devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: devel@driverdev.osuosl.org, devicetree@vger.kernel.org,
	David Airlie <airlied@linux.ie>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	dri-devel@lists.freedesktop.org,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	kernel@pengutronix.de, Grant Likely <grant.likely@linaro.org>,
	Shawn Guo <shawn.guo@linaro.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v4 3/8] staging: imx-drm: Document updated imx-drm device tree bindings
Date: Thu, 27 Feb 2014 13:00:21 +0000	[thread overview]
Message-ID: <20140227130020.GJ21483@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <1393506385.4507.49.camel@paszta.hi.pengutronix.de>

On Thu, Feb 27, 2014 at 02:06:25PM +0100, Philipp Zabel wrote:
> For the i.MX6 display subsystem there is no clear single master device,
> and the physical configuration changes across the SoC family. The
> i.MX6Q/i.MX6D SoCs have two separate display controller devices IPU1 and
> IPU2, with two output ports each.

Not also forgetting that there's another scenario too: you may wish
to drive IPU1 and IPU2 as two completely separate display subsystems
in some hardware, but as a combined display subsystem in others.

Here's another scenario.  You may have these two IPUs on the SoC, but
there's only one display output.  You want to leave the second IPU
disabled, as you wouldn't want it to be probed or even exposed to
userland.

On the face of it, the top-level super-device node doesn't look very
hardware-y, but it actually is - it's about how a board uses the
hardware provided.  This is entirely in keeping with the spirit of DT,
which is to describe what hardware is present and how it's connected
together, whether it be at the chip or board level.

If this wasn't the case, we wouldn't even attempt to describe what devices
we have on which I2C buses - we'd just list the hardware on the board
without giving any information about how it's wired together.

This is no different - however, it doesn't have (and shouldn't) be
subsystem specific... but - and this is the challenge we then face - how
do you decide that on one board with a single zImage kernel, with both
DRM and fbdev built-in, whether to use the DRM interfaces or the fbdev
interfaces?  We could have both matching the same compatible string, but
we'd also need some way to tell each other that they're not allowed to
bind.

Before anyone argues against "it isn't hardware-y", stop and think.
What if I design a board with two Epson LCD controllers on board and
put a muxing arrangement on their output.  Is that one or two devices?
What if I want them to operate as one combined system?  What if I have
two different LCD controllers on a board.  How is this any different
from the two independent IPU hardware blocks integrated inside an iMX6
SoC with a muxing arrangement on their output?

It's very easy to look at a SoC and make the wrong decision...

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

  reply	other threads:[~2014-02-27 13:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-25 14:23 [RFC PATCH v4 0/8] imx-drm dt bindings Philipp Zabel
2014-02-25 14:23 ` [RFC PATCH v4 3/8] staging: imx-drm: Document updated imx-drm device tree bindings Philipp Zabel
2014-02-27 11:06   ` Tomi Valkeinen
2014-02-27 11:56     ` Russell King - ARM Linux
2014-02-27 13:16       ` Tomi Valkeinen
2014-02-27 13:43         ` Russell King - ARM Linux
2014-02-27 14:10           ` Tomi Valkeinen
2014-03-06 23:42             ` Laurent Pinchart
2014-02-27 13:06     ` Philipp Zabel
2014-02-27 13:00       ` Russell King - ARM Linux [this message]
2014-02-27 13:23         ` Rob Clark
2014-02-27 13:55         ` Tomi Valkeinen
2014-02-27 16:54           ` Philipp Zabel
2014-02-28  7:36             ` Tomi Valkeinen
2014-03-04 13:47               ` Philipp Zabel
2014-02-25 14:23 ` [RFC PATCH v4 4/8] staging: imx-drm: Document imx-hdmi " Philipp Zabel
2014-02-25 15:13   ` Fabio Estevam
2014-02-25 18:03     ` Philipp Zabel
2014-02-25 17:32   ` Fabio Estevam
     [not found] ` <1393338203-25051-1-git-send-email-p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2014-02-25 14:23   ` [RFC PATCH v4 1/8] staging: imx-drm-core: Use OF graph to find components and connections between encoder and crtcs Philipp Zabel
2014-02-25 14:23   ` [RFC PATCH v4 2/8] staging: imx-drm-core: use of_graph_parse_endpoint Philipp Zabel
2014-02-25 14:23   ` [RFC PATCH v4 5/8] ARM: dts: imx51: Add IPU ports and endpoints, move imx-drm node to dtsi Philipp Zabel
2014-02-25 14:23   ` [RFC PATCH v4 7/8] ARM: dts: imx6qdl: Add IPU DI " Philipp Zabel
2014-02-25 14:23 ` [RFC PATCH v4 6/8] ARM: dts: imx53: " Philipp Zabel
2014-02-25 14:23 ` [RFC PATCH v4 8/8] staging: imx-drm: Update TODO Philipp Zabel

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=20140227130020.GJ21483@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=airlied@linux.ie \
    --cc=devel@driverdev.osuosl.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=grant.likely@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=p.zabel@pengutronix.de \
    --cc=shawn.guo@linaro.org \
    --cc=tomi.valkeinen@ti.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).