Re: Wintv-HVR-1120 woes
My WinTV-HVR-1120 works if I delete dvb-fe-tda10048-1.0.fw and rename dvb-fe-tda10046.fw in dvb-fe-tda10048-1.0.fw (see cf Hauppauge WinTV-HVR-1120 on Unbuntu 10.04 thread). After reboot my WinTV-HVR-1120 works. Ubuntu recognizes that the firmware isn't correct and doesn't load the firmware. But I know that isn't a good practice. - Messaggio originale - Da: Sasha Sirotkin demi...@femtolinux.com A: Albin Kauffmann albin.kauffm...@gmail.com Cc: linux-media@vger.kernel.org Inviato: Dom 24 ottobre 2010, 23:45:55 Oggetto: Re: Wintv-HVR-1120 woes On Sun, Oct 24, 2010 at 10:22 PM, Sasha Sirotkin demi...@femtolinux.com wrote: On Sun, Oct 24, 2010 at 8:55 PM, Albin Kauffmann albin.kauffm...@gmail.com wrote: On Thursday 21 October 2010 23:25:29 Sasha Sirotkin wrote: I'm having all sorts of troubles with Wintv-HVR-1120 on Ubuntu 10.10 (kernel 2.6.35-22). Judging from what I've seen on the net, including this mailing list, I'm not the only one not being able to use this card and no solution seem to exist. Problems: 1. The driver yells various cryptic error messages (tda18271_write_regs: [1-0060|M] ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5, tda18271_set_analog_params: [1-0060|M] error -5 on line 1045, etc) yes, indeed :( (cf Hauppauge WinTV-HVR-1120 on Unbuntu 10.04 thread) 2. DVB-T scan (using w_scan) produces no results Is this happening after each reboot? As far as I'm concerned, I've never had problems with DVB-T scans. Almost always. I think I had a lucky reboot or two, but most of the time DVB-T scan produces nothing. 3. Analog seems to work, but with very poor quality I just tried to use Analog TV in order to confirm the problem but I cannot get any picture. Maybe I just don't know how to use it. I'm using commands like (I'm located in France): mplayer tv:// -tv driver=v4l2:norm=SECAM:chanlist=france -tvscan autostart ... and just get some snow on scanned channels. As I might have a problem with my antenna (an interior one), I am going to test it under Windows and report back my experience. I'm using tvtime-scanner Cheers, -- Albin Kauffmann I'm trying to downgrade the kernel now to see if it helps I went back as far as 2.6.30 and I still have this problem. 2.6.29 does not recognize this card at all. -- 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: Wintv-HVR-1120 woes
Da: Sasha Sirotkin demi...@femtolinux.com A: fabio tirapelle ftirape...@yahoo.it Cc: Albin Kauffmann albin.kauffm...@gmail.com; linux-media@vger.kernel.org Inviato: Lun 25 ottobre 2010, 09:18:28 Oggetto: Re: Wintv-HVR-1120 woes On Mon, Oct 25, 2010 at 8:16 AM, fabio tirapelle ftirape...@yahoo.it wrote: My WinTV-HVR-1120 works if I delete dvb-fe-tda10048-1.0.fw and rename dvb-fe-tda10046.fw in dvb-fe-tda10048-1.0.fw (see cf Hauppauge WinTV-HVR-1120 on Unbuntu 10.04 thread). After reboot my WinTV-HVR-1120 works. Ubuntu recognizes that the firmware isn't correct and doesn't load the firmware. How come it works without the firmware !? Is it possible that you booted into Windows before that and there is a correct firmware already running in the card ? No my mediacenter works only on Ubuntu But I know that isn't a good practice. - Messaggio originale - Da: Sasha Sirotkin demi...@femtolinux.com A: Albin Kauffmann albin.kauffm...@gmail.com Cc: linux-media@vger.kernel.org Inviato: Dom 24 ottobre 2010, 23:45:55 Oggetto: Re: Wintv-HVR-1120 woes On Sun, Oct 24, 2010 at 10:22 PM, Sasha Sirotkin demi...@femtolinux.com wrote: On Sun, Oct 24, 2010 at 8:55 PM, Albin Kauffmann albin.kauffm...@gmail.com wrote: On Thursday 21 October 2010 23:25:29 Sasha Sirotkin wrote: I'm having all sorts of troubles with Wintv-HVR-1120 on Ubuntu 10.10 (kernel 2.6.35-22). Judging from what I've seen on the net, including this mailing list, I'm not the only one not being able to use this card and no solution seem to exist. Problems: 1. The driver yells various cryptic error messages (tda18271_write_regs: [1-0060|M] ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5, tda18271_set_analog_params: [1-0060|M] error -5 on line 1045, etc) yes, indeed :( (cf Hauppauge WinTV-HVR-1120 on Unbuntu 10.04 thread) 2. DVB-T scan (using w_scan) produces no results Is this happening after each reboot? As far as I'm concerned, I've never had problems with DVB-T scans. Almost always. I think I had a lucky reboot or two, but most of the time DVB-T scan produces nothing. 3. Analog seems to work, but with very poor quality I just tried to use Analog TV in order to confirm the problem but I cannot get any picture. Maybe I just don't know how to use it. I'm using commands like (I'm located in France): mplayer tv:// -tv driver=v4l2:norm=SECAM:chanlist=france -tvscan autostart ... and just get some snow on scanned channels. As I might have a problem with my antenna (an interior one), I am going to test it under Windows and report back my experience. I'm using tvtime-scanner Cheers, -- Albin Kauffmann I'm trying to downgrade the kernel now to see if it helps I went back as far as 2.6.30 and I still have this problem. 2.6.29 does not recognize this card at all. -- 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 -- 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: Wintv-HVR-1120 woes
On Mon, Oct 25, 2010 at 8:16 AM, fabio tirapelle ftirape...@yahoo.it wrote: My WinTV-HVR-1120 works if I delete dvb-fe-tda10048-1.0.fw and rename dvb-fe-tda10046.fw in dvb-fe-tda10048-1.0.fw (see cf Hauppauge WinTV-HVR-1120 on Unbuntu 10.04 thread). After reboot my WinTV-HVR-1120 works. Ubuntu recognizes that the firmware isn't correct and doesn't load the firmware. How come it works without the firmware !? Is it possible that you booted into Windows before that and there is a correct firmware already running in the card ? But I know that isn't a good practice. - Messaggio originale - Da: Sasha Sirotkin demi...@femtolinux.com A: Albin Kauffmann albin.kauffm...@gmail.com Cc: linux-media@vger.kernel.org Inviato: Dom 24 ottobre 2010, 23:45:55 Oggetto: Re: Wintv-HVR-1120 woes On Sun, Oct 24, 2010 at 10:22 PM, Sasha Sirotkin demi...@femtolinux.com wrote: On Sun, Oct 24, 2010 at 8:55 PM, Albin Kauffmann albin.kauffm...@gmail.com wrote: On Thursday 21 October 2010 23:25:29 Sasha Sirotkin wrote: I'm having all sorts of troubles with Wintv-HVR-1120 on Ubuntu 10.10 (kernel 2.6.35-22). Judging from what I've seen on the net, including this mailing list, I'm not the only one not being able to use this card and no solution seem to exist. Problems: 1. The driver yells various cryptic error messages (tda18271_write_regs: [1-0060|M] ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5, tda18271_set_analog_params: [1-0060|M] error -5 on line 1045, etc) yes, indeed :( (cf Hauppauge WinTV-HVR-1120 on Unbuntu 10.04 thread) 2. DVB-T scan (using w_scan) produces no results Is this happening after each reboot? As far as I'm concerned, I've never had problems with DVB-T scans. Almost always. I think I had a lucky reboot or two, but most of the time DVB-T scan produces nothing. 3. Analog seems to work, but with very poor quality I just tried to use Analog TV in order to confirm the problem but I cannot get any picture. Maybe I just don't know how to use it. I'm using commands like (I'm located in France): mplayer tv:// -tv driver=v4l2:norm=SECAM:chanlist=france -tvscan autostart ... and just get some snow on scanned channels. As I might have a problem with my antenna (an interior one), I am going to test it under Windows and report back my experience. I'm using tvtime-scanner Cheers, -- Albin Kauffmann I'm trying to downgrade the kernel now to see if it helps I went back as far as 2.6.30 and I still have this problem. 2.6.29 does not recognize this card at all. -- 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 -- 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
V4L hg doesn't compile for current stable kernel 2.6.36
hg hash abd3aac6644e tip make[2]: Entering directory `/usr/src/linux-2.6.36' CC [M] /tmp/v4l_dvb.20101025/v4l-dvb/v4l/dvbdev.o CC [M] /tmp/v4l_dvb.20101025/v4l-dvb/v4l/dmxdev.o /tmp/v4l_dvb.20101025/v4l-dvb/v4l/dmxdev.c:1142: error: unknown field 'ioctl' specified in initializer /tmp/v4l_dvb.20101025/v4l-dvb/v4l/dmxdev.c:1142: warning: initialization from incompatible pointer type /tmp/v4l_dvb.20101025/v4l-dvb/v4l/dmxdev.c:1211: error: unknown field 'ioctl' specified in initializer /tmp/v4l_dvb.20101025/v4l-dvb/v4l/dmxdev.c:1211: warning: initialization from incompatible pointer type make[3]: *** [/tmp/v4l_dvb.20101025/v4l-dvb/v4l/dmxdev.o] Error 1 make[2]: *** [_module_/tmp/v4l_dvb.20101025/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-2.6.36' make[1]: *** [default] Error 2 make[1]: Leaving directory `/tmp/v4l_dvb.20101025/v4l-dvb/v4l' make: *** [all] Error 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: Wintv-HVR-1120 woes
On Mon, Oct 25, 2010 at 9:24 AM, fabio tirapelle ftirape...@yahoo.it wrote: Da: Sasha Sirotkin demi...@femtolinux.com A: fabio tirapelle ftirape...@yahoo.it Cc: Albin Kauffmann albin.kauffm...@gmail.com; linux-media@vger.kernel.org Inviato: Lun 25 ottobre 2010, 09:18:28 Oggetto: Re: Wintv-HVR-1120 woes On Mon, Oct 25, 2010 at 8:16 AM, fabio tirapelle ftirape...@yahoo.it wrote: My WinTV-HVR-1120 works if I delete dvb-fe-tda10048-1.0.fw and rename dvb-fe-tda10046.fw in dvb-fe-tda10048-1.0.fw (see cf Hauppauge WinTV-HVR-1120 on Unbuntu 10.04 thread). After reboot my WinTV-HVR-1120 works. Ubuntu recognizes that the firmware isn't correct and doesn't load the firmware. How come it works without the firmware !? Is it possible that you booted into Windows before that and there is a correct firmware already running in the card ? No my mediacenter works only on Ubuntu This is weird. I will try this workaround tonight. I hope that anyone will eventually reveal an interest to solve this bug. I'd happily do it myself, but I cannot really afford to spend enough time to start digging into these sources, but I'm willing to help. But I know that isn't a good practice. - Messaggio originale - Da: Sasha Sirotkin demi...@femtolinux.com A: Albin Kauffmann albin.kauffm...@gmail.com Cc: linux-media@vger.kernel.org Inviato: Dom 24 ottobre 2010, 23:45:55 Oggetto: Re: Wintv-HVR-1120 woes On Sun, Oct 24, 2010 at 10:22 PM, Sasha Sirotkin demi...@femtolinux.com wrote: On Sun, Oct 24, 2010 at 8:55 PM, Albin Kauffmann albin.kauffm...@gmail.com wrote: On Thursday 21 October 2010 23:25:29 Sasha Sirotkin wrote: I'm having all sorts of troubles with Wintv-HVR-1120 on Ubuntu 10.10 (kernel 2.6.35-22). Judging from what I've seen on the net, including this mailing list, I'm not the only one not being able to use this card and no solution seem to exist. Problems: 1. The driver yells various cryptic error messages (tda18271_write_regs: [1-0060|M] ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5, tda18271_set_analog_params: [1-0060|M] error -5 on line 1045, etc) yes, indeed :( (cf Hauppauge WinTV-HVR-1120 on Unbuntu 10.04 thread) 2. DVB-T scan (using w_scan) produces no results Is this happening after each reboot? As far as I'm concerned, I've never had problems with DVB-T scans. Almost always. I think I had a lucky reboot or two, but most of the time DVB-T scan produces nothing. 3. Analog seems to work, but with very poor quality I just tried to use Analog TV in order to confirm the problem but I cannot get any picture. Maybe I just don't know how to use it. I'm using commands like (I'm located in France): mplayer tv:// -tv driver=v4l2:norm=SECAM:chanlist=france -tvscan autostart ... and just get some snow on scanned channels. As I might have a problem with my antenna (an interior one), I am going to test it under Windows and report back my experience. I'm using tvtime-scanner Cheers, -- Albin Kauffmann I'm trying to downgrade the kernel now to see if it helps I went back as far as 2.6.30 and I still have this problem. 2.6.29 does not recognize this card at all. -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 5/6 v5] V4L/DVB: s5p-fimc: Add camera capture support
Hi Sewoon,
thanks you for your further review!
-Original Message-
From: Sewoon Park [mailto:seuni.p...@samsung.com]
Sent: Thursday, October 21, 2010 10:21 AM
To: 'Sylwester Nawrocki'; linux-media@vger.kernel.org; linux-samsung-
s...@vger.kernel.org
Cc: m.szyprow...@samsung.com; kyungmin.p...@samsung.com
Subject: RE: [PATCH 5/6 v5] V4L/DVB: s5p-fimc: Add camera capture
support
Latest your reply is easy to understand.
And I send you another parts review comments.
Tuesday, October 12, 2010 2:27, Sylwester Nawrocki wrote :
Add a video device driver per each FIMC entity to support
the camera capture input mode. Video capture node is registered
only if CCD sensor data is provided through driver's platfrom data
and board setup code.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/video/s5p-fimc/Makefile |2 +-
drivers/media/video/s5p-fimc/fimc-capture.c | 819
+++
drivers/media/video/s5p-fimc/fimc-core.c| 563 +
--
drivers/media/video/s5p-fimc/fimc-core.h| 205 +++-
drivers/media/video/s5p-fimc/fimc-reg.c | 173 +-
include/media/s3c_fimc.h| 60 ++
6 files changed, 1630 insertions(+), 192 deletions(-)
create mode 100644 drivers/media/video/s5p-fimc/fimc-capture.c
create mode 100644 include/media/s3c_fimc.h
diff --git a/drivers/media/video/s5p-fimc/Makefile
b/drivers/media/video/s5p-fimc/Makefile
index 0d9d541..7ea1b14 100644
--- a/drivers/media/video/s5p-fimc/Makefile
+++ b/drivers/media/video/s5p-fimc/Makefile
@@ -1,3 +1,3 @@
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC) := s5p-fimc.o
-s5p-fimc-y := fimc-core.o fimc-reg.o
+s5p-fimc-y := fimc-core.o fimc-reg.o fimc-capture.o
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
new file mode 100644
index 000..e8f13d3
--- /dev/null
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -0,0 +1,819 @@
+/*
[snip]
+
+ vid_cap-input_index = -1;
+}
(snip)
+static int fimc_cap_s_fmt(struct file *file, void *priv,
+struct v4l2_format *f)
+{
+ struct fimc_ctx *ctx = priv;
+ struct fimc_dev *fimc = ctx-fimc_dev;
+ struct fimc_frame *frame;
+ struct v4l2_pix_format *pix;
+ int ret;
+
+ if (f-type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+
+ ret = fimc_vidioc_try_fmt(file, priv, f);
+ if (ret)
+ return ret;
+
+ if (mutex_lock_interruptible(fimc-lock))
+ return -ERESTARTSYS;
+
+ if (fimc_capture_active(fimc)) {
+ ret = -EBUSY;
+ goto sf_unlock;
+ }
I suggest to use vb_lock on here.
You already use vb_lock fimc_m2m_s_fmt function in fimc-core.c code
-- sample --
struct fimc_capture_device *cap = ctx-fimc_dev-vid_cap;
mutex_lock(cap-vbq-vb-lock);
I don't really think it is needed since the output frame parameters
are used only in fimc_cap_streamon() to setup the device and fimc-lock
is also used there for serialization. Can you point to any specific
use case where it is needed?
+
+ frame = ctx-d_frame;
+
+ pix = f-fmt.pix;
+ frame-fmt = find_format(f, FMT_FLAGS_M2M | FMT_FLAGS_CAM);
+ if (!frame-fmt) {
+ err(fimc target format not found\n);
+ ret = -EINVAL;
+ goto sf_unlock;
+ }
+
+ /* Output DMA frame pixel size and offsets. */
+ frame-f_width = pix-bytesperline * 8 / frame-fmt-depth;
+ frame-f_height = pix-height;
+ frame-width= pix-width;
+ frame-height = pix-height;
+ frame-o_width = pix-width;
+ frame-o_height = pix-height;
+ frame-size = (pix-width * pix-height * frame-fmt-depth)
3;
+ frame-offs_h = 0;
+ frame-offs_v = 0;
+
+ ret = sync_capture_fmt(ctx);
+
+ ctx-state |= (FIMC_PARAMS | FIMC_DST_FMT);
+
+sf_unlock:
+ mutex_unlock(fimc-lock);
+ return ret;
+}
(snip)
-static int fimc_prepare_config(struct fimc_ctx *ctx, u32 flags)
+int fimc_prepare_config(struct fimc_ctx *ctx, u32 flags)
{
struct fimc_frame *s_frame, *d_frame;
struct fimc_vid_buffer *buf = NULL;
@@ -513,9 +585,9 @@ static void fimc_dma_run(void *priv)
if (ctx-state FIMC_PARAMS)
fimc_hw_set_out_dma(ctx);
- ctx-state = 0;
fimc_activate_capture(ctx);
+ ctx-state = (FIMC_CTX_M2M | FIMC_CTX_CAP);
fimc_hw_activate_input_dma(fimc, true);
dma_unlock:
@@ -598,10 +670,31 @@ static void fimc_buf_queue(struct
videobuf_queue *vq,
struct videobuf_buffer *vb)
{
struct fimc_ctx *ctx = vq-priv_data;
- v4l2_m2m_buf_queue(ctx-m2m_ctx, vq, vb);
+ struct fimc_dev *fimc = ctx-fimc_dev;
+ struct fimc_vid_cap
Re: [PATCH v2 10/11] mt9m111: rewrite set_pixfmt
On Sat, Oct 02, 2010 at 10:03:55AM +0200, Guennadi Liakhovetski wrote: Michael, any insight? long time ago... For the YUV and RGB formats, tested and acked. For the bayer, I don't use it. With row switch, that gives back: byte offset: 0 1 2 3 B G B G G R G R Without the switch: byte offset: 0 1 2 3 G R G R B G B G I would have expected the second version (ie. without the switch, ie. the original version of mt9m111 driver) to be correct, but I might be wrong. Maybe Michael can enlighten me here. Yes this seems odd, i normaly expect the first line to be BGBG. I will search for the cause and reply a little later, perhaps end of the week, since i am also short on time at this moment. I have reviewed the Datasheet of the Camera and found Roberts previously described behaviour as correct. So the Bayercode seems functional in that patch. Ok, _if_ you have to redo this patch, maybe you could also merge [PATCH 04/11] mt9m111: added new bit offset defines [PATCH 08/11] mt9m111: added reg_mask function into it, otherwise their purpose is unclear. I will send a squashed Version of the three patches in some minutes. Cheers, Michael -- 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 v3] mt9m111: rewrite set_pixfmt
added new bit offset defines,
more supported BE colour formats
and also support BGR565 swapped pixel formats
removed pixfmt helper functions and option flags
setting the configuration register directly in set_pixfmt
added reg_mask function
reg_mask is basically the same as clearing setting registers,
but it is more convenient and faster (saves one rw cycle).
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
Signed-off-by: Philipp Wiesner p.wies...@phytec.de
---
Changes v1 - v2
* removed unrelated OPMODE handling in this function
Changes v2 - v3
* squashed: [PATCH 04/11] mt9m111: added new bit offset defines
* squashed: [PATCH 08/11] mt9m111: added reg_mask function
drivers/media/video/mt9m111.c | 176 +++--
1 files changed, 81 insertions(+), 95 deletions(-)
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index 3eeda19..9da30c0 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -63,6 +63,12 @@
#define MT9M111_RESET_RESTART_FRAME(1 1)
#define MT9M111_RESET_RESET_MODE (1 0)
+#define MT9M111_RM_FULL_POWER_RD (0 10)
+#define MT9M111_RM_LOW_POWER_RD(1 10)
+#define MT9M111_RM_COL_SKIP_4X (1 5)
+#define MT9M111_RM_ROW_SKIP_4X (1 4)
+#define MT9M111_RM_COL_SKIP_2X (1 3)
+#define MT9M111_RM_ROW_SKIP_2X (1 2)
#define MT9M111_RMB_MIRROR_COLS(1 1)
#define MT9M111_RMB_MIRROR_ROWS(1 0)
#define MT9M111_CTXT_CTRL_RESTART (1 15)
@@ -95,7 +101,8 @@
#define MT9M111_OPMODE_AUTOEXPO_EN (1 14)
#define MT9M111_OPMODE_AUTOWHITEBAL_EN (1 1)
-
+#define MT9M111_OUTFMT_FLIP_BAYER_COL (1 9)
+#define MT9M111_OUTFMT_FLIP_BAYER_ROW (1 8)
#define MT9M111_OUTFMT_PROCESSED_BAYER (1 14)
#define MT9M111_OUTFMT_BYPASS_IFP (1 10)
#define MT9M111_OUTFMT_INV_PIX_CLOCK (1 9)
@@ -113,6 +120,7 @@
#define MT9M111_OUTFMT_SWAP_YCbCr_C_Y (1 1)
#define MT9M111_OUTFMT_SWAP_RGB_EVEN (1 1)
#define MT9M111_OUTFMT_SWAP_YCbCr_Cb_Cr(1 0)
+#define MT9M111_OUTFMT_SWAP_RGB_R_B(1 0)
/*
* Camera control register addresses (0x200..0x2ff not implemented)
@@ -122,6 +130,8 @@
#define reg_write(reg, val) mt9m111_reg_write(client, MT9M111_##reg, (val))
#define reg_set(reg, val) mt9m111_reg_set(client, MT9M111_##reg, (val))
#define reg_clear(reg, val) mt9m111_reg_clear(client, MT9M111_##reg, (val))
+#define reg_mask(reg, val, mask) mt9m111_reg_mask(client, MT9M111_##reg, \
+ (val), (mask))
#define MT9M111_MIN_DARK_ROWS 8
#define MT9M111_MIN_DARK_COLS 26
@@ -148,12 +158,16 @@ static const struct mt9m111_datafmt *mt9m111_find_datafmt(
}
static const struct mt9m111_datafmt mt9m111_colour_fmts[] = {
- {V4L2_MBUS_FMT_YUYV8_2X8, V4L2_COLORSPACE_JPEG},
- {V4L2_MBUS_FMT_YVYU8_2X8, V4L2_COLORSPACE_JPEG},
- {V4L2_MBUS_FMT_UYVY8_2X8, V4L2_COLORSPACE_JPEG},
- {V4L2_MBUS_FMT_VYUY8_2X8, V4L2_COLORSPACE_JPEG},
+ {V4L2_MBUS_FMT_YUYV8_2X8_LE, V4L2_COLORSPACE_JPEG},
+ {V4L2_MBUS_FMT_YVYU8_2X8_LE, V4L2_COLORSPACE_JPEG},
+ {V4L2_MBUS_FMT_YUYV8_2X8_BE, V4L2_COLORSPACE_JPEG},
+ {V4L2_MBUS_FMT_YVYU8_2X8_BE, V4L2_COLORSPACE_JPEG},
{V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE, V4L2_COLORSPACE_SRGB},
+ {V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE, V4L2_COLORSPACE_SRGB},
{V4L2_MBUS_FMT_RGB565_2X8_LE, V4L2_COLORSPACE_SRGB},
+ {V4L2_MBUS_FMT_RGB565_2X8_BE, V4L2_COLORSPACE_SRGB},
+ {V4L2_MBUS_FMT_BGR565_2X8_LE, V4L2_COLORSPACE_SRGB},
+ {V4L2_MBUS_FMT_BGR565_2X8_BE, V4L2_COLORSPACE_SRGB},
{V4L2_MBUS_FMT_SBGGR8_1X8, V4L2_COLORSPACE_SRGB},
{V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE, V4L2_COLORSPACE_SRGB},
};
@@ -176,10 +190,6 @@ struct mt9m111 {
unsigned int powered:1;
unsigned int hflip:1;
unsigned int vflip:1;
- unsigned int swap_rgb_even_odd:1;
- unsigned int swap_rgb_red_blue:1;
- unsigned int swap_yuv_y_chromas:1;
- unsigned int swap_yuv_cb_cr:1;
unsigned int autowhitebalance:1;
};
@@ -251,6 +261,15 @@ static int mt9m111_reg_clear(struct i2c_client *client,
const u16 reg,
return mt9m111_reg_write(client, reg, ret ~data);
}
+static int mt9m111_reg_mask(struct i2c_client *client, const u16 reg,
+ const u16 data, const u16 mask)
+{
+ int ret;
+
+ ret = mt9m111_reg_read(client, reg);
+ return mt9m111_reg_write(client, reg, (ret ~mask) | data);
+}
+
static int mt9m111_set_context(struct i2c_client *client,
enum mt9m111_context ctxt)
{
@@ -312,68 +331,6 @@ static int mt9m111_setup_rect(struct i2c_client *client,
return ret;
}
-static int mt9m111_setup_pixfmt(struct i2c_client *client, u16 outfmt)
-{
- int ret;
-
- ret = reg_write(OUTPUT_FORMAT_CTRL2_A, outfmt);
- if (!ret)
- ret =
RE: [PATCH 1/7] v4l: add videobuf2 Video for Linux 2 driver framework
Hello,
On Monday, October 25, 2010 2:17 AM Pawel Osciak wrote:
On Tue, Oct 19, 2010 at 23:41, Marek Szyprowski
m.szyprow...@samsung.com wrote:
From: Pawel Osciak p.osc...@samsung.com
+/**
+ * __vb2_queue_cancel() - cancel and stop (pause) streaming
+ *
+ * Removes all queued buffers from driver's queue and all buffers queued by
+ * userspace from videobuf's queue. Returns to state after reqbufs.
+ */
+static void __vb2_queue_cancel(struct vb2_queue *q)
+{
+ /*
+ * Tell driver to stop all dma transactions and release all queued
+ * buffers
+ */
Just being picky, but those doesn't neccesarily are dma transactions.
Ok, I will change this comment.
+ if (q-streaming q-ops-stop_streaming)
+ q-ops-stop_streaming(q);
+ q-streaming = 0;
+
+ /*
+ * Remove all buffers from videobuf's list...
+ */
+ INIT_LIST_HEAD(q-queued_list);
+ /*
+ * ...and done list; userspace will not receive any buffers it
+ * has not already dequeued before initiating cancel.
+ */
+ INIT_LIST_HEAD(q-done_list);
+ wake_up_all(q-done_wq);
Any reason for replacing wake_up_interruptible_all with wake_up_all?
IMHO there is no reason to limit it to wake_up_interruptible_all.
Initially I thought that the driver MIGHT want to implement stop_streaming()
on top of this wait_queue, but later I abandoned this idea...
Best regards
--
Marek Szyprowski
Samsung Poland RD Center
--
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 5/7] v4l: videobuf2: add read() emulator
Hello,
On Monday, October 25, 2010 2:13 AM Pawel Osciak wrote:
Hi Marek,
This is a pretty crafty patch, you've managed to make it nice and
clean, without adding complexity to streaming code. Nice job. A few of
my comments below.
Thanks!
On Tue, Oct 19, 2010 at 23:41, Marek Szyprowski
m.szyprow...@samsung.com wrote:
Add a generic read() emulator for videobuf2. It uses MMAP memory type
buffers and generic vb2 calls: req_bufs, qbuf and dqbuf. Video date is
being copied from mmap buffers to userspace with standard copy_to_user()
function. To add read() support to the driver, only one additional
structure should be provides which defines the default number of buffers
used by emulator and detemines the style of read() emulation
('streaming' or 'one shot').
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Pawel Osciak pa...@osciak.com
---
drivers/media/video/videobuf2-core.c | 322
--
include/media/videobuf2-core.h | 21 +++
2 files changed, 325 insertions(+), 18 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 4a29c49..ab00246 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -471,7 +471,7 @@ static bool __buffers_in_use(struct vb2_queue *q)
* The return values from this function are intended to be directly returned
* from vidioc_reqbufs handler in driver.
*/
-int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req)
+static int __vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers
*req)
{
unsigned int num_buffers, num_planes;
int ret = 0;
@@ -482,8 +482,6 @@ int vb2_reqbufs(struct vb2_queue *q, struct
v4l2_requestbuffers *req)
return -EINVAL;
}
- mutex_lock(q-vb_lock);
-
if (req-type != q-type) {
dprintk(1, reqbufs: queue type invalid\n);
ret = -EINVAL;
@@ -567,6 +565,15 @@ end:
mutex_unlock(q-vb_lock);
return ret;
}
+
+int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req)
+{
+ int ret = 0;
+ mutex_lock(q-vb_lock);
+ ret = (q-read_data) ? -EBUSY : __vb2_reqbufs(q, req);
+ mutex_unlock(q-vb_lock);
+ return ret;
+}
EXPORT_SYMBOL_GPL(vb2_reqbufs);
/**
@@ -821,14 +828,11 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
* The return values from this function are intended to be directly returned
* from vidioc_qbuf handler in driver.
*/
-int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
+static int __vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
{
struct vb2_buffer *vb;
- int ret;
-
- mutex_lock(q-vb_lock);
+ int ret = -EINVAL;
- ret = -EINVAL;
if (b-type != q-type) {
dprintk(1, qbuf: invalid buffer type\n);
goto done;
@@ -887,6 +891,14 @@ int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer
*b)
dprintk(1, qbuf of buffer %d succeeded\n, vb-v4l2_buf.index);
ret = 0;
done:
+ return ret;
+}
+
+int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
+{
+ int ret = 0;
+ mutex_lock(q-vb_lock);
+ ret = (q-read_data) ? -EBUSY : __vb2_qbuf(q, b);
mutex_unlock(q-vb_lock);
return ret;
}
@@ -996,13 +1008,11 @@ end:
* The return values from this function are intended to be directly returned
* from vidioc_dqbuf handler in driver.
*/
-int vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer *b, bool nonblocking)
+static int __vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer *b, bool
nonblocking)
{
struct vb2_buffer *vb = NULL;
int ret;
- mutex_lock(q-vb_lock);
-
if (b-type != q-type) {
dprintk(1, dqbuf: invalid buffer type\n);
ret = -EINVAL;
@@ -1047,6 +1057,14 @@ int vb2_dqbuf(struct vb2_queue *q, struct
v4l2_buffer *b, bool nonblocking)
vb-state = VB2_BUF_STATE_DEQUEUED;
done:
+ return ret;
+}
+
+int vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer *b, bool nonblocking)
+{
+ int ret;
+ mutex_lock(q-vb_lock);
+ ret = (q-read_data) ? -EBUSY : __vb2_dqbuf(q, b, nonblocking);
mutex_unlock(q-vb_lock);
return ret;
}
@@ -1065,13 +1083,11 @@ EXPORT_SYMBOL_GPL(vb2_dqbuf);
* The return values from this function are intended to be directly returned
* from vidioc_streamon handler in the driver.
*/
-int vb2_streamon(struct vb2_queue *q, enum v4l2_buf_type type)
+static int __vb2_streamon(struct vb2_queue *q, enum v4l2_buf_type type)
{
struct vb2_buffer *vb;
int ret = 0;
- mutex_lock(q-vb_lock);
-
if
Re: Wintv-HVR-1120 woes
On Mon, Oct 25, 2010 at 9:46 AM, Sasha Sirotkin demi...@femtolinux.com wrote: On Mon, Oct 25, 2010 at 9:24 AM, fabio tirapelle ftirape...@yahoo.it wrote: Da: Sasha Sirotkin demi...@femtolinux.com A: fabio tirapelle ftirape...@yahoo.it Cc: Albin Kauffmann albin.kauffm...@gmail.com; linux-media@vger.kernel.org Inviato: Lun 25 ottobre 2010, 09:18:28 Oggetto: Re: Wintv-HVR-1120 woes On Mon, Oct 25, 2010 at 8:16 AM, fabio tirapelle ftirape...@yahoo.it wrote: My WinTV-HVR-1120 works if I delete dvb-fe-tda10048-1.0.fw and rename dvb-fe-tda10046.fw in dvb-fe-tda10048-1.0.fw (see cf Hauppauge WinTV-HVR-1120 on Unbuntu 10.04 thread). After reboot my WinTV-HVR-1120 works. Ubuntu recognizes that the firmware isn't correct and doesn't load the firmware. How come it works without the firmware !? Is it possible that you booted into Windows before that and there is a correct firmware already running in the card ? No my mediacenter works only on Ubuntu This is weird. I will try this workaround tonight. Actually, I think that the dvb-fe-tda10048-1.0.fw firmware is still loaded in the TV card and that this scenario has not changed anything. Fabio, have you tried to reboot several times in order to see if the problem is really fixed? And are you still getting some ERROR messages in `dmesg`? If not, this is good but I don't understand :) Cheers, -- Albin Kauffmann -- 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: Wintv-HVR-1120 woes
Da: Albin Kauffmann albin.kauffm...@gmail.com A: Sasha Sirotkin demi...@femtolinux.com Cc: fabio tirapelle ftirape...@yahoo.it; linux-media@vger.kernel.org Inviato: Lun 25 ottobre 2010, 13:20:13 Oggetto: Re: Wintv-HVR-1120 woes On Mon, Oct 25, 2010 at 9:46 AM, Sasha Sirotkin demi...@femtolinux.com wrote: On Mon, Oct 25, 2010 at 9:24 AM, fabio tirapelle ftirape...@yahoo.it wrote: Da: Sasha Sirotkin demi...@femtolinux.com A: fabio tirapelle ftirape...@yahoo.it Cc: Albin Kauffmann albin.kauffm...@gmail.com; linux-media@vger.kernel.org Inviato: Lun 25 ottobre 2010, 09:18:28 Oggetto: Re: Wintv-HVR-1120 woes On Mon, Oct 25, 2010 at 8:16 AM, fabio tirapelle ftirape...@yahoo.it wrote: My WinTV-HVR-1120 works if I delete dvb-fe-tda10048-1.0.fw and rename dvb-fe-tda10046.fw in dvb-fe-tda10048-1.0.fw (see cf Hauppauge WinTV-HVR-1120 on Unbuntu 10.04 thread). After reboot my WinTV-HVR-1120 works. Ubuntu recognizes that the firmware isn't correct and doesn't load the firmware. How come it works without the firmware !? Is it possible that you booted into Windows before that and there is a correct firmware already running in the card ? No my mediacenter works only on Ubuntu This is weird. I will try this workaround tonight. Actually, I think that the dvb-fe-tda10048-1.0.fw firmware is still loaded in the TV card and that this scenario has not changed anything. Fabio, have you tried to reboot several times in order to see if the problem is really fixed? And are you still getting some ERROR messages in `dmesg`? If not, this is good but I don't understand :) Yes, if several times means 3 times. But I think this isn't a good practice. So I have bought another card (NOVA-T-Stick) and I wait for a real solution. As I have written, the WinTV-1120 did work correctly with Ubunt 9.10. I haven't had problems with this version of Ubuntu. But the linux-firmware-nonfree package for Ubuntu 9.10 (karmic) didn't contain the dvb-fe-tda10048-1.0.fw (see http://packages.ubuntu.com/karmic/all/linux-firmware-nonfree/filelist) The dvb-fe-tda10048-1.0.fw was introduced with lucid (see http://packages.ubuntu.com/lucid/all/linux-firmware-nonfree/filelist). And now the question. Why without dvb-fe-tda10048-1.0.fw I haven't had problems and now with Ubuntu 10.04 I have problem exactly with this firmware? So I have renamed the dvb-fe-tda10046.fw in dvb-fe-tda10048-1.0.fw but I have seen that Ubuntu checks if the firmware is consistent. In the next two days I cannot post my dmesg, as I cannot access to my mediacenter. Tuesday night I will post it. What you think about my consideration about Ubuntu 9.10 and 10.04? Cheers, -- Albin Kauffmann -- 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 v3] media: Add timberdale video-in driver
This patch adds the timberdale video-in driver.
The video IP of timberdale delivers the video data via DMA.
The driver uses the DMA api to handle DMA transfers, and make use
of the V4L2 video buffers to handle buffers against user space.
If available the driver uses an encoder to get/set the video standard
Signed-off-by: Richard Röjfors richard.rojf...@pelagicore.com
---
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index f6e4d04..1afbe26 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -734,6 +734,15 @@ config VIDEO_HEXIUM_GEMINI
To compile this driver as a module, choose M here: the
module will be called hexium_gemini.
+config VIDEO_TIMBERDALE
+ tristate Support for timberdale Video In/LogiWIN
+ depends on VIDEO_V4L2 I2C
+ select TIMB_DMA
+ select VIDEO_ADV7180
+ select VIDEOBUF_DMA_CONTIG
+ ---help---
+ Add support for the Video In peripherial of the timberdale FPGA.
+
source drivers/media/video/cx88/Kconfig
source drivers/media/video/cx23885/Kconfig
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 40f98fb..c93af35 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -109,6 +109,7 @@ obj-$(CONFIG_VIDEO_CPIA2) += cpia2/
obj-$(CONFIG_VIDEO_MXB) += mxb.o
obj-$(CONFIG_VIDEO_HEXIUM_ORION) += hexium_orion.o
obj-$(CONFIG_VIDEO_HEXIUM_GEMINI) += hexium_gemini.o
+obj-$(CONFIG_VIDEO_TIMBERDALE) += timblogiw.o
obj-$(CONFIG_VIDEOBUF_GEN) += videobuf-core.o
obj-$(CONFIG_VIDEOBUF_DMA_SG) += videobuf-dma-sg.o
diff --git a/drivers/media/video/timblogiw.c b/drivers/media/video/timblogiw.c
new file mode 100644
index 000..a3a330f
--- /dev/null
+++ b/drivers/media/video/timblogiw.c
@@ -0,0 +1,894 @@
+/*
+ * timblogiw.c timberdale FPGA LogiWin Video In driver
+ * Copyright (c) 2009-2010 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+/* Supports:
+ * Timberdale FPGA LogiWin Video In
+ */
+
+#include linux/version.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/dmaengine.h
+#include linux/scatterlist.h
+#include linux/interrupt.h
+#include linux/list.h
+#include linux/i2c.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-device.h
+#include media/videobuf-dma-contig.h
+#include media/timb_video.h
+
+#define DRIVER_NAMEtimb-video
+
+#define TIMBLOGIWIN_NAME Timberdale Video-In
+#define TIMBLOGIW_VERSION_CODE 0x04
+
+#define TIMBLOGIW_LINES_PER_DESC 44
+#define TIMBLOGIW_MAX_VIDEO_MEM16
+
+#define TIMBLOGIW_HAS_DECODER(lw) (lw-pdata.encoder.module_name)
+
+
+struct timblogiw {
+ struct video_device video_dev;
+ struct v4l2_device v4l2_dev; /* mutual exclusion */
+ struct mutexlock;
+ struct device *dev;
+ struct timb_video_platform_data pdata;
+ struct v4l2_subdev *sd_enc;/* encoder */
+ boolopened;
+};
+
+struct timblogiw_tvnorm {
+ v4l2_std_id std;
+ u16 width;
+ u16 height;
+ u8 fps;
+};
+
+struct timblogiw_fh {
+ struct videobuf_queue vb_vidq;
+ struct timblogiw_tvnorm const *cur_norm;
+ struct list_headcapture;
+ struct dma_chan *chan;
+ spinlock_t queue_lock; /* mutual exclusion */
+ unsigned intframe_count;
+};
+
+struct timblogiw_buffer {
+ /* common v4l buffer stuff -- must be first */
+ struct videobuf_buffer vb;
+ struct scatterlist sg[16];
+ dma_cookie_tcookie;
+ struct timblogiw_fh *fh;
+};
+
+const struct timblogiw_tvnorm timblogiw_tvnorms[] = {
+ {
+ .std= V4L2_STD_PAL,
+ .width = 720,
+ .height = 576,
+ .fps= 25
+ },
+ {
+ .std= V4L2_STD_NTSC,
+ .width = 720,
+ .height = 480,
+ .fps= 30
+ }
+};
+
+static int timblogiw_bytes_per_line(const struct timblogiw_tvnorm *norm)
+{
+
[PATCH 0/2 v3] media, mfd: Add timberdale video-in driver
To follow are two patches. The first adds the timberdale video-in driver to the media tree. The second adds it to the timberdale MFD driver. Changes since last version: * Using the unlocked_ioctl to avoid BKL, instead using a mutex in the ioctl callbacks where needed. * The try_fmt function does _not_ set the format anymore. As Samuel pointed out earlier the patch to timberdale should be trivial so I hope Mauro can take the patches via his tree. Thanks --Richard -- 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 2/2 v3] mfd: Add timberdale video-in driver to timberdale
This patch defines platform data for the video-in driver
and adds it to all configurations of timberdale.
Signed-off-by: Richard Röjfors richard.rojf...@pelagicore.com
Acked-by: Samuel Ortiz sa...@linux.intel.com
---
diff --git a/drivers/mfd/timberdale.c b/drivers/mfd/timberdale.c
index ac59950..52a651b 100644
--- a/drivers/mfd/timberdale.c
+++ b/drivers/mfd/timberdale.c
@@ -40,6 +40,7 @@
#include linux/spi/mc33880.h
#include media/timb_radio.h
+#include media/timb_video.h
#include linux/timb_dma.h
@@ -238,7 +239,24 @@ static const __devinitconst struct resource
timberdale_uartlite_resources[] = {
},
};
-static const __devinitconst struct resource timberdale_radio_resources[] = {
+static __devinitdata struct i2c_board_info timberdale_adv7180_i2c_board_info =
{
+ /* Requires jumper JP9 to be off */
+ I2C_BOARD_INFO(adv7180, 0x42 1),
+ .irq = IRQ_TIMBERDALE_ADV7180
+};
+
+static __devinitdata struct timb_video_platform_data
+ timberdale_video_platform_data = {
+ .dma_channel = DMA_VIDEO_RX,
+ .i2c_adapter = 0,
+ .encoder = {
+ .module_name = adv7180,
+ .info = timberdale_adv7180_i2c_board_info
+ }
+};
+
+static const __devinitconst struct resource
+timberdale_radio_resources[] = {
{
.start = RDSOFFSET,
.end= RDSEND,
@@ -272,6 +290,18 @@ static __devinitdata struct timb_radio_platform_data
}
};
+static const __devinitconst struct resource timberdale_video_resources[] = {
+ {
+ .start = LOGIWOFFSET,
+ .end= LOGIWEND,
+ .flags = IORESOURCE_MEM,
+ },
+ /*
+ note that the frame buffer is located in DMA area
+ starting at 0x120
+ */
+};
+
static __devinitdata struct timb_dma_platform_data timb_dma_platform_data = {
.nr_channels = 10,
.channels = {
@@ -372,6 +402,13 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg0[] = {
.data_size = sizeof(timberdale_gpio_platform_data),
},
{
+ .name = timb-video,
+ .num_resources = ARRAY_SIZE(timberdale_video_resources),
+ .resources = timberdale_video_resources,
+ .platform_data = timberdale_video_platform_data,
+ .data_size = sizeof(timberdale_video_platform_data),
+ },
+ {
.name = timb-radio,
.num_resources = ARRAY_SIZE(timberdale_radio_resources),
.resources = timberdale_radio_resources,
@@ -430,6 +467,13 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg1[] = {
.resources = timberdale_mlogicore_resources,
},
{
+ .name = timb-video,
+ .num_resources = ARRAY_SIZE(timberdale_video_resources),
+ .resources = timberdale_video_resources,
+ .platform_data = timberdale_video_platform_data,
+ .data_size = sizeof(timberdale_video_platform_data),
+ },
+ {
.name = timb-radio,
.num_resources = ARRAY_SIZE(timberdale_radio_resources),
.resources = timberdale_radio_resources,
@@ -478,6 +522,13 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg2[] = {
.data_size = sizeof(timberdale_gpio_platform_data),
},
{
+ .name = timb-video,
+ .num_resources = ARRAY_SIZE(timberdale_video_resources),
+ .resources = timberdale_video_resources,
+ .platform_data = timberdale_video_platform_data,
+ .data_size = sizeof(timberdale_video_platform_data),
+ },
+ {
.name = timb-radio,
.num_resources = ARRAY_SIZE(timberdale_radio_resources),
.resources = timberdale_radio_resources,
@@ -521,6 +572,13 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg3[] = {
.data_size = sizeof(timberdale_gpio_platform_data),
},
{
+ .name = timb-video,
+ .num_resources = ARRAY_SIZE(timberdale_video_resources),
+ .resources = timberdale_video_resources,
+ .platform_data = timberdale_video_platform_data,
+ .data_size = sizeof(timberdale_video_platform_data),
+ },
+ {
.name = timb-radio,
.num_resources = ARRAY_SIZE(timberdale_radio_resources),
.resources = timberdale_radio_resources,
diff --git a/drivers/mfd/timberdale.h b/drivers/mfd/timberdale.h
index c11bf6e..4412acd 100644
--- a/drivers/mfd/timberdale.h
+++ b/drivers/mfd/timberdale.h
@@ -23,7 +23,7 @@
#ifndef MFD_TIMBERDALE_H
#define MFD_TIMBERDALE_H
-#define DRV_VERSION0.2
+#define DRV_VERSION0.3
/* This driver only support versions = 3.8 and 4.0 */
#define TIMB_SUPPORTED_MAJOR 3
--
To
[PATCH] bttv driver memory corruption
Hello, here is a bug report for the bttv driver and tentative patches to solve the problem. Two bugs are addressed, a memory corruption of random kernel pages and a race condition in the DMA RISC code. NOTE: this message was sent originally sent to video4linux-l...@redhat.com two months ago. Apparently developers no longer read that mailing list, so I'm forwarding the message here. I couldn't get checkpatch.pl to work so the patches are in plain 'hg diff' format. The card I am using is Osprey 440, Bt878 (rev 17). I have tested my patches on kernel 2.6.18-164.el5 (RHEL 5) which is the kernel on my target production machines. The V4L2_MEMORY_USERPTR method was not tested as I don't have the proper support functions in this kernel; I also don't know how to reliably allocate physically contiguous DMA32 memory in user space. I have checked that VBI capture doesn't crash the kernel but not that it works correctly. I haven't tested the capture of only a single field, odd or even. I've used the driver code revision ee9826bc7106 (hg). The stable tip crashes my kernel on module load and I don't have the resources to investigate this problem at this time. Memory corruption: The bt878 chipset has a hardware limitation on the buffers used to capture a line. Quote from the specification: The target memory for a given scan line of data is assumed to be linear, incrementing, and contiguous. For a 1024-pixel scan line a maximum of 4 KB of contiguous physical memory is required. Each scan line can be stored anywhere in the 32-bit address space. A scan line can be broken into segments with each segment sent to a different target area. An image buffer can be allocated to line fragments anywhere in the physical memory, as the line sequence is arbitrary. The fourth sentence seems to directly contradict the first but it appears that the first sentence is true. I've observed a memory corruption by allocating a single buffer twice as large as necessary, dividing it into pages and poisoning all of it. When the user memory maps a buffer, I allocate every even page from the poisoned buffer in the nopage fault handler. Picture: A=Allocated, P=Poison, PoisonedBuffer=APAPAPAP... I've observed that the poison was corrupted at some random pages, but always in the first four bytes. The value of those bytes is 0x23232323. This byte sequence often appears in kernel oops reports on my setup. I dumped the content of the RISC write instructions and noticed that while the corruptions are random, they always occur when the 'end of line' bit of the write instructions is not set and the instructions write data up to the end of a page. It looks like the DMA controller gets confused when it needs to write to non-contiguous memory. The first patch changes the use of scatter-gather buffers for a single contiguous buffer. I have emulated the scatter-gather behavior in the RISC subprogram setup code. Obviously the code can be made simpler when a single buffer is used. As a side note, the code in bttv_risc_planar() appears to choke if the number of bytes to write in 'todo' is not a multiple of 4, due to the horizontal shift. The use of line-based scatter-gather buffers does not seem appealing, since it requires memory copies to present user-space with the contiguous buffer that it expects. RISC program synchronization: All modifications to the main RISC program and its subprograms (i.e. the RISC instructions that fill the content of a buffer) and to the card registers are protected by a spinlock. However, the driver takes no provision to avoid race conditions with the DMA controller itself. Holding the spinlock or servicing an IRQ does not prevent the DMA controller from executing RISC instructions. This leads to a race condition that can crash the kernel. The current RISC program loops over all its instructions continuously. When a RISC interrupt is raised, the IRQ handler modifies the program, without knowing which instruction the DMA controller is currently executing. Usually, this will be the SYNC instruction for the odd field as this stalls the DMA controller for a while. If the IRQ handler is slow, which can happen when it waits on the spinlock, then the DMA controller will re-execute a subprogram capturing a field. The code tries to detect this situation with the is_active() macro but this method is not reliable. In the case where the IRQ handler dequeues a buffer while it is active, then a kernel crash can occur. Assuming the application quits at this point, the function bttv_dma_free() will find that the capture buffer is done and then free the buffer containing the RISC instructions being executed by the DMA controller. The proposed fix modifies the driver to solve this race condition. The implementation is kept as simple as possible and preserve the existing synchronization logic. The code is not optimal for performance as it needlessly causes an interrupt to be raised when both fields are being captured with the same
Re: Wintv-HVR-1120 woes
On Mon, Oct 25, 2010 at 1:51 PM, fabio tirapelle ftirape...@yahoo.it wrote: Da: Albin Kauffmann albin.kauffm...@gmail.com A: Sasha Sirotkin demi...@femtolinux.com Cc: fabio tirapelle ftirape...@yahoo.it; linux-media@vger.kernel.org Inviato: Lun 25 ottobre 2010, 13:20:13 Oggetto: Re: Wintv-HVR-1120 woes On Mon, Oct 25, 2010 at 9:46 AM, Sasha Sirotkin demi...@femtolinux.com wrote: On Mon, Oct 25, 2010 at 9:24 AM, fabio tirapelle ftirape...@yahoo.it wrote: Da: Sasha Sirotkin demi...@femtolinux.com A: fabio tirapelle ftirape...@yahoo.it Cc: Albin Kauffmann albin.kauffm...@gmail.com; linux-media@vger.kernel.org Inviato: Lun 25 ottobre 2010, 09:18:28 Oggetto: Re: Wintv-HVR-1120 woes On Mon, Oct 25, 2010 at 8:16 AM, fabio tirapelle ftirape...@yahoo.it wrote: My WinTV-HVR-1120 works if I delete dvb-fe-tda10048-1.0.fw and rename dvb-fe-tda10046.fw in dvb-fe-tda10048-1.0.fw (see cf Hauppauge WinTV-HVR-1120 on Unbuntu 10.04 thread). After reboot my WinTV-HVR-1120 works. Ubuntu recognizes that the firmware isn't correct and doesn't load the firmware. How come it works without the firmware !? Is it possible that you booted into Windows before that and there is a correct firmware already running in the card ? No my mediacenter works only on Ubuntu This is weird. I will try this workaround tonight. Actually, I think that the dvb-fe-tda10048-1.0.fw firmware is still loaded in the TV card and that this scenario has not changed anything. Fabio, have you tried to reboot several times in order to see if the problem is really fixed? And are you still getting some ERROR messages in `dmesg`? If not, this is good but I don't understand :) Yes, if several times means 3 times. But I think this isn't a good practice. So I have bought another card (NOVA-T-Stick) and I wait for a real solution. As I have written, the WinTV-1120 did work correctly with Ubunt 9.10. I haven't had problems with this version of Ubuntu. But the linux-firmware-nonfree package for Ubuntu 9.10 (karmic) didn't contain the dvb-fe-tda10048-1.0.fw (see http://packages.ubuntu.com/karmic/all/linux-firmware-nonfree/filelist) The dvb-fe-tda10048-1.0.fw was introduced with lucid (see http://packages.ubuntu.com/lucid/all/linux-firmware-nonfree/filelist). And now the question. Why without dvb-fe-tda10048-1.0.fw I haven't had problems and now with Ubuntu 10.04 I have problem exactly with this firmware? So I have renamed the dvb-fe-tda10046.fw in dvb-fe-tda10048-1.0.fw but I have seen that Ubuntu checks if the firmware is consistent. I did the same and it did not help me much - I get the same errors and DVB scan does not work. In the next two days I cannot post my dmesg, as I cannot access to my mediacenter. Tuesday night I will post it. What you think about my consideration about Ubuntu 9.10 and 10.04? Cheers, -- Albin Kauffmann -- 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: em28xx: Terratec Grabby no sound
Em 25-10-2010 15:24, Florian Klink escreveu:
Hi,
I recently bought a Terratec Grabby. The device has a S-Video and 3 Cinch
cables (sound left, sound right, video). I want to record some video
cassettes with it. (with a cinch-scart adapter).
I checked the signal, there is audio and video on it.
When I try to play the capture device with e.g. mplayer, I see no
sound, even with various options.
I can hear sound only by doing arecord -D hw:2,0 -r 32000 -c 2 -f S16_LE |
aplay -, but as soon as mplayer is starting, I can't hear anything
anymore.
...which means that using alsa as the sound device with mplayer doesn't
work either.
Am I missing something?
Maybe the amux is wrong. The only way to know for sure is to check the used
GPIO's,
via a USB snoop dump. Please take a look at linuxtv.org Wiki (search for
usbsnoop).
After getting the dump, please parse it and send me.
I checked the source code, Terratec Grabby support was introduced with
4557af9c5338605c85fe54f5ebba3d4b14a60ab8:
-
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index 7cb93fb..b4c78f2 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -1347,6 +1347,22 @@ struct em28xx_board em28xx_boards[] = {
.amux = EM28XX_AMUX_VIDEO,
} },
},
+[EM2860_BOARD_TERRATEC_GRABBY] = {
+.name= Terratec Grabby,
+.vchannels = 2,
+.tuner_type = TUNER_ABSENT,
+.decoder = EM28XX_SAA711X,
+.xclk= EM28XX_XCLK_FREQUENCY_12MHZ,
+.input = { {
+.type = EM28XX_VMUX_COMPOSITE1,
+.vmux = SAA7115_COMPOSITE0,
+.amux = EM28XX_AMUX_VIDEO2,
+}, {
+.type = EM28XX_VMUX_SVIDEO,
+.vmux = SAA7115_SVIDEO3,
+.amux = EM28XX_AMUX_VIDEO2,
+} },
+},
};
const unsigned int em28xx_bcount = ARRAY_SIZE(em28xx_boards);
@@ -1410,6 +1426,8 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM2870_BOARD_TERRATEC_XS },
{ USB_DEVICE(0x0ccd, 0x0047),
.driver_info = EM2880_BOARD_TERRATEC_PRODIGY_XS },
+{ USB_DEVICE(0x0ccd, 0x0096),
+.driver_info = EM2860_BOARD_TERRATEC_GRABBY },
{ USB_DEVICE(0x185b, 0x2870),
.driver_info = EM2870_BOARD_COMPRO_VIDEOMATE },
{ USB_DEVICE(0x185b, 0x2041),
diff --git a/drivers/media/video/em28xx/em28xx.h
b/drivers/media/video/em28xx/em28xx.h
index e801f78..fa2fb41 100644
--- a/drivers/media/video/em28xx/em28xx.h
+++ b/drivers/media/video/em28xx/em28xx.h
@@ -103,6 +103,7 @@
#define EM2860_BOARD_EASYCAP 64
#define EM2820_BOARD_IODATA_GVMVP_SZ 65
#define EM2880_BOARD_EMPIRE_DUAL_TV 66
+#define EM2860_BOARD_TERRATEC_GRABBY 67
/* Limits minimum and default number of buffers */
#define EM28XX_MIN_BUF 4
-
Is there maybe a wrong amux set? Which one could it be?
Is sound-usb-audio somehow conflicting with em28xx module?
I hope you have an idea what is wrong here!
Florian Klink
--
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
em28xx: Terratec Grabby no sound
Hi,
I recently bought a Terratec Grabby. The device has a S-Video and 3
Cinch
cables (sound left, sound right, video). I want to record some video
cassettes with it. (with a cinch-scart adapter).
I checked the signal, there is audio and video on it.
When I try to play the capture device with e.g. mplayer, I see no
sound, even with various options.
I can hear sound only by doing arecord -D hw:2,0 -r 32000 -c 2 -f
S16_LE |
aplay -, but as soon as mplayer is starting, I can't hear anything
anymore.
...which means that using alsa as the sound device with mplayer doesn't
work either.
Am I missing something?
I checked the source code, Terratec Grabby support was introduced with
4557af9c5338605c85fe54f5ebba3d4b14a60ab8:
-
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index 7cb93fb..b4c78f2 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -1347,6 +1347,22 @@ struct em28xx_board em28xx_boards[] = {
.amux = EM28XX_AMUX_VIDEO,
} },
},
+ [EM2860_BOARD_TERRATEC_GRABBY] = {
+ .name= Terratec Grabby,
+ .vchannels = 2,
+ .tuner_type = TUNER_ABSENT,
+ .decoder = EM28XX_SAA711X,
+ .xclk= EM28XX_XCLK_FREQUENCY_12MHZ,
+ .input = { {
+ .type = EM28XX_VMUX_COMPOSITE1,
+ .vmux = SAA7115_COMPOSITE0,
+ .amux = EM28XX_AMUX_VIDEO2,
+ }, {
+ .type = EM28XX_VMUX_SVIDEO,
+ .vmux = SAA7115_SVIDEO3,
+ .amux = EM28XX_AMUX_VIDEO2,
+ } },
+ },
};
const unsigned int em28xx_bcount = ARRAY_SIZE(em28xx_boards);
@@ -1410,6 +1426,8 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM2870_BOARD_TERRATEC_XS },
{ USB_DEVICE(0x0ccd, 0x0047),
.driver_info = EM2880_BOARD_TERRATEC_PRODIGY_XS },
+ { USB_DEVICE(0x0ccd, 0x0096),
+ .driver_info = EM2860_BOARD_TERRATEC_GRABBY },
{ USB_DEVICE(0x185b, 0x2870),
.driver_info = EM2870_BOARD_COMPRO_VIDEOMATE },
{ USB_DEVICE(0x185b, 0x2041),
diff --git a/drivers/media/video/em28xx/em28xx.h
b/drivers/media/video/em28xx/em28xx.h
index e801f78..fa2fb41 100644
--- a/drivers/media/video/em28xx/em28xx.h
+++ b/drivers/media/video/em28xx/em28xx.h
@@ -103,6 +103,7 @@
#define EM2860_BOARD_EASYCAP 64
#define EM2820_BOARD_IODATA_GVMVP_SZ 65
#define EM2880_BOARD_EMPIRE_DUAL_TV 66
+#define EM2860_BOARD_TERRATEC_GRABBY 67
/* Limits minimum and default number of buffers */
#define EM28XX_MIN_BUF 4
-
Is there maybe a wrong amux set? Which one could it be?
Is sound-usb-audio somehow conflicting with em28xx module?
I hope you have an idea what is wrong here!
Florian Klink
--
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
[V4L][SAA7134] fix tda9887 detection on cold and eeprom read corruption on warm Medion 7134
[V4L][SAA7134] fix tda9887 detection on cold and eeprom read corruption on warm
Medion 7134
When Medion 7134 analog+DVB-T card is cold (after powerup) the tda9887 analog
demodulator
won't show on i2c bus.
This results in no signal on analog TV. After loading driver for second time
eeprom (required for tuner autodetection) read is corrupted, but tda9987 is
detected
properly and analog TV works when tuner model is forced.
Fix tda9887 problem by moving its detect code after tuner setup which unhides
it.
The eeprom read issue is fixed by opening i2c gate in DVB-T demodulator.
Tested on Medion 7134 and also tested for reference on Typhoon Cardbus Hybrid
(which also uses saa7134 driver).
Signed-off-by: Maciej Szmigiero m...@o2.pl
--- a/drivers/media/video/saa7134/saa7134-cards.c 2010-08-02
00:11:14.0 +0200
+++ b/drivers/media/video/saa7134/saa7134-cards.c 2010-10-25
19:19:08.0 +0200
@@ -7249,12 +7249,37 @@
break;
case SAA7134_BOARD_MD7134:
{
- u8 subaddr;
+ u8 subaddr, dmdregval;
u8 data[3];
int ret, tuner_t;
+ struct i2c_msg i2cgatemsg_r[] = { {.addr = 0x08, .flags = 0,
+ .buf = subaddr, .len = 1},
+ {.addr = 0x08,
+ .flags = I2C_M_RD,
+ .buf = dmdregval, .len = 1} };
+ struct i2c_msg i2cgatemsg_w[] = { {.addr = 0x08, .flags = 0,
+ .buf = data, .len = 2} };
struct i2c_msg msg[] = {{.addr=0x50, .flags=0, .buf=subaddr,
.len = 1},
{.addr=0x50, .flags=I2C_M_RD,
.buf=data, .len = 3}};
+ /* open i2c gate in DVB-T demod */
+ /* so eeprom read won't be corrupted */
+ subaddr = 0x7;
+ ret = i2c_transfer(dev-i2c_adap, i2cgatemsg_r, 2);
+ if ((ret == 2) (dmdregval 0x2)) {
+ printk(KERN_NOTICE %s DVB-T demod i2c gate was left
+closed\n, dev-name);
+ printk(KERN_NOTICE %s previous informational
+EEPROM read might have been
+corrupted\n, dev-name);
+
+ data[0] = 0x7;
+ data[1] = (dmdregval ~0x2);
+ if (i2c_transfer(dev-i2c_adap, i2cgatemsg_w, 1) != 1)
+ printk(KERN_ERR early i2c gate
+open failure\n);
+ }
+
subaddr= 0x14;
tuner_t = 0;
@@ -7522,10 +7547,6 @@
v4l2_i2c_new_subdev(dev-v4l2_dev,
dev-i2c_adap, tuner, tuner,
dev-radio_addr, NULL);
- if (has_demod)
- v4l2_i2c_new_subdev(dev-v4l2_dev,
- dev-i2c_adap, tuner, tuner,
- 0, v4l2_i2c_tuner_addrs(ADDRS_DEMOD));
if (dev-tuner_addr == ADDR_UNSET) {
enum v4l2_i2c_tuner_type type =
has_demod ? ADDRS_TV_WITH_DEMOD : ADDRS_TV;
@@ -7542,6 +7563,15 @@
saa7134_tuner_setup(dev);
+ /* some cards (Medion 7134 for example) needs tuner to be setup */
+ /* before tda9887 shows itself on i2c bus */
+ if ((TUNER_ABSENT != dev-tuner_type)
+(dev-tda9887_conf TDA9887_PRESENT)) {
+ v4l2_i2c_new_subdev(dev-v4l2_dev,
+ dev-i2c_adap, tuner, tuner,
+ 0, v4l2_i2c_tuner_addrs(ADDRS_DEMOD));
+ }
+
switch (dev-board) {
case SAA7134_BOARD_BEHOLD_COLUMBUS_TVFM:
case SAA7134_BOARD_AVERMEDIA_CARDBUS_501:
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.26 and up: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Mon Oct 25 19:00:21 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15167:abd3aac6644e git master: 3e6dce76d99b328716b43929b9195adfee1de00c git media-master: a348e9110ddb5d494e060d989b35dd1f35359d58 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: 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.32.6-armv5: WARNINGS linux-2.6.33-armv5: WARNINGS linux-2.6.34-armv5: WARNINGS linux-2.6.35.3-armv5: WARNINGS linux-2.6.32.6-armv5-davinci: ERRORS linux-2.6.33-armv5-davinci: ERRORS linux-2.6.34-armv5-davinci: ERRORS linux-2.6.35.3-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: ERRORS linux-2.6.33-armv5-ixp: ERRORS linux-2.6.34-armv5-ixp: ERRORS linux-2.6.35.3-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: ERRORS linux-2.6.33-armv5-omap2: ERRORS linux-2.6.34-armv5-omap2: ERRORS linux-2.6.35.3-armv5-omap2: ERRORS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: 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.32.6-m32r: WARNINGS linux-2.6.33-m32r: WARNINGS linux-2.6.34-m32r: WARNINGS linux-2.6.35.3-m32r: WARNINGS linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-mips: WARNINGS linux-2.6.35.3-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-powerpc64: WARNINGS linux-2.6.35.3-powerpc64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS spec-git: OK 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
[ANNOUNCE] mercurial backport tree is needing a new maintainer
Hello, I am just writing to officially say that I cannot maintain the hg backport tree anymore. Sorry for this, I *really* tried to help here, but, since I know some people still like to use it I prefer write this email. Unfortunately due my current activities I cannot give attention which this task requires. Also, if I could say something here for the next person which will take care about it. - Doing backport manually from 200 to 400 backports doesn't work - Making a script to do it, also not good approach since it will break because of our macros. The best opition here to my eyes, is tar the current -git tree and make a directory with the backports (Mauro's new build system). This will save a lot of time: - no need to backport the current patches coming - will keep the tree updated - Minize the backport job. I will keep around, helping the group with what I can. Cheers Douglas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] mt9m111: rewrite set_pixfmt
On Mon, 25 Oct 2010, Michael Grzeschik wrote:
added new bit offset defines,
more supported BE colour formats
and also support BGR565 swapped pixel formats
removed pixfmt helper functions and option flags
setting the configuration register directly in set_pixfmt
added reg_mask function
reg_mask is basically the same as clearing setting registers,
but it is more convenient and faster (saves one rw cycle).
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
Signed-off-by: Philipp Wiesner p.wies...@phytec.de
---
Changes v1 - v2
* removed unrelated OPMODE handling in this function
Changes v2 - v3
* squashed: [PATCH 04/11] mt9m111: added new bit offset defines
* squashed: [PATCH 08/11] mt9m111: added reg_mask function
drivers/media/video/mt9m111.c | 176
+++--
1 files changed, 81 insertions(+), 95 deletions(-)
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index 3eeda19..9da30c0 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -63,6 +63,12 @@
#define MT9M111_RESET_RESTART_FRAME (1 1)
#define MT9M111_RESET_RESET_MODE (1 0)
+#define MT9M111_RM_FULL_POWER_RD (0 10)
+#define MT9M111_RM_LOW_POWER_RD (1 10)
+#define MT9M111_RM_COL_SKIP_4X (1 5)
+#define MT9M111_RM_ROW_SKIP_4X (1 4)
+#define MT9M111_RM_COL_SKIP_2X (1 3)
+#define MT9M111_RM_ROW_SKIP_2X (1 2)
#define MT9M111_RMB_MIRROR_COLS (1 1)
#define MT9M111_RMB_MIRROR_ROWS (1 0)
#define MT9M111_CTXT_CTRL_RESTART(1 15)
@@ -95,7 +101,8 @@
#define MT9M111_OPMODE_AUTOEXPO_EN (1 14)
#define MT9M111_OPMODE_AUTOWHITEBAL_EN (1 1)
-
+#define MT9M111_OUTFMT_FLIP_BAYER_COL (1 9)
+#define MT9M111_OUTFMT_FLIP_BAYER_ROW (1 8)
#define MT9M111_OUTFMT_PROCESSED_BAYER (1 14)
#define MT9M111_OUTFMT_BYPASS_IFP(1 10)
#define MT9M111_OUTFMT_INV_PIX_CLOCK (1 9)
@@ -113,6 +120,7 @@
#define MT9M111_OUTFMT_SWAP_YCbCr_C_Y(1 1)
#define MT9M111_OUTFMT_SWAP_RGB_EVEN (1 1)
#define MT9M111_OUTFMT_SWAP_YCbCr_Cb_Cr (1 0)
+#define MT9M111_OUTFMT_SWAP_RGB_R_B (1 0)
/*
* Camera control register addresses (0x200..0x2ff not implemented)
@@ -122,6 +130,8 @@
#define reg_write(reg, val) mt9m111_reg_write(client, MT9M111_##reg, (val))
#define reg_set(reg, val) mt9m111_reg_set(client, MT9M111_##reg, (val))
#define reg_clear(reg, val) mt9m111_reg_clear(client, MT9M111_##reg, (val))
+#define reg_mask(reg, val, mask) mt9m111_reg_mask(client, MT9M111_##reg, \
+ (val), (mask))
#define MT9M111_MIN_DARK_ROWS8
#define MT9M111_MIN_DARK_COLS26
@@ -148,12 +158,16 @@ static const struct mt9m111_datafmt
*mt9m111_find_datafmt(
}
static const struct mt9m111_datafmt mt9m111_colour_fmts[] = {
- {V4L2_MBUS_FMT_YUYV8_2X8, V4L2_COLORSPACE_JPEG},
- {V4L2_MBUS_FMT_YVYU8_2X8, V4L2_COLORSPACE_JPEG},
- {V4L2_MBUS_FMT_UYVY8_2X8, V4L2_COLORSPACE_JPEG},
- {V4L2_MBUS_FMT_VYUY8_2X8, V4L2_COLORSPACE_JPEG},
+ {V4L2_MBUS_FMT_YUYV8_2X8_LE, V4L2_COLORSPACE_JPEG},
+ {V4L2_MBUS_FMT_YVYU8_2X8_LE, V4L2_COLORSPACE_JPEG},
+ {V4L2_MBUS_FMT_YUYV8_2X8_BE, V4L2_COLORSPACE_JPEG},
+ {V4L2_MBUS_FMT_YVYU8_2X8_BE, V4L2_COLORSPACE_JPEG},
This looks to me like you're breaking the driver. Please, develop against
a recent v4l tree, or, in fact, against next. With this in mind, I don't
think we still have a realistic chance to get this in for 2.6.37. In fact,
it is _already_ too late, so, no way, sorry.
{V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE, V4L2_COLORSPACE_SRGB},
+ {V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE, V4L2_COLORSPACE_SRGB},
{V4L2_MBUS_FMT_RGB565_2X8_LE, V4L2_COLORSPACE_SRGB},
+ {V4L2_MBUS_FMT_RGB565_2X8_BE, V4L2_COLORSPACE_SRGB},
+ {V4L2_MBUS_FMT_BGR565_2X8_LE, V4L2_COLORSPACE_SRGB},
+ {V4L2_MBUS_FMT_BGR565_2X8_BE, V4L2_COLORSPACE_SRGB},
{V4L2_MBUS_FMT_SBGGR8_1X8, V4L2_COLORSPACE_SRGB},
{V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE, V4L2_COLORSPACE_SRGB},
};
@@ -176,10 +190,6 @@ struct mt9m111 {
unsigned int powered:1;
unsigned int hflip:1;
unsigned int vflip:1;
- unsigned int swap_rgb_even_odd:1;
- unsigned int swap_rgb_red_blue:1;
- unsigned int swap_yuv_y_chromas:1;
- unsigned int swap_yuv_cb_cr:1;
unsigned int autowhitebalance:1;
};
@@ -251,6 +261,15 @@ static int mt9m111_reg_clear(struct i2c_client *client,
const u16 reg,
return mt9m111_reg_write(client, reg, ret ~data);
}
+static int mt9m111_reg_mask(struct i2c_client *client, const u16 reg,
+ const u16 data, const u16 mask)
+{
+ int ret;
+
+ ret = mt9m111_reg_read(client, reg);
+ return mt9m111_reg_write(client, reg, (ret ~mask) | data);
Ok, I feel ashamed, that I have accepted
Re: em28xx: Terratec Grabby no sound
Em 25-10-2010 18:24, Florian Klink escreveu:
Hi Mauro,
thanks for your answer!
I'm c/c the mailing list, as this info may be useful for the others.
It would be nice to have this added to wiki, but I won't have time for it,
unfortunately.
Maybe the amux is wrong. The only way to know for sure is to check
the used GPIO's,
via a USB snoop dump. Please take a look at linuxtv.org Wiki (search
for usbsnoop).
After getting the dump, please parse it and send me.
I did the usbsnooping and hope I did the parsing right (At least the log
file shrinked from 100MB to some KB, and there are plenty of EM28XX
strings inside ;-))
You can get it here: http://pastebin.com/SXKfLUny
There are a few things that are relevant:
First of all, GPIO's. They enable/disable parts of the board:
$ grep GPIO /tmp/dump
em28xx_write_reg(dev, EM28XX_R08_GPIO, 0xff);
em28xx_read_reg(dev, EM28XX_R08_GPIO); /* read 0xff */
em28xx_write_reg(dev, EM28XX_R08_GPIO, 0xfd);
em28xx_read_reg(dev, EM28XX_R08_GPIO); /* read 0xfd */
em28xx_write_reg(dev, EM28XX_R08_GPIO, 0xfd);
em28xx_read_reg(dev, EM28XX_R08_GPIO); /* read 0xfd */
em28xx_write_reg(dev, EM28XX_R08_GPIO, 0x7d);
em28xx_write_reg(dev, EM28XX_R08_GPIO, 0x2a);
em28xx_write_reg(dev, EM28XX_R08_GPIO, 0x2a);
Currently, they're not touched for this device. Perhaps, we might need to
initialize
them to 0xfd for capture mode, and 0x2a for sleep mode.
In this specific case, maybe it is just safe to keep it as-is, as I suspect
that GPIO's
are not used on this device. I may be wrong, though. A simple test will tell.
The audio entries are related to the ac97 chip.
The driver will basically run this code:
amux = EM28XX_AMUX_VIDEO2; /* from Terratec Grabby entry, at
em28xx-cards.c */
static struct em28xx_vol_table inputs[] = {
{ EM28XX_AMUX_VIDEO,AC97_VIDEO_VOL },
{ EM28XX_AMUX_LINE_IN, AC97_LINEIN_VOL },
{ EM28XX_AMUX_PHONE,AC97_PHONE_VOL },
{ EM28XX_AMUX_MIC, AC97_MIC_VOL },
{ EM28XX_AMUX_CD, AC97_CD_VOL },
{ EM28XX_AMUX_AUX, AC97_AUX_VOL },
{ EM28XX_AMUX_PCM_OUT, AC97_PCM_OUT_VOL },
if (amux == inputs[i].mux)
ret = em28xx_write_ac97(dev, inputs[i].reg, 0x0808);
/* Put the volume in 50% */
else
ret = em28xx_write_ac97(dev, inputs[i].reg, 0x8000);
/* Mute the volume */
Any mixer entry equal or bigger than 0x8000 is muted.
$ grep 97 dump
em28xx_read_ac97(dev, AC97_VENDOR_ID1); /* read 0x0x8384 */
em28xx_read_ac97(dev, AC97_VENDOR_ID2); /* read 0x0x7652 */
em28xx_write_ac97(dev, AC97_LINEIN_VOL, 0x0808);
em28xx_write_ac97(dev, AC97_VIDEO_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_AUX_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_MIC_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x8000);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x8000);
em28xx_write_ac97(dev, AC97_POWER_DOWN_CTRL, 0x4200);
em28xx_write_ac97(dev, AC97_RECORD_SELECT, 0x0505);
em28xx_write_ac97(dev, AC97_EXT_AUD_CTRL, 0x0031);
em28xx_write_ac97(dev, AC97_PCM_IN_SRATE, 0xbb80);
em28xx_write_ac97(dev, AC97_LINEIN_VOL, 0x0808);
em28xx_write_ac97(dev, AC97_VIDEO_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_AUX_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_MIC_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x8000);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x8000);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x8000);
em28xx_write_ac97(dev, AC97_LINEIN_VOL, 0x0808);
em28xx_write_ac97(dev, AC97_VIDEO_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_AUX_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_MIC_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x);
em28xx_write_ac97(dev, AC97_LINEIN_VOL, 0x0808);
em28xx_write_ac97(dev, AC97_VIDEO_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_AUX_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_MIC_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x8000);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x8000);
em28xx_write_ac97(dev, AC97_POWER_DOWN_CTRL, 0x4200);
em28xx_write_ac97(dev, AC97_RECORD_SELECT, 0x0505);
em28xx_write_ac97(dev, AC97_EXT_AUD_CTRL, 0x0031);
em28xx_write_ac97(dev, AC97_PCM_IN_SRATE, 0xbb80);
em28xx_write_ac97(dev, AC97_LINEIN_VOL, 0x0808);
em28xx_write_ac97(dev, AC97_VIDEO_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_AUX_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_MIC_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x8000);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x8000);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x8000);
em28xx_write_ac97(dev, AC97_LINEIN_VOL, 0x0808);
em28xx_write_ac97(dev, AC97_VIDEO_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_AUX_VOL, 0x9010);
em28xx_write_ac97(dev,
Re: em28xx: Terratec Grabby no sound
Hi,
I'm not very familiar with mailing lists, sorry!
Patched em28xx-cards.c, but no luck with
mplayer -v -tv driver=v4l2:input=0:device=/dev/video1:forceaudio tv://
(/dev/video0 is webcam). I'm able to see the video, but still no sound
in mplayer
playing the sound with arecord works (i think it goes over the
snd-usb-audio module,
but don't know why some mplayer -v -tv
driver=v4l2:input=0:device=/dev/video1:alsa:adevice=hw.2,0:forceaudio
tv:// magic won't do the job.
And shouldn't the sound go over v4l, too?
Florian
On Mon, 25 Oct 2010 18:51:15 -0200, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em 25-10-2010 18:24, Florian Klink escreveu:
Hi Mauro,
thanks for your answer!
I'm c/c the mailing list, as this info may be useful for the others.
It would be nice to have this added to wiki, but I won't have time
for it,
unfortunately.
Maybe the amux is wrong. The only way to know for sure is to check
the used GPIO's,
via a USB snoop dump. Please take a look at linuxtv.org Wiki
(search
for usbsnoop).
After getting the dump, please parse it and send me.
I did the usbsnooping and hope I did the parsing right (At least the
log
file shrinked from 100MB to some KB, and there are plenty of EM28XX
strings inside ;-))
You can get it here: http://pastebin.com/SXKfLUny
There are a few things that are relevant:
First of all, GPIO's. They enable/disable parts of the board:
$ grep GPIO /tmp/dump
em28xx_write_reg(dev, EM28XX_R08_GPIO, 0xff);
em28xx_read_reg(dev, EM28XX_R08_GPIO); /* read 0xff */
em28xx_write_reg(dev, EM28XX_R08_GPIO, 0xfd);
em28xx_read_reg(dev, EM28XX_R08_GPIO); /* read 0xfd */
em28xx_write_reg(dev, EM28XX_R08_GPIO, 0xfd);
em28xx_read_reg(dev, EM28XX_R08_GPIO); /* read 0xfd */
em28xx_write_reg(dev, EM28XX_R08_GPIO, 0x7d);
em28xx_write_reg(dev, EM28XX_R08_GPIO, 0x2a);
em28xx_write_reg(dev, EM28XX_R08_GPIO, 0x2a);
Currently, they're not touched for this device. Perhaps, we might
need to initialize
them to 0xfd for capture mode, and 0x2a for sleep mode.
In this specific case, maybe it is just safe to keep it as-is, as I
suspect that GPIO's
are not used on this device. I may be wrong, though. A simple test
will tell.
The audio entries are related to the ac97 chip.
The driver will basically run this code:
amux = EM28XX_AMUX_VIDEO2; /* from Terratec Grabby entry, at
em28xx-cards.c */
static struct em28xx_vol_table inputs[] = {
{ EM28XX_AMUX_VIDEO,AC97_VIDEO_VOL },
{ EM28XX_AMUX_LINE_IN, AC97_LINEIN_VOL },
{ EM28XX_AMUX_PHONE,AC97_PHONE_VOL },
{ EM28XX_AMUX_MIC, AC97_MIC_VOL },
{ EM28XX_AMUX_CD, AC97_CD_VOL },
{ EM28XX_AMUX_AUX, AC97_AUX_VOL },
{ EM28XX_AMUX_PCM_OUT, AC97_PCM_OUT_VOL },
if (amux == inputs[i].mux)
ret = em28xx_write_ac97(dev, inputs[i].reg, 0x0808);
/* Put the
volume in 50% */
else
ret = em28xx_write_ac97(dev, inputs[i].reg, 0x8000);
/* Mute the
volume */
Any mixer entry equal or bigger than 0x8000 is muted.
$ grep 97 dump
em28xx_read_ac97(dev, AC97_VENDOR_ID1); /* read 0x0x8384 */
em28xx_read_ac97(dev, AC97_VENDOR_ID2); /* read 0x0x7652 */
em28xx_write_ac97(dev, AC97_LINEIN_VOL, 0x0808);
em28xx_write_ac97(dev, AC97_VIDEO_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_AUX_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_MIC_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x8000);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x8000);
em28xx_write_ac97(dev, AC97_POWER_DOWN_CTRL, 0x4200);
em28xx_write_ac97(dev, AC97_RECORD_SELECT, 0x0505);
em28xx_write_ac97(dev, AC97_EXT_AUD_CTRL, 0x0031);
em28xx_write_ac97(dev, AC97_PCM_IN_SRATE, 0xbb80);
em28xx_write_ac97(dev, AC97_LINEIN_VOL, 0x0808);
em28xx_write_ac97(dev, AC97_VIDEO_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_AUX_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_MIC_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x8000);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x8000);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x8000);
em28xx_write_ac97(dev, AC97_LINEIN_VOL, 0x0808);
em28xx_write_ac97(dev, AC97_VIDEO_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_AUX_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_MIC_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x);
em28xx_write_ac97(dev, AC97_LINEIN_VOL, 0x0808);
em28xx_write_ac97(dev, AC97_VIDEO_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_AUX_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_MIC_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x8000);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x8000);
em28xx_write_ac97(dev, AC97_POWER_DOWN_CTRL, 0x4200);
em28xx_write_ac97(dev, AC97_RECORD_SELECT, 0x0505);
Re: em28xx: Terratec Grabby no sound
Em 25-10-2010 20:06, Florian Klink escreveu:
Hi,
I'm not very familiar with mailing lists, sorry!
Patched em28xx-cards.c, but no luck with
mplayer -v -tv driver=v4l2:input=0:device=/dev/video1:forceaudio tv://
(/dev/video0 is webcam). I'm able to see the video, but still no sound in
mplayer
playing the sound with arecord works (i think it goes over the snd-usb-audio
module,
but don't know why some mplayer -v -tv
driver=v4l2:input=0:device=/dev/video1:alsa:adevice=hw.2,0:forceaudio tv://
magic won't do the job.
And shouldn't the sound go over v4l, too?
The sound comes from alsa device. Several em28xx types provide standard USB
audio. So,
snd-usb-audio handles it. That's why you need alsa:adevice=hw.2,0:forceaudio at
mplayer.
Florian
On Mon, 25 Oct 2010 18:51:15 -0200, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em 25-10-2010 18:24, Florian Klink escreveu:
Hi Mauro,
thanks for your answer!
I'm c/c the mailing list, as this info may be useful for the others.
It would be nice to have this added to wiki, but I won't have time for it,
unfortunately.
Maybe the amux is wrong. The only way to know for sure is to check
the used GPIO's,
via a USB snoop dump. Please take a look at linuxtv.org Wiki (search
for usbsnoop).
After getting the dump, please parse it and send me.
I did the usbsnooping and hope I did the parsing right (At least the log
file shrinked from 100MB to some KB, and there are plenty of EM28XX
strings inside ;-))
You can get it here: http://pastebin.com/SXKfLUny
There are a few things that are relevant:
First of all, GPIO's. They enable/disable parts of the board:
$ grep GPIO /tmp/dump
em28xx_write_reg(dev, EM28XX_R08_GPIO, 0xff);
em28xx_read_reg(dev, EM28XX_R08_GPIO);/* read 0xff */
em28xx_write_reg(dev, EM28XX_R08_GPIO, 0xfd);
em28xx_read_reg(dev, EM28XX_R08_GPIO);/* read 0xfd */
em28xx_write_reg(dev, EM28XX_R08_GPIO, 0xfd);
em28xx_read_reg(dev, EM28XX_R08_GPIO);/* read 0xfd */
em28xx_write_reg(dev, EM28XX_R08_GPIO, 0x7d);
em28xx_write_reg(dev, EM28XX_R08_GPIO, 0x2a);
em28xx_write_reg(dev, EM28XX_R08_GPIO, 0x2a);
Currently, they're not touched for this device. Perhaps, we might
need to initialize
them to 0xfd for capture mode, and 0x2a for sleep mode.
In this specific case, maybe it is just safe to keep it as-is, as I
suspect that GPIO's
are not used on this device. I may be wrong, though. A simple test will tell.
The audio entries are related to the ac97 chip.
The driver will basically run this code:
amux = EM28XX_AMUX_VIDEO2; /* from Terratec Grabby entry, at
em28xx-cards.c */
static struct em28xx_vol_table inputs[] = {
{ EM28XX_AMUX_VIDEO, AC97_VIDEO_VOL },
{ EM28XX_AMUX_LINE_IN,AC97_LINEIN_VOL },
{ EM28XX_AMUX_PHONE,AC97_PHONE_VOL },
{ EM28XX_AMUX_MIC,AC97_MIC_VOL },
{ EM28XX_AMUX_CD,AC97_CD_VOL },
{ EM28XX_AMUX_AUX,AC97_AUX_VOL },
{ EM28XX_AMUX_PCM_OUT,AC97_PCM_OUT_VOL },
if (amux == inputs[i].mux)
ret = em28xx_write_ac97(dev, inputs[i].reg, 0x0808);/*
Put the
volume in 50% */
else
ret = em28xx_write_ac97(dev, inputs[i].reg, 0x8000);/*
Mute the
volume */
Any mixer entry equal or bigger than 0x8000 is muted.
$ grep 97 dump
em28xx_read_ac97(dev, AC97_VENDOR_ID1);/* read 0x0x8384 */
em28xx_read_ac97(dev, AC97_VENDOR_ID2);/* read 0x0x7652 */
em28xx_write_ac97(dev, AC97_LINEIN_VOL, 0x0808);
em28xx_write_ac97(dev, AC97_VIDEO_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_AUX_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_MIC_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x8000);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x8000);
em28xx_write_ac97(dev, AC97_POWER_DOWN_CTRL, 0x4200);
em28xx_write_ac97(dev, AC97_RECORD_SELECT, 0x0505);
em28xx_write_ac97(dev, AC97_EXT_AUD_CTRL, 0x0031);
em28xx_write_ac97(dev, AC97_PCM_IN_SRATE, 0xbb80);
em28xx_write_ac97(dev, AC97_LINEIN_VOL, 0x0808);
em28xx_write_ac97(dev, AC97_VIDEO_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_AUX_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_MIC_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x8000);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x8000);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x8000);
em28xx_write_ac97(dev, AC97_LINEIN_VOL, 0x0808);
em28xx_write_ac97(dev, AC97_VIDEO_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_AUX_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_MIC_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x);
em28xx_write_ac97(dev, AC97_LINEIN_VOL, 0x0808);
em28xx_write_ac97(dev, AC97_VIDEO_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_AUX_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_MIC_VOL, 0x9010);
em28xx_write_ac97(dev, AC97_RECORD_GAIN, 0x);
[PATCH 07/10] drivers/media: Removed unnecessary KERN_levels from dprintk uses
Converted if (debug = 2) printk(KERN_DEBUG... to if debug = 2) dprintk(...)
Signed-off-by: Joe Perches j...@perches.com
---
drivers/media/common/tuners/max2165.c | 10 --
drivers/media/dvb/frontends/atbm8830.c|8 +++-
drivers/media/dvb/frontends/lgs8gxx.c | 11 ---
drivers/media/video/saa7134/saa7134-input.c |2 +-
drivers/media/video/saa7134/saa7134-tvaudio.c | 12 ++--
5 files changed, 18 insertions(+), 25 deletions(-)
diff --git a/drivers/media/common/tuners/max2165.c
b/drivers/media/common/tuners/max2165.c
index 937e4b0..9883617 100644
--- a/drivers/media/common/tuners/max2165.c
+++ b/drivers/media/common/tuners/max2165.c
@@ -52,13 +52,12 @@ static int max2165_write_reg(struct max2165_priv *priv, u8
reg, u8 data)
msg.addr = priv-config-i2c_address;
if (debug = 2)
- printk(KERN_DEBUG %s: reg=0x%02X, data=0x%02X\n,
- __func__, reg, data);
+ dprintk(%s: reg=0x%02X, data=0x%02X\n, __func__, reg, data);
ret = i2c_transfer(priv-i2c, msg, 1);
if (ret != 1)
- dprintk(KERN_DEBUG %s: error reg=0x%x, data=0x%x, ret=%i\n,
+ dprintk(%s: error reg=0x%x, data=0x%x, ret=%i\n,
__func__, reg, data, ret);
return (ret != 1) ? -EIO : 0;
@@ -78,14 +77,13 @@ static int max2165_read_reg(struct max2165_priv *priv, u8
reg, u8 *p_data)
ret = i2c_transfer(priv-i2c, msg, 2);
if (ret != 2) {
- dprintk(KERN_DEBUG %s: error reg=0x%x, ret=%i\n,
- __func__, reg, ret);
+ dprintk(%s: error reg=0x%x, ret=%i\n, __func__, reg, ret);
return -EIO;
}
*p_data = b1[0];
if (debug = 2)
- printk(KERN_DEBUG %s: reg=0x%02X, data=0x%02X\n,
+ dprintk(%s: reg=0x%02X, data=0x%02X\n,
__func__, reg, b1[0]);
return 0;
}
diff --git a/drivers/media/dvb/frontends/atbm8830.c
b/drivers/media/dvb/frontends/atbm8830.c
index 43aac2f..1539ea1 100644
--- a/drivers/media/dvb/frontends/atbm8830.c
+++ b/drivers/media/dvb/frontends/atbm8830.c
@@ -50,8 +50,7 @@ static int atbm8830_write_reg(struct atbm_state *priv, u16
reg, u8 data)
msg2.addr = dev_addr;
if (debug = 2)
- printk(KERN_DEBUG %s: reg=0x%04X, data=0x%02X\n,
- __func__, reg, data);
+ dprintk(%s: reg=0x%04X, data=0x%02X\n, __func__, reg, data);
ret = i2c_transfer(priv-i2c, msg1, 1);
if (ret != 1)
@@ -77,8 +76,7 @@ static int atbm8830_read_reg(struct atbm_state *priv, u16
reg, u8 *p_data)
ret = i2c_transfer(priv-i2c, msg1, 1);
if (ret != 1) {
- dprintk(KERN_DEBUG %s: error reg=0x%04x, ret=%i\n,
- __func__, reg, ret);
+ dprintk(%s: error reg=0x%04x, ret=%i\n, __func__, reg, ret);
return -EIO;
}
@@ -88,7 +86,7 @@ static int atbm8830_read_reg(struct atbm_state *priv, u16
reg, u8 *p_data)
*p_data = buf2[0];
if (debug = 2)
- printk(KERN_DEBUG %s: reg=0x%04X, data=0x%02X\n,
+ dprintk(%s: reg=0x%04X, data=0x%02X\n,
__func__, reg, buf2[0]);
return 0;
diff --git a/drivers/media/dvb/frontends/lgs8gxx.c
b/drivers/media/dvb/frontends/lgs8gxx.c
index 5ea28ae..8989f8f 100644
--- a/drivers/media/dvb/frontends/lgs8gxx.c
+++ b/drivers/media/dvb/frontends/lgs8gxx.c
@@ -60,13 +60,12 @@ static int lgs8gxx_write_reg(struct lgs8gxx_state *priv, u8
reg, u8 data)
msg.addr += 0x02;
if (debug = 2)
- printk(KERN_DEBUG %s: reg=0x%02X, data=0x%02X\n,
- __func__, reg, data);
+ dprintk(%s: reg=0x%02X, data=0x%02X\n, __func__, reg, data);
ret = i2c_transfer(priv-i2c, msg, 1);
if (ret != 1)
- dprintk(KERN_DEBUG %s: error reg=0x%x, data=0x%x, ret=%i\n,
+ dprintk(%s: error reg=0x%x, data=0x%x, ret=%i\n,
__func__, reg, data, ret);
return (ret != 1) ? -1 : 0;
@@ -91,15 +90,13 @@ static int lgs8gxx_read_reg(struct lgs8gxx_state *priv, u8
reg, u8 *p_data)
ret = i2c_transfer(priv-i2c, msg, 2);
if (ret != 2) {
- dprintk(KERN_DEBUG %s: error reg=0x%x, ret=%i\n,
- __func__, reg, ret);
+ dprintk(%s: error reg=0x%x, ret=%i\n, __func__, reg, ret);
return -1;
}
*p_data = b1[0];
if (debug = 2)
- printk(KERN_DEBUG %s: reg=0x%02X, data=0x%02X\n,
- __func__, reg, b1[0]);
+ dprintk(%s: reg=0x%02X, data=0x%02X\n, __func__, reg, b1[0]);
return 0;
}
diff --git a/drivers/media/video/saa7134/saa7134-input.c
b/drivers/media/video/saa7134/saa7134-input.c
index 0b336ca..f81a19f 100644
---
[PATCH 00/10] Remove multiple uses of KERN_level
Found using strings vmlinux | grep ^..*. and a couple of other cleanups of logging message format strings. Joe Perches (10): arch/x86/kernel/apic/io_apic.c: Typo fix WARNING drivers/atm/eni.c: Remove multiple uses of KERN_level drivers/hid/hid-input.c: Remove KERN_DEBUG from dbg_hid use drivers/infiniband: Remove unnecessary KERN_level uses drivers/input/mouse/appletouch.c: Remove KERN_DEBUG use from dprintk drivers/input/serio/i8042: Use pr_level, pr_fmt. Fix dbg and __FILE__ use drivers/media: Removed unnecessary KERN_levels from dprintk uses drivers/scsi:mvsas/mv_sas.c: Remove KERN_DEBUG from mv_dprintk use drivers/video/msm/mddi.c: Remove multiple KERN_level uses fs/proc/vmcore.c: Use pr_level and pr_fmt arch/x86/kernel/apic/io_apic.c|2 +- drivers/atm/eni.c |7 +- drivers/hid/hid-input.c |2 +- drivers/infiniband/hw/amso1100/c2_intr.c |4 +- drivers/infiniband/hw/cxgb3/iwch_cm.c |4 +- drivers/infiniband/hw/cxgb4/cm.c |4 +- drivers/input/mouse/appletouch.c |2 +- drivers/input/serio/i8042.c | 94 - drivers/input/serio/i8042.h | 19 +++-- drivers/media/common/tuners/max2165.c | 10 +-- drivers/media/dvb/frontends/atbm8830.c|8 +-- drivers/media/dvb/frontends/lgs8gxx.c | 11 +-- drivers/media/video/saa7134/saa7134-input.c |2 +- drivers/media/video/saa7134/saa7134-tvaudio.c | 12 ++-- drivers/scsi/mvsas/mv_sas.c |2 +- drivers/video/msm/mddi.c |5 +- fs/proc/vmcore.c | 16 ++--- 17 files changed, 97 insertions(+), 107 deletions(-) -- 1.7.3.dirty -- 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] saa7134 behold A7 and H7
Hi
Fix autodetect for Behold A7 and H7 TV cards.
diff -r abd3aac6644e linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Fri Jul 02 00:38:54
2010 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Mon Oct 25 09:16:24
2010 +1000
@@ -6700,6 +6700,18 @@
.subdevice= 0x2804,
.driver_data = SAA7134_BOARD_TECHNOTREND_BUDGET_T3000,
}, {
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+ .subvendor= 0x5ace, /* Beholder Intl. Ltd. */
+ .subdevice= 0x7190,
+ .driver_data = SAA7134_BOARD_BEHOLD_H7,
+ }, {
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+ .subvendor= 0x5ace, /* Beholder Intl. Ltd. */
+ .subdevice= 0x7090,
+ .driver_data = SAA7134_BOARD_BEHOLD_A7,
+ }, {
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7134,
@@ -6737,18 +6749,6 @@
.subvendor= PCI_ANY_ID,
.subdevice= PCI_ANY_ID,
.driver_data = SAA7134_BOARD_UNKNOWN,
- }, {
- .vendor = PCI_VENDOR_ID_PHILIPS,
- .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
- .subvendor= 0x5ace, /* Beholder Intl. Ltd. */
- .subdevice= 0x7190,
- .driver_data = SAA7134_BOARD_BEHOLD_H7,
- }, {
- .vendor = PCI_VENDOR_ID_PHILIPS,
- .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
- .subvendor= 0x5ace, /* Beholder Intl. Ltd. */
- .subdevice= 0x7090,
- .driver_data = SAA7134_BOARD_BEHOLD_A7,
},{
/* --- end of list --- */
}
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com
With my best regards, Dmitry.
diff -r abd3aac6644e linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Fri Jul 02 00:38:54 2010 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Mon Oct 25 09:16:24 2010 +1000
@@ -6700,6 +6700,18 @@
.subdevice= 0x2804,
.driver_data = SAA7134_BOARD_TECHNOTREND_BUDGET_T3000,
}, {
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+ .subvendor= 0x5ace, /* Beholder Intl. Ltd. */
+ .subdevice= 0x7190,
+ .driver_data = SAA7134_BOARD_BEHOLD_H7,
+ }, {
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+ .subvendor= 0x5ace, /* Beholder Intl. Ltd. */
+ .subdevice= 0x7090,
+ .driver_data = SAA7134_BOARD_BEHOLD_A7,
+ }, {
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7134,
@@ -6737,18 +6749,6 @@
.subvendor= PCI_ANY_ID,
.subdevice= PCI_ANY_ID,
.driver_data = SAA7134_BOARD_UNKNOWN,
- }, {
- .vendor = PCI_VENDOR_ID_PHILIPS,
- .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
- .subvendor= 0x5ace, /* Beholder Intl. Ltd. */
- .subdevice= 0x7190,
- .driver_data = SAA7134_BOARD_BEHOLD_H7,
- }, {
- .vendor = PCI_VENDOR_ID_PHILIPS,
- .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
- .subvendor= 0x5ace, /* Beholder Intl. Ltd. */
- .subdevice= 0x7090,
- .driver_data = SAA7134_BOARD_BEHOLD_A7,
},{
/* --- end of list --- */
}
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com
