> Yes, the goal is to remove all implementations of the old framework
> (HAVE_PWM) and replace it with PWM only implementations. I suppose we
> could in the meantime add #ifdef CONFIG_HAVE_PWM around the legacy
> functions and provide dummies in the !PWM case. That might work.
Sounds great,
On Mon, Aug 20, 2012 at 07:41:31AM +, Kim, Milo wrote:
> > Maybe we should get this resolved somehow in the meantime. Resolving
> > the
> > other issues may take another cycle or two, so you may not want to wait
> > that long.
>
> Is that job also including HAVE_PWM configurations?
> Some
> Maybe we should get this resolved somehow in the meantime. Resolving
> the
> other issues may take another cycle or two, so you may not want to wait
> that long.
Is that job also including HAVE_PWM configurations?
Some SoCs still set HAVE_PWMs and codes exist under arch/ directory.
As I far as
On Mon, Aug 20, 2012 at 06:16:41AM +, Kim, Milo wrote:
> > > * Rather than having to do the #ifdef here, I think it would be
> > better if
> > > the PWM subsystem provided stub functions for pwm_request,
> > pwm_config,
> > > pwm_enable, pwm_disable and pwm_free that do nothing, so you can
> In that case, I would recommend changing it from
>
> + /* if the pwm device exists, skip requesting the device */
> + if (drvdata->pwm)
> + return 0;
>
> to
>
> /* warn if the PWM was not released prior to reneabling it */
> WARN_ON(drvdata->pwm);
>
OK,
On Monday 20 August 2012, Kim, Milo wrote:
> > * I don't understand why you need the "if (rvdata->pwm) return 0;" case.
> > It's normally better to do the initialization exactly once from the
> > probe() function. You might want to return -EPROBE_DEFER if the pwm
> > source is not yet
> > * Rather than having to do the #ifdef here, I think it would be
> better if
> > the PWM subsystem provided stub functions for pwm_request,
> pwm_config,
> > pwm_enable, pwm_disable and pwm_free that do nothing, so you can in
> effect
> > let the compiler optimize away the above code.
>
> * Rather than having to do the #ifdef here, I think it would be better
> if
> the PWM subsystem provided stub functions for pwm_request, pwm_config,
> pwm_enable, pwm_disable and pwm_free that do nothing, so you can in
> effect
> let the compiler optimize away the above code.
Thanks a lot
* Rather than having to do the #ifdef here, I think it would be better
if
the PWM subsystem provided stub functions for pwm_request, pwm_config,
pwm_enable, pwm_disable and pwm_free that do nothing, so you can in
effect
let the compiler optimize away the above code.
Thanks a lot for
* Rather than having to do the #ifdef here, I think it would be
better if
the PWM subsystem provided stub functions for pwm_request,
pwm_config,
pwm_enable, pwm_disable and pwm_free that do nothing, so you can in
effect
let the compiler optimize away the above code.
That's
On Monday 20 August 2012, Kim, Milo wrote:
* I don't understand why you need the if (rvdata-pwm) return 0; case.
It's normally better to do the initialization exactly once from the
probe() function. You might want to return -EPROBE_DEFER if the pwm
source is not yet available though.
In that case, I would recommend changing it from
+ /* if the pwm device exists, skip requesting the device */
+ if (drvdata-pwm)
+ return 0;
to
/* warn if the PWM was not released prior to reneabling it */
WARN_ON(drvdata-pwm);
OK, thanks for
On Mon, Aug 20, 2012 at 06:16:41AM +, Kim, Milo wrote:
* Rather than having to do the #ifdef here, I think it would be
better if
the PWM subsystem provided stub functions for pwm_request,
pwm_config,
pwm_enable, pwm_disable and pwm_free that do nothing, so you can in
effect
Maybe we should get this resolved somehow in the meantime. Resolving
the
other issues may take another cycle or two, so you may not want to wait
that long.
Is that job also including HAVE_PWM configurations?
Some SoCs still set HAVE_PWMs and codes exist under arch/ directory.
As I far as
On Mon, Aug 20, 2012 at 07:41:31AM +, Kim, Milo wrote:
Maybe we should get this resolved somehow in the meantime. Resolving
the
other issues may take another cycle or two, so you may not want to wait
that long.
Is that job also including HAVE_PWM configurations?
Some SoCs still set
Yes, the goal is to remove all implementations of the old framework
(HAVE_PWM) and replace it with PWM only implementations. I suppose we
could in the meantime add #ifdef CONFIG_HAVE_PWM around the legacy
functions and provide dummies in the !PWM case. That might work.
Sounds great, thanks a
On Mon, Aug 20, 2012 at 05:37:48AM +, Arnd Bergmann wrote:
> On Monday 20 August 2012, Kim, Milo wrote:
> > +#ifdef CONFIG_PWM
> > +static int lm3530_pwm_request(struct lm3530_data *drvdata)
> > +{
> > + int pwm_id;
> > +
> > + /* if the pwm device exists, skip requesting the
On Monday 20 August 2012, Kim, Milo wrote:
> +#ifdef CONFIG_PWM
> +static int lm3530_pwm_request(struct lm3530_data *drvdata)
> +{
> + int pwm_id;
> +
> + /* if the pwm device exists, skip requesting the device */
> + if (drvdata->pwm)
> + return 0;
> +
> +
On Mon, Aug 20, 2012 at 04:02:05AM +, Kim, Milo wrote:
[...]
> diff --git a/drivers/leds/leds-lm3530.c b/drivers/leds/leds-lm3530.c
[...]
> @@ -111,6 +114,8 @@ struct lm3530_data {
> struct regulator *regulator;
> enum led_brightness brightness;
> bool enable;
> + struct
On Mon, Aug 20, 2012 at 04:02:05AM +, Kim, Milo wrote:
> use generic pwm functions for changing the duty rather than the platform data
pwm -> PWM, duty -> duty-cycle
There are more occurrences of "pwm"scattered through the file, please
fix those as well.
> @@ -153,6 +158,64 @@ static int
use generic pwm functions for changing the duty rather than the platform data
(a) add lm3530_pwm_xxx functions for supporting pwm control mode
(b) add pwm id and period in the platform data
(c) gather pwm platform data into one place
This device should be built even if the pwm mode is unused.
use generic pwm functions for changing the duty rather than the platform data
(a) add lm3530_pwm_xxx functions for supporting pwm control mode
(b) add pwm id and period in the platform data
(c) gather pwm platform data into one place
This device should be built even if the pwm mode is unused.
On Mon, Aug 20, 2012 at 04:02:05AM +, Kim, Milo wrote:
use generic pwm functions for changing the duty rather than the platform data
pwm - PWM, duty - duty-cycle
There are more occurrences of pwmscattered through the file, please
fix those as well.
@@ -153,6 +158,64 @@ static int
On Mon, Aug 20, 2012 at 04:02:05AM +, Kim, Milo wrote:
[...]
diff --git a/drivers/leds/leds-lm3530.c b/drivers/leds/leds-lm3530.c
[...]
@@ -111,6 +114,8 @@ struct lm3530_data {
struct regulator *regulator;
enum led_brightness brightness;
bool enable;
+ struct
On Monday 20 August 2012, Kim, Milo wrote:
+#ifdef CONFIG_PWM
+static int lm3530_pwm_request(struct lm3530_data *drvdata)
+{
+ int pwm_id;
+
+ /* if the pwm device exists, skip requesting the device */
+ if (drvdata-pwm)
+ return 0;
+
+ pwm_id =
On Mon, Aug 20, 2012 at 05:37:48AM +, Arnd Bergmann wrote:
On Monday 20 August 2012, Kim, Milo wrote:
+#ifdef CONFIG_PWM
+static int lm3530_pwm_request(struct lm3530_data *drvdata)
+{
+ int pwm_id;
+
+ /* if the pwm device exists, skip requesting the device */
+
26 matches
Mail list logo
