Kobo Clara: Fails to change CPU frequency

Describe your issue

My Kobo Clara (board revision: 37NB-E60K00+4B0) is unable to change its CPU's frequency and is stuck on the lowest value.

What's the expected behaviour?

The CPU frequency changes in response to the governor, or to requests to manually set the frequency

What's the current behaviour?

The CPU frequency stays locked at the lowest value.

When checkingdmesg there's hundreds of this log:

[83791.375121] DCDC2: unsupportable voltage range: 1175000-1000000uV
[83791.375207] DCDC2: unsupportable voltage range: 1175000-1000000uV
[83791.375257] cpu cpu0: failed to scale vddsoc up: -22
[83791.375298] cpufreq: __target_index: Failed to change cpu frequency: -22

How to reproduce your issue?

What device are you using?

On what postmarketOS version did you encounter the issue?

• edge (master branch)

• v23.12

• v23.06 (supported until 2024-01-18)

• I confirm that the issue still is present after running sudo apk upgrade -a

On what environment did you encounter the issue?

Environments

• GNOME Shell on Mobile
• Phosh
• Plasma Mobile
• Sxmo (Wayland/Sway) Please post the output of sxmo_version.sh
• Other: console

How did you get postmarketOS image?

• from https://images.postmarketos.org
• I built it using pmbootstrap
• It was preinstalled on my device

What's the build date of the image? (in yyyy-mm-dd format)

2024-05-07

Additional information

This revision of the Kobo Clara has a different regulator, and was previously unable to boot, but this was resolved by @akemnade. Issue here

There may be something some other differences with this revision that are causing the frequency scaling to not work?

mentioned in issue #2356 (closed)

By Geoffrey Tearle on 2024-05-08T20:15:21

added device-category::testing type::support labels

@akemnade

By Newbyte on 2024-05-17T14:44:05

Hmm, vendor dtb has cpu voltage override in combination with that pmic otp version.

       cpus {
                cpu0: cpu@0 {
                        operating-points = <    /* Core2_1V3_ARM */
                                /* kHz    uV */
                                996000  1062500
                                792000  1062500
                                396000  1062500
                                198000  975000
                        >;
                        fsl,soc-operating-points = <    /* Core2_1V3_SOC */
                                /* ARM kHz      SOC-PU uV */
                                996000          987500
                                792000          987500
                                396000          987500
                                198000          900000
                        >;
                };

        };

hmm, so how does that make sense

By Andreas Kemnade on 2024-05-17T17:00:17

What is exactly written on the SoC? So we have some ultra low power variant of the 6SLL? I do not find any information about that in 6SLL docs

By Andreas Kemnade on 2024-05-18T21:57:12

Here's what's written on the SOC:

MCIMX6V7DVN10AB
    XAA2119

 TAIW QSAAXGD

By Geoffrey Tearle on 2024-05-18T21:57:12

By Geoffrey Tearle on 2024-05-18T21:58:29

added status::needmoreinfo label

assigned to @akemnade

By Andreas Kemnade on 2024-05-23T06:13:04

removed status::needmoreinfo label

added type::bug label and removed type::support label

mentioned in merge request !5201 (merged)

By Andreas Kemnade on 2024-06-04T14:24:26

copied that snippet from vendor dtb into the 6.9.0 update

By Andreas Kemnade on 2024-06-04T14:26:31

do also something cpu-intensive for testing

By Andreas Kemnade on 2024-06-05T00:18:08

Cheers @akemnade, I'll keep an eye on the PR and test once its in

By Geoffrey Tearle on 2024-06-05T00:18:08

@akemnade That seems to have fixed it! Ran glxgears and was able to see the CPU frequency go to the highest value

By Geoffrey Tearle on 2024-06-05T22:31:46

can you check if you can compress/decompress something, esp. with bzip2?

By Andreas Kemnade on 2024-06-06T08:45:09

closed