cron job: media_tree daily build: ERRORS
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: Wed Jan 18 05:00:18 CET 2017 media-tree git hash:40eca140c404505c09773d1c6685d818cb55ab1a media_build git hash: 3c6ce4ff75f19adf45869e34b376c5b9dee4d50a v4l-utils git hash: bc29784e7a3d27f996f7134ad1117985adf103d7 gcc version:i686-linux-gcc (GCC) 6.2.0 sparse version: v0.5.0-3553-g78b2ea6 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.8.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: 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.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: WARNINGS linux-3.11.1-i686: OK linux-3.12.67-i686: OK linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0.9-i686: WARNINGS linux-4.1.33-i686: WARNINGS linux-4.2.8-i686: WARNINGS linux-4.3.6-i686: WARNINGS linux-4.4.22-i686: WARNINGS linux-4.5.7-i686: WARNINGS linux-4.6.7-i686: WARNINGS linux-4.7.5-i686: WARNINGS linux-4.8-i686: OK linux-4.9-i686: OK linux-4.10-rc3-i686: OK linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: OK linux-3.12.67-x86_64: OK linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16.7-x86_64: WARNINGS linux-3.17.8-x86_64: WARNINGS linux-3.18.7-x86_64: WARNINGS linux-3.19-x86_64: WARNINGS linux-4.0.9-x86_64: WARNINGS linux-4.1.33-x86_64: WARNINGS linux-4.2.8-x86_64: WARNINGS linux-4.3.6-x86_64: WARNINGS linux-4.4.22-x86_64: WARNINGS linux-4.5.7-x86_64: WARNINGS linux-4.6.7-x86_64: WARNINGS linux-4.7.5-x86_64: WARNINGS linux-4.8-x86_64: OK linux-4.9-x86_64: OK linux-4.10-rc3-x86_64: OK apps: WARNINGS spec-git: ERRORS sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.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
[PATCH 2/2] [media] exynos-gsc: Fix imprecise external abort due disabled power domain
Commit 15f90ab57acc ("[media] exynos-gsc: Make driver functional when CONFIG_PM is unset") removed the implicit dependency that the driver had with CONFIG_PM, since it relied on the config option to be enabled. In order to work with !CONFIG_PM, the GSC reset logic that happens in the runtime resume callback had to be executed on the probe function. The problem is that if CONFIG_PM is enabled, the power domain for the GSC could be disabled and so an attempt to write to the GSC_SW_RESET register leads to an unhandled fault / imprecise external abort error: [ 10.178825] Unhandled fault: imprecise external abort (0x1406) at 0x [ 10.186982] pgd = ed728000 [ 10.190847] [] *pgd= [ 10.195553] Internal error: : 1406 [#1] PREEMPT SMP ARM [ 10.229761] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 10.237134] task: ed49e400 task.stack: ed724000 [ 10.242934] PC is at gsc_wait_reset+0x5c/0x6c [exynos_gsc] [ 10.249710] LR is at gsc_probe+0x300/0x33c [exynos_gsc] [ 10.256139] pc : []lr : []psr: 60070013 [ 10.256139] sp : ed725d30 ip : fp : 0001 [ 10.271492] r10: eea74800 r9 : ecd6a2c0 r8 : ed7d8854 [ 10.277912] r7 : ed7d8c08 r6 : ed7d8810 r5 : 8ecd r4 : c0c03900 [ 10.285664] r3 : r2 : 0001 r1 : ed7d8b98 r0 : ed7d8810 So only do a GSC reset if CONFIG_PM is disabled, since if is enabled the runtime PM resume callback will be called by the VIDIOC_STREAMON ioctl, making the reset in probe unneeded. Fixes: 15f90ab57acc ("[media] exynos-gsc: Make driver functional when CONFIG_PM is unset") Signed-off-by: Javier Martinez Canillas--- I-ve only tested with CONFIG_PM enabled since my Exynos5422 Odroid XU4 board fails to boot when the config option is disabled. Best regards, Javier drivers/media/platform/exynos-gsc/gsc-core.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c index 83272f10722d..42e1e09ea915 100644 --- a/drivers/media/platform/exynos-gsc/gsc-core.c +++ b/drivers/media/platform/exynos-gsc/gsc-core.c @@ -1083,8 +1083,10 @@ static int gsc_probe(struct platform_device *pdev) platform_set_drvdata(pdev, gsc); - gsc_hw_set_sw_reset(gsc); - gsc_wait_reset(gsc); + if (!IS_ENABLED(CONFIG_PM)) { + gsc_hw_set_sw_reset(gsc); + gsc_wait_reset(gsc); + } vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32)); -- 2.7.4 -- 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
[PATCH 1/2] [media] exynos-gsc: Fix unbalanced pm_runtime_enable() error
Commit a006c04e6218 ("[media] exynos-gsc: Fixup clock management at ->remove()") changed the driver's .remove function logic to fist do a pm_runtime_get_sync() to make sure the device is powered before attempting to gate the gsc clock. But the commit also removed a pm_runtime_disable() call that leads to an unbalanced pm_runtime_enable() error if the driver is removed and re-probed: exynos-gsc 13e0.video-scaler: Unbalanced pm_runtime_enable! exynos-gsc 13e1.video-scaler: Unbalanced pm_runtime_enable! Fixes: a006c04e6218 ("[media] exynos-gsc: Fixup clock management at ->remove()") Signed-off-by: Javier Martinez Canillas--- drivers/media/platform/exynos-gsc/gsc-core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c index cbf75b6194b4..83272f10722d 100644 --- a/drivers/media/platform/exynos-gsc/gsc-core.c +++ b/drivers/media/platform/exynos-gsc/gsc-core.c @@ -1118,6 +1118,7 @@ static int gsc_remove(struct platform_device *pdev) clk_disable_unprepare(gsc->clock[i]); pm_runtime_put_noidle(>dev); + pm_runtime_disable(>dev); dev_dbg(>dev, "%s driver unloaded\n", pdev->name); return 0; -- 2.7.4 -- 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: [PATCH] cxd2820r: fix gpio null pointer dereference
Works here also ! Thanks. /Håkan On 2017-01-17 21:43, Chris Rankin wrote: On 16 January 2017 at 23:40, Antti Palosaariwrote: Chris and Håkan, test please without Kconfig CONFIG_GPIOLIB option. I cannot test it properly as there seems to quite many drivers selecting this option by default. Works here :-) Tested-by: Chris Rankin [ 125.162762] usb 4-4: new high-speed USB device number 4 using ehci-pci [ 125.326832] em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, interface 0, class 0) [ 125.334573] em28xx: DVB interface 0 found: isoc [ 125.337981] em28xx: chip ID is em28174 [ 125.674813] em28174 #0: EEPROM ID = 26 00 01 00, EEPROM hash = 0x1eb936d2 [ 125.680331] em28174 #0: EEPROM info: [ 125.682610] em28174 #0: microcode start address = 0x0004, boot configuration = 0x01 [ 125.716963] em28174 #0: No audio on board. [ 125.719856] em28174 #0: 500mA max power [ 125.722495] em28174 #0: Table at offset 0x39, strings=0x1aa0, 0x14ba, 0x1ace [ 125.728384] em28174 #0: Identified as PCTV nanoStick T2 290e (card=78) [ 125.733669] em28174 #0: dvb set to isoc mode. [ 125.736863] usbcore: registered new interface driver em28xx [ 125.751373] em28174 #0: Binding DVB extension [ 125.763306] cxd2820r 11-006c: Sony CXD2820R successfully identified [ 125.770763] tda18271 11-0060: creating new instance [ 125.783435] tda18271: TDA18271HD/C2 detected @ 11-0060 [ 125.980162] DVB: registering new adapter (em28174 #0) [ 125.983923] usb 4-4: DVB: registering adapter 0 frontend 0 (Sony CXD2820R)... [ 125.991316] em28174 #0: DVB extension successfully initialized [ 125.995962] em28xx: Registered (Em28xx dvb Extension) extension [ 126.003999] em28174 #0: Registering input extension [ 126.035656] Registered IR keymap rc-pinnacle-pctv-hd [ 126.039589] input: em28xx IR (em28174 #0) as /devices/pci:00/:00:1d.7/usb4/4-4/rc/rc0/input23 [ 126.047940] rc rc0: em28xx IR (em28174 #0) as /devices/pci:00/:00:1d.7/usb4/4-4/rc/rc0 [ 126.056022] em28174 #0: Input extension successfully initalized [ 126.060706] em28xx: Registered (Em28xx Input Extension) extension Cheers, Chris -- 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: [PATCH] cxd2820r: fix gpio null pointer dereference
On 16 January 2017 at 23:40, Antti Palosaariwrote: > Chris and Håkan, test please without Kconfig CONFIG_GPIOLIB option. I cannot > test it properly as there seems to quite many drivers selecting this option > by default. Works here :-) Tested-by: Chris Rankin [ 125.162762] usb 4-4: new high-speed USB device number 4 using ehci-pci [ 125.326832] em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, interface 0, class 0) [ 125.334573] em28xx: DVB interface 0 found: isoc [ 125.337981] em28xx: chip ID is em28174 [ 125.674813] em28174 #0: EEPROM ID = 26 00 01 00, EEPROM hash = 0x1eb936d2 [ 125.680331] em28174 #0: EEPROM info: [ 125.682610] em28174 #0: microcode start address = 0x0004, boot configuration = 0x01 [ 125.716963] em28174 #0: No audio on board. [ 125.719856] em28174 #0: 500mA max power [ 125.722495] em28174 #0: Table at offset 0x39, strings=0x1aa0, 0x14ba, 0x1ace [ 125.728384] em28174 #0: Identified as PCTV nanoStick T2 290e (card=78) [ 125.733669] em28174 #0: dvb set to isoc mode. [ 125.736863] usbcore: registered new interface driver em28xx [ 125.751373] em28174 #0: Binding DVB extension [ 125.763306] cxd2820r 11-006c: Sony CXD2820R successfully identified [ 125.770763] tda18271 11-0060: creating new instance [ 125.783435] tda18271: TDA18271HD/C2 detected @ 11-0060 [ 125.980162] DVB: registering new adapter (em28174 #0) [ 125.983923] usb 4-4: DVB: registering adapter 0 frontend 0 (Sony CXD2820R)... [ 125.991316] em28174 #0: DVB extension successfully initialized [ 125.995962] em28xx: Registered (Em28xx dvb Extension) extension [ 126.003999] em28174 #0: Registering input extension [ 126.035656] Registered IR keymap rc-pinnacle-pctv-hd [ 126.039589] input: em28xx IR (em28174 #0) as /devices/pci:00/:00:1d.7/usb4/4-4/rc/rc0/input23 [ 126.047940] rc rc0: em28xx IR (em28174 #0) as /devices/pci:00/:00:1d.7/usb4/4-4/rc/rc0 [ 126.056022] em28174 #0: Input extension successfully initalized [ 126.060706] em28xx: Registered (Em28xx Input Extension) extension Cheers, Chris -- 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: Request API: stateless VPU: the buffer mechanism and DPB management
On 01/17/2017 10:59 PM, Nicolas Dufresne wrote: Le mardi 17 janvier 2017 à 20:46 +0800, herman.c...@rock-chips.com a écrit : If we move parser or part of DPB management mechanism into kernel we will face a issue as follows: One customer requires dpb management do a flush when stream occurs in order to keep output frame clean. While another one requires output frame with error to keep output frame smooth. And when only one field has a error one customer wants to do a simple field copy to recover. The driver should send all frames and simply mark the corrupted frames using V4L2_BUF_FLAG_ERROR. This way, the userspace can then make their own decision. It is also important to keep track and cleanup the buffers meta's (which are application specific). If the driver silently drops frame, it makes that management much harder. About flushing and draining operation, they are respectively signalled to the driver using STREAMOFF and CMD_STOP. These are some operation related to strategy rather then mechanism. I think it is not a good idea to bring such kind of flexible process to kernel driver. So here is the ultimate challenge that how to reasonably move the parser and flexible process which is encapsuled in firmware to a userspace - kernel stateless driver model. Moving the parsers in the kernel (on the main CPU) is not acceptable. No, what is not what I said. What I want to do is "The whole plan in userspace is just injecting a parsing operation and set those v4l2 control in kernel before enqueue a buffer into OUTPUT, which would keep the most compatible with those stateful video IP(those with a firmware). " This is too much of a security threat. Userspace should parse the data into structures, doing any validation required before end. My main question and that should have an impact decision, is if those structures can be made generic. PDB handling is not that trivial (my reference is VAAPI here, maybe they are doing it wrong) and with driver specific structures, we would have this code copy-pasted over and over. So with driver specific structures, it's probably better to keep all the parsing and reordering logic outside (hence together). The result to keep DPB and re-order inside the kernel is want to be compatible with the original buffer operation. Anyway the DPB structure could be common. That remains, that some driver will deal with reordering on the firmware side (even the if they don't parse), hence we need to take this into consideration. No sure what do you mean, I think all those driver with firmware would do that. regards, Nicolas Hello all: I have recently finish the learning of the H.264 codec and ready to write the driver. Although I have not get deep in syntax of H.264 but I think I just need to reuse and extended the VA-API H264 Parser from gstreamer. The whole plan in userspace is just injecting a parsing operation and set those v4l2 control in kernel before enqueue a buffer into OUTPUT, which would keep the most compatible with those stateful video IP(those with a firmware). But in order to do that, I can't avoid the management of DPB. I decided to moving the DPB management job from userspace in kernel. Also the video IP(On2 on rk3288 and the transition video IP on those future SoC than rk3288, rkv don't have this problem) would a special way to manage the DPB, which requests the same reference frame is storing in the same reference index in the runtime(actually it is its Motion Vector data appended in decoded YUV data would not be moved). I would suggest to keep those job in kernel, the userspace just to need update the list0 and list1 of DPB. DPB is self managed in kernel the userspace don't need to even dequeue the buffer from CAPTURE until the re-order is done. The kernel driver would also re-order the CAPTURE buffer into display order, and blocking the operation on CAPTURE until a buffer is ready to place in the very display order. If I don't do that, I have to get the buffer once it is decoded, and marking its result with the poc, I could only begin the processing of the next frame only after those thing are done. Which would effect the performance badly. That is what chromebook did(I hear that from the other staff, I didn't get invoke in chromium project yet). So I would suggest that doing the re-order job in kernel, and inform the the userspace the buffers are ready when the new I frame(key frame) is pushed into the video IP. Although moving those job into kernel would increase the loading, but I think it is worth to do that, but I don't know whether all those thought are correct and high performance(It is more important than API compatible especially for those 4K video). And I want to know more ideas about this topic. I would begin the writing the new driver after the coming culture new year vacation(I would go to the Europe), I wish we can decide the final mechanism before I begin this job. -- To unsubscribe from this
Re: Request API: stateless VPU: the buffer mechanism and DPB management
Le mardi 17 janvier 2017 à 20:46 +0800, herman.c...@rock-chips.com a écrit : > If we move parser or part of DPB management mechanism into kernel we > will face a issue as follows: > One customer requires dpb management do a flush when stream occurs in > order to keep output frame clean. > While another one requires output frame with error to keep output > frame smooth. > And when only one field has a error one customer wants to do a simple > field copy to recover. The driver should send all frames and simply mark the corrupted frames using V4L2_BUF_FLAG_ERROR. This way, the userspace can then make their own decision. It is also important to keep track and cleanup the buffers meta's (which are application specific). If the driver silently drops frame, it makes that management much harder. About flushing and draining operation, they are respectively signalled to the driver using STREAMOFF and CMD_STOP. > > These are some operation related to strategy rather then mechanism. > I think it is not a good idea to bring such kind of flexible process > to kernel driver. > > So here is the ultimate challenge that how to reasonably move the > parser and flexible process > which is encapsuled in firmware to a userspace - kernel stateless > driver model. Moving the parsers in the kernel (on the main CPU) is not acceptable. This is too much of a security threat. Userspace should parse the data into structures, doing any validation required before end. My main question and that should have an impact decision, is if those structures can be made generic. PDB handling is not that trivial (my reference is VAAPI here, maybe they are doing it wrong) and with driver specific structures, we would have this code copy-pasted over and over. So with driver specific structures, it's probably better to keep all the parsing and reordering logic outside (hence together). That remains, that some driver will deal with reordering on the firmware side (even the if they don't parse), hence we need to take this into consideration. regards, Nicolas -- 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: em28xx failed with kernel 3.14.79
I played a little around with it and i think, the "submit of audio urb failed" message is not the main reason. Any ideas, why I do not get a /dev/dvb/... ? greetings Am 16.01.2017 um 14:32 schrieb em28xx PCTV 520e: Hi, I'm using a PCTV 520e usb dvb-c device at an ODROID-C2, running ubuntu with kernel 3.14.79. I'd like to use the lates media build drivers. However, if I do so, I get the following output with dmesg: [ 132.288365] usb 1-1.1: new high-speed USB device number 4 using dwc_otg ...snip.. [ 133.918431] em28xx 1-1.1:1.0: submit of audio urb failed (error=-90) ...snip.. [ 133.948866] em28xx: Registered (Em28xx Input Extension) extension Finally, there is no /dev/dvb/... created. I guess because of the [ 133.918431] em28xx 1-1.1:1.0: submit of audio urb failed (error=-90) message. Can any1 help me with this? 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 -- 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