Mailing List archive

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

[linux-dvb] Re: Proposal for new frontend architecture



Am Di, den 21.09.2004 schrieb Michael Hunold um 16:55:
> Do the MPC8xx and/or IBM4xx platforms already support kernel i2c?

Yes. 
http://linux.bkbits.net:8080/linux-2.5/anno/drivers/i2c/busses/i2c-ibm_iic.c@1.11?nav=index.html|src/|src/drivers|src/drivers/i2c|src/drivers/i2c/busses|hist/drivers/i2c/busses/i2c-ibm_iic.c|diffs/drivers/i2c/busses/i2c-ibm_iic.c@1.11

The 8xx driver is not yet in mainline, but I would really like to get
our driver there in the future.

http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/driver/i2c/dbox2_i2c.c?rev=1.28&content-type=text/vnd.viewcvs-markup

I especially don't like the patch required for dvb-core's FE_REGISTER
stuff:

http://www.fbihome.de/~obi/2.6/i2c.diff

> On 21.09.2004 16:35, Andreas Oberritter wrote:
> > Well, I dislike using "I2C commands" for the following reason: On
> > embedded STBs the I2C bus is usually not bound to a PCI/USB device like
> > in the PC world.
> 
> Does this matter? It's simply "there" isn't it?
> 
> If the frontend drivers asks you "can the stv0299 frontend be found on 
> your system at all?" then you can simply have a look-up in some device 
> table and tell the frontend to continue or stop.
> 
> In case of the dvb-ttpci, this device table includes the pci ids, but 
> for the dbox it can simply be a static list.

Since these PowerPC CPUs provide the I2C bus the driver does not know
whether it is used on a set top box or on some kind of other device. 

> > You can use the in-kernel drivers for the MPC8xx and
> > IBM4xx platforms for example. With this API change (and also the
> > previous FE_REGISTER/UNREGISTER commands) you will have to patch these
> > I2C drivers in a way which will never be accepted by the kernel folks.
> > (e.g. #if defined(CONFIG_DBOX2)
> 
> I don't understand that, sorry. 8-(
> 
> Why do the frontends drivers have to be cluttered with #ifdefs?

Not the frontend driver but the kernel i2c driver would need these
ifdefs.

> > then make 8xx-i2c depend on dvb, include
> > the necessary headers and have a lot of knowledge about the 6 different
> > dbox2 frontends and their PLLs *inside* the generic mpc8xx i2c driver.)
> 
> No, the knowledge is inside the mpc8xx main driver that handles the 
> kernel i2c callback functions like client_register() (when a client has 
> attached), client_unregister() and the new born command().
> 
> You can implement a generic mpc8xx i2c driver that provides the i2c 
> algorithm, then register an i2c_adapter inside the core dbox2 mpc8xx 
> driver which additionally provides the callback functions. (I hope I got 
> this right)

The i2c adapter is system wide and already registered at bootup.

> Where are the necessary h/w dependend informations now?

We are using the old dvb_i2c on the dbox2, because 2.6 is still unstable
on 8xx. The dbox2 manufacturer is identified on system bootup. Userspace
then knows which frontend modules to load. Satellite/Cable frontends are
probed on the i2c bus.

> > Will support for non-PCI and non-USB devices be dropped?
> 
> No, why do you think so? It's about kernel i2c, which is completely 
> independend of PCI and USB. If your device supports kernel i2c, you'll 
> only need to move the frontend specific data from the frontend to the 
> kernel i2c callback functions in your driver.

That's the problem. The driver must not know anything about DVB, because
it is a CPU driver and not a DVB driver.

Regards,
Andreas






Home | Main Index | Thread Index