| Message ID | 20240418121116.22184-2-kabel@kernel.org (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Arnd Bergmann |
| Headers | show |
| Series | Turris Omnia MCU driver | expand |
On Thu, Apr 18, 2024 at 02:11:06PM +0200, Marek Behún wrote: > Add binding for cznic,turris-omnia-mcu, the device-tree node > representing the system-controller features provided by the MCU on the > Turris Omnia router. > > Signed-off-by: Marek Behún <kabel@kernel.org> > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > --- > .../bindings/arm/cznic,turris-omnia-mcu.yaml | 86 +++++++++++++++++++ Why's this in bindings/arm btw? Seems like it is some remote firmware if it is running off-SoC on an MCU, so either remoteproc or firmware would make more sense? Tying it to arm at least needs an explanation IMO.
On Thu, Apr 18, 2024 at 04:43:54PM +0100, Conor Dooley wrote: > On Thu, Apr 18, 2024 at 02:11:06PM +0200, Marek Behún wrote: > > Add binding for cznic,turris-omnia-mcu, the device-tree node > > representing the system-controller features provided by the MCU on the > > Turris Omnia router. > > > > Signed-off-by: Marek Behún <kabel@kernel.org> > > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > --- > > .../bindings/arm/cznic,turris-omnia-mcu.yaml | 86 +++++++++++++++++++ > > Why's this in bindings/arm btw? Seems like it is some remote firmware if > it is running off-SoC on an MCU, so either remoteproc or firmware would > make more sense? Tying it to arm at least needs an explanation IMO. This was discussed with Krzysztof in v1, you can look it up at https://lore.kernel.org/soc/20230824131736.067c40e2@dellmb/ Basically the SoC is an ARM board, and the MCU is also always ARM. I'm guessing firmware would also make sense...
On Fri, Apr 19, 2024 at 10:23:37AM +0200, Marek Behún wrote: > On Thu, Apr 18, 2024 at 04:43:54PM +0100, Conor Dooley wrote: > > On Thu, Apr 18, 2024 at 02:11:06PM +0200, Marek Behún wrote: > > > Add binding for cznic,turris-omnia-mcu, the device-tree node > > > representing the system-controller features provided by the MCU on the > > > Turris Omnia router. > > > > > > Signed-off-by: Marek Behún <kabel@kernel.org> > > > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > > --- > > > .../bindings/arm/cznic,turris-omnia-mcu.yaml | 86 +++++++++++++++++++ > > > > Why's this in bindings/arm btw? Seems like it is some remote firmware if > > it is running off-SoC on an MCU, so either remoteproc or firmware would > > make more sense? Tying it to arm at least needs an explanation IMO. > > This was discussed with Krzysztof in v1, you can look it up at > https://lore.kernel.org/soc/20230824131736.067c40e2@dellmb/ > > Basically the SoC is an ARM board, and the MCU is also always ARM. What I wrote does not make sense. I wanted to say is that the driver drives the peripherals implemented by the Turris Omnia MCU firmware, and the Turris Omnia router is based on an ARM SoC, and that the MCU is also an ARM-based MCU. > > I'm guessing firmware would also make sense... >
On Fri, Apr 19, 2024 at 01:14:45PM +0200, Marek Behún wrote: > On Fri, Apr 19, 2024 at 10:23:37AM +0200, Marek Behún wrote: > > On Thu, Apr 18, 2024 at 04:43:54PM +0100, Conor Dooley wrote: > > > On Thu, Apr 18, 2024 at 02:11:06PM +0200, Marek Behún wrote: > > > > Add binding for cznic,turris-omnia-mcu, the device-tree node > > > > representing the system-controller features provided by the MCU on the > > > > Turris Omnia router. > > > > > > > > Signed-off-by: Marek Behún <kabel@kernel.org> > > > > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > > > --- > > > > .../bindings/arm/cznic,turris-omnia-mcu.yaml | 86 +++++++++++++++++++ > > > > > > Why's this in bindings/arm btw? Seems like it is some remote firmware if > > > it is running off-SoC on an MCU, so either remoteproc or firmware would > > > make more sense? Tying it to arm at least needs an explanation IMO. > > > > This was discussed with Krzysztof in v1, you can look it up at > > https://lore.kernel.org/soc/20230824131736.067c40e2@dellmb/ > > > > Basically the SoC is an ARM board, and the MCU is also always ARM. > > What I wrote does not make sense. I wanted to say is that the driver > drives the peripherals implemented by the Turris Omnia MCU firmware, and > the Turris Omnia router is based on an ARM SoC, and that the MCU is also > an ARM-based MCU. Yeah, it didn't really make sense, but I read between the lines. FWIW, I still don't really think that bindings/arm is the right place for it. > > > > > I'm guessing firmware would also make sense... > >
diff --git a/Documentation/devicetree/bindings/arm/cznic,turris-omnia-mcu.yaml b/Documentation/devicetree/bindings/arm/cznic,turris-omnia-mcu.yaml new file mode 100644 index 000000000000..dd9ee21ee24d --- /dev/null +++ b/Documentation/devicetree/bindings/arm/cznic,turris-omnia-mcu.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/cznic,turris-omnia-mcu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: CZ.NIC's Turris Omnia MCU + +maintainers: + - Marek Behún <kabel@kernel.org> + +description: + The MCU on Turris Omnia acts as a system controller providing additional + GPIOs, interrupts, watchdog, system power off and wakeup configuration. + +properties: + compatible: + const: cznic,turris-omnia-mcu + + reg: + description: MCU I2C slave address + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + description: | + The first cell specifies the interrupt number (0 to 63), the second cell + specifies interrupt type (which can be one of IRQ_TYPE_EDGE_RISING, + IRQ_TYPE_EDGE_FALLING or IRQ_TYPE_EDGE_BOTH). + The interrupt numbers correspond sequentially to GPIO numbers, taking the + GPIO banks into account: + IRQ number GPIO bank GPIO pin within bank + 0 - 15 0 0 - 15 + 16 - 47 1 0 - 31 + 48 - 63 2 0 - 15 + There are several exceptions: + IRQ number meaning + 11 LED panel brightness changed by button press + 13 TRNG entropy ready + 14 ECDSA message signature computation done + + gpio-controller: true + + '#gpio-cells': + const: 3 + description: + The first cell is bank number (0, 1 or 2), the second cell is pin number + within the bank (0 to 15 for banks 0 and 2, 0 to 31 for bank 1), and the + third cell specifies consumer flags. + +required: + - compatible + - reg + - interrupts + - interrupt-controller + - gpio-controller + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + system-controller@2a { + compatible = "cznic,turris-omnia-mcu"; + reg = <0x2a>; + + interrupt-parent = <&gpio1>; + interrupts = <11 IRQ_TYPE_NONE>; + + gpio-controller; + #gpio-cells = <3>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + }; diff --git a/MAINTAINERS b/MAINTAINERS index c23fda1aa1f0..23637ff1e0bc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2141,6 +2141,7 @@ W: https://www.turris.cz/ F: Documentation/ABI/testing/debugfs-moxtet F: Documentation/ABI/testing/sysfs-bus-moxtet-devices F: Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm +F: Documentation/devicetree/bindings/arm/cznic,turris-omnia-mcu.yaml F: Documentation/devicetree/bindings/bus/moxtet.txt F: Documentation/devicetree/bindings/firmware/cznic,turris-mox-rwtm.txt F: Documentation/devicetree/bindings/gpio/gpio-moxtet.txt