[PATCH v3] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/media
From: Philipp Zabel philipp.za...@gmail.com
This patch moves the parsing helpers used to parse connected graphs
in the device tree, like the video interface bindings documented in
Documentation/devicetree/bindings/media/video-interfaces.txt, from
drivers/media/v4l2-core to drivers/media.
This allows to reuse the same parser code from outside the V4L2
framework, most importantly from display drivers.
The functions v4l2_of_get_next_endpoint, v4l2_of_get_remote_port,
and v4l2_of_get_remote_port_parent are moved. They are renamed to
of_graph_get_next_endpoint, of_graph_get_remote_port, and
of_graph_get_remote_port_parent, respectively.
Since there are not that many current users yet, switch all of
them to the new functions right away.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Acked-by: Mauro Carvalho Chehab m.che...@samsung.com
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Changes since v2:
- Removed CONFIG_OF_GRAPH option, helpers are compiled in when
CONFIG_OF is enabled.
---
drivers/media/Makefile| 2 +
drivers/media/i2c/adv7343.c | 4 +-
drivers/media/i2c/mt9p031.c | 4 +-
drivers/media/i2c/s5k5baf.c | 3 +-
drivers/media/i2c/tvp514x.c | 3 +-
drivers/media/i2c/tvp7002.c | 3 +-
drivers/media/of_graph.c | 133 ++
drivers/media/platform/exynos4-is/fimc-is.c | 6 +-
drivers/media/platform/exynos4-is/media-dev.c | 3 +-
drivers/media/platform/exynos4-is/mipi-csis.c | 3 +-
drivers/media/v4l2-core/v4l2-of.c | 117 --
include/media/of_graph.h | 46 +
include/media/v4l2-of.h | 24 -
13 files changed, 198 insertions(+), 153 deletions(-)
create mode 100644 drivers/media/of_graph.c
create mode 100644 include/media/of_graph.h
diff --git a/drivers/media/Makefile b/drivers/media/Makefile
index 620f275..0341472 100644
--- a/drivers/media/Makefile
+++ b/drivers/media/Makefile
@@ -18,6 +18,8 @@ ifeq ($(CONFIG_MEDIA_CONTROLLER),y)
obj-$(CONFIG_MEDIA_SUPPORT) += media.o
endif
+obj-$(CONFIG_OF) += of_graph.o
+
obj-$(CONFIG_VIDEO_DEV) += v4l2-core/
obj-$(CONFIG_DVB_CORE) += dvb-core/
diff --git a/drivers/media/i2c/adv7343.c b/drivers/media/i2c/adv7343.c
index d4e15a6..74a1507 100644
--- a/drivers/media/i2c/adv7343.c
+++ b/drivers/media/i2c/adv7343.c
@@ -28,10 +28,10 @@
#include linux/of.h
#include media/adv7343.h
+#include media/of_graph.h
#include media/v4l2-async.h
#include media/v4l2-device.h
#include media/v4l2-ctrls.h
-#include media/v4l2-of.h
#include adv7343_regs.h
@@ -410,7 +410,7 @@ adv7343_get_pdata(struct i2c_client *client)
if (!IS_ENABLED(CONFIG_OF) || !client-dev.of_node)
return client-dev.platform_data;
- np = v4l2_of_get_next_endpoint(client-dev.of_node, NULL);
+ np = of_graph_get_next_endpoint(client-dev.of_node, NULL);
if (!np)
return NULL;
diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c
index e5ddf47..60f36dc 100644
--- a/drivers/media/i2c/mt9p031.c
+++ b/drivers/media/i2c/mt9p031.c
@@ -27,9 +27,9 @@
#include linux/videodev2.h
#include media/mt9p031.h
+#include media/of_graph.h
#include media/v4l2-ctrls.h
#include media/v4l2-device.h
-#include media/v4l2-of.h
#include media/v4l2-subdev.h
#include aptina-pll.h
@@ -943,7 +943,7 @@ mt9p031_get_pdata(struct i2c_client *client)
if (!IS_ENABLED(CONFIG_OF) || !client-dev.of_node)
return client-dev.platform_data;
- np = v4l2_of_get_next_endpoint(client-dev.of_node, NULL);
+ np = of_graph_get_next_endpoint(client-dev.of_node, NULL);
if (!np)
return NULL;
diff --git a/drivers/media/i2c/s5k5baf.c b/drivers/media/i2c/s5k5baf.c
index 77e10e0..06261ee 100644
--- a/drivers/media/i2c/s5k5baf.c
+++ b/drivers/media/i2c/s5k5baf.c
@@ -25,6 +25,7 @@
#include linux/slab.h
#include media/media-entity.h
+#include media/of_graph.h
#include media/v4l2-ctrls.h
#include media/v4l2-device.h
#include media/v4l2-subdev.h
@@ -1855,7 +1856,7 @@ static int s5k5baf_parse_device_node(struct s5k5baf
*state, struct device *dev)
if (ret 0)
return ret;
- node_ep = v4l2_of_get_next_endpoint(node, NULL);
+ node_ep = of_graph_get_next_endpoint(node, NULL);
if (!node_ep) {
dev_err(dev, no endpoint defined at node %s\n,
node-full_name);
diff --git a/drivers/media/i2c/tvp514x.c b/drivers/media/i2c/tvp514x.c
index 83d85df..50062d2 100644
--- a/drivers/media/i2c/tvp514x.c
+++ b/drivers/media/i2c/tvp514x.c
@@ -37,6 +37,7 @@
#include linux/v4l2-mediabus.h
#include linux/of.h
+#include media/of_graph.h
#include media/v4l2-async.h
#include media/v4l2-device.h
#include media/v4l2-common.h
@@ -1068,7 +1069,7 @@
[RFC v3,1/3] v4l2-controls.h: add addtional Flash fault bits
Add addtional falult bits for FLASH
V4L2_FLASH_FAULT_UNDER_VOLTAGE : UVLO
V4L2_FLASH_FAULT_INPUT_VOLTAGE : input voltage is adjusted by IVFM
V4L2_FLASH_FAULT_LED_OVER_TEMPERATURE : NTC Trip point is crossed.
Signed-off-by: Daniel Jeong gshark.je...@gmail.com
---
include/uapi/linux/v4l2-controls.h |3 +++
1 file changed, 3 insertions(+)
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 2cbe605..1d662f6 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -812,6 +812,9 @@ enum v4l2_flash_strobe_source {
#define V4L2_FLASH_FAULT_SHORT_CIRCUIT (1 3)
#define V4L2_FLASH_FAULT_OVER_CURRENT (1 4)
#define V4L2_FLASH_FAULT_INDICATOR (1 5)
+#define V4L2_FLASH_FAULT_UNDER_VOLTAGE (1 6)
+#define V4L2_FLASH_FAULT_INPUT_VOLTAGE (1 7)
+#define V4L2_FLASH_FAULT_LED_OVER_TEMPERATURE (1 8)
#define V4L2_CID_FLASH_CHARGE (V4L2_CID_FLASH_CLASS_BASE + 11)
#define V4L2_CID_FLASH_READY (V4L2_CID_FLASH_CLASS_BASE + 12)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v3,2/3] controls.xml : add addtional Flash fault bits
Add addtional falult bits for FLASH V4L2_FLASH_FAULT_UNDER_VOLTAGE : UVLO V4L2_FLASH_FAULT_INPUT_VOLTAGE : input voltage is adjusted by IVFM V4L2_FLASH_FAULT_LED_OVER_TEMPERATURE : NTC Trip point is crossed. Signed-off-by: Daniel Jeong gshark.je...@gmail.com --- Documentation/DocBook/media/v4l/controls.xml | 16 1 file changed, 16 insertions(+) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index a5a3188..8121f7e 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -4370,6 +4370,22 @@ interface and may change in the future./para entryThe flash controller has detected a short or open circuit condition on the indicator LED./entry /row + row + entryconstantV4L2_FLASH_FAULT_UNDER_VOLTAGE/constant/entry + entryFlash controller voltage to the flash LED + has been below the minimum limit specific to the flash + controller./entry + /row + row + entryconstantV4L2_FLASH_FAULT_INPUT_VOLTAGE/constant/entry + entryThe flash controller has detected adjustment of input + voltage by Input Volage Flash Monitor(IVFM)./entry + /row + row + entryconstantV4L2_FLASH_FAULT_LED_OVER_TEMPERATURE/constant/entry + entryThe flash controller has detected that TEMP input has + crossed NTC Trip Voltage./entry + /row /tbody /entrytbl /row -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v3,3/3] media: i2c: add new dual LED Flash driver, lm3646
Add new dual flash driver.
Fixed the previous issues and added device tree support.
Signed-off-by: Daniel Jeong gshark.je...@gmail.com
---
drivers/media/i2c/Kconfig |9 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/lm3646.c | 451
include/media/lm3646.h | 87 +
4 files changed, 548 insertions(+)
create mode 100644 drivers/media/i2c/lm3646.c
create mode 100644 include/media/lm3646.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 4aa9c53..c7f2823 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -629,6 +629,15 @@ config VIDEO_LM3560
This is a driver for the lm3560 dual flash controllers. It controls
flash, torch LEDs.
+config VIDEO_LM3646
+ tristate LM3646 dual flash driver support
+ depends on I2C VIDEO_V4L2 MEDIA_CONTROLLER
+ depends on MEDIA_CAMERA_SUPPORT
+ select REGMAP_I2C
+ ---help---
+ This is a driver for the lm3646 dual flash controllers. It controls
+ flash, torch LEDs.
+
comment Video improvement chips
config VIDEO_UPD64031A
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 4ae..01b6bfc 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_VIDEO_S5C73M3) += s5c73m3/
obj-$(CONFIG_VIDEO_ADP1653)+= adp1653.o
obj-$(CONFIG_VIDEO_AS3645A)+= as3645a.o
obj-$(CONFIG_VIDEO_LM3560) += lm3560.o
+obj-$(CONFIG_VIDEO_LM3646) += lm3646.o
obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
diff --git a/drivers/media/i2c/lm3646.c b/drivers/media/i2c/lm3646.c
new file mode 100644
index 000..388ffe9
--- /dev/null
+++ b/drivers/media/i2c/lm3646.c
@@ -0,0 +1,451 @@
+/*
+ * drivers/media/i2c/lm3646.c
+ * General device driver for TI lm3646, Dual FLASH LED Driver
+ *
+ * Copyright (C) 2014 Texas Instruments
+ *
+ * Contact: Daniel Jeong gshark.je...@gmail.com
+ * Ldd-Mlp ldd-...@list.ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/module.h
+#include linux/i2c.h
+#include linux/slab.h
+#include linux/regmap.h
+#include linux/videodev2.h
+#include media/lm3646.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-device.h
+
+/* registers definitions */
+#define REG_ENABLE 0x01
+#define REG_TORCH_BR 0x05
+#define REG_FLASH_BR 0x05
+#define REG_FLASH_TOUT 0x04
+#define REG_FLAG 0x08
+#define REG_STROBE_SRC 0x06
+#define REG_LED1_FLASH_BR 0x06
+#define REG_LED1_TORCH_BR 0x07
+
+#define MASK_ENABLE0x03
+#define MASK_TORCH_BR 0x70
+#define MASK_FLASH_BR 0x0F
+#define MASK_FLASH_TOUT0x07
+#define MASK_FLAG 0xFF
+#define MASK_STROBE_SRC0x80
+
+/* Fault Mask */
+#define FAULT_TIMEOUT (10)
+#define FAULT_SHORT_CIRCUIT(11)
+#define FAULT_UVLO (12)
+#define FAULT_IVFM (13)
+#define FAULT_OCP (14)
+#define FAULT_OVERTEMP (15)
+#define FAULT_NTC_TRIP (16)
+#define FAULT_OVP (17)
+
+enum led_mode {
+ MODE_SHDN = 0x0,
+ MODE_TORCH = 0x2,
+ MODE_FLASH = 0x3,
+};
+
+/*
+ * struct lm3646_flash
+ *
+ * @pdata: platform data
+ * @regmap: reg. map for i2c
+ * @lock: muxtex for serial access.
+ * @led_mode: V4L2 LED mode
+ * @ctrls_led: V4L2 contols
+ * @subdev_led: V4L2 subdev
+ */
+struct lm3646_flash {
+ struct device *dev;
+ struct lm3646_platform_data *pdata;
+ struct regmap *regmap;
+
+ struct v4l2_ctrl_handler ctrls_led;
+ struct v4l2_subdev subdev_led;
+};
+
+#define to_lm3646_flash(_ctrl) \
+ container_of(_ctrl-handler, struct lm3646_flash, ctrls_led)
+
+/* enable mode control */
+static int lm3646_mode_ctrl(struct lm3646_flash *flash,
+ enum v4l2_flash_led_mode led_mode)
+{
+ int rval = -EINVAL;
+
+ switch (led_mode) {
+ case V4L2_FLASH_LED_MODE_NONE:
+ rval = regmap_update_bits(flash-regmap,
+ REG_ENABLE, MASK_ENABLE, MODE_SHDN);
+ break;
+ case V4L2_FLASH_LED_MODE_TORCH:
+ rval = regmap_update_bits(flash-regmap,
+ REG_ENABLE, MASK_ENABLE, MODE_TORCH);
+ break;
+ case V4L2_FLASH_LED_MODE_FLASH:
+ rval = regmap_update_bits(flash-regmap,
+ REG_ENABLE, MASK_ENABLE, MODE_FLASH);
+ break;
+ }
+ return rval;
+}
+
+/* V4L2 controls */
+static int lm3646_get_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct lm3646_flash *flash = to_lm3646_flash(ctrl);
+ int rval = -EINVAL;
+
+
Re: [RFCv3 PATCH 05/10] vb2: fix buf_init/buf_cleanup call sequences
Hi Pawel,
Thanks for the review!
On 02/14/2014 05:40 AM, Pawel Osciak wrote:
On Thu, Feb 13, 2014 at 6:40 PM, Hans Verkuil hverk...@xs4all.nl wrote:
From: Hans Verkuil hans.verk...@cisco.com
Ensure that these ops are properly balanced.
There two scenarios:
s/There two/There are two/
1) for MMAP buf_init is called when the buffers are created and buf_cleanup
must be called when the queue is finally freed. This scenario was always
working.
2) for USERPTR and DMABUF it is more complicated. When a buffer is queued
the code checks if all planes of this buffer have been acquired before.
If that's the case, then only buf_prepare has to be called. Otherwise
buf_clean needs to be called if the buffer was acquired before, then,
s/buf_clean/buf_cleanup/
once all changed planes have been (re)acquired, buf_init has to be
called again followed by buf_prepare. Should buf_prepare fail, then
s/again//
I know what you mean, but there is only one call to buf_init in this
particular sequence.
buf_cleanup must be called again because all planes will be released
s/again because all planes will be released/on the newly acquired
planes to release them/
in case of an error.
Finally, in __vb2_queue_free we have to check if the buffer was actually
acquired before calling buf_cleanup. While that it always true for MMAP
mode, it is not necessarily true for the other modes. E.g. if you just
call REQBUFS and close the filehandle, then buffers were ever queued and
s/ever/never/
s/filehandle/file handle/
Thanks for spell-checking my commit log! That's slightly embarrassing...
so no buf_init was ever called.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/videobuf2-core.c | 100
+--
1 file changed, 67 insertions(+), 33 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 3756378..7766bf5 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -373,8 +373,10 @@ static int __vb2_queue_free(struct vb2_queue *q,
unsigned int buffers)
/* Call driver-provided cleanup function for each buffer, if
provided */
for (buffer = q-num_buffers - buffers; buffer q-num_buffers;
++buffer) {
- if (q-bufs[buffer])
- call_vb_qop(q-bufs[buffer], buf_cleanup,
q-bufs[buffer]);
+ struct vb2_buffer *vb = q-bufs[buffer];
+
+ if (vb vb-planes[0].mem_priv)
+ call_vb_qop(vb, buf_cleanup, vb);
}
/* Release video buffer memory */
@@ -1161,6 +1163,7 @@ static int __qbuf_userptr(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
unsigned int plane;
int ret;
int write = !V4L2_TYPE_IS_OUTPUT(q-type);
+ bool reacquired = vb-planes[0].mem_priv == NULL;
This requires a comment I feel. In general, I'm not especially happy
with the fact that we are making mem_priv != NULL equivalent to
buf_init() called and succeeded. It is true right now, but it'll be
very hard to make the association without previously seeing this very
patch I feel.
I don't see a perfect way to do this, but I'm strongly leaning towards
having a bool inited in the vb2_buffer. Really.
I agree that it isn't all that great how it is done today. However, I would like
to postpone changing this. Mostly because I do not feel all that confident yet
changing it :-)
I like to do some more testing first, especially with dma-buf.
/* Copy relevant information provided by the userspace */
__fill_vb2_buffer(vb, b, planes);
@@ -1186,12 +1189,16 @@ static int __qbuf_userptr(struct vb2_buffer *vb,
const struct v4l2_buffer *b)
}
/* Release previously acquired memory if present */
- if (vb-planes[plane].mem_priv)
+ if (vb-planes[plane].mem_priv) {
+ if (!reacquired) {
+ reacquired = true;
+ call_vb_qop(vb, buf_cleanup, vb);
+ }
call_memop(vb, put_userptr,
vb-planes[plane].mem_priv);
+ }
vb-planes[plane].mem_priv = NULL;
- vb-v4l2_planes[plane].m.userptr = 0;
- vb-v4l2_planes[plane].length = 0;
+ memset(vb-v4l2_planes[plane], 0, sizeof(struct
v4l2_plane));
/* Acquire each plane's memory */
mem_priv = call_memop(vb, get_userptr, q-alloc_ctx[plane],
@@ -1208,23 +1215,34 @@ static int __qbuf_userptr(struct vb2_buffer *vb,
const struct v4l2_buffer *b)
}
/*
-* Call driver-specific initialization on the newly acquired buffer,
-* if provided.
-*/
- ret = call_vb_qop(vb, buf_init, vb);
Re: [RFCv3 PATCH 06/10] vb2: fix read/write regression
On 02/14/2014 05:49 AM, Pawel Osciak wrote:
On Thu, Feb 13, 2014 at 6:40 PM, Hans Verkuil hverk...@xs4all.nl wrote:
From: Hans Verkuil hans.verk...@cisco.com
Commit 88e268702bfba78448abd20a31129458707383aa (vb2: Improve file I/O
emulation to handle buffers in any order) broke read/write support if
the size of the buffer being read/written is less than the size of the
image.
When the commit was tested originally I used qv4l2, which call read()
with exactly the size of the image. But if you try 'cat /dev/video0'
then it will fail and typically hang after reading two buffers.
This patch fixes the behavior by adding a new buf_index field that
contains the index of the field currently being filled/read, or it
is num_buffers in which case a new buffer needs to be dequeued.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Cc: Andy Walls awa...@md.metrocast.net
---
drivers/media/v4l2-core/videobuf2-core.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 7766bf5..a3b4b4c 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2418,6 +2418,7 @@ struct vb2_fileio_data {
struct v4l2_requestbuffers req;
struct v4l2_buffer b;
struct vb2_fileio_buf bufs[VIDEO_MAX_FRAME];
+ unsigned int buf_index;
unsigned int index;
The two index fields are now confusing, especially because there is no
documentation. Perhaps we could call index cur_index and also add
documentation please?
I agree, I'll post an updated version today.
Regards,
Hans
unsigned int q_count;
unsigned int dq_count;
@@ -2519,6 +2520,7 @@ static int __vb2_init_fileio(struct vb2_queue *q, int
read)
fileio-bufs[i].queued = 1;
}
fileio-index = q-num_buffers;
+ fileio-buf_index = q-num_buffers;
}
/*
@@ -2597,7 +2599,7 @@ static size_t __vb2_perform_fileio(struct vb2_queue
*q, char __user *data, size_
/*
* Check if we need to dequeue the buffer.
*/
- index = fileio-index;
+ index = fileio-buf_index;
if (index = q-num_buffers) {
/*
* Call vb2_dqbuf to get buffer back.
@@ -2611,7 +2613,7 @@ static size_t __vb2_perform_fileio(struct vb2_queue
*q, char __user *data, size_
return ret;
fileio-dq_count += 1;
- index = fileio-b.index;
+ fileio-buf_index = index = fileio-b.index;
buf = fileio-bufs[index];
/*
@@ -2689,6 +2691,7 @@ static size_t __vb2_perform_fileio(struct vb2_queue
*q, char __user *data, size_
fileio-q_count += 1;
if (fileio-index q-num_buffers)
fileio-index++;
+ fileio-buf_index = fileio-index;
}
/*
--
1.8.4.rc3
--
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: [RFCv3 PATCH 08/10] vb2: only call start_streaming if sufficient buffers are queued
On 02/14/2014 06:13 AM, Pawel Osciak wrote:
On Thu, Feb 13, 2014 at 6:40 PM, Hans Verkuil hverk...@xs4all.nl wrote:
From: Hans Verkuil hans.verk...@cisco.com
In commit 02f142ecd24aaf891324ffba8527284c1731b561 support was added to
start_streaming to return -ENOBUFS if insufficient buffers were queued
for the DMA engine to start. The vb2 core would attempt calling
start_streaming again if another buffer would be queued up.
Later analysis uncovered problems with the queue management if
start_streaming
would return an error: the buffers are enqueued to the driver before the
start_streaming op is called, so after an error they are never returned to
the vb2 core. The solution for this is to let the driver return them to
the vb2 core in case of an error while starting the DMA engine. However,
in the case of -ENOBUFS that would be weird: it is not a real error, it
just says that more buffers are needed. Requiring start_streaming to give
them back only to have them requeued again the next time the application
calls QBUF is inefficient.
This patch changes this mechanism: it adds a 'min_buffers_needed' field
to vb2_queue that drivers can set with the minimum number of buffers
required to start the DMA engine. The start_streaming op is only called
if enough buffers are queued. The -ENOBUFS handling has been dropped in
favor of this new method.
Drivers are expected to return buffers back to vb2 core with state QUEUED
if start_streaming would return an error. The vb2 core checks for this
and produces a warning if that didn't happen and it will forcefully
reclaim such buffers to ensure that the internal vb2 core state remains
consistent and all buffer-related resources have been correctly freed
and all op callss have been balanced.
s/callss/calls/
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/davinci/vpbe_display.c | 6 +-
drivers/media/platform/davinci/vpif_capture.c | 7 +-
drivers/media/platform/davinci/vpif_display.c | 7 +-
drivers/media/platform/s5p-tv/mixer_video.c | 6 +-
drivers/media/v4l2-core/videobuf2-core.c| 130
drivers/staging/media/davinci_vpfe/vpfe_video.c | 3 +-
include/media/videobuf2-core.h | 14 ++-
7 files changed, 100 insertions(+), 73 deletions(-)
diff --git a/drivers/media/platform/davinci/vpbe_display.c
b/drivers/media/platform/davinci/vpbe_display.c
index b02aba4..9231e48 100644
--- a/drivers/media/platform/davinci/vpbe_display.c
+++ b/drivers/media/platform/davinci/vpbe_display.c
@@ -344,11 +344,6 @@ static int vpbe_start_streaming(struct vb2_queue *vq,
unsigned int count)
struct vpbe_device *vpbe_dev = fh-disp_dev-vpbe_dev;
int ret;
- /* If buffer queue is empty, return error */
- if (list_empty(layer-dma_queue)) {
- v4l2_err(vpbe_dev-v4l2_dev, buffer queue is empty\n);
- return -ENOBUFS;
- }
/* Get the next frame from the buffer queue */
layer-next_frm = layer-cur_frm = list_entry(layer-dma_queue.next,
struct vpbe_disp_buffer, list);
@@ -1416,6 +1411,7 @@ static int vpbe_display_reqbufs(struct file *file,
void *priv,
q-mem_ops = vb2_dma_contig_memops;
q-buf_struct_size = sizeof(struct vpbe_disp_buffer);
q-timestamp_type = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
+ q-min_buffers_needed = 1;
ret = vb2_queue_init(q);
if (ret) {
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index 735ec47..9731ad4 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -272,13 +272,7 @@ static int vpif_start_streaming(struct vb2_queue *vq,
unsigned int count)
unsigned long flags;
int ret;
- /* If buffer queue is empty, return error */
spin_lock_irqsave(common-irqlock, flags);
- if (list_empty(common-dma_queue)) {
- spin_unlock_irqrestore(common-irqlock, flags);
- vpif_dbg(1, debug, buffer queue is empty\n);
- return -ENOBUFS;
- }
/* Get the next frame from the buffer queue */
common-cur_frm = common-next_frm =
list_entry(common-dma_queue.next,
@@ -1024,6 +1018,7 @@ static int vpif_reqbufs(struct file *file, void *priv,
q-mem_ops = vb2_dma_contig_memops;
q-buf_struct_size = sizeof(struct vpif_cap_buffer);
q-timestamp_type = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
+ q-min_buffers_needed = 1;
ret = vb2_queue_init(q);
if (ret) {
diff --git a/drivers/media/platform/davinci/vpif_display.c
b/drivers/media/platform/davinci/vpif_display.c
index 9d115cd..af660f5 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -234,13 +234,7 @@ static
Re: [RFC v3,3/3] media: i2c: add new dual LED Flash driver, lm3646
On Fri, 2014-02-14 at 18:46 +0900, Daniel Jeong wrote:
Add new dual flash driver.
Fixed the previous issues and added device tree support.
Signed-off-by: Daniel Jeong gshark.je...@gmail.com
---
drivers/media/i2c/Kconfig |9 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/lm3646.c | 451
include/media/lm3646.h | 87 +
4 files changed, 548 insertions(+)
create mode 100644 drivers/media/i2c/lm3646.c
create mode 100644 include/media/lm3646.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 4aa9c53..c7f2823 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -629,6 +629,15 @@ config VIDEO_LM3560
This is a driver for the lm3560 dual flash controllers. It controls
flash, torch LEDs.
+config VIDEO_LM3646
+ tristate LM3646 dual flash driver support
+ depends on I2C VIDEO_V4L2 MEDIA_CONTROLLER
+ depends on MEDIA_CAMERA_SUPPORT
+ select REGMAP_I2C
+ ---help---
+ This is a driver for the lm3646 dual flash controllers. It controls
+ flash, torch LEDs.
+
comment Video improvement chips
config VIDEO_UPD64031A
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 4ae..01b6bfc 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_VIDEO_S5C73M3) += s5c73m3/
obj-$(CONFIG_VIDEO_ADP1653) += adp1653.o
obj-$(CONFIG_VIDEO_AS3645A) += as3645a.o
obj-$(CONFIG_VIDEO_LM3560) += lm3560.o
+obj-$(CONFIG_VIDEO_LM3646) += lm3646.o
obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
diff --git a/drivers/media/i2c/lm3646.c b/drivers/media/i2c/lm3646.c
new file mode 100644
index 000..388ffe9
--- /dev/null
+++ b/drivers/media/i2c/lm3646.c
@@ -0,0 +1,451 @@
+/*
+ * drivers/media/i2c/lm3646.c
+ * General device driver for TI lm3646, Dual FLASH LED Driver
+ *
+ * Copyright (C) 2014 Texas Instruments
+ *
+ * Contact: Daniel Jeong gshark.je...@gmail.com
+ * Ldd-Mlp ldd-...@list.ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/module.h
+#include linux/i2c.h
+#include linux/slab.h
+#include linux/regmap.h
+#include linux/videodev2.h
+#include media/lm3646.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-device.h
+
+/* registers definitions */
+#define REG_ENABLE 0x01
+#define REG_TORCH_BR 0x05
+#define REG_FLASH_BR 0x05
+#define REG_FLASH_TOUT 0x04
+#define REG_FLAG 0x08
+#define REG_STROBE_SRC 0x06
+#define REG_LED1_FLASH_BR 0x06
+#define REG_LED1_TORCH_BR 0x07
+
+#define MASK_ENABLE 0x03
+#define MASK_TORCH_BR0x70
+#define MASK_FLASH_BR0x0F
+#define MASK_FLASH_TOUT 0x07
+#define MASK_FLAG0xFF
+#define MASK_STROBE_SRC 0x80
+
+/* Fault Mask */
+#define FAULT_TIMEOUT(10)
+#define FAULT_SHORT_CIRCUIT (11)
+#define FAULT_UVLO (12)
+#define FAULT_IVFM (13)
+#define FAULT_OCP(14)
+#define FAULT_OVERTEMP (15)
+#define FAULT_NTC_TRIP (16)
+#define FAULT_OVP(17)
+
+enum led_mode {
+ MODE_SHDN = 0x0,
+ MODE_TORCH = 0x2,
+ MODE_FLASH = 0x3,
+};
+
+/*
+ * struct lm3646_flash
+ *
+ * @pdata: platform data
+ * @regmap: reg. map for i2c
+ * @lock: muxtex for serial access.
+ * @led_mode: V4L2 LED mode
+ * @ctrls_led: V4L2 contols
+ * @subdev_led: V4L2 subdev
+ */
+struct lm3646_flash {
+ struct device *dev;
+ struct lm3646_platform_data *pdata;
+ struct regmap *regmap;
+
+ struct v4l2_ctrl_handler ctrls_led;
+ struct v4l2_subdev subdev_led;
+};
+
+#define to_lm3646_flash(_ctrl) \
+ container_of(_ctrl-handler, struct lm3646_flash, ctrls_led)
+
+/* enable mode control */
+static int lm3646_mode_ctrl(struct lm3646_flash *flash,
+ enum v4l2_flash_led_mode led_mode)
+{
+ int rval = -EINVAL;
+
+ switch (led_mode) {
+ case V4L2_FLASH_LED_MODE_NONE:
+ rval = regmap_update_bits(flash-regmap,
+ REG_ENABLE, MASK_ENABLE, MODE_SHDN);
+ break;
+ case V4L2_FLASH_LED_MODE_TORCH:
+ rval = regmap_update_bits(flash-regmap,
+ REG_ENABLE, MASK_ENABLE, MODE_TORCH);
+ break;
+ case V4L2_FLASH_LED_MODE_FLASH:
+ rval = regmap_update_bits(flash-regmap,
+ REG_ENABLE, MASK_ENABLE, MODE_FLASH);
+ break;
+ }
+ return rval;
+}
+
+/* V4L2 controls
[RFCv4 PATCH 07/11] vb2: rename queued_count to owned_by_drv_count
From: Hans Verkuil hans.verk...@cisco.com
'queued_count' is a bit vague since it is not clear to which queue it
refers to: the vb2 internal list of buffers or the driver-owned list
of buffers.
Rename to make it explicit.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Pawel Osciak pa...@osciak.com
---
drivers/media/v4l2-core/videobuf2-core.c | 10 +-
include/media/videobuf2-core.h | 4 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 72cac8c..ad3db83 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1071,7 +1071,7 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
vb2_buffer_state state)
spin_lock_irqsave(q-done_lock, flags);
vb-state = state;
list_add_tail(vb-done_entry, q-done_list);
- atomic_dec(q-queued_count);
+ atomic_dec(q-owned_by_drv_count);
spin_unlock_irqrestore(q-done_lock, flags);
/* Inform any processes that may be waiting for buffers */
@@ -1402,7 +1402,7 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
unsigned int plane;
vb-state = VB2_BUF_STATE_ACTIVE;
- atomic_inc(q-queued_count);
+ atomic_inc(q-owned_by_drv_count);
/* sync buffers */
for (plane = 0; plane vb-num_planes; ++plane)
@@ -1554,7 +1554,7 @@ static int vb2_start_streaming(struct vb2_queue *q)
int ret;
/* Tell the driver to start streaming */
- ret = call_qop(q, start_streaming, q, atomic_read(q-queued_count));
+ ret = call_qop(q, start_streaming, q,
atomic_read(q-owned_by_drv_count));
if (ret)
fail_qop(q, start_streaming);
@@ -1779,7 +1779,7 @@ int vb2_wait_for_all_buffers(struct vb2_queue *q)
}
if (!q-retry_start_streaming)
- wait_event(q-done_wq, !atomic_read(q-queued_count));
+ wait_event(q-done_wq, !atomic_read(q-owned_by_drv_count));
return 0;
}
EXPORT_SYMBOL_GPL(vb2_wait_for_all_buffers);
@@ -1911,7 +1911,7 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
* has not already dequeued before initiating cancel.
*/
INIT_LIST_HEAD(q-done_list);
- atomic_set(q-queued_count, 0);
+ atomic_set(q-owned_by_drv_count, 0);
wake_up_all(q-done_wq);
/*
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 82b7f0f..adaffed 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -353,7 +353,7 @@ struct v4l2_fh;
* @bufs: videobuf buffer structures
* @num_buffers: number of allocated/used buffers
* @queued_list: list of buffers currently queued from userspace
- * @queued_count: number of buffers owned by the driver
+ * @owned_by_drv_count: number of buffers owned by the driver
* @done_list: list of buffers ready to be dequeued to userspace
* @done_lock: lock to protect done_list list
* @done_wq: waitqueue for processes waiting for buffers ready to be dequeued
@@ -385,7 +385,7 @@ struct vb2_queue {
struct list_headqueued_list;
- atomic_tqueued_count;
+ atomic_towned_by_drv_count;
struct list_headdone_list;
spinlock_t done_lock;
wait_queue_head_t done_wq;
--
1.8.4.rc3
--
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
[RFCv4 PATCH 09/11] vb2: only call start_streaming if sufficient buffers are queued
From: Hans Verkuil hans.verk...@cisco.com
In commit 02f142ecd24aaf891324ffba8527284c1731b561 support was added to
start_streaming to return -ENOBUFS if insufficient buffers were queued
for the DMA engine to start. The vb2 core would attempt calling
start_streaming again if another buffer would be queued up.
Later analysis uncovered problems with the queue management if start_streaming
would return an error: the buffers are enqueued to the driver before the
start_streaming op is called, so after an error they are never returned to
the vb2 core. The solution for this is to let the driver return them to
the vb2 core in case of an error while starting the DMA engine. However,
in the case of -ENOBUFS that would be weird: it is not a real error, it
just says that more buffers are needed. Requiring start_streaming to give
them back only to have them requeued again the next time the application
calls QBUF is inefficient.
This patch changes this mechanism: it adds a 'min_buffers_needed' field
to vb2_queue that drivers can set with the minimum number of buffers
required to start the DMA engine. The start_streaming op is only called
if enough buffers are queued. The -ENOBUFS handling has been dropped in
favor of this new method.
Drivers are expected to return buffers back to vb2 core with state QUEUED
if start_streaming would return an error. The vb2 core checks for this
and produces a warning if that didn't happen and it will forcefully
reclaim such buffers to ensure that the internal vb2 core state remains
consistent and all buffer-related resources have been correctly freed
and all op calls have been balanced.
__reqbufs() and __create_bufs() have been updated to check that at least
min_buffers_needed buffers could be allocated. If fewer buffers were
allocated then those functions will free what was allocated and return
-ENOMEM. Based on a suggestion from Pawel Osciak.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/davinci/vpbe_display.c | 6 +-
drivers/media/platform/davinci/vpif_capture.c | 7 +-
drivers/media/platform/davinci/vpif_display.c | 7 +-
drivers/media/platform/s5p-tv/mixer_video.c | 6 +-
drivers/media/v4l2-core/videobuf2-core.c| 151
drivers/staging/media/davinci_vpfe/vpfe_video.c | 3 +-
include/media/videobuf2-core.h | 14 ++-
7 files changed, 120 insertions(+), 74 deletions(-)
diff --git a/drivers/media/platform/davinci/vpbe_display.c
b/drivers/media/platform/davinci/vpbe_display.c
index b02aba4..9231e48 100644
--- a/drivers/media/platform/davinci/vpbe_display.c
+++ b/drivers/media/platform/davinci/vpbe_display.c
@@ -344,11 +344,6 @@ static int vpbe_start_streaming(struct vb2_queue *vq,
unsigned int count)
struct vpbe_device *vpbe_dev = fh-disp_dev-vpbe_dev;
int ret;
- /* If buffer queue is empty, return error */
- if (list_empty(layer-dma_queue)) {
- v4l2_err(vpbe_dev-v4l2_dev, buffer queue is empty\n);
- return -ENOBUFS;
- }
/* Get the next frame from the buffer queue */
layer-next_frm = layer-cur_frm = list_entry(layer-dma_queue.next,
struct vpbe_disp_buffer, list);
@@ -1416,6 +1411,7 @@ static int vpbe_display_reqbufs(struct file *file, void
*priv,
q-mem_ops = vb2_dma_contig_memops;
q-buf_struct_size = sizeof(struct vpbe_disp_buffer);
q-timestamp_type = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
+ q-min_buffers_needed = 1;
ret = vb2_queue_init(q);
if (ret) {
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index 735ec47..9731ad4 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -272,13 +272,7 @@ static int vpif_start_streaming(struct vb2_queue *vq,
unsigned int count)
unsigned long flags;
int ret;
- /* If buffer queue is empty, return error */
spin_lock_irqsave(common-irqlock, flags);
- if (list_empty(common-dma_queue)) {
- spin_unlock_irqrestore(common-irqlock, flags);
- vpif_dbg(1, debug, buffer queue is empty\n);
- return -ENOBUFS;
- }
/* Get the next frame from the buffer queue */
common-cur_frm = common-next_frm = list_entry(common-dma_queue.next,
@@ -1024,6 +1018,7 @@ static int vpif_reqbufs(struct file *file, void *priv,
q-mem_ops = vb2_dma_contig_memops;
q-buf_struct_size = sizeof(struct vpif_cap_buffer);
q-timestamp_type = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
+ q-min_buffers_needed = 1;
ret = vb2_queue_init(q);
if (ret) {
diff --git a/drivers/media/platform/davinci/vpif_display.c
b/drivers/media/platform/davinci/vpif_display.c
index 9d115cd..af660f5 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++
[RFCv4 PATCH 00/11] vb2: fixes, balancing callbacks
This patch series is v4 of the previous series: http://www.spinics.net/lists/linux-media/msg73005.html Changelog: - Fixed a number of typos as pointed out by Pawel Osciak - Added better documentation and renamed the index fields in patch 6 (fix read/write regression) - added patch 8/11 to fix a bug in updating q-num_buffers - incorporated suggestions from Pawel for patch 9/11 (was 8/10 in RFCv3). The main change is that reqbufs and createbufs check if at least 'min_buffers_needed' buffers could be allocated. If not, then return -ENOMEM. This patch series fixes a series of bugs in vb2. Recently I have been converting the saa7134 driver to vb2 and as part of that work I discovered that the op calls were not properly balanced, which caused saa7134 to fail. Based on that I did more debugging and I found lots of different issues with vb2 when it comes to balancing ops. This patch series fixes them. Many thanks to Pawel Osciak for a good brainstorm session. Patch 1 adds debugging code to check for unbalanced calls. I used this when testing since without this it is very hard to verify correctness. It is currently turned on when CONFIG_VIDEO_ADV_DEBUG is set, but perhaps this should be placed under a vb2 specific debug option? The next patch changes the buf_finish return type to void. It must not fail, and you can't do anything useful if it does anyway. Note that I really would like to do the same for stop_streaming. The stop_streaming error is currently ignored, and there are some drivers that can actually return an error (waiting for an interruptible mutex for example). Opinions are welcome. Patch 3 just improves some comments. Patches 4 and 5 fix several unbalanced ops. Patch 6 fixes a regression (must go to 3.14!). Patch 7 just renames queue_count to owned_by_drv_count. The old name suggests the number of buffers in the queue_list, but that's not what it is. Since the next patch will actually add a real count for the number of buffers in the queue_list I decided to just rename this, thus freeing up the name 'queue_count'. Patch 8 fixes a bug in when q-num_buffers is updated after allocating new buffers. It should be moved after a final error check. Patch 9 fixes a bug in the handling of start_streaming: before that op is called any prequeued buffers are handed over to the driver. But if start_streaming returns an error, then those buffers are not reclaimed. Since start_streaming failed, q-streaming is 0, so stop_streaming isn't called either. There are two reasons for an error in start_streaming: either a real error when setting up the DMA engine occurred or there were not enough buffers queued for the DMA engine to start (start_streaming returns -ENOBUFS in that case). It makes sense to require that drivers return queued buffers back to vb2 in case of an error, but not if they also have to do that in case of insufficient buffers. So this patch replaces the -ENOBUFS mechanism by a vb2_queue field that tells vb2 what the minimum number of buffers is. Now if start_streaming returns an error the vb2 core will check if there are still buffers owned by the driver and if so produce a warning and reclaim those buffers. The same is done when the vb2_queue is freed. This ensures that the prepare/finish memops are correctly called and the state of all the buffers is consistent. Patch 10 fixes vivi for this start_streaming issue. Note that there are many drivers that do not clean up properly in case of an error during start_streaming. The final patch attempts to fix another issue: I noticed that in the few drivers that implement VIDIOC_CREATE_BUFS the v4l2_format is just used as-is, i.e. no checks are done whether the contents of the struct makes sense or not. This patch adds a number of sanity check to see if the buffer size related values make sense. I have been testing these vb2 changes with vivi (vmalloc based), saa7134 and an out-of-tree PCI driver (dma-sg based), with the mmap/userptr and read/write streaming modes. I hope to test this also for a dma-contig based driver. I have no way of testing with dmabuf, though. Does anyone know of a simple way to obtain dmabufs from somewhere so they can be passed to a v4l driver? It would be great to add a --stream-dmabuf option for v4l2-ctl. I have to admit that I was a bit disappointed by all these vb2 issues... Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv4 PATCH 11/11] v4l2-ioctl: add CREATE_BUFS sanity checks.
From: Hans Verkuil hans.verk...@cisco.com
Many drivers do not check anything. At least make sure that the various
buffer size related fields are not obviously wrong.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/v4l2-ioctl.c | 52 ++--
1 file changed, 50 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 707aef7..69a1948 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1444,9 +1444,57 @@ static int v4l_create_bufs(const struct v4l2_ioctl_ops
*ops,
struct file *file, void *fh, void *arg)
{
struct v4l2_create_buffers *create = arg;
- int ret = check_fmt(file, create-format.type);
+ const struct v4l2_format *fmt = create-format;
+ const struct v4l2_pix_format *pix = fmt-fmt.pix;
+ const struct v4l2_pix_format_mplane *mp = fmt-fmt.pix_mp;
+ const struct v4l2_plane_pix_format *p;
+ int ret = check_fmt(file, fmt-type);
+ unsigned i;
+
+ if (ret)
+ return ret;
- return ret ? ret : ops-vidioc_create_bufs(file, fh, create);
+ /* Sanity checks */
+ switch (fmt-type) {
+ case V4L2_BUF_TYPE_VIDEO_CAPTURE:
+ case V4L2_BUF_TYPE_VIDEO_OUTPUT:
+ if (pix-sizeimage == 0 || pix-width == 0 || pix-height == 0)
+ return -EINVAL;
+ /* Note: bytesperline is 0 for compressed formats */
+ if (pix-bytesperline
+ pix-height * pix-bytesperline pix-sizeimage)
+ return -EINVAL;
+ break;
+ case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
+ case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
+ if (mp-num_planes == 0 || mp-width == 0 || mp-height == 0)
+ return -EINVAL;
+ for (i = 0; i mp-num_planes; i++) {
+ p = mp-plane_fmt[i];
+
+ if (p-sizeimage == 0)
+ return -EINVAL;
+ /* Note: bytesperline is 0 for compressed formats */
+ if (p-bytesperline
+ p-bytesperline * mp-height p-sizeimage)
+ return -EINVAL;
+ }
+ break;
+ case V4L2_BUF_TYPE_VBI_CAPTURE:
+ case V4L2_BUF_TYPE_VBI_OUTPUT:
+ if (fmt-fmt.vbi.count[0] + fmt-fmt.vbi.count[1] == 0)
+ return -EINVAL;
+ break;
+ case V4L2_BUF_TYPE_SLICED_VBI_CAPTURE:
+ case V4L2_BUF_TYPE_SLICED_VBI_OUTPUT:
+ if (fmt-fmt.sliced.io_size == 0)
+ return -EINVAL;
+ break;
+ default:
+ /* Overlay formats are invalid */
+ return -EINVAL;
+ }
+ return ops-vidioc_create_bufs(file, fh, create);
}
static int v4l_prepare_buf(const struct v4l2_ioctl_ops *ops,
--
1.8.4.rc3
--
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
[RFCv4 PATCH 06/11] vb2: fix read/write regression
From: Hans Verkuil hans.verk...@cisco.com
Commit 88e268702bfba78448abd20a31129458707383aa (vb2: Improve file I/O
emulation to handle buffers in any order) broke read/write support if
the size of the buffer being read/written is less than the size of the
image.
When the commit was tested originally I used qv4l2, which calls read()
with exactly the size of the image. But if you try 'cat /dev/video0'
then it will fail and typically hang after reading two buffers.
This patch fixes the behavior by adding a new cur_index field that
contains the index of the field currently being filled/read, or it
is num_buffers in which case a new buffer needs to be dequeued.
The old index field has been renamed to initial_index in order to be
a bit more descriptive.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Cc: Andy Walls awa...@md.metrocast.net
---
drivers/media/v4l2-core/videobuf2-core.c | 46 +++-
1 file changed, 40 insertions(+), 6 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 7766bf5..72cac8c 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2409,6 +2409,22 @@ struct vb2_fileio_buf {
/**
* struct vb2_fileio_data - queue context used by file io emulator
*
+ * @cur_index: the index of the buffer currently being read from or
+ * written to. If equal to q-num_buffers then a new buffer
+ * must be dequeued.
+ * @initial_index: in the read() case all buffers are queued up immediately
+ * in __vb2_init_fileio() and __vb2_perform_fileio() just cycles
+ * buffers. However, in the write() case no buffers are initially
+ * queued, instead whenever a buffer is full it is queued up by
+ * __vb2_perform_fileio(). Only once all available buffers have
+ * been queued up will __vb2_perform_fileio() start to dequeue
+ * buffers. This means that initially __vb2_perform_fileio()
+ * needs to know what buffer index to use when it is queuing up
+ * the buffers for the first time. That initial index is stored
+ * in this field. Once it is equal to q-num_buffers all
+ * available buffers have been queued and __vb2_perform_fileio()
+ * should start the normal dequeue/queue cycle.
+ *
* vb2 provides a compatibility layer and emulator of file io (read and
* write) calls on top of streaming API. For proper operation it required
* this structure to save the driver state between each call of the read
@@ -2418,7 +2434,8 @@ struct vb2_fileio_data {
struct v4l2_requestbuffers req;
struct v4l2_buffer b;
struct vb2_fileio_buf bufs[VIDEO_MAX_FRAME];
- unsigned int index;
+ unsigned int cur_index;
+ unsigned int initial_index;
unsigned int q_count;
unsigned int dq_count;
unsigned int flags;
@@ -2518,7 +2535,12 @@ static int __vb2_init_fileio(struct vb2_queue *q, int
read)
goto err_reqbufs;
fileio-bufs[i].queued = 1;
}
- fileio-index = q-num_buffers;
+ /*
+* All buffers have been queued, so mark that by setting
+* initial_index to q-num_buffers
+*/
+ fileio-initial_index = q-num_buffers;
+ fileio-cur_index = q-num_buffers;
}
/*
@@ -2597,7 +2619,7 @@ static size_t __vb2_perform_fileio(struct vb2_queue *q,
char __user *data, size_
/*
* Check if we need to dequeue the buffer.
*/
- index = fileio-index;
+ index = fileio-cur_index;
if (index = q-num_buffers) {
/*
* Call vb2_dqbuf to get buffer back.
@@ -2611,7 +2633,7 @@ static size_t __vb2_perform_fileio(struct vb2_queue *q,
char __user *data, size_
return ret;
fileio-dq_count += 1;
- index = fileio-b.index;
+ fileio-cur_index = index = fileio-b.index;
buf = fileio-bufs[index];
/*
@@ -2687,8 +2709,20 @@ static size_t __vb2_perform_fileio(struct vb2_queue *q,
char __user *data, size_
buf-queued = 1;
buf-size = vb2_plane_size(q-bufs[index], 0);
fileio-q_count += 1;
- if (fileio-index q-num_buffers)
- fileio-index++;
+ /*
+* If we are queuing up buffers for the first time, then
+* increase initial_index by one.
+*/
+ if (fileio-initial_index q-num_buffers)
+ fileio-initial_index++;
+ /*
+* The next buffer to use is either a buffer that's going to be
+* queued for the first time (initial_index q-num_buffers)
+
[RFCv4 PATCH 08/11] vb2: q-num_buffers was updated too soon
From: Hans Verkuil hans.verk...@cisco.com
In __reqbufs() and __create_bufs() the q-num_buffers field was updated
with the number of newly allocated buffers, but right after that those are
freed again if some error had occurred before. Move the line updating
num_buffers to *after* that error check.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/videobuf2-core.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index ad3db83..96c5ac6 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -848,13 +848,13 @@ static int __reqbufs(struct vb2_queue *q, struct
v4l2_requestbuffers *req)
*/
}
- q-num_buffers = allocated_buffers;
-
if (ret 0) {
__vb2_queue_free(q, allocated_buffers);
return ret;
}
+ q-num_buffers = allocated_buffers;
+
/*
* Return the number of successfully allocated buffers
* to the userspace.
@@ -957,13 +957,13 @@ static int __create_bufs(struct vb2_queue *q, struct
v4l2_create_buffers *create
*/
}
- q-num_buffers += allocated_buffers;
-
if (ret 0) {
__vb2_queue_free(q, allocated_buffers);
return -ENOMEM;
}
+ q-num_buffers += allocated_buffers;
+
/*
* Return the number of successfully allocated buffers
* to the userspace.
--
1.8.4.rc3
--
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
[RFCv4 PATCH 04/11] vb2: call buf_finish from __dqbuf
From: Hans Verkuil hans.verk...@cisco.com
This ensures that it is also called from queue_cancel, which also calls
__dqbuf(). Without this change any time queue_cancel is called while
streaming the buf_finish op will not be called and any driver cleanup
will not happen.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Pawel Osciak pa...@osciak.com
---
drivers/media/v4l2-core/videobuf2-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 1f037de..3756378 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1762,6 +1762,8 @@ static void __vb2_dqbuf(struct vb2_buffer *vb)
if (vb-state == VB2_BUF_STATE_DEQUEUED)
return;
+ call_vb_qop(vb, buf_finish, vb);
+
vb-state = VB2_BUF_STATE_DEQUEUED;
/* unmap DMABUF buffer */
@@ -1787,8 +1789,6 @@ static int vb2_internal_dqbuf(struct vb2_queue *q, struct
v4l2_buffer *b, bool n
if (ret 0)
return ret;
- call_vb_qop(vb, buf_finish, vb);
-
switch (vb-state) {
case VB2_BUF_STATE_DONE:
dprintk(3, dqbuf: Returning done buffer\n);
--
1.8.4.rc3
--
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
[RFCv4 PATCH 10/11] vivi: correctly cleanup after a start_streaming failure.
From: Hans Verkuil hans.verk...@cisco.com
If start_streaming fails then any queued buffers must be given back
to the vb2 core.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/vivi.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
index 2d4e73b..6085e2f 100644
--- a/drivers/media/platform/vivi.c
+++ b/drivers/media/platform/vivi.c
@@ -901,8 +901,19 @@ static void buffer_queue(struct vb2_buffer *vb)
static int start_streaming(struct vb2_queue *vq, unsigned int count)
{
struct vivi_dev *dev = vb2_get_drv_priv(vq);
+ int err;
+
dprintk(dev, 1, %s\n, __func__);
- return vivi_start_generating(dev);
+ err = vivi_start_generating(dev);
+ if (err) {
+ struct vivi_buffer *buf, *tmp;
+
+ list_for_each_entry_safe(buf, tmp, dev-vidq.active, list) {
+ list_del(buf-list);
+ vb2_buffer_done(buf-vb, VB2_BUF_STATE_QUEUED);
+ }
+ }
+ return err;
}
/* abort streaming and wait for last buffer */
--
1.8.4.rc3
--
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
[RFCv4 PATCH 02/11] vb2: change result code of buf_finish to void.
From: Hans Verkuil hans.verk...@cisco.com
The buf_finish op should always work, so change the return type to void.
Update the few drivers that use it. Note that buf_finish can be called
both when the DMA is streaming and when it isn't (during queue_cancel).
Update drivers to check that where appropriate.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Pawel Osciak pa...@osciak.com
Reviewed-by: Pawel Osciak pa...@osciak.com
---
drivers/media/parport/bw-qcam.c | 6 --
drivers/media/pci/sta2x11/sta2x11_vip.c | 7 +++
drivers/media/platform/marvell-ccic/mcam-core.c | 3 +--
drivers/media/usb/pwc/pwc-if.c | 16 +---
drivers/media/usb/uvc/uvc_queue.c | 6 +++---
drivers/media/v4l2-core/videobuf2-core.c| 6 +-
drivers/staging/media/go7007/go7007-v4l2.c | 3 +--
include/media/videobuf2-core.h | 2 +-
8 files changed, 23 insertions(+), 26 deletions(-)
diff --git a/drivers/media/parport/bw-qcam.c b/drivers/media/parport/bw-qcam.c
index d12bd33..8d69bfb 100644
--- a/drivers/media/parport/bw-qcam.c
+++ b/drivers/media/parport/bw-qcam.c
@@ -667,13 +667,16 @@ static void buffer_queue(struct vb2_buffer *vb)
vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
}
-static int buffer_finish(struct vb2_buffer *vb)
+static void buffer_finish(struct vb2_buffer *vb)
{
struct qcam *qcam = vb2_get_drv_priv(vb-vb2_queue);
void *vbuf = vb2_plane_vaddr(vb, 0);
int size = vb-vb2_queue-plane_sizes[0];
int len;
+ if (!vb2_is_streaming(vb-vb2_queue))
+ return;
+
mutex_lock(qcam-lock);
parport_claim_or_block(qcam-pdev);
@@ -691,7 +694,6 @@ static int buffer_finish(struct vb2_buffer *vb)
if (len != size)
vb-state = VB2_BUF_STATE_ERROR;
vb2_set_plane_payload(vb, 0, len);
- return 0;
}
static struct vb2_ops qcam_video_qops = {
diff --git a/drivers/media/pci/sta2x11/sta2x11_vip.c
b/drivers/media/pci/sta2x11/sta2x11_vip.c
index e5cfb6c..bb11443 100644
--- a/drivers/media/pci/sta2x11/sta2x11_vip.c
+++ b/drivers/media/pci/sta2x11/sta2x11_vip.c
@@ -327,7 +327,7 @@ static void buffer_queue(struct vb2_buffer *vb)
}
spin_unlock(vip-lock);
}
-static int buffer_finish(struct vb2_buffer *vb)
+static void buffer_finish(struct vb2_buffer *vb)
{
struct sta2x11_vip *vip = vb2_get_drv_priv(vb-vb2_queue);
struct vip_buffer *vip_buf = to_vip_buffer(vb);
@@ -337,9 +337,8 @@ static int buffer_finish(struct vb2_buffer *vb)
list_del_init(vip_buf-list);
spin_unlock(vip-lock);
- vip_active_buf_next(vip);
-
- return 0;
+ if (vb2_is_streaming(vb-vb2_queue))
+ vip_active_buf_next(vip);
}
static int start_streaming(struct vb2_queue *vq, unsigned int count)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 32fab30..8b34c48 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -1238,7 +1238,7 @@ static int mcam_vb_sg_buf_prepare(struct vb2_buffer *vb)
return 0;
}
-static int mcam_vb_sg_buf_finish(struct vb2_buffer *vb)
+static void mcam_vb_sg_buf_finish(struct vb2_buffer *vb)
{
struct mcam_camera *cam = vb2_get_drv_priv(vb-vb2_queue);
struct sg_table *sg_table = vb2_dma_sg_plane_desc(vb, 0);
@@ -1246,7 +1246,6 @@ static int mcam_vb_sg_buf_finish(struct vb2_buffer *vb)
if (sg_table)
dma_unmap_sg(cam-dev, sg_table-sgl,
sg_table-nents, DMA_FROM_DEVICE);
- return 0;
}
static void mcam_vb_sg_buf_cleanup(struct vb2_buffer *vb)
diff --git a/drivers/media/usb/pwc/pwc-if.c b/drivers/media/usb/pwc/pwc-if.c
index abf365a..b9c9f10 100644
--- a/drivers/media/usb/pwc/pwc-if.c
+++ b/drivers/media/usb/pwc/pwc-if.c
@@ -614,17 +614,19 @@ static int buffer_prepare(struct vb2_buffer *vb)
return 0;
}
-static int buffer_finish(struct vb2_buffer *vb)
+static void buffer_finish(struct vb2_buffer *vb)
{
struct pwc_device *pdev = vb2_get_drv_priv(vb-vb2_queue);
struct pwc_frame_buf *buf = container_of(vb, struct pwc_frame_buf, vb);
- /*
-* Application has called dqbuf and is getting back a buffer we've
-* filled, take the pwc data we've stored in buf-data and decompress
-* it into a usable format, storing the result in the vb2_buffer
-*/
- return pwc_decompress(pdev, buf);
+ if (vb-state == VB2_BUF_STATE_DONE) {
+ /*
+* Application has called dqbuf and is getting back a buffer
we've
+* filled, take the pwc data we've stored in buf-data and
decompress
+* it into a usable format, storing the result in the vb2_buffer
+*/
+ pwc_decompress(pdev, buf);
+ }
}
static void
[RFCv4 PATCH 01/11] vb2: add debugging code to check for unbalanced ops.
From: Hans Verkuil hans.verk...@cisco.com
When a vb2_queue is freed check if all the mem_ops and queue ops were balanced.
So the number of calls to e.g. buf_finish has to match the number of calls to
buf_prepare, etc.
This code is only enabled if CONFIG_VIDEO_ADV_DEBUG is set.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Pawel Osciak pa...@osciak.com
---
drivers/media/v4l2-core/videobuf2-core.c | 233 ---
include/media/videobuf2-core.h | 43 ++
2 files changed, 226 insertions(+), 50 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 5a5fb7f..07b58bd 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -33,12 +33,63 @@ module_param(debug, int, 0644);
printk(KERN_DEBUG vb2: fmt, ## arg); \
} while (0)
-#define call_memop(q, op, args...) \
- (((q)-mem_ops-op) ? \
- ((q)-mem_ops-op(args)) : 0)
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+
+/*
+ * If advanced debugging is on, then count how often each op is called,
+ * which can either be per-buffer or per-queue.
+ *
+ * If the op failed then the 'fail_' variant is called to decrease the
+ * counter. That makes it easy to check that the 'init' and 'cleanup'
+ * (and variations thereof) stay balanced.
+ */
+
+#define call_memop(vb, op, args...)\
+({ \
+ struct vb2_queue *_q = (vb)-vb2_queue; \
+ dprintk(2, call_memop(%p, %d, %s)%s\n,\
+ _q, (vb)-v4l2_buf.index, #op, \
+ _q-mem_ops-op ? : (nop)); \
+ (vb)-cnt_mem_ ## op++; \
+ _q-mem_ops-op ? _q-mem_ops-op(args) : 0;\
+})
+#define fail_memop(vb, op) ((vb)-cnt_mem_ ## op--)
+
+#define call_qop(q, op, args...) \
+({ \
+ dprintk(2, call_qop(%p, %s)%s\n, q, #op, \
+ (q)-ops-op ? : (nop)); \
+ (q)-cnt_ ## op++; \
+ (q)-ops-op ? (q)-ops-op(args) : 0; \
+})
+#define fail_qop(q, op) ((q)-cnt_ ## op--)
+
+#define call_vb_qop(vb, op, args...) \
+({ \
+ struct vb2_queue *_q = (vb)-vb2_queue; \
+ dprintk(2, call_vb_qop(%p, %d, %s)%s\n, \
+ _q, (vb)-v4l2_buf.index, #op, \
+ _q-ops-op ? : (nop)); \
+ (vb)-cnt_ ## op++; \
+ _q-ops-op ? _q-ops-op(args) : 0;\
+})
+#define fail_vb_qop(vb, op) ((vb)-cnt_ ## op--)
+
+#else
+
+#define call_memop(vb, op, args...)\
+ ((vb)-vb2_queue-mem_ops-op ? (vb)-vb2_queue-mem_ops-op(args) : 0)
+#define fail_memop(vb, op)
#define call_qop(q, op, args...) \
- (((q)-ops-op) ? ((q)-ops-op(args)) : 0)
+ ((q)-ops-op ? (q)-ops-op(args) : 0)
+#define fail_qop(q, op)
+
+#define call_vb_qop(vb, op, args...) \
+ ((vb)-vb2_queue-ops-op ? (vb)-vb2_queue-ops-op(args) : 0)
+#define fail_vb_qop(vb, op)
+
+#endif
#define V4L2_BUFFER_MASK_FLAGS (V4L2_BUF_FLAG_MAPPED | V4L2_BUF_FLAG_QUEUED | \
V4L2_BUF_FLAG_DONE | V4L2_BUF_FLAG_ERROR | \
@@ -61,7 +112,7 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
for (plane = 0; plane vb-num_planes; ++plane) {
unsigned long size = PAGE_ALIGN(q-plane_sizes[plane]);
- mem_priv = call_memop(q, alloc, q-alloc_ctx[plane],
+ mem_priv = call_memop(vb, alloc, q-alloc_ctx[plane],
size, q-gfp_flags);
if (IS_ERR_OR_NULL(mem_priv))
goto free;
@@ -73,9 +124,10 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
return 0;
free:
+ fail_memop(vb, alloc);
/* Free already allocated memory if one of the allocations failed */
for (; plane 0; --plane) {
- call_memop(q, put, vb-planes[plane - 1].mem_priv);
+ call_memop(vb, put, vb-planes[plane - 1].mem_priv);
vb-planes[plane - 1].mem_priv = NULL;
}
@@ -87,11 +139,10 @@ free:
*/
static void __vb2_buf_mem_free(struct vb2_buffer *vb)
{
- struct vb2_queue *q =
[RFCv4 PATCH 05/11] vb2: fix buf_init/buf_cleanup call sequences
From: Hans Verkuil hans.verk...@cisco.com
Ensure that these ops are properly balanced.
There are two scenarios:
1) for MMAP buf_init is called when the buffers are created and buf_cleanup
must be called when the queue is finally freed. This scenario was always
working.
2) for USERPTR and DMABUF it is more complicated. When a buffer is queued
the code checks if all planes of this buffer have been acquired before.
If that's the case, then only buf_prepare has to be called. Otherwise
buf_cleanup needs to be called if the buffer was acquired before, then,
once all changed planes have been (re)acquired, buf_init has to be
called followed by buf_prepare. Should buf_prepare fail, then buf_cleanup
must be called on the newly acquired planes to release them in.
Finally, in __vb2_queue_free we have to check if the buffer was actually
acquired before calling buf_cleanup. While that it always true for MMAP
mode, it is not necessarily true for the other modes. E.g. if you just
call REQBUFS and close the file handle, then buffers were never queued and
so no buf_init was ever called.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/videobuf2-core.c | 100 +--
1 file changed, 67 insertions(+), 33 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 3756378..7766bf5 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -373,8 +373,10 @@ static int __vb2_queue_free(struct vb2_queue *q, unsigned
int buffers)
/* Call driver-provided cleanup function for each buffer, if provided */
for (buffer = q-num_buffers - buffers; buffer q-num_buffers;
++buffer) {
- if (q-bufs[buffer])
- call_vb_qop(q-bufs[buffer], buf_cleanup,
q-bufs[buffer]);
+ struct vb2_buffer *vb = q-bufs[buffer];
+
+ if (vb vb-planes[0].mem_priv)
+ call_vb_qop(vb, buf_cleanup, vb);
}
/* Release video buffer memory */
@@ -1161,6 +1163,7 @@ static int __qbuf_userptr(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
unsigned int plane;
int ret;
int write = !V4L2_TYPE_IS_OUTPUT(q-type);
+ bool reacquired = vb-planes[0].mem_priv == NULL;
/* Copy relevant information provided by the userspace */
__fill_vb2_buffer(vb, b, planes);
@@ -1186,12 +1189,16 @@ static int __qbuf_userptr(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
}
/* Release previously acquired memory if present */
- if (vb-planes[plane].mem_priv)
+ if (vb-planes[plane].mem_priv) {
+ if (!reacquired) {
+ reacquired = true;
+ call_vb_qop(vb, buf_cleanup, vb);
+ }
call_memop(vb, put_userptr, vb-planes[plane].mem_priv);
+ }
vb-planes[plane].mem_priv = NULL;
- vb-v4l2_planes[plane].m.userptr = 0;
- vb-v4l2_planes[plane].length = 0;
+ memset(vb-v4l2_planes[plane], 0, sizeof(struct v4l2_plane));
/* Acquire each plane's memory */
mem_priv = call_memop(vb, get_userptr, q-alloc_ctx[plane],
@@ -1208,23 +1215,34 @@ static int __qbuf_userptr(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
}
/*
-* Call driver-specific initialization on the newly acquired buffer,
-* if provided.
-*/
- ret = call_vb_qop(vb, buf_init, vb);
- if (ret) {
- dprintk(1, qbuf: buffer initialization failed\n);
- fail_vb_qop(vb, buf_init);
- goto err;
- }
-
- /*
* Now that everything is in order, copy relevant information
* provided by userspace.
*/
for (plane = 0; plane vb-num_planes; ++plane)
vb-v4l2_planes[plane] = planes[plane];
+ if (reacquired) {
+ /*
+* One or more planes changed, so we must call buf_init to do
+* the driver-specific initialization on the newly acquired
+* buffer, if provided.
+*/
+ ret = call_vb_qop(vb, buf_init, vb);
+ if (ret) {
+ dprintk(1, qbuf: buffer initialization failed\n);
+ fail_vb_qop(vb, buf_init);
+ goto err;
+ }
+ }
+
+ ret = call_vb_qop(vb, buf_prepare, vb);
+ if (ret) {
+ dprintk(1, qbuf: buffer preparation failed\n);
+ fail_vb_qop(vb, buf_prepare);
+ call_vb_qop(vb, buf_cleanup, vb);
+ goto err;
+ }
+
return 0;
err:
/* In case of errors, release planes that were already
[RFCv4 PATCH 03/11] vb2: add note that buf_finish can be called with !vb2_is_streaming()
From: Hans Verkuil hans.verk...@cisco.com
Drivers need to be aware that buf_finish can be called when there is no
streaming going on, so make a note of that.
Also add a bunch of missing periods at the end of sentences.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Pawel Osciak pa...@osciak.com
---
include/media/videobuf2-core.h | 44 ++
1 file changed, 23 insertions(+), 21 deletions(-)
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index f443ce0..82b7f0f 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -34,49 +34,49 @@ struct vb2_fileio_data;
* usually will result in the allocator freeing the buffer (if
* no other users of this buffer are present); the buf_priv
* argument is the allocator private per-buffer structure
- * previously returned from the alloc callback
+ * previously returned from the alloc callback.
* @get_userptr: acquire userspace memory for a hardware operation; used for
* USERPTR memory types; vaddr is the address passed to the
* videobuf layer when queuing a video buffer of USERPTR type;
* should return an allocator private per-buffer structure
* associated with the buffer on success, NULL on failure;
* the returned private structure will then be passed as buf_priv
- * argument to other ops in this structure
+ * argument to other ops in this structure.
* @put_userptr: inform the allocator that a USERPTR buffer will no longer
- * be used
+ * be used.
* @attach_dmabuf: attach a shared struct dma_buf for a hardware operation;
*used for DMABUF memory types; alloc_ctx is the alloc context
*dbuf is the shared dma_buf; returns NULL on failure;
*allocator private per-buffer structure on success;
- *this needs to be used for further accesses to the buffer
+ *this needs to be used for further accesses to the buffer.
* @detach_dmabuf: inform the exporter of the buffer that the current DMABUF
*buffer is no longer used; the buf_priv argument is the
*allocator private per-buffer structure previously returned
- *from the attach_dmabuf callback
+ *from the attach_dmabuf callback.
* @map_dmabuf: request for access to the dmabuf from allocator; the allocator
* of dmabuf is informed that this driver is going to use the
- * dmabuf
+ * dmabuf.
* @unmap_dmabuf: releases access control to the dmabuf - allocator is notified
- * that this driver is done using the dmabuf for now
+ * that this driver is done using the dmabuf for now.
* @prepare: called every time the buffer is passed from userspace to the
- * driver, useful for cache synchronisation, optional
+ * driver, useful for cache synchronisation, optional.
* @finish:called every time the buffer is passed back from the driver
- * to the userspace, also optional
+ * to the userspace, also optional.
* @vaddr: return a kernel virtual address to a given memory buffer
* associated with the passed private structure or NULL if no
- * such mapping exists
+ * such mapping exists.
* @cookie:return allocator specific cookie for a given memory buffer
* associated with the passed private structure or NULL if not
- * available
+ * available.
* @num_users: return the current number of users of a memory buffer;
* return 1 if the videobuf layer (or actually the driver using
- * it) is the only user
+ * it) is the only user.
* @mmap: setup a userspace mapping for a given memory buffer under
- * the provided virtual memory region
+ * the provided virtual memory region.
*
* Required ops for USERPTR types: get_userptr, put_userptr.
* Required ops for MMAP types: alloc, put, num_users, mmap.
- * Required ops for read/write access types: alloc, put, num_users, vaddr
+ * Required ops for read/write access types: alloc, put, num_users, vaddr.
* Required ops for DMABUF types: attach_dmabuf, detach_dmabuf, map_dmabuf,
* unmap_dmabuf.
*/
@@ -258,27 +258,29 @@ struct vb2_buffer {
* @wait_prepare: release any locks taken while calling vb2 functions;
* it is called before an ioctl needs to wait for a new
* buffer to arrive; required to avoid a deadlock in
- * blocking access type
+ * blocking access type.
* @wait_finish: reacquire all locks released in the previous callback;
*
Re: [REVIEW PATCH 3/6] v4l: reorganize RF tuner control ID numbers
Hi Antti,
On 02/10/2014 05:17 PM, Antti Palosaari wrote:
It appears that controls are ordered by ID number. Change order of
controls by reorganizing assigned IDs now as we can. It is not
reasonable possible after the API is released. Leave some spare
space between IDs too for future extensions.
Am I missing something? I see no reason for this patch or for adding the
spare space.
Regards,
Hans
Cc: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Antti Palosaari cr...@iki.fi
---
include/uapi/linux/v4l2-controls.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 3cf68a6..cc488c3 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -899,13 +899,13 @@ enum v4l2_deemphasis {
#define V4L2_CID_RF_TUNER_CLASS_BASE (V4L2_CTRL_CLASS_RF_TUNER |
0x900)
#define V4L2_CID_RF_TUNER_CLASS
(V4L2_CTRL_CLASS_RF_TUNER | 1)
-#define V4L2_CID_LNA_GAIN_AUTO
(V4L2_CID_RF_TUNER_CLASS_BASE + 1)
-#define V4L2_CID_LNA_GAIN(V4L2_CID_RF_TUNER_CLASS_BASE +
2)
-#define V4L2_CID_MIXER_GAIN_AUTO (V4L2_CID_RF_TUNER_CLASS_BASE +
3)
-#define V4L2_CID_MIXER_GAIN (V4L2_CID_RF_TUNER_CLASS_BASE +
4)
-#define V4L2_CID_IF_GAIN_AUTO
(V4L2_CID_RF_TUNER_CLASS_BASE + 5)
-#define V4L2_CID_IF_GAIN (V4L2_CID_RF_TUNER_CLASS_BASE +
6)
-#define V4L2_CID_BANDWIDTH_AUTO
(V4L2_CID_RF_TUNER_CLASS_BASE + 7)
-#define V4L2_CID_BANDWIDTH (V4L2_CID_RF_TUNER_CLASS_BASE +
8)
+#define V4L2_CID_BANDWIDTH_AUTO
(V4L2_CID_RF_TUNER_CLASS_BASE + 11)
+#define V4L2_CID_BANDWIDTH (V4L2_CID_RF_TUNER_CLASS_BASE +
12)
+#define V4L2_CID_LNA_GAIN_AUTO
(V4L2_CID_RF_TUNER_CLASS_BASE + 41)
+#define V4L2_CID_LNA_GAIN(V4L2_CID_RF_TUNER_CLASS_BASE +
42)
+#define V4L2_CID_MIXER_GAIN_AUTO (V4L2_CID_RF_TUNER_CLASS_BASE +
51)
+#define V4L2_CID_MIXER_GAIN (V4L2_CID_RF_TUNER_CLASS_BASE +
52)
+#define V4L2_CID_IF_GAIN_AUTO
(V4L2_CID_RF_TUNER_CLASS_BASE + 61)
+#define V4L2_CID_IF_GAIN (V4L2_CID_RF_TUNER_CLASS_BASE +
62)
#endif
--
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: [REVIEW PATCH 1/6] v4l: add RF tuner gain controls
On 02/10/2014 05:17 PM, Antti Palosaari wrote:
Modern silicon RF tuners used nowadays has many controllable gain
stages on signal path. Usually, but not always, there is at least
3 gain stages. Also on some cases there could be multiple gain
stages within the ones specified here. However, I think that having
these three controllable gain stages offers enough fine-tuning for
real use cases.
1) LNA gain. That is first gain just after antenna input.
2) Mixer gain. It is located quite middle of the signal path, where
RF signal is down-converted to IF/BB.
3) IF gain. That is last gain in order to adjust output signal level
to optimal level for receiving party (usually demodulator ADC).
Each gain stage could be set rather often both manual or automatic
(AGC) mode. Due to that add separate controls for controlling
operation mode.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/v4l2-core/v4l2-ctrls.c | 15 +++
include/uapi/linux/v4l2-controls.h | 11 +++
2 files changed, 26 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 6ff002b..d201f61 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -857,6 +857,14 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_FM_RX_CLASS: return FM Radio Receiver
Controls;
case V4L2_CID_TUNE_DEEMPHASIS: return De-Emphasis;
case V4L2_CID_RDS_RECEPTION:return RDS Reception;
+
+ case V4L2_CID_RF_TUNER_CLASS: return RF Tuner Controls;
+ case V4L2_CID_LNA_GAIN_AUTO:return LNA Gain, Auto;
+ case V4L2_CID_LNA_GAIN: return LNA Gain;
+ case V4L2_CID_MIXER_GAIN_AUTO: return Mixer Gain, Auto;
+ case V4L2_CID_MIXER_GAIN: return Mixer Gain;
+ case V4L2_CID_IF_GAIN_AUTO: return IF Gain, Auto;
+ case V4L2_CID_IF_GAIN: return IF Gain;
default:
return NULL;
}
@@ -906,6 +914,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_WIDE_DYNAMIC_RANGE:
case V4L2_CID_IMAGE_STABILIZATION:
case V4L2_CID_RDS_RECEPTION:
+ case V4L2_CID_LNA_GAIN_AUTO:
+ case V4L2_CID_MIXER_GAIN_AUTO:
+ case V4L2_CID_IF_GAIN_AUTO:
*type = V4L2_CTRL_TYPE_BOOLEAN;
*min = 0;
*max = *step = 1;
@@ -991,6 +1002,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_IMAGE_PROC_CLASS:
case V4L2_CID_DV_CLASS:
case V4L2_CID_FM_RX_CLASS:
+ case V4L2_CID_RF_TUNER_CLASS:
*type = V4L2_CTRL_TYPE_CTRL_CLASS;
/* You can neither read not write these */
*flags |= V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_WRITE_ONLY;
@@ -1063,6 +1075,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_PILOT_TONE_FREQUENCY:
case V4L2_CID_TUNE_POWER_LEVEL:
case V4L2_CID_TUNE_ANTENNA_CAPACITOR:
+ case V4L2_CID_LNA_GAIN:
+ case V4L2_CID_MIXER_GAIN:
+ case V4L2_CID_IF_GAIN:
*flags |= V4L2_CTRL_FLAG_SLIDER;
break;
case V4L2_CID_PAN_RELATIVE:
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 2cbe605..076fa34 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -60,6 +60,7 @@
#define V4L2_CTRL_CLASS_IMAGE_PROC 0x009f /* Image processing
controls */
#define V4L2_CTRL_CLASS_DV 0x00a0 /* Digital Video
controls */
#define V4L2_CTRL_CLASS_FM_RX0x00a1 /* FM Receiver
controls */
+#define V4L2_CTRL_CLASS_RF_TUNER 0x00a2 /* RF tuner controls */
/* User-class control IDs */
@@ -895,4 +896,14 @@ enum v4l2_deemphasis {
#define V4L2_CID_RDS_RECEPTION
(V4L2_CID_FM_RX_CLASS_BASE + 2)
+#define V4L2_CID_RF_TUNER_CLASS_BASE (V4L2_CTRL_CLASS_RF_TUNER |
0x900)
+#define V4L2_CID_RF_TUNER_CLASS
(V4L2_CTRL_CLASS_RF_TUNER | 1)
+
+#define V4L2_CID_LNA_GAIN_AUTO
(V4L2_CID_RF_TUNER_CLASS_BASE + 1)
+#define V4L2_CID_LNA_GAIN(V4L2_CID_RF_TUNER_CLASS_BASE +
2)
+#define V4L2_CID_MIXER_GAIN_AUTO (V4L2_CID_RF_TUNER_CLASS_BASE +
3)
+#define V4L2_CID_MIXER_GAIN (V4L2_CID_RF_TUNER_CLASS_BASE +
4)
+#define V4L2_CID_IF_GAIN_AUTO
(V4L2_CID_RF_TUNER_CLASS_BASE + 5)
+#define V4L2_CID_IF_GAIN (V4L2_CID_RF_TUNER_CLASS_BASE +
6)
I would prefer to give these control defines a prefix:
V4L2_CID_RF_TUNER_MIXER_GAIN_AUTO (or possibly V4L2_CID_RF_TNR_...)
'MIXER_GAIN' by itself does not make it clear it relates to a
Re: [REVIEW PATCH 2/6] v4l: add RF tuner channel bandwidth control
On 02/10/2014 05:17 PM, Antti Palosaari wrote:
Modern silicon RF tuners has one or more adjustable filters on
signal path, in order to filter noise from desired radio channel.
Add channel bandwidth control to tell the driver which is radio
channel width we want receive. Filters could be then adjusted by
the driver or hardware, using RF frequency and channel bandwidth
as a base of filter calculations.
On automatic mode (normal mode), bandwidth is calculated from sampling
rate or tuning info got from userspace. That new control gives
possibility to set manual mode and let user have more control for
filters.
Cc: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/v4l2-core/v4l2-ctrls.c | 4
include/uapi/linux/v4l2-controls.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index d201f61..e44722b 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -865,6 +865,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MIXER_GAIN: return Mixer Gain;
case V4L2_CID_IF_GAIN_AUTO: return IF Gain, Auto;
case V4L2_CID_IF_GAIN: return IF Gain;
+ case V4L2_CID_BANDWIDTH_AUTO: return Channel Bandwidth,
Auto;
+ case V4L2_CID_BANDWIDTH:return Channel Bandwidth;
default:
return NULL;
}
@@ -917,6 +919,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_LNA_GAIN_AUTO:
case V4L2_CID_MIXER_GAIN_AUTO:
case V4L2_CID_IF_GAIN_AUTO:
+ case V4L2_CID_BANDWIDTH_AUTO:
*type = V4L2_CTRL_TYPE_BOOLEAN;
*min = 0;
*max = *step = 1;
@@ -1078,6 +1081,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_LNA_GAIN:
case V4L2_CID_MIXER_GAIN:
case V4L2_CID_IF_GAIN:
+ case V4L2_CID_BANDWIDTH:
*flags |= V4L2_CTRL_FLAG_SLIDER;
break;
case V4L2_CID_PAN_RELATIVE:
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 076fa34..3cf68a6 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -905,5 +905,7 @@ enum v4l2_deemphasis {
#define V4L2_CID_MIXER_GAIN (V4L2_CID_RF_TUNER_CLASS_BASE +
4)
#define V4L2_CID_IF_GAIN_AUTO
(V4L2_CID_RF_TUNER_CLASS_BASE + 5)
#define V4L2_CID_IF_GAIN (V4L2_CID_RF_TUNER_CLASS_BASE +
6)
+#define V4L2_CID_BANDWIDTH_AUTO
(V4L2_CID_RF_TUNER_CLASS_BASE + 7)
+#define V4L2_CID_BANDWIDTH (V4L2_CID_RF_TUNER_CLASS_BASE +
8)
This definitely needs a prefix. Bandwidth can refer to so many things that
we have to be clear here.
Hans
#endif
--
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] of: move common endpoint parsing to drivers/media
This patch adds a new struct of_endpoint which is embedded in struct
v4l2_of_endpoint and contains the endpoint properties that are not V4L2
specific: port number, endpoint id, local device tree node.
of_graph_parse_endpoint parses those properties and is used by
v4l2_of_parse_endpoint, which just adds the V4L2 MBUS information
to the containing v4l2_of_endpoint structure. of_graph_parse_endpoint
is split out so that non-V4L2 drivers don't have to open code reading
the port and endpoint ids from the reg properties.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/of_graph.c | 32
drivers/media/v4l2-core/v4l2-of.c | 16 +++-
include/media/of_graph.h | 20
include/media/v4l2-of.h | 9 +++--
4 files changed, 58 insertions(+), 19 deletions(-)
diff --git a/drivers/media/of_graph.c b/drivers/media/of_graph.c
index aa526d7..5d1448a 100644
--- a/drivers/media/of_graph.c
+++ b/drivers/media/of_graph.c
@@ -14,6 +14,38 @@
#include linux/kernel.h
#include linux/of.h
#include linux/types.h
+#include media/of_graph.h
+
+/**
+ * of_graph_parse_endpoint() - parse common endpoint node properties
+ * @node: pointer to endpoint device_node
+ * @endpoint: pointer to the OF endpoint data structure
+ *
+ * All properties are optional. If none are found, we don't set any flags.
+ * This means the port has a static configuration and no properties have
+ * to be specified explicitly.
+ * The caller should hold a reference to @node.
+ */
+int of_graph_parse_endpoint(const struct device_node *node,
+ struct of_endpoint *endpoint)
+{
+ struct device_node *port_node = of_get_parent(node);
+
+ memset(endpoint, 0, sizeof(*endpoint));
+
+ endpoint-local_node = node;
+ /*
+* It doesn't matter whether the two calls below succeed.
+* If they don't then the default value 0 is used.
+*/
+ of_property_read_u32(port_node, reg, endpoint-port);
+ of_property_read_u32(node, reg, endpoint-id);
+
+ of_node_put(port_node);
+
+ return 0;
+}
+EXPORT_SYMBOL(of_graph_parse_endpoint);
/**
* of_graph_get_next_endpoint() - get next endpoint node
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c
index f919db3..a338c88 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -127,17 +127,9 @@ static void v4l2_of_parse_parallel_bus(const struct
device_node *node,
int v4l2_of_parse_endpoint(const struct device_node *node,
struct v4l2_of_endpoint *endpoint)
{
- struct device_node *port_node = of_get_parent(node);
-
- memset(endpoint, 0, offsetof(struct v4l2_of_endpoint, head));
-
- endpoint-local_node = node;
- /*
-* It doesn't matter whether the two calls below succeed.
-* If they don't then the default value 0 is used.
-*/
- of_property_read_u32(port_node, reg, endpoint-port);
- of_property_read_u32(node, reg, endpoint-id);
+ ret = of_graph_parse_endpoint(node, endpoint-ep);
+ endpoint-bus_type = 0;
+ memset(endpoint-bus, 0, sizeof(endpoint-bus));
v4l2_of_parse_csi_bus(node, endpoint);
/*
@@ -147,8 +139,6 @@ int v4l2_of_parse_endpoint(const struct device_node *node,
if (endpoint-bus.mipi_csi2.flags == 0)
v4l2_of_parse_parallel_bus(node, endpoint);
- of_node_put(port_node);
-
return 0;
}
EXPORT_SYMBOL(v4l2_of_parse_endpoint);
diff --git a/include/media/of_graph.h b/include/media/of_graph.h
index 3bbeb60..2b233db 100644
--- a/include/media/of_graph.h
+++ b/include/media/of_graph.h
@@ -14,7 +14,21 @@
#ifndef __LINUX_OF_GRAPH_H
#define __LINUX_OF_GRAPH_H
+/**
+ * struct of_endpoint - the OF graph endpoint data structure
+ * @port: identifier (value of reg property) of a port this endpoint belongs to
+ * @id: identifier (value of reg property) of this endpoint
+ * @local_node: pointer to device_node of this endpoint
+ */
+struct of_endpoint {
+ unsigned int port;
+ unsigned int id;
+ const struct device_node *local_node;
+};
+
#ifdef CONFIG_OF
+int of_graph_parse_endpoint(const struct device_node *node,
+ struct of_endpoint *endpoint);
struct device_node *of_graph_get_next_endpoint(const struct device_node
*parent,
struct device_node *previous);
struct device_node *of_graph_get_remote_port_parent(
@@ -22,6 +36,12 @@ struct device_node *of_graph_get_remote_port_parent(
struct device_node *of_graph_get_remote_port(const struct device_node *node);
#else
+static inline int of_graph_parse_endpoint(const struct device_node *node,
+ struct of_endpoint *endpoint);
+{
+ return -ENOSYS;
+}
+
static inline struct device_node *of_graph_get_next_endpoint(
Re: [REVIEW PATCH 3/6] v4l: reorganize RF tuner control ID numbers
On 14.02.2014 16:20, Hans Verkuil wrote:
Hi Antti,
On 02/10/2014 05:17 PM, Antti Palosaari wrote:
It appears that controls are ordered by ID number. Change order of
controls by reorganizing assigned IDs now as we can. It is not
reasonable possible after the API is released. Leave some spare
space between IDs too for future extensions.
Am I missing something? I see no reason for this patch or for adding the
spare space.
It appears that controls are ordered by ID number
I used app called v4l2ucp and at least it seems to organize those
controls by ID. Is there some way to say application how those are
organized?
regards
Antti
Regards,
Hans
Cc: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Antti Palosaari cr...@iki.fi
---
include/uapi/linux/v4l2-controls.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 3cf68a6..cc488c3 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -899,13 +899,13 @@ enum v4l2_deemphasis {
#define V4L2_CID_RF_TUNER_CLASS_BASE (V4L2_CTRL_CLASS_RF_TUNER |
0x900)
#define V4L2_CID_RF_TUNER_CLASS
(V4L2_CTRL_CLASS_RF_TUNER | 1)
-#define V4L2_CID_LNA_GAIN_AUTO (V4L2_CID_RF_TUNER_CLASS_BASE +
1)
-#define V4L2_CID_LNA_GAIN (V4L2_CID_RF_TUNER_CLASS_BASE +
2)
-#define V4L2_CID_MIXER_GAIN_AUTO (V4L2_CID_RF_TUNER_CLASS_BASE +
3)
-#define V4L2_CID_MIXER_GAIN(V4L2_CID_RF_TUNER_CLASS_BASE +
4)
-#define V4L2_CID_IF_GAIN_AUTO (V4L2_CID_RF_TUNER_CLASS_BASE +
5)
-#define V4L2_CID_IF_GAIN (V4L2_CID_RF_TUNER_CLASS_BASE +
6)
-#define V4L2_CID_BANDWIDTH_AUTO
(V4L2_CID_RF_TUNER_CLASS_BASE + 7)
-#define V4L2_CID_BANDWIDTH (V4L2_CID_RF_TUNER_CLASS_BASE +
8)
+#define V4L2_CID_BANDWIDTH_AUTO
(V4L2_CID_RF_TUNER_CLASS_BASE + 11)
+#define V4L2_CID_BANDWIDTH (V4L2_CID_RF_TUNER_CLASS_BASE +
12)
+#define V4L2_CID_LNA_GAIN_AUTO (V4L2_CID_RF_TUNER_CLASS_BASE +
41)
+#define V4L2_CID_LNA_GAIN (V4L2_CID_RF_TUNER_CLASS_BASE +
42)
+#define V4L2_CID_MIXER_GAIN_AUTO (V4L2_CID_RF_TUNER_CLASS_BASE +
51)
+#define V4L2_CID_MIXER_GAIN(V4L2_CID_RF_TUNER_CLASS_BASE +
52)
+#define V4L2_CID_IF_GAIN_AUTO (V4L2_CID_RF_TUNER_CLASS_BASE +
61)
+#define V4L2_CID_IF_GAIN (V4L2_CID_RF_TUNER_CLASS_BASE +
62)
#endif
--
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: [REVIEW PATCH 0/5] SDR API - Mirics MSi3101 driver
Hi Antti, Just one very tiny thing: in patch 1 in msi3101_template you added this line: + .debug= 0, Please remove. Fields initialized to 0 should in general be dropped since the compiler sets it to 0 already, and eventually the debug field will disappear anyway since you can set it by doing echo 1 /sys/class/video4linux/video0/debug Regards, Hans On 02/10/2014 08:28 PM, Antti Palosaari wrote: Split / group / merge changes as requested by Hans. Antti Antti Palosaari (5): msi3101: convert to SDR API msi001: Mirics MSi001 silicon tuner driver msi3101: use msi001 tuner driver MAINTAINERS: add msi001 driver MAINTAINERS: add msi3101 driver MAINTAINERS | 20 + drivers/staging/media/msi3101/Kconfig |7 +- drivers/staging/media/msi3101/Makefile |1 + drivers/staging/media/msi3101/msi001.c | 499 + drivers/staging/media/msi3101/sdr-msi3101.c | 1558 ++- 5 files changed, 1095 insertions(+), 990 deletions(-) create mode 100644 drivers/staging/media/msi3101/msi001.c -- 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: [REVIEW PATCH 1/6] v4l: add RF tuner gain controls
On 14.02.2014 16:30, Hans Verkuil wrote:
On 02/10/2014 05:17 PM, Antti Palosaari wrote:
Modern silicon RF tuners used nowadays has many controllable gain
stages on signal path. Usually, but not always, there is at least
3 gain stages. Also on some cases there could be multiple gain
stages within the ones specified here. However, I think that having
these three controllable gain stages offers enough fine-tuning for
real use cases.
1) LNA gain. That is first gain just after antenna input.
2) Mixer gain. It is located quite middle of the signal path, where
RF signal is down-converted to IF/BB.
3) IF gain. That is last gain in order to adjust output signal level
to optimal level for receiving party (usually demodulator ADC).
Each gain stage could be set rather often both manual or automatic
(AGC) mode. Due to that add separate controls for controlling
operation mode.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/v4l2-core/v4l2-ctrls.c | 15 +++
include/uapi/linux/v4l2-controls.h | 11 +++
2 files changed, 26 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 6ff002b..d201f61 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -857,6 +857,14 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_FM_RX_CLASS: return FM Radio Receiver
Controls;
case V4L2_CID_TUNE_DEEMPHASIS: return De-Emphasis;
case V4L2_CID_RDS_RECEPTION:return RDS Reception;
+
+ case V4L2_CID_RF_TUNER_CLASS: return RF Tuner Controls;
+ case V4L2_CID_LNA_GAIN_AUTO:return LNA Gain, Auto;
+ case V4L2_CID_LNA_GAIN: return LNA Gain;
+ case V4L2_CID_MIXER_GAIN_AUTO: return Mixer Gain, Auto;
+ case V4L2_CID_MIXER_GAIN: return Mixer Gain;
+ case V4L2_CID_IF_GAIN_AUTO: return IF Gain, Auto;
+ case V4L2_CID_IF_GAIN: return IF Gain;
default:
return NULL;
}
@@ -906,6 +914,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_WIDE_DYNAMIC_RANGE:
case V4L2_CID_IMAGE_STABILIZATION:
case V4L2_CID_RDS_RECEPTION:
+ case V4L2_CID_LNA_GAIN_AUTO:
+ case V4L2_CID_MIXER_GAIN_AUTO:
+ case V4L2_CID_IF_GAIN_AUTO:
*type = V4L2_CTRL_TYPE_BOOLEAN;
*min = 0;
*max = *step = 1;
@@ -991,6 +1002,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_IMAGE_PROC_CLASS:
case V4L2_CID_DV_CLASS:
case V4L2_CID_FM_RX_CLASS:
+ case V4L2_CID_RF_TUNER_CLASS:
*type = V4L2_CTRL_TYPE_CTRL_CLASS;
/* You can neither read not write these */
*flags |= V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_WRITE_ONLY;
@@ -1063,6 +1075,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_PILOT_TONE_FREQUENCY:
case V4L2_CID_TUNE_POWER_LEVEL:
case V4L2_CID_TUNE_ANTENNA_CAPACITOR:
+ case V4L2_CID_LNA_GAIN:
+ case V4L2_CID_MIXER_GAIN:
+ case V4L2_CID_IF_GAIN:
*flags |= V4L2_CTRL_FLAG_SLIDER;
break;
case V4L2_CID_PAN_RELATIVE:
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 2cbe605..076fa34 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -60,6 +60,7 @@
#define V4L2_CTRL_CLASS_IMAGE_PROC0x009f /* Image processing
controls */
#define V4L2_CTRL_CLASS_DV0x00a0 /* Digital Video
controls */
#define V4L2_CTRL_CLASS_FM_RX 0x00a1 /* FM Receiver controls
*/
+#define V4L2_CTRL_CLASS_RF_TUNER 0x00a2 /* RF tuner controls */
/* User-class control IDs */
@@ -895,4 +896,14 @@ enum v4l2_deemphasis {
#define V4L2_CID_RDS_RECEPTION
(V4L2_CID_FM_RX_CLASS_BASE + 2)
+#define V4L2_CID_RF_TUNER_CLASS_BASE (V4L2_CTRL_CLASS_RF_TUNER |
0x900)
+#define V4L2_CID_RF_TUNER_CLASS
(V4L2_CTRL_CLASS_RF_TUNER | 1)
+
+#define V4L2_CID_LNA_GAIN_AUTO (V4L2_CID_RF_TUNER_CLASS_BASE +
1)
+#define V4L2_CID_LNA_GAIN (V4L2_CID_RF_TUNER_CLASS_BASE +
2)
+#define V4L2_CID_MIXER_GAIN_AUTO (V4L2_CID_RF_TUNER_CLASS_BASE +
3)
+#define V4L2_CID_MIXER_GAIN(V4L2_CID_RF_TUNER_CLASS_BASE +
4)
+#define V4L2_CID_IF_GAIN_AUTO (V4L2_CID_RF_TUNER_CLASS_BASE +
5)
+#define V4L2_CID_IF_GAIN (V4L2_CID_RF_TUNER_CLASS_BASE +
6)
I would prefer to give these control defines a prefix:
V4L2_CID_RF_TUNER_MIXER_GAIN_AUTO (or possibly V4L2_CID_RF_TNR_...)
'MIXER_GAIN' by itself does not make it clear it relates
Re: [REVIEW PATCH 3/6] v4l: reorganize RF tuner control ID numbers
On 02/14/2014 03:36 PM, Antti Palosaari wrote:
On 14.02.2014 16:20, Hans Verkuil wrote:
Hi Antti,
On 02/10/2014 05:17 PM, Antti Palosaari wrote:
It appears that controls are ordered by ID number. Change order of
controls by reorganizing assigned IDs now as we can. It is not
reasonable possible after the API is released. Leave some spare
space between IDs too for future extensions.
Am I missing something? I see no reason for this patch or for adding the
spare space.
It appears that controls are ordered by ID number
I used app called v4l2ucp and at least it seems to organize those
controls by ID. Is there some way to say application how those are
organized?
Ah, now I get it. When enumerating controls they are enumerated by
increasing control ID. Yes, that's correct.
The commit message could be improved since I completely missed the point :-)
Regards,
Hans
regards
Antti
Regards,
Hans
Cc: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Antti Palosaari cr...@iki.fi
---
include/uapi/linux/v4l2-controls.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 3cf68a6..cc488c3 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -899,13 +899,13 @@ enum v4l2_deemphasis {
#define V4L2_CID_RF_TUNER_CLASS_BASE
(V4L2_CTRL_CLASS_RF_TUNER | 0x900)
#define V4L2_CID_RF_TUNER_CLASS
(V4L2_CTRL_CLASS_RF_TUNER | 1)
-#define V4L2_CID_LNA_GAIN_AUTO
(V4L2_CID_RF_TUNER_CLASS_BASE + 1)
-#define V4L2_CID_LNA_GAIN (V4L2_CID_RF_TUNER_CLASS_BASE +
2)
-#define V4L2_CID_MIXER_GAIN_AUTO (V4L2_CID_RF_TUNER_CLASS_BASE +
3)
-#define V4L2_CID_MIXER_GAIN
(V4L2_CID_RF_TUNER_CLASS_BASE + 4)
-#define V4L2_CID_IF_GAIN_AUTO
(V4L2_CID_RF_TUNER_CLASS_BASE + 5)
-#define V4L2_CID_IF_GAIN (V4L2_CID_RF_TUNER_CLASS_BASE +
6)
-#define V4L2_CID_BANDWIDTH_AUTO
(V4L2_CID_RF_TUNER_CLASS_BASE + 7)
-#define V4L2_CID_BANDWIDTH (V4L2_CID_RF_TUNER_CLASS_BASE +
8)
+#define V4L2_CID_BANDWIDTH_AUTO
(V4L2_CID_RF_TUNER_CLASS_BASE + 11)
+#define V4L2_CID_BANDWIDTH (V4L2_CID_RF_TUNER_CLASS_BASE +
12)
+#define V4L2_CID_LNA_GAIN_AUTO
(V4L2_CID_RF_TUNER_CLASS_BASE + 41)
+#define V4L2_CID_LNA_GAIN (V4L2_CID_RF_TUNER_CLASS_BASE +
42)
+#define V4L2_CID_MIXER_GAIN_AUTO (V4L2_CID_RF_TUNER_CLASS_BASE +
51)
+#define V4L2_CID_MIXER_GAIN
(V4L2_CID_RF_TUNER_CLASS_BASE + 52)
+#define V4L2_CID_IF_GAIN_AUTO
(V4L2_CID_RF_TUNER_CLASS_BASE + 61)
+#define V4L2_CID_IF_GAIN (V4L2_CID_RF_TUNER_CLASS_BASE +
62)
#endif
--
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: [REVIEW PATCH 0/5] SDR API - Mirics MSi3101 driver
On 02/14/2014 03:40 PM, Hans Verkuil wrote: Hi Antti, Just one very tiny thing: in patch 1 in msi3101_template you added this line: + .debug= 0, Please remove. Fields initialized to 0 should in general be dropped since the compiler sets it to 0 already, and eventually the debug field will disappear anyway since you can set it by doing echo 1 /sys/class/video4linux/video0/debug Sorry, forgot to mention that after making that small change you can add my Acked-by: Hans Verkuil hans.verk...@cisco.com for these 5 patches. Regards, Hans Regards, Hans On 02/10/2014 08:28 PM, Antti Palosaari wrote: Split / group / merge changes as requested by Hans. Antti Antti Palosaari (5): msi3101: convert to SDR API msi001: Mirics MSi001 silicon tuner driver msi3101: use msi001 tuner driver MAINTAINERS: add msi001 driver MAINTAINERS: add msi3101 driver MAINTAINERS | 20 + drivers/staging/media/msi3101/Kconfig |7 +- drivers/staging/media/msi3101/Makefile |1 + drivers/staging/media/msi3101/msi001.c | 499 + drivers/staging/media/msi3101/sdr-msi3101.c | 1558 ++- 5 files changed, 1095 insertions(+), 990 deletions(-) create mode 100644 drivers/staging/media/msi3101/msi001.c -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 1/6] v4l: add RF tuner gain controls
On 02/14/2014 03:44 PM, Antti Palosaari wrote:
On 14.02.2014 16:30, Hans Verkuil wrote:
On 02/10/2014 05:17 PM, Antti Palosaari wrote:
Modern silicon RF tuners used nowadays has many controllable gain
stages on signal path. Usually, but not always, there is at least
3 gain stages. Also on some cases there could be multiple gain
stages within the ones specified here. However, I think that having
these three controllable gain stages offers enough fine-tuning for
real use cases.
1) LNA gain. That is first gain just after antenna input.
2) Mixer gain. It is located quite middle of the signal path, where
RF signal is down-converted to IF/BB.
3) IF gain. That is last gain in order to adjust output signal level
to optimal level for receiving party (usually demodulator ADC).
Each gain stage could be set rather often both manual or automatic
(AGC) mode. Due to that add separate controls for controlling
operation mode.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/v4l2-core/v4l2-ctrls.c | 15 +++
include/uapi/linux/v4l2-controls.h | 11 +++
2 files changed, 26 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 6ff002b..d201f61 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -857,6 +857,14 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_FM_RX_CLASS: return FM Radio Receiver
Controls;
case V4L2_CID_TUNE_DEEMPHASIS: return De-Emphasis;
case V4L2_CID_RDS_RECEPTION:return RDS Reception;
+
+ case V4L2_CID_RF_TUNER_CLASS: return RF Tuner Controls;
+ case V4L2_CID_LNA_GAIN_AUTO:return LNA Gain, Auto;
+ case V4L2_CID_LNA_GAIN: return LNA Gain;
+ case V4L2_CID_MIXER_GAIN_AUTO: return Mixer Gain, Auto;
+ case V4L2_CID_MIXER_GAIN: return Mixer Gain;
+ case V4L2_CID_IF_GAIN_AUTO: return IF Gain, Auto;
+ case V4L2_CID_IF_GAIN: return IF Gain;
default:
return NULL;
}
@@ -906,6 +914,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_WIDE_DYNAMIC_RANGE:
case V4L2_CID_IMAGE_STABILIZATION:
case V4L2_CID_RDS_RECEPTION:
+ case V4L2_CID_LNA_GAIN_AUTO:
+ case V4L2_CID_MIXER_GAIN_AUTO:
+ case V4L2_CID_IF_GAIN_AUTO:
*type = V4L2_CTRL_TYPE_BOOLEAN;
*min = 0;
*max = *step = 1;
@@ -991,6 +1002,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_IMAGE_PROC_CLASS:
case V4L2_CID_DV_CLASS:
case V4L2_CID_FM_RX_CLASS:
+ case V4L2_CID_RF_TUNER_CLASS:
*type = V4L2_CTRL_TYPE_CTRL_CLASS;
/* You can neither read not write these */
*flags |= V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_WRITE_ONLY;
@@ -1063,6 +1075,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_PILOT_TONE_FREQUENCY:
case V4L2_CID_TUNE_POWER_LEVEL:
case V4L2_CID_TUNE_ANTENNA_CAPACITOR:
+ case V4L2_CID_LNA_GAIN:
+ case V4L2_CID_MIXER_GAIN:
+ case V4L2_CID_IF_GAIN:
*flags |= V4L2_CTRL_FLAG_SLIDER;
break;
case V4L2_CID_PAN_RELATIVE:
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 2cbe605..076fa34 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -60,6 +60,7 @@
#define V4L2_CTRL_CLASS_IMAGE_PROC0x009f /* Image
processing controls */
#define V4L2_CTRL_CLASS_DV0x00a0 /* Digital
Video controls */
#define V4L2_CTRL_CLASS_FM_RX 0x00a1 /* FM Receiver
controls */
+#define V4L2_CTRL_CLASS_RF_TUNER 0x00a2 /* RF tuner controls */
/* User-class control IDs */
@@ -895,4 +896,14 @@ enum v4l2_deemphasis {
#define V4L2_CID_RDS_RECEPTION
(V4L2_CID_FM_RX_CLASS_BASE + 2)
+#define V4L2_CID_RF_TUNER_CLASS_BASE
(V4L2_CTRL_CLASS_RF_TUNER | 0x900)
+#define V4L2_CID_RF_TUNER_CLASS
(V4L2_CTRL_CLASS_RF_TUNER | 1)
+
+#define V4L2_CID_LNA_GAIN_AUTO
(V4L2_CID_RF_TUNER_CLASS_BASE + 1)
+#define V4L2_CID_LNA_GAIN (V4L2_CID_RF_TUNER_CLASS_BASE +
2)
+#define V4L2_CID_MIXER_GAIN_AUTO (V4L2_CID_RF_TUNER_CLASS_BASE +
3)
+#define V4L2_CID_MIXER_GAIN
(V4L2_CID_RF_TUNER_CLASS_BASE + 4)
+#define V4L2_CID_IF_GAIN_AUTO
(V4L2_CID_RF_TUNER_CLASS_BASE + 5)
+#define V4L2_CID_IF_GAIN (V4L2_CID_RF_TUNER_CLASS_BASE +
6)
I would prefer to give these control defines a prefix:
V4L2_CID_RF_TUNER_MIXER_GAIN_AUTO (or possibly V4L2_CID_RF_TNR_...)
'MIXER_GAIN' by itself does not make it clear it
Re: Instructions to release your payment.
Attention Sir, Following an application brought, seeking the release of your due payment through British bank, I am directed to inform you that the application has been approved and Natwest bank of London has been mandated to make transfer of your payment to the bank account you will nominate. Please kindly reply for immediate release of your US$6.2 Million to you nominates account. Sir, for the avoidance of doubts, reconfirm the following information to me to enable us forward same to Natwest bank to contact you for your payment. Name: Address: Tel/Fax No.: Nationality: Occupation: Date of birth: As soon as I received the above information, I will forward them to Natwest bank to contact you for your approved payment. Please see in the attachment, letter I wrote to Natwest bank informing them of the transaction Yours faithfully Dr.William Davies Chairman,British Banking Regulatory Board. -- 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: [REVIEW PATCH 08/16] rtl2832_sdr: Realtek RTL2832 SDR driver module
On 02/11/2014 03:04 AM, Antti Palosaari wrote:
Implement SDR driver for Realtek RTL2832U chip as a DVB extension
module. SDR module is attached by DVB USB RTL28XXU driver as a DVB
SEC (satellite equipment controller) module. Abusing unused SEC here
has no harm as that is DVB-T only frontend.
SDR functionality is provided by RTL2832 DVB-T demodulator. I suspect
it is originally planned for DAB and FM, but it could be abused general
SDR, due to modern silicon tuners that has wide frequency range and a
lot of configurable parameters (filters, gains, ...).
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/44461
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/staging/media/Kconfig|2 +
drivers/staging/media/Makefile |2 +
drivers/staging/media/rtl2832u_sdr/Kconfig |7 +
drivers/staging/media/rtl2832u_sdr/Makefile |6 +
drivers/staging/media/rtl2832u_sdr/rtl2832_sdr.c | 1470
++
drivers/staging/media/rtl2832u_sdr/rtl2832_sdr.h | 51 +
6 files changed, 1538 insertions(+)
create mode 100644 drivers/staging/media/rtl2832u_sdr/Kconfig
create mode 100644 drivers/staging/media/rtl2832u_sdr/Makefile
create mode 100644 drivers/staging/media/rtl2832u_sdr/rtl2832_sdr.c
create mode 100644 drivers/staging/media/rtl2832u_sdr/rtl2832_sdr.h
diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig
index 22b0c9d..a9f2e63 100644
--- a/drivers/staging/media/Kconfig
+++ b/drivers/staging/media/Kconfig
@@ -41,6 +41,8 @@ source drivers/staging/media/solo6x10/Kconfig
source drivers/staging/media/omap4iss/Kconfig
+source drivers/staging/media/rtl2832u_sdr/Kconfig
+
# Keep LIRC at the end, as it has sub-menus
source drivers/staging/media/lirc/Kconfig
diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile
index bedc62a..8e2c5d2 100644
--- a/drivers/staging/media/Makefile
+++ b/drivers/staging/media/Makefile
@@ -11,3 +11,5 @@ obj-$(CONFIG_VIDEO_OMAP4) += omap4iss/
obj-$(CONFIG_USB_SN9C102) += sn9c102/
obj-$(CONFIG_VIDEO_OMAP2) += omap24xx/
obj-$(CONFIG_VIDEO_TCM825X) += omap24xx/
+obj-$(CONFIG_DVB_RTL2832_SDR)+= rtl2832u_sdr/
+
diff --git a/drivers/staging/media/rtl2832u_sdr/Kconfig
b/drivers/staging/media/rtl2832u_sdr/Kconfig
new file mode 100644
index 000..3ede5fe
--- /dev/null
+++ b/drivers/staging/media/rtl2832u_sdr/Kconfig
@@ -0,0 +1,7 @@
+config DVB_RTL2832_SDR
+ tristate Realtek RTL2832 SDR
+ depends on USB DVB_CORE I2C VIDEO_V4L2 DVB_USB_RTL28XXU
+ select DVB_RTL2832
+ select VIDEOBUF2_VMALLOC
+ default m if !MEDIA_SUBDRV_AUTOSELECT
+
diff --git a/drivers/staging/media/rtl2832u_sdr/Makefile
b/drivers/staging/media/rtl2832u_sdr/Makefile
new file mode 100644
index 000..7e00a0d
--- /dev/null
+++ b/drivers/staging/media/rtl2832u_sdr/Makefile
@@ -0,0 +1,6 @@
+obj-$(CONFIG_DVB_RTL2832_SDR) += rtl2832_sdr.o
+
+ccflags-y += -Idrivers/media/dvb-core
+ccflags-y += -Idrivers/media/dvb-frontends
+ccflags-y += -Idrivers/media/tuners
+ccflags-y += -Idrivers/media/usb/dvb-usb-v2
diff --git a/drivers/staging/media/rtl2832u_sdr/rtl2832_sdr.c
b/drivers/staging/media/rtl2832u_sdr/rtl2832_sdr.c
new file mode 100644
index 000..9265424
--- /dev/null
+++ b/drivers/staging/media/rtl2832u_sdr/rtl2832_sdr.c
@@ -0,0 +1,1470 @@
+/*
+ * Realtek RTL2832U SDR driver
+ *
+ * Copyright (C) 2013 Antti Palosaari cr...@iki.fi
+ *
+ *This program is free software; you can redistribute it and/or modify
+ *it under the terms of the GNU General Public License as published by
+ *the Free Software Foundation; either version 2 of the License, or
+ *(at your option) any later version.
+ *
+ *This program is distributed in the hope that it will be useful,
+ *but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ *GNU General Public License for more details.
+ *
+ *You should have received a copy of the GNU General Public License along
+ *with this program; if not, write to the Free Software Foundation, Inc.,
+ *51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * GNU Radio plugin gr-kernel for device usage will be on:
+ * http://git.linuxtv.org/anttip/gr-kernel.git
+ *
+ */
+
+#include dvb_frontend.h
+#include rtl2832_sdr.h
+#include dvb_usb.h
+
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-event.h
+#include media/videobuf2-vmalloc.h
+
+#include linux/jiffies.h
+#include linux/math64.h
+
+#define MAX_BULK_BUFS(10)
+#define BULK_BUFFER_SIZE (128 * 512)
+
+static const struct v4l2_frequency_band bands_adc[] = {
+ {
+ .tuner = 0,
+ .type = V4L2_TUNER_ADC,
+
Re: [REVIEW PATCH 13/16] rtl2832_sdr: expose e4000 controls to user
On 02/11/2014 03:04 AM, Antti Palosaari wrote:
E4000 tuner driver provides now some controls. Expose those to
userland.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/staging/media/rtl2832u_sdr/rtl2832_sdr.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/rtl2832u_sdr/rtl2832_sdr.c
b/drivers/staging/media/rtl2832u_sdr/rtl2832_sdr.c
index 9265424..18f8c56 100644
--- a/drivers/staging/media/rtl2832u_sdr/rtl2832_sdr.c
+++ b/drivers/staging/media/rtl2832u_sdr/rtl2832_sdr.c
@@ -25,6 +25,7 @@
#include dvb_frontend.h
#include rtl2832_sdr.h
#include dvb_usb.h
+#include e4000.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
@@ -1347,6 +1348,7 @@ struct dvb_frontend *rtl2832_sdr_attach(struct
dvb_frontend *fe,
struct rtl2832_sdr_state *s;
const struct v4l2_ctrl_ops *ops = rtl2832_sdr_ctrl_ops;
struct dvb_usb_device *d = i2c_get_adapdata(i2c);
+ struct v4l2_ctrl_handler *hdl;
s = kzalloc(sizeof(struct rtl2832_sdr_state), GFP_KERNEL);
if (s == NULL) {
@@ -1386,10 +1388,10 @@ struct dvb_frontend *rtl2832_sdr_attach(struct
dvb_frontend *fe,
/* Register controls */
switch (s-cfg-tuner) {
case RTL2832_TUNER_E4000:
- v4l2_ctrl_handler_init(s-hdl, 2);
- s-bandwidth_auto = v4l2_ctrl_new_std(s-hdl, ops,
V4L2_CID_BANDWIDTH_AUTO, 0, 1, 1, 1);
- s-bandwidth = v4l2_ctrl_new_std(s-hdl, ops,
V4L2_CID_BANDWIDTH, 430, 1100, 10, 430);
- v4l2_ctrl_auto_cluster(2, s-bandwidth_auto, 0, false);
+ hdl = e4000_get_ctrl_handler(fe);
+ v4l2_ctrl_handler_init(s-hdl, 0);
Use the same number as is used in e4000: 8.
It's a hint of the number of controls that the handler will contain and it
affects
the number of buckets used for the hash table. Putting in a 0 will result in a
single
bucket which means that all controls end up in a single linked list. Changing
it to
8 will result in two buckets, which performs a bit better.
Regards,
Hans
+ if (hdl)
+ v4l2_ctrl_add_handler(s-hdl, hdl, NULL);
break;
case RTL2832_TUNER_R820T:
v4l2_ctrl_handler_init(s-hdl, 2);
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
SAA7134 warning during resume from S3: regression 3.8.13 - 3.9.0
This is also on bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=69581 [1.] One line summary of the problem: Kernel gives a oops warning during resume from S3 sleep. [2.] Full description of the problem/report: OS is Debian Lenny, with vanilla kernel. It happens the same after upgrade to Squeeze. I've tried with kernels over kernels to find the point and I've found: the latest working kernel is 3.8.13, the first failing is 3.9.0 I suspend the machine with s2ram and it goes off. During the resume it writes that warning, then it seem to work normally, except for serial redirection of console. I use redirection of console to serial port (with lilo directive: append= console=ttyS0 console=tty0) and I check the messages in another machine. This stops working as soon as I resume. It begins to send mangled lines and it doesn't work again until the next full restart. Only the serial redirection has this problem, the local console works. The serial console issue has its own thread on bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=69751 and it happens also with kernels = 3.8.13. For now I've seen that it's between 2.6.24.7 and 2.6.34.15, I'll do further tests and I'll report in the proper thread. Going back to the SAA7134 warning: dmesg: PM: Syncing filesystems ... done. PM: Preparing system for mem sleep Freezing user space processes ... (elapsed 0.001 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.006 seconds) done. PM: Entering mem sleep Suspending console(s) (use no_console_suspend to debug) sd 5:0:0:0: [sdc] Synchronizing SCSI cache sd 4:0:0:0: [sdb] Synchronizing SCSI cache sd 5:0:0:0: [sdc] Stopping disk sd 4:0:0:0: [sdb] Stopping disk sd 1:0:0:0: [sda] Synchronizing SCSI cache parport_pc 00:09: disabled serial 00:08: disabled serial 00:08: System wakeup disabled by ACPI serial 00:07: disabled serial 00:07: System wakeup disabled by ACPI sd 1:0:0:0: [sda] Stopping disk PM: suspend of devices complete after 859.795 msecs PM: late suspend of devices complete after 0.144 msecs pcieport :00:1c.5: System wakeup enabled by ACPI ehci-pci :00:1d.7: System wakeup enabled by ACPI uhci_hcd :00:1d.2: System wakeup enabled by ACPI uhci_hcd :00:1d.1: System wakeup enabled by ACPI uhci_hcd :00:1d.0: System wakeup enabled by ACPI ehci-pci :00:1a.7: System wakeup enabled by ACPI uhci_hcd :00:1a.2: System wakeup enabled by ACPI uhci_hcd :00:1a.1: System wakeup enabled by ACPI uhci_hcd :00:1a.0: System wakeup enabled by ACPI PM: noirq suspend of devices complete after 32.930 msecs ACPI: Preparing to enter system sleep state S3 PM: Saving platform NVS memory Disabling non-boot CPUs ... smpboot: CPU 1 is now offline smpboot: CPU 2 is now offline smpboot: CPU 3 is now offline ACPI: Low-level resume complete PM: Restoring platform NVS memory Enabling non-boot CPUs ... x86: Booting SMP configuration: smpboot: Booting Node 0 Processor 1 APIC 0x1 Initializing CPU#1 CPU1 is up smpboot: Booting Node 0 Processor 2 APIC 0x3 Initializing CPU#2 CPU2 is up smpboot: Booting Node 0 Processor 3 APIC 0x2 Initializing CPU#3 CPU3 is up ACPI: Waking up from system sleep state S3 uhci_hcd :00:1a.0: System wakeup disabled by ACPI uhci_hcd :00:1a.1: System wakeup disabled by ACPI uhci_hcd :00:1a.2: System wakeup disabled by ACPI ehci-pci :00:1a.7: System wakeup disabled by ACPI uhci_hcd :00:1d.0: System wakeup disabled by ACPI uhci_hcd :00:1d.1: System wakeup disabled by ACPI uhci_hcd :00:1d.2: System wakeup disabled by ACPI ehci-pci :00:1d.7: System wakeup disabled by ACPI PM: noirq resume of devices complete after 99.105 msecs PM: early resume of devices complete after 0.059 msecs usb usb3: root hub lost power or was reset usb usb4: root hub lost power or was reset usb usb5: root hub lost power or was reset snd_hda_intel :00:1b.0: irq 45 for MSI/MSI-X usb usb6: root hub lost power or was reset usb usb7: root hub lost power or was reset pcieport :00:1c.5: System wakeup disabled by ACPI usb usb8: root hub lost power or was reset saa7133[0]: board init: gpio is 4 serial 00:07: activated serial 00:08: activated parport_pc 00:09: activated r8169 :03:00.0 eth0: link down [ cut here ] WARNING: CPU: 0 PID: 7928 at kernel/kmod.c:148 __request_module+0x34/0x1ae() Modules linked in: vmnet(O) vsock(O) vmci(O) vmmon(O) lp fbcon font bitblit softcursor i915 drm_kms_helper fb fbdev cfbcopyarea video backlight cfbimgblt cfbfillrect bnep nfsd lockd sunrpc fuse saa7134_alsa snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_seq_device cifs rfcomm bluetooth rfkill it87 hwmon_vid isofs zlib_inflate nls_utf8 nls_iso8859_1 nls_cp850 nls_cp437 nls_ascii cpuid vfat ntfs msdos fat udf nls_iso8859_15 softdog loop tda1004x saa7134_dvb videobuf_dvb dvb_core tda827x mousedev tda8290 tuner snd_hda_codec_realtek snd_hda_intel snd_hda_codec saa7134 v4l2_common usb_storage videodev r8169 snd_hwdep
Re: linux-next: Tree for Feb 14 (media/pci/ttpci/av7110_ir.c)
On 02/13/2014 09:28 PM, Stephen Rothwell wrote: Hi all, If you see failures in building this tree due to missing declarations of k..alloc/free, then it may be caused by commit 2bd59d48ebfb (cgroup: convert to kernfs). Please send Tejun Heo t...@kernel.org a patch adding an inclusion of linux/slab.h to the appropriate file(s). This tree fails (more than usual) the powerpc allyesconfig build. Changes since 20140213: on i386: when CONFIG_DVB_AV7110=y CONFIG_INPUT=m CONFIG_INPUT_EVDEV=m drivers/built-in.o: In function `input_sync': av7110_ir.c:(.text+0x247276): undefined reference to `input_event' drivers/built-in.o: In function `av7110_emit_key': av7110_ir.c:(.text+0x247308): undefined reference to `input_event' av7110_ir.c:(.text+0x24731e): undefined reference to `input_event' av7110_ir.c:(.text+0x247384): undefined reference to `input_event' av7110_ir.c:(.text+0x247399): undefined reference to `input_event' drivers/built-in.o:av7110_ir.c:(.text+0x2473da): more undefined references to `input_event' follow drivers/built-in.o: In function `av7110_ir_init': (.text+0x2475b7): undefined reference to `input_allocate_device' drivers/built-in.o: In function `av7110_ir_init': (.text+0x247738): undefined reference to `input_register_device' drivers/built-in.o: In function `av7110_ir_init': (.text+0x247748): undefined reference to `input_free_device' drivers/built-in.o: In function `av7110_ir_exit': (.text+0x24780a): undefined reference to `input_unregister_device' -- ~Randy -- 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] omap3isp: Don't try to locate external subdev for mem-to-mem pipelines
Memory-to-memory pipelines have no external subdev, we shouldn't try to
locate one and validate its configuration. The driver currently works by
chance due to another bug that results in failure to locate the external
subdev being ignored.
This gets rid of the omap3isp omap3isp: can't find source, failing now
error message in the kernel log when operating on a memory-to-memory
pipeline.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/omap3isp/ispvideo.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/media/platform/omap3isp/ispvideo.c
b/drivers/media/platform/omap3isp/ispvideo.c
index 856fdf5..313fd13 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -888,6 +888,10 @@ static int isp_video_check_external_subdevs(struct
isp_video *video,
unsigned int i;
int ret = 0;
+ /* Memory-to-memory pipelines have no external subdev. */
+ if (pipe-input != NULL)
+ return 0;
+
for (i = 0; i ARRAY_SIZE(ents); i++) {
/* Is the entity part of the pipeline? */
if (!(pipe-entities (1 ents[i]-id)))
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP capabilities, resizer
Hi Peter,
On Wednesday 12 February 2014 16:19:55 Peter Meerwald wrote:
Hello,
some more findings:
* the driver bug seen below was observed with kernel 3.7 and is already
fixed in more recent kernels, likely with commit 864a121274,
[media] v4l: Don't warn during link validation when encountering a V4L2
devnode
Correct. I tend to forget about bugs that have been fixed ;-)
* there still is a a confusing warning:
omap3isp omap3isp: can't find source, failing now
which may be addressed by the patch here https://linuxtv.org/patch/15200/,
but has not been applied
The patch won't apply anymore. I've just submitted two other patches (you've
been CCed) to fix the problem, could you please test them ?
* I have a test program, http://pmeerw.net/scaler.c, which exercises the
OMAP3 ISP resizer standalone with the pipeline given below; it crashes the
system quite reliably on 3.7 and recent kernels :(
the reason for the crash is that the ISP resizer can still be busy and
doesn't like to be turned off then; a little sleep before
omap3isp_sbl_disable() helps (or waiting for the ISP resize to become
idle, see the patch below)
I'm not sure what omap3isp_module_sync_idle() is supposed to do, it
immediately returns since we are in SINGLESHOT mode and
isp_pipeline_ready() is false
The function is supposed to wait until the module becomes idle. I'm not sure
why we don't call it for memory-to-memory pipelines, I need to investigate
that. Sakari, do you remember what we've done there ?
with below patch I am happily resizing...
// snip, RFC
From: Peter Meerwald p.meerw...@bct-electronic.com
Date: Wed, 12 Feb 2014 15:59:20 +0100
Subject: [PATCH] omap3isp: Wait for resizer to become idle before
disabling
---
drivers/media/platform/omap3isp/ispresizer.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/media/platform/omap3isp/ispresizer.c
b/drivers/media/platform/omap3isp/ispresizer.c
index d11fb26..fea98f7 100644
--- a/drivers/media/platform/omap3isp/ispresizer.c
+++ b/drivers/media/platform/omap3isp/ispresizer.c
@@ -1145,6 +1145,7 @@ static int resizer_set_stream(struct v4l2_subdev *sd,
int enable) struct isp_video *video_out = res-video_out;
struct isp_device *isp = to_isp_device(res);
struct device *dev = to_device(res);
+ unsigned long timeout = 0;
if (res-state == ISP_PIPELINE_STREAM_STOPPED) {
if (enable == ISP_PIPELINE_STREAM_STOPPED)
@@ -1176,6 +1177,15 @@ static int resizer_set_stream(struct v4l2_subdev *sd,
int enable) if (omap3isp_module_sync_idle(sd-entity, res-wait,
res-stopping))
dev_dbg(dev, %s: module stop timeout.\n,
sd-name);
+
+ while (omap3isp_resizer_busy(res)) {
+ if (timeout++ 1000) {
+ dev_alert(isp-dev, ISP resizer does not
become idle\n);
+ return -ETIMEDOUT;
+ }
+ udelay(100);
+ }
+
Let's try to avoid busy loops if possible. Does it help if you comment out the
condition at the top of omap3isp_module_sync_idle() ?
omap3isp_sbl_disable(isp, OMAP3_ISP_SBL_RESIZER_READ |
OMAP3_ISP_SBL_RESIZER_WRITE);
omap3isp_subclk_disable(isp, OMAP3_ISP_SUBCLK_RESIZER);
--
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
[PATCH 2/2] omap3isp: Don't ignore failure to locate external subdev
A failure to locate the external subdev for a non memory-to-memory
pipeline is a fatal error, don't ignore it.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/omap3isp/ispvideo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispvideo.c
b/drivers/media/platform/omap3isp/ispvideo.c
index 313fd13..a62cf0b 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -886,7 +886,7 @@ static int isp_video_check_external_subdevs(struct
isp_video *video,
struct v4l2_ext_controls ctrls;
struct v4l2_ext_control ctrl;
unsigned int i;
- int ret = 0;
+ int ret;
/* Memory-to-memory pipelines have no external subdev. */
if (pipe-input != NULL)
@@ -909,7 +909,7 @@ static int isp_video_check_external_subdevs(struct
isp_video *video,
if (!source) {
dev_warn(isp-dev, can't find source, failing now\n);
- return ret;
+ return -EINVAL;
}
if (media_entity_type(source) != MEDIA_ENT_T_V4L2_SUBDEV)
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAP3 ISP pipeline validation patches
Hello, Those two patches fix the OMAP3 ISP pipeline validation when locating the external subdevice. The code currently works by chance with memory-to-memory pipelines, as it tries to locate the external subdevice when none is available, but ignores the failure due to a bug. This patch set fixes both issues. Peter, could you check whether this fixes the warning you've reported ? Laurent Pinchart (2): omap3isp: Don't try to locate external subdev for mem-to-mem pipelines omap3isp: Don't ignore failure to locate external subdev drivers/media/platform/omap3isp/ispvideo.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) -- 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
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sat Feb 15 04:00:21 CET 2014 git branch: test git hash: 37e59f876bc710d67a30b660826a5e83e07101ce gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.12-6.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: WARNINGS linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-i686: OK linux-3.14-rc1-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK linux-3.13-x86_64: OK linux-3.14-rc1-x86_64: OK apps: OK spec-git: OK sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The Media Infrastructure API 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
