OMAP4 errata i740

OMAP4 errata i740

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

Hi,

I just found out about OMAP4 errata i740:

DESCRIPTION
A bug has been identified in the interconnect agent handling the connect-disconnect protocol between an
initiator and interconnect. When the disconnect protocol violation occurs, there is a dead lock and a
system lockup is observed.

The issue can occur in a corner case when the impacted module has started a transition to standby, for
the L3 initiator on which it is attached, exactly at the time the initiator gets an event for exiting idle state.
Such a situation can occur when the impacted initiator is generating short MStandby pulses (pulse
durations less than one L4 clock cycle).

DSS and ISS are the only initiators that are impacted.

WORKAROUND
L3_CLK1 must be kept in NO-IDLE when the DSS clock domain is ON. It can be switched back to
HW_AUTO when the DSS clock domain is IDLE.

L3_CLK2 must be kept in NO-IDLE when the ISS clock domain is ON. It can be switched back to
HW_AUTO when the ISS clock domain is IDLE.


All OMAP4 versions seem to be affected. I couldn't find a mention about
this in the mainline kernel. Any ideas how and where this should be
fixed?

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: OMAP4 errata i740

[Shilimkar, Santosh]

On Fri, Mar 30, 2012 at 1:37 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi,
>
> I just found out about OMAP4 errata i740:
>
> DESCRIPTION
> A bug has been identified in the interconnect agent handling the connect-disconnect protocol between an
> initiator and interconnect. When the disconnect protocol violation occurs, there is a dead lock and a
> system lockup is observed.
>
> The issue can occur in a corner case when the impacted module has started a transition to standby, for
> the L3 initiator on which it is attached, exactly at the time the initiator gets an event for exiting idle state.
> Such a situation can occur when the impacted initiator is generating short MStandby pulses (pulse
> durations less than one L4 clock cycle).
>
> DSS and ISS are the only initiators that are impacted.
>
> WORKAROUND
> L3_CLK1 must be kept in NO-IDLE when the DSS clock domain is ON. It can be switched back to
> HW_AUTO when the DSS clock domain is IDLE.
>
> L3_CLK2 must be kept in NO-IDLE when the ISS clock domain is ON. It can be switched back to
> HW_AUTO when the ISS clock domain is IDLE.
>
>
> All OMAP4 versions seem to be affected. I couldn't find a mention about
> this in the mainline kernel. Any ideas how and where this should be
> fixed?
>
It's not patched for mainline. Generally clock-domain code
is abstracted from drivers but considering the errata and affected
modules, I guees it should be handled by DSS driver
since that is where the state of DSS or ISS will be known. Note
ISS will be automatically taken care since it will always use disaplay.

In internal tree's this was handled as part of DSS early suspend/resume

Regards
Santosh

Re: OMAP4 errata i740

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]

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:

> > All OMAP4 versions seem to be affected. I couldn't find a mention about
> > this in the mainline kernel. Any ideas how and where this should be
> > fixed?
> >
> It's not patched for mainline. Generally clock-domain code
> is abstracted from drivers but considering the errata and affected
> modules, I guees it should be handled by DSS driver
> since that is where the state of DSS or ISS will be known. Note
> ISS will be automatically taken care since it will always use disaplay.
> 
> In internal tree's this was handled as part of DSS early suspend/resume

That version doesn't work as it uses functions that are not exported to
drivers.

I don't know much about the clock domain code, but I hope there's a way
to handle it there. Otherwise I guess I need to add a new set of
platform callback functions, so that the dss driver can call
arch/arm/mach-omap2 code to enable and disable the work-around. I
dislike that because I'm currently trying to remove those kinds of hacks
to make dss work better with DT =).

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: OMAP4 errata i740

[Santosh Shilimkar]

+ 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:
> 
>>> All OMAP4 versions seem to be affected. I couldn't find a mention about
>>> this in the mainline kernel. Any ideas how and where this should be
>>> fixed?
>>>
>> It's not patched for mainline. Generally clock-domain code
>> is abstracted from drivers but considering the errata and affected
>> modules, I guees it should be handled by DSS driver
>> since that is where the state of DSS or ISS will be known. Note
>> ISS will be automatically taken care since it will always use disaplay.
>>
>> In internal tree's this was handled as part of DSS early suspend/resume
> 
> That version doesn't work as it uses functions that are not exported to
> drivers.
> 
> I don't know much about the clock domain code, but I hope there's a way
> to handle it there. Otherwise I guess I need to add a new set of
> platform callback functions, so that the dss driver can call
> arch/arm/mach-omap2 code to enable and disable the work-around. I
> dislike that because I'm currently trying to remove those kinds of hacks
> to make dss work better with DT =).
> 
I agree. In fact I faced similar issue when I briefly tried moving
OMAP cpuidle code to drivers/idle/*.

That time me and Kevin concluded that till we move the powerdomain,
clockdomain code to drivers/* and export it, the cpuidle movement
needs to be deferred.

Regards
Santosh

Re: OMAP4 errata i740

[Archit Taneja]

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:
>>
>>>> All OMAP4 versions seem to be affected. I couldn't find a mention about
>>>> this in the mainline kernel. Any ideas how and where this should be
>>>> fixed?
>>>>
>>> It's not patched for mainline. Generally clock-domain code
>>> is abstracted from drivers but considering the errata and affected
>>> modules, I guees it should be handled by DSS driver
>>> since that is where the state of DSS or ISS will be known. Note
>>> ISS will be automatically taken care since it will always use disaplay.
>>>
>>> In internal tree's this was handled as part of DSS early suspend/resume
>>
>> That version doesn't work as it uses functions that are not exported to
>> drivers.
>>
>> I don't know much about the clock domain code, but I hope there's a way
>> to handle it there. Otherwise I guess I need to add a new set of
>> platform callback functions, so that the dss driver can call
>> arch/arm/mach-omap2 code to enable and disable the work-around. I
>> dislike that because I'm currently trying to remove those kinds of hacks
>> to make dss work better with DT =).
>>
> I agree. In fact I faced similar issue when I briefly tried moving
> OMAP cpuidle code to drivers/idle/*.
>
> That time me and Kevin concluded that till we move the powerdomain,
> clockdomain code to drivers/* and export it, the cpuidle movement
> needs to be deferred.

How about preventing the issue to occur by keeping DSS and ISS in 
No-standby mode for the affected OMAP versions. The errata says:

"Such a situation can occur when the impacted initiator is generating 
short MStandby pulses (pulse durations less than one L4 clock cycle)"

Chaning the mstandby hwmod data for DSS and ISS would prevent the need 
for exporting these clock domain functions only for this errata.

Archit


>
> Regards
> Santosh
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: OMAP4 errata i740

[Santosh Shilimkar]

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:
>>>
>>>>> All OMAP4 versions seem to be affected. I couldn't find a mention
>>>>> about
>>>>> this in the mainline kernel. Any ideas how and where this should be
>>>>> fixed?
>>>>>
>>>> It's not patched for mainline. Generally clock-domain code
>>>> is abstracted from drivers but considering the errata and affected
>>>> modules, I guees it should be handled by DSS driver
>>>> since that is where the state of DSS or ISS will be known. Note
>>>> ISS will be automatically taken care since it will always use disaplay.
>>>>
>>>> In internal tree's this was handled as part of DSS early suspend/resume
>>>
>>> That version doesn't work as it uses functions that are not exported to
>>> drivers.
>>>
>>> I don't know much about the clock domain code, but I hope there's a way
>>> to handle it there. Otherwise I guess I need to add a new set of
>>> platform callback functions, so that the dss driver can call
>>> arch/arm/mach-omap2 code to enable and disable the work-around. I
>>> dislike that because I'm currently trying to remove those kinds of hacks
>>> to make dss work better with DT =).
>>>
>> I agree. In fact I faced similar issue when I briefly tried moving
>> OMAP cpuidle code to drivers/idle/*.
>>
>> That time me and Kevin concluded that till we move the powerdomain,
>> clockdomain code to drivers/* and export it, the cpuidle movement
>> needs to be deferred.
> 
> How about preventing the issue to occur by keeping DSS and ISS in
> No-standby mode for the affected OMAP versions. The errata says:
> 
> "Such a situation can occur when the impacted initiator is generating
> short MStandby pulses (pulse durations less than one L4 clock cycle)"
> 
> Chaning the mstandby hwmod data for DSS and ISS would prevent the need
> for exporting these clock domain functions only for this errata.
> 
That will just break PM :-)

With this change DSS will never assert standby and then PRCM can never
send idle-req to modules. Indirectly no power transitions.

Regards
Santosh

Re: OMAP4 errata i740

[Cousson, Benoit]

On 3/30/2012 10:26 AM, 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:
>
>>> All OMAP4 versions seem to be affected. I couldn't find a mention about
>>> this in the mainline kernel. Any ideas how and where this should be
>>> fixed?
>>>
>> It's not patched for mainline. Generally clock-domain code
>> is abstracted from drivers but considering the errata and affected
>> modules, I guees it should be handled by DSS driver
>> since that is where the state of DSS or ISS will be known. Note
>> ISS will be automatically taken care since it will always use disaplay.
>>
>> In internal tree's this was handled as part of DSS early suspend/resume
>
> That version doesn't work as it uses functions that are not exported to
> drivers.
>
> I don't know much about the clock domain code, but I hope there's a way
> to handle it there. Otherwise I guess I need to add a new set of
> platform callback functions, so that the dss driver can call
> arch/arm/mach-omap2 code to enable and disable the work-around. I
> dislike that because I'm currently trying to remove those kinds of hacks
> to make dss work better with DT =).

I think we should just find another workaround :-)

There is not way we can let the drivers play directly with the clock 
domain idle mode.
And in theory hacking the local sysconfig should have the same effect.

So we should check for a better workaround with HW designers on that one.

Regards,
Benoit

Re: OMAP4 errata i740

[Cousson, Benoit]

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:
>>>>
>>>>>> All OMAP4 versions seem to be affected. I couldn't find a mention
>>>>>> about
>>>>>> this in the mainline kernel. Any ideas how and where this should be
>>>>>> fixed?
>>>>>>
>>>>> It's not patched for mainline. Generally clock-domain code
>>>>> is abstracted from drivers but considering the errata and affected
>>>>> modules, I guees it should be handled by DSS driver
>>>>> since that is where the state of DSS or ISS will be known. Note
>>>>> ISS will be automatically taken care since it will always use disaplay.
>>>>>
>>>>> In internal tree's this was handled as part of DSS early suspend/resume
>>>>
>>>> That version doesn't work as it uses functions that are not exported to
>>>> drivers.
>>>>
>>>> I don't know much about the clock domain code, but I hope there's a way
>>>> to handle it there. Otherwise I guess I need to add a new set of
>>>> platform callback functions, so that the dss driver can call
>>>> arch/arm/mach-omap2 code to enable and disable the work-around. I
>>>> dislike that because I'm currently trying to remove those kinds of hacks
>>>> to make dss work better with DT =).
>>>>
>>> I agree. In fact I faced similar issue when I briefly tried moving
>>> OMAP cpuidle code to drivers/idle/*.
>>>
>>> That time me and Kevin concluded that till we move the powerdomain,
>>> clockdomain code to drivers/* and export it, the cpuidle movement
>>> needs to be deferred.
>>
>> How about preventing the issue to occur by keeping DSS and ISS in
>> No-standby mode for the affected OMAP versions. The errata says:
>>
>> "Such a situation can occur when the impacted initiator is generating
>> short MStandby pulses (pulse durations less than one L4 clock cycle)"
>>
>> Chaning the mstandby hwmod data for DSS and ISS would prevent the need
>> for exporting these clock domain functions only for this errata.
>>
> That will just break PM :-)

Not at all. At least it will not be worst than the current WA.

I think Archit is right, at least this is the exact same question I'm 
asking to the designers :-).

> With this change DSS will never assert standby and then PRCM can never
> send idle-req to modules. Indirectly no power transitions.

This is exactly what will happen if you set the clock domain in NO_IDLE. 
So in any case, you cannot have autoidle during the

Regards,
Benoit

Re: OMAP4 errata i740

[Santosh Shilimkar]

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:
>>>>>
>>>>>>> All OMAP4 versions seem to be affected. I couldn't find a mention
>>>>>>> about
>>>>>>> this in the mainline kernel. Any ideas how and where this should be
>>>>>>> fixed?
>>>>>>>
>>>>>> It's not patched for mainline. Generally clock-domain code
>>>>>> is abstracted from drivers but considering the errata and affected
>>>>>> modules, I guees it should be handled by DSS driver
>>>>>> since that is where the state of DSS or ISS will be known. Note
>>>>>> ISS will be automatically taken care since it will always use
>>>>>> disaplay.
>>>>>>
>>>>>> In internal tree's this was handled as part of DSS early
>>>>>> suspend/resume
>>>>>
>>>>> That version doesn't work as it uses functions that are not
>>>>> exported to
>>>>> drivers.
>>>>>
>>>>> I don't know much about the clock domain code, but I hope there's a
>>>>> way
>>>>> to handle it there. Otherwise I guess I need to add a new set of
>>>>> platform callback functions, so that the dss driver can call
>>>>> arch/arm/mach-omap2 code to enable and disable the work-around. I
>>>>> dislike that because I'm currently trying to remove those kinds of
>>>>> hacks
>>>>> to make dss work better with DT =).
>>>>>
>>>> I agree. In fact I faced similar issue when I briefly tried moving
>>>> OMAP cpuidle code to drivers/idle/*.
>>>>
>>>> That time me and Kevin concluded that till we move the powerdomain,
>>>> clockdomain code to drivers/* and export it, the cpuidle movement
>>>> needs to be deferred.
>>>
>>> How about preventing the issue to occur by keeping DSS and ISS in
>>> No-standby mode for the affected OMAP versions. The errata says:
>>>
>>> "Such a situation can occur when the impacted initiator is generating
>>> short MStandby pulses (pulse durations less than one L4 clock cycle)"
>>>
>>> Chaning the mstandby hwmod data for DSS and ISS would prevent the need
>>> for exporting these clock domain functions only for this errata.
>>>
>> That will just break PM :-)
> 
> Not at all. At least it will not be worst than the current WA.
> 
> I think Archit is right, at least this is the exact same question I'm
> asking to the designers :-).
>
Am not sure what do you mean by here. What Archit said is statitically
setting up DSS/ISS sysnconfig to no standby. It will definitely break
PM.

The WA was doing runtime this with clockdomain APIs. If you say manage
the sysconfig runtime in driver, then it will work.

>> With this change DSS will never assert standby and then PRCM can never
>> send idle-req to modules. Indirectly no power transitions.
> 
> This is exactly what will happen if you set the clock domain in NO_IDLE.
> So in any case, you cannot have autoidle during the
> 
Guess I was not clear. The idea was to put CD in no_idle
when DSS active and allow idle when not active.

Looks like you saying OK to hack sysconfig for which we have
been pushing back on drivers not to do it. Ofcourse errata
and various reset bugs have broken that rule anyways.

Regards
Santosh

Regards
santosh

Re: OMAP4 errata i740

[Archit Taneja]

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:
>>>>>>
>>>>>>>> All OMAP4 versions seem to be affected. I couldn't find a mention
>>>>>>>> about
>>>>>>>> this in the mainline kernel. Any ideas how and where this should be
>>>>>>>> fixed?
>>>>>>>>
>>>>>>> It's not patched for mainline. Generally clock-domain code
>>>>>>> is abstracted from drivers but considering the errata and affected
>>>>>>> modules, I guees it should be handled by DSS driver
>>>>>>> since that is where the state of DSS or ISS will be known. Note
>>>>>>> ISS will be automatically taken care since it will always use
>>>>>>> disaplay.
>>>>>>>
>>>>>>> In internal tree's this was handled as part of DSS early
>>>>>>> suspend/resume
>>>>>>
>>>>>> That version doesn't work as it uses functions that are not
>>>>>> exported to
>>>>>> drivers.
>>>>>>
>>>>>> I don't know much about the clock domain code, but I hope there's a
>>>>>> way
>>>>>> to handle it there. Otherwise I guess I need to add a new set of
>>>>>> platform callback functions, so that the dss driver can call
>>>>>> arch/arm/mach-omap2 code to enable and disable the work-around. I
>>>>>> dislike that because I'm currently trying to remove those kinds of
>>>>>> hacks
>>>>>> to make dss work better with DT =).
>>>>>>
>>>>> I agree. In fact I faced similar issue when I briefly tried moving
>>>>> OMAP cpuidle code to drivers/idle/*.
>>>>>
>>>>> That time me and Kevin concluded that till we move the powerdomain,
>>>>> clockdomain code to drivers/* and export it, the cpuidle movement
>>>>> needs to be deferred.
>>>>
>>>> How about preventing the issue to occur by keeping DSS and ISS in
>>>> No-standby mode for the affected OMAP versions. The errata says:
>>>>
>>>> "Such a situation can occur when the impacted initiator is generating
>>>> short MStandby pulses (pulse durations less than one L4 clock cycle)"
>>>>
>>>> Chaning the mstandby hwmod data for DSS and ISS would prevent the need
>>>> for exporting these clock domain functions only for this errata.
>>>>
>>> That will just break PM :-)
>>
>> Not at all. At least it will not be worst than the current WA.
>>
>> I think Archit is right, at least this is the exact same question I'm
>> asking to the designers :-).
>>
> Am not sure what do you mean by here. What Archit said is statitically
> setting up DSS/ISS sysnconfig to no standby. It will definitely break
> PM.
>
> The WA was doing runtime this with clockdomain APIs. If you say manage
> the sysconfig runtime in driver, then it will work.

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!

Archit

>
>>> With this change DSS will never assert standby and then PRCM can never
>>> send idle-req to modules. Indirectly no power transitions.
>>
>> This is exactly what will happen if you set the clock domain in NO_IDLE.
>> So in any case, you cannot have autoidle during the
>>
> Guess I was not clear. The idea was to put CD in no_idle
> when DSS active and allow idle when not active.
>
> Looks like you saying OK to hack sysconfig for which we have
> been pushing back on drivers not to do it. Ofcourse errata
> and various reset bugs have broken that rule anyways.
>
> Regards
> Santosh
>
> Regards
> santosh
>
>

Re: OMAP4 errata i740

[Shilimkar, Santosh]

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.

So PRCM won't poke that PD initiators/modules because it has
already have a green signal for power transitions. At least that is
what my understanding from the OMAP PRCM specs.

Regards
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP4 errata i740

[Archit Taneja]

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 :)

Archit

>
> So PRCM won't poke that PD initiators/modules because it has
> already have a green signal for power transitions. At least that is
> what my understanding from the OMAP PRCM specs.
>
> Regards
> Santosh
>

Re: OMAP4 errata i740

[Shilimkar, Santosh]

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.

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.

Regards
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP4 errata i740

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

On Fri, 2012-03-30 at 16:50 +0530, Shilimkar, Santosh wrote:

> Exactly. That's what I mean. You tweak sysconfig or clockdomain,
> both are messy.
> 
> 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.

If the driver touches sysconfig, isn't it possible that hwmod/something
just reverts the changes? I mean, sysconfig register is supposedly
"owned" by the arch code, and if the driver modifies it there could be a
race condition.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: OMAP4 errata i740

[Cousson, Benoit]

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

Re: OMAP4 errata i740

[Cousson, Benoit]

On 3/30/2012 1:59 PM, Tomi Valkeinen wrote:
> On Fri, 2012-03-30 at 16:50 +0530, Shilimkar, Santosh wrote:
>
>> Exactly. That's what I mean. You tweak sysconfig or clockdomain,
>> both are messy.
>>
>> 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.
>
> If the driver touches sysconfig, isn't it possible that hwmod/something
> just reverts the changes? I mean, sysconfig register is supposedly
> "owned" by the arch code, and if the driver modifies it there could be a
> race condition.

No because we had to expose API from hwmod core code to do that already 
because of various HW bugs.
So you will not access it directly but through the hwmod API.

The only issue is that these API are exposed today through pdata 
function pointers, and thus this is not usable in a DT case :-(

Regards,
Benoit

Re: OMAP4 errata i740

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]

On Fri, 2012-03-30 at 14:02 +0200, Cousson, Benoit wrote:
> On 3/30/2012 1:59 PM, Tomi Valkeinen wrote:
> > On Fri, 2012-03-30 at 16:50 +0530, Shilimkar, Santosh wrote:
> >
> >> Exactly. That's what I mean. You tweak sysconfig or clockdomain,
> >> both are messy.
> >>
> >> 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.
> >
> > If the driver touches sysconfig, isn't it possible that hwmod/something
> > just reverts the changes? I mean, sysconfig register is supposedly
> > "owned" by the arch code, and if the driver modifies it there could be a
> > race condition.
> 
> No because we had to expose API from hwmod core code to do that already 
> because of various HW bugs.
> So you will not access it directly but through the hwmod API.

Ah. What functions would be needed to solve this case?

> The only issue is that these API are exposed today through pdata 
> function pointers, and thus this is not usable in a DT case :-(

That's ok (for now), we will anyway have this "omapdss" higer level
driver, which is not HW driver (i.e. not mentioned in the DT data), but
created in arch/arm code. I have put all the current function pointers
there already, so I can add a few more.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: OMAP4 errata i740

[Santosh Shilimkar]

On Friday 30 March 2012 05:30 PM, Cousson, Benoit wrote:
> On 3/30/2012 1:20 PM, Shilimkar, Santosh wrote:

[..]

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

Sorry for small digration but the clock-domain/power domain APIs
were coming in between CPUIDLE code movement to drivers/idle/*

How do we deal with that code which is today lying under platform
code.

Regards
Santosh