Re: [PATCHv3 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support

[Nishanth Menon <nm@ti.com>]

On 08/08/2013 11:06 AM, Dave Gerlach wrote:
> On 08/08/2013 10:03 AM, Santosh Shilimkar wrote:
>> $subject and patch don't match.
>>
>> On Thursday 08 August 2013 08:26 AM, Nishanth Menon wrote:
>>> On 08/08/2013 03:45 AM, Russ Dill wrote:
>>>>    In reference to
>>>> the M3 handling it, the M3 wouldn't know which devices have a driver
>>>> bound and which don't.
>>> Does it need to? M3 firmware can pretty much define "I will force the
>>> device into low power state, and if the drivers dont handle things
>>> properly, fix the darned driver". M3 behavior should be considered as
>>> a "hardware" as far as Linux running on MPU is concerned, and
>>> firmware helps change the behavior by accounting for SoC quirks. *if*
>>> we have ability to handle this in the firmware, there is no need to
>>> carry this in Linux.
>>>
>> I agree with Nishant. I don't like this patch and IIRC, I gave same
>> comment in the last version. Linux need not know about all such firmware
>> quirks. Also all these M3 specific stuff, should be done somewhere
>> else. Probably having a small M3 driver won't be a bad idea.
>>
>> Regards,
>> Santosh
>>
>
> I am not opposed to doing it this way and letting the M3 firmware handle
> idling these modules, however the one concern raised in the last series
> is that an approach that does not acknowledge drivers will hide driver
> PM bugs. I suppose as long as I make sure to document that the devices
> are being idled by the M3 firmware this may not be an issue. I will look
> into implementing this.

yes, but doing it in M3 will ensure it is a "hardware behavior" - from 
debug perspective, you could make M3 firmware "release mode" - which it 
is stringent in terms of forcing all down to target state, OR "debug" 
where it does nothing - thus helping pick up driver bugs. With M3 in the 
picture, we now have an awesome flexibility of "defining what the 
hardware behavior should be" - that allows us to have lesser code to 
carry in kernel- especially ones(like quirks) that does not really add 
value from power saving strategies.

-- 
Regards,
Nishanth Menon