All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ezequiel Garcia <ezequiel@collabora.com>
To: Rob Herring <robh@kernel.org>,
	Benjamin Gaignard <benjamin.gaignard@collabora.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Sascha Hauer <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	NXP Linux Team <linux-imx@nxp.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Maxime Ripard <mripard@kernel.org>,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	Chen-Yu Tsai <wens@csie.org>,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	Peng Fan <peng.fan@nxp.com>,
	Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	devicetree@vger.kernel.org,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Collabora Kernel ML <kernel@collabora.com>
Subject: Re: [PATCH v3 8/9] dt-bindings: media: nxp,imx8mq-vpu: Update bindings
Date: Tue, 23 Feb 2021 11:48:29 -0300	[thread overview]
Message-ID: <f024535585fe5b248ca8cf7ca95c14ced746f9da.camel@collabora.com> (raw)
In-Reply-To: <CAL_JsqJGZK2C8mcDiYa4yfKxf4sKykxSQ-Nfr4bi_u_OcAxW_Q@mail.gmail.com>

Hi Rob,

On Tue, 2021-02-23 at 08:31 -0600, Rob Herring wrote:
> On Tue, Feb 23, 2021 at 2:04 AM Benjamin Gaignard
> <benjamin.gaignard@collabora.com> wrote:
> > 
> > 
> > Le 23/02/2021 à 01:34, Rob Herring a écrit :
> > > On Mon, Feb 22, 2021 at 01:24:05PM +0100, Benjamin Gaignard wrote:
> > > > The current bindings seem to make the assumption that the
> > > > two VPUs hardware blocks (G1 and G2) are only one set of
> > > > registers.
> > > > After implementing the VPU reset driver and G2 decoder driver
> > > > it shows that all the VPUs are independent and don't need to
> > > > know about the registers of the other blocks.
> > > > Remove from the bindings the need to set all blocks register
> > > > but keep reg-names property because removing it from the driver
> > > > may affect other variants.
> > > > 
> > > > Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
> > > > ---
> > > > version 2:
> > > > - be more verbose about why I change the bindings
> > > > Keep in mind that series comes after: https://www.spinics.net/lists/arm-kernel/msg875766.html
> > > > without that review and ack it won't work
> > > Better, but you've still mentioned nothing about breaking compatibility.
> > > Why is that okay?
> > 

Indeed, the commit description should be clearer about breaking compatibility.

> > Because this reg-names wasn't used before for this variant so remove it won't change anything.
> 
> It is the reset changes in the driver that break. The driver
> previously got the 'ctrl' registers whether it went by name or index,
> right? With an old DTB and a kernel with the changes (and vice-versa),
> you'll have nothing to handle the VPU resets because the VPU reset
> node doesn't exist. It could work if the default state is not held in
> reset.
> 
> At least the removal of 'ctrl' registers belongs in the reset changes series.
> 
> 

Considering that FFMPEG patches that are required to support this driver
are still floating around, and GStreamer's implementation is also still
a bit under discussion, we are certain there aren't many upstreams users
(leaving ChromiumOS aside which mostly care for Rockchip variants).

So, given the driver is in staging, and that there aren't users of the
i.MX8MQ G1 variant just yet, I think we are safe breaking the compatibility
(and I'm not taking it lightly).

It would be important to detect an old devicetree and do some pr_warn about
the driver not supporting it.

Thanks,
Ezequiel


WARNING: multiple messages have this Message-ID (diff)
From: Ezequiel Garcia <ezequiel@collabora.com>
To: Rob Herring <robh@kernel.org>,
	Benjamin Gaignard <benjamin.gaignard@collabora.com>
Cc: linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	devicetree@vger.kernel.org,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	Collabora Kernel ML <kernel@collabora.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Peng Fan <peng.fan@nxp.com>, Maxime Ripard <mripard@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Chen-Yu Tsai <wens@csie.org>, NXP Linux Team <linux-imx@nxp.com>,
	Sascha Hauer <kernel@pengutronix.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Fabio Estevam <festevam@gmail.com>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH v3 8/9] dt-bindings: media: nxp,imx8mq-vpu: Update bindings
Date: Tue, 23 Feb 2021 11:48:29 -0300	[thread overview]
Message-ID: <f024535585fe5b248ca8cf7ca95c14ced746f9da.camel@collabora.com> (raw)
In-Reply-To: <CAL_JsqJGZK2C8mcDiYa4yfKxf4sKykxSQ-Nfr4bi_u_OcAxW_Q@mail.gmail.com>

Hi Rob,

On Tue, 2021-02-23 at 08:31 -0600, Rob Herring wrote:
> On Tue, Feb 23, 2021 at 2:04 AM Benjamin Gaignard
> <benjamin.gaignard@collabora.com> wrote:
> > 
> > 
> > Le 23/02/2021 à 01:34, Rob Herring a écrit :
> > > On Mon, Feb 22, 2021 at 01:24:05PM +0100, Benjamin Gaignard wrote:
> > > > The current bindings seem to make the assumption that the
> > > > two VPUs hardware blocks (G1 and G2) are only one set of
> > > > registers.
> > > > After implementing the VPU reset driver and G2 decoder driver
> > > > it shows that all the VPUs are independent and don't need to
> > > > know about the registers of the other blocks.
> > > > Remove from the bindings the need to set all blocks register
> > > > but keep reg-names property because removing it from the driver
> > > > may affect other variants.
> > > > 
> > > > Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
> > > > ---
> > > > version 2:
> > > > - be more verbose about why I change the bindings
> > > > Keep in mind that series comes after: https://www.spinics.net/lists/arm-kernel/msg875766.html
> > > > without that review and ack it won't work
> > > Better, but you've still mentioned nothing about breaking compatibility.
> > > Why is that okay?
> > 

Indeed, the commit description should be clearer about breaking compatibility.

> > Because this reg-names wasn't used before for this variant so remove it won't change anything.
> 
> It is the reset changes in the driver that break. The driver
> previously got the 'ctrl' registers whether it went by name or index,
> right? With an old DTB and a kernel with the changes (and vice-versa),
> you'll have nothing to handle the VPU resets because the VPU reset
> node doesn't exist. It could work if the default state is not held in
> reset.
> 
> At least the removal of 'ctrl' registers belongs in the reset changes series.
> 
> 

Considering that FFMPEG patches that are required to support this driver
are still floating around, and GStreamer's implementation is also still
a bit under discussion, we are certain there aren't many upstreams users
(leaving ChromiumOS aside which mostly care for Rockchip variants).

So, given the driver is in staging, and that there aren't users of the
i.MX8MQ G1 variant just yet, I think we are safe breaking the compatibility
(and I'm not taking it lightly).

It would be important to detect an old devicetree and do some pr_warn about
the driver not supporting it.

Thanks,
Ezequiel


_______________________________________________
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: Ezequiel Garcia <ezequiel@collabora.com>
To: Rob Herring <robh@kernel.org>,
	Benjamin Gaignard <benjamin.gaignard@collabora.com>
Cc: linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	devicetree@vger.kernel.org,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	Collabora Kernel ML <kernel@collabora.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Peng Fan <peng.fan@nxp.com>, Maxime Ripard <mripard@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Chen-Yu Tsai <wens@csie.org>, NXP Linux Team <linux-imx@nxp.com>,
	Sascha Hauer <kernel@pengutronix.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Fabio Estevam <festevam@gmail.com>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH v3 8/9] dt-bindings: media: nxp,imx8mq-vpu: Update bindings
Date: Tue, 23 Feb 2021 11:48:29 -0300	[thread overview]
Message-ID: <f024535585fe5b248ca8cf7ca95c14ced746f9da.camel@collabora.com> (raw)
In-Reply-To: <CAL_JsqJGZK2C8mcDiYa4yfKxf4sKykxSQ-Nfr4bi_u_OcAxW_Q@mail.gmail.com>

Hi Rob,

On Tue, 2021-02-23 at 08:31 -0600, Rob Herring wrote:
> On Tue, Feb 23, 2021 at 2:04 AM Benjamin Gaignard
> <benjamin.gaignard@collabora.com> wrote:
> > 
> > 
> > Le 23/02/2021 à 01:34, Rob Herring a écrit :
> > > On Mon, Feb 22, 2021 at 01:24:05PM +0100, Benjamin Gaignard wrote:
> > > > The current bindings seem to make the assumption that the
> > > > two VPUs hardware blocks (G1 and G2) are only one set of
> > > > registers.
> > > > After implementing the VPU reset driver and G2 decoder driver
> > > > it shows that all the VPUs are independent and don't need to
> > > > know about the registers of the other blocks.
> > > > Remove from the bindings the need to set all blocks register
> > > > but keep reg-names property because removing it from the driver
> > > > may affect other variants.
> > > > 
> > > > Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
> > > > ---
> > > > version 2:
> > > > - be more verbose about why I change the bindings
> > > > Keep in mind that series comes after: https://www.spinics.net/lists/arm-kernel/msg875766.html
> > > > without that review and ack it won't work
> > > Better, but you've still mentioned nothing about breaking compatibility.
> > > Why is that okay?
> > 

Indeed, the commit description should be clearer about breaking compatibility.

> > Because this reg-names wasn't used before for this variant so remove it won't change anything.
> 
> It is the reset changes in the driver that break. The driver
> previously got the 'ctrl' registers whether it went by name or index,
> right? With an old DTB and a kernel with the changes (and vice-versa),
> you'll have nothing to handle the VPU resets because the VPU reset
> node doesn't exist. It could work if the default state is not held in
> reset.
> 
> At least the removal of 'ctrl' registers belongs in the reset changes series.
> 
> 

Considering that FFMPEG patches that are required to support this driver
are still floating around, and GStreamer's implementation is also still
a bit under discussion, we are certain there aren't many upstreams users
(leaving ChromiumOS aside which mostly care for Rockchip variants).

So, given the driver is in staging, and that there aren't users of the
i.MX8MQ G1 variant just yet, I think we are safe breaking the compatibility
(and I'm not taking it lightly).

It would be important to detect an old devicetree and do some pr_warn about
the driver not supporting it.

Thanks,
Ezequiel


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

  reply	other threads:[~2021-02-23 14:49 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-22 12:23 [PATCH v3 0/9] Add HANTRO G2/HEVC decoder support for IMX8MQ Benjamin Gaignard
2021-02-22 12:23 ` Benjamin Gaignard
2021-02-22 12:23 ` Benjamin Gaignard
2021-02-22 12:23 ` [PATCH v3 1/9] media: hevc: Modify structures to follow H265 ITU spec Benjamin Gaignard
2021-02-22 12:23   ` Benjamin Gaignard
2021-02-22 12:23   ` Benjamin Gaignard
2021-02-25 13:09   ` Ezequiel Garcia
2021-02-25 13:09     ` Ezequiel Garcia
2021-02-25 13:09     ` Ezequiel Garcia
2021-02-25 17:01     ` Jernej Škrabec
2021-02-25 17:01       ` Jernej Škrabec
2021-02-25 17:01       ` Jernej Škrabec
2021-02-25 17:34       ` Ezequiel Garcia
2021-02-25 17:34         ` Ezequiel Garcia
2021-02-25 17:34         ` Ezequiel Garcia
2021-02-25 18:05         ` Jernej Škrabec
2021-02-25 18:05           ` Jernej Škrabec
2021-02-25 18:05           ` Jernej Škrabec
2021-02-25 18:34           ` John Cox
2021-02-25 18:34             ` John Cox
2021-02-25 18:34             ` John Cox
2021-02-25 19:11             ` Nicolas Dufresne
2021-02-25 19:11               ` Nicolas Dufresne
2021-02-25 19:11               ` Nicolas Dufresne
2021-02-25 18:35     ` Nicolas Dufresne
2021-02-25 18:35       ` Nicolas Dufresne
2021-02-25 18:35       ` Nicolas Dufresne
2021-02-22 12:23 ` [PATCH v3 2/9] media: hantro: Define HEVC codec profiles and supported features Benjamin Gaignard
2021-02-22 12:23   ` Benjamin Gaignard
2021-02-22 12:23   ` Benjamin Gaignard
2021-02-24 20:39   ` Ezequiel Garcia
2021-02-24 20:39     ` Ezequiel Garcia
2021-02-24 20:39     ` Ezequiel Garcia
2021-02-22 12:24 ` [PATCH v3 3/9] media: hantro: Add a field to distinguish the hardware versions Benjamin Gaignard
2021-02-22 12:24   ` Benjamin Gaignard
2021-02-22 12:24   ` Benjamin Gaignard
2021-02-22 12:24 ` [PATCH v3 4/9] media: uapi: Add a control for HANTRO driver Benjamin Gaignard
2021-02-22 12:24   ` Benjamin Gaignard
2021-02-22 12:24   ` Benjamin Gaignard
2021-02-25 14:05   ` Ezequiel Garcia
2021-02-25 14:05     ` Ezequiel Garcia
2021-02-25 14:05     ` Ezequiel Garcia
2021-02-22 12:24 ` [PATCH v3 5/9] media: hantro: Introduce G2/HEVC decoder Benjamin Gaignard
2021-02-22 12:24   ` Benjamin Gaignard
2021-02-22 12:24   ` Benjamin Gaignard
2021-02-25 17:55   ` Ezequiel Garcia
2021-02-25 17:55     ` Ezequiel Garcia
2021-02-25 17:55     ` Ezequiel Garcia
2021-02-26  9:47     ` Benjamin Gaignard
2021-02-26  9:47       ` Benjamin Gaignard
2021-02-26  9:47       ` Benjamin Gaignard
2021-02-26 21:08       ` Ezequiel Garcia
2021-02-26 21:08         ` Ezequiel Garcia
2021-02-26 21:08         ` Ezequiel Garcia
2021-02-22 12:24 ` [PATCH v3 6/9] media: hantro: handle V4L2_PIX_FMT_HEVC_SLICE control Benjamin Gaignard
2021-02-22 12:24   ` Benjamin Gaignard
2021-02-22 12:24   ` Benjamin Gaignard
2021-02-22 12:24 ` [PATCH v3 7/9] media: hantro: IMX8M: add variant for G2/HEVC codec Benjamin Gaignard
2021-02-22 12:24   ` Benjamin Gaignard
2021-02-22 12:24   ` Benjamin Gaignard
2021-02-22 12:24 ` [PATCH v3 8/9] dt-bindings: media: nxp,imx8mq-vpu: Update bindings Benjamin Gaignard
2021-02-22 12:24   ` Benjamin Gaignard
2021-02-22 12:24   ` Benjamin Gaignard
2021-02-23  0:34   ` Rob Herring
2021-02-23  0:34     ` Rob Herring
2021-02-23  0:34     ` Rob Herring
2021-02-23  8:04     ` Benjamin Gaignard
2021-02-23  8:04       ` Benjamin Gaignard
2021-02-23  8:04       ` Benjamin Gaignard
2021-02-23 14:31       ` Rob Herring
2021-02-23 14:31         ` [PATCH v3 8/9] dt-bindings: media: nxp, imx8mq-vpu: " Rob Herring
2021-02-23 14:31         ` Rob Herring
2021-02-23 14:48         ` Ezequiel Garcia [this message]
2021-02-23 14:48           ` [PATCH v3 8/9] dt-bindings: media: nxp,imx8mq-vpu: " Ezequiel Garcia
2021-02-23 14:48           ` Ezequiel Garcia
2021-02-22 12:24 ` [PATCH v3 9/9] arm64: dts: imx8mq: Add node to G2 hardware Benjamin Gaignard
2021-02-22 12:24   ` Benjamin Gaignard
2021-02-22 12:24   ` Benjamin Gaignard
2021-02-24 20:31 ` [PATCH v3 0/9] Add HANTRO G2/HEVC decoder support for IMX8MQ Ezequiel Garcia
2021-02-24 20:31   ` Ezequiel Garcia
2021-02-24 20:31   ` Ezequiel Garcia

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=f024535585fe5b248ca8cf7ca95c14ced746f9da.camel@collabora.com \
    --to=ezequiel@collabora.com \
    --cc=benjamin.gaignard@collabora.com \
    --cc=dan.carpenter@oracle.com \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=jernej.skrabec@siol.net \
    --cc=kernel@collabora.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mchehab@kernel.org \
    --cc=mripard@kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=paul.kocialkowski@bootlin.com \
    --cc=peng.fan@nxp.com \
    --cc=robh@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=wens@csie.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.