* [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
@ 2018-12-04 16:36 ` Laurent Pinchart
0 siblings, 0 replies; 16+ messages in thread
From: Laurent Pinchart @ 2018-12-04 16:36 UTC (permalink / raw)
To: dri-devel; +Cc: linux-renesas-soc, kieran.bingham
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
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
@ 2018-12-04 16:36 ` Laurent Pinchart
0 siblings, 0 replies; 16+ messages in thread
From: Laurent Pinchart @ 2018-12-04 16:36 UTC (permalink / raw)
To: dri-devel; +Cc: linux-renesas-soc, kieran.bingham
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
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
2018-12-04 16:36 ` Laurent Pinchart
@ 2018-12-04 17:30 ` Geert Uytterhoeven
-1 siblings, 0 replies; 16+ messages in thread
From: Geert Uytterhoeven @ 2018-12-04 17:30 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: DRI Development, Linux-Renesas, Kieran Bingham
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
@ 2018-12-04 17:30 ` Geert Uytterhoeven
0 siblings, 0 replies; 16+ messages in thread
From: Geert Uytterhoeven @ 2018-12-04 17:30 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Linux-Renesas, Kieran Bingham, DRI Development
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
2018-12-04 17:30 ` Geert Uytterhoeven
@ 2018-12-04 18:13 ` Laurent Pinchart
-1 siblings, 0 replies; 16+ messages in thread
From: Laurent Pinchart @ 2018-12-04 18:13 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Laurent Pinchart, DRI Development, Linux-Renesas, Kieran Bingham
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
@ 2018-12-04 18:13 ` Laurent Pinchart
0 siblings, 0 replies; 16+ messages in thread
From: Laurent Pinchart @ 2018-12-04 18:13 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux-Renesas, Laurent Pinchart, Kieran Bingham, DRI Development
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
2018-12-04 18:13 ` Laurent Pinchart
@ 2018-12-04 18:42 ` Geert Uytterhoeven
-1 siblings, 0 replies; 16+ messages in thread
From: Geert Uytterhoeven @ 2018-12-04 18:42 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Laurent Pinchart, DRI Development, Linux-Renesas, Kieran Bingham
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
@ 2018-12-04 18:42 ` Geert Uytterhoeven
0 siblings, 0 replies; 16+ messages in thread
From: Geert Uytterhoeven @ 2018-12-04 18:42 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Linux-Renesas, Laurent Pinchart, Kieran Bingham, DRI Development
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
2018-12-04 18:42 ` Geert Uytterhoeven
@ 2018-12-04 18:51 ` Laurent Pinchart
-1 siblings, 0 replies; 16+ messages in thread
From: Laurent Pinchart @ 2018-12-04 18:51 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Laurent Pinchart, DRI Development, Linux-Renesas, Kieran Bingham
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
@ 2018-12-04 18:51 ` Laurent Pinchart
0 siblings, 0 replies; 16+ messages in thread
From: Laurent Pinchart @ 2018-12-04 18:51 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux-Renesas, Laurent Pinchart, Kieran Bingham, DRI Development
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
2018-12-04 18:51 ` Laurent Pinchart
@ 2018-12-04 19:45 ` Geert Uytterhoeven
-1 siblings, 0 replies; 16+ messages in thread
From: Geert Uytterhoeven @ 2018-12-04 19:45 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Laurent Pinchart, DRI Development, Linux-Renesas, Kieran Bingham
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
@ 2018-12-04 19:45 ` Geert Uytterhoeven
0 siblings, 0 replies; 16+ messages in thread
From: Geert Uytterhoeven @ 2018-12-04 19:45 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Linux-Renesas, Laurent Pinchart, Kieran Bingham, DRI Development
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
2018-12-04 19:45 ` Geert Uytterhoeven
@ 2018-12-04 19:50 ` Laurent Pinchart
-1 siblings, 0 replies; 16+ messages in thread
From: Laurent Pinchart @ 2018-12-04 19:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Laurent Pinchart, DRI Development, Linux-Renesas, Kieran Bingham
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
@ 2018-12-04 19:50 ` Laurent Pinchart
0 siblings, 0 replies; 16+ messages in thread
From: Laurent Pinchart @ 2018-12-04 19:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux-Renesas, Laurent Pinchart, Kieran Bingham, DRI Development
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
2018-12-04 16:36 ` Laurent Pinchart
@ 2018-12-11 14:57 ` Kieran Bingham
-1 siblings, 0 replies; 16+ messages in thread
From: Kieran Bingham @ 2018-12-11 14:57 UTC (permalink / raw)
To: Laurent Pinchart, dri-devel; +Cc: linux-renesas-soc
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
@ 2018-12-11 14:57 ` Kieran Bingham
0 siblings, 0 replies; 16+ messages in thread
From: Kieran Bingham @ 2018-12-11 14:57 UTC (permalink / raw)
To: Laurent Pinchart, dri-devel; +Cc: linux-renesas-soc
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
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2018-12-11 14:57 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-12-04 16:36 [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency Laurent Pinchart
2018-12-04 16:36 ` Laurent Pinchart
2018-12-04 17:30 ` Geert Uytterhoeven
2018-12-04 17:30 ` Geert Uytterhoeven
2018-12-04 18:13 ` Laurent Pinchart
2018-12-04 18:13 ` Laurent Pinchart
2018-12-04 18:42 ` Geert Uytterhoeven
2018-12-04 18:42 ` Geert Uytterhoeven
2018-12-04 18:51 ` Laurent Pinchart
2018-12-04 18:51 ` Laurent Pinchart
2018-12-04 19:45 ` Geert Uytterhoeven
2018-12-04 19:45 ` Geert Uytterhoeven
2018-12-04 19:50 ` Laurent Pinchart
2018-12-04 19:50 ` Laurent Pinchart
2018-12-11 14:57 ` Kieran Bingham
2018-12-11 14:57 ` Kieran Bingham
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.