[PATCH] [media] ir-spi: add SPDX identifier
Replace the original license statement with the SPDX identifier. Update also the copyright owner adding myself as co-owner of the copyright. Signed-off-by: Andi Shyti --- drivers/media/rc/ir-spi.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/drivers/media/rc/ir-spi.c b/drivers/media/rc/ir-spi.c index 29ed0638cb74..a32a84ae2d0b 100644 --- a/drivers/media/rc/ir-spi.c +++ b/drivers/media/rc/ir-spi.c @@ -1,13 +1,8 @@ -/* - * Copyright (c) 2016 Samsung Electronics Co., Ltd. - * Author: Andi Shyti - * - * 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. - * - * SPI driven IR LED device driver - */ +// SPDX-License-Identifier: GPL-2.0 +// SPI driven IR LED device driver +// +// Copyright (c) 2016 Samsung Electronics Co., Ltd. +// Copyright (c) Andi Shyti #include #include -- 2.15.1
Re: [PATCH 0/2] uvcvideo: Refactor code to ease metadata implementation
Hi Laurent, Thanks for the patches. Please feel free to add either or both of Reviewed-by: Guennadi Liakhovetski Tested-by: Guennadi Liakhovetski to both of the patches. Whereas in fact strictly speaking your current tree has updated improved versions of the patches, at least of the first of them - it now correctly handles the struct video_device::vfl_dir field, even thoough I'd still find merging that "if" with the following "switch" prettier ;-) So, strictly speaking you'd have to post those updated versions, in any case my approval tags refer to versions in your tree with commit IDs 53464c9f76da054ac3c291d27f348170d2a346c6 and b6c5f10563c4ee8437cd9131bc3d389514456519 Thanks Guennadi On Tue, 5 Dec 2017, Laurent Pinchart wrote: > Hi Guennadi, > > This small patch series refactors the uvc_video_register() function to extract > the code that you need into a new uvc_video_register_device() function. Please > let me know if it can help. > > Laurent Pinchart (2): > uvcvideo: Factor out video device registration to a function > uvcvideo: Report V4L2 device caps through the video_device structure > > drivers/media/usb/uvc/uvc_driver.c | 77 > +- > drivers/media/usb/uvc/uvc_v4l2.c | 4 -- > drivers/media/usb/uvc/uvcvideo.h | 8 > 3 files changed, 60 insertions(+), 29 deletions(-) > > -- > Regards, > > Laurent Pinchart >
Re: [PATCH v2 4/7] media: usb: add SPDX identifiers to some code I wrote
Hi Mauro, > diff --git a/drivers/media/usb/tm6000/tm6000-usb-isoc.h > b/drivers/media/usb/tm6000/tm6000-usb-isoc.h > index 6a13a27c55d7..e69f5cf8fe9f 100644 > --- a/drivers/media/usb/tm6000/tm6000-usb-isoc.h > +++ b/drivers/media/usb/tm6000/tm6000-usb-isoc.h > @@ -1,17 +1,7 @@ > -/* > - * tm6000-buf.c - driver for TM5600/TM6000/TM6010 USB video capture devices > - * > - * Copyright (C) 2006-2007 Mauro Carvalho Chehab > - * > - * 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 version 2 > - * > - * 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. > - */ > +// SPDX-License-Identifier: GPL-2.0 > +// tm6000-buf.c - driver for TM5600/TM6000/TM6010 USB video capture devices > +// > +// Copyright (c) 2006-2007 Mauro Carvalho Chehab shouldn't this and all the header files be of the type: /* SPDX-License-Identifier: GPL-2.0 ... */ as stated here: https://lwn.net/Articles/739183/ Andi
[PATCH 0/2] Rockchip: Add rk1608 driver and DT-bindings
For RK1608 driver ,you can use the v4l2-ctl command to capture frames. Add DT bindings documentation for Rockchip RK1608. Add the information of the maintainer. Leo Wen (2): [media] Add Rockchip RK1608 driver dt-bindings: Document the Rockchip RK1608 bindings Documentation/devicetree/bindings/media/rk1608.txt | 143 +++ MAINTAINERS|7 + drivers/media/spi/Makefile |1 + drivers/media/spi/rk1608.c | 1165 drivers/media/spi/rk1608.h | 366 ++ 5 files changed, 1682 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/rk1608.txt create mode 100644 drivers/media/spi/rk1608.c create mode 100644 drivers/media/spi/rk1608.h -- 2.7.4
[PATCH 2/2] dt-bindings: Document the Rockchip RK1608 bindings
Add DT bindings documentation for Rockchip RK1608.
Signed-off-by: Leo Wen
---
Documentation/devicetree/bindings/media/rk1608.txt | 143 +
MAINTAINERS| 1 +
2 files changed, 144 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/rk1608.txt
diff --git a/Documentation/devicetree/bindings/media/rk1608.txt
b/Documentation/devicetree/bindings/media/rk1608.txt
new file mode 100644
index 000..bda5cdb
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rk1608.txt
@@ -0,0 +1,143 @@
+Rockchip RK1608 as a PreISP to link on Soc
+--
+
+Required properties:
+
+- compatible : "rockchip,rk1608";
+- reg : SPI slave address of the rk1608;
+- clocks : Must contain an entry for each entry in clock-names;
+- clock-names: Must contain "mclk" for the device's master clock;
+- reset-gpio : GPIO connected to reset pin;
+- irq-gpio: GPIO connected to irq pin;
+- sleepst-gpio: GPIO connected to sleepst pin;
+- wakeup-gpio : GPIO connected to wakeup pin;
+- powerdown-gpio : GPIO connected to powerdown pin;
+- pinctrl-names : Should contain only one value - "default";
+- pinctrl-0 : Pin control group to be used for this controller;
+
+Optional properties:
+
+- spi-max-frequency: Maximum SPI clocking speed of the device;
+ (for RK1608)
+- spi-min-frequency: Minimum SPI clocking speed of the device;
+ (for RK1608)
+
+The device node should contain one 'port' child node with one child 'endpoint'
+node, according to the bindings defined in Documentation/devicetree/bindings/
+media/video-interfaces.txt. The following are properties specific to those
+nodes.
+
+endpoint node
+-
+
+- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
+ video-interfaces.txt. If present it should be <1> - the device
+ supports only one data lane without re-mapping.
+
+Note1: Since no data is generated in RK1608，so this is meaningful that you need
+a extra sensor (such as a camera) mounted on RK1608. You need to use endpoint@x
+to match these sensors.
+
+Note2:You must set the current value of the spi pins to be 8mA, if they are
not.
+
+Example:
+
+&spi0 {
+ status = "okay";
+
+ spi_rk1608@00 {
+ compatible = "rockchip,rk1608";
+ reg = <0>;
+ status = "okay";
+ spi-max-frequency = <2400>;
+ spi-min-frequency = <1200>;
+ clocks = <&cru SCLK_SPI0>;
+ clock-names = "mclk";
+
+ reset-gpio = <&gpio6 0 GPIO_ACTIVE_HIGH>;
+ irq-gpio = <&gpio6 2 GPIO_ACTIVE_HIGH>;
+ sleepst-gpio = <&gpio6 1 GPIO_ACTIVE_HIGH>;
+ wakeup-gpio = <&gpio6 4 GPIO_ACTIVE_HIGH>;
+ powerdown-gpio = <&gpio8 0 GPIO_ACTIVE_HIGH>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&rk1608_irq_gpios &rk1608_wake_gpios
+&rk1608_sleep_gpios>;
+
+ port {
+ isp_mipi_out: endpoint {
+ remote-endpoint = <&isp_mipi_in>;
+ data-lanes = <1>;
+ };
+ /*Example: we have two cameras*/
+ sensor_in0: endpoint@0 {
+ remote-endpoint = <&xxx0>;
+ };
+
+ sensor_in1: endpoint@1 {
+ remote-endpoint = <&xxx1>;
+ };
+ };
+ };
+};
+
+&mipi_phy_rx0 {
+ bus-width = <2>;
+ status = "okay";
+
+ port {
+ isp_mipi_in: endpoint {
+ remote-endpoint = <&isp_mipi_out>;
+ data-lanes = <1>;
+ link-frequencies =
+ /bits/ 64 <10>;
+ };
+ };
+};
+
+&pinctrl {
+ rk1608_irq_gpios {
+ rk1608_irq_gpios: rk1608_irq_gpios {
+ rockchip,pins = <6 2 RK_FUNC_GPIO &pcfg_pull_none>;
+ rockchip,pull = <1>;
+ };
+ };
+
+ rk1608_wake_gpios {
+ rk1608_wake_gpios: rk1608_wake_gpios {
+ rockchip,pins = <6 4 RK_FUNC_GPIO &pcfg_pull_none>;
+ rockchip,pull = <1>;
+ };
+ };
+
+ rk1608_sleep_gpios {
+ rk1608_sleep_gpios: rk1608_sleep_gpios {
+ rockchip,pins = <6 1 RK_FUNC_GPIO &pcfg_pull_none>;
+ rockchip,pull = <1>;
+ rockchip,drive = <0>;
+ };
+ };
+
+ pcfg_pull_none_8ma: pcfg-pull-none-8ma {
+ bias-disable;
+ drive-streng
[PATCH 1/2] [media] Add Rockchip RK1608 driver
Rk1608 is used as a PreISP to link on Soc, which mainly has two functions.
One is to download the firmware of RK1608, and the other is to match the
extra sensor such as camera and enable sensor by calling sensor's s_power.
use below v4l2-ctl command to capture frames.
v4l2-ctl --verbose -d /dev/video1 --stream-mmap=2
--stream-to=/tmp/stream.out --stream-count=60 --stream-poll
use below command to playback the video on your PC.
mplayer ./stream.out -loop 0 -demuxer rawvideo -rawvideo
w=640:h=480:size=$((640*480*3/2)):format=NV12
Signed-off-by: Leo Wen
---
MAINTAINERS|6 +
drivers/media/spi/Makefile |1 +
drivers/media/spi/rk1608.c | 1165
drivers/media/spi/rk1608.h | 366 ++
4 files changed, 1538 insertions(+)
create mode 100644 drivers/media/spi/rk1608.c
create mode 100644 drivers/media/spi/rk1608.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 82ad0ea..48235d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -128,6 +128,12 @@ Maintainers List (try to look for most precise areas first)
---
+ROCKCHIP RK1608 DRIVER
+M: Leo Wen
+S: Maintained
+F: drivers/media/platform/spi/rk1608.c
+F: drivers/media/platform/spi/rk1608.h
+
3C59X NETWORK DRIVER
M: Steffen Klassert
L: net...@vger.kernel.org
diff --git a/drivers/media/spi/Makefile b/drivers/media/spi/Makefile
index ea64013..9d9d9ec 100644
--- a/drivers/media/spi/Makefile
+++ b/drivers/media/spi/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_VIDEO_GS1662) += gs1662.o
+obj-$(CONFIG_ROCKCHIP_RK1608) += rk1608.o
diff --git a/drivers/media/spi/rk1608.c b/drivers/media/spi/rk1608.c
new file mode 100644
index 000..e646204
--- /dev/null
+++ b/drivers/media/spi/rk1608.c
@@ -0,0 +1,1165 @@
+/**
+ * Rockchip rk1608 driver
+ *
+ * Copyright (C) 2017 Rockchip Electronics Co., Ltd.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "rk1608.h"
+
+/**
+ * Rk1608 is used as the Pre-ISP to link on Soc, which mainly has two
+ * functions. One is to download the firmware of RK1608, and the other
+ * is to match the extra sensor such as camera and enable sensor by
+ * calling sensor's s_power.
+ * |---|
+ * | Sensor Camera |
+ * |---|
+ * |---||--|
+ * |---||--|
+ * |---\/--|
+ * | Pre-ISP RK1608|
+ * |---|
+ * |---||--|
+ * |---||--|
+ * |---\/--|
+ * | Rockchip Soc |
+ * |---|
+ * Data Transfer As shown above. In RK1608, the data received from the
+ * extra sensor,and it is passed to the Soc through ISP.
+ */
+struct rk1608_state {
+ struct v4l2_subdev sd;
+ struct v4l2_subdev *sensor_sd;
+ struct device *dev;
+ struct spi_device *spi;
+ struct media_padpad;
+ struct clk *mclk;
+ struct mutexlock; /* protect resource */
+ struct mutexsensor_lock;/* protect sensor */
+ struct mutexsend_msg_lock; /* protect msg */
+ int power_count;
+ int reset_gpio;
+ int reset_active;
+ int irq_gpio;
+ int irq;
+ int sleepst_gpio;
+ int sleepst_irq;
+ int wakeup_gpio;
+ int wakeup_active;
+ int powerdow
Re: [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
Hi Laurent Pinchart, Thanks a lot for the review. On Mon, Dec 11, 2017 at 7:17 PM, Laurent Pinchart wrote: > > Hi Dhaval, > > Thank you for the patch. > > On Friday, 8 December 2017 14:35:37 EET Dhaval Shah wrote: > > SPDX-License-Identifier is used for the Xilinx Video IP and > > related drivers. > > > > Signed-off-by: Dhaval Shah > > --- > > drivers/media/platform/xilinx/xilinx-dma.c | 5 + > > drivers/media/platform/xilinx/xilinx-dma.h | 5 + > > drivers/media/platform/xilinx/xilinx-tpg.c | 5 + > > drivers/media/platform/xilinx/xilinx-vip.c | 5 + > > drivers/media/platform/xilinx/xilinx-vip.h | 5 + > > drivers/media/platform/xilinx/xilinx-vipp.c | 5 + > > drivers/media/platform/xilinx/xilinx-vipp.h | 5 + > > drivers/media/platform/xilinx/xilinx-vtc.c | 5 + > > drivers/media/platform/xilinx/xilinx-vtc.h | 5 + > > How about addressing drivers/media/platform/xilinx/Makefile, drivers/media/ > platform/xilinx/Kconfig and include/dt-bindings/media/xilinx-vip.h as well ? > If you're fine with that I can make the change when applying, there's no need > to resubmit the patch. Sorry, I forgot to update in those files. Thanks for that. I am fine with what you said. Please do that change as you said. > > -- > Regards, > > Laurent Pinchart >
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: Tue Dec 12 05:00:16 CET 2017 media-tree git hash:72c27a68a2a3f650f0dc7891ee98f02283fc11af media_build git hash: f5a5e5e470d834f9843fee7a7c2ce3e4be610ca7 v4l-utils git hash: 58803000a99c22dceabfb45bec402e746ce966c3 gcc version:i686-linux-gcc (GCC) 7.1.0 sparse version: v0.5.0-3911-g6f737e1f smatch version: v0.5.0-3911-g6f737e1f host hardware: x86_64 host os:4.13.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: 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: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: ERRORS linux-3.6.11-i686: ERRORS linux-3.7.4-i686: ERRORS linux-3.8-i686: ERRORS linux-3.9.2-i686: ERRORS linux-3.10.1-i686: ERRORS linux-3.11.1-i686: ERRORS linux-3.12.67-i686: ERRORS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: ERRORS linux-3.16.7-i686: ERRORS 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: ERRORS linux-4.9.26-i686: ERRORS linux-4.10.14-i686: ERRORS linux-4.11-i686: ERRORS linux-4.12.1-i686: ERRORS linux-4.13-i686: ERRORS linux-4.14-i686: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: ERRORS linux-3.6.11-x86_64: ERRORS linux-3.7.4-x86_64: ERRORS linux-3.8-x86_64: ERRORS linux-3.9.2-x86_64: ERRORS linux-3.10.1-x86_64: ERRORS linux-3.11.1-x86_64: ERRORS linux-3.12.67-x86_64: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: ERRORS linux-3.15.2-x86_64: ERRORS linux-3.16.7-x86_64: ERRORS 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: ERRORS linux-4.9.26-x86_64: ERRORS linux-4.10.14-x86_64: ERRORS linux-4.11-x86_64: ERRORS linux-4.12.1-x86_64: ERRORS linux-4.13-x86_64: ERRORS linux-4.14-x86_64: ERRORS apps: OK spec-git: OK smatch: OK 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/index.html
Re: [Patch v6 10/12] [media] v4l2: Add v4l2 control IDs for HEVC encoder
On Sat, 2017-12-09 at 20:48 +0200, Stanimir Varbanov wrote:
> Hi Smitha,
>
> Thanks for the patches!
>
> On 12/08/2017 11:08 AM, Smitha T Murthy wrote:
> > Add v4l2 controls for HEVC encoder
> >
> > Signed-off-by: Smitha T Murthy
> > Reviewed-by: Andrzej Hajda
> > ---
> > drivers/media/v4l2-core/v4l2-ctrls.c | 118
> > +++
> > include/uapi/linux/v4l2-controls.h | 92 ++-
> > 2 files changed, 209 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> > b/drivers/media/v4l2-core/v4l2-ctrls.c
> > index 4e53a86..3f98318 100644
> > --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> > @@ -480,6 +480,56 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> > NULL,
> > };
> >
> > + static const char * const hevc_profile[] = {
> > + "Main",
>
> You forgot "Main 10" profile.
>
Sorry I forgot to update it, I will fix it in the next version.
> > + "Main Still Picture",
> > + NULL,
> > + };
> > + static const char * const hevc_level[] = {
> > + "1",
> > + "2",
> > + "2.1",
> > + "3",
> > + "3.1",
> > + "4",
> > + "4.1",
> > + "5",
> > + "5.1",
> > + "5.2",
> > + "6",
> > + "6.1",
> > + "6.2",
> > + NULL,
> > + };
> > + static const char * const hevc_hierarchial_coding_type[] = {
> > + "B",
> > + "P",
> > + NULL,
> > + };
> > + static const char * const hevc_refresh_type[] = {
> > + "None",
> > + "CRA",
> > + "IDR",
> > + NULL,
> > + };
> > + static const char * const hevc_size_of_length_field[] = {
> > + "0",
> > + "1",
> > + "2",
> > + "4",
> > + NULL,
> > + };
> > + static const char * const hevc_tier_flag[] = {
> > + "Main",
> > + "High",
> > + NULL,
> > + };
> > + static const char * const hevc_loop_filter_mode[] = {
> > + "Disabled",
> > + "Enabled",
> > + "Disabled at slice boundary",
> > + "NULL",
> > + };
> >
> > switch (id) {
> > case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
> > @@ -575,6 +625,20 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> > return dv_it_content_type;
> > case V4L2_CID_DETECT_MD_MODE:
> > return detect_md_mode;
> > + case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
> > + return hevc_profile;
> > + case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
> > + return hevc_level;
> > + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_TYPE:
> > + return hevc_hierarchial_coding_type;
> > + case V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_TYPE:
> > + return hevc_refresh_type;
> > + case V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD:
> > + return hevc_size_of_length_field;
> > + case V4L2_CID_MPEG_VIDEO_HEVC_TIER_FLAG:
>
> Could you drop _FLAG suffix? Looking (briefly) into the spec they not
> specify `tier flag` but just `tier`.
>
Yes I will remove it.
> > + return hevc_tier_flag;
> > + case V4L2_CID_MPEG_VIDEO_HEVC_LOOP_FILTER_MODE:
> > + return hevc_loop_filter_mode;
> >
> > default:
> > return NULL;
> > @@ -776,6 +840,53 @@ const char *v4l2_ctrl_get_name(u32 id)
> > case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:return "VPX
> > P-Frame QP Value";
> > case V4L2_CID_MPEG_VIDEO_VPX_PROFILE: return "VPX
> > Profile";
> >
> > + /* HEVC controls */
> > + case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP: return "HEVC
> > I-Frame QP Value";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP: return "HEVC
> > P-Frame QP Value";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP: return "HEVC
> > B-Frame QP Value";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP: return "HEVC
> > Minimum QP Value";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP: return "HEVC
> > Maximum QP Value";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE: return "HEVC
> > Profile";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:return "HEVC
> > Level";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_TIER_FLAG:return "HEVC
> > Tier Flag";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_FRAME_RATE_RESOLUTION:return "HEVC
> > Frame Rate Resolution";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_MAX_PARTITION_DEPTH: return "HEVC
> > Maximum Coding Unit Depth";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_TYPE: return "HEVC
> > Refresh Type";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_CONST_INTRA_PRED: return "HEVC
> > Constant Intra Prediction";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_LOSSLESS_CU: return "HEVC
> > Lossless Encoding
[PATCH RESEND] media: dvb-frontends: Add delay to Si2168 restart.
On faster CPUs a delay is required after the resume command and the restart command. Without the delay, the restart command often returns -EREMOTEIO and the Si2168 does not restart. Note that this patch fixes the same issue as https://patchwork.linuxtv.org/patch/44304/, but I believe my udelay() fix addresses the actual problem. Signed-off-by: Ron Economos --- drivers/media/dvb-frontends/si2168.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/dvb-frontends/si2168.c b/drivers/media/dvb-frontends/si2168.c index 41d9c51..539399d 100644 --- a/drivers/media/dvb-frontends/si2168.c +++ b/drivers/media/dvb-frontends/si2168.c @@ -14,6 +14,8 @@ *GNU General Public License for more details. */ +#include + #include "si2168_priv.h" static const struct dvb_frontend_ops si2168_ops; @@ -435,6 +437,7 @@ static int si2168_init(struct dvb_frontend *fe) if (ret) goto err; + udelay(100); memcpy(cmd.args, "\x85", 1); cmd.wlen = 1; cmd.rlen = 1; -- 2.7.4
[PATCH v5 1/4] media: dt: bindings: Add binding for NVIDIA Tegra Video Decoder Engine
Add binding documentation for the Video Decoder Engine which is found
on NVIDIA Tegra20/30/114/124/132 SoC's.
Signed-off-by: Dmitry Osipenko
Acked-by: Rob Herring
---
.../devicetree/bindings/media/nvidia,tegra-vde.txt | 55 ++
1 file changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt
diff --git a/Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt
b/Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt
new file mode 100644
index ..470237ed6fe5
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt
@@ -0,0 +1,55 @@
+NVIDIA Tegra Video Decoder Engine
+
+Required properties:
+- compatible : Must contain one of the following values:
+ - "nvidia,tegra20-vde"
+ - "nvidia,tegra30-vde"
+ - "nvidia,tegra114-vde"
+ - "nvidia,tegra124-vde"
+ - "nvidia,tegra132-vde"
+- reg : Must contain an entry for each entry in reg-names.
+- reg-names : Must include the following entries:
+ - sxe
+ - bsev
+ - mbe
+ - ppe
+ - mce
+ - tfe
+ - ppb
+ - vdma
+ - frameid
+- iram : Must contain phandle to the mmio-sram device node that represents
+ IRAM region used by VDE.
+- interrupts : Must contain an entry for each entry in interrupt-names.
+- interrupt-names : Must include the following entries:
+ - sync-token
+ - bsev
+ - sxe
+- clocks : Must include the following entries:
+ - vde
+- resets : Must include the following entries:
+ - vde
+
+Example:
+
+video-codec@6001a000 {
+ compatible = "nvidia,tegra20-vde";
+ reg = <0x6001a000 0x1000 /* Syntax Engine */
+ 0x6001b000 0x1000 /* Video Bitstream Engine */
+ 0x6001c000 0x100 /* Macroblock Engine */
+ 0x6001c200 0x100 /* Post-processing Engine */
+ 0x6001c400 0x100 /* Motion Compensation Engine */
+ 0x6001c600 0x100 /* Transform Engine */
+ 0x6001c800 0x100 /* Pixel prediction block */
+ 0x6001ca00 0x100 /* Video DMA */
+ 0x6001d800 0x300 /* Video frame controls */>;
+ reg-names = "sxe", "bsev", "mbe", "ppe", "mce",
+ "tfe", "ppb", "vdma", "frameid";
+ iram = <&vde_pool>; /* IRAM region */
+ interrupts = , /* Sync token interrupt
*/
+, /* BSE-V interrupt */
+; /* SXE interrupt */
+ interrupt-names = "sync-token", "bsev", "sxe";
+ clocks = <&tegra_car TEGRA20_CLK_VDE>;
+ resets = <&tegra_car 61>;
+};
--
2.15.1
[PATCH v5 0/4] NVIDIA Tegra video decoder driver
VDE driver provides accelerated video decoding to NVIDIA Tegra SoC's, it is a result of reverse-engineering efforts. Driver has been tested on Toshiba AC100 and Acer A500, it should work on any Tegra20 device. In userspace this driver is utilized by libvdpau-tegra [0] that implements VDPAU interface, so any video player that supports VDPAU can provide accelerated video decoding on Tegra20 on Linux. [0] https://github.com/grate-driver/libvdpau-tegra Change log: v5: - Moved driver to staging/media as per Hans's Verkuil request - Addressed review comments to v4 from Vladimir Zapolskiy and Dan Carpenter - Updated 'TODO', reflecting that this driver require upcoming support of stateless decoders by V4L2 - Dropped patch that enabled VDE driver in tegra_defconfig for now as I realized that Tegra's DRM staging config is disabled there and right now we are relying on it in libvdpau-tegra - Added myself to MAINTAINERS in the "Introduce driver" patch as per Vladimir's suggestion v4: - Added mmio-sram "IRAM DT node" patch from Vladimir Zapolskiy to the series, I modified it to cover all Tegra's and not only Tegra20 - Utilized genalloc for the reservation of IRAM region as per Vladimir's suggestion, VDE driver now selects SRAM driver in Kconfig - Added defconfig patch to the series - Described VDE registers in DT per HW unit, excluding BSE-A / UCQ and holes between the units - Extended DT compatibility property with Tegra30/114/124/132 in the binding doc. - Removed BSE-A interrupt from the DT binding because it's very likely that Audio Bitstream Engine isn't integrated with VDE - Removed UCQ interrupt from the DT binding because in TRM it is represented as a distinct HW block that probably should have its own driver - Addressed v3 review comments: factored out DT binding addition into a standalone patch, moved binding to media/, removed clocks/resets-names v3: - Suppressed compilation warnings reported by 'kbuild test robot' v2: - Addressed v1 review comments from Stephen Warren and Dan Carpenter - Implemented runtime PM - Miscellaneous code cleanups - Changed 'TODO' - CC'd media maintainers for the review as per Greg's K-H request, v1 can be viewed at https://lkml.org/lkml/2017/9/25/606 Dmitry Osipenko (3): media: dt: bindings: Add binding for NVIDIA Tegra Video Decoder Engine staging: media: Introduce NVIDIA Tegra video decoder driver ARM: dts: tegra20: Add video decoder node Vladimir Zapolskiy (1): ARM: dts: tegra20: Add device tree node to describe IRAM .../devicetree/bindings/media/nvidia,tegra-vde.txt | 55 + MAINTAINERS|9 + arch/arm/boot/dts/tegra20.dtsi | 35 + drivers/staging/media/Kconfig |2 + drivers/staging/media/Makefile |1 + drivers/staging/media/tegra-vde/Kconfig|7 + drivers/staging/media/tegra-vde/Makefile |1 + drivers/staging/media/tegra-vde/TODO |4 + drivers/staging/media/tegra-vde/tegra-vde.c| 1213 drivers/staging/media/tegra-vde/uapi.h | 78 ++ 10 files changed, 1405 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt create mode 100644 drivers/staging/media/tegra-vde/Kconfig create mode 100644 drivers/staging/media/tegra-vde/Makefile create mode 100644 drivers/staging/media/tegra-vde/TODO create mode 100644 drivers/staging/media/tegra-vde/tegra-vde.c create mode 100644 drivers/staging/media/tegra-vde/uapi.h -- 2.15.1
[PATCH v5 4/4] ARM: dts: tegra20: Add video decoder node
Add Video Decoder Engine device node.
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra20.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 36909df653c3..864a95872b8d 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -16,6 +16,11 @@
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x4000 0x4>;
+
+ vde_pool: vde {
+ reg = <0x400 0x3fc00>;
+ pool;
+ };
};
host1x@5000 {
@@ -258,6 +263,28 @@
*/
};
+ vde@6001a000 {
+ compatible = "nvidia,tegra20-vde";
+ reg = <0x6001a000 0x1000 /* Syntax Engine */
+ 0x6001b000 0x1000 /* Video Bitstream Engine */
+ 0x6001c000 0x100 /* Macroblock Engine */
+ 0x6001c200 0x100 /* Post-processing Engine */
+ 0x6001c400 0x100 /* Motion Compensation Engine */
+ 0x6001c600 0x100 /* Transform Engine */
+ 0x6001c800 0x100 /* Pixel prediction block */
+ 0x6001ca00 0x100 /* Video DMA */
+ 0x6001d800 0x300>; /* Video frame controls */
+ reg-names = "sxe", "bsev", "mbe", "ppe", "mce",
+ "tfe", "ppb", "vdma", "frameid";
+ iram = <&vde_pool>; /* IRAM region */
+ interrupts = , /* Sync token
interrupt */
+, /* BSE-V
interrupt */
+; /* SXE interrupt
*/
+ interrupt-names = "sync-token", "bsev", "sxe";
+ clocks = <&tegra_car TEGRA20_CLK_VDE>;
+ resets = <&tegra_car 61>;
+ };
+
apbmisc@7800 {
compatible = "nvidia,tegra20-apbmisc";
reg = <0x7800 0x64 /* Chip revision */
--
2.15.1
[PATCH v5 3/4] ARM: dts: tegra20: Add device tree node to describe IRAM
From: Vladimir Zapolskiy
All Tegra20 SoCs contain 256KiB IRAM, which is used to store
resume code and by a video decoder engine.
Signed-off-by: Vladimir Zapolskiy
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra20.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 914f59166a99..36909df653c3 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -10,6 +10,14 @@
compatible = "nvidia,tegra20";
interrupt-parent = <&lic>;
+ iram@4000 {
+ compatible = "mmio-sram";
+ reg = <0x4000 0x4>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x4000 0x4>;
+ };
+
host1x@5000 {
compatible = "nvidia,tegra20-host1x", "simple-bus";
reg = <0x5000 0x00024000>;
--
2.15.1
[PATCH v5 2/4] staging: media: Introduce NVIDIA Tegra video decoder driver
NVIDIA Tegra20/30/114/124/132 SoC's have video decoder engine that
supports standard set of video formats like H.264 / MPEG-4 / WMV / VC1.
Signed-off-by: Dmitry Osipenko
---
MAINTAINERS |9 +
drivers/staging/media/Kconfig |2 +
drivers/staging/media/Makefile |1 +
drivers/staging/media/tegra-vde/Kconfig |7 +
drivers/staging/media/tegra-vde/Makefile|1 +
drivers/staging/media/tegra-vde/TODO|4 +
drivers/staging/media/tegra-vde/tegra-vde.c | 1213 +++
drivers/staging/media/tegra-vde/uapi.h | 78 ++
8 files changed, 1315 insertions(+)
create mode 100644 drivers/staging/media/tegra-vde/Kconfig
create mode 100644 drivers/staging/media/tegra-vde/Makefile
create mode 100644 drivers/staging/media/tegra-vde/TODO
create mode 100644 drivers/staging/media/tegra-vde/tegra-vde.c
create mode 100644 drivers/staging/media/tegra-vde/uapi.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 7d195739f892..7f7c24949a06 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8706,6 +8706,15 @@ T: git git://linuxtv.org/media_tree.git
S: Maintained
F: drivers/media/dvb-frontends/stv6111*
+MEDIA DRIVERS FOR NVIDIA TEGRA - VDE
+M: Dmitry Osipenko
+L: linux-media@vger.kernel.org
+L: linux-te...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt
+F: drivers/staging/media/tegra-vde/
+
MEDIA INPUT INFRASTRUCTURE (V4L/DVB)
M: Mauro Carvalho Chehab
M: Mauro Carvalho Chehab
diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig
index 3a09140700e6..227437f22acf 100644
--- a/drivers/staging/media/Kconfig
+++ b/drivers/staging/media/Kconfig
@@ -31,4 +31,6 @@ source "drivers/staging/media/imx/Kconfig"
source "drivers/staging/media/omap4iss/Kconfig"
+source "drivers/staging/media/tegra-vde/Kconfig"
+
endif
diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile
index f25327163c67..59a47f69884f 100644
--- a/drivers/staging/media/Makefile
+++ b/drivers/staging/media/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx/
obj-$(CONFIG_VIDEO_DM365_VPFE) += davinci_vpfe/
obj-$(CONFIG_VIDEO_OMAP4) += omap4iss/
obj-$(CONFIG_INTEL_ATOMISP) += atomisp/
+obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/
diff --git a/drivers/staging/media/tegra-vde/Kconfig
b/drivers/staging/media/tegra-vde/Kconfig
new file mode 100644
index ..ec3ebdaa
--- /dev/null
+++ b/drivers/staging/media/tegra-vde/Kconfig
@@ -0,0 +1,7 @@
+config TEGRA_VDE
+ tristate "NVIDIA Tegra Video Decoder Engine driver"
+ depends on ARCH_TEGRA || COMPILE_TEST
+ select SRAM
+ help
+ Say Y here to enable support for the NVIDIA Tegra video decoder
+ driver.
diff --git a/drivers/staging/media/tegra-vde/Makefile
b/drivers/staging/media/tegra-vde/Makefile
new file mode 100644
index ..444c1d62daa1
--- /dev/null
+++ b/drivers/staging/media/tegra-vde/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_TEGRA_VDE)+= tegra-vde.o
diff --git a/drivers/staging/media/tegra-vde/TODO
b/drivers/staging/media/tegra-vde/TODO
new file mode 100644
index ..31aaa3e66d80
--- /dev/null
+++ b/drivers/staging/media/tegra-vde/TODO
@@ -0,0 +1,4 @@
+TODO:
+ - Implement V4L2 API once it gains support for stateless decoders.
+
+Contact: Dmitry Osipenko
diff --git a/drivers/staging/media/tegra-vde/tegra-vde.c
b/drivers/staging/media/tegra-vde/tegra-vde.c
new file mode 100644
index ..c47659e96089
--- /dev/null
+++ b/drivers/staging/media/tegra-vde/tegra-vde.c
@@ -0,0 +1,1213 @@
+/*
+ * NVIDIA Tegra Video decoder driver
+ *
+ * Copyright (C) 2016-2017 Dmitry Osipenko
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "uapi.h"
+
+#define ICMDQUE_WR 0x00
+#define CMDQUE_CONTROL 0x08
+#define INTR_STATUS0x18
+#define BSE_INT_ENB0x40
+#define BSE_CONFIG 0x44
+
+#define BSE_ICMDQUE_EMPTY BIT(3)
+#define BSE_DMA_BUSY BIT(23)
+
+#define VDE_WR(__data, __addr) \
+do { \
+ dev_dbg(vde->miscdev.parent,\
+ "%s: %d: 0x%08X => " #__addr ")\n", \
+ __func__, __LINE__, (u32)(__data)); \
+ writel_relaxed(__data, __addr); \
+} while (0)
+
+struct video_frame {
+ struct dma_buf_attachment *y_dmabuf_attachment;
+
Re: [PATCH] media: pxa_camera: disable and unprepare the clock source on error
Laurent Pinchart writes: > Hi Flavio, > > On Monday, 11 December 2017 23:05:46 EET Flavio Ceolin wrote: >> > On Wednesday, 6 December 2017 18:38:50 EET Flavio Ceolin wrote: >> >> pxa_camera_probe() was not calling pxa_camera_deactivate(), >> >> responsible to call clk_disable_unprepare(), on the failure path. This >> >> was leading to unbalancing source clock. >> >> >> >> Found by Linux Driver Verification project (linuxtesting.org). >> > >> > Any chance I could sign you up for more work on this driver ? :-) >> >> Definetely, this would be great :) > > Actually it looks like the work I thought was needed has already been > performed. The pxa-camera driver used to make use of the soc-camera > framework, > which we are trying to remove, and occurrences of soc_camera in the code gave > me the wrong idea that the driver was still based on that framework. It seems > this isn't the case. Thank you for making me happy :-) I'm glad to hear it :) > >> >> Signed-off-by: Flavio Ceolin >> > >> > Reviewed-by: Laurent Pinchart >> > >> > I expect Hans Verkuil to pick up the patch. >> > >> >> --- >> >> >> >> drivers/media/platform/pxa_camera.c | 4 +++- >> >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> >> >> diff --git a/drivers/media/platform/pxa_camera.c >> >> b/drivers/media/platform/pxa_camera.c index 9d3f0cb..7877037 100644 >> >> --- a/drivers/media/platform/pxa_camera.c >> >> +++ b/drivers/media/platform/pxa_camera.c >> >> @@ -2489,7 +2489,7 @@ static int pxa_camera_probe(struct platform_device >> >> *pdev) >> >> dev_set_drvdata(&pdev->dev, pcdev); >> >> err = v4l2_device_register(&pdev->dev, &pcdev->v4l2_dev); >> >> if (err) >> >> - goto exit_free_dma; >> >> + goto exit_deactivate; >> >> >> >> pcdev->asds[0] = &pcdev->asd; >> >> pcdev->notifier.subdevs = pcdev->asds; >> >> @@ -2525,6 +2525,8 @@ static int pxa_camera_probe(struct platform_device >> >> *pdev) >> >> v4l2_clk_unregister(pcdev->mclk_clk); >> >> exit_free_v4l2dev: >> >> v4l2_device_unregister(&pcdev->v4l2_dev); >> >> +exit_deactivate: >> >> + pxa_camera_deactivate(pcdev); >> >> exit_free_dma: >> >> dma_release_channel(pcdev->dma_chans[2]); >> >> exit_free_dma_u: > > -- > Regards, > > Laurent Pinchart Regards, Flavio Ceolin
Re: [PATCH 0/2] Add timers to en50221 protocol driver
Hi! > I don't know if you are also waiting for a comment from me. All positive ones are welcome ;) > I am fine with those changes. They are even desperately needed > to get some "problem CAMs" working. THX, so we can interpret this as an "Acked-by"? BR, Jasmin
Re: [PATCH v2 08/26] media: v4l2-async: shut up an unitialized symbol warning
Hi Mauro, On Monday, 11 December 2017 20:10:58 EET Mauro Carvalho Chehab wrote: > Em Thu, 02 Nov 2017 04:51:40 +0200 Laurent Pinchart escreveu: > > On Wednesday, 1 November 2017 23:05:45 EET Mauro Carvalho Chehab wrote: > >> Smatch reports this warning: > >>drivers/media/v4l2-core/v4l2-async.c:597 v4l2_async_register_subdev() > >> > >> error: uninitialized symbol 'ret'. > >> > >> However, there's nothing wrong there. So, just shut up the > >> warning. > > > > Nothing wrong, really ? ret does seem to be used uninitialized when the > > function returns at the very last line. > > There's nothing wrong. If you follow the logic, you'll see that > the line: > > return ret; > > is called only at "err_unbind" label, with is called only on > two places: > > ret = v4l2_async_match_notify(notifier, v4l2_dev, sd, asd); > if (ret) > goto err_unbind; > > ret = v4l2_async_notifier_try_complete(notifier); > if (ret) > goto err_unbind; > > There, ret is defined. > > Yeah, the logic there is confusing. I had missed the return 0 just before the error label. Sorry for the noise. -- Regards, Laurent Pinchart
Re: [PATCH 0/2] Add timers to en50221 protocol driver
Hi, I don't know if you are also waiting for a comment from me. I am fine with those changes. They are even desperately needed to get some "problem CAMs" working. Regards, Ralph Jasmin J. writes: > Ping 2! > > On 10/15/2017 03:59 PM, Jasmin J. wrote: > > Ping! > > -- --
Re: [PATCH v8] uvcvideo: Add a metadata device node
Hi Guennadi,
On Monday, 11 December 2017 23:44:09 EET Guennadi Liakhovetski wrote:
> On Mon, 11 Dec 2017, Laurent Pinchart wrote:
> > On Monday, 11 December 2017 22:16:23 EET Laurent Pinchart wrote:
> >> On Wednesday, 6 December 2017 17:15:40 EET Guennadi Liakhovetski wrote:
> >>> From: Guennadi Liakhovetski
> >>>
> >>> Some UVC video cameras contain metadata in their payload headers. This
> >>> patch extracts that data, adding more clock synchronisation
> >>> information, on both bulk and isochronous endpoints and makes it
> >>> available to the user space on a separate video node, using the
> >>> V4L2_CAP_META_CAPTURE capability and the V4L2_BUF_TYPE_META_CAPTURE
> >>> buffer queue type. By default, only the V4L2_META_FMT_UVC pixel format
> >>> is available from those nodes. However, cameras can be added to the
> >>> device ID table to additionally specify their own metadata format, in
> >>> which case that format will also become available from the metadata
> >>> node.
> >>>
> >>> Signed-off-by: Guennadi Liakhovetski
> >>> ---
> >>>
> >>> v8: addressed comments and integrated changes from Laurent, thanks
> >>> again, e.g.:
> >>>
> >>> - multiple stylistic changes
> >>> - remove the UVC_DEV_FLAG_METADATA_NODE flag / quirk: nodes are now
> >>> created unconditionally
> >>> - reuse uvc_ioctl_querycap()
> >>> - reuse code in uvc_register_video()
> >>> - set an error flag when the metadata buffer overflows
> >>>
> >>> drivers/media/usb/uvc/Makefile | 2 +-
> >>> drivers/media/usb/uvc/uvc_driver.c | 15 ++-
> >>> drivers/media/usb/uvc/uvc_isight.c | 2 +-
> >>> drivers/media/usb/uvc/uvc_metadata.c | 179
> >>> drivers/media/usb/uvc/uvc_queue.c| 44 +++--
> >>> drivers/media/usb/uvc/uvc_video.c| 132 --
> >>> drivers/media/usb/uvc/uvcvideo.h | 16 +++-
> >>> include/uapi/linux/uvcvideo.h| 26 +
> >>> 8 files changed, 394 insertions(+), 22 deletions(-)
> >>> create mode 100644 drivers/media/usb/uvc/uvc_metadata.c
> >>
> >> [snip]
> >>
> >> > diff --git a/drivers/media/usb/uvc/uvc_video.c
> >> > b/drivers/media/usb/uvc/uvc_video.c index 13f459e..2fc0bf2 100644
> >> > --- a/drivers/media/usb/uvc/uvc_video.c
> >> > +++ b/drivers/media/usb/uvc/uvc_video.c
> >>
> >> [snip]
> >>
> >>> +static void uvc_video_decode_meta(struct uvc_streaming *stream,
> >>> + struct uvc_buffer *meta_buf,
> >>> + const u8 *mem, unsigned int length)
> >>> +{
> >>> + struct uvc_meta_buf *meta;
> >>> + size_t len_std = 2;
> >>> + bool has_pts, has_scr;
> >>> + unsigned long flags;
> >>> + ktime_t time;
> >>> + const u8 *scr;
> >>> +
> >>> + if (!meta_buf || length == 2)
> >>> + return;
> >>> +
> >>> + if (meta_buf->length - meta_buf->bytesused <
> >>> + length + sizeof(meta->ns) + sizeof(meta->sof)) {
> >>> + meta_buf->error = 1;
> >>> + return;
> >>> + }
> >>> +
> >>> + has_pts = mem[1] & UVC_STREAM_PTS;
> >>> + has_scr = mem[1] & UVC_STREAM_SCR;
> >>> +
> >>> + if (has_pts) {
> >>> + len_std += 4;
> >>> + scr = mem + 6;
> >>> + } else {
> >>> + scr = mem + 2;
> >>> + }
> >>> +
> >>> + if (has_scr)
> >>> + len_std += 6;
> >>> +
> >>> + if (stream->meta.format == V4L2_META_FMT_UVC)
> >>> + length = len_std;
> >>> +
> >>> + if (length == len_std && (!has_scr ||
> >>> + !memcmp(scr, stream->clock.last_scr, 6)))
> >>> + return;
> >>> +
> >>> + meta = (struct uvc_meta_buf *)((u8 *)meta_buf->mem +
> >>> meta_buf->bytesused); + local_irq_save(flags);
> >>> + time = uvc_video_get_time();
> >>> + meta->sof = usb_get_current_frame_number(stream->dev->udev);
> >>
> >> You need a put_unaligned here too. If you're fine with the patch below
> >> there's no need to resubmit, and
> >
> > One more thing, __put_unaligned_cpu16() and __put_unaligned_cpu64() don't
> > compile on x86_64 with v4.12 (using media_build.git). I propose replacing
> > them with put_unaligned() which compiles and should do the right thing.
> Sure, thanks for catching! Shall I fix and resubmit?
If you're fine with
git://linuxtv.org/pinchartl/media.git uvc/next
there's no need to resubmit.
By the way, could you please review "uvcvideo: Factor out video device
registration to a function" and "uvcvideo: Report V4L2 device caps through the
video_device structure" ?
I will send a pull request after testing the code and getting those two
patches reviewed.
> >> Reviewed-by: Laurent Pinchart
> >>
> >> Would you mind sending me your test tool patch ?
>
> Will send it offline.
>
> Thanks
> Guennadi
>
> >> diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/
> >> uvc_video.c
> >> index 2fc0bf2221db..02e4997a32bb 100644
> >> --- a/drivers/media/usb/uvc/uvc_video.c
> >> +++ b/drivers/media/usb/uvc/uvc_video.c
> >> @@ -1142,6 +1142,7 @@ static void uvc_video_decode_meta(struct
> >> uvc_stre
Re: [PATCH v8] uvcvideo: Add a metadata device node
Hi Laurent,
On Mon, 11 Dec 2017, Laurent Pinchart wrote:
> Hi Guennadi,
>
> On Monday, 11 December 2017 22:16:23 EET Laurent Pinchart wrote:
> > On Wednesday, 6 December 2017 17:15:40 EET Guennadi Liakhovetski wrote:
> > > From: Guennadi Liakhovetski
> > >
> > > Some UVC video cameras contain metadata in their payload headers. This
> > > patch extracts that data, adding more clock synchronisation information,
> > > on both bulk and isochronous endpoints and makes it available to the user
> > > space on a separate video node, using the V4L2_CAP_META_CAPTURE capability
> > > and the V4L2_BUF_TYPE_META_CAPTURE buffer queue type. By default, only the
> > > V4L2_META_FMT_UVC pixel format is available from those nodes. However,
> > > cameras can be added to the device ID table to additionally specify their
> > > own metadata format, in which case that format will also become available
> > > from the metadata node.
> > >
> > > Signed-off-by: Guennadi Liakhovetski
> > > ---
> > >
> > > v8: addressed comments and integrated changes from Laurent, thanks again,
> > > e.g.:
> > >
> > > - multiple stylistic changes
> > > - remove the UVC_DEV_FLAG_METADATA_NODE flag / quirk: nodes are now
> > > created unconditionally
> > > - reuse uvc_ioctl_querycap()
> > > - reuse code in uvc_register_video()
> > > - set an error flag when the metadata buffer overflows
> > >
> > > drivers/media/usb/uvc/Makefile | 2 +-
> > > drivers/media/usb/uvc/uvc_driver.c | 15 ++-
> > > drivers/media/usb/uvc/uvc_isight.c | 2 +-
> > > drivers/media/usb/uvc/uvc_metadata.c | 179 ++
> > > drivers/media/usb/uvc/uvc_queue.c| 44 +++--
> > > drivers/media/usb/uvc/uvc_video.c| 132 --
> > > drivers/media/usb/uvc/uvcvideo.h | 16 +++-
> > > include/uapi/linux/uvcvideo.h| 26 +
> > > 8 files changed, 394 insertions(+), 22 deletions(-)
> > > create mode 100644 drivers/media/usb/uvc/uvc_metadata.c
> >
> > [snip]
> >
> > > diff --git a/drivers/media/usb/uvc/uvc_video.c
> > > b/drivers/media/usb/uvc/uvc_video.c index 13f459e..2fc0bf2 100644
> > > --- a/drivers/media/usb/uvc/uvc_video.c
> > > +++ b/drivers/media/usb/uvc/uvc_video.c
> >
> > [snip]
> >
> > > +static void uvc_video_decode_meta(struct uvc_streaming *stream,
> > > + struct uvc_buffer *meta_buf,
> > > + const u8 *mem, unsigned int length)
> > > +{
> > > + struct uvc_meta_buf *meta;
> > > + size_t len_std = 2;
> > > + bool has_pts, has_scr;
> > > + unsigned long flags;
> > > + ktime_t time;
> > > + const u8 *scr;
> > > +
> > > + if (!meta_buf || length == 2)
> > > + return;
> > > +
> > > + if (meta_buf->length - meta_buf->bytesused <
> > > + length + sizeof(meta->ns) + sizeof(meta->sof)) {
> > > + meta_buf->error = 1;
> > > + return;
> > > + }
> > > +
> > > + has_pts = mem[1] & UVC_STREAM_PTS;
> > > + has_scr = mem[1] & UVC_STREAM_SCR;
> > > +
> > > + if (has_pts) {
> > > + len_std += 4;
> > > + scr = mem + 6;
> > > + } else {
> > > + scr = mem + 2;
> > > + }
> > > +
> > > + if (has_scr)
> > > + len_std += 6;
> > > +
> > > + if (stream->meta.format == V4L2_META_FMT_UVC)
> > > + length = len_std;
> > > +
> > > + if (length == len_std && (!has_scr ||
> > > + !memcmp(scr, stream->clock.last_scr, 6)))
> > > + return;
> > > +
> > > + meta = (struct uvc_meta_buf *)((u8 *)meta_buf->mem +
> > > meta_buf->bytesused); + local_irq_save(flags);
> > > + time = uvc_video_get_time();
> > > + meta->sof = usb_get_current_frame_number(stream->dev->udev);
> >
> > You need a put_unaligned here too. If you're fine with the patch below
> > there's no need to resubmit, and
>
> One more thing, __put_unaligned_cpu16() and __put_unaligned_cpu64() don't
> compile on x86_64 with v4.12 (using media_build.git). I propose replacing
> them
> with put_unaligned() which compiles and should do the right thing.
Sure, thanks for catching! Shall I fix and resubmit?
> > Reviewed-by: Laurent Pinchart
> >
> > Would you mind sending me your test tool patch ?
Will send it offline.
Thanks
Guennadi
> >
> > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/
> > uvc_video.c
> > index 2fc0bf2221db..02e4997a32bb 100644
> > --- a/drivers/media/usb/uvc/uvc_video.c
> > +++ b/drivers/media/usb/uvc/uvc_video.c
> > @@ -1142,6 +1142,7 @@ static void uvc_video_decode_meta(struct uvc_streaming
> > *stream,
> > size_t len_std = 2;
> > bool has_pts, has_scr;
> > unsigned long flags;
> > + unsigned int sof;
> > ktime_t time;
> > const u8 *scr;
> >
> > @@ -1177,9 +1178,10 @@ static void uvc_video_decode_meta(struct
> > uvc_streaming *stream,
> > meta = (struct uvc_meta_buf *)((u8 *)meta_buf->mem +
> > meta_buf->bytesused);
> > local_irq_save(flags);
> > time = uvc_video_get_time();
> > - meta->sof = usb_get_current_frame_numbe
Re: [PATCH] media: pxa_camera: disable and unprepare the clock source on error
Hi Flavio, On Monday, 11 December 2017 23:05:46 EET Flavio Ceolin wrote: > > On Wednesday, 6 December 2017 18:38:50 EET Flavio Ceolin wrote: > >> pxa_camera_probe() was not calling pxa_camera_deactivate(), > >> responsible to call clk_disable_unprepare(), on the failure path. This > >> was leading to unbalancing source clock. > >> > >> Found by Linux Driver Verification project (linuxtesting.org). > > > > Any chance I could sign you up for more work on this driver ? :-) > > Definetely, this would be great :) Actually it looks like the work I thought was needed has already been performed. The pxa-camera driver used to make use of the soc-camera framework, which we are trying to remove, and occurrences of soc_camera in the code gave me the wrong idea that the driver was still based on that framework. It seems this isn't the case. Thank you for making me happy :-) > >> Signed-off-by: Flavio Ceolin > > > > Reviewed-by: Laurent Pinchart > > > > I expect Hans Verkuil to pick up the patch. > > > >> --- > >> > >> drivers/media/platform/pxa_camera.c | 4 +++- > >> 1 file changed, 3 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/media/platform/pxa_camera.c > >> b/drivers/media/platform/pxa_camera.c index 9d3f0cb..7877037 100644 > >> --- a/drivers/media/platform/pxa_camera.c > >> +++ b/drivers/media/platform/pxa_camera.c > >> @@ -2489,7 +2489,7 @@ static int pxa_camera_probe(struct platform_device > >> *pdev) > >>dev_set_drvdata(&pdev->dev, pcdev); > >>err = v4l2_device_register(&pdev->dev, &pcdev->v4l2_dev); > >>if (err) > >> - goto exit_free_dma; > >> + goto exit_deactivate; > >> > >>pcdev->asds[0] = &pcdev->asd; > >>pcdev->notifier.subdevs = pcdev->asds; > >> @@ -2525,6 +2525,8 @@ static int pxa_camera_probe(struct platform_device > >> *pdev) > >>v4l2_clk_unregister(pcdev->mclk_clk); > >> exit_free_v4l2dev: > >>v4l2_device_unregister(&pcdev->v4l2_dev); > >> +exit_deactivate: > >> + pxa_camera_deactivate(pcdev); > >> exit_free_dma: > >>dma_release_channel(pcdev->dma_chans[2]); > >> exit_free_dma_u: -- Regards, Laurent Pinchart
Re: [PATCH 0/2] Add timers to en50221 protocol driver
Ping 2! On 10/15/2017 03:59 PM, Jasmin J. wrote: > Ping! >
Re: [PATCH v2] kernel-doc: parse DECLARE_KFIFO and DECLARE_KFIFO_PTR()
On Fri, 8 Dec 2017 09:05:12 -0500 Mauro Carvalho Chehab wrote: > So, teach kernel-doc how to parse DECLARE_KFIFO() and DECLARE_KFIFO_PTR(). > > While here, relax at the past DECLARE_foo() macros, accepting a random > number of spaces after comma. Applied, thanks. jon
Re: [PATCH] tuners: tda8290: reduce stack usage with kasan
On Mon, Dec 11, 2017 at 2:34 PM, Joe Perches wrote:
> On Mon, 2017-12-11 at 13:06 +0100, Arnd Bergmann wrote:
>> With CONFIG_KASAN enabled, we get a relatively large stack frame in one
>> function
>>
>> drivers/media/tuners/tda8290.c: In function 'tda8290_set_params':
>> drivers/media/tuners/tda8290.c:310:1: warning: the frame size of 1520 bytes
>> is larger than 1024 bytes [-Wframe-larger-than=]
>>
>> With CONFIG_KASAN_EXTRA this goes up to
>>
>> drivers/media/tuners/tda8290.c: In function 'tda8290_set_params':
>> drivers/media/tuners/tda8290.c:310:1: error: the frame size of 3200 bytes is
>> larger than 3072 bytes [-Werror=frame-larger-than=]
>>
>> We can significantly reduce this by marking local arrays as 'static const',
>> and
>> this should result in better compiled code for everyone.
> []
>> diff --git a/drivers/media/tuners/tda8290.c b/drivers/media/tuners/tda8290.c
> []
>> @@ -63,8 +63,8 @@ static int tda8290_i2c_bridge(struct dvb_frontend *fe, int
>> close)
>> {
>> struct tda8290_priv *priv = fe->analog_demod_priv;
>>
>> - unsigned char enable[2] = { 0x21, 0xC0 };
>> - unsigned char disable[2] = { 0x21, 0x00 };
>> + static unsigned char enable[2] = { 0x21, 0xC0 };
>> + static unsigned char disable[2] = { 0x21, 0x00 };
>
> Doesn't match commit message.
>
> static const or just static?
>
>> @@ -84,9 +84,9 @@ static int tda8295_i2c_bridge(struct dvb_frontend *fe, int
>> close)
>> {
>> struct tda8290_priv *priv = fe->analog_demod_priv;
>>
>> - unsigned char enable[2] = { 0x45, 0xc1 };
>> - unsigned char disable[2] = { 0x46, 0x00 };
>> - unsigned char buf[3] = { 0x45, 0x01, 0x00 };
>> + static unsigned char enable[2] = { 0x45, 0xc1 };
>> + static unsigned char disable[2] = { 0x46, 0x00 };
>
> etc.
>
>
Joe is correct - they can be CONSTified. My bad -- a lot of the code I
wrote many years ago has this problem -- I wasn't so stack-conscious
back then.
The bytes in `enable` / `disable` don't get changed, but they may be
copied to another byte array that does get changed. If would be best
to make these `static const`
Best regards,
Michael Ira Krufky
Re: [PATCH v8] uvcvideo: Add a metadata device node
Hi Guennadi,
On Monday, 11 December 2017 22:16:23 EET Laurent Pinchart wrote:
> On Wednesday, 6 December 2017 17:15:40 EET Guennadi Liakhovetski wrote:
> > From: Guennadi Liakhovetski
> >
> > Some UVC video cameras contain metadata in their payload headers. This
> > patch extracts that data, adding more clock synchronisation information,
> > on both bulk and isochronous endpoints and makes it available to the user
> > space on a separate video node, using the V4L2_CAP_META_CAPTURE capability
> > and the V4L2_BUF_TYPE_META_CAPTURE buffer queue type. By default, only the
> > V4L2_META_FMT_UVC pixel format is available from those nodes. However,
> > cameras can be added to the device ID table to additionally specify their
> > own metadata format, in which case that format will also become available
> > from the metadata node.
> >
> > Signed-off-by: Guennadi Liakhovetski
> > ---
> >
> > v8: addressed comments and integrated changes from Laurent, thanks again,
> > e.g.:
> >
> > - multiple stylistic changes
> > - remove the UVC_DEV_FLAG_METADATA_NODE flag / quirk: nodes are now
> > created unconditionally
> > - reuse uvc_ioctl_querycap()
> > - reuse code in uvc_register_video()
> > - set an error flag when the metadata buffer overflows
> >
> > drivers/media/usb/uvc/Makefile | 2 +-
> > drivers/media/usb/uvc/uvc_driver.c | 15 ++-
> > drivers/media/usb/uvc/uvc_isight.c | 2 +-
> > drivers/media/usb/uvc/uvc_metadata.c | 179 ++
> > drivers/media/usb/uvc/uvc_queue.c| 44 +++--
> > drivers/media/usb/uvc/uvc_video.c| 132 --
> > drivers/media/usb/uvc/uvcvideo.h | 16 +++-
> > include/uapi/linux/uvcvideo.h| 26 +
> > 8 files changed, 394 insertions(+), 22 deletions(-)
> > create mode 100644 drivers/media/usb/uvc/uvc_metadata.c
>
> [snip]
>
> > diff --git a/drivers/media/usb/uvc/uvc_video.c
> > b/drivers/media/usb/uvc/uvc_video.c index 13f459e..2fc0bf2 100644
> > --- a/drivers/media/usb/uvc/uvc_video.c
> > +++ b/drivers/media/usb/uvc/uvc_video.c
>
> [snip]
>
> > +static void uvc_video_decode_meta(struct uvc_streaming *stream,
> > + struct uvc_buffer *meta_buf,
> > + const u8 *mem, unsigned int length)
> > +{
> > + struct uvc_meta_buf *meta;
> > + size_t len_std = 2;
> > + bool has_pts, has_scr;
> > + unsigned long flags;
> > + ktime_t time;
> > + const u8 *scr;
> > +
> > + if (!meta_buf || length == 2)
> > + return;
> > +
> > + if (meta_buf->length - meta_buf->bytesused <
> > + length + sizeof(meta->ns) + sizeof(meta->sof)) {
> > + meta_buf->error = 1;
> > + return;
> > + }
> > +
> > + has_pts = mem[1] & UVC_STREAM_PTS;
> > + has_scr = mem[1] & UVC_STREAM_SCR;
> > +
> > + if (has_pts) {
> > + len_std += 4;
> > + scr = mem + 6;
> > + } else {
> > + scr = mem + 2;
> > + }
> > +
> > + if (has_scr)
> > + len_std += 6;
> > +
> > + if (stream->meta.format == V4L2_META_FMT_UVC)
> > + length = len_std;
> > +
> > + if (length == len_std && (!has_scr ||
> > + !memcmp(scr, stream->clock.last_scr, 6)))
> > + return;
> > +
> > + meta = (struct uvc_meta_buf *)((u8 *)meta_buf->mem +
> > meta_buf->bytesused); + local_irq_save(flags);
> > + time = uvc_video_get_time();
> > + meta->sof = usb_get_current_frame_number(stream->dev->udev);
>
> You need a put_unaligned here too. If you're fine with the patch below
> there's no need to resubmit, and
One more thing, __put_unaligned_cpu16() and __put_unaligned_cpu64() don't
compile on x86_64 with v4.12 (using media_build.git). I propose replacing them
with put_unaligned() which compiles and should do the right thing.
> Reviewed-by: Laurent Pinchart
>
> Would you mind sending me your test tool patch ?
>
> diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/
> uvc_video.c
> index 2fc0bf2221db..02e4997a32bb 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -1142,6 +1142,7 @@ static void uvc_video_decode_meta(struct uvc_streaming
> *stream,
> size_t len_std = 2;
> bool has_pts, has_scr;
> unsigned long flags;
> + unsigned int sof;
> ktime_t time;
> const u8 *scr;
>
> @@ -1177,9 +1178,10 @@ static void uvc_video_decode_meta(struct
> uvc_streaming *stream,
> meta = (struct uvc_meta_buf *)((u8 *)meta_buf->mem +
> meta_buf->bytesused);
> local_irq_save(flags);
> time = uvc_video_get_time();
> - meta->sof = usb_get_current_frame_number(stream->dev->udev);
> + sof = usb_get_current_frame_number(stream->dev->udev);
> local_irq_restore(flags);
> __put_unaligned_cpu64(ktime_to_ns(time), &meta->ns);
> + __put_unaligned_cpu16(sof, &meta->sof);
>
> if (has_scr)
> memcpy(stream->clock.last_scr, scr, 6);
>
> > + lo
Re: [PATCH] media: pxa_camera: disable and unprepare the clock source on error
Hi Laurent, > Hi Flavio, > > Thank you for the patch. > > On Wednesday, 6 December 2017 18:38:50 EET Flavio Ceolin wrote: >> pxa_camera_probe() was not calling pxa_camera_deactivate(), >> responsible to call clk_disable_unprepare(), on the failure path. This >> was leading to unbalancing source clock. >> >> Found by Linux Driver Verification project (linuxtesting.org). > > Any chance I could sign you up for more work on this driver ? :-) Definetely, this would be great :) > >> Signed-off-by: Flavio Ceolin > > Reviewed-by: Laurent Pinchart > > I expect Hans Verkuil to pick up the patch. > >> --- >> drivers/media/platform/pxa_camera.c | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/media/platform/pxa_camera.c >> b/drivers/media/platform/pxa_camera.c index 9d3f0cb..7877037 100644 >> --- a/drivers/media/platform/pxa_camera.c >> +++ b/drivers/media/platform/pxa_camera.c >> @@ -2489,7 +2489,7 @@ static int pxa_camera_probe(struct platform_device >> *pdev) dev_set_drvdata(&pdev->dev, pcdev); >> err = v4l2_device_register(&pdev->dev, &pcdev->v4l2_dev); >> if (err) >> -goto exit_free_dma; >> +goto exit_deactivate; >> >> pcdev->asds[0] = &pcdev->asd; >> pcdev->notifier.subdevs = pcdev->asds; >> @@ -2525,6 +2525,8 @@ static int pxa_camera_probe(struct platform_device >> *pdev) v4l2_clk_unregister(pcdev->mclk_clk); >> exit_free_v4l2dev: >> v4l2_device_unregister(&pcdev->v4l2_dev); >> +exit_deactivate: >> +pxa_camera_deactivate(pcdev); >> exit_free_dma: >> dma_release_channel(pcdev->dma_chans[2]); >> exit_free_dma_u: > > -- > Regards, > > Laurent Pinchart Regards, Flavio Ceolin
Re: [PATCH v2 13/14] drm: rcar-du: Restrict DPLL duty cycle workaround to H3 ES1.x
Hi Kieran,
I found this e-mail already written and sitting in my outbox, so even if it's
quite outdated I decided to still send it.
On Tuesday 01 Aug 2017 15:06:20 Kieran Bingham wrote:
> On 26/06/17 19:12, Laurent Pinchart wrote:
> > The H3 ES1.x exhibits dot clock duty cycle stability issues. We can work
> > around them by configuring the DPLL to twice the desired frequency,
> > coupled with a /2 post-divider. This isn't needed on other SoCs and
> > breaks HDMI output on M3-W for a currently unknown reason, so restrict
> > the workaround to H3 ES1.x.
> >
> > From an implementation point of view, move work around handling outside
> > of the rcar_du_dpll_divider() function by requesting a x2 DPLL output
> > frequency explicitly. The existing post-divider calculation mechanism
> > will then take care of dividing the clock by two automatically.
> >
> > While at it, print a more useful debugging message to ease debugging
> > clock rate issues.
> >
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
> > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 37 -
> > 1 file changed, 27 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 8f942ebdd0c6..6c29981377c0
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > @@ -13,6 +13,7 @@
> >
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -129,10 +130,8 @@ static void rcar_du_dpll_divider(struct rcar_du_crtc
> > *rcrtc,
> > for (fdpll = 1; fdpll < 32; fdpll++) {
> > unsigned long output;
> >
> > - /* 1/2 (FRQSEL=1) for duty rate 50% */
> > output = input * (n + 1) / (m + 1)
> > - / (fdpll + 1) / 2;
> > -
> > + / (fdpll + 1);
>
> I'm finding this hard to interpret vs the commit-message.
>
> Here we remove the /2 (which affects all targets... is this a problem?)
The purpose of the rcar_du_dpll_divider() function is to compute the DPLL
settings for a target output frequency. However, at the moment, it computes
settings that will generate twice the output frequency, assuming that the
caller will configure an additional /2 post-divider.
I found that confusing, so I've modified this function to generate the target
output frequency. The caller is modified below to request twice the desired
display clock frequency when adding the post-divider.
Note that DPLLs are available on Gen3 only, so this affects H3 and M3-W only.
> > if (output >= 4)
> > continue;
[snip]
> > @@ -185,7 +189,20 @@ static void rcar_du_crtc_set_display_timing(struct
> > rcar_du_crtc *rcrtc)>
> > extclk = clk_get_rate(rcrtc->extclock);
> > if (rcdu->info->dpll_ch & (1 << rcrtc->index)) {
> >
> > - rcar_du_dpll_divider(rcrtc, &dpll, extclk,
> > mode_clock);
> > + unsigned long target = mode_clock;
> > +
> > + /*
> > +* The H3 ES1.x exhibits dot clock duty cycle
> > stability
> > +* issues. We can work around them by configuring the
> > +* DPLL to twice the desired frequency, coupled with a
> > +* /2 post-divider. This isn't needed on other SoCs
> > and
>
> But here we discuss 'coupling' it with a /2 post - divider.
>
> My inference here then is that by setting a target that is 'twice' the value
> - code later will provide the /2 post-divide?
Correct. On H3 ES1.x the behaviour of the code is unchanged, while on H3 ES2.0
and M3-W we now configure the DPLL without the post-divider.
> > +* breaks HDMI output on M3-W for a currently unknown
> > +* reason, so restrict the workaround to H3 ES1.x.
> > +*/
> > + if (soc_device_match(rcar_du_r8a7795_es1))
> > + target *= 2;
> > +
> > + rcar_du_dpll_divider(rcrtc, &dpll, extclk, target);
> > extclk = dpll.output;
> > }
> >
> > @@ -197,8 +214,6 @@ static void rcar_du_crtc_set_display_timing(struct
> > rcar_du_crtc *rcrtc)
> > if (abs((long)extrate - (long)mode_clock) <
> > abs((long)rate - (long)mode_clock)) {
> > - dev_dbg(rcrtc->group->dev->dev,
> > - "crtc%u: using external clock\n",
> > rcrtc->index);
> >
> > if (rcdu->info->dpll_ch & (1 << rcrtc->index)) {
> > u32 dpllcr = DPLLCR_CODE | DPLLCR_CLKE
> > @@ -215,12 +230,14 @@ static void rcar_du_crtc_set_display_timing(struct
> > rcar_du_crtc *rcrtc)
> > rcar_du_group_write(rcrtc->group, DPLLCR,
Re: [PATCH v8] uvcvideo: Add a metadata device node
Hi Guennadi,
Thank you for the patch.
On Wednesday, 6 December 2017 17:15:40 EET Guennadi Liakhovetski wrote:
> From: Guennadi Liakhovetski
>
> Some UVC video cameras contain metadata in their payload headers. This
> patch extracts that data, adding more clock synchronisation information,
> on both bulk and isochronous endpoints and makes it available to the user
> space on a separate video node, using the V4L2_CAP_META_CAPTURE capability
> and the V4L2_BUF_TYPE_META_CAPTURE buffer queue type. By default, only the
> V4L2_META_FMT_UVC pixel format is available from those nodes. However,
> cameras can be added to the device ID table to additionally specify their
> own metadata format, in which case that format will also become available
> from the metadata node.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
>
> v8: addressed comments and integrated changes from Laurent, thanks again,
> e.g.:
>
> - multiple stylistic changes
> - remove the UVC_DEV_FLAG_METADATA_NODE flag / quirk: nodes are now
> created unconditionally
> - reuse uvc_ioctl_querycap()
> - reuse code in uvc_register_video()
> - set an error flag when the metadata buffer overflows
>
> drivers/media/usb/uvc/Makefile | 2 +-
> drivers/media/usb/uvc/uvc_driver.c | 15 ++-
> drivers/media/usb/uvc/uvc_isight.c | 2 +-
> drivers/media/usb/uvc/uvc_metadata.c | 179
> drivers/media/usb/uvc/uvc_queue.c| 44 +++--
> drivers/media/usb/uvc/uvc_video.c| 132 --
> drivers/media/usb/uvc/uvcvideo.h | 16 +++-
> include/uapi/linux/uvcvideo.h| 26 +
> 8 files changed, 394 insertions(+), 22 deletions(-)
> create mode 100644 drivers/media/usb/uvc/uvc_metadata.c
[snip]
> diff --git a/drivers/media/usb/uvc/uvc_video.c
> b/drivers/media/usb/uvc/uvc_video.c index 13f459e..2fc0bf2 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
[snip]
> +static void uvc_video_decode_meta(struct uvc_streaming *stream,
> + struct uvc_buffer *meta_buf,
> + const u8 *mem, unsigned int length)
> +{
> + struct uvc_meta_buf *meta;
> + size_t len_std = 2;
> + bool has_pts, has_scr;
> + unsigned long flags;
> + ktime_t time;
> + const u8 *scr;
> +
> + if (!meta_buf || length == 2)
> + return;
> +
> + if (meta_buf->length - meta_buf->bytesused <
> + length + sizeof(meta->ns) + sizeof(meta->sof)) {
> + meta_buf->error = 1;
> + return;
> + }
> +
> + has_pts = mem[1] & UVC_STREAM_PTS;
> + has_scr = mem[1] & UVC_STREAM_SCR;
> +
> + if (has_pts) {
> + len_std += 4;
> + scr = mem + 6;
> + } else {
> + scr = mem + 2;
> + }
> +
> + if (has_scr)
> + len_std += 6;
> +
> + if (stream->meta.format == V4L2_META_FMT_UVC)
> + length = len_std;
> +
> + if (length == len_std && (!has_scr ||
> + !memcmp(scr, stream->clock.last_scr, 6)))
> + return;
> +
> + meta = (struct uvc_meta_buf *)((u8 *)meta_buf->mem +
> meta_buf->bytesused);
> + local_irq_save(flags);
> + time = uvc_video_get_time();
> + meta->sof = usb_get_current_frame_number(stream->dev->udev);
You need a put_unaligned here too. If you're fine with the patch below there's
no need to resubmit, and
Reviewed-by: Laurent Pinchart
Would you mind sending me your test tool patch ?
diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/
uvc_video.c
index 2fc0bf2221db..02e4997a32bb 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1142,6 +1142,7 @@ static void uvc_video_decode_meta(struct uvc_streaming
*stream,
size_t len_std = 2;
bool has_pts, has_scr;
unsigned long flags;
+ unsigned int sof;
ktime_t time;
const u8 *scr;
@@ -1177,9 +1178,10 @@ static void uvc_video_decode_meta(struct uvc_streaming
*stream,
meta = (struct uvc_meta_buf *)((u8 *)meta_buf->mem +
meta_buf->bytesused);
local_irq_save(flags);
time = uvc_video_get_time();
- meta->sof = usb_get_current_frame_number(stream->dev->udev);
+ sof = usb_get_current_frame_number(stream->dev->udev);
local_irq_restore(flags);
__put_unaligned_cpu64(ktime_to_ns(time), &meta->ns);
+ __put_unaligned_cpu16(sof, &meta->sof);
if (has_scr)
memcpy(stream->clock.last_scr, scr, 6);
> + local_irq_restore(flags);
> + __put_unaligned_cpu64(ktime_to_ns(time), &meta->ns);
> +
> + if (has_scr)
> + memcpy(stream->clock.last_scr, scr, 6);
> +
> + memcpy(&meta->length, mem, length);
> + meta_buf->bytesused += length + sizeof(meta->ns) + sizeof(meta->sof);
> +
> + uvc_trace(UVC_TRACE_FRAME,
> + "%s(): t-sys %lluns, SOF %u, len %u, flags 0x%x, PT
[PATCH] [media] ddbridge: stv09xx: detach frontends on lnb failure
From: Daniel Scheller
While the failure handling in dvb_input_attach() has been improved lately
so any tuner failure won't result in demod driver modules with a
usecount > 0 anymore (thus requiring rmmod -f), there's still an issue
with stv090x and stv0910 based tuner modules, in that LNB driver attach
failures leave an attached demod frontend driver behind which have a
usecount of > 0 in this failure case, due to them not being detached/
released. Fix this by detaching the demod frontends if the LNB driver
fails.
Richard tested and verified the changes with STV0910 hardware, thus adding
his Tested-by.
Signed-off-by: Daniel Scheller
Tested-by: Richard Scobie
---
drivers/media/pci/ddbridge/ddbridge-core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c
b/drivers/media/pci/ddbridge/ddbridge-core.c
index 348cc8b3d1f9..f4d6e43aa0f0 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -1114,6 +1114,7 @@ static int demod_attach_stv0900(struct ddb_input *input,
int type)
0, (input->nr & 1) ?
(0x09 - type) : (0x0b - type))) {
dev_err(dev, "No LNBH24 found!\n");
+ dvb_frontend_detach(dvb->fe);
return -ENODEV;
}
return 0;
@@ -1196,6 +1197,7 @@ static int demod_attach_stv0910(struct ddb_input *input,
int type)
lnbcfg.i2c_address = (((input->nr & 1) ? 0x09 : 0x08) << 1);
if (!dvb_attach(lnbh25_attach, dvb->fe, &lnbcfg, i2c)) {
dev_err(dev, "No LNBH25 found!\n");
+ dvb_frontend_detach(dvb->fe);
return -ENODEV;
}
}
--
2.13.6
Re: [PATCH 3/3 v7] uvcvideo: add a metadata device node
Hi Guennadi, On Wednesday, 6 December 2017 17:08:14 EET Guennadi Liakhovetski wrote: > Hi Laurent, > > While testing the new patch version, we did introduce a couple of > differences: > > 1. We cannot (easily) reuse .vidioc_querycap() - the metadata node uses > v4l2_fh_open() directly, so, it has a different struct file::private_data > pointer. OK, no problem, it's not a big deal.µ > 2. After your video device unification, the order has swapped: now > /dev/video0 is a metadata node and /dev/video1 is a video node. Is that > how you wanted to have this or you don't mind or shall I swap them back? > For now I've swapped them back, I think that would be more appropriate. I agree, that's better, thank you. -- Regards, Laurent Pinchart
Re: [PATCH v12 2/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver
Hi Niklas,
Thank you for the patch.
On Wednesday, 29 November 2017 21:32:35 EET Niklas Söderlund wrote:
> A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver
> supports the rcar-vin driver on R-Car Gen3 SoCs where separate CSI-2
The driver supports the driver ?
> hardware blocks are connected between the video sources and the video
> grabbers (VIN).
>
> Driver is based on a prototype by Koji Matsuoka in the Renesas BSP.
>
> Signed-off-by: Niklas Söderlund
> Reviewed-by: Hans Verkuil
> ---
> drivers/media/platform/rcar-vin/Kconfig | 12 +
> drivers/media/platform/rcar-vin/Makefile| 1 +
> drivers/media/platform/rcar-vin/rcar-csi2.c | 898 +
> 3 files changed, 911 insertions(+)
> create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c
[snip]
> diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c
> b/drivers/media/platform/rcar-vin/rcar-csi2.c new file mode 100644
> index ..30aafcbb7a3642c6
> --- /dev/null
> +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> @@ -0,0 +1,898 @@
> +/*
> + * Driver for Renesas R-Car MIPI CSI-2 Receiver
> + *
> + * Copyright (C) 2017 Renesas Electronics Corp.
> + *
> + * 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.
Given that copyright headers are replaced by SPDX in the kernel sources, you
might want to get rid of this paragraph and add
// SPDX-License-Identifier: GPL-2.0+
as the first line of the file.
> + */
[snip]
> +static int rcar_csi2_calc_phypll(struct rcar_csi2 *priv, unsigned int bpp,
> + u32 *phypll)
> +{
> +
> + const struct phypll_hsfreqrange *hsfreq;
> + struct media_pad *pad, *source_pad;
> + struct v4l2_subdev *source = NULL;
No need to initialize this to NULL.
> + struct v4l2_ctrl *ctrl;
> + u64 mbps;
> +
> + /* Get remote subdevice */
> + pad = &priv->subdev.entity.pads[RCAR_CSI2_SINK];
> + source_pad = media_entity_remote_pad(pad);
> + if (!source_pad) {
> + dev_err(priv->dev, "Could not find remote source pad\n");
> + return -ENODEV;
> + }
> + source = media_entity_to_v4l2_subdev(source_pad->entity);
> +
> + dev_dbg(priv->dev, "Using source %s pad: %u\n", source->name,
> + source_pad->index);
Doesn't this duplicate rcar_csi2_sd_info() ?
> + /* Read the pixel rate control from remote */
> + ctrl = v4l2_ctrl_find(source->ctrl_handler, V4L2_CID_PIXEL_RATE);
> + if (!ctrl) {
> + dev_err(priv->dev, "no link freq control in subdev %s\n",
s/link freq/pixel rate/
> + source->name);
> + return -EINVAL;
> + }
> +
> + /* Calculate the phypll */
> + mbps = v4l2_ctrl_g_ctrl_int64(ctrl) * bpp;
> + do_div(mbps, priv->lanes * 100);
> +
> + for (hsfreq = priv->info->hsfreqrange; hsfreq->mbps != 0; hsfreq++)
> + if (hsfreq->mbps >= mbps)
> + break;
If you ever feel bored you could implement lookup through bisection ;-)
> + if (!hsfreq->mbps) {
> + dev_err(priv->dev, "Unsupported PHY speed (%llu Mbps)", mbps);
> + return -ERANGE;
> + }
> +
> + dev_dbg(priv->dev, "PHY HSFREQRANGE requested %llu got %u Mbps\n", mbps,
> + hsfreq->mbps);
> +
> + *phypll = PHYPLL_HSFREQRANGE(hsfreq->reg);
> +
> + return 0;
> +}
> +
> +static int rcar_csi2_start(struct rcar_csi2 *priv)
> +{
> + const struct rcar_csi2_format *format;
> + u32 phycnt, phypll, tmp;
> + u32 vcdt = 0, vcdt2 = 0;
> + unsigned int i;
> + int ret;
> +
> + dev_dbg(priv->dev, "Input size (%ux%u%c)\n",
> + priv->mf.width, priv->mf.height,
> + priv->mf.field == V4L2_FIELD_NONE ? 'p' : 'i');
> +
> + /* Code is validated in set_ftm */
s/set_ftm/set_fmt/
> + format = rcar_csi2_code_to_fmt(priv->mf.code);
You could also cache the pointer to the format info structure in the set_fmt
handler instead of looking it up every time, that's up to you.
> + /*
> + * Enable all Virtual Channels
> + *
> + * NOTE: It's not possible to get individual datatype for each
> + * source virtual channel. Once this is possible in V4L2
> + * it should be used here.
> + */
> + for (i = 0; i < 4; i++) {
> + tmp = VCDT_SEL_VC(i) | VCDT_VCDTN_EN | VCDT_SEL_DTN_ON |
> + VCDT_SEL_DT(format->datatype);
Could you find a better name than tmp for the variable ? It can also be
declared inside the loop as it isn't used outside.
> +
> + /* Store in correct reg and offset */
> + if (i < 2)
> + vcdt |= tmp << ((i % 2) * 16);
> + else
> + vcdt2 |= tmp << ((i % 2) *
Re: [PATCH] tuners: tda8290: reduce stack usage with kasan
On Mon, 2017-12-11 at 13:06 +0100, Arnd Bergmann wrote:
> With CONFIG_KASAN enabled, we get a relatively large stack frame in one
> function
>
> drivers/media/tuners/tda8290.c: In function 'tda8290_set_params':
> drivers/media/tuners/tda8290.c:310:1: warning: the frame size of 1520 bytes
> is larger than 1024 bytes [-Wframe-larger-than=]
>
> With CONFIG_KASAN_EXTRA this goes up to
>
> drivers/media/tuners/tda8290.c: In function 'tda8290_set_params':
> drivers/media/tuners/tda8290.c:310:1: error: the frame size of 3200 bytes is
> larger than 3072 bytes [-Werror=frame-larger-than=]
>
> We can significantly reduce this by marking local arrays as 'static const',
> and
> this should result in better compiled code for everyone.
[]
> diff --git a/drivers/media/tuners/tda8290.c b/drivers/media/tuners/tda8290.c
[]
> @@ -63,8 +63,8 @@ static int tda8290_i2c_bridge(struct dvb_frontend *fe, int
> close)
> {
> struct tda8290_priv *priv = fe->analog_demod_priv;
>
> - unsigned char enable[2] = { 0x21, 0xC0 };
> - unsigned char disable[2] = { 0x21, 0x00 };
> + static unsigned char enable[2] = { 0x21, 0xC0 };
> + static unsigned char disable[2] = { 0x21, 0x00 };
Doesn't match commit message.
static const or just static?
> @@ -84,9 +84,9 @@ static int tda8295_i2c_bridge(struct dvb_frontend *fe, int
> close)
> {
> struct tda8290_priv *priv = fe->analog_demod_priv;
>
> - unsigned char enable[2] = { 0x45, 0xc1 };
> - unsigned char disable[2] = { 0x46, 0x00 };
> - unsigned char buf[3] = { 0x45, 0x01, 0x00 };
> + static unsigned char enable[2] = { 0x45, 0xc1 };
> + static unsigned char disable[2] = { 0x46, 0x00 };
etc.
Re: [PATCH v10 4/4] [media] platform: Add Synopsys DesignWare HDMI RX Controller Driver
On Mon, Dec 11, 2017 at 6:41 PM, Jose Abreu wrote: > This is an initial submission for the Synopsys DesignWare HDMI RX > Controller Driver. This driver interacts with a phy driver so that > a communication between them is created and a video pipeline is > configured. > > The controller + phy pipeline can then be integrated into a fully > featured system that can be able to receive video up to 4k@60Hz > with deep color 48bit RGB, depending on the platform. Although, > this initial version does not yet handle deep color modes. > > This driver was implemented as a standard V4L2 subdevice and its > main features are: > - Internal state machine that reconfigures phy until the > video is not stable > - JTAG communication with phy > - Inter-module communication with phy driver > - Debug write/read ioctls > > Some notes: > - RX sense controller (cable connection/disconnection) must > be handled by the platform wrapper as this is not integrated > into the controller RTL > - The same goes for EDID ROM's > - ZCAL calibration is needed only in FPGA platforms, in ASIC > this is not needed > - The state machine is not an ideal solution as it creates a > kthread but it is needed because some sources might not be > very stable at sending the video (i.e. we must react > accordingly). > > Signed-off-by: Jose Abreu > Cc: Joao Pinto > Cc: Mauro Carvalho Chehab > Cc: Hans Verkuil > Cc: Sylwester Nawrocki > Cc: Sakari Ailus > Cc: Philippe Ombredanne > --- > Changes from v9: > - Use SPDX License ID (Philippe) Acked-by: Philippe Ombredanne
Re: [PATCH v10 3/4] [media] platform: Add Synopsys DesignWare HDMI RX PHY e405 Driver
On Mon, Dec 11, 2017 at 6:41 PM, Jose Abreu wrote: > This adds support for the Synopsys DesignWare HDMI RX PHY e405. This > phy receives and decodes HDMI video that is delivered to a controller. > > Main features included in this driver are: > - Equalizer algorithm that chooses the phy best settings > according to the detected HDMI cable characteristics. > - Support for scrambling > - Support for HDMI 2.0 modes up to 6G (HDMI 4k@60Hz). > > The driver was implemented as a standalone V4L2 subdevice and the > phy interface with the controller was implemented using V4L2 ioctls. I > do not know if this is the best option but it is not possible to use the > existing API functions directly as we need specific functions that will > be called by the controller at specific configuration stages. > > There is also a bidirectional communication between controller and phy: > The phy must provide functions that the controller will call (i.e. > configuration functions) and the controller must provide read/write > callbacks, as well as other specific functions. > > Signed-off-by: Jose Abreu > Cc: Joao Pinto > Cc: Mauro Carvalho Chehab > Cc: Hans Verkuil > Cc: Sylwester Nawrocki > Cc: Philippe Ombredanne > --- > Changes from v9: > - Use SPDX License ID (Philippe) Acked-by: Philippe Ombredanne Thanks! -- Cordially Philippe Ombredanne
[PATCH v6 1/6] [media] vb2: add is_unordered callback for drivers
From: Gustavo Padovan
Explicit synchronization benefits a lot from ordered queues, they fit
better in a pipeline with DRM for example so create a opt-in way for
drivers notify videobuf2 that the queue is unordered.
Drivers don't need implement it if the queue is ordered.
Signed-off-by: Gustavo Padovan
---
include/media/videobuf2-core.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index ef9b64398c8c..eddb38a2a2f3 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -368,6 +368,9 @@ struct vb2_buffer {
* callback by calling vb2_buffer_done() with either
* %VB2_BUF_STATE_DONE or %VB2_BUF_STATE_ERROR; may use
* vb2_wait_for_all_buffers() function
+ * @is_unordered: tell if the queue format is unordered. The default is
+ * assumed to be ordered and this function only needs to
+ * be implemented for unordered queues.
* @buf_queue: passes buffer vb to the driver; driver may start
* hardware operation on this buffer; driver should give
* the buffer back by calling vb2_buffer_done() function;
@@ -391,6 +394,7 @@ struct vb2_ops {
int (*start_streaming)(struct vb2_queue *q, unsigned int count);
void (*stop_streaming)(struct vb2_queue *q);
+ int (*is_unordered)(struct vb2_queue *q);
void (*buf_queue)(struct vb2_buffer *vb);
};
@@ -564,6 +568,7 @@ struct vb2_queue {
u32 cnt_wait_finish;
u32 cnt_start_streaming;
u32 cnt_stop_streaming;
+ u32 cnt_is_unordered;
#endif
};
--
2.13.6
[PATCH v6 3/6] [media] vb2: add explicit fence user API
From: Gustavo Padovan
Turn the reserved2 field into fence_fd that we will use to send
an in-fence to the kernel and return an out-fence from the kernel to
userspace.
Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that should be used
when sending a fence to the kernel to be waited on, and
V4L2_BUF_FLAG_OUT_FENCE, to ask the kernel to give back an out-fence.
v4:
- make it a union with reserved2 and fence_fd (Hans Verkuil)
v3:
- make the out_fence refer to the current buffer (Hans Verkuil)
v2: add documentation
Signed-off-by: Gustavo Padovan
---
Documentation/media/uapi/v4l/buffer.rst | 15 +++
drivers/media/usb/cpia2/cpia2_v4l.c | 2 +-
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 4 ++--
drivers/media/v4l2-core/videobuf2-v4l2.c | 2 +-
include/uapi/linux/videodev2.h| 7 ++-
5 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/Documentation/media/uapi/v4l/buffer.rst
b/Documentation/media/uapi/v4l/buffer.rst
index ae6ee73f151c..eeefbd2547e7 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -648,6 +648,21 @@ Buffer Flags
- Start Of Exposure. The buffer timestamp has been taken when the
exposure of the frame has begun. This is only valid for the
``V4L2_BUF_TYPE_VIDEO_CAPTURE`` buffer type.
+* .. _`V4L2-BUF-FLAG-IN-FENCE`:
+
+ - ``V4L2_BUF_FLAG_IN_FENCE``
+ - 0x0020
+ - Ask V4L2 to wait on fence passed in ``fence_fd`` field. The buffer
+ won't be queued to the driver until the fence signals.
+
+* .. _`V4L2-BUF-FLAG-OUT-FENCE`:
+
+ - ``V4L2_BUF_FLAG_OUT_FENCE``
+ - 0x0040
+ - Request a fence to be attached to the buffer. The ``fence_fd``
+ field on
+ :ref:`VIDIOC_QBUF` is used as a return argument to send the out-fence
+ fd to userspace.
diff --git a/drivers/media/usb/cpia2/cpia2_v4l.c
b/drivers/media/usb/cpia2/cpia2_v4l.c
index a1c59f19cf2d..7d7459fa2077 100644
--- a/drivers/media/usb/cpia2/cpia2_v4l.c
+++ b/drivers/media/usb/cpia2/cpia2_v4l.c
@@ -948,7 +948,7 @@ static int cpia2_dqbuf(struct file *file, void *fh, struct
v4l2_buffer *buf)
buf->sequence = cam->buffers[buf->index].seq;
buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer;
buf->length = cam->frame_size;
- buf->reserved2 = 0;
+ buf->fence_fd = -1;
buf->reserved = 0;
memset(&buf->timecode, 0, sizeof(buf->timecode));
diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index 821f2aa299ae..3a31d318df2a 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -370,7 +370,7 @@ struct v4l2_buffer32 {
__s32 fd;
} m;
__u32 length;
- __u32 reserved2;
+ __s32 fence_fd;
__u32 reserved;
};
@@ -533,7 +533,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer *kp, struct
v4l2_buffer32 __user
put_user(kp->timestamp.tv_usec, &up->timestamp.tv_usec) ||
copy_to_user(&up->timecode, &kp->timecode, sizeof(struct
v4l2_timecode)) ||
put_user(kp->sequence, &up->sequence) ||
- put_user(kp->reserved2, &up->reserved2) ||
+ put_user(kp->fence_fd, &up->fence_fd) ||
put_user(kp->reserved, &up->reserved) ||
put_user(kp->length, &up->length))
return -EFAULT;
diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 4075314a6989..4a5244ee2c58 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -203,7 +203,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, void
*pb)
b->timestamp = ns_to_timeval(vb->timestamp);
b->timecode = vbuf->timecode;
b->sequence = vbuf->sequence;
- b->reserved2 = 0;
+ b->fence_fd = -1;
b->reserved = 0;
if (q->is_multiplanar) {
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index a8ea632c14f0..17e163b5036d 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -926,7 +926,10 @@ struct v4l2_buffer {
__s32 fd;
} m;
__u32 length;
- __u32 reserved2;
+ union {
+ __s32 fence_fd;
+ __u32 reserved2;
+ };
__u32 reserved;
};
@@ -963,6 +966,8 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_TSTAMP_SRC_SOE 0x0001
/* mem2mem encoder/decoder */
#define V4L2_BUF_FLAG_LAST 0x0010
+#define V4L2_BUF_FLAG_IN_FENCE 0x0020
+#define V4L2_BUF_FLAG_OUT_F
[PATCH v6 0/6] V4L2 Explicit Synchronization
From: Gustavo Padovan Hi, One more iteration of the explicit fences patches, please refer to the previous version[1] for more details about the general mechanism This version makes the patchset and the implementation much more simple, to start we are not using a ordered capability anymore, but instead we have a VIDIOC_ENUM_FMT flag to tell when the queue in not ordered. Drivers with ordered queues/formats don't need implement anything. See patches 1 and 2 for more details. The implementation of in-fences and out-fences were condensed in just patches 4 and 5, making it more self-contained and easy to understand. See the patches for detailed changelog. Please review! Thanks. Gustavo. [1] https://lkml.org/lkml/2017/11/15/550 Gustavo Padovan (6): [media] vb2: add is_unordered callback for drivers [media] v4l: add 'unordered' flag to format description ioctl [media] vb2: add explicit fence user API [media] vb2: add in-fence support to QBUF [media] vb2: add out-fence support to QBUF [media] v4l: Document explicit synchronization behavior Documentation/media/uapi/v4l/buffer.rst | 15 ++ Documentation/media/uapi/v4l/vidioc-enum-fmt.rst | 3 + Documentation/media/uapi/v4l/vidioc-qbuf.rst | 47 - Documentation/media/uapi/v4l/vidioc-querybuf.rst | 9 +- drivers/media/usb/cpia2/cpia2_v4l.c | 2 +- drivers/media/v4l2-core/Kconfig | 1 + drivers/media/v4l2-core/v4l2-compat-ioctl32.c| 4 +- drivers/media/v4l2-core/videobuf2-core.c | 239 +-- drivers/media/v4l2-core/videobuf2-v4l2.c | 52 - include/media/videobuf2-core.h | 41 +++- include/uapi/linux/videodev2.h | 8 +- 11 files changed, 393 insertions(+), 28 deletions(-) -- 2.13.6
[PATCH v6 5/6] [media] vb2: add out-fence support to QBUF
From: Gustavo Padovan
If V4L2_BUF_FLAG_OUT_FENCE flag is present on the QBUF call we create
an out_fence and send its fd to userspace on the fence_fd field as a
return arg for the QBUF call.
The fence is signaled on buffer_done(), when the job on the buffer is
finished.
v7:
- merge patch that add the infrastructure to out-fences into
this one (Alex Courbot)
- Do not install the fd if there is no fence. (Alex Courbot)
- do not report error on requeueing, just WARN_ON_ONCE() (Hans)
v6
- get rid of the V4L2_EVENT_OUT_FENCE event. We always keep the
ordering in vb2 for queueing in the driver, so the event is not
necessary anymore and the out_fence_fd is sent back to userspace
on QBUF call return arg
- do not allow requeueing with out-fences, instead mark the buffer
with an error and wake up to userspace.
- send the out_fence_fd back to userspace on the fence_fd field
v5:
- delay fd_install to DQ_EVENT (Hans)
- if queue is fully ordered send OUT_FENCE event right away
(Brian)
- rename 'q->ordered' to 'q->ordered_in_driver'
- merge change to implement OUT_FENCE event here
v4:
- return the out_fence_fd in the BUF_QUEUED event(Hans)
v3: - add WARN_ON_ONCE(q->ordered) on requeueing (Hans)
- set the OUT_FENCE flag if there is a fence pending (Hans)
- call fd_install() after vb2_core_qbuf() (Hans)
- clean up fence if vb2_core_qbuf() fails (Hans)
- add list to store sync_file and fence for the next queued buffer
v2: check if the queue is ordered.
Signed-off-by: Gustavo Padovan
---
drivers/media/v4l2-core/videobuf2-core.c | 99 +---
drivers/media/v4l2-core/videobuf2-v4l2.c | 29 +-
include/media/videobuf2-core.h | 22 +++
3 files changed, 139 insertions(+), 11 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 520aa3c7d9f0..cbe115f00736 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -351,6 +352,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum
vb2_memory memory,
vb->planes[plane].length = plane_sizes[plane];
vb->planes[plane].min_length = plane_sizes[plane];
}
+ vb->out_fence_fd = -1;
q->bufs[vb->index] = vb;
/* Allocate video buffer memory for the MMAP type */
@@ -931,10 +933,20 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
vb2_buffer_state state)
case VB2_BUF_STATE_QUEUED:
break;
case VB2_BUF_STATE_REQUEUEING:
+ /* Requeuing with explicit synchronization, spit warning */
+ WARN_ON_ONCE(vb->out_fence);
+
if (q->start_streaming_called)
__enqueue_in_driver(vb);
- return;
+ break;
default:
+ if (state == VB2_BUF_STATE_ERROR)
+ dma_fence_set_error(vb->out_fence, -EFAULT);
+ dma_fence_signal(vb->out_fence);
+ dma_fence_put(vb->out_fence);
+ vb->out_fence = NULL;
+ vb->out_fence_fd = -1;
+
/* Inform any processes that may be waiting for buffers */
wake_up(&q->done_wq);
break;
@@ -1330,6 +1342,65 @@ int vb2_core_prepare_buf(struct vb2_queue *q, unsigned
int index, void *pb)
}
EXPORT_SYMBOL_GPL(vb2_core_prepare_buf);
+static inline const char *vb2_fence_get_driver_name(struct dma_fence *fence)
+{
+ return "vb2_fence";
+}
+
+static inline const char *vb2_fence_get_timeline_name(struct dma_fence *fence)
+{
+ return "vb2_fence_timeline";
+}
+
+static inline bool vb2_fence_enable_signaling(struct dma_fence *fence)
+{
+ return true;
+}
+
+static const struct dma_fence_ops vb2_fence_ops = {
+ .get_driver_name = vb2_fence_get_driver_name,
+ .get_timeline_name = vb2_fence_get_timeline_name,
+ .enable_signaling = vb2_fence_enable_signaling,
+ .wait = dma_fence_default_wait,
+};
+
+int vb2_setup_out_fence(struct vb2_queue *q, unsigned int index)
+{
+ struct vb2_buffer *vb;
+ u64 context;
+
+ vb = q->bufs[index];
+
+ vb->out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
+
+ if (call_qop(q, is_unordered, q))
+ context = dma_fence_context_alloc(1);
+ else
+ context = q->out_fence_context;
+
+ vb->out_fence = kzalloc(sizeof(*vb->out_fence), GFP_KERNEL);
+ if (!vb->out_fence)
+ return -ENOMEM;
+
+ dma_fence_init(vb->out_fence, &vb2_fence_ops, &q->out_fence_lock,
+ context, 1);
+ if (!vb->out_fence) {
+ put_unused_fd(vb->out_fence
[PATCH v6 6/6] [media] v4l: Document explicit synchronization behavior
From: Gustavo Padovan Add section to VIDIOC_QBUF about it v5: - Remove V4L2_CAP_ORDERED - Add doc about V4L2_FMT_FLAG_UNORDERED v4: - Document ordering behavior for in-fences - Document V4L2_CAP_ORDERED capability - Remove doc about OUT_FENCE event - Document immediate return of out-fence in QBUF v3: - make the out_fence refer to the current buffer (Hans) - Note what happens when the IN_FENCE is not set (Hans) v2: - mention that fences are files (Hans) - rework for the new API Signed-off-by: Gustavo Padovan --- Documentation/media/uapi/v4l/vidioc-qbuf.rst | 47 +++- Documentation/media/uapi/v4l/vidioc-querybuf.rst | 9 - 2 files changed, 54 insertions(+), 2 deletions(-) diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst b/Documentation/media/uapi/v4l/vidioc-qbuf.rst index 9e448a4aa3aa..8809397fb110 100644 --- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst +++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst @@ -54,7 +54,7 @@ When the buffer is intended for output (``type`` is or ``V4L2_BUF_TYPE_VBI_OUTPUT``) applications must also initialize the ``bytesused``, ``field`` and ``timestamp`` fields, see :ref:`buffer` for details. Applications must also set ``flags`` to 0. The -``reserved2`` and ``reserved`` fields must be set to 0. When using the +``reserved`` field must be set to 0. When using the :ref:`multi-planar API `, the ``m.planes`` field must contain a userspace pointer to a filled-in array of struct :c:type:`v4l2_plane` and the ``length`` field must be set @@ -118,6 +118,51 @@ immediately with an ``EAGAIN`` error code when no buffer is available. The struct :c:type:`v4l2_buffer` structure is specified in :ref:`buffer`. +Explicit Synchronization + + +Explicit Synchronization allows us to control the synchronization of +shared buffers from userspace by passing fences to the kernel and/or +receiving them from it. Fences passed to the kernel are named in-fences and +the kernel should wait on them to signal before using the buffer, i.e., queueing +it to the driver. On the other side, the kernel can create out-fences for the +buffers it queues to the drivers. Out-fences signal when the driver is +finished with buffer, i.e., the buffer is ready. The fences are represented +as a file and passed as a file descriptor to userspace. + +The in-fences are communicated to the kernel at the ``VIDIOC_QBUF`` ioctl +using the ``V4L2_BUF_FLAG_IN_FENCE`` buffer flag and the `fence_fd` field. If +an in-fence needs to be passed to the kernel, `fence_fd` should be set to the +fence file descriptor number and the ``V4L2_BUF_FLAG_IN_FENCE`` should be set +as well. Setting one but not the other will cause ``VIDIOC_QBUF`` to return +with error. The fence_fd field will be ignored if the +``V4L2_BUF_FLAG_IN_FENCE`` is not set. + +The videobuf2-core will guarantee that all buffers queued with in-fence will +be queued to the drivers in the same order. Fence may signal out of order, so +this guarantee at videobuf2 is necessary to not change ordering. + +If the in-fence signals with an error the videobuf2 won't queue the buffer to +the driver, instead it will flag it with an error. And then wait for the +previous buffer to complete before asking userspace dequeue the buffer with +error - to make sure we deliver the buffers back in the correct order. + +To get an out-fence back from V4L2 the ``V4L2_BUF_FLAG_OUT_FENCE`` flag should +be set to ask for a fence to be attached to the buffer. The out-fence fd is +sent to userspace as a ``VIDIOC_QBUF`` return argument on the `fence_fd` field. + +Note the the same `fence_fd` field is used for both sending the in-fence as +input argument to receive the out-fence as a return argument. + +At streamoff the out-fences will either signal normally if the driver waits +for the operations on the buffers to finish or signal with an error if the +driver cancels the pending operations. Buffers with in-fences won't be queued +to the driver if their fences signal. It will be cleaned up. + +The ``V4L2_FMT_FLAG_UNORDERED`` flag in ``VIDIOC_ENUM_FMT`` tells userspace +that the current buffer queues is able to keep the ordering of buffers, i.e., +the dequeing of buffers will happen at the same order we queue them, with no +reordering by the driver. Return Value diff --git a/Documentation/media/uapi/v4l/vidioc-querybuf.rst b/Documentation/media/uapi/v4l/vidioc-querybuf.rst index dd54747fabc9..df964c4d916b 100644 --- a/Documentation/media/uapi/v4l/vidioc-querybuf.rst +++ b/Documentation/media/uapi/v4l/vidioc-querybuf.rst @@ -44,7 +44,7 @@ and the ``index`` field. Valid index numbers range from zero to the number of buffers allocated with :ref:`VIDIOC_REQBUFS` (struct :c:type:`v4l2_requestbuffers` ``count``) minus -one. The ``reserved`` and ``reserved2`` fields must be set to 0. When +one. The ``reserved`` field must be set to 0. Whe
[PATCH v6 4/6] [media] vb2: add in-fence support to QBUF
From: Gustavo Padovan
Receive in-fence from userspace and add support for waiting on them
before queueing the buffer to the driver. Buffers can't be queued to the
driver before its fences signal. And a buffer can't be queue to the driver
out of the order they were queued from userspace. That means that even if
it fence signal it must wait all other buffers, ahead of it in the queue,
to signal first.
If the fence for some buffer fails we do not queue it to the driver,
instead we mark it as error and wait until the previous buffer is done
to notify userspace of the error. We wait here to deliver the buffers back
to userspace in order.
v7:
- get rid of the fence array stuff for ordering and just use
get_num_buffers_ready() (Hans)
- fix issue of queuing the buffer twice (Hans)
- avoid the dma_fence_wait() in core_qbuf() (Alex)
- merge preparation commit in
v6:
- With fences always keep the order userspace queues the buffers.
- Protect in_fence manipulation with a lock (Brian Starkey)
- check if fences have the same context before adding a fence array
- Fix last_fence ref unbalance in __set_in_fence() (Brian Starkey)
- Clean up fence if __set_in_fence() fails (Brian Starkey)
- treat -EINVAL from dma_fence_add_callback() (Brian Starkey)
v5: - use fence_array to keep buffers ordered in vb2 core when
needed (Brian Starkey)
- keep backward compat on the reserved2 field (Brian Starkey)
- protect fence callback removal with lock (Brian Starkey)
v4:
- Add a comment about dma_fence_add_callback() not returning a
error (Hans)
- Call dma_fence_put(vb->in_fence) if fence signaled (Hans)
- select SYNC_FILE under config VIDEOBUF2_CORE (Hans)
- Move dma_fence_is_signaled() check to __enqueue_in_driver() (Hans)
- Remove list_for_each_entry() in __vb2_core_qbuf() (Hans)
- Remove if (vb->state != VB2_BUF_STATE_QUEUED) from
vb2_start_streaming() (Hans)
- set IN_FENCE flags on __fill_v4l2_buffer (Hans)
- Queue buffers to the driver as soon as they are ready (Hans)
- call fill_user_buffer() after queuing the buffer (Hans)
- add err: label to clean up fence
- add dma_fence_wait() before calling vb2_start_streaming()
v3: - document fence parameter
- remove ternary if at vb2_qbuf() return (Mauro)
- do not change if conditions behaviour (Mauro)
v2:
- fix vb2_queue_or_prepare_buf() ret check
- remove check for VB2_MEMORY_DMABUF only (Javier)
- check num of ready buffers to start streaming
- when queueing, start from the first ready buffer
- handle queue cancel
Signed-off-by: Gustavo Padovan
---
drivers/media/v4l2-core/Kconfig | 1 +
drivers/media/v4l2-core/videobuf2-core.c | 154 +++
drivers/media/v4l2-core/videobuf2-v4l2.c | 29 +-
include/media/videobuf2-core.h | 14 ++-
4 files changed, 177 insertions(+), 21 deletions(-)
diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index a35c33686abf..3f988c407c80 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -83,6 +83,7 @@ config VIDEOBUF_DVB
# Used by drivers that need Videobuf2 modules
config VIDEOBUF2_CORE
select DMA_SHARED_BUFFER
+ select SYNC_FILE
tristate
config VIDEOBUF2_MEMOPS
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index a8589d96ef72..520aa3c7d9f0 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -346,6 +346,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum
vb2_memory memory,
vb->index = q->num_buffers + buffer;
vb->type = q->type;
vb->memory = memory;
+ spin_lock_init(&vb->fence_cb_lock);
for (plane = 0; plane < num_planes; ++plane) {
vb->planes[plane].length = plane_sizes[plane];
vb->planes[plane].min_length = plane_sizes[plane];
@@ -928,7 +929,7 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
vb2_buffer_state state)
switch (state) {
case VB2_BUF_STATE_QUEUED:
- return;
+ break;
case VB2_BUF_STATE_REQUEUEING:
if (q->start_streaming_called)
__enqueue_in_driver(vb);
@@ -938,6 +939,16 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
vb2_buffer_state state)
wake_up(&q->done_wq);
break;
}
+
+ /*
+* If the in-fence fails the buffer is not queued to the driver
+* and we have to wait until the previous buffer is done before
+* we notify userspace that the buffer with error can be dequeued.
+* That way we maintain the ordering from u
[PATCH v6 2/6] [media] v4l: add 'unordered' flag to format description ioctl
From: Gustavo Padovan
For explicit synchronization it important for userspace to know if the
format being used by the driver can deliver the buffers back to userspace
in the same order they were queued with QBUF.
Ordered streams fits nicely in a pipeline with DRM for example, where
ordered buffer are expected.
Signed-off-by: Gustavo Padovan
---
Documentation/media/uapi/v4l/vidioc-enum-fmt.rst | 3 +++
include/uapi/linux/videodev2.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
b/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
index 019c513df217..368115f44fc0 100644
--- a/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
+++ b/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
@@ -116,6 +116,9 @@ one until ``EINVAL`` is returned.
- This format is not native to the device but emulated through
software (usually libv4l2), where possible try to use a native
format instead for better performance.
+* - ``V4L2_FMT_FLAG_UNORDERED``
+ - 0x0004
+ - This is a format that doesn't guarantee timely order of frames.
Return Value
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 1c095b5a99c5..a8ea632c14f0 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -709,6 +709,7 @@ struct v4l2_fmtdesc {
#define V4L2_FMT_FLAG_COMPRESSED 0x0001
#define V4L2_FMT_FLAG_EMULATED 0x0002
+#define V4L2_FMT_FLAG_UNORDERED 0x0004
/* Frame Size and frame rate enumeration */
/*
--
2.13.6
Re: [PATCH v2 08/26] media: v4l2-async: shut up an unitialized symbol warning
Em Thu, 02 Nov 2017 04:51:40 +0200
Laurent Pinchart escreveu:
> Hi Mauro,
>
> Thank you for the patch.
>
> On Wednesday, 1 November 2017 23:05:45 EET Mauro Carvalho Chehab wrote:
> > Smatch reports this warning:
> > drivers/media/v4l2-core/v4l2-async.c:597 v4l2_async_register_subdev()
> > error: uninitialized symbol 'ret'.
> >
> > However, there's nothing wrong there. So, just shut up the
> > warning.
>
> Nothing wrong, really ? ret does seem to be used uninitialized when the
> function returns at the very last line.
There's nothing wrong. If you follow the logic, you'll see that
the line:
return ret;
is called only at "err_unbind" label, with is called only on
two places:
ret = v4l2_async_match_notify(notifier, v4l2_dev, sd, asd);
if (ret)
goto err_unbind;
ret = v4l2_async_notifier_try_complete(notifier);
if (ret)
goto err_unbind;
There, ret is defined.
Yeah, the logic there is confusing.
Thanks,
Mauro
media: v4l2-async: shut up an unitialized symbol warning
Smatch reports this warning:
drivers/media/v4l2-core/v4l2-async.c:597 v4l2_async_register_subdev()
error: uninitialized symbol 'ret'.
However, there's nothing wrong there. Yet, the logic is more
complex than it should. So, rework it to make clearer about
what happens when ret != 0.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/v4l2-core/v4l2-async.c | 38 +++
1 file changed, 17 insertions(+), 21 deletions(-)
--- patchwork.orig/drivers/media/v4l2-core/v4l2-async.c
+++ patchwork/drivers/media/v4l2-core/v4l2-async.c
@@ -532,7 +532,7 @@ int v4l2_async_register_subdev(struct v4
{
struct v4l2_async_notifier *subdev_notifier;
struct v4l2_async_notifier *notifier;
- int ret;
+ int ret = 0;
/*
* No reference taken. The reference is held by the device
@@ -560,11 +560,11 @@ int v4l2_async_register_subdev(struct v4
ret = v4l2_async_match_notify(notifier, v4l2_dev, sd, asd);
if (ret)
- goto err_unbind;
+ break;
ret = v4l2_async_notifier_try_complete(notifier);
if (ret)
- goto err_unbind;
+ break;
goto out_unlock;
}
@@ -572,26 +572,22 @@ int v4l2_async_register_subdev(struct v4
/* None matched, wait for hot-plugging */
list_add(&sd->async_list, &subdev_list);
-out_unlock:
- mutex_unlock(&list_lock);
-
- return 0;
-
-err_unbind:
- /*
-* Complete failed. Unbind the sub-devices bound through registering
-* this async sub-device.
-*/
- subdev_notifier = v4l2_async_find_subdev_notifier(sd);
- if (subdev_notifier)
- v4l2_async_notifier_unbind_all_subdevs(subdev_notifier);
-
- if (sd->asd)
- v4l2_async_notifier_call_unbind(notifier, sd, sd->asd);
- v4l2_async_cleanup(sd);
+ if (ret) {
+ /*
+* Complete failed. Unbind the sub-devices bound through
registering
+* this async sub-device.
+*/
+ subdev_notifier = v4l2_async_find_subdev_notifier(sd);
+ if (subdev_notifier)
+ v4l2_async_notifier_unbind_all_subdevs(subdev_notifier);
+
+ if (sd->asd)
+ v4l2_async_notifier_call_unbind(notifier, sd, sd->asd);
+ v4l2_async_cleanup(sd);
+ }
+out_unlock:
mutex_unlock(&list_lock);
-
return ret;
}
EXPORT_SYMBOL(v4l2_async_register_subdev);
Re: [PATCH v12 1/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation
Hi Niklas,
Thank you for the patch.
On Wednesday, 29 November 2017 21:32:34 EET Niklas Söderlund wrote:
> Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers
> are located between the video sources (CSI-2 transmitters) and the video
> grabbers (VIN) on Gen3 of Renesas R-Car SoC.
>
> Each CSI-2 device is connected to more then one VIN device which
s/then/than/
> simultaneously can receive video from the same CSI-2 device. Each VIN
> device can also be connected to more then one CSI-2 device. The routing
s/then/than/
> of which link are used are controlled by the VIN devices. There are only
s/link are/links are/ or s/link are/link is/
s/are controlled/is controlled/
> a few possible routes which are set by hardware limitations, which are
> different for each SoC in the Gen3 family.
>
> To work with the limitations of routing possibilities it is necessary
> for the DT bindings to describe which VIN device is connected to which
> CSI-2 device. This is why port 1 needs to to assign reg numbers for each
> VIN device that be connected to it. To setup and to know which links are
s/that be/that is/
> valid for each SoC is the responsibility of the VIN driver since the
> register to configure it belongs to the VIN hardware.
>
> Signed-off-by: Niklas Söderlund
> Acked-by: Rob Herring
> ---
> .../bindings/media/renesas,rcar-csi2.txt | 105 ++
> MAINTAINERS| 1 +
> 2 files changed, 106 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
>
> diff --git a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
> b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt new file
> mode 100644
> index ..688afd83bf66f8cf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
> @@ -0,0 +1,105 @@
> +Renesas R-Car MIPI CSI-2
> +
> +
> +The rcar-csi2 device provides MIPI CSI-2 capabilities for the Renesas R-Car
rcar-csi2 is the name of the driver, I would call it the "R-Car CSI-2 receiver
device" (or s/device/IP core/).
> +family of devices. It is to be used in conjunction with the R-Car VIN
> module,
The IP core itself doesn't have to be used with the VIN, but in R-Car SoCs it
is, so I would phrase it as "It is used ...".
> +which provides the video capture capabilities.
> +
> +Mandatory properties
> +
> + - compatible: Must be one or more of the following
> + - "renesas,r8a7795-csi2" for the R8A7795 device.
> + - "renesas,r8a7796-csi2" for the R8A7796 device.
> +
> + - reg: the register base and size for the device registers
> + - interrupts: the interrupt for the device
> + - clocks: Reference to the parent clock
Either capitalize the first word after the colon or don't, but please don't
mix them :-)
> +
> +The device node shall contain two 'port' child nodes according to the
> +bindings defined in Documentation/devicetree/bindings/media/
> +video-interfaces.txt. Port 0 shall connect the node that is the video
> +source for to the CSI-2.
Or simply "Port 0 shall connect to the CSI-2 source." ?
> Port 1 shall connect all the R-Car VIN
> +modules, which can make use of the CSI-2 module.
And to be a bit more explicit, how about "Port 1 shall connect to all the R-
Car VIN modules that have a hardware connection to the CSI-2 receiver." ?
> +
> +- Port 0 - Video source (Mandatory)
Nitpicking, I don't think you need to capitalize Mandatory.
> + - Endpoint 0 - sub-node describing the endpoint that is the video source
> +
> +- Port 1 - VIN instances (Mandatory for all VIN present in the SoC)
> + - Endpoint 0 - sub-node describing the endpoint that is VIN0
> + - Endpoint 1 - sub-node describing the endpoint that is VIN1
> + - Endpoint 2 - sub-node describing the endpoint that is VIN2
> + - Endpoint 3 - sub-node describing the endpoint that is VIN3
> + - Endpoint 4 - sub-node describing the endpoint that is VIN4
> + - Endpoint 5 - sub-node describing the endpoint that is VIN5
> + - Endpoint 6 - sub-node describing the endpoint that is VIN6
> + - Endpoint 7 - sub-node describing the endpoint that is VIN7
Should we clarify that only a subset of those endpoints shall be present when
the CSI-2 receiver isn't connected to all VIN instances ?
Furthermore, as explained in a comment I made when reviewing the VIN patch
series, I wonder whether we shouldn't identify the CSI-2 receiver instances by
ID the same way we do with the VIN instances (using the renesas,id property).
In that case I think the endpoint numbering won't matter.
> +Example:
> +
> + csi20: csi2@fea8 {
> + compatible = "renesas,r8a7796-csi2";
> + reg = <0 0xfea8 0 0x1>;
> + interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 714>;
> + power-domains = <&sysc R8A7796_PD_ALWAYS_
[PATCH v10 1/4] dt-bindings: media: Document Synopsys DesignWare HDMI RX
Document the bindings for the Synopsys DesignWare HDMI RX.
Signed-off-by: Jose Abreu
Acked-by: Rob Herring (v8)
Cc: Joao Pinto
Cc: Rob Herring
Cc: Mark Rutland
Cc: Mauro Carvalho Chehab
Cc: Hans Verkuil
Cc: Sylwester Nawrocki
Cc: devicet...@vger.kernel.org
---
Changes from v7:
- Remove SoC specific bindings (Rob)
Changes from v6:
- Document which properties are required/optional (Sylwester)
- Drop compatible string for SoC (Sylwester)
- Reword edid-phandle property (Sylwester)
- Typo fixes (Sylwester)
Changes from v4:
- Use "cfg" instead of "cfg-clk" (Rob)
- Change node names (Rob)
Changes from v3:
- Document the new DT bindings suggested by Sylwester
Changes from v2:
- Document edid-phandle property
---
.../devicetree/bindings/media/snps,dw-hdmi-rx.txt | 58 ++
1 file changed, 58 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
diff --git a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
new file mode 100644
index 000..1dc09c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
@@ -0,0 +1,58 @@
+Synopsys DesignWare HDMI RX Decoder
+===
+
+This document defines device tree properties for the Synopsys DesignWare HDMI
+RX Decoder (DWC HDMI RX).
+
+The properties bellow belong to the Synopsys DesignWare HDMI RX Decoder node.
+
+Required properties:
+
+- compatible: Shall be "snps,dw-hdmi-rx".
+- reg: Memory mapped base address and length of the DWC HDMI RX registers.
+- interrupts: Reference to the DWC HDMI RX interrupt and the HDMI 5V sense
+interrupt.
+- clocks: Reference to the config clock.
+- clock-names: Shall be "cfg".
+- #address-cells: Shall be 1.
+- #size-cells: Shall be 0.
+
+Optional properties:
+
+- edid-phandle: Reference to the EDID handler block; if this property is not
+specified it is assumed that EDID is handled by device described by parent
+node of the HDMI RX node. You should not specify this property if your HDMI RX
+controller does not have CEC.
+
+You also have to create a subnode for the PHY device. PHY node properties are
+as follows.
+
+Required properties:
+
+- compatible: Shall be "snps,dw-hdmi-phy-e405".
+- reg: Shall be the JTAG address of the PHY.
+- clocks: Reference to the config clock.
+- clock-names: Shall be "cfg".
+
+Example:
+
+hdmi_rx: hdmi-rx@0 {
+ compatible = "snps,dw-hdmi-rx";
+ reg = <0x0 0x1>;
+ interrupts = <1 2>;
+ edid-phandle = <&dw_hdmi_edid>;
+
+ clocks = <&dw_hdmi_refclk>;
+ clock-names = "cfg";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi-phy@fc {
+ compatible = "snps,dw-hdmi-phy-e405";
+ reg = <0xfc>;
+
+ clocks = <&dw_hdmi_refclk>;
+ clock-names = "cfg";
+ };
+};
--
1.9.1
[PATCH v10 4/4] [media] platform: Add Synopsys DesignWare HDMI RX Controller Driver
This is an initial submission for the Synopsys DesignWare HDMI RX Controller Driver. This driver interacts with a phy driver so that a communication between them is created and a video pipeline is configured. The controller + phy pipeline can then be integrated into a fully featured system that can be able to receive video up to 4k@60Hz with deep color 48bit RGB, depending on the platform. Although, this initial version does not yet handle deep color modes. This driver was implemented as a standard V4L2 subdevice and its main features are: - Internal state machine that reconfigures phy until the video is not stable - JTAG communication with phy - Inter-module communication with phy driver - Debug write/read ioctls Some notes: - RX sense controller (cable connection/disconnection) must be handled by the platform wrapper as this is not integrated into the controller RTL - The same goes for EDID ROM's - ZCAL calibration is needed only in FPGA platforms, in ASIC this is not needed - The state machine is not an ideal solution as it creates a kthread but it is needed because some sources might not be very stable at sending the video (i.e. we must react accordingly). Signed-off-by: Jose Abreu Cc: Joao Pinto Cc: Mauro Carvalho Chehab Cc: Hans Verkuil Cc: Sylwester Nawrocki Cc: Sakari Ailus Cc: Philippe Ombredanne --- Changes from v9: - Use SPDX License ID (Philippe) - Use LOW_DRIVE CEC error (Hans) - Fill bt->il_* fields (Hans) - Fix format->field to NONE (Hans) - Drop a left-over comment (Hans) - Use CEC_CAP_DEFAULTS (Hans) Changes from v8: - Incorporate Sakari's work on ASYNC subdevs Changes from v6: - edid-phandle now also looks for parent node (Sylwester) - Fix kbuild build warnings Changes from v5: - Removed HDCP 1.4 support (Hans) - Removed some CEC debug messages (Hans) - Add s_dv_timings callback (Hans) - Add V4L2_CID_DV_RX_POWER_PRESENT ctrl (Hans) Changes from v4: - Add flag V4L2_SUBDEV_FL_HAS_DEVNODE (Sylwester) - Remove some comments and change some messages to dev_dbg (Sylwester) - Use v4l2_async_subnotifier_register() (Sylwester) Changes from v3: - Use v4l2 async API (Sylwester) - Do not block waiting for phy - Do not use busy waiting delays (Sylwester) - Simplify dw_hdmi_power_on (Sylwester) - Use clock API (Sylwester) - Use compatible string (Sylwester) - Minor fixes (Sylwester) Changes from v2: - Address review comments from Hans regarding CEC - Use CEC notifier - Enable SCDC Changes from v1: - Add support for CEC - Correct typo errors - Correctly detect interlaced video modes - Correct VIC parsing Changes from RFC: - Add support for HDCP 1.4 - Fixup HDMI_VIC not being parsed (Hans) - Send source change signal when powering off (Hans) - Add a "wait stable delay" - Detect interlaced video modes (Hans) - Restrain g/s_register from reading/writing to HDCP regs (Hans) --- drivers/media/platform/dwc/Kconfig | 15 + drivers/media/platform/dwc/Makefile |1 + drivers/media/platform/dwc/dw-hdmi-rx.c | 1840 +++ drivers/media/platform/dwc/dw-hdmi-rx.h | 419 +++ include/media/dwc/dw-hdmi-rx-pdata.h| 48 + 5 files changed, 2323 insertions(+) create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.c create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.h create mode 100644 include/media/dwc/dw-hdmi-rx-pdata.h diff --git a/drivers/media/platform/dwc/Kconfig b/drivers/media/platform/dwc/Kconfig index 361d38d..3ddccde 100644 --- a/drivers/media/platform/dwc/Kconfig +++ b/drivers/media/platform/dwc/Kconfig @@ -6,3 +6,18 @@ config VIDEO_DWC_HDMI_PHY_E405 To compile this driver as a module, choose M here. The module will be called dw-hdmi-phy-e405. + +config VIDEO_DWC_HDMI_RX + tristate "Synopsys Designware HDMI Receiver driver" + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API + help + Support for Synopsys Designware HDMI RX controller. + + To compile this driver as a module, choose M here. The module + will be called dw-hdmi-rx. + +config VIDEO_DWC_HDMI_RX_CEC + bool + depends on VIDEO_DWC_HDMI_RX + select CEC_CORE + select CEC_NOTIFIER diff --git a/drivers/media/platform/dwc/Makefile b/drivers/media/platform/dwc/Makefile index fc3b62c..cd04ca9 100644 --- a/drivers/media/platform/dwc/Makefile +++ b/drivers/media/platform/dwc/Makefile @@ -1 +1,2 @@ obj-$(CONFIG_VIDEO_DWC_HDMI_PHY_E405) += dw-hdmi-phy-e405.o +obj-$(CONFIG_VIDEO_DWC_HDMI_RX) += dw-hdmi-rx.o diff --git a/drivers/media/platform/dwc/dw-hdmi-rx.c b/drivers/media/platform/dwc/dw-hdmi-rx.c new
[PATCH v10 3/4] [media] platform: Add Synopsys DesignWare HDMI RX PHY e405 Driver
This adds support for the Synopsys DesignWare HDMI RX PHY e405. This
phy receives and decodes HDMI video that is delivered to a controller.
Main features included in this driver are:
- Equalizer algorithm that chooses the phy best settings
according to the detected HDMI cable characteristics.
- Support for scrambling
- Support for HDMI 2.0 modes up to 6G (HDMI 4k@60Hz).
The driver was implemented as a standalone V4L2 subdevice and the
phy interface with the controller was implemented using V4L2 ioctls. I
do not know if this is the best option but it is not possible to use the
existing API functions directly as we need specific functions that will
be called by the controller at specific configuration stages.
There is also a bidirectional communication between controller and phy:
The phy must provide functions that the controller will call (i.e.
configuration functions) and the controller must provide read/write
callbacks, as well as other specific functions.
Signed-off-by: Jose Abreu
Cc: Joao Pinto
Cc: Mauro Carvalho Chehab
Cc: Hans Verkuil
Cc: Sylwester Nawrocki
Cc: Philippe Ombredanne
---
Changes from v9:
- Use SPDX License ID (Philippe)
Changes from v4:
- Use usleep_range (Sylwester)
- Remove some comments (Sylwester)
- Parse phy version from of_device_id (Sylwester)
- Use "cfg" instead of "cfg-clk" (Sylwester, Rob)
- Change some messages to dev_dbg (Sylwester)
Changes from v3:
- Use v4l2 async API (Sylwester)
- Use clock API (Sylwester)
- Add compatible string (Sylwester)
Changes from RFC:
- Remove a bunch of functions that can be collapsed into
a single config() function
- Add comments for the callbacks and structures (Hans)
---
drivers/media/platform/Kconfig| 2 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/dwc/Kconfig| 8 +
drivers/media/platform/dwc/Makefile | 1 +
drivers/media/platform/dwc/dw-hdmi-phy-e405.c | 822 ++
drivers/media/platform/dwc/dw-hdmi-phy-e405.h | 41 ++
include/media/dwc/dw-hdmi-phy-pdata.h | 106
7 files changed, 982 insertions(+)
create mode 100644 drivers/media/platform/dwc/Kconfig
create mode 100644 drivers/media/platform/dwc/Makefile
create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.c
create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.h
create mode 100644 include/media/dwc/dw-hdmi-phy-pdata.h
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index fd0c998..0187cbd 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -33,6 +33,8 @@ source "drivers/media/platform/omap/Kconfig"
source "drivers/media/platform/blackfin/Kconfig"
+source "drivers/media/platform/dwc/Kconfig"
+
config VIDEO_SH_VOU
tristate "SuperH VOU video output driver"
depends on MEDIA_CAMERA_SUPPORT
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 003b0bb..2e879c6 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -97,3 +97,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS)+=
qcom/camss-8x16/
obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
obj-y += meson/
+
+obj-y += dwc/
diff --git a/drivers/media/platform/dwc/Kconfig
b/drivers/media/platform/dwc/Kconfig
new file mode 100644
index 000..361d38d
--- /dev/null
+++ b/drivers/media/platform/dwc/Kconfig
@@ -0,0 +1,8 @@
+config VIDEO_DWC_HDMI_PHY_E405
+ tristate "Synopsys Designware HDMI RX PHY e405 driver"
+ depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ help
+ Support for Synopsys Designware HDMI RX PHY. Version is e405.
+
+ To compile this driver as a module, choose M here. The module
+ will be called dw-hdmi-phy-e405.
diff --git a/drivers/media/platform/dwc/Makefile
b/drivers/media/platform/dwc/Makefile
new file mode 100644
index 000..fc3b62c
--- /dev/null
+++ b/drivers/media/platform/dwc/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_DWC_HDMI_PHY_E405) += dw-hdmi-phy-e405.o
diff --git a/drivers/media/platform/dwc/dw-hdmi-phy-e405.c
b/drivers/media/platform/dwc/dw-hdmi-phy-e405.c
new file mode 100644
index 000..e781cc1
--- /dev/null
+++ b/drivers/media/platform/dwc/dw-hdmi-phy-e405.c
@@ -0,0 +1,822 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+// Copyright (c) 2017 Synopsys, Inc. and/or its affiliates.
+// Synopsys DesignWare HDMI PHY e405 driver
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "dw-hdmi-phy-e405.h"
+
+MODULE_AUTHOR("Jose Abreu ");
+MODULE_DESCRIPTION("Designware HDMI PHY e405 driver");
+MODULE_LICENSE("Dual MIT/GPL");
+
+#define PHY_EQ_WAIT_TIME_START 3
+#define PHY_EQ_SLEEP_TIME_CDR 30
+#de
[PATCH v10 2/4] MAINTAINERS: Add entry for Synopsys DesignWare HDMI drivers
Add an entry for Synopsys DesignWare HDMI Receivers drivers and phys. Signed-off-by: Jose Abreu Cc: Joao Pinto --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7a52a66..a1675bc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13108,6 +13108,13 @@ L: net...@vger.kernel.org S: Supported F: drivers/net/ethernet/synopsys/ +SYNOPSYS DESIGNWARE HDMI RECEIVERS AND PHY DRIVERS +M: Jose Abreu +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/media/platform/dwc/* +F: include/media/dwc/* + SYNOPSYS DESIGNWARE I2C DRIVER M: Jarkko Nikula R: Andy Shevchenko -- 1.9.1
[PATCH v10 0/4] Synopsys DesignWare HDMI Video Capture Controller + PHY
The Synopsys DesignWare HDMI RX controller is an HDMI receiver controller that is responsible to process digital data that comes from a phy. The final result is a stream of RAW video data that can then be connected to a video DMA, for example, and transfered into RAM so that it can be displayed. The controller + phy available in this series natively support all HDMI 1.4 and HDMI 2.0 modes, including deep color. Although, the driver is quite in its initial stage and unfortunatelly only non deep color modes are supported. Also, audio is not yet supported in the driver (the controller has several audio output interfaces). Version 10 addresses review comments from Hans Verkuil and from Philippe Ombredanne. This series was tested in a FPGA platform using an embedded platform called ARC AXS101. Jose Abreu (4): dt-bindings: media: Document Synopsys DesignWare HDMI RX MAINTAINERS: Add entry for Synopsys DesignWare HDMI drivers [media] platform: Add Synopsys DesignWare HDMI RX PHY e405 Driver [media] platform: Add Synopsys DesignWare HDMI RX Controller Driver .../devicetree/bindings/media/snps,dw-hdmi-rx.txt | 58 + MAINTAINERS|7 + drivers/media/platform/Kconfig |2 + drivers/media/platform/Makefile|2 + drivers/media/platform/dwc/Kconfig | 23 + drivers/media/platform/dwc/Makefile|2 + drivers/media/platform/dwc/dw-hdmi-phy-e405.c | 822 + drivers/media/platform/dwc/dw-hdmi-phy-e405.h | 41 + drivers/media/platform/dwc/dw-hdmi-rx.c| 1840 drivers/media/platform/dwc/dw-hdmi-rx.h| 419 + include/media/dwc/dw-hdmi-phy-pdata.h | 106 ++ include/media/dwc/dw-hdmi-rx-pdata.h | 48 + 12 files changed, 3370 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt create mode 100644 drivers/media/platform/dwc/Kconfig create mode 100644 drivers/media/platform/dwc/Makefile create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.c create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.h create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.c create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.h create mode 100644 include/media/dwc/dw-hdmi-phy-pdata.h create mode 100644 include/media/dwc/dw-hdmi-rx-pdata.h -- 1.9.1
[PATCH] staging: atomisp2: replace DEVICE_ATTR with DEVICE_ATTR_RO
This is a clean-up patch which replaces DEVICE_ATTR() macro with file
permission specific DEVICE_ATTR_RO() macro for compaction and
readability.
Done using coccinelle:
@r@
identifier attr, show_fn;
declarer name DEVICE_ATTR;
@@
DEVICE_ATTR(attr, \(S_IRUGO\|0444\), show_fn, NULL);
@script: python p@
attr_show;
attr << r.attr;
@@
// standardise the show fn name to {attr}_show
coccinelle.attr_show = attr + "_show"
@@
identifier r.attr, r.show_fn;
declarer name DEVICE_ATTR_RO;
@@
// change the attr declaration
- DEVICE_ATTR(attr, \(S_IRUGO\|0444\), show_fn, NULL);
+ DEVICE_ATTR_RO(attr);
@rr@
identifier r.show_fn, p.attr_show;
@@
// rename the show function
- show_fn
+ attr_show
(...) {
...
}
@depends on rr@
identifier r.show_fn, p.attr_show;
@@
// rename fn usages
- show_fun
+ attr_show
Signed-off-by: Aishwarya Pant
---
drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
index a1c81c12718c..4338b8a1309f 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
@@ -158,10 +158,10 @@ static ssize_t dynamic_pool_show(struct device *dev,
return ret;
};
-static DEVICE_ATTR(active_bo, 0444, active_bo_show, NULL);
-static DEVICE_ATTR(free_bo, 0444, free_bo_show, NULL);
-static DEVICE_ATTR(reserved_pool, 0444, reserved_pool_show, NULL);
-static DEVICE_ATTR(dynamic_pool, 0444, dynamic_pool_show, NULL);
+static DEVICE_ATTR_RO(active_bo);
+static DEVICE_ATTR_RO(free_bo);
+static DEVICE_ATTR_RO(reserved_pool);
+static DEVICE_ATTR_RO(dynamic_pool);
static struct attribute *sysfs_attrs_ctrl[] = {
&dev_attr_active_bo.attr,
--
2.15.1
[PATCH] media: ddbridge: shut up a new warning
drivers/media/pci/ddbridge/ddbridge-ci.c:321:5: warning: no previous prototype for 'ddb_ci_attach' [-Wmissing-prototypes] int ddb_ci_attach(struct ddb_port *port, u32 bitrate) ^ Signed-off-by: Mauro Carvalho Chehab --- drivers/media/pci/ddbridge/ddbridge-ci.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/pci/ddbridge/ddbridge-ci.c b/drivers/media/pci/ddbridge/ddbridge-ci.c index 457c711aaced..a4fd747763a0 100644 --- a/drivers/media/pci/ddbridge/ddbridge-ci.c +++ b/drivers/media/pci/ddbridge/ddbridge-ci.c @@ -20,6 +20,7 @@ #include "ddbridge.h" #include "ddbridge-regs.h" +#include "ddbridge-ci.h" #include "ddbridge-io.h" #include "ddbridge-i2c.h" -- 2.14.3
Re: [PATCH] media: pxa_camera: disable and unprepare the clock source on error
Hi Flavio, Thank you for the patch. On Wednesday, 6 December 2017 18:38:50 EET Flavio Ceolin wrote: > pxa_camera_probe() was not calling pxa_camera_deactivate(), > responsible to call clk_disable_unprepare(), on the failure path. This > was leading to unbalancing source clock. > > Found by Linux Driver Verification project (linuxtesting.org). Any chance I could sign you up for more work on this driver ? :-) > Signed-off-by: Flavio Ceolin Reviewed-by: Laurent Pinchart I expect Hans Verkuil to pick up the patch. > --- > drivers/media/platform/pxa_camera.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/media/platform/pxa_camera.c > b/drivers/media/platform/pxa_camera.c index 9d3f0cb..7877037 100644 > --- a/drivers/media/platform/pxa_camera.c > +++ b/drivers/media/platform/pxa_camera.c > @@ -2489,7 +2489,7 @@ static int pxa_camera_probe(struct platform_device > *pdev) dev_set_drvdata(&pdev->dev, pcdev); > err = v4l2_device_register(&pdev->dev, &pcdev->v4l2_dev); > if (err) > - goto exit_free_dma; > + goto exit_deactivate; > > pcdev->asds[0] = &pcdev->asd; > pcdev->notifier.subdevs = pcdev->asds; > @@ -2525,6 +2525,8 @@ static int pxa_camera_probe(struct platform_device > *pdev) v4l2_clk_unregister(pcdev->mclk_clk); > exit_free_v4l2dev: > v4l2_device_unregister(&pcdev->v4l2_dev); > +exit_deactivate: > + pxa_camera_deactivate(pcdev); > exit_free_dma: > dma_release_channel(pcdev->dma_chans[2]); > exit_free_dma_u: -- Regards, Laurent Pinchart
Re: [PATCH v3 07/12] dt-bindings: Document the Rockchip MIPI RX D-PHY bindings
Hello Jacob,
Thank you for the patch.
On Wednesday, 6 December 2017 13:19:34 EET Jacob Chen wrote:
> From: Jacob Chen
>
> Add DT bindings documentation for Rockchip MIPI D-PHY RX
>
> Signed-off-by: Jacob Chen
> ---
> .../bindings/media/rockchip-mipi-dphy.txt | 71 +++
> 1 file changed, 71 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/media/rockchip-mipi-dphy.txt
>
> diff --git a/Documentation/devicetree/bindings/media/rockchip-mipi-dphy.txt
> b/Documentation/devicetree/bindings/media/rockchip-mipi-dphy.txt new file
> mode 100644
> index ..cef9450db051
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/rockchip-mipi-dphy.txt
> @@ -0,0 +1,71 @@
> +Rockchip SoC MIPI RX D-PHY
> +-
> +
> +Required properties:
> +
> +- compatible: value should be one of the following
> +"rockchip,rk3288-mipi-dphy";
> +"rockchip,rk3399-mipi-dphy";
> +- rockchip,grf: GRF regs.
> +- bus-width : maximum number of data lanes supported (SoC specific);
Bus width isn't a standard property, should this be rockchip,data-lanes or
rockchip,#data-lanes ?
> +- clocks : list of clock specifiers, corresponding to entries in
> + clock-names property;
> +- clock-names: required clock name.
> +
> +The device node should contain two 'port' child node, according to the
s/child node/child nodes/
> bindings
> +defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
> +The first port should be connected to sensor nodes, and the second port
> should be
> +connected to isp node. The following are properties specific to those
> nodes.
> +
> +endpoint node
> +-
> +
> +- data-lanes : (required) an array specifying active physical MIPI-CSI2
> + data input lanes and their mapping to logical lanes; the
> + array's content is unused, only its length is meaningful;
I assume this means that the D-PHY can't reroute lanes. I would mention that
explicitly, and require that the data-lanes values start at one at are
consecutive instead of ignoring them.
> +Device node example
> +---
> +
> +mipi_dphy_rx0: mipi-dphy-rx0 {
> +compatible = "rockchip,rk3399-mipi-dphy";
> +clocks = <&cru SCLK_MIPIDPHY_REF>,
> +<&cru SCLK_DPHY_RX0_CFG>,
> +<&cru PCLK_VIO_GRF>;
> +clock-names = "dphy-ref", "dphy-cfg", "grf";
> +power-domains = <&power RK3399_PD_VIO>;
> +bus-width = <4>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +mipi_in_wcam: endpoint@0 {
> +reg = <0>;
> +remote-endpoint = <&wcam_out>;
> +data-lanes = <1 2>;
> +};
> +mipi_in_ucam: endpoint@1 {
> +reg = <1>;
> +remote-endpoint = <&ucam_out>;
> +data-lanes = <1>;
> +};
What do those two camera correspond to ? Can they be active at the same time,
or do they use the same data lanes ? If they use the same data lanes, how does
this work, is there a multiplexer on the board ?
> +};
> +
> +port@1 {
> +reg = <1>;
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +dphy_rx0_out: endpoint@0 {
> +reg = <0>;
> +remote-endpoint = <&isp0_mipi_in>;
> +};
> +};
> +};
> +};
> \ No newline at end of file
--
Regards,
Laurent Pinchart
Re: [PATCH]media: dvb-frontends: Add delay to Si2168 restart
Em Tue, 10 Oct 2017 18:13:30 -0700 Ron Economos escreveu: > On faster CPUs a delay is required after the POWER_UP/RESUME command and > the DD_RESTART command. Without the delay, the DD_RESTART command often > returns -EREMOTEIO and the Si2168 does not restart. You forgot to add your signed-off-by after the patch description. That's required for all patches that will be applied. See: https://linuxtv.org/wiki/index.php/Development:_Submitting_Patches#Sign_your_work > > diff --git a/drivers/media/dvb-frontends/si2168.c > b/drivers/media/dvb-frontends/si2168.c > index 172fc36..f2a3c8f 100644 > --- a/drivers/media/dvb-frontends/si2168.c > +++ b/drivers/media/dvb-frontends/si2168.c > @@ -15,6 +15,7 @@ > */ > > #include "si2168_priv.h" > +#include > > static const struct dvb_frontend_ops si2168_ops; > > @@ -435,6 +436,7 @@ static int si2168_init(struct dvb_frontend *fe) > if (ret) > goto err; > > + udelay(100); Your emailer is mangling your patches, replacing tabs by spaces and breaking long lines. Please either use git send-email or use some other email software, like claws-mail, pine or exim. > memcpy(cmd.args, "\x85", 1); > cmd.wlen = 1; > cmd.rlen = 1; > Thanks, Mauro
[PATCH 3/3] media: dvb-core: allow users to enable DVB net ULE debug
This debug option is there for a long time, but it is only
enabled by editing the source code. Due to that, a breakage
inside its code was only noticed years after a change at
the ULE handling logic.
Make it a Kconfig parameter, as it makes easier for
advanced users to enable, and allow test if the compilation
won't be broken in the future.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-core/Kconfig | 13 +
drivers/media/dvb-core/dvb_net.c | 14 +-
2 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/media/dvb-core/Kconfig b/drivers/media/dvb-core/Kconfig
index eeef94a0c84e..f004aea352e0 100644
--- a/drivers/media/dvb-core/Kconfig
+++ b/drivers/media/dvb-core/Kconfig
@@ -40,3 +40,16 @@ config DVB_DEMUX_SECTION_LOSS_LOG
be very verbose.
If you are unsure about this, say N here.
+
+config DVB_ULE_DEBUG
+ bool "Enable DVB net ULE packet debug messages"
+ depends on DVB_CORE
+ default n
+ help
+ Enable extra log messages meant to detect problems while
+ handling DVB network ULE packet loss inside the Kernel.
+
+ Should not be enabled on normal cases, as logs can
+ be very verbose.
+
+ If you are unsure about this, say N here.
diff --git a/drivers/media/dvb-core/dvb_net.c b/drivers/media/dvb-core/dvb_net.c
index bf0bea5c21c1..d8adc968cbf2 100644
--- a/drivers/media/dvb-core/dvb_net.c
+++ b/drivers/media/dvb-core/dvb_net.c
@@ -38,7 +38,7 @@
* Competence Center for Advanced Satellite
Communications.
* Bugfixes and robustness improvements.
* Filtering on dest MAC addresses, if present (D-Bit = 0)
- * ULE_DEBUG compile-time option.
+ * DVB_ULE_DEBUG compile-time option.
* Apr 2006: cp v3:Bugfixes and compliency with RFC 4326 (ULE) by
* Christian Praehauser ,
* Paris Lodron University of Salzburg.
@@ -78,12 +78,9 @@ static inline __u32 iov_crc32( __u32 c, struct kvec *iov,
unsigned int cnt )
#define DVB_NET_MULTICAST_MAX 10
-#undef ULE_DEBUG
-
-#ifdef ULE_DEBUG
-
+#ifdef DVB_ULE_DEBUG
/*
- * The code inside ULE_DEBUG keeps a history of the
+ * The code inside DVB_ULE_DEBUG keeps a history of the
* last 100 TS cells processed.
*/
static unsigned char ule_hist[100*TS_SZ] = { 0 };
@@ -93,7 +90,6 @@ static void hexdump(const unsigned char *buf, unsigned short
len)
{
print_hex_dump_debug("", DUMP_PREFIX_OFFSET, 16, 1, buf, len, true);
}
-
#endif
struct dvb_net_priv {
@@ -331,7 +327,7 @@ static int dvb_net_ule_new_ts_cell(struct
dvb_net_ule_handle *h)
{
/* We are about to process a new TS cell. */
-#ifdef ULE_DEBUG
+#ifdef DVB_ULE_DEBUG
if (ule_where >= &ule_hist[100*TS_SZ])
ule_where = ule_hist;
memcpy(ule_where, h->ts, TS_SZ);
@@ -669,7 +665,7 @@ static void dvb_net_ule_check_crc(struct dvb_net_ule_handle
*h, struct kvec iov[
h->ts_remain > 2 ?
*(unsigned short *)h->from_where : 0);
- #ifdef ULE_DEBUG
+ #ifdef DVB_ULE_DEBUG
hexdump(iov[0].iov_base, iov[0].iov_len);
hexdump(iov[1].iov_base, iov[1].iov_len);
hexdump(iov[2].iov_base, iov[2].iov_len);
--
2.14.3
[PATCH 2/3] media: dvb_net: let dynamic debug enable some DVB net handling
pr_debug() and netdev_dbg() can be enabled/disabled dynamically
via sysfs. So, stop hidding them under ULE_DEBUG config macro.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-core/dvb_net.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/media/dvb-core/dvb_net.c b/drivers/media/dvb-core/dvb_net.c
index bff5cd908df6..bf0bea5c21c1 100644
--- a/drivers/media/dvb-core/dvb_net.c
+++ b/drivers/media/dvb-core/dvb_net.c
@@ -287,11 +287,9 @@ static int handle_ule_extensions( struct dvb_net_priv *p )
if (l < 0)
return l; /* Stop extension header processing and
discard SNDU. */
total_ext_len += l;
-#ifdef ULE_DEBUG
pr_debug("ule_next_hdr=%p, ule_sndu_type=%i, l=%i,
total_ext_len=%i\n",
p->ule_next_hdr, (int)p->ule_sndu_type,
l, total_ext_len);
-#endif
} while (p->ule_sndu_type < ETH_P_802_3_MIN);
@@ -704,11 +702,9 @@ static void dvb_net_ule_check_crc(struct
dvb_net_ule_handle *h, struct kvec iov[
if (!h->priv->ule_dbit) {
if (dvb_net_ule_should_drop(h)) {
-#ifdef ULE_DEBUG
netdev_dbg(h->dev,
"Dropping SNDU: MAC destination address does
not match: dest addr: %pM, h->dev addr: %pM\n",
h->priv->ule_skb->data, h->dev->dev_addr);
-#endif
dev_kfree_skb(h->priv->ule_skb);
return;
}
--
2.14.3
[PATCH 1/3] media: dvb_net: ensure that dvb_net_ule_handle is fully initialized
changeset efb9ab67255f ("[media] dvb_net: prepare to split a very
complex function") changed the ULE handling logic, simplifying it.
However, it forgot to keep the initialization for .priv and to
zero .ule_hist fields.
The lack of .priv cause crashes if dvb_net_ule() is called, as
the function assuems that .priv field to be initialized.
With regards to .ule_hist, the current logic is broken and don't
even compile if ULE_DEBUG. Fix it by making the debug vars static
again, and be sure to pass iov parameter to dvb_net_ule_check_crc().
Fixes: efb9ab67255f ("[media] dvb_net: prepare to split a very complex
function")
Suggested-by: Ron Economos
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-core/dvb_net.c | 57 +++-
1 file changed, 27 insertions(+), 30 deletions(-)
diff --git a/drivers/media/dvb-core/dvb_net.c b/drivers/media/dvb-core/dvb_net.c
index c018e3c06d5d..bff5cd908df6 100644
--- a/drivers/media/dvb-core/dvb_net.c
+++ b/drivers/media/dvb-core/dvb_net.c
@@ -82,6 +82,13 @@ static inline __u32 iov_crc32( __u32 c, struct kvec *iov,
unsigned int cnt )
#ifdef ULE_DEBUG
+/*
+ * The code inside ULE_DEBUG keeps a history of the
+ * last 100 TS cells processed.
+ */
+static unsigned char ule_hist[100*TS_SZ] = { 0 };
+static unsigned char *ule_where = ule_hist, ule_dump;
+
static void hexdump(const unsigned char *buf, unsigned short len)
{
print_hex_dump_debug("", DUMP_PREFIX_OFFSET, 16, 1, buf, len, true);
@@ -320,14 +327,6 @@ struct dvb_net_ule_handle {
const u8 *ts, *ts_end, *from_where;
u8 ts_remain, how_much, new_ts;
bool error;
-#ifdef ULE_DEBUG
- /*
-* The code inside ULE_DEBUG keeps a history of the
-* last 100 TS cells processed.
-*/
- static unsigned char ule_hist[100*TS_SZ];
- static unsigned char *ule_where = ule_hist, ule_dump;
-#endif
};
static int dvb_net_ule_new_ts_cell(struct dvb_net_ule_handle *h)
@@ -335,14 +334,14 @@ static int dvb_net_ule_new_ts_cell(struct
dvb_net_ule_handle *h)
/* We are about to process a new TS cell. */
#ifdef ULE_DEBUG
- if (h->ule_where >= &h->ule_hist[100*TS_SZ])
- h->ule_where = h->ule_hist;
- memcpy(h->ule_where, h->ts, TS_SZ);
- if (h->ule_dump) {
- hexdump(h->ule_where, TS_SZ);
- h->ule_dump = 0;
+ if (ule_where >= &ule_hist[100*TS_SZ])
+ ule_where = ule_hist;
+ memcpy(ule_where, h->ts, TS_SZ);
+ if (ule_dump) {
+ hexdump(ule_where, TS_SZ);
+ ule_dump = 0;
}
- h->ule_where += TS_SZ;
+ ule_where += TS_SZ;
#endif
/*
@@ -659,7 +658,7 @@ static int dvb_net_ule_should_drop(struct
dvb_net_ule_handle *h)
}
-static void dvb_net_ule_check_crc(struct dvb_net_ule_handle *h,
+static void dvb_net_ule_check_crc(struct dvb_net_ule_handle *h, struct kvec
iov[3],
u32 ule_crc, u32 expected_crc)
{
u8 dest_addr[ETH_ALEN];
@@ -677,17 +676,17 @@ static void dvb_net_ule_check_crc(struct
dvb_net_ule_handle *h,
hexdump(iov[1].iov_base, iov[1].iov_len);
hexdump(iov[2].iov_base, iov[2].iov_len);
- if (h->ule_where == h->ule_hist) {
- hexdump(&h->ule_hist[98*TS_SZ], TS_SZ);
- hexdump(&h->ule_hist[99*TS_SZ], TS_SZ);
- } else if (h->ule_where == &h->ule_hist[TS_SZ]) {
- hexdump(&h->ule_hist[99*TS_SZ], TS_SZ);
- hexdump(h->ule_hist, TS_SZ);
+ if (ule_where == ule_hist) {
+ hexdump(&ule_hist[98*TS_SZ], TS_SZ);
+ hexdump(&ule_hist[99*TS_SZ], TS_SZ);
+ } else if (ule_where == &ule_hist[TS_SZ]) {
+ hexdump(&ule_hist[99*TS_SZ], TS_SZ);
+ hexdump(ule_hist, TS_SZ);
} else {
- hexdump(h->ule_where - TS_SZ - TS_SZ, TS_SZ);
- hexdump(h->ule_where - TS_SZ, TS_SZ);
+ hexdump(ule_where - TS_SZ - TS_SZ, TS_SZ);
+ hexdump(ule_where - TS_SZ, TS_SZ);
}
- h->ule_dump = 1;
+ ule_dump = 1;
#endif
h->dev->stats.rx_errors++;
@@ -779,6 +778,8 @@ static void dvb_net_ule(struct net_device *dev, const u8
*buf, size_t buf_len)
int ret;
struct dvb_net_ule_handle h = {
.dev = dev,
+ .priv = netdev_priv(dev),
+ .ethh = NULL,
.buf = buf,
.buf_len = buf_len,
.skipped = 0L,
@@ -788,11 +789,7 @@ static void dvb_net_ule(struct net_device *dev, const u8
*buf, size_t buf_len)
.ts_remain = 0,
.how_much = 0,
.new_ts = 1,
- .ethh = NULL,
.error = false,
-#ifdef ULE_DEBU
Re: [PATCH 1/2] usb: gadget: restore tristate-choice for legacy gadgets
On Mon, Dec 11, 2017 at 5:09 PM, Bart Van Assche wrote:
> On Mon, 2017-12-11 at 12:30 +0100, Arnd Bergmann wrote:
>> One patch that was meant as a cleanup apparently did more than it intended,
>> allowing all combinations of legacy gadget drivers to be built into the
>> kernel, and leaving an empty 'choice' statement behind:
>>
>> drivers/usb/gadget/Kconfig:487:warning: choice default symbol 'USB_ETH' is
>> not contained in the choice
>>
>> The description of commit 7a9618a22aad ("usb: gadget: allow to enable legacy
>> drivers without USB_ETH") was a bit cryptic, as it did not change the
>> behavior of USB_ETH other than allowing it to be built into the kernel
>> alongside other legacy gadgets, which is not a valid configuration.
>>
>> As Felipe explained in the description for commit bc49d1d17dcf ("usb:
>> gadget: don't couple configfs to legacy gadgets"), the configfs based
>> gadgets can be freely configured as loadable modules or built-in
>> drivers, but the legacy gadgets can only be modules if there is more
>> than one of them, so we require the 'choice' statement here.
>>
>> This leaves the added USB_GADGET_LEGACY menuconfig symbol in place,
>> but then restores the 'choice' below it, so we can enforce the
>> single-legacy-gadget rule as before.
>
> Hello Arnd,
>
> A discussion is ongoing about whether or not commit 7a9618a22aad should be
> reverted.
> Please drop this patch until a conclusion has been reached.
Ok. I'll use a revert of 7a9618a22aad in my local test tree then.
Reverting that is probably good, I thought about suggesting that
instead, but couldn't tell whether you had a bigger plan behind that
commit.
Arnd
Re: [PATCH v1 03/10] v4l: platform: Add Renesas CEU driver
Hi Jacopo,
Thank you for the patch.
On Wednesday, 15 November 2017 12:55:56 EET Jacopo Mondi wrote:
> Add driver for Renesas Capture Engine Unit (CEU).
>
> The CEU interface supports capturing 'data' (YUV422) and 'images'
> (NV[12|21|16|61]).
>
> This driver aims to replace the soc_camera based sh_mobile_ceu one.
s/soc_camera based/soc_camera-based/
> Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
> platform GR-Peach.
>
> Tested with ov7725 camera sensor on SH4 platform Migo-R.
>
> Signed-off-by: Jacopo Mondi
> ---
> drivers/media/platform/Kconfig |9 +
> drivers/media/platform/Makefile |2 +
> drivers/media/platform/renesas-ceu.c | 1768 +++
> 3 files changed, 1779 insertions(+)
> create mode 100644 drivers/media/platform/renesas-ceu.c
[snip]
> diff --git a/drivers/media/platform/renesas-ceu.c
> b/drivers/media/platform/renesas-ceu.c new file mode 100644
> index 000..aaba3cd
> --- /dev/null
> +++ b/drivers/media/platform/renesas-ceu.c
> @@ -0,0 +1,1768 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * V4L2 Driver for Renesas Capture Engine Unit (CEU) interface
> + *
> + * Copyright (C) 2017 Jacopo Mondi
> + *
> + * Based on soc-camera driver "soc_camera/sh_mobile_ceu_camera.c"
> + * Copyright (C) 2008 Magnus Damm
> + *
> + * Based on V4L2 Driver for PXA camera host - "pxa_camera.c",
> + * Copyright (C) 2006, Sascha Hauer, Pengutronix
> + * Copyright (C) 2008, Guennadi Liakhovetski
> + *
> + * 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.
You can use an SPDX header instead of a copyright text. Start the file with
// SPDX-License-Identifier: GPL-2.0+
and remove this paragraph.
> + */
[snip]
> +/* mbus configuration flags */
> +#define CEU_BUS_FLAGS (V4L2_MBUS_MASTER | \
> + V4L2_MBUS_PCLK_SAMPLE_RISING | \
> + V4L2_MBUS_HSYNC_ACTIVE_HIGH | \
> + V4L2_MBUS_HSYNC_ACTIVE_LOW | \
> + V4L2_MBUS_VSYNC_ACTIVE_HIGH | \
> + V4L2_MBUS_VSYNC_ACTIVE_LOW | \
> + V4L2_MBUS_DATA_ACTIVE_HIGH)
> +
> +#define CEU_MAX_WIDTH2560
> +#define CEU_MAX_HEIGHT 1920
> +#define CEU_W_MAX(w) ((w) < CEU_MAX_WIDTH ? (w) : CEU_MAX_WIDTH)
> +#define CEU_H_MAX(h) ((h) < CEU_MAX_HEIGHT ? (h) : CEU_MAX_HEIGHT)
> +
> +/*
> + * CEU formats
> + */
> +
> +/**
> + * ceu_bus_fmt - describe a 8-bits yuyv format the sensor can produce
> + *
> + * @mbus_code: bus format code
> + * @fmt_order: CEU_CAMCR.DTARY ordering of input components (Y, Cb, Cr)
> + * @fmt_order_swap: swapped CEU_CAMCR.DTARY ordering of input components
> + * (Y, Cr, Cb)
> + * @swapped: does Cr appear before Cb?
> + * @bps: number of bits sent over bus for each sample
> + * @bpp: number of bits per pixels unit
> + */
> +struct ceu_mbus_fmt {
> + u32 mbus_code;
> + u32 fmt_order;
> + u32 fmt_order_swap;
> + boolswapped;
> + u8 bps;
> + u8 bpp;
> +};
> +
> +/**
> + * ceu_buffer - Link vb2 buffer to the list of available buffers
If you use kerneldoc comments please make them compile. You need to document
the structure fields and function arguments.
> + */
> +struct ceu_buffer {
> + struct vb2_v4l2_buffer vb;
> + struct list_head queue;
> +};
> +
> +static inline struct ceu_buffer *vb2_to_ceu(struct vb2_v4l2_buffer *vbuf)
> +{
> + return container_of(vbuf, struct ceu_buffer, vb);
> +}
> +
> +/**
> + * ceu_subdev - Wraps v4l2 sub-device and provides async subdevice.
> + */
> +struct ceu_subdev {
> + struct v4l2_subdev *v4l2_sd;
> + struct v4l2_async_subdev asd;
> +
> + /* per-subdevice mbus configuration options */
> + unsigned int mbus_flags;
> + struct ceu_mbus_fmt mbus_fmt;
> +};
> +
> +static struct ceu_subdev *to_ceu_subdev(struct v4l2_async_subdev *asd)
> +{
> + return container_of(asd, struct ceu_subdev, asd);
> +}
> +
> +/**
> + * ceu_device - CEU device instance
> + */
> +struct ceu_device {
> + struct device *dev;
> + struct video_device vdev;
> + struct v4l2_device v4l2_dev;
> +
> + /* subdevices descriptors */
> + struct ceu_subdev *subdevs;
> + /* the subdevice currently in use */
> + struct ceu_subdev *sd;
> + unsigned intsd_index;
> + unsigned intnum_sd;
> +
> + /* currently configured field and pixel format */
> + enum v4l2_field field;
> + struct v4l2_pix_format_mplane v4l2_pix;
> +
> + /* async subdev notification helpers */
> + struct v4l2_async_notifier notifier;
> + /* pointers to "struct ceu_subdevice -> asd" *
Re: [PATCH 1/2] usb: gadget: restore tristate-choice for legacy gadgets
On Mon, 2017-12-11 at 12:30 +0100, Arnd Bergmann wrote:
> One patch that was meant as a cleanup apparently did more than it intended,
> allowing all combinations of legacy gadget drivers to be built into the
> kernel, and leaving an empty 'choice' statement behind:
>
> drivers/usb/gadget/Kconfig:487:warning: choice default symbol 'USB_ETH' is
> not contained in the choice
>
> The description of commit 7a9618a22aad ("usb: gadget: allow to enable legacy
> drivers without USB_ETH") was a bit cryptic, as it did not change the
> behavior of USB_ETH other than allowing it to be built into the kernel
> alongside other legacy gadgets, which is not a valid configuration.
>
> As Felipe explained in the description for commit bc49d1d17dcf ("usb:
> gadget: don't couple configfs to legacy gadgets"), the configfs based
> gadgets can be freely configured as loadable modules or built-in
> drivers, but the legacy gadgets can only be modules if there is more
> than one of them, so we require the 'choice' statement here.
>
> This leaves the added USB_GADGET_LEGACY menuconfig symbol in place,
> but then restores the 'choice' below it, so we can enforce the
> single-legacy-gadget rule as before.
Hello Arnd,
A discussion is ongoing about whether or not commit 7a9618a22aad should be
reverted.
Please drop this patch until a conclusion has been reached.
Thanks,
Bart.
Re: [PATCH v2 5/6] [media] cxusb: implement Medion MD95700 digital / analog coexistence
On 11.12.2017 16:45, Mauro Carvalho Chehab wrote: > Em Tue, 10 Oct 2017 23:36:55 +0200 > "Maciej S. Szmigiero" escreveu: > >> This patch prepares cxusb driver for supporting the analog part of >> Medion 95700 (previously only the digital - DVB - mode was supported). >> >> Specifically, it adds support for: >> * switching the device between analog and digital modes of operation, >> * enforcing that only one mode is active at the same time due to hardware >> limitations. >> >> Actual implementation of the analog mode will be provided by the next >> commit. >> >> Signed-off-by: Maciej S. Szmigiero > > This patch doesn't apply: > > Hunk #2 FAILED at 25. > Hunk #3 FAILED at 47. (..) Probably it has already bit-rotted since October - will try to respin within two weeks (while addressing your comments to patch 1, too.) Maciej
Re: [PATCH v2 5/6] [media] cxusb: implement Medion MD95700 digital / analog coexistence
Em Tue, 10 Oct 2017 23:36:55 +0200 "Maciej S. Szmigiero" escreveu: > This patch prepares cxusb driver for supporting the analog part of > Medion 95700 (previously only the digital - DVB - mode was supported). > > Specifically, it adds support for: > * switching the device between analog and digital modes of operation, > * enforcing that only one mode is active at the same time due to hardware > limitations. > > Actual implementation of the analog mode will be provided by the next > commit. > > Signed-off-by: Maciej S. Szmigiero This patch doesn't apply: Hunk #2 FAILED at 25. Hunk #3 FAILED at 47. Hunk #4 succeeded at 90 (offset 1 line). Hunk #5 succeeded at 102 (offset 1 line). Hunk #6 succeeded at 262 (offset 1 line). Hunk #7 succeeded at 270 (offset 1 line). Hunk #8 succeeded at 389 (offset 2 lines). Hunk #9 succeeded at 683 (offset 2 lines). Hunk #10 succeeded at 799 (offset 2 lines). Hunk #11 succeeded at 1533 (offset 2 lines). Hunk #12 succeeded at 1644 (offset 2 lines). Hunk #13 succeeded at 1770 (offset 2 lines). Hunk #14 succeeded at 1783 (offset 2 lines). Hunk #15 succeeded at 1803 (offset 2 lines). Hunk #16 succeeded at 1879 (offset 2 lines). Hunk #17 succeeded at 2649 (offset 2 lines). 2 out of 17 hunks FAILED checking file drivers/media/usb/dvb-usb/cxusb.h Hunk #1 succeeded at 2 (offset 1 line). Hunk #2 succeeded at 37 (offset 1 line). Hunk #3 succeeded at 49 (offset 1 line). checking file drivers/media/usb/dvb-usb/dvb-usb-dvb.c Hunk #1 succeeded at 15 (offset 1 line). Hunk #2 succeeded at 25 (offset 1 line). Hunk #3 succeeded at 43 (offset 1 line). Hunk #4 succeeded at 64 (offset 1 line). Hunk #5 succeeded at 90 (offset 1 line). checking file drivers/media/usb/dvb-usb/dvb-usb-init.c checking file drivers/media/usb/dvb-usb/dvb-usb.h Hunk #1 succeeded at 143 (offset 1 line). Hunk #2 succeeded at 235 (offset 1 line). Hunk #3 succeeded at 281 (offset 1 line). drivers/media/usb/dvb-usb/cxusb.c| 450 +++ drivers/media/usb/dvb-usb/cxusb.h| 48 +++ drivers/media/usb/dvb-usb/dvb-usb-dvb.c | 20 + drivers/media/usb/dvb-usb/dvb-usb-init.c | 13 drivers/media/usb/dvb-usb/dvb-usb.h |8 5 files changed, 486 insertions(+), 53 deletions(-)
Re: [PATCH v2 1/6] cx25840: add pin to pad mapping and output format configuration
Em Tue, 10 Oct 2017 23:34:45 +0200
"Maciej S. Szmigiero" escreveu:
> This commit adds pin to pad mapping and output format configuration support
> in CX2584x-series chips to cx25840 driver.
>
> This functionality is then used to allow disabling ivtv-specific hacks
> (called a "generic mode"), so cx25840 driver can be used for other devices
> not needing them without risking compatibility problems.
>
> Signed-off-by: Maciej S. Szmigiero
> ---
> drivers/media/i2c/cx25840/cx25840-core.c | 394
> ++-
> drivers/media/i2c/cx25840/cx25840-core.h | 11 +
> drivers/media/i2c/cx25840/cx25840-vbi.c | 3 +
> drivers/media/pci/ivtv/ivtv-i2c.c| 1 +
> include/media/drv-intf/cx25840.h | 74 +-
> 5 files changed, 481 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/i2c/cx25840/cx25840-core.c
> b/drivers/media/i2c/cx25840/cx25840-core.c
> index f38bf819d805..a1efc975852c 100644
> --- a/drivers/media/i2c/cx25840/cx25840-core.c
> +++ b/drivers/media/i2c/cx25840/cx25840-core.c
> @@ -21,6 +21,9 @@
> * CX23888 DIF support for the HVR1850
> * Copyright (C) 2011 Steven Toth
> *
> + * CX2584x pin to pad mapping and output format configuration support are
> + * Copyright (C) 2011 Maciej S. Szmigiero
> + *
> * 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
> @@ -316,6 +319,260 @@ static int cx23885_s_io_pin_config(struct v4l2_subdev
> *sd, size_t n,
> return 0;
> }
>
> +static u8 cx25840_function_to_pad(struct i2c_client *client, u8 function)
> +{
> + switch (function) {
> + case CX25840_PAD_ACTIVE:
> + return 1;
> +
> + case CX25840_PAD_VACTIVE:
> + return 2;
> +
> + case CX25840_PAD_CBFLAG:
> + return 3;
> +
> + case CX25840_PAD_VID_DATA_EXT0:
> + return 4;
> +
> + case CX25840_PAD_VID_DATA_EXT1:
> + return 5;
> +
> + case CX25840_PAD_GPO0:
> + return 6;
> +
> + case CX25840_PAD_GPO1:
> + return 7;
> +
> + case CX25840_PAD_GPO2:
> + return 8;
> +
> + case CX25840_PAD_GPO3:
> + return 9;
> +
> + case CX25840_PAD_IRQ_N:
> + return 10;
> +
> + case CX25840_PAD_AC_SYNC:
> + return 11;
> +
> + case CX25840_PAD_AC_SDOUT:
> + return 12;
> +
> + case CX25840_PAD_PLL_CLK:
> + return 13;
> +
> + case CX25840_PAD_VRESET:
> + return 14;
> +
> + default:
> + if (function != CX25840_PAD_DEFAULT)
> + v4l_err(client,
> + "invalid function %u, assuming default\n",
> + (unsigned int)function);
> + return 0;
> + }
> +}
> +
> +static void cx25840_set_invert(u8 *pinctrl3, u8 *voutctrl4, u8 function,
> +u8 pin, bool invert)
> +{
> + switch (function) {
> + case CX25840_PAD_IRQ_N:
> + if (invert)
> + *pinctrl3 &= ~2;
> + else
> + *pinctrl3 |= 2;
> + break;
> +
> + case CX25840_PAD_ACTIVE:
> + if (invert)
> + *voutctrl4 |= BIT(2);
> + else
> + *voutctrl4 &= ~BIT(2);
> + break;
> +
> + case CX25840_PAD_VACTIVE:
> + if (invert)
> + *voutctrl4 |= BIT(5);
> + else
> + *voutctrl4 &= ~BIT(5);
> + break;
> +
> + case CX25840_PAD_CBFLAG:
> + if (invert)
> + *voutctrl4 |= BIT(4);
> + else
> + *voutctrl4 &= ~BIT(4);
> + break;
> +
> + case CX25840_PAD_VRESET:
> + if (invert)
> + *voutctrl4 |= BIT(0);
> + else
> + *voutctrl4 &= ~BIT(0);
> + break;
> + }
> +
> + if (function != CX25840_PAD_DEFAULT)
> + return;
> +
> + switch (pin) {
> + case CX25840_PIN_DVALID_PRGM0:
> + if (invert)
> + *voutctrl4 |= BIT(6);
> + else
> + *voutctrl4 &= ~BIT(6);
> + break;
> +
> + case CX25840_PIN_HRESET_PRGM2:
> + if (invert)
> + *voutctrl4 |= BIT(1);
> + else
> + *voutctrl4 &= ~BIT(1);
> + break;
> + }
> +}
> +
> +static int cx25840_s_io_pin_config(struct v4l2_subdev *sd, size_t n,
> +struct v4l2_subdev_io_pin_config *p)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(sd);
> + unsigned int i;
> + u8 pinctrl[6], pinconf[10], voutctrl4;
> +
> + for (i = 0; i < 6; i++)
> + pinctrl[i] = cx25840_read(client, 0x114 + i);
> +
> + for (i =
Re: [PATCH] tuners: tda8290: reduce stack usage with kasan
On Mon, Dec 11, 2017 at 7:06 AM, Arnd Bergmann wrote:
> With CONFIG_KASAN enabled, we get a relatively large stack frame in one
> function
>
> drivers/media/tuners/tda8290.c: In function 'tda8290_set_params':
> drivers/media/tuners/tda8290.c:310:1: warning: the frame size of 1520 bytes
> is larger than 1024 bytes [-Wframe-larger-than=]
>
> With CONFIG_KASAN_EXTRA this goes up to
>
> drivers/media/tuners/tda8290.c: In function 'tda8290_set_params':
> drivers/media/tuners/tda8290.c:310:1: error: the frame size of 3200 bytes is
> larger than 3072 bytes [-Werror=frame-larger-than=]
>
> We can significantly reduce this by marking local arrays as 'static const',
> and
> this should result in better compiled code for everyone.
>
> I have another patch for the same symptom to patch tuner_i2c_xfer_*, and we
> actually want both of them.
>
> Signed-off-by: Arnd Bergmann
Thank you, Arnd.
Reviewed-by: Michael Ira Krufky
> ---
> drivers/media/tuners/tda8290.c | 76
> ++
> 1 file changed, 39 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/media/tuners/tda8290.c b/drivers/media/tuners/tda8290.c
> index a59c567c55d6..19854221b72d 100644
> --- a/drivers/media/tuners/tda8290.c
> +++ b/drivers/media/tuners/tda8290.c
> @@ -63,8 +63,8 @@ static int tda8290_i2c_bridge(struct dvb_frontend *fe, int
> close)
> {
> struct tda8290_priv *priv = fe->analog_demod_priv;
>
> - unsigned char enable[2] = { 0x21, 0xC0 };
> - unsigned char disable[2] = { 0x21, 0x00 };
> + static unsigned char enable[2] = { 0x21, 0xC0 };
> + static unsigned char disable[2] = { 0x21, 0x00 };
> unsigned char *msg;
>
> if (close) {
> @@ -84,9 +84,9 @@ static int tda8295_i2c_bridge(struct dvb_frontend *fe, int
> close)
> {
> struct tda8290_priv *priv = fe->analog_demod_priv;
>
> - unsigned char enable[2] = { 0x45, 0xc1 };
> - unsigned char disable[2] = { 0x46, 0x00 };
> - unsigned char buf[3] = { 0x45, 0x01, 0x00 };
> + static unsigned char enable[2] = { 0x45, 0xc1 };
> + static unsigned char disable[2] = { 0x46, 0x00 };
> + static unsigned char buf[3] = { 0x45, 0x01, 0x00 };
> unsigned char *msg;
>
> if (close) {
> @@ -178,24 +178,24 @@ static void tda8290_set_params(struct dvb_frontend *fe,
> {
> struct tda8290_priv *priv = fe->analog_demod_priv;
>
> - unsigned char soft_reset[] = { 0x00, 0x00 };
> + static unsigned char soft_reset[] = { 0x00, 0x00 };
> unsigned char easy_mode[] = { 0x01, priv->tda8290_easy_mode };
> - unsigned char expert_mode[] = { 0x01, 0x80 };
> - unsigned char agc_out_on[] = { 0x02, 0x00 };
> - unsigned char gainset_off[] = { 0x28, 0x14 };
> - unsigned char if_agc_spd[] = { 0x0f, 0x88 };
> - unsigned char adc_head_6[] = { 0x05, 0x04 };
> - unsigned char adc_head_9[] = { 0x05, 0x02 };
> - unsigned char adc_head_12[] = { 0x05, 0x01 };
> - unsigned char pll_bw_nom[] = { 0x0d, 0x47 };
> - unsigned char pll_bw_low[] = { 0x0d, 0x27 };
> - unsigned char gainset_2[] = { 0x28, 0x64 };
> - unsigned char agc_rst_on[] = { 0x0e, 0x0b };
> - unsigned char agc_rst_off[] = { 0x0e, 0x09 };
> - unsigned char if_agc_set[] = { 0x0f, 0x81 };
> - unsigned char addr_adc_sat = 0x1a;
> - unsigned char addr_agc_stat = 0x1d;
> - unsigned char addr_pll_stat = 0x1b;
> + static unsigned char expert_mode[] = { 0x01, 0x80 };
> + static unsigned char agc_out_on[] = { 0x02, 0x00 };
> + static unsigned char gainset_off[] = { 0x28, 0x14 };
> + static unsigned char if_agc_spd[] = { 0x0f, 0x88 };
> + static unsigned char adc_head_6[] = { 0x05, 0x04 };
> + static unsigned char adc_head_9[] = { 0x05, 0x02 };
> + static unsigned char adc_head_12[] = { 0x05, 0x01 };
> + static unsigned char pll_bw_nom[] = { 0x0d, 0x47 };
> + static unsigned char pll_bw_low[] = { 0x0d, 0x27 };
> + static unsigned char gainset_2[] = { 0x28, 0x64 };
> + static unsigned char agc_rst_on[] = { 0x0e, 0x0b };
> + static unsigned char agc_rst_off[] = { 0x0e, 0x09 };
> + static unsigned char if_agc_set[] = { 0x0f, 0x81 };
> + static unsigned char addr_adc_sat = 0x1a;
> + static unsigned char addr_agc_stat = 0x1d;
> + static unsigned char addr_pll_stat = 0x1b;
> unsigned char adc_sat, agc_stat,
> pll_stat;
> int i;
> @@ -468,9 +468,9 @@ static void tda8290_standby(struct dvb_frontend *fe)
> {
> struct tda8290_priv *priv = fe->analog_demod_priv;
>
> - unsigned char cb1[] = { 0x30, 0xD0 };
> - unsigned char tda8290_standby[] = { 0x00, 0x02 };
> - unsigned char tda8290_agc_tri[] = { 0x02, 0x20 };
> + static unsigned char cb1[] = { 0x30, 0xD0 };
> + static unsigned char tda8290_standby[] = { 0x00, 0x02 };
> + stati
Re: [PATCH v1 03/10] v4l: platform: Add Renesas CEU driver
Hi Sakari,
On Friday, 17 November 2017 02:36:51 EET Sakari Ailus wrote:
> On Wed, Nov 15, 2017 at 03:25:11PM +0100, jacopo mondi wrote:
> > On Wed, Nov 15, 2017 at 02:45:51PM +0200, Sakari Ailus wrote:
> >> Hi Jacopo,
> >>
> >> Could you remove the original driver and send the patch using git
> >> send-email -C ? That way a single patch would address converting it to a
> >> proper V4L2 driver as well as move it to the correct location. The
> >> changes would be easier to review that way since then, well, it'd be
> >> easier to see the changes. :-)
> >
> > Actually I prefer not to remove the existing driver at the moment. See
> > the cover letter for reasons why not to do so right now...
>
> So it's about testing mostly? Does someone (possibly you) have those boards
> to test? I'd like to see this patchset to remove that last remaining SoC
> camera bridge driver. :-)
Unfortunately there's also drivers/media/platform/pxa-camera.c :-(
> > Also, there's not that much code from the old driver in here, surely
> > less than the default 50% -C and -M options of 'git format-patch' use
> > as a threshold for detecting copies iirc..
>
> Oh, if that's so, then makes sense to review it as a new driver.
Yes, unfortunately the drivers are too different. Jacopo started developing an
incremental patch series to move the driver away from soc-camera, but in the
end we decided to stop following that path as it was too painful. It's easier
to review a new driver in this case.
> > I would prefer this to be reviewed as new driver, I know it's a bit
> > more painful, but irq handler and a couple of other routines apart,
> > there's not that much code shared between the two...
> >
> >> The same goes for the two V4L2 SoC camera sensor / video decoder drivers
> >> at the end of the set.
> >
> > Also in this case I prefer not to remove existing code, as long as
> > there are platforms using it..
>
> Couldn't they use this driver instead?
>
> >> On Wed, Nov 15, 2017 at 11:55:56AM +0100, Jacopo Mondi wrote:
> >>> Add driver for Renesas Capture Engine Unit (CEU).
> >>>
> >>> The CEU interface supports capturing 'data' (YUV422) and 'images'
> >>> (NV[12|21|16|61]).
> >>>
> >>> This driver aims to replace the soc_camera based sh_mobile_ceu one.
> >>>
> >>> Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas
> >>> RZ platform GR-Peach.
> >>>
> >>> Tested with ov7725 camera sensor on SH4 platform Migo-R.
> >>
> >> Nice!
> >>
> >>> Signed-off-by: Jacopo Mondi
> >>> ---
> >>> +#include
> >>
> >> Do you need this header? There would seem some that I wouldn't expect to
> >> be needed below, such as linux/init.h.
> >
> > It's probably a leftover, I'll remove it...
> >
> > [snip]
> >
> >>> +#if IS_ENABLED(CONFIG_OF)
> >>> +static const struct of_device_id ceu_of_match[] = {
> >>> + { .compatible = "renesas,renesas-ceu" },
> >>
> >> Even if you add support for new hardware, shouldn't you maintain support
> >> for renesas,sh-mobile-ceu?
> >
> > As you noticed already, the old driver did not support OF, so there
> > are no compatibility issues here
>
> Yeah, I realised that only after reviewing this patch.
>
> It'd be Super-cool if someone did the DT conversion. Perhaps Laurent? ;-)
Or you ? :-)
--
Regards,
Laurent Pinchart
Re: [PATCH v1 10/10] media: i2c: tw9910: Remove soc_camera dependencies
Hi Jacopo,
Thank you for the patch.
On Wednesday, 15 November 2017 12:56:03 EET Jacopo Mondi wrote:
> Remove soc_camera framework dependencies from tw9910 sensor driver.
> - Handle clock directly
> - Register async subdevice
> - Add platform specific enable/disable functions
> - Adjust build system
>
> This commit does not remove the original soc_camera based driver.
>
> Signed-off-by: Jacopo Mondi
> ---
> drivers/media/i2c/Kconfig | 9 ++
> drivers/media/i2c/Makefile | 1 +
> drivers/media/i2c/tw9910.c | 80 +++
> include/media/i2c/tw9910.h | 6
> 4 files changed, 75 insertions(+), 21 deletions(-)
[snip]
> diff --git a/drivers/media/i2c/tw9910.c b/drivers/media/i2c/tw9910.c
> index bdb5e0a..f422da2 100644
> --- a/drivers/media/i2c/tw9910.c
> +++ b/drivers/media/i2c/tw9910.c
[snip]
> @@ -582,13 +581,40 @@ static int tw9910_s_register(struct v4l2_subdev *sd,
> }
> #endif
>
> +static int tw9910_power_on(struct tw9910_priv *priv)
> +{
> + int ret;
> +
> + if (priv->info->platform_enable) {
> + ret = priv->info->platform_enable();
> + if (ret)
> + return ret;
> + }
> +
> + if (priv->clk)
> + return clk_enable(priv->clk);
Shouldn't you use clk_prepare_enable() here ?
> + return 0;
> +}
> +
> +static int tw9910_power_off(struct tw9910_priv *priv)
> +{
> + if (priv->info->platform_enable)
> + priv->info->platform_disable();
> +
> + if (priv->clk)
> + clk_disable(priv->clk);
And clk_disable_unprepare() here ?
> +
> + return 0;
> +}
[snip]
> @@ -959,13 +979,27 @@ static int tw9910_probe(struct i2c_client *client,
>
> v4l2_i2c_subdev_init(&priv->subdev, client, &tw9910_subdev_ops);
>
> - priv->clk = v4l2_clk_get(&client->dev, "mclk");
> - if (IS_ERR(priv->clk))
> + priv->clk = clk_get(&client->dev, "mclk");
> + if (PTR_ERR(priv->clk) == -ENOENT) {
> + priv->clk = NULL;
> + } else if (IS_ERR(priv->clk)) {
> + dev_err(&client->dev, "Unable to get mclk clock\n");
> return PTR_ERR(priv->clk);
> + }
>
> ret = tw9910_video_probe(client);
> if (ret < 0)
> - v4l2_clk_put(priv->clk);
> + goto error_put_clk;
> +
> + ret = v4l2_async_register_subdev(&priv->subdev);
> + if (ret)
> + goto error_put_clk;
> +
> + return ret;
> +
> +error_put_clk:
> + if (priv->clk)
> + clk_put(priv->clk);
No need to check if priv->clk is NULL here, clk_put() should handle that
properly.
> return ret;
> }
> @@ -973,7 +1007,11 @@ static int tw9910_probe(struct i2c_client *client,
> static int tw9910_remove(struct i2c_client *client)
> {
> struct tw9910_priv *priv = to_tw9910(client);
> - v4l2_clk_put(priv->clk);
> +
> + if (priv->clk)
> + clk_put(priv->clk);
Same here.
> + v4l2_device_unregister_subdev(&priv->subdev);
> +
> return 0;
> }
>
> diff --git a/include/media/i2c/tw9910.h b/include/media/i2c/tw9910.h
> index 90bcf1f..b80e45c 100644
> --- a/include/media/i2c/tw9910.h
> +++ b/include/media/i2c/tw9910.h
> @@ -18,6 +18,9 @@
>
> #include
>
> +#define TW9910_DATAWIDTH_8 BIT(0)
> +#define TW9910_DATAWIDTH_16 BIT(1)
> +
> enum tw9910_mpout_pin {
> TW9910_MPO_VLOSS,
> TW9910_MPO_HLOCK,
> @@ -32,6 +35,9 @@ enum tw9910_mpout_pin {
> struct tw9910_video_info {
> unsigned long buswidth;
> enum tw9910_mpout_pin mpout;
How about storing that as an unsigned int that takes values 8 or 16 ? It would
be more explicit (and a bit of kerneldoc for the tw9910_video_info structure
would make that even better).
> + int (*platform_enable)(void);
> + void (*platform_disable)(void);
> };
--
Regards,
Laurent Pinchart
Re: [PATCH v1 09/10] v4l: i2c: Copy tw9910 soc_camera sensor driver
Hi Jacopo, Thank you for the patch. On Wednesday, 15 November 2017 12:56:02 EET Jacopo Mondi wrote: > Copy the soc_camera based driver in v4l2 sensor driver directory. > This commit just copies the original file without modifying it. As for patch 07/10, you might want to explain why you're not patching the Kconfig and Makefile here, that is because you will first convert the driver away from soc-camera in the next commit. Apart from that, Acked-by: Laurent Pinchart > Signed-off-by: Jacopo Mondi > --- > drivers/media/i2c/tw9910.c | 999 ++ > 1 file changed, 999 insertions(+) > create mode 100644 drivers/media/i2c/tw9910.c -- Regards, Laurent Pinchart
Re: [PATCH v1 07/10] v4l: i2c: Copy ov772x soc_camera sensor driver
Hi Jacopo, Thank you for the patch. On Wednesday, 15 November 2017 12:56:00 EET Jacopo Mondi wrote: > Copy the soc_camera based driver in v4l2 sensor driver directory. > This commit just copies the original file without modifying it. You might want to explain why you're not patching the Kconfig and Makefile here, that is because you will first convert the driver away from soc-camera in the next commit. Apart from that, Acked-by: Laurent Pinchart > Signed-off-by: Jacopo Mondi > --- > drivers/media/i2c/ov772x.c | 1124 + > 1 file changed, 1124 insertions(+) > create mode 100644 drivers/media/i2c/ov772x.c -- Regards, Laurent Pinchart
Re: [PATCH v1 08/10] media: i2c: ov772x: Remove soc_camera dependencies
Hi Jacopo,
Thank you for the patch.
On Wednesday, 15 November 2017 12:56:01 EET Jacopo Mondi wrote:
> Remove soc_camera framework dependencies from ov772x sensor driver.
> - Handle clock directly
> - Register async subdevice
> - Add platform specific enable/disable functions
> - Adjust build system
>
> This commit does not remove the original soc_camera based driver.
>
> Signed-off-by: Jacopo Mondi
> ---
> drivers/media/i2c/Kconfig | 12 +++
> drivers/media/i2c/Makefile | 1 +
> drivers/media/i2c/ov772x.c | 88 ---
> include/media/i2c/ov772x.h | 3 ++
> 4 files changed, 76 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 9415389..ff251ce 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -629,6 +629,18 @@ config VIDEO_OV5670
> To compile this driver as a module, choose M here: the
> module will be called ov5670.
>
> +config VIDEO_OV772X
> + tristate "OmniVision OV772x sensor support"
> + depends on I2C && VIDEO_V4L2
> + depends on MEDIA_CAMERA_SUPPORT
> + ---help---
> + This is a Video4Linux2 sensor-level driver for the OmniVision
> + OV772x camera.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called ov772x.
> +
> +
A single blank line is enough.
> config VIDEO_OV7640
> tristate "OmniVision OV7640 sensor support"
> depends on I2C && VIDEO_V4L2
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index f104650..b2459a1 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -66,6 +66,7 @@ obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
> obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
> obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
> obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
> +obj-$(CONFIG_VIDEO_OV772X) += ov772x.o
> obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
> obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
> obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
> diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
> index 8063835..9be7e4e 100644
> --- a/drivers/media/i2c/ov772x.c
> +++ b/drivers/media/i2c/ov772x.c
[snip]
> @@ -650,13 +651,36 @@ static int ov772x_s_register(struct v4l2_subdev *sd,
> }
> #endif
>
> +static int ov772x_power_on(struct ov772x_priv *priv)
> +{
> + int ret;
> +
> + if (priv->info->platform_enable) {
> + ret = priv->info->platform_enable();
> + if (ret)
> + return ret;
> + }
> +
> + /* drivers/sh/clk/core.c returns -EINVAL if clk is NULL */
> + return clk_enable(priv->clk) <= 0 ? 0 : 1;
Then please don't call clk_enable() if priv->clk is NULL, and propagate errors
from clk_enable() back to the caller.
And shouldn't you call clk_prepare_enable() (and clk_disable_unprepare()
below) ?
> +}
> +
> +static int ov772x_power_off(struct ov772x_priv *priv)
> +{
> + if (priv->info->platform_enable)
> + priv->info->platform_disable();
> +
> + clk_disable(priv->clk);
> +
> + return 0;
> +}
[snip]
> @@ -1073,21 +1092,33 @@ static int ov772x_probe(struct i2c_client *client,
> if (priv->hdl.error)
> return priv->hdl.error;
>
> - priv->clk = v4l2_clk_get(&client->dev, "mclk");
> - if (IS_ERR(priv->clk)) {
> + priv->clk = clk_get(&client->dev, "mclk");
> + if (PTR_ERR(priv->clk) == -ENOENT) {
> + priv->clk = NULL;
> + } else if (IS_ERR(priv->clk)) {
> + dev_err(&client->dev, "Unable to get mclk clock\n");
> ret = PTR_ERR(priv->clk);
> - goto eclkget;
You need a priv->clk = NULL here otherwise the error path will oops.
> + goto error_clk_enable;
> }
>
> ret = ov772x_video_probe(priv);
> - if (ret < 0) {
> - v4l2_clk_put(priv->clk);
> -eclkget:
> - v4l2_ctrl_handler_free(&priv->hdl);
> - } else {
> - priv->cfmt = &ov772x_cfmts[0];
> - priv->win = &ov772x_win_sizes[0];
> - }
> + if (ret < 0)
> + goto error_video_probe;
> +
> + priv->cfmt = &ov772x_cfmts[0];
> + priv->win = &ov772x_win_sizes[0];
> +
> + ret = v4l2_async_register_subdev(&priv->subdev);
> + if (ret)
> + goto error_video_probe;
> +
> + return 0;
> +
> +error_video_probe:
> + if (priv->clk)
> + clk_put(priv->clk);
clk_put() accepts a NULL clock, you don't have to check the pointer first.
> +error_clk_enable:
> + v4l2_ctrl_handler_free(&priv->hdl);
>
> return ret;
> }
> @@ -1096,7 +1127,8 @@ static int ov772x_remove(struct i2c_client *client)
> {
> struct ov772x_priv *priv = to_ov772x(i2c_get_clientdata(client));
>
> - v4l2_clk_put(priv->clk);
> + if (priv->clk)
> + clk_put(priv->clk);
Same here.
> v4l2_device_unregister_subdev(&priv->subdev);
> v4l2_ctrl_handler_free(&priv->hdl);
>
Re: [PATCH v3 3/5] media: dt-bindings: ov5640: add support of DVP parallel interface
Hi Sakari,
On 12/07/2017 02:59 PM, Sakari Ailus wrote:
> Hi Hugues,
>
> On Thu, Dec 07, 2017 at 01:40:51PM +0100, Hugues Fruchet wrote:
>> Add bindings for OV5640 DVP parallel interface support.
>>
>> Signed-off-by: Hugues Fruchet
>> ---
>> .../devicetree/bindings/media/i2c/ov5640.txt | 27
>> --
>> 1 file changed, 25 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5640.txt
>> b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
>> index 540b36c..04e2a91 100644
>> --- a/Documentation/devicetree/bindings/media/i2c/ov5640.txt
>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
>> @@ -1,4 +1,4 @@
>> -* Omnivision OV5640 MIPI CSI-2 sensor
>> +* Omnivision OV5640 MIPI CSI-2 / parallel sensor
>>
>> Required Properties:
>> - compatible: should be "ovti,ov5640"
>> @@ -18,7 +18,11 @@ The device node must contain one 'port' child node for
>> its digital output
>> video port, in accordance with the video interface bindings defined in
>> Documentation/devicetree/bindings/media/video-interfaces.txt.
>>
>> -Example:
>> +Parallel or CSI mode is selected according to optional endpoint properties.
>> +Without properties (or bus properties), parallel mode is selected.
>> +Specifying any CSI properties such as lanes will enable CSI mode.
>
> These bindings never documented what which endpoint properties were needed.
Ok I will add a section related to endpoint properties for both CSI and
parallel.
>
> Beyond that, the sensor supports two CSI-2 lanes. You should explicitly
> specify that, in other words, you'll need "data-lanes" property. Could you
> add that?
Ok I will add it to required endpoint property in case of CSI mode.
I will change commit header to reflect changes on parallel but also CSI
documentation.
>
> Long time ago when the video-interfaces.txt and the V4L2 OF framework were
> written, the bus type selection was made implicit and only later on
> explicit. This is still reflected in how the bus type gets set between
> CSI-2 D-PHY, parallel and Bt.656.
>
I'm a little bit confused, must I explicitly add as required property
"bus-type=0" (autodetect) for both cases ? Or must I require
"bus-type=1" for CSI and "bus-type=3" for parallel ?
Talking bindings, I feel that it could be of great help to document also
the polarity of control signals (hsync/vsync/pclk), they are currently
set by ov5640 init sequence and not configurable.
Moreover, should some checks be added in probe sequence to verify that
the defined control signals polarity are aligned with default ones from
init sequence ?
Here is a proposal:
"
The device node must contain one 'port' child node for its digital
output video port with a single 'endpoint' subnode, in accordance
with the video interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
OV5640 can be connected to a MIPI CSI bus or a parallel bus endpoint:
Endpoint node required properties for CSI connection are:
- remote-endpoint: a phandle to the bus receiver's endpoint node.
- bus-type: should be set to <1> (MIPI CSI-2 C-PHY)
- clock-lanes: should be set to <0> (clock lane on hardware lane 0)
- data-lanes: should be set to <1 2> (two CSI-2 lanes supported)
Endpoint node required properties for parallel connection are:
- remote-endpoint: a phandle to the bus receiver's endpoint node.
- bus-type: should be set to <3> (parallel CCP2)
- bus-width: should be set to <8> for 8 bits parallel bus
or <10> for 10 bits parallel bus
- data-shift: should be set to <2> for 8 bits parallel bus
(lines 9:2 are used) or <0> for 10 bits parallel bus
- hsync-active: should be set to <0> (Horizontal synchronization
polarity is active low).
- vsync-active: should be set to <1> (active high) (Horizontal
synchronization polarity is active low).
- pclk-sample: should be set to <1> (data are sampled on the rising
edge of the pixel clock signal).
>> +
>> +Examples:
>>
>> &i2c1 {
>> ov5640: camera@3c {
>> @@ -35,6 +39,7 @@ Example:
>> reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
>>
>> port {
>> +/* MIPI CSI-2 bus endpoint */
>> ov5640_to_mipi_csi2: endpoint {
>> remote-endpoint = <&mipi_csi2_from_ov5640>;
>> clock-lanes = <0>;
>> @@ -43,3 +48,21 @@ Example:
>> };
>> };
>> };
>> +
>> +&i2c1 {
>> +ov5640: camera@3c {
>> +compatible = "ovti,ov5640";
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&pinctrl_ov5640>;
>> +reg = <0x3c>;
>> +clocks = <&clk_ext_camera>;
>> +clock-names = "xclk";
>> +
>> +port {
>> +/* Parallel bus endpoint */
>> +ov5640_to_parallel: endpoint {
>> +
Re: [PATCH v1 05/10] arch: sh: migor: Use new renesas-ceu camera driver
Hi Jacopo,
Thank you for the patch.
On Wednesday, 15 November 2017 12:55:58 EET Jacopo Mondi wrote:
> Migo-R platform uses sh_mobile_ceu camera driver, which is now being
> replaced by a proper V4L2 camera driver named 'renesas-ceu'.
>
> Move Migo-R platform to use the v4l2 renesas-ceu camera driver
> interface and get rid of soc_camera defined components used to register
> sensor drivers.
>
> Also, memory for CEU video buffers is now reserved with membocks APIs,
> and need to be declared as dma_coherent during machine initialization to
> remove that architecture specific part from CEU driver.
>
> Signed-off-by: Jacopo Mondi
> ---
> arch/sh/boards/mach-migor/setup.c | 164 --
> 1 file changed, 76 insertions(+), 88 deletions(-)
>
> diff --git a/arch/sh/boards/mach-migor/setup.c
> b/arch/sh/boards/mach-migor/setup.c index 98aa094..10a9b3c 100644
> --- a/arch/sh/boards/mach-migor/setup.c
> +++ b/arch/sh/boards/mach-migor/setup.c
> @@ -27,7 +27,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> @@ -308,62 +308,80 @@ static struct platform_device migor_lcdc_device = {
> static struct clk *camera_clk;
> static DEFINE_MUTEX(camera_lock);
>
> -static void camera_power_on(int is_tw)
> +static void camera_vio_clk_on(void)
> {
> - mutex_lock(&camera_lock);
> -
> /* Use 10 MHz VIO_CKO instead of 24 MHz to work
>* around signal quality issues on Panel Board V2.1.
>*/
> camera_clk = clk_get(NULL, "video_clk");
> clk_set_rate(camera_clk, 1000);
> clk_enable(camera_clk); /* start VIO_CKO */
> -
> - /* use VIO_RST to take camera out of reset */
> - mdelay(10);
> - if (is_tw) {
> - gpio_set_value(GPIO_PTT2, 0);
> - gpio_set_value(GPIO_PTT0, 0);
> - } else {
> - gpio_set_value(GPIO_PTT0, 1);
> - }
> - gpio_set_value(GPIO_PTT3, 0);
> - mdelay(10);
> - gpio_set_value(GPIO_PTT3, 1);
> - mdelay(10); /* wait to let chip come out of reset */
> }
>
> -static void camera_power_off(void)
> +static void camera_disable(void)
> {
> - clk_disable(camera_clk); /* stop VIO_CKO */
> + /* stop VIO_CKO */
> + clk_disable(camera_clk);
> clk_put(camera_clk);
>
> + gpio_set_value(GPIO_PTT0, 0);
> + gpio_set_value(GPIO_PTT2, 1);
> gpio_set_value(GPIO_PTT3, 0);
> +
> mutex_unlock(&camera_lock);
> }
>
> -static int ov7725_power(struct device *dev, int mode)
> +static void camera_reset(void)
> {
> - if (mode)
> - camera_power_on(0);
> - else
> - camera_power_off();
> + /* use VIO_RST to take camera out of reset */
> + gpio_set_value(GPIO_PTT3, 0);
> + mdelay(10);
> + gpio_set_value(GPIO_PTT3, 1);
> + mdelay(10);
> +}
> +
> +static int ov7725_enable(void)
> +{
> + mutex_lock(&camera_lock);
> + camera_vio_clk_on();
> + mdelay(10);
> + gpio_set_value(GPIO_PTT0, 1);
> +
> + camera_reset();
>
> return 0;
> }
>
> -static int tw9910_power(struct device *dev, int mode)
> +static int tw9910_enable(void)
> {
> - if (mode)
> - camera_power_on(1);
> - else
> - camera_power_off();
> + mutex_lock(&camera_lock);
> + camera_vio_clk_on();
> + mdelay(10);
> + gpio_set_value(GPIO_PTT2, 0);
> +
> + camera_reset();
>
> return 0;
> }
Can't all these be moved to drivers by using the GPIO, clock and regulator
APIs ? We should really try to get rid of platform callbacks. Apart from the
patch patch looks good to me.
> -static struct sh_mobile_ceu_info sh_mobile_ceu_info = {
> - .flags = SH_CEU_FLAG_USE_8BIT_BUS,
> +static struct ceu_info ceu_info = {
> + .num_subdevs= 2,
> + .subdevs = {
> + { /* [0] = ov772x */
> + .flags = CEU_FLAG_PRIMARY_SENS,
> + .bus_width = 8,
> + .bus_shift = 0,
> + .i2c_adapter_id = 0,
> + .i2c_address= 0x21,
> + },
> + { /* [1] = tw9910 */
> + .flags = 0,
> + .bus_width = 8,
> + .bus_shift = 0,
> + .i2c_adapter_id = 0,
> + .i2c_address= 0x45,
> + },
> + },
> };
>
> static struct resource migor_ceu_resources[] = {
> @@ -377,18 +395,15 @@ static struct resource migor_ceu_resources[] = {
> .start = evt2irq(0x880),
> .flags = IORESOURCE_IRQ,
> },
> - [2] = {
> - /* place holder for contiguous memory */
> - },
> };
>
> static struct platform_device migor_ceu_device = {
> - .name = "sh_mobile_ceu",
> + .name = "renesas-ceu",
> .id = 0, /* "ceu0" clock */
> .num_resources = ARRAY_SIZE(migor_ceu_resources),
> .reso
Re: [PATCH v1 02/10] include: media: Add Renesas CEU driver interface
Hi Jacopo,
On Monday, 11 December 2017 16:26:27 EET Laurent Pinchart wrote:
> On Wednesday, 15 November 2017 14:36:33 EET Sakari Ailus wrote:
> > On Wed, Nov 15, 2017 at 11:55:55AM +0100, Jacopo Mondi wrote:
> >> Add renesas-ceu header file.
> >>
> >> Do not remove the existing sh_mobile_ceu.h one as long as the original
> >> driver does not go away.
> >
> > Hmm. This isn't really not about not removing a file but adding a new one.
> > Do you really need it outside the driver's own directory?
>
> The file defines platform data structures that are needed for arch/sh/.
>
> >> Signed-off-by: Jacopo Mondi
> >> ---
> >>
> >> include/media/drv-intf/renesas-ceu.h | 23 +++
> >> 1 file changed, 23 insertions(+)
> >> create mode 100644 include/media/drv-intf/renesas-ceu.h
> >>
> >> diff --git a/include/media/drv-intf/renesas-ceu.h
> >> b/include/media/drv-intf/renesas-ceu.h new file mode 100644
> >> index 000..f2da78c
> >> --- /dev/null
> >> +++ b/include/media/drv-intf/renesas-ceu.h
> >> @@ -0,0 +1,23 @@
> >> +// SPDX-License-Identifier: GPL-2.0+
> >> +#ifndef __ASM_RENESAS_CEU_H__
> >> +#define __ASM_RENESAS_CEU_H__
> >> +
> >> +#include
>
> I don't think you need this.
>
> > > +#define CEU_FLAG_PRIMARY_SENSBIT(0)
I forgot to mention that this flag should be renamed as well, but couldn't we
get rid of it completely by mandating that the first subdev in the subdevs
array should be the primary one ?
> > > +#define CEU_MAX_SENS 2
>
> I assume SENS stands for sensor. As other sources than sensors can be
> supported (video decoders for instance), I would name this CEU_MAX_SUBDEVS,
> CEU_MAX_INPUTS or something similar.
>
> >> +
> >> +struct ceu_async_subdev {
> >> + unsigned long flags;
> >> + unsigned char bus_width;
> >> + unsigned char bus_shift;
> >> + unsigned int i2c_adapter_id;
> >> + unsigned int i2c_address;
> >> +};
> >> +
> >> +struct ceu_info {
> >> + unsigned int num_subdevs;
> >> + struct ceu_async_subdev subdevs[CEU_MAX_SENS];
> >> +};
> >> +
> >> +#endif /* __ASM_RENESAS_CEU_H__ */
--
Regards,
Laurent Pinchart
Re: [PATCH v1 02/10] include: media: Add Renesas CEU driver interface
Hi Sakari,
On Wednesday, 15 November 2017 14:36:33 EET Sakari Ailus wrote:
> On Wed, Nov 15, 2017 at 11:55:55AM +0100, Jacopo Mondi wrote:
> > Add renesas-ceu header file.
> >
> > Do not remove the existing sh_mobile_ceu.h one as long as the original
> > driver does not go away.
>
> Hmm. This isn't really not about not removing a file but adding a new one.
> Do you really need it outside the driver's own directory?
The file defines platform data structures that are needed for arch/sh/.
> > Signed-off-by: Jacopo Mondi
> > ---
> >
> > include/media/drv-intf/renesas-ceu.h | 23 +++
> > 1 file changed, 23 insertions(+)
> > create mode 100644 include/media/drv-intf/renesas-ceu.h
> >
> > diff --git a/include/media/drv-intf/renesas-ceu.h
> > b/include/media/drv-intf/renesas-ceu.h new file mode 100644
> > index 000..f2da78c
> > --- /dev/null
> > +++ b/include/media/drv-intf/renesas-ceu.h
> > @@ -0,0 +1,23 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +#ifndef __ASM_RENESAS_CEU_H__
> > +#define __ASM_RENESAS_CEU_H__
> > +
> > +#include
I don't think you need this.
> > +#define CEU_FLAG_PRIMARY_SENS BIT(0)
> > +#define CEU_MAX_SENS 2
I assume SENS stands for sensor. As other sources than sensors can be
supported (video decoders for instance), I would name this CEU_MAX_SUBDEVS,
CEU_MAX_INPUTS or something similar.
> > +
> > +struct ceu_async_subdev {
> > + unsigned long flags;
> > + unsigned char bus_width;
> > + unsigned char bus_shift;
> > + unsigned int i2c_adapter_id;
> > + unsigned int i2c_address;
> > +};
> > +
> > +struct ceu_info {
> > + unsigned int num_subdevs;
> > + struct ceu_async_subdev subdevs[CEU_MAX_SENS];
> > +};
> > +
> > +#endif /* __ASM_RENESAS_CEU_H__ */
> > --
> > 2.7.4
--
Regards,
Laurent Pinchart
Re: [PATCH v1 01/10] dt-bindings: media: Add Renesas CEU bindings
Hello,
On Wednesday, 15 November 2017 14:33:12 EET Sakari Ailus wrote:
> On Wed, Nov 15, 2017 at 11:55:54AM +0100, Jacopo Mondi wrote:
> > Add bindings documentation for Renesas Capture Engine Unit (CEU).
> >
> > Signed-off-by: Jacopo Mondi
> > ---
> >
> > .../devicetree/bindings/media/renesas,ceu.txt | 87 +
> > 1 file changed, 87 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/media/renesas,ceu.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt
> > b/Documentation/devicetree/bindings/media/renesas,ceu.txt new file mode
> > 100644
> > index 000..a88e9cb
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> > @@ -0,0 +1,87 @@
> > +Renesas Capture Engine Unit (CEU)
> > +--
> > +
> > +The Capture Engine Unit is the image capture interface found on Renesas
> > +RZ chip series and on SH Mobile ones.
> > +
> > +The interface supports a single parallel input with up 8/16bits data bus
> > width.
> > +
> > +Required properties:
> > +- compatible
> > + Must be "renesas,renesas-ceu".
> > +- reg
> > + Physical address base and size.
> > +- interrupts
> > + The interrupt line number.
> > +- pinctrl-names, pinctrl-0
> > + phandle of pin controller sub-node configuring pins for CEU operations.
> > +
> > +CEU supports a single parallel input and should contain a single 'port'
> > subnode
> > +with a single 'endpoint'. Optional endpoint properties applicable to
> > parallel
> > +input bus are described in "video-interfaces.txt".
>
> Could you list which ones they are? For someone not familiar with the
> parallel bus this might not be obvious; also not all hardware can make use
> of every one of these properties.
Agreed, you should list the properties here and reference video-interfaces.txt
for the detailed description.
> > +
> > +Example:
> > +
> > +The example describes the connection between the Capture Engine Unit and
> > a
> > +OV7670 image sensor sitting on bus i2c1 with an on-board 24Mhz clock.
> > +
> > +ceu: ceu@e821 {
> > + reg = <0xe821 0x209c>;
> > + compatible = "renesas,renesas-ceu";
> > + interrupts = ;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&vio_pins>;
> > +
> > + status = "okay";
> > +
> > + port {
> > + ceu_in: endpoint {
> > + remote-endpoint = <&ov7670_out>;
> > +
> > + bus-width = <8>;
> > + hsync-active = <1>;
> > + vsync-active = <1>;
> > + pclk-sample = <1>;
> > + data-active = <1>;
> > + };
> > + };
> > +};
> > +
> > +i2c1: i2c@fcfee400 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&i2c1_pins>;
> > +
> > + status = "okay";
> > + clock-frequency = <10>;
> > +
> > + ov7670: camera@21 {
> > + compatible = "ovti,ov7670";
> > + reg = <0x21>;
> > +
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&vio_pins>;
> > +
> > + reset-gpios = <&port3 11 GPIO_ACTIVE_LOW>;
> > + powerdown-gpios = <&port3 12 GPIO_ACTIVE_HIGH>;
> > +
> > + clocks = <&xclk>;
> > + clock-names = "xclk";
> > +
> > + xclk: fixed_clk {
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency = <2400>;
> > + };
>
> What's the purpose of the fixed_clk node here?
The sensor is clocked by a 24MHz oscillator. The clock isn't provided by the
sensor, so it should be located at the root of the device tree, not as a child
of the sensor DT node.
> > +
> > + port {
> > + ov7670_out: endpoint {
> > + remote-endpoint = <&ceu_in>;
> > +
> > + bus-width = <8>;
> > + hsync-active = <1>;
> > + vsync-active = <1>;
> > + pclk-sample = <1>;
> > + data-active = <1>;
> > + };
> > + };
> > + };
--
Regards,
Laurent Pinchart
Urgent Message.
Dear Friend, How are you with your family? I hope fine. I'm happy to inform you about my success in getting those funds transferred under the cooperation of a new partner from India, Presently I’m in India, meanwhile I didn't forget your past efforts to assist me in transferring those funds despite that it failed us some how. Now contact my secretary in Benin Republic West Africa through her e-mail id (lucynn...@hotmail.fr) ask her to send you the ATM CARD worth’s sum of ($250,000.00 US Dollars) which I kept for your compensation for all the past efforts and attempts to assist me in this transaction. so feel free and get in touch with my secretary Ms. Lucy Nnani she will send the ATM CARD to you. Regards, Samuel Amar.
Re: [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
Hi Dhaval, Thank you for the patch. On Friday, 8 December 2017 14:35:37 EET Dhaval Shah wrote: > SPDX-License-Identifier is used for the Xilinx Video IP and > related drivers. > > Signed-off-by: Dhaval Shah > --- > drivers/media/platform/xilinx/xilinx-dma.c | 5 + > drivers/media/platform/xilinx/xilinx-dma.h | 5 + > drivers/media/platform/xilinx/xilinx-tpg.c | 5 + > drivers/media/platform/xilinx/xilinx-vip.c | 5 + > drivers/media/platform/xilinx/xilinx-vip.h | 5 + > drivers/media/platform/xilinx/xilinx-vipp.c | 5 + > drivers/media/platform/xilinx/xilinx-vipp.h | 5 + > drivers/media/platform/xilinx/xilinx-vtc.c | 5 + > drivers/media/platform/xilinx/xilinx-vtc.h | 5 + How about addressing drivers/media/platform/xilinx/Makefile, drivers/media/ platform/xilinx/Kconfig and include/dt-bindings/media/xilinx-vip.h as well ? If you're fine with that I can make the change when applying, there's no need to resubmit the patch. -- Regards, Laurent Pinchart
Re: [PATCH] media: xilinx-video: fix bad of_node_put() on endpoint error
Hi Akinobu,
Thank you for the patch.
On Thursday, 12 October 2017 19:04:44 EET Akinobu Mita wrote:
> When iterating through all endpoints using of_graph_get_next_endpoint(),
> the refcount of the returned endpoint node is incremented and the refcount
> of the node which is passed as previous endpoint is decremented.
>
> So the caller doesn't need to call of_node_put() for each iterated node
> except for error exit paths. Otherwise we get "OF: ERROR: Bad
> of_node_put() on ..." messages.
>
> Cc: Hyun Kwon
> Cc: Laurent Pinchart
> Signed-off-by: Akinobu Mita
Reviewed-by: Laurent Pinchart
and applied to my tree.
> ---
> drivers/media/platform/xilinx/xilinx-vipp.c | 16
> 1 file changed, 4 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/platform/xilinx/xilinx-vipp.c
> b/drivers/media/platform/xilinx/xilinx-vipp.c index ebfdf33..e5c80c9 100644
> --- a/drivers/media/platform/xilinx/xilinx-vipp.c
> +++ b/drivers/media/platform/xilinx/xilinx-vipp.c
> @@ -76,20 +76,16 @@ static int xvip_graph_build_one(struct
> xvip_composite_device *xdev, struct xvip_graph_entity *ent;
> struct v4l2_fwnode_link link;
> struct device_node *ep = NULL;
> - struct device_node *next;
> int ret = 0;
>
> dev_dbg(xdev->dev, "creating links for entity %s\n", local->name);
>
> while (1) {
> /* Get the next endpoint and parse its link. */
> - next = of_graph_get_next_endpoint(entity->node, ep);
> - if (next == NULL)
> + ep = of_graph_get_next_endpoint(entity->node, ep);
> + if (ep == NULL)
> break;
>
> - of_node_put(ep);
> - ep = next;
> -
> dev_dbg(xdev->dev, "processing endpoint %pOF\n", ep);
>
> ret = v4l2_fwnode_parse_link(of_fwnode_handle(ep), &link);
> @@ -200,7 +196,6 @@ static int xvip_graph_build_dma(struct
> xvip_composite_device *xdev) struct xvip_graph_entity *ent;
> struct v4l2_fwnode_link link;
> struct device_node *ep = NULL;
> - struct device_node *next;
> struct xvip_dma *dma;
> int ret = 0;
>
> @@ -208,13 +203,10 @@ static int xvip_graph_build_dma(struct
> xvip_composite_device *xdev)
>
> while (1) {
> /* Get the next endpoint and parse its link. */
> - next = of_graph_get_next_endpoint(node, ep);
> - if (next == NULL)
> + ep = of_graph_get_next_endpoint(node, ep);
> + if (ep == NULL)
> break;
>
> - of_node_put(ep);
> - ep = next;
> -
> dev_dbg(xdev->dev, "processing endpoint %pOF\n", ep);
>
> ret = v4l2_fwnode_parse_link(of_fwnode_handle(ep), &link);
--
Regards,
Laurent Pinchart
[PATCH] tuners: tda8290: reduce stack usage with kasan
With CONFIG_KASAN enabled, we get a relatively large stack frame in one function
drivers/media/tuners/tda8290.c: In function 'tda8290_set_params':
drivers/media/tuners/tda8290.c:310:1: warning: the frame size of 1520 bytes is
larger than 1024 bytes [-Wframe-larger-than=]
With CONFIG_KASAN_EXTRA this goes up to
drivers/media/tuners/tda8290.c: In function 'tda8290_set_params':
drivers/media/tuners/tda8290.c:310:1: error: the frame size of 3200 bytes is
larger than 3072 bytes [-Werror=frame-larger-than=]
We can significantly reduce this by marking local arrays as 'static const', and
this should result in better compiled code for everyone.
I have another patch for the same symptom to patch tuner_i2c_xfer_*, and we
actually want both of them.
Signed-off-by: Arnd Bergmann
---
drivers/media/tuners/tda8290.c | 76 ++
1 file changed, 39 insertions(+), 37 deletions(-)
diff --git a/drivers/media/tuners/tda8290.c b/drivers/media/tuners/tda8290.c
index a59c567c55d6..19854221b72d 100644
--- a/drivers/media/tuners/tda8290.c
+++ b/drivers/media/tuners/tda8290.c
@@ -63,8 +63,8 @@ static int tda8290_i2c_bridge(struct dvb_frontend *fe, int
close)
{
struct tda8290_priv *priv = fe->analog_demod_priv;
- unsigned char enable[2] = { 0x21, 0xC0 };
- unsigned char disable[2] = { 0x21, 0x00 };
+ static unsigned char enable[2] = { 0x21, 0xC0 };
+ static unsigned char disable[2] = { 0x21, 0x00 };
unsigned char *msg;
if (close) {
@@ -84,9 +84,9 @@ static int tda8295_i2c_bridge(struct dvb_frontend *fe, int
close)
{
struct tda8290_priv *priv = fe->analog_demod_priv;
- unsigned char enable[2] = { 0x45, 0xc1 };
- unsigned char disable[2] = { 0x46, 0x00 };
- unsigned char buf[3] = { 0x45, 0x01, 0x00 };
+ static unsigned char enable[2] = { 0x45, 0xc1 };
+ static unsigned char disable[2] = { 0x46, 0x00 };
+ static unsigned char buf[3] = { 0x45, 0x01, 0x00 };
unsigned char *msg;
if (close) {
@@ -178,24 +178,24 @@ static void tda8290_set_params(struct dvb_frontend *fe,
{
struct tda8290_priv *priv = fe->analog_demod_priv;
- unsigned char soft_reset[] = { 0x00, 0x00 };
+ static unsigned char soft_reset[] = { 0x00, 0x00 };
unsigned char easy_mode[] = { 0x01, priv->tda8290_easy_mode };
- unsigned char expert_mode[] = { 0x01, 0x80 };
- unsigned char agc_out_on[] = { 0x02, 0x00 };
- unsigned char gainset_off[] = { 0x28, 0x14 };
- unsigned char if_agc_spd[] = { 0x0f, 0x88 };
- unsigned char adc_head_6[] = { 0x05, 0x04 };
- unsigned char adc_head_9[] = { 0x05, 0x02 };
- unsigned char adc_head_12[] = { 0x05, 0x01 };
- unsigned char pll_bw_nom[] = { 0x0d, 0x47 };
- unsigned char pll_bw_low[] = { 0x0d, 0x27 };
- unsigned char gainset_2[] = { 0x28, 0x64 };
- unsigned char agc_rst_on[] = { 0x0e, 0x0b };
- unsigned char agc_rst_off[] = { 0x0e, 0x09 };
- unsigned char if_agc_set[] = { 0x0f, 0x81 };
- unsigned char addr_adc_sat = 0x1a;
- unsigned char addr_agc_stat = 0x1d;
- unsigned char addr_pll_stat = 0x1b;
+ static unsigned char expert_mode[] = { 0x01, 0x80 };
+ static unsigned char agc_out_on[] = { 0x02, 0x00 };
+ static unsigned char gainset_off[] = { 0x28, 0x14 };
+ static unsigned char if_agc_spd[] = { 0x0f, 0x88 };
+ static unsigned char adc_head_6[] = { 0x05, 0x04 };
+ static unsigned char adc_head_9[] = { 0x05, 0x02 };
+ static unsigned char adc_head_12[] = { 0x05, 0x01 };
+ static unsigned char pll_bw_nom[] = { 0x0d, 0x47 };
+ static unsigned char pll_bw_low[] = { 0x0d, 0x27 };
+ static unsigned char gainset_2[] = { 0x28, 0x64 };
+ static unsigned char agc_rst_on[] = { 0x0e, 0x0b };
+ static unsigned char agc_rst_off[] = { 0x0e, 0x09 };
+ static unsigned char if_agc_set[] = { 0x0f, 0x81 };
+ static unsigned char addr_adc_sat = 0x1a;
+ static unsigned char addr_agc_stat = 0x1d;
+ static unsigned char addr_pll_stat = 0x1b;
unsigned char adc_sat, agc_stat,
pll_stat;
int i;
@@ -468,9 +468,9 @@ static void tda8290_standby(struct dvb_frontend *fe)
{
struct tda8290_priv *priv = fe->analog_demod_priv;
- unsigned char cb1[] = { 0x30, 0xD0 };
- unsigned char tda8290_standby[] = { 0x00, 0x02 };
- unsigned char tda8290_agc_tri[] = { 0x02, 0x20 };
+ static unsigned char cb1[] = { 0x30, 0xD0 };
+ static unsigned char tda8290_standby[] = { 0x00, 0x02 };
+ static unsigned char tda8290_agc_tri[] = { 0x02, 0x20 };
struct i2c_msg msg = {.addr = priv->tda827x_addr, .flags=0, .buf=cb1,
.len = 2};
if (fe->ops.analog_ops.i2c_gate_ctrl)
@@ -495,9 +495,9 @@ static void tda8290_init_if(struct dvb_frontend *fe)
{
struct tda8290_priv *priv = fe->ana
[PATCH] em28xx: split up em28xx_dvb_init to reduce stack size
With CONFIG_KASAN, the init function uses a large amount of kernel stack:
drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init.part.4':
drivers/media/usb/em28xx/em28xx-dvb.c:2061:1: error: the frame size of 3232
bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
Using gcc-7 with -fsanitize-address-use-after-scope makes this even worse:
drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init':
drivers/media/usb/em28xx/em28xx-dvb.c:2069:1: error: the frame size of 4280
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
By splitting out each part of the switch/case statement that has its own local
variables into a separate function, no single one of them uses more than 500
bytes,
and with a noinline_for_stack annotation we can ensure that they are not merged
back together.
Signed-off-by: Arnd Bergmann
---
drivers/media/usb/em28xx/em28xx-dvb.c | 947 ++
1 file changed, 508 insertions(+), 439 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 9950a740e04e..6665885dbaa7 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -934,7 +934,7 @@ static struct lgdt3306a_config
hauppauge_01595_lgdt3306a_config = {
/* -- */
-static int em28xx_attach_xc3028(u8 addr, struct em28xx *dev)
+static noinline_for_stack int em28xx_attach_xc3028(u8 addr, struct em28xx *dev)
{
struct dvb_frontend *fe;
struct xc2028_config cfg;
@@ -1126,6 +1126,492 @@ static void em28xx_unregister_dvb(struct em28xx_dvb
*dvb)
dvb_unregister_adapter(&dvb->adapter);
}
+static noinline_for_stack int em28174_dvb_init_pctv_460e(struct em28xx *dev)
+{
+ struct em28xx_dvb *dvb = dev->dvb;
+ struct i2c_client *client;
+ struct i2c_board_info board_info;
+ struct tda10071_platform_data tda10071_pdata = {};
+ struct a8293_platform_data a8293_pdata = {};
+ int result;
+
+ /* attach demod + tuner combo */
+ tda10071_pdata.clk = 40444000, /* 40.444 MHz */
+ tda10071_pdata.i2c_wr_max = 64,
+ tda10071_pdata.ts_mode = TDA10071_TS_SERIAL,
+ tda10071_pdata.pll_multiplier = 20,
+ tda10071_pdata.tuner_i2c_addr = 0x14,
+ memset(&board_info, 0, sizeof(board_info));
+ strlcpy(board_info.type, "tda10071_cx24118", I2C_NAME_SIZE);
+ board_info.addr = 0x55;
+ board_info.platform_data = &tda10071_pdata;
+ request_module("tda10071");
+ client = i2c_new_device(&dev->i2c_adap[dev->def_i2c_bus], &board_info);
+ if (client == NULL || client->dev.driver == NULL) {
+ result = -ENODEV;
+ goto out_free;
+ }
+ if (!try_module_get(client->dev.driver->owner)) {
+ i2c_unregister_device(client);
+ result = -ENODEV;
+ goto out_free;
+ }
+ dvb->fe[0] = tda10071_pdata.get_dvb_frontend(client);
+ dvb->i2c_client_demod = client;
+
+ /* attach SEC */
+ a8293_pdata.dvb_frontend = dvb->fe[0];
+ memset(&board_info, 0, sizeof(board_info));
+ strlcpy(board_info.type, "a8293", I2C_NAME_SIZE);
+ board_info.addr = 0x08;
+ board_info.platform_data = &a8293_pdata;
+ request_module("a8293");
+ client = i2c_new_device(&dev->i2c_adap[dev->def_i2c_bus], &board_info);
+ if (client == NULL || client->dev.driver == NULL) {
+ module_put(dvb->i2c_client_demod->dev.driver->owner);
+ i2c_unregister_device(dvb->i2c_client_demod);
+ result = -ENODEV;
+ goto out_free;
+ }
+ if (!try_module_get(client->dev.driver->owner)) {
+ i2c_unregister_device(client);
+ module_put(dvb->i2c_client_demod->dev.driver->owner);
+ i2c_unregister_device(dvb->i2c_client_demod);
+ result = -ENODEV;
+ goto out_free;
+ }
+ dvb->i2c_client_sec = client;
+ result = 0;
+out_free:
+ return result;
+}
+
+static noinline_for_stack int em28178_dvb_init_pctv_461e(struct em28xx *dev)
+{
+ struct em28xx_dvb *dvb = dev->dvb;
+ struct i2c_client *client;
+ struct i2c_adapter *i2c_adapter;
+ struct i2c_board_info board_info;
+ struct m88ds3103_platform_data m88ds3103_pdata = {};
+ struct ts2020_config ts2020_config = {};
+ struct a8293_platform_data a8293_pdata = {};
+ int result;
+
+ /* attach demod */
+ m88ds3103_pdata.clk = 2700;
+ m88ds3103_pdata.i2c_wr_max = 33;
+ m88ds3103_pdata.ts_mode = M88DS3103_TS_PARALLEL;
+ m88ds3103_pdata.ts_clk = 16000;
+ m88ds3103_pdata.ts_clk_pol = 1;
+ m88ds3103_pdata.agc = 0x99;
+ memset(&board_info, 0, sizeof(board_info));
+ strlcpy(board_info.type, "m88ds3103", I2C_NAME_SIZE);
+ board_info.addr = 0x68;
Seasons greetings
I am Mr.Sheng Li Hung, from china I got your information while search for a reliable person, I have a very profitable business proposition for you and i can assure you that you will not regret been part of this mutual beneficial transaction after completion. Kindly get back to me for more details on this email id: shengl...@hotmail.com Thanks Sheng Li Hung
[PATCH 2/2] usb: gadget: webcam: fix V4L2 Kconfig dependency
Configuring the USB_G_WEBCAM driver as built-in leads to a link error when CONFIG_VIDEO_V4L2 is a loadable module: drivers/usb/gadget/function/f_uvc.o: In function `uvc_function_setup': f_uvc.c:(.text+0xfe): undefined reference to `v4l2_event_queue' drivers/usb/gadget/function/f_uvc.o: In function `uvc_function_ep0_complete': f_uvc.c:(.text+0x188): undefined reference to `v4l2_event_queue' This changes the Kconfig dependency to disallow that configuration, and force it to be a module in that case as well. This is apparently a rather old bug, but very hard to trigger even in thousands of randconfig builds. Signed-off-by: Arnd Bergmann --- drivers/usb/gadget/legacy/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/legacy/Kconfig b/drivers/usb/gadget/legacy/Kconfig index 2d80a9d1d5d9..fbd974965399 100644 --- a/drivers/usb/gadget/legacy/Kconfig +++ b/drivers/usb/gadget/legacy/Kconfig @@ -513,7 +513,7 @@ endif # or video class gadget drivers), or specific hardware, here. config USB_G_WEBCAM tristate "USB Webcam Gadget" - depends on VIDEO_DEV + depends on VIDEO_V4L2 select USB_LIBCOMPOSITE select VIDEOBUF2_VMALLOC select USB_F_UVC -- 2.9.0
[PATCH 1/2] usb: gadget: restore tristate-choice for legacy gadgets
One patch that was meant as a cleanup apparently did more than it intended,
allowing all combinations of legacy gadget drivers to be built into the
kernel, and leaving an empty 'choice' statement behind:
drivers/usb/gadget/Kconfig:487:warning: choice default symbol 'USB_ETH' is not
contained in the choice
The description of commit 7a9618a22aad ("usb: gadget: allow to enable legacy
drivers without USB_ETH") was a bit cryptic, as it did not change the
behavior of USB_ETH other than allowing it to be built into the kernel
alongside other legacy gadgets, which is not a valid configuration.
As Felipe explained in the description for commit bc49d1d17dcf ("usb:
gadget: don't couple configfs to legacy gadgets"), the configfs based
gadgets can be freely configured as loadable modules or built-in
drivers, but the legacy gadgets can only be modules if there is more
than one of them, so we require the 'choice' statement here.
This leaves the added USB_GADGET_LEGACY menuconfig symbol in place,
but then restores the 'choice' below it, so we can enforce the
single-legacy-gadget rule as before.
Fixes: 7a9618a22aad ("usb: gadget: allow to enable legacy drivers without
USB_ETH")
Signed-off-by: Arnd Bergmann
---
drivers/usb/gadget/Kconfig| 28
drivers/usb/gadget/legacy/Kconfig | 28
2 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 0a19a76645ad..eab61f552c19 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -482,34 +482,6 @@ config USB_CONFIGFS_F_TCM
Both protocols can work on USB2.0 and USB3.0.
UAS utilizes the USB 3.0 feature called streams support.
-choice
- tristate "USB Gadget precomposed configurations"
- default USB_ETH
- optional
- help
- A Linux "Gadget Driver" talks to the USB Peripheral Controller
- driver through the abstract "gadget" API. Some other operating
- systems call these "client" drivers, of which "class drivers"
- are a subset (implementing a USB device class specification).
- A gadget driver implements one or more USB functions using
- the peripheral hardware.
-
- Gadget drivers are hardware-neutral, or "platform independent",
- except that they sometimes must understand quirks or limitations
- of the particular controllers they work with. For example, when
- a controller doesn't support alternate configurations or provide
- enough of the right types of endpoints, the gadget driver might
- not be able work with that controller, or might need to implement
- a less common variant of a device class protocol.
-
- The available choices each represent a single precomposed USB
- gadget configuration. In the device model, each option contains
- both the device instantiation as a child for a USB gadget
- controller, and the relevant drivers for each function declared
- by the device.
-
-endchoice
-
source "drivers/usb/gadget/legacy/Kconfig"
endif # USB_GADGET
diff --git a/drivers/usb/gadget/legacy/Kconfig
b/drivers/usb/gadget/legacy/Kconfig
index 9570bbeced4f..2d80a9d1d5d9 100644
--- a/drivers/usb/gadget/legacy/Kconfig
+++ b/drivers/usb/gadget/legacy/Kconfig
@@ -21,6 +21,32 @@ menuconfig USB_GADGET_LEGACY
if USB_GADGET_LEGACY
+choice
+ tristate "USB Gadget precomposed configurations"
+ default USB_ETH
+ optional
+ help
+ A Linux "Gadget Driver" talks to the USB Peripheral Controller
+ driver through the abstract "gadget" API. Some other operating
+ systems call these "client" drivers, of which "class drivers"
+ are a subset (implementing a USB device class specification).
+ A gadget driver implements one or more USB functions using
+ the peripheral hardware.
+
+ Gadget drivers are hardware-neutral, or "platform independent",
+ except that they sometimes must understand quirks or limitations
+ of the particular controllers they work with. For example, when
+ a controller doesn't support alternate configurations or provide
+ enough of the right types of endpoints, the gadget driver might
+ not be able work with that controller, or might need to implement
+ a less common variant of a device class protocol.
+
+ The available choices each represent a single precomposed USB
+ gadget configuration. In the device model, each option contains
+ both the device instantiation as a child for a USB gadget
+ controller, and the relevant drivers for each function declared
+ by the device.
+
config USB_ZERO
tristate "Gadget Zero (DEVELOPMENT)"
select USB_LIBCOMPOSITE
@@ -499,4 +525,6 @@ config USB_G_WEBCAM
Say "y" to link the driver statically, or "m" to build
Re: [GIT PULL for v4.15-rc3] media fixes
Hi Linus, Em Fri, 8 Dec 2017 13:28:57 -0800 Linus Torvalds escreveu: > On Fri, Dec 8, 2017 at 7:56 AM, Mauro Carvalho Chehab > wrote: > > > > - The largest amount of fixes in this series is with regards to comments > > that aren't kernel-doc, but start with "/**". A new check added for > > 4.15 makes it to produce a *huge* amount of new warnings (I'm compiling > > here with W=1). Most of the patches in this series fix those. No code > > changes - just comment changes at the source files; > > Guys, this was just pure garbage, and obviously noboduy actually > looked at that shit-for-brains patch. > > There were several idiotic things like this: > > -/** > +/* > > because part of it was apparently generated with some overly stupid > search-and-replace. So when replacing "/**" with "/*", it also just > removed a star from those boxed-in comments. > > In the process that thing also made some of those boxes no longer aligned. > > Now, box comments are stupid anyway, but they become truly > mind-bogglingly pointless when they are then edited like this. Sorry for that. On most patches, the regex was more smart than that, but on a few I had to use a more stupid regex, and used git citool to exclude the hunks like above. Clearly, I missed some such blocks at dvb-frontends/drx* and stating/atomisp drivers. The comments on both drivers need to be reviewed anyway. Both have a large amount of comments using alien formats (doxygen, apparently), like this (before this changeset): /** * \def DRXJ_DEF_I2C_ADDR * \brief Default I2C address of a demodulator instance. */ #define DRXJ_DEF_I2C_ADDR (0x52) Once I tried to cleanup those comments, but there are just too many things there that would require manual fix, requiring a large amount of time to do it manually. Maybe one day I may do it. Also, on several of them (like the above), we don't even have a way to convert to docbook, as docbook currently doesn't allow documenting defines and static vars. > I've pulled this, but dammit, show some amount of sense. We shouldn't > have this kind of pointless noise in the rc series. That pointless > noise may now be hiding the real changes. Thanks for pulling it, and sorry for the noise. Without this series, I was getting 809 lines of bogus warnings (see below), with was preventing me to see new warnings on my incremental builds while applying new patches at the media tree. -- Thanks, Mauro $ make ARCH=i386 CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y W=1 CHECK='' M=drivers/staging/media drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isys/src/isys_stream2mmio_rmgr.c:17: warning: Cannot understand Support for Intel Camera Imaging ISP subsystem. on line 17 - I thought it was a doc line drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/eventq/src/eventq.c:41: warning: Cannot understand * @brief The Host sends the event to the SP. on line 41 - I thought it was a doc line drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/rmgr/src/rmgr.c:17: warning: Cannot understand Support for Intel Camera Imaging ISP subsystem. on line 17 - I thought it was a doc line drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/rmgr/src/rmgr.c:48: warning: Cannot understand * @brief Uninitialize resource pool (host) on line 48 - I thought it was a doc line drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isys/src/virtual_isys.c:17: warning: Cannot understand Support for Intel Camera Imaging ISP subsystem. on line 17 - I thought it was a doc line drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/timer/src/timer.c:17: warning: Cannot understand Support for Intel Camera Imaging ISP subsystem. on line 17 - I thought it was a doc line drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isys/src/ibuf_ctrl_rmgr.c:40: warning: cannot understand function prototype: 'ibuf_rsrc_tibuf_rsrc; ' drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isys/src/isys_init.c:17: warning: Cannot understand Support for Intel Camera Imaging ISP subsystem. on line 17 - I thought it was a doc line drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isys/src/isys_dma_rmgr.c:17: warning: Cannot understand Support for Intel Camera Imaging ISP subsystem. on line 17 - I thought it was a doc line drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isys/src/csi_rx_rmgr.c:17: warning: Cannot understand Support for Intel Camera Imaging ISP subsystem. on line 17 - I thought it was a doc line drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isys/src/rx.c:17: warning: Cannot understand Support for Intel Camera Imaging ISP subsystem. on line 17 - I thought it was a doc line drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/inputfifo/src/inputfifo.c:17: warning: Cannot understand Support for Intel Camera Imaging ISP subsystem. on line 17 - I thought it was a doc line dri
Re: [PATCH v9 0/2] media: ov7740: Add a V4L2 sensor-level driver
On Mon, Dec 11, 2017 at 2:31 AM, Wenyou Yang wrote: > Add a Video4Linux2 sensor-level driver for the OmniVision OV7740 > VGA camera image sensor. > > Changes in v9: > - Use the new SPDX ids. Thank you for this Acked-by: Philippe Ombredanne -- Cordially Philippe Ombredanne
Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
Ping again. Added a CC to Ville whom I inexplicably forgot to add when I sent the v5 patch series. Regards, Hans On 01/12/17 08:23, Hans Verkuil wrote: > Ping! > > I really like to get this in for 4.16 so I can move forward with hooking > this up for nouveau/amd. > > Regards, > > Hans > > On 11/20/2017 12:42 PM, Hans Verkuil wrote: >> This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX >> feature. This patch series is based on the 4.14 mainline release but applies >> as well to drm-next. >> >> This patch series has been tested with my NUC7i5BNK, a Samsung USB-C to >> HDMI adapter and a Club 3D DisplayPort MST Hub + modified UpTab DP-to-HDMI >> adapter (where the CEC pin is wired up). >> >> Please note this comment at the start of drm_dp_cec.c: >> >> -- >> Unfortunately it turns out that we have a chicken-and-egg situation >> here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters >> have a converter chip that supports CEC-Tunneling-over-AUX (usually the >> Parade PS176 or MegaChips MCDP2900), but they do not wire up the CEC pin, >> thus making CEC useless. >> >> Sadly there is no way for this driver to know this. What happens is >> that a /dev/cecX device is created that is isolated and unable to see >> any of the other CEC devices. Quite literally the CEC wire is cut >> (or in this case, never connected in the first place). >> >> I suspect that the reason so few adapters support this is that this >> tunneling protocol was never supported by any OS. So there was no >> easy way of testing it, and no incentive to correctly wire up the >> CEC pin. >> >> Hopefully by creating this driver it will be easier for vendors to >> finally fix their adapters and test the CEC functionality. >> >> I keep a list of known working adapters here: >> >> https://hverkuil.home.xs4all.nl/cec-status.txt >> >> Please mail me (hverk...@xs4all.nl) if you find an adapter that works >> and is not yet listed there. >> >> Note that the current implementation does not support CEC over an MST hub. >> As far as I can see there is no mechanism defined in the DisplayPort >> standard to transport CEC interrupts over an MST device. It might be >> possible to do this through polling, but I have not been able to get that >> to work. >> -- >> >> I really hope that this work will provide an incentive for vendors to >> finally connect the CEC pin. It's a shame that there are so few adapters >> that work (I found only two USB-C to HDMI adapters that work, and no >> (mini-)DP to HDMI adapters at all). >> >> Hopefully if this gets merged there will be an incentive for vendors >> to make adapters where this actually works. It is a very nice feature >> for HTPC boxes. >> >> The main reason why this v5 is delayed by 2 months is due to the fact >> that I needed some dedicated time to investigate what happens when an >> MST hub is in use. It turns out that this is not working. There is no >> mechanism defined in the DisplayPort standard to transport the CEC >> interrupt back up the MST chain. I was actually able to send a CEC >> message but the interrupt that tells when the transmit finished is >> unavailable. >> >> I attempted to implement this via polling, but I got weird errors >> and was not able to read the DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1 >> register. I decided to give up on this for now and just disable CEC >> for DP-to-HDMI adapters after an MST hub. I plan to revisit this >> later since it would be neat to make this work as well. Although it >> might not be possible at all. >> >> If anyone is interested, work-in-progress for this is here: >> >> https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=dp-cec-mst >> >> Note that I removed the Tested-by tag from Carlos Santa due to the >> almost complete rework of the third patch. Carlos, can you test this again? >> >> Regards, >> >> Hans >> >> Changes since v4: >> >> - Updated comment at the start of drm_dp_cec.c >> - Add edid pointer to drm_dp_cec_configure_adapter >> - Reworked the last patch (adding CEC to i915) based on Ville's comments >> and my MST testing: >> - register/unregister CEC in intel_dp_connector_register/unregister >> - add comment and check if connector is registered in long_pulse >> - unregister CEC if an MST 'connector' is detected. >> >> ___ >> dri-devel mailing list >> dri-de...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel >
Re: cron job: media_tree daily build: WARNINGS
Nice! It's working again! Jasmin, thank you for your help, much appreciated! Regards, Hans On 11/12/17 06:03, Hans Verkuil wrote: > 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: Mon Dec 11 05:00:15 CET 2017 > media-tree git hash: 0393e735649dc41358adb7b603bd57dad1ed3260 > media_build git hash: f5a5e5e470d834f9843fee7a7c2ce3e4be610ca7 > v4l-utils git hash: 58803000a99c22dceabfb45bec402e746ce966c3 > gcc version: i686-linux-gcc (GCC) 7.1.0 > sparse version: v0.5.0-3911-g6f737e1f > smatch version: v0.5.0-3911-g6f737e1f > host hardware:x86_64 > host os: 4.13.0-164 > > linux-git-arm-at91: OK > linux-git-arm-davinci: OK > linux-git-arm-multi: OK > linux-git-arm-pxa: OK > linux-git-arm-stm32: 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: WARNINGS > linux-3.12.67-i686: WARNINGS > 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: WARNINGS > linux-3.18.7-i686: WARNINGS > linux-3.19-i686: WARNINGS > linux-4.0.9-i686: WARNINGS > linux-4.1.33-i686: WARNINGS > linux-4.2.8-i686: WARNINGS > linux-4.3.6-i686: WARNINGS > linux-4.4.22-i686: WARNINGS > linux-4.5.7-i686: WARNINGS > linux-4.6.7-i686: WARNINGS > linux-4.7.5-i686: WARNINGS > linux-4.8-i686: OK > linux-4.9.26-i686: OK > linux-4.10.14-i686: OK > linux-4.11-i686: OK > linux-4.12.1-i686: OK > linux-4.13-i686: OK > linux-4.14-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: WARNINGS > linux-3.12.67-x86_64: WARNINGS > 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: WARNINGS > linux-3.18.7-x86_64: WARNINGS > linux-3.19-x86_64: WARNINGS > linux-4.0.9-x86_64: WARNINGS > linux-4.1.33-x86_64: WARNINGS > linux-4.2.8-x86_64: WARNINGS > linux-4.3.6-x86_64: WARNINGS > linux-4.4.22-x86_64: WARNINGS > linux-4.5.7-x86_64: WARNINGS > linux-4.6.7-x86_64: WARNINGS > linux-4.7.5-x86_64: WARNINGS > linux-4.8-x86_64: WARNINGS > linux-4.9.26-x86_64: WARNINGS > linux-4.10.14-x86_64: WARNINGS > linux-4.11-x86_64: WARNINGS > linux-4.12.1-x86_64: WARNINGS > linux-4.13-x86_64: OK > linux-4.14-x86_64: OK > apps: OK > spec-git: OK > smatch: OK > > Detailed results are available here: > > http://www.xs4all.nl/~hverkuil/logs/Monday.log > > Full logs are available here: > > http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 > > The Media Infrastructure API from this daily build is here: > > http://www.xs4all.nl/~hverkuil/spec/index.html >
