Hi Geert, On Mon, Nov 21, 2016 at 8:09 PM, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > Hi Magnus, > > 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. > 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. Thanks! / magnus
