From: Sascha Hauer <s.hauer@pengutronix.de>
To: Daniel Drake <dsd@laptop.org>
Cc: "Jean-François Moine" <moinejf@free.fr>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
dri-devel@lists.freedesktop.org,
"Russell King" <rmk@arm.linux.org.uk>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
"Sebastian Hesselbarth" <sebastian.hesselbarth@gmail.com>
Subject: Re: DT binding review for Armada display subsystem
Date: Mon, 15 Jul 2013 23:09:00 +0200 [thread overview]
Message-ID: <20130715210900.GT14452@pengutronix.de> (raw)
In-Reply-To: <CAMLZHHRvWFrxxjr0sF0NRqvz+K1wB9Mb_OGG-8tx36A2rk-SNQ@mail.gmail.com>
On Mon, Jul 15, 2013 at 02:23:30PM -0600, Daniel Drake wrote:
> On Fri, Jul 12, 2013 at 10:44 AM, Daniel Drake <dsd@laptop.org> wrote:
> > Based on the outcomes of the "Best practice device tree design for display
> > subsystems" discussion I have drafted a DT binding. Comments much appreciated.
> >
> > At a high level, it uses a "super node" as something for the driver to bind
> > to, needed because there is no clear one device that controls all the
> > others, and also to distinguish between the Armada 510 possible use cases
> > of having one video card with two outputs, or two independent video cards.
> > It uses node-to-node linking beyond that point, V4L2 style.
>
> As this hasn't been shot down very far, I've started to implement the
> driver side of this binding. I have already run into a couple of
> little problems.
>
> First, interrupts. In the dt binding, each "lcd controller" node
> defines which interrupt it listens to, and in the armada 510 case
> there are indeed 2 interrupts (47 and 46, one for each LCD
> controller). And remember that the drm driver itself binds to the
> super-node.
>
> Looking at drm_irq_install(), it looks like DRM only supports 1
> interrupt line per drm_device.
You don't have to call drm_irq_install(). Both the exynos and i.MX
driver do without it and at least the i.MX driver uses multiple irqs per
drm_device.
>
> Secondly, devm. I understand from the "best practices" thread that we
> want to have exactly one platform_device which corresponds to the
> "super node", and all of the individual display controller components
> will be represented by DT nodes but *without* their own
> platform_device.
A super node approach doesn't mean that there's only one platform
device. You can still have a platform device for each component. The
super node should rather be seen as a node which contains phandles
to the different components..
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2013-07-15 21:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-12 16:44 DT binding review for Armada display subsystem Daniel Drake
2013-07-12 18:39 ` Jean-Francois Moine
2013-07-12 19:00 ` Daniel Drake
2013-07-13 8:35 ` Jean-Francois Moine
2013-07-13 10:56 ` Sylwester Nawrocki
[not found] ` <51E13272.5040903-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-07-13 11:12 ` Russell King - ARM Linux
[not found] ` <20130713111239.GM24642-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2013-07-13 17:44 ` Sebastian Hesselbarth
[not found] ` <51E1921A.3070207-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-07-13 20:43 ` Sylwester Nawrocki
[not found] ` <51E1BBF1.1020009-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-07-13 21:02 ` Russell King - ARM Linux
[not found] ` <20130713210236.GP24642-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2013-07-13 22:16 ` Sylwester Nawrocki
[not found] ` <51E1D1DA.8080102-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-07-13 23:09 ` Russell King - ARM Linux
[not found] ` <20130713230955.GQ24642-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2013-07-15 20:35 ` Tomasz Figa
2013-07-13 20:51 ` Russell King - ARM Linux
2013-07-13 14:25 ` Daniel Drake
2013-07-13 17:36 ` Sebastian Hesselbarth
[not found] ` <CAMLZHHSrX2T+pU3RosmjS3EggV3mX_J8D2OJD52sww_n6Y7B+A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-07-13 17:38 ` Russell King - ARM Linux
[not found] ` <20130712164428.AC3D2FAAE9-2+9YHz4BXxlLDiiyqF6/jw@public.gmane.org>
2013-07-15 20:23 ` Daniel Drake
2013-07-15 21:09 ` Sascha Hauer [this message]
[not found] ` <20130715210900.GT14452-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2013-07-17 17:50 ` Daniel Drake
2013-07-17 18:30 ` Jean-Francois Moine
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=20130715210900.GT14452@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=dsd@laptop.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=moinejf@free.fr \
--cc=rmk@arm.linux.org.uk \
--cc=sebastian.hesselbarth@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 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).