All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

WARNING: multiple messages have this Message-ID (diff)
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 10:39:57 +0100	[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 --]

  reply	other threads:[~2013-11-11  9:39 UTC|newest]

Thread overview: 26+ 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-03 19:26 ` Mike Dunn
2013-09-10 17:21 ` Thierry Reding
2013-09-10 17:21   ` Thierry Reding
2013-09-11 11:40   ` Mike Dunn
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 10:13         ` Tomi Valkeinen
2013-09-26 10:13         ` Tomi Valkeinen
2013-09-26 10:13         ` Tomi Valkeinen
2013-09-26 12:02         ` Thierry Reding
2013-09-26 12:02           ` Thierry Reding
2013-09-26 12:26           ` Tomi Valkeinen
2013-09-26 12:26             ` Tomi Valkeinen
2013-09-26 12:26             ` Tomi Valkeinen
2013-09-26 12:26             ` Tomi Valkeinen
2013-09-26 12:50             ` Thierry Reding
2013-09-26 12:50               ` Thierry Reding
2013-09-27  6:55               ` Tomi Valkeinen
2013-09-27  6:55                 ` Tomi Valkeinen
2013-09-27  6:55                 ` Tomi Valkeinen
2013-09-27 13:35               ` Mike Dunn
2013-09-27 13:35                 ` Mike Dunn
2013-09-27 13:35                 ` Mike Dunn
2013-11-11  9:39                 ` Thierry Reding [this message]
2013-11-11  9:39                   ` Thierry Reding

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 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.