Bug 212615 - amd-sfh driver gives invalid output
Summary: amd-sfh driver gives invalid output
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_input-devices
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-08 20:48 UTC by Stuart Morgan
Modified: 2021-10-19 01:07 UTC (History)
10 users (show)

See Also:
Kernel Version: 5.12.5
Tree: Mainline
Regression: No


Attachments

Description Stuart Morgan 2021-04-08 20:48:10 UTC
The amd-sfh driver loads correct and detects the hardware, but the output is all zeros no matter the device orientation.

This bug was originally raised downstream against iio_sensor_proxy where the determination was made that the problem originates at the driver level. The issue was reported against multiple laptop models using Ryzen mobile processors.

https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/issues/315


# iio_generic_buffer --device-num 0 -A -c 100
iio device number being used is 0
iio trigger number being used is 0
Enabling all channels
Enabling: in_accel_x_en
Enabling: in_accel_z_en
Enabling: in_timestamp_en
Enabling: in_accel_y_en
/sys/bus/iio/devices/iio:device0 accel_3d-dev0
514284.375000 816214.562500 816227.125000 1617913283256446331 
514284.375000 816214.562500 816227.125000 1617913283256478807 
0.000000 0.000000 0.000000 1617913283271095729 
0.000000 0.000000 0.000000 1617913283479099805 
0.000000 0.000000 0.000000 1617913283687318920 
0.000000 0.000000 0.000000 1617913283895314405 
0.000000 0.000000 0.000000 1617913284103289845 
0.000000 0.000000 0.000000 1617913284311314384 
0.000000 0.000000 0.000000 1617913284519359526 
0.000000 0.000000 0.000000 1617913284727312478
Comment 1 Daniel Parks 2021-04-14 20:15:43 UTC
On my system, the accelerometer is not always device #0. I get the exact same results as Stuart Morgan with the accelerometer, and similar results from the magnetometer and gyroscope:

# ./iio_generic_buffer --device-num 0 -a -c 5
iio device number being used is 0
iio trigger number being used is 0
Enabling all channels
Enabling: in_magn_z_en
Enabling: in_magn_y_en
Enabling: in_magn_x_en
/sys/bus/iio/devices/iio:device0 magn_3d-dev0
5.244241 8.323072 8.388735
5.244241 8.323072 8.388735
0.000000 0.000000 0.000000
0.000000 0.000000 0.000000
0.000000 0.000000 0.000000
0.000000 0.000000 0.000000
Disabling: in_magn_z_en
Disabling: in_magn_y_en
Disabling: in_magn_x_en

# ./iio_generic_buffer --device-num 1 -a -c 5
iio device number being used is 1
iio trigger number being used is 2
Enabling all channels
Enabling: in_anglvel_z_en
Enabling: in_anglvel_y_en
Enabling: in_anglvel_x_en
/sys/bus/iio/devices/iio:device1 gyro_3d-dev1
915.287903 1452.642456 1452.664795
915.287903 1452.642456 1452.664795
0.000000 0.000000 0.000000
0.000000 0.000000 0.000000
0.000000 0.000000 0.000000
0.000000 0.000000 0.000000
Disabling: in_anglvel_z_en
Disabling: in_anglvel_y_en
Disabling: in_anglvel_x_en

While I was testing this, I unloaded and reloaded amd_sfh, and shortly afterwards, my system experienced a kernel panic. I don't have the logs, unfortunately, because all outputs froze (even the caps lock key didn't blink) and it didn't sync.

The last command in the audit log before the panic was:

./iio_generic_buffer --device-num 2 -a -c 5
Comment 2 Stuart Morgan 2021-04-20 16:39:02 UTC
I see some device quirks being added to the 5.12 branch, RC8, for HP Envy line model ag0* 

I'm using the HP Envy AY0009NA which isn't covered by those quirks.
Comment 3 Dylan MacKenzie 2021-06-22 01:57:09 UTC
I have an HP Envy x360 13-ay0xxx, which has a Ryzen 4700U (Renoir) processor. I am experiencing the same issue: 2 sensors are detected but `./iio_generic_buffer` shows the same nonsense value followed by all zeroes. Multiple other Linux users with Renoir chipsets are having the [same issue](https://bbs.archlinux.org/viewtopic.php?pid=1947124#p1947124).

I took a look at the Windows driver (amdsfhkmdf.sys), and found many similarities with the Linux driver. However, the Windows driver checks the lower four bits of [`activecontrolstatus`](
https://github.com/torvalds/linux/blob/a96bfed64c8986d6404e553f18203cae1f5ac7e6/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c#L112) for the magic value 2. If found, it uses very different set of MMIO writes to pass commands to the SFH. For example, here's pseudocode that mimics the Windows driver's method of enabling a given sensor:

```c
  c2p_cmd_idx_and_interval = sensor_idx | (uint)interval << 8;

  if (data->activecontrolstatus_lo4 == 2) {
    c2p_cmd_part = (param_4 & 1 | c2p_cmd_idx_and_interval << 0xc) << 4;
    c2p_cmd = c2p_cmd_part | 0x1001;

    // MMIO writes
    data->c2p_msg[2] = /* sensor addr hi */;
    data->c2p_msg[1] = /* sensor addr lo */;
    *data->c2p_msg = c2p_cmd;
  } else {
    c2p_cmd = c2p_cmd_idx_and_interval << 8 | AMD_SFH_CMD_ENABLE_SENSOR;

    // MMIO writes
    data->c2p_msg[3] = /* sensor addr hi */;
    data->c2p_msg[2] = /* sensor addr lo */;

                    /* amd_sfh_param {
                        .layout = 1,
                        .len = 0x20,
                       } */
    data->c2p_msg[1] = 0x41;
    *data->c2p_msg = c2p_cmd;
  }
```

The code in the `else` block is basically the same as `amd_start_sensor` in the Linux driver, but the code in the `if` block uses a different layout for the command register, has extra bit flags, and uses different address registers.

Sure enough, the lower bits of `activecontrolstatus` on my system are 2. I'm guessing that this is not the case on older architectures (Matisse, Starship, etc.), and those bits indicate a later revision of the SFH hardware with a different interface. I have not confirmed this, however.

cc nehal-bakulchandra.shah@amd.com
Comment 4 Dylan MacKenzie 2021-06-22 03:26:15 UTC
Ah, I just found a patch for the new architecture that was filed a couple days ago. Seems like this will be fixed soon.

https://patchwork.kernel.org/project/linux-input/patch/20210618081838.4156571-4-Basavaraj.Natikar@amd.com/
Comment 5 Maxwell Beck 2021-08-07 02:17:22 UTC
Unfortunately screen rotation still does not work for me on kernel 5.14-rc4, which should have all of the patches for Renoir/Cezanne support merged in. I get the same exact behavior as the others here. I also have the HP Envy x360 13-ay000 but with a 4500U, and it is updated to the latest available BIOS (F.18).
Comment 6 Nehal Shah 2021-08-07 03:36:35 UTC
Hi Maxwell

Can you please share your laptop model number
And also the ubuntu version?

Hi @Dylan, is it working fine in your laptop( presuming you have Renior based laptop)

Regards
Nehal
Comment 7 Stuart Morgan 2021-08-07 10:00:01 UTC
5.14-rc4 is also not working for me with the HP Envy x360 model AY0009NA. I see exactly the same behaviour as with earlier kernels and as shared in my initial bug report.
Comment 8 Stuart Morgan 2021-08-07 11:45:34 UTC
(In reply to Stuart Morgan from comment #7)
> 5.14-rc4 is also not working for me with the HP Envy x360 model AY0009NA. I
> see exactly the same behaviour as with earlier kernels and as shared in my
> initial bug report.

This is with Fedora 34.
Comment 9 Maxwell Beck 2021-08-09 20:13:21 UTC
The most exact model number I can get on my laptop is 13z-ay000 as it was a customized order. I have been testing with NixOS 21.05.
Comment 10 Swar Shah 2021-08-12 03:41:55 UTC
I just tried the 5.14-rc5 on my IdeaPad Flex 5 14ARE05 running on Ubuntu 20.04.2 and it still seems to be broken, at least in my case. It appears to detect the rotation but as soon as it detects it, the screen goes static like the old television static screen and only way to get screen working again is a hard reboot.
Comment 11 Nehal Shah 2021-08-12 05:15:51 UTC
Hi Swar and All,

We are setting up the same environment and looking into the issue as we are not getting the issue on available reference platform.

Thanks
Nehal Shah
Comment 12 Stormy 2021-08-16 15:31:11 UTC
Hello everyone,

I have the same issue with the following laptop...


Make/Model: HP ENVY x360 2-in-1 Convertible 15z-ee100

CPU/GPU: AMD Ryzen 5700U with Radeon Graphics


I hope this will help find a fix.
Comment 13 Mark Lee 2021-08-20 02:17:02 UTC
Hi Stormy,

May I know the BIOS version on the laptop?
Comment 14 Mark Lee 2021-08-20 02:41:18 UTC
Hi Swar,

May I know the BIOS version (Flex 5) you are using?
Comment 15 Stormy 2021-08-20 12:49:25 UTC
(In reply to Mark Lee from comment #13)
> Hi Stormy,
> 
> May I know the BIOS version on the laptop?

Hello Mark,

Is this what you are looking for? See attached images:
https://cdn.discordapp.com/attachments/365979535642066957/878256612740050974/20210820_083334.jpg
https://cdn.discordapp.com/attachments/365979535642066957/878257538762698802/20210820_084133.jpg


Images not working? Possible information:
BIOS Vendor: Insyde
BIOS Revision: F.03
Comment 16 Swar Shah 2021-08-20 17:51:27 UTC
(In reply to Mark Lee from comment #14)
> Hi Swar,
> 
> May I know the BIOS version (Flex 5) you are using?

BIOS Version: EECN30WW
Comment 17 Stuart Morgan 2021-09-29 21:45:09 UTC
As an update, this issue is still present with 5.15 rc1
Comment 18 Mek101 2021-10-06 12:03:56 UTC
I would like to confirm that this issue is also affecting the Lenovo Ideapad 14ALC05 with the Ryzen 3 5300U cpu, kernel 5.14.7


$ sudo ./iio_generic_buffer --device-num 0
iio device number being used is 0
iio trigger number being used is 0
/sys/bus/iio/devices/iio:device0 accel_3d-dev0
514284.375000 816214.562500 816227.125000 1633520534367737352 
514284.375000 816214.562500 816227.125000 1633520534367756348 
0.000000 0.000000 0.882599 1633520534567971505 
0.000000 0.000000 0.882599 1633520534771316637
Comment 19 Swar Shah 2021-10-19 01:07:45 UTC
I just tried the 5.15.0-rc6 and it seems to have resolved the issue for me. No more static screen on rotation or waking the display up from suspend. Thanks!

Note You need to log in before you can comment on or make changes to this bug.