| Message ID | 20190203185501.8958-7-anarsoul@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Analogix ANX6345 RGB-(e)DP bridge support | expand |
Hi, On Sun, Feb 03, 2019 at 10:54:55AM -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. > > 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 a 1% tolerence to the dot clock check when bridge is > connected. > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> I'm not sure we want to make exceptions for all the hardware combination we face, but we should go for something more generic (and easier to maintain instead). IIRC, from the previous discussion, HDMI had a tolerancy requirement in the standard. Do you know if there's such a thing for eDP? That would solve the issue for all the eDP displays at once. Maxime
On Mon, Feb 4, 2019 at 6:20 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > Hi, > > On Sun, Feb 03, 2019 at 10:54:55AM -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. > > > > 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 a 1% tolerence to the dot clock check when bridge is > > connected. > > > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> > > I'm not sure we want to make exceptions for all the hardware > combination we face, but we should go for something more generic (and > easier to maintain instead). > > IIRC, from the previous discussion, HDMI had a tolerancy requirement > in the standard. Do you know if there's such a thing for eDP? That > would solve the issue for all the eDP displays at once. I don't have access to eDP standard - vesa.org says it's available to members only. > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
于 2019年2月5日 GMT+08:00 上午12:26:43, Vasily Khoruzhick <anarsoul@gmail.com> 写到: >On Mon, Feb 4, 2019 at 6:20 AM Maxime Ripard ><maxime.ripard@bootlin.com> wrote: >> >> Hi, >> >> On Sun, Feb 03, 2019 at 10:54:55AM -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. >> > >> > 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 a 1% tolerence to the dot clock check when bridge >is >> > connected. >> > >> > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> >> >> I'm not sure we want to make exceptions for all the hardware >> combination we face, but we should go for something more generic (and >> easier to maintain instead). >> >> IIRC, from the previous discussion, HDMI had a tolerancy requirement >> in the standard. Do you know if there's such a thing for eDP? That >> would solve the issue for all the eDP displays at once. > >I don't have access to eDP standard - vesa.org says it's available to >members only. Try out to grab an old version? I remember 1.0 is open. > >> Maxime >> >> -- >> Maxime Ripard, Bootlin >> Embedded Linux and Kernel engineering >> https://bootlin.com > >_______________________________________________ >linux-arm-kernel mailing list >linux-arm-kernel@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng <icenowy@aosc.io> wrote: > >> IIRC, from the previous discussion, HDMI had a tolerancy requirement > >> in the standard. Do you know if there's such a thing for eDP? That > >> would solve the issue for all the eDP displays at once. > > > >I don't have access to eDP standard - vesa.org says it's available to > >members only. > > Try out to grab an old version? > > I remember 1.0 is open. I can't find anything regarding dot clock tolerance in DisplayPort specification.
On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote: > On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng <icenowy@aosc.io> wrote: > > >> IIRC, from the previous discussion, HDMI had a tolerancy requirement > > >> in the standard. Do you know if there's such a thing for eDP? That > > >> would solve the issue for all the eDP displays at once. > > > > > >I don't have access to eDP standard - vesa.org says it's available to > > >members only. > > > > Try out to grab an old version? > > > > I remember 1.0 is open. > > I can't find anything regarding dot clock tolerance in DisplayPort > specification. I guess since the DP is a VESA spec, it's probably .5%, just like on the EDID (well, CVT). Maxime
On Tue, Feb 5, 2019 at 7:42 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote: > > On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng <icenowy@aosc.io> wrote: > > > >> IIRC, from the previous discussion, HDMI had a tolerancy requirement > > > >> in the standard. Do you know if there's such a thing for eDP? That > > > >> would solve the issue for all the eDP displays at once. > > > > > > > >I don't have access to eDP standard - vesa.org says it's available to > > > >members only. > > > > > > Try out to grab an old version? > > > > > > I remember 1.0 is open. > > > > I can't find anything regarding dot clock tolerance in DisplayPort > > specification. > > I guess since the DP is a VESA spec, it's probably .5%, just like on > the EDID (well, CVT). Unfortunately that's not enough for Pinebook. It needs 1% for 768p panel. > > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
On Tue, Feb 05, 2019 at 09:49:17AM -0800, Vasily Khoruzhick wrote: > On Tue, Feb 5, 2019 at 7:42 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > > > On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote: > > > On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng <icenowy@aosc.io> wrote: > > > > >> IIRC, from the previous discussion, HDMI had a tolerancy requirement > > > > >> in the standard. Do you know if there's such a thing for eDP? That > > > > >> would solve the issue for all the eDP displays at once. > > > > > > > > > >I don't have access to eDP standard - vesa.org says it's available to > > > > >members only. > > > > > > > > Try out to grab an old version? > > > > > > > > I remember 1.0 is open. > > > > > > I can't find anything regarding dot clock tolerance in DisplayPort > > > specification. > > > > I guess since the DP is a VESA spec, it's probably .5%, just like on > > the EDID (well, CVT). > > Unfortunately that's not enough for Pinebook. It needs 1% for 768p > panel. And that mode is stored in the EDID as a standard (or established) timing, or a detailed timing? If the latter, then it should also provide the tolerancies as part of the panel timing description. If the former, then what would be the advertised pixel clock and the one we can compute? Maybe we have a bug somewhere. Maxime
On Wed, Feb 06, 2019 at 10:16:08AM +0100, Maxime Ripard wrote: > On Tue, Feb 05, 2019 at 09:49:17AM -0800, Vasily Khoruzhick wrote: > > On Tue, Feb 5, 2019 at 7:42 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > > > > > On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote: > > > > On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng <icenowy@aosc.io> wrote: > > > > > >> IIRC, from the previous discussion, HDMI had a tolerancy requirement > > > > > >> in the standard. Do you know if there's such a thing for eDP? That > > > > > >> would solve the issue for all the eDP displays at once. > > > > > > > > > > > >I don't have access to eDP standard - vesa.org says it's available to > > > > > >members only. > > > > > > > > > > Try out to grab an old version? > > > > > > > > > > I remember 1.0 is open. > > > > > > > > I can't find anything regarding dot clock tolerance in DisplayPort > > > > specification. > > > > > > I guess since the DP is a VESA spec, it's probably .5%, just like on > > > the EDID (well, CVT). > > > > Unfortunately that's not enough for Pinebook. It needs 1% for 768p > > panel. > > And that mode is stored in the EDID as a standard (or established) > timing, or a detailed timing? > > If the latter, then it should also provide the tolerancies as part of > the panel timing description. The simple-panel driver can, in addition to a struct drm_display_mode take a struct display_timings to specify the modes. These allow to define <minimum, typical, maximum> triplets for each parameter, which are usually found in panel datasheets. Of course that's not going to help you much if all you have is EDID and if that doesn't provide tolerances. Thierry > If the former, then what would be the advertised pixel clock and the > one we can compute? Maybe we have a bug somewhere. > > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c b/drivers/gpu/drm/sun4i/sun4i_rgb.c index f4a22689eb54..3f04446120f6 100644 --- a/drivers/gpu/drm/sun4i/sun4i_rgb.c +++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c @@ -61,6 +61,7 @@ static enum drm_mode_status sun4i_rgb_mode_valid(struct drm_encoder *crtc, u32 vsync = mode->vsync_end - mode->vsync_start; unsigned long rate = mode->clock * 1000; long rounded_rate; + long tolerance = 0; DRM_DEBUG_DRIVER("Validating modes...\n"); @@ -95,10 +96,14 @@ static enum drm_mode_status sun4i_rgb_mode_valid(struct drm_encoder *crtc, tcon->dclk_min_div = 6; tcon->dclk_max_div = 127; rounded_rate = clk_round_rate(tcon->dclk, rate); - if (rounded_rate < rate) + if (tcon->bridge) + /* Check against a 1% tolerance for the dot clock for bridge */ + tolerance = rate / 100; + + if (rounded_rate < (rate - tolerance)) return MODE_CLOCK_LOW; - if (rounded_rate > rate) + if (rounded_rate > (rate + tolerance)) return MODE_CLOCK_HIGH; DRM_DEBUG_DRIVER("Clock rate OK\n"); @@ -172,7 +177,6 @@ static struct drm_encoder_funcs sun4i_rgb_enc_funcs = { int sun4i_rgb_init(struct drm_device *drm, struct sun4i_tcon *tcon) { struct drm_encoder *encoder; - struct drm_bridge *bridge; struct sun4i_rgb *rgb; int ret; @@ -183,7 +187,7 @@ int sun4i_rgb_init(struct drm_device *drm, struct sun4i_tcon *tcon) encoder = &rgb->encoder; ret = drm_of_find_panel_or_bridge(tcon->dev->of_node, 1, 0, - &tcon->panel, &bridge); + &tcon->panel, &tcon->bridge); if (ret) { dev_info(drm->dev, "No panel or bridge found... RGB output disabled\n"); return 0; @@ -225,8 +229,8 @@ int sun4i_rgb_init(struct drm_device *drm, struct sun4i_tcon *tcon) } } - if (bridge) { - ret = drm_bridge_attach(encoder, bridge, NULL); + if (tcon->bridge) { + ret = drm_bridge_attach(encoder, tcon->bridge, NULL); if (ret) { dev_err(drm->dev, "Couldn't attach our bridge\n"); goto err_cleanup_connector; diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h index b5214d71610f..487cb070b25c 100644 --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h @@ -258,6 +258,7 @@ struct sun4i_tcon { struct reset_control *lvds_rst; struct drm_panel *panel; + struct drm_bridge *bridge; /* Platform adjustments */ const struct sun4i_tcon_quirks *quirks;
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. 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 a 1% tolerence to the dot clock check when bridge is connected. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> --- drivers/gpu/drm/sun4i/sun4i_rgb.c | 16 ++++++++++------ drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 + 2 files changed, 11 insertions(+), 6 deletions(-)