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
