From: "Oliver Endriss" <[EMAIL PROTECTED]> > Well, I found the reason for the high cpu load: > i2c_busy_rise_and_fall (saa7146.c) uses mdelay calls, i.e. busy-waiting. > Normally this is no problem, but it consumes 30% of the cpu power when > the frontend thread is unable to tune...
Hmm, I had mentioned this before. Try replacing the wait for the rise with an empty read of IICSTA. In my experience, only the first read of IICSTA will sometimes not indicate the correct busy states, but the second one is always correct. As to waiting for the transfer to complete, try increasing the I2C bus clock rate, 275kHz should work for all components and decrease the wait significantly. Then try if you can do entirely _without_ any delay or scheduler calls, i.e. a fully busy loop. This is preferrable for cases in which greater amounts of data need to be transferred. Such a case is e.g. the TDA10045H DSP firmware code upload, which takes only about 1 second when fully exploiting the 275kHz clock, but can take over a minute when scheduler calls are inserted... Aside from that, with a 275kHz clock a transfer finishes so fast that the overhead from rescheduling to other tasks might exceed the CPU load from the busy wait loop... Regards, -- Robert Schlabbach e-mail: [EMAIL PROTECTED] Berlin, Germany -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
