Hi Geert, > To avoid future problems, you probably do want to specify spi-tx-bus-width = > <4> and spi-rx-bus-width = <4> in DTS now. I didn't do that because if the MTD layer then thinks I 'want' to do 4-bit access, then that introduces a new problem the solve. The MTD layer might start sending down QUAD READ commands to the external SPI and then the SPI Flash will start sending back data on all 4 lines, but the controller is only configured for 1-bit transfers. I honestly don't know when/why the MTD layer decides on switch from 1-bit to 4-bit mode, so while the board hardware is wired for 4-bit (as the DT would document), we are not ready to be doing 4-bit just yet. I just want to try and get the driver in at first....then we can make it do fancy stuff later. If someone can tell me that even if "spi-rx-bus-width = <4>" is put I the board DTS, the spi will still only do 1-bit transfers until the application specially enables 4-bit mode, then I'm fine with add bus-width=<4> in the DTS. Unless....I did not understand you meaning.... Did you mean put 'spi-rx-bus-width = <4>' in the .dtsi???? (then I can override it back to <1> that in the board .dts)??? > > 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. Yes, I agree. That is what I would suggest to someone. (I suggest unbind/bind for a lot of situations that people ask me what to do). > (Which cuts the branch the kernel is sitting on in the case of XIP...) XIP is a special case all in it's own.....which is why we uses a completely special driver for R/W in XIP mode...which is out of scope from mainline. The case I'm talking above would probably before an R-Car or RZ/G use case. But, since no one has stated a use case like that, it's very low on the priority list. > > 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). I can agree with that....and we go back to my first idea: If you are 'using' the SPIBSC for anything (XIP or SPI mode) then you describe that in DT. And when the driver probes, if it does not see a 'spi-nor' partition, it does not register a spi-controller, but it does keep the clock (power) on the entire time (until removed). For GR-PEACH, we would just have to go back and put the qspi@18000000 (which is currently at the root) node under a spibsc node. Of course also if we do all this, we could drop all the patches for enabling 'critical clocks' that were needed to cover the XIP cases. > BTW, when using spibsc in direct-mapped mode: if you turn of and on again the > module clock, does the spibsc need reprogramming? Nope. Everything will stay the same (just like all the other peripherals). The only thing you 'might' want to do is flush the read cache (especially if you disconnected it because you were going to go out and re-write some of the flash in SPI mode). Chris
