Mailing List archive

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

[linux-dvb] Re: cx88 dvb modification



On Friday 10 Sep 2004 10:40, Andrew de Quincey wrote:
> On Friday 10 Sep 2004 10:13, Andrew de Quincey wrote:
> > On Thursday 09 Sep 2004 23:54, Gerd Knorr wrote:
> > > > The cx88 however, sets these to "cx88[0]" - which is unfortunately
> > > > not useful for the above purpose - and theres no other way of doing
> > > > it.
> > >
> > > We should add one then.  For analog TV there is the tuner_type field
> > > which is passed to tuner.o using some ->command() call.  We can (and
> > > IMHO should) do that for digital tv cards as well, just matching the
> > > name of the card is a bad idea.
> > >
> > > The cx88 driver can easily figure more details on the card if needed.
> > > For analog tv thats actually needed as for example the hauppauge wintv
> > > cards may have have different tuners.  cx88 can figure that by checking
> > > the eeprom with the config info, tuner.o can't do that ...
> > >
> > > >  static int dvb_register(struct cx8802_dev *dev)
> > > >
> > > > +
> > > > strlcpy(dev->core->i2c_adap.name,cx88_boards[dev->core->board].name,s
> > > >iz eo f(dev->core->i2c_adap.name));
> > >
> > > No way.  That simply isn't the right place to mess with the name
> > > of the i2c device.  And as mentioned above IMHO messing with the
> > > name for configuration is a bad idea in the first place.
> > >
> > > > + result = dvb_register_adapter(&dev->core->dvb_adapter,
> > > > cx88_boards[dev->core->board].name,
> > >
> > > Same for this one.
> >
> > I suggested adding a field like your "board" identifier to the DVB
> > adapters months ago - people rejected it. Therefore I have to use the
> > device name.
>
> The way I would see it working would be for each piece of hardware to
> supply a list of the IDS of frontends/tuners drivers it expects to see in
> its init function. The i2c probing code then only tests those. So the
> hardware driver is free to probe EEPROMs or whatever to determine its
> frontend (if it can) and simply supply the id of the one it has chosen, or
> a list if it cannot.
>
> Of course this would mean all i2c devices had a separate id - currently all
> the DVB ones are defined to be "I2C_DRIVERID_EXP2".

On second thoughts - this won't work either with the frontends in their 
current state. The frontends have to know which hardware they're on to choose 
certain parameters (since manufacturers wire them all up differently). 

The userspace library idea suddenly looks much more attractive - but it would 
still need to be combined with the i2c device lists to avoid clashes.




Home | Main Index | Thread Index