Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
Grant: On Wed, Oct 20, 2010 at 2:32 PM, Bill Gatliff b...@billgatliff.com wrote: Yeah, by changing to using class attributes, a lot of this could end up going away. Looking at that now, in fact. Going to class device attributes did the trick. Thanks for pointing me in the right direction! b.g. -- Bill Gatliff b...@billgatliff.com -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
On Wed, Oct 6, 2010 at 12:48 PM, Bill Gatliff b...@billgatliff.com wrote: Hector: On Sat, Oct 2, 2010 at 7:25 AM, Hector Oron hector.o...@gmail.com wrote: Hello Bill, Thanks for trying (again) to get this in mainline. Are you planning to request a slot in the GIT at kernel.org to hold and maintain this nice framework? I did make such a request once, and it went nowhere. :( Git trees don't have to be hosted on git.kernel.org. None of my trees are on kernel.org, and Linus pulls from me all the time. You can host your own git server, or use a git hosting provider. But, if you're serious about getting it mainlined, then you need to post the whole series to linux-kernel. Also, without a specific maintainer to pick it up for you, it helps to cc: Andrew Morton. I recommend doing so sooner rather than later. It probably won't make 2.6.37 since the merge window is opening in about a week, but it would be a good candidate for .38. I'll go through all the patches right now and make my comments. g. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
On Thu, Oct 07, 2010 at 00:20:25, Bill Gatliff wrote: On Tue, Oct 5, 2010 at 5:35 AM, sugumar sugumar.embed...@gmail.com wrote: I have been working on writing generic PWM driver that provides common interface to all the PWM devices. I hadn't come across this thread until kevin pointed out. It looks like a very good implementation and i would like to make my eHRPWM driver to fit into this framework. eHRPWM (enhanced high resolution pwm) module has other features such as Dead Band, PWM chopper and Trip Zone and i am not sure how to incorporate these in the generic framework. I really need you help here. Ok. Can you point me to a datasheet for the part? I am sure the generic framework should support all the features provided by the PWM devices. For eg, eHRPWM has Trip-Zone feature where an asynchronous input (incase of short circuit .) can be configured to generate an interrupt. I am interested in finding a way to handle this. Kindly give your comments. Well, we could handle it in the generic framework by adding to the synchronization callback mechanism. Or we could leave it as a feature unique to the eHRPWM device, and a device-specific solution. Maybe I will have a better idea once I look at the hardware. Bill, Thanks for your comments. Also, I am not particularly clear about the pwm_set_handler function. As far my understanding goes, in order to defer the work, 1. Set the set_callback variable in the pwm_device structure to the callback function. 2. Call the pwm_set_handler function to set the bottom halve handler and the data. 3. pwm_set_handler inturn invokes the call back function defined in step 1 .The latter would set the PWM channel call back to pwm_handler function which is local to the PWM framework. 4.Call the pwm_channel callback in the interrupt handler to queue the work for later processing. 1. Is my above understanding correct? 2. Single channel may support multiple interrupts. For eg., pwm_set_handler(handler_1) pwm_set_handler(handler_2) How to handle multiple interrupts with the above framework? 3. pwm_set_handler() -- Defines an end-of-period callback. Is the pwm_set_handler only used for the end-of-period interrupt. Can't it be used for other events ? 4. Various applications may require different actions to be handled in the interrupt handler (Eg. Motor Control, Backlight control ..). so, we cannot have a generic interrupt handler in the pwm device driver. How to handle this? Regards, N.Sugumar. b.g. -- Bill Gatliff b...@billgatliff.com -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
On Fri, Oct 1, 2010 at 5:00 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Bill Gatliff b...@billgatliff.com writes: Signed-off-by: Bill Gatliff b...@billgatliff.com Hi Bill, Any plans to post this to a broader audience? maybe linux-arm-kernel? I was thinking that the appropriate audience was all right here. :) b.g. -- Bill Gatliff b...@billgatliff.com -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
Hector: On Sat, Oct 2, 2010 at 7:25 AM, Hector Oron hector.o...@gmail.com wrote: Hello Bill, Thanks for trying (again) to get this in mainline. Are you planning to request a slot in the GIT at kernel.org to hold and maintain this nice framework? I did make such a request once, and it went nowhere. :( b.g. -- Bill Gatliff b...@billgatliff.com -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
On Tue, Oct 5, 2010 at 5:35 AM, sugumar sugumar.embed...@gmail.com wrote: I have been working on writing generic PWM driver that provides common interface to all the PWM devices. I hadn't come across this thread until kevin pointed out. It looks like a very good implementation and i would like to make my eHRPWM driver to fit into this framework. eHRPWM (enhanced high resolution pwm) module has other features such as Dead Band, PWM chopper and Trip Zone and i am not sure how to incorporate these in the generic framework. I really need you help here. Ok. Can you point me to a datasheet for the part? I am sure the generic framework should support all the features provided by the PWM devices. For eg, eHRPWM has Trip-Zone feature where an asynchronous input (incase of short circuit .) can be configured to generate an interrupt. I am interested in finding a way to handle this. Kindly give your comments. Well, we could handle it in the generic framework by adding to the synchronization callback mechanism. Or we could leave it as a feature unique to the eHRPWM device, and a device-specific solution. Maybe I will have a better idea once I look at the hardware. b.g. -- Bill Gatliff b...@billgatliff.com -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
-Original Message- From: linux-embedded-ow...@vger.kernel.org [mailto:linux-embedded-ow...@vger.kernel.org] On Behalf Of Bill Gatliff Sent: Wednesday, October 06, 2010 11:50 AM To: sugumar Cc: linux-embedded@vger.kernel.org Subject: Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface On Tue, Oct 5, 2010 at 5:35 AM, sugumar sugumar.embed...@gmail.com wrote: I have been working on writing generic PWM driver that provides common interface to all the PWM devices. I hadn't come across this thread until kevin pointed out. It looks like a very good implementation and i would like to make my eHRPWM driver to fit into this framework. eHRPWM (enhanced high resolution pwm) module has other features such as Dead Band, PWM chopper and Trip Zone and i am not sure how to incorporate these in the generic framework. I really need you help here. Ok. Can you point me to a datasheet for the part? PDF datasheet here: http://www.ti.com/litv/pdf/sprufl3b Mark-- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
Bill Gatliff b...@billgatliff.com writes: On Fri, Oct 1, 2010 at 5:00 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Bill Gatliff b...@billgatliff.com writes: Signed-off-by: Bill Gatliff b...@billgatliff.com Hi Bill, Any plans to post this to a broader audience? maybe linux-arm-kernel? I was thinking that the appropriate audience was all right here. :) Maybe so, in terms of maintainers and folks watching the bigger picture of the kernel. However, the folks that seem to be developing similar things in parallel are apparently not here as they seem to be doing similar work in parallel. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
Bill Gatliff bgat at billgatliff.com writes: Signed-off-by: Bill Gatliff bgat at billgatliff.com --- Documentation/pwm.txt | 260 +++ drivers/pwm/pwm.c | 635 +++ include/linux/pwm.h | 31 --- include/linux/pwm/pwm.h | 128 ++ 4 files changed, 1023 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 diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt new file mode 100644 index 000..34b1e5a --- /dev/null +++ b/Documentation/pwm.txt @@ -0,0 +1,260 @@ + Hi bill, I have been working on writing generic PWM driver that provides common interface to all the PWM devices. I hadn't come across this thread until kevin pointed out. It looks like a very good implementation and i would like to make my eHRPWM driver to fit into this framework. eHRPWM (enhanced high resolution pwm) module has other features such as Dead Band, PWM chopper and Trip Zone and i am not sure how to incorporate these in the generic framework. I really need you help here. I am sure the generic framework should support all the features provided by the PWM devices. For eg, eHRPWM has Trip-Zone feature where an asynchronous input (incase of short circuit .) can be configured to generate an interrupt. I am interested in finding a way to handle this. Kindly give your comments. Regards, N.Sugumar -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
Hello Bill, 2010/10/1 Bill Gatliff b...@billgatliff.com: Signed-off-by: Bill Gatliff b...@billgatliff.com --- Documentation/pwm.txt | 260 +++ drivers/pwm/pwm.c | 635 +++ include/linux/pwm.h | 31 --- include/linux/pwm/pwm.h | 128 ++ 4 files changed, 1023 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 Thanks for trying (again) to get this in mainline. Are you planning to request a slot in the GIT at kernel.org to hold and maintain this nice framework? Best regards, -- Héctor Orón -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
Signed-off-by: Bill Gatliff b...@billgatliff.com --- Documentation/pwm.txt | 260 +++ drivers/pwm/pwm.c | 635 +++ include/linux/pwm.h | 31 --- include/linux/pwm/pwm.h | 128 ++ 4 files changed, 1023 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 diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt new file mode 100644 index 000..34b1e5a --- /dev/null +++ b/Documentation/pwm.txt @@ -0,0 +1,260 @@ + Generic PWM Device API + + August 5, 2010 +Bill Gatliff +b...@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
Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
Bill Gatliff b...@billgatliff.com writes: Signed-off-by: Bill Gatliff b...@billgatliff.com Hi Bill, Any plans to post this to a broader audience? maybe linux-arm-kernel? On davinci, I recently received a patch[1] for a davinci PWM layer which allows the mulitple available PWM devices on davinci to make themselves available by using the existing PWM API. It just added a pwm_add() and pwm_remove() function to the existing API to do this. Not being terribly familiar with all the PWM implementations out there, I was suprised to see that something like this didn't exist. I will ask the author of the davinci PWM code to have a look at your stuff as well. Thanks, Kevin [1] http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-September/020338.html --- Documentation/pwm.txt | 260 +++ drivers/pwm/pwm.c | 635 +++ include/linux/pwm.h | 31 --- include/linux/pwm/pwm.h | 128 ++ 4 files changed, 1023 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 diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt new file mode 100644 index 000..34b1e5a --- /dev/null +++ b/Documentation/pwm.txt @@ -0,0 +1,260 @@ + Generic PWM Device API + + August 5, 2010 +Bill Gatliff +b...@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
Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
On Fri, Oct 1, 2010 at 5:00 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Bill Gatliff b...@billgatliff.com writes: Signed-off-by: Bill Gatliff b...@billgatliff.com Hi Bill, Any plans to post this to a broader audience? maybe linux-arm-kernel? On davinci, I recently received a patch[1] for a davinci PWM layer which allows the mulitple available PWM devices on davinci to make themselves available by using the existing PWM API. It just added a pwm_add() and pwm_remove() function to the existing API to do this. Not being terribly familiar with all the PWM implementations out there, I was suprised to see that something like this didn't exist. I will ask the author of the davinci PWM code to have a look at your stuff as well. Also, Varun and Scott also have submitted PWM patches for OMAP [2] and I hope they will look at this patch set and comment. If I get a chance, and I never do, I will try these myself. I hope that baseline PWM support is accepted soon. [2] http://www.mail-archive.com/linux-embedded@vger.kernel.org/msg02851.html Thanks, Kevin [1] http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-September/020338.html --- Documentation/pwm.txt | 260 +++ drivers/pwm/pwm.c | 635 +++ include/linux/pwm.h | 31 --- include/linux/pwm/pwm.h | 128 ++ 4 files changed, 1023 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 diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt new file mode 100644 index 000..34b1e5a --- /dev/null +++ b/Documentation/pwm.txt @@ -0,0 +1,260 @@ + Generic PWM Device API + + August 5, 2010 + Bill Gatliff + b...@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
