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 - unless someone have some real argument why stv090x* 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
