RE: [PATCH v2] twl4030 reboot workaround

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




>>-----Original Message-----
>>From: Turquette, Mike
>>Sent: Saturday, July 31, 2010 12:09 AM
>>To: Gopinath, Thara
>>Cc: Mike Rapoport; Mikko Rapeli; linux-omap@xxxxxxxxxxxxxxx; sameo@xxxxxxxxxxxxxxx
>>Subject: Re: [PATCH v2] twl4030 reboot workaround
>>
>>Gopinath, Thara wrote:
>>>
>>>>> -----Original Message-----
>>>>> From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of
>>Mike
>>>>> Rapoport
>>>>> Sent: Friday, July 30, 2010 12:41 AM
>>>>> To: Mikko Rapeli
>>>>> Cc: linux-omap@xxxxxxxxxxxxxxx; Turquette, Mike; sameo@xxxxxxxxxxxxxxx
>>>>> Subject: Re: [PATCH v2] twl4030 reboot workaround
>>>>>
>>>>> Hi
>>>>>
>>>>> On Thu, Jul 29, 2010 at 9:41 AM, Mikko Rapeli
>>>>> <ext-mikko.rapeli@xxxxxxxxx> wrote:
>>>>>> From: Mikko Rapeli <ext-mikko.rapeli@xxxxxxxxx>
>>>>>>
>>>>>> 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.

Regards
Thara

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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux