Re: [PATCH] DSPBRIDGE: Fix BUG scheduling while atomic

[Nishanth Menon <nm@ti.com>]

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.

> 
> But the entire bumping thing is specific to 3430 IMHO.
> 
if I get your point, you would rather see that this bump up disappear? 
OR is there a reason for saying this 3430 specific? on 3630, there are 
upto 4 OPPs(on the 1Ghz device), OR is this a errata workaround that we 
have here? the original commit is lacking in info about this.


-- 
Regards,
Nishanth Menon