All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Gatliff <bgat@billgatliff.com>
To: David Brownell <david-b@pacbell.net>
Cc: Grant Likely <grant.likely@secretlab.ca>,
	linux-embedded@vger.kernel.org,
	Mike Frysinger <vapier.adi@gmail.com>
Subject: Re: [PATCH 0/6] Generic PWM API implementation
Date: Tue, 17 Nov 2009 09:54:14 -0600	[thread overview]
Message-ID: <4B02C726.6070607@billgatliff.com> (raw)
In-Reply-To: <200911170027.38664.david-b@pacbell.net>

David Brownell wrote:
> On Friday 13 November 2009, Grant Likely wrote:
>   
>> I'm concerned about the approach taken here.  As I understand it, the
>> PWM signals are very similar to GPIOs in that each PWM device controls
>> an external signal line, just like GPIO lines.
>>     
>
> PWM is not GPIO, and doesn't fit into a GPIO framework.
>
> Since *everything* boils down to one or more signal lines,
> your argument leads directly to Linux having no native
> hardware interface except GPIOs.  Not ... practical. ;)
>   

Wait.  Isn't that what Ubicom's chips do?  :)


> If you want to combine PWM with something else ... timers would
> be a better target.  They're both fundamentally about periodic
> phenomena.  And quite a lot of timers support PWM output modes...
>
> (A generic interface to hardware timers is lacking, too.)
>   

True, and I have code (not yet published) to support a couple of
timer/counter peripherals under the PWM interface.  So for that
functionality at least, I don't think a more generic or standalone API
is necessary.

I don't know how to define a generic interface for the counter a.k.a.
"input capture" behavior of such devices, though.  Still an unsolved
problem, but I don't think it will be a part of the PWM API.  It's a
different metaphor.


> GPIOs, on the other hand, are packaged for manual bit
> twiddling.  While it's possible to create low-speed
> implementations of serial protocols using GPIOs (like
> 2-wire/I2C, one-wire, and various SPI variants), those
> are explicitly the high-overhead (and low performance)
> substitutes, to be used only when native hardware isn't
> available (or is broken etc).
>   

And when using GPIO to generate I2C or SPI signals, you don't do it
through the GPIO interface--- you do it through the I2C or SPI
interface, and a driver behind that API talks to the GPIO API.... or to
a different driver if you change your mind.  Same idea for the PWM API.


-- 
Bill Gatliff
bgat@billgatliff.com


  reply	other threads:[~2009-11-17 15:54 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-15 18:14 [PATCH 0/6] Generic PWM API implementation Bill Gatliff
2008-10-15 18:14 ` [PATCH 1/6] [PWM] " Bill Gatliff
2008-10-17 15:59   ` Mike Frysinger
2008-11-04 20:16     ` Bill Gatliff
2008-11-04 20:51       ` Mike Frysinger
2008-11-04 23:55       ` David Brownell
2008-11-05  0:17         ` Mike Frysinger
2008-11-05  2:59           ` Bill Gatliff
2008-11-05  5:08           ` David Brownell
2008-11-05  2:56         ` Bill Gatliff
2008-10-15 18:14 ` [PATCH 2/6] [PWM] Changes to existing include/linux/pwm.h to adapt to generic PWM API Bill Gatliff
2008-10-15 18:14 ` [PATCH 3/6] [PWM] Documentation Bill Gatliff
2008-10-15 18:14 ` [PATCH 4/6] [PWM] Driver for Atmel PWMC peripheral Bill Gatliff
2008-10-15 18:14 ` [PATCH 5/6] [PWM] Install new Atmel PWMC driver in Kconfig, expunge old one Bill Gatliff
2008-10-15 18:14 ` [PATCH 6/6] [PWM] New LED driver and trigger that use PWM API Bill Gatliff
2009-11-13 19:08 ` [PATCH 0/6] Generic PWM API implementation Grant Likely
2009-11-14  4:22   ` Mike Frysinger
2009-11-14  7:55     ` Grant Likely
2009-11-17  7:47       ` David Brownell
2009-11-17 15:48         ` Bill Gatliff
2009-11-17 16:53           ` David Brownell
2009-11-20 22:51             ` Grant Likely
2009-11-20 22:14         ` Grant Likely
2009-11-23 14:12           ` Bill Gatliff
2009-11-23 17:39             ` Grant Likely
2009-11-23 20:51               ` Albrecht Dreß
2009-11-28 21:38               ` David Brownell
2009-11-28 21:59               ` David Brownell
2009-11-17 15:45       ` Bill Gatliff
2009-11-17  8:27   ` David Brownell
2009-11-17 15:54     ` Bill Gatliff [this message]
2009-11-20 22:21     ` Grant Likely
2009-11-23 14:13       ` Bill Gatliff
2009-11-23 17:40         ` Grant Likely
2009-11-23 15:29       ` Mark Brown
2009-11-23 17:44         ` Grant Likely
2009-11-23 18:09           ` Mark Brown
2009-11-28 21:54             ` David Brownell
2009-11-17 15:39   ` Bill Gatliff
2009-11-20 22:49     ` Grant Likely
2009-11-28 21:28       ` David Brownell

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=4B02C726.6070607@billgatliff.com \
    --to=bgat@billgatliff.com \
    --cc=david-b@pacbell.net \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-embedded@vger.kernel.org \
    --cc=vapier.adi@gmail.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.