Mailing List archive

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

[linux-dvb] Re: CX88 i2c issue w/ DVB tuners



Andrew de Quincey wrote:
On Friday 10 Sep 2004 11:50, Holger Waechtler wrote:

Andrew de Quincey wrote:

On Friday 10 Sep 2004 11:02, John Dalgliesh wrote:

On Fri, 10 Sep 2004, Andrew de Quincey wrote:

On Thursday 09 Sep 2004 23:41, Gerd Knorr wrote:

Just hope there isn't a card out there with both DVB AND analogue
tuners on it....
class isn't a value but a bitmask, so you can actually say the card
can do both analog and digital tv ...
Ah right cool. Eurgh, nasty problem waiting down the line when those
cards Holger mentioned appear.
I don't think I understand the condition you are worried about. Do you
mean that the card has to have two separate (i2c-addressable) tuners, one
for analogue and one for digital? Or would a card that has one tuner that
does both like <http://www.dvico.com/products_mul_hd3.html> be a worry?

Just wondering :)
If the card is marked as both analogue and digital, and happens to use
one of the i2c addresses which several devices use, you could end up with
the wrong i2c device associated with the wrong device - e.g. the tda9987
(analogue tuner) driver was being used incorrectly as the driver for the
cx22702 (digtial demodulator) because they both commonly reside at the
same i2c address. And theres no way to detect the tda9887 more
specifically.

Gah, if only Philips had mandated that all i2c devices must have a unique
32 bit identifier!
The i2c bus is well-designed for this particular purpose, it is the API
that does not matches the reality.

i2c devices are usually dumb tiny special chips that do a very special
job, which heavily depend on the hardware around them and how everything
is wired together. Not really the environment where autoprobing is a
good idea.

And there is no urge doing anything so complicated at all: all
infrastructure we need are two simple functions for every card's
i2c/SPI/8bit-parallel/whatever uC bus:

   int card->uC_write(u8 addr, const u8 *buf, int len);
   int card->uC_read(u8 addr, u8 *buf, int len);

This is enough to implement the access functions for a particular device:

   #define DEVICE_ADDR XXX

   static
   int device_writereg (u8 reg, u8 val)
   {
       u8 buf [] = { reg, val };
       return card->uC_write(DEVICE_ADDR, buf, sizeof(buf));
   }

   static
   int device_readreg (u8 reg, u8 *val)
   {
       u8 buf [] = { reg };
       int ret;
       if ((ret = card->uC_write(DEVICE_ADDR, buf, sizeof(buf))))
           return ret;
       return card->uC_read(DEVICE_ADDR, val, 1);
   }

These function pointers are passed to the frontend_spec struct (e.g.
mt312_cardspec) and from there together with the card-specific constants
and initialisation tables to the "frontend library" functions.

Yeah, that sounds good. So effectively the frontend drivers will cease to be kernel i2c devices. However, we'll still use the kernel i2c for the adapter's i2c buses if need be, so no one can complain we're duplicating stuff again. That makes sense - theres no point really in making the frontends generic devices usable by non-DVB code.

How will we prevent things like that tda9887 tuner from taking over our addresses on the bus accidentally if our bus is marked as ANALOGUE and DIGITAL? We should probably claim addresses on the bus that we use - but it all depends on what order things are loaded in.
I would not claim any addresses, why should we? Even registration to the kernel i2c API is optional (and only introduces delays and the risk of accidentally attached devices from other subsystems).

The generic i2c_read/write() implementations in the card drivers should allow writes to all addresses. If not we should fix them, we're maintaining them anyway. We also need to ensure they are correctly locking on the low level because we don't rely on the i2c layer locking mechanism anymore (but last time I checked most drivers implemented correct semaphores, so this should not really be a problem).

If properly done both systems can existence peacefully in coexistence and concurrent accesses are allowed (like it was the case for the dvb_i2c_bus code).

Holger




Home | Main Index | Thread Index