Hi Magnus,
(this time with CC kept)
On Fri, Nov 25, 2016 at 9:16 AM, Magnus Damm <magnus.d...@gmail.com> wrote:
> On Mon, Nov 21, 2016 at 8:09 PM, Geert Uytterhoeven
> <ge...@linux-m68k.org> wrote:
>> On Thu, Nov 17, 2016 at 9:51 AM, Magnus Damm <magnus.d...@gmail.com> wrote:
>>> On Thu, Nov 17, 2016 at 5:31 PM, Geert Uytterhoeven
>>> <ge...@linux-m68k.org> wrote:
>>>> On Thu, Nov 17, 2016 at 3:28 AM, Magnus Damm <magnus.d...@gmail.com> 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.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
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
