Re: [PATCH v2] twl4030 reboot workaround

[Mike Rapoport <mike@compulab.co.il>]

Gopinath, Thara wrote:
> 
>>> -----Original Message-----
>>> From: Turquette, Mike
>>> Sent: Saturday, July 31, 2010 12:09 AM
>>> To: Gopinath, Thara
>>> Cc: Mike Rapoport; Mikko Rapeli; linux-omap@vger.kernel.org; sameo@linux.intel.com
>>> Subject: Re: [PATCH v2] twl4030 reboot workaround
>>>
>>> Gopinath, Thara wrote:
>>>>>> -----Original Message-----
>>>>>> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of
>>> Mike
>>>>>> Rapoport
>>>>>> Sent: Friday, July 30, 2010 12:41 AM
>>>>>> To: Mikko Rapeli
>>>>>> Cc: linux-omap@vger.kernel.org; Turquette, Mike; sameo@linux.intel.com
>>>>>> Subject: Re: [PATCH v2] twl4030 reboot workaround
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>> On Thu, Jul 29, 2010 at 9:41 AM, Mikko Rapeli
>>>>>> <ext-mikko.rapeli@nokia.com> wrote:
>>>>>>> From: Mikko Rapeli <ext-mikko.rapeli@nokia.com>
>>>>>>>
>>>>>>> Original patch: http://marc.info/?l=linux-omap&m=126522625032441&w=2
>>>>>>>
>>>>>>> "Removes TWL4030 sleep script prior to rebooting, only on OMAP3. This is
>>>>>>> necessary since DPLL3 reset causes SYS_OFFMODE pin to go low, resulting
>>>>>>> in the sleep script being executed on TWL4030. This usually results in
>>>>>>> VDD1 & VDD2 voltage collapse while ROM code is executing, followed by an
>>>>>>> MPU Watch Dog reset or worse, an irrecoverable hang."
>>>>>> I had a similar issue when my system hanged on hard reset when there
>>>>>> was a TWL sleep script installed.
>>>>>> The workaround I've found was to install the sleep script immediately
>>>>>> before entering the suspend state and remove the script on the resume
>>>>>> path.
>>>>>> If you think that such approach is appropriate I can send a patch.
>>>> How do you hit the off state(Vdd's at 0 V) in the idle path then? Or do you do this every
>>>> time in the idle thread also?
>>> I do not think it is appropriate to add/remove the sleep script
>>> before/after every OFF mode case.  The script should be programmed once
>>> and left alone EXCEPT in the case of warm reset.
>>>
>>> If there are other corner cases where SYS_OFFMODE goes low, then we
>>> should cover those with similar fixes to the warm reset fix, but in
>>> general I think the policy should be to leave the scripts alone once
>>> programmed
>>>
>>> Dynamically programming/removing the scripts around OFF transitions
>>> increases software overhead for those transitions even more which is
>>> very undesirable.
> 
> This was exactly my concern. The latency increase due to the dynamic addition and
> removal of sleep scripts around off transitions might not be justifiable. Maybe Mike
> does not want to hit 0V for Vdd's in the idle thread in which case it can be acceptable to
> dynamically add the script in the system suspend path and remove it in the resume path.
> Else I also do not think this approach is acceptable.

I've missed the idle case indeed and I agree that dynamic addition and removal 
of sleep scripts is not an acceptable solution.

> Regards
> Thara
> 
> --
> 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


-- 
Sincerely yours,
Mike.