From: Maxime Ripard <maxime.ripard@bootlin.com>
To: Vasily Khoruzhick <anarsoul@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
Rob Herring <robh@kernel.org>,
Archit Taneja <architt@codeaurora.org>,
devicetree <devicetree@vger.kernel.org>,
David Airlie <airlied@linux.ie>,
linux-sunxi <linux-sunxi@googlegroups.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
Andrzej Hajda <a.hajda@samsung.com>, Chen-Yu Tsai <wens@csie.org>,
Thierry Reding <thierry.reding@gmail.com>,
Sean Paul <seanpaul@chromium.org>,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
Daniel Vetter <daniel@ffwll.ch>,
arm-linux <linux-arm-kernel@lists.infradead.org>,
Icenowy Zheng <icenowy@aosc.io>
Subject: Re: [PATCH v3 06/11] drm/sun4i: rgb: Add DT property to disable strict clock rate check
Date: Tue, 19 Feb 2019 09:56:26 +0100 [thread overview]
Message-ID: <20190219085626.7poutwvm3lrilnon@flea> (raw)
In-Reply-To: <CA+E=qVfDfDvVmKQDeh2e0SA=tm6VpBMpu9MPKUqxFPObxYFXDg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 6575 bytes --]
On Mon, Feb 18, 2019 at 11:33:05AM -0800, Vasily Khoruzhick wrote:
> On Mon, Feb 18, 2019 at 10:26 AM Rob Herring <robh@kernel.org> wrote:
> >
> > On Thu, Feb 14, 2019 at 09:09:52PM -0800, Vasily Khoruzhick wrote:
> > > Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i: rgb:
> > > Validate the clock rate") prevents some panel and bridges from working with
> > > sun4i driver.
> >
> > Sounds lile a regression that should be reverted. The fix is not a
> > backwards compatible change either.
>
> anx6345 driver isn't mainlined yet and I'm not sure if this change
> breaks any mainlined boards. So likely there's not enough
> justification to revert it.
>
> > > Unfortunately, dotclock frequency for some modes are not achievable on
> > > sunxi hardware, and there's a slight deviation in rate returned by
> > > clk_round_rate(), so they fail this check.
> > >
> > > Experiments show that panels and bridges work fine with this slight
> > > deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP panel
> > > requests 73 MHz, gets 72.296MHz instead (0.96% difference) and works just
> > > fine.
> > >
> > > This patch adds DT property to disable strict clock rate check
> > >
> > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > > ---
> > > .../devicetree/bindings/display/sunxi/sun4i-drm.txt | 2 ++
> > > drivers/gpu/drm/sun4i/sun4i_rgb.c | 5 +++++
> > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 3 +++
> > > drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 +
> > > 4 files changed, 11 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > index f426bdb42f18..18c8b053a28d 100644
> > > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > @@ -63,6 +63,8 @@ Required properties:
> > > Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > > first port should be the input endpoint. The second should be the
> > > output, usually to an HDMI connector.
> > > + - no-strict-clock-check: don't reject timings if exact dot clock can't be
> > > + reached.
> >
> > This should be the default IMO. Most panels are a single timing, so if
> > we reject it the fallback no display?
>
> As far as I remember the change was introduced to reject some modes
> for which dotclock can't be reached when driver is used with VGA
> bridge. So if we make it default it'll break boards with VGA bridge
> and old DT.
>
> > I thought we had some mechanism already to allow some range of
> > frequencies. I think the chromeos guys needed something IIRC.
>
> You can specify frequency range for panels, but there's nothing for
> bridges. In my case EDID doesn't specify clock tolerance.
I gave it some more though, and came up with the following patch. The
basic idea is to leave the boundary check for the bridges that will
have EDID and we need to filter out the modes that have no chance of
being supported. The tolerancy used is the one defined in VESA specs,
but I added a module parameter if you wanted to tune that.
And finally, since most of our panels are single timings without any
tolerancy, we just try our best in this case and that's it, while
leaving the door open to support display_timings and being able to do
more once we have an idea of what the tolerancies are.
If that works for you, I'll submit it.
Maxime
--- >8 ---
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index f4a22689eb54..0460146aab75 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -43,6 +43,25 @@ drm_encoder_to_sun4i_rgb(struct drm_encoder *encoder)
encoder);
}
+static inline struct drm_connector *
+sun4i_rgb_get_connector_from_encoder(const struct drm_encoder *encoder)
+{
+ struct drm_connector *connector = NULL, *tmp;
+ struct drm_connector_list_iter iter;
+
+ drm_connector_list_iter_begin(encoder->dev, &iter);
+ drm_for_each_connector_iter(tmp, &iter)
+ if (tmp->encoder == encoder) {
+ connector = tmp;
+ goto out;
+ }
+
+out:
+ drm_connector_list_iter_end(&iter);
+
+ return connector;
+}
+
static int sun4i_rgb_get_modes(struct drm_connector *connector)
{
struct sun4i_rgb *rgb =
@@ -52,11 +71,22 @@ static int sun4i_rgb_get_modes(struct drm_connector *connector)
return drm_panel_get_modes(tcon->panel);
}
+/*
+ * VESA DMT defines a tolerancy of 0.5% on the pixel clock, while the
+ * CVT spec reuses that tolerancy in its examples, so it looks to be a
+ * good default tolerancy for the EDID-based modes.
+ */
+static unsigned int clock_tolerancy = 5;
+module_param(clock_tolerancy, uint, 0644);
+MODULE_PARM_DESC(clock_tolerancy,
+ "Tolerancy of the pixel clock in per mille");
+
static enum drm_mode_status sun4i_rgb_mode_valid(struct drm_encoder *crtc,
const struct drm_display_mode *mode)
{
struct sun4i_rgb *rgb = drm_encoder_to_sun4i_rgb(crtc);
struct sun4i_tcon *tcon = rgb->tcon;
+ struct drm_connector *connector = sun4i_rgb_get_connector_from_encoder(crtc);
u32 hsync = mode->hsync_end - mode->hsync_start;
u32 vsync = mode->vsync_end - mode->vsync_start;
unsigned long rate = mode->clock * 1000;
@@ -92,15 +122,27 @@ static enum drm_mode_status sun4i_rgb_mode_valid(struct drm_encoder *crtc,
DRM_DEBUG_DRIVER("Vertical parameters OK\n");
+ /*
+ * TODO: We should use the struct display_timing if available
+ * and / or trying to stretch the timings within that
+ * tolerancy to take care of panels that we wouldn't be able
+ * to have a exact match for.
+ */
+ if (connector->connector_type == DRM_MODE_CONNECTOR_Unknown) {
+ DRM_DEBUG_DRIVER("RGB panel used, skipping clock rate checks");
+ goto out;
+ }
+
tcon->dclk_min_div = 6;
tcon->dclk_max_div = 127;
rounded_rate = clk_round_rate(tcon->dclk, rate);
- if (rounded_rate < rate)
+ if (rounded_rate < (rate * (1000 - clock_tolerancy) / 1000))
return MODE_CLOCK_LOW;
- if (rounded_rate > rate)
+ if (rounded_rate > (rate * (1000 + clock_tolerancy) / 1000))
return MODE_CLOCK_HIGH;
+out:
DRM_DEBUG_DRIVER("Clock rate OK\n");
return MODE_OK;
--- >8 ---
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-02-19 8:56 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-15 5:09 [PATCH v3 00/11] Analogix ANX6345 RGB-(e)DP bridge support Vasily Khoruzhick
2019-02-15 5:09 ` [PATCH v3 01/11] drm/bridge: move ANA78xx driver to analogix subdirectory Vasily Khoruzhick
2019-02-15 5:09 ` [PATCH v3 02/11] drm/bridge: split some definitions of ANX78xx to dedicated headers Vasily Khoruzhick
2019-02-15 5:09 ` [PATCH v3 03/11] drm/bridge: extract some Analogix I2C DP common code Vasily Khoruzhick
2019-02-15 5:09 ` [PATCH v3 04/11] dt-bindings: Add ANX6345 DP/eDP transmitter binding Vasily Khoruzhick
2019-02-18 18:13 ` Rob Herring
2019-02-15 5:09 ` [PATCH v3 05/11] drm/bridge: Add Analogix anx6345 support Vasily Khoruzhick
2019-02-15 8:23 ` [linux-sunxi] " Priit Laes
2019-02-15 19:21 ` Vasily Khoruzhick
2019-02-15 9:13 ` Andrzej Hajda
2019-02-15 19:36 ` Vasily Khoruzhick
2019-02-26 7:12 ` Andrzej Hajda
2019-02-15 5:09 ` [PATCH v3 06/11] drm/sun4i: rgb: Add DT property to disable strict clock rate check Vasily Khoruzhick
2019-02-18 18:26 ` Rob Herring
2019-02-18 19:33 ` Vasily Khoruzhick
2019-02-19 8:56 ` Maxime Ripard [this message]
2019-02-19 15:44 ` Vasily Khoruzhick
2019-02-20 10:33 ` Maxime Ripard
2019-02-21 6:39 ` Vasily Khoruzhick
2019-02-21 6:41 ` Vasily Khoruzhick
2019-02-15 5:09 ` [PATCH v3 07/11] arm64: allwinner: a64: add pinmux for RGB666 LCD Vasily Khoruzhick
2019-02-15 5:09 ` [PATCH v3 08/11] drm/panel: simple: Add BOE HB140WX1-501 panel support Vasily Khoruzhick
2019-02-16 20:43 ` Sam Ravnborg
2019-02-16 20:48 ` Vasily Khoruzhick
2019-02-16 21:12 ` Sam Ravnborg
2019-02-15 5:09 ` [PATCH v3 09/11] dt-bindings: Add Guangdong Neweast Optoelectronics CO. LTD vendor prefix Vasily Khoruzhick
2019-02-18 18:27 ` Rob Herring
2019-02-15 5:09 ` [PATCH v3 10/11] drm/panel: simple: Add NewEast Optoelectronics CO., LTD WJFH116008A panel support Vasily Khoruzhick
2019-02-18 18:33 ` Rob Herring
2019-02-18 19:06 ` Vasily Khoruzhick
2019-02-19 14:54 ` Rob Herring
2019-02-19 21:35 ` Vasily Khoruzhick
2019-02-22 18:37 ` Rob Herring
2019-03-07 6:12 ` Vasily Khoruzhick
2019-02-15 5:09 ` [PATCH v3 11/11] arm64: allwinner: a64: enable LCD-related hardware for Pinebook Vasily Khoruzhick
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=20190219085626.7poutwvm3lrilnon@flea \
--to=maxime.ripard@bootlin.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=a.hajda@samsung.com \
--cc=airlied@linux.ie \
--cc=anarsoul@gmail.com \
--cc=architt@codeaurora.org \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=icenowy@aosc.io \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-sunxi@googlegroups.com \
--cc=mark.rutland@arm.com \
--cc=robh@kernel.org \
--cc=seanpaul@chromium.org \
--cc=thierry.reding@gmail.com \
--cc=wens@csie.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