]> git.ipfire.org Git - thirdparty/linux.git/commit
i2c: designware: Support of controller with IC_EMPTYFIFO_HOLD_MASTER disabled
authorBenoît Monin <benoit.monin@bootlin.com>
Fri, 30 Jan 2026 15:52:31 +0000 (16:52 +0100)
committerAndi Shyti <andi.shyti@kernel.org>
Wed, 4 Feb 2026 01:16:22 +0000 (02:16 +0100)
commit5600722460880a16343484fbf5f90b02ff644719
tree56819505740401febcd377a9aa8523eabc1971cc
parent4a5aa00980131c2de520e6fe3fae9b8fe16f93a5
i2c: designware: Support of controller with IC_EMPTYFIFO_HOLD_MASTER disabled

If IC_EMPTYFIFO_HOLD_MASTER_EN parameter is 0, "Stop" and "Repeated Start"
bits in command register do not exist, thus it is impossible to send
several consecutive write messages in a single hardware batch. The
existing implementation worked with such configuration incorrectly:
all consecutive write messages are joined into a single message without
any Start/Stop or Repeated Start conditions. For example, the following
command:

    i2ctransfer -y 0 w1@0x55 0x00 w1@0x55 0x01

does the same as

    i2ctransfer -y 0 w2@0x55 0x00 0x01

In i2c_dw_msg_is_valid(), we ensure that we do not have such sequence
of messages requiring a RESTART, aborting the transfer on controller
that cannot emit them explicitly.

This behavior is activated by compatible entries because the state of
the IC_EMPTYFIFO_HOLD_MASTER_EN parameter cannot be detected at runtime.
The new flag emptyfifo_hold_master reflects the state of the parameter,
it is set to true for all controllers except those found in Mobileye
SoCs. For now, the controllers in Mobileye SoCs are the only ones known
to need the workaround. The behavior of the driver is left unmodified
for other controllers.

There is another possible problem with this controller configuration:
When the CPU is putting commands to the FIFO, this process must not be
interrupted because if FIFO buffer gets empty, the controller finishes
the I2C transaction and generates STOP condition on the bus.

If we continue writing the remainder of the message to the FIFO, the
controller will start emitting a new transaction with those data. This
turns a single message into multiple I2C transactions. To protect against
FIFO underrun, two changes are done:

First we flag the interrupt with IRQF_NO_THREAD, to prevent it from
running in a thread on PREEMPT-RT kernel. This ensures that we are
not interrupted when filling the FIFO as it is very time-senstive. For
example, being preempted after writing a single byte in the FIFO with
a 1MHz bus gives us only 18µs before an underrun. DMA would allow us
to keep the interrupt threaded but it is not available on Mobileye SoC
for I2C.

Second in i2c_dw_process_transfer(), we abort if a STOP is detected
while a read or a write is in progress. This can occur when processing
a message larger than the FIFO. In that case the message is processed in
parts, and rely on the TX EMPTY interrupt to refill the FIFO when it gets
below a threshold. If servicing this interrupt is delayed for too long,
it can trigger a FIFO underrun, thus an unwanted STOP.

Originally-by: Dmitry Guzman <dmitry.guzman@mobileye.com>
Signed-off-by: Benoît Monin <benoit.monin@bootlin.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20260130-i2c-dw-v6-3-08ca1e9ece07@bootlin.com
drivers/i2c/busses/i2c-designware-common.c
drivers/i2c/busses/i2c-designware-core.h
drivers/i2c/busses/i2c-designware-master.c
drivers/i2c/busses/i2c-designware-platdrv.c