On Fri, Feb 8, 2019 at 11:42 AM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > On Fri, Feb 8, 2019 at 11:31 AM Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: > > > > On 08-02-19, 11:22, Rafael J. Wysocki wrote: > > > There are cpufreq driver suspend and resume callbacks, maybe use them? > > > > > > The driver could do the I2C transactions in its suspend/resume > > > callbacks and do nothing in online/offline if those are part of > > > system-wide suspend/resume. > > > > These are per-policy things that we need to do, not sure if driver > > suspend/resume is a good place for that. It is more for a case where > > CPU 0-3 are in one policy and 4-7 in another. Now 1-7 are > > hot-unplugged during system suspend and hotplugged later on. This is > > more like complete removal/addition of devices instead of > > suspend/resume. > > No, it isn't. We don't remove devices on offline. We migrate stuff > away from them and (opportunistically) power them down. > > If this is system suspend, the driver kind of knows that offline will > take place, so it can prepare for it. Likewise, when online takes > place during system-wide resume, it generally is known that this is > system-wide resume (there is a flag to indicate that in CPU hotplug), > it can be "smart" and avoid accessing suspended devices. Deferring > the frequency set up until the driver resume time should do the trick > I suppose. BTW, do transitions to idle states involve I2C transactions on the systems in question?
