>From: Menon, Nishanth on Thursday, January 21, 2010 12:03 PM
>
>Ramirez Luna, Omar had written, on 01/21/2010 11:57 AM, the following:
>>> From: Menon, Nishanth on Thursday, January 21, 2010 11:47 AM
>>>
>>> Ramirez Luna, Omar had written, on 01/21/2010 11:43 AM, the following:
>>>>> From: Chitriki Rudramuni, Deepak on Wednesday, January 20, 2010 10:01 PM
>>>>>
>>> [...]
>>>
>>>>> diff --git a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
>>>>> index 94b399f..54cba9f 100644
>>>>> --- a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
>>>>> +++ b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
>>>>> @@ -806,3 +806,34 @@ void DSPClkWakeupEventCtrl(u32 ClkId, bool enable)
>>>>> break;
>>>>> }
>>>>> }
>>>>> +
>>>>> +/**
>>>>> + * tiomap3430_bump_dsp_opp_level() - bump up the opp if at minimum
>>>>> + *
>>>>> + * if we need a higher opp index, request for the same
>>>>> + */
>>>>> +DSP_STATUS tiomap3430_bump_dsp_opp_level(void)
>>>>> +{
>>>>> +#ifndef CONFIG_BRIDGE_DVFS
>>>> Basically if DVFS is defined nothing is done, this was wrong in the original patch (like I
>>> mentioned offline).
>>>>> + u32 opplevel;
>>>>> +
>>>>> + struct dspbridge_platform_data *pdata =
>>>>> + omap_dspbridge_dev->dev.platform_data;
>>>>> +
>>>>> + if (pdata->dsp_get_opp) {
>>>>> + opplevel = (*pdata->dsp_get_opp)();
>>>>> +
>>>>> + /*
>>>>> + * If OPP is at minimum level, increase it before waking
>>>>> + * up the DSP.
>>>>> + */
>>>>> + if (opplevel == 1 && pdata->dsp_set_min_opp) {
>>>>> + (*pdata->dsp_set_min_opp)(opp_level + 1);
>>>>> + DBG_Trace(DBG_LEVEL7, "CHNLSM_InterruptDSP: Setting "
>>>>> + "the vdd1 constraint level to %d before "
>>>>> + "waking DSP \n", opp_level + 1);
>>>>> + }
>>>>> + }
>>>>> +#endif
>>>>> + return DSP_SOK;
>>>>> +}
>>>> Since we are reworking all of this can be changed (u32, opplevel == MAGIC_NUM), besides this was
>>> specific to 3430.
>>> ^^^^^^^^^^^^^^^
>>> opplevel==1 is independent of 3430.. index 1 has to be the lowest right?
>>
>> You are right, I meant opplevel == VDD1_OPP or similar.
>arrggh... NOoooooo more #ifdefs, I would rather see my patch for min,max
>opps pushed in(after a rework and add a nominal_opp, min_opp params to
>pdata and use it :D) - that way all silicon variances are handled in
>arch/arm/mach-omap2 rather than drivers/dsp/bridge.
Need to see the patch before commenting; agree to no #def's, thought
definition was there already.
>
>>
>> But the entire bumping thing is specific to 3430 IMHO.
>>
>if I get your point, you would rather see that this bump up disappear?
Only if it is not needed.
>OR is there a reason for saying this 3430 specific? on 3630, there are
>upto 4 OPPs(on the 1Ghz device)
Doesn't matter if you have a 100 opps, no point if you have to bump from
1 to 2 and don't need it. Apparently it is needed for 3430.
> OR is this a errata workaround that we have here? the original commit
> is lacking in info about this.
This patch moves the code that bumps the opp outside an interrupt or
atomic context only (would be nice to add a good commit message so it can
be clear).
Code to bump the opp was there already, fixing a crash when waking up
the dsp at OPP1; haven't found the errata, if there is, there might be
one that says this also applies for 3630.
- omar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
