From: Andrew Lunn <andrew@lunn.ch>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: cooloney@gmail.com, rpurdie@rpsys.net, "R,
Vignesh" <vigneshr@ti.com>,
linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
linux ARM <linux-arm-kernel@lists.infradead.org>,
kaloz@openwrt.org, Matthew.Fatheree@belkin.com,
Sekhar Nori <nsekhar@ti.com>
Subject: Re: [PATCHv3 0/2] Driver for TI tlc59116 16 Channel i2c LED driver
Date: Tue, 20 Jan 2015 14:26:13 +0100 [thread overview]
Message-ID: <20150120132613.GJ2938@lunn.ch> (raw)
In-Reply-To: <54BE258A.10808@ti.com>
> I'm not familiar with the LED/PWM frameworks, so I want to summarize our
> use case and how I guess this should be done:
>
> We use the TLC59108 to provide backlight to a LCD, but in addition to
> that, it is used as a GPIO expander (or GPO, as it cannot do input). In
> your earlier patch versions there were some 'gpio' leftovers. Does your
> board have such GPIO use also?
No, only LEDs.
> So my current thinking is that TLC591xx should be a LED driver (as it
> sounded to me that PWM is not quite suitable for it). On top of that, we
> need generic 'led-backlight' and 'led-gpio' drivers, each of which uses
> the given LED driver to do the hardware manipulation, and they expose a
> backlight device and gpio device, respectively.
That sounds sensible. led-backlight seems to be mostly implemented
already via the led trigger code. Adding a minimal backlight_ops does
not look too hard. You might also be able to do some cleanup of the
other led based backlight drivers.
led-gpio looks like more work, but i don't see why it should not be
possible. One thing i do need to check is that if the brightness is
set to 255 the output is not set to 255/256 on and you have a regular
glitch. For an LED that does not really matter, but for GPIO it would
not be good.
Andrew
WARNING: multiple messages have this Message-ID (diff)
From: andrew@lunn.ch (Andrew Lunn)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv3 0/2] Driver for TI tlc59116 16 Channel i2c LED driver
Date: Tue, 20 Jan 2015 14:26:13 +0100 [thread overview]
Message-ID: <20150120132613.GJ2938@lunn.ch> (raw)
In-Reply-To: <54BE258A.10808@ti.com>
> I'm not familiar with the LED/PWM frameworks, so I want to summarize our
> use case and how I guess this should be done:
>
> We use the TLC59108 to provide backlight to a LCD, but in addition to
> that, it is used as a GPIO expander (or GPO, as it cannot do input). In
> your earlier patch versions there were some 'gpio' leftovers. Does your
> board have such GPIO use also?
No, only LEDs.
> So my current thinking is that TLC591xx should be a LED driver (as it
> sounded to me that PWM is not quite suitable for it). On top of that, we
> need generic 'led-backlight' and 'led-gpio' drivers, each of which uses
> the given LED driver to do the hardware manipulation, and they expose a
> backlight device and gpio device, respectively.
That sounds sensible. led-backlight seems to be mostly implemented
already via the led trigger code. Adding a minimal backlight_ops does
not look too hard. You might also be able to do some cleanup of the
other led based backlight drivers.
led-gpio looks like more work, but i don't see why it should not be
possible. One thing i do need to check is that if the brightness is
set to 255 the output is not set to 255/256 on and you have a regular
glitch. For an LED that does not really matter, but for GPIO it would
not be good.
Andrew
next prev parent reply other threads:[~2015-01-20 13:28 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-14 23:15 [PATCHv3 0/2] Driver for TI tlc59116 16 Channel i2c LED driver Andrew Lunn
2015-01-14 23:15 ` Andrew Lunn
2015-01-14 23:15 ` [PATCHv3 1/2] leds: tlc59116: Document binding for the TI " Andrew Lunn
2015-01-14 23:15 ` Andrew Lunn
2015-01-14 23:15 ` [PATCHv3 2/2] leds: tlc59116: Driver " Andrew Lunn
2015-01-14 23:15 ` Andrew Lunn
2015-01-16 14:52 ` [PATCHv3 0/2] Driver for TI tlc59116 " Tomi Valkeinen
2015-01-16 14:52 ` Tomi Valkeinen
[not found] ` <54B9259C.3070403-l0cyMroinI0@public.gmane.org>
2015-01-16 15:55 ` Andrew Lunn
2015-01-16 15:55 ` Andrew Lunn
2015-01-16 17:50 ` R, Vignesh
2015-01-16 17:50 ` R, Vignesh
2015-01-16 19:10 ` Andrew Lunn
2015-01-16 19:10 ` Andrew Lunn
2015-01-16 19:17 ` Andrew Lunn
2015-01-16 19:17 ` Andrew Lunn
2015-01-20 9:53 ` Tomi Valkeinen
2015-01-20 9:53 ` Tomi Valkeinen
2015-01-20 13:26 ` Andrew Lunn [this message]
2015-01-20 13:26 ` Andrew Lunn
[not found] ` <20150120132613.GJ2938-g2DYL2Zd6BY@public.gmane.org>
2015-01-20 13:32 ` Tomi Valkeinen
2015-01-20 13:32 ` Tomi Valkeinen
2015-01-20 13:40 ` Andrew Lunn
2015-01-20 13:40 ` Andrew Lunn
2015-01-20 13:33 ` Geert Uytterhoeven
2015-01-20 13:33 ` Geert Uytterhoeven
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=20150120132613.GJ2938@lunn.ch \
--to=andrew@lunn.ch \
--cc=Matthew.Fatheree@belkin.com \
--cc=cooloney@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=kaloz@openwrt.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-leds@vger.kernel.org \
--cc=nsekhar@ti.com \
--cc=rpurdie@rpsys.net \
--cc=tomi.valkeinen@ti.com \
--cc=vigneshr@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.