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

Johannes Stezenbach js at linuxtv.org
Mon Sep 26 13:33:53 CEST 2005

hunold at linuxtv.org wrote:
> 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. 

Hm. You mean a hw bug, or some yet-to-be-fixed sw bug?

> 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. 

Nah, SAA7146_I2C_SHORT_DELAY will override short_delay for short
messages (long msgs will always be transferred with short_delay=1).


More information about the linux-dvb mailing list