[PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware
From: Daniel Scheller Third iteration of the DD CineCTv6/FlexCT support patches with mostly all things cleaned up that popped up so far. Obsoletes V1 and V2 series. These patches enhance the functionality of dvb-frontends/stv0367 to work with Digital Devices hardware driven by the ST STV0367 demodulator chip and adds probe & attach bits to ddbridge to make use of them, effectively enabling full support for CineCTv6 PCIe bridges and (older) DuoFlex CT addon modules. While the stv0367 code basically works with the DD hardware (e.g. setup of demodulation works for both -C and -T delivery systems), some bits (mostly initialisation) have to be done differently. Also, the static if_khz configuration is not sufficient as the TDA18212 tuner works at different IF speeds depending on the delivery system and carrier bandwidth, so functionality is added to read that speed from the tuner. The most important part is the addition of register default tabs for the DD boards, the DD demod initialisation code and the automated operation mode switch (OFDM vs. QAM) to be able to provide both systems in one DVB frontend. Everything else is provided by the existing code or the existing code is enhanced where it didn't suffice. So instead of duplicating the driver, the existing one is reused. Patches are laid out in a way to add each enhancement in small increments so they should be fairly easy to review. A note on the i2c_gatectrl flag: In the meantime (since v1) I got clarification why this is needed (reception issues), so I'd prefer to not diverge from that behaviour to not cause issues for anyone. Checkpatch complains about some minor style issues, however the patches were cleaned up beforehand and - where it still complains - match the rest of the code style throughout the respective files. In patches where code parts have been picked from other places, proper credits to the original author is given and permissions where granted beforehand. Resulting STV0367/DD support was successfully tested with TVHeadend and VDR setups by some users, with -C and -T combinations and two+four port tuner setups (CTv6 with and without attached CT modules). I even received some more very positive results on this since posting V1. Apologizes if anything regarding the patch submission is/went wrong, as this is my first time contribution to OSS via patch emails. I'd appreciate any comments or even reviews on this to see if the way the device support is done is acceptable at all, and how to proceed with this. Having this as part of the 4.12 merge window would ofc be great. Changes from v2 to v3: - refactored tda18212 ping in ddbridge which now even works, added i2c_read_regs for this (which is also required in another series) and wrapped i2c_read_reg to this - missing curly braces added as complained by the kbuild test bot - read_status() moved before get_frontend() for further signal stats readout (another series) - removed superfluous chip_id readout - added missing kfree(cab_state) to error cleanup in ddb_attach() - "invalid symbol rate" message changed from pr_err to printk to match the rest of the file Changes from v1 to v2: - tda18212 modification/hack removed and implemented into ddbridge where it shouldn't harm but still is needed due to HW quirks - symbolrate_min/max added to dvb_frontend_ops - updated commit message body of the i2c_gatectrl flag patch (1/12) so it is more clear why this is needed and relevant, updated commit message body of 12/12 (ddbridge patch) aswell Daniel Scheller (13): [media] dvb-frontends/stv0367: add flag to make i2c_gatectrl optional [media] dvb-frontends/stv0367: print CPAMP status only if stv_debug is enabled [media] dvb-frontends/stv0367: refactor defaults table handling [media] dvb-frontends/stv0367: move out tables, support multiple tab variants [media] dvb-frontends/stv0367: make PLLSETUP a function, add 58MHz IC speed [media] dvb-frontends/stv0367: make full reinit on set_frontend() optional [media] dvb-frontends/stv0367: support reading if_khz from tuner config [media] dvb-frontends/stv0367: selectable QAM FEC Lock status register [media] dvb-frontends/stv0367: fix symbol rate conditions in cab_SetQamSize() [media] dvb-frontends/stv0367: add defaults for use w/DD-branded devices [media] dvb-frontends/stv0367: add Digital Devices compatibility [media] ddbridge: add i2c_read_regs() [media] ddbridge: support STV0367-based cards and modules drivers/media/dvb-frontends/stv0367.c | 1168 ++--- drivers/media/dvb-frontends/stv0367.h | 13 + drivers/media/dvb-frontends/stv0367_defs.h | 1301 drivers/media/dvb-frontends/stv0367_regs.h |4 - drivers/media/pci/ddbridge/Kconfig |3 + drivers/media/pci/ddbridge/ddbridge-core.c | 168 +++- drivers/media/pci/ddbridge/ddbridge.h |1 + 7 files changed, 1943 insertions(+), 715 deletions(-
Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware
Am Wed, 12 Apr 2017 21:23:27 +0200 schrieb Daniel Scheller : > Am Wed, 29 Mar 2017 18:43:00 +0200 > schrieb Daniel Scheller : > > > From: Daniel Scheller > > > > Third iteration of the DD CineCTv6/FlexCT support patches with > > mostly all things cleaned up that popped up so far. Obsoletes V1 > > and V2 series. > > > > These patches enhance the functionality of dvb-frontends/stv0367 to > > work with Digital Devices hardware driven by the ST STV0367 > > demodulator chip and adds probe & attach bits to ddbridge to make > > use of them, effectively enabling full support for CineCTv6 PCIe > > bridges and (older) DuoFlex CT addon modules. > > Since V1 was sent over five weeks ago: Ping? Anyone? I'd really like > to get this upstreamed. Don't want to sound impatient, but V1 nears nine weeks, so: Second Ping. From what I can see, the two affected drivers aren't (at least) actively maintained anymore, or maintainers may be MIA. So: Mauro, mind having a look if you've got some spare time? Thanks & best regards, Daniel
Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware
Am Sun, 7 May 2017 17:42:12 +0200 schrieb Daniel Scheller : > Am Wed, 12 Apr 2017 21:23:27 +0200 > schrieb Daniel Scheller : > > > Am Wed, 29 Mar 2017 18:43:00 +0200 > > schrieb Daniel Scheller : > > > > > From: Daniel Scheller > > > > > > Third iteration of the DD CineCTv6/FlexCT support patches with > > > mostly all things cleaned up that popped up so far. Obsoletes V1 > > > and V2 series. > > > > > > These patches enhance the functionality of dvb-frontends/stv0367 > > > to work with Digital Devices hardware driven by the ST STV0367 > > > demodulator chip and adds probe & attach bits to ddbridge to make > > > use of them, effectively enabling full support for CineCTv6 PCIe > > > bridges and (older) DuoFlex CT addon modules. > > > > Since V1 was sent over five weeks ago: Ping? Anyone? I'd really like > > to get this upstreamed. > > Don't want to sound impatient, but V1 nears nine weeks, so: Second > Ping. Friendly third time Ping on this - Really, I'd like to have this merged so those quite aging (but still fine) DD CineCTv6 boards finally are supported without having to install out-of-tree drivers which even break the V4L-DVB subsystem... Thanks & regards, Daniel
Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware
Am Sun, 28 May 2017 23:45:37 +0200 schrieb Daniel Scheller : > Am Sun, 7 May 2017 17:42:12 +0200 > schrieb Daniel Scheller : > > > Am Wed, 12 Apr 2017 21:23:27 +0200 > > schrieb Daniel Scheller : > > > > > Am Wed, 29 Mar 2017 18:43:00 +0200 > > > schrieb Daniel Scheller : > > > > > > > From: Daniel Scheller > > > > > > > > Third iteration of the DD CineCTv6/FlexCT support patches with > > > > mostly all things cleaned up that popped up so far. Obsoletes V1 > > > > and V2 series. > > > > > > > > These patches enhance the functionality of dvb-frontends/stv0367 > > > > to work with Digital Devices hardware driven by the ST STV0367 > > > > demodulator chip and adds probe & attach bits to ddbridge to > > > > make use of them, effectively enabling full support for > > > > CineCTv6 PCIe bridges and (older) DuoFlex CT addon > > > > modules. > > > > > > Since V1 was sent over five weeks ago: Ping? Anyone? I'd really > > > like to get this upstreamed. > > > > Don't want to sound impatient, but V1 nears nine weeks, so: Second > > Ping. > > Friendly third time Ping on this - Really, I'd like to have this > merged so those quite aging (but still fine) DD CineCTv6 boards > finally are supported without having to install out-of-tree drivers > which even break the V4L-DVB subsystem... Well. From how things look, these and the cxd2841er+C2T2 ddbridge support patches won't make it in time for the 4.13 merge window. Also, unfortunately, the original owners and/or maintainers of the affected drivers (besides cxd2841er), namely stv0367 and ddbridge, either are MIA or not interested in reviewing or acking this. I have plenty of more work (patches) done, all building upon this CT and C2T2 hardware support, which - together with the work Jasmin has done regarding the en50221 and cxd2099 support - would finally bring the in-tree ddbridge driver on par with the package Digital Devices' provides, having addressed most of the critics the previous attempts to bump the driver received (incremental changes which are more or less easy to review, from what can be done by tearing tarballs without proper changelogs apart). The original series of this will be four(!) months old soon :/ Is there anything wrong with this? How to proceed with this? (Cc Hans since you also seem to be reviewing patches) That said, fourth ping. Best regards, Daniel Scheller
Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware
Hello ! On 06/19/2017 10:18 PM, Daniel Scheller wrote: > Am Sun, 28 May 2017 23:45:37 +0200 > schrieb Daniel Scheller : > >> Am Sun, 7 May 2017 17:42:12 +0200 >> schrieb Daniel Scheller : >> >>> Am Wed, 12 Apr 2017 21:23:27 +0200 >>> schrieb Daniel Scheller : >>> Am Wed, 29 Mar 2017 18:43:00 +0200 schrieb Daniel Scheller : > From: Daniel Scheller > > Third iteration of the DD CineCTv6/FlexCT support patches with > mostly all things cleaned up that popped up so far. Obsoletes V1 > and V2 series. > > These patches enhance the functionality of dvb-frontends/stv0367 > to work with Digital Devices hardware driven by the ST STV0367 > demodulator chip and adds probe & attach bits to ddbridge to > make use of them, effectively enabling full support for > CineCTv6 PCIe bridges and (older) DuoFlex CT addon > modules. Since V1 was sent over five weeks ago: Ping? Anyone? I'd really like to get this upstreamed. >>> >>> Don't want to sound impatient, but V1 nears nine weeks, so: Second >>> Ping. >> >> Friendly third time Ping on this - Really, I'd like to have this >> merged so those quite aging (but still fine) DD CineCTv6 boards >> finally are supported without having to install out-of-tree drivers >> which even break the V4L-DVB subsystem... > > Well. From how things look, these and the cxd2841er+C2T2 ddbridge > support patches won't make it in time for the 4.13 merge window. > Also, unfortunately, the original owners and/or maintainers of the > affected drivers (besides cxd2841er), namely stv0367 and ddbridge, > either are MIA or not interested in reviewing or acking this. > > I have plenty of more work (patches) done, all building upon this CT > and C2T2 hardware support, which - together with the work Jasmin has > done regarding the en50221 and cxd2099 support - would finally bring > the in-tree ddbridge driver on par with the package Digital Devices' > provides, having addressed most of the critics the previous attempts to > bump the driver received (incremental changes which are more or less > easy to review, from what can be done by tearing tarballs without > proper changelogs apart). > > The original series of this will be four(!) months old soon :/ > > Is there anything wrong with this? How to proceed with this? > > (Cc Hans since you also seem to be reviewing patches) > > That said, fourth ping. May I add another aspect. Daniel put a lot of effort into this and also other people in testing his drivers. Daniel was highly motivated to bring this driver into the Kernel. That sayd, waiting 4 months is pretty frustrating and might reduce the motivation to continue. There are 7 more patch series waiting to review and when each of then requires 4 or more months to get into the Kernel, the project is dead before it really started! The community using the DD cards is growing and it is often frustrating using the drivers provided by DD, when you plan to use other cards too, because the DD drivers are simply not compatible. Daniel made them working within the current media tree and a lot of people (including me) would be very happy to see the DD cards supported out of the box by the Kernel. Hopefully before the Kernel 5.x development hast started. I hope there will be soon a review of this series, so that we can move forward with our work! BR, Jasmin
Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware
On 20.06.2017 00:14, Jasmin J. wrote: Hello ! On 06/19/2017 10:18 PM, Daniel Scheller wrote: Am Sun, 28 May 2017 23:45:37 +0200 schrieb Daniel Scheller : Am Sun, 7 May 2017 17:42:12 +0200 schrieb Daniel Scheller : Am Wed, 12 Apr 2017 21:23:27 +0200 schrieb Daniel Scheller : Am Wed, 29 Mar 2017 18:43:00 +0200 schrieb Daniel Scheller : From: Daniel Scheller Third iteration of the DD CineCTv6/FlexCT support patches with mostly all things cleaned up that popped up so far. Obsoletes V1 and V2 series. These patches enhance the functionality of dvb-frontends/stv0367 to work with Digital Devices hardware driven by the ST STV0367 demodulator chip and adds probe & attach bits to ddbridge to make use of them, effectively enabling full support for CineCTv6 PCIe bridges and (older) DuoFlex CT addon modules. Since V1 was sent over five weeks ago: Ping? Anyone? I'd really like to get this upstreamed. Don't want to sound impatient, but V1 nears nine weeks, so: Second Ping. Friendly third time Ping on this - Really, I'd like to have this merged so those quite aging (but still fine) DD CineCTv6 boards finally are supported without having to install out-of-tree drivers which even break the V4L-DVB subsystem... Well. From how things look, these and the cxd2841er+C2T2 ddbridge support patches won't make it in time for the 4.13 merge window. Also, unfortunately, the original owners and/or maintainers of the affected drivers (besides cxd2841er), namely stv0367 and ddbridge, either are MIA or not interested in reviewing or acking this. I have plenty of more work (patches) done, all building upon this CT and C2T2 hardware support, which - together with the work Jasmin has done regarding the en50221 and cxd2099 support - would finally bring the in-tree ddbridge driver on par with the package Digital Devices' provides, having addressed most of the critics the previous attempts to bump the driver received (incremental changes which are more or less easy to review, from what can be done by tearing tarballs without proper changelogs apart). The original series of this will be four(!) months old soon :/ Is there anything wrong with this? How to proceed with this? (Cc Hans since you also seem to be reviewing patches) That said, fourth ping. May I add another aspect. Daniel put a lot of effort into this and also other people in testing his drivers. Daniel was highly motivated to bring this driver into the Kernel. That sayd, waiting 4 months is pretty frustrating and might reduce the motivation to continue. There are 7 more patch series waiting to review and when each of then requires 4 or more months to get into the Kernel, the project is dead before it really started! The community using the DD cards is growing and it is often frustrating using the drivers provided by DD, when you plan to use other cards too, because the DD drivers are simply not compatible. Daniel made them working within the current media tree and a lot of people (including me) would be very happy to see the DD cards supported out of the box by the Kernel. Hopefully before the Kernel 5.x development hast started. I hope there will be soon a review of this series, so that we can move forward with our work! BR, Jasmin Hello Reviewers Me too, I would be very happy to see this driver included in the kernel. Regards, Thomas
Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware
Em Mon, 19 Jun 2017 22:18:21 +0200 Daniel Scheller escreveu: > Am Sun, 28 May 2017 23:45:37 +0200 > schrieb Daniel Scheller : > > > Am Sun, 7 May 2017 17:42:12 +0200 > > schrieb Daniel Scheller : > > > > > Am Wed, 12 Apr 2017 21:23:27 +0200 > > > schrieb Daniel Scheller : > > > > > > > Am Wed, 29 Mar 2017 18:43:00 +0200 > > > > schrieb Daniel Scheller : > > > > > > > > > From: Daniel Scheller > > > > > > > > > > Third iteration of the DD CineCTv6/FlexCT support patches with > > > > > mostly all things cleaned up that popped up so far. Obsoletes V1 > > > > > and V2 series. > > > > > > > > > > These patches enhance the functionality of dvb-frontends/stv0367 > > > > > to work with Digital Devices hardware driven by the ST STV0367 > > > > > demodulator chip and adds probe & attach bits to ddbridge to > > > > > make use of them, effectively enabling full support for > > > > > CineCTv6 PCIe bridges and (older) DuoFlex CT addon > > > > > modules. > > > > > > > > Since V1 was sent over five weeks ago: Ping? Anyone? I'd really > > > > like to get this upstreamed. > > > > > > Don't want to sound impatient, but V1 nears nine weeks, so: Second > > > Ping. > > > > Friendly third time Ping on this - Really, I'd like to have this > > merged so those quite aging (but still fine) DD CineCTv6 boards > > finally are supported without having to install out-of-tree drivers > > which even break the V4L-DVB subsystem... > > Well. From how things look, these and the cxd2841er+C2T2 ddbridge > support patches won't make it in time for the 4.13 merge window. There is time. I just merged this series today. The thing is that we currently have few developers working on DVB, and no sub-maintainers. Due to that, I need to review them myself, with I usually do after reviewing/applying patches from sub-maintainers. > Also, unfortunately, the original owners and/or maintainers of the > affected drivers (besides cxd2841er), namely stv0367 and ddbridge, > either are MIA or not interested in reviewing or acking this. Yeah, it would be great if Ralph would have some time to review them, or to submit a new series adding all pending features from DD drivers upstream. > I have plenty of more work (patches) done, all building upon this CT > and C2T2 hardware support, which - together with the work Jasmin has > done regarding the en50221 and cxd2099 support - would finally bring > the in-tree ddbridge driver on par with the package Digital Devices' > provides, having addressed most of the critics the previous attempts to > bump the driver received (incremental changes which are more or less > easy to review, from what can be done by tearing tarballs without > proper changelogs apart). Both Jasmin and Thomas could have reviewed it, and replied if they tested it, and on what conditions. I tend to give people some time to review/test patches, before doing my review, as I don't usually have time for testing everything myself. > > The original series of this will be four(!) months old soon :/ > > Is there anything wrong with this? How to proceed with this? > > (Cc Hans since you also seem to be reviewing patches) Hans is focused at V4L2 side. > > That said, fourth ping. Btw, while you're here, it would be great if you could take a look on those warnings (that comes via smatch): drivers/media/pci/ddbridge/ddbridge-core.c:1009 input_tasklet() warn: this loop depends on readl() succeeding drivers/media/pci/ddbridge/ddbridge-core.c:1353 flashio() warn: this loop depends on readl() succeeding drivers/media/pci/ddbridge/ddbridge-core.c:1373 flashio() warn: this loop depends on readl() succeeding Regards, Mauro
Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware
Hello Mauro! > Yeah, it would be great if Ralph would have some time to review > them, or to submit a new series adding all pending features from > DD drivers upstream. I am pretty sure he will not do that. > Both Jasmin and Thomas could have reviewed it, and replied > if they tested it, and on what conditions. I can't test this, I have only S2 cards here, sorry. I will not sign things, which I can't test. BR, Jasmin
Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware
Am Wed, 29 Mar 2017 18:43:00 +0200 schrieb Daniel Scheller : > From: Daniel Scheller > > Third iteration of the DD CineCTv6/FlexCT support patches with mostly > all things cleaned up that popped up so far. Obsoletes V1 and V2 > series. > > These patches enhance the functionality of dvb-frontends/stv0367 to > work with Digital Devices hardware driven by the ST STV0367 > demodulator chip and adds probe & attach bits to ddbridge to make use > of them, effectively enabling full support for CineCTv6 PCIe bridges > and (older) DuoFlex CT addon modules. Since V1 was sent over five weeks ago: Ping? Anyone? I'd really like to get this upstreamed. Regards, Daniel
DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Am Tue, 20 Jun 2017 09:36:45 -0300 schrieb Mauro Carvalho Chehab : Hi Mauro, > Em Mon, 19 Jun 2017 22:18:21 +0200 > Daniel Scheller escreveu: > > > Well. From how things look, these and the cxd2841er+C2T2 ddbridge > > support patches won't make it in time for the 4.13 merge window. > > There is time. I just merged this series today. Oh. Well, this, together with the other series, came as a (quite positive) surprise this morning - thank you very very much! > The thing is that we currently have few developers working on > DVB, and no sub-maintainers. Due to that, I need to review > them myself, with I usually do after reviewing/applying patches > from sub-maintainers. Understood. Though, and please don't get me wrong - Tearing apart and under how things in the driver, the vendor driver package, the media and DVB subsystem aswell as kernel parts, additionally aligning the patches/commits with all remarks from previous submissions in mind took quite some spare time for more than a year now, getting no responses at all honestly started to get frustrating. > > Also, unfortunately, the original owners and/or maintainers of the > > affected drivers (besides cxd2841er), namely stv0367 and ddbridge, > > either are MIA or not interested in reviewing or acking this. > > Yeah, it would be great if Ralph would have some time to review > them, or to submit a new series adding all pending features from > DD drivers upstream. This would of course be the way to go. OTOH, the in-kernel driver already diverged quite a lot to that what DD publishes and maintains, and lots of people agree this situation must be improved. > > I have plenty of more work (patches) done, all building upon this CT > > and C2T2 hardware support, which - together with the work Jasmin has > > done regarding the en50221 and cxd2099 support - would finally bring > > the in-tree ddbridge driver on par with the package Digital Devices' > > provides, having addressed most of the critics the previous > > attempts to bump the driver received (incremental changes which are > > more or less easy to review, from what can be done by tearing > > tarballs without proper changelogs apart). > > Both Jasmin and Thomas could have reviewed it, and replied > if they tested it, and on what conditions. I tend to give > people some time to review/test patches, before doing my > review, as I don't usually have time for testing everything > myself. Not sure about Thomas, but I know that Jasmin doesn't own and/ore uses such cards. However, for upcoming patches, I'll try to drag people to the list for some comments, thanks for the pointer. Speaking of patches and pending features (and generally syncing drivers), this is what I plan to send to the list (in order, mostly depending on each other): - 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). - The "big" ddbridge update. I'm thinking of two ways to do this: * Do this in one commit, being a huge code bump, bringing ddbridge to version 0.9.28 (as per vendor versioning). This is mostly ready and successful in use by many testers and in my Gentoo ddbridge kernel sources overlay. Should get some more cleanups though (still some GTL link bits left which are not needed), and all fixes which went to the in-kernel driver like __user annotations need to be put back in. Big drawback: A mess to review. * Try to tear apart most if not all upstream vendor driver tar archives and recreate individual patches out of this. For reference, we need to go from what is in the kernel which is something inbetween v0.5 and v0.8 up to and including version 0.9.29. I'm currently working on this from time to time, and I can assure you that this is an extremely tedious and unthankful thing to do (currently nearly done with 0.9.9b, approx. 20 releases left). This might be better to review, but this will also result in something like 100-200 commits, without guarantee of having everything correct. Reviewers will hate me for this, but I'd personally prefer the first option (less work, verified working on quite some installs, less clutter in GIT, but the drawback of reviewability). - Last bit: DD MaxS4/S8 support. Requires another new demod driver (mxl5xx) and some more bits (not only glue code, but also some operation mode control and LNB handling) in ddbridge. Least work went into this so far an the mxl5xx driver code needs quite some cleanup. Note on the ddbridge update: This is mostly code refactoring and reorganisation, and fe
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Em Tue, 20 Jun 2017 20:41:21 +0200 Daniel Scheller escreveu: > Am Tue, 20 Jun 2017 09:36:45 -0300 > schrieb Mauro Carvalho Chehab : > > Hi Mauro, > > > Em Mon, 19 Jun 2017 22:18:21 +0200 > > Daniel Scheller escreveu: > > > > > Well. From how things look, these and the cxd2841er+C2T2 ddbridge > > > support patches won't make it in time for the 4.13 merge window. > > > > There is time. I just merged this series today. > > Oh. Well, this, together with the other series, came as a (quite > positive) surprise this morning - thank you very very much! Anytime. Sorry again for taking a long time reviewing it. > > > The thing is that we currently have few developers working on > > DVB, and no sub-maintainers. Due to that, I need to review > > them myself, with I usually do after reviewing/applying patches > > from sub-maintainers. > > Understood. Though, and please don't get me wrong - Tearing apart and > under how things in the driver, the vendor driver package, the media and > DVB subsystem aswell as kernel parts, additionally aligning the > patches/commits with all remarks from previous submissions in mind took > quite some spare time for more than a year now, getting no responses at > all honestly started to get frustrating. Yes, I know how frustrating it can be. The real fix for this issue would be to get more people involved on dvb. > > > Also, unfortunately, the original owners and/or maintainers of the > > > affected drivers (besides cxd2841er), namely stv0367 and ddbridge, > > > either are MIA or not interested in reviewing or acking this. > > > > Yeah, it would be great if Ralph would have some time to review > > them, or to submit a new series adding all pending features from > > DD drivers upstream. > > This would of course be the way to go. OTOH, the in-kernel driver > already diverged quite a lot to that what DD publishes and maintains, > and lots of people agree this situation must be improved. Ralph went to a media summit we did in Germany a few years ago. At that time, it sounded that the way to go would be to submit a new version of the DD driver, based on upstream Kernel, and then DD start maintaining it for both DD internal tree and Kernel one. Unfortunately, he never had the required time for such task. We usually don't like this kind of change, as it is disruptive, with regards to bug fixes, but, if we do it only once, and, after that, go to the normal Kernel way, it could be not that bad. > > > I have plenty of more work (patches) done, all building upon this CT > > > and C2T2 hardware support, which - together with the work Jasmin has > > > done regarding the en50221 and cxd2099 support - would finally bring > > > the in-tree ddbridge driver on par with the package Digital Devices' > > > provides, having addressed most of the critics the previous > > > attempts to bump the driver received (incremental changes which are > > > more or less easy to review, from what can be done by tearing > > > tarballs without proper changelogs apart). > > > > Both Jasmin and Thomas could have reviewed it, and replied > > if they tested it, and on what conditions. I tend to give > > people some time to review/test patches, before doing my > > review, as I don't usually have time for testing everything > > myself. > > Not sure about Thomas, but I know that Jasmin doesn't own and/ore uses > such cards. However, for upcoming patches, I'll try to drag people to > the list for some comments, thanks for the pointer. Yeah, if you can drag people to help reviewing/testing (and even coding), that would be really cool, as we'll be able to better do our reviews. > Speaking of patches and pending features (and generally syncing > drivers), this is what I plan to send to the list (in order, mostly > depending on each other): > > - 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. > > - The "big" ddbridge update. I'm thinking of two ways to do this: > > * Do this in one commit, being a huge code bump, bringing ddbridge to > version 0.9.28 (as per vendor versioning). This is mostly ready and > successful in use by many testers and in my Gentoo ddbridge kernel > sources overlay. Should get some more cleanups though (still some > GTL link bits left which are not needed), and all fixes which went > to the in-kernel driver like __user a
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Am Tue, 20 Jun 2017 16:10:43 -0300 schrieb Mauro Carvalho Chehab : > Em Tue, 20 Jun 2017 20:41:21 +0200 > Daniel Scheller escreveu: > > > Not sure about Thomas, but I know that Jasmin doesn't own and/ore uses > > such cards. However, for upcoming patches, I'll try to drag people to > > the list for some comments, thanks for the pointer. > > Yeah, if you can drag people to help reviewing/testing (and even > coding), that would be really cool, as we'll be able to better > do our reviews. For the upcoming bigger changes around ddbridge and new demod/tuner drivers, I'll try to do so. Though this would mostly be for Tested-By's, but still. > > - 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. Putting Ralph into "To:", really like to hear an opinion from him on this whole subject. > > - The "big" ddbridge update. I'm thinking of two ways to do this: > > > > * Do this in one commit, being a huge code bump, bringing ddbridge to > > version 0.9.28 (as per vendor versioning). This is mostly ready and > > successful in use by many testers and in my Gentoo ddbridge kernel > > sources overlay. Should get some more cleanups though (still some > > GTL link bits left which are not needed), and all fixes which went > > to the in-kernel driver like __user annotations need to be put back > > in. Big drawback: A mess to review. > > > > * Try to tear apart most if not all upstream vendor driver tar > > archives and recreate individual patches out of this. For > > reference, we need to go from what is in the kernel which is > > something inbetween v0.5 and v0.8 up to and including version > > 0.9.29. I'm currently working on this from time to time, and I can > > assure you that this is an extremely tedious and unthankful thing > > to do (currently nearly done with 0.9.9b, approx. 20 releases > > left). This might be better to review, but this will also result in > > something like 100-200 commits, without guarantee of having > > everything correct. > > The second approach is preferred, but, as you said, it is a very > complex task, and has bad effect that, at the time you're updating > it, the DD driver will be changed. I'd welcome it if we could put approach two somewhat aside for at least the reasons outlined :) > The first approach will require some things to work, though: > > - the "legacy" driver should be kept at the Kernel for some time, > in order to provide a "fall back" for those that find issues with > the new version; From what can be gathered from forums and such, the current ("upstream") version doesn't show some (if any) issues. Though I'm aware that MSI interrupts are still an issue on a lot of hardware platforms, but disabling that option by default in the driver and toggling this via a Kconfig option works around this, since w/o MSI things work like a charm. Thats a problem that needs to be resolved by the vendor though. Still, I understand you that you'd like to keep this around. Not exactly sure though how to achieve this in detail. Renaming media/pci/ddbridge to e.g. media/pci/ddbridge-legacy is the easy part, but if we don't want to mix up commits, one point in the commit history remains where there's a driver named ddbridge-legacy and no ddbridge (driver missing) exists (commit: "rename ddbridge to ddbridge-legacy", commi
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Daniel Scheller writes: > Am Tue, 20 Jun 2017 16:10:43 -0300 > schrieb Mauro Carvalho Chehab : > ... > > > - 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. > > 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 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. > > - 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. 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 - DTV_INPUT to select an input on cards were demods can choose from several inputs - 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. 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? Regards, Ralph
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Em Thu, 22 Jun 2017 23:35:27 +0200 Ralph Metzler escreveu: > Daniel Scheller writes: > > Am Tue, 20 Jun 2017 16:10:43 -0300 > > schrieb Mauro Carvalho Chehab : > > ... > > > > - 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://linux
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Am Sat, 24 Jun 2017 13:50:01 -0300 schrieb Mauro Carvalho Chehab : > Em Thu, 22 Jun 2017 23:35:27 +0200 > Ralph Metzler escreveu: > > 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? Note that this mostly (if not only) applies to the demodulator drivers. ddbridge itself is okay in this regard and has only some minors like indent, whitespace and such. There's one bigger thing though I'm not sure of if it needs to be changed: Beginning with the 0.9.9-tarball release, functionality was split from ddbridge-core.c into ddbridge.c, ddbridge-i2c.c, ddbridge-mod.c and ddbridge-ns.c (the two latter being modulator and netstream/octonet related code, which we don't need at this time). The issue is that this wasn't done by updating the build system to build multiple objects, but rather build from ddbridge.c which then does '#include "ddbridge-core.c"', and in that file '#include "ddbridge-i2c.c"'. See [1] for how it actually looks like in the file. Mauro, do you think this is acceptable? > > 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 already started something when I searched for possible reasons for the stv0367 I2C bus crashes and implemented the tuner calibration (this wasn't the reason in the end, but still), see [2]. Guess a config flag like in [3] will work. But I'd need advice in what parts are required to be ported over if I should do this. > > - adding SYS_DVBC2 to fe_delivery_system > > OK, we can do that, when adding a driver needing such feature. I might volunteer in adding DVB-C2 support to cxd2841er in porting needed bits over from the cxd2843 driver, but someone else need to do testing on a DVB-C2 enabled coax cable. Best regards, Daniel Scheller [1] https://github.com/herrnst/dddvb-linux-kernel/blob/17d60ca45dd0294120882af9abbbdf9e5a130cb5/drivers/media/pci/ddbridge/ddbridge.c#L50 [2] https://github.com/herrnst/dddvb-linux-kernel/commit/0788bd5e05fffdcd2d00d1fa2732c9712c6c759d [3] https://patchwork.linuxtv.org/patch/40710/ -- https://github.com/herrnst
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Em Sun, 25 Jun 2017 19:52:59 +0200 Daniel Scheller escreveu: > Am Sat, 24 Jun 2017 13:50:01 -0300 > schrieb Mauro Carvalho Chehab : > > > Em Thu, 22 Jun 2017 23:35:27 +0200 > > Ralph Metzler escreveu: > > > > 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? > > Note that this mostly (if not only) applies to the demodulator drivers. > ddbridge itself is okay in this regard and has only some minors like indent, > whitespace and such. There's one bigger thing though I'm not sure of if it > needs to be changed: Beginning with the 0.9.9-tarball release, functionality > was split from ddbridge-core.c into ddbridge.c, ddbridge-i2c.c, > ddbridge-mod.c and ddbridge-ns.c (the two latter being modulator and > netstream/octonet related code, which we don't need at this time). The issue > is that this wasn't done by updating the build system to build multiple > objects, but rather build from ddbridge.c which then does '#include > "ddbridge-core.c"', and in that file '#include "ddbridge-i2c.c"'. See [1] for > how it actually looks like in the file. Mauro, do you think this is > acceptable? Splitting it is OK. Including a *.c file no. It shouldn't be hard to change the makefile to: obj-ddbridge = ddbridge-main.o ddbridge-core.o ddbridge-i2c.o \ ddbridge-modulator.o and ddbridge-ns.o The only detail is that "ddbridge.c" should be renamed to ddbridge-core.c (or something similar) and some *.h files will be needed. I would also refrain for using ddbridge-mod, as the Kernel build system generates file with ".mod.c" extension. Having a file with "-mod.c" can be confusing. > > > 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 already started something when I searched for possible reasons for the > stv0367 I2C bus crashes and implemented the tuner calibration (this wasn't > the reason in the end, but still), see [2]. Guess a config flag like in [3] > will work. But I'd need advice in what parts are required to be ported over > if I should do this. Yes, config flags work, but please don't use a config flag like this: if (initflags & TDA18212_INIT_DDSTV) The flags should identify the required functionality, not if the caller is ddbridge driver. On a quick look at your patch, I suspect that it would need two flags, like: TDA18212_FLAG_SLEEP - with would enable sleep/wakeup/standby TDA18212_FLAG_CALIBRATION - with would enable calibration > > > > - adding SYS_DVBC2 to fe_delivery_system > > > > OK, we can do that, when adding a driver needing such feature. > > I might volunteer in adding DVB-C2 support to cxd2841er in porting needed > bits over from the cxd2843 driver, but someone else need to do testing on a > DVB-C2 enabled coax cable. I can't volunteer myself for the tests, as it depends on how busy I'll be with other things, but I have an universal standard generator, and some ddbridge frontends. Not sure if the one I have has cxd2341er. I won't be able to touch on it for the next month, though. I will need ~60 seconds of a DVB-C2 signal, in order to use the generator, though. > > Best regards, > Daniel Scheller > > [1] > https://github.com/herrnst/dddvb-linux-kernel/blob/17d60ca45dd0294120882af9abbbdf9e5a130cb5/drivers/media/pci/ddbridge/ddbridge.c#L50 > [2] > https://github.com/herrnst/dddvb-linux-kernel/commit/0788bd5e05fffdcd2d00d1fa2732c9712c6c759d > [3] https://patchwork.linuxtv.org/patch/40710/ Thanks, Mauro
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Mauro Carvalho Chehab writes: > Em Thu, 22 Jun 2017 23:35:27 +0200 > Ralph Metzler escreveu: > > > Daniel Scheller writes: > > > Am Tue, 20 Jun 2017 16:10:43 -0300 > > > schrieb Mauro Carvalho Chehab : > > > ... > > > > > - 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 ag
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Mauro Carvalho Chehab writes: > Em Sun, 25 Jun 2017 19:52:59 +0200 > Daniel Scheller escreveu: > > > Am Sat, 24 Jun 2017 13:50:01 -0300 > > schrieb Mauro Carvalho Chehab : > > > > > Em Thu, 22 Jun 2017 23:35:27 +0200 > > > Ralph Metzler escreveu: > > > > > > 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? > > > > Note that this mostly (if not only) applies to the demodulator drivers. > > ddbridge itself is okay in this regard and has only some minors like > > indent, whitespace and such. There's one bigger thing though I'm not sure > > of if it needs to be changed: Beginning with the 0.9.9-tarball release, > > functionality was split from ddbridge-core.c into ddbridge.c, > > ddbridge-i2c.c, ddbridge-mod.c and ddbridge-ns.c (the two latter being > > modulator and netstream/octonet related code, which we don't need at this > > time). The issue is that this wasn't done by updating the build system to > > build multiple objects, but rather build from ddbridge.c which then does > > '#include "ddbridge-core.c"', and in that file '#include > > "ddbridge-i2c.c"'. See [1] for how it actually looks like in the file. > > Mauro, do you think this is acceptable? > > Splitting it is OK. Including a *.c file no. It shouldn't be hard to The main reason for using includes at the time were that the OctopusNet driver (see https://github.com/DigitalDevices/dddvb/blob/master/ddbridge/octonet.c) was using the same files but with different defines set. Those differences are pretty much gone now. > change the makefile to: > obj-ddbridge = ddbridge-main.o ddbridge-core.o ddbridge-i2c.o \ > ddbridge-modulator.o and ddbridge-ns.o > > The only detail is that "ddbridge.c" should be renamed to > ddbridge-core.c (or something similar) and some *.h files will > be needed. Hmm, ddbridge -> ddbridge-main would be fine. Renaming ddbridge to ddbridge-core and ddbridge-core to something else would be confusing. Regards, Ralph
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Em Mon, 26 Jun 2017 11:59:20 +0200 Ralph Metzler escreveu: > Mauro Carvalho Chehab writes: > > Em Sun, 25 Jun 2017 19:52:59 +0200 > > Daniel Scheller escreveu: > > > > > Am Sat, 24 Jun 2017 13:50:01 -0300 > > > schrieb Mauro Carvalho Chehab : > > > > > > > Em Thu, 22 Jun 2017 23:35:27 +0200 > > > > Ralph Metzler escreveu: > > > > > > > > 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? > > > > > > Note that this mostly (if not only) applies to the demodulator drivers. > ddbridge itself is okay in this regard and has only some minors like indent, > whitespace and such. There's one bigger thing though I'm not sure of if it > needs to be changed: Beginning with the 0.9.9-tarball release, functionality > was split from ddbridge-core.c into ddbridge.c, ddbridge-i2c.c, > ddbridge-mod.c and ddbridge-ns.c (the two latter being modulator and > netstream/octonet related code, which we don't need at this time). The issue > is that this wasn't done by updating the build system to build multiple > objects, but rather build from ddbridge.c which then does '#include > "ddbridge-core.c"', and in that file '#include "ddbridge-i2c.c"'. See [1] for > how it actually looks like in the file. Mauro, do you think this is > acceptable? > > > > Splitting it is OK. Including a *.c file no. It shouldn't be hard to > > The main reason for using includes at the time were that the OctopusNet driver > (see https://github.com/DigitalDevices/dddvb/blob/master/ddbridge/octonet.c) > was using the same files but with different defines set. > Those differences are pretty much gone now. I see. If now there's no defines to patch the code included via ddbridge-core.c, it should be possible to create a driver with the ddbridge "core" on it, and use the exported symbols there for both octonet and ddbridge dvb drivers. > > change the makefile to: > >obj-ddbridge = ddbridge-main.o ddbridge-core.o ddbridge-i2c.o \ > > ddbridge-modulator.o and ddbridge-ns.o > > > > The only detail is that "ddbridge.c" should be renamed to > > ddbridge-core.c (or something similar) and some *.h files will > > be needed. > > Hmm, ddbridge -> ddbridge-main would be fine. Yeah, that's what I meant to say :-) I noticed that you have already a ddbridge-core. That's why I added a "ddbridge-main" there. I forgot to change it at the comment above ;) > Renaming ddbridge to ddbridge-core and ddbridge-core to something else > would be confusing. Indeed. Thanks, Mauro
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Em Mon, 26 Jun 2017 11:45:08 +0200 Ralph Metzler escreveu: > Mauro Carvalho Chehab writes: > > Em Thu, 22 Jun 2017 23:35:27 +0200 > > Ralph Metzler escreveu: > > > > > Daniel Scheller writes: > > > > Am Tue, 20 Jun 2017 16:10:43 -0300 > > > > schrieb Mauro Carvalho Chehab : > > > > ... > > > > > > - 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 Good! With that, it should be easier to keep both versions containing the same stuff. > > > > 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. I didn't say they're using Sony code. I actually suspect that they did the same as you (but I have no means to be sure). Yet, as Sony recently approached us for cxd2880, and they're now developing an official driver to be upstreamed, I'm wandering if we can get a better way to handle the cxd2841 driver in a way that will make easier for everyone to use the same 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 IOC
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Resend since I received bad-mail-address bounces, sorry for any duplicated email. Am Mon, 26 Jun 2017 11:59:20 +0200 schrieb Ralph Metzler : > Mauro Carvalho Chehab writes: > > > > Splitting it is OK. Including a *.c file no. It shouldn't be hard > > to > [...] > > change the makefile to: > >obj-ddbridge = ddbridge-main.o ddbridge-core.o > > ddbridge-i2c.o \ ddbridge-modulator.o and ddbridge-ns.o > > > > The only detail is that "ddbridge.c" should be renamed to > > ddbridge-core.c (or something similar) and some *.h files will > > be needed. > > Hmm, ddbridge -> ddbridge-main would be fine. Funny, that's exactly the naming I had in mind when thinking about this in the past :) So, I'll propose a rough todo (commit list) for me (I will do and care about this) then: - 1/4: (Step 0) Since dddvb-0.9.9b besides the split also involved reordering the functions in the code, this will be repeated with the current mainline driver (helps keeping the diff with the actual code bump cleaner) - 2/4: Do the split like done in 0.9.9 with the mainline driver, but do it by having multiple objects in the makefile, adding header files with prototypes where required - 3/4: Bump the driver code with what is already there (means, the pre-cleaned variant w/o modulator and netstream/octonet stuff) - 4/4 (or 4/x): Apply any additional patches (like the "enable msi by default Kconf opt, marked EXPERIMENTAL" thing I did to work around the still problematic MSI IRQ stuff to let users have a better experience) When done, I'll post the patches for early review, but they'll have a hard dependency on the stv0910/stv6111 demod/tuner drivers (don't feel like ripping this out since we want that support anyway). Additionally,I can do this for dddvb and submit it to the DigitalDevices dddvb repository (GitHub Pull Request) so we're at least in-sync wrt building the driver. Ralph, Mauro, are you ok with this? Mauro, in the meantime a decision should be made if the current in-kernel ddbridge should be kept somewhere or not (ie. as legacy driver). IMHO this is not absolutely neccessary since both driver variants (dddvb directly and the "castrated" one) are in use by people all around and besides MSI (which we can workaround until fixed finally) I don't know of any complaints at all. Best regards, Daniel Scheller -- https://github.com/herrnst
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Am Mon, 26 Jun 2017 06:19:20 -0300 schrieb Mauro Carvalho Chehab : > Yes, config flags work, but please don't use a config flag like this: > > if (initflags & TDA18212_INIT_DDSTV) > > The flags should identify the required functionality, not if the > caller is ddbridge driver. On a quick look at your patch, I suspect > that it would need two flags, like: > > TDA18212_FLAG_SLEEP - with would enable sleep/wakeup/standby > TDA18212_FLAG_CALIBRATION - with would enable calibration Yes, of course. Actually, this was just some (early) random attempt at fixing something which turned out unrelated and even doesn't apply as is anymore. But that patch might be a start to get this done. Best regards, Daniel Scheller -- https://github.com/herrnst
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Am Mon, 26 Jun 2017 11:45:08 +0200 schrieb Ralph Metzler : > Mauro Carvalho Chehab writes: > > > 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 Addmittedly, this might have been too quick, but I just couldn't resist :) (thankfully, tools exist for such jobs). Ralph, please have a look at https://github.com/DigitalDevices/dddvb/pull/12 - if you're fine with the result, I will start a V2 series based on kernel_case naming. Best regards, Daniel Scheller -- https://github.com/herrnst
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Daniel Scheller writes: > Am Mon, 26 Jun 2017 11:59:20 +0200 > schrieb Ralph Metzler : > > > Mauro Carvalho Chehab writes: > > > > > > Splitting it is OK. Including a *.c file no. It shouldn't be hard > > > to > > [...] > > > change the makefile to: > > > obj-ddbridge = ddbridge-main.o ddbridge-core.o > > > ddbridge-i2c.o \ ddbridge-modulator.o and ddbridge-ns.o > > > > > > The only detail is that "ddbridge.c" should be renamed to > > > ddbridge-core.c (or something similar) and some *.h files will > > > be needed. > > > > Hmm, ddbridge -> ddbridge-main would be fine. > > Funny, that's exactly the naming I had in mind when thinking about this > in the past :) > > So, I'll propose a rough todo (commit list) for me (I will do and > care about this) then: > > - 1/4: (Step 0) Since dddvb-0.9.9b besides the split also involved > reordering the functions in the code, this will be repeated with the > current mainline driver (helps keeping the diff with the actual code > bump cleaner) > - 2/4: Do the split like done in 0.9.9 with the mainline driver, but do > it by having multiple objects in the makefile, adding header files > with prototypes where required > - 3/4: Bump the driver code with what is already there (means, the > pre-cleaned variant w/o modulator and netstream/octonet stuff) > - 4/4 (or 4/x): Apply any additional patches (like the "enable msi by > default Kconf opt, marked EXPERIMENTAL" thing I did to work around > the still problematic MSI IRQ stuff to let users have a better > experience) > > When done, I'll post the patches for early review, but they'll have a > hard dependency on the stv0910/stv6111 demod/tuner drivers (don't feel > like ripping this out since we want that support anyway). > > Additionally,I can do this for dddvb and submit it to the DigitalDevices > dddvb > repository (GitHub Pull Request) so we're at least in-sync wrt > building the driver. > > Ralph, Mauro, are you ok with this? I cannot promise which changes I will accept and when. Some will likely break other things like building the OctopusNet image. The public DigitalDevices repository also is not the one I am using for development. So, changes will first go into our private repository and will only go upstream for releases. Regards, Ralph
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Mauro Carvalho Chehab writes: > Em Mon, 26 Jun 2017 11:45:08 +0200 > Ralph Metzler escreveu: > > > Mauro Carvalho Chehab writes: > > > Em Thu, 22 Jun 2017 23:35:27 +0200 > > > Ralph Metzler escreveu: > > > > > > > Daniel Scheller writes: > > > > > Am Tue, 20 Jun 2017 16:10:43 -0300 > > > > > schrieb Mauro Carvalho Chehab : > > > > > ... > > > > > > > - 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 > > Good! With that, it should be easier to keep both versions containing > the same stuff. > > > > > > > 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. > > I didn't say they're using Sony code. I actually suspect that they > did the same as you (but I have no means to be sure). The code contains a Sony copyright header. That's why we were surprised. We did not get any GPLed code from Sony. > Yet, as Sony recently approached us for cxd2880, and they're now > developing an official driver to be upstreamed, I'm wandering if we > can get a better way to handle the cxd2841 driver in a way that will > make easier for everyone to use the same code. Yes, that would be nice. > The media controller is generic enough to control all pipelines at > the ha
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Em Tue, 27 Jun 2017 07:38:50 +0200 Ralph Metzler escreveu: > Daniel Scheller writes: > > Am Mon, 26 Jun 2017 11:59:20 +0200 > > schrieb Ralph Metzler : > > > > > Mauro Carvalho Chehab writes: > > > > > > > > Splitting it is OK. Including a *.c file no. It shouldn't be hard > > > > to > > > [...] > > > > change the makefile to: > > > > obj-ddbridge = ddbridge-main.o ddbridge-core.o > > > > ddbridge-i2c.o \ ddbridge-modulator.o and ddbridge-ns.o > > > > > > > > The only detail is that "ddbridge.c" should be renamed to > > > > ddbridge-core.c (or something similar) and some *.h files will > > > > be needed. > > > > > > Hmm, ddbridge -> ddbridge-main would be fine. > > > > Funny, that's exactly the naming I had in mind when thinking about this > > in the past :) > > > > So, I'll propose a rough todo (commit list) for me (I will do and > > care about this) then: > > > > - 1/4: (Step 0) Since dddvb-0.9.9b besides the split also involved > > reordering the functions in the code, this will be repeated with the > > current mainline driver (helps keeping the diff with the actual code > > bump cleaner) > > - 2/4: Do the split like done in 0.9.9 with the mainline driver, but do > > it by having multiple objects in the makefile, adding header files > > with prototypes where required > > - 3/4: Bump the driver code with what is already there (means, the > > pre-cleaned variant w/o modulator and netstream/octonet stuff) > > - 4/4 (or 4/x): Apply any additional patches (like the "enable msi by > > default Kconf opt, marked EXPERIMENTAL" thing I did to work around > > the still problematic MSI IRQ stuff to let users have a better > > experience) > > > > When done, I'll post the patches for early review, but they'll have a > > hard dependency on the stv0910/stv6111 demod/tuner drivers (don't feel > > like ripping this out since we want that support anyway). > > > > Additionally,I can do this for dddvb and submit it to the DigitalDevices > dddvb > > repository (GitHub Pull Request) so we're at least in-sync wrt > > building the driver. > > > > Ralph, Mauro, are you ok with this? > > I cannot promise which changes I will accept and when. Some will likely break > other things like building the OctopusNet image. > > The public DigitalDevices repository also is not the one I am using for > development. > So, changes will first go into our private repository and will only go > upstream > for releases. Are there any way where we can help to make easier to synchronize upstream with your internal tree? As Daniel mentioned that he used some scripts, perhaps he can send them for you to run on your tree. Another alternative would be if you could release a "fork" of your development tree before a release, as sort of "release candidate" or something similar, at least while we're taking some efforts to synchronize it with upstream. Thanks, Mauro
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Em Tue, 11 Jul 2017 20:12:35 +0200 Ralph Metzler escreveu: > Mauro Carvalho Chehab writes: > > Em Mon, 26 Jun 2017 11:45:08 +0200 > > Ralph Metzler escreveu: > > > > The media controller is generic enough to control all pipelines at > > the hardware level. It can be used to select frontend inputs, to > > dynamically add/remove CAM modules, etc. > > > > If I remember well, in the case of the hardware I was working on that > > time, each frontend had 3 inputs (and the hardware had 2 identical > > sets of tuner/demod), plus 3 MPEG-TS demuxes) and 2 CAM modules. > > > > With the media controller, any arrangement between input, tuner, > > demod, demux and CAM is possible, as long as supported by > > the hardware. > > OK, for such complex arrangements it makes sense. > I just thought it to be overkill for just the input selection The media controller support is handled by the DVB core for the general case. The needed bits that would give the flexibility that ddbridge require shouldn't be hard to add. > and it also has to run on older kernels where th MC stuff is > not yet in the DVB core. The MC DVB support is there since jan/2015 (Kernel 3.20): commit a0246e02f466482a34c8ad94bedbe4efa498662d Author: Mauro Carvalho Chehab Date: Fri Jan 2 12:19:51 2015 -0300 [media] dvbdev: add support for media controller Provide a way to register media controller device nodes at the DVB core. Please notice that the dvbdev callers also require changes for the devices to be registered via the media controller. Signed-off-by: Mauro Carvalho Chehab $ git describe a0246e02f4664 media/v3.20-1-9-ga0246e02f466 For older Kernels, there are a few ways to proceed: 1) use an approach like media_build for the DD tree, where the DVB core is replaced by a newer one. I guess it has support since v2.6.30, at least for the core. 2) Keep use the solution you have already, using ifdefs on your tree to keep it supported with legacy Kernels. 3) you could base DD trees at the backport tree: https://backports.wiki.kernel.org/index.php/Main_Page I never used it myself, but it should be covering the media drivers there too. Thanks, Mauro