dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	Kieran Bingham <kieran.bingham@ideasonboard.com>,
	DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v2] drm: rcar-du: dw-hdmi: Reject modes with a too high clock frequency
Date: Tue, 04 Dec 2018 20:51:41 +0200	[thread overview]
Message-ID: <4080472.x6oRvDE9so@avalon> (raw)
In-Reply-To: <CAMuHMdWwCh2BggD9p9aZrmVziiqPiB2strFvgBBMVhJQ4AQx=w@mail.gmail.com>

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

  reply	other threads:[~2018-12-04 18:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 17:30 ` Geert Uytterhoeven
2018-12-04 18:13   ` Laurent Pinchart
2018-12-04 18:42     ` Geert Uytterhoeven
2018-12-04 18:51       ` Laurent Pinchart [this message]
2018-12-04 19:45         ` Geert Uytterhoeven
2018-12-04 19:50           ` Laurent Pinchart
2018-12-11 14:57 ` Kieran Bingham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4080472.x6oRvDE9so@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=geert@linux-m68k.org \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=linux-renesas-soc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox