From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Stuebner Date: Sat, 06 Jul 2019 20:04:52 +0200 Subject: [U-Boot] =?utf-8?q?=5BPATCH_2/3=5D_bouncebuf=3A_Add_DMA_validatio?= =?utf-8?b?biBjaGVjayB0byBhZGRyX2FsaWduZWQoKS7jgJDor7fms6jmhI/vvIw=?= =?utf-8?b?6YKu5Lu255SxdS1ib290LWJvdW5jZXNAbGlzdHMuZGVueC5kZeS7ow==?= =?utf-8?b?5Y+R44CRIGFkZHJfYWxpZ25lZCgpLg==?= In-Reply-To: References: <20190507090531.50670-1-christoph.muellner@theobroma-systems.com> <2220262.IZ0ZhdZ1cB@diego> Message-ID: <9652847.KtFbExOVNQ@phil> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: u-boot@lists.denx.de Hi Simon, Am Samstag, 6. Juli 2019, 19:16:29 CEST schrieb Simon Glass: > On Thu, 4 Jul 2019 at 14:43, Heiko St=C3=BCbner 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 > > > > 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 > > > >> --- > > > >> > > > >> 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 driv= er, > > > > 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 ucl= ass > > > 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). >=20 > 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