Re: [PATCH/RFC v3 5/5] media: Add registration helpers for V4L2 flash sub-devices
Hi Sakari,
On 05/07/2014 09:58 AM, Sakari Ailus wrote:
Hi Jacek,
On Wed, May 07, 2014 at 09:20:17AM +0200, Jacek Anaszewski wrote:
On 05/06/2014 11:10 AM, Sakari Ailus wrote:
Hi Jacek,
On Tue, May 06, 2014 at 08:44:41AM +0200, Jacek Anaszewski wrote:
Hi Sakari,
On 05/02/2014 01:06 PM, Sakari Ailus wrote:
[...]
+static inline enum led_brightness v4l2_flash_intensity_to_led_brightness(
+ struct led_ctrl *config,
+ u32 intensity)
Fits on a single line.
+{
+ return intensity / config-step;
Shouldn't you first decrement the minimum before the division?
Brightness level 0 means that led is off. Let's consider following case:
intensity - 15625
config-step - 15625
intensity / config-step = 1 (the lowest possible current level)
In V4L2 controls the minimum is not off, and zero might not be a possible
value since minimum isn't divisible by step.
I wonder how to best take that into account.
I've assumed that in MODE_TORCH a led is always on. Switching
the mode to MODE_FLASH or MODE_OFF turns the led off.
This way we avoid the problem with converting 0 uA value to
led_brightness, as available torch brightness levels start from
the minimum current level value and turning the led off is
accomplished on transition to MODE_OFF or MODE_FLASH, by
calling brightness_set op with led_brightness = 0.
I'm not sure if we understood the issue the same way. My concern was that if
the intensity isn't a multiple of step (but intensity - min is), the above
formula won't return a valid result (unless I miss something).
Please note that v4l2_flash_intensity_to_led_brightness is called only
from s_ctrl callback, and thus it expects to get the intensity aligned
to the step value, so it will always be a multiple of step.
Is it possible that s_ctrl callback would be passed a non-aligned
control value?
In a nutshell: value - min is aligned but value is not. Please see
validate_new() in drivers/media/v4l2-core/v4l2-ctrls.c .
Still, to my mind, value is aligned.
Below I execute the calculation steps one by one
according to the V4L2_CTRL_TYPE_INTEGER case in the
validate_new function:
c-value = 35000
val = c-value + step / 2; // 35000 + 15625 / 2 = 42812
val = clamp(val, min, max); // val = 42812
offset = val - min; // 42812 - 15625 = 27187
offset = step * (offset / step); // 15625 * (27187 / 15625) = 15625
c-value = min + offset; // 15625 + 15625 = 31250
Value is aligned to the nearest step.
Please spot any discrepancies in my way of thinking if there
are any :)
min is aligned to step above. This is not necessarily the case. And if min
is not aligned, neither is value.
Thanks for spotting this. Below are improved versions of the conversion
functions. Please let me know if you have any comments.
static inline
enum led_brightnessv4l2_flash_intensity_to_led_brightness(
struct led_ctrl *config,
u32 intensity)
{
return ((intensity - config-min) / config-step) + 1;
}
static inline
u32 v4l2_flash_led_brightness_to_intensity(
struct led_ctrl *config,
enum led_brightness brightness)
{
return ((brightness - 1) * config-step) + config-min;
}
Regards,
Jacek Anaszewski
--
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] Fix _IOC_TYPECHECK sparse error
Andrew, can you merge this for 3.15 or 3.16 (you decide)? While it fixes a sparse error for the media subsystem, it is not really appropriate to go through our media tree. Thanks, Hans When running sparse over drivers/media/v4l2-core/v4l2-ioctl.c I get these errors: drivers/media/v4l2-core/v4l2-ioctl.c:2043:9: error: bad integer constant expression drivers/media/v4l2-core/v4l2-ioctl.c:2044:9: error: bad integer constant expression drivers/media/v4l2-core/v4l2-ioctl.c:2045:9: error: bad integer constant expression drivers/media/v4l2-core/v4l2-ioctl.c:2046:9: error: bad integer constant expression etc. The root cause of that turns out to be in include/asm-generic/ioctl.h: #include uapi/asm-generic/ioctl.h /* provoke compile error for invalid uses of size argument */ extern unsigned int __invalid_size_argument_for_IOC; #define _IOC_TYPECHECK(t) \ ((sizeof(t) == sizeof(t[1]) \ sizeof(t) (1 _IOC_SIZEBITS)) ? \ sizeof(t) : __invalid_size_argument_for_IOC) If it is defined as this (as is already done if __KERNEL__ is not defined): #define _IOC_TYPECHECK(t) (sizeof(t)) then all is well with the world. This patch allows sparse to work correctly. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Reviewed-by: Josh Triplett j...@joshtriplett.org --- include/asm-generic/ioctl.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/asm-generic/ioctl.h b/include/asm-generic/ioctl.h index d17295b..297fb0d 100644 --- a/include/asm-generic/ioctl.h +++ b/include/asm-generic/ioctl.h @@ -3,10 +3,15 @@ #include uapi/asm-generic/ioctl.h +#ifdef __CHECKER__ +#define _IOC_TYPECHECK(t) (sizeof(t)) +#else /* provoke compile error for invalid uses of size argument */ extern unsigned int __invalid_size_argument_for_IOC; #define _IOC_TYPECHECK(t) \ ((sizeof(t) == sizeof(t[1]) \ sizeof(t) (1 _IOC_SIZEBITS)) ? \ sizeof(t) : __invalid_size_argument_for_IOC) +#endif + #endif /* _ASM_GENERIC_IOCTL_H */ -- 2.0.0.rc0 -- 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] au0828: Cancel stream-restart operation if frontend is disconnected
Em Fri, 09 May 2014 12:54:11 +0800 Changbing xi...@pop3.w2.samsung.net escreveu: From: Changbing Xiong cb.xi...@samsung.com If the tuner is already disconnected, It is meaningless to go on doing the stream-restart operation, It is better to cancel this operation. Signed-off-by: Changbing Xiong cb.xi...@samsung.com --- drivers/media/usb/au0828/au0828-dvb.c |2 ++ 1 file changed, 2 insertions(+) mode change 100644 = 100755 drivers/media/usb/au0828/au0828-dvb.c diff --git a/drivers/media/usb/au0828/au0828-dvb.c b/drivers/media/usb/au0828/au0828-dvb.c old mode 100644 new mode 100755 index 9a6f156..fd8e798 --- a/drivers/media/usb/au0828/au0828-dvb.c +++ b/drivers/media/usb/au0828/au0828-dvb.c @@ -403,6 +403,8 @@ void au0828_dvb_unregister(struct au0828_dev *dev) if (dvb-frontend == NULL) return; + cancel_work_sync(dev-restart_streaming); + dvb_net_release(dvb-net); dvb-demux.dmx.remove_frontend(dvb-demux.dmx, dvb-fe_mem); dvb-demux.dmx.remove_frontend(dvb-demux.dmx, dvb-fe_hw); Seems ok on my eyes. Btw, I think we should also call cancel_work_sync() on other places. On some tests I did with this frontend last week, things sometimes get badly when switching from one channel to another one, or doing channel scan. This thread could be the culprit. Unfortunately, I can't test it ATM, as I'm in a business trip this week. Anyway, from a theoretical perspective, it seems logical that call cancel_work_sync() should also be called when: - stop_urb_transfer() is called; - when a new tuning starts. For the second one, the patch should be somewhat similar to what cx23885_set_frontend_hook() does, e. g. hooking the fe-ops.set_frontend, in order to call cancel_work_sync() before setting the frontend parameters for the next frequency to zap. Due to the DVB zigzag algorithm, I suspect that this could even improve channel scanning. Devin, What do you think? Thanks, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] em28xx: fix i2c_set_adapdata() call in em28xx_i2c_register()
Hi Frank,
I've got a comment about this patch:
On 03/22/2014 02:01 PM, Frank Schäfer wrote:
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index ba6433c..04e8577 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -939,7 +939,7 @@ int em28xx_i2c_register(struct em28xx *dev, unsigned bus,
dev-i2c_bus[bus].algo_type = algo_type;
dev-i2c_bus[bus].dev = dev;
dev-i2c_adap[bus].algo_data = dev-i2c_bus[bus];
- i2c_set_adapdata(dev-i2c_adap[bus], dev-v4l2_dev);
+ i2c_set_adapdata(dev-i2c_adap[bus], dev);
As far as I can see nobody is calling i2c_get_adapdata. Should this line be
removed
altogether?
If it is used somewhere, can you point me that?
I'm taking the other patches from this series (using the v2 version of patch
4/5) since
those look fine.
Regards,
Hans
retval = i2c_add_adapter(dev-i2c_adap[bus]);
if (retval 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: [PATCH 00/19] em28xx: clean up the main device struct and move sub-module specific data to its own data structs
Hi Frank, This looks good to me. I do have some comments for future cleanups and I'll reply to the relevant patches for that. However, before I can apply this patch series you need to take a look at my comments for this pre-requisite patch: https://patchwork.linuxtv.org/patch/23179/ That needs to be sorted before I can apply this series. Regards, Hans On 03/24/2014 08:33 PM, Frank Schäfer wrote: This patch series cleans up the main device struct of the em28xx driver. Most of the patches (patches 3-16) are about moving the em28xx-v4l specific data to it's own dynamically allocated data structure. Patch 19 moves two em28xx-alsa specific fields to the em28xx_audio struct. Patches 17 and 18 remove two fields which aren't needed. Frank Schäfer (19): em28xx: move sub-module data structs to a common place in the main struct em28xx-video: simplify usage of the pointer to struct v4l2_ctrl_handler in em28xx_v4l2_init() em28xx: start moving em28xx-v4l specific data to its own struct em28xx: move struct v4l2_ctrl_handler ctrl_handler from struct em28xx to struct v4l2 em28xx: move struct v4l2_clk *clk from struct em28xx to struct v4l2 em28xx: move video_device structs from struct em28xx to struct v4l2 em28xx: move videobuf2 related data from struct em28xx to struct v4l2 em28xx: move v4l2 frame resolutions and scale data from struct em28xx to struct v4l2 em28xx: move vinmode and vinctrl data from struct em28xx to struct v4l2 em28xx: move TV norm from struct em28xx to struct v4l2 em28xx: move struct em28xx_fmt *format from struct em28xx to struct v4l2 em28xx: move progressive/interlaced fields from struct em28xx to struct v4l2 em28xx: move sensor parameter fields from struct em28xx to struct v4l2 em28xx: move capture state tracking fields from struct em28xx to struct v4l2 em28xx: move v4l2 user counting fields from struct em28xx to struct v4l2 em28xx: move tuner frequency field from struct em28xx to struct v4l2 em28xx: remove field tda9887_conf from struct em28xx em28xx: remove field tuner_addr from struct em28xx em28xx: move fields wq_trigger and streaming_started from struct em28xx to struct em28xx_audio drivers/media/usb/em28xx/em28xx-audio.c | 39 +- drivers/media/usb/em28xx/em28xx-camera.c | 51 +-- drivers/media/usb/em28xx/em28xx-cards.c | 9 - drivers/media/usb/em28xx/em28xx-vbi.c| 10 +- drivers/media/usb/em28xx/em28xx-video.c | 592 +-- drivers/media/usb/em28xx/em28xx.h| 120 --- 6 files changed, 452 insertions(+), 369 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: [PATCH 03/19] em28xx: start moving em28xx-v4l specific data to its own struct
Some comments for future improvements:
On 03/24/2014 08:33 PM, Frank Schäfer wrote:
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-camera.c | 4 +-
drivers/media/usb/em28xx/em28xx-video.c | 160
+--
drivers/media/usb/em28xx/em28xx.h| 8 +-
3 files changed, 116 insertions(+), 56 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-camera.c
b/drivers/media/usb/em28xx/em28xx-camera.c
index 505e050..daebef3 100644
--- a/drivers/media/usb/em28xx/em28xx-camera.c
+++ b/drivers/media/usb/em28xx/em28xx-camera.c
@@ -365,7 +365,7 @@ int em28xx_init_camera(struct em28xx *dev)
dev-sensor_xtal = 430;
pdata.xtal = dev-sensor_xtal;
if (NULL ==
- v4l2_i2c_new_subdev_board(dev-v4l2_dev, adap,
+ v4l2_i2c_new_subdev_board(dev-v4l2-v4l2_dev, adap,
mt9v011_info, NULL)) {
ret = -ENODEV;
break;
@@ -422,7 +422,7 @@ int em28xx_init_camera(struct em28xx *dev)
dev-sensor_yres = 480;
subdev =
- v4l2_i2c_new_subdev_board(dev-v4l2_dev, adap,
+ v4l2_i2c_new_subdev_board(dev-v4l2-v4l2_dev, adap,
ov2640_info, NULL);
if (NULL == subdev) {
ret = -ENODEV;
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index 45ad471..89947db 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -189,10 +189,11 @@ static int em28xx_vbi_supported(struct em28xx *dev)
*/
static void em28xx_wake_i2c(struct em28xx *dev)
{
- v4l2_device_call_all(dev-v4l2_dev, 0, core, reset, 0);
- v4l2_device_call_all(dev-v4l2_dev, 0, video, s_routing,
+ struct v4l2_device *v4l2_dev = dev-v4l2-v4l2_dev;
+ v4l2_device_call_all(v4l2_dev, 0, core, reset, 0);
+ v4l2_device_call_all(v4l2_dev, 0, video, s_routing,
INPUT(dev-ctl_input)-vmux, 0, 0);
- v4l2_device_call_all(dev-v4l2_dev, 0, video, s_stream, 0);
+ v4l2_device_call_all(v4l2_dev, 0, video, s_stream, 0);
}
static int em28xx_colorlevels_set_default(struct em28xx *dev)
@@ -952,7 +953,8 @@ int em28xx_start_analog_streaming(struct vb2_queue *vq,
unsigned int count)
f.type = V4L2_TUNER_RADIO;
else
f.type = V4L2_TUNER_ANALOG_TV;
- v4l2_device_call_all(dev-v4l2_dev, 0, tuner, s_frequency, f);
+ v4l2_device_call_all(dev-v4l2-v4l2_dev,
+ 0, tuner, s_frequency, f);
}
dev-streaming_users++;
@@ -1083,6 +1085,7 @@ static int em28xx_vb2_setup(struct em28xx *dev)
static void video_mux(struct em28xx *dev, int index)
{
+ struct v4l2_device *v4l2_dev = dev-v4l2-v4l2_dev;
dev-ctl_input = index;
dev-ctl_ainput = INPUT(index)-amux;
dev-ctl_aoutput = INPUT(index)-aout;
@@ -1090,21 +1093,21 @@ static void video_mux(struct em28xx *dev, int index)
if (!dev-ctl_aoutput)
dev-ctl_aoutput = EM28XX_AOUT_MASTER;
- v4l2_device_call_all(dev-v4l2_dev, 0, video, s_routing,
+ v4l2_device_call_all(v4l2_dev, 0, video, s_routing,
INPUT(index)-vmux, 0, 0);
if (dev-board.has_msp34xx) {
if (dev-i2s_speed) {
- v4l2_device_call_all(dev-v4l2_dev, 0, audio,
+ v4l2_device_call_all(v4l2_dev, 0, audio,
s_i2s_clock_freq, dev-i2s_speed);
}
/* Note: this is msp3400 specific */
- v4l2_device_call_all(dev-v4l2_dev, 0, audio, s_routing,
+ v4l2_device_call_all(v4l2_dev, 0, audio, s_routing,
dev-ctl_ainput, MSP_OUTPUT(MSP_SC_IN_DSP_SCART1), 0);
}
if (dev-board.adecoder != EM28XX_NOADECODER) {
- v4l2_device_call_all(dev-v4l2_dev, 0, audio, s_routing,
+ v4l2_device_call_all(v4l2_dev, 0, audio, s_routing,
dev-ctl_ainput, dev-ctl_aoutput, 0);
}
@@ -1344,7 +1347,7 @@ static int vidioc_querystd(struct file *file, void
*priv, v4l2_std_id *norm)
struct em28xx_fh *fh = priv;
struct em28xx *dev = fh-dev;
- v4l2_device_call_all(dev-v4l2_dev, 0, video, querystd, norm);
+ v4l2_device_call_all(dev-v4l2-v4l2_dev, 0, video, querystd, norm);
return 0;
}
@@ -1374,7 +1377,7 @@ static int vidioc_s_std(struct file *file, void *priv,
v4l2_std_id norm)
size_to_scale(dev, dev-width, dev-height, dev-hscale, dev-vscale);
em28xx_resolution_set(dev);
- v4l2_device_call_all(dev-v4l2_dev, 0, core, s_std, dev-norm);
+
Re: [PATCH] au0828: Cancel stream-restart operation if frontend is disconnected
Em Fri, 09 May 2014 05:12:53 -0300
Mauro Carvalho Chehab m.che...@samsung.com escreveu:
Em Fri, 09 May 2014 12:54:11 +0800
Changbing xi...@pop3.w2.samsung.net escreveu:
From: Changbing Xiong cb.xi...@samsung.com
If the tuner is already disconnected, It is meaningless to go on doing the
stream-restart operation, It is better to cancel this operation.
Signed-off-by: Changbing Xiong cb.xi...@samsung.com
---
drivers/media/usb/au0828/au0828-dvb.c |2 ++
1 file changed, 2 insertions(+)
mode change 100644 = 100755 drivers/media/usb/au0828/au0828-dvb.c
diff --git a/drivers/media/usb/au0828/au0828-dvb.c
b/drivers/media/usb/au0828/au0828-dvb.c
old mode 100644
new mode 100755
index 9a6f156..fd8e798
--- a/drivers/media/usb/au0828/au0828-dvb.c
+++ b/drivers/media/usb/au0828/au0828-dvb.c
@@ -403,6 +403,8 @@ void au0828_dvb_unregister(struct au0828_dev *dev)
if (dvb-frontend == NULL)
return;
+ cancel_work_sync(dev-restart_streaming);
+
dvb_net_release(dvb-net);
dvb-demux.dmx.remove_frontend(dvb-demux.dmx, dvb-fe_mem);
dvb-demux.dmx.remove_frontend(dvb-demux.dmx, dvb-fe_hw);
Seems ok on my eyes.
Btw, I think we should also call cancel_work_sync() on other
places. On some tests I did with this frontend last week, things
sometimes get badly when switching from one channel to another one,
or doing channel scan.
This thread could be the culprit. Unfortunately, I can't test it
ATM, as I'm in a business trip this week.
Anyway, from a theoretical perspective, it seems logical that
call cancel_work_sync() should also be called when:
- stop_urb_transfer() is called;
Hmm... we can't call it there, as the thread calls stop_urb_transfer.
Yet, IMHO, it makes sense to add it at au0828_dvb_stop_feed() and on
other places where stop_urb_transfer is called.
- when a new tuning starts.
For the second one, the patch should be somewhat similar to what
cx23885_set_frontend_hook() does, e. g. hooking the
fe-ops.set_frontend, in order to call cancel_work_sync() before setting
the frontend parameters for the next frequency to zap. Due to the
DVB zigzag algorithm, I suspect that this could even improve channel
scanning.
Devin,
What do you think?
On a second thought, maybe au0828_restart_dvb_streaming() should
be called every time fe-ops.set_frontend() is called, as it seems
likely that the misalignment condition that the changeset
43f2cccfc81c0af719a425ea816ce8003bb09748 fixes is actually caused
by not resetting the stream before tuning into a new frequency.
In other words, I think that an approach like the (untested) patch
below could improve tuning with this device.
Unfortunately, I can't test it during this week, as I'm in the middle of
a trip, without this device.
Regards,
Mauro
[PATCH] Reset au0828 streaming when a new frequency is set
Sometimes, when changing channels with au0828 causes it to fail.
Also, sometimes a channel is not properly tuned. I suspect that this is
caused by the DVB core zigzag logic that doesn't know about the scheduled
work to restart streaming when the MPEG TS gets misaligned.
The fix seems to be to cancel the restart_streaming scheduled task
and to stop/start the stream every time a new channel is set, e. g.
every time fe-ops.set_frontend() is called.
This patch is compile-tested only.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
diff --git a/drivers/media/usb/au0828/au0828-dvb.c
b/drivers/media/usb/au0828/au0828-dvb.c
index 4ae8b1074649..c5b5331c85a7 100644
--- a/drivers/media/usb/au0828/au0828-dvb.c
+++ b/drivers/media/usb/au0828/au0828-dvb.c
@@ -338,6 +338,32 @@ static void au0828_restart_dvb_streaming(struct
work_struct *work)
mutex_unlock(dvb-lock);
}
+static int au0828_set_frontend(struct dvb_frontend *fe)
+{
+ struct au0828_dev *dev = fe-dvb-priv;
+ struct au0828_dvb *dvb = dev-dvb;
+ int ret, was_streaming;
+
+ mutex_lock(dvb-lock);
+
+ was_streaming = dev-urb_streaming;
+ if (was_streaming) {
+ stop_urb_transfer(dev);
+ cancel_work_sync(dev-restart_streaming);
+ }
+ au0828_stop_transport(dev, 1);
+
+ ret = dvb-set_frontend(fe);
+
+ au0828_start_transport(dev);
+ if (was_streaming)
+ start_urb_transfer(dev);
+
+ mutex_unlock(dvb-lock);
+
+ return ret;
+}
+
static int dvb_register(struct au0828_dev *dev)
{
struct au0828_dvb *dvb = dev-dvb;
@@ -382,6 +408,10 @@ static int dvb_register(struct au0828_dev *dev)
goto fail_frontend;
}
+ /* Hook dvb frontend */
+dvb-set_frontend = dvb-frontend-ops.set_frontend;
+dvb-frontend-ops.set_frontend = au0828_set_frontend;
+
/* register demux stuff */
dvb-demux.dmx.capabilities =
DMX_TS_FILTERING | DMX_SECTION_FILTERING |
diff --git a/drivers/media/usb/au0828/au0828.h
Re: [PATCH 06/19] em28xx: move video_device structs from struct em28xx to struct v4l2
On 03/24/2014 08:33 PM, Frank Schäfer wrote:
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-video.c | 120
++--
drivers/media/usb/em28xx/em28xx.h | 7 +-
2 files changed, 56 insertions(+), 71 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index 4fb0053..7252eef 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -1447,7 +1447,7 @@ static int vidioc_enum_input(struct file *file, void
*priv,
(EM28XX_VMUX_CABLE == INPUT(n)-type))
i-type = V4L2_INPUT_TYPE_TUNER;
- i-std = dev-vdev-tvnorms;
+ i-std = dev-v4l2-vdev-tvnorms;
/* webcams do not have the STD API */
if (dev-board.is_webcam)
i-capabilities = 0;
@@ -1691,9 +1691,10 @@ static int vidioc_s_register(struct file *file, void
*priv,
static int vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *cap)
{
- struct video_device *vdev = video_devdata(file);
- struct em28xx_fh *fh = priv;
- struct em28xx *dev = fh-dev;
+ struct video_device *vdev = video_devdata(file);
+ struct em28xx_fh *fh = priv;
+ struct em28xx *dev = fh-dev;
+ struct em28xx_v4l2*v4l2 = dev-v4l2;
strlcpy(cap-driver, em28xx, sizeof(cap-driver));
strlcpy(cap-card, em28xx_boards[dev-model].name, sizeof(cap-card));
@@ -1715,9 +1716,9 @@ static int vidioc_querycap(struct file *file, void
*priv,
cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS |
V4L2_CAP_READWRITE | V4L2_CAP_VIDEO_CAPTURE |
V4L2_CAP_STREAMING;
- if (dev-vbi_dev)
+ if (v4l2-vbi_dev)
cap-capabilities |= V4L2_CAP_VBI_CAPTURE;
- if (dev-radio_dev)
+ if (v4l2-radio_dev)
cap-capabilities |= V4L2_CAP_RADIO;
return 0;
}
@@ -1955,20 +1956,20 @@ static int em28xx_v4l2_fini(struct em28xx *dev)
em28xx_uninit_usb_xfer(dev, EM28XX_ANALOG_MODE);
- if (dev-radio_dev) {
+ if (v4l2-radio_dev) {
em28xx_info(V4L2 device %s deregistered\n,
- video_device_node_name(dev-radio_dev));
- video_unregister_device(dev-radio_dev);
+ video_device_node_name(v4l2-radio_dev));
+ video_unregister_device(v4l2-radio_dev);
}
- if (dev-vbi_dev) {
+ if (v4l2-vbi_dev) {
em28xx_info(V4L2 device %s deregistered\n,
- video_device_node_name(dev-vbi_dev));
- video_unregister_device(dev-vbi_dev);
+ video_device_node_name(v4l2-vbi_dev));
+ video_unregister_device(v4l2-vbi_dev);
}
- if (dev-vdev) {
+ if (v4l2-vdev) {
em28xx_info(V4L2 device %s deregistered\n,
- video_device_node_name(dev-vdev));
- video_unregister_device(dev-vdev);
+ video_device_node_name(v4l2-vdev));
+ video_unregister_device(v4l2-vdev);
}
v4l2_ctrl_handler_free(v4l2-ctrl_handler);
@@ -2061,23 +2062,6 @@ exit:
return 0;
}
-/*
- * em28xx_videodevice_release()
- * called when the last user of the video device exits and frees the memeory
- */
-static void em28xx_videodevice_release(struct video_device *vdev)
-{
- struct em28xx *dev = video_get_drvdata(vdev);
-
- video_device_release(vdev);
- if (vdev == dev-vdev)
- dev-vdev = NULL;
- else if (vdev == dev-vbi_dev)
- dev-vbi_dev = NULL;
- else if (vdev == dev-radio_dev)
- dev-radio_dev = NULL;
-}
-
static const struct v4l2_file_operations em28xx_v4l_fops = {
.owner = THIS_MODULE,
.open = em28xx_v4l2_open,
@@ -2134,7 +2118,7 @@ static const struct v4l2_ioctl_ops video_ioctl_ops = {
static const struct video_device em28xx_video_template = {
.fops = em28xx_v4l_fops,
.ioctl_ops = video_ioctl_ops,
- .release= em28xx_videodevice_release,
+ .release= video_device_release,
.tvnorms= V4L2_STD_ALL,
};
@@ -2163,7 +2147,7 @@ static const struct v4l2_ioctl_ops radio_ioctl_ops = {
static struct video_device em28xx_radio_template = {
.fops = radio_fops,
.ioctl_ops = radio_ioctl_ops,
- .release= em28xx_videodevice_release,
+ .release= video_device_release,
};
/* I2C possible address to saa7115, tvp5150, msp3400, tvaudio */
@@ -2493,36 +2477,36 @@ static int em28xx_v4l2_init(struct em28xx *dev)
goto unregister_dev;
/* allocate and fill video video_device struct */
- dev-vdev = em28xx_vdev_init(dev, em28xx_video_template,
Re: [PATCH] [media] ivtv: avoid GFP_KERNEL in atomic context
On 04/25/2014 06:14 PM, Alexey Khoroshilov wrote:
ivtv_yuv_init() is used in atomic context,
so memory allocation should be done keeping that in mind.
Call graph for ivtv_yuv_init() is as follows:
- ivtv_yuv_next_free()
- ivtv_yuv_prep_frame() [ioctl handler]
- ivtv_yuv_setup_stream_frame()
- ivtv_irq_dec_data_req() - ivtv_irq_handler() [ATOMIC CONTEXT]
- ivtv_yuv_udma_stream_frame() [with mutex held]
- ivtv_write() [with mutex held]
The patch adds gfp_t argument and implements its usage according to the
context.
Found by Linux Driver Verification project (linuxtesting.org).
I am hesitant to take this patch. I'm fairly certain that the call from the irq
handler
will never have to allocate memory (it will always be allocated already) so is
this
patch really needed? On the other hand, it certainly won't break anything.
Andy, what is your opinion on this?
Regards,
Hans
Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
---
drivers/media/pci/ivtv/ivtv-fileops.c | 2 +-
drivers/media/pci/ivtv/ivtv-irq.c | 2 +-
drivers/media/pci/ivtv/ivtv-yuv.c | 16
drivers/media/pci/ivtv/ivtv-yuv.h | 2 +-
4 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/media/pci/ivtv/ivtv-fileops.c
b/drivers/media/pci/ivtv/ivtv-fileops.c
index 9caffd8aa995..2e8885c245e7 100644
--- a/drivers/media/pci/ivtv/ivtv-fileops.c
+++ b/drivers/media/pci/ivtv/ivtv-fileops.c
@@ -689,7 +689,7 @@ retry:
int got_sig;
if (mode == OUT_YUV)
- ivtv_yuv_setup_stream_frame(itv);
+ ivtv_yuv_setup_stream_frame(itv, GFP_KERNEL);
mutex_unlock(itv-serialize_lock);
prepare_to_wait(itv-dma_waitq, wait,
TASK_INTERRUPTIBLE);
diff --git a/drivers/media/pci/ivtv/ivtv-irq.c
b/drivers/media/pci/ivtv/ivtv-irq.c
index 19a7c9b990a3..7a44f6b7aed4 100644
--- a/drivers/media/pci/ivtv/ivtv-irq.c
+++ b/drivers/media/pci/ivtv/ivtv-irq.c
@@ -822,7 +822,7 @@ static void ivtv_irq_dec_data_req(struct ivtv *itv)
}
else {
if (test_bit(IVTV_F_I_DEC_YUV, itv-i_flags))
- ivtv_yuv_setup_stream_frame(itv);
+ ivtv_yuv_setup_stream_frame(itv, GFP_ATOMIC);
clear_bit(IVTV_F_S_NEEDS_DATA, s-s_flags);
ivtv_queue_move(s, s-q_full, NULL, s-q_predma,
itv-dma_data_req_size);
ivtv_dma_stream_dec_prepare(s, itv-dma_data_req_offset +
IVTV_DECODER_OFFSET, 0);
diff --git a/drivers/media/pci/ivtv/ivtv-yuv.c
b/drivers/media/pci/ivtv/ivtv-yuv.c
index 2ad65eb29832..9bf47b89f8a0 100644
--- a/drivers/media/pci/ivtv/ivtv-yuv.c
+++ b/drivers/media/pci/ivtv/ivtv-yuv.c
@@ -854,7 +854,7 @@ void ivtv_yuv_work_handler(struct ivtv *itv)
yi-old_frame_info = f;
}
-static void ivtv_yuv_init(struct ivtv *itv)
+static void ivtv_yuv_init(struct ivtv *itv, gfp_t gfp)
{
struct yuv_playback_info *yi = itv-yuv_info;
@@ -936,7 +936,7 @@ static void ivtv_yuv_init(struct ivtv *itv)
}
/* We need a buffer for blanking when Y plane is offset - non-fatal if
we can't get one */
- yi-blanking_ptr = kzalloc(720 * 16, GFP_KERNEL|__GFP_NOWARN);
+ yi-blanking_ptr = kzalloc(720 * 16, gfp|__GFP_NOWARN);
if (yi-blanking_ptr) {
yi-blanking_dmaptr = pci_map_single(itv-pdev,
yi-blanking_ptr, 720*16, PCI_DMA_TODEVICE);
} else {
@@ -952,13 +952,13 @@ static void ivtv_yuv_init(struct ivtv *itv)
}
/* Get next available yuv buffer on PVR350 */
-static void ivtv_yuv_next_free(struct ivtv *itv)
+static void ivtv_yuv_next_free(struct ivtv *itv, gfp_t gfp)
{
int draw, display;
struct yuv_playback_info *yi = itv-yuv_info;
if (atomic_read(yi-next_dma_frame) == -1)
- ivtv_yuv_init(itv);
+ ivtv_yuv_init(itv, gfp);
draw = atomic_read(yi-next_fill_frame);
display = atomic_read(yi-next_dma_frame);
@@ -1119,12 +1119,12 @@ static int ivtv_yuv_udma_frame(struct ivtv *itv,
struct ivtv_dma_frame *args)
}
/* Setup frame according to V4L2 parameters */
-void ivtv_yuv_setup_stream_frame(struct ivtv *itv)
+void ivtv_yuv_setup_stream_frame(struct ivtv *itv, gfp_t gfp)
{
struct yuv_playback_info *yi = itv-yuv_info;
struct ivtv_dma_frame dma_args;
- ivtv_yuv_next_free(itv);
+ ivtv_yuv_next_free(itv, gfp);
/* Copy V4L2 parameters to an ivtv_dma_frame struct... */
dma_args.y_source = NULL;
@@ -1151,7 +1151,7 @@ int ivtv_yuv_udma_stream_frame(struct ivtv *itv, void
__user *src)
struct ivtv_dma_frame dma_args;
int res;
- ivtv_yuv_setup_stream_frame(itv);
+ ivtv_yuv_setup_stream_frame(itv, GFP_KERNEL);
/* We only need to supply source addresses for this */
dma_args.y_source = src;
@@ -1171,7 +1171,7 @@
Re: [RFC] Fix interrupted recording with Hauppauge HD-PVR
On 04/08/2014 07:07 PM, Ryley Angus wrote:
Hi Kyle.
It may be possible that the delay in acceptable grace periods is due to a
difference in our input AV sources more so than the Hauppauge units
themselves. I'm wondering if it would be useful to control the timeout
period via a module parameter that defaults to 3 seconds perhaps?
It is OK for both of you if I set the timeout to 3 seconds in my patch? So it
will use msecs_to_jiffies(3000));.
If you can both confirm that that works, then I'll merge the patch.
Sorry for being late with my reply, it's been busy lately :-)
Regards,
Hans
As far as the issues with concatenated output, I've just looked at the files
containing a channel change and realized that VLC does show the duration as
0:00. Seeking with a keyboard isn't functional. Seeking with the timeline
and a mouse is fine. Avidemux seems to have trouble editing the file. If I
cut a section from a file that is from a single recording session it's
duration is correct, sync is correct and audio properties are correct. I
cannot cut across segments. MPC-HC also has duration issues with the
recording.
If I run the recordings through ffmpeg -fflags +genpts -I INPUT -c:v copy
-c:a copy OUTPUT, the resultant file duration is correct in VLC, I can
seek with the keyboard and mouse and editing is perfect with Avidemux. But
would it be better if the device just cleanly stopped recording instead of
automatically resuming? Or, continuing with the module parameters idea,
could we determine whether or not it will automatically restart based off a
module parameter?
I feel bad for not noticing the VLC issues earlier, but I mostly just use
VLC to broadcast the recordings through my home network to client instances
of VLC. This works well, but obviously seeking isn't relevant.
ryley
-Original Message-
From: Keith Pyle [mailto:kp...@austin.rr.com]
Sent: Wednesday, April 09, 2014 12:28 AM
To: Ryley Angus; 'Hans Verkuil'; linux-media@vger.kernel.org
Subject: Re: [RFC] Fix interrupted recording with Hauppauge HD-PVR
On 04/07/14 22:32, Ryley Angus wrote:
Thanks Hans for getting back to me.
I've been trying out your patch and I found the device wasn't actually
restarting the streaming/recording properly after a channel change. I
changed msecs_to_jiffies(500)) to msecs_to_jiffies(1000)) and had
the same issue, but msecs_to_jiffies(2000))
seems to be working well. I'll let it keep going for a few more hours,
but at the moment it seems to be working well. The recordings can be
ended without anything hanging, and turning off the device ends the
recording properly (mine neglected this occurrence).
I'll let you know if I have any more issues,
ryley
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Tuesday, April 08, 2014 12:07 AM
To: Ryley Angus; linux-media@vger.kernel.org
Subject: Re: [RFC] Fix interrupted recording with Hauppauge HD-PVR
Hi Ryley,
Thank you for the patch. Your analysis seems sound. The patch is
actually not bad for a first attempt, but I did it a bit differently.
Can you test my patch?
Regards,
Hans
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c
b/drivers/media/usb/hdpvr/hdpvr-video.c
index 0500c417..a61373e 100644
--- a/drivers/media/usb/hdpvr/hdpvr-video.c
+++ b/drivers/media/usb/hdpvr/hdpvr-video.c
@@ -454,6 +454,8 @@ static ssize_t hdpvr_read(struct file *file, char
__user *buffer, size_t count,
if (buf-status != BUFSTAT_READY
dev-status != STATUS_DISCONNECTED) {
+int err;
+
/* return nonblocking */
if (file-f_flags O_NONBLOCK) {
if (!ret)
@@ -461,11 +463,23 @@ static ssize_t hdpvr_read(struct file *file,
char __user *buffer, size_t count,
goto err;
}
-if (wait_event_interruptible(dev-wait_data,
- buf-status == BUFSTAT_READY))
{
-ret = -ERESTARTSYS;
+err =
wait_event_interruptible_timeout(dev-wait_data,
+ buf-status == BUFSTAT_READY,
+ msecs_to_jiffies(500));
+if (err 0) {
+ret = err;
goto err;
}
+if (!err) {
+v4l2_dbg(MSG_INFO, hdpvr_debug,
dev-v4l2_dev,
+timeout: restart streaming\n);
+hdpvr_stop_streaming(dev);
+err = hdpvr_start_streaming(dev);
+if (err) {
+ret = err;
+goto err;
[patch] [media] Staging: dt3155v4l: set error code on failure
We should be returning -ENOMEM here instead of success.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/staging/media/dt3155v4l/dt3155v4l.c
b/drivers/staging/media/dt3155v4l/dt3155v4l.c
index afbc2e5..178aa5b 100644
--- a/drivers/staging/media/dt3155v4l/dt3155v4l.c
+++ b/drivers/staging/media/dt3155v4l/dt3155v4l.c
@@ -907,8 +907,10 @@ dt3155_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
if (!pd)
return -ENOMEM;
pd-vdev = video_device_alloc();
- if (!pd-vdev)
+ if (!pd-vdev) {
+ err = -ENOMEM;
goto err_video_device_alloc;
+ }
*pd-vdev = dt3155_vdev;
pci_set_drvdata(pdev, pd);/* for use in dt3155_remove() */
video_set_drvdata(pd-vdev, pd); /* for use in video_fops */
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Smiapp quirk call order and best scaling ratio fixes
Hi Sakari, Thank you for the patches. On Wednesday 23 April 2014 22:33:56 Sakari Ailus wrote: Hi, The most important patch is the third one: wrong scaling ratio was selected in many (or most?) cases due to the wrong signedness of the variable. The other two have less effect on the functionality. Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- 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
[GIT PULL FOR v3.16] uvcvideo fixes
Hi Mauro, The following changes since commit 393cbd8dc532c1ebed60719da8d379f50d445f28: [media] smiapp: Use %u for printing u32 value (2014-04-23 16:05:06 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next for you to fetch changes up to 4d576e85f1d7e11190652619156b9a136d4c4a98: uvcvideo: Fix clock param realtime setting (2014-05-09 14:10:37 +0200) Anton Leontiev (1): uvcvideo: Fix marking buffer erroneous in case of FID toggling Olivier Langlois (1): uvcvideo: Fix clock param realtime setting drivers/media/usb/uvc/uvc_video.c | 36 +--- 1 file changed, 25 insertions(+), 11 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 1/3] smiapp: Use better regulator name for the Device tree
Hi Sakari,
Thank you for the patch.
On Sunday 04 May 2014 03:31:55 Sakari Ailus wrote:
Rename VANA regulator as vana.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/i2c/smiapp/smiapp-core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c index 8741cae..c1d6d1d 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2355,7 +2355,7 @@ static int smiapp_registered(struct v4l2_subdev
*subdev) unsigned int i;
int rval;
- sensor-vana = devm_regulator_get(client-dev, VANA);
+ sensor-vana = devm_regulator_get(client-dev, vana);
if (IS_ERR(sensor-vana)) {
dev_err(client-dev, could not get regulator for vana\n);
return -ENODEV;
--
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 3/3] smiapp: Return correct return value in smiapp_registered()
Hi Sakari,
Thank you for the patch.
On Sunday 04 May 2014 03:31:57 Sakari Ailus wrote:
Prepare for supporting systems using the Device tree. Should the resources
not be available at the time of driver probe(), the EPROBE_DEFER error code
must be also returned from its probe function.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/i2c/smiapp/smiapp-core.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c index e4037c8..3c7be76 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2358,14 +2358,14 @@ static int smiapp_registered(struct v4l2_subdev
*subdev) sensor-vana = devm_regulator_get(client-dev, vana);
if (IS_ERR(sensor-vana)) {
dev_err(client-dev, could not get regulator for vana\n);
- return -ENODEV;
+ return PTR_ERR(sensor-vana);
}
if (!sensor-platform_data-set_xclk) {
sensor-ext_clk = devm_clk_get(client-dev, ext_clk);
if (IS_ERR(sensor-ext_clk)) {
dev_err(client-dev, could not get clock\n);
- return -ENODEV;
+ return PTR_ERR(sensor-ext_clk);
}
rval = clk_set_rate(sensor-ext_clk,
@@ -2374,18 +2374,19 @@ static int smiapp_registered(struct v4l2_subdev
*subdev) dev_err(client-dev,
unable to set clock freq to %u\n,
sensor-platform_data-ext_clk);
- return -ENODEV;
+ return rval;
}
}
if (gpio_is_valid(sensor-platform_data-xshutdown)) {
- if (devm_gpio_request_one(client-dev,
- sensor-platform_data-xshutdown, 0,
- SMIA++ xshutdown) != 0) {
+ rval = devm_gpio_request_one(
+ client-dev, sensor-platform_data-xshutdown, 0,
+ SMIA++ xshutdown);
+ if (rval 0) {
dev_err(client-dev,
unable to acquire reset gpio %d\n,
sensor-platform_data-xshutdown);
- return -ENODEV;
+ return rval;
}
}
--
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 2/3] smiapp: Check for GPIO validity using gpio_is_valid()
Hi Sakari,
Thank you for the patch.
On Sunday 04 May 2014 03:31:56 Sakari Ailus wrote:
Do not use our special value, SMIAPP_NO_XSHUTDOWN.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Wouldn't it make sense to switch to the gpiod API ? That change could then
replace this patch. If you would like to do so in an incremental patch
instead,
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/i2c/smiapp/smiapp-core.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c index c1d6d1d..e4037c8 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -1128,7 +1128,7 @@ static int smiapp_power_on(struct smiapp_sensor
*sensor) }
usleep_range(1000, 1000);
- if (sensor-platform_data-xshutdown != SMIAPP_NO_XSHUTDOWN)
+ if (gpio_is_valid(sensor-platform_data-xshutdown))
gpio_set_value(sensor-platform_data-xshutdown, 1);
sleep = SMIAPP_RESET_DELAY(sensor-platform_data-ext_clk);
@@ -1238,7 +1238,7 @@ static int smiapp_power_on(struct smiapp_sensor
*sensor) return 0;
out_cci_addr_fail:
- if (sensor-platform_data-xshutdown != SMIAPP_NO_XSHUTDOWN)
+ if (gpio_is_valid(sensor-platform_data-xshutdown))
gpio_set_value(sensor-platform_data-xshutdown, 0);
if (sensor-platform_data-set_xclk)
sensor-platform_data-set_xclk(sensor-src-sd, 0);
@@ -1264,7 +1264,7 @@ static void smiapp_power_off(struct smiapp_sensor
*sensor) SMIAPP_REG_U8_SOFTWARE_RESET,
SMIAPP_SOFTWARE_RESET);
- if (sensor-platform_data-xshutdown != SMIAPP_NO_XSHUTDOWN)
+ if (gpio_is_valid(sensor-platform_data-xshutdown))
gpio_set_value(sensor-platform_data-xshutdown, 0);
if (sensor-platform_data-set_xclk)
sensor-platform_data-set_xclk(sensor-src-sd, 0);
@@ -2378,7 +2378,7 @@ static int smiapp_registered(struct v4l2_subdev
*subdev) }
}
- if (sensor-platform_data-xshutdown != SMIAPP_NO_XSHUTDOWN) {
+ if (gpio_is_valid(sensor-platform_data-xshutdown)) {
if (devm_gpio_request_one(client-dev,
sensor-platform_data-xshutdown, 0,
SMIA++ xshutdown) != 0) {
@@ -2830,7 +2830,7 @@ static int smiapp_remove(struct i2c_client *client)
unsigned int i;
if (sensor-power_count) {
- if (sensor-platform_data-xshutdown != SMIAPP_NO_XSHUTDOWN)
+ if (gpio_is_valid(sensor-platform_data-xshutdown))
gpio_set_value(sensor-platform_data-xshutdown, 0);
if (sensor-platform_data-set_xclk)
sensor-platform_data-set_xclk(sensor-src-sd, 0);
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] v4l2-ioctl: drop spurious newline in string
The message logged by v4l_print_cropcap should be a single line without linebreaks, just like all the other v4l_print_ioctl functions. diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index f729bd2..16bffd8 100644 --- a/drivers/media/v4l2-core/v4l2-ioctl.c +++ b/drivers/media/v4l2-core/v4l2-ioctl.c @@ -562,7 +562,7 @@ static void v4l_print_cropcap(const void *arg, bool write_only) const struct v4l2_cropcap *p = arg; pr_cont(type=%s, bounds wxh=%dx%d, x,y=%d,%d, - defrect wxh=%dx%d, x,y=%d,%d\n, + defrect wxh=%dx%d, x,y=%d,%d, pixelaspect %d/%d\n, prt_names(p-type, v4l2_type_names), p-bounds.width, p-bounds.height, -- 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.16] UVC gadget driver fixes
Hi Felipe, Could you please pull the following three patches for v3.16 ? They've been reviewed on the linux-media and linux-usb mailing list. The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5: Linux 3.15-rc1 (2014-04-13 14:18:35 -0700) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-gadget for you to fetch changes up to 7b1e2101bd9286fd9b8e1b37292da32f02080a4f: usb: gadget: uvc: Set the vb2 queue timestamp flags (2014-05-09 14:24:30 +0200) Laurent Pinchart (3): usb: gadget: uvc: Switch to monotonic clock for buffer timestamps usb: gadget: uvc: Set the V4L2 buffer field to V4L2_FIELD_NONE usb: gadget: uvc: Set the vb2 queue timestamp flags drivers/usb/gadget/uvc_queue.c | 12 +--- 1 file changed, 5 insertions(+), 7 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 2/3] smiapp: Check for GPIO validity using gpio_is_valid()
Hi Laurent, On Fri, May 09, 2014 at 02:18:24PM +0200, Laurent Pinchart wrote: On Sunday 04 May 2014 03:31:56 Sakari Ailus wrote: Do not use our special value, SMIAPP_NO_XSHUTDOWN. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Wouldn't it make sense to switch to the gpiod API ? That change could then replace this patch. If you would like to do so in an incremental patch instead, I'll do that a little later. Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Thanks! -- Kind 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: Support for Elgato Game Capture HD / MStar MST3367CMK
On Thu, May 8, 2014 at 9:48 PM, Tolga Cakir to...@cevel.net wrote: Hello everyone! Hi Tolga! Over the past weeks, I've been busy capturing USB packets between the Elgato Game Capture HD and my PC. It's using the MStar MST3367CMK chip, which seems to have proprietary Linux support available only for hardware vendors in form of an SDK. Problem is, that this SDK is strictly kept under an NDA, making it kinda impossible for us to get our hands on. Thanks for raising the subject. While your comment is true, it would have been more appropriate to the development community to say that it truly uses the Fujitsu USB encoder, a fujitsu USB API along with a series of smaller subsystems for HDMI receivers and transmitters. Your capture logs indicate (largely) interaction with the Fujitsu USB bridge + integral encoder. The distinction is important. We outlined the architecture of the device (along with the brief tear down) here: http://www.kernellabs.com/blog/?p=1959 So, I got my hands dirty and have found some very good stuff! First of all, in contrast to many sources, the Elgato Game Capture HD outputs compressed video and audio via USB! It's already encoded, so there is no need for reencoding, this will save CPU power. For testing purposes, I've only tried capturing 720p data for now, but this should be more than enough. Have you posted any source code? I don't see any in the zips or on github. Paging through a 600MB usb capture to find an occasional comment (assuming you have inserted them) doesn't encourage me to contribute. Basically, we need to read raw USB traffic, write an MPEG-TS file header, put in the raw USB data and close the file. I'm not super experienced in C / kernel development (especially V4L), but I'll give my best to get this project forward. My next step is getting a prototype working with libusb in userland; after that's done, I'll try porting it over to kernel / V4L Project page can be found here: https://github.com/tolga9009/elgato-gchd I must be missing something. your repo contains a LICENSE file and README. Did you forget to checking a homebrew datasheet or working sample source code? USB logs and docs: v1.0 as 7zip: https://docs.google.com/file/d/0B29z6-xPIPLEQVBMTWZHbUswYjg v1.0 as rar: https://docs.google.com/file/d/0B29z6-xPIPLEcENMWnh1MklPdTQ v1.0 as zip: https://docs.google.com/file/d/0B29z6-xPIPLEQWtibWk3T3AtVjA Ahh, thank you for circulating the datasheets and images from our blog post, you are most welcome! The internet is a wonderful thing, I'm glad you found them useful. Is anyone interested in getting involved / taking over? Overall, it seems doable and not too complex. I'd be happy about any help! Also, if you need more information, just ask me. I'll provide you everything I have about this little device. How about instead of some usb dumps, pictures and pdfs, a working program and a description of the device protocol? This would help. I spent a few days late 2012 with the usb analyzer and brought together a primitive collection of personal notes on the API. Sadly I'm struggling to locate them currently. From memory, the device has an odd protocol which isn't exactly obvious. Its firmware like, not i2c based. You don't appear to control the HDMI rx/tx silicon by hand, the fijutsu firmware does this via firmware APIs. you would think, YAY! firmware API, easy, surprisingly not. A lot of byte guess to be done. If you have any significant homebrew documentation on the byte sequences that control the device, this would help. Part of the problem is that the device also streams (with the windows/osx drivers I was using) permanently on, making it difficult to see the wood from the noise. So, even when you are not 'using it', its streaming payload via USB to the host. Urgh. I hope they've fixed this. The device outputs native ISO13818 TS packets which are easily playable in VLC as is. I don't even think you need to add a header, unless you are electing to create an updated PMT. I have datasheets and/or source on everything except the fujitsu encoder, sorry - I can't share. Keep going with your project, this should be a fun to follow. libusb is easy to work with, you should have the device running in no time. If you can make the device run at both 720p and 1080i then you should find enough variance in the protocol bytes, build that into your app, to be useful for some people. - Steve -- Steven Toth - 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
[GIT PULL FOR v3.16] OMAP4 ISS fixes
Hi Mauro, The following changes since commit 393cbd8dc532c1ebed60719da8d379f50d445f28: [media] smiapp: Use %u for printing u32 value (2014-04-23 16:05:06 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/media.git omap4iss/next for you to fetch changes up to 616862a3c32b0e1ce9ac99635806b2962e5f50f0: omap4iss: Relax usleep ranges (2014-05-09 14:39:47 +0200) Laurent Pinchart (4): omap4iss: Don't check for DEBUG when printing IRQ debugging messages omap4iss: Add missing white space omap4iss: Use a common macro for all sleep-based poll loops omap4iss: Relax usleep ranges Paul Bolle (1): omap4iss: Remove VIDEO_OMAP4_DEBUG Kconfig option drivers/staging/media/omap4iss/Kconfig | 6 - drivers/staging/media/omap4iss/iss.c | 52 ++--- drivers/staging/media/omap4iss/iss.h | 14 ++ drivers/staging/media/omap4iss/iss_csi2.c | 39 drivers/staging/media/omap4iss/iss_video.h | 2 +- 5 files changed, 49 insertions(+), 64 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
[GIT PULL FOR v3.16] Various fixes
Hi Mauro, I went through my pending patches queue and managed to go through most of it. There is still one em28xx patch series pending (waiting for feedback from Frank about one patch) and I expect more patches from Prabhakar. Hopefully I can do another batch on Monday. Most patches are fairly trivial, but you should take a close look at the videobuf-dma-contig patch from Ma Haijun since you introduced the vm_iomap_memory() change. I reviewed it carefully and tested it and it seems sound to me, but that's one patch that needs an extra pair of eyeballs. Also note that I tested the saa7134 querybuf patch from Mikhail Domrachev successfully using my signal generator. Regards, Hans The following changes since commit 393cbd8dc532c1ebed60719da8d379f50d445f28: [media] smiapp: Use %u for printing u32 value (2014-04-23 16:05:06 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.16d for you to fetch changes up to e9ed81f0b4707fda56a36cf24ea25f0f3205b423: saa7134: add vidioc_querystd (2014-05-09 14:33:49 +0200) Alexander Shiyan (1): media: coda: Use full device name for request_irq() Bartlomiej Zolnierkiewicz (1): v4l: ti-vpe: fix devm_ioremap_resource() return value checking Daeseok Youn (1): s2255drv: fix memory leak s2255_probe() Dan Carpenter (1): av7110: fix confusing indenting Frank Schaefer (4): em28xx: fix indenting in em28xx_usb_probe() em28xx: remove some unused fields from struct em28xx em28xx: remove function em28xx_compression_disable() and its call em28xx: move norm_maxw() and norm_maxh() from em28xx.h to em28xx-video.c Hans Verkuil (2): v4l2-pci-skeleton: fix typo v4l2-ioctl: drop spurious newline in string Himangi Saraogi (1): timblogiw: Introduce the use of the managed version of kzalloc Jinqiang Zeng (1): fix the code style errors in sn9c102 Kirill Tkhai (1): s2255: Do not free fw_data until timer handler has actually stopped using it Lad, Prabhakar (1): media: davinci: vpbe: release buffers in case start_streaming call back fails Ma Haijun (1): videobuf-dma-contig: fix incorrect argument to vm_iomap_memory() call Masanari Iida (1): media: parport: Fix format string mismatch in bw-qcam.c Mikhail Domrachev (1): saa7134: add vidioc_querystd Pali Rohár (1): radio-bcm2048: fix wrong overflow check Ricardo Ribalda (1): videobuf2-dma-sg: Fix NULL pointer dereference BUG Takashi Iwai (1): ivtv: Fix Oops when no firmware is loaded Vitaly Osipov (2): staging: media: omap24xx: fix up checkpatch error message staging: media: omap24xx: use pr_info() instead of KERN_INFO Documentation/video4linux/v4l2-pci-skeleton.c | 2 +- drivers/media/parport/bw-qcam.c| 2 +- drivers/media/pci/ivtv/ivtv-alsa-pcm.c | 6 ++ drivers/media/pci/saa7134/saa7134-empress.c| 1 + drivers/media/pci/saa7134/saa7134-reg.h| 5 ++ drivers/media/pci/saa7134/saa7134-video.c | 41 - drivers/media/pci/saa7134/saa7134.h| 1 + drivers/media/pci/ttpci/av7110_av.c| 6 +- drivers/media/platform/coda.c | 2 +- drivers/media/platform/davinci/vpbe_display.c | 11 ++- drivers/media/platform/ti-vpe/csc.c| 4 +- drivers/media/platform/ti-vpe/sc.c | 4 +- drivers/media/platform/timblogiw.c | 8 +- drivers/media/usb/em28xx/em28xx-cards.c| 13 ++- drivers/media/usb/em28xx/em28xx-video.c| 28 +- drivers/media/usb/em28xx/em28xx.h | 32 --- drivers/media/usb/s2255/s2255drv.c | 6 +- drivers/media/v4l2-core/v4l2-ioctl.c | 2 +- drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +- drivers/media/v4l2-core/videobuf2-dma-sg.c | 2 +- drivers/staging/media/bcm2048/radio-bcm2048.c | 2 +- drivers/staging/media/omap24xx/tcm825x.c | 12 +-- drivers/staging/media/sn9c102/sn9c102.h| 30 +++ drivers/staging/media/sn9c102/sn9c102_core.c | 342 + drivers/staging/media/sn9c102/sn9c102_devtable.h | 22 ++--- drivers/staging/media/sn9c102/sn9c102_hv7131d.c| 22 ++--- drivers/staging/media/sn9c102/sn9c102_mi0343.c | 30 +++ drivers/staging/media/sn9c102/sn9c102_mi0360.c | 30 +++ drivers/staging/media/sn9c102/sn9c102_ov7630.c | 22 ++--- drivers/staging/media/sn9c102/sn9c102_ov7660.c | 22 ++--- drivers/staging/media/sn9c102/sn9c102_pas106b.c| 22 ++--- drivers/staging/media/sn9c102/sn9c102_pas202bcb.c | 22 ++--- drivers/staging/media/sn9c102/sn9c102_sensor.h | 34 drivers/staging/media/sn9c102/sn9c102_tas5110c1b.c | 18
Re: V4L control units
On 05/08/2014 11:04 AM, Sakari Ailus wrote: Heippa! On Wed, May 07, 2014 at 03:57:11PM +0300, Antti Palosaari wrote: What is preferred way implement controls that could have some known unit or unknown unit? For example for gain controls, I would like to offer gain in unit of dB (decibel) and also some unknown driver specific unit. Should I two controls, one for each unit? Like that V4L2_CID_RF_TUNER_LNA_GAIN_AUTO V4L2_CID_RF_TUNER_LNA_GAIN V4L2_CID_RF_TUNER_LNA_GAIN_dB I suppose that on any single device there would be a single unit to control a given... control. Some existing controls do document the unit as well but I don't think that's scalable nor preferrable. This way we'd have many different controls to control the same thing but just using a different unit. The auto control is naturally different. Hans did have a patch to add the unit to queryctrl (in the form of QUERY_EXT_CTRL). Well, that's going to be dropped again. There were too many comments about that during the mini-summit and it was not critical for me. URL:http://www.spinics.net/lists/linux-media/msg73136.html I wish we can get these in relatively soon. Sakari, I think you will have to push this if you want this done. One interesting thing to look at: the AVB IEEE 1722.1 standard has extensive support for all sorts of units. I don't know if you have access to the standard document, but it might be interesting to look at what they do there. 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: s_ctrl V4l2 device driver does not work
On 05/08/2014 11:30 PM, Marcio Campos de Lima wrote:
I have also tried these settings
#define VIDIOC_AVANCA_ZOOM(0x009a|0x900)+14
#define VIDIOC_RECUA_ZOOM (0x009a|0x900)+14
All controls must have unique IDs, which is clearly not the case for these
two ZOOM controls.
You say you have problems with setting AVANCA_ZOOM, but you don't provide
the code in s_ctrl that actually handles that control, so that makes it
impossible to tell what's going on.
In addition I see a 'return 1' in s_ctrl, which makes no sense since return
codes from s_ctrl must either be 0 (for success) or negative (for error codes).
You really need to give more info (post the entire source?) if you want help.
Regards,
Hans
#define VIDIOC_ATIVA_FLASH(0x009a|0x900)+3
#define VIDIOC_WHITE_BALANCE (0x009a|0x900)+13
Em 08/05/2014, à(s) 18:01, Guennadi Liakhovetski g.liakhovet...@gmx.de
escreveu:
On Thu, 8 May 2014, Marcio Campos de Lima wrote:
Hi Guennadi
Thank you very much for your answer.
The driver is a modified OV5642.c for the Omnivision OV5642 sensor. The
platform is a custom AT91SAM9M10 board with a camera paralell interface.
the driver is working quite well (capturing images) apart the set control
interface.
So, you're using the atmel-isi camera _host_ driver.
Unfortunately I cannot move to the most current kernel now.
I don't find VIDIOC_AVANCA_ZOOM in the mainline kernel, it seems to be a
part of your modification, so, I don't think I can help you, sorry.
Thanks
Guennadi
Thanks again
Regards
Marcio
Em 08/05/2014, à(s) 17:14, Guennadi Liakhovetski g.liakhovet...@gmx.de
escreveu:
Hi Marcio,
Firstly, please direct all V4L related questions to the linux-media list
(added to CC), secondly, your problem will have much better chances to
attract attention if you use a current kernel, thirdly, please, specify
which camera host driver / which ARM platform you're dealing with.
Thanks
Guennadi
On Thu, 8 May 2014, Marcio Campos de Lima wrote:
Hi
Can anybody tell me why the set control function is not working in Linux
3.6.9? Thanks.
—— APPLICATION CALL ——
struct v4l2_control controle;
controle.id = VIDIOC_AVANCA_ZOOM;
controle.value = time;
if (-1 == xioctl(fd_camera, VIDIOC_S_CTRL,controle))
{
printf (%s erro\n,__FUNCTION__);
perror (erro iotcl);
}
The ioctl call returns with invalid argument. It is amazing because the
first time the ioctl is called it is executed ok. Then no more call is
allowed and return the invalid
below is the device driver code I think may be relevant.
v4l2_ctrl_handler_init(priv-ctrls, ARRAY_SIZE(ov5642_ctrls));
printk (handler_init\n);
v4l2_ctrl_new_std(priv-ctrls,
ov5642_ctrl_ops,V4L2_CID_ZOOM_RELATIVE, -1000, 1000, 1, 500);
v4l2_ctrl_new_std(priv-ctrls, ov5642_ctrl_ops,V4L2_CID_FLASH_STROBE,
-100, 100, 1, 5);
priv-subdev.ctrl_handler=priv-ctrls;
v4l2_i2c_subdev_init(priv-subdev, client, ov5642_subdev_ops);
return ov5642_video_probe(client);
static int ov5642_s_ctrl(struct v4l2_ctrl *ctrl)
{
struct ov5642 *ov5642 =
container_of(ctrl-handler, struct ov5642, ctrls);
struct i2c_client *client = v4l2_get_subdevdata(ov5642-subdev);
u16 data;
int ret;
printk (%s: id=%08x val=%d\n,__FUNCTION__, ctrl-id, ctrl-val);
switch (ctrl-id) {
case V4L2_CID_DO_WHITE_BALANCE:
ov5640_set_wb_oem(client, ctrl-val);
break;
case V4L2_CID_EXPOSURE:
break;
case V4L2_CID_GAIN:
/* Gain is controlled by 2 analog stages and a digital stage.
* Valid values for the 3 stages are
*
* StageMin Max Step
* --
* First analog stage x1 x2 1
* Second analog stage x1 x4 0.125
* Digital stagex1 x16 0.125
*
* To minimize noise, the gain stages should be used in the
* second analog stage, first analog stage, digital stage order.
* Gain from a previous stage should be pushed to its maximum
* value before the next stage is used.
*/
if (ctrl-val = 32) {
data = ctrl-val;
} else if (ctrl-val = 64) {
ctrl-val = ~1;
data = (1 6) | (ctrl-val 1);
} else {
ctrl-val = ~7;
data = ((ctrl-val - 64) 5) | (1 6) | 32;
}
break;
case V4L2_CID_ZOOM_RELATIVE:
if (ctrl-val0)
avanca_zoom(sysPriv.v4l2_int_device, ctrl-val);
else
recua_zoom(sysPriv.v4l2_int_device, ctrl-val);
break;
case V4L2_CID_BRIGHTNESS:
ov5640_set_brightness(client, ctrl-val);
break;
case V4L2_CID_CONTRAST:
ov5640_set_contrast(client,
Re: [PATCH v2] media: stk1160: Avoid stack-allocated buffer for control URBs
On 09 May 12:34 PM, Hans Verkuil wrote: Hi Ezequiel, On 04/17/2014 02:28 PM, Ezequiel Garcia wrote: Currently stk1160_read_reg() uses a stack-allocated char to get the read control value. This is wrong because usb_control_msg() requires a kmalloc-ed buffer. This commit fixes such issue by kmalloc'ating a 1-byte buffer to receive the read value. While here, let's remove the urb_buf array which was meant for a similar purpose, but never really used. Rather than allocating and freeing a buffer for every read_reg I would allocate this buffer in the probe function. That way this allocation is done only once. I get your point. I just thought that since the control URBs are only used for changing the configuration parameters, and this path is scarcely taken, it wasn't a big deal to allocate it each time. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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: [PATCH v3 1/2] [media] v4l: Add source change event
Hi Arun,
Thank you for the patch. We're slowly getting there :-)
On Thursday 08 May 2014 17:19:15 Arun Kumar K wrote:
This event indicates that the video device has encountered
a source parameter change during runtime. This can typically be a
resolution change detected by a video decoder OR a format change
detected by an HDMI connector.
This needs to be nofified to the userspace and the application may
be expected to reallocate buffers before proceeding. The application
can subscribe to events on a specific pad or input/output port which
it is interested in.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 32 +
.../DocBook/media/v4l/vidioc-subscribe-event.xml | 19 +++
drivers/media/v4l2-core/v4l2-event.c | 36 +
include/media/v4l2-event.h |4 +++
include/uapi/linux/videodev2.h |8 +
5 files changed, 99 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml index 89891ad..6afabaa
100644
--- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
@@ -242,6 +242,22 @@
/tgroup
/table
+table frame=none pgwide=1 id=v4l2-event-src-change
+ titlestruct structnamev4l2_event_src_change/structname/title
+ tgroup cols=3
+ cs-str;
+ tbody valign=top
+ row
+ entry__u32/entry
+ entrystructfieldchanges/structfield/entry
+ entry
+ A bitmask that tells what has changed. See xref
linkend=src-changes-flags /. + /entry
+ /row
+ /tbody
+ /tgroup
+/table
+
table pgwide=1 frame=none id=changes-flags
titleChanges/title
tgroup cols=3
@@ -270,6 +286,22 @@
/tbody
/tgroup
/table
+
+table pgwide=1 frame=none id=src-changes-flags
+ titleSource Changes/title
+ tgroup cols=3
+ cs-def;
+ tbody valign=top
+ row
+ entryconstantV4L2_EVENT_SRC_CH_RESOLUTION/constant/entry
+ entry0x0001/entry
+ entryThis event gets triggered when a resolution change is
+ detected at runtime. This can typically come from a video decoder.
+ /entry
+ /row
+ /tbody
+ /tgroup
+/table
/refsect1
refsect1
return-value;
diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index
5c70b61..8012829 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
@@ -155,6 +155,25 @@
/entry
/row
row
+ entryconstantV4L2_EVENT_SOURCE_CHANGE/constant/entry
+ entry5/entry
+ entry
+ paraThis event is triggered when a format change is
+detected during runtime by the video device. It can be a
+runtime resolution change triggered by a video decoder or the
+format change happening on an HDMI connector.
+This event requires that the structfieldid/structfield
+ matches the pad/input/output index from which you want to
+receive events./para
+
+ paraThis event has a v4l2-event-source-change; associated
+ with it. The structfieldchanges/structfield bitfield denotes
+ what has changed for the subscribed pad. If multiple events
+ occured before application could dequeue them, then the changes
+ will have the ORed value of all the events generated./para
+ /entry
+ /row
+ row
entryconstantV4L2_EVENT_PRIVATE_START/constant/entry
entry0x0800/entry
entryBase event number for driver-private events./entry
diff --git a/drivers/media/v4l2-core/v4l2-event.c
b/drivers/media/v4l2-core/v4l2-event.c index 86dcb54..8761aab 100644
--- a/drivers/media/v4l2-core/v4l2-event.c
+++ b/drivers/media/v4l2-core/v4l2-event.c
@@ -318,3 +318,39 @@ int v4l2_event_subdev_unsubscribe(struct v4l2_subdev
*sd, struct v4l2_fh *fh, return v4l2_event_unsubscribe(fh, sub);
}
EXPORT_SYMBOL_GPL(v4l2_event_subdev_unsubscribe);
+
+static void v4l2_event_src_replace(struct v4l2_event *old,
+ const struct v4l2_event *new)
+{
+ u32 old_changes = old-u.src_change.changes;
+
+ old-u.src_change = new-u.src_change;
+ old-u.src_change.changes |= old_changes;
+}
+
+static void v4l2_event_src_merge(const struct v4l2_event *old,
+ struct v4l2_event *new)
+{
+ new-u.src_change.changes |= old-u.src_change.changes;
+}
+
+static const struct v4l2_subscribed_event_ops v4l2_event_src_ch_ops = {
+ .replace =
Re: [PATCH v3 1/2] [media] v4l: Add source change event
On 05/09/2014 03:09 PM, Laurent Pinchart wrote:
Hi Arun,
Thank you for the patch. We're slowly getting there :-)
On Thursday 08 May 2014 17:19:15 Arun Kumar K wrote:
This event indicates that the video device has encountered
a source parameter change during runtime. This can typically be a
resolution change detected by a video decoder OR a format change
detected by an HDMI connector.
This needs to be nofified to the userspace and the application may
be expected to reallocate buffers before proceeding. The application
can subscribe to events on a specific pad or input/output port which
it is interested in.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 32 +
.../DocBook/media/v4l/vidioc-subscribe-event.xml | 19 +++
drivers/media/v4l2-core/v4l2-event.c | 36 +
include/media/v4l2-event.h |4 +++
include/uapi/linux/videodev2.h |8 +
5 files changed, 99 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml index 89891ad..6afabaa
100644
--- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
@@ -242,6 +242,22 @@
/tgroup
/table
+table frame=none pgwide=1 id=v4l2-event-src-change
+ titlestruct structnamev4l2_event_src_change/structname/title
+ tgroup cols=3
+cs-str;
+tbody valign=top
+ row
+entry__u32/entry
+entrystructfieldchanges/structfield/entry
+entry
+ A bitmask that tells what has changed. See xref
linkend=src-changes-flags /. +/entry
+ /row
+/tbody
+ /tgroup
+/table
+
table pgwide=1 frame=none id=changes-flags
titleChanges/title
tgroup cols=3
@@ -270,6 +286,22 @@
/tbody
/tgroup
/table
+
+table pgwide=1 frame=none id=src-changes-flags
+ titleSource Changes/title
+ tgroup cols=3
+cs-def;
+tbody valign=top
+ row
+entryconstantV4L2_EVENT_SRC_CH_RESOLUTION/constant/entry
+entry0x0001/entry
+entryThis event gets triggered when a resolution change is
+detected at runtime. This can typically come from a video decoder.
+/entry
+ /row
+/tbody
+ /tgroup
+/table
/refsect1
refsect1
return-value;
diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index
5c70b61..8012829 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
@@ -155,6 +155,25 @@
/entry
/row
row
+entryconstantV4L2_EVENT_SOURCE_CHANGE/constant/entry
+entry5/entry
+entry
+ paraThis event is triggered when a format change is
+ detected during runtime by the video device. It can be a
+ runtime resolution change triggered by a video decoder or the
+ format change happening on an HDMI connector.
+ This event requires that the structfieldid/structfield
+ matches the pad/input/output index from which you want to
+ receive events./para
+
+ paraThis event has a v4l2-event-source-change; associated
+ with it. The structfieldchanges/structfield bitfield denotes
+ what has changed for the subscribed pad. If multiple events
+ occured before application could dequeue them, then the changes
+ will have the ORed value of all the events generated./para
+/entry
+ /row
+ row
entryconstantV4L2_EVENT_PRIVATE_START/constant/entry
entry0x0800/entry
entryBase event number for driver-private events./entry
diff --git a/drivers/media/v4l2-core/v4l2-event.c
b/drivers/media/v4l2-core/v4l2-event.c index 86dcb54..8761aab 100644
--- a/drivers/media/v4l2-core/v4l2-event.c
+++ b/drivers/media/v4l2-core/v4l2-event.c
@@ -318,3 +318,39 @@ int v4l2_event_subdev_unsubscribe(struct v4l2_subdev
*sd, struct v4l2_fh *fh, return v4l2_event_unsubscribe(fh, sub);
}
EXPORT_SYMBOL_GPL(v4l2_event_subdev_unsubscribe);
+
+static void v4l2_event_src_replace(struct v4l2_event *old,
+const struct v4l2_event *new)
+{
+u32 old_changes = old-u.src_change.changes;
+
+old-u.src_change = new-u.src_change;
+old-u.src_change.changes |= old_changes;
+}
+
+static void v4l2_event_src_merge(const struct v4l2_event *old,
+struct v4l2_event *new)
+{
+new-u.src_change.changes |= old-u.src_change.changes;
+}
+
+static const struct v4l2_subscribed_event_ops v4l2_event_src_ch_ops = {
+.replace =
Re: [GIT PULL FOR v3.16] uvcvideo fixes
Hi Laurent Any chance of my patch fixing manual exposure mode for the Logitech C920[1] going in for 3.16? [1]: https://patchwork.linuxtv.org/patch/23047/ Thanks Will -- 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: V4L control units
Hi Hans, On Fri, May 09, 2014 at 02:57:13PM +0200, Hans Verkuil wrote: On 05/08/2014 11:04 AM, Sakari Ailus wrote: Heippa! On Wed, May 07, 2014 at 03:57:11PM +0300, Antti Palosaari wrote: What is preferred way implement controls that could have some known unit or unknown unit? For example for gain controls, I would like to offer gain in unit of dB (decibel) and also some unknown driver specific unit. Should I two controls, one for each unit? Like that V4L2_CID_RF_TUNER_LNA_GAIN_AUTO V4L2_CID_RF_TUNER_LNA_GAIN V4L2_CID_RF_TUNER_LNA_GAIN_dB I suppose that on any single device there would be a single unit to control a given... control. Some existing controls do document the unit as well but I don't think that's scalable nor preferrable. This way we'd have many different controls to control the same thing but just using a different unit. The auto control is naturally different. Hans did have a patch to add the unit to queryctrl (in the form of QUERY_EXT_CTRL). Well, that's going to be dropped again. There were too many comments about that during the mini-summit and it was not critical for me. Ok. Thanks for the information. URL:http://www.spinics.net/lists/linux-media/msg73136.html I wish we can get these in relatively soon. Sakari, I think you will have to push this if you want this done. Ack. I think I proposed something like this already a few years ago so I'm fine picking it up. :-) Now it's a good time to add the required space in the struct as we're going to have a new IOCTL anyway. One interesting thing to look at: the AVB IEEE 1722.1 standard has extensive support for all sorts of units. I don't know if you have access to the standard document, but it might be interesting to look at what they do there. I have access to it but I don't see this would be that interesting in regards to what we're doing. In any case, we should document the units so that different drivers end up using exactly the same string to signal a particular unit. I prefer to have a prefix as well: a lot of hardware devices use binary fractions so that even if we provide an integer control to the user the actual control value may well be divided by e.g. 256. That is a somewhat separate topic still. -- Kind 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
[GIT PULL for v3.16] smiapp: Scaling configuration fix, rename regulator; fixes
Hi Mauro, This patchset contains a few miscellaneous fixes but more importantly, a fix for calculating the best scaling and binning ratios. The regulator is also renamed as lower case. The following changes since commit 393cbd8dc532c1ebed60719da8d379f50d445f28: [media] smiapp: Use %u for printing u32 value (2014-04-23 16:05:06 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git smiapp for you to fetch changes up to 183f76494e92a585d9c71f130759553d57bab5f9: smiapp: Return correct return value in smiapp_registered() (2014-05-09 15:44:11 +0300) Sakari Ailus (6): smiapp: Print the index of the format descriptor smiapp: Call limits quirk immediately after retrieving the limits smiapp: Scaling goodness is signed smiapp: Use better regulator name for the Device tree smiapp: Check for GPIO validity using gpio_is_valid() smiapp: Return correct return value in smiapp_registered() drivers/media/i2c/smiapp/smiapp-core.c | 45 1 file changed, 23 insertions(+), 22 deletions(-) -- Kind 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: V4L control units
On 05/09/2014 03:46 PM, Sakari Ailus wrote: Hi Hans, On Fri, May 09, 2014 at 02:57:13PM +0200, Hans Verkuil wrote: On 05/08/2014 11:04 AM, Sakari Ailus wrote: Heippa! On Wed, May 07, 2014 at 03:57:11PM +0300, Antti Palosaari wrote: What is preferred way implement controls that could have some known unit or unknown unit? For example for gain controls, I would like to offer gain in unit of dB (decibel) and also some unknown driver specific unit. Should I two controls, one for each unit? Like that V4L2_CID_RF_TUNER_LNA_GAIN_AUTO V4L2_CID_RF_TUNER_LNA_GAIN V4L2_CID_RF_TUNER_LNA_GAIN_dB I suppose that on any single device there would be a single unit to control a given... control. Some existing controls do document the unit as well but I don't think that's scalable nor preferrable. This way we'd have many different controls to control the same thing but just using a different unit. The auto control is naturally different. Hans did have a patch to add the unit to queryctrl (in the form of QUERY_EXT_CTRL). Well, that's going to be dropped again. There were too many comments about that during the mini-summit and it was not critical for me. Ok. Thanks for the information. URL:http://www.spinics.net/lists/linux-media/msg73136.html I wish we can get these in relatively soon. Sakari, I think you will have to push this if you want this done. Ack. I think I proposed something like this already a few years ago so I'm fine picking it up. :-) Now it's a good time to add the required space in the struct as we're going to have a new IOCTL anyway. One interesting thing to look at: the AVB IEEE 1722.1 standard has extensive support for all sorts of units. I don't know if you have access to the standard document, but it might be interesting to look at what they do there. I have access to it but I don't see this would be that interesting in regards to what we're doing. In any case, we should document the units so that different drivers end up using exactly the same string to signal a particular unit. Actually, it is interesting. AVB has controls as well, and those map pretty much exactly to the sort of controls we have, and they support a wide range of units. Look at section 7.3.3 (Control Value Units) of IEEE 1722.1. If nothing else, it gives a good insight into how others handle this. Regards, Hans I prefer to have a prefix as well: a lot of hardware devices use binary fractions so that even if we provide an integer control to the user the actual control value may well be divided by e.g. 256. That is a somewhat separate topic still. -- 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: s_ctrl V4l2 device driver does not work
Hi Hans
Thanks a lot for your attention.
I managed to find the source of the problem in the following code
v4l2_ctrl_new_std(priv-ctrls, ov5642_ctrl_ops,V4L2_CID_ZOOM_RELATIVE, -1000,
1000, 1, 500)
v4l2_ctrl_new_std(priv-ctrls, ov5642_ctrl_ops,V4L2_CID_FLASH_STROBE, -100,
100, 1, 5);
The range of the maximum and minimum values for both v4l2_ctrl_new_std were not
corrected. I fixed that and the driver is working fine now.
I am not sure for the most updated version of the Kernel but the return code
for the ioctl should be more specific than it is now (Invalid argument).
I havent sent the entire code only because there so many things that are not
relevant that I thought that would not be helpfull.
Thanks all of you for the help.
Best regards
MArcio
Em 09/05/2014, à(s) 10:05, Hans Verkuil hverk...@xs4all.nl escreveu:
On 05/08/2014 11:30 PM, Marcio Campos de Lima wrote:
I have also tried these settings
#define VIDIOC_AVANCA_ZOOM (0x009a|0x900)+14
#define VIDIOC_RECUA_ZOOM(0x009a|0x900)+14
All controls must have unique IDs, which is clearly not the case for these
two ZOOM controls.
You say you have problems with setting AVANCA_ZOOM, but you don't provide
the code in s_ctrl that actually handles that control, so that makes it
impossible to tell what's going on.
In addition I see a 'return 1' in s_ctrl, which makes no sense since return
codes from s_ctrl must either be 0 (for success) or negative (for error
codes).
You really need to give more info (post the entire source?) if you want help.
Regards,
Hans
#define VIDIOC_ATIVA_FLASH (0x009a|0x900)+3
#define VIDIOC_WHITE_BALANCE (0x009a|0x900)+13
Em 08/05/2014, à(s) 18:01, Guennadi Liakhovetski g.liakhovet...@gmx.de
escreveu:
On Thu, 8 May 2014, Marcio Campos de Lima wrote:
Hi Guennadi
Thank you very much for your answer.
The driver is a modified OV5642.c for the Omnivision OV5642 sensor. The
platform is a custom AT91SAM9M10 board with a camera paralell interface.
the driver is working quite well (capturing images) apart the set control
interface.
So, you're using the atmel-isi camera _host_ driver.
Unfortunately I cannot move to the most current kernel now.
I don't find VIDIOC_AVANCA_ZOOM in the mainline kernel, it seems to be a
part of your modification, so, I don't think I can help you, sorry.
Thanks
Guennadi
Thanks again
Regards
Marcio
Em 08/05/2014, à(s) 17:14, Guennadi Liakhovetski g.liakhovet...@gmx.de
escreveu:
Hi Marcio,
Firstly, please direct all V4L related questions to the linux-media list
(added to CC), secondly, your problem will have much better chances to
attract attention if you use a current kernel, thirdly, please, specify
which camera host driver / which ARM platform you're dealing with.
Thanks
Guennadi
On Thu, 8 May 2014, Marcio Campos de Lima wrote:
Hi
Can anybody tell me why the set control function is not working in Linux
3.6.9? Thanks.
—— APPLICATION CALL ——
struct v4l2_control controle;
controle.id = VIDIOC_AVANCA_ZOOM;
controle.value = time;
if (-1 == xioctl(fd_camera, VIDIOC_S_CTRL,controle))
{
printf (%s erro\n,__FUNCTION__);
perror (erro iotcl);
}
The ioctl call returns with invalid argument. It is amazing because the
first time the ioctl is called it is executed ok. Then no more call is
allowed and return the invalid
below is the device driver code I think may be relevant.
v4l2_ctrl_handler_init(priv-ctrls, ARRAY_SIZE(ov5642_ctrls));
printk (handler_init\n);
v4l2_ctrl_new_std(priv-ctrls,
ov5642_ctrl_ops,V4L2_CID_ZOOM_RELATIVE, -1000, 1000, 1, 500);
v4l2_ctrl_new_std(priv-ctrls, ov5642_ctrl_ops,V4L2_CID_FLASH_STROBE,
-100, 100, 1, 5);
priv-subdev.ctrl_handler=priv-ctrls;
v4l2_i2c_subdev_init(priv-subdev, client, ov5642_subdev_ops);
return ov5642_video_probe(client);
static int ov5642_s_ctrl(struct v4l2_ctrl *ctrl)
{
struct ov5642 *ov5642 =
container_of(ctrl-handler, struct ov5642, ctrls);
struct i2c_client *client = v4l2_get_subdevdata(ov5642-subdev);
u16 data;
int ret;
printk (%s: id=%08x val=%d\n,__FUNCTION__, ctrl-id, ctrl-val);
switch (ctrl-id) {
case V4L2_CID_DO_WHITE_BALANCE:
ov5640_set_wb_oem(client, ctrl-val);
break;
case V4L2_CID_EXPOSURE:
break;
case V4L2_CID_GAIN:
/* Gain is controlled by 2 analog stages and a digital stage.
* Valid values for the 3 stages are
*
* StageMin Max Step
* --
* First analog stage x1 x2 1
* Second analog stage x1 x4 0.125
* Digital stagex1 x16 0.125
*
* To minimize noise, the gain stages should be used in the
* second analog stage, first analog stage, digital stage order.
* Gain from a previous stage
Hauppauge 950Q TS capture intermittent lock up
Hello all, I have written a simple application to capture RF QAM transport streams with the Hauppauge 950Q, and save to a file. This is essentially the same as dvbstream, but with unnecessary stuff removed (and I have verified this bug using dvbstream as well): - tune using frontend device - demux device: DMX_SET_PES_FILTER on pid 8192 with DMX_OUT_TS_TAP output. - Read from dvr device, save to file. - Interrupt app using alarm() and stop pes filter, close devices. This works as expected. The problem is after running this a bunch of times (sometimes 15-20+), the device seems to eventually get into a bad state, and nothing is available to read on the dvr device. The lockup never seems to happen while reading data (i.e., either data comes and the app works completely, or the app reads 0 bytes). When this happens, all the tuning/demod locks look good, and everything appears to be working -- there just isn't data ready to read from the dvr device. When it gets into a bad state, I have to physically remove/reinsert the 950Q device or otherwise reset the device (e.g., usb reset - USBDEVFS_RESET ioctl). Has anyone seen this issue before? I am running Fedora 19 with 3.13.9 kernel. Hardware is: - au0828, au8522, xc5000 (with dvb-fe-xc5000c-4.1.30.7.fw) Thanks, -Trevor -- 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] vb2: fix num_buffers calculation if req-count VIDEO_MAX_FRAMES
Signed-off-by: Philipp Zabel p.za...@pengutronix.de --- drivers/media/v4l2-core/videobuf2-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index 40024d7..4d4f6ba 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -905,7 +905,7 @@ static int __reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req) * Make sure the requested values and current defaults are sane. */ num_buffers = min_t(unsigned int, req-count, VIDEO_MAX_FRAME); - num_buffers = max_t(unsigned int, req-count, q-min_buffers_needed); + num_buffers = max_t(unsigned int, num_buffers, q-min_buffers_needed); memset(q-plane_sizes, 0, sizeof(q-plane_sizes)); memset(q-alloc_ctx, 0, sizeof(q-alloc_ctx)); q-memory = req-memory; -- 2.0.0.rc0 -- 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] vb2: drop queued buffers while q-start_streaming_called is still set
Otherwise yet another warning will trigger in vb2_buffer_done.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/v4l2-core/videobuf2-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 4d4f6ba..bdca528 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2088,8 +2088,6 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
if (q-start_streaming_called)
call_void_qop(q, stop_streaming, q);
q-streaming = 0;
- q-start_streaming_called = 0;
- q-queued_count = 0;
if (WARN_ON(atomic_read(q-owned_by_drv_count))) {
for (i = 0; i q-num_buffers; ++i)
@@ -2098,6 +2096,8 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
/* Must be zero now */
WARN_ON(atomic_read(q-owned_by_drv_count));
}
+ q-start_streaming_called = 0;
+ q-queued_count = 0;
/*
* Remove all buffers from videobuf's list...
--
2.0.0.rc0
--
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] vb2: fix num_buffers calculation if req-count VIDEO_MAX_FRAMES
On 05/09/2014 05:32 PM, Philipp Zabel wrote: Signed-off-by: Philipp Zabel p.za...@pengutronix.de Reviewed-by: Hans Verkuil hans.verk...@cisco.com Regards, Hans --- drivers/media/v4l2-core/videobuf2-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index 40024d7..4d4f6ba 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -905,7 +905,7 @@ static int __reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req) * Make sure the requested values and current defaults are sane. */ num_buffers = min_t(unsigned int, req-count, VIDEO_MAX_FRAME); - num_buffers = max_t(unsigned int, req-count, q-min_buffers_needed); + num_buffers = max_t(unsigned int, num_buffers, q-min_buffers_needed); memset(q-plane_sizes, 0, sizeof(q-plane_sizes)); memset(q-alloc_ctx, 0, sizeof(q-alloc_ctx)); q-memory = req-memory; -- 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] vb2: drop queued buffers while q-start_streaming_called is still set
On 05/09/2014 05:32 PM, Philipp Zabel wrote:
Otherwise yet another warning will trigger in vb2_buffer_done.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Duplicate of: https://patchwork.linuxtv.org/patch/23723/
I'm setting your patch to superseded in patchwork.
Regards,
Hans
---
drivers/media/v4l2-core/videobuf2-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 4d4f6ba..bdca528 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2088,8 +2088,6 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
if (q-start_streaming_called)
call_void_qop(q, stop_streaming, q);
q-streaming = 0;
- q-start_streaming_called = 0;
- q-queued_count = 0;
if (WARN_ON(atomic_read(q-owned_by_drv_count))) {
for (i = 0; i q-num_buffers; ++i)
@@ -2098,6 +2096,8 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
/* Must be zero now */
WARN_ON(atomic_read(q-owned_by_drv_count));
}
+ q-start_streaming_called = 0;
+ q-queued_count = 0;
/*
* Remove all buffers from videobuf's list...
--
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] radio-bcm2048.c: fix wrong overflow check
On Monday 05 May 2014 15:34:29 Jiri Kosina wrote: On Tue, 22 Apr 2014, Dan Carpenter wrote: From: Pali Rohár pali.ro...@gmail.com This patch fixes an off by one check in bcm2048_set_region(). Reported-by: Dan Carpenter dan.carpen...@oracle.com Signed-off-by: Pali Rohár pali.ro...@gmail.com Signed-off-by: Pavel Machek pa...@ucw.cz Signed-off-by: Dan Carpenter dan.carpen...@oracle.com --- v2: Send it to the correct list. Re-work the changelog. This patch has been floating around for four months but Pavel and Pali are knuckle-heads and don't know how to use get_maintainer.pl so they never send it to linux-media. Also Pali doesn't give reporter credit and Pavel steals authorship credit. Also when you try explain to them about how to send patches correctly they complain that they have been trying but it is too much work so now I have to do it. During the past four months thousands of other people have been able to send patches in the correct format to the correct list but it is too difficult for Pavel and Pali... *sigh*. Seems like it's not in linux-next as of today, so I am taking it now. Thanks, I still do not see this patch in torvalds branch... So what is needed to include this security buffer overflow patch into mainline stable kernels? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH v2] radio-bcm2048.c: fix wrong overflow check
On 05/09/2014 06:10 PM, Pali Rohár wrote: On Monday 05 May 2014 15:34:29 Jiri Kosina wrote: On Tue, 22 Apr 2014, Dan Carpenter wrote: From: Pali Rohár pali.ro...@gmail.com This patch fixes an off by one check in bcm2048_set_region(). Reported-by: Dan Carpenter dan.carpen...@oracle.com Signed-off-by: Pali Rohár pali.ro...@gmail.com Signed-off-by: Pavel Machek pa...@ucw.cz Signed-off-by: Dan Carpenter dan.carpen...@oracle.com --- v2: Send it to the correct list. Re-work the changelog. This patch has been floating around for four months but Pavel and Pali are knuckle-heads and don't know how to use get_maintainer.pl so they never send it to linux-media. Also Pali doesn't give reporter credit and Pavel steals authorship credit. Also when you try explain to them about how to send patches correctly they complain that they have been trying but it is too much work so now I have to do it. During the past four months thousands of other people have been able to send patches in the correct format to the correct list but it is too difficult for Pavel and Pali... *sigh*. Seems like it's not in linux-next as of today, so I am taking it now. Thanks, I still do not see this patch in torvalds branch... So what is needed to include this security buffer overflow patch into mainline stable kernels? Today I collected a pile of pending patches including this one and posted a pull request on the linux-media mailinglist. Once Mauro picks it up it will appear in our tree and then linux-next. He's been travelling for the past two weeks, so he'll have a sizable backlog. Just be patient, it's not forgotten. 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: [RFC] Fix interrupted recording with Hauppauge HD-PVR
On 05/09/14 06:08, Hans Verkuil wrote:
On 04/08/2014 07:07 PM, Ryley Angus wrote:
Hi Kyle.
It may be possible that the delay in acceptable grace periods is due to a
difference in our input AV sources more so than the Hauppauge units
themselves. I'm wondering if it would be useful to control the timeout
period via a module parameter that defaults to 3 seconds perhaps?
It is OK for both of you if I set the timeout to 3 seconds in my patch? So it
will use msecs_to_jiffies(3000));.
If you can both confirm that that works, then I'll merge the patch.
Sorry for being late with my reply, it's been busy lately :-)
Regards,
Hans
As far as the issues with concatenated output, I've just looked at the files
containing a channel change and realized that VLC does show the duration as
0:00. Seeking with a keyboard isn't functional. Seeking with the timeline
and a mouse is fine. Avidemux seems to have trouble editing the file. If I
cut a section from a file that is from a single recording session it's
duration is correct, sync is correct and audio properties are correct. I
cannot cut across segments. MPC-HC also has duration issues with the
recording.
If I run the recordings through ffmpeg -fflags +genpts -I INPUT -c:v copy
-c:a copy OUTPUT, the resultant file duration is correct in VLC, I can
seek with the keyboard and mouse and editing is perfect with Avidemux. But
would it be better if the device just cleanly stopped recording instead of
automatically resuming? Or, continuing with the module parameters idea,
could we determine whether or not it will automatically restart based off a
module parameter?
I feel bad for not noticing the VLC issues earlier, but I mostly just use
VLC to broadcast the recordings through my home network to client instances
of VLC. This works well, but obviously seeking isn't relevant.
ryley
-Original Message-
From: Keith Pyle [mailto:kp...@austin.rr.com]
Sent: Wednesday, April 09, 2014 12:28 AM
To: Ryley Angus; 'Hans Verkuil'; linux-media@vger.kernel.org
Subject: Re: [RFC] Fix interrupted recording with Hauppauge HD-PVR
On 04/07/14 22:32, Ryley Angus wrote:
Thanks Hans for getting back to me.
I've been trying out your patch and I found the device wasn't actually
restarting the streaming/recording properly after a channel change. I
changed msecs_to_jiffies(500)) to msecs_to_jiffies(1000)) and had
the same issue, but msecs_to_jiffies(2000))
seems to be working well. I'll let it keep going for a few more hours,
but at the moment it seems to be working well. The recordings can be
ended without anything hanging, and turning off the device ends the
recording properly (mine neglected this occurrence).
I'll let you know if I have any more issues,
ryley
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Tuesday, April 08, 2014 12:07 AM
To: Ryley Angus; linux-media@vger.kernel.org
Subject: Re: [RFC] Fix interrupted recording with Hauppauge HD-PVR
Hi Ryley,
Thank you for the patch. Your analysis seems sound. The patch is
actually not bad for a first attempt, but I did it a bit differently.
Can you test my patch?
Regards,
Hans
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c
b/drivers/media/usb/hdpvr/hdpvr-video.c
index 0500c417..a61373e 100644
--- a/drivers/media/usb/hdpvr/hdpvr-video.c
+++ b/drivers/media/usb/hdpvr/hdpvr-video.c
@@ -454,6 +454,8 @@ static ssize_t hdpvr_read(struct file *file, char
__user *buffer, size_t count,
if (buf-status != BUFSTAT_READY
dev-status != STATUS_DISCONNECTED) {
+ int err;
+
/* return nonblocking */
if (file-f_flags O_NONBLOCK) {
if (!ret)
@@ -461,11 +463,23 @@ static ssize_t hdpvr_read(struct file *file,
char __user *buffer, size_t count,
goto err;
}
- if (wait_event_interruptible(dev-wait_data,
- buf-status == BUFSTAT_READY))
{
- ret = -ERESTARTSYS;
+ err =
wait_event_interruptible_timeout(dev-wait_data,
+ buf-status == BUFSTAT_READY,
+ msecs_to_jiffies(500));
+ if (err 0) {
+ ret = err;
goto err;
}
+ if (!err) {
+ v4l2_dbg(MSG_INFO, hdpvr_debug,
dev-v4l2_dev,
+ timeout: restart streaming\n);
+ hdpvr_stop_streaming(dev);
+ err = hdpvr_start_streaming(dev);
+ if (err) {
+ ret = err;
+ goto err;
+
Re: [PATCH] Fix _IOC_TYPECHECK sparse error
On Fri, 09 May 2014 09:43:58 +0200 Hans Verkuil hverk...@xs4all.nl wrote: Andrew, can you merge this for 3.15 or 3.16 (you decide)? While it fixes a sparse error for the media subsystem, it is not really appropriate to go through our media tree. Thanks, Hans When running sparse over drivers/media/v4l2-core/v4l2-ioctl.c I get these errors: drivers/media/v4l2-core/v4l2-ioctl.c:2043:9: error: bad integer constant expression drivers/media/v4l2-core/v4l2-ioctl.c:2044:9: error: bad integer constant expression drivers/media/v4l2-core/v4l2-ioctl.c:2045:9: error: bad integer constant expression drivers/media/v4l2-core/v4l2-ioctl.c:2046:9: error: bad integer constant expression etc. The root cause of that turns out to be in include/asm-generic/ioctl.h: #include uapi/asm-generic/ioctl.h /* provoke compile error for invalid uses of size argument */ extern unsigned int __invalid_size_argument_for_IOC; #define _IOC_TYPECHECK(t) \ ((sizeof(t) == sizeof(t[1]) \ sizeof(t) (1 _IOC_SIZEBITS)) ? \ sizeof(t) : __invalid_size_argument_for_IOC) If it is defined as this (as is already done if __KERNEL__ is not defined): #define _IOC_TYPECHECK(t) (sizeof(t)) then all is well with the world. This patch allows sparse to work correctly. --- a/include/asm-generic/ioctl.h +++ b/include/asm-generic/ioctl.h @@ -3,10 +3,15 @@ #include uapi/asm-generic/ioctl.h +#ifdef __CHECKER__ +#define _IOC_TYPECHECK(t) (sizeof(t)) +#else /* provoke compile error for invalid uses of size argument */ extern unsigned int __invalid_size_argument_for_IOC; #define _IOC_TYPECHECK(t) \ ((sizeof(t) == sizeof(t[1]) \ sizeof(t) (1 _IOC_SIZEBITS)) ? \ sizeof(t) : __invalid_size_argument_for_IOC) +#endif + #endif /* _ASM_GENERIC_IOCTL_H */ Can't we use BUILD_BUG_ON() here? That's neater, more standard and BUILD_BUG_ON() already has sparse handling. -- 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: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sat May 10 04:00:17 CEST 2014 git branch: test git hash: 393cbd8dc532c1ebed60719da8d379f50d445f28 gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.14-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK 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: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-i686: OK linux-3.14-i686: OK linux-3.15-rc1-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK linux-3.13-x86_64: OK linux-3.14-x86_64: OK linux-3.15-rc1-x86_64: OK apps: OK spec-git: OK sparse version: v0.5.0-11-g38d1124 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
