Message ID | 20211226153349.2296024-1-nikita.yoush@cogentembedded.com (mailing list archive) |
---|---|
State | Superseded |
Delegated to: | Geert Uytterhoeven |
Headers | show |
Series | None | expand |
Hi Nikita, On Sun, Dec 26, 2021 at 4:34 PM Nikita Yushchenko <nikita.yoush@cogentembedded.com> wrote: > This patch adds mlp device to dtsi files for R-Car Gen3 SoCs that have > it. > > Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com> > --- > Change from v1: > - fix power domain ids so all dtbs build properly Thanks for the update! > --- a/arch/arm64/boot/dts/renesas/r8a77951.dtsi > +++ b/arch/arm64/boot/dts/renesas/r8a77951.dtsi > @@ -2412,6 +2412,19 @@ ssi9: ssi-9 { > }; > }; > > + mlp: mlp@ec520000 { > + compatible = "renesas,rcar-gen3-mlp"; No SoC-specific compatible value? > + reg = <0 0xec520000 0 0x800>; > + interrupts = <GIC_SPI 384 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 385 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 386 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 387 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 388 IRQ_TYPE_LEVEL_HIGH>; What is the purpose of the various interrupts? Perhaps you need interrupt-names? The driver seems to use only the first two, which is strange, as the second and third interrupt handle different channels. > + clocks = <&cpg CPG_MOD 802>; > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; Missing resets property? > + status = "disabled"; > + }; > + The rest looks sane to me. But without any DT binding documentation for this hardware block, this is hard to validate, and not yet ready for upstream integration. 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
>> + reg = <0 0xec520000 0 0x800>; >> + interrupts = <GIC_SPI 384 IRQ_TYPE_LEVEL_HIGH>, >> + <GIC_SPI 385 IRQ_TYPE_LEVEL_HIGH>, >> + <GIC_SPI 386 IRQ_TYPE_LEVEL_HIGH>, >> + <GIC_SPI 387 IRQ_TYPE_LEVEL_HIGH>, >> + <GIC_SPI 388 IRQ_TYPE_LEVEL_HIGH>; > > What is the purpose of the various interrupts? > Perhaps you need interrupt-names? > The driver seems to use only the first two, which is strange, as > the second and third interrupt handle different channels. Maybe Christian Gromm (the original driver author) can comment here? As far as I understand: - interrupts are: mlb, ahb0, ahb1, ch0rx, ch1rx - of those, the first 3 are from dim2 itself, and the last two are from renesas-specific logic around dim2 - in the interrupt assignment tables for gen3 SoCs, renesas documents all 5 interrupts, however in the mlb section, renesas mentions only mlb, ahb0 and ch0rx interrupts - moreover, renesas explicitly denies access dim2 registers responsible for channels 32..63 - which renders ahb1 interrupt useless; and renesas does not document any registers related to "async rx response" on channels 32..63 - which renders chrx1 interrupt useless - anyway, dim2 driver registers only 32 channels (for all use cases, not only for renesas), and thus uses only ahb0 interrupt - dim2 driver does not implement renesas-specific processing logic and thus does not use ch0rx interrupt I'm not sure how to proceed here. Is it better to define only two interrupts (mlb, ahb0) in device trees? Regarding 'interrupt-names' - dim2 driver currently uses platform_get_irq() and thus depends on numeric positions (mlb interrupt at index 0 and ahb0 interrupt at index 1). I'm not sure about current use cases of the driver other than with rcar-gen3, and if it is ok to use of_get_irq_byname() instead. And without using of_get_irq_byname(), interrupt-names looks somewhat useless. > But without any DT binding documentation > for this hardware block, this is hard to validate, and not yet ready for > upstream integration. Christian, are you going to provide DT binding documentation for dim2? Nikita
Hi Nikita, On Wed, Jan 12, 2022 at 9:56 AM Nikita Yushchenko <nikita.yoush@cogentembedded.com> wrote: > >> + reg = <0 0xec520000 0 0x800>; > >> + interrupts = <GIC_SPI 384 IRQ_TYPE_LEVEL_HIGH>, > >> + <GIC_SPI 385 IRQ_TYPE_LEVEL_HIGH>, > >> + <GIC_SPI 386 IRQ_TYPE_LEVEL_HIGH>, > >> + <GIC_SPI 387 IRQ_TYPE_LEVEL_HIGH>, > >> + <GIC_SPI 388 IRQ_TYPE_LEVEL_HIGH>; > > > > What is the purpose of the various interrupts? > > Perhaps you need interrupt-names? > > The driver seems to use only the first two, which is strange, as > > the second and third interrupt handle different channels. > > Maybe Christian Gromm (the original driver author) can comment here? > > As far as I understand: > - interrupts are: mlb, ahb0, ahb1, ch0rx, ch1rx > - of those, the first 3 are from dim2 itself, and the last two are from renesas-specific logic around dim2 > - in the interrupt assignment tables for gen3 SoCs, renesas documents all 5 interrupts, however in the > mlb section, renesas mentions only mlb, ahb0 and ch0rx interrupts > - moreover, renesas explicitly denies access dim2 registers responsible for channels 32..63 - which > renders ahb1 interrupt useless; and renesas does not document any registers related to "async rx > response" on channels 32..63 - which renders chrx1 interrupt useless > - anyway, dim2 driver registers only 32 channels (for all use cases, not only for renesas), and thus > uses only ahb0 interrupt > - dim2 driver does not implement renesas-specific processing logic and thus does not use ch0rx interrupt > > I'm not sure how to proceed here. > Is it better to define only two interrupts (mlb, ahb0) in device trees? > > Regarding 'interrupt-names' - dim2 driver currently uses platform_get_irq() and thus depends on numeric > positions (mlb interrupt at index 0 and ahb0 interrupt at index 1). I'm not sure about current use cases > of the driver other than with rcar-gen3, and if it is ok to use of_get_irq_byname() instead. And without > using of_get_irq_byname(), interrupt-names looks somewhat useless. As the driver is under staging, I think we can make any changes we want. > > But without any DT binding documentation > > for this hardware block, this is hard to validate, and not yet ready for > > upstream integration. > > Christian, are you going to provide DT binding documentation for dim2? 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
On Wed, 2022-01-12 at 11:56 +0300, Nikita Yushchenko wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > > > + reg = <0 0xec520000 0 0x800>; > > > + interrupts = <GIC_SPI 384 IRQ_TYPE_LEVEL_HIGH>, > > > + <GIC_SPI 385 IRQ_TYPE_LEVEL_HIGH>, > > > + <GIC_SPI 386 IRQ_TYPE_LEVEL_HIGH>, > > > + <GIC_SPI 387 IRQ_TYPE_LEVEL_HIGH>, > > > + <GIC_SPI 388 IRQ_TYPE_LEVEL_HIGH>; > > > > What is the purpose of the various interrupts? > > Perhaps you need interrupt-names? > > The driver seems to use only the first two, which is strange, as > > the second and third interrupt handle different channels. > > Maybe Christian Gromm (the original driver author) can comment here? I am not the author of this driver module and I don't have detailed knowledge about it. I'll get in touch with Andre Edich <andre.edich@microchip.com> so he can comment on this. thanks, Chris > > As far as I understand: > - interrupts are: mlb, ahb0, ahb1, ch0rx, ch1rx > - of those, the first 3 are from dim2 itself, and the last two are from renesas-specific logic around dim2 > - in the interrupt assignment tables for gen3 SoCs, renesas documents all 5 interrupts, however in the > mlb section, renesas mentions only mlb, ahb0 and ch0rx interrupts > - moreover, renesas explicitly denies access dim2 registers responsible for channels 32..63 - which > renders ahb1 interrupt useless; and renesas does not document any registers related to "async rx > response" on channels 32..63 - which renders chrx1 interrupt useless > - anyway, dim2 driver registers only 32 channels (for all use cases, not only for renesas), and thus > uses only ahb0 interrupt > - dim2 driver does not implement renesas-specific processing logic and thus does not use ch0rx interrupt > > I'm not sure how to proceed here. > Is it better to define only two interrupts (mlb, ahb0) in device trees? > > Regarding 'interrupt-names' - dim2 driver currently uses platform_get_irq() and thus depends on numeric > positions (mlb interrupt at index 0 and ahb0 interrupt at index 1). I'm not sure about current use cases > of the driver other than with rcar-gen3, and if it is ok to use of_get_irq_byname() instead. And without > using of_get_irq_byname(), interrupt-names looks somewhat useless. > > > But without any DT binding documentation > > for this hardware block, this is hard to validate, and not yet ready for > > upstream integration. > > Christian, are you going to provide DT binding documentation for dim2? > > Nikita
diff --git a/arch/arm64/boot/dts/renesas/r8a77951.dtsi b/arch/arm64/boot/dts/renesas/r8a77951.dtsi index 1768a3e6bb8d..179d860ab9c3 100644 --- a/arch/arm64/boot/dts/renesas/r8a77951.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a77951.dtsi @@ -2412,6 +2412,19 @@ ssi9: ssi-9 { }; }; + mlp: mlp@ec520000 { + compatible = "renesas,rcar-gen3-mlp"; + reg = <0 0xec520000 0 0x800>; + interrupts = <GIC_SPI 384 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 385 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 386 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 387 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 388 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 802>; + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; + status = "disabled"; + }; + audma0: dma-controller@ec700000 { compatible = "renesas,dmac-r8a7795", "renesas,rcar-dmac"; diff --git a/arch/arm64/boot/dts/renesas/r8a77960.dtsi b/arch/arm64/boot/dts/renesas/r8a77960.dtsi index 2bd8169735d3..1e90e848d2c8 100644 --- a/arch/arm64/boot/dts/renesas/r8a77960.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a77960.dtsi @@ -2284,6 +2284,19 @@ ssiu97: ssiu-51 { }; }; + mlp: mlp@ec520000 { + compatible = "renesas,rcar-gen3-mlp"; + reg = <0 0xec520000 0 0x800>; + interrupts = <GIC_SPI 384 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 385 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 386 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 387 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 388 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 802>; + power-domains = <&sysc R8A7796_PD_ALWAYS_ON>; + status = "disabled"; + }; + audma0: dma-controller@ec700000 { compatible = "renesas,dmac-r8a7796", "renesas,rcar-dmac"; diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi b/arch/arm64/boot/dts/renesas/r8a77961.dtsi index a34d5b1d6431..eb70b601191b 100644 --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi @@ -2128,6 +2128,19 @@ ssiu97: ssiu-51 { }; }; + mlp: mlp@ec520000 { + compatible = "renesas,rcar-gen3-mlp"; + reg = <0 0xec520000 0 0x800>; + interrupts = <GIC_SPI 384 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 385 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 386 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 387 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 388 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 802>; + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>; + status = "disabled"; + }; + audma0: dma-controller@ec700000 { compatible = "renesas,dmac-r8a77961", "renesas,rcar-dmac"; diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi b/arch/arm64/boot/dts/renesas/r8a77965.dtsi index 08df75606430..293021f59818 100644 --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi @@ -2147,6 +2147,19 @@ ssi9: ssi-9 { }; }; + mlp: mlp@ec520000 { + compatible = "renesas,rcar-gen3-mlp"; + reg = <0 0xec520000 0 0x800>; + interrupts = <GIC_SPI 384 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 385 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 386 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 387 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 388 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 802>; + power-domains = <&sysc R8A77965_PD_ALWAYS_ON>; + status = "disabled"; + }; + audma0: dma-controller@ec700000 { compatible = "renesas,dmac-r8a77965", "renesas,rcar-dmac"; diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index 0ea300a8147d..232391fd0751 100644 --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi @@ -1682,6 +1682,19 @@ ssi9: ssi-9 { }; }; + mlp: mlp@ec520000 { + compatible = "renesas,rcar-gen3-mlp"; + reg = <0 0xec520000 0 0x800>; + interrupts = <GIC_SPI 384 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 385 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 386 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 387 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 388 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 802>; + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; + status = "disabled"; + }; + audma0: dma-controller@ec700000 { compatible = "renesas,dmac-r8a77990", "renesas,rcar-dmac"; diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi b/arch/arm64/boot/dts/renesas/r8a77995.dtsi index 16ad5fc23a67..33d9ed431d9c 100644 --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi @@ -1132,6 +1132,19 @@ ssi4: ssi-4 { }; }; + mlp: mlp@ec520000 { + compatible = "renesas,rcar-gen3-mlp"; + reg = <0 0xec520000 0 0x800>; + interrupts = <GIC_SPI 384 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 385 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 386 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 387 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 388 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 802>; + power-domains = <&sysc R8A77995_PD_ALWAYS_ON>; + status = "disabled"; + }; + audma0: dma-controller@ec700000 { compatible = "renesas,dmac-r8a77995", "renesas,rcar-dmac";
This patch adds mlp device to dtsi files for R-Car Gen3 SoCs that have it. Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com> --- Change from v1: - fix power domain ids so all dtbs build properly arch/arm64/boot/dts/renesas/r8a77951.dtsi | 13 +++++++++++++ arch/arm64/boot/dts/renesas/r8a77960.dtsi | 13 +++++++++++++ arch/arm64/boot/dts/renesas/r8a77961.dtsi | 13 +++++++++++++ arch/arm64/boot/dts/renesas/r8a77965.dtsi | 13 +++++++++++++ arch/arm64/boot/dts/renesas/r8a77990.dtsi | 13 +++++++++++++ arch/arm64/boot/dts/renesas/r8a77995.dtsi | 13 +++++++++++++ 6 files changed, 78 insertions(+)