From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>,
Thierry Reding <thierry.reding@gmail.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [RFC PATCH 1/3] drm/panel: Support panel detection
Date: Mon, 30 Apr 2018 18:34:43 +0200 [thread overview]
Message-ID: <20180430183443.6cdaf009@bbrezillon> (raw)
In-Reply-To: <20180430160847.GT12521@phenom.ffwll.local>
Hi Daniel,
On Mon, 30 Apr 2018 18:08:47 +0200
Daniel Vetter <daniel@ffwll.ch> wrote:
> On Mon, Apr 30, 2018 at 04:43:21PM +0200, Boris Brezillon wrote:
> > Some panels might be connected through extension boards and might not
> > be available when the system boots. Extend the panel interface to
> > support panel detection.
> >
> > An optional ->detect() hook is added and, if implemented, will be called
> > every time the panel user wants to know if the panel is connected or
> > disconnected.
> >
> > We also add a ->polled field which should encode the type of polling the
> > DRM core should do (DRM_CONNECTOR_POLL_HPD, DRM_CONNECTOR_POLL_CONNECT
> > and DRM_CONNECTOR_POLL_DISCONNECT flags).
> >
> > Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
>
> Hm, not sure panel detection makes much sense, the entire idea behind
> drm_panel is to hard-code a fixed/built-in panel. The only thing panels
> may report through the connection status is whether the lid is closed or
> not. Yes we should probably document that somewhere.
>
> If you have a panel-that-can-be-hotplugged a drm_bridge that implemens the
> drm_connector is probably the way to go.
That does not really work for the rpi panel case because we use an I2C
message to detect the presence of the panel. So, unless we decide to
attach the I2C client to the bridge device instead of attaching it to
the panel that's not really possible, and I'm not sure doing that is a
good thing either.
I guess the only alternative to solve the issue I'm trying to solve is
drm_bridge hotplug, so that we allow the DRM device to be registered
even if not all of its leaf nodes (i.e. bridges and connectors) are
ready to be used.
>
> > ---
> > include/drm/drm_panel.h | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> > index 14ac240a1f64..718cc1f746ab 100644
> > --- a/include/drm/drm_panel.h
> > +++ b/include/drm/drm_panel.h
> > @@ -24,6 +24,7 @@
> > #ifndef __DRM_PANEL_H__
> > #define __DRM_PANEL_H__
> >
> > +#include <drm/drm_connector.h>
> > #include <linux/errno.h>
> > #include <linux/list.h>
> >
> > @@ -68,6 +69,7 @@ struct display_timing;
> > * the panel. This is the job of the .unprepare() function.
> > */
> > struct drm_panel_funcs {
> > + int (*detect)(struct drm_panel *panel);
>
> Kerneldoc for this please. Would also be really good to switch this struct
> of function pointers over to the in-line style, and put the paragraphs
> relevant for a given callback into it's dedicated comment.
Not useful anymore since the idea appeared to be bad ;-).
Thanks for the quick feedback.
Boris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-04-30 16:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-30 14:43 [RFC PATCH 0/3] drm/panel: Support panel detection Boris Brezillon
2018-04-30 14:43 ` [RFC PATCH 1/3] " Boris Brezillon
2018-04-30 16:08 ` Daniel Vetter
2018-04-30 16:34 ` Boris Brezillon [this message]
2018-04-30 14:43 ` [RFC PATCH 2/3] drm/bridge: panel: Make use of the panel detection infrastructure Boris Brezillon
2018-04-30 14:43 ` [RFC PATCH 3/3] drm/panel: rpi-touchscreen: Implement ->detect() Boris Brezillon
2018-04-30 17:22 ` [RFC PATCH 0/3] drm/panel: Support panel detection Eric Anholt
2018-04-30 17:43 ` Boris Brezillon
2018-04-30 19:48 ` Daniel Vetter
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=20180430183443.6cdaf009@bbrezillon \
--to=boris.brezillon@bootlin.com \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=thierry.reding@gmail.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.