Getting back to an issue after more than a month of summer.
> With hpwdt disabled, can you reboot a few times and look for DMAR
> faults in the dmesg to see if they're all consistent, ie. device 1e.0
> doing a read from 0xb000? Is there any correlation to radeon hanging
> and one of those DMAR fa
Let's fix the error handle of ipmmu_add_device
when failing to find utlbs, otherwise we take a
risk of pontential memleak.
Signed-off-by: Shawn Lin
---
Changes in v2:
- use error-out path
drivers/iommu/ipmmu-vmsa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/io
On 23/08/16 20:05, Robin Murphy wrote:
> Hi all,
Oh bums, looks like I managed to miss LAKML off the CC list. If anyone
there is interested, it's over here:
https://lists.linuxfoundation.org/pipermail/iommu/2016-August/018230.html
Robin.
>
> At long last I've finished the big SMMUv2 rework, so
When an MSI doorbell is located downstream of an IOMMU, attaching
devices to a DMA ops domain and switching on translation leads to a rude
shock when their attempt to write to the physical address returned by
the irqchip driver faults (or worse, writes into some already-mapped
buffer) and no interr
For non-aperture-based IOMMUs, the domain geometry seems to have become
the de-facto way of indicating the input address space size. That is
quite a useful thing from the users' perspective, so let's do the same.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu-v3.c | 2 ++
drivers/iommu/a
With everything else now in place, fill in an of_xlate callback and the
appropriate registration to plumb into the generic configuration
machinery, and watch everything just work.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu.c | 168 ++-
1 fi
We iterate over the SMEs associated with a master config quite a lot in
various places, and are about to do so even more. Let's wrap the idiom
in a handy iterator macro before the repetition gets out of hand.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu.c | 26 -
Stream Match Registers are one of the more awkward parts of the SMMUv2
architecture; there are typically never enough to assign one to each
stream ID in the system, and configuring them such that a single ID
matches multiple entries is catastrophically bad - at best, every
transaction raises a glob
Making S2CRs first-class citizens within the driver with a high-level
representation of their state offers a neat solution to a few problems:
Firstly, the information about which context a device's stream IDs are
associated with is already present by necessity in the S2CR. With that
state easily a
Document how the generic "iommus" binding should be used to describe ARM
SMMU stream IDs instead of the old "mmu-masters" binding.
CC: Rob Herring
CC: Mark Rutland
Signed-off-by: Robin Murphy
---
.../devicetree/bindings/iommu/arm,smmu.txt | 63 --
1 file changed, 48
In the final step of preparation for full generic configuration support,
swap our fixed-size master_cfg for the generic iommu_fwspec. For the
legacy DT bindings, the driver simply gets to act as its own 'firmware'.
Farewell, arbitrary MAX_MASTER_STREAMIDS!
Signed-off-by: Robin Murphy
---
drivers
Rather than assuming fixed worst-case values for stream IDs and SMR
masks, keep track of whatever implemented bits the hardware actually
reports. This also obviates the slightly questionable validation of SMR
fields in isolation - rather than aborting the whole SMMU probe for a
hardware configurati
In order to consider SMR masking, we really want to be able to validate
ID/mask pairs against existing SMR contents to prevent stream match
conflicts, which at best would cause transactions to fault unexpectedly,
and at worst lead to silent unpredictable behaviour. With our SMMU
instance data holdi
Implement the SMMUv3 equivalent of d346180e70b9 ("iommu/arm-smmu: Treat
all device transactions as unprivileged"), so that once again those
pesky DMA controllers with their privileged instruction fetches don't
unexpectedly fault in stage 1 domains due to VMSAv8 rules.
Signed-off-by: Robin Murphy
Simplify things somewhat by stashing our arm_smmu_device instance in
drvdata, so that it's readily available to our driver model callbacks.
Then we can excise the private list entirely, since the driver core
already has a perfectly good list of SMMU devices we can use in the one
instance we actuall
To be able to support the generic bindings and handle of_xlate() calls,
we need to be able to associate SMMUs and stream IDs directly with
devices *before* allocating IOMMU groups. Furthermore, to support real
default domains with multi-device groups we also have to handle domain
attach on a per-de
Now that we can properly describe the mapping between PCI RIDs and
stream IDs via "iommu-map", and have it fed it to the driver
automatically via of_xlate(), rework the SMMUv3 driver to benefit from
that, and get rid of the current misuse of the "iommus" binding.
Since having of_xlate wired up mea
Hi all,
At long last I've finished the big SMMUv2 rework, so here's everything
all together for a v5. As a quick breakdown:
Patches 1-3 are the core PCI part, all acked and ready to go. No code
changes from v4.
Patch 4 is merely bugfixed from v4 for simplicity, as I've not yet
managed to take as
Now that we have a way to pick up the RID translation and target IOMMU,
hook up of_iommu_configure() to bring PCI devices into the of_xlate
mechanism and allow them IOMMU-backed DMA ops without the need for
driver-specific handling.
Signed-off-by: Robin Murphy
---
drivers/iommu/of_iommu.c | 43 +
With the device <-> stream ID relationship suitably abstracted and
of_xlate() hooked up, the PCI dependency now looks, and is, entirely
arbitrary. Any bus using the of_dma_configure() mechanism will work,
so extend support to the platform and AMBA buses which do just that.
Signed-off-by: Robin Mur
The PCI msi-map code is already doing double-duty translating IDs and
retrieving MSI parents, which unsurprisingly is the same functionality
we need for the identically-formatted PCI iommu-map property. Drag the
core parsing routine up yet another layer into the general OF-PCI code,
and further gen
From: Mark Rutland
The existing IOMMU bindings are able to specify the relationship between
masters and IOMMUs, but they are insufficient for describing the general
case of hotpluggable busses such as PCI where the set of masters is not
known until runtime, and the relationship between masters an
Introduce a common structure to hold the per-device firmware data that
non-architectural IOMMU drivers generally need to keep track of.
Initially this is DT-specific to complement the existing of_iommu
support code, but will generalise further once other firmware methods
(e.g. ACPI IORT) come along
Hi Russell,
If you have the time can you please have a look at this patch? This
series have been out for some time now and Vinod is willing to take it
through the dmaengine tree but a ACK is needed on this patch from you
first.
On 2016-08-10 13:22:17 +0200, Niklas Söderlund wrote:
> Add method
Hi Rafael,
On Mon, Aug 15, 2016 at 04:23:26PM +0100, Lorenzo Pieralisi wrote:
> On systems booting with a device tree, every struct device is
> associated with a struct device_node, that represents its DT
> representation. The device node can be used in generic kernel
> contexts (eg IRQ translatio
25 matches
Mail list logo
