Request: Testing of Linux drivers on all laptop models

Framework Laptop 13 Linux
1

Hi,

I wrote and submitted a few Linux drivers for various features exposed by the Embedded Controller on Framework machines.
They are only tested on my Framework 13 AMD and it would be great to get some more test reports.

All patches should apply cleanly on top of current Linux mainline.
If you want to apply all patches at once there will be conflicts but these are trivial to resolve.

All of these patches need to be built as part of a kernel tree build,
they can not be used out-of-tree.

These drivers differ from the one of @dhowett in the following ways:

  • They are not Framework specific and should work on all machines with a
    ChromeOS embedded controller
  • One module per subsystem instead of one big module.
  • The keyboard backlight patch fully reuses an existing driver.
  • The LED driver allows to fully shut off the power LED and also to manage the
    battery LED, including color, automatic EC control can be enabled/disabled.
  • The battery control driver also supports charge behaviour (force discharge, inhibit charge)
  • The hwmon driver has a simpler implementation and also supports temperature readings.
    (It does not yet support fan control but that can be added later, the API provides the feature)

By splitting it up, I hope mainlining will be faster and easier.
Also I guess that the custom Framework APIs will go away at some point as the
upstream CrOS EC APIs provide the same or even more features out of the box.

15 Likes
2

Now that sounds quite useful for battery re-calibration.

1 Like
3

It would be cool if you could limit charge current. IE: no matter what charging source you use, you would be slowly trickle charging.

But @Thomas_Weissschuh this all sounds fantastic! If I have some time, I’ll try them out on my 12th intel FW 13.

1 Like
4

That is indeed the intended usecase.

I think there are some ChromeOS EC commands that implement this.
But I have no clue if they even work on Framework.
And that would require a new Linux userspace API.

What is your usecase for this?

Thanks!

1 Like
5

Controlling heat while charging in embedded applications. (mainboard stacked on top of the battery with a small heatshield in between. Trying to keep temps under 55C for battery longevity, decrease the liklihood of swelling, etc.

6

I’m sorry but I’m not used to reading linux mailing lists, how can I know the status of the patches merging into the kernel? Really interested in all those patches :slight_smile:

7

Basic sensors: v6.11
More sensors: unknown as of now
Keyboard backlight: likely v6.11
LEDs: v6.11
Charge control: Could make v6.11, unsure

5 Likes
8

Since the 6.11 merge window has closed, can we get an update on the status of these?
I am also interested in being notified of future revisions, should there be any.
Thanks!

9

All of them except “More sensors” have been merged for 6.11.

3 Likes
10

Nice. Is “more sensors” scheduled for a later release?

11

I’ll need to spend some more time on it.

12

Hi, wanted to have a spin of the charge control one and just rebooted on a fresh 6.11-rc4. No charge_control_end_threshold sysfs node (had to look up what the expected sysfs entry was, maybe documenting them here would help testers). I’m getting the following in dmesg

[   34.038944] cros_ec_lpcs cros_ec_lpcs.0: loaded with quirks 00000001                                                
[   34.048343] cros_ec_lpcs cros_ec_lpcs.0: Chrome EC device registered                                                
[   34.062606] cros-charge-control cros-charge-control.4.auto: Framework charge control detected, preventing load      
[   34.064840] cros-usbpd-charger cros-usbpd-charger.5.auto: No USB PD charging ports found                            
[   34.071454] cros-usbpd-charger cros-usbpd-charger.5.auto: Unexpected number of charge port count                    
[   34.071504] cros-usbpd-charger cros-usbpd-charger.5.auto: Failing probe (err:0xffffffb9)                            
[   34.071506] cros-usbpd-charger cros-usbpd-charger.5.auto: probe with driver cros-usbpd-charger failed with error -71

That’s on an AMD BIOS 3.05. Any other info you’d like?

EDIT: Thought it’d be related to my blacklisting of ucsi_acpi, but removing it doesn’t change anything.

13

For what it’s worth, I’m getting the same
cros-usbpd-charger cros-usbpd-charger.5.auto error with just plain current 6.10.4, on NixOS (on FW13 AMD 7840u).

The error wasn’t there on 6.9.x, so I assume it’s caused by the EC patches merged into 6.10. I couldn’t find a way to fix it so far.

14

Not really an issue…if I’m understanding the ‘warning’ correctly:
https://lore.kernel.org/lkml/20240406191734.137797-1-superm1@gmail.com/t/

…but appears to be EC incorrectly reporting a feature?
image

15

That’s a great find, @Second_Coming, thanks for posting the reference! My searches did not come across it.

Yes, it looks like the EC reports that feature - 22, if I am not mistaken - as supported, currently:

❯  sudo ectool inventory
EC supported features:
1   : Flash support
2   : Direct Fan power management support
3   : Keyboard backlight support
5   : LED support
7   : Keyboard support
9   : BIOS Port 80h access support
10  : Thermal management support
13  : Host event support
14  : GPIO support
15  : I2C controller support
16  : Charger support
17  : Simple Battery support
18  : Smart Battery support
22  : USB Cros Power Delivery support
25  : Temporary secure vstore support
32  : Unified wake masks for LPC/eSPI support
33  : 64-bit host events support
34  : Execute code in RAM support
16

You need to load the module with the parameter probe_with_fwk_charge_control=1.

And do not

  • Use the charge control settings in the firmware setup
  • mess with charge control settings via ectool
  • use the charge control logic from framework-laptop-kmod
17

Just modprobed it right back in with this parameter and the sysfs nodes appear.

If I’m reading the source correctly, you can use the firmware setup (or any other charge control interface for that matter), just that in this case the changes using those other tools will not be propagated to the sysfs nodes, right?

Also, the EC seems to get configured with the module’s hardcoded defaults of 0-100 on init, hence using it with the FW setup should be fine as long as you then issue the same charging limits?

18

No, there are in fact two separate implementations of charge management in the Framework EC.
The upstream one and their custom one. If the custom one is active it breaks the upstream one.

The mainline driver uses the upstream API, everything else uses the Framework API.

If you want to keep them always the same as the firmware setup,
what is the point of using the module?
(And I’m not sure it would even work)

1 Like
19

Ah, that’s very good to know and explains what I was observing, thanks!

Given the above it would most likely not work, yes. My use case is to have a 60% threshold almost all of the time, but when I know I’ll be traveling I temporarily raise that to 100%, and I want that to also work on Windows. Would the EC retain the thresholds set by the upstream API when powered off, until they’re set again, this way I don’t have to worry about the battery charging up for no reason when powered off? (also can you confirm that to disable the firmware charge control setting it to 100% in the setup is enough?)

EDIT: I probably should have tried myself first :slight_smile: setting fw charge control to 100 in the setup is in fact enough, and using this sysfs node the threshold settings are kept across reboots… up until cros_charge_control is loaded again and resets everything to default. It would be nice to have this be preserved across reboots if possible! Works like a charm otherwise.

20

Notable PRs for charge limit UI in GNOME and the corresponding UPower enhancement. With any luck, this’ll land in GNOME 47 (2024-09-17).

4 Likes