cron job: media_tree daily build: ERRORS
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: Fri Jan 3 04:00:32 CET 2014 git branch: test git hash: f7d40eea8e3e531f1517ab7eded552e8837ef5da gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.12-0.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: ERRORS 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: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-rc1-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: WARNINGS linux-3.12-x86_64: WARNINGS linux-3.13-rc1-x86_64: WARNINGS apps: OK spec-git: OK sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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
[GIT PULL FOR v3.14] More OMAP3 ISP fixes
Hi Mauro, The following changes since commit 7d459937dc09bb8e448d9985ec4623779427d8a5: [media] Add driver for Samsung S5K5BAF camera sensor (2013-12-21 07:01:36 -0200) are available in the git repository at: git://linuxtv.org/pinchartl/media.git omap3isp/next for you to fetch changes up to 7083663ca7326c8e36f0d145bef81a2edece: omap3isp: ccdc: Don't hang when the SBL fails to become idle (2014-01-02 03:06:44 +0100) Laurent Pinchart (3): omap3isp: Cancel streaming when a fatal error occurs omap3isp: Refactor modules stop failure handling omap3isp: ccdc: Don't hang when the SBL fails to become idle drivers/media/platform/omap3isp/isp.c | 53 ++--- drivers/media/platform/omap3isp/isp.h | 3 +++ drivers/media/platform/omap3isp/ispccdc.c | 2 ++ drivers/media/platform/omap3isp/ispvideo.c | 46 + drivers/media/platform/omap3isp/ispvideo.h | 2 ++ 5 files changed, 92 insertions(+), 14 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
Re: [PATCH v3 11/24] tvp5150: make read operations atomic
On 02.01.2014 20:20, Mauro Carvalho Chehab wrote:
Em Wed, 01 Jan 2014 19:52:08 +0100
Frank Schäfer escreveu:
Am 28.12.2013 13:16, schrieb Mauro Carvalho Chehab:
From: Mauro Carvalho Chehab
Instead of using two I2C operations between write and read,
use just one i2c_transfer. That allows I2C mutexes to not
let any other I2C transfer between the two.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/i2c/tvp5150.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index 89c0b13463b7..d6ba457fcf67 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -58,21 +58,19 @@ static int tvp5150_read(struct v4l2_subdev *sd, unsigned
char addr)
struct i2c_client *c = v4l2_get_subdevdata(sd);
unsigned char buffer[1];
int rc;
+ struct i2c_msg msg[] = {
+ { .addr = c->addr, .flags = 0,
+ .buf = &addr, .len = 1 },
I would use.buf = bufferhere, too.
Why? The address needed is already at addr, and it is also an unsigned char.
Using buffer would require an extra data copy.
You are still doing this...
+ { .addr = c->addr, .flags = I2C_M_RD,
+ .buf = buffer, .len = 1 }
+ };
buffer[0] = addr;
... here. ;)
- rc = i2c_master_send(c, buffer, 1);
- if (rc < 0) {
- v4l2_err(sd, "i2c i/o error: rc == %d (should be 1)\n", rc);
- return rc;
- }
-
- msleep(10);
That's the critical change.
I don't think so. I'm not sure why I added this at the first place on the
original patch with where I added this driver, but it is very doubtful
that a msleep() is needed here.
This code is really old (from the time I added support for WinTV USB 2).
I suspect I added the sleep there just because the I2C logs, during the
driver development phase, to be an exact mimic on what it was got via
USB dumps.
-
- rc = i2c_master_recv(c, buffer, 1);
- if (rc < 0) {
- v4l2_err(sd, "i2c i/o error: rc == %d (should be 1)\n", rc);
- return rc;
+ rc = i2c_transfer(c->adapter, msg, 2);
+ if (rc < 0 || rc != 2) {
+ v4l2_err(sd, "i2c i/o error: rc == %d (should be 2)\n", rc);
+ return rc < 0 ? rc : -EIO;
}
v4l2_dbg(2, debug, sd, "tvp5150: read 0x%02x = 0x%02x\n", addr, buffer[0]);
Looks good and works without problems with my HVR-900 and WinTV 2
devices (both em28xx).
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL for v3.14] mem2mem patches
Em Tue, 24 Dec 2013 10:55:00 +0100 Kamil Debski escreveu: > The following changes since commit 7d459937dc09bb8e448d9985ec4623779427d8a5: > > [media] Add driver for Samsung S5K5BAF camera sensor (2013-12-21 07:01:36 > -0200) > > are available in the git repository at: > > git://linuxtv.org/kdebski/media.git master > > for you to fetch changes up to 0f6616ebb7a04219ad7aa84dd9ff9c7ac9323529: > > s5p-mfc: Add controls to set vp8 enc profile (2013-12-24 10:37:27 +0100) > > > Arun Kumar K (1): > s5p-mfc: Add QP setting support for vp8 encoder > > Kiran AVND (1): > s5p-mfc: Add controls to set vp8 enc profile > > Marek Szyprowski (1): > media: s5p_mfc: remove s5p_mfc_get_node_type() function > > Shaik Ameer Basha (4): > exynos-scaler: Add new driver for Exynos5 SCALER > exynos-scaler: Add core functionality for the SCALER driver > exynos-scaler: Add m2m functionality for the SCALER driver > exynos-scaler: Add DT bindings for SCALER driver This one is missing DT maintainer's ack. > > Documentation/DocBook/media/v4l/controls.xml | 41 + > .../devicetree/bindings/media/exynos5-scaler.txt | 22 + > drivers/media/platform/Kconfig |8 + > drivers/media/platform/Makefile|1 + > drivers/media/platform/exynos-scaler/Makefile |3 + > drivers/media/platform/exynos-scaler/scaler-m2m.c | 787 + > drivers/media/platform/exynos-scaler/scaler-regs.c | 336 ++ > drivers/media/platform/exynos-scaler/scaler-regs.h | 331 ++ > drivers/media/platform/exynos-scaler/scaler.c | 1238 > > drivers/media/platform/exynos-scaler/scaler.h | 375 ++ > drivers/media/platform/s5p-mfc/s5p_mfc.c | 28 +- > drivers/media/platform/s5p-mfc/s5p_mfc_common.h| 14 +- > drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 55 + > drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c| 26 +- > drivers/media/v4l2-core/v4l2-ctrls.c |5 + > include/uapi/linux/v4l2-controls.h |5 + > 16 files changed, 3241 insertions(+), 34 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/media/exynos5-scaler.txt > create mode 100644 drivers/media/platform/exynos-scaler/Makefile > create mode 100644 drivers/media/platform/exynos-scaler/scaler-m2m.c > create mode 100644 drivers/media/platform/exynos-scaler/scaler-regs.c > create mode 100644 drivers/media/platform/exynos-scaler/scaler-regs.h > create mode 100644 drivers/media/platform/exynos-scaler/scaler.c > create mode 100644 drivers/media/platform/exynos-scaler/scaler.h > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] exynos-scaler: Add m2m functionality for the SCALER driver
Em Fri, 18 Oct 2013 11:19:24 +0530
Arun Kumar K escreveu:
> From: Shaik Ameer Basha
>
> This patch adds the Makefile and memory to memory (m2m) interface
> functionality for the SCALER driver.
>
> Signed-off-by: Shaik Ameer Basha
> Signed-off-by: Arun Kumar K
> ---
> This patch is part of the Exynos5 Series SCALER Driver patchset [1]
> with the compilation error corrected for this patch alone.
As you fixed those errors, you should have added the above annotation
at the patch description, before SOB, like:
From: Shaik Ameer Basha
This patch adds the Makefile and memory to memory (m2m) interface
functionality for the SCALER driver.
[arun...@samsung.com: fix compilation issues]
Signed-off-by: Shaik Ameer Basha
Signed-off-by: Arun Kumar K
>
> [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg67256.html
>
> Changes from v4
> ---
> - Addressed compilation error pointed out by Kamil
> ---
> drivers/media/platform/Kconfig|8 +
> drivers/media/platform/Makefile |1 +
> drivers/media/platform/exynos-scaler/Makefile |3 +
> drivers/media/platform/exynos-scaler/scaler-m2m.c | 787
> +
> 4 files changed, 799 insertions(+)
> create mode 100644 drivers/media/platform/exynos-scaler/Makefile
> create mode 100644 drivers/media/platform/exynos-scaler/scaler-m2m.c
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index c7caf94..1ba31ea2 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -201,6 +201,14 @@ config VIDEO_SAMSUNG_EXYNOS_GSC
> help
> This is a v4l2 driver for Samsung EXYNOS5 SoC G-Scaler.
>
> +config VIDEO_SAMSUNG_EXYNOS_SCALER
> + tristate "Samsung Exynos SCALER driver"
> + depends on OF && VIDEO_DEV && VIDEO_V4L2 && ARCH_EXYNOS5
> + select VIDEOBUF2_DMA_CONTIG
> + select V4L2_MEM2MEM_DEV
> + help
> + This is a v4l2 driver for Samsung EXYNOS5410/5420 SoC SCALER.
> +
> config VIDEO_SH_VEU
> tristate "SuperH VEU mem2mem video processing driver"
> depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 4e4da48..14cdad5 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -37,6 +37,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV) += s5p-tv/
>
> obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D) += s5p-g2d/
> obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/
> +obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_SCALER)+= exynos-scaler/
>
> obj-$(CONFIG_BLACKFIN) += blackfin/
>
> diff --git a/drivers/media/platform/exynos-scaler/Makefile
> b/drivers/media/platform/exynos-scaler/Makefile
> new file mode 100644
> index 000..6c8a25b
> --- /dev/null
> +++ b/drivers/media/platform/exynos-scaler/Makefile
> @@ -0,0 +1,3 @@
> +exynos-scaler-objs := scaler.o scaler-m2m.o scaler-regs.o
> +
> +obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_SCALER)+= exynos-scaler.o
> diff --git a/drivers/media/platform/exynos-scaler/scaler-m2m.c
> b/drivers/media/platform/exynos-scaler/scaler-m2m.c
> new file mode 100644
> index 000..987f314
> --- /dev/null
> +++ b/drivers/media/platform/exynos-scaler/scaler-m2m.c
> @@ -0,0 +1,787 @@
> +/*
> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Samsung EXYNOS5 SoC series SCALER driver
> + *
> + * 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
> +#include
> +#include
> +
> +#include
> +
> +#include "scaler-regs.h"
> +
> +#define SCALER_DEF_PIX_FMT V4L2_PIX_FMT_RGB32
> +#define SCALER_DEF_WIDTH 1280
> +#define SCALER_DEF_HEIGHT720
> +
> +static int scaler_m2m_ctx_stop_req(struct scaler_ctx *ctx)
> +{
> + struct scaler_ctx *curr_ctx;
> + struct scaler_dev *scaler = ctx->scaler_dev;
> + int ret;
> +
> + curr_ctx = v4l2_m2m_get_curr_priv(scaler->m2m.m2m_dev);
> + if (!scaler_m2m_pending(scaler) || (curr_ctx != ctx))
> + return 0;
> +
> + scaler_ctx_state_lock_set(SCALER_CTX_STOP_REQ, ctx);
> + ret = wait_event_timeout(scaler->irq_queue,
> + !scaler_ctx_state_is_set(SCALER_CTX_STOP_REQ, ctx),
> + SCALER_SHUTDOWN_TIMEOUT);
> +
> + return ret == 0 ? -ETIMEDOUT : ret;
> +}
> +
> +static int scaler_m2m_start_streaming(struct vb2_queue *q, unsigned int
> count)
> +{
> + struct scaler_ctx *ctx = q->drv_priv;
> + int ret;
> +
> + ret = pm_runtime_get_sync(&ctx->scaler_dev->pdev->dev);
> +
> + return ret > 0 ? 0 : ret;
> +}
> +
> +static int scaler_m2m_stop_streaming(struct vb2_queue *q)
> +{
> + struct scaler_ctx *ctx = q->drv_priv;
> + int ret;
> +
> + ret = scaler_m2m_ctx_stop_req(ctx);
> + if (ret < 0)
>
Re: [PATCH v4 2/4] [media] exynos-scaler: Add core functionality for the SCALER driver
Em Fri, 4 Oct 2013 17:56:32 +0530
Shaik Ameer Basha escreveu:
> This patch adds the core functionality for the SCALER driver.
>
> Signed-off-by: Shaik Ameer Basha
> ---
> drivers/media/platform/exynos-scaler/scaler.c | 1238
> +
> drivers/media/platform/exynos-scaler/scaler.h | 375
> 2 files changed, 1613 insertions(+)
> create mode 100644 drivers/media/platform/exynos-scaler/scaler.c
> create mode 100644 drivers/media/platform/exynos-scaler/scaler.h
>
> diff --git a/drivers/media/platform/exynos-scaler/scaler.c
> b/drivers/media/platform/exynos-scaler/scaler.c
> new file mode 100644
> index 000..57635f2
> --- /dev/null
> +++ b/drivers/media/platform/exynos-scaler/scaler.c
> @@ -0,0 +1,1238 @@
> +/*
> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Samsung EXYNOS5 SoC series SCALER driver
> + *
> + * 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
> +#include
> +#include
> +#include
> +#include
> +
> +#include "scaler-regs.h"
> +
> +#define SCALER_CLOCK_GATE_NAME "scaler"
> +
> +static const struct scaler_fmt scaler_formats[] = {
> + {
> + .name = "YUV 4:2:0 non-contig. 2p, Y/CbCr",
> + .pixelformat= V4L2_PIX_FMT_NV12M,
> + .depth = { 8, 4 },
> + .color = SCALER_YUV420,
> + .color_order= SCALER_CBCR,
> + .num_planes = 2,
> + .num_comp = 2,
> + .scaler_color = SCALER_YUV420_2P_Y_UV,
> + .flags = (SCALER_FMT_SRC | SCALER_FMT_DST),
Not a big deal, but you don't need parenthesis for any of those .flags
initialization.
> +
> + }, {
> + .name = "YUV 4:2:0 contig. 2p, Y/CbCr",
> + .pixelformat= V4L2_PIX_FMT_NV12,
> + .depth = { 12 },
> + .color = SCALER_YUV420,
> + .color_order= SCALER_CBCR,
> + .num_planes = 1,
> + .num_comp = 2,
> + .scaler_color = SCALER_YUV420_2P_Y_UV,
> + .flags = (SCALER_FMT_SRC | SCALER_FMT_DST),
> + }, {
> + .name = "YUV 4:2:0 n.c. 2p, Y/CbCr tiled",
> + .pixelformat= V4L2_PIX_FMT_NV12MT_16X16,
> + .depth = { 8, 4 },
> + .color = SCALER_YUV420,
> + .color_order= SCALER_CBCR,
> + .num_planes = 2,
> + .num_comp = 2,
> + .scaler_color = SCALER_YUV420_2P_Y_UV,
> + .flags = (SCALER_FMT_SRC | SCALER_FMT_TILED),
> + }, {
> + .name = "YUV 4:2:2 contig. 2p, Y/CbCr",
> + .pixelformat= V4L2_PIX_FMT_NV16,
> + .depth = { 16 },
> + .color = SCALER_YUV422,
> + .color_order= SCALER_CBCR,
> + .num_planes = 1,
> + .num_comp = 2,
> + .scaler_color = SCALER_YUV422_2P_Y_UV,
> + .flags = (SCALER_FMT_SRC | SCALER_FMT_DST),
> + }, {
> + .name = "YUV 4:4:4 contig. 2p, Y/CbCr",
> + .pixelformat= V4L2_PIX_FMT_NV24,
> + .depth = { 24 },
> + .color = SCALER_YUV444,
> + .color_order= SCALER_CBCR,
> + .num_planes = 1,
> + .num_comp = 2,
> + .scaler_color = SCALER_YUV444_2P_Y_UV,
> + .flags = (SCALER_FMT_SRC | SCALER_FMT_DST),
> + }, {
> + .name = "RGB565",
> + .pixelformat= V4L2_PIX_FMT_RGB565X,
> + .depth = { 16 },
> + .color = SCALER_RGB,
> + .num_planes = 1,
> + .num_comp = 1,
> + .scaler_color = SCALER_RGB565,
> + .flags = (SCALER_FMT_SRC | SCALER_FMT_DST),
> + }, {
> + .name = "XRGB-1555, 16 bpp",
> + .pixelformat= V4L2_PIX_FMT_RGB555,
> + .depth = { 16 },
> + .color = SCALER_RGB,
> + .num_planes = 1,
> + .num_comp = 1,
> + .scaler_color = SCALER_ARGB1555,
> + .flags = (SCALER_FMT_SRC | SCALER_FMT_DST),
> + }, {
> + .name = "XRGB-, 32 bpp",
> + .pixelformat= V4L2_PIX_FMT_RGB32,
> + .depth = { 32 },
> + .color = SCALER_RGB,
> + .num_planes = 1,
> + .num_comp = 1,
> + .scaler_color = SCALER_ARGB,
> + .flags = (SCALER_FMT_SRC | SCALER_FMT_DST),
> +
Re: [PATCH v4 1/4] [media] exynos-scaler: Add new driver for Exynos5 SCALER
Em Fri, 4 Oct 2013 17:56:31 +0530
Shaik Ameer Basha escreveu:
> This patch adds support for SCALER device which is a new device
> for scaling, blending, color fill and color space conversion
> on EXYNOS5410 and EXYNOS5420 SoCs.
>
> This device supports the followings as key feature.
> input image format
> - YCbCr420 2P(UV/VU), 3P
> - YCbCr422 1P(YUYV/UYVY/YVYU), 2P(UV,VU), 3P
> - YCbCr444 2P(UV,VU), 3P
> - RGB565, ARGB1555, ARGB, ARGB, RGBA
> - Pre-multiplexed ARGB, L8A8 and L8
> output image format
> - YCbCr420 2P(UV/VU), 3P
> - YCbCr422 1P(YUYV/UYVY/YVYU), 2P(UV,VU), 3P
> - YCbCr444 2P(UV,VU), 3P
> - RGB565, ARGB1555, ARGB, ARGB, RGBA
> - Pre-multiplexed ARGB
> input rotation
> - 0/90/180/270 degree, X/Y/XY Flip
> scale ratio
> - 1/4 scale down to 16 scale up
> color space conversion
> - RGB to YUV / YUV to RGB
> Size - Exynos5420
> - Input : 16x16 to 8192x8192
> - Output: 4x4 to 8192x8192
> Size - Exynos5410
> - Input/Output: 4x4 to 4096x4096
> alpha blending, color fill
>
> Signed-off-by: Shaik Ameer Basha
> ---
> drivers/media/platform/exynos-scaler/scaler-regs.c | 336
>
> drivers/media/platform/exynos-scaler/scaler-regs.h | 331 +++
> 2 files changed, 667 insertions(+)
> create mode 100644 drivers/media/platform/exynos-scaler/scaler-regs.c
> create mode 100644 drivers/media/platform/exynos-scaler/scaler-regs.h
>
> diff --git a/drivers/media/platform/exynos-scaler/scaler-regs.c
> b/drivers/media/platform/exynos-scaler/scaler-regs.c
> new file mode 100644
> index 000..ae4a548
> --- /dev/null
> +++ b/drivers/media/platform/exynos-scaler/scaler-regs.c
> @@ -0,0 +1,336 @@
> +/*
> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Samsung EXYNOS5 SoC series SCALER driver
> + *
> + * 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
> +#include
> +
> +#include "scaler-regs.h"
> +
> +/* Scaler reset timeout in milliseconds */
> +#define SCALER_RESET_TIMEOUT 50
> +
> +void scaler_hw_set_sw_reset(struct scaler_dev *dev)
> +{
> + u32 cfg;
> +
> + cfg = scaler_read(dev, SCALER_CFG);
> + cfg |= SCALER_CFG_SOFT_RESET;
> +
> + scaler_write(dev, SCALER_CFG, cfg);
> +}
> +
> +int scaler_wait_reset(struct scaler_dev *dev)
> +{
> + unsigned long end = jiffies + msecs_to_jiffies(SCALER_RESET_TIMEOUT);
> + u32 cfg, reset_done = 0;
> +
> + while (time_before(jiffies, end)) {
> + cfg = scaler_read(dev, SCALER_CFG);
> + if (!(cfg & SCALER_CFG_SOFT_RESET)) {
> + reset_done = 1;
> + break;
> + }
> + usleep_range(10, 20);
Hmm... that doesn't seem right... the timeout can take up to 50,000 us, and
you're sleeping from 10 to 20us... that means that this loop can have up to
5000 interactions... It seems that you're wasting power here without need.
I suspect that you should consider sleeping for a longer time here.
Btw, instead of using time_before(jiffies, end), you could do:
time_is_after_jiffies(end)
As, from jiffies.h:
/* time_is_after_jiffies(a) return true if a is after jiffies */
#define time_is_after_jiffies(a) time_before(jiffies, a)
> + }
> +
> + /*
> + * Write any value to read/write register and read it back.
> + * If the written and read value matches, then the reset process is
> + * succeeded.
> + */
> + while (reset_done) {
This is tricky. If the reset fail, it will return busy. Otherwise, it
can loop forever here. Worse than that, you're don't even sleeping
before retries, again wasting power.
Why don't you just change it to something similar to:
if (!reset_done)
return -EBUSY;
end = jiffies + msecs_to_jiffies(SCALER_RESET_TIMEOUT);
while (time_is_after_jiffies(end)) {
scaler_write(dev, SCALER_CFG_SOFT_RESET_CHECK_REG,
SCALER_CFG_SOFT_RESET_CHECK_VAL);
if (SCALER_CFG_SOFT_RESET_CHECK_VAL ==
scaler_read(dev, SCALER_CFG_SOFT_RESET_CHECK_REG))
return 0;
msleep(10);
}
> +
> + /*
> + * TODO: need to define number of tries before returning
> + * -EBUSY to the caller
> + */
> +
> + scaler_write(dev, SCALER_CFG_SOFT_RESET_CHECK_REG,
> + SCALER_CFG_SOFT_RESET_CHECK_VAL);
> + if (SCALER_CFG_SOFT_RESET_CHECK_VAL ==
> + scaler_read(dev, SCALER_CFG_SOFT_RESET_CHECK_REG))
> + r
Re: [PATCH v3 4/6] exynos4-is: Add clock provider for the external clocks
Em Thu, 17 Oct 2013 20:06:49 +0200
Sylwester Nawrocki escreveu:
> This patch adds clock provider to expose the sclk_cam0/1 clocks
> for external image sensor devices.
>
> Signed-off-by: Sylwester Nawrocki
> Signed-off-by: Kyungmin Park
> ---
> Changes since v2:
> - use 'camera' DT node drirectly as clock provider node, rather than
> creating additional clock-controller child node.
> ---
> .../devicetree/bindings/media/samsung-fimc.txt | 15 ++-
> drivers/media/platform/exynos4-is/media-dev.c | 108
>
> drivers/media/platform/exynos4-is/media-dev.h | 18 +++-
> 3 files changed, 137 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt
> b/Documentation/devicetree/bindings/media/samsung-fimc.txt
> index 96312f6..968e065 100644
> --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
> +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
> @@ -32,6 +32,15 @@ way around.
>
> The 'camera' node must include at least one 'fimc' child node.
>
> +Optional properties:
> +
> +- #clock-cells: from the common clock bindings (../clock/clock-bindings.txt),
> + must be 1. A clock provider is associated with the camera node and it
> should
> + be referenced by external sensors that use clocks provided by the SoC on
> + CAM_*_CLKOUT pins. The second cell of the clock specifier is a clock's
> index.
> + The indexes are 0, 1 for CAM_A_CLKOUT, CAM_B_CLKOUT clocks respectively.
> +
> +
> 'fimc' device nodes
> ---
>
> @@ -114,7 +123,7 @@ Example:
> vddio-supply = <...>;
>
> clock-frequency = <2400>;
> - clocks = <...>;
> + clocks = <&camera 1>;
> clock-names = "mclk";
>
> port {
> @@ -135,7 +144,7 @@ Example:
> vddio-supply = <...>;
>
> clock-frequency = <2400>;
> - clocks = <...>;
> + clocks = <&camera 0>;
> clock-names = "mclk";
>
> port {
> @@ -151,8 +160,8 @@ Example:
> compatible = "samsung,fimc", "simple-bus";
> #address-cells = <1>;
> #size-cells = <1>;
> + #clock-cells = <1>;
> status = "okay";
> -
> pinctrl-names = "default";
> pinctrl-0 = <&cam_port_a_clk_active>;
I didn't see the above on the patch series you sent me on your git pull
request. Where is it?
>
> diff --git a/drivers/media/platform/exynos4-is/media-dev.c
> b/drivers/media/platform/exynos4-is/media-dev.c
> index a835112..d78e3da 100644
> --- a/drivers/media/platform/exynos4-is/media-dev.c
> +++ b/drivers/media/platform/exynos4-is/media-dev.c
> @@ -11,6 +11,8 @@
> */
>
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -1437,6 +1439,101 @@ static int fimc_md_get_pinctrl(struct fimc_md *fmd)
> return 0;
> }
>
> +#ifdef CONFIG_OF
> +static int cam_clk_prepare(struct clk_hw *hw)
> +{
> + struct cam_clk *camclk = to_cam_clk(hw);
> + int ret;
> +
> + if (camclk->fmd->pmf == NULL)
> + return -ENODEV;
> +
> + ret = pm_runtime_get_sync(camclk->fmd->pmf);
> + return ret < 0 ? ret : 0;
> +}
> +
> +static void cam_clk_unprepare(struct clk_hw *hw)
> +{
> + struct cam_clk *camclk = to_cam_clk(hw);
> +
> + if (camclk->fmd->pmf == NULL)
> + return;
> +
> + pm_runtime_put_sync(camclk->fmd->pmf);
> +}
> +
> +static const struct clk_ops cam_clk_ops = {
> + .prepare = cam_clk_prepare,
> + .unprepare = cam_clk_unprepare,
> +};
> +
> +static const char *cam_clk_p_names[] = { "sclk_cam0", "sclk_cam1" };
> +
> +static void fimc_md_unregister_clk_provider(struct fimc_md *fmd)
> +{
> + struct cam_clk_provider *cp = &fmd->clk_provider;
> + unsigned int i;
> +
> + if (cp->of_node)
> + of_clk_del_provider(cp->of_node);
> +
> + for (i = 0; i < ARRAY_SIZE(cp->clks); i++)
> + if (!IS_ERR(cp->clks[i]))
> + clk_unregister(cp->clks[i]);
Huh? Why to initialize an array with an error code??? Does it make sense to
have one of the clocks with an error and the others ok, and to store the
error code? The code below doesn't seem to allow that.
Just initialize cp->clks with zero and test it with:
if (cp->clks[i])
clk_unregister(cp->clks[i]);
That makes it easier to understand and review.
> +}
> +
> +static int fimc_md_register_clk_provider(struct fimc_md *fmd)
> +{
> + struct cam_clk_provider *cp = &fmd->clk_provider;
> + struct device *dev = &fmd->pdev->dev;
> + int i, ret;
> +
> + for (i = 0; i < ARRAY_SIZE(cp->clks); i++)
> + cp->clks[i] = ERR_PTR(-EINVAL);
That looks weird for me, due to several reasons:
1) ARRAY_SIZE(cp->clks) is equal to FIMC_MAX_CAMCLKS.
[PATCH] v4l: cx231xx: added usb id of 'Dexatek Video Grabber'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
this patch adds support for the Dexatek Video Grabber with USB id 1d19:610a
The device is sold in germany as 'USB-Video-Digitalisierer Medion E89137
(MD 86937)', provides analog audio/video capture and is based on the
CX23103-11Z.
The driver loads the firmware v4l-cx231xx-avcore-01.fw, despite
v4l-cx23885-avcore-01.fw (merlinD.rom) beeing shipped with the windows
driver. But audio and video capturing works here.
Trivial patch:
- --- a/drivers/media/usb/cx231xx/cx231xx-cards.c 2014-01-01
11:49:19.0 +0100
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c 2014-01-01
11:58:50.949353779 +0100
@@ -684,6 +684,8 @@
.driver_info = CX231XX_BOARD_CNXT_RDU_253S},
{USB_DEVICE(0x0572, 0x58A6),
.driver_info = CX231XX_BOARD_CNXT_VIDEO_GRABBER},
+ {USB_DEVICE(0x1D19, 0x610A),
+.driver_info = CX231XX_BOARD_CNXT_VIDEO_GRABBER},
{USB_DEVICE(0x0572, 0x589E),
.driver_info = CX231XX_BOARD_CNXT_RDE_250},
{USB_DEVICE(0x0572, 0x58A0),
- --
Regards,
C
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSxbxaAAoJECsSvCKD1CYcAacH/07/ps/pwDrVSvGXd5bZ+RBg
p/+9ktxgcW6L2pSLpH6qsF0psX9LRt4zWKuuvomQsC5wf0OS6yP2lxqYGNkX5O1d
ZbLNyAF6CAv3zH/jfAlq0rgi0Sk9ZqEcHjgP/si85lsjKAagZpmtHDMK7kYl6lNC
9IyoZHISbTzSZlbVBerZ/89Pta8AY9CrQ01FWlvpIctmjBE3AB+LCetj9mNB8uEV
164Irv66BMWBKRHGSz9zUXbAHUpJJLSRjN5KOV6Nk5hrodqqRkIe80YnBlkL9PLl
1zchPkd+05QBxVfK3+9Xwv31S4hegVleEv4S96XsnxirzPY9kCLcYF3lYOcGKFw=
=CQvY
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 11/24] tvp5150: make read operations atomic
Em Wed, 01 Jan 2014 19:52:08 +0100
Frank Schäfer escreveu:
> Am 28.12.2013 13:16, schrieb Mauro Carvalho Chehab:
> > From: Mauro Carvalho Chehab
> >
> > Instead of using two I2C operations between write and read,
> > use just one i2c_transfer. That allows I2C mutexes to not
> > let any other I2C transfer between the two.
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> > drivers/media/i2c/tvp5150.c | 22 ++
> > 1 file changed, 10 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
> > index 89c0b13463b7..d6ba457fcf67 100644
> > --- a/drivers/media/i2c/tvp5150.c
> > +++ b/drivers/media/i2c/tvp5150.c
> > @@ -58,21 +58,19 @@ static int tvp5150_read(struct v4l2_subdev *sd,
> > unsigned char addr)
> > struct i2c_client *c = v4l2_get_subdevdata(sd);
> > unsigned char buffer[1];
> > int rc;
> > + struct i2c_msg msg[] = {
> > + { .addr = c->addr, .flags = 0,
> > + .buf = &addr, .len = 1 },
> I would use.buf = bufferhere, too.
Why? The address needed is already at addr, and it is also an unsigned char.
Using buffer would require an extra data copy.
>
> > + { .addr = c->addr, .flags = I2C_M_RD,
> > + .buf = buffer, .len = 1 }
> > + };
> >
> > buffer[0] = addr;
> >
> > - rc = i2c_master_send(c, buffer, 1);
> > - if (rc < 0) {
> > - v4l2_err(sd, "i2c i/o error: rc == %d (should be 1)\n", rc);
> > - return rc;
> > - }
> > -
> > - msleep(10);
> That's the critical change.
I don't think so. I'm not sure why I added this at the first place on the
original patch with where I added this driver, but it is very doubtful
that a msleep() is needed here.
This code is really old (from the time I added support for WinTV USB 2).
I suspect I added the sleep there just because the I2C logs, during the
driver development phase, to be an exact mimic on what it was got via
USB dumps.
>
> > -
> > - rc = i2c_master_recv(c, buffer, 1);
> > - if (rc < 0) {
> > - v4l2_err(sd, "i2c i/o error: rc == %d (should be 1)\n", rc);
> > - return rc;
> > + rc = i2c_transfer(c->adapter, msg, 2);
> > + if (rc < 0 || rc != 2) {
> > + v4l2_err(sd, "i2c i/o error: rc == %d (should be 2)\n", rc);
> > + return rc < 0 ? rc : -EIO;
> > }
> >
> > v4l2_dbg(2, debug, sd, "tvp5150: read 0x%02x = 0x%02x\n", addr,
> > buffer[0]);
> Looks good and works without problems with my HVR-900 and WinTV 2
> devices (both em28xx).
>
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: using MFC memory to memery encoder, start stream and queue order problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 于 2014年01月02日 20:59, Kamil Debski 写道: > Hi, > >> From: lxr1234 [mailto:lxr1...@hotmail.com] Sent: Thursday, >> January 02, 2014 1:57 PM To: Kamil Debski Subject: RE: using MFC >> memory to memery encoder, start stream and queue order problem >> >> >> >> Kamil Debski 写到： >>> Hi Randy, >>> From: randy [mailto:lxr1...@hotmail.com] Sent: Thursday, January 02, 2014 12:35 PM Hello I have follow the README of the v4l2-mfc-encoder from the http://git.infradead.org/users/kmpark/public-apps it seems that I can use the mfc encoder in exynos4412(using 3.5 >>> kernel from manufacturer). >>> >>> So it is not the mainline kernel. Could you give a link to >>> this >> kernel? >>> I have doubts that this kernel is using the open source driver. >>> The driver present in that kernel could be a significantly >>> modified >> driver. >>> The kernel souce code can be found here https://github.com/hizukiayaka/linux-tiny4412-origin I am pushing. >> Sorry, It doesn't in a git repo I will update,it later, the >> kernel is from friendlyarm, I see driver source in kernel. But I have a problem with the contain of the README and I can't get >>> the key frame(the I-frame in H.264). It said that "6. Enqueue CAPTURE buffers. 7. Enqueue OUTPUT buffer with first frame. 8. Start streaming (VIDIOC_STREAMON) on both ends." so I shall enqueue buffer before start stream, to enqueue a buffer, >> I need to dequeue first, but without start stream, it will failed in >>> both side. >>> >>> I think I don't understand this. You should enqueue the buffers >>> and then start streaming. I think dequeueing is not mentioned >>> here. First enqueue then dequeue. >> Without dequeue, hwo to get a buffer to fill data(first raw >> video)? And what shall enqueue in CAPTURE. Is there a guide fo >> usibg memory to memory driver? > > After doing a VIDIOC_REQBUFS you should do a VIDIOC_QUERYBUF call > to get the buffers. After that you can enqueue them. > > I suggest that you first run decoding. v4l2-mfc-example from > public-apps. This way you could see how the V4L2 framework works. > I see thank you the v4l2-mfc-encoder is so difficult that I failed to understand. My code is modified from gst's mfc decoder, I ignored that ioctl in source ;) In this way I start OUTPUT(input raw video) stream first then >> dequeue and enqueue the first frame, then I start the CAPTURE(output encoded video) frame, dequeue CAPTURE to get a buffer, get the data from >>> buffer then enqueue the buffer. The first frame of CAPTURE is always a 22 bytes frame(I don't know whether they are the same data all the time, but size is the same from m.planes[0].bytesused), but it seems not a key frame. What is the problem, and how to solve it. P.S I don't test the Linux 3.13-rc4, as the driver is not ready for encoder before. Thank you >>> >>> Best wishes, >> Thank you -- lxr1234 > > Best wishes, Kamil > > I forget to mail to the list, I just repeated to you directly as I shall CC you. Thank you very much ayaka -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJSxXGxAAoJEPb4VsMIzTziHVQH+wXTpbhxjGme1sn8f1gbPNzZ a3FDBjiVC/WiK0TW0kp1IIlV5X93vMhE/VagXIxgxv7FuNcTRYe3EKxXg96Thk4T 1svg7Cnny0FbZoCbm+2pzg5itvqowZfnQhBI71vnVWVlxHm2ub2tVha/JCtCLoW2 sXDoqg72tcdmxoAl8HqPmokGMkn5aLdVfPnOpLHfPJvNoIWCyOvpc5REutlF4uzT NjgAZMqBwjARjd0nJiLaxsuQQ3EK8d8MCZkkZTCTQLiH+SKfu/Js3nTK1CCkWhSv z82WDw5qmE3573+2+xxgACal0jPJaDynXBMd/wvBWzpLvSF/Jcg49RDS8exVQfs= =q5zX -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.14] Fixes (third attempt)
Hi Mauro,
For some reason my previous pull request (see
https://www.mail-archive.com/linux-media@vger.kernel.org/msg69484.html) did not
appear in patchwork. So I'm trying again (after rebasing).
Regards,
Hans
The following changes since commit 7d459937dc09bb8e448d9985ec4623779427d8a5:
[media] Add driver for Samsung S5K5BAF camera sensor (2013-12-21 07:01:36
-0200)
are available in the git repository at:
git://linuxtv.org/hverkuil/media_tree.git for-v3.14b
for you to fetch changes up to 9a8326ea5ecf6638635d35eb16fcbae333c96386:
davinci-vpfe: fix compile error (2014-01-02 13:56:36 +0100)
Antonio Ospite (2):
Documentation/DocBook/media/v4l/subdev-formats.xml: fix a typo
Documentation/DocBook/media/v4l: fix typo, s/packet/packed/
Archit Taneja (8):
v4l: ti-vpe: create a scaler block library
v4l: ti-vpe: support loading of scaler coefficients
v4l: ti-vpe: make vpe driver load scaler coefficients
v4l: ti-vpe: enable basic scaler support
v4l: ti-vpe: create a color space converter block library
v4l: ti-vpe: Add helper to perform color conversion
v4l: ti-vpe: enable CSC support for VPE
v4l: ti-vpe: Add a type specifier to describe vpdma data format type
Fengguang Wu (2):
fix coccinelle warnings
fix coccinelle warnings
Hans Verkuil (26):
v4l2: move tracepoints to video_usercopy
vb2: push the mmap semaphore down to __buf_prepare()
vb2: simplify qbuf/prepare_buf by removing callback.
vb2: fix race condition between REQBUFS and QBUF/PREPARE_BUF.
vb2: remove the 'fileio = NULL' hack.
vb2: retry start_streaming in case of insufficient buffers.
vb2: don't set index, don't start streaming for write()
vb2: return ENOBUFS in start_streaming in case of too few buffers.
vb2: Improve file I/O emulation to handle buffers in any order
DocBook: drop the word 'only'.
saa7134: move the queue data from saa7134_fh to saa7134_dev.
saa7134: convert to the control framework.
saa7134: cleanup radio/video/empress ioctl handling
saa7134: remove dev from saa7134_fh, use saa7134_fh for empress node
saa7134: share resource management between normal and empress nodes.
saa7134: add support for control events.
saa7134: use V4L2_IN_ST_NO_SIGNAL instead of NO_SYNC
saa6752hs: drop compat control code.
saa6752hs: move to media/i2c
saa6752hs.h: drop empty header.
saa7134: drop log_status for radio.
saa6588: after calling CMD_CLOSE, CMD_POLL is broken.
saa6588: remove unused CMD_OPEN.
saa6588: add support for non-blocking mode.
saa7134: don't set vfd->debug.
davinci-vpfe: fix compile error
Joe Perches (1):
media: Remove OOM message after input_allocate_device
Matthias Schwarzott (2):
cx231xx: Add missing selects for MEDIA_SUBDRV_AUTOSELECT
cx231xx: fix i2c debug prints
Ricardo Ribalda (1):
videodev2: Set vb2_rect's width and height as unsigned
Wei Yongjun (1):
radio-bcm2048: fix missing unlock on error in bcm2048_rds_fifo_receive()
Documentation/DocBook/media/v4l/compat.xml | 12 +
Documentation/DocBook/media/v4l/dev-overlay.xml |9 +-
Documentation/DocBook/media/v4l/subdev-formats.xml |6 +-
Documentation/DocBook/media/v4l/v4l2.xml| 10 +-
Documentation/DocBook/media/v4l/vidioc-cropcap.xml | 10 +-
Documentation/DocBook/media/v4l/vidioc-streamon.xml |2 +-
drivers/media/i2c/Kconfig | 12 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/mt9m032.c | 16 +-
drivers/media/i2c/mt9p031.c | 28 +-
drivers/media/i2c/mt9t001.c | 26 +-
drivers/media/i2c/mt9v032.c | 38 +-
drivers/media/i2c/saa6588.c | 50 +--
drivers/media/{pci/saa7134 => i2c}/saa6752hs.c | 19 +-
drivers/media/i2c/smiapp/smiapp-core.c |8 +-
drivers/media/i2c/soc_camera/mt9m111.c |4 +-
drivers/media/i2c/tvp5150.c | 14 +-
drivers/media/pci/bt8xx/bttv-driver.c | 10 +-
drivers/media/pci/saa7134/Kconfig |1 +
drivers/media/pci/saa7134/Makefile |2 +-
drivers/media/pci/saa7134/saa7134-core.c| 11 +-
drivers/media/pci/saa7134/saa7134-empress.c | 359 +--
drivers/media/pci/saa7134/saa7134-vbi.c | 11 +-
drivers/media/pci/saa7134/saa7134-video.c | 781
+++--
drivers/media/pci/saa7134/saa7134.h | 66 +++-
drivers/media/platform/davinci/vpbe_display.c |2 +-
drivers/media/platform/davinci/vpif_capture.c |2 +-
drivers/media/platform/davinci/vpif_display.c
[patch] [media] staging: sn9c102: add a USB depend to the Kconfig
This driver won't link without USB support. Reported-by: Jim Davis Signed-off-by: Dan Carpenter diff --git a/drivers/staging/media/sn9c102/Kconfig b/drivers/staging/media/sn9c102/Kconfig index d8ae2354b626..3ab9c81173da 100644 --- a/drivers/staging/media/sn9c102/Kconfig +++ b/drivers/staging/media/sn9c102/Kconfig @@ -1,6 +1,6 @@ config USB_SN9C102 tristate "USB SN9C1xx PC Camera Controller support (DEPRECATED)" - depends on VIDEO_V4L2 + depends on USB && VIDEO_V4L2 ---help--- This driver is DEPRECATED, please use the gspca sonixb and sonixj modules instead. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.14] adv fixes and feature enhancements
Mauro, Please pull this patch series for 3.14. It's rebased but otherwise unchanged from the last review patch series: http://www.spinics.net/lists/linux-media/msg70819.html Happy New Year! Regards, Hans The following changes since commit 7d459937dc09bb8e448d9985ec4623779427d8a5: [media] Add driver for Samsung S5K5BAF camera sensor (2013-12-21 07:01:36 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git adv for you to fetch changes up to 4644c02f7befe821bdd0d20b33d6a0de7b59cfae: adv7842: add drive strength enum and sync names with adv7604. (2014-01-02 13:44:30 +0100) Hans Verkuil (6): adv7604: adv7604_s_register clean up. adv7604: initialize timings to CEA 640x480p59.94. adv7842: support YCrCb analog input, receive CEA formats as RGB on VGA input adv7842: set LLC DLL phase from platform_data adv7842: initialize timings to CEA 640x480p59.94. adv7842: add drive strength enum and sync names with adv7604. Martin Bugge (27): ad9389b: whitespace changes to improve readability ad9389b: remove rx-sense irq dependency ad9389b: retry setup if the state is inconsistent adv7511: disable register reset by HPD adv7511: add VIC and audio CTS/N values to log_status adv7511: verify EDID header adv7604: support 1366x768 DMT Reduced Blanking adv7604: set restart_stdi_once flag when signal is lost. adv7604: sync polarities from platform data adv7842: Re-worked query_dv_timings() adv7842: corrected setting of cp-register 0x91 and 0x8f. adv7842: properly enable/disable the irqs. adv7842: save platform data in state struct adv7842: added DE vertical position in SDP-io-sync adv7842: set defaults spa-location. adv7842: 625/525 line standard jitter fix. adv7842: set default input in platform-data adv7842: increase wait time. adv7842: clear edid, if no edid just disable Edid-DDC access adv7842: restart STDI once if format is not found. adv7842: support g_edid ioctl adv7842: i2c dummy clients registration. adv7842: enable HDMI/DVI mode irq adv7842: composite sd-ram test, clear timings before setting. adv7842: obtain free-run mode from the platform_data. adv7842: Composite sync adjustment adv7842: return 0 if no change in s_dv_timings Mats Randgaard (16): ad9389b: verify EDID header adv7604: add support for all the digital input ports adv7604: Receive CEA formats as RGB on VGA (RGB) input adv7604: select YPbPr if RGB_RANGE_FULL/LIMITED is set for VGA_COMP inputs adv7604: set CEC address (SPA) in EDID adv7604: improve EDID handling adv7604: remove connector type. Never used for anything useful. adv7604: return immediately if the new input is equal to what is configured adv7604: remove debouncing of ADV7604_FMT_CHANGE events adv7604: improve HDMI audio handling adv7604: adjust gain and offset for DVI-D signals adv7604: Enable HDMI_MODE interrupt adv7604: return immediately if the new timings are equal to what is configured adv7842: remove connector type. Never used for anything useful adv7842: Use defines to select EDID port adv7842: mute audio before switching inputs to avoid noise/pops Mikhail Khelik (1): adv7604: add hdmi driver strength adjustment arch/blackfin/mach-bf609/boards/ezkit.c | 4 +- drivers/media/i2c/ad9389b.c | 277 +++- drivers/media/i2c/adv7511.c | 64 +++-- drivers/media/i2c/adv7604.c | 645 +-- drivers/media/i2c/adv7842.c | 646 +--- include/media/adv7604.h | 38 +++-- include/media/adv7842.h | 59 ++-- 7 files changed, 1135 insertions(+), 598 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: using MFC memory to memery encoder, start stream and queue order problem
Hi Randy, > From: randy [mailto:lxr1...@hotmail.com] > Sent: Thursday, January 02, 2014 12:35 PM > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello > > I have follow the README of the v4l2-mfc-encoder from the > http://git.infradead.org/users/kmpark/public-apps > it seems that I can use the mfc encoder in exynos4412(using 3.5 kernel > from manufacturer). So it is not the mainline kernel. Could you give a link to this kernel? I have doubts that this kernel is using the open source driver. The driver present in that kernel could be a significantly modified driver. > But I have a problem with the contain of the README and I can't get the > key frame(the I-frame in H.264). It said that "6. Enqueue CAPTURE > buffers. > 7. Enqueue OUTPUT buffer with first frame. > 8. Start streaming (VIDIOC_STREAMON) on both ends." > so I shall enqueue buffer before start stream, to enqueue a buffer, I > need to dequeue first, but without start stream, it will failed in both > side. I think I don't understand this. You should enqueue the buffers and then start streaming. I think dequeueing is not mentioned here. First enqueue then dequeue. > In this way I start OUTPUT(input raw video) stream first then dequeue > and enqueue the first frame, then I start the CAPTURE(output encoded > video) frame, dequeue CAPTURE to get a buffer, get the data from buffer > then enqueue the buffer. The first frame of CAPTURE is always a > 22 bytes > frame(I don't know whether they are the same data all the time, but > size is the same from m.planes[0].bytesused), but it seems not a key > frame. > > What is the problem, and how to solve it. > > P.S I don't test the Linux 3.13-rc4, as the driver is not ready for > encoder before. > > Thank you > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJSxU74AAoJEPb4VsMIzTzi2oEH/1JJqfeZhMwogvWSVz+M3J4Y > 2Bnej0RBBKF0Gu508IWrHy9t+DPg3c3wJt1M0j+GtUsv2Q+Jl2vlmDTLV/Gafzo6 > xywye4raHpqHreFv4Q55SIseDbfV79eO84uv4RuV/fXEuPpo1MlZf9SOGCiAfoQI > ozxqoOPD2l2VaSA/351gtT93lkOREF2EnmVf2Wa31WWHw0LV3aoY9/OosxOiY9Fy > mVHHpYheDwHXdPfrxHXWKEA5GOJ7h0ozc66MPe7JInKSGdUcDrdrFxdSVwyZ/21B > Oc2Aw9RMd85NwjXBc9hYH++3f73tcVhzMCF7Swyb+bsn4Mzyr64Bn4VsYaDqiCc= > =HCKX > -END PGP SIGNATURE- Best wishes, -- Kamil Debski Samsung R&D Institute Poland -- 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, RFC 06/30] [media] usbvision: remove bogus sleep_on_timeout
There is no reason to use sleep_on_timeout here, and we want to get
rid of that interface. Use the simpler msleep_interruptible instead.
Signed-off-by: Arnd Bergmann
Cc: Hans Verkuil
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
---
drivers/media/usb/usbvision/usbvision.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/media/usb/usbvision/usbvision.h
b/drivers/media/usb/usbvision/usbvision.h
index 8a25876..eb6dc8a 100644
--- a/drivers/media/usb/usbvision/usbvision.h
+++ b/drivers/media/usb/usbvision/usbvision.h
@@ -205,10 +205,8 @@ enum {
/* Debugging aid */
#define USBVISION_SAY_AND_WAIT(what) { \
- wait_queue_head_t wq; \
- init_waitqueue_head(&wq); \
printk(KERN_INFO "Say: %s\n", what); \
- interruptible_sleep_on_timeout(&wq, HZ * 3); \
+ msleep_interruptible(3000); \
}
/*
--
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, RFC 07/30] [media] radio-cadet: avoid interruptible_sleep_on race
interruptible_sleep_on is racy and going away. This replaces
one use in the radio-cadet driver with an open-coded
wait loop that lets us check the condition under the mutex
but sleep without it.
Signed-off-by: Arnd Bergmann
Cc: Hans Verkuil
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
---
drivers/media/radio/radio-cadet.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/media/radio/radio-cadet.c
b/drivers/media/radio/radio-cadet.c
index 545c04c..67b5bbf 100644
--- a/drivers/media/radio/radio-cadet.c
+++ b/drivers/media/radio/radio-cadet.c
@@ -39,6 +39,7 @@
#include
#include
#include /* outb, outb_p */
+#include
#include
#include
#include
@@ -323,25 +324,32 @@ static ssize_t cadet_read(struct file *file, char __user
*data, size_t count, lo
struct cadet *dev = video_drvdata(file);
unsigned char readbuf[RDS_BUFFER];
int i = 0;
+ DEFINE_WAIT(wait);
mutex_lock(&dev->lock);
if (dev->rdsstat == 0)
cadet_start_rds(dev);
- if (dev->rdsin == dev->rdsout) {
+ while (1) {
+ prepare_to_wait(&dev->read_queue, &wait, TASK_INTERRUPTIBLE);
+ if (dev->rdsin != dev->rdsout)
+ break;
+
if (file->f_flags & O_NONBLOCK) {
i = -EWOULDBLOCK;
goto unlock;
}
mutex_unlock(&dev->lock);
- interruptible_sleep_on(&dev->read_queue);
+ schedule();
mutex_lock(&dev->lock);
}
+
while (i < count && dev->rdsin != dev->rdsout)
readbuf[i++] = dev->rdsbuf[dev->rdsout++];
if (i && copy_to_user(data, readbuf, i))
i = -EFAULT;
unlock:
+ finish_wait(&dev->read_queue, &wait);
mutex_unlock(&dev->lock);
return i;
}
--
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, RFC 08/30] [media] arv: fix sleep_on race
interruptible_sleep_on is racy and going away. In the arv driver that
race has probably never caused problems since it would require a whole
video frame to be captured before the read function has a chance to
go to sleep, but using wait_event_interruptible lets us kill off the
old interface. In order to do this, we have to slightly adapt the
meaning of the ar->start_capture field to distinguish between not having
started a frame and having completed it.
Signed-off-by: Arnd Bergmann
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
---
drivers/media/platform/arv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/arv.c b/drivers/media/platform/arv.c
index e346d32d..32f6d70 100644
--- a/drivers/media/platform/arv.c
+++ b/drivers/media/platform/arv.c
@@ -307,11 +307,11 @@ static ssize_t ar_read(struct file *file, char *buf,
size_t count, loff_t *ppos)
/*
* Okay, kick AR LSI to invoke an interrupt
*/
- ar->start_capture = 0;
+ ar->start_capture = -1;
ar_outl(arvcr1 | ARVCR1_HIEN, ARVCR1);
local_irq_restore(flags);
/* AR interrupts */
- interruptible_sleep_on(&ar->wait);
+ wait_event_interruptible(ar->wait, ar->start_capture == 0);
if (signal_pending(current)) {
printk(KERN_ERR "arv: interrupted while get frame data.\n");
ret = -EINTR;
--
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, RFC 05/30] [media] omap_vout: avoid sleep_on race
sleep_on and its variants are broken and going away soon. This changes
the omap vout driver to use interruptible_sleep_on_timeout instead,
which fixes potential race where the dma is complete before we
schedule.
Signed-off-by: Arnd Bergmann
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
---
drivers/media/platform/omap/omap_vout_vrfb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/omap/omap_vout_vrfb.c
b/drivers/media/platform/omap/omap_vout_vrfb.c
index cf1c437..62e7e57 100644
--- a/drivers/media/platform/omap/omap_vout_vrfb.c
+++ b/drivers/media/platform/omap/omap_vout_vrfb.c
@@ -270,7 +270,8 @@ int omap_vout_prepare_vrfb(struct omap_vout_device *vout,
omap_dma_set_global_params(DMA_DEFAULT_ARB_RATE, 0x20, 0);
omap_start_dma(tx->dma_ch);
- interruptible_sleep_on_timeout(&tx->wait, VRFB_TX_TIMEOUT);
+ wait_event_interruptible_timeout(tx->wait, tx->tx_status == 1,
+VRFB_TX_TIMEOUT);
if (tx->tx_status == 0) {
omap_stop_dma(tx->dma_ch);
--
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, RFC 00/30] sleep_on removal
The functions sleep_on, sleep_on_timeout, interruptible_sleep_on and interruptible_sleep_on_timeout have been deprecated for as long as I can remember, and a number of people have contributed patches in the past to remove them from various drivers. This has recently popped up again and I decided to spend some of my time on tracking down the last users and kill it for good. The work is somewhat related to the BKL removal I did a couple of years ago, since most of these drivers were using the BKL in a way that actually made the sleep_on function safe to call. As the BKL was converted into mutexes, the semantics changed slightly and typically opened up a race between checking a condition and going to sleep. I don't have any of the hardware that I'm sending the patches for, so it would be great if someone could test them before they get applied. Otherwise please review very carefully. I'm definitely happy for any patches to go into maintainer trees right away. Obviously the final patch cannot go in until everything else gets merged first and I suspect there will be a series of patches for maintainerless drivers that will go along with it. Arnd Arnd Bergmann (30): ataflop: fix sleep_on races scsi: atari_scsi: fix sleep_on race DAC960: remove sleep_on usage swim3: fix interruptible_sleep_on race [media] omap_vout: avoid sleep_on race [media] usbvision: remove bogus sleep_on_timeout [media] radio-cadet: avoid interruptible_sleep_on race [media] arv: fix sleep_on race staging: serqt_usb2: don't use sleep_on staging: gdm72xx: fix interruptible_sleep_on race staging: panel: fix interruptible_sleep_on race parport: fix interruptible_sleep_on race cris: sync_serial: remove interruptible_sleep_on tty/amiserial: avoid interruptible_sleep_on usbserial: stop using interruptible_sleep_on tty: synclink: avoid sleep_on race atm: nicstar: remove interruptible_sleep_on_timeout atm: firestream: fix interruptible_sleep_on race isdn: pcbit: fix interruptible_sleep_on race isdn: hisax/elsa: fix sleep_on race in elsa FSM isdn: divert, hysdn: fix interruptible_sleep_on race isdn: fix multiple sleep_on races oss: msnd_pinnacle: avoid interruptible_sleep_on_timeout oss: midibuf: fix sleep_on races oss: vwsnd: avoid interruptible_sleep_on oss: dmasound: kill SLEEP() macro to avoid race oss: remove last sleep_on users sgi-xp: open-code interruptible_sleep_on_timeout char: nwbutton: open-code interruptible_sleep_on sched: remove sleep_on() and friends Documentation/DocBook/kernel-hacking.tmpl| 10 -- arch/cris/arch-v10/drivers/sync_serial.c | 4 ++- arch/cris/arch-v32/drivers/sync_serial.c | 4 ++- drivers/atm/firestream.c | 4 +-- drivers/atm/nicstar.c| 13 drivers/block/DAC960.c | 34 +-- drivers/block/ataflop.c | 16 - drivers/block/swim3.c| 18 ++ drivers/char/nwbutton.c | 5 ++- drivers/char/pcmcia/synclink_cs.c| 4 +-- drivers/isdn/divert/divert_procfs.c | 7 ++-- drivers/isdn/hisax/elsa.c| 9 +++-- drivers/isdn/hisax/elsa_ser.c| 3 +- drivers/isdn/hysdn/hysdn_proclog.c | 7 ++-- drivers/isdn/i4l/isdn_common.c | 13 +--- drivers/isdn/pcbit/drv.c | 6 ++-- drivers/media/platform/arv.c | 4 +-- drivers/media/platform/omap/omap_vout_vrfb.c | 3 +- drivers/media/radio/radio-cadet.c| 12 +-- drivers/media/usb/usbvision/usbvision.h | 4 +-- drivers/misc/sgi-xp/xpc_channel.c| 5 ++- drivers/parport/share.c | 3 +- drivers/scsi/atari_scsi.c| 12 +-- drivers/staging/gdm72xx/gdm_usb.c| 5 +-- drivers/staging/panel/panel.c| 4 +-- drivers/staging/serqt_usb2/serqt_usb2.c | 17 -- drivers/tty/amiserial.c | 26 ++- drivers/tty/synclink.c | 4 +-- drivers/tty/synclink_gt.c| 4 +-- drivers/tty/synclinkmp.c | 4 +-- drivers/usb/serial/ch341.c | 29 +++- drivers/usb/serial/cypress_m8.c | 49 ++-- drivers/usb/serial/f81232.c | 29 +++- drivers/usb/serial/pl2303.c | 29 +++- include/linux/wait.h | 11 --- kernel/sched/core.c | 46 -- sound/oss/dmabuf.c | 14 sound/oss/dmasound/dmasound.h| 1 - sound/oss/dmasound/dmasound_core.c | 28 +++- sound/oss/midibuf.c | 18 +- sound/oss/msnd_pinnacle.c| 31 ++ sound
using MFC memory to memery encoder, start stream and queue order problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello I have follow the README of the v4l2-mfc-encoder from the http://git.infradead.org/users/kmpark/public-apps it seems that I can use the mfc encoder in exynos4412(using 3.5 kernel from manufacturer). But I have a problem with the contain of the README and I can't get the key frame(the I-frame in H.264). It said that "6. Enqueue CAPTURE buffers. 7. Enqueue OUTPUT buffer with first frame. 8. Start streaming (VIDIOC_STREAMON) on both ends." so I shall enqueue buffer before start stream, to enqueue a buffer, I need to dequeue first, but without start stream, it will failed in both side. In this way I start OUTPUT(input raw video) stream first then dequeue and enqueue the first frame, then I start the CAPTURE(output encoded video) frame, dequeue CAPTURE to get a buffer, get the data from buffer then enqueue the buffer. The first frame of CAPTURE is always a 22 bytes frame(I don't know whether they are the same data all the time, but size is the same from m.planes[0].bytesused), but it seems not a key frame. What is the problem, and how to solve it. P.S I don't test the Linux 3.13-rc4, as the driver is not ready for encoder before. Thank you -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJSxU74AAoJEPb4VsMIzTzi2oEH/1JJqfeZhMwogvWSVz+M3J4Y 2Bnej0RBBKF0Gu508IWrHy9t+DPg3c3wJt1M0j+GtUsv2Q+Jl2vlmDTLV/Gafzo6 xywye4raHpqHreFv4Q55SIseDbfV79eO84uv4RuV/fXEuPpo1MlZf9SOGCiAfoQI ozxqoOPD2l2VaSA/351gtT93lkOREF2EnmVf2Wa31WWHw0LV3aoY9/OosxOiY9Fy mVHHpYheDwHXdPfrxHXWKEA5GOJ7h0ozc66MPe7JInKSGdUcDrdrFxdSVwyZ/21B Oc2Aw9RMd85NwjXBc9hYH++3f73tcVhzMCF7Swyb+bsn4Mzyr64Bn4VsYaDqiCc= =HCKX -END PGP SIGNATURE- -- 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: [linux-uvc-devel] Closing Bulk Stream in V4L2 UVC Linux driver
Thanks for the answer. First, I mentioned something wrong below, I meant "AltSet 0" (alternateSetting set 0) instead of "AltSet 1" (alternateSetting set 1). Sorry about that. What STREAMOFF does is the following: - uvc_uninit_video (frees URB buffers) - usb_set_interface 0 (sends set alternate 0) - uvc_queue_enable 0 (sends vb2_streamoff) - uvc_video_clock_cleanup (cleanup some memory) What STREAMON does is the following: - uvc_video_clock_init (init some memory) - uvc_queue_enable (sends vb2_streamon) - uvc_commit_video (sends commit to USB) - uvc_init_video (allocated URB buffers) So when do you think the device should "open"/"close" a stream/interface? Maybe "open" stream when "commit" is received and "close" stream when "set alternate 0" is received? Thanks, Hani; -Original Message- From: Paulo Assis [mailto:pj.as...@gmail.com] Sent: Thursday, January 02, 2014 11:43 To: Ayoub, Hani Cc: linux-uvc-de...@lists.sourceforge.net; Linux Media Mailing List Subject: Re: [linux-uvc-devel] Closing Bulk Stream in V4L2 UVC Linux driver Hi, guvcview just handles this like any other V4L2 device. You should look at the driver in this case, and check what it does when a VIDIOC_STREAMOFF is received. Regards, Paulo PS: adding linux media to CC 2014/1/1 Ayoub, Hani : > Hi, > > I'm trying to bring up a device which sends data using BULK transfer > using > V4L2 UVC Linux driver (Ubuntu 12.04). > > Using guvcview, I can see that the device transfer data successfully > and I can see a stream. However, that works fine ONLY the first time I > run guvcview after I plug-in the device, closing the app and > re-launching it does not show any pictures... to get a good stream I > have to re-plug-in the device to the USB 3.0 port. > > > > Via USB analyzer, I can see that when closing the application (closing > the > device) an "AltSet 1" (alternateSetting set 1) is sent although it's > prohibited by spec (UVC 1.1 section 2.4.3) - so the device ignores it, > this (I think) is the reason why the stream doesn't work when > re-launching the application. > > > > My question is: how should I properly close the stream in BULK? Is > there any way to "patch" V4L or the application to make closing the device > works fine? > > There are some similar discussions in the web, but I think there's no > real answer (some references below) > > > > References: > > * Thread1 > > * Thread2 > > * Thread3 > > * Thread4 > > > > Thanks, > > Hani; > > - > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > -- > Rapidly troubleshoot problems before they affect your > business. Most IT organizations don't have a clear picture of how > application performance affects their revenue. With AppDynamics, you > get 100% visibility into your Java,.NET, & PHP application. Start your > 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.c > lktrk ___ > Linux-uvc-devel mailing list > linux-uvc-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-uvc-devel > - Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- 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: [linux-uvc-devel] Closing Bulk Stream in V4L2 UVC Linux driver
Hi, guvcview just handles this like any other V4L2 device. You should look at the driver in this case, and check what it does when a VIDIOC_STREAMOFF is received. Regards, Paulo PS: adding linux media to CC 2014/1/1 Ayoub, Hani : > Hi, > > I’m trying to bring up a device which sends data using BULK transfer using > V4L2 UVC Linux driver (Ubuntu 12.04). > > Using guvcview, I can see that the device transfer data successfully and I > can see a stream. However, that works fine ONLY the first time I run > guvcview after I plug-in the device, closing the app and re-launching it > does not show any pictures… to get a good stream I have to re-plug-in the > device to the USB 3.0 port. > > > > Via USB analyzer, I can see that when closing the application (closing the > device) an “AltSet 1” (alternateSetting set 1) is sent although it’s > prohibited by spec (UVC 1.1 section 2.4.3) – so the device ignores it, this > (I think) is the reason why the stream doesn’t work when re-launching the > application. > > > > My question is: how should I properly close the stream in BULK? Is there any > way to “patch” V4L or the application to make closing the device works fine? > > There are some similar discussions in the web, but I think there’s no real > answer (some references below) > > > > References: > > · Thread1 > > · Thread2 > > · Thread3 > > · Thread4 > > > > Thanks, > > Hani; > > - > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > -- > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > ___ > Linux-uvc-devel mailing list > linux-uvc-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-uvc-devel > -- 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
