Hi Simon,
On Thu, Dec 8, 2016 at 2:28 PM, Simon Horman <horms@xxxxxxxxxxxx> wrote:
> On Fri, Nov 25, 2016 at 10:22:59AM +0100, Geert Uytterhoeven wrote:
>> 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?
Yes.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
