Hi, On Thu, 4 Jul 2019 at 14:43, Heiko Stübner <[email protected]> wrote: > > Hi Simon, > > Am Dienstag, 4. Juni 2019, 05:23:14 CEST schrieb Kever Yang: > > On 05/19/2019 12:08 AM, Simon Glass wrote: > > > On Tue, 7 May 2019 at 03:05, Christoph Muellner > > > <[email protected]> wrote: > > >> Currently addr_aligned() performs an alignment and a length check > > >> to validate the DMA address. However, some machines have stricter > > >> restrictions of DMA-able addresses. > > >> > > >> This patch adds a call to mach_addr_is_dmaable() to honor this > > >> machine specific restrictions. > > >> > > >> Signed-off-by: Christoph Muellner > > >> <[email protected]> > > >> --- > > >> > > >> common/bouncebuf.c | 6 ++++++ > > >> 1 file changed, 6 insertions(+) > > > I feel like this should be handled with DM. Can we add a new method to > > > the DMA uclass to check an address? If not provided by the DMA driver, > > > we can assume the address is OK. > > > > The DMA in MMC controller which is not stand alone, do not using the > > driver of DMA uclass, so I'm afraid this is not able to using DMA uclass > > for this address check. > > were you able to consider Kever's response? > > The issue bites us for example when the mmc-driver with its internal dma > does transfer atf loadables to the socs sram. There is no system dma > controller involved but so far we're experiencing this on _all_ Rockchip > socs that need multiple parts of the ATF be written to different memory > locations. (the sram code is obviously needed for suspend/resume).
I don't really understand the thing about the internal MMC DMA controller. Is it not possible to call a DMA driver to validate an address, or to allocate an address? It isn't necessary to use the driver for a transfer. But if this is related to DMA, then it seems to me that the DMA uclass should support the functionality, perhaps with a new method? Regards, Simon _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
