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

[Michael Krufky]

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

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.

Regards,

Michael Krufky