* [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.