All of lore.kernel.org
 help / color / mirror / Atom feed
From: "R, Vignesh" <vigneshr@ti.com>
To: Andrew Lunn <andrew@lunn.ch>, Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: cooloney@gmail.com, rpurdie@rpsys.net,
	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: Fri, 16 Jan 2015 23:20:25 +0530	[thread overview]
Message-ID: <54B94F61.2060706@ti.com> (raw)
In-Reply-To: <20150116155553.GC17658@lunn.ch>



On 1/16/2015 9:25 PM, Andrew Lunn wrote:
> On Fri, Jan 16, 2015 at 04:52:12PM +0200, Tomi Valkeinen wrote:
>> Hi,
>>
>> On 15/01/15 01:15, Andrew Lunn wrote:
>>> This patchset is a driver for the TI tlc59116 16 Channel i2c LED
>>> driver. This driver is used on the Belkin WRT1900AC access point and
>>> the C code is derived from code Belkin contributed to OpenWRT.
>>> However it has been extensively re-written, and a device tree binding
>>> added to replace platform data.
>>
>> We have a TLC59108 on one of our boards, and with a quick glance it
>> looks about the same as TLC59116, except the amount of outputs. Vignesh
>> wrote a driver for it and was about to send it for review.
>>
>> However, Vignesh implemented it as a PWM driver. We use it for LCD
>> backlight (via pwm-backlight).
>>
>> I'm not very familiar with LED and PWM drivers, but doesn't implementing
>> this as a LED driver prevent us from using it as a backlight? Whereas it
>> looks like PWM can be used as a led via pwm-leds (I think).
>>
> Hi Tomi
> 
> I've no idea about backlighting....
> 
> But the driver does fully implement brightness. So on my board:
> 
> echo 128 > /sys/class/leds/wrt1900ac\:white\:wan/brightness
> 
> will set that LED to 128/256 brightness. You have 255 steps of
> brightness.
> 
> The reason i did not model it as a PWM, is that it cannot fulfil the
> PWM interface. The configure interface is:
> 
> int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns);
> 
> However with this device, you have no control over the period. It is
> fixed, from a 97-kHz clock. All you can change is the duty as a ratio
> between 0 and 256. There is the group PWM, where you do have control
> over the period. But as the name implies, this PWM is shared for all
> outputs, which is not what the PWM interface expects, it wants to be
> able to control them individually. Also, it only has a range of 24 Hz
> to 10.73 s. Again, i have no idea about backlights, but i suspect if
> it is driven at 24Hz, i'm going to get a headache. 
> 
> The LED interface can be fully implemented. So that is what i have
> done.

I understand that period of TLC chip cannot be changed and hence cannot
fully implement PWM interface. But, suppose I want to control brightness
of an LCD screen, with your current design, my LCD driver can never can do
something like:
	pwm_get(chip);
	pwm_update_brightness();
	pwm_remove();
I will always have to rely on sysfs entries to control brightness.
 
If the driver is implemented as pwm-backlight, then brightness can
be controlled both via sysfs entries and pwm-core callbacks(in kernel).

> 
> So i think modeling this as an LED driver is correct, and maybe you
> need to implemented an led_bl.c driver?
> 

But, as far as I understand, leds-pwm.c does almost similar function.  

Regards
Vignesh R

WARNING: multiple messages have this Message-ID (diff)
From: vigneshr@ti.com (R, Vignesh)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv3 0/2] Driver for TI tlc59116 16 Channel i2c LED driver
Date: Fri, 16 Jan 2015 23:20:25 +0530	[thread overview]
Message-ID: <54B94F61.2060706@ti.com> (raw)
In-Reply-To: <20150116155553.GC17658@lunn.ch>



On 1/16/2015 9:25 PM, Andrew Lunn wrote:
> On Fri, Jan 16, 2015 at 04:52:12PM +0200, Tomi Valkeinen wrote:
>> Hi,
>>
>> On 15/01/15 01:15, Andrew Lunn wrote:
>>> This patchset is a driver for the TI tlc59116 16 Channel i2c LED
>>> driver. This driver is used on the Belkin WRT1900AC access point and
>>> the C code is derived from code Belkin contributed to OpenWRT.
>>> However it has been extensively re-written, and a device tree binding
>>> added to replace platform data.
>>
>> We have a TLC59108 on one of our boards, and with a quick glance it
>> looks about the same as TLC59116, except the amount of outputs. Vignesh
>> wrote a driver for it and was about to send it for review.
>>
>> However, Vignesh implemented it as a PWM driver. We use it for LCD
>> backlight (via pwm-backlight).
>>
>> I'm not very familiar with LED and PWM drivers, but doesn't implementing
>> this as a LED driver prevent us from using it as a backlight? Whereas it
>> looks like PWM can be used as a led via pwm-leds (I think).
>>
> Hi Tomi
> 
> I've no idea about backlighting....
> 
> But the driver does fully implement brightness. So on my board:
> 
> echo 128 > /sys/class/leds/wrt1900ac\:white\:wan/brightness
> 
> will set that LED to 128/256 brightness. You have 255 steps of
> brightness.
> 
> The reason i did not model it as a PWM, is that it cannot fulfil the
> PWM interface. The configure interface is:
> 
> int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns);
> 
> However with this device, you have no control over the period. It is
> fixed, from a 97-kHz clock. All you can change is the duty as a ratio
> between 0 and 256. There is the group PWM, where you do have control
> over the period. But as the name implies, this PWM is shared for all
> outputs, which is not what the PWM interface expects, it wants to be
> able to control them individually. Also, it only has a range of 24 Hz
> to 10.73 s. Again, i have no idea about backlights, but i suspect if
> it is driven at 24Hz, i'm going to get a headache. 
> 
> The LED interface can be fully implemented. So that is what i have
> done.

I understand that period of TLC chip cannot be changed and hence cannot
fully implement PWM interface. But, suppose I want to control brightness
of an LCD screen, with your current design, my LCD driver can never can do
something like:
	pwm_get(chip);
	pwm_update_brightness();
	pwm_remove();
I will always have to rely on sysfs entries to control brightness.
 
If the driver is implemented as pwm-backlight, then brightness can
be controlled both via sysfs entries and pwm-core callbacks(in kernel).

> 
> So i think modeling this as an LED driver is correct, and maybe you
> need to implemented an led_bl.c driver?
> 

But, as far as I understand, leds-pwm.c does almost similar function.  

Regards
Vignesh R

  reply	other threads:[~2015-01-16 17:51 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 [this message]
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
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=54B94F61.2060706@ti.com \
    --to=vigneshr@ti.com \
    --cc=Matthew.Fatheree@belkin.com \
    --cc=andrew@lunn.ch \
    --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 \
    /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.