Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Mauro Carvalho Chehab]

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

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Mauro Carvalho Chehab]

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)

[Ralph Metzler]

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 

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Ralph Metzler]

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)

[Daniel Scheller]

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]

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)

[Daniel Scheller]

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)

[Mauro Carvalho Chehab]

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 

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Mauro Carvalho Chehab]

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)

[Ralph Metzler]

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)

[Ralph Metzler]

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:
 > 
 >  

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Mauro Carvalho Chehab]

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)

[Daniel Scheller]

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)

[Mauro Carvalho Chehab]

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 

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Ralph Metzler]

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)

[Daniel Scheller]

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 

Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware

[Jasmin J.]

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: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Mauro Carvalho Chehab]

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 

DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Daniel Scheller]

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 

Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware

[Mauro Carvalho Chehab]

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

[Thomas Kaiser]

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

[Jasmin J.]

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

[Daniel Scheller]

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

[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...

Thanks & regards,
Daniel

Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware

[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.

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

[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.

Regards,
Daniel

[PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware

[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.

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