From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>,
Thierry Reding <thierry.reding@avionic-design.de>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
linux-fbdev@vger.kernel.org,
Benjamin Gaignard <benjamin.gaignard@linaro.org>,
Tom Gall <tom.gall@linaro.org>,
Kyungmin Park <kyungmin.park@samsung.com>,
dri-devel@lists.freedesktop.org, Rob Clark <rob.clark@linaro.org>,
Ragesh Radhakrishnan <ragesh.r@linaro.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Vikas Sajjan <vikas.sajjan@linaro.org>,
Sumit Semwal <sumit.semwal@linaro.org>,
Sebastien Guiriec <s-guiriec@ti.com>,
linux-media@vger.kernel.org
Subject: Re: [RFC v2 0/5] Common Display Framework
Date: Mon, 17 Dec 2012 15:15:35 +0000 [thread overview]
Message-ID: <2584890.nIjxiaN4DG@avalon> (raw)
In-Reply-To: <20121126144708.3daec09e@pyramind.ukuu.org.uk>
Hi Alan,
On Monday 26 November 2012 14:47:08 Alan Cox wrote:
> On Sat, 24 Nov 2012 09:15:51 +0200 Tomi Valkeinen wrote:
> > On 2012-11-23 21:56, Thierry Reding wrote:
> > > On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote:
> > > [...]
> > >
> > >> Display entities are accessed by driver using notifiers. Any driver can
> > >> register a display entity notifier with the CDF, which then calls the
> > >> notifier when a matching display entity is registered.
>
> The framebuffer layer has some similar 'anyone can' type notifier
> behaviour and its not a good thing. That kind of "any one can" behaviour
> leads to some really horrible messes unless the connections and the
> locking are well defined IMHO.
I agree with you. I dislike the FBDEV notifier model, and I definitely don't
intend to duplicate it in the common display framework.
In the CDF model, when the display device driver registers a notifier, it
tells the core which device it wants to receive events for. This currently
takes the form of a struct device pointer, and the API will also support
device nodes in a future version (this is still work in progress). The goal is
to implement panel discovery in a way that is compatible with (and very
similar to) hotpluggable display discovery.
Thinking about it now, the API could be cleaner and less subject to abuse if
the notifier was registered for a given video port instead of a given
connected device. I'll add that to my TODO list.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2012-12-17 15:15 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-22 21:45 [RFC v2 0/5] Common Display Framework Laurent Pinchart
2012-11-22 21:45 ` [RFC v2 1/5] video: Add generic display entity core Laurent Pinchart
2012-11-27 13:07 ` Tomi Valkeinen
2012-11-22 21:45 ` [RFC v2 2/5] video: panel: Add DPI panel support Laurent Pinchart
2012-11-27 13:02 ` Tomi Valkeinen
2012-11-30 9:26 ` Philipp Zabel
2012-11-22 21:45 ` [RFC v2 3/5] video: display: Add MIPI DBI bus support Laurent Pinchart
2012-11-30 12:02 ` Tomi Valkeinen
2012-11-22 21:45 ` [RFC v2 4/5] video: panel: Add R61505 panel support Laurent Pinchart
2012-11-22 21:45 ` [RFC v2 5/5] video: panel: Add R61517 " Laurent Pinchart
2012-11-23 14:51 ` [RFC v2 0/5] Common Display Framework Tomi Valkeinen
2012-12-17 14:36 ` Laurent Pinchart
2012-12-17 15:29 ` Tomi Valkeinen
2012-12-17 23:18 ` Laurent Pinchart
2012-12-17 16:53 ` Jani Nikula
2012-12-17 22:19 ` Laurent Pinchart
2012-12-19 14:57 ` Jani Nikula
2012-12-19 15:07 ` Tomi Valkeinen
2012-12-24 17:31 ` Laurent Pinchart
2012-12-19 15:26 ` Rob Clark
2012-12-19 15:37 ` Tomi Valkeinen
2012-12-19 16:05 ` Rob Clark
2012-12-24 17:40 ` Laurent Pinchart
2012-12-24 17:35 ` Laurent Pinchart
2012-12-27 16:10 ` Rob Clark
2012-12-24 17:27 ` Laurent Pinchart
2012-12-27 16:04 ` Rob Clark
2012-12-27 19:19 ` Sascha Hauer
2012-11-23 19:56 ` Thierry Reding
2012-11-24 7:15 ` Tomi Valkeinen
2012-11-26 14:47 ` Alan Cox
2012-12-17 15:15 ` Laurent Pinchart [this message]
2012-11-26 7:53 ` Philipp Zabel
2012-12-17 14:58 ` Laurent Pinchart
2012-11-23 21:41 ` Sascha Hauer
2012-12-17 15:02 ` Laurent Pinchart
2012-12-18 5:04 ` Dave Airlie
2012-12-18 6:21 ` Rob Clark
2012-12-18 8:30 ` Daniel Vetter
2012-12-24 13:39 ` Laurent Pinchart
[not found] ` <CAAQKjZMt+13oooEw39mOM1rF2=ss4ih1s7iVS362di-50h4+Hg@mail.gmail.com>
2012-12-19 20:13 ` Stéphane Marchesin
2012-12-24 14:08 ` Laurent Pinchart
2012-12-18 10:59 ` Sylwester Nawrocki
2012-12-24 17:19 ` Laurent Pinchart
2012-12-19 20:05 ` Stéphane Marchesin
2012-12-24 13:37 ` Laurent Pinchart
2012-12-27 15:54 ` Rob Clark
2012-12-27 19:18 ` Sascha Hauer
2012-12-27 19:57 ` Rob Clark
2012-12-28 0:04 ` Sascha Hauer
2013-01-08 8:33 ` Laurent Pinchart
2013-01-08 8:25 ` Laurent Pinchart
2013-01-08 16:13 ` Rob Clark
2013-01-09 8:35 ` Rahul Sharma
2013-02-01 23:42 ` Laurent Pinchart
2013-02-02 10:08 ` Rob Clark
2012-12-18 10:39 ` Marcus Lorentzon
2012-12-24 17:09 ` Laurent Pinchart
2012-12-27 15:57 ` Rob Clark
2013-01-06 17:46 ` Daniel Vetter
2013-01-08 8:41 ` Laurent Pinchart
2012-12-24 13:24 ` Laurent Pinchart
[not found] ` <CAD025yS5rGMbiRBdDxv=YLP6_fsQndAkr+3t29_mNhcvow_SwA@mail.gmail.com>
[not found] ` <3133576.BkqAl7V01U@avalon>
[not found] ` <CAD025yQoCiNaKvaCwvUWhk_jV70CPhV35UzV9MR6HtE+1baCxg@mail.gmail.com>
2012-12-18 6:25 ` Vikas Sajjan
2012-12-21 10:00 ` Tomasz Figa
2012-12-24 14:12 ` Laurent Pinchart
2012-12-27 14:43 ` Tomasz Figa
2012-12-28 3:38 ` Vikas Sajjan
2013-01-08 8:18 ` Laurent Pinchart
2013-01-08 10:12 ` Marcus Lorentzon
2013-01-08 16:36 ` Tomasz Figa
2013-01-08 17:08 ` Marcus Lorentzon
2013-02-01 23:35 ` Laurent Pinchart
2013-02-04 10:05 ` Marcus Lorentzon
2013-02-06 9:52 ` Archit Taneja
2013-02-08 10:51 ` Tomi Valkeinen
2013-02-08 12:43 ` Marcus Lorentzon
2013-02-01 23:37 ` Laurent Pinchart
2012-12-24 12:59 ` 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=2584890.nIjxiaN4DG@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=benjamin.gaignard@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=kyungmin.park@samsung.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=maxime.ripard@free-electrons.com \
--cc=p.zabel@pengutronix.de \
--cc=ragesh.r@linaro.org \
--cc=rob.clark@linaro.org \
--cc=s-guiriec@ti.com \
--cc=sumit.semwal@linaro.org \
--cc=thierry.reding@avionic-design.de \
--cc=thomas.petazzoni@free-electrons.com \
--cc=tom.gall@linaro.org \
--cc=tomi.valkeinen@ti.com \
--cc=vikas.sajjan@linaro.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;
as well as URLs for NNTP newsgroup(s).