Hi Robin,
On 3/5/2018 5:46 PM, Robin Murphy wrote:
Hi Vivek,
On 05/03/18 09:06, Vivek Gautam wrote:
Hi all,
I have a question regarding usage of 'dma-ranges', can someone point
me in the right direction?
On qcom soc, few of the master devices with iommu attached to them,
have limitations in using the iova address range. They can allow the
iova to be only in a certain range, e.g. video codec firmware can
only access iova only in a first few MBs as the video's arm core
reset starts at 0x0.
To do that, I earlier, had the understanding that we can modify the
iommu_domain's geometry aperture. But that looks kind of a hacky way
to get the domain for the device and modify the aperture.
I was trying to explore if we can use the dma-ranges property. But
the iommu bindings documentation doesn't really talks much about
usage of dma-ranges.
Can someone help me with with the answer to - can we use 'dma-ranges'
to limit a device's iova address access? If yes, then how?
Yes, if the device has physical restrictions on what it can address,
then "dma-ranges" is the correct way to describe that. That should be
pretty much orthogonal to the IOMMU binding and combine in the obvious
way, e.g.:
...
soc {
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
ranges;
...
iommu@f0000000 {
compatible = "iommu";
reg = <0xf0000000 0x1000>;
#iommu-cells = <0>;
};
...
subsystem {
Usually, the multimedia devices are just the device nodes without
any subsystem. Can dma-ranges, and iommus exist together for the
device?
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
ranges;
/* Devices can only drive address bits 0:23 */
dma-ranges = <0 0 0x1000000>;
device {
iommus = <&iommu>;
};
};
};
...
In terms of Linux, for the straightforward platform device case
of_dma_configure() initialises the subsystem devices' DMA masks based
on the size covered by "dma-ranges", and the DMA API code respects the
device's DMA mask when allocating IOVAs. The only problem is the bit
in the middle where the device driver's dma_set_mask() call can just
trash of_dma_configure()'s initial mask, because there's no way to
differentiate an explicitly-specified mask from a default one.
But the drivers should ideally check for any existing dma_mask set for
the device before calling dma_set_mask_and_coherent(). I see few of the
drivers do check that, so we don't overwrite the dma mask.
It's also even uglier for PCI devices since the existing "pass the
host bridge's node as the device's" bodge happens to work for the
"dma-coherent" property but is a bit broken in general and doesn't
work at all for "dma-ranges".
Fixing all of this (not to mention the DT/ACPI interaction aspect) has
been hovering around #3 on my to-do list for the past couple of years
now, but things keep sneaking in above it :(
Anything that I can take a look at, and add?
regards
Vivek
Robin.
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
