All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Xin Ji <xji@analogixsemi.com>
Cc: Daniel Vetter <daniel@ffwll.ch>,
	Nicolas Boichat <drinkcat@google.com>,
	devel@driverdev.osuosl.org,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Jonas Karlman <jonas@kwiboo.se>,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	David Airlie <airlied@linux.ie>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Pi-Hsun Shih <pihsun@chromium.org>,
	Sheng Pan <span@analogixsemi.com>,
	Qilin Wen <qwen@analogixsemi.com>,
	Ming Liu <mliu@analogixsemi.com>
Subject: Re: [PATCH v7 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
Date: Thu, 30 Apr 2020 15:37:31 +0200	[thread overview]
Message-ID: <20200430133731.GA10381@phenom.ffwll.local> (raw)
In-Reply-To: <20200430033614.GA6645@xin-VirtualBox>

On Thu, Apr 30, 2020 at 11:36:14AM +0800, Xin Ji wrote:
> On Tue, Apr 28, 2020 at 12:05:08PM +0200, Daniel Vetter wrote:
> > On Fri, Apr 24, 2020 at 08:12:04PM +0800, Nicolas Boichat wrote:
> > > On Fri, Apr 24, 2020 at 2:51 PM Xin Ji <xji@analogixsemi.com> wrote:
> > > >
> > > > On Thu, Apr 23, 2020 at 07:55:15PM +0800, Nicolas Boichat wrote:
> > > > > Hi,
> > > > >
> > > > > Just commenting on the mode_fixup function that was added in v7.
> > > > >
> > > > [snip]
> > > > > > +       /*
> > > > > > +        * once illegal timing detected, use default HFP, HSYNC, HBP
> > > > > > +        */
> > > > > > +       if (hblanking < HBLANKING_MIN || (hfp < HP_MIN && hbp < HP_MIN)) {
> > > > >
> > > > > should this be adj_hblanking/adj_hfp/adj_hbp?
> > > > NO, need check original HFP and HBP, if they are not legal, driver need
> > > > set default value to adj_hsync, adj_hfp, adj_hbp.
> > > > >
> > > > > > +               adj_hsync = SYNC_LEN_DEF;
> > > > > > +               adj_hfp = HFP_HBP_DEF;
> > > > > > +               adj_hbp = HFP_HBP_DEF;
> > > > > > +               vref = adj->clock * 1000 / (adj->htotal * adj->vtotal);
> > > > > > +               if (hblanking < HBLANKING_MIN) {
> > > > > > +                       delta_adj = HBLANKING_MIN - hblanking;
> > > > > > +                       adj_clock = vref * delta_adj * adj->vtotal;
> > > > > > +                       adj->clock += DIV_ROUND_UP(adj_clock, 1000);
> > > > > > +               } else {
> > > > > > +                       delta_adj = hblanking - HBLANKING_MIN;
> > > > > > +                       adj_clock = vref * delta_adj * adj->vtotal;
> > > > > > +                       adj->clock -= DIV_ROUND_UP(adj_clock, 1000);
> > > > > > +               }
> > > > > > +
> > > > > > +               DRM_WARN("illegal hblanking timing, use default.\n");
> > > > > > +               DRM_WARN("hfp(%d),hbp(%d),hsync(%d).\n", hfp, hbp, hsync);
> > > > >
> > > > > How likely is it that this mode is going to work? Can you just return
> > > > > false here to reject the mode?
> > > > We want to set the default minimal Hblancking value, then it may display,
> > > > otherwise. If we just return false, there is no display for sure.
> > > 
> > > Right, understand your argument. I'm pondering if it's not just better
> > > to reject the mode rather than trying a timing that is definitely
> > > quite different from what the monitor was asking for. No super strong
> > > opinion, I'll let other people on the list weigh in.
> > 
> > Yeah mode_fixup is supposed to be used to adjust the mode in intermediate
> > stages (e.g. if you go from progressive to interlaced only at the end of
> > your pipeline or something like that). It's not meant for adjusting the
> > mode yout actually put out through a hdmi or dp connector. For fixed
> > panels adjusting modes to fit the panel is also fairly common, but not for
> > external outputs.
> > 
> > Since this is a DP bridge I'd say no adjusting, just reject what doesn't
> > fit.
> We have found some panel which HBP less than 8, if we reject to adjust
> video timing, then there is no display. The customer does not accept it,
> they push us to fix it, the only resolve way is to adjust timing.

Are we talking about external DP screen here, or some built-in panel? For
the later case we do a lot of mode adjusting in many drivers ...

I haven't checked, by if our connector type is eDP then this should be all
fine.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Xin Ji <xji@analogixsemi.com>
Cc: devel@driverdev.osuosl.org, Nicolas Boichat <drinkcat@google.com>,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	Pi-Hsun Shih <pihsun@chromium.org>,
	Neil Armstrong <narmstrong@baylibre.com>,
	David Airlie <airlied@linux.ie>,
	Qilin Wen <qwen@analogixsemi.com>,
	Jonas Karlman <jonas@kwiboo.se>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Andrzej Hajda <a.hajda@samsung.com>,
	Ming Liu <mliu@analogixsemi.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Sheng Pan <span@analogixsemi.com>
Subject: Re: [PATCH v7 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
Date: Thu, 30 Apr 2020 15:37:31 +0200	[thread overview]
Message-ID: <20200430133731.GA10381@phenom.ffwll.local> (raw)
In-Reply-To: <20200430033614.GA6645@xin-VirtualBox>

On Thu, Apr 30, 2020 at 11:36:14AM +0800, Xin Ji wrote:
> On Tue, Apr 28, 2020 at 12:05:08PM +0200, Daniel Vetter wrote:
> > On Fri, Apr 24, 2020 at 08:12:04PM +0800, Nicolas Boichat wrote:
> > > On Fri, Apr 24, 2020 at 2:51 PM Xin Ji <xji@analogixsemi.com> wrote:
> > > >
> > > > On Thu, Apr 23, 2020 at 07:55:15PM +0800, Nicolas Boichat wrote:
> > > > > Hi,
> > > > >
> > > > > Just commenting on the mode_fixup function that was added in v7.
> > > > >
> > > > [snip]
> > > > > > +       /*
> > > > > > +        * once illegal timing detected, use default HFP, HSYNC, HBP
> > > > > > +        */
> > > > > > +       if (hblanking < HBLANKING_MIN || (hfp < HP_MIN && hbp < HP_MIN)) {
> > > > >
> > > > > should this be adj_hblanking/adj_hfp/adj_hbp?
> > > > NO, need check original HFP and HBP, if they are not legal, driver need
> > > > set default value to adj_hsync, adj_hfp, adj_hbp.
> > > > >
> > > > > > +               adj_hsync = SYNC_LEN_DEF;
> > > > > > +               adj_hfp = HFP_HBP_DEF;
> > > > > > +               adj_hbp = HFP_HBP_DEF;
> > > > > > +               vref = adj->clock * 1000 / (adj->htotal * adj->vtotal);
> > > > > > +               if (hblanking < HBLANKING_MIN) {
> > > > > > +                       delta_adj = HBLANKING_MIN - hblanking;
> > > > > > +                       adj_clock = vref * delta_adj * adj->vtotal;
> > > > > > +                       adj->clock += DIV_ROUND_UP(adj_clock, 1000);
> > > > > > +               } else {
> > > > > > +                       delta_adj = hblanking - HBLANKING_MIN;
> > > > > > +                       adj_clock = vref * delta_adj * adj->vtotal;
> > > > > > +                       adj->clock -= DIV_ROUND_UP(adj_clock, 1000);
> > > > > > +               }
> > > > > > +
> > > > > > +               DRM_WARN("illegal hblanking timing, use default.\n");
> > > > > > +               DRM_WARN("hfp(%d),hbp(%d),hsync(%d).\n", hfp, hbp, hsync);
> > > > >
> > > > > How likely is it that this mode is going to work? Can you just return
> > > > > false here to reject the mode?
> > > > We want to set the default minimal Hblancking value, then it may display,
> > > > otherwise. If we just return false, there is no display for sure.
> > > 
> > > Right, understand your argument. I'm pondering if it's not just better
> > > to reject the mode rather than trying a timing that is definitely
> > > quite different from what the monitor was asking for. No super strong
> > > opinion, I'll let other people on the list weigh in.
> > 
> > Yeah mode_fixup is supposed to be used to adjust the mode in intermediate
> > stages (e.g. if you go from progressive to interlaced only at the end of
> > your pipeline or something like that). It's not meant for adjusting the
> > mode yout actually put out through a hdmi or dp connector. For fixed
> > panels adjusting modes to fit the panel is also fairly common, but not for
> > external outputs.
> > 
> > Since this is a DP bridge I'd say no adjusting, just reject what doesn't
> > fit.
> We have found some panel which HBP less than 8, if we reject to adjust
> video timing, then there is no display. The customer does not accept it,
> they push us to fix it, the only resolve way is to adjust timing.

Are we talking about external DP screen here, or some built-in panel? For
the later case we do a lot of mode adjusting in many drivers ...

I haven't checked, by if our connector type is eDP then this should be all
fine.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Xin Ji <xji@analogixsemi.com>
Cc: devel@driverdev.osuosl.org, Nicolas Boichat <drinkcat@google.com>,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	Pi-Hsun Shih <pihsun@chromium.org>,
	Neil Armstrong <narmstrong@baylibre.com>,
	David Airlie <airlied@linux.ie>,
	Qilin Wen <qwen@analogixsemi.com>,
	Jonas Karlman <jonas@kwiboo.se>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Andrzej Hajda <a.hajda@samsung.com>,
	Ming Liu <mliu@analogixsemi.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Sheng Pan <span@analogixsemi.com>
Subject: Re: [PATCH v7 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
Date: Thu, 30 Apr 2020 15:37:31 +0200	[thread overview]
Message-ID: <20200430133731.GA10381@phenom.ffwll.local> (raw)
In-Reply-To: <20200430033614.GA6645@xin-VirtualBox>

On Thu, Apr 30, 2020 at 11:36:14AM +0800, Xin Ji wrote:
> On Tue, Apr 28, 2020 at 12:05:08PM +0200, Daniel Vetter wrote:
> > On Fri, Apr 24, 2020 at 08:12:04PM +0800, Nicolas Boichat wrote:
> > > On Fri, Apr 24, 2020 at 2:51 PM Xin Ji <xji@analogixsemi.com> wrote:
> > > >
> > > > On Thu, Apr 23, 2020 at 07:55:15PM +0800, Nicolas Boichat wrote:
> > > > > Hi,
> > > > >
> > > > > Just commenting on the mode_fixup function that was added in v7.
> > > > >
> > > > [snip]
> > > > > > +       /*
> > > > > > +        * once illegal timing detected, use default HFP, HSYNC, HBP
> > > > > > +        */
> > > > > > +       if (hblanking < HBLANKING_MIN || (hfp < HP_MIN && hbp < HP_MIN)) {
> > > > >
> > > > > should this be adj_hblanking/adj_hfp/adj_hbp?
> > > > NO, need check original HFP and HBP, if they are not legal, driver need
> > > > set default value to adj_hsync, adj_hfp, adj_hbp.
> > > > >
> > > > > > +               adj_hsync = SYNC_LEN_DEF;
> > > > > > +               adj_hfp = HFP_HBP_DEF;
> > > > > > +               adj_hbp = HFP_HBP_DEF;
> > > > > > +               vref = adj->clock * 1000 / (adj->htotal * adj->vtotal);
> > > > > > +               if (hblanking < HBLANKING_MIN) {
> > > > > > +                       delta_adj = HBLANKING_MIN - hblanking;
> > > > > > +                       adj_clock = vref * delta_adj * adj->vtotal;
> > > > > > +                       adj->clock += DIV_ROUND_UP(adj_clock, 1000);
> > > > > > +               } else {
> > > > > > +                       delta_adj = hblanking - HBLANKING_MIN;
> > > > > > +                       adj_clock = vref * delta_adj * adj->vtotal;
> > > > > > +                       adj->clock -= DIV_ROUND_UP(adj_clock, 1000);
> > > > > > +               }
> > > > > > +
> > > > > > +               DRM_WARN("illegal hblanking timing, use default.\n");
> > > > > > +               DRM_WARN("hfp(%d),hbp(%d),hsync(%d).\n", hfp, hbp, hsync);
> > > > >
> > > > > How likely is it that this mode is going to work? Can you just return
> > > > > false here to reject the mode?
> > > > We want to set the default minimal Hblancking value, then it may display,
> > > > otherwise. If we just return false, there is no display for sure.
> > > 
> > > Right, understand your argument. I'm pondering if it's not just better
> > > to reject the mode rather than trying a timing that is definitely
> > > quite different from what the monitor was asking for. No super strong
> > > opinion, I'll let other people on the list weigh in.
> > 
> > Yeah mode_fixup is supposed to be used to adjust the mode in intermediate
> > stages (e.g. if you go from progressive to interlaced only at the end of
> > your pipeline or something like that). It's not meant for adjusting the
> > mode yout actually put out through a hdmi or dp connector. For fixed
> > panels adjusting modes to fit the panel is also fairly common, but not for
> > external outputs.
> > 
> > Since this is a DP bridge I'd say no adjusting, just reject what doesn't
> > fit.
> We have found some panel which HBP less than 8, if we reject to adjust
> video timing, then there is no display. The customer does not accept it,
> they push us to fix it, the only resolve way is to adjust timing.

Are we talking about external DP screen here, or some built-in panel? For
the later case we do a lot of mode adjusting in many drivers ...

I haven't checked, by if our connector type is eDP then this should be all
fine.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-04-30 13:37 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-25  6:11 [PATCH v7 0/2] Add initial support for slimport anx7625 Xin Ji
2020-02-25  8:20 ` Xin Ji
2020-02-25  8:20 ` Xin Ji
2020-02-25  8:20 ` Xin Ji
2020-02-25  6:11 ` Xin Ji
2020-02-25  6:11 ` Xin Ji
2020-02-25  6:14 ` [PATCH v7 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding Xin Ji
2020-02-25  6:14   ` Xin Ji
2020-02-25  6:14   ` Xin Ji
2020-02-25  6:15 ` [PATCH v7 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver Xin Ji
2020-02-25  6:15   ` Xin Ji
2020-02-25  6:15   ` Xin Ji
2020-04-23 11:55   ` Nicolas Boichat
2020-04-23 11:55     ` Nicolas Boichat
2020-04-23 11:55     ` Nicolas Boichat
2020-04-24  6:51     ` Xin Ji
2020-04-24  6:51       ` Xin Ji
2020-04-24  6:51       ` Xin Ji
2020-04-24 12:12       ` Nicolas Boichat
2020-04-24 12:12         ` Nicolas Boichat
2020-04-24 12:12         ` Nicolas Boichat
2020-04-28 10:05         ` Daniel Vetter
2020-04-28 10:05           ` Daniel Vetter
2020-04-28 10:05           ` Daniel Vetter
2020-04-30  3:36           ` Xin Ji
2020-04-30  3:36             ` Xin Ji
2020-04-30  3:36             ` Xin Ji
2020-04-30 13:37             ` Daniel Vetter [this message]
2020-04-30 13:37               ` Daniel Vetter
2020-04-30 13:37               ` Daniel Vetter
2020-04-30 13:38               ` Daniel Vetter
2020-04-30 13:38                 ` Daniel Vetter
2020-04-30 13:38                 ` Daniel Vetter
2020-04-30 13:47                 ` Xin Ji
2020-04-30 13:47                   ` Xin Ji
2020-04-30 13:54                   ` Daniel Vetter
2020-04-30 13:54                     ` Daniel Vetter
2020-04-30 13:58                     ` Xin Ji
2020-04-30 13:58                       ` Xin Ji
2020-02-25  7:42 ` [PATCH v7 0/2] Add initial support for slimport anx7625 Dan Carpenter
2020-02-25  7:42   ` Dan Carpenter
2020-02-25  7:42   ` Dan Carpenter
2020-02-25  8:11   ` Xin Ji
2020-02-25  8:11     ` Xin Ji
2020-02-25  8:11     ` Xin Ji

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=20200430133731.GA10381@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=a.hajda@samsung.com \
    --cc=airlied@linux.ie \
    --cc=dan.carpenter@oracle.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=drinkcat@google.com \
    --cc=jernej.skrabec@siol.net \
    --cc=jonas@kwiboo.se \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mliu@analogixsemi.com \
    --cc=narmstrong@baylibre.com \
    --cc=pihsun@chromium.org \
    --cc=qwen@analogixsemi.com \
    --cc=span@analogixsemi.com \
    --cc=xji@analogixsemi.com \
    /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 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.