All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Courbot <acourbot@nvidia.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Rob Herring <rob.herring@calxeda.com>,
	Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] of: Add simple panel device tree binding
Date: Mon, 6 Jan 2014 17:23:34 +0900	[thread overview]
Message-ID: <52CA6806.4070300@nvidia.com> (raw)
In-Reply-To: <52A873DA.9070608@ti.com>

On 12/11/2013 11:16 PM, Tomi Valkeinen wrote:
> * PGP Signed by an unknown key
>
> On 2013-11-22 20:41, Thierry Reding wrote:
>
>> +Example:
>> +
>> +	panel: panel {
>> +		compatible = "cptt,claa101wb01";
>> +		ddc-i2c-bus = <&panelddc>;
>> +
>> +		power-supply = <&vdd_pnl_reg>;
>> +		enable-gpios = <&gpio 90 0>;
>> +
>> +		backlight = <&backlight>;
>> +	};
>
> I'm somewhat torn with this, as I agree with Thierry that it's correct
> to have a panel database in the driver, but, on the other hand, it does
> seem impractical.
>
> In my experience, there are lots of panels out there, and each board I
> have has a different one. So, while just a gut feeling, we could end up
> with lots of panel, each used only on one board.
>
> With a quick thought, things would work fine if we just added the
> videomode data to the DT data, instead of a driver database, as Laurent
> suggested.
>
> However... I don't think the panels are usually as simple as that. With
> the panels I've worked with, the driver has to know things like:
>
> - Does the power supply need to be enabled before the enable gpio, and
> if so, how long before? And the same for power off.
>
> - Does the video stream need to be enabled before the enable gpio, and
> if so, how long before? And the same for power off.
>
> - Is the gpio enable, power down, or reset? If reset, what are the timings.
>
> Where will those be defined? This goes back to the power sequence stuff
> again... (Was the power sequences series forgotten?)

Sorry for the very late reply - power sequences are forgotten for now, 
but I don't mind reviving them if a clear use-case emerges. The main 
point of power seqs (at least in my mind) was to be able to define them 
in the DT to avoid things like the panel DB you mention. This idea has 
been dismissed for good reasons, and anyway in the case of the panel it 
is clear that this is not what we want to do.

Now if we make a power sequences framework without DT support, we will 
end up with something that would still require a panel database, and can 
anyway be expressed by functions. The gain would be automated 
error-handling, and reduced footprint for power sequences. Not sure 
that's enough to justify resurrecting the power seqs.

Alex.

      reply	other threads:[~2014-01-06  8:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-22 18:41 [PATCH] of: Add simple panel device tree binding Thierry Reding
2013-11-26  1:54 ` Laurent Pinchart
2013-11-26  8:59   ` Thierry Reding
2013-12-04 23:45     ` Laurent Pinchart
2013-12-06 13:58       ` Thierry Reding
     [not found]         ` <20131206135759.GD30960-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
2013-12-06 14:54           ` Sascha Hauer
     [not found] ` <1385145714-3022-1-git-send-email-treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-22 20:05   ` Rob Herring
2013-11-26  2:01   ` Daniel Kurtz
     [not found]     ` <CAGS+omB5RKRUod_gDrDGRTi3B-BsX54dD1hHeT32gdPSjw9Bkg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-11-26  9:11       ` Thierry Reding
2013-12-11 14:16   ` Tomi Valkeinen
2014-01-06  8:23     ` Alex Courbot [this message]

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=52CA6806.4070300@nvidia.com \
    --to=acourbot@nvidia.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=rob.herring@calxeda.com \
    --cc=thierry.reding@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.