Re: [PATCH v3][for_v3.5] media: mx2_camera: Fix mbus format handling
On 6 July 2012 14:55, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
Hi Javier
Thanks for the patch, and sorry for delay. I was away first 10 days of
June and still haven't come round to cleaning up my todo list since
then...
On Fri, 1 Jun 2012, Javier Martin wrote:
Remove MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB flags
so that the driver can negotiate with the attached sensor
whether the mbus format needs convertion from UYUV to YUYV
or not.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Fix pass-through mode as requested by Guennadi.
Also a merge conflict has been addressed.
This patch should be applied to for_v3.5 since Guennadi
has requested Mauro to remove the old version:
[PATCH] Revert [media] media: mx2_camera: Fix mbus format handling
This patch is part of the following series:
media: tvp5150: Fix mbus format.
i.MX27: visstrim_m10: Remove use of MX2_CAMERA_SWAP16.
media: mx2_camera: Fix mbus format handling.
---
arch/arm/plat-mxc/include/mach/mx2_cam.h |2 -
drivers/media/video/mx2_camera.c | 50
+++---
2 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/arch/arm/plat-mxc/include/mach/mx2_cam.h
b/arch/arm/plat-mxc/include/mach/mx2_cam.h
index 3c080a3..7ded6f1 100644
--- a/arch/arm/plat-mxc/include/mach/mx2_cam.h
+++ b/arch/arm/plat-mxc/include/mach/mx2_cam.h
@@ -23,7 +23,6 @@
#ifndef __MACH_MX2_CAM_H_
#define __MACH_MX2_CAM_H_
-#define MX2_CAMERA_SWAP16(1 0)
#define MX2_CAMERA_EXT_VSYNC (1 1)
#define MX2_CAMERA_CCIR (1 2)
#define MX2_CAMERA_CCIR_INTERLACE(1 3)
@@ -31,7 +30,6 @@
#define MX2_CAMERA_GATED_CLOCK (1 5)
#define MX2_CAMERA_INV_DATA (1 6)
#define MX2_CAMERA_PCLK_SAMPLE_RISING(1 7)
-#define MX2_CAMERA_PACK_DIR_MSB (1 8)
/**
* struct mx2_camera_platform_data - optional platform data for mx2_camera
diff --git a/drivers/media/video/mx2_camera.c
b/drivers/media/video/mx2_camera.c
index 18afaee..b30ebe5 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -344,6 +344,19 @@ static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
PRP_INTR_CH2OVF,
}
},
+ {
+ .in_fmt = V4L2_MBUS_FMT_UYVY8_2X8,
+ .out_fmt= V4L2_PIX_FMT_YUV420,
+ .cfg= {
+ .channel= 2,
+ .in_fmt = PRP_CNTL_DATA_IN_YUV422,
+ .out_fmt= PRP_CNTL_CH2_OUT_YUV420,
+ .src_pixel = 0x22000888, /* YUV422 (YUYV) */
+ .irq_flags = PRP_INTR_RDERR | PRP_INTR_CH2WERR |
+ PRP_INTR_CH2FC | PRP_INTR_LBOVF |
+ PRP_INTR_CH2OVF,
+ }
+ },
IIUC, this adds one more conversion from V4L2_MBUS_FMT_UYVY8_2X8 to
V4L2_PIX_FMT_YUV420.
Yes, that's exactly what this does.
};
static struct mx2_fmt_cfg *mx27_emma_prp_get_format(
@@ -980,6 +993,8 @@ static int mx2_camera_set_bus_param(struct
soc_camera_device *icd)
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
struct mx2_camera_dev *pcdev = ici-priv;
struct v4l2_mbus_config cfg = {.type = V4L2_MBUS_PARALLEL,};
+ const struct soc_camera_format_xlate *xlate;
+ u32 pixfmt = icd-current_fmt-host_fmt-fourcc;
unsigned long common_flags;
int ret;
int bytesperline;
@@ -1024,14 +1039,28 @@ static int mx2_camera_set_bus_param(struct
soc_camera_device *icd)
return ret;
}
+ xlate = soc_camera_xlate_by_fourcc(icd, pixfmt);
+ if (!xlate) {
+ dev_warn(icd-parent, Format %x not found\n, pixfmt);
+ return -EINVAL;
+ }
+
+ if (xlate-code == V4L2_MBUS_FMT_YUYV8_2X8) {
+ csicr1 |= CSICR1_PACK_DIR;
+ csicr1 = ~CSICR1_SWAP16_EN;
+ dev_dbg(icd-parent, already yuyv format, don't convert\n);
+ } else if (xlate-code == V4L2_MBUS_FMT_UYVY8_2X8) {
+ csicr1 = ~CSICR1_PACK_DIR;
+ csicr1 |= CSICR1_SWAP16_EN;
+ dev_dbg(icd-parent, convert uyvy mbus format into yuyv\n);
+ }
+
if (common_flags V4L2_MBUS_PCLK_SAMPLE_RISING)
csicr1 |= CSICR1_REDGE;
if (common_flags V4L2_MBUS_VSYNC_ACTIVE_HIGH)
csicr1 |= CSICR1_SOF_POL;
if (common_flags V4L2_MBUS_HSYNC_ACTIVE_HIGH)
csicr1 |= CSICR1_HSYNC_POL;
- if (pcdev-platform_flags MX2_CAMERA_SWAP16)
- csicr1 |= CSICR1_SWAP16_EN;
if (pcdev-platform_flags MX2_CAMERA_EXT_VSYNC)
csicr1 |= CSICR1_EXT_VSYNC;
if (pcdev-platform_flags MX2_CAMERA_CCIR)
@@ -1042,8 +1071,6 @@ static int mx2_camera_set_bus_param(struct
soc_camera_device
Re: [PATCH v3][for_v3.5] media: mx2_camera: Fix mbus format handling
On 6 July 2012 17:11, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
hmm... sorry again. It is my fault, that I left this patch without
attention for full 5 weeks, but I still don't have a sufficiently good
feeling about it. Look here:
On Fri, 6 Jul 2012, Guennadi Liakhovetski wrote:
Hi Javier
Thanks for the patch, and sorry for delay. I was away first 10 days of
June and still haven't come round to cleaning up my todo list since
then...
On Fri, 1 Jun 2012, Javier Martin wrote:
[snip]
@@ -1024,14 +1039,28 @@ static int mx2_camera_set_bus_param(struct
soc_camera_device *icd)
return ret;
}
+ xlate = soc_camera_xlate_by_fourcc(icd, pixfmt);
+ if (!xlate) {
+ dev_warn(icd-parent, Format %x not found\n, pixfmt);
+ return -EINVAL;
+ }
+
+ if (xlate-code == V4L2_MBUS_FMT_YUYV8_2X8) {
+ csicr1 |= CSICR1_PACK_DIR;
+ csicr1 = ~CSICR1_SWAP16_EN;
+ dev_dbg(icd-parent, already yuyv format, don't convert\n);
+ } else if (xlate-code == V4L2_MBUS_FMT_UYVY8_2X8) {
+ csicr1 = ~CSICR1_PACK_DIR;
+ csicr1 |= CSICR1_SWAP16_EN;
+ dev_dbg(icd-parent, convert uyvy mbus format into yuyv\n);
+ }
This doesn't look right. From V4L2_MBUS_FMT_YUYV8_2X8 you can produce two
output formats:
V4L2_PIX_FMT_YUV420 and
V4L2_PIX_FMT_YUYV
For both of them you set CSICR1_PACK_DIR, which wasn't the default before?
Next for V4L2_MBUS_FMT_UYVY8_2X8. From this one you can produce 3 formats:
V4L2_PIX_FMT_YUV420,
V4L2_PIX_FMT_YUYV and
V4L2_PIX_FMT_UYVY
For all 3 of them you now set CSICR1_SWAP16_EN. Are you sure all the above
is correct?
No, there's just one thing wrong. With this patch, pass-through mode
for V4L2_MBUS_FMT_UYVY8_2X8 won't work, since I always convert it to
YUYV.
Let me send a new version of the patch to address this problem.
Regards.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.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: pctv452e
On 08.07.2012 14:32, Antti Palosaari wrote: I suspect you stopped szap ? You cannot use dvbdate or dvbtraffic, nor read data from dvr0 unless frontend is tuned. Leave szap running backround and try again. That way it works, and I can save stream. Hovewer it's strange because I shouldn't have to constatly tune channel to watch it, and on previous cards it was enough to tune once and then use other commands. I base my knowledge on http://www.linuxtv.org/wiki/index.php/Testing_your_DVB_device There is nothing about constant tuning channel to use it. Am I missing something? Marx wuwek:/var/lib/vdr/kanaly# nohup ./szap-s2 -n 41 -r [1] 4888 wuwek:/var/lib/vdr/kanaly# nohup: zignorowanie wejścia i dołączenie wyników do `nohup.out' wuwek:/var/lib/vdr/kanaly# wuwek:/var/lib/vdr/kanaly# ps ax|grep szap 4888 pts/1S 0:00 ./szap-s2 -n 41 -r 4891 pts/1S+ 0:00 grep szap wuwek:/var/lib/vdr/kanaly# dvbdate Mon Jul 9 07:12:43 2012 wuwek:/var/lib/vdr/kanaly# dvbtraffic 9 p/s 1 kb/s14 kbit 0001 9 p/s 1 kb/s14 kbit 0011 1 p/s 0 kb/s 2 kbit 0014 0 p/s 0 kb/s 1 kbit 010429 p/s 5 kb/s44 kbit 010858 p/s10 kb/s88 kbit 010964 p/s11 kb/s97 kbit 0e04 309 p/s56 kb/s 465 kbit 0e77 228 p/s41 kb/s 343 kbit 0e7859 p/s10 kb/s90 kbit 17d5 2139 p/s 392 kb/s 3217 kbit 17df90 p/s16 kb/s 136 kbit 17e090 p/s16 kb/s 136 kbit 1831 4 p/s 0 kb/s 7 kbit 1832 9 p/s 1 kb/s14 kbit 1833 9 p/s 1 kb/s14 kbit 1834 4 p/s 0 kb/s 7 kbit 1836 9 p/s 1 kb/s14 kbit 1839 1247 p/s 228 kb/s 1876 kbit 184390 p/s16 kb/s 136 kbit 184490 p/s16 kb/s 136 kbit 1895 4 p/s 0 kb/s 7 kbit 1896 9 p/s 1 kb/s14 kbit 1897 9 p/s 1 kb/s14 kbit -- 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] [v3] i.MX27: Fix emma-prp clocks in mx2_camera.c
On Fri, Jul 06, 2012 at 12:56:02PM +0200, Javier Martin wrote:
This driver wasn't converted to the new clock changes
(clk_prepare_enable/clk_disable_unprepare). Also naming
of emma-prp related clocks for the i.MX27 was not correct.
---
Enable clocks only for i.MX27.
Indeed,
- pcdev-clk_csi = clk_get(pdev-dev, NULL);
- if (IS_ERR(pcdev-clk_csi)) {
- dev_err(pdev-dev, Could not get csi clock\n);
- err = PTR_ERR(pcdev-clk_csi);
- goto exit_kfree;
+ if (cpu_is_mx27()) {
+ pcdev-clk_csi = devm_clk_get(pdev-dev, ahb);
+ if (IS_ERR(pcdev-clk_csi)) {
+ dev_err(pdev-dev, Could not get csi clock\n);
+ err = PTR_ERR(pcdev-clk_csi);
+ goto exit_kfree;
+ }
but why? Now the i.MX25 won't get a clock anymore.
Sascha
--
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
[PATCH v4] media: mx2_camera: Fix mbus format handling
Remove MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB flags
so that the driver can negotiate with the attached sensor
whether the mbus format needs convertion from UYUV to YUYV
or not.
---
Changes since v3:
Do not provide pass-through for UYVY8.
---
arch/arm/plat-mxc/include/mach/mx2_cam.h |2 --
drivers/media/video/mx2_camera.c | 51 +++---
2 files changed, 46 insertions(+), 7 deletions(-)
diff --git a/arch/arm/plat-mxc/include/mach/mx2_cam.h
b/arch/arm/plat-mxc/include/mach/mx2_cam.h
index 3c080a3..7ded6f1 100644
--- a/arch/arm/plat-mxc/include/mach/mx2_cam.h
+++ b/arch/arm/plat-mxc/include/mach/mx2_cam.h
@@ -23,7 +23,6 @@
#ifndef __MACH_MX2_CAM_H_
#define __MACH_MX2_CAM_H_
-#define MX2_CAMERA_SWAP16 (1 0)
#define MX2_CAMERA_EXT_VSYNC (1 1)
#define MX2_CAMERA_CCIR(1 2)
#define MX2_CAMERA_CCIR_INTERLACE (1 3)
@@ -31,7 +30,6 @@
#define MX2_CAMERA_GATED_CLOCK (1 5)
#define MX2_CAMERA_INV_DATA(1 6)
#define MX2_CAMERA_PCLK_SAMPLE_RISING (1 7)
-#define MX2_CAMERA_PACK_DIR_MSB(1 8)
/**
* struct mx2_camera_platform_data - optional platform data for mx2_camera
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 11a9353..baa4ec2 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -345,6 +345,19 @@ static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
PRP_INTR_CH2OVF,
}
},
+ {
+ .in_fmt = V4L2_MBUS_FMT_UYVY8_2X8,
+ .out_fmt= V4L2_PIX_FMT_YUV420,
+ .cfg= {
+ .channel= 2,
+ .in_fmt = PRP_CNTL_DATA_IN_YUV422,
+ .out_fmt= PRP_CNTL_CH2_OUT_YUV420,
+ .src_pixel = 0x22000888, /* YUV422 (YUYV) */
+ .irq_flags = PRP_INTR_RDERR | PRP_INTR_CH2WERR |
+ PRP_INTR_CH2FC | PRP_INTR_LBOVF |
+ PRP_INTR_CH2OVF,
+ }
+ },
};
static struct mx2_fmt_cfg *mx27_emma_prp_get_format(
@@ -974,6 +987,8 @@ static int mx2_camera_set_bus_param(struct
soc_camera_device *icd)
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
struct mx2_camera_dev *pcdev = ici-priv;
struct v4l2_mbus_config cfg = {.type = V4L2_MBUS_PARALLEL,};
+ const struct soc_camera_format_xlate *xlate;
+ u32 pixfmt = icd-current_fmt-host_fmt-fourcc;
unsigned long common_flags;
int ret;
int bytesperline;
@@ -1018,14 +1033,28 @@ static int mx2_camera_set_bus_param(struct
soc_camera_device *icd)
return ret;
}
+ xlate = soc_camera_xlate_by_fourcc(icd, pixfmt);
+ if (!xlate) {
+ dev_warn(icd-parent, Format %x not found\n, pixfmt);
+ return -EINVAL;
+ }
+
+ if (xlate-code == V4L2_MBUS_FMT_YUYV8_2X8) {
+ csicr1 |= CSICR1_PACK_DIR;
+ csicr1 = ~CSICR1_SWAP16_EN;
+ dev_dbg(icd-parent, already yuyv format, don't convert\n);
+ } else if (xlate-code == V4L2_MBUS_FMT_UYVY8_2X8) {
+ csicr1 = ~CSICR1_PACK_DIR;
+ csicr1 |= CSICR1_SWAP16_EN;
+ dev_dbg(icd-parent, convert uyvy mbus format into yuyv\n);
+ }
+
if (common_flags V4L2_MBUS_PCLK_SAMPLE_RISING)
csicr1 |= CSICR1_REDGE;
if (common_flags V4L2_MBUS_VSYNC_ACTIVE_HIGH)
csicr1 |= CSICR1_SOF_POL;
if (common_flags V4L2_MBUS_HSYNC_ACTIVE_HIGH)
csicr1 |= CSICR1_HSYNC_POL;
- if (pcdev-platform_flags MX2_CAMERA_SWAP16)
- csicr1 |= CSICR1_SWAP16_EN;
if (pcdev-platform_flags MX2_CAMERA_EXT_VSYNC)
csicr1 |= CSICR1_EXT_VSYNC;
if (pcdev-platform_flags MX2_CAMERA_CCIR)
@@ -1036,8 +1065,6 @@ static int mx2_camera_set_bus_param(struct
soc_camera_device *icd)
csicr1 |= CSICR1_GCLK_MODE;
if (pcdev-platform_flags MX2_CAMERA_INV_DATA)
csicr1 |= CSICR1_INV_DATA;
- if (pcdev-platform_flags MX2_CAMERA_PACK_DIR_MSB)
- csicr1 |= CSICR1_PACK_DIR;
pcdev-csicr1 = csicr1;
@@ -1112,7 +1139,8 @@ static int mx2_camera_get_formats(struct
soc_camera_device *icd,
return 0;
}
- if (code == V4L2_MBUS_FMT_YUYV8_2X8) {
+ if (code == V4L2_MBUS_FMT_YUYV8_2X8 ||
+ code == V4L2_MBUS_FMT_UYVY8_2X8) {
formats++;
if (xlate) {
/*
@@ -1128,6 +1156,19 @@ static int mx2_camera_get_formats(struct
soc_camera_device *icd,
}
}
+ if (code == V4L2_MBUS_FMT_UYVY8_2X8) {
+ formats++;
+ if (xlate) {
Re: [PATCH] [v3] i.MX27: Fix emma-prp clocks in mx2_camera.c
On 9 July 2012 09:28, Sascha Hauer s.ha...@pengutronix.de wrote:
On Fri, Jul 06, 2012 at 12:56:02PM +0200, Javier Martin wrote:
This driver wasn't converted to the new clock changes
(clk_prepare_enable/clk_disable_unprepare). Also naming
of emma-prp related clocks for the i.MX27 was not correct.
---
Enable clocks only for i.MX27.
Indeed,
- pcdev-clk_csi = clk_get(pdev-dev, NULL);
- if (IS_ERR(pcdev-clk_csi)) {
- dev_err(pdev-dev, Could not get csi clock\n);
- err = PTR_ERR(pcdev-clk_csi);
- goto exit_kfree;
+ if (cpu_is_mx27()) {
+ pcdev-clk_csi = devm_clk_get(pdev-dev, ahb);
+ if (IS_ERR(pcdev-clk_csi)) {
+ dev_err(pdev-dev, Could not get csi clock\n);
+ err = PTR_ERR(pcdev-clk_csi);
+ goto exit_kfree;
+ }
but why? Now the i.MX25 won't get a clock anymore.
What are the clocks needed by i.MX25? csi only?
By the way, is anybody using this driver with i.MX25?
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.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] [v3] i.MX27: Fix emma-prp clocks in mx2_camera.c
On Mon, Jul 09, 2012 at 09:37:25AM +0200, javier Martin wrote:
On 9 July 2012 09:28, Sascha Hauer s.ha...@pengutronix.de wrote:
On Fri, Jul 06, 2012 at 12:56:02PM +0200, Javier Martin wrote:
This driver wasn't converted to the new clock changes
(clk_prepare_enable/clk_disable_unprepare). Also naming
of emma-prp related clocks for the i.MX27 was not correct.
---
Enable clocks only for i.MX27.
Indeed,
- pcdev-clk_csi = clk_get(pdev-dev, NULL);
- if (IS_ERR(pcdev-clk_csi)) {
- dev_err(pdev-dev, Could not get csi clock\n);
- err = PTR_ERR(pcdev-clk_csi);
- goto exit_kfree;
+ if (cpu_is_mx27()) {
+ pcdev-clk_csi = devm_clk_get(pdev-dev, ahb);
+ if (IS_ERR(pcdev-clk_csi)) {
+ dev_err(pdev-dev, Could not get csi clock\n);
+ err = PTR_ERR(pcdev-clk_csi);
+ goto exit_kfree;
+ }
but why? Now the i.MX25 won't get a clock anymore.
What are the clocks needed by i.MX25? csi only?
By the way, is anybody using this driver with i.MX25?
It seems Baruch (added to Cc) has used it on an i.MX25.
Sascha
--
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] [v3] i.MX27: Fix emma-prp clocks in mx2_camera.c
On 9 July 2012 09:43, Sascha Hauer s.ha...@pengutronix.de wrote:
On Mon, Jul 09, 2012 at 09:37:25AM +0200, javier Martin wrote:
On 9 July 2012 09:28, Sascha Hauer s.ha...@pengutronix.de wrote:
On Fri, Jul 06, 2012 at 12:56:02PM +0200, Javier Martin wrote:
This driver wasn't converted to the new clock changes
(clk_prepare_enable/clk_disable_unprepare). Also naming
of emma-prp related clocks for the i.MX27 was not correct.
---
Enable clocks only for i.MX27.
Indeed,
- pcdev-clk_csi = clk_get(pdev-dev, NULL);
- if (IS_ERR(pcdev-clk_csi)) {
- dev_err(pdev-dev, Could not get csi clock\n);
- err = PTR_ERR(pcdev-clk_csi);
- goto exit_kfree;
+ if (cpu_is_mx27()) {
+ pcdev-clk_csi = devm_clk_get(pdev-dev, ahb);
+ if (IS_ERR(pcdev-clk_csi)) {
+ dev_err(pdev-dev, Could not get csi clock\n);
+ err = PTR_ERR(pcdev-clk_csi);
+ goto exit_kfree;
+ }
but why? Now the i.MX25 won't get a clock anymore.
What are the clocks needed by i.MX25? csi only?
By the way, is anybody using this driver with i.MX25?
It seems Baruch (added to Cc) has used it on an i.MX25.
Baruch,
could you tell us what are the clocks needed by i.MX25?
Regards.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.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] [v3] i.MX27: Fix emma-prp clocks in mx2_camera.c
Hi Javier,
On Mon, Jul 09, 2012 at 09:46:03AM +0200, javier Martin wrote:
On 9 July 2012 09:43, Sascha Hauer s.ha...@pengutronix.de wrote:
On Mon, Jul 09, 2012 at 09:37:25AM +0200, javier Martin wrote:
On 9 July 2012 09:28, Sascha Hauer s.ha...@pengutronix.de wrote:
On Fri, Jul 06, 2012 at 12:56:02PM +0200, Javier Martin wrote:
This driver wasn't converted to the new clock changes
(clk_prepare_enable/clk_disable_unprepare). Also naming
of emma-prp related clocks for the i.MX27 was not correct.
---
Enable clocks only for i.MX27.
Indeed,
- pcdev-clk_csi = clk_get(pdev-dev, NULL);
- if (IS_ERR(pcdev-clk_csi)) {
- dev_err(pdev-dev, Could not get csi clock\n);
- err = PTR_ERR(pcdev-clk_csi);
- goto exit_kfree;
+ if (cpu_is_mx27()) {
+ pcdev-clk_csi = devm_clk_get(pdev-dev, ahb);
+ if (IS_ERR(pcdev-clk_csi)) {
+ dev_err(pdev-dev, Could not get csi clock\n);
+ err = PTR_ERR(pcdev-clk_csi);
+ goto exit_kfree;
+ }
but why? Now the i.MX25 won't get a clock anymore.
What are the clocks needed by i.MX25? csi only?
By the way, is anybody using this driver with i.MX25?
It seems Baruch (added to Cc) has used it on an i.MX25.
could you tell us what are the clocks needed by i.MX25?
According to the code the csi clock is sufficient for i.MX25. Unfortunately I
don't have access to a running system anymore, so I can't test current code.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
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] [v3] i.MX27: Fix emma-prp clocks in mx2_camera.c
On Mon, Jul 09, 2012 at 09:46:03AM +0200, javier Martin wrote:
On 9 July 2012 09:43, Sascha Hauer s.ha...@pengutronix.de wrote:
On Mon, Jul 09, 2012 at 09:37:25AM +0200, javier Martin wrote:
On 9 July 2012 09:28, Sascha Hauer s.ha...@pengutronix.de wrote:
On Fri, Jul 06, 2012 at 12:56:02PM +0200, Javier Martin wrote:
This driver wasn't converted to the new clock changes
(clk_prepare_enable/clk_disable_unprepare). Also naming
of emma-prp related clocks for the i.MX27 was not correct.
---
Enable clocks only for i.MX27.
Indeed,
- pcdev-clk_csi = clk_get(pdev-dev, NULL);
- if (IS_ERR(pcdev-clk_csi)) {
- dev_err(pdev-dev, Could not get csi clock\n);
- err = PTR_ERR(pcdev-clk_csi);
- goto exit_kfree;
+ if (cpu_is_mx27()) {
+ pcdev-clk_csi = devm_clk_get(pdev-dev, ahb);
+ if (IS_ERR(pcdev-clk_csi)) {
+ dev_err(pdev-dev, Could not get csi clock\n);
+ err = PTR_ERR(pcdev-clk_csi);
+ goto exit_kfree;
+ }
but why? Now the i.MX25 won't get a clock anymore.
What are the clocks needed by i.MX25? csi only?
By the way, is anybody using this driver with i.MX25?
It seems Baruch (added to Cc) has used it on an i.MX25.
Baruch,
could you tell us what are the clocks needed by i.MX25?
I just had a look and the i.MX25 it needs three clocks: ipg, ahb and
peripheral clock. So this is broken anyway and should probably be fixed
seperately, that is:
- provide dummy clocks for the csi clocks on i.MX27
- clk_get ipg, ahb and peripheral clocks on all SoCs
- clk_get emma clocks on i.MX27 only
As said, this is a separate topic, so your original patch should be fine
for now.
Sascha
--
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 2/3] media: coda: Add driver for Coda video codec.
Am Montag, den 09.07.2012, 10:07 +0200 schrieb javier Martin:
[...]
+static int vidioc_s_parm(struct file *file, void *priv, struct
v4l2_streamparm *a)
+{
+ struct coda_ctx *ctx = fh_to_ctx(priv);
+
+ if (a-type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
+ if (a-parm.output.timeperframe.numerator != 1) {
+ v4l2_err(ctx-dev-v4l2_dev,
+ FPS numerator must be 1\n);
+ return -EINVAL;
+ }
+ ctx-params.framerate =
+
a-parm.output.timeperframe.denominator;
+ } else {
+ v4l2_err(ctx-dev-v4l2_dev,
+ Setting FPS is only possible for the output
queue\n);
+ return -EINVAL;
Why disallow setting timeperframe on the capture side? Shouldn't it
rather succeed without setting anything and return the current context's
frame rate instead?
+ }
+ return 0;
+}
+
+static int vidioc_g_parm(struct file *file, void *priv, struct
v4l2_streamparm *a)
+{
+ struct coda_ctx *ctx = fh_to_ctx(priv);
+
+ if (a-type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
+ a-parm.output.timeperframe.denominator =
+ ctx-params.framerate;
+ a-parm.output.timeperframe.numerator = 1;
+ } else {
+ v4l2_err(ctx-dev-v4l2_dev,
+ Getting FPS is only possible for the output
queue\n);
The nominal capture side timeperframe should match that of the output
side.
Actually, I'm not sure if this needs to be implemented at all, since
V4L2_CAP_TIMEPERFRAME is not set and capture frame dropping / output
frame duplication is not supported.
I am just following the steps of Samsung here:
http://lxr.linux.no/#linux+v3.4.4/drivers/media/video/s5p-mfc/s5p_mfc_enc.c#L1439
http://lxr.linux.no/#linux+v3.4.4/drivers/media/video/s5p-mfc/s5p_mfc_opr.c#L775
I don't think this is completely correct either. According to the V4L2
spec, setting timeperframe from an application is meant to make the
driver skip or duplicate frames to save bandwidth:
http://v4l2spec.bytesex.org/spec-single/v4l2.html#VIDIOC-G-PARM
So returning -EINVAL is not necessarily incorrect, as we can choose not
to support this ioctl - but claiming support for the output side (and
then doing nothing) but returning an error on the capture side seems a
bit inconsistent to me.
regards
Philipp
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] media: coda: Add driver for Coda video codec.
On 9 July 2012 10:19, Philipp Zabel p.za...@pengutronix.de wrote:
Am Montag, den 09.07.2012, 10:07 +0200 schrieb javier Martin:
[...]
+static int vidioc_s_parm(struct file *file, void *priv, struct
v4l2_streamparm *a)
+{
+ struct coda_ctx *ctx = fh_to_ctx(priv);
+
+ if (a-type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
+ if (a-parm.output.timeperframe.numerator != 1) {
+ v4l2_err(ctx-dev-v4l2_dev,
+ FPS numerator must be 1\n);
+ return -EINVAL;
+ }
+ ctx-params.framerate =
+
a-parm.output.timeperframe.denominator;
+ } else {
+ v4l2_err(ctx-dev-v4l2_dev,
+ Setting FPS is only possible for the output
queue\n);
+ return -EINVAL;
Why disallow setting timeperframe on the capture side? Shouldn't it
rather succeed without setting anything and return the current context's
frame rate instead?
+ }
+ return 0;
+}
+
+static int vidioc_g_parm(struct file *file, void *priv, struct
v4l2_streamparm *a)
+{
+ struct coda_ctx *ctx = fh_to_ctx(priv);
+
+ if (a-type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
+ a-parm.output.timeperframe.denominator =
+ ctx-params.framerate;
+ a-parm.output.timeperframe.numerator = 1;
+ } else {
+ v4l2_err(ctx-dev-v4l2_dev,
+ Getting FPS is only possible for the output
queue\n);
The nominal capture side timeperframe should match that of the output
side.
Actually, I'm not sure if this needs to be implemented at all, since
V4L2_CAP_TIMEPERFRAME is not set and capture frame dropping / output
frame duplication is not supported.
I am just following the steps of Samsung here:
http://lxr.linux.no/#linux+v3.4.4/drivers/media/video/s5p-mfc/s5p_mfc_enc.c#L1439
http://lxr.linux.no/#linux+v3.4.4/drivers/media/video/s5p-mfc/s5p_mfc_opr.c#L775
I don't think this is completely correct either. According to the V4L2
spec, setting timeperframe from an application is meant to make the
driver skip or duplicate frames to save bandwidth:
http://v4l2spec.bytesex.org/spec-single/v4l2.html#VIDIOC-G-PARM
So returning -EINVAL is not necessarily incorrect, as we can choose not
to support this ioctl - but claiming support for the output side (and
then doing nothing) but returning an error on the capture side seems a
bit inconsistent to me.
I'll remove it since we don't use it either way.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.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 2/3] media: coda: Add driver for Coda video codec.
Am Montag, den 09.07.2012, 10:14 +0200 schrieb javier Martin:
[...]
+enum coda_platform {
+ CODA_INVALID = 0,
I don't think CODA_INVALID is useful.
It is, otherwise the following will fail since CODA_IMX27 is 0:
if (of_id)
dev-devtype = of_id-data;
else if (pdev_id pdev_id-driver_data) -
pdev_id-driver_data = CODA_IMX27 = 0
dev-devtype = coda_devdata[pdev_id-driver_data];
else
return -EINVAL;
Oh, right. I think it should be ok to just remove the
pdev_id-driver_data check.
Since it's all in the same source file, it's unlikely that somebody adds
a platform_device_id to coda_platform_ids array but forgets to set
the .driver_data field.
regards
Philipp
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-3.5 ] Fix sn9c20x regression (was [regression 3.4-3.5, bisected] kernel oops when starting capturing from gspca-sn9c20x webcams)
Hi Linus, I'm sending this patch (attached) directly to you, since it fixes a regression in 3.5-rc6, and Mauro is on vacation. Please add this to the next 3.5 rc. Thanks Regards, Hans On 07/08/2012 10:04 PM, Frank Schäfer wrote: Am 08.07.2012 19:43, schrieb Hans de Goede: Hi, Thanks for reporting this! On 07/08/2012 06:25 PM, Frank Schäfer wrote: Hi, running kernel 3.5.rc6 with the two gspca-sn9c20x webcams 0c45:62b3 Microdia PC Camera with Microphone (SN9C202 + OV9655) 0c45:6270 Microdia PC Camera (SN9C201 + MI0360/MT9V011 or MI0360SOC/MT9V111) U-CAM PC Camera NE878, Whitcom WHC017, ... I'm getting the following kernel oops when I start capturing with qv4l2 (and also Kopete and others): [ 81.719973] gspca_sn9c20x: Set 640x480 [ 81.736805] BUG: unable to handle kernel NULL pointer dereference at 002c [ 81.736877] IP: [f7aebb59] v4l2_ctrl_g_ctrl+0x9/0x50 [videodev] [ 81.736901] *pdpt = 2c4fa001 *pde = [ 81.736922] Oops: [#1] PREEMPT SMP [ 81.737055] [ 81.737071] Pid: 4026, comm: qv4l2 Not tainted 3.4.0-0.1-desktop+ #19 System manufacturer System Product Name/M2N-VM DH [ 81.737101] EIP: 0060:[f7aebb59] EFLAGS: 00010292 CPU: 1 [ 81.737130] EIP is at v4l2_ctrl_g_ctrl+0x9/0x50 [videodev] [ 81.737147] EAX: EBX: ECX: f6c000c0 EDX: 0001 [ 81.737165] ESI: 0028 EDI: 0028 EBP: f5af9c84 ESP: f5af9c7c [ 81.737183] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 81.737200] CR0: 80050033 CR2: 002c CR3: 2c941000 CR4: 07f0 [ 81.737219] DR0: DR1: DR2: DR3: [ 81.737236] DR6: 0ff0 DR7: 0400 [ 81.737252] Process qv4l2 (pid: 4026, ti=f5af8000 task=f594c030 task.ti=f5af8000) [ 81.737271] Stack: [ 81.737290] 0028 f61c2000 f5af9cd0 f7d1c74c 007f f5af9ca4 c0586ba1 [ 81.737318] ef190444 007f 0080 01e0 0280 0002 02000100 [ 81.737346] 003c2800 00f000a0 f61c2000 f5af9d84 f7b682c0 f71d8bec [ 81.737366] Call Trace: [ 81.737390] [f7d1c74c] sd_start+0x2dc/0x450 [gspca_sn9c20x] [ 81.737421] [c0586ba1] ? usb_alloc_coherent+0x21/0x30 [ 81.737448] [f7b682c0] gspca_init_transfer+0x260/0x420 [gspca_main] [ 81.737479] [c02ea322] ? __alloc_pages_nodemask+0x142/0x7b0 [ 81.737504] [f7b6926b] vidioc_streamon+0x9b/0xb0 [gspca_main] [ 81.737535] [f7ae4919] __video_do_ioctl+0x2ba9/0x5780 [videodev] [ 81.737565] [c031b7ee] ? alloc_pages_current+0x8e/0x100 [ 81.737588] [c0230998] ? kmap_atomic_prot+0xe8/0x110 [ 81.737611] [c04824ea] ? __copy_from_user_ll+0x1a/0x30 [ 81.737630] [c0482530] ? _copy_from_user+0x30/0x50 [ 81.737656] [f7ae1b0e] video_usercopy+0x1de/0x270 [videodev] [ 81.737679] [c0309fc8] ? mmap_region+0x1e8/0x4b0 [ 81.737706] [f7ae1bb2] video_ioctl2+0x12/0x20 [videodev] [ 81.737725] [f7ae1d70] ? v4l2_norm_to_name+0x50/0x50 [videodev] [ 81.737725] [f7ae064a] v4l2_ioctl+0xca/0x190 [videodev] [ 81.737725] [c030a401] ? do_mmap_pgoff+0x171/0x2e0 [ 81.737725] [f7ae0580] ? v4l2_open+0x120/0x120 [videodev] [ 81.737725] [c0344074] do_vfs_ioctl+0x74/0x2e0 [ 81.737725] [c0344347] sys_ioctl+0x67/0x80 [ 81.737725] [c07242dd] syscall_call+0x7/0xb [ 81.737725] Code: 55 f0 89 02 8b 46 10 8b 40 14 e8 03 61 c3 c8 89 f8 83 c4 04 5b 5e 5f 5d c3 89 f6 8d bc 27 00 00 00 00 55 89 e5 53 89 c3 83 ec 04 8b 40 2c c7 45 f8 00 00 00 00 8d 50 fb 83 fa 02 77 09 80 b8 d3 [ 81.737725] EIP: [f7aebb59] v4l2_ctrl_g_ctrl+0x9/0x50 [videodev] SS:ESP 0068:f5af9c7c [ 81.737725] CR2: 002c [ 81.743027] ---[ end trace 1c291740d69b151f ]--- This is a regression from kernel 3.4.x. The causing commit seems to be commit 63069da1c8ef0abcdb74b0ea1c461d23fb9181d9 Author: Hans Verkuil hans.verk...@cisco.com Date: Sun May 6 09:28:29 2012 -0300 [media] gcpca_sn9c20x: Convert to the control framework HdG: Small fix: don't register some controls for sensors which don't have an implementation for them. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans de Goede hdego...@redhat.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Should I open a bug report at bugzilla, too ? That won't be necessary, the attached patch should fix this, can you give it a try please? Thank you Hans, I can confirm that your patch fixes the oops for both devices. Regards, Frank Thanks, Hans From e3d5933cf00270768b202041adf463ffc4fc9544 Mon Sep 17 00:00:00 2001 From: Hans de Goede hdego...@redhat.com Date: Sun, 8 Jul 2012 19:41:14 +0200 Subject: [PATCH] gspca_sn9c20x: Fix NULL pointer dereference MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Don't call v4l2_ctrl_g_ctrl on ctrls which the model cam in question does not have. Reported-by: Frank Schäfer fschaefer@googlemail.com Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/media/video/gspca/sn9c20x.c | 13
Re: pctv452e
On 07/09/2012 09:24 AM, Marx wrote:
On 08.07.2012 14:32, Antti Palosaari wrote:
I suspect you stopped szap ?
You cannot use dvbdate or dvbtraffic, nor read data from dvr0 unless
frontend is tuned. Leave szap running backround and try again.
That way it works, and I can save stream. Hovewer it's strange because I
shouldn't have to constatly tune channel to watch it, and on previous
cards it was enough to tune once and then use other commands.
I base my knowledge on
http://www.linuxtv.org/wiki/index.php/Testing_your_DVB_device
There is nothing about constant tuning channel to use it. Am I missing
something?
given wiki-page says:
4. After you've tuned a frequency and program
a) You could now start up your simple TV watching application and decode
the stream you have tuned.
For example, while keeping {a,c,s,t}zap running in the first console
shell, open up another console and run
Behavior have been always same, at least for the DVB USB.
So you don't have problems at all?
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: video: USB webcam fails since kernel 3.2
Hi, On 07/08/2012 08:33 PM, Jean-Francois Moine wrote: On Sun, 08 Jul 2012 19:58:08 +0200 Hans de Goede hdego...@redhat.com wrote: Hmm, this is then likely caused by the new isoc bandwidth negotiation code in 3.2, unfortunately the vc032x driver is one of the few gspca drivers for which I don't have a cam to test with. Can you try to build your own kernel from source? Hi Martin-Éric, Instead of re-building the gspca driver from a kernel source, you may try the gspca test tarball from my web site http://moinejf.free.fr/gspca-2.15.18.tar.gz That is a good option too and easier then building a whole new kernel, but: It contains most of the bug fixes, including the one about the bandwidth problem. Right, but the problem with the vc032x driver is that there no bandwidth related bugfix for it yet, which is why I asked Martin-Éric, not only to build a new gspca driver from source, but also to try some modifications. Martin-Éric, Building the gspca test-tarbal also is a good way to test this: http://moinejf.free.fr/gspca-2.15.18.tar.gz But once you've confirmed the problem still happens with that version you will still need to try the changes I suggested to gspca.c to help us confirm that this is a bandwidth issue and try to come up with a fix. Thanks 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
[PATCH v2 3/3] Visstrim M10: Add support for Coda.
Support the codadx6 that is included in
the i.MX27 SoC.
---
Changes since v1:
- Use 'arm_memblock_steal'.
---
arch/arm/mach-imx/mach-imx27_visstrim_m10.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
index f76edb9..214e4ff 100644
--- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
+++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
@@ -32,12 +32,12 @@
#include linux/delay.h
#include linux/dma-mapping.h
#include linux/leds.h
-#include linux/memblock.h
#include media/soc_camera.h
#include sound/tlv320aic32x4.h
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/time.h
+#include asm/memblock.h
#include asm/system.h
#include mach/common.h
#include mach/iomux-mx27.h
@@ -232,10 +232,8 @@ static void __init visstrim_camera_init(void)
static void __init visstrim_reserve(void)
{
/* reserve 4 MiB for mx2-camera */
- mx2_camera_base = memblock_alloc(MX2_CAMERA_BUF_SIZE,
+ mx2_camera_base = arm_memblock_steal(2 * MX2_CAMERA_BUF_SIZE,
MX2_CAMERA_BUF_SIZE);
- memblock_free(mx2_camera_base, MX2_CAMERA_BUF_SIZE);
- memblock_remove(mx2_camera_base, MX2_CAMERA_BUF_SIZE);
}
/* GPIOs used as events for applications */
@@ -404,6 +402,23 @@ static const struct imx_ssi_platform_data
visstrim_m10_ssi_pdata __initconst = {
.flags = IMX_SSI_DMA | IMX_SSI_SYN,
};
+/* coda */
+
+static void __init visstrim_coda_init(void)
+{
+ struct platform_device *pdev;
+ int dma;
+
+ pdev = imx27_add_coda();
+ dma = dma_declare_coherent_memory(pdev-dev,
+ mx2_camera_base + MX2_CAMERA_BUF_SIZE,
+ mx2_camera_base + MX2_CAMERA_BUF_SIZE,
+ MX2_CAMERA_BUF_SIZE,
+ DMA_MEMORY_MAP |
DMA_MEMORY_EXCLUSIVE);
+ if (!(dma DMA_MEMORY_MAP))
+ return;
+}
+
static void __init visstrim_m10_revision(void)
{
int exp_version = 0;
@@ -467,6 +482,7 @@ static void __init visstrim_m10_board_init(void)
iclink_tvp5150, sizeof(iclink_tvp5150));
gpio_led_register_device(0, visstrim_m10_led_data);
visstrim_camera_init();
+ visstrim_coda_init();
}
static void __init visstrim_m10_timer_init(void)
--
1.7.9.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
Re: [PATCH 4/4] radio-si470x: Lower firmware version requirements
On 07/07/2012 09:53 PM, Hans de Goede wrote: Hi, On 07/07/2012 11:00 AM, Antti Palosaari wrote: Hello Hans, On 07/07/2012 10:58 AM, Hans de Goede wrote: So is your device working properly now? The reason I'm asking it because it is still causing a firmware version warning, and if it works fine I would like to lower the firmware version warning point, so that the warning goes away. I don't know what is definition of properly in that case. Problem is that when I use radio application from xawtv3 with that new loopback I hear very often cracks and following errors are printed to the radio screen: ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred or ALSA lib pcm.c:7339:(snd_pcm_recover) overrun occurred Looks like those does not appear, at least it does not crack so often nor errors seen, when I use Rhythmbox to tune and arecord -D hw:2,0 -r96000 -c2 -f S16_LE | aplay - to listen. I can guess those are not firmware related so warning texts could be removed. Actually they may very well be firmware related. At least with my firmware there is a bug where actively asking the device for its register contents, it lets its audio stream drop. My patches fix this by waiting for the device to volunteer it register contents through its usb interrupt in endpoint, which it does at xx times / sec. So the first question would be, does this dropping of sound happen approx 1 / sec when using radio? If so this is caused by radio upating the signal strength it displays 1 / sec. If you look at radio.c line 981 you will see a radio_getsignal_n_stereo(fd); call there in the main loop which gets called 1/sec. Try commenting this out. If commenting this out fixes your sound issues with radio, then the next question is are you using my 4 recent si470x patches, if not please give them a try. If you are already using them then I'm afraid that your older firmware may be broken even more then my also not so new firmware. I suspect these signal strength update pops are different thing. Those are almost so minor you cannot even hear. I recorded small sample: http://palosaari.fi/linux/v4l-dvb/xawtv3_radio.m4v And I am almost 100% sure those cracks are coming ALSA underrun/overrun as error text is seen just same time when crack happens. Commenting out line did not help. But I think I was also hearing those small pops too and likely new four patches fixes those - but it is hard to say because it cracks audio all time. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] v4l: Export v4l2-common.h in include/linux/Kbuild
v4l2-common.h is a header file that's used in user space, thus it must be exported using header-y. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- Hi Stephen, Could you try is this patch fixes your issue? The header file indeed should be exported which wasn't done previously. include/linux/Kbuild |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/linux/Kbuild b/include/linux/Kbuild index d38b3a8..ef4cc94 100644 --- a/include/linux/Kbuild +++ b/include/linux/Kbuild @@ -382,6 +382,7 @@ header-y += usbdevice_fs.h header-y += utime.h header-y += utsname.h header-y += uvcvideo.h +header-y += v4l2-common.h header-y += v4l2-dv-timings.h header-y += v4l2-mediabus.h header-y += v4l2-subdev.h -- 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
Re: [PATCH 4/4] radio-si470x: Lower firmware version requirements
Hi, On 07/09/2012 11:17 AM, Antti Palosaari wrote: On 07/07/2012 09:53 PM, Hans de Goede wrote: Hi, On 07/07/2012 11:00 AM, Antti Palosaari wrote: Hello Hans, On 07/07/2012 10:58 AM, Hans de Goede wrote: So is your device working properly now? The reason I'm asking it because it is still causing a firmware version warning, and if it works fine I would like to lower the firmware version warning point, so that the warning goes away. I don't know what is definition of properly in that case. Problem is that when I use radio application from xawtv3 with that new loopback I hear very often cracks and following errors are printed to the radio screen: ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred or ALSA lib pcm.c:7339:(snd_pcm_recover) overrun occurred Looks like those does not appear, at least it does not crack so often nor errors seen, when I use Rhythmbox to tune and arecord -D hw:2,0 -r96000 -c2 -f S16_LE | aplay - to listen. I can guess those are not firmware related so warning texts could be removed. Actually they may very well be firmware related. At least with my firmware there is a bug where actively asking the device for its register contents, it lets its audio stream drop. My patches fix this by waiting for the device to volunteer it register contents through its usb interrupt in endpoint, which it does at xx times / sec. So the first question would be, does this dropping of sound happen approx 1 / sec when using radio? If so this is caused by radio upating the signal strength it displays 1 / sec. If you look at radio.c line 981 you will see a radio_getsignal_n_stereo(fd); call there in the main loop which gets called 1/sec. Try commenting this out. If commenting this out fixes your sound issues with radio, then the next question is are you using my 4 recent si470x patches, if not please give them a try. If you are already using them then I'm afraid that your older firmware may be broken even more then my also not so new firmware. I suspect these signal strength update pops are different thing. Those are almost so minor you cannot even hear. I recorded small sample: http://palosaari.fi/linux/v4l-dvb/xawtv3_radio.m4v And I am almost 100% sure those cracks are coming ALSA underrun/overrun as error text is seen just same time when crack happens. The signal updates are what is causing the ALSA under-runs (*), the over-runs are the result of catching up after a under-run. *) Or at least an important cause of them Commenting out line did not help. Are you sure about this? Did you do a make after commenting, are you sure you were using the new build to test? But I think I was also hearing those small pops too and likely new four patches fixes those - but it is hard to say because it cracks audio all time. One other thing you can try is increasing the buffer size, using: radio -L 1000 For example will increase it from the 500 millisecs default to 1 second 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
Unable to build V4L drivers on Ubuntu 10.04.4 2.6.32-41-server x86_64
Hi, Fairly new user to the list here, but been using V4L with MythTV 0.25 for a few months now. I tried to build the V4L drivers for Ubuntu Server 10.04.4 2.6.32-41-server x86_64 yesterday on a new system, however the build fails when applying the patches. I've previously been able to build the drivers successfully on other servers running Ubuntu 10.04.4 x86_64, but I'm not sure they were the same kernel version as this install. Here's the full log from my terminal when I tried to build: joe@FileServer1:~$ git clone git://linuxtv.org/media_build.git Initialized empty Git repository in /home/joe/media_build/.git/ remote: Counting objects: 1397, done. remote: Compressing objects: 100% (463/463), done. remote: Total 1397 (delta 905), reused 1377 (delta 895) Receiving objects: 100% (1397/1397), 338.38 KiB | 276 KiB/s, done. Resolving deltas: 100% (905/905), done. joe@FileServer1:~$ cd media_build/ joe@FileServer1:~/media_build$ ./build Checking if the needed tools for Ubuntu 10.04.4 LTS are available Needed package dependencies are met. * This script will download the latest tarball and build it* * Assuming that your kernel is compatible with the latest * * drivers. If not, you'll need to add some extra backports,* * ./backports/kernel directory. * * It will also update this tree to be sure that all compat * * bits are there, to avoid compilation failures* * All drivers and build system are under GPLv2 License * * Firmware files are under the license terms found at: * * http://www.linuxtv.org/downloads/firmware/ * * Please abort if you don't agree with the license * Updating the building system From git://linuxtv.org/media_build * branchmaster - FETCH_HEAD Already up-to-date. make: Entering directory `/home/joe/media_build/linux' wget http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2.md5 -O linux-media.tar.bz2.md5.tmp --2012-07-09 10:59:34-- http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2.md5 Resolving linuxtv.org... 130.149.80.248 Connecting to linuxtv.org|130.149.80.248|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 93 [application/x-bzip2] Saving to: `linux-media.tar.bz2.md5.tmp' 100%[==] 93 --.-K/s in 0s 2012-07-09 10:59:34 (21.5 MB/s) - `linux-media.tar.bz2.md5.tmp' saved [93/93] cat: linux-media.tar.bz2.md5: No such file or directory --2012-07-09 10:59:34-- http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2 Resolving linuxtv.org... 130.149.80.248 Connecting to linuxtv.org|130.149.80.248|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 4383385 (4.2M) [application/x-bzip2] Saving to: `linux-media.tar.bz2' 100%[==] 4,383,385383K/s in 12s 2012-07-09 10:59:46 (367 KB/s) - `linux-media.tar.bz2' saved [4383385/4383385] make: Leaving directory `/home/joe/media_build/linux' make: Entering directory `/home/joe/media_build/linux' tar xfj linux-media.tar.bz2 rm -f .patches_applied .linked_dir .git_log.md5 make: Leaving directory `/home/joe/media_build/linux' ** * Downloading firmwares from linuxtv.org.* ** --2012-07-09 10:59:47-- http://www.linuxtv.org/downloads/firmware//dvb-firmwares.tar.bz2 Resolving www.linuxtv.org... 130.149.80.248 Connecting to www.linuxtv.org|130.149.80.248|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 649441 (634K) [application/x-bzip2] Saving to: `dvb-firmwares.tar.bz2' 100%[==] 649,441 370K/s in 1.7s 2012-07-09 10:59:49 (370 KB/s) - `dvb-firmwares.tar.bz2' saved [649441/649441] tar: Record size = 8 blocks dvb-fe-bcm3510-01.fw dvb-fe-or51132-qam.fw dvb-fe-or51132-vsb.fw dvb-fe-or51211.fw dvb-fe-xc5000-1.6.114.fw dvb-ttpci-01.fw-261a dvb-ttpci-01.fw-261b dvb-ttpci-01.fw-261c dvb-ttpci-01.fw-261d dvb-ttpci-01.fw-261f dvb-ttpci-01.fw-2622 dvb-usb-avertv-a800-02.fw dvb-usb-bluebird-01.fw dvb-usb-dib0700-1.20.fw dvb-usb-dibusb-5.0.0.11.fw dvb-usb-dibusb-6.0.0.8.fw dvb-usb-dtt200u-01.fw dvb-usb-terratec-h5-drxk.fw dvb-usb-terratec-h7-az6007.fw dvb-usb-terratec-h7-drxk.fw dvb-usb-umt-010-02.fw dvb-usb-vp702x-01.fw dvb-usb-vp7045-01.fw dvb-usb-wt220u-01.fw dvb-usb-wt220u-02.fw v4l-cx231xx-avcore-01.fw v4l-cx23418-apu.fw v4l-cx23418-cpu.fw v4l-cx23418-dig.fw v4l-cx23885-avcore-01.fw
Re: video: USB webcam fails since kernel 3.2
2012/7/8 Hans de Goede hdego...@redhat.com: On 07/08/2012 03:01 PM, Martin-Éric Racine wrote: 2012/6/17 Martin-Éric Racine martin-eric.rac...@iki.fi: pe, 2012-06-15 kello 23:41 -0500, Jonathan Nieder kirjoitti: Martin-Éric Racine wrote: usb 1-7: new high-speed USB device number 3 using ehci_hcd [...] usb 1-7: New USB device found, idVendor=0ac8, idProduct=0321 usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-7: Product: USB2.0 Web Camera usb 1-7: Manufacturer: Vimicro Corp. [...] Linux media interface: v0.10 Linux video capture interface: v2.00 gspca_main: v2.14.0 registered gspca_main: vc032x-2.14.0 probing 0ac8:0321 usbcore: registered new interface driver vc032x The device of interest is discovered. gspca_main: ISOC data error: [36] len=0, status=-71 gspca_main: ISOC data error: [65] len=0, status=-71 [...] gspca_main: ISOC data error: [48] len=0, status=-71 video_source:sr[3246]: segfault at 0 ip (null) sp ab36de1c error 14 in cheese[8048000+21000] gspca_main: ISOC data error: [17] len=0, status=-71 (The above data error spew starts around t=121 seconds and continues at a rate of about 15 messages per second. The segfault is around t=154.) The vc032x code hasn't changed since 3.4.1, so please report your symptoms to Jean-François Moine moin...@free.fr, cc-ing linux-media@vger.kernel.org, linux-ker...@vger.kernel.org, and either me or this bug log so we can track it. Be sure to mention: - steps to reproduce, expected result, actual result, and how the difference indicates a bug (should be simple enough in this case) 1. Ensure that user 'myself' is a member of the 'video' group. 2. Launch the webcam application Cheese from the GNOME desktop. Expected result: Cheese displays whatever this laptop's camera sees. Actual result: Cheese crashes while attempting to access the camera. - how reproducible the bug is (100%?) 100% - which kernel versions you have tested and result with each (what is the newest kernel version that worked?) It probably was 3.1.0 or some earlier 3.2 release (the upcoming Debian will release with 3.2.x; 3.4 was only used here for testing purposes), but I wouldn't know for sure since I don't use my webcam too often. I finally found time to perform further testing, using kernel packages from snapshots.debian.org, and the last one that positively worked (at least using GNOME's webcam application Cheese) was: linux-image-3.1.0-1-686-pae 3.1.8-2 Linux 3.1 for modern PCs This loaded the following video modules: gspca_vc032x gspca_main videodev media Tests using 3.2.1-1 or more recent crashed as described before. This at least gives us a time frame for when the regression started. Hmm, this is then likely caused by the new isoc bandwidth negotiation code in 3.2, unfortunately the vc032x driver is one of the few gspca drivers for which I don't have a cam to test with. Can you try to build your own kernel from source? Boot into your own kernel, and verify the regression is still there, then edit drivers/media/video/gspca/gspca.c and go to the which_bandwidth function, and at the beginning of this function add the following line: return 2000 * 2000 * 120; Then rebuild and re-install the kernel and try again. If that helps, remove the added return 2000 * 2000 * 120; line, and also remove the following lines from which_bandwidth: /* if the image is compressed, estimate its mean size */ if (!gspca_dev-cam.needs_full_bandwidth bandwidth gspca_dev-cam.cam_mode[i].width * gspca_dev-cam.cam_mode[i].height) bandwidth = bandwidth * 3 / 8; /* 0.375 */ And try again if things still work this way. Once you've tested this I can try to write a fix for this. Hans, Thank you for your reply. Just to eliminate the possibility of mistakes on my part while trying to perform the above changes, could you send me a patch against Linux 3.2.21 that I could apply as-is, before building myself a test kernel package? Cheers! Martin-Éric -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] radio-si470x: Lower firmware version requirements
On 07/09/2012 01:03 PM, Hans de Goede wrote: Hi, On 07/09/2012 11:17 AM, Antti Palosaari wrote: On 07/07/2012 09:53 PM, Hans de Goede wrote: Hi, On 07/07/2012 11:00 AM, Antti Palosaari wrote: Hello Hans, On 07/07/2012 10:58 AM, Hans de Goede wrote: So is your device working properly now? The reason I'm asking it because it is still causing a firmware version warning, and if it works fine I would like to lower the firmware version warning point, so that the warning goes away. I don't know what is definition of properly in that case. Problem is that when I use radio application from xawtv3 with that new loopback I hear very often cracks and following errors are printed to the radio screen: ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred or ALSA lib pcm.c:7339:(snd_pcm_recover) overrun occurred Looks like those does not appear, at least it does not crack so often nor errors seen, when I use Rhythmbox to tune and arecord -D hw:2,0 -r96000 -c2 -f S16_LE | aplay - to listen. I can guess those are not firmware related so warning texts could be removed. Actually they may very well be firmware related. At least with my firmware there is a bug where actively asking the device for its register contents, it lets its audio stream drop. My patches fix this by waiting for the device to volunteer it register contents through its usb interrupt in endpoint, which it does at xx times / sec. So the first question would be, does this dropping of sound happen approx 1 / sec when using radio? If so this is caused by radio upating the signal strength it displays 1 / sec. If you look at radio.c line 981 you will see a radio_getsignal_n_stereo(fd); call there in the main loop which gets called 1/sec. Try commenting this out. If commenting this out fixes your sound issues with radio, then the next question is are you using my 4 recent si470x patches, if not please give them a try. If you are already using them then I'm afraid that your older firmware may be broken even more then my also not so new firmware. I suspect these signal strength update pops are different thing. Those are almost so minor you cannot even hear. I recorded small sample: http://palosaari.fi/linux/v4l-dvb/xawtv3_radio.m4v And I am almost 100% sure those cracks are coming ALSA underrun/overrun as error text is seen just same time when crack happens. The signal updates are what is causing the ALSA under-runs (*), the over-runs are the result of catching up after a under-run. *) Or at least an important cause of them Commenting out line did not help. Are you sure about this? Did you do a make after commenting, are you sure you were using the new build to test? Yes I ran make and new radio bin was generated. And when I make build error as a test build fails so it is compiling. But I think I was also hearing those small pops too and likely new four patches fixes those - but it is hard to say because it cracks audio all time. One other thing you can try is increasing the buffer size, using: radio -L 1000 For example will increase it from the 500 millisecs default to 1 second If I tune using old radio it works. If I tune using latest radio but with option -l 0 (./console/radio -l 0) it also works. Using arecord -D hw:2,0 -r96000 -c2 -f S16_LE | aplay - to listen. So it seems that latest radio with alsa loopback is only having those problems. These are the patches: radio-si470x: Don't unnecesarily read registers on G_TUNER radio-si470x: Lower hardware freq seek signal treshold radio-si470x: Always use interrupt to wait for tune/seek completion radio-si470x: Lower firmware version requirements And from that I can see it loads new driver as it does not warn about software version - only firmware. Jul 9 14:28:29 localhost kernel: [13403.017920] Linux media interface: v0.10 Jul 9 14:28:29 localhost kernel: [13403.020866] Linux video capture interface: v2.00 Jul 9 14:28:29 localhost kernel: [13403.022744] radio-si470x 5-2:1.2: DeviceID=0x1242 ChipID=0x060c Jul 9 14:28:29 localhost kernel: [13403.022747] radio-si470x 5-2:1.2: This driver is known to work with firmware version 14, Jul 9 14:28:29 localhost kernel: [13403.022749] radio-si470x 5-2:1.2: but the device has firmware version 12. Jul 9 14:28:29 localhost kernel: [13403.024715] radio-si470x 5-2:1.2: software version 1, hardware version 7 Jul 9 14:28:29 localhost kernel: [13403.024717] radio-si470x 5-2:1.2: If you have some trouble using this driver, Jul 9 14:28:29 localhost kernel: [13403.024719] radio-si470x 5-2:1.2: please report to V4L ML at linux-media@vger.kernel.org Jul 9 14:28:29 localhost kernel: [13403.114583] usbcore: registered new interface driver radio-si470x regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] radio-si470x: Lower firmware version requirements
Hi, On 07/09/2012 01:58 PM, Antti Palosaari wrote: On 07/09/2012 01:03 PM, Hans de Goede wrote: If I tune using old radio it works. If I tune using latest radio but with option -l 0 (./console/radio -l 0) it also works. Using arecord -D hw:2,0 -r96000 -c2 -f S16_LE | aplay - to listen. So it seems that latest radio with alsa loopback is only having those problems. Ok. These are the patches: radio-si470x: Don't unnecesarily read registers on G_TUNER radio-si470x: Lower hardware freq seek signal treshold radio-si470x: Always use interrupt to wait for tune/seek completion radio-si470x: Lower firmware version requirements And from that I can see it loads new driver as it does not warn about software version - only firmware. Right, so what I want to do is to lower the firmware requirement to 12, so that it won't complain for your device since that seems to be working fine. Does that sound like a good idea to you? Jul 9 14:28:29 localhost kernel: [13403.017920] Linux media interface: v0.10 Jul 9 14:28:29 localhost kernel: [13403.020866] Linux video capture interface: v2.00 Jul 9 14:28:29 localhost kernel: [13403.022744] radio-si470x 5-2:1.2: DeviceID=0x1242 ChipID=0x060c Jul 9 14:28:29 localhost kernel: [13403.022747] radio-si470x 5-2:1.2: This driver is known to work with firmware version 14, Jul 9 14:28:29 localhost kernel: [13403.022749] radio-si470x 5-2:1.2: but the device has firmware version 12. Jul 9 14:28:29 localhost kernel: [13403.024715] radio-si470x 5-2:1.2: software version 1, hardware version 7 Jul 9 14:28:29 localhost kernel: [13403.024717] radio-si470x 5-2:1.2: If you have some trouble using this driver, Jul 9 14:28:29 localhost kernel: [13403.024719] radio-si470x 5-2:1.2: please report to V4L ML at linux-media@vger.kernel.org Jul 9 14:28:29 localhost kernel: [13403.114583] usbcore: registered new interface driver radio-si470x 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 v2 0/2] update MFC v4l2 driver to support MFC6.x
Hi Arun,
First of all you have not addressed all the comments presented in the
previous conversation about this patch.
Look here:
http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/4519
7
+#define V4L2_PIX_FMT_VP8 v4l2_fourcc('V', 'P', '8', '0') /* VP8 */
Note that these new formats need to be documented in the spec as well.
(Hint: Documentation/DocBook/media/v4l)
I agree with Hans here - you need to describe the new format in the
documentation. Without it the patch will not get accepted.
Also, you have just removed all the new controls introduced in that patch.
This is not the way to go, especially when your code uses these controls.
For example in s5p_mfc_opr_v6.c:962 you use the following control:
V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_INTERLEAVED_SLICES
I cannot find it in the videodev2.h you have posted. (also remember
that drivers/media/video/v4l2-ctrls.c has to be updated as well).
This means that if I compile for Exynos5 (v6) I will still get errors.
Also, your modification to Makefile are wrong. It will work if MFC is
built into the kernel image. If I choose to build it as a module it
does not compile.
Best regards,
--
Kamil Debski
Linux Platform Group
Samsung Poland RD Center
-Original Message-
From: Arun Kumar K [mailto:arun...@samsung.com]
Sent: 06 July 2012 16:00
To: linux-media@vger.kernel.org
Cc: jtp.p...@samsung.com; janghyuck@samsung.com;
jaeryul...@samsung.com; ch.nav...@samsung.com; arun...@samsung.com;
m.szyprow...@samsung.com; k.deb...@samsung.com; s.nawro...@samsung.com;
hans.verk...@cisco.com; mche...@infradead.org
Subject: [PATCH v2 0/2] update MFC v4l2 driver to support MFC6.x
This is the v2 series of patches for adding support for MFC v6.x.
In this the new v4l controls added in patch [1] are removed. These can be
added as a separate patch later for providing extra encoder controls for
MFC v6. This also incorporates the review comments received for the
original
patch and fixed for backward compatibility with MFC v5.
[1] http://article.gmane.org/gmane.linux.drivers.video-input-
infrastructure/45190/
Jeongtae Park (2):
[media] v4l: add fourcc definitions for new formats
[media] s5p-mfc: update MFC v4l2 driver to support MFC6.x
drivers/media/video/Kconfig | 16 +-
drivers/media/video/s5p-mfc/Makefile |7 +-
drivers/media/video/s5p-mfc/regs-mfc-v6.h| 676 ++
drivers/media/video/s5p-mfc/regs-mfc.h | 29 +
drivers/media/video/s5p-mfc/s5p_mfc.c| 163 ++-
drivers/media/video/s5p-mfc/s5p_mfc_cmd.c|6 +-
drivers/media/video/s5p-mfc/s5p_mfc_cmd.h|3 +
drivers/media/video/s5p-mfc/s5p_mfc_cmd_v6.c | 96 ++
drivers/media/video/s5p-mfc/s5p_mfc_common.h | 123 ++-
drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c | 160 ++-
drivers/media/video/s5p-mfc/s5p_mfc_ctrl.h |1 +
drivers/media/video/s5p-mfc/s5p_mfc_dec.c| 210 +++-
drivers/media/video/s5p-mfc/s5p_mfc_dec.h|1 +
drivers/media/video/s5p-mfc/s5p_mfc_enc.c| 191 ++--
drivers/media/video/s5p-mfc/s5p_mfc_enc.h|1 +
drivers/media/video/s5p-mfc/s5p_mfc_intr.c |1 -
drivers/media/video/s5p-mfc/s5p_mfc_opr.c| 278 +++--
drivers/media/video/s5p-mfc/s5p_mfc_opr.h| 25 +-
drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.c | 1697
++
drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.h | 140 +++
drivers/media/video/s5p-mfc/s5p_mfc_pm.c |6 +-
drivers/media/video/s5p-mfc/s5p_mfc_shm.c| 28 +-
drivers/media/video/s5p-mfc/s5p_mfc_shm.h| 13 +-
drivers/media/video/v4l2-ctrls.c |1 -
include/linux/videodev2.h|4 +
25 files changed, 3480 insertions(+), 396 deletions(-)
create mode 100644 drivers/media/video/s5p-mfc/regs-mfc-v6.h
create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_cmd_v6.c
create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.c
create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.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: video: USB webcam fails since kernel 3.2
Hi, On 07/09/2012 01:33 PM, Martin-Éric Racine wrote: snip Hmm, this is then likely caused by the new isoc bandwidth negotiation code in 3.2, unfortunately the vc032x driver is one of the few gspca drivers for which I don't have a cam to test with. Can you try to build your own kernel from source? Boot into your own kernel, and verify the regression is still there, then edit drivers/media/video/gspca/gspca.c and go to the which_bandwidth function, and at the beginning of this function add the following line: return 2000 * 2000 * 120; Then rebuild and re-install the kernel and try again. If that helps, remove the added return 2000 * 2000 * 120; line, and also remove the following lines from which_bandwidth: /* if the image is compressed, estimate its mean size */ if (!gspca_dev-cam.needs_full_bandwidth bandwidth gspca_dev-cam.cam_mode[i].width * gspca_dev-cam.cam_mode[i].height) bandwidth = bandwidth * 3 / 8; /* 0.375 */ And try again if things still work this way. Once you've tested this I can try to write a fix for this. Hans, Thank you for your reply. Just to eliminate the possibility of mistakes on my part while trying to perform the above changes, could you send me a patch against Linux 3.2.21 that I could apply as-is, before building myself a test kernel package? Erm, that is quite a bit of work from my side for something which you can easily do yourself, edit gspca.c, search for which_bandwidth and then under the following lines: u32 bandwidth; int i; Add a line like this: return 2000 * 2000 * 120; 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 4/4] radio-si470x: Lower firmware version requirements
Hello On 07/09/2012 04:02 PM, Hans de Goede wrote: On 07/09/2012 01:58 PM, Antti Palosaari wrote: On 07/09/2012 01:03 PM, Hans de Goede wrote: If I tune using old radio it works. If I tune using latest radio but with option -l 0 (./console/radio -l 0) it also works. Using arecord -D hw:2,0 -r96000 -c2 -f S16_LE | aplay - to listen. So it seems that latest radio with alsa loopback is only having those problems. Ok. These are the patches: radio-si470x: Don't unnecesarily read registers on G_TUNER radio-si470x: Lower hardware freq seek signal treshold radio-si470x: Always use interrupt to wait for tune/seek completion radio-si470x: Lower firmware version requirements And from that I can see it loads new driver as it does not warn about software version - only firmware. Right, so what I want to do is to lower the firmware requirement to 12, so that it won't complain for your device since that seems to be working fine. Does that sound like a good idea to you? Yes, indeed lower it to the 12 as it works to get rid of those warnings. It still cracks but rarely, once per 2 mins or so when using arecord + aplay. The whole journey of playing that device was idea to learn V4L2 radio API as I was planning to add SDR functionality. Anyhow, I am a little bit disappointed because that radio uses snd-usb-audio module for audio. Do you know any cheap usb radio which uses vendor specific USB interface, not standard profiles? regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pctv452e
W dniu 2012-07-09 10:42, Antti Palosaari pisze:
On 07/09/2012 09:24 AM, Marx wrote:
On 08.07.2012 14:32, Antti Palosaari wrote:
I suspect you stopped szap ?
You cannot use dvbdate or dvbtraffic, nor read data from dvr0 unless
frontend is tuned. Leave szap running backround and try again.
That way it works, and I can save stream. Hovewer it's strange because I
shouldn't have to constatly tune channel to watch it, and on previous
cards it was enough to tune once and then use other commands.
I base my knowledge on
http://www.linuxtv.org/wiki/index.php/Testing_your_DVB_device
There is nothing about constant tuning channel to use it. Am I missing
something?
given wiki-page says:
4. After you've tuned a frequency and program
a) You could now start up your simple TV watching application and decode
the stream you have tuned.
For example, while keeping {a,c,s,t}zap running in the first console
shell, open up another console and run
Behavior have been always same, at least for the DVB USB.
So you don't have problems at all?
ok, my fault
problem still exists
VDR doesn't play any channel, and while you asked me to abandon it, I
saved some data using
cat /dev/dvb/adapter0/dvr0 /mnt/video/test3.ts
while tuning in the background.
Stream saved that way is unplayable (I play it using VLC for windows -
it played almost all proper TS strems in the past I had). I've tried all
software I have - to play this streams - no way.
So
- I can tune only 2/3 of channels
- TS stream saves with errors
- traditional tuner on the same (brand new) dish works ok
- i've exchanged cables between the two
is it possible that pctv device is less sensitive and the problem is
with too weak signal?
Marx
--
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:Mon Jul 9 19:00:20 CEST 2012 git hash:b7e386360922a15f943b2fbe8d77a19bb86f2e6f 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: ERRORS linux-git-arm-eabi-omap: ERRORS 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: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS linux-2.6.38.2-x86_64: ERRORS linux-2.6.39.1-x86_64: ERRORS linux-3.0-x86_64: ERRORS linux-3.1-x86_64: ERRORS linux-3.2.1-x86_64: ERRORS linux-3.3-x86_64: ERRORS linux-3.4-x86_64: ERRORS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.38.2-i686: ERRORS linux-2.6.39.1-i686: ERRORS linux-3.0-i686: ERRORS linux-3.1-i686: ERRORS linux-3.2.1-i686: ERRORS linux-3.3-i686: ERRORS linux-3.4-i686: ERRORS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.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: pctv452e
On 07/09/2012 07:44 PM, Marx wrote:
W dniu 2012-07-09 10:42, Antti Palosaari pisze:
On 07/09/2012 09:24 AM, Marx wrote:
On 08.07.2012 14:32, Antti Palosaari wrote:
I suspect you stopped szap ?
You cannot use dvbdate or dvbtraffic, nor read data from dvr0 unless
frontend is tuned. Leave szap running backround and try again.
That way it works, and I can save stream. Hovewer it's strange because I
shouldn't have to constatly tune channel to watch it, and on previous
cards it was enough to tune once and then use other commands.
I base my knowledge on
http://www.linuxtv.org/wiki/index.php/Testing_your_DVB_device
There is nothing about constant tuning channel to use it. Am I missing
something?
given wiki-page says:
4. After you've tuned a frequency and program
a) You could now start up your simple TV watching application and decode
the stream you have tuned.
For example, while keeping {a,c,s,t}zap running in the first console
shell, open up another console and run
Behavior have been always same, at least for the DVB USB.
So you don't have problems at all?
ok, my fault
problem still exists
VDR doesn't play any channel, and while you asked me to abandon it, I
saved some data using
cat /dev/dvb/adapter0/dvr0 /mnt/video/test3.ts
while tuning in the background.
Stream saved that way is unplayable (I play it using VLC for windows -
it played almost all proper TS strems in the past I had). I've tried all
software I have - to play this streams - no way.
So
- I can tune only 2/3 of channels
- TS stream saves with errors
- traditional tuner on the same (brand new) dish works ok
- i've exchanged cables between the two
is it possible that pctv device is less sensitive and the problem is
with too weak signal?
If VDR does not work at all, but other tools are working, it could be
compatibility issue between VDR and Kernel.
# tune to channel:
szap -r CHANNEL NAME
# dump channels from tuned multiplex (if you don't have that command
just skip):
scandvb -c
# save tuned channel to file (lets say 20 second):
cat /dev/dvb/adapter0/dvr0 test.ts
# check if ffmpeg finds video and audio
ffmpeg -i test.ts
and post result here
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pctv452e
On 07/09/2012 08:38 PM, Antti Palosaari wrote:
On 07/09/2012 07:44 PM, Marx wrote:
W dniu 2012-07-09 10:42, Antti Palosaari pisze:
On 07/09/2012 09:24 AM, Marx wrote:
On 08.07.2012 14:32, Antti Palosaari wrote:
I suspect you stopped szap ?
You cannot use dvbdate or dvbtraffic, nor read data from dvr0 unless
frontend is tuned. Leave szap running backround and try again.
That way it works, and I can save stream. Hovewer it's strange
because I
shouldn't have to constatly tune channel to watch it, and on previous
cards it was enough to tune once and then use other commands.
I base my knowledge on
http://www.linuxtv.org/wiki/index.php/Testing_your_DVB_device
There is nothing about constant tuning channel to use it. Am I missing
something?
given wiki-page says:
4. After you've tuned a frequency and program
a) You could now start up your simple TV watching application and decode
the stream you have tuned.
For example, while keeping {a,c,s,t}zap running in the first console
shell, open up another console and run
Behavior have been always same, at least for the DVB USB.
So you don't have problems at all?
ok, my fault
problem still exists
VDR doesn't play any channel, and while you asked me to abandon it, I
saved some data using
cat /dev/dvb/adapter0/dvr0 /mnt/video/test3.ts
while tuning in the background.
Stream saved that way is unplayable (I play it using VLC for windows -
it played almost all proper TS strems in the past I had). I've tried all
software I have - to play this streams - no way.
So
- I can tune only 2/3 of channels
- TS stream saves with errors
- traditional tuner on the same (brand new) dish works ok
- i've exchanged cables between the two
is it possible that pctv device is less sensitive and the problem is
with too weak signal?
If VDR does not work at all, but other tools are working, it could be
compatibility issue between VDR and Kernel.
# tune to channel:
szap -r CHANNEL NAME
-r option is important here as it routes stream to /dev/dvb/adapter0/dvr0
# dump channels from tuned multiplex (if you don't have that command
just skip):
scandvb -c
Could be named as scan, dvbscan, scandvb
# save tuned channel to file (lets say 20 second):
cat /dev/dvb/adapter0/dvr0 test.ts
actually seems like ffmpeg could read directly dvr0
ffmpeg -i /dev/dvb/adapter0/dvr0
takes ~20 seconds or so until results are shown
# check if ffmpeg finds video and audio
ffmpeg -i test.ts
and post result here
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pctv452e
On 07/09/2012 06:44 PM, Marx wrote:
W dniu 2012-07-09 10:42, Antti Palosaari pisze:
On 07/09/2012 09:24 AM, Marx wrote:
On 08.07.2012 14:32, Antti Palosaari wrote:
I suspect you stopped szap ?
You cannot use dvbdate or dvbtraffic, nor read data from dvr0 unless
frontend is tuned. Leave szap running backround and try again.
That way it works, and I can save stream. Hovewer it's strange because I
shouldn't have to constatly tune channel to watch it, and on previous
cards it was enough to tune once and then use other commands.
I base my knowledge on
http://www.linuxtv.org/wiki/index.php/Testing_your_DVB_device
There is nothing about constant tuning channel to use it. Am I missing
something?
given wiki-page says:
4. After you've tuned a frequency and program
a) You could now start up your simple TV watching application and decode
the stream you have tuned.
For example, while keeping {a,c,s,t}zap running in the first console
shell, open up another console and run
Behavior have been always same, at least for the DVB USB.
So you don't have problems at all?
ok, my fault
problem still exists
VDR doesn't play any channel, and while you asked me to abandon it, I
saved some data using
cat /dev/dvb/adapter0/dvr0 /mnt/video/test3.ts
while tuning in the background.
Stream saved that way is unplayable (I play it using VLC for windows -
it played almost all proper TS strems in the past I had). I've tried all
software I have - to play this streams - no way.
So
- I can tune only 2/3 of channels
- TS stream saves with errors
- traditional tuner on the same (brand new) dish works ok
- i've exchanged cables between the two
is it possible that pctv device is less sensitive and the problem is
with too weak signal?
Good reception on one device, completely different story on another
device - same cable; different tuner sensitivity.
It is *very* important to achieve *very* good signal reception with
larger dish(DVB-S) and/or Yagi-Uda(DVB-T) - focal angle/directional gain.
Try this one:
dvbstream -f freq -o 8192 full-mux.ts
enough free disk space ;)
mplayer -cache 8912 full-mux.ts (TAB-TAB-TAB…)
or
dvbstream -f freq -o vid aid tid pid single-stream.ts
cheers,
poma
--
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: [GIT PULL FOR v3.6] DVB USB v2
On 07/07/2012 01:22 AM, Mauro Carvalho Chehab wrote: Em 03-07-2012 18:47, Antti Palosaari escreveu: On 07/02/2012 04:08 PM, Antti Palosaari wrote: Here it is finally - quite totally rewritten DVB-USB-framework. I haven't got almost any feedback so far... I rebased it in order to fix compilation issues coming from Kconfig. regards Antti The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678: Linux 3.5-rc5 (2012-06-30 16:08:57 -0700) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git dvb_usb_pull for you to fetch changes up to 747abaa1e0ee4415e67026c119cb73e6277f4898: dvb_usb_v2: remove usb_clear_halt() from stream (2012-07-02 15:54:29 +0300) Antti Palosaari (103): dvb_usb_v2: copy current dvb_usb as a starting point Naming the DVB USB v2 as dvb_usb, instead of dvb-usb is very very ugly. It took me some time to discover what happened. You should have named it as dvb-usb-v2 instead, or to store it into a separate directory. This is even worse as it seems that this series doesn't change all drivers to use dvb usb v2. So, it will be harder to discover what drivers are at V1 and what are at V2. I won't merge it as-is at staging/for_v3.6. I may eventually create a separate topic branch and add them there, while the namespace mess is not corrected, if I still have some time today. Otherwise, I'll only handle that after returning from vacations. I moved it to the dvb-usb-v2 directory. Same location only added patch top of that. Surely I can convert all drivers and use old directory, but IMHO it is simply too risky. We have already too much problems coming from that kind of big changes. And what goes to file naming hyphen (-) vs. underscore (_), underscore seems to be much more common inside Kernel. Anyhow, I keep directory name as dvb-usb-v2 to follow old naming. $ find ./ -type f -printf %f\n | grep _ | wc -l 21465 $ find ./ -type f -printf %f\n | grep - | wc -l 13927 regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dvb_usb_pctv452e driver problems
I am looking problems with that driver. It is said to be buggy after merged to mainline Kernel. It supports three different devices: PCTV HDTV USB Technotrend TT Connect S2-3600 Technotrend TT Connect S2-3650-CI All reports are welcome even when it is working as expected. In problem case I would like to ask if you could test that tree and report if it helps: http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/pctv452e regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: video: USB webcam fails since kernel 3.2
Hi Martin-Éric, Hans de Goede wrote: Erm, that is quite a bit of work from my side for something which you can easily do yourself, edit gspca.c, search for which_bandwidth and then under the following lines: u32 bandwidth; int i; Add a line like this: return 2000 * 2000 * 120; In case it helps, here are some more complete instructions. 0. Prerequisites: apt-get install git build-essential 1. Get the kernel history, if you don't already have it: git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 2. Try linus's master: cd linux git fetch origin git reset --hard origin/master cp /boot/config-$(uname -r) .config; # current configuration scripts/config --disable DEBUG_INFO make localmodconfig; # optional: minimize configuration make deb-pkg; # optionally with -jnum for parallel build dpkg -i ../name of package; # as root reboot ... test test test ... Hopefully it reproduces the bug. 3. Try Hans's first suggested change, as described in the quoted text above: cd linux vi drivers/media/video/gspca/gspca.c ... make the suggested edits ... make deb-pkg; # maybe with -j4 dpkg -i ../name of package; # as root reboot ... test test test ... 4. Try Hans's second suggested change, as described in a previous message: cd linux vi drivers/media/video/gspca/gspca.c ... make the suggested edits ... make deb-pkg; # maybe with -j4 dpkg -i ../name of package; # as root reboot ... test test test ... No doubt Jean-François will notice that it is easier to test the standalone driver because the first build does not have to compile the whole kernel. That's fine, too. The instructions above describe how to test the in-kernel driver because it's what I'm used to (and because it means you test the driver against the same version of the rest of the kernel as would get the fix). Hope that helps, Jonathan -- 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
Linux equivalent of Windows VBIScope?
Hi all, I am using the em28xx driver and have been able to extract captions using zvbi. I would like to visualize the waveform like the DirectShow VBIScope filter on windows (unfortunately the Windows driver doesn't expose any VBI pins). Does anyone know of anythings similar on Linux? Thanks -- 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: Linux equivalent of Windows VBIScope?
Tim Stowell stowe...@gmail.com wrote: Hi all, I am using the em28xx driver and have been able to extract captions using zvbi. I would like to visualize the waveform like the DirectShow VBIScope filter on windows (unfortunately the Windows driver doesn't expose any VBI pins). Does anyone know of anythings similar on Linux? Thanks -- 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 'osc' is a test utility that is part of the zvbi source distribution. It probably does what you need. Regards, 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
Re: Linux equivalent of Windows VBIScope?
On Mon, Jul 9, 2012 at 5:32 PM, Andy Walls awa...@md.metrocast.net wrote: Tim Stowell stowe...@gmail.com wrote: Hi all, I am using the em28xx driver and have been able to extract captions using zvbi. I would like to visualize the waveform like the DirectShow VBIScope filter on windows (unfortunately the Windows driver doesn't expose any VBI pins). Does anyone know of anythings similar on Linux? Thanks -- 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 'osc' is a test utility that is part of the zvbi source distribution. It probably does what you need. Regards, Andy I'll second Andy's endorsement of osc. It's a very handy little tool. Also, if you run into any VBI issues with em28xx, please let me know (I did the original driver support for it). Devin -- Devin J. Heitmueller - 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: Linux equivalent of Windows VBIScope?
osc is perfect, thanks! In my past experience the em28xx driver has been great, but I'll let you know if there are any issues. On Mon, Jul 9, 2012 at 3:49 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Mon, Jul 9, 2012 at 5:32 PM, Andy Walls awa...@md.metrocast.net wrote: Tim Stowell stowe...@gmail.com wrote: Hi all, I am using the em28xx driver and have been able to extract captions using zvbi. I would like to visualize the waveform like the DirectShow VBIScope filter on windows (unfortunately the Windows driver doesn't expose any VBI pins). Does anyone know of anythings similar on Linux? Thanks -- 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 'osc' is a test utility that is part of the zvbi source distribution. It probably does what you need. Regards, Andy I'll second Andy's endorsement of osc. It's a very handy little tool. Also, if you run into any VBI issues with em28xx, please let me know (I did the original driver support for it). Devin -- Devin J. Heitmueller - 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 v4] media: Add stk1160 new driver
Hey Mauro,
On Fri, Jul 6, 2012 at 11:41 AM, Ezequiel Garcia elezegar...@gmail.com wrote:
On Thu, Jul 5, 2012 at 9:01 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em 05-07-2012 19:36, Sylwester Nawrocki escreveu:
On 07/06/2012 12:11 AM, Mauro Carvalho Chehab wrote:
+static int vidioc_dqbuf(struct file *file, void *priv, struct
v4l2_buffer *p)
+{
+ struct stk1160 *dev = video_drvdata(file);
+
+ if (!stk1160_is_owner(dev, file))
+ return -EBUSY;
+
+ return vb2_dqbuf(dev-vb_vidq, p, file-f_flags O_NONBLOCK);
Why to use O_NONBLOCK here? it should be doing whatever userspace wants.
This is OK, since the third argument to vb2_dqbuf() is a boolean indicating
whether this call should be blocking or not. And a O_NONBLOCK masks this
information out from file-f_flags.
Ah! OK then.
It might be better to initialize it during vb2 initialization, at open,
instead of requiring this argument every time vb_dqbuf() is called.
Currently stk1160 doesn't implement an open call, but uses v4l2_fh_open instead.
I'm not sure I should add a separate open, or perhaps you would accept
to initialize this non-block flag in vidioc_reqbufs.
On the other hand, many drivers are doing it at dqbuf, like here at stk1160,
and I was wondering: is it *that* bad?
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
Any program that creates captions from pixel data?
Hello, I'm trying to create a bitmap image such that when output via a composite port it will translate into captions, very similar to this: http://al.robotfuzz.com/generating-teletext-in-software/ except NTSC. I have some ideas but wanted to check if anyone had tried something similar as Google didn't turn up much, thanks! -- 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: Any program that creates captions from pixel data?
On Mon, Jul 9, 2012 at 11:19 PM, Tim Stowell stowe...@gmail.com wrote: Hello, I'm trying to create a bitmap image such that when output via a composite port it will translate into captions, very similar to this: http://al.robotfuzz.com/generating-teletext-in-software/ except NTSC. I have some ideas but wanted to check if anyone had tried something similar as Google didn't turn up much, thanks! I don't know if this is related to your previous thread about VBI capture on em28xx, but if so I can tell you that you can probably pretty easily pass through the VBI data as a graphical waveform if that is your goal. The only difference between the data provided via raw VBI capture and the standard image data is that the chroma is stripped out (every other byte in a YUYV sequence). If your goal is to generate the waveform from scratch, I haven't seen any software to do that but it would be pretty trivial to write (probably a couple hundred lines of code). You just need to read the EIA-608 spec and understand how the byte pairs are represented in the waveform. You should also look more closely at the zvbi source code - it has the ability to create a dummy source which if I recall actually can work with osc (meaning it can generate the waveform internally). You would have to hack up the code to connect the parts and extract the actual image data. It's probably also worth mentioning that much of this is dependent on the output device you are using. Many devices don't actually let you put data into the VBI area just by including it in the image data. You typically have to use special APIs that are specific to the platform. Devin -- Devin J. Heitmueller - 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
