| Message ID | 20250510-wmt-sflash-v1-1-02a1ac6adf12@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | mtd: spi-nor: Add VIA/WonderMedia serial flash controller driver | expand |
On Sat, May 10, 2025 at 11:42:21PM +0400, Alexey Charkov wrote: > Add a binding for the serial flash controller found on VIA/WonderMedia > SoCs, which provides semi-transparent access to SPI NOR chips by > mapping their contents to the physical CPU address space. > > Signed-off-by: Alexey Charkov <alchark@gmail.com> > --- > .../devicetree/bindings/spi/via,vt8500-sflash.yaml | 122 +++++++++++++++++++++ > MAINTAINERS | 1 + > 2 files changed, 123 insertions(+) > > diff --git a/Documentation/devicetree/bindings/spi/via,vt8500-sflash.yaml b/Documentation/devicetree/bindings/spi/via,vt8500-sflash.yaml > new file mode 100644 > index 0000000000000000000000000000000000000000..d2ea0dacdd56118c0cb5a1cb510ceb7591e1e5ca > --- /dev/null > +++ b/Documentation/devicetree/bindings/spi/via,vt8500-sflash.yaml > @@ -0,0 +1,122 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/spi/via,vt8500-sflash.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: VIA/WonderMedia serial flash controller > + > +description: > + This controller is used on VIA/WonderMedia SoCs such as VIA VT8500, > + WonderMedia WM8850 and similar. It provides a semi-transparent interface > + for reading and writing SPI NOR chip contents via a physical memory map, > + abstracting away all SPI communication, while also providing a direct > + mechanism for issuing "programmable commands" to the underlying SPI chip > + > +maintainers: > + - Alexey Charkov <alchark@gmail.com> > + > +properties: > + compatible: > + enum: > + - via,vt8500-sflash > + - wm,wm8505-sflash > + - wm,wm8650-sflash > + - wm,wm8750-sflash > + - wm,wm8850-sflash > + > + reg: > + items: > + - description: MMIO registers region of the controller > + - description: > + Physical memory region within which the controller will map the > + flash contents of chip 0 for reading and writing. If the flash > + size is smaller than this region, it will be mapped at its end. > + Note that if this chip is used as the boot device (as is most > + often the case), the boot ROM maps it at the very end of the > + CPU address space (i.e. ending at 0xffffffff) Period needed on the end. > + - description: > + Physical memory region within which the controller will map the > + flash contents of chip 1 for reading and writing. If the flash > + size is smaller than this region, it will be mapped at its end Period needed on the end. > + > + reg-names: > + items: > + - const: io > + - const: chip0-mmap > + - const: chip1-mmap > + > + clocks: > + maxItems: 1 > + > + "#address-cells": > + const: 1 > + > + "#size-cells": > + const: 0 This follows the SPI binding, right? Drop these 2 and add a $ref to spi-controller.yaml. > + > +patternProperties: > + "^flash@[0-1]$": > + type: object > + additionalProperties: true > + > + properties: > + reg: > + minimum: 0 > + maximum: 1 > + > +required: > + - compatible > + - reg > + - reg-names > + - clocks > + > +unevaluatedProperties: false > + > +examples: > + - | > + sflash: spi-nor-controller@d8002000 { spi@... > + compatible = "wm,wm8850-sflash"; > + reg = <0xd8002000 0x400>, > + <0xff800000 0x800000>, > + <0xef800000 0x800000>; > + reg-names = "io", "chip0-mmap", "chip1-mmap"; > + clocks = <&clksf>; > + #address-cells = <1>; > + #size-cells = <0>; > + > + flash@0 { > + compatible = "jedec,spi-nor"; > + reg = <0>; > + > + partitions { > + compatible = "fixed-partitions"; > + #address-cells = <1>; > + #size-cells = <1>; > + > + partition@0 { > + label = "U-boot"; The somewhat standard value here is 'u-boot'. > + reg = <0 0x50000>; > + read-only; > + }; > + > + partition@1 { > + label = "U-boot environment 1"; u-boot-env > + reg = <0x50000 0x10000>; > + }; > + > + partition@2 { > + label = "U-boot environment 2"; alt-u-boot-env or u-boot-env-backup? > + reg = <0x60000 0x10000>; > + }; > + > + partition@3 { > + label = "W-load"; > + reg = <0x70000 0x10000>; > + read-only; > + }; > + }; > + }; > + }; > + > +... > diff --git a/MAINTAINERS b/MAINTAINERS > index 6dbdf02d6b0c9357ad1da520a0f6c16b7f38f879..f09c457bbfc5ef71a3f8379c111bac52b767cbbc 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3475,6 +3475,7 @@ F: Documentation/devicetree/bindings/hwinfo/via,vt8500-scc-id.yaml > F: Documentation/devicetree/bindings/i2c/wm,wm8505-i2c.yaml > F: Documentation/devicetree/bindings/interrupt-controller/via,vt8500-intc.yaml > F: Documentation/devicetree/bindings/pwm/via,vt8500-pwm.yaml > +F: Documentation/devicetree/bindings/spi/via,vt8500-sflash.yaml > F: arch/arm/boot/dts/vt8500/ > F: arch/arm/mach-vt8500/ > F: drivers/clocksource/timer-vt8500.c > > -- > 2.49.0 >
On Wed, May 14, 2025 at 11:42 PM Rob Herring <robh@kernel.org> wrote: > > On Sat, May 10, 2025 at 11:42:21PM +0400, Alexey Charkov wrote: > > Add a binding for the serial flash controller found on VIA/WonderMedia > > SoCs, which provides semi-transparent access to SPI NOR chips by > > mapping their contents to the physical CPU address space. > > > > Signed-off-by: Alexey Charkov <alchark@gmail.com> > > --- > > .../devicetree/bindings/spi/via,vt8500-sflash.yaml | 122 +++++++++++++++++++++ > > MAINTAINERS | 1 + > > 2 files changed, 123 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/spi/via,vt8500-sflash.yaml b/Documentation/devicetree/bindings/spi/via,vt8500-sflash.yaml > > new file mode 100644 > > index 0000000000000000000000000000000000000000..d2ea0dacdd56118c0cb5a1cb510ceb7591e1e5ca > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/spi/via,vt8500-sflash.yaml > > @@ -0,0 +1,122 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/spi/via,vt8500-sflash.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: VIA/WonderMedia serial flash controller > > + > > +description: > > + This controller is used on VIA/WonderMedia SoCs such as VIA VT8500, > > + WonderMedia WM8850 and similar. It provides a semi-transparent interface > > + for reading and writing SPI NOR chip contents via a physical memory map, > > + abstracting away all SPI communication, while also providing a direct > > + mechanism for issuing "programmable commands" to the underlying SPI chip > > + > > +maintainers: > > + - Alexey Charkov <alchark@gmail.com> > > + > > +properties: > > + compatible: > > + enum: > > + - via,vt8500-sflash > > + - wm,wm8505-sflash > > + - wm,wm8650-sflash > > + - wm,wm8750-sflash > > + - wm,wm8850-sflash > > + > > + reg: > > + items: > > + - description: MMIO registers region of the controller > > + - description: > > + Physical memory region within which the controller will map the > > + flash contents of chip 0 for reading and writing. If the flash > > + size is smaller than this region, it will be mapped at its end. > > + Note that if this chip is used as the boot device (as is most > > + often the case), the boot ROM maps it at the very end of the > > + CPU address space (i.e. ending at 0xffffffff) > > Period needed on the end. Noted, thank you! Will adjust in the next version. > > + - description: > > + Physical memory region within which the controller will map the > > + flash contents of chip 1 for reading and writing. If the flash > > + size is smaller than this region, it will be mapped at its end > > Period needed on the end. Ditto. > > + > > + reg-names: > > + items: > > + - const: io > > + - const: chip0-mmap > > + - const: chip1-mmap > > + > > + clocks: > > + maxItems: 1 > > + > > + "#address-cells": > > + const: 1 > > + > > + "#size-cells": > > + const: 0 > > This follows the SPI binding, right? Drop these 2 and add a $ref to > spi-controller.yaml. Need some advice here. While this controller speaks SPI protocol to its connected flash chips, it's a special-purpose thing that doesn't expose much SPI functionality to the outside world, nor can it drive any SPI devices other than SPI NOR flash. Does that still qualify as an SPI controller as far as the bindings are concerned? Happy to reference the spi-controller.yaml binding if so. > > +patternProperties: > > + "^flash@[0-1]$": > > + type: object > > + additionalProperties: true > > + > > + properties: > > + reg: > > + minimum: 0 > > + maximum: 1 > > + > > +required: > > + - compatible > > + - reg > > + - reg-names > > + - clocks > > + > > +unevaluatedProperties: false > > + > > +examples: > > + - | > > + sflash: spi-nor-controller@d8002000 { > > spi@... Related to the question above... Happy to call it spi@ if appropriate in this case. > > + compatible = "wm,wm8850-sflash"; > > + reg = <0xd8002000 0x400>, > > + <0xff800000 0x800000>, > > + <0xef800000 0x800000>; > > + reg-names = "io", "chip0-mmap", "chip1-mmap"; > > + clocks = <&clksf>; > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + flash@0 { > > + compatible = "jedec,spi-nor"; > > + reg = <0>; > > + > > + partitions { > > + compatible = "fixed-partitions"; > > + #address-cells = <1>; > > + #size-cells = <1>; > > + > > + partition@0 { > > + label = "U-boot"; > > The somewhat standard value here is 'u-boot'. Noted, thanks - will adjust in the next version. > > + reg = <0 0x50000>; > > + read-only; > > + }; > > + > > + partition@1 { > > + label = "U-boot environment 1"; > > u-boot-env Ditto. > > + reg = <0x50000 0x10000>; > > + }; > > + > > + partition@2 { > > + label = "U-boot environment 2"; > > alt-u-boot-env or u-boot-env-backup? Ditto. Thanks for your review and comments Rob! Best regards, Alexey
On 15/05/2025 21:50, Alexey Charkov wrote: >>> + >>> + "#address-cells": >>> + const: 1 >>> + >>> + "#size-cells": >>> + const: 0 >> >> This follows the SPI binding, right? Drop these 2 and add a $ref to >> spi-controller.yaml. > > Need some advice here. While this controller speaks SPI protocol to > its connected flash chips, it's a special-purpose thing that doesn't > expose much SPI functionality to the outside world, nor can it drive > any SPI devices other than SPI NOR flash. Does that still qualify as > an SPI controller as far as the bindings are concerned? > > Happy to reference the spi-controller.yaml binding if so. SPI NOR flashes are still child devices of an SPI controller. You can look at other examples - aren't they all using spi-controller? Why this would be different? Unless you found some cases that are different, but then which ones? Best regards, Krzysztof
On Fri, Jun 6, 2025 at 12:29 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On 15/05/2025 21:50, Alexey Charkov wrote: > >>> + > >>> + "#address-cells": > >>> + const: 1 > >>> + > >>> + "#size-cells": > >>> + const: 0 > >> > >> This follows the SPI binding, right? Drop these 2 and add a $ref to > >> spi-controller.yaml. > > > > Need some advice here. While this controller speaks SPI protocol to > > its connected flash chips, it's a special-purpose thing that doesn't > > expose much SPI functionality to the outside world, nor can it drive > > any SPI devices other than SPI NOR flash. Does that still qualify as > > an SPI controller as far as the bindings are concerned? > > > > Happy to reference the spi-controller.yaml binding if so. > > SPI NOR flashes are still child devices of an SPI controller. You can > look at other examples - aren't they all using spi-controller? Why this > would be different? Unless you found some cases that are different, but > then which ones? No strong opinions here, and no expectation of any special treatment :) Just wanted to consult on what's most appropriate. My (subjective and perhaps unfounded) expectation when seeing something advertise itself as an SPI controller was that it would be a general purpose SPI master, to which one can e.g. connect an SPI driven LCD screen and get it to work with generic Linux SPI infrastructure - which would not be possible with this single-purpose NOR-only flash controller. Given that I don't know how flexible or restrictive other examples are in terms of driving arbitrary SPI devices, I thought it's better to just ask. What I'm getting from this exchange here is that I'd better use the spi-controller binding and respective node names regardless of the fact that this controller cannot drive arbitrary SPI devices beyond NOR flash (which, as I'm getting, is irrelevant after all). Best regards, Alexey
Hi Alexey, >> > Happy to reference the spi-controller.yaml binding if so. >> >> SPI NOR flashes are still child devices of an SPI controller. You can >> look at other examples - aren't they all using spi-controller? Why this >> would be different? Unless you found some cases that are different, but >> then which ones? > > No strong opinions here, and no expectation of any special treatment > :) Just wanted to consult on what's most appropriate. > > My (subjective and perhaps unfounded) expectation when seeing > something advertise itself as an SPI controller was that it would be a > general purpose SPI master, to which one can e.g. connect an SPI > driven LCD screen and get it to work with generic Linux SPI > infrastructure - which would not be possible with this single-purpose > NOR-only flash controller. Given that I don't know how flexible or > restrictive other examples are in terms of driving arbitrary SPI > devices, I thought it's better to just ask. > > What I'm getting from this exchange here is that I'd better use the > spi-controller binding and respective node names regardless of the > fact that this controller cannot drive arbitrary SPI devices beyond > NOR flash (which, as I'm getting, is irrelevant after all). Just for information, there are several SPI controllers which are optimized for flash handling (not only NOR, though) and for that we have a spi-mem layer which allows to reference a set of SPI memory "only" callbacks. On the description side though, these controllers are like all other SPI controllers, so the same controller bindings may apply. Thanks, Miquèl
On Mon, Jun 9, 2025 at 1:07 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > Hi Alexey, > > >> > Happy to reference the spi-controller.yaml binding if so. > >> > >> SPI NOR flashes are still child devices of an SPI controller. You can > >> look at other examples - aren't they all using spi-controller? Why this > >> would be different? Unless you found some cases that are different, but > >> then which ones? > > > > No strong opinions here, and no expectation of any special treatment > > :) Just wanted to consult on what's most appropriate. > > > > My (subjective and perhaps unfounded) expectation when seeing > > something advertise itself as an SPI controller was that it would be a > > general purpose SPI master, to which one can e.g. connect an SPI > > driven LCD screen and get it to work with generic Linux SPI > > infrastructure - which would not be possible with this single-purpose > > NOR-only flash controller. Given that I don't know how flexible or > > restrictive other examples are in terms of driving arbitrary SPI > > devices, I thought it's better to just ask. > > > > What I'm getting from this exchange here is that I'd better use the > > spi-controller binding and respective node names regardless of the > > fact that this controller cannot drive arbitrary SPI devices beyond > > NOR flash (which, as I'm getting, is irrelevant after all). > > Just for information, there are several SPI controllers which are > optimized for flash handling (not only NOR, though) and for that we have > a spi-mem layer which allows to reference a set of SPI memory "only" > callbacks. On the description side though, these controllers are like > all other SPI controllers, so the same controller bindings may apply. Noted, thank you Miquèl! Best regards, Alexey
diff --git a/Documentation/devicetree/bindings/spi/via,vt8500-sflash.yaml b/Documentation/devicetree/bindings/spi/via,vt8500-sflash.yaml new file mode 100644 index 0000000000000000000000000000000000000000..d2ea0dacdd56118c0cb5a1cb510ceb7591e1e5ca --- /dev/null +++ b/Documentation/devicetree/bindings/spi/via,vt8500-sflash.yaml @@ -0,0 +1,122 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/via,vt8500-sflash.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: VIA/WonderMedia serial flash controller + +description: + This controller is used on VIA/WonderMedia SoCs such as VIA VT8500, + WonderMedia WM8850 and similar. It provides a semi-transparent interface + for reading and writing SPI NOR chip contents via a physical memory map, + abstracting away all SPI communication, while also providing a direct + mechanism for issuing "programmable commands" to the underlying SPI chip + +maintainers: + - Alexey Charkov <alchark@gmail.com> + +properties: + compatible: + enum: + - via,vt8500-sflash + - wm,wm8505-sflash + - wm,wm8650-sflash + - wm,wm8750-sflash + - wm,wm8850-sflash + + reg: + items: + - description: MMIO registers region of the controller + - description: + Physical memory region within which the controller will map the + flash contents of chip 0 for reading and writing. If the flash + size is smaller than this region, it will be mapped at its end. + Note that if this chip is used as the boot device (as is most + often the case), the boot ROM maps it at the very end of the + CPU address space (i.e. ending at 0xffffffff) + - description: + Physical memory region within which the controller will map the + flash contents of chip 1 for reading and writing. If the flash + size is smaller than this region, it will be mapped at its end + + reg-names: + items: + - const: io + - const: chip0-mmap + - const: chip1-mmap + + clocks: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^flash@[0-1]$": + type: object + additionalProperties: true + + properties: + reg: + minimum: 0 + maximum: 1 + +required: + - compatible + - reg + - reg-names + - clocks + +unevaluatedProperties: false + +examples: + - | + sflash: spi-nor-controller@d8002000 { + compatible = "wm,wm8850-sflash"; + reg = <0xd8002000 0x400>, + <0xff800000 0x800000>, + <0xef800000 0x800000>; + reg-names = "io", "chip0-mmap", "chip1-mmap"; + clocks = <&clksf>; + #address-cells = <1>; + #size-cells = <0>; + + flash@0 { + compatible = "jedec,spi-nor"; + reg = <0>; + + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + partition@0 { + label = "U-boot"; + reg = <0 0x50000>; + read-only; + }; + + partition@1 { + label = "U-boot environment 1"; + reg = <0x50000 0x10000>; + }; + + partition@2 { + label = "U-boot environment 2"; + reg = <0x60000 0x10000>; + }; + + partition@3 { + label = "W-load"; + reg = <0x70000 0x10000>; + read-only; + }; + }; + }; + }; + +... diff --git a/MAINTAINERS b/MAINTAINERS index 6dbdf02d6b0c9357ad1da520a0f6c16b7f38f879..f09c457bbfc5ef71a3f8379c111bac52b767cbbc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3475,6 +3475,7 @@ F: Documentation/devicetree/bindings/hwinfo/via,vt8500-scc-id.yaml F: Documentation/devicetree/bindings/i2c/wm,wm8505-i2c.yaml F: Documentation/devicetree/bindings/interrupt-controller/via,vt8500-intc.yaml F: Documentation/devicetree/bindings/pwm/via,vt8500-pwm.yaml +F: Documentation/devicetree/bindings/spi/via,vt8500-sflash.yaml F: arch/arm/boot/dts/vt8500/ F: arch/arm/mach-vt8500/ F: drivers/clocksource/timer-vt8500.c
Add a binding for the serial flash controller found on VIA/WonderMedia SoCs, which provides semi-transparent access to SPI NOR chips by mapping their contents to the physical CPU address space. Signed-off-by: Alexey Charkov <alchark@gmail.com> --- .../devicetree/bindings/spi/via,vt8500-sflash.yaml | 122 +++++++++++++++++++++ MAINTAINERS | 1 + 2 files changed, 123 insertions(+)