Hi, On Wed, Oct 23, 2002 at 12:01:48PM +0200, Florian Schirmer wrote: > > we're currently porting all our D-BOX2 driver to the NEWSTRUCT API's and > running into major problems with the new i2c layer.
NEWSTRUCT is history... We were trying to push the DVB API/framework and our favourite driver into the 2.5 kernel, and cleaned up some type naming issues. See http://linuxtv.org/mailinglists/linux-dvb/2002/10-2002/msg00183.html The script attached there can be used to help porting your sources to the new API. > The i2c layer works pretty well as long as the i2c adapter is part of the dvb > adapter. On our STB there are three i2c controller. Two of them are not part > of the dvb adapter and so not under the control of the dvb i2c layer. > > The frontends of our STB are attached to one of the "external" i2c adapters. > Because of this we are running into problems when attaching the frontends to > the dvb adapter. > > Currently i'm not aware of any possible workaround for this situation. We've > tried to register a dummy i2c bus at the dvb i2c layer. Then fe's can > properly attach to the dvb adapter. But we have to deal with the i2c messages > ourself. And there is no way to enumerate the availible i2c busses on the > linux i2c api. So we dont can't send the messages inside the dummy i2c bus > xfer_msg proc. > > To work around this problem again we have to register the frontend to the > linux i2c layer too, as soon it is attached to our dummy dvb i2c bus. > > This is a very ugly hack. Maybe there is a smarter solution to this kind of > problem. It would be nice if someone can elaborate on this subject. Well, the Linux I2C subsystem has the problem that when you register a frontend driver, it will probe for the frontend on all known I2C busses. This causes some long timeouts when you have e.g. a Matrox graphics card and enabled Matrox I2C support. The DVB driver should be able to tell the I2C subsystem to probe for frontends only on a specific I2C bus. (The frontend drivers are the same for all systems, so they know nothing about the busses.) Maybe Holger knows a solution? > Another simple question: > > FE_CAN_FEC_x_y does it tell the api the fe can do fec x/y or does it tell the > fe can be forced to operate in fec x/y mode. We've a fe which is able to do > fec x/y but can only operate in auto fec mode. So do we need to set > FE_CAN_FEC_x_y AND FE_CAN_FEC_AUTO or just FE_CAN_FEC_AUTO? Both, so that an application can see whether the frontend can lock on signals with e.g. FEC_8_9 or not. Regards, Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
