kernel/drivers/devfreq/tegra-devfreq.c, branch linux-rolling-stable

PM / devfreq: tegra: Rename tegra-devfreq.c to tegra30-devfreq.c

2019-08-24T11:11:12Z

In order to reflect that driver serves NVIDIA Tegra30 and later SoC generations, let's rename the driver's source file to "tegra30-devfreq.c". This will make driver files to look more consistent after addition of a driver for Tegra20. Reviewed-by: Chanwoo Choi Signed-off-by: Dmitry Osipenko Signed-off-by: MyungJoo Ham

PM / devfreq: tegra: Support Tegra30

2019-08-24T11:11:12Z

The devfreq driver can be used on Tegra30 without any code change and it works perfectly fine, the default Tegra124 parameters are good enough for Tegra30. Signed-off-by: Dmitry Osipenko Reviewed-by: Chanwoo Choi [Modified by MyungJoo to depends on Tegra30/114/124/210 only] Signed-off-by: MyungJoo Ham

PM / devfreq: tegra: Reconfigure hardware on governor's restart

2019-08-24T11:11:12Z

Move hardware configuration to governor's start/resume methods. This allows to re-initialize hardware counters and reconfigure cleanly if governor was stopped/paused. That is needed because we are not aware of all hardware changes that happened while governor was stopped and the paused state may get out of sync with reality, hence it's better to start with a clean slate after the pause. In a result there is no memory bandwidth starvation after resume from suspend-to-ram that results in display controller underflowing that happens on resume because of improper decision made by devfreq about the required memory frequency. This change also cleans up code a tad by moving hardware-configuration code into a single location. Reviewed-by: Chanwoo Choi Signed-off-by: Dmitry Osipenko Acked-by: Thierry Reding Signed-off-by: MyungJoo Ham

PM / devfreq: tegra: Move governor registration to driver's probe

2019-08-24T11:11:12Z

There is no need to register the ACTMON's governor separately from the driver, hence let's move the registration into the driver's probe function for consistency and to make code cleaner a tad. Reviewed-by: Chanwoo Choi Signed-off-by: Dmitry Osipenko Acked-by: Thierry Reding Signed-off-by: MyungJoo Ham

PM / devfreq: tegra: Mark ACTMON's governor as immutable

2019-08-24T11:11:12Z

The ACTMON's governor supports only the Tegra's devfreq device and there is no need to use any other governor, hence let's mark Tegra governor as immutable to permanently stick it with Tegra's devfreq device. Reviewed-by: Chanwoo Choi Signed-off-by: Dmitry Osipenko Acked-by: Thierry Reding Signed-off-by: MyungJoo Ham

PM / devfreq: tegra: Avoid inconsistency of current frequency value

2019-08-24T11:11:12Z

The frequency value potentially could change in-between. It doesn't cause any real problem at all right now, but that could change in the future. Hence let's avoid the inconsistency. Reviewed-by: Chanwoo Choi Signed-off-by: Dmitry Osipenko Acked-by: Thierry Reding Signed-off-by: MyungJoo Ham

PM / devfreq: tegra: Clean up driver's probe / remove

2019-08-24T11:11:12Z

Reset hardware, disable ACTMON clock, release OPP's and handle all possible error cases correctly, maintaining the correct tear down order. Also use devm_platform_ioremap_resource() which is now available in the kernel. Reviewed-by: Chanwoo Choi Signed-off-by: Dmitry Osipenko Acked-by: Thierry Reding Signed-off-by: MyungJoo Ham

PM / devfreq: tegra: Properly disable interrupts

2019-08-24T11:11:12Z

There is no guarantee that interrupt handling isn't running in parallel with tegra_actmon_disable_interrupts(), hence it is necessary to protect DEV_CTRL register accesses and clear IRQ status with ACTMON's IRQ being disabled in the Interrupt Controller in order to ensure that device interrupt is indeed being disabled. Reviewed-by: Chanwoo Choi Signed-off-by: Dmitry Osipenko Acked-by: Thierry Reding Signed-off-by: MyungJoo Ham

PM / devfreq: tegra: Drop primary interrupt handler

2019-08-24T11:11:12Z

There is no real need in the primary interrupt handler, hence move everything to the secondary (threaded) handler. In a result locking is consistent now and there are no potential races with the interrupt handler because it is protected with the devfreq's mutex. Reviewed-by: Chanwoo Choi Signed-off-by: Dmitry Osipenko Acked-by: Thierry Reding Signed-off-by: MyungJoo Ham

PM / devfreq: tegra: Don't set EMC clock rate to maximum on probe

2019-08-24T11:11:12Z

There is no real benefit from doing so, hence let's drop that rate setting for consistency. Reviewed-by: Chanwoo Choi Signed-off-by: Dmitry Osipenko Acked-by: Thierry Reding Signed-off-by: MyungJoo Ham