[linux-dvb] Re: System load caused by I2C

[Roberto Deza <rdeza@unav.es>]

Hi Michael and all,

At 14:58 23/12/2002 +0100, Michael Hunold wrote:

>> @Michael:
>> A conditional compilation about the use of a RPS for I2C comunication 
>> would be great, to save this precious resource!, for other applications.
>
>Ok, I decided to *not* use the RPS for i2c communication. It would give 
>little additional benefit over the current irq+waitqueue approach.

Doubly great!, as the RPS remains free and by the real improvement on 
the I2C comunication, over the poolled (with sleep) approach.

>Let's assume that we need to transfer three i2c "packets", ie. three 
>writeouts of the i2c data register:
>
>With the irq+waitqueue approach we do:
>- write out register 1
>- enable i2c irq notification, go to sleep
>- get woken up by irq handler
>- check if everything is ok, write out register 2
>- enable i2c irq notification, go to sleep
>- get woken up by irq handler
>- check if everything is ok, write out register 3
>- enable i2c irq notification, go to sleep
>- get woken up by irq handler
>
>If I add additional logic to use the RPS we would get:
>- programm the rps
>- start rps, goto to sleep
>- get woken up by the irq handler
>
>This would save two irq handler->wake_up() calls, but -- hey -- i2c is 
>slow as hell anyway. The load is already decreased dramatically, because 
>we no longer busy sleep via mdelay().

Thanks by your explains and full agreed.

>But: for the above scheme, the steps 2 and 3 can be put into the 
>irq-handler, too, and we get woken up only after the whole transaction 
>has taken place.
>
>(Added this item to the TODO list...)

Still better :-).


Best regards:
--
Roberto Deza Asensio
Universidad de Navarra
Data Procesing Center
rdeza@unav.es


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.