Re: [PATCH v6 5/5] platform/x86: bitland-mifs-wmi: Add per-machine ops table

[Miloš Vlku]

Hi Anton,

> The Pro 14 2024 (TM2307) is built on the same platform (Xiaomi's
> downloads for both, the BIOS included, are filed under one platform
> name, N56N57) and may behave the same; I cannot verify that.

I have a TM2307 (XIAOMI / "Redmi Book Pro 14 2024", BIOS RMAMT4B0P0B0B
06/10/2025, bios_release and ec_firmware_release both 1.11 -- the same
releases you report for the TM2309). It matches your machine on every
point you listed, checked against the ACPI tables:

- Same method and table: \_SB.PC00.WMID.WMAA in the SSDT with OEM Table
  ID XMCC1806.
- Same commands implemented: 0x08 (GET and SET), 0x0a, and 0x10 (GET
  subcommands 1-3, SET subcommand 2 only). Everything else answers
  0xE000, including 0x0d, 0x13, 0x14 and 0x16. A GET of 0x0a echoes
  FUN3 back and answers 0x8000 whatever the subcommand, as you saw.
- NTDP maps QFAN to ODV1 identically: 3 -> 1, 2 -> 2, 4 -> 4, 5 -> 5,
  6 -> 6, and everything else -- so 0 and 1 -- to 0.
- SET fn8 writes the value into QFAN as is, with 5 and 7 going to SMMD
  instead.
- The SET branches never fill in the function id. All five FUTR
  assignments in WMAA are in the GET branch. So "Detect failed function
  calls" returns -ENOMSG for every SET here too, and Chris's "Only check
  the function id of GET responses" is needed on this board as well.
- 0x10 subcommand 2 is the LONL charge-protection bit here too: SET sets
  bit 0 for the value 1 and clears it for anything else, reporting
  0x8000 either way. So "echo fixed > kb_mode" is 0x10/2 with value 0
  and turns charge protection off on this machine as well. Agreed that
  kb_mode must not be exposed on these boards.

One place where I think the data differs, and it matters for the entry.

Your table lists 0 and 1 together as balanced. That is right for ODV1 --
NTDP maps both to 0, same as here -- but they are not interchangeable at
the EC fan level on this board.

There is no tachometer to read (0x0d unimplemented, and no tach byte
anywhere in EC RAM), so I measured cooling rate instead. Heat the package
to 80 C, drop the load, hold QFAN fixed, and record how far the package
temperature falls over a fixed 150 s window. PL1 and PL2 both pinned to
35 W so the ramp is identical between runs, any fan daemon stopped, run
order shuffled, QFAN read back every sample.

  QFAN  n  mean drop  sd    range        end temp  skin TSR3/TSR4
  0     4  15.2 C     1.48  13.0-17.0 C  63-67 C   49-52 / 50-52 C
  1     4  29.5 C     1.12  28.0-31.0 C  50-52 C   44-46 / 41-42 C

>From the same 80 C start at the same power, mode 1 sheds about twice the
heat, and the two ranges do not overlap. The skin sensors say the same
thing independently: the chassis ends 8-10 C hotter after a mode 0 run,
so the heat is staying in the machine rather than being exhausted.

Caveats, since this is a proxy and not an RPM reading: n=4 per mode; the
shuffle happened to put three mode-0 runs together and heat soak is
visible within them (16 -> 15 -> 13 C as the skin climbs), which is
inside the quoted sd; and a time-to-threshold metric I also recorded did
not separate the two modes at all, so the fixed-window drop is the only
thing I am claiming. Raw per-run CSV attached if you want to check it.

So I would suggest an entry for these boards uses balanced = 1 rather
than 0. Same policy, different fan behaviour -- and 0 is exactly what the
current bitland_ops map writes for platform_profile "balanced", which is
how this started for me: fans effectively idle until the EC's own ~100 C
threshold.

Happy to test patches on TM2307.

Thanks,
Milos

On Wed, Sep 30, 2026 at 3:51 AM Anton Karasev <uselessfire@xxxxxxxxx> wrote:
>
> Hi,
>
> Data for the per-machine table from a Xiaomi Redmi Book Pro 16 2024
> (DMI: sys_vendor "XIAOMI", board_name "TM2309"; BIOS RMAMT6B0P0B0B,
> bios_release and ec_firmware_release 1.11), the same model as in
> Martiya's report. RMAMT6B0P0B0B (August 2025) is the latest BIOS Xiaomi
> publishes for this model, so this is what an entry would be written
> against. Its values match neither the Bitland defaults nor the Redmi map
> proposed in v5 6/6. The full acpidump is attached to bugzilla 222062:
> https://bugzilla.kernel.org/attachment.cgi?id=310971
> The WMI method is \_SB.PC00.WMID.WMAA in the SSDT with OEM Table ID
> XMCC1806; QFAN and NTDP are in the DSDT.
>
> Mode values
> -----------
>
> WMAA stores the value written with WMI_FN_SYSTEM_PER_MODE in the EC
> register QFAN as is (5 and 7 go to a separate register, SMMD, instead),
> and NTDP in the DSDT maps QFAN to the DPTF variable \_SB.ODV1 (odvp1 in
> sysfs) that thermald --adaptive uses to pick the policy from the GDDV:
>
>   QFAN   meaning                          ODV1
>   0, 1   balanced (Fn+K sets 1)           0
>   2      quiet                            2
>   3      performance ("Turbo")            1
>   4      full speed ("Geek")              4
>
> GET returns QFAN for 1..4 and 0 otherwise (so 0 after a SET of 0).
> Fn+K on this model cycles 1 -> 3 -> 2.
>
> I tested this with a local build that maps low-power/balanced/
> performance to 2/1/3: power-profiles-daemon power-saver, balanced and
> performance give odvp1 2, 0 and 1, and thermald loads the matching GDDV
> targets (PL1 limits, TCC offset), both on AC and on battery.
>
> On the DMI match: the v5 6/6 match on sys_vendor "Redmi"/"TIMI" would
> not cover this machine, and performance = 0 from that map is balanced
> here. The REDMI Book Pro 16 2025 in Aleksey's report also has
> sys_vendor "XIAOMI" but uses different values, so an entry for this
> model has to match board_name "TM2309". The Pro 14 2024 (TM2307) is
> built on the same platform (Xiaomi's downloads for both, the BIOS
> included, are filed under one platform name, N56N57) and may behave the
> same; I cannot verify that.
>
> Capability checks
> -----------------
>
> a) Performance on AC and on battery. WMI_FN_SYSTEM_AC_TYPE is not
>    implemented on this BIOS, so with Armin's "Treat
>    WMI_FN_SYSTEM_AC_TYPE as optional" the capability check passes on
>    AC. The write itself is still reported as failed here, though:
>    WMAA's SET branches set only the return code and leave the function
>    id at 0 (only the GET branches fill it in), so "Detect failed
>    function calls" (23cc56f6dea6 in for-next) returns -ENOMSG for every
>    SET on this BIOS, although the firmware applies it -- the same as
>    Chris reported for the Book Pro 14. I checked it with the for-next
>    version of the driver built for 7.2.7: every write of low-power,
>    balanced and performance failed with -ENOMSG while QFAN changed to
>    2, 0 and 3; with Chris's "Only check the function id of GET
>    responses" on top, all of them succeed.
>    On battery, power_supply_is_system_supplied() still refuses
>    performance, although the firmware supports Turbo on DC: Fn+K
>    reaches it on battery, the GDDV has a DC Turbo target, and writing 3
>    on battery works (odvp1 1, thermald applies the DC Turbo limits).
>
> b) Full speed. The firmware does not validate the mode at all. Writing
>    4 was accepted and applied (odvp1 4, thermald loads the Geek targets;
>    on AC the PL1 ramped towards the 90 W Geek maximum) both on battery
>    and on a 100 W USB-C PD charger, while Fn+K never offers full speed
>    in either case. It is not a charger thing either: with the stock
>    140 W USB-C charger (the EC register ADPW then reads 140, and GET of
>    command 0x10, subcommand 3, would report the adapter as not below
>    140 W) Fn+K still cycles only 1 -> 3 -> 2. So on this model full
>    speed is never offered by the vendor's own key, and whether it is
>    exposed has to be decided by the driver; the firmware will not stop
>    it.
>
> Commands that are not implemented, and one that is dangerous
> ------------------------------------------------------------
>
> On this BIOS WMAA implements only command 0x08 (GET and SET), 0x0a
> subcommand 5, and 0x10 (GET subcommands 1-3, SET subcommand 2 only).
> Other command IDs answer 0xE000, among them everything else the driver
> uses: 0x09 (gpu_mode), 0x0d (fan speeds), 0x12 (keyboard brightness),
> 0x13 (AC type), 0x14 (fan_boost) and 0x16 (CPU temperature).
> Unhandled subcommands of 0x0a and 0x10 mostly return status 0, and a
> GET of 0x0a answers 0x8000 whatever the subcommand. The hwmon device,
> the kbd_backlight LED, gpu_mode and fan_boost therefore have nothing
> behind them on this machine; probing support at probe time would avoid
> exposing them.
>
> kb_mode is worse than unsupported. kb_mode_store() sends command 0x10
> (WMI_FN_RGB_KB_MODE) with the mode in the first payload byte. On this
> firmware command 0x10 is the battery interface, and subcommand 2 is the
> charge protection (bit 0 of the EC register LONL, 80 % limit; reportedly
> what Xiaomi's Windows tools toggle): WMAA sets the bit only for the
> value 1 and clears it for anything else. "echo fixed > kb_mode" is
> therefore 0x10/2 with value 0. I verified on this machine that it
> silently turns off charge protection -- LONL goes from 0x31 to 0x00, the
> charge limit in the EC goes from 80 back to 100 and the battery, which
> had been held at 80 %, starts charging again -- while the firmware
> reports success (0x8000). That was on 7.2.7, whose driver does not check
> the reply; with 23cc56f6dea6 the write returns -ENOMSG instead, but
> protection is off all the same. I think kb_mode must not be exposed on
> these machines.
>
> Once the generic profile table has settled I can send a patch with the
> entry for this model and the kb_mode fix on top of it, and I am happy to
> test patches in the meantime.
>
> Thanks,
> Anton Karasev
drop_c,heat_s,mode,peak_c,phase,seconds_to_cold,skin_TSR3,skin_TSR4,skin_TSR7,skin_TSRA,t_end_c,t_start_c,window_s
30.00,20.2,1,81.0,cooldown,1.03,46,42,45,39,51.0,81.0,150
29.00,15.3,1,80.0,cooldown,1.03,45,41,44,38,51.0,80.0,150
16.00,19.3,0,80.0,cooldown,3.09,52,51,50,48,64.0,80.0,150
15.00,1.0,0,80.0,cooldown,1.04,52,52,50,48,65.0,80.0,150
13.00,1.0,0,80.0,cooldown,1.04,52,52,50,49,67.0,80.0,150
28.00,1.0,1,80.0,cooldown,1.03,46,42,44,40,52.0,80.0,150
31.00,27.7,1,81.0,cooldown,1.03,44,41,42,38,50.0,81.0,150
17.00,20.6,0,80.0,cooldown,3.11,49,50,48,47,63.0,80.0,150