All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH V2] [PM-WIP-OPP]: Fixing wrong target level being passed during Core DVFS.
@ 2010-02-23 17:03 Thara Gopinath
  2010-02-23 18:37 ` Kevin Hilman
  0 siblings, 1 reply; 2+ messages in thread
From: Thara Gopinath @ 2010-02-23 17:03 UTC (permalink / raw)
  To: linux-omap; +Cc: Thara Gopinath, Kevin Hilman

As per the current implementaion (u8*)&target_level is being passed
to freq_to_opp in set_opp. This would result in updating just the first
8 bits of a u32 variable. Later target_level is passed to
resource_set_opp_level as a u32 parameter. This maens
a. Initially target_level was 0xabcdefgh.
b. freq_to_opp updates the lower eight bits of target_level
to 0xXX. Now target_level = 0xabcdefXX.
c. We pass 0xabcdefXX as target_level to resource_set_opp_level
when we want to pass just 0xXX.
This is leading to some corrupted bookkeeping later on in the
dvfs path.

This patch ensures that target_level passed to resource_set_opp_level
is actually the level that is intended by freq_to_opp API.

Signed-off-by: Thara Gopinath <thara@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
---
 arch/arm/mach-omap2/resource34xx.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/resource34xx.c b/arch/arm/mach-omap2/resource34xx.c
index 3604a38..2c850a2 100644
--- a/arch/arm/mach-omap2/resource34xx.c
+++ b/arch/arm/mach-omap2/resource34xx.c
@@ -478,6 +478,7 @@ int set_opp(struct shared_resource *resp, u32 target_level)
 		/* uh uh.. no OPPs?? */
 		BUG_ON(IS_ERR(oppx));
 
+		target_level = 0;
 		ret = freq_to_opp((u8 *)&target_level, OPP_L3, req_l3_freq);
 		/* we dont expect this to fail */
 		BUG_ON(ret);
-- 
1.5.4.7


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH V2] [PM-WIP-OPP]: Fixing wrong target level being passed during Core DVFS.
  2010-02-23 17:03 [PATCH V2] [PM-WIP-OPP]: Fixing wrong target level being passed during Core DVFS Thara Gopinath
@ 2010-02-23 18:37 ` Kevin Hilman
  0 siblings, 0 replies; 2+ messages in thread
From: Kevin Hilman @ 2010-02-23 18:37 UTC (permalink / raw)
  To: Thara Gopinath; +Cc: linux-omap

Thara Gopinath <thara@ti.com> writes:

> As per the current implementaion (u8*)&target_level is being passed
> to freq_to_opp in set_opp. This would result in updating just the first
> 8 bits of a u32 variable. Later target_level is passed to
> resource_set_opp_level as a u32 parameter. This maens
> a. Initially target_level was 0xabcdefgh.
> b. freq_to_opp updates the lower eight bits of target_level
> to 0xXX. Now target_level = 0xabcdefXX.
> c. We pass 0xabcdefXX as target_level to resource_set_opp_level
> when we want to pass just 0xXX.
> This is leading to some corrupted bookkeeping later on in the
> dvfs path.
>
> This patch ensures that target_level passed to resource_set_opp_level
> is actually the level that is intended by freq_to_opp API.
>
> Signed-off-by: Thara Gopinath <thara@ti.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>

Thanks, applying to pm-wip-opp after cleaning up the formatting in the changelog
to be a little more readable.

Kevin

> ---
>  arch/arm/mach-omap2/resource34xx.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/resource34xx.c b/arch/arm/mach-omap2/resource34xx.c
> index 3604a38..2c850a2 100644
> --- a/arch/arm/mach-omap2/resource34xx.c
> +++ b/arch/arm/mach-omap2/resource34xx.c
> @@ -478,6 +478,7 @@ int set_opp(struct shared_resource *resp, u32 target_level)
>  		/* uh uh.. no OPPs?? */
>  		BUG_ON(IS_ERR(oppx));
>  
> +		target_level = 0;
>  		ret = freq_to_opp((u8 *)&target_level, OPP_L3, req_l3_freq);
>  		/* we dont expect this to fail */
>  		BUG_ON(ret);
> -- 
> 1.5.4.7

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2010-02-23 18:37 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-02-23 17:03 [PATCH V2] [PM-WIP-OPP]: Fixing wrong target level being passed during Core DVFS Thara Gopinath
2010-02-23 18:37 ` Kevin Hilman

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.