* RE: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
From: H Hartley Sweeten @ 2010-02-16 18:12 UTC (permalink / raw)
To: Bill Gatliff; +Cc: Pavel Machek, linux-embedded, linux-kernel
In-Reply-To: <4B758153.2060209@billgatliff.com>
On Friday, February 12, 2010 9:27 AM, Bill Gatliff wrote:
> H Hartley Sweeten wrote:
>>
>> FWIW, the gpiolib API will accept any non-zero value to "set" a gpio pin
>> and a zero value to "clear" the pin.
>>
>
> It makes me sort of cringe to say this, but I'm going to assume that the
> API is intended to work that way so that I can take advantage of it.
> But I'd love to someday have the reassurance that gpiolib really *is*
> intended to work that way (might be a bad idea though, see below). Call
> me paranoid, but I've lost a lot of hair over the years undoing the
> damage of similar failed assumptions.
>
> I've found the Linux kernel code to be refreshingly forgiving of such
> things, however, so I'm willing to risk it this time. :)
>
>> For that matter, some of the gpiolib drivers end up returning the bit
>> position mask for a given gpio pin and not 1 or 0. For instance if the
>> gpio pin in question is bit 6 in an 8-bit register and it is set, a
>> __gpio_get_value will end up returning 0x40 and not '1'.
>>
>
> Who's to say that gpios should always be boolean? On the output side, a
> "gpio" that's four bits wide might be a useful way of dealing with bar
> graphs, seven-segment displays, etc. (but more specialized abstractions
> might be more appropriate, of course).
I think the original intention of gpiolib was to deal with individual pins.
> A two-bit "gpio" input might make it easier to deal with rotary encoders.
True. But a two-bit "gpio" is no longer a "pin" it's now a "port".
I have been messing with a "port" extension for gpiolib but it's not even
close to being mergable yet. But, that's a different topic...
> But for now, GPIOs are assumed to be booleans and that's why I'm
> hesitant to feed the API non-boolean values. Someday, those values
> might mean something subtly but disastrously different. And given my
> luck lately with such things...
True. As such just use ! and !! to make the values boolean.
gpio is bit 6
val = 0x40 -> !(0x40) = 0
val = 0x40 -> !!(0x40) = 1
Just my .02... Regards,
Hartley
^ permalink raw reply
* Re: [PATCH 03/11] readahead: bump up the default readahead size
From: Matt Mackall @ 2010-02-12 20:20 UTC (permalink / raw)
To: Wu Fengguang
Cc: Jamie Lokier, Christian Ehrhardt, Andrew Morton, Jens Axboe,
Chris Mason, Peter Zijlstra, Martin Schwidefsky, Clemens Ladisch,
Olivier Galibert, Linux Memory Management List,
linux-fsdevel@vger.kernel.org, LKML, Paul Gortmaker,
David Woodhouse, linux-embedded@vger.kernel.org
In-Reply-To: <20100212135949.GA22686@localhost>
On Fri, 2010-02-12 at 21:59 +0800, Wu Fengguang wrote:
> On Fri, Feb 12, 2010 at 07:42:49AM +0800, Jamie Lokier wrote:
> > Matt Mackall wrote:
> > > On Mon, 2010-02-08 at 21:46 +0800, Wu Fengguang wrote:
> > > > Chris,
> > > >
> > > > Firstly inform the linux-embedded maintainers :)
> > > >
> > > > I think it's a good suggestion to add a config option
> > > > (CONFIG_READAHEAD_SIZE). Will update the patch..
> > >
> > > I don't have a strong opinion here beyond the nagging feeling that we
> > > should be using a per-bdev scaling window scheme rather than something
> > > static.
>
> It's good to do dynamic scaling -- in fact this patchset has code to do
> - scale down readahead size (per-bdev) for small devices
I'm not sure device size is a great metric. It's only weakly correlated
with the things we actually care about: memory pressure (small devices
are often attached to systems with small and therefore full memory) and
latency (small devices are often old and slow and attached to slow
CPUs). I think we should instead use hints about latency (large request
queues) and memory pressure (reclaim passes) directly.
> - scale down readahead size (per-stream) to thrashing threshold
Yeah, I'm happy to call that part orthogonal to this discussion.
> At the same time, I'd prefer
> - to _only_ do scale down (below the default size) for low end
> - and have a uniform default readahead size for the mainstream
I don't think that's important, given that we're dynamically fiddling
with related things.
> IMHO scaling up automatically
> - would be risky
What, explicitly, are the risks? If we bound the window with memory
pressure and latency, I don't think it can get too far out of hand.
There are also some other bounds in here: we have other limits on how
big I/O requests can be.
I'm happy to worry about only scaling down for now, but it's only a
matter of time before we have to bump the number up again.
We've got an IOPS range from < 1 (mp3 player with power-saving
spin-down) to > 1M (high-end SSD). And the one that needs the most
readahead is the former!
> I would guess most embedded systems put executables on MTD devices
> (anyone to confirm this?).
It's hard to generalize here. Even on flash devices, interleaving with
writes can result in high latencies that make it behave more like
spinning media, but there's no way to generalize about what the write
mix is going to be.
> And I wonder if MTDs have general
> characteristics that are suitable for smaller readahead/readaround
> size (the two sizes are bundled for simplicity)?
Perhaps, but the trend is definitely towards larger blocks here.
> We could add new adjustments based on throughput (estimation is the
> problem) and memory size.
Note that throughput is not enough information here. More interesting is
the "bandwidth delay product" of the I/O path. If latency (of the whole
I/O stack) is zero, it's basically always better to read on demand. But
if every request takes 100ms whether it's for 4k or 4M (see optical
media), then you might want to consider reading 4M every time. And
latency is of course generally not independent of usage pattern. Which
is why I think TCP-like feedback scaling is the right approach.
--
http://selenic.com : development and support for Mercurial and Linux
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
From: Bill Gatliff @ 2010-02-12 16:26 UTC (permalink / raw)
To: H Hartley Sweeten; +Cc: Pavel Machek, linux-embedded, linux-kernel
In-Reply-To: <BD79186B4FD85F4B8E60E381CAEE190902153515@mi8nycmail19.Mi8.com>
H Hartley Sweeten wrote:
>
> FWIW, the gpiolib API will accept any non-zero value to "set" a gpio pin
> and a zero value to "clear" the pin.
>
It makes me sort of cringe to say this, but I'm going to assume that the
API is intended to work that way so that I can take advantage of it.
But I'd love to someday have the reassurance that gpiolib really *is*
intended to work that way (might be a bad idea though, see below). Call
me paranoid, but I've lost a lot of hair over the years undoing the
damage of similar failed assumptions.
I've found the Linux kernel code to be refreshingly forgiving of such
things, however, so I'm willing to risk it this time. :)
> For that matter, some of the gpiolib drivers end up returning the bit
> position mask for a given gpio pin and not 1 or 0. For instance if the
> gpio pin in question is bit 6 in an 8-bit register and it is set, a
> __gpio_get_value will end up returning 0x40 and not '1'.
>
Who's to say that gpios should always be boolean? On the output side, a
"gpio" that's four bits wide might be a useful way of dealing with bar
graphs, seven-segment displays, etc. (but more specialized abstractions
might be more appropriate, of course).
A two-bit "gpio" input might make it easier to deal with rotary encoders.
But for now, GPIOs are assumed to be booleans and that's why I'm
hesitant to feed the API non-boolean values. Someday, those values
might mean something subtly but disastrously different. And given my
luck lately with such things...
b.g.
--
Bill Gatliff
Embedded systems training and consulting
http://billgatliff.com
bgat@billgatliff.com
^ permalink raw reply
* Re: [PATCH 03/11] readahead: bump up the default readahead size
From: Wu Fengguang @ 2010-02-12 13:59 UTC (permalink / raw)
To: Jamie Lokier
Cc: Matt Mackall, Christian Ehrhardt, Andrew Morton, Jens Axboe,
Chris Mason, Peter Zijlstra, Martin Schwidefsky, Clemens Ladisch,
Olivier Galibert, Linux Memory Management List,
linux-fsdevel@vger.kernel.org, LKML, Paul Gortmaker,
David Woodhouse, linux-embedded@vger.kernel.org
In-Reply-To: <20100211234249.GE407@shareable.org>
On Fri, Feb 12, 2010 at 07:42:49AM +0800, Jamie Lokier wrote:
> Matt Mackall wrote:
> > On Mon, 2010-02-08 at 21:46 +0800, Wu Fengguang wrote:
> > > Chris,
> > >
> > > Firstly inform the linux-embedded maintainers :)
> > >
> > > I think it's a good suggestion to add a config option
> > > (CONFIG_READAHEAD_SIZE). Will update the patch..
> >
> > I don't have a strong opinion here beyond the nagging feeling that we
> > should be using a per-bdev scaling window scheme rather than something
> > static.
It's good to do dynamic scaling -- in fact this patchset has code to do
- scale down readahead size (per-bdev) for small devices
- scale down readahead size (per-stream) to thrashing threshold
At the same time, I'd prefer
- to _only_ do scale down (below the default size) for low end
- and have a uniform default readahead size for the mainstream
IMHO scaling up automatically
- would be risky
- hurts to build one common expectation on Linux behavior
(not only developers, but also admins will run into the question:
"what on earth is the readahead size?")
- and still not likely to please the high end guys ;)
> I agree with both. 100Mb/s isn't typical on little devices, even if a
> fast ATA disk is attached. I've got something here where the ATA
> interface itself (on a SoC) gets about 10MB/s max when doing nothing
> else, or 4MB/s when talking to the network at the same time.
> It's not a modern design, but you know, it's junk we try to use :-)
Good to know this. I guess the same situation for some USB-capable
wireless routers -- they typically don't have powerful hardware to
exert the full 100MB/s disk speed.
> It sounds like a calculation based on throughput and seek time or IOP
> rate, and maybe clamped if memory is small, would be good.
>
> Is the window size something that could be meaningfully adjusted
> according to live measurements?
We currently have live adjustment for
- small devices
- thrashed read streams
We could add new adjustments based on throughput (estimation is the
problem) and memory size.
Note that it does not really hurt to have big _readahead_ size on low
throughput or small memory conditions, because it's merely _max_
readahead size, the actual readahead size scales up step-by-step, and
scales down if thrashed, and the sequential readahead hit ratio is
pretty high (so no memory/bandwidth is wasted).
What may hurt is to have big mmap _readaround_ size. The larger
readaround size, the more readaround miss ratio (but still not
disastrous), hence more memory pages and bandwidth wasted. It's not a
big problem for mainstream, however embedded systems may be more
sensitive.
I would guess most embedded systems put executables on MTD devices
(anyone to confirm this?). And I wonder if MTDs have general
characteristics that are suitable for smaller readahead/readaround
size (the two sizes are bundled for simplicity)?
Thanks,
Fengguang
^ permalink raw reply
* RE: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
From: H Hartley Sweeten @ 2010-02-12 13:53 UTC (permalink / raw)
To: Bill Gatliff, Pavel Machek; +Cc: linux-embedded, linux-kernel
In-Reply-To: <4B746A02.9060306@billgatliff.com>
Thursday, February 11, 2010 1:35 PM, Bill Gatliff wrote:
> Pavel Machek wrote:
>>> +static void
>>> +gpio_pwm_work (struct work_struct *work)
>>> +{
>>> + struct gpio_pwm *gp = container_of(work, struct gpio_pwm, work);
>>> +
>>> + if (gp->active)
>>> + gpio_direction_output(gp->gpio, gp->polarity ? 1 : 0);
>>> + else
>>> + gpio_direction_output(gp->gpio, gp->polarity ? 0 : 1);
>>> +}
>>>
>>
>> ...polarity ^ active ?
>>
>
> ... except that if polarity and/or active are >1, I don't send the
> values 1 or 0 to gpio_direction_output. I don't know if the API is
> specifically intended to accept nonzero values that are greater than 1.
FWIW, the gpiolib API will accept any non-zero value to "set" a gpio pin
and a zero value to "clear" the pin.
For that matter, some of the gpiolib drivers end up returning the bit
position mask for a given gpio pin and not 1 or 0. For instance if the
gpio pin in question is bit 6 in an 8-bit register and it is set, a
__gpio_get_value will end up returning 0x40 and not '1'.
Regards,
Hartley
^ permalink raw reply
* Re: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
From: Pavel Machek @ 2010-02-12 13:41 UTC (permalink / raw)
To: Stanislav O. Bezzubtsev; +Cc: Bill Gatliff, linux-embedded, linux-kernel
In-Reply-To: <A8919B3D-43EF-4EA5-8334-F1B52AE97E5A@lvk.cs.msu.su>
>
> 11.02.2010, ? 23:58, Pavel Machek ???????(?):
>
> > On Thu 2010-02-11 14:35:14, Bill Gatliff wrote:
> >> Pavel Machek wrote:
> >>>> +static void
> >>>> +gpio_pwm_work (struct work_struct *work)
> >>>> +{
> >>>> + struct gpio_pwm *gp = container_of(work, struct gpio_pwm, work);
> >>>> +
> >>>> + if (gp->active)
> >>>> + gpio_direction_output(gp->gpio, gp->polarity ? 1 : 0);
> >>>> + else
> >>>> + gpio_direction_output(gp->gpio, gp->polarity ? 0 : 1);
> >>>> +}
> >>>>
> >>>
> >>> ...polarity ^ active ?
> >>>
> >>
> >> ... except that if polarity and/or active are >1, I don't send the
> >> values 1 or 0 to gpio_direction_output. I don't know if the API is
> >> specifically intended to accept nonzero values that are greater than 1.
> >
> > !polarity ^ !active ? :-).
>
>
> One the one hand that wouldn't be 100% right because according to
> ANSI C !(0) is just != 0 but no one says it is 1.
I believe you are wrong here.
!!x is common idiom using to turn anything into 0/1, used all over kernel.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
From: Geert Uytterhoeven @ 2010-02-12 13:13 UTC (permalink / raw)
To: Stanislav O. Bezzubtsev
Cc: Pavel Machek, Bill Gatliff, linux-embedded, linux-kernel
In-Reply-To: <A8919B3D-43EF-4EA5-8334-F1B52AE97E5A@lvk.cs.msu.su>
2010/2/12 Stanislav O. Bezzubtsev <stas@lvk.cs.msu.su>:
> The second strange thing is "unsigned long <name>:1". I'm not sure but as far as I can remember the right way to define several-bits field is "int <name>:1". But I might be mistaken.
A bitfield of size 1 should not be signed, as there's no space for a sign bit.
Usually, you want all bitfields to be unsigned anyway.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
From: Stanislav O. Bezzubtsev @ 2010-02-12 7:22 UTC (permalink / raw)
To: Pavel Machek; +Cc: Bill Gatliff, linux-embedded, linux-kernel
In-Reply-To: <20100211205801.GA29159@elf.ucw.cz>
11.02.2010, в 23:58, Pavel Machek написал(а):
> On Thu 2010-02-11 14:35:14, Bill Gatliff wrote:
>> Pavel Machek wrote:
>>>> +static void
>>>> +gpio_pwm_work (struct work_struct *work)
>>>> +{
>>>> + struct gpio_pwm *gp = container_of(work, struct gpio_pwm, work);
>>>> +
>>>> + if (gp->active)
>>>> + gpio_direction_output(gp->gpio, gp->polarity ? 1 : 0);
>>>> + else
>>>> + gpio_direction_output(gp->gpio, gp->polarity ? 0 : 1);
>>>> +}
>>>>
>>>
>>> ...polarity ^ active ?
>>>
>>
>> ... except that if polarity and/or active are >1, I don't send the
>> values 1 or 0 to gpio_direction_output. I don't know if the API is
>> specifically intended to accept nonzero values that are greater than 1.
>
> !polarity ^ !active ? :-).
One the one hand that wouldn't be 100% right because according to ANSI C !(0) is just != 0 but no one says it is 1.
On another hand as far as I can see polarity and active fields are both defined as "unsigned long <name> :1" in the gpio_pwm structure. And that means they can be equal only to 0 or 1. So simple (polarity ^ active) is the right choice as far as the original decision.
What is strange for me is that resulting control flow is not right representation of what is happening. I mean that actually one should perform a call to an external function with an argument that depends on values of two variables. While this code is equal to call function A if some variable is not equal to 0 with argument depending on value of some other variable else call function B. I hope you understood what I'm trying to say.
Therefore even if you wish to leave if statement (not sure that gcc would optimize that) the right control flow representation should be the following:
.....
if (gp->active)
value = ((gp->polarity)?1:0);
else
value = ((gp->polarity)?0:1);
gpio_direction_output(gp->gpio, value);
.....
The second strange thing is "unsigned long <name>:1". I'm not sure but as far as I can remember the right way to define several-bits field is "int <name>:1". But I might be mistaken.
Best regards. Stas.
^ permalink raw reply
* Re: [PATCH 03/11] readahead: bump up the default readahead size
From: Matt Mackall @ 2010-02-12 0:04 UTC (permalink / raw)
To: Jamie Lokier
Cc: Wu Fengguang, Christian Ehrhardt, Andrew Morton, Jens Axboe,
Chris Mason, Peter Zijlstra, Martin Schwidefsky, Clemens Ladisch,
Olivier Galibert, Linux Memory Management List,
linux-fsdevel@vger.kernel.org, LKML, Paul Gortmaker,
David Woodhouse, linux-embedded
In-Reply-To: <20100211234249.GE407@shareable.org>
On Thu, 2010-02-11 at 23:42 +0000, Jamie Lokier wrote:
> Matt Mackall wrote:
> > On Mon, 2010-02-08 at 21:46 +0800, Wu Fengguang wrote:
> > > Chris,
> > >
> > > Firstly inform the linux-embedded maintainers :)
> > >
> > > I think it's a good suggestion to add a config option
> > > (CONFIG_READAHEAD_SIZE). Will update the patch..
> >
> > I don't have a strong opinion here beyond the nagging feeling that we
> > should be using a per-bdev scaling window scheme rather than something
> > static.
>
> I agree with both. 100Mb/s isn't typical on little devices, even if a
> fast ATA disk is attached. I've got something here where the ATA
> interface itself (on a SoC) gets about 10MB/s max when doing nothing
> else, or 4MB/s when talking to the network at the same time.
> It's not a modern design, but you know, it's junk we try to use :-)
>
> It sounds like a calculation based on throughput and seek time or IOP
> rate, and maybe clamped if memory is small, would be good.
>
> Is the window size something that could be meaningfully adjusted
> according to live measurements?
I think so. You've basically got a few different things you want to
balance: throughput, latency, and memory pressure. Successful readaheads
expand the window, as do empty request queues, while long request queues
and memory reclaim events collapse it. With any luck, we'll then
automatically do the right thing with fast/slow devices on big/small
boxes with varying load. And, like TCP, we don't need to 'know' anything
about the hardware, except to watch what happens when we use it.
--
http://selenic.com : development and support for Mercurial and Linux
^ permalink raw reply
* Re: [PATCH 03/11] readahead: bump up the default readahead size
From: Jamie Lokier @ 2010-02-11 23:42 UTC (permalink / raw)
To: Matt Mackall
Cc: Wu Fengguang, Christian Ehrhardt, Andrew Morton, Jens Axboe,
Chris Mason, Peter Zijlstra, Martin Schwidefsky, Clemens Ladisch,
Olivier Galibert, Linux Memory Management List,
linux-fsdevel@vger.kernel.org, LKML, Paul Gortmaker,
David Woodhouse, linux-embedded
In-Reply-To: <1265924254.15603.79.camel@calx>
Matt Mackall wrote:
> On Mon, 2010-02-08 at 21:46 +0800, Wu Fengguang wrote:
> > Chris,
> >
> > Firstly inform the linux-embedded maintainers :)
> >
> > I think it's a good suggestion to add a config option
> > (CONFIG_READAHEAD_SIZE). Will update the patch..
>
> I don't have a strong opinion here beyond the nagging feeling that we
> should be using a per-bdev scaling window scheme rather than something
> static.
I agree with both. 100Mb/s isn't typical on little devices, even if a
fast ATA disk is attached. I've got something here where the ATA
interface itself (on a SoC) gets about 10MB/s max when doing nothing
else, or 4MB/s when talking to the network at the same time.
It's not a modern design, but you know, it's junk we try to use :-)
It sounds like a calculation based on throughput and seek time or IOP
rate, and maybe clamped if memory is small, would be good.
Is the window size something that could be meaningfully adjusted
according to live measurements?
-- Jamie
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 03/11] readahead: bump up the default readahead size
From: Matt Mackall @ 2010-02-11 21:37 UTC (permalink / raw)
To: Wu Fengguang
Cc: Christian Ehrhardt, Andrew Morton, Jens Axboe, Chris Mason,
Peter Zijlstra, Martin Schwidefsky, Clemens Ladisch,
Olivier Galibert, Linux Memory Management List,
linux-fsdevel@vger.kernel.org, LKML, Paul Gortmaker,
David Woodhouse, linux-embedded
In-Reply-To: <20100208134634.GA3024@localhost>
On Mon, 2010-02-08 at 21:46 +0800, Wu Fengguang wrote:
> Chris,
>
> Firstly inform the linux-embedded maintainers :)
>
> I think it's a good suggestion to add a config option
> (CONFIG_READAHEAD_SIZE). Will update the patch..
I don't have a strong opinion here beyond the nagging feeling that we
should be using a per-bdev scaling window scheme rather than something
static.
--
http://selenic.com : development and support for Mercurial and Linux
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PWM PATCH 1/5] API to consolidate PWM devices behind a common user and kernel interface
From: Pavel Machek @ 2010-02-11 21:00 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-embedded, linux-kernel
In-Reply-To: <4B746DEC.7080602@billgatliff.com>
> >> +pwm_free() -- Marks a PWM channel as no longer in use. The PWM device
> >> +is stopped before it is released by the API.
> >>
> >
> > free is normally used for something else. Rename to open/close?
> ... or request/release?
Works for me.
> >> +pwm_start(), pwm_stop() -- Turns the PWM signal on and off. Except
> >> +where stated otherwise by a driver author, signals are stopped at the
> >> +end of the current period, at which time the output is set to its
> >> +inactive state.
> >>
> >
> > What does it mean to stop a signal? What is the difference between 0%
> > duty cycle and stop() ?
> >
>
> Depends on the hardware. For a true PWM peripheral, a 0% duty cycle
> might still have the base peripheral clock for the device running.
> Whereas a pwm_stop() signal could be used to turn off the clock to the
> peripheral.
If it is just powersaving... I'd do it automatically when 0% duty is
selected...? Or is that infeasible due to latency...?
> > Is polarity realy required? Can't driver just replace duty with
> > 100%-duty
>
> Actually, yes in some cases. Users can always do the 100%-duty math,
> but some hardware asserts a specific output state when you stop the
> peripheral that's potentially different from 0% duty. Also, some
> hardware begins the PWM cycle with the output high, while others do with
> the output low. It isn't necessarily the case that the user cares, but
> I was thinking that having the API allow for different polarity might
> prevent some applications having to optionally do the %duty vs.
> 100-%duty conversion themselves.
Ok, ok, but this should go into the docs.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
From: Pavel Machek @ 2010-02-11 20:58 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-embedded, linux-kernel
In-Reply-To: <4B746A02.9060306@billgatliff.com>
On Thu 2010-02-11 14:35:14, Bill Gatliff wrote:
> Pavel Machek wrote:
> >> +static void
> >> +gpio_pwm_work (struct work_struct *work)
> >> +{
> >> + struct gpio_pwm *gp = container_of(work, struct gpio_pwm, work);
> >> +
> >> + if (gp->active)
> >> + gpio_direction_output(gp->gpio, gp->polarity ? 1 : 0);
> >> + else
> >> + gpio_direction_output(gp->gpio, gp->polarity ? 0 : 1);
> >> +}
> >>
> >
> > ...polarity ^ active ?
> >
>
> ... except that if polarity and/or active are >1, I don't send the
> values 1 or 0 to gpio_direction_output. I don't know if the API is
> specifically intended to accept nonzero values that are greater than 1.
!polarity ^ !active ? :-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PWM PATCH 1/5] API to consolidate PWM devices behind a common user and kernel interface
From: Bill Gatliff @ 2010-02-11 20:51 UTC (permalink / raw)
To: Pavel Machek; +Cc: linux-embedded, linux-kernel
In-Reply-To: <20100211200456.GA1487@ucw.cz>
Pavel Machek wrote:
> Exactly; if your hw can be damaged by software, it was misdesigned.
>
> Is the paragraph #1 really neccessary?
>
It provides a little background on the subject matter. I don't think
it's mandatory, but I don't see the harm in keeping it. I think it
improves the document overall from an editorial perspective, however.
>> +pwm_free() -- Marks a PWM channel as no longer in use. The PWM device
>> +is stopped before it is released by the API.
>>
>
> free is normally used for something else. Rename to open/close?
>
... or request/release?
>> +pwm_start(), pwm_stop() -- Turns the PWM signal on and off. Except
>> +where stated otherwise by a driver author, signals are stopped at the
>> +end of the current period, at which time the output is set to its
>> +inactive state.
>>
>
> What does it mean to stop a signal? What is the difference between 0%
> duty cycle and stop() ?
>
Depends on the hardware. For a true PWM peripheral, a 0% duty cycle
might still have the base peripheral clock for the device running.
Whereas a pwm_stop() signal could be used to turn off the clock to the
peripheral.
> Is polarity realy required? Can't driver just replace duty with
> 100%-duty
Actually, yes in some cases. Users can always do the 100%-duty math,
but some hardware asserts a specific output state when you stop the
peripheral that's potentially different from 0% duty. Also, some
hardware begins the PWM cycle with the output high, while others do with
the output low. It isn't necessarily the case that the user cares, but
I was thinking that having the API allow for different polarity might
prevent some applications having to optionally do the %duty vs.
100-%duty conversion themselves.
b.g.
--
Bill Gatliff
Embedded systems training and consulting
http://billgatliff.com
bgat@billgatliff.com
^ permalink raw reply
* Re: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
From: Bill Gatliff @ 2010-02-11 20:35 UTC (permalink / raw)
To: Pavel Machek; +Cc: linux-embedded, linux-kernel
In-Reply-To: <20100211200702.GB1487@ucw.cz>
Pavel Machek wrote:
>> +static void
>> +gpio_pwm_work (struct work_struct *work)
>> +{
>> + struct gpio_pwm *gp = container_of(work, struct gpio_pwm, work);
>> +
>> + if (gp->active)
>> + gpio_direction_output(gp->gpio, gp->polarity ? 1 : 0);
>> + else
>> + gpio_direction_output(gp->gpio, gp->polarity ? 0 : 1);
>> +}
>>
>
> ...polarity ^ active ?
>
... except that if polarity and/or active are >1, I don't send the
values 1 or 0 to gpio_direction_output. I don't know if the API is
specifically intended to accept nonzero values that are greater than 1.
b.g.
--
Bill Gatliff
Embedded systems training and consulting
http://billgatliff.com
bgat@billgatliff.com
^ permalink raw reply
* Re: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
From: Pavel Machek @ 2010-02-11 20:07 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-embedded, linux-kernel
In-Reply-To: <2d73f9b2fd175fd3e482920baebcd3028206f02e.1265094517.git.bgat@billgatliff.com>
> +static void
> +gpio_pwm_work (struct work_struct *work)
> +{
> + struct gpio_pwm *gp = container_of(work, struct gpio_pwm, work);
> +
> + if (gp->active)
> + gpio_direction_output(gp->gpio, gp->polarity ? 1 : 0);
> + else
> + gpio_direction_output(gp->gpio, gp->polarity ? 0 : 1);
> +}
...polarity ^ active ?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PWM PATCH 1/5] API to consolidate PWM devices behind a common user and kernel interface
From: Pavel Machek @ 2010-02-11 20:04 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-embedded, linux-kernel
In-Reply-To: <c5873aa7c5d20254a9e54fc1ff179345b77c16b5.1265094517.git.bgat@billgatliff.com>
Hi!
> +Challenges
> +
> +One of the difficulties in implementing a generic PWM framework is the
> +fact that pulse-width-modulation applications involve real-world
> +signals, which often must be carefully managed to prevent destruction
> +of hardware that is linked to those signals. A DC motor that
> +experiences a brief interruption in the PWM signal controlling it
> +might destructively overheat; it could suddenly change speed, losing
> +synchronization with a sensor; it could even suddenly change direction
> +or torque, breaking the mechanical device connected to it.
Stop right here. Linux is not hard realtime os, nor is it an os that
never crashes.
> +(A generic PWM device framework is not directly responsible for
> +preventing the above scenarios: that responsibility lies with the
> +hardware designer, and the application and driver authors. But it
Exactly; if your hw can be damaged by software, it was misdesigned.
Is the paragraph #1 really neccessary?
> +Using the API to Generate PWM Signals -- Basic Functions for Users
> +
> +
> +pwm_request() -- Returns a pwm_channel pointer, which is subsequently
> +passed to the other user-related PWM functions. Once requested, a PWM
> +channel is marked as in-use and subsequent requests prior to
> +pwm_free() will fail.
> +
> +The names used to refer to PWM devices are defined by driver authors.
> +Typically they are platform device bus identifiers, and this
> +convention is encouraged for consistency.
> +
> +
> +pwm_free() -- Marks a PWM channel as no longer in use. The PWM device
> +is stopped before it is released by the API.
free is normally used for something else. Rename to open/close?
> +pwm_start(), pwm_stop() -- Turns the PWM signal on and off. Except
> +where stated otherwise by a driver author, signals are stopped at the
> +end of the current period, at which time the output is set to its
> +inactive state.
What does it mean to stop a signal? What is the difference between 0%
duty cycle and stop() ?
> +pwm_polarity() -- Defines whether the PWM signal output's active
> +region is "1" or "0". A 10% duty-cycle, polarity=1 signal will
> +conventionally be at 5V (or 3.3V, or 1000V, or whatever the platform
> +hardware does) for 10% of the period. The same configuration of a
> +polarity=0 signal will be at 5V (or 3.3V, or ...) for 90% of the
> +period.
Is polarity realy required? Can't driver just replace duty with
100%-duty?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* RE: [PWM PATCH 1/7] API to consolidate PWM devices behind a common user and kernel interface
From: H Hartley Sweeten @ 2010-02-10 18:33 UTC (permalink / raw)
To: Bill Gatliff, linux-embedded; +Cc: linux-kernel
In-Reply-To: <b7afd475c3fce08f459bceff7814de57ffce7bd0.1265748264.git.bgat@billgatliff.com>
On Tuesday, February 09, 2010 1:46 PM, Bill Gatliff wrote:
> diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt
> new file mode 100644
> index 0000000..2c41ca5
> --- /dev/null
> +++ b/Documentation/pwm.txt
A couple minor comments below.
> @@ -0,0 +1,260 @@
> + Generic PWM Device API
> +
> + February 1, 2010
> + Bill Gatliff
> + <bgat@billgatliff.com>
> +
> +
> +
> +The code in drivers/pwm and include/linux/pwm/ implements an API for
> +applications involving pulse-width-modulation signals. This document
> +describes how the API implementation facilitates both PWM-generating
> +devices, and users of those devices.
> +
> +
> +
> +Motivation
> +
> +The primary goals for implementing the "generic PWM API" are to
> +consolidate the various PWM implementations within a consistent and
> +redundancy-reducing framework, and to facilitate the use of
> +hotpluggable PWM devices.
> +
> +Previous PWM-related implementations within the Linux kernel achieved
> +their consistency via cut-and-paste, but did not need to (and didn't)
> +facilitate more than one PWM-generating device within the system---
> +hotplug or otherwise. The Generic PWM Device API might be most
> +appropriately viewed as an update to those implementations, rather
> +than a complete rewrite.
> +
> +
> +
> +Challenges
> +
> +One of the difficulties in implementing a generic PWM framework is the
> +fact that pulse-width-modulation applications involve real-world
> +signals, which often must be carefully managed to prevent destruction
> +of hardware that is linked to those signals. A DC motor that
> +experiences a brief interruption in the PWM signal controlling it
> +might destructively overheat; it could suddenly change speed, losing
> +synchronization with a sensor; it could even suddenly change direction
> +or torque, breaking the mechanical device connected to it.
> +
> +(A generic PWM device framework is not directly responsible for
> +preventing the above scenarios: that responsibility lies with the
> +hardware designer, and the application and driver authors. But it
> +must to the greatest extent possible make it easy to avoid such
> +problems).
> +
> +A generic PWM device framework must accommodate the substantial
> +differences between available PWM-generating hardware devices, without
> +becoming sub-optimal for any of them.
> +
> +Finally, a generic PWM device framework must be relatively
> +lightweight, computationally speaking. Some PWM users demand
> +high-speed outputs, plus the ability to regulate those outputs
> +quickly. A device framework must be able to "keep up" with such
> +hardware, while still leaving time to do real work.
> +
> +The Generic PWM Device API is an attempt to meet all of the above
> +requirements. At its initial publication, the API was already in use
> +managing small DC motors, sensors and solenoids through a
> +custom-designed, optically-isolated H-bridge driver.
> +
> +
> +
> +Functional Overview
> +
> +The Generic PWM Device API framework is implemented in
> +include/linux/pwm/pwm.h and drivers/pwm/pwm.c. The functions therein
> +use information from pwm_device, pwm_channel and pwm_channel_config
> +structures to invoke services in PWM peripheral device drivers.
> +Consult drivers/pwm/atmel-pwm.c for an example driver.
> +
> +There are two classes of adopters of the PWM framework:
> +
> + "Users" -- those wishing to employ the API merely to produce PWM
> + signals; once they have identified the appropriate physical output
> + on the platform in question, they don't care about the details of
> + the underlying hardware
> +
> + "Driver authors" -- those wishing to bind devices that can generate
> + PWM signals to the Generic PWM Device API, so that the services of
> + those devices become available to users. Assuming the hardware can
> + support the needs of a user, driver authors don't care about the
> + details of the user's application
> +
> +Generally speaking, users will first invoke pwm_request() to obtain a
> +handle to a PWM device. They will then pass that handle to functions
> +like pwm_duty_ns() and pwm_period_ns() to set the duty cycle and
> +period of the PWM signal, respectively. They will also invoke
> +pwm_start() and pwm_stop() to turn the signal on and off.
> +
> +The Generic PWM API framework also provides a sysfs interface to PWM
> +devices, which is adequate for basic application needs and testing.
> +
> +Driver authors fill out a pwm_device structure, which describes the
> +capabilities of the PWM hardware being constructed--- including the
> +number of distinct output "channels" the peripheral offers. They then
> +invoke pwm_register() (usually from within their device's probe()
> +handler) to make the PWM API aware of their device. The framework
> +will call back to the methods described in the pwm_device structure as
> +users begin to configure and utilize the hardware.
> +
> +Note that PWM signals can be produced by a variety of peripherals,
> +beyond the true "PWM hardware" offered by many system-on-chip devices.
> +Other possibilities include timer/counters with compare-match
> +capabilities, carefully-programmed synchronous serial ports
> +(e.g. SPI), and GPIO pins driven by kernel interval timers. With a
> +proper pwm_device structure, these devices and pseudo-devices can all
> +be accommodated by the Generic PWM Device API framework.
> +
> +
> +
> +Using the API to Generate PWM Signals -- Basic Functions for Users
> +
> +
> +pwm_request() -- Returns a pwm_channel pointer, which is subsequently
> +passed to the other user-related PWM functions. Once requested, a PWM
> +channel is marked as in-use and subsequent requests prior to
> +pwm_free() will fail.
> +
> +The names used to refer to PWM devices are defined by driver authors.
> +Typically they are platform device bus identifiers, and this
> +convention is encouraged for consistency.
> +
> +
> +pwm_free() -- Marks a PWM channel as no longer in use. The PWM device
> +is stopped before it is released by the API.
> +
> +
> +pwm_period_ns() -- Specifies the PWM signal's period, in nanoseconds.
> +
> +
> +pwm_duty_ns() -- Specifies the PWM signal's active duration, in nanoseconds.
> +
> +
> +pwm_duty_percent() -- Specifies the PWM signal's active duration, as a
> +percentage of the current period of the signal. NOTE: this value is
> +not recalculated if the period of the signal is subsequently changed.
> +
> +
> +pwm_start(), pwm_stop() -- Turns the PWM signal on and off. Except
> +where stated otherwise by a driver author, signals are stopped at the
> +end of the current period, at which time the output is set to its
> +inactive state.
> +
> +
> +pwm_polarity() -- Defines whether the PWM signal output's active
> +region is "1" or "0". A 10% duty-cycle, polarity=1 signal will
> +conventionally be at 5V (or 3.3V, or 1000V, or whatever the platform
> +hardware does) for 10% of the period. The same configuration of a
> +polarity=0 signal will be at 5V (or 3.3V, or ...) for 90% of the
> +period.
> +
> +
> +
> +Using the API to Generate PWM Signals -- Advanced Functions
> +
> +
> +pwm_config() -- Passes a pwm_channel_config structure to the
> +associated device driver. This function is invoked by pwm_start(),
> +pwm_duty_ns(), etc. and is one of two main entry points to the PWM
> +driver for the hardware being used. The configuration change is
> +guaranteed atomic if multiple configuration changes are specified.
> +This function might sleep, depending on what the device driver has to
> +do to satisfy the request. All PWM device drivers must support this
> +entry point.
> +
> +
> +pwm_config_nosleep() -- Passes a pwm_channel_config structure to the
> +associated device driver. If the driver must sleep in order to
> +implement the requested configuration change, -EWOULDBLOCK is
> +returned. Users may call this function from interrupt handlers, for
> +example. This is the other main entry point into the PWM hardware
> +driver, but not all device drivers support this entry point.
> +
> +
> +pwm_synchronize(), pwm_unsynchronize() -- "Synchronizes" two or more
> +PWM channels, if the underlying hardware permits. (If it doesn't, the
> +framework facilitates emulating this capability but it is not yet
> +implemented). Synchronized channels will start and stop
> +simultaneously when any single channel in the group is started or
> +stopped. Use pwm_unsynchronize(..., NULL) to completely detach a
> +channel from any other synchronized channels. By default, all PWM
> +channels are unsynchronized.
> +
> +
> +pwm_set_handler() -- Defines an end-of-period callback. The indicated
> +function will be invoked in a worker thread at the end of each PWM
> +period, and can subsequently invoke pwm_config(), etc. Must be used
> +with extreme care for high-speed PWM outputs. Set the handler
> +function to NULL to un-set the handler.
This requires that the pwm producer can generate an interrupt signaling
the end-of-period. If so you might want to mention this so that driver
writers don't spin their wheels trying to get the callback to work. It's
mentioned below but you might want to bring it up here.
> +
> +
> +
> +Implementing a PWM Device API Driver -- Functions for Driver Authors
> +
> +
> +Fill out the appropriate fields in a pwm_device structure, and submit
> +to pwm_register():
> +
What about dev? If it's missing you will get the oops.
> +
> +bus_id -- the plain-text name of the device. Users will bind to a
> +channel on the device using this name plus the channel number. For
> +example, the Atmel PWMC's bus_id is "atmel_pwmc", the same as used by
> +the platform device driver (recommended). The first device registered
> +thereby receives bus_id "atmel_pwmc.0", which is what you put in
> +pwm_device.bus_id. Channels are then named "atmel_pwmc.0:[0-3]".
> +(Hint: just use pdev->dev.bus_id in your probe() method).
The hint doesn't work. The bus_id needs to be a string, use dev_name
or something along that line.
> +
> +
> +nchan -- the number of distinct output channels provided by the device.
> +
> +
> +request -- (optional) Invoked each time a user requests a channel.
> +Use to turn on clocks, clean up register states, etc. The framework
> +takes care of device locking/unlocking; you will see only successful
> +requests.
> +
> +
> +free -- (optional) Callback for each time a user relinquishes a
> +channel. The framework will have already stopped, unsynchronized and
> +un-handled the channel. Use to turn off clocks, etc. as necessary.
> +
> +
> +synchronize, unsynchronize -- (optional) Callbacks to
> +synchronize/unsynchronize channels. Some devices provide this
> +capability in hardware; for others, it can be emulated (see
> +atmel_pwmc.c's sync_mask for an example).
> +
> +
> +set_callback -- (optional) Invoked when a user requests a handler. If
> +the hardware supports an end-of-period interrupt, invoke the function
> +indicated during your interrupt handler. The callback function itself
> +is always internal to the API, and does not map directly to the user's
> +callback function.
See above.
> +
> +
> +config -- Invoked to change the device configuration, always from a
> +sleep-capable context. All the changes indicated must be performed
> +atomically, ideally synchronized to an end-of-period event (so that
> +you avoid short or long output pulses). You may sleep, etc. as
> +necessary within this function.
> +
> +
> +config_nosleep -- (optional) Invoked to change device configuration
> +from within a context that is not allowed to sleep. If you cannot
> +perform the requested configuration changes without sleeping, return
> +-EWOULDBLOCK.
If the pwm hardware does not implement this callback the API will
return -EINVAL. Does this need to be mentioned?
Also, it appears all your drivers first try to implement the pwm_config
using the config_nosleep then fall back to the config inplementation.
is this the desired standard?
> +
> +
> +
> +Acknowledgements
> +
> +
> +The author expresses his gratitude to the countless developers who
> +have reviewed and submitted feedback on the various versions of the
> +Generic PWM Device API code, and those who have submitted drivers and
> +applications that use the framework. You know who you are. ;)
> +
Regards,
Hartley
^ permalink raw reply
* RE: [PWM PATCH 1/7] API to consolidate PWM devices behind a common user and kernel interface
From: H Hartley Sweeten @ 2010-02-10 17:34 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-embedded, linux-kernel
In-Reply-To: <4B723239.4090802@billgatliff.com>
On Tuesday, February 09, 2010 9:13 PM, Bill Gatliff wrote:
> H Hartley Sweeten wrote:
>>> +
>>> +static int __pwm_create_sysfs(struct pwm_device *pwm);
>>> +
>>> +static const char *REQUEST_SYSFS = "sysfs";
>>>
>>
>> Does this static string save that much? It's only used two places in this
>> file.
>>
>
> It makes sure the same string is used in both places. I do a strcmp on
> it, so I wanted to make sure I didn't screw it up!
Ok.
>>> + p = kcalloc(pwm->nchan, sizeof(*p), GFP_KERNEL);
>>> + if (!p)
>>> + {
>>> + pr_err("%s: ENOMEM\n", __func__);
>>> + return -ENOMEM;
>>> + }
>>>
>>
>> I assume this pr_err is just a debug message and will be removed.
>> If not the '{' should be on the previous line.
>>
>
> Yes, it's a debug message. I obviously don't clean up after myself very
> well...
;-)
>>> + list_add_tail(&pwm->list, &pwm_device_list);
>>> + ret = __pwm_create_sysfs(pwm);
>>> + if (ret) {
>>> + mutex_unlock(&device_list_mutex);
>>> + pr_err("%s: err_create_sysfs\n", __func__);
>>>
>>
>> Another debug message?
>>
>
> Yes. Darn it. :)
>
>
>>> + goto err_create_sysfs;
>>> + }
>>> +
>>> + mutex_unlock(&device_list_mutex);
>>> +
>>> + dev_info(pwm->dev, "%d channel%s\n", pwm->nchan,
>>> + pwm->nchan > 1 ? "s" : "");
>>> + return 0;
>>>
>>
>> I need to check the rest of the patch series but I assume you have
>> fixed the pwm->dev = NULL issue.
>>
>
> Yes. Tested it properly, even! :)
Ok.
>>> +
>>> + p->requester = requester;
>>> + if (!strcmp(requester, REQUEST_SYSFS))
>>> + p->pid = current->pid;
>>>
>>
>> This is new.. What's the reason for saving the pid?
>>
>
> I've gotten complaints from those who say, "Ok, so it reported 'sysfs'
> back to me, but how can I be sure that it's because *I* own it now, and
> not another user process?" Seemed easy enough to add the PID so they
> can check. Of course, you could argue that I could report just the PID,
> and skip the "sysfs" string altogether. I'd be inclined to agree with you.
>
> Of course, if you are like me and do the request with cat(1), then the
> PID is pretty meaningless. :)
I would think a userspace request would typically use cat(1). That's why
I didn't understand why you are saving the pid.
More on this below.
>>> +
>>> +int pwm_set_polarity(struct pwm_channel *p,
>>> + int active_high)
>>> +{
>>> + struct pwm_channel_config c = {
>>> + .config_mask = PWM_CONFIG_POLARITY,
>>> + .polarity = active_high,
>>> + };
>>> + return pwm_config(p, &c);
>>> +}
>>> +EXPORT_SYMBOL(pwm_set_polarity);
>>>
>>
>> Has the 'polarity' logic been verified?
>>
>> pwm_set_polarity takes an active high flag that is passed to pwm_config.
>> A write to the sysfs 'polarity' file passes the value directly to pwm_config.
>> A read from the sysfs 'polarity' file returns struct pwm_channel ->active_low.
>>
>> Seems like a mis-match in logic.
>>
>
> It does, indeed! I thought I had checked this before, but I just tried
> it now again. Not good news:
>
> opusa5:/sys/class/pwm/f0000660.timer:0# echo 1 > polarity
> opusa5:/sys/class/pwm/f0000660.timer:0# cat polarity
> 1
> opusa5:/sys/class/pwm/f0000660.timer:0# echo 0 > polarity
> opusa5:/sys/class/pwm/f0000660.timer:0# cat polarity
> 1
>
> Good catch. I'll have to track this one down. I have verified that the
> proper value gets out to the hardware, for all the existing drivers of
> my own, anyway. Some of my hardware simply won't work if the polarity
> is wrong.
I thought I noticed this issue with your original patches. Glad you
were able to verify it.
>>> +static ssize_t pwm_run_store(struct device *dev,
>>> + struct device_attribute *attr,
>>> + const char *buf,
>>> + size_t len)
>>> +{
>>> + struct pwm_channel *p = dev_get_drvdata(dev);
>>> + if (sysfs_streq(buf, "1"))
>>> + pwm_start(p);
>>> + else if (sysfs_streq(buf, "0"))
>>> + pwm_stop(p);
>>> + return len;
>>> +}
>>> +static DEVICE_ATTR(run, 0200, NULL, pwm_run_store);
>>>
>>
>> Any reason not to add a read operation?
>>
>
> Can't think of one. Just haven't had a need for it myself, I suppose.
Time will tell... It can easily be added later if needed.
>>> +static ssize_t pwm_request_store(struct device *dev,
>>> + struct device_attribute *attr,
>>> + const char *buf,
>>> + size_t len)
>>> +{
>>> + struct pwm_channel *p = dev_get_drvdata(dev);
>>> + pwm_free(p);
>>> + return len;
>>> +}
>>> +static DEVICE_ATTR(request, 0644, pwm_request_show, pwm_request_store);
>>
>>
>> Doing a read to request the channel and a write to free it seems wrong...
>>
>> I think you should be able to read the attr to get the current 'requester'
>> and write to it to set the 'requester'. Kind of like the 'trigger' attr
>> for the leds.
>>
>> Also, if a kernel driver has requested the pwm channel wouldn't a read
>> of the attr free it? This seems bad...
>>
>> Just my .02
>>
>
> A read from the attribute shows who the current requester is, and
> implies that if the channel isn't currently owned by anyone else then
> you'd like to own it. This approach makes the locking operation atomic
> in the (unlikely) situation where two user applications are going after
> the same PWM channel at the same time. It also means that I don't have
> to do a write, followed by a read and compare in order to determine if I
> now own the channel.
>
> If the channel is owned when you read the attribute, then the current
> owner is reported.
>
> I guess I can see an advantage to writing a unique text string to the
> attribute to indicate a request operation, and then reading back that
> same text string to confirm that you own the channel. And then you'd
> write a null string to un-request it, perhaps? Or would you have an
> un-request attribute?
Maybe change the attribute so that it works like the led trigger attribute.
The list of available requesters returned would be something like the
following:
If the pwm channel is free.
# cat request
[none] sysfs <- the channel is free
# echo sysfs > request <- request the channel for syfs use
# cat request
none [sysfs] <- sysfs now owns the channel
If the pwm channel is owned by a kernel driver, i.e. the pwm-led.c driver:
# cat request
[cur_led->name] <- the pwm-led driver owns the channel
I think the other attributes should also be removed then the channel is
owned by a kernel driver since that driver is actually in control of the
configuration. I'm not sure if this is possible.
Also, a better name for this attribute might be 'owner' or something along
that line.
As far as making the request atomic, a user application could always just
'request' the channel without checking if it's available first. If the
channel is unavailable the request could return an error back to user space.
The way it is now I think if a kernel driver were to request a channel,
a user app could rip it away by doing:
# cat request
cur_led->name <- the pwm-led driver owns the channel
# echo anything > request <- oops.. pwm_free just got called
# cat request
sysfs p->pid <- sysfs now owns the channel
>>> +#include <linux/completion.h>
>>> +#include <linux/workqueue.h>
>>> +#include <linux/spinlock.h>
>>> +#include <linux/list.h>
>>>
>>
>> Are these really needed in the header? Other than <linux/list.h>, they are
>> already included in the .c file.
>>
>
> They certainly aren't _needed_ in the header, unless someone forgets to
> include them before they include pwm.h. Any idea what the convention is
> on this?
I think it's cleaner to require the .c file to include the necessary headers.
The only reason I can see to have an include in a header is if there is a
strict dependancy on that header, and normally this can be avoided.
>>> +
>>> + int (*request) (struct pwm_channel *p);
>>> + void (*free) (struct pwm_channel *p);
>>> + int (*config) (struct pwm_channel *p,
>>> + struct pwm_channel_config *c);
>>> + int (*config_nosleep)(struct pwm_channel *p,
>>> + struct pwm_channel_config *c);
>>> + int (*synchronize) (struct pwm_channel *p,
>>> + struct pwm_channel *to_p);
>>> + int (*unsynchronize)(struct pwm_channel *p,
>>> + struct pwm_channel *from_p);
>>> + int (*set_callback) (struct pwm_channel *p,
>>> + pwm_callback_t callback);
>>>
>>
>> These might be cleaner without the line breaks.
>>
>
> Yea, they just get kinda long...
The longest is the (*config) one and it's 87 chars when pulled into
one line. That one, and a bunch of others, could be shortened by
changing the pwm_channel_config name to pwm_config.
BTW, there has been discussion and patches on lkml to increase
the 80 character line limit. Personaly I think it makes sense.
My laptop and desktop both have a 1920 horizontal res but my
Vertical res on the laptop is only 1080. I would much rather
read long, easy to read, lines and see more of them than read
short, broken, lines and see less of them. ;-)
>>> +struct pwm_channel *
>>> +pwm_request(const char *bus_id, int chan,
>>> + const char *requester);
>>>
>>
>> You use a mix of style in this patch set.
>>
>> <return type> <fn name> (...)
>>
>> and
>>
>> <return type>
>> <fn_name> (...)
>>
>> Makes reading a bit difficult. Could you make them consistent?
>>
>
> I'm trying to keep the lines from growing too long. But if you don't
> mind them long, I can deal with it. :)
Well, going with the above comment, making all of these one line each
makes them a lot easier to read and see what the API consists of.
Also, grouping the common ones together makes more sense than having
a white space between very function prototype, i.e.:
struct pwm_channel *pwm_request(...)
void pwm_free(...)
int pwm_config_nosleep(...)
int pwm_config(...)
unsigned long pwm_ns_to_ticks(...)
unsigned long pwm_ticks_to_ns(...)
int pwm_set_period_ns(...)
unsigned long int pwm_get_period_ns(...) <- BTW, the 'int' is redundant
int pwm_set_duty_ns(...)
unsigned long pwm_get_duty_ns(...)
int pwm_set_duty_percent(...)
int pwm_set_polarity(...)
int pwm_start(...)
int pwm_stop(...)
int pwm_set_handler(...)
int pwm_synchronize(...)
int pwm_unsynchronize(...)
>> Regards,
>> Hartley
>>
>
> Thanks sooo much for your reviews!
My pleasure to help.
Regards,
Hartley
^ permalink raw reply
* Re: [PWM PATCH 1/7] API to consolidate PWM devices behind a common user and kernel interface
From: Bill Gatliff @ 2010-02-10 13:55 UTC (permalink / raw)
To: H Hartley Sweeten; +Cc: linux-embedded, linux-kernel
In-Reply-To: <BD79186B4FD85F4B8E60E381CAEE190902153279@mi8nycmail19.Mi8.com>
H Hartley Sweeten wrote:
>> +int pwm_set_polarity(struct pwm_channel *p,
>> + int active_high)
>> +{
>> + struct pwm_channel_config c = {
>> + .config_mask = PWM_CONFIG_POLARITY,
>> + .polarity = active_high,
>> + };
>> + return pwm_config(p, &c);
>> +}
>> +EXPORT_SYMBOL(pwm_set_polarity);
>>
>
> Has the 'polarity' logic been verified?
>
> pwm_set_polarity takes an active high flag that is passed to pwm_config.
> A write to the sysfs 'polarity' file passes the value directly to pwm_config.
> A read from the sysfs 'polarity' file returns struct pwm_channel ->active_low.
>
> Seems like a mis-match in logic.
>
It was. And on top of that, none of the drivers were reflecting their
polarity in their pwm_channel structures.
I renamed the channel structure variable to active_high for consistency,
and updated each of the drivers to set that value consistent with their
actual polarities.
Very good catch.
b.g.
--
Bill Gatliff
Embedded systems training and consulting
http://billgatliff.com
bgat@billgatliff.com
^ permalink raw reply
* Re: [PWM PATCH 2/7] Emulates PWM hardware using a high-resolution timer and a GPIO pin
From: Bill Gatliff @ 2010-02-10 13:42 UTC (permalink / raw)
To: Stanislav O. Bezzubtsev; +Cc: linux-embedded, linux-kernel
In-Reply-To: <8B7FF140-BE6E-4AD1-86BC-161488675DFB@lvk.cs.msu.su>
Stanislav O. Bezzubtsev wrote:
>> +
>> +struct gpio_pwm {
>> + struct pwm_device pwm;
>> + struct hrtimer t;
>>
>
> Wouldn't a little bit longer name "timer" instead of simple "t" increase readability?
>
Couldn't hurt. Done.
>> +static void
>> +gpio_pwm_work (struct work_struct *work)
>> +{
>> + struct gpio_pwm *gp = container_of(work, struct gpio_pwm, work);
>> +
>> + if (gp->active)
>> + gpio_direction_output(gp->gpio, gp->polarity ? 1 : 0);
>> + else
>> + gpio_direction_output(gp->gpio, gp->polarity ? 0 : 1);
>>
>
> Maybe the following would be better:
> gpio_direction_output(gp->gpio, gp->polarity ^ gp->active)
> Instead of doing several comparisons.
>
... except that I'm trying to guarantee that only the values '1' or '0'
get sent to gpio_direction_output. There's nothing in the spec that
says other values are legal, although I'll admit that any nonzero value
is unlikely to cause problems. Should I be pedantic here?
>> +
>> + if (gp->active)
>> + hrtimer_start(&gp->t,
>> + ktime_set(0, gp->pwm.channels[0].duty_ticks),
>> + HRTIMER_MODE_REL);
>> + else
>> + hrtimer_start(&gp->t,
>> + ktime_set(0,gp->pwm.channels[0].period_ticks
>> + - gp->pwm.channels[0].duty_ticks),
>> + HRTIMER_MODE_REL);
>>
>
> if (gp->active)
> t = ktime_set(0, gp->pwm.channels[0].duty_ticks));
> else
> t = ktime_set(0, gp->pwm.channels[0].period_ticks - gp->pwm.channels[0].duty_ticks));
>
> htimer_start(&gp->t, t, HRTIMER_MODE_REL);
>
Excellent.
>> +
>> + ret = pwm_register(&gp->pwm);
>> + if (ret)
>> + goto err_pwm_register;
>> +
>> + return 0;
>> +
>> +err_pwm_register:
>>
>
> platform_set_drvdata(pdev, 0);
>
Good catch!
>> +static int __devexit
>> +gpio_pwm_remove(struct platform_device *pdev)
>> +{
>> + struct gpio_pwm *gp = platform_get_drvdata(pdev);
>> + int ret;
>> +
>> + ret = pwm_unregister(&gp->pwm);
>> + hrtimer_cancel(&gp->t);
>> + cancel_work_sync(&gp->work);
>>
>
> platform_set_drvdata(pdev, 0);
>
Ditto.
> And there are too much pr_debug & dev_dbg calls. Several of them are inside critical sections or in functions called from critical sections (inside spin_lock_irqsave - spin_lock_irqrestore block I mean). Don't think it is good.
>
Ok. Now that the code is relatively mature, they're unnecessary anyway.
b.g.
--
Bill Gatliff
Embedded systems training and consulting
http://billgatliff.com
bgat@billgatliff.com
^ permalink raw reply
* Re: [PWM PATCH 1/7] API to consolidate PWM devices behind a common user and kernel interface
From: Bill Gatliff @ 2010-02-10 4:18 UTC (permalink / raw)
To: H Hartley Sweeten; +Cc: linux-embedded, linux-kernel
In-Reply-To: <4B723239.4090802@billgatliff.com>
Bill Gatliff wrote:
>>> +
>>> + p->requester = requester;
>>> + if (!strcmp(requester, REQUEST_SYSFS))
>>> + p->pid = current->pid;
>>>
>>>
>> This is new.. What's the reason for saving the pid?
>>
>>
>
> I've gotten complaints from those who say, "Ok, so it reported 'sysfs'
> back to me, but how can I be sure that it's because *I* own it now, and
> not another user process?" Seemed easy enough to add the PID so they
> can check. Of course, you could argue that I could report just the PID,
> and skip the "sysfs" string altogether. I'd be inclined to agree with you.
>
> Of course, if you are like me and do the request with cat(1), then the
> PID is pretty meaningless. :)
>
For the record, this request activity is mostly advisory. I can't
actually implement something where only the requester is subsequently
allowed to manipulate the state of the channel. You really wouldn't
want to even if it was possible, because then you'd probably lose the
ability to control the output using cat(1) and echo(1).
I'm just trying to provide a tool that allows users to Play Nice if they
choose to. In fact, it's currently possible to manipulate the state of
the channel from userspace without requesting ownership first. Not sure
I'm happy with that, but since I can't enforce any sort of access
restrictions it seems pointless to even go so far as to require ownership...
b.g.
--
Bill Gatliff
Embedded systems training and consulting
http://billgatliff.com
bgat@billgatliff.com
^ permalink raw reply
* Re: [PWM PATCH 1/7] API to consolidate PWM devices behind a common user and kernel interface
From: Bill Gatliff @ 2010-02-10 4:12 UTC (permalink / raw)
To: H Hartley Sweeten; +Cc: linux-embedded, linux-kernel
In-Reply-To: <BD79186B4FD85F4B8E60E381CAEE190902153279@mi8nycmail19.Mi8.com>
H Hartley Sweeten wrote:
>> +
>> +static int __pwm_create_sysfs(struct pwm_device *pwm);
>> +
>> +static const char *REQUEST_SYSFS = "sysfs";
>>
>
> Does this static string save that much? It's only used two places in this
> file.
>
It makes sure the same string is used in both places. I do a strcmp on
it, so I wanted to make sure I didn't screw it up!
>> + p = kcalloc(pwm->nchan, sizeof(*p), GFP_KERNEL);
>> + if (!p)
>> + {
>> + pr_err("%s: ENOMEM\n", __func__);
>> + return -ENOMEM;
>> + }
>>
>
> I assume this pr_err is just a debug message and will be removed.
> If not the '{' should be on the previous line.
>
Yes, it's a debug message. I obviously don't clean up after myself very
well...
>> + list_add_tail(&pwm->list, &pwm_device_list);
>> + ret = __pwm_create_sysfs(pwm);
>> + if (ret) {
>> + mutex_unlock(&device_list_mutex);
>> + pr_err("%s: err_create_sysfs\n", __func__);
>>
>
> Another debug message?
>
Yes. Darn it. :)
>> + goto err_create_sysfs;
>> + }
>> +
>> + mutex_unlock(&device_list_mutex);
>> +
>> + dev_info(pwm->dev, "%d channel%s\n", pwm->nchan,
>> + pwm->nchan > 1 ? "s" : "");
>> + return 0;
>>
>
> I need to check the rest of the patch series but I assume you have
> fixed the pwm->dev = NULL issue.
>
Yes. Tested it properly, even! :)
>> +
>> + p->requester = requester;
>> + if (!strcmp(requester, REQUEST_SYSFS))
>> + p->pid = current->pid;
>>
>
> This is new.. What's the reason for saving the pid?
>
I've gotten complaints from those who say, "Ok, so it reported 'sysfs'
back to me, but how can I be sure that it's because *I* own it now, and
not another user process?" Seemed easy enough to add the PID so they
can check. Of course, you could argue that I could report just the PID,
and skip the "sysfs" string altogether. I'd be inclined to agree with you.
Of course, if you are like me and do the request with cat(1), then the
PID is pretty meaningless. :)
>> +
>> +int pwm_set_polarity(struct pwm_channel *p,
>> + int active_high)
>> +{
>> + struct pwm_channel_config c = {
>> + .config_mask = PWM_CONFIG_POLARITY,
>> + .polarity = active_high,
>> + };
>> + return pwm_config(p, &c);
>> +}
>> +EXPORT_SYMBOL(pwm_set_polarity);
>>
>
> Has the 'polarity' logic been verified?
>
> pwm_set_polarity takes an active high flag that is passed to pwm_config.
> A write to the sysfs 'polarity' file passes the value directly to pwm_config.
> A read from the sysfs 'polarity' file returns struct pwm_channel ->active_low.
>
> Seems like a mis-match in logic.
>
It does, indeed! I thought I had checked this before, but I just tried
it now again. Not good news:
opusa5:/sys/class/pwm/f0000660.timer:0# echo 1 > polarity
opusa5:/sys/class/pwm/f0000660.timer:0# cat polarity
1
opusa5:/sys/class/pwm/f0000660.timer:0# echo 0 > polarity
opusa5:/sys/class/pwm/f0000660.timer:0# cat polarity
1
Good catch. I'll have to track this one down. I have verified that the
proper value gets out to the hardware, for all the existing drivers of
my own, anyway. Some of my hardware simply won't work if the polarity
is wrong.
>> +static ssize_t pwm_run_store(struct device *dev,
>> + struct device_attribute *attr,
>> + const char *buf,
>> + size_t len)
>> +{
>> + struct pwm_channel *p = dev_get_drvdata(dev);
>> + if (sysfs_streq(buf, "1"))
>> + pwm_start(p);
>> + else if (sysfs_streq(buf, "0"))
>> + pwm_stop(p);
>> + return len;
>> +}
>> +static DEVICE_ATTR(run, 0200, NULL, pwm_run_store);
>>
>
> Any reason not to add a read operation?
>
Can't think of one. Just haven't had a need for it myself, I suppose.
>> +static ssize_t pwm_request_store(struct device *dev,
>> + struct device_attribute *attr,
>> + const char *buf,
>> + size_t len)
>> +{
>> + struct pwm_channel *p = dev_get_drvdata(dev);
>> + pwm_free(p);
>> + return len;
>> +}
>> +static DEVICE_ATTR(request, 0644, pwm_request_show, pwm_request_store);
>>
>
> Doing a read to request the channel and a write to free it seems wrong...
>
> I think you should be able to read the attr to get the current 'requester'
> and write to it to set the 'requester'. Kind of like the 'trigger' attr
> for the leds.
>
> Also, if a kernel driver has requested the pwm channel wouldn't a read
> of the attr free it? This seems bad...
>
> Just my .02
>
A read from the attribute shows who the current requester is, and
implies that if the channel isn't currently owned by anyone else then
you'd like to own it. This approach makes the locking operation atomic
in the (unlikely) situation where two user applications are going after
the same PWM channel at the same time. It also means that I don't have
to do a write, followed by a read and compare in order to determine if I
now own the channel.
If the channel is owned when you read the attribute, then the current
owner is reported.
I guess I can see an advantage to writing a unique text string to the
attribute to indicate a request operation, and then reading back that
same text string to confirm that you own the channel. And then you'd
write a null string to un-request it, perhaps? Or would you have an
un-request attribute?
>> +#include <linux/completion.h>
>> +#include <linux/workqueue.h>
>> +#include <linux/spinlock.h>
>> +#include <linux/list.h>
>>
>
> Are these really needed in the header? Other than <linux/list.h>, they are
> already included in the .c file.
>
They certainly aren't _needed_ in the header, unless someone forgets to
include them before they include pwm.h. Any idea what the convention is
on this?
>> +
>> + int (*request) (struct pwm_channel *p);
>> + void (*free) (struct pwm_channel *p);
>> + int (*config) (struct pwm_channel *p,
>> + struct pwm_channel_config *c);
>> + int (*config_nosleep)(struct pwm_channel *p,
>> + struct pwm_channel_config *c);
>> + int (*synchronize) (struct pwm_channel *p,
>> + struct pwm_channel *to_p);
>> + int (*unsynchronize)(struct pwm_channel *p,
>> + struct pwm_channel *from_p);
>> + int (*set_callback) (struct pwm_channel *p,
>> + pwm_callback_t callback);
>>
>
> These might be cleaner without the line breaks.
>
Yea, they just get kinda long...
>> +struct pwm_channel *
>> +pwm_request(const char *bus_id, int chan,
>> + const char *requester);
>>
>
> You use a mix of style in this patch set.
>
> <return type> <fn name> (...)
>
> and
>
> <return type>
> <fn_name> (...)
>
> Makes reading a bit difficult. Could you make them consistent?
>
I'm trying to keep the lines from growing too long. But if you don't
mind them long, I can deal with it. :)
> Regards,
> Hartley
>
Thanks sooo much for your reviews!
b.g.
--
Bill Gatliff
Embedded systems training and consulting
http://billgatliff.com
bgat@billgatliff.com
^ permalink raw reply
* RE: [PWM PATCH 1/7] API to consolidate PWM devices behind a common user and kernel interface
From: H Hartley Sweeten @ 2010-02-10 2:41 UTC (permalink / raw)
To: Bill Gatliff, linux-embedded; +Cc: linux-kernel
In-Reply-To: <b7afd475c3fce08f459bceff7814de57ffce7bd0.1265748264.git.bgat@billgatliff.com>
On Tuesday, February 09, 2010 1:46 PM, Bill Gatliff wrote:
> Signed-off-by: Bill Gatliff <bgat@billgatliff.com>
> ---
> Documentation/pwm.txt | 260 +++++++++++++++++++
> drivers/pwm/pwm.c | 644 +++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/pwm.h | 31 ---
> include/linux/pwm/pwm.h | 170 +++++++++++++
> 4 files changed, 1074 insertions(+), 31 deletions(-)
> create mode 100644 Documentation/pwm.txt
> create mode 100644 drivers/pwm/pwm.c
> delete mode 100644 include/linux/pwm.h
> create mode 100644 include/linux/pwm/pwm.h
Bill,
I'll take a look at the Documentation later.
Couple quick comments below.
[snip]
> diff --git a/drivers/pwm/pwm.c b/drivers/pwm/pwm.c
> new file mode 100644
> index 0000000..40378cb
> --- /dev/null
> +++ b/drivers/pwm/pwm.c
> @@ -0,0 +1,644 @@
> +/*
> + * drivers/pwm/pwm.c
> + *
> + * Copyright (C) 2010 Bill Gatliff <bgat@billgatliff.com>
> + *
> + * This program is free software; you may redistribute and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
> + * USA
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/device.h>
> +#include <linux/spinlock.h>
> +#include <linux/fs.h>
> +#include <linux/completion.h>
> +#include <linux/workqueue.h>
> +#include <linux/pwm/pwm.h>
#include <linux/list.h>
> +
> +static int __pwm_create_sysfs(struct pwm_device *pwm);
> +
> +static const char *REQUEST_SYSFS = "sysfs";
Does this static string save that much? It's only used two places in this
file.
> +static LIST_HEAD(pwm_device_list);
> +static DEFINE_MUTEX(device_list_mutex);
> +static struct class pwm_class;
> +static struct workqueue_struct *pwm_handler_workqueue;
> +
> +int pwm_register(struct pwm_device *pwm)
> +{
> + struct pwm_channel *p;
> + int wchan;
> + int ret;
> +
> + spin_lock_init(&pwm->list_lock);
> +
> + p = kcalloc(pwm->nchan, sizeof(*p), GFP_KERNEL);
> + if (!p)
> + {
> + pr_err("%s: ENOMEM\n", __func__);
> + return -ENOMEM;
> + }
I assume this pr_err is just a debug message and will be removed.
If not the '{' should be on the previous line.
> +
> + for (wchan = 0; wchan < pwm->nchan; wchan++) {
> + spin_lock_init(&p[wchan].lock);
> + init_completion(&p[wchan].complete);
> + p[wchan].chan = wchan;
> + p[wchan].pwm = pwm;
> + }
> +
> + pwm->channels = p;
> +
> + mutex_lock(&device_list_mutex);
> +
> + list_add_tail(&pwm->list, &pwm_device_list);
> + ret = __pwm_create_sysfs(pwm);
> + if (ret) {
> + mutex_unlock(&device_list_mutex);
> + pr_err("%s: err_create_sysfs\n", __func__);
Another debug message?
> + goto err_create_sysfs;
> + }
> +
> + mutex_unlock(&device_list_mutex);
> +
> + dev_info(pwm->dev, "%d channel%s\n", pwm->nchan,
> + pwm->nchan > 1 ? "s" : "");
> + return 0;
I need to check the rest of the patch series but I assume you have
fixed the pwm->dev = NULL issue.
> +
> +err_create_sysfs:
> + kfree(p);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(pwm_register);
> +
> +static int __match_device(struct device *dev, void *data)
> +{
> + return dev_get_drvdata(dev) == data;
> +}
> +
> +int pwm_unregister(struct pwm_device *pwm)
> +{
> + int wchan;
> + struct device *dev;
> +
> + mutex_lock(&device_list_mutex);
> +
> + for (wchan = 0; wchan < pwm->nchan; wchan++) {
> + if (pwm->channels[wchan].flags & BIT(FLAG_REQUESTED)) {
> + mutex_unlock(&device_list_mutex);
> + return -EBUSY;
> + }
> + }
> +
> + for (wchan = 0; wchan < pwm->nchan; wchan++) {
> + dev = class_find_device(&pwm_class, NULL,
> + &pwm->channels[wchan],
> + __match_device);
> + if (dev) {
> + put_device(dev);
> + device_unregister(dev);
> + }
> + }
> +
> + kfree(pwm->channels);
> + list_del(&pwm->list);
> + mutex_unlock(&device_list_mutex);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(pwm_unregister);
> +
> +static struct pwm_device *
> +__pwm_find_device(const char *bus_id)
> +{
> + struct pwm_device *p;
> +
> + list_for_each_entry(p, &pwm_device_list, list) {
> + if (!strcmp(bus_id, p->bus_id))
> + return p;
> + }
> + return NULL;
> +}
> +
> +static int
> +__pwm_request_channel(struct pwm_channel *p,
> + const char *requester)
> +{
> + int ret;
> +
> + if (test_and_set_bit(FLAG_REQUESTED, &p->flags))
> + return -EBUSY;
> +
> + if (p->pwm->request) {
> + ret = p->pwm->request(p);
> + if (ret) {
> + clear_bit(FLAG_REQUESTED, &p->flags);
> + return ret;
> + }
> + }
> +
> + p->requester = requester;
> + if (!strcmp(requester, REQUEST_SYSFS))
> + p->pid = current->pid;
This is new.. What's the reason for saving the pid?
> +
> + return 0;
> +}
> +
> +struct pwm_channel *
> +pwm_request(const char *bus_id,
> + int chan,
> + const char *requester)
> +{
> + struct pwm_device *p;
> + int ret;
> +
> + mutex_lock(&device_list_mutex);
> +
> + p = __pwm_find_device(bus_id);
> + if (!p || chan >= p->nchan)
> + goto err_no_device;
> +
> + if (!try_module_get(p->owner))
> + goto err_module_get_failed;
> +
> + ret = __pwm_request_channel(&p->channels[chan], requester);
> + if (ret)
> + goto err_request_failed;
> +
> + mutex_unlock(&device_list_mutex);
> + return &p->channels[chan];
> +
> +err_request_failed:
> + module_put(p->owner);
> +err_module_get_failed:
> +err_no_device:
> + mutex_unlock(&device_list_mutex);
> + return NULL;
> +}
> +EXPORT_SYMBOL(pwm_request);
> +
> +void pwm_free(struct pwm_channel *p)
> +{
> + mutex_lock(&device_list_mutex);
> +
> + if (!test_and_clear_bit(FLAG_REQUESTED, &p->flags))
> + goto done;
> +
> + pwm_stop(p);
> + pwm_unsynchronize(p, NULL);
> + pwm_set_handler(p, NULL, NULL);
> +
> + if (p->pwm->free)
> + p->pwm->free(p);
> + module_put(p->pwm->owner);
> +done:
> + mutex_unlock(&device_list_mutex);
> +}
> +EXPORT_SYMBOL(pwm_free);
> +
> +unsigned long pwm_ns_to_ticks(struct pwm_channel *p,
> + unsigned long nsecs)
> +{
> + unsigned long long ticks;
> +
> + ticks = nsecs;
> + ticks *= p->tick_hz;
> + do_div(ticks, 1000000000);
> + return ticks;
> +}
> +EXPORT_SYMBOL(pwm_ns_to_ticks);
> +
> +unsigned long pwm_ticks_to_ns(struct pwm_channel *p,
> + unsigned long ticks)
> +{
> + unsigned long long ns;
> +
> + if (!p->tick_hz)
> + return 0;
> +
> + ns = ticks;
> + ns *= 1000000000UL;
> + do_div(ns, p->tick_hz);
> + return ns;
> +}
> +EXPORT_SYMBOL(pwm_ticks_to_ns);
> +
> +static void
> +pwm_config_ns_to_ticks(struct pwm_channel *p,
> + struct pwm_channel_config *c)
> +{
> + if (c->config_mask & PWM_CONFIG_PERIOD_NS) {
> + c->period_ticks = pwm_ns_to_ticks(p, c->period_ns);
> + c->config_mask &= ~PWM_CONFIG_PERIOD_NS;
> + c->config_mask |= PWM_CONFIG_PERIOD_TICKS;
> + }
> +
> + if (c->config_mask & PWM_CONFIG_DUTY_NS) {
> + c->duty_ticks = pwm_ns_to_ticks(p, c->duty_ns);
> + c->config_mask &= ~PWM_CONFIG_DUTY_NS;
> + c->config_mask |= PWM_CONFIG_DUTY_TICKS;
> + }
> +}
> +
> +static void
> +pwm_config_percent_to_ticks(struct pwm_channel *p,
> + struct pwm_channel_config *c)
> +{
> + if (c->config_mask & PWM_CONFIG_DUTY_PERCENT) {
> + if (c->config_mask & PWM_CONFIG_PERIOD_TICKS)
> + c->duty_ticks = c->period_ticks;
> + else
> + c->duty_ticks = p->period_ticks;
> +
> + c->duty_ticks *= c->duty_percent;
> + c->duty_ticks /= 100;
> + c->config_mask &= ~PWM_CONFIG_DUTY_PERCENT;
> + c->config_mask |= PWM_CONFIG_DUTY_TICKS;
> + }
> +}
> +
> +int pwm_config_nosleep(struct pwm_channel *p,
> + struct pwm_channel_config *c)
> +{
> + if (!p->pwm->config_nosleep)
> + return -EINVAL;
> +
> + pwm_config_ns_to_ticks(p, c);
> + pwm_config_percent_to_ticks(p, c);
> +
> + return p->pwm->config_nosleep(p, c);
> +}
> +EXPORT_SYMBOL(pwm_config_nosleep);
> +
> +int pwm_config(struct pwm_channel *p,
> + struct pwm_channel_config *c)
> +{
> + int ret = 0;
> +
> + if (unlikely(!p->pwm->config))
> + return -EINVAL;
> +
> + pwm_config_ns_to_ticks(p, c);
> + pwm_config_percent_to_ticks(p, c);
> +
> + switch (c->config_mask & (PWM_CONFIG_PERIOD_TICKS
> + | PWM_CONFIG_DUTY_TICKS)) {
> + case PWM_CONFIG_PERIOD_TICKS:
> + if (p->duty_ticks > c->period_ticks) {
> + ret = -EINVAL;
> + goto err;
> + }
> + break;
> + case PWM_CONFIG_DUTY_TICKS:
> + if (p->period_ticks < c->duty_ticks) {
> + ret = -EINVAL;
> + goto err;
> + }
> + break;
> + case PWM_CONFIG_DUTY_TICKS | PWM_CONFIG_PERIOD_TICKS:
> + if (c->duty_ticks > c->period_ticks) {
> + ret = -EINVAL;
> + goto err;
> + }
> + break;
> + default:
> + break;
> + }
> +
> +err:
> + dev_dbg(p->pwm->dev, "%s: config_mask %d period_ticks %lu duty_ticks %lu"
> + " polarity %d duty_ns %lu period_ns %lu duty_percent %d\n",
> + __func__, c->config_mask, c->period_ticks, c->duty_ticks,
> + c->polarity, c->duty_ns, c->period_ns, c->duty_percent);
> +
> + if (ret)
> + return ret;
> + return p->pwm->config(p, c);
> +}
> +EXPORT_SYMBOL(pwm_config);
> +
> +int pwm_set_period_ns(struct pwm_channel *p,
> + unsigned long period_ns)
> +{
> + struct pwm_channel_config c = {
> + .config_mask = PWM_CONFIG_PERIOD_TICKS,
> + .period_ticks = pwm_ns_to_ticks(p, period_ns),
> + };
> +
> + return pwm_config(p, &c);
> +}
> +EXPORT_SYMBOL(pwm_set_period_ns);
> +
> +unsigned long pwm_get_period_ns(struct pwm_channel *p)
> +{
> + return pwm_ticks_to_ns(p, p->period_ticks);
> +}
> +EXPORT_SYMBOL(pwm_get_period_ns);
> +
> +int pwm_set_duty_ns(struct pwm_channel *p,
> + unsigned long duty_ns)
> +{
> + struct pwm_channel_config c = {
> + .config_mask = PWM_CONFIG_DUTY_TICKS,
> + .duty_ticks = pwm_ns_to_ticks(p, duty_ns),
> + };
> + return pwm_config(p, &c);
> +}
> +EXPORT_SYMBOL(pwm_set_duty_ns);
> +
> +unsigned long pwm_get_duty_ns(struct pwm_channel *p)
> +{
> + return pwm_ticks_to_ns(p, p->duty_ticks);
> +}
> +EXPORT_SYMBOL(pwm_get_duty_ns);
> +
> +int pwm_set_duty_percent(struct pwm_channel *p,
> + int percent)
> +{
> + struct pwm_channel_config c = {
> + .config_mask = PWM_CONFIG_DUTY_PERCENT,
> + .duty_percent = percent,
> + };
> + return pwm_config(p, &c);
> +}
> +EXPORT_SYMBOL(pwm_set_duty_percent);
> +
> +int pwm_set_polarity(struct pwm_channel *p,
> + int active_high)
> +{
> + struct pwm_channel_config c = {
> + .config_mask = PWM_CONFIG_POLARITY,
> + .polarity = active_high,
> + };
> + return pwm_config(p, &c);
> +}
> +EXPORT_SYMBOL(pwm_set_polarity);
Has the 'polarity' logic been verified?
pwm_set_polarity takes an active high flag that is passed to pwm_config.
A write to the sysfs 'polarity' file passes the value directly to pwm_config.
A read from the sysfs 'polarity' file returns struct pwm_channel ->active_low.
Seems like a mis-match in logic.
> +
> +int pwm_start(struct pwm_channel *p)
> +{
> + struct pwm_channel_config c = {
> + .config_mask = PWM_CONFIG_START,
> + };
> + return pwm_config(p, &c);
> +}
> +EXPORT_SYMBOL(pwm_start);
> +
> +int pwm_stop(struct pwm_channel *p)
> +{
> + struct pwm_channel_config c = {
> + .config_mask = PWM_CONFIG_STOP,
> + };
> + return pwm_config(p, &c);
> +}
> +EXPORT_SYMBOL(pwm_stop);
> +
> +int pwm_synchronize(struct pwm_channel *p,
> + struct pwm_channel *to_p)
> +{
> + if (p->pwm != to_p->pwm) {
> + /* TODO: support cross-device synchronization */
> + return -EINVAL;
> + }
> +
> + if (!p->pwm->synchronize)
> + return -EINVAL;
> +
> + return p->pwm->synchronize(p, to_p);
> +}
> +EXPORT_SYMBOL(pwm_synchronize);
> +
> +int pwm_unsynchronize(struct pwm_channel *p,
> + struct pwm_channel *from_p)
> +{
> + if (from_p && (p->pwm != from_p->pwm)) {
> + /* TODO: support cross-device synchronization */
> + return -EINVAL;
> + }
> +
> + if (!p->pwm->unsynchronize)
> + return -EINVAL;
> +
> + return p->pwm->unsynchronize(p, from_p);
> +}
> +EXPORT_SYMBOL(pwm_unsynchronize);
> +
> +static void pwm_handler(struct work_struct *w)
> +{
> + struct pwm_channel *p = container_of(w, struct pwm_channel,
> + handler_work);
> + if (p->handler && p->handler(p, p->handler_data))
> + pwm_stop(p);
> +}
> +
> +static void __pwm_callback(struct pwm_channel *p)
> +{
> + queue_work(pwm_handler_workqueue, &p->handler_work);
> + dev_dbg(p->pwm->dev, "handler %p scheduled with data %p\n",
> + p->handler, p->handler_data);
> +}
> +
> +int pwm_set_handler(struct pwm_channel *p,
> + pwm_handler_t handler,
> + void *data)
> +{
> + if (p->pwm->set_callback) {
> + p->handler_data = data;
> + p->handler = handler;
> + INIT_WORK(&p->handler_work, pwm_handler);
> + return p->pwm->set_callback(p, handler ? __pwm_callback : NULL);
> + }
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL(pwm_set_handler);
> +
> +static ssize_t pwm_run_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t len)
> +{
> + struct pwm_channel *p = dev_get_drvdata(dev);
> + if (sysfs_streq(buf, "1"))
> + pwm_start(p);
> + else if (sysfs_streq(buf, "0"))
> + pwm_stop(p);
> + return len;
> +}
> +static DEVICE_ATTR(run, 0200, NULL, pwm_run_store);
Any reason not to add a read operation?
> +
> +static ssize_t pwm_duty_ns_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct pwm_channel *p = dev_get_drvdata(dev);
> + return sprintf(buf, "%lu\n", pwm_get_duty_ns(p));
> +}
> +
> +static ssize_t pwm_duty_ns_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t len)
> +{
> + unsigned long duty_ns;
> + struct pwm_channel *p = dev_get_drvdata(dev);
> +
> + if (1 == sscanf(buf, "%lu", &duty_ns))
> + pwm_set_duty_ns(p, duty_ns);
> + return len;
> +}
> +static DEVICE_ATTR(duty_ns, 0644, pwm_duty_ns_show, pwm_duty_ns_store);
> +
> +static ssize_t pwm_period_ns_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct pwm_channel *p = dev_get_drvdata(dev);
> + return sprintf(buf, "%lu\n", pwm_get_period_ns(p));
> +}
> +
> +static ssize_t pwm_period_ns_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t len)
> +{
> + unsigned long period_ns;
> + struct pwm_channel *p = dev_get_drvdata(dev);
> +
> + if (1 == sscanf(buf, "%lu", &period_ns))
> + pwm_set_period_ns(p, period_ns);
> + return len;
> +}
> +static DEVICE_ATTR(period_ns, 0644, pwm_period_ns_show, pwm_period_ns_store);
> +
> +static ssize_t pwm_polarity_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct pwm_channel *p = dev_get_drvdata(dev);
> + return sprintf(buf, "%d\n", p->active_low ? 0 : 1);
> +}
> +
> +static ssize_t pwm_polarity_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t len)
> +{
> + int polarity;
> + struct pwm_channel *p = dev_get_drvdata(dev);
> +
> + if (1 == sscanf(buf, "%d", &polarity))
> + pwm_set_polarity(p, polarity);
> + return len;
> +}
> +static DEVICE_ATTR(polarity, 0644, pwm_polarity_show, pwm_polarity_store);
> +
> +static ssize_t pwm_request_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct pwm_channel *p = dev_get_drvdata(dev);
> + mutex_lock(&device_list_mutex);
> + __pwm_request_channel(p, REQUEST_SYSFS);
> + mutex_unlock(&device_list_mutex);
> +
> + if (p->pid)
> + return sprintf(buf, "%s %d\n", p->requester, p->pid);
> + else
> + return sprintf(buf, "%s\n", p->requester);
> +}
> +
> +static ssize_t pwm_request_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t len)
> +{
> + struct pwm_channel *p = dev_get_drvdata(dev);
> + pwm_free(p);
> + return len;
> +}
> +static DEVICE_ATTR(request, 0644, pwm_request_show, pwm_request_store);
Doing a read to request the channel and a write to free it seems wrong...
I think you should be able to read the attr to get the current 'requester'
and write to it to set the 'requester'. Kind of like the 'trigger' attr
for the leds.
Also, if a kernel driver has requested the pwm channel wouldn't a read
of the attr free it? This seems bad...
Just my .02
> +
> +static const struct attribute *pwm_attrs[] =
> +{
> + &dev_attr_run.attr,
> + &dev_attr_polarity.attr,
> + &dev_attr_duty_ns.attr,
> + &dev_attr_period_ns.attr,
> + &dev_attr_request.attr,
> + NULL,
> +};
> +
> +static const struct attribute_group pwm_device_attr_group = {
> + .attrs = (struct attribute **)pwm_attrs,
> +};
> +
> +static int __pwm_create_sysfs(struct pwm_device *pwm)
> +{
> + int ret = 0;
> + struct device *dev;
> + int wchan;
> +
> + for (wchan = 0; wchan < pwm->nchan; wchan++) {
> + dev = device_create(&pwm_class, pwm->dev, MKDEV(0, 0),
> + pwm->channels + wchan,
> + "%s:%d", pwm->bus_id, wchan);
> + if (!dev)
> + goto err_dev_create;
> + ret = sysfs_create_group(&dev->kobj, &pwm_device_attr_group);
> + if (ret)
> + goto err_dev_create;
> + }
> +
> + return ret;
> +
> +err_dev_create:
> + for (wchan = 0; wchan < pwm->nchan; wchan++) {
> + dev = class_find_device(&pwm_class, NULL,
> + &pwm->channels[wchan],
> + __match_device);
> + if (dev) {
> + put_device(dev);
> + device_unregister(dev);
> + }
> + }
> +
> + return ret;
> +}
> +
> +static struct class_attribute pwm_class_attrs[] = {
> + __ATTR_NULL,
> +};
> +
> +static struct class pwm_class = {
> + .name = "pwm",
> + .owner = THIS_MODULE,
> +
> + .class_attrs = pwm_class_attrs,
> +};
> +
> +static int __init pwm_init(void)
> +{
> + int ret;
> +
> + /* TODO: how to deal with devices that register very early? */
> + pr_err("%s\n", __func__);
> + ret = class_register(&pwm_class);
> + if (ret < 0)
> + return ret;
> +
> + pwm_handler_workqueue = create_workqueue("pwmd");
> +
> + return 0;
> +}
> +postcore_initcall(pwm_init);
> diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> deleted file mode 100644
> index 7c77575..0000000
> --- a/include/linux/pwm.h
> +++ /dev/null
[snip]
> diff --git a/include/linux/pwm/pwm.h b/include/linux/pwm/pwm.h
> new file mode 100644
> index 0000000..ec40774
> --- /dev/null
> +++ b/include/linux/pwm/pwm.h
> @@ -0,0 +1,170 @@
> +/*
> + * include/linux/pwm.h
> + *
> + * Copyright (C) 2008 Bill Gatliff < bgat@billgatliff.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + */
> +#ifndef __LINUX_PWM_H
> +#define __LINUX_PWM_H
> +
> +#include <linux/completion.h>
> +#include <linux/workqueue.h>
> +#include <linux/spinlock.h>
> +#include <linux/list.h>
Are these really needed in the header? Other than <linux/list.h>, they are
already included in the .c file.
> +
> +enum {
> + PWM_CONFIG_DUTY_TICKS = BIT(0),
> + PWM_CONFIG_PERIOD_TICKS = BIT(1),
> + PWM_CONFIG_POLARITY = BIT(2),
> + PWM_CONFIG_START = BIT(3),
> + PWM_CONFIG_STOP = BIT(4),
> +
> + PWM_CONFIG_HANDLER = BIT(5),
> +
> + PWM_CONFIG_DUTY_NS = BIT(6),
> + PWM_CONFIG_DUTY_PERCENT = BIT(7),
> + PWM_CONFIG_PERIOD_NS = BIT(8),
> +};
> +
> +struct pwm_channel;
> +struct work_struct;
> +
> +typedef int (*pwm_handler_t)(struct pwm_channel *p, void *data);
> +typedef void (*pwm_callback_t)(struct pwm_channel *p);
> +
> +struct pwm_channel_config {
> + int config_mask;
> + unsigned long duty_ticks;
> + unsigned long period_ticks;
> + int polarity;
> +
> + pwm_handler_t handler;
> +
> + unsigned long duty_ns;
> + unsigned long period_ns;
> + int duty_percent;
> +};
> +
> +struct pwm_device {
> + struct list_head list;
> + spinlock_t list_lock;
> + struct device *dev;
> + struct module *owner;
> + struct pwm_channel *channels;
> +
> + const char *bus_id;
> + int nchan;
> +
> + int (*request) (struct pwm_channel *p);
> + void (*free) (struct pwm_channel *p);
> + int (*config) (struct pwm_channel *p,
> + struct pwm_channel_config *c);
> + int (*config_nosleep)(struct pwm_channel *p,
> + struct pwm_channel_config *c);
> + int (*synchronize) (struct pwm_channel *p,
> + struct pwm_channel *to_p);
> + int (*unsynchronize)(struct pwm_channel *p,
> + struct pwm_channel *from_p);
> + int (*set_callback) (struct pwm_channel *p,
> + pwm_callback_t callback);
These might be cleaner without the line breaks.
> +};
> +
> +int pwm_register(struct pwm_device *pwm);
> +int pwm_unregister(struct pwm_device *pwm);
> +
> +enum {
> + FLAG_REQUESTED = 0,
> + FLAG_STOP = 1,
> +};
> +
> +struct pwm_channel {
> + struct list_head list;
> + struct pwm_device *pwm;
> + const char *requester;
> + pid_t pid;
> + int chan;
> + unsigned long flags;
> + unsigned long tick_hz;
> +
> + spinlock_t lock;
> + struct completion complete;
> +
> + pwm_callback_t callback;
> +
> + struct work_struct handler_work;
> + pwm_handler_t handler;
> + void *handler_data;
> +
> + int active_low;
> + unsigned long period_ticks;
> + unsigned long duty_ticks;
> +};
> +
> +struct gpio_pwm_platform_data {
> + int gpio;
> +};
> +
> +struct pwm_channel *
> +pwm_request(const char *bus_id, int chan,
> + const char *requester);
You use a mix of style in this patch set.
<return type> <fn name> (...)
and
<return type>
<fn_name> (...)
Makes reading a bit difficult. Could you make them consistent?
> +
> +void pwm_free(struct pwm_channel *pwm);
> +
> +int pwm_config_nosleep(struct pwm_channel *pwm,
> + struct pwm_channel_config *c);
> +
> +int pwm_config(struct pwm_channel *pwm,
> + struct pwm_channel_config *c);
> +
> +unsigned long pwm_ns_to_ticks(struct pwm_channel *pwm,
> + unsigned long nsecs);
> +
> +unsigned long pwm_ticks_to_ns(struct pwm_channel *pwm,
> + unsigned long ticks);
> +
> +int pwm_set_period_ns(struct pwm_channel *pwm,
> + unsigned long period_ns);
> +
> +unsigned long int pwm_get_period_ns(struct pwm_channel *pwm);
> +
> +int pwm_set_duty_ns(struct pwm_channel *pwm,
> + unsigned long duty_ns);
> +
> +int pwm_set_duty_percent(struct pwm_channel *pwm,
> + int percent);
> +
> +unsigned long pwm_get_duty_ns(struct pwm_channel *pwm);
> +
> +int pwm_set_polarity(struct pwm_channel *pwm,
> + int active_high);
> +
> +int pwm_start(struct pwm_channel *pwm);
> +
> +int pwm_stop(struct pwm_channel *pwm);
> +
> +int pwm_set_handler(struct pwm_channel *pwm,
> + pwm_handler_t handler,
> + void *data);
> +
> +int pwm_synchronize(struct pwm_channel *p,
> + struct pwm_channel *to_p);
> +
> +
> +int pwm_unsynchronize(struct pwm_channel *p,
> + struct pwm_channel *from_p);
> +
> +
> +#endif /* __LINUX_PWM_H */
Regards,
Hartley
^ permalink raw reply
* [PWM PATCH 7/7] PWM API driver for MPC52xx GPT peripheral
From: Bill Gatliff @ 2010-02-09 20:46 UTC (permalink / raw)
To: linux-embedded; +Cc: linux-kernel, Bill Gatliff
In-Reply-To: <cover.1265748263.git.bgat@billgatliff.com>
Signed-off-by: Bill Gatliff <bgat@billgatliff.com>
---
arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 195 ++++++++++++++++++++++++++++-
1 files changed, 193 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
index 6f8ebe1..b9aa4a5 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -1,6 +1,7 @@
/*
* MPC5200 General Purpose Timer device driver
*
+ * Copyright (c) 2010 Bill Gatliff <bgat@billgatliff.com>
* Copyright (c) 2009 Secret Lab Technologies Ltd.
* Copyright (c) 2008 Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix
*
@@ -50,6 +51,12 @@
* IO, or it can be an Open Collector (OC) output. At the moment it is the
* responsibility of either the bootloader or the platform setup code to set
* the output mode. This driver does not change the output mode setting.
+ *
+ * To use the PWM function, the following property must be added to
+ * the device tree node for the gpt device:
+ * pwm-controller;
+ * TODO: we could set polarity, initial period and duty cycle, on/off,
+ * and whatnot inside the dts file...
*/
#include <linux/device.h>
@@ -65,11 +72,12 @@
#include <linux/watchdog.h>
#include <linux/miscdevice.h>
#include <linux/uaccess.h>
+#include <linux/pwm/pwm.h>
#include <asm/div64.h>
#include <asm/mpc52xx.h>
MODULE_DESCRIPTION("Freescale MPC52xx gpt driver");
-MODULE_AUTHOR("Sascha Hauer, Grant Likely, Albrecht Dreß");
+MODULE_AUTHOR("Sascha Hauer, Grant Likely, Albrecht Dreß, Bill Gatliff");
MODULE_LICENSE("GPL");
/**
@@ -95,6 +103,9 @@ struct mpc52xx_gpt_priv {
#if defined(CONFIG_GPIOLIB)
struct of_gpio_chip of_gc;
#endif
+#if defined(CONFIG_GENERIC_PWM)
+ struct pwm_device pwm;
+#endif
};
LIST_HEAD(mpc52xx_gpt_list);
@@ -125,6 +136,10 @@ DEFINE_MUTEX(mpc52xx_gpt_list_mutex);
#define MPC52xx_GPT_STATUS_IRQMASK (0x000f)
+#define MPC52xx_GPT_PWM_WIDTH_MASK (0xffff0000)
+#define MPC52xx_GPT_PWM_PWMOP (0x100)
+#define MPC52xx_GPT_PWM_LOAD (0x1)
+
#define MPC52xx_GPT_CAN_WDT (1 << 0)
#define MPC52xx_GPT_IS_WDT (1 << 1)
@@ -274,6 +289,182 @@ mpc52xx_gpt_irq_setup(struct mpc52xx_gpt_priv *gpt, struct device_node *node)
/* ---------------------------------------------------------------------
+ * PWM API hooks
+ */
+#if defined(CONFIG_GENERIC_PWM)
+static inline struct mpc52xx_gpt_priv *pwm_to_mpc52xx_gpt(const struct pwm_channel *p)
+{
+ return container_of(p->pwm, struct mpc52xx_gpt_priv, pwm);
+}
+
+static int mpc52xx_gpt_pwm_request(struct pwm_channel *p)
+{
+ struct mpc52xx_gpt_priv *gpt = pwm_to_mpc52xx_gpt(p);
+
+ /* TODO: add hooks to prevent conflicts in use */
+ p->tick_hz = gpt->ipb_freq;
+ return 0;
+}
+
+static void mpc52xx_gpt_pwm_free(struct pwm_channel *p)
+{
+ /* TODO: add hooks to prevent conflicts in use */
+}
+
+static int __mpc52xx_gpt_pwm_config_period_ticks(struct pwm_channel *p,
+ struct pwm_channel_config *c)
+{
+ struct mpc52xx_gpt_priv *gpt = pwm_to_mpc52xx_gpt(p);
+ u64 prescale, count;
+
+ prescale = (c->period_ticks >> 16) + 1;
+ count = c->period_ticks;
+ do_div(count, prescale);
+ out_be32(&gpt->regs->count, prescale << 16 | count);
+
+ p->period_ticks = count * prescale;
+ dev_dbg(p->pwm->dev, "prescale %4x count %4x period_ticks %8x\n",
+ (unsigned int)prescale, (unsigned int)count,
+ (unsigned int)p->period_ticks);
+
+ return 0;
+}
+
+static int __mpc52xx_gpt_pwm_config_duty_ticks(struct pwm_channel *p,
+ struct pwm_channel_config *c)
+{
+ struct mpc52xx_gpt_priv *gpt = pwm_to_mpc52xx_gpt(p);
+ unsigned long flags;
+ u64 width = c->duty_ticks;
+ u32 prescale, count;
+
+ spin_lock_irqsave(&gpt->lock, flags);
+
+ count = in_be32(&gpt->regs->count);
+ prescale = count >> 16;
+ count &= 0xffffUL;
+
+ /* TODO: this probably isn't the best place to do a divide... */
+ do_div(width, prescale);
+
+ clrsetbits_be32(&gpt->regs->pwm, MPC52xx_GPT_PWM_WIDTH_MASK,
+ MPC52xx_GPT_PWM_WIDTH_MASK & (width << 16));
+ spin_unlock_irqrestore(&gpt->lock, flags);
+
+ p->duty_ticks = width * prescale;
+ dev_dbg(p->pwm->dev, "prescale %4x count %4x width %4x duty_ticks %8x\n",
+ (unsigned int)prescale, (unsigned int)count,
+ (unsigned int)width, (unsigned int)p->duty_ticks);
+
+ return 0;
+}
+
+static int __mpc52xx_gpt_pwm_config_polarity(struct pwm_channel *p,
+ struct pwm_channel_config *c)
+{
+ struct mpc52xx_gpt_priv *gpt = pwm_to_mpc52xx_gpt(p);
+ unsigned long flags;
+
+ spin_lock_irqsave(&gpt->lock, flags);
+ if (c->polarity)
+ setbits32(&gpt->regs->pwm, MPC52xx_GPT_PWM_PWMOP);
+ else
+ clrbits32(&gpt->regs->pwm, MPC52xx_GPT_PWM_PWMOP);
+ spin_unlock_irqrestore(&gpt->lock, flags);
+ return 0;
+}
+
+static int __mpc52xx_gpt_pwm_start(struct pwm_channel *p)
+{
+ struct mpc52xx_gpt_priv *gpt = pwm_to_mpc52xx_gpt(p);
+ unsigned long flags;
+
+ spin_lock_irqsave(&gpt->lock, flags);
+ clrsetbits_be32(&gpt->regs->mode, MPC52xx_GPT_MODE_MS_MASK,
+ MPC52xx_GPT_MODE_MS_PWM);
+ spin_unlock_irqrestore(&gpt->lock, flags);
+ return 0;
+}
+
+static int __mpc52xx_gpt_pwm_stop(struct pwm_channel *p)
+{
+ struct mpc52xx_gpt_priv *gpt = pwm_to_mpc52xx_gpt(p);
+ unsigned long flags;
+
+ spin_lock_irqsave(&gpt->lock, flags);
+ clrbits32(&gpt->regs->mode, MPC52xx_GPT_MODE_MS_MASK);
+ spin_unlock_irqrestore(&gpt->lock, flags);
+ return 0;
+}
+
+static int mpc52xx_gpt_pwm_config_nosleep(struct pwm_channel *p,
+ struct pwm_channel_config *c)
+{
+ int ret = -EINVAL;
+
+ if (c->config_mask & PWM_CONFIG_PERIOD_TICKS)
+ if ((ret = __mpc52xx_gpt_pwm_config_period_ticks(p, c)))
+ goto done;
+
+ if (c->config_mask & PWM_CONFIG_DUTY_TICKS)
+ if ((ret = __mpc52xx_gpt_pwm_config_duty_ticks(p, c)))
+ goto done;
+
+ if (c->config_mask & PWM_CONFIG_POLARITY)
+ if ((ret = __mpc52xx_gpt_pwm_config_polarity(p, c)))
+ goto done;
+
+ if (c->config_mask & PWM_CONFIG_START)
+ if ((ret = __mpc52xx_gpt_pwm_start(p)))
+ goto done;
+
+ if (c->config_mask & PWM_CONFIG_STOP)
+ if ((ret = __mpc52xx_gpt_pwm_stop(p)))
+ goto done;
+
+done:
+ return ret;
+}
+
+static int mpc52xx_gpt_pwm_config(struct pwm_channel *p,
+ struct pwm_channel_config *c)
+{
+ dev_dbg(p->pwm->dev, "config_mask %x\n", c->config_mask);
+
+ if (!mpc52xx_gpt_pwm_config_nosleep(p, c))
+ return 0;
+
+ might_sleep();
+
+ /* TODO: add other API entry points */
+
+ return -EINVAL;
+}
+
+static void
+mpc52xx_gpt_pwm_setup(struct mpc52xx_gpt_priv *gpt, struct device_node *node)
+{
+ if (!of_find_property(node, "pwm-controller", NULL))
+ return;
+
+ gpt->pwm.dev = gpt->dev;
+ gpt->pwm.bus_id = dev_name(gpt->dev);
+ gpt->pwm.nchan = 1;
+ gpt->pwm.owner = THIS_MODULE;
+
+ gpt->pwm.request = mpc52xx_gpt_pwm_request;
+ gpt->pwm.free = mpc52xx_gpt_pwm_free;
+ gpt->pwm.config_nosleep = mpc52xx_gpt_pwm_config_nosleep;
+ gpt->pwm.config = mpc52xx_gpt_pwm_config;
+
+ pwm_register(&gpt->pwm);
+}
+#else
+static void
+mpc52xx_gpt_pwm_setup(struct mpc52xx_gpt_priv *p, struct device_node *np) {}
+#endif
+
+/* ---------------------------------------------------------------------
* GPIOLIB hooks
*/
#if defined(CONFIG_GPIOLIB)
@@ -737,9 +928,9 @@ static int __devinit mpc52xx_gpt_probe(struct of_device *ofdev,
}
dev_set_drvdata(&ofdev->dev, gpt);
-
mpc52xx_gpt_gpio_setup(gpt, ofdev->node);
mpc52xx_gpt_irq_setup(gpt, ofdev->node);
+ mpc52xx_gpt_pwm_setup(gpt, ofdev->node);
mutex_lock(&mpc52xx_gpt_list_mutex);
list_add(&gpt->list, &mpc52xx_gpt_list);
--
1.6.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox