[U-Boot] [RFC] ARM: rmobile: create DT memory nodes for R8A7795 3.0 and newer

[Laurent Pinchart]

Hi Magnus,

On Tuesday, 19 June 2018 08:43:31 EEST Magnus Damm wrote:
> On Tue, Jun 19, 2018 at 11:15 AM, Laurent Pinchart wrote:
> > On Sunday, 17 June 2018 03:08:02 EEST Marek Vasut wrote:
> >> On 06/16/2018 05:44 PM, Laurent Pinchart wrote:
> >>> On Saturday, 16 June 2018 02:42:30 EEST Marek Vasut wrote:
> >>>> On 06/16/2018 01:21 AM, Laurent Pinchart wrote:
> >>>>> On Friday, 15 June 2018 15:00:31 EEST Marek Vasut wrote:
> >>>>>> On 06/15/2018 01:43 PM, Marek Vasut wrote:

[snip]

> >>>>>>> Yet, I have to wonder if ATF doesn't already contain some sort of
> >>>>>>> standard SMC call to get memory topology. It surprises me that it
> >>>>>>> wouldn't.
> >>>>>> 
> >>>>>> In fact, Laurent (CCed) was solving some similar issue with lossy
> >>>>>> decomp and I think this involved some passing of memory layout
> >>>>>> information from ATF to U-Boot too, or am I mistaken ?
> >>>>> 
> >>>>> That's correct, ATF stores information about the memory layout at a
> >>>>> fixed address in system memory, and U-Boot can read it.
> >>>> 
> >>>> Well, that sounds good ! Maybe we can avoid adding SMC call altogether
> >>>> then? :)
> >>> 
> >>> I'd prefer that, yes.
> >>> 
> >>> Let's not duplicate the mechanism used to pass FCNL information from
> >>> ATF to U- Boot, but instead create a data table format that can store
> >>> all the information we need, in an easily extensible way.
> >>> 
> >>> To see how the mechanism is implemented for FCNL, search for 47FD7000
> >>> in the Renesas ATF sources
> >>> (git://github.com/renesas-rcar/arm-trusted-firmware.git).
> >> 
> >> For everyone involved, can you explain what FCNL is ? ;-)
> > 
> > FCNL is Frame Compression Near Lossless. It's a way to reduce memory
> > bandwidth by transparent compression and decompression of video frames.
> > Compression is handled by an IP core called FCP, and decompression is
> > handled by the DRAM controller. ATF programs the DRAM controller with
> > ranges of memory addresses that will be dynamically decompressed. The
> > registers containing those ranges are accessible in secure mode only, so
> > neither U-Boot nor Linux can read them. That's why ATF has to pass the
> > information to U-Boot, in order to add the ranges as reserved memory in
> > DT.
> 
> Thanks for the clarification. I wonder how much of the split between
> ATF and "the rest" can be adjusted. It smells like just a software
> architecture policy, my gut feeling is that LIFEC can be programmed to
> adjust the assignment between secure side and "regular". At least it
> can do so for a wide range of bus masters. However if this is the case
> for FCNL remains to be seen.
> 
> As a side note, for FCNL I personally would prefer a more dynamic
> solution where we manage physically contiguous ranges from Linux
> during run time instead of relying of statically setup windows.

So would I, but whether we can be allowed to access those registers from Linux 
isn't my decision :-/

> >> Any yes, I agree this sounds good. I had a discussion on the U-Boot IRC
> >> about passing the memory configuration around and the result is
> >> basically the same -- pass a table from ATF to U-Boot. If there's
> >> already something, great.

-- 
Regards,

Laurent Pinchart