public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: John Keeping <john@metanate.com>
Cc: Sam Ravnborg <sam@ravnborg.org>,
	Doug Anderson <dianders@chromium.org>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Robert Foss <rfoss@kernel.org>, Jonas Karlman <jonas@kwiboo.se>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Stephen Boyd <swboyd@chromium.org>,
	Andrzej Hajda <andrzej.hajda@intel.com>,
	Hsin-Yi Wang <hsinyi@chromium.org>
Subject: Re: [PATCH] drm/bridge: panel: Set orientation on panel_bridge connector
Date: Sun, 22 Jan 2023 17:01:27 +0200	[thread overview]
Message-ID: <Y81Px74OUYt21nj4@pendragon.ideasonboard.com> (raw)
In-Reply-To: <Y8wnswk++tvr9xMe@donbot>

Hello,

On Sat, Jan 21, 2023 at 05:58:11PM +0000, John Keeping wrote:
> On Sat, Jan 21, 2023 at 09:57:18AM +0100, Sam Ravnborg wrote:
> > On Fri, Jan 20, 2023 at 01:44:38PM -0800, Doug Anderson wrote:
> > > On Fri, Jan 20, 2023 at 3:43 AM John Keeping wrote:
> > > >
> > > > Commit 15b9ca1641f0 ("drm: Config orientation property if panel provides
> > > > it") added a helper to set the panel panel orientation early but only
> > > > connected this for drm_bridge_connector, which constructs a panel bridge
> > > > with DRM_BRIDGE_ATTACH_NO_CONNECTOR and creates the connector itself.
> > > >
> > > > When the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is not specified and the
> > > > panel_bridge creates its own connector the orientation is not set unless
> > > > the panel does it in .get_modes which is too late and leads to a warning
> > > > splat from __drm_mode_object_add() because the device is already
> > > > registered.
> > > >
> > > > Call the necessary function to set add the orientation property when the
> > > > connector is created so that it is available before the device is
> > > > registered.
> > > 
> > > I have no huge objection to your patch and it looks OK to me. That
> > > being said, my understanding is that:
> > > 
> > > 1. DRM_BRIDGE_ATTACH_NO_CONNECTOR is "the future" and not using the
> > > flag is "deprecated".
> >
> > Correct.
> > Could we take a look at how much is required to move the relevant driver
> > to use DRM_BRIDGE_ATTACH_NO_CONNECTOR?
> >
> > If this is too much work now we may land this simple patch, but the
> > preference is to move all drivers to the new bridge handling and thus
> > asking display drivers to create the connector.

I fully agree with Doug and Sam here. Let's see if we can keep the yak
shaving minimal :-)

> > What display driver are we dealing with here?
> 
> This is dw-mipi-dsi-rockchip which uses the component path in
> dw-mipi-dsi (and, in fact, is the only driver using that mode of
> dw-mipi-dsi).
> 
> I'm not familiar enough with DRM to say whether it's easy to convert to
> DRM_BRIDGE_ATTACH_NO_CONNECTOR - should dw-mipi-dsi-rockchip be moving
> to use dw-mipi-dsi as a bridge driver or should dw_mipi_dsi_bind() have
> a drm_bridge_attach_flags argument?  But I'm happy to test patches if it
> looks easy to convert to you :-)

I'd go for the former (use dw_mipi_dsi_probe() and acquire the DSI
bridge with of_drm_find_bridge() instead of using the component
framework) if possible, but I don't know how intrusive that would be.

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2023-01-22 15:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-20 11:43 [PATCH] drm/bridge: panel: Set orientation on panel_bridge connector John Keeping
2023-01-20 21:44 ` Doug Anderson
2023-01-21  8:57   ` Sam Ravnborg
2023-01-21 17:58     ` John Keeping
2023-01-22 15:01       ` Laurent Pinchart [this message]
2023-01-23 12:16         ` John Keeping
2023-01-23 16:05           ` Laurent Pinchart
2023-02-03  0:45             ` Doug Anderson
2023-02-03  8:08               ` Neil Armstrong
2023-02-07  0:53               ` Doug Anderson

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=Y81Px74OUYt21nj4@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=andrzej.hajda@intel.com \
    --cc=dianders@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hsinyi@chromium.org \
    --cc=jernej.skrabec@gmail.com \
    --cc=john@metanate.com \
    --cc=jonas@kwiboo.se \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=rfoss@kernel.org \
    --cc=sam@ravnborg.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox