Hi Geert, 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. > 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 ) 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. 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). 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). Chris
