Re: [PATCH] Add support for M-5MOLS 8 Mega Pixel camera
Hi Sylwester, 2011-03-20 오전 4:28, Sylwester Nawrocki 쓴 글: On 03/19/2011 04:11 PM, Kim HeungJun wrote: Hi Sylwester, Thanks for the reviews. :) 2011. 3. 19., 오후 10:37, Sylwester Nawrocki 작성: Hi HeungJun, On 03/16/2011 02:38 PM, Kim, Heungjun wrote: Add I2C/V4L2 subdev driver for M-5MOLS camera sensor with integrated image signal processor. [snip] 3. Speed-up whole I2C operation : I've tested several times for decreasing the stabilization time while I2C communication, and I have find proper time. Of course, it's more faster than previous version. That sounds good. Do you think the delays before I2C read/write could be avoided in some (if not all) cases by using some status registers polling? I don't understand literally. Could you explain more detailed with some examples? My understanding is that it might be an issues or problem when getting some status registers with polling it. is it right? My concern is that we might not need an extra delay between consecutive read or write operations in every case. Possibly it would be enough to read the status of some operations instead. But that just what I suspect. Ah, I understand. The consecutive delay needs to read/write operations. Because, in non-delay cases, I found the values is not changed to be read when the driver is reading continuously at the different address. I means, if there is not regular amount of delay in r/w operations, the value is kept the previous value to be read by I2C operation. It's the same way in writing case. It's wierd. It might be different the kind of M-5MOLS sensor's FW and packaging type. But, I expect that the internal ARM core of M-5MOLS takes time to proceed something and to load values through I2C bus for the host process. Regards, Heungjun Kim -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] [media] vb2: vb2_poll() fix return values for file I/O mode
Hello,
On Monday, March 21, 2011 12:31 AM Pawel Osciak wrote:
poll() should be returning poll-specific error values, not E* errors.
Signed-off-by: Pawel Osciak pa...@osciak.com
Acked-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/video/videobuf2-core.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index ce03225..8c6f04b 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -1364,18 +1364,18 @@ unsigned int vb2_poll(struct vb2_queue *q, struct
file *file, poll_table *wait)
struct vb2_buffer *vb = NULL;
/*
- * Start file io emulator if streaming api has not been used yet.
+ * Start file I/O emulator only if streaming API has not been used yet.
*/
if (q-num_buffers == 0 q-fileio == NULL) {
if (!V4L2_TYPE_IS_OUTPUT(q-type) (q-io_modes VB2_READ)) {
ret = __vb2_init_fileio(q, 1);
if (ret)
- return ret;
+ return POLLERR;
}
if (V4L2_TYPE_IS_OUTPUT(q-type) (q-io_modes VB2_WRITE)) {
ret = __vb2_init_fileio(q, 0);
if (ret)
- return ret;
+ return POLLERR;
/*
* Write to OUTPUT queue can be done immediately.
*/
--
1.7.4.1
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
referencing other control values in the clustered control
Hi Hans, I have a question about referencing control values. For example: 1) A control and B control is clustered, and each is defined v4l2_ctrl a, b. 2) These two control is relevant, and start to make one process by real control A. 3) The b-val is should be referenced for process in the A control function, even though in which is the A. And, in this case, 3) is right? I mean, if the ctrl value clustered with another ctrl can be referenced in the another ctrl function, or not. Regards, Heungjun Kim -- 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/2] [media] vb2: Handle return value from start_streaming callback
Hello,
On Monday, March 21, 2011 12:31 AM Pawel Osciak wrote:
Fix vb2 not handling return value from start_streaming() callback.
Signed-off-by: Pawel Osciak pa...@osciak.com
Acked-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/video/videobuf2-core.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 8c6f04b..6698c77 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -,6 +,7 @@ EXPORT_SYMBOL_GPL(vb2_dqbuf);
int vb2_streamon(struct vb2_queue *q, enum v4l2_buf_type type)
{
struct vb2_buffer *vb;
+ int ret;
if (q-fileio) {
dprintk(1, streamon: file io in progress\n);
@@ -1138,12 +1139,16 @@ int vb2_streamon(struct vb2_queue *q, enum
v4l2_buf_type type)
}
}
- q-streaming = 1;
-
/*
* Let driver notice that streaming state has been enabled.
*/
- call_qop(q, start_streaming, q);
+ ret = call_qop(q, start_streaming, q);
+ if (ret) {
+ dprintk(1, streamon: driver refused to start streaming\n);
+ return ret;
+ }
+
+ q-streaming = 1;
/*
* If any buffers were queued before streamon,
--
1.7.4.1
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
[PATCH] V4L: soc-camera: explicitly require V4L2_BUF_TYPE_VIDEO_CAPTURE
The soc-camera core accesses the pix member of the struct v4l2_format::fmt
union, which is only valid for V4L2_BUF_TYPE_VIDEO_CAPTURE streams. This
patch adds explicit checks for this to {g,s,try}_fmt methods.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Trying to quickly rotate this pretty trivial patch through the list to
hopefully push it for the second 2.6.39 v4l pull request.
drivers/media/video/soc_camera.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 07525e7..4628448 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -144,6 +144,10 @@ static int soc_camera_try_fmt_vid_cap(struct file *file,
void *priv,
WARN_ON(priv != file-private_data);
+ /* Only single-plane capture is supported so far */
+ if (f-type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+
/* limit format to hardware capabilities */
return ici-ops-try_fmt(icd, f);
}
@@ -396,10 +400,6 @@ static int soc_camera_set_fmt(struct soc_camera_device
*icd,
if (ici-ops-init_videobuf)
icd-vb_vidq.field = pix-field;
- if (f-type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
- dev_warn(icd-dev, Attention! Wrong buf-type %d\n,
-f-type);
-
dev_dbg(icd-dev, set width: %d height: %d\n,
icd-user_width, icd-user_height);
@@ -618,6 +618,11 @@ static int soc_camera_s_fmt_vid_cap(struct file *file,
void *priv,
WARN_ON(priv != file-private_data);
+ if (f-type != V4L2_BUF_TYPE_VIDEO_CAPTURE) {
+ dev_warn(icd-dev, Wrong buf-type %d\n, f-type);
+ return -EINVAL;
+ }
+
if (icd-streamer icd-streamer != file)
return -EBUSY;
@@ -661,6 +666,9 @@ static int soc_camera_g_fmt_vid_cap(struct file *file, void
*priv,
WARN_ON(priv != file-private_data);
+ if (f-type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+
pix-width = icd-user_width;
pix-height = icd-user_height;
pix-bytesperline = icd-bytesperline;
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/9] vp702x: get rid of on-stack dma buffers (part2 1/2)
Hi! This is a patchset modifying the vp702x to get rid of on-stack dma buffers and additionally preallocating the used buffers on device probe. I can not test these patches, as I don't have the hardware. They compile though... I made it a bit more finegrained for easier review. If someone could test these, that would be appreciated. I have a few more patches to dib0700 and gp8psk to also use a preallocated buffer, but I'm not shure the added complexity is worth it. So I'm waiting on feedback to the vp702x to proceed. I have another batch of patches to opera1, m920x, dw2102, friio, a800 which I did not modify since my first patch submission. Regards, Flo Florian Mickler (9): [media] vp702x: cleanup: whitespace and indentation [media] vp702x: rename struct vp702x_state - vp702x_adapter_state [media] vp702x: preallocate memory on device probe [media] vp702x: remove unused variable [media] vp702x: get rid of on-stack dma buffers [media] vp702x: fix locking of usb operations [media] vp702x: use preallocated buffer [media] vp702x: use preallocated buffer in vp702x_usb_inout_cmd [media] vp702x: use preallocated buffer in the frontend drivers/media/dvb/dvb-usb/vp702x-fe.c | 80 + drivers/media/dvb/dvb-usb/vp702x.c| 213 ++--- drivers/media/dvb/dvb-usb/vp702x.h|7 + 3 files changed, 233 insertions(+), 67 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] [media] vp702x: preallocate memory on device probe
This sets up a buffer and a mutex protecting that buffer in
the struct vp702x_device_state.
The definition of struct vp702x_device_state is moved into the header
in order to use the buffer also in the frontend.
Signed-off-by: Florian Mickler flor...@mickler.org
---
drivers/media/dvb/dvb-usb/vp702x.c | 41 +--
drivers/media/dvb/dvb-usb/vp702x.h |8 +++
2 files changed, 42 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/vp702x.c
b/drivers/media/dvb/dvb-usb/vp702x.c
index 25536f9..569c93f 100644
--- a/drivers/media/dvb/dvb-usb/vp702x.c
+++ b/drivers/media/dvb/dvb-usb/vp702x.c
@@ -15,6 +15,7 @@
* see Documentation/dvb/README.dvb-usb for more information
*/
#include vp702x.h
+#include linux/mutex.h
/* debug */
int dvb_usb_vp702x_debug;
@@ -29,10 +30,6 @@ struct vp702x_adapter_state {
u8 pid_filter_state;
};
-struct vp702x_device_state {
- u8 power_state;
-};
-
/* check for mutex FIXME */
int vp702x_usb_in_op(struct dvb_usb_device *d, u8 req, u16 value, u16 index,
u8 *b, int blen)
{
@@ -241,8 +238,38 @@ static struct dvb_usb_device_properties vp702x_properties;
static int vp702x_usb_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
- return dvb_usb_device_init(intf, vp702x_properties,
- THIS_MODULE, NULL, adapter_nr);
+ struct dvb_usb_device *d;
+ struct vp702x_device_state *st;
+ int ret;
+
+ ret = dvb_usb_device_init(intf, vp702x_properties,
+ THIS_MODULE, d, adapter_nr);
+ if (ret)
+ goto out;
+
+ st = d-priv;
+ st-buf_len = 16;
+ st-buf = kmalloc(st-buf_len, GFP_KERNEL);
+ if (!st-buf) {
+ ret = -ENOMEM;
+ dvb_usb_device_exit(intf);
+ goto out;
+ }
+ mutex_init(st-buf_mutex);
+
+out:
+ return ret;
+
+}
+
+static void vp702x_usb_disconnect(struct usb_interface *intf)
+{
+ struct dvb_usb_device *d = usb_get_intfdata(intf);
+ struct vp702x_device_state *st = d-priv;
+ mutex_lock(st-buf_mutex);
+ kfree(st-buf);
+ mutex_unlock(st-buf_mutex);
+ dvb_usb_device_exit(intf);
}
static struct usb_device_id vp702x_usb_table [] = {
@@ -309,7 +336,7 @@ static struct dvb_usb_device_properties vp702x_properties =
{
static struct usb_driver vp702x_usb_driver = {
.name = dvb_usb_vp702x,
.probe = vp702x_usb_probe,
- .disconnect = dvb_usb_device_exit,
+ .disconnect = vp702x_usb_disconnect,
.id_table = vp702x_usb_table,
};
diff --git a/drivers/media/dvb/dvb-usb/vp702x.h
b/drivers/media/dvb/dvb-usb/vp702x.h
index c2f97f9..86960c6 100644
--- a/drivers/media/dvb/dvb-usb/vp702x.h
+++ b/drivers/media/dvb/dvb-usb/vp702x.h
@@ -98,6 +98,14 @@ extern int dvb_usb_vp702x_debug;
#define RESET_TUNER0xBE
/* IN i: 0, v: 0, no extra buffer */
+struct vp702x_device_state {
+ u8 power_state;
+ struct mutex buf_mutex;
+ int buf_len;
+ u8 *buf;
+};
+
+
extern struct dvb_frontend * vp702x_fe_attach(struct dvb_usb_device *d);
extern int vp702x_usb_inout_op(struct dvb_usb_device *d, u8 *o, int olen, u8
*i, int ilen, int msec);
--
1.7.4.1
--
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/9] [media] vp702x: cleanup: whitespace and indentation
Some whitespace, one linebreak and one unneded variable
initialization...
Signed-off-by: Florian Mickler flor...@mickler.org
---
drivers/media/dvb/dvb-usb/vp702x.c | 23 ---
1 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/vp702x.c
b/drivers/media/dvb/dvb-usb/vp702x.c
index 7890e75..4c9939f 100644
--- a/drivers/media/dvb/dvb-usb/vp702x.c
+++ b/drivers/media/dvb/dvb-usb/vp702x.c
@@ -36,14 +36,14 @@ struct vp702x_device_state {
/* check for mutex FIXME */
int vp702x_usb_in_op(struct dvb_usb_device *d, u8 req, u16 value, u16 index,
u8 *b, int blen)
{
- int ret = -1;
+ int ret;
- ret = usb_control_msg(d-udev,
- usb_rcvctrlpipe(d-udev,0),
- req,
- USB_TYPE_VENDOR | USB_DIR_IN,
- value,index,b,blen,
- 2000);
+ ret = usb_control_msg(d-udev,
+ usb_rcvctrlpipe(d-udev, 0),
+ req,
+ USB_TYPE_VENDOR | USB_DIR_IN,
+ value, index, b, blen,
+ 2000);
if (ret 0) {
warn(usb in operation failed. (%d), ret);
@@ -221,7 +221,8 @@ static int vp702x_frontend_attach(struct dvb_usb_adapter
*adap)
vp702x_usb_out_op(adap-dev, SET_TUNER_POWER_REQ, 0, 7, NULL, 0);
- if (vp702x_usb_inout_cmd(adap-dev, GET_SYSTEM_STRING, NULL, 0, buf,
10, 10))
+ if (vp702x_usb_inout_cmd(adap-dev, GET_SYSTEM_STRING, NULL, 0,
+ buf, 10, 10))
return -EIO;
buf[9] = '\0';
@@ -307,9 +308,9 @@ static struct dvb_usb_device_properties vp702x_properties =
{
/* usb specific object needed to register this driver with the usb subsystem */
static struct usb_driver vp702x_usb_driver = {
.name = dvb_usb_vp702x,
- .probe = vp702x_usb_probe,
- .disconnect = dvb_usb_device_exit,
- .id_table = vp702x_usb_table,
+ .probe = vp702x_usb_probe,
+ .disconnect = dvb_usb_device_exit,
+ .id_table = vp702x_usb_table,
};
/* module stuff */
--
1.7.4.1
--
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/9] [media] vp702x: rename struct vp702x_state - vp702x_adapter_state
We need a state struct for the dvb_usb_device.
In order to reduce confusion we rename the vp702x_state struct.
Signed-off-by: Florian Mickler flor...@mickler.org
---
drivers/media/dvb/dvb-usb/vp702x.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/vp702x.c
b/drivers/media/dvb/dvb-usb/vp702x.c
index 4c9939f..25536f9 100644
--- a/drivers/media/dvb/dvb-usb/vp702x.c
+++ b/drivers/media/dvb/dvb-usb/vp702x.c
@@ -23,7 +23,7 @@ MODULE_PARM_DESC(debug, set debugging level
(1=info,xfer=2,rc=4 (or-able)). DV
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
-struct vp702x_state {
+struct vp702x_adapter_state {
int pid_filter_count;
int pid_filter_can_bypass;
u8 pid_filter_state;
@@ -126,7 +126,7 @@ static int vp702x_set_pld_state(struct dvb_usb_adapter
*adap, u8 state)
static int vp702x_set_pid(struct dvb_usb_adapter *adap, u16 pid, u8 id, int
onoff)
{
- struct vp702x_state *st = adap-priv;
+ struct vp702x_adapter_state *st = adap-priv;
u8 buf[16] = { 0 };
if (onoff)
@@ -147,7 +147,7 @@ static int vp702x_set_pid(struct dvb_usb_adapter *adap, u16
pid, u8 id, int onof
static int vp702x_init_pid_filter(struct dvb_usb_adapter *adap)
{
- struct vp702x_state *st = adap-priv;
+ struct vp702x_adapter_state *st = adap-priv;
int i;
u8 b[10] = { 0 };
@@ -279,7 +279,7 @@ static struct dvb_usb_device_properties vp702x_properties =
{
}
}
},
- .size_of_priv = sizeof(struct vp702x_state),
+ .size_of_priv = sizeof(struct vp702x_adapter_state),
}
},
.read_mac_address = vp702x_read_mac_addr,
--
1.7.4.1
--
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 6/9] [media] vp702x: fix locking of usb operations
Otherwise it is not obvious that vp702x_usb_in_op or vp702x_usb_out_op
will not interfere with any vp702x_usb_inout_op.
Note: This change is tested to compile only, as I don't have the
hardware.
Signed-off-by: Florian Mickler flor...@mickler.org
---
drivers/media/dvb/dvb-usb/vp702x.c | 37 +--
1 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/vp702x.c
b/drivers/media/dvb/dvb-usb/vp702x.c
index 35fe778..c82cb6b 100644
--- a/drivers/media/dvb/dvb-usb/vp702x.c
+++ b/drivers/media/dvb/dvb-usb/vp702x.c
@@ -30,8 +30,8 @@ struct vp702x_adapter_state {
u8 pid_filter_state;
};
-/* check for mutex FIXME */
-int vp702x_usb_in_op(struct dvb_usb_device *d, u8 req, u16 value, u16 index,
u8 *b, int blen)
+static int vp702x_usb_in_op_unlocked(struct dvb_usb_device *d, u8 req,
+u16 value, u16 index, u8 *b, int blen)
{
int ret;
@@ -55,8 +55,20 @@ int vp702x_usb_in_op(struct dvb_usb_device *d, u8 req, u16
value, u16 index, u8
return ret;
}
-static int vp702x_usb_out_op(struct dvb_usb_device *d, u8 req, u16 value,
-u16 index, u8 *b, int blen)
+int vp702x_usb_in_op(struct dvb_usb_device *d, u8 req, u16 value,
+ u16 index, u8 *b, int blen)
+{
+ int ret;
+
+ mutex_lock(d-usb_mutex);
+ ret = vp702x_usb_in_op_unlocked(d, req, value, index, b, blen);
+ mutex_unlock(d-usb_mutex);
+
+ return ret;
+}
+
+int vp702x_usb_out_op_unlocked(struct dvb_usb_device *d, u8 req, u16 value,
+ u16 index, u8 *b, int blen)
{
int ret;
deb_xfer(out: req. %02x, val: %04x, ind: %04x, buffer:
,req,value,index);
@@ -74,6 +86,18 @@ static int vp702x_usb_out_op(struct dvb_usb_device *d, u8
req, u16 value,
return 0;
}
+int vp702x_usb_out_op(struct dvb_usb_device *d, u8 req, u16 value,
+u16 index, u8 *b, int blen)
+{
+ int ret;
+
+ mutex_lock(d-usb_mutex);
+ ret = vp702x_usb_out_op_unlocked(d, req, value, index, b, blen);
+ mutex_unlock(d-usb_mutex);
+
+ return ret;
+}
+
int vp702x_usb_inout_op(struct dvb_usb_device *d, u8 *o, int olen, u8 *i, int
ilen, int msec)
{
int ret;
@@ -81,12 +105,11 @@ int vp702x_usb_inout_op(struct dvb_usb_device *d, u8 *o,
int olen, u8 *i, int il
if ((ret = mutex_lock_interruptible(d-usb_mutex)))
return ret;
- ret = vp702x_usb_out_op(d,REQUEST_OUT,0,0,o,olen);
+ ret = vp702x_usb_out_op_unlocked(d, REQUEST_OUT, 0, 0, o, olen);
msleep(msec);
- ret = vp702x_usb_in_op(d,REQUEST_IN,0,0,i,ilen);
+ ret = vp702x_usb_in_op_unlocked(d, REQUEST_IN, 0, 0, i, ilen);
mutex_unlock(d-usb_mutex);
-
return ret;
}
--
1.7.4.1
--
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 9/9] [media] vp702x: use preallocated buffer in the frontend
Note: This change is tested to compile only as I don't have the
hardware.
Signed-off-by: Florian Mickler flor...@mickler.org
---
drivers/media/dvb/dvb-usb/vp702x-fe.c | 69 +
1 files changed, 35 insertions(+), 34 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/vp702x-fe.c
b/drivers/media/dvb/dvb-usb/vp702x-fe.c
index 7468a38..2bb8d4c 100644
--- a/drivers/media/dvb/dvb-usb/vp702x-fe.c
+++ b/drivers/media/dvb/dvb-usb/vp702x-fe.c
@@ -41,14 +41,13 @@ struct vp702x_fe_state {
static int vp702x_fe_refresh_state(struct vp702x_fe_state *st)
{
+ struct vp702x_device_state *dst = st-d-priv;
u8 *buf;
if (time_after(jiffies, st-next_status_check)) {
- buf = kmalloc(10, GFP_KERNEL);
- if (!buf) {
- deb_fe(%s: buffer alloc failed\n, __func__);
- return -ENOMEM;
- }
+ mutex_lock(dst-buf_mutex);
+ buf = dst-buf;
+
vp702x_usb_in_op(st-d, READ_STATUS, 0, 0, buf, 10);
st-lock = buf[4];
@@ -58,9 +57,8 @@ static int vp702x_fe_refresh_state(struct vp702x_fe_state *st)
vp702x_usb_in_op(st-d, READ_TUNER_REG_REQ, 0x15, 0, buf, 1);
st-sig = buf[0];
-
+ mutex_unlock(dst-buf_mutex);
st-next_status_check = jiffies +
(st-status_check_interval*HZ)/1000;
- kfree(buf);
}
return 0;
}
@@ -141,15 +139,17 @@ static int vp702x_fe_set_frontend(struct dvb_frontend* fe,
struct dvb_frontend_parameters *fep)
{
struct vp702x_fe_state *st = fe-demodulator_priv;
+ struct vp702x_device_state *dst = st-d-priv;
u32 freq = fep-frequency/1000;
/*CalFrequency*/
/* u16 frequencyRef[16] = { 2, 4, 8, 16, 32, 64, 128, 256, 24, 5, 10, 20,
40, 80, 160, 320 }; */
u64 sr;
u8 *cmd;
- cmd = kzalloc(10, GFP_KERNEL);
- if (!cmd)
- return -ENOMEM;
+ mutex_lock(dst-buf_mutex);
+
+ cmd = dst-buf;
+ memset(cmd, 0, 10);
cmd[0] = (freq 8) 0x7f;
cmd[1] = freq0xff;
@@ -192,7 +192,8 @@ static int vp702x_fe_set_frontend(struct dvb_frontend* fe,
else
deb_fe(tuning succeeded.\n);
- kfree(cmd);
+ mutex_unlock(dst-buf_mutex);
+
return 0;
}
@@ -220,21 +221,18 @@ static int vp702x_fe_get_frontend(struct dvb_frontend* fe,
static int vp702x_fe_send_diseqc_msg (struct dvb_frontend* fe,
struct dvb_diseqc_master_cmd *m)
{
- int ret;
u8 *cmd;
struct vp702x_fe_state *st = fe-demodulator_priv;
-
- cmd = kzalloc(10, GFP_KERNEL);
- if (!cmd)
- return -ENOMEM;
+ struct vp702x_device_state *dst = st-d-priv;
deb_fe(%s\n,__func__);
- if (m-msg_len 4) {
- ret = -EINVAL;
- goto out;
- }
+ if (m-msg_len 4)
+ return -EINVAL;
+
+ mutex_lock(dst-buf_mutex);
+ cmd = dst-buf;
cmd[1] = SET_DISEQC_CMD;
cmd[2] = m-msg_len;
memcpy(cmd[3], m-msg, m-msg_len);
@@ -246,10 +244,10 @@ static int vp702x_fe_send_diseqc_msg (struct
dvb_frontend* fe,
deb_fe(diseqc cmd failed.\n);
else
deb_fe(diseqc cmd succeeded.\n);
- ret = 0;
-out:
- kfree(cmd);
- return ret;
+
+ mutex_unlock(dst-buf_mutex);
+
+ return 0;
}
static int vp702x_fe_send_diseqc_burst (struct dvb_frontend* fe,
fe_sec_mini_cmd_t burst)
@@ -261,14 +259,11 @@ static int vp702x_fe_send_diseqc_burst (struct
dvb_frontend* fe, fe_sec_mini_cmd
static int vp702x_fe_set_tone(struct dvb_frontend* fe, fe_sec_tone_mode_t tone)
{
struct vp702x_fe_state *st = fe-demodulator_priv;
+ struct vp702x_device_state *dst = st-d-priv;
u8 *buf;
deb_fe(%s\n,__func__);
- buf = kmalloc(10, GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
-
st-tone_mode = tone;
if (tone == SEC_TONE_ON)
@@ -277,6 +272,10 @@ static int vp702x_fe_set_tone(struct dvb_frontend* fe,
fe_sec_tone_mode_t tone)
st-lnb_buf[2] = 0x00;
st-lnb_buf[7] = vp702x_chksum(st-lnb_buf, 0, 7);
+
+ mutex_lock(dst-buf_mutex);
+
+ buf = dst-buf;
memcpy(buf, st-lnb_buf, 8);
vp702x_usb_inout_op(st-d, buf, 8, buf, 10, 100);
@@ -285,7 +284,8 @@ static int vp702x_fe_set_tone(struct dvb_frontend* fe,
fe_sec_tone_mode_t tone)
else
deb_fe(set_tone cmd succeeded.\n);
- kfree(buf);
+ mutex_unlock(dst-buf_mutex);
+
return 0;
}
@@ -293,13 +293,10 @@ static int vp702x_fe_set_voltage (struct dvb_frontend*
fe, fe_sec_voltage_t
voltage)
{
struct vp702x_fe_state *st = fe-demodulator_priv;
+ struct vp702x_device_state *dst = st-d-priv;
[PATCH 5/9] [media] vp702x: get rid of on-stack dma buffers
usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.
In lib/dma_debug.c the function check_for_stack even warns about it:
WARNING: at lib/dma-debug.c:866 check_for_stack
Note: This change is tested to compile only, as I don't have the hardware.
Signed-off-by: Florian Mickler flor...@mickler.org
---
drivers/media/dvb/dvb-usb/vp702x-fe.c | 89 +++--
drivers/media/dvb/dvb-usb/vp702x.c| 78 ++--
2 files changed, 124 insertions(+), 43 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/vp702x-fe.c
b/drivers/media/dvb/dvb-usb/vp702x-fe.c
index ccc7e44..7468a38 100644
--- a/drivers/media/dvb/dvb-usb/vp702x-fe.c
+++ b/drivers/media/dvb/dvb-usb/vp702x-fe.c
@@ -41,15 +41,26 @@ struct vp702x_fe_state {
static int vp702x_fe_refresh_state(struct vp702x_fe_state *st)
{
- u8 buf[10];
- if (time_after(jiffies,st-next_status_check)) {
- vp702x_usb_in_op(st-d,READ_STATUS,0,0,buf,10);
-
+ u8 *buf;
+
+ if (time_after(jiffies, st-next_status_check)) {
+ buf = kmalloc(10, GFP_KERNEL);
+ if (!buf) {
+ deb_fe(%s: buffer alloc failed\n, __func__);
+ return -ENOMEM;
+ }
+ vp702x_usb_in_op(st-d, READ_STATUS, 0, 0, buf, 10);
st-lock = buf[4];
- vp702x_usb_in_op(st-d,READ_TUNER_REG_REQ,0x11,0,st-snr,1);
- vp702x_usb_in_op(st-d,READ_TUNER_REG_REQ,0x15,0,st-sig,1);
+
+ vp702x_usb_in_op(st-d, READ_TUNER_REG_REQ, 0x11, 0, buf, 1);
+ st-snr = buf[0];
+
+ vp702x_usb_in_op(st-d, READ_TUNER_REG_REQ, 0x15, 0, buf, 1);
+ st-sig = buf[0];
+
st-next_status_check = jiffies +
(st-status_check_interval*HZ)/1000;
+ kfree(buf);
}
return 0;
}
@@ -134,7 +145,11 @@ static int vp702x_fe_set_frontend(struct dvb_frontend* fe,
/*CalFrequency*/
/* u16 frequencyRef[16] = { 2, 4, 8, 16, 32, 64, 128, 256, 24, 5, 10, 20,
40, 80, 160, 320 }; */
u64 sr;
- u8 cmd[8] = { 0 },ibuf[10];
+ u8 *cmd;
+
+ cmd = kzalloc(10, GFP_KERNEL);
+ if (!cmd)
+ return -ENOMEM;
cmd[0] = (freq 8) 0x7f;
cmd[1] = freq0xff;
@@ -170,13 +185,14 @@ static int vp702x_fe_set_frontend(struct dvb_frontend* fe,
st-status_check_interval = 250;
st-next_status_check = jiffies;
- vp702x_usb_inout_op(st-d,cmd,8,ibuf,10,100);
+ vp702x_usb_inout_op(st-d, cmd, 8, cmd, 10, 100);
- if (ibuf[2] == 0 ibuf[3] == 0)
+ if (cmd[2] == 0 cmd[3] == 0)
deb_fe(tuning failed.\n);
else
deb_fe(tuning succeeded.\n);
+ kfree(cmd);
return 0;
}
@@ -204,28 +220,36 @@ static int vp702x_fe_get_frontend(struct dvb_frontend* fe,
static int vp702x_fe_send_diseqc_msg (struct dvb_frontend* fe,
struct dvb_diseqc_master_cmd *m)
{
+ int ret;
+ u8 *cmd;
struct vp702x_fe_state *st = fe-demodulator_priv;
- u8 cmd[8],ibuf[10];
- memset(cmd,0,8);
+
+ cmd = kzalloc(10, GFP_KERNEL);
+ if (!cmd)
+ return -ENOMEM;
deb_fe(%s\n,__func__);
- if (m-msg_len 4)
- return -EINVAL;
+ if (m-msg_len 4) {
+ ret = -EINVAL;
+ goto out;
+ }
cmd[1] = SET_DISEQC_CMD;
cmd[2] = m-msg_len;
memcpy(cmd[3], m-msg, m-msg_len);
- cmd[7] = vp702x_chksum(cmd,0,7);
+ cmd[7] = vp702x_chksum(cmd, 0, 7);
- vp702x_usb_inout_op(st-d,cmd,8,ibuf,10,100);
+ vp702x_usb_inout_op(st-d, cmd, 8, cmd, 10, 100);
- if (ibuf[2] == 0 ibuf[3] == 0)
+ if (cmd[2] == 0 cmd[3] == 0)
deb_fe(diseqc cmd failed.\n);
else
deb_fe(diseqc cmd succeeded.\n);
-
- return 0;
+ ret = 0;
+out:
+ kfree(cmd);
+ return ret;
}
static int vp702x_fe_send_diseqc_burst (struct dvb_frontend* fe,
fe_sec_mini_cmd_t burst)
@@ -237,9 +261,14 @@ static int vp702x_fe_send_diseqc_burst (struct
dvb_frontend* fe, fe_sec_mini_cmd
static int vp702x_fe_set_tone(struct dvb_frontend* fe, fe_sec_tone_mode_t tone)
{
struct vp702x_fe_state *st = fe-demodulator_priv;
- u8 ibuf[10];
+ u8 *buf;
+
deb_fe(%s\n,__func__);
+ buf = kmalloc(10, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
st-tone_mode = tone;
if (tone == SEC_TONE_ON)
@@ -247,14 +276,16 @@ static int vp702x_fe_set_tone(struct dvb_frontend* fe,
fe_sec_tone_mode_t tone)
else
st-lnb_buf[2] = 0x00;
- st-lnb_buf[7] = vp702x_chksum(st-lnb_buf,0,7);
+ st-lnb_buf[7] = vp702x_chksum(st-lnb_buf, 0, 7);
+
[PATCH 4/9] [media] vp702x: remove unused variable
struct vp702x_device_state.power_state is nowhere referenced.
Signed-off-by: Florian Mickler flor...@mickler.org
---
drivers/media/dvb/dvb-usb/vp702x.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/vp702x.h
b/drivers/media/dvb/dvb-usb/vp702x.h
index 86960c6..20b9005 100644
--- a/drivers/media/dvb/dvb-usb/vp702x.h
+++ b/drivers/media/dvb/dvb-usb/vp702x.h
@@ -99,7 +99,6 @@ extern int dvb_usb_vp702x_debug;
/* IN i: 0, v: 0, no extra buffer */
struct vp702x_device_state {
- u8 power_state;
struct mutex buf_mutex;
int buf_len;
u8 *buf;
--
1.7.4.1
--
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 7/9] [media] vp702x: use preallocated buffer
Note: This change is tested to compile only as I don't have the
hardware.
Signed-off-by: Florian Mickler flor...@mickler.org
---
drivers/media/dvb/dvb-usb/vp702x.c | 59 +--
1 files changed, 35 insertions(+), 24 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/vp702x.c
b/drivers/media/dvb/dvb-usb/vp702x.c
index c82cb6b..6dd50bc 100644
--- a/drivers/media/dvb/dvb-usb/vp702x.c
+++ b/drivers/media/dvb/dvb-usb/vp702x.c
@@ -140,38 +140,44 @@ static int vp702x_usb_inout_cmd(struct dvb_usb_device *d,
u8 cmd, u8 *o,
static int vp702x_set_pld_mode(struct dvb_usb_adapter *adap, u8 bypass)
{
int ret;
- u8 *buf = kzalloc(16, GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
+ struct vp702x_device_state *st = adap-dev-priv;
+ u8 *buf;
+
+ mutex_lock(st-buf_mutex);
+
+ buf = st-buf;
+ memset(buf, 0, 16);
ret = vp702x_usb_in_op(adap-dev, 0xe0, (bypass 8) | 0x0e,
0, buf, 16);
- kfree(buf);
+ mutex_unlock(st-buf_mutex);
return ret;
}
static int vp702x_set_pld_state(struct dvb_usb_adapter *adap, u8 state)
{
int ret;
- u8 *buf = kzalloc(16, GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
+ struct vp702x_device_state *st = adap-dev-priv;
+ u8 *buf;
+
+ mutex_lock(st-buf_mutex);
+ buf = st-buf;
+ memset(buf, 0, 16);
ret = vp702x_usb_in_op(adap-dev, 0xe0, (state 8) | 0x0f,
0, buf, 16);
- kfree(buf);
+
+ mutex_unlock(st-buf_mutex);
+
return ret;
}
static int vp702x_set_pid(struct dvb_usb_adapter *adap, u16 pid, u8 id, int
onoff)
{
struct vp702x_adapter_state *st = adap-priv;
+ struct vp702x_device_state *dst = adap-dev-priv;
u8 *buf;
- buf = kzalloc(16, GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
-
if (onoff)
st-pid_filter_state |= (1 id);
else {
@@ -182,10 +188,16 @@ static int vp702x_set_pid(struct dvb_usb_adapter *adap,
u16 pid, u8 id, int onof
id = 0x10 + id*2;
vp702x_set_pld_state(adap, st-pid_filter_state);
+
+ mutex_lock(dst-buf_mutex);
+
+ buf = dst-buf;
+ memset(buf, 0, 16);
vp702x_usb_in_op(adap-dev, 0xe0, (((pid 8) 0xff) 8) | (id), 0,
buf, 16);
vp702x_usb_in_op(adap-dev, 0xe0, (((pid ) 0xff) 8) | (id+1),
0, buf, 16);
- kfree(buf);
+ mutex_unlock(dst-buf_mutex);
+
return 0;
}
@@ -193,13 +205,10 @@ static int vp702x_set_pid(struct dvb_usb_adapter *adap,
u16 pid, u8 id, int onof
static int vp702x_init_pid_filter(struct dvb_usb_adapter *adap)
{
struct vp702x_adapter_state *st = adap-priv;
+ struct vp702x_device_state *dst = adap-dev-priv;
int i;
u8 *b;
- b = kzalloc(10, GFP_KERNEL);
- if (!b)
- return -ENOMEM;
-
st-pid_filter_count = 8;
st-pid_filter_can_bypass = 1;
st-pid_filter_state = 0x00;
@@ -209,12 +218,15 @@ static int vp702x_init_pid_filter(struct dvb_usb_adapter
*adap)
for (i = 0; i st-pid_filter_count; i++)
vp702x_set_pid(adap, 0x, i, 1);
+ mutex_lock(dst-buf_mutex);
+ b = dst-buf;
+ memset(b, 0, 10);
vp702x_usb_in_op(adap-dev, 0xb5, 3, 0, b, 10);
vp702x_usb_in_op(adap-dev, 0xb5, 0, 0, b, 10);
vp702x_usb_in_op(adap-dev, 0xb5, 1, 0, b, 10);
+ mutex_unlock(dst-buf_mutex);
+ /*vp702x_set_pld_mode(d, 0); // filter */
- //vp702x_set_pld_mode(d, 0); // filter
- kfree(b);
return 0;
}
@@ -266,16 +278,15 @@ static int vp702x_rc_query(struct dvb_usb_device *d, u32
*event, int *state)
static int vp702x_read_mac_addr(struct dvb_usb_device *d,u8 mac[6])
{
u8 i, *buf;
+ struct vp702x_device_state *st = d-priv;
- buf = kmalloc(6, GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
-
+ mutex_lock(st-buf_mutex);
+ buf = st-buf;
for (i = 6; i 12; i++)
vp702x_usb_in_op(d, READ_EEPROM_REQ, i, 1, buf[i - 6], 1);
memcpy(mac, buf, 6);
- kfree(buf);
+ mutex_unlock(st-buf_mutex);
return 0;
}
--
1.7.4.1
--
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: Leadtek Winfast 1800H FM Tuner
Em 20-03-2011 05:18, Antti Palosaari escreveu: On 03/20/2011 02:56 AM, Andrew Goff wrote: Hi, I hope someone may be able to help me solve a problem or point me in the right direction. I have been using a Leadtek Winfast DTV1800H card (Xceive xc3028 tuner) for a while now without any issues (DTV Radio have been working well), I recently decided to get another tuner card, Leadtek Winfast DTV2000DS (Tuner: NXP TDA18211, but detected as TDA18271 by V4L drivers, Chipset: AF9015 + AF9013 ) and had to compile and install the V4L drivers to get it working. Now DTV on both cards work well but there is a problem with the radio tuner on the 1800H card. After installing the more recent V4L drivers the radio frequency is 2.7MHz out, so if I want to listen to 104.9 I need to tune the radio to 107.6. Now I could just change all my preset stations but I can not listen to my preferred stations as I need to set the frequency above 108MHz. I think there is something wrong with the FM tuner (xc3028?) or other chipset drivers used for DTV1800H. No relations to the af9015, af9013 or tda18271. tda18211 is same chip as tda18271 but only DVB-T included. If DTV1800H does not contain tda18211 or tda18271 problem cannot be either that. Yes, the problem is likely at xc3028. It has to do frequency shift for some DVB standards, and the shift is dependent on what firmware is loaded. So, you need to enable load tuner-xc2028 with debug=1, and provide us the dmesg. 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 2/2] [media] videobuf2-dma-contig: make cookie() return a pointer to dma_addr_t
On Mon, 14 Mar 2011, Pawel Osciak wrote:
dma_addr_t may not fit into void* on some architectures. To be safe, make
vb2_dma_contig_cookie() return a pointer to dma_addr_t and dereference it
in vb2_dma_contig_plane_paddr() back to dma_addr_t.
Signed-off-by: Pawel Osciak pa...@osciak.com
Reported-by: Hans Verkuil hverk...@xs4all.nl
Right, it is correct, that this patch is submitted as 2/2 with
sh_mobile_ceu_camera: Do not call vb2's mem_ops directly being 1/2.
The only slight difficulty is, that this patch should go directly to
Mauro or via some vb2 tree, if one exists, whereas 1/2 I would normally
take via my tree. Hence the question: should I take them both via my tree,
or should I only take 1/2 and we take care to merge this one after it?
Assuming, there are no objections against this one.
Thanks
Guennadi
---
drivers/media/video/videobuf2-dma-contig.c |2 +-
include/media/videobuf2-dma-contig.h |9 ++---
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c
index 90495b7..58205d5 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -78,7 +78,7 @@ static void *vb2_dma_contig_cookie(void *buf_priv)
{
struct vb2_dc_buf *buf = buf_priv;
- return (void *)buf-paddr;
+ return buf-paddr;
}
static void *vb2_dma_contig_vaddr(void *buf_priv)
diff --git a/include/media/videobuf2-dma-contig.h
b/include/media/videobuf2-dma-contig.h
index 1d6188d..7e6c68b 100644
--- a/include/media/videobuf2-dma-contig.h
+++ b/include/media/videobuf2-dma-contig.h
@@ -14,11 +14,14 @@
#define _MEDIA_VIDEOBUF2_DMA_COHERENT_H
#include media/videobuf2-core.h
+#include linux/dma-mapping.h
-static inline unsigned long vb2_dma_contig_plane_paddr(
- struct vb2_buffer *vb, unsigned int plane_no)
+static inline dma_addr_t
+vb2_dma_contig_plane_paddr(struct vb2_buffer *vb, unsigned int plane_no)
{
- return (unsigned long)vb2_plane_cookie(vb, plane_no);
+ dma_addr_t *paddr = vb2_plane_cookie(vb, plane_no);
+
+ return *paddr;
}
void *vb2_dma_contig_init_ctx(struct device *dev);
--
1.7.4.1
---
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: Leadtek Winfast 1800H FM Tuner
On Sun 20-Mar-2011 7:18 PM, Antti Palosaari wrote: On 03/20/2011 02:56 AM, Andrew Goff wrote: Hi, I hope someone may be able to help me solve a problem or point me in the right direction. I have been using a Leadtek Winfast DTV1800H card (Xceive xc3028 tuner) for a while now without any issues (DTV Radio have been working well), I recently decided to get another tuner card, Leadtek Winfast DTV2000DS (Tuner: NXP TDA18211, but detected as TDA18271 by V4L drivers, Chipset: AF9015 + AF9013 ) and had to compile and install the V4L drivers to get it working. Now DTV on both cards work well but there is a problem with the radio tuner on the 1800H card. After installing the more recent V4L drivers the radio frequency is 2.7MHz out, so if I want to listen to 104.9 I need to tune the radio to 107.6. Now I could just change all my preset stations but I can not listen to my preferred stations as I need to set the frequency above 108MHz. I think there is something wrong with the FM tuner (xc3028?) or other chipset drivers used for DTV1800H. No relations to the af9015, af9013 or tda18271. tda18211 is same chip as tda18271 but only DVB-T included. If DTV1800H does not contain tda18211 or tda18271 problem cannot be either that. Antti yes, I suspect it is a problem with the newer drivers for the DTV1800H card. I am using mythbuntu 10.04 as my operating systems and the FM tuner works fine until the the newer V4L drivers installed. The FM tuner frequency is not correct with the new drivers. -- 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] [media] radio: wl128x: Update registration process with ST.
From: Manjunatha Halli manjunatha_ha...@ti.com
As underlying ST driver registration API's have changed this
patch will update the FM driver accordingly.
Signed-off-by: Manjunatha Halli manjunatha_ha...@ti.com
---
drivers/media/radio/wl128x/fmdrv_common.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/media/radio/wl128x/fmdrv_common.c
b/drivers/media/radio/wl128x/fmdrv_common.c
index 96a95c5..b09b283 100644
--- a/drivers/media/radio/wl128x/fmdrv_common.c
+++ b/drivers/media/radio/wl128x/fmdrv_common.c
@@ -1494,12 +1494,17 @@ u32 fmc_prepare(struct fmdev *fmdev)
}
memset(fm_st_proto, 0, sizeof(fm_st_proto));
- fm_st_proto.type = ST_FM;
fm_st_proto.recv = fm_st_receive;
fm_st_proto.match_packet = NULL;
fm_st_proto.reg_complete_cb = fm_st_reg_comp_cb;
fm_st_proto.write = NULL; /* TI ST driver will fill write pointer */
fm_st_proto.priv_data = fmdev;
+ fm_st_proto.chnl_id = 0x08;
+ fm_st_proto.max_frame_size = 0xff;
+ fm_st_proto.hdr_len = 1;
+ fm_st_proto.offset_len_in_hdr = 0;
+ fm_st_proto.len_size = 1;
+ fm_st_proto.reserve = 1;
ret = st_register(fm_st_proto);
if (ret == -EINPROGRESS) {
@@ -1532,7 +1537,7 @@ u32 fmc_prepare(struct fmdev *fmdev)
g_st_write = fm_st_proto.write;
} else {
fmerr(Failed to get ST write func pointer\n);
- ret = st_unregister(ST_FM);
+ ret = st_unregister(fm_st_proto);
if (ret 0)
fmerr(st_unregister failed %d\n, ret);
return -EAGAIN;
@@ -1586,6 +1591,7 @@ u32 fmc_prepare(struct fmdev *fmdev)
*/
u32 fmc_release(struct fmdev *fmdev)
{
+ static struct st_proto_s fm_st_proto;
u32 ret;
if (!test_bit(FM_CORE_READY, fmdev-flag)) {
@@ -1604,7 +1610,11 @@ u32 fmc_release(struct fmdev *fmdev)
fmdev-resp_comp = NULL;
fmdev-rx.freq = 0;
- ret = st_unregister(ST_FM);
+ memset(fm_st_proto, 0, sizeof(fm_st_proto));
+ fm_st_proto.chnl_id = 0x08;
+
+ ret = st_unregister(fm_st_proto);
+
if (ret 0)
fmerr(Failed to de-register FM from ST %d\n, ret);
else
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] [media] radio: wl128x: Fix printk format warning
From: Manjunatha Halli manjunatha_ha...@ti.com
Signed-off-by: Manjunatha Halli manjunatha_ha...@ti.com
Signed-off-by: Randy Dunlap randy.dun...@oracle.com
---
drivers/media/radio/wl128x/fmdrv_common.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/radio/wl128x/fmdrv_common.c
b/drivers/media/radio/wl128x/fmdrv_common.c
index 12f4c65..96a95c5 100644
--- a/drivers/media/radio/wl128x/fmdrv_common.c
+++ b/drivers/media/radio/wl128x/fmdrv_common.c
@@ -272,7 +272,7 @@ static void recv_tasklet(unsigned long arg)
while ((skb = skb_dequeue(fmdev-rx_q))) {
if (skb-len sizeof(struct fm_event_msg_hdr)) {
fmerr(skb(%p) has only %d bytes
- atleast need %d bytes to decode\n, skb,
+ need at least %zd bytes to decode\n, skb,
skb-len, sizeof(struct fm_event_msg_hdr));
kfree_skb(skb);
continue;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/3] tea575x-tuner: various improvements
At Sat, 19 Mar 2011 16:32:53 +0100,
Ondrej Zary wrote:
Improve tea575x-tuner with various good things from radio-maestro:
- extend frequency range to 50-150MHz
- fix querycap(): card name, CAP_RADIO
- improve g_tuner(): CAP_STEREO, stereo and tuned indication
- improve g_frequency(): tuner index checking and reading frequency from HW
- improve s_frequency(): tuner index and type checking
Signed-off-by: Ondrej Zary li...@rainbow-software.org
Applied these 3 patches now to topic/misc branch of sound git tree
(i.e. for 2.6.40 kernel).
I leave the removal of radio-maestro to v4l guys, as this is fairly
independent.
thanks,
Takashi
--- linux-2.6.38-rc4-orig/sound/i2c/other/tea575x-tuner.c 2011-02-08
01:03:55.0 +0100
+++ linux-2.6.38-rc4/sound/i2c/other/tea575x-tuner.c 2011-03-19
15:40:14.0 +0100
@@ -37,8 +37,8 @@ static int radio_nr = -1;
module_param(radio_nr, int, 0);
#define RADIO_VERSION KERNEL_VERSION(0, 0, 2)
-#define FREQ_LO (87 * 16000)
-#define FREQ_HI (108 * 16000)
+#define FREQ_LO (50UL * 16000)
+#define FREQ_HI (150UL * 16000)
/*
* definitions
@@ -77,15 +77,29 @@ static struct v4l2_queryctrl radio_qctrl
* lowlevel part
*/
+static void snd_tea575x_get_freq(struct snd_tea575x *tea)
+{
+ unsigned long freq;
+
+ freq = tea-ops-read(tea) TEA575X_BIT_FREQ_MASK;
+ /* freq *= 12.5 */
+ freq *= 125;
+ freq /= 10;
+ /* crystal fixup */
+ if (tea-tea5759)
+ freq += tea-freq_fixup;
+ else
+ freq -= tea-freq_fixup;
+
+ tea-freq = freq * 16; /* from kHz */
+}
+
static void snd_tea575x_set_freq(struct snd_tea575x *tea)
{
unsigned long freq;
- freq = tea-freq / 16; /* to kHz */
- if (freq 108000)
- freq = 108000;
- if (freq 87000)
- freq = 87000;
+ freq = clamp(tea-freq, FREQ_LO, FREQ_HI);
+ freq /= 16; /* to kHz */
/* crystal fixup */
if (tea-tea5759)
freq -= tea-freq_fixup;
@@ -109,29 +123,33 @@ static int vidioc_querycap(struct file *
{
struct snd_tea575x *tea = video_drvdata(file);
- strcpy(v-card, tea-tea5759 ? TEA5759 : TEA5757);
strlcpy(v-driver, tea575x-tuner, sizeof(v-driver));
- strlcpy(v-card, Maestro Radio, sizeof(v-card));
+ strlcpy(v-card, tea-tea5759 ? TEA5759 : TEA5757, sizeof(v-card));
sprintf(v-bus_info, PCI);
v-version = RADIO_VERSION;
- v-capabilities = V4L2_CAP_TUNER;
+ v-capabilities = V4L2_CAP_TUNER | V4L2_CAP_RADIO;
return 0;
}
static int vidioc_g_tuner(struct file *file, void *priv,
struct v4l2_tuner *v)
{
+ struct snd_tea575x *tea = video_drvdata(file);
+
if (v-index 0)
return -EINVAL;
+ tea-ops-read(tea);
+
strcpy(v-name, FM);
v-type = V4L2_TUNER_RADIO;
+ v-capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO;
v-rangelow = FREQ_LO;
v-rangehigh = FREQ_HI;
- v-rxsubchans = V4L2_TUNER_SUB_MONO|V4L2_TUNER_SUB_STEREO;
- v-capability = V4L2_TUNER_CAP_LOW;
- v-audmode = V4L2_TUNER_MODE_MONO;
- v-signal = 0x;
+ v-rxsubchans = V4L2_TUNER_SUB_MONO | V4L2_TUNER_SUB_STEREO;
+ v-audmode = tea-stereo ? V4L2_TUNER_MODE_STEREO :
V4L2_TUNER_MODE_MONO;
+ v-signal = tea-tuned ? 0x : 0;
+
return 0;
}
@@ -148,7 +166,10 @@ static int vidioc_g_frequency(struct fil
{
struct snd_tea575x *tea = video_drvdata(file);
+ if (f-tuner != 0)
+ return -EINVAL;
f-type = V4L2_TUNER_RADIO;
+ snd_tea575x_get_freq(tea);
f-frequency = tea-freq;
return 0;
}
@@ -158,6 +179,9 @@ static int vidioc_s_frequency(struct fil
{
struct snd_tea575x *tea = video_drvdata(file);
+ if (f-tuner != 0 || f-type != V4L2_TUNER_RADIO)
+ return -EINVAL;
+
if (f-frequency FREQ_LO || f-frequency FREQ_HI)
return -EINVAL;
--- linux-2.6.38-rc4-orig/include/sound/tea575x-tuner.h 2011-02-08
01:03:55.0 +0100
+++ linux-2.6.38-rc4/include/sound/tea575x-tuner.h2011-03-19
14:18:06.0 +0100
@@ -38,8 +38,10 @@ struct snd_tea575x {
struct snd_card *card;
struct video_device *vd;/* video device */
int dev_nr; /* requested device number + 1 */
- int tea5759;/* 5759 chip is present */
- int mute; /* Device is muted? */
+ bool tea5759; /* 5759 chip is present */
+ bool mute; /* Device is muted? */
+ bool stereo;/* receiving stereo */
+ bool tuned; /* tuned to a station */
unsigned int freq_fixup;/* crystal onboard */
unsigned int val;
Re: [PATCH 3/3] ARM: switch mackerel to dynamically manage the platform camera
Hi Magnus
On Wed, 16 Mar 2011, Magnus Damm wrote:
On Tue, Feb 22, 2011 at 6:57 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
Use soc_camera_platform helper functions to dynamically manage the
camera device.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
arch/arm/mach-shmobile/board-mackerel.c | 28 +++-
1 files changed, 7 insertions(+), 21 deletions(-)
Hi Guennadi,
Thanks for your work on this. The soc_camera_platform interface has
become much much nicer with these patches.
I just tested patch 1/3 and patch 3/3 on my Mackerel board.
Thanks for testing!
Unfortunately I get this printout on the console:
sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver attached to camera 0
soc_camera_platform soc_camera_platform.0: Platform has not set
soc_camera_device pointer!
soc_camera_platform: probe of soc_camera_platform.0 failed with error -22
sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver detached from camera 0
Without these two patches everything work just fine. Any ideas on how
to fix it? I'd be happy to test V2. =)
Hm, yes, looks like I'm initialising the pointer too late. Could you,
please, test the patch below on top, if it helps, I'll send v2.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
diff --git a/include/media/soc_camera_platform.h
b/include/media/soc_camera_platform.h
index fbf4b79..6d7a4fd 100644
--- a/include/media/soc_camera_platform.h
+++ b/include/media/soc_camera_platform.h
@@ -50,6 +50,8 @@ static inline int soc_camera_platform_add(const struct
soc_camera_link *icl,
if (!*pdev)
return -ENOMEM;
+ info-dev = dev;
+
(*pdev)-dev.platform_data = info;
(*pdev)-dev.release = release;
@@ -57,11 +59,10 @@ static inline int soc_camera_platform_add(const struct
soc_camera_link *icl,
if (ret 0) {
platform_device_put(*pdev);
*pdev = NULL;
- } else {
- info-dev = dev;
+ info-dev = NULL;
}
- return 0;
+ return ret;
}
static inline void soc_camera_platform_del(const struct soc_camera_link *icl,
--
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/2] [media] videobuf2-dma-contig: make cookie() return a pointer to dma_addr_t
Hi Guennadi, On Mon, Mar 21, 2011 at 03:47, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Mon, 14 Mar 2011, Pawel Osciak wrote: dma_addr_t may not fit into void* on some architectures. To be safe, make vb2_dma_contig_cookie() return a pointer to dma_addr_t and dereference it in vb2_dma_contig_plane_paddr() back to dma_addr_t. Signed-off-by: Pawel Osciak pa...@osciak.com Reported-by: Hans Verkuil hverk...@xs4all.nl Right, it is correct, that this patch is submitted as 2/2 with sh_mobile_ceu_camera: Do not call vb2's mem_ops directly being 1/2. The only slight difficulty is, that this patch should go directly to Mauro or via some vb2 tree, if one exists, whereas 1/2 I would normally take via my tree. Hence the question: should I take them both via my tree, or should I only take 1/2 and we take care to merge this one after it? Assuming, there are no objections against this one. I attached 2/2 for reference, please take 1/2 and I will take care to ask Mauro to pull 2/2, unless you prefer to pull both. Thanks, -- Pawel Osciak -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] use pci_dev-revision
pci_setup_device() has saved the PCI revision in the pci_dev
struct since Linux 2.6.23. Use it.
Cc: Auke Kok auke-jan.h@intel.com
Signed-off-by: Bjørn Mork bj...@mork.no
---
I assume some of these drivers could have the revision
removed from their driver specific structures as well, but
I haven't done that to avoid unnecessary ABI changes.
drivers/media/common/saa7146_core.c|7 +--
drivers/media/dvb/b2c2/flexcop-pci.c |4 +---
drivers/media/dvb/bt8xx/bt878.c|2 +-
drivers/media/dvb/mantis/mantis_pci.c |5 ++---
drivers/media/video/bt8xx/bttv-driver.c|2 +-
drivers/media/video/cx18/cx18-driver.c |2 +-
drivers/media/video/cx23885/cx23885-core.c |2 +-
drivers/media/video/cx88/cx88-mpeg.c |2 +-
drivers/media/video/cx88/cx88-video.c |2 +-
drivers/media/video/ivtv/ivtv-driver.c |4 +---
drivers/media/video/saa7134/saa7134-core.c |2 +-
drivers/media/video/saa7164/saa7164-core.c |2 +-
drivers/media/video/zoran/zoran_card.c |2 +-
13 files changed, 14 insertions(+), 24 deletions(-)
diff --git a/drivers/media/common/saa7146_core.c
b/drivers/media/common/saa7146_core.c
index 9f47e38..9af2140 100644
--- a/drivers/media/common/saa7146_core.c
+++ b/drivers/media/common/saa7146_core.c
@@ -378,12 +378,7 @@ static int saa7146_init_one(struct pci_dev *pci, const
struct pci_device_id *ent
dev-pci = pci;
/* get chip-revision; this is needed to enable bug-fixes */
- err = pci_read_config_dword(pci, PCI_CLASS_REVISION, dev-revision);
- if (err 0) {
- ERR((pci_read_config_dword() failed.\n));
- goto err_disable;
- }
- dev-revision = 0xf;
+ dev-revision = pci-revision;
/* remap the memory from virtual to physical address */
diff --git a/drivers/media/dvb/b2c2/flexcop-pci.c
b/drivers/media/dvb/b2c2/flexcop-pci.c
index 227c020..326d2e8 100644
--- a/drivers/media/dvb/b2c2/flexcop-pci.c
+++ b/drivers/media/dvb/b2c2/flexcop-pci.c
@@ -290,10 +290,8 @@ static void flexcop_pci_dma_exit(struct flexcop_pci
*fc_pci)
static int flexcop_pci_init(struct flexcop_pci *fc_pci)
{
int ret;
- u8 card_rev;
- pci_read_config_byte(fc_pci-pdev, PCI_CLASS_REVISION, card_rev);
- info(card revision %x, card_rev);
+ info(card revision %x, fc_pci-pdev-revision);
if ((ret = pci_enable_device(fc_pci-pdev)) != 0)
return ret;
diff --git a/drivers/media/dvb/bt8xx/bt878.c b/drivers/media/dvb/bt8xx/bt878.c
index 99d6209..b34fa95 100644
--- a/drivers/media/dvb/bt8xx/bt878.c
+++ b/drivers/media/dvb/bt8xx/bt878.c
@@ -460,7 +460,7 @@ static int __devinit bt878_probe(struct pci_dev *dev,
goto fail0;
}
- pci_read_config_byte(dev, PCI_CLASS_REVISION, bt-revision);
+ bt-revision = dev-revision;
pci_read_config_byte(dev, PCI_LATENCY_TIMER, lat);
diff --git a/drivers/media/dvb/mantis/mantis_pci.c
b/drivers/media/dvb/mantis/mantis_pci.c
index 10a432a..371558a 100644
--- a/drivers/media/dvb/mantis/mantis_pci.c
+++ b/drivers/media/dvb/mantis/mantis_pci.c
@@ -48,7 +48,7 @@
int __devinit mantis_pci_init(struct mantis_pci *mantis)
{
- u8 revision, latency;
+ u8 latency;
struct mantis_hwconfig *config = mantis-hwconfig;
struct pci_dev *pdev= mantis-pdev;
int err, ret = 0;
@@ -95,9 +95,8 @@ int __devinit mantis_pci_init(struct mantis_pci *mantis)
}
pci_read_config_byte(pdev, PCI_LATENCY_TIMER, latency);
- pci_read_config_byte(pdev, PCI_CLASS_REVISION, revision);
mantis-latency = latency;
- mantis-revision = revision;
+ mantis-revision = pdev-revision;
dprintk(MANTIS_ERROR, 0, Mantis Rev %d [%04x:%04x], ,
mantis-revision,
diff --git a/drivers/media/video/bt8xx/bttv-driver.c
b/drivers/media/video/bt8xx/bttv-driver.c
index 91399c9..a97cf27 100644
--- a/drivers/media/video/bt8xx/bttv-driver.c
+++ b/drivers/media/video/bt8xx/bttv-driver.c
@@ -4303,7 +4303,7 @@ static int __devinit bttv_probe(struct pci_dev *dev,
goto fail0;
}
- pci_read_config_byte(dev, PCI_CLASS_REVISION, btv-revision);
+ btv-revision = dev-revision;
pci_read_config_byte(dev, PCI_LATENCY_TIMER, lat);
printk(KERN_INFO bttv%d: Bt%d (rev %d) at %s, ,
bttv_num,btv-id, btv-revision, pci_name(dev));
diff --git a/drivers/media/video/cx18/cx18-driver.c
b/drivers/media/video/cx18/cx18-driver.c
index b1c3cbd..9d7f8f2 100644
--- a/drivers/media/video/cx18/cx18-driver.c
+++ b/drivers/media/video/cx18/cx18-driver.c
@@ -810,7 +810,7 @@ static int cx18_setup_pci(struct cx18 *cx, struct pci_dev
*pci_dev,
cmd |= PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER;
pci_write_config_word(pci_dev, PCI_COMMAND, cmd);
- pci_read_config_byte(pci_dev, PCI_CLASS_REVISION, cx-card_rev);
+ cx-card_rev =
Re: V4L2_CAP_VIDEO_OUTPUT and videobuf[1/2] adv7175 mediabus
Hi Christian On Thu, 24 Feb 2011, Christian Gmeiner wrote: Hi all, I jumped into the cold water and I am trying to convert the dxr3/em8300 driver to the v4l2 api. I got some parts already working, but I think that the hardest parts are still missing. As you might think... yes I have some questions :) 1) The dxr3 has a hardware fifo, which is used to play content. Can I reuse videbuf1 or videbuf2 to manage the fifo? Are these the frameworks designed to support output devices - write operation to the device? Yes, videobuf* APIs are used for both input and output. I don't think you would be able to use videobuf1 for your set up, and you shouldn't anyway. As for videobuf2 - not sure... Are those hardware buffers purely internal to the hardware or can they also be directly accessed by the CPU as normal RAM? Even if it is possible in principle, using videobuf2, you would, probably, have to write your own memory-allocator. I'm sure others on this list can give a more qualified answer to this question;-) Here you can find the current fifo impl. https://github.com/austriancoder/v4l2-em8300/blob/master/modules/em8300_fifo.c 2) The adv7175 chip support to different input data types: Video Input Data Port Supports: CCIR-656 4:2:2 8-Bit Parallel Input Format 4:2:2 16-Bit Parallel Input Format See http://dxr3.sourceforge.net/download/hardware/ADV7175A_6A.pdf for more details about the chip. Now I thought that I should use the v4l2-mediabus api for that, but I am not sure what pixel codes (V4L2_MBUS_FMT...) should be used for CCIR-656 4:2:2 8-Bit and CCIR-656 4:2:2 16-Bit. Yes, you should use mediabus formats, and no, these formats are not defined yet. Please, propose a patch with these two new formats. 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: V4L2_CAP_VIDEO_OUTPUT and videobuf[1/2] adv7175 mediabus
On Monday, March 21, 2011 17:49:24 Guennadi Liakhovetski wrote: Hi Christian On Thu, 24 Feb 2011, Christian Gmeiner wrote: Hi all, I jumped into the cold water and I am trying to convert the dxr3/em8300 driver to the v4l2 api. I got some parts already working, but I think that the hardest parts are still missing. As you might think... yes I have some questions :) 1) The dxr3 has a hardware fifo, which is used to play content. Can I reuse videbuf1 or videbuf2 to manage the fifo? Are these the frameworks designed to support output devices - write operation to the device? Yes, videobuf* APIs are used for both input and output. I don't think you would be able to use videobuf1 for your set up, and you shouldn't anyway. As for videobuf2 - not sure... Are those hardware buffers purely internal to the hardware or can they also be directly accessed by the CPU as normal RAM? Even if it is possible in principle, using videobuf2, you would, probably, have to write your own memory-allocator. I'm sure others on this list can give a more qualified answer to this question;-) vb2 should definitely be a good fit for this. That said, be aware that it is quite new, so if you run into problems don't hesitate to ask on the list just in case we overlooked something. Also useful to know is that work will need to be done on the decoding API. The ivtv driver does decoding as well. However, it uses a DVB API for that (include/linux/dvb/video.h and audio.h). In hindsight this was a bad idea and instead a proper V4L2 API should be created. This can be based on the those headers. I can help with that, time permitting. Regards, Hans Here you can find the current fifo impl. https://github.com/austriancoder/v4l2-em8300/blob/master/modules/em8300_fifo.c 2) The adv7175 chip support to different input data types: Video Input Data Port Supports: CCIR-656 4:2:2 8-Bit Parallel Input Format 4:2:2 16-Bit Parallel Input Format See http://dxr3.sourceforge.net/download/hardware/ADV7175A_6A.pdf for more details about the chip. Now I thought that I should use the v4l2-mediabus api for that, but I am not sure what pixel codes (V4L2_MBUS_FMT...) should be used for CCIR-656 4:2:2 8-Bit and CCIR-656 4:2:2 16-Bit. Yes, you should use mediabus formats, and no, these formats are not defined yet. Please, propose a patch with these two new formats. 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 -- 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
Re: Prof_Revolution_DVB-S2_8000_PCI-E Linux Kernel 2.6.38-rc8-next-20110314
W dniu 20.03.2011 20:32, Wojciech Myrda pisze: Hi all, I have purchased Prof_Revolution_DVB-S2_8000_PCI-E which is listed on the wiki http://linuxtv.org/wiki/index.php/Prof_Revolution_DVB-S2_8000_PCI-E as not yet suppoorted, however I found out there is some work ongoing on the driver for that card as the producer make the folowing patch http://www.proftuners.com/sites/default/files/prof8000_0.patch available on their website http://www.prof-tuners.pl/download8000.html This patch would not apply agaist the recent Linux Kernel 2.6.38-rc8-next-20110314 so I did a few quick fixes that moved few lines (patch in the attachment). Now that it all applies like it should it fails with the following error CC [M] kernel/configs.o CC [M] drivers/media/video/cx23885/cx23885-cards.o CC [M] drivers/media/video/cx23885/cx23885-video.o CC [M] drivers/media/video/cx23885/cx23885-vbi.o CC [M] drivers/media/video/cx23885/cx23885-core.o drivers/media/video/cx23885/altera-ci.h:71:12: warning: ‘altera_ci_tuner_reset’ defined but not used [-Wunused-function] CC [M] drivers/media/video/cx23885/cx23885-i2c.o CC [M] drivers/media/video/cx23885/cx23885-dvb.o drivers/media/video/cx23885/cx23885-dvb.c:505:15: error: variable ‘prof_8000_stb6100_config’ has initializer but incomplete type drivers/media/video/cx23885/cx23885-dvb.c:506:2: error: unknown field ‘tuner_address’ specified in initializer drivers/media/video/cx23885/cx23885-dvb.c:506:2: warning: excess elements in struct initializer [enabled by default] drivers/media/video/cx23885/cx23885-dvb.c:506:2: warning: (near initialization for ‘prof_8000_stb6100_config’) [enabled by default] drivers/media/video/cx23885/cx23885-dvb.c:507:2: error: unknown field ‘refclock’ specified in initializer drivers/media/video/cx23885/cx23885-dvb.c:507:2: warning: excess elements in struct initializer [enabled by default] drivers/media/video/cx23885/cx23885-dvb.c:507:2: warning: (near initialization for ‘prof_8000_stb6100_config’) [enabled by default] drivers/media/video/cx23885/cx23885-dvb.c: In function ‘dvb_register’: drivers/media/video/cx23885/cx23885-dvb.c:1134:8: error: ‘stb6100_attach’ undeclared (first use in this function) drivers/media/video/cx23885/cx23885-dvb.c:1134:8: note: each undeclared identifier is reported only once for each function it appears in drivers/media/video/cx23885/cx23885-dvb.c:1134:8: error: called object ‘__a’ is not a function drivers/media/video/cx23885/cx23885-dvb.c:1138:32: error: ‘stb6100_set_freq’ undeclared (first use in this function) drivers/media/video/cx23885/cx23885-dvb.c:1139:32: error: ‘stb6100_get_freq’ undeclared (first use in this function) drivers/media/video/cx23885/cx23885-dvb.c:1140:32: error: ‘stb6100_set_bandw’ undeclared (first use in this function) drivers/media/video/cx23885/cx23885-dvb.c:1141:32: error: ‘stb6100_get_bandw’ undeclared (first use in this function) drivers/media/video/cx23885/cx23885-dvb.c: At top level: drivers/media/video/cx23885/altera-ci.h:71:12: warning: ‘altera_ci_tuner_reset’ defined but not used [-Wunused-function] make[4]: *** [drivers/media/video/cx23885/cx23885-dvb.o] Error 1 make[3]: *** [drivers/media/video/cx23885] Error 2 make[2]: *** [drivers/media/video] Error 2 make[1]: *** [drivers/media] Error 2 make: *** [drivers] Error 2 Please help in making it work as my Kung Fu ends here Regards, Wojciech It turns ot that revised patch not only applies cleanly but compiles as well agaist Linux Kernel 2.6.38-rc8-next-20110321. Looking at dmesg everything is recognized properly as well. Do you guys think if it is possible to include it into the tree? mediapc linux-2.6.38 # cat ../dvb/prof8000_1.patch |patch -E -p2 (Stripping trailing CRs from patch.) patching file drivers/media/video/cx23885/cx23885-cards.c Hunk #1 succeeded at 183 (offset 14 lines). Hunk #2 succeeded at 445 (offset 53 lines). Hunk #3 succeeded at 932 (offset 111 lines). Hunk #4 succeeded at 1297 (offset 245 lines). (Stripping trailing CRs from patch.) patching file drivers/media/video/cx23885/cx23885-dvb.c Hunk #1 succeeded at 46 (offset -1 lines). (Stripping trailing CRs from patch.) patching file drivers/media/video/cx23885/cx23885.h mediapc linux-2.6.38 # make CHK include/linux/version.h CHK include/generated/utsrelease.h CALLscripts/checksyscalls.sh CHK include/generated/compile.h CC [M] drivers/media/video/cx23885/cx23885-cards.o CC [M] drivers/media/video/cx23885/cx23885-video.o CC [M] drivers/media/video/cx23885/cx23885-vbi.o CC [M] drivers/media/video/cx23885/cx23885-core.o drivers/media/video/cx23885/altera-ci.h:71:12: warning: ‘altera_ci_tuner_reset’ defined but not used [-Wunused-function] CC [M] drivers/media/video/cx23885/cx23885-i2c.o CC [M] drivers/media/video/cx23885/cx23885-dvb.o drivers/media/video/cx23885/altera-ci.h:71:12: warning: ‘altera_ci_tuner_reset’ defined but not used [-Wunused-function
Re: Demande de support V4L2
Hi Loïc, On Friday 18 March 2011 16:43:40 Loïc Akue wrote: Hi, Do you know if Gstreamer or Mplayer are able to capture some vidéo from the CCDC output? I've been trying with the v4l2src plugin but Gstreamer can negociate format. I haven't tried mplayer or v4l2src with the OAMP3 ISP, sorry. -- 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: Leadtek Winfast 1800H FM Tuner
Em 21-03-2011 08:35, Andrew Goff escreveu: On Mon 21-Mar-2011 9:21 PM, Mauro Carvalho Chehab wrote: Em 20-03-2011 05:18, Antti Palosaari escreveu: On 03/20/2011 02:56 AM, Andrew Goff wrote: Hi, I hope someone may be able to help me solve a problem or point me in the right direction. I have been using a Leadtek Winfast DTV1800H card (Xceive xc3028 tuner) for a while now without any issues (DTV Radio have been working well), I recently decided to get another tuner card, Leadtek Winfast DTV2000DS (Tuner: NXP TDA18211, but detected as TDA18271 by V4L drivers, Chipset: AF9015 + AF9013 ) and had to compile and install the V4L drivers to get it working. Now DTV on both cards work well but there is a problem with the radio tuner on the 1800H card. After installing the more recent V4L drivers the radio frequency is 2.7MHz out, so if I want to listen to 104.9 I need to tune the radio to 107.6. Now I could just change all my preset stations but I can not listen to my preferred stations as I need to set the frequency above 108MHz. I think there is something wrong with the FM tuner (xc3028?) or other chipset drivers used for DTV1800H. No relations to the af9015, af9013 or tda18271. tda18211 is same chip as tda18271 but only DVB-T included. If DTV1800H does not contain tda18211 or tda18271 problem cannot be either that. Yes, the problem is likely at xc3028. It has to do frequency shift for some DVB standards, and the shift is dependent on what firmware is loaded. So, you need to enable load tuner-xc2028 with debug=1, and provide us the dmesg. Mauro. Hi Mauro To do this do I just add the line options tuner-xc2028 debug=1 to the /etc/modules file. From my current dmesg file looks like the firmware is version 2.7. xc2028 1-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 There are about 60 firmwares that are grouped inside xc3028-v27.fw. Please post the complete dmesg. We also need to know what version of the driver you were using when the driver used to work and what you're using when it broke. Thanks 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
Report of the Warsaw Brainstorming Meeting
This is my report of the three day brainstorming meeting in Warsaw, Poland,
March 16-18.
Attendees:
Samsung Poland RD Center:
Kamil Debski k.deb...@samsung.com
Sylwester Nawrocki s.nawro...@samsung.com
Tomasz Stanislawski t.stanisl...@samsung.com
Marek Szyprowski (Organizer) m.szyprow...@samsung.com
Cisco Systems Norway:
Martin Bugge marbu...@cisco.com
Hans Verkuil (Chair) hverk...@xs4all.nl
Nokia:
Sakari Ailus sakari.ai...@maxwell.research.nokia.com
Ideas On Board:
Laurent Pinchart laurent.pinch...@ideasonboard.com
ST-Ericsson:
Willy Poisson willy.pois...@stericsson.com
Samsung System.LSI Korea
Jonghun Han jonghun@samsung.com
Jaeryul Oh jaeryul...@samsung.com
Samsung DMC Korea:
Seung-Woo Kim sw0312@samsung.com
Freelance:
Guennadi Liakhovetski g.liakhovet...@gmx.de
All presentations, photos and notes are available here:
http://www.retiisi.org.uk/v4l2/v4l2-brainstorming-warsaw-2011-03
This report is based on the etherpad notes. See the URL above for the raw
notes.
I hope I haven't forgotten anything, but I believe I've covered pretty much
everything relevant.
1) Compressed format API for MPEG, H.264, etc.
The current API was developed for multiplexed MPEG transport and program streams
and it was not entirely clear how new formats like H.264 should be incorporated.
Right now V4L2_PIX_FMT_MPEG can be used for any multiplexed stream and the
STREAM_TYPE/AUDIO_ENCODER/VIDEO_ENCODER controls are used to discover the
precise
format of the multiplexed stream and the used audio and video encoders.
This scheme breaks down for elementary streams. After discussing this we came to
the conclusion that the current scheme should be used for multiplexed streams,
while elementary streams should get their own pixel format. In that case the
controls mentioned above would not exist.
We would need new pixel formats for elementary streams:
V4L2_PIX_FMT_MPEG1
V4L2_PIX_FMT_MPEG2
V4L2_PIX_FMT_MPEG4
V4L2_PIX_FMT_H264 (H.264 using start codes for the 'Network Abstraction Layer
Units (NALU)')
V4L2_PIX_FMT_AVC1 (H.264 without start codes for the NALUs)
DivX formats also need FourCCs. The DivX specification is proprietary, we don't
know how the different DivX formats differ ('DIV3', 'DIV4, 'DIVX', 'DX50',
'XVID', ...). More information is needed there.
VC1 comes in two flavors, VC1 (containerless) and VC1 RCV (VC-1 inside and RCV
container). More information is needed on the VC1 RCV format: should we consider
this as a multiplexed stream or as an elementary stream? Could be similiar to
H264
and AVC1 as described above.
ACTION: Kamil will propose new fourcc's.
The V4L2 spec already includes a codec class, but it's mostly an unused stub.
The V4L2 codec definition is very similar to V4L2 M2M devices. V4L2 also defines
an effect device interface. The codec and effect device interfaces should be
merged in the spec and be replaced by a M2M interface section.
ACTION: Kamil will make a small RFC for this.
M2M devices currently have both capture and output V4L2 capabilities set, so
they
show up as capture devices in applications. This could be fixed by skipping (at
the
application level) devices that have both capabilities sets. But this doesn't
work
for devices that can do both memory-to-memory processing and live capture (such
as
the OMAP3 ISP) depending on the link configuration.
We probably need a new capability flag for M2M devices.
ACTION: Hans will look into this as this is also needed to suppress the core
handling of VIDIOC_G/S_PRIORITY for M2M devices.
For the newer codecs new controls will be needed to set the various parameters.
Besides the Samsung hardware it might also be useful to look at the SuperH /
sh-mobile
compressed video processing library to get an idea about video processing
parameters,
available on different types of hardware:
https://oss.renesas.com/modules/document/?libshcodecs
A V4L2_CTRL_CLASS_CODEC class was proposed. But the existing MPEG class should
be
used instead even though the name is misleading. We should consider creating
aliases
that replace MPEG with CODEC.
Vendor-specific controls will be defined as vendor controls and can later be
standardized if needed. Whether the vendor control can then be removed is a
gray area.
Some controls shared by different codecs can have different min/max values. For
instance,
the QP range is 0..51 for H.264 and 1..31 for MPEG4/H.263. Should we use two
different
controls, or a single one? When switching between codecs, min/max changes can
be reported
to userspace through a V4L2 control event, so a single control can work. Hans
would rather
see separate controls if there's only a couple of such controls.
ACTION: Kamil will make a list of controls and send it to linux-media.
A special case is UVC and the 'H.264 inside MJPEG' format. See:
http://www.quickcamteam.net/uvc-h264/USB_Video_Payload_H.264_0.87.pdf
Introduced to overcome hardware limitation (lack of 5th usb endpoint in the
chip),
Re: Yet another memory provider: can linaro organize a meeting?
On Wednesday, March 16, 2011 09:14:54 Kyungmin Park wrote: Rough schedules. 1. Warsaw meetings (3/16~3/18): mostly v4l2 person and some SoC vendors Make a consensence at media developers. and share the information. Please note that it's v4l2 brainstorming meeting. so memory management is not the main issue. I have asked all participants to the meeting to try and assemble requirements for their hardware in the next week. 2. ELC (4/11~4/13): DRM, DRI and v4l2 person. Discuss GEM/TTM is acceptable for non-X86 system and find out the which modules are acceptable. We studied the GEM for our environment. but it's too huge and not much benefit for us since current frameworks are enough. The missing is that no generic memory passing mechanism. We need the generic memory passing interface. that's all. Who will be there? Is there a BoF or something similar organized? 3. Linaro (5/9~5/13): ARM, SoC vendors and v4l2 persons. I hope several person are anticipated and made a small step for final goal. I should be able to join, at least for the part related to buffer pools and related topics. Regards, Hans -- 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
[PATCH 1/6] [media] a800: get rid of on-stack dma buffers
usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.
In lib/dma_debug.c the function check_for_stack even warns about it:
WARNING: at lib/dma-debug.c:866 check_for_stack
Note: This change is tested to compile only, as I don't have the hardware.
Signed-off-by: Florian Mickler flor...@mickler.org
---
drivers/media/dvb/dvb-usb/a800.c | 17 +
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/a800.c b/drivers/media/dvb/dvb-usb/a800.c
index 53b93a4..fe2366b 100644
--- a/drivers/media/dvb/dvb-usb/a800.c
+++ b/drivers/media/dvb/dvb-usb/a800.c
@@ -78,17 +78,26 @@ static struct rc_map_table rc_map_a800_table[] = {
static int a800_rc_query(struct dvb_usb_device *d, u32 *event, int *state)
{
- u8 key[5];
+ int ret;
+ u8 *key = kmalloc(5, GFP_KERNEL);
+ if (!key)
+ return -ENOMEM;
+
if (usb_control_msg(d-udev,usb_rcvctrlpipe(d-udev,0),
0x04, USB_TYPE_VENDOR | USB_DIR_IN, 0, 0, key,
5,
- 2000) != 5)
- return -ENODEV;
+ 2000) != 5) {
+ ret = -ENODEV;
+ goto out;
+ }
/* call the universal NEC remote processor, to find out the key's state
and event */
dvb_usb_nec_rc_key_to_event(d,key,event,state);
if (key[0] != 0)
deb_rc(key: %x %x %x %x
%x\n,key[0],key[1],key[2],key[3],key[4]);
- return 0;
+ ret = 0;
+out:
+ kfree(key);
+ return ret;
}
/* USB Driver stuff */
--
1.7.4.1
--
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 4/6] [media] dw2102: get rid of on-stack dma buffer
usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.
In lib/dma_debug.c the function check_for_stack even warns about it:
WARNING: at lib/dma-debug.c:866 check_for_stack
Note: This change is tested to compile only, as I don't have the hardware.
Signed-off-by: Florian Mickler flor...@mickler.org
---
drivers/media/dvb/dvb-usb/dw2102.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dw2102.c
b/drivers/media/dvb/dvb-usb/dw2102.c
index 2c307ba..4c8ff39 100644
--- a/drivers/media/dvb/dvb-usb/dw2102.c
+++ b/drivers/media/dvb/dvb-usb/dw2102.c
@@ -101,12 +101,16 @@ static int dw210x_op_rw(struct usb_device *dev, u8
request, u16 value,
u16 index, u8 * data, u16 len, int flags)
{
int ret;
- u8 u8buf[len];
-
+ u8 *u8buf;
unsigned int pipe = (flags == DW210X_READ_MSG) ?
usb_rcvctrlpipe(dev, 0) : usb_sndctrlpipe(dev,
0);
u8 request_type = (flags == DW210X_READ_MSG) ? USB_DIR_IN : USB_DIR_OUT;
+ u8buf = kmalloc(len, GFP_KERNEL);
+ if (!u8buf)
+ return -ENOMEM;
+
+
if (flags == DW210X_WRITE_MSG)
memcpy(u8buf, data, len);
ret = usb_control_msg(dev, pipe, request, request_type |
USB_TYPE_VENDOR,
@@ -114,6 +118,8 @@ static int dw210x_op_rw(struct usb_device *dev, u8 request,
u16 value,
if (flags == DW210X_READ_MSG)
memcpy(data, u8buf, len);
+
+ kfree(u8buf);
return ret;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] [media] friio: get rid of on-stack dma buffers
usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.
In lib/dma_debug.c the function check_for_stack even warns about it:
WARNING: at lib/dma-debug.c:866 check_for_stack
Note: This change is tested to compile only, as I don't have the hardware.
Signed-off-by: Florian Mickler flor...@mickler.org
---
drivers/media/dvb/dvb-usb/friio.c | 23 +++
1 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/friio.c
b/drivers/media/dvb/dvb-usb/friio.c
index 14a65b4..76159ae 100644
--- a/drivers/media/dvb/dvb-usb/friio.c
+++ b/drivers/media/dvb/dvb-usb/friio.c
@@ -142,17 +142,20 @@ static u32 gl861_i2c_func(struct i2c_adapter *adapter)
return I2C_FUNC_I2C;
}
-
static int friio_ext_ctl(struct dvb_usb_adapter *adap,
u32 sat_color, int lnb_on)
{
int i;
int ret;
struct i2c_msg msg;
- u8 buf[2];
+ u8 *buf;
u32 mask;
u8 lnb = (lnb_on) ? FRIIO_CTL_LNB : 0;
+ buf = kmalloc(2, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
msg.addr = 0x00;
msg.flags = 0;
msg.len = 2;
@@ -189,6 +192,7 @@ static int friio_ext_ctl(struct dvb_usb_adapter *adap,
buf[1] |= FRIIO_CTL_CLK;
ret += gl861_i2c_xfer(adap-dev-i2c_adap, msg, 1);
+ kfree(buf);
return (ret == 70);
}
@@ -219,11 +223,20 @@ static int friio_initialize(struct dvb_usb_device *d)
int ret;
int i;
int retry = 0;
- u8 rbuf[2];
- u8 wbuf[3];
+ u8 *rbuf, *wbuf;
deb_info(%s called.\n, __func__);
+ wbuf = kmalloc(3, GFP_KERNEL);
+ if (!wbuf)
+ return -ENOMEM;
+
+ rbuf = kmalloc(2, GFP_KERNEL);
+ if (!rbuf) {
+ kfree(wbuf);
+ return -ENOMEM;
+ }
+
/* use gl861_i2c_msg instead of gl861_i2c_xfer(), */
/* because the i2c device is not set up yet. */
wbuf[0] = 0x11;
@@ -358,6 +371,8 @@ restart:
return 0;
error:
+ kfree(wbuf);
+ kfree(rbuf);
deb_info(%s:ret == %d\n, __func__, ret);
return -EIO;
}
--
1.7.4.1
--
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 5/6] [media] m920x: get rid of on-stack dma buffers
usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.
In lib/dma_debug.c the function check_for_stack even warns about it:
WARNING: at lib/dma-debug.c:866 check_for_stack
Note: This change is tested to compile only, as I don't have the hardware.
Signed-off-by: Florian Mickler flor...@mickler.org
---
drivers/media/dvb/dvb-usb/m920x.c | 33 ++---
1 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/m920x.c
b/drivers/media/dvb/dvb-usb/m920x.c
index da9dc91..f66eaa3 100644
--- a/drivers/media/dvb/dvb-usb/m920x.c
+++ b/drivers/media/dvb/dvb-usb/m920x.c
@@ -134,13 +134,17 @@ static int m920x_rc_query(struct dvb_usb_device *d, u32
*event, int *state)
{
struct m920x_state *m = d-priv;
int i, ret = 0;
- u8 rc_state[2];
+ u8 *rc_state;
+
+ rc_state = kmalloc(2, GFP_KERNEL);
+ if (!rc_state)
+ return -ENOMEM;
if ((ret = m920x_read(d-udev, M9206_CORE, 0x0, M9206_RC_STATE,
rc_state, 1)) != 0)
- goto unlock;
+ goto out;
if ((ret = m920x_read(d-udev, M9206_CORE, 0x0, M9206_RC_KEY, rc_state
+ 1, 1)) != 0)
- goto unlock;
+ goto out;
for (i = 0; i d-props.rc.legacy.rc_map_size; i++)
if (rc5_data(d-props.rc.legacy.rc_map_table[i]) ==
rc_state[1]) {
@@ -149,7 +153,7 @@ static int m920x_rc_query(struct dvb_usb_device *d, u32
*event, int *state)
switch(rc_state[0]) {
case 0x80:
*state = REMOTE_NO_KEY_PRESSED;
- goto unlock;
+ goto out;
case 0x88: /* framing error or invalid code */
case 0x99:
@@ -157,7 +161,7 @@ static int m920x_rc_query(struct dvb_usb_device *d, u32
*event, int *state)
case 0xd8:
*state = REMOTE_NO_KEY_PRESSED;
m-rep_count = 0;
- goto unlock;
+ goto out;
case 0x93:
case 0x92:
@@ -165,7 +169,7 @@ static int m920x_rc_query(struct dvb_usb_device *d, u32
*event, int *state)
case 0x82:
m-rep_count = 0;
*state = REMOTE_KEY_PRESSED;
- goto unlock;
+ goto out;
case 0x91:
case 0x81: /* pinnacle PCTV310e */
@@ -174,12 +178,12 @@ static int m920x_rc_query(struct dvb_usb_device *d, u32
*event, int *state)
*state = REMOTE_KEY_REPEAT;
else
*state = REMOTE_NO_KEY_PRESSED;
- goto unlock;
+ goto out;
default:
deb(Unexpected rc state %02x\n, rc_state[0]);
*state = REMOTE_NO_KEY_PRESSED;
- goto unlock;
+ goto out;
}
}
@@ -188,8 +192,8 @@ static int m920x_rc_query(struct dvb_usb_device *d, u32
*event, int *state)
*state = REMOTE_NO_KEY_PRESSED;
- unlock:
-
+ out:
+ kfree(rc_state);
return ret;
}
@@ -339,13 +343,19 @@ static int m920x_pid_filter(struct dvb_usb_adapter *adap,
int index, u16 pid, in
static int m920x_firmware_download(struct usb_device *udev, const struct
firmware *fw)
{
u16 value, index, size;
- u8 read[4], *buff;
+ u8 *read, *buff;
int i, pass, ret = 0;
buff = kmalloc(65536, GFP_KERNEL);
if (buff == NULL)
return -ENOMEM;
+ read = kmalloc(4, GFP_KERNEL);
+ if (!read) {
+ kfree(buff);
+ return -ENOMEM;
+ }
+
if ((ret = m920x_read(udev, M9206_FILTER, 0x0, 0x8000, read, 4)) != 0)
goto done;
deb(%x %x %x %x\n, read[0], read[1], read[2], read[3]);
@@ -396,6 +406,7 @@ static int m920x_firmware_download(struct usb_device *udev,
const struct firmwar
deb(firmware uploaded!\n);
done:
+ kfree(read);
kfree(buff);
return ret;
--
1.7.4.1
--
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 0/6] get rid of on-stack dma buffers
Hi all! These patches get rid of on-stack dma buffers for some of the dvb-usb drivers. I do not own the hardware, so these are only compile tested. I would appreciate testing and review. They were previously sent to the list, but some error on my side prevented (some of?) them from beeing delivered to all parties (the lists). These changes are motivated by https://bugzilla.kernel.org/show_bug.cgi?id=15977 . The patches which got tested already were submitted to Mauro (and lkml/linux-media) yesterday seperately. Those fix this same issue for ec168, ce6230, au6610 and lmedm04. A fix for vp702x has been submitted seperately for review on the list. I have similiar fixes like the vp702x-fix for dib0700 (overlooked some on-stack buffers in there in my original submission as well) and gp8psk, but I am holding them back 'till I got time to recheck those and getting some feedback on vp702x. Please review and test. Regards, Flo Florian Mickler (6): [media] a800: get rid of on-stack dma buffers [media v2] vp7045: get rid of on-stack dma buffers [media] friio: get rid of on-stack dma buffers [media] dw2102: get rid of on-stack dma buffer [media] m920x: get rid of on-stack dma buffers [media] opera1: get rid of on-stack dma buffer drivers/media/dvb/dvb-usb/a800.c | 17 ++--- drivers/media/dvb/dvb-usb/dw2102.c | 10 ++- drivers/media/dvb/dvb-usb/friio.c | 23 ++--- drivers/media/dvb/dvb-usb/m920x.c | 33 drivers/media/dvb/dvb-usb/opera1.c | 31 +++ drivers/media/dvb/dvb-usb/vp7045.c | 47 ++-- 6 files changed, 116 insertions(+), 45 deletions(-) -- 1.7.4.1 -- 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/6 v2] [media] vp7045: get rid of on-stack dma buffers
usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.
In lib/dma_debug.c the function check_for_stack even warns about it:
WARNING: at lib/dma-debug.c:866 check_for_stack
Note: This change is tested to compile only, as I don't have the hardware.
Signed-off-by: Florian Mickler flor...@mickler.org
---
[v2: pulled buffer access under the mutex]
drivers/media/dvb/dvb-usb/vp7045.c | 47 ++--
1 files changed, 34 insertions(+), 13 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/vp7045.c
b/drivers/media/dvb/dvb-usb/vp7045.c
index ab0ab3c..3db89e3 100644
--- a/drivers/media/dvb/dvb-usb/vp7045.c
+++ b/drivers/media/dvb/dvb-usb/vp7045.c
@@ -28,9 +28,9 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
int vp7045_usb_op(struct dvb_usb_device *d, u8 cmd, u8 *out, int outlen, u8
*in, int inlen, int msec)
{
int ret = 0;
- u8 inbuf[12] = { 0 }, outbuf[20] = { 0 };
+ u8 *buf = d-priv;
- outbuf[0] = cmd;
+ buf[0] = cmd;
if (outlen 19)
outlen = 19;
@@ -38,19 +38,21 @@ int vp7045_usb_op(struct dvb_usb_device *d, u8 cmd, u8
*out, int outlen, u8 *in,
if (inlen 11)
inlen = 11;
+ ret = mutex_lock_interruptible(d-usb_mutex);
+ if (ret)
+ return ret;
+
if (out != NULL outlen 0)
- memcpy(outbuf[1], out, outlen);
+ memcpy(buf[1], out, outlen);
deb_xfer(out buffer: );
- debug_dump(outbuf,outlen+1,deb_xfer);
+ debug_dump(buf, outlen+1, deb_xfer);
- if ((ret = mutex_lock_interruptible(d-usb_mutex)))
- return ret;
if (usb_control_msg(d-udev,
usb_sndctrlpipe(d-udev,0),
TH_COMMAND_OUT, USB_TYPE_VENDOR | USB_DIR_OUT, 0, 0,
- outbuf, 20, 2000) != 20) {
+ buf, 20, 2000) != 20) {
err(USB control message 'out' went wrong.);
ret = -EIO;
goto unlock;
@@ -61,17 +63,17 @@ int vp7045_usb_op(struct dvb_usb_device *d, u8 cmd, u8
*out, int outlen, u8 *in,
if (usb_control_msg(d-udev,
usb_rcvctrlpipe(d-udev,0),
TH_COMMAND_IN, USB_TYPE_VENDOR | USB_DIR_IN, 0, 0,
- inbuf, 12, 2000) != 12) {
+ buf, 12, 2000) != 12) {
err(USB control message 'in' went wrong.);
ret = -EIO;
goto unlock;
}
deb_xfer(in buffer: );
- debug_dump(inbuf,12,deb_xfer);
+ debug_dump(buf, 12, deb_xfer);
if (in != NULL inlen 0)
- memcpy(in,inbuf[1],inlen);
+ memcpy(in, buf[1], inlen);
unlock:
mutex_unlock(d-usb_mutex);
@@ -222,8 +224,26 @@ static struct dvb_usb_device_properties vp7045_properties;
static int vp7045_usb_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
- return dvb_usb_device_init(intf, vp7045_properties,
- THIS_MODULE, NULL, adapter_nr);
+ struct dvb_usb_device *d;
+ int ret = dvb_usb_device_init(intf, vp7045_properties,
+ THIS_MODULE, d, adapter_nr);
+ if (ret)
+ return ret;
+
+ d-priv = kmalloc(20, GFP_KERNEL);
+ if (!d-priv) {
+ dvb_usb_device_exit(intf);
+ return -ENOMEM;
+ }
+
+ return ret;
+}
+
+static void vp7045_usb_disconnect(struct usb_interface *intf)
+{
+ struct dvb_usb_device *d = usb_get_intfdata(intf);
+ kfree(d-priv);
+ dvb_usb_device_exit(intf);
}
static struct usb_device_id vp7045_usb_table [] = {
@@ -238,6 +258,7 @@ MODULE_DEVICE_TABLE(usb, vp7045_usb_table);
static struct dvb_usb_device_properties vp7045_properties = {
.usb_ctrl = CYPRESS_FX2,
.firmware = dvb-usb-vp7045-01.fw,
+ .size_of_priv = sizeof(u8 *),
.num_adapters = 1,
.adapter = {
@@ -284,7 +305,7 @@ static struct dvb_usb_device_properties vp7045_properties =
{
static struct usb_driver vp7045_usb_driver = {
.name = dvb_usb_vp7045,
.probe = vp7045_usb_probe,
- .disconnect = dvb_usb_device_exit,
+ .disconnect = vp7045_usb_disconnect,
.id_table = vp7045_usb_table,
};
--
1.7.4.1
--
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-dvb Mercurial repository and media-build git repository
Hi, Today I added a patch at the old -hg repository meant to warn people that might eventually be using the old v4l-dvb hg repository in the hope that his device will eventually work on it. The latest patch there were applied 8 months ago. So, I'd say that the drivers there are likely older than 2.6.36 kernel. I also updated the linuxtv git homepage to point to the media_build.git tree (that replaced the legacy tree), and added a few patches there to help developers to know what media_tree.git snapshot was used when some user reports an issue. Now, when someone compiles from the media-build, a warning message will be displayed when dvb, rc or v4l core is loaded. Something like: Linux video capture interface: v2.00 WARNING: You are using an experimental version of the media stack. As the driver is backported to an older kernel, it doesn't offer enough quality for its usage in production. Use it with care. Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): 41f3becb7bef489f9e8c35284dd88a1ff59b190c [media] V4L DocBook: update V4L2 version 00cd84ab54a51d4bce9754d54d5d8160358844c4 [media] V4L doc fixes e82aa4810c1ff222b344e3de6cc5c26177c321f6 [media] v4l2: vb2-dma-sg: fix potential security hole With the above messages, developers that may be receiving a bug report will know that: 1) the reporter used a media_tree.git tree to report a bug, and not a vanilla (or a distro-patched kernel); 2) the latest 3 git commits that were applied at the tree, being able to check if a newer patch might already be fixed the reported issue. The tester will know that: 1) he is using an experimental tree, not meant for production; 2) the email where he could report an issue; 3) that developers need a dmesg in order to know what's happening. It should be noticed that there are still a few group of developers using the old hg tree as the basis for his development. I don't have any intention to remove the -hg repository for the same reason we still preserve the legacy cvs repositories: people may find its history useful. Also, people still can send me pull requests from -hg, as I still have my scripts to retrieve patches from it. However, as the code is diverging from upstream, as nobody is keeping the -hg tree updated, the developers that are still using -hg will likely need to apply some backports by themselves, or eventually work together to do backports, otherwise, the submitted patches may not apply upstream anymore, as some non-trivial merge conflict may happen. 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 0/6] get rid of on-stack dma buffers
Florian Mickler flor...@mickler.org wrote: Hi all! These patches get rid of on-stack dma buffers for some of the dvb-usb drivers. I do not own the hardware, so these are only compile tested. I would appreciate testing and review. They were previously sent to the list, but some error on my side prevented (some of?) them from beeing delivered to all parties (the lists). These changes are motivated by https://bugzilla.kernel.org/show_bug.cgi?id=15977 . The patches which got tested already were submitted to Mauro (and lkml/linux-media) yesterday seperately. Those fix this same issue for ec168, ce6230, au6610 and lmedm04. A fix for vp702x has been submitted seperately for review on the list. I have similiar fixes like the vp702x-fix for dib0700 (overlooked some on-stack buffers in there in my original submission as well) and gp8psk, but I am holding them back 'till I got time to recheck those and getting some feedback on vp702x. Please review and test. Regards, Flo Florian Mickler (6): [media] a800: get rid of on-stack dma buffers [media v2] vp7045: get rid of on-stack dma buffers [media] friio: get rid of on-stack dma buffers [media] dw2102: get rid of on-stack dma buffer [media] m920x: get rid of on-stack dma buffers [media] opera1: get rid of on-stack dma buffer drivers/media/dvb/dvb-usb/a800.c | 17 ++--- drivers/media/dvb/dvb-usb/dw2102.c | 10 ++- drivers/media/dvb/dvb-usb/friio.c | 23 ++--- drivers/media/dvb/dvb-usb/m920x.c | 33 drivers/media/dvb/dvb-usb/opera1.c | 31 +++ drivers/media/dvb/dvb-usb/vp7045.c | 47 ++-- 6 files changed, 116 insertions(+), 45 deletions(-) -- 1.7.4.1 -- 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 Florian, For all of these, what happens when the USB call times out and you kfree() the buffer? Can the USB DMA actually complete after this kfree(), possibly corrupting space that has been reallocated off the heap, since the kfree()? This is the scenario for which I assume allocating off the stack is bad. Do these changes simply make corruption less noticable since heap gets corrupted vs stack? Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: 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 Mar 21 19:05:47 CET 2011 git hash:d95ec04a6f9fe5ff72b6798106f563a21880c3ac 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 linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS 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
Re: [GIT PATCHES FOR 2.6.39] Make the UVC API public (and bug fixes)
Em 27-02-2011 14:36, Laurent Pinchart escreveu:
Hi Mauro,
These patches move the uvcvideo.h header file from drivers/media/video/uvc
to include/linux, making the UVC API public.
Martin Rubli has committed support for the public API to libwebcam, so
userspace support is up to date.
The following changes since commit 9e650fdb12171a5a5839152863eaab9426984317:
[media] drivers:media:radio: Update Kconfig and Makefile for wl128x FM
driver (2011-02-27 07:50:42 -0300)
are available in the git repository at:
git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next
Laurent Pinchart (6):
uvcvideo: Deprecate UVCIOC_CTRL_{ADD,MAP_OLD,GET,SET}
There are some places there saying that the removal will happen at 2.6.39.
uvcvideo: Rename UVC_CONTROL_* flags to UVC_CTRL_FLAG_*
uvcvideo: Include linux/types.h in uvcvideo.h
uvcvideo: Move uvcvideo.h to include/linux
-'U'00-0F drivers/media/video/uvc/uvcvideo.h conflict!
+'U'00-0F linux/uvcvideo.hconflict!
Please avoid conflicts at userspace API's.
uvcvideo: Fix descriptor parsing for video output devices
This one seems independent from API changes. Applying it.
v4l: videobuf2: Typo fix
Martin Rubli (2):
uvcvideo: Add UVCIOC_CTRL_QUERY ioctl
uvcvideo: Add driver documentation
Please, don't use enum at the public API:
+ __u32 id V4L2 control identifier
+ __u8name[32]V4L2 control name
+ __u8entity[16] UVC extension unit GUID
+ __u8selectorUVC control selector
+ __u8sizeV4L2 control size (in bits)
+ __u8offset V4L2 control offset (in bits)
+ enum v4l2_ctrl_type
+ v4l2_type V4L2 control type
+ enum uvc_control_data_type
+ data_type UVC control data type
+ struct uvc_menu_info
+ *menu_info Array of menu entries (for menu controls only)
+ __u32 menu_count Number of menu entries (for menu controls only)
+
+ * struct uvc_menu_info
+
+ __u32 value Menu entry value used by the device
+ __u8name[32]Menu entry name
enum size is not portable. (OK, I know that V4L2 API has some enum's, but let's
not add new stuff using it). Also, please be sure that the new API won't require
any compat32 bits.
Stephan Lachowsky (1):
uvcvideo: Fix uvc_fixup_video_ctrl() format search
This one seems independent from API changes. Applying it.
Documentation/feature-removal-schedule.txt | 23 ++
Documentation/ioctl/ioctl-number.txt |2 +-
Documentation/video4linux/uvcvideo.txt | 239 ++
drivers/media/video/uvc/uvc_ctrl.c | 334
drivers/media/video/uvc/uvc_driver.c | 11 +-
drivers/media/video/uvc/uvc_isight.c |3 +-
drivers/media/video/uvc/uvc_queue.c|3 +-
drivers/media/video/uvc/uvc_status.c |3 +-
drivers/media/video/uvc/uvc_v4l2.c | 45 +++-
drivers/media/video/uvc/uvc_video.c| 17 +-
include/linux/Kbuild |1 +
.../media/video/uvc = include/linux}/uvcvideo.h | 43 ++-
include/media/videobuf2-core.h |2 +-
13 files changed, 550 insertions(+), 176 deletions(-)
create mode 100644 Documentation/video4linux/uvcvideo.txt
rename {drivers/media/video/uvc = include/linux}/uvcvideo.h (95%)
--
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] add endpoint direction test in alt_xfer
Hi, This patch fixes a bug in gspca, more precisely in alt_xfer(). This function looks for an input transfer endpoint in an alternate setting. By default it returns the first endpoint corresponding to the transfer type indicated in parameter. But with some USB devices, the first endpoint corresponding to the transfer type is not always an INPUT endpoint but an OUTPOUT one. This patch adds the endpoint direction test to be sure to return an INPUT endpoint Regards Signed-off-by: Patrice CHOTARD patricechot...@free.fr --- drivers/media/video/gspca/gspca.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/gspca/gspca.c b/drivers/media/video/gspca/gspca.c index f21f2a2..03823ea 100644 --- a/drivers/media/video/gspca/gspca.c +++ b/drivers/media/video/gspca/gspca.c @@ -631,7 +631,8 @@ static struct usb_host_endpoint *alt_xfer(struct usb_host_interface *alt, ep = alt-endpoint[i]; attr = ep-desc.bmAttributes USB_ENDPOINT_XFERTYPE_MASK; if (attr == xfer -ep-desc.wMaxPacketSize != 0) +ep-desc.wMaxPacketSize != 0 +usb_endpoint_dir_in(ep-desc)) return ep; } return NULL; -- 1.7.0.4 -- 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
S2-3200 switching-timeouts on 2.6.38
Hello, I would like to know if there is any intention to include this patch soon? https://patchwork.kernel.org/patch/244201/ Currently using 2.6.38 results in switching-timeouts on my S2-3200 and this patch fixes this for good. So it would be nice to have it in 2.6.39. Thank you and best regards, Rico Tzschichholz signature.asc Description: OpenPGP digital signature
[PATCH/RFC] v4l2-ctl: Add -m option for the multi-planar API
Add -m option to force using the multiplanar API. That is,
where applicable, instead of V4L2_BUF_TYPE_VIDEO_[OUTPUT/CAPTURE]
buffer types their *_MPLANE counterparts are used when this option
is enabled.
Signed-off-by: Sylwester Nawrocki snj...@gmail.com
---
Hello,
This patch has been tested with vivi, after applying a basic
support for multi-planar formats. I intend to also post
the vivi patch after completing the image generation bits.
Regards,
Sylwester
---
utils/v4l2-ctl/v4l2-ctl.cpp | 93 +-
1 files changed, 82 insertions(+), 11 deletions(-)
diff --git a/utils/v4l2-ctl/v4l2-ctl.cpp b/utils/v4l2-ctl/v4l2-ctl.cpp
index 3db26ab..efd45b8 100644
--- a/utils/v4l2-ctl/v4l2-ctl.cpp
+++ b/utils/v4l2-ctl/v4l2-ctl.cpp
@@ -68,6 +68,7 @@ enum Option {
OptSetInput = 'i',
OptListCtrls = 'l',
OptListCtrlsMenus = 'L',
+ OptUseMultiplanarApi = 'm',
OptListOutputs = 'N',
OptListInputs = 'n',
OptGetOutput = 'O',
@@ -223,6 +224,7 @@ static struct option long_options[] = {
{try-fmt-video-out, required_argument, 0, OptTryVideoOutFormat},
{help, no_argument, 0, OptHelp},
{wrapper, no_argument, 0, OptUseWrapper},
+ {multiplanar-api, no_argument, 0, OptUseMultiplanarApi},
{get-output, no_argument, 0, OptGetOutput},
{set-output, required_argument, 0, OptSetOutput},
{list-outputs, no_argument, 0, OptListOutputs},
@@ -509,6 +511,9 @@ static void usage(void)
--sleep=secs sleep for secs seconds, call QUERYCAP
and close the file handle\n
--streamoffturn the stream off [VIDIOC_STREAMOFF]\n
--streamon turn the stream on [VIDIOC_STREAMON]\n
+-m, --multiplanar-api\n
+ force using the multiplanar API; it is
applicable to video output\n
+ and video capture devices\n
--log-status log the board status in the kernel log
[VIDIOC_LOG_STATUS]\n);
exit(0);
}
@@ -541,8 +546,12 @@ static std::string buftype2s(int type)
switch (type) {
case V4L2_BUF_TYPE_VIDEO_CAPTURE:
return Video Capture;
+ case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
+ return Video Capture Multiplanar;
case V4L2_BUF_TYPE_VIDEO_OUTPUT:
return Video Output;
+ case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
+ return Video Output Multiplanar;
case V4L2_BUF_TYPE_VIDEO_OVERLAY:
return Video Overlay;
case V4L2_BUF_TYPE_VBI_CAPTURE:
@@ -1064,6 +1073,19 @@ static void printfmt(const struct v4l2_format vfmt)
if (vfmt.fmt.pix.priv)
printf(\tCustom Info : %08x\n, vfmt.fmt.pix.priv);
break;
+ case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
+ case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
+ printf(\tWidth/Height : %u/%u\n, vfmt.fmt.pix_mp.width,
vfmt.fmt.pix_mp.height);
+ printf(\tPixel Format : '%s'\n,
fcc2s(vfmt.fmt.pix_mp.pixelformat).c_str());
+ printf(\tField : %s\n,
field2s(vfmt.fmt.pix_mp.field).c_str());
+ printf(\tNumber of planes : %u\n,
vfmt.fmt.pix_mp.num_planes);
+ printf(\tColorspace: %s\n,
colorspace2s(vfmt.fmt.pix_mp.colorspace).c_str());
+ for (int i = 0; i vfmt.fmt.pix_mp.num_planes; i++) {
+ printf(\tPlane %d :\n, i);
+ printf(\t Bytes per Line : %u\n,
vfmt.fmt.pix_mp.plane_fmt[i].bytesperline);
+ printf(\t Size Image : %u\n,
vfmt.fmt.pix_mp.plane_fmt[i].sizeimage);
+ }
+ break;
case V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY:
case V4L2_BUF_TYPE_VIDEO_OVERLAY:
printf(\tLeft/Top: %d/%d\n,
@@ -1302,8 +1324,12 @@ static std::string cap2s(unsigned cap)
if (cap V4L2_CAP_VIDEO_CAPTURE)
s += \t\tVideo Capture\n;
+ if (cap V4L2_CAP_VIDEO_CAPTURE_MPLANE)
+ s += \t\tVideo Capture Multiplanar\n;
if (cap V4L2_CAP_VIDEO_OUTPUT)
s += \t\tVideo Output\n;
+ if (cap V4L2_CAP_VIDEO_OUTPUT_MPLANE)
+ s += \t\tVideo Output Multiplanar\n;
if (cap V4L2_CAP_VIDEO_OVERLAY)
s += \t\tVideo Overlay\n;
if (cap V4L2_CAP_VIDEO_OUTPUT_OVERLAY)
@@ -1845,12 +1871,13 @@ static __u32 parse_event(const char *e)
return event;
}
-static __u32 find_pixel_format(int fd, unsigned index)
+static __u32 find_pixel_format(int fd, unsigned index, bool multiplanar)
{
struct v4l2_fmtdesc fmt;
fmt.index = index;
- fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ fmt.type = multiplanar ?
+ V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE :
V4L2_BUF_TYPE_VIDEO_CAPTURE;
if (doioctl(fd,
Re: [PATCH v2 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical
Em 28-02-2011 15:20, Mauro Carvalho Chehab escreveu:
Em 28-02-2011 12:47, Jiri Slaby escreveu:
On 02/28/2011 03:53 PM, Konrad Rzeszutek Wilk wrote:
On Mon, Feb 28, 2011 at 10:37:02AM +0100, Jiri Slaby wrote:
mem-dma_handle is a dma address obtained by dma_alloc_coherent which
needn't be a physical address in presence of IOMMU. So ensure we are
Can you add a comment why you are fixing it? Is there a bug report for this?
Under what conditions did you expose this fault?
No, by a just peer review when I was looking for something completely
different.
You also might want to mention that needn't be a physical address as
a hardware IOMMU can (and most likely) will return a bus address where
physical != bus address.
Mauro, do you want me to resend this with such an udpate in the changelog?
Having it properly documented is always a good idea, especially since a
similar
fix might be needed on other drivers that also need contiguous memory. While
it
currently is used only on devices embedded on hardware with no iommu, there
are
some x86 hardware that doesn't allow DMA scatter/gather.
Btw, it may be worth to take a look at vb2 dma contig module, as it might have
similar issues.
Otherwise you can stick 'Reviewed-by: Konrad Rzeszutek Wilk
konrad.w...@oracle.com'
on it.
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
As I got no return, and the patch looked sane, I've reviewed the comment myself,
in order to make it more explicit, as suggested by Konrad, and added his
reviewed-by: tag:
Author: Jiri Slaby jsl...@suse.cz
Date: Mon Feb 28 06:37:02 2011 -0300
[media] V4L: videobuf, don't use dma addr as physical
mem-dma_handle is a dma address obtained by dma_alloc_coherent which
needn't be a physical address in presence of IOMMU, as
a hardware IOMMU can (and most likely) will return a bus address where
physical != bus address.
So ensure we are remapping (remap_pfn_range) the right page in
__videobuf_mmap_mapper by using virt_to_phys(mem-vaddr) and not
mem-dma_handle.
While at it, use PFN_DOWN instead of explicit shift.
Signed-off-by: Jiri Slaby jsl...@suse.cz
Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/videobuf-dma-contig.c
b/drivers/media/video/videobuf-dma-contig.c
index c969111..19d3e4a 100644
--- a/drivers/media/video/videobuf-dma-contig.c
+++ b/drivers/media/video/videobuf-dma-contig.c
@@ -300,7 +300,7 @@ static int __videobuf_mmap_mapper(struct videobuf_queue *q,
vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
retval = remap_pfn_range(vma, vma-vm_start,
-mem-dma_handle PAGE_SHIFT,
+ PFN_DOWN(virt_to_phys(mem-vaddr))
size, vma-vm_page_prot);
if (retval) {
dev_err(q-dev, mmap: remap failed with error %d. , retval);
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical
On 03/21/2011 11:43 PM, Mauro Carvalho Chehab wrote:
As I got no return, and the patch looked sane, I've reviewed the comment
myself,
Aha, I forgot to send it. Sorry.
It looks OK.
Author: Jiri Slaby jsl...@suse.cz
Date: Mon Feb 28 06:37:02 2011 -0300
[media] V4L: videobuf, don't use dma addr as physical
mem-dma_handle is a dma address obtained by dma_alloc_coherent which
needn't be a physical address in presence of IOMMU, as
a hardware IOMMU can (and most likely) will return a bus address where
physical != bus address.
So ensure we are remapping (remap_pfn_range) the right page in
__videobuf_mmap_mapper by using virt_to_phys(mem-vaddr) and not
mem-dma_handle.
While at it, use PFN_DOWN instead of explicit shift.
Signed-off-by: Jiri Slaby jsl...@suse.cz
Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/videobuf-dma-contig.c
b/drivers/media/video/videobuf-dma-contig.c
index c969111..19d3e4a 100644
--- a/drivers/media/video/videobuf-dma-contig.c
+++ b/drivers/media/video/videobuf-dma-contig.c
@@ -300,7 +300,7 @@ static int __videobuf_mmap_mapper(struct videobuf_queue
*q,
vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
retval = remap_pfn_range(vma, vma-vm_start,
-mem-dma_handle PAGE_SHIFT,
+ PFN_DOWN(virt_to_phys(mem-vaddr))
size, vma-vm_page_prot);
if (retval) {
dev_err(q-dev, mmap: remap failed with error %d. , retval);
thanks,
--
js
suse labs
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] v180 - DM04/QQBOX added support for BS2F7HZ0194 versions
Em 12-02-2011 23:35, Malcolm Priestley escreveu: Old versions of these boxes have the BS2F7HZ0194 tuner module on both the LME2510 and LME2510C. Firmware dvb-usb-lme2510-s0194.fw and/or dvb-usb-lme2510c-s0194.fw files are required. See Documentation/dvb/lmedm04.txt Patch 535181 is also required. Signed-off-by: Malcolm Priestley tvbox...@gmail.com --- @@ -1110,5 +1220,5 @@ module_exit(lme2510_module_exit); MODULE_AUTHOR(Malcolm Priestley tvbox...@gmail.com); MODULE_DESCRIPTION(LME2510(C) DVB-S USB2.0); -MODULE_VERSION(1.76); +MODULE_VERSION(1.80); MODULE_LICENSE(GPL); There were a merge conflict on this patch. The version we have was 1.75. Maybe some patch got missed? 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: [RFC PATCH RESEND v2 2/3] v4l2-ctrls: modify uvc driver to use new menu type of V4L2_CID_FOCUS_AUTO
Hi Laurent,
Em 03-03-2011 07:10, Laurent Pinchart escreveu:
On Thursday 03 March 2011 03:16:32 Kim, HeungJun wrote:
As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu
type, this uvc is modified the usage of V4L2_CID_FOCUS_AUTO, maintaining
v4l2 menu index.
Signed-off-by: Heungjun Kim riverful@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
I'm assuming that you'll be applying those patches on your tree and sending
me a pull request, right?
Thanks!
Mauro
---
drivers/media/video/uvc/uvc_ctrl.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_ctrl.c
b/drivers/media/video/uvc/uvc_ctrl.c index 59f8a9a..064827f 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -333,6 +333,11 @@ static struct uvc_menu_info exposure_auto_controls[] =
{ { 8, Aperture Priority Mode },
};
+static struct uvc_menu_info focus_auto_controls[] = {
+{ 0, Manual Mode },
+{ 1, Auto Mode },
+};
+
static __s32 uvc_ctrl_get_zoom(struct uvc_control_mapping *mapping,
__u8 query, const __u8 *data)
{
@@ -560,8 +565,10 @@ static struct uvc_control_mapping uvc_ctrl_mappings[]
= { .selector= UVC_CT_FOCUS_AUTO_CONTROL,
.size = 1,
.offset = 0,
-.v4l2_type = V4L2_CTRL_TYPE_BOOLEAN,
+.v4l2_type = V4L2_CTRL_TYPE_MENU,
.data_type = UVC_CTRL_DATA_TYPE_BOOLEAN,
+.menu_info = focus_auto_controls,
+.menu_count = ARRAY_SIZE(focus_auto_controls),
},
{
.id = V4L2_CID_IRIS_ABSOLUTE,
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] v180 - DM04/QQBOX added support for BS2F7HZ0194 versions
On Mon, 2011-03-21 at 21:17 -0300, Mauro Carvalho Chehab wrote: Em 12-02-2011 23:35, Malcolm Priestley escreveu: Old versions of these boxes have the BS2F7HZ0194 tuner module on both the LME2510 and LME2510C. Firmware dvb-usb-lme2510-s0194.fw and/or dvb-usb-lme2510c-s0194.fw files are required. See Documentation/dvb/lmedm04.txt Patch 535181 is also required. Signed-off-by: Malcolm Priestley tvbox...@gmail.com --- @@ -1110,5 +1220,5 @@ module_exit(lme2510_module_exit); MODULE_AUTHOR(Malcolm Priestley tvbox...@gmail.com); MODULE_DESCRIPTION(LME2510(C) DVB-S USB2.0); -MODULE_VERSION(1.76); +MODULE_VERSION(1.80); MODULE_LICENSE(GPL); There were a merge conflict on this patch. The version we have was 1.75. Maybe some patch got missed? 1.76 relates to remote control patches. https://patchwork.kernel.org/patch/499391/ https://patchwork.kernel.org/patch/499401/ Regards Malcolm -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] v180 - DM04/QQBOX added support for BS2F7HZ0194 versions
Em 21-03-2011 21:32, Malcolm Priestley escreveu: On Mon, 2011-03-21 at 21:17 -0300, Mauro Carvalho Chehab wrote: Em 12-02-2011 23:35, Malcolm Priestley escreveu: Old versions of these boxes have the BS2F7HZ0194 tuner module on both the LME2510 and LME2510C. Firmware dvb-usb-lme2510-s0194.fw and/or dvb-usb-lme2510c-s0194.fw files are required. See Documentation/dvb/lmedm04.txt Patch 535181 is also required. Signed-off-by: Malcolm Priestley tvbox...@gmail.com --- @@ -1110,5 +1220,5 @@ module_exit(lme2510_module_exit); MODULE_AUTHOR(Malcolm Priestley tvbox...@gmail.com); MODULE_DESCRIPTION(LME2510(C) DVB-S USB2.0); -MODULE_VERSION(1.76); +MODULE_VERSION(1.80); MODULE_LICENSE(GPL); There were a merge conflict on this patch. The version we have was 1.75. Maybe some patch got missed? 1.76 relates to remote control patches. https://patchwork.kernel.org/patch/499391/ https://patchwork.kernel.org/patch/499401/ Ah! Ok, I'll be applying them. Btw, please, move the keycode tables to the proper place and use the RC core stuff. The idea is to remove all those keytables from kernel in a near future, and use the userspace tool to load it via udev. Thanks! 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/2] v180 - DM04/QQBOX added support for BS2F7HZ0194 versions
On 03/22/2011 02:32 AM, Malcolm Priestley wrote: On Mon, 2011-03-21 at 21:17 -0300, Mauro Carvalho Chehab wrote: Em 12-02-2011 23:35, Malcolm Priestley escreveu: Old versions of these boxes have the BS2F7HZ0194 tuner module on both the LME2510 and LME2510C. Firmware dvb-usb-lme2510-s0194.fw and/or dvb-usb-lme2510c-s0194.fw files are required. See Documentation/dvb/lmedm04.txt Patch 535181 is also required. Signed-off-by: Malcolm Priestleytvbox...@gmail.com --- @@ -1110,5 +1220,5 @@ module_exit(lme2510_module_exit); MODULE_AUTHOR(Malcolm Priestleytvbox...@gmail.com); MODULE_DESCRIPTION(LME2510(C) DVB-S USB2.0); -MODULE_VERSION(1.76); +MODULE_VERSION(1.80); MODULE_LICENSE(GPL); There were a merge conflict on this patch. The version we have was 1.75. Maybe some patch got missed? 1.76 relates to remote control patches. https://patchwork.kernel.org/patch/499391/ https://patchwork.kernel.org/patch/499401/ Those are NEC extended remotes. You are now setting it as 32 bit NEC, in my understanding it should be defined as 24 bit NEC extended. Anyhow, my opinion is still that we *should* make all NEC remotes as 32 bit and leave handling of NEC 16, NEC 24, NEC 32 to NEC decoder. For example AF9015 current NEC handling is too complex for that reason... I don't like how it is implemented currently. Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] via-camera: Fix OLPC serial check
Em 10-03-2011 13:24, Jonathan Corbet escreveu: [Trying to bash my inbox into reasonable shape, sorry for the slow response...] On Thu, 3 Mar 2011 19:03:31 + (GMT) Daniel Drake d...@laptop.org wrote: The code that checks the OLPC serial port is never built at the moment, because CONFIG_OLPC_XO_1_5 doesn't exist and probably won't be added. Fix it so that it gets compiled in, only executes on OLPC laptops, and move the check into the probe routine. The compiler is smart enough to eliminate this code when CONFIG_OLPC=n (due to machine_is_olpc() always returning false). Getting rid of the nonexistent config option is clearly the right thing to do. I only wonder about moving the check to viacam_probe(). The nice thing about having things fail in viacam_init() is that, if the camera is not usable, the module will not load at all. By the time you get to viacam_probe(), the module is there but not will be useful for anything. Did the check need to move for some reason? If so, a one-of-these-days nice feature might be to allow changing override_serial at run time. Regardless, the behavior change only affects OLPC folks using the serial line, so I'm OK with it. Acked-by: Jonathan Corbet cor...@lwn.net Weird, patchwork didn't catch the acked-by: https://patchwork.kernel.org/patch/607461/ Perhaps it only does the right thing if the ack is not indented? As reference, I'm enclosing what patchwork provides when clicking at the mbox download hyperlink. Anyway, manually added. Thanks! Mauro --- From patchwork Thu Mar 3 19:03:31 2011 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: via-camera: Fix OLPC serial check Date: Thu, 03 Mar 2011 19:03:31 - From: Daniel Drake d...@laptop.org X-Patchwork-Id: 607461 Message-Id: 20110303190331.e8ed79d4...@zog.reactivated.net To: mche...@infradead.org Cc: linux-media@vger.kernel.org The code that checks the OLPC serial port is never built at the moment, because CONFIG_OLPC_XO_1_5 doesn't exist and probably won't be added. Fix it so that it gets compiled in, only executes on OLPC laptops, and move the check into the probe routine. The compiler is smart enough to eliminate this code when CONFIG_OLPC=n (due to machine_is_olpc() always returning false). Signed-off-by: Daniel Drake d...@laptop.org --- drivers/media/video/via-camera.c | 83 +- 1 files changed, 37 insertions(+), 46 deletions(-) diff snipped -- 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
