RE: [PATCH v4 1/1] i2c: ocores: fix polling mode workaround on FU540-C000 SoC
Hello Peter,
> -Original Message-
> From: Peter Korsgaard On Behalf Of Peter Korsgaard
> Sent: Wednesday, October 21, 2020 9:16 PM
> To: Sagar Kadam
> Cc: linux-kernel@vger.kernel.org; linux-ri...@lists.infradead.org; linux-
> i...@vger.kernel.org; and...@lunn.ch; Paul Walmsley ( Sifive)
> ; pal...@dabbelt.com;
> a...@eecs.berkeley.edu
> Subject: Re: [PATCH v4 1/1] i2c: ocores: fix polling mode workaround on
> FU540-C000 SoC
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> >>>>> "Sagar" == Sagar Shrikant Kadam writes:
>
> > The FU540-C000 has a broken IRQ and support was added earlier
> > so that it will operate in polling mode, but seems to work only
> > in case interrupts property is missing from the i2c0 dt-node.
> > This should not be the case and the driver should handle polling
> > mode with the interrupt property present in i2c0 node of the
> > device tree.
> > So check if it's the FU540-C000 soc and enable polling mode master
> > xfers, as the IRQ for this chip is broken.
>
> > Fixes commit c45d4ba86731 ("i2c: ocores: add polling mode workaround
> > for Sifive FU540-C000 SoC")
>
> > Signed-off-by: Sagar Shrikant Kadam
>
> LGTM, thanks.
>
> Acked-by: Peter Korsgaard
>
Thank you for the review and "Acked-by"
BR,
Sagar
> --
> Bye, Peter Korsgaard
RE: [PATCH v3 1/1] i2c: ocores: fix polling mode workaround on FU540-C000 SoC
Hello Peter,
> -Original Message-
> From: Peter Korsgaard On Behalf Of Peter Korsgaard
> Sent: Thursday, October 15, 2020 8:19 PM
> To: Sagar Kadam
> Cc: linux-kernel@vger.kernel.org; linux-ri...@lists.infradead.org; linux-
> i...@vger.kernel.org; and...@lunn.ch; Paul Walmsley ( Sifive)
> ; pal...@dabbelt.com;
> a...@eecs.berkeley.edu
> Subject: Re: [PATCH v3 1/1] i2c: ocores: fix polling mode workaround on
> FU540-C000 SoC
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> >>>>> "Sagar" == Sagar Shrikant Kadam writes:
>
> > The FU540-C000 has a broken IRQ and support was added earlier
> > so that it will operate in polling mode, but seems to work only
> > in case interrupts property is missing from the i2c0 dt-node.
> > This should not be the case and the driver should handle polling
> > mode with the interrupt property present in i2c0 node of the
> > device tree.
> > So check if it's the FU540-C000 soc and enable polling mode master
> > xfers, as the IRQ for this chip is broken.
>
> > Fixes commit c45d4ba86731 ("i2c: ocores: add polling mode workaround
> > for Sifive FU540-C000 SoC")
>
> > Signed-off-by: Sagar Shrikant Kadam
> > ---
> > drivers/i2c/busses/i2c-ocores.c | 22 +-
> > 1 file changed, 13 insertions(+), 9 deletions(-)
>
> > diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-
> ocores.c
> > index f5fc75b..1dab02d 100644
> > --- a/drivers/i2c/busses/i2c-ocores.c
> > +++ b/drivers/i2c/busses/i2c-ocores.c
> > @@ -686,17 +686,21 @@ static int ocores_i2c_probe(struct
> platform_device *pdev)
>
> > init_waitqueue_head(>wait);
>
> > +/*
> > + * Set OCORES_FLAG_BROKEN_IRQ to enable workaround for
> > + * FU540-C000 SoC in polling mode.
> > + * Since the SoC does have interrupt its dt has the interrupt
> > + * defined but it should be bypassed in driver as this SoC has
>
> NIT: Looks like there some commas missing and the wording sounds a bit
> odd to me. What about E.G.:
>
Sorry for the confusing wordings here.
> /*
> * Since the SoC does have an interrupt, its DT has an interrupt
> * property - But this should be bypassed as the IRQ logic in this
> * SoC is broken.
> */
>
I will replace mine with your suggested one.
> > + * a broken IRQ, hence update the master_xfer to use polling
> > + * transfers.
> > + */
> > +if (of_device_is_compatible(pdev->dev.of_node,
> > +"sifive,fu540-c000-i2c"))
> > +i2c->flags |= OCORES_FLAG_BROKEN_IRQ;
> > +
> > irq = platform_get_irq(pdev, 0);
> > -if (irq == -ENXIO) {
> > +if (i2c->flags & OCORES_FLAG_BROKEN_IRQ || irq == -ENXIO) {
>
>
> Alternatively you can move it after the irq = platform_get_irq(pdev, 0)
> line and just clear irq, E.G.:
>
> irq = platform_get_irq(pdev, 0);
>
> if (of_device_is_compatible(..)) {
>i2c->flags |= OCORES_FLAG_BROKEN_IRQ;
>irq = -ENXIO;
> }
>
Yeah..
This is a better alternative implementation.
I will push v4 with this.
Thanks & BR,
Sagar
> if (irq == -ENXIO) {
> ..
>
> --
> Bye, Peter Korsgaard
RE: [PATCH v2 1/1] i2c: ocores: fix polling mode workaround on FU540-C000 SoC
> -Original Message- > From: Andreas Schwab > Sent: Friday, October 9, 2020 11:55 PM > To: Sagar Kadam > Cc: linux-kernel@vger.kernel.org; linux-ri...@lists.infradead.org; linux- > i...@vger.kernel.org; pe...@korsgaard.com; and...@lunn.ch; Paul > Walmsley ( Sifive) ; pal...@dabbelt.com; > a...@eecs.berkeley.edu > Subject: Re: [PATCH v2 1/1] i2c: ocores: fix polling mode workaround on > FU540-C000 SoC > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > On Okt 09 2020, Sagar Shrikant Kadam wrote: > > > diff --git a/drivers/i2c/busses/i2c-ocores.c > > b/drivers/i2c/busses/i2c-ocores.c index f5fc75b..9b3d1ab 100644 > > --- a/drivers/i2c/busses/i2c-ocores.c > > +++ b/drivers/i2c/busses/i2c-ocores.c > > @@ -686,17 +686,21 @@ static int ocores_i2c_probe(struct > > platform_device *pdev) > > > > init_waitqueue_head(>wait); > > > > + /* > > + * Set OCORES_FLAG_BROKEN_IRQ to enable workaround for > > + * FU540-C000 SoC in polling mode. > > + * Since the SoC does have interrupt it's dt has the interrupt > > Typo: its > Thanks Andreas, I will submit v3 with the change. BR, Sagar > Andreas. > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA > AEC1 "And now for something completely different."
RE: [PATCH 1/1] i2c: ocores: fix polling mode workaround on FU540-C000 SoC
Hello Peter,
> -Original Message-
> From: Peter Korsgaard On Behalf Of Peter Korsgaard
> Sent: Wednesday, October 7, 2020 5:10 PM
> To: Sagar Kadam
> Cc: linux-kernel@vger.kernel.org; linux-ri...@lists.infradead.org; linux-
> i...@vger.kernel.org; and...@lunn.ch; Paul Walmsley ( Sifive)
> ; pal...@dabbelt.com;
> a...@eecs.berkeley.edu
> Subject: Re: [PATCH 1/1] i2c: ocores: fix polling mode workaround on FU540-
> C000 SoC
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> >>>>> "Sagar" == Sagar Shrikant Kadam writes:
>
> > The FU540-C000 has a broken IRQ and support was added earlier
> > so that it will operate in polling mode, but seems to work only
> > in case interrupts property is missing from the i2c0 dt-node.
> > This should not be the case and the driver should handle polling
> > mode with the interrupt property present in i2c0 node of the
> > device tree.
> > So check if it's the FU540-C000 soc and enable polling mode master
> > xfers, as the IRQ for this chip is broken.
>
> > Fixes commit c45d4ba86731 ("i2c: ocores: add polling mode workaround
> > for Sifive FU540-C000 SoC")
>
> > Signed-off-by: Sagar Shrikant Kadam
> > ---
> > drivers/i2c/busses/i2c-ocores.c | 22 +-
> > 1 file changed, 13 insertions(+), 9 deletions(-)
>
> > diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-
> ocores.c
> > index f5fc75b..4405244 100644
> > --- a/drivers/i2c/busses/i2c-ocores.c
> > +++ b/drivers/i2c/busses/i2c-ocores.c
> > @@ -686,17 +686,21 @@ static int ocores_i2c_probe(struct
> platform_device *pdev)
>
> > init_waitqueue_head(>wait);
>
> > +/*
> > + * Set OCORES_FLAG_BROKEN_IRQ to enable workaround for
> > + * FU540-C000 SoC in polling mode.
> > + * Since the SoC does have interrupt it's dt has the interrupt
> > + * defined but it should be bypassed in driver as this SoC has
> > + * a broken IRQ, hence update the master_xfer to use polling
> > + * transfers.
> > + */
> > +match = of_match_node(ocores_i2c_match, pdev->dev.of_node);
> > +if (match && (long)match->data == TYPE_SIFIVE_REV0)
> > +i2c->flags |= OCORES_FLAG_BROKEN_IRQ;
> > +
> > irq = platform_get_irq(pdev, 0);
> > -if (irq == -ENXIO) {
> > +if (i2c->flags == OCORES_FLAG_BROKEN_IRQ || irq == -ENXIO) {
>
> NIT: flags is a bitmask, so i2c->flags & OCORES_FLAG_BROKEN_IRQ would be
> better, even if there currently doesn't exist any other flags.
>
Thanks for your suggestions. I will apply the bitmask, this will be better.
> TYPE_SIFIVE_REV0 is also set for two compatibles:
>
> {
> .compatible = "sifive,fu540-c000-i2c",
> .data = (void *)TYPE_SIFIVE_REV0,
> },
> {
> .compatible = "sifive,i2c0",
> .data = (void *)TYPE_SIFIVE_REV0,
> },
>
> Are both affected by this issue? if not, we will need to extend the code
> to handle them differently.
>
No, this issue is present in FU540-C000 SoC i.e SoC- specific, and so I can
check
for the soc-compatible string as follows:
- match = of_match_node(ocores_i2c_match, pdev->dev.of_node);
- if (match && (long)match->data == TYPE_SIFIVE_REV0)
+ if (of_device_is_compatible(pdev->dev.of_node,
+ "sifive,fu540-c000-i2c"))
Please let me know if this is okay.
Thanks & BR,
Sagar
> Other than that, it looks OK to me.
>
> --
> Bye, Peter Korsgaard
RE: [PATCH v2 1/3] dt-bindings: fu540: prci: convert PRCI bindings to json-schema
> -Original Message- > From: Rob Herring > Sent: Wednesday, October 7, 2020 12:13 AM > To: Sagar Kadam > Cc: a...@eecs.berkeley.edu; linux-ri...@lists.infradead.org; > t...@linutronix.de; linux-...@vger.kernel.org; pal...@dabbelt.com; > ja...@lakedaemon.net; Yash Shah ; > thierry.red...@gmail.com; lee.jo...@linaro.org; u.kleine- > koe...@pengutronix.de; robh...@kernel.org; Paul Walmsley ( Sifive) > ; linux-kernel@vger.kernel.org; linux- > c...@vger.kernel.org; m...@kernel.org; mturque...@baylibre.com; > devicet...@vger.kernel.org; sb...@kernel.org > Subject: Re: [PATCH v2 1/3] dt-bindings: fu540: prci: convert PRCI bindings to > json-schema > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > On Tue, 29 Sep 2020 21:02:09 +0530, Sagar Kadam wrote: > > FU540-C000 SoC from SiFive has a PRCI block, here we convert the > > device tree bindings from txt to YAML. > > > > Signed-off-by: Sagar Kadam > > --- > > .../bindings/clock/sifive/fu540-prci.txt | 46 - > > .../bindings/clock/sifive/fu540-prci.yaml | 60 > ++ > > 2 files changed, 60 insertions(+), 46 deletions(-) delete mode > > 100644 Documentation/devicetree/bindings/clock/sifive/fu540-prci.txt > > create mode 100644 > > Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml > > > > Applied, thanks! Thanks Rob for applying these patches. BR, Sagar
[PATCH v2 2/3] dt-bindings: riscv: convert plic bindings to json-schema
Convert device tree bindings for SiFive's PLIC to YAML format
Signed-off-by: Sagar Kadam
---
.../interrupt-controller/sifive,plic-1.0.0.txt | 58 -
.../interrupt-controller/sifive,plic-1.0.0.yaml| 97 ++
2 files changed, 97 insertions(+), 58 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.txt
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.txt
b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.txt
deleted file mode 100644
index 6adf7a6..000
---
a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-SiFive Platform-Level Interrupt Controller (PLIC)
--
-
-SiFive SOCs include an implementation of the Platform-Level Interrupt
Controller
-(PLIC) high-level specification in the RISC-V Privileged Architecture
-specification. The PLIC connects all external interrupts in the system to all
-hart contexts in the system, via the external interrupt source in each hart.
-
-A hart context is a privilege mode in a hardware execution thread. For
example,
-in an 4 core system with 2-way SMT, you have 8 harts and probably at least two
-privilege modes per hart; machine mode and supervisor mode.
-
-Each interrupt can be enabled on per-context basis. Any context can claim
-a pending enabled interrupt and then release it once it has been handled.
-
-Each interrupt has a configurable priority. Higher priority interrupts are
-serviced first. Each context can specify a priority threshold. Interrupts
-with priority below this threshold will not cause the PLIC to raise its
-interrupt line leading to the context.
-
-While the PLIC supports both edge-triggered and level-triggered interrupts,
-interrupt handlers are oblivious to this distinction and therefore it is not
-specified in the PLIC device-tree binding.
-
-While the RISC-V ISA doesn't specify a memory layout for the PLIC, the
-"sifive,plic-1.0.0" device is a concrete implementation of the PLIC that
-contains a specific memory layout, which is documented in chapter 8 of the
-SiFive U5 Coreplex Series Manual
<https://static.dev.sifive.com/U54-MC-RVCoreIP.pdf>.
-
-Required properties:
-- compatible : "sifive,plic-1.0.0" and a string identifying the actual
- detailed implementation in case that specific bugs need to be worked around.
-- #address-cells : should be <0> or more.
-- #interrupt-cells : should be <1> or more.
-- interrupt-controller : Identifies the node as an interrupt controller.
-- reg : Should contain 1 register range (address and length).
-- interrupts-extended : Specifies which contexts are connected to the PLIC,
- with "-1" specifying that a context is not present. Each node pointed
- to should be a riscv,cpu-intc node, which has a riscv node as parent.
-- riscv,ndev: Specifies how many external interrupts are supported by
- this controller.
-
-Example:
-
- plic: interrupt-controller@c00 {
- #address-cells = <0>;
- #interrupt-cells = <1>;
- compatible = "sifive,plic-1.0.0", "sifive,fu540-c000-plic";
- interrupt-controller;
- interrupts-extended = <
-11
-11 9
-11 9
-11 9
-11 9>;
- reg = <0xc00 0x400>;
- riscv,ndev = <10>;
- };
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
new file mode 100644
index 000..b9a61c9
--- /dev/null
+++
b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
@@ -0,0 +1,97 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+# Copyright (C) 2020 SiFive, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/sifive,plic-1.0.0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SiFive Platform-Level Interrupt Controller (PLIC)
+
+description:
+ SiFive SOCs include an implementation of the Platform-Level Interrupt
Controller
+ (PLIC) high-level specification in the RISC-V Privileged Architecture
+ specification. The PLIC connects all external interrupts in the system to all
+ hart contexts in the system, via the external interrupt source in each hart.
+
+ A hart context is a privilege mode in a hardware execution thread. For
example,
+ in an 4 core system with 2-way SMT, you have 8 harts and probably at least
two
+ privilege modes per hart; machine mode and supervisor mode.
+
+ Each interrupt can be enabled o
[PATCH v2 0/3] convert sifive's prci, plic and pwm bindings to yaml
The prci, plic and pwm controller bindings are in txt format. Here,
we convert them to yaml format.
These patches are tested on commit a1b8638ba132 ("Linux 5.9-rc7")
I have added the log of dt_binding_check for these IP block's
on 5.9-rc7 kernel here [1] in case someone want's to refer it.
[1] https://paste.ubuntu.com/p/7BRfJXckkV/
Additionally the default log of dt_binding_check on linux-5.9-rc7 without
these patches can be found here [2].
[2] https://paste.ubuntu.com/p/ys5XNn38VP/
Patch History:
v2:
-Incorporated suggestions as per discussion from here [3]
[3] https://patchwork.kernel.org/cover/11769499/
-Rebased patches to 5.9-rc7
V1: Base version.
Sagar Kadam (3):
dt-bindings: fu540: prci: convert PRCI bindings to json-schema
dt-bindings: riscv: convert plic bindings to json-schema
dt-bindings: riscv: convert pwm bindings to json-schema
.../bindings/clock/sifive/fu540-prci.txt | 46 --
.../bindings/clock/sifive/fu540-prci.yaml | 60 +
.../interrupt-controller/sifive,plic-1.0.0.txt | 58 -
.../interrupt-controller/sifive,plic-1.0.0.yaml| 97 ++
.../devicetree/bindings/pwm/pwm-sifive.txt | 33
.../devicetree/bindings/pwm/pwm-sifive.yaml| 69 +++
6 files changed, 226 insertions(+), 137 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/clock/sifive/fu540-prci.txt
create mode 100644
Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml
delete mode 100644
Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.txt
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
delete mode 100644 Documentation/devicetree/bindings/pwm/pwm-sifive.txt
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sifive.yaml
--
2.7.4
[PATCH v2 1/3] dt-bindings: fu540: prci: convert PRCI bindings to json-schema
FU540-C000 SoC from SiFive has a PRCI block, here we convert
the device tree bindings from txt to YAML.
Signed-off-by: Sagar Kadam
---
.../bindings/clock/sifive/fu540-prci.txt | 46 -
.../bindings/clock/sifive/fu540-prci.yaml | 60 ++
2 files changed, 60 insertions(+), 46 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/clock/sifive/fu540-prci.txt
create mode 100644
Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml
diff --git a/Documentation/devicetree/bindings/clock/sifive/fu540-prci.txt
b/Documentation/devicetree/bindings/clock/sifive/fu540-prci.txt
deleted file mode 100644
index 349808f..000
--- a/Documentation/devicetree/bindings/clock/sifive/fu540-prci.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-SiFive FU540 PRCI bindings
-
-On the FU540 family of SoCs, most system-wide clock and reset integration
-is via the PRCI IP block.
-
-Required properties:
-- compatible: Should be "sifive,-prci". Only one value is
- supported: "sifive,fu540-c000-prci"
-- reg: Should describe the PRCI's register target physical address region
-- clocks: Should point to the hfclk device tree node and the rtcclk
- device tree node. The RTC clock here is not a time-of-day clock,
- but is instead a high-stability clock source for system timers
- and cycle counters.
-- #clock-cells: Should be <1>
-
-The clock consumer should specify the desired clock via the clock ID
-macros defined in include/dt-bindings/clock/sifive-fu540-prci.h.
-These macros begin with PRCI_CLK_.
-
-The hfclk and rtcclk nodes are required, and represent physical
-crystals or resonators located on the PCB. These nodes should be present
-underneath /, rather than /soc.
-
-Examples:
-
-/* under /, in PCB-specific DT data */
-hfclk: hfclk {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <>;
- clock-output-names = "hfclk";
-};
-rtcclk: rtcclk {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <100>;
- clock-output-names = "rtcclk";
-};
-
-/* under /soc, in SoC-specific DT data */
-prci: clock-controller@1000 {
- compatible = "sifive,fu540-c000-prci";
- reg = <0x0 0x1000 0x0 0x1000>;
- clocks = <>, <>;
- #clock-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml
b/Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml
new file mode 100644
index 000..c3be1b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2020 SiFive, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/sifive/fu540-prci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SiFive FU540 Power Reset Clock Interrupt Controller (PRCI)
+
+maintainers:
+ - Sagar Kadam
+ - Paul Walmsley
+
+description:
+ On the FU540 family of SoCs, most system-wide clock and reset integration
+ is via the PRCI IP block.
+ The clock consumer should specify the desired clock via the clock ID
+ macros defined in include/dt-bindings/clock/sifive-fu540-prci.h.
+ These macros begin with PRCI_CLK_.
+
+ The hfclk and rtcclk nodes are required, and represent physical
+ crystals or resonators located on the PCB. These nodes should be present
+ underneath /, rather than /soc.
+
+properties:
+ compatible:
+const: sifive,fu540-c000-prci
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: high frequency clock.
+ - description: RTL clock.
+
+ clock-names:
+items:
+ - const: hfclk
+ - const: rtcclk
+
+ "#clock-cells":
+const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+prci: clock-controller@1000 {
+ compatible = "sifive,fu540-c000-prci";
+ reg = <0x1000 0x1000>;
+ clocks = <>, <>;
+ #clock-cells = <1>;
+};
--
2.7.4
[PATCH v2 3/3] dt-bindings: riscv: convert pwm bindings to json-schema
Convert device tree bindings for SiFive's PWM controller to YAML
format.
Signed-off-by: Sagar Kadam
---
.../devicetree/bindings/pwm/pwm-sifive.txt | 33 ---
.../devicetree/bindings/pwm/pwm-sifive.yaml| 69 ++
2 files changed, 69 insertions(+), 33 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/pwm/pwm-sifive.txt
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sifive.yaml
diff --git a/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
b/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
deleted file mode 100644
index 3d1dd7b0..000
--- a/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-SiFive PWM controller
-
-Unlike most other PWM controllers, the SiFive PWM controller currently only
-supports one period for all channels in the PWM. All PWMs need to run at
-the same period. The period also has significant restrictions on the values
-it can achieve, which the driver rounds to the nearest achievable period.
-PWM RTL that corresponds to the IP block version numbers can be found
-here:
-
-https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/pwm
-
-Required properties:
-- compatible: Should be "sifive,-pwm" and "sifive,pwm".
- Supported compatible strings are: "sifive,fu540-c000-pwm" for the SiFive
- PWM v0 as integrated onto the SiFive FU540 chip, and "sifive,pwm0" for the
- SiFive PWM v0 IP block with no chip integration tweaks.
- Please refer to sifive-blocks-ip-versioning.txt for details.
-- reg: physical base address and length of the controller's registers
-- clocks: Should contain a clock identifier for the PWM's parent clock.
-- #pwm-cells: Should be 3. See pwm.yaml in this directory
- for a description of the cell format.
-- interrupts: one interrupt per PWM channel
-
-Examples:
-
-pwm: pwm@1002 {
- compatible = "sifive,fu540-c000-pwm", "sifive,pwm0";
- reg = <0x0 0x1002 0x0 0x1000>;
- clocks = <>;
- interrupt-parent = <>;
- interrupts = <42 43 44 45>;
- #pwm-cells = <3>;
-};
diff --git a/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml
b/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml
new file mode 100644
index 000..5ac2527
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2020 SiFive, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/pwm-sifive.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SiFive PWM controller
+
+maintainers:
+ - Yash Shah
+ - Sagar Kadam
+ - Paul Walmsley
+
+description:
+ Unlike most other PWM controllers, the SiFive PWM controller currently
+ only supports one period for all channels in the PWM. All PWMs need to
+ run at the same period. The period also has significant restrictions on
+ the values it can achieve, which the driver rounds to the nearest
+ achievable period. PWM RTL that corresponds to the IP block version
+ numbers can be found here -
+
+
https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/pwm
+
+properties:
+ compatible:
+items:
+ - const: sifive,fu540-c000-pwm
+ - const: sifive,pwm0
+description:
+ Should be "sifive,-pwm" and "sifive,pwm". Supported
+ compatible strings are "sifive,fu540-c000-pwm" for the SiFive PWM v0
+ as integrated onto the SiFive FU540 chip, and "sifive,pwm0" for the
+ SiFive PWM v0 IP block with no chip integration tweaks.
+ Please refer to sifive-blocks-ip-versioning.txt for details.
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ "#pwm-cells":
+const: 3
+
+ interrupts:
+maxItems: 4
+description:
+ Each PWM instance in FU540-C000 has 4 comparators. One interrupt per
comparator.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#pwm-cells"
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+pwm: pwm@1002 {
+ compatible = "sifive,fu540-c000-pwm", "sifive,pwm0";
+ reg = <0x1002 0x1000>;
+ clocks = <>;
+ interrupt-parent = <>;
+ interrupts = <42>, <43>, <44>, <45>;
+ #pwm-cells = <3>;
+};
--
2.7.4
[PATCH v4 0/1] convert l2 cache dt bindings to YAML format
This patch is created and tested on top of mainline linux
commit a1b8638ba132 ("Linux 5.9-rc7")
Reference log of "make dt_binding_check" is available here[1].
Just in case required, reference log of "make dt_binding_check"
without this patch is available here[2].
[1] https://paste.ubuntu.com/p/8TmWDZJs3g/
[2] https://paste.ubuntu.com/p/ys5XNn38VP/
Change History:
V4:
-Incorporated changes as suggested by Rob Herring here[3]
[3] https://lkml.org/lkml/2020/9/22/929
-Rebased patch on 5.9-rc7
V3:
-Incorporated changes as suggested by Rob Herring here[3]
[3] https://lkml.org/lkml/2020/9/15/670
-Rebased patch on 5.9-rc5
V2:
-Fixed bot failure mentioned by Rob Herring
-Updated dt-schema and kernel as suggested
V1:
Base version
Sagar Kadam (1):
dt-bindings: riscv: sifive-l2-cache: convert bindings to json-schema
.../devicetree/bindings/riscv/sifive-l2-cache.txt | 51 ---
.../devicetree/bindings/riscv/sifive-l2-cache.yaml | 98 ++
2 files changed, 98 insertions(+), 51 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
create mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
--
2.7.4
[PATCH v4 1/1] dt-bindings: riscv: sifive-l2-cache: convert bindings to json-schema
Convert the device tree bindings for the SiFive's FU540-C000 SoC's L2 Cache
controller to YAML format.
Signed-off-by: Sagar Kadam
---
.../devicetree/bindings/riscv/sifive-l2-cache.txt | 51 ---
.../devicetree/bindings/riscv/sifive-l2-cache.yaml | 98 ++
2 files changed, 98 insertions(+), 51 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
create mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
deleted file mode 100644
index 73d8f19..000
--- a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
+++ /dev/null
@@ -1,51 +0,0 @@
-SiFive L2 Cache Controller
---
-The SiFive Level 2 Cache Controller is used to provide access to fast copies
-of memory for masters in a Core Complex. The Level 2 Cache Controller also
-acts as directory-based coherency manager.
-All the properties in ePAPR/DeviceTree specification applies for this platform
-
-Required Properties:
-
-- compatible: Should be "sifive,fu540-c000-ccache" and "cache"
-
-- cache-block-size: Specifies the block size in bytes of the cache.
- Should be 64
-
-- cache-level: Should be set to 2 for a level 2 cache
-
-- cache-sets: Specifies the number of associativity sets of the cache.
- Should be 1024
-
-- cache-size: Specifies the size in bytes of the cache. Should be 2097152
-
-- cache-unified: Specifies the cache is a unified cache
-
-- interrupts: Must contain 3 entries (DirError, DataError and DataFail signals)
-
-- reg: Physical base address and size of L2 cache controller registers map
-
-Optional Properties:
-
-- next-level-cache: phandle to the next level cache if present.
-
-- memory-region: reference to the reserved-memory for the L2 Loosely Integrated
- Memory region. The reserved memory node should be defined as per the bindings
- in reserved-memory.txt
-
-
-Example:
-
- cache-controller@201 {
- compatible = "sifive,fu540-c000-ccache", "cache";
- cache-block-size = <64>;
- cache-level = <2>;
- cache-sets = <1024>;
- cache-size = <2097152>;
- cache-unified;
- interrupt-parent = <>;
- interrupts = <1 2 3>;
- reg = <0x0 0x201 0x0 0x1000>;
- next-level-cache = < >;
- memory-region = <_lim>;
- };
diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
new file mode 100644
index 000..3f4a193
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (C) 2020 SiFive, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/sifive-l2-cache.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SiFive L2 Cache Controller
+
+maintainers:
+ - Sagar Kadam
+ - Yash Shah
+ - Paul Walmsley
+
+description:
+ The SiFive Level 2 Cache Controller is used to provide access to fast copies
+ of memory for masters in a Core Complex. The Level 2 Cache Controller also
+ acts as directory-based coherency manager.
+ All the properties in ePAPR/DeviceTree specification applies for this
platform.
+
+allOf:
+ - $ref: /schemas/cache-controller.yaml#
+
+select:
+ properties:
+compatible:
+ items:
+ - enum:
+ - sifive,fu540-c000-ccache
+
+ required:
+- compatible
+
+properties:
+ compatible:
+items:
+ - const: sifive,fu540-c000-ccache
+ - const: cache
+
+ cache-block-size:
+const: 64
+
+ cache-level:
+const: 2
+
+ cache-sets:
+const: 1024
+
+ cache-size:
+const: 2097152
+
+ cache-unified: true
+
+ interrupts:
+description: |
+ Must contain entries for DirError, DataError and DataFail signals.
+minItems: 3
+maxItems: 3
+
+ reg:
+maxItems: 1
+
+ next-level-cache: true
+
+ memory-region:
+description: |
+ The reference to the reserved-memory for the L2 Loosely Integrated
Memory region.
+ The reserved memory node should be defined as per the bindings in
reserved-memory.txt.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - cache-block-size
+ - cache-level
+ - cache-sets
+ - cache-size
+ - cache-unified
+ - interrupts
+ - reg
+
+examples:
+ - |
+cache-controller@201 {
+compatible = "sifive,fu540-c000-ccache", "cache";
+cache-block-size = <64>;
+cache-level = <2>;
+cache-sets = <1024>;
+cache-size = <2097152>;
+cache-unified;
+reg = <0x201 0x1000
RE: [PATCH v1 3/3] dt-bindings: riscv: convert pwm bindings to json-schema
Hello Rob,
> -Original Message-
> From: Rob Herring
> Sent: Wednesday, September 23, 2020 2:07 AM
> To: Sagar Kadam
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> ri...@lists.infradead.org; devicet...@vger.kernel.org; linux-
> c...@vger.kernel.org; mturque...@baylibre.com; sb...@kernel.org; Paul
> Walmsley ( Sifive) ; pal...@dabbelt.com;
> t...@linutronix.de; ja...@lakedaemon.net; m...@kernel.org;
> thierry.red...@gmail.com; u.kleine-koe...@pengutronix.de;
> lee.jo...@linaro.org; a...@eecs.berkeley.edu; Yash Shah
>
> Subject: Re: [PATCH v1 3/3] dt-bindings: riscv: convert pwm bindings to json-
> schema
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> On Thu, Sep 10, 2020 at 04:14:04PM +0530, Sagar Kadam wrote:
> > Convert device tree bindings for SiFive's PWM controller to YAML
> > format.
> >
> > Signed-off-by: Sagar Kadam
> > ---
> > .../devicetree/bindings/pwm/pwm-sifive.txt | 33 --
> > .../devicetree/bindings/pwm/pwm-sifive.yaml| 72
> ++
> > 2 files changed, 72 insertions(+), 33 deletions(-) delete mode
> > 100644 Documentation/devicetree/bindings/pwm/pwm-sifive.txt
> > create mode 100644
> > Documentation/devicetree/bindings/pwm/pwm-sifive.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
> > b/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
> > deleted file mode 100644
> > index 3d1dd7b0..000
> > --- a/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
> > +++ /dev/null
> > @@ -1,33 +0,0 @@
> > -SiFive PWM controller
> > -
> > -Unlike most other PWM controllers, the SiFive PWM controller
> > currently only -supports one period for all channels in the PWM. All
> > PWMs need to run at -the same period. The period also has significant
> > restrictions on the values -it can achieve, which the driver rounds to the
> nearest achievable period.
> > -PWM RTL that corresponds to the IP block version numbers can be found
> > -here:
> > -
> > -https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/de
> > vices/pwm
> > -
> > -Required properties:
> > -- compatible: Should be "sifive,-pwm" and "sifive,pwm".
> > - Supported compatible strings are: "sifive,fu540-c000-pwm" for the
> > SiFive
> > - PWM v0 as integrated onto the SiFive FU540 chip, and "sifive,pwm0"
> > for the
> > - SiFive PWM v0 IP block with no chip integration tweaks.
> > - Please refer to sifive-blocks-ip-versioning.txt for details.
> > -- reg: physical base address and length of the controller's registers
> > -- clocks: Should contain a clock identifier for the PWM's parent clock.
> > -- #pwm-cells: Should be 3. See pwm.yaml in this directory
> > - for a description of the cell format.
> > -- interrupts: one interrupt per PWM channel
> > -
> > -Examples:
> > -
> > -pwm: pwm@1002 {
> > - compatible = "sifive,fu540-c000-pwm", "sifive,pwm0";
> > - reg = <0x0 0x1002 0x0 0x1000>;
> > - clocks = <>;
> > - interrupt-parent = <>;
> > - interrupts = <42 43 44 45>;
> > - #pwm-cells = <3>;
> > -};
> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml
> > b/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml
> > new file mode 100644
> > index 000..415d053
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml
> > @@ -0,0 +1,72 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) # Copyright
> > +(C) 2020 SiFive, Inc.
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/pwm/pwm-sifive.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: SiFive PWM controller
> > +
> > +maintainers:
> > + - Yash Shah
> > + - Sagar Kadam
> > + - Paul Walmsley
> > +
> > +description:
> > + Unlike most other PWM controllers, the SiFive PWM controller
> > +currently
> > + only supports one period for all channels in the PWM. All PWMs need
> > +to
> > + run at the same period. The period also has significant
> > +restrictions on
> > + the values it can achieve, which the driver rounds to the nearest
> > + achievable period. PWM RTL that corresponds to the IP block version
> > + numbers can be found here -
> > +
> > +
> > + https:/
RE: [PATCH v1 2/3] dt-bindings: riscv: convert plic bindings to json-schema
Hello Rob,
> -Original Message-
> From: Rob Herring
> Sent: Wednesday, September 23, 2020 2:04 AM
> To: Sagar Kadam
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> ri...@lists.infradead.org; devicet...@vger.kernel.org; linux-
> c...@vger.kernel.org; mturque...@baylibre.com; sb...@kernel.org; Paul
> Walmsley ( Sifive) ; pal...@dabbelt.com;
> t...@linutronix.de; ja...@lakedaemon.net; m...@kernel.org;
> thierry.red...@gmail.com; u.kleine-koe...@pengutronix.de;
> lee.jo...@linaro.org; a...@eecs.berkeley.edu; Yash Shah
>
> Subject: Re: [PATCH v1 2/3] dt-bindings: riscv: convert plic bindings to json-
> schema
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> On Thu, Sep 10, 2020 at 04:14:03PM +0530, Sagar Kadam wrote:
> > Convert device tree bindings for SiFive's PLIC to YAML format
> >
> > Signed-off-by: Sagar Kadam
> > ---
> > .../interrupt-controller/sifive,plic-1.0.0.txt | 58 ---
> > .../interrupt-controller/sifive,plic-1.0.0.yaml| 107
> +
> > 2 files changed, 107 insertions(+), 58 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/interrupt-
> controller/sifive,plic-1.0.0.txt
> > create mode 100644 Documentation/devicetree/bindings/interrupt-
> controller/sifive,plic-1.0.0.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/interrupt-
> controller/sifive,plic-1.0.0.txt
> b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-
> 1.0.0.txt
> > deleted file mode 100644
> > index 6adf7a6..000
> > --- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-
> 1.0.0.txt
> > +++ /dev/null
> > @@ -1,58 +0,0 @@
> > -SiFive Platform-Level Interrupt Controller (PLIC)
> > --
> > -
> > -SiFive SOCs include an implementation of the Platform-Level Interrupt
> Controller
> > -(PLIC) high-level specification in the RISC-V Privileged Architecture
> > -specification. The PLIC connects all external interrupts in the system to
> > all
> > -hart contexts in the system, via the external interrupt source in each
> > hart.
> > -
> > -A hart context is a privilege mode in a hardware execution thread. For
> example,
> > -in an 4 core system with 2-way SMT, you have 8 harts and probably at
> least two
> > -privilege modes per hart; machine mode and supervisor mode.
> > -
> > -Each interrupt can be enabled on per-context basis. Any context can claim
> > -a pending enabled interrupt and then release it once it has been handled.
> > -
> > -Each interrupt has a configurable priority. Higher priority interrupts are
> > -serviced first. Each context can specify a priority threshold. Interrupts
> > -with priority below this threshold will not cause the PLIC to raise its
> > -interrupt line leading to the context.
> > -
> > -While the PLIC supports both edge-triggered and level-triggered interrupts,
> > -interrupt handlers are oblivious to this distinction and therefore it is
> > not
> > -specified in the PLIC device-tree binding.
> > -
> > -While the RISC-V ISA doesn't specify a memory layout for the PLIC, the
> > -"sifive,plic-1.0.0" device is a concrete implementation of the PLIC that
> > -contains a specific memory layout, which is documented in chapter 8 of
> the
> > -SiFive U5 Coreplex Series Manual <https://static.dev.sifive.com/U54-MC-
> RVCoreIP.pdf>.
> > -
> > -Required properties:
> > -- compatible : "sifive,plic-1.0.0" and a string identifying the actual
> > - detailed implementation in case that specific bugs need to be worked
> around.
> > -- #address-cells : should be <0> or more.
> > -- #interrupt-cells : should be <1> or more.
> > -- interrupt-controller : Identifies the node as an interrupt controller.
> > -- reg : Should contain 1 register range (address and length).
> > -- interrupts-extended : Specifies which contexts are connected to the PLIC,
> > - with "-1" specifying that a context is not present. Each node pointed
> > - to should be a riscv,cpu-intc node, which has a riscv node as parent.
> > -- riscv,ndev: Specifies how many external interrupts are supported by
> > - this controller.
> > -
> > -Example:
> > -
> > - plic: interrupt-controller@c00 {
> > - #address-cells = <0>;
> > - #interrupt-cells = <1>;
> > - compatible = "sifive,plic-1.0.0", &
RE: [RESEND PATCH v2 1/1] dt-bindings: riscv: sifive-l2-cache: convert bindings to json-schema
Hello Rob,
> -Original Message-
> From: Rob Herring
> Sent: Wednesday, September 23, 2020 12:57 AM
> To: Sagar Kadam
> Cc: linux-kernel@vger.kernel.org; linux-ri...@lists.infradead.org;
> devicet...@vger.kernel.org; Paul Walmsley ( Sifive)
> ; pal...@dabbelt.com;
> a...@eecs.berkeley.edu; Yash Shah
> Subject: Re: [RESEND PATCH v2 1/1] dt-bindings: riscv: sifive-l2-cache:
> convert
> bindings to json-schema
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> On Tue, Sep 15, 2020 at 9:17 AM Sagar Kadam
> wrote:
> >
> > Hello Rob,
> >
> > > -Original Message-
> > > From: Rob Herring
> > > Sent: Monday, September 14, 2020 11:30 PM
> > > To: Sagar Kadam
> > > Cc: linux-kernel@vger.kernel.org; linux-ri...@lists.infradead.org;
> > > devicet...@vger.kernel.org; Paul Walmsley ( Sifive)
> > > ; pal...@dabbelt.com;
> > > a...@eecs.berkeley.edu; Yash Shah
> > > Subject: Re: [RESEND PATCH v2 1/1] dt-bindings: riscv: sifive-l2-cache:
> > > convert bindings to json-schema
> > >
> > > [External Email] Do not click links or attachments unless you recognize
> > > the
> > > sender and know the content is safe
> > >
> > > On Fri, Aug 28, 2020 at 10:25:43PM +0530, Sagar Kadam wrote:
> > > > Convert the device tree bindings for the SiFive's FU540-C000 SoC's L2
> > > Cache
> > > > controller to YAML format.
> > > >
> > > > Signed-off-by: Sagar Kadam
> > > > ---
> > > > .../devicetree/bindings/riscv/sifive-l2-cache.txt | 51
> > > > .../devicetree/bindings/riscv/sifive-l2-cache.yaml | 92
> > > ++
> > > > 2 files changed, 92 insertions(+), 51 deletions(-)
> > > > delete mode 100644 Documentation/devicetree/bindings/riscv/sifive-
> l2-
> > > cache.txt
> > > > create mode 100644 Documentation/devicetree/bindings/riscv/sifive-
> l2-
> > > cache.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
> > > b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
> > > > deleted file mode 100644
> > > > index 73d8f19..000
> > > > --- a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
> > > > +++ /dev/null
> > > > @@ -1,51 +0,0 @@
> > > > -SiFive L2 Cache Controller
> > > > ---
> > > > -The SiFive Level 2 Cache Controller is used to provide access to fast
> > > copies
> > > > -of memory for masters in a Core Complex. The Level 2 Cache
> Controller
> > > also
> > > > -acts as directory-based coherency manager.
> > > > -All the properties in ePAPR/DeviceTree specification applies for this
> > > platform
> > > > -
> > > > -Required Properties:
> > > > -
> > > > -- compatible: Should be "sifive,fu540-c000-ccache" and "cache"
> > > > -
> > > > -- cache-block-size: Specifies the block size in bytes of the cache.
> > > > - Should be 64
> > > > -
> > > > -- cache-level: Should be set to 2 for a level 2 cache
> > > > -
> > > > -- cache-sets: Specifies the number of associativity sets of the cache.
> > > > - Should be 1024
> > > > -
> > > > -- cache-size: Specifies the size in bytes of the cache. Should be
> > > > 2097152
> > > > -
> > > > -- cache-unified: Specifies the cache is a unified cache
> > > > -
> > > > -- interrupts: Must contain 3 entries (DirError, DataError and DataFail
> > > signals)
> > > > -
> > > > -- reg: Physical base address and size of L2 cache controller registers
> map
> > > > -
> > > > -Optional Properties:
> > > > -
> > > > -- next-level-cache: phandle to the next level cache if present.
> > > > -
> > > > -- memory-region: reference to the reserved-memory for the L2 Loosely
> > > Integrated
> > > > - Memory region. The reserved memory node should be defined as per
> > > the bindings
> > > > - in reserved-memory.txt
> > > > -
> > > > -
> > > > -Example:
> > > > -
> > > > - cache-controller@201 {
> > > > - compatible
[PATCH v3 0/1] convert l2 cache dt bindings to YAML format
This patch is created and tested on top of mainline linux
commit 856deb866d16 ("Linux 5.9-rc5")
Reference log of "make dt_binding_check" is available here[1].
Just in case required the log of dt_binding_check without this patch
is available here[2]
[1] https://paste.ubuntu.com/p/d2bXwvpFz9/
[2] https://paste.ubuntu.com/p/X2TzBbCs3k/
Change History:
v3:
-Incorporated changes as suggested by Rob Herring here[3]
[3] https://lkml.org/lkml/2020/9/15/670
-Rebased patch on 5.9-rc5
V2:
-Fixed bot failure mentioned by Rob Herring
-Updated dt-schema and kernel as suggested
V1:
Base version
Sagar Kadam (1):
dt-bindings: riscv: sifive-l2-cache: convert bindings to json-schema
.../devicetree/bindings/riscv/sifive-l2-cache.txt | 51
.../devicetree/bindings/riscv/sifive-l2-cache.yaml | 90 ++
2 files changed, 90 insertions(+), 51 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
create mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
--
2.7.4
[PATCH v3 1/1] dt-bindings: riscv: sifive-l2-cache: convert bindings to json-schema
Convert the device tree bindings for the SiFive's FU540-C000 SoC's L2 Cache
controller to YAML format.
Signed-off-by: Sagar Kadam
---
.../devicetree/bindings/riscv/sifive-l2-cache.txt | 51
.../devicetree/bindings/riscv/sifive-l2-cache.yaml | 90 ++
2 files changed, 90 insertions(+), 51 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
create mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
deleted file mode 100644
index 73d8f19..000
--- a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
+++ /dev/null
@@ -1,51 +0,0 @@
-SiFive L2 Cache Controller
---
-The SiFive Level 2 Cache Controller is used to provide access to fast copies
-of memory for masters in a Core Complex. The Level 2 Cache Controller also
-acts as directory-based coherency manager.
-All the properties in ePAPR/DeviceTree specification applies for this platform
-
-Required Properties:
-
-- compatible: Should be "sifive,fu540-c000-ccache" and "cache"
-
-- cache-block-size: Specifies the block size in bytes of the cache.
- Should be 64
-
-- cache-level: Should be set to 2 for a level 2 cache
-
-- cache-sets: Specifies the number of associativity sets of the cache.
- Should be 1024
-
-- cache-size: Specifies the size in bytes of the cache. Should be 2097152
-
-- cache-unified: Specifies the cache is a unified cache
-
-- interrupts: Must contain 3 entries (DirError, DataError and DataFail signals)
-
-- reg: Physical base address and size of L2 cache controller registers map
-
-Optional Properties:
-
-- next-level-cache: phandle to the next level cache if present.
-
-- memory-region: reference to the reserved-memory for the L2 Loosely Integrated
- Memory region. The reserved memory node should be defined as per the bindings
- in reserved-memory.txt
-
-
-Example:
-
- cache-controller@201 {
- compatible = "sifive,fu540-c000-ccache", "cache";
- cache-block-size = <64>;
- cache-level = <2>;
- cache-sets = <1024>;
- cache-size = <2097152>;
- cache-unified;
- interrupt-parent = <>;
- interrupts = <1 2 3>;
- reg = <0x0 0x201 0x0 0x1000>;
- next-level-cache = < >;
- memory-region = <_lim>;
- };
diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
new file mode 100644
index 000..c135dad
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (C) 2020 SiFive, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/sifive-l2-cache.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SiFive L2 Cache Controller
+
+maintainers:
+ - Sagar Kadam
+ - Yash Shah
+ - Paul Walmsley
+
+description:
+ The SiFive Level 2 Cache Controller is used to provide access to fast copies
+ of memory for masters in a Core Complex. The Level 2 Cache Controller also
+ acts as directory-based coherency manager.
+ All the properties in ePAPR/DeviceTree specification applies for this
platform.
+
+allOf:
+ - $ref: /schemas/cache-controller.yaml#
+
+properties:
+ compatible:
+items:
+ - enum:
+- sifive,fu540-c000-ccache
+description: |
+ Should have "sifive,fu540-c000-ccache" and "cache"
+
+ cache-block-size:
+const: 64
+
+ cache-level:
+const: 2
+
+ cache-sets:
+const: 1024
+
+ cache-size:
+const: 2097152
+
+ cache-unified: true
+
+ interrupts:
+description: |
+ Must contain entries for DirError, DataError and DataFail signals.
+minItems: 3
+maxItems: 3
+
+ reg:
+maxItems: 1
+
+ next-level-cache: true
+
+ memory-region:
+description: |
+ The reference to the reserved-memory for the L2 Loosely Integrated
Memory region.
+ The reserved memory node should be defined as per the bindings in
reserved-memory.txt.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - cache-block-size
+ - cache-level
+ - cache-sets
+ - cache-size
+ - cache-unified
+ - interrupts
+ - reg
+
+examples:
+ - |
+cache-controller@201 {
+compatible = "sifive,fu540-c000-ccache";
+cache-block-size = <64>;
+cache-level = <2>;
+cache-sets = <1024>;
+cache-size = <2097152>;
+cache-unified;
+reg = <0x201 0x1000>;
+interrupt-parent = <>;
+interrupts = <1>,
+ <2>,
+ <3>;
+next-level-cache = <>;
+memory-region = <_lim>;
+};
--
2.7.4
RE: [PATCH v1 1/3] dt-bindings: fu540: prci: convert PRCI bindings to json-schema
Hello Stephen,
> -Original Message-
> From: Stephen Boyd
> Sent: Tuesday, September 15, 2020 5:37 AM
> To: Sagar Kadam ;
> devicet...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> ri...@lists.infradead.org
> Cc: mturque...@baylibre.com; robh...@kernel.org; Paul Walmsley ( Sifive)
> ; pal...@dabbelt.com; t...@linutronix.de;
> ja...@lakedaemon.net; m...@kernel.org; thierry.red...@gmail.com;
> u.kleine-koe...@pengutronix.de; lee.jo...@linaro.org;
> a...@eecs.berkeley.edu; Yash Shah ; Sagar
> Kadam
> Subject: Re: [PATCH v1 1/3] dt-bindings: fu540: prci: convert PRCI bindings
> to json-schema
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> Quoting Sagar Kadam (2020-09-10 03:44:02)
> > diff --git
> > a/Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml
> > b/Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml
> > new file mode 100644
> > index 000..49386cd
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml
> > @@ -0,0 +1,75 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) # Copyright
> > +(C) 2020 SiFive, Inc.
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/clock/sifive/fu540-prci.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: SiFive FU540 Power Reset Clock Interrupt Controller (PRCI)
> > +
> > +maintainers:
> > + - Sagar Kadam
> > + - Paul Walmsley
> > +
> > +description:
> > + On the FU540 family of SoCs, most system-wide clock and reset
> > +integration
> > + is via the PRCI IP block.
> > + The clock consumer should specify the desired clock via the clock
> > +ID
> > + macros defined in include/dt-bindings/clock/sifive-fu540-prci.h.
> > + These macros begin with PRCI_CLK_.
> > +
> > + The hfclk and rtcclk nodes are required, and represent physical
> > + crystals or resonators located on the PCB. These nodes should be
> > + present underneath /, rather than /soc.
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - sifive,fu540-c000-prci
> > +description:
> > + Should have "sifive,-prci", only one value is supported
>
> Drop description and have
>
> compatible:
> const: sifive,fu540-c000-prci
>
Thank you for suggestion here, I will remove this.
> > +
> > + reg:
> > +maxItems: 1
> > +description: Describe the PRCI's register target physical address
> > + region
>
> Drop description.
>
Okay.
> > +
> > + clocks:
> > +description:
> > + Should point to the hfclk device tree node and the rtcclk device tree
> node.
>
> s/device tree node//g
Okay, will remove these.
>
> > + The RTC clock here is not a time-of-day clock, but is instead a high-
> stability
> > + clock source for system timers and cycle counters.
>
> Better to have:
>
> clocks:
> items:
> - const: high frequency clock
> - const: RTC clock
>
> Can you add clock-names too? Making it optional is OK.
Okay, I will include these optional properties as
-const: "hfclk"
-const: "rtcclk"
>
> > + "#clock-cells":
> > +const: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - "#clock-cells"
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +//hfclk and rtcclk present under /, in PCB-specific DT data
> > +hfclk: hfclk {
> > + #clock-cells = <0>;
> > + compatible = "fixed-clock";
> > + clock-frequency = <>;
> > + clock-output-names = "hfclk";
> > +};
>
> Add a newline here?
>
Okay.
> > +rtcclk: rtcclk {
> > + #clock-cells = <0>;
> > + compatible = "fixed-clock";
> > + clock-frequency = <100>;
> > + clock-output-names = "rtcclk";
> > +};
>
> These may not be necessary either, just have the clock-controller node
> reference phandles?
>
Okay.
> > +
> > +//under /soc, in SoC-specific DT data
>
> Don't think this comment is necessary.
>
Okay.
Thanks & BR,
Sagar
> > +prci: clock-controller@1000 {
> > + compatible = "sifive,fu540-c000-prci";
> > + reg = <0x1000 0x1000>;
> > + clocks = <>, <>;
> > + #clock-cells = <1>;
> > +};
RE: [RESEND PATCH v2 1/1] dt-bindings: riscv: sifive-l2-cache: convert bindings to json-schema
Hello Rob,
> -Original Message-
> From: Rob Herring
> Sent: Monday, September 14, 2020 11:30 PM
> To: Sagar Kadam
> Cc: linux-kernel@vger.kernel.org; linux-ri...@lists.infradead.org;
> devicet...@vger.kernel.org; Paul Walmsley ( Sifive)
> ; pal...@dabbelt.com;
> a...@eecs.berkeley.edu; Yash Shah
> Subject: Re: [RESEND PATCH v2 1/1] dt-bindings: riscv: sifive-l2-cache:
> convert bindings to json-schema
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> On Fri, Aug 28, 2020 at 10:25:43PM +0530, Sagar Kadam wrote:
> > Convert the device tree bindings for the SiFive's FU540-C000 SoC's L2
> Cache
> > controller to YAML format.
> >
> > Signed-off-by: Sagar Kadam
> > ---
> > .../devicetree/bindings/riscv/sifive-l2-cache.txt | 51
> > .../devicetree/bindings/riscv/sifive-l2-cache.yaml | 92
> ++
> > 2 files changed, 92 insertions(+), 51 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-
> cache.txt
> > create mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-
> cache.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
> b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
> > deleted file mode 100644
> > index 73d8f19..000
> > --- a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
> > +++ /dev/null
> > @@ -1,51 +0,0 @@
> > -SiFive L2 Cache Controller
> > ---
> > -The SiFive Level 2 Cache Controller is used to provide access to fast
> copies
> > -of memory for masters in a Core Complex. The Level 2 Cache Controller
> also
> > -acts as directory-based coherency manager.
> > -All the properties in ePAPR/DeviceTree specification applies for this
> platform
> > -
> > -Required Properties:
> > -
> > -- compatible: Should be "sifive,fu540-c000-ccache" and "cache"
> > -
> > -- cache-block-size: Specifies the block size in bytes of the cache.
> > - Should be 64
> > -
> > -- cache-level: Should be set to 2 for a level 2 cache
> > -
> > -- cache-sets: Specifies the number of associativity sets of the cache.
> > - Should be 1024
> > -
> > -- cache-size: Specifies the size in bytes of the cache. Should be 2097152
> > -
> > -- cache-unified: Specifies the cache is a unified cache
> > -
> > -- interrupts: Must contain 3 entries (DirError, DataError and DataFail
> signals)
> > -
> > -- reg: Physical base address and size of L2 cache controller registers map
> > -
> > -Optional Properties:
> > -
> > -- next-level-cache: phandle to the next level cache if present.
> > -
> > -- memory-region: reference to the reserved-memory for the L2 Loosely
> Integrated
> > - Memory region. The reserved memory node should be defined as per
> the bindings
> > - in reserved-memory.txt
> > -
> > -
> > -Example:
> > -
> > - cache-controller@201 {
> > - compatible = "sifive,fu540-c000-ccache", "cache";
> > - cache-block-size = <64>;
> > - cache-level = <2>;
> > - cache-sets = <1024>;
> > - cache-size = <2097152>;
> > - cache-unified;
> > - interrupt-parent = <>;
> > - interrupts = <1 2 3>;
> > - reg = <0x0 0x201 0x0 0x1000>;
> > - next-level-cache = < >;
> > - memory-region = <_lim>;
> > - };
> > diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
> b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
> > new file mode 100644
> > index 000..e14c8c6
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
> > @@ -0,0 +1,92 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +# Copyright (C) 2020 SiFive, Inc.
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/riscv/sifive-l2-cache.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: SiFive L2 Cache Controller
> > +
> > +maintainers:
> > + - Sagar Kadam
> > + - Yash Shah
> > + - Paul Walmsley
> > +
> > +description:
> > + The SiFive Level 2 Cache Controller is used to provide access to fast
> copies
> > + of memo
[PATCH v1 0/3] convert sifive's prci, plic and pwm bindings to yaml
The PRCI and PLIC controller bindings are in txt format. Here, we convert
them to yaml format.
These patches are tested on commit f4d51dffc6c0 ("Linux 5.9-rc4"). I have
added the log of dt_binding_check for these IP block's on 5.9-rc4 kernel
here [1] in case someone want's to refer it.
[1] https://paste.ubuntu.com/p/VHqqnXdrkJ
Additionally the default log of dt_binding_check on linux-5.9-rc4 without
these patches can be found here [2].
[2] https://paste.ubuntu.com/p/KNGJrJvvdt
Patch History:
V1: Base version.
Sagar Kadam (3):
dt-bindings: fu540: prci: convert PRCI bindings to json-schema
dt-bindings: riscv: convert plic bindings to json-schema
dt-bindings: riscv: convert pwm bindings to json-schema
.../bindings/clock/sifive/fu540-prci.txt | 46 -
.../bindings/clock/sifive/fu540-prci.yaml | 75 +++
.../interrupt-controller/sifive,plic-1.0.0.txt | 58 ---
.../interrupt-controller/sifive,plic-1.0.0.yaml| 107 +
.../devicetree/bindings/pwm/pwm-sifive.txt | 33 ---
.../devicetree/bindings/pwm/pwm-sifive.yaml| 72 ++
6 files changed, 254 insertions(+), 137 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/clock/sifive/fu540-prci.txt
create mode 100644
Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml
delete mode 100644
Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.txt
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
delete mode 100644 Documentation/devicetree/bindings/pwm/pwm-sifive.txt
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sifive.yaml
--
2.7.4
[PATCH v1 2/3] dt-bindings: riscv: convert plic bindings to json-schema
Convert device tree bindings for SiFive's PLIC to YAML format
Signed-off-by: Sagar Kadam
---
.../interrupt-controller/sifive,plic-1.0.0.txt | 58 ---
.../interrupt-controller/sifive,plic-1.0.0.yaml| 107 +
2 files changed, 107 insertions(+), 58 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.txt
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.txt
b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.txt
deleted file mode 100644
index 6adf7a6..000
---
a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-SiFive Platform-Level Interrupt Controller (PLIC)
--
-
-SiFive SOCs include an implementation of the Platform-Level Interrupt
Controller
-(PLIC) high-level specification in the RISC-V Privileged Architecture
-specification. The PLIC connects all external interrupts in the system to all
-hart contexts in the system, via the external interrupt source in each hart.
-
-A hart context is a privilege mode in a hardware execution thread. For
example,
-in an 4 core system with 2-way SMT, you have 8 harts and probably at least two
-privilege modes per hart; machine mode and supervisor mode.
-
-Each interrupt can be enabled on per-context basis. Any context can claim
-a pending enabled interrupt and then release it once it has been handled.
-
-Each interrupt has a configurable priority. Higher priority interrupts are
-serviced first. Each context can specify a priority threshold. Interrupts
-with priority below this threshold will not cause the PLIC to raise its
-interrupt line leading to the context.
-
-While the PLIC supports both edge-triggered and level-triggered interrupts,
-interrupt handlers are oblivious to this distinction and therefore it is not
-specified in the PLIC device-tree binding.
-
-While the RISC-V ISA doesn't specify a memory layout for the PLIC, the
-"sifive,plic-1.0.0" device is a concrete implementation of the PLIC that
-contains a specific memory layout, which is documented in chapter 8 of the
-SiFive U5 Coreplex Series Manual
<https://static.dev.sifive.com/U54-MC-RVCoreIP.pdf>.
-
-Required properties:
-- compatible : "sifive,plic-1.0.0" and a string identifying the actual
- detailed implementation in case that specific bugs need to be worked around.
-- #address-cells : should be <0> or more.
-- #interrupt-cells : should be <1> or more.
-- interrupt-controller : Identifies the node as an interrupt controller.
-- reg : Should contain 1 register range (address and length).
-- interrupts-extended : Specifies which contexts are connected to the PLIC,
- with "-1" specifying that a context is not present. Each node pointed
- to should be a riscv,cpu-intc node, which has a riscv node as parent.
-- riscv,ndev: Specifies how many external interrupts are supported by
- this controller.
-
-Example:
-
- plic: interrupt-controller@c00 {
- #address-cells = <0>;
- #interrupt-cells = <1>;
- compatible = "sifive,plic-1.0.0", "sifive,fu540-c000-plic";
- interrupt-controller;
- interrupts-extended = <
-11
-11 9
-11 9
-11 9
-11 9>;
- reg = <0xc00 0x400>;
- riscv,ndev = <10>;
- };
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
new file mode 100644
index 000..95c8c85
--- /dev/null
+++
b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+# Copyright (C) 2020 SiFive, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/sifive,plic-1.0.0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SiFive Platform-Level Interrupt Controller (PLIC)
+
+description:
+ SiFive SOCs include an implementation of the Platform-Level Interrupt
Controller
+ (PLIC) high-level specification in the RISC-V Privileged Architecture
+ specification. The PLIC connects all external interrupts in the system to all
+ hart contexts in the system, via the external interrupt source in each hart.
+
+ A hart context is a privilege mode in a hardware execution thread. For
example,
+ in an 4 core system with 2-way SMT, you have 8 harts and probably at least
two
+ privilege modes per hart; machine mode and supervisor mode.
+
+ Each interrupt can be enabled o
[PATCH v1 3/3] dt-bindings: riscv: convert pwm bindings to json-schema
Convert device tree bindings for SiFive's PWM controller to YAML
format.
Signed-off-by: Sagar Kadam
---
.../devicetree/bindings/pwm/pwm-sifive.txt | 33 --
.../devicetree/bindings/pwm/pwm-sifive.yaml| 72 ++
2 files changed, 72 insertions(+), 33 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/pwm/pwm-sifive.txt
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sifive.yaml
diff --git a/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
b/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
deleted file mode 100644
index 3d1dd7b0..000
--- a/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-SiFive PWM controller
-
-Unlike most other PWM controllers, the SiFive PWM controller currently only
-supports one period for all channels in the PWM. All PWMs need to run at
-the same period. The period also has significant restrictions on the values
-it can achieve, which the driver rounds to the nearest achievable period.
-PWM RTL that corresponds to the IP block version numbers can be found
-here:
-
-https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/pwm
-
-Required properties:
-- compatible: Should be "sifive,-pwm" and "sifive,pwm".
- Supported compatible strings are: "sifive,fu540-c000-pwm" for the SiFive
- PWM v0 as integrated onto the SiFive FU540 chip, and "sifive,pwm0" for the
- SiFive PWM v0 IP block with no chip integration tweaks.
- Please refer to sifive-blocks-ip-versioning.txt for details.
-- reg: physical base address and length of the controller's registers
-- clocks: Should contain a clock identifier for the PWM's parent clock.
-- #pwm-cells: Should be 3. See pwm.yaml in this directory
- for a description of the cell format.
-- interrupts: one interrupt per PWM channel
-
-Examples:
-
-pwm: pwm@1002 {
- compatible = "sifive,fu540-c000-pwm", "sifive,pwm0";
- reg = <0x0 0x1002 0x0 0x1000>;
- clocks = <>;
- interrupt-parent = <>;
- interrupts = <42 43 44 45>;
- #pwm-cells = <3>;
-};
diff --git a/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml
b/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml
new file mode 100644
index 000..415d053
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2020 SiFive, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/pwm-sifive.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SiFive PWM controller
+
+maintainers:
+ - Yash Shah
+ - Sagar Kadam
+ - Paul Walmsley
+
+description:
+ Unlike most other PWM controllers, the SiFive PWM controller currently
+ only supports one period for all channels in the PWM. All PWMs need to
+ run at the same period. The period also has significant restrictions on
+ the values it can achieve, which the driver rounds to the nearest
+ achievable period. PWM RTL that corresponds to the IP block version
+ numbers can be found here -
+
+
https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/pwm
+
+properties:
+ compatible:
+items:
+ - const: sifive,fu540-c000-pwm
+ - const: sifive,pwm0
+description:
+ Should be "sifive,-pwm" and "sifive,pwm". Supported
+ compatible strings are "sifive,fu540-c000-pwm" for the SiFive PWM v0
+ as integrated onto the SiFive FU540 chip, and "sifive,pwm0" for the
+ SiFive PWM v0 IP block with no chip integration tweaks.
+ Please refer to sifive-blocks-ip-versioning.txt for details.
+
+ reg:
+maxItems: 1
+description: Physical base address and length of the controller's registers
+
+ clocks:
+description: Should contain a clock identifier for the PWM's parent clock.
+
+ "#pwm-cells":
+const: 3
+description:
+ Should be 3. See pwm.yaml in this directory for a description of the
+ cell format.
+
+ interrupts:
+maxItems: 1
+description: One interrupt per PWM channel.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#pwm-cells"
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+pwm: pwm@1002 {
+ compatible = "sifive,fu540-c000-pwm", "sifive,pwm0";
+ reg = <0x1002 0x1000>;
+ clocks = <>;
+ interrupt-parent = <>;
+ interrupts = <42 43 44 45>;
+ #pwm-cells = <3>;
+};
--
2.7.4
[PATCH v1 1/3] dt-bindings: fu540: prci: convert PRCI bindings to json-schema
FU540-C000 SoC from SiFive has a PRCI block, here we convert
the device tree bindings from txt to YAML.
Signed-off-by: Sagar Kadam
---
.../bindings/clock/sifive/fu540-prci.txt | 46 -
.../bindings/clock/sifive/fu540-prci.yaml | 75 ++
2 files changed, 75 insertions(+), 46 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/clock/sifive/fu540-prci.txt
create mode 100644
Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml
diff --git a/Documentation/devicetree/bindings/clock/sifive/fu540-prci.txt
b/Documentation/devicetree/bindings/clock/sifive/fu540-prci.txt
deleted file mode 100644
index 349808f..000
--- a/Documentation/devicetree/bindings/clock/sifive/fu540-prci.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-SiFive FU540 PRCI bindings
-
-On the FU540 family of SoCs, most system-wide clock and reset integration
-is via the PRCI IP block.
-
-Required properties:
-- compatible: Should be "sifive,-prci". Only one value is
- supported: "sifive,fu540-c000-prci"
-- reg: Should describe the PRCI's register target physical address region
-- clocks: Should point to the hfclk device tree node and the rtcclk
- device tree node. The RTC clock here is not a time-of-day clock,
- but is instead a high-stability clock source for system timers
- and cycle counters.
-- #clock-cells: Should be <1>
-
-The clock consumer should specify the desired clock via the clock ID
-macros defined in include/dt-bindings/clock/sifive-fu540-prci.h.
-These macros begin with PRCI_CLK_.
-
-The hfclk and rtcclk nodes are required, and represent physical
-crystals or resonators located on the PCB. These nodes should be present
-underneath /, rather than /soc.
-
-Examples:
-
-/* under /, in PCB-specific DT data */
-hfclk: hfclk {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <>;
- clock-output-names = "hfclk";
-};
-rtcclk: rtcclk {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <100>;
- clock-output-names = "rtcclk";
-};
-
-/* under /soc, in SoC-specific DT data */
-prci: clock-controller@1000 {
- compatible = "sifive,fu540-c000-prci";
- reg = <0x0 0x1000 0x0 0x1000>;
- clocks = <>, <>;
- #clock-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml
b/Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml
new file mode 100644
index 000..49386cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2020 SiFive, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/sifive/fu540-prci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SiFive FU540 Power Reset Clock Interrupt Controller (PRCI)
+
+maintainers:
+ - Sagar Kadam
+ - Paul Walmsley
+
+description:
+ On the FU540 family of SoCs, most system-wide clock and reset integration
+ is via the PRCI IP block.
+ The clock consumer should specify the desired clock via the clock ID
+ macros defined in include/dt-bindings/clock/sifive-fu540-prci.h.
+ These macros begin with PRCI_CLK_.
+
+ The hfclk and rtcclk nodes are required, and represent physical
+ crystals or resonators located on the PCB. These nodes should be present
+ underneath /, rather than /soc.
+
+properties:
+ compatible:
+enum:
+ - sifive,fu540-c000-prci
+description:
+ Should have "sifive,-prci", only one value is supported
+
+ reg:
+maxItems: 1
+description: Describe the PRCI's register target physical address region
+
+ clocks:
+description:
+ Should point to the hfclk device tree node and the rtcclk device tree
node.
+ The RTC clock here is not a time-of-day clock, but is instead a
high-stability
+ clock source for system timers and cycle counters.
+
+ "#clock-cells":
+const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+//hfclk and rtcclk present under /, in PCB-specific DT data
+hfclk: hfclk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <>;
+ clock-output-names = "hfclk";
+};
+rtcclk: rtcclk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <100>;
+ clock-output-names = "rtcclk";
+};
+
+//under /soc, in SoC-specific DT data
+prci: clock-controller@1000 {
+ compatible = "sifive,fu540-c000-prci";
+ reg = <0x1000 0x1000>;
+ clocks = <>, <>;
+ #clock-cells = <1>;
+};
--
2.7.4
[RESEND PATCH v2 1/1] dt-bindings: riscv: sifive-l2-cache: convert bindings to json-schema
Convert the device tree bindings for the SiFive's FU540-C000 SoC's L2 Cache
controller to YAML format.
Signed-off-by: Sagar Kadam
---
.../devicetree/bindings/riscv/sifive-l2-cache.txt | 51
.../devicetree/bindings/riscv/sifive-l2-cache.yaml | 92 ++
2 files changed, 92 insertions(+), 51 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
create mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
deleted file mode 100644
index 73d8f19..000
--- a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
+++ /dev/null
@@ -1,51 +0,0 @@
-SiFive L2 Cache Controller
---
-The SiFive Level 2 Cache Controller is used to provide access to fast copies
-of memory for masters in a Core Complex. The Level 2 Cache Controller also
-acts as directory-based coherency manager.
-All the properties in ePAPR/DeviceTree specification applies for this platform
-
-Required Properties:
-
-- compatible: Should be "sifive,fu540-c000-ccache" and "cache"
-
-- cache-block-size: Specifies the block size in bytes of the cache.
- Should be 64
-
-- cache-level: Should be set to 2 for a level 2 cache
-
-- cache-sets: Specifies the number of associativity sets of the cache.
- Should be 1024
-
-- cache-size: Specifies the size in bytes of the cache. Should be 2097152
-
-- cache-unified: Specifies the cache is a unified cache
-
-- interrupts: Must contain 3 entries (DirError, DataError and DataFail signals)
-
-- reg: Physical base address and size of L2 cache controller registers map
-
-Optional Properties:
-
-- next-level-cache: phandle to the next level cache if present.
-
-- memory-region: reference to the reserved-memory for the L2 Loosely Integrated
- Memory region. The reserved memory node should be defined as per the bindings
- in reserved-memory.txt
-
-
-Example:
-
- cache-controller@201 {
- compatible = "sifive,fu540-c000-ccache", "cache";
- cache-block-size = <64>;
- cache-level = <2>;
- cache-sets = <1024>;
- cache-size = <2097152>;
- cache-unified;
- interrupt-parent = <>;
- interrupts = <1 2 3>;
- reg = <0x0 0x201 0x0 0x1000>;
- next-level-cache = < >;
- memory-region = <_lim>;
- };
diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
new file mode 100644
index 000..e14c8c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (C) 2020 SiFive, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/sifive-l2-cache.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SiFive L2 Cache Controller
+
+maintainers:
+ - Sagar Kadam
+ - Yash Shah
+ - Paul Walmsley
+
+description:
+ The SiFive Level 2 Cache Controller is used to provide access to fast copies
+ of memory for masters in a Core Complex. The Level 2 Cache Controller also
+ acts as directory-based coherency manager.
+ All the properties in ePAPR/DeviceTree specification applies for this
platform.
+
+allOf:
+ - $ref: /schemas/cache-controller.yaml#
+
+properties:
+ compatible:
+items:
+ - enum:
+- sifive,fu540-c000-ccache
+description: |
+ Should have "sifive,-cache" and "cache".
+
+ cache-block-size:
+const: 64
+
+ cache-level:
+const: 2
+
+ cache-sets:
+const: 1024
+
+ cache-size:
+const: 2097152
+
+ cache-unified: true
+
+ interrupts:
+description: |
+ Must contain entries for DirError, DataError and DataFail signals.
+minItems: 1
+maxItems: 3
+
+ reg:
+maxItems: 1
+description: address of cache controller's registers.
+
+
+ next-level-cache:
+description: |
+ Phandle to the next level cache if present.
+
+ memory-region:
+description: |
+ The reference to the reserved-memory for the L2 Loosely Integrated
memory region.
+ The reserved memory node should be defined as per the bindings in
reserved-memory.txt.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - cache-block-size
+ - cache-level
+ - cache-sets
+ - cache-size
+ - cache-unified
+ - interrupts
+ - reg
+
+examples:
+ - |
+cache-controller@201 {
+compatible = "sifive,fu540-c000-ccache";
+cache-block-size = <64>;
+cache-level = <2>;
+cache-sets = <1024>;
+cache-size = <2097152>;
+cache-unifie
[RESEND PATCH v2 0/1] convert l2 cache dt bindings to YAML format
Resending it, since subject lines of earlier v2 patches missed the file
sequence like PATCH 0/1 and 1/1.
This patch is created and tested on top of mainline linux
commit d012a7190fc1 ("Linux 5.9-rc2")
Reference log of "make dt_binding_check" is available here[1].
I was able to reproduce the error after excluding the DT_SCHEMA_FILES
option. Just in case required the failure log is here[2].
[1] https://paste.ubuntu.com/p/R5b52vCkKJ/
[2] https://paste.ubuntu.com/p/gwYY3hd9Rx/
Change History:
V2:
-Fixed bot failure mentioned by Rob Herring
-Updated dt-schema and kernel as suggested
V1:
Base version
Sagar Kadam (1):
dt-bindings: riscv: sifive-l2-cache: convert bindings to json-schema
.../devicetree/bindings/riscv/sifive-l2-cache.txt | 51
.../devicetree/bindings/riscv/sifive-l2-cache.yaml | 92 ++
2 files changed, 92 insertions(+), 51 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
create mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
--
2.7.4
RE: [PATCH v2] dt-bindings: riscv: sifive-l2-cache: convert bindings to json-schema
Hi,
Please ignore this v2, since the subject line missed the patch sequences 0/1
and 1/1.
Will resubmit it.
Thanks & BR,
Sagar
> -Original Message-
> From: Sagar Kadam
> Sent: Friday, August 28, 2020 9:31 PM
> To: linux-kernel@vger.kernel.org
> Cc: linux-ri...@lists.infradead.org; devicet...@vger.kernel.org;
> robh...@kernel.org; Paul Walmsley ( Sifive) ;
> pal...@dabbelt.com; a...@eecs.berkeley.edu; Yash Shah
> ; Sagar Kadam
> Subject: [PATCH v2] dt-bindings: riscv: sifive-l2-cache: convert bindings to
> json-schema
>
> Convert the device tree bindings for the SiFive's FU540-C000 SoC's L2 Cache
> controller to YAML format.
>
> Signed-off-by: Sagar Kadam
> ---
> .../devicetree/bindings/riscv/sifive-l2-cache.txt | 51
> .../devicetree/bindings/riscv/sifive-l2-cache.yaml | 92
> ++
> 2 files changed, 92 insertions(+), 51 deletions(-) delete mode 100644
> Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
> create mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-
> cache.yaml
>
> diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
> b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
> deleted file mode 100644
> index 73d8f19..000
> --- a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
> +++ /dev/null
> @@ -1,51 +0,0 @@
> -SiFive L2 Cache Controller
> ---
> -The SiFive Level 2 Cache Controller is used to provide access to fast copies
> -
> of memory for masters in a Core Complex. The Level 2 Cache Controller also
> -acts as directory-based coherency manager.
> -All the properties in ePAPR/DeviceTree specification applies for this
> platform
> -
> -Required Properties:
> -
> -- compatible: Should be "sifive,fu540-c000-ccache" and "cache"
> -
> -- cache-block-size: Specifies the block size in bytes of the cache.
> - Should be 64
> -
> -- cache-level: Should be set to 2 for a level 2 cache
> -
> -- cache-sets: Specifies the number of associativity sets of the cache.
> - Should be 1024
> -
> -- cache-size: Specifies the size in bytes of the cache. Should be 2097152
> -
> -- cache-unified: Specifies the cache is a unified cache
> -
> -- interrupts: Must contain 3 entries (DirError, DataError and DataFail
> signals)
> -
> -- reg: Physical base address and size of L2 cache controller registers map
> -
> -Optional Properties:
> -
> -- next-level-cache: phandle to the next level cache if present.
> -
> -- memory-region: reference to the reserved-memory for the L2 Loosely
> Integrated
> - Memory region. The reserved memory node should be defined as per the
> bindings
> - in reserved-memory.txt
> -
> -
> -Example:
> -
> - cache-controller@201 {
> - compatible = "sifive,fu540-c000-ccache", "cache";
> - cache-block-size = <64>;
> - cache-level = <2>;
> - cache-sets = <1024>;
> - cache-size = <2097152>;
> - cache-unified;
> - interrupt-parent = <>;
> - interrupts = <1 2 3>;
> - reg = <0x0 0x201 0x0 0x1000>;
> - next-level-cache = < >;
> - memory-region = <_lim>;
> - };
> diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
> b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
> new file mode 100644
> index 000..e14c8c6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
> @@ -0,0 +1,92 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) # Copyright (C)
> +2020 SiFive, Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/riscv/sifive-l2-cache.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: SiFive L2 Cache Controller
> +
> +maintainers:
> + - Sagar Kadam
> + - Yash Shah
> + - Paul Walmsley
> +
> +description:
> + The SiFive Level 2 Cache Controller is used to provide access to fast
> +copies
> + of memory for masters in a Core Complex. The Level 2 Cache Controller
> +also
> + acts as directory-based coherency manager.
> + All the properties in ePAPR/DeviceTree specification applies for this
> platform.
> +
> +allOf:
> + - $ref: /schemas/cache-controller.yaml#
> +
> +properties:
> + compatible:
> +items:
> + - enum:
> +- sifive,fu540-c000-ccache
> +description: |
> + Should have "sifive,-cache" and "cache".
> +
> + cache-block-size:
> +
[PATCH v2] dt-bindings: riscv: sifive-l2-cache: convert bindings to json-schema
Convert the device tree bindings for the SiFive's FU540-C000 SoC's L2 Cache
controller to YAML format.
Signed-off-by: Sagar Kadam
---
.../devicetree/bindings/riscv/sifive-l2-cache.txt | 51
.../devicetree/bindings/riscv/sifive-l2-cache.yaml | 92 ++
2 files changed, 92 insertions(+), 51 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
create mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
deleted file mode 100644
index 73d8f19..000
--- a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
+++ /dev/null
@@ -1,51 +0,0 @@
-SiFive L2 Cache Controller
---
-The SiFive Level 2 Cache Controller is used to provide access to fast copies
-of memory for masters in a Core Complex. The Level 2 Cache Controller also
-acts as directory-based coherency manager.
-All the properties in ePAPR/DeviceTree specification applies for this platform
-
-Required Properties:
-
-- compatible: Should be "sifive,fu540-c000-ccache" and "cache"
-
-- cache-block-size: Specifies the block size in bytes of the cache.
- Should be 64
-
-- cache-level: Should be set to 2 for a level 2 cache
-
-- cache-sets: Specifies the number of associativity sets of the cache.
- Should be 1024
-
-- cache-size: Specifies the size in bytes of the cache. Should be 2097152
-
-- cache-unified: Specifies the cache is a unified cache
-
-- interrupts: Must contain 3 entries (DirError, DataError and DataFail signals)
-
-- reg: Physical base address and size of L2 cache controller registers map
-
-Optional Properties:
-
-- next-level-cache: phandle to the next level cache if present.
-
-- memory-region: reference to the reserved-memory for the L2 Loosely Integrated
- Memory region. The reserved memory node should be defined as per the bindings
- in reserved-memory.txt
-
-
-Example:
-
- cache-controller@201 {
- compatible = "sifive,fu540-c000-ccache", "cache";
- cache-block-size = <64>;
- cache-level = <2>;
- cache-sets = <1024>;
- cache-size = <2097152>;
- cache-unified;
- interrupt-parent = <>;
- interrupts = <1 2 3>;
- reg = <0x0 0x201 0x0 0x1000>;
- next-level-cache = < >;
- memory-region = <_lim>;
- };
diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
new file mode 100644
index 000..e14c8c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (C) 2020 SiFive, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/sifive-l2-cache.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SiFive L2 Cache Controller
+
+maintainers:
+ - Sagar Kadam
+ - Yash Shah
+ - Paul Walmsley
+
+description:
+ The SiFive Level 2 Cache Controller is used to provide access to fast copies
+ of memory for masters in a Core Complex. The Level 2 Cache Controller also
+ acts as directory-based coherency manager.
+ All the properties in ePAPR/DeviceTree specification applies for this
platform.
+
+allOf:
+ - $ref: /schemas/cache-controller.yaml#
+
+properties:
+ compatible:
+items:
+ - enum:
+- sifive,fu540-c000-ccache
+description: |
+ Should have "sifive,-cache" and "cache".
+
+ cache-block-size:
+const: 64
+
+ cache-level:
+const: 2
+
+ cache-sets:
+const: 1024
+
+ cache-size:
+const: 2097152
+
+ cache-unified: true
+
+ interrupts:
+description: |
+ Must contain entries for DirError, DataError and DataFail signals.
+minItems: 1
+maxItems: 3
+
+ reg:
+maxItems: 1
+description: address of cache controller's registers.
+
+
+ next-level-cache:
+description: |
+ Phandle to the next level cache if present.
+
+ memory-region:
+description: |
+ The reference to the reserved-memory for the L2 Loosely Integrated
memory region.
+ The reserved memory node should be defined as per the bindings in
reserved-memory.txt.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - cache-block-size
+ - cache-level
+ - cache-sets
+ - cache-size
+ - cache-unified
+ - interrupts
+ - reg
+
+examples:
+ - |
+cache-controller@201 {
+compatible = "sifive,fu540-c000-ccache";
+cache-block-size = <64>;
+cache-level = <2>;
+cache-sets = <1024>;
+cache-size = <2097152>;
+cache-unifie
[PATCH v2] convert l2 cache dt bindings to YAML format
This patch is created and tested on top of mainline linux
commit d012a7190fc1 ("Linux 5.9-rc2")
Reference log of "make dt_binding_check" is available here[1].
I was able to reproduce the error after excluding the DT_SCHEMA_FILES
option. Just in case required the failure log is here[2].
[1] https://paste.ubuntu.com/p/R5b52vCkKJ/
[2] https://paste.ubuntu.com/p/gwYY3hd9Rx/
Change History:
V2:
-Fixed bot failure mentioned by Rob Herring
-Updated dt-schema and kernel as suggested
V1:
Base version
Sagar Kadam (1):
dt-bindings: riscv: sifive-l2-cache: convert bindings to json-schema
.../devicetree/bindings/riscv/sifive-l2-cache.txt | 51
.../devicetree/bindings/riscv/sifive-l2-cache.yaml | 92 ++
2 files changed, 92 insertions(+), 51 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
create mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
--
2.7.4
RE: [PATCH 1/1] dt-bindings: riscv: sifive-l2-cache: convert bindings to json-schema
Hi Rob, > -Original Message- > From: Rob Herring > Sent: Tuesday, August 25, 2020 9:51 PM > To: Sagar Kadam > Cc: a...@eecs.berkeley.edu; devicet...@vger.kernel.org; Paul Walmsley ( > Sifive) ; Yash Shah ; > pal...@dabbelt.com; linux-kernel@vger.kernel.org; linux- > ri...@lists.infradead.org > Subject: Re: [PATCH 1/1] dt-bindings: riscv: sifive-l2-cache: convert bindings > to json-schema > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > On Tue, Aug 25, 2020 at 2:47 AM Sagar Kadam > wrote: > > > > Hello Rob, > > > > > -Original Message- > > > From: Rob Herring > > > Sent: Monday, August 24, 2020 11:06 PM > > > To: Sagar Kadam > > > Cc: a...@eecs.berkeley.edu; devicet...@vger.kernel.org; Paul Walmsley > > > ( > > > Sifive) ; robh...@kernel.org; Yash Shah > > > ; pal...@dabbelt.com; linux- > > > ker...@vger.kernel.org; linux-ri...@lists.infradead.org > > > Subject: Re: [PATCH 1/1] dt-bindings: riscv: sifive-l2-cache: > > > convert bindings to json-schema > > > > > > [External Email] Do not click links or attachments unless you > > > recognize the sender and know the content is safe > > > > > > On Mon, 24 Aug 2020 13:20:21 +0530, Sagar Kadam wrote: > > > > Convert the device tree bindings for the SiFive's FU540-C000 SoC's > > > > L2 Cache controller to YAML format. > > > > > > > > Signed-off-by: Sagar Kadam > > > > --- > > > > .../devicetree/bindings/riscv/sifive-l2-cache.txt | 51 > > > > .../devicetree/bindings/riscv/sifive-l2-cache.yaml | > > > > 93 > > > > ++ > > > > 2 files changed, 93 insertions(+), 51 deletions(-) delete mode > > > > 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt > > > > create mode 100644 > > > > Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml > > > > > > > > > > > > > My bot found errors running 'make dt_binding_check' on your patch: > > > > > > > I had checked using DT_SCHEMA_FILES option due to which it didn't > > catch any error on other schemas. Without this I could regenerate the > error you mentioned. > > I will fix it and update. Sorry for the error. > > Update your kernel. DT_SCHEMA_FILES setting no longer matters on current > tree. It only affects 'dtbs_check' now. > Thanks for the input. Sure, I see v5.9-rc2 as latest tag on mainline, I will base and fix my patch above it. BR, Sagar > Rob
RE: [PATCH 1/1] dt-bindings: riscv: sifive-l2-cache: convert bindings to json-schema
Hello Rob,
> -Original Message-
> From: Rob Herring
> Sent: Monday, August 24, 2020 11:06 PM
> To: Sagar Kadam
> Cc: a...@eecs.berkeley.edu; devicet...@vger.kernel.org; Paul Walmsley (
> Sifive) ; robh...@kernel.org; Yash Shah
> ; pal...@dabbelt.com; linux-
> ker...@vger.kernel.org; linux-ri...@lists.infradead.org
> Subject: Re: [PATCH 1/1] dt-bindings: riscv: sifive-l2-cache: convert bindings
> to json-schema
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> On Mon, 24 Aug 2020 13:20:21 +0530, Sagar Kadam wrote:
> > Convert the device tree bindings for the SiFive's FU540-C000 SoC's L2
> > Cache controller to YAML format.
> >
> > Signed-off-by: Sagar Kadam
> > ---
> > .../devicetree/bindings/riscv/sifive-l2-cache.txt | 51
> > .../devicetree/bindings/riscv/sifive-l2-cache.yaml | 93
> > ++
> > 2 files changed, 93 insertions(+), 51 deletions(-) delete mode
> > 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
> > create mode 100644
> > Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
> >
>
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
I had checked using DT_SCHEMA_FILES option due to which it didn't catch any
error on other
schemas. Without this I could regenerate the error you mentioned.
I will fix it and update. Sorry for the error.
Thanks & BR,
Sagar
> /builds/robherring/linux-dt-
> review/Documentation/devicetree/bindings/thermal/thermal-cooling-
> devices.example.dt.yaml: l2-cache: $nodename:0: 'l2-cache' does not match
> '^(cache-controller|cpu)(@[0-9a-f,]+)*$'
> From schema: /builds/robherring/linux-dt-
> review/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
> /builds/robherring/linux-dt-
> review/Documentation/devicetree/bindings/thermal/thermal-cooling-
> devices.example.dt.yaml: l2-cache: compatible:0: 'cache' is not one of
> ['sifive,fu540-c000-ccache']
> From schema: /builds/robherring/linux-dt-
> review/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
> /builds/robherring/linux-dt-
> review/Documentation/devicetree/bindings/thermal/thermal-cooling-
> devices.example.dt.yaml: l2-cache: compatible: ['cache'] is too short
> From schema: /builds/robherring/linux-dt-
> review/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
> /builds/robherring/linux-dt-
> review/Documentation/devicetree/bindings/thermal/thermal-cooling-
> devices.example.dt.yaml: l2-cache: 'l3-cache' does not match any of the
> regexes: 'pinctrl-[0-9]+'
> From schema: /builds/robherring/linux-dt-
> review/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
> /builds/robherring/linux-dt-
> review/Documentation/devicetree/bindings/thermal/thermal-cooling-
> devices.example.dt.yaml: l2-cache: 'cache-block-size' is a required property
> From schema: /builds/robherring/linux-dt-
> review/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
> /builds/robherring/linux-dt-
> review/Documentation/devicetree/bindings/thermal/thermal-cooling-
> devices.example.dt.yaml: l2-cache: 'cache-level' is a required property
> From schema: /builds/robherring/linux-dt-
> review/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
> /builds/robherring/linux-dt-
> review/Documentation/devicetree/bindings/thermal/thermal-cooling-
> devices.example.dt.yaml: l2-cache: 'cache-sets' is a required property
> From schema: /builds/robherring/linux-dt-
> review/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
> /builds/robherring/linux-dt-
> review/Documentation/devicetree/bindings/thermal/thermal-cooling-
> devices.example.dt.yaml: l2-cache: 'cache-size' is a required property
> From schema: /builds/robherring/linux-dt-
> review/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
> /builds/robherring/linux-dt-
> review/Documentation/devicetree/bindings/thermal/thermal-cooling-
> devices.example.dt.yaml: l2-cache: 'cache-unified' is a required property
> From schema: /builds/robherring/linux-dt-
> review/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
> /builds/robherring/linux-dt-
> review/Documentation/devicetree/bindings/thermal/thermal-cooling-
> devices.example.dt.yaml: l2-cache: 'reg' is a required property
> From schema: /builds/robherring/linux-dt-
> review/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
> /builds/robherring/linux-dt-
> review/Documentation/devicetree/bindings/thermal/thermal-cooling-
> devices.example.dt.yaml: l2-cache: {'compatible': ['cache'],
> 'ne
[PATCH 1/1] dt-bindings: riscv: sifive-l2-cache: convert bindings to json-schema
Convert the device tree bindings for the SiFive's FU540-C000 SoC's L2 Cache
controller to YAML format.
Signed-off-by: Sagar Kadam
---
.../devicetree/bindings/riscv/sifive-l2-cache.txt | 51
.../devicetree/bindings/riscv/sifive-l2-cache.yaml | 93 ++
2 files changed, 93 insertions(+), 51 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
create mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
deleted file mode 100644
index 73d8f19..000
--- a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
+++ /dev/null
@@ -1,51 +0,0 @@
-SiFive L2 Cache Controller
---
-The SiFive Level 2 Cache Controller is used to provide access to fast copies
-of memory for masters in a Core Complex. The Level 2 Cache Controller also
-acts as directory-based coherency manager.
-All the properties in ePAPR/DeviceTree specification applies for this platform
-
-Required Properties:
-
-- compatible: Should be "sifive,fu540-c000-ccache" and "cache"
-
-- cache-block-size: Specifies the block size in bytes of the cache.
- Should be 64
-
-- cache-level: Should be set to 2 for a level 2 cache
-
-- cache-sets: Specifies the number of associativity sets of the cache.
- Should be 1024
-
-- cache-size: Specifies the size in bytes of the cache. Should be 2097152
-
-- cache-unified: Specifies the cache is a unified cache
-
-- interrupts: Must contain 3 entries (DirError, DataError and DataFail signals)
-
-- reg: Physical base address and size of L2 cache controller registers map
-
-Optional Properties:
-
-- next-level-cache: phandle to the next level cache if present.
-
-- memory-region: reference to the reserved-memory for the L2 Loosely Integrated
- Memory region. The reserved memory node should be defined as per the bindings
- in reserved-memory.txt
-
-
-Example:
-
- cache-controller@201 {
- compatible = "sifive,fu540-c000-ccache", "cache";
- cache-block-size = <64>;
- cache-level = <2>;
- cache-sets = <1024>;
- cache-size = <2097152>;
- cache-unified;
- interrupt-parent = <>;
- interrupts = <1 2 3>;
- reg = <0x0 0x201 0x0 0x1000>;
- next-level-cache = < >;
- memory-region = <_lim>;
- };
diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
new file mode 100644
index 000..d2edeb0
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (C) 2020 SiFive, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/sifive-l2-cache.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SiFive L2 Cache Controller
+
+maintainers:
+ - Sagar Kadam
+ - Yash Shah
+ - Paul Walmsley
+
+description:
+ The SiFive Level 2 Cache Controller is used to provide access to fast copies
+ of memory for masters in a Core Complex. The Level 2 Cache Controller also
+ acts as directory-based coherency manager.
+ All the properties in ePAPR/DeviceTree specification applies for this
platform.
+
+allOf:
+ - $ref: /schemas/cache-controller.yaml#
+
+properties:
+ compatible:
+items:
+ - enum:
+- sifive,fu540-c000-ccache
+ - const: cache
+description: |
+ Should have "sifive,-cache" and "cache".
+
+ cache-block-size:
+const: 64
+
+ cache-level:
+const: 2
+
+ cache-sets:
+const: 1024
+
+ cache-size:
+const: 2097152
+
+ cache-unified: true
+
+ interrupts:
+description: |
+ Must contain entries for DirError, DataError and DataFail signals.
+minItems: 1
+maxItems: 3
+
+ reg:
+maxItems: 1
+description: address of cache controller's registers.
+
+
+ next-level-cache:
+description: |
+ Phandle to the next level cache if present.
+
+ memory-region:
+description: |
+ The reference to the reserved-memory for the L2 Loosely Integrated
memory region.
+ The reserved memory node should be defined as per the bindings in
reserved-memory.txt.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - cache-block-size
+ - cache-level
+ - cache-sets
+ - cache-size
+ - cache-unified
+ - interrupts
+ - reg
+
+examples:
+ - |
+cache-controller@201 {
+compatible = "sifive,fu540-c000-ccache", "cache";
+cache-block-size = <64>;
+cache-level = <2>;
+cache-sets = <1024>;
+cache-s
[PATCH 0/1] convert l2 cache dt bindings to YAML format
The patch is created on mainline linux v5.8.rc-7
commit 92ed30191993 ("Linux 5.8-rc7")
Following is the log for dt_binding_check and dtbs_check
linux> make DT_SCHEMA_FLAGS="-u"
DT_SCHEMA_FILES="Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml"
dt_binding_check
HOSTCC scripts/dtc/dtc.o
HOSTCC scripts/dtc/flattree.o
HOSTCC scripts/dtc/fstree.o
HOSTCC scripts/dtc/data.o
HOSTCC scripts/dtc/livetree.o
HOSTCC scripts/dtc/treesource.o
HOSTCC scripts/dtc/srcpos.o
HOSTCC scripts/dtc/checks.o
HOSTCC scripts/dtc/util.o
LEX scripts/dtc/dtc-lexer.lex.c
YACCscripts/dtc/dtc-parser.tab.[ch]
HOSTCC scripts/dtc/dtc-lexer.lex.o
HOSTCC scripts/dtc/dtc-parser.tab.o
HOSTCC scripts/dtc/yamltree.o
HOSTLD scripts/dtc/dtc
CHKDT Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
SCHEMA Documentation/devicetree/bindings/processed-schema-examples.yaml
DTC
Documentation/devicetree/bindings/riscv/sifive-l2-cache.example.dt.yaml
CHECK
Documentation/devicetree/bindings/riscv/sifive-l2-cache.example.dt.yaml
linux> make DT_SCHEMA_FLAGS="-u"
DT_SCHEMA_FILES="Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml"
dtbs_check
SCHEMA Documentation/devicetree/bindings/processed-schema.yaml
UPD include/config/kernel.release
DTC arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dtb
DTC arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dt.yaml
CHECK arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dt.yaml
linux>
Sagar Kadam (1):
dt-bindings: riscv: sifive-l2-cache: convert bindings to json-schema
.../devicetree/bindings/riscv/sifive-l2-cache.txt | 51
.../devicetree/bindings/riscv/sifive-l2-cache.yaml | 93 ++
2 files changed, 93 insertions(+), 51 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt
create mode 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
--
2.7.4
RE: [PATCH v2 0/2] enable spi flash and update is25wp256d page write capabilities
Hi, A gentle reminder. Any suggestions here? BR, Sagar Kadam > -Original Message- > From: Sagar Kadam > Sent: Tuesday, May 19, 2020 4:16 PM > To: linux-ri...@lists.infradead.org; linux-kernel@vger.kernel.org; linux- > m...@lists.infradead.org > Cc: Paul Walmsley ; pal...@dabbelt.com; > a...@eecs.berkeley.edu; tudor.amba...@microchip.com; > miquel.ray...@bootlin.com; rich...@nod.at; vigne...@ti.com; > anup.pa...@wdc.com; Sagar Kadam > Subject: [PATCH v2 0/2] enable spi flash and update is25wp256d page write > capabilities > > HiFive Unleashed A00 board has is25wp256d snor chip. It is observed that it > gets configured with Serial Input Page program by the end of spi_nor_scan. > Using the post bfpt fixup hook we prioritize the page program settings to > use quad input page program (opcode:0x34) over serial input page program > (opcode: 0x12). > > The patchset is tested on Linux 5.7.0-rc5. > > Changelog: > === > V2: > -Split common code between is25lp256 and is25wp256 devices as suggested > Added a generic post bfpt fixup handler that identifies the flash parts > based on their device id and uses the corresponding fixup. Other device's > that need a post bfpt fixup can just add the device id check and either > reuse the available fixups or write the necessary fixup code if one is not > available. > > V1: > -Moved SPI_SIFIVE from defconfig to Kconfig.socs for SOC_SIFIVE. > Retained it's configurability using "imply" instead of "select" > > V0: Base version patch (Tested on 5.7.0-rc3). > > > Sagar Shrikant Kadam (2): > riscv: defconfig: enable spi nor on Hifive Unleashed A00 > spi: nor: update page program settings for is25wp256 using post bfpt > fixup > > arch/riscv/Kconfig.socs | 1 + > arch/riscv/configs/defconfig | 3 +- > drivers/mtd/spi-nor/issi.c | 72 > > 3 files changed, 63 insertions(+), 13 deletions(-) > > -- > 2.7.4
RE: [PATCH v1 0/3] fix macb phy probe failure if phy-reset is not handled
Hello, A gentle reminder. Any suggestions here? BR, Sagar > -Original Message- > From: Sagar Kadam > Sent: Wednesday, May 13, 2020 7:27 PM > To: linux-kernel@vger.kernel.org; linux-ri...@lists.infradead.org; > devicet...@vger.kernel.org; robh...@kernel.org > Cc: pal...@dabbelt.com; Paul Walmsley ; > atish.pa...@wdc.com; Sagar Kadam > Subject: [PATCH v1 0/3] fix macb phy probe failure if phy-reset is not > handled > > HiFive Unleashed is having VSC8541-01 ethernet phy device and requires a > specific reset sequence of 0-1-0-1 in order to use it in unmanaged mode. > This series addresses a corner case where phy reset is not handled by boot > stages prior to linux. > Somewhat similar unreliable phy probe failure was reported and discussed > here [1]. > The macb driver fails to detect the ethernet phy device if the bootloader > doesn't provide a proper reset sequence to the phy device or the phy itself > is in some invalid state. Currently, the FSBL is resetting the phy device, and > so there is no issue observed in the linux network setup. > > The series is based on linux-5.7-rc5. > Patch 1: Add the OUI to the phy dt node to fix issue of missing mdio device > Patch 2 and 3: > Resetting phy needs GPIO support so add to dt and defconfig. > > [1] https://lkml.org/lkml/2018/11/29/154 > > To reproduce the issue: > 1. Comment out VSC8541 reset sequence in fsbl/main.c >from within the freedom-u540-c000-bootloader. > 2. Build and flash fsbl.bin to micro sdcard. > > Boot the board and bootlog will show network setup failure messages as: > > [ 1.069474] libphy: MACB_mii_bus: probed [ 1.073092] mdio_bus > 1009.ethernet-: MDIO device at address 0 > is missing > . > [ 1.979252] macb 1009.ethernet eth0: Could not attach PHY (-19) > > 3. Now apply the series build, and boot kernel. > 4. MACB and VSC8541 driver get successfully probed and the network is set >without any failure. > > > So irrespective of whether the prior stages handle the phy reset sequence, > the probing is successful in both the cases of cold boot and warm boot. > > Change History: > === > V1: > -Ignore 4th patch as suggested and so removed it from the series. > -Verified this series on 5.7-rc5. > > V0: Base RFC patch. Verified on 5.7-rc2 > > > Sagar Shrikant Kadam (3): > dts: phy: fix missing mdio device and probe failure of vsc8541-01 > device > dts: phy: add GPIO number and active state used for phy reset > riscv: defconfig: enable gpio support for HiFive Unleashed > > arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts | 2 ++ > arch/riscv/configs/defconfig| 2 ++ > 2 files changed, 4 insertions(+) > > -- > 2.7.4
RE: [PATCH v1 2/2] spi: nor: update page program settings for is25wp256 using post bfpt fixup
Hi Pratyush,
> -Original Message-
> From: Pratyush Yadav
> Sent: Friday, May 15, 2020 12:35 PM
> To: Sagar Kadam
> Cc: linux-ri...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> m...@lists.infradead.org; tudor.amba...@microchip.com;
> miquel.ray...@bootlin.com; rich...@nod.at; vigne...@ti.com;
> anup.pa...@wdc.com; a...@eecs.berkeley.edu; pal...@dabbelt.com; Paul
> Walmsley
> Subject: Re: [PATCH v1 2/2] spi: nor: update page program settings for
> is25wp256 using post bfpt fixup
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> Hi Sagar,
>
> On 14/05/20 04:50AM, Sagar Shrikant Kadam wrote:
> > During SFDP parsing it is seen that the IS25WP256d device is missing 4BAIT
> > (4-Byte address instruction table), due to which it's page program
> > capacity doesn't get correctly populated and the device gets configured
> > with 4-byte Address Serial Input Page Program i.e. SNOR_PROTO_1_1_1
> > even though it can work with SNOR_PROTO_1_1_4.
> >
> > Here using the post bfpt fixup hooks we update the page program
> > settings to 4-byte QUAD Input Page program operations.
> >
> > The patch is tested on HiFive Unleashed A00 board and it benefits
> > few seconds of average write time for entire flash write.
> >
> > QUAD Input Page Program operations:
> > > time mtd_debug write /dev/mtd0 0 33554432 rd32M
> > Copied 33554432 bytes from rd32M to address 0x in flash
> > real0m 32.85s
> > user0m 0.00s
> > sys 0m 31.79s
> >
> > Serial Input Page Program operations:
> > > time mtd_debug write /dev/mtd0 0 33554432 rd32M
> > Copied 33554432 bytes from rd32M to address 0x in flash
> > real0m 35.87s
> > user0m 0.00s
> > sys 0m 35.42s
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > ---
> > drivers/mtd/spi-nor/issi.c | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/mtd/spi-nor/issi.c b/drivers/mtd/spi-nor/issi.c
> > index ffcb60e..9eb6e82 100644
> > --- a/drivers/mtd/spi-nor/issi.c
> > +++ b/drivers/mtd/spi-nor/issi.c
> > @@ -23,6 +23,22 @@ is25lp256_post_bfpt_fixups(struct spi_nor *nor,
> > BFPT_DWORD1_ADDRESS_BYTES_3_ONLY)
> > nor->addr_width = 4;
> >
> > + /*
> > + * On IS25WP256d device 4-Byte address instruction table doesn't
> > + * get populated and so the device get's configured with 4-byte
> > + * Address Serial Input Page Program i.e. SNOR_PROTO_1_1_1 even
> > + * though it supports SNOR_PROTO_1_1_4, so priorotize QUAD write
> > + * over SINGLE write if device id table holds SPI_NOR_QUAD_READ.
> > + */
> > + if (strcmp(nor->info->name, "is25wp256") == 0) {
>
> Instead of doing this, wouldn't it make more sense to have a separate
> fixup hook for is25wp256? Does this device also need the above address
> width fixup? If it does, maybe that can be split into a separate
> function, and used by both the fixups?
>
Thanks for suggestion. Yes this device requires the above address width fixup.
I suspect that this QUAD mode fix might also be required for "is25lp256" device.
But since I don't have it on my board, I couldn't validate it. If someone could
give it a try
on "is25lp256" device and confirm this, then I guess we can remove this check
from
here "if (strcmp(nor->info->name, "is25wp256") == 0)" and rename the
is25lp256_post_bfpt_fixups
to is25lpwp256_post_bfpt_fixups to use command fixup for both flash devices,
else I am also ok to split it into separate function as suggested that can be
used by both fixup's
Thanks & BR,
Sagar Kadam
> > + if (nor->info->flags & SPI_NOR_QUAD_READ) {
> > + params->hwcaps.mask |= SNOR_HWCAPS_PP_1_1_4;
> > + spi_nor_set_pp_settings
> > + (>page_programs[SNOR_CMD_PP_1_1_4],
> > + SPINOR_OP_PP_1_1_4,
> > + SNOR_PROTO_1_1_4);
> > + }
> > + }
> > return 0;
> > }
>
> --
> Regards,
> Pratyush Yadav
RE: [PATCH v1 1/1] tty: serial: add missing spin_lock_init for SiFive serial console
Hello Greg and Palmer,
> -Original Message-
> From: Greg KH
> Sent: Wednesday, May 13, 2020 12:30 PM
> To: Palmer Dabbelt
> Cc: Sagar Kadam ; linux-ser...@vger.kernel.org;
> linux-ri...@lists.infradead.org; linux-kernel@vger.kernel.org; Paul Walmsley
> ; a...@eecs.berkeley.edu; Atish Patra
> ; Anup Patel
> Subject: Re: [PATCH v1 1/1] tty: serial: add missing spin_lock_init for SiFive
> serial console
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> On Tue, May 12, 2020 at 04:00:23PM -0700, Palmer Dabbelt wrote:
> > On Sat, 09 May 2020 03:24:12 PDT (-0700), sagar.ka...@sifive.com wrote:
> > > An uninitialised spin lock for sifive serial console raises a bad
> > > magic spin_lock error as reported and discussed here [1].
> > > Initialising the spin lock resolves the issue.
> > >
> > > The fix is tested on HiFive Unleashed A00 board with Linux 5.7-rc4
> > > and OpenSBI v0.7
> > >
> > > [1]
> > > https://lore.kernel.org/linux-riscv/b9fe49483a903f404e7acc15a6efbef7
> > > 56db28ae.ca...@wdc.com
> > >
> > > Fixes: 45c054d0815b ("tty: serial: add driver for the SiFive UART")
> > > Reported-by: Atish Patra
> > > Signed-off-by: Sagar Shrikant Kadam
> > > ---
> > > drivers/tty/serial/sifive.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/tty/serial/sifive.c
> > > b/drivers/tty/serial/sifive.c index 13eadcb..0b5110d 100644
> > > --- a/drivers/tty/serial/sifive.c
> > > +++ b/drivers/tty/serial/sifive.c
> > > @@ -883,6 +883,7 @@ console_initcall(sifive_console_init);
> > >
> > > static void __ssp_add_console_port(struct sifive_serial_port *ssp)
> > > {
> > > + spin_lock_init(>port.lock);
> > > sifive_serial_console_ports[ssp->port.line] = ssp; }
> >
> > Reviewed-by: Palmer Dabbelt
> > Acked-by: Palmer Dabbelt
> >
Thanks for the review.
> > I'm assuming it's going in through Greg's tree.
>
> Sure, I'll be glad to take it.
>
Thanks for accepting it within your tree.
BR,
Sagar Kadam
> greg k-h
RE: [RFC PATCH 4/4] dt-bindings: net: phy: extend dt binding for VSC8541 ethernet-phy
Hello Rob,
> -Original Message-
> From: Rob Herring
> Sent: Tuesday, May 12, 2020 7:42 AM
> To: Sagar Kadam
> Cc: linux-kernel@vger.kernel.org; linux-ri...@lists.infradead.org;
> pal...@dabbelt.com; Paul Walmsley ;
> atish.pa...@wdc.com; devicet...@vger.kernel.org
> Subject: Re: [RFC PATCH 4/4] dt-bindings: net: phy: extend dt binding for
> VSC8541 ethernet-phy
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> On Tue, Apr 28, 2020 at 04:16:48AM -0700, Sagar Shrikant Kadam wrote:
> > Adding a OUI (Organizationally Unique Identifier) for VSC8541-01
> > device to dt node requires a corresponding dt-binding entry as well
> > so that checkpatch doesn't complain with a warning:
> >
> > DT compatible string "ethernet-phy-id0007.0771" appears un-documented
> >
> > Here extend the existing dt binding of VSC8531 device to include
> > VSC8541 device example.
>
> Checkpatch.pl is just dumb here and can be ignored. We have the regex
> that documents this compatible. We don't need every VID/PID listed.
>
Thank you for the information.
We can then drop this patch to handle un-documented warning.
BR,
Sagar Kadam
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > ---
> > Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> > index 5ff37c6..774448a 100644
> > --- a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> > +++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> > @@ -68,3 +68,6 @@ Example:
> > vsc8531,led-0-mode = ;
> > vsc8531,led-1-mode = ;
> > };
> > +vsc8541_0: ethernet-phy@0 {
> > +compatible = "ethernet-phy-id0007.0771";
> > + };
> > --
> > 2.7.4
> >
RE: [PATCH 1/2] riscv: defconfig: enable spi nor on Hifive Unleashed A00 board.
Hi,
> -Original Message-
> From: Andreas Schwab
> Sent: Wednesday, May 6, 2020 12:57 PM
> To: Anup Patel
> Cc: Sagar Kadam ; Palmer Dabbelt
> ; vigne...@ti.com; tudor.amba...@microchip.com;
> rich...@nod.at; Paul Walmsley ; linux-
> ker...@vger.kernel.org; linux-...@lists.infradead.org;
> miquel.ray...@bootlin.com; linux-ri...@lists.infradead.org
> Subject: Re: [PATCH 1/2] riscv: defconfig: enable spi nor on Hifive Unleashed
> A00 board.
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> On Mai 06 2020, Anup Patel wrote:
>
Thanks for suggestions Anup and Andreas.
I missed to reply, sorry for that.
> > We had build issues in past by selecting major driver subsystems
> > in Kconfig.socs
> >
Please let me know if I am wrong, are you stating about the build issues, fixed
in
commit bd6f20333c67 ("RISC-V: Only select essential drivers for SOC_VIRT
config")
which was due to all platform dependent and independent driver's enabled in
Kconfig.soc
for virtual platform.
Kconfig.socs as meant for platform drivers we can guard SPI_SIFIVE with a guard
"if SPI"
so that come across " WARNING: unmet direct dependencies detected for
SPI_SIFIVE"
--- a/arch/riscv/Kconfig.socs
+++ b/arch/riscv/Kconfig.socs
@@ -7,6 +7,7 @@ config SOC_SIFIVE
select CLK_SIFIVE
select CLK_SIFIVE_FU540_PRCI
select SIFIVE_PLIC
+ imply SPI_SIFIVE if SPI
help
This enables support for SiFive SoC platform hardware.
> > I suggest to select SPI_SIFIVE from Kconfig.socs
>
> SPI_SIFIVE can be m, don't override that.
>
> Andreas.
>
Currently SPI and SPI_SIFIVE are default enabled via defconfig.
In Kconfig.socs if we force the config option using "select" SPI_SIFIVE will
lose its configurable option.
So I was thinking of using the weak dependency using "imply" as above, so that
SPI_SIFIVE can
still be modular if required i.e 'm'.
We can then have other platform independent driver's ( SPI, MTD and
MTD_SPI_NOR) required for
enabling SPI_NOR flash into the defconfig.
This way we can have SPI_SIFIVE in Kconfig.soc's and SPI_SIFIVE will also be
modular
Please let me know your views on this, or if I am missing something.
Thanks & BR,
Sagar Kadam
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA
> AEC1
> "And now for something completely different."
RE: [PATCH 1/2] riscv: defconfig: enable spi nor on Hifive Unleashed A00 board.
Hi Palmer, > -Original Message- > From: Palmer Dabbelt > Sent: Wednesday, May 6, 2020 4:54 AM > To: Sagar Kadam > Cc: tudor.amba...@microchip.com; miquel.ray...@bootlin.com; > rich...@nod.at; vigne...@ti.com; Paul Walmsley > ; linux-ri...@lists.infradead.org; linux- > ker...@vger.kernel.org; linux-...@lists.infradead.org > Subject: RE: [PATCH 1/2] riscv: defconfig: enable spi nor on Hifive Unleashed > A00 board. > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > On Tue, 05 May 2020 00:18:45 PDT (-0700), sagar.ka...@sifive.com wrote: > > Hello Palmer, > > > >> -Original Message- > >> From: Palmer Dabbelt > >> Sent: Tuesday, May 5, 2020 3:40 AM > >> To: Sagar Kadam > >> Cc: tudor.amba...@microchip.com; miquel.ray...@bootlin.com; > >> rich...@nod.at; vigne...@ti.com; Paul Walmsley > >> ; linux-ri...@lists.infradead.org; linux- > >> ker...@vger.kernel.org; linux-...@lists.infradead.org; Sagar Kadam > >> > >> Subject: Re: [PATCH 1/2] riscv: defconfig: enable spi nor on Hifive > Unleashed > >> A00 board. > >> > >> [External Email] Do not click links or attachments unless you recognize > the > >> sender and know the content is safe > >> > >> On Thu, 30 Apr 2020 02:58:51 PDT (-0700), sagar.ka...@sifive.com > wrote: > >> > Enable MTD based SPI-NOR framework in order to use spi flash > available > >> > on HiFive Unleashed A00 board. > >> > > >> > Signed-off-by: Sagar Shrikant Kadam > >> > --- > >> > arch/riscv/configs/defconfig | 2 ++ > >> > 1 file changed, 2 insertions(+) > >> > > >> > diff --git a/arch/riscv/configs/defconfig > >> > b/arch/riscv/configs/defconfig index 4da4886..970580b 100644 > >> > --- a/arch/riscv/configs/defconfig > >> > +++ b/arch/riscv/configs/defconfig > >> > @@ -80,6 +80,8 @@ CONFIG_USB_STORAGE=y CONFIG_USB_UAS=y > >> CONFIG_MMC=y > >> > CONFIG_MMC_SPI=y > >> > +CONFIG_MTD=y > >> > +CONFIG_MTD_SPI_NOR=y > >> > CONFIG_RTC_CLASS=y > >> > CONFIG_VIRTIO_PCI=y > >> > CONFIG_VIRTIO_BALLOON=y > >> > >> From the second patch's description I'm assuming that MTD still > functions > >> correctly without that change? > > > > Yes Palmer, the second patch is to enable QUAD write to nor flash.. > > MTD function's correctly without second patch. > > > > Using the character interface (/dev/mtd0) mtd_utils (mtd_debug : > erase/read/write) work fine. > > We might require CONFIG_MTD_BLOCK, CONFIG_MTD_CMDLINE_PARTS > in order to use MTD partitioning. > > IMHO it can be at user's choice weather to use flash partitions or not, so I > have not enabled. Please let me > > know if I should enable these features as well. > > Looks like arm64 has these: > > arch/arm64/configs/defconfig:CONFIG_MTD=y > arch/arm64/configs/defconfig:CONFIG_MTD_BLOCK=y > arch/arm64/configs/defconfig:CONFIG_MTD_CFI=y > arch/arm64/configs/defconfig:CONFIG_MTD_CFI_ADV_OPTIONS=y > arch/arm64/configs/defconfig:CONFIG_MTD_CFI_INTELEXT=y > arch/arm64/configs/defconfig:CONFIG_MTD_CFI_AMDSTD=y > arch/arm64/configs/defconfig:CONFIG_MTD_CFI_STAA=y > arch/arm64/configs/defconfig:CONFIG_MTD_PHYSMAP=y > arch/arm64/configs/defconfig:CONFIG_MTD_PHYSMAP_OF=y > arch/arm64/configs/defconfig:CONFIG_MTD_DATAFLASH=y > arch/arm64/configs/defconfig:CONFIG_MTD_SST25L=y > arch/arm64/configs/defconfig:CONFIG_MTD_RAW_NAND=y > arch/arm64/configs/defconfig:CONFIG_MTD_NAND_DENALI_DT=y > arch/arm64/configs/defconfig:CONFIG_MTD_NAND_MARVELL=y > arch/arm64/configs/defconfig:CONFIG_MTD_NAND_FSL_IFC=y > arch/arm64/configs/defconfig:CONFIG_MTD_NAND_QCOM=y > arch/arm64/configs/defconfig:CONFIG_MTD_SPI_NOR=y > > so I think we're good with just what you have here: MTD_BLOCK doesn't > seem that > useful, and the rest are drivers. That said, these (along with SPI and > SPI_SIFIVE) should really be in Kconfig.socs rather than defconfig. Can you > send a patch that does that? > Yes sure, I will send a V2 series, where SPI, SPI_SIFIVE, MTD, and MTD_SPI_NOR will be a part of Kconfig.socs. Thanks & BR, Sagar Kadam > > > > To demonstrate a bit more with linux 5.7-rc3 > > > > Specify on U-boot prompt: > > # setenv bootargs "root=/dev/ram rw console=ttySIF0 > mtdparts=spi0.0:1024k(loader1),4096K(loader2),26M(rootfs)" > > > > After booting linux will enumerate mtd partitions: > > # cat /proc/mtd > &g
RE: [PATCH 1/2] riscv: defconfig: enable spi nor on Hifive Unleashed A00 board.
Hello Palmer, > -Original Message- > From: Palmer Dabbelt > Sent: Tuesday, May 5, 2020 3:40 AM > To: Sagar Kadam > Cc: tudor.amba...@microchip.com; miquel.ray...@bootlin.com; > rich...@nod.at; vigne...@ti.com; Paul Walmsley > ; linux-ri...@lists.infradead.org; linux- > ker...@vger.kernel.org; linux-...@lists.infradead.org; Sagar Kadam > > Subject: Re: [PATCH 1/2] riscv: defconfig: enable spi nor on Hifive Unleashed > A00 board. > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > On Thu, 30 Apr 2020 02:58:51 PDT (-0700), sagar.ka...@sifive.com wrote: > > Enable MTD based SPI-NOR framework in order to use spi flash available > > on HiFive Unleashed A00 board. > > > > Signed-off-by: Sagar Shrikant Kadam > > --- > > arch/riscv/configs/defconfig | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/arch/riscv/configs/defconfig > > b/arch/riscv/configs/defconfig index 4da4886..970580b 100644 > > --- a/arch/riscv/configs/defconfig > > +++ b/arch/riscv/configs/defconfig > > @@ -80,6 +80,8 @@ CONFIG_USB_STORAGE=y CONFIG_USB_UAS=y > CONFIG_MMC=y > > CONFIG_MMC_SPI=y > > +CONFIG_MTD=y > > +CONFIG_MTD_SPI_NOR=y > > CONFIG_RTC_CLASS=y > > CONFIG_VIRTIO_PCI=y > > CONFIG_VIRTIO_BALLOON=y > > From the second patch's description I'm assuming that MTD still functions > correctly without that change? Yes Palmer, the second patch is to enable QUAD write to nor flash.. MTD function's correctly without second patch. Using the character interface (/dev/mtd0) mtd_utils (mtd_debug : erase/read/write) work fine. We might require CONFIG_MTD_BLOCK, CONFIG_MTD_CMDLINE_PARTS in order to use MTD partitioning. IMHO it can be at user's choice weather to use flash partitions or not, so I have not enabled. Please let me know if I should enable these features as well. To demonstrate a bit more with linux 5.7-rc3 Specify on U-boot prompt: # setenv bootargs "root=/dev/ram rw console=ttySIF0 mtdparts=spi0.0:1024k(loader1),4096K(loader2),26M(rootfs)" After booting linux will enumerate mtd partitions: # cat /proc/mtd dev:size erasesize name mtd0: 0010 1000 "loader1" mtd1: 0040 1000 "loader2" mtd2: 01a0 1000 "rootfs" # cat /proc/partitions major minor #blocks name 310 1024 mtdblock0 311 4096 mtdblock1 312 26624 mtdblock2 #Format mtdblock2 with mkfs.ext3/4 and mount results in # mkfs.ext3 /dev/mtdblock2 mke2fs 1.44.5 (15-Dec-2018) /dev/mtdblock2 contains a ext3 file system last mounted on /mnt on Thu Jan 1 00:00:14 1970 Proceed anyway? (y,N) y Creating filesystem with 26624 1k blocks and 6656 inodes Filesystem UUID: 1b09252d-e313-430c-9ecb-79b0cef003ca Superblock backups stored on blocks: 8193, 24577 Allocating group tables: done Writing inode tables: done Creating journal (1024 blocks): done Writing superblocks and filesystem accounting information: done # mount none on / type rootfs (rw) proc on /proc type proc (rw,relatime) devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=666) tmpfs on /dev/shm type tmpfs (rw,relatime,mode=777) tmpfs on /tmp type tmpfs (rw,relatime) tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755) sysfs on /sys type sysfs (rw,relatime) /dev/mtdblock2 on /mnt type ext3 (rw,relatime) Thanks & BR, Sagar Kadam
Re: [PATCH v9 0/2] mtd: spi-nor: add support for is25wp256 spi-nor flash
Hi,
On Wed, Sep 18, 2019 at 9:32 PM Sagar Shrikant Kadam
wrote:
>
> The patch series adds basic support for 32MiB spi-nor is25wp256 present on
> HiFive
> Unleashed A00 board. The flash device gets BFPT_DWORD1_ADDRESS_BYTES_3_ONLY
> from BFPT table for address width, whereas the flash can support 4 byte
> address width, so the address width is configured by using the post bfpt
> fixup hook as done for is25lp256 device in
> commit cf580a924005 ("mtd: spi-nor: fix nor->addr_width when its value
> configured from SFDP does not match the actual width")
>
> Patches are based on original work done by Wesley Terpstra and/or
> Palmer Dabbelt:
> https://github.com/riscv/riscv-linux/commit/c94e267766d62bc9a669611c3d0c8ed5ea26569b
>
> Erase/Read/Write operations are verified on HiFive Unleashed board using mtd
> and
> flash utils (v1.5.2):
> 1. mtd_debug: Options available are : erase/read/write.
> 2. flashcp : Single utility that erases flash, writes a file to flash
> and verifies the data back.
>
> The changes are available under branch dev/sagark/spi-nor-v9 at
> https://github.com/sagsifive/riscv-linux-hifive
>
> Revision history:
> V8<->V9:
> -Rebased this series to mainline v5.3-rc8
> -Corrected number of sectors in the spi nor id table for is25wp256 device as
> suggested in the review.
> -The lock/unlock scheme in the V8 version of this series needs to have a more
> generic approach.
> These protection scheme patches are not included in this series, will submit
> those separately.
>
A gentle reminder!!
Any comments on this series?
Thanks & BR,
Sagar Kadam
> V7<->V8:
> -Rebased this series on mainline v5.3-rc4.
> -Removed remaining func_reg reference from issi_lock as updating OTP region
> was dropped as part of V6.
> -Updated Reviewed-By tags to 1st and 2nd patch.
>
> V6<->V7:
> -Incorporated review comments from Vignesh.
> -Used post bfpt fixup hook as suggested by Vignesh.
> -Introduce SPI_NOR_HAS_BP3 to identify whether the flash has 4th bit protect
> bit.
> -Prefix generic flash access functions with spi_nor_.
>
> V5<->V6:
> -Incorporated review comments from Vignesh.
> -Set addr width based on device size and if SPI_NOR_4B_OPCODES is set.
> -Added 4th block protect identifier (SPI_NOR_HAS_BP3) to flash_info structure
> -Changed flash_info: flag from u16 to u32 to accommodate SPI_NOR_HAS_BP3
> -Prefix newly added function with spi_nor_xxx.
> -Dropped write_fr function, as updating OTP bit's present in function
> register doesn't seem to be a good idea.
> -Set lock/unlock schemes based on whether the ISSI device has locking support
> and BP3 bit present.
>
> V4<->V5:
> -Rebased to linux version v5.2-rc1.
> -Updated heading of this cover letter with sub-system, instead of just plain
> "add support for is25wp256..."
>
> V3<->V4:
> -Extracted comman code and renamed few stm functions so that it can be reused
> for issi lock implementation.
> -Added function's to read and write FR register, for selecting Top/Bottom
> area.
>
> V2<->V3:
> -Rebased patch to mainline v5.1 from earlier v5.1-rc5.
> -Updated commit messages, and cover letter with reference to git URL and
> author information.
> -Deferred flash_lock mechanism and can go as separate patch.
>
> V1<-> V2:
> -Incorporated changes suggested by reviewers regarding patch/cover letter
> versioning, references of patch.
> -Updated cover letter with description for flash operations verified with
> these changes.
> -Add support for unlocking is25xx device.
> -Add support for locking is25xx device.
>
> v1:
> -Add support for is25wp256 device.
>
> Sagar Shrikant Kadam (2):
> mtd: spi-nor: add support for is25wp256
> mtd: spi-nor: fix nor->addr_width for is25wp256
>
> drivers/mtd/spi-nor/spi-nor.c | 9 -
> include/linux/mtd/spi-nor.h | 1 +
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> --
> 1.9.1
>
Re: [PATCH v8 1/4] mtd: spi-nor: add support for is25wp256
Hi Bin,
On Mon, Aug 26, 2019 at 2:49 AM Bin Meng wrote:
>
> On Tue, Aug 13, 2019 at 8:40 PM Sagar Shrikant Kadam
> wrote:
> >
> > Update spi_nor_id table for is25wp256 (32MB) device from ISSI,
> > present on HiFive Unleashed dev board (Rev: A00).
> >
> > Set method to enable quad mode for ISSI device in flash parameters
> > table.
> >
> > Based on code originally written by Wesley Terpstra
> > and/or Palmer Dabbelt
> > https://github.com/riscv/riscv-linux/commit/c94e267766d62bc9a669611c3d0c8ed5ea26569b
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > Reviewed-by: Vignesh Raghavendra
> > ---
> > drivers/mtd/spi-nor/spi-nor.c | 9 -
> > include/linux/mtd/spi-nor.h | 1 +
> > 2 files changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> > index 03cc788..6635127 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -1946,7 +1946,10 @@ static int spi_nor_spansion_clear_sr_bp(struct
> > spi_nor *nor)
> > SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > { "is25wp128", INFO(0x9d7018, 0, 64 * 1024, 256,
> > SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > -
> > + { "is25wp256", INFO(0x9d7019, 0, 64 * 1024, 1024,
>
> The sector number should be 512, not 1024.
Thanks for pointing this out.
I had rectified it in recent U-boot patchset here
https://patchwork.ozlabs.org/patch/1146522/
but I missed the change in the linux one as it was sent earlier.
I will include this change in the next version of the patch
Thanks & BR,
Sagar
>
> > + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
> > + SPI_NOR_4B_OPCODES)
> > + },
> > /* Macronix */
> > { "mx25l512e", INFO(0xc22010, 0, 64 * 1024, 1, SECT_4K) },
> > { "mx25l2005a", INFO(0xc22012, 0, 64 * 1024, 4, SECT_4K) },
> > @@ -3776,6 +3779,10 @@ static int spi_nor_init_params(struct spi_nor *nor,
> > case SNOR_MFR_ST:
> > case SNOR_MFR_MICRON:
> > break;
> > + case SNOR_MFR_ISSI:
> > + params->quad_enable = macronix_quad_enable;
> > + break;
> > +
> >
> > default:
> > /* Kept only for backward compatibility purpose. */
> > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> > index 9f57cdf..5d6583e 100644
> > --- a/include/linux/mtd/spi-nor.h
> > +++ b/include/linux/mtd/spi-nor.h
> > @@ -21,6 +21,7 @@
> > #define SNOR_MFR_INTEL CFI_MFR_INTEL
> > #define SNOR_MFR_STCFI_MFR_ST /* ST Micro */
> > #define SNOR_MFR_MICRONCFI_MFR_MICRON /* Micron */
> > +#define SNOR_MFR_ISSI 0x9d/* ISSI */
> > #define SNOR_MFR_MACRONIX CFI_MFR_MACRONIX
> > #define SNOR_MFR_SPANSION CFI_MFR_AMD
> > #define SNOR_MFR_SST CFI_MFR_SST
>
> Regards,
> Bin
Re: [PATCH v7 2/4] mtd: spi-nor: fix nor->addr_width for is25wp256
Hi Vignesh,
On Fri, Aug 9, 2019 at 5:05 PM Vignesh Raghavendra wrote:
>
>
>
> On 03/07/19 12:09 AM, Sagar Shrikant Kadam wrote:
> > Use the post bfpt fixup hook for the is25wp256 device as done for
> > is25lp256 device to overwrite the address width advertised by BFPT.
> >
> > For instance the standard devices eg: IS25WP256D-JMLE where J stands
> > for "standard" does not support SFDP.
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > ---
>
> Reviewed-by: Vignesh Raghavendra
>
Thankyou for reviewing.
BR,
Sagar
> > drivers/mtd/spi-nor/spi-nor.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> > index 971f0f3..315eeec 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -1860,7 +1860,7 @@ static int sr2_bit7_quad_enable(struct spi_nor *nor)
> > { "is25wp256", INFO(0x9d7019, 0, 64 * 1024, 1024,
> > SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
> > SPI_NOR_4B_OPCODES)
> > - },
> > + .fixups = _fixups },
> > /* Macronix */
> > { "mx25l512e", INFO(0xc22010, 0, 64 * 1024, 1, SECT_4K) },
> > { "mx25l2005a", INFO(0xc22012, 0, 64 * 1024, 4, SECT_4K) },
> >
>
> --
> Regards
> Vignesh
Re: [PATCH v7 4/4] mtd: spi-nor: add locking support for is25wp256 device
Hello Vignesh,
On Fri, Aug 9, 2019 at 4:57 PM Vignesh Raghavendra wrote:
>
> Hi Sagar,
>
> On 03/07/19 12:09 AM, Sagar Shrikant Kadam wrote:
> [...]> +static int issi_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
> > +{
> > + int status_old, status_new, blk_prot;
> > + u8 mask;
> > + u8 shift;
> > + u8 pow, ret, func_reg;
> > + bool use_top;
> > + loff_t lock_len;
> > +
> > + if (nor->flags & SNOR_F_HAS_BP3)
> > + mask = SR_BP3 | SR_BP2 | SR_BP1 | SR_BP0;
> > + else
> > + mask = SR_BP2 | SR_BP1 | SR_BP0;
> > +
> > + shift = ffs(mask) - 1;
> > +
> > + status_old = read_sr(nor);
> > +
> > + /* if status reg is Write protected don't update bit protection */
> > + if (status_old & SR_SRWD) {
> > + dev_err(nor->dev,
> > + "SR is write protected, can't update BP bits...\n");
> > + return -EINVAL;
> > + }
> > +
> > + ret = spi_nor_select_zone(nor, ofs, len, status_old, _top, 1);
> > + if (!ret)
> > + /* Older protected blocks include the new requested block's */
> > + return 0;
> > + else if (ret < 0)
> > + return ret;
> > +
> > + func_reg = spi_nor_read_fr(nor);
>
Thank you for reviewing the patch.
> Sorry, I don't understand where func_reg is used? Since TBS OTP, how
> does issi_lock() code comprehend that TBS bit value in OTP register and
> use_top returned by spi_nor_select_zone() are matching before we go
> ahead and program status register.
>
In my earlier version of this patch, you had suggested an approach to skip
updating the TBS OTP bits as ones written that cannot be changed.
Actually, func_reg was used to update the OTP section, sorry I missed
removing the func_reg reference here as per your suggestion.
I will update a new version of this patch which will not modify the OTP
region and will return with an error when locking the requested region by
the user is not possible.
> We should reject locking request if top-bottom calculation does not
> match OTP bit. Where is that done?
>
> Regards
> Vignesh
>
Thanks & BR,
Sagar
> > + /* lock_len: length of region that should end up locked */
> > + if (use_top)
> > + lock_len = nor->mtd.size - ofs;
> > + else
> > + lock_len = ofs + len;
> > +
> > + pow = order_base_2(lock_len);
> > + blk_prot = mask & (((pow + 1) & 0xf) << shift);
> > + if (lock_len <= 0) {
> > + dev_err(nor->dev, "invalid Length to protect");
> > + return -EINVAL;
> > + }
> > +
> > + status_new = status_old | blk_prot;
> > + if (status_old == status_new)
> > + return 0;
> > +
> > + return write_sr_and_check(nor, status_new, mask);
> > +}
> > +
> > +/**
> > * issi_unlock() - clear BP[0123] write-protection.
> > * @nor: pointer to a 'struct spi_nor'.
> > * @ofs: offset from which to unlock memory.
> > @@ -4171,6 +4338,7 @@ int spi_nor_scan(struct spi_nor *nor, const char
> > *name,
> > if (JEDEC_MFR(info) == SNOR_MFR_ISSI &&
> > info->flags & SPI_NOR_HAS_LOCK &&
> > info->flags & SPI_NOR_HAS_BP3) {
> > + nor->flash_lock = issi_lock;
> > nor->flash_unlock = issi_unlock;
> > }
> >
> > @@ -4194,6 +4362,8 @@ int spi_nor_scan(struct spi_nor *nor, const char
> > *name,
> > nor->flags |= SNOR_F_NO_OP_CHIP_ERASE;
> > if (info->flags & USE_CLSR)
> > nor->flags |= SNOR_F_USE_CLSR;
> > + if (info->flags & SPI_NOR_HAS_BP3)
> > + nor->flags |= SNOR_F_HAS_BP3;
> >
> > if (info->flags & SPI_NOR_NO_ERASE)
> > mtd->flags |= MTD_NO_ERASE;
> > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> > index f6fa70f..26dbf48 100644
> > --- a/include/linux/mtd/spi-nor.h
> > +++ b/include/linux/mtd/spi-nor.h
> > @@ -40,6 +40,8 @@
> > #define SPINOR_OP_RDSR 0x05/* Read status register */
> > #define SPINOR_OP_WRSR 0x01/* Write status register 1
> > byte */
> > #define SPINOR_OP_RDSR2 0x3f/* Read status register 2 */
> > +#define SPINOR_OP_RDFR 0x48/* Read Function register */
> > +#define SPINOR_OP_WRFR 0x42/* Write Function register 1
> > byte */
> > #define SPINOR_OP_WRSR2 0x3e/* Write status register 2 */
> > #define SPINOR_OP_READ 0x03/* Read data bytes (low
> > frequency) */
> > #define SPINOR_OP_READ_FAST 0x0b/* Read data bytes (high frequency) */
> > @@ -139,6 +141,9 @@
> > /* Enhanced Volatile Configuration Register bits */
> > #define EVCR_QUAD_EN_MICRON BIT(7) /* Micron Quad I/O */
> >
> > +/*Function register bit */
> > +#define FR_TBBIT(1) /*ISSI: Top/Bottom protect */
> > +
> > /* Flag Status Register bits */
> > #define FSR_READYBIT(7) /* Device status, 0 = Busy, 1 = Ready
> > */
> > #define
Re: [PATCH 3/3] riscv: dts: Add DT node for SiFive FU540 Ethernet controller driver
Hello Andrew,
On Fri, Jul 19, 2019 at 6:57 PM Andrew Lunn wrote:
>
> On Fri, Jul 19, 2019 at 05:23:45PM +0530, Sagar Kadam wrote:
> > > + {
> > > + status = "okay";
> > > + phy-mode = "gmii";
> > > + phy-handle = <>;
> > > + phy1: ethernet-phy@0 {
> > > + reg = <0>;
> > > + };
>
> Hi Sagar
>
> Is there a good reason to call it phy1? Is there a phy0?
>
Sorry for the delayed response.
There is a single phy, so yes phy0 is a better name.
Thank you for pointing this out.
Thanks & Regards,
Sagar Kadam
> Thanks
>
>Andrew
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [PATCH 3/3] riscv: dts: Add DT node for SiFive FU540 Ethernet controller driver
The series looks good to me.
Reviewed-by: Sagar Kadam
On Fri, Jul 19, 2019 at 4:41 PM Yash Shah wrote:
>
> DT node for SiFive FU540-C000 GEMGXL Ethernet controller driver added
>
> Signed-off-by: Yash Shah
> ---
> arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 15 +++
> arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts | 9 +
> 2 files changed, 24 insertions(+)
>
> diff --git a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
> b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
> index cc73522..588669f0 100644
> --- a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
> +++ b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
> @@ -231,5 +231,20 @@
> #size-cells = <0>;
> status = "disabled";
> };
> + eth0: ethernet@1009 {
> + compatible = "sifive,fu540-c000-gem";
> + interrupt-parent = <>;
> + interrupts = <53>;
> + reg = <0x0 0x1009 0x0 0x2000
> + 0x0 0x100a 0x0 0x1000>;
> + local-mac-address = [00 00 00 00 00 00];
> + clock-names = "pclk", "hclk";
> + clocks = < PRCI_CLK_GEMGXLPLL>,
> +< PRCI_CLK_GEMGXLPLL>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> };
> };
> diff --git a/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
> b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
> index 0b55c53..85c17a7 100644
> --- a/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
> +++ b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
> @@ -76,3 +76,12 @@
> disable-wp;
> };
> };
> +
> + {
> + status = "okay";
> + phy-mode = "gmii";
> + phy-handle = <>;
> + phy1: ethernet-phy@0 {
> + reg = <0>;
> + };
> +};
> --
> 1.9.1
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [PATCH v7 0/4] mtd: spi-nor: add support for is25wp256 spi-nor flash
Hi Tudor, On Mon, Jul 15, 2019 at 4:35 PM wrote: > > > > On 07/15/2019 01:45 PM, Sagar Kadam wrote: > > Hi All, > > > > Any comments on this series? > > > > Hi, Sagar, > > I was OOO the last 2 weeks and previously I was busy with other spi-nor > patches. > The series is in my queue, I'll review it. You can check the status of a mtd > patch by looking in https://patchwork.ozlabs.org/project/linux-mtd/list/ > > Cheers, > ta Thank you for queuing it for review and sharing the link. I will follow-up on patchwork. BR, Sagar Kadam
Re: [PATCH v7 0/4] mtd: spi-nor: add support for is25wp256 spi-nor flash
On Wed, Jul 3, 2019 at 12:10 AM Sagar Shrikant Kadam
wrote:
>
> The patch series adds support for 32MiB spi-nor is25wp256 present on HiFive
> Unleashed A00 board. The flash device gets BFPT_DWORD1_ADDRESS_BYTES_3_ONLY
> from BFPT table for address width, whereas the flash can support 4 byte
> address width, so the address width is configured by using the post bfpt
> fixup hook as done for is25lp256 device in
> commit cf580a924005 ("mtd: spi-nor: fix nor->addr_width when its value
> configured from SFDP does not match the actual width") queued in
> spi-nor/next branch [1].
>
> Patches 1 and 3 are based on original work done by Wesley Terpstra and/or
> Palmer Dabbelt:
> https://github.com/riscv/riscv-linux/commit/c94e267766d62bc9a669611c3d0c8ed5ea26569b
>
> Erase/Read/Write operations are verified on HiFive Unleashed board using mtd
> and
> flash utils (v1.5.2):
> 1. mtd_debug: Options available are : erase/read/write.
> 2. flashcp : Single utility that erases flash, writes a file to flash
> and verifies the data back.
> 3. flash_unlock : Unlock flash memory blocks. Arguments: are offset and
> number of blocks.
> 3. flash_lock : Lock flash memory blocks. Arguments: are offset and number
> of blocks.
>
> The Unlock scheme clears the protection bits of all blocks in the Status
> register.
>
> Lock scheme:
> A basic implementation based on the stm_lock scheme and is validated for a
> different
> number of blocks passed to flash_lock. ISSI devices have top/bottom area
> selection
> in function register which is OTP memory. so we are not updating the OTP
> section
> of function register.
>
> The changes along are available under branch v5.2-rc1-mtd-spi-nor/next at:
> https://github.com/sagsifive/riscv-linux-hifive
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git/log/?h=spi-nor/next
>
> Revision history:
> V6<->V7:
> -Incorporated review comments from Vignesh.
> -Used post bfpt fixup hook as suggested by Vignesh.
> -Introduce SPI_NOR_HAS_BP3 to identify whether the flash has 4th bit protect
> bit.
> -Prefix generic flash access functions with spi_nor_.
>
> V5<->V6:
> -Incorporated review comments from Vignesh.
> -Set addr width based on device size and if SPI_NOR_4B_OPCODES is set.
> -Added 4th block protect identifier (SPI_NOR_HAS_BP3) to flash_info structure
> -Changed flash_info: flag from u16 to u32 to accommodate SPI_NOR_HAS_BP3
> -Prefix newly added function with spi_nor_xxx.
> -Dropped write_fr function, as updating OTP bit's present in function
> register doesn't seem to be a good idea.
> -Set lock/unlock schemes based on whether the ISSI device has locking support
> and BP3 bit present.
>
> V4<->V5:
> -Rebased to linux version v5.2-rc1.
> -Updated heading of this cover letter with sub-system, instead of just plain
> "add support for is25wp256..."
>
> V3<->V4:
> -Extracted comman code and renamed few stm functions so that it can be reused
> for issi lock implementation.
> -Added function's to read and write FR register, for selecting Top/Bottom
> area.
>
> V2<->V3:
> -Rebased patch to mainline v5.1 from earlier v5.1-rc5.
> -Updated commit messages, and cover letter with reference to git URL and
> author information.
> -Deferred flash_lock mechanism and can go as separate patch.
>
> V1<-> V2:
> -Incorporated changes suggested by reviewers regarding patch/cover letter
> versioning, references of patch.
> -Updated cover letter with description for flash operations verified with
> these changes.
> -Add support for unlocking is25xx device.
> -Add support for locking is25xx device.
>
> v1:
> -Add support for is25wp256 device.
>
> Sagar Shrikant Kadam (4):
> mtd: spi-nor: add support for is25wp256
> mtd: spi-nor: fix nor->addr_width for is25wp256
> mtd: spi-nor: add support to unlock the flash device
> mtd: spi-nor: add locking support for is25wp256 device
>
> drivers/mtd/spi-nor/spi-nor.c | 343
> +++---
> include/linux/mtd/spi-nor.h | 8 +
> 2 files changed, 300 insertions(+), 51 deletions(-)
>
> --
> 1.9.1
>
Hi All,
Any comments on this series?
BR,
Sagar Kadam
Re: [PATCH v5 1/3] mtd: spi-nor: add support for is25wp256
Hi Vignesh,
On Mon, Jun 24, 2019 at 6:37 PM Vignesh Raghavendra wrote:
>
>
>
> On 24/06/19 6:10 PM, Sagar Kadam wrote:
> > Hello Vignesh,
> >
> > On Mon, Jun 24, 2019 at 3:04 PM Vignesh Raghavendra wrote:
> >>
> >> Hi,
> >>
> >> On 21/06/19 3:58 PM, Sagar Kadam wrote:
> >>> Hello Vignesh,
> >>>
> >>> On Fri, Jun 21, 2019 at 11:33 AM Vignesh Raghavendra
> >>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> On 17/06/19 8:48 PM, Sagar Kadam wrote:
> >>>>> Hello Vignesh,
> >>>>>
> >>>>> Thanks for your review comments.
> >>>>>
> >>>>> On Sun, Jun 16, 2019 at 6:14 PM Vignesh Raghavendra
> >>>>> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> On 12-Jun-19 4:17 PM, Sagar Shrikant Kadam wrote:
> >>>>>> [...]
> >>>>>>
> >>>>>>> @@ -4129,7 +4137,7 @@ int spi_nor_scan(struct spi_nor *nor, const
> >>>>>>> char *name,
> >>>>>>> if (ret)
> >>>>>>> return ret;
> >>>>>>>
> >>>>>>> - if (nor->addr_width) {
> >>>>>>> + if (nor->addr_width && JEDEC_MFR(info) != SNOR_MFR_ISSI) {
> >>>>>>> /* already configured from SFDP */
> >>>>>>
> >>>>>> Hmm, why would you want to ignore addr_width that's read from SFDP
> >>>>>> table?
> >>>>>
> >>>>> The SFDP table for ISSI device considered here, has addr_width set to
> >>>>> 3 byte, and the flash considered
> >>>>> here is 32MB. With 3 byte address width we won't be able to access
> >>>>> flash memories higher address range.
> >>>>
> >>>> Is it specific to a particular ISSI part as indicated here[1]? If so,
> >>>> please submit solution agreed there i.e. use spi_nor_fixups callback
> >>>>
> >>>> [1]https://patchwork.ozlabs.org/patch/1056049/
> >>>>
> >>>
> >>> Thanks for sharing the link.
> >>> From what I understand here, it seems that "Address Bytes" of SFDP
> >>> table for the device under
> >>> consideration (is25lp256) supports 3 byte only Addressing mode
> >>> (DWORD1[18:17] = 0b00.
> >>> where as that of ISSI device (is25LP/WP 256Mb/512/Mb/1Gb) support 3 or
> >>> 4 byte Addressing mode DWORD1[18:17] = 0b01.
> >>>
> >>
> >> Okay, so that SFDP table entry is correct. SPI NOR framework should
> >> using 4 byte addressing if WORD1[18:17] = 0b01. Could you see if below
> >> diff helps:
> >>
> > Thank-you for the suggestion.
> > I applied it, and observed, that data in SFDP table mentioned in
> > document received
> > from ISSI support doesn't match with what is actually present on the
> > device (I have raised a query with issi support for the same)
> > The WP device also has the same SFDP entry as the LP device (the one
> > which you shared).
> > So, will submit V7 with the solution agreed in the link you shared above.
> > https://patchwork.ozlabs.org/patch/1056049/
> > Apologies for the confusion, so please excuse the v6 which I submitted
> > earlier.
> >
>
> There is an updated version of the patch:
> https://patchwork.ozlabs.org/patch/1071453/
>
> You may want to align with Liu Xiang to avoid duplication of effort
>
Ok. It seems Liu Xiang, is working on supporting is25LP256 device,
while the one considered here is WP
Although both are very similar devices, they differ a bit maybe with
Operating voltage, ID values, die revision etc..
I will sync-up with him about his v4 plan, and update you accordingly.
Thanks for the link.
BR,
Sagar Kadam
> > Thanks & BR,
> > Sagar Kadam
> >
> >> --->8---
> >> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> >> index c0a8837c0575..ebf32aebe5e9 100644
> >> --- a/drivers/mtd/spi-nor/spi-nor.c
> >> +++ b/drivers/mtd/spi-nor/spi-nor.c
> >> @@ -2808,6 +2808,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
> >> break;
> >>
> >> case BFPT_DWORD1_ADDRESS_BYTES_4_ONLY:
> >> + case BFPT_DWORD1_ADDRESS_BYTES_3_OR_4:
> >> nor->addr_width = 4;
> >> break;
> >
> >
> >>
> >>
> >>
> >>
> >> --
> >> Regards
> >> Vignesh
>
> --
> Regards
> Vignesh
Re: [PATCH v5 1/3] mtd: spi-nor: add support for is25wp256
Hello Vignesh,
On Mon, Jun 24, 2019 at 3:04 PM Vignesh Raghavendra wrote:
>
> Hi,
>
> On 21/06/19 3:58 PM, Sagar Kadam wrote:
> > Hello Vignesh,
> >
> > On Fri, Jun 21, 2019 at 11:33 AM Vignesh Raghavendra
> > wrote:
> >>
> >> Hi,
> >>
> >> On 17/06/19 8:48 PM, Sagar Kadam wrote:
> >>> Hello Vignesh,
> >>>
> >>> Thanks for your review comments.
> >>>
> >>> On Sun, Jun 16, 2019 at 6:14 PM Vignesh Raghavendra
> >>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> On 12-Jun-19 4:17 PM, Sagar Shrikant Kadam wrote:
> >>>> [...]
> >>>>
> >>>>> @@ -4129,7 +4137,7 @@ int spi_nor_scan(struct spi_nor *nor, const char
> >>>>> *name,
> >>>>> if (ret)
> >>>>> return ret;
> >>>>>
> >>>>> - if (nor->addr_width) {
> >>>>> + if (nor->addr_width && JEDEC_MFR(info) != SNOR_MFR_ISSI) {
> >>>>> /* already configured from SFDP */
> >>>>
> >>>> Hmm, why would you want to ignore addr_width that's read from SFDP table?
> >>>
> >>> The SFDP table for ISSI device considered here, has addr_width set to
> >>> 3 byte, and the flash considered
> >>> here is 32MB. With 3 byte address width we won't be able to access
> >>> flash memories higher address range.
> >>
> >> Is it specific to a particular ISSI part as indicated here[1]? If so,
> >> please submit solution agreed there i.e. use spi_nor_fixups callback
> >>
> >> [1]https://patchwork.ozlabs.org/patch/1056049/
> >>
> >
> > Thanks for sharing the link.
> > From what I understand here, it seems that "Address Bytes" of SFDP
> > table for the device under
> > consideration (is25lp256) supports 3 byte only Addressing mode
> > (DWORD1[18:17] = 0b00.
> > where as that of ISSI device (is25LP/WP 256Mb/512/Mb/1Gb) support 3 or
> > 4 byte Addressing mode DWORD1[18:17] = 0b01.
> >
>
> Okay, so that SFDP table entry is correct. SPI NOR framework should
> using 4 byte addressing if WORD1[18:17] = 0b01. Could you see if below
> diff helps:
>
Thank-you for the suggestion.
I applied it, and observed, that data in SFDP table mentioned in
document received
from ISSI support doesn't match with what is actually present on the
device (I have raised a query with issi support for the same)
The WP device also has the same SFDP entry as the LP device (the one
which you shared).
So, will submit V7 with the solution agreed in the link you shared above.
https://patchwork.ozlabs.org/patch/1056049/
Apologies for the confusion, so please excuse the v6 which I submitted earlier.
Thanks & BR,
Sagar Kadam
> --->8---
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index c0a8837c0575..ebf32aebe5e9 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -2808,6 +2808,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
> break;
>
> case BFPT_DWORD1_ADDRESS_BYTES_4_ONLY:
> + case BFPT_DWORD1_ADDRESS_BYTES_3_OR_4:
> nor->addr_width = 4;
> break;
>
>
>
>
> --
> Regards
> Vignesh
Re: [PATCH v5 1/3] mtd: spi-nor: add support for is25wp256
Hello Vignesh,
On Fri, Jun 21, 2019 at 11:33 AM Vignesh Raghavendra wrote:
>
> Hi,
>
> On 17/06/19 8:48 PM, Sagar Kadam wrote:
> > Hello Vignesh,
> >
> > Thanks for your review comments.
> >
> > On Sun, Jun 16, 2019 at 6:14 PM Vignesh Raghavendra wrote:
> >>
> >> Hi,
> >>
> >> On 12-Jun-19 4:17 PM, Sagar Shrikant Kadam wrote:
> >> [...]
> >>
> >>> @@ -4129,7 +4137,7 @@ int spi_nor_scan(struct spi_nor *nor, const char
> >>> *name,
> >>> if (ret)
> >>> return ret;
> >>>
> >>> - if (nor->addr_width) {
> >>> + if (nor->addr_width && JEDEC_MFR(info) != SNOR_MFR_ISSI) {
> >>> /* already configured from SFDP */
> >>
> >> Hmm, why would you want to ignore addr_width that's read from SFDP table?
> >
> > The SFDP table for ISSI device considered here, has addr_width set to
> > 3 byte, and the flash considered
> > here is 32MB. With 3 byte address width we won't be able to access
> > flash memories higher address range.
>
> Is it specific to a particular ISSI part as indicated here[1]? If so,
> please submit solution agreed there i.e. use spi_nor_fixups callback
>
> [1]https://patchwork.ozlabs.org/patch/1056049/
>
Thanks for sharing the link.
>From what I understand here, it seems that "Address Bytes" of SFDP
table for the device under
consideration (is25lp256) supports 3 byte only Addressing mode
(DWORD1[18:17] = 0b00.
where as that of ISSI device (is25LP/WP 256Mb/512/Mb/1Gb) support 3 or
4 byte Addressing mode DWORD1[18:17] = 0b01.
> > Hence I have ignored the addr width from SFDP. I have verified that
> > with 3 byte address width, the
> > flascp util fails while verifying the written data. Please let me
> > know your views on this?
> >
> If this affects multiple ISSI parts then:
> Instead of checking for mfr code, look for SNOR_F_4B_OPCODES flag in
> flash_info struct of the device and let it take precedence over SFDP in
> case size is over 16MB
>
So as per your suggestion I think second approach is a better one.
I will send this in V6.
Thanks & Regards,
Sagar
> Regards
> Vignesh
>
> > BR,
> > Sagar Kadam
> >
> >> Regards
> >> Vignesh
> >>
> >>
> >>> } else if (info->addr_width) {
> >>> nor->addr_width = info->addr_width;
> >>> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> >>> index b3d360b..ff13297 100644
> >>> --- a/include/linux/mtd/spi-nor.h
> >>> +++ b/include/linux/mtd/spi-nor.h
> >>> @@ -19,6 +19,7 @@
> >>> #define SNOR_MFR_ATMEL CFI_MFR_ATMEL
> >>> #define SNOR_MFR_GIGADEVICE 0xc8
> >>> #define SNOR_MFR_INTEL CFI_MFR_INTEL
> >>> +#define SNOR_MFR_ISSI0x9d/* ISSI */
> >>> #define SNOR_MFR_ST CFI_MFR_ST /* ST Micro */
> >>> #define SNOR_MFR_MICRON CFI_MFR_MICRON /* Micron */
> >>> #define SNOR_MFR_MACRONIXCFI_MFR_MACRONIX
> >>>
>
> --
> Regards
> Vignesh
Re: [PATCH v5 3/3] mtd: spi-nor: add locking support for is25xxxxx device
se;
> > -
> > - if (!can_be_bottom && !can_be_top)
> > - return -EINVAL;
> > -
> > - /* Prefer top, if both are valid */
> > - use_top = can_be_top;
> > -
> > - /* lock_len: length of region that should remain locked */
> > + /* lock_len: length of region that should end up locked */
> > if (use_top)
> > lock_len = mtd->size - (ofs + len);
> > else
> > @@ -1338,7 +1455,7 @@ static int stm_unlock(struct spi_nor *nor, loff_t
> > ofs, uint64_t len)
> > * Returns 1 if entire region is locked, 0 if any portion is unlocked, and
> > * negative on errors.
> > */
> > -static int stm_is_locked(struct spi_nor *nor, loff_t ofs, uint64_t len)
> > +static int fl_is_locked(struct spi_nor *nor, loff_t ofs, uint64_t len)
> > {
> > int status;
> >
> > @@ -1346,7 +1463,7 @@ static int stm_is_locked(struct spi_nor *nor, loff_t
> > ofs, uint64_t len)
> > if (status < 0)
> > return status;
> >
> > - return stm_is_locked_sr(nor, ofs, len, status);
> > + return fl_is_locked_sr(nor, ofs, len, status);
> > }
> >
> > static int spi_nor_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
> > @@ -1461,6 +1578,77 @@ static int macronix_quad_enable(struct spi_nor *nor)
> > }
> >
> > /**
> > + * issi_lock() - set BP[0123] write-protection.
> > + * @nor: pointer to a 'struct spi_nor'.
> > + * @ofs: offset from which to lock memory.
> > + * @len: number of bytes to unlock.
> > + *
> > + * Lock a region of the flash.Implementation is based on stm_lock
> > + * Supports the block protection bits BP{0,1,2,3} in the status register
> > + *
> > + * Return: 0 on success, -errno otherwise.
> > + */
> > +static int issi_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
> > +{
> > + int status_old, status_new, blk_prot;
> > + u8 mask = SR_BP3 | SR_BP2 | SR_BP1 | SR_BP0;
> > + u8 shift = ffs(mask) - 1;
> > + u8 pow, ret, func_reg;
> > + bool use_top;
> > + loff_t lock_len;
> > +
> > + status_old = read_sr(nor);
> > +
> > + /* if status reg is Write protected don't update bit protection */
> > + if (status_old & SR_SRWD) {
> > + dev_err(nor->dev,
> > + "SR is Write Protected,can't update BP bits...\n");
> > + return -EINVAL;
> > + }
> > +
> > + ret = fl_select_zone(nor, ofs, len, status_old, _top, 1);
> > + if (!ret)
> > + /* Older protected blocks include the new requested block's */
> > + return 0;
> > + else if (ret < 0)
> > + return ret;
> > +
> > + func_reg = read_fr(nor);
> > + /* lock_len: length of region that should end up locked */
> > + if (use_top) {
> > + /* Update Function register to use TOP area */
> > + if ((func_reg >> 1) & 0x1) {
> > + /* Currently bootom selected change to top */
> > + func_reg ^= FR_TB;
> > + write_fr(nor, func_reg);
> > + }
>
> IIUC, since this FR_TB OTP bit is initially 0 and now reads 1, implies
> that OTP bit has already been programmed once. So is clearing the bit
> possible?
>
> I think this lock/unlock mechanism needs a bit more thought.
> One solution would be to not modify OTP bit and return error in all
> cases when locking a region requested by user is not possible (for a
> default scheme).
I do agree here, writing the OTP will refrain the user from changing
the lock direction
once it's set. So better not update the OTP bits.
I will redo the approach and submit a v6 for this.
Thanks for your valuable feedback.
> Regards
> Vignesh
>
Regards,
Sagar Kadam
> > + lock_len = nor->mtd.size - ofs;
> > + } else {
> > +
> > + /* Update Function register to use bottom area */
> > + if (!((func_reg >> 1) & 0x1)) {
> > + /*Currently top is selected, change to bottom */
> > + func_reg ^= FR_TB;
> > + write_fr(nor, func_reg);
> > + }
> > + lock_len = ofs + len;
> > + }
> > +
> > + pow = order_base_2(lock_len);
> > + blk_prot = mask & (((pow+1) & 0xf)< > + if (lock_len <= 0) {
> > + dev_err(nor->dev, "invalid Length to protect");
> > + return -EINVAL;
> > + }
> > +
> > + status_new = status_old | blk_prot;
> > + if (status_old == status_new)
> > + return 0;
> > +
> > + return write_sr_and_check(nor, status_new, mask);
> > +}
> > +
> > +/**
> > * issi_unlock() - clear BP[0123] write-protection.
> > * @nor: pointer to a 'struct spi_nor'.
> > * @ofs: offset from which to unlock memory.
> > @@ -1879,7 +2067,7 @@ static int sr2_bit7_quad_enable(struct spi_nor *nor)
> > SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > { "is25wp256", INFO(0x9d7019, 0, 64 * 1024, 1024,
> > SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
> > - SPI_NOR_4B_OPCODES | SPI_NOR_HAS_LOCK)
> > + SPI_NOR_4B_OPCODES | SPI_NOR_HAS_LOCK |
> > SPI_NOR_HAS_TB)
> > },
> >
> > /* Macronix */
> > @@ -4120,12 +4308,13 @@ int spi_nor_scan(struct spi_nor *nor, const char
> > *name,
> > info->flags & SPI_NOR_HAS_LOCK) {
> > nor->flash_lock = stm_lock;
> > nor->flash_unlock = stm_unlock;
> > - nor->flash_is_locked = stm_is_locked;
> > + nor->flash_is_locked = fl_is_locked;
> > }
> >
> > /* NOR protection support for ISSI chips */
> > if (JEDEC_MFR(info) == SNOR_MFR_ISSI ||
> > info->flags & SPI_NOR_HAS_LOCK) {
> > + nor->flash_lock = issi_lock;
> > nor->flash_unlock = issi_unlock;
> >
> > }
> > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> > index 9a7d719..a15d012 100644
> > --- a/include/linux/mtd/spi-nor.h
> > +++ b/include/linux/mtd/spi-nor.h
> > @@ -40,6 +40,8 @@
> > #define SPINOR_OP_RDSR 0x05/* Read status register */
> > #define SPINOR_OP_WRSR 0x01/* Write status register 1
> > byte */
> > #define SPINOR_OP_RDSR2 0x3f/* Read status register 2 */
> > +#define SPINOR_OP_RDFR 0x48/* Read Function register */
> > +#define SPINOR_OP_WRFR 0x42/* Write Function register 1
> > byte */
> > #define SPINOR_OP_WRSR2 0x3e/* Write status register 2 */
> > #define SPINOR_OP_READ 0x03/* Read data bytes (low
> > frequency) */
> > #define SPINOR_OP_READ_FAST 0x0b/* Read data bytes (high frequency) */
> > @@ -139,6 +141,9 @@
> > /* Enhanced Volatile Configuration Register bits */
> > #define EVCR_QUAD_EN_MICRON BIT(7) /* Micron Quad I/O */
> >
> > +/*Function register bit */
> > +#define FR_TBBIT(1) /*ISSI: Top/Bottom protect */
> > +
> > /* Flag Status Register bits */
> > #define FSR_READYBIT(7) /* Device status, 0 = Busy, 1 = Ready
> > */
> > #define FSR_E_ERRBIT(5) /* Erase operation status */
> >
Re: [PATCH v5 2/3] mtd: spi-nor: add support to unlock flash device
Hello Joe,
Thanks for reviewing the patch.
On Tue, Jun 18, 2019 at 5:55 AM Joe Perches wrote:
>
> On Mon, 2019-06-17 at 21:10 +0530, Sagar Kadam wrote:
> > On Sun, Jun 16, 2019 at 6:35 PM Vignesh Raghavendra wrote:
> []
> > > > +static int issi_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
> > > > +{
> []
> > > > + if (ret > 0 && !(ret & mask)) {
> > > > + dev_info(nor->dev,
> > > > + "ISSI Block Protection Bits cleared SR=0x%x",
> > > > ret);
>
> Please use '\n' terminations on formats
>
I will include this in v6.
> > > > + ret = 0;
> > > > + } else {
> > > > + dev_err(nor->dev, "ISSI Block Protection Bits not
> > > > cleared\n");
>
> like this one
>
> > > > + ret = -EINVAL;
> > > > + }
> > > > + return ret;
> > > > +}
> > > > +
> > > > +/**
> > > > * spansion_quad_enable() - set QE bit in Configuraiton Register.
>
> s/Configuraiton/Configuration/
>
>
Thanks & BR,
Sagar Kadam
Re: [PATCH v5 2/3] mtd: spi-nor: add support to unlock flash device
Hello Vignesh,
On Sun, Jun 16, 2019 at 6:35 PM Vignesh Raghavendra wrote:
>
>
>
> On 12-Jun-19 4:17 PM, Sagar Shrikant Kadam wrote:
> > Nor device (is25wp256 mounted on HiFive unleashed Rev A00 board) from ISSI
> > have memory blocks guarded by block protection bits BP[0,1,2,3].
> >
> > Clearing block protection bits,unlocks the flash memory regions
> > The unlock scheme is registered during nor scans.
> >
> > Based on code developed by Wesley Terpstra
> > and/or Palmer Dabbelt .
> > https://github.com/riscv/riscv-linux/commit/c94e267766d62bc9a669611c3d0c8ed5ea26569b
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > ---
> > drivers/mtd/spi-nor/spi-nor.c | 51
> > ++-
> > include/linux/mtd/spi-nor.h | 1 +
> > 2 files changed, 51 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> > index 2d5a925..b7c6261 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -1461,6 +1461,49 @@ static int macronix_quad_enable(struct spi_nor *nor)
> > }
> >
> > /**
> > + * issi_unlock() - clear BP[0123] write-protection.
> > + * @nor: pointer to a 'struct spi_nor'.
> > + * @ofs: offset from which to unlock memory.
> > + * @len: number of bytes to unlock.
> > + *
> > + * Bits [2345] of the Status Register are BP[0123].
> > + * ISSI chips use a different block protection scheme than other chips.
> > + * Just disable the write-protect unilaterally.
> > + *
> > + * Return: 0 on success, -errno otherwise.
> > + */
> > +static int issi_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
> > +{
> > + int ret, val;
> > + u8 mask = SR_BP0 | SR_BP1 | SR_BP2 | SR_BP3;
> > +
> > + val = read_sr(nor);
> > + if (val < 0)
> > + return val;
> > + if (!(val & mask))
> > + return 0;
> > +
> > + write_enable(nor);
> > +
> > + write_sr(nor, val & ~mask);
> > +
> > + ret = spi_nor_wait_till_ready(nor);
> > + if (ret)
> > + return ret;
> > +
> > + ret = read_sr(nor);
> > + if (ret > 0 && !(ret & mask)) {
> > + dev_info(nor->dev,
> > + "ISSI Block Protection Bits cleared SR=0x%x", ret);
> > + ret = 0;
> > + } else {
> > + dev_err(nor->dev, "ISSI Block Protection Bits not cleared\n");
> > + ret = -EINVAL;
> > + }
> > + return ret;
> > +}
> > +
> > +/**
> > * spansion_quad_enable() - set QE bit in Configuraiton Register.
> > * @nor: pointer to a 'struct spi_nor'
> > *
> > @@ -1836,7 +1879,7 @@ static int sr2_bit7_quad_enable(struct spi_nor *nor)
> > SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > { "is25wp256", INFO(0x9d7019, 0, 64 * 1024, 1024,
> > SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
> > - SPI_NOR_4B_OPCODES)
> > + SPI_NOR_4B_OPCODES | SPI_NOR_HAS_LOCK)
> > },
> >
> > /* Macronix */
> > @@ -4080,6 +4123,12 @@ int spi_nor_scan(struct spi_nor *nor, const char
> > *name,
> > nor->flash_is_locked = stm_is_locked;
> > }
> >
> > + /* NOR protection support for ISSI chips */
> > + if (JEDEC_MFR(info) == SNOR_MFR_ISSI ||
> > + info->flags & SPI_NOR_HAS_LOCK) {
>
> This should be:
>
> if (JEDEC_MFR(info) == SNOR_MFR_ISSI &&
> info->flags & SPI_NOR_HAS_LOCK) {
>
> Otherwise you would end up overriding nor->flash_unlock function for
> other vendors too, right?
>
Yes, right. I will submit a v6 for this.
> > + nor->flash_unlock = issi_unlock;
> > +
>
> No need for blank line here.
> Please run ./scripts/checkpatch.pl --strict on all patches and address
> all the issues reported by it.
>
>
Ok. The plain checkpatch.pl run didn't catch this.
I will fix this and provide a v6 for this.
>
> > + }
> > if (nor->flash_lock && nor->flash_unlock && nor->flash_is_locked) {
> > mtd->_lock = spi_nor_lock;
> > mtd->_unlock = spi_nor_unlock;
> > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> > index ff13297..9a7d719 100644
> > --- a/include/linux/mtd/spi-nor.h
> > +++ b/include/linux/mtd/spi-nor.h
> > @@ -127,6 +127,7 @@
> > #define SR_BP0 BIT(2) /* Block protect 0 */
> > #define SR_BP1 BIT(3) /* Block protect 1 */
> > #define SR_BP2 BIT(4) /* Block protect 2 */
> > +#define SR_BP3 BIT(5) /* Block protect 3 for ISSI
> > device*/
>
> No need to mention ISSI here. I am sure there are devices from other
> vendors with BP3
>
Ok, I will drop this in V6 and submit.
> > #define SR_TBBIT(5) /* Top/Bottom protect */
> > #define SR_SRWD BIT(7) /* SR write protect */
> > /* Spansion/Cypress specific status bits */
> >
>
> Regards
> Vignesh
Thanks & BR,
Sagar Kadam
Re: [PATCH v5 1/3] mtd: spi-nor: add support for is25wp256
Hello Vignesh,
Thanks for your review comments.
On Sun, Jun 16, 2019 at 6:14 PM Vignesh Raghavendra wrote:
>
> Hi,
>
> On 12-Jun-19 4:17 PM, Sagar Shrikant Kadam wrote:
> [...]
>
> > @@ -4129,7 +4137,7 @@ int spi_nor_scan(struct spi_nor *nor, const char
> > *name,
> > if (ret)
> > return ret;
> >
> > - if (nor->addr_width) {
> > + if (nor->addr_width && JEDEC_MFR(info) != SNOR_MFR_ISSI) {
> > /* already configured from SFDP */
>
> Hmm, why would you want to ignore addr_width that's read from SFDP table?
The SFDP table for ISSI device considered here, has addr_width set to
3 byte, and the flash considered
here is 32MB. With 3 byte address width we won't be able to access
flash memories higher address range.
Hence I have ignored the addr width from SFDP. I have verified that
with 3 byte address width, the
flascp util fails while verifying the written data. Please let me
know your views on this?
BR,
Sagar Kadam
> Regards
> Vignesh
>
>
> > } else if (info->addr_width) {
> > nor->addr_width = info->addr_width;
> > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> > index b3d360b..ff13297 100644
> > --- a/include/linux/mtd/spi-nor.h
> > +++ b/include/linux/mtd/spi-nor.h
> > @@ -19,6 +19,7 @@
> > #define SNOR_MFR_ATMEL CFI_MFR_ATMEL
> > #define SNOR_MFR_GIGADEVICE 0xc8
> > #define SNOR_MFR_INTEL CFI_MFR_INTEL
> > +#define SNOR_MFR_ISSI0x9d/* ISSI */
> > #define SNOR_MFR_ST CFI_MFR_ST /* ST Micro */
> > #define SNOR_MFR_MICRON CFI_MFR_MICRON /* Micron */
> > #define SNOR_MFR_MACRONIXCFI_MFR_MACRONIX
> >
Re: [PATCH v8 1/3] dt-bindings: i2c: extend existing opencore bindings.
Hello Rob, Please let me know if this patch is as per your requirements/comments you mentioned earlier. Thanks & Regards, Sagar Kadam On Wed, May 29, 2019 at 9:57 AM Sagar Shrikant Kadam wrote: > > Reformatted compatibility strings to one valid combination on > each line. > Add FU540-C000 specific device tree bindings to already available > i2-ocores file. This device is available on > HiFive Unleashed Rev A00 board. Move interrupt under optional > property list as this can be optional. > > The FU540-C000 SoC from sifive, has an Opencore's I2C block > reimplementation. > > The DT compatibility string for this IP is present in HDL and available at. > https://github.com/sifive/sifive-blocks/blob/master/src/main/scala/devices/i2c/I2C.scala#L73 > > Signed-off-by: Sagar Shrikant Kadam > --- > Documentation/devicetree/bindings/i2c/i2c-ocores.txt | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/i2c/i2c-ocores.txt > b/Documentation/devicetree/bindings/i2c/i2c-ocores.txt > index 17bef9a..6b25a80 100644 > --- a/Documentation/devicetree/bindings/i2c/i2c-ocores.txt > +++ b/Documentation/devicetree/bindings/i2c/i2c-ocores.txt > @@ -1,9 +1,13 @@ > Device tree configuration for i2c-ocores > > Required properties: > -- compatible : "opencores,i2c-ocores" or "aeroflexgaisler,i2cmst" > +- compatible : "opencores,i2c-ocores" > +"aeroflexgaisler,i2cmst" > +"sifive,fu540-c000-i2c", "sifive,i2c0" > +For Opencore based I2C IP block reimplemented in > +FU540-C000 SoC. Please refer to > sifive-blocks-ip-versioning.txt > +for additional details. > - reg : bus address start and address range size of device > -- interrupts : interrupt number > - clocks : handle to the controller clock; see the note below. > Mutually exclusive with opencores,ip-clock-frequency > - opencores,ip-clock-frequency: frequency of the controller clock in Hz; > @@ -12,6 +16,7 @@ Required properties: > - #size-cells : should be <0> > > Optional properties: > +- interrupts : interrupt number. > - clock-frequency : frequency of bus clock in Hz; see the note below. > Defaults to 100 KHz when the property is not specified > - reg-shift : device register offsets are shifted by this value > -- > 1.9.1 >
Re: [PATCH v8 3/3] i2c-ocores: sifive: add polling mode workaround for FU540-C000 SoC.
On Wed, May 29, 2019 at 9:23 PM Andrew Lunn wrote:
>
> On Wed, May 29, 2019 at 09:57:27AM +0530, Sagar Shrikant Kadam wrote:
> > The i2c-ocore driver already has a polling mode interface.But it needs
> > a workaround for FU540 Chipset on HiFive unleashed board (RevA00).
> > There is an erratum in FU540 chip that prevents interrupt driven i2c
> > transfers from working, and also the I2C controller's interrupt bit
> > cannot be cleared if set, due to this the existing i2c polling mode
> > interface added in mainline earlier doesn't work, and CPU stall's
> > infinitely, when-ever i2c transfer is initiated.
> >
> > Ref:
> > commit dd7dbf0eb090 ("i2c: ocores: refactor setup for polling")
> >
> > The workaround / fix under OCORES_FLAG_BROKEN_IRQ is particularly for
> > FU540-COOO SoC.
> >
> > The polling function identifies a SiFive device based on the device node
> > and enables the workaround.
> >
> > Signed-off-by: Sagar Shrikant Kadam
>
> Hi Sagar
>
> When you repost, you are supposed to add any reviewed-by, or acked-by
> tags you received.
Sorry Andrew, I missed it.
I will repost it, with acked by Andrew Lunn as you had Acknowledged it earlier
>
> Andrew
Thanks,
Sagar
Re: [PATCH v7 1/3] dt-bindings: i2c: extend existing opencore bindings.
Hi Rob, On Sat, May 25, 2019 at 2:10 AM Rob Herring wrote: > > On Wed, May 22, 2019 at 02:29:32PM +0530, Sagar Shrikant Kadam wrote: > > Reformatted compatibility strings to one valid combination on > > each line. > > Add FU540-C000 specific device tree bindings to already available > > i2-ocores file. This device is available on > > HiFive Unleashed Rev A00 board. Move interrupt under optional > > property list as this can be optional. > > > > The FU540-C000 SoC from sifive, has an Opencore's I2C block > > reimplementation. > > > > The DT compatibility string for this IP is present in HDL and available at. > > https://github.com/sifive/sifive-blocks/blob/master/src/main/scala/devices/i2c/I2C.scala#L73 > > > > Signed-off-by: Sagar Shrikant Kadam > > --- > > Documentation/devicetree/bindings/i2c/i2c-ocores.txt | 9 +++-- > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/i2c/i2c-ocores.txt > > b/Documentation/devicetree/bindings/i2c/i2c-ocores.txt > > index 17bef9a..db96951 100644 > > --- a/Documentation/devicetree/bindings/i2c/i2c-ocores.txt > > +++ b/Documentation/devicetree/bindings/i2c/i2c-ocores.txt > > @@ -1,9 +1,13 @@ > > Device tree configuration for i2c-ocores > > > > Required properties: > > -- compatible : "opencores,i2c-ocores" or "aeroflexgaisler,i2cmst" > > +- compatible : "opencores,i2c-ocores", > > +"aeroflexgaisler,i2cmst", > > +"sifive,fu540-c000-i2c","sifive,i2c0". > > space needed ^ > > And drop the end of line commas and period. > > > > +For Opencore based I2C IP block reimplemented in > > +FU540-C000 SoC.Please refer > > sifive-blocks-ip-versioning.txt > > And here too. > > And 'refer to' I will incorporate the changes you have suggested. Thanks, Sagar Kadam > > > +for additional details. > > - reg : bus address start and address range size of device > > -- interrupts : interrupt number > > - clocks : handle to the controller clock; see the note below. > > Mutually exclusive with opencores,ip-clock-frequency > > - opencores,ip-clock-frequency: frequency of the controller clock in Hz; > > @@ -12,6 +16,7 @@ Required properties: > > - #size-cells : should be <0> > > > > Optional properties: > > +- interrupts : interrupt number. > > - clock-frequency : frequency of bus clock in Hz; see the note below. > > Defaults to 100 KHz when the property is not specified > > - reg-shift : device register offsets are shifted by this value > > -- > > 1.9.1 > >
Re: [PATCH v7 3/3] i2c-ocores: sifive: add polling mode workaround for FU540-C000 SoC.
On Thu, May 23, 2019 at 7:23 PM Wolfram Sang wrote: > > > > Ok, Great. Do we need to write to him about this patchset? > > Nope. Hint: You can dig in the mail archives studying older patches to > see how things work. I do this as well because things may work > differently per subsystem. > Thanks Wolfram for confirming on this. I will do check in the mail archives for additional info. Regards, Sagar Kadam
Re: [PATCH v7 3/3] i2c-ocores: sifive: add polling mode workaround for FU540-C000 SoC.
Hi Andrew, On Thu, May 23, 2019 at 6:04 PM Andrew Lunn wrote: > > > Thank you Andrew for reviewing the patch set. > > Can you please let me know weather you or Peter will be pick up the patch > > for v5.3 or they should go in via some other tree? > > Hi Sagar > > Wolfram Sang should pick the patchset up. > Ok, Great. Do we need to write to him about this patchset? > Andrew Regards, Sagar Kadam
Re: [PATCH v6 3/3] i2c-ocores: sifive: add polling mode workaround for FU540-C000 SoC.
Hi Andrew,
On Tue, May 21, 2019 at 7:24 PM Andrew Lunn wrote:
>
> > static void ocores_process_polling(struct ocores_i2c *i2c)
> > {
> > + const struct of_device_id *match;
> > +
> > + match = of_match_node(ocores_i2c_match, i2c->adap.dev.of_node);
> > +
> > while (1) {
> > irqreturn_t ret;
> > int err;
>
> Please keep with the idea of i2c->flags, which is set during probe.
> Just because it was removed because it was no longer needed does not
> stop you from putting it back again if it is needed.
>
I had modified the implementation, so as to keep it compatible with
the new implementation of polling mode.
As per your suggestion, I will keep the older method (the v5 version
which you Reviewed earlier : https://lkml.org/lkml/2019/5/20/1261)
and submit a v7 for this.
>Andrew
Thanks & Regards,
Sagar
Re: [PATCH v6 1/3] dt-bindings: i2c: extend existing opencore bindings.
Hi Andrew, On Tue, May 21, 2019 at 7:26 PM Andrew Lunn wrote: > > > Required properties: > > -- compatible : "opencores,i2c-ocores" or "aeroflexgaisler,i2cmst" > > +- compatible : "opencores,i2c-ocores", > > + "aeroflexgaisler,i2cmst", > > +"sifive,fu540-c000-i2c","sifive,i2c0". > > + For Opencore based I2C IP block reimplemented in > > It looks like there are some tabs vs space issues here. Ohh. It was not catched in checkpatch.pl. I will update it. Thanks, Sagar Kadam >Andrew
Re: [PATCH v5 3/3] i2c-ocores: sifive: add polling mode workaround for FU540-C000 SoC.
Thanks Andreas,
Yes, I rebased to v5.2-rc1 and observed that there have been changes
in polling interface, and i2c->flags is not longer being used for
setting the polling mode. I am working on a way to hook in the fix for
broken IRQ and will submit it in v6.
Thanks & BR,
Sagar Kadam
On Tue, May 21, 2019 at 2:03 PM Andreas Schwab wrote:
>
> On Mai 20 2019, Sagar Shrikant Kadam wrote:
>
> > The i2c-ocore driver already has a polling mode interface.But it needs
> > a workaround for FU540 Chipset on HiFive unleashed board (RevA00).
> > There is an erratum in FU540 chip that prevents interrupt driven i2c
> > transfers from working, and also the I2C controller's interrupt bit
> > cannot be cleared if set, due to this the existing i2c polling mode
> > interface added in mainline earlier doesn't work, and CPU stall's
> > infinitely, when-ever i2c transfer is initiated.
> >
> > Ref:previous polling mode support in mainline
> >
> > commit 69c8c0c0efa8 ("i2c: ocores: add polling interface")
> >
> > The workaround / fix under OCORES_FLAG_BROKEN_IRQ is particularly for
> > FU540-COOO SoC.
>
> After commit dd7dbf0eb090 this no longer fits.
>
> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
Re: [PATCH v5 1/3] dt-bindings: i2c: extend existing opencore bindings.
Hi Rob, On Mon, May 20, 2019 at 8:07 PM Rob Herring wrote: > > On Mon, May 20, 2019 at 9:12 AM Sagar Shrikant Kadam > wrote: > > > > Add FU540-C000 specific device tree bindings to already > > available i2-ocores file. This device is available on > > HiFive Unleashed Rev A00 board. Move interrupt and interrupt > > parents under optional property list as these can be optional. > > > > The FU540-C000 SoC from sifive, has an Opencore's I2C block > > reimplementation. > > > > The DT compatibility string for this IP is present in HDL and available at. > > https://github.com/sifive/sifive-blocks/blob/master/src/main/scala/devices/i2c/I2C.scala#L73 > > > > Signed-off-by: Sagar Shrikant Kadam > > --- > > Documentation/devicetree/bindings/i2c/i2c-ocores.txt | 7 ++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/i2c/i2c-ocores.txt > > b/Documentation/devicetree/bindings/i2c/i2c-ocores.txt > > index 17bef9a..b73960e 100644 > > --- a/Documentation/devicetree/bindings/i2c/i2c-ocores.txt > > +++ b/Documentation/devicetree/bindings/i2c/i2c-ocores.txt > > @@ -2,8 +2,11 @@ Device tree configuration for i2c-ocores > > > > Required properties: > > - compatible : "opencores,i2c-ocores" or "aeroflexgaisler,i2cmst" > > +"sifive,fu540-c000-i2c" or "sifive,i2c0". > > It's not an OR because both are required. Please reformat to 1 valid > combination per line. Yes, will rectify it in V6. > > + for Opencore based I2C IP block reimplemented in > > + FU540-C000 SoC.Please refer > > sifive-blocks-ip-versioning.txt > > + for additional details. > > - reg : bus address start and address range size of device > > -- interrupts : interrupt number > > - clocks : handle to the controller clock; see the note below. > > Mutually exclusive with opencores,ip-clock-frequency > > - opencores,ip-clock-frequency: frequency of the controller clock in Hz; > > @@ -12,6 +15,8 @@ Required properties: > > - #size-cells : should be <0> > > > > Optional properties: > > +- interrupt-parent: handle to interrupt controller. > > Drop this. interrupt-parent is implied. > Sure, will exclude it in v6. > > +- interrupts : interrupt number. > > - clock-frequency : frequency of bus clock in Hz; see the note below. > > Defaults to 100 KHz when the property is not specified > > - reg-shift : device register offsets are shifted by this value > > -- > > 1.9.1 > > > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv Thanks, Sagar
Re: [PATCH v5 3/3] i2c-ocores: sifive: add polling mode workaround for FU540-C000 SoC.
On Mon, May 20, 2019 at 8:22 PM Andrew Lunn wrote:
>
> On Mon, May 20, 2019 at 07:41:18PM +0530, Sagar Shrikant Kadam wrote:
> > The i2c-ocore driver already has a polling mode interface.But it needs
> > a workaround for FU540 Chipset on HiFive unleashed board (RevA00).
> > There is an erratum in FU540 chip that prevents interrupt driven i2c
> > transfers from working, and also the I2C controller's interrupt bit
> > cannot be cleared if set, due to this the existing i2c polling mode
> > interface added in mainline earlier doesn't work, and CPU stall's
> > infinitely, when-ever i2c transfer is initiated.
> >
> > Ref:previous polling mode support in mainline
> >
> > commit 69c8c0c0efa8 ("i2c: ocores: add polling interface")
> >
> > The workaround / fix under OCORES_FLAG_BROKEN_IRQ is particularly for
> > FU540-COOO SoC.
> >
> > Signed-off-by: Sagar Shrikant Kadam
>
> Much better, thanks.
My pleasure Andrew.
Appreciate your timely review and response.
>
> Reviewed-by: Andrew Lunn
>
> Andrew
Thanks,
Sagar
Re: [PATCH v4 3/3] i2c-ocores: sifive: add polling mode workaround for FU540-C000 SoC
Hi Andrew,
On Mon, May 20, 2019 at 6:11 PM Andrew Lunn wrote:
>
> > @@ -406,7 +416,7 @@ static int ocores_xfer(struct i2c_adapter *adap,
> > {
> > struct ocores_i2c *i2c = i2c_get_adapdata(adap);
> >
> > - if (i2c->flags & OCORES_FLAG_POLL)
> > + if ((i2c->flags & (OCORES_FLAG_POLL | OCORES_FLAG_BROKEN_IRQ)))
> > return ocores_xfer_polling(adap, msgs, num);
> > return ocores_xfer_core(i2c, msgs, num, false);
> > }
>
> You are not listening to what i said. All you need to know here is
> that you must poll. It does not matter if the IRQ is broken or not.
>
Apologies for my miss-understanding. I will rectify this and submit a v5.
> > irq = platform_get_irq(pdev, 0);
> > if (irq == -ENXIO) {
> > - i2c->flags |= OCORES_FLAG_POLL;
>
> If there is no interrupt, you need to poll. So keep this line.
Will retain this.
> > + /*
> > + * Set a OCORES_FLAG_BROKEN_IRQ to enable workaround for
> > + * FU540-C000 SoC in polling mode interface of i2c-ocore
> > driver.
> > + * Else enable default polling mode interface for SIFIVE/OCORE
> > + * device types.
> > + */
> > + match = of_match_node(ocores_i2c_match, pdev->dev.of_node);
> > + if (match && (long)match->data == TYPE_SIFIVE_REV0)
> > + i2c->flags |= OCORES_FLAG_BROKEN_IRQ;
>
> If it is a OCORE, IRQ is broken, so OR in OCORES_FLAG_BROKEN_IRQ.
Got it, as device type SIFIVE is based on OCORE's re-implementation,
will OR in the broken IRQ flag and submit a v5.
> >
> > - if (!(i2c->flags & OCORES_FLAG_POLL)) {
> > + if (!(i2c->flags & (OCORES_FLAG_POLL | OCORES_FLAG_BROKEN_IRQ))) {
> > ret = devm_request_irq(>dev, irq, ocores_isr, 0,
> > pdev->name, i2c);
>
> Here you just need to know if you are polling. Broken IRQ does not
> matter.
>
> Andrew
Thanks & Regards,
Sagar
Re: [PATCH v3 3/3] i2c-ocores: sifive: add polling mode workaround for FU540-C000 SoC
Hi Andrew,
On Thu, May 16, 2019 at 6:37 PM Andrew Lunn wrote:
>
> On Thu, May 16, 2019 at 10:38:40AM +0530, Sagar Shrikant Kadam wrote:
> > The i2c-ocore driver already has a polling mode interface.But it needs
> > a workaround for FU540 Chipset on HiFive unleashed board (RevA00).
> > There is an erratum in FU540 chip that prevents interrupt driven i2c
> > transfers from working, and also the I2C controller's interrupt bit
> > cannot be cleared if set, due to this the existing i2c polling mode
> > interface added in mainline earlier doesn't work, and CPU stall's
> > infinitely, when-ever i2c transfer is initiated.
> >
> > Ref:previous polling mode support in mainline
> >
> > commit 69c8c0c0efa8 ("i2c: ocores: add polling interface")
> >
> > The workaround / fix under OCORES_FLAG_BROKEN_IRQ is particularly for
> > FU540-COOO SoC.
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > ---
> > drivers/i2c/busses/i2c-ocores.c | 34 --
> > 1 file changed, 28 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-ocores.c
> > b/drivers/i2c/busses/i2c-ocores.c
> > index aee1d86..00ee45c 100644
> > --- a/drivers/i2c/busses/i2c-ocores.c
> > +++ b/drivers/i2c/busses/i2c-ocores.c
> > @@ -27,6 +27,7 @@
> > #include
> >
> > #define OCORES_FLAG_POLL BIT(0)
> > +#define OCORES_FLAG_BROKEN_IRQ BIT(2) /* Broken IRQ in HiFive Unleashed */
>
> Hi Sigar
>
> BIT(1). Don't leave a gap.
I will remove the gap and update this in V4.
Thanks,
Sagar
>
> Andrew
Re: [PATCH v3 3/3] i2c-ocores: sifive: add polling mode workaround for FU540-C000 SoC
Hello Andrew,
On Thu, May 16, 2019 at 6:01 PM Andrew Lunn wrote:
>
> > @@ -682,13 +693,24 @@ static int ocores_i2c_probe(struct platform_device
> > *pdev)
> >
> > irq = platform_get_irq(pdev, 0);
> > if (irq == -ENXIO) {
> > - i2c->flags |= OCORES_FLAG_POLL;
> > + /*
> > + * Set a OCORES_FLAG_BROKEN_IRQ to enable workaround for
> > + * FU540-C000 SoC in polling mode interface of i2c-ocore
> > driver.
> > + * Else enable default polling mode interface for SIFIVE/OCORE
> > + * device types.
> > + */
> > + match = of_match_node(ocores_i2c_match, pdev->dev.of_node);
> > + if (match && (long)match->data ==
> > + (TYPE_SIFIVE_REV0 | OCORES_FLAG_BROKEN_IRQ))
>
> This looks wrong. You added:
>
> + {
> + .compatible = "sifive,fu540-c000-i2c",
> + .data = (void *)TYPE_SIFIVE_REV0,
> + },
> + {
> + .compatible = "sifive,i2c0",
> + .data = (void *)TYPE_SIFIVE_REV0,
> + },
>
> So match->data just has TYPE_SIFIVE_REV0.
I updated the device_id table into two logically separated patches as follows:-
1. Update device id table for Sifive devices
[PATCH v3 2/3] i2c-ocore:
.data for sifive,fu540-540-c000 and sifive,i2c0 both
are for sifive devices hence TYPE_SIFIVE_REV0
2. Add polling mode workaround fix for fu540-c000 SoC
[PATCH v3 3/3] i2c-ocores:
.data for sifive,fu540-540-c000 is of
TYPE_SIFIVE_REV0 and has a broken IRQ so the flag
OCORES_FLAG_BROKEN_IRQ is OR'd to data into device id table.
Please let me know if you feel patch 2 and patch 3 need to be squashed
together into a single patch.
>
> > + i2c->flags |= OCORES_FLAG_BROKEN_IRQ;
> > + else
> > + i2c->flags |= OCORES_FLAG_POLL;
>
> These two don't need to be exclusive. It makes more sense to say
> SIFIVE needs to poll and it its IRQ is broken. A lot of your other
> changes then go away.
>
Other SiFive chip's with Ocore based I2C re-implementation might not
need the broken IRQ workaround.
and can use the the existing mainline polling mode interface, using
OCORES_FLAG_POLL.
Thanks & BR,
Sagar Kadam
>Andrew
Re: [PATCH v2 v2 1/3] dt-bindings: i2c: extend existing opencore bindings.
Hello Rob,
Thank you for the review.
On Tue, May 14, 2019 at 2:26 AM Rob Herring wrote:
>
> On Tue, May 07, 2019 at 08:45:06PM +0530, Sagar Shrikant Kadam wrote:
> > Add FU540-C000 specific device tree bindings to already
> > available i2-ocores file. This device is available on
> > HiFive Unleashed Rev A00 board.
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > ---
> > Documentation/devicetree/bindings/i2c/i2c-ocores.txt | 20
> >
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/i2c/i2c-ocores.txt
> > b/Documentation/devicetree/bindings/i2c/i2c-ocores.txt
> > index 17bef9a..f6bcf90 100644
> > --- a/Documentation/devicetree/bindings/i2c/i2c-ocores.txt
> > +++ b/Documentation/devicetree/bindings/i2c/i2c-ocores.txt
> > @@ -2,6 +2,7 @@ Device tree configuration for i2c-ocores
> >
> > Required properties:
> > - compatible : "opencores,i2c-ocores" or "aeroflexgaisler,i2cmst"
> > +"sifive,fu540-c000-i2c" or "sifive,i2c0"
>
> If this is Opencores IP, does it really follow the Sifive versioning
> convention? If so, please reference sifive-blocks-ip-versioning.txt
> (which appears to have missed going upstream). Also, referencing the IP
> repository would be good too. If this IP block doesn't follow the same
> convention, then don't try using it for this binding.
>
Yes, the sifive,fu540-c000-i2c is a SoC specific compatibility string,
this way SoC specific
workaround's or bugs, can be handled in the software and the ip-block
specific compatibility
string "sifive," i.e.
sifive,i2c0 is IP block specific compatibility
string. Please let me know if I need some correction here?
I will also update reference for sifive-blocks-ip-versioning and the
ip repository into next version of patch.
> > - reg : bus address start and address range size of device
> > - interrupts : interrupt number
> > - clocks : handle to the controller clock; see the note below.
> > @@ -67,3 +68,22 @@ or
> > reg = <0x60>;
> > };
> > };
> > +or
>
> Just a new compatible isn't really a reason to add an example.
>
> > + /*
> > + An Opencore based I2C node in FU540-C000 chip from SiFive
> > + This chip has a hardware erratum for broken IRQ
> > + so it's recommended not to define interrupt in the device node
>
> Then interrupts needs to be optional.
True, I will move interrupts and interrupt parent into optional section
>
> > + */
> > + i2c@1003 {
> > + compatible = "sifive,i2c0","sifive,fu540-c000-i2c";
> > + reg = <0x0 0x1003 0x0 0x1000>;
> > + reg-names = "i2c-control";
>
> Not doucmented.
In v1, I had added a new binding file as sifive-i2c-ocores.txt for
SiFive i2c core.
After Andrew's suggestion, extending the available i2c-ocores.txt
seemed to be a better idea rather than adding a new file.
so added an example node which is HiFive specific in the existing file.
Please let me know if I need to handle this in a different way.
>
> > + clocks = <>;
> > + clock-frequency = <10>;
> > +
> > + reg-shift = <2>;
> > + reg-io-width = <1>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > --
> > 1.9.1
> >
> >
> > --
> > The information transmitted is intended only for the person or entity to
> > which it is addressed and may contain confidential and/or privileged
> > material. If you are not the intended recipient of this message please do
> > not read, copy, use or disclose this communication and notify the sender
> > immediately. It should be noted that any review, retransmission,
> > dissemination or other use of, or taking action or reliance upon, this
> > information by persons or entities other than the intended recipient is
> > prohibited
Re: [PATCH v1 v1 3/3] i2c-ocores: sifive: add polling mode workaround for FU540-C000 SoC.
On Mon, May 6, 2019 at 6:59 PM Andrew Lunn wrote:
>
> > /*
> > * 'process_lock' exists because ocores_process() and
> > ocores_process_timeout()
> > @@ -239,8 +240,13 @@ static irqreturn_t ocores_isr(int irq, void *dev_id)
> > struct ocores_i2c *i2c = dev_id;
> > u8 stat = oc_getreg(i2c, OCI2C_STATUS);
> >
> > - if (!(stat & OCI2C_STAT_IF))
> > + if (i2c->flags && SIFIVE_FLAG_POLL) {
>
> Do you really want && here?
>
> > + if (stat & OCI2C_STAT_IF)
> > + if (!(stat & OCI2C_STAT_BUSY))
> > + return IRQ_NONE;
> > + } else if (!(stat & OCI2C_STAT_IF)) {
> > return IRQ_NONE;
> > + }
> >
> > ocores_process(i2c, stat);
> >
> > @@ -356,6 +362,11 @@ static void ocores_process_polling(struct ocores_i2c
> > *i2c)
> > ret = ocores_isr(-1, i2c);
> > if (ret == IRQ_NONE)
> > break; /* all messages have been transferred */
> > + else {
> > + if (i2c->flags && SIFIVE_FLAG_POLL)
>
> And here?
>
> > + if (i2c->state == STATE_DONE)
> > + break;
> > + }
> > }
> > }
> >
> > @@ -406,7 +417,7 @@ static int ocores_xfer(struct i2c_adapter *adap,
> > {
> > struct ocores_i2c *i2c = i2c_get_adapdata(adap);
> >
> > - if (i2c->flags & OCORES_FLAG_POLL)
> > + if ((i2c->flags & OCORES_FLAG_POLL) || (i2c->flags &
> > SIFIVE_FLAG_POLL))
>
> You can combine this
Thanks for your suggestion's Andrew.
Yes, I will optimize this.
>
> if ((i2c->flags & (OCORES_FLAG_POLL | SIFIVE_FLAG_POLL))
>
> > return ocores_xfer_polling(adap, msgs, num);
> > return ocores_xfer_core(i2c, msgs, num, false);
> > }
> > @@ -597,6 +608,7 @@ static int ocores_i2c_probe(struct platform_device
> > *pdev)
> > {
> > struct ocores_i2c *i2c;
> > struct ocores_i2c_platform_data *pdata;
> > + const struct of_device_id *match;
> > struct resource *res;
> > int irq;
> > int ret;
> > @@ -678,13 +690,21 @@ static int ocores_i2c_probe(struct platform_device
> > *pdev)
> >
> > irq = platform_get_irq(pdev, 0);
> > if (irq == -ENXIO) {
> > - i2c->flags |= OCORES_FLAG_POLL;
> > + /*
> > + * Set a SIFIVE_FLAG_POLL to enable workaround for FU540
> > + * in polling mode interface of i2c-ocore driver.
> > + */
> > + match = of_match_node(ocores_i2c_match, pdev->dev.of_node);
> > + if (match && (long)match->data == TYPE_SIFIVE_REV0)
> > + i2c->flags |= SIFIVE_FLAG_POLL;
> > + else
> > + i2c->flags |= OCORES_FLAG_POLL;
>
> Please take a look at the whole code, and consider if it is better to
> set both SIFIVE_FLAG_POLL and OCORES_FLAG_POLL. Maybe rename
> SIFIVE_FLAG_POLL to OCORES_FLAG_BROKEN_IRQ_BIT?
>
The intent of this patch is to add a workaround for hardware errratum
of FU540 a SiFive Device,
hence I had named the flag accordingly. Yes,
OCORES_FLAG_BROKEN_IRQ_BIT is a better and generic term,
I will rename and resubmit this patch
-Thanks
Sagar
> Thanks
> Andrew
Re: [PATCH v1 v1 1/3] dt-bindings: i2c: add documentation for adding SiFive I2C driver
On Mon, May 6, 2019 at 6:49 PM Andrew Lunn wrote: > > On Mon, May 06, 2019 at 06:23:58PM +0530, Sagar Shrikant Kadam wrote: > > Add DT binding for OpenCore's based i2c device as found in > > FU540 Chipset on HiFive Unleashed Platform (Rev A00). > > > > The doc explains, how to add DT support for I2C devices. > > > > Signed-off-by: Sagar Shrikant Kadam > > --- > > .../devicetree/bindings/i2c/i2c-sifive.txt | 29 > > ++ > > 1 file changed, 29 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/i2c/i2c-sifive.txt > > Hi Sagar > > Please extend the existing i2c-ocores.txt file, not add a new file. Hi Andrew, Thanks for your review. Yes I will extend the i2c-ocores.txt to support sifive devices, and will submit a v2 of this patch. > >Andrew
Re: [PATCH v2 2/3] mtd: spi-nor: add support to unlock flash device.
On Tue, Apr 30, 2019 at 10:49 PM Paul Walmsley wrote:
>
> On Sun, 28 Apr 2019, Sagar Shrikant Kadam wrote:
>
> > Nor device (is25wp256 mounted on HiFive unleashed Rev A00 board) from ISSI
> > have memory blocks guarded by block protection bits BP[0,1,2,3].
> >
> > Clearing block protection bits,unlocks the flash memory regions
> > The unlock scheme is registered during nor scans.
>
> This also looks like it's partially based on Wes or Palmer's patch from
>
> https://github.com/riscv/riscv-linux/commit/c94e267766d62bc9a669611c3d0c8ed5ea26569b
>
> Please note that in the patch message.
Thank you Paul for pointing this out.
Yes, I missed to add it to commit message and will submit a V3
version of the patch.
> > Signed-off-by: Sagar Shrikant Kadam
> > ---
> > drivers/mtd/spi-nor/spi-nor.c | 48
> > ++-
> > include/linux/mtd/spi-nor.h | 1 +
> > 2 files changed, 48 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> > index c5408ed..81c7b3e 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -1461,6 +1461,46 @@ static int macronix_quad_enable(struct spi_nor *nor)
> > }
> >
> > /**
> > + * issi_unlock() - clear BP[0123] write-protection.
> > + * @nor: pointer to a 'struct spi_nor'
> > + * @ofs: offset from which to unlock memory
> > + * @len: number of bytes to unlock
> > + * Bits [2345] of the Status Register are BP[0123].
> > + * ISSI chips use a different block protection scheme than other chips.
> > + * Just disable the write-protect unilaterally.
> > + * Return: 0 on success, -errno otherwise.
>
> This is closer to kernel-doc format, but not quite. Please update this to
> align to
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/doc-guide/kernel-doc.rst#n57
>
This is a good pointer. I will align the function description
according to kernel-doc format.
>
> - Paul
>
> > + */
> > +static int issi_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
> > +{
> > + int ret, val;
> > + u8 mask = SR_BP0 | SR_BP1 | SR_BP2 | SR_BP3;
> > +
> > + val = read_sr(nor);
> > + if (val < 0)
> > + return val;
> > + if (!(val & mask))
> > + return 0;
> > +
> > + write_enable(nor);
> > +
> > + write_sr(nor, val & ~mask);
> > +
> > + ret = spi_nor_wait_till_ready(nor);
> > + if (ret)
> > + return ret;
> > +
> > + ret = read_sr(nor);
> > + if (ret > 0 && !(ret & mask)) {
> > + dev_info(nor->dev,
> > + "ISSI Block Protection Bits cleared SR=0x%x", ret);
> > + return 0;
> > + } else {
> > + dev_err(nor->dev, "ISSI Block Protection Bits not cleared\n");
> > + return -EINVAL;
> > + }
> > +}
> > +
> > +/**
> > * spansion_quad_enable() - set QE bit in Configuraiton Register.
> > * @nor: pointer to a 'struct spi_nor'
> > *
> > @@ -1836,7 +1876,7 @@ static int sr2_bit7_quad_enable(struct spi_nor *nor)
> > SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > { "is25wp256", INFO(0x9d7019, 0, 64 * 1024, 1024,
> > SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
> > - SPI_NOR_4B_OPCODES)
> > + SPI_NOR_4B_OPCODES | SPI_NOR_HAS_LOCK)
> > },
> >
> > /* Macronix */
> > @@ -4078,6 +4118,12 @@ int spi_nor_scan(struct spi_nor *nor, const char
> > *name,
> > nor->flash_is_locked = stm_is_locked;
> > }
> >
> > + /* NOR protection support for ISSI chips */
> > + if (JEDEC_MFR(info) == SNOR_MFR_ISSI ||
> > + info->flags & SPI_NOR_HAS_LOCK) {
> > + nor->flash_unlock = issi_unlock;
> > +
> > + }
> > if (nor->flash_lock && nor->flash_unlock && nor->flash_is_locked) {
> > mtd->_lock = spi_nor_lock;
> > mtd->_unlock = spi_nor_unlock;
> > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> > index ff13297..9a7d719 100644
> > --- a/include/linux/mtd/spi-nor.h
> > +++ b/include/linux/mtd/spi-nor.h
> > @@ -127,6 +127,7 @@
> > #define SR_BP0 BIT(2) /* Block protect 0 */
> > #define SR_BP1 BIT(3) /* Block protect 1 */
> > #define SR_BP2 BIT(4) /* Block protect 2 */
> > +#define SR_BP3 BIT(5) /* Block protect 3 for ISSI
> > device*/
> > #define SR_TBBIT(5) /* Top/Bottom protect */
> > #define SR_SRWD BIT(7) /* SR write protect */
> > /* Spansion/Cypress specific status bits */
> > --
> > 1.9.1
> >
> >
Re: [PATCH v2 1/3] mtd: spi-nor: add support for is25wp256
Thank you Paul, for your review comments.
On Tue, Apr 30, 2019 at 10:33 PM Paul Walmsley wrote:
>
> On Sun, 28 Apr 2019, Sagar Shrikant Kadam wrote:
>
> > Update spi_nor_id tablet for is25wp256 (32MB)device from ISSI,
> > present on HiFive Unleashed dev board (Rev: A00).
> >
> > Set method to enable quad mode for ISSI device in flash parameters
> > table.
>
> This patch was based on one originally written by Wes and/or Palmer:
> https://github.com/riscv/riscv-linux/commit/c94e267766d62bc9a669611c3d0c8ed5ea26569b
>
> The right thing to do is to note this in the commit message.
>
Yes true, this is important as well.
I had mentioned this in the covering letter, but I missed to add the
details into the commit message,
I will submit V3 for this.
> > Signed-off-by: Sagar Shrikant Kadam
> > ---
> > drivers/mtd/spi-nor/spi-nor.c | 10 +-
> > include/linux/mtd/spi-nor.h | 1 +
> > 2 files changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> > index fae1474..c5408ed 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -1834,6 +1834,10 @@ static int sr2_bit7_quad_enable(struct spi_nor *nor)
> > SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > { "is25wp128", INFO(0x9d7018, 0, 64 * 1024, 256,
> > SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > + { "is25wp256", INFO(0x9d7019, 0, 64 * 1024, 1024,
> > + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
> > + SPI_NOR_4B_OPCODES)
> > + },
> >
> > /* Macronix */
> > { "mx25l512e", INFO(0xc22010, 0, 64 * 1024, 1, SECT_4K) },
> > @@ -3650,6 +3654,10 @@ static int spi_nor_init_params(struct spi_nor *nor,
> > case SNOR_MFR_MACRONIX:
> > params->quad_enable = macronix_quad_enable;
> > break;
> > + case SNOR_MFR_ISSI:
> > + params->quad_enable = macronix_quad_enable;
> > + break;
> > +
> >
> > case SNOR_MFR_ST:
> > case SNOR_MFR_MICRON:
> > @@ -4127,7 +4135,7 @@ int spi_nor_scan(struct spi_nor *nor, const char
> > *name,
> > if (ret)
> > return ret;
> >
> > - if (nor->addr_width) {
> > + if (nor->addr_width && JEDEC_MFR(info) != SNOR_MFR_ISSI) {
> > /* already configured from SFDP */
> > } else if (info->addr_width) {
> > nor->addr_width = info->addr_width;
> > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> > index b3d360b..ff13297 100644
> > --- a/include/linux/mtd/spi-nor.h
> > +++ b/include/linux/mtd/spi-nor.h
> > @@ -19,6 +19,7 @@
> > #define SNOR_MFR_ATMEL CFI_MFR_ATMEL
> > #define SNOR_MFR_GIGADEVICE 0xc8
> > #define SNOR_MFR_INTEL CFI_MFR_INTEL
> > +#define SNOR_MFR_ISSI0x9d/* ISSI */
> > #define SNOR_MFR_ST CFI_MFR_ST /* ST Micro */
> > #define SNOR_MFR_MICRON CFI_MFR_MICRON /* Micron */
> > #define SNOR_MFR_MACRONIXCFI_MFR_MACRONIX
> > --
> > 1.9.1
> >
> >
