From: nm@ti.com (Nishanth Menon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] ARM: OMAP3+: PM: VP: ensure VP is idle before disable
Date: Thu, 31 May 2012 18:35:23 -0500 [thread overview]
Message-ID: <20120531233521.GA23870@horus> (raw)
In-Reply-To: <874nqwx7gt.fsf@ti.com>
On 16:21-20120531, Kevin Hilman wrote:
> Nishanth Menon <nm@ti.com> writes:
>
> > From: Wenbiao Wang <wwang@ti.com>
> >
> > Voltage Processor state machine transition to disable need to
> > occur from IDLE state. When we transition OPP in a functioning
> > system, the call sequence for an OPP transition is as follows:
> > omap_sr_disable
> > -> sr class 3 disable
> > -> vp disable
> > -> sr disable
> > forceupdate to voltage/frequency scale depending on which OPP
> > we are transitioning to.
> >
> > If we hit a critical timing window where SR had commanded VP
> > for a voltage transition and VP is in the middle of operating
> > on that command, it needs to go through a few states before
> > going to update state(where it actually sends the command to
> > VC). Initial view of h/w owners is that the state disable of VP
> > is expected to be sampled for the next transition.
> >
> > Instead, to be on a safer side, we ensure that the valid states
> > of the VP state machine is diligently followed by software. This
> > can be done by waiting for VP to be in idle prior to disabling
> > VP. Existing prints have been updated to ensure context is
> > available on error messages.
> >
> > As part of this change, increase timeout for VP idle check to
> > improbable 500uSec to be certain that system is indeed unable
> > to continue before crashing out with error(worst case expectancy
> > remains the same 3-100uSec depending on when we caught VP).
> >
> > Cc: Tony Lindgren <tony@atomide.com>
> > Cc: Kevin Hilman <khilman@ti.com>
> > Cc: linux-omap at vger.kernel.org
> > Cc: linux-arm-kernel at lists.infradead.org
> >
> > [nm at ti.com: port from android]
> > Signed-off-by: Nishanth Menon <nm@ti.com>
> > Signed-off-by: Wenbiao Wang <wwang@ti.com>
> > ---
> > arch/arm/mach-omap2/vp.c | 15 +++++++++++++--
> > arch/arm/mach-omap2/vp.h | 2 +-
> > 2 files changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
> > index f95c1ba..925d869 100644
> > --- a/arch/arm/mach-omap2/vp.c
> > +++ b/arch/arm/mach-omap2/vp.c
> > @@ -262,6 +262,17 @@ void omap_vp_disable(struct voltagedomain *voltdm)
> > return;
> > }
> >
> > + /*
> > + * Wait for VP idle Typical latency is <2us. Maximum latency is ~100us
> > + * Depending on if we catch VP in the middle of an SR operation.
> > + */
> > + omap_test_timeout((voltdm->read(vp->vstatus)),
> > + VP_IDLE_TIMEOUT, timeout);
> > +
> > + if (timeout >= VP_IDLE_TIMEOUT)
> > + pr_warning("%s: vdd_%s idle timedout before disable\n",
> > + __func__, voltdm->name);
> > +
>
> Shouldn't this bail out here instead of continuing to disable VP?
yes - but then the entire voltage path is without error handling :(
I think the cleanup should be done independent of this patch - just
doing a return at this point might actually not effective.
>
> It would be even better to have some error recovery (or at least
> clean failure) here rather than just printing a warning and continuing.
Once VP does not idle, it is an indication that something seriously has
gone wrong in the VP state machine. VP in PRM module is reset only on
cold reset - so even a traditional arch_reset would not help us here.
The intent here is to be completely sure that VP is in idle state before
we trigger a disable. With the cleanup of all error handling flows, we
might be able to flag all the way back up to calling event (a DVFS
event) and may even be able to trigger appropriate recovery mechanism.
>
> > /* Disable VP */
> > vpconfig = voltdm->read(vp->vpconfig);
> > vpconfig &= ~vp->common->vpconfig_vpenable;
> > @@ -274,8 +285,8 @@ void omap_vp_disable(struct voltagedomain *voltdm)
> > VP_IDLE_TIMEOUT, timeout);
> >
> > if (timeout >= VP_IDLE_TIMEOUT)
> > - pr_warning("%s: vdd_%s idle timedout\n",
> > - __func__, voltdm->name);
> > + pr_warning("%s: vdd_%s idle timedout after disable\n",
> > + __func__, voltdm->name);
> >
> > vp->enabled = false;
> >
> > diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h
> > index 7c155d2..0abf895 100644
> > --- a/arch/arm/mach-omap2/vp.h
> > +++ b/arch/arm/mach-omap2/vp.h
> > @@ -31,7 +31,7 @@ struct voltagedomain;
> > #define OMAP4_VP_VDD_MPU_ID 2
> >
> > /* XXX document */
> > -#define VP_IDLE_TIMEOUT 200
> > +#define VP_IDLE_TIMEOUT 500
>
> Were you planning to insert the comment here as suggested by Eduardo?
yep. waiting in case we have more comments :)
---
Regards,
Nishanth Menon
next prev parent reply other threads:[~2012-05-31 23:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <[PATCH] ARM: OMAP3+: PM: VP: ensure VP is idle before disable>
2012-05-18 18:18 ` [PATCH V2] ARM: OMAP3+: PM: VP: ensure VP is idle before disable Nishanth Menon
2012-05-19 9:52 ` Eduardo Valentin
2012-05-21 13:36 ` Menon, Nishanth
2012-05-21 14:51 ` Eduardo Valentin
2012-05-21 15:14 ` Menon, Nishanth
2012-05-22 7:02 ` Valentin, Eduardo
2012-05-18 19:33 ` [PATCH 0/3] ARM: OMAP3+: VP: collate fixes Nishanth Menon
2012-05-18 19:33 ` [PATCH 1/3] ARM: OMAP3+: PM: VP: ensure VP is idle before disable Nishanth Menon
2012-05-31 23:21 ` Kevin Hilman
2012-05-31 23:28 ` Kevin Hilman
2012-05-31 23:35 ` Nishanth Menon [this message]
2012-05-18 19:33 ` [PATCH 2/3] ARM: OMAP3+: PM: VP: check to ensure VP is idle before forceupdate Nishanth Menon
2012-05-31 23:23 ` Kevin Hilman
2012-05-31 23:37 ` Nishanth Menon
2012-05-18 19:33 ` [PATCH 3/3] ARM: OMAP3+: PM: VP: check only the VPINIDLE status bit Nishanth Menon
2012-05-31 23:27 ` Kevin Hilman
2012-05-31 23:39 ` Nishanth Menon
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=20120531233521.GA23870@horus \
--to=nm@ti.com \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).