[linux-dvb] SAA7146 short delay flag and budget cards

Oliver Endriss o.endriss at gmx.de
Mon Sep 26 13:19:48 CEST 2005

hunold at linuxtv.org wrote:
> Johannes Stezenbach writes:
> > It looks to me like SAA7146_I2C_SHORT_DELAY should be safe
> > for all cards? Looking at saa7146_i2c.c it seems the worst
> > which could happen is that with some slow i2c devices it
> > would wast some CPU? Why does SAA7146_I2C_SHORT_DELAY
> > exist in the first place? Why does the short_delay flag
> > depend on the result of saa7146_i2c_msg_prepare()?
> First of all, I did not add "short_delay" to that code. ;-) 

I did, see below.

> In theory, i2c transfers with the saa7146 can be interrupt-driven. The 
> transfer is started, the caller goes to sleep, remaining transfers are 
> continued from the interrupt handler. After the last transfer, the caller 
> wakes up, ok. 
> This does not work with DVB cards because i2c interrupts seem to screw up 
> GPIO and/or DEBI interrupts, I don't remember which exactly. 
> So DVB cards use polling. The saa7146 transfers 3 bytes of i2c data at a 
> time. It seems that if one i2c transfer would take more than 9 bytes to 
> transfer ("count" * 3 bytes), then short_delay is set. 
> After a chunk of 3 bytes has been written to the saa7146 i2c transfer 
> engine, the device must be polled in order to see if the next chunk can be 
> written. If short_delay is *not* set, it will uses a msleep(1) to do this 
> waiting. The problem is that reading out the status after the transfer has 
> just been started always gives "busy". In theory you can calculate the time 
> needed to wait by looking at the i2c transmission rate selected. Because you 
> usually send only a handful of bytes, this is usually overkill. 
> IIRC short_delay was introduced to speed up firmware uploads via i2c. There, 
> waiting for 1ms after every 3 bytes will slow down your firmware upload 
> tremendously. 
> > Comments?
> Setting SAA7146_I2C_SHORT_DELAY should be ok for every card that uses 
> polling. It will only take effect, if more than 9 bytes of i2c data are 
> transferred though. I don't know why this limit was chosen. 

Sorry, this is not correct. SAA7146_I2C_SHORT_DELAY turns on polling for
_all_ transfers. (That's the reason why it had been added.)

|       if ( count > 3 || 0 != (SAA7146_I2C_SHORT_DELAY & dev->ext->flags) )
|                short_delay = 1;

SAA7146_I2C_SHORT_DELAY was introduced by me because tuning with FF
cards was rather slow. From Changelog:

| 2003-11-25 20:13  endriss
|         * linux/: drivers/media/common/saa7146_i2c.c,
|          drivers/media/dvb/ttpci/av7110.c, include/media/saa7146.h:
|          introduced flag SAA7146_I2C_SHORT_DELAY to speed up I2C access

Before that, only larger transfers used polling. Since DVB cards use a
lot of small i2c transfers there was noticeable delay during tuning.

Imho the flag SAA7146_I2C_SHORT_DELAY should be added for all
saa7146-based cards.


VDR Remote Plugin available at

More information about the linux-dvb mailing list