linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: s.hauer@pengutronix.de (Sascha Hauer)
To: linux-arm-kernel@lists.infradead.org
Subject: 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
2013-07-13 11:12         ` Russell King - ARM Linux
2013-07-13 17:44           ` Sebastian Hesselbarth
2013-07-13 20:43             ` Sylwester Nawrocki
2013-07-13 21:02               ` Russell King - ARM Linux
2013-07-13 22:16                 ` Sylwester Nawrocki
2013-07-13 23:09                   ` Russell King - ARM Linux
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
2013-07-13 17:38         ` Russell King - ARM Linux
2013-07-15 20:23 ` Daniel Drake
2013-07-15 21:09   ` Sascha Hauer [this message]
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=linux-arm-kernel@lists.infradead.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).