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