Mailing List archive

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

[linux-dvb] Re: Busy waiting in i2c_busy_rise_and_fall (was: Re: Re: full featured card without signal and required video memory investigation)



From: "Oliver Endriss" <o.endriss@gmx.de>
> 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: robert_s@gmx.net
Berlin, Germany



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



Home | Main Index | Thread Index