[linux-dvb] [patch] dvb-bt8xx cleanup

[Manu Abraham]

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 
point ?

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.
> 
> Exactly. 
> 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
> file.

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.


Manu