Message ID | 20200511111912.3001-1-lukasz.luba@arm.com (mailing list archive) |
---|---|
Headers | show |
Series | Add support for devices in the Energy Model | expand |
Hi Lukasz, On 11/05/2020 13:18, Lukasz Luba wrote: > Hi all, > > This patch set introduces support for devices in the Energy Model (EM) > framework. It will unify the power model for thermal subsystem. It will > make simpler to add support for new devices willing to use more > advanced features (like Intelligent Power Allocation). Now it should > require less knowledge and effort for driver developer to add e.g. > GPU driver with simple energy model. A more sophisticated energy model > in the thermal framework is also possible, driver needs to provide > a dedicated callback function. More information can be found in the > updated documentation file. > > First 7 patches are refactoring Energy Model framework to add support > of other devices that CPUs. They change: > - naming convention from 'capacity' to 'performance' state, > - API arguments adding device pointer and not rely only on cpumask, > - change naming when 'cpu' was used, now it's a 'device' > - internal structure to maintain registered devices > - update users to the new API > Patch 8 updates OPP framework helper function to be more generic, not > CPU specific. > Patches 9-14 change devfreq cooling, dropping part of old power model and > adding registration with Energy Model via exported GPL function. > The last path is a simple change for Panfrost GPU driver. > > The patch set is based on linux-next tag next-20200508. Do you think it is possible to respin against linux-pm next ? I wanted to try the series but I'm getting non trivial conflicts with the devfreq_cooling changes
Hi Daniel, On 5/22/20 11:43 AM, Daniel Lezcano wrote: > > Hi Lukasz, > > On 11/05/2020 13:18, Lukasz Luba wrote: >> Hi all, >> >> This patch set introduces support for devices in the Energy Model (EM) >> framework. It will unify the power model for thermal subsystem. It will >> make simpler to add support for new devices willing to use more >> advanced features (like Intelligent Power Allocation). Now it should >> require less knowledge and effort for driver developer to add e.g. >> GPU driver with simple energy model. A more sophisticated energy model >> in the thermal framework is also possible, driver needs to provide >> a dedicated callback function. More information can be found in the >> updated documentation file. >> >> First 7 patches are refactoring Energy Model framework to add support >> of other devices that CPUs. They change: >> - naming convention from 'capacity' to 'performance' state, >> - API arguments adding device pointer and not rely only on cpumask, >> - change naming when 'cpu' was used, now it's a 'device' >> - internal structure to maintain registered devices >> - update users to the new API >> Patch 8 updates OPP framework helper function to be more generic, not >> CPU specific. >> Patches 9-14 change devfreq cooling, dropping part of old power model and >> adding registration with Energy Model via exported GPL function. >> The last path is a simple change for Panfrost GPU driver. >> >> The patch set is based on linux-next tag next-20200508. > > Do you think it is possible to respin against linux-pm next ? Yes, I will do it and send the v8. > > I wanted to try the series but I'm getting non trivial conflicts with > the devfreq_cooling changes > > Let me take care of this. Regards, Lukasz
On 22/05/2020 14:58, Lukasz Luba wrote: [ ... ] >>> >>> The patch set is based on linux-next tag next-20200508. >> >> Do you think it is possible to respin against linux-pm next ? > > Yes, I will do it and send the v8. > >> >> I wanted to try the series but I'm getting non trivial conflicts with >> the devfreq_cooling changes >> >> > > Let me take care of this. Thanks Lukasz !