On Fri, Apr 27, 2012 at 11:37 PM, Konstantin Dimitrov <kosio.dimitrov@xxxxxxxxx> wrote: > hi Mauro, > > in the mean time i was actually pointed out that there is 3rd party > tuner that is proved to work in practice with both Montage ds3k > demodulator family, as well ST STV090x demods, i.e. there are such > reference designs. so, the split further makes sense and in fact that > should be make in way that both drivers for STV090x and Montage ds3k > demodulator family can share tuners with each other. so, that's just > note for the upcoming review of the patches i will submit - in short > the split of Montage tuner and demodulator code i will make it in the > same fashion as how the driver code for ST 6100/6110 tuner are split > from STV090x driver, because that now, as i've just mentioned, makes > sense from practical point of view since of the 3rd party tuner for > which there is reference designs with both STV090x and Montage > demodulator. also, that way STB0899, STV090x and Montage demodulator > drivers can be used together with any other of the DVB-S2 tuners > available in the kernel - ST 6100 and 6110 and soon TS2020. > > however, i want to pointed out few other problems - they are off-topic > as not related to drivers for Montage chips, but related as far as > we're putting some order and making things in a proper way and those > those things are out of that order: > > - there are 2 drivers for the same DVB-S2 tuner: ST 6110, respectively > "stv6110.c" and "stv6110x.c" > > - there are 2 drivers for the same DVB-S2 demodulator family: > respectively stv090x* and stv0900* > > the above couldn't be more wrong - in fact i can submit patches to > make all drivers that relies on stv090x* and "stv6110.c" to use > stv090x* and "stv6110x.c" instead except the NetUP board, for which in > my opinion someone should submit patches using stv090x* and > "stv6110x.c" and subsequently stv090x* and "stv6110.c" be removed - to correct a typo: and subsequently stv0900* and "stv6110.c" be removed > unless someone have some real argument why stv090x* and "stv6110.c" the same: unless someone have some real argument why stv0900* and "stv6110.c" > should stay or even if for why they should replace stv090x* and > "stv6110x.c" and subsequently stv090x* and "stv6110x.c" be removed > instead. so, the case with ST 6110 and STV090x support is the most > frustrating and out of order thing that i can indicate regarding the > support of DVB-S2 chips in the kernel and i hope you will take care as > maintainer to be resolved or at least someone to explain why the > current state is like that - or point me out to explanation if such > was already made to the mailing list. so, what i'm suggesting is > "spring cleaning" of all DVB-S2 tuner/demodulator drivers in the > kernel - if it's not done now in the future the mess will only > increase. > > thank you, > konstantin > > On Fri, Apr 27, 2012 at 10:36 PM, Mauro Carvalho Chehab > <mchehab@xxxxxxxxxx> wrote: >> Hi Konstantin, >> >> Em 27-04-2012 16:01, Konstantin Dimitrov escreveu: >>> Mauro, your reasoning makes sense to me. so, let's split them and at >>> least settle this part of the discussion - i will do as far as my >>> spare time allows, as well make sure there are no some problems >>> introduced after the split. >> >> Thank you! >> >>> also, in one email i've just sent in answer to Antti there is enough >>> argument why such split, i.e. tuner-pass-through-mode is subject to >>> discussion about CX24116 and TDA10071 drivers too. currently, majority >>> of DVB-S2 demodulator drivers in the kernel are married to particular >>> tuners and there is no split. >> >> Besides the reasoning I gave you, having the tuner and the demod on separate >> drivers help a lot code reviewers to check what's happening inside the code, >> because the code on each driver becomes more coincide and the two different >> functions become more decoupled, with reduces the code complexity. So, bugs >> tend to be reduced and they're easier to fix, especially when someone need >> to fix bad things at the dvb core. >> >> Also, as almost all drivers are like that, it is easier to identify driver >> patterns, especially when newer patches are adding extra functionality there. >> >> Thanks! >> Mauro >> -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
