cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sat Dec 24 05:00:17 CET 2016 media-tree git hash:c739c0a7c3c2472d7562b8f802cdce44d2597c8b media_build git hash: 1606032398b1d79149c1507be2029e1a00d8dff0 v4l-utils git hash: c9aacef24d152007c7344b691da0cc90788395a7 gcc version:i686-linux-gcc (GCC) 6.2.0 sparse version: v0.5.0-3553-g78b2ea6 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.8.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: 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.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: WARNINGS linux-3.11.1-i686: OK linux-3.12.67-i686: OK linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: ERRORS linux-3.18.7-i686: ERRORS linux-3.19-i686: ERRORS linux-4.0.9-i686: ERRORS linux-4.1.33-i686: ERRORS linux-4.2.8-i686: ERRORS linux-4.3.6-i686: ERRORS linux-4.4.22-i686: ERRORS linux-4.5.7-i686: ERRORS linux-4.6.7-i686: ERRORS linux-4.7.5-i686: ERRORS linux-4.8-i686: OK linux-4.9-i686: OK linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: OK linux-3.12.67-x86_64: OK linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16.7-x86_64: WARNINGS linux-3.17.8-x86_64: ERRORS linux-3.18.7-x86_64: ERRORS linux-3.19-x86_64: ERRORS linux-4.0.9-x86_64: ERRORS linux-4.1.33-x86_64: ERRORS linux-4.2.8-x86_64: ERRORS linux-4.3.6-x86_64: ERRORS linux-4.4.22-x86_64: ERRORS linux-4.5.7-x86_64: ERRORS linux-4.6.7-x86_64: ERRORS linux-4.7.5-x86_64: ERRORS linux-4.8-x86_64: OK linux-4.9-x86_64: OK apps: WARNINGS spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.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 v5] media: video-i2c: add video-i2c driver
There are several thermal sensors that only have a low-speed bus
interface but output valid video data. This patchset enables support
for the AMG88xx "Grid-Eye" sensor family.
Cc: Attila Kinali
Cc: Marek Vasut
Cc: Luca Barbato
Cc: Laurent Pinchart
Signed-off-by: Matt Ranostay
---
Changes from v1:
* correct i2c_polling_remove() operations
* fixed delay calcuation in buffer_queue()
* add include linux/slab.h
Changes from v2:
* fix build error due to typo in include of slab.h
Changes from v3:
* switch data transport to a kthread to avoid to .buf_queue that can't sleep
* change naming from i2c-polling to video-i2c
* make the driver for single chipset under another uses the driver
Changes from v4:
* fix wraparound issue with jiffies and schedule_timeout_interruptible()
drivers/media/i2c/Kconfig | 9 +
drivers/media/i2c/Makefile| 1 +
drivers/media/i2c/video-i2c.c | 569 ++
3 files changed, 579 insertions(+)
create mode 100644 drivers/media/i2c/video-i2c.c
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index b31fa6fae009..ef84715293a9 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -768,6 +768,15 @@ config VIDEO_M52790
To compile this driver as a module, choose M here: the
module will be called m52790.
+
+config VIDEO_I2C
+ tristate "I2C transport video support"
+ depends on VIDEO_V4L2 && I2C
+ select VIDEOBUF2_VMALLOC
+ ---help---
+ Enable the I2C transport video support which supports the
+ following:
+ * Panasonic AMG88xx Grid-Eye Sensors
endmenu
menu "Sensors used on soc_camera driver"
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 92773b2e6225..7c8eeb213c3b 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -79,6 +79,7 @@ obj-$(CONFIG_VIDEO_LM3646)+= lm3646.o
obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
+obj-$(CONFIG_VIDEO_I2C)+= video-i2c.o
obj-$(CONFIG_VIDEO_ML86V7667) += ml86v7667.o
obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
obj-$(CONFIG_VIDEO_TC358743) += tc358743.o
diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
new file mode 100644
index ..9390560bd117
--- /dev/null
+++ b/drivers/media/i2c/video-i2c.c
@@ -0,0 +1,569 @@
+/*
+ * video-i2c.c - Support for I2C transport video devices
+ *
+ * Copyright (C) 2016 Matt Ranostay
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Supported:
+ * - Panasonic AMG88xx Grid-Eye Sensors
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define VIDEO_I2C_DRIVER "video-i2c"
+#define MAX_BUFFER_SIZE128
+
+struct video_i2c_chip;
+
+struct video_i2c_buffer {
+ struct vb2_v4l2_buffer vb;
+ struct list_head list;
+};
+
+struct video_i2c_data {
+ struct i2c_client *client;
+ const struct video_i2c_chip *chip;
+ struct mutex lock;
+ spinlock_t slock;
+ struct mutex queue_lock;
+
+ struct v4l2_device v4l2_dev;
+ struct video_device vdev;
+ struct vb2_queue vb_vidq;
+
+ struct task_struct *kthread_vid_cap;
+ struct list_head vid_cap_active;
+};
+
+static struct v4l2_fmtdesc amg88xx_format = {
+ .description = "12-bit Greyscale",
+ .pixelformat = V4L2_PIX_FMT_Y12,
+};
+
+static struct v4l2_frmsize_discrete amg88xx_size = {
+ .width = 8,
+ .height = 8,
+};
+
+struct video_i2c_chip {
+ /* video dimensions */
+ struct v4l2_fmtdesc *format;
+ struct v4l2_frmsize_discrete *size;
+
+ /* max frames per second */
+ unsigned int max_fps;
+
+ /* pixel buffer size */
+ unsigned int buffer_size;
+
+ /* pixel size in bits */
+ unsigned int bpp;
+
+ /* xfer function */
+ int (*xfer)(struct video_i2c_data *data, char *buf);
+};
+
+static int amg88xx_xfer(struct video_i2c_data *data, char *buf)
+{
+ struct i2c_client *client = data->client;
+ struct i2c_msg msg[2];
+ u8 reg = 0x80;
+ int ret;
+
+ msg[0].addr = client->addr;
+ msg[0].flags = 0;
+ msg[0].len = 1;
+ msg[0].buf = (char *) ®
+
+ msg[1].addr = client->addr;
+ msg[1].flags = I2C_M_RD;
+ msg[1].len
Re: [RFC/PATCH] media: Add video bus switch
Hi!
Ok, this should be closer to something working. (But it does not work,
yet).
Pavel
diff --git a/Documentation/devicetree/bindings/media/video-bus-switch.txt
b/Documentation/devicetree/bindings/media/video-bus-switch.txt
new file mode 100644
index 000..1b9f8e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/video-bus-switch.txt
@@ -0,0 +1,63 @@
+Video Bus Switch Binding
+
+
+This is a binding for a gpio controlled switch for camera interfaces. Such a
+device is used on some embedded devices to connect two cameras to the same
+interface of a image signal processor.
+
+Required properties
+===
+
+compatible : must contain "video-bus-switch"
+switch-gpios : GPIO specifier for the gpio, which can toggle the
+ selected camera. The GPIO should be configured, so
+ that a disabled GPIO means, that the first port is
+ selected.
+
+Required Port nodes
+===
+
+More documentation on these bindings is available in
+video-interfaces.txt in the same directory.
+
+reg: The interface:
+ 0 - port for image signal processor
+ 1 - port for first camera sensor
+ 2 - port for second camera sensor
+
+Example
+===
+
+video-bus-switch {
+ compatible = "video-bus-switch"
+ switch-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ csi_switch_in: endpoint {
+ remote-endpoint = <&csi_isp>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ csi_switch_out1: endpoint {
+ remote-endpoint = <&csi_cam1>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ csi_switch_out2: endpoint {
+ remote-endpoint = <&csi_cam2>;
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 8043290..7189dfd 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -230,6 +230,15 @@
csi_switch_out1: endpoint {
remote-endpoint = <&csi_cam1>;
+ bus-type = <3>; /* CCP2 */
+ clock-lanes = <0>;
+ data-lanes = <1>;
+ lane-polarity = <0 0>;
+ clock-inv = <0>;
+ /* Select strobe = <1> for back camera, <0> for
front camera */
+ strobe = <1>;
+ crc = <0>;
+
};
};
@@ -238,6 +247,15 @@
csi_switch_out2: endpoint {
remote-endpoint = <&csi_cam2>;
+ bus-type = <3>; /* CCP2 */
+ clock-lanes = <0>;
+ data-lanes = <1>;
+ lane-polarity = <0 0>;
+ clock-inv = <0>;
+ /* Select strobe = <1> for back camera, <0> for
front camera */
+ strobe = <0>;
+ crc = <0>;
+
};
};
};
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index 45c69ed..f0aa8cd 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -2024,44 +2054,51 @@ enum isp_of_phy {
ISP_OF_PHY_CSIPHY2,
};
-static void isp_of_parse_node_csi1(struct device *dev,
- struct isp_bus_cfg *buscfg,
+void __isp_of_parse_node_csi1(struct device *dev,
+ struct isp_ccp2_cfg *buscfg,
struct v4l2_of_endpoint *vep)
{
- if (vep->base.port == ISP_OF_PHY_CSIPHY1)
- buscfg->interface = ISP_INTERFACE_CCP2B_PHY1;
- else
- buscfg->interface = ISP_INTERFACE_CCP2B_PHY2;
- buscfg->bus.ccp2.lanecfg.clk.pos = vep->bus.mipi_csi1.clock_lane;
- buscfg->bus.ccp2.lanecfg.clk.pol =
+ buscfg->lanecfg.clk.pos = vep->bus.mipi_csi1.clock_lane;
+ buscfg->lanecfg.clk.pol =
vep->bus.mipi_csi1.lane_polarity[0];
[PATCH] media: usb: cpia2: Use kmemdup instead of kmalloc and memcpy
When some other buffer is immediately copied into allocated region. Replace calls to kmalloc followed by a memcpy with a direct call to kmemdup. Signed-off-by: Shyam Saini --- drivers/media/usb/cpia2/cpia2_usb.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/media/usb/cpia2/cpia2_usb.c b/drivers/media/usb/cpia2/cpia2_usb.c index 37f9b30..ce36331 100644 --- a/drivers/media/usb/cpia2/cpia2_usb.c +++ b/drivers/media/usb/cpia2/cpia2_usb.c @@ -551,12 +551,10 @@ static int write_packet(struct usb_device *udev, if (!registers || size <= 0) return -EINVAL; - buf = kmalloc(size, GFP_KERNEL); + buf = kmemdup(registers, size, GFP_KERNEL); if (!buf) return -ENOMEM; - memcpy(buf, registers, size); - ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0), request, -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] media: Add video bus switch
Hi,
On 23.12.2016 13:42, Pavel Machek wrote:
Hi!
[...]
static int isp_subdev_notifier_bound(struct v4l2_async_notifier *async,
diff --git a/drivers/media/platform/video-bus-switch.c
b/drivers/media/platform/video-bus-switch.c
index 1a5d944..3a2d442 100644
--- a/drivers/media/platform/video-bus-switch.c
+++ b/drivers/media/platform/video-bus-switch.c
@@ -247,12 +247,21 @@ static int vbs_s_stream(struct v4l2_subdev *sd, int
enable)
{
struct v4l2_subdev *subdev = vbs_get_remote_subdev(sd);
+ /* FIXME: we need to set the GPIO here */
+
The gpio is set when the pad is selected, so no need to do it again.
The gpio selection actually works with your branch (assuming its
based on Ivo's).
Yes. I did not notice... is there actually some interface to select
the camera from userland?
When you construct the pipeline, you enable the port you need in vbs, so
the camera is selected.
I used (similar to)this by the time I played with cameras:
front:
export LD_LIBRARY_PATH=./
./media-ctl -r
./media-ctl -l '"vs6555 binner 2-0010":1 -> "video-bus-switch":2 [1]'
./media-ctl -l '"video-bus-switch":0 -> "OMAP3 ISP CCP2":0 [1]'
./media-ctl -l '"OMAP3 ISP CCP2":1 -> "OMAP3 ISP CCDC":0 [1]'
./media-ctl -l '"OMAP3 ISP CCDC":2 -> "OMAP3 ISP preview":0 [1]'
./media-ctl -l '"OMAP3 ISP preview":1 -> "OMAP3 ISP resizer":0 [1]'
./media-ctl -l '"OMAP3 ISP resizer":1 -> "OMAP3 ISP resizer output":0 [1]'
./media-ctl -V '"vs6555 pixel array 2-0010":0 [SGRBG10/648x488
(0,0)/648x488 (0,0)/648x488]'
./media-ctl -V '"vs6555 binner 2-0010":1 [SGRBG10/648x488 (0,0)/648x488
(0,0)/648x488]'
./media-ctl -V '"OMAP3 ISP CCP2":0 [SGRBG10 648x488]'
./media-ctl -V '"OMAP3 ISP CCP2":1 [SGRBG10 648x488]'
./media-ctl -V '"OMAP3 ISP CCDC":2 [SGRBG10 648x488]'
./media-ctl -V '"OMAP3 ISP preview":1 [UYVY 648x488]'
./media-ctl -V '"OMAP3 ISP resizer":1 [UYVY 656x488]'
mplayer -tv
driver=v4l2:width=656:height=488:outfmt=uyvy:device=/dev/video6 -vo xv
-vf screenshot tv://
back:
export LD_LIBRARY_PATH=./
./media-ctl -r
./media-ctl -l '"et8ek8 3-003e":0 -> "video-bus-switch":1 [1]'
./media-ctl -l '"video-bus-switch":0 -> "OMAP3 ISP CCP2":0 [1]'
./media-ctl -l '"OMAP3 ISP CCP2":1 -> "OMAP3 ISP CCDC":0 [1]'
./media-ctl -l '"OMAP3 ISP CCDC":2 -> "OMAP3 ISP preview":0 [1]'
./media-ctl -l '"OMAP3 ISP preview":1 -> "OMAP3 ISP resizer":0 [1]'
./media-ctl -l '"OMAP3 ISP resizer":1 -> "OMAP3 ISP resizer output":0 [1]'
./media-ctl -V '"et8ek8 3-003e":0 [SGRBG10 864x656]'
./media-ctl -V '"OMAP3 ISP CCP2":0 [SGRBG10 864x656]'
./media-ctl -V '"OMAP3 ISP CCP2":1 [SGRBG10 864x656]'
./media-ctl -V '"OMAP3 ISP CCDC":2 [SGRBG10 864x656]'
./media-ctl -V '"OMAP3 ISP preview":1 [UYVY 864x656]'
./media-ctl -V '"OMAP3 ISP resizer":1 [UYVY 800x480]'
mplayer -tv
driver=v4l2:width=800:height=480:outfmt=uyvy:device=/dev/video6 -vo xv
-vf screenshot tv://
or IOW:
./media-ctl -l '"vs6555 binner 2-0010":1 -> "video-bus-switch":2 [1]'
switches GPIO to use front camera
and
./media-ctl -l '"video-bus-switch":0 -> "OMAP3 ISP CCP2":0 [1]'
for back camera
Ivo
--
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 v3 00/21] Make use of kref in media device, grab references as needed
Hi Shuah, On Thursday 15 Dec 2016 09:06:41 Shuah Khan wrote: > On 12/15/2016 08:26 AM, Hans Verkuil wrote: > > On 15/12/16 15:45, Shuah Khan wrote: > >> On 12/15/2016 07:03 AM, Hans Verkuil wrote: > >>> On 15/12/16 13:56, Laurent Pinchart wrote: > On Thursday 15 Dec 2016 13:30:41 Sakari Ailus wrote: > > On Tue, Dec 13, 2016 at 10:24:47AM -0200, Mauro Carvalho Chehab wrote: > >> Em Tue, 13 Dec 2016 12:53:05 +0200 Sakari Ailus escreveu: > >>> On Tue, Nov 29, 2016 at 09:13:05AM -0200, Mauro Carvalho Chehab wrote: [snip] > >>> In my view the main problem is that the media core is bound to a struct > >>> device set by the driver that creates the MC. But since the MC gives an > >>> overview of lots of other (sub)devices the refcount of the media device > >>> should be increased for any (sub)device that adds itself to the MC and > >>> decreased for any (sub)device that is removed. Only when the very last > >>> user goes away can the MC memory be released. > >> > >> Correct. Media Device Allocator API work I did allows creating media > >> device on parent USB device to allow media sound driver share the media > >> device. It does ref-counting on media device and media device is > >> unregistered only when the last driver unregisters it. > >> > >> There is another aspect to explore regarding media device and the graph. > >> > >> Should all the entities stick around until all references to media > >> device are gone? If an application has /dev/media open, does that > >> mean all entities should not be free'd until this app. exits? What > >> should happen if an app. is streaming? Should the graph stay intact > >> until the app. exits? > > > > Yes, everything must stay around until the last user has disappeared. > > > > In general unplugs can happen at any time. So applications can be in the > > middle of an ioctl, and removing memory during that time is just > > impossible. > > > > On unplug you: > > > > 1) stop any HW DMA (highly device dependent) > > 2) wake up any filehandles that wait for an event > > 3) unregister any device nodes > > > > Then just sit back and wait for refcounts to go down as filehandles are > > closed by the application. > > > > Note: the v4l2/media/cec/IR/whatever core is typically responsible for > > rejecting any ioctls/mmap/etc. once the device node has been > > unregistered. The only valid file operation is release(). > > > >>If yes, this would pose problems when we have multiple drivers bound > >>to the media device. When audio driver goes away for example, it > >>should > >>be allowed to delete its entities. > > > > Only if you can safely remove it from the topology data structures while > > being 100% certain that nobody can ever access it. I'm not sure if that is > > the case. Actually, looking at e.g. adv7604.c it does > > media_entity_cleanup(&sd->entity); in remove() which is an empty > > function, so there doesn't appear any attempt to safely clean up an > > entity (i.e. make sure no running media ioctl can access it or call ops). > > Right. media_entity_cleanup() nothing at the moment. Also if it gets called > after media_device_unregister_entity(), it could pose problems. I wonder if > we have drivers that are calling media_entity_cleanup() after unregistering > the entity? > > > This probably will need to be serialized with the graph_mutex lock. > > > >> The approach current mc-core takes is that the media_device and > >> media_devnode stick around, but entities can be added and removed during > >> media_device lifetime. > > > > Seems reasonable. But the removal needs to be done carefully, and that > > doesn't seem to be the case now (unless adv7604.c is just buggy). > > Correct. It is possible media_device is embedded in this driver. I assume you mean the private data structure instantiated by the adv7604 driver. That can't be the case, as adv7604 is a subdev. > When driver that embeds is unbound, media_device goes away. I needed to make > the media device refcounted and sharable for audio work and that is what the > Media Device Allocator API does. > > Maybe we have more cases than this audio case that requires media_device > refcounted. If we have to keep entities that are in use until all the > references go away, we have to ref-count them as well. I think we're converging towards refcounting media_device to manage its lifetime, so there's more cases, yes. That's why I propose first making media_device refcounted, and then adding the allocator API on top of that given that the allocator API requires refcounting. That seems to me to be the cleanest approach. > >> If an app. is still running when media_device is unregistered, > >> media_device isn't released until the last reference goes away and ioctls > >> can check if media_device is registered or not. > >> > >> We have to decide on the larger lifetime question surrounding > >> media_device and graph as well. > > > > I don't think there is any choice but to k
Re: [RFC v3 00/21] Make use of kref in media device, grab references as needed
Hi Mauro, On Thursday 15 Dec 2016 15:08:26 Mauro Carvalho Chehab wrote: > Em Thu, 15 Dec 2016 16:26:19 +0100 Hans Verkuil escreveu: > >> Should all the entities stick around until all references to media > >> device are gone? If an application has /dev/media open, does that > >> mean all entities should not be free'd until this app. exits? What > >> should happen if an app. is streaming? Should the graph stay intact > >> until the app. exits? > > > > Yes, everything must stay around until the last user has disappeared. > > > > In general unplugs can happen at any time. So applications can be in the > > middle of an ioctl, and removing memory during that time is just > > impossible. > > > > On unplug you: > > > > 1) stop any HW DMA (highly device dependent) > > 2) wake up any filehandles that wait for an event > > 3) unregister any device nodes > > > > Then just sit back and wait for refcounts to go down as filehandles are > > closed by the application. > > > > Note: the v4l2/media/cec/IR/whatever core is typically responsible for > > rejecting any ioctls/mmap/etc. once the device node has been > > unregistered. The only valid file operation is release(). > > Agreed. The problem on OMAP3 is that it doesn't stop HW DMA when > struct media_devnode is released. It tries to do it later, when the > V4L2 core is unbind, by trying to dig into the media controller > struct that the driver removed before. Note that stopping the hardware doesn't mean updating the pipeline state to mark it as stopped. Unlike stopping the hardware that is mandatory at unbind time as hardware access is not allowed after the unbind handler returns, how we handle the software state is entirely up to us. I'm not saying it can't be done at unbind time, but I'm not sure yet whether it should either. > That's said, for OMAP3 and all other drivers that don't support hot unplug, > I would just use suppress_bind_attrs, as I fail to see any need to allow > unbinding them. That's akin to breaking the thermometer to cure the patient from fever. I'm not completely opposed to making drivers non-unbindable in a case-by-case basis (and based on the author's will), but if a driver author wants to make a driver unbindable the core should allow that to be implemented. -- 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: [RFC v3 00/21] Make use of kref in media device, grab references as needed
Hi Hans, On Thursday 15 Dec 2016 16:26:19 Hans Verkuil wrote: > On 15/12/16 15:45, Shuah Khan wrote: > > On 12/15/2016 07:03 AM, Hans Verkuil wrote: [snip] > >> In my view the main problem is that the media core is bound to a struct > >> device set by the driver that creates the MC. But since the MC gives an > >> overview of lots of other (sub)devices the refcount of the media device > >> should be increased for any (sub)device that adds itself to the MC and > >> decreased for any (sub)device that is removed. Only when the very last > >> user goes away can the MC memory be released. > > > > Correct. Media Device Allocator API work I did allows creating media > > device on parent USB device to allow media sound driver share the media > > device. It does ref-counting on media device and media device is > > unregistered only when the last driver unregisters it. > > > > There is another aspect to explore regarding media device and the graph. > > > > Should all the entities stick around until all references to media > > device are gone? If an application has /dev/media open, does that > > mean all entities should not be free'd until this app. exits? What > > should happen if an app. is streaming? Should the graph stay intact > > until the app. exits? > > Yes, everything must stay around until the last user has disappeared. > > In general unplugs can happen at any time. So applications can be in the > middle of an ioctl, and removing memory during that time is just > impossible. > > On unplug you: > > 1) stop any HW DMA (highly device dependent) > 2) wake up any filehandles that wait for an event > 3) unregister any device nodes Shouldn't 2 and 3 be switched ? We also need to return all buffers to vb2 without any race condition, so I would say the sequence of events should be as follows. 1. Mark the device as being disconnected. This condition should be tested by the .buf_queue() handler that will then return the buffer immediately to vb2 with the state set to VB2_BUF_STATE_ERROR. 2. Stop hardware operation (DMA, interrupts, ...). 3. Unregister the devnodes. This shall result in all new ioctl calls being blocked by the core. 4. Wake up all waiters. There's still a race between 2 and 3, as new hardware operations could be started. We need to decide how to handle that. The uvcvideo driver handles this in a reasonably clean way (at least for the video devnodes, there are races related to the media controller devnode), but the driver-side implementation is a bit complex (look at the comment in uvc_queue_cancel(), and how uvc_unregister_video() has to increase the refcount temporarily for instance) even if the fact that the USB core stops hardware access simplifies step 2 above. It would be nice if we could move some of the code to the core. > Then just sit back and wait for refcounts to go down as filehandles are > closed by the application. Sit back doesn't mean that the unbind handler (.remove for platform devices, .disconnect for USB devices, ...) blocks, right ? It should return after completing the steps above, > Note: the v4l2/media/cec/IR/whatever core is typically responsible for > rejecting any ioctls/mmap/etc. once the device node has been unregistered. > The only valid file operation is release(). That's a very good start. The hard part is then the handling of ioctls in progress. > >If yes, this would pose problems when we have multiple drivers bound > >to the media device. When audio driver goes away for example, it should > >be allowed to delete its entities. > > Only if you can safely remove it from the topology data structures while > being 100% certain that nobody can ever access it. I'm not sure if that is > the case. In some cases it might be, but I don't think we can build anything on top of that assumption. > Actually, looking at e.g. adv7604.c it does > media_entity_cleanup(&sd->entity); in remove() which is an empty function, > so there doesn't appear any attempt to safely clean up an entity (i.e. make > sure no running media ioctl can access it or call ops). > > This probably will need to be serialized with the graph_mutex lock. In the worst case, but we should try to minimize lock contention with proper refcounting. > > The approach current mc-core takes is that the media_device and > > media_devnode stick around, but entities can be added and removed during > > media_device lifetime. > > Seems reasonable. But the removal needs to be done carefully, and that > doesn't seem to be the case now (unless adv7604.c is just buggy). > > > If an app. is still running when media_device is unregistered, > > media_device isn't released until the last reference goes away and ioctls > > can check if media_device is registered or not. > > > > We have to decide on the larger lifetime question surrounding media_device > > and graph as well. > > I don't think there is any choice but to keep it all alive until the last > reference goes away. I agree wi
Re: [RFC v3 00/21] Make use of kref in media device, grab references as needed
Hi Shuah, On Thursday 15 Dec 2016 07:45:29 Shuah Khan wrote: > On 12/15/2016 07:03 AM, Hans Verkuil wrote: > > On 15/12/16 13:56, Laurent Pinchart wrote: > >> On Thursday 15 Dec 2016 13:30:41 Sakari Ailus wrote: > >>> On Tue, Dec 13, 2016 at 10:24:47AM -0200, Mauro Carvalho Chehab wrote: > Em Tue, 13 Dec 2016 12:53:05 +0200 Sakari Ailus escreveu: > > On Tue, Nov 29, 2016 at 09:13:05AM -0200, Mauro Carvalho Chehab wrote: [snip] > >> There's plenty of way to try and work around the problem in drivers, some > >> more racy than others, but if we require changes to all platform drivers > >> to fix this we need to ensure that we get it right, not as half-baked > >> hacks spread around the whole subsystem. > > > > Why on earth do we want this for the omap3 driver? It is not a > > hot-pluggable device and I see no reason whatsoever to start modifying > > platform drivers just because you can do an unbind. I know there are real > > hot-pluggable devices, and getting this right for those is of course > > important. > > This was my first reaction when I saw this RFC series. None of the platform > drivers are designed to be unbound. Making core changes based on such as > driver would make the core very complex. > > We can't even reproduce the problem on other drivers. > > > If the omap3 is used as a testbed, then that's fine by me, but even then I > > probably wouldn't want the omap3 code that makes this possible in the > > kernel. It's just additional code for no purpose. > > I agree with Hans. Why are we using the most complex case as a reference > driver The omap3isp driver is a very good test case, as it registers a media controller device node, multiple video device nodes and multiple subdev device nodes. This is not an exceptional situation (and is actually simpler than a driver that would also register an audio device, as we would span multiple subsystems there). If we can't design a clean lifetime management solution for MC and V4L2 objects that fixes the unbind problem with omap3isp then we could as well give up on kernel development completely. > and basing that driver to make core changes which will force changes to all > the driver that use mc-core? Making changes to all drivers isn't a goal. My goal is to fix the objects lifetime management problem cleanly. If there's a way to do so that minimizes changes to drivers, great. Otherwise, we'll have to bite the bullet. The MC and V4L2 core code is the foundation on top of which everything is built, it has to be fail-proof and clean. > That could be done by overwriting the dev.release() callback at > omap3 driver, as I discussed on my past e-mails, and flagging the > driver that it should not accept streamon anymore, as the hardware > is being disconnecting. > >>> > >>> A mutex will be needed to serialise the this with starting streaming. > >>> > Btw, that explains a lot why Shuah can't reproduce the stuff you're > complaining on her USB hardware. > > The USB subsystem has a a .disconnect() callback that notifies > the drivers that a device was unbound (likely physically removed). > The way USB media drivers handle it is by returning -ENODEV to any > V4L2 call that would try to touch at the hardware after unbound. > > > > In my view the main problem is that the media core is bound to a struct > > device set by the driver that creates the MC. But since the MC gives an > > overview of lots of other (sub)devices the refcount of the media device > > should be increased for any (sub)device that adds itself to the MC and > > decreased for any (sub)device that is removed. Only when the very last > > user goes away can the MC memory be released. > > Correct. Media Device Allocator API work I did allows creating media device > on parent USB device to allow media sound driver share the media device. It > does ref-counting on media device and media device is unregistered only when > the last driver unregisters it. It doesn't address references taken to the media_device from v4l2_subdev and video_device though. I believe we need one reference counting implementation that can cover both references from other objects and media_device sharing. > There is another aspect to explore regarding media device and the graph. > > Should all the entities stick around until all references to media > device are gone? If an application has /dev/media open, does that > mean all entities should not be free'd until this app. exits? Probably not, as we need to target dynamic updates of the media graph. > What should happen if an app. is streaming? Should the graph stay intact > until the app. exits? I'll need to give this more thought, but I'd say yes. >If yes, this would pose problems when we have multiple drivers bound >to the media device. When audio driver goes away for example, it should >be allowed to delete its entities. There's two parts to "driver goes away". When the dev
Important lnbp22.c patch
Hello, don’t know if this is the right way to report, so excuse me in advance if it is wrong… While searching the internet to fix my " TT S2-3650-CI USB with HH90 Rotor“ problem (see https://forum.libreelec.tv/thread-3038.html) I found this original patch (https://www.spinics.net/lists/linux-media/msg38226.html) from the same author as the current lnbp22.c ; Since it is not yet included and not on the Incoming patches list I decided to post to you. Any chance to get this merged (at least for the lnbp22)? Thanks Ognian -- 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] media: Add video bus switch
Hi!
> > [...]
> >
> > static int isp_subdev_notifier_bound(struct v4l2_async_notifier *async,
> > diff --git a/drivers/media/platform/video-bus-switch.c
> > b/drivers/media/platform/video-bus-switch.c
> > index 1a5d944..3a2d442 100644
> > --- a/drivers/media/platform/video-bus-switch.c
> > +++ b/drivers/media/platform/video-bus-switch.c
> > @@ -247,12 +247,21 @@ static int vbs_s_stream(struct v4l2_subdev *sd, int
> > enable)
> > {
> > struct v4l2_subdev *subdev = vbs_get_remote_subdev(sd);
> >
> > + /* FIXME: we need to set the GPIO here */
> > +
>
> The gpio is set when the pad is selected, so no need to do it again.
> The gpio selection actually works with your branch (assuming its
> based on Ivo's).
Yes. I did not notice... is there actually some interface to select
the camera from userland?
> > if (IS_ERR(subdev))
> > return PTR_ERR(subdev);
> >
> > return v4l2_subdev_call(subdev, video, s_stream, enable);
> > }
> >
> > +static int vbs_g_endpoint_config(struct v4l2_subdev *sd, struct
> > isp_bus_cfg *cfg)
> > +{
> > + printk("vbs_g_endpoint_config...\n");
> > + return 0;
> > +}
>
> Would be nice to find something more abstract than isp_bus_cfg,
> which is specific to omap3isp.
Yes, that should be doable.
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index 45c69ed..f0aa8cd 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -2024,44 +2054,51 @@ enum isp_of_phy {
ISP_OF_PHY_CSIPHY2,
};
-static void isp_of_parse_node_csi1(struct device *dev,
- struct isp_bus_cfg *buscfg,
+void __isp_of_parse_node_csi1(struct device *dev,
+ struct isp_ccp2_cfg *buscfg,
struct v4l2_of_endpoint *vep)
{
- if (vep->base.port == ISP_OF_PHY_CSIPHY1)
- buscfg->interface = ISP_INTERFACE_CCP2B_PHY1;
- else
- buscfg->interface = ISP_INTERFACE_CCP2B_PHY2;
- buscfg->bus.ccp2.lanecfg.clk.pos = vep->bus.mipi_csi1.clock_lane;
- buscfg->bus.ccp2.lanecfg.clk.pol =
+ buscfg->lanecfg.clk.pos = vep->bus.mipi_csi1.clock_lane;
+ buscfg->lanecfg.clk.pol =
vep->bus.mipi_csi1.lane_polarity[0];
dev_dbg(dev, "clock lane polarity %u, pos %u\n",
- buscfg->bus.ccp2.lanecfg.clk.pol,
- buscfg->bus.ccp2.lanecfg.clk.pos);
+ buscfg->lanecfg.clk.pol,
+ buscfg->lanecfg.clk.pos);
- buscfg->bus.ccp2.lanecfg.data[0].pos = vep->bus.mipi_csi2.data_lanes[0];
- buscfg->bus.ccp2.lanecfg.data[0].pol =
+ buscfg->lanecfg.data[0].pos = vep->bus.mipi_csi2.data_lanes[0];
+ buscfg->lanecfg.data[0].pol =
vep->bus.mipi_csi2.lane_polarities[1];
dev_dbg(dev, "data lane polarity %u, pos %u\n",
- buscfg->bus.ccp2.lanecfg.data[0].pol,
- buscfg->bus.ccp2.lanecfg.data[0].pos);
+ buscfg->lanecfg.data[0].pol,
+ buscfg->lanecfg.data[0].pos);
- buscfg->bus.ccp2.strobe_clk_pol = vep->bus.mipi_csi1.clock_inv;
- buscfg->bus.ccp2.phy_layer = vep->bus.mipi_csi1.strobe;
- buscfg->bus.ccp2.ccp2_mode = vep->bus_type == V4L2_MBUS_CCP2;
+ buscfg->strobe_clk_pol = vep->bus.mipi_csi1.clock_inv;
+ buscfg->phy_layer = vep->bus.mipi_csi1.strobe;
+ buscfg->ccp2_mode = vep->bus_type == V4L2_MBUS_CCP2;
dev_dbg(dev, "clock_inv %u strobe %u ccp2 %u\n",
- buscfg->bus.ccp2.strobe_clk_pol,
- buscfg->bus.ccp2.phy_layer,
- buscfg->bus.ccp2.ccp2_mode);
+ buscfg->strobe_clk_pol,
+ buscfg->phy_layer,
+ buscfg->ccp2_mode);
/*
* FIXME: now we assume the CRC is always there.
* Implement a way to obtain this information from the
* sensor. Frame descriptors, perhaps?
*/
- buscfg->bus.ccp2.crc = 1;
+ buscfg->crc = 1;
- buscfg->bus.ccp2.vp_clk_pol = 1;
+ buscfg->vp_clk_pol = 1;
+}
+
+static void isp_of_parse_node_csi1(struct device *dev,
+ struct isp_bus_cfg *buscfg,
+ struct v4l2_of_endpoint *vep)
+{
+ if (vep->base.port == ISP_OF_PHY_CSIPHY1)
+ buscfg->interface = ISP_INTERFACE_CCP2B_PHY1;
+ else
+ buscfg->interface = ISP_INTERFACE_CCP2B_PHY2;
+ __isp_of_parse_node_csi1(dev, &buscfg->bus.ccp2, vep);
}
static void isp_of_parse_node_csi2(struct device *dev,
@@ -2099,27 +2136,8 @@ static void isp_of_parse_node_csi2(struct device *dev,
buscfg->bus.csi2.crc = 1;
}
-static int isp_of_parse_node_endpoint(struct device *dev,
- struct device_node *node,
- struct isp_async_subdev *isd)
+static int isp_endpoint_to_buscfg(struct device
[PATCH] [media] atmel-isc: add the isc pipeline function
Image Sensor Controller has an internal image processor. It can convert raw format to the other formats, like RGB565, YUV420P. A module parameter 'sensor_preferred' is used to enable or disable the pipeline function. Some v4l2 controls are added to tuning the image when the pipeline function is enabled. Signed-off-by: Songjun Wu --- drivers/media/platform/atmel/atmel-isc-regs.h | 102 - drivers/media/platform/atmel/atmel-isc.c | 629 +- 2 files changed, 623 insertions(+), 108 deletions(-) diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h index 00c449717cde..6936ac467609 100644 --- a/drivers/media/platform/atmel/atmel-isc-regs.h +++ b/drivers/media/platform/atmel/atmel-isc-regs.h @@ -65,6 +65,7 @@ #define ISC_INTSR 0x0034 #define ISC_INT_DDONE BIT(8) +#define ISC_INT_HISDONEBIT(12) /* ISC White Balance Control Register */ #define ISC_WB_CTRL 0x0058 @@ -72,30 +73,98 @@ /* ISC White Balance Configuration Register */ #define ISC_WB_CFG 0x005c +/* ISC White Balance Offset for R, GR Register */ +#define ISC_WB_O_RGR 0x0060 + +/* ISC White Balance Offset for B, GB Register */ +#define ISC_WB_O_BGR 0x0064 + +/* ISC White Balance Gain for R, GR Register */ +#define ISC_WB_G_RGR 0x0068 + +/* ISC White Balance Gain for B, GB Register */ +#define ISC_WB_G_BGR 0x006c + /* ISC Color Filter Array Control Register */ #define ISC_CFA_CTRL0x0070 /* ISC Color Filter Array Configuration Register */ #define ISC_CFA_CFG 0x0074 +#define ISC_CFA_CFG_EITPOL BIT(4) #define ISC_BAY_CFG_GRGR 0x0 #define ISC_BAY_CFG_RGRG 0x1 #define ISC_BAY_CFG_GBGB 0x2 #define ISC_BAY_CFG_BGBG 0x3 -#define ISC_BAY_CFG_MASK GENMASK(1, 0) /* ISC Color Correction Control Register */ #define ISC_CC_CTRL 0x0078 +/* ISC Color Correction RR RG Register */ +#define ISC_CC_RR_RG 0x007c + +/* ISC Color Correction RB OR Register */ +#define ISC_CC_RB_OR 0x0080 + +/* ISC Color Correction GR GG Register */ +#define ISC_CC_GR_GG 0x0084 + +/* ISC Color Correction GB OG Register */ +#define ISC_CC_GB_OG 0x0088 + +/* ISC Color Correction BR BG Register */ +#define ISC_CC_BR_BG 0x008c + +/* ISC Color Correction BB OB Register */ +#define ISC_CC_BB_OB 0x0090 + /* ISC Gamma Correction Control Register */ #define ISC_GAM_CTRL0x0094 +/* ISC_Gamma Correction Blue Entry Register */ +#define ISC_GAM_BENTRY 0x0098 + +/* ISC_Gamma Correction Green Entry Register */ +#define ISC_GAM_GENTRY 0x0198 + +/* ISC_Gamma Correction Green Entry Register */ +#define ISC_GAM_RENTRY 0x0298 + /* Color Space Conversion Control Register */ #define ISC_CSC_CTRL0x0398 +/* Color Space Conversion YR YG Register */ +#define ISC_CSC_YR_YG 0x039c + +/* Color Space Conversion YB OY Register */ +#define ISC_CSC_YB_OY 0x03a0 + +/* Color Space Conversion CBR CBG Register */ +#define ISC_CSC_CBR_CBG0x03a4 + +/* Color Space Conversion CBB OCB Register */ +#define ISC_CSC_CBB_OCB0x03a8 + +/* Color Space Conversion CRR CRG Register */ +#define ISC_CSC_CRR_CRG0x03ac + +/* Color Space Conversion CRB OCR Register */ +#define ISC_CSC_CRB_OCR0x03b0 + /* Contrast And Brightness Control Register */ #define ISC_CBC_CTRL0x03b4 +/* Contrast And Brightness Configuration Register */ +#define ISC_CBC_CFG0x03b8 + +/* Brightness Register */ +#define ISC_CBC_BRIGHT 0x03bc +#define ISC_CBC_BRIGHT_MASKGENMASK(10, 0) + +/* Contrast Register */ +#define ISC_CBC_CONTRAST 0x03c0 +#define ISC_CBC_CONTRAST_MASK GENMASK(11, 0) + /* Subsampling 4:4:4 to 4:2:2 Control Register */ #define ISC_SUB422_CTRL 0x03c4 @@ -120,6 +189,27 @@ #define ISC_RLP_CFG_MODE_YYCC_LIMITED 0xc #define ISC_RLP_CFG_MODE_MASK GENMASK(3, 0) +/* Histogram Control Register */ +#define ISC_HIS_CTRL 0x03d4 + +#define ISC_HIS_CTRL_ENBIT(0) +#define ISC_HIS_CTRL_DIS 0x0 + +/* Histogram Configuration Register */ +#define ISC_HIS_CFG0x03d8 + +#define ISC_HIS_CFG_MODE_GR0x0 +#define ISC_HIS_CFG_MODE_R 0x1 +#define ISC_HIS_CFG_MODE_GB0x2 +#define ISC_HIS_CFG_MODE_B 0x3 +#define ISC_HIS_CFG_MODE_Y 0x4 +#define ISC_HIS_CFG_MODE_RAW 0x5 +#define ISC_HIS_CFG_MODE_YCCIR656 0x6 + +#define ISC_HIS_CFG_BAYSEL_SHIFT 4 + +#define ISC_HIS_CFG_RARBIT(8) + /* DMA Configuration Register */ #define ISC_DCFG0x03e0 #define ISC_DCFG_IMODE_PACKED8 0x0 @@ -159,7 +249,13 @@ /* DMA Address 0 Register */ #define ISC_DAD00x03ec -/* DMA Stride 0 Register */ -#define ISC_DST00x03f0 +/* DMA Address 1 Register */ +#define ISC_DAD10x03f4
