Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Florian, Thank you for the review. On Friday 26 August 2011 19:07:01 Florian Tobias Schandinat wrote: Hi Laurent, hope we're close to the final thing now. Just a few minor issues. I agree with all your comments, I'll fix the patches accordingly. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 3/3] fbdev: sh_mobile_lcdc: Support FOURCC-based format API
Hi Florian,
Thanks for the review.
On Friday 26 August 2011 19:24:02 Florian Tobias Schandinat wrote:
On 08/19/2011 09:37 AM, Laurent Pinchart wrote:
[snip]
diff --git a/drivers/video/sh_mobile_lcdcfb.c
b/drivers/video/sh_mobile_lcdcfb.c index 97ab8ba..ea3f619 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
[snip]
@@ -1099,51 +1154,78 @@ static int sh_mobile_check_var(struct
[snip]
+ if (var-format.fourcc 1) {
+ switch (var-format.fourcc) {
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_NV21:
+ var-bits_per_pixel = 12;
+ break;
+ case V4L2_PIX_FMT_RGB565:
+ case V4L2_PIX_FMT_NV16:
+ case V4L2_PIX_FMT_NV61:
+ var-bits_per_pixel = 16;
+ break;
+ case V4L2_PIX_FMT_BGR24:
+ case V4L2_PIX_FMT_NV24:
+ case V4L2_PIX_FMT_NV42:
+ var-bits_per_pixel = 24;
+ break;
+ case V4L2_PIX_FMT_BGR32:
+ var-bits_per_pixel = 32;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ memset(var-format.reserved, 0, sizeof(var-format.reserved));
If we decide to use another of the reserved area this won't have the
desired behavior as the behavior of this driver will change even if it
does not support the new field. Probably the best thing is to get the
desired behavior is zeroing the whole struct and setting the supported
fields to the actual values. You should check and adjust colorspace here
as well.
Agreed. I'll fix the patch accordingly.
--
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: [ANN] Meeting minutes of the Cambourne meeting
Hi Laurent,
On 08/08/2011 05:50 PM, Laurent Pinchart wrote:
Subdevs hierachy, Linux device model
Preliminary conclusions:
- With the move to device tree on ARM (and other platforms), I2C, SPI and
platform subdevs should be created from board code, not from bridge/host
drivers.
- Bus notifiers should be used by bridge/host drivers to wait for all
required subdevs. V4L2 core should provide helper functions.
- struct clk should be used to handle clocks provided by hosts to subdevs.
I have been investigating recently possible ways to correct the external clock
handling in Samsung FIMC driver and this led me up to the device tree stuff.
I.e. in order to be able to register any I2C client device there is a need
to enable its master clock at the v4l2 host/bridge driver.
There is an issue that the v4l2_device (host)/v4l2_subdev hierarchy is not
reflected by the linux device tree model, e.g. the host might be a platform
device while the client an I2C client device. Thus a proper device/driver
registration order is not assured by the device driver core from v4l2 POV.
I thought about embedding some API in a struct v4l2_device for the subdevs
to be able to get their master clock(s) as they need it. But this would work
only when a v4l2_device and v4l2_subdev are matched (registered) before I2C
client's probe(), or alternatively subdev_internal_ops::registered() callback,
is called.
Currently such requirement is satisfied when the I2C client/v4l2 subdev
devices are registered from within a v4l2 bridge/host driver initialization
routine. But we may need to stop doing this to adhere to the DT rules.
I guess above you didn't really mean to create subdevs from board code?
The I2C client registration is now done at the I2C bus drivers, using the OF
helpers to retrieve the child devices list from fdt.
I guess we could try to create some sort of replacement for
v4l2_i2c_new_subdev_board() function in linux/drivers/of/* (of_i2c.c ?),
similar to of_i2c_register_devices().
But first we would have somehow to make sure the host drivers are registered
and initialized first. I'm not sure how to do it.
Plus such a new subdev registration method would have to obtain a relevant
struct v4l2_device object reference during the process; which is getting
a bit cumbersome..
Also, if we used a 'struct clk' to handle clocks provided by hosts to subdevs,
could we use any subdev operation callback to pass a reference to such object
from host to subdev? I doubt since the clock may be needed in the subdev before
it is allocated and fully initialized, (i.e. available in the host).
If we have embedded a 'struct clk' pointer into struct v4l2_device, it would
have probably to be an array of clocks and the subdev would have to be able to
find out which clock applies to it.
So I thought about doing something like:
diff --git a/include/media/v4l2-device.h b/include/media/v4l2-device.h
index d61febf..9888f7d 100644
--- a/include/media/v4l2-device.h
+++ b/include/media/v4l2-device.h
@@ -54,6 +54,7 @@ struct v4l2_device {
/* notify callback called by some sub-devices. */
void (*notify)(struct v4l2_subdev *sd,
unsigned int notification, void *arg);
+ const struct clk * (*clock_get)(struct v4l2_subdev *sd);
/* The control handler. May be NULL. */
struct v4l2_ctrl_handler *ctrl_handler;
/* Device's priority state */
This would allow the host to return proper clock for a subdev.
But it won't work unless the initialization order is assured..
Actions:
- Work on a proof-of-concept implementation of the new subdevs registration
mechanism and send an RFC (whoever needs it first).
- Work on a proof-of-concept clock handling using struct clk with the OMAP3
ISP driver (Laurent).
---
Regards,
Sylwester
--
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
Some success with Terratec Cinergy HTC USB XS
Hi,
I had some success with a Terratec Cinergy HTC USB XS:
I added the usb id as a Terratec H5 to em28xx-cards.c and downloaded
the firmware file for Terratec H5, because I saw on Terratecs linux-site
that both devices use the same ICs. DVB-C works with this setup.
Watching analog tv didn't work: Xawtv timed out or hang trying to
access /dev/video0.
Is there anything else I could test?
regards,
Holger
--- linux/drivers/media/video/em28xx/em28xx-cards.c~2011-07-18
05:45:26.0 +0200
+++ linux/drivers/media/video/em28xx/em28xx-cards.c 2011-08-27
21:15:26.564483966 +0200
@@ -1883,6 +1883,8 @@ struct usb_device_id em28xx_id_table[] =
.driver_info = EM2882_BOARD_TERRATEC_HYBRID_XS },
{ USB_DEVICE(0x0ccd, 0x0042),
.driver_info = EM2882_BOARD_TERRATEC_HYBRID_XS },
+ { USB_DEVICE(0x0ccd, 0x008e),
+ .driver_info = EM2884_BOARD_TERRATEC_H5 },
{ USB_DEVICE(0x0ccd, 0x0043),
.driver_info = EM2884_BOARD_TERRATEC_H5 },
{ USB_DEVICE(0x0ccd, 0x10a2), /* Rev. 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: VIDEO_OMAP2_VOUT broken
Hi Arnd, On Sat, Aug 27, 2011 at 11:58 PM, Arnd Bergmann a...@arndb.de wrote: Hi Tomi, Apparently your patch 8cff88c5d OMAP: DSS2: remove update_mode from omapdss broke building the omap_vout driver: Yes, I didn't realize it affects v4l2, and I didn't have v4l2 enabled in the kernel. I have it now enabled by default =). There was a patch posted to linux-omap and to linux-media by Archit some weeks ago which fixes the issue. I guess it hasn't gotten into mainline yet: [PATCH] [media] OMAP_VOUT: Fix build break caused by update_mode removal in DSS2 Tomi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: Add support for arbitrary resolution for the ov5642 camera driver
Hi Bastian,
Thanks for the patch.
On Wednesday 17 August 2011 17:53:42 Bastian Hecht wrote:
This patch adds the ability to get arbitrary resolutions with a width
up to 2592 and a height up to 720 pixels instead of the standard 1280x720
only.
Signed-off-by: Bastian Hecht hec...@gmail.com
---
diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
index 6410bda..1b40d90 100644
--- a/drivers/media/video/ov5642.c
+++ b/drivers/media/video/ov5642.c
@@ -14,8 +14,10 @@
* published by the Free Software Foundation.
*/
+#include linux/bitops.h
#include linux/delay.h
#include linux/i2c.h
+#include linux/kernel.h
#include linux/slab.h
#include linux/videodev2.h
@@ -28,13 +30,25 @@
#define REG_CHIP_ID_HIGH 0x300a
#define REG_CHIP_ID_LOW 0x300b
+#define REG_RED_GAIN_HIGH0x3400
+#define REG_RED_GAIN_LOW 0x3401
+#define REG_BLUE_GAIN_HIGH 0x3404
+#define REG_BLUE_GAIN_LOW0x3405
+#define REG_AWB_MANUAL 0x3406
+#define REG_EXP_HIGH 0x3500
+#define REG_EXP_MIDDLE 0x3501
+#define REG_EXP_LOW 0x3502
+#define REG_EXP_GAIN_CTRL0x3503
+#define REG_GAIN 0x350b
This belongs to the second patch.
+#define REG_EXTEND_FRAME_TIME_HIGH 0x350c
+#define REG_EXTEND_FRAME_TIME_LOW0x350d
#define REG_WINDOW_START_X_HIGH 0x3800
#define REG_WINDOW_START_X_LOW 0x3801
#define REG_WINDOW_START_Y_HIGH 0x3802
#define REG_WINDOW_START_Y_LOW 0x3803
#define REG_WINDOW_WIDTH_HIGH0x3804
#define REG_WINDOW_WIDTH_LOW 0x3805
-#define REG_WINDOW_HEIGHT_HIGH 0x3806
+#define REG_WINDOW_HEIGHT_HIGH 0x3806
#define REG_WINDOW_HEIGHT_LOW0x3807
#define REG_OUT_WIDTH_HIGH 0x3808
#define REG_OUT_WIDTH_LOW0x3809
@@ -44,19 +58,56 @@
#define REG_OUT_TOTAL_WIDTH_LOW 0x380d
#define REG_OUT_TOTAL_HEIGHT_HIGH0x380e
#define REG_OUT_TOTAL_HEIGHT_LOW 0x380f
+#define REG_FLIP_SUBSAMPLE 0x3818
+#define REG_OUTPUT_FORMAT0x4300
+#define REG_ISP_CTRL_01 0x5001
+#define REG_DIGITAL_EFFECTS 0x5580
+#define REG_HUE_COS 0x5581
+#define REG_HUE_SIN 0x5582
+#define REG_BLUE_SATURATION 0x5583
+#define REG_RED_SATURATION 0x5584
+#define REG_CONTRAST 0x5588
+#define REG_BRIGHTNESS 0x5589
+#define REG_D_E_AUXILLARY0x558a
+#define REG_AVG_WINDOW_END_X_HIGH0x5682
+#define REG_AVG_WINDOW_END_X_LOW 0x5683
+#define REG_AVG_WINDOW_END_Y_HIGH0x5686
+#define REG_AVG_WINDOW_END_Y_LOW 0x5687
So does this.
+
+/* active pixel array size */
+#define OV5642_SENSOR_SIZE_X 2592
+#define OV5642_SENSOR_SIZE_Y 1944
+
+/* current maximum working size */
+#define OV5642_MAX_WIDTH OV5642_SENSOR_SIZE_X
+#define OV5642_MAX_HEIGHT720
+
+/* default sizes */
+#define OV5642_DEFAULT_WIDTH 1280
+#define OV5642_DEFAULT_HEIGHTOV5642_MAX_HEIGHT
+
+/* minimum extra blanking */
+#define BLANKING_EXTRA_WIDTH 500
+#define BLANKING_EXTRA_HEIGHT20
/*
- * define standard resolution.
- * Works currently only for up to 720 lines
- * eg. 320x240, 640x480, 800x600, 1280x720, 2048x720
+ * the sensor's autoexposure is buggy when setting total_height low.
+ * It tries to expose longer than 1 frame period without taking care of it
+ * and this leads to weird output. So we set 1000 lines as minimum.
*/
-#define OV5642_WIDTH 1280
-#define OV5642_HEIGHT720
-#define OV5642_TOTAL_WIDTH 3200
-#define OV5642_TOTAL_HEIGHT 2000
-#define OV5642_SENSOR_SIZE_X 2592
-#define OV5642_SENSOR_SIZE_Y 1944
+#define BLANKING_MIN_HEIGHT 1000
+
+/*
+ * About OV5642 resolution, cropping and binning:
+ * This sensor supports it all, at least in the feature description.
+ * Unfortunately, no combination of appropriate registers settings could
make + * the chip work the intended way. As it works with predefined
register lists, + * some undocumented registers are presumably changed
there to achieve their + * goals.
+ * This driver currently only works for resolutions up to 720 lines with a
+ * 1:1 scale. Hopefully these restrictions will be removed in the future.
+ */
Can you please move this comment above the OV5642_MAX_WIDTH and
OV5642_MAX_HEIGHT definitions ?
struct regval_list {
u16 reg_num;
@@ -105,10 +156,8 @@ static struct regval_list ov5642_default_regs_init[] =
{ { 0x471d, 0x5 },
{ 0x4708, 0x6 },
{ 0x370c, 0xa0 },
- { 0x5687, 0x94 },
Unless I'm mistaken, this register value is removed and isn't replaced by
anything in this patch or the next one. Is that
Re: [PATCH] media: Add camera controls for the ov5642 driver
Hi Bastian,
Thanks for the patch.
On Wednesday 17 August 2011 18:02:07 Bastian Hecht wrote:
The driver now supports automatic/manual gain, automatic/manual white
balance, automatic/manual exposure control, vertical flip, brightness
control, contrast control and saturation control. Additionally the
following effects are available now: rotating the hue in the colorspace,
gray scale image and solarize effect.
Any chance to port soc-camera to the control framework ? :-)
Signed-off-by: Bastian Hecht hec...@gmail.com
---
diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
index 1b40d90..069a720 100644
--- a/drivers/media/video/ov5642.c
+++ b/drivers/media/video/ov5642.c
@@ -74,6 +74,34 @@
#define REG_AVG_WINDOW_END_Y_HIGH0x5686
#define REG_AVG_WINDOW_END_Y_LOW 0x5687
+/* default values in native space */
+#define DEFAULT_RBBALANCE0x400
+#define DEFAULT_CONTRAST 0x20
+#define DEFAULT_SATURATION 0x40
+
+#define MAX_EXP_NATIVE 0x01
+#define MAX_GAIN_NATIVE 0x1f
+#define MAX_RBBALANCE_NATIVE 0x0fff
+#define MAX_EXP 0x
+#define MAX_GAIN 0xff
+#define MAX_RBBALANCE0xff
+#define MAX_HUE_TRIG_NATIVE 0x80
+
+#define OV5642_CONTROL_BLUE_SATURATION (V4L2_CID_PRIVATE_BASE + 0)
+#define OV5642_CONTROL_RED_SATURATION(V4L2_CID_PRIVATE_BASE + 1)
+#define OV5642_CONTROL_GRAY_SCALE(V4L2_CID_PRIVATE_BASE + 2)
+#define OV5642_CONTROL_SOLARIZE (V4L2_CID_PRIVATE_BASE + 3)
If I'm not mistaken V4L2_CID_PRIVATE_BASE is deprecated.
+
+#define EXP_V4L2_TO_NATIVE(x) ((x) 4)
+#define EXP_NATIVE_TO_V4L2(x) ((x) 4)
+#define GAIN_V4L2_TO_NATIVE(x) ((x) * MAX_GAIN_NATIVE / MAX_GAIN)
+#define GAIN_NATIVE_TO_V4L2(x) ((x) * MAX_GAIN / MAX_GAIN_NATIVE)
+#define RBBALANCE_V4L2_TO_NATIVE(x) ((x) * MAX_RBBALANCE_NATIVE /
MAX_RBBALANCE) +#define RBBALANCE_NATIVE_TO_V4L2(x) ((x) * MAX_RBBALANCE /
MAX_RBBALANCE_NATIVE) +
+/* flaw in the datasheet. we need some extra lines */
+#define MANUAL_LONG_EXP_SAFETY_DISTANCE 20
+
/* active pixel array size */
#define OV5642_SENSOR_SIZE_X 2592
#define OV5642_SENSOR_SIZE_Y 1944
[snip]
@@ -804,6 +1013,100 @@ static int ov5642_set_resolution(struct v4l2_subdev
*sd) return ret;
}
+static int ov5642_restore_state(struct v4l2_subdev *sd)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ov5642 *priv = to_ov5642(client);
+ struct v4l2_control set_ctrl;
+ int tmp_red_balance = priv-red_balance;
+ int tmp_blue_balance = priv-blue_balance;
+ int tmp_gain = priv-gain;
+ int tmp_exp = priv-exposure;
+ int ret;
+
+ set_ctrl.id = V4L2_CID_AUTOGAIN;
+ set_ctrl.value = priv-agc;
+ ret = ov5642_s_ctrl(sd, set_ctrl);
What about writing to registers directly ?
+
+ if (!priv-agc) {
+ set_ctrl.id = V4L2_CID_GAIN;
+ set_ctrl.value = tmp_gain;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+ }
+
+ set_ctrl.id = V4L2_CID_AUTO_WHITE_BALANCE;
+ set_ctrl.value = priv-awb;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+
+ if (!priv-awb) {
+ set_ctrl.id = V4L2_CID_RED_BALANCE;
+ set_ctrl.value = tmp_red_balance;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+
+ set_ctrl.id = V4L2_CID_BLUE_BALANCE;
+ set_ctrl.value = tmp_blue_balance;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+ }
+
+ set_ctrl.id = V4L2_CID_EXPOSURE_AUTO;
+ set_ctrl.value = priv-aec;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+
+ if (priv-aec == V4L2_EXPOSURE_MANUAL) {
+ set_ctrl.id = V4L2_CID_EXPOSURE;
+ set_ctrl.value = tmp_exp;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+ }
+
+ set_ctrl.id = V4L2_CID_VFLIP;
+ set_ctrl.value = priv-vflip;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+
+ set_ctrl.id = OV5642_CONTROL_GRAY_SCALE;
+ set_ctrl.value = priv-grayscale;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+
+ set_ctrl.id = OV5642_CONTROL_SOLARIZE;
+ set_ctrl.value = priv-solarize;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+
+ set_ctrl.id = OV5642_CONTROL_BLUE_SATURATION;
+ set_ctrl.value = priv-blue_saturation;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+
+ set_ctrl.id = OV5642_CONTROL_RED_SATURATION;
+ set_ctrl.value = priv-red_saturation;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+
+ set_ctrl.id = V4L2_CID_BRIGHTNESS;
+ set_ctrl.value = priv-brightness;
+
Re: [PATCH] media i.MX27 camera: remove legacy dma support
Hi Guennadi,
On Wed, Aug 24, 2011 at 09:19:24AM +0200, Guennadi Liakhovetski wrote:
[snip]
On Wed, 24 Aug 2011, Sascha Hauer wrote:
The i.MX27 dma support was introduced with the initial commit of
this driver and originally created by me. However, I never got
this stable due to the racy dma engine and used the EMMA engine
instead. As the DMA support is most probably unused and broken in
its current state, remove it. This also helps us to get rid of
another user of the legacy i.MX DMA support,
Also, remove the dependency on ARCH_MX* macros as these are scheduled
for removal.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Cc: Baruch Siach bar...@tkos.co.il
Cc: linux-media@vger.kernel.org
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
[snip]
Baruch, any comment?
No comment so far. Thanks for your continued maintenance. I wish I could do
the videobuf2 migration of this driver.
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DiBxxxx: fixes for 3.1/3.0
Hi, Patrick Boettcher wrote: On Wed, 3 Aug 2011, Patrick Boettcher wrote: [media] dib0700: protect the dib0700 buffer access [media] DiBcom: protect the I2C bufer access I added a patch from Olivier which fixes wrongly used dprintks and replaces them by err()-calls. [media] dib0700: correct error message Just for the record[1]: Tested-by: Eric Valette eric.vale...@free.fr Thanks! [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639161#22 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7 v5] V4L: vb2: add support for buffers of different sizes on a single queue
Hi Guennadi,
On Wed, Aug 24, 2011 at 11:41, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
The two recently added ioctl()s VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF
allow user-space applications to allocate video buffers of different
sizes and hand them over to the driver for fast switching between
different frame formats. This patch adds support for buffers of different
sizes on the same buffer-queue to vb2.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Pawel Osciak pa...@osciak.com
Cc: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/videobuf2-core.c | 278
--
include/media/videobuf2-core.h | 31 +++--
2 files changed, 252 insertions(+), 57 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 8a81a89..fed6f2d 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
snip
@@ -454,7 +465,7 @@ static bool __buffers_in_use(struct vb2_queue *q)
*/
int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req)
{
- unsigned int num_buffers, num_planes;
+ unsigned int num_buffers, allocated_buffers, num_planes = 0;
unsigned long plane_sizes[VIDEO_MAX_PLANES];
int ret = 0;
@@ -503,7 +514,7 @@ int vb2_reqbufs(struct vb2_queue *q, struct
v4l2_requestbuffers *req)
return -EBUSY;
}
- __vb2_queue_free(q);
+ __vb2_queue_free(q, q-num_buffers);
/*
* In case of REQBUFS(0) return immediately without calling
@@ -538,44 +549,166 @@ int vb2_reqbufs(struct vb2_queue *q, struct
v4l2_requestbuffers *req)
return -ENOMEM;
}
+ allocated_buffers = ret;
+
/*
* Check if driver can handle the allocated number of buffers.
*/
- if (ret num_buffers) {
- unsigned int orig_num_buffers;
+ if (allocated_buffers num_buffers) {
+ num_buffers = allocated_buffers;
- orig_num_buffers = num_buffers = ret;
ret = call_qop(q, queue_setup, q, NULL, num_buffers,
num_planes, plane_sizes, q-alloc_ctx);
- if (ret)
- goto free_mem;
- if (orig_num_buffers num_buffers) {
+ if (!ret allocated_buffers num_buffers)
ret = -ENOMEM;
- goto free_mem;
- }
/*
- * Ok, driver accepted smaller number of buffers.
+ * Either the driver has accepted a smaller number of buffers,
+ * or .queue_setup() returned an error
*/
- ret = num_buffers;
+ }
+
+ q-num_buffers = allocated_buffers;
+
+ if (ret 0) {
+ __vb2_queue_free(q, allocated_buffers);
+ return ret;
}
/*
* Return the number of successfully allocated buffers
* to the userspace.
*/
- req-count = ret;
+ req-count = allocated_buffers;
return 0;
-
-free_mem:
- __vb2_queue_free(q);
- return ret;
}
EXPORT_SYMBOL_GPL(vb2_reqbufs);
/**
+ * vb2_create_bufs() - Allocate buffers and any required auxiliary structs
+ * @q: videobuf2 queue
+ * @create: creation parameters, passed from userspace to
vidioc_create_bufs
+ * handler in driver
+ *
+ * Should be called from vidioc_create_bufs ioctl handler of a driver.
+ * This function:
+ * 1) verifies parameter sanity
+ * 2) calls the .queue_setup() queue operation
+ * 3) performs any necessary memory allocations
+ *
+ * The return values from this function are intended to be directly returned
+ * from vidioc_create_bufs handler in driver.
+ */
+int vb2_create_bufs(struct vb2_queue *q, struct v4l2_create_buffers *create)
+{
+ unsigned int num_planes, num_buffers = create-count,
allocated_buffers;
+ unsigned long plane_sizes[VIDEO_MAX_PLANES];
+ int ret = 0;
+
+ if (q-fileio) {
+ dprintk(1, %s(): file io in progress\n, __func__);
+ return -EBUSY;
+ }
+
+ if (create-memory != V4L2_MEMORY_MMAP
+ create-memory != V4L2_MEMORY_USERPTR) {
+ dprintk(1, %s(): unsupported memory type\n, __func__);
+ return -EINVAL;
+ }
+
+ if (create-format.type != q-type) {
+ dprintk(1, %s(): requested type is incorrect\n, __func__);
+ return -EINVAL;
+ }
+
+ /*
+ * Make sure all the required memory ops
AVerMedia HC82R Hybrid NanoExpress (saa716x)
Hi, [I'm not subscribed to this list.] The AVerMedia HC82R AVerTV Hybrid NanoExpress is a hybrid analogue/DVB-T ExpressCard with A/V input. I have a Dell OEM version of this card, which has PCI vendor:product ID 1131:7160, subsystem 1461:0555. The current saa716x source from http://jusst.de/hg/saa716x doesn't recognise it because its subsystem ID differs from the normal HC82R value (1461:2355). For my card: $ lspci -vvv -nn -d1131:7160 05:00.0 Multimedia controller [0480]: Philips Semiconductors Device [1131:7160] (rev 03) Subsystem: Avermedia Technologies Inc Device [1461:0555] ... For testing, I changed a line in saa716x_hybrid.h from #define AVERMEDIA_HC82 0x2355 to #define AVERMEDIA_HC82 0x0555 and with that change my card was recognised when inserted. Maybe someone would like to write a patch to add support for the alternate subsystem ID? Mark -- 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
usb_set_intfdata usage for two subdrivers
I am trying to implement DVB USB device smartcard reader support using USB-serial. The main problem is now that both DVB-USB and USB-serial uses interface data (usb_set_intfdata / usb_get_intfdata) for state. Is there any common solution to resolve issue easily? regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 3/3] fbdev: sh_mobile_lcdc: Support FOURCC-based format API
On Fri, Aug 19, 2011 at 6:37 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- arch/arm/mach-shmobile/board-ag5evm.c | 2 +- arch/arm/mach-shmobile/board-ap4evb.c | 4 +- arch/arm/mach-shmobile/board-mackerel.c | 4 +- drivers/video/sh_mobile_lcdcfb.c | 342 --- include/video/sh_mobile_lcdc.h | 4 +- 5 files changed, 230 insertions(+), 126 deletions(-) Hi Laurent, thanks for the patch! Since you're changing the LCDC platform data please make sure you also update the 5 boards using the LCDC under arch/sh. Thanks, / magnus -- 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: usb_set_intfdata usage for two subdrivers
On Mon, Aug 29, 2011 at 02:30:26AM +0300, Antti Palosaari wrote: I am trying to implement DVB USB device smartcard reader support using USB-serial. Really? Why? That doesn't seem to make sense, please explain more. The main problem is now that both DVB-USB and USB-serial uses interface data (usb_set_intfdata / usb_get_intfdata) for state. Is there any common solution to resolve issue easily? No two drivers can bind to the same USB interface, so of course they would interfere. Care to explain the problem in more detail to see if there is a better way to do all of this? greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: VIDEO_OMAP2_VOUT broken
-Original Message- From: Valkeinen, Tomi Sent: Sunday, August 28, 2011 9:52 PM To: Arnd Bergmann Cc: linux-media@vger.kernel.org; JAIN, AMBER; Hiremath, Vaibhav; Taneja, Archit Subject: Re: VIDEO_OMAP2_VOUT broken Hi Arnd, On Sat, Aug 27, 2011 at 11:58 PM, Arnd Bergmann a...@arndb.de wrote: Hi Tomi, Apparently your patch 8cff88c5d OMAP: DSS2: remove update_mode from omapdss broke building the omap_vout driver: Yes, I didn't realize it affects v4l2, and I didn't have v4l2 enabled in the kernel. I have it now enabled by default =). There was a patch posted to linux-omap and to linux-media by Archit some weeks ago which fixes the issue. I guess it hasn't gotten into mainline yet: [PATCH] [media] OMAP_VOUT: Fix build break caused by update_mode removal in DSS2 [Hiremath, Vaibhav] It's because of me I have already queued it in my branch but could not able to give pull request in time. Sorry for that, doing it now... Thanks, Vaibhav Tomi -- 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
