From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: ppc-dev <linuxppc-dev@ozlabs.org>,
linux-kernel@vger.kernel.org, Stefan Strobl <nst@gersys.de>
Subject: Re: PWM class? (was: Re: MPC52xx simple GPIO support)
Date: Fri, 12 Jun 2009 04:37:01 +0400 [thread overview]
Message-ID: <20090612003701.GA9496@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <fa686aa40906111500w1760290bm890f3ee132500b1d@mail.gmail.com>
On Thu, Jun 11, 2009 at 04:00:51PM -0600, Grant Likely wrote:
> On Wed, Jun 3, 2009 at 7:22 AM, Anton Vorontsov<avorontsov@ru.mvista.com> wrote:
> > On Wed, Jun 03, 2009 at 02:42:26PM +0200, Stefan Strobl wrote:
> > [...]
> >> The led class provides support for setting the brightness, which
> >> obviously the gpio driver doesn't support. The hardware (mpc52xx_gpt)
> >> would support it in PWM mode though. I'm now wandering how this could be
> >> best implemented.
> >>
> >> 1) - Create some PWM class similar to the GPIO class
> >> - Add support for PWM mode in mpc52xx_gpt.c that uses that PWM class
> >> - And add an interface for the LED to use the PWM class
> >>
> >> 2) - Create an LED driver that accesses the mpc52xx_gpt directly.
> >>
> >> I think I would be overwhelmed trying to implement (1) but am confident
> >> to do (2). What do you think is the right approach?
> >
> > I'd suggest creating a generic PWM class, i.e. PWMLIB, alike to
> > GPIOLIB. (2) can be an acceptable approach for now, but for the
> > long-term solution (1) is the way to go.
> >
> > The non-lib PWM API is already there, see include/linux/pwm.h,
> > and arch/arm/mach-pxa/pwm.c as an implementation example.
> >
> > Note that PXA implementation is SOC-specific, which is not very
> > good.
> >
> > So I'd suggest creating drivers/pwm/pwmlib.c, borrowing
> > ideas from gpiolib. And then we can reuse drivers/leds/leds-pwm.c
> > driver (of course, after adding appropriate OF code into it).
>
> Ugh. The referenced pwm api is about as trivial as it gets; it is an
> anonymous context pointer (anonymous struct pwm_device *) with a set
> of accessor functions. PWMs are also not nearly as common as GPIO
> pins, and I am not interested in gpiolib being duplicated for PWMs, at
> least not until there are more that just two examples of use to draw
> from.
I didn't say that we should duplicate gpiolib. I said that we
might borrow some ideas. ;-)
> If anything, I'd rather struct pwm_device be non-anonymous and contain
> a set of ops which call directly into the driver. That way is at
> least multiplatform friendly. I don't think the gpio API is the
> example to follow here. But even then I think it is premature to try
> and define a PWM api. Personally, I'd modify mpc52xx_gpt to export
> its own PWM interface for the time being using the existing GPIO
> infrastructure to find the appropriate pin.
Jon Smirl found that there were already some efforts put
into making generic PWM class:
http://thread.gmane.org/gmane.linux.kernel.embedded/1160
Briefly looking, the class is pretty cool. Somebody should just
continue this work.
> If you do decide to do a generic PWM api, then I think the way to go
> is to build it as an extension to gpiolib.
I don't think David Brownell will like this idea. But
who knows... maybe.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
WARNING: multiple messages have this Message-ID (diff)
From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Stefan Strobl <nst@gersys.de>, ppc-dev <linuxppc-dev@ozlabs.org>,
linux-kernel@vger.kernel.org
Subject: Re: PWM class? (was: Re: MPC52xx simple GPIO support)
Date: Fri, 12 Jun 2009 04:37:01 +0400 [thread overview]
Message-ID: <20090612003701.GA9496@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <fa686aa40906111500w1760290bm890f3ee132500b1d@mail.gmail.com>
On Thu, Jun 11, 2009 at 04:00:51PM -0600, Grant Likely wrote:
> On Wed, Jun 3, 2009 at 7:22 AM, Anton Vorontsov<avorontsov@ru.mvista.com> wrote:
> > On Wed, Jun 03, 2009 at 02:42:26PM +0200, Stefan Strobl wrote:
> > [...]
> >> The led class provides support for setting the brightness, which
> >> obviously the gpio driver doesn't support. The hardware (mpc52xx_gpt)
> >> would support it in PWM mode though. I'm now wandering how this could be
> >> best implemented.
> >>
> >> 1) - Create some PWM class similar to the GPIO class
> >> - Add support for PWM mode in mpc52xx_gpt.c that uses that PWM class
> >> - And add an interface for the LED to use the PWM class
> >>
> >> 2) - Create an LED driver that accesses the mpc52xx_gpt directly.
> >>
> >> I think I would be overwhelmed trying to implement (1) but am confident
> >> to do (2). What do you think is the right approach?
> >
> > I'd suggest creating a generic PWM class, i.e. PWMLIB, alike to
> > GPIOLIB. (2) can be an acceptable approach for now, but for the
> > long-term solution (1) is the way to go.
> >
> > The non-lib PWM API is already there, see include/linux/pwm.h,
> > and arch/arm/mach-pxa/pwm.c as an implementation example.
> >
> > Note that PXA implementation is SOC-specific, which is not very
> > good.
> >
> > So I'd suggest creating drivers/pwm/pwmlib.c, borrowing
> > ideas from gpiolib. And then we can reuse drivers/leds/leds-pwm.c
> > driver (of course, after adding appropriate OF code into it).
>
> Ugh. The referenced pwm api is about as trivial as it gets; it is an
> anonymous context pointer (anonymous struct pwm_device *) with a set
> of accessor functions. PWMs are also not nearly as common as GPIO
> pins, and I am not interested in gpiolib being duplicated for PWMs, at
> least not until there are more that just two examples of use to draw
> from.
I didn't say that we should duplicate gpiolib. I said that we
might borrow some ideas. ;-)
> If anything, I'd rather struct pwm_device be non-anonymous and contain
> a set of ops which call directly into the driver. That way is at
> least multiplatform friendly. I don't think the gpio API is the
> example to follow here. But even then I think it is premature to try
> and define a PWM api. Personally, I'd modify mpc52xx_gpt to export
> its own PWM interface for the time being using the existing GPIO
> infrastructure to find the appropriate pin.
Jon Smirl found that there were already some efforts put
into making generic PWM class:
http://thread.gmane.org/gmane.linux.kernel.embedded/1160
Briefly looking, the class is pretty cool. Somebody should just
continue this work.
> If you do decide to do a generic PWM api, then I think the way to go
> is to build it as an extension to gpiolib.
I don't think David Brownell will like this idea. But
who knows... maybe.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
next prev parent reply other threads:[~2009-06-12 0:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-02 17:02 MPC52xx simple GPIO support Stefan Strobl
2009-06-02 17:15 ` Anton Vorontsov
2009-06-03 12:42 ` Stefan Strobl
2009-06-03 13:22 ` PWM class? (was: Re: MPC52xx simple GPIO support) Anton Vorontsov
2009-06-03 15:38 ` Jon Smirl
2009-06-03 15:38 ` Jon Smirl
2009-06-03 15:54 ` Trilok Soni
2009-06-03 15:54 ` Trilok Soni
2009-06-11 22:00 ` Grant Likely
2009-06-11 22:00 ` Grant Likely
2009-06-12 0:37 ` Anton Vorontsov [this message]
2009-06-12 0:37 ` Anton Vorontsov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090612003701.GA9496@oksana.dev.rtsoft.ru \
--to=avorontsov@ru.mvista.com \
--cc=grant.likely@secretlab.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=nst@gersys.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.