On 01/21/2012 10:57 PM, Mark Brown wrote: > On Sat, Jan 21, 2012 at 10:33:44PM +0100, Sylwester Nawrocki wrote: >> On 01/21/2012 10:23 PM, Heiko Stübner wrote: > >>> At least S3C2416/S3C2450 and S3C2412 (i.e. the ARMv5 SoCs) might profit from >>> it, as they also support the idle modes (stop modes) that Mark is targetting >>> with his patches in the long run. > >> It would be much better to enable core runtime PM support on all platforms >> that use particular driver, even though there is no any drivers adapted >> runtime PM on some of them yet. > > It's just a Kconfig switch, the only issue is that users might not turn > it on and for platforms where there's not much driver support they're > more likely to not have done so. Yes, and some simple SoCs might probably never benefit from runtime PM due to their limited power modes. Hence enforcing RUNTIME_PM dependency on some common drivers might not be sane. But it would be ideal not to work around things too much, and reimplement in drivers functionality that involves upper layers. >>> Not sure about the 2410, 2440 and 2443 currently > >> But would just enabling RUNTIME_PM make any harm to those platforms ? > > It really shouldn't cause any issues but it seems better to not push > people towards it too much when there's not much win yet. What I've > been doing with all these patches is leaving any PM that already exists > untouched (in so far as it's not buggy). Where there's nothing already > and it's all new code I've been using a more modern idiom. I hope that > this minimise any impact on existing systems. Sounds good. The idea of enforcing runtime PM seems to be good for /dev/null only.. I noticed recently that you did a nice work correcting broken s3c-fb driver PM code. I've done similar corrections but the patches never left the internal trees due to limited time for this. And there is also a DRM driver for FIMD on Exynos now. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |