Message-ID: <524589A3.50700@newsguy.com>
Date:	Fri, 27 Sep 2013 06:35:31 -0700
From:	Mike Dunn <mikedunn@...sguy.com>
To:	Thierry Reding <thierry.reding@...il.com>
CC:	Tomi Valkeinen <tomi.valkeinen@...com>,
	Richard Purdie <rpurdie@...ys.net>,
	Jingoo Han <jg1.han@...sung.com>,
	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <rob.herring@...xeda.com>,
	linux-pwm@...r.kernel.org, linux-fbdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	Robert Jarzmik <robert.jarzmik@...e.fr>,
	Marek Vasut <marex@...x.de>
Subject: Re: [PATCH] pwm-backlight: add support for device tree gpio control

On 09/26/2013 05:50 AM, Thierry Reding wrote:
> On Thu, Sep 26, 2013 at 03:26:13PM +0300, Tomi Valkeinen wrote:
>> On 26/09/13 15:02, Thierry Reding wrote:
>>> On Thu, Sep 26, 2013 at 01:13:18PM +0300, Tomi Valkeinen wrote:
>>>> On 11/09/13 14:40, Mike Dunn wrote:
>>>>> On 09/10/2013 10:21 AM, Thierry Reding wrote:
>>>>
>>>>>> Do you have a real setup that actually needs multiple GPIOs? Usually
>>>>>> such a setup requires some kind of timing or other additional constraint
>>>>>> which can't be represented by this simple binding.
>>>>>>
>>>>>> Looking at the Palm Treo code it seems like the reason why multiple
>>>>>> GPIOs are needed is because one is to enable the backlight, while the
>>>>>> other is in fact used to enable the LCD panel. 
>>>>>
>>>>>
>>>>> There are actually four GPIOs involved!  (There is an embarrasingly horrible
>>>>> hack in arch/arm/mach-pxa/palmtreo.c that handles the others.)  One is almost
>>>>> certainly simply backlight power.  The other three are probably LCD related.
>>>>
>>>> When you say "power", do you mean the gpio enables a regulator to feed
>>>> power to the backlight? If so, wouldn't that be a regulator, not gpio,
>>>> from the bl driver's point of view?
>>>>
>>>> Generally speaking, this same problem appears in many places, but for
>>>> some reason especially in display. I'm a bit hesitant in adding "free
>>>> form" gpio/regulator support for drivers, as, as Thierry pointed out,
>>>> there are often timing requirements, or sometimes the gpios are
>>>> inverted, or sometimes the gpio is, in fact, a reset gpio, where you'll
>>>> assert the gpio for a short moment only.
>>>
>>> I sent out another series a few days ago that somewhat obsoletes this
>>> patch. What it does is basically add a single enable GPIO that can be
>>> used to turn the backlight on and off. In a separate patch, support is
>>> added for a power regulator. The combination of both should be able to
>>> cover the majority of use-cases.
>>
>> But Mike's case required 4 GPIOs? Or can that be reduced to one gpio and
>> one regulator?
> 
> Well, at least for the backlight it only seemed to involve a single
> GPIO. The other three were probably related to LCD and therefore not
> really suitable for a backlight driver. Traditionally it has been that
> the backlight driver handled these things as well (via the callbacks
> installed by board setup code). While really they should be handled by a
> separate driver (for the LCD).


Yes, this is currently my best guess.  This is reverse-engineered and
unfortunately I'm not yet able to accurately describe my particular use-case.
Probably as wacky as anything you can imagine, Thierry :)

The gpio and regulator patches will probably suffice.  Thierry, can you please
point me to those patches?  I don't see them in your gitorious tree.  If they
were posted to linux-pwm, I missed them; sorry.

Thanks,
Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists