[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,

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