* [PATCH 0/3] ARM: OMAP3+: VP: collate fixes
@ 2012-05-18 19:33 ` Nishanth Menon
0 siblings, 0 replies; 34+ messages in thread
From: Nishanth Menon @ 2012-05-18 19:33 UTC (permalink / raw)
To: linux-arm-kernel
Reviewing the android code base brought out a few fixes that upstream
does not have, so collating them and posting them out in this chain.
Nishanth Menon (2):
ARM: OMAP3+: PM: VP: check to ensure VP is idle before forceupdate
ARM: OMAP3+: PM: VP: check only the VPINIDLE status bit
Wenbiao Wang (1):
ARM: OMAP3+: PM: VP: ensure VP is idle before disable
arch/arm/mach-omap2/vp.c | 34 ++++++++++++++++++++++++++++++----
arch/arm/mach-omap2/vp.h | 3 ++-
arch/arm/mach-omap2/vp3xxx_data.c | 1 +
arch/arm/mach-omap2/vp44xx_data.c | 1 +
4 files changed, 34 insertions(+), 5 deletions(-)
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
Regards,
Nishanth Menon
--
1.7.9.5
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 1/3] ARM: OMAP3+: PM: VP: ensure VP is idle before disable
2012-05-18 19:33 ` Nishanth Menon
@ 2012-05-18 19:33 ` Nishanth Menon
-1 siblings, 0 replies; 34+ messages in thread
From: Nishanth Menon @ 2012-05-18 19:33 UTC (permalink / raw)
To: Kevin Hilman
Cc: Wenbiao Wang, Tony Lindgren, linux-omap, linux-arm-kernel,
Nishanth Menon
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@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
[nm@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);
+
/* 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
#define VP_TRANXDONE_TIMEOUT 300
/**
--
1.7.9.5
^ permalink raw reply related [flat|nested] 34+ messages in thread* [PATCH 1/3] ARM: OMAP3+: PM: VP: ensure VP is idle before disable
@ 2012-05-18 19:33 ` Nishanth Menon
0 siblings, 0 replies; 34+ messages in thread
From: Nishanth Menon @ 2012-05-18 19:33 UTC (permalink / raw)
To: linux-arm-kernel
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);
+
/* 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
#define VP_TRANXDONE_TIMEOUT 300
/**
--
1.7.9.5
^ permalink raw reply related [flat|nested] 34+ messages in thread* Re: [PATCH 1/3] ARM: OMAP3+: PM: VP: ensure VP is idle before disable
2012-05-18 19:33 ` Nishanth Menon
@ 2012-05-31 23:21 ` Kevin Hilman
-1 siblings, 0 replies; 34+ messages in thread
From: Kevin Hilman @ 2012-05-31 23:21 UTC (permalink / raw)
To: Nishanth Menon; +Cc: Wenbiao Wang, Tony Lindgren, linux-omap, linux-arm-kernel
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@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
>
> [nm@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?
It would be even better to have some error recovery (or at least
clean failure) here rather than just printing a warning and continuing.
> /* 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?
Kevin
> #define VP_TRANXDONE_TIMEOUT 300
>
> /**
^ permalink raw reply [flat|nested] 34+ messages in thread* [PATCH 1/3] ARM: OMAP3+: PM: VP: ensure VP is idle before disable
@ 2012-05-31 23:21 ` Kevin Hilman
0 siblings, 0 replies; 34+ messages in thread
From: Kevin Hilman @ 2012-05-31 23:21 UTC (permalink / raw)
To: linux-arm-kernel
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?
It would be even better to have some error recovery (or at least
clean failure) here rather than just printing a warning and continuing.
> /* 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?
Kevin
> #define VP_TRANXDONE_TIMEOUT 300
>
> /**
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [PATCH 1/3] ARM: OMAP3+: PM: VP: ensure VP is idle before disable
2012-05-31 23:21 ` Kevin Hilman
@ 2012-05-31 23:28 ` Kevin Hilman
-1 siblings, 0 replies; 34+ messages in thread
From: Kevin Hilman @ 2012-05-31 23:28 UTC (permalink / raw)
To: Kevin Hilman
Cc: Nishanth Menon, Wenbiao Wang, Tony Lindgren, linux-omap,
linux-arm-kernel
On 05/31/2012 04:21 PM, Kevin Hilman wrote:
>> 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?
Oops, ignore this comment. I see you posted a v3 with this added.
Sorry,
Kevin
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 1/3] ARM: OMAP3+: PM: VP: ensure VP is idle before disable
@ 2012-05-31 23:28 ` Kevin Hilman
0 siblings, 0 replies; 34+ messages in thread
From: Kevin Hilman @ 2012-05-31 23:28 UTC (permalink / raw)
To: linux-arm-kernel
On 05/31/2012 04:21 PM, Kevin Hilman wrote:
>> 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?
Oops, ignore this comment. I see you posted a v3 with this added.
Sorry,
Kevin
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/3] ARM: OMAP3+: PM: VP: ensure VP is idle before disable
2012-05-31 23:21 ` Kevin Hilman
@ 2012-05-31 23:35 ` Nishanth Menon
-1 siblings, 0 replies; 34+ messages in thread
From: Nishanth Menon @ 2012-05-31 23:35 UTC (permalink / raw)
To: Kevin Hilman; +Cc: Wenbiao Wang, Tony Lindgren, linux-omap, linux-arm-kernel
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@vger.kernel.org
> > Cc: linux-arm-kernel@lists.infradead.org
> >
> > [nm@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
^ permalink raw reply [flat|nested] 34+ messages in thread* [PATCH 1/3] ARM: OMAP3+: PM: VP: ensure VP is idle before disable
@ 2012-05-31 23:35 ` Nishanth Menon
0 siblings, 0 replies; 34+ messages in thread
From: Nishanth Menon @ 2012-05-31 23:35 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 2/3] ARM: OMAP3+: PM: VP: check to ensure VP is idle before forceupdate
2012-05-18 19:33 ` Nishanth Menon
@ 2012-05-18 19:33 ` Nishanth Menon
-1 siblings, 0 replies; 34+ messages in thread
From: Nishanth Menon @ 2012-05-18 19:33 UTC (permalink / raw)
To: Kevin Hilman
Cc: Nishanth Menon, Tony Lindgren, linux-omap, linux-arm-kernel,
Vinay Amancha
Ideally in the flow of DVFS programming, VP should be in idle state
(since we disabled it) before entering forceupdate. Ensure that
this is the case. Not doing this could cause VP statemachine
to enter invalid states.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Vinay Amancha <vinaykumar@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-omap2/vp.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 925d869..985091b 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -123,6 +123,18 @@ int omap_vp_forceupdate_scale(struct voltagedomain *voltdm,
u8 target_vsel, current_vsel;
int ret, timeout = 0;
+/*
+ * Wait for VP idle Typical latency is <2us. Maximum latency is ~100us
+ * This is an additional allowance to ensure we are in proper state
+ * to enter into forceupdate state transition.
+ */
+ omap_test_timeout((voltdm->read(vp->vstatus)),
+ VP_IDLE_TIMEOUT, timeout);
+
+ if (timeout >= VP_IDLE_TIMEOUT)
+ pr_warning("%s: vdd_%s idle timedout forceupdate(v=%ld)\n",
+ __func__, voltdm->name, target_volt);
+
ret = omap_vc_pre_scale(voltdm, target_volt, &target_vsel, ¤t_vsel);
if (ret)
return ret;
--
1.7.9.5
^ permalink raw reply related [flat|nested] 34+ messages in thread* [PATCH 2/3] ARM: OMAP3+: PM: VP: check to ensure VP is idle before forceupdate
@ 2012-05-18 19:33 ` Nishanth Menon
0 siblings, 0 replies; 34+ messages in thread
From: Nishanth Menon @ 2012-05-18 19:33 UTC (permalink / raw)
To: linux-arm-kernel
Ideally in the flow of DVFS programming, VP should be in idle state
(since we disabled it) before entering forceupdate. Ensure that
this is the case. Not doing this could cause VP statemachine
to enter invalid states.
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
Signed-off-by: Vinay Amancha <vinaykumar@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-omap2/vp.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 925d869..985091b 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -123,6 +123,18 @@ int omap_vp_forceupdate_scale(struct voltagedomain *voltdm,
u8 target_vsel, current_vsel;
int ret, timeout = 0;
+/*
+ * Wait for VP idle Typical latency is <2us. Maximum latency is ~100us
+ * This is an additional allowance to ensure we are in proper state
+ * to enter into forceupdate state transition.
+ */
+ omap_test_timeout((voltdm->read(vp->vstatus)),
+ VP_IDLE_TIMEOUT, timeout);
+
+ if (timeout >= VP_IDLE_TIMEOUT)
+ pr_warning("%s: vdd_%s idle timedout forceupdate(v=%ld)\n",
+ __func__, voltdm->name, target_volt);
+
ret = omap_vc_pre_scale(voltdm, target_volt, &target_vsel, ¤t_vsel);
if (ret)
return ret;
--
1.7.9.5
^ permalink raw reply related [flat|nested] 34+ messages in thread* Re: [PATCH 2/3] ARM: OMAP3+: PM: VP: check to ensure VP is idle before forceupdate
2012-05-18 19:33 ` Nishanth Menon
@ 2012-05-31 23:23 ` Kevin Hilman
-1 siblings, 0 replies; 34+ messages in thread
From: Kevin Hilman @ 2012-05-31 23:23 UTC (permalink / raw)
To: Nishanth Menon; +Cc: Tony Lindgren, linux-omap, linux-arm-kernel, Vinay Amancha
Nishanth Menon <nm@ti.com> writes:
> Ideally in the flow of DVFS programming, VP should be in idle state
> (since we disabled it) before entering forceupdate. Ensure that
> this is the case. Not doing this could cause VP statemachine
> to enter invalid states.
>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: linux-omap@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
>
> Signed-off-by: Vinay Amancha <vinaykumar@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> arch/arm/mach-omap2/vp.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
> index 925d869..985091b 100644
> --- a/arch/arm/mach-omap2/vp.c
> +++ b/arch/arm/mach-omap2/vp.c
> @@ -123,6 +123,18 @@ int omap_vp_forceupdate_scale(struct voltagedomain *voltdm,
> u8 target_vsel, current_vsel;
> int ret, timeout = 0;
>
> +/*
missing indent
> + * Wait for VP idle Typical latency is <2us. Maximum latency is ~100us
> + * This is an additional allowance to ensure we are in proper state
> + * to enter into forceupdate state transition.
> + */
> + omap_test_timeout((voltdm->read(vp->vstatus)),
> + VP_IDLE_TIMEOUT, timeout);
> +
> + if (timeout >= VP_IDLE_TIMEOUT)
> + pr_warning("%s: vdd_%s idle timedout forceupdate(v=%ld)\n",
> + __func__, voltdm->name, target_volt);
> +
Again, some clean failure and error recovery should be done here instead
of just a print and bail.
Kevin
> ret = omap_vc_pre_scale(voltdm, target_volt, &target_vsel, ¤t_vsel);
> if (ret)
> return ret;
^ permalink raw reply [flat|nested] 34+ messages in thread* [PATCH 2/3] ARM: OMAP3+: PM: VP: check to ensure VP is idle before forceupdate
@ 2012-05-31 23:23 ` Kevin Hilman
0 siblings, 0 replies; 34+ messages in thread
From: Kevin Hilman @ 2012-05-31 23:23 UTC (permalink / raw)
To: linux-arm-kernel
Nishanth Menon <nm@ti.com> writes:
> Ideally in the flow of DVFS programming, VP should be in idle state
> (since we disabled it) before entering forceupdate. Ensure that
> this is the case. Not doing this could cause VP statemachine
> to enter invalid states.
>
> 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
>
> Signed-off-by: Vinay Amancha <vinaykumar@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> arch/arm/mach-omap2/vp.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
> index 925d869..985091b 100644
> --- a/arch/arm/mach-omap2/vp.c
> +++ b/arch/arm/mach-omap2/vp.c
> @@ -123,6 +123,18 @@ int omap_vp_forceupdate_scale(struct voltagedomain *voltdm,
> u8 target_vsel, current_vsel;
> int ret, timeout = 0;
>
> +/*
missing indent
> + * Wait for VP idle Typical latency is <2us. Maximum latency is ~100us
> + * This is an additional allowance to ensure we are in proper state
> + * to enter into forceupdate state transition.
> + */
> + omap_test_timeout((voltdm->read(vp->vstatus)),
> + VP_IDLE_TIMEOUT, timeout);
> +
> + if (timeout >= VP_IDLE_TIMEOUT)
> + pr_warning("%s: vdd_%s idle timedout forceupdate(v=%ld)\n",
> + __func__, voltdm->name, target_volt);
> +
Again, some clean failure and error recovery should be done here instead
of just a print and bail.
Kevin
> ret = omap_vc_pre_scale(voltdm, target_volt, &target_vsel, ¤t_vsel);
> if (ret)
> return ret;
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [PATCH 2/3] ARM: OMAP3+: PM: VP: check to ensure VP is idle before forceupdate
2012-05-31 23:23 ` Kevin Hilman
@ 2012-05-31 23:37 ` Nishanth Menon
-1 siblings, 0 replies; 34+ messages in thread
From: Nishanth Menon @ 2012-05-31 23:37 UTC (permalink / raw)
To: Kevin Hilman; +Cc: Tony Lindgren, linux-omap, linux-arm-kernel, Vinay Amancha
On 16:23-20120531, Kevin Hilman wrote:
> Nishanth Menon <nm@ti.com> writes:
>
> > Ideally in the flow of DVFS programming, VP should be in idle state
> > (since we disabled it) before entering forceupdate. Ensure that
> > this is the case. Not doing this could cause VP statemachine
> > to enter invalid states.
> >
> > Cc: Tony Lindgren <tony@atomide.com>
> > Cc: Kevin Hilman <khilman@ti.com>
> > Cc: linux-omap@vger.kernel.org
> > Cc: linux-arm-kernel@lists.infradead.org
> >
> > Signed-off-by: Vinay Amancha <vinaykumar@ti.com>
> > Signed-off-by: Nishanth Menon <nm@ti.com>
> > ---
> > arch/arm/mach-omap2/vp.c | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
> > index 925d869..985091b 100644
> > --- a/arch/arm/mach-omap2/vp.c
> > +++ b/arch/arm/mach-omap2/vp.c
> > @@ -123,6 +123,18 @@ int omap_vp_forceupdate_scale(struct voltagedomain *voltdm,
> > u8 target_vsel, current_vsel;
> > int ret, timeout = 0;
> >
> > +/*
>
> missing indent
oops. will fix
>
> > + * Wait for VP idle Typical latency is <2us. Maximum latency is ~100us
> > + * This is an additional allowance to ensure we are in proper state
> > + * to enter into forceupdate state transition.
> > + */
> > + omap_test_timeout((voltdm->read(vp->vstatus)),
> > + VP_IDLE_TIMEOUT, timeout);
> > +
> > + if (timeout >= VP_IDLE_TIMEOUT)
> > + pr_warning("%s: vdd_%s idle timedout forceupdate(v=%ld)\n",
> > + __func__, voltdm->name, target_volt);
> > +
>
> Again, some clean failure and error recovery should be done here instead
> of just a print and bail.
thx - we should at least refuse to do forceupdate at this point.
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 34+ messages in thread* [PATCH 2/3] ARM: OMAP3+: PM: VP: check to ensure VP is idle before forceupdate
@ 2012-05-31 23:37 ` Nishanth Menon
0 siblings, 0 replies; 34+ messages in thread
From: Nishanth Menon @ 2012-05-31 23:37 UTC (permalink / raw)
To: linux-arm-kernel
On 16:23-20120531, Kevin Hilman wrote:
> Nishanth Menon <nm@ti.com> writes:
>
> > Ideally in the flow of DVFS programming, VP should be in idle state
> > (since we disabled it) before entering forceupdate. Ensure that
> > this is the case. Not doing this could cause VP statemachine
> > to enter invalid states.
> >
> > 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
> >
> > Signed-off-by: Vinay Amancha <vinaykumar@ti.com>
> > Signed-off-by: Nishanth Menon <nm@ti.com>
> > ---
> > arch/arm/mach-omap2/vp.c | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
> > index 925d869..985091b 100644
> > --- a/arch/arm/mach-omap2/vp.c
> > +++ b/arch/arm/mach-omap2/vp.c
> > @@ -123,6 +123,18 @@ int omap_vp_forceupdate_scale(struct voltagedomain *voltdm,
> > u8 target_vsel, current_vsel;
> > int ret, timeout = 0;
> >
> > +/*
>
> missing indent
oops. will fix
>
> > + * Wait for VP idle Typical latency is <2us. Maximum latency is ~100us
> > + * This is an additional allowance to ensure we are in proper state
> > + * to enter into forceupdate state transition.
> > + */
> > + omap_test_timeout((voltdm->read(vp->vstatus)),
> > + VP_IDLE_TIMEOUT, timeout);
> > +
> > + if (timeout >= VP_IDLE_TIMEOUT)
> > + pr_warning("%s: vdd_%s idle timedout forceupdate(v=%ld)\n",
> > + __func__, voltdm->name, target_volt);
> > +
>
> Again, some clean failure and error recovery should be done here instead
> of just a print and bail.
thx - we should at least refuse to do forceupdate at this point.
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 3/3] ARM: OMAP3+: PM: VP: check only the VPINIDLE status bit
2012-05-18 19:33 ` Nishanth Menon
@ 2012-05-18 19:33 ` Nishanth Menon
-1 siblings, 0 replies; 34+ messages in thread
From: Nishanth Menon @ 2012-05-18 19:33 UTC (permalink / raw)
To: Kevin Hilman; +Cc: Nishanth Menon, Tony Lindgren, linux-omap, linux-arm-kernel
Currently we check against the entire 32 bits of the status register
Where, bits 1-31 are marked as reserved and mentioned in TRM as read
returns undefined values. Hence, check against purely the vpinidle
status bit.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Reported-by: Vinay Amancha <vinaykumar@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-omap2/vp.c | 15 +++++++++------
arch/arm/mach-omap2/vp.h | 1 +
arch/arm/mach-omap2/vp3xxx_data.c | 1 +
arch/arm/mach-omap2/vp44xx_data.c | 1 +
4 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 985091b..cdcac16 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -128,8 +128,9 @@ int omap_vp_forceupdate_scale(struct voltagedomain *voltdm,
* This is an additional allowance to ensure we are in proper state
* to enter into forceupdate state transition.
*/
- omap_test_timeout((voltdm->read(vp->vstatus)),
- VP_IDLE_TIMEOUT, timeout);
+ omap_test_timeout((voltdm->read(vp->vstatus) &
+ vp->common->vstatus_vpidle), VP_IDLE_TIMEOUT,
+ timeout);
if (timeout >= VP_IDLE_TIMEOUT)
pr_warning("%s: vdd_%s idle timedout forceupdate(v=%ld)\n",
@@ -278,8 +279,9 @@ void omap_vp_disable(struct voltagedomain *voltdm)
* 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);
+ omap_test_timeout((voltdm->read(vp->vstatus) &
+ vp->common->vstatus_vpidle), VP_IDLE_TIMEOUT,
+ timeout);
if (timeout >= VP_IDLE_TIMEOUT)
pr_warning("%s: vdd_%s idle timedout before disable\n",
@@ -293,8 +295,9 @@ void omap_vp_disable(struct voltagedomain *voltdm)
/*
* Wait for VP idle Typical latency is <2us. Maximum latency is ~100us
*/
- omap_test_timeout((voltdm->read(vp->vstatus)),
- VP_IDLE_TIMEOUT, timeout);
+ omap_test_timeout((voltdm->read(vp->vstatus) &
+ vp->common->vstatus_vpidle), VP_IDLE_TIMEOUT,
+ timeout);
if (timeout >= VP_IDLE_TIMEOUT)
pr_warning("%s: vdd_%s idle timedout after disable\n",
diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h
index 0abf895..876b5ab 100644
--- a/arch/arm/mach-omap2/vp.h
+++ b/arch/arm/mach-omap2/vp.h
@@ -73,6 +73,7 @@ struct omap_vp_common {
u8 vpconfig_initvdd;
u8 vpconfig_forceupdate;
u8 vpconfig_vpenable;
+ u8 vstatus_vpidle;
u8 vstepmin_stepmin_shift;
u8 vstepmin_smpswaittimemin_shift;
u8 vstepmax_stepmax_shift;
diff --git a/arch/arm/mach-omap2/vp3xxx_data.c b/arch/arm/mach-omap2/vp3xxx_data.c
index bd89f80..a65909b 100644
--- a/arch/arm/mach-omap2/vp3xxx_data.c
+++ b/arch/arm/mach-omap2/vp3xxx_data.c
@@ -44,6 +44,7 @@ static const struct omap_vp_common omap3_vp_common = {
.vpconfig_initvdd = OMAP3430_INITVDD_MASK,
.vpconfig_forceupdate = OMAP3430_FORCEUPDATE_MASK,
.vpconfig_vpenable = OMAP3430_VPENABLE_MASK,
+ .vstatus_vpidle = OMAP3430_VPINIDLE_MASK,
.vstepmin_smpswaittimemin_shift = OMAP3430_SMPSWAITTIMEMIN_SHIFT,
.vstepmax_smpswaittimemax_shift = OMAP3430_SMPSWAITTIMEMAX_SHIFT,
.vstepmin_stepmin_shift = OMAP3430_VSTEPMIN_SHIFT,
diff --git a/arch/arm/mach-omap2/vp44xx_data.c b/arch/arm/mach-omap2/vp44xx_data.c
index 8c031d1..9d14881 100644
--- a/arch/arm/mach-omap2/vp44xx_data.c
+++ b/arch/arm/mach-omap2/vp44xx_data.c
@@ -44,6 +44,7 @@ static const struct omap_vp_common omap4_vp_common = {
.vpconfig_initvdd = OMAP4430_INITVDD_MASK,
.vpconfig_forceupdate = OMAP4430_FORCEUPDATE_MASK,
.vpconfig_vpenable = OMAP4430_VPENABLE_MASK,
+ .vstatus_vpidle = OMAP4430_VPINIDLE_MASK,
.vstepmin_smpswaittimemin_shift = OMAP4430_SMPSWAITTIMEMIN_SHIFT,
.vstepmax_smpswaittimemax_shift = OMAP4430_SMPSWAITTIMEMAX_SHIFT,
.vstepmin_stepmin_shift = OMAP4430_VSTEPMIN_SHIFT,
--
1.7.9.5
^ permalink raw reply related [flat|nested] 34+ messages in thread* [PATCH 3/3] ARM: OMAP3+: PM: VP: check only the VPINIDLE status bit
@ 2012-05-18 19:33 ` Nishanth Menon
0 siblings, 0 replies; 34+ messages in thread
From: Nishanth Menon @ 2012-05-18 19:33 UTC (permalink / raw)
To: linux-arm-kernel
Currently we check against the entire 32 bits of the status register
Where, bits 1-31 are marked as reserved and mentioned in TRM as read
returns undefined values. Hence, check against purely the vpinidle
status bit.
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
Reported-by: Vinay Amancha <vinaykumar@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-omap2/vp.c | 15 +++++++++------
arch/arm/mach-omap2/vp.h | 1 +
arch/arm/mach-omap2/vp3xxx_data.c | 1 +
arch/arm/mach-omap2/vp44xx_data.c | 1 +
4 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 985091b..cdcac16 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -128,8 +128,9 @@ int omap_vp_forceupdate_scale(struct voltagedomain *voltdm,
* This is an additional allowance to ensure we are in proper state
* to enter into forceupdate state transition.
*/
- omap_test_timeout((voltdm->read(vp->vstatus)),
- VP_IDLE_TIMEOUT, timeout);
+ omap_test_timeout((voltdm->read(vp->vstatus) &
+ vp->common->vstatus_vpidle), VP_IDLE_TIMEOUT,
+ timeout);
if (timeout >= VP_IDLE_TIMEOUT)
pr_warning("%s: vdd_%s idle timedout forceupdate(v=%ld)\n",
@@ -278,8 +279,9 @@ void omap_vp_disable(struct voltagedomain *voltdm)
* 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);
+ omap_test_timeout((voltdm->read(vp->vstatus) &
+ vp->common->vstatus_vpidle), VP_IDLE_TIMEOUT,
+ timeout);
if (timeout >= VP_IDLE_TIMEOUT)
pr_warning("%s: vdd_%s idle timedout before disable\n",
@@ -293,8 +295,9 @@ void omap_vp_disable(struct voltagedomain *voltdm)
/*
* Wait for VP idle Typical latency is <2us. Maximum latency is ~100us
*/
- omap_test_timeout((voltdm->read(vp->vstatus)),
- VP_IDLE_TIMEOUT, timeout);
+ omap_test_timeout((voltdm->read(vp->vstatus) &
+ vp->common->vstatus_vpidle), VP_IDLE_TIMEOUT,
+ timeout);
if (timeout >= VP_IDLE_TIMEOUT)
pr_warning("%s: vdd_%s idle timedout after disable\n",
diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h
index 0abf895..876b5ab 100644
--- a/arch/arm/mach-omap2/vp.h
+++ b/arch/arm/mach-omap2/vp.h
@@ -73,6 +73,7 @@ struct omap_vp_common {
u8 vpconfig_initvdd;
u8 vpconfig_forceupdate;
u8 vpconfig_vpenable;
+ u8 vstatus_vpidle;
u8 vstepmin_stepmin_shift;
u8 vstepmin_smpswaittimemin_shift;
u8 vstepmax_stepmax_shift;
diff --git a/arch/arm/mach-omap2/vp3xxx_data.c b/arch/arm/mach-omap2/vp3xxx_data.c
index bd89f80..a65909b 100644
--- a/arch/arm/mach-omap2/vp3xxx_data.c
+++ b/arch/arm/mach-omap2/vp3xxx_data.c
@@ -44,6 +44,7 @@ static const struct omap_vp_common omap3_vp_common = {
.vpconfig_initvdd = OMAP3430_INITVDD_MASK,
.vpconfig_forceupdate = OMAP3430_FORCEUPDATE_MASK,
.vpconfig_vpenable = OMAP3430_VPENABLE_MASK,
+ .vstatus_vpidle = OMAP3430_VPINIDLE_MASK,
.vstepmin_smpswaittimemin_shift = OMAP3430_SMPSWAITTIMEMIN_SHIFT,
.vstepmax_smpswaittimemax_shift = OMAP3430_SMPSWAITTIMEMAX_SHIFT,
.vstepmin_stepmin_shift = OMAP3430_VSTEPMIN_SHIFT,
diff --git a/arch/arm/mach-omap2/vp44xx_data.c b/arch/arm/mach-omap2/vp44xx_data.c
index 8c031d1..9d14881 100644
--- a/arch/arm/mach-omap2/vp44xx_data.c
+++ b/arch/arm/mach-omap2/vp44xx_data.c
@@ -44,6 +44,7 @@ static const struct omap_vp_common omap4_vp_common = {
.vpconfig_initvdd = OMAP4430_INITVDD_MASK,
.vpconfig_forceupdate = OMAP4430_FORCEUPDATE_MASK,
.vpconfig_vpenable = OMAP4430_VPENABLE_MASK,
+ .vstatus_vpidle = OMAP4430_VPINIDLE_MASK,
.vstepmin_smpswaittimemin_shift = OMAP4430_SMPSWAITTIMEMIN_SHIFT,
.vstepmax_smpswaittimemax_shift = OMAP4430_SMPSWAITTIMEMAX_SHIFT,
.vstepmin_stepmin_shift = OMAP4430_VSTEPMIN_SHIFT,
--
1.7.9.5
^ permalink raw reply related [flat|nested] 34+ messages in thread* Re: [PATCH 3/3] ARM: OMAP3+: PM: VP: check only the VPINIDLE status bit
2012-05-18 19:33 ` Nishanth Menon
@ 2012-05-31 23:27 ` Kevin Hilman
-1 siblings, 0 replies; 34+ messages in thread
From: Kevin Hilman @ 2012-05-31 23:27 UTC (permalink / raw)
To: Nishanth Menon; +Cc: Tony Lindgren, linux-omap, linux-arm-kernel
Nishanth Menon <nm@ti.com> writes:
> Currently we check against the entire 32 bits of the status register
> Where, bits 1-31 are marked as reserved and mentioned in TRM as read
> returns undefined values.
ouch
> Hence, check against purely the vpinidle status bit.
>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: linux-omap@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
>
> Reported-by: Vinay Amancha <vinaykumar@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
Thanks for the fix.
Looking at this combined with the previous patches, since this same
thing is done several places, it looks like we need a helper function
'omap_vp_wait_for_idle()' or similar. That function will do the check,
wait for timeout, and return an error if failure. The callers can than
do appropriate error handling upon failure.
Thanks,
Kevin
> ---
> arch/arm/mach-omap2/vp.c | 15 +++++++++------
> arch/arm/mach-omap2/vp.h | 1 +
> arch/arm/mach-omap2/vp3xxx_data.c | 1 +
> arch/arm/mach-omap2/vp44xx_data.c | 1 +
> 4 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
> index 985091b..cdcac16 100644
> --- a/arch/arm/mach-omap2/vp.c
> +++ b/arch/arm/mach-omap2/vp.c
> @@ -128,8 +128,9 @@ int omap_vp_forceupdate_scale(struct voltagedomain *voltdm,
> * This is an additional allowance to ensure we are in proper state
> * to enter into forceupdate state transition.
> */
> - omap_test_timeout((voltdm->read(vp->vstatus)),
> - VP_IDLE_TIMEOUT, timeout);
> + omap_test_timeout((voltdm->read(vp->vstatus) &
> + vp->common->vstatus_vpidle), VP_IDLE_TIMEOUT,
> + timeout);
>
> if (timeout >= VP_IDLE_TIMEOUT)
> pr_warning("%s: vdd_%s idle timedout forceupdate(v=%ld)\n",
> @@ -278,8 +279,9 @@ void omap_vp_disable(struct voltagedomain *voltdm)
> * 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);
> + omap_test_timeout((voltdm->read(vp->vstatus) &
> + vp->common->vstatus_vpidle), VP_IDLE_TIMEOUT,
> + timeout);
>
> if (timeout >= VP_IDLE_TIMEOUT)
> pr_warning("%s: vdd_%s idle timedout before disable\n",
> @@ -293,8 +295,9 @@ void omap_vp_disable(struct voltagedomain *voltdm)
> /*
> * Wait for VP idle Typical latency is <2us. Maximum latency is ~100us
> */
> - omap_test_timeout((voltdm->read(vp->vstatus)),
> - VP_IDLE_TIMEOUT, timeout);
> + omap_test_timeout((voltdm->read(vp->vstatus) &
> + vp->common->vstatus_vpidle), VP_IDLE_TIMEOUT,
> + timeout);
>
> if (timeout >= VP_IDLE_TIMEOUT)
> pr_warning("%s: vdd_%s idle timedout after disable\n",
> diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h
> index 0abf895..876b5ab 100644
> --- a/arch/arm/mach-omap2/vp.h
> +++ b/arch/arm/mach-omap2/vp.h
> @@ -73,6 +73,7 @@ struct omap_vp_common {
> u8 vpconfig_initvdd;
> u8 vpconfig_forceupdate;
> u8 vpconfig_vpenable;
> + u8 vstatus_vpidle;
> u8 vstepmin_stepmin_shift;
> u8 vstepmin_smpswaittimemin_shift;
> u8 vstepmax_stepmax_shift;
> diff --git a/arch/arm/mach-omap2/vp3xxx_data.c b/arch/arm/mach-omap2/vp3xxx_data.c
> index bd89f80..a65909b 100644
> --- a/arch/arm/mach-omap2/vp3xxx_data.c
> +++ b/arch/arm/mach-omap2/vp3xxx_data.c
> @@ -44,6 +44,7 @@ static const struct omap_vp_common omap3_vp_common = {
> .vpconfig_initvdd = OMAP3430_INITVDD_MASK,
> .vpconfig_forceupdate = OMAP3430_FORCEUPDATE_MASK,
> .vpconfig_vpenable = OMAP3430_VPENABLE_MASK,
> + .vstatus_vpidle = OMAP3430_VPINIDLE_MASK,
> .vstepmin_smpswaittimemin_shift = OMAP3430_SMPSWAITTIMEMIN_SHIFT,
> .vstepmax_smpswaittimemax_shift = OMAP3430_SMPSWAITTIMEMAX_SHIFT,
> .vstepmin_stepmin_shift = OMAP3430_VSTEPMIN_SHIFT,
> diff --git a/arch/arm/mach-omap2/vp44xx_data.c b/arch/arm/mach-omap2/vp44xx_data.c
> index 8c031d1..9d14881 100644
> --- a/arch/arm/mach-omap2/vp44xx_data.c
> +++ b/arch/arm/mach-omap2/vp44xx_data.c
> @@ -44,6 +44,7 @@ static const struct omap_vp_common omap4_vp_common = {
> .vpconfig_initvdd = OMAP4430_INITVDD_MASK,
> .vpconfig_forceupdate = OMAP4430_FORCEUPDATE_MASK,
> .vpconfig_vpenable = OMAP4430_VPENABLE_MASK,
> + .vstatus_vpidle = OMAP4430_VPINIDLE_MASK,
> .vstepmin_smpswaittimemin_shift = OMAP4430_SMPSWAITTIMEMIN_SHIFT,
> .vstepmax_smpswaittimemax_shift = OMAP4430_SMPSWAITTIMEMAX_SHIFT,
> .vstepmin_stepmin_shift = OMAP4430_VSTEPMIN_SHIFT,
^ permalink raw reply [flat|nested] 34+ messages in thread* [PATCH 3/3] ARM: OMAP3+: PM: VP: check only the VPINIDLE status bit
@ 2012-05-31 23:27 ` Kevin Hilman
0 siblings, 0 replies; 34+ messages in thread
From: Kevin Hilman @ 2012-05-31 23:27 UTC (permalink / raw)
To: linux-arm-kernel
Nishanth Menon <nm@ti.com> writes:
> Currently we check against the entire 32 bits of the status register
> Where, bits 1-31 are marked as reserved and mentioned in TRM as read
> returns undefined values.
ouch
> Hence, check against purely the vpinidle status bit.
>
> 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
>
> Reported-by: Vinay Amancha <vinaykumar@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
Thanks for the fix.
Looking at this combined with the previous patches, since this same
thing is done several places, it looks like we need a helper function
'omap_vp_wait_for_idle()' or similar. That function will do the check,
wait for timeout, and return an error if failure. The callers can than
do appropriate error handling upon failure.
Thanks,
Kevin
> ---
> arch/arm/mach-omap2/vp.c | 15 +++++++++------
> arch/arm/mach-omap2/vp.h | 1 +
> arch/arm/mach-omap2/vp3xxx_data.c | 1 +
> arch/arm/mach-omap2/vp44xx_data.c | 1 +
> 4 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
> index 985091b..cdcac16 100644
> --- a/arch/arm/mach-omap2/vp.c
> +++ b/arch/arm/mach-omap2/vp.c
> @@ -128,8 +128,9 @@ int omap_vp_forceupdate_scale(struct voltagedomain *voltdm,
> * This is an additional allowance to ensure we are in proper state
> * to enter into forceupdate state transition.
> */
> - omap_test_timeout((voltdm->read(vp->vstatus)),
> - VP_IDLE_TIMEOUT, timeout);
> + omap_test_timeout((voltdm->read(vp->vstatus) &
> + vp->common->vstatus_vpidle), VP_IDLE_TIMEOUT,
> + timeout);
>
> if (timeout >= VP_IDLE_TIMEOUT)
> pr_warning("%s: vdd_%s idle timedout forceupdate(v=%ld)\n",
> @@ -278,8 +279,9 @@ void omap_vp_disable(struct voltagedomain *voltdm)
> * 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);
> + omap_test_timeout((voltdm->read(vp->vstatus) &
> + vp->common->vstatus_vpidle), VP_IDLE_TIMEOUT,
> + timeout);
>
> if (timeout >= VP_IDLE_TIMEOUT)
> pr_warning("%s: vdd_%s idle timedout before disable\n",
> @@ -293,8 +295,9 @@ void omap_vp_disable(struct voltagedomain *voltdm)
> /*
> * Wait for VP idle Typical latency is <2us. Maximum latency is ~100us
> */
> - omap_test_timeout((voltdm->read(vp->vstatus)),
> - VP_IDLE_TIMEOUT, timeout);
> + omap_test_timeout((voltdm->read(vp->vstatus) &
> + vp->common->vstatus_vpidle), VP_IDLE_TIMEOUT,
> + timeout);
>
> if (timeout >= VP_IDLE_TIMEOUT)
> pr_warning("%s: vdd_%s idle timedout after disable\n",
> diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h
> index 0abf895..876b5ab 100644
> --- a/arch/arm/mach-omap2/vp.h
> +++ b/arch/arm/mach-omap2/vp.h
> @@ -73,6 +73,7 @@ struct omap_vp_common {
> u8 vpconfig_initvdd;
> u8 vpconfig_forceupdate;
> u8 vpconfig_vpenable;
> + u8 vstatus_vpidle;
> u8 vstepmin_stepmin_shift;
> u8 vstepmin_smpswaittimemin_shift;
> u8 vstepmax_stepmax_shift;
> diff --git a/arch/arm/mach-omap2/vp3xxx_data.c b/arch/arm/mach-omap2/vp3xxx_data.c
> index bd89f80..a65909b 100644
> --- a/arch/arm/mach-omap2/vp3xxx_data.c
> +++ b/arch/arm/mach-omap2/vp3xxx_data.c
> @@ -44,6 +44,7 @@ static const struct omap_vp_common omap3_vp_common = {
> .vpconfig_initvdd = OMAP3430_INITVDD_MASK,
> .vpconfig_forceupdate = OMAP3430_FORCEUPDATE_MASK,
> .vpconfig_vpenable = OMAP3430_VPENABLE_MASK,
> + .vstatus_vpidle = OMAP3430_VPINIDLE_MASK,
> .vstepmin_smpswaittimemin_shift = OMAP3430_SMPSWAITTIMEMIN_SHIFT,
> .vstepmax_smpswaittimemax_shift = OMAP3430_SMPSWAITTIMEMAX_SHIFT,
> .vstepmin_stepmin_shift = OMAP3430_VSTEPMIN_SHIFT,
> diff --git a/arch/arm/mach-omap2/vp44xx_data.c b/arch/arm/mach-omap2/vp44xx_data.c
> index 8c031d1..9d14881 100644
> --- a/arch/arm/mach-omap2/vp44xx_data.c
> +++ b/arch/arm/mach-omap2/vp44xx_data.c
> @@ -44,6 +44,7 @@ static const struct omap_vp_common omap4_vp_common = {
> .vpconfig_initvdd = OMAP4430_INITVDD_MASK,
> .vpconfig_forceupdate = OMAP4430_FORCEUPDATE_MASK,
> .vpconfig_vpenable = OMAP4430_VPENABLE_MASK,
> + .vstatus_vpidle = OMAP4430_VPINIDLE_MASK,
> .vstepmin_smpswaittimemin_shift = OMAP4430_SMPSWAITTIMEMIN_SHIFT,
> .vstepmax_smpswaittimemax_shift = OMAP4430_SMPSWAITTIMEMAX_SHIFT,
> .vstepmin_stepmin_shift = OMAP4430_VSTEPMIN_SHIFT,
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [PATCH 3/3] ARM: OMAP3+: PM: VP: check only the VPINIDLE status bit
2012-05-31 23:27 ` Kevin Hilman
@ 2012-05-31 23:39 ` Nishanth Menon
-1 siblings, 0 replies; 34+ messages in thread
From: Nishanth Menon @ 2012-05-31 23:39 UTC (permalink / raw)
To: Kevin Hilman; +Cc: Tony Lindgren, linux-omap, linux-arm-kernel
On 16:27-20120531, Kevin Hilman wrote:
> Nishanth Menon <nm@ti.com> writes:
>
> > Currently we check against the entire 32 bits of the status register
> > Where, bits 1-31 are marked as reserved and mentioned in TRM as read
> > returns undefined values.
>
> ouch
>
> > Hence, check against purely the vpinidle status bit.
> >
> > Cc: Tony Lindgren <tony@atomide.com>
> > Cc: Kevin Hilman <khilman@ti.com>
> > Cc: linux-omap@vger.kernel.org
> > Cc: linux-arm-kernel@lists.infradead.org
> >
> > Reported-by: Vinay Amancha <vinaykumar@ti.com>
> > Signed-off-by: Nishanth Menon <nm@ti.com>
>
> Thanks for the fix.
>
> Looking at this combined with the previous patches, since this same
> thing is done several places, it looks like we need a helper function
> 'omap_vp_wait_for_idle()' or similar. That function will do the check,
> wait for timeout, and return an error if failure. The callers can than
> do appropriate error handling upon failure.
>
yep - i think a static inline should do just fine here considering just
a test_timeout is involved.
will post out a new series in a few mins.
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 3/3] ARM: OMAP3+: PM: VP: check only the VPINIDLE status bit
@ 2012-05-31 23:39 ` Nishanth Menon
0 siblings, 0 replies; 34+ messages in thread
From: Nishanth Menon @ 2012-05-31 23:39 UTC (permalink / raw)
To: linux-arm-kernel
On 16:27-20120531, Kevin Hilman wrote:
> Nishanth Menon <nm@ti.com> writes:
>
> > Currently we check against the entire 32 bits of the status register
> > Where, bits 1-31 are marked as reserved and mentioned in TRM as read
> > returns undefined values.
>
> ouch
>
> > Hence, check against purely the vpinidle status bit.
> >
> > 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
> >
> > Reported-by: Vinay Amancha <vinaykumar@ti.com>
> > Signed-off-by: Nishanth Menon <nm@ti.com>
>
> Thanks for the fix.
>
> Looking at this combined with the previous patches, since this same
> thing is done several places, it looks like we need a helper function
> 'omap_vp_wait_for_idle()' or similar. That function will do the check,
> wait for timeout, and return an error if failure. The callers can than
> do appropriate error handling upon failure.
>
yep - i think a static inline should do just fine here considering just
a test_timeout is involved.
will post out a new series in a few mins.
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 34+ messages in thread