cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Sep 26 05:00:11 CEST 2018 media-tree git hash:4158757395b300b6eb308fc20b96d1d231484413 media_build git hash: 44385b9c61ecc27059a651885895c8ea09cd4179 v4l-utils git hash: 3874aa8eb1ff0c2e103d024ba5af915b1b26f098 edid-decode git hash: 5eeb151a748788666534d6ea3da07f90400d24c2 gcc version:i686-linux-gcc (GCC) 8.1.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.18.0-1-amd64 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-arm64: OK linux-git-i686: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK Check COMPILE_TEST: OK linux-3.10.108-i686: OK linux-3.10.108-x86_64: OK linux-3.11.10-i686: OK linux-3.11.10-x86_64: OK linux-3.12.74-i686: OK linux-3.12.74-x86_64: OK linux-3.13.11-i686: OK linux-3.13.11-x86_64: OK linux-3.14.79-i686: OK linux-3.14.79-x86_64: OK linux-3.15.10-i686: OK linux-3.15.10-x86_64: OK linux-3.16.57-i686: OK linux-3.16.57-x86_64: OK linux-3.17.8-i686: OK linux-3.17.8-x86_64: OK linux-3.18.119-i686: OK linux-3.18.119-x86_64: OK linux-3.19.8-i686: OK linux-3.19.8-x86_64: OK linux-4.0.9-i686: OK linux-4.0.9-x86_64: OK linux-4.1.52-i686: OK linux-4.1.52-x86_64: OK linux-4.2.8-i686: OK linux-4.2.8-x86_64: OK linux-4.3.6-i686: OK linux-4.3.6-x86_64: OK linux-4.4.152-i686: OK linux-4.4.152-x86_64: OK linux-4.5.7-i686: OK linux-4.5.7-x86_64: OK linux-4.6.7-i686: OK linux-4.6.7-x86_64: OK linux-4.7.10-i686: OK linux-4.7.10-x86_64: OK linux-4.8.17-i686: OK linux-4.8.17-x86_64: OK linux-4.9.124-i686: OK linux-4.9.124-x86_64: OK linux-4.10.17-i686: OK linux-4.10.17-x86_64: OK linux-4.11.12-i686: OK linux-4.11.12-x86_64: OK linux-4.12.14-i686: OK linux-4.12.14-x86_64: OK linux-4.13.16-i686: OK linux-4.13.16-x86_64: OK linux-4.14.67-i686: OK linux-4.14.67-x86_64: OK linux-4.15.18-i686: OK linux-4.15.18-x86_64: OK linux-4.16.18-i686: OK linux-4.16.18-x86_64: OK linux-4.17.19-i686: OK linux-4.17.19-x86_64: OK linux-4.18.5-i686: OK linux-4.18.5-x86_64: OK linux-4.19-rc1-i686: OK linux-4.19-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
[PATCH v7] media: add imx319 camera sensor driver
From: Bingbu Cao Add a v4l2 sub-device driver for the Sony imx319 image sensor. This is a camera sensor using the i2c bus for control and the csi-2 bus for data. This driver supports following features: - manual exposure and analog/digital gain control support - vblank/hblank control support - 4 test patterns control support - vflip/hflip control support (will impact the output bayer order) - support following resolutions: - 3264x2448, 3280x2464 @ 30fps - 1936x1096, 1920x1080 @ 60fps - 1640x1232, 1640x922, 1296x736, 1280x720 @ 120fps - support 4 bayer orders output (via change v/hflip) - SRGGB10(default), SGRBG10, SGBRG10, SBGGR10 Cc: Tomasz Figa Cc: Sakari Ailus Signed-off-by: Bingbu Cao Signed-off-by: Tianshu Qiu --- This patch is based on sakari's media-tree git: https://git.linuxtv.org/sailus/media_tree.git/log/?h=for-4.20-1 Changes from v5: - add some comments for gain calculation - use lock to protect the format - fix some style issues Changes from v4 to v5: - use single PLL for all internal clocks - change link frequency to 482.4MHz - adjust frame timing for 2x2 binning modes and enlarge frame readout time - get CSI-2 link frequencies and external clock from firmware - use unlocked __v4l2_ctrl_grab() with change from: https://git.linuxtv.org/sailus/media_tree.git/commit/?h=unlocked-ctrl-grab Changes since v1: - fix some coding style issues - line breaks - add v4l2_ctrl_grab() to prevent v/hflip change during streaming - add v4l2 ctrl event (un)subscribe support - add more info into commit message --- --- MAINTAINERS|7 + drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/imx319.c | 2556 4 files changed, 2575 insertions(+) create mode 100644 drivers/media/i2c/imx319.c diff --git a/MAINTAINERS b/MAINTAINERS index a5b256b25905..abc4abb6f83c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13530,6 +13530,13 @@ S: Maintained F: drivers/media/i2c/imx274.c F: Documentation/devicetree/bindings/media/i2c/imx274.txt +SONY IMX319 SENSOR DRIVER +M: Bingbu Cao +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +S: Maintained +F: drivers/media/i2c/imx319.c + SONY MEMORYSTICK CARD SUPPORT M: Alex Dubov W: http://tifmxx.berlios.de/ diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index bfdb494686bf..603ac087975b 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -614,6 +614,17 @@ config VIDEO_IMX274 This is a V4L2 sensor driver for the Sony IMX274 CMOS image sensor. +config VIDEO_IMX319 + tristate "Sony IMX319 sensor support" + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API + depends on MEDIA_CAMERA_SUPPORT + help + This is a Video4Linux2 sensor driver for the Sony + IMX319 camera. + + To compile this driver as a module, choose M here: the + module will be called imx319. + config VIDEO_OV2640 tristate "OmniVision OV2640 sensor support" depends on VIDEO_V4L2 && I2C diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index a94eb03d10d4..d10b438577be 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -108,5 +108,6 @@ obj-$(CONFIG_VIDEO_OV2659) += ov2659.o obj-$(CONFIG_VIDEO_TC358743) += tc358743.o obj-$(CONFIG_VIDEO_IMX258) += imx258.o obj-$(CONFIG_VIDEO_IMX274) += imx274.o +obj-$(CONFIG_VIDEO_IMX319) += imx319.o obj-$(CONFIG_SDR_MAX2175) += max2175.o diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c new file mode 100644 index ..e10d60f500dd --- /dev/null +++ b/drivers/media/i2c/imx319.c @@ -0,0 +1,2556 @@ +// SPDX-License-Identifier: GPL-2.0 +// Copyright (C) 2018 Intel Corporation + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define IMX319_REG_MODE_SELECT 0x0100 +#define IMX319_MODE_STANDBY0x00 +#define IMX319_MODE_STREAMING 0x01 + +/* Chip ID */ +#define IMX319_REG_CHIP_ID 0x0016 +#define IMX319_CHIP_ID 0x0319 + +/* V_TIMING internal */ +#define IMX319_REG_FLL 0x0340 +#define IMX319_FLL_MAX 0x + +/* Exposure control */ +#define IMX319_REG_EXPOSURE0x0202 +#define IMX319_EXPOSURE_MIN1 +#define IMX319_EXPOSURE_STEP 1 +#define IMX319_EXPOSURE_DEFAULT0x04f6 + +/* + * the digital control register for all color control looks like: + * +-+--+ + * | [7:0] | [15:8] | + * +-+--+ + * |0x020f | 0x020e | + * -- + * it is used to calculate the digital gain times value(integral + fractional) + * the [15:8] bits is the
RE: [PATCH v5] media: imx208: Add imx208 camera sensor driver
Hi Sakari,
>-Original Message-
>From: Sakari Ailus [mailto:sakari.ai...@linux.intel.com]
>Sent: Wednesday, September 26, 2018 5:55 AM
>Hi Ping-chung,
>On Tue, Sep 25, 2018 at 10:17:48AM +, Chen, Ping-chung wrote:
>...
> > > > Controls that have a documented unit use that unit --- as long
> > > > as that's the unit used by the hardware. If it's not, it tends
> > > > to be that another unit is used but the user space has currently
> > > > no way of knowing this. And the digital gain control is no exception to
> > > > this.
> > > >
> > > > So if we want to improve the user space's ability to be informed
> > > > how the control values reflect to device configuration, we do
> > > > need to provide more information to the user space. One way to
> > > > do that would be through VIDIOC_QUERY_EXT_CTRL. The IOCTL struct
> > > > has plenty of reserved fields --- just for purposes such as this one.
> > >
> > > I don't think we can come up with a good way to expose arbitrary
> > > mathematical formulas through an ioctl. In my opinion the question
> > > is how far we want to go, how precise we need to be.
> > >
> > > > > Any opinions or better ideas?
> >
> > >My 0.02 DKK. On a similar situation, where userspace was running a close
> > >loop calibration:
> >
> > >We have implemented two extra control: eposure_next exposure_pre that tell
> > >us which one is the next value. Perhaps we could embebed such
> > >functionality in QUERY_EXT_CTRL.
> >
> > >Cheers
> >
> > How about creating an additional control to handle the case of
> > V4L2_CID_GAIN in the imx208 driver? HAL can set AG and DG separately
> > for the general sensor usage by V4L2_CID_ANALOGUE_GAIN and
> > V4L2_CID_DIGITAL_GAIN but call V4L2_CID_GAIN for the condition of
> > setting total_gain=AGxDG.
>
> >How do you update the two other controls if the user updates the
> >V4L2_CID_GAIN control?
>
> In imx208 driver:
>
> Add two pointers *digital_gain and *analog_gain of v4l2_ctrl in the global
> structure imx208.
> static int imx208_init_controls(struct imx208 *imx208) {
> Imx208->digital_gain = v4l2_ctrl_new_std(..., V4L2_CID_DIGITAL_GAIN,
> Imx208->...); analog_gain =
> Imx208->v4l2_ctrl_new_std(...,V4L2_CID_ANALOGUE_GAIN, ...);
>
> static int imx208_set_ctrl(struct v4l2_ctrl *ctrl) { ...
> case V4L2_CID_ANALOGUE_GAIN:
> ret = imx208_write_reg(imx208, IMX208_REG_ANALOG_GAIN, 2,
> ctrl->val);
> break;
> case V4L2_CID_DIGITAL_GAIN:
> ret = imx208_update_digital_gain(imx208, 2, ctrl->val);
> break;
> case V4L2_CID_ GAIN:
> ret = imx208_update_gain(imx208, 2, ctrl->val); // total gain
> break;
> }
>
> Then the implementation of imx208_update_gain():
> static int imx208_update_gain(struct imx208 *imx208, u32 len, u32 val)
> {
> digital_gain = (val - 1) / ag_max;
> digital_gain = map_to_real_DG(digital_gain);// map to 1x,
> 2x, 4x, 8x, 16x
> digital_gain_code = digital_gain << 8 // DGx256 for
> DG_code
> ret = imx208_update_digital_gain(imx208, 2, digital_gain_code);
> imx208->digital_gain->val = digital_gain_code;
> analog_gain = val/digital_gain;
> analog_gain_code = SMIA_AG_to_Code(analog_gain); // AG =
> 256/(256-ag_code)
> ret = imx208_write_reg(imx208, IMX208_REG_ANALOG_GAIN, 2,
> analog_gain_code);
> imx208->digital_gain->val = analog_gain_code;
>How about putting this piece of code to the user space instead?
>Some work would be needed to generalise it in order for it to work on other
>sensors that do need >digital gain applied, too --- assuming it'd be combined
>with the TRY_EXT_CTRLS rounding flags.
There might be many kinds of discrete DG formats. For imx208, DG=2^n, but for
other sensors, DG could be 2*n, 5*n, or other styles. If HAL needs to cover all
cases, kernel will have to update more information to this control.
Another problem is should HAL take over the SMIA calculation? If so, kernel
will also need to update SMIA parameters to user space (or create an addition
filed for SMIA in the configuration XML file).
Thanks,
PC Chen
>--
>Kind regards,
>Sakari Ailus
>sakari.ai...@linux.intel.com
Editing for 5
Want editing for your photos? We can help you for this. We can do cutting out and retouching for your ecommerce photos, jewelry photos retouching, portrait photos or wedding photos. Turnaround time is fast Send us one photo, we wil do testing for you. Thanks, Heather
Editing for 5
Want editing for your photos? We can help you for this. We can do cutting out and retouching for your ecommerce photos, jewelry photos retouching, portrait photos or wedding photos. Turnaround time is fast Send us one photo, we wil do testing for you. Thanks, Heather
Re: [PATCH v5] media: imx208: Add imx208 camera sensor driver
Hi Ping-chung,
On Tue, Sep 25, 2018 at 10:17:48AM +, Chen, Ping-chung wrote:
...
> > > > Controls that have a documented unit use that unit --- as long as
> > > > that's the unit used by the hardware. If it's not, it tends to be
> > > > that another unit is used but the user space has currently no way
> > > > of knowing this. And the digital gain control is no exception to this.
> > > >
> > > > So if we want to improve the user space's ability to be informed
> > > > how the control values reflect to device configuration, we do need
> > > > to provide more information to the user space. One way to do that
> > > > would be through VIDIOC_QUERY_EXT_CTRL. The IOCTL struct has
> > > > plenty of reserved fields --- just for purposes such as this one.
> > >
> > > I don't think we can come up with a good way to expose arbitrary
> > > mathematical formulas through an ioctl. In my opinion the question
> > > is how far we want to go, how precise we need to be.
> > >
> > > > > Any opinions or better ideas?
> >
> > >My 0.02 DKK. On a similar situation, where userspace was running a close
> > >loop calibration:
> >
> > >We have implemented two extra control: eposure_next exposure_pre that tell
> > >us which one is the next value. Perhaps we could embebed such
> > >functionality in QUERY_EXT_CTRL.
> >
> > >Cheers
> >
> > How about creating an additional control to handle the case of
> > V4L2_CID_GAIN in the imx208 driver? HAL can set AG and DG separately
> > for the general sensor usage by V4L2_CID_ANALOGUE_GAIN and
> > V4L2_CID_DIGITAL_GAIN but call V4L2_CID_GAIN for the condition of
> > setting total_gain=AGxDG.
>
> >How do you update the two other controls if the user updates the
> >V4L2_CID_GAIN control?
>
> In imx208 driver:
>
> Add two pointers *digital_gain and *analog_gain of v4l2_ctrl in the global
> structure imx208.
> static int imx208_init_controls(struct imx208 *imx208) {
> Imx208->digital_gain = v4l2_ctrl_new_std(..., V4L2_CID_DIGITAL_GAIN, ...);
> Imx208->analog_gain = v4l2_ctrl_new_std(...,V4L2_CID_ANALOGUE_GAIN, ...);
>
> static int imx208_set_ctrl(struct v4l2_ctrl *ctrl)
> {
> ...
> case V4L2_CID_ANALOGUE_GAIN:
> ret = imx208_write_reg(imx208, IMX208_REG_ANALOG_GAIN, 2,
> ctrl->val);
> break;
> case V4L2_CID_DIGITAL_GAIN:
> ret = imx208_update_digital_gain(imx208, 2, ctrl->val);
> break;
> case V4L2_CID_ GAIN:
> ret = imx208_update_gain(imx208, 2, ctrl->val); // total gain
> break;
> }
>
> Then the implementation of imx208_update_gain():
> static int imx208_update_gain(struct imx208 *imx208, u32 len, u32 val)
> {
> digital_gain = (val - 1) / ag_max;
> digital_gain = map_to_real_DG(digital_gain);// map to 1x,
> 2x, 4x, 8x, 16x
> digital_gain_code = digital_gain << 8 // DGx256 for
> DG_code
> ret = imx208_update_digital_gain(imx208, 2, digital_gain_code);
> imx208->digital_gain->val = digital_gain_code;
> analog_gain = val/digital_gain;
> analog_gain_code = SMIA_AG_to_Code(analog_gain); // AG =
> 256/(256-ag_code)
> ret = imx208_write_reg(imx208, IMX208_REG_ANALOG_GAIN, 2,
> analog_gain_code);
> imx208->digital_gain->val = analog_gain_code;
How about putting this piece of code to the user space instead?
Some work would be needed to generalise it in order for it to work on other
sensors that do need digital gain applied, too --- assuming it'd be
combined with the TRY_EXT_CTRLS rounding flags.
--
Kind regards,
Sakari Ailus
sakari.ai...@linux.intel.com
[PATCH v3] media: docs: add glossary.rst with common terms used at V4L2 spec
From: Mauro Carvalho Chehab Add a glossary of terms used within the media userspace API documentation, as several concepts are complex enough to cause misunderstandings. Signed-off-by: Mauro Carvalho Chehab --- v3: - Add SPDX header and dual-license the glossary - Make glossary generic enough to be used for all media uAPI documentation; - Add a few new items to the glossary, to imply that it covers not only V4L2; - Move it to the uAPI document as a hole. v2: Did some changes based on Sakari's feedback. Documentation/media/media_uapi.rst| 3 + Documentation/media/uapi/glossary.rst | 162 ++ 2 files changed, 165 insertions(+) create mode 100644 Documentation/media/uapi/glossary.rst diff --git a/Documentation/media/media_uapi.rst b/Documentation/media/media_uapi.rst index 28eb35a1f965..41f091a26003 100644 --- a/Documentation/media/media_uapi.rst +++ b/Documentation/media/media_uapi.rst @@ -2,6 +2,8 @@ .. include:: +.. _media_uapi: + Linux Media Infrastructure userspace API @@ -31,3 +33,4 @@ License". uapi/cec/cec-api uapi/gen-errors uapi/fdl-appendix +uapi/glossary diff --git a/Documentation/media/uapi/glossary.rst b/Documentation/media/uapi/glossary.rst new file mode 100644 index ..9e2a2b29e8b2 --- /dev/null +++ b/Documentation/media/uapi/glossary.rst @@ -0,0 +1,162 @@ +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-or-later + +.. For GPL-2.0, see LICENSES/preferred/GPL-2.0 +.. +.. For GFDL-1.1-or-later, see: +.. +.. Permission is granted to copy, distribute and/or modify this document +.. under the terms of the GNU Free Documentation License, Version 1.1 or +.. any later version published by the Free Software Foundation, with no +.. Invariant Sections, no Front-Cover Texts and no Back-Cover Texts. +.. A copy of the license is included at +.. Documentation/media/uapi/fdl-appendix.rst. + + +Glossary + + +.. note:: + + This goal of section is to standardize the terms used within the media + userspace API documentation. It is written incrementally as they are + standardized in the media documentation. + + So, it is a Work In Progress. + +.. Please keep the glossary entries in alphabetical order + +.. glossary:: + +Bridge driver + A device driver that implements the main logic to talk with + a media hardware. + + For V4L2 hardware, this is also known as V4L2 main driver. + +Consumer Electronics Control API + An API designed to receive and transmit data via a HDMI + CEC interface. + + See :ref:`cec`. + +Device Node + A character device node in the file system used to control and do + input/output data transfers from/to a Kernel driver. + +Digital TV API - DVB API + An API designed to control the media device components related to + digital TV, including frontends, demuxes, streaming, conditional + access, etc. + + See :ref:`dvbapi`. + +Digital Signal Processor - DSP + A specialized microprocessor, with its architecture optimized for + the operational needs of digital signal processing. + +Driver + Part of the Linux Kernel that implements support for a hardware + component. + +Field-programmable Gate Array - FPGA + A field-programmable gate array (FPGA) is an integrated circuit + designed to be configured by a customer or a designer after + manufacturing. + + See https://en.wikipedia.org/wiki/Field-programmable_gate_array. + +Inter-Integrated Circuit - I²C + A multi-master, multi-slave, packet switched, single-ended, + serial computer bus used to control some hardware components + like sub-device hardware components. + + See http://www.nxp.com/docs/en/user-guide/UM10204.pdf. + +Integrated circuit - IC + A set of electronic circuits on one small flat piece of + semiconductor material, normally silicon. + + Also known as chip. + +Intelectual property core - IP block + In electronic design a semiconductor intellectual property core, + is a reusable unit of logic, cell, or integrated circuit layout + design that is the intellectual property of one party. + IP cores may be licensed to another party or can be owned + and used by a single party alone. + + See https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core). + +Image Signal Processor - ISP + A specialised processor that implements a set of algorithms for + processing image data. ISPs may implement algorithms for lens + shading correction, demosaic, scaling and pixel format conversion + as well as produce statistics for the use of the control + algorithms (e.g. automatic exposure, white balance and focus). + +Media API + A set of userspace APIs used to control a media
[linuxtv-media:request_api 77/77] ERROR: "sunxi_sram_release" [drivers/staging/media/sunxi/cedrus/sunxi-cedrus.ko] undefined!
tree: git://linuxtv.org/media_tree.git request_api head: 50e761516f2b8c0cdeb31a8c6ca1b4ef98cd13f1 commit: 50e761516f2b8c0cdeb31a8c6ca1b4ef98cd13f1 [77/77] media: platform: Add Cedrus VPU decoder driver config: i386-allmodconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: git checkout 50e761516f2b8c0cdeb31a8c6ca1b4ef98cd13f1 # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): >> ERROR: "sunxi_sram_release" >> [drivers/staging/media/sunxi/cedrus/sunxi-cedrus.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Editing for 1
Want editing for your photos? We can help you for this. We can do cutting out and retouching for your ecommerce photos, jewelry photos retouching, portrait photos or wedding photos. Turnaround time is fast Send us one photo, we wil do testing for you. Thanks, Heather
Editing for 3
Want editing for your photos? We can help you for this. We can do cutting out and retouching for your ecommerce photos, jewelry photos retouching, portrait photos or wedding photos. Turnaround time is fast Send us one photo, we wil do testing for you. Thanks, Heather
Editing for 3
Want editing for your photos? We can help you for this. We can do cutting out and retouching for your ecommerce photos, jewelry photos retouching, portrait photos or wedding photos. Turnaround time is fast Send us one photo, we wil do testing for you. Thanks, Heather
Editing for 4
Want editing for your photos? We can help you for this. We can do cutting out and retouching for your ecommerce photos, jewelry photos retouching, portrait photos or wedding photos. Turnaround time is fast Send us one photo, we wil do testing for you. Thanks, Heather
Re: [PATCH v3 1/9] partial revert of "[media] tvp5150: add HW input connectors support"
On Tue, Sep 18, 2018 at 03:14:45PM +0200, Marco Felsch wrote:
> From: Javier Martinez Canillas
>
> Commit f7b4b54e6364 ("[media] tvp5150: add HW input connectors support")
> added input signals support for the tvp5150, but the approach was found
> to be incorrect so the corresponding DT binding commit 82c2ffeb217a
> ("[media] tvp5150: document input connectors DT bindings") was reverted.
>
> This left the driver with an undocumented (and wrong) DT parsing logic,
> so lets get rid of this code as well until the input connectors support
> is implemented properly.
>
> It's a partial revert due other patches added on top of mentioned commit
> not allowing the commit to be reverted cleanly anymore. But all the code
> related to the DT parsing logic and input entities creation are removed.
>
> Suggested-by: Laurent Pinchart
> Signed-off-by: Javier Martinez Canillas
> Acked-by: Laurent Pinchart
> [m.fel...@pengutronix.de: rm TVP5150_INPUT_NUM define]
> Signed-off-by: Marco Felsch
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/media/i2c/tvp5150.c | 141
> include/dt-bindings/media/tvp5150.h | 2 -
> 2 files changed, 143 deletions(-)
Acked-by: Rob Herring
[PATCH v2] media: docs: add glossary.rst with common terms used at V4L2 spec
From: Mauro Carvalho Chehab Add a glossary of terms for V4L2, as several concepts are complex enough to cause misunderstandings. Signed-off-by: Mauro Carvalho Chehab --- v2.: Did some changes based on Sakari's feedback. Documentation/media/media_uapi.rst| 2 + Documentation/media/uapi/v4l/glossary.rst | 118 ++ Documentation/media/uapi/v4l/v4l2.rst | 1 + 3 files changed, 121 insertions(+) create mode 100644 Documentation/media/uapi/v4l/glossary.rst diff --git a/Documentation/media/media_uapi.rst b/Documentation/media/media_uapi.rst index 28eb35a1f965..aebe48b98ad3 100644 --- a/Documentation/media/media_uapi.rst +++ b/Documentation/media/media_uapi.rst @@ -2,6 +2,8 @@ .. include:: +.. _media_uapi: + Linux Media Infrastructure userspace API diff --git a/Documentation/media/uapi/v4l/glossary.rst b/Documentation/media/uapi/v4l/glossary.rst new file mode 100644 index ..d91833255404 --- /dev/null +++ b/Documentation/media/uapi/v4l/glossary.rst @@ -0,0 +1,118 @@ + +Glossary + + +.. note:: + + This goal of section is to standardize the terms used within the media + userspace API documentation. It is written incrementally as they are + standardized in the media documentation. So, it is a Work In Progress. + +.. Please keep the glossary entries in alphabetical order + +.. glossary:: + +Bridge driver + The same as V4L2 main driver. + +Device Node + A character device node in the file system used to control and do + input/output data transfers from/to a Kernel driver. + +Digital Signal Processor - DSP + A specialized microprocessor, with its architecture optimized for + the operational needs of digital signal processing. + +Driver + The part of the Linux Kernel that implements support + for a hardware component. + +Field-programmable Gate Array - FPGA + A field-programmable gate array (FPGA) is an integrated circuit + designed to be configured by a customer or a designer after + manufacturing. + + See https://en.wikipedia.org/wiki/Field-programmable_gate_array. + +Inter-Integrated Circuit - I²C + A multi-master, multi-slave, packet switched, single-ended, + serial computer bus used to control V4L2 sub-devices. + + See http://www.nxp.com/docs/en/user-guide/UM10204.pdf. + +Integrated circuit - IC + A set of electronic circuits on one small flat piece of + semiconductor material, normally silicon. + + Also known as chip. + +Intelectual property core - IP block + In electronic design a semiconductor intellectual property core, + is a reusable unit of logic, cell, or integrated circuit layout + design that is the intellectual property of one party. + IP cores may be licensed to another party or can be owned + and used by a single party alone. + + See https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core). + +Image Signal Processor - ISP + A specialised processor that implements a set of algorithms for + processing image data. ISPs may implement algorithms for lens + shading correction, demosaic, scaling and pixel format conversion + as well as produce statistics for the use of the control + algorithms (e.g. automatic exposure, white balance and focus). + +Media Controller + An API designed to expose and control devices and sub-devices' + relationships to applications. + + See :ref:`media_controller`. + +Media Hardware +The parts of a hardware that are supported by the Linux + media API (see :ref:`media_uapi`). + + Includes audio and video capture and playback hardware, + digital and analog TV, camera sensors, ISPs, remote controllers, + codecs, HDMI Consumer Electronics Control, HDMI capture, etc. + +Microprocessor + An electronic circuitry that carries out the instructions + of a computer program by performing the basic arithmetic, logical, + control and input/output (I/O) operations specified by the + instructions on a single integrated circuit. + +SMBus + A subset of I²C, with defines a stricter usage of the bus. + +Serial Peripheral Interface Bus - SPI + Synchronous serial communication interface specification used for + short distance communication, primarily in embedded systems. + +System on a Chip - SoC + An integrated circuit that integrates all components of a computer + or other electronic systems. + +Sub-device hardware components + V4L2 hardware components that aren't controlled by the + V4L2 main driver. + +V4L2 userspace API - V4L2 API + The userspace API defined at :ref:`v4l2spec`, with is used + to control a V4L2 hardware. + +V4L2 hardware + Part of
Re: [PATCH 1/3] media: add glossary.rst with common terms used at V4L2 spec
Em Tue, 25 Sep 2018 16:03:57 +0300 Sakari Ailus escreveu: > Hi Mauro, > > Thanks for the set! A few quick comments below, mainly additions and language. > > On Tue, Sep 25, 2018 at 09:06:51AM -0300, Mauro Carvalho Chehab wrote: > > From: Mauro Carvalho Chehab > > > > Add a glossary of terms for V4L2, as several concepts are complex > > enough to cause misunderstandings. > > > > Signed-off-by: Mauro Carvalho Chehab > > --- > > Documentation/media/uapi/v4l/glossary.rst | 108 ++ > > Documentation/media/uapi/v4l/v4l2.rst | 1 + > > 2 files changed, 109 insertions(+) > > create mode 100644 Documentation/media/uapi/v4l/glossary.rst > > > > diff --git a/Documentation/media/uapi/v4l/glossary.rst > > b/Documentation/media/uapi/v4l/glossary.rst > > new file mode 100644 > > index ..3dff6430d79f > > --- /dev/null > > +++ b/Documentation/media/uapi/v4l/glossary.rst > > @@ -0,0 +1,108 @@ > > + > > +Glossary > > + > > + > > +.. note:: > > + > > + This goal of section is to standardize the terms used within the V4L2 > > + documentation. It is written incrementally as they are standardized in > > + the V4L2 documentation. So, it is a Work In Progress. > > + > > +.. Please keep the glossary entries in alphabetical order > > + > > +.. glossary:: > > + > > +Bridge driver > > + The same as V4L2 main driver. > > + > > +Device Node > > + A character device node in the file system used to control and do > > + input/output data transfers from/to a Kernel driver. > > + > > +Digital Signal Processor - DSP > > + A specialized microprocessor, with its architecture optimized for > > + the operational needs of digital signal processing. > > + > > +Driver > > + The part of the Linux Kernel that implements support > > + for a hardware component. > > + > > +Field-programmable Gate Array - FPGA > > + A field-programmable gate array (FPGA) is an integrated circuit > > + designed to be configured by a customer or a designer after > > + manufacturing. > > + > > + See https://en.wikipedia.org/wiki/Field-programmable_gate_array. > > + > > +Inter-Integrated Circuit - I²C > > + A multi-master, multi-slave, packet switched, single-ended, > > + serial computer bus used to control V4L2 sub-devices. > > + > > + See http://www.nxp.com/docs/en/user-guide/UM10204.pdf. > > + > > +Integrated circuit - IC > > + A set of electronic circuits on one small flat piece of > > + semiconductor material, normally silicon. > > + > > + Also known as chip. > > + > > +IP block > > + The same as IP core. > > + > > +Intelectual property core - IP core > > + In electronic design a semiconductor intellectual property core, > > + is a reusable unit of logic, cell, or integrated circuit layout > > + design that is the intellectual property of one party. > > + IP cores may be licensed to another party or can be owned > > + and used by a single party alone. > > "Intellectual property" is not really the main point here, but I don't > object. You could use "hardware block" as well; I think that could be more > commonly used. > > Either way, we should be fine with just one of "IP block" and "IP core". Let's stick with IP block then. "IP is "Intelectual Property", so we need to use it at the glossary. > > > + > > + See > > https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core). > > + > > +Image Signal Processor - ISP > > + A specialised processor that implements a set of algorithms for > > + processing image data. ISPs may implement algorithms for lens > > + shading correction, demosaic, scaling and pixel format conversion > > + as well as produce statistics for the use of the control > > + algorithms (e.g. automatic exposure, white balance and focus). > > + > > +Media Controller > > + An API designed to expose and control devices and sub-devices > > + relationships to applications. > > + > > + See :ref:`media_controller`. > > Could you also add: > > Media device > > A device node that implements the Media controller interface. Used > to access the Media device complex besides the V4L2 and V4L2 > sub-device nodes. > > Media hardware complex > > A collection of hardware components that together constitute an > complex that can be seen as a single device. An example of this is > a raw Bayer camera and an ISP that processes the images from the > camera before writing them to system memory. I prefer to keep those more polemic terms to a next patchset. Yeah, I know that we ended by coming with that "complex" term, but the more I heard it, the less I like using it on that context. Anyway, I'm having some ideas that could prevent us the need of using a complex[1] term like that, but for now, let's skip this discussion, merging only the parts that won't cause discussions. [1] "complex" in the sense that it produces complex
Re: [PATCH 0/3] Add a glossary and fix some issues at open.rst docs
On Tue, Sep 25, 2018 at 09:06:50AM -0300, Mauro Carvalho Chehab wrote: > Those three patches were part of an attempt to add definitions for > some terms used at the media subsystem: > > https://lwn.net/Articles/732022/ > > On that time, the first patch generated heated discussions, on terms > related to mc-centric/vdev-centric. The cern of the discussions were > how to call the subdev API and the non-subdev API part of the > video4linux API. > > I ended by being side-tracked by other things, and didn't have a chance > to submit an updated version. > > Well, now I'm doing things differently: at the glossary.rst, I removed > everything related to hardware control. So, it should contain only the > terms that there aren't any divergences. So, I hope we can manage to > merge it this time. > > After having this series merged, I'll address again the MC/vdev centric > hardware control on a separate patchset, perhaps using a different > approach together with the new glossary definitions related > to it. > > Mauro Carvalho Chehab (3): > media: add glossary.rst with common terms used at V4L2 spec > media: open.rst: better document device node naming > media: open.rst: remove the minor number range For patches 2 and 3: Acked-by: Sakari Ailus -- Sakari Ailus e-mail: sakari.ai...@iki.fi
Re: [PATCH 1/3] media: add glossary.rst with common terms used at V4L2 spec
Hi Mauro, Thanks for the set! A few quick comments below, mainly additions and language. On Tue, Sep 25, 2018 at 09:06:51AM -0300, Mauro Carvalho Chehab wrote: > From: Mauro Carvalho Chehab > > Add a glossary of terms for V4L2, as several concepts are complex > enough to cause misunderstandings. > > Signed-off-by: Mauro Carvalho Chehab > --- > Documentation/media/uapi/v4l/glossary.rst | 108 ++ > Documentation/media/uapi/v4l/v4l2.rst | 1 + > 2 files changed, 109 insertions(+) > create mode 100644 Documentation/media/uapi/v4l/glossary.rst > > diff --git a/Documentation/media/uapi/v4l/glossary.rst > b/Documentation/media/uapi/v4l/glossary.rst > new file mode 100644 > index ..3dff6430d79f > --- /dev/null > +++ b/Documentation/media/uapi/v4l/glossary.rst > @@ -0,0 +1,108 @@ > + > +Glossary > + > + > +.. note:: > + > + This goal of section is to standardize the terms used within the V4L2 > + documentation. It is written incrementally as they are standardized in > + the V4L2 documentation. So, it is a Work In Progress. > + > +.. Please keep the glossary entries in alphabetical order > + > +.. glossary:: > + > +Bridge driver > + The same as V4L2 main driver. > + > +Device Node > + A character device node in the file system used to control and do > + input/output data transfers from/to a Kernel driver. > + > +Digital Signal Processor - DSP > + A specialized microprocessor, with its architecture optimized for > + the operational needs of digital signal processing. > + > +Driver > + The part of the Linux Kernel that implements support > + for a hardware component. > + > +Field-programmable Gate Array - FPGA > + A field-programmable gate array (FPGA) is an integrated circuit > + designed to be configured by a customer or a designer after > + manufacturing. > + > + See https://en.wikipedia.org/wiki/Field-programmable_gate_array. > + > +Inter-Integrated Circuit - I²C > + A multi-master, multi-slave, packet switched, single-ended, > + serial computer bus used to control V4L2 sub-devices. > + > + See http://www.nxp.com/docs/en/user-guide/UM10204.pdf. > + > +Integrated circuit - IC > + A set of electronic circuits on one small flat piece of > + semiconductor material, normally silicon. > + > + Also known as chip. > + > +IP block > + The same as IP core. > + > +Intelectual property core - IP core > + In electronic design a semiconductor intellectual property core, > + is a reusable unit of logic, cell, or integrated circuit layout > + design that is the intellectual property of one party. > + IP cores may be licensed to another party or can be owned > + and used by a single party alone. "Intellectual property" is not really the main point here, but I don't object. You could use "hardware block" as well; I think that could be more commonly used. Either way, we should be fine with just one of "IP block" and "IP core". > + > + See > https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core). > + > +Image Signal Processor - ISP > + A specialised processor that implements a set of algorithms for > + processing image data. ISPs may implement algorithms for lens > + shading correction, demosaic, scaling and pixel format conversion > + as well as produce statistics for the use of the control > + algorithms (e.g. automatic exposure, white balance and focus). > + > +Media Controller > + An API designed to expose and control devices and sub-devices > + relationships to applications. > + > + See :ref:`media_controller`. Could you also add: Media device A device node that implements the Media controller interface. Used to access the Media device complex besides the V4L2 and V4L2 sub-device nodes. Media hardware complex A collection of hardware components that together constitute an complex that can be seen as a single device. An example of this is a raw Bayer camera and an ISP that processes the images from the camera before writing them to system memory. > + > +MC-centric > + V4L2 hardware that requires a Media controller. How about: Hardware the image data pipeline configuration of which requires the use of Media controller and V4L2 sub-device interfaces. > + > +Microprocessor > + An electronic circuitry that carries out the instructions > + of a computer program by performing the basic arithmetic, logical, > + control and input/output (I/O) operations specified by the > + instructions on a single integrated circuit. > + > +SMBus > + A subset of I²C, with defines a stricter usage of the bus. > + > +Serial Peripheral Interface Bus - SPI > + Synchronous serial communication interface specification used for > + short distance communication, primarily in embedded
Re: [PATCH 0/5] Add units to controls
Hi Helmut, Thanks for the comments. On Tue, Sep 25, 2018 at 01:48:02PM +0200, Helmut Grohne wrote: > On Tue, Sep 25, 2018 at 12:14:29PM +0200, Sakari Ailus wrote: > > This set adds a few things to the current control framework in terms of > > what kind of information the user space may have on controls. It adds > > support for units and prefixes, exponential base as well as information on > > whether a control is linear or exponential, to struct v4l2_query_ext_ctrl. > > That's a great improvement. Being able to give meaning to controls is > great. However, I see two significant weaknesses in the approach being > taken: > > 1. There are a number of controls whose value is not easily described as >either linear or exponential. I'm faced with at least two controls >that actually are floating point numbers. One with two bits for the >exponent and one (strange) bit for the mantissa (no joke) and another >with three bits for the exponent and four bits for the mantissa. >Neither can suitably be represented. > >Since the value ranges are small for the cases I mentioned, I looked >into using an integer menu. The present approach does not allow for >replacing an integer with an integer menu though. Each control id has >a fixed type. I'm not sure how to solve this. The proposal does not address all potential situations, that's true. There's no way to try to represent everything out there (without enumerating the values) in an easily generalised way but something can be done. There are devices such as some flash LED controllers where the flash current if simply a value you can pick from the list. It's currently implemented as an integer control. AFAIR the driver is drivers/leds/leds-aat1290.c . > > 2. The present implementation places the responsibility of assigning >units and scales into drivers. A number of controls (e.g. >V4L2_CID_EXPOSURE_ABSOLUTE, V4L2_CID_AUDIO_LIMITER_RELEASE_TIME, >V4L2_CID_PIXEL_RATE, ...) clearly state the scale and unit in the >documentation. Having each and every driver set units and scales in >the documented way will lead to duplication and buggy code. Having >each driver choose unit and scale will lead to inconsistency. It >would be very good to have a mechanism that puts the framework in >charge of maintaining units and scales for the standard control ids. > >What is a consumer supposed to do with a control that changes unit? >The algorithm expected e.g. a duration. It might be able to convert >to pixels, but what should it do if it gets back amperes? I argue >that the unit should be a property of the control id and be >documented (i.e. what is done now). If it is reported via an ioctl, The fact is that the unit is specific to hardware. The documentation documents something, and often suggests a unit, but if the hardware does something else, then that's what you get --- independently of what the documentation says. Hence the need to convey it via the API. Some controls could have the unit set by the framework if that makes sense. Most drivers shouldn't actually need to touch this if they're fine with defaults (whenever a control has a default). >the framework needs to be in charge of setting it. > >The story is much different for scales. Scaling the value up and down >is something consumers can reasonably be expected to do. It allows >shifting the value range such that the relevant values can be fully >represented. Allowing drivers to change scales is much more >reasonable. Still the framework should provide a default such that >most drivers should not need any update. > > I acknowledge that these expectations are high and see that they're > partially covered in your later remarks. > > > The smiapp driver gains support for the feature. In the near term, some > > controls could also be assigned the unit automatically. The pixel rate, > > for instance. Fewer driver changes would be needed this way. A driver > > could override the value if there's a need to. > > I believe that in the interest of keeping maintenance cost low, this > should happen rather sooner than later. Just even adding the support to > smiapp seems wrong when it would be possible to have the framework do > the work. > > > I think I'll merge the undefined and no unit cases. Same for the > > exponential base actually --- the flag can be removed, too... > > I'm not sure I understand. It reads like you are going to revert a > significant part of the patch. A macro or two, it's not a major change. From the user space point of view, does it make a difference if a control has no unit or when it's not known what the unit is? > > > Regarding Ricardo's suggestion --- I was thinking of adding a control flag > > (yes, there are a few bits available) to tell how to round the value. The > > user could use the TRY_EXT_CTRLS IOCTL to figure out the next (or > > previous) control value by
[PATCH 1/3] media: add glossary.rst with common terms used at V4L2 spec
From: Mauro Carvalho Chehab Add a glossary of terms for V4L2, as several concepts are complex enough to cause misunderstandings. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/v4l/glossary.rst | 108 ++ Documentation/media/uapi/v4l/v4l2.rst | 1 + 2 files changed, 109 insertions(+) create mode 100644 Documentation/media/uapi/v4l/glossary.rst diff --git a/Documentation/media/uapi/v4l/glossary.rst b/Documentation/media/uapi/v4l/glossary.rst new file mode 100644 index ..3dff6430d79f --- /dev/null +++ b/Documentation/media/uapi/v4l/glossary.rst @@ -0,0 +1,108 @@ + +Glossary + + +.. note:: + + This goal of section is to standardize the terms used within the V4L2 + documentation. It is written incrementally as they are standardized in + the V4L2 documentation. So, it is a Work In Progress. + +.. Please keep the glossary entries in alphabetical order + +.. glossary:: + +Bridge driver + The same as V4L2 main driver. + +Device Node + A character device node in the file system used to control and do + input/output data transfers from/to a Kernel driver. + +Digital Signal Processor - DSP + A specialized microprocessor, with its architecture optimized for + the operational needs of digital signal processing. + +Driver + The part of the Linux Kernel that implements support + for a hardware component. + +Field-programmable Gate Array - FPGA + A field-programmable gate array (FPGA) is an integrated circuit + designed to be configured by a customer or a designer after + manufacturing. + + See https://en.wikipedia.org/wiki/Field-programmable_gate_array. + +Inter-Integrated Circuit - I²C + A multi-master, multi-slave, packet switched, single-ended, + serial computer bus used to control V4L2 sub-devices. + + See http://www.nxp.com/docs/en/user-guide/UM10204.pdf. + +Integrated circuit - IC + A set of electronic circuits on one small flat piece of + semiconductor material, normally silicon. + + Also known as chip. + +IP block + The same as IP core. + +Intelectual property core - IP core + In electronic design a semiconductor intellectual property core, + is a reusable unit of logic, cell, or integrated circuit layout + design that is the intellectual property of one party. + IP cores may be licensed to another party or can be owned + and used by a single party alone. + + See https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core). + +Image Signal Processor - ISP + A specialised processor that implements a set of algorithms for + processing image data. ISPs may implement algorithms for lens + shading correction, demosaic, scaling and pixel format conversion + as well as produce statistics for the use of the control + algorithms (e.g. automatic exposure, white balance and focus). + +Media Controller + An API designed to expose and control devices and sub-devices + relationships to applications. + + See :ref:`media_controller`. + +MC-centric + V4L2 hardware that requires a Media controller. + +Microprocessor + An electronic circuitry that carries out the instructions + of a computer program by performing the basic arithmetic, logical, + control and input/output (I/O) operations specified by the + instructions on a single integrated circuit. + +SMBus + A subset of I²C, with defines a stricter usage of the bus. + +Serial Peripheral Interface Bus - SPI + Synchronous serial communication interface specification used for + short distance communication, primarily in embedded systems. + +System on a Chip - SoC + An integrated circuit that integrates all components of a computer + or other electronic systems. + +Sub-device hardware components + Hardware components that aren't controlled by the + V4L2 main driver. + +V4L2 main driver + The V4L2 device driver that implements the main logic to talk with + the V4L2 hardware. + + Also known as bridge driver. + +V4L2 sub-device + Part of the media hardware that it is implemented by a device + driver that is not part of the main V4L2 driver. + + See :ref:`subdev`. diff --git a/Documentation/media/uapi/v4l/v4l2.rst b/Documentation/media/uapi/v4l/v4l2.rst index b89e5621ae69..74b397a8d033 100644 --- a/Documentation/media/uapi/v4l/v4l2.rst +++ b/Documentation/media/uapi/v4l/v4l2.rst @@ -32,6 +32,7 @@ This part describes the Video for Linux API version 2 (V4L2 API) specification. videodev capture-example v4l2grab-example +glossary biblio -- 2.17.1
[PATCH 3/3] media: open.rst: remove the minor number range
From: Mauro Carvalho Chehab minor numbers use to range between 0 to 255, but that was changed a long time ago. While it still applies when CONFIG_VIDEO_FIXED_MINOR_RANGES, when the minor number is dynamically allocated, this may not be true. In any case, this is not relevant, as udev will take care of it. So, remove this useless misinformation. Acked-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/v4l/open.rst | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/Documentation/media/uapi/v4l/open.rst b/Documentation/media/uapi/v4l/open.rst index 7e7aad784388..18030131ef77 100644 --- a/Documentation/media/uapi/v4l/open.rst +++ b/Documentation/media/uapi/v4l/open.rst @@ -19,11 +19,10 @@ helper functions and a common application interface specified in this document. Each driver thus loaded registers one or more device nodes with major -number 81 and a minor number between 0 and 255. Minor numbers are -allocated dynamically unless the kernel is compiled with the kernel -option CONFIG_VIDEO_FIXED_MINOR_RANGES. In that case minor numbers -are allocated in ranges depending on the device node type (video, radio, -etc.). +number 81. Minor numbers are allocated dynamically unless the kernel +is compiled with the kernel option CONFIG_VIDEO_FIXED_MINOR_RANGES. +In that case minor numbers are allocated in ranges depending on the +device node type. The existing V4L2 device node types are: -- 2.17.1
[PATCH 2/3] media: open.rst: better document device node naming
From: Mauro Carvalho Chehab Right now, only kAPI documentation describes the device naming. However, such description is needed at the uAPI too. Add it, and describe how to get an unique identify for a given device. Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/v4l/open.rst | 44 +-- 1 file changed, 41 insertions(+), 3 deletions(-) diff --git a/Documentation/media/uapi/v4l/open.rst b/Documentation/media/uapi/v4l/open.rst index afd116edb40d..7e7aad784388 100644 --- a/Documentation/media/uapi/v4l/open.rst +++ b/Documentation/media/uapi/v4l/open.rst @@ -7,12 +7,14 @@ Opening and Closing Devices *** -Device Naming -= +.. _v4l2_device_naming: + +V4L2 Device Node Naming +=== V4L2 drivers are implemented as kernel modules, loaded manually by the system administrator or automatically when a device is first discovered. -The driver modules plug into the "videodev" kernel module. It provides +The driver modules plug into the ``videodev`` kernel module. It provides helper functions and a common application interface specified in this document. @@ -23,6 +25,42 @@ option CONFIG_VIDEO_FIXED_MINOR_RANGES. In that case minor numbers are allocated in ranges depending on the device node type (video, radio, etc.). +The existing V4L2 device node types are: + + == +Default device node name Usage + == +``/dev/videoX`` Video input/output devices +``/dev/vbiX`` Vertical blank data (i.e. closed captions, teletext) +``/dev/radioX`` Radio tuners and modulators +``/dev/swradioX`` Software Defined Radio tuners and modulators +``/dev/v4l-touchX`` Touch sensors + == + +Where ``X`` is a non-negative number. + +.. note:: + + 1. The actual device node name is system-dependent, as udev rules may apply. + 2. There is no guarantee that ``X`` will remain the same for the same + device, as the number depends on the device driver's probe order. + If you need an unique name, udev default rules produce + ``/dev/v4l/by-id/`` and ``/dev/v4l/by-path/`` directories containing + links that can be used uniquely to identify a V4L2 device node:: + + $ tree /dev/v4l + /dev/v4l + ├── by-id + │ └── usb-OmniVision._USB_Camera-B4.04.27.1-video-index0 -> ../../video0 + └── by-path + └── pci-:00:14.0-usb-0:2:1.0-video-index0 -> ../../video0 + + 3. **V4L2 sub-device nodes** (e. g. ``/dev/v4l-sudevX``) provide a + different API and aren't considered as V4L2 device nodes. + + They are covered at :ref:`subdev`. + + Many drivers support "video_nr", "radio_nr" or "vbi_nr" module options to select specific video/radio/vbi node numbers. This allows the user to request that the device node is named e.g. /dev/video5 instead -- 2.17.1
[PATCH 0/3] Add a glossary and fix some issues at open.rst docs
Those three patches were part of an attempt to add definitions for some terms used at the media subsystem: https://lwn.net/Articles/732022/ On that time, the first patch generated heated discussions, on terms related to mc-centric/vdev-centric. The cern of the discussions were how to call the subdev API and the non-subdev API part of the video4linux API. I ended by being side-tracked by other things, and didn't have a chance to submit an updated version. Well, now I'm doing things differently: at the glossary.rst, I removed everything related to hardware control. So, it should contain only the terms that there aren't any divergences. So, I hope we can manage to merge it this time. After having this series merged, I'll address again the MC/vdev centric hardware control on a separate patchset, perhaps using a different approach together with the new glossary definitions related to it. Mauro Carvalho Chehab (3): media: add glossary.rst with common terms used at V4L2 spec media: open.rst: better document device node naming media: open.rst: remove the minor number range Documentation/media/uapi/v4l/glossary.rst | 108 ++ Documentation/media/uapi/v4l/open.rst | 53 +-- Documentation/media/uapi/v4l/v4l2.rst | 1 + 3 files changed, 154 insertions(+), 8 deletions(-) create mode 100644 Documentation/media/uapi/v4l/glossary.rst -- 2.17.1
Re: [PATCH 0/5] Add units to controls
On Tue, Sep 25, 2018 at 12:14:29PM +0200, Sakari Ailus wrote: > This set adds a few things to the current control framework in terms of > what kind of information the user space may have on controls. It adds > support for units and prefixes, exponential base as well as information on > whether a control is linear or exponential, to struct v4l2_query_ext_ctrl. That's a great improvement. Being able to give meaning to controls is great. However, I see two significant weaknesses in the approach being taken: 1. There are a number of controls whose value is not easily described as either linear or exponential. I'm faced with at least two controls that actually are floating point numbers. One with two bits for the exponent and one (strange) bit for the mantissa (no joke) and another with three bits for the exponent and four bits for the mantissa. Neither can suitably be represented. Since the value ranges are small for the cases I mentioned, I looked into using an integer menu. The present approach does not allow for replacing an integer with an integer menu though. Each control id has a fixed type. I'm not sure how to solve this. 2. The present implementation places the responsibility of assigning units and scales into drivers. A number of controls (e.g. V4L2_CID_EXPOSURE_ABSOLUTE, V4L2_CID_AUDIO_LIMITER_RELEASE_TIME, V4L2_CID_PIXEL_RATE, ...) clearly state the scale and unit in the documentation. Having each and every driver set units and scales in the documented way will lead to duplication and buggy code. Having each driver choose unit and scale will lead to inconsistency. It would be very good to have a mechanism that puts the framework in charge of maintaining units and scales for the standard control ids. What is a consumer supposed to do with a control that changes unit? The algorithm expected e.g. a duration. It might be able to convert to pixels, but what should it do if it gets back amperes? I argue that the unit should be a property of the control id and be documented (i.e. what is done now). If it is reported via an ioctl, the framework needs to be in charge of setting it. The story is much different for scales. Scaling the value up and down is something consumers can reasonably be expected to do. It allows shifting the value range such that the relevant values can be fully represented. Allowing drivers to change scales is much more reasonable. Still the framework should provide a default such that most drivers should not need any update. I acknowledge that these expectations are high and see that they're partially covered in your later remarks. > The smiapp driver gains support for the feature. In the near term, some > controls could also be assigned the unit automatically. The pixel rate, > for instance. Fewer driver changes would be needed this way. A driver > could override the value if there's a need to. I believe that in the interest of keeping maintenance cost low, this should happen rather sooner than later. Just even adding the support to smiapp seems wrong when it would be possible to have the framework do the work. > I think I'll merge the undefined and no unit cases. Same for the > exponential base actually --- the flag can be removed, too... I'm not sure I understand. It reads like you are going to revert a significant part of the patch. > Regarding Ricardo's suggestion --- I was thinking of adding a control flag > (yes, there are a few bits available) to tell how to round the value. The > user could use the TRY_EXT_CTRLS IOCTL to figure out the next (or > previous) control value by incrementing the current value and setting the > appropriate flag. This is out of the scope of this set though. This approach sounds really useful to me. Having control over the rounding would allow reading supported control values with reasonable effort. With such an approach, a very sparsely populated control becomes feasible and with integer64 controls that'd likely allow representing most exponential controls with linear values. If going this route, I don't see an application of V4L2_CTRL_FLAG_EXPONENTIAL. Thus, I think that control over the rounding is tightly related to this patchset and needs to be discussed together. Helmut
Re: [PATCH 3/5] Documentation: media: Document control exponential bases, units, prefixes
On Tue, Sep 25, 2018 at 12:39:56PM +0200, Helmut Grohne wrote: > On Tue, Sep 25, 2018 at 12:14:32PM +0200, Sakari Ailus wrote: > > +* - ``V4L2_CTRL_UNIT_PIXEL`` > > + - 5 > > + - A pixel in sensor's pixel matrix. This is a unit of time commonly > > used > > +by camera sensors in e.g. exposure control, i.e. the time it takes > > for > > + a sensor to read a pixel from the sensor's pixel matrix. > > + > > +* - ``V4L2_CTRL_UNIT_PIXEL`` > > + - 6 > > The latter V4L2_CTRL_UNIT_PIXEL looks like a typo that should say > V4L2_CTRL_UNIT_PIXELS_PER_SEC. Correct. I'll fix this for v2. Thanks! -- Sakari Ailus sakari.ai...@linux.intel.com
Re: [PATCH 3/5] Documentation: media: Document control exponential bases, units, prefixes
On Tue, Sep 25, 2018 at 12:14:32PM +0200, Sakari Ailus wrote: > +* - ``V4L2_CTRL_UNIT_PIXEL`` > + - 5 > + - A pixel in sensor's pixel matrix. This is a unit of time commonly > used > +by camera sensors in e.g. exposure control, i.e. the time it takes > for > + a sensor to read a pixel from the sensor's pixel matrix. > + > +* - ``V4L2_CTRL_UNIT_PIXEL`` > + - 6 The latter V4L2_CTRL_UNIT_PIXEL looks like a typo that should say V4L2_CTRL_UNIT_PIXELS_PER_SEC. Helmut
RE: [PATCH v5] media: imx208: Add imx208 camera sensor driver
Hi Sakari,
>-Original Message-
>From: Sakari Ailus [mailto:sakari.ai...@linux.intel.com]
>Sent: Tuesday, September 25, 2018 5:25 PM
>To: Chen, Ping-chung
>Cc: Ricardo Ribalda Delgado ; Laurent Pinchart
>Subject: Re: [PATCH v5] media: imx208: Add imx208 camera sensor driver
>Hi Ping-chung,
>On Fri, Sep 21, 2018 at 07:08:10AM +, Chen, Ping-chung wrote:
> Typo.
>
> -Original Message-
> From: Chen, Ping-chung
> Sent: Friday, September 21, 2018 3:07 PM
> To: 'Ricardo Ribalda Delgado' ; Laurent
> Pinchart
> Cc: Sakari Ailus ; tf...@chromium.org; Sakari
> Ailus ; sylwester.nawro...@gmail.com;
> linux-media ; Yeh, Andy
> ; Lai, Jim ;
> grund...@chromium.org; Mani, Rajmohan
> Subject: RE: [PATCH v5] media: imx208: Add imx208 camera sensor driver
>
> Hi Sakari,
>
> >-Original Message-
> >From: Ricardo Ribalda Delgado [mailto:ricardo.riba...@gmail.com]
> >Sent: Friday, September 21, 2018 5:55 AM
>
> >HI
> On Thu, Sep 20, 2018 at 11:13 PM Laurent Pinchart
> wrote:
> >
> > Hi Sakari,
> >
> > On Thursday, 20 September 2018 23:56:59 EEST Sakari Ailus wrote:
> > > On Thu, Sep 20, 2018 at 05:51:55PM +0900, Tomasz Figa wrote:
> > > > On Wed, Aug 8, 2018 at 4:08 PM Ping-chung Chen wrote:
> > > > [snip]
> > > >
> > > > > +
> > > > > +/* Digital gain control */
> > > > > +#define IMX208_REG_GR_DIGITAL_GAIN 0x020e
> > > > > +#define IMX208_REG_R_DIGITAL_GAIN 0x0210
> > > > > +#define IMX208_REG_B_DIGITAL_GAIN 0x0212
> > > > > +#define IMX208_REG_GB_DIGITAL_GAIN 0x0214
> > > > > +#define IMX208_DGTL_GAIN_MIN 0
> > > > > +#define IMX208_DGTL_GAIN_MAX 4096
> > > > > +#define IMX208_DGTL_GAIN_DEFAULT 0x100
> > > > > +#define IMX208_DGTL_GAIN_STEP 1
> > > > > +
> > > >
> > > > [snip]
> > > >
> > > > > +/* Initialize control handlers */ static int
> > > > > +imx208_init_controls(struct imx208 *imx208) {
> > > >
> > > > [snip]
> > > >
> > > > > + v4l2_ctrl_new_std(ctrl_hdlr, _ctrl_ops,
> > > > > V4L2_CID_DIGITAL_GAIN, + IMX208_DGTL_GAIN_MIN,
> > > > > IMX208_DGTL_GAIN_MAX, + IMX208_DGTL_GAIN_STEP,
> > > > > + IMX208_DGTL_GAIN_DEFAULT);
> > > >
> > > > We have a problem here. The sensor supports only a discrete
> > > > range of values here - {1, 2, 4, 8, 16} (multiplied by 256,
> > > > since the value is fixed point). This makes it possible for the
> > > > userspace to set values that are not allowed by the sensor
> > > > specification and also leaves no way to enumerate the supported values.
> > > >
> > > > I can see two solutions here:
> > > >
> > > > 1) Define the control range from 0 to 4 and treat it as an
> > > > exponent of 2, so that the value for the sensor becomes (1 << val) *
> > > > 256.
> > > > (Suggested by Sakari offline.)
> > > >
> > > > This approach has the problem of losing the original unit (and
> > > > scale) of the value.
> > >
> > > I'd like to add that this is not a property of the proposed solution.
> > >
> > > Rather, the above needs to be accompanied by additional
> > > information provided through VIDIOC_QUERY_EXT_CTRL, i.e. the unit,
> > > prefix as well as other information such as whether the control is
> > > linear or exponential (as in this case).
> > >
> > > > 2) Use an integer menu control, which reports only the supported
> > > > discrete values - {1, 2, 4, 8, 16}.
> > > >
> > > > With this approach, userspace can enumerate the real gain
> > > > values, but we would either need to introduce a new control (e.g.
> > > > V4L2_CID_DIGITAL_GAIN_DISCRETE) or abuse the specification and
> > > > register V4L2_CID_DIGITAL_GAIN as an integer menu.
> > >
> > > New controls in V4L2 are, for the most part, created when there's
> > > something new to control. The documentation of some controls
> > > (similar to e.g. gain) documents a unit as well as a prefix but
> > > that's the case only because there's been no way to tell the unit or
> > > prefix otherwise in the API.
> > >
> > > An exception to this are EXPOSURE and EXPOSURE_ABSOLUTE. I'm not
> > > entirely sure how they came to be though. An accident is a
> > > possibility as far as I see.
> >
> > If I remember correctly I introduced the absolute variant for the
> > UVC driver (even though git blame points to Brandon Philips). I
> > don't really remember why though.
> >
> > > Controls that have a documented unit use that unit --- as long as
> > > that's the unit used by the hardware. If it's not, it tends to be
> > > that another unit is used but the user space has currently no way
> > > of knowing this. And the digital gain control is no exception to this.
> > >
> > > So if we want to improve the user space's ability to be informed
> > > how the control values reflect to device configuration, we do need
> > > to provide more information to the user space. One way to do that
> > > would be through VIDIOC_QUERY_EXT_CTRL. The IOCTL struct has
> > > plenty of
[PATCH 4/5] v4l: controls: QUERY_EXT_CTRL support for base, prefix and unit
Add support for conveying the information set by the driver to the user
space.
Signed-off-by: Sakari Ailus
---
drivers/media/v4l2-core/v4l2-ctrls.c | 3 +++
include/media/v4l2-ctrls.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index ee006d34c19f0..8d2931b0a4701 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -2732,6 +2732,9 @@ int v4l2_query_ext_ctrl(struct v4l2_ctrl_handler *hdl,
struct v4l2_query_ext_ctr
qc->minimum = ctrl->minimum;
qc->maximum = ctrl->maximum;
qc->default_value = ctrl->default_value;
+ qc->base = ctrl->base;
+ qc->prefix = ctrl->prefix;
+ qc->unit = ctrl->unit;
if (ctrl->type == V4L2_CTRL_TYPE_MENU
|| ctrl->type == V4L2_CTRL_TYPE_INTEGER_MENU)
qc->step = 1;
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index f615ba1b29dd9..d6aaf45b70381 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -220,6 +220,8 @@ struct v4l2_ctrl {
u32 elem_size;
u32 dims[V4L2_CTRL_MAX_DIMS];
u32 nr_of_dims;
+ u8 base, unit;
+ u16 prefix;
union {
u64 step;
u64 menu_skip_mask;
--
2.11.0
[PATCH 2/5] v4l: controls: Add support for exponential bases, prefixes and units
Add support for exponential bases, prefixes as well as units for V4L2
controls. This makes it possible to convey information on the relation
between the control value and the hardware feature being controlled.
Signed-off-by: Sakari Ailus
---
include/uapi/linux/videodev2.h | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index ae083978988f1..23b02f2db85a1 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1652,6 +1652,32 @@ struct v4l2_queryctrl {
__u32reserved[2];
};
+/* V4L2 control exponential bases */
+#define V4L2_CTRL_BASE_UNDEFINED 0
+#define V4L2_CTRL_BASE_LINEAR 1
+#define V4L2_CTRL_BASE_2 2
+#define V4L2_CTRL_BASE_10 10
+
+/* V4L2 control unit prefixes */
+#define V4L2_CTRL_PREFIX_NANO -9
+#define V4L2_CTRL_PREFIX_MICRO -6
+#define V4L2_CTRL_PREFIX_MILLI -3
+#define V4L2_CTRL_PREFIX_1 0
+#define V4L2_CTRL_PREFIX_KILO 3
+#define V4L2_CTRL_PREFIX_MEGA 6
+#define V4L2_CTRL_PREFIX_GIGA 9
+
+/* V4L2 control units */
+#define V4L2_CTRL_UNIT_UNDEFINED 0
+#define V4L2_CTRL_UNIT_NONE1
+#define V4L2_CTRL_UNIT_SECOND 2
+#define V4L2_CTRL_UNIT_AMPERE 3
+#define V4L2_CTRL_UNIT_LINE4
+#define V4L2_CTRL_UNIT_PIXEL 5
+#define V4L2_CTRL_UNIT_PIXELS_PER_SEC 6
+#define V4L2_CTRL_UNIT_HZ 7
+
+
/* Used in the VIDIOC_QUERY_EXT_CTRL ioctl for querying extended controls */
struct v4l2_query_ext_ctrl {
__u32id;
@@ -1666,7 +1692,10 @@ struct v4l2_query_ext_ctrl {
__u32elems;
__u32nr_of_dims;
__u32dims[V4L2_CTRL_MAX_DIMS];
- __u32reserved[32];
+ __u8 base;
+ __s8 prefix;
+ __u16unit;
+ __u32reserved[31];
};
/* Used in the VIDIOC_QUERYMENU ioctl for querying menu items */
@@ -1692,6 +1721,7 @@ struct v4l2_querymenu {
#define V4L2_CTRL_FLAG_HAS_PAYLOAD 0x0100
#define V4L2_CTRL_FLAG_EXECUTE_ON_WRITE0x0200
#define V4L2_CTRL_FLAG_MODIFY_LAYOUT 0x0400
+#define V4L2_CTRL_FLAG_EXPONENTIAL 0x0800
/* Query flags, to be ORed with the control ID */
#define V4L2_CTRL_FLAG_NEXT_CTRL 0x8000
--
2.11.0
[PATCH 5/5] smiapp: Set control units
Assign units for the controls exposed by the smiapp driver. Signed-off-by: Sakari Ailus --- drivers/media/i2c/smiapp/smiapp-core.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/media/i2c/smiapp/smiapp-core.c b/drivers/media/i2c/smiapp/smiapp-core.c index 99f3b295ae3c7..289313c232430 100644 --- a/drivers/media/i2c/smiapp/smiapp-core.c +++ b/drivers/media/i2c/smiapp/smiapp-core.c @@ -562,17 +562,10 @@ static int smiapp_init_controls(struct smiapp_sensor *sensor) sensor->vblank = v4l2_ctrl_new_std( >pixel_array->ctrl_handler, _ctrl_ops, V4L2_CID_VBLANK, 0, 1, 1, 0); - - if (sensor->vblank) - sensor->vblank->flags |= V4L2_CTRL_FLAG_UPDATE; - sensor->hblank = v4l2_ctrl_new_std( >pixel_array->ctrl_handler, _ctrl_ops, V4L2_CID_HBLANK, 0, 1, 1, 0); - if (sensor->hblank) - sensor->hblank->flags |= V4L2_CTRL_FLAG_UPDATE; - sensor->pixel_rate_parray = v4l2_ctrl_new_std( >pixel_array->ctrl_handler, _ctrl_ops, V4L2_CID_PIXEL_RATE, 1, INT_MAX, 1, 1); @@ -589,6 +582,13 @@ static int smiapp_init_controls(struct smiapp_sensor *sensor) return sensor->pixel_array->ctrl_handler.error; } + sensor->exposure->unit = V4L2_CTRL_UNIT_LINE; + sensor->vblank->flags |= V4L2_CTRL_FLAG_UPDATE; + sensor->vblank->unit = V4L2_CTRL_UNIT_LINE; + sensor->hblank->flags |= V4L2_CTRL_FLAG_UPDATE; + sensor->hblank->unit = V4L2_CTRL_UNIT_PIXEL; + sensor->pixel_rate_parray->unit = V4L2_CTRL_UNIT_PIXELS_PER_SEC; + sensor->pixel_array->sd.ctrl_handler = >pixel_array->ctrl_handler; @@ -611,6 +611,8 @@ static int smiapp_init_controls(struct smiapp_sensor *sensor) return sensor->src->ctrl_handler.error; } + sensor->pixel_rate_csi->unit = V4L2_CTRL_UNIT_PIXELS_PER_SEC; + sensor->src->sd.ctrl_handler = >src->ctrl_handler; return 0; -- 2.11.0
[PATCH 1/5] videodev2.h: Use 8 hexadecimals (32 bits) for control flags
The V4L2 control flags are a 32-bit bitmask. Use 32-bit hexadecimal
numbers to specify the flags (was 16).
Signed-off-by: Sakari Ailus
---
Documentation/media/uapi/v4l/vidioc-queryctrl.rst | 22 +++---
include/uapi/linux/videodev2.h| 22 +++---
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/Documentation/media/uapi/v4l/vidioc-queryctrl.rst
b/Documentation/media/uapi/v4l/vidioc-queryctrl.rst
index 5bd26e8c9a1a0..ff2d131223b84 100644
--- a/Documentation/media/uapi/v4l/vidioc-queryctrl.rst
+++ b/Documentation/media/uapi/v4l/vidioc-queryctrl.rst
@@ -439,37 +439,37 @@ See also the examples in :ref:`control`.
:widths: 3 1 4
* - ``V4L2_CTRL_FLAG_DISABLED``
- - 0x0001
+ - 0x0001
- This control is permanently disabled and should be ignored by the
application. Any attempt to change the control will result in an
``EINVAL`` error code.
* - ``V4L2_CTRL_FLAG_GRABBED``
- - 0x0002
+ - 0x0002
- This control is temporarily unchangeable, for example because
another application took over control of the respective resource.
Such controls may be displayed specially in a user interface.
Attempts to change the control may result in an ``EBUSY`` error code.
* - ``V4L2_CTRL_FLAG_READ_ONLY``
- - 0x0004
+ - 0x0004
- This control is permanently readable only. Any attempt to change
the control will result in an ``EINVAL`` error code.
* - ``V4L2_CTRL_FLAG_UPDATE``
- - 0x0008
+ - 0x0008
- A hint that changing this control may affect the value of other
controls within the same control class. Applications should update
their user interface accordingly.
* - ``V4L2_CTRL_FLAG_INACTIVE``
- - 0x0010
+ - 0x0010
- This control is not applicable to the current configuration and
should be displayed accordingly in a user interface. For example
the flag may be set on a MPEG audio level 2 bitrate control when
MPEG audio encoding level 1 was selected with another control.
* - ``V4L2_CTRL_FLAG_SLIDER``
- - 0x0020
+ - 0x0020
- A hint that this control is best represented as a slider-like
element in a user interface.
* - ``V4L2_CTRL_FLAG_WRITE_ONLY``
- - 0x0040
+ - 0x0040
- This control is permanently writable only. Any attempt to read the
control will result in an ``EACCES`` error code error code. This flag
is typically present for relative controls or action controls
@@ -477,7 +477,7 @@ See also the examples in :ref:`control`.
action (e. g. motor control) but no meaningful value can be
returned.
* - ``V4L2_CTRL_FLAG_VOLATILE``
- - 0x0080
+ - 0x0080
- This control is volatile, which means that the value of the
control changes continuously. A typical example would be the
current gain value if the device is in auto-gain mode. In such a
@@ -493,7 +493,7 @@ See also the examples in :ref:`control`.
Setting a new value for a volatile control will *never* trigger a
:ref:`V4L2_EVENT_CTRL_CH_VALUE ` event.
* - ``V4L2_CTRL_FLAG_HAS_PAYLOAD``
- - 0x0100
+ - 0x0100
- This control has a pointer type, so its value has to be accessed
using one of the pointer fields of struct
:c:type:`v4l2_ext_control`. This flag is set
@@ -503,7 +503,7 @@ See also the examples in :ref:`control`.
* .. _FLAG_EXECUTE_ON_WRITE:
- ``V4L2_CTRL_FLAG_EXECUTE_ON_WRITE``
- - 0x0200
+ - 0x0200
- The value provided to the control will be propagated to the driver
even if it remains constant. This is required when the control
represents an action on the hardware. For example: clearing an
@@ -512,7 +512,7 @@ See also the examples in :ref:`control`.
* .. _FLAG_MODIFY_LAYOUT:
- ``V4L2_CTRL_FLAG_MODIFY_LAYOUT``
- - 0x0400
+ - 0x0400
- Changing this control value may modify the layout of the
buffer (for video devices) or the media bus format (for sub-devices).
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 184e4dbe8f9c0..ae083978988f1 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1681,17 +1681,17 @@ struct v4l2_querymenu {
} __attribute__ ((packed));
/* Control flags */
-#define V4L2_CTRL_FLAG_DISABLED0x0001
-#define V4L2_CTRL_FLAG_GRABBED 0x0002
-#define V4L2_CTRL_FLAG_READ_ONLY 0x0004
-#define V4L2_CTRL_FLAG_UPDATE 0x0008
-#define V4L2_CTRL_FLAG_INACTIVE0x0010
-#define V4L2_CTRL_FLAG_SLIDER 0x0020
-#define V4L2_CTRL_FLAG_WRITE_ONLY 0x0040
-#define V4L2_CTRL_FLAG_VOLATILE0x0080
-#define V4L2_CTRL_FLAG_HAS_PAYLOAD 0x0100
-#define
[PATCH 0/5] Add units to controls
Hi all, This set adds a few things to the current control framework in terms of what kind of information the user space may have on controls. It adds support for units and prefixes, exponential base as well as information on whether a control is linear or exponential, to struct v4l2_query_ext_ctrl. The smiapp driver gains support for the feature. In the near term, some controls could also be assigned the unit automatically. The pixel rate, for instance. Fewer driver changes would be needed this way. A driver could override the value if there's a need to. I think I'll merge the undefined and no unit cases. Same for the exponential base actually --- the flag can be removed, too... Regarding Ricardo's suggestion --- I was thinking of adding a control flag (yes, there are a few bits available) to tell how to round the value. The user could use the TRY_EXT_CTRLS IOCTL to figure out the next (or previous) control value by incrementing the current value and setting the appropriate flag. This is out of the scope of this set though. Comments, questions? Sakari Ailus (5): videodev2.h: Use 8 hexadecimals (32 bits) for control flags v4l: controls: Add support for exponential bases, prefixes and units Documentation: media: Document control exponential bases, units, prefixes v4l: controls: QUERY_EXT_CTRL support for base, prefix and unit smiapp: Set control units Documentation/media/uapi/v4l/extended-controls.rst | 2 + Documentation/media/uapi/v4l/vidioc-queryctrl.rst | 174 +++-- Documentation/media/videodev2.h.rst.exceptions | 22 +++ drivers/media/i2c/smiapp/smiapp-core.c | 16 +- drivers/media/v4l2-core/v4l2-ctrls.c | 3 + include/media/v4l2-ctrls.h | 2 + include/uapi/linux/videodev2.h | 54 +-- 7 files changed, 242 insertions(+), 31 deletions(-) -- 2.11.0
[PATCH 3/5] Documentation: media: Document control exponential bases, units, prefixes
Document V4L2 control exponential bases, units and prefixes, as well as
the control flag telling a control value is an exponent.
Signed-off-by: Sakari Ailus
---
Documentation/media/uapi/v4l/extended-controls.rst | 2 +
Documentation/media/uapi/v4l/vidioc-queryctrl.rst | 152 -
Documentation/media/videodev2.h.rst.exceptions | 22 +++
3 files changed, 175 insertions(+), 1 deletion(-)
diff --git a/Documentation/media/uapi/v4l/extended-controls.rst
b/Documentation/media/uapi/v4l/extended-controls.rst
index 9f7312bf33651..8461fd92d1b9e 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -3460,6 +3460,8 @@ Image Process Control IDs
by selecting the desired horizontal and vertical blanking. The unit
of this control is Hz.
+.. _v4l2_cid_pixel_rate:
+
``V4L2_CID_PIXEL_RATE (64-bit integer)``
Pixel rate in the source pads of the subdev. This control is
read-only and its unit is pixels / second.
diff --git a/Documentation/media/uapi/v4l/vidioc-queryctrl.rst
b/Documentation/media/uapi/v4l/vidioc-queryctrl.rst
index ff2d131223b84..472378f5d7566 100644
--- a/Documentation/media/uapi/v4l/vidioc-queryctrl.rst
+++ b/Documentation/media/uapi/v4l/vidioc-queryctrl.rst
@@ -269,8 +269,22 @@ See also the examples in :ref:`control`.
- ``dims[V4L2_CTRL_MAX_DIMS]``
- The size of each dimension. The first ``nr_of_dims`` elements of
this array must be non-zero, all remaining elements must be zero.
+* - __u8
+ - ``base``
+ - The exponential base of the control value. Valid only if the
+ :ref:`V4L2_CTRL_FLAG_EXPONENTIAL ` control flag is
+ set. This is an enumeration.
+* - __u8
+ - ``prefix``
+ - Prefix of the unit. This is an enumeration.
+* - __u16
+ - ``unit``
+ - Unit of the value. Together with the ``prefix`` as well as the ``base``
+ field (if :ref:`V4L2_CTRL_FLAG_EXPONENTIAL ` is set),
+ defines the relation between the control value and the property of the
+ hardware being controlled. This is an enumeration.
* - __u32
- - ``reserved``\ [32]
+ - ``reserved``\ [31]
- Reserved for future extensions. Applications and drivers must set
the array to zero.
@@ -523,6 +537,142 @@ See also the examples in :ref:`control`.
streaming is in progress since most drivers do not support changing
the format in that case.
+* .. _FLAG_EXPONENTIAL:
+
+ - ``V4L2_CTRL_FLAG_EXPONENTIAL``
+ - 0x0800
+
+ - The value of the control has an exponential relation to the feature
+ being controled instead of a linear relation. In other words, the value
+ of the control is an exponent of the base specified in the
+base field in v4l2_query_ext_ctrl.
+
+
+.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
+
+.. _control-bases:
+
+.. cssclass:: longtable
+
+.. flat-table:: Control Exponential Bases
+:header-rows: 1
+:stub-columns: 0
+:widths: 3 1 4
+
+* - Base Name
+ - Value
+ - Description
+
+* - ``V4L2_CTRL_BASE_UNDEFINED``
+ - 0
+ - The control exponential base is not defined.
+
+* - ``V4L2_CTRL_BASE_LINEAR``
+ - 1
+ - The control is linear.
+
+* - ``V4L2_CTRL_BASE_2``
+ - 2
+ - The base of the control is 2.
+
+* - ``V4L2_CTRL_BASE_10``
+ - 10
+ - The base of the control is 10.
+
+.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
+
+.. _control-prefixes:
+
+.. cssclass:: longtable
+
+.. flat-table:: Control Prefixes
+:header-rows: 1
+:stub-columns: 0
+:widths: 3 1 4
+
+* - Prefix Name
+ - Value
+ - Description
+
+* - ``V4L2_CTRL_PREFIX_NANO``
+ - -9
+ - Nano
+
+* - ``V4L2_CTRL_PREFIX_MICRO``
+ - -6
+ - Micro
+
+* - ``V4L2_CTRL_PREFIX_MILLI``
+ - -3
+ - Milli
+
+* - ``V4L2_CTRL_PREFIX_1``
+ - 0
+ - \-
+
+* - ``V4L2_CTRL_PREFIX_KILO``
+ - 3
+ - Kilo
+
+* - ``V4L2_CTRL_PREFIX_MEGA``
+ - 6
+ - Mega
+
+* - ``V4L2_CTRL_PREFIX_GIGA``
+ - 9
+ - Giga
+
+.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
+
+.. _control-units:
+
+.. cssclass:: longtable
+
+.. flat-table:: Control Units
+:header-rows: 1
+:stub-columns: 0
+:widths: 3 1 4
+
+* - Unit Name
+ - Value
+ - Description
+
+* - ``V4L2_CTRL_UNIT_UNDEFINED``
+ - 0
+ - The unit of the control is not defined.
+
+* - ``V4L2_CTRL_UNIT_NONE``
+ - 1
+ - The control has no unit.
+
+* - ``V4L2_CTRL_UNIT_SECOND``
+ - 2
+ - Second
+
+* - ``V4L2_CTRL_UNIT_AMPERE``
+ - 3
+ - Ampère
+
+* - ``V4L2_CTRL_UNIT_LINE``
+ - 4
+ - A line of pixels in sensor's pixel matrix. This is a unit of time
+commonly used by camera sensors in e.g. exposure control, i.e. the time
+it takes for a sensor to read a
Re: [PATCH v6] media: add imx319 camera sensor driver
Hi Bingbu,
On Tue, Sep 25, 2018 at 05:10:59PM +0800, Bing Bu Cao wrote:
...
> > +/* Initialize control handlers */
> > +static int imx319_init_controls(struct imx319 *imx319)
> > +{
> > + struct i2c_client *client = v4l2_get_subdevdata(>sd);
> > + struct v4l2_ctrl_handler *ctrl_hdlr;
> > + s64 exposure_max;
> > + s64 vblank_def;
> > + s64 vblank_min;
> > + s64 hblank;
> > + s64 pixel_rate;
> > + const struct imx319_mode *mode;
> > + int ret;
> > +
> > + ctrl_hdlr = >ctrl_handler;
> > + ret = v4l2_ctrl_handler_init(ctrl_hdlr, 10);
> > + if (ret)
> > + return ret;
> > +
> > + ctrl_hdlr->lock = >mutex;
> > + imx319->link_freq = v4l2_ctrl_new_int_menu(ctrl_hdlr,
> > _ctrl_ops,
> > + V4L2_CID_LINK_FREQ,
> > 0, 0,
> > +
> > imx319->hwcfg->link_freqs);
> Could you check that the link frequency matches with what the register
> lists assume?
> >>> Sakari, do you mean associate link frequency index with register list?
> > The driver should only allow using link frequencies that are explicitly
> > allowed for the system.
> Sakari, as current driver only support one link frequency, so I think once
> getting the link frequencies from firmware,
> driver can simply check and match the values with link_freq_menu_items[0] and
> only keep 1 item in the menu:
Please wrap the lines at around 76 characters, please.
>
> max = ARRAY_SIZE(link_freq_menu_items) - 1;
> imx319->link_freq = v4l2_ctrl_new_int_menu(ctrl_hdlr, _ctrl_ops,
> V4L2_CID_LINK_FREQ, max, 0,
> link_freq_menu_items);
> Is it OK?
"max" would be 0 in this case, I presume. Seems fine to me.
--
Regards,
Sakari Ailus
sakari.ai...@linux.intel.com
Re: [PATCH 1/1] v4l: Remove support for crop default target in subdev drivers
Hi Helmut, On Tue, Sep 25, 2018 at 08:33:29AM +0200, Helmut Grohne wrote: > On Mon, Sep 24, 2018 at 04:42:27PM +0200, Sakari Ailus wrote: > > --- a/drivers/media/i2c/mt9t112.c > > +++ b/drivers/media/i2c/mt9t112.c > > @@ -888,12 +888,6 @@ static int mt9t112_get_selection(struct v4l2_subdev > > *sd, > > sel->r.width = MAX_WIDTH; > > sel->r.height = MAX_HEIGHT; > > return 0; > > - case V4L2_SEL_TGT_CROP_DEFAULT: > > - sel->r.left = 0; > > - sel->r.top = 0; > > - sel->r.width = VGA_WIDTH; > > - sel->r.height = VGA_HEIGHT; > > - return 0; > > case V4L2_SEL_TGT_CROP: > > sel->r = priv->frame; > > return 0; > > Together with the change in soc_scale_crop.c, this constitutes an > (unintentional?) behaviour change. It was formerly reporting 640x480 and > will now be reporting 2048x1536. I cannot tell whether that is > reasonable. > > > --- a/drivers/media/i2c/soc_camera/mt9t112.c > > +++ b/drivers/media/i2c/soc_camera/mt9t112.c > > @@ -884,12 +884,6 @@ static int mt9t112_get_selection(struct v4l2_subdev > > *sd, > > sel->r.width = MAX_WIDTH; > > sel->r.height = MAX_HEIGHT; > > return 0; > > - case V4L2_SEL_TGT_CROP_DEFAULT: > > - sel->r.left = 0; > > - sel->r.top = 0; > > - sel->r.width = VGA_WIDTH; > > - sel->r.height = VGA_HEIGHT; > > - return 0; > > case V4L2_SEL_TGT_CROP: > > sel->r = priv->frame; > > return 0; > > This one looks duplicate. Is there a good reason to have two drivers for > mt9t112? This is lilely out of scope for the patch. Cced Jacopo Mondi as > he introduced the copy. > This version is the one using te soc_camera framework which is targeted for deprecation. The soc_camera based sensor drivers are being ported to be regular v4l2 sensor drivers, hence the copy in drivers/media/i2c/. The original versions in drivers/media/i2c/soc_camera will be around for a little longer and then possibly moved to staging or later removed. Hope this clarifies. Thanks j > Other than your patch looks fine to me. > > Helmut signature.asc Description: PGP signature
Re: [PATCH v5] media: imx208: Add imx208 camera sensor driver
Hi Ping-chung,
On Fri, Sep 21, 2018 at 07:08:10AM +, Chen, Ping-chung wrote:
> Typo.
>
> -Original Message-
> From: Chen, Ping-chung
> Sent: Friday, September 21, 2018 3:07 PM
> To: 'Ricardo Ribalda Delgado' ; Laurent Pinchart
>
> Cc: Sakari Ailus ; tf...@chromium.org; Sakari Ailus
> ; sylwester.nawro...@gmail.com; linux-media
> ; Yeh, Andy ; Lai, Jim
> ; grund...@chromium.org; Mani, Rajmohan
>
> Subject: RE: [PATCH v5] media: imx208: Add imx208 camera sensor driver
>
> Hi Sakari,
>
> >-Original Message-
> >From: Ricardo Ribalda Delgado [mailto:ricardo.riba...@gmail.com]
> >Sent: Friday, September 21, 2018 5:55 AM
>
> >HI
> On Thu, Sep 20, 2018 at 11:13 PM Laurent Pinchart
> wrote:
> >
> > Hi Sakari,
> >
> > On Thursday, 20 September 2018 23:56:59 EEST Sakari Ailus wrote:
> > > On Thu, Sep 20, 2018 at 05:51:55PM +0900, Tomasz Figa wrote:
> > > > On Wed, Aug 8, 2018 at 4:08 PM Ping-chung Chen wrote:
> > > > [snip]
> > > >
> > > > > +
> > > > > +/* Digital gain control */
> > > > > +#define IMX208_REG_GR_DIGITAL_GAIN 0x020e
> > > > > +#define IMX208_REG_R_DIGITAL_GAIN 0x0210
> > > > > +#define IMX208_REG_B_DIGITAL_GAIN 0x0212
> > > > > +#define IMX208_REG_GB_DIGITAL_GAIN 0x0214
> > > > > +#define IMX208_DGTL_GAIN_MIN 0
> > > > > +#define IMX208_DGTL_GAIN_MAX 4096
> > > > > +#define IMX208_DGTL_GAIN_DEFAULT 0x100
> > > > > +#define IMX208_DGTL_GAIN_STEP 1
> > > > > +
> > > >
> > > > [snip]
> > > >
> > > > > +/* Initialize control handlers */ static int
> > > > > +imx208_init_controls(struct imx208 *imx208) {
> > > >
> > > > [snip]
> > > >
> > > > > + v4l2_ctrl_new_std(ctrl_hdlr, _ctrl_ops,
> > > > > V4L2_CID_DIGITAL_GAIN, + IMX208_DGTL_GAIN_MIN,
> > > > > IMX208_DGTL_GAIN_MAX, + IMX208_DGTL_GAIN_STEP,
> > > > > + IMX208_DGTL_GAIN_DEFAULT);
> > > >
> > > > We have a problem here. The sensor supports only a discrete range
> > > > of values here - {1, 2, 4, 8, 16} (multiplied by 256, since the
> > > > value is fixed point). This makes it possible for the userspace to
> > > > set values that are not allowed by the sensor specification and
> > > > also leaves no way to enumerate the supported values.
> > > >
> > > > I can see two solutions here:
> > > >
> > > > 1) Define the control range from 0 to 4 and treat it as an
> > > > exponent of 2, so that the value for the sensor becomes (1 << val) *
> > > > 256.
> > > > (Suggested by Sakari offline.)
> > > >
> > > > This approach has the problem of losing the original unit (and
> > > > scale) of the value.
> > >
> > > I'd like to add that this is not a property of the proposed solution.
> > >
> > > Rather, the above needs to be accompanied by additional information
> > > provided through VIDIOC_QUERY_EXT_CTRL, i.e. the unit, prefix as
> > > well as other information such as whether the control is linear or
> > > exponential (as in this case).
> > >
> > > > 2) Use an integer menu control, which reports only the supported
> > > > discrete values - {1, 2, 4, 8, 16}.
> > > >
> > > > With this approach, userspace can enumerate the real gain values,
> > > > but we would either need to introduce a new control (e.g.
> > > > V4L2_CID_DIGITAL_GAIN_DISCRETE) or abuse the specification and
> > > > register V4L2_CID_DIGITAL_GAIN as an integer menu.
> > >
> > > New controls in V4L2 are, for the most part, created when there's
> > > something new to control. The documentation of some controls
> > > (similar to e.g. gain) documents a unit as well as a prefix but
> > > that's the case only because there's been no way to tell the unit or
> > > prefix otherwise in the API.
> > >
> > > An exception to this are EXPOSURE and EXPOSURE_ABSOLUTE. I'm not
> > > entirely sure how they came to be though. An accident is a
> > > possibility as far as I see.
> >
> > If I remember correctly I introduced the absolute variant for the UVC
> > driver (even though git blame points to Brandon Philips). I don't
> > really remember why though.
> >
> > > Controls that have a documented unit use that unit --- as long as
> > > that's the unit used by the hardware. If it's not, it tends to be
> > > that another unit is used but the user space has currently no way of
> > > knowing this. And the digital gain control is no exception to this.
> > >
> > > So if we want to improve the user space's ability to be informed how
> > > the control values reflect to device configuration, we do need to
> > > provide more information to the user space. One way to do that would
> > > be through VIDIOC_QUERY_EXT_CTRL. The IOCTL struct has plenty of
> > > reserved fields --- just for purposes such as this one.
> >
> > I don't think we can come up with a good way to expose arbitrary
> > mathematical formulas through an ioctl. In my opinion the question is
> > how far we want to go, how precise we need to be.
> >
> > > > Any opinions or
Re: [PATCH v6] media: add imx319 camera sensor driver
On 09/25/2018 03:33 PM, Sakari Ailus wrote: > Hi Bingbu, > > On Tue, Sep 25, 2018 at 02:59:05PM +0800, Bing Bu Cao wrote: >> >> On 09/25/2018 11:57 AM, Bing Bu Cao wrote: >>> On 09/21/2018 08:06 PM, Sakari Ailus wrote: Hi Bingbu, On Fri, Sep 21, 2018 at 05:41:55PM +0800, bingbu@intel.com wrote: > From: Bingbu Cao > > Add a v4l2 sub-device driver for the Sony imx319 image sensor. > This is a camera sensor using the i2c bus for control and the > csi-2 bus for data. > > This driver supports following features: > - manual exposure and analog/digital gain control support > - vblank/hblank control support > - 4 test patterns control support > - vflip/hflip control support (will impact the output bayer order) > - support following resolutions: > - 3264x2448, 3280x2464 @ 30fps > - 1936x1096, 1920x1080 @ 60fps > - 1640x1232, 1640x922, 1296x736, 1280x720 @ 120fps > - support 4 bayer orders output (via change v/hflip) > - SRGGB10(default), SGRBG10, SGBRG10, SBGGR10 > > Cc: Tomasz Figa > Cc: Sakari Ailus > Signed-off-by: Bingbu Cao > Signed-off-by: Tianshu Qiu > > --- > > This patch is based on sakari's media-tree git: > https://git.linuxtv.org/sailus/media_tree.git/log/?h=for-4.20-1 > > Changes from v5: > - add some comments for gain calculation > - use lock to protect the format > > Changes from v4 to v5: > - use single PLL for all internal clocks > - change link frequency to 482.4MHz > - adjust frame timing for 2x2 binning modes >and enlarge frame readout time > - get CSI-2 link frequencies and external clock >from firmware > - use unlocked __v4l2_ctrl_grab() with change from: > > https://git.linuxtv.org/sailus/media_tree.git/commit/?h=unlocked-ctrl-grab > > Changes since v1: > - fix some coding style issues - line breaks > - add v4l2_ctrl_grab() to prevent v/hflip change >during streaming > - add v4l2 ctrl event (un)subscribe support > - add more info into commit message > > --- > --- > MAINTAINERS|7 + > drivers/media/i2c/Kconfig | 11 + > drivers/media/i2c/Makefile |1 + > drivers/media/i2c/imx319.c | 2545 > > 4 files changed, 2564 insertions(+) > create mode 100644 drivers/media/i2c/imx319.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index a5b256b25905..abc4abb6f83c 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -13530,6 +13530,13 @@ S: Maintained > F: drivers/media/i2c/imx274.c > F: Documentation/devicetree/bindings/media/i2c/imx274.txt > > +SONY IMX319 SENSOR DRIVER > +M: Bingbu Cao > +L: linux-media@vger.kernel.org > +T: git git://linuxtv.org/media_tree.git > +S: Maintained > +F: drivers/media/i2c/imx319.c > + > SONY MEMORYSTICK CARD SUPPORT > M: Alex Dubov > W: http://tifmxx.berlios.de/ > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig > index bfdb494686bf..603ac087975b 100644 > --- a/drivers/media/i2c/Kconfig > +++ b/drivers/media/i2c/Kconfig > @@ -614,6 +614,17 @@ config VIDEO_IMX274 > This is a V4L2 sensor driver for the Sony IMX274 > CMOS image sensor. > > +config VIDEO_IMX319 > + tristate "Sony IMX319 sensor support" > + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API > + depends on MEDIA_CAMERA_SUPPORT > + help > + This is a Video4Linux2 sensor driver for the Sony > + IMX319 camera. > + > + To compile this driver as a module, choose M here: the > + module will be called imx319. > + > config VIDEO_OV2640 > tristate "OmniVision OV2640 sensor support" > depends on VIDEO_V4L2 && I2C > diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile > index a94eb03d10d4..d10b438577be 100644 > --- a/drivers/media/i2c/Makefile > +++ b/drivers/media/i2c/Makefile > @@ -108,5 +108,6 @@ obj-$(CONFIG_VIDEO_OV2659)+= ov2659.o > obj-$(CONFIG_VIDEO_TC358743) += tc358743.o > obj-$(CONFIG_VIDEO_IMX258) += imx258.o > obj-$(CONFIG_VIDEO_IMX274) += imx274.o > +obj-$(CONFIG_VIDEO_IMX319) += imx319.o > > obj-$(CONFIG_SDR_MAX2175) += max2175.o > diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c > new file mode 100644 > index ..5e80b113c386 > --- /dev/null > +++ b/drivers/media/i2c/imx319.c > @@ -0,0 +1,2545 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// Copyright (C) 2018 Intel Corporation > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include >
Re: cron job: media_tree daily build: ERRORS
The git-spec ERRORS were due to a missing package on the build server, nothing to do with errors in our code/documentation. Should be fixed now. Regards, Hans On 09/25/2018 05:50 AM, Hans Verkuil wrote: > This message is generated daily by a cron job that builds media_tree for > the kernels and architectures in the list below. > > Results of the daily build of media_tree: > > date: Tue Sep 25 05:00:38 CEST 2018 > media-tree git hash: 4158757395b300b6eb308fc20b96d1d231484413 > media_build git hash: 44385b9c61ecc27059a651885895c8ea09cd4179 > v4l-utils git hash: 4890391b5d9e25ddd933e29c8f812a138e77919b > edid-decode git hash: 5eeb151a748788666534d6ea3da07f90400d24c2 > gcc version: i686-linux-gcc (GCC) 8.1.0 > sparse version: 0.5.2 > smatch version: 0.5.1 > host hardware:x86_64 > host os: 4.18.0-1-amd64 > > 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-arm64: OK > linux-git-i686: OK > linux-git-mips: OK > linux-git-powerpc64: OK > linux-git-sh: WARNINGS > linux-git-x86_64: OK > Check COMPILE_TEST: OK > linux-3.10.108-i686: OK > linux-3.10.108-x86_64: OK > linux-3.11.10-i686: OK > linux-3.11.10-x86_64: OK > linux-3.12.74-i686: OK > linux-3.12.74-x86_64: OK > linux-3.13.11-i686: OK > linux-3.13.11-x86_64: OK > linux-3.14.79-i686: OK > linux-3.14.79-x86_64: OK > linux-3.15.10-i686: OK > linux-3.15.10-x86_64: OK > linux-3.16.57-i686: OK > linux-3.16.57-x86_64: OK > linux-3.17.8-i686: OK > linux-3.17.8-x86_64: OK > linux-3.18.119-i686: OK > linux-3.18.119-x86_64: OK > linux-3.19.8-i686: OK > linux-3.19.8-x86_64: OK > linux-4.0.9-i686: OK > linux-4.0.9-x86_64: OK > linux-4.1.52-i686: OK > linux-4.1.52-x86_64: OK > linux-4.2.8-i686: OK > linux-4.2.8-x86_64: OK > linux-4.3.6-i686: OK > linux-4.3.6-x86_64: OK > linux-4.4.152-i686: OK > linux-4.4.152-x86_64: OK > linux-4.5.7-i686: OK > linux-4.5.7-x86_64: OK > linux-4.6.7-i686: OK > linux-4.6.7-x86_64: OK > linux-4.7.10-i686: OK > linux-4.7.10-x86_64: OK > linux-4.8.17-i686: OK > linux-4.8.17-x86_64: OK > linux-4.9.124-i686: OK > linux-4.9.124-x86_64: OK > linux-4.10.17-i686: OK > linux-4.10.17-x86_64: OK > linux-4.11.12-i686: OK > linux-4.11.12-x86_64: OK > linux-4.12.14-i686: OK > linux-4.12.14-x86_64: OK > linux-4.13.16-i686: OK > linux-4.13.16-x86_64: OK > linux-4.14.67-i686: OK > linux-4.14.67-x86_64: OK > linux-4.15.18-i686: OK > linux-4.15.18-x86_64: OK > linux-4.16.18-i686: OK > linux-4.16.18-x86_64: OK > linux-4.17.19-i686: OK > linux-4.17.19-x86_64: OK > linux-4.18.5-i686: OK > linux-4.18.5-x86_64: OK > linux-4.19-rc1-i686: OK > linux-4.19-rc1-x86_64: OK > apps: OK > spec-git: ERRORS > sparse: WARNINGS > > Detailed results are available here: > > http://www.xs4all.nl/~hverkuil/logs/Tuesday.log > > Full logs are available here: > > http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 > > The Media Infrastructure API from this daily build is here: > > http://www.xs4all.nl/~hverkuil/spec/index.html >
Re: [PATCH v6] media: add imx319 camera sensor driver
Hi Bingbu, On Tue, Sep 25, 2018 at 02:59:05PM +0800, Bing Bu Cao wrote: > > > On 09/25/2018 11:57 AM, Bing Bu Cao wrote: > > > > On 09/21/2018 08:06 PM, Sakari Ailus wrote: > >> Hi Bingbu, > >> > >> On Fri, Sep 21, 2018 at 05:41:55PM +0800, bingbu@intel.com wrote: > >>> From: Bingbu Cao > >>> > >>> Add a v4l2 sub-device driver for the Sony imx319 image sensor. > >>> This is a camera sensor using the i2c bus for control and the > >>> csi-2 bus for data. > >>> > >>> This driver supports following features: > >>> - manual exposure and analog/digital gain control support > >>> - vblank/hblank control support > >>> - 4 test patterns control support > >>> - vflip/hflip control support (will impact the output bayer order) > >>> - support following resolutions: > >>> - 3264x2448, 3280x2464 @ 30fps > >>> - 1936x1096, 1920x1080 @ 60fps > >>> - 1640x1232, 1640x922, 1296x736, 1280x720 @ 120fps > >>> - support 4 bayer orders output (via change v/hflip) > >>> - SRGGB10(default), SGRBG10, SGBRG10, SBGGR10 > >>> > >>> Cc: Tomasz Figa > >>> Cc: Sakari Ailus > >>> Signed-off-by: Bingbu Cao > >>> Signed-off-by: Tianshu Qiu > >>> > >>> --- > >>> > >>> This patch is based on sakari's media-tree git: > >>> https://git.linuxtv.org/sailus/media_tree.git/log/?h=for-4.20-1 > >>> > >>> Changes from v5: > >>> - add some comments for gain calculation > >>> - use lock to protect the format > >>> > >>> Changes from v4 to v5: > >>> - use single PLL for all internal clocks > >>> - change link frequency to 482.4MHz > >>> - adjust frame timing for 2x2 binning modes > >>>and enlarge frame readout time > >>> - get CSI-2 link frequencies and external clock > >>>from firmware > >>> - use unlocked __v4l2_ctrl_grab() with change from: > >>> > >>> https://git.linuxtv.org/sailus/media_tree.git/commit/?h=unlocked-ctrl-grab > >>> > >>> Changes since v1: > >>> - fix some coding style issues - line breaks > >>> - add v4l2_ctrl_grab() to prevent v/hflip change > >>>during streaming > >>> - add v4l2 ctrl event (un)subscribe support > >>> - add more info into commit message > >>> > >>> --- > >>> --- > >>> MAINTAINERS|7 + > >>> drivers/media/i2c/Kconfig | 11 + > >>> drivers/media/i2c/Makefile |1 + > >>> drivers/media/i2c/imx319.c | 2545 > >>> > >>> 4 files changed, 2564 insertions(+) > >>> create mode 100644 drivers/media/i2c/imx319.c > >>> > >>> diff --git a/MAINTAINERS b/MAINTAINERS > >>> index a5b256b25905..abc4abb6f83c 100644 > >>> --- a/MAINTAINERS > >>> +++ b/MAINTAINERS > >>> @@ -13530,6 +13530,13 @@ S: Maintained > >>> F: drivers/media/i2c/imx274.c > >>> F: Documentation/devicetree/bindings/media/i2c/imx274.txt > >>> > >>> +SONY IMX319 SENSOR DRIVER > >>> +M: Bingbu Cao > >>> +L: linux-media@vger.kernel.org > >>> +T: git git://linuxtv.org/media_tree.git > >>> +S: Maintained > >>> +F: drivers/media/i2c/imx319.c > >>> + > >>> SONY MEMORYSTICK CARD SUPPORT > >>> M: Alex Dubov > >>> W: http://tifmxx.berlios.de/ > >>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig > >>> index bfdb494686bf..603ac087975b 100644 > >>> --- a/drivers/media/i2c/Kconfig > >>> +++ b/drivers/media/i2c/Kconfig > >>> @@ -614,6 +614,17 @@ config VIDEO_IMX274 > >>> This is a V4L2 sensor driver for the Sony IMX274 > >>> CMOS image sensor. > >>> > >>> +config VIDEO_IMX319 > >>> + tristate "Sony IMX319 sensor support" > >>> + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API > >>> + depends on MEDIA_CAMERA_SUPPORT > >>> + help > >>> + This is a Video4Linux2 sensor driver for the Sony > >>> + IMX319 camera. > >>> + > >>> + To compile this driver as a module, choose M here: the > >>> + module will be called imx319. > >>> + > >>> config VIDEO_OV2640 > >>> tristate "OmniVision OV2640 sensor support" > >>> depends on VIDEO_V4L2 && I2C > >>> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile > >>> index a94eb03d10d4..d10b438577be 100644 > >>> --- a/drivers/media/i2c/Makefile > >>> +++ b/drivers/media/i2c/Makefile > >>> @@ -108,5 +108,6 @@ obj-$(CONFIG_VIDEO_OV2659)+= ov2659.o > >>> obj-$(CONFIG_VIDEO_TC358743) += tc358743.o > >>> obj-$(CONFIG_VIDEO_IMX258) += imx258.o > >>> obj-$(CONFIG_VIDEO_IMX274) += imx274.o > >>> +obj-$(CONFIG_VIDEO_IMX319) += imx319.o > >>> > >>> obj-$(CONFIG_SDR_MAX2175) += max2175.o > >>> diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c > >>> new file mode 100644 > >>> index ..5e80b113c386 > >>> --- /dev/null > >>> +++ b/drivers/media/i2c/imx319.c > >>> @@ -0,0 +1,2545 @@ > >>> +// SPDX-License-Identifier: GPL-2.0 > >>> +// Copyright (C) 2018 Intel Corporation > >>> + > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> + > >>>
Re: [PATCH v6] media: add imx319 camera sensor driver
On 09/25/2018 11:57 AM, Bing Bu Cao wrote: > > On 09/21/2018 08:06 PM, Sakari Ailus wrote: >> Hi Bingbu, >> >> On Fri, Sep 21, 2018 at 05:41:55PM +0800, bingbu@intel.com wrote: >>> From: Bingbu Cao >>> >>> Add a v4l2 sub-device driver for the Sony imx319 image sensor. >>> This is a camera sensor using the i2c bus for control and the >>> csi-2 bus for data. >>> >>> This driver supports following features: >>> - manual exposure and analog/digital gain control support >>> - vblank/hblank control support >>> - 4 test patterns control support >>> - vflip/hflip control support (will impact the output bayer order) >>> - support following resolutions: >>> - 3264x2448, 3280x2464 @ 30fps >>> - 1936x1096, 1920x1080 @ 60fps >>> - 1640x1232, 1640x922, 1296x736, 1280x720 @ 120fps >>> - support 4 bayer orders output (via change v/hflip) >>> - SRGGB10(default), SGRBG10, SGBRG10, SBGGR10 >>> >>> Cc: Tomasz Figa >>> Cc: Sakari Ailus >>> Signed-off-by: Bingbu Cao >>> Signed-off-by: Tianshu Qiu >>> >>> --- >>> >>> This patch is based on sakari's media-tree git: >>> https://git.linuxtv.org/sailus/media_tree.git/log/?h=for-4.20-1 >>> >>> Changes from v5: >>> - add some comments for gain calculation >>> - use lock to protect the format >>> >>> Changes from v4 to v5: >>> - use single PLL for all internal clocks >>> - change link frequency to 482.4MHz >>> - adjust frame timing for 2x2 binning modes >>>and enlarge frame readout time >>> - get CSI-2 link frequencies and external clock >>>from firmware >>> - use unlocked __v4l2_ctrl_grab() with change from: >>> >>> https://git.linuxtv.org/sailus/media_tree.git/commit/?h=unlocked-ctrl-grab >>> >>> Changes since v1: >>> - fix some coding style issues - line breaks >>> - add v4l2_ctrl_grab() to prevent v/hflip change >>>during streaming >>> - add v4l2 ctrl event (un)subscribe support >>> - add more info into commit message >>> >>> --- >>> --- >>> MAINTAINERS|7 + >>> drivers/media/i2c/Kconfig | 11 + >>> drivers/media/i2c/Makefile |1 + >>> drivers/media/i2c/imx319.c | 2545 >>> >>> 4 files changed, 2564 insertions(+) >>> create mode 100644 drivers/media/i2c/imx319.c >>> >>> diff --git a/MAINTAINERS b/MAINTAINERS >>> index a5b256b25905..abc4abb6f83c 100644 >>> --- a/MAINTAINERS >>> +++ b/MAINTAINERS >>> @@ -13530,6 +13530,13 @@ S: Maintained >>> F: drivers/media/i2c/imx274.c >>> F: Documentation/devicetree/bindings/media/i2c/imx274.txt >>> >>> +SONY IMX319 SENSOR DRIVER >>> +M: Bingbu Cao >>> +L: linux-media@vger.kernel.org >>> +T: git git://linuxtv.org/media_tree.git >>> +S: Maintained >>> +F: drivers/media/i2c/imx319.c >>> + >>> SONY MEMORYSTICK CARD SUPPORT >>> M: Alex Dubov >>> W: http://tifmxx.berlios.de/ >>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig >>> index bfdb494686bf..603ac087975b 100644 >>> --- a/drivers/media/i2c/Kconfig >>> +++ b/drivers/media/i2c/Kconfig >>> @@ -614,6 +614,17 @@ config VIDEO_IMX274 >>> This is a V4L2 sensor driver for the Sony IMX274 >>> CMOS image sensor. >>> >>> +config VIDEO_IMX319 >>> + tristate "Sony IMX319 sensor support" >>> + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API >>> + depends on MEDIA_CAMERA_SUPPORT >>> + help >>> + This is a Video4Linux2 sensor driver for the Sony >>> + IMX319 camera. >>> + >>> + To compile this driver as a module, choose M here: the >>> + module will be called imx319. >>> + >>> config VIDEO_OV2640 >>> tristate "OmniVision OV2640 sensor support" >>> depends on VIDEO_V4L2 && I2C >>> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile >>> index a94eb03d10d4..d10b438577be 100644 >>> --- a/drivers/media/i2c/Makefile >>> +++ b/drivers/media/i2c/Makefile >>> @@ -108,5 +108,6 @@ obj-$(CONFIG_VIDEO_OV2659) += ov2659.o >>> obj-$(CONFIG_VIDEO_TC358743) += tc358743.o >>> obj-$(CONFIG_VIDEO_IMX258) += imx258.o >>> obj-$(CONFIG_VIDEO_IMX274) += imx274.o >>> +obj-$(CONFIG_VIDEO_IMX319) += imx319.o >>> >>> obj-$(CONFIG_SDR_MAX2175) += max2175.o >>> diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c >>> new file mode 100644 >>> index ..5e80b113c386 >>> --- /dev/null >>> +++ b/drivers/media/i2c/imx319.c >>> @@ -0,0 +1,2545 @@ >>> +// SPDX-License-Identifier: GPL-2.0 >>> +// Copyright (C) 2018 Intel Corporation >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +#define IMX319_REG_MODE_SELECT 0x0100 >>> +#define IMX319_MODE_STANDBY0x00 >>> +#define IMX319_MODE_STREAMING 0x01 >>> + >>> +/* Chip ID */ >>> +#define IMX319_REG_CHIP_ID 0x0016 >>> +#define IMX319_CHIP_ID 0x0319 >>> + >>> +/* V_TIMING internal */ >>> +#define IMX319_REG_FLL 0x0340 >>> +#define IMX319_FLL_MAX
Re: [PATCH 1/1] v4l: Remove support for crop default target in subdev drivers
On Mon, Sep 24, 2018 at 04:42:27PM +0200, Sakari Ailus wrote: > --- a/drivers/media/i2c/mt9t112.c > +++ b/drivers/media/i2c/mt9t112.c > @@ -888,12 +888,6 @@ static int mt9t112_get_selection(struct v4l2_subdev *sd, > sel->r.width = MAX_WIDTH; > sel->r.height = MAX_HEIGHT; > return 0; > - case V4L2_SEL_TGT_CROP_DEFAULT: > - sel->r.left = 0; > - sel->r.top = 0; > - sel->r.width = VGA_WIDTH; > - sel->r.height = VGA_HEIGHT; > - return 0; > case V4L2_SEL_TGT_CROP: > sel->r = priv->frame; > return 0; Together with the change in soc_scale_crop.c, this constitutes an (unintentional?) behaviour change. It was formerly reporting 640x480 and will now be reporting 2048x1536. I cannot tell whether that is reasonable. > --- a/drivers/media/i2c/soc_camera/mt9t112.c > +++ b/drivers/media/i2c/soc_camera/mt9t112.c > @@ -884,12 +884,6 @@ static int mt9t112_get_selection(struct v4l2_subdev *sd, > sel->r.width = MAX_WIDTH; > sel->r.height = MAX_HEIGHT; > return 0; > - case V4L2_SEL_TGT_CROP_DEFAULT: > - sel->r.left = 0; > - sel->r.top = 0; > - sel->r.width = VGA_WIDTH; > - sel->r.height = VGA_HEIGHT; > - return 0; > case V4L2_SEL_TGT_CROP: > sel->r = priv->frame; > return 0; This one looks duplicate. Is there a good reason to have two drivers for mt9t112? This is lilely out of scope for the patch. Cced Jacopo Mondi as he introduced the copy. Other than your patch looks fine to me. Helmut
