Mauro Carvalho Chehab writes: > 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? It differs from case to case. Digital Devices gets drivers and/or documetation from the manufacturer. Sometimes from this a Windows driver is written which we convert to Linux or a Linux driver is written directly. > 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? Yes > > 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) All I know is that they were strict with Digital Devices. We could not use their code directly. That's why I am surprised the Netup code contains Sony code. > > > > - 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. I'll see if that works. > > 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). I this also for selecting frontend inputs? It sounds more like switching transport stream data paths after the demod. > 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 also support this old method in the stv0900 and stv0910 drivers. > > 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. OK Reagards, Ralph
