Em Thu, 22 Jun 2017 23:35:27 +0200 Ralph Metzler <rjkm@xxxxxxxxxxxxxx> escreveu: > Daniel Scheller writes: > > Am Tue, 20 Jun 2017 16:10:43 -0300 > > schrieb Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxxxxx>: > > ... > > > > - Maybe for 4.14: Support for the CineS2 V7 and FlexV4 line of > > > > cards/modules. This mainly involves a new demod driver (stv0910) and > > > > a new tuner driver (stv6111). Permissions for this are cleared with > > > > Ralph already. The glue code needed in ddbridge is rather easy, and > > > > as some ground work (mostly the MachXO2 support from the 2841 series) > > > > is now in, the changes are quite small. Patches are ready so far but > > > > need more cleanup (checkpatch fixes, camel case and such things). > > > > > > Please try to sync it with Ralph, in a way that his code won't > > > diverge from the upstream one, as this will make easier for both > > > sides to keep the Kernel in track with driver improvements. > > > > This is not going to work. DD (Ralph and Manfred Voelkel) sort of maintain a shared code base between their Windows driver and the Linux kernel driver sources. While they didn't explicitely stated this, this can be noticed by the remarks and commented code in their OSS code, and the commit messages in their dddvb GIT (e.g. "sync with windows driver"). I've already cleaned up a lot of this (I believe no one wants to see such stuff in the linux kernel tree). If we're additionally going to replace all things camel case, with some more cleaning and maybe code shuffling after like a V4 patch series, those two sources are out of sync in a way that no automatic sync by applying patches will be possible anymore. So, pushing from vendor's upstream to the kernel seems to be the only option, and in fact, if the whole driver/package stack completely lives in the kernel sources, maybe DD even decide to directly commit upstream (kernel) again. Ralph, do you share Linux code with Windows, or are you just getting drivers from the manufacturer and converting them to Linux at dddvb tree? Would it be possible to change things at the dddvb tree to make it to use our coding style (for example, replacing CamelCase by the kernel_style), in order to minimize the amount of work to sync from your tree? > > > > Putting Ralph into "To:", really like to hear an opinion from him on this whole subject. > > Regarding divergence in the tuner/demod drivers I see some concerns. > The TDA18212 driver as they are presently in kernel and Daniel's github tree still seems to be missing features > like calibration and spur avoidance. This problem was already discussed here a few years ago. > I would not want to move to these versions if those features are still missing. I don't see any issue on adding the missing features to the existing tda18212 driver. Maybe Daniel can help adding the missing features there. The best would be to make those new features opt-in, in order to allow drivers to gradually use them (after tests), avoiding regressions. > I also already told Daniel about our concerns regarding the CXD drivers in private mail. > Sony did not want us to use their code directly and we had to get our code approved > before publishing it. I do not know how the arrangement is regarding the in-kernel driver. > DVB-C2 support also seems to be missing in this. Sony recently started submitting CXD drivers to us directly (for cxd2880). The upstream verson for cx2841 came from NetUP. I guess they develop the drivers themselves, but not really sure. Perhaps we can ask Sony's help to make easier add the features that are missing at the existing driver in a way that DDbridge could also use the upstream driver, or to do some other sort of agreement that would make possible for us to use the same driver as you at the upstream Kernel. (c/c Takiguchi-san and Tim Bird from Sony) > > > - you'll still need to patch DD tree, as I'm pretty sure there are > > > changes on the upstream driver that will need to be ported there; > > > > The same as for the stv0910 code applies here, in addition that it's not sure if DD even wants this. DD even has KERNEL_VERSION_CODE ifdefs in some places. And - most importantly - they carry around an old version of the DVB core API (from what it looks, around linux-3.10, not exactly sure) which even was modified by some IOCTLs, vars, defines and the netstream and modulator support. I managed to remove all core API change deps from everything tuner related (and thats the reason things work in harmony with and in current kernels), but getting all this over to DD or even merge things from DD into the media subsystem will get "interesting". > > We certainly will want to keep supporting older kernels via KERNEL_VERSION. In the past, we used a script that "solves" KERNEL_VERSION on our Mercurial tree (https://linuxtv.org/hg/v4l-dvb) and gets rid of other ifdefs: https://linuxtv.org/hg/v4l-dvb/file/3724e93f7af5/v4l/scripts/gentree.pl I don't use it for ages, but I guess it shouldn't be hard to modify it to get rid of KERNEL_VERSION when submitting stuff from DD tree upstream. Alternatively, DDbridge could use, instead, a modified version of media-build tree in order to support backports. > But I can change the dvb core version in dddvb to a newer version. > > Also, some of the new tuning defines and properties are generally useful and > should be added to the kernel. > > e.g.: > > - adding SYS_DVBC2 to fe_delivery_system OK, we can do that, when adding a driver needing such feature. > > - DTV_INPUT > > to select an input on cards were demods can choose from several inputs We're actually wanting to use the media controller to change the pipeline (selecting inputs and outputs, directing output to a MPEG decoding pipeline and descrambler, etc). The needed bits are there already at the DVB core upstream (although we don't have, currently, any DVB driver allowing changes at the pipeline). My original intention were to upstream some embedded drivers with such usage, but, unfortunately, the MC changes took too many time to be applied. by the time it got merged, it was too late, due to some internal changes that happened about the same time. > > - DTV_PLS > > to set the gold code used for DVB-S2 physical layer scrambling. > (btw. the sometimes used root and combo codes are redundant) > Some driver mods misuse the upper bits of DTV_STREAM_ID (which is for MIS in DVB-S2) for this, but > PLS and MIS are independent. In principle, sounds ok, but we need to take some care to avoid regressions here. > I know that the netstream and modulator support are proprietary but we will of course also need to keep > them dddvb package. > Btw., are there any standard APIs for modulator cards in the kernel now? Right now, we don't have. Feel free to propose what you're using at the dddvb package as standard, if you think it is generic enough to support other modulators in the future. Thanks, Mauro
