Hello Roberto,
@Michael:Ok, I decided to *not* use the RPS for i2c communication. It would give little additional benefit over the current irq+waitqueue approach.
A conditional compilation about the use of a RPS for I2C comunication would be great, to save this precious resource!, for other applications.
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 [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.