BUG: no cpufreq on gta04 (omap dm3730) in 5.2-rc4

BUG: no cpufreq on gta04 (omap dm3730) in 5.2-rc4

[Andreas Kemnade]

[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]

Hi,

On the gta04 (dm3730 cpu), cpufreq does not work properly with above-mentioned
kernel.
cpufreq-info just shows
analyzing CPU 0:
  no or unknown cpufreq driver is active on this CPU
  maximum transition latency: 0.00 ms.

dmesg log shows these interesting lines.

[    3.140655] core: _opp_supported_by_regulators: OPP minuV: 1012500 maxuV: 1012500, not supported by regulator
[    3.152709] cpu cpu0: _opp_add: OPP not supported by regulators (300000000)
[    3.160278] core: _opp_supported_by_regulators: OPP minuV: 1200000 maxuV: 1200000, not supported by regulator
[    3.171142] cpu cpu0: _opp_add: OPP not supported by regulators (600000000)
[    3.178710] core: _opp_supported_by_regulators: OPP minuV: 1325000 maxuV: 1325000, not supported by regulator
[    3.189483] cpu cpu0: _opp_add: OPP not supported by regulators
(800000000)

looking through logs shows that these lines first appeared in
next-20190506. They were not present in next-20190503. If I understand that
correcly it is about vdd1.
Analysis reveals:

in
int regulator_is_supported_voltage(struct regulator *regulator,
                                   int min_uV, int max_uV)

the following if fails:
     /* Any voltage within constrains range is fine? */
        if (rdev->desc->continuous_voltage_range) {

The following hack did the trick

diff --git a/drivers/regulator/twl-regulator.c b/drivers/regulator/twl-regulator.c
index 6fa15b2d6fb3..f7bfdf53701d 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -478,6 +478,7 @@ static const struct twlreg_info TWL4030_INFO_##label = { \
 		.type = REGULATOR_VOLTAGE, \
 		.owner = THIS_MODULE, \
 		.enable_time = turnon_delay, \
+		.continuous_voltage_range = true, \
 		.of_map_mode = twl4030reg_map_mode, \
 		}, \
 	}


not sure whether it is correct, whether these things are continuous enough.
If that all is ok, I will of course submit a formal patch.

Regards
Andreas

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]