[linux-dvb] [patch] dvb-bt8xx cleanup
manu at kromtek.com
Fri Mar 11 15:16:56 CET 2005
Ralph Metzler wrote:
> Manu Abraham writes:
> > No that is wrong.. That was because Jamie originally made dummy frontend
> > routines for the dst, and thereby somebody who moved the code around,
> > without the idea, thought the dst was a frontend driver. Many people do
> > think that the dst is a frontend. *This was actually wrong*.
> > There might be more dst hardware, that we have not seen yet ! I have one
> > such thing, which i am yet to get the driver moving, but waiting to
> > finish upon this.
> Yes, there is. The Twinhan DVB-S USB hardware uses the same kind of
> messages to the frontend, just via USB instead of the Bt878 I2C port.
The USB devices are also the same in the sense it is considered as a
STB. The difference, the interface is USB.
So do you mean the USB stuff also should be mixed into this mess at this
Or if you think that would be the way to go, i would make the changes as
dst_high_level and dst_low_level ?
> > As per what you state, then the CA features and the rest of the other
> > features will also be in the frontend, which is not the case as per the
> > linux DVB API.
> One would need another layer with a "Twinhan command protocol" and the card
> driver only supplies the I2C, USB, etc. interface. This is kind of
> overkill right now when all cards on the market with this protocol are
> Bt878 based (or is the DVB-S USB adapter available?).
I had thought about a different layer (but did not consider the USB
devices), considering the new PCI devices having multiple sessions..
I was wondering how exactly to tackle that one.. since all the devices
were common in one aspect.
But at this point do we really need an additional layer ? As you said
wouldn't it be an overkill ?
I think the devices are outgrowing the API too fast than expected..
> In any case I would still keep the frontend and CA code for Twinhan in one
I was planning to have one more addons, since some modules have
different initializations periods, and a change in them leads to
read/write errors, as you have seen earlier with my code, but the same
with a proper initialization period worked out beautifully.
And i thought it would be better to have addons separate, such that
others who do not have that hardware need not be taxed, as Johannes
suggested, seemed logical to me
When a lot of people have different hardware, wouldn't it be better to
have only the necessary stuff loaded up rather than all the kernel data ?
and moreover the long code inside one single file was making me too
uncomfortable.. Hence i did split up.
My first code had everything in one file, and the CA ioctl's were too in
the frontend driver, later on i split it up as you have seen already.
> > > You should have a look at the budget-core driver and the associated
> > > sub drivers, they all do the same as this.
> > >
> > Nope.. It is totally different.. I too thought like that before i laid
> > my hands on the documents awhile back.
> Yes, the other cards are different because they still give access to the
> actual frontend I2C bus. The Twinhan cards hide this behind another
> abstraction layer.
True, the i2c for Twinhan is a pseudo bus, when you look at it
initially, but a real one does exist in hardware.. behind the interface.
Even the hardware has some level of abstraction.
More information about the linux-dvb