Re: v4l vs. dpdk
On 11/12/2015 07:54 AM, Ran Shalit wrote: > Hello, > > I hope you can assist me on the following debate. > > I need to develop a driver/application which capture and output video > frames from PCIe device , and is using Intel cpu (i7), and Intel's > media sdk server framework for the video compression. > > I am not sure what will be a better choice between the following 2 options: > 1. application which use dpdk for capture and output to the PCIe device > 2. v4l driver for the PCIe device > > Intel advocate the usage of dpdk (framework for packet processing). > dpdk is supposed to be able to read/write from PCIe device too. > I tried to see the prons/cons of dpdk compared to v4l. Of course they advocate it: it will lock you in to their CPU and their SDK. V4L2 is platform independent: your PCIe device will work just as well on other platforms and with any v4l2-aware application. > > prons of dpdk, as I understand them: > 1. userspace application (easier debugging compared to kernel > debugging of v4l device driver) But you probably have to do all the work and you can't use any of the frameworks v4l2 gives you to simplify driver development. > 2. supposed better performance 2 is nonsense. Video capture/output is just a matter of setting up the DMA and feeding it buffers. The CPU is barely involved. > > cons of dpdk compared to v4l: > 1. I could not find examples for PCIe device usage , or samples for > showing how application (such as media sdk) use dpdk video frames. That might be a hint that it is perhaps not the best choice. On the other hand, asking this on the linux-media mailinglist will give you a biased answer :-) Regards, Hans -- 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
v4l vs. dpdk
Hello, I hope you can assist me on the following debate. I need to develop a driver/application which capture and output video frames from PCIe device , and is using Intel cpu (i7), and Intel's media sdk server framework for the video compression. I am not sure what will be a better choice between the following 2 options: 1. application which use dpdk for capture and output to the PCIe device 2. v4l driver for the PCIe device Intel advocate the usage of dpdk (framework for packet processing). dpdk is supposed to be able to read/write from PCIe device too. I tried to see the prons/cons of dpdk compared to v4l. prons of dpdk, as I understand them: 1. userspace application (easier debugging compared to kernel debugging of v4l device driver) 2. supposed better performance cons of dpdk compared to v4l: 1. I could not find examples for PCIe device usage , or samples for showing how application (such as media sdk) use dpdk video frames. Thank you for any feedback on the matter, Regards, Ran -- 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
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: Thu Nov 12 04:00:17 CET 2015 git branch: test git hash: 79f5b6ae960d380c829fb67d5dadcd1d025d2775 gcc version:i686-linux-gcc (GCC) 5.1.0 sparse version: v0.5.0 smatch version: host hardware: x86_64 host os:4.2.0-164 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.1-i686: OK linux-4.2-i686: OK linux-4.3-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.1-x86_64: OK linux-4.2-x86_64: OK linux-4.3-x86_64: ERRORS apps: OK spec-git: OK sparse: ERRORS smatch: OK 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
[no subject]
Hi, I sent a patch named "[PATCH] tv tuner max2165 driver: extend frequency range" two weeks ago (22/10). Is it being reviewed? Thank you. Walter Cheuk -- 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: Slow path and cpu lock warnings - MC Next Gen
On 11/11/2015 05:25 PM, Shuah Khan wrote: > On 11/11/2015 08:49 AM, Shuah Khan wrote: >> On 11/11/2015 08:36 AM, Mauro Carvalho Chehab wrote: >>> Em Wed, 11 Nov 2015 07:22:47 -0700 >>> Shuah Khan escreveu: >>> On 11/11/2015 05:30 AM, Mauro Carvalho Chehab wrote: > Em Mon, 09 Nov 2015 08:55:06 -0700 > Shuah Khan escreveu: > >> On 11/09/2015 08:51 AM, Shuah Khan wrote: >>> As I mentioned on the IRC, here is the log for the problems I am seeing. >>> I have to do eject HVR 950Q TV stick to see the problem. >>> >>> mc_next_gen.v8.4 branch with no changes. >>> >>> I can test and debug this week. >>> >>> thanks, >>> -- Shuah >>> >> >> Forgot to cc linux-media, just in case others are interested >> and have ideas on debugging. >> > > snip > > > Sorry, but I fail to see how this is related to the V4L2 subsystem. > > At least on my eyes, it seems that the bug is somewhere at the Radeon > driver. > Mauro, I think you didn't look down the dmesg far enough. The following is the problem I am talking about and you will see media_device_unregister() on the stack. This occurs as soon as the device is removed. >>> >>> Shuah, >>> >>> I saw that, but it is clear, from the above log, that the Radeon >>> driver is broken and it has some bad lock dependencies with the >>> driver_attach locks. Any other bad lock report related to the >>> Radeon driver or driver binding/unbiding code are very likely >>> related to the above bug. >>> >>> You should either fix the bad lock at the Radeon driver or not >>> load it at all, in order to be able to get any reliable results >>> about possible locking troubles with the MC drivers with the Kernel >>> lock tests. >>> >> >> Yeah Radeon driver bug could be making things worse. Did you see >> any problems with device removal during your testing? >> >> ok found the following commit that fixes the problem: >> 7231ed1a813e0a9d249bbbe58e66ca058aee83e1 >> >> This went into 4.2-rc4 or rc5. I will test applying just this >> one patch to mc_next_gen.v8.4 branch and see if device removal >> problem also goes away. >> > > Applied the acpi backlight fix and now kernel hangs solid when > device is removed. I managed to get stack trace enabling sysrq > and that showed media_device_unregister_entity() attempt to hold > spin_lock() -> raw_spin_lock() on the stack trace. It is same as > the one seen in the dmesg I sent. > > I think we have several calls to media_device_unregister_entity() > from various media core drivers (dvb, v4l2, bridge driver) during > device removal from their unregister paths. This adds lot of > contention on the mdev->lock. > > media_device_unregister() calls media_device_unregister_entity() > as well on all the mdev entities. > > I am not testing with my ALSA patches at the moment. When that > gets added, media_devnode_is_registered() check to ensure only > one of them (bridge driver or snd-usb-audio) runs > media_device_unregister() won't work as the MEDIA_FLAG_REGISTERED > flag gets cleared towards the end of media_device_unregister(). > media_device_unregister() needs to be safe to be run by these two > drivers and still do the work only once. media_device_unregister() > does a lot (removes interface links, interfaces, and then then > unregister entities before it removes the media device devnode > file and call media_devnode_unregister() to clear the > MEDIA_FLAG_REGISTERED bit. > > I see two problems to solve: > > - ensure media_device_unregister() is safe to be called by one > or more drivers during device removal (usb disconnect in this > case) > - Reduce contention on mdev->lock during device removal > > I have some ideas on how to do this. I can work on them and send > patches. Sounds like a plan? > Found a two line fix to the problem. Will send patch tomorrow. I was able to do device inserts and removals in a row with the change. It hangs every time device removed without the change. thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- 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: Slow path and cpu lock warnings - MC Next Gen
On 11/11/2015 08:49 AM, Shuah Khan wrote: > On 11/11/2015 08:36 AM, Mauro Carvalho Chehab wrote: >> Em Wed, 11 Nov 2015 07:22:47 -0700 >> Shuah Khan escreveu: >> >>> On 11/11/2015 05:30 AM, Mauro Carvalho Chehab wrote: Em Mon, 09 Nov 2015 08:55:06 -0700 Shuah Khan escreveu: > On 11/09/2015 08:51 AM, Shuah Khan wrote: >> As I mentioned on the IRC, here is the log for the problems I am seeing. >> I have to do eject HVR 950Q TV stick to see the problem. >> >> mc_next_gen.v8.4 branch with no changes. >> >> I can test and debug this week. >> >> thanks, >> -- Shuah >> > > Forgot to cc linux-media, just in case others are interested > and have ideas on debugging. > snip Sorry, but I fail to see how this is related to the V4L2 subsystem. At least on my eyes, it seems that the bug is somewhere at the Radeon driver. >>> >>> Mauro, >>> >>> I think you didn't look down the dmesg far enough. The following is the >>> problem I am talking about and you will see media_device_unregister() >>> on the stack. This occurs as soon as the device is removed. >> >> Shuah, >> >> I saw that, but it is clear, from the above log, that the Radeon >> driver is broken and it has some bad lock dependencies with the >> driver_attach locks. Any other bad lock report related to the >> Radeon driver or driver binding/unbiding code are very likely >> related to the above bug. >> >> You should either fix the bad lock at the Radeon driver or not >> load it at all, in order to be able to get any reliable results >> about possible locking troubles with the MC drivers with the Kernel >> lock tests. >> > > Yeah Radeon driver bug could be making things worse. Did you see > any problems with device removal during your testing? > > ok found the following commit that fixes the problem: > 7231ed1a813e0a9d249bbbe58e66ca058aee83e1 > > This went into 4.2-rc4 or rc5. I will test applying just this > one patch to mc_next_gen.v8.4 branch and see if device removal > problem also goes away. > Applied the acpi backlight fix and now kernel hangs solid when device is removed. I managed to get stack trace enabling sysrq and that showed media_device_unregister_entity() attempt to hold spin_lock() -> raw_spin_lock() on the stack trace. It is same as the one seen in the dmesg I sent. I think we have several calls to media_device_unregister_entity() from various media core drivers (dvb, v4l2, bridge driver) during device removal from their unregister paths. This adds lot of contention on the mdev->lock. media_device_unregister() calls media_device_unregister_entity() as well on all the mdev entities. I am not testing with my ALSA patches at the moment. When that gets added, media_devnode_is_registered() check to ensure only one of them (bridge driver or snd-usb-audio) runs media_device_unregister() won't work as the MEDIA_FLAG_REGISTERED flag gets cleared towards the end of media_device_unregister(). media_device_unregister() needs to be safe to be run by these two drivers and still do the work only once. media_device_unregister() does a lot (removes interface links, interfaces, and then then unregister entities before it removes the media device devnode file and call media_devnode_unregister() to clear the MEDIA_FLAG_REGISTERED bit. I see two problems to solve: - ensure media_device_unregister() is safe to be called by one or more drivers during device removal (usb disconnect in this case) - Reduce contention on mdev->lock during device removal I have some ideas on how to do this. I can work on them and send patches. Sounds like a plan? thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- 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] media: adv7180: increase delay after reset to 5ms
Hi Ulrich, (CC'ing Lars-Peter Clausen) Thank you for the patch. On Tuesday 10 November 2015 14:39:00 Ulrich Hecht wrote: > Initialization of the ADV7180 chip fails on the Renesas R8A7790-based > Lager board about 50% of the time. This patch resolves the issue by > increasing the minimum delay after reset from 2 ms to 5 ms, following the > recommendation in the ADV7180 datasheet: > > "Executing a software reset takes approximately 2 ms. However, it is > recommended to wait 5 ms before any further I2C writes are performed." > > Signed-off-by: Ulrich Hecht Acked-by: Laurent Pinchart Lars, would you like to take this in your tree with other Analog Devices patches, or should I take it ? > --- > drivers/media/i2c/adv7180.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c > index f82c8aa..3c3c4bf 100644 > --- a/drivers/media/i2c/adv7180.c > +++ b/drivers/media/i2c/adv7180.c > @@ -1112,7 +1112,7 @@ static int init_device(struct adv7180_state *state) > mutex_lock(&state->mutex); > > adv7180_write(state, ADV7180_REG_PWR_MAN, ADV7180_PWR_MAN_RES); > - usleep_range(2000, 1); > + usleep_range(5000, 1); > > ret = state->chip_info->init(state); > if (ret) -- Regards, Laurent Pinchart -- 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/1] smiapp: Move include/media/smiapp.h under include/media/i2c
Signed-off-by: Sakari Ailus
---
Hi Mauro,
Your script appears to miss smiapp as it's in a separate directory. Could
you either change the script, or apply this patch, please?
Kind regards,
Sakari
MAINTAINERS | 2 +-
drivers/media/i2c/smiapp/smiapp.h | 2 +-
include/media/{ => i2c}/smiapp.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
rename include/media/{ => i2c}/smiapp.h (98%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 42e81f9..bbeea09 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9614,7 +9614,7 @@ M:Sakari Ailus
L: linux-media@vger.kernel.org
S: Maintained
F: drivers/media/i2c/smiapp/
-F: include/media/smiapp.h
+F: include/media/i2c/smiapp.h
F: drivers/media/i2c/smiapp-pll.c
F: drivers/media/i2c/smiapp-pll.h
F: include/uapi/linux/smiapp.h
diff --git a/drivers/media/i2c/smiapp/smiapp.h
b/drivers/media/i2c/smiapp/smiapp.h
index ed010a8..66e34b1 100644
--- a/drivers/media/i2c/smiapp/smiapp.h
+++ b/drivers/media/i2c/smiapp/smiapp.h
@@ -20,9 +20,9 @@
#define __SMIAPP_PRIV_H_
#include
+#include
#include
#include
-#include
#include "smiapp-pll.h"
#include "smiapp-reg.h"
diff --git a/include/media/smiapp.h b/include/media/i2c/smiapp.h
similarity index 98%
rename from include/media/smiapp.h
rename to include/media/i2c/smiapp.h
index 268a3cd..029142d 100644
--- a/include/media/smiapp.h
+++ b/include/media/i2c/smiapp.h
@@ -1,5 +1,5 @@
/*
- * include/media/smiapp.h
+ * include/media/i2c/smiapp.h
*
* Generic driver for SMIA/SMIA++ compliant camera modules
*
--
2.1.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 1/1] omap3isp: preview: Mark output buffer done first
Hi Sakari,
Thank you for the patch.
On Wednesday 11 November 2015 01:34:18 Sakari Ailus wrote:
> The sequence number counter is incremented on each output buffer, and that
> incremented value is used as the sequence number of that buffer. The input
> buffer sequence numbering is based just on reading the same counter. If
> the input buffer is marked done first, its sequence number ends up being
> that of the output buffer - 1.
>
> This is how the resizer works as well.
>
> Signed-off-by: Sakari Ailus
I'm always wary when touching interrupt handling in the omap3isp driver, but
this change really looks correct and harmless.
Reviewed-by: Laurent Pinchart
and applied to my tree.
> ---
> drivers/media/platform/omap3isp/isppreview.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/isppreview.c
> b/drivers/media/platform/omap3isp/isppreview.c index cfb2debb..1478076
> 100644
> --- a/drivers/media/platform/omap3isp/isppreview.c
> +++ b/drivers/media/platform/omap3isp/isppreview.c
> @@ -1480,13 +1480,6 @@ static void preview_isr_buffer(struct isp_prev_device
> *prev) struct isp_buffer *buffer;
> int restart = 0;
>
> - if (prev->input == PREVIEW_INPUT_MEMORY) {
> - buffer = omap3isp_video_buffer_next(&prev->video_in);
> - if (buffer != NULL)
> - preview_set_inaddr(prev, buffer->dma);
> - pipe->state |= ISP_PIPELINE_IDLE_INPUT;
> - }
> -
> if (prev->output & PREVIEW_OUTPUT_MEMORY) {
> buffer = omap3isp_video_buffer_next(&prev->video_out);
> if (buffer != NULL) {
> @@ -1496,6 +1489,13 @@ static void preview_isr_buffer(struct isp_prev_device
> *prev) pipe->state |= ISP_PIPELINE_IDLE_OUTPUT;
> }
>
> + if (prev->input == PREVIEW_INPUT_MEMORY) {
> + buffer = omap3isp_video_buffer_next(&prev->video_in);
> + if (buffer != NULL)
> + preview_set_inaddr(prev, buffer->dma);
> + pipe->state |= ISP_PIPELINE_IDLE_INPUT;
> + }
> +
> switch (prev->state) {
> case ISP_PIPELINE_STREAM_SINGLESHOT:
> if (isp_pipeline_ready(pipe))
--
Regards,
Laurent Pinchart
--
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 4/4] v4l2-mem2mem: allow reqbufs(0) with "in use" MMAP buffers
Hi, 2015-11-02 19:31 GMT+01:00 Nicolas Dufresne : > Le mardi 08 avril 2014 à 12:51 +0200, Marek Szyprowski a écrit : >> Hello, >> >> On 2014-04-07 16:41, Kamil Debski wrote: >> > Pawel, Marek, >> > >> > Before taking this to my tree I wanted to get an ACK from one of >> > the >> > videobuf2 maintainers. Could you spare a moment to look through >> > this >> > patch? >> >> It's not a bug, it is a feature. This was one of the fundamental >> design >> requirements to allow applications to track if the memory is used or >> not. > > I still have the impression it is not fully correct for the case > buffers are exported using DMABUF. Like if the dmabuf was owning the > vb2 buffer instead of the opposite ... I am observing this behaviour too... Tried it, but seems to not do the job on dmabuf buffers... with gstreamer at least ;-). JM -- 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 2/2] [media] include/media: move platform driver headers to a separate dir
On Wednesday 11 November 2015 15:14:48 Mauro Carvalho Chehab wrote:
> rename include/media/{ => platform}/exynos-fimc.h (100%)
> rename include/media/{ => platform}/mmp-camera.h (100%)
> rename include/media/{ => platform}/omap1_camera.h (100%)
> rename include/media/{ => platform}/omap4iss.h (100%)
> rename include/media/{ => platform}/s3c_camif.h (100%)
> rename include/media/{ => platform}/s5p_hdmi.h (100%)
> rename include/media/{ => platform}/sh_mobile_ceu.h (100%)
> rename include/media/{ => platform}/sh_mobile_csi2.h (100%)
> rename include/media/{ => platform}/sh_vou.h (100%)
> rename include/media/{ => platform}/sii9234.h (100%)
> rename include/media/{ => platform}/soc_camera.h (100%)
> rename include/media/{ => platform}/soc_camera_platform.h (98%)
> rename include/media/{ => platform}/soc_mediabus.h (100%)
This still seems to be a mix of various things. Some of these are interfaces
between drivers, while others declare a foo_platform_data structure that
is used to interface between platform code and the driver.
I think the latter should go into include/linux/platform_data/media/*.h instead.
Arnd
--
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/3] [media] v4l: tegra: Add NVIDIA Tegra VI driver
NVIDIA Tegra processor contains a powerful Video Input (VI) hardware controller which can support up to 6 MIPI CSI camera sensors. This patch adds a V4L2 media controller and capture driver to support Tegra VI hardware. It's verified with Tegra built-in test pattern generator. Signed-off-by: Bryan Wu Reviewed-by: Hans Verkuil --- drivers/media/platform/Kconfig | 1 + drivers/media/platform/Makefile | 2 + drivers/media/platform/tegra/Kconfig | 10 + drivers/media/platform/tegra/Makefile| 3 + drivers/media/platform/tegra/tegra-channel.c | 849 +++ drivers/media/platform/tegra/tegra-core.c| 254 drivers/media/platform/tegra/tegra-core.h| 162 + drivers/media/platform/tegra/tegra-csi.c | 560 ++ drivers/media/platform/tegra/tegra-vi.c | 732 +++ drivers/media/platform/tegra/tegra-vi.h | 213 +++ 10 files changed, 2786 insertions(+) create mode 100644 drivers/media/platform/tegra/Kconfig create mode 100644 drivers/media/platform/tegra/Makefile create mode 100644 drivers/media/platform/tegra/tegra-channel.c create mode 100644 drivers/media/platform/tegra/tegra-core.c create mode 100644 drivers/media/platform/tegra/tegra-core.h create mode 100644 drivers/media/platform/tegra/tegra-csi.c create mode 100644 drivers/media/platform/tegra/tegra-vi.c create mode 100644 drivers/media/platform/tegra/tegra-vi.h diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index ccbc974..036210a 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -119,6 +119,7 @@ source "drivers/media/platform/exynos4-is/Kconfig" source "drivers/media/platform/s5p-tv/Kconfig" source "drivers/media/platform/am437x/Kconfig" source "drivers/media/platform/xilinx/Kconfig" +source "drivers/media/platform/tegra/Kconfig" endif # V4L_PLATFORM_DRIVERS diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index efa0295..3c79fd3 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -54,4 +54,6 @@ obj-$(CONFIG_VIDEO_AM437X_VPFE) += am437x/ obj-$(CONFIG_VIDEO_XILINX) += xilinx/ +obj-$(CONFIG_VIDEO_TEGRA) += tegra/ + ccflags-y += -I$(srctree)/drivers/media/i2c diff --git a/drivers/media/platform/tegra/Kconfig b/drivers/media/platform/tegra/Kconfig new file mode 100644 index 000..54c0e7a --- /dev/null +++ b/drivers/media/platform/tegra/Kconfig @@ -0,0 +1,10 @@ +config VIDEO_TEGRA + tristate "NVIDIA Tegra Video Input Driver" + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF + depends on TEGRA_HOST1X + select VIDEOBUF2_DMA_CONTIG + ---help--- + Driver for Video Input (VI) controller found on NVIDIA Tegra SoC. + + To compile this driver as a module, choose M here: the module will be + called tegra-video. diff --git a/drivers/media/platform/tegra/Makefile b/drivers/media/platform/tegra/Makefile new file mode 100644 index 000..18a1c16 --- /dev/null +++ b/drivers/media/platform/tegra/Makefile @@ -0,0 +1,3 @@ +tegra-video-objs += tegra-core.o tegra-csi.o tegra-vi.o tegra-channel.o + +obj-$(CONFIG_VIDEO_TEGRA) += tegra-video.o diff --git a/drivers/media/platform/tegra/tegra-channel.c b/drivers/media/platform/tegra/tegra-channel.c new file mode 100644 index 000..63eb942 --- /dev/null +++ b/drivers/media/platform/tegra/tegra-channel.c @@ -0,0 +1,849 @@ +/* + * NVIDIA Tegra Video Input Device + * + * Copyright (c) 2015, NVIDIA CORPORATION. All rights reserved. + * + * Author: Bryan Wu + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#include + +#include "tegra-vi.h" + +#define TEGRA_VI_SYNCPT_WAIT_TIMEOUT 200 + +/* VI registers */ +#define TEGRA_VI_CFG_VI_INCR_SYNCPT0x000 +#define VI_CFG_VI_INCR_SYNCPT_COND(x)(((x) & 0xff) << 8) +#define VI_CSI_PP_LINE_START(port) (4 + (port) * 4) +#define VI_CSI_PP_FRAME_START(port) (5 + (port) * 4) +#define VI_CSI_MW_REQ_DONE(port) (6 + (port) * 4) +#define VI_CSI_MW_ACK_DONE(port) (7 + (port) * 4) + +#define TEGRA_VI_CFG_VI_INCR_SYNCPT_CNTRL 0x004 +#define TEGRA_VI_CFG_VI_INCR_SYNCPT_ERROR 0x008 +#define TEGRA_VI_CFG_CTXSW 0x020 +#define TEGRA_VI_CFG_INTSTATUS 0x024 +#define TEGRA_VI_CFG_PWM_CONTROL 0x038 +#define TEGRA_VI_CFG_PWM_HIGH_PULSE
[PATCH 0/3 RFC v5] media: platform: add NVIDIA Tegra VI driver
This patchset add and enable V4L2 driver for latest NVIDIA Tegra Video Input hardware controller. It's based on the staging/work branch of Thierry Reding Tegra upstream kernel github repo, which is based on 4.3.0-next-20151106. (https://github.com/thierryreding/linux/tree/staging/work) v5: - Introduce 2 kthreads for capture Use one kthread to start capture a frame and wait for next frame start. Before waiting, it will move the current buffer to another queue which will be handled by the second kthread. The second kthread (capture_done) will wait for memory output done sync point event and hand over the buffer to videobuffer2 framework as capture done. - Fix building issue after upstream V4L2 API changed - Fix one potential race condition Increase syncpoint max value before arming syncshot capture - Remove freezer in kthread since it's problematic according latest discussion in 2015 Kernel Summit - Verify with a real sensor module (OV5693) v4: - fix all the coding style issues - solve all the minor problems pointed out by Hans Verkuil v3: - rework on the locking code related to kthread - remove some dead code - other fixes v2: - allocate kthread for each channel instead of workqueue - create tegra-csi as a separated V4L2 subdevice - define all the register bits needed in this driver - add device tree binding document - update things according to Hans and Thierry's review. Bryan Wu (3): [media] v4l: tegra: Add NVIDIA Tegra VI driver ARM64: add tegra-vi support in T210 device-tree Documentation: DT bindings: add VI and CSI bindings .../display/tegra/nvidia,tegra20-host1x.txt| 211 - arch/arm64/boot/dts/nvidia/tegra210-p2571.dts | 8 + arch/arm64/boot/dts/nvidia/tegra210.dtsi | 174 - drivers/media/platform/Kconfig | 1 + drivers/media/platform/Makefile| 2 + drivers/media/platform/tegra/Kconfig | 10 + drivers/media/platform/tegra/Makefile | 3 + drivers/media/platform/tegra/tegra-channel.c | 849 + drivers/media/platform/tegra/tegra-core.c | 254 ++ drivers/media/platform/tegra/tegra-core.h | 162 drivers/media/platform/tegra/tegra-csi.c | 560 ++ drivers/media/platform/tegra/tegra-vi.c| 732 ++ drivers/media/platform/tegra/tegra-vi.h| 213 ++ 13 files changed, 3172 insertions(+), 7 deletions(-) create mode 100644 drivers/media/platform/tegra/Kconfig create mode 100644 drivers/media/platform/tegra/Makefile create mode 100644 drivers/media/platform/tegra/tegra-channel.c create mode 100644 drivers/media/platform/tegra/tegra-core.c create mode 100644 drivers/media/platform/tegra/tegra-core.h create mode 100644 drivers/media/platform/tegra/tegra-csi.c create mode 100644 drivers/media/platform/tegra/tegra-vi.c create mode 100644 drivers/media/platform/tegra/tegra-vi.h -- 2.1.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 3/3] Documentation: DT bindings: add VI and CSI bindings
Signed-off-by: Bryan Wu
---
.../display/tegra/nvidia,tegra20-host1x.txt| 211 -
1 file changed, 205 insertions(+), 6 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
index f3b545a..dbd3f57 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
@@ -40,10 +40,39 @@ of the following host1x client modules:
- interrupts: The interrupt outputs from the controller.
- clocks: Must contain one entry, for the module clock.
See ../clocks/clock-bindings.txt for details.
+ - clock-names: Must include the following entries:
+- vi
+ This MUST be the first entry.
+- csi
+- parent
- resets: Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: Must include the following entries:
- vi
+ - power-domains: The power domains settings.
+See ../power/power_domain.txt
+ - iommus: The IOMMU settings.
+See ../iommu/iommu.txt
+ - ports: several VI input ports which connecting CSI ports. Ports contain
+several port and each port has one endpoint.
+See ../graph.txt and ../media/video-interfaces.txt
+ - avdd-dsi-csi-supply: a regulator required by VI.
+
+- csi: camera serial interface
+
+ Required properties:
+ - compatible: "nvidia,tegra-csi"
+ - reg: Physical base address and length of the controller's registers.
+ - interrupts: The interrupt outputs from the controller.
+ - clocks: Must contain one entry, for the module clock.
+See ../clocks/clock-bindings.txt for details.
+ - clock-names: Must include the following entries:
+- cil
+ This MUST be the first entry.
+ - ports: 2 ports presenting 2 channels of CSI. Each port has 2 endpoints:
+one connects to sensor device tree node as input and the other one connects
+to VI endpoint.
+See ../graph.txt and ../media/video-interfaces.txt
- epp: encoder pre-processor
@@ -280,13 +309,183 @@ Example:
reset-names = "mpe";
};
- vi {
- compatible = "nvidia,tegra20-vi";
- reg = <0x5408 0x0004>;
- interrupts = <0 69 0x04>;
- clocks = <&tegra_car TEGRA20_CLK_VI>;
- resets = <&tegra_car 100>;
+ vi@0,5408 {
+ compatible = "nvidia,tegra210-vi";
+ reg = <0x0 0x5408 0x0 0x800>;
+ interrupts = ;
+ status = "disabled";
+ clocks = <&tegra_car TEGRA210_CLK_VI>,
+<&tegra_car TEGRA210_CLK_CSI>,
+<&tegra_car TEGRA210_CLK_PLL_C>;
+ clock-names = "vi", "csi", "parent";
+ resets = <&tegra_car 20>;
reset-names = "vi";
+
+ power-domains = <&pmc TEGRA_POWERGATE_VENC>;
+
+ iommus = <&mc TEGRA_SWGROUP_VI>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ vi_in0: endpoint {
+ remote-endpoint = <&csi_out0>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+
+ vi_in1: endpoint {
+ remote-endpoint = <&csi_out1>;
+ };
+ };
+ port@2 {
+ reg = <2>;
+
+ vi_in2: endpoint {
+ remote-endpoint = <&csi_out2>;
+ };
+ };
+ port@3 {
+ reg = <3>;
+
+ vi_in3: endpoint {
+ remote-endpoint = <&csi_out3>;
+ };
+ };
+ port@4 {
+ reg = <4>;
+
+ vi_in4: endpoint {
+ remote-endpoint = <&csi_out4>;
+ };
+ };
+ port@5 {
+
[PATCH 2/3] ARM64: add tegra-vi support in T210 device-tree
Following device tree support for Tegra VI now:
- "vi" node which might have 6 ports/endpoints
- in TPG mode, "vi" node don't need to define any ports/endpoints
- ports/endpoints defines the link between VI and external sensors.
Signed-off-by: Bryan Wu
---
arch/arm64/boot/dts/nvidia/tegra210-p2571.dts | 8 ++
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 174 +-
2 files changed, 181 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p2571.dts
b/arch/arm64/boot/dts/nvidia/tegra210-p2571.dts
index 50a3582..c573546 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210-p2571.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra210-p2571.dts
@@ -7,6 +7,14 @@
model = "NVIDIA Tegra210 P2571 reference board";
compatible = "nvidia,p2571", "nvidia,tegra210";
+ host1x@0,5000 {
+ vi@0,5408 {
+ status = "okay";
+
+ avdd-dsi-csi-supply = <&vdd_dsi_csi>;
+ };
+ };
+
pinmux: pinmux@0,78d4 {
pinctrl-names = "boot";
pinctrl-0 = <&state_boot>;
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index 8048fc5..57ffc28 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -123,9 +123,181 @@
vi@0,5408 {
compatible = "nvidia,tegra210-vi";
- reg = <0x0 0x5408 0x0 0x0004>;
+ reg = <0x0 0x5408 0x0 0x800>;
interrupts = ;
status = "disabled";
+ clocks = <&tegra_car TEGRA210_CLK_VI>,
+<&tegra_car TEGRA210_CLK_CSI>,
+<&tegra_car TEGRA210_CLK_PLL_C>;
+ clock-names = "vi", "csi", "parent";
+ resets = <&tegra_car 20>;
+ reset-names = "vi";
+
+ power-domains = <&pmc TEGRA_POWERGATE_VENC>;
+
+ iommus = <&mc TEGRA_SWGROUP_VI>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ vi_in0: endpoint {
+ remote-endpoint = <&csi_out0>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+
+ vi_in1: endpoint {
+ remote-endpoint = <&csi_out1>;
+ };
+ };
+ port@2 {
+ reg = <2>;
+
+ vi_in2: endpoint {
+ remote-endpoint = <&csi_out2>;
+ };
+ };
+ port@3 {
+ reg = <3>;
+
+ vi_in3: endpoint {
+ remote-endpoint = <&csi_out3>;
+ };
+ };
+ port@4 {
+ reg = <4>;
+
+ vi_in4: endpoint {
+ remote-endpoint = <&csi_out4>;
+ };
+ };
+ port@5 {
+ reg = <5>;
+
+ vi_in5: endpoint {
+ remote-endpoint = <&csi_out5>;
+ };
+ };
+
+ };
+ };
+
+ csi@0,54080838 {
+ compatible = "nvidia,tegra210-csi";
+ reg = <0x0 0x54080838 0x0 0x700>;
+ clocks = <&tegra_car TEGRA210_CLK_CILAB>;
+ clock-names = "cil";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ csi_in0: endpoint@0 {
+ reg = <0x0>;
+ };
+
[PATCH 2/2] [media] include/media: move platform driver headers to a separate dir
Let's not mix headers used by the core with those headers that
are needed by some specific platform drivers.
This patch was made via this script:
mkdir include/media/platform
for i in include/media/*.h; do n=`basename $i`; (for j in $(git grep
-l $n); do dirname $j; done)|sort|uniq|grep -ve '^.$' > list; num=$(wc -l
list|cut -d' ' -f1); if [ $num == 1 ]; then if [ "`grep platform list`" != ""
]; then git mv $i include/media/platform; fi; fi; done
git mv include/media/exynos* include/media/s5p* include/media/omap*
include/media/soc_* include/media/sh_include/media/platform/
for i in $(find include/media/ -type f); do n=`basename $i`; git grep
-l $n; done|sort|uniq >files && (echo "for i in \$(cat files); do cat \$i |
\\"; cd include/media; for j in rc/ i2c/ platform/ common_drv/; do for i in
$(ls $j); do echo "perl -ne 's,(include
[\\\"\\<]media/)($i)([\\\"\\>]),\1$j\2\3,; print \$_' |\\"; done; done; echo
"cat > a && mv a \$i; done") >script && . ./script
Signed-off-by: Mauro Carvalho Chehab
rename include/media/{ => platform}/exynos-fimc.h (100%)
rename include/media/{ => platform}/mmp-camera.h (100%)
rename include/media/{ => platform}/omap1_camera.h (100%)
rename include/media/{ => platform}/omap4iss.h (100%)
rename include/media/{ => platform}/s3c_camif.h (100%)
rename include/media/{ => platform}/s5p_hdmi.h (100%)
rename include/media/{ => platform}/sh_mobile_ceu.h (100%)
rename include/media/{ => platform}/sh_mobile_csi2.h (100%)
rename include/media/{ => platform}/sh_vou.h (100%)
rename include/media/{ => platform}/sii9234.h (100%)
rename include/media/{ => platform}/soc_camera.h (100%)
rename include/media/{ => platform}/soc_camera_platform.h (98%)
rename include/media/{ => platform}/soc_mediabus.h (100%)
diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
index ede2bdbb5dd5..99bd64c69a4f 100644
--- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
+++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
@@ -33,7 +33,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/arch/arm/mach-imx/mach-mx27_3ds.c
b/arch/arm/mach-imx/mach-mx27_3ds.c
index 9ef4640f3660..74d073fd4fa6 100644
--- a/arch/arm/mach-imx/mach-mx27_3ds.c
+++ b/arch/arm/mach-imx/mach-mx27_3ds.c
@@ -31,7 +31,7 @@
#include
#include
-#include
+#include
#include
#include
diff --git a/arch/arm/mach-imx/mach-mx31_3ds.c
b/arch/arm/mach-imx/mach-mx31_3ds.c
index 65a0dc06a97c..5e1b9c335103 100644
--- a/arch/arm/mach-imx/mach-mx31_3ds.c
+++ b/arch/arm/mach-imx/mach-mx31_3ds.c
@@ -28,7 +28,7 @@
#include
#include
-#include
+#include
#include
#include
diff --git a/arch/arm/mach-imx/mach-mx35_3ds.c
b/arch/arm/mach-imx/mach-mx35_3ds.c
index 7e315f00648d..355b9521f7f0 100644
--- a/arch/arm/mach-imx/mach-mx35_3ds.c
+++ b/arch/arm/mach-imx/mach-mx35_3ds.c
@@ -45,7 +45,7 @@
#include
-#include
+#include
#include "3ds_debugboard.h"
#include "common.h"
diff --git a/arch/arm/mach-imx/mach-pcm037.c b/arch/arm/mach-imx/mach-pcm037.c
index 6d879417db49..02cc07b0a687 100644
--- a/arch/arm/mach-imx/mach-pcm037.c
+++ b/arch/arm/mach-imx/mach-pcm037.c
@@ -35,7 +35,7 @@
#include
#include
-#include
+#include
#include
#include
diff --git a/arch/arm/mach-imx/mx31moboard-marxbot.c
b/arch/arm/mach-imx/mx31moboard-marxbot.c
index 2e895a82a6eb..79ae360a9c8f 100644
--- a/arch/arm/mach-imx/mx31moboard-marxbot.c
+++ b/arch/arm/mach-imx/mx31moboard-marxbot.c
@@ -24,7 +24,7 @@
#include
-#include
+#include
#include "common.h"
#include "devices-imx31.h"
diff --git a/arch/arm/mach-imx/mx31moboard-smartbot.c
b/arch/arm/mach-imx/mx31moboard-smartbot.c
index 89fc35a64448..00bd100df69a 100644
--- a/arch/arm/mach-imx/mx31moboard-smartbot.c
+++ b/arch/arm/mach-imx/mx31moboard-smartbot.c
@@ -23,7 +23,7 @@
#include
#include
-#include
+#include
#include "board-mx31moboard.h"
#include "common.h"
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index a95499ea8706..7adef38f27c2 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -28,7 +28,7 @@
#include
#include
-#include
+#include
#include
#include
diff --git a/arch/arm/mach-omap1/include/mach/camera.h
b/arch/arm/mach-omap1/include/mach/camera.h
index 847d00f0bb0a..0df5ebf85de6 100644
--- a/arch/arm/mach-omap1/include/mach/camera.h
+++ b/arch/arm/mach-omap1/include/mach/camera.h
@@ -1,7 +1,7 @@
#ifndef __ASM_ARCH_CAMERA_H_
#define __ASM_ARCH_CAMERA_H_
-#include
+#include
void omap1_camera_init(void *);
diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-x270.c
index 9d7072b04045..ae645794ffd0 100644
--- a/arch/arm/mach-pxa/em-x270.c
+++ b/arch/arm/mach-pxa/em-x270.c
@@ -34,7 +34,7 @@
#include
#include
-#include
+#include
#include
#include
diff --git a/arch/arm/mach-pxa/ezx
Re: PVR-250 Composite 3 unavailable [Re: ivtv driver]
Em Fri, 06 Nov 2015 10:36:08 -0700 Warren Sturm escreveu: > On Mon, 2015-10-26 at 19:49 -0400, Andy Walls wrote: > > On October 26, 2015 7:13:52 PM EDT, Warren Sturm < > > warren.st...@gmail.com> wrote: > > > Hi Andy. > > > > > > I don't know whether this was intended but the pvr250 lost the > > > composite 3 input when going from kernel version 4.1.10 to 4.2.3. > > > > > > This is on a Fedora 22 x86_64 system. > > > > > > > > > Thanks for any insight. > > > > Unintentional. > > > > I'm guessing this commit was the problem: > > > > http://git.linuxtv.org/cgit.cgi/media_tree.git/commit/drivers/media/pci/ivtv/ivtv-driver.c?id=09290cc885937cab3b2d60a6d48fe3d2d3e04061 My fault. I'll revert that patch. > > > > Could you confirm? > > > > R, > > Andy > > Ok. I rebuilt the SRPM for kernel-4.2.5-201 with the patch reverted > and installed it. > > uname -a > Linux wrs 4.2.5-201.fc22.x86_64 #1 SMP Fri Nov 6 00:13:17 MST 2015 x86_64 > x86_64 x86_64 GNU/Linux > > Attached are the v4l2-ctl --list-inputs for the respective kernels. > > Hope this is sufficient confirmation. > > > -- 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: [RFC] Documentation: dontdiff: remove media from dontdiff
On Fri, 30 Oct 2015 01:15:39 +0800 Wang YanQing wrote: > media will hide all the changes in drivers/media. > > Signed-off-by: Wang YanQing > --- > I don't know whether it is still acceptable to patch dontdiff, > so I add Linus to CC list. As long as the file is there, its contents should make sense, so I've applied this to the docs tree, thanks. That said, the fact that it excludes a big driver subsystem and nobody has said anything suggests it hasn't been used in some time, so we should consider just deleting it. jon -- 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: Slow path and cpu lock warnings - MC Next Gen
On 11/11/2015 08:36 AM, Mauro Carvalho Chehab wrote:
> Em Wed, 11 Nov 2015 07:22:47 -0700
> Shuah Khan escreveu:
>
>> On 11/11/2015 05:30 AM, Mauro Carvalho Chehab wrote:
>>> Em Mon, 09 Nov 2015 08:55:06 -0700
>>> Shuah Khan escreveu:
>>>
On 11/09/2015 08:51 AM, Shuah Khan wrote:
> As I mentioned on the IRC, here is the log for the problems I am seeing.
> I have to do eject HVR 950Q TV stick to see the problem.
>
> mc_next_gen.v8.4 branch with no changes.
>
> I can test and debug this week.
>
> thanks,
> -- Shuah
>
Forgot to cc linux-media, just in case others are interested
and have ideas on debugging.
thanks,
-- Shuah
>>>
[8.558049] ==
[8.558056] [ INFO: possible circular locking dependency detected ]
[8.558063] 4.2.0-rc2+ #21 Not tainted
[8.558070] ---
[8.558077] systemd-udevd/143 is trying to acquire lock:
[8.558084] (init_mutex){+.+.+.}, at: []
acpi_video_get_backlight_type+0x17/0x163 [video]
[8.558104]
but task is already holding lock:
[8.558114] (&(&backlight_notifier)->rwsem){..}, at:
[] __blocking_notifier_call_chain+0x39/0x70
[8.558133]
which lock already depends on the new lock.
[8.558147]
the existing dependency chain (in reverse order) is:
[8.558158]
-> #1 (&(&backlight_notifier)->rwsem){..}:
[8.558170][] lock_acquire+0xb1/0x130
[8.558180][] down_write+0x36/0x70
[8.558189][]
blocking_notifier_chain_register+0x21/0xb0
[8.558202][]
backlight_register_notifier+0x18/0x20
[8.558212][]
acpi_video_get_backlight_type+0xfa/0x163 [video]
[8.558225][] acpi_video_bus_add+0x686/0xdfa
[video]
[8.558237][] acpi_device_probe+0x50/0xf7
[8.558247][] driver_probe_device+0x14d/0x470
[8.558257][] __driver_attach+0x94/0xa0
[8.558266][] bus_for_each_dev+0x66/0xa0
[8.558275][] driver_attach+0x1e/0x20
[8.558287][] bus_add_driver+0x1ee/0x280
[8.558296][] driver_register+0x60/0xe0
[8.558304][]
acpi_bus_register_driver+0x3b/0x43
[8.558313][] acpi_video_register+0x6e/0x90
[video]
[8.558322][] hid_generic_exit+0x87/0x1000
[hid_generic]
[8.558334][] do_one_initcall+0xab/0x1d0
[8.558344][] do_init_module+0x60/0x1e9
[8.558353][] load_module+0x2170/0x2780
[8.558363][] SyS_finit_module+0x9a/0xc0
[8.558372][]
entry_SYSCALL_64_fastpath+0x12/0x6f
[8.558381]
-> #0 (init_mutex){+.+.+.}:
[8.558392][] __lock_acquire+0x1f29/0x1f90
[8.558401][] lock_acquire+0xb1/0x130
[8.558409][] mutex_lock_nested+0x4b/0x340
[8.558417][]
acpi_video_get_backlight_type+0x17/0x163 [video]
[8.558430][]
acpi_video_backlight_notify+0x19/0x2f [video]
[8.558442][] notifier_call_chain+0x5d/0x80
[8.558451][]
__blocking_notifier_call_chain+0x51/0x70
[8.558462][]
blocking_notifier_call_chain+0x16/0x20
[8.558474][]
backlight_device_register+0x1a2/0x260
[8.558483][]
radeon_atom_backlight_init+0xda/0x1d0 [radeon]
[8.558543][]
radeon_link_encoder_connector+0xc3/0x130 [radeon]
[8.558585][]
radeon_get_atom_connector_info_from_object_table+0x3a6/0x950 [radeon]
[8.558625][] radeon_modeset_init+0x5dc/0xa40
[radeon]
[8.558667][]
radeon_driver_load_kms+0x12b/0x220 [radeon]
[8.558706][] drm_dev_register+0xb1/0x100
[drm]
[8.558728][] drm_get_pci_dev+0x8d/0x1e0 [drm]
[8.558747][] radeon_pci_probe+0xa4/0xc0
[radeon]
[8.558783][] local_pci_probe+0x45/0xa0
[8.558792][] pci_device_probe+0xd1/0x120
[8.558800][] driver_probe_device+0x14d/0x470
[8.558809][] __driver_attach+0x94/0xa0
[8.558818][] bus_for_each_dev+0x66/0xa0
[8.558827][] driver_attach+0x1e/0x20
[8.558835][] bus_add_driver+0x1ee/0x280
[8.558844][] driver_register+0x60/0xe0
[8.558852][] __pci_register_driver+0x64/0x70
[8.558860][] drm_pci_init+0xe0/0x110 [drm]
[8.558879][] radeon_init+0x9d/0xb2 [radeon]
[8.558911][] do_one_initcall+0xab/0x1d0
[
Re: [PATCH] [media] hackrf: don't emit dev debug on a kfree'd or null dev
On 11/11/2015 05:05 PM, Colin King wrote: From: Colin Ian King Static analysis with smatch detected a couple of issues: drivers/media/usb/hackrf/hackrf.c:1533 hackrf_probe() error: we previously assumed 'dev' could be null (see line 1366) drivers/media/usb/hackrf/hackrf.c:1533 hackrf_probe() error: dereferencing freed memory 'dev' A dev_dbg message is being output on a kfree'd dev. Worse, if dev is not allocated earlier, on, a null pointer deference on dev->dev can occur onthe deb_dbg call. Clean this up by only printing a debug message if dev is not null and has not been kfree'd. It is already fixed: https://patchwork.linuxtv.org/patch/31712/ Signed-off-by: Colin Ian King --- drivers/media/usb/hackrf/hackrf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/usb/hackrf/hackrf.c b/drivers/media/usb/hackrf/hackrf.c index e05bfec..faf3670 100644 --- a/drivers/media/usb/hackrf/hackrf.c +++ b/drivers/media/usb/hackrf/hackrf.c @@ -1528,9 +1528,9 @@ err_v4l2_ctrl_handler_free_tx: err_v4l2_ctrl_handler_free_rx: v4l2_ctrl_handler_free(&dev->rx_ctrl_handler); err_kfree: + dev_dbg(dev->dev, "failed=%d\n", ret); kfree(dev); err: - dev_dbg(dev->dev, "failed=%d\n", ret); return ret; } regards Antti -- http://palosaari.fi/ -- 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: Slow path and cpu lock warnings - MC Next Gen
Em Wed, 11 Nov 2015 07:22:47 -0700
Shuah Khan escreveu:
> On 11/11/2015 05:30 AM, Mauro Carvalho Chehab wrote:
> > Em Mon, 09 Nov 2015 08:55:06 -0700
> > Shuah Khan escreveu:
> >
> >> On 11/09/2015 08:51 AM, Shuah Khan wrote:
> >>> As I mentioned on the IRC, here is the log for the problems I am seeing.
> >>> I have to do eject HVR 950Q TV stick to see the problem.
> >>>
> >>> mc_next_gen.v8.4 branch with no changes.
> >>>
> >>> I can test and debug this week.
> >>>
> >>> thanks,
> >>> -- Shuah
> >>>
> >>
> >> Forgot to cc linux-media, just in case others are interested
> >> and have ideas on debugging.
> >>
> >> thanks,
> >> -- Shuah
> >
> >> [8.558049] ==
> >> [8.558056] [ INFO: possible circular locking dependency detected ]
> >> [8.558063] 4.2.0-rc2+ #21 Not tainted
> >> [8.558070] ---
> >> [8.558077] systemd-udevd/143 is trying to acquire lock:
> >> [8.558084] (init_mutex){+.+.+.}, at: []
> >> acpi_video_get_backlight_type+0x17/0x163 [video]
> >> [8.558104]
> >>but task is already holding lock:
> >> [8.558114] (&(&backlight_notifier)->rwsem){..}, at:
> >> [] __blocking_notifier_call_chain+0x39/0x70
> >> [8.558133]
> >>which lock already depends on the new lock.
> >>
> >> [8.558147]
> >>the existing dependency chain (in reverse order) is:
> >> [8.558158]
> >>-> #1 (&(&backlight_notifier)->rwsem){..}:
> >> [8.558170][] lock_acquire+0xb1/0x130
> >> [8.558180][] down_write+0x36/0x70
> >> [8.558189][]
> >> blocking_notifier_chain_register+0x21/0xb0
> >> [8.558202][]
> >> backlight_register_notifier+0x18/0x20
> >> [8.558212][]
> >> acpi_video_get_backlight_type+0xfa/0x163 [video]
> >> [8.558225][] acpi_video_bus_add+0x686/0xdfa
> >> [video]
> >> [8.558237][] acpi_device_probe+0x50/0xf7
> >> [8.558247][] driver_probe_device+0x14d/0x470
> >> [8.558257][] __driver_attach+0x94/0xa0
> >> [8.558266][] bus_for_each_dev+0x66/0xa0
> >> [8.558275][] driver_attach+0x1e/0x20
> >> [8.558287][] bus_add_driver+0x1ee/0x280
> >> [8.558296][] driver_register+0x60/0xe0
> >> [8.558304][]
> >> acpi_bus_register_driver+0x3b/0x43
> >> [8.558313][] acpi_video_register+0x6e/0x90
> >> [video]
> >> [8.558322][] hid_generic_exit+0x87/0x1000
> >> [hid_generic]
> >> [8.558334][] do_one_initcall+0xab/0x1d0
> >> [8.558344][] do_init_module+0x60/0x1e9
> >> [8.558353][] load_module+0x2170/0x2780
> >> [8.558363][] SyS_finit_module+0x9a/0xc0
> >> [8.558372][]
> >> entry_SYSCALL_64_fastpath+0x12/0x6f
> >> [8.558381]
> >>-> #0 (init_mutex){+.+.+.}:
> >> [8.558392][] __lock_acquire+0x1f29/0x1f90
> >> [8.558401][] lock_acquire+0xb1/0x130
> >> [8.558409][] mutex_lock_nested+0x4b/0x340
> >> [8.558417][]
> >> acpi_video_get_backlight_type+0x17/0x163 [video]
> >> [8.558430][]
> >> acpi_video_backlight_notify+0x19/0x2f [video]
> >> [8.558442][] notifier_call_chain+0x5d/0x80
> >> [8.558451][]
> >> __blocking_notifier_call_chain+0x51/0x70
> >> [8.558462][]
> >> blocking_notifier_call_chain+0x16/0x20
> >> [8.558474][]
> >> backlight_device_register+0x1a2/0x260
> >> [8.558483][]
> >> radeon_atom_backlight_init+0xda/0x1d0 [radeon]
> >> [8.558543][]
> >> radeon_link_encoder_connector+0xc3/0x130 [radeon]
> >> [8.558585][]
> >> radeon_get_atom_connector_info_from_object_table+0x3a6/0x950 [radeon]
> >> [8.558625][] radeon_modeset_init+0x5dc/0xa40
> >> [radeon]
> >> [8.558667][]
> >> radeon_driver_load_kms+0x12b/0x220 [radeon]
> >> [8.558706][] drm_dev_register+0xb1/0x100
> >> [drm]
> >> [8.558728][] drm_get_pci_dev+0x8d/0x1e0 [drm]
> >> [8.558747][] radeon_pci_probe+0xa4/0xc0
> >> [radeon]
> >> [8.558783][] local_pci_probe+0x45/0xa0
> >> [8.558792][] pci_device_probe+0xd1/0x120
> >> [8.558800][] driver_probe_device+0x14d/0x470
> >> [8.558809][] __driver_attach+0x94/0xa0
> >> [8.558818][] bus_for_each_dev+0x66/0xa0
> >> [8.558827][] driver_attach+0x1e/0x20
> >> [8.558835][] bus_add_driver+0x1ee/0x280
> >> [8.558844][] driver_register+0x60/0xe0
> >> [8.558852][] __pci_register_driver+0x64/0x70
> >> [8.558860][] drm_pci_init+0xe0/0x110 [drm]
> >> [8.558879][] radeon_init+0x9d/0xb2 [radeon]
> >> [8.558911][] do_one_initcall+0xab/0x1d0
> >> [8.558920][] do_init_module+0x60/0x1e9
> >> [
[PATCH] [media] hackrf: don't emit dev debug on a kfree'd or null dev
From: Colin Ian King Static analysis with smatch detected a couple of issues: drivers/media/usb/hackrf/hackrf.c:1533 hackrf_probe() error: we previously assumed 'dev' could be null (see line 1366) drivers/media/usb/hackrf/hackrf.c:1533 hackrf_probe() error: dereferencing freed memory 'dev' A dev_dbg message is being output on a kfree'd dev. Worse, if dev is not allocated earlier, on, a null pointer deference on dev->dev can occur onthe deb_dbg call. Clean this up by only printing a debug message if dev is not null and has not been kfree'd. Signed-off-by: Colin Ian King --- drivers/media/usb/hackrf/hackrf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/usb/hackrf/hackrf.c b/drivers/media/usb/hackrf/hackrf.c index e05bfec..faf3670 100644 --- a/drivers/media/usb/hackrf/hackrf.c +++ b/drivers/media/usb/hackrf/hackrf.c @@ -1528,9 +1528,9 @@ err_v4l2_ctrl_handler_free_tx: err_v4l2_ctrl_handler_free_rx: v4l2_ctrl_handler_free(&dev->rx_ctrl_handler); err_kfree: + dev_dbg(dev->dev, "failed=%d\n", ret); kfree(dev); err: - dev_dbg(dev->dev, "failed=%d\n", ret); return ret; } -- 2.5.0 -- 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: Slow path and cpu lock warnings - MC Next Gen
On 11/11/2015 05:30 AM, Mauro Carvalho Chehab wrote:
> Em Mon, 09 Nov 2015 08:55:06 -0700
> Shuah Khan escreveu:
>
>> On 11/09/2015 08:51 AM, Shuah Khan wrote:
>>> As I mentioned on the IRC, here is the log for the problems I am seeing.
>>> I have to do eject HVR 950Q TV stick to see the problem.
>>>
>>> mc_next_gen.v8.4 branch with no changes.
>>>
>>> I can test and debug this week.
>>>
>>> thanks,
>>> -- Shuah
>>>
>>
>> Forgot to cc linux-media, just in case others are interested
>> and have ideas on debugging.
>>
>> thanks,
>> -- Shuah
>
>> [8.558049] ==
>> [8.558056] [ INFO: possible circular locking dependency detected ]
>> [8.558063] 4.2.0-rc2+ #21 Not tainted
>> [8.558070] ---
>> [8.558077] systemd-udevd/143 is trying to acquire lock:
>> [8.558084] (init_mutex){+.+.+.}, at: []
>> acpi_video_get_backlight_type+0x17/0x163 [video]
>> [8.558104]
>>but task is already holding lock:
>> [8.558114] (&(&backlight_notifier)->rwsem){..}, at:
>> [] __blocking_notifier_call_chain+0x39/0x70
>> [8.558133]
>>which lock already depends on the new lock.
>>
>> [8.558147]
>>the existing dependency chain (in reverse order) is:
>> [8.558158]
>>-> #1 (&(&backlight_notifier)->rwsem){..}:
>> [8.558170][] lock_acquire+0xb1/0x130
>> [8.558180][] down_write+0x36/0x70
>> [8.558189][]
>> blocking_notifier_chain_register+0x21/0xb0
>> [8.558202][]
>> backlight_register_notifier+0x18/0x20
>> [8.558212][]
>> acpi_video_get_backlight_type+0xfa/0x163 [video]
>> [8.558225][] acpi_video_bus_add+0x686/0xdfa
>> [video]
>> [8.558237][] acpi_device_probe+0x50/0xf7
>> [8.558247][] driver_probe_device+0x14d/0x470
>> [8.558257][] __driver_attach+0x94/0xa0
>> [8.558266][] bus_for_each_dev+0x66/0xa0
>> [8.558275][] driver_attach+0x1e/0x20
>> [8.558287][] bus_add_driver+0x1ee/0x280
>> [8.558296][] driver_register+0x60/0xe0
>> [8.558304][] acpi_bus_register_driver+0x3b/0x43
>> [8.558313][] acpi_video_register+0x6e/0x90
>> [video]
>> [8.558322][] hid_generic_exit+0x87/0x1000
>> [hid_generic]
>> [8.558334][] do_one_initcall+0xab/0x1d0
>> [8.558344][] do_init_module+0x60/0x1e9
>> [8.558353][] load_module+0x2170/0x2780
>> [8.558363][] SyS_finit_module+0x9a/0xc0
>> [8.558372][]
>> entry_SYSCALL_64_fastpath+0x12/0x6f
>> [8.558381]
>>-> #0 (init_mutex){+.+.+.}:
>> [8.558392][] __lock_acquire+0x1f29/0x1f90
>> [8.558401][] lock_acquire+0xb1/0x130
>> [8.558409][] mutex_lock_nested+0x4b/0x340
>> [8.558417][]
>> acpi_video_get_backlight_type+0x17/0x163 [video]
>> [8.558430][]
>> acpi_video_backlight_notify+0x19/0x2f [video]
>> [8.558442][] notifier_call_chain+0x5d/0x80
>> [8.558451][]
>> __blocking_notifier_call_chain+0x51/0x70
>> [8.558462][]
>> blocking_notifier_call_chain+0x16/0x20
>> [8.558474][]
>> backlight_device_register+0x1a2/0x260
>> [8.558483][]
>> radeon_atom_backlight_init+0xda/0x1d0 [radeon]
>> [8.558543][]
>> radeon_link_encoder_connector+0xc3/0x130 [radeon]
>> [8.558585][]
>> radeon_get_atom_connector_info_from_object_table+0x3a6/0x950 [radeon]
>> [8.558625][] radeon_modeset_init+0x5dc/0xa40
>> [radeon]
>> [8.558667][]
>> radeon_driver_load_kms+0x12b/0x220 [radeon]
>> [8.558706][] drm_dev_register+0xb1/0x100 [drm]
>> [8.558728][] drm_get_pci_dev+0x8d/0x1e0 [drm]
>> [8.558747][] radeon_pci_probe+0xa4/0xc0
>> [radeon]
>> [8.558783][] local_pci_probe+0x45/0xa0
>> [8.558792][] pci_device_probe+0xd1/0x120
>> [8.558800][] driver_probe_device+0x14d/0x470
>> [8.558809][] __driver_attach+0x94/0xa0
>> [8.558818][] bus_for_each_dev+0x66/0xa0
>> [8.558827][] driver_attach+0x1e/0x20
>> [8.558835][] bus_add_driver+0x1ee/0x280
>> [8.558844][] driver_register+0x60/0xe0
>> [8.558852][] __pci_register_driver+0x64/0x70
>> [8.558860][] drm_pci_init+0xe0/0x110 [drm]
>> [8.558879][] radeon_init+0x9d/0xb2 [radeon]
>> [8.558911][] do_one_initcall+0xab/0x1d0
>> [8.558920][] do_init_module+0x60/0x1e9
>> [8.558928][] load_module+0x2170/0x2780
>> [8.558937][] SyS_finit_module+0x9a/0xc0
>> [8.558945][]
>> entry_SYSCALL_64_fastpath+0x12/0x6f
>> [8.558954]
>>other info that might help us debug this:
>>
>> [8.558968] Possible unsafe locking
Re: [PATCH 1/1] v4l2-device: Don't unregister ACPI/Device Tree based devices
On 11/11/15 14:50, Sakari Ailus wrote:
> From: Tommi Franttila
>
> When a V4L2 sub-device backed by a DT or ACPI based device was removed,
> the device was unregistered as well which certainly was not intentional,
> as the client device would not be re-created by simply reinstating the
> V4L2 sub-device (indeed the device would have to be there first!).
>
> Skip unregistering the device in case it has non-NULL of_node or fwnode.
>
> Signed-off-by: Tommi Franttila
> Signed-off-by: Sakari Ailus
> ---
> drivers/media/v4l2-core/v4l2-device.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-device.c
> b/drivers/media/v4l2-core/v4l2-device.c
> index 5b0a30b..3c8cc9a 100644
> --- a/drivers/media/v4l2-core/v4l2-device.c
> +++ b/drivers/media/v4l2-core/v4l2-device.c
> @@ -122,7 +122,8 @@ void v4l2_device_unregister(struct v4l2_device *v4l2_dev)
> We cannot rely on i2c_del_adapter to always
> unregister clients for us, since if the i2c bus
> is a platform bus, then it is never deleted. */
Can this comment be extended? This is non-trivial and it is helpful to
document this. Other than that it looks good.
Thanks,
Hans
> - if (client)
> + if (client &&
> + !client->dev.of_node && !client->dev.fwnode)
> i2c_unregister_device(client);
> continue;
> }
> @@ -131,7 +132,7 @@ void v4l2_device_unregister(struct v4l2_device *v4l2_dev)
> if (sd->flags & V4L2_SUBDEV_FL_IS_SPI) {
> struct spi_device *spi = v4l2_get_subdevdata(sd);
>
> - if (spi)
> + if (spi && !spi->dev.of_node && !spi->dev.fwnode)
> spi_unregister_device(spi);
> continue;
> }
>
--
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/1] v4l2-device: Don't unregister ACPI/Device Tree based devices
From: Tommi Franttila
When a V4L2 sub-device backed by a DT or ACPI based device was removed,
the device was unregistered as well which certainly was not intentional,
as the client device would not be re-created by simply reinstating the
V4L2 sub-device (indeed the device would have to be there first!).
Skip unregistering the device in case it has non-NULL of_node or fwnode.
Signed-off-by: Tommi Franttila
Signed-off-by: Sakari Ailus
---
drivers/media/v4l2-core/v4l2-device.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-device.c
b/drivers/media/v4l2-core/v4l2-device.c
index 5b0a30b..3c8cc9a 100644
--- a/drivers/media/v4l2-core/v4l2-device.c
+++ b/drivers/media/v4l2-core/v4l2-device.c
@@ -122,7 +122,8 @@ void v4l2_device_unregister(struct v4l2_device *v4l2_dev)
We cannot rely on i2c_del_adapter to always
unregister clients for us, since if the i2c bus
is a platform bus, then it is never deleted. */
- if (client)
+ if (client &&
+ !client->dev.of_node && !client->dev.fwnode)
i2c_unregister_device(client);
continue;
}
@@ -131,7 +132,7 @@ void v4l2_device_unregister(struct v4l2_device *v4l2_dev)
if (sd->flags & V4L2_SUBDEV_FL_IS_SPI) {
struct spi_device *spi = v4l2_get_subdevdata(sd);
- if (spi)
+ if (spi && !spi->dev.of_node && !spi->dev.fwnode)
spi_unregister_device(spi);
continue;
}
--
2.1.0.231.g7484e3b
--
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] v4l2-core/v4l2-ctrls: Filter NOOP CH_RANGE events
On 11/11/15 13:20, Ricardo Ribalda Delgado wrote:
> Hello Hans
>
> On my cameras, the framerate can be controlled in very fine steps (so
> you can be in sync with the conveyor belt). The exposure time is
> dependent on the framerate. I was calling modify_range every time
> there was a change on the framerate on all the different heads.
> Leading to invalid/noop events.
>
> I have already fixed it on my sensor code, but there is a lot of copy
> paste I thought that check belong to the framework. It also will
> give some consistency, because If my memory is good, set_ctrl does not
> send and event if the value is unchanged.
Ah, OK. That makes sense. Thanks for the explanation.
Hans
>
>
> Thanks :)
>
> And take as much time as you need for V4L2_CTRL_WHICH_DEF_VAL :-)
>
>
>
> On Wed, Nov 11, 2015 at 1:11 PM, Hans Verkuil wrote:
>> On 11/11/15 12:58, Ricardo Ribalda Delgado wrote:
>>> If modify_range is called but no range is changed, do not send the
>>> CH_RANGE event.
>>
>> While not opposed to this patch, I do wonder what triggered this patch?
>> Is it just a matter of efficiency? And since it is a driver that calls
>> this, shouldn't the driver only call this function when something
>> actually changes?
>>
>> In other words, can you give some background information?
>>
>> Regards,
>>
>> Hans
>>
>> PS: still haven't processed your V4L2_CTRL_WHICH_DEF_VAL patch series. Hope
>> to do this next week at the latest.
>>
>>>
>>> Reported-by: Dimitrios Katsaros
>>> Signed-off-by: Ricardo Ribalda Delgado
>>> ---
>>> drivers/media/v4l2-core/v4l2-ctrls.c | 23 ++-
>>> 1 file changed, 14 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
>>> b/drivers/media/v4l2-core/v4l2-ctrls.c
>>> index 4a1d9fdd14bb..f9c0e8150bd1 100644
>>> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
>>> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
>>> @@ -3300,7 +3300,8 @@ EXPORT_SYMBOL(v4l2_ctrl_notify);
>>> int __v4l2_ctrl_modify_range(struct v4l2_ctrl *ctrl,
>>> s64 min, s64 max, u64 step, s64 def)
>>> {
>>> - bool changed;
>>> + bool value_changed;
>>> + bool range_changed = false;
>>> int ret;
>>>
>>> lockdep_assert_held(ctrl->handler->lock);
>>> @@ -3324,10 +3325,14 @@ int __v4l2_ctrl_modify_range(struct v4l2_ctrl *ctrl,
>>> default:
>>> return -EINVAL;
>>> }
>>> - ctrl->minimum = min;
>>> - ctrl->maximum = max;
>>> - ctrl->step = step;
>>> - ctrl->default_value = def;
>>> + if ((ctrl->minimum != min) || (ctrl->maximum != max) ||
>>> + (ctrl->step != step) || ctrl->default_value != def) {
>>> + range_changed = true;
>>> + ctrl->minimum = min;
>>> + ctrl->maximum = max;
>>> + ctrl->step = step;
>>> + ctrl->default_value = def;
>>> + }
>>> cur_to_new(ctrl);
>>> if (validate_new(ctrl, ctrl->p_new)) {
>>> if (ctrl->type == V4L2_CTRL_TYPE_INTEGER64)
>>> @@ -3337,12 +3342,12 @@ int __v4l2_ctrl_modify_range(struct v4l2_ctrl *ctrl,
>>> }
>>>
>>> if (ctrl->type == V4L2_CTRL_TYPE_INTEGER64)
>>> - changed = *ctrl->p_new.p_s64 != *ctrl->p_cur.p_s64;
>>> + value_changed = *ctrl->p_new.p_s64 != *ctrl->p_cur.p_s64;
>>> else
>>> - changed = *ctrl->p_new.p_s32 != *ctrl->p_cur.p_s32;
>>> - if (changed)
>>> + value_changed = *ctrl->p_new.p_s32 != *ctrl->p_cur.p_s32;
>>> + if (value_changed)
>>> ret = set_ctrl(NULL, ctrl, V4L2_EVENT_CTRL_CH_RANGE);
>>> - else
>>> + else if (range_changed)
>>> send_event(NULL, ctrl, V4L2_EVENT_CTRL_CH_RANGE);
>>> return ret;
>>> }
>>>
>
>
>
--
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: Slow path and cpu lock warnings - MC Next Gen
Em Mon, 09 Nov 2015 08:55:06 -0700
Shuah Khan escreveu:
> On 11/09/2015 08:51 AM, Shuah Khan wrote:
> > As I mentioned on the IRC, here is the log for the problems I am seeing.
> > I have to do eject HVR 950Q TV stick to see the problem.
> >
> > mc_next_gen.v8.4 branch with no changes.
> >
> > I can test and debug this week.
> >
> > thanks,
> > -- Shuah
> >
>
> Forgot to cc linux-media, just in case others are interested
> and have ideas on debugging.
>
> thanks,
> -- Shuah
> [8.558049] ==
> [8.558056] [ INFO: possible circular locking dependency detected ]
> [8.558063] 4.2.0-rc2+ #21 Not tainted
> [8.558070] ---
> [8.558077] systemd-udevd/143 is trying to acquire lock:
> [8.558084] (init_mutex){+.+.+.}, at: []
> acpi_video_get_backlight_type+0x17/0x163 [video]
> [8.558104]
>but task is already holding lock:
> [8.558114] (&(&backlight_notifier)->rwsem){..}, at:
> [] __blocking_notifier_call_chain+0x39/0x70
> [8.558133]
>which lock already depends on the new lock.
>
> [8.558147]
>the existing dependency chain (in reverse order) is:
> [8.558158]
>-> #1 (&(&backlight_notifier)->rwsem){..}:
> [8.558170][] lock_acquire+0xb1/0x130
> [8.558180][] down_write+0x36/0x70
> [8.558189][]
> blocking_notifier_chain_register+0x21/0xb0
> [8.558202][]
> backlight_register_notifier+0x18/0x20
> [8.558212][]
> acpi_video_get_backlight_type+0xfa/0x163 [video]
> [8.558225][] acpi_video_bus_add+0x686/0xdfa
> [video]
> [8.558237][] acpi_device_probe+0x50/0xf7
> [8.558247][] driver_probe_device+0x14d/0x470
> [8.558257][] __driver_attach+0x94/0xa0
> [8.558266][] bus_for_each_dev+0x66/0xa0
> [8.558275][] driver_attach+0x1e/0x20
> [8.558287][] bus_add_driver+0x1ee/0x280
> [8.558296][] driver_register+0x60/0xe0
> [8.558304][] acpi_bus_register_driver+0x3b/0x43
> [8.558313][] acpi_video_register+0x6e/0x90
> [video]
> [8.558322][] hid_generic_exit+0x87/0x1000
> [hid_generic]
> [8.558334][] do_one_initcall+0xab/0x1d0
> [8.558344][] do_init_module+0x60/0x1e9
> [8.558353][] load_module+0x2170/0x2780
> [8.558363][] SyS_finit_module+0x9a/0xc0
> [8.558372][] entry_SYSCALL_64_fastpath+0x12/0x6f
> [8.558381]
>-> #0 (init_mutex){+.+.+.}:
> [8.558392][] __lock_acquire+0x1f29/0x1f90
> [8.558401][] lock_acquire+0xb1/0x130
> [8.558409][] mutex_lock_nested+0x4b/0x340
> [8.558417][]
> acpi_video_get_backlight_type+0x17/0x163 [video]
> [8.558430][]
> acpi_video_backlight_notify+0x19/0x2f [video]
> [8.558442][] notifier_call_chain+0x5d/0x80
> [8.558451][]
> __blocking_notifier_call_chain+0x51/0x70
> [8.558462][]
> blocking_notifier_call_chain+0x16/0x20
> [8.558474][]
> backlight_device_register+0x1a2/0x260
> [8.558483][]
> radeon_atom_backlight_init+0xda/0x1d0 [radeon]
> [8.558543][]
> radeon_link_encoder_connector+0xc3/0x130 [radeon]
> [8.558585][]
> radeon_get_atom_connector_info_from_object_table+0x3a6/0x950 [radeon]
> [8.558625][] radeon_modeset_init+0x5dc/0xa40
> [radeon]
> [8.558667][] radeon_driver_load_kms+0x12b/0x220
> [radeon]
> [8.558706][] drm_dev_register+0xb1/0x100 [drm]
> [8.558728][] drm_get_pci_dev+0x8d/0x1e0 [drm]
> [8.558747][] radeon_pci_probe+0xa4/0xc0 [radeon]
> [8.558783][] local_pci_probe+0x45/0xa0
> [8.558792][] pci_device_probe+0xd1/0x120
> [8.558800][] driver_probe_device+0x14d/0x470
> [8.558809][] __driver_attach+0x94/0xa0
> [8.558818][] bus_for_each_dev+0x66/0xa0
> [8.558827][] driver_attach+0x1e/0x20
> [8.558835][] bus_add_driver+0x1ee/0x280
> [8.558844][] driver_register+0x60/0xe0
> [8.558852][] __pci_register_driver+0x64/0x70
> [8.558860][] drm_pci_init+0xe0/0x110 [drm]
> [8.558879][] radeon_init+0x9d/0xb2 [radeon]
> [8.558911][] do_one_initcall+0xab/0x1d0
> [8.558920][] do_init_module+0x60/0x1e9
> [8.558928][] load_module+0x2170/0x2780
> [8.558937][] SyS_finit_module+0x9a/0xc0
> [8.558945][] entry_SYSCALL_64_fastpath+0x12/0x6f
> [8.558954]
>other info that might help us debug this:
>
> [8.558968] Possible unsafe locking scenario:
>
> [8.558978]CPU0CPU1
> [8.558984]
> [8.558989] lock(&(&backlight_notifier)->
Re: [PATCH] v4l2-core/v4l2-ctrls: Filter NOOP CH_RANGE events
Hello Hans
On my cameras, the framerate can be controlled in very fine steps (so
you can be in sync with the conveyor belt). The exposure time is
dependent on the framerate. I was calling modify_range every time
there was a change on the framerate on all the different heads.
Leading to invalid/noop events.
I have already fixed it on my sensor code, but there is a lot of copy
paste I thought that check belong to the framework. It also will
give some consistency, because If my memory is good, set_ctrl does not
send and event if the value is unchanged.
Thanks :)
And take as much time as you need for V4L2_CTRL_WHICH_DEF_VAL :-)
On Wed, Nov 11, 2015 at 1:11 PM, Hans Verkuil wrote:
> On 11/11/15 12:58, Ricardo Ribalda Delgado wrote:
>> If modify_range is called but no range is changed, do not send the
>> CH_RANGE event.
>
> While not opposed to this patch, I do wonder what triggered this patch?
> Is it just a matter of efficiency? And since it is a driver that calls
> this, shouldn't the driver only call this function when something
> actually changes?
>
> In other words, can you give some background information?
>
> Regards,
>
> Hans
>
> PS: still haven't processed your V4L2_CTRL_WHICH_DEF_VAL patch series. Hope
> to do this next week at the latest.
>
>>
>> Reported-by: Dimitrios Katsaros
>> Signed-off-by: Ricardo Ribalda Delgado
>> ---
>> drivers/media/v4l2-core/v4l2-ctrls.c | 23 ++-
>> 1 file changed, 14 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
>> b/drivers/media/v4l2-core/v4l2-ctrls.c
>> index 4a1d9fdd14bb..f9c0e8150bd1 100644
>> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
>> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
>> @@ -3300,7 +3300,8 @@ EXPORT_SYMBOL(v4l2_ctrl_notify);
>> int __v4l2_ctrl_modify_range(struct v4l2_ctrl *ctrl,
>> s64 min, s64 max, u64 step, s64 def)
>> {
>> - bool changed;
>> + bool value_changed;
>> + bool range_changed = false;
>> int ret;
>>
>> lockdep_assert_held(ctrl->handler->lock);
>> @@ -3324,10 +3325,14 @@ int __v4l2_ctrl_modify_range(struct v4l2_ctrl *ctrl,
>> default:
>> return -EINVAL;
>> }
>> - ctrl->minimum = min;
>> - ctrl->maximum = max;
>> - ctrl->step = step;
>> - ctrl->default_value = def;
>> + if ((ctrl->minimum != min) || (ctrl->maximum != max) ||
>> + (ctrl->step != step) || ctrl->default_value != def) {
>> + range_changed = true;
>> + ctrl->minimum = min;
>> + ctrl->maximum = max;
>> + ctrl->step = step;
>> + ctrl->default_value = def;
>> + }
>> cur_to_new(ctrl);
>> if (validate_new(ctrl, ctrl->p_new)) {
>> if (ctrl->type == V4L2_CTRL_TYPE_INTEGER64)
>> @@ -3337,12 +3342,12 @@ int __v4l2_ctrl_modify_range(struct v4l2_ctrl *ctrl,
>> }
>>
>> if (ctrl->type == V4L2_CTRL_TYPE_INTEGER64)
>> - changed = *ctrl->p_new.p_s64 != *ctrl->p_cur.p_s64;
>> + value_changed = *ctrl->p_new.p_s64 != *ctrl->p_cur.p_s64;
>> else
>> - changed = *ctrl->p_new.p_s32 != *ctrl->p_cur.p_s32;
>> - if (changed)
>> + value_changed = *ctrl->p_new.p_s32 != *ctrl->p_cur.p_s32;
>> + if (value_changed)
>> ret = set_ctrl(NULL, ctrl, V4L2_EVENT_CTRL_CH_RANGE);
>> - else
>> + else if (range_changed)
>> send_event(NULL, ctrl, V4L2_EVENT_CTRL_CH_RANGE);
>> return ret;
>> }
>>
--
Ricardo Ribalda
--
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] v4l2-core/v4l2-ctrls: Filter NOOP CH_RANGE events
On 11/11/15 12:58, Ricardo Ribalda Delgado wrote:
> If modify_range is called but no range is changed, do not send the
> CH_RANGE event.
While not opposed to this patch, I do wonder what triggered this patch?
Is it just a matter of efficiency? And since it is a driver that calls
this, shouldn't the driver only call this function when something
actually changes?
In other words, can you give some background information?
Regards,
Hans
PS: still haven't processed your V4L2_CTRL_WHICH_DEF_VAL patch series. Hope
to do this next week at the latest.
>
> Reported-by: Dimitrios Katsaros
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> drivers/media/v4l2-core/v4l2-ctrls.c | 23 ++-
> 1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index 4a1d9fdd14bb..f9c0e8150bd1 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -3300,7 +3300,8 @@ EXPORT_SYMBOL(v4l2_ctrl_notify);
> int __v4l2_ctrl_modify_range(struct v4l2_ctrl *ctrl,
> s64 min, s64 max, u64 step, s64 def)
> {
> - bool changed;
> + bool value_changed;
> + bool range_changed = false;
> int ret;
>
> lockdep_assert_held(ctrl->handler->lock);
> @@ -3324,10 +3325,14 @@ int __v4l2_ctrl_modify_range(struct v4l2_ctrl *ctrl,
> default:
> return -EINVAL;
> }
> - ctrl->minimum = min;
> - ctrl->maximum = max;
> - ctrl->step = step;
> - ctrl->default_value = def;
> + if ((ctrl->minimum != min) || (ctrl->maximum != max) ||
> + (ctrl->step != step) || ctrl->default_value != def) {
> + range_changed = true;
> + ctrl->minimum = min;
> + ctrl->maximum = max;
> + ctrl->step = step;
> + ctrl->default_value = def;
> + }
> cur_to_new(ctrl);
> if (validate_new(ctrl, ctrl->p_new)) {
> if (ctrl->type == V4L2_CTRL_TYPE_INTEGER64)
> @@ -3337,12 +3342,12 @@ int __v4l2_ctrl_modify_range(struct v4l2_ctrl *ctrl,
> }
>
> if (ctrl->type == V4L2_CTRL_TYPE_INTEGER64)
> - changed = *ctrl->p_new.p_s64 != *ctrl->p_cur.p_s64;
> + value_changed = *ctrl->p_new.p_s64 != *ctrl->p_cur.p_s64;
> else
> - changed = *ctrl->p_new.p_s32 != *ctrl->p_cur.p_s32;
> - if (changed)
> + value_changed = *ctrl->p_new.p_s32 != *ctrl->p_cur.p_s32;
> + if (value_changed)
> ret = set_ctrl(NULL, ctrl, V4L2_EVENT_CTRL_CH_RANGE);
> - else
> + else if (range_changed)
> send_event(NULL, ctrl, V4L2_EVENT_CTRL_CH_RANGE);
> return ret;
> }
>
--
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] v4l2-core/v4l2-ctrls: Filter NOOP CH_RANGE events
If modify_range is called but no range is changed, do not send the
CH_RANGE event.
Reported-by: Dimitrios Katsaros
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/media/v4l2-core/v4l2-ctrls.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 4a1d9fdd14bb..f9c0e8150bd1 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -3300,7 +3300,8 @@ EXPORT_SYMBOL(v4l2_ctrl_notify);
int __v4l2_ctrl_modify_range(struct v4l2_ctrl *ctrl,
s64 min, s64 max, u64 step, s64 def)
{
- bool changed;
+ bool value_changed;
+ bool range_changed = false;
int ret;
lockdep_assert_held(ctrl->handler->lock);
@@ -3324,10 +3325,14 @@ int __v4l2_ctrl_modify_range(struct v4l2_ctrl *ctrl,
default:
return -EINVAL;
}
- ctrl->minimum = min;
- ctrl->maximum = max;
- ctrl->step = step;
- ctrl->default_value = def;
+ if ((ctrl->minimum != min) || (ctrl->maximum != max) ||
+ (ctrl->step != step) || ctrl->default_value != def) {
+ range_changed = true;
+ ctrl->minimum = min;
+ ctrl->maximum = max;
+ ctrl->step = step;
+ ctrl->default_value = def;
+ }
cur_to_new(ctrl);
if (validate_new(ctrl, ctrl->p_new)) {
if (ctrl->type == V4L2_CTRL_TYPE_INTEGER64)
@@ -3337,12 +3342,12 @@ int __v4l2_ctrl_modify_range(struct v4l2_ctrl *ctrl,
}
if (ctrl->type == V4L2_CTRL_TYPE_INTEGER64)
- changed = *ctrl->p_new.p_s64 != *ctrl->p_cur.p_s64;
+ value_changed = *ctrl->p_new.p_s64 != *ctrl->p_cur.p_s64;
else
- changed = *ctrl->p_new.p_s32 != *ctrl->p_cur.p_s32;
- if (changed)
+ value_changed = *ctrl->p_new.p_s32 != *ctrl->p_cur.p_s32;
+ if (value_changed)
ret = set_ctrl(NULL, ctrl, V4L2_EVENT_CTRL_CH_RANGE);
- else
+ else if (range_changed)
send_event(NULL, ctrl, V4L2_EVENT_CTRL_CH_RANGE);
return ret;
}
--
2.6.2
--
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 v2] [media] ivtv: avoid going past input/audio array
As reported by smatch: drivers/media/pci/ivtv/ivtv-driver.c:832 ivtv_init_struct2() error: buffer overflow 'itv->card->video_inputs' 6 <= 6 drivers/media/pci/ivtv/ivtv-driver.c:832 ivtv_init_struct2() error: buffer overflow 'itv->card->video_inputs' 6 <= 6 Signed-off-by: Mauro Carvalho Chehab --- v2: Added a missing new line after the patch subject. diff --git a/drivers/media/pci/ivtv/ivtv-driver.c b/drivers/media/pci/ivtv/ivtv-driver.c index 21501c560610..374033a5bdaf 100644 --- a/drivers/media/pci/ivtv/ivtv-driver.c +++ b/drivers/media/pci/ivtv/ivtv-driver.c @@ -826,7 +826,7 @@ static void ivtv_init_struct2(struct ivtv *itv) IVTV_CARD_INPUT_VID_TUNER) break; } - if (i == itv->nof_inputs) + if (i >= itv->nof_inputs) i = 0; itv->active_input = i; itv->audio_input = itv->card->video_inputs[i].audio_index; -- 2.4.3 -- 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] Revert "[media] ivtv: avoid going past input/audio array"
This patch broke ivtv logic, as reported at
https://bugzilla.redhat.com/show_bug.cgi?id=1278942
This reverts commit 09290cc885937cab3b2d60a6d48fe3d2d3e04061.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/pci/ivtv/ivtv-driver.c
b/drivers/media/pci/ivtv/ivtv-driver.c
index 3a6f668b14b8..21501c560610 100644
--- a/drivers/media/pci/ivtv/ivtv-driver.c
+++ b/drivers/media/pci/ivtv/ivtv-driver.c
@@ -805,11 +805,11 @@ static void ivtv_init_struct2(struct ivtv *itv)
{
int i;
- for (i = 0; i < IVTV_CARD_MAX_VIDEO_INPUTS - 1; i++)
+ for (i = 0; i < IVTV_CARD_MAX_VIDEO_INPUTS; i++)
if (itv->card->video_inputs[i].video_type == 0)
break;
itv->nof_inputs = i;
- for (i = 0; i < IVTV_CARD_MAX_AUDIO_INPUTS - 1; i++)
+ for (i = 0; i < IVTV_CARD_MAX_AUDIO_INPUTS; i++)
if (itv->card->audio_inputs[i].audio_type == 0)
break;
itv->nof_audio_inputs = i;
--
2.4.3
--
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] ivtv: avoid going past input/audio array As reported by smatch: drivers/media/pci/ivtv/ivtv-driver.c:832 ivtv_init_struct2() error: buffer overflow 'itv->card->video_inputs' 6 <=
drivers/media/pci/ivtv/ivtv-driver.c:832 ivtv_init_struct2() error: buffer overflow 'itv->card->video_inputs' 6 <= 6 Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/pci/ivtv/ivtv-driver.c b/drivers/media/pci/ivtv/ivtv-driver.c index 21501c560610..374033a5bdaf 100644 --- a/drivers/media/pci/ivtv/ivtv-driver.c +++ b/drivers/media/pci/ivtv/ivtv-driver.c @@ -826,7 +826,7 @@ static void ivtv_init_struct2(struct ivtv *itv) IVTV_CARD_INPUT_VID_TUNER) break; } - if (i == itv->nof_inputs) + if (i >= itv->nof_inputs) i = 0; itv->active_input = i; itv->audio_input = itv->card->video_inputs[i].audio_index; -- 2.4.3 -- 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
