[linux-dvb] Re: [PATCH] Coding style for skystar2.c (both DVBand dvb-kernel)

[Holger Waechtler <holger@convergence.de>]

Ralph Metzler wrote:
> Holger Waechtler writes:
>  > the dst_frontend driver (and the dec2000_frontend driver too) are 
>  > pseudo-i2c device drivers. This makes no sense for these cards since the 
>  > driver is working only in conjunction with the dst.o and ttusb_dec.o 
>  > driver. As the implement the general attach/detach and 
>  > register_i2c_device callbacks they get probed for every card - this does 
>  > not makes much sense, right?
>
> Correct.
>  
>  > Instead it would be simpler and easier when the dvb_register_frontend() 
>  > function would get called directly inside dst.o and ttusb_dec.o and no 
>  > i2c bus would get registered via dvb_register_i2c_bus(). The struct 
>  > dvb_i2c_bus pointer for dvb_register_frontend() can easily get faked.
>
> Actually, there is not even any need for dvb_frontend.[ch] to depend on I2C at all.
> This can be handled by only passing the adapter struct and a generic 
> private data pointer. 
> There are also dependencies on dvb_frontend.h in drivers with frontend
> callbacks which do not really need the frontend structure itself.
> If none of the drivers need it these dependencies could be removed as
> well.
yes, right now dvb_frontend.[hc] is mostly a collection of helper 
functions for old and not really reliable hardware, the new demodulators 
which can handle recovery and status checks in hardware or using their 
onboar/onchip controller can do this on their own. Especially when they 
can throw interrupts to notify the host that some status changed -- 
these interrupt lines are independent from i2c anyway.

The old i2c/frontend infrastructure makes mostly sense for the 
ves18xx/stv099 class of demodulators.

Holger



--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.