[linux-dvb] [patch] dvb-bt8xx cleanup
manu at kromtek.com
Fri Mar 11 13:59:06 CET 2005
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
> 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
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
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
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 ?
More information about the linux-dvb