The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/lima/lima_devf
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on rock960.
Signed-off-by: Daniel Lezcano
Reviewed-by: Steven Price
---
drive
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on dragonboard 845c
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/msm/msm_
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/lima/lima_devf
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on rock960.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/dr
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on dragonboard 845c
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/msm/msm_
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/lima/lima_devf
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on rock960.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/dr
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on dragonboard 845c
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/msm/msm_
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/lima/lima_devf
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on rock960.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/dr
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on dragonboard 845c
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/msm/msm_
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on rock960.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/dr
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on dragonboard 845c
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/msm/msm_
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/lima/lima_devf
On 05/03/2021 09:12, Steven Price wrote:
> On 04/03/2021 12:50, Daniel Lezcano wrote:
>> Currently the default behavior is to manually having the devfreq
>> backend to register themselves as a devfreq cooling device.
>>
>> There are no so many and actually it makes
Hi Lukasz,
thanks for commenting this patch,
On 04/03/2021 14:47, Lukasz Luba wrote:
> Hi Daniel,
>
> On 3/4/21 12:50 PM, Daniel Lezcano wrote:
>> Currently the default behavior is to manually having the devfreq
>> backend to register themselves as a devfreq cooling devic
.
Having a devfreq being registered as a cooling device can not mitigate
a thermal zone if it is not bound to this one. Thus, the current
configurations are not impacted by this change.
Signed-off-by: Daniel Lezcano
---
drivers/devfreq/devfreq.c | 8
drivers/gpu/drm
On 04/03/2021 16:06, Chanwoo Choi wrote:
> Hi Daniel,
>
> As Lukasz's comment, actually some devfreq devices like memory bus
> might not affect the thermal critically. In the mainline,
> there are four types devfreq as following:
> 1. GPU
> 2. UFS Storage
> 3. DMC (Memory Controller)
> 4. Memory b
On 21/01/2021 18:04, Lukasz Luba wrote:
> The simple_ondemand devfreq governor uses two thresholds to decide about
> the frequency change: upthreshold, downdifferential. These two tunable
> change the behavior of the governor decision, e.g. how fast to increase
> the frequency or how rapidly limit
On 17/12/2020 20:01, Dmitry Osipenko wrote:
> 17.12.2020 21:28, Daniel Lezcano пишет:
>> On 17/12/2020 19:06, Dmitry Osipenko wrote:
>>> Enable CPU voltage scaling and thermal throttling on Tegra20 Ventana board.
>>>
>>> Signed-off-by: Dmitry Osipenko
&g
On 17/12/2020 21:28, Dmitry Osipenko wrote:
> 17.12.2020 22:36, Daniel Lezcano пишет:
>>>>> + type = "critical";
>>>>> + };
>>>>> + };
>>>>> +
&g
On 17/12/2020 19:06, Dmitry Osipenko wrote:
> Enable CPU voltage scaling and thermal throttling on Tegra20 Ventana board.
>
> Signed-off-by: Dmitry Osipenko
> ---
> arch/arm/boot/dts/tegra20-ventana.dts | 40 ++-
> 1 file changed, 39 insertions(+), 1 deletion(-)
>
> diff
On 17/12/2020 19:06, Dmitry Osipenko wrote:
> Enable CPU voltage scaling and thermal throttling on Tegra30 Cardhu board.
>
> Signed-off-by: Dmitry Osipenko
> ---
Same comments as 47/48
> arch/arm/boot/dts/tegra30-cardhu.dtsi | 61 ++-
> 1 file changed, 60 insertions(+
On 11/12/2020 16:11, Lukasz Luba wrote:
> Hi Daniel,
>
> Do you think it has chance to go to as material for v5.11?
Yes, it is in the thermal/linux-next material ATM.
> On 12/10/20 2:30 PM, Lukasz Luba wrote:
>> Hi all,
>>
>> This patch set is a continuation of my previous work, which aimed
>>
On 18/11/2020 13:03, Lukasz Luba wrote:
> The Energy Model (EM) framework supports devices such as Devfreq. Create
> new registration functions which automatically register EM for the thermal
> devfreq_cooling devices. This patch prepares the code for coming changes
> which are going to replace old
On 03/12/2020 16:38, Lukasz Luba wrote:
>
>
> On 12/3/20 1:09 PM, Daniel Lezcano wrote:
>> On 18/11/2020 13:03, Lukasz Luba wrote:
>>> Devfreq cooling needs to now the correct status of the device in order
>>> to operate. Do not rely on Devfreq last_status which
On 18/11/2020 13:03, Lukasz Luba wrote:
> Devfreq cooling needs to now the correct status of the device in order
> to operate. Do not rely on Devfreq last_status which might be a stale data
> and get more up-to-date values of the load.
>
> Devfreq framework can change the device status in the back
On 18/11/2020 13:03, Lukasz Luba wrote:
> Hi all,
>
> This patch set is a continuation of my previous work, which aimed
> to add Energy Model to all devices. This series is a follow up
> for the patches which got merged to v5.9-rc1. It aims to change
> the thermal devfreq cooling and use the Energ
On 21/09/2020 14:20, Lukasz Luba wrote:
> Devfreq cooling needs to now the correct status of the device in order
> to operate. Do not rely on Devfreq last_status which might be a stale data
> and get more up-to-date values of the load.
>
> Devfreq framework can change the device status in the back
On 27/05/2020 11:58, Lukasz Luba wrote:
> Add support for other devices than CPUs. The registration function
> does not require a valid cpumask pointer and is ready to handle new
> devices. Some of the internal structures has been reorganized in order to
> keep consistent view (like removing per_cp
llback from the
> Energy Model.
>
> Acked-by: Quentin Perret
> Signed-off-by: Lukasz Luba
Acked-by: Daniel Lezcano
[ ... ]
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
&l
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 wit
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
On 24/04/2020 12:02, Lukasz Luba wrote:
> Hi Daniel,
>
> On 4/23/20 6:57 PM, Daniel Lezcano wrote:
>> On Fri, Apr 10, 2020 at 09:42:09AM +0100, Lukasz Luba wrote:
>>> The overhauled Energy Model (EM) framework support also devfreq devices.
>>> The unified API i
On Fri, Apr 10, 2020 at 09:42:07AM +0100, Lukasz Luba wrote:
> The Energy Model framework supports also other devices than CPUs. Update
> related information and add description for the new usage.
>
> Signed-off-by: Lukasz Luba
> ---
Acked-by:
when the new structures and infrastructure will be ready.
>
> Signed-off-by: Lukasz Luba
> ---
Acked-by: Daniel Lezcano
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http
gt; a simple Energy Model, which then might be used by e.g. thermal subsystem.
>
> Signed-off-by: Lukasz Luba
Acked-by: Daniel Lezcano
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Apr 10, 2020 at 09:42:09AM +0100, Lukasz Luba wrote:
> The overhauled Energy Model (EM) framework support also devfreq devices.
> The unified API interface of the EM can be used in the thermal subsystem to
> not duplicate code. The power table now is taken from EM structure and
> there is n
On Fri, Apr 10, 2020 at 09:42:05AM +0100, Lukasz Luba wrote:
> Remove old function em_register_perf_domain which is no longer needed.
> There is em_dev_register_perf_domain that covers old use cases and new as
> well.
>
> Signed-off-by: Lukasz Luba
Acked-by:
mask pointer, which is possible only for CPU devices. Thus, rename it
> and add proper description to warn of potential wrong usage for other
> devices.
>
> Signed-off-by: Lukasz Luba
Acked-by: Daniel Lezcano
___
dri-devel mailing list
dri-dev
On Fri, Apr 10, 2020 at 09:42:04AM +0100, Lukasz Luba wrote:
> Add support for other devices that CPUs. The registration function
> does not require a valid cpumask pointer and is ready to handle new
> devices. Some of the internal structures has been reorganized in order to
> keep consistent view
On 23/04/2020 18:57, Lukasz Luba wrote:
>
>
> On 4/23/20 4:12 PM, Daniel Lezcano wrote:
>> On Fri, Apr 10, 2020 at 09:42:04AM +0100, Lukasz Luba wrote:
>>> Add support for other devices that CPUs. The registration function
>>> does not require a valid cpumask p
ther devices other than CPUs.
>
> Signed-off-by: Lukasz Luba
> ---
Acked-by: Daniel Lezcano
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroo
On Fri, Apr 10, 2020 at 09:42:03AM +0100, Lukasz Luba wrote:
> The Energy Model framework is going to support devices other that CPUs. In
> order to make this happen change the callback function and add pointer to
> a device as an argument.
>
> Update the related users to use new function and new
On 06/04/2020 18:07, Lukasz Luba wrote:
>
>
> On 4/6/20 3:58 PM, Daniel Lezcano wrote:
>>
>> Hi Lukasz,
>>
>>
>> On 06/04/2020 15:29, Lukasz Luba wrote:
>>> Hi Daniel,
>>>
>>> Thank you for the review.
>>>
>>> O
Hi Lukasz,
On 06/04/2020 15:29, Lukasz Luba wrote:
> Hi Daniel,
>
> Thank you for the review.
>
> On 4/3/20 5:05 PM, Daniel Lezcano wrote:
>>
>> Hi Lukasz,
>>
>>
>> On 18/03/2020 12:45, Lukasz Luba wrote:
>>> Add support of other de
Hi Lukasz,
On 18/03/2020 12:45, Lukasz Luba wrote:
> Add support of other devices into the Energy Model framework not only the
> CPUs. Change the interface to be more unified which can handle other
> devices as well.
thanks for taking care of that. Overall I like the changes in this patch
but i
On 03/04/2020 19:18, Matthias Kaehlcke wrote:
> Hi Daniel,
>
> On Fri, Apr 03, 2020 at 06:43:20PM +0200, Daniel Lezcano wrote:
>> On 18/03/2020 12:45, Lukasz Luba wrote:
>>> From: Matthias Kaehlcke
>>>
>>> Now that devfreq supports limiting the frequency
On 18/03/2020 12:45, Lukasz Luba wrote:
> The Energy Model framework supports both: CPUs and devfreq devices. Drop
> the CPU specific interface with cpumask and add struct device. Add also a
> return value. This new interface provides easy way to create a simple
> Energy Model, which then might be
On 18/03/2020 12:45, Lukasz Luba wrote:
> From: Matthias Kaehlcke
>
> Now that devfreq supports limiting the frequency range of a device
> through PM QoS make use of it instead of disabling OPPs that should
> not be used.
>
> The switch from disabling OPPs to PM QoS introduces a subtle behaviora
On 18/03/2020 12:45, Lukasz Luba wrote:
> The overhauled Energy Model (EM) framework support also devfreq devices.
> The unified API interface of the EM can be used in the thermal subsystem to
> not duplicate code. The power table now is taken from EM structure and
> there is no need to maintain ca
on/devicetree/bindings/thermal/brcm,avs-ro-thermal.yaml
> @@ -17,7 +17,7 @@ description: |+
> "brcm,bcm2711-avs-monitor", "syscon", "simple-mfd"
>
>Refer to the the bindings described in
> - Documentation/devicetree/bindings/mfd/sysc
53 matches
Mail list logo
