[U-Boot] [PATCH v2 1/3] board_f: Add mach specific DMA address check function.

[Simon Glass]

Hi Heiko,

On Wed, 22 May 2019 at 05:29, Heiko Stuebner <heiko at sntech.de> wrote:
>
> Hi Simon,
>
> Am Samstag, 18. Mai 2019, 18:08:58 CEST schrieb Simon Glass:
> > On Tue, 7 May 2019 at 09:59, Christoph Muellner
> > <christoph.muellner at theobroma-systems.com> wrote:
> > >
> > > From: Christoph Müllner <christoph.muellner at theobroma-systems.com>
> > >
> > > Some machines have limited DMA engines, which cannot deal
> > > with arbitrary addresses. This patch introduces a function
> > > to model these restrictions on a machine level.
> > >
> > > Signed-off-by: Christoph Müllner <christoph.muellner at theobroma-systems.com>
> > > Signed-off-by: Christoph Muellner <christoph.muellner at theobroma-systems.com>
> > > ---
> > >
> > > Changes in v2: None
> > >
> > >  common/board_f.c | 5 +++++
> > >  include/init.h   | 2 ++
> > >  2 files changed, 7 insertions(+)
> > >
> >
> > Can we handle this with driver model somehow? How does the kernel
> > handle it?
>
> The problem Christoph is trying to solve here is doing a mmc transfer
> from mmc to the sram (not main memory), which cannot use dma.
> So this exact problem doesn't happen in the kernel itself.
>
> But back in veyron times we had a similar dma issue with anything accessing
> that area as dma hung the system, but the solution was just reserving the
> memblock:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b21bcfc9fda56bac573367d18ce3e4dbf3cdedf9
>
> As the commit describes, other options would've been soc-settings
> also going around the kernel's driver model or limiting the dma-able
> memory even more (to 2GB), so we opted to just reserve the upper 16MB
> completely.

OK I see.

>
>
> > Is there a device-tree binding for the DMA node that could
> > provide this information.
>
> I don't think so. At least in the kernel affecting the dma-mask is a
> setting for the using component (mmc, gmac, whatever), so would
> mean adapting every device doing dma ... and even then there wasn't
> a dt-binding for something like that, which in turn would've required
> to adapt every driver to set a specific per-soc dma-mask for Rockchip
> compatibles - hence the "simple" reserve above was the least intrusive
> option.

That's odd. Are you saying that some devices can DMA from SRAM and some cannot?

If the DMA is not allowed, could the DMA driver return -EPERM or
similar when the attempt is made, and then the bounce buffer can be
used if needed?

>
>
> > Also, where is this function called from?
>
> In the theobroma u-boot it gets called from the bouncebuffer right now
>         https://git.theobroma-systems.com/puma-u-boot.git/commit/?id=d68222d45b4e7f55f500f5e28722cb4304ecde96
> to check if the mmc drivers can dma directly or needs to use the
> bouncebuffer for reaching something like the sram.

OK ta.

>
>
> Heiko
>
>

Regards,
Simon