Re: cx23885: Add basic analog radio support
Em Fri, 04 Oct 2013 15:56:23 -0300
Alfredo Jesús Delaiti alfredodela...@netscape.net escreveu:
Hi all
El 14/01/12 15:25, Miroslav Slugeň escribió:
New version of patch, fixed video modes for DVR3200 tuners and working
audio mux.
I tested this patch (https://linuxtv.org/patch/9498/) with the latest
versions of git (September 28, 2013) with my TV card (Mygica X8507) and
it works.
I found some issue, although it may be through a bad implementation of mine.
Details of them:
1) Some warning when compiling
...
CC [M]
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/cx23885-video.o
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/cx23885-video.c:1910:8:
: initialization from incompatible pointer type [enabled by default]
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/cx23885-video.c:1910:8:
warning: (near initialization for 'radio_ioctl_ops.vidioc_s_tuner')
[enabled by default]
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/cx23885-video.c:1911:8:
warning: initialization from incompatible pointer type [enabled by default]
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/cx23885-video.c:1911:8:
warning: (near initialization for 'radio_ioctl_ops.vidioc_s_audio')
[enabled by default]
CC [M] /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/cx23885-vbi.o
...
static const struct v4l2_ioctl_ops radio_ioctl_ops = {
.vidioc_s_tuner = radio_s_tuner, /* line 1910 */
.vidioc_s_audio = radio_s_audio, /* line 1911 */
2)
No reports signal strength or stereo signal with KRadio. XC5000 neither
reported (modprobe xc5000 debug=1). Maybe a feature XC5000.
To listen in stereo, sometimes, you have to turn on the Digital TV then
Analog TV and then radio.
3)
To listen Analog TV I need changed to NTSC standard and then PAL-Nc (the
norm in my country is PAL-Nc). If I leave the tune in NTSC no problem
with sound.
The patch (https://linuxtv.org/patch/9505/) corrects the latter, if used
tvtime with xawtv not always.
If I see-Digital TV (ISDB-T), then so as to listen the radio I have
first put the TV-Analog, because I hear very low and a strong white noise.
The latter is likely to be corrected by resetting the tuner, I have to
study it more.
I put below attached the patch applied to the plate: X8507.
Have you done any update of this patch?
Hi Alfredo,
My understanding is that the patch you've enclosed is incomplete and
depends on Miroslav's patch.
As he have you his ack to rework on it, could you please prepare a
patch series addressing the above comments for us to review?
Than
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] em28xx: fix device initialization in em28xx_v4l2_open() for radio and VBI mode
Em Thu, 10 Oct 2013 21:20:24 +0200
Frank Schäfer fschaefer@googlemail.com escreveu:
- bail out on unsupported VFL_TYPE
- em28xx_set_mode() needs to be called for VBI and radio mode, too
- em28xx_wake_i2c() needs to be called for VBI and radio mode, too
- em28xx_resolution_set() also needs to be called for VBI
Compilation tested only and should be reviewed thoroughly !
Makes sense to me. I don't remember any real issue with radio and I2C
devices, but, in theory, that could happen with xc3028/5000 tuners.
I can't test it right now, through. So, I'll delay it for when I would
have some time for testing.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-video.c | 17 +++--
1 Datei geändert, 11 Zeilen hinzugefügt(+), 6 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index fc5d60e..962f4b2 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -1570,13 +1570,16 @@ static int em28xx_v4l2_open(struct file *filp)
case VFL_TYPE_VBI:
fh_type = V4L2_BUF_TYPE_VBI_CAPTURE;
break;
+ case VFL_TYPE_RADIO:
+ break;
+ default:
+ return -EINVAL;
}
em28xx_videodbg(open dev=%s type=%s users=%d\n,
video_device_node_name(vdev), v4l2_type_names[fh_type],
dev-users);
-
if (mutex_lock_interruptible(dev-lock))
return -ERESTARTSYS;
fh = kzalloc(sizeof(struct em28xx_fh), GFP_KERNEL);
@@ -1590,15 +1593,17 @@ static int em28xx_v4l2_open(struct file *filp)
fh-type = fh_type;
filp-private_data = fh;
- if (fh-type == V4L2_BUF_TYPE_VIDEO_CAPTURE dev-users == 0) {
+ if (dev-users == 0) {
em28xx_set_mode(dev, EM28XX_ANALOG_MODE);
- em28xx_resolution_set(dev);
- /* Needed, since GPIO might have disabled power of
-some i2c device
+ if (vdev-vfl_type != VFL_TYPE_RADIO)
+ em28xx_resolution_set(dev);
+
+ /*
+ * Needed, since GPIO might have disabled power of
+ * some i2c devices
*/
em28xx_wake_i2c(dev);
-
}
if (vdev-vfl_type == VFL_TYPE_RADIO) {
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] Notes on the Media summit 2013-10-23
Notes on the Media summit 2013-10-23 List of Participants: Ricardo Ribalda - Qtechnology Hans Verkuil - Cisco Sakari Ailus - Intel Mauro Carvalho Chehab - Samsung Kieran Kunhya - Open Broadcast Systems Sylwester Nawrocki - Samsung Guennadi Liakhovetski Benjamin Gaignard - ST Microelectronics Hugues Fruchet - ST Microelectronics Andrzej Hajda - Samsung Peter Senna Tschudin - Coccinelle? Hans de Goede - Red Hat Michael Krufky - Samsung Paul Walmsley - Nvidia Laurent Pinchart - Ideas on board 1. Mauro Chehab: is the submaintainer arrangement working? General consensus is that it is working. Hans pointed that the commits ML is not working. Mauro will check what's happening at LinuxTV website after returning back. Hans also pointed that patches for the rcX kernel aren't always picked up quickly enough. Mauro says this is due to his move to Samsung which took a lot of his time. This should improve. 2. Ricardo Ribalda Delgado: Multiple selections For a more flexible cropping selection a new extended rectangle struct has to be added with possibly negative top and left offsets. This would allow to explore capabilities of industry grade sensors, that can be configured to crop multiple rectangles from the input area. Sylwester: an alternative approach would be to use indexed windows. The issue of atomicity should also be addressed. Ricardo is proposing to add the capability of adding more than one selection areas - No objections so far. - Helper functions to detect if rectangles overlap or are contained on other rectangles are needed. - Documentation changes for V4L2 subdev selection API. Special care needs to be taken for too few or too many rectangles. In both cases the rectangles field should be set to the actual number of allowed rectangles. In the too few case an error should be returned, in the too many case the extra rects should just be ignored. Mauro thinks that it will be useful to see if the width/height fields in v4l2_rect can be changes to u32 instead of s32: will require code review of drivers. 3. Hans Verkuil: colorspaces - Colorspace: limited/full range Draft presentation for all these topics: http://hverkuil.home.xs4all.nl/presentations/summit2013.odp Proposal accepted, although the _SRGB_LIM name might need to be improved, although no alternatives were given. ALso mention in the docs that S_FMT can overwrite the colorspace for output devices if the selected one isn't supported. 4. Kieran Kunhya: SDI The biggest problem is separate audio and video file descriptors. Audio data is transfered in the video blanking areas, where should they be separated - in the kernel, using multiple planes, or in the user-space? One possibility is to consider this data as similar to an uncompressed MPEG datastream. It might be possible to use hardware-specific time-stamps to synchronise the data. Separate ALSA and V4L2 nodes are inherently problematic since they do not keep the audio and video together. Another possibility is to offer two APIs: for professional applications, where data is perfectly synchronised, and separate audio and video for human consumption. A format for professional applications were VBI/HBI/Video is all captured in one big frame is OK (provided an open source lib is created to parse it). The proposal for using a multiplanar API where the audio is in a separate plane ran into opposition: the alsa devs should be asked whether it is possible to return the audio data in such a way that it can be exactly associated with the corresponding video buffer. This also requires that the audio can be variable length since for NTSC the size of the audio data will alternate between frames. If this is possible, then the alsa API can be used and things can still remain in sync. UPDATE: Mauro and Hans had some discussions with Takashi (ALSA Maintainer), in order to have some shed about the possibilities. We're planning to discuss more on this Friday's lunch. 5. Paul Walmsley on behalf of Bryan Wu: LED / flash API integration Currently functionality is accessible from two APIs: LED and flash. A proposal is presented to put V4L2 flash subdev on top of LED core. It would be better not to go via the LED trigger layer. - One to one mapping between LED chips and V4L2 sub-devices. This probably means the LED flash driver needs to register the sub-device. - Two interfaces: should the sysfs interface be disabled if an application chose the flash mode on V4L2 API? The flash driver has no knowledge of streaming state or capturing frames. - Same requirements as for the LED API as the V4L2 flash API needs (LED flashes only). - Currently there's no V4L2 API to put a sensor into a flash mode to automatically trigger a flash pin. This would have to be handled. It is also possible, that a V4L2 application uses a sensor, but only puts it into a flash mode (single-shot mode) for several frames. The LED might therefore have to be made busy always when the sensor is
Re: [ANNOUNCE] Notes on the Media summit 2013-10-23
Em Thu, 31 Oct 2013 09:27:27 -0200 Mauro Carvalho Chehab m.che...@samsung.com escreveu: 1. Mauro Chehab: is the submaintainer arrangement working? General consensus is that it is working. Hans pointed that the commits ML is not working. Mauro will check what's happening at LinuxTV website after returning back. Fixed. The issue was due to my email change. The mailbomb script has a logic that checks if the patch committer is myself, in order to prevent mailbomb when pulling back from Linus tree. As I'm now using my email @samsung to commit patches, that logic was not sending emails anymore to linuxtv-comm...@linuxtv.org. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 19/51] DMA-API: media: dt3155v4l: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Hi Russell, Em Mon, 30 Sep 2013 13:57:47 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On 09/19/2013 11:44 PM, Russell King wrote: Replace the following sequence: dma_set_mask(dev, mask); dma_set_coherent_mask(dev, mask); with a call to the new helper dma_set_mask_and_coherent(). Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Hans Verkuil hans.verk...@cisco.com Somehow, I lost your original post (I got unsubscribed on a few days from all vger mailing lists at the end of september). I suspect that you want to sent this via your tree, right? If so: Acked-by: Mauro Carvalho Chehab m.che...@samsung.com Regards, Hans --- drivers/staging/media/dt3155v4l/dt3155v4l.c |5 + 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/drivers/staging/media/dt3155v4l/dt3155v4l.c b/drivers/staging/media/dt3155v4l/dt3155v4l.c index 90d6ac4..081407b 100644 --- a/drivers/staging/media/dt3155v4l/dt3155v4l.c +++ b/drivers/staging/media/dt3155v4l/dt3155v4l.c @@ -901,10 +901,7 @@ dt3155_probe(struct pci_dev *pdev, const struct pci_device_id *id) int err; struct dt3155_priv *pd; - err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32)); - if (err) - return -ENODEV; - err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32)); + err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32)); if (err) return -ENODEV; pd = kzalloc(sizeof(*pd), GFP_KERNEL); -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v2][ 13/37] staging: imx-drm: Add RGB666 support for parallel display
Em Thu, 17 Oct 2013 17:02:11 +0200
Denis Carikli de...@eukrea.com escreveu:
Support the RGB666 format on the IPUv3 parallel display.
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: devicet...@vger.kernel.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: driverdev-de...@linuxdriverproject.org
Cc: David Airlie airl...@linux.ie
Cc: dri-de...@lists.freedesktop.org
Cc: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: linux-media@vger.kernel.org
Cc: Sascha Hauer ker...@pengutronix.de
Cc: linux-arm-ker...@lists.infradead.org
Cc: Eric Bénard e...@eukrea.com
Signed-off-by: Denis Carikli de...@eukrea.com
It seems better to apply this one together with the other DRM patches via
DRM tree. So:
Acked-by: Mauro Carvalho Chehab m.che...@samsung.com
---
.../bindings/staging/imx-drm/fsl-imx-drm.txt |2 +-
drivers/staging/imx-drm/ipu-v3/ipu-dc.c|9 +
drivers/staging/imx-drm/parallel-display.c |2 ++
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
index b876d49..2d24425 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -29,7 +29,7 @@ Required properties:
- crtc: the crtc this display is connected to, see below
Optional properties:
- interface_pix_fmt: How this display is connected to the
- crtc. Currently supported types: rgb24, rgb565, bgr666
+ crtc. Currently supported types: rgb24, rgb565, bgr666, rgb666
- edid: verbatim EDID data block describing attached display.
- ddc: phandle describing the i2c bus handling the display data
channel
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
index 21bf1c8..c84ad22 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
@@ -91,6 +91,7 @@ enum ipu_dc_map {
IPU_DC_MAP_RGB565,
IPU_DC_MAP_GBR24, /* TVEv2 */
IPU_DC_MAP_BGR666,
+ IPU_DC_MAP_RGB666,
};
struct ipu_dc {
@@ -152,6 +153,8 @@ static int ipu_pixfmt_to_map(u32 fmt)
return IPU_DC_MAP_GBR24;
case V4L2_PIX_FMT_BGR666:
return IPU_DC_MAP_BGR666;
+ case V4L2_PIX_FMT_RGB666:
+ return IPU_DC_MAP_RGB666;
default:
return -EINVAL;
}
@@ -395,6 +398,12 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 1, 11, 0xfc); /* green */
ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 2, 17, 0xfc); /* red */
+ /* rgb666 */
+ ipu_dc_map_clear(priv, IPU_DC_MAP_BGR666);
+ ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 2, 17, 0xfc); /* red */
+ ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 1, 11, 0xfc); /* green */
+ ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 0, 5, 0xfc); /* blue */
+
return 0;
}
diff --git a/drivers/staging/imx-drm/parallel-display.c
b/drivers/staging/imx-drm/parallel-display.c
index c04b017..1c8f63f 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -238,6 +238,8 @@ static int imx_pd_probe(struct platform_device *pdev)
imxpd-interface_pix_fmt = V4L2_PIX_FMT_RGB565;
else if (!strcmp(fmt, bgr666))
imxpd-interface_pix_fmt = V4L2_PIX_FMT_BGR666;
+ else if (!strcmp(fmt, rgb666))
+ imxpd-interface_pix_fmt = V4L2_PIX_FMT_RGB666;
}
imxpd-dev = pdev-dev;
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v2][ 04/37] [media] v4l2: add new V4L2_PIX_FMT_RGB666 pixel format.
Em Thu, 17 Oct 2013 17:02:02 +0200
Denis Carikli de...@eukrea.com escreveu:
That new macro is needed by the imx_drm staging driver
for supporting the QVGA display of the eukrea-cpuimx51 board.
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: devicet...@vger.kernel.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: driverdev-de...@linuxdriverproject.org
Cc: David Airlie airl...@linux.ie
Cc: dri-de...@lists.freedesktop.org
Cc: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: linux-media@vger.kernel.org
Cc: Sascha Hauer ker...@pengutronix.de
Cc: linux-arm-ker...@lists.infradead.org
Cc: Eric Bénard e...@eukrea.com
Signed-off-by: Denis Carikli de...@eukrea.com
It seems better to apply this one together with the other DRM patches via
DRM tree. So:
Acked-by: Mauro Carvalho Chehab m.che...@samsung.com
---
include/uapi/linux/videodev2.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 437f1b0..e8ff410 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -294,6 +294,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_RGB555X v4l2_fourcc('R', 'G', 'B', 'Q') /* 16
RGB-5-5-5 BE */
#define V4L2_PIX_FMT_RGB565X v4l2_fourcc('R', 'G', 'B', 'R') /* 16
RGB-5-6-5 BE */
#define V4L2_PIX_FMT_BGR666 v4l2_fourcc('B', 'G', 'R', 'H') /* 18
BGR-6-6-6 */
+#define V4L2_PIX_FMT_RGB666 v4l2_fourcc('R', 'G', 'B', 'H') /* 18
RGB-6-6-6 */
#define V4L2_PIX_FMT_BGR24 v4l2_fourcc('B', 'G', 'R', '3') /* 24
BGR-8-8-8 */
#define V4L2_PIX_FMT_RGB24 v4l2_fourcc('R', 'G', 'B', '3') /* 24
RGB-8-8-8 */
#define V4L2_PIX_FMT_BGR32 v4l2_fourcc('B', 'G', 'R', '4') /* 32
BGR-8-8-8-8 */
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] v4l2-dev: Add tracepoints for QBUF and DQBUF
Hi Wade, Em Fri, 18 Oct 2013 08:03:21 -0700 Wade Farnsworth wade_farnswo...@mentor.com escreveu: Greetings, We've found this patch helpful for making some simple performance measurements on V4L2 systems using the standard Linux tracers (FTRACE, LTTng, etc.), and were wondering if the larger community would find it useful to have this in mainline as well. This patch adds two tracepoints for the VIDIOC_DQBUF and VIDIOC_QBUF ioctls. We've identified two ways we can use this information to measure performance, though this is likely not an exhaustive list: 1. Measuring the difference in timestamps between QBUF events on a display device provides a throughput (framerate) measurement for the display. 2. Measuring the difference between the timestamps on a DQBUF event for a capture device and a corresponding timestamp on a QBUF event on a display device provides a rough approximation of the latency of that particular frame. However, this tends to only work for simple video pipelines where captured and displayed frames can be correlated in such a fashion. Comments are welcome. If there is interest, I'll post another patch suitable for merge. I like the idea of adding those tracepoints. See my comments below. Signed-off-by: Wade Farnsworth wade_farnswo...@mentor.com --- drivers/media/v4l2-core/v4l2-dev.c |9 ++ include/trace/events/v4l2.h| 48 2 files changed, 57 insertions(+), 0 deletions(-) create mode 100644 include/trace/events/v4l2.h diff --git a/drivers/media/v4l2-core/v4l2-dev.c b/drivers/media/v4l2-core/v4l2-dev.c index b5c..1cc1749 100644 --- a/drivers/media/v4l2-core/v4l2-dev.c +++ b/drivers/media/v4l2-core/v4l2-dev.c @@ -31,6 +31,10 @@ #include media/v4l2-device.h #include media/v4l2-ioctl.h + +#define CREATE_TRACE_POINTS +#include trace/events/v4l2.h + #define VIDEO_NUM_DEVICES256 #define VIDEO_NAME video4linux @@ -391,6 +395,11 @@ static long v4l2_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) } else ret = -ENOTTY; + if (cmd == VIDIOC_DQBUF) + trace_v4l2_dqbuf(vdev-minor, (struct v4l2_buffer *)arg); + else if (cmd == VIDIOC_QBUF) + trace_v4l2_qbuf(vdev-minor, (struct v4l2_buffer *)arg); + return ret; } diff --git a/include/trace/events/v4l2.h b/include/trace/events/v4l2.h new file mode 100644 index 000..1697441 --- /dev/null +++ b/include/trace/events/v4l2.h @@ -0,0 +1,48 @@ +#undef TRACE_SYSTEM +#define TRACE_SYSTEM v4l2 + +#if !defined(_TRACE_V4L2_H) || defined(TRACE_HEADER_MULTI_READ) +#define _TRACE_V4L2_H + +#include linux/tracepoint.h + +TRACE_EVENT(v4l2_dqbuf, + TP_PROTO(int minor, struct v4l2_buffer *buf), + + TP_ARGS(minor, buf), + + TP_STRUCT__entry( + __field(int, minor) + __field(s64, ts) + ), + + TP_fast_assign( + __entry-minor = minor; + __entry-ts = timeval_to_ns(buf-timestamp); + ), + + TP_printk(%d [%lld], __entry-minor, __entry-ts) +); + +TRACE_EVENT(v4l2_qbuf, + TP_PROTO(int minor, struct v4l2_buffer *buf), + + TP_ARGS(minor, buf), + + TP_STRUCT__entry( + __field(int, minor) + __field(s64, ts) + ), + + TP_fast_assign( + __entry-minor = minor; + __entry-ts = timeval_to_ns(buf-timestamp); On both events, you're only decoding the buffer timestamp. I think you should also decode the other metadata there. For example, on some devices, the dqbuf order is different than the qbuf one. One may need to associate both, in order to be able to time how much time a buffer takes to be filled. + ), + + TP_printk(%d [%lld], __entry-minor, __entry-ts) +); + +#endif /* if !defined(_TRACE_V4L2_H) || defined(TRACE_HEADER_MULTI_READ) */ + +/* This part must be outside protection */ +#include trace/define_trace.h -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] videobuf2: Add missing lock held on vb2_fop_relase
Em Sat, 19 Oct 2013 18:07:57 +0200
Ricardo Ribalda ricardo.riba...@gmail.com escreveu:
vb2_fop_relase does not held the lock although it is modifying the
queue-owner field.
This could lead to race conditions on the vb2_perform_io function
when multiple applications are accessing the video device via
read/write API:
[ 308.297741] BUG: unable to handle kernel NULL pointer dereference at
0260
[ 308.297759] IP: [a07a9fd2] vb2_perform_fileio+0x372/0x610
[videobuf2_core]
[ 308.297794] PGD 159719067 PUD 158119067 PMD 0
[ 308.297812] Oops: #1 SMP
[ 308.297826] Modules linked in: qt5023_video videobuf2_dma_sg
qtec_xform videobuf2_vmalloc videobuf2_memops videobuf2_core
qtec_white qtec_mem gpio_xilinx qtec_cmosis qtec_pcie fglrx(PO)
spi_xilinx spi_bitbang qt5023
[ 308.297888] CPU: 1 PID: 2189 Comm: java Tainted: P O 3.11.0-qtec-standard #1
[ 308.297919] Hardware name: QTechnology QT5022/QT5022, BIOS
PM_2.1.0.309 X64 05/23/2013
[ 308.297952] task: 8801564e1690 ti: 88014dc02000 task.ti:
88014dc02000
[ 308.297962] RIP: 0010:[a07a9fd2] [a07a9fd2]
vb2_perform_fileio+0x372/0x610 [videobuf2_core]
[ 308.297985] RSP: 0018:88014dc03df8 EFLAGS: 00010202
[ 308.297995] RAX: RBX: 880158a23000 RCX:
dead00100100
[ 308.298003] RDX: RSI: dead00200200 RDI:
[ 308.298012] RBP: 88014dc03e58 R08: R09:
0001
[ 308.298020] R10: ea00051e8380 R11: 88014dc03fd8 R12:
880158a23070
[ 308.298029] R13: 8801549040b8 R14: 00198000 R15:
01887e60
[ 308.298040] FS: 7f65130d5700() GS:88015ed0()
knlGS:
[ 308.298049] CS: 0010 DS: ES: CR0: 80050033
[ 308.298057] CR2: 0260 CR3: 00015963 CR4:
07e0
[ 308.298064] Stack:
[ 308.298071] 880156416c00 00198000
88010001
[ 308.298087] 88014dc03f50 810a79ca 00020001
880154904718
[ 308.298101] 880156416c00 00198000 880154904338
88014dc03f50
[ 308.298116] Call Trace:
[ 308.298143] [a07aa3c4] vb2_read+0x14/0x20 [videobuf2_core]
[ 308.298198] [a07aa494] vb2_fop_read+0xc4/0x120 [videobuf2_core]
[ 308.298252] [8154ee9e] v4l2_read+0x7e/0xc0
[ 308.298296] [8116e639] vfs_read+0xa9/0x160
[ 308.298312] [8116e882] SyS_read+0x52/0xb0
[ 308.298328] [81784179] tracesys+0xd0/0xd5
[ 308.298335] Code: e5 d6 ff ff 83 3d be 24 00 00 04 89 c2 4c 8b 45 b0
44 8b 4d b8 0f 8f 20 02 00 00 85 d2 75 32 83 83 78 03 00 00 01 4b 8b
44 c5 48 8b 88 60 02 00 00 85 c9 0f 84 b0 00 00 00 8b 40 58 89 c2 41
89
[ 308.298487] RIP [a07a9fd2] vb2_perform_fileio+0x372/0x610
[videobuf2_core]
[ 308.298507] RSP 88014dc03df8
[ 308.298514] CR2: 0260
[ 308.298526] ---[ end trace e8f01717c96d1e41 ]---
v2: Add bug found by Sylvester Nawrocki
fimc-capture and fimc-lite where calling vb2_fop_release with the lock held.
Therefore a new __vb2_fop_release function has been created to be used by
drivers that overload the release function.
Signed-off-by: Ricardo Ribalda ricardo.riba...@gmail.com
---
drivers/media/platform/exynos4-is/fimc-capture.c | 2 +-
drivers/media/platform/exynos4-is/fimc-lite.c| 2 +-
drivers/media/usb/em28xx/em28xx-video.c | 2 +-
drivers/media/v4l2-core/videobuf2-core.c | 18 +-
include/media/videobuf2-core.h | 2 ++
5 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c
b/drivers/media/platform/exynos4-is/fimc-capture.c
index fb27ff7..c38d247c 100644
--- a/drivers/media/platform/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/exynos4-is/fimc-capture.c
@@ -549,7 +549,7 @@ static int fimc_capture_release(struct file *file)
vc-streaming = false;
}
- ret = vb2_fop_release(file);
+ ret = __vb2_fop_release(file, true);
if (close) {
clear_bit(ST_CAPT_BUSY, fimc-state);
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c
b/drivers/media/platform/exynos4-is/fimc-lite.c
index e5798f7..021d804 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -546,7 +546,7 @@ static int fimc_lite_release(struct file *file)
mutex_unlock(entity-parent-graph_mutex);
}
- vb2_fop_release(file);
+ __vb2_fop_release(file, true);
pm_runtime_put(fimc-pdev-dev);
clear_bit(ST_FLITE_SUSPENDED, fimc-state);
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index 9d10334..6a5c147 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -1664,7 +1664,7 @@ static int
Re: [Patch v2][ 04/37] [media] v4l2: add new V4L2_PIX_FMT_RGB666 pixel format.
On Thursday 31 October 2013 11:18:06 Mauro Carvalho Chehab wrote:
Em Thu, 17 Oct 2013 17:02:02 +0200
Denis Carikli de...@eukrea.com escreveu:
That new macro is needed by the imx_drm staging driver
for supporting the QVGA display of the eukrea-cpuimx51 board.
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: devicet...@vger.kernel.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: driverdev-de...@linuxdriverproject.org
Cc: David Airlie airl...@linux.ie
Cc: dri-de...@lists.freedesktop.org
Cc: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: linux-media@vger.kernel.org
Cc: Sascha Hauer ker...@pengutronix.de
Cc: linux-arm-ker...@lists.infradead.org
Cc: Eric Bénard e...@eukrea.com
Signed-off-by: Denis Carikli de...@eukrea.com
It seems better to apply this one together with the other DRM patches via
DRM tree. So:
Acked-by: Mauro Carvalho Chehab m.che...@samsung.com
Actually, if I might, I'd like to nak this patch, as adding new pixel formats
requires updating the documentation as well (see
Documentation/DocBook/media/v4l/pixfmt*.xml).
---
include/uapi/linux/videodev2.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/videodev2.h
b/include/uapi/linux/videodev2.h index 437f1b0..e8ff410 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -294,6 +294,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_RGB555X v4l2_fourcc('R', 'G', 'B', 'Q') /* 16
RGB-5-5-5 BE */ #define V4L2_PIX_FMT_RGB565X v4l2_fourcc('R', 'G', 'B',
'R') /* 16 RGB-5-6-5 BE */ #define V4L2_PIX_FMT_BGR666
v4l2_fourcc('B', 'G', 'R', 'H') /* 18 BGR-6-6-6 */
+#define V4L2_PIX_FMT_RGB666 v4l2_fourcc('R', 'G', 'B', 'H') /* 18
RGB-6-6-6 */
#define V4L2_PIX_FMT_BGR24 v4l2_fourcc('B', 'G', 'R', '3') /* 24
BGR-8-8-8 */ #define V4L2_PIX_FMT_RGB24 v4l2_fourcc('R', 'G', 'B',
'3') /* 24 RGB-8-8-8 */ #define V4L2_PIX_FMT_BGR32
v4l2_fourcc('B', 'G', 'R', '4') /* 32 BGR-8-8-8-8 */
--
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 v2] videobuf2: Add missing lock held on vb2_fop_relase
On 31/10/13 14:42, Mauro Carvalho Chehab wrote:
Em Sat, 19 Oct 2013 18:07:57 +0200
Ricardo Ribalda ricardo.riba...@gmail.com escreveu:
vb2_fop_relase does not held the lock although it is modifying the
queue-owner field.
This could lead to race conditions on the vb2_perform_io function
when multiple applications are accessing the video device via
read/write API:
[...]
Signed-off-by: Ricardo Ribalda ricardo.riba...@gmail.com
---
drivers/media/platform/exynos4-is/fimc-capture.c | 2 +-
drivers/media/platform/exynos4-is/fimc-lite.c| 2 +-
drivers/media/usb/em28xx/em28xx-video.c | 2 +-
drivers/media/v4l2-core/videobuf2-core.c | 18 +-
include/media/videobuf2-core.h | 2 ++
5 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c
b/drivers/media/platform/exynos4-is/fimc-capture.c
index fb27ff7..c38d247c 100644
--- a/drivers/media/platform/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/exynos4-is/fimc-capture.c
@@ -549,7 +549,7 @@ static int fimc_capture_release(struct file *file)
vc-streaming = false;
}
-ret = vb2_fop_release(file);
+ret = __vb2_fop_release(file, true);
if (close) {
clear_bit(ST_CAPT_BUSY, fimc-state);
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c
b/drivers/media/platform/exynos4-is/fimc-lite.c
index e5798f7..021d804 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -546,7 +546,7 @@ static int fimc_lite_release(struct file *file)
mutex_unlock(entity-parent-graph_mutex);
}
-vb2_fop_release(file);
+__vb2_fop_release(file, true);
pm_runtime_put(fimc-pdev-dev);
clear_bit(ST_FLITE_SUSPENDED, fimc-state);
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index 9d10334..6a5c147 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -1664,7 +1664,7 @@ static int em28xx_v4l2_close(struct file *filp)
em28xx_videodbg(users=%d\n, dev-users);
mutex_lock(dev-lock);
-vb2_fop_release(filp);
+__vb2_fop_release(filp, false);
if (dev-users == 1) {
/* the device is already disconnect,
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 594c75e..ce309a8 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2619,16 +2619,32 @@ int vb2_fop_mmap(struct file *file, struct
vm_area_struct *vma)
}
EXPORT_SYMBOL_GPL(vb2_fop_mmap);
-int vb2_fop_release(struct file *file)
+int __vb2_fop_release(struct file *file, bool lock_is_held)
{
struct video_device *vdev = video_devdata(file);
+struct mutex *lock;
if (file-private_data == vdev-queue-owner) {
+if (lock_is_held)
+lock = NULL;
+else
+lock = vdev-queue-lock ?
+vdev-queue-lock : vdev-lock;
+if (lock)
+mutex_lock(lock);
vb2_queue_release(vdev-queue);
vdev-queue-owner = NULL;
+if (lock)
+mutex_unlock(lock);
}
return v4l2_fh_release(file);
}
+EXPORT_SYMBOL_GPL(__vb2_fop_release);
+
+int vb2_fop_release(struct file *file)
+{
+return __vb2_fop_release(file, false);
+}
EXPORT_SYMBOL_GPL(vb2_fop_release);
In general, when a symbol has both locked/unlocked versions, we
use the __symbol for unlocked versions (as the usage of the __symbol
requires the caller do do additional protection).
On this patch, (and on Sylwester's version) you're seeming to be doing
just the opposite. That sounds inconsistent with other Kernel symbols.
Actually the version with double underscore prefix in my proposed changes
doesn't take the lock internally (please see below). Hence it follows
the common convention you're ponting out.
Please either use that version or add a suffix (like _locked / __unlocked)
to allow a clearer understanding about what's the locked version.
Btw, Does it even make sense to have both options, or wouldn't be better
to just make sure that all drivers will do the same? My concern here is
with race conditions that may happen at device removal, if the lock is
released/retaken inside the routine that unbinds the driver.
Exactly for this reason, i.e. not needing to release and reacquire lock
in driver release() callback I suggested to have the
int __vb2_fop_release(struct file *file); version, for cases when drivers
use their custom handler and call __vb2_fop_release() from within it with
the lock already held.
static int _vb2_fop_release(struct file *file, bool locked)
{
struct video_device *vdev = video_devdata(file);
Vážení E-mail užívatela;
Vážení E-mail užívatela; Prekrocili ste 23432 boxy nastavit svoje Webová služba / Administrátor, a budete mat problémy pri odosielaní a prijímat e-maily, kým znova overit. Musíte aktualizovat kliknutím na odkaz nižšie a vyplnte údaje pre overenie vášho úctu Prosím, kliknite na odkaz nižšie alebo skopírovat vložit do e-prehliadac pre overenie Schránky. http://webmailupdate6786.jimdo.com/ Pozor! Ak tak neurobíte, budú mat obmedzený prístup k e-mailu schránky. Ak sa nepodarí aktualizovat svoj ??úcet do troch dní od aktualizácie oznámenia, bude váš úcet natrvalo uzavretá. S pozdravom, System Administrator -- 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.2 1/4] media: Add pad flag MEDIA_PAD_FL_MUST_CONNECT
Hi Sakari,
Thank you for the patch.
On Wednesday 16 October 2013 00:46:57 Sakari Ailus wrote:
Pads that set this flag must be connected by an active link for the entity
to stream.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Sylwester Nawrocki s.nawro...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Documentation/DocBook/media/v4l/media-ioc-enum-links.xml |9 +
include/uapi/linux/media.h |1 +
2 files changed, 10 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml
b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml index
355df43..cf85485 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml
@@ -134,6 +134,15 @@
entryOutput pad, relative to the entity. Output pads source data
and are origins of links./entry
/row
+ row
+ entryconstantMEDIA_PAD_FL_MUST_CONNECT/constant/entry
+ entryIf this flag is set and the pad is linked to any other
+ pad, then at least one of those links must be enabled for the
+ entity to be able to stream. There could be temporary reasons
+ (e.g. device configuration dependent) for the pad to need
+ enabled links even when this flag isn't set; the absence of the
+ flag doesn't imply there is none./entry
+ /row
/tbody
/tgroup
/table
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index ed49574..d847c76 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -98,6 +98,7 @@ struct media_entity_desc {
#define MEDIA_PAD_FL_SINK(1 0)
#define MEDIA_PAD_FL_SOURCE (1 1)
+#define MEDIA_PAD_FL_MUST_CONNECT(1 2)
struct media_pad_desc {
__u32 entity; /* entity ID */
--
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 v2.2 2/4] media: Check for active links on pads with MEDIA_PAD_FL_MUST_CONNECT flag
Hi Sakari,
Thank you for the patch.
On Wednesday 16 October 2013 00:48:17 Sakari Ailus wrote:
Do not allow streaming if a pad with MEDIA_PAD_FL_MUST_CONNECT flag is not
connected by an active link.
This patch makes it possible to avoid drivers having to check for the most
common case of link state validation: a sink pad that must be connected.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Tested-by: Sylwester Nawrocki s.nawro...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
I've taken the whole series in my tree and will push it upstream for v3.14.
---
drivers/media/media-entity.c | 41 ---
1 file changed, 34 insertions(+), 7 deletions(-)
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index 2c286c3..37c334e 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -235,6 +235,8 @@ __must_check int media_entity_pipeline_start(struct
media_entity *entity, media_entity_graph_walk_start(graph, entity);
while ((entity = media_entity_graph_walk_next(graph))) {
+ DECLARE_BITMAP(active, entity-num_pads);
+ DECLARE_BITMAP(has_no_links, entity-num_pads);
unsigned int i;
entity-stream_count++;
@@ -248,21 +250,46 @@ __must_check int media_entity_pipeline_start(struct
media_entity *entity, if (!entity-ops || !entity-ops-link_validate)
continue;
+ bitmap_zero(active, entity-num_pads);
+ bitmap_fill(has_no_links, entity-num_pads);
+
for (i = 0; i entity-num_links; i++) {
struct media_link *link = entity-links[i];
-
- /* Is this pad part of an enabled link? */
- if (!(link-flags MEDIA_LNK_FL_ENABLED))
- continue;
-
- /* Are we the sink or not? */
- if (link-sink-entity != entity)
+ struct media_pad *pad = link-sink-entity == entity
+ ? link-sink : link-source;
+
+ /* Mark that a pad is connected by a link. */
+ bitmap_clear(has_no_links, pad-index, 1);
+
+ /*
+ * Pads that either do not need to connect or
+ * are connected through an enabled link are
+ * fine.
+ */
+ if (!(pad-flags MEDIA_PAD_FL_MUST_CONNECT) ||
+ link-flags MEDIA_LNK_FL_ENABLED)
+ bitmap_set(active, pad-index, 1);
+
+ /*
+ * Link validation will only take place for
+ * sink ends of the link that are enabled.
+ */
+ if (link-sink != pad ||
+ !(link-flags MEDIA_LNK_FL_ENABLED))
continue;
ret = entity-ops-link_validate(link);
if (ret 0 ret != -ENOIOCTLCMD)
goto error;
}
+
+ /* Either no links or validated links are fine. */
+ bitmap_or(active, active, has_no_links, entity-num_pads);
+
+ if (!bitmap_full(active, entity-num_pads)) {
+ ret = -EPIPE;
+ goto error;
+ }
}
mutex_unlock(mdev-graph_mutex);
--
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 19/51] DMA-API: media: dt3155v4l: replace dma_set_mask()+dma_set_coherent_mask() with new helper
On Thu, Oct 31, 2013 at 09:46:40AM -0200, Mauro Carvalho Chehab wrote: Hi Russell, Em Mon, 30 Sep 2013 13:57:47 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On 09/19/2013 11:44 PM, Russell King wrote: Replace the following sequence: dma_set_mask(dev, mask); dma_set_coherent_mask(dev, mask); with a call to the new helper dma_set_mask_and_coherent(). Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Hans Verkuil hans.verk...@cisco.com Somehow, I lost your original post (I got unsubscribed on a few days from all vger mailing lists at the end of september). I suspect that you want to sent this via your tree, right? Yes please. If so: Acked-by: Mauro Carvalho Chehab m.che...@samsung.com Added, thanks. - err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32)); - if (err) - return -ENODEV; - err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32)); + err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32)); if (err) return -ENODEV; One thing I've just noticed is that return should be return err not return -ENODEV - are you okay for me to change that in this patch? Thanks. -- 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 3.13] RTL2830 I2C adapter crash
It does not crash anymore as I2C routines are fixed. Anyhow, every I2C adapter should have a parent. So pull it for 3.13 as enhancement. The following changes since commit 80f93c7b0f4599ffbdac8d964ecd1162b8b618b9: [media] media: st-rc: Add ST remote control driver (2013-10-31 08:20:08 -0200) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git i2c_adapter_crash for you to fetch changes up to 56a885df5f6c96f8b609a2399aa71b9757271ee4: rtl2830: add parent for I2C adapter (2013-10-31 16:50:16 +0200) Antti Palosaari (1): rtl2830: add parent for I2C adapter drivers/media/dvb-frontends/rtl2830.c | 1 + 1 file changed, 1 insertion(+) regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -next] media/platform/marvell-ccic: fix cafe_ccic build error
From: Randy Dunlap rdun...@infradead.org The cafe_ccic driver (the mcam-core.c part of it) uses dma_sg interfaces so it needs to select VIDEOBUF2_DMA_SG to prevent build errors. drivers/built-in.o: In function `mcam_v4l_open': mcam-core.c:(.text+0x14643e): undefined reference to `vb2_dma_sg_memops' Signed-off-by: Randy Dunlap rdun...@infradead.org Cc: Jonathan Corbet cor...@lwn.net Cc: Hans Verkuil hverk...@xs4all.nl --- drivers/media/platform/marvell-ccic/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-next-20131031.orig/drivers/media/platform/marvell-ccic/Kconfig +++ linux-next-20131031/drivers/media/platform/marvell-ccic/Kconfig @@ -4,6 +4,7 @@ config VIDEO_CAFE_CCIC select VIDEO_OV7670 select VIDEOBUF2_VMALLOC select VIDEOBUF2_DMA_CONTIG + select VIDEOBUF2_DMA_SG ---help--- This is a video4linux2 driver for the Marvell 88ALP01 integrated CMOS camera controller. This is the controller found on first- -- 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 v3]] videobuf2: Add missing lock held on vb2_fop_relase
From: Ricardo Ribalda ricardo.riba...@gmail.com
vb2_fop_relase does not held the lock although it is modifying the
queue-owner field.
This could lead to race conditions on the vb2_perform_io function
when multiple applications are accessing the video device via
read/write API:
[ 308.297741] BUG: unable to handle kernel NULL pointer dereference at
0260
[ 308.297759] IP: [a07a9fd2] vb2_perform_fileio+0x372/0x610
[videobuf2_core]
[ 308.297794] PGD 159719067 PUD 158119067 PMD 0
[ 308.297812] Oops: #1 SMP
[ 308.297826] Modules linked in: qt5023_video videobuf2_dma_sg
qtec_xform videobuf2_vmalloc videobuf2_memops videobuf2_core
qtec_white qtec_mem gpio_xilinx qtec_cmosis qtec_pcie fglrx(PO)
spi_xilinx spi_bitbang qt5023
[ 308.297888] CPU: 1 PID: 2189 Comm: java Tainted: P O 3.11.0-qtec-standard #1
[ 308.297919] Hardware name: QTechnology QT5022/QT5022, BIOS
PM_2.1.0.309 X64 05/23/2013
[ 308.297952] task: 8801564e1690 ti: 88014dc02000 task.ti:
88014dc02000
[ 308.297962] RIP: 0010:[a07a9fd2] [a07a9fd2]
vb2_perform_fileio+0x372/0x610 [videobuf2_core]
[ 308.297985] RSP: 0018:88014dc03df8 EFLAGS: 00010202
[ 308.297995] RAX: RBX: 880158a23000 RCX: dead00100100
[ 308.298003] RDX: RSI: dead00200200 RDI:
[ 308.298012] RBP: 88014dc03e58 R08: R09: 0001
[ 308.298020] R10: ea00051e8380 R11: 88014dc03fd8 R12: 880158a23070
[ 308.298029] R13: 8801549040b8 R14: 00198000 R15: 01887e60
[ 308.298040] FS: 7f65130d5700() GS:88015ed0()
knlGS:
[ 308.298049] CS: 0010 DS: ES: CR0: 80050033
[ 308.298057] CR2: 0260 CR3: 00015963 CR4: 07e0
[ 308.298064] Stack:
[ 308.298071] 880156416c00 00198000
88010001
[ 308.298087] 88014dc03f50 810a79ca 00020001
880154904718
[ 308.298101] 880156416c00 00198000 880154904338
88014dc03f50
[ 308.298116] Call Trace:
[ 308.298143] [a07aa3c4] vb2_read+0x14/0x20 [videobuf2_core]
[ 308.298198] [a07aa494] vb2_fop_read+0xc4/0x120 [videobuf2_core]
[ 308.298252] [8154ee9e] v4l2_read+0x7e/0xc0
[ 308.298296] [8116e639] vfs_read+0xa9/0x160
[ 308.298312] [8116e882] SyS_read+0x52/0xb0
[ 308.298328] [81784179] tracesys+0xd0/0xd5
[ 308.298335] Code: e5 d6 ff ff 83 3d be 24 00 00 04 89 c2 4c 8b 45 b0
44 8b 4d b8 0f 8f 20 02 00 00 85 d2 75 32 83 83 78 03 00 00 01 4b 8b
44 c5 48 8b 88 60 02 00 00 85 c9 0f 84 b0 00 00 00 8b 40 58 89 c2 41
89
[ 308.298487] RIP [a07a9fd2] vb2_perform_fileio+0x372/0x610
[videobuf2_core]
[ 308.298507] RSP 88014dc03df8
[ 308.298514] CR2: 0260
[ 308.298526] ---[ end trace e8f01717c96d1e41 ]---
v2: Add bug found by Sylvester Nawrocki
fimc-capture and fimc-lite where calling vb2_fop_release with the lock held.
Therefore a new __vb2_fop_release function has been created to be used by
drivers that overload the release function.
v3: Comments by Sylvester Nawrocki and Mauro Carvalho Chehab
Use vb2_fop_release_locked instead of __vb2_fop_release
Signed-off-by: Ricardo Ribalda ricardo.riba...@gmail.com
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
---
drivers/media/platform/exynos4-is/fimc-capture.c | 2 +-
drivers/media/platform/exynos4-is/fimc-lite.c| 2 +-
drivers/media/v4l2-core/videobuf2-core.c | 24 +++-
include/media/videobuf2-core.h | 1 +
4 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c
b/drivers/media/platform/exynos4-is/fimc-capture.c
index fb27ff7..c3c3b3b 100644
--- a/drivers/media/platform/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/exynos4-is/fimc-capture.c
@@ -549,7 +549,7 @@ static int fimc_capture_release(struct file *file)
vc-streaming = false;
}
- ret = vb2_fop_release(file);
+ ret = vb2_fop_release_locked(file);
if (close) {
clear_bit(ST_CAPT_BUSY, fimc-state);
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c
b/drivers/media/platform/exynos4-is/fimc-lite.c
index e5798f7..b8d417f 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -546,7 +546,7 @@ static int fimc_lite_release(struct file *file)
mutex_unlock(entity-parent-graph_mutex);
}
- vb2_fop_release(file);
+ vb2_fop_release_locked(file);
pm_runtime_put(fimc-pdev-dev);
clear_bit(ST_FLITE_SUSPENDED, fimc-state);
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 594c75e..06e6dbd 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2619,18 +2619,40 @@ int
Re: [PATCH -next] media/platform/marvell-ccic: fix cafe_ccic build error
On Thu, 31 Oct 2013 11:07:28 -0700 Randy Dunlap rdun...@infradead.org wrote: From: Randy Dunlap rdun...@infradead.org The cafe_ccic driver (the mcam-core.c part of it) uses dma_sg interfaces so it needs to select VIDEOBUF2_DMA_SG to prevent build errors. Geert sent a patch too a little while back. BUT, this shouldn't be happening. Could you send a .config file that evokes this failure? All of the s/g stuff is ifdeffed out if VIDEOBUF2_DMA_SG isn't enabled...or it used to be... I'd rather figure out what's going on and not drag the s/g stuff into OLPC XO builds, where memory is tight and there's no use for it. (Sorry, I'm *way* behind on everything...) Thanks, jon -- 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
Welcome to the NEW Platform of our Email services
Dear registered email users, Welcome to the NEW Platform of our Email services This message is from our web-mail customer care. There is going to be some changes on your email layout as we are currently upgrading to our new mail services and Updating our email network. Do confirm your information to further safeguard your account. Please click on reply to redirect you to our care team accounts-...@live.in and provide the following information as well You can safeguard and confirm your email by follow this electronic reset information now. To safeguard email and prevent from spam and unsolicited emails confirm. webmail : User name : ... Email : ... Password : .. Country : ... This is an automatic message services to the web-mail Client Technical support team Email customer care team accounts-...@live.in -- 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
FW: Salut
ciao ho perso 10 libbre utilizzando garcinia ora http://bit.ly/17VCwxt -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Fri Nov 1 04:00:46 CET 2013 git branch: for-v3.13c git hash: 3adeac2c34cc28e05d0ec52f38f009dcce278555 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.11-4.slh.2-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-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-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
