All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Marek Vasut <marex@denx.de>
Cc: dri-devel@lists.freedesktop.org,
	Alexandre Torgue <alexandre.torgue@st.com>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Antonio Borneo <antonio.borneo@st.com>,
	Benjamin Gaignard <benjamin.gaignard@st.com>,
	Biju Das <biju.das.jz@bp.renesas.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Philippe Cornu <philippe.cornu@st.com>,
	Sam Ravnborg <sam@ravnborg.org>,
	Vincent Abriou <vincent.abriou@st.com>,
	Yannick Fertre <yannick.fertre@st.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-stm32@st-md-mailman.stormreply.com,
	Rob Herring <robh+dt@kernel.org>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH V2] drm/bridge: lvds-codec: Add support for pixel data sampling edge select
Date: Mon, 22 Mar 2021 12:37:47 +0200	[thread overview]
Message-ID: <YFhze79nDdtf7KQS@pendragon.ideasonboard.com> (raw)
In-Reply-To: <4372d1cd-ffdb-e545-7262-d1ad1a649770@denx.de>

Hi Marek,

(CC'ing Ron and the DT mailing list for the DT discussion)

On Mon, Mar 22, 2021 at 11:29:04AM +0100, Marek Vasut wrote:
> On 3/22/21 2:14 AM, Laurent Pinchart wrote:
> > Hi Marek,
> 
> Hi,
> 
> [...]
> 
> >> diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> >> index e5e3c72630cf..399a6528780a 100644
> >> --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> >> +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> >> @@ -74,6 +74,13 @@ properties:
> >>   
> >>       additionalProperties: false
> >>   
> >> +  pixelclk-active:
> >> +    description: |
> >> +      Data sampling on rising or falling edge.
> >> +      Use 0 to sample pixel data on rising edge and
> >> +      Use 1 to sample pixel data on falling edge and
> >> +    enum: [0, 1]
> > 
> > The idea is good, but instead of adding a custom property, how about
> > reusing the pclk-sample property defined in
> > ../../media/video-interfaces.yaml ?
> 
> Repeating myself from V1 discussion ... Either is fine by me, but I 
> think pixelclk-active, which comes from panel-timings.yaml is closer to 
> the video than multimedia bindings.

That's a good point. The part that bothers me a bit is that it would be
nice to define the property in a single YAML schema, referenced by
individual bindings. video-interfaces.yaml is there for that purpose. We
could do something similar on the display side, or consider the
pixelclk-active usage in panel-timings.yaml an exception that we can't
switch to video-interfaces.yaml as backward compatibility must be
preserved.

I don't have a too strong preference, whatever Rob prefers would be fine
with me.

> > The property is only valid for encoders, so I would at least mention
> > that in the description, or, better, handle this based on the compatible
> > string to allow validation.
> 
> How does that work in the Yaml file ?

Something along the lines of

if:
  not:
    properties:
      compatible:
        contains:
          const: lvds-encoder
then:
  properties:
    pixelclk-active: false

My YAML schema foo is a bit rusty though, I apologize if this doesn't
work as-is. There are lots of similar examples in DT bindings that
should hopefully be right :-)

> >> +
> >>     powerdown-gpios:
> >>       description:
> >>         The GPIO used to control the power down line of this device.
> >> diff --git a/drivers/gpu/drm/bridge/lvds-codec.c b/drivers/gpu/drm/bridge/lvds-codec.c
> >> index dcf579a4cf83..cab81ccd895d 100644
> >> --- a/drivers/gpu/drm/bridge/lvds-codec.c
> >> +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> 
> [...]
> 
> >> @@ -126,6 +146,7 @@ static int lvds_codec_probe(struct platform_device *pdev)
> >>   	 */
> >>   	lvds_codec->bridge.of_node = dev->of_node;
> >>   	lvds_codec->bridge.funcs = &funcs;
> >> +	lvds_codec->bridge.timings = &lvds_codec->timings;
> >>   	drm_bridge_add(&lvds_codec->bridge);
> >>   
> >>   	platform_set_drvdata(pdev, lvds_codec);
> >> @@ -142,19 +163,20 @@ static int lvds_codec_remove(struct platform_device *pdev)
> >>   	return 0;
> >>   }
> >>   
> >> +static const struct lvds_codec_data decoder_data = {
> >> +	.connector_type = DRM_MODE_CONNECTOR_DPI,
> >> +	.is_encoder = false,
> > 
> > The two fields are a bit redundant, as the decoder is always
> > LVDS-to-DPI, and the encoder DPI-to-LVDS. I don't mind too much, but
> > maybe we could drop the connector_type field, and derive the connector
> > type from is_encoder ?
> 
> Or the other way around instead ? That is, if the connector_type is 
> LVDS, then it is encoder , otherwise its decoder ?

Either way works for me.

> > One may then say that we could drop the lvds_codec_data structure as it
> > contains a single field, but I foresee a need to have device-specific
> > timings at some point, so I think it's a good addition.
> 
> [...]

-- 
Regards,

Laurent Pinchart

WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Marek Vasut <marex@denx.de>
Cc: dri-devel@lists.freedesktop.org,
	Alexandre Torgue <alexandre.torgue@st.com>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Antonio Borneo <antonio.borneo@st.com>,
	Benjamin Gaignard <benjamin.gaignard@st.com>,
	Biju Das <biju.das.jz@bp.renesas.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Philippe Cornu <philippe.cornu@st.com>,
	Sam Ravnborg <sam@ravnborg.org>,
	Vincent Abriou <vincent.abriou@st.com>,
	Yannick Fertre <yannick.fertre@st.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-stm32@st-md-mailman.stormreply.com,
	Rob Herring <robh+dt@kernel.org>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH V2] drm/bridge: lvds-codec: Add support for pixel data sampling edge select
Date: Mon, 22 Mar 2021 12:37:47 +0200	[thread overview]
Message-ID: <YFhze79nDdtf7KQS@pendragon.ideasonboard.com> (raw)
In-Reply-To: <4372d1cd-ffdb-e545-7262-d1ad1a649770@denx.de>

Hi Marek,

(CC'ing Ron and the DT mailing list for the DT discussion)

On Mon, Mar 22, 2021 at 11:29:04AM +0100, Marek Vasut wrote:
> On 3/22/21 2:14 AM, Laurent Pinchart wrote:
> > Hi Marek,
> 
> Hi,
> 
> [...]
> 
> >> diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> >> index e5e3c72630cf..399a6528780a 100644
> >> --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> >> +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> >> @@ -74,6 +74,13 @@ properties:
> >>   
> >>       additionalProperties: false
> >>   
> >> +  pixelclk-active:
> >> +    description: |
> >> +      Data sampling on rising or falling edge.
> >> +      Use 0 to sample pixel data on rising edge and
> >> +      Use 1 to sample pixel data on falling edge and
> >> +    enum: [0, 1]
> > 
> > The idea is good, but instead of adding a custom property, how about
> > reusing the pclk-sample property defined in
> > ../../media/video-interfaces.yaml ?
> 
> Repeating myself from V1 discussion ... Either is fine by me, but I 
> think pixelclk-active, which comes from panel-timings.yaml is closer to 
> the video than multimedia bindings.

That's a good point. The part that bothers me a bit is that it would be
nice to define the property in a single YAML schema, referenced by
individual bindings. video-interfaces.yaml is there for that purpose. We
could do something similar on the display side, or consider the
pixelclk-active usage in panel-timings.yaml an exception that we can't
switch to video-interfaces.yaml as backward compatibility must be
preserved.

I don't have a too strong preference, whatever Rob prefers would be fine
with me.

> > The property is only valid for encoders, so I would at least mention
> > that in the description, or, better, handle this based on the compatible
> > string to allow validation.
> 
> How does that work in the Yaml file ?

Something along the lines of

if:
  not:
    properties:
      compatible:
        contains:
          const: lvds-encoder
then:
  properties:
    pixelclk-active: false

My YAML schema foo is a bit rusty though, I apologize if this doesn't
work as-is. There are lots of similar examples in DT bindings that
should hopefully be right :-)

> >> +
> >>     powerdown-gpios:
> >>       description:
> >>         The GPIO used to control the power down line of this device.
> >> diff --git a/drivers/gpu/drm/bridge/lvds-codec.c b/drivers/gpu/drm/bridge/lvds-codec.c
> >> index dcf579a4cf83..cab81ccd895d 100644
> >> --- a/drivers/gpu/drm/bridge/lvds-codec.c
> >> +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> 
> [...]
> 
> >> @@ -126,6 +146,7 @@ static int lvds_codec_probe(struct platform_device *pdev)
> >>   	 */
> >>   	lvds_codec->bridge.of_node = dev->of_node;
> >>   	lvds_codec->bridge.funcs = &funcs;
> >> +	lvds_codec->bridge.timings = &lvds_codec->timings;
> >>   	drm_bridge_add(&lvds_codec->bridge);
> >>   
> >>   	platform_set_drvdata(pdev, lvds_codec);
> >> @@ -142,19 +163,20 @@ static int lvds_codec_remove(struct platform_device *pdev)
> >>   	return 0;
> >>   }
> >>   
> >> +static const struct lvds_codec_data decoder_data = {
> >> +	.connector_type = DRM_MODE_CONNECTOR_DPI,
> >> +	.is_encoder = false,
> > 
> > The two fields are a bit redundant, as the decoder is always
> > LVDS-to-DPI, and the encoder DPI-to-LVDS. I don't mind too much, but
> > maybe we could drop the connector_type field, and derive the connector
> > type from is_encoder ?
> 
> Or the other way around instead ? That is, if the connector_type is 
> LVDS, then it is encoder , otherwise its decoder ?

Either way works for me.

> > One may then say that we could drop the lvds_codec_data structure as it
> > contains a single field, but I foresee a need to have device-specific
> > timings at some point, so I think it's a good addition.
> 
> [...]

-- 
Regards,

Laurent Pinchart

_______________________________________________
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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Marek Vasut <marex@denx.de>
Cc: devicetree@vger.kernel.org,
	Alexandre Torgue <alexandre.torgue@st.com>,
	Antonio Borneo <antonio.borneo@st.com>,
	Vincent Abriou <vincent.abriou@st.com>,
	Philippe Cornu <philippe.cornu@st.com>,
	dri-devel@lists.freedesktop.org,
	Yannick Fertre <yannick.fertre@st.com>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Rob Herring <robh+dt@kernel.org>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Biju Das <biju.das.jz@bp.renesas.com>,
	Sam Ravnborg <sam@ravnborg.org>,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org,
	Benjamin Gaignard <benjamin.gaignard@st.com>
Subject: Re: [PATCH V2] drm/bridge: lvds-codec: Add support for pixel data sampling edge select
Date: Mon, 22 Mar 2021 12:37:47 +0200	[thread overview]
Message-ID: <YFhze79nDdtf7KQS@pendragon.ideasonboard.com> (raw)
In-Reply-To: <4372d1cd-ffdb-e545-7262-d1ad1a649770@denx.de>

Hi Marek,

(CC'ing Ron and the DT mailing list for the DT discussion)

On Mon, Mar 22, 2021 at 11:29:04AM +0100, Marek Vasut wrote:
> On 3/22/21 2:14 AM, Laurent Pinchart wrote:
> > Hi Marek,
> 
> Hi,
> 
> [...]
> 
> >> diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> >> index e5e3c72630cf..399a6528780a 100644
> >> --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> >> +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> >> @@ -74,6 +74,13 @@ properties:
> >>   
> >>       additionalProperties: false
> >>   
> >> +  pixelclk-active:
> >> +    description: |
> >> +      Data sampling on rising or falling edge.
> >> +      Use 0 to sample pixel data on rising edge and
> >> +      Use 1 to sample pixel data on falling edge and
> >> +    enum: [0, 1]
> > 
> > The idea is good, but instead of adding a custom property, how about
> > reusing the pclk-sample property defined in
> > ../../media/video-interfaces.yaml ?
> 
> Repeating myself from V1 discussion ... Either is fine by me, but I 
> think pixelclk-active, which comes from panel-timings.yaml is closer to 
> the video than multimedia bindings.

That's a good point. The part that bothers me a bit is that it would be
nice to define the property in a single YAML schema, referenced by
individual bindings. video-interfaces.yaml is there for that purpose. We
could do something similar on the display side, or consider the
pixelclk-active usage in panel-timings.yaml an exception that we can't
switch to video-interfaces.yaml as backward compatibility must be
preserved.

I don't have a too strong preference, whatever Rob prefers would be fine
with me.

> > The property is only valid for encoders, so I would at least mention
> > that in the description, or, better, handle this based on the compatible
> > string to allow validation.
> 
> How does that work in the Yaml file ?

Something along the lines of

if:
  not:
    properties:
      compatible:
        contains:
          const: lvds-encoder
then:
  properties:
    pixelclk-active: false

My YAML schema foo is a bit rusty though, I apologize if this doesn't
work as-is. There are lots of similar examples in DT bindings that
should hopefully be right :-)

> >> +
> >>     powerdown-gpios:
> >>       description:
> >>         The GPIO used to control the power down line of this device.
> >> diff --git a/drivers/gpu/drm/bridge/lvds-codec.c b/drivers/gpu/drm/bridge/lvds-codec.c
> >> index dcf579a4cf83..cab81ccd895d 100644
> >> --- a/drivers/gpu/drm/bridge/lvds-codec.c
> >> +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> 
> [...]
> 
> >> @@ -126,6 +146,7 @@ static int lvds_codec_probe(struct platform_device *pdev)
> >>   	 */
> >>   	lvds_codec->bridge.of_node = dev->of_node;
> >>   	lvds_codec->bridge.funcs = &funcs;
> >> +	lvds_codec->bridge.timings = &lvds_codec->timings;
> >>   	drm_bridge_add(&lvds_codec->bridge);
> >>   
> >>   	platform_set_drvdata(pdev, lvds_codec);
> >> @@ -142,19 +163,20 @@ static int lvds_codec_remove(struct platform_device *pdev)
> >>   	return 0;
> >>   }
> >>   
> >> +static const struct lvds_codec_data decoder_data = {
> >> +	.connector_type = DRM_MODE_CONNECTOR_DPI,
> >> +	.is_encoder = false,
> > 
> > The two fields are a bit redundant, as the decoder is always
> > LVDS-to-DPI, and the encoder DPI-to-LVDS. I don't mind too much, but
> > maybe we could drop the connector_type field, and derive the connector
> > type from is_encoder ?
> 
> Or the other way around instead ? That is, if the connector_type is 
> LVDS, then it is encoder , otherwise its decoder ?

Either way works for me.

> > One may then say that we could drop the lvds_codec_data structure as it
> > contains a single field, but I foresee a need to have device-specific
> > timings at some point, so I think it's a good addition.
> 
> [...]

-- 
Regards,

Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2021-03-22 10:39 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-24  6:18 [PATCH V2] drm/bridge: lvds-codec: Add support for pixel data sampling edge select Marek Vasut
2020-12-24  6:18 ` Marek Vasut
2021-01-24 17:04 ` Marek Vasut
2021-01-24 17:04   ` Marek Vasut
2021-03-19 18:20   ` Marek Vasut
2021-03-19 18:20     ` Marek Vasut
2021-03-22  1:14 ` Laurent Pinchart
2021-03-22  1:14   ` Laurent Pinchart
2021-03-22 10:29   ` Marek Vasut
2021-03-22 10:29     ` Marek Vasut
2021-03-22 10:37     ` Laurent Pinchart [this message]
2021-03-22 10:37       ` Laurent Pinchart
2021-03-22 10:37       ` Laurent Pinchart
2021-04-16  6:49       ` Laurent Pinchart
2021-04-16  6:49         ` Laurent Pinchart
2021-04-16  6:49         ` Laurent Pinchart
2021-04-07  9:55     ` Marek Vasut
2021-04-07  9:55       ` Marek Vasut

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=YFhze79nDdtf7KQS@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=alexandre.torgue@st.com \
    --cc=antonio.borneo@st.com \
    --cc=benjamin.gaignard@st.com \
    --cc=biju.das.jz@bp.renesas.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=marex@denx.de \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=philippe.cornu@st.com \
    --cc=robh+dt@kernel.org \
    --cc=sam@ravnborg.org \
    --cc=vincent.abriou@st.com \
    --cc=yannick.fertre@st.com \
    /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.