Re: [PATCH 1/3] PWM: add pwm framework support

[Kurt Van Dijck]

On Mon, Jul 04, 2011 at 08:43:23PM +1000, Ryan Mallon wrote:
> On 04/07/11 17:55, Sascha Hauer wrote:
> 
> If we are going to introduce a new framework for pwms then we should
> create one which meets the needs of at least all of the in kernel
> drivers. This patch series provides no solution for either the atmel or
> ep93xx drivers, so it is not a complete solution. At some point the
> api/framework _must_ be changed. If we can introduce transition layers
> then we should do that now so they we can provide a common framework
> along with some forward thinking about how the other drivers are going
[...]
> 
> The pwm framework needs to incorporate at least the following:
>  - sysfs access (ep93xx driver)
>  - Multiple channels per device (atmel driver)

These are 2 very hardware dependant additions. Is this really the job
for a framework to incorporate this?
IMHO, the job of a framework is to _allow_ such things. Creating a framework
that does _all_ special things of _all_ vendors makes such thing
complicated.

With socketCAN, we encountered a similar problem. Every chip maker
tries to create added value by means of special options. You can't
support them all in the framework. Therefore, sysfs can be added
to configure special things.
> 
> The other nice things to have for the pwm framework are:
>  - More fine grained control of pwms: pwm_period_ns, period_duty_ns, etc
>  - Polarity control
>  - Synchronisation support for multi-channel devices
>  - Interrupt handler support
>  - Sleeping vs non-sleeping configuration api
> 
> The fine-grained control api could be added now. pwm_config could be
> left as is for the time being (the new api could be a wrapper around it
> to start with). Polarity control and interrupt handling apis could also
> be defined without affecting the drivers which don't need to implement

polarity control could be implemented by taking the complement of the duty?

> them. Multiple channels and the sleeping/non-sleeping api are the more
> difficult ones, but at least having some sort of indication about how
> these plan to be solved would be useful.
> 
> ~Ryan
Kurt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/