From: Thierry Reding <thierry.reding@gmail.com>
To: Mike Dunn <mikedunn@newsguy.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>,
Richard Purdie <rpurdie@rpsys.net>,
Jingoo Han <jg1.han@samsung.com>,
Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
Grant Likely <grant.likely@linaro.org>,
Rob Herring <rob.herring@calxeda.com>,
linux-pwm@vger.kernel.org, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Robert Jarzmik <robert.jarzmik@free.fr>,
Marek Vasut <marex@denx.de>
Subject: Re: [PATCH] pwm-backlight: add support for device tree gpio control
Date: Mon, 11 Nov 2013 09:39:57 +0000 [thread overview]
Message-ID: <20131111093956.GI3884@ulmo.nvidia.com> (raw)
In-Reply-To: <524589A3.50700@newsguy.com>
[-- Attachment #1: Type: text/plain, Size: 3427 bytes --]
On Fri, Sep 27, 2013 at 06:35:31AM -0700, Mike Dunn wrote:
> 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.
I've stumbled across this email and it's not marked as answered, so here
goes: these patches will be part of my pull request for 3.13. They
should now be in my tree, although that's now moved to kernel.org. You
can find it here:
https://git.kernel.org/cgit/linux/kernel/git/thierry.reding/linux-pwm.git
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
prev parent reply other threads:[~2013-11-11 9:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-03 19:26 [PATCH] pwm-backlight: add support for device tree gpio control Mike Dunn
2013-09-10 17:21 ` Thierry Reding
2013-09-11 11:40 ` Mike Dunn
[not found] ` <523056A6.5060000-kFrNdAxtuftBDgjK7y7TUQ@public.gmane.org>
2013-09-26 10:13 ` Tomi Valkeinen
2013-09-26 12:02 ` Thierry Reding
2013-09-26 12:26 ` Tomi Valkeinen
2013-09-26 12:50 ` Thierry Reding
2013-09-27 6:55 ` Tomi Valkeinen
2013-09-27 13:35 ` Mike Dunn
2013-11-11 9:39 ` Thierry Reding [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=20131111093956.GI3884@ulmo.nvidia.com \
--to=thierry.reding@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=grant.likely@linaro.org \
--cc=jg1.han@samsung.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=marex@denx.de \
--cc=mikedunn@newsguy.com \
--cc=plagnioj@jcrosoft.com \
--cc=rob.herring@calxeda.com \
--cc=robert.jarzmik@free.fr \
--cc=rpurdie@rpsys.net \
--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).