All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Rob Clark <robdclark@gmail.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	freedreno <freedreno@lists.freedesktop.org>,
	Stephen Boyd <swboyd@chromium.org>,
	Douglas Anderson <dianders@chromium.org>,
	Rob Clark <robdclark@chromium.org>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Robert Foss <robert.foss@linaro.org>,
	Jonas Karlman <jonas@kwiboo.se>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/4] drm/bridge: ti-sn65dsi86: Implement bridge->mode_valid()
Date: Thu, 12 Aug 2021 22:17:44 +0300	[thread overview]
Message-ID: <YRVz2MN4EDyHZYka@pendragon.ideasonboard.com> (raw)
In-Reply-To: <CAF6AEGs8g2miQz=upd0LMPg109JR7gMeEGyd1u1jQ2WYR=oWtQ@mail.gmail.com>

Hi Rob,

On Thu, Aug 12, 2021 at 12:09:12PM -0700, Rob Clark wrote:
> On Thu, Aug 12, 2021 at 11:44 AM Laurent Pinchart wrote:
> > On Wed, Aug 11, 2021 at 04:52:49PM -0700, Rob Clark wrote:
> > > From: Rob Clark <robdclark@chromium.org>
> > >
> > > For the brave new world of bridges not creating their own connectors, we
> > > need to implement the max clock limitation via bridge->mode_valid()
> > > instead of connector->mode_valid().
> > >
> > > Signed-off-by: Rob Clark <robdclark@chromium.org>
> > > ---
> > >  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 24 +++++++++++++++++++-----
> > >  1 file changed, 19 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > index 5d3b30b2f547..38dcc49eccaf 100644
> > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > @@ -595,6 +595,15 @@ static struct auxiliary_driver ti_sn_aux_driver = {
> > >       .id_table = ti_sn_aux_id_table,
> > >  };
> > >
> > > +static enum drm_mode_status check_mode(const struct drm_display_mode *mode)
> > > +{
> > > +     /* maximum supported resolution is 4K at 60 fps */
> > > +     if (mode->clock > 594000)
> > > +             return MODE_CLOCK_HIGH;
> > > +
> > > +     return MODE_OK;
> > > +}
> > > +
> > >  /* -----------------------------------------------------------------------------
> > >   * DRM Connector Operations
> > >   */
> > > @@ -616,11 +625,7 @@ static enum drm_mode_status
> > >  ti_sn_bridge_connector_mode_valid(struct drm_connector *connector,
> > >                                 struct drm_display_mode *mode)
> > >  {
> > > -     /* maximum supported resolution is 4K at 60 fps */
> > > -     if (mode->clock > 594000)
> > > -             return MODE_CLOCK_HIGH;
> > > -
> > > -     return MODE_OK;
> > > +     return check_mode(mode);
> >
> > Do we need to implement the connector .mode_valid() operation, given
> > that the bridge is linked in the chain ?
> 
> My understanding is that we need to keep it for display drivers that
> are not converted to NO_CONNECTOR..
> 
> But AFAIK snapdragon is the only upstream user of this bridge, so
> after the drm/msm/dsi patch lands we could probably garbage collect
> the connector support.

Even in the !NO_CONNECTOR case, the bridge will still be linked in the
chain, so the atomic helpers should call the bridge .mode_valid() in
addition to the connector .mode_valid(). I think the connector operation
is redundant.

> > >  }
> > >
> > >  static struct drm_connector_helper_funcs ti_sn_bridge_connector_helper_funcs = {
> > > @@ -763,6 +768,14 @@ static void ti_sn_bridge_detach(struct drm_bridge *bridge)
> > >       drm_dp_aux_unregister(&bridge_to_ti_sn65dsi86(bridge)->aux);
> > >  }
> > >
> > > +static enum drm_mode_status
> > > +ti_sn_bridge_mode_valid(struct drm_bridge *bridge,
> > > +                     const struct drm_display_info *info,
> > > +                     const struct drm_display_mode *mode)
> > > +{
> > > +     return check_mode(mode);
> > > +}
> > > +
> > >  static void ti_sn_bridge_disable(struct drm_bridge *bridge)
> > >  {
> > >       struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
> > > @@ -1118,6 +1131,7 @@ static void ti_sn_bridge_post_disable(struct drm_bridge *bridge)
> > >  static const struct drm_bridge_funcs ti_sn_bridge_funcs = {
> > >       .attach = ti_sn_bridge_attach,
> > >       .detach = ti_sn_bridge_detach,
> > > +     .mode_valid = ti_sn_bridge_mode_valid,
> > >       .pre_enable = ti_sn_bridge_pre_enable,
> > >       .enable = ti_sn_bridge_enable,
> > >       .disable = ti_sn_bridge_disable,

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2021-08-12 19:17 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-11 23:52 [PATCH 0/4] drm/msm+ti-sn65dsi86: Fix NO_CONNECTOR fallout Rob Clark
2021-08-11 23:52 ` [PATCH 1/4] drm/bridge: ti-sn65dsi86: Avoid creating multiple connectors Rob Clark
2021-08-12  0:25   ` Stephen Boyd
2021-08-12  0:25     ` Stephen Boyd
2021-08-12 16:38   ` Laurent Pinchart
2021-08-12 16:54   ` Doug Anderson
2021-08-12 16:54     ` Doug Anderson
2021-08-12 17:11     ` Rob Clark
2021-08-12 17:11       ` Rob Clark
2021-08-11 23:52 ` [PATCH 2/4] drm/msm/dsi: Support NO_CONNECTOR bridges Rob Clark
2021-08-12 16:44   ` Laurent Pinchart
2021-08-12 17:31   ` Sam Ravnborg
2021-08-12 17:45     ` Rob Clark
2021-08-12 17:45       ` Rob Clark
2021-08-11 23:52 ` [PATCH 3/4] drm/bridge: ti-sn65dsi86: Implement bridge->mode_valid() Rob Clark
2021-08-12 17:23   ` Doug Anderson
2021-08-12 17:23     ` Doug Anderson
2021-08-12 18:44   ` Laurent Pinchart
2021-08-12 19:09     ` Rob Clark
2021-08-12 19:09       ` Rob Clark
2021-08-12 19:17       ` Laurent Pinchart [this message]
2021-08-11 23:52 ` [PATCH 4/4] drm/bridge: ti-sn65dsi86: Add NO_CONNECTOR support Rob Clark
2021-08-12 17:22   ` Doug Anderson
2021-08-12 17:22     ` Doug Anderson
2021-08-12 19:26   ` Laurent Pinchart
2021-08-12 20:08     ` Doug Anderson
2021-08-12 20:08       ` Doug Anderson
2021-09-20 18:32       ` Rob Clark
2021-09-20 18:32         ` Rob Clark
2021-09-23  0:39         ` Laurent Pinchart

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=YRVz2MN4EDyHZYka@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=dianders@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=jernej.skrabec@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=narmstrong@baylibre.com \
    --cc=robdclark@chromium.org \
    --cc=robdclark@gmail.com \
    --cc=robert.foss@linaro.org \
    --cc=swboyd@chromium.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 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.