Cine CT V6.1 code change request

Cine CT V6.1 code change request

[Martin Herrman]

All,

I have a Cine CT V6.1 in my fedora 25 based media center. It is now
running a default fedora 4.9 kernel. I install the driver as follows:

hg clone https://linuxtv.org/hg/~endriss/media_build_experimental
cd media_build_experimental
make download
make untar
make menuconfig
make
make install

However, I have to make two changes to the source to make it work.

Change 1: in media_build_experimental/v4l/Kconfig line 6936 I have to
remove the whitespace in '--- help ---', otherwise make menuconfig
fails.
Change 2: during compilation the following error occurs (since about
kernel 4.5?):

make -C /lib/modules/4.9.7-201.fc25.x86_64/build
SUBDIRS=/home/htpc/Downloads/media_build_experimental/v4l  modules
make[2]: Entering directory '/usr/src/kernels/4.9.7-201.fc25.x86_64'
  CC [M]  /home/htpc/Downloads/media_build_experimental/v4l/tuner-xc2028.o
In file included from <command-line>:0:0:
/home/htpc/Downloads/media_build_experimental/v4l/compat.h:1463:1:
error: redefinition of 'pci_zalloc_consistent'
 pci_zalloc_consistent(struct pci_dev *hwdev, size_t size,
 ^~~~~~~~~~~~~~~~~~~~~
In file included from ./include/linux/pci.h:2145:0,
                 from
/home/htpc/Downloads/media_build_experimental/v4l/compat.h:1459,
                 from <command-line>:0:
./include/linux/pci-dma-compat.h:23:1: note: previous definition of
'pci_zalloc_consistent' was here
 pci_zalloc_consistent(struct pci_dev *hwdev, size_t size,
 ^~~~~~~~~~~~~~~~~~~~~
In file included from <command-line>:0:0:
/home/htpc/Downloads/media_build_experimental/v4l/compat.h:1552:0:
warning: "DMA_ATTR_SKIP_CPU_SYNC" redefined
 #define DMA_ATTR_SKIP_CPU_SYNC 0

In file included from ./include/linux/pci-dma-compat.h:7:0,
                 from ./include/linux/pci.h:2145,
                 from
/home/htpc/Downloads/media_build_experimental/v4l/compat.h:1459,
                 from <command-line>:0:
./include/linux/dma-mapping.h:47:0: note: this is the location of the
previous definition
 #define DMA_ATTR_SKIP_CPU_SYNC  (1UL << 5)

scripts/Makefile.build:299: recipe for target
'/home/htpc/Downloads/media_build_experimental/v4l/tuner-xc2028.o'
failed
make[3]: *** [/home/htpc/Downloads/media_build_experimental/v4l/tuner-xc2028.o]
Error 1
Makefile:1494: recipe for target
'_module_/home/htpc/Downloads/media_build_experimental/v4l' failed
make[2]: *** [_module_/home/htpc/Downloads/media_build_experimental/v4l] Error 2
make[2]: Leaving directory '/usr/src/kernels/4.9.7-201.fc25.x86_64'
Makefile:51: recipe for target 'default' failed
make[1]: *** [default] Error 2
make[1]: Leaving directory '/home/htpc/Downloads/media_build_experimental/v4l'
Makefile:28: recipe for target 'all' failed
make: *** [all] Error 2

Which I fix by commenting out lines 1462 up to 1468 in
media_build_experimental/v4l/compat.h:

//static inline void *
//pci_zalloc_consistent(struct pci_dev *hwdev, size_t size,
// dma_addr_t *dma_handle)
//{
// return dma_alloc_coherent(hwdev == NULL ? NULL : &hwdev->dev,
// size, dma_handle, GFP_ATOMIC | __GFP_ZERO);
//}

Now it compiles and works fine. I still get these warnings:

media_build_experimental/v4l/compat.h:1552:0: warning:
"DMA_ATTR_SKIP_CPU_SYNC" redefined
 #define DMA_ATTR_SKIP_CPU_SYNC 0

Which I can easily remove by commenting out the specific line as well.

Now my questions are:
- is this the correct way to fix these compile errors? (I'm definately
not a professional developer)
- what can I do to have this solved in the source?

Besides that, I'm also wondering if these drivers have any change of
getting into kernel mainline?

Regards,

Martin

Re: Cine CT V6.1 code change request

[Hans Verkuil]

On 02/14/2017 09:59 PM, Martin Herrman wrote:
> All,
> 
> I have a Cine CT V6.1 in my fedora 25 based media center. It is now
> running a default fedora 4.9 kernel. I install the driver as follows:
> 
> hg clone https://linuxtv.org/hg/~endriss/media_build_experimental

I'm not sure what this media_build directory is. It certainly is
outdated. The latest media_build is here: https://git.linuxtv.org/media_build.git/

> cd media_build_experimental
> make download
> make untar
> make menuconfig
> make
> make install
> 
> However, I have to make two changes to the source to make it work.
> 
> Change 1: in media_build_experimental/v4l/Kconfig line 6936 I have to
> remove the whitespace in '--- help ---', otherwise make menuconfig
> fails.

Can you show that line and the surrounding lines? I.e. the whole menu
entry?

> Change 2: during compilation the following error occurs (since about
> kernel 4.5?):

Most likely because the media build you use is outdated.

> 
> make -C /lib/modules/4.9.7-201.fc25.x86_64/build
> SUBDIRS=/home/htpc/Downloads/media_build_experimental/v4l  modules
> make[2]: Entering directory '/usr/src/kernels/4.9.7-201.fc25.x86_64'
>   CC [M]  /home/htpc/Downloads/media_build_experimental/v4l/tuner-xc2028.o
> In file included from <command-line>:0:0:
> /home/htpc/Downloads/media_build_experimental/v4l/compat.h:1463:1:
> error: redefinition of 'pci_zalloc_consistent'
>  pci_zalloc_consistent(struct pci_dev *hwdev, size_t size,
>  ^~~~~~~~~~~~~~~~~~~~~
> In file included from ./include/linux/pci.h:2145:0,
>                  from
> /home/htpc/Downloads/media_build_experimental/v4l/compat.h:1459,
>                  from <command-line>:0:
> ./include/linux/pci-dma-compat.h:23:1: note: previous definition of
> 'pci_zalloc_consistent' was here
>  pci_zalloc_consistent(struct pci_dev *hwdev, size_t size,
>  ^~~~~~~~~~~~~~~~~~~~~
> In file included from <command-line>:0:0:
> /home/htpc/Downloads/media_build_experimental/v4l/compat.h:1552:0:
> warning: "DMA_ATTR_SKIP_CPU_SYNC" redefined
>  #define DMA_ATTR_SKIP_CPU_SYNC 0
> 
> In file included from ./include/linux/pci-dma-compat.h:7:0,
>                  from ./include/linux/pci.h:2145,
>                  from
> /home/htpc/Downloads/media_build_experimental/v4l/compat.h:1459,
>                  from <command-line>:0:
> ./include/linux/dma-mapping.h:47:0: note: this is the location of the
> previous definition
>  #define DMA_ATTR_SKIP_CPU_SYNC  (1UL << 5)
> 
> scripts/Makefile.build:299: recipe for target
> '/home/htpc/Downloads/media_build_experimental/v4l/tuner-xc2028.o'
> failed
> make[3]: *** [/home/htpc/Downloads/media_build_experimental/v4l/tuner-xc2028.o]
> Error 1
> Makefile:1494: recipe for target
> '_module_/home/htpc/Downloads/media_build_experimental/v4l' failed
> make[2]: *** [_module_/home/htpc/Downloads/media_build_experimental/v4l] Error 2
> make[2]: Leaving directory '/usr/src/kernels/4.9.7-201.fc25.x86_64'
> Makefile:51: recipe for target 'default' failed
> make[1]: *** [default] Error 2
> make[1]: Leaving directory '/home/htpc/Downloads/media_build_experimental/v4l'
> Makefile:28: recipe for target 'all' failed
> make: *** [all] Error 2
> 
> Which I fix by commenting out lines 1462 up to 1468 in
> media_build_experimental/v4l/compat.h:
> 
> //static inline void *
> //pci_zalloc_consistent(struct pci_dev *hwdev, size_t size,
> // dma_addr_t *dma_handle)
> //{
> // return dma_alloc_coherent(hwdev == NULL ? NULL : &hwdev->dev,
> // size, dma_handle, GFP_ATOMIC | __GFP_ZERO);
> //}
> 
> Now it compiles and works fine. I still get these warnings:
> 
> media_build_experimental/v4l/compat.h:1552:0: warning:
> "DMA_ATTR_SKIP_CPU_SYNC" redefined
>  #define DMA_ATTR_SKIP_CPU_SYNC 0
> 
> Which I can easily remove by commenting out the specific line as well.
> 
> Now my questions are:
> - is this the correct way to fix these compile errors? (I'm definately
> not a professional developer)
> - what can I do to have this solved in the source?
> 
> Besides that, I'm also wondering if these drivers have any change of
> getting into kernel mainline?

Which driver?

Regards,

	Hans

Re: Cine CT V6.1 code change request

[Martin Herrman]

2017-02-15 8:55 GMT+01:00 Hans Verkuil <hverkuil@xs4all.nl>:

Hi Hans,

Thanks for the quick response!

> I'm not sure what this media_build directory is. It certainly is
> outdated. The latest media_build is here: https://git.linuxtv.org/media_build.git/

And thanks for sharing!

> Can you show that line and the surrounding lines? I.e. the whole menu
> entry?

Of course, here it is:

if STAGING
menu "Media devices in staging"

config STAGING_BROKEN
bool "Enable drivers that are known to not compile"
default n
--- help ---
 Say N here, except if you will be fixing the drivers
 compilation.

menuconfig STAGING_MEDIA

> Most likely because the media build you use is outdated.

I cloned the latest repository and build it, all went fine, however.. (read on)

> Which driver?

This is my device:

02:00.0 Multimedia controller: Digital Devices GmbH Octopus DVB Adapter
Subsystem: Digital Devices GmbH Cine CT V6.1 DVB adapter
Flags: bus master, fast devsel, latency 0, IRQ 32
Memory at fbcf0000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [50] Power Management version 3
Capabilities: [70] MSI: Enable+ Count=1/2 Maskable- 64bit+
Capabilities: [90] Express Endpoint, MSI 00
Capabilities: [100] Vendor Specific Information: ID=0000 Rev=0 Len=00c <?>
Kernel driver in use: ddbridge
Kernel modules: ddbridge

I am using the following modules:

[htpc@htpc ~]$ lsmod | grep dd
tda18212dd             20480  2
stv0367dd              24576  2
ddbridge               90112  29
cxd2099                20480  1 ddbridge
dvb_core              102400  1 ddbridge

The ddbridge and cxd2099 are in the latest media_build, but the
stv0367dd and tda18212dd are missing (however, the stv0367 and
tda18212 are available). How hard is it to add these two?

Regards,

Martin

> Regards,
>
>         Hans
>

Re: Cine CT V6.1 code change request

[Daniel Scheller]

Wed, 15 Feb 2017 20:20:58 +0100 Martin Herrman
<martin.herrman@gmail.com>:

Hi Martin,

> The ddbridge and cxd2099 are in the latest media_build, but the
> stv0367dd and tda18212dd are missing (however, the stv0367 and
> tda18212 are available). How hard is it to add these two?

For someone who has some knowledge on the stv0367 demods, it's probably
not very hard.

While I don't have that knowledge, I've started tackling
the "in-kernel" stv0367 module to work as a replacement for DD's
stv0367dd anyway, and while I didn't get very far yet, this is what I
found out so far:

- stv0367dd always provides multiple delivery systems (DVB-C, DVB-T)
  when attached, where stv0367 needs multiple frontends for each
  delivery systems, e.g. you need to attach the -T and -C
  frontends separately. Basically, this is also the case in the
  stv0367dd, but it has some sort of "wrapper" ontop which does the
  QAM/OFDM operation mode switch transparently.
- When attaching only one of the two -T/-C code paths, there's still
  something more that needs to be done. With the QAM path, I got the
  demod to somewhat do some work (it reported signal statistics when
  tuned to a frequency) but didn't properly send the transport stream
  to the bridge.
- stv0367dd runs at 58MHz IC speed for the QAM mode, but this is rather
  easy to add since (what I could find out so far) it just requires
  different values poked into the PLLxDIV regs.
- The i2c_gate_ctrl() in stv0367 must not be called from inside the
  demod driver (thinking of a config flag to toggle this) since
  ddbridge remaps the function pointers to a mutex_lock'ed variant,
  which in turn will cause a deadlock when the demod driver triggers
  the i2c_gate itself.

The biggest problem at the moment is 2., e.g. get the transport to the
bridge working. 1. should be fairly easy to do, 3. and 4. are done. See
[1] for my attempt on this. But generally speaking, the stv0367 driver
should work even with DD cards with a few additions.

The TDA18212 "in-tree" tuner frontend works perfectly with the STV and
also the CXD28xx-based tuners. The work on this was done in around 2013
or so by Antti Palosaari (see [2]), and it worked out so nicely when I
first started tackling things I never cared to pick up the
tda18212DD :-)

Best regards,
Daniel Scheller

[1]
https://github.com/herrnst/dddvb-linux-kernel/compare/attic/old-0_9_23-0_9_28-mediatree/master-ddbridge-cttesting-cxd...attic/old-0_9_23-0_9_28-mediatree/master-ddbridge-cttesting-stv
[2]
https://github.com/herrnst/dddvb-linux-kernel/commit/905c999f69e58e2c54be24bd7ec6c86ec2ef1e65

Re: Cine CT V6.1 code change request

[Martin Herrman]

2017-02-19 14:27 GMT+01:00 Daniel Scheller <d.scheller.oss@gmail.com>:
>
> Hi Martin,
>
> For someone who has some knowledge on the stv0367 demods, it's probably
> not very hard.
>
> While I don't have that knowledge, I've started tackling
> the "in-kernel" stv0367 module to work as a replacement for DD's
> stv0367dd anyway, and while I didn't get very far yet, this is what I
> found out so far:
>
> - stv0367dd always provides multiple delivery systems (DVB-C, DVB-T)
>   when attached, where stv0367 needs multiple frontends for each
>   delivery systems, e.g. you need to attach the -T and -C
>   frontends separately. Basically, this is also the case in the
>   stv0367dd, but it has some sort of "wrapper" ontop which does the
>   QAM/OFDM operation mode switch transparently.
> - When attaching only one of the two -T/-C code paths, there's still
>   something more that needs to be done. With the QAM path, I got the
>   demod to somewhat do some work (it reported signal statistics when
>   tuned to a frequency) but didn't properly send the transport stream
>   to the bridge.
> - stv0367dd runs at 58MHz IC speed for the QAM mode, but this is rather
>   easy to add since (what I could find out so far) it just requires
>   different values poked into the PLLxDIV regs.
> - The i2c_gate_ctrl() in stv0367 must not be called from inside the
>   demod driver (thinking of a config flag to toggle this) since
>   ddbridge remaps the function pointers to a mutex_lock'ed variant,
>   which in turn will cause a deadlock when the demod driver triggers
>   the i2c_gate itself.
>
> The biggest problem at the moment is 2., e.g. get the transport to the
> bridge working. 1. should be fairly easy to do, 3. and 4. are done. See
> [1] for my attempt on this. But generally speaking, the stv0367 driver
> should work even with DD cards with a few additions.
>
> The TDA18212 "in-tree" tuner frontend works perfectly with the STV and
> also the CXD28xx-based tuners. The work on this was done in around 2013
> or so by Antti Palosaari (see [2]), and it worked out so nicely when I
> first started tackling things I never cared to pick up the
> tda18212DD :-)
>
> Best regards,
> Daniel Scheller
>
> [1]
> https://github.com/herrnst/dddvb-linux-kernel/compare/attic/old-0_9_23-0_9_28-mediatree/master-ddbridge-cttesting-cxd...attic/old-0_9_23-0_9_28-mediatree/master-ddbridge-cttesting-stv
> [2]
> https://github.com/herrnst/dddvb-linux-kernel/commit/905c999f69e58e2c54be24bd7ec6c86ec2ef1e65

Hi Daniel,

Thanks for starting this investigation! If I'm understanding
correctly, there is some work to do, but it can be done and is not a
huge amount of work. (But it is more than just moving something from
the old repo and fixing some errors/warnings.)

I'm not familiar with the linux-media way of organizing the work, or
how priorities are set (on the backlog?). What should be the next step
and what can I do to have this feature/enhancement picked up? I'm not
a developer, but I own the hardware and thus I am able to test any new
code. If there might anything else I can do, please let me know.

Thanks,

Martin