Bug 218578

On Sat, 09 Mar 2024 17:55:32 +0000
bugzilla-daemon@kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=218578
> 
>             Bug ID: 218578
>            Summary: MXC6655 accelerometer not working with MXC4005 driver
>            Product: Drivers
>            Version: 2.5
>           Hardware: Intel
>                 OS: Linux
>             Status: NEW
>           Severity: normal
>           Priority: P3
>          Component: IIO
>           Assignee: drivers_iio@kernel-bugs.kernel.org
>           Reporter: kernelbugzilla@kirkschnable.com
>         Regression: No
> 
> Created attachment 305970 [details]
>   --> https://bugzilla.kernel.org/attachment.cgi?id=305970&action=edit  
> Output from udevadm info -n /dev/iio\:device0 && also some samples of
> accelerometer raw values I see in /sys/bus/iio/devices/iio:device:0/.
> 
> Hello,
> 
> I recently bought two Chuwi tablets which contain MXC6655 accelerometers. 
> The
> accelerometers work in Windows 11 and the tablet rotates as expected in
> Windows, but upon installing Linux the tablet auto rotation was not working.
> 

Hi, thanks for the report,

First thought is that there may be some power control hidden in the ACPI tables.
Could you dump
/sys/firmware/acpi/tables/DSDT
and run it through iasl -d (from acpica-tools)

Find the section related to his accelerometer and post all of that.
Sometimes there is a _DSM (device specific method) used to power things up
- this stuff is completely non standard unfortunately so we have to base
any support on table dumps from the particular devices.

Thanks,

Jonathan


> The Chuwi tablets are:
> - UBook X Pro 2023
> - UBook X 2023
> 
> This does not appear to be distro specific, as I am seeing the same behavior
> on
> both:
> - Linux Mint 21.3, with kernel 5.15.0-91-generic
> - Fedora 39 Workstation, with kernel 6.5.6-300.fc39.x86_64
> 
> I came across this thread indicating that support was added for this in 2020
> via the MXC4005 driver: https://www.spinics.net/lists/linux-iio/msg53171.html
> 
> This seems to be double confirmed by another issue I found here on this bug
> tracker: https://bugzilla.kernel.org/show_bug.cgi?id=206703
> 
> Unfortunately in my case, I see the MXC4005 driver is in fact loaded and
> running, however it appears the raw data is not changing.  When looking at
> the
> output from iio-sensor-proxy with "monitor-sensor", the orientation always
> reports "left-up".
> 
> I tried a test where I watched a cat of all of the files in
> /sys/bus/iio/devices/iio:device0/, and I never see the raw data changing when
> the tablet is rotated.  I'm attaching the values I see from the raw data in
> the
> text file.  Interestingly, Fedora reports different raw values, but
> iio-sensor-proxy still says orientation is left-up with these values.  In
> both
> cases, the values don't change when the tablet is rotated.
> 
> The output of "udevadm info -n /dev/iio\:device0" is attached too.
> 
> lsmod reports that the mxc4005 driver is loaded, along with industrialio and
> industrialio_triggered_buffer.  Unloading the mxc4005 module with rmmod
> causes
> it to disappear from iio-sensor-proxy as expected, but otherwise unloading
> and
> reloading the driver seems to have no effect on the symptoms.
> 
> If there is any further information I can gather which will be helpful, or
> any
> testing I can help with, please let me know. 
> 
> Thanks!
>

Created attachment 305975 [details]
Excerpts from DSDT in ACPI table

Hello Jonathan,

Thanks for your response, and I have done some further testing today which has led me to some interesting conclusions.

I have, as you requested, extracted the DSDT information relevant to the accelerometer and attached it.  I found 6 devices containing the word "Accelerometer" so I pulled the details of all of them, but I think the first one, ACC0, is the relevant one since it mentions the MXC6655 model number.

My further testing today has led me to conclude that this problem is more "intermittent" than I'd first believed.  It almost led me to incorrectly conclude that I'd been mistaken about the whole thing in fact.

I made another post elsewhere and connected with another user of a similar Chuwi tablet device who says their accelerometer is working reliably on Fedora 39 (after a workaround to correct the fact that the orientation is 90 degrees off).  They encouraged me to try it from the live environment, which I did not expect to make any difference, however it actually worked exactly as he had described.  For the first time, I saw actual updates to the raw data, and the screen was actually rotating (albeit, incorrectly).

This prompted me to perform another fresh install of Fedora.  To my shock, the fresh install worked at first boot too, then I started to try to fix the 90 degree orientation issue.  I created a file in /etc/udev/hwdb.d/ with some suggested settings and rebooted.  After that, the accelerometer no longer worked.  So, I reverted the change and rebooted again.  Still no accelerometer readings anymore.

Thinking that maybe I'd broken that install somehow (even though I reverted all the changes), I did another fresh install.  This fresh install worked too until I rebooted the system.  I did nothing else but reboot the system.  Totally broken, even several reboots later.

I tried running DNF updates on this install (over 600 packages needing update), and rebooted again.  Still no accelerometer.  An update clearly didn't break it but an update also didn't fix it.

While attempting to begin a third fresh install to try to reproduce this and see if this was a pattern, I performed the test again from the live environment and got no accelerometer readings.  This is the exact same USB I installed from earlier that worked several times this morning.

Something is very strange.  I would almost believe it was a faulty accelerometer if it weren't for the fact that I used this tablet for 3 hours today in Windows 11 and experienced no issues with the screen rotation.

I will say this much, I have yet to see the problem "go away" on an install once it starts.  The installs that work once and then break never start working again.  The live environment has been the most likely to work, but I have now seen it not work.  I dumped the ACPI data for you from a live session of Fedora 39 when the accelerometer was not working.

Hopefully this data is helpful.  I am not knowledgeable enough about how these ACPI components function under the hood, but it seems like the issue is less an issue of "the accelerometer never works" and more of an issue of "the accelerometer only works sometimes".

Thanks!
Kirk

Kirk, Jonathan Cc-ed me on this bug since I've done a lot of work on accelerometers on x86 tablets.

I notice you use the word "reboot(ed)" a lot in your last comment.

What happens if you power off the tablet and then power it back on again and then directly start the livecd (presumably this is what you did during your first test?).

This way the device is fully reset / in a clean hwstate when starting the livecd.

Or reboot from a working Windows environment into the livecd ?  (maybe Windows does something extra and rebooting keeps that state, combined with the livecd because you have had the accelerometer work there before)

As for figuring out which DSDT node is actually the one used on your tablet. Lets first focus on 1 single tablet (of your choosing) and ignore the other tablet for now.

On the chosen tablet can you do:

ls -l /sys/bus/i2c/devices/

This should show a device for your accelerometer. E.g. "i2c-MXC6655:00" (but maybe something else) please run:

cat /sys/bus/i2c/devices/i2c-MXC6655:00/firmware_node/path

replacing "i2c-MXC6655:00" with the actual accelerometer i2c-device and then let us know the output.

Also please run:

sudo acpidump -o acpidump.txt
sudo dmesg > dmesg.txt

And attach both generated .txt files here.

Created attachment 305987 [details]
dmesg

Created attachment 305988 [details]
acpidump

Hello Hans,

Thanks for your response as well, and my apologies for the delay, I wanted to do a bit of further testing.

It hadn't specifically occurred to me that rebooting from Windows might be causing an issue.  I'm aware that Windows by default does save some state data for a faster boot, but I didn't think any of this would make any difference in a normal reboot once you hit GRUB and select your Linux installation.

Regardless, it does seem like making sure to do a cold boot every time has resulted in the accelerometer working a bit more reliably.  However, before, I was even rebooting from Fedora back into Fedora and still having trouble with it, so I don't think it's specifically Windows causing the symptoms either.  Not sure what to make of it yet...

In any case here are your requested details:

The path you specified did exist:
i2c-MXC6655:00 -> ../../../devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-MXC6655:00

# cat /sys/bus/i2c/devices/i2c-MXC6655\:00/firmware_node/path 
\_SB_.PCI0.I2C0.ACC0

I'm attaching the dmesg and acpidump.  These are from a persistent Fedora install which was updated to 6.7.7-200.fc39.x86_64.

Thanks!
Kirk

Thanks.

So I've taken a look at the driver and I noticed that it does not reset the chip on probe. So maybe sometimes the chip comes up in a weird state and we need to modify the driver to reset it on probe.

Can you try the following:

First install i2c-tools:

sudo dnf install i2c-tools

Then do a cold boot, check the accelerometer works and then do:

sudo i2cdump -y -f -r 0-15 0 0x15

And copy and paste the output to a "i2cdump-good.txt" .

Then reboot until the accelerometer stops working, then do:

sudo i2cdump -y -f -r 0-15 0 0x15

And copy and paste the output to a "i2cdump-bad.txt" .

Now on this broken setup lets try to reset the accelerometer:

sudo i2cset -y -f 0 0x15 0x01 0x10

This writes 0x10 to register 0x01 which sets the SW_RST bit

And then check if the accelerometer now has started working.

Also please make another dump after the reset (from bad state):

sudo i2cdump -y -f -r 0-15 0 0x15

And copy and paste the output to a "i2cdump-after-reset.txt" .

Hopefully these dumps will help us figure out what is going on.

If you are interested in poking more at this yourself, there is a datasheet available here: https://media.digikey.com/pdf/Data%20Sheets/MEMSIC%20PDFs/MXC6655XA_Rev_A_1-22-20.pdf

This should allow you to interpret the contents of the dumps.

p.s.

In your next comment please also let me know if the accel started working after the reset.

p.s. (again)

And (likely stating the obvious) please attach all the i2cdump-*.txt files here.

Created attachment 305992 [details]
i2cdump good, cold boot, accelerometer working

Created attachment 305993 [details]
i2cdump bad, reboot, accelerometer not updating

Created attachment 305994 [details]
i2cdump after reset, accelerometer started updating again

Hello Hans,

Thanks!  I think your diagnosis is spot on.  I went ahead with the process and attached the files. 

Resetting the accelerometer with the provided command immediately made it start updating again.

Cheers,
Kirk

(In reply to Kirk Schnable from comment #14)
> Thanks!  I think your diagnosis is spot on.  I went ahead with the process
> and attached the files. 
> 
> Resetting the accelerometer with the provided command immediately made it
> start updating again.

Ok, that is good news, so we just need to add the reset command to the probe() method of the driver.

If Jonathan or me provide a kernel patch for this, would you be able to test this (this requires building your own kernel with the patch) ?

Jonathan, I'm buried in work atm, so I would not mind if you beat me to providing a patch for this.

FWIW the (main?) problem seems to be that sometimes the chip comes up with bit 0 register 0x0d set putting the chip in power-down mode. Although some of the other register values are suspect to in the bad dump (all the interrupt bits are set) but that might be due to the powerdown mode ?

Thanks for the continued support Hans!  I have actually never compiled my own kernel before, but there's a first time for everything.  I'm down to give it a go.

Also FWIW, my further testing has indicated that there are also problems when coming out of a sleep state.  Will your proposed fix also be likely to correct that behavior too?

(In reply to Kirk Schnable from comment #16)
> Thanks for the continued support Hans!  I have actually never compiled my
> own kernel before, but there's a first time for everything.  I'm down to
> give it a go.

I see in your attached dmesg that you are actually running Fedora, in that case I can actually provide pre-build kernel rpms with the patch for you.

I'll try to make some time to write a patch for this and provide rpms sometime this week.

> Also FWIW, my further testing has indicated that there are also problems
> when coming out of a sleep state.  Will your proposed fix also be likely to
> correct that behavior too?

That is good to know, that means that the driver also needs to reset the chip on resume (and restore any non default settings). I'll add this to the patch.

> I'll try to make some time to write a patch for this and provide rpms
> sometime this week.

Quick update: I don't expect to get around to this this week. I should be able to write the patch + prep a test kernel next week.

No worries Hans, it's been a busy week over here as well.  Thanks for the continued support! :)

Ok I have written a set of fixes for this and posted this upstream (as RFC for now since these are untested):
https://lore.kernel.org/linux-iio/20240326113700.56725-1-hdegoede@redhat.com/

I have also started a build of the latest Fedora 39 kernel with these patches (and the MDA6655 ACPI id which was recently added) for you to test:
https://koji.fedoraproject.org/koji/taskinfo?taskID=115457033

This is still building atm, this should complete building in a couple of hours.
Once this is done building please give this a test run. Here are some instructions for directly installing a kernel from koji (Fedora's buildsystem):
https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

If you don't have time to test the next couple of days, please at least download the kernel rpms. Since this is a test kernel build the build-results will be cleaned up to reclaim diskspace in about 5 days from now.

Created attachment 306045 [details]
/etc/udev/hwdb.d/ubook.hwdb file I created to fix the accelerometer orientation.

Hello Hans,

Awesome, thanks so much!  I am thrilled to report that this has fixed all of the issues.

I tested on both of my devices with this chip:
- UBook X 2023
- UBook X Pro 2023

I tested a number of scenarios including:
- Cold boot into Fedora
- Reboot out of Windows, boot into Fedora
- Reboot out of Fedora, boot into Fedora
- Go to sleep and wake up

In all cases, the accelerometer is now working 100% of the time. :) 


My issue is resolved, but I am still leaving the file I put in /etc/udev/hwdb.d/ubook.hwdb which is necessary to fix the orientation of the accelerometer.  Without this updated ACCEL_MOUNT_MATRIX, I found the screen rotation was upside down.

I'm not sure if it would be appropriate to push this type of update with the update we're doing, but if we are able to push that changed matrix out too, then anyone with this hardware should work properly out of the box with your patch.  If not, users of this model will still need to create that hwdb file.

Thanks!
Kirk

> In all cases, the accelerometer is now working 100% of the time. :) 

That is great, thank you for testing.

> My issue is resolved, but I am still leaving the file I put in
> /etc/udev/hwdb.d/
ubook.hwdb
> which is necessary to fix the orientation of the accelerometer.  Without this
> updated ACCEL_MOUNT_MATRIX, I found the screen rotation was upside down.

Right accelerometers needing a hwdb entry to set ACCEL_MOUNT_MATRIX unfortunately is quite normal. The hwdb with this entries is maintained as part of the systemd project.

I see in the attached file that your DMI "pn" (product name) is somewhat generic if possible please make this more specific to your model. After this please modify:

https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb

To add the entry for your tablet (or 2 entries one for each model if necessary) to the existing Chuwi section and then submit a pull-request to systemd upstream to get these orientation quirks added to the official hwdb. If you mention me: "@jwrdegoede" in the pull-request then I can review it.

Let me know if you need any help with creating the pull-request.

Hello Hans,

Thanks again for the guidance, and my apologies for my brief absence.  

I actually checked and they had a trivially different ACCELT_MOUNT_MATRIX already.  I think the problem was that they were missing a colon, LOL.  I tested their sensor line and their matrix and it works fine as long as the colon is properly present.

I have submitted my pull request:
https://github.com/systemd/systemd/pull/32108

Here's the actual change:
https://github.com/systemd/systemd/pull/32108/commits/dc133ca33821e3d5598351b973bc91ede5144c92

That should work correctly as I've tested it in my hwdb override file and it's working fine there.

It looks like your request is making some progress toward getting the patch into a kernel release too. :) 

Thanks!
Kirk

Kirk, I just noticed in the DSDT of another tablet with a MXC6655 accel that there is a ROTM method in the ACC0 device with BOSC0200 ACPI nodes this describes the orientation matrix.

So maybe we can just get the matrix from the ACPI tables and don't need a hwdb entry at all. Can you do:

sudo dnf install acpica-tools
sudo acpidump -o acpidump.txt 

And then attach acpidump.txt here ?

Created attachment 306125 [details]
acpidump

Hello Hans,

I have attached an ACPI Dump as requested.

Cheers,
Kirk

> I have attached an ACPI Dump as requested.

Thank you. First of all sorry for asking for one needlessly I now see there already was one attached to this bug.

So the ACPI firmware node describing the MXC6655 does contain a ROTM method like we have also seen on BOSC0200 and KIOX000A ACPI firmware nodes and that does correctly describe the rotation matrix of the accelerometer if I compare it with your hwdb, the only thing which is different is that it inverts the Z axis, but that axis is not used for rotation so chances are that inverting it is actually correct for apps which do care about it.

I have prepared a set of patches:
https://lore.kernel.org/linux-iio/20240417164616.74651-1-hdegoede@redhat.com/

Which adds ROTM parsing to the mxc4005 driver. I have started a F39 kernel build with the original set of fixes + these patches on top here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=116515238

This is still building atm, this should complete building in a couple of hours.
Once this is done building please give this a test run. Here are some instructions for directly installing a kernel from koji (Fedora's buildsystem):
https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

If you don't have time to test the next couple of days, please at least download the kernel rpms.

After booting this kernel you should be able to do:

cat /sys/bus/iio/devices/iio:device0/in_mount_matrix

(assuming iio:device0 is the accel)

And this should then show:

0, -1, 0; -1, 0, 0; 0, 0, -1

and you could drop the hwdb entry for the tablet if you want since iio-sensor-proxy should now pick it up from this file (hwdb entries will override the contents of this file so that broken firmware settings can be fixed).

p.s. Your systemd pull-request to fix the missing colon in hwdb of course is still good to have no need to retract that.

Ok, so my first build failed due to some diskspace issue on the builder. A new successful build with the patches to parse the "ROTM" ACPI method is here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=116519225

Hello Hans,

Awesome, thanks!  I tested the new build (and removed my udev workaround).  It looks to be working perfectly. :) 

The path /sys/bus/iio/devices/iio:device0/in_mount_matrix didn't exist but I found /sys/bus/iio/devices/iio:device0/in_accel_mount_matrix which does contain the matrix.

Looks like this now resolves all of the issues!

Cheers,
Kirk

(In reply to Kirk Schnable from comment #31)
> Awesome, thanks!  I tested the new build (and removed my udev workaround). 
> It looks to be working perfectly. :) 

Great thank you for testing. I've send a reply to the upstream patch submission to indicate that this has been tested now.