[PATCH] s5p-jpeg: exynos3250: fix erroneous reset procedure
The first while loop in the function exynos3250_jpeg_reset had no chance
to be executed because the reg variable was initialized to 0.
Initialize reg variable to 1 to fix the issue.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Reported-by: Andrzej Pietrasiewicz andrze...@samsung.com
---
.../media/platform/s5p-jpeg/jpeg-hw-exynos3250.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c
b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c
index e8c2cad..0974b9a 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c
@@ -20,7 +20,7 @@
void exynos3250_jpeg_reset(void __iomem *regs)
{
- u32 reg = 0;
+ u32 reg = 1;
int count = 1000;
writel(1, regs + EXYNOS3250_SW_RESET);
--
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
Re: [REVIEW PATCH 3/3] smiapp: Use __v4l2_ctrl_grab() to grab controls
On 02/25/15 14:57, Sakari Ailus wrote:
Hi Hans,
On Wed, Feb 25, 2015 at 02:45:58PM +0100, Hans Verkuil wrote:
...
@@ -1535,15 +1529,15 @@ static int smiapp_set_stream(struct v4l2_subdev
*subdev, int enable)
if (sensor-streaming == enable)
goto out;
- if (enable) {
- sensor-streaming = true;
+ if (enable)
rval = smiapp_start_streaming(sensor);
- if (rval 0)
- sensor-streaming = false;
- } else {
+ else
rval = smiapp_stop_streaming(sensor);
- sensor-streaming = false;
- }
+
+ sensor-streaming = enable;
+ __v4l2_ctrl_grab(sensor-hflip, enable);
+ __v4l2_ctrl_grab(sensor-vflip, enable);
+ __v4l2_ctrl_grab(sensor-link_freq, enable);
Just checking: is it really not possible to change these controls
while streaming? Most devices I know of allow changing this on the fly.
If it is really not possible, then you can add my Ack for this series:
I'm not sure what the sensors would do in practice, but the problem is that
changing the values of these control affect the pixel order. That's why
changing them has been prevented while streaming.
Ah, OK.
Can you add a comment explaining why this is done?
BTW, I understand that HFLIP will cause changes in the pixel order,
but VFLIP and link_freq should be OK, I would expect.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 3/3] smiapp: Use __v4l2_ctrl_grab() to grab controls
Hi Hans,
On Wed, Feb 25, 2015 at 03:14:16PM +0100, Hans Verkuil wrote:
On 02/25/15 14:57, Sakari Ailus wrote:
Hi Hans,
On Wed, Feb 25, 2015 at 02:45:58PM +0100, Hans Verkuil wrote:
...
@@ -1535,15 +1529,15 @@ static int smiapp_set_stream(struct v4l2_subdev
*subdev, int enable)
if (sensor-streaming == enable)
goto out;
- if (enable) {
- sensor-streaming = true;
+ if (enable)
rval = smiapp_start_streaming(sensor);
- if (rval 0)
- sensor-streaming = false;
- } else {
+ else
rval = smiapp_stop_streaming(sensor);
- sensor-streaming = false;
- }
+
+ sensor-streaming = enable;
+ __v4l2_ctrl_grab(sensor-hflip, enable);
+ __v4l2_ctrl_grab(sensor-vflip, enable);
+ __v4l2_ctrl_grab(sensor-link_freq, enable);
Just checking: is it really not possible to change these controls
while streaming? Most devices I know of allow changing this on the fly.
If it is really not possible, then you can add my Ack for this series:
I'm not sure what the sensors would do in practice, but the problem is that
changing the values of these control affect the pixel order. That's why
changing them has been prevented while streaming.
Ah, OK.
Can you add a comment explaining why this is done?
BTW, I understand that HFLIP will cause changes in the pixel order,
but VFLIP and link_freq should be OK, I would expect.
Sure I can add a comment. Same for vflip, it will change the pixel order.
The flip controls will change the readout direction. For example, a 4x4
bayer sensor:
GRGR
BGBG
GRGR
BGBG
Without flipping, the readout of the first line will be GRGR while the
second is BGBG. With vertical flipping, the first line read out from the
sensor will be BGBG and the second GRGR.
The link frequency cannot be changed since this would change the sensor PLL
configuration and the CSI-2 bus frequency, neither of which are changeable
while streaming.
--
Regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: em28xx replace printk in dprintk macros
Em Tue, 24 Feb 2015 19:45:50 -0800
Joe Perches j...@perches.com escreveu:
On Tue, 2015-02-24 at 16:41 -0700, Shuah Khan wrote:
On 02/24/2015 03:03 PM, Mauro Carvalho Chehab wrote:
Em Tue, 24 Feb 2015 11:53:47 -0700 Shuah Khan shua...@osg.samsung.com
escreveu:
Replace printk macro in dprintk macros in em28xx audio, dvb,
and input files with pr_* equivalent routines.
[]
diff --git a/drivers/media/usb/em28xx/em28xx-input.c
b/drivers/media/usb/em28xx/em28xx-input.c
[]
#define dprintk(fmt, arg...) \
if (ir_debug) { \
-printk(KERN_DEBUG %s/ir: fmt, ir-name , ## arg); \
+pr_debug(%s/ir: fmt, ir-name, ## arg); \
NACK.
This is the worse of two words, as it would require both to enable
each debug line via dynamic printk setting and to enable ir_debug.
Ah. I missed that. Sorry for the noise.
It's
At some point, I'm going to propose a standard mechanism
similar to netif_level that does bitmap matching for
dynamic_debug and generic debugging.
Such mechanism would make sense for media drivers.
Regards,
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
[REVIEW PATCH 2/3] smiapp: Correctly serialise stream start / stop
From: Sakari Ailus sakari.ai...@linux.intel.com
The stream state was stored in sensor-streaming, but access to it was not
serialised properly. Fix this by moving the mutex to smiapp_set_stream().
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
---
drivers/media/i2c/smiapp/smiapp-core.c | 54 ++--
1 file changed, 24 insertions(+), 30 deletions(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c
index d47eff5..e534f1b 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -1391,28 +1391,26 @@ static int smiapp_start_streaming(struct smiapp_sensor
*sensor)
struct i2c_client *client = v4l2_get_subdevdata(sensor-src-sd);
int rval;
- mutex_lock(sensor-mutex);
-
rval = smiapp_write(sensor, SMIAPP_REG_U16_CSI_DATA_FORMAT,
(sensor-csi_format-width 8) |
sensor-csi_format-compressed);
if (rval)
- goto out;
+ return rval;
rval = smiapp_pll_configure(sensor);
if (rval)
- goto out;
+ return rval;
/* Analog crop start coordinates */
rval = smiapp_write(sensor, SMIAPP_REG_U16_X_ADDR_START,
sensor-pixel_array-crop[SMIAPP_PA_PAD_SRC].left);
if (rval 0)
- goto out;
+ return rval;
rval = smiapp_write(sensor, SMIAPP_REG_U16_Y_ADDR_START,
sensor-pixel_array-crop[SMIAPP_PA_PAD_SRC].top);
if (rval 0)
- goto out;
+ return rval;
/* Analog crop end coordinates */
rval = smiapp_write(
@@ -1420,14 +1418,14 @@ static int smiapp_start_streaming(struct smiapp_sensor
*sensor)
sensor-pixel_array-crop[SMIAPP_PA_PAD_SRC].left
+ sensor-pixel_array-crop[SMIAPP_PA_PAD_SRC].width - 1);
if (rval 0)
- goto out;
+ return rval;
rval = smiapp_write(
sensor, SMIAPP_REG_U16_Y_ADDR_END,
sensor-pixel_array-crop[SMIAPP_PA_PAD_SRC].top
+ sensor-pixel_array-crop[SMIAPP_PA_PAD_SRC].height - 1);
if (rval 0)
- goto out;
+ return rval;
/*
* Output from pixel array, including blanking, is set using
@@ -1441,25 +1439,25 @@ static int smiapp_start_streaming(struct smiapp_sensor
*sensor)
sensor, SMIAPP_REG_U16_DIGITAL_CROP_X_OFFSET,
sensor-scaler-crop[SMIAPP_PAD_SINK].left);
if (rval 0)
- goto out;
+ return rval;
rval = smiapp_write(
sensor, SMIAPP_REG_U16_DIGITAL_CROP_Y_OFFSET,
sensor-scaler-crop[SMIAPP_PAD_SINK].top);
if (rval 0)
- goto out;
+ return rval;
rval = smiapp_write(
sensor, SMIAPP_REG_U16_DIGITAL_CROP_IMAGE_WIDTH,
sensor-scaler-crop[SMIAPP_PAD_SINK].width);
if (rval 0)
- goto out;
+ return rval;
rval = smiapp_write(
sensor, SMIAPP_REG_U16_DIGITAL_CROP_IMAGE_HEIGHT,
sensor-scaler-crop[SMIAPP_PAD_SINK].height);
if (rval 0)
- goto out;
+ return rval;
}
/* Scaling */
@@ -1468,23 +1466,23 @@ static int smiapp_start_streaming(struct smiapp_sensor
*sensor)
rval = smiapp_write(sensor, SMIAPP_REG_U16_SCALING_MODE,
sensor-scaling_mode);
if (rval 0)
- goto out;
+ return rval;
rval = smiapp_write(sensor, SMIAPP_REG_U16_SCALE_M,
sensor-scale_m);
if (rval 0)
- goto out;
+ return rval;
}
/* Output size from sensor */
rval = smiapp_write(sensor, SMIAPP_REG_U16_X_OUTPUT_SIZE,
sensor-src-crop[SMIAPP_PAD_SRC].width);
if (rval 0)
- goto out;
+ return rval;
rval = smiapp_write(sensor, SMIAPP_REG_U16_Y_OUTPUT_SIZE,
sensor-src-crop[SMIAPP_PAD_SRC].height);
if (rval 0)
- goto out;
+ return rval;
if ((sensor-limits[SMIAPP_LIMIT_FLASH_MODE_CAPABILITY]
(SMIAPP_FLASH_MODE_CAPABILITY_SINGLE_STROBE |
@@ -1493,22 +1491,17 @@ static int smiapp_start_streaming(struct smiapp_sensor
*sensor)
sensor-platform_data-strobe_setup-trigger != 0) {
rval = smiapp_setup_flash_strobe(sensor);
[REVIEW PATCH 0/3] Add unlocked v4l2_grab_ctrl(), use it in smiapp driver
Hi, This patchset adds an unlocked variant of v4l2_grab_ctrl() which then is used by the smiapp driver. -- Regards, Sakari -- 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
[REVIEW PATCH 3/3] smiapp: Use __v4l2_ctrl_grab() to grab controls
From: Sakari Ailus sakari.ai...@linux.intel.com
Instead of returning -EBUSY in s_ctrl(), use __v4l2_ctrl_grab() to mark the
controls grabbed.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
---
drivers/media/i2c/smiapp/smiapp-core.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c
index e534f1b..6658f61 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -423,9 +423,6 @@ static int smiapp_set_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_HFLIP:
case V4L2_CID_VFLIP:
- if (sensor-streaming)
- return -EBUSY;
-
if (sensor-hflip-val)
orient |= SMIAPP_IMAGE_ORIENTATION_HFLIP;
@@ -469,9 +466,6 @@ static int smiapp_set_ctrl(struct v4l2_ctrl *ctrl)
+ ctrl-val);
case V4L2_CID_LINK_FREQ:
- if (sensor-streaming)
- return -EBUSY;
-
return smiapp_pll_update(sensor);
case V4L2_CID_TEST_PATTERN: {
@@ -1535,15 +1529,15 @@ static int smiapp_set_stream(struct v4l2_subdev
*subdev, int enable)
if (sensor-streaming == enable)
goto out;
- if (enable) {
- sensor-streaming = true;
+ if (enable)
rval = smiapp_start_streaming(sensor);
- if (rval 0)
- sensor-streaming = false;
- } else {
+ else
rval = smiapp_stop_streaming(sensor);
- sensor-streaming = false;
- }
+
+ sensor-streaming = enable;
+ __v4l2_ctrl_grab(sensor-hflip, enable);
+ __v4l2_ctrl_grab(sensor-vflip, enable);
+ __v4l2_ctrl_grab(sensor-link_freq, enable);
out:
mutex_unlock(sensor-mutex);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[REVIEW PATCH 1/3] v4l: Add an unlocked variant of v4l2_grab_ctrl()
From: Sakari Ailus sakari.ai...@linux.intel.com
Commonly the control mutex is shared with the rest of the driver, which
already holds the mutex when accessing the control framework. Add
unlocked v4l2_grab_ctrl(), __v4l2_grab_ctrl() for this purpose.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
---
drivers/media/v4l2-core/v4l2-ctrls.c |6 ++
include/media/v4l2-ctrls.h | 13 -
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 45c5b47..a80bc9f 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -2344,14 +2344,13 @@ EXPORT_SYMBOL(v4l2_ctrl_activate);
Just call this and the framework will block any attempts to change
these controls. */
-void v4l2_ctrl_grab(struct v4l2_ctrl *ctrl, bool grabbed)
+void __v4l2_ctrl_grab(struct v4l2_ctrl *ctrl, bool grabbed)
{
bool old;
if (ctrl == NULL)
return;
- v4l2_ctrl_lock(ctrl);
if (grabbed)
/* set V4L2_CTRL_FLAG_GRABBED */
old = test_and_set_bit(1, ctrl-flags);
@@ -2360,9 +2359,8 @@ void v4l2_ctrl_grab(struct v4l2_ctrl *ctrl, bool grabbed)
old = test_and_clear_bit(1, ctrl-flags);
if (old != grabbed)
send_event(NULL, ctrl, V4L2_EVENT_CTRL_CH_FLAGS);
- v4l2_ctrl_unlock(ctrl);
}
-EXPORT_SYMBOL(v4l2_ctrl_grab);
+EXPORT_SYMBOL(__v4l2_ctrl_grab);
/* Log the control name and value */
static void log_ctrl(const struct v4l2_ctrl *ctrl,
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index 911f3e5..b50d1dd 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -607,6 +607,9 @@ struct v4l2_ctrl *v4l2_ctrl_find(struct v4l2_ctrl_handler
*hdl, u32 id);
*/
void v4l2_ctrl_activate(struct v4l2_ctrl *ctrl, bool active);
+/** __v4l2_ctrl_grab() - Unlocked variant of v4l2_ctrl_grab() */
+void __v4l2_ctrl_grab(struct v4l2_ctrl *ctrl, bool grabbed);
+
/** v4l2_ctrl_grab() - Mark the control as grabbed or not grabbed.
* @ctrl: The control to (de)activate.
* @grabbed: True if the control should become grabbed.
@@ -620,7 +623,15 @@ void v4l2_ctrl_activate(struct v4l2_ctrl *ctrl, bool
active);
* This function assumes that the control handler is not locked and will
* take the lock itself.
*/
-void v4l2_ctrl_grab(struct v4l2_ctrl *ctrl, bool grabbed);
+static inline void v4l2_ctrl_grab(struct v4l2_ctrl *ctrl, bool grabbed)
+{
+ if (!ctrl)
+ return;
+
+ v4l2_ctrl_lock(ctrl);
+ __v4l2_ctrl_grab(ctrl, grabbed);
+ v4l2_ctrl_unlock(ctrl);
+}
/** __v4l2_ctrl_modify_range() - Unlocked variant of v4l2_ctrl_modify_range()
*/
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xc5000: fix memory corruption when unplugging device
On 02/24/2015 10:29 AM, Devin Heitmueller wrote:
This patch addresses a regression introduced in the following patch:
commit 5264a522a597032c009f9143686ebf0fa4e244fb
Author: Shuah Khan shua...@osg.samsung.com
Date: Mon Sep 22 21:30:46 2014 -0300
[media] media: tuner xc5000 - release firmwware from xc5000_release()
The priv struct is actually reference counted, so the xc5000_release()
function gets called multiple times for hybrid devices. Because
release_firmware() was always being called, it would work fine as expected
on the first call but then the second call would corrupt aribtrary memory.
Set the pointer to NULL after releasing so that we don't call
release_firmware() twice.
This problem was detected in the HVR-950q where plugging/unplugging the
device multiple times would intermittently show panics in completely
unrelated areas of the kernel.
Thanks for finding and fixing the problem.
Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com
Cc: Shuah Khan shua...@osg.samsung.com
---
drivers/media/tuners/xc5000.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/tuners/xc5000.c b/drivers/media/tuners/xc5000.c
index 40f9db6..74b2092 100644
--- a/drivers/media/tuners/xc5000.c
+++ b/drivers/media/tuners/xc5000.c
@@ -1314,7 +1314,10 @@ static int xc5000_release(struct dvb_frontend *fe)
if (priv) {
cancel_delayed_work(priv-timer_sleep);
- release_firmware(priv-firmware);
I would request you to add a comment here indicating the
hybrid case scenario to avoid any future cleanup type work
deciding there is no need to set priv-firmware to null
since priv gets released in hybrid_tuner_release_state(priv);
+ if (priv-firmware) {
+ release_firmware(priv-firmware);
+ priv-firmware = NULL;
+ }
hybrid_tuner_release_state(priv);
}
Adding Mauro as will to the thread. This should go into stable
as well.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
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 3/3] smiapp: Use __v4l2_ctrl_grab() to grab controls
Hi Hans,
On Wed, Feb 25, 2015 at 02:45:58PM +0100, Hans Verkuil wrote:
...
@@ -1535,15 +1529,15 @@ static int smiapp_set_stream(struct v4l2_subdev
*subdev, int enable)
if (sensor-streaming == enable)
goto out;
- if (enable) {
- sensor-streaming = true;
+ if (enable)
rval = smiapp_start_streaming(sensor);
- if (rval 0)
- sensor-streaming = false;
- } else {
+ else
rval = smiapp_stop_streaming(sensor);
- sensor-streaming = false;
- }
+
+ sensor-streaming = enable;
+ __v4l2_ctrl_grab(sensor-hflip, enable);
+ __v4l2_ctrl_grab(sensor-vflip, enable);
+ __v4l2_ctrl_grab(sensor-link_freq, enable);
Just checking: is it really not possible to change these controls
while streaming? Most devices I know of allow changing this on the fly.
If it is really not possible, then you can add my Ack for this series:
I'm not sure what the sensors would do in practice, but the problem is that
changing the values of these control affect the pixel order. That's why
changing them has been prevented while streaming.
Thanks for the ack!
--
Regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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 3/3] smiapp: Use __v4l2_ctrl_grab() to grab controls
On 02/25/15 15:22, Sakari Ailus wrote:
Hi Hans,
On Wed, Feb 25, 2015 at 03:14:16PM +0100, Hans Verkuil wrote:
On 02/25/15 14:57, Sakari Ailus wrote:
Hi Hans,
On Wed, Feb 25, 2015 at 02:45:58PM +0100, Hans Verkuil wrote:
...
@@ -1535,15 +1529,15 @@ static int smiapp_set_stream(struct v4l2_subdev
*subdev, int enable)
if (sensor-streaming == enable)
goto out;
- if (enable) {
- sensor-streaming = true;
+ if (enable)
rval = smiapp_start_streaming(sensor);
- if (rval 0)
- sensor-streaming = false;
- } else {
+ else
rval = smiapp_stop_streaming(sensor);
- sensor-streaming = false;
- }
+
+ sensor-streaming = enable;
+ __v4l2_ctrl_grab(sensor-hflip, enable);
+ __v4l2_ctrl_grab(sensor-vflip, enable);
+ __v4l2_ctrl_grab(sensor-link_freq, enable);
Just checking: is it really not possible to change these controls
while streaming? Most devices I know of allow changing this on the fly.
If it is really not possible, then you can add my Ack for this series:
I'm not sure what the sensors would do in practice, but the problem is that
changing the values of these control affect the pixel order. That's why
changing them has been prevented while streaming.
Ah, OK.
Can you add a comment explaining why this is done?
BTW, I understand that HFLIP will cause changes in the pixel order,
but VFLIP and link_freq should be OK, I would expect.
Sure I can add a comment. Same for vflip, it will change the pixel order.
The flip controls will change the readout direction. For example, a 4x4
bayer sensor:
GRGR
BGBG
GRGR
BGBG
Without flipping, the readout of the first line will be GRGR while the
second is BGBG. With vertical flipping, the first line read out from the
sensor will be BGBG and the second GRGR.
Ah, of course. A comment would be useful indeed as this is not immediately
obvious (well, not to me at least!).
The link frequency cannot be changed since this would change the sensor PLL
configuration and the CSI-2 bus frequency, neither of which are changeable
while streaming.
Sorry, my mistake. I confused the link frequency with the powerline frequency
control (50/60 Hz). Of course the link frequency can't be changed while
streaming.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 3/3] smiapp: Use __v4l2_ctrl_grab() to grab controls
Hi Sakari,
Thanks for the patch series, but I have one question, see below.
On 02/25/15 13:33, Sakari Ailus wrote:
From: Sakari Ailus sakari.ai...@linux.intel.com
Instead of returning -EBUSY in s_ctrl(), use __v4l2_ctrl_grab() to mark the
controls grabbed.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
---
drivers/media/i2c/smiapp/smiapp-core.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c
index e534f1b..6658f61 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -423,9 +423,6 @@ static int smiapp_set_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_HFLIP:
case V4L2_CID_VFLIP:
- if (sensor-streaming)
- return -EBUSY;
-
if (sensor-hflip-val)
orient |= SMIAPP_IMAGE_ORIENTATION_HFLIP;
@@ -469,9 +466,6 @@ static int smiapp_set_ctrl(struct v4l2_ctrl *ctrl)
+ ctrl-val);
case V4L2_CID_LINK_FREQ:
- if (sensor-streaming)
- return -EBUSY;
-
return smiapp_pll_update(sensor);
case V4L2_CID_TEST_PATTERN: {
@@ -1535,15 +1529,15 @@ static int smiapp_set_stream(struct v4l2_subdev
*subdev, int enable)
if (sensor-streaming == enable)
goto out;
- if (enable) {
- sensor-streaming = true;
+ if (enable)
rval = smiapp_start_streaming(sensor);
- if (rval 0)
- sensor-streaming = false;
- } else {
+ else
rval = smiapp_stop_streaming(sensor);
- sensor-streaming = false;
- }
+
+ sensor-streaming = enable;
+ __v4l2_ctrl_grab(sensor-hflip, enable);
+ __v4l2_ctrl_grab(sensor-vflip, enable);
+ __v4l2_ctrl_grab(sensor-link_freq, enable);
Just checking: is it really not possible to change these controls
while streaming? Most devices I know of allow changing this on the fly.
If it is really not possible, then you can add my Ack for this series:
Acked-by: Hans Verkuil hans.verk...@cisco.com
Regards,
Hans
out:
mutex_unlock(sensor-mutex);
--
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
[PATCHv3] media.h: mark alsa struct in media_entity_desc as TODO
The alsa struct in struct media_entity_desc is now marked as deprecated.
However, the alsa struct should remain as it is since it cannot be replaced
by a simple major/minor device node description. The alsa struct was designed
to be used as an alsa card description so V4L2 drivers could use this to expose
the alsa card that they create to carry the captured audio. Such a card is not
just a PCM device, but also needs to contain the alsa subdevice information,
and it may map to multiple devices, e.g. a PCM and a mixer device, such as the
au0828 usb stick creates.
This is exactly as intended and this cannot and should not be replaced by a
simple major/minor.
However, whether this information is in the right form for an ALSA device such
that it can handle udev renaming rules as well is another matter. So mark this
alsa struct as TODO and document the problems involved.
Updated the documentation as well to reflect this and to add the 'major'
and 'minor' field documentation.
Updated the documentation to clearly state that struct dev is to be used for
(sub-)devices that create a single device node. Other devices need their own
structure here.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
.../DocBook/media/v4l/media-ioc-enum-entities.xml | 16 -
include/uapi/linux/media.h | 26 +-
2 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
index cbf307f..5872f8bb 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
@@ -145,7 +145,21 @@
entrystruct/entry
entrystructfielddev/structfield/entry
entry/entry
- entryValid for (sub-)devices that create devnodes./entry
+ entryValid for (sub-)devices that create a single device
node./entry
+ /row
+ row
+ entry/entry
+ entry/entry
+ entry__u32/entry
+ entrystructfieldmajor/structfield/entry
+ entryDevice node major number./entry
+ /row
+ row
+ entry/entry
+ entry/entry
+ entry__u32/entry
+ entrystructfieldminor/structfield/entry
+ entryDevice node minor number./entry
/row
row
entry/entry
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 52cc2a6..4e816be 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -91,6 +91,27 @@ struct media_entity_desc {
#if 1
/*
+* TODO: this shouldn't have been added without
+* actual drivers that use this. When the first real driver
+* appears that sets this information, special attention
+* should be given whether this information is 1) enough, and
+* 2) can deal with udev rules that rename devices. The struct
+* dev would not be sufficient for this since that does not
+* contain the subdevice information. In addition, struct dev
+* can only refer to a single device, and not to multiple (e.g.
+* pcm and mixer devices).
+*
+* So for now mark this as a to do.
+*/
+ struct {
+ __u32 card;
+ __u32 device;
+ __u32 subdevice;
+ } alsa;
+#endif
+
+#if 1
+ /*
* DEPRECATED: previous node specifications. Kept just to
* avoid breaking compilation, but media_entity_desc.dev
* should be used instead. In particular, alsa and dvb
@@ -106,11 +127,6 @@ struct media_entity_desc {
__u32 major;
__u32 minor;
} fb;
- struct {
- __u32 card;
- __u32 device;
- __u32 subdevice;
- } alsa;
int dvb;
#endif
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: omap3isp: use vb2_buffer_state enum for vb2 buffer state
From: Lad, Prabhakar prabhakar.cse...@gmail.com
use the vb2_buffer_state enum for assigning the state
of the vb2 buffer, along side making isp_pipeline_state
state variable local to the block.
This fixes the following sparse warning as well:
drivers/media/platform/omap3isp/ispvideo.c:497:35: warning: mixing different
enum types
drivers/media/platform/omap3isp/ispvideo.c:497:35: int enum
isp_pipeline_state versus
drivers/media/platform/omap3isp/ispvideo.c:497:35: int enum vb2_buffer_state
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
drivers/media/platform/omap3isp/ispvideo.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispvideo.c
b/drivers/media/platform/omap3isp/ispvideo.c
index 3fe9047..8cd3a57 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -449,7 +449,7 @@ static const struct vb2_ops isp_video_queue_ops = {
struct isp_buffer *omap3isp_video_buffer_next(struct isp_video *video)
{
struct isp_pipeline *pipe = to_isp_pipeline(video-video.entity);
- enum isp_pipeline_state state;
+ enum vb2_buffer_state vb_state;
struct isp_buffer *buf;
unsigned long flags;
struct timespec ts;
@@ -488,17 +488,19 @@ struct isp_buffer *omap3isp_video_buffer_next(struct
isp_video *video)
/* Report pipeline errors to userspace on the capture device side. */
if (video-type == V4L2_BUF_TYPE_VIDEO_CAPTURE pipe-error) {
- state = VB2_BUF_STATE_ERROR;
+ vb_state = VB2_BUF_STATE_ERROR;
pipe-error = false;
} else {
- state = VB2_BUF_STATE_DONE;
+ vb_state = VB2_BUF_STATE_DONE;
}
- vb2_buffer_done(buf-vb, state);
+ vb2_buffer_done(buf-vb, vb_state);
spin_lock_irqsave(video-irqlock, flags);
if (list_empty(video-dmaqueue)) {
+ enum isp_pipeline_state state;
+
spin_unlock_irqrestore(video-irqlock, flags);
if (video-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cx18: Fix bytes_per_line
Current GStreamer userspace respects the bytes_per_line from the driver. Set
it to something reasonable for the format chosen.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
I'm hoping this is trivially correct - I've only tested UYVY.
drivers/media/pci/cx18/cx18-driver.h | 1 +
drivers/media/pci/cx18/cx18-ioctl.c | 9 ++---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/media/pci/cx18/cx18-driver.h
b/drivers/media/pci/cx18/cx18-driver.h
index 207d6e82..ec40f2d 100644
--- a/drivers/media/pci/cx18/cx18-driver.h
+++ b/drivers/media/pci/cx18/cx18-driver.h
@@ -409,6 +409,7 @@ struct cx18_stream {
/* Videobuf for YUV video */
u32 pixelformat;
u32 vb_bytes_per_frame;
+ u32 vb_bytes_per_line;
struct list_head vb_capture;/* video capture queue */
spinlock_t vb_lock;
struct timer_list vb_timeout;
diff --git a/drivers/media/pci/cx18/cx18-ioctl.c
b/drivers/media/pci/cx18/cx18-ioctl.c
index b8e4b68..c2e0093 100644
--- a/drivers/media/pci/cx18/cx18-ioctl.c
+++ b/drivers/media/pci/cx18/cx18-ioctl.c
@@ -159,7 +159,7 @@ static int cx18_g_fmt_vid_cap(struct file *file, void *fh,
if (id-type == CX18_ENC_STREAM_TYPE_YUV) {
pixfmt-pixelformat = s-pixelformat;
pixfmt-sizeimage = s-vb_bytes_per_frame;
- pixfmt-bytesperline = 720;
+ pixfmt-bytesperline = s-vb_bytes_per_line;
} else {
pixfmt-pixelformat = V4L2_PIX_FMT_MPEG;
pixfmt-sizeimage = 128 * 1024;
@@ -287,10 +287,13 @@ static int cx18_s_fmt_vid_cap(struct file *file, void *fh,
s-pixelformat = fmt-fmt.pix.pixelformat;
/* HM12 YUV size is (Y=(h*720) + UV=(h*(720/2)))
UYUV YUV size is (Y=(h*720) + UV=(h*(720))) */
- if (s-pixelformat == V4L2_PIX_FMT_HM12)
+ if (s-pixelformat == V4L2_PIX_FMT_HM12) {
s-vb_bytes_per_frame = h * 720 * 3 / 2;
- else
+ s-vb_bytes_per_line = 720; /* First plane */
+ } else {
s-vb_bytes_per_frame = h * 720 * 2;
+ s-vb_bytes_per_line = 1440; /* Packed */
+ }
mbus_fmt.width = cx-cxhdl.width = w;
mbus_fmt.height = cx-cxhdl.height = h;
--
2.1.0
--
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: i.MX6 Video combiner
On 02/25/2015 02:57 AM, Jean-Michel Hautbois wrote: Hi all, I read in the i.MX6 TRM that it can do combining or deinterlacing with VDIC. Has it been tested by anyone ? Could it be a driver, which would allow to do some simple compositing of souces ? Thanks, JM I've added VDIC support (deinterlace with motion compensation) to the capture driver, it's in the my media tree clone: g...@github.com:slongerbeam/mediatree.git, mx6-media-staging Steve -- 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] xc5000: fix memory corruption when unplugging device
I would request you to add a comment here indicating the hybrid case scenario to avoid any future cleanup type work deciding there is no need to set priv-firmware to null since priv gets released in hybrid_tuner_release_state(priv); No, I'm not going to rebase my tree and regenerate the patch just to add a comment explaining how hybrid_tuner_[request/release]_state() works (which, btw, is how it works in all hybrid tuner drivers). I already wasted enough of my time tracking down the source of the memory corruption and providing a fix for this regression. If you want to submit a subsequent patch with a comment, be my guest. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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: i.MX6 Video combiner
On 02/25/2015 09:37 AM, Steve Longerbeam wrote: On 02/25/2015 02:57 AM, Jean-Michel Hautbois wrote: Hi all, I read in the i.MX6 TRM that it can do combining or deinterlacing with VDIC. Has it been tested by anyone ? Could it be a driver, which would allow to do some simple compositing of souces ? Thanks, JM I've added VDIC support (deinterlace with motion compensation) to the capture driver, it's in the my media tree clone: g...@github.com:slongerbeam/mediatree.git, mx6-media-staging it is activated if user sets the motion compensation control to 1 (low motion), 2 (medium motion), or 3 (high motion), for example: # v4l2-ctl --set-ctrl=motion_compensation=2 Steve -- 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: 0001-media-vb2-Fill-vb2_buffer-with-bytesused-from-user.patch
Hi Sudip, 2015-02-25 19:23 GMT+01:00 Jeremiah Mahler jmmah...@gmail.com: Sudip, On Wed, Feb 25, 2015 at 03:29:22PM +0800, Sudip JAIN wrote: Dear Maintainer, PFA attached patch that prevents user from being returned garbage bytesused value from vb2 framework. Regards, Sudip Jain Patches should never be submitted as attachments, they should be inline. See Documentation/SubmittingPatches for more info. You also can have a look here : http://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches In fact, is the patch on top of master tree ? According to line numbers, I would say no. Thx, JM -- 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: i.MX6 Video combiner
Hi Steve, 2015-02-25 18:54 GMT+01:00 Steve Longerbeam slongerb...@gmail.com: On 02/25/2015 09:37 AM, Steve Longerbeam wrote: On 02/25/2015 02:57 AM, Jean-Michel Hautbois wrote: Hi all, I read in the i.MX6 TRM that it can do combining or deinterlacing with VDIC. Has it been tested by anyone ? Could it be a driver, which would allow to do some simple compositing of souces ? Thanks, JM I've added VDIC support (deinterlace with motion compensation) to the capture driver, it's in the my media tree clone: g...@github.com:slongerbeam/mediatree.git, mx6-media-staging it is activated if user sets the motion compensation control to 1 (low motion), 2 (medium motion), or 3 (high motion), for example: # v4l2-ctl --set-ctrl=motion_compensation=2 Thx for the tip :). And in fact, it is only deinterlacing, not combining two planes with background as specified in the TRM (or did I miss something ?). JM -- 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] xc5000: fix memory corruption when unplugging device
On 02/25/2015 07:56 PM, Devin Heitmueller wrote: I would request you to add a comment here indicating the hybrid case scenario to avoid any future cleanup type work deciding there is no need to set priv-firmware to null since priv gets released in hybrid_tuner_release_state(priv); No, I'm not going to rebase my tree and regenerate the patch just to add a comment explaining how hybrid_tuner_[request/release]_state() works (which, btw, is how it works in all hybrid tuner drivers). I already wasted enough of my time tracking down the source of the memory corruption and providing a fix for this regression. If you want to submit a subsequent patch with a comment, be my guest. These are just the issues I would like to implement drivers as standard I2C driver model =) Attaching driver for one chip twice is ugly hack! regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xc5000: fix memory corruption when unplugging device
These are just the issues I would like to implement drivers as standard I2C driver model =) Attaching driver for one chip twice is ugly hack! While I'm not arguing the merits of using the standard I2C driver model, it won't actually help in this case since we would still need a structure representing shared state accessible by both the DVB and V4L2 subsystems. And that struct will need to be referenced counted, which is exactly what hybrid_tuner_request_state() does. In short, what you're proposing doesn't have any relevance to this case - it just moves the problem to some other mechanism for sharing private state between two drivers and having to reference count it. And at least in this case it's done the same way for all the tuner drivers (as opposed to different tuners re-inventing their own mechanism for sharing state between the different consumers). If you ever get around to implementing support for a hybrid device (where you actually have to worry about how both digital and analog share a single tuner), you'll appreciate some of these challenges and why what was done was not as bad/crazy as you might think. If anything, this little regression is yet another point of evidence that innocent refactoring and cleanup of existing code without really understanding what it does and/or performing significant testing can leave everybody worse off than if the well-intentioned committer had done nothing at all. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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: 0001-media-vb2-Fill-vb2_buffer-with-bytesused-from-user.patch
Sudip, On Wed, Feb 25, 2015 at 03:29:22PM +0800, Sudip JAIN wrote: Dear Maintainer, PFA attached patch that prevents user from being returned garbage bytesused value from vb2 framework. Regards, Sudip Jain Patches should never be submitted as attachments, they should be inline. See Documentation/SubmittingPatches for more info. [...] -- - Jeremiah Mahler -- 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] xc5000: fix memory corruption when unplugging device
Em Wed, 25 Feb 2015 13:37:07 -0500 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: These are just the issues I would like to implement drivers as standard I2C driver model =) Attaching driver for one chip twice is ugly hack! While I'm not arguing the merits of using the standard I2C driver model, it won't actually help in this case since we would still need a structure representing shared state accessible by both the DVB and V4L2 subsystems. And that struct will need to be referenced counted, which is exactly what hybrid_tuner_request_state() does. ... If you ever get around to implementing support for a hybrid device (where you actually have to worry about how both digital and analog share a single tuner), you'll appreciate some of these challenges and why what was done was not as bad/crazy as you might think. The I2C model that Antti is proposing may work, but, for that, we'll very likely need to re-write the tuner core. Currently, the binding model is: for analog: tuner driver - tuner-core module == V4L2 driver The interface between V4L2 driver and tuner core is the I2C high level API. for digital tuner driver == DVB driver The interface between the tuner driver and the DVB driver is the I2C low level API. Antti's proposal makes the DVB driver to use the high level I2C API, with makes the DVB driver a little closer to what V4L2 does. Yet, for V4L2, the tuner-core module is required. The binding code at the tuner-core is very complex, as it needs to talk both V4L2 and DVB dialogs. This should be simplified. In other words, If we want to use the same model for all tuners, we'll need to rewrite the binding schema to avoid the need of a tuner core module, or to replace it by something better/simpler. For locking the tuner between analog/digital usage, the best approach seems to be to use the media controller. Regards, 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: i.MX6 Video combiner
2015-02-25 22:44 GMT+01:00 Steve Longerbeam slongerb...@gmail.com: On 02/25/2015 11:40 AM, Jean-Michel Hautbois wrote: Hi Steve, 2015-02-25 18:54 GMT+01:00 Steve Longerbeam slongerb...@gmail.com: On 02/25/2015 09:37 AM, Steve Longerbeam wrote: On 02/25/2015 02:57 AM, Jean-Michel Hautbois wrote: Hi all, I read in the i.MX6 TRM that it can do combining or deinterlacing with VDIC. Has it been tested by anyone ? Could it be a driver, which would allow to do some simple compositing of souces ? Thanks, JM I've added VDIC support (deinterlace with motion compensation) to the capture driver, it's in the my media tree clone: g...@github.com:slongerbeam/mediatree.git, mx6-media-staging it is activated if user sets the motion compensation control to 1 (low motion), 2 (medium motion), or 3 (high motion), for example: # v4l2-ctl --set-ctrl=motion_compensation=2 Thx for the tip :). And in fact, it is only deinterlacing, not combining two planes with background as specified in the TRM (or did I miss something ?). Hi JM, yes it is deinterlace only, the combiner in the VDIC is not being used. Well, I don't really know if it would be possible to have it too, and how difficult it is. Maybe as a m2m device, as it could be driven by gstreamer for instance and would replace pure software composition element... I may need to take some time and look further into this, but if anyone has tested it, or can give me advices on how it should be done, it can help (a lot)... :). Thanks, JM -- 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: i.MX6 Video combiner
On 02/25/2015 11:40 AM, Jean-Michel Hautbois wrote: Hi Steve, 2015-02-25 18:54 GMT+01:00 Steve Longerbeam slongerb...@gmail.com: On 02/25/2015 09:37 AM, Steve Longerbeam wrote: On 02/25/2015 02:57 AM, Jean-Michel Hautbois wrote: Hi all, I read in the i.MX6 TRM that it can do combining or deinterlacing with VDIC. Has it been tested by anyone ? Could it be a driver, which would allow to do some simple compositing of souces ? Thanks, JM I've added VDIC support (deinterlace with motion compensation) to the capture driver, it's in the my media tree clone: g...@github.com:slongerbeam/mediatree.git, mx6-media-staging it is activated if user sets the motion compensation control to 1 (low motion), 2 (medium motion), or 3 (high motion), for example: # v4l2-ctl --set-ctrl=motion_compensation=2 Thx for the tip :). And in fact, it is only deinterlacing, not combining two planes with background as specified in the TRM (or did I miss something ?). Hi JM, yes it is deinterlace only, the combiner in the VDIC is not being used. Steve -- 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] rc-core: fix dib0700 scancode generation for RC5
David, could you please test this patch?
---
drivers/media/usb/dvb-usb/dib0700_core.c | 70 +-
1 file changed, 40 insertions(+), 30 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c
b/drivers/media/usb/dvb-usb/dib0700_core.c
index 50856db..605b090 100644
--- a/drivers/media/usb/dvb-usb/dib0700_core.c
+++ b/drivers/media/usb/dvb-usb/dib0700_core.c
@@ -658,10 +658,20 @@ out:
struct dib0700_rc_response {
u8 report_id;
u8 data_state;
- u8 system;
- u8 not_system;
- u8 data;
- u8 not_data;
+ union {
+ struct {
+ u8 system;
+ u8 not_system;
+ u8 data;
+ u8 not_data;
+ } nec;
+ struct {
+ u8 not_used;
+ u8 system;
+ u8 data;
+ u8 not_data;
+ } rc5;
+ };
};
#define RC_MSG_SIZE_V1_20 6
@@ -697,8 +707,8 @@ static void dib0700_rc_urb_completion(struct urb *purb)
deb_data(IR ID = %02X state = %02X System = %02X %02X Cmd = %02X %02X
(len %d)\n,
poll_reply-report_id, poll_reply-data_state,
-poll_reply-system, poll_reply-not_system,
-poll_reply-data, poll_reply-not_data,
+poll_reply-nec.system, poll_reply-nec.not_system,
+poll_reply-nec.data, poll_reply-nec.not_data,
purb-actual_length);
switch (d-props.rc.core.protocol) {
@@ -707,30 +717,30 @@ static void dib0700_rc_urb_completion(struct urb *purb)
toggle = 0;
/* NEC protocol sends repeat code as 0 0 0 FF */
- if (poll_reply-system == 0x00
- poll_reply-not_system == 0x00
- poll_reply-data == 0x00
- poll_reply-not_data == 0xff) {
+ if (poll_reply-nec.system == 0x00
+ poll_reply-nec.not_system == 0x00
+ poll_reply-nec.data == 0x00
+ poll_reply-nec.not_data == 0xff) {
poll_reply-data_state = 2;
break;
}
- if ((poll_reply-data ^ poll_reply-not_data) != 0xff) {
+ if ((poll_reply-nec.data ^ poll_reply-nec.not_data) != 0xff) {
deb_data(NEC32 protocol\n);
- keycode = RC_SCANCODE_NEC32(poll_reply-system
24 |
-poll_reply-not_system
16 |
-poll_reply-data
8 |
-poll_reply-not_data);
- } else if ((poll_reply-system ^ poll_reply-not_system) !=
0xff) {
+ keycode = RC_SCANCODE_NEC32(poll_reply-nec.system
24 |
+poll_reply-nec.not_system
16 |
+poll_reply-nec.data
8 |
+poll_reply-nec.not_data);
+ } else if ((poll_reply-nec.system ^
poll_reply-nec.not_system) != 0xff) {
deb_data(NEC extended protocol\n);
- keycode = RC_SCANCODE_NECX(poll_reply-system 8 |
- poll_reply-not_system,
- poll_reply-data);
+ keycode = RC_SCANCODE_NECX(poll_reply-nec.system 8 |
+ poll_reply-nec.not_system,
+ poll_reply-nec.data);
} else {
deb_data(NEC normal protocol\n);
- keycode = RC_SCANCODE_NEC(poll_reply-system,
- poll_reply-data);
+ keycode = RC_SCANCODE_NEC(poll_reply-nec.system,
+ poll_reply-nec.data);
}
break;
@@ -738,19 +748,19 @@ static void dib0700_rc_urb_completion(struct urb *purb)
deb_data(RC5 protocol\n);
protocol = RC_TYPE_RC5;
toggle = poll_reply-report_id;
- keycode = RC_SCANCODE_RC5(poll_reply-system, poll_reply-data);
+ keycode = RC_SCANCODE_RC5(poll_reply-rc5.system,
poll_reply-rc5.data);
+
+ if ((poll_reply-rc5.data ^ poll_reply-rc5.not_data) != 0xff) {
+ /* Key failed integrity check */
+ err(key failed integrity check: %02x %02x %02x %02x,
+ poll_reply-rc5.not_used, poll_reply-rc5.system,
+ poll_reply-rc5.data, poll_reply-rc5.not_data);
+
[PATCH] [media] saa7164: use an MSI interrupt when available
From: Brendan McGrath red...@redmandi.dyndns.org
[media] saa7164: use an MSI interrupt when available
Fixes a known crash which most commonly occurs when multiple saa7164
chips are in use.
Signed-off-by: Brendan McGrath red...@redmandi.dyndns.org
---
drivers/media/pci/saa7164/saa7164-core.c | 34
++--
drivers/media/pci/saa7164/saa7164.h | 1 +
2 files changed, 33 insertions(+), 2 deletions(-)
This patch falls back to the original code - a 'shared' interrupt - when
MSI is not available (or encounters an error).
Many of today's cards that use the saa7164 chip operate on a PCI-E bus
(thus MSI should be available). Examples: the Hauppage HVR-2200 and HVR-2250
This enhancement also fixes an issue that was causing the driver to crash:
http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/83948
I believe the root cause of the crash is due to a DMA/IRQ race
condition. It most commonly occurs when the saa7164 driver is dealing
with more than one saa7164 chip (the HVR-2200 and HVR-2250 for example
have two - one for each tuner). Given MSI avoids DMA/IRQ race conditions
- this would explain why the patch works as a fix.
diff --git a/drivers/media/pci/saa7164/saa7164-core.c
b/drivers/media/pci/saa7164/saa7164-core.c
index 4b0bec3..083bea4 100644
--- a/drivers/media/pci/saa7164/saa7164-core.c
+++ b/drivers/media/pci/saa7164/saa7164-core.c
@@ -1230,8 +1230,33 @@ static int saa7164_initdev(struct pci_dev *pci_dev,
goto fail_irq;
}
-err = request_irq(pci_dev-irq, saa7164_irq,
-IRQF_SHARED, dev-name, dev);
+/* irq bit */
+err = pci_enable_msi(pci_dev);
+
+if (!err) {
+/* no error - so request an msi interrupt */
+err = request_irq(pci_dev-irq, saa7164_irq, 0,
+ dev-name, dev);
+
+if (err) {
+/* fall back to legacy interrupt */
+printk(KERN_ERR %s() Failed to get an MSI interrupt.
+ Falling back to a shared IRQ\n, __func__);
+pci_disable_msi(pci_dev);
+} else {
+dev-msi = true;
+}
+}
+
+if (err) {
+dev-msi = false;
+/* if we have an error (i.e. we don't have an interrupt)
+ - fallback to legacy interrupt */
+
+err = request_irq(pci_dev-irq, saa7164_irq,
+IRQF_SHARED, dev-name, dev);
+}
+
if (err 0) {
printk(KERN_ERR %s: can't get IRQ %d\n, dev-name,
pci_dev-irq);
@@ -1441,6 +1466,11 @@ static void saa7164_finidev(struct pci_dev *pci_dev)
/* unregister stuff */
free_irq(pci_dev-irq, dev);
+if (dev-msi) {
+pci_disable_msi(pci_dev);
+dev-msi = false;
+}
+
mutex_lock(devlist);
list_del(dev-devlist);
mutex_unlock(devlist);
diff --git a/drivers/media/pci/saa7164/saa7164.h
b/drivers/media/pci/saa7164/saa7164.h
index cd1a07c..6df4b252 100644
--- a/drivers/media/pci/saa7164/saa7164.h
+++ b/drivers/media/pci/saa7164/saa7164.h
@@ -459,6 +459,7 @@ struct saa7164_dev {
/* Interrupt status and ack registers */
u32 int_status;
u32 int_ack;
+u32 msi;
struct cmdcmds[SAA_CMD_MAX_MSG_UNITS];
struct mutexlock;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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: Thu Feb 26 04:00:20 CET 2015 git branch: test git hash: 8a26a258bdb82db241cdc35f332f88dd67bdb9c9 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-41-g6c2d743 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.18.0-5.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: OK 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: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: 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: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-rc1-i686: 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: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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
Re: [PATCH v5 3/4] media: ov2640: add primary dt support
Hi Josh, On Wed, Feb 25, 2015 at 3:54 AM, Josh Wu josh...@atmel.com wrote: Hi, Prabhakar Lad On 2/17/2015 12:48 AM, Lad, Prabhakar wrote: Hi Josh, Thanks for the patch. On Tue, Feb 10, 2015 at 9:31 AM, Josh Wu josh...@atmel.com wrote: [Snip] - priv-clk = v4l2_clk_get(client-dev, mclk); + priv-clk = v4l2_clk_get(client-dev, xvclk); with this change don’t you need to update the board file using this driver/ the bridge driver ? I think no. First, my patch should be on top of the following two patches, which changed the *v4l2_clk_get()* behavior: [v3,1/2] V4L: remove clock name from v4l2_clk API https://patchwork.linuxtv.org/patch/28108/ [v4,2/2] V4L: add CCF support to the v4l2_clk API https://patchwork.linuxtv.org/patch/28111/ Thanks I missed the dependent patches. Cheers, --Prabhakar Lad -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] media: i2c: add support for omnivision's ov2659 sensor
Hi Prabhakar,
Lad, Prabhakar wrote:
...
+
+For further reading on port node refer to
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ i2c0@1c22000 {
+ ...
+ ...
+ ov2659@30 {
+ compatible = ovti,ov2659;
+ reg = 0x30;
+
+ clocks = clk_ov2659;
+ clock-names = xvclk;
+
+ assigned-clocks = clk_ov2659;
+ assigned-clock-rates = 1200;
These don't quite match with the documentation above.
These are the standard clock properties, which I thought could be ignored
for documenting ?
I think you still should say the device / driver needs or can use them.
+
+ port {
+ ov2659_0: endpoint {
+ remote-endpoint = vpfe_ep;
+ xvclk-frequency = 1200;
+ };
+ };
+ };
+ ...
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index becb274..1126c9e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8758,6 +8758,16 @@ T: git
git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git
S: Maintained
F: drivers/media/platform/am437x/
+OV2659 OMNIVISION SENSOR DRIVER
+M: Lad, Prabhakar prabhakar.cse...@gmail.com
+L: linux-media@vger.kernel.org
+W: http://linuxtv.org/
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+T: git git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git
+S: Maintained
+F: drivers/media/i2c/ov2659.c
+F: include/media/ov2659.h
+
SIS 190 ETHERNET DRIVER
M: Francois Romieu rom...@fr.zoreil.com
L: net...@vger.kernel.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index da58c9b..6f30ea7 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -466,6 +466,17 @@ config VIDEO_APTINA_PLL
config VIDEO_SMIAPP_PLL
tristate
+config VIDEO_OV2659
+ tristate OmniVision OV2659 sensor support
+ depends on VIDEO_V4L2 I2C
+ depends on MEDIA_CAMERA_SUPPORT
Please add VIDEO_V4L2_SUBDEV_API .
+ ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV2659 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov2659.
+
config VIDEO_OV7640
tristate OmniVision OV7640 sensor support
depends on I2C VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 98589001..f165fae 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -77,3 +77,4 @@ obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
obj-$(CONFIG_VIDEO_ML86V7667)+= ml86v7667.o
+obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
new file mode 100644
index 000..e79298b
--- /dev/null
+++ b/drivers/media/i2c/ov2659.c
...
+
+struct sensor_register {
+ u16 addr;
+ u8 value;
+};
+
+struct ov2659_framesize {
+ u16 width;
+ u16 height;
+ u16 max_exp_lines;
+ const struct sensor_register *regs;
+};
+
+struct ov2659_pll_ctrl {
+ u8 ctrl1;
+ u8 ctrl2;
+ u8 ctrl3;
+};
+
+struct ov2659_pixfmt {
+ u32 code;
+ u32 colorspace;
+ /* Output format Register Value (REG_FORMAT_CTRL00) */
+ struct sensor_register *format_ctrl_regs;
+};
+
+struct pll_ctrl_reg {
+ unsigned int div;
+ unsigned char reg;
+};
+
+struct ov2659 {
+ struct v4l2_subdev sd;
+ struct media_pad pad;
+ enum v4l2_mbus_type bus_type;
+ struct v4l2_mbus_framefmt format;
+ const struct ov2659_platform_data *pdata;
+ struct mutex lock;
+ struct i2c_client *client;
+ const struct ov2659_framesize *frame_size;
+ struct sensor_register *format_ctrl_regs;
+ struct ov2659_pll_ctrl pll;
+ int streaming;
+};
+
+static const struct sensor_register ov2659_init_regs[] = {
+ {0x3000, 0x03}, /* IO CTRL */
+ {0x3001, 0xff}, /* IO CTRL */
+ {0x3002, 0xe0}, /* IO CTRL */
+ {0x3633, 0x3d},
+ {0x3620, 0x02},
+ {0x3631, 0x11},
+ {0x3612, 0x04},
+ {0x3630, 0x20},
+ {0x4702, 0x02}, /* DVP Debug mode */
+ {0x370c, 0x34},
+ {0x3004, 0x10}, /* System Divider */
+ {0x3005, 0x22}, /* Pixel clock Multiplier */
Do these belong here?
+ {0x3800, 0x00}, /* TIMING */
+ {0x3801, 0x00}, /* TIMING */
+ {0x3802, 0x00}, /* TIMING */
+ {0x3803, 0x00}, /* TIMING */
+ {0x3804, 0x06}, /* TIMING */
+ {0x3805, 0x5f}, /* TIMING */
+ {0x3806, 0x04}, /* TIMING */
+ {0x3807, 0xb7}, /* TIMING */
+ {0x3808, 0x03}, /* Horizontal High Byte */
+ {0x3809,
Re: [PATCH v2] media: i2c: add support for omnivision's ov2659 sensor
Hi Sakari,
Thanks for the review.
On Thu, Feb 26, 2015 at 12:18 AM, Sakari Ailus sakari.ai...@iki.fi wrote:
Hi Prabhakar,
Lad, Prabhakar wrote:
...
+
+For further reading on port node refer to
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ i2c0@1c22000 {
+ ...
+ ...
+ ov2659@30 {
+ compatible = ovti,ov2659;
+ reg = 0x30;
+
+ clocks = clk_ov2659;
+ clock-names = xvclk;
+
+ assigned-clocks = clk_ov2659;
+ assigned-clock-rates = 1200;
These don't quite match with the documentation above.
These are the standard clock properties, which I thought could be ignored
for documenting ?
I think you still should say the device / driver needs or can use them.
OK
+
+ port {
+ ov2659_0: endpoint {
+ remote-endpoint = vpfe_ep;
+ xvclk-frequency = 1200;
+ };
+ };
+ };
+ ...
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index becb274..1126c9e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8758,6 +8758,16 @@ T: git
git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git
S: Maintained
F: drivers/media/platform/am437x/
+OV2659 OMNIVISION SENSOR DRIVER
+M: Lad, Prabhakar prabhakar.cse...@gmail.com
+L: linux-media@vger.kernel.org
+W: http://linuxtv.org/
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+T: git git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git
+S: Maintained
+F: drivers/media/i2c/ov2659.c
+F: include/media/ov2659.h
+
SIS 190 ETHERNET DRIVER
M: Francois Romieu rom...@fr.zoreil.com
L: net...@vger.kernel.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index da58c9b..6f30ea7 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -466,6 +466,17 @@ config VIDEO_APTINA_PLL
config VIDEO_SMIAPP_PLL
tristate
+config VIDEO_OV2659
+ tristate OmniVision OV2659 sensor support
+ depends on VIDEO_V4L2 I2C
+ depends on MEDIA_CAMERA_SUPPORT
Please add VIDEO_V4L2_SUBDEV_API .
OK
+ ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV2659 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov2659.
+
config VIDEO_OV7640
tristate OmniVision OV7640 sensor support
depends on I2C VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 98589001..f165fae 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -77,3 +77,4 @@ obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
obj-$(CONFIG_VIDEO_ML86V7667)+= ml86v7667.o
+obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
new file mode 100644
index 000..e79298b
--- /dev/null
+++ b/drivers/media/i2c/ov2659.c
...
+
+struct sensor_register {
+ u16 addr;
+ u8 value;
+};
+
+struct ov2659_framesize {
+ u16 width;
+ u16 height;
+ u16 max_exp_lines;
+ const struct sensor_register *regs;
+};
+
+struct ov2659_pll_ctrl {
+ u8 ctrl1;
+ u8 ctrl2;
+ u8 ctrl3;
+};
+
+struct ov2659_pixfmt {
+ u32 code;
+ u32 colorspace;
+ /* Output format Register Value (REG_FORMAT_CTRL00) */
+ struct sensor_register *format_ctrl_regs;
+};
+
+struct pll_ctrl_reg {
+ unsigned int div;
+ unsigned char reg;
+};
+
+struct ov2659 {
+ struct v4l2_subdev sd;
+ struct media_pad pad;
+ enum v4l2_mbus_type bus_type;
+ struct v4l2_mbus_framefmt format;
+ const struct ov2659_platform_data *pdata;
+ struct mutex lock;
+ struct i2c_client *client;
+ const struct ov2659_framesize *frame_size;
+ struct sensor_register *format_ctrl_regs;
+ struct ov2659_pll_ctrl pll;
+ int streaming;
+};
+
+static const struct sensor_register ov2659_init_regs[] = {
+ {0x3000, 0x03}, /* IO CTRL */
+ {0x3001, 0xff}, /* IO CTRL */
+ {0x3002, 0xe0}, /* IO CTRL */
+ {0x3633, 0x3d},
+ {0x3620, 0x02},
+ {0x3631, 0x11},
+ {0x3612, 0x04},
+ {0x3630, 0x20},
+ {0x4702, 0x02}, /* DVP Debug mode */
+ {0x370c, 0x34},
+ {0x3004, 0x10}, /* System Divider */
+ {0x3005, 0x22}, /* Pixel clock Multiplier */
Do these belong here?
+ {0x3800, 0x00}, /* TIMING */
+ {0x3801, 0x00}, /* TIMING */
+ {0x3802, 0x00}, /* TIMING */
+ {0x3803, 0x00}, /* TIMING */
+ {0x3804, 0x06}, /* TIMING */
+ {0x3805, 0x5f}, /* TIMING */
+ {0x3806,
[linuxtv-media:master 332/350] drivers/media/usb/cx231xx/cx231xx-cards.c:1553:15: error: 'struct v4l2_device' has no member named 'mdev'
Hi Mauro,
FYI, the error/warning still remains. You may either fix it or ask me to
silently ignore in future.
tree: git://linuxtv.org/media_tree.git master
head: 8a26a258bdb82db241cdc35f332f88dd67bdb9c9
commit: 1d058bdcf5cc800fbfeece0204f7774556d341bb [332/350] [media] cx231xx: add
media controller support
config: x86_64-rhel (attached as .config)
reproduce:
git checkout 1d058bdcf5cc800fbfeece0204f7774556d341bb
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings:
drivers/media/usb/cx231xx/cx231xx-cards.c: In function 'cx231xx_usb_probe':
drivers/media/usb/cx231xx/cx231xx-cards.c:1553:15: error: 'struct
v4l2_device' has no member named 'mdev'
dev-v4l2_dev.mdev = dev-media_dev;
^
drivers/media/usb/cx231xx/cx231xx-cards.c:1553:26: error: 'struct cx231xx'
has no member named 'media_dev'
dev-v4l2_dev.mdev = dev-media_dev;
^
vim +1553 drivers/media/usb/cx231xx/cx231xx-cards.c
1547 usb_set_intfdata(interface, dev);
1548
1549 /* Register the media controller */
1550 cx231xx_media_device_register(dev, udev);
1551
1552 /* Create v4l2 device */
1553 dev-v4l2_dev.mdev = dev-media_dev;
1554 retval = v4l2_device_register(interface-dev, dev-v4l2_dev);
1555 if (retval) {
1556 dev_err(d, v4l2_device_register failed\n);
---
0-DAY kernel test infrastructureOpen Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.19.0-rc6 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT=elf64-x86-64
CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10
-fcall-saved-r11
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME=(none)
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_GENERIC_MSI_IRQ=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
# CONFIG_NO_HZ_IDLE is not set
CONFIG_NO_HZ_FULL=y
# CONFIG_NO_HZ_FULL_ALL is not set
# CONFIG_NO_HZ_FULL_SYSIDLE is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
#
# RCU Subsystem
#
[linuxtv-media:master 338/350] drivers/media/v4l2-core/tuner-core.c:440:7: error: 'struct v4l2_subdev' has no member named 'entity'
Hi Mauro,
FYI, the error/warning still remains. You may either fix it or ask me to
silently ignore in future.
tree: git://linuxtv.org/media_tree.git master
head: 8a26a258bdb82db241cdc35f332f88dd67bdb9c9
commit: 00a5a4bf7bb40fe8cd5de042948b925c54b016de [338/350] [media] tuner-core:
properly initialize media controller subdev
config: x86_64-rhel (attached as .config)
reproduce:
git checkout 00a5a4bf7bb40fe8cd5de042948b925c54b016de
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings:
drivers/media/v4l2-core/tuner-core.c: In function 'set_type':
drivers/media/v4l2-core/tuner-core.c:440:7: error: 'struct v4l2_subdev' has
no member named 'entity'
t-sd.entity.name = t-name;
^
vim +440 drivers/media/v4l2-core/tuner-core.c
434 analog_ops-get_afc = fe_tuner_ops-get_afc;
435
436 } else {
437 t-name = analog_ops-info.name;
438 }
439
440 t-sd.entity.name = t-name;
441
442 tuner_dbg(type set to %s\n, t-name);
443
---
0-DAY kernel test infrastructureOpen Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.19.0-rc6 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT=elf64-x86-64
CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10
-fcall-saved-r11
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME=(none)
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_GENERIC_MSI_IRQ=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
# CONFIG_NO_HZ_IDLE is not set
CONFIG_NO_HZ_FULL=y
# CONFIG_NO_HZ_FULL_ALL is not set
# CONFIG_NO_HZ_FULL_SYSIDLE is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
CONFIG_CONTEXT_TRACKING=y
CONFIG_RCU_USER_QS=y
# CONFIG_CONTEXT_TRACKING_FORCE is not set
CONFIG_RCU_FANOUT=64
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_RCU_FAST_NO_HZ is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_NOCB_CPU=y
#
RE: 0001-media-vb2-Fill-vb2_buffer-with-bytesused-from-user.patch; kernel version 3.10.69
Hello Jeremiah,
Please find the patch inline
commit 3390900680e5182998916c8fa231bc79cd84046b
Author: Sudip Jain sudip.j...@st.com
Date: Thu Feb 26 10:40:34 2015 +0530
media: vb2: Fill vb2_buffer with bytesused from user
In vb2_qbuf for dmabuf memory type, userside bytesused is not read to
vb2 buffer. This leads garbage value being copied from __qbuf_dmabuf()
back to user in __fill_v4l2_buffer().
As a default case, the vb2 framework must trust the userside value,
and also allow driver's buffer prepare function prefer modify/update
or not to.
Applied on kernel version 3.10.69
Change-Id: Ieda389403898935f59c2e2994106f3e5238cfefd
Signed-off-by: Sudip Jain sudip.j...@st.com
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 5e47ba4..54fe9c9 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -919,6 +919,8 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const
struct v4l2_buffer *b
b-m.planes[plane].m.fd;
v4l2_planes[plane].length =
b-m.planes[plane].length;
+ v4l2_planes[plane].bytesused =
+ b-m.planes[plane].bytesused;
v4l2_planes[plane].data_offset =
b-m.planes[plane].data_offset;
}
@@ -943,6 +945,7 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const
struct v4l2_buffer *b
if (b-memory == V4L2_MEMORY_DMABUF) {
v4l2_planes[0].m.fd = b-m.fd;
v4l2_planes[0].length = b-length;
+ v4l2_planes[0].bytesused = b-bytesused;
v4l2_planes[0].data_offset = 0;
}
Thanks,
Sudip
From: Jeremiah Mahler [jmmah...@gmail.com]
Sent: Wednesday, February 25, 2015 11:53 PM
To: Sudip JAIN
Cc: linux-media@vger.kernel.org; linux-ker...@vger.kernel.org
Subject: Re: 0001-media-vb2-Fill-vb2_buffer-with-bytesused-from-user.patch
Sudip,
On Wed, Feb 25, 2015 at 03:29:22PM +0800, Sudip JAIN wrote:
Dear Maintainer,
PFA attached patch that prevents user from being returned garbage bytesused
value from vb2 framework.
Regards,
Sudip Jain
Patches should never be submitted as attachments, they should be inline.
See Documentation/SubmittingPatches for more info.
[...]
--
- Jeremiah Mahler
--
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
i.MX6 Video combiner
Hi all, I read in the i.MX6 TRM that it can do combining or deinterlacing with VDIC. Has it been tested by anyone ? Could it be a driver, which would allow to do some simple compositing of souces ? Thanks, JM -- 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
