RE: FW: OMAP 3 ISP
Hi Ritesh, Please send in the future CC to laurent.pinch...@ideasonboard.com and linux-media@vger.kernel.org Hi Alex, I also started working with OMAP35x torpedo kit, I successful compile Linux 3.0 and ported on the board. Device is booting correctly but probe function in omap3isp module not getting called. Please help me You have relevant Kernel boot messages? You can also find information in media archives OMAP 3 ISP thread. Regards, Alex -- 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: FW: OMAP 3 ISP
2012/5/29 Alex Gershgorin al...@meprolight.com: Hi Ritesh, Please send in the future CC to laurent.pinch...@ideasonboard.com and linux-media@vger.kernel.org Hi Alex, I also started working with OMAP35x torpedo kit, I successful compile Linux 3.0 and ported on the board. Device is booting correctly but probe function in omap3isp module not getting called. Please help me You have relevant Kernel boot messages? You can also find information in media archives OMAP 3 ISP thread. Regards, Alex Hi, I had a similar problem with a 2.6.39 kernel, that was solved with a 3.2 kernel. When compiled as a module, the probe function was called, but was failing later. The single message I would see was ISP revision x.y found [1] When compiled in the kernel image, everything was fine. [1] http://lxr.linux.no/linux+v2.6.39.4/drivers/media/video/omap3isp/isp.c#L2103 Jean-Philippe François -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 0/5] Add hwseek caps and frequency bands
Hi, On 05/28/2012 01:58 PM, Hans Verkuil wrote: On Mon May 28 2012 13:20:47 Hans de Goede wrote: Hi, Looks good, the entire series is: Acked-by: Hans de Goedehdego...@redhat.com I was thinking that it would be a good idea to add a: #define V4L2_TUNER_CAP_BANDS_MASK 0x001f to videodev2.h, which apps can then easily use to test if the driver supports any bands other then the default, and decide to show band selection elements of the UI or not based on a test on the tuner-caps using that mask. This can be done in a separate patch, or merged into PATCH 4/6 videodev2.h: add frequency band information Good idea, I've merged it into patch 4 and 5 (documenting it). It's here: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/bands New version still look good, so the entire series still is: Acked-by: Hans de Goedehdego...@redhat.com :) Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH] omap3isp : fix cfa demosaicing for format other than GRBG
Hi,
omap3 ISP previewer block can convert a raw bayer image
into a UYVY image. Debayering coefficient are stored in
an undocumented table. In the current form, only
GRBG format are converted correctly.
However, the other CFA arrangement can be transformed
in GRBG arrangement by shifting the image window one pixel
to the left or to the bottom.
Here is a patch against vanilla 3.2.17, that was only tested with a
BGGR arrangement.
Is it the right way to fix this issue ?
Thank you,
Jean-Philippe François
Index: b/drivers/media/video/omap3isp/isppreview.c
===
--- a/drivers/media/video/omap3isp/isppreview.c
+++ b/drivers/media/video/omap3isp/isppreview.c
@@ -96,21 +96,26 @@
* 2 lines in other modes
* Color suppression 2 pixels
* or luma enhancement
+ *
+ * Bayer pattern shifting 2 pixels, 1 line
* -
- * Maximum total 14 pixels, 8 lines
+ * Maximum total 18 pixels, 9 lines
*
* The color suppression and luma enhancement filters are applied
after bayer to
* YUV conversion. They thus can crop one pixel on the left and one
pixel on the
* right side of the image without changing the color pattern. When both those
* filters are disabled, the driver must crop the two pixels on the
same side of
- * the image to avoid changing the bayer pattern. The left margin is
thus set to
- * 8 pixels and the right margin to 6 pixels.
+ * the image to avoid changing the bayer pattern.
+ *
+ * Bayer pattern shifting is needed for some bayer pattern. Shifting
+ * will be in the right and bottom direction.
+ * The left margin is thus set to 8 pixels and the right margin to 10 pixels.
*/
#define PREV_MARGIN_LEFT 8
-#define PREV_MARGIN_RIGHT 6
+#define PREV_MARGIN_RIGHT 10
#define PREV_MARGIN_TOP4
-#define PREV_MARGIN_BOTTOM 4
+#define PREV_MARGIN_BOTTOM 5
#define PREV_MIN_IN_WIDTH 64
#define PREV_MIN_IN_HEIGHT 8
@@ -1038,6 +1043,34 @@
eph += 2;
slv -= 2;
elv += 2;
+ /* CFA table coef only handle GRBG format. Other format
+* can be transformed in GRBG by shifting the pattern :
+* BGGR - GRBG is obtained by a 1 row shift
+* RGGB - GRBG is obtained by a 1 column shift
+* GBRG - GRBG is obtained by a row and column shift
+*/
+ switch(prev-formats[PREV_PAD_SINK].code) {
+ case V4L2_MBUS_FMT_SRGGB10_1X10:
+ sph += 1;
+ eph += 1;
+ break;
+
+ case V4L2_MBUS_FMT_SBGGR10_1X10:
+ slv += 1;
+ elv += 1;
+ break;
+
+ case V4L2_MBUS_FMT_SGBRG10_1X10:
+ sph += 1;
+ eph += 1;
+ slv += 1;
+ elv += 1;
+ break;
+
+ default:
+ break;
+ }
+
}
if (params-features (PREV_DEFECT_COR | PREV_NOISE_FILTER)) {
sph -= 2;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
TurboX Hybrid TV Tuner HTT-1000 SUPPORT?
Hello, I have bought recently TurboX Hybrid TV Tuner HTT-1000, which don't work on linux at all. from lsusb, appears as: Bus 001 Device 003: ID 1b80:d418 Afatech and no other infos are available. dmesg doesn't give any info about it. lsusb -v gives these: --- Bus 001 Device 010: ID 1b80:d418 Afatech Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 idVendor 0x1b80 Afatech idProduct 0xd418 bcdDevice 40.01 iManufacturer 1 Conexant Corporation iProduct 2 Polaris AV Capture iSerial 3 00 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 344 bNumInterfaces 7 bConfigurationValue 1 iConfiguration 4 Polaris AV Capture bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 32 Polaris AV Capture Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0e EP 14 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 4 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 1 bInterfaceCount 6 bFunctionClass 255 Vendor Specific Class bFunctionSubClass 255 Vendor Specific Subclass bFunctionProtocol 255 Vendor Specific Protocol iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 7 Polaris AV Capture Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8f EP 15 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 7 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 8 Polaris AV Capture Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 9 Polaris AV Capture Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 5 Transfer Type Isochronous Synch Type
[GIT PULL FIXES FOR 3.5]: gspca radio fixes (updated 3x)
Hi Mauro et al, updated again to include 2 gspca fixes from Jean-François Moine Here is a bunch of fixes for gspca and a couple of fixes for good old radio support :) The following changes since commit abed623ca59a7d1abed6c4e7459be03e25a90a1e: [media] radio-sf16fmi: add support for SF16-FMD (2012-05-20 16:10:05 -0300) are available in the git repository at: git://linuxtv.org/hgoede/gspca.git media-for_v3.5 for you to fetch changes up to 2856acfae0a84b3cb4af049d17c09593d6b1b2d3: gspca - sonixj: Fix bad values of webcam 0458:7025 (2012-05-29 11:11:10 +0200) Antonio Ospite (1): gspca_ov534: make AGC and AWB controls independent Hans de Goede (10): radio/si470x: Add support for the Axentia ALERT FM USB Receiver snd_tea575x: Report correct frequency range for EU/US versus JA models snd_tea575x: Make the module using snd_tea575x the fops owner snd_tea575x: set_freq: update cached freq to the actual achieved frequency bttv: Use btv-has_radio rather then the card info when registering the tuner bttv: Remove unused needs_tvaudio card variable bttv: The Hauppauge 61334 needs the msp3410 to do radio demodulation gspca_pac7311: Correct number of controls gscpa_sn9c20x: Move clustering of controls to after error checking gspca-core: Fix buffers staying in queued state after a stream_off Jean-Francois Moine (2): gspca - ov534/ov534_9: Fix sccd_read/write errors gspca - sonixj: Fix bad values of webcam 0458:7025 drivers/hid/hid-core.c|1 + drivers/hid/hid-ids.h |3 + drivers/media/radio/radio-maxiradio.c |2 +- drivers/media/radio/radio-sf16fmr2.c |2 +- drivers/media/radio/si470x/radio-si470x-usb.c |2 + drivers/media/video/bt8xx/bttv-cards.c| 84 ++--- drivers/media/video/bt8xx/bttv-driver.c |5 ++ drivers/media/video/bt8xx/bttv.h |1 - drivers/media/video/bt8xx/bttvp.h |1 + drivers/media/video/gspca/gspca.c |4 +- drivers/media/video/gspca/ov534.c | 32 +- drivers/media/video/gspca/ov534_9.c |1 + drivers/media/video/gspca/pac7311.c |2 +- drivers/media/video/gspca/sn9c20x.c | 24 --- drivers/media/video/gspca/sonixj.c|2 +- include/sound/tea575x-tuner.h |3 +- sound/i2c/other/tea575x-tuner.c | 21 --- sound/pci/es1968.c|2 +- sound/pci/fm801.c |4 +- 19 files changed, 62 insertions(+), 134 deletions(-) Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gspca - ov534/ov534_9: Fix sccd_read/write errors
Hi,
Thanks I've added this and the sonixj fixes to my tree and send an
updated pullreq to Mauro to include these in the next round of
fixes for 3.5
Regards,
Hans
On 05/28/2012 07:04 PM, Jean-Francois Moine wrote:
The ov534 bridge is too slow to handle the sensor accesses
requested by fast hosts giving 'sccb_reg_write failed'.
A small delay fixes the problem.
Signed-off-by: Jean-François Moinemoin...@free.fr
---
drivers/media/video/gspca/ov534.c |1 +
drivers/media/video/gspca/ov534_9.c |1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/media/video/gspca/ov534.c
b/drivers/media/video/gspca/ov534.c
index b5acb1e..d5a7873 100644
--- a/drivers/media/video/gspca/ov534.c
+++ b/drivers/media/video/gspca/ov534.c
@@ -851,6 +851,7 @@ static int sccb_check_status(struct gspca_dev *gspca_dev)
int i;
for (i = 0; i 5; i++) {
+ msleep(10);
data = ov534_reg_read(gspca_dev, OV534_REG_STATUS);
switch (data) {
diff --git a/drivers/media/video/gspca/ov534_9.c
b/drivers/media/video/gspca/ov534_9.c
index e6601b8..0120f94 100644
--- a/drivers/media/video/gspca/ov534_9.c
+++ b/drivers/media/video/gspca/ov534_9.c
@@ -1008,6 +1008,7 @@ static int sccb_check_status(struct gspca_dev *gspca_dev)
int i;
for (i = 0; i 5; i++) {
+ msleep(10);
data = reg_r(gspca_dev, OV534_REG_STATUS);
switch (data) {
--
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 06/15] video: mx1_camera: Use clk_prepare_enable/clk_disable_unprepare
On Fri, May 25, 2012 at 08:14:47PM -0300, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com Prepare the clock before enabling it. Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: linux-media@vger.kernel.org Signed-off-by: Fabio Estevam fabio.este...@freescale.com Acked-by: Sascha Hauer s.ha...@pengutronix.de --- drivers/media/video/mx1_camera.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/mx1_camera.c b/drivers/media/video/mx1_camera.c index 4296a83..dc58084 100644 --- a/drivers/media/video/mx1_camera.c +++ b/drivers/media/video/mx1_camera.c @@ -402,7 +402,7 @@ static void mx1_camera_activate(struct mx1_camera_dev *pcdev) dev_dbg(pcdev-icd-parent, Activate device\n); - clk_enable(pcdev-clk); + clk_prepare_enable(pcdev-clk); /* enable CSI before doing anything else */ __raw_writel(csicr1, pcdev-base + CSICR1); @@ -421,7 +421,7 @@ static void mx1_camera_deactivate(struct mx1_camera_dev *pcdev) /* Disable all CSI interface */ __raw_writel(0x00, pcdev-base + CSICR1); - clk_disable(pcdev-clk); + clk_disable_unprepare(pcdev-clk); } /* -- 1.7.1 -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 07/15] video: mx2_camera: Use clk_prepare_enable/clk_disable_unprepare
On Fri, May 25, 2012 at 08:14:48PM -0300, Fabio Estevam wrote:
From: Fabio Estevam fabio.este...@freescale.com
Prepare the clock before enabling it.
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: linux-media@vger.kernel.org
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
Acked-by: Sascha Hauer s.ha...@pengutronix.de
---
drivers/media/video/mx2_camera.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c
b/drivers/media/video/mx2_camera.c
index ded26b7..71b67a3 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -402,7 +402,7 @@ static void mx2_camera_deactivate(struct mx2_camera_dev
*pcdev)
{
unsigned long flags;
- clk_disable(pcdev-clk_csi);
+ clk_disable_unprepare(pcdev-clk_csi);
writel(0, pcdev-base_csi + CSICR1);
if (cpu_is_mx27()) {
writel(0, pcdev-base_emma + PRP_CNTL);
@@ -430,7 +430,7 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
if (pcdev-icd)
return -EBUSY;
- ret = clk_enable(pcdev-clk_csi);
+ ret = clk_prepare_enable(pcdev-clk_csi);
if (ret 0)
return ret;
@@ -1664,7 +1664,7 @@ static int __devinit mx27_camera_emma_init(struct
mx2_camera_dev *pcdev)
goto exit_free_irq;
}
- clk_enable(pcdev-clk_emma);
+ clk_prepare_enable(pcdev-clk_emma);
err = mx27_camera_emma_prp_reset(pcdev);
if (err)
@@ -1673,7 +1673,7 @@ static int __devinit mx27_camera_emma_init(struct
mx2_camera_dev *pcdev)
return err;
exit_clk_emma_put:
- clk_disable(pcdev-clk_emma);
+ clk_disable_unprepare(pcdev-clk_emma);
clk_put(pcdev-clk_emma);
exit_free_irq:
free_irq(pcdev-irq_emma, pcdev);
@@ -1810,7 +1810,7 @@ exit_free_emma:
eallocctx:
if (cpu_is_mx27()) {
free_irq(pcdev-irq_emma, pcdev);
- clk_disable(pcdev-clk_emma);
+ clk_disable_unprepare(pcdev-clk_emma);
clk_put(pcdev-clk_emma);
iounmap(pcdev-base_emma);
release_mem_region(pcdev-res_emma-start,
resource_size(pcdev-res_emma));
@@ -1850,7 +1850,7 @@ static int __devexit mx2_camera_remove(struct
platform_device *pdev)
iounmap(pcdev-base_csi);
if (cpu_is_mx27()) {
- clk_disable(pcdev-clk_emma);
+ clk_disable_unprepare(pcdev-clk_emma);
clk_put(pcdev-clk_emma);
iounmap(pcdev-base_emma);
res = pcdev-res_emma;
--
1.7.1
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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 08/15] video: mx2_emmaprp: Use clk_prepare_enable/clk_disable_unprepare
On Fri, May 25, 2012 at 08:14:49PM -0300, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com Prepare the clock before enabling it. Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: linux-media@vger.kernel.org Signed-off-by: Fabio Estevam fabio.este...@freescale.com Acked-by: Sascha Hauer s.ha...@pengutronix.de --- drivers/media/video/mx2_emmaprp.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/mx2_emmaprp.c b/drivers/media/video/mx2_emmaprp.c index 0bd5815..b364557 100644 --- a/drivers/media/video/mx2_emmaprp.c +++ b/drivers/media/video/mx2_emmaprp.c @@ -800,7 +800,7 @@ static int emmaprp_open(struct file *file) return ret; } - clk_enable(pcdev-clk_emma); + clk_prepare_enable(pcdev-clk_emma); ctx-q_data[V4L2_M2M_SRC].fmt = formats[1]; ctx-q_data[V4L2_M2M_DST].fmt = formats[0]; @@ -816,7 +816,7 @@ static int emmaprp_release(struct file *file) dprintk(pcdev, Releasing instance %p\n, ctx); - clk_disable(pcdev-clk_emma); + clk_disable_unprepare(pcdev-clk_emma); v4l2_m2m_ctx_release(ctx-m2m_ctx); kfree(ctx); -- 1.7.1 -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: FW: OMAP 3 ISP
On Tue, May 29, 2012 at 10:15 AM, jean-philippe francois jp.franc...@cynove.com wrote: 2012/5/29 Alex Gershgorin al...@meprolight.com: Hi Ritesh, Please send in the future CC to laurent.pinch...@ideasonboard.com and linux-media@vger.kernel.org Hi Alex, I also started working with OMAP35x torpedo kit, I successful compile Linux 3.0 and ported on the board. Device is booting correctly but probe function in omap3isp module not getting called. Please help me You have relevant Kernel boot messages? You can also find information in media archives OMAP 3 ISP thread. Regards, Alex Hi, I had a similar problem with a 2.6.39 kernel, that was solved with a 3.2 kernel. When compiled as a module, the probe function was called, but was failing later. The single message I would see was ISP revision x.y found [1] When compiled in the kernel image, everything was fine. [1] http://lxr.linux.no/linux+v2.6.39.4/drivers/media/video/omap3isp/isp.c#L2103 I think with kernel version 3.0 i had the same problem, i had to modprobe iommu2 before omap3isp, removing (if already loaded) iommu. Probably later on it was fixed and you don't need that anymore. Laurent will know better. Enrico -- 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: FW: OMAP 3 ISP
Hi Enrico, On Tuesday 29 May 2012 12:08:43 Enrico wrote: On Tue, May 29, 2012 at 10:15 AM, jean-philippe francois wrote: 2012/5/29 Alex Gershgorin al...@meprolight.com: Hi Ritesh, Please send in the future CC to laurent.pinch...@ideasonboard.com and linux-media@vger.kernel.org Hi Alex, I also started working with OMAP35x torpedo kit, I successful compile Linux 3.0 and ported on the board. Device is booting correctly but probe function in omap3isp module not getting called. Please help me You have relevant Kernel boot messages? You can also find information in media archives OMAP 3 ISP thread. Regards, Alex Hi, I had a similar problem with a 2.6.39 kernel, that was solved with a 3.2 kernel. When compiled as a module, the probe function was called, but was failing later. The single message I would see was ISP revision x.y found [1] When compiled in the kernel image, everything was fine. [1] http://lxr.linux.no/linux+v2.6.39.4/drivers/media/video/omap3isp/isp.c#L2 103 I think with kernel version 3.0 i had the same problem, i had to modprobe iommu2 before omap3isp, removing (if already loaded) iommu. Probably later on it was fixed and you don't need that anymore. That's right. The OMAP3 ISP driver indirectly depended on the iommu2 module, which wasn't loaded automatically. Nowadays OMAP IOMMU support is a boolean option, so it will get compiled in the kernel directly. -- 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: [RFC/PATCH] media: Add stk1160 new driver
On Mon, May 28, 2012 at 7:22 AM, Hans Verkuil hverk...@xs4all.nl wrote: In practice it seems that the easiest approach is not to clean up anything in the disconnect, just take the lock, do the bare minimum necessary for the disconnect, unregister the video nodes, unlock and end with v4l2_device_put(v4l2_dev). It's a suggestion only, but experience has shown that it works well. And as I said, when you get multiple device nodes, then this is the only workable approach. I'm convinced: it's both cleaner and more logical to use v4l2_release instead of video_device release to the final cleanup. OK, the general rule is as follows (many drivers do not follow this correctly, BTW, but this is what should happen): - the filehandle that calls REQBUFS owns the buffers and is the only one that can start/stop streaming and queue/dequeue buffers. and read, poll, etc right? This is until REQBUFS with count == 0 is called, or until the filehandle is closed. Okey. But currently videobuf2 doesn't notify the driver when reqbufs with zero count has been called. So, I have to assume it (aka trouble ahead) or capture the zero count case before/after calling vb2_reqbufs (aka ugly). I humbly think that, if we wan't to enforce this behavior (as part of v4l2 driver semantics) then we should have videobuf2 tell the driver when reqbufs has been called with zero count. You can take a look at pwc which only drops owner on filehandle close, or uvc which captures this from vb2_reqbufs. After looking at uvc, now I wonder is it really ugly? or perhaps it's just ok. v4l2_device is a top-level struct, video_device represents a single device node. For cleanup purposes there isn't much difference between the two if you have only one device node. When you have more, then those differences are much more important. Yes, it's cleaner now. Thanks! Ezequiel. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] media: Add stk1160 new driver
On Tue 29 May 2012 14:05:08 Ezequiel Garcia wrote: On Mon, May 28, 2012 at 7:22 AM, Hans Verkuil hverk...@xs4all.nl wrote: In practice it seems that the easiest approach is not to clean up anything in the disconnect, just take the lock, do the bare minimum necessary for the disconnect, unregister the video nodes, unlock and end with v4l2_device_put(v4l2_dev). It's a suggestion only, but experience has shown that it works well. And as I said, when you get multiple device nodes, then this is the only workable approach. I'm convinced: it's both cleaner and more logical to use v4l2_release instead of video_device release to the final cleanup. OK, the general rule is as follows (many drivers do not follow this correctly, BTW, but this is what should happen): - the filehandle that calls REQBUFS owns the buffers and is the only one that can start/stop streaming and queue/dequeue buffers. and read, poll, etc right? Read yes, but anyone can poll. This is until REQBUFS with count == 0 is called, or until the filehandle is closed. Okey. But currently videobuf2 doesn't notify the driver when reqbufs with zero count has been called. So, I have to assume it (aka trouble ahead) or capture the zero count case before/after calling vb2_reqbufs (aka ugly). You just check the count after calling vb2_reqbufs. Nothing ugly about it. I humbly think that, if we wan't to enforce this behavior (as part of v4l2 driver semantics) then we should have videobuf2 tell the driver when reqbufs has been called with zero count. You can take a look at pwc which only drops owner on filehandle close, That's a bug. REQBUFS(0) must drop the owner: you've just released all resources related to streaming, so there is no reason to prevent others from using them. But I suspect 90% of all drivers do this wrong. Not to mention that the old videobuf doesn't handle a count of 0 at all, which is a complete violation of the spec. So an application never knows whether a count of 0 will work. Lovely... The qv4l2 test tool has some really ugly workaround for this :-) At some point I'm going to add a test for this to v4l2-compliance... or uvc which captures this from vb2_reqbufs. After looking at uvc, now I wonder is it really ugly? or perhaps it's just ok. It would be nice if this was somehow integrated into videobuf2, but not everyone liked the idea of vb2 using filehandle information from what I remember. But I didn't push for it very hard. v4l2_device is a top-level struct, video_device represents a single device node. For cleanup purposes there isn't much difference between the two if you have only one device node. When you have more, then those differences are much more important. Yes, it's cleaner now. Thanks! Ezequiel. Your welcome! Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
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:Tue May 29 19:00:17 CEST 2012 git hash:5472d3f17845c4398c6a510b46855820920c2181 gcc version: i686-linux-gcc (GCC) 4.6.3 host hardware:x86_64 host os: 3.3-6.slh.2-amd64 linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: WARNINGS 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-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 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 apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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: [RFC PATCH] omap3isp : fix cfa demosaicing for format other than GRBG
Hi Jean-Philippe, On Tuesday 29 May 2012 10:24:45 jean-philippe francois wrote: Hi, omap3 ISP previewer block can convert a raw bayer image into a UYVY image. Debayering coefficient are stored in an undocumented table. In the current form, only GRBG format are converted correctly. However, the other CFA arrangement can be transformed in GRBG arrangement by shifting the image window one pixel to the left or to the bottom. Here is a patch against vanilla 3.2.17, that was only tested with a BGGR arrangement. Is it the right way to fix this issue ? That's really a hack. I'd much rather support other Bayer orders properly by modifying the CFA coefficients table. The table is arranged as 4 blocks of 144 coefficients. If I'm not mistaken (I haven't tested it), the blocks should be arranged as follows: GRBG 0 1 2 3 RGGB 1 0 3 2 BGGR 2 3 0 1 GBRG 3 2 1 0 Would you be able to test that with your BGGR sensor ? If that's correct, it shouldn't be too difficult to modify the order dynamically based on the format. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] em28xx: Show a warning if the board does not support remote controls
This simply shows a little warning if the board does not have remote
control support. This should make it easier for users to see if they
have misconfigured their system or if the driver simply does not have
rc-support for their card (yet).
Signed-off-by: Martin Blumenstingl martin.blumensti...@googlemail.com
---
drivers/media/video/em28xx/em28xx-input.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/video/em28xx/em28xx-input.c
b/drivers/media/video/em28xx/em28xx-input.c
index fce5f76..d94b434 100644
--- a/drivers/media/video/em28xx/em28xx-input.c
+++ b/drivers/media/video/em28xx/em28xx-input.c
@@ -527,6 +527,9 @@ static int em28xx_ir_init(struct em28xx *dev)
if (dev-board.ir_codes == NULL) {
/* No remote control support */
+ printk(No remote control support for em28xx
+ card %s (model %d) available.\n,
+ dev-name, dev-model);
return 0;
}
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] em28xx: Show a warning if the board does not support remote controls
This simply shows a little warning if the board does not have remote
control support. This should make it easier for users to see if they
have misconfigured their system or if the driver simply does not have
rc-support for their card (yet).
Signed-off-by: Martin Blumenstingl martin.blumensti...@googlemail.com
---
drivers/media/video/em28xx/em28xx-input.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/video/em28xx/em28xx-input.c
b/drivers/media/video/em28xx/em28xx-input.c
index fce5f76..d94b434 100644
--- a/drivers/media/video/em28xx/em28xx-input.c
+++ b/drivers/media/video/em28xx/em28xx-input.c
@@ -527,6 +527,9 @@ static int em28xx_ir_init(struct em28xx *dev)
if (dev-board.ir_codes == NULL) {
/* No remote control support */
+ printk(No remote control support for em28xx
+ card %s (model %d) available.\n,
+ dev-name, dev-model);
return 0;
}
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] [media] em28xx: Add remote control support for Terratec's Cinergy HTC Stick HD
The Cinergy HTC Stick HD uses the same remote control as the TerraTec
Cinergy XS products. Thus the same keymap could be re-used.
Signed-off-by: Martin Blumenstingl martin.blumensti...@googlemail.com
---
drivers/media/video/em28xx/em28xx-cards.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index 20a7e24..92da7c2 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -974,6 +974,7 @@ struct em28xx_board em28xx_boards[] = {
[EM2884_BOARD_CINERGY_HTC_STICK] = {
.name = Terratec Cinergy HTC Stick,
.has_dvb = 1,
+ .ir_codes = RC_MAP_NEC_TERRATEC_CINERGY_XS,
#if 0
.tuner_type = TUNER_PHILIPS_TDA8290,
.tuner_addr = 0x41,
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] em28xx: Show a warning if the board does not support remote controls
This simply shows a little warning if the board does not have remote
control support. This should make it easier for users to see if they
have misconfigured their system or if the driver simply does not have
rc-support for their card (yet).
Signed-off-by: Martin Blumenstingl martin.blumensti...@googlemail.com
---
drivers/media/video/em28xx/em28xx-input.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/video/em28xx/em28xx-input.c
b/drivers/media/video/em28xx/em28xx-input.c
index fce5f76..d94b434 100644
--- a/drivers/media/video/em28xx/em28xx-input.c
+++ b/drivers/media/video/em28xx/em28xx-input.c
@@ -527,6 +527,9 @@ static int em28xx_ir_init(struct em28xx *dev)
if (dev-board.ir_codes == NULL) {
/* No remote control support */
+ printk(No remote control support for em28xx
+ card %s (model %d) available.\n,
+ dev-name, dev-model);
return 0;
}
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] em28xx: Show a warning if the board does not support remote controls
On Tue, May 29, 2012 at 6:08 PM, Martin Blumenstingl
martin.blumensti...@googlemail.com wrote:
This simply shows a little warning if the board does not have remote
control support. This should make it easier for users to see if they
have misconfigured their system or if the driver simply does not have
rc-support for their card (yet).
Signed-off-by: Martin Blumenstingl martin.blumensti...@googlemail.com
---
drivers/media/video/em28xx/em28xx-input.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/video/em28xx/em28xx-input.c
b/drivers/media/video/em28xx/em28xx-input.c
index fce5f76..d94b434 100644
--- a/drivers/media/video/em28xx/em28xx-input.c
+++ b/drivers/media/video/em28xx/em28xx-input.c
@@ -527,6 +527,9 @@ static int em28xx_ir_init(struct em28xx *dev)
if (dev-board.ir_codes == NULL) {
/* No remote control support */
+ printk(No remote control support for em28xx
+ card %s (model %d) available.\n,
+ dev-name, dev-model);
What about using dev_err instead?
--
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] [media] em28xx: Add remote control support for Terratec's Cinergy HTC Stick HD
Hello everyone,
sorry for the first reply - I messed up the git send-email command.
This is the correct version of the patch (including my signed-off-by
and a whitespace fix).
Regards,
Martin
On Tue, May 29, 2012 at 11:19 PM, Martin Blumenstingl
martin.blumensti...@googlemail.com wrote:
The Cinergy HTC Stick HD uses the same remote control as the TerraTec
Cinergy XS products. Thus the same keymap could be re-used.
Signed-off-by: Martin Blumenstingl martin.blumensti...@googlemail.com
---
drivers/media/video/em28xx/em28xx-cards.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index 20a7e24..92da7c2 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -974,6 +974,7 @@ struct em28xx_board em28xx_boards[] = {
[EM2884_BOARD_CINERGY_HTC_STICK] = {
.name = Terratec Cinergy HTC Stick,
.has_dvb = 1,
+ .ir_codes = RC_MAP_NEC_TERRATEC_CINERGY_XS,
#if 0
.tuner_type = TUNER_PHILIPS_TDA8290,
.tuner_addr = 0x41,
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] em28xx: Show a warning if the board does not support remote controls
Hello Fabio,
I can use dev_err if you want.
And sorry for sending the patch twice.
I messed up the git send-email command here - sorry for that.
Regards,
Martin
On Tue, May 29, 2012 at 11:22 PM, Fabio Estevam feste...@gmail.com wrote:
On Tue, May 29, 2012 at 6:08 PM, Martin Blumenstingl
martin.blumensti...@googlemail.com wrote:
This simply shows a little warning if the board does not have remote
control support. This should make it easier for users to see if they
have misconfigured their system or if the driver simply does not have
rc-support for their card (yet).
Signed-off-by: Martin Blumenstingl martin.blumensti...@googlemail.com
---
drivers/media/video/em28xx/em28xx-input.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/video/em28xx/em28xx-input.c
b/drivers/media/video/em28xx/em28xx-input.c
index fce5f76..d94b434 100644
--- a/drivers/media/video/em28xx/em28xx-input.c
+++ b/drivers/media/video/em28xx/em28xx-input.c
@@ -527,6 +527,9 @@ static int em28xx_ir_init(struct em28xx *dev)
if (dev-board.ir_codes == NULL) {
/* No remote control support */
+ printk(No remote control support for em28xx
+ card %s (model %d) available.\n,
+ dev-name, dev-model);
What about using dev_err instead?
--
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] em28xx: Show a warning if the board does not support remote controls
On Tue, May 29, 2012 at 6:26 PM, Martin Blumenstingl martin.blumensti...@googlemail.com wrote: Hello Fabio, I can use dev_err if you want. Or maybe dev_warn is better since this is a warning. -- 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] em28xx: Show a warning if the board does not support remote controls
What would you use as the first (dev) argument for dev_*? I simply tried using the USB-device (dev-udev-dev) there, and I think it's less descriptive if one removes the driver name and the board number: usb 1-1.2: Remote control support is not available for this device. What do you think about using dev_warn but still including the driver name and the board number? On Tue, May 29, 2012 at 11:28 PM, Fabio Estevam feste...@gmail.com wrote: On Tue, May 29, 2012 at 6:26 PM, Martin Blumenstingl martin.blumensti...@googlemail.com wrote: Hello Fabio, I can use dev_err if you want. Or maybe dev_warn is better since this is a warning. -- 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: Preliminary proposal, new APIs for HDMI and DVI control in v4l2
Martin Bugge (marbugge marbugge at cisco.com writes: This is a preliminary proposal for an extension to the v4l2 api. To be discussed at the V4L2 'brainstorming' meeting in Warsaw, March 2011 Purpose: Provide basic controls for HDMI and DVI devices. reposting the query since the earlier post did not appear in mailing list. Hi Martin, We are also in requirement of these controls as described by you. I did a search in the archives but could not find a suitable conclusion to the RFC. I could find that the dv_timings structure has been modified as a result of further discussions. But for many items like S_EDID, DV_CABLE_DETECT, Info frames etc , I could not find the logical conclusion to this RFC. Could please let me know the further updates on these requirements? Thanks in Advance Best Regards Soby Mathew -- 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
