Re: v4l2: circular locking between mmap_sem and device mutex
On 05/23/2014 04:53 AM, Sasha Levin wrote:
> ping?
I've reproduced it and plan to look at it soon.
Regards,
Hans
>
> On 05/05/2014 11:49 AM, Sasha Levin wrote:
>> Hi all,
>>
>> While fuzzing with trinity inside a KVM tools guest running latest -next
>> kernel I've stumbled on the following:
>>
>>
>> [ 2179.111265] ==
>> [ 2179.112228] [ INFO: possible circular locking dependency detected ]
>> [ 2179.113144] 3.15.0-rc3-next-20140502-sasha-00020-g3183c20 #432 Tainted: G
>>W
>> [ 2179.114325] ---
>> [ 2179.115286] trinity-c15/27050 is trying to acquire lock:
>> [ 2179.116071] (&dev->mutex#3){+.+.+.}, at: vb2_fop_mmap
>> (drivers/media/v4l2-core/videobuf2-core.c:3029 (discriminator 1))
>> [ 2179.117347]
>> [ 2179.117347] but task is already holding lock:
>> [ 2179.118185] (&mm->mmap_sem){++}, at: vm_mmap_pgoff (mm/util.c:398)
>> [ 2179.120023]
>> [ 2179.120023] which lock already depends on the new lock.
>> [ 2179.120023]
>> [ 2179.120036]
>> [ 2179.120036] the existing dependency chain (in reverse order) is:
>> [ 2179.120036]
>> -> #1 (&mm->mmap_sem){++}:
>> [ 2179.120036] lock_acquire (arch/x86/include/asm/current.h:14
>> kernel/locking/lockdep.c:3602)
>> [ 2179.120036] might_fault (mm/memory.c:4368)
>> [ 2179.120036] video_usercopy (arch/x86/include/asm/uaccess.h:713
>> drivers/media/v4l2-core/v4l2-ioctl.c:2369)
>> [ 2179.120036] video_ioctl2 (drivers/media/v4l2-core/v4l2-ioctl.c:2445)
>> [ 2179.120036] v4l2_ioctl (drivers/media/v4l2-core/v4l2-dev.c:355)
>> [ 2179.120036] do_vfs_ioctl (fs/ioctl.c:44 fs/ioctl.c:598)
>> [ 2179.120036] SyS_ioctl (include/linux/file.h:38 fs/ioctl.c:614
>> fs/ioctl.c:604)
>> [ 2179.120036] tracesys (arch/x86/kernel/entry_64.S:746)
>> [ 2179.120036]
>> -> #0 (&dev->mutex#3){+.+.+.}:
>> [ 2179.120036] __lock_acquire (kernel/locking/lockdep.c:1840
>> kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131
>> kernel/locking/lockdep.c:3182)
>> [ 2179.120036] lock_acquire (arch/x86/include/asm/current.h:14
>> kernel/locking/lockdep.c:3602)
>> [ 2179.120036] mutex_lock_interruptible_nested (kernel/locking/mutex.c:486
>> kernel/locking/mutex.c:616)
>> [ 2179.120036] vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
>> (discriminator 1))
>> [ 2179.120036] v4l2_mmap (drivers/media/v4l2-core/v4l2-dev.c:427)
>> [ 2179.120036] mmap_region (mm/mmap.c:1577)
>> [ 2179.120036] do_mmap_pgoff (mm/mmap.c:1369)
>> [ 2179.120036] vm_mmap_pgoff (mm/util.c:400)
>> [ 2179.120036] SyS_mmap_pgoff (mm/mmap.c:1418 mm/mmap.c:1378)
>> [ 2179.120036] SyS_mmap (arch/x86/kernel/sys_x86_64.c:72)
>> [ 2179.120036] tracesys (arch/x86/kernel/entry_64.S:746)
>> [ 2179.120036]
>> [ 2179.120036] other info that might help us debug this:
>> [ 2179.120036]
>> [ 2179.120036] Possible unsafe locking scenario:
>> [ 2179.120036]
>> [ 2179.120036]CPU0CPU1
>> [ 2179.120036]
>> [ 2179.120036] lock(&mm->mmap_sem);
>> [ 2179.120036]lock(&dev->mutex#3);
>> [ 2179.120036]lock(&mm->mmap_sem);
>> [ 2179.120036] lock(&dev->mutex#3);
>> [ 2179.120036]
>> [ 2179.120036] *** DEADLOCK ***
>> [ 2179.120036]
>> [ 2179.120036] 1 lock held by trinity-c15/27050:
>> [ 2179.120036] #0: (&mm->mmap_sem){++}, at: vm_mmap_pgoff (mm/util.c:398)
>> [ 2179.120036]
>> [ 2179.120036] stack backtrace:
>> [ 2179.120036] CPU: 1 PID: 27050 Comm: trinity-c15 Tainted: GW
>> 3.15.0-rc3-next-20140502-sasha-00020-g3183c20 #432
>> [ 2179.120036] baa718e0 88065df9dab8 b75326bb
>> 0002
>> [ 2179.120036] baa718e0 88065df9db08 b7525488
>> 0001
>> [ 2179.120036] 88065df9db98 88065df9db08 88065dd63cf0
>> 88065dd63d28
>> [ 2179.120036] Call Trace:
>> [ 2179.120036] dump_stack (lib/dump_stack.c:52)
>> [ 2179.120036] print_circular_bug (kernel/locking/lockdep.c:1216)
>> [ 2179.120036] __lock_acquire (kernel/locking/lockdep.c:1840
>> kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131
>> kernel/locking/lockdep.c:3182)
>> [ 2179.120036] ? mmap_region (mm/mmap.c:1556)
>> [ 2179.120036] lock_acquire (arch/x86/include/asm/current.h:14
>> kernel/locking/lockdep.c:3602)
>> [ 2179.120036] ? vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
>> (discriminator 1))
>> [ 2179.120036] mutex_lock_interruptible_nested (kernel/locking/mutex.c:486
>> kernel/locking/mutex.c:616)
>> [ 2179.120036] ? vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
>> (discriminator 1))
>> [ 2179.120036] ? vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
>> (discriminator 1))
>> [ 2179.120036] ? get_parent_ip (kernel/sched/core.c:2485)
>> [ 2179.120036] vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
>> (discriminator 1))
>> [ 2179.120036] ? mmap_region (mm/mmap.c:
Re: [PATCH v2 2/3] [media] atmel-isi: convert the pdata from pointer to structure
Hi, Guennadi On 5/19/2014 4:59 AM, Guennadi Liakhovetski wrote: Hi Josh, I'm still waiting for an update of Ben's patches to then also apply yours, but I decided to have a look at yours now to see if I find anything, that might be worth changing. A small note to this one below. On Tue, 25 Mar 2014, Josh Wu wrote: Now the platform data is initialized by allocation of isi structure. In the future, we use pdata to store the dt parameters. Signed-off-by: Josh Wu --- v1 --> v2: no change. drivers/media/platform/soc_camera/atmel-isi.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/media/platform/soc_camera/atmel-isi.c b/drivers/media/platform/soc_camera/atmel-isi.c index 9d977c5..f4add0a 100644 --- a/drivers/media/platform/soc_camera/atmel-isi.c +++ b/drivers/media/platform/soc_camera/atmel-isi.c [snip] @@ -912,7 +912,7 @@ static int atmel_isi_probe(struct platform_device *pdev) if (IS_ERR(isi->pclk)) return PTR_ERR(isi->pclk); - isi->pdata = pdata; + memcpy(&isi->pdata, pdata, sizeof(struct isi_platform_data)); I think it'd be better to use + memcpy(&isi->pdata, pdata, sizeof(isi->pdata)); This way if the type of the pdata changes at any time in the future this line will not have to be changed. If you don't mind I can make this change myself, so you don't have to make a new version just for this. Thanks for pointing it out. I think I will sent out a new version of patch (include bus-width parsing) then I will included with this fix. Best Regards, Josh Wu Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 v2 3/3] [media] atmel-isi: add primary DT support
Hi, Guennadi
On 5/19/2014 5:51 AM, Guennadi Liakhovetski wrote:
On Tue, 25 Mar 2014, Josh Wu wrote:
This patch add the DT support for Atmel ISI driver.
It use the same v4l2 DT interface that defined in video-interfaces.txt.
Signed-off-by: Josh Wu
Cc: devicet...@vger.kernel.org
---
v1 --> v2:
refine the binding document.
add port node description.
removed the optional property.
.../devicetree/bindings/media/atmel-isi.txt| 50
drivers/media/platform/soc_camera/atmel-isi.c | 31 +++-
2 files changed, 79 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/atmel-isi.txt
[snip]
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index f4add0a..d6a1f7b 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
[snip]
@@ -885,6 +887,20 @@ static int atmel_isi_remove(struct platform_device *pdev)
return 0;
}
+static int atmel_isi_probe_dt(struct atmel_isi *isi,
+ struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+
+ /* Default settings for ISI */
+ isi->pdata.full_mode = 1;
+ isi->pdata.mck_hz = ISI_DEFAULT_MCLK_FREQ;
+ isi->pdata.frate = ISI_CFG1_FRATE_CAPTURE_ALL;
The above flags eventually should probably partially be added as new
driver-specific DT properties, partially derived from DT clock bindings.
But I'm ok to have them fixed like this in the initial version.
+ isi->pdata.data_width_flags = ISI_DATAWIDTH_8 | ISI_DATAWIDTH_10;
Whereas these flags, I think, should already now be derived from the
bus-width standard property?
yes. I agree.
v4l2_of_parse_parallel_bus() will extract
them for you and I just asked Ben to add a call to
v4l2_of_parse_endpoint() to his patch.
Is it better to call v4l2_of_parse_endpoint() in the atmel-isi driver? I
think the dt parsing stuff should be done by host driver and sensor
driver itself. No need to call v4l2_of_parse_endpoint() in soc-camera.c.
Consequently you'll have to
rearrange bus-width interpretation in isi_camera_try_bus_param() a bit and
use OF parsing results there directly if available? Or maybe you find a
better way. It would certainly be better to extend your probing code and
just use OF results to initialise isi->width_flags, but that might be
impossible, because OF parsing would be performed inside
soc_camera_host_register() and your isi_camera_try_bus_param() can also be
called immediately from it if all required I2C devices are already
available?
I am little bit confuse here. I don't see any issue in above case. Since
atmel_isi_probe_dt() will always be called earlier then
soc_camera_host_register().
That means when soc_camera_host_register() called
isi_camera_try_bus_param(), the isi->width_flags are already initialized
in a valid value by atmel_isi_probe_dt().
Am I missing anything here?
If your I2C subdevice drivers defer probing until the host has
probed, then you could initialise .width_flags after
soc_camera_host_register(), but you cannot rely on that.
I tested these two cases without any issue:
1. In dtb, the i2c sensor dt node probe earlier than atmel-isi dt node.
i2c sensor will do a defer probe here as mclk is not found until
atmel-isi driver probed and call soc_camera_host_register().
2. In dtb, the atmel-isi dt node is probed earlier than i2c sensor.
Best Regards,
Josh Wu
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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
Re: v4l2: circular locking between mmap_sem and device mutex
ping?
On 05/05/2014 11:49 AM, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest running latest -next
> kernel I've stumbled on the following:
>
>
> [ 2179.111265] ==
> [ 2179.112228] [ INFO: possible circular locking dependency detected ]
> [ 2179.113144] 3.15.0-rc3-next-20140502-sasha-00020-g3183c20 #432 Tainted: G
> W
> [ 2179.114325] ---
> [ 2179.115286] trinity-c15/27050 is trying to acquire lock:
> [ 2179.116071] (&dev->mutex#3){+.+.+.}, at: vb2_fop_mmap
> (drivers/media/v4l2-core/videobuf2-core.c:3029 (discriminator 1))
> [ 2179.117347]
> [ 2179.117347] but task is already holding lock:
> [ 2179.118185] (&mm->mmap_sem){++}, at: vm_mmap_pgoff (mm/util.c:398)
> [ 2179.120023]
> [ 2179.120023] which lock already depends on the new lock.
> [ 2179.120023]
> [ 2179.120036]
> [ 2179.120036] the existing dependency chain (in reverse order) is:
> [ 2179.120036]
> -> #1 (&mm->mmap_sem){++}:
> [ 2179.120036] lock_acquire (arch/x86/include/asm/current.h:14
> kernel/locking/lockdep.c:3602)
> [ 2179.120036] might_fault (mm/memory.c:4368)
> [ 2179.120036] video_usercopy (arch/x86/include/asm/uaccess.h:713
> drivers/media/v4l2-core/v4l2-ioctl.c:2369)
> [ 2179.120036] video_ioctl2 (drivers/media/v4l2-core/v4l2-ioctl.c:2445)
> [ 2179.120036] v4l2_ioctl (drivers/media/v4l2-core/v4l2-dev.c:355)
> [ 2179.120036] do_vfs_ioctl (fs/ioctl.c:44 fs/ioctl.c:598)
> [ 2179.120036] SyS_ioctl (include/linux/file.h:38 fs/ioctl.c:614
> fs/ioctl.c:604)
> [ 2179.120036] tracesys (arch/x86/kernel/entry_64.S:746)
> [ 2179.120036]
> -> #0 (&dev->mutex#3){+.+.+.}:
> [ 2179.120036] __lock_acquire (kernel/locking/lockdep.c:1840
> kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131
> kernel/locking/lockdep.c:3182)
> [ 2179.120036] lock_acquire (arch/x86/include/asm/current.h:14
> kernel/locking/lockdep.c:3602)
> [ 2179.120036] mutex_lock_interruptible_nested (kernel/locking/mutex.c:486
> kernel/locking/mutex.c:616)
> [ 2179.120036] vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
> (discriminator 1))
> [ 2179.120036] v4l2_mmap (drivers/media/v4l2-core/v4l2-dev.c:427)
> [ 2179.120036] mmap_region (mm/mmap.c:1577)
> [ 2179.120036] do_mmap_pgoff (mm/mmap.c:1369)
> [ 2179.120036] vm_mmap_pgoff (mm/util.c:400)
> [ 2179.120036] SyS_mmap_pgoff (mm/mmap.c:1418 mm/mmap.c:1378)
> [ 2179.120036] SyS_mmap (arch/x86/kernel/sys_x86_64.c:72)
> [ 2179.120036] tracesys (arch/x86/kernel/entry_64.S:746)
> [ 2179.120036]
> [ 2179.120036] other info that might help us debug this:
> [ 2179.120036]
> [ 2179.120036] Possible unsafe locking scenario:
> [ 2179.120036]
> [ 2179.120036]CPU0CPU1
> [ 2179.120036]
> [ 2179.120036] lock(&mm->mmap_sem);
> [ 2179.120036]lock(&dev->mutex#3);
> [ 2179.120036]lock(&mm->mmap_sem);
> [ 2179.120036] lock(&dev->mutex#3);
> [ 2179.120036]
> [ 2179.120036] *** DEADLOCK ***
> [ 2179.120036]
> [ 2179.120036] 1 lock held by trinity-c15/27050:
> [ 2179.120036] #0: (&mm->mmap_sem){++}, at: vm_mmap_pgoff (mm/util.c:398)
> [ 2179.120036]
> [ 2179.120036] stack backtrace:
> [ 2179.120036] CPU: 1 PID: 27050 Comm: trinity-c15 Tainted: GW
> 3.15.0-rc3-next-20140502-sasha-00020-g3183c20 #432
> [ 2179.120036] baa718e0 88065df9dab8 b75326bb
> 0002
> [ 2179.120036] baa718e0 88065df9db08 b7525488
> 0001
> [ 2179.120036] 88065df9db98 88065df9db08 88065dd63cf0
> 88065dd63d28
> [ 2179.120036] Call Trace:
> [ 2179.120036] dump_stack (lib/dump_stack.c:52)
> [ 2179.120036] print_circular_bug (kernel/locking/lockdep.c:1216)
> [ 2179.120036] __lock_acquire (kernel/locking/lockdep.c:1840
> kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131
> kernel/locking/lockdep.c:3182)
> [ 2179.120036] ? mmap_region (mm/mmap.c:1556)
> [ 2179.120036] lock_acquire (arch/x86/include/asm/current.h:14
> kernel/locking/lockdep.c:3602)
> [ 2179.120036] ? vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
> (discriminator 1))
> [ 2179.120036] mutex_lock_interruptible_nested (kernel/locking/mutex.c:486
> kernel/locking/mutex.c:616)
> [ 2179.120036] ? vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
> (discriminator 1))
> [ 2179.120036] ? vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
> (discriminator 1))
> [ 2179.120036] ? get_parent_ip (kernel/sched/core.c:2485)
> [ 2179.120036] vb2_fop_mmap (drivers/media/v4l2-core/videobuf2-core.c:3029
> (discriminator 1))
> [ 2179.120036] ? mmap_region (mm/mmap.c:1556)
> [ 2179.120036] ? mmap_region (mm/mmap.c:1556)
> [ 2179.120036] v4l2_mmap (drivers/media/v4l2-core/v4l2-dev.c:427)
> [ 2179.120036] mmap_region (mm/mmap.c:1577)
> [ 2179.120036] do_mmap_pgoff (mm/mmap.c:1369)
> [
cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Fri May 23 04:00:25 CEST 2014 git branch: test git hash: e899966f626f1f657a4a7bac736c0b9ae5a243ea gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.14-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: 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.31.14-i686: 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-i686: OK linux-3.13-i686: OK linux-3.14-i686: OK linux-3.15-rc1-i686: OK linux-2.6.31.14-x86_64: 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-x86_64: OK linux-3.13-x86_64: OK linux-3.14-x86_64: OK linux-3.15-rc1-x86_64: OK apps: OK spec-git: OK sparse version: v0.5.0-11-g38d1124 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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
[PATCH] Staging: Media: sn9c102: Fixed a pointer declaration coding style issue
Fixed the ERROR thrown off by checkpatch.pl.
Signed-off-by: Chaitanya Hazarey
---
drivers/staging/media/sn9c102/sn9c102_tas5130d1b.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/media/sn9c102/sn9c102_tas5130d1b.c
b/drivers/staging/media/sn9c102/sn9c102_tas5130d1b.c
index a30bbc4..725de85 100644
--- a/drivers/staging/media/sn9c102/sn9c102_tas5130d1b.c
+++ b/drivers/staging/media/sn9c102/sn9c102_tas5130d1b.c
@@ -23,7 +23,7 @@
#include "sn9c102_devtable.h"
-static int tas5130d1b_init(struct sn9c102_device* cam)
+static int tas5130d1b_init(struct sn9c102_device *cam)
{
int err;
@@ -36,8 +36,8 @@ static int tas5130d1b_init(struct sn9c102_device* cam)
}
-static int tas5130d1b_set_ctrl(struct sn9c102_device* cam,
- const struct v4l2_control* ctrl)
+static int tas5130d1b_set_ctrl(struct sn9c102_device *cam,
+ const struct v4l2_control *ctrl)
{
int err = 0;
@@ -56,10 +56,10 @@ static int tas5130d1b_set_ctrl(struct sn9c102_device* cam,
}
-static int tas5130d1b_set_crop(struct sn9c102_device* cam,
- const struct v4l2_rect* rect)
+static int tas5130d1b_set_crop(struct sn9c102_device *cam,
+ const struct v4l2_rect *rect)
{
- struct sn9c102_sensor* s = sn9c102_get_sensor(cam);
+ struct sn9c102_sensor *s = sn9c102_get_sensor(cam);
u8 h_start = (u8)(rect->left - s->cropcap.bounds.left) + 104,
v_start = (u8)(rect->top - s->cropcap.bounds.top) + 12;
int err = 0;
@@ -76,8 +76,8 @@ static int tas5130d1b_set_crop(struct sn9c102_device* cam,
}
-static int tas5130d1b_set_pix_format(struct sn9c102_device* cam,
- const struct v4l2_pix_format* pix)
+static int tas5130d1b_set_pix_format(struct sn9c102_device *cam,
+ const struct v4l2_pix_format *pix)
{
int err = 0;
@@ -146,7 +146,7 @@ static const struct sn9c102_sensor tas5130d1b = {
};
-int sn9c102_probe_tas5130d1b(struct sn9c102_device* cam)
+int sn9c102_probe_tas5130d1b(struct sn9c102_device *cam)
{
const struct usb_device_id tas5130d1b_id_table[] = {
{ USB_DEVICE(0x0c45, 0x6024), },
--
1.9.1
--
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] [media] dm644x_ccdc: remove check for CONFIG_DM644X_VIDEO_PORT_ENABLE
A check for CONFIG_DM644X_VIDEO_PORT_ENABLE was added in v2.6.32. The related Kconfig symbol was never added so this check has always evaluated to false. Remove that check. Signed-off-by: Paul Bolle --- Untested. Related, trivial, cleanup: make ccdc_enable_vport() a oneliner. drivers/media/platform/davinci/dm644x_ccdc.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/media/platform/davinci/dm644x_ccdc.c b/drivers/media/platform/davinci/dm644x_ccdc.c index 30fa08405d61..07e98df3d867 100644 --- a/drivers/media/platform/davinci/dm644x_ccdc.c +++ b/drivers/media/platform/davinci/dm644x_ccdc.c @@ -581,13 +581,8 @@ void ccdc_config_raw(void) config_params->alaw.enable) syn_mode |= CCDC_DATA_PACK_ENABLE; -#ifdef CONFIG_DM644X_VIDEO_PORT_ENABLE - /* enable video port */ - val = CCDC_ENABLE_VIDEO_PORT; -#else /* disable video port */ val = CCDC_DISABLE_VIDEO_PORT; -#endif if (config_params->data_sz == CCDC_DATA_8BITS) val |= (CCDC_DATA_10BITS & CCDC_FMTCFG_VPIN_MASK) -- 1.9.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: am i in the right list?
> Should i email Hans Verkuil or would he see this already ? > Fresco Logic FL2000 USB to VGA adapter He would have seen this already. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- 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: am i in the right list?
Should i email Hans Verkuil or would he see this already ? Fresco Logic FL2000 USB to VGA adapter Mike KC7NOA On Wed, May 21, 2014 at 11:39 AM, Antti Palosaari wrote: > Moikka > > > On 05/21/2014 09:28 PM, Michael Durkin wrote: >> >> Im looking for support for a Fresco logic FL2000 USB to VGA adapter ... >> Is any one already working on this or am i in the wrong list? > > > List is right AFAIK. In my understanding it should be implement as a V4L2 > device which sends picture, like a analog RV modulator. I am not sure if > there is any existing driver. There is modulator driver for audio > transmitters, though. > > Hans Verkuil is correct person to answer that as he known about everything > from V4L2. > > 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
[PATCH] [media] dib0090: remove manual configuration system
dib0900.c has always shipped with its own, manual, configuration
system. There a three problems with it.
1) macros that are defined, but not used:
CONFIG_SYS_DVBT
CONFIG_DIB0090_USE_PWM_AGC
2) checks for macros that are always true:
CONFIG_SYS_ISDBT
CONFIG_BAND_CBAND
CONFIG_BAND_VHF
CONFIG_BAND_UHF
3) checks for macros that are never defined and are always false:
CONFIG_BAND_SBAND
CONFIG_STANDARD_DAB
CONFIG_STANDARD_DVBT
CONFIG_TUNER_DIB0090_P1B_SUPPORT
CONFIG_BAND_LBAND
Remove all references to these macros, and, of course, remove the code
hidden behind the macros that are never defined too.
Signed-off-by: Paul Bolle
---
0) Compile tested. I don't have the hardware.
1) This might be a bit hard to review. Should I split it in two or three
patches?
2) dib0070.c has a reference to CONFIG_SYS_ISDBT. I'll remove it in a
future patch.
3) If this gets accepted I might be inclined to clean up the coding
style in a future patch. It needs cleaning up quite a bit.
drivers/media/dvb-frontends/dib0090.c | 130 --
1 file changed, 130 deletions(-)
diff --git a/drivers/media/dvb-frontends/dib0090.c
b/drivers/media/dvb-frontends/dib0090.c
index 3ee22ff76315..bb50fec4f475 100644
--- a/drivers/media/dvb-frontends/dib0090.c
+++ b/drivers/media/dvb-frontends/dib0090.c
@@ -46,13 +46,6 @@ MODULE_PARM_DESC(debug, "turn on debugging (default: 0)");
} \
} while (0)
-#define CONFIG_SYS_DVBT
-#define CONFIG_SYS_ISDBT
-#define CONFIG_BAND_CBAND
-#define CONFIG_BAND_VHF
-#define CONFIG_BAND_UHF
-#define CONFIG_DIB0090_USE_PWM_AGC
-
#define EN_LNA0 0x8000
#define EN_LNA1 0x4000
#define EN_LNA2 0x2000
@@ -1165,24 +1158,14 @@ int dib0090_gain_control(struct dvb_frontend *fe)
state->agc_freeze = 0;
dib0090_write_reg(state, 0x04, 0x0);
-#ifdef CONFIG_BAND_SBAND
- if (state->current_band == BAND_SBAND) {
- dib0090_set_rframp(state, rf_ramp_sband);
- dib0090_set_bbramp(state, bb_ramp_boost);
- } else
-#endif
-#ifdef CONFIG_BAND_VHF
if (state->current_band == BAND_VHF && !state->identity.p1g) {
dib0090_set_rframp(state, rf_ramp_pwm_vhf);
dib0090_set_bbramp(state, bb_ramp_pwm_normal);
} else
-#endif
-#ifdef CONFIG_BAND_CBAND
if (state->current_band == BAND_CBAND && !state->identity.p1g) {
dib0090_set_rframp(state, rf_ramp_pwm_cband);
dib0090_set_bbramp(state, bb_ramp_pwm_normal);
} else
-#endif
if ((state->current_band == BAND_CBAND || state->current_band
== BAND_VHF) && state->identity.p1g) {
dib0090_set_rframp(state, rf_ramp_pwm_cband_7090p);
dib0090_set_bbramp(state, bb_ramp_pwm_normal_socs);
@@ -1220,14 +1203,12 @@ int dib0090_gain_control(struct dvb_frontend *fe)
if (*tune_state == CT_AGC_STEP_0) {
if (wbd_error < 0 && state->rf_gain_limit > 0 &&
!state->identity.p1g) {
-#ifdef CONFIG_BAND_CBAND
/* in case of CBAND tune reduce first the
lt_gain2 before adjusting the RF gain */
u8 ltg2 = (state->rf_lt_def >> 10) & 0x7;
if (state->current_band == BAND_CBAND && ltg2) {
ltg2 >>= 1;
state->rf_lt_def &= ltg2 << 10; /*
reduce in 3 steps from 7 to 0 */
}
-#endif
} else {
state->agc_step = 0;
*tune_state = CT_AGC_STEP_1;
@@ -1238,16 +1219,6 @@ int dib0090_gain_control(struct dvb_frontend *fe)
adc = (adc * ((s32) 355774) + (((s32) 1) << 20)) >> 21;
/* included in [0:-700] */
adc_error = (s16) (((s32) ADC_TARGET) - adc);
-#ifdef CONFIG_STANDARD_DAB
- if (state->fe->dtv_property_cache.delivery_system ==
STANDARD_DAB)
- adc_error -= 10;
-#endif
-#ifdef CONFIG_STANDARD_DVBT
- if (state->fe->dtv_property_cache.delivery_system ==
STANDARD_DVBT &&
-
(state->fe->dtv_property_cache.modulation == QAM_64 ||
state->fe->dtv_property_cache.modulation == QAM_16))
- adc_error += 60;
-#endif
-#ifdef CONFIG_SYS_ISDBT
if ((state->fe->dtv_property_cache.delivery_system ==
SYS_ISDBT) && (((state->fe->dtv_property_cache.layer[0].segment_count >
0)
&&
@@ -1274,17 +1245,9 @@ int dib0090_gain_control(struct dvb_frontend *fe)
V4L2 control API - choosing base CID for private controls
Hi, I got completely confused while trying to create private controls with control API and when I finally got down to sanity checks in v4l2_ctrl_new() in v4l2-ctrls.c... It would be nice if the following explanation by Hans (archive msg69922) or maybe some more elaborate version could somehow make its way to Documentation/video4linux/v4l2-controls.txt :-) Regards, Krzysztof -- 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/8] [media] au0828: Improve debug messages for urb_completion
Em Thu, 22 May 2014 10:36:24 +0200
Ricardo Ribalda Delgado escreveu:
> Hello Mauro
>
> Are you aware that using dynamic printk you can decide to print
> __func__ on demand?
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/dynamic-debug-howto.txt#n213
Yes, I'm aware.
Yet, but changing the driver to use the dynamic printk's should
be done on a separate patch that would convert all printks to use the
dev_* printk macros.
The goal of this specific patch is just to make the already existing
debug macros more useful, allowing to see when the DMA stuck, like:
[ 248.733896] au0828/0: urb_completion: 0
[ 248.733900] au0828/0: urb_completion: not streaming!
[ 248.733998] au0828/0: urb_completion: 0
[ 248.734005] au0828/0: urb_completion: not streaming!
[ 248.734042] au0828/0: urb_completion: 0
[ 248.734045] au0828/0: urb_completion: not streaming!
[ 248.734097] au0828/0: urb_completion: 1536
[ 248.734101] au0828/0: urb_completion: not streaming!
[ 248.734164] au0828/0: urb_completion: 2048
[ 248.734168] au0828/0: urb_completion: not streaming!
[ 248.734200] au0828/0: urb_completion: 514
[ 248.734204] au0828/0: urb_completion: not streaming!
...
>
>
> Perhaps it is better to not add __func__
>
> Regards!
>
> On Wed, May 21, 2014 at 8:19 PM, Mauro Carvalho Chehab
> wrote:
> > Sometimes, it helps to know how much data was received by
> > urb_completion. Add that information to the optional debug
> > log.
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> > drivers/media/usb/au0828/au0828-dvb.c | 12
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/media/usb/au0828/au0828-dvb.c
> > b/drivers/media/usb/au0828/au0828-dvb.c
> > index 2019e4a168b2..ab5f93643021 100755
> > --- a/drivers/media/usb/au0828/au0828-dvb.c
> > +++ b/drivers/media/usb/au0828/au0828-dvb.c
> > @@ -114,16 +114,20 @@ static void urb_completion(struct urb *purb)
> > int ptype = usb_pipetype(purb->pipe);
> > unsigned char *ptr;
> >
> > - dprintk(2, "%s()\n", __func__);
> > + dprintk(2, "%s: %d\n", __func__, purb->actual_length);
> >
> > - if (!dev)
> > + if (!dev) {
> > + dprintk(2, "%s: no dev!\n", __func__);
> > return;
> > + }
> >
> > - if (dev->urb_streaming == 0)
> > + if (dev->urb_streaming == 0) {
> > + dprintk(2, "%s: not streaming!\n", __func__);
> > return;
> > + }
> >
> > if (ptype != PIPE_BULK) {
> > - printk(KERN_ERR "%s() Unsupported URB type %d\n",
> > + printk(KERN_ERR "%s: Unsupported URB type %d\n",
> >__func__, ptype);
> > return;
> > }
> > --
> > 1.9.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
>
>
>
--
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/8] [media] au0828: Improve debug messages for urb_completion
Hello Mauro
Are you aware that using dynamic printk you can decide to print
__func__ on demand?
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/dynamic-debug-howto.txt#n213
Perhaps it is better to not add __func__
Regards!
On Wed, May 21, 2014 at 8:19 PM, Mauro Carvalho Chehab
wrote:
> Sometimes, it helps to know how much data was received by
> urb_completion. Add that information to the optional debug
> log.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/media/usb/au0828/au0828-dvb.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/usb/au0828/au0828-dvb.c
> b/drivers/media/usb/au0828/au0828-dvb.c
> index 2019e4a168b2..ab5f93643021 100755
> --- a/drivers/media/usb/au0828/au0828-dvb.c
> +++ b/drivers/media/usb/au0828/au0828-dvb.c
> @@ -114,16 +114,20 @@ static void urb_completion(struct urb *purb)
> int ptype = usb_pipetype(purb->pipe);
> unsigned char *ptr;
>
> - dprintk(2, "%s()\n", __func__);
> + dprintk(2, "%s: %d\n", __func__, purb->actual_length);
>
> - if (!dev)
> + if (!dev) {
> + dprintk(2, "%s: no dev!\n", __func__);
> return;
> + }
>
> - if (dev->urb_streaming == 0)
> + if (dev->urb_streaming == 0) {
> + dprintk(2, "%s: not streaming!\n", __func__);
> return;
> + }
>
> if (ptype != PIPE_BULK) {
> - printk(KERN_ERR "%s() Unsupported URB type %d\n",
> + printk(KERN_ERR "%s: Unsupported URB type %d\n",
>__func__, ptype);
> return;
> }
> --
> 1.9.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
--
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
