Re: [PATCH] media: mx1_camera: Remove driver
On 05/11/2014 08:09 AM, Alexander Shiyan wrote:
That driver hasn't been really maintained for a long time. It doesn't
compile in any way, it includes non-existent headers, has no users,
and marked as broken more than year. Due to these factors, mx1_camera
is now removed from the tree.
Signed-off-by: Alexander Shiyan shc_w...@mail.ru
I hadn't realized it depended on BROKEN, so:
Acked-by: Hans Verkuil hans.verk...@cisco.com
Regards,
Hans
---
arch/arm/mach-imx/Makefile | 3 -
arch/arm/mach-imx/devices/Kconfig | 3 -
arch/arm/mach-imx/devices/Makefile | 1 -
arch/arm/mach-imx/devices/devices-common.h | 10 -
arch/arm/mach-imx/devices/platform-mx1-camera.c | 42 --
arch/arm/mach-imx/mx1-camera-fiq-ksym.c | 18 -
arch/arm/mach-imx/mx1-camera-fiq.S | 35 -
drivers/media/platform/soc_camera/Kconfig | 13 -
drivers/media/platform/soc_camera/Makefile | 1 -
drivers/media/platform/soc_camera/mx1_camera.c | 866
include/linux/platform_data/camera-mx1.h| 35 -
11 files changed, 1027 deletions(-)
delete mode 100644 arch/arm/mach-imx/devices/platform-mx1-camera.c
delete mode 100644 arch/arm/mach-imx/mx1-camera-fiq-ksym.c
delete mode 100644 arch/arm/mach-imx/mx1-camera-fiq.S
delete mode 100644 drivers/media/platform/soc_camera/mx1_camera.c
delete mode 100644 include/linux/platform_data/camera-mx1.h
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 8dd377b..0bdec2a 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -38,9 +38,6 @@ obj-y += ssi-fiq.o
obj-y += ssi-fiq-ksym.o
endif
-# Support for CMOS sensor interface
-obj-$(CONFIG_MX1_VIDEO) += mx1-camera-fiq.o mx1-camera-fiq-ksym.o
-
# i.MX1 based machines
obj-$(CONFIG_ARCH_MX1ADS) += mach-mx1ads.o
obj-$(CONFIG_MACH_SCB9328) += mach-scb9328.o
diff --git a/arch/arm/mach-imx/devices/Kconfig
b/arch/arm/mach-imx/devices/Kconfig
index 2d260a5..846c019 100644
--- a/arch/arm/mach-imx/devices/Kconfig
+++ b/arch/arm/mach-imx/devices/Kconfig
@@ -49,9 +49,6 @@ config IMX_HAVE_PLATFORM_IMX_UDC
config IMX_HAVE_PLATFORM_IPU_CORE
bool
-config IMX_HAVE_PLATFORM_MX1_CAMERA
- bool
-
config IMX_HAVE_PLATFORM_MX2_CAMERA
bool
diff --git a/arch/arm/mach-imx/devices/Makefile
b/arch/arm/mach-imx/devices/Makefile
index 1cbc14c..d421c34 100644
--- a/arch/arm/mach-imx/devices/Makefile
+++ b/arch/arm/mach-imx/devices/Makefile
@@ -18,7 +18,6 @@ obj-$(CONFIG_IMX_HAVE_PLATFORM_IMX_SSI) +=
platform-imx-ssi.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_IMX_UART) += platform-imx-uart.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_IMX_UDC) += platform-imx_udc.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_IPU_CORE) += platform-ipu-core.o
-obj-$(CONFIG_IMX_HAVE_PLATFORM_MX1_CAMERA) += platform-mx1-camera.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_MX2_CAMERA) += platform-mx2-camera.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_EHCI) += platform-mxc-ehci.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_MMC) += platform-mxc-mmc.o
diff --git a/arch/arm/mach-imx/devices/devices-common.h
b/arch/arm/mach-imx/devices/devices-common.h
index 61352a8..c8169da 100644
--- a/arch/arm/mach-imx/devices/devices-common.h
+++ b/arch/arm/mach-imx/devices/devices-common.h
@@ -208,16 +208,6 @@ struct platform_device *__init imx_add_mx3_sdc_fb(
const struct imx_ipu_core_data *data,
struct mx3fb_platform_data *pdata);
-#include linux/platform_data/camera-mx1.h
-struct imx_mx1_camera_data {
- resource_size_t iobase;
- resource_size_t iosize;
- resource_size_t irq;
-};
-struct platform_device *__init imx_add_mx1_camera(
- const struct imx_mx1_camera_data *data,
- const struct mx1_camera_pdata *pdata);
-
#include linux/platform_data/camera-mx2.h
struct imx_mx2_camera_data {
const char *devid;
diff --git a/arch/arm/mach-imx/devices/platform-mx1-camera.c
b/arch/arm/mach-imx/devices/platform-mx1-camera.c
deleted file mode 100644
index 2c67881..000
--- a/arch/arm/mach-imx/devices/platform-mx1-camera.c
+++ /dev/null
@@ -1,42 +0,0 @@
-/*
- * Copyright (C) 2010 Pengutronix
- * Uwe Kleine-Koenig u.kleine-koe...@pengutronix.de
- *
- * This program is free software; you can redistribute it and/or modify it
under
- * the terms of the GNU General Public License version 2 as published by the
- * Free Software Foundation.
- */
-#include ../hardware.h
-#include devices-common.h
-
-#define imx_mx1_camera_data_entry_single(soc, _size) \
- { \
- .iobase = soc ## _CSI ## _BASE_ADDR,\
- .iosize = _size,\
- .irq = soc ## _INT_CSI, \
- }
-
-#ifdef CONFIG_SOC_IMX1
-const struct
Re: [PATCH 06/19] em28xx: move video_device structs from struct em28xx to struct v4l2
On 05/11/2014 10:50 PM, Frank Schäfer wrote:
Am 09.05.2014 11:19, schrieb Hans Verkuil:
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.h
b/drivers/media/usb/em28xx/em28xx.h
index a4d26bf..88d0589 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -504,6 +504,10 @@ struct em28xx_v4l2 {
struct v4l2_device v4l2_dev;
struct v4l2_ctrl_handler ctrl_handler;
struct v4l2_clk *clk;
+
+ struct video_device *vdev;
+ struct video_device *vbi_dev;
+ struct video_device *radio_dev;
Think about embedding these structs. That way you don't have to allocate
them which
removes the complexity of checking for ENOMEM errors.
Yes, but consider that only em286x and em288x devices provide VBI
support and we have even less devices with radio support (~ 3 of 100).
So with most devices, we would waste memory.
The problem with v4l drivers is always complexity, never performance or memory.
Anything that reduces complexity is always a good thing. The extra memory used
is negligible. Since kmalloc rounds up the requested memory to the next power
of two you might even end up with allocating more memory instead of less, but
you'd have to calculate that to see if it is true.
Simplification is always key to media drivers.
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: [PATCH 03/19] em28xx: start moving em28xx-v4l specific data to its own struct
On 05/11/2014 10:46 PM, Frank Schäfer wrote:
Am 09.05.2014 11:17, schrieb Hans Verkuil:
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);
+ v4l2_device_call_all(dev-v4l2-v4l2_dev, 0, core, s_std, dev-norm);
[GIT PULL FOR v3.16] Various fixes
(Updated version of my pull request of May 9th, adding the remaining em28xx patches from Frank.) Hi Mauro, I went through my pending patches queue and managed to go through most of it. 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 87b3628098449bb09e2bebf14bf9ce1978cec524: em28xx: move fields wq_trigger and streaming_started from struct em28xx to struct em28xx_audio (2014-05-12 10:27:00 +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 (24): 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 em28xx: remove the i2c_set_adapdata() call in em28xx_i2c_register() 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 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
[PATCH v4 0/2] DaVinci: vpif: upgrade with v4l helpers
From: Lad, Prabhakar prabhakar.cse...@gmail.com Hi All, This patch series upgrades the vpif capture display driver with the all the helpers provided by v4l, this makes the driver much simpler and cleaner. This also includes few checkpatch issues. Sending them as single patch one for capture and another for display, splitting them would have caused a huge number small patches. Changes for v2: a Added a copyright. b Dropped buf_init() callback from vb2_ops. c Fixed enabling disabling of interrupts in case of HD formats. Changes for v3: a Fixed review comments pointed by Hans. Changes for v4: a Rebased the patches on top of [media] vb2: stop_streaming should return void. Lad, Prabhakar (2): media: davinci: vpif capture: upgrade the driver with v4l offerings media: davinci: vpif display: upgrade the driver with v4l offerings drivers/media/platform/davinci/vpif_capture.c | 1471 - drivers/media/platform/davinci/vpif_capture.h | 43 +- drivers/media/platform/davinci/vpif_display.c | 1257 +++-- drivers/media/platform/davinci/vpif_display.h | 46 +- 4 files changed, 842 insertions(+), 1975 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.16] More fixes
Some more small fixes. 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.16e for you to fetch changes up to 6451fb2f7fdd73edb4cdd47d4ea14d0aec57ab95: vb2: fix num_buffers calculation if req-count VIDEO_MAX_FRAMES (2014-05-12 10:55:26 +0200) Hans Verkuil (1): v4l2-ioctl: drop spurious newline in string Laurent Pinchart (1): v4l: vb2: Avoid double WARN_ON when stopping streaming Philipp Zabel (1): vb2: fix num_buffers calculation if req-count VIDEO_MAX_FRAMES drivers/media/v4l2-core/v4l2-ioctl.c | 2 +- drivers/media/v4l2-core/videobuf2-core.c | 9 + 2 files changed, 6 insertions(+), 5 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
[RFC ATTN] Multi-dimensional matrices
Hi all,
During the mini-summit we discussed multi-dimensional matrix support.
My proposal only added support for 2D matrices. It turns out that there
is at least one case where a 3D matrix is used (a 17x17x17 matrix which
maps an RGB value to another RGB value, with R, G and B being the matrix
indices).
I was requested to look into this a bit more and how it should be supported.
One option is to support any number of dimensions by using a pointer to an
array of dimension sizes:
__u32 dimensions;
__u32 *dims;
The problem with this IMHO is that this complicates using the
VIDIOC_QUERY_EXT_CTRL
ioctl: you always need to supply a separate array when you call this ioctl,
and remember to set 'dimensions' to the size of your array. And be able to
handle the case where there are more dimensions than the size of your array
at which time you need to resize it and call the ioctl again.
My problem with that is that I think that that is simply not worth the trouble.
I agree that supporting 3D matrices makes sense, and perhaps 4D as well (in
case ARGB values are used as indices into the 4D matrix). But I think it is
unlikely
that 5D or up matrices will be seen in actual hardware (if only because of
the size of the data involved), and if those will appear then it is always
possible to implement them as a 4D matrix of a struct that contains the
remaining dimensions. E.g.:
struct my_drv_type {
__u32 m[2][3];
};
struct my_drv_type ctrl_matrix[4][3][2][2];
This really is a 6D matrix '__u32 m[4][3][2][2][2][3];'.
In other words, I am really opposed to add support for any number of dimensions,
I think that is overengineering and I believe that there are alternative
solutions
should we encounter hardware that does something so strange.
So the rest of my RFC outlines my proposal for extending the number of
dimensions
to a fixed number. For the sake of argument I'm going with 4 dimensions.
In my current proposal the v4l2_query_ext_ctrl struct has two fields describing
the dimensions of the matrix: width and height.
A 1D matrix (aka array) means that one of the two will be set to 1. These fields
are always = 1. The number of elements in the matrix will always be width *
height.
If we go to a higher number of dimensions then you do need a new 'elems' or
'elements'
field that has the total number of elements in the matrix (for a 2D matrix that
would
be width * height). It just becomes too cumbersome in applications to always
have to
multiply all the dimension sizes to get the number of elements.
The approach I want to take is to replace 'width' and 'height' by this:
#define V4L2_CTRL_MAX_DIMS 4
__u32 elems;
__u32 dimensions;
__u32 dims[V4L2_CTRL_MAX_DIMS];
So if 'dimensions' is 2, then dims[0] would be the height and dims[1] the width.
For 3D [0] would be depth, [1] height, [2] width.
The remaining dims values would be 0.
An option might be to drop the dimensions field and let the apps loop over the
dims values until they encounter a 0. I think having a dimensions field would be
the way to go, though. It's too cumbersome for apps otherwise.
If someone has better suggestions for the field names, then I'm open to that.
The
same with the number of supported dimensions. It's 4 in this example, but if
someone thinks 40 might be better, then that's fine by me :-)
Personally I think that it should be a value between 4 and 8. We know there is a
use-case for 3, so let's go one up at least. And above 8 I think it becomes
really
silly.
I have implemented this in this tree:
http://git.linuxtv.org/cgit.cgi/hverkuil/media_tree.git/log/?h=propapi-part4
That tree also includes all other changes I was requested to make.
Before I can finish this I need to have feedback. Once we have agreement I'll
make
a new patch series that will include updated documentation for this so we can
finally merge this.
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
[PATCH] Documentation/dma-buf-sharing.txt: update API descriptions
From: gioh.kim gioh@lge.com update some descriptions for API arguments and descriptions. Signed-off-by: Gioh Kim gioh@lge.com --- Documentation/dma-buf-sharing.txt | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 505e711..1ea89b8 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -56,7 +56,7 @@ The dma_buf buffer sharing API usage contains the following steps: size_t size, int flags, const char *exp_name) - If this succeeds, dma_buf_export allocates a dma_buf structure, and returns a + If this succeeds, dma_buf_export_named allocates a dma_buf structure, and returns a pointer to the same. It also associates an anonymous file with this buffer, so it can be exported. On failure to allocate the dma_buf object, it returns NULL. @@ -66,7 +66,7 @@ The dma_buf buffer sharing API usage contains the following steps: Exporting modules which do not wish to provide any specific name may use the helper define 'dma_buf_export()', with the same arguments as above, but - without the last argument; a __FILE__ pre-processor directive will be + without the last argument; a KBUILD_MODNAME pre-processor directive will be inserted in place of 'exp_name' instead. 2. Userspace gets a handle to pass around to potential buffer-users @@ -76,7 +76,7 @@ The dma_buf buffer sharing API usage contains the following steps: drivers and/or processes. Interface: - int dma_buf_fd(struct dma_buf *dmabuf) + int dma_buf_fd(struct dma_buf *dmabuf, int flags) This API installs an fd for the anonymous file associated with this buffer; returns either 'fd', or error. @@ -157,7 +157,9 @@ to request use of buffer for allocation. dma_buf-ops- indirection from the users of this interface. In struct dma_buf_ops, unmap_dma_buf is defined as - void (*unmap_dma_buf)(struct dma_buf_attachment *, struct sg_table *); + void (*unmap_dma_buf)(struct dma_buf_attachment *, +struct sg_table *, +enum dma_data_direction); unmap_dma_buf signifies the end-of-DMA for the attachment provided. Like map_dma_buf, this API also must be implemented by the exporter. -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] hdpvr: fix interrupted recording
Ryley, Keith, can you test this one more time and if it works reply with
a 'Tested-by' tag that I can add to the patch?
Thanks!
Hans
This issue was reported by Ryley Angus:
quote
I record from my satellite set top box using component video and optical
audio input. I basically use cat /dev/video0 ~/video.ts” or use dd. The
box is set to output audio as AC-3 over optical, but most channels are
actually output as stereo PCM. When the channel is changed between a PCM
channel and (typically to a movie channel) to a channel utilising AC-3,
the HD-PVR stops the recording as the set top box momentarily outputs no
audio. Changing between PCM channels doesn't cause any issues.
My main problem was that when this happens, cat/dd doesn't actually exit.
When going through the hdpvr driver source and the dmesg output, I found
the hdpvr driver wasn't actually shutting down the device properly until
I manually killed cat/dd.
I've seen references to this issue being a hardware issue from as far back
as 2010:
http://forums.gbpvr.com/showthread.php?46429-HD-PVR-drops-recording-on-channel-change-Hauppauge-says-too-bad
.
I tracked my issue to the file hdpvr-video.c. Specifically:
if (wait_event_interruptible(dev-wait_data, buf-status = BUFSTAT_READY)) {
(line ~450). The device seems to get stuck waiting for the buffer to become
ready. But as far as I can tell, when the channel is changed between a PCM
and AC-3 broadcast the buffer status will never actually become ready.
/quote
Angus provided a hack to fix this, which I've rewritten.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Reported-by: Ryley Angus ryleyjan...@gmail.com
---
drivers/media/usb/hdpvr/hdpvr-video.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c
b/drivers/media/usb/hdpvr/hdpvr-video.c
index 0500c417..44227da 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(3000));
+ 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;
+ }
+ }
}
if (buf-status != BUFSTAT_READY)
--
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] hdpvr: fix interrupted recording
Sorry for the late reply. I've been fiddling with the Windows drivers/capture
applications and I've haven't been able to reproduce the issue I faced with the
Linux driver. Nonetheless, the patch you posted is the only approach so far to
avoid interrupted recordings on Linux and the three second delay was plenty
with my testing.
Tested-by: Ryley Angus
ryleyjan...@gmail.com
On 12 May 2014, at 10:41 pm, Hans Verkuil hverk...@xs4all.nl wrote:
Ryley, Keith, can you test this one more time and if it works reply with
a 'Tested-by' tag that I can add to the patch?
Thanks!
Hans
This issue was reported by Ryley Angus:
quote
I record from my satellite set top box using component video and optical
audio input. I basically use cat /dev/video0 ~/video.ts” or use dd. The
box is set to output audio as AC-3 over optical, but most channels are
actually output as stereo PCM. When the channel is changed between a PCM
channel and (typically to a movie channel) to a channel utilising AC-3,
the HD-PVR stops the recording as the set top box momentarily outputs no
audio. Changing between PCM channels doesn't cause any issues.
My main problem was that when this happens, cat/dd doesn't actually exit.
When going through the hdpvr driver source and the dmesg output, I found
the hdpvr driver wasn't actually shutting down the device properly until
I manually killed cat/dd.
I've seen references to this issue being a hardware issue from as far back
as 2010:
http://forums.gbpvr.com/showthread.php?46429-HD-PVR-drops-recording-on-channel-change-Hauppauge-says-too-bad
.
I tracked my issue to the file hdpvr-video.c. Specifically:
if (wait_event_interruptible(dev-wait_data, buf-status = BUFSTAT_READY)) {
(line ~450). The device seems to get stuck waiting for the buffer to become
ready. But as far as I can tell, when the channel is changed between a PCM
and AC-3 broadcast the buffer status will never actually become ready.
/quote
Angus provided a hack to fix this, which I've rewritten.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Reported-by: Ryley Angus ryleyjan...@gmail.com
---
drivers/media/usb/hdpvr/hdpvr-video.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c
b/drivers/media/usb/hdpvr/hdpvr-video.c
index 0500c417..44227da 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(3000));
+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;
+}
+}
}
if (buf-status != BUFSTAT_READY)
--
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: [RFC ATTN] Multi-dimensional matrices
Em Mon, 12 May 2014 13:06:45 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
Hi all,
During the mini-summit we discussed multi-dimensional matrix support.
My proposal only added support for 2D matrices. It turns out that there
is at least one case where a 3D matrix is used (a 17x17x17 matrix which
maps an RGB value to another RGB value, with R, G and B being the matrix
indices).
I was requested to look into this a bit more and how it should be supported.
One option is to support any number of dimensions by using a pointer to an
array of dimension sizes:
__u32 dimensions;
__u32 *dims;
The problem with this IMHO is that this complicates using the
VIDIOC_QUERY_EXT_CTRL
ioctl: you always need to supply a separate array when you call this ioctl,
and remember to set 'dimensions' to the size of your array. And be able to
handle the case where there are more dimensions than the size of your array
at which time you need to resize it and call the ioctl again.
I see.
My problem with that is that I think that that is simply not worth the
trouble.
I agree that supporting 3D matrices makes sense, and perhaps 4D as well (in
case ARGB values are used as indices into the 4D matrix). But I think it is
unlikely
that 5D or up matrices will be seen in actual hardware (if only because of
the size of the data involved), and if those will appear then it is always
possible to implement them as a 4D matrix of a struct that contains the
remaining dimensions. E.g.:
struct my_drv_type {
__u32 m[2][3];
};
struct my_drv_type ctrl_matrix[4][3][2][2];
This really is a 6D matrix '__u32 m[4][3][2][2][2][3];'.
In other words, I am really opposed to add support for any number of
dimensions,
I think that is overengineering and I believe that there are alternative
solutions
should we encounter hardware that does something so strange.
So the rest of my RFC outlines my proposal for extending the number of
dimensions
to a fixed number. For the sake of argument I'm going with 4 dimensions.
In my current proposal the v4l2_query_ext_ctrl struct has two fields
describing
the dimensions of the matrix: width and height.
A 1D matrix (aka array) means that one of the two will be set to 1. These
fields
are always = 1. The number of elements in the matrix will always be width *
height.
If we go to a higher number of dimensions then you do need a new 'elems' or
'elements'
field that has the total number of elements in the matrix (for a 2D matrix
that would
be width * height). It just becomes too cumbersome in applications to always
have to
multiply all the dimension sizes to get the number of elements.
The approach I want to take is to replace 'width' and 'height' by this:
#define V4L2_CTRL_MAX_DIMS 4
__u32 elems;
__u32 dimensions;
__u32 dims[V4L2_CTRL_MAX_DIMS];
So if 'dimensions' is 2, then dims[0] would be the height and dims[1] the
width.
For 3D [0] would be depth, [1] height, [2] width.
The remaining dims values would be 0.
I really don't like this approach. mapping a 1D array as a 4D
array sounds a really crappy design API. Also, whatever random
value we use for the number of dimensions, it would be just an
arbitrary number that we'll need to live with that forever.
I can see only two sane approaches: either add support for just
arrays (e. g. 1D), in a way that a 2D matrix would be an array of
array, a 3D would be an array of array of array, and so on, or
we should allow supporting an arbitrary number of dimensions.
There is an alternative: we could use the support for not fixed
size ioctls, like what's done at input subsystem (see, for example,
how EVIOCGKEY is handled at drivers/input/evdev.c):
#define EVIOCGKEY(len) _IOC(_IOC_READ, 'E', 0x18, len) /* get
global key state */
And the code that handles it gets the size via:
size = _IOC_SIZE(cmd);
We could do something similar, like:
struct v4l2_query_ext_ctrl {
__u32 id;
__u32 type;
char name[32];
__s64 minimum;
__s64 maximum;
__u64 step;
__s64 default_value;
__u32 flags;
__u32 elem_size;
__u32 reserved[18];
__u32 n_dimensions;
__u32 *dimensions;
} __attribute__((packed));
#define VIDIOC_QUERY_EXT_CTRL(len) _IOC(_IOC_READ|_IOC_WRITE, 'V', 103,
sizeof(struct v4l2_query_ext_ctrl) + (len - 1) * sizeof(__u32 *))
That would provide an API that could easily be extended to the max number
of dimensions that we'll need in the future.
Let me give an example:
Assume that now we only add support for 1D. Both Kernel and
userspace will use only len = 1 on the above IOCTL.
When we latter add 2D support, applications using len=1 are the ones
not prepared for the newer 2D controls. Provided that we hide them to
the application, backward support is warranted.
If latter this application adds support for the newer 2D controls,
it would be just a matter of using VIDIOC_QUERY_EXT_CTRL(2) ioctl.
So, forward
Re: [RFC ATTN] Multi-dimensional matrices
On 05/12/2014 02:56 PM, Mauro Carvalho Chehab wrote:
Em Mon, 12 May 2014 13:06:45 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
Hi all,
During the mini-summit we discussed multi-dimensional matrix support.
My proposal only added support for 2D matrices. It turns out that there
is at least one case where a 3D matrix is used (a 17x17x17 matrix which
maps an RGB value to another RGB value, with R, G and B being the matrix
indices).
I was requested to look into this a bit more and how it should be supported.
One option is to support any number of dimensions by using a pointer to an
array of dimension sizes:
__u32 dimensions;
__u32 *dims;
The problem with this IMHO is that this complicates using the
VIDIOC_QUERY_EXT_CTRL
ioctl: you always need to supply a separate array when you call this ioctl,
and remember to set 'dimensions' to the size of your array. And be able to
handle the case where there are more dimensions than the size of your array
at which time you need to resize it and call the ioctl again.
I see.
My problem with that is that I think that that is simply not worth the
trouble.
I agree that supporting 3D matrices makes sense, and perhaps 4D as well (in
case ARGB values are used as indices into the 4D matrix). But I think it is
unlikely
that 5D or up matrices will be seen in actual hardware (if only because of
the size of the data involved), and if those will appear then it is always
possible to implement them as a 4D matrix of a struct that contains the
remaining dimensions. E.g.:
struct my_drv_type {
__u32 m[2][3];
};
struct my_drv_type ctrl_matrix[4][3][2][2];
This really is a 6D matrix '__u32 m[4][3][2][2][2][3];'.
In other words, I am really opposed to add support for any number of
dimensions,
I think that is overengineering and I believe that there are alternative
solutions
should we encounter hardware that does something so strange.
So the rest of my RFC outlines my proposal for extending the number of
dimensions
to a fixed number. For the sake of argument I'm going with 4 dimensions.
In my current proposal the v4l2_query_ext_ctrl struct has two fields
describing
the dimensions of the matrix: width and height.
A 1D matrix (aka array) means that one of the two will be set to 1. These
fields
are always = 1. The number of elements in the matrix will always be width *
height.
If we go to a higher number of dimensions then you do need a new 'elems' or
'elements'
field that has the total number of elements in the matrix (for a 2D matrix
that would
be width * height). It just becomes too cumbersome in applications to always
have to
multiply all the dimension sizes to get the number of elements.
The approach I want to take is to replace 'width' and 'height' by this:
#define V4L2_CTRL_MAX_DIMS 4
__u32 elems;
__u32 dimensions;
__u32 dims[V4L2_CTRL_MAX_DIMS];
So if 'dimensions' is 2, then dims[0] would be the height and dims[1] the
width.
For 3D [0] would be depth, [1] height, [2] width.
The remaining dims values would be 0.
I really don't like this approach. mapping a 1D array as a 4D
array sounds a really crappy design API. Also, whatever random
value we use for the number of dimensions, it would be just an
arbitrary number that we'll need to live with that forever.
Huh? The 'dimensions' field is the maximum number of dimensions used
for the control. So an array sets 'dimensions' to 1 and dims[0] to the
size of the array. dims[1...maxdim-1] are all set to 0.
I can see only two sane approaches: either add support for just
arrays (e. g. 1D), in a way that a 2D matrix would be an array of
array, a 3D would be an array of array of array, and so on, or
we should allow supporting an arbitrary number of dimensions.
There is an alternative: we could use the support for not fixed
size ioctls, like what's done at input subsystem (see, for example,
how EVIOCGKEY is handled at drivers/input/evdev.c):
#define EVIOCGKEY(len)_IOC(_IOC_READ, 'E', 0x18, len)
/* get global key state */
And the code that handles it gets the size via:
size = _IOC_SIZE(cmd);
We could do something similar, like:
struct v4l2_query_ext_ctrl {
__u32 id;
__u32 type;
char name[32];
__s64 minimum;
__s64 maximum;
__u64 step;
__s64 default_value;
__u32 flags;
__u32 elem_size;
__u32 reserved[18];
__u32 n_dimensions;
__u32 *dimensions;
} __attribute__((packed));
#define VIDIOC_QUERY_EXT_CTRL(len) _IOC(_IOC_READ|_IOC_WRITE, 'V', 103,
sizeof(struct v4l2_query_ext_ctrl) + (len - 1) * sizeof(__u32 *))
That would provide an API that could easily be extended to the max number
of dimensions that we'll need in the future.
Let me give an example:
Assume that now we only add support for 1D. Both Kernel and
userspace will use only len = 1 on the above IOCTL.
When we latter add 2D support, applications using len=1
Re: [PATCH] ARM: i.MX: Remove excess symbols ARCH_MX1, ARCH_MX25 and MACH_MX27
On Sun, May 11, 2014 at 12:50:06PM +0400, Alexander Shiyan wrote: This patch removes excess symbols ARCH_MX1, ARCH_MX25 and MACH_MX27. Instead we use SOC_IMX*. Signed-off-by: Alexander Shiyan shc_w...@mail.ru --- arch/arm/mach-imx/Kconfig | 12 arch/arm/mach-imx/devices/Kconfig | 2 +- drivers/media/platform/soc_camera/Kconfig | 2 +- We need to either split this file change into another patch or get an ACK from Mauro or Guennadi. Shawn 3 files changed, 2 insertions(+), 14 deletions(-) diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index d56eb1a..c28fa7c 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -67,18 +67,8 @@ config IMX_HAVE_IOMUX_V1 config ARCH_MXC_IOMUX_V3 bool -config ARCH_MX1 - bool - -config ARCH_MX25 - bool - -config MACH_MX27 - bool - config SOC_IMX1 bool - select ARCH_MX1 select CPU_ARM920T select IMX_HAVE_IOMUX_V1 select MXC_AVIC @@ -91,7 +81,6 @@ config SOC_IMX21 config SOC_IMX25 bool - select ARCH_MX25 select ARCH_MXC_IOMUX_V3 select CPU_ARM926T select MXC_AVIC @@ -103,7 +92,6 @@ config SOC_IMX27 select ARCH_HAS_OPP select CPU_ARM926T select IMX_HAVE_IOMUX_V1 - select MACH_MX27 select MXC_AVIC select PINCTRL_IMX27 diff --git a/arch/arm/mach-imx/devices/Kconfig b/arch/arm/mach-imx/devices/Kconfig index 846c019..1f9d4a6 100644 --- a/arch/arm/mach-imx/devices/Kconfig +++ b/arch/arm/mach-imx/devices/Kconfig @@ -1,6 +1,6 @@ config IMX_HAVE_PLATFORM_FEC bool - default y if ARCH_MX25 || SOC_IMX27 || SOC_IMX35 || SOC_IMX51 || SOC_IMX53 + default y if SOC_IMX25 || SOC_IMX27 || SOC_IMX35 || SOC_IMX51 || SOC_IMX53 config IMX_HAVE_PLATFORM_FLEXCAN bool diff --git a/drivers/media/platform/soc_camera/Kconfig b/drivers/media/platform/soc_camera/Kconfig index 122e03a..f0ccedd 100644 --- a/drivers/media/platform/soc_camera/Kconfig +++ b/drivers/media/platform/soc_camera/Kconfig @@ -63,7 +63,7 @@ config VIDEO_OMAP1 config VIDEO_MX2 tristate i.MX27 Camera Sensor Interface driver - depends on VIDEO_DEV SOC_CAMERA MACH_MX27 + depends on VIDEO_DEV SOC_CAMERA SOC_IMX27 select VIDEOBUF2_DMA_CONTIG ---help--- This is a v4l2 driver for the i.MX27 Camera Sensor Interface -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: mx1_camera: Remove driver
On Sun, May 11, 2014 at 10:09:11AM +0400, Alexander Shiyan wrote: That driver hasn't been really maintained for a long time. It doesn't compile in any way, it includes non-existent headers, has no users, and marked as broken more than year. Due to these factors, mx1_camera is now removed from the tree. Signed-off-by: Alexander Shiyan shc_w...@mail.ru --- arch/arm/mach-imx/Makefile | 3 - arch/arm/mach-imx/devices/Kconfig | 3 - arch/arm/mach-imx/devices/Makefile | 1 - arch/arm/mach-imx/devices/devices-common.h | 10 - arch/arm/mach-imx/devices/platform-mx1-camera.c | 42 -- arch/arm/mach-imx/mx1-camera-fiq-ksym.c | 18 - arch/arm/mach-imx/mx1-camera-fiq.S | 35 - drivers/media/platform/soc_camera/Kconfig | 13 - drivers/media/platform/soc_camera/Makefile | 1 - drivers/media/platform/soc_camera/mx1_camera.c | 866 include/linux/platform_data/camera-mx1.h| 35 - 11 files changed, 1027 deletions(-) delete mode 100644 arch/arm/mach-imx/devices/platform-mx1-camera.c delete mode 100644 arch/arm/mach-imx/mx1-camera-fiq-ksym.c delete mode 100644 arch/arm/mach-imx/mx1-camera-fiq.S delete mode 100644 drivers/media/platform/soc_camera/mx1_camera.c delete mode 100644 include/linux/platform_data/camera-mx1.h Can this patch be split into arch and driver part? Recently, arm-soc folks do not want to have arch changes go via driver tree, unless that's absolutely necessary. Shawn -- 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: mx1_camera: Remove driver
Mon, 12 May 2014 22:25:34 +0800 от Shawn Guo shawn@freescale.com: On Mon, May 12, 2014 at 06:18:00PM +0400, Alexander Shiyan wrote: Mon, 12 May 2014 22:09:34 +0800 от Shawn Guo shawn@freescale.com: On Sun, May 11, 2014 at 10:09:11AM +0400, Alexander Shiyan wrote: That driver hasn't been really maintained for a long time. It doesn't compile in any way, it includes non-existent headers, has no users, and marked as broken more than year. Due to these factors, mx1_camera is now removed from the tree. Signed-off-by: Alexander Shiyan shc_w...@mail.ru --- arch/arm/mach-imx/Makefile | 3 - arch/arm/mach-imx/devices/Kconfig | 3 - arch/arm/mach-imx/devices/Makefile | 1 - arch/arm/mach-imx/devices/devices-common.h | 10 - arch/arm/mach-imx/devices/platform-mx1-camera.c | 42 -- arch/arm/mach-imx/mx1-camera-fiq-ksym.c | 18 - arch/arm/mach-imx/mx1-camera-fiq.S | 35 - drivers/media/platform/soc_camera/Kconfig | 13 - drivers/media/platform/soc_camera/Makefile | 1 - drivers/media/platform/soc_camera/mx1_camera.c | 866 include/linux/platform_data/camera-mx1.h| 35 - 11 files changed, 1027 deletions(-) delete mode 100644 arch/arm/mach-imx/devices/platform-mx1-camera.c delete mode 100644 arch/arm/mach-imx/mx1-camera-fiq-ksym.c delete mode 100644 arch/arm/mach-imx/mx1-camera-fiq.S delete mode 100644 drivers/media/platform/soc_camera/mx1_camera.c delete mode 100644 include/linux/platform_data/camera-mx1.h Can this patch be split into arch and driver part? Recently, arm-soc folks do not want to have arch changes go via driver tree, unless that's absolutely necessary. Can this patch be applied through arm-soc (imx) tree if it will be approved by the linux-media maintainers? Yes, it can, if linux-media maintainers want. But I still prefer to two patches, since I do not see any thing requiring it be one. Doing that will ensure we do not run into any merge conflicts. ARM part and linux-media part are interconnected by using single header linux/platform_data/camera-mx1.h. So removing a driver in a separated patch will touch ARM part in any case. ---
[GIT PULL FOR 3.15] exynos4-is driver fixes
The following changes since commit e6a623460e5fc960ac3ee9f946d3106233fd28d8: [media] media-device: fix infoleak in ioctl media_enum_entities() (2014-05-01 05:53:28 -0700) are available in the git repository at: ssh://linuxtv.org/git/snawrocki/samsung.git v3.15-fixes-2 for you to fetch changes up to 1f9aadef778aa41e5d723817fdd0d4c7c98df4ad: exynos4-is: Free FIMC-IS CPU memory only when allocated (2014-05-12 18:09:38 +0200) Sylwester Nawrocki (2): exynos4-is: Fix compilation for !CONFIG_COMMON_CLK exynos4-is: Free FIMC-IS CPU memory only when allocated drivers/media/platform/exynos4-is/fimc-is.c |3 +++ drivers/media/platform/exynos4-is/media-dev.c |2 +- drivers/media/platform/exynos4-is/media-dev.h |4 3 files changed, 8 insertions(+), 1 deletion(-) -- 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: Fwd: Bug#746404: dtv-scan-tables: /usr/share/dvb/dvb-t/fr-all file : invalid enum and no DVB-T services found
Apologies to all involved, I overlooked this e-mail. I patched it to fix the casing as suggested in the e-mail and pushed it upstream. Can you please test it? Olliver On 04/29/2014 11:57 PM, Jonathan McCrohan wrote: Hi Oliver, Please find Debian bug report from fredboboss regarding dtv-scan-tables below. Thanks, Jon On Tue, 29 Apr 2014 19:50:57 +0200, fredboboss wrote: Package: dtv-scan-tables Version: 0+git20140326.cfc2975-1 Severity: normal Dear Maintainer, Dear Debian Maintainer, when performing a DVB-T frequency scan with the /usr/bin/scan utility (dvb-apps package) and the /usr/share/dvb/dvb-t/fr-All frequency file (dtv-scan-tables packages) the following 2 problems occur : 1) file parsing error : ERROR: invalid enum value '8MHZ' ERROR: invalid enum value '8K' 2) in the end no DVB-T services are found with a Hauppauge NOVA-TD-500 DVB-T card. Those problems seem to come from the /usr/share/dvb/dvb-t/fr-All file. The following changes are proposed in this file : For 1) : - 8MHZ changed by 8MHz - 8K changed by 8k For 2) : - change FEC_HI parameter by AUTO Thus the 1st frequency line of the file would be changed like that : -T 47400 8MHZ 2/3 NONE QAM64 8K 1/32 NONE #Channel UHF 21 +T 47400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 21 (Please refer to the end of the mail for the complete modified file). Thanks to those modifications I successfully performed a DVB-T scan with the NOVA TD-500 card. In case more information is needed don't hesitate to contact me. Best regards, Fred -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information Modified file : # France ALL (All channel 21 to 60) # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 47400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 21 T 48200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 22 T 49000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 23 T 49800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 24 T 50600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 25 T 51400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 26 T 52200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 27 T 53000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 28 T 53800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 29 T 54600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 30 T 55400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 31 T 56200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 32 T 57000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 33 T 57800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 34 T 58600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 35 T 59400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 36 T 60200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 37 T 61000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 38 T 61800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 39 T 62600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 40 T 63400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 41 T 64200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 42 T 65000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 43 T 65800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 44 T 66600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 45 T 67400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 46 T 68200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 47 T 69000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 48 T 69800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 49 T 70600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 50 T 71400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 51 T 72200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 52 T 73000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 53 T 73800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 54 T 74600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 55 T 75400 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 56 T 76200 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 57 T 77000 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 58 T 77800 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 59 T 78600 8MHz AUTO NONE QAM64 8k 1/32 NONE #Channel UHF 60 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR v3.16] uvcvideo fixes
Hi William, On Friday 09 May 2014 14:33:57 William Manley wrote: Hi Laurent Any chance of my patch fixing manual exposure mode for the Logitech C920[1] going in for 3.16? I know I've been largely unresponsive regarding this patch, and I'm really ashamed for that. I would have liked to get feedback from Logitech on the issue, but they've been mostly silent so far. I'll thus apply your patch even though I'm still bothered by the issue, we can always revisit it later if needed. [1]: https://patchwork.linuxtv.org/patch/23047/ -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: 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: Tue May 13 04:00:29 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/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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
[PATCH v4 0/2] Add resolution change event
This patchset adds a source_change event to the v4l2-events. This can be used for notifying the userspace about runtime format changes happening on video nodes / pads like resolution change in video decoder. Changes from v3 -- - Addressed comments from Laurent / Hans https://patchwork.kernel.org/patch/4135731/ Changes from v2 --- - Event can be subscribed on specific pad / port as suggested by Hans. Changes from v1 --- - Addressed review comments from Hans and Laurent https://patchwork.kernel.org/patch/4000951/ Arun Kumar K (1): [media] v4l: Add source change event Pawel Osciak (1): [media] s5p-mfc: Add support for resolution change event Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 32 + .../DocBook/media/v4l/vidioc-subscribe-event.xml | 19 +++ drivers/media/platform/s5p-mfc/s5p_mfc.c |7 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |2 ++ drivers/media/v4l2-core/v4l2-event.c | 36 include/media/v4l2-event.h |4 +++ include/uapi/linux/videodev2.h |8 + 7 files changed, 108 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/2] [media] s5p-mfc: Add support for resolution change event
From: Pawel Osciak posc...@chromium.org
When a resolution change point is reached, queue an event to signal the
userspace that a new set of buffers is required before decoding can
continue.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c |7 +++
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |2 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 54f7ba1..2d7d1ae 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -320,6 +320,7 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
struct s5p_mfc_buf *src_buf;
unsigned long flags;
unsigned int res_change;
+ struct v4l2_event ev;
dst_frame_status = s5p_mfc_hw_call(dev-mfc_ops, get_dspl_status, dev)
S5P_FIMV_DEC_STATUS_DECODING_STATUS_MASK;
@@ -351,6 +352,12 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
if (ctx-state == MFCINST_RES_CHANGE_FLUSH) {
s5p_mfc_handle_frame_all_extracted(ctx);
ctx-state = MFCINST_RES_CHANGE_END;
+
+ memset(ev, 0, sizeof(struct v4l2_event));
+ ev.type = V4L2_EVENT_SOURCE_CHANGE;
+ ev.u.src_change.changes = V4L2_EVENT_SRC_CH_RESOLUTION;
+ v4l2_event_queue_fh(ctx-fh, ev);
+
goto leave_handle_frame;
} else {
s5p_mfc_handle_frame_all_extracted(ctx);
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 4f94491..b383829 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -855,6 +855,8 @@ static int vidioc_subscribe_event(struct v4l2_fh *fh,
switch (sub-type) {
case V4L2_EVENT_EOS:
return v4l2_event_subscribe(fh, sub, 2, NULL);
+ case V4L2_EVENT_SOURCE_CHANGE:
+ return v4l2_src_change_event_subscribe(fh, sub);
default:
return -EINVAL;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
