devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 |

  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).