devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: devel@driverdev.osuosl.org, devicetree@vger.kernel.org,
	kernel@pengutronix.de, David Airlie <airlied@linux.ie>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	dri-devel@lists.freedesktop.org,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Philipp Zabel <p.zabel@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 16:10:41 +0200	[thread overview]
Message-ID: <530F4761.2020000@ti.com> (raw)
In-Reply-To: <20140227134348.GK21483@n2100.arm.linux.org.uk>


[-- Attachment #1.1: Type: text/plain, Size: 2120 bytes --]

On 27/02/14 15:43, Russell King - ARM Linux wrote:

> That may be - but the problem with CDF solving this problem is that it's
> wrong.  It's fixing what is in actual fact a *generic* problem in a much
> too specific way.  To put it another way, it's forcing everyone to fix
> the same problem in their own separate ways because no one is willing to
> take a step back and look at the larger picture.
> 
> We can see that because ASoC has exactly the same problem - it has to
> wait until all devices (DMA, CPU DAIs, codecs etc) are present before it
> can initialise, just like DRM.  Can you re-use the CDF solution for ASoC?
> No.  Can it be re-used elsewhere in non-display subsystems?  No.
> 
> Therefore, CDF is yet another implementation specific solution to a
> generic problem which can't be re-used.
> 
> Yes, I realise that CDF may do other stuff, but because of the above, it's
> a broken solution.

What? Because CDF didn't fix a particular subproblem for everyone, it's
broken solution? Or did I miss your point?

The main point of CDF is not solving the initialization issue. If that
was the point, it would've been Common Initialization Framework.

The main point of CDF is to allow us to have encoder and panel drivers
that can be used by all platforms, in complex display pipeline setups.
It just also has to have some solution for the initialization problem to
get things working.

In fact, Laurent's CDF version has a solution for init problem which, I
my memory serves me right, is very much similar to yours. It just wasn't
generic. I don't remember if Laurent had a specific master node defined,
but the LCD controller was very much like it. It would be trivial to
change it to use the component helpers.

My solution is different, because I don't like the idea of requiring all
the display components to be up and running to use any of the displays.
In fact, it's not a solution at all for me, as it would prevent displays
working on boards that do not have all the display components installed,
or if the user didn't compile all the drivers.

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[-- Attachment #2: Type: text/plain, Size: 169 bytes --]

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

  reply	other threads:[~2014-02-27 14:10 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 [this message]
2014-03-06 23:42             ` Laurent Pinchart
2014-02-27 13:06     ` Philipp Zabel
2014-02-27 13:00       ` Russell King - ARM Linux
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
2014-02-25 14:23 ` [RFC PATCH v4 6/8] ARM: dts: imx53: Add IPU DI ports and endpoints, move imx-drm node to dtsi Philipp Zabel
     [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 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=530F4761.2020000@ti.com \
    --to=tomi.valkeinen@ti.com \
    --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=laurent.pinchart@ideasonboard.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux@arm.linux.org.uk \
    --cc=p.zabel@pengutronix.de \
    --cc=shawn.guo@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).