[PATCH] pwc: Use vb2 queue mutex through a single name
This lock was being taken using two different names (pointers) in the same function. Both names refer to the same lock, so this wasn't an error; but it looked very strange. Cc: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Ezequiel Garcia elezegar...@gmail.com --- drivers/media/video/pwc/pwc-if.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/pwc/pwc-if.c b/drivers/media/video/pwc/pwc-if.c index de7c7ba..b5d0729 100644 --- a/drivers/media/video/pwc/pwc-if.c +++ b/drivers/media/video/pwc/pwc-if.c @@ -1127,7 +1127,7 @@ static void usb_pwc_disconnect(struct usb_interface *intf) v4l2_device_disconnect(pdev-v4l2_dev); video_unregister_device(pdev-vdev); mutex_unlock(pdev-v4l2_lock); - mutex_unlock(pdev-vb_queue.lock); + mutex_unlock(pdev-vb_queue_lock); #ifdef CONFIG_USB_PWC_INPUT_EVDEV if (pdev-button_dev) -- 1.7.8.6 -- 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: Make menuconfig doesn't work anymore
2012/7/12 Martin Herrman martin.herr...@gmail.com: 2012/7/12 VDR User user@gmail.com: No, the drivers I need were already there but I just checked my menuconfig and I see: Multimedia support - Customize TV tuners - NXP TDA18212 silicon tuner Is that what you're looking for? If so, all you need, I think, is DVB for Linux and Customize analog and hybrid tuner modules to build to get the Customize TV tuners option. Thanks for the input, but that's not the driver I need. I need the ddbridge compatible (?) driver, NXP TDA18212 DD [*] DVB/ATSC adapters M Digital Devices bridge support [*] Customse the frontend modules to build Customize DVB Frontends → STV 0367 (DD) NXP TDA18212 silicon tuner (DD) Problem solved: although I cannot select the drivers, they are build during 'make'. Done a make install and reboot and card is detected :-) -- 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] drivers/media/dvb/siano/smscoreapi.c: use list_for_each_entry
From: Julia Lawall julia.law...@lip6.fr
Use list_for_each_entry and perform some other induced simplifications.
The semantic match that finds the opportunity for this reorganization is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@@
struct list_head *pos;
struct list_head *head;
statement S;
@@
*for (pos = (head)-next; pos != (head); pos = pos-next)
S
// /smpl
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
Not tested.
drivers/media/dvb/siano/smscoreapi.c | 39 ++-
1 file changed, 16 insertions(+), 23 deletions(-)
diff --git a/drivers/media/dvb/siano/smscoreapi.c
b/drivers/media/dvb/siano/smscoreapi.c
index 7331e84..9cc5554 100644
--- a/drivers/media/dvb/siano/smscoreapi.c
+++ b/drivers/media/dvb/siano/smscoreapi.c
@@ -276,16 +276,13 @@ static void smscore_notify_clients(struct
smscore_device_t *coredev)
static int smscore_notify_callbacks(struct smscore_device_t *coredev,
struct device *device, int arrival)
{
- struct list_head *next, *first;
+ struct smscore_device_notifyee_t *elem;
int rc = 0;
/* note: must be called under g_deviceslock */
- first = g_smscore_notifyees;
-
- for (next = first-next; next != first; next = next-next) {
- rc = ((struct smscore_device_notifyee_t *) next)-
- hotplug(coredev, device, arrival);
+ list_for_each_entry(elem, g_smscore_notifyees, entry) {
+ rc = elem-hotplug(coredev, device, arrival);
if (rc 0)
break;
}
@@ -940,29 +937,25 @@ static struct
smscore_client_t *smscore_find_client(struct smscore_device_t *coredev,
int data_type, int id)
{
- struct smscore_client_t *client = NULL;
- struct list_head *next, *first;
+ struct list_head *first;
+ struct smscore_client_t *client;
unsigned long flags;
- struct list_head *firstid, *nextid;
-
+ struct list_head *firstid;
+ struct smscore_idlist_t *client_id;
spin_lock_irqsave(coredev-clientslock, flags);
first = coredev-clients;
- for (next = first-next;
-(next != first) !client;
-next = next-next) {
- firstid = ((struct smscore_client_t *)next)-idlist;
- for (nextid = firstid-next;
-nextid != firstid;
-nextid = nextid-next) {
- if struct smscore_idlist_t *)nextid)-id == id)
- (((struct smscore_idlist_t *)nextid)-data_type ==
data_type ||
- (((struct smscore_idlist_t *)nextid)-data_type ==
0))) {
- client = (struct smscore_client_t *) next;
- break;
- }
+ list_for_each_entry(client, first, entry) {
+ firstid = client-idlist;
+ list_for_each_entry(client_id, firstid, entry) {
+ if ((client_id-id == id)
+ (client_id-data_type == data_type ||
+ (client_id-data_type == 0)))
+ goto found;
}
}
+ client = NULL;
+found:
spin_unlock_irqrestore(coredev-clientslock, flags);
return client;
}
--
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: Tips is OOPSing with basic v4l2 controls - Major breakage
On Sun July 15 2012 01:12:02 Steven Toth wrote: Tip is oopsing the moment the V4L2 API is exercised, Eg. v4l2-ctl or tvtime. Its unusable at this point. It's fixed here: https://patchwork.kernel.org/patch/1168931/ We're all waiting for Mauro to return from vacation :-) Regards, Hans Verified with two different drivers (cx23885 and SAA7164), same oops. [ 120.255980] BUG: unable to handle kernel NULL pointer dereference at 0016 [ 120.255992] IP: [c074efd6] v4l2_queryctrl+0x21/0x105 [ 120.256000] *pdpt = 10de8001 *pde = [ 120.256005] Oops: [#1] SMP [ 120.256009] Modules linked in: mt2131 s5h1409 tda8290 tuner cx25840 cx23885 videobuf_dma_sg altera_stapl cx2341x tda18271 videobuf_dvb videobuf_core v4l2_common altera_ci btcx_risc tveeprom fuse nouveau ttm drm_kms_helper drm i2c_algo_bit video nfsd lockd nfs_acl auth_rpcgss exportfs sunrpc ipv6 cpufreq_ondemand acpi_cpufreq mperf uinput pl2303 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd coretemp r8169 iTCO_wdt soundcore i2c_i801 crc32c_intel iTCO_vendor_support snd_page_alloc usbserial i2c_core mii microcode serio_raw pcspkr mxm_wmi floppy wmi [last unloaded: scsi_wait_scan] [ 120.256077] [ 120.256080] Pid: 2659, comm: tvtime Not tainted 3.4.0-rc7+ #2 Gigabyte Technology Co., Ltd. P67A-UD4-B3/P67A-UD4-B3 [ 120.256088] EIP: 0060:[c074efd6] EFLAGS: 00010202 CPU: 0 [ 120.256092] EIP is at v4l2_queryctrl+0x21/0x105 [ 120.256095] EAX: ffea EBX: 0002 ECX: d1565c00 EDX: 00980900 [ 120.256099] ESI: d17d7e58 EDI: e0f8191c EBP: d17d7db8 ESP: d17d7da4 [ 120.256103] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 120.256106] CR0: 80050033 CR2: 0016 CR3: 10de6000 CR4: 000407f0 [ 120.256110] DR0: DR1: DR2: DR3: [ 120.256114] DR6: 0ff0 DR7: 0400 [ 120.256117] Process tvtime (pid: 2659, ti=d17d6000 task=d27dcb60 task.ti=d17d6000) [ 120.256121] Stack: [ 120.256123] 0020 d04d11cc d04e0300 d0da3c00 e0f8191c d17d7dd0 c074b4a3 d17d7e58 [ 120.256134] c0aaaba0 d1565c00 d17d7e2c c074b989 d17d7e58 d04d11cc cfee0840 [ 120.256344] d0da3c00 d04e0300 e0f8191c d17d7e58 00459196 c0aaaba0[ 120.256353] Call Trace: [ 120.256357] [c074b4a3] v4l_queryctrl+0x40/0x5f [ 120.256361] [c074b989] __video_do_ioctl+0x199/0x29c [ 120.256368] [c0445624] ? prepare_signal+0x72/0x169 [ 120.256373] [c0604848] ? _copy_from_user+0x3e/0x52 [ 120.256377] [c074bcdd] video_usercopy+0x251/0x30b [ 120.256381] [c074b7f0] ? v4l2_is_known_ioctl+0x22/0x22 [ 120.256386] [c0445624] ? prepare_signal+0x72/0x169 [ 120.256392] [c04de360] ? handle_pte_fault+0x32f/0x8d0 [ 120.256397] [c0459184] ? need_resched+0x14/0x1e [ 120.256401] [c074bdae] video_ioctl2+0x17/0x19 [ 120.256405] [c074b7f0] ? v4l2_is_known_ioctl+0x22/0x22 [ 120.256411] [c074805d] v4l2_ioctl+0xc1/0xdd [ 120.256415] [c0445624] ? prepare_signal+0x72/0x169 [ 120.256420] [c0747f9c] ? v4l2_open+0xf2/0xf2 [ 120.256425] [c050bbb4] do_vfs_ioctl+0x491/0x4c7 [ 120.256431] [c08470ee] ? do_page_fault+0x2ce/0x32b [ 120.256436] [c045ec09] ? sched_clock_cpu+0x42/0x14d [ 120.256444] [c0476284] ? tick_program_event+0x29/0x2d [ 120.256996] [c04e1c49] ? do_munmap+0x201/0x218 [ 120.257438] [c0445624] ? prepare_signal+0x72/0x169 [ 120.257892] [c050bc32] sys_ioctl+0x48/0x6a [ 120.258351] [c0426c5d] ? smp_apic_timer_interrupt+0x69/0x76 [ 120.258819] [c0849c1f] sysenter_do_call+0x12/0x28 [ 120.259290] [c0445624] ? prepare_signal+0x72/0x169 (gdb) list *(v4l2_queryctrl + 0x21) 0xc074efd6 is in v4l2_queryctrl (drivers/media/video/v4l2-ctrls.c:1917). 1912 struct v4l2_ctrl *ctrl; 1913 1914 if (hdl == NULL) 1915 return -EINVAL; 1916 1917 mutex_lock(hdl-lock); 1918 1919 /* Try to find it */ 1920 ref = find_ref(hdl, id); 1921 (gdb) FYI -- 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: [Regression 3.1-3.2, bisected] UVC-webcam: kernel panic when starting capturing
Hi Frank, Thanks for the report. On Thursday 12 July 2012 21:07:56 Frank Schäfer wrote: Hi, when I start capturing from the UVC-webcam 2232:1005 (WebCam SCB-0385N) of my netbook, I get a kernel panic. You can find a screenshot of the backtrace here: http://imageshack.us/photo/my-images/9/img125km.jpg/ This is a regression which has been introduced between kernel 3.2-rc2 and 3.2-rc3 with the following commit: 3afedb95858bcc117b207a7c0a6767fe891bdfe9 is the first bad commit commit 3afedb95858bcc117b207a7c0a6767fe891bdfe9 Author: Laurent Pinchart laurent.pinch...@ideasonboard.com Date: Thu Nov 3 07:24:34 2011 -0300 [media] uvcvideo: Don't skip erroneous payloads Instead of skipping the payload completely, which would make the resulting image corrupted anyway, store the payload normally and mark the buffer as erroneous. If the no_drop module parameter is set to 1 the buffer will then be passed to userspace, and tt will then be up to the application to decide what to do with the buffer. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com I'm puzzled. Your screenshot shows the uvc_video_stats_decode() function in the stack trace, but that function wasn't present in 3afedb95858bcc117b207a7c0a6767fe891bdfe9. Could you please send me a stack trace corresponding to 3afedb95858bcc117b207a7c0a6767fe891bdfe9 ? Your stack trace looks similar to the problem reported in https://bugzilla.redhat.com/show_bug.cgi?id=836742. 3afedb95858bcc117b207a7c0a6767fe891bdfe9 might have introduced a different bug, possibly fixed in a later commit. -- 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] media: mx2_camera: Remove MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB flags.
Hi Javier, On Thursday 12 July 2012 11:03:29 Javier Martin wrote: These flags are not used any longer and can be safely removed since the following patch: http://www.spinics.net/lists/linux-media/msg50165.html Signed-off-by: Javier Martin javier.mar...@vista-silicon.com I would replace the URL with the commit ID in mainline. Apart from that, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- 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: Tips is OOPSing with basic v4l2 controls - Major breakage
On Sun, Jul 15, 2012 at 6:43 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Sun July 15 2012 01:12:02 Steven Toth wrote: Tip is oopsing the moment the V4L2 API is exercised, Eg. v4l2-ctl or tvtime. Its unusable at this point. It's fixed here: https://patchwork.kernel.org/patch/1168931/ We're all waiting for Mauro to return from vacation :-) Thanks Hans. :) - 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: [PATCH] [media] davinci: vpfe: Add documentation
Hi Manjunath,
Thanks for the patch.
On Wednesday 11 July 2012 21:09:26 Manjunath Hadli wrote:
Add documentation on the Davinci VPFE driver. Document the subdevs,
and private IOTCLs the driver implements
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
---
Documentation/video4linux/davinci-vpfe-mc.txt | 263
+ 1 files changed, 263 insertions(+), 0
deletions(-)
create mode 100644 Documentation/video4linux/davinci-vpfe-mc.txt
diff --git a/Documentation/video4linux/davinci-vpfe-mc.txt
b/Documentation/video4linux/davinci-vpfe-mc.txt new file mode 100644
index 000..968194f
--- /dev/null
+++ b/Documentation/video4linux/davinci-vpfe-mc.txt
@@ -0,0 +1,263 @@
+Davinci Video processing Front End (VPFE) driver
+
+Copyright (C) 2012 Texas Instruments Inc
+
+Contacts: Manjunath Hadli manjunath.ha...@ti.com
+
+Introduction
+
+
+This file documents the Texas Instruments Davinci Video processing Front
End
+(VPFE) driver located under drivers/media/video/davinci. The original
driver
+exists for Davinci VPFE, which is now being changed to Media Controller
+Framework.
+
+Currently the driver has been successfully used on the following version of
Davinci:
+
+ DM365/DM368
Does the driver still support the DM644x ?
+The driver implements V4L2, Media controller and v4l2_subdev interfaces.
+Sensor, lens and flash drivers using the v4l2_subdev interface in the
kernel
+are supported.
+
+
+Split to subdevs
+
+
+The Davinic VPFE is split into V4L2 subdevs, each of the blocks inside the
s/Davinic/Davinci/
VPFE
+having one subdev to represent it. Each of the subdevs provide a V4L2
subdev
+interface to userspace.
+
+ DAVINCI CCDC
+ DAVINCI PREVIEWER
+ DAVINCI RESIZER
the DM36x VPFE documentation doesn't split the hardware in CCDC, PREVIEWER and
RESIZER modules, but in ISIF, IPIPEIF and IPIPE. Why don't you use those names
? It looks like you're introducing an abstraction layer on top of the existing
driver. Why is that needed, why don't you just port the driver to the MC API
instead ?
+ DAVINCI AEW
+ DAVINCI AF
+
+Each possible link in the VPFE is modeled by a link in the Media controller
+interface. For an example program see [1].
+
+
+Private IOCTLs
+==
+
+The Davinci Video processing Front End (VPFE) driver supports standard V4L2
+IOCTLs and controls where possible and practical. Much of the functions
provided
+by the VPFE, however, does not fall under the standard IOCTLs.
+
+In general, there is a private ioctl for configuring each of the blocks
+containing hardware-dependent functions.
+
+The following private IOCTLs are supported:
+
+1: IOCTL: PREV_S_PARAM/PREV_G_PARAM
+Description:
+ Sets/Gets the parameters required by the previewer module
+Parameter:
+ /**
+ * struct prev_module_param- structure to configure preview modules
+ * @version: Version of the preview module
Who is responsible for filling this field, the application or the driver ?
+ * @len: Length of the module config structure
+ * @module_id: Module id
+ * @param: pointer to module config parameter.
What is module_id for ? What does param point to ?
+ */
+ struct prev_module_param {
+ char version[IMP_MAX_NAME_SIZE];
Is there a need to express the version as a string instead of an integer ?
+ unsigned short len;
+ unsigned short module_id;
+ void *param;
+ };
+
+2: IOCTL: PREV_S_CONFIG/PREV_G_CONFIG
+Description:
+ Sets/Gets the configuration required by the previewer channel
+Parameter:
+ /**
+ * struct prev_channel_config - structure for configuring the previewer
channel
+ * @len: Length of the user configuration
+ * @config: pointer to either single shot config or continuous
+ */
+ struct prev_channel_config {
+ unsigned short len;
+ void *config;
+ };
What's the difference between parameters and configuration ? What does config
point to ?
+
+3: IOCTL: PREV_ENUM_CAP
+Description:
+ Queries the modules available in the image processor for preview the
+ input image.
+Parameter:
+ /**
+ * struct prev_cap - structure to enumerate capabilities of previewer
+ * @index: application use this to iterate over the available modules
+ * @version: version of the preview module
+ * @module_id: module id
+ * @control: control operation allowed in continuous mode? 1 - allowed, 0
- not allowed
+ * @path: path on which the module is sitting
+ * @module_name: module name
+ */
+ struct prev_cap {
+ unsigned short index;
+ char version[IMP_MAX_NAME_SIZE];
+ unsigned short module_id;
+ char control;
+ enum imp_data_paths
Re: [3.2-3.3 regression] mceusb: only every second keypress is recognised
Did this issue drop under everybodys radar? :) I am the person that reported that bug in the Debian bugtracker a month ago and I find it hard to believe no-one else can at least confirm that issue. As I have seen a second box with Debian wheezy and kernel 3.4 (needed because of radeon-hdmi-sound) with the *same* issue, but I think a different receiver (can't check that right now but it is a Zotac Zbox mini AD10 built-in IR-receiver). With kernel 3.2 no issue, with 3.4 only every second keypress recognized. Any thoughts about that issue would be greatly appreciated! And are there any other users out there having such kernel-related issues? Maybe some change in the kernel now needs a different kind of setup for lirc? Maybe similar to the switch from lirc drivers to in-kernel lirc / devinput? Just guessing here... regards Michael Am 22.06.2012 06:52, schrieb Ben Hutchings: [Full bug log is athttp://bugs.debian.org/677727.] On Mon, 2012-06-18 at 15:20 +0200, Michael Schmitt wrote: Hi Ben, mschmitt@ganymed:~$ dmesg |head -3 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.3.0-rc6-686-pae (Debian 3.3~rc6-1~experimental.1) (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-1) ) #1 SMP Mon Mar 5 21:21:52 UTC 2012 that is the first kernel I found on snapshot.d.o that does show that issue. The next one backwards is linux-image-3.2.0-2-686-pae (3.2.20-1) and that one works. Is there anything that comes to your mind? No, but this version information should help to track down how the bug was introduced. Michael originally wrote: with the current kernel from experimental only every second keypress is recognized on my ir remote control. Reboot to kernel 3.2 from sid, all back to normal. I have no idea how the kernel could be responsible there... ok, a weird bug in the responsible kernel module for the remote, but somehow I doubt that. The driver in question is mceusb. Ben. -- 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 9/9] soc-camera: Push probe-time power management to drivers
Hi Guennadi,
On Tuesday 10 July 2012 14:06:51 Guennadi Liakhovetski wrote:
On Thu, 5 Jul 2012, Laurent Pinchart wrote:
Several client drivers access the hardware at probe time, for instance
to read the probe chip ID. Such chips need to be powered up when being
probed.
soc-camera handles this by powering chips up in the soc-camera probe
implementation. However, this will break with non soc-camera hosts that
don't perform the same operations.
Fix the problem by pushing the power up/down from the soc-camera core
down to individual drivers on a needs basis.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/imx074.c | 21 --
drivers/media/video/mt9m001.c| 17 +++-
drivers/media/video/mt9m111.c| 80 ++--
drivers/media/video/mt9t031.c| 37 +++--
drivers/media/video/mt9t112.c| 12 +-
drivers/media/video/mt9v022.c|5 ++
drivers/media/video/ov2640.c | 11 -
drivers/media/video/ov5642.c | 21 --
drivers/media/video/ov6650.c | 19 ++---
drivers/media/video/ov772x.c | 14 ++-
drivers/media/video/ov9640.c | 17 ++--
drivers/media/video/ov9740.c | 23 +++
drivers/media/video/rj54n1cb0c.c | 18 ++--
drivers/media/video/soc_camera.c | 20 -
drivers/media/video/tw9910.c | 12 +-
15 files changed, 204 insertions(+), 123 deletions(-)
[snip]
diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c
index 9666e20..4f12177 100644
--- a/drivers/media/video/mt9t031.c
+++ b/drivers/media/video/mt9t031.c
@@ -161,14 +161,6 @@ static int mt9t031_idle(struct i2c_client *client)
return ret = 0 ? 0 : -EIO;
}
-static int mt9t031_disable(struct i2c_client *client)
-{
- /* Disable the chip */
- reg_clear(client, MT9T031_OUTPUT_CONTROL, 2);
-
- return 0;
-}
-
static int mt9t031_s_stream(struct v4l2_subdev *sd, int enable)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
@@ -643,9 +635,15 @@ static int mt9t031_video_probe(struct i2c_client
*client)
s32 data;
int ret;
- /* Enable the chip */
- data = reg_write(client, MT9T031_CHIP_ENABLE, 1);
- dev_dbg(client-dev, write: %d\n, data);
+ ret = mt9t031_s_power(mt9t031-subdev, 1);
+ if (ret 0)
+ return ret;
+
+ ret = mt9t031_idle(client);
+ if (ret 0) {
+ dev_err(client-dev, Failed to initialise the camera\n);
+ return ret;
grm... don't you have to goto done here instead to disable the power
again?
Sorry about that one. Will fix.
+ }
/* Read out the chip version register */
data = reg_read(client, MT9T031_CHIP_VERSION);
@@ -657,16 +655,16 @@ static int mt9t031_video_probe(struct i2c_client
*client)
default:
dev_err(client-dev,
No MT9T031 chip detected, register read %x\n, data);
- return -ENODEV;
+ ret = -ENODEV;
+ goto done;
}
dev_info(client-dev, Detected a MT9T031 chip ID %x\n, data);
- ret = mt9t031_idle(client);
- if (ret 0)
- dev_err(client-dev, Failed to initialise the camera\n);
- else
- v4l2_ctrl_handler_setup(mt9t031-hdl);
+ ret = v4l2_ctrl_handler_setup(mt9t031-hdl);
+
+done:
+ mt9t031_s_power(mt9t031-subdev, 0);
return 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
Re: OMAP4 support
Hi Gary, On Fri, Jul 13, 2012 at 5:24 AM, Gary Thomas g...@mlbassoc.com wrote: On 2012-07-12 20:30, Sergio Aguirre wrote: Hi Gary, On Tue, Jul 10, 2012 at 2:31 PM, Gary Thomas g...@mlbassoc.com wrote: On 2012-07-10 11:05, Chris Lalancette wrote: On Tue, Jul 10, 2012 at 9:41 AM, Gary Thomas g...@mlbassoc.com wrote: I'm looking for video support on OMAP4 platforms. I've found the PandaBoard camera project (http://www.omappedia.org/wiki/PandaBoard_Camera_Support) and this is starting to work. That said, I'm having some issues with setting up the pipeline, etc. Can this list help out? I'm not sure exactly what kind of cameras you want to get working, but if you are looking to get CSI2 cameras going through the ISS, Sergio Aguirre has been working on support. He also works on the media-ctl tool, which is used for configuring the media framework pipeline. The latest versions that I am aware of are here: git://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera.git Yes, this is the tree I've been working with (pointed to by the page I mentioned). My kernel can see the camera OV5650 and set up the pipeline. I am able to grab the raw SGRBG10 data but I'd like to get the ISS to convert this to a more usable UYVY format. Here's what I tried: media-ctl -r media-ctl -l 'OMAP4 ISS CSI2a:1 - OMAP4 ISS ISP IPIPEIF:0 [1]' media-ctl -l 'OMAP4 ISS ISP IPIPEIF:1 - OMAP4 ISS ISP IPIPEIF output:0 [1]' media-ctl -f 'ov5650 3-0036:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP4 ISS CSI2a:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP4 ISS ISP IPIPEIF:0 [SGRBG10 2592x1944]','OMAP4 ISS ISP IPIPEIF:1 [UYVY 2592x1944]' Sadly, I can't get the IPIPEIF element to take SGRGB10 in and put UYVY out (my reading of the manual implies that this _should_ be possible). I always see this pipeline setup: - entity 5: OMAP4 ISS ISP IPIPEIF (3 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Input [SGRBG10 2592x1944] - 'OMAP4 ISS CSI2a':pad1 [ACTIVE] - 'OMAP4 ISS CSI2b':pad1 [] pad1: Output [SGRBG10 2592x1944] - 'OMAP4 ISS ISP IPIPEIF output':pad0 [ACTIVE] pad2: Output [SGRBG10 2592x1944] - 'OMAP4 ISS ISP resizer':pad0 [] Am I missing something? How can I make this conversion in the ISS? The core problem is that, i haven't published any support for RAW10-YUV conversion, which is part of the IPIPE module (not the IPIPEIF, like you mention). I had some patches, but sadly it is unfinished work. :/ Now, there's a main non-technical problem... I no longer work at TI since end of June this year, and I don't have the right HW setup available anymore. Those sensors were company's asset, and I couldn't keep any. Now, we can make this work with cooperation of someone who has the right setup, and me sharing my patches and some advice on my experience. What do you think? Note: if this is not the appropriate place to ask these questions, please redirect me (hopefully to a useful list :-) As I'm the main person who has been actively developing this, I'm your guy to ask questions :). By the way, this development has been my initiative the whole time, and not an official TI objective, so, to be honest, asking TI for official support won't help much right now. Tell me how I can help make this happen. I'll be glad to apply patches, figure out bugs, etc, I just need a little help with getting started. I have access to the hardware and it's really important that I make some progress on this soon. Can you share your RAW10-YUV patches and some guidance on how to proceed? Sure. I just pushed an internal branch I had, named: devel-ISPSUPPORT-IPIPE, please take that as a base. And please try these commands: media-ctl -r -l 'OMAP4 ISS CSI2a:1 - OMAP4 ISS ISP IPIPEIF:0 [1]','OMAP4 ISS ISP IPIPEIF:2 - OMAP4 ISS ISP IPIPE:0 [1]','OMAP4 ISS ISP IPIPE:1 - OMAP4 ISS ISP resizer:0 [1]','OMAP4 ISS ISP resizer:1 - OMAP4 ISS ISP resizer a output:0 [1]' media-ctl -f 'ov5650 3-0036:0 [SGRBG10 2592x1944]','OMAP4 ISS CSI2a:0 [SGRBG10 2592x1944]','OMAP4 ISS ISP IPIPEIF:0 [SGRBG10 2592x1944]','OMAP4 ISS ISP IPIPE:0 [SGRBG10 2592x1944]','OMAP4 ISS ISP resizer:0 [UYVY 2592x1944]' yavta /dev/video3 -c4 -n1 -s2592x1944 -fUYVY -Fov5650_2592x1944_UYVY_8bpp.yuv I have been able to capture RAW10 data, but often the whole thing just sits there (hangs). Restarting the process sometimes works, sometimes not. Looking at the registers and the actual signals on a scope do not show any difference that we can find. Any ideas what might cause this? Have you seen it as well? Can you please try again with the before mentioned branch? The branch you were using didn't have some changes, so maybe this new one would take care of that. Thanks for the help - Please let me know how I can get this working... Well,
[PATCH] Minor cleanups for MCE USB.
Signed-off-by: Sean Young s...@mess.org
---
drivers/media/rc/mceusb.c | 13 +
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index e150a2e..1af0b0c 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -410,14 +410,12 @@ struct mceusb_dev {
/* usb */
struct usb_device *usbdev;
struct urb *urb_in;
- struct usb_endpoint_descriptor *usb_ep_in;
struct usb_endpoint_descriptor *usb_ep_out;
/* buffers and dma */
unsigned char *buf_in;
unsigned int len_in;
dma_addr_t dma_in;
- dma_addr_t dma_out;
enum {
CMD_HEADER = 0,
@@ -687,7 +685,7 @@ static void mceusb_dev_printdata(struct mceusb_dev *ir,
char *buf,
dev_info(dev, Raw IR data, %d pulse/space samples\n, ir-rem);
}
-static void mce_async_callback(struct urb *urb, struct pt_regs *regs)
+static void mce_async_callback(struct urb *urb)
{
struct mceusb_dev *ir;
int len;
@@ -734,7 +732,7 @@ static void mce_request_packet(struct mceusb_dev *ir,
unsigned char *data,
pipe = usb_sndintpipe(ir-usbdev,
ir-usb_ep_out-bEndpointAddress);
usb_fill_int_urb(async_urb, ir-usbdev, pipe,
- async_buf, size, (usb_complete_t)mce_async_callback,
+ async_buf, size, mce_async_callback,
ir, ir-usb_ep_out-bInterval);
memcpy(async_buf, data, size);
@@ -1032,7 +1030,7 @@ static void mceusb_process_ir_data(struct mceusb_dev *ir,
int buf_len)
ir_raw_event_handle(ir-rc);
}
-static void mceusb_dev_recv(struct urb *urb, struct pt_regs *regs)
+static void mceusb_dev_recv(struct urb *urb)
{
struct mceusb_dev *ir;
int buf_len;
@@ -1332,7 +1330,6 @@ static int __devinit mceusb_dev_probe(struct
usb_interface *intf,
ir-model = model;
/* Saving usb interface data for use by the transmitter routine */
- ir-usb_ep_in = ep_in;
ir-usb_ep_out = ep_out;
if (dev-descriptor.iManufacturer
@@ -1350,8 +1347,8 @@ static int __devinit mceusb_dev_probe(struct
usb_interface *intf,
goto rc_dev_fail;
/* wire up inbound data handler */
- usb_fill_int_urb(ir-urb_in, dev, pipe, ir-buf_in,
- maxp, (usb_complete_t) mceusb_dev_recv, ir, ep_in-bInterval);
+ usb_fill_int_urb(ir-urb_in, dev, pipe, ir-buf_in, maxp,
+ mceusb_dev_recv, ir, ep_in-bInterval);
ir-urb_in-transfer_dma = ir-dma_in;
ir-urb_in-transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
--
1.7.2.5
--
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] Add support for the IguanaWorks USB IR Transceiver.
Signed-off-by: Sean Young s...@mess.org
---
drivers/media/rc/Kconfig| 11 +
drivers/media/rc/Makefile |1 +
drivers/media/rc/iguanair.c | 639 +++
3 files changed, 651 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/rc/iguanair.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index a3fbb21..3b1d4e2 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -253,6 +253,17 @@ config IR_WINBOND_CIR
To compile this driver as a module, choose M here: the module will
be called winbond_cir.
+config IR_IGUANA
+ tristate IguanaWorks USB IR Transceiver
+ depends on RC_CORE
+ select USB
+ ---help---
+ Say Y here if you want to use the IgaunaWorks USB IR Transceiver.
+ Both infrared receive and send are supported.
+
+ To compile this driver as a module, choose M here: the module will
+ be called iguanair.
+
config RC_LOOPBACK
tristate Remote Control Loopback Driver
depends on RC_CORE
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 29f364f..f871d19 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -27,3 +27,4 @@ obj-$(CONFIG_IR_STREAMZAP) += streamzap.o
obj-$(CONFIG_IR_WINBOND_CIR) += winbond-cir.o
obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
obj-$(CONFIG_IR_GPIO_CIR) += gpio-ir-recv.o
+obj-$(CONFIG_IR_IGUANA) += iguanair.o
diff --git a/drivers/media/rc/iguanair.c b/drivers/media/rc/iguanair.c
new file mode 100644
index 000..5e2eaf8
--- /dev/null
+++ b/drivers/media/rc/iguanair.c
@@ -0,0 +1,639 @@
+/*
+ * IguanaWorks USB IR Transceiver support
+ *
+ * Copyright (C) 2012 Sean Young s...@mess.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/device.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/usb.h
+#include linux/usb/input.h
+#include linux/slab.h
+#include linux/completion.h
+#include media/rc-core.h
+
+#define DRIVER_NAME iguanair
+
+struct iguanair {
+ struct rc_dev *rc;
+
+ struct device *dev;
+ struct usb_device *udev;
+
+ int pipe_in, pipe_out;
+ uint8_t bufsize;
+ uint8_t version[2];
+
+ struct mutex lock;
+
+ /* receiver support */
+ bool receiver_on;
+ dma_addr_t dma_in;
+ uint8_t *buf_in;
+ struct urb *urb_in;
+ struct completion completion;
+
+ /* transmit support */
+ bool tx_overflow;
+ uint32_t carrier;
+ uint8_t cycle_overhead;
+ uint8_t channels;
+ uint8_t busy4;
+ uint8_t busy7;
+
+ char name[64];
+ char phys[64];
+};
+
+#define CMD_GET_VERSION0x01
+#define CMD_GET_BUFSIZE0x11
+#define CMD_GET_FEATURES 0x10
+#define CMD_SEND 0x15
+#define CMD_EXECUTE0x1f
+#define CMD_RX_OVERFLOW0x31
+#define CMD_TX_OVERFLOW0x32
+#define CMD_RECEIVER_ON0x12
+#define CMD_RECEIVER_OFF 0x14
+
+#define DIR_IN 0xdc
+#define DIR_OUT0xcd
+
+#define MAX_PACKET_SIZE8u
+#define TIMEOUT1000
+
+struct packet {
+ uint16_t start;
+ uint8_t direction;
+ uint8_t cmd;
+};
+
+struct response_packet {
+ struct packet header;
+ uint8_t data[4];
+};
+
+struct send_packet {
+ struct packet header;
+ uint8_t length;
+ uint8_t channels;
+ uint8_t busy7;
+ uint8_t busy4;
+ uint8_t payload[0];
+};
+
+static void process_ir_data(struct iguanair *ir, unsigned len)
+{
+ if (len = 4 ir-buf_in[0] == 0 ir-buf_in[1] == 0) {
+ switch (ir-buf_in[3]) {
+ case CMD_TX_OVERFLOW:
+ ir-tx_overflow = true;
+ case CMD_RECEIVER_OFF:
+ case CMD_RECEIVER_ON:
+ case CMD_SEND:
+ complete(ir-completion);
+ break;
+ case CMD_RX_OVERFLOW:
+ dev_warn(ir-dev, receive overflow\n);
+ break;
+ default:
+ dev_warn(ir-dev, control code %02x received\n,
+
[PATCH] rtl2832.c: minor cleanup
The current formulation of the bw_params loop uses the counter j as an index
for the first dimension of the
bw_params array which is later incremented by the variable i.
It is evaluated correctly only, because j is initialized to 0 at the beginning
of the loop.
I think that explicitly using the index 0 better reflects the intent of the
expression.
Signed-off-by: Hans-Frieder Vogt hfv...@gmx.net
rtl2832.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/media/dvb/frontends/rtl2832.c 2012-07-06 05:45:16.0
+0200
+++ b/drivers/media/dvb/frontends/rtl2832.c 2012-07-15 19:05:28.428017449
+0200
@@ -589,7 +589,7 @@ static int rtl2832_set_frontend(struct d
return -EINVAL;
}
- for (j = 0; j sizeof(bw_params[j]); j++) {
+ for (j = 0; j sizeof(bw_params[0]); j++) {
ret = rtl2832_wr_regs(priv, 0x1c+j, 1, bw_params[i][j], 1);
if (ret)
goto err;
Hans-Frieder Vogt e-mail: hfvogt at gmx .dot. net
--
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:Sun Jul 15 19:00:23 CEST 2012 git hash:931efdf58bd83af8d0578a6cc53421675daf6d41 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Regression 3.1-3.2, bisected] UVC-webcam: kernel panic when starting capturing
Am 15.07.2012 14:07, schrieb Laurent Pinchart: Hi Frank, Thanks for the report. On Thursday 12 July 2012 21:07:56 Frank Schäfer wrote: Hi, when I start capturing from the UVC-webcam 2232:1005 (WebCam SCB-0385N) of my netbook, I get a kernel panic. You can find a screenshot of the backtrace here: http://imageshack.us/photo/my-images/9/img125km.jpg/ This is a regression which has been introduced between kernel 3.2-rc2 and 3.2-rc3 with the following commit: 3afedb95858bcc117b207a7c0a6767fe891bdfe9 is the first bad commit commit 3afedb95858bcc117b207a7c0a6767fe891bdfe9 Author: Laurent Pinchart laurent.pinch...@ideasonboard.com Date: Thu Nov 3 07:24:34 2011 -0300 [media] uvcvideo: Don't skip erroneous payloads Instead of skipping the payload completely, which would make the resulting image corrupted anyway, store the payload normally and mark the buffer as erroneous. If the no_drop module parameter is set to 1 the buffer will then be passed to userspace, and tt will then be up to the application to decide what to do with the buffer. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com I'm puzzled. Your screenshot shows the uvc_video_stats_decode() function in the stack trace, but that function wasn't present in 3afedb95858bcc117b207a7c0a6767fe891bdfe9. Could you please send me a stack trace corresponding to 3afedb95858bcc117b207a7c0a6767fe891bdfe9 ? Your stack trace looks similar to the problem reported in https://bugzilla.redhat.com/show_bug.cgi?id=836742. 3afedb95858bcc117b207a7c0a6767fe891bdfe9 might have introduced a different bug, possibly fixed in a later commit. Hmm... you're right. The screenshot I've sent to you was made during the bisection process at a commit somewhere between 3.2-rc7 and 3.2-rc8. It seems that this one is slightly different from the others. This one is made at commit 3afedb95858bcc117b207a7c0a6767fe891bdfe9 (the first bad commit): http://imageshack.us/photo/my-images/811/img130hv.jpg and this one is made at 3.5.rc6+: http://imageshack.us/photo/my-images/440/img127u.jpg Regards, Frank Schäfer -- 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: OMAP4 support
On 2012-07-15 08:31, Sergio Aguirre wrote: Hi Gary, On Fri, Jul 13, 2012 at 5:24 AM, Gary Thomas g...@mlbassoc.com wrote: On 2012-07-12 20:30, Sergio Aguirre wrote: Hi Gary, On Tue, Jul 10, 2012 at 2:31 PM, Gary Thomas g...@mlbassoc.com wrote: On 2012-07-10 11:05, Chris Lalancette wrote: On Tue, Jul 10, 2012 at 9:41 AM, Gary Thomas g...@mlbassoc.com wrote: I'm looking for video support on OMAP4 platforms. I've found the PandaBoard camera project (http://www.omappedia.org/wiki/PandaBoard_Camera_Support) and this is starting to work. That said, I'm having some issues with setting up the pipeline, etc. Can this list help out? I'm not sure exactly what kind of cameras you want to get working, but if you are looking to get CSI2 cameras going through the ISS, Sergio Aguirre has been working on support. He also works on the media-ctl tool, which is used for configuring the media framework pipeline. The latest versions that I am aware of are here: git://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera.git Yes, this is the tree I've been working with (pointed to by the page I mentioned). My kernel can see the camera OV5650 and set up the pipeline. I am able to grab the raw SGRBG10 data but I'd like to get the ISS to convert this to a more usable UYVY format. Here's what I tried: media-ctl -r media-ctl -l 'OMAP4 ISS CSI2a:1 - OMAP4 ISS ISP IPIPEIF:0 [1]' media-ctl -l 'OMAP4 ISS ISP IPIPEIF:1 - OMAP4 ISS ISP IPIPEIF output:0 [1]' media-ctl -f 'ov5650 3-0036:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP4 ISS CSI2a:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP4 ISS ISP IPIPEIF:0 [SGRBG10 2592x1944]','OMAP4 ISS ISP IPIPEIF:1 [UYVY 2592x1944]' Sadly, I can't get the IPIPEIF element to take SGRGB10 in and put UYVY out (my reading of the manual implies that this _should_ be possible). I always see this pipeline setup: - entity 5: OMAP4 ISS ISP IPIPEIF (3 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Input [SGRBG10 2592x1944] - 'OMAP4 ISS CSI2a':pad1 [ACTIVE] - 'OMAP4 ISS CSI2b':pad1 [] pad1: Output [SGRBG10 2592x1944] - 'OMAP4 ISS ISP IPIPEIF output':pad0 [ACTIVE] pad2: Output [SGRBG10 2592x1944] - 'OMAP4 ISS ISP resizer':pad0 [] Am I missing something? How can I make this conversion in the ISS? The core problem is that, i haven't published any support for RAW10-YUV conversion, which is part of the IPIPE module (not the IPIPEIF, like you mention). I had some patches, but sadly it is unfinished work. :/ Now, there's a main non-technical problem... I no longer work at TI since end of June this year, and I don't have the right HW setup available anymore. Those sensors were company's asset, and I couldn't keep any. Now, we can make this work with cooperation of someone who has the right setup, and me sharing my patches and some advice on my experience. What do you think? Note: if this is not the appropriate place to ask these questions, please redirect me (hopefully to a useful list :-) As I'm the main person who has been actively developing this, I'm your guy to ask questions :). By the way, this development has been my initiative the whole time, and not an official TI objective, so, to be honest, asking TI for official support won't help much right now. Tell me how I can help make this happen. I'll be glad to apply patches, figure out bugs, etc, I just need a little help with getting started. I have access to the hardware and it's really important that I make some progress on this soon. Can you share your RAW10-YUV patches and some guidance on how to proceed? Sure. I just pushed an internal branch I had, named: devel-ISPSUPPORT-IPIPE, please take that as a base. And please try these commands: media-ctl -r -l 'OMAP4 ISS CSI2a:1 - OMAP4 ISS ISP IPIPEIF:0 [1]','OMAP4 ISS ISP IPIPEIF:2 - OMAP4 ISS ISP IPIPE:0 [1]','OMAP4 ISS ISP IPIPE:1 - OMAP4 ISS ISP resizer:0 [1]','OMAP4 ISS ISP resizer:1 - OMAP4 ISS ISP resizer a output:0 [1]' media-ctl -f 'ov5650 3-0036:0 [SGRBG10 2592x1944]','OMAP4 ISS CSI2a:0 [SGRBG10 2592x1944]','OMAP4 ISS ISP IPIPEIF:0 [SGRBG10 2592x1944]','OMAP4 ISS ISP IPIPE:0 [SGRBG10 2592x1944]','OMAP4 ISS ISP resizer:0 [UYVY 2592x1944]' yavta /dev/video3 -c4 -n1 -s2592x1944 -fUYVY -Fov5650_2592x1944_UYVY_8bpp.yuv With the new branch, I am able to set up the pipeline for UYVY. That part's good. However, just like before, with either RAW10 or UYVY, the grab process does not start more times than it does (it only starts about 1 out of 10 tries). If I just ^C and try again, it may start, it may not. The single time I was able to get the UYVY capture to work, I got an error after the first frame: # grab-uyvy Device /dev/video3 opened. Device `OMAP4 ISS ISP resizer a output' on `media' is a video capture device. Video format set: UYVY (59565955) 2592x1944 buffer size
[PATCH resend] via-camera: pass correct format settings to sensor
The code attempts to maintain a user format and a sensor format, but in this case it looks like a typo is passing the user format down to the sensor. This was preventing display of video at anything other than 640x480. Signed-off-by: Daniel Drake d...@laptop.org --- drivers/media/video/via-camera.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/video/via-camera.c b/drivers/media/video/via-camera.c index 308e150..eb404c2 100644 --- a/drivers/media/video/via-camera.c +++ b/drivers/media/video/via-camera.c @@ -963,7 +963,7 @@ static int viacam_do_try_fmt(struct via_camera *cam, upix-pixelformat = f-pixelformat; viacam_fmt_pre(upix, spix); - v4l2_fill_mbus_format(mbus_fmt, upix, f-mbus_code); + v4l2_fill_mbus_format(mbus_fmt, spix, f-mbus_code); ret = sensor_call(cam, video, try_mbus_fmt, mbus_fmt); v4l2_fill_pix_format(spix, mbus_fmt); viacam_fmt_post(upix, spix); -- 1.7.10.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 v2 7/9] soc-camera: Continue the power off sequence if one of the steps fails
Hi Laurent,
Few comments below.
On 07/05/2012 11:38 PM, Laurent Pinchart wrote:
Powering off a device is a best effort task: failure to execute one of
the steps should not prevent the next steps to be executed. For
instance, an I2C communication error when putting the chip in stand-by
mode should not prevent the more agressive next step of turning the
chip's power supply off.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/soc_camera.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 55b981f..bbd518f 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -89,18 +89,15 @@ static int soc_camera_power_off(struct soc_camera_device
*icd,
struct soc_camera_link *icl)
{
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
- int ret = v4l2_subdev_call(sd, core, s_power, 0);
+ int ret;
- if (ret 0 ret != -ENOIOCTLCMD ret != -ENODEV)
- return ret;
+ v4l2_subdev_call(sd, core, s_power, 0);
Fair enough. I agree we should not prevent power off because of failure
in this step. But IMO we should not silently bypass it too. How about
an error message?
if (icl-power) {
ret = icl-power(icd-control, 0);
- if (ret 0) {
+ if (ret 0)
dev_err(icd-pdev,
Platform failed to power-off the camera.\n);
- return ret;
- }
}
ret = regulator_bulk_disable(icl-num_regulators,
One more comment. Should this function's return value being based fully
on last action? If any earlier error happened but this last step is
fine, IMO we should not return 0.
Kind regards,
David Cohen
--
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 8/9] soc-camera: Add and use soc_camera_power_[on|off]() helper functions
Hi Laurent,
Few more comments below :)
On 07/05/2012 11:38 PM, Laurent Pinchart wrote:
Instead of forcing all soc-camera drivers to go through the mid-layer to
handle power management, create soc_camera_power_[on|off]() functions
that can be called from the subdev .s_power() operation to manage
regulators and platform-specific power handling. This allows non
soc-camera hosts to use soc-camera-aware clients.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/imx074.c |9 +++
drivers/media/video/mt9m001.c |9 +++
drivers/media/video/mt9m111.c | 52 +-
drivers/media/video/mt9t031.c | 11 +++-
drivers/media/video/mt9t112.c |9 +++
drivers/media/video/mt9v022.c |9 +++
drivers/media/video/ov2640.c |9 +++
drivers/media/video/ov5642.c | 10 +++-
drivers/media/video/ov6650.c |9 +++
drivers/media/video/ov772x.c |9 +++
drivers/media/video/ov9640.c | 10 +++-
drivers/media/video/ov9740.c | 15 +-
drivers/media/video/rj54n1cb0c.c |9 +++
drivers/media/video/soc_camera.c | 83 +
drivers/media/video/soc_camera_platform.c | 11 -
drivers/media/video/tw9910.c |9 +++
include/media/soc_camera.h| 10
17 files changed, 225 insertions(+), 58 deletions(-)
[snip]
diff --git a/drivers/media/video/ov9740.c b/drivers/media/video/ov9740.c
index 3eb07c2..effd0f1 100644
--- a/drivers/media/video/ov9740.c
+++ b/drivers/media/video/ov9740.c
@@ -786,16 +786,29 @@ static int ov9740_g_chip_ident(struct v4l2_subdev *sd,
static int ov9740_s_power(struct v4l2_subdev *sd, int on)
{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
struct ov9740_priv *priv = to_ov9740(sd);
+ int ret;
- if (!priv-current_enable)
+ if (on) {
+ ret = soc_camera_power_on(client-dev, icl);
+ if (ret 0)
+ return ret;
+ }
+
+ if (!priv-current_enable) {
+ if (!on)
+ soc_camera_power_off(client-dev, icl);
After your changes, this function has 3 if's (one nested) where all of
them checks on variable due to you need to mix on and
priv-current_enable checks. However, code's traceability is not so
trivial.
How about if you nest priv-current_enable into last if and keep
only that one?
See an incomplete code below:
return 0;
+ }
if (on) {
soc_camera_power_on();
if (!priv-current_enable)
return;
ov9740_s_fmt(sd, priv-current_mf);
ov9740_s_stream(sd, priv-current_enable);
} else {
ov9740_s_stream(sd, 0);
Execute ov9740_s_stream() conditionally:
if (priv-current_enable) {
ov9740_s_stream();
priv-current_enable = true;
}
+ soc_camera_power_off(client-dev, icl);
priv-current_enable = true;
priv-current_enable is set to false when ov9740_s_stream(0) is called
then this function sets it back to true afterwards. So, in case you want
to have no functional change, it seems to me you should call
soc_camera_power_off() after that variable has its original value set
back.
In this case, even if you don't like my suggestion, you still need to
swap those 2 lines above. :)
Br,
David Cohen
}
diff --git a/drivers/media/video/rj54n1cb0c.c b/drivers/media/video/rj54n1cb0c.c
index f6419b2..ca1cee7 100644
--- a/drivers/media/video/rj54n1cb0c.c
+++ b/drivers/media/video/rj54n1cb0c.c
@@ -1180,6 +1180,14 @@ static int rj54n1_s_register(struct v4l2_subdev *sd,
}
#endif
+static int rj54n1_s_power(struct v4l2_subdev *sd, int on)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
+
+ return soc_camera_set_power(client-dev, icl, on);
+}
+
static int rj54n1_s_ctrl(struct v4l2_ctrl *ctrl)
{
struct rj54n1 *rj54n1 = container_of(ctrl-handler, struct rj54n1, hdl);
@@ -1230,6 +1238,7 @@ static struct v4l2_subdev_core_ops rj54n1_subdev_core_ops
= {
.g_register = rj54n1_g_register,
.s_register = rj54n1_s_register,
#endif
+ .s_power= rj54n1_s_power,
};
static int rj54n1_g_mbus_config(struct v4l2_subdev *sd,
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index bbd518f..576146e 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -50,63 +50,72 @@ static LIST_HEAD(hosts);
static LIST_HEAD(devices);
static DEFINE_MUTEX(list_lock); /* Protects the list of hosts */
-static int soc_camera_power_on(struct soc_camera_device *icd,
-
Re: [Regression 3.1-3.2, bisected] UVC-webcam: kernel panic when starting capturing
Hi Frank, On Sunday 15 July 2012 21:39:47 Frank Schäfer wrote: Am 15.07.2012 14:07, schrieb Laurent Pinchart: On Thursday 12 July 2012 21:07:56 Frank Schäfer wrote: Hi, when I start capturing from the UVC-webcam 2232:1005 (WebCam SCB-0385N) of my netbook, I get a kernel panic. You can find a screenshot of the backtrace here: http://imageshack.us/photo/my-images/9/img125km.jpg/ This is a regression which has been introduced between kernel 3.2-rc2 and 3.2-rc3 with the following commit: 3afedb95858bcc117b207a7c0a6767fe891bdfe9 is the first bad commit commit 3afedb95858bcc117b207a7c0a6767fe891bdfe9 Author: Laurent Pinchart laurent.pinch...@ideasonboard.com Date: Thu Nov 3 07:24:34 2011 -0300 [media] uvcvideo: Don't skip erroneous payloads Instead of skipping the payload completely, which would make the resulting image corrupted anyway, store the payload normally and mark the buffer as erroneous. If the no_drop module parameter is set to 1 the buffer will then be passed to userspace, and tt will then be up to the application to decide what to do with the buffer. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com I'm puzzled. Your screenshot shows the uvc_video_stats_decode() function in the stack trace, but that function wasn't present in 3afedb95858bcc117b207a7c0a6767fe891bdfe9. Could you please send me a stack trace corresponding to 3afedb95858bcc117b207a7c0a6767fe891bdfe9 ? Your stack trace looks similar to the problem reported in https://bugzilla.redhat.com/show_bug.cgi?id=836742. 3afedb95858bcc117b207a7c0a6767fe891bdfe9 might have introduced a different bug, possibly fixed in a later commit. Hmm... you're right. The screenshot I've sent to you was made during the bisection process at a commit somewhere between 3.2-rc7 and 3.2-rc8. It seems that this one is slightly different from the others. This one is made at commit 3afedb95858bcc117b207a7c0a6767fe891bdfe9 (the first bad commit): http://imageshack.us/photo/my-images/811/img130hv.jpg and this one is made at 3.5.rc6+: http://imageshack.us/photo/my-images/440/img127u.jpg Thank you. Could you please try the patch I've attached to https://bugzilla.redhat.com/show_bug.cgi?id=836742 ? -- 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
