Hi Chris,
On Wed, Dec 4, 2019 at 3:55 AM Chris Brandt <Chris.Brandt@xxxxxxxxxxx> wrote:
> On Tue, Dec 3, 2019, Geert Uytterhoeven wrote:
> > > What about the "mtd-rom" use for e.g. XIP?
> >
> > I gave this some more thought. Basically there are two modes: SPI FLASH and
> > direct mapped emulation (HyperFLASH could be a third mode).
> > The bindings described above are for the SPI FLASH use-case.
>
> I would say in general, there are just two modes "SPI Mode" which was
> intended to do things like discover the attached flash and erase/writing.
> And direct mapped which was intended only for reading. Both of those
> modes were intended to be used for QSPI flash, HyperFlash or OctaFlash.
> There's a register bit you set to tell the PHY what you are talking to.
OK.
> > On the driver side, if your spibsc driver does not find a flash subnode that
> > is compatible with "jedec,spi-nor", it should return -ENODEV, so
> > drivers/bus/simple-pm-bus.c can take over for the second mode, if needed.
>
> I think here is the bigger issue/question/decision.
>
> This one IP block supports 3 different types of Flash: QSPI, Hyper, Octa.
> Also, it runs in 2 mode:
> "SPI Mode" for writing and other stuff
> "Direct Mode" Read only, but faster and directly accessible.
>
> (QSPI also supports 1-bit,2-bit,4-bit, and 8-bit(dual)....but we'll
> forget about that for now )
To avoid future problems, you probably do want to specify
spi-tx-bus-width = <4> and spi-rx-bus-width = <4> in DTS now.
> So the question is if someone really wants to use it in "direct mode"
> most of the time, but also need to switch back into "SPI mode" to rewrite
> the flash, should this driver handle both cases?
>
> Basically, it's like the 'role switch' in the USB OTG drivers.
If you want to do that, both configurations should be described in DT,
and we need a way to specify what's being used.
I guess if the direct mapped mode is used, you always want to boot the
kernel using that mode, and only switch to SPI mode temporarily after
boot? So that could be handled by manually unbinding the driver
from physmap-flash, and forcing a bind to spibsc, all from sysfs.
(Which cuts the branch the kernel is sitting on in the case of XIP...)
Suggestions are welcome!
> This driver I created was just attempting to cover the "SPI mode" case
> for those that want to be able to re-write u-boot at run-time. And, it
> could be extended to support HyperFlash and OctaFlash in SPI mode as well
> (you use the same registers, but the commands are different).
OK.
> So my suggestion is to forget about trying to 'support' direct mode in
> this driver at the moment. If you're using this HW for something like
> XIP, then don't enable this driver at all (which is what we have been
> doing).
Still, the direct-mapped mode should be described in DT, when used.
arch/arm/boot/dts/r7s72100-gr-peach.dts does describe the FLASH,
but fails to describe the exact topology (flash is a child of spibsc,
and thus relies on the spibsc module clock being turned on).
BTW, when using spibsc in direct-mapped mode: if you turn of and on
again the module clock, does the spibsc need reprogramming?
Thanks!
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
