i2c driver debugging on low memory

53 views
Skip to first unread message

Pankaj Pandey

unread,
Jul 13, 2024, 1:53:55 AM7/13/24
to kernel-meet...@googlegroups.com, Yogender Arya
Hi All, 

We are trying to use Goodix GT-911 touch sensor with synopsis DW-I2C IP to configure the sensor. The I2c driver is interrupt driven and the depth of Receive/transmit FIFO is 32-bytes. During the probe of GT-911 touch sensor, The sensor requests the firmware using request_firmware_nowait() call which uses system workqueue thread for the call-back function, if the firmware is found successfully. The touch sensor is compiled as a part of the kernel and not as a separate module. The issue is that when the call back function is called from the workqueue thread (kworker/0:1) and it tries to send the 186 bytes of firmware that it has found, The I2C_TX_EMPTY interrupt (I2C TX Threshold = 16 bytes) is getting delayed for several milliseconds. When the same data is sent through the main probing thread (swapper) during the system init, we can see the I2C_TX_EMPTY interrupt is not delayed and the whole 186 byte of firmware is sent through successfully in a single burst.   Due to the delaying of the I2C interrupt handling in workqueue thread, the data that should have been replenished in the TX FIFO after the I2C_TX_EMPTY interrupt was not replenished, and the I2C STOP was detected. This I2C stop is used in the ISR of DW-I2C handler to release a completion, which is being waited upon in the i2c_dw_xfer (master_xfer) function. This causes the I2C transfer to terminate abnormally resulting in the failure of Goodix Probe. 

Any pointer how we can debug this issue?  We are booting linux-5.4 xip boot which is booting on a small memory system which is about 8mb mram. We tried PERF or FTRACE results in OOM Killer during the device init itself (verified through the log_buf).

Regards,
Pankaj Pandey

Kaiwan N Billimoria

unread,
Jul 14, 2024, 9:06:49 AM7/14/24
to Pankaj Pandey, kernel-meet...@googlegroups.com, Yogender Arya
Hi Pankaj,

Don't know if this will help, but have you tried passing the @gfp param of request_firmware_nowait() as GFP_ATOMIC (as opposed to GFP_KERNEL)?
The func header states that this ensures it "can't sleep at all"..


--
You received this message because you are subscribed to the Google Groups "Kernel Meetup Bangalore" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kernel-meetup-ban...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/kernel-meetup-bangalore/CAOdCjQu3DNgQxAZsbaCjW4c9zGBdN1U2HYMrAk%2B9S539D8jRxw%40mail.gmail.com.

Pankaj Pandey

unread,
Jul 14, 2024, 9:27:54 AM7/14/24
to Kaiwan N Billimoria, Yogender Arya, kernel-meet...@googlegroups.com
Thanks Kaiwan, will try GFP_ATOMIC.

Regards,
Pankaj Pandey
Reply all
Reply to author
Forward
0 new messages