[U-Boot] [PATCH 2/3] bouncebuf: Add DMA validation check to addr_aligned().【请注意，邮件由u-boot-bounces at lists.denx.de代发】 addr_aligned().

[Heiko Stuebner]

Hi Simon,

just pulling up this thread again, as it would be great if we could
resolve how to proceed here.

The important points regarding your questions are below.


Am Samstag, 6. Juli 2019, 20:04:52 CEST schrieb Heiko Stuebner:
> Am Samstag, 6. Juli 2019, 19:16:29 CEST schrieb Simon Glass:
> > On Thu, 4 Jul 2019 at 14:43, Heiko Stübner <heiko at sntech.de> wrote:
> > > 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
> > > > > <christoph.muellner at theobroma-systems.com> 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 <christoph.muellner at theobroma-systems.com>
> > > > >> ---
> > > > >>
> > > > >>  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.
>
> The dw_mmc IP block can either be connected to a system-level
> dma controller (like a pl330 on for example the rk3188)
> or have its own completely separate dma-controller _inside_ the
> dw-mmc ip-block itself (I think all newer Rockchip socs for example).
> 
> > 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.
> 
> For the internal-dma case, there really is no separate dma-driver
> involved, all is contained in dw-mmc.
> 
> On rk3288 on the kernel-side we also "just" blocked off the offending
> memory area due to all other approaches being cumbersome,
> with multiple IP blocks all bringing their own dma-controllers
> circumventing the system-level ones.
> 
> > 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?
> 
> So something like
> 	int dma_address_is_allowed(void *address);
> which then calls into a system-specific function (or valus from Kconfig)?
> Or do you have something different in mind?


Thanks
Heiko