On 23.05.19 00:57, Simon Glass wrote: > Hi Heiko, > > On Wed, 22 May 2019 at 05:29, Heiko Stuebner <[email protected]> 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 >>> <[email protected]> wrote: >>>> >>>> From: Christoph Müllner <[email protected]> >>>> >>>> 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 <[email protected]> >>>> Signed-off-by: Christoph Muellner >>>> <[email protected]> >>>> --- >>>> >>>> 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?
Yes, that is also confirmed by Kever (see commit message of [1]). My patch series assumes, that only the CPU can see the non-DDR memory areas (including SRAM). I would really like to get feedback here from Kever. Kever has posted a first patch to address this end of March [2]. After waiting a few weeks, I've prepared a reworked version (because I needed it for mainline ATF testing on our RK3399-Q7). A few hours after I sent them to the list Kever also pushed another patch for this [1]. From my perspective mainline ATF cannot be used with mainline U-Boot on RK3399 when booting from SD card or eMMC at the moment. [1] https://patchwork.ozlabs.org/patch/1096366/ [2] https://patchwork.ozlabs.org/patch/1069730/ > > 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 [email protected] https://lists.denx.de/listinfo/u-boot
