Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hello Roberto,

> @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.

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().

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...)

CU
Michael.



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



Home | Main Index | Thread Index