RE: [PATCH 2/2] ARM: dts: r7s9210-rza2mevb: Add support for RZ/A2M EVB

From: Chris Brandt <Chris.Brandt@renesas.com>
To: Rob Herring <robh@kernel.org>, Kumar Gala <kumar.gala@linaro.org>
Cc: Simon Horman <horms@verge.net.au>,
	Mark Rutland <mark.rutland@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"open list:MEDIA DRIVERS FOR RENESAS - FCP"
	<linux-renesas-soc@vger.kernel.org>
Subject: RE: [PATCH 2/2] ARM: dts: r7s9210-rza2mevb: Add support for RZ/A2M EVB
Date: Wed, 12 Dec 2018 18:03:29 +0000	[thread overview]
Message-ID: <TY2SPR01MB0015C0AC923F1CDEC44061D88AA70@TY2SPR01MB0015.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <CAL_Jsq+Ah7Xg0VnEaYyn4giFeQme9r9GyRsFDucq78BP+Cw2=A@mail.gmail.com>

On Wednesday, December 12, 2018 1, Rob Herring wrote:
> > Not really.
> > The "QSPI" actually works as a memory mapped SPI (as in, the CPU sees
> > the QSPI flash as a linear read-only address range).
> 
> Yes, those controllers are becoming pretty standard.

Ya, my SoCs are not so special any more :(

But, XIP_KERNEL does not seem to be mainstream either.

> > Therefore, there is no need to know anything about the actually
> > Flash that is connected, because you are never allowed to interact with
> it
> > (or even query it on boot).
> 
> Okay, but these days u-boot uses DT itself. So how does u-boot know
> how to set things up? It's going to need to know what controller and
> flash details.

That's all hand coded at the moment. As these Quad-SPI chips came on the
market, each vendor had their own way to get in (and out) of these 
modes, and even the protocols were not the same. Sometimes even the same 
flash vendor would do things different form chip to chip. At this point, 
(at least for Renesas) I have u-boot code that at least points you in the 
right direction depending on what flash vendor you go with....but I 
can't guarantee you won't need to do some tweaking.

> Or how does one do a flash update (in the field)?
Well....for that there's a "special" driver that I wrote. Basically, 
going back to the ways we've done it with MCU for years: Copy code to RAM, 
shut off interrupts, jump to RAM, do your business, jump back to flash.

Again, tweaking is needed depending on what SPI flash you use, so there 
is no magic 'one driver fits all'.

> I think it would be better to have a property to say the flash is
> already setup and just use it. Or maybe it can be done with
> compatibles:
> 
> spi@1234 {
>   compatible = "vendor,soc-quadspi", "mmio-spi";
>   flash@0 {
>     compatible = "some-flash-part", "mtd-rom";
>   };
> };
> 
> Now the problem is how to define the address range as SPI flash
> devices are already defined to use SPI chip-select numbers. The
> easiest option from a DT standpoint is just look at the parent reg
> property and figure out the memory range (typically there are 2 and
> you want the big one). Or you could have some simple driver that knows
> which reg range to get for specific compatibles.

I'm still confused on why I would want to do this as I want the kernel 
to not know nothing about the underlying HW so it never tries to access
it any way.
At the end of the day, all I want is for the kernel to do an ioremap of 
this area for me so my file system (XIP cramfs in this case) can access 
it. "mtd-rom" does this for me today.

Just FYI, early in boot, the kernel already mapped part of my QSPI into 
virtual memory since we're most likely running an XIP_KERNEL.

While these XIP Linux systems seem to function quiet well, I might need 
to continue to hide some of the inner details from mainline because they
don't always fit into the direction of the kernel systems (ie, monster 
quad core systems with lots of DDR memory).

The other XIP file system that we use more often (AXFS, not in mainline)
does not require the partitions in DT at all, so it's really only 
needed when using cramfs. So for now, maybe it would be better to just remove
this confusing portion of the dts.

Chris