All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
To: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Cc: Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Heiko Stuebner <heiko@sntech.de>,
	devicetree <devicetree@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 3/3] arm64: dts: rockchip: Add Hantro encoder node to rk356x
Date: Tue, 10 May 2022 17:27:08 +0200	[thread overview]
Message-ID: <1959188.DQhRDO7MrQ@archbook> (raw)
In-Reply-To: <CAAEAJfC5aoFmk7hKZ-CSv1=RhzO8YU38Abz8PhD26MvV+X0r-Q@mail.gmail.com>

Hi Ezequiel,

On Montag, 9. Mai 2022 16:17:03 CEST Ezequiel Garcia wrote:
> Hi Nicolas,
> 
> On Sun, May 8, 2022 at 5:26 PM Nicolas Frattaroli
> <frattaroli.nicolas@gmail.com> wrote:
> >
> > The RK3566 and RK3568 come with a dedicated Hantro instance solely for
> > encoding. This patch adds a node for this to the device tree, along with
> > a node for its MMU.
> >
> > Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
> > ---
> >  arch/arm64/boot/dts/rockchip/rk356x.dtsi | 21 +++++++++++++++++++++
> >  1 file changed, 21 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> > index 7cdef800cb3c..2e3c9e1887e3 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> > @@ -508,6 +508,27 @@ gpu: gpu@fde60000 {
> >                 status = "disabled";
> >         };
> >
> > +       vepu: video-codec@fdee0000 {
> > +               compatible = "rockchip,rk3568-vepu";
> > +               reg = <0x0 0xfdee0000 0x0 0x800>;
> > +               interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
> > +               interrupt-names = "vepu";
> 
> It this block "encoder only" and if so, maybe we should remove the
> "interrupt-names" [1]?
> 
> The driver is able to handle it. See:
> 
> https://elixir.bootlin.com/linux/latest/source/drivers/staging/media/hantro/hantro_drv.c#L962
> 
> You might have to adjust the dt-bindings for this.
> 
> [1] https://lore.kernel.org/linux-media/20210324151715.GA3070006@robh.at.kernel.org/

What the Linux driver can handle should not matter to the device tree;
device trees are independent of drivers and kernels.

What does matter though is to be consistent in the bindings.
interrupt-names is a required property even if there's only a vdpu
interrupt. I modelled my vepu-only binding after this case.

If robh thinks there is no value to having the interrupt show up
as anything other than "default" in /proc/interrupts, then I respectfully
disagree with that opinion and point out that this should have been brought
up when the vdpu-only case in the bindings was made to require
interrupt-names also.

Changing the binding now that there theoretically could be drivers out
in the wild (though I doubt it) that do require interrupt-names, because
the binding told them that this is okay to do, seems unwise to me.

Regards,
Nicolas Frattaroli

> 
> Thanks,
> Ezequiel
> 
> > +               clocks = <&cru ACLK_JENC>, <&cru HCLK_JENC>;
> > +               clock-names = "aclk", "hclk";
> > +               iommus = <&vepu_mmu>;
> > +               power-domains = <&power RK3568_PD_RGA>;
> > +       };
> > +
> > +       vepu_mmu: iommu@fdee0800 {
> > +               compatible = "rockchip,rk3568-iommu";
> > +               reg = <0x0 0xfdee0800 0x0 0x40>;
> > +               interrupts = <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>;
> > +               clocks = <&cru ACLK_JENC>, <&cru HCLK_JENC>;
> > +               clock-names = "aclk", "iface";
> > +               power-domains = <&power RK3568_PD_RGA>;
> > +               #iommu-cells = <0>;
> > +       };
> > +
> >         sdmmc2: mmc@fe000000 {
> >                 compatible = "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc";
> >                 reg = <0x0 0xfe000000 0x0 0x4000>;
> > --
> > 2.36.0
> >
> >
> > _______________________________________________
> > Linux-rockchip mailing list
> > Linux-rockchip@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-rockchip
> 





_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
To: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Cc: Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Heiko Stuebner <heiko@sntech.de>,
	devicetree <devicetree@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 3/3] arm64: dts: rockchip: Add Hantro encoder node to rk356x
Date: Tue, 10 May 2022 17:27:08 +0200	[thread overview]
Message-ID: <1959188.DQhRDO7MrQ@archbook> (raw)
In-Reply-To: <CAAEAJfC5aoFmk7hKZ-CSv1=RhzO8YU38Abz8PhD26MvV+X0r-Q@mail.gmail.com>

Hi Ezequiel,

On Montag, 9. Mai 2022 16:17:03 CEST Ezequiel Garcia wrote:
> Hi Nicolas,
> 
> On Sun, May 8, 2022 at 5:26 PM Nicolas Frattaroli
> <frattaroli.nicolas@gmail.com> wrote:
> >
> > The RK3566 and RK3568 come with a dedicated Hantro instance solely for
> > encoding. This patch adds a node for this to the device tree, along with
> > a node for its MMU.
> >
> > Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
> > ---
> >  arch/arm64/boot/dts/rockchip/rk356x.dtsi | 21 +++++++++++++++++++++
> >  1 file changed, 21 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> > index 7cdef800cb3c..2e3c9e1887e3 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> > @@ -508,6 +508,27 @@ gpu: gpu@fde60000 {
> >                 status = "disabled";
> >         };
> >
> > +       vepu: video-codec@fdee0000 {
> > +               compatible = "rockchip,rk3568-vepu";
> > +               reg = <0x0 0xfdee0000 0x0 0x800>;
> > +               interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
> > +               interrupt-names = "vepu";
> 
> It this block "encoder only" and if so, maybe we should remove the
> "interrupt-names" [1]?
> 
> The driver is able to handle it. See:
> 
> https://elixir.bootlin.com/linux/latest/source/drivers/staging/media/hantro/hantro_drv.c#L962
> 
> You might have to adjust the dt-bindings for this.
> 
> [1] https://lore.kernel.org/linux-media/20210324151715.GA3070006@robh.at.kernel.org/

What the Linux driver can handle should not matter to the device tree;
device trees are independent of drivers and kernels.

What does matter though is to be consistent in the bindings.
interrupt-names is a required property even if there's only a vdpu
interrupt. I modelled my vepu-only binding after this case.

If robh thinks there is no value to having the interrupt show up
as anything other than "default" in /proc/interrupts, then I respectfully
disagree with that opinion and point out that this should have been brought
up when the vdpu-only case in the bindings was made to require
interrupt-names also.

Changing the binding now that there theoretically could be drivers out
in the wild (though I doubt it) that do require interrupt-names, because
the binding told them that this is okay to do, seems unwise to me.

Regards,
Nicolas Frattaroli

> 
> Thanks,
> Ezequiel
> 
> > +               clocks = <&cru ACLK_JENC>, <&cru HCLK_JENC>;
> > +               clock-names = "aclk", "hclk";
> > +               iommus = <&vepu_mmu>;
> > +               power-domains = <&power RK3568_PD_RGA>;
> > +       };
> > +
> > +       vepu_mmu: iommu@fdee0800 {
> > +               compatible = "rockchip,rk3568-iommu";
> > +               reg = <0x0 0xfdee0800 0x0 0x40>;
> > +               interrupts = <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>;
> > +               clocks = <&cru ACLK_JENC>, <&cru HCLK_JENC>;
> > +               clock-names = "aclk", "iface";
> > +               power-domains = <&power RK3568_PD_RGA>;
> > +               #iommu-cells = <0>;
> > +       };
> > +
> >         sdmmc2: mmc@fe000000 {
> >                 compatible = "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc";
> >                 reg = <0x0 0xfe000000 0x0 0x4000>;
> > --
> > 2.36.0
> >
> >
> > _______________________________________________
> > Linux-rockchip mailing list
> > Linux-rockchip@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-rockchip
> 





_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
To: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Cc: Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Heiko Stuebner <heiko@sntech.de>,
	devicetree <devicetree@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 3/3] arm64: dts: rockchip: Add Hantro encoder node to rk356x
Date: Tue, 10 May 2022 17:27:08 +0200	[thread overview]
Message-ID: <1959188.DQhRDO7MrQ@archbook> (raw)
In-Reply-To: <CAAEAJfC5aoFmk7hKZ-CSv1=RhzO8YU38Abz8PhD26MvV+X0r-Q@mail.gmail.com>

Hi Ezequiel,

On Montag, 9. Mai 2022 16:17:03 CEST Ezequiel Garcia wrote:
> Hi Nicolas,
> 
> On Sun, May 8, 2022 at 5:26 PM Nicolas Frattaroli
> <frattaroli.nicolas@gmail.com> wrote:
> >
> > The RK3566 and RK3568 come with a dedicated Hantro instance solely for
> > encoding. This patch adds a node for this to the device tree, along with
> > a node for its MMU.
> >
> > Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
> > ---
> >  arch/arm64/boot/dts/rockchip/rk356x.dtsi | 21 +++++++++++++++++++++
> >  1 file changed, 21 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> > index 7cdef800cb3c..2e3c9e1887e3 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> > @@ -508,6 +508,27 @@ gpu: gpu@fde60000 {
> >                 status = "disabled";
> >         };
> >
> > +       vepu: video-codec@fdee0000 {
> > +               compatible = "rockchip,rk3568-vepu";
> > +               reg = <0x0 0xfdee0000 0x0 0x800>;
> > +               interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
> > +               interrupt-names = "vepu";
> 
> It this block "encoder only" and if so, maybe we should remove the
> "interrupt-names" [1]?
> 
> The driver is able to handle it. See:
> 
> https://elixir.bootlin.com/linux/latest/source/drivers/staging/media/hantro/hantro_drv.c#L962
> 
> You might have to adjust the dt-bindings for this.
> 
> [1] https://lore.kernel.org/linux-media/20210324151715.GA3070006@robh.at.kernel.org/

What the Linux driver can handle should not matter to the device tree;
device trees are independent of drivers and kernels.

What does matter though is to be consistent in the bindings.
interrupt-names is a required property even if there's only a vdpu
interrupt. I modelled my vepu-only binding after this case.

If robh thinks there is no value to having the interrupt show up
as anything other than "default" in /proc/interrupts, then I respectfully
disagree with that opinion and point out that this should have been brought
up when the vdpu-only case in the bindings was made to require
interrupt-names also.

Changing the binding now that there theoretically could be drivers out
in the wild (though I doubt it) that do require interrupt-names, because
the binding told them that this is okay to do, seems unwise to me.

Regards,
Nicolas Frattaroli

> 
> Thanks,
> Ezequiel
> 
> > +               clocks = <&cru ACLK_JENC>, <&cru HCLK_JENC>;
> > +               clock-names = "aclk", "hclk";
> > +               iommus = <&vepu_mmu>;
> > +               power-domains = <&power RK3568_PD_RGA>;
> > +       };
> > +
> > +       vepu_mmu: iommu@fdee0800 {
> > +               compatible = "rockchip,rk3568-iommu";
> > +               reg = <0x0 0xfdee0800 0x0 0x40>;
> > +               interrupts = <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>;
> > +               clocks = <&cru ACLK_JENC>, <&cru HCLK_JENC>;
> > +               clock-names = "aclk", "iface";
> > +               power-domains = <&power RK3568_PD_RGA>;
> > +               #iommu-cells = <0>;
> > +       };
> > +
> >         sdmmc2: mmc@fe000000 {
> >                 compatible = "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc";
> >                 reg = <0x0 0xfe000000 0x0 0x4000>;
> > --
> > 2.36.0
> >
> >
> > _______________________________________________
> > Linux-rockchip mailing list
> > Linux-rockchip@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-rockchip
> 





  reply	other threads:[~2022-05-10 15:29 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-08 20:25 [PATCH v2 0/3] Enable JPEG Encoder on RK3566/RK3568 Nicolas Frattaroli
2022-05-08 20:25 ` Nicolas Frattaroli
2022-05-08 20:25 ` Nicolas Frattaroli
2022-05-08 20:25 ` [PATCH v2 1/3] dt-bindings: media: rockchip-vpu: Add RK3568 VEPU compatible Nicolas Frattaroli
2022-05-08 20:25   ` Nicolas Frattaroli
2022-05-08 20:25   ` Nicolas Frattaroli
2022-05-09  7:25   ` Krzysztof Kozlowski
2022-05-09  7:25     ` Krzysztof Kozlowski
2022-05-09  7:25     ` Krzysztof Kozlowski
2022-05-09  9:24     ` Nicolas Frattaroli
2022-05-09  9:24       ` Nicolas Frattaroli
2022-05-09  9:24       ` Nicolas Frattaroli
2022-05-09 10:41       ` Krzysztof Kozlowski
2022-05-09 10:41         ` Krzysztof Kozlowski
2022-05-09 10:41         ` Krzysztof Kozlowski
2022-05-08 20:25 ` [PATCH v2 2/3] media: hantro: Add support for RK356x encoder Nicolas Frattaroli
2022-05-08 20:25   ` Nicolas Frattaroli
2022-05-08 20:25   ` Nicolas Frattaroli
2022-05-08 20:25 ` [PATCH v2 3/3] arm64: dts: rockchip: Add Hantro encoder node to rk356x Nicolas Frattaroli
2022-05-08 20:25   ` Nicolas Frattaroli
2022-05-08 20:25   ` Nicolas Frattaroli
2022-05-09 14:17   ` Ezequiel Garcia
2022-05-09 14:17     ` Ezequiel Garcia
2022-05-09 14:17     ` Ezequiel Garcia
2022-05-10 15:27     ` Nicolas Frattaroli [this message]
2022-05-10 15:27       ` Nicolas Frattaroli
2022-05-10 15:27       ` Nicolas Frattaroli
2022-05-12 14:16       ` Ezequiel Garcia
2022-05-12 14:16         ` Ezequiel Garcia
2022-05-12 14:16         ` Ezequiel Garcia
2022-05-12 20:00         ` Nicolas Frattaroli
2022-05-12 20:00           ` Nicolas Frattaroli
2022-05-12 20:00           ` Nicolas Frattaroli
2022-05-12 21:33           ` Ezequiel Garcia
2022-05-12 21:33             ` Ezequiel Garcia
2022-05-12 21:33             ` Ezequiel Garcia
2022-05-13  6:23             ` Nicolas Frattaroli
2022-05-13  6:23               ` Nicolas Frattaroli
2022-05-13  6:23               ` Nicolas Frattaroli
2022-05-13 13:07               ` Ezequiel Garcia
2022-05-13 13:07                 ` Ezequiel Garcia
2022-05-13 13:07                 ` Ezequiel Garcia
2022-05-13 14:44                 ` Nicolas Frattaroli
2022-05-13 14:44                   ` Nicolas Frattaroli
2022-05-13 14:44                   ` Nicolas Frattaroli
2022-05-13 15:23                 ` Rob Herring
2022-05-13 15:23                   ` Rob Herring
2022-05-13 15:23                   ` Rob Herring
2022-05-13 16:36                   ` Nicolas Frattaroli
2022-05-13 16:36                     ` Nicolas Frattaroli
2022-05-13 16:36                     ` Nicolas Frattaroli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1959188.DQhRDO7MrQ@archbook \
    --to=frattaroli.nicolas@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=ezequiel@vanguardiasur.com.ar \
    --cc=heiko@sntech.de \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.