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 [EMAIL PROTECTED] -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
