* Re: [PATCH v2] arm64: dts: imx8mp: Add DT nodes for the two ISPs
From: Alexander Stein @ 2024-03-26 7:14 UTC (permalink / raw)
To: Laurent Pinchart
Cc: imx, linux-arm-kernel, Paul Elder, Adam Ford, Conor Dooley,
Fabio Estevam, Krzysztof Kozlowski, Marek Vasut,
Pengutronix Kernel Team, Rob Herring, Sascha Hauer, Shawn Guo,
devicetree, linux-media
In-Reply-To: <20240325204924.GY18799@pendragon.ideasonboard.com>
Hi Laurent,
Am Montag, 25. März 2024, 21:49:24 CET schrieb Laurent Pinchart:
> Hi Alexander,
>
> On Mon, Mar 25, 2024 at 04:52:21PM +0100, Alexander Stein wrote:
> > Am Montag, 25. März 2024, 16:13:39 CET schrieb Laurent Pinchart:
> > > From: Paul Elder <paul.elder@ideasonboard.com>
> > >
> > > The ISP supports both CSI and parallel interfaces, where port 0
> > > corresponds to the former and port 1 corresponds to the latter. Since
> > > the i.MX8MP's ISPs are connected by the parallel interface to the CSI
> > > receiver, set them both to port 1.
> > >
> > > Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
> > > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > ---
> > > Changes since v1:
> > >
> > > - Fix clock ordering
> > > - Add #address-cells and #size-cells to ports nodes
> > > ---
> > > arch/arm64/boot/dts/freescale/imx8mp.dtsi | 50 +++++++++++++++++++++++
> > > 1 file changed, 50 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > > index bfc5c81a5bd4..1d2670b91b53 100644
> > > --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > > @@ -1616,6 +1616,56 @@ isi_in_1: endpoint {
> > > };
> > > };
> > >
> > > + isp_0: isp@32e10000 {
> > > + compatible = "fsl,imx8mp-isp";
> > > + reg = <0x32e10000 0x10000>;
> > > + interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&clk IMX8MP_CLK_MEDIA_ISP_ROOT>,
> > > + <&clk IMX8MP_CLK_MEDIA_AXI_ROOT>,
> > > + <&clk IMX8MP_CLK_MEDIA_APB_ROOT>;
> > > + clock-names = "isp", "aclk", "hclk";
> > > + assigned-clocks = <&clk IMX8MP_CLK_MEDIA_ISP>;
> > > + assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_500M>;
> > > + assigned-clock-rates = <500000000>;
> > > + power-domains = <&media_blk_ctrl IMX8MP_MEDIABLK_PD_ISP>;
> > > + fsl,blk-ctrl = <&media_blk_ctrl 0>;
> > > + status = "disabled";
> > > +
> > > + ports {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + port@1 {
> > > + reg = <1>;
> > > + };
> > > + };
> > > + };
> > > +
> > > + isp_1: isp@32e20000 {
> > > + compatible = "fsl,imx8mp-isp";
> > > + reg = <0x32e20000 0x10000>;
> > > + interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&clk IMX8MP_CLK_MEDIA_ISP_ROOT>,
> > > + <&clk IMX8MP_CLK_MEDIA_AXI_ROOT>,
> > > + <&clk IMX8MP_CLK_MEDIA_APB_ROOT>;
> > > + clock-names = "isp", "aclk", "hclk";
> > > + assigned-clocks = <&clk IMX8MP_CLK_MEDIA_ISP>;
> > > + assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_500M>;
> > > + assigned-clock-rates = <500000000>;
> > > + power-domains = <&media_blk_ctrl IMX8MP_MEDIABLK_PD_ISP>;
> > > + fsl,blk-ctrl = <&media_blk_ctrl 1>;
> > > + status = "disabled";
> > > +
> > > + ports {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + port@1 {
> > > + reg = <1>;
> > > + };
> > > + };
> > > + };
> > > +
> >
> > The patch itself is okay. But you might not be able to
> > configure the parent of IMX8MP_CLK_MEDIA_ISP if dewarp is enabled before.
> > This is due to IMX8MP_CLK_MEDIA_ISP_ROOT being enabled in 'pgc_ispdwp'
> > power domain. Reparenting is not possible anymore in this case.
>
> Good point.
>
> > Something like
> > ---8<---
> > --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > @@ -1837,11 +1837,13 @@ media_blk_ctrl: blk-ctrl@32ec0000 {
> > <&clk IMX8MP_CLK_MEDIA_APB>,
> > <&clk IMX8MP_CLK_MEDIA_DISP1_PIX>,
> > <&clk IMX8MP_CLK_MEDIA_DISP2_PIX>,
> > + <&clk IMX8MP_CLK_MEDIA_ISP>,
> > <&clk IMX8MP_VIDEO_PLL1>;
> > assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_1000M>,
> > <&clk IMX8MP_SYS_PLL1_800M>,
> > <&clk IMX8MP_VIDEO_PLL1_OUT>,
> > - <&clk IMX8MP_VIDEO_PLL1_OUT>;
> > + <&clk IMX8MP_VIDEO_PLL1_OUT>,
> > + <&clk IMX8MP_SYS_PLL2_500M>;
> > assigned-clock-rates = <500000000>, <200000000>,
> > <0>, <0>, <1039500000>;
>
> With an assigned clock rate here too then ?
You are right. This posted diff is what I was using for a while now though.
Apparently the clock frequency was still correct.
Best regards,
Alexander
> > #power-domain-cells = <1>;
> > ---8<---
> > is needed.
>
> Sascha, are you OK with this approach ?
>
> > > dewarp: dwe@32e30000 {
> > > compatible = "nxp,imx8mp-dw100";
> > > reg = <0x32e30000 0x10000>;
> > >
> > > base-commit: 4cece764965020c22cff7665b18a012006359095
>
>
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
^ permalink raw reply
* [PATCH v1] ARM: dts: aspeed: yosemite4: set bus13 frequency to 100k
From: Delphine CC Chiu @ 2024-03-26 7:17 UTC (permalink / raw)
To: patrick
Cc: Delphine CC Chiu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel
Since the ocp debug card only supports 100k, the bus is also set to 100k.
Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu@wiwynn.com>
---
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index 64075cc41d92..98e58e3fea77 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -369,7 +369,7 @@ rtc@6f {
&i2c13 {
status = "okay";
- bus-frequency = <400000>;
+ bus-frequency = <100000>;
};
&i2c14 {
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 1/3] dt-bindings: hsi: hsi-client: convert to YAML
From: Krzysztof Kozlowski @ 2024-03-26 7:18 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sebastian Reichel
Cc: Tony Lindgren, devicetree, linux-omap, linux-kernel
In-Reply-To: <20240325-hsi-dt-binding-v1-1-88e8e97c3aae@collabora.com>
On 25/03/2024 22:45, Sebastian Reichel wrote:
> Convert the legacy txt binding to modern YAML and rename from
> client-devices to hsi-client. No semantic change.
There is semantic change: missing example (which is reasonable for
shared schema) but more importantly: some properties are now excluding
each other.
>
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> ---
...
> diff --git a/Documentation/devicetree/bindings/hsi/hsi-client.yaml b/Documentation/devicetree/bindings/hsi/hsi-client.yaml
> new file mode 100644
> index 000000000000..df6e1fdd2702
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hsi/hsi-client.yaml
> @@ -0,0 +1,84 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hsi/hsi-client.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: HSI bus peripheral
> +
> +description:
> + Each HSI port is supposed to have one child node, which
> + symbols the remote device connected to the HSI port.
> +
> +maintainers:
> + - Sebastian Reichel <sre@kernel.org>
> +
> +properties:
> + $nodename:
> + const: hsi-client
Why? Does anything depend on this? It breaks generic-node-name rule. It
seems you need it only to match the schema, but this just point to main
problem - missing bus schema.
> +
> + hsi-channel-ids:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + minItems: 1
> + maxItems: 8
> +
> + hsi-channel-names:
> + minItems: 1
> + maxItems: 8
> +
> + hsi-rx-mode:
> + enum: [stream, frame]
> + description: Receiver Bit transmission mode
> +
> + hsi-tx-mode:
> + enum: [stream, frame]
> + description: Transmitter Bit transmission mode
> +
> + hsi-mode:
> + enum: [stream, frame]
> + description:
> + May be used instead hsi-rx-mode and hsi-tx-mode if the
> + transmission mode is the same for receiver and transmitter.
> +
> + hsi-speed-kbps:
> + description: Max bit transmission speed in kbit/s
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> + hsi-flow:
> + enum: [synchronized, pipeline]
> + description: RX flow type
> +
> + hsi-arb-mode:
> + enum: [round-robin, priority]
> + description: Arbitration mode for TX frame
> +
> +additionalProperties: true
> +
> +required:
> + - compatible
> + - hsi-channel-ids
> + - hsi-speed-kbps
> + - hsi-flow
> + - hsi-arb-mode
> +
> +anyOf:
> + - required:
> + - hsi-mode
> + - required:
> + - hsi-rx-mode
> + - hsi-tx-mode
> +
> +allOf:
> + - if:
> + required:
> + - hsi-mode
> + then:
> + properties:
> + hsi-rx-mode: false
> + hsi-tx-mode: false
I don't understand what you are trying to achieve here and with anyOf.
It looks like just oneOf. OTOH, old binding did not exclude these
properties.
> + - if:
> + required:
> + - hsi-rx-mode
> + then:
> + properties:
> + hsi-mode: false
>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: hsi: nokia-modem: convert to YAML
From: Krzysztof Kozlowski @ 2024-03-26 7:21 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sebastian Reichel
Cc: Tony Lindgren, devicetree, linux-omap, linux-kernel
In-Reply-To: <20240325-hsi-dt-binding-v1-2-88e8e97c3aae@collabora.com>
On 25/03/2024 22:45, Sebastian Reichel wrote:
> Convert the legacy txt binding to modern YAML.
> No semantic change.
>
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> ---
> .../devicetree/bindings/hsi/nokia-modem.txt | 59 ------------
> .../devicetree/bindings/hsi/nokia-modem.yaml | 101 +++++++++++++++++++++
> 2 files changed, 101 insertions(+), 59 deletions(-)
>
> -};
> diff --git a/Documentation/devicetree/bindings/hsi/nokia-modem.yaml b/Documentation/devicetree/bindings/hsi/nokia-modem.yaml
> new file mode 100644
> index 000000000000..c57cbcc7b722
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hsi/nokia-modem.yaml
Filename should match compatibles. nokia,n9-modem.yaml or nokia,modem.yaml
> @@ -0,0 +1,101 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hsi/nokia-modem.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Nokia modem
> +
> +maintainers:
> + - Sebastian Reichel <sre@kernel.org>
> +
> +properties:
> + compatible:
> + enum:
> + - nokia,n900-modem
> + - nokia,n950-modem
> + - nokia,n9-modem
> +
Aren't hsi-channel-ids related to hsi-channel-names? If so, they should
be here with constraints.
> + hsi-channel-names:
> + items:
> + - const: mcsaab-control
> + - const: speech-control
> + - const: speech-data
> + - const: mcsaab-data
> +
> + interrupts:
> + items:
> + - description: modem reset indication
> +
> + gpios:
> + minItems: 3
> + maxItems: 5
> +
> + gpio-names:
> + items:
> + - const: cmt_apeslpx
> + - const: cmt_rst_rq
> + - const: cmt_en
> + - const: cmt_rst
> + - const: cmt_bsi
> + minItems: 3
> +
> +required:
> + - gpios
> + - gpio-names
> + - interrupts
> +
> +allOf:
> + - $ref: hsi-client.yaml#
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - nokia,n950-modem
> + - nokia,n9-modem
> + then:
> + properties:
> + gpios:
> + maxItems: 3
> + gpio-names:
> + maxItems: 3
> + else:
> + properties:
> + gpios:
> + minItems: 5
> + gpio-names:
> + minItems: 5
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> + hsi-client {
This should be "modem".
> + compatible = "nokia,n900-modem";
> +
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: iio: dac: ti,dac5571: Add DAC081C081 support
From: Jonathan Cameron @ 2024-03-25 22:32 UTC (permalink / raw)
To: Laurent Pinchart, Jonathan Cameron
Cc: devicetree, imx, linux-arm-kernel, Trevor Zaharichuk, Greg Lytle,
Lars-Peter Clausen, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sean Nyekjaer, linux-iio
In-Reply-To: <20240325222308.GA31216@pendragon.ideasonboard.com>
On 25 March 2024 22:23:08 GMT, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
>On Mon, Mar 25, 2024 at 10:56:44PM +0200, Laurent Pinchart wrote:
>> On Mon, Mar 25, 2024 at 08:48:57PM +0000, Jonathan Cameron wrote:
>> > On Mon, 25 Mar 2024 22:32:41 +0200 Laurent Pinchart wrote:
>> >
>> > > The DAC081C081 is a TI DAC whose software interface is compatible with
>> > > the DAC5571. It is the 8-bit version of the DAC121C081, already
>> > > supported by the DAC5571 bindings. Extends the bindings to support this
>> > > chip.
>> > >
>> > > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> >
>> > Hi Laurent,
>> >
>> > Given it's a part number where no one is going to guess it is compatible
>> > with the DAC5571 and that we don't have a history of fallback compatibles
>> > I'm fine with this change, but just wanted to ask is a fallback compatible
>> > useful to you to run with older kernels?
>> >
>> > I should have noticed when Peter added the dac121c081. If we add a fallback
>> > should do that one as well.
>>
>> I've indeed noticed that there should have been a fallback for
>> dac121c081, but didn't stop to ponder why that wasn't the case, and just
>> went along with the flow :-) I agree a fallback could be useful, which
>> would then allow dropping patch 2/5 from this series (*). I can do so if
>> you prefer.
>
>And in that case, should I first introduce support in the bindings for
>"ti,dac121c081", "ti,dac7571" and deprecate usage of "ti,dac121c081"
>alone ?
Yes. Not sure if we need an explicit binding entry for deprecated version...
>
>> * This is not entirely true. While the DAC1081C081 is largely compatible
>> with the DAC5573, they have different values for one of the power-down
>> resistors (2.5kΩ instead of 1kΩ if I recall correctly). To be completely
>> accurate, the driver should report that. We could still use the fallback
>> compatible, reporting the wrong power-down resistor value.
>>
>> > > ---
>> > > Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml | 1 +
>> > > 1 file changed, 1 insertion(+)
>> > >
>> > > diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml b/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
>> > > index 79da0323c327..e59db861e2eb 100644
>> > > --- a/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
>> > > +++ b/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
>> > > @@ -21,6 +21,7 @@ properties:
>> > > - ti,dac5573
>> > > - ti,dac6573
>> > > - ti,dac7573
>> > > + - ti,dac081c081
>> > > - ti,dac121c081
>> > >
>> > > reg:
>
^ permalink raw reply
* Re: [PATCH 3/3] dt-bindings: hsi: omap-ssi: convert to YAML
From: Krzysztof Kozlowski @ 2024-03-26 7:26 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sebastian Reichel
Cc: Tony Lindgren, devicetree, linux-omap, linux-kernel
In-Reply-To: <20240325-hsi-dt-binding-v1-3-88e8e97c3aae@collabora.com>
On 25/03/2024 22:45, Sebastian Reichel wrote:
> Convert the legacy txt binding to modern YAML.
> No semantic change.
You deprecated a property: ti,hwmods. Also will be one more change:
ti,ssi-cawake-gpio->gpios
>
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> ---
> Documentation/devicetree/bindings/hsi/omap-ssi.txt | 102 -----------
> .../devicetree/bindings/hsi/ti,omap-ssi.yaml | 196 +++++++++++++++++++++
> 2 files changed, 196 insertions(+), 102 deletions(-)
>
...
> diff --git a/Documentation/devicetree/bindings/hsi/ti,omap-ssi.yaml b/Documentation/devicetree/bindings/hsi/ti,omap-ssi.yaml
> new file mode 100644
> index 000000000000..eb82f85c25b6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hsi/ti,omap-ssi.yaml
> @@ -0,0 +1,196 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hsi/ti,omap-ssi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: SSI Controller on OMAP SoCs
> +
> +description:
> + OMAP3's Synchronous Serial Interface (SSI) controller implements a
> + legacy variant of MIPI's High Speed Synchronous Serial Interface (HSI),
> + while the controller found inside OMAP4 is supposed to be fully compliant
> + with the HSI standard.
> +
> +maintainers:
> + - Sebastian Reichel <sre@kernel.org>
> +
> +properties:
> + compatible:
> + enum:
> + - ti,omap3-ssi
> + - ti,omap4-hsi
> +
> + reg:
> + items:
> + - description: registers for sys
> + - description: registers for gdd
> +
> + reg-names:
> + items:
> + - const: sys
> + - const: gdd
> +
> + ranges: true
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 1
> +
> + clocks:
> + minItems: 1
> + maxItems: 3
> +
> + clock-names:
> + minItems: 1
> + maxItems: 3
> +
> + interrupts:
> + maxItems: 1
> +
> + interrupt-names:
> + const: gdd_mpu
> +
> + ti,hwmods:
> + const: ssi
> + deprecated: true
> +
> +patternProperties:
> + "[hs]si-port@[0-9a-f]+":
Does anything actually depends on the name? Can these be "port@[0-9a-f]+"?
> + type: object
> +
Drop blank line.
> + additionalProperties: false
> +
> + properties:
> + compatible:
> + enum:
> + - ti,omap3-ssi-port
> + - ti,omap4-hsi-port
> +
> + reg:
> + items:
> + - description: TX registers
> + - description: RX registers
> +
> + reg-names:
> + items:
> + - const: tx
> + - const: rx
> +
> + interrupts:
> + items:
> + - description: MPU interrupt 0
> + - description: MPU interrupt 1
> + minItems: 1
> +
> + ti,ssi-cawake-gpio:
ti,ssi-cawake-gpios
> + description: GPIO signifying CAWAKE events
> + maxItems: 1
> +
> + hsi-client:
> + type: object
On this level, should be explicit: additionalProperties: true
> + $ref: /schemas/hsi/hsi-client.yaml#
> +
> + required:
> + - compatible
> + - reg
> + - reg-names
> + - interrupts
> +
> + allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: ti,omap3-ssi-port
> + then:
> + properties:
> + $nodename:
> + pattern: "^ssi-port@(.*)?$"
> + interrupts:
> + minItems: 2
> + else:
> + properties:
> + $nodename:
> + pattern: "^hsi-port@(.*)?$"
> + interrupts:
> + maxItems: 1
> +
> +additionalProperties: false
This goes after allOf: block
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - ranges
> + - "#address-cells"
> + - "#size-cells"
> + - clocks
> + - clock-names
> + - interrupts
> + - interrupt-names
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: ti,omap3-ssi
> + then:
> + properties:
> + clocks:
> + minItems: 3
> + clock-names:
> + items:
> + - const: ssi_ssr_fck
> + - const: ssi_sst_fck
> + - const: ssi_ick
> + else:
> + properties:
> + clocks:
> + maxItems: 1
> + clock-names:
> + items:
> + - const: hsi_fck
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + ssi-controller@48058000 {
> + compatible = "ti,omap3-ssi";
> + reg = <0x48058000 0x1000>,
> + <0x48059000 0x1000>;
> + reg-names = "sys", "gdd";
> + ranges;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + clocks = <&ssi_ssr_fck>,
> + <&ssi_sst_fck>,
> + <&ssi_ick>;
> + clock-names = "ssi_ssr_fck",
> + "ssi_sst_fck",
> + "ssi_ick";
> + interrupts = <55>;
> + interrupt-names = "gdd_mpu";
> +
> + ssi-port@4805a000 {
> + compatible = "ti,omap3-ssi-port";
Use 4 spaces for example indentation.
> + reg = <0x4805a000 0x800>,
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 3/4] dt-bindings: interconnect: add clock property to enable QOS on SC7280
From: Krzysztof Kozlowski @ 2024-03-26 7:30 UTC (permalink / raw)
To: Odelu Kukatla, Bjorn Andersson, Konrad Dybcio, Georgi Djakov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Kees Cook, cros-qcom-dts-watchers, Gustavo A . R . Silva,
linux-arm-msm, linux-pm, devicetree, linux-kernel,
linux-hardening, quic_rlaggysh, quic_mdtipton
In-Reply-To: <20240325181628.9407-4-quic_okukatla@quicinc.com>
On 25/03/2024 19:16, Odelu Kukatla wrote:
> Added clock property to enable clocks required for accessing
> qos registers.
>
> Signed-off-by: Odelu Kukatla <quic_okukatla@quicinc.com>
> ---
> .../bindings/interconnect/qcom,sc7280-rpmh.yaml | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml
> index b135597d9489..950ecdd5252e 100644
> --- a/Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml
> +++ b/Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml
> @@ -35,6 +35,10 @@ properties:
> reg:
> maxItems: 1
>
> + clocks:
> + minItems: 1
> + maxItems: 2
Why is this flexible? Nothing in commit msg explains that. I gave the
same talk twice, gave there examples, yet it is not enough...
https://elixir.bootlin.com/linux/v6.8/source/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml#L132
> +
> required:
> - compatible
>
> @@ -57,6 +61,7 @@ unevaluatedProperties: false
>
> examples:
> - |
> + #include <dt-bindings/clock/qcom,gcc-sc7280.h>
> interconnect {
> compatible = "qcom,sc7280-clk-virt";
> #interconnect-cells = <2>;
> @@ -69,3 +74,12 @@ examples:
> #interconnect-cells = <2>;
> qcom,bcm-voters = <&apps_bcm_voter>;
If all devices have clocks, then you could add them here. It seems not
all of them have clocks...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] ARM: dts: stm32: add heartbeat led for stm32mp157c-ed1
From: Patrice CHOTARD @ 2024-03-26 7:29 UTC (permalink / raw)
To: Krzysztof Kozlowski, robh+dt, Krzysztof Kozlowski,
alexandre.torgue
Cc: linux-stm32, linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <dc4251d1-8cbb-4a0c-834c-26f16f3f9484@linaro.org>
On 3/25/24 19:29, Krzysztof Kozlowski wrote:
> On 25/03/2024 18:06, patrice.chotard@foss.st.com wrote:
>> From: Patrice Chotard <patrice.chotard@foss.st.com>
>>
>> Add heartbeat led for stm32mp157c-ed1.
>>
>> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
>> ---
>> arch/arm/boot/dts/st/stm32mp157c-ed1.dts | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/st/stm32mp157c-ed1.dts b/arch/arm/boot/dts/st/stm32mp157c-ed1.dts
>> index 66ed5f9921ba..bd727455a7e4 100644
>> --- a/arch/arm/boot/dts/st/stm32mp157c-ed1.dts
>> +++ b/arch/arm/boot/dts/st/stm32mp157c-ed1.dts
>> @@ -24,6 +24,15 @@ chosen {
>> stdout-path = "serial0:115200n8";
>> };
>>
>> + led {
>> + compatible = "gpio-leds";
>> + led-blue {
>> + gpios = <&gpiod 9 GPIO_ACTIVE_HIGH>;
>> + linux,default-trigger = "heartbeat";
>> + default-state = "off";
>
> Please add function and color properties.
Hi Krzysztof
OK i will send a v2
Thanks
Patrice
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: rtc: digicolor-rtc: move to trivial-rtc
From: Krzysztof Kozlowski @ 2024-03-26 7:31 UTC (permalink / raw)
To: Javier Carrasco, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Baruch Siach
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20240325-rtc-yaml-v2-3-ff9f68f43dbc@gmail.com>
On 25/03/2024 22:10, Javier Carrasco wrote:
> Convert existing binding to dtschema to support validation.
>
> This device meets the requirements to be moved to trivial-rtc
> (compatible, reg and a single interrupt).
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> ---
> Documentation/devicetree/bindings/rtc/digicolor-rtc.txt | 17 -----------------
> Documentation/devicetree/bindings/rtc/trivial-rtc.yaml | 2 ++
> 2 files changed, 2 insertions(+), 17 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] usb: dwc2: add support for Sophgo CV18XX/SG200X series SoC
From: Minas Harutyunyan @ 2024-03-26 7:31 UTC (permalink / raw)
To: Inochi Amaoto, Greg Kroah-Hartman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Minas Harutyunyan,
Paul Walmsley, Palmer Dabbelt, Albert Ou
Cc: Chen Wang, Liu Gui, linux-usb@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org
In-Reply-To: <IA1PR20MB4953EE73DD36D5FFC81D90EDBB352@IA1PR20MB4953.namprd20.prod.outlook.com>
On 3/26/24 06:37, Inochi Amaoto wrote:
> Add params for DWC2 IP in Sophgo CV18XX/SG200X series SoC.
>
> Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
Acked-by: Minas Harutyunyan <hminas@synopsys.com>
> ---
> drivers/usb/dwc2/params.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
> index eb677c3cfd0b..171fcb34eb75 100644
> --- a/drivers/usb/dwc2/params.c
> +++ b/drivers/usb/dwc2/params.c
> @@ -201,6 +201,25 @@ static void dwc2_set_amcc_params(struct dwc2_hsotg *hsotg)
> p->ahbcfg = GAHBCFG_HBSTLEN_INCR16 << GAHBCFG_HBSTLEN_SHIFT;
> }
>
> +static void dwc2_set_cv1800_params(struct dwc2_hsotg *hsotg)
> +{
> + struct dwc2_core_params *p = &hsotg->params;
> +
> + p->otg_caps.hnp_support = false;
> + p->otg_caps.srp_support = false;
> + p->host_dma = false;
> + p->g_dma = false;
> + p->speed = DWC2_SPEED_PARAM_HIGH;
> + p->phy_type = DWC2_PHY_TYPE_PARAM_UTMI;
> + p->phy_utmi_width = 16;
> + p->ahbcfg = GAHBCFG_HBSTLEN_INCR16 << GAHBCFG_HBSTLEN_SHIFT;
> + p->lpm = false;
> + p->lpm_clock_gating = false;
> + p->besl = false;
> + p->hird_threshold_en = false;
> + p->power_down = DWC2_POWER_DOWN_PARAM_NONE;
> +}
> +
> static void dwc2_set_stm32f4x9_fsotg_params(struct dwc2_hsotg *hsotg)
> {
> struct dwc2_core_params *p = &hsotg->params;
> @@ -295,6 +314,8 @@ const struct of_device_id dwc2_of_match_table[] = {
> .data = dwc2_set_amlogic_a1_params },
> { .compatible = "amcc,dwc-otg", .data = dwc2_set_amcc_params },
> { .compatible = "apm,apm82181-dwc-otg", .data = dwc2_set_amcc_params },
> + { .compatible = "sophgo,cv1800-usb",
> + .data = dwc2_set_cv1800_params },
> { .compatible = "st,stm32f4x9-fsotg",
> .data = dwc2_set_stm32f4x9_fsotg_params },
> { .compatible = "st,stm32f4x9-hsotg" },
> --
> 2.44.0
>
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: rtc: armada-380-rtc: convert to dtschema
From: Krzysztof Kozlowski @ 2024-03-26 7:32 UTC (permalink / raw)
To: Javier Carrasco, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Baruch Siach
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20240325-rtc-yaml-v2-1-ff9f68f43dbc@gmail.com>
On 25/03/2024 22:10, Javier Carrasco wrote:
> Convert existing binding to dtschema to support validation.
>
> This is a direct conversion with no additions.
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: rtc: alphascale,asm9260-rtc: convert to dtschema
From: Krzysztof Kozlowski @ 2024-03-26 7:34 UTC (permalink / raw)
To: Javier Carrasco, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Baruch Siach
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20240325-rtc-yaml-v2-2-ff9f68f43dbc@gmail.com>
On 25/03/2024 22:10, Javier Carrasco wrote:
> Convert existing binding to dtschema to support validation.
>
> This is a direct conversion with no additions.
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> +allOf:
> + - $ref: rtc.yaml#
> +
> +properties:
> + compatible:
> + const: alphascale,asm9260-rtc
> +
> + reg:
> + description:
> + Base address and length of the register region.
If there is going to be any resend, drop description. It is redundant
and obvious. reg cannot be anything else.
> + maxItems: 1
> +
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 4/4] dt-bindings: rtc: nxp,lpc1788-rtc: convert to dtschema
From: Krzysztof Kozlowski @ 2024-03-26 7:35 UTC (permalink / raw)
To: Javier Carrasco, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Baruch Siach
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20240325-rtc-yaml-v2-4-ff9f68f43dbc@gmail.com>
On 25/03/2024 22:10, Javier Carrasco wrote:
> Convert existing binding to dtschema to support validation.
>
> This is a direct conversion with no additions.
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 1/3] dt-bindings: dmaengine: Add dmamux for CV18XX/SG200X series SoC
From: Inochi Amaoto @ 2024-03-26 7:35 UTC (permalink / raw)
To: Krzysztof Kozlowski, Inochi Amaoto, Vinod Koul, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen Wang, Paul Walmsley,
Palmer Dabbelt, Albert Ou
Cc: Jisheng Zhang, Liu Gui, Jingbao Qiu, dlan, dmaengine, devicetree,
linux-kernel, linux-riscv
In-Reply-To: <57398ee0-212c-4c82-bfed-bf38f4faa111@linaro.org>
On Tue, Mar 26, 2024 at 07:57:44AM +0100, Krzysztof Kozlowski wrote:
> On 26/03/2024 02:47, Inochi Amaoto wrote:
> > The DMA IP of Sophgo CV18XX/SG200X is based on a DW AXI CORE, with
> > an additional channel remap register located in the top system control
> > area. The DMA channel is exclusive to each core.
> >
> > Add the dmamux binding for CV18XX/SG200X series SoC
> >
>
>
> > +
> > +allOf:
> > + - $ref: dma-router.yaml#
> > +
> > +properties:
> > + compatible:
> > + const: sophgo,cv1800-dmamux
> > +
> > + reg:
> > + items:
> > + - description: DMA channal remapping register
> > + - description: DMA channel interrupt mapping register
> > +
> > + '#dma-cells':
> > + const: 2
> > + description:
> > + The first cells is device id. The second one is the cpu id.
> > +
> > + dma-masters:
> > + maxItems: 1
> > +
> > + dma-requests:
> > + const: 8
>
> If this is const, why do you need it in the DTS in the first place?
> compatible defines it.
>
Yes, you are right. I will remove this property.
> > +
> > +required:
> > + - '#dma-cells'
> > + - dma-masters
> > +
>
>
> I don't understand what happened here. Previously you had a child and I
> proposed to properly describe it with $ref.
>
> Now, all children are gone. Binding is supposed to be complete. Based on
> your cover letter, this is not complete, but why? What is missing and
> why it cannot be added?
>
The binding of syscon is removed due to a usb phy subdevices, which needs
sometime to figure out the actual property. This is why the syscon binding
is removed.
I think it is better to use the origianl syscon series to evolve after
the usb phy binding is submitted. The subdevices of syscon may need
much reverse engineering to know its parameters. So at least for now,
the syscon binding is hard to be complete.
>
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + dma-router {
> > + compatible = "sophgo,cv1800-dmamux";
> > + #dma-cells = <2>;
> > + dma-masters = <&dmac>;
> > + dma-requests = <8>;
> > + };
> > diff --git a/include/dt-bindings/dma/cv1800-dma.h b/include/dt-bindings/dma/cv1800-dma.h
> > new file mode 100644
> > index 000000000000..3ce9dac25259
> > --- /dev/null
> > +++ b/include/dt-bindings/dma/cv1800-dma.h
>
> Filename should match bindings filename.
>
Thanks.
>
> Anyway, the problem is that it is a dead header. I don't see it being
> used, so it is not a binding.
>
This header is not used because the dmamux node is not defined at now.
And considering the limitation of this dmamux, maybe only devices that
require dma as a must can have the dma assigned.
Due to the fact, I think it may be a long time to wait for this header
to be used as the binding header.
>
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: input: touchscreen: edt-ft5x06: Add ft5426
From: Krzysztof Kozlowski @ 2024-03-26 7:36 UTC (permalink / raw)
To: Andreas Kemnade, dmitry.torokhov, robh+dt, krzysztof.kozlowski+dt,
conor+dt, o.rempel, dario.binacchi, u.kleine-koenig, hdegoede,
p.puschmann, linux-input, devicetree, linux-kernel,
caleb.connolly
In-Reply-To: <20240325192531.256854-1-andreas@kemnade.info>
On 25/03/2024 20:25, Andreas Kemnade wrote:
> Add compatible for ft5426.
> Searches for documentation reveal neither edt nor evervision
> as some related company, only FocalTech.
>
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> ---
> .../devicetree/bindings/input/touchscreen/edt-ft5x06.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> index f2808cb4d99df..17b05522eacd9 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> @@ -40,6 +40,7 @@ properties:
> - edt,edt-ft5506
> - evervision,ev-ft5726
> - focaltech,ft6236
> + - focaltech,ft5426
Please keep the order, so one line bump.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH V8 00/12] soc: imx8mp: Add support for HDMI
From: Tommaso Merciai @ 2024-03-26 7:46 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Adam Ford, linux-arm-kernel, marex, alexander.stein,
frieder.schrempf, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Philipp Zabel, Vinod Koul, Kishon Vijay Abraham I,
Catalin Marinas, Will Deacon, Liu Ying, Ulf Hansson, Lucas Stach,
dri-devel, devicetree, linux-kernel, linux-phy, linux-pm
In-Reply-To: <20240325220338.GE23988@pendragon.ideasonboard.com>
Hi Laurent,
On Tue, Mar 26, 2024 at 12:03:38AM +0200, Laurent Pinchart wrote:
> Hi Tommaso,
>
> On Mon, Mar 25, 2024 at 10:48:56PM +0100, Tommaso Merciai wrote:
> > Hi Adam, Lucas,
> > Thanks for this series.
> >
> > This series make HDMI work on evk.
> > All is working properly on my side.
> >
> > Tested on: Linux imx8mp-lpddr4-evk 6.9.0-rc1.
> > Hope this help.
> >
> > Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
>
> The DRM side has been merged already. The only missing patches are for
> the PHY, and the latest version can be found in
> https://lore.kernel.org/linux-phy/20240227220444.77566-1-aford173@gmail.com/.
> You can test that series and send a Tested-by tag. I'm crossing my
> fingers and hoping it will be merged in v6.10.
(same here :) )
Thanks for sharing! :)
To be honest I test all this series rebasing my alvium next branch on top of media_stage/master (6.9.0-rc1)
All is working properly on my side.
I found v8 into the commit msg here: https://patches.linaro.org/project/linux-pm/patch/20240203165307.7806-9-aford173@gmail.com/
then I'm thinking this is the latest.
I'm going to switch to your suggestion that looks more recent :)
Thanks again,
Tommaso
>
> > On Sat, Feb 03, 2024 at 10:52:40AM -0600, Adam Ford wrote:
> > > The i.MX8M Plus has an HDMI controller, but it depends on two
> > > other systems, the Parallel Video Interface (PVI) and the
> > > HDMI PHY from Samsung. The LCDIF controller generates the display
> > > and routes it to the PVI which converts passes the parallel video
> > > to the HDMI bridge. The HDMI system has a corresponding power
> > > domain controller whose driver was partially written, but the
> > > device tree for it was never applied, so some changes to the
> > > power domain should be harmless because they've not really been
> > > used yet.
> > >
> > > This series is adapted from multiple series from Lucas Stach with
> > > edits and suggestions from feedback from various series, but it
> > > since it's difficult to use and test them independently,
> > > I merged them into on unified series. The version history is a
> > > bit ambiguous since different components were submitted at different
> > > times and had different amount of retries. In an effort to merge them
> > > I used the highest version attempt.
> > >
> > > Adam Ford (3):
> > > dt-bindings: soc: imx: add missing clock and power-domains to
> > > imx8mp-hdmi-blk-ctrl
> > > pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix
> > > domain
> > > arm64: defconfig: Enable DRM_IMX8MP_DW_HDMI_BRIDGE as module
> > >
> > > Lucas Stach (9):
> > > dt-bindings: phy: add binding for the i.MX8MP HDMI PHY
> > > phy: freescale: add Samsung HDMI PHY
> > > arm64: dts: imx8mp: add HDMI power-domains
> > > arm64: dts: imx8mp: add HDMI irqsteer
> > > dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI
> > > drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
> > > dt-bindings: display: imx: add binding for i.MX8MP HDMI TX
> > > drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI
> > > arm64: dts: imx8mp: add HDMI display pipeline
> > >
> > > .../display/bridge/fsl,imx8mp-hdmi-tx.yaml | 102 ++
> > > .../display/imx/fsl,imx8mp-hdmi-pvi.yaml | 84 ++
> > > .../bindings/phy/fsl,imx8mp-hdmi-phy.yaml | 62 +
> > > .../soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml | 22 +-
> > > arch/arm64/boot/dts/freescale/imx8mp.dtsi | 145 +++
> > > arch/arm64/configs/defconfig | 1 +
> > > drivers/gpu/drm/bridge/imx/Kconfig | 18 +
> > > drivers/gpu/drm/bridge/imx/Makefile | 2 +
> > > drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c | 207 ++++
> > > drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c | 154 +++
> > > drivers/phy/freescale/Kconfig | 6 +
> > > drivers/phy/freescale/Makefile | 1 +
> > > drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 1075 +++++++++++++++++
> > > drivers/pmdomain/imx/imx8mp-blk-ctrl.c | 10 +-
> > > 14 files changed, 1876 insertions(+), 13 deletions(-)
> > > create mode 100644 Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> > > create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
> > > create mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml
> > > create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> > > create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
> > > create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c
>
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply
* [PATCH v2] ARM: dts: stm32: add heartbeat led for stm32mp157c-ed1
From: patrice.chotard @ 2024-03-26 7:54 UTC (permalink / raw)
To: robh+dt, Krzysztof Kozlowski, alexandre.torgue
Cc: linux-stm32, linux-arm-kernel, linux-kernel, devicetree,
Patrice Chotard
From: Patrice Chotard <patrice.chotard@foss.st.com>
Add heartbeat led for stm32mp157c-ed1.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
---
V2 changes :
_ add color and function properties.
arch/arm/boot/dts/st/stm32mp157c-ed1.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/st/stm32mp157c-ed1.dts b/arch/arm/boot/dts/st/stm32mp157c-ed1.dts
index 66ed5f9921ba..525d9ca7d576 100644
--- a/arch/arm/boot/dts/st/stm32mp157c-ed1.dts
+++ b/arch/arm/boot/dts/st/stm32mp157c-ed1.dts
@@ -10,6 +10,7 @@
#include "stm32mp15-pinctrl.dtsi"
#include "stm32mp15xxaa-pinctrl.dtsi"
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
#include <dt-bindings/mfd/st,stpmic1.h>
/ {
@@ -24,6 +25,17 @@ chosen {
stdout-path = "serial0:115200n8";
};
+ led {
+ compatible = "gpio-leds";
+ led-blue {
+ gpios = <&gpiod 9 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ default-state = "off";
+ function = LED_FUNCTION_HEARTBEAT;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+
memory@c0000000 {
device_type = "memory";
reg = <0xC0000000 0x40000000>;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v6 1/2] driver core: Introduce device_link_wait_removal()
From: Herve Codina @ 2024-03-26 7:56 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Rafael J. Wysocki, Rob Herring, Frank Rowand, Saravana Kannan,
Lizhi Hou, Max Zhen, Sonal Santan, Stefano Stabellini,
Jonathan Cameron, linux-kernel, devicetree, Allan Nielsen,
Horatiu Vultur, Steen Hegelund, Luca Ceresoli, Nuno Sa,
Thomas Petazzoni, stable
In-Reply-To: <2024032548-rope-improper-4f67@gregkh>
On Mon, 25 Mar 2024 19:37:10 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Mon, Mar 25, 2024 at 04:21:25PM +0100, Herve Codina wrote:
> > The commit 80dd33cf72d1 ("drivers: base: Fix device link removal")
> > introduces a workqueue to release the consumer and supplier devices used
> > in the devlink.
> > In the job queued, devices are release and in turn, when all the
> > references to these devices are dropped, the release function of the
> > device itself is called.
> >
> > Nothing is present to provide some synchronisation with this workqueue
> > in order to ensure that all ongoing releasing operations are done and
> > so, some other operations can be started safely.
> >
> > For instance, in the following sequence:
> > 1) of_platform_depopulate()
> > 2) of_overlay_remove()
> >
> > During the step 1, devices are released and related devlinks are removed
> > (jobs pushed in the workqueue).
> > During the step 2, OF nodes are destroyed but, without any
> > synchronisation with devlink removal jobs, of_overlay_remove() can raise
> > warnings related to missing of_node_put():
> > ERROR: memory leak, expected refcount 1 instead of 2
> >
> > Indeed, the missing of_node_put() call is going to be done, too late,
> > from the workqueue job execution.
> >
> > Introduce device_link_wait_removal() to offer a way to synchronize
> > operations waiting for the end of devlink removals (i.e. end of
> > workqueue jobs).
> > Also, as a flushing operation is done on the workqueue, the workqueue
> > used is moved from a system-wide workqueue to a local one.
> >
> > Cc: stable@vger.kernel.org
>
> Why is this for stable? You are just adding a new api, no one is using
> it.
>
> Or if they are, you didn't send me that patch...
The patch 2 in this current series uses the new api.
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH v4 2/5] dt-bindings: serial: renesas,scif: Validate 'interrupts' and 'interrupt-names'
From: Geert Uytterhoeven @ 2024-03-26 8:02 UTC (permalink / raw)
To: Biju Das
Cc: Prabhakar, Greg Kroah-Hartman, Jiri Slaby, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-serial@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Fabrizio Castro, Prabhakar Mahadev Lad
In-Reply-To: <OSAPR01MB15871221D42B6CEAA08168C386362@OSAPR01MB1587.jpnprd01.prod.outlook.com>
Hi Biju,
On Mon, Mar 25, 2024 at 5:21 PM Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > -----Original Message-----
> > From: Prabhakar <prabhakar.csengg@gmail.com>
> > Sent: Friday, March 22, 2024 2:44 PM
> > Subject: [PATCH v4 2/5] dt-bindings: serial: renesas,scif: Validate 'interrupts' and 'interrupt-
> > names'
> >
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > This commit adds support to validate the 'interrupts' and 'interrupt-names'
> > properties for every supported SoC. This ensures proper handling and configuration of interrupt-
> > related properties across supported platforms.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> > v3->v4
> > - Reverted back to v2 version of the patch.
> > - Used suggestion from Krzysztof for interrupts
> > - Restored RB tag from Geert
> >
> > v2->v3
> > - Listed interrupts and interrupt-names for every SoC in if check
> > ---
> > .../bindings/serial/renesas,scif.yaml | 73 ++++++++++++++-----
> > 1 file changed, 55 insertions(+), 18 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> > b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> > index af72c3420453..eb2aa5e75e02 100644
> > --- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> > +++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> > @@ -86,11 +86,6 @@ properties:
> > oneOf:
> > - items:
> > - description: A combined interrupt
> > - - items:
> > - - description: Error interrupt
> > - - description: Receive buffer full interrupt
> > - - description: Transmit buffer empty interrupt
> > - - description: Break interrupt
> > - items:
> > - description: Error interrupt
> > - description: Receive buffer full interrupt @@ -98,21 +93,17 @@ properties:
> > - description: Break interrupt
> > - description: Data Ready interrupt
> > - description: Transmit End interrupt
> > + minItems: 4
>
> I think here minItems is 1 as it is either 1 or 4 or 6
The single interrupt is handled by the first case in the oneOf (which
can probably be simplified by dropping the "items"?).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* RE: [PATCH v4 2/5] dt-bindings: serial: renesas,scif: Validate 'interrupts' and 'interrupt-names'
From: Biju Das @ 2024-03-26 8:08 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Prabhakar, Greg Kroah-Hartman, Jiri Slaby, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-serial@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Fabrizio Castro, Prabhakar Mahadev Lad
In-Reply-To: <CAMuHMdXtPPwzgwekKiuNF5MzDvLSOqvBXWgQd4tgPtTnnQp2VQ@mail.gmail.com>
Hi Geert,
> -----Original Message-----
> From: Geert Uytterhoeven <geert@linux-m68k.org>
> Sent: Tuesday, March 26, 2024 8:02 AM
> Subject: Re: [PATCH v4 2/5] dt-bindings: serial: renesas,scif: Validate 'interrupts' and
> 'interrupt-names'
>
> Hi Biju,
>
> On Mon, Mar 25, 2024 at 5:21 PM Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > > -----Original Message-----
> > > From: Prabhakar <prabhakar.csengg@gmail.com>
> > > Sent: Friday, March 22, 2024 2:44 PM
> > > Subject: [PATCH v4 2/5] dt-bindings: serial: renesas,scif: Validate
> > > 'interrupts' and 'interrupt- names'
> > >
> > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > >
> > > This commit adds support to validate the 'interrupts' and 'interrupt-names'
> > > properties for every supported SoC. This ensures proper handling and
> > > configuration of interrupt- related properties across supported platforms.
> > >
> > > Signed-off-by: Lad Prabhakar
> > > <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > ---
> > > v3->v4
> > > - Reverted back to v2 version of the patch.
> > > - Used suggestion from Krzysztof for interrupts
> > > - Restored RB tag from Geert
> > >
> > > v2->v3
> > > - Listed interrupts and interrupt-names for every SoC in if check
> > > ---
> > > .../bindings/serial/renesas,scif.yaml | 73 ++++++++++++++-----
> > > 1 file changed, 55 insertions(+), 18 deletions(-)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> > > b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> > > index af72c3420453..eb2aa5e75e02 100644
> > > --- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> > > +++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> > > @@ -86,11 +86,6 @@ properties:
> > > oneOf:
> > > - items:
> > > - description: A combined interrupt
> > > - - items:
> > > - - description: Error interrupt
> > > - - description: Receive buffer full interrupt
> > > - - description: Transmit buffer empty interrupt
> > > - - description: Break interrupt
> > > - items:
> > > - description: Error interrupt
> > > - description: Receive buffer full interrupt @@ -98,21 +93,17 @@ properties:
> > > - description: Break interrupt
> > > - description: Data Ready interrupt
> > > - description: Transmit End interrupt
> > > + minItems: 4
> >
> > I think here minItems is 1 as it is either 1 or 4 or 6
>
> The single interrupt is handled by the first case in the oneOf (which can probably be simplified by
> dropping the "items"?).
Good point, it is not items, so it can be dropped.
Cheers,
Biju
^ permalink raw reply
* Re: [PATCH v6 04/16] dt-bindings: net: wireless: qcom,ath11k: describe the ath11k on QCA6390
From: Johan Hovold @ 2024-03-26 8:11 UTC (permalink / raw)
To: Kalle Valo
Cc: Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Liam Girdwood, Mark Brown, Catalin Marinas,
Will Deacon, Bjorn Helgaas, Saravana Kannan, Geert Uytterhoeven,
Arnd Bergmann, Neil Armstrong, Marek Szyprowski, Alex Elder,
Srini Kandagatla, Greg Kroah-Hartman, Abel Vesa,
Manivannan Sadhasivam, Lukas Wunner, Dmitry Baryshkov,
linux-bluetooth, netdev, devicetree, linux-kernel, linux-wireless,
linux-arm-msm, linux-arm-kernel, linux-pci, linux-pm,
Bartosz Golaszewski, ath11k
In-Reply-To: <87frwe8jiu.fsf@kernel.org>
On Mon, Mar 25, 2024 at 04:37:29PM +0200, Kalle Valo wrote:
> Bartosz Golaszewski <brgl@bgdev.pl> writes:
> > On Mon, Mar 25, 2024 at 2:57 PM Kalle Valo <kvalo@kernel.org> wrote:
> >> Bartosz Golaszewski <brgl@bgdev.pl> writes:
> >> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >> >
> >> > Add a PCI compatible for the ATH11K module on QCA6390 and describe the
> >> > power inputs from the PMU that it consumes.
> >> >
> >> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >>
> >> [...]
> >>
> >> > +allOf:
> >> > + - if:
> >> > + properties:
> >> > + compatible:
> >> > + contains:
> >> > + const: pci17cb,1101
> >> > + then:
> >> > + required:
> >> > + - vddrfacmn-supply
> >> > + - vddaon-supply
> >> > + - vddwlcx-supply
> >> > + - vddwlmx-supply
> >> > + - vddrfa0p8-supply
> >> > + - vddrfa1p2-supply
> >> > + - vddrfa1p7-supply
> >> > + - vddpcie0p9-supply
> >> > + - vddpcie1p8-supply
> >>
> >> I don't know DT well enough to know what the "required:" above means,
> >> but does this take into account that there are normal "plug&play" type
> >> of QCA6390 boards as well which don't need any DT settings?
> >
> > Do they require a DT node though for some reason?
>
> You can attach the device to any PCI slot, connect the WLAN antenna and
> it just works without DT nodes. I'm trying to make sure here that basic
> setup still works.
>
> Adding also Johan and ath11k list. For example, I don't know what's the
> plan with Lenovo X13s, will it use this framework? I guess in theory we
> could have devices which use qcom,ath11k-calibration-variant from DT but
> not any of these supply properties?
In theory we could, but at least the WCN6855 in the X13s has a similar
set of supplies and enable gpios which are currently not fully described
in the devicetree as there has been no support for doing so thus far.
Instead we rely on the bootloader to enable the module.
I haven't had time to look at the latest attempt on adding support for
handling such resources, but eventually we'll need to address this in
some way.
Johan
^ permalink raw reply
* Re: [PATCH v16 7/9] usb: dwc3: qcom: Refactor IRQ handling in glue driver
From: Krishna Kurapati PSSNV @ 2024-03-26 8:11 UTC (permalink / raw)
To: Johan Hovold
Cc: Krzysztof Kozlowski, Rob Herring, Bjorn Andersson, Wesley Cheng,
Konrad Dybcio, Greg Kroah-Hartman, Conor Dooley, Thinh Nguyen,
Felipe Balbi, devicetree, linux-arm-msm, linux-usb, linux-kernel,
quic_ppratap, quic_jackp
In-Reply-To: <ZgHUR-Rk-YzqiTtt@hovoldconsulting.com>
On 3/26/2024 1:15 AM, Johan Hovold wrote:
> Just change the logic in dwc3_qcom_find_num_ports() so that it returns 1
> if "dp_hs_phy_1" is missing, and otherwise you determine the number of
> ports by iterating from 2 to DWC3_MAX_PORTS - 1.
Hi Johan,
I made this change and it works. Removed any return value check for the
find_num_ports call as it can return only 1/2/3/4 now.
---
irq = platform_get_irq_byname_optional(pdev, "qusb2_phy");
if (irq > 0)
return 1;
irq = platform_get_irq_byname_optional(pdev, "dp_hs_phy_irq");
if (irq > 0)
return 1;
irq = platform_get_irq_byname_optional(pdev, "dp_hs_phy_1");
if (irq <= 0)
return 1;
for (port_index = 1; port_index < DWC3_MAX_PORTS - 1;
port_index++) {
sprintf(irq_name, "dp_hs_phy_%d", port_index + 1);
irq = platform_get_irq_byname_optional(pdev, irq_name);
if (irq <= 0)
return port_index;
}
return DWC3_MAX_PORTS;
---
Let me know if this is fine and I can push out v17.
Regards,
Krishna,
^ permalink raw reply
* Re: [PATCH v6 1/2] driver core: Introduce device_link_wait_removal()
From: Greg Kroah-Hartman @ 2024-03-26 8:20 UTC (permalink / raw)
To: Rob Herring
Cc: Herve Codina, Rafael J. Wysocki, Frank Rowand, Saravana Kannan,
Lizhi Hou, Max Zhen, Sonal Santan, Stefano Stabellini,
Jonathan Cameron, linux-kernel, devicetree, Allan Nielsen,
Horatiu Vultur, Steen Hegelund, Luca Ceresoli, Nuno Sa,
Thomas Petazzoni, stable
In-Reply-To: <20240325164401.GA276583-robh@kernel.org>
On Mon, Mar 25, 2024 at 11:44:01AM -0500, Rob Herring wrote:
> On Mon, Mar 25, 2024 at 04:21:25PM +0100, Herve Codina wrote:
> > The commit 80dd33cf72d1 ("drivers: base: Fix device link removal")
> > introduces a workqueue to release the consumer and supplier devices used
> > in the devlink.
> > In the job queued, devices are release and in turn, when all the
> > references to these devices are dropped, the release function of the
> > device itself is called.
> >
> > Nothing is present to provide some synchronisation with this workqueue
> > in order to ensure that all ongoing releasing operations are done and
> > so, some other operations can be started safely.
> >
> > For instance, in the following sequence:
> > 1) of_platform_depopulate()
> > 2) of_overlay_remove()
> >
> > During the step 1, devices are released and related devlinks are removed
> > (jobs pushed in the workqueue).
> > During the step 2, OF nodes are destroyed but, without any
> > synchronisation with devlink removal jobs, of_overlay_remove() can raise
> > warnings related to missing of_node_put():
> > ERROR: memory leak, expected refcount 1 instead of 2
> >
> > Indeed, the missing of_node_put() call is going to be done, too late,
> > from the workqueue job execution.
> >
> > Introduce device_link_wait_removal() to offer a way to synchronize
> > operations waiting for the end of devlink removals (i.e. end of
> > workqueue jobs).
> > Also, as a flushing operation is done on the workqueue, the workqueue
> > used is moved from a system-wide workqueue to a local one.
> >
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> > Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> > Reviewed-by: Nuno Sa <nuno.sa@analog.com>
> > Reviewed-by: Saravana Kannan <saravanak@google.com>
> > ---
> > drivers/base/core.c | 26 +++++++++++++++++++++++---
> > include/linux/device.h | 1 +
> > 2 files changed, 24 insertions(+), 3 deletions(-)
>
> Greg, can you ack and I'll take this series.
Looks semi-sane:
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH v16 7/9] usb: dwc3: qcom: Refactor IRQ handling in glue driver
From: Johan Hovold @ 2024-03-26 8:28 UTC (permalink / raw)
To: Krishna Kurapati PSSNV
Cc: Krzysztof Kozlowski, Rob Herring, Bjorn Andersson, Wesley Cheng,
Konrad Dybcio, Greg Kroah-Hartman, Conor Dooley, Thinh Nguyen,
Felipe Balbi, devicetree, linux-arm-msm, linux-usb, linux-kernel,
quic_ppratap, quic_jackp
In-Reply-To: <7b4a6d7f-76ad-471f-a178-dc598fbc0e22@quicinc.com>
On Tue, Mar 26, 2024 at 01:41:52PM +0530, Krishna Kurapati PSSNV wrote:
> On 3/26/2024 1:15 AM, Johan Hovold wrote:
>
> > Just change the logic in dwc3_qcom_find_num_ports() so that it returns 1
> > if "dp_hs_phy_1" is missing, and otherwise you determine the number of
> > ports by iterating from 2 to DWC3_MAX_PORTS - 1.
> I made this change and it works. Removed any return value check for the
> find_num_ports call as it can return only 1/2/3/4 now.
>
> ---
> irq = platform_get_irq_byname_optional(pdev, "qusb2_phy");
> if (irq > 0)
> return 1;
>
> irq = platform_get_irq_byname_optional(pdev, "dp_hs_phy_irq");
> if (irq > 0)
> return 1;
As I mentioned above, these two lookups are no longer needed and should
be removed.
> irq = platform_get_irq_byname_optional(pdev, "dp_hs_phy_1");
> if (irq <= 0)
> return 1;
Just assume it's a single port controller unless "dp_hs_phy_1" is
present.
> for (port_index = 1; port_index < DWC3_MAX_PORTS - 1;
> port_index++) {
I think this would be more readable if you use port (num) as iterator
(2..DWC3_MAX_PORTS) as you're returning a number of ports.
> sprintf(irq_name, "dp_hs_phy_%d", port_index + 1);
Then this would use just "port";
>
> irq = platform_get_irq_byname_optional(pdev, irq_name);
> if (irq <= 0)
> return port_index;
And return "port - 1" here.
> }
>
> return DWC3_MAX_PORTS;
Johan
^ permalink raw reply
* Re: [PATCH v4 2/5] dt-bindings: serial: renesas,scif: Validate 'interrupts' and 'interrupt-names'
From: Lad, Prabhakar @ 2024-03-26 8:29 UTC (permalink / raw)
To: Biju Das
Cc: Geert Uytterhoeven, Greg Kroah-Hartman, Jiri Slaby, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-serial@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Fabrizio Castro, Prabhakar Mahadev Lad
In-Reply-To: <OSAPR01MB15871221D42B6CEAA08168C386362@OSAPR01MB1587.jpnprd01.prod.outlook.com>
Hi Biju,
On Mon, Mar 25, 2024 at 4:21 PM Biju Das <biju.das.jz@bp.renesas.com> wrote:
>
> Hi Prabhakar,
>
> > -----Original Message-----
> > From: Prabhakar <prabhakar.csengg@gmail.com>
> > Sent: Friday, March 22, 2024 2:44 PM
> > Subject: [PATCH v4 2/5] dt-bindings: serial: renesas,scif: Validate 'interrupts' and 'interrupt-
> > names'
> >
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > This commit adds support to validate the 'interrupts' and 'interrupt-names'
> > properties for every supported SoC. This ensures proper handling and configuration of interrupt-
> > related properties across supported platforms.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> > v3->v4
> > - Reverted back to v2 version of the patch.
> > - Used suggestion from Krzysztof for interrupts
> > - Restored RB tag from Geert
> >
> > v2->v3
> > - Listed interrupts and interrupt-names for every SoC in if check
> > ---
> > .../bindings/serial/renesas,scif.yaml | 73 ++++++++++++++-----
> > 1 file changed, 55 insertions(+), 18 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> > b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> > index af72c3420453..eb2aa5e75e02 100644
> > --- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> > +++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> > @@ -86,11 +86,6 @@ properties:
> > oneOf:
> > - items:
> > - description: A combined interrupt
> > - - items:
> > - - description: Error interrupt
> > - - description: Receive buffer full interrupt
> > - - description: Transmit buffer empty interrupt
> > - - description: Break interrupt
> > - items:
> > - description: Error interrupt
> > - description: Receive buffer full interrupt @@ -98,21 +93,17 @@ properties:
> > - description: Break interrupt
> > - description: Data Ready interrupt
> > - description: Transmit End interrupt
> > + minItems: 4
>
> I think here minItems is 1 as it is either 1 or 4 or 6
>
minItems 1 case is already handled above.
Cheers,
Prabhakar
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox