Re: [PATCH 1/2] Compatibility layer for hrtimer API
On Fri, 3 Jul 2009, Jean Delvare wrote:
Kernels 2.6.22 to 2.6.24 (inclusive) need some compatibility quirks
for the hrtimer API. For older kernels, some required functions were
not exported so there's nothing we can do. This means that drivers
using the hrtimer infrastructure will no longer work for kernels older
than 2.6.22.
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
v4l/compat.h | 18 ++
1 file changed, 18 insertions(+)
--- a/v4l/compat.h
+++ b/v4l/compat.h
@@ -480,4 +480,22 @@ static inline unsigned long v4l_compat_f
}
#endif
+/*
+ * Compatibility code for hrtimer API
+ * This will make hrtimer usable for kernels 2.6.22 and later.
+ * For earlier kernels, not all required functions are exported
+ * so there's nothing we can do.
+ */
+
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 25) \
+ LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 22)
+#include linux/hrtimer.h
Instead of including hrtimer.h from compat.h it's better if you check if it
has already been included and only enable the compat code in that case.
That way hrtimer doesn't get included for files that don't need it and
might define something that conflicts with something from hrtimer. And it
prevents someone from forgetting to include hrtimer when they needed it,
but having the error masked because compat.h is doing it for them.
+/* Forward a hrtimer so it expires after the hrtimer's current now */
+static inline unsigned long hrtimer_forward_now(struct hrtimer *timer,
+ ktime_t interval)
+{
+ return hrtimer_forward(timer, timer-base-get_time(), interval);
+}
+#endif
+
#endif /* _COMPAT_H */
--
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/2] Compatibility layer for hrtimer API
Hi Trent,
On Sun, 5 Jul 2009 01:13:14 -0700 (PDT), Trent Piepho wrote:
On Fri, 3 Jul 2009, Jean Delvare wrote:
Kernels 2.6.22 to 2.6.24 (inclusive) need some compatibility quirks
for the hrtimer API. For older kernels, some required functions were
not exported so there's nothing we can do. This means that drivers
using the hrtimer infrastructure will no longer work for kernels older
than 2.6.22.
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
v4l/compat.h | 18 ++
1 file changed, 18 insertions(+)
--- a/v4l/compat.h
+++ b/v4l/compat.h
@@ -480,4 +480,22 @@ static inline unsigned long v4l_compat_f
}
#endif
+/*
+ * Compatibility code for hrtimer API
+ * This will make hrtimer usable for kernels 2.6.22 and later.
+ * For earlier kernels, not all required functions are exported
+ * so there's nothing we can do.
+ */
+
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 25) \
+ LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 22)
+#include linux/hrtimer.h
Instead of including hrtimer.h from compat.h it's better if you check if it
has already been included and only enable the compat code in that case.
That way hrtimer doesn't get included for files that don't need it and
might define something that conflicts with something from hrtimer. And it
prevents someone from forgetting to include hrtimer when they needed it,
but having the error masked because compat.h is doing it for them.
I see. But this will only work if compat.h is included after all
headers. If it always the case? I see for example that cx88-input
includes media/ir-common.h after compat.h.
+/* Forward a hrtimer so it expires after the hrtimer's current now */
+static inline unsigned long hrtimer_forward_now(struct hrtimer *timer,
+ ktime_t interval)
+{
+ return hrtimer_forward(timer, timer-base-get_time(), interval);
+}
+#endif
+
#endif /* _COMPAT_H */
--
Jean Delvare
--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-dm646x
Em Fri, 26 Jun 2009 21:01:50 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-dm646x for the following: - ARM: DaVinci: DM646x Video: VPIF driver - ARM: DaVinci: DM646x Video: Add VPIF display driver - ARM: DaVinci: DM646x Video: Makefile and config files modifications for Display - ARM: DaVinci: DM646x Video: Fix compile time warnings for mutex locking Note that these four patches depend on the attached platform patch that should be applied to the git tree first. If possible, it would be great if this (like the vpfe capture driver) can be merged for 2.6.31. One note about your changesets: Please, don't use both Reviewed-by and Signed-off-by. The first tag is meant for patches that you reviewed, but you are not part of the submission chain, while the second one means that you reviewed and you're submitting to a maintainer. I'm fixing this at the -git patches. Cheers, Mauro -- 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: [PULL] http://linuxtv.org/hg/~pinchartl/uvcvideo/
Em Fri, 3 Jul 2009 17:37:35 +0200 Laurent Pinchart laurent.pinch...@skynet.be escreveu: Mauro, Please pull from http://linuxtv.org/hg/~pinchartl/uvcvideo/ for the following 5 changesets: uvcvideo: Use class-specific descriptor types from usb/ch9.h uvcvideo: Prefix all UVC constants with UVC_ uvcvideo: Remove unused Logitech-specific constants uvcvideo: Move UVC definitions to linux/usb/video.h uvcvideo: Set PROBE_MINMAX quirk for Aveo Technology webcams b/linux/include/linux/usb/video.h | 164 linux/drivers/media/video/uvc/uvc_ctrl.c | 205 --- linux/drivers/media/video/uvc/uvc_driver.c | 139 +- linux/drivers/media/video/uvc/uvc_v4l2.c | 14 - linux/drivers/media/video/uvc/uvc_video.c | 30 +- linux/drivers/media/video/uvc/uvcvideo.h | 374 - 6 files changed, 474 insertions(+), 452 deletions(-) The fourth patch (Move UVC definitions to linux/usb/video.h) has been submitted to the linux-usb mailing list and acked by Greh KH. Ok. I'm adding it on my linux-next tree. Cheers, Mauro -- 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] em28xx: Add support for Gadmei UTV330+
em28xx: Add support for Gadmei UTV330+
Signed-off-by: Zhenyu Wang zhe...@gmail.com
---
This had been sent to mcentral.de long time ago, but I'm sad to notice
this hasn't been in mainline till now, when I'm trying to view TV in summer
again. I don't know what's the problem with origin em28xx tree, but I do
hope this can be mainline asap. Thanks.
diff -r 05e6c5c9bcb4 -r 647f4c1e5283
linux/drivers/media/video/em28xx/em28xx-cards.c
--- a/linux/drivers/media/video/em28xx/em28xx-cards.c Tue Jun 23 21:11:47
2009 -0300
+++ b/linux/drivers/media/video/em28xx/em28xx-cards.c Sun Jul 05 21:28:02
2009 +0800
@@ -1672,6 +1672,8 @@
.driver_info = EM2861_BOARD_PLEXTOR_PX_TV100U },
{ USB_DEVICE(0x04bb, 0x0515),
.driver_info = EM2820_BOARD_IODATA_GVMVP_SZ },
+ { USB_DEVICE(0xeb1a, 0x50a6),
+ .driver_info = EM2860_BOARD_GADMEI_UTV330 },
{ },
};
MODULE_DEVICE_TABLE(usb, em28xx_id_table);
--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-dm646x
On Sun, Jul 05, 2009 at 09:51:55AM -0300, Mauro Carvalho Chehab wrote:
Hmm... I'm not seeing Russel ack on the arch/arm patch. Russel, could you
please review the enclosed patch? Would this be ok for 2.6.31?
I'm not sure who this Russel is!
@@ -207,6 +220,40 @@ static struct at24_platform_data eeprom_info = {
.context= (void *)0x7f00,
};
+static struct i2c_client *cpld_client;
+
+static int cpld_video_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ cpld_client = client;
+ return 0;
+}
+
+static int __devexit cpld_video_remove(struct i2c_client *client)
+{
+ cpld_client = NULL;
+ return 0;
+}
...
+static int set_vpif_clock(int mux_mode, int hd)
+{
+ int val = 0;
+ int err = 0;
+ unsigned int value;
+ void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
+
+ /* disable the clock */
+ value = __raw_readl(base + VSCLKDIS_OFFSET);
+ value |= (VIDCH3CLK | VIDCH2CLK);
+ __raw_writel(value, base + VSCLKDIS_OFFSET);
+
+ val = i2c_smbus_read_byte(cpld_client);
+ if (val 0)
+ return val;
+
+ if (mux_mode == 1)
+ val = ~0x40;
+ else
+ val |= 0x40;
+
+ err = i2c_smbus_write_byte(cpld_client, val);
+ if (err)
+ return err;
So what prevents this 'cpld_client' being removed mid-operation? What if
'cpld_client' isn't found for whatever reason?
+static struct platform_device vpif_display_dev = {
+ .name = vpif_display,
+ .id = -1,
+ .dev= {
+ .dma_mask = vpif_dma_mask,
+ .coherent_dma_mask = DMA_32BIT_MASK,
Shouldn't this be DMA_BIT_MASK(32) ?
--
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: [BUG] drivers/video/sis: deadlock introduced by fbdev: add mutex for fb_mmap locking
On Sun, Jul 05, 2009 at 07:19:33AM -0700, Linus Torvalds wrote: On Sun, 5 Jul 2009, Wu Zhangjin wrote: then it works! so, I guess there is a deadlock introduced by the above commit. Hmm. Perhaps more likely, the 'mm_lock' mutex hasn't even been initialized yet. We appear to have had that problem with matroxfb and sm501fb, and it may be more common than that. See commit f50bf2b2. That said, I do agree that the mm_lock seems to be causing more problems than it actually fixes, and maybe we should revert it. Krzysztof? Looking at this a bit closer, just moving the mutex initialization in to framebuffer_alloc() should basically fix most of these, at least it certainly does for sm501fb and for this sis case as well. So, here's a patch to do that. As an aside note, matroxfb is the odd one out, as it doesn't use framebuffer_alloc() directly for whatever reason. This actually raises an additional issue, in that framebuffer_alloc() is already where other mutexes are initialized, which will simply never happen on matroxfb (suggesting that at least the FB_BACKLIGHT and matroxfb combination will blow up, although perhaps that's not a valid combination). Signed-off-by: Paul Mundt let...@linux-sh.org --- drivers/video/fbmem.c |1 - drivers/video/fbsysfs.c |2 ++ 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c index 53ea056..27a5271 100644 --- a/drivers/video/fbmem.c +++ b/drivers/video/fbmem.c @@ -1514,7 +1514,6 @@ register_framebuffer(struct fb_info *fb_info) break; fb_info-node = i; mutex_init(fb_info-lock); - mutex_init(fb_info-mm_lock); fb_info-dev = device_create(fb_class, fb_info-device, MKDEV(FB_MAJOR, i), NULL, fb%d, i); diff --git a/drivers/video/fbsysfs.c b/drivers/video/fbsysfs.c index d4a2c11..dd413ad 100644 --- a/drivers/video/fbsysfs.c +++ b/drivers/video/fbsysfs.c @@ -62,6 +62,8 @@ struct fb_info *framebuffer_alloc(size_t size, struct device *dev) mutex_init(info-bl_curve_mutex); #endif + mutex_init(info-mm_lock); + return info; #undef PADDING #undef BYTES_PER_LONG -- 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: [BUG] drivers/video/sis: deadlock introduced by fbdev: add mutex for fb_mmap locking
On Sun, 5 Jul 2009 07:19:33 -0700 (PDT) Linus Torvalds torva...@linux-foundation.org wrote: On Sun, 5 Jul 2009, Wu Zhangjin wrote: then it works! so, I guess there is a deadlock introduced by the above commit. Hmm. Perhaps more likely, the 'mm_lock' mutex hasn't even been initialized yet. We appear to have had that problem with matroxfb and sm501fb, and it may be more common than that. See commit f50bf2b2. That said, I do agree that the mm_lock seems to be causing more problems than it actually fixes, and maybe we should revert it. Krzysztof? I vote for fixing these drivers after my change. I will send a patch for the sis driver soon. I am building new kernel now. Regards, Krzysztof -- Rozwiaz krzyzowke i wygraj nagrody! Sprawdz http://link.interia.pl/f2232 -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-dm646x
Em Sun, 5 Jul 2009 15:46:32 +0100 Russell King - ARM Linux li...@arm.linux.org.uk escreveu: On Sun, Jul 05, 2009 at 09:51:55AM -0300, Mauro Carvalho Chehab wrote: Hmm... I'm not seeing Russel ack on the arch/arm patch. Russel, could you please review the enclosed patch? Would this be ok for 2.6.31? I'm not sure who this Russel is! Sorry for the typo, Russell. As double consonants are forbidden on my mother tong (except for ss), sometimes my fingers refuse to type a double consonant :) Cheers, Mauro -- 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: [BUG] drivers/video/sis: deadlock introduced by fbdev: add mutex for fb_mmap locking
On Sun, Jul 05, 2009 at 07:56:56AM -0700, Linus Torvalds wrote: On Sun, 5 Jul 2009, Paul Mundt wrote: break; fb_info-node = i; mutex_init(fb_info-lock); - mutex_init(fb_info-mm_lock); Why not lock as well? I had that initially, but matroxfb will break if we do that, and presently nothing cares about trying to take -lock that early on. -mm_lock was a special case as the lock/unlock pairs were sprinkled around well before initialization, while in the -lock case all of the lock/unlock pairs are handled internally by the fbmem code (at least a quick grep does not show any drivers using it on their own). -- 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: [PULL] http://linuxtv.org/hg/~eandren/v4l-dvb/
Em Sat, 4 Jul 2009 21:58:31 +0200
Erik Andrén erik.and...@gmail.com escreveu:
08/24: gspca - m5602-ov7660: Create blue gain control
http://linuxtv.org/hg/~eandren/v4l-dvb?cmd=changeset;node=5675978999c5
09/24: gspca - m5602-ov7660: Add red gain control
http://linuxtv.org/hg/~eandren/v4l-dvb?cmd=changeset;node=802e9a025e93
+#define RED_BALANCE_IDX 3
+ {
+ {
+ .id = V4L2_CID_RED_BALANCE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = red balance,
+ .minimum= 0x00,
+ .maximum= 0x7f,
+ .step = 0x1,
+ .default_value = OV7660_DEFAULT_RED_GAIN,
+ .flags = V4L2_CTRL_FLAG_SLIDER
+ },
+ .set = ov7660_set_red_gain,
+ .get = ov7660_get_red_gain
+ },
};
x
Hmm... as far as I understand, Red Balance and Red gain are different ways
to see the same measure. Unfortunately, the V4L2 API is not clear about those
controls.
According with the spec, we have:
V4L2_CID_CONTRAST integer Picture contrast or luma gain.
V4L2_CID_SATURATION integer Picture color saturation or chroma gain.
V4L2_CID_HUEinteger Hue or color balance.
V4L2_CID_RED_BALANCEinteger Red chroma balance.
V4L2_CID_BLUE_BALANCE integer Blue chroma balance.
V4L2_CID_GAIN integer Gain control.
From what I'm understanding from the term balance, it should be a shift over
the gain control (so, 0 means normal colors, like on HUE balance).
So, in order to convert from a RED GAIN into a RED BALANCE, we need to
calculate it as a function of the V4L2_CID_GAIN or V4L2_CID_SATURATION.
Positive values should mean more gain than the other colors, while negative
values would mean the opposite.
Since there are other patches that touch on it, I'll stop analyzing your series
on those two patches.
Cheers,
Mauro
--
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: [BUG] drivers/video/sis: deadlock introduced by fbdev: add mutex for fb_mmap locking
On Mon, 6 Jul 2009, Paul Mundt wrote: Why not lock as well? I had that initially, but matroxfb will break if we do that, and presently nothing cares about trying to take -lock that early on. I really would rather have consistency than some odd rules like that. In particular - if matroxfb is different and needs its own lock initialization because it doesn't use the common allocation routine, then please make _that_ consistent too. Rather than have it special-case just one lock that it needs to initialize separately, make it clear that since it does its own allocations it needs to initialize _everything_ separately. Otherwise anybody grepping for things will always be confused, since depending on random factors they'll notice the initializations in one place or the other, and then do the wrong thing - exactly like mm_lock was not correctly initialized this time around. In other words: it's actually _better_ to make the matroxfb pain _more_ obvious rather than less. And maybe we can deprecate the driver, throw it out entirely, or have somebody actually fix it? Linus -- 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: [BUG] drivers/video/sis: deadlock introduced by fbdev: add mutex for fb_mmap locking
On Sun, Jul 05, 2009 at 08:19:40AM -0700, Linus Torvalds wrote:
On Mon, 6 Jul 2009, Paul Mundt wrote:
Why not lock as well?
I had that initially, but matroxfb will break if we do that, and
presently nothing cares about trying to take -lock that early on.
I really would rather have consistency than some odd rules like that.
In particular - if matroxfb is different and needs its own lock
initialization because it doesn't use the common allocation routine, then
please make _that_ consistent too. Rather than have it special-case just
one lock that it needs to initialize separately, make it clear that since
it does its own allocations it needs to initialize _everything_
separately.
Ok, here is an updated version with an updated matroxfb and the sm501fb
change reverted.
Signed-off-by: Paul Mundt let...@linux-sh.org
---
drivers/video/fbmem.c|2 --
drivers/video/fbsysfs.c |3 +++
drivers/video/matrox/matroxfb_base.c |1 +
drivers/video/sm501fb.c |2 --
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 53ea056..53eb396 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1513,8 +1513,6 @@ register_framebuffer(struct fb_info *fb_info)
if (!registered_fb[i])
break;
fb_info-node = i;
- mutex_init(fb_info-lock);
- mutex_init(fb_info-mm_lock);
fb_info-dev = device_create(fb_class, fb_info-device,
MKDEV(FB_MAJOR, i), NULL, fb%d, i);
diff --git a/drivers/video/fbsysfs.c b/drivers/video/fbsysfs.c
index d4a2c11..afc04df 100644
--- a/drivers/video/fbsysfs.c
+++ b/drivers/video/fbsysfs.c
@@ -62,6 +62,9 @@ struct fb_info *framebuffer_alloc(size_t size, struct device
*dev)
mutex_init(info-bl_curve_mutex);
#endif
+ mutex_init(info-lock);
+ mutex_init(info-mm_lock);
+
return info;
#undef PADDING
#undef BYTES_PER_LONG
diff --git a/drivers/video/matrox/matroxfb_base.c
b/drivers/video/matrox/matroxfb_base.c
index 59c3a2e..76bc51b 100644
--- a/drivers/video/matrox/matroxfb_base.c
+++ b/drivers/video/matrox/matroxfb_base.c
@@ -2083,6 +2083,7 @@ static int matroxfb_probe(struct pci_dev* pdev, const
struct pci_device_id* dumm
spin_lock_init(ACCESS_FBINFO(lock.accel));
init_rwsem(ACCESS_FBINFO(crtc2.lock));
init_rwsem(ACCESS_FBINFO(altout.lock));
+ mutex_init(ACCESS_FBINFO(fbcon).lock);
mutex_init(ACCESS_FBINFO(fbcon).mm_lock);
ACCESS_FBINFO(irq_flags) = 0;
init_waitqueue_head(ACCESS_FBINFO(crtc1.vsync.wait));
diff --git a/drivers/video/sm501fb.c b/drivers/video/sm501fb.c
index 16d4f4c..98f24f0 100644
--- a/drivers/video/sm501fb.c
+++ b/drivers/video/sm501fb.c
@@ -1624,8 +1624,6 @@ static int __devinit sm501fb_start_one(struct
sm501fb_info *info,
if (!fbi)
return 0;
- mutex_init(info-fb[head]-mm_lock);
-
ret = sm501fb_init_fb(info-fb[head], head, drvname);
if (ret) {
dev_err(info-dev, cannot initialise fb %s\n, drvname);
--
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: [BUG] drivers/video/sis: deadlock introduced by fbdev: add mutex for fb_mmap locking
On Mon, 6 Jul 2009, Paul Mundt wrote: Ok, here is an updated version with an updated matroxfb and the sm501fb change reverted. Wu Zhangjin, can you also confirm that this works for you (without your patch)? Linus -- 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: [BUG] drivers/video/sis: deadlock introduced by fbdev: add mutex for fb_mmap locking
On Mon, 6 Jul 2009 00:25:57 +0900 Paul Mundt let...@linux-sh.org wrote: On Sun, Jul 05, 2009 at 08:19:40AM -0700, Linus Torvalds wrote: On Mon, 6 Jul 2009, Paul Mundt wrote: Why not lock as well? I had that initially, but matroxfb will break if we do that, and presently nothing cares about trying to take -lock that early on. I really would rather have consistency than some odd rules like that. In particular - if matroxfb is different and needs its own lock initialization because it doesn't use the common allocation routine, then please make _that_ consistent too. Rather than have it special-case just one lock that it needs to initialize separately, make it clear that since it does its own allocations it needs to initialize _everything_ separately. Ok, here is an updated version with an updated matroxfb and the sm501fb change reverted. Signed-off-by: Paul Mundt let...@linux-sh.org --- This is incorrect way to fix this as some drivers do not use the framebuffer_alloc() at all. They use global (for a file) fb_info structure. I have done some cleanups to the fbdev layer before the 2.6.31 and there should no drivers which uses kmalloc or kzalloc to allocate the fb_info (your patch would break these drivers too). A root of the whole mm_lock issue is that the fb_mmap() BKL protected two fb_info fields which were never protected when set. I changed this by add the mm_lock around these fields but only in drivers which modified this fields AFTER call to the register_framebuffer(). Some drivers set these fields using the same function before and after the register_framebuffer(). I strongly believe that setting these fields before the register_framebuffer() is wrong or redundant for these drivers. See my fix for the sisfb driver below. I have tested the patch below. Wu Zhangjin, can you also confirm that this works for you (without your patch)? I will look into the matroxfb and sm501fb drivers now. The same problem is already fixed for the mx3fb driver and the patch is sent to Andrew Morton. Regards, Krzysztof From: Krzysztof Helt krzysztof...@wp.pl Remove redundant call to the sisfb_get_fix() before sis frambuffer is registered. This fixes a problem with uninitialized the fb_info-mm_lock mutex. Signed-off-by: Krzysztof Helt krzysztof...@wp.pl --- diff -urp linux-ref/drivers/video/sis/sis_main.c linux-next/drivers/video/sis/sis_main.c --- linux-ref/drivers/video/sis/sis_main.c 2009-07-01 18:07:05.0 +0200 +++ linux-next/drivers/video/sis/sis_main.c 2009-07-05 17:20:33.0 +0200 @@ -6367,7 +6367,6 @@ error_3: vfree(ivideo-bios_abase); sis_fb_info-fix = ivideo-sisfb_fix; sis_fb_info-screen_base = ivideo-video_vbase + ivideo-video_offset; sis_fb_info-fbops = sisfb_ops; - sisfb_get_fix(sis_fb_info-fix, -1, sis_fb_info); sis_fb_info-pseudo_palette = ivideo-pseudo_palette; fb_alloc_cmap(sis_fb_info-cmap, 256 , 0); -- Najlepsze OC i AC tylko w Ergo Hestia http://link.interia.pl/f222 -- 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: [BUG] drivers/video/sis: deadlock introduced by fbdev: add mutex for fb_mmap locking
On Mon, 6 Jul 2009 00:25:57 +0900 Paul Mundt let...@linux-sh.org wrote: Ok, here is an updated version with an updated matroxfb and the sm501fb change reverted. Signed-off-by: Paul Mundt let...@linux-sh.org Here is a patch which should fix problem with sm501fb driver: diff --git a/drivers/video/sm501fb.c b/drivers/video/sm501fb.c index 16d4f4c..924d794 100644 --- a/drivers/video/sm501fb.c +++ b/drivers/video/sm501fb.c @@ -1540,9 +1540,6 @@ static int sm501fb_init_fb(struct fb_info *fb, if (ret) dev_err(info-dev, check_var() failed on initial setup?\n); - /* ensure we've activated our new configuration */ - (fb-fbops-fb_set_par)(fb); - return 0; } Paul, please test it (without additional initialization of the mm_lock mutext). I will post the patch if it works for you. An issue here is that these drivers calls fb_set_par() function (or part of it as the sisfb driver) but the register_framebuffer() calls the fb_set_par() also after all structures are set up. There should be no need to call the fb_set_par() just before the register_framebuffer(). The matroxfb driver is quite far from standard driver framework by now. I vote for fixing it by adding this early initialization of the mm_mutex for now. Kind regards, Krzysztof -- Promocja ubezpieczen komunikacyjnych Ergo Hestia. Sprawdz! http://link.interia.pl/f222f -- 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] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Jul 5 19:00:05 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12191:d703149eab45 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-rc1-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.31-rc1-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.31-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-rc1-i686: ERRORS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-rc1-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-rc1-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: OK linux-2.6.30-x86_64: WARNINGS linux-2.6.31-rc1-x86_64: ERRORS sparse (linux-2.6.30): OK sparse (linux-2.6.31-rc1): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK 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 V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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
[PULL] http://linuxtv.org/hg/~awalls/ivtv
Mauro, Please pull from http://linuxtv.org/hg/~awalls/ivtv for the following 2 changesets: 01/02: ivtv: Add card entry for AVerMedia UltraTV 1500 MCE (M113 variant) http://linuxtv.org/hg/~awalls/ivtv?cmd=changeset;node=ebb0ea04b057 02/02: ivtv: Fix automatic detection of AVerMedia UltraTV 1500MCE. http://linuxtv.org/hg/~awalls/ivtv?cmd=changeset;node=ff6524eeaecb ivtv-cards.c | 45 + ivtv-cards.h |3 ++- ivtv-driver.c |1 + 3 files changed, 48 insertions(+), 1 deletion(-) Thanks, Andy -- 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
[PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
Hello Mauro, Please pull from http://www.linuxtv.org/hg/~dougsland/v4l-dvb for the following: bttv and meye: Use PCI_VDEVICE radio-si470x: fix lock imbalance em28xx, fix lock imbalance adv7343: remove unused #include linux/version.h mt312: Fix checkpatch warnings remove redundant tests on unsigned ivtv-driver.c: Remove unnecessary semicolons Remove unnecessary semicolons cx18-fileops.c: Remove unnecessary semicolons Cheers, Douglas -- 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: [PULL] http://linuxtv.org/hg/~eandren/v4l-dvb/
Mauro Carvalho Chehab wrote:
Em Sat, 4 Jul 2009 21:58:31 +0200
Erik Andrén erik.and...@gmail.com escreveu:
08/24: gspca - m5602-ov7660: Create blue gain control
http://linuxtv.org/hg/~eandren/v4l-dvb?cmd=changeset;node=5675978999c5
09/24: gspca - m5602-ov7660: Add red gain control
http://linuxtv.org/hg/~eandren/v4l-dvb?cmd=changeset;node=802e9a025e93
+#define RED_BALANCE_IDX 3
+ {
+ {
+ .id = V4L2_CID_RED_BALANCE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = red balance,
+ .minimum= 0x00,
+ .maximum= 0x7f,
+ .step = 0x1,
+ .default_value = OV7660_DEFAULT_RED_GAIN,
+ .flags = V4L2_CTRL_FLAG_SLIDER
+ },
+ .set = ov7660_set_red_gain,
+ .get = ov7660_get_red_gain
+ },
};
x
Hmm... as far as I understand, Red Balance and Red gain are different ways
to see the same measure. Unfortunately, the V4L2 API is not clear about those
controls.
According with the spec, we have:
V4L2_CID_CONTRAST integer Picture contrast or luma gain.
V4L2_CID_SATURATION integer Picture color saturation or chroma gain.
V4L2_CID_HUE integer Hue or color balance.
V4L2_CID_RED_BALANCE integer Red chroma balance.
V4L2_CID_BLUE_BALANCE integer Blue chroma balance.
V4L2_CID_GAIN integer Gain control.
From what I'm understanding from the term balance, it should be a shift over
the gain control (so, 0 means normal colors, like on HUE balance).
So, in order to convert from a RED GAIN into a RED BALANCE, we need to
calculate it as a function of the V4L2_CID_GAIN or V4L2_CID_SATURATION.
Positive values should mean more gain than the other colors, while negative
values would mean the opposite.
Is such a function defined somewhere? Do you have an example
implementing it?
I've done the same thing in the m5602 ov9650 sensor code.
Regards,
Erik
Since there are other patches that touch on it, I'll stop analyzing your
series
on those two patches.
Cheers,
Mauro
--
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
[PULL] http://linuxtv.org/hg/~awalls/v4l-dvb
Mauro, Please pull from http://linuxtv.org/hg/~awalls/v4l-dvb for the following 2 changesets: 01/02: get_dvb_firmware: Correct errors in MPC718 firmware extraction logic http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=e5e765a66e0c 02/02: cx18: Add an EEPROM dump routine for the Yuan MPC718 and future cards http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=e1f463b65749 Documentation/dvb/get_dvb_firmware |3 +- drivers/media/video/cx18/cx18-cards.c |2 - drivers/media/video/cx18/cx18-driver.c | 41 +++-- 3 files changed, 42 insertions(+), 4 deletions(-) Thanks, Andy -- 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
[GIT PATCHES for 2.6.31] V4L/DVB fixes
Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git for_linus For the following bug fixes: - v4l2 core: move V4L2_PIX_FMT_SGRBG8 to the proper place; - vivi: bug: don't assume that S_STD will be called before streaming; - ttpci: config TTPCI_EEPROM depends on I2C; - soc_camera: Fix debug output of supported formats count and fix missing clean up on error path; - tuner-xc2028: Fix 7 MHz DVB-T; - cx18: Update Yuan MPC-718 card entry with better information and guesses; - cx23885: allow rf input path switching on the HVR1275; - radio-si470x: fix lock imbalance; - em28xx, fix lock imbalance. There's also a few changes at the dvb get firmware script: - get_dvb_firmware: Add Yuan MPC718 MT352 DVB-T firmware extraction - get_dvb_firmware: Correct errors in MPC718 firmware extraction logic A trivial board addition to an existing driver: - cx18: Add DVB-T support for Yuan MPC-718 cards with an MT352 or ZL10353 And a new webcam sensor driver, with the corresponding fixes on em28xx, in order to properly support webcams: - Add a driver for mt9v011 sensor; - mt9v011: Some fixes at the register initialization table; - mt9v011: CodingStyle fixes; - mt9v011: properly calculate image resolution registers; - mt9v011: let's stick with datasheet values where it works; - em28xx: add support for Silvercrest Webcam; - em28xx: add other video formats; - em28xx: Fix tuning for Terratec Cinergy T XS USB (zl10353 version); - em28xx-video: fix VIDIOC_G_FMT and VIDIOC_ENUMFMT with webcams; - em28xx: fix webcam usage with different output formats; - em28xx: Add autodetection code for Silvercrest 1.3 mpix. Cheers, Mauro. --- Documentation/dvb/get_dvb_firmware | 53 - Documentation/video4linux/CARDLIST.em28xx |1 + drivers/media/common/tuners/tuner-xc2028.c | 13 +- drivers/media/dvb/ttpci/Kconfig |1 + drivers/media/radio/radio-si470x.c |5 +- drivers/media/video/Kconfig |8 + drivers/media/video/Makefile|1 + drivers/media/video/cx18/cx18-cards.c | 34 ++- drivers/media/video/cx18/cx18-dvb.c | 160 ++ drivers/media/video/cx23885/cx23885-dvb.c | 30 ++ drivers/media/video/cx23885/cx23885.h |4 + drivers/media/video/em28xx/Kconfig |2 + drivers/media/video/em28xx/em28xx-cards.c | 84 +- drivers/media/video/em28xx/em28xx-core.c| 32 ++- drivers/media/video/em28xx/em28xx-dvb.c | 28 ++- drivers/media/video/em28xx/em28xx-i2c.c |2 +- drivers/media/video/em28xx/em28xx-video.c | 92 -- drivers/media/video/em28xx/em28xx.h |3 + drivers/media/video/gspca/stv06xx/stv06xx.h |4 - drivers/media/video/mt9v011.c | 431 +++ drivers/media/video/mt9v011.h | 35 +++ drivers/media/video/soc_camera.c| 12 +- drivers/media/video/vivi.c | 99 +++--- include/linux/videodev2.h |2 + include/media/v4l2-chip-ident.h |3 + 25 files changed, 1027 insertions(+), 112 deletions(-) create mode 100644 drivers/media/video/mt9v011.c create mode 100644 drivers/media/video/mt9v011.h Andy Walls (5): V4L/DVB (12167): tuner-xc2028: Fix 7 MHz DVB-T V4L/DVB (12180): cx18: Update Yuan MPC-718 card entry with better information and guesses V4L/DVB (12181): get_dvb_firmware: Add Yuan MPC718 MT352 DVB-T firmware extraction V4L/DVB (12182): cx18: Add DVB-T support for Yuan MPC-718 cards with an MT352 or ZL10353 V4L/DVB (12206): get_dvb_firmware: Correct errors in MPC718 firmware extraction logic Devin Heitmueller (1): V4L/DVB (12156): em28xx: Fix tuning for Terratec Cinergy T XS USB (zl10353 version) Guennadi Liakhovetski (1): V4L/DVB (12160): soc-camera: fix missing clean up on error path Hans Verkuil (1): V4L/DVB (12153): ttpci: config TTPCI_EEPROM depends on I2C Jiri Slaby (2): V4L/DVB (12202): em28xx, fix lock imbalance V4L/DVB (12203): radio-si470x: fix lock imbalance Mauro Carvalho Chehab (12): V4L/DVB (12134): vivi: bug: don't assume that S_STD will be called before streaming V4L/DVB (12148): move V4L2_PIX_FMT_SGRBG8 to the proper place V4L/DVB (12135): Add a driver for mt9v011 sensor V4L/DVB (12136): mt9v011: Some fixes at the register initialization table V4L/DVB (12137): mt9v011: CodingStyle fixes V4L/DVB (12173): mt9v011: properly calculate image resolution registers V4L/DVB (12174): mt9v011: let's stick with datasheet values where it works V4L/DVB (12138): em28xx: add support for Silvercrest Webcam V4L/DVB (12139): em28xx: add other video formats V4L/DVB (12169): em28xx-video: fix VIDIOC_G_FMT and VIDIOC_ENUMFMT with webcams V4L/DVB (12171): em28xx: fix webcam
Re: regression : saa7134 with Pinnacle PCTV 50i (analog) can not tune anymore
Hi Eric, Am Sonntag, den 05.07.2009, 09:08 +0200 schrieb eric.patur...@orange.fr: On 4 Jul, hermann pitton wrote: Am Samstag, den 04.07.2009, 20:05 +0200 schrieb eric.patur...@orange.fr: On 4 Jul, hermann pitton wrote: Hello, Am Samstag, den 04.07.2009, 15:16 +0200 schrieb eric.patur...@orange.fr: hello I had my Pinnacle PCTV 50i analog tv card working quite well for several years with linux . but since mid june it can not tune anymore when using the latest mercurial version of the v4l2 drivers . It is working fine up to the official V4l2 driver of 2.6.30 . here is an example of /var/log/messages with official v4l2 drivers of 2.6.27.4 (working well) : [snip] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff TUNER: Unable to find symbol tda829x_probe() ..^^^ tuner 1-004b: chip found @ 0x96 (saa7133[0]) DVB: Unable to find symbol tda9887_attach() saa7133[0]: registered device video0 [v4l2] saa7133[0]: registered device vbi0 saa7133[0]: registered device radio0 saa7134 ALSA driver for DMA sound loaded IRQ 11/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs saa7133[0]/alsa: saa7133[0] at 0xed80 irq 11 registered as card -1 Jul 2 09:12:43 neptune kernel: tuner 1-004b: Tuner has no way to set tv freq Jul 2 09:19:14 neptune kernel: tuner 1-004b: Tuner has no way to set tv freq Jul 2 09:20:16 neptune kernel: tuner 1-004b: Tuner has no way to set tv freq Jul 2 09:20:26 neptune kernel: tuner 1-004b: Tuner has no way to set tv freq any idea what is going on ? out of some reason you don't have the tda8290 analog IF demodulator module. In theory this should be only possible, if you have selected Customize analog and hybrid tuner modules to build and deselected TDA 8290/8295 + 8275(a)/18271 tuner combo. I'm writing from a 2.6.29 and don't have such problems, but what makes me wonder is, that you also don't have the tda9887. You don't need it for that card, but I can't even deselect it at all. With deselected tda8290 it gets loaded here instead, since within the same address range. Can you check with make xconfig/menuconfig, if the tda8290 is selected on your build and watch if it is compiled at the beginning of make? Cheers, Hermann Hi Hermann i checked the xconfig menu , I unselected Customize analog and hybrid tuner modules to build (just to be sure) the module tda8290.ko gets built and installed (i double checked ) . [r...@neptune / ]# cd /lib/modules/2.6.29.4 [r...@neptune 2.6.29.4]# find . -name tda829* ./kernel/drivers/media/common/tuners/tda8290.ko [r...@neptune 2.6.29.4]# uname -a Linux neptune.localwarp.net 2.6.29.4 #1 Mon Jun 1 11:01:38 CEST 2009 i686 AMD Athlon(tm) Processor unknown GNU/Linux [r...@neptune 2.6.29.4]# find . -name tda829* -ls 36948 16 -rw-r--r-- 1 root root15908 Jul 4 19:44 ./kernel/drivers/media/common/tuners/tda8290.ko but it does not get loaded automatically . I tried to load it manualy with modprobe , but, even with that module loaded i still get : tuner 1-004b: Tuner has no way to set tv freq tuner 1-004b: Tuner has no way to set tv freq tuner 1-004b: Tuner has no way to set tv freq cheers , Hi Eric, hm, are you sure all old modules have been unloaded previously with make rmmod. saa7134-alsa might be in use by some mixer application und you can't unload the tuner stuff anymore independently from saa7134, like it was in all the prior years. Do you also still see the unresolved symbols? Then maybe try a reboot. Cheers, Hermann Hi Hermann I rebooted everytime i recompiled v4l . I also t unloaded saa7134 , tuner , saa7134_alsa just after reboot . reloaded tda8290 , then tuner , then saa7134 . I do not get unresolved symbols then, but no picture either , and the tv application hangs . did not have time to think about it, since I'm sitting in some other unrelated hardware troubles too, but that sounds strange. Maybe our debugging for such cases is not good enough. I then tried this 2 cases : - case 1 : vanilla kernel 2.6.30.1 (tv application works fine with saa7134), bash-2.05b$ modinfo tuner snip depends: i2c-core,tea5761,mt20xx,tuner-simple,tda9887,videodev,tea5767,xc5000,tuner-xc2028,tda8290,v4l2-common vermagic: 2.6.30.1 mod_unload K7 bash-2.05b$ modinfo tda8290 snip depends:tda18271,tda827x,i2c-core vermagic: 2.6.30.1 case 2 kernel 2.6.30.1 with mercurial v4l drivers tv application does not work : can not tune / no picture / hangs modinfo tda8290 snip depends:i2c-core
Re: eMpia Microscope Camera
Em Fri, 3 Jul 2009 19:02:36 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu: On Fri, 3 Jul 2009, Mauro Carvalho Chehab wrote: Em Fri, 3 Jul 2009 17:38:36 +0200 Wally wa...@voosen.eu escreveu: Hi Mauro, built the driver without problems. the rsult picture on mplayer is much better and the camera response now much better. But the picture sync (or something like this is still not ok). Here are the logs: removed all em28xx distro packages $ hg clone http://www.linuxtv.org/hg/v4l-dvb $ cd v4l-dvb $ make $ make rmmod $ make install $ modprobe em28xx modprobe em28xx dmesg Linux video capture interface: v2.00 usbcore: registered new interface driver em28xx em28xx driver loaded plugin device dmesg: usb 5-2: new high speed USB device using ehci_hcd and address 2 usb 5-2: configuration #1 chosen from 1 choice em28xx: New device @ 480 Mbps (eb1a:2750, interface 0, class 0) em28xx #0: Identified as Unknown EM2750/EM2751 webcam grabber (card=22) em28xx #0: chip ID is em2750 em28xx #0: board has no eeprom em28xx #0: Config register raw data: 0x00 em28xx #0: v4l2 driver version 0.1.2 em28xx #0: V4L2 device registered as /dev/video0 and /dev/vbi0 usb 5-2: New USB device found, idVendor=eb1a, idProduct=2750 usb 5-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 same behavior of camera as was, green screen etc. trying: modprobe em28xx card=71 dmesg: Linux video capture interface: v2.00 usbcore: registered new interface driver em28xx em28xx driver loaded plugin the device dmesg: usb 5-2: new high speed USB device using ehci_hcd and address 2 usb 5-2: configuration #1 chosen from 1 choice em28xx: New device @ 480 Mbps (eb1a:2750, interface 0, class 0) em28xx #0: Identified as Silvercrest Webcam 1.3mpix (card=71) em28xx #0: chip ID is em2750 em28xx #0: board has no eeprom mt9v011 4-005d: chip found @ 0xba (em28xx #0) em28xx #0: Config register raw data: 0x00 mt9v011 4-005d: *** unknown micron chip detected (0x8431. em28xx #0: v4l2 driver version 0.1.2 em28xx #0: V4L2 device registered as /dev/video0 and /dev/vbi0 usb 5-2: New USB device found, idVendor=eb1a, idProduct=2750 usb 5-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 mt9v011 4-005d: *** unknown micron chip detected (0x8431. much better but still not recognizable picture. Good! Based on the chip version, this one seems to use mt9m001c2st sensor. This sensor is already supported by mt9m001 driver. It will probably work like a charm after using it. Yet, the mt9m001 currently uses a different API for I2C binding, although Guennadi is porting it to v4l2 dev/subdev. Guennadi, I saw some patches from you migrating soc_camera to v4l2 dev/subdev. When are you intending to send those patches to me? It would be cool if Wally could test the mt9m001 with em28xx driver Hi Mauro Yes, in my quilt stack soc-camera uses v4l2-subdev registration / module loading procedure and some operations. Currently I am fixing cropping / scaling (which, I hope, I interpreted correctly this time, although I haven't got your or Hans' or anyone else's opinion to my last question / interpretation) in all soc-camera drivers. Ok. I'll seek for some time to better understand your question and give my impression about the crop/scaling question. This makes the legacy soc-camera API between the core and host drivers on one side and camera drivers on the other side quite thin. Still even when this is done, there are still some remaining bonds that have to be broken: 1) pixel format negotiation, 2) bus parameter negotiation, and we still haven't got your decision regarding whether or not we shall support autonegiation. What thread are you referring to? So, one delaying factor is that there is still some work to be done, and I don't think, I'll be getting more time for soc-camera in the near future. Another delaying factor, is that ARM platforms have missed the 2.6.31 merge window, so, we cannot convert now and have to wait until 2.6.32. Are you meaning that you need some patches at arch/arm that aren't merged upstream yet? Are those patches already in linux-next? Of course, development and testing can be done in a separate tree. My last snapshot is based on post 2.6.30. Considering the regressions we had with 2.6.30, several of them directly or indirectly related to dev/subdev conversion, I prefer if you could send the soc-camera conversion on an early -rc kernel, to allow more time for testing inside v4l-dvb tree and at linux-next, before entering on a new merge window Cheers, Mauro -- 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
Re: [BUG] drivers/video/sis: deadlock introduced by fbdev: add mutex for fb_mmap locking
Hi, On Sun, 2009-07-05 at 18:18 +0200, Krzysztof Helt wrote: On Mon, 6 Jul 2009 00:25:57 +0900 Paul Mundt let...@linux-sh.org wrote: On Sun, Jul 05, 2009 at 08:19:40AM -0700, Linus Torvalds wrote: On Mon, 6 Jul 2009, Paul Mundt wrote: Why not lock as well? I had that initially, but matroxfb will break if we do that, and presently nothing cares about trying to take -lock that early on. I really would rather have consistency than some odd rules like that. In particular - if matroxfb is different and needs its own lock initialization because it doesn't use the common allocation routine, then please make _that_ consistent too. Rather than have it special-case just one lock that it needs to initialize separately, make it clear that since it does its own allocations it needs to initialize _everything_ separately. Ok, here is an updated version with an updated matroxfb and the sm501fb change reverted. Signed-off-by: Paul Mundt let...@linux-sh.org --- This is incorrect way to fix this as some drivers do not use the framebuffer_alloc() at all. They use global (for a file) fb_info structure. I have done some cleanups to the fbdev layer before the 2.6.31 and there should no drivers which uses kmalloc or kzalloc to allocate the fb_info (your patch would break these drivers too). A root of the whole mm_lock issue is that the fb_mmap() BKL protected two fb_info fields which were never protected when set. I changed this by add the mm_lock around these fields but only in drivers which modified this fields AFTER call to the register_framebuffer(). Some drivers set these fields using the same function before and after the register_framebuffer(). I strongly believe that setting these fields before the register_framebuffer() is wrong or redundant for these drivers. See my fix for the sisfb driver below. I have tested the patch below. Wu Zhangjin, can you also confirm that this works for you (without your patch)? This patch also works for me, thanks! Regards, Wu Zhangjin I will look into the matroxfb and sm501fb drivers now. The same problem is already fixed for the mx3fb driver and the patch is sent to Andrew Morton. Regards, Krzysztof From: Krzysztof Helt krzysztof...@wp.pl Remove redundant call to the sisfb_get_fix() before sis frambuffer is registered. This fixes a problem with uninitialized the fb_info-mm_lock mutex. Signed-off-by: Krzysztof Helt krzysztof...@wp.pl --- diff -urp linux-ref/drivers/video/sis/sis_main.c linux-next/drivers/video/sis/sis_main.c --- linux-ref/drivers/video/sis/sis_main.c2009-07-01 18:07:05.0 +0200 +++ linux-next/drivers/video/sis/sis_main.c 2009-07-05 17:20:33.0 +0200 @@ -6367,7 +6367,6 @@ error_3:vfree(ivideo-bios_abase); sis_fb_info-fix = ivideo-sisfb_fix; sis_fb_info-screen_base = ivideo-video_vbase + ivideo-video_offset; sis_fb_info-fbops = sisfb_ops; - sisfb_get_fix(sis_fb_info-fix, -1, sis_fb_info); sis_fb_info-pseudo_palette = ivideo-pseudo_palette; fb_alloc_cmap(sis_fb_info-cmap, 256 , 0); -- Najlepsze OC i AC tylko w Ergo Hestia http://link.interia.pl/f222 -- 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
