<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/devfreq/event, branch v6.12.80</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>PM / devfreq: rockchip-dfi: double count on RK3588</title>
<updated>2025-10-15T09:59:59+00:00</updated>
<author>
<name>Nicolas Frattaroli</name>
<email>nicolas.frattaroli@collabora.com</email>
</author>
<published>2025-05-30T13:38:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=f7344709705ca0fa565c69e6ae1d464e03a64ca1'/>
<id>f7344709705ca0fa565c69e6ae1d464e03a64ca1</id>
<content type='text'>
[ Upstream commit f89c7fb83ae95578e355bed1a7aeea5f3ca5a067 ]

On RK3588 with LPDDR4X memory, the cycle count as returned by

  perf stat -a -e rockchip_ddr/cycles/ sleep 1

consistently reads half as much as what the actual DDR frequency is at.
For a LPDDR4X module running at 2112MHz, I get more like 1056059916
cycles per second, which is almost bang-on half what it should be. No,
I'm not mixing up megatransfers and megahertz.

Consulting the downstream driver, this appears to be because the RK3588
hardware specifically (and RK3528 as well, for future reference) needs a
multiplier of 2 to get to the correct frequency with everything but
LPDDR5.

The RK3588's actual memory bandwidth measurements in MB/s are correct
however, as confirmed with stress-ng --stream. This makes me think the
access counters are not affected in the same way. This tracks with the
vendor kernel not multiplying the access counts either.

Solve this by adding a new member to the dfi struct, which each SoC can
set to whatever they want, but defaults to 1 if left unset by the SoC
init functions. The event_get_count op can then use this multiplier if
the cycle count is requested.

The cycle multiplier is not used in rockchip_dfi_get_event because the
vendor driver doesn't use it there either, and we don't do other actual
bandwidth unit conversion stuff in there anyway.

Fixes: 481d97ba61e1 ("PM / devfreq: rockchip-dfi: add support for RK3588")
Signed-off-by: Nicolas Frattaroli &lt;nicolas.frattaroli@collabora.com&gt;
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Link: https://lore.kernel.org/lkml/20250530-rk3588-dfi-improvements-v1-1-6e077c243a95@collabora.com/
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit f89c7fb83ae95578e355bed1a7aeea5f3ca5a067 ]

On RK3588 with LPDDR4X memory, the cycle count as returned by

  perf stat -a -e rockchip_ddr/cycles/ sleep 1

consistently reads half as much as what the actual DDR frequency is at.
For a LPDDR4X module running at 2112MHz, I get more like 1056059916
cycles per second, which is almost bang-on half what it should be. No,
I'm not mixing up megatransfers and megahertz.

Consulting the downstream driver, this appears to be because the RK3588
hardware specifically (and RK3528 as well, for future reference) needs a
multiplier of 2 to get to the correct frequency with everything but
LPDDR5.

The RK3588's actual memory bandwidth measurements in MB/s are correct
however, as confirmed with stress-ng --stream. This makes me think the
access counters are not affected in the same way. This tracks with the
vendor kernel not multiplying the access counts either.

Solve this by adding a new member to the dfi struct, which each SoC can
set to whatever they want, but defaults to 1 if left unset by the SoC
init functions. The event_get_count op can then use this multiplier if
the cycle count is requested.

The cycle multiplier is not used in rockchip_dfi_get_event because the
vendor driver doesn't use it there either, and we don't do other actual
bandwidth unit conversion stuff in there anyway.

Fixes: 481d97ba61e1 ("PM / devfreq: rockchip-dfi: add support for RK3588")
Signed-off-by: Nicolas Frattaroli &lt;nicolas.frattaroli@collabora.com&gt;
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Link: https://lore.kernel.org/lkml/20250530-rk3588-dfi-improvements-v1-1-6e077c243a95@collabora.com/
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PM / devfreq: exynos-ppmu: Convert to platform remove callback returning void</title>
<updated>2024-05-08T14:53:08+00:00</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@pengutronix.de</email>
</author>
<published>2024-03-04T21:28:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=177e15dfbcaa5b3944f4586e6d42e96920b81db9'/>
<id>177e15dfbcaa5b3944f4586e6d42e96920b81db9</id>
<content type='text'>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PM / devfreq: exynos-nocp: Convert to platform remove callback returning void</title>
<updated>2024-05-08T14:53:08+00:00</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@pengutronix.de</email>
</author>
<published>2024-03-04T21:28:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=45d8b572fac3aa8b49d53c946b3685eaf78a2824'/>
<id>45d8b572fac3aa8b49d53c946b3685eaf78a2824</id>
<content type='text'>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PM / devfreq: rockchip-dfi: add support for RK3588</title>
<updated>2023-10-19T12:21:16+00:00</updated>
<author>
<name>Sascha Hauer</name>
<email>s.hauer@pengutronix.de</email>
</author>
<published>2023-10-18T06:17:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=481d97ba61e12f34acc59b6632de1aed7c93b824'/>
<id>481d97ba61e12f34acc59b6632de1aed7c93b824</id>
<content type='text'>
Add support for the RK3588 to the driver. The RK3588 has four DDR
channels with a register stride of 0x4000 between the channel
registers, also it has a DDRMON_CTRL register per channel.

Link: https://lore.kernel.org/all/20231018061714.3553817-20-s.hauer@pengutronix.de/
Reviewed-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Reviewed-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Acked-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Acked-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Signed-off-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add support for the RK3588 to the driver. The RK3588 has four DDR
channels with a register stride of 0x4000 between the channel
registers, also it has a DDRMON_CTRL register per channel.

Link: https://lore.kernel.org/all/20231018061714.3553817-20-s.hauer@pengutronix.de/
Reviewed-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Reviewed-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Acked-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Acked-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Signed-off-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PM / devfreq: rockchip-dfi: account for multiple DDRMON_CTRL registers</title>
<updated>2023-10-19T12:17:42+00:00</updated>
<author>
<name>Sascha Hauer</name>
<email>s.hauer@pengutronix.de</email>
</author>
<published>2023-10-18T06:17:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=bbe7cbd07406b75ec845eb261f25373bf88b276a'/>
<id>bbe7cbd07406b75ec845eb261f25373bf88b276a</id>
<content type='text'>
The currently supported RK3399 has a set of registers per channel, but
it has only a single DDRMON_CTRL register. With upcoming RK3588 this
will be different, the RK3588 has a DDRMON_CTRL register per channel.

Instead of expecting a single DDRMON_CTRL register, loop over the
channels and write the channel specific DDRMON_CTRL register. Break
out early out of the loop when there is only a single DDRMON_CTRL
register like on the RK3399.

Link: https://lore.kernel.org/all/20231018061714.3553817-19-s.hauer@pengutronix.de/
Reviewed-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Reviewed-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Signed-off-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The currently supported RK3399 has a set of registers per channel, but
it has only a single DDRMON_CTRL register. With upcoming RK3588 this
will be different, the RK3588 has a DDRMON_CTRL register per channel.

Instead of expecting a single DDRMON_CTRL register, loop over the
channels and write the channel specific DDRMON_CTRL register. Break
out early out of the loop when there is only a single DDRMON_CTRL
register like on the RK3399.

Link: https://lore.kernel.org/all/20231018061714.3553817-19-s.hauer@pengutronix.de/
Reviewed-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Reviewed-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Signed-off-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PM / devfreq: rockchip-dfi: make register stride SoC specific</title>
<updated>2023-10-19T12:17:10+00:00</updated>
<author>
<name>Sascha Hauer</name>
<email>s.hauer@pengutronix.de</email>
</author>
<published>2023-10-18T06:17:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=d1d0b3fe95d888f1ae82a0cf6a594fa0c3cbfa79'/>
<id>d1d0b3fe95d888f1ae82a0cf6a594fa0c3cbfa79</id>
<content type='text'>
The currently supported RK3399 has a stride of 20 between the channel
specific registers. Upcoming RK3588 has a different stride, so put
the stride into driver data to make it configurable.
While at it convert decimal 20 to hex 0x14 for consistency with RK3588
which has a register stride 0x4000 and we want to write that in hex
as well.

Link: https://lore.kernel.org/all/20231018061714.3553817-18-s.hauer@pengutronix.de/
Reviewed-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Reviewed-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Signed-off-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The currently supported RK3399 has a stride of 20 between the channel
specific registers. Upcoming RK3588 has a different stride, so put
the stride into driver data to make it configurable.
While at it convert decimal 20 to hex 0x14 for consistency with RK3588
which has a register stride 0x4000 and we want to write that in hex
as well.

Link: https://lore.kernel.org/all/20231018061714.3553817-18-s.hauer@pengutronix.de/
Reviewed-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Reviewed-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Signed-off-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PM / devfreq: rockchip-dfi: Add perf support</title>
<updated>2023-10-19T12:13:28+00:00</updated>
<author>
<name>Sascha Hauer</name>
<email>s.hauer@pengutronix.de</email>
</author>
<published>2023-10-19T06:48:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=4d586b5724d3233a73603000de7b8a035b493138'/>
<id>4d586b5724d3233a73603000de7b8a035b493138</id>
<content type='text'>
The DFI is a unit which is suitable for measuring DDR utilization, but
so far it could only be used as an event driver for the DDR frequency
scaling driver. This adds perf support to the DFI driver.

Usage with the 'perf' tool can look like:

perf stat -a -e rockchip_ddr/cycles/,\
		rockchip_ddr/read-bytes/,\
		rockchip_ddr/write-bytes/,\
		rockchip_ddr/bytes/ sleep 1

 Performance counter stats for 'system wide':

        1582524826      rockchip_ddr/cycles/
           1802.25 MB   rockchip_ddr/read-bytes/
           1793.72 MB   rockchip_ddr/write-bytes/
           3595.90 MB   rockchip_ddr/bytes/

       1.014369709 seconds time elapsed

perf support has been tested on a RK3568 and a RK3399, the latter with
dual channel DDR.

Link: https://lore.kernel.org/all/20231019064819.3496740-1-s.hauer@pengutronix.de/
Reviewed-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Acked-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Acked-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Signed-off-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
[cw00.choi: Fix typo from 'write_acccess' to 'write_access']
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The DFI is a unit which is suitable for measuring DDR utilization, but
so far it could only be used as an event driver for the DDR frequency
scaling driver. This adds perf support to the DFI driver.

Usage with the 'perf' tool can look like:

perf stat -a -e rockchip_ddr/cycles/,\
		rockchip_ddr/read-bytes/,\
		rockchip_ddr/write-bytes/,\
		rockchip_ddr/bytes/ sleep 1

 Performance counter stats for 'system wide':

        1582524826      rockchip_ddr/cycles/
           1802.25 MB   rockchip_ddr/read-bytes/
           1793.72 MB   rockchip_ddr/write-bytes/
           3595.90 MB   rockchip_ddr/bytes/

       1.014369709 seconds time elapsed

perf support has been tested on a RK3568 and a RK3399, the latter with
dual channel DDR.

Link: https://lore.kernel.org/all/20231019064819.3496740-1-s.hauer@pengutronix.de/
Reviewed-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Acked-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Acked-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Signed-off-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
[cw00.choi: Fix typo from 'write_acccess' to 'write_access']
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PM / devfreq: rockchip-dfi: give variable a better name</title>
<updated>2023-10-19T11:58:34+00:00</updated>
<author>
<name>Sascha Hauer</name>
<email>s.hauer@pengutronix.de</email>
</author>
<published>2023-10-18T06:17:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=2785cc00f6fa4e5ebd0927679ade6df367ac1f24'/>
<id>2785cc00f6fa4e5ebd0927679ade6df367ac1f24</id>
<content type='text'>
struct dmc_count_channel::total counts the clock cycles of the DDR
controller. Rename it accordingly to give the reader a better idea
what this is about. While at it, at some documentation to struct
dmc_count_channel.

Link: https://lore.kernel.org/all/20231018061714.3553817-16-s.hauer@pengutronix.de/
Reviewed-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Acked-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Signed-off-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
struct dmc_count_channel::total counts the clock cycles of the DDR
controller. Rename it accordingly to give the reader a better idea
what this is about. While at it, at some documentation to struct
dmc_count_channel.

Link: https://lore.kernel.org/all/20231018061714.3553817-16-s.hauer@pengutronix.de/
Reviewed-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Acked-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Signed-off-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PM / devfreq: rockchip-dfi: Prepare for multiple users</title>
<updated>2023-10-19T11:50:10+00:00</updated>
<author>
<name>Sascha Hauer</name>
<email>s.hauer@pengutronix.de</email>
</author>
<published>2023-10-18T06:17:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=d724f4a4581b2910ce79b45bd353ee66e7cf9d7f'/>
<id>d724f4a4581b2910ce79b45bd353ee66e7cf9d7f</id>
<content type='text'>
When adding perf support later the DFI must be enabled when
either of devfreq-event or perf is active. Prepare for that
by adding a usage counter for the DFI. Also move enabling
and disabling of the clock away from the devfreq-event specific
functions to which the perf specific part won't have access.

Link: https://lore.kernel.org/all/20231018061714.3553817-15-s.hauer@pengutronix.de/
Reviewed-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Reviewed-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Acked-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Signed-off-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When adding perf support later the DFI must be enabled when
either of devfreq-event or perf is active. Prepare for that
by adding a usage counter for the DFI. Also move enabling
and disabling of the clock away from the devfreq-event specific
functions to which the perf specific part won't have access.

Link: https://lore.kernel.org/all/20231018061714.3553817-15-s.hauer@pengutronix.de/
Reviewed-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Reviewed-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Acked-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Signed-off-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PM / devfreq: rockchip-dfi: Pass private data struct to internal functions</title>
<updated>2023-10-19T11:49:19+00:00</updated>
<author>
<name>Sascha Hauer</name>
<email>s.hauer@pengutronix.de</email>
</author>
<published>2023-10-18T06:17:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=b82932fbd870b64fd71a999f9b61fbdcf2924ee6'/>
<id>b82932fbd870b64fd71a999f9b61fbdcf2924ee6</id>
<content type='text'>
The internal functions do not need the struct devfreq_event_dev *,
so pass them the struct rockchip_dfi *. This is a preparation for
adding perf support later which doesn't have a struct devfreq_event_dev *.

Link: https://lore.kernel.org/all/20231018061714.3553817-14-s.hauer@pengutronix.de/
Reviewed-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Reviewed-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Acked-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Signed-off-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The internal functions do not need the struct devfreq_event_dev *,
so pass them the struct rockchip_dfi *. This is a preparation for
adding perf support later which doesn't have a struct devfreq_event_dev *.

Link: https://lore.kernel.org/all/20231018061714.3553817-14-s.hauer@pengutronix.de/
Reviewed-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Reviewed-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Acked-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Signed-off-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
