On Monday, December 17, 2018 1, linux-renesas-soc-owner@xxxxxxxxxxxxxxx wrote: > > Yup...there's the killer! > > You'll notice that in mainline RZ/A devices, there is no QSPI driver, > > and also the QSPI clock is left out of the list of HW clocks. Otherwise, > > as you mentioned, that 'unused' clock would get shut off at the end of > > boot...and you're whole system would stop immediately. > > If you had a simple driver with the binding as I proposed, then it > could do the ioremap and clock management. And you could also have > specific SPI and flash drivers for when you need to flashing without > changing the DT. I agree. At the same time, this particular XIP-QSPI HW is now used in the latest Renesas R-Car devices, and there has been some talk of upstreaming the driver for it (as in, using it in SPI mode instead of XIP mode). I'm waiting to see where that ends up, and if I should just use that SPI mode driver for the RZ/A series but simply put in a new property like "use-xip-mode;" that basically tells the driver to do nothing except enable the clock (again) so it doesn't get shut off at the end of boot. However, with your idea, I could also add in the io-remapping into that driver as well. The only thing I can't remember is if the cramfs-xip driver really needed to have an mtd partition with 'probe-type = "direct-mapped";' underneath it so it could more closely map different regions during run-time. And in that case, the QSPI driver should not be doing an io-remapping because it's not its responsibility (and might screw things up). Chris
