[linux-dvb] Re: [video4linux-cvs] Add support for the Avermedia 777 DVB-T card

Hartmut Hackmann hartmut.hackmann at t-online.de
Mon Jan 30 22:45:18 CET 2006


Hi,

Michael Krufky wrote:
> Hartmut Hackmann wrote:
> 
>> Michael Krufky wrote:
>>
>>> This patch causes the following warnings during the build:
>>>
>>> saa7134-tvaudio.c: In function 'tvaudio_setmode':
>>> saa7134-tvaudio.c:309: warning: enumeration value 'TVAUDIO_AM_MONO' 
>>> not handled in switch
>>> saa7134-tvaudio.c: In function 'tvaudio_getstereo':
>>> saa7134-tvaudio.c:439: warning: enumeration value 'TVAUDIO_AM_MONO' 
>>> not handled in switch
>>> saa7134-tvaudio.c: In function 'tvaudio_setstereo':
>>> saa7134-tvaudio.c:505: warning: enumeration value 'TVAUDIO_AM_MONO' 
>>> not handled in switch
>>>
>> Sorry, my fault. This is due to an older change i forgot to commit.
>> I will do this this evening.
> 
> 
> Okay...
> 
>>> Why is all this tuner programming (below) hardcoded into the card 
>>> driver?  I've noticed a LOT of this in saa7134-dvb.c  Most of these 
>>> can be converted to use dvb-pll, and I see no reason why new code 
>>> should be accepted this way.  We are trying to have consistant 
>>> looking code, and this is counter-productive.  Please re-do this 
>>> function to use dvb-pll, so that other devices that have the same 
>>> tuner can share its programming.
>>>
>> This has historical / practical reasons.
>> 1) When i started extending the saa1734-dvb.c, there simply was no
>>    dvb-pll module. I simply did it the same was as it was i.e. in 
>> budget-ci.
>> 2) Philips recommends to initialize the RF AGC differently for analog TV
>>    and DVB. Appropriate functions are not jet in dvb-pll. This is the 
>> case
>>    i.e. for TU1216, TU1316, FMd1216ME.
>> 3) A whole bunch of the tuning code is for TDA8275(A). They require a
>>    programming *sequence* which isn't supported by dvb-pll either.
>>    Additionally, this chip has a very special IF interface and can only
>>    work with few channel decoders. It is not very likely that it will 
>> ever
>>    occur i.e. with a connexant PCI bridge.
>>
>> I also wish to remove as much much as possible of the PLL code from
>> saa7134-dvb. But since i need to extend the dvb-pll interface, i have to
>> go throught the big procedure with RFC and so on. I hope i can do this
>> this spring, together with a rework of the tda1004x api.
>>
>> The MT352 channel decoder has its own I2C master with the tuner attached
>> to it. This is why it needs a different tuning function. I submitted this
>> patch since i wish to do the movement to dvb-pll in one step.
>>
>> Accepting this for the time being does no harm. And sorry, my time is
>> limited, i can not do everything immedeately.
>>
>> Hartmut
> 
> 
> Fair enough...  Although I am curious..... Exactly what do you plan to 
> expand on in dvb-pll?  What fields do you need to add?
>
I would like to add 2 functions:
dvb_pll_init()
This should wake up the tuner and initialize it to DVB mode. And
dvb_pll_sleep()
which puts the tuner to sleep mode resp. puts it back to analog mode.
As far as i currently know, both could provide byte lists as the configure
function currently does.
You might not be aware of this: Some PLL chips have a 5th "hidden" programming
byte that is accessibe by writing a special value into byte 2. This is
what i wish / need to modify.

> I have been working on the tuner-simple structs and dvb-pll structs, in 
> an effort to make them similar to each other, such that eventually the 
> dvb-pll tuners can be stored in tuner.ko 's multi-standard tuner array.  
> Of course, I will not do this right away... There is a lot of 
> preparation that needs to be done on the analog side first, and I will 
> go through the RFC process as well before dvb-pll becomes involved...
> 
> However, I *do* request that any tuner code that isnt using dvb-pll 
> should be converted such that it will in the future.  I understand the 
> situation that you are describing, and I see why this must wait in the 
> case of saa7134-dvb, but we should try in cases where possible.  I'd 
> like to see some type of conformity here.
 >
Ok. But there still is the question "what do we do with the silicon
tuners". I currently see no way to handle these with a generic approach
like the ones in dvb-pll and tuner-simple. This holds for both, the
Philips as well as the Microtune chips.
> 
> Please look at the recent changes to the tuner-* stuff, for an idea 
> about what I'm talking about.  There are comments at the top of 
> tuner-types.c that describe the general idea of the changes that I am 
> working on.  Please let me know if you have any comments.
> 
Ok, i will do so.

> Regards,
> 
> Michael Krufky
> 
Best regards
    Hartmut



More information about the linux-dvb mailing list