| Message ID | 1439522892-7524-1-git-send-email-marex@denx.de |
|---|---|
| State | Superseded |
| Headers | show |
Hi Marek, On 08/13/2015 08:28 PM, Marek Vasut wrote: > From: Graham Moore <grmoore@opensource.altera.com> > > Add binding document for the Cadence QSPI controller. > > Signed-off-by: Graham Moore <grmoore@opensource.altera.com> > Signed-off-by: Marek Vasut <marex@denx.de> > Cc: Alan Tull <atull@opensource.altera.com> > Cc: Brian Norris <computersforpeace@gmail.com> > Cc: David Woodhouse <dwmw2@infradead.org> > Cc: Dinh Nguyen <dinguyen@opensource.altera.com> > Cc: Graham Moore <grmoore@opensource.altera.com> > Cc: Vikas MANOCHA <vikas.manocha@st.com> > Cc: Yves Vandervennet <yvanderv@opensource.altera.com> > Cc: devicetree@vger.kernel.org > --- > .../devicetree/bindings/mtd/cadence_quadspi.txt | 50 ++++++++++++++++++++++ > 1 file changed, 50 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mtd/cadence_quadspi.txt > > V2: Add cdns prefix to driver-specific bindings. > V3: Use existing property "is-decoded-cs" instead of creating a > duplicate, "ext-decoder". Timing parameters are in nanoseconds, > not master reference clocks. Remove bus-num completely. > V4: Add new properties fifo-width and trigger-address > V7: - Prefix all of the Cadence-specific properties with cdns prefix, > those are in particular "cdns,is-decoded-cs", "cdns,fifo-depth", > "cdns,fifo-width", "cdns,trigger-address". > - Drop bogus properties which were not used and were incorrect. > > diff --git a/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt b/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt > new file mode 100644 > index 0000000..ebaf1fd > --- /dev/null > +++ b/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt > @@ -0,0 +1,50 @@ > +* Cadence Quad SPI controller > + > +Required properties: > +- compatible : Should be "cdns,qspi-nor". > +- reg : Contains two entries, each of which is a tuple consisting of a > + physical address and length. The first entry is the address and > + length of the controller register set. The second entry is the > + address and length of the QSPI Controller data area. "Controller data area", i think it means mapped NOR Flash address ? If yes, it would be more clear with "Physical base address & size of NOR Flash". > +- interrupts : Unit interrupt specifier for the controller interrupt. > +- clocks : phandle to the Quad SPI clock. > +- cdns,fifo-depth : Size of the data FIFO in words. It actually is sram-depth, better would be "sram-depth" to avoid confusion. > +- cdns,fifo-width: Bus width of the data FIFO in bytes. > +- cdns,trigger-address : 32-bit indirect AHB trigger address. we might make trigger-address also part of property "reg". > + > +Optional properties: > +- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not. Not clear about the usage of decoder, if it does not make sense we might remove it from driver. > + > +Optional subnodes: I think flash subnode is mandatory. Rgds, Vikas > +Subnodes of the Cadence Quad SPI controller are spi slave nodes with additional > +custom properties: > +- cdns,read-delay : Delay for read capture logic, in clock cycles > +- cdns,tshsl-ns : Delay in nanoseconds for the length that the master mode chip select outputs are de-asserted between transactions. > +- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being de-activated and the activation of another. > +- cdns,tchsh-ns : Delay in nanoseconds between last bit of current transaction and deasserting the device chip select (qspi_n_ss_out). > +- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low and first bit transfer. > + > +Example: > + > + qspi: spi@ff705000 { > + compatible = "cdns,qspi-nor"; > + #address-cells = <1>; > + #size-cells = <0>; > + reg = <0xff705000 0x1000>, > + <0xffa00000 0x1000>; > + interrupts = <0 151 4>; > + clocks = <&qspi_clk>; > + cdns,is-decoded-cs; > + cdns,fifo-depth = <128>; > + cdns,fifo-width = <4>; > + cdns,trigger-address = <0x00000000>; > + > + flash0: n25q00@0 { > + ... > + cdns,read-delay = <4>; > + cdns,tshsl-ns = <50>; > + cdns,tsd2d-ns = <50>; > + cdns,tchsh-ns = <4>; > + cdns,tslch-ns = <4>; > + }; > + }; >
On Tuesday, August 18, 2015 at 04:35:55 AM, vikas wrote: > Hi Marek, > > On 08/13/2015 08:28 PM, Marek Vasut wrote: > > From: Graham Moore <grmoore@opensource.altera.com> > > > > Add binding document for the Cadence QSPI controller. > > > > Signed-off-by: Graham Moore <grmoore@opensource.altera.com> > > Signed-off-by: Marek Vasut <marex@denx.de> > > Cc: Alan Tull <atull@opensource.altera.com> > > Cc: Brian Norris <computersforpeace@gmail.com> > > Cc: David Woodhouse <dwmw2@infradead.org> > > Cc: Dinh Nguyen <dinguyen@opensource.altera.com> > > Cc: Graham Moore <grmoore@opensource.altera.com> > > Cc: Vikas MANOCHA <vikas.manocha@st.com> > > Cc: Yves Vandervennet <yvanderv@opensource.altera.com> > > Cc: devicetree@vger.kernel.org > > --- > > > > .../devicetree/bindings/mtd/cadence_quadspi.txt | 50 > > ++++++++++++++++++++++ 1 file changed, 50 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/mtd/cadence_quadspi.txt > > > > V2: Add cdns prefix to driver-specific bindings. > > V3: Use existing property "is-decoded-cs" instead of creating a > > > > duplicate, "ext-decoder". Timing parameters are in nanoseconds, > > not master reference clocks. Remove bus-num completely. > > > > V4: Add new properties fifo-width and trigger-address > > V7: - Prefix all of the Cadence-specific properties with cdns prefix, > > > > those are in particular "cdns,is-decoded-cs", "cdns,fifo-depth", > > "cdns,fifo-width", "cdns,trigger-address". > > > > - Drop bogus properties which were not used and were incorrect. > > > > diff --git a/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt > > b/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt new file > > mode 100644 > > index 0000000..ebaf1fd > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt > > @@ -0,0 +1,50 @@ > > +* Cadence Quad SPI controller > > + > > +Required properties: > > +- compatible : Should be "cdns,qspi-nor". > > +- reg : Contains two entries, each of which is a tuple consisting of a > > + physical address and length. The first entry is the address and > > + length of the controller register set. The second entry is the > > + address and length of the QSPI Controller data area. > > "Controller data area", i think it means mapped NOR Flash address ? Probably ; Graham ? > If yes, it would be more clear with "Physical base address & size of NOR > Flash". This is the Direct mode thing, correct ? We don't support this, so I think we should drop this bit altogether and keep only one single address in this field. > > +- interrupts : Unit interrupt specifier for the controller interrupt. > > +- clocks : phandle to the Quad SPI clock. > > +- cdns,fifo-depth : Size of the data FIFO in words. > > It actually is sram-depth, better would be "sram-depth" to avoid confusion. Is there any documentation for this piece to which you can point me ? > > +- cdns,fifo-width: Bus width of the data FIFO in bytes. > > +- cdns,trigger-address : 32-bit indirect AHB trigger address. > > we might make trigger-address also part of property "reg". No, we cannot, it's not part of the controller's base address, is it ? > > + > > +Optional properties: > > +- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not. > > Not clear about the usage of decoder, if it does not make sense we might > remove it from driver. Graham ? SoCFPGA uses this decoded-cs thing, so we absolutely can not remove it from the driver. > > +Optional subnodes: > I think flash subnode is mandatory. You can have a controller with no SPI NORs on it.
Ho Marek, > On Aug 17, 2015, at 9:48 PM, Marek Vasut <marex@denx.de> wrote: > >> On Tuesday, August 18, 2015 at 04:35:55 AM, vikas wrote: >> Hi Marek, >> >>> On 08/13/2015 08:28 PM, Marek Vasut wrote: >>> From: Graham Moore <grmoore@opensource.altera.com> >>> >>> Add binding document for the Cadence QSPI controller. >>> >>> Signed-off-by: Graham Moore <grmoore@opensource.altera.com> >>> Signed-off-by: Marek Vasut <marex@denx.de> >>> Cc: Alan Tull <atull@opensource.altera.com> >>> Cc: Brian Norris <computersforpeace@gmail.com> >>> Cc: David Woodhouse <dwmw2@infradead.org> >>> Cc: Dinh Nguyen <dinguyen@opensource.altera.com> >>> Cc: Graham Moore <grmoore@opensource.altera.com> >>> Cc: Vikas MANOCHA <vikas.manocha@st.com> >>> Cc: Yves Vandervennet <yvanderv@opensource.altera.com> >>> Cc: devicetree@vger.kernel.org >>> --- >>> >>> .../devicetree/bindings/mtd/cadence_quadspi.txt | 50 >>> ++++++++++++++++++++++ 1 file changed, 50 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/mtd/cadence_quadspi.txt >>> >>> V2: Add cdns prefix to driver-specific bindings. >>> V3: Use existing property "is-decoded-cs" instead of creating a >>> >>> duplicate, "ext-decoder". Timing parameters are in nanoseconds, >>> not master reference clocks. Remove bus-num completely. >>> >>> V4: Add new properties fifo-width and trigger-address >>> V7: - Prefix all of the Cadence-specific properties with cdns prefix, >>> >>> those are in particular "cdns,is-decoded-cs", "cdns,fifo-depth", >>> "cdns,fifo-width", "cdns,trigger-address". >>> >>> - Drop bogus properties which were not used and were incorrect. >>> >>> diff --git a/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt >>> b/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt new file >>> mode 100644 >>> index 0000000..ebaf1fd >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt >>> @@ -0,0 +1,50 @@ >>> +* Cadence Quad SPI controller >>> + >>> +Required properties: >>> +- compatible : Should be "cdns,qspi-nor". >>> +- reg : Contains two entries, each of which is a tuple consisting of a >>> + physical address and length. The first entry is the address and >>> + length of the controller register set. The second entry is the >>> + address and length of the QSPI Controller data area. >> >> "Controller data area", i think it means mapped NOR Flash address ? > > Probably ; Graham ? > >> If yes, it would be more clear with "Physical base address & size of NOR >> Flash". > > This is the Direct mode thing, correct ? We don't support this, so I think > we should drop this bit altogether and keep only one single address in this > field. No it's not. > >>> +- interrupts : Unit interrupt specifier for the controller interrupt. >>> +- clocks : phandle to the Quad SPI clock. >>> +- cdns,fifo-depth : Size of the data FIFO in words. >> >> It actually is sram-depth, better would be "sram-depth" to avoid confusion. > > Is there any documentation for this piece to which you can point me ? It's on the controller data sheet , should also be part of socfpga doc, let me know the document you have access to, I will point to the relevant part. > >>> +- cdns,fifo-width: Bus width of the data FIFO in bytes. >>> +- cdns,trigger-address : 32-bit indirect AHB trigger address. >> >> we might make trigger-address also part of property "reg". > > No, we cannot, it's not part of the controller's base address, is it ? Ok. > >>> + >>> +Optional properties: >>> +- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not. >> >> Not clear about the usage of decoder, if it does not make sense we might >> remove it from driver. > > Graham ? SoCFPGA uses this decoded-cs thing, so we absolutely can not remove > it from the driver. > >>> +Optional subnodes: >> I think flash subnode is mandatory. > > You can have a controller with no SPI NORs on it. Without spi nor this controller/driver can't be used for anything. Rgds, Vikas
Hi all, On 08/18/2015 12:48 AM, Vikas MANOCHA wrote: [...] >>>> +Required properties: >>>> +- compatible : Should be "cdns,qspi-nor". >>>> +- reg : Contains two entries, each of which is a tuple consisting of a >>>> + physical address and length. The first entry is the address and >>>> + length of the controller register set. The second entry is the >>>> + address and length of the QSPI Controller data area. >>> >>> "Controller data area", i think it means mapped NOR Flash address ? >> >> Probably ; Graham ? >> >>> If yes, it would be more clear with "Physical base address & size of NOR >>> Flash". >> >> This is the Direct mode thing, correct ? We don't support this, so I think >> we should drop this bit altogether and keep only one single address in this >> field. > > No it's not. > It's the location of the SRAM fifo. Also direct mode location I think, if that were ever used. The size is determined by a configuration parameter during system design. On Altera Cyclone5 the size is really big compared to SRAM fifo. I don't know why, maybe some hw engineer thought it would be better to have a large size in case direct mode was used. BR, Graham
Hi, On 08/18/2015 12:03 PM, Graham Moore wrote: > Hi all, > > On 08/18/2015 12:48 AM, Vikas MANOCHA wrote: > > [...] > >>>>> +Required properties: >>>>> +- compatible : Should be "cdns,qspi-nor". >>>>> +- reg : Contains two entries, each of which is a tuple consisting of a >>>>> + physical address and length. The first entry is the address and >>>>> + length of the controller register set. The second entry is the >>>>> + address and length of the QSPI Controller data area. >>>> >>>> "Controller data area", i think it means mapped NOR Flash address ? >>> >>> Probably ; Graham ? >>> >>>> If yes, it would be more clear with "Physical base address & size of NOR >>>> Flash". >>> >>> This is the Direct mode thing, correct ? We don't support this, so I think >>> we should drop this bit altogether and keep only one single address in this >>> field. >> >> No it's not. >> > > It's the location of the SRAM fifo. Also direct mode location I think, > if that were ever used. Hmm...It is the base address of NOR flash. SRAM is not memory mapped. > > The size is determined by a configuration parameter during system > design. On Altera Cyclone5 the size is really big compared to SRAM > fifo. I don't know why, maybe some hw engineer thought it would be > better to have a large size in case direct mode was used. my comment is about second parameter of property "reg" which is NOR flash address, so above explanation does not make sense for it. Also in direct mode, sram does not come into play. Rgds, Vikas > > BR, > Graham > . >
On Tuesday, August 18, 2015 at 10:18:33 PM, vikas wrote: > Hi, > > On 08/18/2015 12:03 PM, Graham Moore wrote: > > Hi all, > > > > On 08/18/2015 12:48 AM, Vikas MANOCHA wrote: > > > > [...] > > > >>>>> +Required properties: > >>>>> +- compatible : Should be "cdns,qspi-nor". > >>>>> +- reg : Contains two entries, each of which is a tuple consisting of > >>>>> a + physical address and length. The first entry is the address > >>>>> and + length of the controller register set. The second entry is > >>>>> the + address and length of the QSPI Controller data area. > >>>> > >>>> "Controller data area", i think it means mapped NOR Flash address ? > >>> > >>> Probably ; Graham ? > >>> > >>>> If yes, it would be more clear with "Physical base address & size of > >>>> NOR Flash". > >>> > >>> This is the Direct mode thing, correct ? We don't support this, so I > >>> think we should drop this bit altogether and keep only one single > >>> address in this field. > >> > >> No it's not. > > > > It's the location of the SRAM fifo. Also direct mode location I think, > > if that were ever used. > > Hmm...It is the base address of NOR flash. SRAM is not memory mapped. Huh ? I am inclined to trust Graham more -- I have seen memory mapped SRAM, but I have yet to see memory mapped SPI NOR. Also, the driver code clearly uses that area in a way one would use a memory mapped SRAM with FIFO on the other side. I think the above description is pretty much OK. > > The size is determined by a configuration parameter during system > > design. On Altera Cyclone5 the size is really big compared to SRAM > > fifo. I don't know why, maybe some hw engineer thought it would be > > better to have a large size in case direct mode was used. > > my comment is about second parameter of property "reg" which is NOR flash > address, so above explanation does not make sense for it. > Also in direct mode, sram does not come into play. This is absolutelly not a SPI NOR address. Best regards, Marek Vasut
Hi, On 08/19/2015 09:03 PM, Marek Vasut wrote: > On Tuesday, August 18, 2015 at 10:18:33 PM, vikas wrote: >> Hi, >> >> On 08/18/2015 12:03 PM, Graham Moore wrote: >>> Hi all, >>> >>> On 08/18/2015 12:48 AM, Vikas MANOCHA wrote: >>> >>> [...] >>> >>>>>>> +Required properties: >>>>>>> +- compatible : Should be "cdns,qspi-nor". >>>>>>> +- reg : Contains two entries, each of which is a tuple consisting of >>>>>>> a + physical address and length. The first entry is the address >>>>>>> and + length of the controller register set. The second entry is >>>>>>> the + address and length of the QSPI Controller data area. >>>>>> >>>>>> "Controller data area", i think it means mapped NOR Flash address ? >>>>> >>>>> Probably ; Graham ? >>>>> >>>>>> If yes, it would be more clear with "Physical base address & size of >>>>>> NOR Flash". >>>>> >>>>> This is the Direct mode thing, correct ? We don't support this, so I >>>>> think we should drop this bit altogether and keep only one single >>>>> address in this field. >>>> >>>> No it's not. >>> >>> It's the location of the SRAM fifo. Also direct mode location I think, >>> if that were ever used. >> >> Hmm...It is the base address of NOR flash. SRAM is not memory mapped. > > Huh ? I am inclined to trust Graham more -- I have seen memory mapped SRAM, > but I have yet to see memory mapped SPI NOR. Well, SPI NOR flash in SOCs normally is memory mapped. To give some mainline examples, all Spear family SOCs (spear300, 320, 1310, 1340). > Also, the driver code clearly > uses that area in a way one would use a memory mapped SRAM with FIFO on the > other side. I think the above description is pretty much OK. that is the purpose of making NOR flash memory mapped. > >>> The size is determined by a configuration parameter during system >>> design. On Altera Cyclone5 the size is really big compared to SRAM >>> fifo. I don't know why, maybe some hw engineer thought it would be >>> better to have a large size in case direct mode was used. >> >> my comment is about second parameter of property "reg" which is NOR flash >> address, so above explanation does not make sense for it. >> Also in direct mode, sram does not come into play. > > This is absolutelly not a SPI NOR address. Then i can only suggest to check out the controller literature. Think like this : what is the purpose of SRAM in all this flash access business, It can work without SRAM also, the only purpose of sram (& in fact indirect mode) is to access data from flash memory without AHB access to trigger it. Once the data is available in SRAM(in case of read), AHB Master can access it with low letency. Same is true for writes. SRAM is integral internal part of state machine in case of indirect mode, there is no need for it to memory mapped. If the controller does not support indirect mode, there is no need of sram in the system. Hope it is little bit more clear. Cheers, Vikas > > Best regards, > Marek Vasut > . >
On Thursday, August 20, 2015 at 06:06:49 PM, vikas wrote: > Hi, Hi! [...] > >>> It's the location of the SRAM fifo. Also direct mode location I think, > >>> if that were ever used. > >> > >> Hmm...It is the base address of NOR flash. SRAM is not memory mapped. > > > > Huh ? I am inclined to trust Graham more -- I have seen memory mapped > > SRAM, but I have yet to see memory mapped SPI NOR. > > Well, SPI NOR flash in SOCs normally is memory mapped. I'm afraid you have some very disturbed views of how SPI NORs are operated most of the time. No, SPI NOR is most often hanging off of some sort of SPI controller just like any other SPI device. It is definitelly not common for a SPI NOR to be memory mapped. > To give some mainline examples, all Spear family SOCs (spear300, 320, 1310, > 1340). That's an exception, not a rule :) > > Also, the driver code clearly > > uses that area in a way one would use a memory mapped SRAM with FIFO on > > the other side. I think the above description is pretty much OK. > > that is the purpose of making NOR flash memory mapped. I'm not sure if you agree with me or not anymore. I am pretty sure the discussion went quite far for such a trivial matter though. > >>> The size is determined by a configuration parameter during system > >>> design. On Altera Cyclone5 the size is really big compared to SRAM > >>> fifo. I don't know why, maybe some hw engineer thought it would be > >>> better to have a large size in case direct mode was used. > >> > >> my comment is about second parameter of property "reg" which is NOR > >> flash address, so above explanation does not make sense for it. > >> Also in direct mode, sram does not come into play. > > > > This is absolutelly not a SPI NOR address. > > Then i can only suggest to check out the controller literature. > > Think like this : what is the purpose of SRAM in all this flash access > business, It can work without SRAM also, the only purpose of sram (& in > fact indirect mode) is to access data from flash memory without AHB access > to trigger it. Once the data is available in SRAM(in case of read), AHB > Master can access it with low letency. Same is true for writes. SRAM is > integral internal part of state machine in case of indirect mode, there is > no need for it to memory mapped. If the controller does not support > indirect mode, there is no need of sram in the system. > > Hope it is little bit more clear. It is, I understand what you're trying to convey now. Yes, this register area can be used in certain modes of the controller in such a way that it presents a window of the SPI NOR, which can be directly accessed. This register area can also be used as a FIFO, which is the way we used this area in the driver . We read/write the first four bytes when communicating with the flash. So I don't really see a problem with calling the second register a "Controller data area", that's what the IP documentation also calls it.
Hi, > On Aug 20, 2015, at 10:20 PM, Marek Vasut <marex@denx.de> wrote: > >> On Thursday, August 20, 2015 at 06:06:49 PM, vikas wrote: >> Hi, > > Hi! > > [...] > >>>>> It's the location of the SRAM fifo. Also direct mode location I think, >>>>> if that were ever used. >>>> >>>> Hmm...It is the base address of NOR flash. SRAM is not memory mapped. >>> >>> Huh ? I am inclined to trust Graham more -- I have seen memory mapped >>> SRAM, but I have yet to see memory mapped SPI NOR. >> >> Well, SPI NOR flash in SOCs normally is memory mapped. > > I'm afraid you have some very disturbed views of how SPI NORs are operated > most of the time. Just wondering what should I say, hoping you will sit back and try to correct your views. > No, SPI NOR is most often hanging off of some sort of SPI > controller just like any other SPI device. It is definitelly not common for > a SPI NOR to be memory mapped. Definitely ? And what made you think like this ? Do you even know the spi peripheral you are sending patch for has memory mapped nor flash ? > >> To give some mainline examples, all Spear family SOCs (spear300, 320, 1310, >> 1340). > > That's an exception, not a rule :) And there are many such exceptions starting from this cadence qspi :-) > >>> Also, the driver code clearly >>> uses that area in a way one would use a memory mapped SRAM with FIFO on >>> the other side. I think the above description is pretty much OK. >> >> that is the purpose of making NOR flash memory mapped. > > I'm not sure if you agree with me or not anymore. I am pretty sure the > discussion went quite far for such a trivial matter though. I definitely disagree with you. I stop here now. Cheers, Vikas > >>>>> The size is determined by a configuration parameter during system >>>>> design. On Altera Cyclone5 the size is really big compared to SRAM >>>>> fifo. I don't know why, maybe some hw engineer thought it would be >>>>> better to have a large size in case direct mode was used. >>>> >>>> my comment is about second parameter of property "reg" which is NOR >>>> flash address, so above explanation does not make sense for it. >>>> Also in direct mode, sram does not come into play. >>> >>> This is absolutelly not a SPI NOR address. >> >> Then i can only suggest to check out the controller literature. >> >> Think like this : what is the purpose of SRAM in all this flash access >> business, It can work without SRAM also, the only purpose of sram (& in >> fact indirect mode) is to access data from flash memory without AHB access >> to trigger it. Once the data is available in SRAM(in case of read), AHB >> Master can access it with low letency. Same is true for writes. SRAM is >> integral internal part of state machine in case of indirect mode, there is >> no need for it to memory mapped. If the controller does not support >> indirect mode, there is no need of sram in the system. >> >> Hope it is little bit more clear. > > It is, I understand what you're trying to convey now. > > Yes, this register area can be used in certain modes of the controller in > such a way that it presents a window of the SPI NOR, which can be directly > accessed. > > This register area can also be used as a FIFO, which is the way we used this > area in the driver . We read/write the first four bytes when communicating > with the flash. > > So I don't really see a problem with calling the second register a "Controller > data area", that's what the IP documentation also calls it.
diff --git a/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt b/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt new file mode 100644 index 0000000..ebaf1fd --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt @@ -0,0 +1,50 @@ +* Cadence Quad SPI controller + +Required properties: +- compatible : Should be "cdns,qspi-nor". +- reg : Contains two entries, each of which is a tuple consisting of a + physical address and length. The first entry is the address and + length of the controller register set. The second entry is the + address and length of the QSPI Controller data area. +- interrupts : Unit interrupt specifier for the controller interrupt. +- clocks : phandle to the Quad SPI clock. +- cdns,fifo-depth : Size of the data FIFO in words. +- cdns,fifo-width: Bus width of the data FIFO in bytes. +- cdns,trigger-address : 32-bit indirect AHB trigger address. + +Optional properties: +- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not. + +Optional subnodes: +Subnodes of the Cadence Quad SPI controller are spi slave nodes with additional +custom properties: +- cdns,read-delay : Delay for read capture logic, in clock cycles +- cdns,tshsl-ns : Delay in nanoseconds for the length that the master mode chip select outputs are de-asserted between transactions. +- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being de-activated and the activation of another. +- cdns,tchsh-ns : Delay in nanoseconds between last bit of current transaction and deasserting the device chip select (qspi_n_ss_out). +- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low and first bit transfer. + +Example: + + qspi: spi@ff705000 { + compatible = "cdns,qspi-nor"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0xff705000 0x1000>, + <0xffa00000 0x1000>; + interrupts = <0 151 4>; + clocks = <&qspi_clk>; + cdns,is-decoded-cs; + cdns,fifo-depth = <128>; + cdns,fifo-width = <4>; + cdns,trigger-address = <0x00000000>; + + flash0: n25q00@0 { + ... + cdns,read-delay = <4>; + cdns,tshsl-ns = <50>; + cdns,tsd2d-ns = <50>; + cdns,tchsh-ns = <4>; + cdns,tslch-ns = <4>; + }; + };