0

I'm using ST's own driver for the LSM6DS[ML] IMU.

If that driver is in the middle of accessing an IMU register at kernel shutdown, the I2C bus can be left jammed, with SCL pulled low: pulseview screenshot of jammed i2c bus

This means that the final I2C write (to a PMU chip, hooking into pm_power_off) cannot always happen. Therefore the power sometimes gets left on.

I'm trying to understand where I should fix this.

  • Is ST's lsm6dsm driver faulty in some way?
  • Is the kernel's I2C handling faulty? (I can't think of a reason for it to ever leave the I2C bus jammed.)
  • Is it valid for an I2C bus to be left jammed at shutdown and therefore invalid to call regmap_write() from pm_power_off?
0andriy
  • 4,183
  • 1
  • 24
  • 37
fadedbee
  • 42,671
  • 44
  • 178
  • 308
  • 1
    The lines should be left in the idle state at the end of read or write. If the I/O is not completing there should be a log. Turn up console logging and capture with PuTTY. – stark Oct 01 '21 at 11:51
  • 1
    Oh. No question it's the driver. – stark Oct 01 '21 at 11:52
  • @stark Their code calls `i2c_transfer(client->adapter, msg, 2);` to write the register number to the address, restart and then read from the address. Looking at the logic analyser, I could see the first message part but the restart and the second message part were missing. Their driver was not in control at this point, as it had called `i2c_transfer()` with both message parts at once. Does a kernel shutdown just kill drivers in the middle of function calls, implicitly killing what they're calling? – fadedbee Oct 01 '21 at 12:29
  • Shutdown normally sends "please terminate". Any current I/O completes, the device is closed, the process ends gracefully. If it doesn't stop quickly, shutdown says "kill now". Normally, I/O will still complete, but if it doesn't, then shutdown may do something drastic. Is it possible the process is ignoring SIGTERM? – stark Oct 01 '21 at 13:22
  • And why you don't use the upstreamed version of it? https://elixir.bootlin.com/linux/v4.19.208/source/drivers/iio/imu/st_lsm6dsx – 0andriy Oct 02 '21 at 08:31
  • 1
    The I²C communications WRT shutdown is very tricky in the Linux kernel. You may read this discussion: https://lwn.net/Articles/781173/ – 0andriy Oct 02 '21 at 08:37
  • @0andriy I need the correct driver for the ST-provided Sensor HAL. I have previously had issues (with a different ST IMU). The upstreamed driver did not provide all of the /sys paths that ST's SensorHAL required, and which ST's driver provided. – fadedbee Oct 02 '21 at 14:44
  • @stark ST's driver is part of the kernel. (They also provided a SensorHAL implementation.) Do kernel threads get signalled with SIGTERM? – fadedbee Oct 02 '21 at 14:46
  • Have you tried to report upstream about this? STMicro guys are also active there – 0andriy Oct 02 '21 at 15:04
  • @0andriy I'll raise a GitHub Issue on Monday, thanks. – fadedbee Oct 02 '21 at 15:24
  • @fadedbee I was referring to the user process which is making the I2C calls. Once shutdown starts, there should be no more I/Os issued. – stark Oct 02 '21 at 19:14
  • @stark the user process is ST's Sensor HAL. The problem is that the driver's call to `i2c_transfer(client->adapter, msg, 2);` only completes the first message part (a write containing the register address) and not the second (a restart and a read from that register), leaving the I2C bus jammed. – fadedbee Oct 03 '21 at 07:51

0 Answers0