Patchwork [v3] implement a generic PWM framework

login
register
mail settings
Submitter Sascha Hauer
Date June 30, 2011, 10:41 a.m.
Message ID <1309430517-23821-1-git-send-email-s.hauer@pengutronix.de>
Download mbox
Permalink /patch/102740/
State New
Headers show

Pull-request

git://git.pengutronix.de/git/imx/linux-2.6.git pwm

Comments

Sascha Hauer - June 30, 2011, 10:41 a.m.
3rd version. No changes to the core except that I added F: drivers/pwm/ to
MAINTAINERS. Arnd, I looked through the comments to the first series again
and this was the only thing I could find I forgot. You referred to three
things. Is there more I forgot?

What changed though is the mxs pwm driver. I now register a pwm core
device which handles the shared enable register as suggested by Arnd.

Sascha

The following changes since commit b0af8dfdd67699e25083478c63eedef2e72ebd85:

  Linux 3.0-rc5 (2011-06-27 19:12:22 -0700)

are available in the git repository at:
  git://git.pengutronix.de/git/imx/linux-2.6.git pwm

Sascha Hauer (3):
      PWM: add pwm framework support
      ARM mxs: adjust pwm resources to what the driver expects
      pwm: Add a i.MX23/28 pwm driver

 Documentation/pwm.txt                        |   56 +++++
 MAINTAINERS                                  |    6 +
 arch/arm/mach-mxs/devices/platform-mxs-pwm.c |   32 +++-
 drivers/Kconfig                              |    2 +
 drivers/Makefile                             |    1 +
 drivers/pwm/Kconfig                          |   16 ++
 drivers/pwm/Makefile                         |    2 +
 drivers/pwm/core.c                           |  220 ++++++++++++++++++
 drivers/pwm/mxs-pwm.c                        |  312 ++++++++++++++++++++++++++
 include/linux/pwm.h                          |   37 +++
 10 files changed, 681 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/pwm.txt
 create mode 100644 drivers/pwm/Kconfig
 create mode 100644 drivers/pwm/Makefile
 create mode 100644 drivers/pwm/core.c
 create mode 100644 drivers/pwm/mxs-pwm.c
Bill Gatliff - June 30, 2011, 11:07 a.m.
Sascha:


I'm completely against this effort.

The objections to my submission weren't ever because I was changing
the user-visible API, so I don't think you can claim any advantage to
mine in that regard.

I will take some blame for not getting my API finished, but I have
been fighting some serious non-work issues that have consumed nearly
all of my available time--- including the professional time I would
otherwise have to invest in getting my code finished.

Is there the possibility that we could cooperate to get my patches
finished, rather than discarding and reinventing them completely?



b.g.
Arnd Bergmann - June 30, 2011, 11:42 a.m.
On Thursday 30 June 2011, Sascha Hauer wrote:
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Hi Sascha,

The probing looks good to me now. I would have added extra code to avoid
ioremapping the same page multiple times, but I see this as a matter of
different preferences, so I'm fine with that.

You are still missing a description of the driver, both in the changelog
above and in the Kconfig patch. A small sentence to spell out PWM
in the changelog and to list the devices that will use this driver
would be helpful to the causal reader.

Provided that you add that:

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 93c1052..5694574 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -2,11 +2,15 @@ menuconfig PWM
>  	bool "PWM Support"
>  	help
>  	  This enables PWM support through the generic PWM framework.
> -	  You only need to enable this, if you also want to enable
> +	  You only need to enable this if you also want to enable
>  	  one or more of the PWM drivers below.
>  
>  	  If unsure, say N.
>  

I think this hunk should have been in the other first patch.

	Arnd
Arnd Bergmann - June 30, 2011, 12:41 p.m.
On Thursday 30 June 2011, Bill Gatliff wrote:
> I'm completely against this effort.
> 
> The objections to my submission weren't ever because I was changing
> the user-visible API, so I don't think you can claim any advantage to
> mine in that regard.
> 
> I will take some blame for not getting my API finished, but I have
> been fighting some serious non-work issues that have consumed nearly
> all of my available time--- including the professional time I would
> otherwise have to invest in getting my code finished.
> 
> Is there the possibility that we could cooperate to get my patches
> finished, rather than discarding and reinventing them completely?

I've looked at your patches again, and it seems that you are doing
two distinct changes, both good:

1. You provide a generic framework for pwm drivers that makes it
possible for multiple drivers to coexist and simplifies the way
that these drivers interact with the core OS.

2. You extend and fix a number of aspects in the global PWM API.

Sascha's patch does only part 1, not part 2, but I don't think that
makes his patches any worse. The introduction of the framework
now is very similar to what you had suggested, and you should
probably be mentioned in the changelog, even though the two
implementations were done independently.

A lot of people want to see a framework get merged, and I think it's
great that Sascha has volunteered to do the work to push that
through this time, especially since you have not been able to
finish your work.

What I think would be the best plan forward is to merge Sascha's
patches as soon as we can, then get all currently existing pwm
drivers converted to that and moved to drivers/pwm, and finally
do the interface changes that you have proposed earlier.

I would also hope that you can give constructive feedback to
the submission and point out potential problems that you see
where the code should be changed now in order to make your
interface changes more easy later.

I realize that it's annoying to spend a lot of time on a specific
implementation and then see competing code get merged. Unfortunately,
this happens all the time, and the code we merge is often not
the one that has had the most effort spent on it, but the one that
looks most promising at the time when it gets merged.

	Arnd
Sascha Hauer - June 30, 2011, 3:11 p.m.
On Thu, Jun 30, 2011 at 01:42:35PM +0200, Arnd Bergmann wrote:
> On Thursday 30 June 2011, Sascha Hauer wrote:
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> 
> Hi Sascha,
> 
> The probing looks good to me now. I would have added extra code to avoid
> ioremapping the same page multiple times, but I see this as a matter of
> different preferences, so I'm fine with that.
> 
> You are still missing a description of the driver, both in the changelog
> above and in the Kconfig patch. A small sentence to spell out PWM
> in the changelog and to list the devices that will use this driver
> would be helpful to the causal reader.

Ok, will add.

> 
> Provided that you add that:
> 
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> 
> > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> > index 93c1052..5694574 100644
> > --- a/drivers/pwm/Kconfig
> > +++ b/drivers/pwm/Kconfig
> > @@ -2,11 +2,15 @@ menuconfig PWM
> >  	bool "PWM Support"
> >  	help
> >  	  This enables PWM support through the generic PWM framework.
> > -	  You only need to enable this, if you also want to enable
> > +	  You only need to enable this if you also want to enable
> >  	  one or more of the PWM drivers below.
> >  
> >  	  If unsure, say N.
> >  
> 
> I think this hunk should have been in the other first patch.

Indeed, will fix.

Sascha
Bill Gatliff - June 30, 2011, 4:17 p.m.
Guys:

On Thu, Jun 30, 2011 at 7:41 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> A lot of people want to see a framework get merged, and I think it's
> great that Sascha has volunteered to do the work to push that
> through this time, especially since you have not been able to
> finish your work.

Sascha is wasting his time by reinventing the wheel.  He's traveling
over exactly the same path I have already covered.  In fact, some of
his reviewer comments are almost word-for-word the same as those I
have received and addressed in the past.

My patches were always kept current in this mailing list and others,
and Sascha clearly has the skills necessary to make improvements and
corrections should he have chosen to do so.

> What I think would be the best plan forward is to merge Sascha's
> patches as soon as we can, then get all currently existing pwm
> drivers converted to that and moved to drivers/pwm, and finally
> do the interface changes that you have proposed earlier.

That's a real duplication of work.  That makes no sense.

> I would also hope that you can give constructive feedback to
> the submission and point out potential problems that you see
> where the code should be changed now in order to make your
> interface changes more easy later.

My code has already moved past that point.  And if I had the time to
evaluate and improve Sascha's patches, I would have the time to finish
my own.  Sascha is more than welcome to apply his efforts to the
preexisting PWM API patches already present in the LKML archives.

> I realize that it's annoying to spend a lot of time on a specific
> implementation and then see competing code get merged.

Annoyed isn't the word you are looking for.

My code has been reviewed, tested and actively used as posted in LKML
by several reviewers (including myself) in actual hardware.  We are
consciously choosing to discard a known entity and restart the whole
process with new code.  That's a waste of everyone's time and risk
exposure.

I don't consider Sascha's code to be "competing" with mine, as
apparently nobody has bothered to consider one against the other.


> Unfortunately,
> this happens all the time, and the code we merge is often not
> the one that has had the most effort spent on it, but the one that
> looks most promising at the time when it gets merged.

Your definition of "promsing" apparently correlates with "new and shiny".


b.g.
Sascha Hauer - June 30, 2011, 5:02 p.m.
Bill,

On Thu, Jun 30, 2011 at 11:17:54AM -0500, Bill Gatliff wrote:
> Guys:
> 
> On Thu, Jun 30, 2011 at 7:41 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> 
> > A lot of people want to see a framework get merged, and I think it's
> > great that Sascha has volunteered to do the work to push that
> > through this time, especially since you have not been able to
> > finish your work.
> 
> Sascha is wasting his time by reinventing the wheel.  He's traveling
> over exactly the same path I have already covered.  In fact, some of
> his reviewer comments are almost word-for-word the same as those I
> have received and addressed in the past.
> 
> My patches were always kept current in this mailing list and others,
> and Sascha clearly has the skills necessary to make improvements and
> corrections should he have chosen to do so.

I think that you made the fundamental mistake to completly ignore the
existing pwm API and its users. With a competing api we are basically
stuck. We can't convert the existing hardware drivers to the new API
because leds-pwm.c, pwm_bl.c and others still depend on the old API and
boards using it would break. We can't convert the function drivers
either because again this would break boards for which only an old style
pwm driver exists.  So the logical thing to do is to put a step in
between: Consolidate the existing drivers and *then* change the API
atomically so that nothing breaks. Your patches don't do this, so I
don't think at all that what I did is duplication of work.

Given the current rush to move drivers out of arch/ it probably won't
take long until all pwm drivers are moved to drivers/pwm/ and converted
to use the framework, and then you have a good base to put your work onto.
So please don't complain too much: We are currently only doing the work
you didn't want to do.


Sascha
Bill Gatliff - June 30, 2011, 7:45 p.m.
Sascha:

On Thu, Jun 30, 2011 at 12:02 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> So please don't complain too much: We are currently only doing the work
> you didn't want to do.

Per request of some the early reviewers, my plan was to migrate
existing users over to the new API after the API itself was committed
to mainstream.

At any rate, this isn't a question of work I didn't "want" to do.  On
the one hand, I was simply doing what was asked of me.  On the other
hand, I was trying to make progress while simultaneously dealing with
serious family matters that are still unresolved.

At any rate, it's clear that your patches are going in, and mine
aren't--- I have no choice but to accept that.  I'm just frustrated by
the duplication of effort.


b.g.
Ryan Mallon - June 30, 2011, 11:24 p.m.
On 01/07/11 03:02, Sascha Hauer wrote:
> Bill,
>
> On Thu, Jun 30, 2011 at 11:17:54AM -0500, Bill Gatliff wrote:
>> Guys:
>>
>> On Thu, Jun 30, 2011 at 7:41 AM, Arnd Bergmann<arnd@arndb.de>  wrote:
>>
>>> A lot of people want to see a framework get merged, and I think it's
>>> great that Sascha has volunteered to do the work to push that
>>> through this time, especially since you have not been able to
>>> finish your work.
>> Sascha is wasting his time by reinventing the wheel.  He's traveling
>> over exactly the same path I have already covered.  In fact, some of
>> his reviewer comments are almost word-for-word the same as those I
>> have received and addressed in the past.
>>
>> My patches were always kept current in this mailing list and others,
>> and Sascha clearly has the skills necessary to make improvements and
>> corrections should he have chosen to do so.
> I think that you made the fundamental mistake to completly ignore the
> existing pwm API and its users. With a competing api we are basically
> stuck. We can't convert the existing hardware drivers to the new API
> because leds-pwm.c, pwm_bl.c and others still depend on the old API and
> boards using it would break.

I don't think this is really a blocker to Bill's patches. There are 
three (that I can see) pwm users currently:
drivers/video/backlight/pwm_bl.c
drivers/leds/leds-pwm.c
drivers/input/misc/pwm-beeper.c

All of those drivers are trivial and good easily be updated to work with 
Bill's patches. Bill already provided a leds-pwm driver.

There is also the interesting case of the Atmel pwm driver, which does 
not fit the current pwm api and has its own backlight and leds drivers. 
Bill's patches addressed this, Sasha's patches do not. If we merge 
Sasha's patches then we are going to be in the same position as Bill's 
patches at some point in that we need to change the pwm api (and all its 
users) to meet the needs of the Atmel (and any similar hardware) pwm device.

The ep93xx pwm driver (drivers/misc/ep93xx-pwm.c) also does not fit the 
current api (though it could), but instead provides a sysfs interface to 
user-space. Again, this was addressed by Bill's patches.

> We can't convert the function drivers
> either because again this would break boards for which only an old style
> pwm driver exists.  So the logical thing to do is to put a step in
> between: Consolidate the existing drivers and *then* change the API
> atomically so that nothing breaks. Your patches don't do this, so I
> don't think at all that what I did is duplication of work.

You have to modify the drivers anyway match the new pwm core. The Atmel 
and ep93xx drivers are going to be difficult to merge into the new api, 
and seeing as there are only about seven pwm drivers total in the kernel 
I think its a significant portion. Any pwm api patchset could easily 
convert all of the existing pwm drivers without becoming overly massive.

If we merge Sasha's api, then we can move most of the existing drivers 
and maybe add some new ones, but we will still have the unconsolidated 
outliers. When (if?) we try to fix those we will probably need to change 
the pwm api and therefore all of the drivers to. So its basically a case 
of do the effort now (Bill's patches) or do it later. Doing it later 
will probably require more effort.

> Given the current rush to move drivers out of arch/ it probably won't
> take long until all pwm drivers are moved to drivers/pwm/ and converted
> to use the framework, and then you have a good base to put your work onto.
> So please don't complain too much: We are currently only doing the work
> you didn't want to do.
>

You can move all of the drivers out of arch now if you want. You just 
need to make sure you are only compiling one of them in. The real job in 
consolidating means making sure that the api meets the needs of all of 
the drivers. The in kernel Atmel pwm driver at least is not going to 
convert easily to this api.

Also, please not my change of email address for future emails.

Thanks,
~Ryan
hartleys - July 1, 2011, 12:33 a.m.
On Thursday, June 30, 2011 4:24 PM, Ryan Mallon wrote:
> On 01/07/11 03:02, Sascha Hauer wrote:
>> I think that you made the fundamental mistake to completly ignore the
>> existing pwm API and its users. With a competing api we are basically
>> stuck. We can't convert the existing hardware drivers to the new API
>> because leds-pwm.c, pwm_bl.c and others still depend on the old API and
>> boards using it would break.
>
> I don't think this is really a blocker to Bill's patches. There are 
> three (that I can see) pwm users currently:
> drivers/video/backlight/pwm_bl.c
> drivers/leds/leds-pwm.c
> drivers/input/misc/pwm-beeper.c
>
> All of those drivers are trivial and good easily be updated to work with 
> Bill's patches. Bill already provided a leds-pwm driver.

I agree with Ryan.  The three drivers listed above appear to be the only
pwm "user" drivers.  They are all trivial and could be updated easily.

The "core" drivers using the existing API appear to be:
arch/arm/mach-vt8500/pwm.c
arch/arm/plat-mxc/pwm.c
arch/arm/plat-pxa/pwm.c
arch/arm/plat-samsung/pwm.c
arch/blackfin/kernel/pwm.c
arch/mips/jz4740/pwm.c
arch/unicore32/kernel/pwm.c
drivers/misc/ab8500-pwm.c
drivers/mfd/twl6030-pwm.c

> There is also the interesting case of the Atmel pwm driver, which does 
> not fit the current pwm api and has its own backlight and leds drivers. 
> Bill's patches addressed this, Sasha's patches do not. If we merge 
> Sasha's patches then we are going to be in the same position as Bill's 
> patches at some point in that we need to change the pwm api (and all its 
> users) to meet the needs of the Atmel (and any similar hardware) pwm device.
> 
> The ep93xx pwm driver (drivers/misc/ep93xx-pwm.c) also does not fit the 
> current api (though it could), but instead provides a sysfs interface to 
> user-space. Again, this was addressed by Bill's patches.

I modified the ep93xx pwm driver previously to work with Bill's patches.
The use for that driver required user-space control of the pwm.  Bill's
patches handle that.

>> We can't convert the function drivers
>> either because again this would break boards for which only an old style
>> pwm driver exists.  So the logical thing to do is to put a step in
>> between: Consolidate the existing drivers and *then* change the API
>> atomically so that nothing breaks. Your patches don't do this, so I
>> don't think at all that what I did is duplication of work.
>
> You have to modify the drivers anyway match the new pwm core. The Atmel 
> and ep93xx drivers are going to be difficult to merge into the new api, 
> and seeing as there are only about seven pwm drivers total in the kernel 
> I think its a significant portion. Any pwm api patchset could easily 
> convert all of the existing pwm drivers without becoming overly massive.
>
> If we merge Sasha's api, then we can move most of the existing drivers 
> and maybe add some new ones, but we will still have the unconsolidated 
> outliers. When (if?) we try to fix those we will probably need to change 
> the pwm api and therefore all of the drivers to. So its basically a case 
> of do the effort now (Bill's patches) or do it later. Doing it later 
> will probably require more effort.
>
>> Given the current rush to move drivers out of arch/ it probably won't
>> take long until all pwm drivers are moved to drivers/pwm/ and converted
>> to use the framework, and then you have a good base to put your work onto.
>> So please don't complain too much: We are currently only doing the work
>> you didn't want to do.
>>
> You can move all of the drivers out of arch now if you want. You just 
> need to make sure you are only compiling one of them in. The real job in 
> consolidating means making sure that the api meets the needs of all of 
> the drivers. The in kernel Atmel pwm driver at least is not going to 
> convert easily to this api.

I think the only open issue with Bill's patches was where the pwm subsystem
belongs.  Some people thought it should be part of gpiolib and others
thought it should be on it's own.  The core library Bill presented does
share some commonality with gpiolib but I feel it still represents it's
own subsystem.  On-chip pwms might also be gpio capable but this is not
always the case.

With Bill's patches we could run into resource conflicts between gpio and
pwm but that really exists now anyway.  The pinmux subsystem that Linus
Walleij (cc'ed) has been proposing should fix that.

Overall I think Bill's patches will get us to the desired end result quicker
and save a lot of needless churn.

Regards,
Hartley
Mike Frysinger - July 1, 2011, 12:55 a.m.
On Thu, Jun 30, 2011 at 20:33, H Hartley Sweeten wrote:
> On Thursday, June 30, 2011 4:24 PM, Ryan Mallon wrote:
>> On 01/07/11 03:02, Sascha Hauer wrote:
>>> I think that you made the fundamental mistake to completly ignore the
>>> existing pwm API and its users. With a competing api we are basically
>>> stuck. We can't convert the existing hardware drivers to the new API
>>> because leds-pwm.c, pwm_bl.c and others still depend on the old API and
>>> boards using it would break.
>>
>> I don't think this is really a blocker to Bill's patches. There are
>> three (that I can see) pwm users currently:
>> drivers/video/backlight/pwm_bl.c
>> drivers/leds/leds-pwm.c
>> drivers/input/misc/pwm-beeper.c
>>
>> All of those drivers are trivial and good easily be updated to work with
>> Bill's patches. Bill already provided a leds-pwm driver.
>
> I agree with Ryan.  The three drivers listed above appear to be the only
> pwm "user" drivers.  They are all trivial and could be updated easily.

indeed ... the current pwm API is almost toy like in its simplicity.

> The "core" drivers using the existing API appear to be:
> arch/blackfin/kernel/pwm.c

i only wrote this because Bill's subsystem wasnt yet merged.  but i
made sure that it was done in such a way that it's trivial to convert
over to Bill's work once it's done.
-mike
Sascha Hauer - July 1, 2011, 7:37 a.m.
On Fri, Jul 01, 2011 at 09:24:05AM +1000, Ryan Mallon wrote:
> On 01/07/11 03:02, Sascha Hauer wrote:
> >Bill,
> >
> >On Thu, Jun 30, 2011 at 11:17:54AM -0500, Bill Gatliff wrote:
> >>Guys:
> >>
> >>On Thu, Jun 30, 2011 at 7:41 AM, Arnd Bergmann<arnd@arndb.de>  wrote:
> >>
> >>>A lot of people want to see a framework get merged, and I think it's
> >>>great that Sascha has volunteered to do the work to push that
> >>>through this time, especially since you have not been able to
> >>>finish your work.
> >>Sascha is wasting his time by reinventing the wheel.  He's traveling
> >>over exactly the same path I have already covered.  In fact, some of
> >>his reviewer comments are almost word-for-word the same as those I
> >>have received and addressed in the past.
> >>
> >>My patches were always kept current in this mailing list and others,
> >>and Sascha clearly has the skills necessary to make improvements and
> >>corrections should he have chosen to do so.
> >I think that you made the fundamental mistake to completly ignore the
> >existing pwm API and its users. With a competing api we are basically
> >stuck. We can't convert the existing hardware drivers to the new API
> >because leds-pwm.c, pwm_bl.c and others still depend on the old API and
> >boards using it would break.
> 
> I don't think this is really a blocker to Bill's patches. There are
> three (that I can see) pwm users currently:
> drivers/video/backlight/pwm_bl.c
> drivers/leds/leds-pwm.c
> drivers/input/misc/pwm-beeper.c
> 
> All of those drivers are trivial and good easily be updated to work
> with Bill's patches. Bill already provided a leds-pwm driver.

Yes, it is easy but that's not my point. The point is that you can't
convert the drivers without converting *all* hardware drivers in a
*single* step. If you choose to have two competing APIs in the tree
for one purpose you can't convert the drivers but instead you have
to copy them, either with cp or ifdefs. I have just looked at the
leds-pwm driver Bill provided. Applying it immediately breaks all
users.

> 
> There is also the interesting case of the Atmel pwm driver, which
> does not fit the current pwm api and has its own backlight and leds
> drivers. Bill's patches addressed this, Sasha's patches do not. If
> we merge Sasha's patches then we are going to be in the same
> position as Bill's patches at some point in that we need to change
> the pwm api (and all its users) to meet the needs of the Atmel (and
> any similar hardware) pwm device.

My patches are compatible to the current (user-) API on purpose. It
offers the possibility to convert each hardware driver independently
of the others. Once we have a framework we can change the driver API
independent of the user API.

> 
> The ep93xx pwm driver (drivers/misc/ep93xx-pwm.c) also does not fit
> the current api (though it could), but instead provides a sysfs
> interface to user-space. Again, this was addressed by Bill's
> patches.
> 
> >We can't convert the function drivers
> >either because again this would break boards for which only an old style
> >pwm driver exists.  So the logical thing to do is to put a step in
> >between: Consolidate the existing drivers and *then* change the API
> >atomically so that nothing breaks. Your patches don't do this, so I
> >don't think at all that what I did is duplication of work.
> 
> You have to modify the drivers anyway match the new pwm core.

Yes. But changing the user API *and* the driver API in a single patch
really is a bad idea.

I don't say at all that the end result Bill is aiming at is bad because
it isn't. We are not talking about the end result, but only the way to
get there. And getting from a to b in bisectable small steps is a well
established development model in the Kernel, or have I missed something?

> The
> Atmel and ep93xx drivers are going to be difficult to merge into the
> new api, and seeing as there are only about seven pwm drivers total
> in the kernel I think its a significant portion. Any pwm api
> patchset could easily convert all of the existing pwm drivers
> without becoming overly massive.
> 
> If we merge Sasha's api, then we can move most of the existing
> drivers and maybe add some new ones, but we will still have the
> unconsolidated outliers. When (if?) we try to fix those we will
> probably need to change the pwm api and therefore all of the drivers
> to. So its basically a case of do the effort now (Bill's patches) or
> do it later. Doing it later will probably require more effort.
> 
> >Given the current rush to move drivers out of arch/ it probably won't
> >take long until all pwm drivers are moved to drivers/pwm/ and converted
> >to use the framework, and then you have a good base to put your work onto.
> >So please don't complain too much: We are currently only doing the work
> >you didn't want to do.
> >
> 
> You can move all of the drivers out of arch now if you want. You
> just need to make sure you are only compiling one of them in.

Yes, we can. But this does not solve the migration problem I try
to describe in this and the previous mail.

Let's face it: Bill is working on his PWM patches for three years now,
still the merge of these patches is not in sight. Let's just split
them into smaller parts which are easier to swallow.

> The
> real job in consolidating means making sure that the api meets the
> needs of all of the drivers. The in kernel Atmel pwm driver at least
> is not going to convert easily to this api.

Then let's change the API. I have nothing against this.

> 
> Also, please not my change of email address for future emails.

ack

Sascha
Ryan Mallon - July 1, 2011, 8:28 a.m.
On 01/07/11 17:37, Sascha Hauer wrote:
> On Fri, Jul 01, 2011 at 09:24:05AM +1000, Ryan Mallon wrote:
>> On 01/07/11 03:02, Sascha Hauer wrote:
>>> Bill,
>>>
>>> On Thu, Jun 30, 2011 at 11:17:54AM -0500, Bill Gatliff wrote:
>>>> Guys:
>>>>
>>>> On Thu, Jun 30, 2011 at 7:41 AM, Arnd Bergmann<arnd@arndb.de>  wrote:
>>>>
>>>>> A lot of people want to see a framework get merged, and I think it's
>>>>> great that Sascha has volunteered to do the work to push that
>>>>> through this time, especially since you have not been able to
>>>>> finish your work.
>>>> Sascha is wasting his time by reinventing the wheel.  He's traveling
>>>> over exactly the same path I have already covered.  In fact, some of
>>>> his reviewer comments are almost word-for-word the same as those I
>>>> have received and addressed in the past.
>>>>
>>>> My patches were always kept current in this mailing list and others,
>>>> and Sascha clearly has the skills necessary to make improvements and
>>>> corrections should he have chosen to do so.
>>> I think that you made the fundamental mistake to completly ignore the
>>> existing pwm API and its users. With a competing api we are basically
>>> stuck. We can't convert the existing hardware drivers to the new API
>>> because leds-pwm.c, pwm_bl.c and others still depend on the old API and
>>> boards using it would break.
>> I don't think this is really a blocker to Bill's patches. There are
>> three (that I can see) pwm users currently:
>> drivers/video/backlight/pwm_bl.c
>> drivers/leds/leds-pwm.c
>> drivers/input/misc/pwm-beeper.c
>>
>> All of those drivers are trivial and good easily be updated to work
>> with Bill's patches. Bill already provided a leds-pwm driver.
> Yes, it is easy but that's not my point. The point is that you can't
> convert the drivers without converting *all* hardware drivers in a
> *single* step. If you choose to have two competing APIs in the tree
> for one purpose you can't convert the drivers but instead you have
> to copy them, either with cp or ifdefs. I have just looked at the
> leds-pwm driver Bill provided. Applying it immediately breaks all
> users.
>

At _any_ point that you change the pwm api you will need to change all
of the drivers. How do you plan to adapt the api in the future to
support the oddball pwm drivers without having to change all of the
drivers in one go?

The number of pwm drivers and users is so small that it would be nice to
see a patch series that introduces the new framework/api and converts
all of the drivers over. That way we don't get left in an intermediate
state with some drivers using the new framework and some using the old one.

>> There is also the interesting case of the Atmel pwm driver, which
>> does not fit the current pwm api and has its own backlight and leds
>> drivers. Bill's patches addressed this, Sasha's patches do not. If
>> we merge Sasha's patches then we are going to be in the same
>> position as Bill's patches at some point in that we need to change
>> the pwm api (and all its users) to meet the needs of the Atmel (and
>> any similar hardware) pwm device.
> My patches are compatible to the current (user-) API on purpose. It
> offers the possibility to convert each hardware driver independently
> of the others. Once we have a framework we can change the driver API
> independent of the user API.

We should just convert all of the drivers now rather than waiting for
the various maintainers to do it. Because your proposed api is backwards
compatible and most SoC platforms don't have additional external pwms
there is little motivation for them to do this work.

>> The ep93xx pwm driver (drivers/misc/ep93xx-pwm.c) also does not fit
>> the current api (though it could), but instead provides a sysfs
>> interface to user-space. Again, this was addressed by Bill's
>> patches.
>>
>>> We can't convert the function drivers
>>> either because again this would break boards for which only an old style
>>> pwm driver exists.  So the logical thing to do is to put a step in
>>> between: Consolidate the existing drivers and *then* change the API
>>> atomically so that nothing breaks. Your patches don't do this, so I
>>> don't think at all that what I did is duplication of work.
>> You have to modify the drivers anyway match the new pwm core.
> Yes. But changing the user API *and* the driver API in a single patch
> really is a bad idea.

It doesn't have to be in a single patch, but it should be in a single
patch series.

> I don't say at all that the end result Bill is aiming at is bad because
> it isn't. We are not talking about the end result, but only the way to
> get there. And getting from a to b in bisectable small steps is a well
> established development model in the Kernel, or have I missed something?

The bi-sectable steps is fine. But what we have is a patch series which
introduces a new framework with a vague promise that the existing
drivers will get converted and the api will be improved later. Again,
the number of in-kernel users is so small that we may as well do it all
in one series.

>> The
>> Atmel and ep93xx drivers are going to be difficult to merge into the
>> new api, and seeing as there are only about seven pwm drivers total
>> in the kernel I think its a significant portion. Any pwm api
>> patchset could easily convert all of the existing pwm drivers
>> without becoming overly massive.
>>
>> If we merge Sasha's api, then we can move most of the existing
>> drivers and maybe add some new ones, but we will still have the
>> unconsolidated outliers. When (if?) we try to fix those we will
>> probably need to change the pwm api and therefore all of the drivers
>> to. So its basically a case of do the effort now (Bill's patches) or
>> do it later. Doing it later will probably require more effort.
>>
>>> Given the current rush to move drivers out of arch/ it probably won't
>>> take long until all pwm drivers are moved to drivers/pwm/ and converted
>>> to use the framework, and then you have a good base to put your work onto.
>>> So please don't complain too much: We are currently only doing the work
>>> you didn't want to do.
>>>
>> You can move all of the drivers out of arch now if you want. You
>> just need to make sure you are only compiling one of them in.
> Yes, we can. But this does not solve the migration problem I try
> to describe in this and the previous mail.
>
> Let's face it: Bill is working on his PWM patches for three years now,
> still the merge of these patches is not in sight. Let's just split
> them into smaller parts which are easier to swallow.
>

Sure, but your series still leaves a lot of work to be done. How many
years will the ep93xx and atmel pwm drivers exist in isolation from the
rest of the pwm drivers?

~Ryan
Sascha Hauer - July 1, 2011, 8:54 a.m.
On Fri, Jul 01, 2011 at 06:28:48PM +1000, Ryan Mallon wrote:
> On 01/07/11 17:37, Sascha Hauer wrote:
> > On Fri, Jul 01, 2011 at 09:24:05AM +1000, Ryan Mallon wrote:
> >> On 01/07/11 03:02, Sascha Hauer wrote:
> >>> Bill,
> >>>
> >>> On Thu, Jun 30, 2011 at 11:17:54AM -0500, Bill Gatliff wrote:
> >>>> Guys:
> >>>>
> >>>> On Thu, Jun 30, 2011 at 7:41 AM, Arnd Bergmann<arnd@arndb.de>  wrote:
> >>>>
> >>>>> A lot of people want to see a framework get merged, and I think it's
> >>>>> great that Sascha has volunteered to do the work to push that
> >>>>> through this time, especially since you have not been able to
> >>>>> finish your work.
> >>>> Sascha is wasting his time by reinventing the wheel.  He's traveling
> >>>> over exactly the same path I have already covered.  In fact, some of
> >>>> his reviewer comments are almost word-for-word the same as those I
> >>>> have received and addressed in the past.
> >>>>
> >>>> My patches were always kept current in this mailing list and others,
> >>>> and Sascha clearly has the skills necessary to make improvements and
> >>>> corrections should he have chosen to do so.
> >>> I think that you made the fundamental mistake to completly ignore the
> >>> existing pwm API and its users. With a competing api we are basically
> >>> stuck. We can't convert the existing hardware drivers to the new API
> >>> because leds-pwm.c, pwm_bl.c and others still depend on the old API and
> >>> boards using it would break.
> >> I don't think this is really a blocker to Bill's patches. There are
> >> three (that I can see) pwm users currently:
> >> drivers/video/backlight/pwm_bl.c
> >> drivers/leds/leds-pwm.c
> >> drivers/input/misc/pwm-beeper.c
> >>
> >> All of those drivers are trivial and good easily be updated to work
> >> with Bill's patches. Bill already provided a leds-pwm driver.
> > Yes, it is easy but that's not my point. The point is that you can't
> > convert the drivers without converting *all* hardware drivers in a
> > *single* step. If you choose to have two competing APIs in the tree
> > for one purpose you can't convert the drivers but instead you have
> > to copy them, either with cp or ifdefs. I have just looked at the
> > leds-pwm driver Bill provided. Applying it immediately breaks all
> > users.
> >
> 
> At _any_ point that you change the pwm api you will need to change all
> of the drivers. How do you plan to adapt the api in the future to
> support the oddball pwm drivers without having to change all of the
> drivers in one go?

It is a framework between hardware drivers and user drivers and as such
it is able to abstract between the API to the hardware drivers and the
API to the user drivers. You can change one of those without touching
the other.

> 
> The number of pwm drivers and users is so small that it would be nice to
> see a patch series that introduces the new framework/api and converts
> all of the drivers over. That way we don't get left in an intermediate
> state with some drivers using the new framework and some using the old one.

Go ahead, send patches.

> 
> >> There is also the interesting case of the Atmel pwm driver, which
> >> does not fit the current pwm api and has its own backlight and leds
> >> drivers. Bill's patches addressed this, Sasha's patches do not. If
> >> we merge Sasha's patches then we are going to be in the same
> >> position as Bill's patches at some point in that we need to change
> >> the pwm api (and all its users) to meet the needs of the Atmel (and
> >> any similar hardware) pwm device.
> > My patches are compatible to the current (user-) API on purpose. It
> > offers the possibility to convert each hardware driver independently
> > of the others. Once we have a framework we can change the driver API
> > independent of the user API.
> 
> We should just convert all of the drivers now rather than waiting for
> the various maintainers to do it. Because your proposed api is backwards
> compatible and most SoC platforms don't have additional external pwms
> there is little motivation for them to do this work.

And with a compatible API this is an easy job. Just remove the list
handling from the drivers and put the pwm_* functions into callbacks.
The motivation to do this comes from the people who want to change
the pwm API. I volunteer to convert at least the PXA and i.MX driver.

> 
> >> The ep93xx pwm driver (drivers/misc/ep93xx-pwm.c) also does not fit
> >> the current api (though it could), but instead provides a sysfs
> >> interface to user-space. Again, this was addressed by Bill's
> >> patches.
> >>
> >>> We can't convert the function drivers
> >>> either because again this would break boards for which only an old style
> >>> pwm driver exists.  So the logical thing to do is to put a step in
> >>> between: Consolidate the existing drivers and *then* change the API
> >>> atomically so that nothing breaks. Your patches don't do this, so I
> >>> don't think at all that what I did is duplication of work.
> >> You have to modify the drivers anyway match the new pwm core.
> > Yes. But changing the user API *and* the driver API in a single patch
> > really is a bad idea.
> 
> It doesn't have to be in a single patch, but it should be in a single
> patch series.
> 
> > I don't say at all that the end result Bill is aiming at is bad because
> > it isn't. We are not talking about the end result, but only the way to
> > get there. And getting from a to b in bisectable small steps is a well
> > established development model in the Kernel, or have I missed something?
> 
> The bi-sectable steps is fine. But what we have is a patch series which
> introduces a new framework with a vague promise that the existing
> drivers will get converted and the api will be improved later. Again,
> the number of in-kernel users is so small that we may as well do it all
> in one series.

I don't understand you. On one hand you argue that it's trivial enough to
port all drivers over the a new API in a single series and on the other
hand you argue that we have to wait for several subsystem maintainers
to port the drivers over to an existing-but-now-in-a-framework API.

> 
> >> The
> >> Atmel and ep93xx drivers are going to be difficult to merge into the
> >> new api, and seeing as there are only about seven pwm drivers total
> >> in the kernel I think its a significant portion. Any pwm api
> >> patchset could easily convert all of the existing pwm drivers
> >> without becoming overly massive.
> >>
> >> If we merge Sasha's api, then we can move most of the existing
> >> drivers and maybe add some new ones, but we will still have the
> >> unconsolidated outliers. When (if?) we try to fix those we will
> >> probably need to change the pwm api and therefore all of the drivers
> >> to. So its basically a case of do the effort now (Bill's patches) or
> >> do it later. Doing it later will probably require more effort.
> >>
> >>> Given the current rush to move drivers out of arch/ it probably won't
> >>> take long until all pwm drivers are moved to drivers/pwm/ and converted
> >>> to use the framework, and then you have a good base to put your work onto.
> >>> So please don't complain too much: We are currently only doing the work
> >>> you didn't want to do.
> >>>
> >> You can move all of the drivers out of arch now if you want. You
> >> just need to make sure you are only compiling one of them in.
> > Yes, we can. But this does not solve the migration problem I try
> > to describe in this and the previous mail.
> >
> > Let's face it: Bill is working on his PWM patches for three years now,
> > still the merge of these patches is not in sight. Let's just split
> > them into smaller parts which are easier to swallow.
> >
> 
> Sure, but your series still leaves a lot of work to be done. How many
> years will the ep93xx and atmel pwm drivers exist in isolation from the
> rest of the pwm drivers?

If we continue to argue probably many years...

Sascha
Ryan Mallon - July 2, 2011, 12:40 a.m.
On 01/07/11 18:54, Sascha Hauer wrote:
> On Fri, Jul 01, 2011 at 06:28:48PM +1000, Ryan Mallon wrote:
>> On 01/07/11 17:37, Sascha Hauer wrote:
>>> On Fri, Jul 01, 2011 at 09:24:05AM +1000, Ryan Mallon wrote:
>>>> On 01/07/11 03:02, Sascha Hauer wrote:
>>>>> Bill,
>>>>>
>>>>> On Thu, Jun 30, 2011 at 11:17:54AM -0500, Bill Gatliff wrote:
>>>>>> Guys:
>>>>>>
>>>>>> On Thu, Jun 30, 2011 at 7:41 AM, Arnd Bergmann<arnd@arndb.de>  wrote:
>>>>>>
>>>>>>> A lot of people want to see a framework get merged, and I think it's
>>>>>>> great that Sascha has volunteered to do the work to push that
>>>>>>> through this time, especially since you have not been able to
>>>>>>> finish your work.
>>>>>> Sascha is wasting his time by reinventing the wheel.  He's traveling
>>>>>> over exactly the same path I have already covered.  In fact, some of
>>>>>> his reviewer comments are almost word-for-word the same as those I
>>>>>> have received and addressed in the past.
>>>>>>
>>>>>> My patches were always kept current in this mailing list and others,
>>>>>> and Sascha clearly has the skills necessary to make improvements and
>>>>>> corrections should he have chosen to do so.
>>>>> I think that you made the fundamental mistake to completly ignore the
>>>>> existing pwm API and its users. With a competing api we are basically
>>>>> stuck. We can't convert the existing hardware drivers to the new API
>>>>> because leds-pwm.c, pwm_bl.c and others still depend on the old API and
>>>>> boards using it would break.
>>>> I don't think this is really a blocker to Bill's patches. There are
>>>> three (that I can see) pwm users currently:
>>>> drivers/video/backlight/pwm_bl.c
>>>> drivers/leds/leds-pwm.c
>>>> drivers/input/misc/pwm-beeper.c
>>>>
>>>> All of those drivers are trivial and good easily be updated to work
>>>> with Bill's patches. Bill already provided a leds-pwm driver.
>>> Yes, it is easy but that's not my point. The point is that you can't
>>> convert the drivers without converting *all* hardware drivers in a
>>> *single* step. If you choose to have two competing APIs in the tree
>>> for one purpose you can't convert the drivers but instead you have
>>> to copy them, either with cp or ifdefs. I have just looked at the
>>> leds-pwm driver Bill provided. Applying it immediately breaks all
>>> users.
>>>
>> At _any_ point that you change the pwm api you will need to change all
>> of the drivers. How do you plan to adapt the api in the future to
>> support the oddball pwm drivers without having to change all of the
>> drivers in one go?
> It is a framework between hardware drivers and user drivers and as such
> it is able to abstract between the API to the hardware drivers and the
> API to the user drivers. You can change one of those without touching
> the other.

You are missing the point. For example, the current in-kernel api to
configure a pwm is this:

int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns);

Bill's proposed change to the api, which is more flexible, looks like this:

int pwm_config(struct pwm_channel *p,
        struct pwm_channel_config *c)

If you want to change the api in this way at any time, you will need to
change all of the pwm drivers and all of the users (pwm-bl, pwm-leds,
etc) at the same time, or introduce some sort of wrapper layer to ease
the conversion. Either way, if you do it now or do it after your patch
set it is still the same amount of work.

We do want a better api for pwm drivers, if only to support oddball
hardware like the atmel. The process I see is this if we go with Bill's
patches:
 - Introduce new api with common framework
 - Move drivers to new api

With your patches we get this:
 - Introduce common framework
 - Move drivers to common framework
 - Modify api
 - Rewrite drivers for new api

The problem we have seen with these processes in the past is they get
left half way with some drivers moving to the new framework and some
trailing behind and some having their own hand-rolled approach because
the common api doesn't meet their needs.

>>> I don't say at all that the end result Bill is aiming at is bad because
>>> it isn't. We are not talking about the end result, but only the way to
>>> get there. And getting from a to b in bisectable small steps is a well
>>> established development model in the Kernel, or have I missed something?
>> The bi-sectable steps is fine. But what we have is a patch series which
>> introduces a new framework with a vague promise that the existing
>> drivers will get converted and the api will be improved later. Again,
>> the number of in-kernel users is so small that we may as well do it all
>> in one series.
> I don't understand you. On one hand you argue that it's trivial enough to
> port all drivers over the a new API in a single series and on the other
> hand you argue that we have to wait for several subsystem maintainers
> to port the drivers over to an existing-but-now-in-a-framework API.
>

No, I am saying that if we don't port all the drivers and leave it up to
the maintainers then it won't get done and we get left with some drivers
using the old approach and some using the new approach. For example, we
still have platforms which aren't using gpiolib yet and that was
introduced 3 years ago.

~Ryan
Sascha Hauer - July 4, 2011, 7:55 a.m.
On Sat, Jul 02, 2011 at 10:40:54AM +1000, Ryan Mallon wrote:
> On 01/07/11 18:54, Sascha Hauer wrote:
> >> At _any_ point that you change the pwm api you will need to change all
> >> of the drivers. How do you plan to adapt the api in the future to
> >> support the oddball pwm drivers without having to change all of the
> >> drivers in one go?
> > It is a framework between hardware drivers and user drivers and as such
> > it is able to abstract between the API to the hardware drivers and the
> > API to the user drivers. You can change one of those without touching
> > the other.
> 
> You are missing the point. For example, the current in-kernel api to
> configure a pwm is this:
> 
> int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns);
> 
> Bill's proposed change to the api, which is more flexible, looks like this:
> 
> int pwm_config(struct pwm_channel *p,
>         struct pwm_channel_config *c)
> 
> If you want to change the api in this way at any time, you will need to
> change all of the pwm drivers and all of the users (pwm-bl, pwm-leds,
> etc) at the same time, or introduce some sort of wrapper layer to ease
> the conversion. Either way, if you do it now or do it after your patch
> set it is still the same amount of work.
> 
> We do want a better api for pwm drivers, if only to support oddball
> hardware like the atmel. The process I see is this if we go with Bill's
> patches:
>  - Introduce new api with common framework

I'm repeating myself. At this point you can't convert any of the old
drivers because it breaks the support we already have.

>  - Move drivers to new api

And that's one single step. To be really bisectible have would have to
convert *all* PWM drivers in a single patch, not even a patch series
as it would break bisectibility in between.

> 
> With your patches we get this:
>  - Introduce common framework

And still everything works

>  - Move drivers to common framework

One after another, still everything works

>  - Modify api
>  - Rewrite drivers for new api

There are two of them. One for the hardware drivers and one for the
users. You can change them independently, introduce wrappers where
necessary, you have all the time in the world to do this.

Your aim is to change the API? Then you have to clean up first. People
like Thomas have cleaned up in all areas of the kernel to reach their
goal of merging the RT stuff. They wouldn't have got anywhere with
a here's-a-patch-that-changes-everything approach.

> 
> The problem we have seen with these processes in the past is they get
> left half way with some drivers moving to the new framework and some
> trailing behind and some having their own hand-rolled approach because
> the common api doesn't meet their needs.

With two competing APIs it's even worse because you can't go anywhere
without converting everything in tree.

Just imagine Bill or someone else comes up with a series

PATCH: introduce new pwm framework with completely changed API, sysfs
interface and interrupt support, also convert leds-pwm, pwm_bl, pwm-beeper
to new API and convert all hardware drivers to new API aswell.

What do you think would happen? I can think of two things: Either no
reaction at all from others or a huge thread with no result at all
because we can't agree on details. Then someone comes up with the
recommendation to start small and do it in little steps.


I am tired of discussing this. It seems we can't agree and unless
someone else jumps in here we will probably have to wait for another
year until something moves in the PWM area.

Sascha
Dmitry Eremin-Solenikov - July 4, 2011, 8:50 a.m.
Sascha Hauer wrote:

> I am tired of discussing this. It seems we can't agree and unless
> someone else jumps in here we will probably have to wait for another
> year until something moves in the PWM area.

Please continue your work on PWM area! Patch reviews show a really
positive attitute towards merging your patchset. Please don't stop here!
Ryan Mallon - July 4, 2011, 10:43 a.m.
On 04/07/11 17:55, Sascha Hauer wrote:
> I am tired of discussing this. It seems we can't agree and unless
> someone else jumps in here we will probably have to wait for another
> year until something moves in the PWM area.

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
to be migrated to the new framework. This patch series doesn't even
migrate _any_ of the existing drivers.

It doesn't have to be an all or nothing approach. Possibly Bill's series
is perhaps too involved by changing the api, introducing sysfs support
and reworking the pwm users. But your series is at the opposite end of
the spectrum. It does too little. It will take a few release cycles to
get all of the existing drivers migrated and since we can't change the
api until that happens the atmel and ep93xx drivers will take longer
still. At the very least your series should migrate some of the drivers.

The timeline argument is a bit poor. Yes, there has been discussion for
a lengthy time about how the pwm api should be developed, but I think
that is because it is non-trivial to come up with a framework which is
good enough to support all of the pwm hardware (some of which is already
in the mainline). Getting something merged now just because it can be
done quickly is not a good idea if it all has to get reworked in the
future so that it can support all the hardware.

The pwm framework needs to incorporate at least the following:
 - sysfs access (ep93xx driver)
 - Multiple channels per device (atmel driver)

The mxs driver you introduce looks like it could be implemented as a
single device (continuous mmio space) with multiple channels rather than
the pwm core/driver approach you have. I also can't see anything in this
patch set which hooks up the mxs pwms to an actual board (i.e. nothing
calls mxs_add_mxs_pwm)?

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
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
Sascha Hauer - July 4, 2011, 12:43 p.m.
On Mon, Jul 04, 2011 at 08:43:23PM +1000, Ryan Mallon wrote:
> On 04/07/11 17:55, Sascha Hauer wrote:
> > I am tired of discussing this. It seems we can't agree and unless
> > someone else jumps in here we will probably have to wait for another
> > year until something moves in the PWM area.
> 
> 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
> to be migrated to the new framework. This patch series doesn't even
> migrate _any_ of the existing drivers.
> 
> It doesn't have to be an all or nothing approach. Possibly Bill's series
> is perhaps too involved by changing the api, introducing sysfs support
> and reworking the pwm users. But your series is at the opposite end of
> the spectrum. It does too little. It will take a few release cycles to
> get all of the existing drivers migrated and since we can't change the
> api until that happens the atmel and ep93xx drivers will take longer
> still. At the very least your series should migrate some of the drivers.
> 
> The timeline argument is a bit poor. Yes, there has been discussion for
> a lengthy time about how the pwm api should be developed, but I think
> that is because it is non-trivial to come up with a framework which is
> good enough to support all of the pwm hardware (some of which is already
> in the mainline). Getting something merged now just because it can be
> done quickly is not a good idea if it all has to get reworked in the
> future so that it can support all the hardware.
> 
> The pwm framework needs to incorporate at least the following:
>  - sysfs access (ep93xx driver)

The sysfs interface will likely raise smoe more discussion, that's why I
intentionally have no support for it. It can be added later, but right
now I see no reason why we should add artificial barriers to merge these
patches.

>  - Multiple channels per device (atmel driver)

Again, this can be added later.

> 
> The mxs driver you introduce looks like it could be implemented as a
> single device (continuous mmio space) with multiple channels rather than
> the pwm core/driver approach you have. I also can't see anything in this
> patch set which hooks up the mxs pwms to an actual board (i.e. nothing
> calls mxs_add_mxs_pwm)?

Why should anyone register a device for which no driver is in the tree?

> 
> 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
> 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.

Again, why should we add these *now*? It only raises the chance that
there's more discussion.

Sascha
Arnd Bergmann - July 4, 2011, 1:53 p.m.
On Monday 04 July 2011, Kurt Van Dijck wrote:
> > 
> > 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.

I think you shouldn't make it too easy for drivers to add extra
sysfs files. If at all possible, the default should be to add
them to the core, and define them in a way that makes sense for
future similar drivers.

We need to be careful to avoid a situation where multiple driver
writers introduce the same feature with a sysfs attribute, but do
so in an incompatible way.

> 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.

I would expect that pwm is much simpler than CAN, so the amount
of creativity there is also limited.

	Arnd
Arnd Bergmann - July 4, 2011, 2:07 p.m.
On Monday 04 July 2011, Sascha Hauer wrote:
> On Mon, Jul 04, 2011 at 08:43:23PM +1000, Ryan Mallon wrote:
>
> > 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
> > 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.
> 
> Again, why should we add these *now*? It only raises the chance that
> there's more discussion.

My impression is that there are a lot of things that could easily be
done to improve the state of PWM drivers, but I don't care about the
order in which they are done. My main issue is the lack of a subsystem
core driver, which both you and Bill have patches for. It's clear that
other people have other issues and want to see their problems addressed
first.

I also think that the pwm code is simple enough that we don't have
to worry too much about the order that things are done in. Any patch
that is making the code better should just get in and not have to
wait for something else to be completed first.

What we do need now is a maintainer that can coordinate the patches
and merge the ones that have been agreed on. Or multiple maintainers.

	Arnd
Thierry Reding - Dec. 7, 2011, 8:53 a.m.
* Arnd Bergmann wrote:
> On Monday 04 July 2011, Sascha Hauer wrote:
> > On Mon, Jul 04, 2011 at 08:43:23PM +1000, Ryan Mallon wrote:
> >
> > > 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
> > > 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.
> > 
> > Again, why should we add these *now*? It only raises the chance that
> > there's more discussion.
> 
> My impression is that there are a lot of things that could easily be
> done to improve the state of PWM drivers, but I don't care about the
> order in which they are done. My main issue is the lack of a subsystem
> core driver, which both you and Bill have patches for. It's clear that
> other people have other issues and want to see their problems addressed
> first.
> 
> I also think that the pwm code is simple enough that we don't have
> to worry too much about the order that things are done in. Any patch
> that is making the code better should just get in and not have to
> wait for something else to be completed first.
> 
> What we do need now is a maintainer that can coordinate the patches
> and merge the ones that have been agreed on. Or multiple maintainers.

Hi,

I'm looking at adding DT support for pwm-backlight, and I think a central PWM
API will be required first. Looking through the archives this seems to be the
last activity in that direction. Perhaps we can get the efforts restarted?

I pretty much agree with Arnd and Sascha here in that we should try to get a
basic framework added. Everything else can be added on top later.

Thierry