Re: [PATCH v2 02/11] media: rkisp1: Add user space ABI definitions
Hi Hans, 2017-11-27 18:26 GMT+08:00 Hans Verkuil : > On 11/24/2017 03:36 AM, Jacob Chen wrote: >> From: Jeffy Chen >> >> Add the header for userspace > > I gather that this effectively documents the metadata? > > I recommend using kernel-doc formatting here. > > One thing I immediately noticed is that these structures will have a > different layout for 32 or 64 architectures. Which is a problem if you compile > for 32 bit on a 64 bit kernel on the rk3399. > Thanks.We didn't even notice that. I will add "__attribute__ ((packed))" to each sturct. > I think you need to be very careful how you define these structures. > > Are these parameters documented in a datasheet? If so, then add a reference > to that datasheet. Is it publicly available or do you need an NDA to get it? > It can't be published, but i will try to add document for each parameters. >> >> Signed-off-by: Jeffy Chen >> Signed-off-by: Jacob Chen >> --- >> include/uapi/linux/rkisp1-config.h | 554 >> + >> 1 file changed, 554 insertions(+) >> create mode 100644 include/uapi/linux/rkisp1-config.h >> >> diff --git a/include/uapi/linux/rkisp1-config.h >> b/include/uapi/linux/rkisp1-config.h >> new file mode 100644 >> index ..a801fbc9ef47 >> --- /dev/null >> +++ b/include/uapi/linux/rkisp1-config.h >> @@ -0,0 +1,554 @@ >> +/* >> + * Rockchip isp1 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. >> + */ >> + >> +#ifndef _UAPI_RKISP1_CONFIG_H >> +#define _UAPI_RKISP1_CONFIG_H >> + >> +#include >> +#include >> + >> +#define CIFISP_MODULE_DPCC (1 << 0) >> +#define CIFISP_MODULE_BLS (1 << 1) >> +#define CIFISP_MODULE_SDG (1 << 2) >> +#define CIFISP_MODULE_HST (1 << 3) >> +#define CIFISP_MODULE_LSC (1 << 4) >> +#define CIFISP_MODULE_AWB_GAIN (1 << 5) >> +#define CIFISP_MODULE_FLT (1 << 6) >> +#define CIFISP_MODULE_BDM (1 << 7) >> +#define CIFISP_MODULE_CTK (1 << 8) >> +#define CIFISP_MODULE_GOC (1 << 9) >> +#define CIFISP_MODULE_CPROC (1 << 10) >> +#define CIFISP_MODULE_AFC (1 << 11) >> +#define CIFISP_MODULE_AWB (1 << 12) >> +#define CIFISP_MODULE_IE(1 << 13) >> +#define CIFISP_MODULE_AEC (1 << 14) >> +#define CIFISP_MODULE_WDR (1 << 15) >> +#define CIFISP_MODULE_DPF (1 << 16) >> +#define CIFISP_MODULE_DPF_STRENGTH (1 << 17) >> + >> +#define CIFISP_CTK_COEFF_MAX0x100 >> +#define CIFISP_CTK_OFFSET_MAX 0x800 >> + >> +#define CIFISP_AE_MEAN_MAX 25 >> +#define CIFISP_HIST_BIN_N_MAX 16 >> +#define CIFISP_AFM_MAX_WINDOWS 3 >> +#define CIFISP_DEGAMMA_CURVE_SIZE 17 >> + >> +#define CIFISP_BDM_MAX_TH 0xFF >> + >> +/* maximum value for horizontal start address */ >> +#define CIFISP_BLS_START_H_MAX 0x0FFF >> +/* maximum value for horizontal stop address */ >> +#define CIFISP_BLS_STOP_H_MAX 0x0FFF >> +/* maximum value for vertical start address */ >> +#define CIFISP_BLS_START_V_MAX 0x0FFF >> +/* maximum value for vertical stop address */ >> +#define CIFISP_BLS_STOP_V_MAX 0x0FFF >> +/* maximum is 2^18 = 262144*/ >> +#define CIFISP_BLS_SAMPLES_MAX 0x0012 >> +/* maximum value for fixed black level */ >> +#define CIFISP_BLS_FIX_SUB_MAX 0x0FF
[PATCH v5 0/2] media: ov7740: Add a V4L2 sensor-level driver
Add a Video4Linux2 sensor-level driver for the OmniVision OV7740 VGA camera image sensor. Changes in v5: - Squash the driver and MAINTAINERS entry patches to one. - Precede the driver patch with the bindings patch. Changes in v4: - Assign 'val' a initial value to avoid warning: 'val' may be used uninitialized. - Rename REG_REG15 to avoid warning: "REG_REG15" redefined. Changes in v3: - Explicitly document the "remote-endpoint" property. - Put the MAINTAINERS change to a separate patch. Changes in v2: - Split off the bindings into a separate patch. - Add a new entry to the MAINTAINERS file. Wenyou Yang (2): media: ov7740: Document device tree bindings media: i2c: Add the ov7740 image sensor driver .../devicetree/bindings/media/i2c/ov7740.txt | 47 + MAINTAINERS|8 + drivers/media/i2c/Kconfig |8 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/ov7740.c | 1220 5 files changed, 1284 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7740.txt create mode 100644 drivers/media/i2c/ov7740.c -- 2.15.0
[PATCH v5 2/2] media: i2c: Add the ov7740 image sensor driver
The ov7740 (color) image sensor is a high performance VGA CMOS image snesor, which supports for output formats: RAW RGB and YUV and image sizes: VGA, and QVGA, CIF and any size smaller. Signed-off-by: Songjun Wu Signed-off-by: Wenyou Yang --- Changes in v5: - Squash the driver and MAINTAINERS entry patches to one. - Precede the driver patch with the bindings patch. Changes in v4: - Assign 'val' a initial value to avoid warning: 'val' may be used uninitialized. - Rename REG_REG15 to avoid warning: "REG_REG15" redefined. Changes in v3: - Put the MAINTAINERS change to a separate patch. Changes in v2: - Split off the bindings into a separate patch. - Add a new entry to the MAINTAINERS file. MAINTAINERS|8 + drivers/media/i2c/Kconfig |8 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/ov7740.c | 1220 4 files changed, 1237 insertions(+) create mode 100644 drivers/media/i2c/ov7740.c diff --git a/MAINTAINERS b/MAINTAINERS index aa71ab52fd76..19086a073ae9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10053,6 +10053,14 @@ S: Maintained F: drivers/media/i2c/ov7670.c F: Documentation/devicetree/bindings/media/i2c/ov7670.txt +OMNIVISION OV7740 SENSOR DRIVER +M: Wenyou Yang +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +S: Maintained +F: drivers/media/i2c/ov7740.c +F: Documentation/devicetree/bindings/media/i2c/ov7740.txt + ONENAND FLASH DRIVER M: Kyungmin Park L: linux-...@lists.infradead.org diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 3c6d6428f525..ac484bb82fae 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -665,6 +665,14 @@ config VIDEO_OV7670 OV7670 VGA camera. It currently only works with the M88ALP01 controller. +config VIDEO_OV7740 + tristate "OmniVision OV7740 sensor support" + depends on I2C && VIDEO_V4L2 + depends on MEDIA_CAMERA_SUPPORT + ---help--- + This is a Video4Linux2 sensor-level driver for the OmniVision + OV7740 VGA camera sensor. + config VIDEO_OV9650 tristate "OmniVision OV9650/OV9652 sensor support" depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 548a9efce966..9b19ec7fcaf4 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_OV5670) += ov5670.o obj-$(CONFIG_VIDEO_OV6650) += ov6650.o obj-$(CONFIG_VIDEO_OV7640) += ov7640.o obj-$(CONFIG_VIDEO_OV7670) += ov7670.o +obj-$(CONFIG_VIDEO_OV7740) += ov7740.o obj-$(CONFIG_VIDEO_OV9650) += ov9650.o obj-$(CONFIG_VIDEO_OV13858) += ov13858.o obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o diff --git a/drivers/media/i2c/ov7740.c b/drivers/media/i2c/ov7740.c new file mode 100644 index ..b2ec015bf3f6 --- /dev/null +++ b/drivers/media/i2c/ov7740.c @@ -0,0 +1,1220 @@ +/* + * Copyright (c) 2017 Microchip Corporation. + * + * 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. + * + * 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. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define REG_OUTSIZE_LSB 0x34 + +/* OV7740 register tables */ +#define REG_GAIN 0x00/* Gain lower 8 bits (rest in vref) */ +#define REG_BGAIN 0x01/* blue gain */ +#define REG_RGAIN 0x02/* red gain */ +#define REG_GGAIN 0x03/* green gain */ +#define REG_REG04 0x04/* analog setting, dont change*/ +#define REG_BAVG 0x05/* b channel average */ +#define REG_GAVG 0x06/* g channel average */ +#define REG_RAVG 0x07/* r channel average */ + +#define REG_REG0C 0x0C/* filp enable */ +#define REG0C_IMG_FLIP 0x80 +#define REG0C_IMG_MIRROR 0x40 + +#define REG_REG0E 0x0E/* blc line */ +#define REG_HAEC 0x0F/* auto exposure cntrl */ +#define REG_AEC0x10/* auto exposure cntrl */ + +#define REG_CLK0x11/* Clock control */ +#define REG_REG55 0x55/* Clock PLL DIV/PreDiv */ + +#define REG_REG12 0x12 + +#define REG_REG13 0x13/* auto/manual AGC, AEC, Write Balance*/ +#define REG13_AEC_EN 0x01 +#define REG13_AGC_EN 0x04 + +#define REG_REG14 0x14 +#define REG_CTRL15 0x15 +#define REG15_GAIN_MSB 0x03 + +#define REG_REG16 0x16 + +#define REG_MIDH 0x1C/* manufacture id byte */ +#define REG_MIDL 0x1D/* manufacture id byre */ +#define
[PATCH v5 1/2] media: ov7740: Document device tree bindings
Add the device tree binding documentation for the ov7740 sensor driver.
Signed-off-by: Wenyou Yang
---
Changes in v5: None
Changes in v4: None
Changes in v3:
- Explicitly document the "remote-endpoint" property.
Changes in v2: None
.../devicetree/bindings/media/i2c/ov7740.txt | 47 ++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7740.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/ov7740.txt
b/Documentation/devicetree/bindings/media/i2c/ov7740.txt
new file mode 100644
index ..af781c3a5f0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov7740.txt
@@ -0,0 +1,47 @@
+* Omnivision OV7740 CMOS image sensor
+
+The Omnivision OV7740 image sensor supports multiple output image
+size, such as VGA, and QVGA, CIF and any size smaller. It also
+supports the RAW RGB and YUV output formats.
+
+The common video interfaces bindings (see video-interfaces.txt) should
+be used to specify link to the image data receiver. The OV7740 device
+node should contain one 'port' child node with an 'endpoint' subnode.
+
+Required Properties:
+- compatible: "ovti,ov7740".
+- reg: I2C slave address of the sensor.
+- clocks: Reference to the xvclk input clock.
+- clock-names: "xvclk".
+
+Optional Properties:
+- reset-gpios: Rreference to the GPIO connected to the reset_b pin,
+ if any. Active low with pull-ip resistor.
+- powerdown-gpios: Reference to the GPIO connected to the pwdn pin,
+ if any. Active high with pull-down resistor.
+
+Endpoint node mandatory properties:
+- remote-endpoint: A phandle to the bus receiver's endpoint node.
+
+Example:
+
+ i2c1: i2c@fc028000 {
+ ov7740: camera@21 {
+ compatible = "ovti,ov7740";
+ reg = <0x21>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sensor_power
&pinctrl_sensor_reset>;
+ clocks = <&isc>;
+ clock-names = "xvclk";
+ assigned-clocks = <&isc>;
+ assigned-clock-rates = <2400>;
+ reset-gpios = <&pioA 43 GPIO_ACTIVE_LOW>;
+ powerdown-gpios = <&pioA 44 GPIO_ACTIVE_HIGH>;
+
+ port {
+ ov7740_0: endpoint {
+ remote-endpoint = <&isc_0>;
+ };
+ };
+ };
+ };
--
2.15.0
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 Nov 28 05:00:23 CET 2017 media-tree git hash:04226916d2360f56d57ad00bc48d2d1854d1e0b0 media_build git hash: 097aaf3e4e4bfdeff130db9697dec1befeb3221b v4l-utils git hash: 45722ce368eec47123e3e7a16bdeeb50dadcc00a gcc version:i686-linux-gcc (GCC) 7.1.0 sparse version: 0.5.1 (Debian: 0.5.1-2) smatch version: v0.5.0-3553-g78b2ea6 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 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: [linux-sunxi] Cedrus driver
Hi Maxime, Il 16/11/2017 14:42, Giulio Benetti ha scritto: Hi, Il 16/11/2017 14:39, Maxime Ripard ha scritto: On Thu, Nov 16, 2017 at 02:17:08PM +0100, Giulio Benetti wrote: Hi Hans, Il 16/11/2017 14:12, Hans Verkuil ha scritto: On 16/11/17 13:57, Giulio Benetti wrote: Il 16/11/2017 13:53, Maxime Ripard ha scritto: On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote: On Thu, Nov 16, 2017 at 11:37:30AM +0100, Giulio Benetti wrote: Il 16/11/2017 11:31, Andreas Baierl ha scritto: Am 16.11.2017 um 11:13 schrieb Giulio Benetti: Hello, Hello, I'm wondering why cedrus https://github.com/FlorentRevest/linux-sunxi-cedrus has never been merged with linux-sunxi sunxi-next. Because it is not ready to be merged. It depends on the v4l2 request API, which was not merged and which is re-worked atm. Also, sunxi-cedrus itself is not in a finished state and is not as feature-complete to be merged. Anyway it might be something for staging... Has there been a [RFC] on the mailing list at all? Where can I find a list of TODOs to get it ready to be merged? Assuming that the request API is in, we'd need to: - Finish the MPEG4 support - Work on more useful codecs (H264 comes to my mind) - Implement the DRM planes support for the custom frame format - Implement the DRM planes support for scaling - Test it on more SoCs Or something along those lines. Lot of work to do Well... If it was fast and easy it would have been done already :) :)) I see it seems to be dead, no commit in 1 year. Yes, because the author did this during an internship, which ended ... Afaik nobody picked up his work yet. That's not entirely true. Some work has been done by Thomas (in CC), especially on the display engine side, but last time we talked his work was not really upstreamable. We will also resume that effort starting next march. Is it possible a preview on a separate Reporitory to start working on now? Expecially to start porting everything done by FlorentRevest to mainline, admitted you've not already done. I'm not sure what you're asking for. Florent's work *was* on mainline. and then they took it off because it was unmantained? You've spoken about Thomas(in CC) not ready, maybe I could help on that if it's public to accelerate. If I'm able to of course, this is my primary concern. Otherwise, in which way can I help improving it to make it accept to linux-sunxi? Starting from Florent's work and porting it to sunxi-next to begin? And after that adding all features you've listed? Tell me what I can do(I repeat, if I'm able to). The bottleneck is that the Request API is not mainlined. We restarted work on it after a meeting a few weeks back where we all agreed on the roadmap so hopefully it will go into mainline Q1 or Q2 next year. That said, you can use Florent's patch series for further development. It should be relatively easy to convert it to the final version of the Request API. Just note that the public API of the final Request API will be somewhat different from the old version Florent's patch series is using. So I'm going to try soon to : 1) adapt that patchset to sunxi-next 2) add A20 support 3) add A33 support 4) after mainlined APIs, merge That sounds good. Thomas already has the support for the A20, and as I was saying, there is someone that is going to work full time on this in a couple monthes on our side. I'll set up a git repo on github so that we can collaborate until the request API is ready. Any news about git repo? When do you plan to do it more or less? Great! Write me when you've got news. Thank you very much! Maxime -- Giulio Benetti R&D Manager & Advanced Research MICRONOVA SRL Sede: Via A. Niedda 3 - 35010 Vigonza (PD) Tel. 049/8931563 - Fax 049/8931346 Cod.Fiscale - P.IVA 02663420285 Capitale Sociale € 26.000 i.v. Iscritta al Reg. Imprese di Padova N. 02663420285 Numero R.E.A. 258642
Re: [PATCH v2 3/3] media: staging: atomisp: fixed some checkpatch integer type warnings.
On 2017-11-27, at 19:09:38 +, Alan Cox wrote: > On Mon, 27 Nov 2017 12:44:50 + Jeremy Sowden wrote: > > Changed the types of some arrays from int16_t to s16 > > Which are the same type, except int16_t is the standard form. > > No point. Righto, so this would be one of those cases in which I should have exercised judgment: checkpatch suggested preferring the kernel's own types, but it wasn't a reason to change existing code. Thanks for the feedback. J.
[GIT PULL FOR v4.16] RC changes
Hi Mauro, This is my big rc-core pull request. In summary: - Teaches ir-kbd-i2c to send raw IR with the zilog microcontroller, tested on PVR-150 (ivtv), HVR-1600 (cx18), HD-PVR (hdpvr). Only driver which supports this hardware not tested is usbpvr2. - Removes lirc_zilog, lirc staging and lirc kapi. This breaks any out of tree lirc drivers. - Introduces lirc mode scancode for transmission using the IR encoders, and receiving full IR protocol information for decoded IR (requires kfifo fix) - Various bugs with the lirc uapi have been fixed (e.g. locking), and now a lirc device can be opened more than once. - Line count is down 1500 and code is cleaner. Thanks, Sean The following changes since commit 04226916d2360f56d57ad00bc48d2d1854d1e0b0: media: usbtv: add a new usbid (2017-11-27 14:49:18 -0500) are available in the Git repository at: git://linuxtv.org/syoung/media_tree.git for-v4.16a for you to fetch changes up to b2c96ba352b5ba1f68d13f24d62cbccdb8faa3be: media: cec: move cec autorepeat handling to rc-core (2017-11-27 21:44:09 +) Arvind Yadav (1): media: winbond-cir: Fix pnp_irq's error checking for wbcir_probe Chunyan Zhang (1): media: rc: Replace timeval with ktime_t in imon.c Sean Young (33): media: rc: i2c: set parent of rc device and improve name media: rc: i2c: use dev_dbg rather hand-rolled debug media: rc: i2c: only poll if the rc device is opened media: merge ir_tx_z8f0811_haup and ir_rx_z8f0811_haup i2c devices media: rc: implement zilog transmitter media: i2c: enable i2c IR for hardware which isn't HD-PVR media: staging: remove lirc_zilog driver media: MAINTAINERS: remove lirc staging area media: lirc: remove LIRCCODE and LIRC_GET_LENGTH media: lirc: implement scancode sending media: lirc: use the correct carrier for scancode transmit media: rc: auto load encoder if necessary media: lirc: lirc interface should not be a raw decoder media: lirc: validate scancode for transmit media: rc: document and fix rc_validate_scancode() media: lirc: merge lirc_dev_fop_ioctl and ir_lirc_ioctl media: lirc: use kfifo rather than lirc_buffer for raw IR media: lirc: move lirc_dev->attached to rc_dev->registered media: lirc: do not call close() or open() on unregistered devices media: lirc: create rc-core open and close lirc functions media: lirc: remove name from lirc_dev media: lirc: remove last remnants of lirc kapi media: lirc: implement reading scancode media: lirc: ensure lirc device receives nec repeats media: lirc: document LIRC_MODE_SCANCODE media: lirc: scancode rc devices should have a lirc device too kfifo: DECLARE_KIFO_PTR(fifo, u64) does not work on arm 32 bit media: rc: move ir-lirc-codec.c contents into lirc_dev.c media: rc: include rather than media: lirc: allow lirc device to be opened more than once media: lirc: improve locking media: imon: auto-config ffdc 30 device media: cec: move cec autorepeat handling to rc-core Documentation/media/kapi/rc-core.rst |5 - Documentation/media/lirc.h.rst.exceptions | 31 + Documentation/media/uapi/rc/lirc-dev-intro.rst | 68 +- Documentation/media/uapi/rc/lirc-func.rst |1 - Documentation/media/uapi/rc/lirc-get-features.rst | 17 +- Documentation/media/uapi/rc/lirc-get-length.rst| 44 - Documentation/media/uapi/rc/lirc-get-rec-mode.rst |5 +- Documentation/media/uapi/rc/lirc-get-send-mode.rst |2 +- Documentation/media/uapi/rc/lirc-read.rst | 15 +- Documentation/media/uapi/rc/lirc-write.rst | 19 +- MAINTAINERS|6 - drivers/media/cec/cec-adap.c | 56 +- drivers/media/cec/cec-core.c | 12 - drivers/media/i2c/ir-kbd-i2c.c | 540 ++- drivers/media/pci/cx18/cx18-cards.h|8 +- drivers/media/pci/cx18/cx18-i2c.c | 13 +- drivers/media/pci/ivtv/ivtv-cards.h| 22 +- drivers/media/pci/ivtv/ivtv-i2c.c | 20 +- drivers/media/pci/saa7134/saa7134-input.c |3 +- drivers/media/rc/Kconfig | 29 +- drivers/media/rc/Makefile |5 +- drivers/media/rc/imon.c| 27 +- drivers/media/rc/ir-jvc-decoder.c |1 + drivers/media/rc/ir-lirc-codec.c | 448 -- drivers/media/rc/ir-mce_kbd-decoder.c | 12 +- drivers/media/rc/ir-nec-decoder.c |1 + drivers/media/rc/ir-rc5-decoder.c |1 + drivers/media/rc/ir-rc6-decoder.c |1 + drivers/media/rc/ir-sanyo-decoder.c|
[PATCH 4/4] staging: fix indentation in atomisp-ov5693
Fix "suspect code indent for conditional statements" issue
Signed-off-by: Riccardo Schirone
---
drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
index 4eeb478ae84b..6eb6afdc730e 100644
--- a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
+++ b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
@@ -776,7 +776,7 @@ static int __ov5693_otp_read(struct v4l2_subdev *sd, u8
*buf)
if ((*b) == 0) {
dev->otp_size = 32;
break;
- } else {
+ } else {
b = buf;
continue;
}
--
2.14.3
[PATCH 3/4] staging: improves comparisons readability in atomisp-ov5693
Fix "Comparisons should place the constant on the right side of the
test" issue.
Signed-off-by: Riccardo Schirone
---
drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
index ecd607b7b005..4eeb478ae84b 100644
--- a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
+++ b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
@@ -764,7 +764,7 @@ static int __ov5693_otp_read(struct v4l2_subdev *sd, u8
*buf)
//pr_debug("BANK[%2d] %02x %02x %02x %02x %02x %02x %02x %02x
%02x %02x %02x %02x %02x %02x %02x %02x\n", i, *b, *(b+1), *(b+2), *(b+3),
*(b+4), *(b+5), *(b+6), *(b+7), *(b+8), *(b+9), *(b+10), *(b+11), *(b+12),
*(b+13), *(b+14), *(b+15));
//Intel OTP map, try to read 320byts first.
- if (21 == i) {
+ if (i == 21) {
if ((*b) == 0) {
dev->otp_size = 320;
break;
@@ -772,7 +772,7 @@ static int __ov5693_otp_read(struct v4l2_subdev *sd, u8
*buf)
b = buf;
continue;
}
- } else if (24 == i) { //if the first 320bytes data
doesn't not exist, try to read the next 32bytes data.
+ } else if (i == 24) { //if the first 320bytes data
doesn't not exist, try to read the next 32bytes data.
if ((*b) == 0) {
dev->otp_size = 32;
break;
@@ -780,7 +780,7 @@ static int __ov5693_otp_read(struct v4l2_subdev *sd, u8
*buf)
b = buf;
continue;
}
- } else if (27 == i) { //if the prvious 32bytes data
doesn't exist, try to read the next 32bytes data again.
+ } else if (i == 27) { //if the prvious 32bytes data
doesn't exist, try to read the next 32bytes data again.
if ((*b) == 0) {
dev->otp_size = 32;
break;
@@ -1351,7 +1351,7 @@ static int __power_up(struct v4l2_subdev *sd)
struct i2c_client *client = v4l2_get_subdevdata(sd);
int ret;
- if (NULL == dev->platform_data) {
+ if (!dev->platform_data) {
dev_err(&client->dev,
"no camera_sensor_platform_data");
return -ENODEV;
@@ -1399,7 +1399,7 @@ static int power_down(struct v4l2_subdev *sd)
int ret = 0;
dev->focus = OV5693_INVALID_CONFIG;
- if (NULL == dev->platform_data) {
+ if (!dev->platform_data) {
dev_err(&client->dev,
"no camera_sensor_platform_data");
return -ENODEV;
--
2.14.3
[PATCH 1/4] staging: add missing blank line after declarations in atomisp-ov5693
Signed-off-by: Riccardo Schirone
---
drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
index 3e7c3851280f..387c65be10f4 100644
--- a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
+++ b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
@@ -82,6 +82,7 @@ static int ad5823_i2c_write(struct i2c_client *client, u8
reg, u8 val)
{
struct i2c_msg msg;
u8 buf[2];
+
buf[0] = reg;
buf[1] = val;
msg.addr = AD5823_VCM_ADDR;
@@ -98,6 +99,7 @@ static int ad5823_i2c_read(struct i2c_client *client, u8 reg,
u8 *val)
{
struct i2c_msg msg[2];
u8 buf[2];
+
buf[0] = reg;
buf[1] = 0;
@@ -228,6 +230,7 @@ static int vcm_detect(struct i2c_client *client)
int i, ret;
struct i2c_msg msg;
u16 data0 = 0, data;
+
for (i = 0; i < 4; i++) {
msg.addr = VCM_ADDR;
msg.flags = I2C_M_RD;
@@ -690,6 +693,7 @@ static long ov5693_s_exposure(struct v4l2_subdev *sd,
/* we should not accept the invalid value below */
if (analog_gain == 0) {
struct i2c_client *client = v4l2_get_subdevdata(sd);
+
v4l2_err(client, "%s: invalid value\n", __func__);
return -EINVAL;
}
@@ -722,6 +726,7 @@ static int __ov5693_otp_read(struct v4l2_subdev *sd, u8
*buf)
int ret;
int i;
u8 *b = buf;
+
dev->otp_size = 0;
for (i = 1; i < OV5693_OTP_BANK_MAX; i++) {
/*set bank NO and OTP read mode. */
@@ -984,6 +989,7 @@ static int ov5693_t_focus_abs(struct v4l2_subdev *sd, s32
value)
static int ov5693_t_focus_rel(struct v4l2_subdev *sd, s32 value)
{
struct ov5693_device *dev = to_ov5693_sensor(sd);
+
return ov5693_t_focus_abs(sd, dev->focus + value);
}
@@ -1033,6 +1039,7 @@ static int ov5693_q_focus_abs(struct v4l2_subdev *sd, s32
*value)
static int ov5693_t_vcm_slew(struct v4l2_subdev *sd, s32 value)
{
struct ov5693_device *dev = to_ov5693_sensor(sd);
+
dev->number_of_steps = value;
dev->vcm_update = true;
return 0;
@@ -1041,6 +1048,7 @@ static int ov5693_t_vcm_slew(struct v4l2_subdev *sd, s32
value)
static int ov5693_t_vcm_timing(struct v4l2_subdev *sd, s32 value)
{
struct ov5693_device *dev = to_ov5693_sensor(sd);
+
dev->number_of_steps = value;
dev->vcm_update = true;
return 0;
@@ -1563,6 +1571,7 @@ static int ov5693_set_fmt(struct v4l2_subdev *sd,
struct camera_mipi_info *ov5693_info = NULL;
int ret = 0;
int idx;
+
if (format->pad)
return -EINVAL;
if (!fmt)
@@ -1599,6 +1608,7 @@ static int ov5693_set_fmt(struct v4l2_subdev *sd,
ret = startup(sd);
if (ret) {
int i = 0;
+
dev_err(&client->dev, "ov5693 startup err, retry to power
up\n");
for (i = 0; i < OV5693_POWER_UP_RETRY_NUM; i++) {
dev_err(&client->dev,
@@ -1655,6 +1665,7 @@ static int ov5693_get_fmt(struct v4l2_subdev *sd,
{
struct v4l2_mbus_framefmt *fmt = &format->format;
struct ov5693_device *dev = to_ov5693_sensor(sd);
+
if (format->pad)
return -EINVAL;
@@ -1818,6 +1829,7 @@ static int ov5693_s_parm(struct v4l2_subdev *sd,
struct v4l2_streamparm *param)
{
struct ov5693_device *dev = to_ov5693_sensor(sd);
+
dev->run_mode = param->parm.capture.capturemode;
mutex_lock(&dev->input_lock);
@@ -1907,6 +1919,7 @@ static int ov5693_remove(struct i2c_client *client)
{
struct v4l2_subdev *sd = i2c_get_clientdata(client);
struct ov5693_device *dev = to_ov5693_sensor(sd);
+
dev_dbg(&client->dev, "ov5693_remove...\n");
dev->platform_data->csi_cfg(sd, 0);
--
2.14.3
[PATCH 0/4] fix some checkpatch style issues in atomisp driver
This patch series fixes some coding style issues reported by checkpatch. It is based on next-20171127. Riccardo Schirone (4): staging: add missing blank line after declarations in atomisp-ov5693 staging: improve comments usage in atomisp-ov5693 staging: improves comparisons readability in atomisp-ov5693 staging: fix indentation in atomisp-ov5693 .../media/atomisp/i2c/ov5693/atomisp-ov5693.c | 63 +++--- 1 file changed, 44 insertions(+), 19 deletions(-) -- 2.14.3
[PATCH 2/4] staging: improve comments usage in atomisp-ov5693
* Fix "Block comments use a trailing */ on a separate line" issue
* Fix "Block comments use * on subsequent lines" issue
Signed-off-by: Riccardo Schirone
---
.../media/atomisp/i2c/ov5693/atomisp-ov5693.c | 38 ++
1 file changed, 25 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
index 387c65be10f4..ecd607b7b005 100644
--- a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
+++ b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
@@ -213,7 +213,8 @@ static int vcm_dw_i2c_write(struct i2c_client *client, u16
data)
return ret == num_msg ? 0 : -EIO;
}
-/* Theory: per datasheet, the two VCMs both allow for a 2-byte read.
+/*
+ * Theory: per datasheet, the two VCMs both allow for a 2-byte read.
* The DW9714 doesn't actually specify what this does (it has a
* two-byte write-only protocol, but specifies the read sequence as
* legal), but it returns the same data (zeroes) always, after an
@@ -224,7 +225,8 @@ static int vcm_dw_i2c_write(struct i2c_client *client, u16
data)
* these) in AD5823 are not pairwise repetitions of the same 16 bit
* word. So all we have to do is sequentially read two bytes at a
* time and see if we detect a difference in any of the first four
- * pairs. */
+ * pairs.
+ */
static int vcm_detect(struct i2c_client *client)
{
int i, ret;
@@ -238,8 +240,10 @@ static int vcm_detect(struct i2c_client *client)
msg.buf = (u8 *)&data;
ret = i2c_transfer(client->adapter, &msg, 1);
- /* DW9714 always fails the first read and returns
-* zeroes for subsequent ones */
+ /*
+* DW9714 always fails the first read and returns
+* zeroes for subsequent ones
+*/
if (i == 0 && ret == -EREMOTEIO) {
data0 = 0;
continue;
@@ -533,9 +537,11 @@ static long __ov5693_set_exposure(struct v4l2_subdev *sd,
int coarse_itg,
hts = ov5693_res[dev->fmt_idx].pixels_per_line;
vts = ov5693_res[dev->fmt_idx].lines_per_frame;
- /*If coarse_itg is larger than 1<<15, can not write to reg directly.
- The way is to write coarse_itg/2 to the reg, meanwhile write 2*hts
- to the reg. */
+ /*
+* If coarse_itg is larger than 1<<15, can not write to reg directly.
+* The way is to write coarse_itg/2 to the reg, meanwhile write 2*hts
+* to the reg.
+*/
if (coarse_itg > (1 << 15)) {
hts = hts * 2;
coarse_itg = (int)coarse_itg / 2;
@@ -880,8 +886,10 @@ static long ov5693_ioctl(struct v4l2_subdev *sd, unsigned
int cmd, void *arg)
return 0;
}
-/* This returns the exposure time being used. This should only be used
- for filling in EXIF data, not for actual image processing. */
+/*
+ * This returns the exposure time being used. This should only be used
+ * for filling in EXIF data, not for actual image processing.
+ */
static int ov5693_q_exposure(struct v4l2_subdev *sd, s32 *value)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
@@ -1301,11 +1309,13 @@ static int power_ctrl(struct v4l2_subdev *sd, bool flag)
if (!dev || !dev->platform_data)
return -ENODEV;
- /* This driver assumes "internal DVDD, PWDNB tied to DOVDD".
+ /*
+* This driver assumes "internal DVDD, PWDNB tied to DOVDD".
* In this set up only gpio0 (XSHUTDN) should be available
* but in some products (for example ECS) gpio1 (PWDNB) is
* also available. If gpio1 is available we emulate it being
-* tied to DOVDD here. */
+* tied to DOVDD here.
+*/
if (flag) {
ret = dev->platform_data->v2p8_ctrl(sd, 1);
dev->platform_data->gpio1_ctrl(sd, 1);
@@ -1944,10 +1954,12 @@ static int ov5693_probe(struct i2c_client *client)
struct acpi_device *adev;
unsigned int i;
- /* Firmware workaround: Some modules use a "secondary default"
+ /*
+* Firmware workaround: Some modules use a "secondary default"
* address of 0x10 which doesn't appear on schematics, and
* some BIOS versions haven't gotten the memo. Work around
-* via config. */
+* via config.
+*/
i2c = gmin_get_var_int(&client->dev, "I2CAddr", -1);
if (i2c != -1) {
dev_info(&client->dev,
--
2.14.3
Re: [PATCH 3/8] [media] solo6x10: use ktime_get_ts64() for time sync
On 27/Nov/2017 14:19, Arnd Bergmann wrote:
> solo6x10 correctly deals with time stamps and will never
> suffer from overflows, but it uses the deprecated 'struct timespec'
> type and 'ktime_get_ts()' interface to read the monotonic clock.
>
> This changes it to use ktime_get_ts64() instead, so we can
> eventually remove ktime_get_ts().
>
> Signed-off-by: Arnd Bergmann
> ---
> drivers/media/pci/solo6x10/solo6x10-core.c | 17 +
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/pci/solo6x10/solo6x10-core.c
> b/drivers/media/pci/solo6x10/solo6x10-core.c
> index ca0873e47bea..19ffd2ed3cc7 100644
> --- a/drivers/media/pci/solo6x10/solo6x10-core.c
> +++ b/drivers/media/pci/solo6x10/solo6x10-core.c
> @@ -47,18 +47,19 @@ MODULE_PARM_DESC(full_eeprom, "Allow access to full 128B
> EEPROM (dangerous)");
>
> static void solo_set_time(struct solo_dev *solo_dev)
> {
> - struct timespec ts;
> + struct timespec64 ts;
>
> - ktime_get_ts(&ts);
> + ktime_get_ts64(&ts);
>
> - solo_reg_write(solo_dev, SOLO_TIMER_SEC, ts.tv_sec);
> - solo_reg_write(solo_dev, SOLO_TIMER_USEC, ts.tv_nsec / NSEC_PER_USEC);
> + /* no overflow because we use monotonic timestamps */
> + solo_reg_write(solo_dev, SOLO_TIMER_SEC, (u32)ts.tv_sec);
> + solo_reg_write(solo_dev, SOLO_TIMER_USEC, (u32)ts.tv_nsec /
> NSEC_PER_USEC);
> }
>
> static void solo_timer_sync(struct solo_dev *solo_dev)
> {
> u32 sec, usec;
> - struct timespec ts;
> + struct timespec64 ts;
> long diff;
>
> if (solo_dev->type != SOLO_DEV_6110)
> @@ -72,11 +73,11 @@ static void solo_timer_sync(struct solo_dev *solo_dev)
> sec = solo_reg_read(solo_dev, SOLO_TIMER_SEC);
> usec = solo_reg_read(solo_dev, SOLO_TIMER_USEC);
>
> - ktime_get_ts(&ts);
> + ktime_get_ts64(&ts);
>
> - diff = (long)ts.tv_sec - (long)sec;
> + diff = (s32)ts.tv_sec - (s32)sec;
> diff = (diff * 100)
> - + ((long)(ts.tv_nsec / NSEC_PER_USEC) - (long)usec);
> + + ((s32)(ts.tv_nsec / NSEC_PER_USEC) - (s32)usec);
>
> if (diff > 1000 || diff < -1000) {
> solo_set_time(solo_dev);
> --
> 2.9.0
>
Signed-off-by: Ismael Luceno
signature.asc
Description: PGP signature
Re: [PATCH/RFC] not use a DiSEqC switch
Em Fri, 24 Nov 2017 10:52:04 +0200
Maksym Veremeyenko escreveu:
> Hi,
>
> there is a code in function *dvbsat_diseqc_set_input*:
>
> [...]
> /* Negative numbers means to not use a DiSEqC switch */
> if (parms->p.sat_number < 0)
> return 0;
> [...]
>
> if it mean /there is no DiSEqC switch/ then LNB's *polarity* and *band*
> settings still should be applied - attached patch fixes that behavior.
>
> if it mean /current DVB is a slave/ i.e. it is connected to LOOP OUT of
> another DVB, so no need to configure anything, then statement above is
> correct and no patches from this email should be applied.
No, it actually means that there's no DiSEqC at all; the LNBf
is a bandstacking one, where different polarities use different
LO, like on those LNBf:
{
.desc = {
.name = N_("Big Dish - Multipoint LNBf"),
.alias = "C-MULT",
},
.freqrange = {
{ 3700, 4200, 5150, 0, POLARIZATION_R },
{ 3700, 4200, 5750, 0, POLARIZATION_L }
},
}, {
.desc = {
.name = N_("BrasilSat Amazonas 1/2 - 2 Oscilators"),
.alias = "AMAZONAS",
},
.freqrange = {
{ 11037, 11360, 9670, 0, POLARIZATION_V },
{ 11780, 12150, 1, 0, POLARIZATION_H },
{ 10950, 11280, 1, 0, POLARIZATION_H },
},
},
The case where the LNBf accepts DiSEqC commands, but there's no
switch will work just fine, as the switch control data will be
silently ignored.
Ok, removing them could reduce a little bit the tuning time, at
the expense of making harder for the user, as he would need to
select between 4 different DiSEqC situations:
- no DiSEqC at all;
- DiSEqC LNbf, no DiSEqC switch;
- DiSEqC LNbf, DiSEqC switch with 2 ports (miniDiSEqC);
- DiSEqC LNbf, DiSEqC switch with 4 ports.
The way the code is, if DiSEqC is selected, it will send both
mini-DiSEqC (if satellite number < 2) and DiSEqC commands, so,
all 3 DiSEqC cases will be covered by just one configuration.
Regards,
Mauro
Re: [PATCH v2 3/3] media: staging: atomisp: fixed some checkpatch integer type warnings.
On Mon, 27 Nov 2017 12:44:50 + Jeremy Sowden wrote: > Changed the types of some arrays from int16_t to s16W Which are the same type, except int16_t is the standard form. No point. Alan
Re: [PATCH v2] [media] staging: atomisp: convert timestamps to ktime_t
On Mon, 27 Nov 2017 16:21:41 +0100 Arnd Bergmann wrote: > timespec overflows in 2038 on 32-bit architectures, and the > getnstimeofday() suffers from possible time jumps, so the > timestamps here are better done using ktime_get(), which has > neither of those problems. > > In case of ov2680, we don't seem to use the timestamp at > all, so I just remove it. > > Signed-off-by: Arnd Bergmann Reviewed-by: Alan Cox
Re: [PATCH v6 0/9] i2c: document DMA handling and add helpers for it
On Wed, Nov 08, 2017 at 10:50:37PM +, Mark Brown wrote: > On Sat, Nov 04, 2017 at 09:20:00PM +0100, Wolfram Sang wrote: > > > While previous versions until v3 tried to magically apply bounce buffers > > when > > needed, it became clear that detecting DMA safe buffers is too fragile. This > > approach is now opt-in, a DMA_SAFE flag needs to be set on an i2c_msg. The > > outcome so far is very convincing IMO. The core additions are simple and > > easy > > to understand. The driver changes for the Renesas IP cores became easy to > > understand, too. > > It would really help a lot of things if there were a way to detect if a > given memory block is DMA safe, having to pass the information around > causes so much pain. I so agree. > > I am still not sure how we can teach regmap this new flag. regmap is a heavy > > user of I2C, so broonie's opinion here would be great to have. The rest > > should > > mostly be updating individual drivers which can be done when needed. > > We pretty much assume everything is DMA safe already, the majority of > transfers go to/from kmalloc()ed scratch buffers so actually are DMA > safe but for bulk transfers we use the caller buffer and there might be > some problem users. So, pretty much the situation I2C was in before this patch set: we pretty much assume DMA safety but there might be problem users. > I can't really think of a particularly good way of > handling it off the top of my head, obviously not setting the flag is > easy but doesn't get the benefit while always using a bounce buffer > would involve lots of unneeded memcpy(). Doing _dmasafe() isn't > particularly appealing either but might be what we end up with. Okay. That sounds you are fine with the approach taken here, in general? Thanks, Wolfram signature.asc Description: PGP signature
[PATCH V3 22/29] [media] atomisp: deprecate pci_get_bus_and_slot()
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function. Since ISP always
uses domain 0, hard-code it in the code when calling the replacement
function pci_get_domain_bus_and_slot().
Signed-off-by: Sinan Kaya
---
drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c | 2 +-
drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
index 663aa91..95b9c7a 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
@@ -1233,7 +1233,7 @@ static int atomisp_pci_probe(struct pci_dev *dev,
isp->pdev = dev;
isp->dev = &dev->dev;
isp->sw_contex.power_state = ATOM_ISP_POWER_UP;
- isp->pci_root = pci_get_bus_and_slot(0, 0);
+ isp->pci_root = pci_get_domain_bus_and_slot(0, 0, 0);
if (!isp->pci_root) {
dev_err(&dev->dev, "Unable to find PCI host\n");
return -ENODEV;
diff --git
a/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
b/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
index 4631b1d..51dcef57 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
@@ -39,7 +39,7 @@ static inline int platform_is(u8 model)
static int intel_mid_msgbus_init(void)
{
- pci_root = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
+ pci_root = pci_get_domain_bus_and_slot(0, 0, PCI_DEVFN(0, 0));
if (!pci_root) {
pr_err("%s: Error: msgbus PCI handle NULL\n", __func__);
return -ENODEV;
--
1.9.1
Re: [PATCH v2 2/4] mm: fail get_vaddr_frames() for filesystem-dax mappings
On Mon, Nov 27, 2017 at 8:15 AM, Jan Kara wrote:
> On Tue 14-11-17 11:56:39, Dan Williams wrote:
>> Until there is a solution to the dma-to-dax vs truncate problem it is
>> not safe to allow V4L2, Exynos, and other frame vector users to create
>> long standing / irrevocable memory registrations against filesytem-dax
>> vmas.
>>
>> Cc: Inki Dae
>> Cc: Seung-Woo Kim
>> Cc: Joonyoung Shim
>> Cc: Kyungmin Park
>> Cc: Mauro Carvalho Chehab
>> Cc: linux-media@vger.kernel.org
>> Cc: Jan Kara
>> Cc: Mel Gorman
>> Cc: Vlastimil Babka
>> Cc: Andrew Morton
>> Cc:
>> Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
>> Signed-off-by: Dan Williams
>
> Makes sense. I'd just note that in principle get_vaddr_frames() is no more
> long-term than get_user_pages(). It is just so that all the users of
> get_vaddr_frames() currently want a long-term reference. Maybe could you
> add here also a comment that the vma_is_fsdax() check is there because all
> users of this function want a long term page reference? With that you can
> add:
Ok, will do.
> Reviewed-by: Jan Kara
Thanks.
Re: [PATCH v2 3/4] [media] v4l2: disable filesystem-dax mapping support
On Tue 14-11-17 11:56:45, Dan Williams wrote:
> V4L2 memory registrations are incompatible with filesystem-dax that
> needs the ability to revoke dma access to a mapping at will, or
> otherwise allow the kernel to wait for completion of DMA. The
> filesystem-dax implementation breaks the traditional solution of
> truncate of active file backed mappings since there is no page-cache
> page we can orphan to sustain ongoing DMA.
>
> If v4l2 wants to support long lived DMA mappings it needs to arrange to
> hold a file lease or use some other mechanism so that the kernel can
> coordinate revoking DMA access when the filesystem needs to truncate
> mappings.
>
> Reported-by: Jan Kara
> Cc: Mauro Carvalho Chehab
> Cc: linux-media@vger.kernel.org
> Cc:
> Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
> Signed-off-by: Dan Williams
Looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> drivers/media/v4l2-core/videobuf-dma-sg.c |5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c
> b/drivers/media/v4l2-core/videobuf-dma-sg.c
> index 0b5c43f7e020..f412429cf5ba 100644
> --- a/drivers/media/v4l2-core/videobuf-dma-sg.c
> +++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
> @@ -185,12 +185,13 @@ static int videobuf_dma_init_user_locked(struct
> videobuf_dmabuf *dma,
> dprintk(1, "init user [0x%lx+0x%lx => %d pages]\n",
> data, size, dma->nr_pages);
>
> - err = get_user_pages(data & PAGE_MASK, dma->nr_pages,
> + err = get_user_pages_longterm(data & PAGE_MASK, dma->nr_pages,
>flags, dma->pages, NULL);
>
> if (err != dma->nr_pages) {
> dma->nr_pages = (err >= 0) ? err : 0;
> - dprintk(1, "get_user_pages: err=%d [%d]\n", err, dma->nr_pages);
> + dprintk(1, "get_user_pages_longterm: err=%d [%d]\n", err,
> + dma->nr_pages);
> return err < 0 ? err : -EINVAL;
> }
> return 0;
>
--
Jan Kara
SUSE Labs, CR
Re: [PATCH v2 2/4] mm: fail get_vaddr_frames() for filesystem-dax mappings
On Tue 14-11-17 11:56:39, Dan Williams wrote:
> Until there is a solution to the dma-to-dax vs truncate problem it is
> not safe to allow V4L2, Exynos, and other frame vector users to create
> long standing / irrevocable memory registrations against filesytem-dax
> vmas.
>
> Cc: Inki Dae
> Cc: Seung-Woo Kim
> Cc: Joonyoung Shim
> Cc: Kyungmin Park
> Cc: Mauro Carvalho Chehab
> Cc: linux-media@vger.kernel.org
> Cc: Jan Kara
> Cc: Mel Gorman
> Cc: Vlastimil Babka
> Cc: Andrew Morton
> Cc:
> Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
> Signed-off-by: Dan Williams
Makes sense. I'd just note that in principle get_vaddr_frames() is no more
long-term than get_user_pages(). It is just so that all the users of
get_vaddr_frames() currently want a long-term reference. Maybe could you
add here also a comment that the vma_is_fsdax() check is there because all
users of this function want a long term page reference? With that you can
add:
Reviewed-by: Jan Kara
Honza
> ---
> mm/frame_vector.c |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/mm/frame_vector.c b/mm/frame_vector.c
> index 72ebec18629c..d2fdbeaadc8b 100644
> --- a/mm/frame_vector.c
> +++ b/mm/frame_vector.c
> @@ -52,6 +52,10 @@ int get_vaddr_frames(unsigned long start, unsigned int
> nr_frames,
> ret = -EFAULT;
> goto out;
> }
> +
> + if (vma_is_fsdax(vma))
> + return -EOPNOTSUPP;
> +
> if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) {
> vec->got_ref = true;
> vec->is_pfns = false;
>
--
Jan Kara
SUSE Labs, CR
Re: [PATCH 0/3] Improve CEC autorepeat handling
On 11/27/2017 10:47 AM, Sean Young wrote:
> Hi Hans,
>
> On Mon, Nov 27, 2017 at 10:13:51AM +0100, Hans Verkuil wrote:
>> On 11/26/2017 12:47 AM, Dmitry Torokhov wrote:
>>> On Fri, Nov 24, 2017 at 11:43:58AM +, Sean Young wrote:
Due to the slowness of the CEC bus, autorepeat handling rather special
on CEC. If the repeated user control pressed message is received, a
keydown repeat should be sent immediately.
>>>
>>> This sounds like you want to have hardware autorepeat combined with
>>> software one. This seems fairly specific to CEC and I do not think that
>>> this should be in input core; but stay in the driver.
>>>
>>> Another option just to decide what common delay for CEC autorepeat is
>>> and rely on the standard autorepeat handling. The benefit is that users
>>> can control the delay before autorepeat kicks in.
>>
>> They are not allowed to. Autorepeat is only allowed to start when a second
>> keydown message arrives within 550 ms as per the spec. After that autorepeat
>> continues as long as keydown messages are received within 550ms from the
>> previous one. The actual REP_PERIOD time is unrelated to the frequency of
>> the CEC messages but should be that of the local system.
>>
>> The thing to remember here is that CEC is slooow (400 bits/s) so you cannot
>> send messages at REP_PERIOD rate. You should see it as messages that tell
>> you to enter/stay in autorepeat mode. Not as actual autorepeat messages.
>>
>>>
By handling this in the input layer, we can remove some ugly code from
cec, which also sends a keyup event after the first keydown, to prevent
autorepeat.
>>>
>>> If driver does not want input core to handle autorepeat (but handle
>>> autorepeat by themselves) they should indicate it by setting appropriate
>>> dev->rep[REP_DELAY] and dev->rep[REP_PERIOD] before calling
>>> input_register_device(). This will let input core know that it should
>>> not setup its autorepeat timer.
>>
>> That only means that I have to setup the autorepeat timer myself, there
>> is no benefit in that :-)
>>
>> Sean, I kind of agree with Dmitry here. The way autorepeat works for CEC
>> is pretty specific to that protocol and unlikely to be needed for other
>> protocols.
>
> That's a valid point, I guess. The only downside is special case handling
> outside the input layer, which would be much simpler in the input layer.
>
>> It is also no big deal to keep knowledge of that within cec-adap.c.
>
> So first of all, the sii8620 uses the CEC protocol as well (see commit
> e25f1f7c94e1 drm/bridge/sii8620: add remote control support), so this
> will have to go into rc-core, not cec-adap.c. There was a discussion about
> some time ago.
>
> The current implementation has an ugly key up event which would be nice
> to do without.
>
>> The only thing that would be nice to have control over is that with CEC
>> userspace shouldn't be able to change REP_DELAY and that REP_DELAY should
>> always be identical to REP_PERIOD. If this can be done easily, then that
>> would be nice, but it's a nice-to-have in my opinion.
>
> The REP_DELAY must be equal to REP_PERIOD seems a bit odd to me. In fact,
> I propose something different. If REP_DELAY != 0 then the input layer
> produces autorepeats as normal. If REP_DELAY == 0, then generate repeats
> on the second key down event.
>
> See patch below.
>
> Thanks,
> Sean
>
> From 3f439e326888a0ab8688d73c4276ac87b4225b1c Mon Sep 17 00:00:00 2001
> From: Sean Young
> Date: Thu, 23 Nov 2017 22:37:10 +
> Subject: [PATCH] media: cec: move cec autorepeat handling to rc-core
>
> CEC autorepeat is different than other protocols. Autorepeat is triggered
> by the first repeated user control pressed CEC message, rather than a
> fixed REP_DELAY.
>
> This change also does away with the KEY_UP event directly after the first
> KEY_DOWN event, which was used to stop autorepeat from starting.
>
> See commit a9a249a2c997 ("media: cec: fix remote control passthrough")
> for the original change.
>
> Signed-off-by: Sean Young
> ---
> drivers/media/cec/cec-adap.c | 56
>
> drivers/media/cec/cec-core.c | 12 --
> drivers/media/rc/rc-main.c | 45 +--
> include/media/cec.h | 5
> include/media/rc-core.h | 3 +++
> 5 files changed, 51 insertions(+), 70 deletions(-)
>
> diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
> index 98f88c43f62c..258a91800963 100644
> --- a/drivers/media/cec/cec-adap.c
> +++ b/drivers/media/cec/cec-adap.c
> @@ -1788,9 +1788,6 @@ static int cec_receive_notify(struct cec_adapter *adap,
> struct cec_msg *msg,
> int la_idx = cec_log_addr2idx(adap, dest_laddr);
> bool from_unregistered = init_laddr == 0xf;
> struct cec_msg tx_cec_msg = { };
> -#ifdef CONFIG_MEDIA_CEC_RC
> - int scancode;
> -#endif
>
> dprintk(2, "%s: %*ph\n", __func__, msg->len, msg->msg);
>
> @@ -1886,
[PATCH v2] [media] vivid: use ktime_t for timestamp calculation
timespec is generally deprecated because of the y2038 overflow.
In vivid, the usage is fine, since we are dealing with monotonic
timestamps, but we can also simplify the code by going to ktime_t.
Using ktime_divns() should be roughly as efficient as the old code,
since the constant 64-bit division gets turned into a multiplication
on modern platforms, and we save multiple 32-bit divisions that can be
expensive e.g. on ARMv7.
Tested-by: Hans Verkuil
Signed-off-by: Arnd Bergmann
---
v2: fix a small mistake in the use_alternates computation
---
drivers/media/platform/vivid/vivid-core.c | 2 +-
drivers/media/platform/vivid/vivid-core.h | 2 +-
drivers/media/platform/vivid/vivid-radio-rx.c | 11 +--
drivers/media/platform/vivid/vivid-radio-tx.c | 8 +++-
drivers/media/platform/vivid/vivid-rds-gen.h | 1 +
5 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/vivid/vivid-core.c
b/drivers/media/platform/vivid/vivid-core.c
index 5f316a5e38db..a091cfd93164 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -995,7 +995,7 @@ static int vivid_create_instance(struct platform_device
*pdev, int inst)
dev->edid_max_blocks = dev->edid_blocks = 2;
memcpy(dev->edid, vivid_hdmi_edid, sizeof(vivid_hdmi_edid));
- ktime_get_ts(&dev->radio_rds_init_ts);
+ dev->radio_rds_init_time = ktime_get();
/* create all controls */
ret = vivid_create_controls(dev, ccs_cap == -1, ccs_out == -1,
no_error_inj,
diff --git a/drivers/media/platform/vivid/vivid-core.h
b/drivers/media/platform/vivid/vivid-core.h
index 5cdf95bdc4d1..d8bff4dcefb7 100644
--- a/drivers/media/platform/vivid/vivid-core.h
+++ b/drivers/media/platform/vivid/vivid-core.h
@@ -510,7 +510,7 @@ struct vivid_dev {
/* Shared between radio receiver and transmitter */
boolradio_rds_loop;
- struct timespec radio_rds_init_ts;
+ ktime_t radio_rds_init_time;
/* CEC */
struct cec_adapter *cec_rx_adap;
diff --git a/drivers/media/platform/vivid/vivid-radio-rx.c
b/drivers/media/platform/vivid/vivid-radio-rx.c
index 47c36c26096b..35fbff490535 100644
--- a/drivers/media/platform/vivid/vivid-radio-rx.c
+++ b/drivers/media/platform/vivid/vivid-radio-rx.c
@@ -38,9 +38,9 @@ ssize_t vivid_radio_rx_read(struct file *file, char __user
*buf,
size_t size, loff_t *offset)
{
struct vivid_dev *dev = video_drvdata(file);
- struct timespec ts;
struct v4l2_rds_data *data = dev->rds_gen.data;
bool use_alternates;
+ ktime_t timestamp;
unsigned blk;
int perc;
int i;
@@ -64,17 +64,16 @@ ssize_t vivid_radio_rx_read(struct file *file, char __user
*buf,
}
retry:
- ktime_get_ts(&ts);
- use_alternates = ts.tv_sec % 10 >= 5;
+ timestamp = ktime_sub(ktime_get(), dev->radio_rds_init_time);
+ blk = ktime_divns(timestamp, VIVID_RDS_NSEC_PER_BLK);
+ use_alternates = (blk % VIVID_RDS_GEN_BLOCKS) & 1;
+
if (dev->radio_rx_rds_last_block == 0 ||
dev->radio_rx_rds_use_alternates != use_alternates) {
dev->radio_rx_rds_use_alternates = use_alternates;
/* Re-init the RDS generator */
vivid_radio_rds_init(dev);
}
- ts = timespec_sub(ts, dev->radio_rds_init_ts);
- blk = ts.tv_sec * 100 + ts.tv_nsec / 1000;
- blk = (blk * VIVID_RDS_GEN_BLOCKS) / 500;
if (blk >= dev->radio_rx_rds_last_block + VIVID_RDS_GEN_BLOCKS)
dev->radio_rx_rds_last_block = blk - VIVID_RDS_GEN_BLOCKS + 1;
diff --git a/drivers/media/platform/vivid/vivid-radio-tx.c
b/drivers/media/platform/vivid/vivid-radio-tx.c
index 0e8025b7b4dd..897b56195ca7 100644
--- a/drivers/media/platform/vivid/vivid-radio-tx.c
+++ b/drivers/media/platform/vivid/vivid-radio-tx.c
@@ -37,7 +37,7 @@ ssize_t vivid_radio_tx_write(struct file *file, const char
__user *buf,
{
struct vivid_dev *dev = video_drvdata(file);
struct v4l2_rds_data *data = dev->rds_gen.data;
- struct timespec ts;
+ ktime_t timestamp;
unsigned blk;
int i;
@@ -58,10 +58,8 @@ ssize_t vivid_radio_tx_write(struct file *file, const char
__user *buf,
dev->radio_tx_rds_owner = file->private_data;
retry:
- ktime_get_ts(&ts);
- ts = timespec_sub(ts, dev->radio_rds_init_ts);
- blk = ts.tv_sec * 100 + ts.tv_nsec / 1000;
- blk = (blk * VIVID_RDS_GEN_BLOCKS) / 500;
+ timestamp = ktime_sub(ktime_get(), dev->radio_rds_init_time);
+ blk = ktime_divns(timestamp, VIVID_RDS_NSEC_PER_BLK);
if (blk - VIVID_RDS_GEN_BLOCKS >= dev->radio_tx_rds_last_block)
dev->radio_tx_rds_last_block = blk - VIVID_RDS_GEN_BLOCKS + 1;
diff --git a/drivers/media/platform/vivid/vivid-rds-gen.h
b/
Re: [PATCH v2] [media] staging: atomisp: convert timestamps to ktime_t
On Mon, 2017-11-27 at 16:21 +0100, Arnd Bergmann wrote:
> timespec overflows in 2038 on 32-bit architectures, and the
> getnstimeofday() suffers from possible time jumps, so the
> timestamps here are better done using ktime_get(), which has
> neither of those problems.
>
> In case of ov2680, we don't seem to use the timestamp at
> all, so I just remove it.
>
Yep,
Reviewed-by: Andy Shevchenko
> Signed-off-by: Arnd Bergmann
> ---
> v2: use min_t() as suggested by Andy Shevchenko
> ---
> drivers/staging/media/atomisp/i2c/ov2680.h| 1 -
> .../staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c | 19
> ---
> drivers/staging/media/atomisp/i2c/ov5693/ov5693.h | 2 +-
> 3 files changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/staging/media/atomisp/i2c/ov2680.h
> b/drivers/staging/media/atomisp/i2c/ov2680.h
> index bf4897347df7..03f75dd80f87 100644
> --- a/drivers/staging/media/atomisp/i2c/ov2680.h
> +++ b/drivers/staging/media/atomisp/i2c/ov2680.h
> @@ -174,7 +174,6 @@ struct ov2680_format {
> struct mutex input_lock;
> struct v4l2_ctrl_handler ctrl_handler;
> struct camera_sensor_platform_data *platform_data;
> - struct timespec timestamp_t_focus_abs;
> int vt_pix_clk_freq_mhz;
> int fmt_idx;
> int run_mode;
> diff --git a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
> b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
> index 3e7c3851280f..9fa25bb8f1ee 100644
> --- a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
> +++ b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
> @@ -973,7 +973,7 @@ static int ov5693_t_focus_abs(struct v4l2_subdev
> *sd, s32 value)
> if (ret == 0) {
> dev->number_of_steps = value - dev->focus;
> dev->focus = value;
> - getnstimeofday(&(dev->timestamp_t_focus_abs));
> + dev->timestamp_t_focus_abs = ktime_get();
> } else
> dev_err(&client->dev,
> "%s: i2c failed. ret %d\n", __func__, ret);
> @@ -993,16 +993,13 @@ static int ov5693_q_focus_status(struct
> v4l2_subdev *sd, s32 *value)
> {
> u32 status = 0;
> struct ov5693_device *dev = to_ov5693_sensor(sd);
> - struct timespec temptime;
> - const struct timespec timedelay = {
> - 0,
> - min((u32)abs(dev->number_of_steps) *
> DELAY_PER_STEP_NS,
> - (u32)DELAY_MAX_PER_STEP_NS),
> - };
> -
> - getnstimeofday(&temptime);
> - temptime = timespec_sub(temptime, (dev-
> >timestamp_t_focus_abs));
> - if (timespec_compare(&temptime, &timedelay) <= 0) {
> + ktime_t temptime;
> + ktime_t timedelay = ns_to_ktime(min_t(u32,
> + abs(dev->number_of_steps) *
> DELAY_PER_STEP_NS,
> + DELAY_MAX_PER_STEP_NS));
> +
> + temptime = ktime_sub(ktime_get(), (dev-
> >timestamp_t_focus_abs));
> + if (ktime_compare(temptime, timedelay) <= 0) {
> status |= ATOMISP_FOCUS_STATUS_MOVING;
> status |= ATOMISP_FOCUS_HP_IN_PROGRESS;
> } else {
> diff --git a/drivers/staging/media/atomisp/i2c/ov5693/ov5693.h
> b/drivers/staging/media/atomisp/i2c/ov5693/ov5693.h
> index 2ea63807c56d..68cfcb4a6c3c 100644
> --- a/drivers/staging/media/atomisp/i2c/ov5693/ov5693.h
> +++ b/drivers/staging/media/atomisp/i2c/ov5693/ov5693.h
> @@ -221,7 +221,7 @@ struct ov5693_device {
> struct v4l2_ctrl_handler ctrl_handler;
>
> struct camera_sensor_platform_data *platform_data;
> - struct timespec timestamp_t_focus_abs;
> + ktime_t timestamp_t_focus_abs;
> int vt_pix_clk_freq_mhz;
> int fmt_idx;
> int run_mode;
--
Andy Shevchenko
Intel Finland Oy
Re: [PATCH 6/8] [media] vivid: use ktime_t for timestamp calculation
On Mon, Nov 27, 2017 at 4:14 PM, Hans Verkuil wrote: >> - ktime_get_ts(&ts); >> - use_alternates = ts.tv_sec % 10 >= 5; >> + timestamp = ktime_sub(ktime_get(), dev->radio_rds_init_time); >> + blk = ktime_divns(timestamp, VIVID_RDS_NSEC_PER_BLK); >> + use_alternates = blk % VIVID_RDS_GEN_BLOCKS; >> + > > Almost right. This last line should be: > > use_alternates = (blk / VIVID_RDS_GEN_BLOCKS) & 1; > > With that in place it works and you can add my: > > Tested-by: Hans Verkuil Makes sense. Sending a fixed version now, thanks a lot for testing! Arnd
[PATCH v2] [media] staging: atomisp: convert timestamps to ktime_t
timespec overflows in 2038 on 32-bit architectures, and the
getnstimeofday() suffers from possible time jumps, so the
timestamps here are better done using ktime_get(), which has
neither of those problems.
In case of ov2680, we don't seem to use the timestamp at
all, so I just remove it.
Signed-off-by: Arnd Bergmann
---
v2: use min_t() as suggested by Andy Shevchenko
---
drivers/staging/media/atomisp/i2c/ov2680.h| 1 -
.../staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c | 19 ---
drivers/staging/media/atomisp/i2c/ov5693/ov5693.h | 2 +-
3 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/ov2680.h
b/drivers/staging/media/atomisp/i2c/ov2680.h
index bf4897347df7..03f75dd80f87 100644
--- a/drivers/staging/media/atomisp/i2c/ov2680.h
+++ b/drivers/staging/media/atomisp/i2c/ov2680.h
@@ -174,7 +174,6 @@ struct ov2680_format {
struct mutex input_lock;
struct v4l2_ctrl_handler ctrl_handler;
struct camera_sensor_platform_data *platform_data;
- struct timespec timestamp_t_focus_abs;
int vt_pix_clk_freq_mhz;
int fmt_idx;
int run_mode;
diff --git a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
index 3e7c3851280f..9fa25bb8f1ee 100644
--- a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
+++ b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
@@ -973,7 +973,7 @@ static int ov5693_t_focus_abs(struct v4l2_subdev *sd, s32
value)
if (ret == 0) {
dev->number_of_steps = value - dev->focus;
dev->focus = value;
- getnstimeofday(&(dev->timestamp_t_focus_abs));
+ dev->timestamp_t_focus_abs = ktime_get();
} else
dev_err(&client->dev,
"%s: i2c failed. ret %d\n", __func__, ret);
@@ -993,16 +993,13 @@ static int ov5693_q_focus_status(struct v4l2_subdev *sd,
s32 *value)
{
u32 status = 0;
struct ov5693_device *dev = to_ov5693_sensor(sd);
- struct timespec temptime;
- const struct timespec timedelay = {
- 0,
- min((u32)abs(dev->number_of_steps) * DELAY_PER_STEP_NS,
- (u32)DELAY_MAX_PER_STEP_NS),
- };
-
- getnstimeofday(&temptime);
- temptime = timespec_sub(temptime, (dev->timestamp_t_focus_abs));
- if (timespec_compare(&temptime, &timedelay) <= 0) {
+ ktime_t temptime;
+ ktime_t timedelay = ns_to_ktime(min_t(u32,
+ abs(dev->number_of_steps) * DELAY_PER_STEP_NS,
+ DELAY_MAX_PER_STEP_NS));
+
+ temptime = ktime_sub(ktime_get(), (dev->timestamp_t_focus_abs));
+ if (ktime_compare(temptime, timedelay) <= 0) {
status |= ATOMISP_FOCUS_STATUS_MOVING;
status |= ATOMISP_FOCUS_HP_IN_PROGRESS;
} else {
diff --git a/drivers/staging/media/atomisp/i2c/ov5693/ov5693.h
b/drivers/staging/media/atomisp/i2c/ov5693/ov5693.h
index 2ea63807c56d..68cfcb4a6c3c 100644
--- a/drivers/staging/media/atomisp/i2c/ov5693/ov5693.h
+++ b/drivers/staging/media/atomisp/i2c/ov5693/ov5693.h
@@ -221,7 +221,7 @@ struct ov5693_device {
struct v4l2_ctrl_handler ctrl_handler;
struct camera_sensor_platform_data *platform_data;
- struct timespec timestamp_t_focus_abs;
+ ktime_t timestamp_t_focus_abs;
int vt_pix_clk_freq_mhz;
int fmt_idx;
int run_mode;
--
2.9.0
Re: [Y2038] [PATCH 7/8] [media] staging: atomisp: convert timestamps to ktime_t
On Mon, Nov 27, 2017 at 4:05 PM, Andy Shevchenko wrote: > On Mon, 2017-11-27 at 14:19 +0100, Arnd Bergmann wrote: >> timespec overflows in 2038 on 32-bit architectures, and the >> getnstimeofday() suffers from possible time jumps, so the >> timestamps here are better done using ktime_get(), which has >> neither of those problems. >> >> In case of ov2680, we don't seem to use the timestamp at >> all, so I just remove it. >> > >> + ktime_t timedelay = ns_to_ktime( >> min((u32)abs(dev->number_of_steps) * >> DELAY_PER_STEP_NS, >> - (u32)DELAY_MAX_PER_STEP_NS), >> - }; >> + (u32)DELAY_MAX_PER_STEP_NS)); > > Since you are touching this, it might make sense to convert to > > min_t(u32, ...) > > ...and locate lines something like: > > ktime_t timeday = ns_to_ktime(min_t(u32, > param1, > param2)); > > From my pov will make readability better. Yes, good idea. Re-sending the patch now. Thanks for taking a look, Arnd
Re: [PATCH 6/8] [media] vivid: use ktime_t for timestamp calculation
Hi Arnd,
On 11/27/2017 02:19 PM, Arnd Bergmann wrote:
> timespec is generally deprecated because of the y2038 overflow.
> In vivid, the usage is fine, since we are dealing with monotonic
> timestamps, but we can also simplify the code by going to ktime_t.
>
> Using ktime_divns() should be roughly as efficient as the old code,
> since the constant 64-bit division gets turned into a multiplication
> on modern platforms, and we save multiple 32-bit divisions that can be
> expensive e.g. on ARMv7.
>
> Signed-off-by: Arnd Bergmann
> ---
> I hope I understood the VIVID_RDS_GEN_BLOCKS calculation right,
> please review carefully.
> ---
> drivers/media/platform/vivid/vivid-core.c | 2 +-
> drivers/media/platform/vivid/vivid-core.h | 2 +-
> drivers/media/platform/vivid/vivid-radio-rx.c | 11 +--
> drivers/media/platform/vivid/vivid-radio-tx.c | 8 +++-
> drivers/media/platform/vivid/vivid-rds-gen.h | 1 +
> 5 files changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/media/platform/vivid/vivid-core.c
> b/drivers/media/platform/vivid/vivid-core.c
> index 5f316a5e38db..a091cfd93164 100644
> --- a/drivers/media/platform/vivid/vivid-core.c
> +++ b/drivers/media/platform/vivid/vivid-core.c
> @@ -995,7 +995,7 @@ static int vivid_create_instance(struct platform_device
> *pdev, int inst)
>
> dev->edid_max_blocks = dev->edid_blocks = 2;
> memcpy(dev->edid, vivid_hdmi_edid, sizeof(vivid_hdmi_edid));
> - ktime_get_ts(&dev->radio_rds_init_ts);
> + dev->radio_rds_init_time = ktime_get();
>
> /* create all controls */
> ret = vivid_create_controls(dev, ccs_cap == -1, ccs_out == -1,
> no_error_inj,
> diff --git a/drivers/media/platform/vivid/vivid-core.h
> b/drivers/media/platform/vivid/vivid-core.h
> index 5cdf95bdc4d1..d8bff4dcefb7 100644
> --- a/drivers/media/platform/vivid/vivid-core.h
> +++ b/drivers/media/platform/vivid/vivid-core.h
> @@ -510,7 +510,7 @@ struct vivid_dev {
>
> /* Shared between radio receiver and transmitter */
> boolradio_rds_loop;
> - struct timespec radio_rds_init_ts;
> + ktime_t radio_rds_init_time;
>
> /* CEC */
> struct cec_adapter *cec_rx_adap;
> diff --git a/drivers/media/platform/vivid/vivid-radio-rx.c
> b/drivers/media/platform/vivid/vivid-radio-rx.c
> index 47c36c26096b..1b96cbd7f2ea 100644
> --- a/drivers/media/platform/vivid/vivid-radio-rx.c
> +++ b/drivers/media/platform/vivid/vivid-radio-rx.c
> @@ -38,9 +38,9 @@ ssize_t vivid_radio_rx_read(struct file *file, char __user
> *buf,
>size_t size, loff_t *offset)
> {
> struct vivid_dev *dev = video_drvdata(file);
> - struct timespec ts;
> struct v4l2_rds_data *data = dev->rds_gen.data;
> bool use_alternates;
> + ktime_t timestamp;
> unsigned blk;
> int perc;
> int i;
> @@ -64,17 +64,16 @@ ssize_t vivid_radio_rx_read(struct file *file, char
> __user *buf,
> }
>
> retry:
> - ktime_get_ts(&ts);
> - use_alternates = ts.tv_sec % 10 >= 5;
> + timestamp = ktime_sub(ktime_get(), dev->radio_rds_init_time);
> + blk = ktime_divns(timestamp, VIVID_RDS_NSEC_PER_BLK);
> + use_alternates = blk % VIVID_RDS_GEN_BLOCKS;
> +
Almost right. This last line should be:
use_alternates = (blk / VIVID_RDS_GEN_BLOCKS) & 1;
With that in place it works and you can add my:
Tested-by: Hans Verkuil
to this patch.
Regards,
Hans
> if (dev->radio_rx_rds_last_block == 0 ||
> dev->radio_rx_rds_use_alternates != use_alternates) {
> dev->radio_rx_rds_use_alternates = use_alternates;
> /* Re-init the RDS generator */
> vivid_radio_rds_init(dev);
> }
> - ts = timespec_sub(ts, dev->radio_rds_init_ts);
> - blk = ts.tv_sec * 100 + ts.tv_nsec / 1000;
> - blk = (blk * VIVID_RDS_GEN_BLOCKS) / 500;
> if (blk >= dev->radio_rx_rds_last_block + VIVID_RDS_GEN_BLOCKS)
> dev->radio_rx_rds_last_block = blk - VIVID_RDS_GEN_BLOCKS + 1;
>
> diff --git a/drivers/media/platform/vivid/vivid-radio-tx.c
> b/drivers/media/platform/vivid/vivid-radio-tx.c
> index 0e8025b7b4dd..897b56195ca7 100644
> --- a/drivers/media/platform/vivid/vivid-radio-tx.c
> +++ b/drivers/media/platform/vivid/vivid-radio-tx.c
> @@ -37,7 +37,7 @@ ssize_t vivid_radio_tx_write(struct file *file, const char
> __user *buf,
> {
> struct vivid_dev *dev = video_drvdata(file);
> struct v4l2_rds_data *data = dev->rds_gen.data;
> - struct timespec ts;
> + ktime_t timestamp;
> unsigned blk;
> int i;
>
> @@ -58,10 +58,8 @@ ssize_t vivid_radio_tx_write(struct file *file, const char
> __user *buf,
> dev->radio_tx_rds_owner = file->private_data;
>
> retry:
> - ktime_get_ts(&ts);
> - ts = timespec_sub(ts, dev->radio_rds_init_ts);
> - blk = ts.tv_sec * 100 + ts.tv_nsec / 1
Re: [PATCH 7/8] [media] staging: atomisp: convert timestamps to ktime_t
On Mon, 2017-11-27 at 14:19 +0100, Arnd Bergmann wrote: > timespec overflows in 2038 on 32-bit architectures, and the > getnstimeofday() suffers from possible time jumps, so the > timestamps here are better done using ktime_get(), which has > neither of those problems. > > In case of ov2680, we don't seem to use the timestamp at > all, so I just remove it. > > + ktime_t timedelay = ns_to_ktime( > min((u32)abs(dev->number_of_steps) * > DELAY_PER_STEP_NS, > - (u32)DELAY_MAX_PER_STEP_NS), > - }; > + (u32)DELAY_MAX_PER_STEP_NS)); Since you are touching this, it might make sense to convert to min_t(u32, ...) ...and locate lines something like: ktime_t timeday = ns_to_ktime(min_t(u32, param1, param2)); >From my pov will make readability better. -- Andy Shevchenko Intel Finland Oy
Re: [PATCH v8 0/5] Synopsys Designware HDMI Video Capture Controller + PHY
Hi Hans, On 27-11-2017 12:05, Hans Verkuil wrote: > Hi Jose, > > Sakari's work was merged. Can you make a v9? Then we can merge this for 4.16. Yeah, I saw that. Unfortunately due to my schedule I don't have the time now to make a v9. I will try to make a new version once possible but I don't know if it will be ready for v4.16 ( and we also need to consider review time ). Best Regards, Jose Miguel Abreu > > Thanks! > > Hans > > On 09/22/2017 02:53 PM, Hans Verkuil wrote: >> Hi Jose, >> >> I'm going to mark this patch series as 'Changes Requested' since it depends >> on >> Sakari's subnotifier work. Once that is accepted I assume you'll make a v9 >> on top >> and then this can hopefully be merged. >> >> Regards, >> >> Hans >> >> On 10/07/17 17:46, Jose Abreu wrote: >>> 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 8 addresses review comments from Rob Herring regarding device tree >>> bindings. >>> >>> I also added one patch for cec.h which is needed to fix build >>> errors/warnings. >>> >>> This series depends on the patch at [1]. >>> >>> This series was tested in a FPGA platform using an embedded platform called >>> ARC AXS101. >>> >>> Jose Abreu (5): >>> [media] cec.h: Add stub function for cec_register_cec_notifier() >>> 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 >>> >>> Cc: Carlos Palminha >>> Cc: Mauro Carvalho Chehab >>> Cc: Hans Verkuil >>> Cc: Rob Herring >>> Cc: Mark Rutland >>> Cc: Sylwester Nawrocki >>> >>> [1] >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.linuxtv.org_patch_41834_&d=DwIC-g&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=tFDR8q-niqA9NmwOe-TrIsUMRsdlCFuhK9BrjgBnrfE&s=LRBhbdZgYuMYDoE4DDs5uwO3BHci_7E4vp77UYn8Duo&e= >>> >>> .../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 | 844 + >>> drivers/media/platform/dwc/dw-hdmi-phy-e405.h | 63 + >>> drivers/media/platform/dwc/dw-hdmi-rx.c| 1823 >>> >>> drivers/media/platform/dwc/dw-hdmi-rx.h| 441 + >>> include/media/cec.h|8 + >>> include/media/dwc/dw-hdmi-phy-pdata.h | 128 ++ >>> include/media/dwc/dw-hdmi-rx-pdata.h | 70 + >>> 13 files changed, 3471 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 >>>
Re: [PATCH v2 04/11] media: rkisp1: add Rockchip MIPI Synopsys DPHY driver
++ Joao, ++ Luis Hi Hans, We will take a look into this. Thanks for pointing this out! Best Regards, Jose Miguel Abreu On 27-11-2017 12:01, Hans Verkuil wrote: > I'm CC-ing Jose Abreu from Synopsys to this. Jose, can you or a colleague take > a look at this as well? > > Jacob, I have some high-level questions first: > > 1) to what extend is this code rockchip-specific as opposed to be more > synopsys-generic? > > 2) I don't quite see how this works when there are two sensors. Is only one > active at a >time? Or are they multiplexed somehow? > > 3) Same as for the previous patch: some more comments would be welcome. > > On 11/24/2017 03:36 AM, Jacob Chen wrote: >> From: Jacob Chen >> >> This commit adds a subdev driver for Rockchip MIPI Synopsys DPHY driver. >> >> The phy driver is kind of independent compare to the other parts, but i'd >> like >> to keep it in rkisp1 driver, unless people want to generalize it >> >> Signed-off-by: Jacob Chen >> Signed-off-by: Shunqian Zheng >> Signed-off-by: Tomasz Figa >> --- >> drivers/media/platform/rockchip/isp1/Makefile | 1 + >> .../media/platform/rockchip/isp1/mipi_dphy_sy.c| 805 >> + >> 2 files changed, 806 insertions(+) >> create mode 100644 drivers/media/platform/rockchip/isp1/mipi_dphy_sy.c >> >> diff --git a/drivers/media/platform/rockchip/isp1/Makefile >> b/drivers/media/platform/rockchip/isp1/Makefile >> index 8f52f959398e..18af64853734 100644 >> --- a/drivers/media/platform/rockchip/isp1/Makefile >> +++ b/drivers/media/platform/rockchip/isp1/Makefile >> @@ -4,4 +4,5 @@ video_rkisp1-objs += rkisp1.o \ >> regs.o \ >> isp_stats.o \ >> isp_params.o \ >> +mipi_dphy_sy.o \ >> capture.o >> diff --git a/drivers/media/platform/rockchip/isp1/mipi_dphy_sy.c >> b/drivers/media/platform/rockchip/isp1/mipi_dphy_sy.c >> new file mode 100644 >> index ..56deff2be6fd >> --- /dev/null >> +++ b/drivers/media/platform/rockchip/isp1/mipi_dphy_sy.c >> @@ -0,0 +1,805 @@ >> +/* >> + * Rockchip MIPI Synopsys DPHY driver >> + * >> + * Copyright (C) 2017 Fuzhou 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 >> + >> +#define RK3288_GRF_SOC_CON6 0x025c >> +#define RK3288_GRF_SOC_CON8 0x0264 >> +#define RK3288_GRF_SOC_CON9 0x0268 >> +#define RK3288_GRF_SOC_CON100x026c >> +#define RK3288_GRF_SOC_CON140x027c >> +#define RK3288_GRF_SOC_STATUS21 0x02d4 >> +#define RK3288_GRF_IO_VSEL 0x0380 >> +#define RK3288_GRF_SOC_CON150x03a4 >> + >> +#define RK3399_GRF_SOC_CON9 0x6224 >> +#define RK3399_GRF_SOC_CON210x6254 >> +#define RK3399_GRF_SOC_CON220x6258 >> +#define RK3399_GRF_SOC_CON230x625c >> +#define RK3399_GRF_SOC_CON240x6260 >> +#define RK3399_GRF_SOC_CON250x6264 >> +#define RK3399_GRF_SOC_STATUS1 0xe2a4 >> + >> +#define CLOCK_LANE_HS_RX_CONTROL0x34 >> +#define LANE0_HS_RX_CONTROL 0x44 >> +#define LANE1_HS_RX_CONTROL 0x54 >> +#define LANE2_HS_RX_CONTROL 0x84 >> +#define LANE3_HS_RX_CONTROL 0x94 >> +#define HS_RX_DATA_LANES_THS_SETTLE__CONTROL0x75 >> + >> +#define HIWORD_UPDATE(val, mask, shift) \ >> +((v
[PATCH 8/8] [media] staging: imx: use ktime_t for timestamps
The imx media driver passes around monotonic timestamps in the deprecated
'timespec' format. This is not a problem for the driver, as they won't
overflow, but moving to either timespec64 or ktime_t is preferred.
I'm picking ktime_t for simplicity here. frame_interval_monitor() is
the main function that changes, as it tries to compare a time interval
in microseconds. The algorithm slightly changes here, to avoid 64-bit
division. The code previously assumed that the error was at most 32-bit
worth of microseconds here, so I'm making the same assumption but add
an explicit test for it.
Signed-off-by: Arnd Bergmann
---
drivers/staging/media/imx/imx-media-csi.c | 8 ++--
drivers/staging/media/imx/imx-media-fim.c | 30 +-
drivers/staging/media/imx/imx-media.h | 2 +-
3 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/media/imx/imx-media-csi.c
b/drivers/staging/media/imx/imx-media-csi.c
index bb1d6dafca83..26994b429cf2 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -207,13 +207,9 @@ static irqreturn_t csi_idmac_eof_interrupt(int irq, void
*dev_id)
goto unlock;
}
- if (priv->fim) {
- struct timespec cur_ts;
-
- ktime_get_ts(&cur_ts);
+ if (priv->fim)
/* call frame interval monitor */
- imx_media_fim_eof_monitor(priv->fim, &cur_ts);
- }
+ imx_media_fim_eof_monitor(priv->fim, ktime_get());
csi_vb2_buf_done(priv);
diff --git a/drivers/staging/media/imx/imx-media-fim.c
b/drivers/staging/media/imx/imx-media-fim.c
index 47275ef803f3..6df189135db8 100644
--- a/drivers/staging/media/imx/imx-media-fim.c
+++ b/drivers/staging/media/imx/imx-media-fim.c
@@ -66,7 +66,7 @@ struct imx_media_fim {
int icap_flags;
int counter;
- struct timespec last_ts;
+ ktime_t last_ts;
unsigned long sum; /* usec */
unsigned long nominal; /* usec */
@@ -147,22 +147,26 @@ static void send_fim_event(struct imx_media_fim *fim,
unsigned long error)
* (presumably random) interrupt latency.
*/
static void frame_interval_monitor(struct imx_media_fim *fim,
- struct timespec *ts)
+ ktime_t timestamp)
{
- unsigned long interval, error, error_avg;
+ long long interval, error;
+ unsigned long error_avg;
bool send_event = false;
- struct timespec diff;
if (!fim->enabled || ++fim->counter <= 0)
goto out_update_ts;
- diff = timespec_sub(*ts, fim->last_ts);
- interval = diff.tv_sec * 1000 * 1000 + diff.tv_nsec / 1000;
- error = abs(interval - fim->nominal);
+ /* max error is less than l00µs, so use 32-bit division or fail */
+ interval = ktime_to_ns(ktime_sub(timestamp, fim->last_ts));
+ error = abs(interval - NSEC_PER_USEC * (u64)fim->nominal);
+ if (error > U32_MAX)
+ error = U32_MAX;
+ else
+ error = abs((u32)error / NSEC_PER_USEC);
if (fim->tolerance_max && error >= fim->tolerance_max) {
dev_dbg(fim->sd->dev,
- "FIM: %lu ignored, out of tolerance bounds\n",
+ "FIM: %llu ignored, out of tolerance bounds\n",
error);
fim->counter--;
goto out_update_ts;
@@ -184,7 +188,7 @@ static void frame_interval_monitor(struct imx_media_fim
*fim,
}
out_update_ts:
- fim->last_ts = *ts;
+ fim->last_ts = timestamp;
if (send_event)
send_fim_event(fim, error_avg);
}
@@ -195,14 +199,14 @@ static void frame_interval_monitor(struct imx_media_fim
*fim,
* to interrupt latency.
*/
static void fim_input_capture_handler(int channel, void *dev_id,
- struct timespec *ts)
+ ktime_t timestamp)
{
struct imx_media_fim *fim = dev_id;
unsigned long flags;
spin_lock_irqsave(&fim->lock, flags);
- frame_interval_monitor(fim, ts);
+ frame_interval_monitor(fim, timestamp);
if (!completion_done(&fim->icap_first_event))
complete(&fim->icap_first_event);
@@ -405,14 +409,14 @@ static int init_fim_controls(struct imx_media_fim *fim)
* the frame_interval_monitor() is called by the input capture event
* callback handler in that case.
*/
-void imx_media_fim_eof_monitor(struct imx_media_fim *fim, struct timespec *ts)
+void imx_media_fim_eof_monitor(struct imx_media_fim *fim, ktime_t timestamp)
{
unsigned long flags;
spin_lock_irqsave(&fim->lock, flags);
if (!icap_enabled(fim))
- frame_interval_monitor(fim, ts);
+ frame_interval_monitor(fim, timestamp);
spin_un
[PATCH 7/8] [media] staging: atomisp: convert timestamps to ktime_t
timespec overflows in 2038 on 32-bit architectures, and the
getnstimeofday() suffers from possible time jumps, so the
timestamps here are better done using ktime_get(), which has
neither of those problems.
In case of ov2680, we don't seem to use the timestamp at
all, so I just remove it.
Signed-off-by: Arnd Bergmann
---
drivers/staging/media/atomisp/i2c/ov2680.h| 1 -
drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c | 15 ++-
drivers/staging/media/atomisp/i2c/ov5693/ov5693.h | 2 +-
3 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/ov2680.h
b/drivers/staging/media/atomisp/i2c/ov2680.h
index bf4897347df7..03f75dd80f87 100644
--- a/drivers/staging/media/atomisp/i2c/ov2680.h
+++ b/drivers/staging/media/atomisp/i2c/ov2680.h
@@ -174,7 +174,6 @@ struct ov2680_format {
struct mutex input_lock;
struct v4l2_ctrl_handler ctrl_handler;
struct camera_sensor_platform_data *platform_data;
- struct timespec timestamp_t_focus_abs;
int vt_pix_clk_freq_mhz;
int fmt_idx;
int run_mode;
diff --git a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
index 3e7c3851280f..a715ea0e4230 100644
--- a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
+++ b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
@@ -973,7 +973,7 @@ static int ov5693_t_focus_abs(struct v4l2_subdev *sd, s32
value)
if (ret == 0) {
dev->number_of_steps = value - dev->focus;
dev->focus = value;
- getnstimeofday(&(dev->timestamp_t_focus_abs));
+ dev->timestamp_t_focus_abs = ktime_get();
} else
dev_err(&client->dev,
"%s: i2c failed. ret %d\n", __func__, ret);
@@ -993,16 +993,13 @@ static int ov5693_q_focus_status(struct v4l2_subdev *sd,
s32 *value)
{
u32 status = 0;
struct ov5693_device *dev = to_ov5693_sensor(sd);
- struct timespec temptime;
- const struct timespec timedelay = {
- 0,
+ ktime_t temptime;
+ ktime_t timedelay = ns_to_ktime(
min((u32)abs(dev->number_of_steps) * DELAY_PER_STEP_NS,
- (u32)DELAY_MAX_PER_STEP_NS),
- };
+ (u32)DELAY_MAX_PER_STEP_NS));
- getnstimeofday(&temptime);
- temptime = timespec_sub(temptime, (dev->timestamp_t_focus_abs));
- if (timespec_compare(&temptime, &timedelay) <= 0) {
+ temptime = ktime_sub(ktime_get(), (dev->timestamp_t_focus_abs));
+ if (ktime_compare(temptime, timedelay) <= 0) {
status |= ATOMISP_FOCUS_STATUS_MOVING;
status |= ATOMISP_FOCUS_HP_IN_PROGRESS;
} else {
diff --git a/drivers/staging/media/atomisp/i2c/ov5693/ov5693.h
b/drivers/staging/media/atomisp/i2c/ov5693/ov5693.h
index 2ea63807c56d..68cfcb4a6c3c 100644
--- a/drivers/staging/media/atomisp/i2c/ov5693/ov5693.h
+++ b/drivers/staging/media/atomisp/i2c/ov5693/ov5693.h
@@ -221,7 +221,7 @@ struct ov5693_device {
struct v4l2_ctrl_handler ctrl_handler;
struct camera_sensor_platform_data *platform_data;
- struct timespec timestamp_t_focus_abs;
+ ktime_t timestamp_t_focus_abs;
int vt_pix_clk_freq_mhz;
int fmt_idx;
int run_mode;
--
2.9.0
[PATCH 6/8] [media] vivid: use ktime_t for timestamp calculation
timespec is generally deprecated because of the y2038 overflow.
In vivid, the usage is fine, since we are dealing with monotonic
timestamps, but we can also simplify the code by going to ktime_t.
Using ktime_divns() should be roughly as efficient as the old code,
since the constant 64-bit division gets turned into a multiplication
on modern platforms, and we save multiple 32-bit divisions that can be
expensive e.g. on ARMv7.
Signed-off-by: Arnd Bergmann
---
I hope I understood the VIVID_RDS_GEN_BLOCKS calculation right,
please review carefully.
---
drivers/media/platform/vivid/vivid-core.c | 2 +-
drivers/media/platform/vivid/vivid-core.h | 2 +-
drivers/media/platform/vivid/vivid-radio-rx.c | 11 +--
drivers/media/platform/vivid/vivid-radio-tx.c | 8 +++-
drivers/media/platform/vivid/vivid-rds-gen.h | 1 +
5 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/vivid/vivid-core.c
b/drivers/media/platform/vivid/vivid-core.c
index 5f316a5e38db..a091cfd93164 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -995,7 +995,7 @@ static int vivid_create_instance(struct platform_device
*pdev, int inst)
dev->edid_max_blocks = dev->edid_blocks = 2;
memcpy(dev->edid, vivid_hdmi_edid, sizeof(vivid_hdmi_edid));
- ktime_get_ts(&dev->radio_rds_init_ts);
+ dev->radio_rds_init_time = ktime_get();
/* create all controls */
ret = vivid_create_controls(dev, ccs_cap == -1, ccs_out == -1,
no_error_inj,
diff --git a/drivers/media/platform/vivid/vivid-core.h
b/drivers/media/platform/vivid/vivid-core.h
index 5cdf95bdc4d1..d8bff4dcefb7 100644
--- a/drivers/media/platform/vivid/vivid-core.h
+++ b/drivers/media/platform/vivid/vivid-core.h
@@ -510,7 +510,7 @@ struct vivid_dev {
/* Shared between radio receiver and transmitter */
boolradio_rds_loop;
- struct timespec radio_rds_init_ts;
+ ktime_t radio_rds_init_time;
/* CEC */
struct cec_adapter *cec_rx_adap;
diff --git a/drivers/media/platform/vivid/vivid-radio-rx.c
b/drivers/media/platform/vivid/vivid-radio-rx.c
index 47c36c26096b..1b96cbd7f2ea 100644
--- a/drivers/media/platform/vivid/vivid-radio-rx.c
+++ b/drivers/media/platform/vivid/vivid-radio-rx.c
@@ -38,9 +38,9 @@ ssize_t vivid_radio_rx_read(struct file *file, char __user
*buf,
size_t size, loff_t *offset)
{
struct vivid_dev *dev = video_drvdata(file);
- struct timespec ts;
struct v4l2_rds_data *data = dev->rds_gen.data;
bool use_alternates;
+ ktime_t timestamp;
unsigned blk;
int perc;
int i;
@@ -64,17 +64,16 @@ ssize_t vivid_radio_rx_read(struct file *file, char __user
*buf,
}
retry:
- ktime_get_ts(&ts);
- use_alternates = ts.tv_sec % 10 >= 5;
+ timestamp = ktime_sub(ktime_get(), dev->radio_rds_init_time);
+ blk = ktime_divns(timestamp, VIVID_RDS_NSEC_PER_BLK);
+ use_alternates = blk % VIVID_RDS_GEN_BLOCKS;
+
if (dev->radio_rx_rds_last_block == 0 ||
dev->radio_rx_rds_use_alternates != use_alternates) {
dev->radio_rx_rds_use_alternates = use_alternates;
/* Re-init the RDS generator */
vivid_radio_rds_init(dev);
}
- ts = timespec_sub(ts, dev->radio_rds_init_ts);
- blk = ts.tv_sec * 100 + ts.tv_nsec / 1000;
- blk = (blk * VIVID_RDS_GEN_BLOCKS) / 500;
if (blk >= dev->radio_rx_rds_last_block + VIVID_RDS_GEN_BLOCKS)
dev->radio_rx_rds_last_block = blk - VIVID_RDS_GEN_BLOCKS + 1;
diff --git a/drivers/media/platform/vivid/vivid-radio-tx.c
b/drivers/media/platform/vivid/vivid-radio-tx.c
index 0e8025b7b4dd..897b56195ca7 100644
--- a/drivers/media/platform/vivid/vivid-radio-tx.c
+++ b/drivers/media/platform/vivid/vivid-radio-tx.c
@@ -37,7 +37,7 @@ ssize_t vivid_radio_tx_write(struct file *file, const char
__user *buf,
{
struct vivid_dev *dev = video_drvdata(file);
struct v4l2_rds_data *data = dev->rds_gen.data;
- struct timespec ts;
+ ktime_t timestamp;
unsigned blk;
int i;
@@ -58,10 +58,8 @@ ssize_t vivid_radio_tx_write(struct file *file, const char
__user *buf,
dev->radio_tx_rds_owner = file->private_data;
retry:
- ktime_get_ts(&ts);
- ts = timespec_sub(ts, dev->radio_rds_init_ts);
- blk = ts.tv_sec * 100 + ts.tv_nsec / 1000;
- blk = (blk * VIVID_RDS_GEN_BLOCKS) / 500;
+ timestamp = ktime_sub(ktime_get(), dev->radio_rds_init_time);
+ blk = ktime_divns(timestamp, VIVID_RDS_NSEC_PER_BLK);
if (blk - VIVID_RDS_GEN_BLOCKS >= dev->radio_tx_rds_last_block)
dev->radio_tx_rds_last_block = blk - VIVID_RDS_GEN_BLOCKS + 1;
diff --git a/drivers/media/platform/vivid/vivid-rds-gen.h
b/
[PATCH 5/8] [media] omap3isp: support 64-bit version of omap3isp_stat_data
C libraries with 64-bit time_t use an incompatible format for
struct omap3isp_stat_data. This changes the kernel code to
support either version, by moving over the normal handling
to the 64-bit variant, and adding compatiblity code to handle
the old binary format with the existing ioctl command code.
Fortunately, the command code includes the size of the structure,
so the difference gets handled automatically. In the process of
eliminating the references to 'struct timeval' from the kernel,
I also change the way the timestamp is generated internally,
basically by open-coding the v4l2_get_timestamp() call.
Signed-off-by: Arnd Bergmann
---
drivers/media/platform/omap3isp/isph3a_aewb.c | 2 ++
drivers/media/platform/omap3isp/isph3a_af.c | 2 ++
drivers/media/platform/omap3isp/isphist.c | 2 ++
drivers/media/platform/omap3isp/ispstat.c | 21 +++--
drivers/media/platform/omap3isp/ispstat.h | 4 +++-
include/uapi/linux/omap3isp.h | 22 ++
6 files changed, 50 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isph3a_aewb.c
b/drivers/media/platform/omap3isp/isph3a_aewb.c
index d44626f20ac6..3c82dea4d375 100644
--- a/drivers/media/platform/omap3isp/isph3a_aewb.c
+++ b/drivers/media/platform/omap3isp/isph3a_aewb.c
@@ -250,6 +250,8 @@ static long h3a_aewb_ioctl(struct v4l2_subdev *sd, unsigned
int cmd, void *arg)
return omap3isp_stat_config(stat, arg);
case VIDIOC_OMAP3ISP_STAT_REQ:
return omap3isp_stat_request_statistics(stat, arg);
+ case VIDIOC_OMAP3ISP_STAT_REQ_TIME32:
+ return omap3isp_stat_request_statistics_time32(stat, arg);
case VIDIOC_OMAP3ISP_STAT_EN: {
unsigned long *en = arg;
return omap3isp_stat_enable(stat, !!*en);
diff --git a/drivers/media/platform/omap3isp/isph3a_af.c
b/drivers/media/platform/omap3isp/isph3a_af.c
index 99bd6cc21d86..4da25c84f0c6 100644
--- a/drivers/media/platform/omap3isp/isph3a_af.c
+++ b/drivers/media/platform/omap3isp/isph3a_af.c
@@ -314,6 +314,8 @@ static long h3a_af_ioctl(struct v4l2_subdev *sd, unsigned
int cmd, void *arg)
return omap3isp_stat_config(stat, arg);
case VIDIOC_OMAP3ISP_STAT_REQ:
return omap3isp_stat_request_statistics(stat, arg);
+ case VIDIOC_OMAP3ISP_STAT_REQ_TIME32:
+ return omap3isp_stat_request_statistics_time32(stat, arg);
case VIDIOC_OMAP3ISP_STAT_EN: {
int *en = arg;
return omap3isp_stat_enable(stat, !!*en);
diff --git a/drivers/media/platform/omap3isp/isphist.c
b/drivers/media/platform/omap3isp/isphist.c
index a4ed5d140d48..d4be3d0e06f9 100644
--- a/drivers/media/platform/omap3isp/isphist.c
+++ b/drivers/media/platform/omap3isp/isphist.c
@@ -435,6 +435,8 @@ static long hist_ioctl(struct v4l2_subdev *sd, unsigned int
cmd, void *arg)
return omap3isp_stat_config(stat, arg);
case VIDIOC_OMAP3ISP_STAT_REQ:
return omap3isp_stat_request_statistics(stat, arg);
+ case VIDIOC_OMAP3ISP_STAT_REQ_TIME32:
+ return omap3isp_stat_request_statistics_time32(stat, arg);
case VIDIOC_OMAP3ISP_STAT_EN: {
int *en = arg;
return omap3isp_stat_enable(stat, !!*en);
diff --git a/drivers/media/platform/omap3isp/ispstat.c
b/drivers/media/platform/omap3isp/ispstat.c
index 47cbc7e3d825..5967dfd0a9f7 100644
--- a/drivers/media/platform/omap3isp/ispstat.c
+++ b/drivers/media/platform/omap3isp/ispstat.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "isp.h"
@@ -237,7 +238,7 @@ static int isp_stat_buf_queue(struct ispstat *stat)
if (!stat->active_buf)
return STAT_NO_BUF;
- v4l2_get_timestamp(&stat->active_buf->ts);
+ ktime_get_ts64(&stat->active_buf->ts);
stat->active_buf->buf_size = stat->buf_size;
if (isp_stat_buf_check_magic(stat, stat->active_buf)) {
@@ -500,7 +501,8 @@ int omap3isp_stat_request_statistics(struct ispstat *stat,
return PTR_ERR(buf);
}
- data->ts = buf->ts;
+ data->ts.tv_sec = buf->ts.tv_sec;
+ data->ts.tv_usec = buf->ts.tv_nsec / NSEC_PER_USEC;
data->config_counter = buf->config_counter;
data->frame_number = buf->frame_number;
data->buf_size = buf->buf_size;
@@ -512,6 +514,21 @@ int omap3isp_stat_request_statistics(struct ispstat *stat,
return 0;
}
+int omap3isp_stat_request_statistics_time32(struct ispstat *stat,
+ struct omap3isp_stat_data_time32 *data)
+{
+ struct omap3isp_stat_data data64;
+ int ret;
+
+ ret = omap3isp_stat_request_statistics(stat, &data64);
+
+ data->ts.tv_sec = data64.ts.tv_sec;
+ data->ts.tv_usec = data64.ts.tv_usec;
+ memcpy(&data->buf, &data64.buf, sizeof(*data) - sizeof(data->ts));
+
+ return ret;
+}
+
/
[PATCH 3/8] [media] solo6x10: use ktime_get_ts64() for time sync
solo6x10 correctly deals with time stamps and will never
suffer from overflows, but it uses the deprecated 'struct timespec'
type and 'ktime_get_ts()' interface to read the monotonic clock.
This changes it to use ktime_get_ts64() instead, so we can
eventually remove ktime_get_ts().
Signed-off-by: Arnd Bergmann
---
drivers/media/pci/solo6x10/solo6x10-core.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/media/pci/solo6x10/solo6x10-core.c
b/drivers/media/pci/solo6x10/solo6x10-core.c
index ca0873e47bea..19ffd2ed3cc7 100644
--- a/drivers/media/pci/solo6x10/solo6x10-core.c
+++ b/drivers/media/pci/solo6x10/solo6x10-core.c
@@ -47,18 +47,19 @@ MODULE_PARM_DESC(full_eeprom, "Allow access to full 128B
EEPROM (dangerous)");
static void solo_set_time(struct solo_dev *solo_dev)
{
- struct timespec ts;
+ struct timespec64 ts;
- ktime_get_ts(&ts);
+ ktime_get_ts64(&ts);
- solo_reg_write(solo_dev, SOLO_TIMER_SEC, ts.tv_sec);
- solo_reg_write(solo_dev, SOLO_TIMER_USEC, ts.tv_nsec / NSEC_PER_USEC);
+ /* no overflow because we use monotonic timestamps */
+ solo_reg_write(solo_dev, SOLO_TIMER_SEC, (u32)ts.tv_sec);
+ solo_reg_write(solo_dev, SOLO_TIMER_USEC, (u32)ts.tv_nsec /
NSEC_PER_USEC);
}
static void solo_timer_sync(struct solo_dev *solo_dev)
{
u32 sec, usec;
- struct timespec ts;
+ struct timespec64 ts;
long diff;
if (solo_dev->type != SOLO_DEV_6110)
@@ -72,11 +73,11 @@ static void solo_timer_sync(struct solo_dev *solo_dev)
sec = solo_reg_read(solo_dev, SOLO_TIMER_SEC);
usec = solo_reg_read(solo_dev, SOLO_TIMER_USEC);
- ktime_get_ts(&ts);
+ ktime_get_ts64(&ts);
- diff = (long)ts.tv_sec - (long)sec;
+ diff = (s32)ts.tv_sec - (s32)sec;
diff = (diff * 100)
- + ((long)(ts.tv_nsec / NSEC_PER_USEC) - (long)usec);
+ + ((s32)(ts.tv_nsec / NSEC_PER_USEC) - (s32)usec);
if (diff > 1000 || diff < -1000) {
solo_set_time(solo_dev);
--
2.9.0
[PATCH 2/8] [media] uvc_video: use ktime_t for timestamps
uvc_video_get_ts() returns a 'struct timespec', but all its users
really want a nanoseconds variable anyway.
Changing the deprecated ktime_get_ts/ktime_get_real_ts to ktime_get
and ktime_get_real simplifies the code noticeably, while keeping
the resulting numbers unchanged.
Signed-off-by: Arnd Bergmann
---
drivers/media/usb/uvc/uvc_video.c | 37 -
drivers/media/usb/uvc/uvcvideo.h | 2 +-
2 files changed, 13 insertions(+), 26 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc/uvc_video.c
index d6bee37cd1b8..f7a919490b2b 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -369,12 +369,12 @@ static int uvc_commit_video(struct uvc_streaming *stream,
* Clocks and timestamps
*/
-static inline void uvc_video_get_ts(struct timespec *ts)
+static inline ktime_t uvc_video_get_time(void)
{
if (uvc_clock_param == CLOCK_MONOTONIC)
- ktime_get_ts(ts);
+ return ktime_get();
else
- ktime_get_real_ts(ts);
+ return ktime_get_real();
}
static void
@@ -386,7 +386,7 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct
uvc_buffer *buf,
bool has_pts = false;
bool has_scr = false;
unsigned long flags;
- struct timespec ts;
+ ktime_t time;
u16 host_sof;
u16 dev_sof;
@@ -436,7 +436,7 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct
uvc_buffer *buf,
stream->clock.last_sof = dev_sof;
host_sof = usb_get_current_frame_number(stream->dev->udev);
- uvc_video_get_ts(&ts);
+ time = uvc_video_get_time();
/* The UVC specification allows device implementations that can't obtain
* the USB frame number to keep their own frame counters as long as they
@@ -473,7 +473,7 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct
uvc_buffer *buf,
sample->dev_stc = get_unaligned_le32(&data[header_size - 6]);
sample->dev_sof = dev_sof;
sample->host_sof = host_sof;
- sample->host_ts = ts;
+ sample->host_time = time;
/* Update the sliding window head and count. */
stream->clock.head = (stream->clock.head + 1) % stream->clock.size;
@@ -613,14 +613,12 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
struct uvc_clock_sample *first;
struct uvc_clock_sample *last;
unsigned long flags;
- struct timespec ts;
+ u64 timestamp;
u32 delta_stc;
u32 y1, y2;
u32 x1, x2;
u32 mean;
u32 sof;
- u32 div;
- u32 rem;
u64 y;
if (!uvc_hw_timestamps_param)
@@ -667,9 +665,8 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
if (x1 == x2)
goto done;
- ts = timespec_sub(last->host_ts, first->host_ts);
y1 = NSEC_PER_SEC;
- y2 = (ts.tv_sec + 1) * NSEC_PER_SEC + ts.tv_nsec;
+ y2 = (u32)ktime_to_ns(ktime_sub(last->host_time, first->host_time)) +
y1;
/* Interpolated and host SOF timestamps can wrap around at slightly
* different times. Handle this by adding or removing 2048 to or from
@@ -686,24 +683,18 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
- (u64)y2 * (u64)x1;
y = div_u64(y, x2 - x1);
- div = div_u64_rem(y, NSEC_PER_SEC, &rem);
- ts.tv_sec = first->host_ts.tv_sec - 1 + div;
- ts.tv_nsec = first->host_ts.tv_nsec + rem;
- if (ts.tv_nsec >= NSEC_PER_SEC) {
- ts.tv_sec++;
- ts.tv_nsec -= NSEC_PER_SEC;
- }
+ timestamp = ktime_to_ns(first->host_time) + y - y1;
uvc_trace(UVC_TRACE_CLOCK, "%s: SOF %u.%06llu y %llu ts %llu "
"buf ts %llu (x1 %u/%u/%u x2 %u/%u/%u y1 %u y2 %u)\n",
stream->dev->name,
sof >> 16, div_u64(((u64)sof & 0x) * 100LLU, 65536),
- y, timespec_to_ns(&ts), vbuf->vb2_buf.timestamp,
+ y, timestamp, vbuf->vb2_buf.timestamp,
x1, first->host_sof, first->dev_sof,
x2, last->host_sof, last->dev_sof, y1, y2);
/* Update the V4L2 buffer. */
- vbuf->vb2_buf.timestamp = timespec_to_ns(&ts);
+ vbuf->vb2_buf.timestamp = timestamp;
done:
spin_unlock_irqrestore(&clock->lock, flags);
@@ -1007,8 +998,6 @@ static int uvc_video_decode_start(struct uvc_streaming
*stream,
* when the EOF bit is set to force synchronisation on the next packet.
*/
if (buf->state != UVC_BUF_STATE_ACTIVE) {
- struct timespec ts;
-
if (fid == stream->last_fid) {
uvc_trace(UVC_TRACE_FRAME, "Dropping payload (out of "
"sync).\n");
@@ -1018,11 +1007,9 @@ static int uvc_video_decode_start(struct uvc_streaming
*stream,
return -ENODATA;
[PATCH 1/8] [media] uvc_video: use ktime_t for stats
'struct timespec' works fine here, but we try to migrate
away from it in favor of ktime_t or timespec64. In this
case, using ktime_t produces the simplest code.
Signed-off-by: Arnd Bergmann
---
drivers/media/usb/uvc/uvc_video.c | 11 ---
drivers/media/usb/uvc/uvcvideo.h | 4 ++--
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc/uvc_video.c
index fb86d6af398d..d6bee37cd1b8 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -725,7 +725,7 @@ static void uvc_video_stats_decode(struct uvc_streaming
*stream,
if (stream->stats.stream.nb_frames == 0 &&
stream->stats.frame.nb_packets == 0)
- ktime_get_ts(&stream->stats.stream.start_ts);
+ stream->stats.stream.start_ts = ktime_get();
switch (data[1] & (UVC_STREAM_PTS | UVC_STREAM_SCR)) {
case UVC_STREAM_PTS | UVC_STREAM_SCR:
@@ -865,16 +865,13 @@ size_t uvc_video_stats_dump(struct uvc_streaming *stream,
char *buf,
{
unsigned int scr_sof_freq;
unsigned int duration;
- struct timespec ts;
size_t count = 0;
- ts = timespec_sub(stream->stats.stream.stop_ts,
- stream->stats.stream.start_ts);
-
/* Compute the SCR.SOF frequency estimate. At the nominal 1kHz SOF
* frequency this will not overflow before more than 1h.
*/
- duration = ts.tv_sec * 1000 + ts.tv_nsec / 100;
+ duration = ktime_ms_delta(stream->stats.stream.stop_ts,
+ stream->stats.stream.start_ts);
if (duration != 0)
scr_sof_freq = stream->stats.stream.scr_sof_count * 1000
/ duration;
@@ -915,7 +912,7 @@ static void uvc_video_stats_start(struct uvc_streaming
*stream)
static void uvc_video_stats_stop(struct uvc_streaming *stream)
{
- ktime_get_ts(&stream->stats.stream.stop_ts);
+ stream->stats.stream.stop_ts = ktime_get();
}
/*
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index 05398784d1c8..a2c190937067 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -452,8 +452,8 @@ struct uvc_stats_frame {
};
struct uvc_stats_stream {
- struct timespec start_ts; /* Stream start timestamp */
- struct timespec stop_ts;/* Stream stop timestamp */
+ ktime_t start_ts; /* Stream start timestamp */
+ ktime_t stop_ts;/* Stream stop timestamp */
unsigned int nb_frames; /* Number of frames */
--
2.9.0
[PATCH] media: exynos4-is: check pipe is valid before calling subdev
if the subdev is not yet present (probably because the subdev module has not yet been loaded), the pipe will be NULL. Make sure that this is not the case before attempting to call the op. Signed-off-by: Simon Shields --- include/media/drv-intf/exynos-fimc.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/media/drv-intf/exynos-fimc.h b/include/media/drv-intf/exynos-fimc.h index 69bcd2a07d5c..f9c64338841f 100644 --- a/include/media/drv-intf/exynos-fimc.h +++ b/include/media/drv-intf/exynos-fimc.h @@ -155,7 +155,8 @@ static inline struct exynos_video_entity *vdev_to_exynos_video_entity( } #define fimc_pipeline_call(ent, op, args...) \ - (!(ent) ? -ENOENT : (((ent)->pipe->ops && (ent)->pipe->ops->op) ? \ + ((!(ent) || !(ent)->pipe) ? -ENOENT : \ + (((ent)->pipe->ops && (ent)->pipe->ops->op) ? \ (ent)->pipe->ops->op(((ent)->pipe), ##args) : -ENOIOCTLCMD)) \ #endif /* S5P_FIMC_H_ */ -- 2.15.0
[PATCH v2 2/3] media: staging: atomisp: fixes for "symbol was not declared. Should it be static?" sparse warnings.
Defined some const arrays as static since they don't need external linkage.
Signed-off-by: Jeremy Sowden
---
.../isp/kernels/eed1_8/ia_css_eed1_8.host.c| 24 +++---
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/eed1_8/ia_css_eed1_8.host.c
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/eed1_8/ia_css_eed1_8.host.c
index 682f8b709ff9..47bb5042381b 100644
---
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/eed1_8/ia_css_eed1_8.host.c
+++
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/eed1_8/ia_css_eed1_8.host.c
@@ -32,44 +32,44 @@
#define NUMBER_OF_TCINV_POINTS 9
#define NUMBER_OF_FCINV_POINTS 9
-const int16_t chgrinv_x[NUMBER_OF_CHGRINV_POINTS] = {
+static const int16_t chgrinv_x[NUMBER_OF_CHGRINV_POINTS] = {
0, 16, 64, 144, 272, 448, 672, 976,
1376, 1888, 2528, 3312, 4256, 5376, 6688};
-const int16_t chgrinv_a[NUMBER_OF_CHGRINV_POINTS] = {
+static const int16_t chgrinv_a[NUMBER_OF_CHGRINV_POINTS] = {
-7171, -256, -29, -3456, -1071, -475, -189, -102,
-48, -38, -10, -9, -7, -6, 0};
-const int16_t chgrinv_b[NUMBER_OF_CHGRINV_POINTS] = {
+static const int16_t chgrinv_b[NUMBER_OF_CHGRINV_POINTS] = {
8191, 1021, 256, 114, 60, 37, 24, 17,
12, 9, 6, 5, 4, 3, 2};
-const int16_t chgrinv_c[NUMBER_OF_CHGRINV_POINTS] = {
+static const int16_t chgrinv_c[NUMBER_OF_CHGRINV_POINTS] = {
1, 1, 1, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0};
-const int16_t tcinv_x[NUMBER_OF_TCINV_POINTS] = {
+static const int16_t tcinv_x[NUMBER_OF_TCINV_POINTS] = {
0, 4, 11, 23, 42, 68, 102, 148, 205};
-const int16_t tcinv_a[NUMBER_OF_TCINV_POINTS] = {
+static const int16_t tcinv_a[NUMBER_OF_TCINV_POINTS] = {
-6364, -631, -126, -34, -13, -6, -4452, -2156, 0};
-const int16_t tcinv_b[NUMBER_OF_TCINV_POINTS] = {
+static const int16_t tcinv_b[NUMBER_OF_TCINV_POINTS] = {
8191, 1828, 726, 352, 197, 121, 80, 55, 40};
-const int16_t tcinv_c[NUMBER_OF_TCINV_POINTS] = {
+static const int16_t tcinv_c[NUMBER_OF_TCINV_POINTS] = {
1, 1, 1, 1, 1, 1, 0, 0, 0};
-const int16_t fcinv_x[NUMBER_OF_FCINV_POINTS] = {
+static const int16_t fcinv_x[NUMBER_OF_FCINV_POINTS] = {
0, 80, 216, 456, 824, 1344, 2040, 2952, 4096};
-const int16_t fcinv_a[NUMBER_OF_FCINV_POINTS] = {
+static const int16_t fcinv_a[NUMBER_OF_FCINV_POINTS] = {
-5244, -486, -86, -2849, -961, -400, -180, -86, 0};
-const int16_t fcinv_b[NUMBER_OF_FCINV_POINTS] = {
+static const int16_t fcinv_b[NUMBER_OF_FCINV_POINTS] = {
8191, 1637, 607, 287, 159, 98, 64, 44, 32};
-const int16_t fcinv_c[NUMBER_OF_FCINV_POINTS] = {
+static const int16_t fcinv_c[NUMBER_OF_FCINV_POINTS] = {
1, 1, 1, 0, 0, 0, 0, 0, 0};
--
2.15.0
[PATCH v2 1/3] media: staging: atomisp: fix for sparse "using plain integer as NULL pointer" warnings.
The "address" member of struct ia_css_host_data is a pointer-to-char, so define
default as NULL.
Signed-off-by: Jeremy Sowden
---
.../css2400/runtime/isp_param/interface/ia_css_isp_param_types.h| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isp_param/interface/ia_css_isp_param_types.h
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isp_param/interface/ia_css_isp_param_types.h
index 8e651b80345a..6fee3f7fd184 100644
---
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isp_param/interface/ia_css_isp_param_types.h
+++
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isp_param/interface/ia_css_isp_param_types.h
@@ -95,7 +95,7 @@ union ia_css_all_memory_offsets {
};
#define IA_CSS_DEFAULT_ISP_MEM_PARAMS \
- { { { { 0, 0 } } } }
+ { { { { NULL, 0 } } } }
#define IA_CSS_DEFAULT_ISP_CSS_PARAMS \
{ { { { 0, 0 } } } }
--
2.15.0
[PATCH v2 3/3] media: staging: atomisp: fixed some checkpatch integer type warnings.
Changed the types of some arrays from int16_t to s16.
Signed-off-by: Jeremy Sowden
---
.../isp/kernels/eed1_8/ia_css_eed1_8.host.c| 25 +++---
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/eed1_8/ia_css_eed1_8.host.c
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/eed1_8/ia_css_eed1_8.host.c
index 47bb5042381b..af6c8688876d 100644
---
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/eed1_8/ia_css_eed1_8.host.c
+++
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/eed1_8/ia_css_eed1_8.host.c
@@ -32,47 +32,46 @@
#define NUMBER_OF_TCINV_POINTS 9
#define NUMBER_OF_FCINV_POINTS 9
-static const int16_t chgrinv_x[NUMBER_OF_CHGRINV_POINTS] = {
+static const s16 chgrinv_x[NUMBER_OF_CHGRINV_POINTS] = {
0, 16, 64, 144, 272, 448, 672, 976,
1376, 1888, 2528, 3312, 4256, 5376, 6688};
-static const int16_t chgrinv_a[NUMBER_OF_CHGRINV_POINTS] = {
+static const s16 chgrinv_a[NUMBER_OF_CHGRINV_POINTS] = {
-7171, -256, -29, -3456, -1071, -475, -189, -102,
-48, -38, -10, -9, -7, -6, 0};
-static const int16_t chgrinv_b[NUMBER_OF_CHGRINV_POINTS] = {
+static const s16 chgrinv_b[NUMBER_OF_CHGRINV_POINTS] = {
8191, 1021, 256, 114, 60, 37, 24, 17,
12, 9, 6, 5, 4, 3, 2};
-static const int16_t chgrinv_c[NUMBER_OF_CHGRINV_POINTS] = {
+static const s16 chgrinv_c[NUMBER_OF_CHGRINV_POINTS] = {
1, 1, 1, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0};
-static const int16_t tcinv_x[NUMBER_OF_TCINV_POINTS] = {
+static const s16 tcinv_x[NUMBER_OF_TCINV_POINTS] = {
0, 4, 11, 23, 42, 68, 102, 148, 205};
-static const int16_t tcinv_a[NUMBER_OF_TCINV_POINTS] = {
+static const s16 tcinv_a[NUMBER_OF_TCINV_POINTS] = {
-6364, -631, -126, -34, -13, -6, -4452, -2156, 0};
-static const int16_t tcinv_b[NUMBER_OF_TCINV_POINTS] = {
+static const s16 tcinv_b[NUMBER_OF_TCINV_POINTS] = {
8191, 1828, 726, 352, 197, 121, 80, 55, 40};
-static const int16_t tcinv_c[NUMBER_OF_TCINV_POINTS] = {
+static const s16 tcinv_c[NUMBER_OF_TCINV_POINTS] = {
1, 1, 1, 1, 1, 1, 0, 0, 0};
-static const int16_t fcinv_x[NUMBER_OF_FCINV_POINTS] = {
+static const s16 fcinv_x[NUMBER_OF_FCINV_POINTS] = {
0, 80, 216, 456, 824, 1344, 2040, 2952, 4096};
-static const int16_t fcinv_a[NUMBER_OF_FCINV_POINTS] = {
+static const s16 fcinv_a[NUMBER_OF_FCINV_POINTS] = {
-5244, -486, -86, -2849, -961, -400, -180, -86, 0};
-static const int16_t fcinv_b[NUMBER_OF_FCINV_POINTS] = {
+static const s16 fcinv_b[NUMBER_OF_FCINV_POINTS] = {
8191, 1637, 607, 287, 159, 98, 64, 44, 32};
-static const int16_t fcinv_c[NUMBER_OF_FCINV_POINTS] = {
+static const s16 fcinv_c[NUMBER_OF_FCINV_POINTS] = {
1, 1, 1, 0, 0, 0, 0, 0, 0};
-
void
ia_css_eed1_8_vmem_encode(
struct eed1_8_vmem_params *to,
--
2.15.0
[PATCH v2 0/3] Sparse fixes for the Atom ISP Staging Driver
Fixed some sparse warnings in the Atom ISP staging driver and the checkpatch warnings that affected my patches. This time with longer commit messages. :) Jeremy Sowden (3): media: staging: atomisp: fix for sparse "using plain integer as NULL pointer" warnings. media: staging: atomisp: fixes for "symbol was not declared. Should it be static?" sparse warnings. media: staging: atomisp: fixed some checkpatch integer type warnings. .../isp/kernels/eed1_8/ia_css_eed1_8.host.c| 25 +++--- .../isp_param/interface/ia_css_isp_param_types.h | 2 +- 2 files changed, 13 insertions(+), 14 deletions(-) base-commit: 844056fd74ebdd826bd23a7d989597e15f478acb -- 2.15.0
Re: [PATCH 2/3] media: staging: atomisp: defined as static some const arrays which don't need external linkage.
On Mon, Nov 27, 2017 at 11:30:53AM +, Jeremy Sowden wrote: > Signed-off-by: Jeremy Sowden > --- > .../isp/kernels/eed1_8/ia_css_eed1_8.host.c| 24 > +++--- > 1 file changed, 12 insertions(+), 12 deletions(-) I can never take patches without any changelog text, and so no one should write them that way :) Try it again? thanks, greg k-h
Re: [PATCH v8 0/5] Synopsys Designware HDMI Video Capture Controller + PHY
Hi Jose, Sakari's work was merged. Can you make a v9? Then we can merge this for 4.16. Thanks! Hans On 09/22/2017 02:53 PM, Hans Verkuil wrote: > Hi Jose, > > I'm going to mark this patch series as 'Changes Requested' since it depends on > Sakari's subnotifier work. Once that is accepted I assume you'll make a v9 on > top > and then this can hopefully be merged. > > Regards, > > Hans > > On 10/07/17 17:46, Jose Abreu wrote: >> 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 8 addresses review comments from Rob Herring regarding device tree >> bindings. >> >> I also added one patch for cec.h which is needed to fix build >> errors/warnings. >> >> This series depends on the patch at [1]. >> >> This series was tested in a FPGA platform using an embedded platform called >> ARC AXS101. >> >> Jose Abreu (5): >> [media] cec.h: Add stub function for cec_register_cec_notifier() >> 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 >> >> Cc: Carlos Palminha >> Cc: Mauro Carvalho Chehab >> Cc: Hans Verkuil >> Cc: Rob Herring >> Cc: Mark Rutland >> Cc: Sylwester Nawrocki >> >> [1] https://patchwork.linuxtv.org/patch/41834/ >> >> .../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 | 844 + >> drivers/media/platform/dwc/dw-hdmi-phy-e405.h | 63 + >> drivers/media/platform/dwc/dw-hdmi-rx.c| 1823 >> >> drivers/media/platform/dwc/dw-hdmi-rx.h| 441 + >> include/media/cec.h|8 + >> include/media/dwc/dw-hdmi-phy-pdata.h | 128 ++ >> include/media/dwc/dw-hdmi-rx-pdata.h | 70 + >> 13 files changed, 3471 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 >> >
Re: [PATCH v2 04/11] media: rkisp1: add Rockchip MIPI Synopsys DPHY driver
I'm CC-ing Jose Abreu from Synopsys to this. Jose, can you or a colleague take
a look at this as well?
Jacob, I have some high-level questions first:
1) to what extend is this code rockchip-specific as opposed to be more
synopsys-generic?
2) I don't quite see how this works when there are two sensors. Is only one
active at a
time? Or are they multiplexed somehow?
3) Same as for the previous patch: some more comments would be welcome.
On 11/24/2017 03:36 AM, Jacob Chen wrote:
> From: Jacob Chen
>
> This commit adds a subdev driver for Rockchip MIPI Synopsys DPHY driver.
>
> The phy driver is kind of independent compare to the other parts, but i'd like
> to keep it in rkisp1 driver, unless people want to generalize it
>
> Signed-off-by: Jacob Chen
> Signed-off-by: Shunqian Zheng
> Signed-off-by: Tomasz Figa
> ---
> drivers/media/platform/rockchip/isp1/Makefile | 1 +
> .../media/platform/rockchip/isp1/mipi_dphy_sy.c| 805
> +
> 2 files changed, 806 insertions(+)
> create mode 100644 drivers/media/platform/rockchip/isp1/mipi_dphy_sy.c
>
> diff --git a/drivers/media/platform/rockchip/isp1/Makefile
> b/drivers/media/platform/rockchip/isp1/Makefile
> index 8f52f959398e..18af64853734 100644
> --- a/drivers/media/platform/rockchip/isp1/Makefile
> +++ b/drivers/media/platform/rockchip/isp1/Makefile
> @@ -4,4 +4,5 @@ video_rkisp1-objs+= rkisp1.o \
> regs.o \
> isp_stats.o \
> isp_params.o \
> + mipi_dphy_sy.o \
> capture.o
> diff --git a/drivers/media/platform/rockchip/isp1/mipi_dphy_sy.c
> b/drivers/media/platform/rockchip/isp1/mipi_dphy_sy.c
> new file mode 100644
> index ..56deff2be6fd
> --- /dev/null
> +++ b/drivers/media/platform/rockchip/isp1/mipi_dphy_sy.c
> @@ -0,0 +1,805 @@
> +/*
> + * Rockchip MIPI Synopsys DPHY driver
> + *
> + * Copyright (C) 2017 Fuzhou 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
> +
> +#define RK3288_GRF_SOC_CON6 0x025c
> +#define RK3288_GRF_SOC_CON8 0x0264
> +#define RK3288_GRF_SOC_CON9 0x0268
> +#define RK3288_GRF_SOC_CON10 0x026c
> +#define RK3288_GRF_SOC_CON14 0x027c
> +#define RK3288_GRF_SOC_STATUS21 0x02d4
> +#define RK3288_GRF_IO_VSEL 0x0380
> +#define RK3288_GRF_SOC_CON15 0x03a4
> +
> +#define RK3399_GRF_SOC_CON9 0x6224
> +#define RK3399_GRF_SOC_CON21 0x6254
> +#define RK3399_GRF_SOC_CON22 0x6258
> +#define RK3399_GRF_SOC_CON23 0x625c
> +#define RK3399_GRF_SOC_CON24 0x6260
> +#define RK3399_GRF_SOC_CON25 0x6264
> +#define RK3399_GRF_SOC_STATUS1 0xe2a4
> +
> +#define CLOCK_LANE_HS_RX_CONTROL 0x34
> +#define LANE0_HS_RX_CONTROL 0x44
> +#define LANE1_HS_RX_CONTROL 0x54
> +#define LANE2_HS_RX_CONTROL 0x84
> +#define LANE3_HS_RX_CONTROL 0x94
> +#define HS_RX_DATA_LANES_THS_SETTLE__CONTROL 0x75
> +
> +#define HIWORD_UPDATE(val, mask, shift) \
> + ((val) << (shift) | (mask) << ((shift) + 16))
> +
> +enum mipi_dphy_sy_pads {
> + MIPI_DPHY_SY_PAD_SINK = 0,
> + MIPI_DPHY_SY_PAD_SOURCE,
> + MIPI_DPHY_SY_PADS_NUM,
> +};
> +
> +enum dphy_reg_id {
> + GRF_DPHY_RX0_TURNDISABLE = 0,
> + GRF_DPHY_RX0_FORCERXMODE,
> + GRF_DPHY_RX0_FORCETXSTOPMODE,
> + GRF_DPHY_RX0_ENABL
[PATCH 0/3] Sparse fixes for the Atom ISP Staging Driver
Fixed some sparse warnings in the Atom ISP staging driver and the checkpatch warnings that affected my patches. Jeremy Sowden (3): media: staging: atomisp: address member of struct ia_css_host_data is a pointer-to-char, so define default as NULL. media: staging: atomisp: defined as static some const arrays which don't need external linkage. media: staging: atomisp: prefer s16 to int16_t. .../isp/kernels/eed1_8/ia_css_eed1_8.host.c| 25 +++--- .../isp_param/interface/ia_css_isp_param_types.h | 2 +- 2 files changed, 13 insertions(+), 14 deletions(-) base-commit: 844056fd74ebdd826bd23a7d989597e15f478acb -- 2.15.0
[PATCH 3/3] media: staging: atomisp: prefer s16 to int16_t.
Signed-off-by: Jeremy Sowden
---
.../isp/kernels/eed1_8/ia_css_eed1_8.host.c| 25 +++---
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/eed1_8/ia_css_eed1_8.host.c
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/eed1_8/ia_css_eed1_8.host.c
index 47bb5042381b..af6c8688876d 100644
---
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/eed1_8/ia_css_eed1_8.host.c
+++
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/eed1_8/ia_css_eed1_8.host.c
@@ -32,47 +32,46 @@
#define NUMBER_OF_TCINV_POINTS 9
#define NUMBER_OF_FCINV_POINTS 9
-static const int16_t chgrinv_x[NUMBER_OF_CHGRINV_POINTS] = {
+static const s16 chgrinv_x[NUMBER_OF_CHGRINV_POINTS] = {
0, 16, 64, 144, 272, 448, 672, 976,
1376, 1888, 2528, 3312, 4256, 5376, 6688};
-static const int16_t chgrinv_a[NUMBER_OF_CHGRINV_POINTS] = {
+static const s16 chgrinv_a[NUMBER_OF_CHGRINV_POINTS] = {
-7171, -256, -29, -3456, -1071, -475, -189, -102,
-48, -38, -10, -9, -7, -6, 0};
-static const int16_t chgrinv_b[NUMBER_OF_CHGRINV_POINTS] = {
+static const s16 chgrinv_b[NUMBER_OF_CHGRINV_POINTS] = {
8191, 1021, 256, 114, 60, 37, 24, 17,
12, 9, 6, 5, 4, 3, 2};
-static const int16_t chgrinv_c[NUMBER_OF_CHGRINV_POINTS] = {
+static const s16 chgrinv_c[NUMBER_OF_CHGRINV_POINTS] = {
1, 1, 1, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0};
-static const int16_t tcinv_x[NUMBER_OF_TCINV_POINTS] = {
+static const s16 tcinv_x[NUMBER_OF_TCINV_POINTS] = {
0, 4, 11, 23, 42, 68, 102, 148, 205};
-static const int16_t tcinv_a[NUMBER_OF_TCINV_POINTS] = {
+static const s16 tcinv_a[NUMBER_OF_TCINV_POINTS] = {
-6364, -631, -126, -34, -13, -6, -4452, -2156, 0};
-static const int16_t tcinv_b[NUMBER_OF_TCINV_POINTS] = {
+static const s16 tcinv_b[NUMBER_OF_TCINV_POINTS] = {
8191, 1828, 726, 352, 197, 121, 80, 55, 40};
-static const int16_t tcinv_c[NUMBER_OF_TCINV_POINTS] = {
+static const s16 tcinv_c[NUMBER_OF_TCINV_POINTS] = {
1, 1, 1, 1, 1, 1, 0, 0, 0};
-static const int16_t fcinv_x[NUMBER_OF_FCINV_POINTS] = {
+static const s16 fcinv_x[NUMBER_OF_FCINV_POINTS] = {
0, 80, 216, 456, 824, 1344, 2040, 2952, 4096};
-static const int16_t fcinv_a[NUMBER_OF_FCINV_POINTS] = {
+static const s16 fcinv_a[NUMBER_OF_FCINV_POINTS] = {
-5244, -486, -86, -2849, -961, -400, -180, -86, 0};
-static const int16_t fcinv_b[NUMBER_OF_FCINV_POINTS] = {
+static const s16 fcinv_b[NUMBER_OF_FCINV_POINTS] = {
8191, 1637, 607, 287, 159, 98, 64, 44, 32};
-static const int16_t fcinv_c[NUMBER_OF_FCINV_POINTS] = {
+static const s16 fcinv_c[NUMBER_OF_FCINV_POINTS] = {
1, 1, 1, 0, 0, 0, 0, 0, 0};
-
void
ia_css_eed1_8_vmem_encode(
struct eed1_8_vmem_params *to,
--
2.15.0
[PATCH 2/3] media: staging: atomisp: defined as static some const arrays which don't need external linkage.
Signed-off-by: Jeremy Sowden
---
.../isp/kernels/eed1_8/ia_css_eed1_8.host.c| 24 +++---
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/eed1_8/ia_css_eed1_8.host.c
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/eed1_8/ia_css_eed1_8.host.c
index 682f8b709ff9..47bb5042381b 100644
---
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/eed1_8/ia_css_eed1_8.host.c
+++
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/eed1_8/ia_css_eed1_8.host.c
@@ -32,44 +32,44 @@
#define NUMBER_OF_TCINV_POINTS 9
#define NUMBER_OF_FCINV_POINTS 9
-const int16_t chgrinv_x[NUMBER_OF_CHGRINV_POINTS] = {
+static const int16_t chgrinv_x[NUMBER_OF_CHGRINV_POINTS] = {
0, 16, 64, 144, 272, 448, 672, 976,
1376, 1888, 2528, 3312, 4256, 5376, 6688};
-const int16_t chgrinv_a[NUMBER_OF_CHGRINV_POINTS] = {
+static const int16_t chgrinv_a[NUMBER_OF_CHGRINV_POINTS] = {
-7171, -256, -29, -3456, -1071, -475, -189, -102,
-48, -38, -10, -9, -7, -6, 0};
-const int16_t chgrinv_b[NUMBER_OF_CHGRINV_POINTS] = {
+static const int16_t chgrinv_b[NUMBER_OF_CHGRINV_POINTS] = {
8191, 1021, 256, 114, 60, 37, 24, 17,
12, 9, 6, 5, 4, 3, 2};
-const int16_t chgrinv_c[NUMBER_OF_CHGRINV_POINTS] = {
+static const int16_t chgrinv_c[NUMBER_OF_CHGRINV_POINTS] = {
1, 1, 1, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0};
-const int16_t tcinv_x[NUMBER_OF_TCINV_POINTS] = {
+static const int16_t tcinv_x[NUMBER_OF_TCINV_POINTS] = {
0, 4, 11, 23, 42, 68, 102, 148, 205};
-const int16_t tcinv_a[NUMBER_OF_TCINV_POINTS] = {
+static const int16_t tcinv_a[NUMBER_OF_TCINV_POINTS] = {
-6364, -631, -126, -34, -13, -6, -4452, -2156, 0};
-const int16_t tcinv_b[NUMBER_OF_TCINV_POINTS] = {
+static const int16_t tcinv_b[NUMBER_OF_TCINV_POINTS] = {
8191, 1828, 726, 352, 197, 121, 80, 55, 40};
-const int16_t tcinv_c[NUMBER_OF_TCINV_POINTS] = {
+static const int16_t tcinv_c[NUMBER_OF_TCINV_POINTS] = {
1, 1, 1, 1, 1, 1, 0, 0, 0};
-const int16_t fcinv_x[NUMBER_OF_FCINV_POINTS] = {
+static const int16_t fcinv_x[NUMBER_OF_FCINV_POINTS] = {
0, 80, 216, 456, 824, 1344, 2040, 2952, 4096};
-const int16_t fcinv_a[NUMBER_OF_FCINV_POINTS] = {
+static const int16_t fcinv_a[NUMBER_OF_FCINV_POINTS] = {
-5244, -486, -86, -2849, -961, -400, -180, -86, 0};
-const int16_t fcinv_b[NUMBER_OF_FCINV_POINTS] = {
+static const int16_t fcinv_b[NUMBER_OF_FCINV_POINTS] = {
8191, 1637, 607, 287, 159, 98, 64, 44, 32};
-const int16_t fcinv_c[NUMBER_OF_FCINV_POINTS] = {
+static const int16_t fcinv_c[NUMBER_OF_FCINV_POINTS] = {
1, 1, 1, 0, 0, 0, 0, 0, 0};
--
2.15.0
[PATCH 1/3] media: staging: atomisp: address member of struct ia_css_host_data is a pointer-to-char, so define default as NULL.
Signed-off-by: Jeremy Sowden
---
.../css2400/runtime/isp_param/interface/ia_css_isp_param_types.h| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isp_param/interface/ia_css_isp_param_types.h
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isp_param/interface/ia_css_isp_param_types.h
index 8e651b80345a..6fee3f7fd184 100644
---
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isp_param/interface/ia_css_isp_param_types.h
+++
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isp_param/interface/ia_css_isp_param_types.h
@@ -95,7 +95,7 @@ union ia_css_all_memory_offsets {
};
#define IA_CSS_DEFAULT_ISP_MEM_PARAMS \
- { { { { 0, 0 } } } }
+ { { { { NULL, 0 } } } }
#define IA_CSS_DEFAULT_ISP_CSS_PARAMS \
{ { { { 0, 0 } } } }
--
2.15.0
Re: [GIT PULL] SAA716x DVB driver
Em Fri, 24 Nov 2017 17:28:37 +0100 Tycho Lürsen escreveu: > Hi Mauro, > > afaik the last communication about submission of this driver was about > two months ago. > > This driver is important to me, because I own several TurboSight cards > that are saa716x based. I want to submit a patch that supports my cards. > Of course I can only do so when you accept this driver in the first place. > > Any chance you and Sören agree about how to proceed about this driver > anytime soon? If we can reach an agreement about what should be done for the driver to be promoted from staging some day, I'll merge it. Otherwise, it can be kept maintained out of tree. This driver has been maintained OOT for a very long time, and it seems that people were happy with that, as only at the second half of this year someone is requesting to merge it. So, while I agree that the best is to merge it upstream and address the issues that made it OOT for a long time, we shouldn't rush it with the risk of doing more harm than good. Thanks, Mauro
Re: [PATCH v2 0/2] rcar-du, vsp1: rcar-gen3: Add support for colorkey alpha blending
Hi Alex et all,
On Tuesday, 9 May 2017 10:12:31 EET Gheorghe, Alexandru wrote:
> On Mon, Monday, May 8, 2017 9:29 PM +0200, Daniel Vetter wrote:
> > On Mon, May 08, 2017 at 09:33:37AM -0700, Eric Anholt wrote:
> >> Alexandru Gheorghe writes:
> >>> Currently, rcar-du supports colorkeying only for rcar-gen2 and it
> >>> uses some hw capability of the display unit(DU) which is not available
> >>> on gen3.
> >>>
> >>> In order to implement colorkeying for gen3 we need to use the
> >>> colorkey capability of the VSPD, hence the need to change both
> >>> drivers rcar-du and vsp1.
> >>>
> >>> This patchset had been developed and tested on top of
> >>> v4.9/rcar-3.5.1 from
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git
> >>
> >> A few questions:
> >>
> >> Are other drivers interested in supporting this property? VC4 has the
> >> 24-bit RGB colorkey, but I don't see YCBCR support. Should it be
> >> documented in a generic location?
>
> As far as I identified armada, i815, nouveau, rcar-du, vmwgfx drivers have
> this notion of colorkey. There could be other HW which don't have this
> implemented yet.
Among those drivers only armada, nouveau and rcar-du expose the color key
through DRM properties. The i915 and vmwgfx drivers use custom ioctls. Here is
what is currently implemented.
- armada
"colorkey" range 0x 0x00ff
"colorkey_min" range 0x 0x00ff
"colorkey_max" range 0x 0x00ff
"colorkey_val" range 0x 0x00ff
"colorkey_alpha" range 0x 0x00ff
"colorkey_mode" enum "disable", "Y component", "U component", "V component",
"RGB", "R component", "G component", "B component"
All range properties store a RGB888 or YUV888 triplet.
The min and max properties store the comparison ranges. When a match occurs
for one of the components, the value and alpha from the val and alpha
properties replace the pixel. It's not clear which of the alpha "components"
is used when a match occurs in RGB mode.
The colorkey property is a shortcut that stores identical values in min, max
and val and 0 in alpha.
- i915
#define I915_SET_COLORKEY_NONE (1<<0)
#define I915_SET_COLORKEY_DESTINATION (1<<1)
#define I915_SET_COLORKEY_SOURCE(1<<2)
struct drm_intel_sprite_colorkey {
__u32 plane_id;
__u32 min_value;
__u32 channel_mask;
__u32 max_value;
__u32 flags;
};
- nouveau
"colorkey" range 0x 0x01ff
The format isn't documented but it seems from the source code that bits 23:0
store the color key value (written directly to a register, so possibly in a
pixel format-dependent format) and bit 24 enables color keying.
- rcar-du
"colorkey" range 0x 0x01ff
Bits 23:0 store the color key value in RGB888 (regardless of the pixel format
of the plane) and bit 24 enables color keying. This supports Gen2 hardware
only, where the only available more is exact match. The pixel then becomes
fully transparent (the hardware doesn't support custom target alpha values).
On Gen3 hardware color keying can be performed in exact RGB match, exact Y
match or range Y match (only the max value is programmable, the min value is
always 0). Furthermore in exact match modes the hardware can operate with a
single match value, in which case it can then override the full ARGB or AYUV
pixel, or double match value, in which case it can then override the alpha
component only, but with two distinct match values each associated with a
target alpha.
- vmwgfx
struct drm_vmw_control_stream_arg {
__u32 stream_id;
__u32 enabled;
__u32 flags;
__u32 color_key;
__u32 handle;
__u32 offset;
__s32 format;
__u32 size;
__u32 width;
__u32 height;
__u32 pitch[3];
__u32 pad64;
struct drm_vmw_rect src;
struct drm_vmw_rect dst;
};
The color_key field isn't documented, but the following (unused) macros hint
that it could store an RGB888, with the color key feature enabled through the
flags field.
#define SVGA_VIDEO_FLAG_COLORKEY0x0001
#define SVGA_VIDEO_COLORKEY_MASK 0x00ff
> >> Does your colorkey end up forcing alpha to 1 for the plane when it's
> >> not matched?
>
> I think this behavior is HW dependent, on R-CAR Gen3, the alpha for pixel
> that don't match is not touch.
>
> > I think generic color-key for plane compositioning would be nice, but I'm
> > not sure that's possible due to differences in how the key works.
>
> I'm thinking of starting from the drivers that do have this property and see
> if there is any common ground for a generic color-key property/ies
Looking at the 5 drivers we have in mainline that support color keying one way
or another, we can already see that the hardware implementations differ quite
widely. There are however similarities, and we could express most of the above
features through a set of generic properties similar
[RFC] v4l: i2c: ov7670: Implement mbus configuration
ov7670 currently supports configuration of a few parameters only through
platform data. Implement media bus configuration by parsing DT properties
at probe() time and opportunely configure REG_COM10 during s_format().
Signed-off-by: Jacopo Mondi
---
Hi linux-media,
I'm using this sensor to test the CEU driver I have submitted some time ago
and I would like to change synchronization signal polarities to test them in
combination with that driver.
So I added support for retrieving some properties listed in the device tree
bindings documentation from sensor's DT node and made a patch, BUT I'm
slightly confused about this (and that's why this is an RFC).
I did a grep for "sync-active" in drivers/media/i2c/ and no sensor driver
implements any property parsing, so I guess I'm doing something wrong here.
I thought that maybe sensor media bus configuration should come from the
platform driver, through the s_mbus_config() operation in v4l2_subdev_video_ops,
but that's said to be deprecated. So maybe is the framework providing support
for parsing those properties? Another grep there and I found only v4l2-fwnode.c
has support for parsing serial/parallel bus properties, but my understanding is
that those functions are meant to be used by the platform driver when
parsing the remote fw node.
So please help me out here: where should I implement media bus configuration
for sensor drivers?
Thanks
j
PS: being this just an RFC I have not updated dt bindings, and only
compile-tested the patch
---
drivers/media/i2c/ov7670.c | 108 ++---
1 file changed, 101 insertions(+), 7 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index e88549f..7e2de7e 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -88,6 +88,7 @@ MODULE_PARM_DESC(debug, "Debug level (0-1)");
#define REG_COM10 0x15/* Control 10 */
#define COM10_HSYNC0x40/* HSYNC instead of HREF */
#define COM10_PCLK_HB 0x20/* Suppress PCLK on horiz blank */
+#define COM10_PCLK_REV 0x10 /* Latch data on PCLK rising edge */
#define COM10_HREF_REV 0x08 /* Reverse HREF */
#define COM10_VS_LEAD 0x04/* VSYNC on clock leading edge */
#define COM10_VS_NEG 0x02/* VSYNC negative */
@@ -233,6 +234,7 @@ struct ov7670_info {
struct clk *clk;
struct gpio_desc *resetb_gpio;
struct gpio_desc *pwdn_gpio;
+ unsigned int mbus_config; /* Media bus configuration flags */
int min_width; /* Filter out smaller sizes */
int min_height; /* Filter out smaller sizes */
int clock_speed;/* External clock speed (MHz) */
@@ -985,7 +987,7 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
struct ov7670_format_struct *ovfmt;
struct ov7670_win_size *wsize;
struct ov7670_info *info = to_state(sd);
- unsigned char com7;
+ unsigned char com7, com10;
int ret;
if (format->pad)
@@ -1021,6 +1023,9 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
ret = 0;
if (wsize->regs)
ret = ov7670_write_array(sd, wsize->regs);
+ if (ret)
+ return ret;
+
info->fmt = ovfmt;
/*
@@ -1033,8 +1038,26 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
* to write it unconditionally, and that will make the frame
* rate persistent too.
*/
- if (ret == 0)
- ret = ov7670_write(sd, REG_CLKRC, info->clkrc);
+ ret = ov7670_write(sd, REG_CLKRC, info->clkrc);
+ if (ret)
+ return ret;
+
+ /* Configure the media bus after the image format */
+ com10 = 0;
+ if (info->mbus_config & V4L2_MBUS_VSYNC_ACTIVE_LOW)
+ com10 |= COM10_VS_NEG;
+ if (info->mbus_config & V4L2_MBUS_HSYNC_ACTIVE_LOW)
+ com10 |= COM10_HS_NEG;
+ if (info->mbus_config & V4L2_MBUS_PCLK_SAMPLE_RISING)
+ com10 |= COM10_PCLK_REV;
+ if (info->pclk_hb_disable)
+ com10 |= COM10_PCLK_HB;
+
+ if (com10)
+ ret = ov7670_write(sd, REG_COM10, com10);
+ if (ret)
+ return ret;
+
return 0;
}
@@ -1572,6 +1595,29 @@ static int ov7670_init_gpio(struct i2c_client *client,
struct ov7670_info *info)
return 0;
}
+/**
+ * ov7670_parse_dt_prop() - parse property "prop_name" in OF node
+ *
+ * @return The property value or < 0 if property not present
+ *or wrongly specified.
+ */
+static int ov7670_parse_dt_prop(struct device *dev, char *prop_name)
+{
+ struct device_node *np = dev->of_node;
+ u32 prop_val;
+ int ret;
+
+ ret = of_property_read_u32(np, prop_name, &prop_val);
+ if (ret) {
+ if (ret != -EINVAL)
+ dev_err(dev, "Unable to parse property %s: %d\n",
+ prop_name,
Re: [PATCH v2 02/11] media: rkisp1: Add user space ABI definitions
On 11/24/2017 03:36 AM, Jacob Chen wrote: > From: Jeffy Chen > > Add the header for userspace I gather that this effectively documents the metadata? I recommend using kernel-doc formatting here. One thing I immediately noticed is that these structures will have a different layout for 32 or 64 architectures. Which is a problem if you compile for 32 bit on a 64 bit kernel on the rk3399. I think you need to be very careful how you define these structures. Are these parameters documented in a datasheet? If so, then add a reference to that datasheet. Is it publicly available or do you need an NDA to get it? > > Signed-off-by: Jeffy Chen > Signed-off-by: Jacob Chen > --- > include/uapi/linux/rkisp1-config.h | 554 > + > 1 file changed, 554 insertions(+) > create mode 100644 include/uapi/linux/rkisp1-config.h > > diff --git a/include/uapi/linux/rkisp1-config.h > b/include/uapi/linux/rkisp1-config.h > new file mode 100644 > index ..a801fbc9ef47 > --- /dev/null > +++ b/include/uapi/linux/rkisp1-config.h > @@ -0,0 +1,554 @@ > +/* > + * Rockchip isp1 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. > + */ > + > +#ifndef _UAPI_RKISP1_CONFIG_H > +#define _UAPI_RKISP1_CONFIG_H > + > +#include > +#include > + > +#define CIFISP_MODULE_DPCC (1 << 0) > +#define CIFISP_MODULE_BLS (1 << 1) > +#define CIFISP_MODULE_SDG (1 << 2) > +#define CIFISP_MODULE_HST (1 << 3) > +#define CIFISP_MODULE_LSC (1 << 4) > +#define CIFISP_MODULE_AWB_GAIN (1 << 5) > +#define CIFISP_MODULE_FLT (1 << 6) > +#define CIFISP_MODULE_BDM (1 << 7) > +#define CIFISP_MODULE_CTK (1 << 8) > +#define CIFISP_MODULE_GOC (1 << 9) > +#define CIFISP_MODULE_CPROC (1 << 10) > +#define CIFISP_MODULE_AFC (1 << 11) > +#define CIFISP_MODULE_AWB (1 << 12) > +#define CIFISP_MODULE_IE(1 << 13) > +#define CIFISP_MODULE_AEC (1 << 14) > +#define CIFISP_MODULE_WDR (1 << 15) > +#define CIFISP_MODULE_DPF (1 << 16) > +#define CIFISP_MODULE_DPF_STRENGTH (1 << 17) > + > +#define CIFISP_CTK_COEFF_MAX0x100 > +#define CIFISP_CTK_OFFSET_MAX 0x800 > + > +#define CIFISP_AE_MEAN_MAX 25 > +#define CIFISP_HIST_BIN_N_MAX 16 > +#define CIFISP_AFM_MAX_WINDOWS 3 > +#define CIFISP_DEGAMMA_CURVE_SIZE 17 > + > +#define CIFISP_BDM_MAX_TH 0xFF > + > +/* maximum value for horizontal start address */ > +#define CIFISP_BLS_START_H_MAX 0x0FFF > +/* maximum value for horizontal stop address */ > +#define CIFISP_BLS_STOP_H_MAX 0x0FFF > +/* maximum value for vertical start address */ > +#define CIFISP_BLS_START_V_MAX 0x0FFF > +/* maximum value for vertical stop address */ > +#define CIFISP_BLS_STOP_V_MAX 0x0FFF > +/* maximum is 2^18 = 262144*/ > +#define CIFISP_BLS_SAMPLES_MAX 0x0012 > +/* maximum value for fixed black level */ > +#define CIFISP_BLS_FIX_SUB_MAX 0x0FFF > +/* minimum value for fixed black level */ > +#define CIFISP_BLS_FIX_SUB_MIN 0xF000 > +/* 13 bit range (signed)*/ > +#define CIFISP_BLS_FIX_MASK0x1FFF > +/* AWB */ > +#define CIFISP_AWB_MAX_GRID1 > +#define CIFISP_AWB_MAX_FRAMES 7 > + > +/* Gamma out*/ > +/* Maximum number of
Re: [PATCH v2 01/11] media: videodev2.h, v4l2-ioctl: add rkisp1 meta buffer format
On 11/24/2017 03:36 AM, Jacob Chen wrote:
> From: Shunqian Zheng
>
> Add the Rockchip ISP1 specific processing parameter format
> V4L2_META_FMT_RK_ISP1_PARAMS and metadata format
> V4L2_META_FMT_RK_ISP1_STAT_3A for 3A.
These formats are not documented in the V4L2 spec. I think it is documented in
rkisp1-config.h, so you need to add something to meta-formats.rst. It's OK to
refer to that header, as long as it is clear where the documentation of the
format can be found.
Regards,
Hans
>
> Signed-off-by: Shunqian Zheng
> Signed-off-by: Jacob Chen
> ---
> drivers/media/v4l2-core/v4l2-ioctl.c | 2 ++
> include/uapi/linux/videodev2.h | 4
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index d6587b3ec33e..0604ae9ea444 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1252,6 +1252,8 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
> case V4L2_TCH_FMT_TU08: descr = "8-bit unsigned touch data";
> break;
> case V4L2_META_FMT_VSP1_HGO:descr = "R-Car VSP1 1-D Histogram";
> break;
> case V4L2_META_FMT_VSP1_HGT:descr = "R-Car VSP1 2-D Histogram";
> break;
> + case V4L2_META_FMT_RK_ISP1_PARAMS: descr = "Rockchip ISP1 3A
> params"; break;
> + case V4L2_META_FMT_RK_ISP1_STAT_3A: descr = "Rockchip ISP1 3A
> statistics"; break;
>
> default:
> /* Compressed formats */
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 7c871291c1fa..961545e64c12 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -691,6 +691,10 @@ struct v4l2_pix_format {
> #define V4L2_META_FMT_VSP1_HGOv4l2_fourcc('V', 'S', 'P', 'H') /* R-Car
> VSP1 1-D Histogram */
> #define V4L2_META_FMT_VSP1_HGTv4l2_fourcc('V', 'S', 'P', 'T') /* R-Car
> VSP1 2-D Histogram */
>
> +/* Vendor specific - used for IPU3 camera sub-system */
> +#define V4L2_META_FMT_RK_ISP1_PARAMS v4l2_fourcc('R', 'K', '1', 'P') /*
> Rockchip ISP1 params */
> +#define V4L2_META_FMT_RK_ISP1_STAT_3Av4l2_fourcc('R', 'K', '1', 'S')
> /* Rockchip ISP1 3A statistics */
> +
> /* priv field value to indicates that subsequent fields are valid. */
> #define V4L2_PIX_FMT_PRIV_MAGIC 0xfeedcafe
>
>
Re: [PATCH 0/3] Improve CEC autorepeat handling
On Mon, Nov 27, 2017 at 09:47:24AM +, Sean Young wrote: > Hi Hans, > > On Mon, Nov 27, 2017 at 10:13:51AM +0100, Hans Verkuil wrote: > > On 11/26/2017 12:47 AM, Dmitry Torokhov wrote: > > > On Fri, Nov 24, 2017 at 11:43:58AM +, Sean Young wrote: > > >> Due to the slowness of the CEC bus, autorepeat handling rather special > > >> on CEC. If the repeated user control pressed message is received, a > > >> keydown repeat should be sent immediately. > > > > > > This sounds like you want to have hardware autorepeat combined with > > > software one. This seems fairly specific to CEC and I do not think that > > > this should be in input core; but stay in the driver. > > > > > > Another option just to decide what common delay for CEC autorepeat is > > > and rely on the standard autorepeat handling. The benefit is that users > > > can control the delay before autorepeat kicks in. > > > > They are not allowed to. Autorepeat is only allowed to start when a second > > keydown message arrives within 550 ms as per the spec. After that autorepeat > > continues as long as keydown messages are received within 550ms from the > > previous one. The actual REP_PERIOD time is unrelated to the frequency of > > the CEC messages but should be that of the local system. Not allowed by whom? If I, as a user, want my remote to start autorepeating after 400 msec instead of 550, will the police come and fine me? Please do not confuse the default behavior with allowed one. The only restriction is that if you have not seen messages for longer than 550 msecs you should "release" the key. > > > > The thing to remember here is that CEC is slooow (400 bits/s) so you cannot > > send messages at REP_PERIOD rate. You should see it as messages that tell > > you to enter/stay in autorepeat mode. Not as actual autorepeat messages. Right, and they do not have to match autorepeat timings, just control whether we should continue repeating or generate release event. > > > > > > > >> > > >> By handling this in the input layer, we can remove some ugly code from > > >> cec, which also sends a keyup event after the first keydown, to prevent > > >> autorepeat. > > > > > > If driver does not want input core to handle autorepeat (but handle > > > autorepeat by themselves) they should indicate it by setting appropriate > > > dev->rep[REP_DELAY] and dev->rep[REP_PERIOD] before calling > > > input_register_device(). This will let input core know that it should > > > not setup its autorepeat timer. > > > > That only means that I have to setup the autorepeat timer myself, there > > is no benefit in that :-) > > > > Sean, I kind of agree with Dmitry here. The way autorepeat works for CEC > > is pretty specific to that protocol and unlikely to be needed for other > > protocols. > > That's a valid point, I guess. The only downside is special case handling > outside the input layer, which would be much simpler in the input layer. > > > It is also no big deal to keep knowledge of that within cec-adap.c. > > So first of all, the sii8620 uses the CEC protocol as well (see commit > e25f1f7c94e1 drm/bridge/sii8620: add remote control support), so this > will have to go into rc-core, not cec-adap.c. There was a discussion about > some time ago. > > The current implementation has an ugly key up event which would be nice > to do without. > > > The only thing that would be nice to have control over is that with CEC > > userspace shouldn't be able to change REP_DELAY and that REP_DELAY should > > always be identical to REP_PERIOD. If this can be done easily, then that > > would be nice, but it's a nice-to-have in my opinion. You could do that by catching EV_REP events in your driver, but I do not see why you want to remove this flexibility from users. Again, if I want to wait for autorepeat to start for 10 seconds, or 10 msecs, it is my choice. You are to provide the default, I am to override it if I want. > > The REP_DELAY must be equal to REP_PERIOD seems a bit odd to me. In fact, > I propose something different. If REP_DELAY != 0 then the input layer > produces autorepeats as normal. If REP_DELAY == 0, then generate repeats > on the second key down event. I have no idea why you simply not rely on current input core autorepeat handling, set REP_DELAY to be 550 msec and call it a day. Thanks. -- Dmitry
Re: [PATCH 0/3] Improve CEC autorepeat handling
On 11/27/2017 10:47 AM, Sean Young wrote:
> Hi Hans,
>
> On Mon, Nov 27, 2017 at 10:13:51AM +0100, Hans Verkuil wrote:
>> On 11/26/2017 12:47 AM, Dmitry Torokhov wrote:
>>> On Fri, Nov 24, 2017 at 11:43:58AM +, Sean Young wrote:
Due to the slowness of the CEC bus, autorepeat handling rather special
on CEC. If the repeated user control pressed message is received, a
keydown repeat should be sent immediately.
>>>
>>> This sounds like you want to have hardware autorepeat combined with
>>> software one. This seems fairly specific to CEC and I do not think that
>>> this should be in input core; but stay in the driver.
>>>
>>> Another option just to decide what common delay for CEC autorepeat is
>>> and rely on the standard autorepeat handling. The benefit is that users
>>> can control the delay before autorepeat kicks in.
>>
>> They are not allowed to. Autorepeat is only allowed to start when a second
>> keydown message arrives within 550 ms as per the spec. After that autorepeat
>> continues as long as keydown messages are received within 550ms from the
>> previous one. The actual REP_PERIOD time is unrelated to the frequency of
>> the CEC messages but should be that of the local system.
>>
>> The thing to remember here is that CEC is slooow (400 bits/s) so you cannot
>> send messages at REP_PERIOD rate. You should see it as messages that tell
>> you to enter/stay in autorepeat mode. Not as actual autorepeat messages.
>>
>>>
By handling this in the input layer, we can remove some ugly code from
cec, which also sends a keyup event after the first keydown, to prevent
autorepeat.
>>>
>>> If driver does not want input core to handle autorepeat (but handle
>>> autorepeat by themselves) they should indicate it by setting appropriate
>>> dev->rep[REP_DELAY] and dev->rep[REP_PERIOD] before calling
>>> input_register_device(). This will let input core know that it should
>>> not setup its autorepeat timer.
>>
>> That only means that I have to setup the autorepeat timer myself, there
>> is no benefit in that :-)
>>
>> Sean, I kind of agree with Dmitry here. The way autorepeat works for CEC
>> is pretty specific to that protocol and unlikely to be needed for other
>> protocols.
>
> That's a valid point, I guess. The only downside is special case handling
> outside the input layer, which would be much simpler in the input layer.
>
>> It is also no big deal to keep knowledge of that within cec-adap.c.
>
> So first of all, the sii8620 uses the CEC protocol as well (see commit
> e25f1f7c94e1 drm/bridge/sii8620: add remote control support), so this
> will have to go into rc-core, not cec-adap.c. There was a discussion about
> some time ago.
Ah yes, that's true. But it still is specific to the CEC protocol, the code
handling that would just move to rc-core from cec-adap.c
>
> The current implementation has an ugly key up event which would be nice
> to do without.
>
>> The only thing that would be nice to have control over is that with CEC
>> userspace shouldn't be able to change REP_DELAY and that REP_DELAY should
>> always be identical to REP_PERIOD. If this can be done easily, then that
>> would be nice, but it's a nice-to-have in my opinion.
>
> The REP_DELAY must be equal to REP_PERIOD seems a bit odd to me. In fact,
> I propose something different. If REP_DELAY != 0 then the input layer
> produces autorepeats as normal. If REP_DELAY == 0, then generate repeats
> on the second key down event.
>
> See patch below.
That looks nice! I'm fine with that.
Regards,
Hans
>
> Thanks,
> Sean
>
> From 3f439e326888a0ab8688d73c4276ac87b4225b1c Mon Sep 17 00:00:00 2001
> From: Sean Young
> Date: Thu, 23 Nov 2017 22:37:10 +
> Subject: [PATCH] media: cec: move cec autorepeat handling to rc-core
>
> CEC autorepeat is different than other protocols. Autorepeat is triggered
> by the first repeated user control pressed CEC message, rather than a
> fixed REP_DELAY.
>
> This change also does away with the KEY_UP event directly after the first
> KEY_DOWN event, which was used to stop autorepeat from starting.
>
> See commit a9a249a2c997 ("media: cec: fix remote control passthrough")
> for the original change.
>
> Signed-off-by: Sean Young
> ---
> drivers/media/cec/cec-adap.c | 56
>
> drivers/media/cec/cec-core.c | 12 --
> drivers/media/rc/rc-main.c | 45 +--
> include/media/cec.h | 5
> include/media/rc-core.h | 3 +++
> 5 files changed, 51 insertions(+), 70 deletions(-)
>
> diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
> index 98f88c43f62c..258a91800963 100644
> --- a/drivers/media/cec/cec-adap.c
> +++ b/drivers/media/cec/cec-adap.c
> @@ -1788,9 +1788,6 @@ static int cec_receive_notify(struct cec_adapter *adap,
> struct cec_msg *msg,
> int la_idx = cec_log_addr2idx(adap, dest_laddr);
> bool from_unregistered = init_la
Re: [PATCH v4 00/12] Intel IPU3 ImgU patchset
Hi Rajmohan, On 11/17/2017 03:58 AM, Mani, Rajmohan wrote: > Hi Sakari and all, > >> -Original Message- >> From: Zhi, Yong >> Sent: Tuesday, October 17, 2017 8:47 PM >> To: linux-media@vger.kernel.org; sakari.ai...@linux.intel.com >> Cc: Zheng, Jian Xu ; Mani, Rajmohan >> ; Toivonen, Tuukka >> ; Hu, Jerry W ; >> a...@arndb.de; h...@lst.de; robin.mur...@arm.com; iommu@lists.linux- >> foundation.org; Zhi, Yong >> Subject: [PATCH v4 00/12] Intel IPU3 ImgU patchset >> >> This patchset adds support for the Intel IPU3 (Image Processing Unit) ImgU >> which is essentially a modern memory-to-memory ISP. It implements raw >> Bayer to YUV image format conversion as well as a large number of other pixel >> processing algorithms for improving the image quality. >> >> Meta data formats are defined for image statistics (3A, i.e. automatic white >> balance, exposure and focus, histogram and local area contrast >> enhancement) as well as for the pixel processing algorithm parameters. >> The documentation for these formats is currently not included in the patchset >> but will be added in a future version of this set. >> > > Here is an update on the IPU3 documentation that we are currently working on. > > Image processing in IPU3 relies on the following. > > 1) HW configuration to enable ISP and > 2) setting customer specific 3A Tuning / Algorithm Parameters to achieve > desired image quality. > > We intend to provide documentation on ImgU driver programming interface to > help users of this driver to configure and enable ISP HW to meet their needs. > This documentation will include details on complete V4L2 Kernel driver > interface and IO-Control parameters, except for the ISP internal algorithm > and its parameters (which is Intel proprietary IP). > > We will also provide an user space library in binary form to help users of > this driver, to convert the public 3A tuning parameters to IPU3 algorithm > parameters. This tool will be released under NDA to the users of this driver. So I discussed this situation with Sakari in Prague during the ELCE. I am not happy with adding a driver to the kernel that needs an NDA to be usable. I can't agree to that. It's effectively the same as firmware that's only available under an NDA and we wouldn't accept such drivers either. There are a few options: 1) Document the ISP parameters and that format they are stored in allowing for open source implementations. While this is the ideal, I suspect that this is a no-go for Intel. 2) The driver can be used without using these ISP parameters and still achieve 'OK' quality. I.e., it's usable for basic webcam usage under normal lighting conditions. I'm not sure if this is possible at all, though. 3) Make the library available without requiring an NDA. 4) Provide a non-NDA library (ideally open source) that achieves at minimum the quality as described in 2: i.e. usable for basic webcam. 5) Other solutions I didn't think of? I think 4 might be the best option, especially if it is open sourced and just uses non-IP 3A algorithms. It could even be added to the v4l-utils git repo. A closed source non-NDA library might also work, but you will need to check what Mauro thinks about that. My problem is that such libraries tend to be abandoned after a few years and then bit-rot sets in. An open-source solution is much easier to maintain in the long term. Regards, Hans > >> The algorithm parameters need to be considered specific to a given frame and >> typically a large number of these parameters change on frame to frame basis. >> Additionally, the parameters are highly structured (and not a flat space of >> independent configuration primitives). They also reflect the data structures >> used by the firmware and the hardware. On top of that, the algorithms require >> highly specialized user space to make meaningful use of them. For these >> reasons it has been chosen video buffers to pass the parameters to the >> device. >> >> On individual patches: >> >> The heart of ImgU is the CSS, or Camera Subsystem, which contains the image >> processors and HW accelerators. >> >> The 3A statistics and other firmware parameter computation related functions >> are implemented in patch 8. >> >> All h/w programming related code can be found in patch 9. >> >> To access DDR via ImgU's own memory space, IPU3 is also equipped with its >> own MMU unit, the driver is implemented in patch 2. >> >> Currently, the MMU driver has dependency on two exported symbols >> (iommu_group_ref_get and iommu_group_get_for_dev))to build as ko. >> >> Patch 3 uses above IOMMU driver for DMA mem related functions. >> >> Patch 5-10 are basically IPU3 CSS specific implementations: >> >> 6 and 7 provide some utility functions and manage IPU3 fw download and >> install. >> >> The firmware which is called ipu3-fw.bin can be downloaded from: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git >> (commit 2c27b0cb02f1
Re: [PATCH 0/3] Improve CEC autorepeat handling
Hi Hans,
On Mon, Nov 27, 2017 at 10:13:51AM +0100, Hans Verkuil wrote:
> On 11/26/2017 12:47 AM, Dmitry Torokhov wrote:
> > On Fri, Nov 24, 2017 at 11:43:58AM +, Sean Young wrote:
> >> Due to the slowness of the CEC bus, autorepeat handling rather special
> >> on CEC. If the repeated user control pressed message is received, a
> >> keydown repeat should be sent immediately.
> >
> > This sounds like you want to have hardware autorepeat combined with
> > software one. This seems fairly specific to CEC and I do not think that
> > this should be in input core; but stay in the driver.
> >
> > Another option just to decide what common delay for CEC autorepeat is
> > and rely on the standard autorepeat handling. The benefit is that users
> > can control the delay before autorepeat kicks in.
>
> They are not allowed to. Autorepeat is only allowed to start when a second
> keydown message arrives within 550 ms as per the spec. After that autorepeat
> continues as long as keydown messages are received within 550ms from the
> previous one. The actual REP_PERIOD time is unrelated to the frequency of
> the CEC messages but should be that of the local system.
>
> The thing to remember here is that CEC is slooow (400 bits/s) so you cannot
> send messages at REP_PERIOD rate. You should see it as messages that tell
> you to enter/stay in autorepeat mode. Not as actual autorepeat messages.
>
> >
> >>
> >> By handling this in the input layer, we can remove some ugly code from
> >> cec, which also sends a keyup event after the first keydown, to prevent
> >> autorepeat.
> >
> > If driver does not want input core to handle autorepeat (but handle
> > autorepeat by themselves) they should indicate it by setting appropriate
> > dev->rep[REP_DELAY] and dev->rep[REP_PERIOD] before calling
> > input_register_device(). This will let input core know that it should
> > not setup its autorepeat timer.
>
> That only means that I have to setup the autorepeat timer myself, there
> is no benefit in that :-)
>
> Sean, I kind of agree with Dmitry here. The way autorepeat works for CEC
> is pretty specific to that protocol and unlikely to be needed for other
> protocols.
That's a valid point, I guess. The only downside is special case handling
outside the input layer, which would be much simpler in the input layer.
> It is also no big deal to keep knowledge of that within cec-adap.c.
So first of all, the sii8620 uses the CEC protocol as well (see commit
e25f1f7c94e1 drm/bridge/sii8620: add remote control support), so this
will have to go into rc-core, not cec-adap.c. There was a discussion about
some time ago.
The current implementation has an ugly key up event which would be nice
to do without.
> The only thing that would be nice to have control over is that with CEC
> userspace shouldn't be able to change REP_DELAY and that REP_DELAY should
> always be identical to REP_PERIOD. If this can be done easily, then that
> would be nice, but it's a nice-to-have in my opinion.
The REP_DELAY must be equal to REP_PERIOD seems a bit odd to me. In fact,
I propose something different. If REP_DELAY != 0 then the input layer
produces autorepeats as normal. If REP_DELAY == 0, then generate repeats
on the second key down event.
See patch below.
Thanks,
Sean
>From 3f439e326888a0ab8688d73c4276ac87b4225b1c Mon Sep 17 00:00:00 2001
From: Sean Young
Date: Thu, 23 Nov 2017 22:37:10 +
Subject: [PATCH] media: cec: move cec autorepeat handling to rc-core
CEC autorepeat is different than other protocols. Autorepeat is triggered
by the first repeated user control pressed CEC message, rather than a
fixed REP_DELAY.
This change also does away with the KEY_UP event directly after the first
KEY_DOWN event, which was used to stop autorepeat from starting.
See commit a9a249a2c997 ("media: cec: fix remote control passthrough")
for the original change.
Signed-off-by: Sean Young
---
drivers/media/cec/cec-adap.c | 56
drivers/media/cec/cec-core.c | 12 --
drivers/media/rc/rc-main.c | 45 +--
include/media/cec.h | 5
include/media/rc-core.h | 3 +++
5 files changed, 51 insertions(+), 70 deletions(-)
diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index 98f88c43f62c..258a91800963 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -1788,9 +1788,6 @@ static int cec_receive_notify(struct cec_adapter *adap,
struct cec_msg *msg,
int la_idx = cec_log_addr2idx(adap, dest_laddr);
bool from_unregistered = init_laddr == 0xf;
struct cec_msg tx_cec_msg = { };
-#ifdef CONFIG_MEDIA_CEC_RC
- int scancode;
-#endif
dprintk(2, "%s: %*ph\n", __func__, msg->len, msg->msg);
@@ -1886,9 +1883,11 @@ static int cec_receive_notify(struct cec_adapter *adap,
struct cec_msg *msg,
*/
case 0x60:
if (msg->len == 2)
-
[PATCH] dvb_frontend: fix ifnullfree.cocci warnings
drivers/media/dvb-core/dvb_frontend.c:154:2-7: WARNING: NULL check before
freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or
usb_free_urb is not needed. Maybe consider reorganizing relevant code to avoid
passing NULL values.
NULL check before some freeing functions is not needed.
Based on checkpatch warning
"kfree(NULL) is safe this check is probably not required"
and kfreeaddr.cocci by Julia Lawall.
Generated by: scripts/coccinelle/free/ifnullfree.cocci
Fixes: b1cb7372fa82 ("dvb_frontend: don't use-after-free the frontend struct")
Signed-off-by: Fengguang Wu
---
dvb_frontend.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -150,8 +150,7 @@ static void __dvb_frontend_free(struct d
dvb_frontend_invoke_release(fe, fe->ops.release);
- if (fepriv)
- kfree(fepriv);
+ kfree(fepriv);
}
static void dvb_frontend_free(struct kref *ref)
drivers/media/dvb-core/dvb_frontend.c:154:2-7: WARNING: NULL check before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not needed. Maybe consider reorganiz
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323 commit: b1cb7372fa822af6c06c8045963571d13ad6348b dvb_frontend: don't use-after-free the frontend struct date: 3 weeks ago coccinelle warnings: (new ones prefixed by >>) >> drivers/media/dvb-core/dvb_frontend.c:154:2-7: WARNING: NULL check before >> freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or >> usb_free_urb is not needed. Maybe consider reorganizing relevant code to >> avoid passing NULL values. Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH 0/3] Improve CEC autorepeat handling
On 11/26/2017 12:47 AM, Dmitry Torokhov wrote: > Hi Sean, > > On Fri, Nov 24, 2017 at 11:43:58AM +, Sean Young wrote: >> Due to the slowness of the CEC bus, autorepeat handling rather special >> on CEC. If the repeated user control pressed message is received, a >> keydown repeat should be sent immediately. > > This sounds like you want to have hardware autorepeat combined with > software one. This seems fairly specific to CEC and I do not think that > this should be in input core; but stay in the driver. > > Another option just to decide what common delay for CEC autorepeat is > and rely on the standard autorepeat handling. The benefit is that users > can control the delay before autorepeat kicks in. They are not allowed to. Autorepeat is only allowed to start when a second keydown message arrives within 550 ms as per the spec. After that autorepeat continues as long as keydown messages are received within 550ms from the previous one. The actual REP_PERIOD time is unrelated to the frequency of the CEC messages but should be that of the local system. The thing to remember here is that CEC is slooow (400 bits/s) so you cannot send messages at REP_PERIOD rate. You should see it as messages that tell you to enter/stay in autorepeat mode. Not as actual autorepeat messages. > >> >> By handling this in the input layer, we can remove some ugly code from >> cec, which also sends a keyup event after the first keydown, to prevent >> autorepeat. > > If driver does not want input core to handle autorepeat (but handle > autorepeat by themselves) they should indicate it by setting appropriate > dev->rep[REP_DELAY] and dev->rep[REP_PERIOD] before calling > input_register_device(). This will let input core know that it should > not setup its autorepeat timer. That only means that I have to setup the autorepeat timer myself, there is no benefit in that :-) Sean, I kind of agree with Dmitry here. The way autorepeat works for CEC is pretty specific to that protocol and unlikely to be needed for other protocols. It is also no big deal to keep knowledge of that within cec-adap.c. The only thing that would be nice to have control over is that with CEC userspace shouldn't be able to change REP_DELAY and that REP_DELAY should always be identical to REP_PERIOD. If this can be done easily, then that would be nice, but it's a nice-to-have in my opinion. Regards, Hans
