| Message ID | cover.1565089196.git.leonard.crestez@nxp.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | opp: Parse required-opp as dev_pm_qos_request | expand |
On 06-08-19, 14:12, Leonard Crestez wrote: > The "required-opps" property can be placed on any device and point to > any OPP table according to bindings doc but this is not fully > implemented. In practice it can only point from the opp table of a > device to the opp table of a power domain. > > As part of my investingating QOS mechanisms I implemented support for > parsing "required-opps" into a DEV_PM_QOS_MIN_FREQUENCY > dev_pm_qos_request. Since OPPs can be shared between devices this only > works when OPP tables are unshared. > > This would need to be called from a device probe function and any > suspend/resume handling (which likely means disabling the QOS requests) > would also be handled manually by each driver. > > This is RFC mostly because I plan to use the "interconnect" framework > for device requests instead. In theory this could be used if you don't > care about implementing smart aggregation and just want to "set bus freq > to high". > > Devfreq support for dev_pm_qos is here: https://patchwork.kernel.org/patch/11078475/ Some work is going on in related field. Please have a look at this as well. https://lore.kernel.org/lkml/20190724014222.110767-1-saravanak@google.com
On 20.08.2019 09:52, Viresh Kumar wrote: > On 06-08-19, 14:12, Leonard Crestez wrote: >> The "required-opps" property can be placed on any device and point to >> any OPP table according to bindings doc but this is not fully >> implemented. In practice it can only point from the opp table of a >> device to the opp table of a power domain. >> >> As part of my investingating QOS mechanisms I implemented support for >> parsing "required-opps" into a DEV_PM_QOS_MIN_FREQUENCY >> dev_pm_qos_request. Since OPPs can be shared between devices this only >> works when OPP tables are unshared. >> >> This would need to be called from a device probe function and any >> suspend/resume handling (which likely means disabling the QOS requests) >> would also be handled manually by each driver. >> >> This is RFC mostly because I plan to use the "interconnect" framework >> for device requests instead. In theory this could be used if you don't >> care about implementing smart aggregation and just want to "set bus freq >> to high". >> >> Devfreq support for dev_pm_qos is here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fpatch%2F11078475%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7C09dabcdb17434862317508d7253aeac8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637018807295295723&sdata=vXvTIowhuqDkTxVZMHq%2BQxrKuqYv7n%2FU01ZDA7fdB0c%3D&reserved=0 > > Some work is going on in related field. Please have a look at this as well. I noticed that series but other than touching "required-opp" there is little in common. It seems to be mostly an expansion of the passive governor. My series doesn't even depend on devfreq; in theory you could even use required-opp = <&opp_1200mhz> on a cpu device. -- Regards, Leonard
On 20-08-19, 09:02, Leonard Crestez wrote: > On 20.08.2019 09:52, Viresh Kumar wrote: > > On 06-08-19, 14:12, Leonard Crestez wrote: > >> The "required-opps" property can be placed on any device and point to > >> any OPP table according to bindings doc but this is not fully > >> implemented. In practice it can only point from the opp table of a > >> device to the opp table of a power domain. > >> > >> As part of my investingating QOS mechanisms I implemented support for > >> parsing "required-opps" into a DEV_PM_QOS_MIN_FREQUENCY > >> dev_pm_qos_request. Since OPPs can be shared between devices this only > >> works when OPP tables are unshared. > >> > >> This would need to be called from a device probe function and any > >> suspend/resume handling (which likely means disabling the QOS requests) > >> would also be handled manually by each driver. > >> > >> This is RFC mostly because I plan to use the "interconnect" framework > >> for device requests instead. In theory this could be used if you don't > >> care about implementing smart aggregation and just want to "set bus freq > >> to high". > >> > >> Devfreq support for dev_pm_qos is here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fpatch%2F11078475%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7C09dabcdb17434862317508d7253aeac8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637018807295295723&sdata=vXvTIowhuqDkTxVZMHq%2BQxrKuqYv7n%2FU01ZDA7fdB0c%3D&reserved=0 > > > > Some work is going on in related field. Please have a look at this as well. > > I noticed that series but other than touching "required-opp" there is > little in common. It seems to be mostly an expansion of the passive > governor. > > My series doesn't even depend on devfreq; in theory you could even use > required-opp = <&opp_1200mhz> on a cpu device. What is the exact use case you are targeting here or the problem you are trying to solve ?
On 20.08.2019 12:22, Viresh Kumar wrote: > On 20-08-19, 09:02, Leonard Crestez wrote: >> On 20.08.2019 09:52, Viresh Kumar wrote: >>> On 06-08-19, 14:12, Leonard Crestez wrote: >>>> The "required-opps" property can be placed on any device and point to >>>> any OPP table according to bindings doc but this is not fully >>>> implemented. In practice it can only point from the opp table of a >>>> device to the opp table of a power domain. >>>> >>>> As part of my investingating QOS mechanisms I implemented support for >>>> parsing "required-opps" into a DEV_PM_QOS_MIN_FREQUENCY >>>> dev_pm_qos_request. Since OPPs can be shared between devices this only >>>> works when OPP tables are unshared. >>>> >>>> This would need to be called from a device probe function and any >>>> suspend/resume handling (which likely means disabling the QOS requests) >>>> would also be handled manually by each driver. >>>> >>>> This is RFC mostly because I plan to use the "interconnect" framework >>>> for device requests instead. In theory this could be used if you don't >>>> care about implementing smart aggregation and just want to "set bus freq >>>> to high". >>>> >>>> Devfreq support for dev_pm_qos is here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fpatch%2F11078475%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7C9ff357888cba49c522ce08d7254fe2c4%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637018897344276009&sdata=NV2Xnop9%2BplnKdIqrMCHF05xpt9y651ed%2BhwFK8gEKI%3D&reserved=0 >>> >>> Some work is going on in related field. Please have a look at this as well. >> >> I noticed that series but other than touching "required-opp" there is >> little in common. It seems to be mostly an expansion of the passive >> governor. >> >> My series doesn't even depend on devfreq; in theory you could even use >> required-opp = <&opp_1200mhz> on a cpu device. > > What is the exact use case you are targeting here or the problem you are trying > to solve ? My exact use case is that devices (such as display, gpu, audio etc) need DRAM to run at a minimum frequency. This is currently done in imx vendor tree with a custom API but I'm trying to upstream via devfreq: https://patchwork.kernel.org/cover/11104113/ The "required-opp" documentation looked like it would be a fit but apparently it requires all requesting devices to have OPPs and the target to be a power domain? This seemed very restrictive so this series implements a different way to handle required-opp, via dev_pm_qos. The interconnect subsystem has additional capabilities (scaling along a path) so I plan to use that instead. You can treat this series as a "curiosity". -- Regards, Leonard
On 20-08-19, 15:48, Leonard Crestez wrote: > The interconnect subsystem has additional capabilities (scaling along a > path) so I plan to use that instead. You can treat this series as a > "curiosity". So I can just ignore it ;)