[PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
Laurent Pinchart
laurent.pinchart at ideasonboard.com
Tue Dec 4 18:51:41 UTC 2018
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 at 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
More information about the dri-devel
mailing list