Re: Cine CT V6.1 code change request
2017-02-19 14:27 GMT+01:00 Daniel Scheller: > > 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
Re: Cine CT V6.1 code change request
Wed, 15 Feb 2017 20:20:58 +0100 Martin Herrman: 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
2017-02-15 8:55 GMT+01:00 Hans Verkuil: 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 fbcf (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= 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 cxd209920480 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
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 :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 :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 :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 :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 : >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
Cine CT V6.1 code change request
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 :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 :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 :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 :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 : >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