From: Tomasz Figa <tomasz.figa@gmail.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: ben-linux@fluff.org, kgene.kim@samsung.com,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org
Subject: Re: [PATCH 1/2] ARM: s3c64xx: cpuidle: convert to platform driver
Date: Fri, 25 Oct 2013 22:52:27 +0200 [thread overview]
Message-ID: <1953577.TBW5ixuUM5@thinkpad> (raw)
In-Reply-To: <526AC2DF.2020904@linaro.org>
On Friday 25 of October 2013 21:13:35 Daniel Lezcano wrote:
> On 10/25/2013 12:39 PM, Tomasz Figa wrote:
> > Hi Daniel,
> >
> > [Sending again, without HTML part. Sorry for the noise.]
> >
> > On Friday 25 of October 2013 09:11:13 Daniel Lezcano wrote:
> >> The driver is tied with the pm low level code making difficult to
> >> split
> >> the driver into a more arch independent code. The platform driver
> >> allows
> >> to move the standby callback into the platform data field and use a
> >> simple driver with no more dependency on the low level code.
> >>
> >> The standby callback has a portion of code to set the standby method
> >> and
> >> the effective cpu_do_idle switching the cpu to the right mode. As this
> >> code is redundant in the cpu suspend code, it has been factored out
> >> when
> >> implementing the standby methdod.
> >>
> >> By this way, the driver is ready to be moved out to the
> >> drivers/cpuidle.
> >
> > The idea itself is quite good, but unfortunately I have to NAK this.
> > Please see details in comments below.
> >
> >> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> >> ---
> >>
> >> arch/arm/mach-s3c64xx/cpuidle.c | 38
> >>
> >> ++++++++++++++++---------------------- arch/arm/mach-s3c64xx/pm.c
> >> |
> >>
> >> 33 ++++++++++++++++++++++++++------- 2 files changed, 42
> >>
> >> insertions(+), 29 deletions(-)
>
> [ ... ]
>
> >> -
> >> - tmp = __raw_readl(S3C64XX_PWR_CFG);
> >> - tmp &= ~S3C64XX_PWRCFG_CFG_WFI_MASK;
> >> - tmp |= S3C64XX_PWRCFG_CFG_WFI_SLEEP;
> >
> > Finally note the S3C64XX_PWRCFG_CFG_WFI_SLEEP flag here again.
>
> Ouch ! I missed it. Thanks for spotting the problem.
>
> > I believe it should be visible now what's wrong with this patch. To
> > make
> > sure it is, let me explain how the system controller of S3C64xx handles
> > WFI requests.
> >
> > When the CPU issues WFI request to the syscon, it takes an action
> > depending on how it is configured. A bit field is there in one of
> > syscon registers (S3C64XX_PWR_CFG) that selects what action to perform
> > in case of WFI request.
> >
> > You can program the syscon to ignore the request, enter IDLE mode,
> > enter
> > STOP mode or enter SLEEP mode. As the names suggest, for cpuidle, it
> > needs to be programmed for IDLE mode and for system-wide sleep it
> > needs to be set to SLEEP mode. STOP mode is not very useful as it has
> > mostly the same effect that can be achieved by performing fine-grained
> > clock and power gating of peripherals manually, so it is unused by
> > Linux.
>
> Yes, this is what I assumed but I missed the CFG_WFI_SLEEP flag, my eyes
> read CFG_WFI_IDLE.
>
> > Now, my take on the issue you are trying to solve would be a bit
> > different. Since the S3C64xx does not have any interesting cpuidle
> > modes, just a normal, clock-gated WFI mode, it does not need to have a
> > cpuidle driver at all. All that is needed is simply setting up the
> > S3C64XX_PWRCFG_CFG_WFI field to S3C64XX_PWRCFG_CFG_WFI_IDLE early at
> > boot-up, then set it to S3C64XX_PWRCFG_CFG_WFI_SLEEP just before
> > entering the sleep mode and restore it back to
> > S3C64XX_PWRCFG_CFG_WFI_IDLE after waking up.
> So you are suggesting to remove the cpuidle driver ?
Exactly.
>
> Won't it be worth to add a new WFI_SLEEP state to the cpuidle driver ?
I don't think so. How a suspend-to-RAM specific thing like WFI_SLEEP could
be relevant to a cpuidle driver? (Unless there are some plans to
consolidate STR with cpuidle that I haven't heard about...)
Best regards,
Tomasz
WARNING: multiple messages have this Message-ID (diff)
From: tomasz.figa@gmail.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] ARM: s3c64xx: cpuidle: convert to platform driver
Date: Fri, 25 Oct 2013 22:52:27 +0200 [thread overview]
Message-ID: <1953577.TBW5ixuUM5@thinkpad> (raw)
In-Reply-To: <526AC2DF.2020904@linaro.org>
On Friday 25 of October 2013 21:13:35 Daniel Lezcano wrote:
> On 10/25/2013 12:39 PM, Tomasz Figa wrote:
> > Hi Daniel,
> >
> > [Sending again, without HTML part. Sorry for the noise.]
> >
> > On Friday 25 of October 2013 09:11:13 Daniel Lezcano wrote:
> >> The driver is tied with the pm low level code making difficult to
> >> split
> >> the driver into a more arch independent code. The platform driver
> >> allows
> >> to move the standby callback into the platform data field and use a
> >> simple driver with no more dependency on the low level code.
> >>
> >> The standby callback has a portion of code to set the standby method
> >> and
> >> the effective cpu_do_idle switching the cpu to the right mode. As this
> >> code is redundant in the cpu suspend code, it has been factored out
> >> when
> >> implementing the standby methdod.
> >>
> >> By this way, the driver is ready to be moved out to the
> >> drivers/cpuidle.
> >
> > The idea itself is quite good, but unfortunately I have to NAK this.
> > Please see details in comments below.
> >
> >> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> >> ---
> >>
> >> arch/arm/mach-s3c64xx/cpuidle.c | 38
> >>
> >> ++++++++++++++++---------------------- arch/arm/mach-s3c64xx/pm.c
> >> |
> >>
> >> 33 ++++++++++++++++++++++++++------- 2 files changed, 42
> >>
> >> insertions(+), 29 deletions(-)
>
> [ ... ]
>
> >> -
> >> - tmp = __raw_readl(S3C64XX_PWR_CFG);
> >> - tmp &= ~S3C64XX_PWRCFG_CFG_WFI_MASK;
> >> - tmp |= S3C64XX_PWRCFG_CFG_WFI_SLEEP;
> >
> > Finally note the S3C64XX_PWRCFG_CFG_WFI_SLEEP flag here again.
>
> Ouch ! I missed it. Thanks for spotting the problem.
>
> > I believe it should be visible now what's wrong with this patch. To
> > make
> > sure it is, let me explain how the system controller of S3C64xx handles
> > WFI requests.
> >
> > When the CPU issues WFI request to the syscon, it takes an action
> > depending on how it is configured. A bit field is there in one of
> > syscon registers (S3C64XX_PWR_CFG) that selects what action to perform
> > in case of WFI request.
> >
> > You can program the syscon to ignore the request, enter IDLE mode,
> > enter
> > STOP mode or enter SLEEP mode. As the names suggest, for cpuidle, it
> > needs to be programmed for IDLE mode and for system-wide sleep it
> > needs to be set to SLEEP mode. STOP mode is not very useful as it has
> > mostly the same effect that can be achieved by performing fine-grained
> > clock and power gating of peripherals manually, so it is unused by
> > Linux.
>
> Yes, this is what I assumed but I missed the CFG_WFI_SLEEP flag, my eyes
> read CFG_WFI_IDLE.
>
> > Now, my take on the issue you are trying to solve would be a bit
> > different. Since the S3C64xx does not have any interesting cpuidle
> > modes, just a normal, clock-gated WFI mode, it does not need to have a
> > cpuidle driver at all. All that is needed is simply setting up the
> > S3C64XX_PWRCFG_CFG_WFI field to S3C64XX_PWRCFG_CFG_WFI_IDLE early at
> > boot-up, then set it to S3C64XX_PWRCFG_CFG_WFI_SLEEP just before
> > entering the sleep mode and restore it back to
> > S3C64XX_PWRCFG_CFG_WFI_IDLE after waking up.
> So you are suggesting to remove the cpuidle driver ?
Exactly.
>
> Won't it be worth to add a new WFI_SLEEP state to the cpuidle driver ?
I don't think so. How a suspend-to-RAM specific thing like WFI_SLEEP could
be relevant to a cpuidle driver? (Unless there are some plans to
consolidate STR with cpuidle that I haven't heard about...)
Best regards,
Tomasz
next prev parent reply other threads:[~2013-10-25 20:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-25 7:11 [PATCH 1/2] ARM: s3c64xx: cpuidle: convert to platform driver Daniel Lezcano
2013-10-25 7:11 ` Daniel Lezcano
2013-10-25 7:11 ` [PATCH 2/2] ARM: s3c64xx: cpuidle: move driver to drivers/cpuidle Daniel Lezcano
2013-10-25 7:11 ` Daniel Lezcano
2013-10-25 10:39 ` [PATCH 1/2] ARM: s3c64xx: cpuidle: convert to platform driver Tomasz Figa
2013-10-25 10:39 ` Tomasz Figa
2013-10-25 19:13 ` Daniel Lezcano
2013-10-25 19:13 ` Daniel Lezcano
2013-10-25 20:52 ` Tomasz Figa [this message]
2013-10-25 20:52 ` Tomasz Figa
2013-10-25 22:23 ` Daniel Lezcano
2013-10-25 22:23 ` Daniel Lezcano
2013-10-30 21:43 ` Daniel Lezcano
2013-10-30 21:43 ` Daniel Lezcano
2013-10-30 22:40 ` Tomasz Figa
2013-10-30 22:40 ` Tomasz Figa
2013-10-30 22:50 ` Daniel Lezcano
2013-10-30 22:50 ` Daniel Lezcano
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=1953577.TBW5ixuUM5@thinkpad \
--to=tomasz.figa@gmail.com \
--cc=ben-linux@fluff.org \
--cc=daniel.lezcano@linaro.org \
--cc=kgene.kim@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-samsung-soc@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.