Bug 212615

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

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.

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

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/

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).

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

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.

(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.

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.

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.

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

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.

Hi Stormy,

May I know the BIOS version on the laptop?

Hi Swar,

May I know the BIOS version (Flex 5) you are using?

(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

(In reply to Mark Lee from comment #14)
> Hi Swar,
> 
> May I know the BIOS version (Flex 5) you are using?

BIOS Version: EECN30WW

As an update, this issue is still present with 5.15 rc1

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

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!

Apart for 1 more column of non-zero output, the bug is still present on the Lenovo 14ALC05 with Kernel 5.15.0 (Ryzen 3 5300U)

$ sudo ./iio_generic_buffer -a --device-num 0
iio device number being used is 0
iio trigger number being used is 0
Auto-channels selected but some channels are already activated in sysfs
Proceeding without activating any channels
/sys/bus/iio/devices/iio:device0 accel_3d-dev0
514284.375000 816214.562500 816227.125000 1635780653841921687 
514284.375000 816214.562500 816227.125000 1635780653841948835 
0.000000 -0.882599 -0.294199 1635780653951177401 
0.000000 -0.882599 -0.294199 1635780654154205185

Can confirm issue on 5.16. Device is HP ENVY x360 Convertible 13-ay0xxx. Distro is Manjaro.