On Fri, Nov 25, 2016 at 10:22:59AM +0100, Geert Uytterhoeven wrote: > Hi Magnus, > > (this time with CC kept) > > On Fri, Nov 25, 2016 at 9:16 AM, Magnus Damm <magnus.damm@xxxxxxxxx> wrote: > > On Mon, Nov 21, 2016 at 8:09 PM, Geert Uytterhoeven > > <geert@xxxxxxxxxxxxxx> wrote: > >> On Thu, Nov 17, 2016 at 9:51 AM, Magnus Damm <magnus.damm@xxxxxxxxx> wrote: > >>> On Thu, Nov 17, 2016 at 5:31 PM, Geert Uytterhoeven > >>> <geert@xxxxxxxxxxxxxx> wrote: > >>>> On Thu, Nov 17, 2016 at 3:28 AM, Magnus Damm <magnus.damm@xxxxxxxxx> wrote: > >>>>> First of all, we might have slightly different view of the hardware, > >>>>> so this might need some further discussions. Also, this topic in my > >>>>> mind is mainly about DT integration code merge ordering for r8a7796 to > >>>>> enable >4GB memory access early on without introducing any potential > >>>>> issues. > >>>> > >>>> Note that >4GB memory is already enabled on r8a7796 by U-Boot. > >>> > >>> Right, can you remind me - did we get any conclusion about how to > >>> handle the memory ranges in DTS and the ones from u-boot? > >>> > >>> It would be good with a consistent plan how to handle such. > >> > >> I think we should just apply "arm64: dts: r8a7796: salvator-x: Update memory > >> node to 4 GiB map". > > > > I guess that we cannot control what u-boot will pass to us, but with > > the patch above at least we have some chance of having a consistent > > memory map. > > Indeed. > > >> IMHO it doesn't make much sense to pretend the memory is not present nor > >> enabled. > > > > Enabling all the memory makes sense at this point, but I'd like us to > > keep considering performance of bounce buffers and/or IPMMU when > > merging different on-chip devices that may not support addressing of > > the full physical memory space. > > > > We earlier had issues with "enable-and-forget" development approach in > > case of USB host over on-chip PCI for the R-Car Gen2 family of > > devices. In that case the hardware was unable to do bus mastering to > > all the memory but this was not considered as part of the upstreaming > > plan and instead came as a nasty surprise later on. So for each device > > that we develop code for and integrate i would like to make sure that > > we understand how memory handling is supposed to work and what > > potential workarounds we may have to use. > > Sure. > > All existing devices in r8a7796.dtsi in Simon's tree either use PIO, or DMA > through SYS-DMAC. The latter supports 64-bit addressing hardware-wise, > but the software side needs a patch to enable that, cfr. "[PATCH/RFC 5/5] > dmaengine: rcar-dmac: Widen DMA mask to 40 bits". > Without that, it still works, but using swiotlb bounce buffers. > > Once that's fixed, there are no performance deteriorations due to bounce > buffers, with the current set of enabled devices. So we can enable all the memory with a low risk of regression?
