devicetree.vger.kernel.org archive mirror
 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 --]

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

Thread overview: 10+ 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
     [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 ` [PATCHv5 2/2] leds: tlc591xx: Driver " Andrew Lunn
2015-01-26 11:32   ` Tomi Valkeinen
2015-01-26 17:41     ` Andrew Lunn
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 17:10       ` Andrew Lunn
2015-01-27 11:11         ` Tomi Valkeinen [this message]
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 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).