cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu Jul 2 04:00:20 CEST 2015 git branch: test git hash: 5bab86243d949cf021b0f104faafc18f5d20283c gcc version:i686-linux-gcc (GCC) 5.1.0 sparse version: v0.5.0-44-g40791b9 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:4.0.0-3.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-i686: OK linux-4.1-rc1-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-x86_64: OK linux-4.1-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC5000C 0x14b4 status
IMHO, the best is to get the latest firmware licensed is the best thing to do. Does that "new" xc5000c come with a firmware pre-loaded already? I've got firmware here that is indicated as being for the xc5300 (i.e. 0x14b4). That said, I am not sure if it's the same as the original 5000c firmware. Definitely makes sense to do an I2C dump and compare the firmware images since using the wrong firmware can damage the part. I'm not against an additional #define for the 0x14b4 part ID, but it shouldn't be accepted upstream until we have corresponding firmware and have seen the tuner working. Do you have digital signal lock working with this device under Linux and the issue is strictly with part identification? Hello. There are new details. My assumption, that such behaviour of IC can be because of an old or incorrect (for that HW) firmware, was wrong. It does not matter which FW version we use. With a fresh (beginning of 2015) media_build, even with an "old" firmware, RF tuner always and stably returns status 0x14b4. Also it's stably detects an already loaded firmware from another instance of the driver (analog part initialisation). And there is no i2c errors. With an old media_build from beginning of 2014, there is some problem with detection of already loaded firmware, there is i2c errors, and it gives the 50/50 status either 0x1388 or 0x14b4. My mistake I didn't checked a fresh media_build before. So, the only thing we need is to add an additional #define for the 0x14b4 part ID to a driver's code, as I wrote before. If you have any more questions, please ask. Best regards. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: randconfig build error with next-20150620, in drivers/media/v4l2-core/videobuf2-core.c
On 06/20/15 09:44, Jim Davis wrote: > Building with the attached random configuration file, > > drivers/media/v4l2-core/videobuf2-core.c: In function > ‘vb2_warn_zero_bytesused’: > drivers/media/v4l2-core/videobuf2-core.c:1253:2: error: implicit declaration > of > function ‘__WARN’ [-Werror=implicit-function-declaration] > __WARN(); > ^ > When CONFIG_BUG is not enabled, there is no definition of __WARN(). Should be add an empty stub for __WARN() or just change the only user (caller) of it to do something different? -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx23885 risc op code error with DvbSKY T982
01.07.2015, 12:13, Hans Verkuil kirjoitti: Do you actually see any visual artifacts, or is it just messages in the log? hi, I am pretty certain that these are minor problems. The cards seem to work fine after the messages, so I would not call this urgent. Some recordings have visual artefacts, but I do not know whether they happen because of these events or because of the broadcast transmission or for some other reason. These occur every few hours in the log/ or a few times a day (with three cx23885 based cards on the PCIe bus). I started to look at the driver as for 3.19 kernel coming with ubuntu (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1451009) the cards seemed to crash. For 4.0.6 and 4.1.0 the cards work, but as I was already looking at this, I decided to report these. If you think these messages are not worth more effort, I am OK with it. yours, Jouni -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Porting dma-fence and dma-buf from 4.1 to 3.10 kernel
Hello All, We need to port dma fence and dma buf frame work to 3.10 kernel from 4.1 kernel. It seems a huge changes happened to 4.1 to 3.10. I am trying to figure out difficulties before porting the same. Can you please point out difficulties to port dma-fence and dma-buf to 3.10 kernel? Thanks and regards, Ayyappa.Ch -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx23885 risc op code error with DvbSKY T982
On 07/01/15 11:11, Jouni Karvo wrote: > 29.06.2015, 12:39, Jouni Karvo kirjoitti: >> 22.06.2015, 12:55, Tycho Lürsen kirjoitti: >>> I've got a couple of T982 cards. Running Debian Jessie, with kernel >>> 4.1-rc8, I cannot reproduce your errors. >>> Only difference might be: >>> I synced the silabs drivers with upstream and used the patch from: >> >> hi, >> >> I tested with 4.1.0 (which produced the errors. 4.1.0 with media_build >> produced the errors. I did not test that with the patch, as because of >> another kernel bug (in mdraid) I switched to 4.0.6. >> >> With 4.0.6 this error does not seem to happen with neither card. > > Just as I reported, it happened. Then I got the media_build driver from Jun > 25 (which seems to include the IF selection patch), and there it happens > again... Do you actually see any visual artifacts, or is it just messages in the log? Regards, Hans > > Jun 30 21:16:40 xpc kernel: [11870.833240] cx23885[1]: mpeg risc op code error > Jun 30 21:16:40 xpc kernel: [11870.833244] cx23885[1]: TS1 B - dma channel > status dump > Jun 30 21:16:40 xpc kernel: [11870.833247] cx23885[1]: cmds: init risc lo > : 0x924d > Jun 30 21:16:40 xpc kernel: [11870.833248] cx23885[1]: cmds: init risc hi > : 0x > Jun 30 21:16:40 xpc kernel: [11870.833250] cx23885[1]: cmds: cdt base > : 0x00010580 > Jun 30 21:16:40 xpc kernel: [11870.833252] cx23885[1]: cmds: cdt size > : 0x000a > Jun 30 21:16:40 xpc kernel: [11870.833254] cx23885[1]: cmds: iq base > : 0x00010400 > Jun 30 21:16:40 xpc kernel: [11870.833256] cx23885[1]: cmds: iq size > : 0x0010 > Jun 30 21:16:40 xpc kernel: [11870.833257] cx23885[1]: cmds: risc pc lo > : 0x924d000c > Jun 30 21:16:40 xpc kernel: [11870.833259] cx23885[1]: cmds: risc pc hi > : 0x > Jun 30 21:16:40 xpc kernel: [11870.833261] cx23885[1]: cmds: iq wr ptr > : 0x4103 > Jun 30 21:16:40 xpc kernel: [11870.833263] cx23885[1]: cmds: iq rd ptr > : 0x4100 > Jun 30 21:16:40 xpc kernel: [11870.833264] cx23885[1]: cmds: cdt current > : 0x000105c8 > Jun 30 21:16:40 xpc kernel: [11870.833266] cx23885[1]: cmds: pci target lo > : 0xaed882f0 > Jun 30 21:16:40 xpc kernel: [11870.833268] cx23885[1]: cmds: pci target hi > : 0x > Jun 30 21:16:40 xpc kernel: [11870.833270] cx23885[1]: cmds: line / byte > : 0x0161 > Jun 30 21:16:40 xpc kernel: [11870.833272] cx23885[1]: risc0: 0x1c0002f0 [ > write sol eol count=752 ] > Jun 30 21:16:40 xpc kernel: [11870.833275] cx23885[1]: risc1: 0xaed882f0 [ > readc sol eol irq2 23 22 20 19 resync count=752 ] > Jun 30 21:16:40 xpc kernel: [11870.833279] cx23885[1]: risc2: 0x [ > INVALID count=0 ] > Jun 30 21:16:40 xpc kernel: [11870.833281] cx23885[1]: risc3: 0x1c0002f0 [ > write sol eol count=752 ] > Jun 30 21:16:40 xpc kernel: [11870.833284] cx23885[1]: (0x00010400) iq 0: > 0x80200080 [ sync 21 count=128 ] > Jun 30 21:16:40 xpc kernel: [11870.833286] cx23885[1]: (0x00010404) iq 1: > 0x87ff3140 [ sync eol irq2 irq1 23 22 21 20 19 18 cnt1 cnt0 13 12 count=320 ] > Jun 30 21:16:40 xpc kernel: [11870.833291] cx23885[1]: (0x00010408) iq 2: > 0x0100 [ INVALID irq1 count=0 ] > Jun 30 21:16:40 xpc kernel: [11870.833293] cx23885[1]: (0x0001040c) iq 3: > 0x [ INVALID count=0 ] > Jun 30 21:16:40 xpc kernel: [11870.833295] cx23885[1]: (0x00010410) iq 4: > 0x1c0002f0 [ write sol eol count=752 ] > Jun 30 21:16:40 xpc kernel: [11870.833298] cx23885[1]: iq 5: 0xaed88bc0 [ > arg #1 ] > Jun 30 21:16:40 xpc kernel: [11870.833300] cx23885[1]: iq 6: 0x [ > arg #2 ] > Jun 30 21:16:40 xpc kernel: [11870.833301] cx23885[1]: (0x0001041c) iq 7: > 0x7100 [ jump irq1 count=0 ] > Jun 30 21:16:40 xpc kernel: [11870.833304] cx23885[1]: iq 8: 0x1c0002f0 [ > arg #1 ] > Jun 30 21:16:40 xpc kernel: [11870.833306] cx23885[1]: iq 9: 0xaed88000 [ > arg #2 ] > Jun 30 21:16:40 xpc kernel: [11870.833307] cx23885[1]: (0x00010428) iq a: > 0x [ INVALID count=0 ] > Jun 30 21:16:40 xpc kernel: [11870.833309] cx23885[1]: (0x0001042c) iq b: > 0x1c0002f0 [ write sol eol count=752 ] > Jun 30 21:16:40 xpc kernel: [11870.833312] cx23885[1]: iq c: 0xaed882f0 [ > arg #1 ] > Jun 30 21:16:40 xpc kernel: [11870.833314] cx23885[1]: iq d: 0x [ > arg #2 ] > Jun 30 21:16:40 xpc kernel: [11870.833315] cx23885[1]: (0x00010438) iq e: > 0x1c0002f0 [ write sol eol count=752 ] > Jun 30 21:16:40 xpc kernel: [11870.833318] cx23885[1]: iq f: 0xaed885e0 [ > arg #1 ] > Jun 30 21:16:40 xpc kernel: [11870.833320] cx23885[1]: iq 10: 0x9beae2ae [ > arg #2 ] > Jun 30 21:16:40 xpc kernel: [11870.833320] cx23885[1]: fifo: 0x5000 -> > 0x6000 > Jun 30 21:16:40 xpc kernel: [11870.833321] cx23885[1]: ctrl: 0x00010400 -> > 0x10460 > Jun 30 21:16:40 xpc kernel: [11870.833323] cx23885[1]: ptr1_reg: 0x5bf0 > Jun 30 21:16:40 xpc kernel: [11870.833325] cx23885[1]: ptr2_reg: 0x000
Re: cx23885 risc op code error with DvbSKY T982
29.06.2015, 12:39, Jouni Karvo kirjoitti: 22.06.2015, 12:55, Tycho Lürsen kirjoitti: I've got a couple of T982 cards. Running Debian Jessie, with kernel 4.1-rc8, I cannot reproduce your errors. Only difference might be: I synced the silabs drivers with upstream and used the patch from: hi, I tested with 4.1.0 (which produced the errors. 4.1.0 with media_build produced the errors. I did not test that with the patch, as because of another kernel bug (in mdraid) I switched to 4.0.6. With 4.0.6 this error does not seem to happen with neither card. Just as I reported, it happened. Then I got the media_build driver from Jun 25 (which seems to include the IF selection patch), and there it happens again... Jun 30 21:16:40 xpc kernel: [11870.833240] cx23885[1]: mpeg risc op code error Jun 30 21:16:40 xpc kernel: [11870.833244] cx23885[1]: TS1 B - dma channel status dump Jun 30 21:16:40 xpc kernel: [11870.833247] cx23885[1]: cmds: init risc lo : 0x924d Jun 30 21:16:40 xpc kernel: [11870.833248] cx23885[1]: cmds: init risc hi : 0x Jun 30 21:16:40 xpc kernel: [11870.833250] cx23885[1]: cmds: cdt base : 0x00010580 Jun 30 21:16:40 xpc kernel: [11870.833252] cx23885[1]: cmds: cdt size : 0x000a Jun 30 21:16:40 xpc kernel: [11870.833254] cx23885[1]: cmds: iq base: 0x00010400 Jun 30 21:16:40 xpc kernel: [11870.833256] cx23885[1]: cmds: iq size: 0x0010 Jun 30 21:16:40 xpc kernel: [11870.833257] cx23885[1]: cmds: risc pc lo : 0x924d000c Jun 30 21:16:40 xpc kernel: [11870.833259] cx23885[1]: cmds: risc pc hi : 0x Jun 30 21:16:40 xpc kernel: [11870.833261] cx23885[1]: cmds: iq wr ptr : 0x4103 Jun 30 21:16:40 xpc kernel: [11870.833263] cx23885[1]: cmds: iq rd ptr : 0x4100 Jun 30 21:16:40 xpc kernel: [11870.833264] cx23885[1]: cmds: cdt current: 0x000105c8 Jun 30 21:16:40 xpc kernel: [11870.833266] cx23885[1]: cmds: pci target lo : 0xaed882f0 Jun 30 21:16:40 xpc kernel: [11870.833268] cx23885[1]: cmds: pci target hi : 0x Jun 30 21:16:40 xpc kernel: [11870.833270] cx23885[1]: cmds: line / byte: 0x0161 Jun 30 21:16:40 xpc kernel: [11870.833272] cx23885[1]: risc0: 0x1c0002f0 [ write sol eol count=752 ] Jun 30 21:16:40 xpc kernel: [11870.833275] cx23885[1]: risc1: 0xaed882f0 [ readc sol eol irq2 23 22 20 19 resync count=752 ] Jun 30 21:16:40 xpc kernel: [11870.833279] cx23885[1]: risc2: 0x [ INVALID count=0 ] Jun 30 21:16:40 xpc kernel: [11870.833281] cx23885[1]: risc3: 0x1c0002f0 [ write sol eol count=752 ] Jun 30 21:16:40 xpc kernel: [11870.833284] cx23885[1]: (0x00010400) iq 0: 0x80200080 [ sync 21 count=128 ] Jun 30 21:16:40 xpc kernel: [11870.833286] cx23885[1]: (0x00010404) iq 1: 0x87ff3140 [ sync eol irq2 irq1 23 22 21 20 19 18 cnt1 cnt0 13 12 count=320 ] Jun 30 21:16:40 xpc kernel: [11870.833291] cx23885[1]: (0x00010408) iq 2: 0x0100 [ INVALID irq1 count=0 ] Jun 30 21:16:40 xpc kernel: [11870.833293] cx23885[1]: (0x0001040c) iq 3: 0x [ INVALID count=0 ] Jun 30 21:16:40 xpc kernel: [11870.833295] cx23885[1]: (0x00010410) iq 4: 0x1c0002f0 [ write sol eol count=752 ] Jun 30 21:16:40 xpc kernel: [11870.833298] cx23885[1]: iq 5: 0xaed88bc0 [ arg #1 ] Jun 30 21:16:40 xpc kernel: [11870.833300] cx23885[1]: iq 6: 0x [ arg #2 ] Jun 30 21:16:40 xpc kernel: [11870.833301] cx23885[1]: (0x0001041c) iq 7: 0x7100 [ jump irq1 count=0 ] Jun 30 21:16:40 xpc kernel: [11870.833304] cx23885[1]: iq 8: 0x1c0002f0 [ arg #1 ] Jun 30 21:16:40 xpc kernel: [11870.833306] cx23885[1]: iq 9: 0xaed88000 [ arg #2 ] Jun 30 21:16:40 xpc kernel: [11870.833307] cx23885[1]: (0x00010428) iq a: 0x [ INVALID count=0 ] Jun 30 21:16:40 xpc kernel: [11870.833309] cx23885[1]: (0x0001042c) iq b: 0x1c0002f0 [ write sol eol count=752 ] Jun 30 21:16:40 xpc kernel: [11870.833312] cx23885[1]: iq c: 0xaed882f0 [ arg #1 ] Jun 30 21:16:40 xpc kernel: [11870.833314] cx23885[1]: iq d: 0x [ arg #2 ] Jun 30 21:16:40 xpc kernel: [11870.833315] cx23885[1]: (0x00010438) iq e: 0x1c0002f0 [ write sol eol count=752 ] Jun 30 21:16:40 xpc kernel: [11870.833318] cx23885[1]: iq f: 0xaed885e0 [ arg #1 ] Jun 30 21:16:40 xpc kernel: [11870.833320] cx23885[1]: iq 10: 0x9beae2ae [ arg #2 ] Jun 30 21:16:40 xpc kernel: [11870.833320] cx23885[1]: fifo: 0x5000 -> 0x6000 Jun 30 21:16:40 xpc kernel: [11870.833321] cx23885[1]: ctrl: 0x00010400 -> 0x10460 Jun 30 21:16:40 xpc kernel: [11870.833323] cx23885[1]: ptr1_reg: 0x5bf0 Jun 30 21:16:40 xpc kernel: [11870.833325] cx23885[1]: ptr2_reg: 0x000105c8 Jun 30 21:16:40 xpc kernel: [11870.833326] cx23885[1]: cnt1_reg: 0x0003 Jun 30 21:16:40 xpc kernel: [11870.833328] cx23885[1]: cnt2_reg: 0x0001 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org
AF9015 driver force reload firmware
Hi, Time to time my DVB-T usb dual tuner based on AF9015 stops to receive data. The symptom is: you can send any command to the driver and the device responds OK, but it don't sends packets. I suspect that the problem is inside the firmware, as when I force to use the second tuner, the device works as expected... until some time later the second tuner also suffers the same problem. In this case the only solution is disconnect the device and reconnect it. After this "cold" reboot, it returns to work. I try to substitute this solution to a "hot" reset of the device with these commands: # rmmod dvb_usb_af9015 # modprobe dvb_usb_af9015 But the dmesg shows: [398121.465865] dvb-usb: found a 'Dual DVB-T Stick' in warm state. And in this case the firmware isn't loaded in the device, then the device don't resets. So I suggest to modify the driver for supporting "force reload" of firmware, that I suspect will be equivalent to a "cold" reset of the device. Please, someone can try to implement this? Thank you! -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
