From: Thierry Reding <thierry.reding@gmail.com>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: linux-pwm@vger.kernel.org, linux-kernel@vger.kernel.org,
alexandre.belloni@free-electrons.com,
Claudiu Beznea <claudiu.beznea@microchip.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] drivers: pwm: pwm-atmel: implement suspend/resume functions
Date: Mon, 10 Apr 2017 17:10:11 +0200 [thread overview]
Message-ID: <20170410151011.GA18753@ulmo.ba.sec> (raw)
In-Reply-To: <20170410163558.494cf9be@bbrezillon>
[-- Attachment #1.1: Type: text/plain, Size: 2566 bytes --]
On Mon, Apr 10, 2017 at 04:35:58PM +0200, Boris Brezillon wrote:
> On Mon, 10 Apr 2017 17:20:20 +0300
> Claudiu Beznea <claudiu.beznea@microchip.com> wrote:
>
> > Implement suspend and resume power management specific
> > function to allow PWM controller to correctly suspend
> > and resume.
> >
> > Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
> > ---
> > drivers/pwm/pwm-atmel.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 81 insertions(+)
> >
> > diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> > index 530d7dc..75177c6 100644
> > --- a/drivers/pwm/pwm-atmel.c
> > +++ b/drivers/pwm/pwm-atmel.c
> > @@ -58,6 +58,8 @@
> > #define PWM_MAX_PRD 0xFFFF
> > #define PRD_MAX_PRES 10
> >
> > +#define PWM_MAX_CH_NUM (4)
> > +
> > struct atmel_pwm_registers {
> > u8 period;
> > u8 period_upd;
> > @@ -65,11 +67,18 @@ struct atmel_pwm_registers {
> > u8 duty_upd;
> > };
> >
> > +struct atmel_pwm_pm_ctx {
> > + u32 cmr;
> > + u32 cdty;
> > + u32 cprd;
> > +};
> > +
> > struct atmel_pwm_chip {
> > struct pwm_chip chip;
> > struct clk *clk;
> > void __iomem *base;
> > const struct atmel_pwm_registers *regs;
> > + struct atmel_pwm_pm_ctx ctx[PWM_MAX_CH_NUM];
>
> Hm, I'm pretty sure you can rely on the current PWM state and call
> atmel_pwm_apply() at resume time instead of doing that. See what I did
> here [1].
>
> Thierry, maybe it's time to start thinking about a generic solution to
> save/restore PWM states.
Generally speaking I think applying the states are the right way to go.
Ideally the PWM core could simply resume all of the PWM channels that a
device exports and the ->apply() callback would be enough to restore
that. I'm not sure if that's going to work with current implementations,
though. Your pwm-atmel-hlcdc patch certainly indicates that we're not
quite there yet.
On the other hand, I'm beginning to think that maybe PWMs are too low-
level for this kind of suspend/resume. For example if you use the PWM to
control a backlight brightness, restoring it via the driver core's
resume hook is potentially going to turn it back on at the wrong time. I
have a feeling that we might be better off just pushing this up to the
PWM users. A slight special case might be sysfs, for which no external
user driver exists. But we already have separate data structures to keep
track of sysfs-related context, so suspend/resume support could be added
there.
Any thoughts on that?
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: thierry.reding@gmail.com (Thierry Reding)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] drivers: pwm: pwm-atmel: implement suspend/resume functions
Date: Mon, 10 Apr 2017 17:10:11 +0200 [thread overview]
Message-ID: <20170410151011.GA18753@ulmo.ba.sec> (raw)
In-Reply-To: <20170410163558.494cf9be@bbrezillon>
On Mon, Apr 10, 2017 at 04:35:58PM +0200, Boris Brezillon wrote:
> On Mon, 10 Apr 2017 17:20:20 +0300
> Claudiu Beznea <claudiu.beznea@microchip.com> wrote:
>
> > Implement suspend and resume power management specific
> > function to allow PWM controller to correctly suspend
> > and resume.
> >
> > Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
> > ---
> > drivers/pwm/pwm-atmel.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 81 insertions(+)
> >
> > diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> > index 530d7dc..75177c6 100644
> > --- a/drivers/pwm/pwm-atmel.c
> > +++ b/drivers/pwm/pwm-atmel.c
> > @@ -58,6 +58,8 @@
> > #define PWM_MAX_PRD 0xFFFF
> > #define PRD_MAX_PRES 10
> >
> > +#define PWM_MAX_CH_NUM (4)
> > +
> > struct atmel_pwm_registers {
> > u8 period;
> > u8 period_upd;
> > @@ -65,11 +67,18 @@ struct atmel_pwm_registers {
> > u8 duty_upd;
> > };
> >
> > +struct atmel_pwm_pm_ctx {
> > + u32 cmr;
> > + u32 cdty;
> > + u32 cprd;
> > +};
> > +
> > struct atmel_pwm_chip {
> > struct pwm_chip chip;
> > struct clk *clk;
> > void __iomem *base;
> > const struct atmel_pwm_registers *regs;
> > + struct atmel_pwm_pm_ctx ctx[PWM_MAX_CH_NUM];
>
> Hm, I'm pretty sure you can rely on the current PWM state and call
> atmel_pwm_apply() at resume time instead of doing that. See what I did
> here [1].
>
> Thierry, maybe it's time to start thinking about a generic solution to
> save/restore PWM states.
Generally speaking I think applying the states are the right way to go.
Ideally the PWM core could simply resume all of the PWM channels that a
device exports and the ->apply() callback would be enough to restore
that. I'm not sure if that's going to work with current implementations,
though. Your pwm-atmel-hlcdc patch certainly indicates that we're not
quite there yet.
On the other hand, I'm beginning to think that maybe PWMs are too low-
level for this kind of suspend/resume. For example if you use the PWM to
control a backlight brightness, restoring it via the driver core's
resume hook is potentially going to turn it back on at the wrong time. I
have a feeling that we might be better off just pushing this up to the
PWM users. A slight special case might be sysfs, for which no external
user driver exists. But we already have separate data structures to keep
track of sysfs-related context, so suspend/resume support could be added
there.
Any thoughts on that?
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170410/8dd56f59/attachment-0001.sig>
WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Claudiu Beznea <claudiu.beznea@microchip.com>,
linux-pwm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
alexandre.belloni@free-electrons.com,
nicolas.ferre@microchip.com
Subject: Re: [PATCH] drivers: pwm: pwm-atmel: implement suspend/resume functions
Date: Mon, 10 Apr 2017 17:10:11 +0200 [thread overview]
Message-ID: <20170410151011.GA18753@ulmo.ba.sec> (raw)
In-Reply-To: <20170410163558.494cf9be@bbrezillon>
[-- Attachment #1: Type: text/plain, Size: 2566 bytes --]
On Mon, Apr 10, 2017 at 04:35:58PM +0200, Boris Brezillon wrote:
> On Mon, 10 Apr 2017 17:20:20 +0300
> Claudiu Beznea <claudiu.beznea@microchip.com> wrote:
>
> > Implement suspend and resume power management specific
> > function to allow PWM controller to correctly suspend
> > and resume.
> >
> > Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
> > ---
> > drivers/pwm/pwm-atmel.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 81 insertions(+)
> >
> > diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> > index 530d7dc..75177c6 100644
> > --- a/drivers/pwm/pwm-atmel.c
> > +++ b/drivers/pwm/pwm-atmel.c
> > @@ -58,6 +58,8 @@
> > #define PWM_MAX_PRD 0xFFFF
> > #define PRD_MAX_PRES 10
> >
> > +#define PWM_MAX_CH_NUM (4)
> > +
> > struct atmel_pwm_registers {
> > u8 period;
> > u8 period_upd;
> > @@ -65,11 +67,18 @@ struct atmel_pwm_registers {
> > u8 duty_upd;
> > };
> >
> > +struct atmel_pwm_pm_ctx {
> > + u32 cmr;
> > + u32 cdty;
> > + u32 cprd;
> > +};
> > +
> > struct atmel_pwm_chip {
> > struct pwm_chip chip;
> > struct clk *clk;
> > void __iomem *base;
> > const struct atmel_pwm_registers *regs;
> > + struct atmel_pwm_pm_ctx ctx[PWM_MAX_CH_NUM];
>
> Hm, I'm pretty sure you can rely on the current PWM state and call
> atmel_pwm_apply() at resume time instead of doing that. See what I did
> here [1].
>
> Thierry, maybe it's time to start thinking about a generic solution to
> save/restore PWM states.
Generally speaking I think applying the states are the right way to go.
Ideally the PWM core could simply resume all of the PWM channels that a
device exports and the ->apply() callback would be enough to restore
that. I'm not sure if that's going to work with current implementations,
though. Your pwm-atmel-hlcdc patch certainly indicates that we're not
quite there yet.
On the other hand, I'm beginning to think that maybe PWMs are too low-
level for this kind of suspend/resume. For example if you use the PWM to
control a backlight brightness, restoring it via the driver core's
resume hook is potentially going to turn it back on at the wrong time. I
have a feeling that we might be better off just pushing this up to the
PWM users. A slight special case might be sysfs, for which no external
user driver exists. But we already have separate data structures to keep
track of sysfs-related context, so suspend/resume support could be added
there.
Any thoughts on that?
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2017-04-10 15:10 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-10 14:20 [PATCH] drivers: pwm: pwm-atmel: implement suspend/resume functions Claudiu Beznea
2017-04-10 14:20 ` Claudiu Beznea
2017-04-10 14:20 ` Claudiu Beznea
2017-04-10 14:35 ` Boris Brezillon
2017-04-10 14:35 ` Boris Brezillon
2017-04-10 14:35 ` Boris Brezillon
2017-04-10 15:10 ` Thierry Reding [this message]
2017-04-10 15:10 ` Thierry Reding
2017-04-10 15:10 ` Thierry Reding
2017-04-10 16:01 ` Boris Brezillon
2017-04-10 16:01 ` Boris Brezillon
2017-04-10 16:01 ` Boris Brezillon
2017-04-10 16:27 ` Boris Brezillon
2017-04-10 16:27 ` Boris Brezillon
2017-04-11 8:33 ` m18063
2017-04-11 8:33 ` m18063
2017-04-11 8:33 ` m18063
2017-04-11 8:50 ` Boris Brezillon
2017-04-11 8:50 ` Boris Brezillon
2017-04-11 8:50 ` Boris Brezillon
2017-04-11 8:59 ` m18063
2017-04-11 8:59 ` m18063
2017-04-11 8:59 ` m18063
2017-04-11 8:22 ` m18063
2017-04-11 8:22 ` m18063
2017-04-11 8:22 ` m18063
2017-04-11 8:56 ` Boris Brezillon
2017-04-11 8:56 ` Boris Brezillon
2017-04-11 8:56 ` Boris Brezillon
2017-04-11 9:41 ` m18063
2017-04-11 9:41 ` m18063
2017-04-11 9:41 ` m18063
2017-04-11 9:53 ` Boris Brezillon
2017-04-11 9:53 ` Boris Brezillon
2017-04-11 9:53 ` Boris Brezillon
2017-12-05 9:06 ` Thierry Reding
2017-12-05 9:06 ` Thierry Reding
2018-01-11 13:51 ` Claudiu Beznea
2018-01-11 13:51 ` Claudiu Beznea
2018-01-11 13:51 ` Claudiu Beznea
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=20170410151011.GA18753@ulmo.ba.sec \
--to=thierry.reding@gmail.com \
--cc=alexandre.belloni@free-electrons.com \
--cc=boris.brezillon@free-electrons.com \
--cc=claudiu.beznea@microchip.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
/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.