RE: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430

RE: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430

[Shilimkar, Santosh]

Shweta,
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of y@india.ti.com
> Sent: Monday, October 05, 2009 4:53 PM
> To: linux-omap@vger.kernel.org
> Cc: Gulati, Shweta
> Subject: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on
> OMAP3430
> 
> From: Shweta Gulati <shweta.gulati@ti.com>

Please add change-log / description about this patch here.

> Signed-off-by: Shweta Gulati <shweta.gulati@ti.com>
> ---
>  arch/arm/mach-omap2/pm34xx.c |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index a9eda25..38f4781 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -140,6 +140,12 @@ static void omap3_core_save_context(void)
>  	omap_ctrl_readl(OMAP343X_CONTROL_PADCONF_OFF);
>  	control_padconf_off |= START_PADCONF_SAVE;
>  	omap_ctrl_writel(control_padconf_off, OMAP343X_CONTROL_PADCONF_OFF);
> +	/* Due to Silicon Bug on context restore it is found
> +	 * that the CONTROL_PAD_CONF_ETK14 register is not saved into
> +	 * scratch pad memory sometimes. To rectify it delay acess by Mpu
> +	 * for 300us for scm to finish saving task
> +	 */
> +	udelay(300);
>  	/* wait for the save to complete */
>  	while (!omap_ctrl_readl(OMAP343X_CONTROL_GENERAL_PURPOSE_STATUS)
>  			& PADCONF_SAVE_DONE)
> --
> 1.5.4.7
> 
> --
> 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

Regards,
Santosh

Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430

[Kevin Hilman]

y@india.ti.com writes:

> From: Shweta Gulati <shweta.gulati@ti.com>

Please add descriptive changelog, including Erratta number and
summary of the bug.

> Signed-off-by: Shweta Gulati <shweta.gulati@ti.com>
> ---
>  arch/arm/mach-omap2/pm34xx.c |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index a9eda25..38f4781 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -140,6 +140,12 @@ static void omap3_core_save_context(void)
>  	omap_ctrl_readl(OMAP343X_CONTROL_PADCONF_OFF);
>  	control_padconf_off |= START_PADCONF_SAVE;
>  	omap_ctrl_writel(control_padconf_off, OMAP343X_CONTROL_PADCONF_OFF);
> +	/* Due to Silicon Bug on context restore it is found
> +	 * that the CONTROL_PAD_CONF_ETK14 register is not saved into
> +	 * scratch pad memory sometimes. To rectify it delay acess by Mpu
> +	 * for 300us for scm to finish saving task
> +	 */
> +	udelay(300);

Why 300 usecs?
Is ETK14 the only register not saved?

>  	/* wait for the save to complete */
>  	while (!omap_ctrl_readl(OMAP343X_CONTROL_GENERAL_PURPOSE_STATUS)
>  			& PADCONF_SAVE_DONE)

And please describe why this loop doesn't work.

Kevin

Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430

[Nishanth Menon]

Kevin Hilman had written, on 10/05/2009 12:04 PM, the following:
> y@india.ti.com writes:
> 
>> From: Shweta Gulati <shweta.gulati@ti.com>
> 
> Please add descriptive changelog, including Erratta number and
> summary of the bug.
> 
>> Signed-off-by: Shweta Gulati <shweta.gulati@ti.com>
>> ---
>>  arch/arm/mach-omap2/pm34xx.c |    6 ++++++
>>  1 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
>> index a9eda25..38f4781 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -140,6 +140,12 @@ static void omap3_core_save_context(void)
>>  	omap_ctrl_readl(OMAP343X_CONTROL_PADCONF_OFF);
>>  	control_padconf_off |= START_PADCONF_SAVE;
>>  	omap_ctrl_writel(control_padconf_off, OMAP343X_CONTROL_PADCONF_OFF);
>> +	/* Due to Silicon Bug on context restore it is found
>> +	 * that the CONTROL_PAD_CONF_ETK14 register is not saved into
>> +	 * scratch pad memory sometimes. To rectify it delay acess by Mpu
>> +	 * for 300us for scm to finish saving task
>> +	 */
>> +	udelay(300);
> 
> Why 300 usecs?
300uSec could be optimized as I understand.

> Is ETK14 the only register not saved?
The bug as I understand is that the register is saved, but restore 
potentially can corrupt the values.
there is an alternative implementation possible:
a) we save the register in a seperate variable
b) we allow the restore issue to kick us (essentially allow it to be 
corrupted)
c) we over write the restored value with the saved value.
This has the risk of a glitch on the line (between the corrupted restore 
data to the time we restore with correct data).

-- 
Regards,
Nishanth Menon

RE: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430

[Gopinath, Thara]

The problem here is not with the restore. If MPU reads the PADCONF_SAVEDONE bit very close
to the end of context save sequence for the pad conf registers, the last context is not
saved to the scratchpad memory. This is a h/w bug. The workaround proposed is to delay the
MPU access of SAVEDONE bit until the last context has been saved. 300 us delay is the current
safe delay proposed by TI. I believe investigations are going on to whether this delay can be
optimized. Also only the last context (ETK_D14) has the risk of not getting saved.

We could add a defconfig option for this workaround and enable it on need basis till TI
comes out with proper optimized workaround sequence.

Regards
Thara

>>-----Original Message-----
>>From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Menon,
>>Nishanth
>>Sent: Monday, October 05, 2009 10:58 PM
>>To: Kevin Hilman
>>Cc: linux-omap@vger.kernel.org; Gulati, Shweta
>>Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
>>
>>Kevin Hilman had written, on 10/05/2009 12:04 PM, the following:
>>> y@india.ti.com writes:
>>>
>>>> From: Shweta Gulati <shweta.gulati@ti.com>
>>>
>>> Please add descriptive changelog, including Erratta number and
>>> summary of the bug.
>>>
>>>> Signed-off-by: Shweta Gulati <shweta.gulati@ti.com>
>>>> ---
>>>>  arch/arm/mach-omap2/pm34xx.c |    6 ++++++
>>>>  1 files changed, 6 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
>>>> index a9eda25..38f4781 100644
>>>> --- a/arch/arm/mach-omap2/pm34xx.c
>>>> +++ b/arch/arm/mach-omap2/pm34xx.c
>>>> @@ -140,6 +140,12 @@ static void omap3_core_save_context(void)
>>>>  	omap_ctrl_readl(OMAP343X_CONTROL_PADCONF_OFF);
>>>>  	control_padconf_off |= START_PADCONF_SAVE;
>>>>  	omap_ctrl_writel(control_padconf_off, OMAP343X_CONTROL_PADCONF_OFF);
>>>> +	/* Due to Silicon Bug on context restore it is found
>>>> +	 * that the CONTROL_PAD_CONF_ETK14 register is not saved into
>>>> +	 * scratch pad memory sometimes. To rectify it delay acess by Mpu
>>>> +	 * for 300us for scm to finish saving task
>>>> +	 */
>>>> +	udelay(300);
>>>
>>> Why 300 usecs?
>>300uSec could be optimized as I understand.
>>
>>> Is ETK14 the only register not saved?
>>The bug as I understand is that the register is saved, but restore
>>potentially can corrupt the values.
>>there is an alternative implementation possible:
>>a) we save the register in a seperate variable
>>b) we allow the restore issue to kick us (essentially allow it to be
>>corrupted)
>>c) we over write the restored value with the saved value.
>>This has the risk of a glitch on the line (between the corrupted restore
>>data to the time we restore with correct data).
>>
>>--
>>Regards,
>>Nishanth Menon
>>--
>>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: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430

[Nishanth Menon]

Gopinath, Thara had written, on 10/06/2009 01:59 AM, the following:
> The problem here is not with the restore. If MPU reads the PADCONF_SAVEDONE bit very close
> to the end of context save sequence for the pad conf registers, the last context is not
> saved to the scratchpad memory. This is a h/w bug. The workaround proposed is to delay the
> MPU access of SAVEDONE bit until the last context has been saved. 300 us delay is the current
> safe delay proposed by TI. I believe investigations are going on to whether this delay can be
> optimized. Also only the last context (ETK_D14) has the risk of not getting saved.
So, if I were to save specifically the ETK14 and restore it explicitly, 
I could in theory work around this issue.

> 
> We could add a defconfig option for this workaround and enable it on need basis till TI
> comes out with proper optimized workaround sequence.
we could probably hope to see a final patch then I believe?

Regards,
Nishanth Menon

Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430

[Kevin Hilman]

"Gopinath, Thara" <thara@ti.com> writes:

> The problem here is not with the restore. If MPU reads the PADCONF_SAVEDONE bit very close
> to the end of context save sequence for the pad conf registers, the last context is not
> saved to the scratchpad memory. This is a h/w bug. The workaround proposed is to delay the
> MPU access of SAVEDONE bit until the last context has been saved. 300 us delay is the current
> safe delay proposed by TI. I believe investigations are going on to whether this delay can be
> optimized. Also only the last context (ETK_D14) has the risk of not getting saved.

All of this should've been in the original changelog.  These are the
details that help others understand the problem trying to be solved
and think about whether there might be other solutions.

> We could add a defconfig option for this workaround and enable it on need basis till TI
> comes out with proper optimized workaround sequence.

No, Kconfig is not an option for this.

I think Nishanth's proposal is a much better workaround for this
problem, and doesn't introduce and additional 300 usec delay to
*every* off-mode transistion.

Kevin

>
>>>-----Original Message-----
>>>From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Menon,
>>>Nishanth
>>>Sent: Monday, October 05, 2009 10:58 PM
>>>To: Kevin Hilman
>>>Cc: linux-omap@vger.kernel.org; Gulati, Shweta
>>>Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
>>>
>>>Kevin Hilman had written, on 10/05/2009 12:04 PM, the following:
>>>> y@india.ti.com writes:
>>>>
>>>>> From: Shweta Gulati <shweta.gulati@ti.com>
>>>>
>>>> Please add descriptive changelog, including Erratta number and
>>>> summary of the bug.
>>>>
>>>>> Signed-off-by: Shweta Gulati <shweta.gulati@ti.com>
>>>>> ---
>>>>>  arch/arm/mach-omap2/pm34xx.c |    6 ++++++
>>>>>  1 files changed, 6 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
>>>>> index a9eda25..38f4781 100644
>>>>> --- a/arch/arm/mach-omap2/pm34xx.c
>>>>> +++ b/arch/arm/mach-omap2/pm34xx.c
>>>>> @@ -140,6 +140,12 @@ static void omap3_core_save_context(void)
>>>>>  	omap_ctrl_readl(OMAP343X_CONTROL_PADCONF_OFF);
>>>>>  	control_padconf_off |= START_PADCONF_SAVE;
>>>>>  	omap_ctrl_writel(control_padconf_off, OMAP343X_CONTROL_PADCONF_OFF);
>>>>> +	/* Due to Silicon Bug on context restore it is found
>>>>> +	 * that the CONTROL_PAD_CONF_ETK14 register is not saved into
>>>>> +	 * scratch pad memory sometimes. To rectify it delay acess by Mpu
>>>>> +	 * for 300us for scm to finish saving task
>>>>> +	 */
>>>>> +	udelay(300);
>>>>
>>>> Why 300 usecs?
>>>300uSec could be optimized as I understand.
>>>
>>>> Is ETK14 the only register not saved?
>>>The bug as I understand is that the register is saved, but restore
>>>potentially can corrupt the values.
>>>there is an alternative implementation possible:
>>>a) we save the register in a seperate variable
>>>b) we allow the restore issue to kick us (essentially allow it to be
>>>corrupted)
>>>c) we over write the restored value with the saved value.
>>>This has the risk of a glitch on the line (between the corrupted restore
>>>data to the time we restore with correct data).
>>>
>>>--
>>>Regards,
>>>Nishanth Menon
>>>--
>>>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: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430

[Gopinath, Thara]

>>-----Original Message-----
>>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>Sent: Tuesday, October 06, 2009 6:47 PM
>>To: Gopinath, Thara
>>Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta
>>Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
>>
>>"Gopinath, Thara" <thara@ti.com> writes:
>>
>>> The problem here is not with the restore. If MPU reads the PADCONF_SAVEDONE bit very close
>>> to the end of context save sequence for the pad conf registers, the last context is not
>>> saved to the scratchpad memory. This is a h/w bug. The workaround proposed is to delay the
>>> MPU access of SAVEDONE bit until the last context has been saved. 300 us delay is the current
>>> safe delay proposed by TI. I believe investigations are going on to whether this delay can be
>>> optimized. Also only the last context (ETK_D14) has the risk of not getting saved.
>>
>>All of this should've been in the original changelog.  These are the
>>details that help others understand the problem trying to be solved
>>and think about whether there might be other solutions.
>>
>>> We could add a defconfig option for this workaround and enable it on need basis till TI
>>> comes out with proper optimized workaround sequence.
>>
>>No, Kconfig is not an option for this.
>>
>>I think Nishanth's proposal is a much better workaround for this
>>problem, and doesn't introduce and additional 300 usec delay to
>>*every* off-mode transistion.

I am not very sure about this as it has the risk of glitch on the line. It is probably ok if the ball is not used. But if in use, the glitch could create issues. 
>>
>>Kevin

Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430

[Kevin Hilman]

"Gopinath, Thara" <thara@ti.com> writes:

>>>-----Original Message-----
>>>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>>Sent: Tuesday, October 06, 2009 6:47 PM
>>>To: Gopinath, Thara
>>>Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta
>>>Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
>>>
>>>"Gopinath, Thara" <thara@ti.com> writes:
>>>
>>>> The problem here is not with the restore. If MPU reads the PADCONF_SAVEDONE bit very close
>>>> to the end of context save sequence for the pad conf registers, the last context is not
>>>> saved to the scratchpad memory. This is a h/w bug. The workaround proposed is to delay the
>>>> MPU access of SAVEDONE bit until the last context has been saved. 300 us delay is the current
>>>> safe delay proposed by TI. I believe investigations are going on to whether this delay can be
>>>> optimized. Also only the last context (ETK_D14) has the risk of not getting saved.
>>>
>>>All of this should've been in the original changelog.  These are the
>>>details that help others understand the problem trying to be solved
>>>and think about whether there might be other solutions.
>>>
>>>> We could add a defconfig option for this workaround and enable it on need basis till TI
>>>> comes out with proper optimized workaround sequence.
>>>
>>>No, Kconfig is not an option for this.
>>>
>>>I think Nishanth's proposal is a much better workaround for this
>>>problem, and doesn't introduce and additional 300 usec delay to
>>>*every* off-mode transistion.
>
> I am not very sure about this as it has the risk of glitch on the
> line. It is probably ok if the ball is not used. But if in use, the
> glitch could create issues.

I don't follow.

IIUC, Nishanth's proposal would be to

In save context:
- manually save ETK_D14 to some static variable (SDRAM)
- initiate the padconf safe 
- poll SAVE_DONE
- here ETK_D14 value saved by HW possibly corrupted, 
  but the copy saved manually should be fine

In restore:
- manually restore ETK_D14 from the static variable

What is wrong with this approach?

Kevin

RE: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430

[Gopinath, Thara]

>>-----Original Message-----
>>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>Sent: Tuesday, October 06, 2009 7:50 PM
>>To: Gopinath, Thara
>>Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta
>>Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
>>
>>"Gopinath, Thara" <thara@ti.com> writes:
>>
>>>>>-----Original Message-----
>>>>>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>>>>Sent: Tuesday, October 06, 2009 6:47 PM
>>>>>To: Gopinath, Thara
>>>>>Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta
>>>>>Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
>>>>>
>>>>>"Gopinath, Thara" <thara@ti.com> writes:
>>>>>
>>>>>> The problem here is not with the restore. If MPU reads the PADCONF_SAVEDONE bit very close
>>>>>> to the end of context save sequence for the pad conf registers, the last context is not
>>>>>> saved to the scratchpad memory. This is a h/w bug. The workaround proposed is to delay the
>>>>>> MPU access of SAVEDONE bit until the last context has been saved. 300 us delay is the current
>>>>>> safe delay proposed by TI. I believe investigations are going on to whether this delay can be
>>>>>> optimized. Also only the last context (ETK_D14) has the risk of not getting saved.
>>>>>
>>>>>All of this should've been in the original changelog.  These are the
>>>>>details that help others understand the problem trying to be solved
>>>>>and think about whether there might be other solutions.
>>>>>
>>>>>> We could add a defconfig option for this workaround and enable it on need basis till TI
>>>>>> comes out with proper optimized workaround sequence.
>>>>>
>>>>>No, Kconfig is not an option for this.
>>>>>
>>>>>I think Nishanth's proposal is a much better workaround for this
>>>>>problem, and doesn't introduce and additional 300 usec delay to
>>>>>*every* off-mode transistion.
>>>
>>> I am not very sure about this as it has the risk of glitch on the
>>> line. It is probably ok if the ball is not used. But if in use, the
>>> glitch could create issues.
>>
>>I don't follow.
>>
>>IIUC, Nishanth's proposal would be to
>>
>>In save context:
>>- manually save ETK_D14 to some static variable (SDRAM)
>>- initiate the padconf safe
>>- poll SAVE_DONE
>>- here ETK_D14 value saved by HW possibly corrupted,
>>  but the copy saved manually should be fine
>>
>>In restore:
>>- manually restore ETK_D14 from the static variable
>>
>>What is wrong with this approach?
In this approach there is a possibility that the h/w restore a wrong value to PADCONF_ETKD14.
Now suppose this pin is in use and is supposed to be pulled high. And the proper save does not happen
1. Before going to Off - the pin is pulled high
2. Off 
3. h/w restore - Has done bad save. So bad value restored. Say pull low.
4. Manual restore - the pin is again pulled high.

Now there is a glitch between step 3 and 4. If this pin is not used by anybody we could live with this glitch. But considering this pin is muxed with gpio28/gpio29, hsusb_tll_data0/ hsusb_tll_data1 this glitch might be unacceptable.

Regards
Thara

Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430

[Kevin Hilman]

"Gopinath, Thara" <thara@ti.com> writes:

>>>-----Original Message-----
>>>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>>Sent: Tuesday, October 06, 2009 7:50 PM
>>>To: Gopinath, Thara
>>>Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta
>>>Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
>>>
>>>"Gopinath, Thara" <thara@ti.com> writes:
>>>
>>>>>>-----Original Message-----
>>>>>>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>>>>>Sent: Tuesday, October 06, 2009 6:47 PM
>>>>>>To: Gopinath, Thara
>>>>>>Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta
>>>>>>Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
>>>>>>
>>>>>>"Gopinath, Thara" <thara@ti.com> writes:
>>>>>>
>>>>>>> The problem here is not with the restore. If MPU reads the PADCONF_SAVEDONE bit very close
>>>>>>> to the end of context save sequence for the pad conf registers, the last context is not
>>>>>>> saved to the scratchpad memory. This is a h/w bug. The workaround proposed is to delay the
>>>>>>> MPU access of SAVEDONE bit until the last context has been saved. 300 us delay is the current
>>>>>>> safe delay proposed by TI. I believe investigations are going on to whether this delay can be
>>>>>>> optimized. Also only the last context (ETK_D14) has the risk of not getting saved.
>>>>>>
>>>>>>All of this should've been in the original changelog.  These are the
>>>>>>details that help others understand the problem trying to be solved
>>>>>>and think about whether there might be other solutions.
>>>>>>
>>>>>>> We could add a defconfig option for this workaround and enable it on need basis till TI
>>>>>>> comes out with proper optimized workaround sequence.
>>>>>>
>>>>>>No, Kconfig is not an option for this.
>>>>>>
>>>>>>I think Nishanth's proposal is a much better workaround for this
>>>>>>problem, and doesn't introduce and additional 300 usec delay to
>>>>>>*every* off-mode transistion.
>>>>
>>>> I am not very sure about this as it has the risk of glitch on the
>>>> line. It is probably ok if the ball is not used. But if in use, the
>>>> glitch could create issues.
>>>
>>>I don't follow.
>>>
>>>IIUC, Nishanth's proposal would be to
>>>
>>>In save context:
>>>- manually save ETK_D14 to some static variable (SDRAM)
>>>- initiate the padconf safe
>>>- poll SAVE_DONE
>>>- here ETK_D14 value saved by HW possibly corrupted,
>>>  but the copy saved manually should be fine
>>>
>>>In restore:
>>>- manually restore ETK_D14 from the static variable
>>>
>>>What is wrong with this approach?
> In this approach there is a possibility that the h/w restore a wrong value to PADCONF_ETKD14.
> Now suppose this pin is in use and is supposed to be pulled high. And the proper save does not happen
> 1. Before going to Off - the pin is pulled high
> 2. Off 
> 3. h/w restore - Has done bad save. So bad value restored. Say pull low.
> 4. Manual restore - the pin is again pulled high.
>
> Now there is a glitch between step 3 and 4. If this pin is not used by anybody we could live with this glitch. But considering this pin is muxed with gpio28/gpio29, hsusb_tll_data0/ hsusb_tll_data1 this glitch might be unacceptable.

I see now.  Thanks for explanation.

Kevin

RE: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430

[Gopinath, Thara]

Will repost the patch with the defconfig option added. So that this can be disabled if not needed.

Regards
Thara
>>-----Original Message-----
>>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>Sent: Tuesday, October 06, 2009 8:19 PM
>>To: Gopinath, Thara
>>Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta
>>Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
>>
>>"Gopinath, Thara" <thara@ti.com> writes:
>>
>>>>>-----Original Message-----
>>>>>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>>>>Sent: Tuesday, October 06, 2009 7:50 PM
>>>>>To: Gopinath, Thara
>>>>>Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta
>>>>>Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
>>>>>
>>>>>"Gopinath, Thara" <thara@ti.com> writes:
>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>>>>>>>Sent: Tuesday, October 06, 2009 6:47 PM
>>>>>>>>To: Gopinath, Thara
>>>>>>>>Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta
>>>>>>>>Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
>>>>>>>>
>>>>>>>>"Gopinath, Thara" <thara@ti.com> writes:
>>>>>>>>
>>>>>>>>> The problem here is not with the restore. If MPU reads the PADCONF_SAVEDONE bit very close
>>>>>>>>> to the end of context save sequence for the pad conf registers, the last context is not
>>>>>>>>> saved to the scratchpad memory. This is a h/w bug. The workaround proposed is to delay the
>>>>>>>>> MPU access of SAVEDONE bit until the last context has been saved. 300 us delay is the current
>>>>>>>>> safe delay proposed by TI. I believe investigations are going on to whether this delay can be
>>>>>>>>> optimized. Also only the last context (ETK_D14) has the risk of not getting saved.
>>>>>>>>
>>>>>>>>All of this should've been in the original changelog.  These are the
>>>>>>>>details that help others understand the problem trying to be solved
>>>>>>>>and think about whether there might be other solutions.
>>>>>>>>
>>>>>>>>> We could add a defconfig option for this workaround and enable it on need basis till TI
>>>>>>>>> comes out with proper optimized workaround sequence.
>>>>>>>>
>>>>>>>>No, Kconfig is not an option for this.
>>>>>>>>
>>>>>>>>I think Nishanth's proposal is a much better workaround for this
>>>>>>>>problem, and doesn't introduce and additional 300 usec delay to
>>>>>>>>*every* off-mode transistion.
>>>>>>
>>>>>> I am not very sure about this as it has the risk of glitch on the
>>>>>> line. It is probably ok if the ball is not used. But if in use, the
>>>>>> glitch could create issues.
>>>>>
>>>>>I don't follow.
>>>>>
>>>>>IIUC, Nishanth's proposal would be to
>>>>>
>>>>>In save context:
>>>>>- manually save ETK_D14 to some static variable (SDRAM)
>>>>>- initiate the padconf safe
>>>>>- poll SAVE_DONE
>>>>>- here ETK_D14 value saved by HW possibly corrupted,
>>>>>  but the copy saved manually should be fine
>>>>>
>>>>>In restore:
>>>>>- manually restore ETK_D14 from the static variable
>>>>>
>>>>>What is wrong with this approach?
>>> In this approach there is a possibility that the h/w restore a wrong value to PADCONF_ETKD14.
>>> Now suppose this pin is in use and is supposed to be pulled high. And the proper save does not
>>happen
>>> 1. Before going to Off - the pin is pulled high
>>> 2. Off
>>> 3. h/w restore - Has done bad save. So bad value restored. Say pull low.
>>> 4. Manual restore - the pin is again pulled high.
>>>
>>> Now there is a glitch between step 3 and 4. If this pin is not used by anybody we could live with
>>this glitch. But considering this pin is muxed with gpio28/gpio29, hsusb_tll_data0/ hsusb_tll_data1
>>this glitch might be unacceptable.
>>
>>I see now.  Thanks for explanation.
>>
>>Kevin

Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430

[Kevin Hilman]

"Gopinath, Thara" <thara@ti.com> writes:

> Will repost the patch with the defconfig option added. So that this can be disabled if not needed.

ok, please update the changelog as well as describe the 300usec value
in terms of cycles.  IOW, is 300usecs going to work at lower OPPs also?

Kevin

>>>-----Original Message-----
>>>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>>Sent: Tuesday, October 06, 2009 8:19 PM
>>>To: Gopinath, Thara
>>>Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta
>>>Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
>>>
>>>"Gopinath, Thara" <thara@ti.com> writes:
>>>
>>>>>>-----Original Message-----
>>>>>>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>>>>>Sent: Tuesday, October 06, 2009 7:50 PM
>>>>>>To: Gopinath, Thara
>>>>>>Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta
>>>>>>Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
>>>>>>
>>>>>>"Gopinath, Thara" <thara@ti.com> writes:
>>>>>>
>>>>>>>>>-----Original Message-----
>>>>>>>>>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>>>>>>>>Sent: Tuesday, October 06, 2009 6:47 PM
>>>>>>>>>To: Gopinath, Thara
>>>>>>>>>Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta
>>>>>>>>>Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
>>>>>>>>>
>>>>>>>>>"Gopinath, Thara" <thara@ti.com> writes:
>>>>>>>>>
>>>>>>>>>> The problem here is not with the restore. If MPU reads the PADCONF_SAVEDONE bit very close
>>>>>>>>>> to the end of context save sequence for the pad conf registers, the last context is not
>>>>>>>>>> saved to the scratchpad memory. This is a h/w bug. The workaround proposed is to delay the
>>>>>>>>>> MPU access of SAVEDONE bit until the last context has been saved. 300 us delay is the current
>>>>>>>>>> safe delay proposed by TI. I believe investigations are going on to whether this delay can be
>>>>>>>>>> optimized. Also only the last context (ETK_D14) has the risk of not getting saved.
>>>>>>>>>
>>>>>>>>>All of this should've been in the original changelog.  These are the
>>>>>>>>>details that help others understand the problem trying to be solved
>>>>>>>>>and think about whether there might be other solutions.
>>>>>>>>>
>>>>>>>>>> We could add a defconfig option for this workaround and enable it on need basis till TI
>>>>>>>>>> comes out with proper optimized workaround sequence.
>>>>>>>>>
>>>>>>>>>No, Kconfig is not an option for this.
>>>>>>>>>
>>>>>>>>>I think Nishanth's proposal is a much better workaround for this
>>>>>>>>>problem, and doesn't introduce and additional 300 usec delay to
>>>>>>>>>*every* off-mode transistion.
>>>>>>>
>>>>>>> I am not very sure about this as it has the risk of glitch on the
>>>>>>> line. It is probably ok if the ball is not used. But if in use, the
>>>>>>> glitch could create issues.
>>>>>>
>>>>>>I don't follow.
>>>>>>
>>>>>>IIUC, Nishanth's proposal would be to
>>>>>>
>>>>>>In save context:
>>>>>>- manually save ETK_D14 to some static variable (SDRAM)
>>>>>>- initiate the padconf safe
>>>>>>- poll SAVE_DONE
>>>>>>- here ETK_D14 value saved by HW possibly corrupted,
>>>>>>  but the copy saved manually should be fine
>>>>>>
>>>>>>In restore:
>>>>>>- manually restore ETK_D14 from the static variable
>>>>>>
>>>>>>What is wrong with this approach?
>>>> In this approach there is a possibility that the h/w restore a wrong value to PADCONF_ETKD14.
>>>> Now suppose this pin is in use and is supposed to be pulled high. And the proper save does not
>>>happen
>>>> 1. Before going to Off - the pin is pulled high
>>>> 2. Off
>>>> 3. h/w restore - Has done bad save. So bad value restored. Say pull low.
>>>> 4. Manual restore - the pin is again pulled high.
>>>>
>>>> Now there is a glitch between step 3 and 4. If this pin is not used by anybody we could live with
>>>this glitch. But considering this pin is muxed with gpio28/gpio29, hsusb_tll_data0/ hsusb_tll_data1
>>>this glitch might be unacceptable.
>>>
>>>I see now.  Thanks for explanation.
>>>
>>>Kevin

Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430

[Nishanth Menon]

Kevin Hilman had written, on 10/06/2009 10:05 AM, the following:
> "Gopinath, Thara" <thara@ti.com> writes:
> 
>> Will repost the patch with the defconfig option added. So that this can be disabled if not needed.
> 
> ok, please update the changelog as well as describe the 300usec value
> in terms of cycles.  IOW, is 300usecs going to work at lower OPPs also?
> 
Could I request for 2 options:
a) workaround with no delay (manual save restore) - power savings for 
boards which dont use the pin
b) workaround with 300uSec - for boards which use the pin ->functional

Also please have a check based on CPU revision and add errata number?

-- 
Regards,
Nishanth Menon

RE: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430

[Gopinath, Thara]

>>-----Original Message-----
>>From: Menon, Nishanth
>>Sent: Tuesday, October 06, 2009 8:48 PM
>>To: Kevin Hilman
>>Cc: Gopinath, Thara; linux-omap@vger.kernel.org; Gulati, Shweta
>>Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
>>
>>Kevin Hilman had written, on 10/06/2009 10:05 AM, the following:
>>> "Gopinath, Thara" <thara@ti.com> writes:
>>>
>>>> Will repost the patch with the defconfig option added. So that this can be disabled if not needed.
>>>
>>> ok, please update the changelog as well as describe the 300usec value
>>> in terms of cycles.  IOW, is 300usecs going to work at lower OPPs also?
>>>
>>Could I request for 2 options:
>>a) workaround with no delay (manual save restore) - power savings for
>>boards which dont use the pin
>>b) workaround with 300uSec - for boards which use the pin ->functional
How do we find out if the pin is functional or not? 
>>
>>Also please have a check based on CPU revision and add errata number?
I do not think this is yet published as an errata.
>>
>>--
>>Regards,
>>Nishanth Menon

Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430

[Nishanth Menon]

Gopinath, Thara had written, on 10/06/2009 10:23 AM, the following:
> 
>>> -----Original Message-----
>>> From: Menon, Nishanth
>>> Sent: Tuesday, October 06, 2009 8:48 PM
>>> To: Kevin Hilman
>>> Cc: Gopinath, Thara; linux-omap@vger.kernel.org; Gulati, Shweta
>>> Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
>>>
>>> Kevin Hilman had written, on 10/06/2009 10:05 AM, the following:
>>>> "Gopinath, Thara" <thara@ti.com> writes:
>>>>
>>>>> Will repost the patch with the defconfig option added. So that this can be disabled if not needed.
>>>> ok, please update the changelog as well as describe the 300usec value
>>>> in terms of cycles.  IOW, is 300usecs going to work at lower OPPs also?
>>>>
>>> Could I request for 2 options:
>>> a) workaround with no delay (manual save restore) - power savings for
>>> boards which dont use the pin
>>> b) workaround with 300uSec - for boards which use the pin ->functional
> How do we find out if the pin is functional or not? 
I thought you are adding Kconfig option. leave it to the board defconfig 
to decide?

>>> Also please have a check based on CPU revision and add errata number?
> I do not think this is yet published as an errata.
could we atleast mark it as an
/* ERRATA YET TO BE NUMBERED... */
blah blah

-- 
Regards,
Nishanth Menon

[PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430

[y]

From: Shweta Gulati <shweta.gulati@ti.com>

Signed-off-by: Shweta Gulati <shweta.gulati@ti.com>
---
 arch/arm/mach-omap2/pm34xx.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index a9eda25..38f4781 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -140,6 +140,12 @@ static void omap3_core_save_context(void)
 	omap_ctrl_readl(OMAP343X_CONTROL_PADCONF_OFF);
 	control_padconf_off |= START_PADCONF_SAVE;
 	omap_ctrl_writel(control_padconf_off, OMAP343X_CONTROL_PADCONF_OFF);
+	/* Due to Silicon Bug on context restore it is found
+	 * that the CONTROL_PAD_CONF_ETK14 register is not saved into
+	 * scratch pad memory sometimes. To rectify it delay acess by Mpu
+	 * for 300us for scm to finish saving task
+	 */
+	udelay(300);
 	/* wait for the save to complete */
 	while (!omap_ctrl_readl(OMAP343X_CONTROL_GENERAL_PURPOSE_STATUS)
 			& PADCONF_SAVE_DONE)
-- 
1.5.4.7