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
