From: Mark W. <mar...@np...> - 2005-09-30 19:42:51
|
> lirc_dev has to poll the I2C bus for new IR signals. I'm surprised that > the cpu load is that high (if the given number is really accurate is a > different story). > If you don't like it, then fix it and send patches. > It sounds like the I2C driver is using i2c-algo-bit. This basically drives the I2C clock and data lines itself at the appropriate frequency (as set by the I2C adapter, e.g. a TV card driver), and uses udelays to wait for clock transitions. Since these are timed busy loops, and CPU load is measured over a particular time, it's not really a surprise that it takes a constant fraction of CPU time. Speeding up the CPU won't help of course -- it will just whizz around the busy loop faster. For example I have had a Hauppauge PVR-150 in an Athlon 1600+ and a Sempron 2800+ box and lirc_i2c takes about 1% of the CPU to poll in either of them. The ivtv udelay is 10us, and you get that twice per bit. The chip returns 6 bytes of data, so roughly (ignoring the details of the I2C protocol), we have 6*20*8 = 960us ~ 1ms of udelay. Polling rate is 10Hz, so that makes ~10ms of busy loop per second, which is 1%. |