| Message ID | 20191203034519.5640-7-chris.brandt@renesas.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
| Series | spi: Add Renesas SPIBSC controller | expand |
Hello! On 03.12.2019 6:45, Chris Brandt wrote: > Document the bindings used by the Renesas SPI bus space controller. > > Signed-off-by: Chris Brandt <chris.brandt@renesas.com> > --- > .../bindings/spi/spi-renesas-spibsc.txt | 48 +++++++++++++++++++ > 1 file changed, 48 insertions(+) > create mode 100644 Documentation/devicetree/bindings/spi/spi-renesas-spibsc.txt > > diff --git a/Documentation/devicetree/bindings/spi/spi-renesas-spibsc.txt b/Documentation/devicetree/bindings/spi/spi-renesas-spibsc.txt > new file mode 100644 > index 000000000000..b5f7081d2d1e > --- /dev/null > +++ b/Documentation/devicetree/bindings/spi/spi-renesas-spibsc.txt > @@ -0,0 +1,48 @@ > +Renesas SPI Bus Space Controller (SPIBSC) Device Tree Bindings > + > +Otherwise referred to as the "SPI Multi I/O Bus Controller" in SoC hardware > +manuals. This controller was designed specifically for accessing SPI flash > +devices. > + > +Required properties: > +- compatible: should be an SoC-specific compatible value, followed by > + "renesas,spibsc" as a fallback. > + supported SoC-specific values are: > + "renesas,r7s72100-spibsc" (RZ/A1) > + "renesas,r7s9210-spibsc" (RZ/A2) > +- reg: should contain three register areas: > + first for the base address of SPIBSC registers, > + second for the direct mapping read mode That's only 2 areas, not 3. :-) > +- clocks: should contain the clock phandle/specifier pair for the module clock. > +- power-domains: should contain the power domain phandle/specifier pair. > +- #address-cells: should be 1 > +- #size-cells: should be 0 > +- flash: should be represented by a subnode of the SPIBSC node, > + its "compatible" property contains "jedec,spi-nor" if SPI is used. Are any other flash variants supported? > + > +Example: > + > + spibsc: spi@1f800000 { > + compatible = "renesas,r7s9210-spibsc", "renesas,spibsc"; > + reg = <0x1f800000 0x8c>, <0x20000000 0x10000000 >; > + clocks = <&cpg CPG_MOD 83>; > + power-domains = <&cpg>; > + #address-cells = <1>; > + #size-cells = <0>; > + > + flash@0 { > + compatible = "jedec,spi-nor"; > + reg = <0>; > + spi-max-frequency = <40000000>; > + > + partitions { > + compatible = "fixed-partitions"; > + #address-cells = <1>; > + #size-cells = <1>; > + > + partition@0000000 { > + label = "u-boot"; > + reg = <0x00000000 0x80000>; > + }; > + }; > + }; MBR, Sergei
On Tue, Dec 3, 2019, Sergei Shtylyov wrote: > That's only 2 areas, not 3. :-) Thank you! > > +- flash: should be represented by a subnode of the SPIBSC node, > > + its "compatible" property contains "jedec,spi-nor" if SPI is used. > > Are any other flash variants supported? Do you mean other types of SPI flash? I've only used SPI flash devices that are auto detected using "jedec,spi-nor". In theory, you could use other types of SPI flash like "atmel,at45", but no one has every tried it, mostly because the SoC will only boot from JEDEC compatible SPI flash. Chris
On 12/03/2019 04:27 PM, Chris Brandt wrote: >>> +- flash: should be represented by a subnode of the SPIBSC node, >>> + its "compatible" property contains "jedec,spi-nor" if SPI is used. >> >> Are any other flash variants supported? > > Do you mean other types of SPI flash? No, I mean flashes connected via different buses, like HyperBus with the gen3 SoC RPC-IF. If SPI's the only bu supported, there's no point saying "if SPI is used". [...] > Chris MBR, Sergei
On Tue, Dec 3, 2019 1, Sergei Shtylyov wrote: > > Do you mean other types of SPI flash? > > No, I mean flashes connected via different buses, like HyperBus with the > gen3 SoC RPC-IF. > If SPI's the only bu supported, there's no point saying "if SPI is used". OK, I see your point. I will remove the 'if'. The hardware in RZ/A2 also supports HyperFlash and OctaFlash (same as gen3), but RZ/A1 only supports SPI flash. Therefore this driver does not touch PHYCNT.PHYMEM and assumes it is at 0. Chris
Hi Chris, On Tue, Dec 3, 2019 at 4:47 AM Chris Brandt <chris.brandt@renesas.com> wrote: > Document the bindings used by the Renesas SPI bus space controller. > > Signed-off-by: Chris Brandt <chris.brandt@renesas.com> Thanks for your patch! > --- /dev/null > +++ b/Documentation/devicetree/bindings/spi/spi-renesas-spibsc.txt Checkpatch.pl says: WARNING: DT bindings should be in DT schema format. See: Documentation/devicetree/writing-schema.rst > @@ -0,0 +1,48 @@ > +Renesas SPI Bus Space Controller (SPIBSC) Device Tree Bindings > + > +Otherwise referred to as the "SPI Multi I/O Bus Controller" in SoC hardware > +manuals. This controller was designed specifically for accessing SPI flash > +devices. > + > +Required properties: > +- compatible: should be an SoC-specific compatible value, followed by > + "renesas,spibsc" as a fallback. > + supported SoC-specific values are: > + "renesas,r7s72100-spibsc" (RZ/A1) > + "renesas,r7s9210-spibsc" (RZ/A2) Is the fallback valid for RZ/A1, which has its own special match entry in the driver? Will it be valid for R-Car Gen3? If not, you may want to drop it completely. > +- reg: should contain three register areas: > + first for the base address of SPIBSC registers, > + second for the direct mapping read mode > +- clocks: should contain the clock phandle/specifier pair for the module clock. > +- power-domains: should contain the power domain phandle/specifier pair. > +- #address-cells: should be 1 > +- #size-cells: should be 0 > +- flash: should be represented by a subnode of the SPIBSC node, > + its "compatible" property contains "jedec,spi-nor" if SPI is used. What about the "mtd-rom" use for e.g. XIP? interrupts? RZ/A2M seems to have an SPIBSC interrupt, RZ/A1 hasn't. Gr{oetje,eeting}s, Geert
Hi Chris, On Tue, Dec 3, 2019 at 7:57 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Tue, Dec 3, 2019 at 4:47 AM Chris Brandt <chris.brandt@renesas.com> wrote: > > Document the bindings used by the Renesas SPI bus space controller. > > > > Signed-off-by: Chris Brandt <chris.brandt@renesas.com> > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/spi/spi-renesas-spibsc.txt > > @@ -0,0 +1,48 @@ > > +Renesas SPI Bus Space Controller (SPIBSC) Device Tree Bindings > > + > > +Otherwise referred to as the "SPI Multi I/O Bus Controller" in SoC hardware > > +manuals. This controller was designed specifically for accessing SPI flash > > +devices. > > + > > +Required properties: > > +- compatible: should be an SoC-specific compatible value, followed by > > + "renesas,spibsc" as a fallback. > > + supported SoC-specific values are: > > + "renesas,r7s72100-spibsc" (RZ/A1) > > + "renesas,r7s9210-spibsc" (RZ/A2) > > Is the fallback valid for RZ/A1, which has its own special match entry > in the driver? > Will it be valid for R-Car Gen3? > If not, you may want to drop it completely. > > > +- reg: should contain three register areas: > > + first for the base address of SPIBSC registers, > > + second for the direct mapping read mode > > +- clocks: should contain the clock phandle/specifier pair for the module clock. > > +- power-domains: should contain the power domain phandle/specifier pair. > > +- #address-cells: should be 1 > > +- #size-cells: should be 0 > > +- flash: should be represented by a subnode of the SPIBSC node, > > + its "compatible" property contains "jedec,spi-nor" if SPI is used. > > 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. For the direct mapped use-case, you need different bindings: 1. Append "simple-pm-bus" to the list of compatible values, 2. Add a "ranges" property, 3. The flash subnode becomes directly mapped, and must be compatible with "mtd-rom", cfr. the CFI FLASH on ape6evm: arch/arm/boot/dts/r8a73a4.dtsi:bus@fec10000 and arch/arm/boot/dts/r8a73a4-ape6evm.dts:flash@0. 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. Once you have added basic Runtime PM support to drivers/mtd/maps/physmap-core.c:physmap_flash_probe(), the module clock should be kept enabled through the clock domain when using direct mapped mode (hmm, as the driver currently lacks this, it means the FLASH on ape6evm must rely on the bsc module clock being kept enabled through the Ethernet controller connected to the same bsc module?). Does this make sense? Thanks! Gr{oetje,eeting}s, Geert
Hi Geert, As always, thank you for the review. On Tue, Dec 3, 2019, Geert Uytterhoeven wrote: > > +++ b/Documentation/devicetree/bindings/spi/spi-renesas-spibsc.txt > > Checkpatch.pl says: > WARNING: DT bindings should be in DT schema format. See: > Documentation/devicetree/writing-schema.rst :( > > +Required properties: > > +- compatible: should be an SoC-specific compatible value, followed by > > + "renesas,spibsc" as a fallback. > > + supported SoC-specific values are: > > + "renesas,r7s72100-spibsc" (RZ/A1) > > + "renesas,r7s9210-spibsc" (RZ/A2) > > Is the fallback valid for RZ/A1, which has its own special match entry in the > driver? > Will it be valid for R-Car Gen3? > If not, you may want to drop it completely. The fallback would still work for RZ/A1, you just would not be able to set the baud rate. But, I have no problem dropping the fallback. I'm fine with having a compatible string for each SoC that is known to work for. I have not tried it with Gen3, but I would guess there will be some minor difference that will needed to be accounted for. > > +- reg: should contain three register areas: > > + first for the base address of SPIBSC registers, > > + second for the direct mapping read mode > > +- clocks: should contain the clock phandle/specifier pair for the module > clock. > > +- power-domains: should contain the power domain phandle/specifier pair. > > +- #address-cells: should be 1 > > +- #size-cells: should be 0 > > +- flash: should be represented by a subnode of the SPIBSC node, > > + its "compatible" property contains "jedec,spi-nor" if SPI is used. > > What about the "mtd-rom" use for e.g. XIP? But "mtd-rom" doesn't really have anything to do with the functionality of the driver when it is being used in "SPI mode". Maybe I just remove any mention of this for now. > interrupts? RZ/A2M seems to have an SPIBSC interrupt, RZ/A1 hasn't. There was never any interrupts in the SPIBSC. But it looks like when they added HyperFlash and OctaFlash support, they put in some interrupts for that. And now that I look at it, they are for pins labeled RPC_INT, RPC_WC, RPC_RESET. (I just realized that "RPC" stands for "Reduced Pin Count") So....am I supposed to add in that interrupt even though I'm not planning on using it?? Chris
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
On Tue, Dec 3, 2019 at 9:39 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Tue, Dec 3, 2019 at 7:57 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > Once you have added basic Runtime PM support to > drivers/mtd/maps/physmap-core.c:physmap_flash_probe(), the module clock > should be kept enabled through the clock domain when using direct mapped > mode (hmm, as the driver currently lacks this, it means the FLASH on > ape6evm must rely on the bsc module clock being kept enabled through the > Ethernet controller connected to the same bsc module?). JFTR, this is indeed broken: after removing the Ethernet node from r8a73a4-ape6evm.dts, accessing the FLASH crashes the system with an imprecise external abort. Gr{oetje,eeting}s, Geert
Hi Chris, On Tue, Dec 3, 2019 at 11:33 PM Chris Brandt <Chris.Brandt@renesas.com> wrote: > On Tue, Dec 3, 2019, Geert Uytterhoeven wrote: > > > +++ b/Documentation/devicetree/bindings/spi/spi-renesas-spibsc.txt > > > +Required properties: > > > +- compatible: should be an SoC-specific compatible value, followed by > > > + "renesas,spibsc" as a fallback. > > > + supported SoC-specific values are: > > > + "renesas,r7s72100-spibsc" (RZ/A1) > > > + "renesas,r7s9210-spibsc" (RZ/A2) > > > > Is the fallback valid for RZ/A1, which has its own special match entry in the > > driver? > > Will it be valid for R-Car Gen3? > > If not, you may want to drop it completely. > > The fallback would still work for RZ/A1, you just would not be able to > set the baud rate. But, I have no problem dropping the fallback. I'm fine > with having a compatible string for each SoC that is known to work for. > > I have not tried it with Gen3, but I would guess there will be some minor > difference that will needed to be accounted for. OK. > > > +- reg: should contain three register areas: > > > + first for the base address of SPIBSC registers, > > > + second for the direct mapping read mode > > > +- clocks: should contain the clock phandle/specifier pair for the module > > clock. > > > +- power-domains: should contain the power domain phandle/specifier pair. > > > +- #address-cells: should be 1 > > > +- #size-cells: should be 0 > > > +- flash: should be represented by a subnode of the SPIBSC node, > > > + its "compatible" property contains "jedec,spi-nor" if SPI is used. > > > > What about the "mtd-rom" use for e.g. XIP? > > But "mtd-rom" doesn't really have anything to do with the functionality of the > driver when it is being used in "SPI mode". Correct. But DT describes hardware. If the FLASH is used in direct mapped mode, that should be described in DT. > Maybe I just remove any mention of this for now. > > > interrupts? RZ/A2M seems to have an SPIBSC interrupt, RZ/A1 hasn't. > > There was never any interrupts in the SPIBSC. > But it looks like when they added HyperFlash and OctaFlash support, they put > in some interrupts for that. > And now that I look at it, they are for pins labeled RPC_INT, RPC_WC, RPC_RESET. > (I just realized that "RPC" stands for "Reduced Pin Count") > > So....am I supposed to add in that interrupt even though I'm not planning on using > it?? DT describes hardware, not driver limitations. Gr{oetje,eeting}s, Geert
Hi Chris, On Wed, Dec 4, 2019 at 3:55 AM Chris Brandt <Chris.Brandt@renesas.com> 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
Hi Geert, > > But "mtd-rom" doesn't really have anything to do with the > > functionality of the driver when it is being used in "SPI mode". > > Correct. But DT describes hardware. If the FLASH is used in direct mapped > mode, that should be described in DT. So it seems we are going back to my original plan: Always enable the SPIBSC node in the .dts to ensure the clocks stay on for the XIP kernel case. But, if there is no spi-nor partitions in the node, then simple drop out and do not register the device as a SPI controller. However, you can have mtd-rom partitions in there which is what XIP Linux will use, but we still don't need to register a spi controller for that. Do you agree????? > > > interrupts? RZ/A2M seems to have an SPIBSC interrupt, RZ/A1 hasn't. > > > > There was never any interrupts in the SPIBSC. > > But it looks like when they added HyperFlash and OctaFlash support, > > they put in some interrupts for that. > > And now that I look at it, they are for pins labeled RPC_INT, RPC_WC, > RPC_RESET. > > (I just realized that "RPC" stands for "Reduced Pin Count") > > > > So....am I supposed to add in that interrupt even though I'm not > > planning on using it?? > > DT describes hardware, not driver limitations. OK. I will add the interrupt to the DT. Chris
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
Hi Chris, On Wed, Dec 4, 2019 at 2:31 PM Chris Brandt <Chris.Brandt@renesas.com> wrote: > > 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. Your spibsc driver does: master->mode_bits = SPI_CPOL | SPI_CPHA; i.e. SPI_[TR]X_{QUAD,DUAL} are not set, so it should not try those modes. At least on RSK+RZA1, the FLASHes are wired in quad mode, so you should describe the hardware in DT. > > 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)??? No, in the board .dtb. > > 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). Good. So that means the MTD driver can be modular. Unused clocks are turned off at boot, and can be turned on when the mtd-rom driver is loaded and activated. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org 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
Hi Geert, On Thu, Dec 5, 2019 1, Geert Uytterhoeven wrote: > Your spibsc driver does: > > master->mode_bits = SPI_CPOL | SPI_CPHA; > > i.e. SPI_[TR]X_{QUAD,DUAL} are not set, so it should not try those modes. OK, Thank you! > At least on RSK+RZA1, the FLASHes are wired in quad mode, so you should > describe the hardware in DT. OK. > > > 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). > > Good. So that means the MTD driver can be modular. Unused clocks are turned > off at boot, and can be turned on when the mtd-rom driver is loaded and > activated. I'm going to do some testing now and then send out a V2 to see if we are getting closer to a consensus. Chris
diff --git a/Documentation/devicetree/bindings/spi/spi-renesas-spibsc.txt b/Documentation/devicetree/bindings/spi/spi-renesas-spibsc.txt new file mode 100644 index 000000000000..b5f7081d2d1e --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-renesas-spibsc.txt @@ -0,0 +1,48 @@ +Renesas SPI Bus Space Controller (SPIBSC) Device Tree Bindings + +Otherwise referred to as the "SPI Multi I/O Bus Controller" in SoC hardware +manuals. This controller was designed specifically for accessing SPI flash +devices. + +Required properties: +- compatible: should be an SoC-specific compatible value, followed by + "renesas,spibsc" as a fallback. + supported SoC-specific values are: + "renesas,r7s72100-spibsc" (RZ/A1) + "renesas,r7s9210-spibsc" (RZ/A2) +- reg: should contain three register areas: + first for the base address of SPIBSC registers, + second for the direct mapping read mode +- clocks: should contain the clock phandle/specifier pair for the module clock. +- power-domains: should contain the power domain phandle/specifier pair. +- #address-cells: should be 1 +- #size-cells: should be 0 +- flash: should be represented by a subnode of the SPIBSC node, + its "compatible" property contains "jedec,spi-nor" if SPI is used. + +Example: + + spibsc: spi@1f800000 { + compatible = "renesas,r7s9210-spibsc", "renesas,spibsc"; + reg = <0x1f800000 0x8c>, <0x20000000 0x10000000 >; + clocks = <&cpg CPG_MOD 83>; + power-domains = <&cpg>; + #address-cells = <1>; + #size-cells = <0>; + + flash@0 { + compatible = "jedec,spi-nor"; + reg = <0>; + spi-max-frequency = <40000000>; + + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + partition@0000000 { + label = "u-boot"; + reg = <0x00000000 0x80000>; + }; + }; + };
Document the bindings used by the Renesas SPI bus space controller. Signed-off-by: Chris Brandt <chris.brandt@renesas.com> --- .../bindings/spi/spi-renesas-spibsc.txt | 48 +++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/spi-renesas-spibsc.txt