[PATCH] arm64: dts: juno: Enable some SMMUs
Robin Murphy
robin.murphy at arm.com
Tue Jun 6 08:59:12 PDT 2017
On 06/06/17 16:45, Jean-Philippe Brucker wrote:
> Hello,
>
> On 18/05/17 13:23, Robin Murphy wrote:
>> The IOMMU-backed DMA API support has now been in place for a while and
>> proven stable, so there's no real need to keep most of Juno's SMMUs
>> disabled. The USB, HDLCDs, and CoreSight ETR all just need to map RAM
>> buffers for DMA - enabling their SMMUs obviates CPU bounce buffering for
>> USB's streaming DMA to the upper memory bank, and lets the other two
>> allocate their relatively large coherent buffers without pressuring CMA.
>>
>> Some more software work is still needed for the DMA-330 and PCIe before
>> those can accommodate SMMU translation correctly in all cases, so we
>> leave those alone for now.
>
> Out of curiosity, what is missing for DMA-330? I can use dmatest over SMMU
> on my juno-r1 by enabling the node, but I don't have any complex workload
> yet. Guest pass-through is really unreliable and I'm trying to figure out why.
Yes, dmatest has always been fine* since both ends get mapped for DMA
appropriately by the client. The missing bit is, or should I say was,
4d6d74e22096 currently in linux-next.
Robin.
* For certain values of fine, anyway. There are a number of catastrophic
races in the driver that make it generally a bad idea to use more than 1
thread per channel.
>
> Thanks,
> Jean
>
More information about the linux-arm-kernel
mailing list