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
