Hi Heiko, On Wed, 22 May 2019 at 05:29, Heiko Stuebner <he...@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.muell...@theobroma-systems.com> wrote: > > > > > > From: Christoph Müllner <christoph.muell...@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.muell...@theobroma-systems.com> > > > Signed-off-by: Christoph Muellner > > > <christoph.muell...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot