On Friday 20 November 2009, Grant Likely wrote:
I don't think that's true, but I'm approaching it from the viewpoint
of managing pins; not the usage API. ie. the difference between
gpiolib (management) and the gpio api (usage).
Don't follow. The gpiolib code is unrelated to pin managment.
On Monday 23 November 2009, Grant Likely wrote:
*however* I do agree that it is the responsibility of platform code to
set up chip-internal pin muxing and routing.
Fo over 95% of systems, I'd agree -- given that platform code
includes the arch/.../mach-X/board-Y.c files. It's not realistic
to
On Monday 23 November 2009, Mark Brown wrote:
Judging from some of the other messages in the thread I suspect you're
thinking of a much closer mapping between PWM and GPIO pins - many SoCs
do have distinct PWM controllers that aren't terribly tied to a GPIO
pin.
Sometimes they can be coupled
On Monday 23 November 2009, Grant Likely wrote:
I take issue
with all the common code behind the API to make it work and to allow
GPIOs or PWMs to be registered at runtime. The overlap is the code
and behaviour used to register pins and to obtain a reference to a
pin.
Grant Likely wrote:
I'm talking about discrete controllable entities.
At the extreme, I see discrete, single-pin GPIO as being a degenerate
case of PWM: only 0% or 100% duty cycle e.g. one-bit granularity, a
single output, and no dependencies with any other channels or pins.
But the
On Fri, Nov 20, 2009 at 03:21:31PM -0700, Grant Likely wrote:
On Tue, Nov 17, 2009 at 1:27 AM, David Brownell davi...@pacbell.net wrote:
Since *everything* boils down to one or more signal lines,
your argument leads directly to Linux having no native
hardware interface except GPIOs. ?Not
On Mon, Nov 23, 2009 at 7:12 AM, Bill Gatliff b...@billgatliff.com wrote:
Grant Likely wrote:
I'm talking about discrete controllable entities.
At the extreme, I see discrete, single-pin GPIO as being a degenerate
case of PWM: only 0% or 100% duty cycle e.g. one-bit granularity, a
single
On Mon, Nov 23, 2009 at 7:13 AM, Bill Gatliff b...@billgatliff.com wrote:
Grant Likely wrote:
But that *isn't* the primary purpose of the GPIO subsystem. All that
stuff is layered on top of the GPIO pin management code and doesn't
really play into this debate.
I don't understand you. You
On Mon, Nov 23, 2009 at 8:29 AM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Fri, Nov 20, 2009 at 03:21:31PM -0700, Grant Likely wrote:
On Tue, Nov 17, 2009 at 1:27 AM, David Brownell davi...@pacbell.net wrote:
Since *everything* boils down to one or more signal lines,
your
On Mon, Nov 23, 2009 at 10:44:25AM -0700, Grant Likely wrote:
Right, pin-mux is a different problem. But there are also devices
that implement both PWM and GPIO functionality in the same IP block.
That's not the general case, though - most of the SoCs seem to have PWM
as a separate IP block.
Am 23.11.09 18:39 schrieb(en) Grant Likely:
There is no overlap here (except for the degenerate case of using a PWM as an
output only GPIO... which is useful. Board designers do crazy things).
But there may be cases where a device pin is used as GPIO *and* as pwm output. Think of a relay
On Tue, Nov 17, 2009 at 1:27 AM, David Brownell davi...@pacbell.net 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
On Tue, Nov 17, 2009 at 8:39 AM, Bill Gatliff b...@billgatliff.com wrote:
Grant Likely wrote:
Hi Bill
On Wed, Oct 15, 2008 at 11:14 AM, Bill Gatliff b...@billgatliff.com wrote:
This series implements a Generic PWM Device API, including reference
implementations for the Atmel PWMC device, an
On Tue, Nov 17, 2009 at 9:53 AM, David Brownell davi...@pacbell.net wrote:
On Tuesday 17 November 2009, Bill Gatliff wrote:
David Brownell wrote:
It'd be purely for pinmux.
Ugh. That would be a tough interface to design.
True. That's part of why I object to wanting to combine
it
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.
Grant Likely wrote:
Common code is a big gain in and of itself.
I completely agree! Which is why I used the GPIO API in my PWM
pseudo-device, along with an hrtimer.
What I would like to see is the PWM functions added to the GPIO API.
GPIO drivers can then either implement them or not. If a
David Brownell wrote:
It'd be purely for pinmux.
Ugh. That would be a tough interface to design. It makes me think of
an old-time telephone switchboard, with an undefined number of wires and
an equally-undefined number of plugs to insert them into.
Good morning, Mabel! Give me SCL1 on
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
On Tuesday 17 November 2009, Bill Gatliff wrote:
David Brownell wrote:
It'd be purely for pinmux.
Ugh. That would be a tough interface to design.
True. That's part of why I object to wanting to combine
it with GPIOs ... or, combine everything else with GPIOs
too (like PWMs).
But
This series implements a Generic PWM Device API, including reference
implementations for the Atmel PWMC device, an LED device, and an LED
trigger. It is based on linux-2.6.27.
This API is motivated by the author's need to support pluggable
devices; a secondary objective is to consolidate the
20 matches
Mail list logo
