Mailing List archive

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

[linux-dvb] Re: refactoring



On Sunday 10 Oct 2004 19:34, Gerd Knorr wrote:
> > >a *good* linux driver, with full suspend+sysfs support, and I simply
> > >have to use the kernel i2c infrastructure for that.
> >
> > no, you don't have to.
>
> I do, otherwise I don't get device nodes for my i2c devices.
>
> > Finish the dvbdev sysfs implementation and you will get proper sysfs
> > nodes even for you demod, decoder and networking devices, not only for
> > the frontend.
>
> dvb core will care about the stuff below /sys/class/dvb/  That isn't the
> whole story through.  The devices registered there usually have a device
> and a driver symlink pointing into the /sys/devices tree and to
> /sys/bus/<bustype>/drivers/<drivername>.  I must register the fe driver
> and the physical device within the sysfs tree to be able to get these.
> And for that I need a i2c_client per i2c device,
>
> Having a struct device* pointer within the new struct dvb_fe would be a
> good thing.  dvb_register_frontend() can correctly register the physical
> device for /sys/class/dvb/dvb.frontent then.

I'm not convinced representing the "frontend" as the demodulator's i2c_client 
in sysfs is good, although I do agree we need *a* device in sysfs to 
represent the frontend.

The demodulator is only part of the story.. as everyone knows by now :) most 
cards have extra glue hardware that together with the demodulator is the 
"frontend". This is the PLL, which is _usually_ i2c (not always!) and also 
some extra random stuff controlled by GPIO lines coming off one (or more) of 
the chips.

Ideally, what I would want is to have the main DVB adapter, then under that, 
DVB-specific frontend device(s) -  a new _type_ of device. Any frontend 
configuration files/power management stuff is then attached to those entries 
so that the card can bring up the frontend in its entirety in one go. This 
also allows for frontends attached to proprietary weirdy buses that have no 
standard kernel representation.

To me, exposing the different bits making up the "frontend" is wrong - it 
should conceptually just be the one device. If we expose the demodulator as 
an i2c_client, then shouldn't we also expose all the other i2c devices for 
consistency? (e.g. the PLL). I don't like that at all.

Anyway, lemme know your thoughts - I'm gonna get on with the enhanced function 
pointer API stuff.




Home | Main Index | Thread Index