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

[Heiko Stuebner]

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.


> 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.


> 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.


Heiko