Re: OMAP4 errata i740

["Cousson, Benoit" <b-cousson@ti.com>]

On 3/30/2012 1:20 PM, Shilimkar, Santosh wrote:
> On Fri, Mar 30, 2012 at 4:47 PM, Archit Taneja<a0393947@ti.com>  wrote:
>> On Friday 30 March 2012 04:34 PM, Shilimkar, Santosh wrote:
>>>
>>> On Fri, Mar 30, 2012 at 4:26 PM, Archit Taneja<a0393947@ti.com>    wrote:
>>>>
>>>> On Friday 30 March 2012 03:59 PM, Santosh Shilimkar wrote:
>>>>>
>>>>>
>>>>> On Friday 30 March 2012 03:53 PM, Cousson, Benoit wrote:
>>>>>>
>>>>>>
>>>>>> On 3/30/2012 10:44 AM, Santosh Shilimkar wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Friday 30 March 2012 02:04 PM, Archit Taneja wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Friday 30 March 2012 02:01 PM, Santosh Shilimkar wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> + Kevin
>>>>>>>>>
>>>>>>>>> On Friday 30 March 2012 01:56 PM, Tomi Valkeinen wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, 2012-03-30 at 13:51 +0530, Shilimkar, Santosh wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Mar 30, 2012 at 1:37 PM, Tomi
>>>>>>>>>>> Valkeinen<tomi.valkeinen@ti.com>        wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>
>>> [...]
>>>
>>>>
>>>> I had a general PRCM question regarding this. If an initiator is disabled
>>>> (i.e, clocks are OFF and Power state is OFF), then would the PRCM even
>>>> care
>>>> to look at the IdleAck/Mstandby signal of that initiator? Or in other
>>>> words,
>>>> look at what the initiator had programmed in it's SYSCONFIG register. If
>>>> it
>>>> does consider them, it seems like that's bad HW design!
>>>>
>>> If a PD 9powerdomain) is already in OFF state, that means all the
>>> initiators in
>>> that PD already has standby asserted. The modules in that
>>> PD also have transitioned.
>>
>>
>> Ah, so if DSS was configured as Nostandby, and if we try to disable DSS, it
>> would never transition to OFF, and hence never get disabled correctly, hence
>> giving trouble to PRCM.
>>
>> So just before disabling DSS, we would need to put it to Force standby, and
>> then try to cut the clocks and change the power state. Is this correct? If
>> so, then it's equally messy as the suggested workaround :)
>>
> Exactly. That's what I mean. You tweak sysconfig or clockdomain,
> both are messy.

Not it's not. We are trying to avoid accessing the sysconfig from the 
driver, but at least this is a setting local to the IP.

And as you said, we have to do that already do to the various bugs here 
and there on a lot of IPs.

Playing with clock domain state from the driver is just not acceptable.

> if one need to choose between two bad options, I guess sysconifig
> one is better because that is local to IPs and there is some way today
> for drivers to manage sysconfig directly.

Yes, that's the point.

Benoit