Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Fri, 10 Oct 2008, Bill Gatliff wrote: Paul Mundt wrote: Your first version should have been to linux-embedded and linux-kernel. If you want to alert the linux-arm-kernel people to the fact that a discussion is going on in this area, then feel free to post a notification to the list with references to the relevant lists. There is no reason why public lists should have to dig in to private archives to try and play catch up. I'm not asking anyone to do that. Just review the patches posted to the list of your choice. Or, don't review them. Up to you. My next update will be the one where I formally request a review with intent to merge into mainline. That one will go to linux-embedded only, with notifications sent elsewhere as indicated per community request. I don't have a problem with that. I can't change history, but I'm doing what you are asking of me otherwise. For a formally request for review, you do want to CC lkml. With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
Jon Loeliger wrote: On Fri, 2008-10-10 at 09:04 -0500, Bill Gatliff wrote: Jon Smirl wrote: What do the device tree deities have to say about PWM support? Dunno. What lists are they on? :) Perhaps [EMAIL PROTECTED] too. I thought this was what ePAPR was for. Why would it need all that discussion if it's being codified into a proper standard? Someone should just submit a reasonable extension to a reasonable extension-managing body :) -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Fri, Oct 10, 2008 at 11:00:09AM +0200, Geert Uytterhoeven wrote: On Thu, 9 Oct 2008, Bill Gatliff wrote: Benjamin Herrenschmidt wrote: On Wed, 2008-10-08 at 11:43 -0500, Bill Gatliff wrote: This series proposes a generic PWM driver API. This proposed API is motivated by the author's need to support pluggable devices; a secondary objective is to consolidate the existing PWM implementations behind an agreeable, consistent, redundancy-reducing interface. .../... You should send your patches to the main linux kernel list ! Perhaps. But it seemed more relevant to this crowd, and the linux-embedded crowd, and the linux-arm-kernel crowd. Were did you actually sent them to? Apparently you sent them to each mailing list (at least linux-embedded and linuxppc-dev) _separately_ (or using bcc). Hence different people may give the same comments without knowing about each other, and you may have to explain everything multiple times. I would go for lkml and linux-embedded, _together_. This is likely because some of those lists are subscribers only, so cross posting is poor form. It makes sense to keep the discussion in one place, and to send notification messages with a pointer to the list archives to the other lists so folks can jump in if they really care. Splitting it out doesn't help matters in the least, but unfortunately this is what seems to happen the most when subscribers only lists are involved. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
David Woodhouse wrote: Subscriber-only lists are broken. Just don't use them. You owe me a new keyboard! :) b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
Paul Mundt wrote: This is likely because some of those lists are subscribers only, so cross posting is poor form. It makes sense to keep the discussion in one place, and to send notification messages with a pointer to the list archives to the other lists so folks can jump in if they really care. Splitting it out doesn't help matters in the least, but unfortunately this is what seems to happen the most when subscribers only lists are involved. Alright, then maybe I can do this when I post the final changeset for review: cross-post to lkml and linux-embedded, and then post one short note on l-a-k, linuxppc-dev and elsewhere that refers those interested to the actual content. I can live with that. b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
Jon Smirl wrote: What do the device tree deities have to say about PWM support? Dunno. What lists are they on? :) b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Fri, Oct 10, 2008 at 10:04 AM, Bill Gatliff [EMAIL PROTECTED] wrote: Jon Smirl wrote: What do the device tree deities have to say about PWM support? Dunno. What lists are they on? :) They are on linuxppc-dev. Device trees would be used on powerpc to control the initial setup of the PWM device. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Thu, 9 Oct 2008, Bill Gatliff wrote: Benjamin Herrenschmidt wrote: On Wed, 2008-10-08 at 11:43 -0500, Bill Gatliff wrote: This series proposes a generic PWM driver API. This proposed API is motivated by the author's need to support pluggable devices; a secondary objective is to consolidate the existing PWM implementations behind an agreeable, consistent, redundancy-reducing interface. .../... You should send your patches to the main linux kernel list ! Perhaps. But it seemed more relevant to this crowd, and the linux-embedded crowd, and the linux-arm-kernel crowd. Were did you actually sent them to? Apparently you sent them to each mailing list (at least linux-embedded and linuxppc-dev) _separately_ (or using bcc). Hence different people may give the same comments without knowing about each other, and you may have to explain everything multiple times. I would go for lkml and linux-embedded, _together_. With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
Bill Gatliff [EMAIL PROTECTED] wrote: Paul Mundt wrote: This is likely because some of those lists are subscribers only, so cross posting is poor form. It makes sense to keep the discussion in one place, and to send notification messages with a pointer to the list archives to the other lists so folks can jump in if they really care. Splitting it out doesn't help matters in the least, but unfortunately this is what seems to happen the most when subscribers only lists are involved. Alright, then maybe I can do this when I post the final changeset for review: cross-post to lkml and linux-embedded, and then post one short note on l-a-k, linuxppc-dev and elsewhere that refers those interested to the actual content. I can live with that. Feel free to cross-post to [EMAIL PROTECTED] It's open for non-subscribers, and there may be people interested in PWM there (especially since you include a driver for the PWM hardware on AVR32 devices.) Haavard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Fri, 2008-10-10 at 18:36 +0900, Paul Mundt wrote: This is likely because some of those lists are subscribers only, so cross posting is poor form. It makes sense to keep the discussion in one place, and to send notification messages with a pointer to the list archives to the other lists so folks can jump in if they really care. Splitting it out doesn't help matters in the least, but unfortunately this is what seems to happen the most when subscribers only lists are involved. Subscriber-only lists are broken. Just don't use them. -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED] Intel Corporation ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
Geert Uytterhoeven wrote: Were did you actually sent them to? Apparently you sent them to each mailing list (at least linux-embedded and linuxppc-dev) _separately_ (or using bcc). I sent them separately to linux-embedded, linuxppc-dev, and linux-arm-kernel. Those three groups seemed to have the developers who were most likely to provide a motivated review and constructive response; unfortunately, some are subscriber-only and so I couldn't just cross-post. I was expecting some criticism for this, but I'm not sure there's a good alternative. I don't like the idea of posting in so many places, but PWM is a pretty expansive topic: just about every SoC under the sun has some ability to do PWM, and people use the signals for all sorts of things. Both have to be taken into consideration by the API, hence I need lots of review and feedback. There isn't a lot of traffic on linux-embedded, and I'm not sure how many people who read linux-arm-kernel also read linuxppc-dev. Lkml's topic coverage is huge, so I don't know how many hardcore embedded developers I would encounter there. I was hoping for a round of feedback at a lower level before pushing anything upstream like that. Hence different people may give the same comments without knowing about each other, and you may have to explain everything multiple times. Hasn't been a problem so far. I posted the first version of the code on l-a-k, and got some feedback on the pwm_device API and a lot of feedback on the way users wanted to use the API to realize applications. I incorporated all of it, and in this release I broadened the exposure per recommendations received from l-a-k. I would go for lkml and linux-embedded, _together_. So, you're saying the same thing as me, basically. But leaving out the lists with very high ratios of device-specific domain knowledge, which is important for the backend parts of what I'm proposing. Blackfin's PWM-capable peripherals work differently from those commonly found in ARM and PPC, for example. I haven't run anything by the MIPS or AVR guys, but I'm guessing they would have something to add, too. I'm beginning to appreciate what everyone must have had to deal with for GPIO. :) b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Fri, Oct 10, 2008 at 09:03:34AM -0500, Bill Gatliff wrote: Paul Mundt wrote: This is likely because some of those lists are subscribers only, so cross posting is poor form. It makes sense to keep the discussion in one place, and to send notification messages with a pointer to the list archives to the other lists so folks can jump in if they really care. Splitting it out doesn't help matters in the least, but unfortunately this is what seems to happen the most when subscribers only lists are involved. Alright, then maybe I can do this when I post the final changeset for review: cross-post to lkml and linux-embedded, and then post one short note on l-a-k, linuxppc-dev and elsewhere that refers those interested to the actual content. I can live with that. linux-arm-kernel is the only one that is subscribers only out of that list, according to MAINTAINERS. If rmk wants to mandate a broken policy, that's perfectly fine, just don't expect the rest of the kernel community to tolerate it. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Fri, Oct 10, 2008 at 08:59:08AM -0500, Bill Gatliff wrote: There isn't a lot of traffic on linux-embedded, and I'm not sure how many people who read linux-arm-kernel also read linuxppc-dev. Lkml's topic coverage is huge, so I don't know how many hardcore embedded developers I would encounter there. I was hoping for a round of feedback at a lower level before pushing anything upstream like that. This isn't your problem. If people are interested in general embedded topics, they should be subscribed to the list. If they aren't, it's their loss. Cross posting to every potentially relevant list is a complete waste of time, and only helps to split out the discussion so nothing actually gets accomplished in a centralized location. Hasn't been a problem so far. I posted the first version of the code on l-a-k, and got some feedback on the pwm_device API and a lot of feedback on the way users wanted to use the API to realize applications. I incorporated all of it, and in this release I broadened the exposure per recommendations received from l-a-k. This is precisely the problem. Stuff that gets reviewed on linux-arm-kernel gets reviewed for ARM only. There has been way too much crap that has been pushed into the kernel under the guise of being generic and reviewed that has broken _every_ architecture _except_ ARM. If you want to refute this, go look at the recent fiasco with musb, which still hasn't been solved properly, primarily because the ARM people couldn't be bothered using grep. This crap happens all the time, because stuff is reviewed and merged in private, and the only time anyone else notices is when their platform suddenly stops building. Your first version should have been to linux-embedded and linux-kernel. If you want to alert the linux-arm-kernel people to the fact that a discussion is going on in this area, then feel free to post a notification to the list with references to the relevant lists. There is no reason why public lists should have to dig in to private archives to try and play catch up. So, you're saying the same thing as me, basically. But leaving out the lists with very high ratios of device-specific domain knowledge, which is important for the backend parts of what I'm proposing. Blackfin's PWM-capable peripherals work differently from those commonly found in ARM and PPC, for example. I haven't run anything by the MIPS or AVR guys, but I'm guessing they would have something to add, too. I'm beginning to appreciate what everyone must have had to deal with for GPIO. :) The GPIO mess was broken in different ways, which we're still trying to fix today. The GPIO discussion did happen out on public lists though, so all of the discussion on that was visible, even if the end result left something to be desired. If you're trying to pitch a generic API and doing your review on a private list, you've already lost. If you're talking about things that only effect arch/arm, feel free to do whatever you want. As soon as you step outside of that structure, you have to follow common convention, or you risk breaking things all over the place. I can't remember the last time I saw a generic API reviewed on linux-arm-kernel that didn't end up breaking every other architecture in existence. This is true for drivers, also. Better yet, don't bother dropping the ARM depedency until you've posted to a public list. Some of us are pretty damn tired of cleaning up after the ARM people. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
Paul Mundt wrote: On Fri, Oct 10, 2008 at 09:03:34AM -0500, Bill Gatliff wrote: Paul Mundt wrote: This is likely because some of those lists are subscribers only, so cross posting is poor form. It makes sense to keep the discussion in one place, and to send notification messages with a pointer to the list archives to the other lists so folks can jump in if they really care. Splitting it out doesn't help matters in the least, but unfortunately this is what seems to happen the most when subscribers only lists are involved. Alright, then maybe I can do this when I post the final changeset for review: cross-post to lkml and linux-embedded, and then post one short note on l-a-k, linuxppc-dev and elsewhere that refers those interested to the actual content. I can live with that. linux-arm-kernel is the only one that is subscribers only out of that list, according to MAINTAINERS. If rmk wants to mandate a broken policy, that's perfectly fine, just don't expect the rest of the kernel community to tolerate it. Problem is, the rest of the kernel community is the one who takes it in the, ahem, server when I cross-post. And since my reference platform is currently ARM, I can't leave l-a-k out. b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
Paul Mundt wrote: Hasn't been a problem so far. I posted the first version of the code on l-a-k, and got some feedback on the pwm_device API and a lot of feedback on the way users wanted to use the API to realize applications. I incorporated all of it, and in this release I broadened the exposure per recommendations received from l-a-k. This is precisely the problem. Stuff that gets reviewed on linux-arm-kernel gets reviewed for ARM only. There has been way too much crap that has been pushed into the kernel under the guise of being generic and reviewed that has broken _every_ architecture _except_ ARM. If you want to refute this, go look at the recent fiasco with musb, which still hasn't been solved properly, primarily because the ARM people couldn't be bothered using grep. This crap happens all the time, because stuff is reviewed and merged in private, and the only time anyone else notices is when their platform suddenly stops building. I'll note for the record that I didn't post on linux-arm-kernel only. Otherwise, we wouldn't be having this discussion. :) Your first version should have been to linux-embedded and linux-kernel. If you want to alert the linux-arm-kernel people to the fact that a discussion is going on in this area, then feel free to post a notification to the list with references to the relevant lists. There is no reason why public lists should have to dig in to private archives to try and play catch up. I'm not asking anyone to do that. Just review the patches posted to the list of your choice. Or, don't review them. Up to you. My next update will be the one where I formally request a review with intent to merge into mainline. That one will go to linux-embedded only, with notifications sent elsewhere as indicated per community request. I don't have a problem with that. I can't change history, but I'm doing what you are asking of me otherwise. If you're trying to pitch a generic API and doing your review on a private list, you've already lost. If you're talking about things that only effect arch/arm, feel free to do whatever you want. As soon as you step outside of that structure, you have to follow common convention, or you risk breaking things all over the place. I can't remember the last time I saw a generic API reviewed on linux-arm-kernel that didn't end up breaking every other architecture in existence. This is true for drivers, also. Better yet, don't bother dropping the ARM depedency until you've posted to a public list. Again, we wouldn't be having this exchange if I was pitching a generic API on a private list because I sense that you aren't an l-a-k subscriber. :) It's true that the early posts were on the ARM list, but you can see that I didn't stop there. I started there because the platform that supports the API right now is ARM, and so I wanted that part to be right before moving upstream. That process worked: I received feedback on the ARM-specific bits which improved the API as a whole. The diversity of ARM machines plus Blackfin, PPC, MIPS, X, Y, Z and PDQ machines was more than I could deal with until now. Right, enough of that. I really don't want to get distracted from the code. I'll readily admit to not handing the mailing list submissions right, and I resolve to do a better job effective immediately. But I think that's the last that I need to say on the subject. If it makes you feel any better, I'll stop responding to your replies unless they come to me via linux-embedded. :) Some of us are pretty damn tired of cleaning up after the ARM people. Sounds like the ARM people need you to drop by and help them do a better job. Sounds like you could directly benefit from their doing a better job, too. Win-win. b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Fri, 2008-10-10 at 09:04 -0500, Bill Gatliff wrote: Jon Smirl wrote: What do the device tree deities have to say about PWM support? Dunno. What lists are they on? :) Perhaps [EMAIL PROTECTED] too. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
I'm all for this if you manage it. The code and API looks good. We have some projects which involve PWM and having a nice clean standard API like the GPIO API was on the wishlist.. this will make it so much easier to do fan control, backlight control, drive motors, audio output, and the billion other things.. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations Bill Gatliff wrote: This series proposes a generic PWM driver API. This proposed API is motivated by the author's need to support pluggable devices; a secondary objective is to consolidate the existing PWM implementations behind an agreeable, consistent, redundancy-reducing interface. The code included in this patch draws heavily from the existing PWM infrastructure and driver for the AT91SAM9263 PWMC. The author is grateful to Russell King, Eric Miao, David Brownell and others for providing such tall shoulders to stand upon. The proposed updates to that code should not be interpreted as attempts to address shortcomings, but rather to extend functionality in ways that were not originally required. The implementation of the proposed API is structurally similar to the generic GPIO API, except that the PWM code uses platform bus_id strings instead of integers to identify devices. A configuration structure is also provided, so that the API can be extended in a source-code-compatible way to accomodate devices with features not anticipated by the current code. Pulse width modulated signals are used in an astounding number and range of applications, and there is no one true way of either realizing them or employing them to accomplish real work. The current proposal attempts to provide a useful feature set for the most basic users, packaged in such a way as to allow the API to be extended in a backwards-compatible way as new needs are identified. Some of these needs have already been identified. The proposed code has been run-tested on a Cogent CSB737 (AT91SAM9263), mated to a custom circuit that drives multiple DC motors and sensors. Feedback is welcome! b.g. -- Bill Gatliff [EMAIL PROTECTED] == Bill Gatliff (6): [PWM] Generic PWM API implementation [PWM] Changes to existing pwm.h to adapt to generic PWM API [PWM] Documentation [PWM] Driver for Atmel PWMC peripheral [PWM] Install new Atmel PWMC driver in Kconfig, expunge old one [PWM] New LED driver and trigger that use PWM API Documentation/pwm.txt | 258 + arch/arm/Kconfig |2 + drivers/Makefile |2 + drivers/leds/Kconfig | 21 +- drivers/leds/Makefile |2 + drivers/leds/leds-pwm.c| 141 ++ drivers/leds/ledtrig-dim.c | 95 +++ drivers/misc/Kconfig |9 - drivers/misc/Makefile |1 - drivers/misc/atmel_pwm.c | 409 --- drivers/pwm/Kconfig| 24 ++ drivers/pwm/Makefile |6 + drivers/pwm/atmel-pwm.c| 631 + drivers/pwm/pwm.c | 667 include/linux/pwm-led.h| 34 +++ include/linux/pwm.h| 168 ++-- 16 files changed, 2023 insertions(+), 447 deletions(-) create mode 100644 Documentation/pwm.txt create mode 100644 drivers/leds/leds-pwm.c create mode 100644 drivers/leds/ledtrig-dim.c delete mode 100644 drivers/misc/atmel_pwm.c create mode 100644 drivers/pwm/Kconfig create mode 100644 drivers/pwm/Makefile create mode 100644 drivers/pwm/atmel-pwm.c create mode 100644 drivers/pwm/pwm.c create mode 100644 include/linux/pwm-led.h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
Matt Sealey wrote: I'm all for this if you manage it. The code and API looks good. We have some projects which involve PWM and having a nice clean standard API like the GPIO API was on the wishlist.. this will make it so much easier to do fan control, backlight control, drive motors, audio output, and the billion other things.. /me blushes Aw, shucks. I'm just glad I could help. :) b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Wed, 2008-10-08 at 11:43 -0500, Bill Gatliff wrote: This series proposes a generic PWM driver API. This proposed API is motivated by the author's need to support pluggable devices; a secondary objective is to consolidate the existing PWM implementations behind an agreeable, consistent, redundancy-reducing interface. .../... You should send your patches to the main linux kernel list ! Cheers, Ben ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
Benjamin Herrenschmidt wrote: On Wed, 2008-10-08 at 11:43 -0500, Bill Gatliff wrote: This series proposes a generic PWM driver API. This proposed API is motivated by the author's need to support pluggable devices; a secondary objective is to consolidate the existing PWM implementations behind an agreeable, consistent, redundancy-reducing interface. .../... You should send your patches to the main linux kernel list ! Perhaps. But it seemed more relevant to this crowd, and the linux-embedded crowd, and the linux-arm-kernel crowd. At the very least, it made sense to present it in this sort of venue first. Given that it's a global API proposal, I suppose I'll have to run it by lkml at some point--- unless one of the aforementioned groups can mainline it themselves. b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Thu, 2008-10-09 at 23:06 -0500, Bill Gatliff wrote: Benjamin Herrenschmidt wrote: On Wed, 2008-10-08 at 11:43 -0500, Bill Gatliff wrote: This series proposes a generic PWM driver API. This proposed API is motivated by the author's need to support pluggable devices; a secondary objective is to consolidate the existing PWM implementations behind an agreeable, consistent, redundancy-reducing interface. .../... You should send your patches to the main linux kernel list ! Perhaps. But it seemed more relevant to this crowd, and the linux-embedded crowd, and the linux-arm-kernel crowd. Sure but if you want then applied, you probably still need lkml and andrew. At the very least, it made sense to present it in this sort of venue first. Given that it's a global API proposal, I suppose I'll have to run it by lkml at some point--- unless one of the aforementioned groups can mainline it themselves. For review and comments, sure. Cheers, ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Fri, Oct 10, 2008 at 1:02 AM, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Thu, 2008-10-09 at 23:06 -0500, Bill Gatliff wrote: Benjamin Herrenschmidt wrote: On Wed, 2008-10-08 at 11:43 -0500, Bill Gatliff wrote: This series proposes a generic PWM driver API. This proposed API is motivated by the author's need to support pluggable devices; a secondary objective is to consolidate the existing PWM implementations behind an agreeable, consistent, redundancy-reducing interface. .../... You should send your patches to the main linux kernel list ! Perhaps. But it seemed more relevant to this crowd, and the linux-embedded crowd, and the linux-arm-kernel crowd. Sure but if you want then applied, you probably still need lkml and andrew. At the very least, it made sense to present it in this sort of venue first. Given that it's a global API proposal, I suppose I'll have to run it by lkml at some point--- unless one of the aforementioned groups can mainline it themselves. For review and comments, sure. What do the device tree deities have to say about PWM support? -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC 0/6] Proposal for a Generic PWM Device API
This series proposes a generic PWM driver API. This proposed API is motivated by the author's need to support pluggable devices; a secondary objective is to consolidate the existing PWM implementations behind an agreeable, consistent, redundancy-reducing interface. The code included in this patch draws heavily from the existing PWM infrastructure and driver for the AT91SAM9263 PWMC. The author is grateful to Russell King, Eric Miao, David Brownell and others for providing such tall shoulders to stand upon. The proposed updates to that code should not be interpreted as attempts to address shortcomings, but rather to extend functionality in ways that were not originally required. The implementation of the proposed API is structurally similar to the generic GPIO API, except that the PWM code uses platform bus_id strings instead of integers to identify devices. A configuration structure is also provided, so that the API can be extended in a source-code-compatible way to accomodate devices with features not anticipated by the current code. Pulse width modulated signals are used in an astounding number and range of applications, and there is no one true way of either realizing them or employing them to accomplish real work. The current proposal attempts to provide a useful feature set for the most basic users, packaged in such a way as to allow the API to be extended in a backwards-compatible way as new needs are identified. Some of these needs have already been identified. The proposed code has been run-tested on a Cogent CSB737 (AT91SAM9263), mated to a custom circuit that drives multiple DC motors and sensors. Feedback is welcome! b.g. -- Bill Gatliff [EMAIL PROTECTED] == Bill Gatliff (6): [PWM] Generic PWM API implementation [PWM] Changes to existing pwm.h to adapt to generic PWM API [PWM] Documentation [PWM] Driver for Atmel PWMC peripheral [PWM] Install new Atmel PWMC driver in Kconfig, expunge old one [PWM] New LED driver and trigger that use PWM API Documentation/pwm.txt | 258 + arch/arm/Kconfig |2 + drivers/Makefile |2 + drivers/leds/Kconfig | 21 +- drivers/leds/Makefile |2 + drivers/leds/leds-pwm.c| 141 ++ drivers/leds/ledtrig-dim.c | 95 +++ drivers/misc/Kconfig |9 - drivers/misc/Makefile |1 - drivers/misc/atmel_pwm.c | 409 --- drivers/pwm/Kconfig| 24 ++ drivers/pwm/Makefile |6 + drivers/pwm/atmel-pwm.c| 631 + drivers/pwm/pwm.c | 667 include/linux/pwm-led.h| 34 +++ include/linux/pwm.h| 168 ++-- 16 files changed, 2023 insertions(+), 447 deletions(-) create mode 100644 Documentation/pwm.txt create mode 100644 drivers/leds/leds-pwm.c create mode 100644 drivers/leds/ledtrig-dim.c delete mode 100644 drivers/misc/atmel_pwm.c create mode 100644 drivers/pwm/Kconfig create mode 100644 drivers/pwm/Makefile create mode 100644 drivers/pwm/atmel-pwm.c create mode 100644 drivers/pwm/pwm.c create mode 100644 include/linux/pwm-led.h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
