[PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency

[PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency

[Laurent Pinchart]

Implement a .mode_valid() handler in the R-Car glue layer to reject
modes with an unsupported clock frequency.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
 drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

Changes since v1:

- Add a comment to explain where the limit comes from

diff --git a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
index 75490a3e0a2a..603bb340e8cf 100644
--- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
+++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
@@ -35,6 +35,20 @@ static const struct rcar_hdmi_phy_params rcar_hdmi_phy_params[] = {
 	{ ~0UL,      0x0000, 0x0000, 0x0000 },
 };
 
+static enum drm_mode_status
+rcar_hdmi_mode_valid(struct drm_connector *connector,
+		     const struct drm_display_mode *mode)
+{
+	/*
+	 * The maximum supported clock frequency is 297 MHz, as shown in the PHY
+	 * parameters table.
+	 */
+	if (mode->clock > 297000)
+		return MODE_CLOCK_HIGH;
+
+	return MODE_OK;
+}
+
 static int rcar_hdmi_phy_configure(struct dw_hdmi *hdmi,
 				   const struct dw_hdmi_plat_data *pdata,
 				   unsigned long mpixelclock)
@@ -59,6 +73,7 @@ static int rcar_hdmi_phy_configure(struct dw_hdmi *hdmi,
 }
 
 static const struct dw_hdmi_plat_data rcar_dw_hdmi_plat_data = {
+	.mode_valid = rcar_hdmi_mode_valid,
 	.configure_phy	= rcar_hdmi_phy_configure,
 };
 
-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency

[Geert Uytterhoeven]

Hi Laurent,

On Tue, Dec 4, 2018 at 5:36 PM Laurent Pinchart
<laurent.pinchart+renesas@ideasonboard.com> wrote:
> Implement a .mode_valid() handler in the R-Car glue layer to reject
> modes with an unsupported clock frequency.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Thanks for your patch!

> --- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> @@ -35,6 +35,20 @@ static const struct rcar_hdmi_phy_params rcar_hdmi_phy_params[] = {
>         { ~0UL,      0x0000, 0x0000, 0x0000 },
>  };
>
> +static enum drm_mode_status
> +rcar_hdmi_mode_valid(struct drm_connector *connector,
> +                    const struct drm_display_mode *mode)
> +{
> +       /*
> +        * The maximum supported clock frequency is 297 MHz, as shown in the PHY
> +        * parameters table.
> +        */
> +       if (mode->clock > 297000)
> +               return MODE_CLOCK_HIGH;

Perhaps you need a check for the lower limit (25 MHz), too?

> +
> +       return MODE_OK;
> +}

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency

[Laurent Pinchart]

Hi Geert,

On Tuesday, 4 December 2018 19:30:25 EET Geert Uytterhoeven wrote:
> On Tue, Dec 4, 2018 at 5:36 PM Laurent Pinchart wrote:
> > Implement a .mode_valid() handler in the R-Car glue layer to reject
> > modes with an unsupported clock frequency.
> > 
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas@ideasonboard.com>
> 
> Thanks for your patch!
> 
> > --- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> > @@ -35,6 +35,20 @@ static const struct rcar_hdmi_phy_params
> > rcar_hdmi_phy_params[] = {
> >         { ~0UL,      0x0000, 0x0000, 0x0000 },
> >  };
> > 
> > +static enum drm_mode_status
> > +rcar_hdmi_mode_valid(struct drm_connector *connector,
> > +                    const struct drm_display_mode *mode)
> > +{
> > +       /*
> > +        * The maximum supported clock frequency is 297 MHz, as shown in
> > the PHY +        * parameters table.
> > +        */
> > +       if (mode->clock > 297000)
> > +               return MODE_CLOCK_HIGH;
> 
> Perhaps you need a check for the lower limit (25 MHz), too?

There's no lower limit implied by the rcar_hdmi_phy_params table.

> > +
> > +       return MODE_OK;
> > +}

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency

[Geert Uytterhoeven]

Hi Laurent,

On Tue, Dec 4, 2018 at 7:12 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Tuesday, 4 December 2018 19:30:25 EET Geert Uytterhoeven wrote:
> > On Tue, Dec 4, 2018 at 5:36 PM Laurent Pinchart wrote:
> > > Implement a .mode_valid() handler in the R-Car glue layer to reject
> > > modes with an unsupported clock frequency.
> > >
> > > Signed-off-by: Laurent Pinchart
> > > <laurent.pinchart+renesas@ideasonboard.com>
> >
> > Thanks for your patch!
> >
> > > --- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> > > @@ -35,6 +35,20 @@ static const struct rcar_hdmi_phy_params
> > > rcar_hdmi_phy_params[] = {
> > >         { ~0UL,      0x0000, 0x0000, 0x0000 },
> > >  };
> > >
> > > +static enum drm_mode_status
> > > +rcar_hdmi_mode_valid(struct drm_connector *connector,
> > > +                    const struct drm_display_mode *mode)
> > > +{
> > > +       /*
> > > +        * The maximum supported clock frequency is 297 MHz, as shown in
> > > the PHY +        * parameters table.
> > > +        */
> > > +       if (mode->clock > 297000)
> > > +               return MODE_CLOCK_HIGH;
> >
> > Perhaps you need a check for the lower limit (25 MHz), too?
>
> There's no lower limit implied by the rcar_hdmi_phy_params table.

Oh, you mean the table in the driver, not a table in the Hardware User's
Manual?
That's why I couldn't find the table, but only a short notice in the HDMI
section of the Hardware User's Manual, stating:

    Pixel clock from 25MHz up to 297MHz

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency

[Laurent Pinchart]

Hi Geert,

On Tuesday, 4 December 2018 20:42:53 EET Geert Uytterhoeven wrote:
> On Tue, Dec 4, 2018 at 7:12 PM Laurent Pinchart wrote:
> > On Tuesday, 4 December 2018 19:30:25 EET Geert Uytterhoeven wrote:
> >> On Tue, Dec 4, 2018 at 5:36 PM Laurent Pinchart wrote:
> >>> Implement a .mode_valid() handler in the R-Car glue layer to reject
> >>> modes with an unsupported clock frequency.
> >>> 
> >>> Signed-off-by: Laurent Pinchart
> >>> <laurent.pinchart+renesas@ideasonboard.com>
> >> 
> >> Thanks for your patch!
> >> 
> >>> --- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> >>> +++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> >>> @@ -35,6 +35,20 @@ static const struct rcar_hdmi_phy_params
> >>> rcar_hdmi_phy_params[] = {
> >>>         { ~0UL,      0x0000, 0x0000, 0x0000 },
> >>>  };
> >>> 
> >>> +static enum drm_mode_status
> >>> +rcar_hdmi_mode_valid(struct drm_connector *connector,
> >>> +                    const struct drm_display_mode *mode)
> >>> +{
> >>> +       /*
> >>> +        * The maximum supported clock frequency is 297 MHz, as shown
> >>> in the PHY
> >>> +        * parameters table.
> >>> +        */
> >>> +       if (mode->clock > 297000)
> >>> +               return MODE_CLOCK_HIGH;
> >> 
> >> Perhaps you need a check for the lower limit (25 MHz), too?
> > 
> > There's no lower limit implied by the rcar_hdmi_phy_params table.
> 
> Oh, you mean the table in the driver, not a table in the Hardware User's
> Manual?

Correct, I mean the table in the driver. This patch was prompted by an error 
returned from rcar_hdmi_phy_configure() when the mode frequency was too high, 
making mode setting failed. I've thus added a .mode_valid() handler to ensure 
that invalid modes don't get exposed to upper layers, fixing such use cases as 
fbvon on a 4K monitor (where the fbcon was picking a mode advertised as 
supported by the driver while its frequency was too high).

> That's why I couldn't find the table, but only a short notice in the HDMI
> section of the Hardware User's Manual, stating:
> 
>     Pixel clock from 25MHz up to 297MHz

Well, the IP core vendor doesn't allow us to submit patches based on the 
content of non-public documentation, so I'm afraid I won't sign such a patch 
without being given explicit permission. It's a very stupid game really, but I 
don't set the rules :-(

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency

[Geert Uytterhoeven]

Hi Laurent,

On Tue, Dec 4, 2018 at 7:51 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Tuesday, 4 December 2018 20:42:53 EET Geert Uytterhoeven wrote:
> > On Tue, Dec 4, 2018 at 7:12 PM Laurent Pinchart wrote:
> > > On Tuesday, 4 December 2018 19:30:25 EET Geert Uytterhoeven wrote:
> > >> On Tue, Dec 4, 2018 at 5:36 PM Laurent Pinchart wrote:
> > >>> Implement a .mode_valid() handler in the R-Car glue layer to reject
> > >>> modes with an unsupported clock frequency.
> > >>>
> > >>> Signed-off-by: Laurent Pinchart
> > >>> <laurent.pinchart+renesas@ideasonboard.com>
> > >>
> > >> Thanks for your patch!
> > >>
> > >>> --- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> > >>> +++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> > >>> @@ -35,6 +35,20 @@ static const struct rcar_hdmi_phy_params
> > >>> rcar_hdmi_phy_params[] = {
> > >>>         { ~0UL,      0x0000, 0x0000, 0x0000 },
> > >>>  };
> > >>>
> > >>> +static enum drm_mode_status
> > >>> +rcar_hdmi_mode_valid(struct drm_connector *connector,
> > >>> +                    const struct drm_display_mode *mode)
> > >>> +{
> > >>> +       /*
> > >>> +        * The maximum supported clock frequency is 297 MHz, as shown
> > >>> in the PHY
> > >>> +        * parameters table.
> > >>> +        */
> > >>> +       if (mode->clock > 297000)
> > >>> +               return MODE_CLOCK_HIGH;
> > >>
> > >> Perhaps you need a check for the lower limit (25 MHz), too?
> > >
> > > There's no lower limit implied by the rcar_hdmi_phy_params table.
> >
> > Oh, you mean the table in the driver, not a table in the Hardware User's
> > Manual?
>
> Correct, I mean the table in the driver. This patch was prompted by an error
> returned from rcar_hdmi_phy_configure() when the mode frequency was too high,
> making mode setting failed. I've thus added a .mode_valid() handler to ensure
> that invalid modes don't get exposed to upper layers, fixing such use cases as
> fbvon on a 4K monitor (where the fbcon was picking a mode advertised as
> supported by the driver while its frequency was too high).
>
> > That's why I couldn't find the table, but only a short notice in the HDMI
> > section of the Hardware User's Manual, stating:
> >
> >     Pixel clock from 25MHz up to 297MHz
>
> Well, the IP core vendor doesn't allow us to submit patches based on the
> content of non-public documentation, so I'm afraid I won't sign such a patch
> without being given explicit permission. It's a very stupid game really, but I
> don't set the rules :-(

https://en.wikipedia.org/wiki/HDMI claims 25 MHz is  the minimum TMDS rate
for HDMI anyway. Anything below that needs to use pixel replication.

So you can reject < 25 MHz for sure.

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency

[Laurent Pinchart]

Hi Geert,

On Tuesday, 4 December 2018 21:45:10 EET Geert Uytterhoeven wrote:
> On Tue, Dec 4, 2018 at 7:51 PM Laurent Pinchart wrote:
> > On Tuesday, 4 December 2018 20:42:53 EET Geert Uytterhoeven wrote:
> > > On Tue, Dec 4, 2018 at 7:12 PM Laurent Pinchart wrote:
> > > > On Tuesday, 4 December 2018 19:30:25 EET Geert Uytterhoeven wrote:
> > > >> On Tue, Dec 4, 2018 at 5:36 PM Laurent Pinchart wrote:
> > > >>> Implement a .mode_valid() handler in the R-Car glue layer to reject
> > > >>> modes with an unsupported clock frequency.
> > > >>> 
> > > >>> Signed-off-by: Laurent Pinchart
> > > >>> <laurent.pinchart+renesas@ideasonboard.com>
> > > >> 
> > > >> Thanks for your patch!
> > > >> 
> > > >>> --- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> > > >>> +++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> > > >>> @@ -35,6 +35,20 @@ static const struct rcar_hdmi_phy_params
> > > >>> rcar_hdmi_phy_params[] = {
> > > >>> 
> > > >>>         { ~0UL,      0x0000, 0x0000, 0x0000 },
> > > >>>  
> > > >>>  };
> > > >>> 
> > > >>> +static enum drm_mode_status
> > > >>> +rcar_hdmi_mode_valid(struct drm_connector *connector,
> > > >>> +                    const struct drm_display_mode *mode)
> > > >>> +{
> > > >>> +       /*
> > > >>> +        * The maximum supported clock frequency is 297 MHz, as
> > > >>> shown
> > > >>> in the PHY
> > > >>> +        * parameters table.
> > > >>> +        */
> > > >>> +       if (mode->clock > 297000)
> > > >>> +               return MODE_CLOCK_HIGH;
> > > >> 
> > > >> Perhaps you need a check for the lower limit (25 MHz), too?
> > > > 
> > > > There's no lower limit implied by the rcar_hdmi_phy_params table.
> > > 
> > > Oh, you mean the table in the driver, not a table in the Hardware User's
> > > Manual?
> > 
> > Correct, I mean the table in the driver. This patch was prompted by an
> > error returned from rcar_hdmi_phy_configure() when the mode frequency was
> > too high, making mode setting failed. I've thus added a .mode_valid()
> > handler to ensure that invalid modes don't get exposed to upper layers,
> > fixing such use cases as fbvon on a 4K monitor (where the fbcon was
> > picking a mode advertised as supported by the driver while its frequency
> > was too high).
> > 
> > > That's why I couldn't find the table, but only a short notice in the
> > > HDMI section of the Hardware User's Manual, stating:
> > > 
> > >     Pixel clock from 25MHz up to 297MHz
> > 
> > Well, the IP core vendor doesn't allow us to submit patches based on the
> > content of non-public documentation, so I'm afraid I won't sign such a
> > patch without being given explicit permission. It's a very stupid game
> > really, but I don't set the rules :-(
> 
> https://en.wikipedia.org/wiki/HDMI claims 25 MHz is  the minimum TMDS rate
> for HDMI anyway. Anything below that needs to use pixel replication.
> 
> So you can reject < 25 MHz for sure.

That should then be performed in the common dw_hdmi_bridge_mode_valid() 
handler, in drivers/gpu/drm/bridge/synopsys/dw-hdmi.c.


-- 
Regards,

Laurent Pinchart



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

Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency

[Kieran Bingham]

Hi Laurent,

On 04/12/2018 16:36, Laurent Pinchart wrote:
> Implement a .mode_valid() handler in the R-Car glue layer to reject
> modes with an unsupported clock frequency.

Thank you, I believe my concerns were addressed;
 (and my misunderstandings are now understandings)

> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>

> ---
>  drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> Changes since v1:
> 
> - Add a comment to explain where the limit comes from
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> index 75490a3e0a2a..603bb340e8cf 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> @@ -35,6 +35,20 @@ static const struct rcar_hdmi_phy_params rcar_hdmi_phy_params[] = {
>  	{ ~0UL,      0x0000, 0x0000, 0x0000 },
>  };
>  
> +static enum drm_mode_status
> +rcar_hdmi_mode_valid(struct drm_connector *connector,
> +		     const struct drm_display_mode *mode)
> +{
> +	/*
> +	 * The maximum supported clock frequency is 297 MHz, as shown in the PHY
> +	 * parameters table.
> +	 */
> +	if (mode->clock > 297000)

It's still a bit of a shame that it's not clear that the mode->clock is
expressed in KHz (unless you already know that, which I didn't)
 - but I'll let that slide for now.

--
KB

> +		return MODE_CLOCK_HIGH;
> +
> +	return MODE_OK;
> +}
> +
>  static int rcar_hdmi_phy_configure(struct dw_hdmi *hdmi,
>  				   const struct dw_hdmi_plat_data *pdata,
>  				   unsigned long mpixelclock)
> @@ -59,6 +73,7 @@ static int rcar_hdmi_phy_configure(struct dw_hdmi *hdmi,
>  }
>  
>  static const struct dw_hdmi_plat_data rcar_dw_hdmi_plat_data = {
> +	.mode_valid = rcar_hdmi_mode_valid,
>  	.configure_phy	= rcar_hdmi_phy_configure,
>  };
>  
> 

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