Hello again, I've just send a draft for the patch(set) I have in mind. It's still in bad shape and I would appreciate some comments from the guys more versed with the DevFreq subsystem than me. In particular I'm not sure how exactly the various components (exynos-bus, devfreq, devfreq-event, governor) work together. - Tobias MyungJoo Ham wrote: > On Tue, Nov 22, 2016 at 7:15 AM, Tobias Jakobi > <tjakobi@xxxxxxxxxxxxxxxxxxxxx> wrote: >> OK, I don't think this is as easy implementable as MyungJoo implied. >> >> - exynos_bus_suspend() and exynos_bus_resume() are not called during >> shutdown/reboot. > > You don't need them at shutdown/reboot. probe() is going to be called > afterwards anyway. > >> >> - devfreq_suspend_device() and devfreq_resume_device() have to be called >> from driver code. > > Yes. That's the limitation. > > The easiest way is to fix the freq/volt at device driver. > > Unless devfreq manages struct device directly at subsystem, it won't > be easy to manage device's suspend/resume directly. > > > MyungJoo > -- > 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 > -- 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
 |