Skip to content

Integrate linux-imx-kuk/i2c_imx_isr_read_fsl

GitBot requested to merge integrate/linux-imx-kuk/i2c_imx_isr_read_fsl/into/kirkstone into kirkstone

Commit: seco-ne/kernel/linux-imx-kuk@a6646c02

arm:dts:imx6qdl-san: Enable i2c msg read within ISR for bus 3

Some connected touches lead to a large traffic on the bus. If this traffic is handled too slowly, some ugly effects show up, such as input delays or a high CPU load due to the touch driver. Set the enable-isr-read flag to speed up the message read process.

Cherry-picked from 52d249fcd8ff14c01bce0b4049613b11c779426e https://git.seco.com/seco-ne/kernel/linux-guf

BCS 746-001477 746-001000

--

Commit: seco-ne/kernel/linux-imx-kuk@8ab02e4d

drivers:i2c-imx: Add option for i2c read processing within ISR

By default the read msg process is handled by the follwing queue mechanism:

  1. Client driver read request
  2. The i2c driver triggers a read and waits for a byte to be ready to read
  3. ISR sends a wake_up call to the queue when the byte is ready to read
  4. The i2c driver becomes scheduled again and reads the byte
  5. The i2c driver waits for the next byte and so on

For some reason, it often takes a long time to reschedule the i2c driver after the ISR reports ready status. This causes problems with i2c devices that cause a lot of bus traffic, such as touch devices. To resolve this, the devicetree flag "enable-i2c-isr" enables the following read routine:

  1. Client driver read request
  2. The i2c driver triggers a read and waits for the ISR
  3. The ISR reads the bytes itself and wakes up the queue when all bytes are processed

This way the wake_up calls are reduced by the number of bytes in a message and processing becomes much faster. However the ISR does more, but adding something that controls the scheduling of the i2c driver also seems to be very complicated.

Cherry-picked from 850be496c49aeca59bf9caa295a939d39fb4dbec https://git.seco.com/seco-ne/kernel/linux-guf

BCS 746-001477 746-001000

Merge request reports