Integrate linux-imx-kuk/i2c_imx_isr_read_fsl
-- 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 5. The i2c driver becomes scheduled again and reads the byte 6. 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
parent
7c4c771f
No related branches found
No related tags found
Please register or sign in to comment