pxa:spitz_pm.c: commit b6eede11 breaks spitz resume under certain conditions.

[Eric Miao]

On Fri, Oct 19, 2012 at 7:37 PM, Marko Katić <dromede at gmail.com> wrote:
> On Thu, Oct 18, 2012 at 11:28 AM, Marko Katić <dromede at gmail.com> wrote:
>>> Almost there, but I guess we could do this better and less confusing by having
>>> another array, e.g. tosa_gpio18_config[], which is tosa specific, and only
>>> initialize that MFP setting in the tosa path.
>>>
>>>>
>>>> I also looked at the original sharp kernel sources.
>>>> Only tosa used the RDY signal for it's tc6393tx chip, other machines simply
>>>> configured gpio18 as output in their suspend routines.
>>
>>
>> Actually, tosa doesn't use sharpsl_pm. Tosa uses the pda-power framework.
>> I said that only tosa uses the RDY signal to point out that we
>> probably don't need
>> the mfp-config line in postsuspend. That being said, i still think
>> that the array ordering
>> fix is adequate. Maybe later we may remove the mfp-config line from
>> postsuspend when
>> we're absolutely sure it isn't necessary for devices that use spitz_pm.c.
>
> So Eric what do you think, is the simple gpio array reordering patch
> an adequate fix for this bug?

Sorry for late reply. That simple reordering still looks a bit confusing
to me, i.e. the same pin firstly configured as GPIO then RDY. Do we
have a less confusing way to fix this?