Re: [PATCH] arm64: dts: juno: Enable some SMMUs

On 06/06/17 16:59, Robin Murphy wrote:

On 06/06/17 16:45, Jean-Philippe Brucker wrote:

quoted

Hello,

On 18/05/17 13:23, Robin Murphy wrote:

quoted

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.

Ah I see, thanks. The issue I was seeing was mismatched dma-coherency,
which I fixed. But my guest does sometimes hang when running 1024
threads/chan in dmatest, so that might be it.

Thanks,
Jean

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html