From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko =?ISO-8859-1?Q?St=FCbner?= Date: Thu, 04 Jul 2019 22:43:25 +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> Message-ID: <2220262.IZ0ZhdZ1cB@diego> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Simon, 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 driver, > > 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 uclass > 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). Thanks Heiko