> -----Original Message-----
> From: Roger Quadros [mailto:[email protected]] 
> Sent: Wednesday, April 29, 2009 1:20 PM
> To: Nayak, Rajendra
> Cc: [email protected]
> Subject: Re: [PATCH] OMAP3: SR: Fix SR driver to check for 
> omap-pm return values
> 
> ext Rajendra Nayak wrote:
> > This patch checks for the return values of omap_pm_vddx_get_opp()
> > in SR driver and acts accordingly. With no SRF layer 
> enabled the OMAP-PM layer
> > api is unable to return the current OPP.
> > 
> > Signed-off-by: Rajendra Nayak <[email protected]>
> > ---
> >  arch/arm/mach-omap2/smartreflex.c |   42 
> +++++++++++++++++++++++++++++++++---
> >  1 files changed, 38 insertions(+), 4 deletions(-)
> > 
> 
> > +           if (!omap_pm_vdd1_get_opp())
> > +                   /* Assume Nominal OPP as current OPP unknown */
> > +                   vsel = mpu_opps[VDD1_OPP3].vsel;
> > +           else
> > +                   vsel = mpu_opps[omap_pm_vdd1_get_opp()].vsel;
> > +
> 
> Hi Rajendra,
> 
>    By this approach, what will be the implications if the 
> bootloader had set the 
> OPP to something different than your assumption?
>    I think the best approach would be to modify the PM layer 
> to at least return 
> correct OPP and Frequency values. What do you think?

The PM layer was designed to be just a thin wrapper layer, which
on its own does not have any way to return the right OPP.
It relies on SRF or something else below to provide the right info.

The assumption of OPP comes in only with SRF disabled and nothing
else present to replace the functionality. 
Any reason why SRF is disabled in Nokia builds?

>    We should not expect every driver using X_get_opp to 
> assume the OPP if it 
> returns error.
> 
> Please see this thread to see the alternative solution.
> http://www.mail-archive.com/[email protected]/msg12021.html
> 
> I know it uses resource framework even if we set PM_NONE or 
> PM_NOOP, but only 
> for getting the correct OPP/frequency values.
> 
> regards,
> -roger
> 
> --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to