[U-Boot] [PATCH v3 11/11] spi: cadence_qspi: Support specifying the sample edge used
Phil Edworthy
phil.edworthy at renesas.com
Tue Dec 6 11:25:39 CET 2016
Hi Marek,
On 05 December 2016 13:31, Marek Vasut wrote:
> On 12/05/2016 11:46 AM, Phil Edworthy wrote:
> > On 05 December 2016 10:42, Jagan Teki wrote:
> >> On Mon, Dec 5, 2016 at 11:31 AM, Phil Edworthy
> >> <phil.edworthy at renesas.com> wrote:
> >>> On 05 December 2016 10:26, Jagan Teki wrote:
> >>>> On Mon, Dec 5, 2016 at 11:09 AM, Phil Edworthy
> >>>> <phil.edworthy at renesas.com> wrote:
> >>>>> On 02 December 2016 14:23, Jagan Teki wrote:
> >>>>>> On Tue, Nov 29, 2016 at 6:28 PM, Phil Edworthy
> >>>>>> <phil.edworthy at renesas.com> wrote:
> >>>>>>> Introduce a new DT property to specify whether the QSPI Controller
> >>>>>>> samples the data on a rising edge. The default is falling edge.
> >>>>>>> Some versions of the QSPI Controller do not implement this bit, in
> >>>>>>> which case the property should be omitted.
> >>>>>>>
> >>>>>>> Signed-off-by: Phil Edworthy <phil.edworthy at renesas.com>
> >>>>>>> ---
> >>>>>>> v3:
> >>>>>>> - Patch split so this one only has code related to the subject.
> >>>>>>> - Commit message updated.
> >>>>>>> v2:
> >>>>>>> - Change name of DT prop and provide details of what it does.
> >>>>>>> Whilst at it, move the code to read the "sram-size" property
> >>>>>>> into the other code that reads properties from the node, rather
> >>>>>>> than the SF subnode.
> >>>>>>>
> >>>>>>> Also change the code to use a bool for the bypass arg.
> >>>>>>> ---
> >>>>>>> doc/device-tree-bindings/spi/spi-cadence.txt | 2 ++
> >>>>>>> drivers/spi/cadence_qspi.c | 10 +++++++---
> >>>>>>> drivers/spi/cadence_qspi.h | 3 ++-
> >>>>>>> drivers/spi/cadence_qspi_apb.c | 8 +++++++-
> >>>>>>> 4 files changed, 18 insertions(+), 5 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/doc/device-tree-bindings/spi/spi-cadence.txt b/doc/device-
> >> tree-
> >>>>>> bindings/spi/spi-cadence.txt
> >>>>>>> index c1e2233..94c800b 100644
> >>>>>>> --- a/doc/device-tree-bindings/spi/spi-cadence.txt
> >>>>>>> +++ b/doc/device-tree-bindings/spi/spi-cadence.txt
> >>>>>>> @@ -26,3 +26,5 @@ connected flash properties
> >>>>>>> select (n_ss_out).
> >>>>>>> - tslch-ns : Delay in master reference clocks between setting
> >>>>>>> n_ss_out low and first bit transfer
> >>>>>>> +- sample-edge-rising : Data outputs from flash memory will be
> sampled
> >> on
> >>>>>> the
> >>>>>>> + rising edge. Default is falling edge.
> >>>>>>
> >>>>>> Code look reasonable, but how Linux handling this with the same dt
> >>>>>> property, any idea? I couldn't find it either.
> >>>>> The Linux driver does not yet have this property. Is there a policy to add
> new
> >>>>> props to Linux first?
> >>>>
> >>>> If the same/equal code used in Linux better to have the same property
> >>>> instead of another name used in U-boot?
> >>> Of course, but I cannot see this in Linux:
> >>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-
> >> next.git/tree/Documentation/devicetree/bindings/spi/spi-cadence.txt
> >>
> >> Yeah, I saw this. Do you have any idea how Linux handling this sample edge?
> > The same way U-Boot currently handles it, i.e. it does nothing with this.
> Intel/Altera
> > (Chin Liang) said that they do not have this bit in their version of the Cadence
> QSPI
> > Controller.
> >
> > We are using a later version that has had this bit added.
>
> You were looking at the wrong bindings:
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-
> next.git/tree/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
Thanks for pointing that out!
> but yes, Linux does not do support the data edge toggling. I think there
> was another QSPI patch in Linux which tried adding such property, so
> check linux-mtd for it. Generic one would be great.
I had a search around, but couldn't find anything.
> And no, there is no policy for pushing new props to linux first. New DT
> props should ideally get approved via devicetree at vger though, but that's
> about it. Also, while I tried backporting the Linux CQSPI driver to
> U-Boot, but unfortunately, it turned out to be extremely difficult due
> significant differences between the Linux and U-Boot SPI NOR framework.
OK, thanks for the information.
Thanks
Phil
More information about the U-Boot
mailing list