Kenneth Aafl?y wrote: > On Friday 11 March 2005 09:16, you wrote: > >>Kenneth Aafl?y wrote: >> >>>I've attached a patch for dvb-bt8xx that I wish to commit. >>> >>>I've moved the card specific bttv cruft out of the dst frontend module, >>>so that it can be moved to the other frontends. >> >>Kenneth, the dst is not a frontend and moving it to other frontends will >>"hinder" the functionality of the card. The frontend is hardware based, >>and *no* software drivers for it AFAIK, nor the manufacturer. It is very >>much card specific and hence the structure. > > > The dst code certainly registers a frontend device, so hence it's a frontend. 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. 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. What i emphasise, is that trying to split it up as a frontend is going to remove a lot of functionality. I can only say this, I am not supposed to make any documents, regarding this public. :-( So you have any suggestion how to go about, without registering a frontend ? If so, that would be the right approach ? I tried that sometime back, but my lack of understanding how to proceed even with the documents have made me proceed in this direction. Any suggestions that you might have would be valuable in this aspect, but i would have to wait a bit to implement that , considering taht i am workin hard to get it working in certain aspects.. > It's not embedded on the bt878 either, so the possibility of it appearing > in concert with another chip is at least not impossible. > > You cannot state that very explicitly considering all the details. It is, well in a way heavily tied up with the bt878. Looking at the schematics and other details and documentation from the manufacturer, it extremely difficult to say that, but even for the manufacturer to have a similar bridge would be very difficult. but i feel that eventhough there would be interface differences , i mean the pin config differences, the 878 bridge would be there i believe. If the manufacturer decides to have a different chip, that would mean an entirely different bridge. In that case it would be easier to write a new driver altogether. >>>Made bt878.c be part of the dvb-bt8xx-pci driver, since there are no other >>>users of this module, at least as far as I know. >>> >> >>I created a twinhan-exp branch on the CVS and plan to move the >>development over there .. >>There are dst specific parts in the dvb-bt8xx module as it is a 878 >>based card, and not being a frontend, moving *any* dst specific code out >>of dvb-bt8xx would make my work irrelevant. > > > 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. > >>It is very difficult for people to understand the driver, *without >>knowing what the hardware is*. The changes that was happening quite >>often, made my work *very difficult on the dst module*, especially >>frontend refactoring. > > > Ok, It's only an hour of work, let me know when I can start poking the > driver again.. > My patches are almost 8 months old, but people have been testing it out for 2 ~ 3 months with various good and bad results. Sure, i have created an experimental tree (teinahn-exp) yesterday. Working on the driver, in a proper shape can be a real nightmare with the hardware features. What i intend to do as people test out the experimental code, i can keep merging it into MAIN. That was what even Johannes and Patrick were suggesting.. It would be nightmare if everything goes into MAIN straightaway, since what works for one will not work for another. This we have seen quite recently on the list.. > >>I wasted quite a lot of time to get the module working *properly* at >>least for me, after fe refactoring.... >> >>I don't want to have the burden of a very expensive mistake again.... > > > Well, it's going to happen, the driver is very messy compared to the other pci > drivers. > When the hardware itself is messy, what can you say about the driver.. ? Anyway i am doing a huge cleanup/rewrite.. Have you seen my previous patches ? The reason why i did not commit the code was the same reason, there are too many cards out there, once you make a change, many cards that do work will stop working The messy code is due to the difference in the architecture of the card, trying to force the driver architecture to follow a standard concept, will only lead to a driver that has less features on the hardware.. Well, i don't think anything really much can be done to the messy code at this point of time, when i am trying to get things working. Don't you feel that a working driver is more acceptable than a broken driver with nice code ? Manu
