hunold@xxxxxxxxxxx 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).
Thanks,
Johannes
