RE: [PATCH 0/5] DaVinci VPIF: Support for DV preset and DV timings.
Tested for SD modes on TI Dm6467 EVM. DV_PRESTES testing done for THS8200 based EVM by Hans. For the whole patch series: Acked-by: Manjunath Hadli manjunath.ha...@ti.com Regards, -Manju -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of mats.randga...@cisco.com Sent: Thursday, December 16, 2010 8:48 PM To: linux-media@vger.kernel.org Cc: mats.randga...@cisco.com Subject: [PATCH 0/5] DaVinci VPIF: Support for DV preset and DV timings. From: Mats Randgaard mats.randga...@cisco.com Support for DV preset and timings added to vpif_capture and vpif_display drivers. Functions for debugging are added and the code is improved as well. Mats Randgaard (5): vpif_cap/disp: Add debug functionality vpif: Consolidate formats from capture and display vpif_cap/disp: Add support for DV presets vpif_cap/disp: Added support for DV timings vpif_cap/disp: Cleanup, improved comments drivers/media/video/davinci/vpif.c | 177 drivers/media/video/davinci/vpif.h | 18 +- drivers/media/video/davinci/vpif_capture.c | 361 +++-- drivers/media/video/davinci/vpif_capture.h |2 + drivers/media/video/davinci/vpif_display.c | 402 +--- drivers/media/video/davinci/vpif_display.h |2 + 6 files changed, 886 insertions(+), 76 deletions(-) -- 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
[GIT PATCHES FOR 2.6.38] DaVinci VPIF: Support for DV preset and DV timings
Hi Mauro, Can you please pull from the following tree for DV preset and DV timings support for DaVinci VPIF. Sorry for the late request, but we were waiting for an ack from Manju. The patches themselves have been reviewed on the list quite a while ago. The patches affect only DaVinci VPIF video and have been verified by Manju to not have broken anything. Thanks, Sekhar The following changes since commit 187134a5875df20356f4dca075db29f294115a47: David Henningsson (1): [media] DVB: IR support for TechnoTrend CT-3650 are available in the git repository at: git://arago-project.org/git/projects/linux-davinci.git for-mauro Mats Randgaard (5): vpif_cap/disp: Add debug functionality vpif: Consolidate formats from capture and display vpif_cap/disp: Add support for DV presets vpif_cap/disp: Added support for DV timings vpif_cap/disp: Cleanup, improved comments drivers/media/video/davinci/vpif.c | 177 drivers/media/video/davinci/vpif.h | 18 +- drivers/media/video/davinci/vpif_capture.c | 361 +++-- drivers/media/video/davinci/vpif_capture.h |2 + drivers/media/video/davinci/vpif_display.c | 400 +--- drivers/media/video/davinci/vpif_display.h |2 + 6 files changed, 884 insertions(+), 76 deletions(-) -- 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 01/18] Altera FPGA firmware download module.
Hi, On Friday 31 December 2010 16:04:13 Ben Gamari wrote: On Fri, 31 Dec 2010 09:47:41 -0200, Mauro Carvalho Chehab wrote: I understand this. However, a complete JTAG state machine in the kernel, plus an Altera firmware parser, seems to be a lot of code that could live in userspace. Moving it to userspace would mean a kernel driver that would depend on an userspace daemon^Wfirmware loader to work. I would NAK such designs. Why? I agree that JTAG is a lot to place in the kernel and is much better suited to be in user space. What exactly is your objection to depending on a userspace utility? There is no shortage of precedent for loading firmware in userspace (e.g. fx2 usb devices). I agree with this. Mauro, why would a userspace firmware loader be such a bad idea ? If I understand it correctly the driver assumes the firmware is in an Altera proprietary format. If we really want JTAG code in the kernel we should at least split the file parser and the TAP access code. Agreed, but I don't think this would be a good reason to block the code merge for .38. I agree with the above isn't good reason to block it but if there is still debate about the general architecture of the code (see above), then it seems aren't ready yet. The code looks very nice, but I'm not at all convinced that it needs to be in the kernel. Just my two-tenths of a cent. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] hdpvr: Add I2C and ir-kdb-i2c registration of the Zilog Z8 IR chip
On Tue, 28 Dec 2010 20:46:13 -0500, Andy Walls wrote: Add I2C registration of the Zilog Z8F0811 IR microcontroller for either lirc_zilog or ir-kbd-i2c to use. This is a required step in removing lirc_zilog's use of the deprecated struct i2c_adapter.id field. Signed-off-by: Andy Walls awa...@md.metrocast.net --- drivers/media/video/hdpvr/hdpvr-core.c |5 +++ drivers/media/video/hdpvr/hdpvr-i2c.c | 53 drivers/media/video/hdpvr/hdpvr.h |6 +++ 3 files changed, 64 insertions(+), 0 deletions(-) Looks good to me (even though it looks strange to update code which is apparently disabled for quite a while...) Acked-by: Jean Delvare kh...@linux-fr.org -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
KWorld Dual DVB-T (399U)
Hello list, I am getting some problems with my twin DVB-T device: [ 1343.118485] af9015: command failed:2 [ 1343.118496] af9013: I2C read failed reg:d2e6 [ 1457.208508] af9015: command failed:2 [ 1457.208519] af9013: I2C read failed reg:d2e6 [ 1707.999326] af9015: command failed:2 [ 1707.999338] af9013: I2C read failed reg:d330 [ 2300.180919] af9015: command failed:2 [ 2300.180930] af9013: I2C read failed reg:d2e6 [ 6099.824505] af9015: command failed:2 [ 6099.824519] af9013: I2C read failed reg:d330 [ 6697.288537] af9015: command failed:2 [ 6697.288548] af9013: I2C read failed reg:d2e6 [ 6840.668785] af9015: command failed:2 [ 6840.668796] af9013: I2C read failed reg:d330 [ 7687.376269] af9015: command failed:2 [ 7687.376281] af9013: I2C read failed reg:d2e5 [ 9317.488541] af9015: command failed:2 [ 9317.488553] af9013: I2C read failed reg:d330 [10001.390487] af9015: command failed:2 [10001.390498] af9013: I2C read failed reg:d330 [10178.032510] af9015: command failed:2 [10178.032521] af9013: I2C read failed reg:d2e6 [11395.172504] af9015: command failed:2 [11395.172516] af9013: I2C read failed reg:d330 [12004.728546] af9015: command failed:2 [12004.728558] af9013: I2C read failed reg:d2e6 [12493.461116] af9015: command failed:2 [12493.461127] af9013: I2C read failed reg:d2e6 [14606.278574] af9015: command failed:2 [14606.278586] af9013: I2C read failed reg:d330 [15455.204499] af9015: command failed:2 [15455.204511] af9013: I2C read failed reg:d2e1 [15986.988414] af9015: command failed:2 [15986.988425] af9013: I2C read failed reg:d330 [17096.200505] af9015: command failed:2 [17096.200517] af9013: I2C read failed reg:d330 I am using this firmware: http://palosaari.fi/linux/v4l-dvb/firmware/af9015/5.1.0.0/dvb-usb-af9015.fw Is there any way to get it working? When I am watching a channel, I get lots of bad pixels and is very difficult to see the TV. Thanks for all and best regards. -- Josu Lazkano -- 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] ir-kbd-i2c: Add HD PVR IR Rx support to ir-kbd-i2c
On Tue, 28 Dec 2010 20:47:46 -0500, Andy Walls wrote:
Add HD PVR IR Rx support to ir-kbd-i2c
Signed-off-by: Andy Walls awa...@md.metrocast.net
---
drivers/media/video/ir-kbd-i2c.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/ir-kbd-i2c.c
b/drivers/media/video/ir-kbd-i2c.c
index dd54c3d..c87b6bc 100644
--- a/drivers/media/video/ir-kbd-i2c.c
+++ b/drivers/media/video/ir-kbd-i2c.c
@@ -449,6 +449,7 @@ static const struct i2c_device_id ir_kbd_id[] = {
{ ir_video, 0 },
/* IR device specific entries should be added here */
{ ir_rx_z8f0811_haup, 0 },
+ { ir_rx_z8f0811_hdpvr, 0 },
{ }
};
Acked-by: Jean Delvare kh...@linux-fr.org
--
Jean Delvare
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] lirc_zilog: Remove use of deprecated struct i2c_adapter.id field
Hi Andy,
On Tue, 28 Dec 2010 20:49:50 -0500, Andy Walls wrote:
Remove use of deprecated struct i2c_adapter.id field. In the process,
perform different detection of the HD PVR's Z8 IR microcontroller versus
the other Hauppauge cards with the Z8 IR microcontroller.
Thanks a lot for doing this. I'll be very happy when we can finally get
rid of i2c_adapter.id.
Also added a comment about probe() function behavior that needs to be
fixed.
See my suggestion inline below.
Signed-off-by: Andy Walls awa...@md.metrocast.net
---
drivers/staging/lirc/lirc_zilog.c | 47
1 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/lirc/lirc_zilog.c
b/drivers/staging/lirc/lirc_zilog.c
index 52be6de..ad29bb1 100644
--- a/drivers/staging/lirc/lirc_zilog.c
+++ b/drivers/staging/lirc/lirc_zilog.c
@@ -66,6 +66,7 @@ struct IR {
/* Device info */
struct mutex ir_lock;
int open;
+ bool is_hdpvr;
/* RX device */
struct i2c_client c_rx;
@@ -206,16 +207,12 @@ static int add_to_buf(struct IR *ir)
}
/* key pressed ? */
-#ifdef I2C_HW_B_HDPVR
- if (ir-c_rx.adapter-id == I2C_HW_B_HDPVR) {
+ if (ir-is_hdpvr) {
if (got_data (keybuf[0] == 0x80))
return 0;
else if (got_data (keybuf[0] == 0x00))
return -ENODATA;
} else if ((ir-b[0] 0x80) == 0)
-#else
- if ((ir-b[0] 0x80) == 0)
-#endif
return got_data ? 0 : -ENODATA;
/* look what we have */
@@ -841,15 +838,15 @@ static int send_code(struct IR *ir, unsigned int code,
unsigned int key)
return ret 0 ? ret : -EFAULT;
}
-#ifdef I2C_HW_B_HDPVR
/*
* The sleep bits aren't necessary on the HD PVR, and in fact, the
* last i2c_master_recv always fails with a -5, so for now, we're
* going to skip this whole mess and say we're done on the HD PVR
*/
- if (ir-c_rx.adapter-id == I2C_HW_B_HDPVR)
- goto done;
-#endif
+ if (ir-is_hdpvr) {
+ dprintk(sent code %u, key %u\n, code, key);
+ return 0;
+ }
I don't get the change. What was wrong with the goto done? Now you
duplicated the dprintk(), and as far as I can see the done label is
left unused.
/*
* This bit NAKs until the device is ready, so we retry it
@@ -,12 +1108,14 @@ static int ir_remove(struct i2c_client *client);
static int ir_probe(struct i2c_client *client, const struct i2c_device_id
*id);
static int ir_command(struct i2c_client *client, unsigned int cmd, void
*arg);
+#define ID_FLAG_TX 0x01
+#define ID_FLAG_HDPVR0x02
+
static const struct i2c_device_id ir_transceiver_id[] = {
- /* Generic entry for any IR transceiver */
- { ir_video, 0 },
- /* IR device specific entries should be added here */
- { ir_tx_z8f0811_haup, 0 },
- { ir_rx_z8f0811_haup, 0 },
+ { ir_tx_z8f0811_haup, ID_FLAG_TX },
+ { ir_rx_z8f0811_haup, 0 },
+ { ir_tx_z8f0811_hdpvr, ID_FLAG_HDPVR | ID_FLAG_TX },
+ { ir_rx_z8f0811_hdpvr, ID_FLAG_HDPVR },
{ }
};
@@ -1196,10 +1195,25 @@ static int ir_probe(struct i2c_client *client, const
struct i2c_device_id *id)
int ret;
int have_rx = 0, have_tx = 0;
- dprintk(%s: adapter id=0x%x, client addr=0x%02x\n,
- __func__, adap-id, client-addr);
+ dprintk(%s: adapter name (%s) nr %d, i2c_device_id name (%s),
+ client addr=0x%02x\n,
+ __func__, adap-name, adap-nr, id-name, client-addr);
The debug message format is long and confusing. What about:
dprintk(%s: %s on i2c-%d (%s), client addr=0x%02x\n,
__func__, id-name, adap-nr, adap-name, client-addr);
/*
+ * FIXME - This probe function probes both the Tx and Rx
+ * addresses of the IR microcontroller.
+ *
+ * However, the I2C subsystem is passing along one I2C client at a
+ * time, based on matches to the ir_transceiver_id[] table above.
+ * The expectation is that each i2c_client address will be probed
+ * individually by drivers so the I2C subsystem can mark all client
+ * addresses as claimed or not.
+ *
+ * This probe routine causes only one of the client addresses, TX or RX,
+ * to be claimed. This will cause a problem if the I2C subsystem is
+ * subsequently triggered to probe unclaimed clients again.
+ */
This can be easily addressed. You can call i2c_new_dummy() from within
the probe function to register secondary addresses. See
drivers/misc/eeprom/at24.c for an example.
That being said, I doubt this is what we want here. i2c_new_dummy() is
only meant for cases where
RE: [PATCH 7/9] media: MFC: Add MFC v5.1 V4L2 driver
Hi,
Thanks for the comment. Some of them include my code, which will I comment
below.
My review also imply Kamil's original patch.
snip
+
+/* Display status */
+#define S5P_FIMV_DEC_STATUS_DECODING_ONLY 0
+#define S5P_FIMV_DEC_STATUS_DECODING_DISPLAY 1
+#define S5P_FIMV_DEC_STATUS_DISPLAY_ONLY 2
+#define S5P_FIMV_DEC_STATUS_DECODING_EMPTY 3
+#define S5P_FIMV_DEC_STATUS_DECODING_STATUS_MASK 7
+#define S5P_FIMV_DEC_STATUS_PROGRESSIVE(03)
+#define S5P_FIMV_DEC_STATUS_INTERLACE (13)
+#define S5P_FIMV_DEC_STATUS_INTERLACE_MASK (13)
+#define S5P_FIMV_DEC_STATUS_CRC_NUMBER_TWO (04)
+#define S5P_FIMV_DEC_STATUS_CRC_NUMBER_FOUR(14)
+#define S5P_FIMV_DEC_STATUS_CRC_NUMBER_MASK(14)
+#define S5P_FIMV_DEC_STATUS_CRC_GENERATED (15)
+#define S5P_FIMV_DEC_STATUS_CRC_NOT_GENERATED (05)
+#define S5P_FIMV_DEC_STATUS_CRC_MASK (15)
Use like (0 3), (1 3) ...
snip
Fixed.
+/* Enumerate format */
+static int vidioc_enum_fmt(struct v4l2_fmtdesc *f, bool mplane, bool
out,
+ enum s5p_mfc_node_type
node)
+{
+ struct s5p_mfc_fmt *fmt;
+ int i, j = 0;
+
+ if (node == MFCNODE_INVALID)
+ return 0;
+
+ for (i = 0; i ARRAY_SIZE(formats); ++i) {
+ if (mplane formats[i].num_planes == 1)
+ continue;
+ else if (!mplane formats[i].num_planes 1)
+ continue;
+ if (node == MFCNODE_DECODER) {
+ if (out formats[i].type != MFC_FMT_DEC)
+ continue;
+ else if (!out formats[i].type != MFC_FMT_RAW)
+ continue;
+ } else if (node == MFCNODE_ENCODER) {
+ if (out formats[i].type != MFC_FMT_RAW)
+ continue;
+ else if (!out formats[i].type != MFC_FMT_ENC)
+ continue;
+ }
+
+ if (j == f-index) {
+ fmt = formats[i];
+ strlcpy(f-description, fmt-name,
+ sizeof(f-description));
+ f-pixelformat = fmt-fourcc;
+
+ return 0;
+ }
+
+ ++j;
+ }
+
+ return -EINVAL;
+}
+
At a glance, no needed to use j variable.
if (i == f-index) instead of if (j == f-index)
This code by me was modified, as you know the patches got mixed up.
There should be two num_fmt's one for decoding and one for encoding node.
Using j here will ensure that numbering of formats for both nodes is
continuous.
+/* Get format */
+static int vidioc_g_fmt(struct file *file, void *priv, struct
v4l2_format
*f)
+{
+ struct s5p_mfc_ctx *ctx = priv;
+
+ mfc_debug_enter();
+ mfc_debug(f-type = %d ctx-state = %d\n, f-type, ctx-state);
+ if (f-type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE
+ ctx-state == MFCINST_GOT_INST) {
+ /* If the MFC is parsing the header,
+* so wait until it is finished */
+ s5p_mfc_clean_ctx_int_flags(ctx);
+ s5p_mfc_wait_for_done_ctx(ctx,
S5P_FIMV_R2H_CMD_SEQ_DONE_RET,
+ 1);
+ }
+ if (f-type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE
+ ctx-state = MFCINST_HEAD_PARSED
+ ctx-state = MFCINST_ABORT) {
+ /* This is run on CAPTURE (deocde output) */
+ /* Width and height are set to the dimensions
+ of the movie, the buffer is bigger and
+ further processing stages should crop to this
+ rectangle. */
+ f-fmt.pix_mp.width = ctx-buf_width;
+ f-fmt.pix_mp.height = ctx-buf_height;
+ f-fmt.pix_mp.field = V4L2_FIELD_NONE;
+ f-fmt.pix_mp.num_planes = 2;
+ /* Set pixelformat to the format in which MFC
+ outputs the decoded frame */
+ f-fmt.pix_mp.pixelformat = V4L2_PIX_FMT_NV12MT;
+ f-fmt.pix_mp.plane_fmt[0].bytesperline = ctx-buf_width;
+ f-fmt.pix_mp.plane_fmt[0].sizeimage = ctx-luma_size;
+ f-fmt.pix_mp.plane_fmt[1].bytesperline = ctx-buf_width;
+ f-fmt.pix_mp.plane_fmt[1].sizeimage = ctx-chroma_size;
+ } else if (f-type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
+ /* This is run on OUTPUT
+ The buffer contains compressed image
+ so width and height have no meaning */
+ f-fmt.pix_mp.width = 1;
+ f-fmt.pix_mp.height = 1;
+ f-fmt.pix_mp.field = V4L2_FIELD_NONE;
+ f-fmt.pix_mp.plane_fmt[0].bytesperline = ctx-
dec_src_buf_size;
+
[RFC PATCH 0/2] davinci: convert to core-assisted locking
These two patches convert vpif_capture and vpif_display to core-assisted locking and now use .unlocked_ioctl instead of .ioctl. These patches assume that the 'DaVinci VPIF: Support for DV preset and DV timings' patch series was applied first. See: http://www.mail-archive.com/linux-media@vger.kernel.org/msg26594.html These patches are targeted for 2.6.38. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 2/2] davinci: convert vpif_display to core-assisted locking
vpif_display now uses .unlocked_ioctl instead of .ioctl.
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/davinci/vpif_display.c | 98 ++--
1 files changed, 20 insertions(+), 78 deletions(-)
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c
index 7cb70d9..cdf659a 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -652,9 +652,6 @@ static int vpif_release(struct file *filep)
struct channel_obj *ch = fh-channel;
struct common_obj *common = ch-common[VPIF_VIDEO_INDEX];
- if (mutex_lock_interruptible(common-lock))
- return -ERESTARTSYS;
-
/* if this instance is doing IO */
if (fh-io_allowed[VPIF_VIDEO_INDEX]) {
/* Reset io_usrs member of channel object */
@@ -677,8 +674,6 @@ static int vpif_release(struct file *filep)
config_params.numbuffers[ch-channel_id];
}
- mutex_unlock(common-lock);
-
/* Decrement channel usrs counter */
atomic_dec(ch-usrs);
/* If this file handle has initialize encoder device, reset it */
@@ -737,24 +732,15 @@ static int vpif_g_fmt_vid_out(struct file *file, void
*priv,
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh-channel;
struct common_obj *common = ch-common[VPIF_VIDEO_INDEX];
- int ret = 0;
/* Check the validity of the buffer type */
if (common-fmt.type != fmt-type)
return -EINVAL;
- /* Fill in the information about format */
- if (mutex_lock_interruptible(common-lock))
- return -ERESTARTSYS;
-
if (vpif_update_resolution(ch))
- ret = -EINVAL;
- else
- *fmt = common-fmt;
-
- mutex_unlock(common-lock);
-
- return ret;
+ return -EINVAL;
+ *fmt = common-fmt;
+ return 0;
}
static int vpif_s_fmt_vid_out(struct file *file, void *priv,
@@ -794,12 +780,7 @@ static int vpif_s_fmt_vid_out(struct file *file, void
*priv,
/* store the pix format in the channel object */
common-fmt.fmt.pix = *pixfmt;
/* store the format in the channel object */
- if (mutex_lock_interruptible(common-lock))
- return -ERESTARTSYS;
-
common-fmt = *fmt;
- mutex_unlock(common-lock);
-
return 0;
}
@@ -829,7 +810,6 @@ static int vpif_reqbufs(struct file *file, void *priv,
struct common_obj *common;
enum v4l2_field field;
u8 index = 0;
- int ret = 0;
/* This file handle has not initialized the channel,
It is not allowed to do settings */
@@ -847,18 +827,12 @@ static int vpif_reqbufs(struct file *file, void *priv,
index = VPIF_VIDEO_INDEX;
common = ch-common[index];
- if (mutex_lock_interruptible(common-lock))
- return -ERESTARTSYS;
- if (common-fmt.type != reqbuf-type) {
- ret = -EINVAL;
- goto reqbuf_exit;
- }
+ if (common-fmt.type != reqbuf-type)
+ return -EINVAL;
- if (0 != common-io_usrs) {
- ret = -EBUSY;
- goto reqbuf_exit;
- }
+ if (0 != common-io_usrs)
+ return -EBUSY;
if (reqbuf-type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
if (common-fmt.fmt.pix.field == V4L2_FIELD_ANY)
@@ -875,7 +849,7 @@ static int vpif_reqbufs(struct file *file, void *priv,
common-irqlock,
reqbuf-type, field,
sizeof(struct videobuf_buffer), fh,
- NULL);
+ common-lock);
/* Set io allowed member of file handle to TRUE */
fh-io_allowed[index] = 1;
@@ -886,11 +860,7 @@ static int vpif_reqbufs(struct file *file, void *priv,
INIT_LIST_HEAD(common-dma_queue);
/* Allocate buffers */
- ret = videobuf_reqbufs(common-buffer_queue, reqbuf);
-
-reqbuf_exit:
- mutex_unlock(common-lock);
- return ret;
+ return videobuf_reqbufs(common-buffer_queue, reqbuf);
}
static int vpif_querybuf(struct file *file, void *priv,
@@ -1011,25 +981,19 @@ static int vpif_s_std(struct file *file, void *priv,
v4l2_std_id *std_id)
}
/* Call encoder subdevice function to set the standard */
- if (mutex_lock_interruptible(common-lock))
- return -ERESTARTSYS;
-
ch-video.stdid = *std_id;
ch-video.dv_preset = V4L2_DV_INVALID;
memset(ch-video.bt_timings, 0, sizeof(ch-video.bt_timings));
/* Get the information about the standard */
- if (vpif_update_resolution(ch)) {
- ret = -EINVAL;
- goto s_std_exit;
- }
+ if
[RFC PATCH 1/2] davinci: convert vpif_capture to core-assisted locking
From: Hans Verkuil hans.verk...@cisco.com
Now uses .unlocked_ioctl instead of .ioctl.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/davinci/vpif_capture.c | 90 ---
1 files changed, 14 insertions(+), 76 deletions(-)
diff --git a/drivers/media/video/davinci/vpif_capture.c
b/drivers/media/video/davinci/vpif_capture.c
index f8e6590..d93ad74 100644
--- a/drivers/media/video/davinci/vpif_capture.c
+++ b/drivers/media/video/davinci/vpif_capture.c
@@ -752,7 +752,7 @@ static int vpif_open(struct file *filep)
struct video_obj *vid_ch;
struct channel_obj *ch;
struct vpif_fh *fh;
- int i, ret = 0;
+ int i;
vpif_dbg(2, debug, vpif_open\n);
@@ -761,9 +761,6 @@ static int vpif_open(struct file *filep)
vid_ch = ch-video;
common = ch-common[VPIF_VIDEO_INDEX];
- if (mutex_lock_interruptible(common-lock))
- return -ERESTARTSYS;
-
if (NULL == ch-curr_subdev_info) {
/**
* search through the sub device to see a registered
@@ -780,8 +777,7 @@ static int vpif_open(struct file *filep)
}
if (i == config-subdev_count) {
vpif_err(No sub device registered\n);
- ret = -ENOENT;
- goto exit;
+ return -ENOENT;
}
}
@@ -789,8 +785,7 @@ static int vpif_open(struct file *filep)
fh = kzalloc(sizeof(struct vpif_fh), GFP_KERNEL);
if (NULL == fh) {
vpif_err(unable to allocate memory for file handle object\n);
- ret = -ENOMEM;
- goto exit;
+ return -ENOMEM;
}
/* store pointer to fh in private_data member of filep */
@@ -810,9 +805,7 @@ static int vpif_open(struct file *filep)
/* Initialize priority of this instance to default priority */
fh-prio = V4L2_PRIORITY_UNSET;
v4l2_prio_open(ch-prio, fh-prio);
-exit:
- mutex_unlock(common-lock);
- return ret;
+ return 0;
}
/**
@@ -832,9 +825,6 @@ static int vpif_release(struct file *filep)
common = ch-common[VPIF_VIDEO_INDEX];
- if (mutex_lock_interruptible(common-lock))
- return -ERESTARTSYS;
-
/* if this instance is doing IO */
if (fh-io_allowed[VPIF_VIDEO_INDEX]) {
/* Reset io_usrs member of channel object */
@@ -858,9 +848,6 @@ static int vpif_release(struct file *filep)
/* Decrement channel usrs counter */
ch-usrs--;
- /* unlock mutex on channel object */
- mutex_unlock(common-lock);
-
/* Close the priority */
v4l2_prio_close(ch-prio, fh-prio);
@@ -885,7 +872,6 @@ static int vpif_reqbufs(struct file *file, void *priv,
struct channel_obj *ch = fh-channel;
struct common_obj *common;
u8 index = 0;
- int ret = 0;
vpif_dbg(2, debug, vpif_reqbufs\n);
@@ -908,13 +894,8 @@ static int vpif_reqbufs(struct file *file, void *priv,
common = ch-common[index];
- if (mutex_lock_interruptible(common-lock))
- return -ERESTARTSYS;
-
- if (0 != common-io_usrs) {
- ret = -EBUSY;
- goto reqbuf_exit;
- }
+ if (0 != common-io_usrs)
+ return -EBUSY;
/* Initialize videobuf queue as per the buffer type */
videobuf_queue_dma_contig_init(common-buffer_queue,
@@ -923,7 +904,7 @@ static int vpif_reqbufs(struct file *file, void *priv,
reqbuf-type,
common-fmt.fmt.pix.field,
sizeof(struct videobuf_buffer), fh,
- NULL);
+ common-lock);
/* Set io allowed member of file handle to TRUE */
fh-io_allowed[index] = 1;
@@ -934,11 +915,7 @@ static int vpif_reqbufs(struct file *file, void *priv,
INIT_LIST_HEAD(common-dma_queue);
/* Allocate buffers */
- ret = videobuf_reqbufs(common-buffer_queue, reqbuf);
-
-reqbuf_exit:
- mutex_unlock(common-lock);
- return ret;
+ return videobuf_reqbufs(common-buffer_queue, reqbuf);
}
/**
@@ -1152,11 +1129,6 @@ static int vpif_streamon(struct file *file, void *priv,
return ret;
}
- if (mutex_lock_interruptible(common-lock)) {
- ret = -ERESTARTSYS;
- goto streamoff_exit;
- }
-
/* If buffer queue is empty, return error */
if (list_empty(common-dma_queue)) {
vpif_dbg(1, debug, buffer queue is empty\n);
@@ -1235,13 +1207,10 @@ static int vpif_streamon(struct file *file, void *priv,
enable_channel1(1);
}
channel_first_int[VPIF_VIDEO_INDEX][ch-channel_id] = 1;
-
Re: [PATCH 3/3] lirc_zilog: Remove use of deprecated struct i2c_adapter.id field
Hi Jean,
Thanks for your acks for patches 1 and 2. I've already applied the patches
on my tree and at linux-next. I'll try to add the acks on it before sending
upstream.
Em 05-01-2011 12:45, Jean Delvare escreveu:
Hi Andy,
On Tue, 28 Dec 2010 20:49:50 -0500, Andy Walls wrote:
Remove use of deprecated struct i2c_adapter.id field. In the process,
perform different detection of the HD PVR's Z8 IR microcontroller versus
the other Hauppauge cards with the Z8 IR microcontroller.
Thanks a lot for doing this. I'll be very happy when we can finally get
rid of i2c_adapter.id.
Also added a comment about probe() function behavior that needs to be
fixed.
See my suggestion inline below.
Signed-off-by: Andy Walls awa...@md.metrocast.net
---
drivers/staging/lirc/lirc_zilog.c | 47
1 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/lirc/lirc_zilog.c
b/drivers/staging/lirc/lirc_zilog.c
index 52be6de..ad29bb1 100644
--- a/drivers/staging/lirc/lirc_zilog.c
+++ b/drivers/staging/lirc/lirc_zilog.c
@@ -66,6 +66,7 @@ struct IR {
/* Device info */
struct mutex ir_lock;
int open;
+bool is_hdpvr;
/* RX device */
struct i2c_client c_rx;
@@ -206,16 +207,12 @@ static int add_to_buf(struct IR *ir)
}
/* key pressed ? */
-#ifdef I2C_HW_B_HDPVR
-if (ir-c_rx.adapter-id == I2C_HW_B_HDPVR) {
+if (ir-is_hdpvr) {
if (got_data (keybuf[0] == 0x80))
return 0;
else if (got_data (keybuf[0] == 0x00))
return -ENODATA;
} else if ((ir-b[0] 0x80) == 0)
-#else
-if ((ir-b[0] 0x80) == 0)
-#endif
return got_data ? 0 : -ENODATA;
/* look what we have */
@@ -841,15 +838,15 @@ static int send_code(struct IR *ir, unsigned int code,
unsigned int key)
return ret 0 ? ret : -EFAULT;
}
-#ifdef I2C_HW_B_HDPVR
/*
* The sleep bits aren't necessary on the HD PVR, and in fact, the
* last i2c_master_recv always fails with a -5, so for now, we're
* going to skip this whole mess and say we're done on the HD PVR
*/
-if (ir-c_rx.adapter-id == I2C_HW_B_HDPVR)
-goto done;
-#endif
+if (ir-is_hdpvr) {
+dprintk(sent code %u, key %u\n, code, key);
+return 0;
+}
I don't get the change. What was wrong with the goto done? Now you
duplicated the dprintk(), and as far as I can see the done label is
left unused.
You probably missed some other changes here. There's a patch fixing the warning
that happens due to the done: label that it was not used.
While this code is, in practice, not used, as IR support is disabled at hdpvr,
I don't see much sense on trying to optimize its code. I'd rather prefer
to see some patches re-enabling IR support on hdpvr and fixing the remaining
issues at lirc_zilog, converting it to use RC core.
/*
* This bit NAKs until the device is ready, so we retry it
@@ -,12 +1108,14 @@ static int ir_remove(struct i2c_client *client);
static int ir_probe(struct i2c_client *client, const struct i2c_device_id
*id);
static int ir_command(struct i2c_client *client, unsigned int cmd, void
*arg);
+#define ID_FLAG_TX 0x01
+#define ID_FLAG_HDPVR 0x02
+
static const struct i2c_device_id ir_transceiver_id[] = {
-/* Generic entry for any IR transceiver */
-{ ir_video, 0 },
-/* IR device specific entries should be added here */
-{ ir_tx_z8f0811_haup, 0 },
-{ ir_rx_z8f0811_haup, 0 },
+{ ir_tx_z8f0811_haup, ID_FLAG_TX },
+{ ir_rx_z8f0811_haup, 0 },
+{ ir_tx_z8f0811_hdpvr, ID_FLAG_HDPVR | ID_FLAG_TX },
+{ ir_rx_z8f0811_hdpvr, ID_FLAG_HDPVR },
{ }
};
@@ -1196,10 +1195,25 @@ static int ir_probe(struct i2c_client *client, const
struct i2c_device_id *id)
int ret;
int have_rx = 0, have_tx = 0;
-dprintk(%s: adapter id=0x%x, client addr=0x%02x\n,
-__func__, adap-id, client-addr);
+dprintk(%s: adapter name (%s) nr %d, i2c_device_id name (%s),
+client addr=0x%02x\n,
+__func__, adap-name, adap-nr, id-name, client-addr);
The debug message format is long and confusing. What about:
dprintk(%s: %s on i2c-%d (%s), client addr=0x%02x\n,
__func__, id-name, adap-nr, adap-name, client-addr);
Agreed.
/*
+ * FIXME - This probe function probes both the Tx and Rx
+ * addresses of the IR microcontroller.
+ *
+ * However, the I2C subsystem is passing along one I2C client at a
+ * time, based on matches to the ir_transceiver_id[] table above.
+ * The expectation is that each i2c_client address will be probed
+ * individually by
Re: Add Terratec Grabster support to tm6000
On Tue, 4 Jan 2011, Stefan Ringel wrote:
Am 04.01.2011 20:12, schrieb Holger Nelson:
Hi,
the following patch adds support for a Terratec Grabster AV MX150 (and
maybe other devices in the Grabster series). This device is an analog
frame grabber device using a tm5600. This device doesn't have a tuner,
so I changed the code to skip the tuner reset if neither has_tuner nor
has_dvb is set.
it skip, if you has no tuner gpio defined. You does'nt need more. Work
the driver with input select (tv (conposite0), composite, s-vhs)?
Yes tuner reset is skipped, but in the else-branch, the code also
complains that tuner reset is not configured and returns -1, which makes
tm6000_init_dev exit before v4l2_device_register is called. Switching
inputs does not work, but at least I can use the composite input, if I
use the tv-input.
Below is a new version of the patch.
Holger
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index 5a7946c..0f4154f 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -50,6 +50,7 @@
#define TM6010_BOARD_BEHOLD_VOYAGER11
#define TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE12
#define TM6010_BOARD_TWINHAN_TU501 13
+#define TM5600_BOARD_TERRATEC_GRABSTER 14
#define TM6000_MAXBOARDS16
static unsigned int card[] = {[0 ... (TM6000_MAXBOARDS - 1)] = UNSET };
@@ -303,6 +304,19 @@ struct tm6000_board tm6000_boards[] = {
.dvb_led= TM6010_GPIO_5,
.ir = TM6010_GPIO_0,
},
+ },
+ [TM5600_BOARD_TERRATEC_GRABSTER] = {
+ .name = Terratec Grabster AV 150/250 MX,
+ .type = TM5600,
+ .caps = {
+ .has_tuner = 0,
+ .has_dvb= 0,
+ .has_zl10353= 0,
+ .has_eeprom = 0,
+ .has_remote = 0,
+ },
+ .gpio = {
+ },
}
};
@@ -325,6 +339,7 @@ struct usb_device_id tm6000_id_table[] = {
{ USB_DEVICE(0x13d3, 0x3241), .driver_info = TM6010_BOARD_TWINHAN_TU501
},
{ USB_DEVICE(0x13d3, 0x3243), .driver_info = TM6010_BOARD_TWINHAN_TU501
},
{ USB_DEVICE(0x13d3, 0x3264), .driver_info = TM6010_BOARD_TWINHAN_TU501
},
+ { USB_DEVICE(0x0ccd, 0x0079), .driver_info =
TM5600_BOARD_TERRATEC_GRABSTER },
{ },
};
@@ -447,6 +462,8 @@ int tm6000_cards_setup(struct tm6000_core *dev)
* the board-specific session.
*/
switch (dev-model) {
+ case TM5600_BOARD_TERRATEC_GRABSTER:
+ return 0;
case TM6010_BOARD_HAUPPAUGE_900H:
case TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE:
case TM6010_BOARD_TWINHAN_TU501:
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.38] Remove duplicate radio-gemtek-pci driver
The radio-gemtek-pci driver and the radio-maxiradio driver are identical. This patch removes the gemtek-pci driver. The maxiradio driver is slightly better as it supports mono/stereo detection. Tested with my GemTek PCI card. Regards, Hans The following changes since commit aeb13b434d0953050306435cd3134d65547dbcf4: Mauro Carvalho Chehab (1): cx25821: Fix compilation breakage due to BKL dependency are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git gemtek Hans Verkuil (2): radio-maxiradio.c: use sensible frequency range radio-gemtek-pci: remove duplicate driver drivers/media/radio/Kconfig| 14 - drivers/media/radio/Makefile |1 - drivers/media/radio/radio-gemtek-pci.c | 478 drivers/media/radio/radio-maxiradio.c |4 +- 4 files changed, 2 insertions(+), 495 deletions(-) delete mode 100644 drivers/media/radio/radio-gemtek-pci.c -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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: WARNINGS
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:Wed Jan 5 19:00:26 CET 2011 git master: 59365d136d205cc20fe666ca7f89b1c5001b0d5a git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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: KWorld Dual DVB-T (399U)
2011/1/5 Josu Lazkano josu.lazk...@gmail.com: Hello list, I am getting some problems with my twin DVB-T device: [ 1343.118485] af9015: command failed:2 [ 1343.118496] af9013: I2C read failed reg:d2e6 [ 1457.208508] af9015: command failed:2 [ 1457.208519] af9013: I2C read failed reg:d2e6 [ 1707.999326] af9015: command failed:2 [ 1707.999338] af9013: I2C read failed reg:d330 [ 2300.180919] af9015: command failed:2 [ 2300.180930] af9013: I2C read failed reg:d2e6 [ 6099.824505] af9015: command failed:2 [ 6099.824519] af9013: I2C read failed reg:d330 [ 6697.288537] af9015: command failed:2 [ 6697.288548] af9013: I2C read failed reg:d2e6 [ 6840.668785] af9015: command failed:2 [ 6840.668796] af9013: I2C read failed reg:d330 [ 7687.376269] af9015: command failed:2 [ 7687.376281] af9013: I2C read failed reg:d2e5 [ 9317.488541] af9015: command failed:2 [ 9317.488553] af9013: I2C read failed reg:d330 [10001.390487] af9015: command failed:2 [10001.390498] af9013: I2C read failed reg:d330 [10178.032510] af9015: command failed:2 [10178.032521] af9013: I2C read failed reg:d2e6 [11395.172504] af9015: command failed:2 [11395.172516] af9013: I2C read failed reg:d330 [12004.728546] af9015: command failed:2 [12004.728558] af9013: I2C read failed reg:d2e6 [12493.461116] af9015: command failed:2 [12493.461127] af9013: I2C read failed reg:d2e6 [14606.278574] af9015: command failed:2 [14606.278586] af9013: I2C read failed reg:d330 [15455.204499] af9015: command failed:2 [15455.204511] af9013: I2C read failed reg:d2e1 [15986.988414] af9015: command failed:2 [15986.988425] af9013: I2C read failed reg:d330 [17096.200505] af9015: command failed:2 [17096.200517] af9013: I2C read failed reg:d330 I am using this firmware: http://palosaari.fi/linux/v4l-dvb/firmware/af9015/5.1.0.0/dvb-usb-af9015.fw Is there any way to get it working? When I am watching a channel, I get lots of bad pixels and is very difficult to see the TV. Thanks for all and best regards. Hello again, I try to change the USB port, now the SD channels goes well but the HD channels has little freeze (less than a second). And there is no any dmesg errors. It looks that the adapter can not handle the HD channels. How can I debug this? I will appreciate any help, thanks and best regards. -- Josu Lazkano -- 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 3/3] lirc_zilog: Remove use of deprecated struct i2c_adapter.id field
Hi Mauro, On Wed, 05 Jan 2011 15:34:28 -0200, Mauro Carvalho Chehab wrote: Hi Jean, Thanks for your acks for patches 1 and 2. I've already applied the patches on my tree and at linux-next. I'll try to add the acks on it before sending upstream. If you can't, it's fine. I merely wanted to show my support to Andy's work, I don't care if I'm not counted as a reviewer for these small patches. Em 05-01-2011 12:45, Jean Delvare escreveu: From a purely technical perspective, changing client-addr in the probe() function is totally prohibited. Agreed. Btw, there are some other hacks with client-addr abuse on some other random places at drivers/media, mostly at the device bridge code, used to test if certain devices are present and/or to open some I2C gates before doing some init code. People use this approach as it provides a fast way to do some things. On several cases, the amount of code for doing such hack is very small, when compared to writing a new I2C driver just to do some static initialization code. Not sure what would be the better approach to fix them. Hard to tell without seeing the exact code. Ideally, i2c_new_dummy() would cover these cases: you don't need to write an actual driver for the device, it's perfectly OK to use the freshly instantiated i2c_client from the bridge driver directly. Alternatively, i2c_smbus_xfer() or i2c_transfer() can be used for one-time data exchange with any slave on the bus as long as you know what you're doing (i.e. you know that no i2c_client will ever be instantiated for this slave.) If you have specific cases you don't know how to solve, please point me to them and I'll take a look. -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] lirc_zilog: Remove use of deprecated struct i2c_adapter.id field
Em 05-01-2011 19:51, Jean Delvare escreveu:
Hi Mauro,
On Wed, 05 Jan 2011 15:34:28 -0200, Mauro Carvalho Chehab wrote:
Hi Jean,
Thanks for your acks for patches 1 and 2. I've already applied the patches
on my tree and at linux-next. I'll try to add the acks on it before sending
upstream.
If you can't, it's fine. I merely wanted to show my support to Andy's
work, I don't care if I'm not counted as a reviewer for these small
patches.
Ok. So, it is probably better to keep it as-is, to avoid rebasing and having
to wait for a couple days at linux-next before sending the git pull request.
Em 05-01-2011 12:45, Jean Delvare escreveu:
From a purely technical perspective, changing client-addr in the
probe() function is totally prohibited.
Agreed. Btw, there are some other hacks with client-addr abuse on some
other random places at drivers/media, mostly at the device bridge code,
used to test if certain devices are present and/or to open some I2C gates
before doing some init code. People use this approach as it provides a
fast way to do some things. On several cases, the amount of code for
doing such hack is very small, when compared to writing a new I2C driver
just to do some static initialization code. Not sure what would be the
better approach to fix them.
Hard to tell without seeing the exact code. Ideally,
i2c_new_dummy() would cover these cases: you don't need to write an
actual driver for the device, it's perfectly OK to use the freshly
instantiated i2c_client from the bridge driver directly. Alternatively,
i2c_smbus_xfer() or i2c_transfer() can be used for one-time data
exchange with any slave on the bus as long as you know what you're
doing (i.e. you know that no i2c_client will ever be instantiated for
this slave.)
If you have specific cases you don't know how to solve, please point me
to them and I'll take a look.
You can take a look at saa7134-cards.c, for example. saa7134_tuner_setup()
has several examples. It starts with this one:
switch (dev-board) {
case SAA7134_BOARD_BMK_MPEX_NOTUNER:
case SAA7134_BOARD_BMK_MPEX_TUNER:
/* Checks if the device has a tuner at 0x60 addr
If the device doesn't have a tuner, TUNER_ABSENT
will be used at tuner_type, avoiding loading tuner
without needing it
*/
dev-i2c_client.addr = 0x60;
board = (i2c_master_recv(dev-i2c_client, buf, 0) 0)
? SAA7134_BOARD_BMK_MPEX_NOTUNER
: SAA7134_BOARD_BMK_MPEX_TUNER;
In this specific case, it is simply a probe for a device at address 0x60, but
there are more complex cases there, with eeprom reads and/or some random init
that happens before actually attaching some driver at the i2c address.
It is known to work, but it sounds like a hack.
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] hdpvr: Add I2C and ir-kdb-i2c registration of the Zilog Z8 IR chip
On Wed, 2011-01-05 at 13:50 +0100, Jean Delvare wrote: On Tue, 28 Dec 2010 20:46:13 -0500, Andy Walls wrote: Add I2C registration of the Zilog Z8F0811 IR microcontroller for either lirc_zilog or ir-kbd-i2c to use. This is a required step in removing lirc_zilog's use of the deprecated struct i2c_adapter.id field. Signed-off-by: Andy Walls awa...@md.metrocast.net --- drivers/media/video/hdpvr/hdpvr-core.c |5 +++ drivers/media/video/hdpvr/hdpvr-i2c.c | 53 drivers/media/video/hdpvr/hdpvr.h |6 +++ 3 files changed, 64 insertions(+), 0 deletions(-) Looks good to me (even though it looks strange to update code which is apparently disabled for quite a while...) Yes it is odd. My intent was ensure that after removal of adap-id, that the hdpvr driver would, in the future, identify its device in a manner lirc_zilog was expecting. I don't have a HD PVR with which to test things myself. So putting in all the plumbing lowers the barrier for developers like Jarrod or Janne to test lirc_zilog with an HD PVR when/if they re-enable I2C in hdpvr. Regards, Andy Acked-by: Jean Delvare kh...@linux-fr.org -- 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 3/3] lirc_zilog: Remove use of deprecated struct i2c_adapter.id field
On Wed, 2011-01-05 at 15:45 +0100, Jean Delvare wrote:
Hi Andy,
On Tue, 28 Dec 2010 20:49:50 -0500, Andy Walls wrote:
Remove use of deprecated struct i2c_adapter.id field. In the process,
perform different detection of the HD PVR's Z8 IR microcontroller versus
the other Hauppauge cards with the Z8 IR microcontroller.
Thanks a lot for doing this. I'll be very happy when we can finally get
rid of i2c_adapter.id.
You're welcome. If I hadn't done it, I was worried that lirc_zilog
would have been deleted. I want to fix lirc_zilog properly, but haven't
had the time yet.
Keep in mind, that in this patch I had one objective: remove use of
struct i2c_adapter.id .
I turned a blind-eye to other obvious problems, since fixing
lirc_zilog's problems looked like it was going to be like peeling an
onion. Once you peel back one layer of problems, you find another one
underneath. ;)
Also added a comment about probe() function behavior that needs to be
fixed.
See my suggestion inline below.
Signed-off-by: Andy Walls awa...@md.metrocast.net
---
drivers/staging/lirc/lirc_zilog.c | 47
1 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/lirc/lirc_zilog.c
b/drivers/staging/lirc/lirc_zilog.c
index 52be6de..ad29bb1 100644
--- a/drivers/staging/lirc/lirc_zilog.c
+++ b/drivers/staging/lirc/lirc_zilog.c
@@ -66,6 +66,7 @@ struct IR {
/* Device info */
struct mutex ir_lock;
int open;
+ bool is_hdpvr;
/* RX device */
struct i2c_client c_rx;
@@ -206,16 +207,12 @@ static int add_to_buf(struct IR *ir)
}
/* key pressed ? */
-#ifdef I2C_HW_B_HDPVR
- if (ir-c_rx.adapter-id == I2C_HW_B_HDPVR) {
+ if (ir-is_hdpvr) {
if (got_data (keybuf[0] == 0x80))
return 0;
else if (got_data (keybuf[0] == 0x00))
return -ENODATA;
} else if ((ir-b[0] 0x80) == 0)
-#else
- if ((ir-b[0] 0x80) == 0)
-#endif
return got_data ? 0 : -ENODATA;
/* look what we have */
@@ -841,15 +838,15 @@ static int send_code(struct IR *ir, unsigned int
code, unsigned int key)
return ret 0 ? ret : -EFAULT;
}
-#ifdef I2C_HW_B_HDPVR
/*
* The sleep bits aren't necessary on the HD PVR, and in fact, the
* last i2c_master_recv always fails with a -5, so for now, we're
* going to skip this whole mess and say we're done on the HD PVR
*/
- if (ir-c_rx.adapter-id == I2C_HW_B_HDPVR)
- goto done;
-#endif
+ if (ir-is_hdpvr) {
+ dprintk(sent code %u, key %u\n, code, key);
+ return 0;
+ }
I don't get the change. What was wrong with the goto done? Now you
duplicated the dprintk(), and as far as I can see the done label is
left unused.
Mauro removed the done: label in a commit just prior to this one.
Otherwise, yes, I would have used a goto done:.
So much needs cleaning up in lirc_zilog, that I didn't agonize over this
particular item.
/*
* This bit NAKs until the device is ready, so we retry it
@@ -,12 +1108,14 @@ static int ir_remove(struct i2c_client *client);
static int ir_probe(struct i2c_client *client, const struct i2c_device_id
*id);
static int ir_command(struct i2c_client *client, unsigned int cmd, void
*arg);
+#define ID_FLAG_TX 0x01
+#define ID_FLAG_HDPVR 0x02
+
static const struct i2c_device_id ir_transceiver_id[] = {
- /* Generic entry for any IR transceiver */
- { ir_video, 0 },
- /* IR device specific entries should be added here */
- { ir_tx_z8f0811_haup, 0 },
- { ir_rx_z8f0811_haup, 0 },
+ { ir_tx_z8f0811_haup, ID_FLAG_TX },
+ { ir_rx_z8f0811_haup, 0 },
+ { ir_tx_z8f0811_hdpvr, ID_FLAG_HDPVR | ID_FLAG_TX },
+ { ir_rx_z8f0811_hdpvr, ID_FLAG_HDPVR },
{ }
};
@@ -1196,10 +1195,25 @@ static int ir_probe(struct i2c_client *client,
const struct i2c_device_id *id)
int ret;
int have_rx = 0, have_tx = 0;
- dprintk(%s: adapter id=0x%x, client addr=0x%02x\n,
- __func__, adap-id, client-addr);
+ dprintk(%s: adapter name (%s) nr %d, i2c_device_id name (%s),
+ client addr=0x%02x\n,
+ __func__, adap-name, adap-nr, id-name, client-addr);
The debug message format is long and confusing. What about:
dprintk(%s: %s on i2c-%d (%s), client addr=0x%02x\n,
__func__, id-name, adap-nr, adap-name, client-addr);
Ack. Your suggestion seems fine to me.
/*
+* FIXME - This probe function probes both the Tx and Rx
+* addresses of the IR microcontroller.
+*
+* However, the I2C subsystem is passing along one I2C client
Re: [PATCH 3/3] lirc_zilog: Remove use of deprecated struct i2c_adapter.id field
On Wed, 2011-01-05 at 20:02 -0200, Mauro Carvalho Chehab wrote:
Em 05-01-2011 19:51, Jean Delvare escreveu:
Hi Mauro,
On Wed, 05 Jan 2011 15:34:28 -0200, Mauro Carvalho Chehab wrote:
Hi Jean,
Thanks for your acks for patches 1 and 2. I've already applied the patches
on my tree and at linux-next. I'll try to add the acks on it before sending
upstream.
If you can't, it's fine. I merely wanted to show my support to Andy's
work, I don't care if I'm not counted as a reviewer for these small
patches.
Ok. So, it is probably better to keep it as-is, to avoid rebasing and having
to wait for a couple days at linux-next before sending the git pull request.
Em 05-01-2011 12:45, Jean Delvare escreveu:
From a purely technical perspective, changing client-addr in the
probe() function is totally prohibited.
Agreed. Btw, there are some other hacks with client-addr abuse on some
other random places at drivers/media, mostly at the device bridge code,
used to test if certain devices are present and/or to open some I2C gates
before doing some init code. People use this approach as it provides a
fast way to do some things. On several cases, the amount of code for
doing such hack is very small, when compared to writing a new I2C driver
just to do some static initialization code. Not sure what would be the
better approach to fix them.
Hard to tell without seeing the exact code. Ideally,
i2c_new_dummy() would cover these cases: you don't need to write an
actual driver for the device, it's perfectly OK to use the freshly
instantiated i2c_client from the bridge driver directly. Alternatively,
i2c_smbus_xfer() or i2c_transfer() can be used for one-time data
exchange with any slave on the bus as long as you know what you're
doing (i.e. you know that no i2c_client will ever be instantiated for
this slave.)
If you have specific cases you don't know how to solve, please point me
to them and I'll take a look.
You can take a look at saa7134-cards.c, for example. saa7134_tuner_setup()
has several examples. It starts with this one:
switch (dev-board) {
case SAA7134_BOARD_BMK_MPEX_NOTUNER:
case SAA7134_BOARD_BMK_MPEX_TUNER:
/* Checks if the device has a tuner at 0x60 addr
If the device doesn't have a tuner, TUNER_ABSENT
will be used at tuner_type, avoiding loading tuner
without needing it
*/
dev-i2c_client.addr = 0x60;
board = (i2c_master_recv(dev-i2c_client, buf, 0) 0)
? SAA7134_BOARD_BMK_MPEX_NOTUNER
: SAA7134_BOARD_BMK_MPEX_TUNER;
In this specific case, it is simply a probe for a device at address 0x60, but
there are more complex cases there, with eeprom reads and/or some random init
that happens before actually attaching some driver at the i2c address.
It is known to work, but it sounds like a hack.
The cx18 driver has a function scope i2c_client for reading the EEPROM,
and there's a good reason for it. We don't want to register the EEPROM
with the I2C system and make it visible to the rest of the system,
including i2c-dev and user-space tools. To avoid EEPROM corruption,
it's better keep communication with EEPROMs to a very limited scope.
Regards,
Andy
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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
Question about Night Mode
Hi, i'm interested in implement the Night Mode for the ov7370 driver, and it is done by modifyng 1 bit of the control register 11, but i'm unable to find a V4l2 user Control ID for that (Ex: V4L2-CID-NIGHT_MODE). I also think that the mentioned feature is quite common in cameras so my question is: Is there any control commonly used for that feature or it has to be a hack? Thank you very much -- Roberto Rodríguez Alcalá -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] Add multi-planar API documentation
Hi Hans,
Huge thanks for the review!
On Mon, Jan 3, 2011 at 23:53, Hans Verkuil hverk...@xs4all.nl wrote:
On Tuesday, January 04, 2011 05:20:45 Pawel Osciak wrote:
Add DocBook documentation for the new multi-planar API extensions to the
Video for Linux 2 API DocBook.
Signed-off-by: Pawel Osciak pa...@osciak.com
---
Documentation/DocBook/media-entities.tmpl | 4 +
Documentation/DocBook/v4l/common.xml | 2 +
Documentation/DocBook/v4l/compat.xml | 11 +
Documentation/DocBook/v4l/dev-capture.xml | 13 +-
Documentation/DocBook/v4l/dev-output.xml | 13 +-
Documentation/DocBook/v4l/func-mmap.xml | 10 +-
Documentation/DocBook/v4l/func-munmap.xml | 3 +-
Documentation/DocBook/v4l/io.xml | 242
+
Documentation/DocBook/v4l/pixfmt.xml | 114 +++-
Documentation/DocBook/v4l/planar-apis.xml | 79
Documentation/DocBook/v4l/v4l2.xml | 21 ++-
Documentation/DocBook/v4l/vidioc-enum-fmt.xml | 2 +
Documentation/DocBook/v4l/vidioc-g-fmt.xml | 15 ++-
Documentation/DocBook/v4l/vidioc-qbuf.xml | 24 ++-
Documentation/DocBook/v4l/vidioc-querybuf.xml | 14 +-
Documentation/DocBook/v4l/vidioc-querycap.xml | 14 ++
16 files changed, 515 insertions(+), 66 deletions(-)
create mode 100644 Documentation/DocBook/v4l/planar-apis.xml
diff --git a/Documentation/DocBook/media-entities.tmpl
b/Documentation/DocBook/media-entities.tmpl
index be34dcb..74923d7 100644
--- a/Documentation/DocBook/media-entities.tmpl
+++ b/Documentation/DocBook/media-entities.tmpl
snip
+memset (amp;reqbuf, 0, sizeof (reqbuf));
No space before (
I used the previous example and modified it, I didn't want to change
code style. But I guess it's maybe the original one that should be
corrected as well...
+reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
+reqbuf.memory = V4L2_MEMORY_MMAP;
+reqbuf.count = 20;
+
+if (-1 == ioctl (fd, VIDIOC-REQBUFS;, amp;reqbuf)) {
Ditto. Same below.
It's also better to do 'if (ioctl() 0) {'
Ditto ;) Maybe I should do a separate patch for the original example later.
snip
@@ -596,6 +702,64 @@ should set this to 0./entry
/tgroup
/table
+ table frame=none pgwide=1 id=v4l2-plane
+ titlestruct structnamev4l2_plane/structname/title
+ tgroup cols=4
+ cs-ustr;
+ tbody valign=top
+ row
+ entry__u32/entry
+ entrystructfieldbytesused/structfield/entry
+ entry/entry
+ entryThe number of bytes occupied by data in the plane
+ (its payload)./entry
+ /row
+ row
+ entry__u32/entry
+ entrystructfieldlength/structfield/entry
+ entry/entry
+ entrySize in bytes of the plane (not its payload)./entry
+ /row
+ row
+ entryunion/entry
+ entrystructfieldm/structfield/entry
+ entry/entry
+ entry/entry
+ /row
+ row
+ entry/entry
+ entry__u32/entry
+ entrystructfieldmem_offset/structfield/entry
+ entryWhen memory type in the containing v4l2-buffer; is
When the
+ constantV4L2_MEMORY_MMAP/constant, this is the value that
+ should be passed to func-mmap;, analogically to the
analogically - similar
+ structfieldoffset/structfield field in v4l2-buffer;./entry
+ /row
+ row
+ entry/entry
+ entry__unsigned long/entry
+ entrystructfielduserptr/structfield/entry
+ entryWhen memory type in the containing v4l2-buffer; is
When the
+ constantV4L2_MEMORY_USERPTR/constant, a userspace pointer
a userspace - this is a userspace
+ to memory allocated for this plane by an application./entry
+ /row
+ row
+ entry__u32/entry
+ entrystructfielddata_offset/structfield/entry
+ entry/entry
+ entryOffset in bytes to video data in the plane, if applicable.
+ /entry
+ /row
+ row
+ entry__u32/entry
+ entrystructfieldreserved[11]/structfield/entry
+ entry/entry
+ entryReserved for future use. Should be zero./entry
Who zeroes this? Driver and/or application?
Well, it's ignored, as most reserved fields are. Should I say the
application should zero it? Or maybe even say nothing at all?
snip
diff --git a/Documentation/DocBook/v4l/planar-apis.xml
b/Documentation/DocBook/v4l/planar-apis.xml
new file mode 100644
index 000..ce89831
--- /dev/null
+++ b/Documentation/DocBook/v4l/planar-apis.xml
@@ -0,0 +1,79 @@
+section id=planar-apis
+ titleSingle- and multi-planar APIs/title
+
+ paraSome devices require data for each input or output video frame
+ to be placed in discontiguous memory buffers. In such cases one
+ video frame has to be addressed using more than one memory address, i.e.
one
+ pointer
RE: [RFC PATCH 0/2] davinci: convert to core-assisted locking
Tested for SD loopback and other IOCTLS. Reviewed the patches. Patch series Acked by: Manjunath Hadli manjunath.ha...@ti.com -Manju On Wed, Jan 05, 2011 at 22:12:38, Hans Verkuil wrote: These two patches convert vpif_capture and vpif_display to core-assisted locking and now use .unlocked_ioctl instead of .ioctl. These patches assume that the 'DaVinci VPIF: Support for DV preset and DV timings' patch series was applied first. See: http://www.mail-archive.com/linux-media@vger.kernel.org/msg26594.html These patches are targeted for 2.6.38. 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: Question about Night Mode
On Thu, 6 Jan 2011, Roberto Rodriguez Alcala wrote: Hi, i'm interested in implement the Night Mode for the ov7370 driver, and it is done by modifyng 1 bit of the control register 11, but i'm unable to find a V4l2 user Control ID for that (Ex: V4L2-CID-NIGHT_MODE). I also think that the mentioned feature is quite common in cameras so my question is: Is there any control commonly used for that feature or it has to be a hack? I cannot claim, that I understand what all existing controls do, but in general, I would say, try to think, whether one of them has the same function, as what you need, is you find one - use it, if not - try to propose a new control ID. Of course, you can always implement a driver-private control, using V4L2_CID_PRIVATE_BASE, but it is not for features, that are common for multiple devices. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] Add multi-planar API documentation
On Thursday, January 06, 2011 06:53:37 Pawel Osciak wrote:
Hi Hans,
Huge thanks for the review!
On Mon, Jan 3, 2011 at 23:53, Hans Verkuil hverk...@xs4all.nl wrote:
On Tuesday, January 04, 2011 05:20:45 Pawel Osciak wrote:
Add DocBook documentation for the new multi-planar API extensions to the
Video for Linux 2 API DocBook.
Signed-off-by: Pawel Osciak pa...@osciak.com
---
Documentation/DocBook/media-entities.tmpl |4 +
Documentation/DocBook/v4l/common.xml |2 +
Documentation/DocBook/v4l/compat.xml | 11 +
Documentation/DocBook/v4l/dev-capture.xml | 13 +-
Documentation/DocBook/v4l/dev-output.xml | 13 +-
Documentation/DocBook/v4l/func-mmap.xml | 10 +-
Documentation/DocBook/v4l/func-munmap.xml |3 +-
Documentation/DocBook/v4l/io.xml | 242
+
Documentation/DocBook/v4l/pixfmt.xml | 114 +++-
Documentation/DocBook/v4l/planar-apis.xml | 79
Documentation/DocBook/v4l/v4l2.xml| 21 ++-
Documentation/DocBook/v4l/vidioc-enum-fmt.xml |2 +
Documentation/DocBook/v4l/vidioc-g-fmt.xml| 15 ++-
Documentation/DocBook/v4l/vidioc-qbuf.xml | 24 ++-
Documentation/DocBook/v4l/vidioc-querybuf.xml | 14 +-
Documentation/DocBook/v4l/vidioc-querycap.xml | 14 ++
16 files changed, 515 insertions(+), 66 deletions(-)
create mode 100644 Documentation/DocBook/v4l/planar-apis.xml
diff --git a/Documentation/DocBook/media-entities.tmpl
b/Documentation/DocBook/media-entities.tmpl
index be34dcb..74923d7 100644
--- a/Documentation/DocBook/media-entities.tmpl
+++ b/Documentation/DocBook/media-entities.tmpl
snip
+memset (amp;reqbuf, 0, sizeof (reqbuf));
No space before (
I used the previous example and modified it, I didn't want to change
code style. But I guess it's maybe the original one that should be
corrected as well...
+reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
+reqbuf.memory = V4L2_MEMORY_MMAP;
+reqbuf.count = 20;
+
+if (-1 == ioctl (fd, VIDIOC-REQBUFS;, amp;reqbuf)) {
Ditto. Same below.
It's also better to do 'if (ioctl() 0) {'
Ditto ;) Maybe I should do a separate patch for the original example later.
Probably a good idea. This example code is really old, written before the
cding style was strictly enforced. Cleaning it up is a good idea.
snip
+ to memory allocated for this plane by an application./entry
+ /row
+ row
+ entry__u32/entry
+ entrystructfielddata_offset/structfield/entry
+ entry/entry
+ entryOffset in bytes to video data in the plane, if applicable.
+ /entry
+ /row
+ row
+ entry__u32/entry
+ entrystructfieldreserved[11]/structfield/entry
+ entry/entry
+ entryReserved for future use. Should be zero./entry
Who zeroes this? Driver and/or application?
Well, it's ignored, as most reserved fields are. Should I say the
application should zero it? Or maybe even say nothing at all?
Typically write ioctls (_IOW/_IOWR) require the app to zero reserved fields,
while read ioctls (_IOR/_IOWR) require the driver to zero reserved fields.
This is usually mentioned in the spec, particularly if the app has to zero
the fields. If you don't mention that apps should zero, then they typically
don't :-)
snip
+ section
+titleCalls that distinguish between single and multi-planar
APIs/title
+variablelist
+ varlistentry
+termVIDIOC-QUERYCAP;/term
+listitemTwo additional multi-planar capabilities are added.
They can
+be set together with non-multi-planar ones for devices that
support both
+APIs./listitem
What happens if a driver supports only single-planar API, but the core adds
transparent support for multi-planar API? Are the MPLANE caps set or not?
I can't remember what we decided to do. Ditto for the other way around
(driver
does only multi-planar, but core adds single-planar support).
Hm, that's a good point. Right now are not hijacking the caps ioctl...
This is tricky though, I don't see any good solutions. Adding
additional caps artificially would practically result in
V4L2_CAP_VIDEO_CAPTURE_MPLANE == V4L2_CAP_VIDEO_CAPTURE. But what
makes MPLANE or not-MPLANE supported are the actual formats later
on, not the API.
If we were to add artificial caps, then adding non-mplane caps to
mplane drivers might actually be the problematic case: if a
multi-planar driver didn't support any single-planar formats (and
there would be no practical way of knowing that from our standpoint),
a single-planar application would ENUM_FMT and get 0 formats, which
wouldn't be good.
Adding mplane caps to non-mplane drivers might actually be somehow
safer, as long as the application behaves and uses only single-planar
formats (as
