All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: cooloney@gmail.com, rpurdie@rpsys.net,
	Peter Ujfalusi <peter.ujfalusi@ti.com>,
	devicetree@vger.kernel.org, vigneshr@ti.com,
	Matthew.Fatheree@belkin.com, linux-leds@vger.kernel.org,
	kaloz@openwrt.org,
	linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCHv5 2/2] leds: tlc591xx: Driver for the TI 8/16 Channel i2c LED driver
Date: Tue, 27 Jan 2015 13:11:57 +0200	[thread overview]
Message-ID: <54C7727D.70000@ti.com> (raw)
In-Reply-To: <20150126171052.GC5015@lunn.ch>

[-- Attachment #1: Type: text/plain, Size: 2287 bytes --]

Hi,

On 26/01/15 19:10, Andrew Lunn wrote:
>> So... To me it's still slightly unclear when should one write a PWM
>> driver and when a LED driver. But I would say that as the TLC591xx
>> outputs a PWM signal, it should be a PWM driver. Then the different
>> users of this PWM signal could be made on top of that (LED, backlight, GPO).
>>
>> What would be the technical drawbacks with having the TLC591xx driver as
>> a PWM, instead of LED?
>  
> Hi Tomi
> 
> We have been through this once, but the big technical drawback is that
> this hardware cannot do what the Linux Kernel defines as PWM.
> 
> It cannot correctly implement the PMW call:
> 
> int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns);
> 
> This hardware has a fixed period, since it is clocked at 97-kHz.  So
> you cannot set the period. The duty is also somewhat restrictive, in
> that it only allows 1/256 increments of the 97Khz.

Surely other PWM devices also have restrictions in the period or duty cycle?

> This hardware does however perfectly fit the LED API:
> 
> enum led_brightness {
>         LED_OFF         = 0,
>         LED_HALF        = 127,
>         LED_FULL        = 255,
> };
> 
>         void            (*brightness_set)(struct led_classdev *led_cdev,
>                                           enum led_brightness brightness);
> 
> So we can model it perfectly as an LED driver, or badly as a PWM
> driver.

Maybe so, but what does it mean in practice? If it's implemented as a
PWM driver, and the existing leds-pwm driver is used for the led
functionality, shall we miss some brightness values? Is the
configuration more difficult? Or what?

So my point here is that it outputs a PWM signal, so it makes sense to
have it as a PWM driver. It has restricted configurability compared to
more versatile PWM hardware, but I so far don't see why that would be an
issue.

If it is a PWM driver, we get backlight support for free via the
existing pwm_bl driver, and LED support via leds-pwm. And there has been
a clear acceptance on GPO functionality with PWM outputs (in the Peter's
mail thread), whereas I would bet that a LED based GPO functionality
would encounter resistance, because that doesn't quite make sense.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: tomi.valkeinen@ti.com (Tomi Valkeinen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv5 2/2] leds: tlc591xx: Driver for the TI 8/16 Channel i2c LED driver
Date: Tue, 27 Jan 2015 13:11:57 +0200	[thread overview]
Message-ID: <54C7727D.70000@ti.com> (raw)
In-Reply-To: <20150126171052.GC5015@lunn.ch>

Hi,

On 26/01/15 19:10, Andrew Lunn wrote:
>> So... To me it's still slightly unclear when should one write a PWM
>> driver and when a LED driver. But I would say that as the TLC591xx
>> outputs a PWM signal, it should be a PWM driver. Then the different
>> users of this PWM signal could be made on top of that (LED, backlight, GPO).
>>
>> What would be the technical drawbacks with having the TLC591xx driver as
>> a PWM, instead of LED?
>  
> Hi Tomi
> 
> We have been through this once, but the big technical drawback is that
> this hardware cannot do what the Linux Kernel defines as PWM.
> 
> It cannot correctly implement the PMW call:
> 
> int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns);
> 
> This hardware has a fixed period, since it is clocked at 97-kHz.  So
> you cannot set the period. The duty is also somewhat restrictive, in
> that it only allows 1/256 increments of the 97Khz.

Surely other PWM devices also have restrictions in the period or duty cycle?

> This hardware does however perfectly fit the LED API:
> 
> enum led_brightness {
>         LED_OFF         = 0,
>         LED_HALF        = 127,
>         LED_FULL        = 255,
> };
> 
>         void            (*brightness_set)(struct led_classdev *led_cdev,
>                                           enum led_brightness brightness);
> 
> So we can model it perfectly as an LED driver, or badly as a PWM
> driver.

Maybe so, but what does it mean in practice? If it's implemented as a
PWM driver, and the existing leds-pwm driver is used for the led
functionality, shall we miss some brightness values? Is the
configuration more difficult? Or what?

So my point here is that it outputs a PWM signal, so it makes sense to
have it as a PWM driver. It has restricted configurability compared to
more versatile PWM hardware, but I so far don't see why that would be an
issue.

If it is a PWM driver, we get backlight support for free via the
existing pwm_bl driver, and LED support via leds-pwm. And there has been
a clear acceptance on GPO functionality with PWM outputs (in the Peter's
mail thread), whereas I would bet that a LED based GPO functionality
would encounter resistance, because that doesn't quite make sense.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150127/5a23a940/attachment.sig>

  reply	other threads:[~2015-01-27 11:12 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-21 22:29 [PATCHv5 0/2] Driver for TI tlc591xx 8/16 Channel i2c LED driver Andrew Lunn
2015-01-21 22:29 ` Andrew Lunn
     [not found] ` <1421879364-8573-1-git-send-email-andrew-g2DYL2Zd6BY@public.gmane.org>
2015-01-21 22:29   ` [PATCHv5 1/2] leds: tlc591xx: Document binding for the TI " Andrew Lunn
2015-01-21 22:29     ` Andrew Lunn
2015-01-21 22:29 ` [PATCHv5 2/2] leds: tlc591xx: Driver " Andrew Lunn
2015-01-21 22:29   ` Andrew Lunn
2015-01-26 11:32   ` Tomi Valkeinen
2015-01-26 11:32     ` Tomi Valkeinen
2015-01-26 17:41     ` Andrew Lunn
2015-01-26 17:41       ` Andrew Lunn
2015-01-27 11:17       ` Tomi Valkeinen
2015-01-27 11:17         ` Tomi Valkeinen
     [not found]   ` <1421879364-8573-3-git-send-email-andrew-g2DYL2Zd6BY@public.gmane.org>
2015-01-26 11:46     ` Tomi Valkeinen
2015-01-26 11:46       ` Tomi Valkeinen
2015-01-26 17:10       ` Andrew Lunn
2015-01-26 17:10         ` Andrew Lunn
2015-01-27 11:11         ` Tomi Valkeinen [this message]
2015-01-27 11:11           ` Tomi Valkeinen
2015-02-03  9:14           ` Peter Ujfalusi
2015-02-03  9:14             ` Peter Ujfalusi

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=54C7727D.70000@ti.com \
    --to=tomi.valkeinen@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=peter.ujfalusi@ti.com \
    --cc=rpurdie@rpsys.net \
    --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.