Hi, > 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.
Doh. This was a naming issue. No idea how to call the current api. Maybe newapi :D Sorry for the trouble. We're aware of the current state and are using the dvb-kernel tree of the linuxtv.org cvs. http://cvs.berlios.de/cgi-bin/viewcvs.cgi/tuxbox/driver/dvb/drivers/media/dvb/ There you will find a (currently not working) snapshot of your efford to port to the newapi. There is a dummy frontend and adapter driver which might be helpfull for others trying to understand how it works. It is currently under development and far from beeing complete. > 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.) Thats true. At least it would be fine to have such a situation ;) > Maybe Holger knows a solution? Hope so! I've a vague idea on how to fix the problem in a much cleaner way. I will try to elaborate but dont know if this even will work: My idea is to extend the dvb_i2c layer with some kind of gateway/bridge to the linux i2c layer. dvb_i2c will try to probe its internal busses first and then fallback to linux i2c if no devices could be attached. Would you accept a patch for that? This will result in a dependency to the i2c_core. If a dependency is not acceptable it is possible to make it a compile time option. This opens up another question: Is there a required module load order? Frist fe's then adapters or the other way round? Or no required order at all? Thanks for your helpfull reply! Regards, Florian Schirmer -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
