Rapid Prototyping Services/Anby from China
Dear Purchasing Manager, How are you? This is Nancy from Anby. We are a professional rapid prototyping,plastic and metal components processing manufacturer at Shenzhen in China for years. We can do 3D printing, CNC milling and turning, sheet metal fabricating, Injection mold, blow mold. If you have projects to make, pls kindly send us 3D drawing in STP file, quantity, material and finish, we will quote you immediately. Our service is good quality, fast delivery. Thanks and best regards Nancy Chiang Shenzhen Anby Technology Co., Ltd Address: Number 8, Qiaotou, Fuyong Town, Baoan District, Shenzhen City, Guangdong Province, China Mobile: 0086-13420952289 Skype: nancychiang7 QQ: 276337634 mail: info(at)anbytech(dot)com
cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Tue Oct 2 05:00:10 CEST 2018 media-tree git hash:4158757395b300b6eb308fc20b96d1d231484413 media_build git hash: 44385b9c61ecc27059a651885895c8ea09cd4179 v4l-utils git hash: 7bde5ef172bd4a09b9544788ba9c5dbb1aa9994a 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.11-marune 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.123-i686: OK linux-3.18.123-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.158-i686: OK linux-4.4.158-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.129-i686: OK linux-4.9.129-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.72-i686: OK linux-4.14.72-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.10-i686: OK linux-4.18.10-x86_64: OK linux-4.19-rc5-i686: OK linux-4.19-rc5-x86_64: OK apps: OK spec-git: OK 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
rtl2832_sdr: Use-after-free when unplugging busy device
Hello, While testing rtl-sdr (v3) dongle, I've hit an memory corruption while unplugging the device. With KASAN enabled, I get use-after-free report from it (see below). This is on Linux v4.18.11. Best Regards, Michał Mirosław [16141.107421] usb 3-2.1: new high-speed USB device number 10 using xhci_hcd [16141.213180] usb 3-2.1: New USB device found, idVendor=0bda, idProduct=2838, bcdDevice= 1.00 [16141.213194] usb 3-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [16141.213197] usb 3-2.1: Product: RTL2838UHIDIR [16141.213200] usb 3-2.1: Manufacturer: Realtek [16141.213202] usb 3-2.1: SerialNumber: 0001 [16141.224531] usb 3-2.1: dvb_usb_v2: found a 'Realtek RTL2832U reference design' in warm state [16141.286662] usb 3-2.1: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer [16141.286762] dvbdev: DVB: registering new adapter (Realtek RTL2832U reference design) [16141.290794] i2c i2c-1: Added multiplexed i2c bus 2 [16141.290799] rtl2832 1-0010: Realtek RTL2832 successfully attached [16141.290885] usb 3-2.1: DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))... [16141.291209] r820t 2-001a: creating new instance [16141.298378] r820t 2-001a: Rafael Micro r820t successfully identified [16141.301125] rtl2832_sdr rtl2832_sdr.2.auto: Registered as swradio0 [16141.301129] rtl2832_sdr rtl2832_sdr.2.auto: Realtek RTL2832 SDR attached [16141.301133] rtl2832_sdr rtl2832_sdr.2.auto: SDR API is still slightly experimental and functionality changes may follow [16141.312612] Registered IR keymap rc-empty [16141.312838] rc rc0: Realtek RTL2832U reference design as /devices/pci:00/:00:1c.1/:07:00.0/usb3/3-2/3-2.1/rc/rc0 [16141.313149] input: Realtek RTL2832U reference design as /devices/pci:00/:00:1c.1/:07:00.0/usb3/3-2/3-2.1/rc/rc0/input16 [16141.313679] rc rc0: lirc_dev: driver dvb_usb_rtl28xxu registered at minor = 0, raw IR receiver, no transmitter [16141.313749] usb 3-2.1: dvb_usb_v2: schedule remote query interval to 200 msecs [16141.322310] usb 3-2.1: dvb_usb_v2: 'Realtek RTL2832U reference design' successfully initialized and connected [16171.703626] rtl2832_sdr_urb_complete: 138 callbacks suppressed [16171.703636] rtl2832_sdr rtl2832_sdr.2.auto: videobuf is full, 1 packets dropped [...] [17946.704899] rtl2832_sdr rtl2832_sdr.2.auto: videobuf is full, 6071 packets dropped [18831.758684] usb 3-2.1: dvb_usb_v2: rc.query() failed=-71 [18831.758883] rtl2832_sdr rtl2832_sdr.2.auto: urb failed=-71 [18831.759678] rtl2832_sdr rtl2832_sdr.2.auto: urb failed=-71 [18831.760263] rtl2832_sdr rtl2832_sdr.2.auto: urb failed=-71 [18831.760865] rtl2832_sdr rtl2832_sdr.2.auto: urb failed=-71 [18831.761443] rtl2832_sdr rtl2832_sdr.2.auto: urb failed=-71 [18831.762080] rtl2832_sdr rtl2832_sdr.2.auto: urb failed=-71 [18831.762713] rtl2832_sdr rtl2832_sdr.2.auto: urb failed=-71 [18831.763316] rtl2832_sdr rtl2832_sdr.2.auto: urb failed=-71 [18831.763923] rtl2832_sdr rtl2832_sdr.2.auto: urb failed=-71 [18831.764567] rtl2832_sdr rtl2832_sdr.2.auto: urb failed=-71 [18831.778416] usb 3-2.1: USB disconnect, device number 10 [18831.825671] r820t 2-001a: destroying instance [18831.827016] dvb_usb_v2: 'Realtek RTL2832U reference design:3-2.1' successfully deinitialized and disconnected [18840.759215] == [18840.759223] BUG: KASAN: use-after-free in rtl2832_sdr_stop_streaming+0x3e/0x4c0 [rtl2832_sdr] [18840.759226] Read of size 8 at addr 8803775fc420 by task kdec/9354 [18840.759232] CPU: 4 PID: 9354 Comm: kdec Tainted: P O 4.18.11mq+ #265 [18840.759234] Hardware name: System manufacturer System Product Name/P8Z68-V PRO, BIOS 3603 11/09/2012 [18840.759236] Call Trace: [18840.759241] dump_stack+0x5b/0x8c [18840.759246] print_address_description+0x67/0x237 [18840.759249] kasan_report.cold.6+0x243/0x2ff [18840.759253] ? rtl2832_sdr_stop_streaming+0x3e/0x4c0 [rtl2832_sdr] [18840.759257] rtl2832_sdr_stop_streaming+0x3e/0x4c0 [rtl2832_sdr] [18840.759262] __vb2_queue_cancel+0x54/0x390 [videobuf2_common] [18840.759267] ? fsnotify+0x8f3/0x920 [18840.759271] vb2_core_streamoff+0x22/0x80 [videobuf2_common] [18840.759275] __vb2_cleanup_fileio+0x34/0x90 [videobuf2_common] [18840.759280] vb2_core_queue_release+0xa/0x50 [videobuf2_common] [18840.759284] _vb2_fop_release+0xe3/0x110 [videobuf2_v4l2] [18840.759292] v4l2_release+0x65/0xa0 [videodev] [18840.759295] __fput+0x12b/0x310 [18840.759300] task_work_run+0xb5/0xe0 [18840.759303] do_exit+0x47a/0x11f0 [18840.759306] ? mm_update_next_owner+0x350/0x350 [18840.759309] ? memset+0x1f/0x40 [18840.759312] ? __dequeue_signal+0x1f8/0x210 [18840.759315] ? recalc_sigpending_tsk+0x6b/0x90 [18840.759317] ? recalc_sigpending+0x12/0x60 [18840.759320] ? dequeue_signal+0x8b/0x290 [18840.759323] ? vb2_fop_read+0xc7/0x1a0 [videobuf2_v4l2] [18840.759326] ? kernel_sigaction+0x160/0x160 [18840.759329]
[RESEND] [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Dhaval Shah SPDX-License-Identifier is used for the Xilinx Video IP and related drivers. Signed-off-by: Dhaval Shah Reviewed-by: Laurent Pinchart [Added drivers/media/platform/xilinx/Kconfig] [Added drivers/media/platform/xilinx/Makefile] [Added include/dt-bindings/media/xilinx-vip.h] Signed-off-by: Laurent Pinchart --- drivers/media/platform/xilinx/Kconfig | 2 ++ drivers/media/platform/xilinx/Makefile | 2 ++ drivers/media/platform/xilinx/xilinx-dma.c | 5 + drivers/media/platform/xilinx/xilinx-dma.h | 5 + drivers/media/platform/xilinx/xilinx-tpg.c | 5 + drivers/media/platform/xilinx/xilinx-vip.c | 5 + drivers/media/platform/xilinx/xilinx-vip.h | 5 + drivers/media/platform/xilinx/xilinx-vipp.c | 5 + drivers/media/platform/xilinx/xilinx-vipp.h | 5 + drivers/media/platform/xilinx/xilinx-vtc.c | 5 + drivers/media/platform/xilinx/xilinx-vtc.h | 5 + include/dt-bindings/media/xilinx-vip.h | 5 + 12 files changed, 14 insertions(+), 40 deletions(-) diff --git a/drivers/media/platform/xilinx/Kconfig b/drivers/media/platform/xilinx/Kconfig index a5d21b7c6e0b..74ec8aaa5ae0 100644 --- a/drivers/media/platform/xilinx/Kconfig +++ b/drivers/media/platform/xilinx/Kconfig @@ -1,3 +1,5 @@ +# SPDX-License-Identifier: GPL-2.0 + config VIDEO_XILINX tristate "Xilinx Video IP (EXPERIMENTAL)" depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA diff --git a/drivers/media/platform/xilinx/Makefile b/drivers/media/platform/xilinx/Makefile index e8a0f2a9f733..4cdc0b1ec7a5 100644 --- a/drivers/media/platform/xilinx/Makefile +++ b/drivers/media/platform/xilinx/Makefile @@ -1,3 +1,5 @@ +# SPDX-License-Identifier: GPL-2.0 + xilinx-video-objs += xilinx-dma.o xilinx-vip.o xilinx-vipp.o obj-$(CONFIG_VIDEO_XILINX) += xilinx-video.o diff --git a/drivers/media/platform/xilinx/xilinx-dma.c b/drivers/media/platform/xilinx/xilinx-dma.c index 4ae9d38c9433..c9d5fdb2d407 100644 --- a/drivers/media/platform/xilinx/xilinx-dma.c +++ b/drivers/media/platform/xilinx/xilinx-dma.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Xilinx Video DMA * @@ -6,10 +7,6 @@ * * Contacts: Hyun Kwon * Laurent Pinchart - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. */ #include diff --git a/drivers/media/platform/xilinx/xilinx-dma.h b/drivers/media/platform/xilinx/xilinx-dma.h index e95d136c153a..5aec4d17eb21 100644 --- a/drivers/media/platform/xilinx/xilinx-dma.h +++ b/drivers/media/platform/xilinx/xilinx-dma.h @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Xilinx Video DMA * @@ -6,10 +7,6 @@ * * Contacts: Hyun Kwon * Laurent Pinchart - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. */ #ifndef __XILINX_VIP_DMA_H__ diff --git a/drivers/media/platform/xilinx/xilinx-tpg.c b/drivers/media/platform/xilinx/xilinx-tpg.c index 851d20dcd550..1399e71d42c2 100644 --- a/drivers/media/platform/xilinx/xilinx-tpg.c +++ b/drivers/media/platform/xilinx/xilinx-tpg.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Xilinx Test Pattern Generator * @@ -6,10 +7,6 @@ * * Contacts: Hyun Kwon * Laurent Pinchart - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. */ #include diff --git a/drivers/media/platform/xilinx/xilinx-vip.c b/drivers/media/platform/xilinx/xilinx-vip.c index 311259129504..5f7efa9f093e 100644 --- a/drivers/media/platform/xilinx/xilinx-vip.c +++ b/drivers/media/platform/xilinx/xilinx-vip.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Xilinx Video IP Core * @@ -6,10 +7,6 @@ * * Contacts: Hyun Kwon * Laurent Pinchart - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. */ #include diff --git a/drivers/media/platform/xilinx/xilinx-vip.h b/drivers/media/platform/xilinx/xilinx-vip.h index 42fee2026815..ba939dd52818 100644 --- a/drivers/media/platform/xilinx/xilinx-vip.h +++ b/drivers/media/platform/xilinx/xilinx-vip.h @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Xilinx Video IP Core * @@ -6,10 +7,6 @@ * * Contacts: Hyun Kwon * Laurent Pinchart - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. */ #ifndef __XILINX_VIP_H__ diff --git
Re: [PATCH v6 0/6] Add Rockchip VPU JPEG encoder
On Fri, 2018-09-28 at 14:33 +0200, Hans Verkuil wrote:
> On 09/17/2018 07:30 PM, Ezequiel Garcia wrote:
> > This series adds support for JPEG encoding via the VPU block
> > present in Rockchip platforms. Currently, support for RK3288
> > and RK3399 is included.
> >
> > Please, see the previous versions of this cover letter for
> > more information.
> >
> > Compared to v5, the only change is in the V4L2_CID_JPEG_QUANTIZATION
> > control. We've decided to support only baseline profile,
> > and only add 8-bit luma and chroma tables.
> >
> > struct v4l2_ctrl_jpeg_quantization {
> >__u8luma_quantization_matrix[64];
> >__u8chroma_quantization_matrix[64];
> > };
> >
> > By doing this, it's clear that we don't currently support anything
> > but baseline.
> >
> > This series should apply cleanly on top of
> >
> > git://linuxtv.org/hverkuil/media_tree.git br-cedrus tag.
> >
> > If everyone is happy with this series, I'd like to route the devicetree
> > changes through the rockchip tree, and the rest via the media subsystem.
>
> OK, so I have what is no doubt an annoying question: do we really need
> a JPEG_RAW format?
>
Not annoying, as it helps clarify a few things :-)
I think we do need the JPEG_RAW format. The way I see it, using
JPEG opens a can of worms...
> The JPEG header is really easy to parse for a decoder and really easy to
> prepend to the compressed image for the encoder.
>
> The only reason I can see for a JPEG_RAW is if the image must start at
> some specific address alignment. Although even then you can just pad the
> JPEG header that you will add according to the alignment requirements.
>
> I know I am very late with this question, but I never looked all that
> closely at what a JPEG header looks like. But this helped:
>
> https://en.wikipedia.org/wiki/JPEG_File_Interchange_Format
>
> and it doesn't seem difficult at all to parse or create the header.
>
>
... I think that having JPEG_RAW as the compressed format
is much more clear for userspace, as it explicitly specifies
what is expected.
This way, for a stateless encoder, applications are required
to set quantization and/or entropy tables, and are then in
charge of using the compressed JPEG_RAW payload in whatever form
they want. Stupid simple.
On the other side, if the stateless encoder driver supports
JPEG (creating headers in-kernel), it means that:
*) applications should pass a quality control, if supported,
and the driver will use hardcoded tables or...
*) applications pass quantization control and, if supported,
entropy control. The kernel uses them to create the JPEG frame.
But also, some drivers (e.g. Rockchip), use default entropy
tables, which should now be in the kernel.
So the application would have to query controls to find out
what to do. Not exactly hard, but I think having the JPEG_RAW
is much simpler and more clear.
Now, for stateless decoders, supporting JPEG_RAW means
the application has to pass quantization and entropy
controls, probably using the Request API.
Given the application has parsed the JPEG,
it knows the width and height and can request
buffers accordingly.
The hardware is stateless, and so is the driver.
On the other hand, supporting JPEG would mean that
drivers will have to parse the image, extracting
the quantization and entropy tables.
Format negotiation is now more complex,
either we follow the stateful spec, introducing a little
state machine in the driver... or we use the Request API,
but that means parsing on both sides kernel and application.
Either way, using JPEG_RAW is just waaay simpler and puts
things where they belong.
> I also think there are more drivers (solo6x10) that
> manipulate the JPEG header.
Well, I've always thought this was kind of suboptimal.
Thanks,
Ezequiel
Re: [RFC] V4L2_PIX_FMT_MJPEG vs V4L2_PIX_FMT_JPEG
Hi All, On Mon, 1 Oct 2018 at 17:32, Ezequiel Garcia wrote: > > Hi Hans, > > Thanks for looking into. I remember MJPEG vs. JPEG being a source > of confusion for me a few years ago, so clarification is greatly > welcome :-) > > On Mon, 2018-10-01 at 15:03 +0300, Laurent Pinchart wrote: > > Hi Hans, > > > > On Monday, 1 October 2018 14:54:29 EEST Hans Verkuil wrote: > > > On 10/01/2018 01:48 PM, Laurent Pinchart wrote: > > > > On Monday, 1 October 2018 11:43:04 EEST Hans Verkuil wrote: > > > > > It turns out that we have both JPEG and Motion-JPEG pixel formats > > > > > defined. > > > > > > > > > > Furthermore, some drivers support one, some the other and some both. > > > > > > > > > > These pixelformats both mean the same. > > > > > > > > Do they ? I thought MJPEG was JPEG using fixed Huffman tables that were > > > > not included in the JPEG headers. > > > > > > I'm not aware of any difference. If there is one, then it is certainly not > > > documented. > > > > What I can tell for sure is that many UVC devices don't include Huffman > > tables > > in their JPEG headers. > > > > > Ezequiel, since you've been working with this recently, do you know > > > anything > > > about this? > > > > > > JPEG frames must include huffman and quantization tables, as per the standard. > > AFAIK, there's no MJPEG specification per-se and vendors specify its own > way of conveying a Motion JPEG stream. There is the specfication for MJPEG in Quicktime containers, which defines the MJPEG-A and MJPEG-B variants [1]. MJPEG-B is not a concatenation of JPEG frames as the framing is different, so can't really be combined into V4L2_PIX_FMT_JPEG. Have people encountered devices that produce MJPEG-A or MJPEG-B via V4L2? I haven't, but I have been forced to support both variants on decode. On that thought, whilst capture devices generally don't care, is there a need to differentiate for M2M codec devices which can support encoding the variants? Or likewise on M2M decoders that support only JPEG, how do they tell userspace that they don't support MJPEG-A or MJPEG-B? Dave [1] https://developer.apple.com/standards/qtff-2001.pdf > For instance, omiting the huffman table seems to be a vendor thing. Microsoft > explicitly omits the huffman tables from each frame: > > https://www.fileformat.info/format/bmp/spec/b7c72ebab8064da48ae5ed0c053c67a4/view.htm > > Others could be following the same things. > > Like I mentioned before, Gstreamer always check for missing huffman table > and adds one if missing. Gstreamer has other quirks for missing markers, > e.g. deal with a missing EOI: > > https://github.com/GStreamer/gst-plugins-good/commit/10ff3c8e14e8fba9e0a5d696dce0bea27de644d7 > > I think Hans suggestion of settling on JPEG makes sense and it would > be consistent with Gstreamer. Otherwise, we should specify exactly what we > understand by MJPEG, but I don't think it's worth it. > > Thanks, > Ezequiel
Re: [RFC] V4L2_PIX_FMT_MJPEG vs V4L2_PIX_FMT_JPEG
Hi Hans, On Monday, 1 October 2018 19:28:58 EEST Hans Verkuil wrote: > On 10/01/2018 06:12 PM, Ezequiel Garcia wrote: > > On Mon, 2018-10-01 at 08:42 -0400, Nicolas Dufresne wrote: > >> Le lundi 01 octobre 2018 à 10:43 +0200, Hans Verkuil a écrit : > >>> It turns out that we have both JPEG and Motion-JPEG pixel formats > >>> defined. > >>> > >>> Furthermore, some drivers support one, some the other and some both. > >>> > >>> These pixelformats both mean the same. > >>> > >>> I propose that we settle on JPEG (since it seems to be used most often) > >>> and add JPEG support to those drivers that currently only use MJPEG. > >> > >> Thanks for looking into this. As per GStreamer code, I see 3 alias for > >> JPEG. V4L2_PIX_FMT_MJPEG/JPEG/PJPG. I don't know the context, this code > >> was written before I knew GStreamer existed. It's possible there is a > >> subtle difference, I have never looked at it, but clearly all our JPEG > >> decoder handle these as being the same. > >> > >> https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/sys/v4l2/gst > >> v4l2object.c#n956 > > > > To add more data points on the gstreamer side, there's really no > > difference between gstreamer's types image/jpeg and video/x-jpeg. > > > > Notably, jpegdec element just stuffs a huffman table if one is missing, > > for any jpeg: > > > > https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/ext/jpeg/gstj > > pegdec.c#n584 > > lib/libv4lconvert/libv4lconvert.c also treats JPEG and MJPEG the same. > > It looks like JPEG and MJPEG are randomly used and I don't think you can > assume that one will have a huffman table and not the other. That at least should be fixed. If we decide that whether the frames will contain a Huffman table or not is useful information for userspace, then we should convey it, either through the current mechanism (JPEG vs. MJPEG) or through a different mechanism. Otherwise, we can merge JPEG and MJPEG (as long as it doesn't break userspace). -- Regards, Laurent Pinchart
Re: [PATCH] MAINTAINERS: Remove stale file entry for the Atmel ISI driver
Em Sun, 30 Sep 2018 02:40:35 -0700
Joe Perches escreveu:
> On Sun, 2018-09-30 at 06:30 -0300, Mauro Carvalho Chehab wrote:
> > Em Sun, 30 Sep 2018 09:54:48 +0300
> > Laurent Pinchart escreveu:
> >
> > > include/media/atmel-isi got removed three years ago without the
> > > MAINTAINERS file being updated. Remove the stale entry.
> > >
> > > Fixes: 40a78f36fc92 ("[media] v4l: atmel-isi: Remove support for platform
> > > data")
> > > Reported-by: Joe Perches
> > > Signed-off-by: Laurent Pinchart
> > > ---
> > > MAINTAINERS | 1 -
> > > 1 file changed, 1 deletion(-)
> > >
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> []
> > > @@ -2497,7 +2497,6 @@ M: Ludovic Desroches
> > >
> > > L: linux-media@vger.kernel.org
> > > S: Supported
> > > F: drivers/media/platform/atmel/atmel-isi.c
> > > -F: include/media/atmel-isi.h
> >
> > I guess the right fix would be to replace it by:
> >
> > F: drivers/media/platform/atmel/atmel-isi.h
>
> Or replace both F entries with:
>
> F:drivers/media/platform/atmel/atmel-isi.*
>
> Or combine the 2 MICROCHIP sections into one
>
> MICROCHIP ISC DRIVER
> M:Eugen Hristev
> L:linux-media@vger.kernel.org
> S:Supported
> F:drivers/media/platform/atmel/atmel-isc.c
> F:drivers/media/platform/atmel/atmel-isc-regs.h
> F:devicetree/bindings/media/atmel-isc.txt
>
> MICROCHIP ISI DRIVER
> M:Eugen Hristev
> L:linux-media@vger.kernel.org
> S:Supported
> F:drivers/media/platform/atmel/atmel-isi.c
> F:include/media/atmel-isi.h
>
> and maybe use something like:
>
> MICROCHIP MEDIA DRIVERS
> M:Eugen Hristev
> L:
> linux-media@vger.kernel.org
> S:Supported
> F:drivers/media/platform/atmel/
> F:devicetree/bindings/media/atmel-isc.txt
Yeah, combining both of them seems a good alternative to me.
Eugen/Ludovic/Josh,
Comments?
Regards,
Mauro
>
>
Thanks,
Mauro
Re: [RFC] V4L2_PIX_FMT_MJPEG vs V4L2_PIX_FMT_JPEG
Hi Hans, Thanks for looking into. I remember MJPEG vs. JPEG being a source of confusion for me a few years ago, so clarification is greatly welcome :-) On Mon, 2018-10-01 at 15:03 +0300, Laurent Pinchart wrote: > Hi Hans, > > On Monday, 1 October 2018 14:54:29 EEST Hans Verkuil wrote: > > On 10/01/2018 01:48 PM, Laurent Pinchart wrote: > > > On Monday, 1 October 2018 11:43:04 EEST Hans Verkuil wrote: > > > > It turns out that we have both JPEG and Motion-JPEG pixel formats > > > > defined. > > > > > > > > Furthermore, some drivers support one, some the other and some both. > > > > > > > > These pixelformats both mean the same. > > > > > > Do they ? I thought MJPEG was JPEG using fixed Huffman tables that were > > > not included in the JPEG headers. > > > > I'm not aware of any difference. If there is one, then it is certainly not > > documented. > > What I can tell for sure is that many UVC devices don't include Huffman > tables > in their JPEG headers. > > > Ezequiel, since you've been working with this recently, do you know anything > > about this? > > JPEG frames must include huffman and quantization tables, as per the standard. AFAIK, there's no MJPEG specification per-se and vendors specify its own way of conveying a Motion JPEG stream. For instance, omiting the huffman table seems to be a vendor thing. Microsoft explicitly omits the huffman tables from each frame: https://www.fileformat.info/format/bmp/spec/b7c72ebab8064da48ae5ed0c053c67a4/view.htm Others could be following the same things. Like I mentioned before, Gstreamer always check for missing huffman table and adds one if missing. Gstreamer has other quirks for missing markers, e.g. deal with a missing EOI: https://github.com/GStreamer/gst-plugins-good/commit/10ff3c8e14e8fba9e0a5d696dce0bea27de644d7 I think Hans suggestion of settling on JPEG makes sense and it would be consistent with Gstreamer. Otherwise, we should specify exactly what we understand by MJPEG, but I don't think it's worth it. Thanks, Ezequiel
Re: [RFC] V4L2_PIX_FMT_MJPEG vs V4L2_PIX_FMT_JPEG
On 10/01/2018 06:12 PM, Ezequiel Garcia wrote: > On Mon, 2018-10-01 at 08:42 -0400, Nicolas Dufresne wrote: >> Hello Hans, >> >> Le lundi 01 octobre 2018 à 10:43 +0200, Hans Verkuil a écrit : >>> It turns out that we have both JPEG and Motion-JPEG pixel formats defined. >>> >>> Furthermore, some drivers support one, some the other and some both. >>> >>> These pixelformats both mean the same. >>> >>> I propose that we settle on JPEG (since it seems to be used most often) and >>> add JPEG support to those drivers that currently only use MJPEG. >> >> Thanks for looking into this. As per GStreamer code, I see 3 alias for >> JPEG. V4L2_PIX_FMT_MJPEG/JPEG/PJPG. I don't know the context, this code >> was written before I knew GStreamer existed. It's possible there is a >> subtle difference, I have never looked at it, but clearly all our JPEG >> decoder handle these as being the same. >> >> https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/sys/v4l2/gstv4l2object.c#n956 >> > > To add more data points on the gstreamer side, there's really no difference > between gstreamer's types image/jpeg and video/x-jpeg. > > Notably, jpegdec element just stuffs a huffman table if one is missing, > for any jpeg: > > https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/ext/jpeg/gstjpegdec.c#n584 lib/libv4lconvert/libv4lconvert.c also treats JPEG and MJPEG the same. It looks like JPEG and MJPEG are randomly used and I don't think you can assume that one will have a huffman table and not the other. Regards, Hans > >>> >>> We also need to update the V4L2_PIX_FMT_JPEG documentation since it just >>> says >>> TBD: >>> >>> https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/pixfmt-compressed.html >>> >>> $ git grep -l V4L2_PIX_FMT_MJPEG >>> drivers/media/pci/meye/meye.c >>> drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c >>> drivers/media/platform/sti/delta/delta-cfg.h >>> drivers/media/platform/sti/delta/delta-mjpeg-dec.c >>> drivers/media/usb/cpia2/cpia2_v4l.c >>> drivers/media/usb/go7007/go7007-driver.c >>> drivers/media/usb/go7007/go7007-fw.c >>> drivers/media/usb/go7007/go7007-v4l2.c >>> drivers/media/usb/s2255/s2255drv.c >>> drivers/media/usb/uvc/uvc_driver.c >>> drivers/staging/media/zoran/zoran_driver.c >>> drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c >>> drivers/usb/gadget/function/uvc_v4l2.c >>> >>> It looks like s2255 and cpia2 support both already, so that would leave >>> 8 drivers that need to be modified, uvc being the most important of the >>> lot. >>> >>> Any comments? >>> >>> Regards, >>> >>> Hans >> >> >
Re: [RFC] V4L2_PIX_FMT_MJPEG vs V4L2_PIX_FMT_JPEG
On Mon, 2018-10-01 at 08:42 -0400, Nicolas Dufresne wrote: > Hello Hans, > > Le lundi 01 octobre 2018 à 10:43 +0200, Hans Verkuil a écrit : > > It turns out that we have both JPEG and Motion-JPEG pixel formats defined. > > > > Furthermore, some drivers support one, some the other and some both. > > > > These pixelformats both mean the same. > > > > I propose that we settle on JPEG (since it seems to be used most often) and > > add JPEG support to those drivers that currently only use MJPEG. > > Thanks for looking into this. As per GStreamer code, I see 3 alias for > JPEG. V4L2_PIX_FMT_MJPEG/JPEG/PJPG. I don't know the context, this code > was written before I knew GStreamer existed. It's possible there is a > subtle difference, I have never looked at it, but clearly all our JPEG > decoder handle these as being the same. > > https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/sys/v4l2/gstv4l2object.c#n956 > To add more data points on the gstreamer side, there's really no difference between gstreamer's types image/jpeg and video/x-jpeg. Notably, jpegdec element just stuffs a huffman table if one is missing, for any jpeg: https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/ext/jpeg/gstjpegdec.c#n584 > > > > We also need to update the V4L2_PIX_FMT_JPEG documentation since it just > > says > > TBD: > > > > https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/pixfmt-compressed.html > > > > $ git grep -l V4L2_PIX_FMT_MJPEG > > drivers/media/pci/meye/meye.c > > drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c > > drivers/media/platform/sti/delta/delta-cfg.h > > drivers/media/platform/sti/delta/delta-mjpeg-dec.c > > drivers/media/usb/cpia2/cpia2_v4l.c > > drivers/media/usb/go7007/go7007-driver.c > > drivers/media/usb/go7007/go7007-fw.c > > drivers/media/usb/go7007/go7007-v4l2.c > > drivers/media/usb/s2255/s2255drv.c > > drivers/media/usb/uvc/uvc_driver.c > > drivers/staging/media/zoran/zoran_driver.c > > drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c > > drivers/usb/gadget/function/uvc_v4l2.c > > > > It looks like s2255 and cpia2 support both already, so that would leave > > 8 drivers that need to be modified, uvc being the most important of the > > lot. > > > > Any comments? > > > > Regards, > > > > Hans > >
Re: [linux-firmware] [GIT PULL] amlogic: add video decoder firmwares
On Mon, Oct 1, 2018 at 5:36 PM Josh Boyer wrote: > > On Mon, Oct 1, 2018 at 11:27 AM Maxime Jourdan wrote: > > > > Hello, > > > > Below is a pull request to add the firmwares required by the Amlogic video > > decoder. > > > > The firmwares were dumped from GPLv2+ in-kernel source files from Amlogic's > > vendor kernel, in their buildroot package > > "buildroot_openlinux_kernel_4.9_wayland_20180316" > > > > You can find an example of such a file in an older kernel here: > > https://github.com/hardkernel/linux/blob/odroidc2-3.14.y/drivers/amlogic/amports/arch/ucode/mpeg12/vmpeg12_mc.c > > > > The corresponding driver is currently being upstreamed: > > https://lore.kernel.org/patchwork/cover/993093/ > > > > Regards, > > Maxime > > > > The following changes since commit 7c81f23ad903f72e87e2102d8f52408305c0f7a2: > > > > ti-connectivity: add firmware for CC2560(A) Bluetooth (2018-10-01 > > 10:08:30 -0400) > > > > are available in the Git repository at: > > > > https://github.com/Elyotna/linux-firmware.git > > This seems questionable to me. You have the license listed as GPLv2 > or later, which is what the header file originally had but you have no > corresponding source included in your commit and it's completely > unclear who would be fulfilling the GPL obligations around this. Even > less clear is how one would take whatever source is provided and turn > them back into the binaries you've provided. Have you contacted AM > Logic to see if they can post the firmware files themselves or confirm > the license should be GPLv2? > > josh > Hi Josh, I see your point. The "source" files that are GPLv2+ in the vendor kernel only contain binary arrays, and there is no actual source code available for these firmwares. I had hoped this would at least mean we could redistribute the binary firmwares. I will contact Amlogic and (hopefully) follow up with clarified licensing regarding the firmwares. Regards, Maxime
Re: [PATCH v2 0/6] media: video-i2c: support changing frame interval and runtime PM
2018年10月1日(月) 18:41 Hans Verkuil : > > On 09/23/2018 06:34 PM, Akinobu Mita wrote: > > This patchset adds support for changing frame interval and runtime PM for > > video-i2c driver. This also adds an helper macro to v4l2 common > > internal API that is used to to find a suitable frame interval. > > > > There are a couple of unrelated changes that are included for simplifying > > driver initialization code and register accesses. > > > > * v2 > > - Add Acked-by and Reviewed-by tags > > - Update commit log to clarify the use after free > > - Add thermistor and termperature register address definisions > > - Stop adding v4l2_find_closest_fract() in v4l2 common internal API > > - Add V4L2_FRACT_COMPARE() macro in v4l2 common internal API > > - Use V4L2_FRACT_COMPARE() to find suitable frame interval instead of > > v4l2_find_closest_fract() > > 1) What's wrong with v4l2_find_closest_fract()? My implementation of v4l2_find_closest_fract() in v1 didn't care about u32 overflow. Even if the overflow problem is fixed, there are only a few drivers (video-i2c and vivid) that can make use of it. So I feel it adds more lines of code than it can remove. > 2) Please test this with the latest v4l2-compliance: I recently improved >the S_PARM checks, so I want to make sure this driver passes those tests. v4l2-compliance SHA: 7bde5ef172bd4a09b9544788ba9c5dbb1aa9994a, 32 bits Compliance test for device /dev/video2: Driver Info: Driver name : video-i2c Card type: I2C 1-104 Transport Video Bus info : I2C:1-104 Driver version : 4.19.0 Capabilities : 0x8521 Video Capture Read/Write Streaming Extended Pix Format Device Capabilities Device Caps : 0x0521 Video Capture Read/Write Streaming Extended Pix Format Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second /dev/video2 open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK test for unlimited opens: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK test VIDIOC_LOG_STATUS: OK (Not Supported) Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 1 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported) Control ioctls (Input 0): test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported) test VIDIOC_QUERYCTRL: OK (Not Supported) test VIDIOC_G/S_CTRL: OK (Not Supported) test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported) test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 0 Private Controls: 0 Format ioctls (Input 0): test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK test VIDIOC_G/S_PARM: OK test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK test VIDIOC_TRY_FMT: OK test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK (Not Supported) test Composing: OK (Not Supported) test Scaling: OK (Not Supported) Codec ioctls (Input 0): test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls (Input 0): test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK (Not Supported) Total: 43, Succeeded: 43, Failed: 0, Warnings: 0
Re: [linux-firmware] [GIT PULL] amlogic: add video decoder firmwares
On Mon, Oct 1, 2018 at 11:27 AM Maxime Jourdan wrote: > > Hello, > > Below is a pull request to add the firmwares required by the Amlogic video > decoder. > > The firmwares were dumped from GPLv2+ in-kernel source files from Amlogic's > vendor kernel, in their buildroot package > "buildroot_openlinux_kernel_4.9_wayland_20180316" > > You can find an example of such a file in an older kernel here: > https://github.com/hardkernel/linux/blob/odroidc2-3.14.y/drivers/amlogic/amports/arch/ucode/mpeg12/vmpeg12_mc.c > > The corresponding driver is currently being upstreamed: > https://lore.kernel.org/patchwork/cover/993093/ > > Regards, > Maxime > > The following changes since commit 7c81f23ad903f72e87e2102d8f52408305c0f7a2: > > ti-connectivity: add firmware for CC2560(A) Bluetooth (2018-10-01 10:08:30 > -0400) > > are available in the Git repository at: > > https://github.com/Elyotna/linux-firmware.git This seems questionable to me. You have the license listed as GPLv2 or later, which is what the header file originally had but you have no corresponding source included in your commit and it's completely unclear who would be fulfilling the GPL obligations around this. Even less clear is how one would take whatever source is provided and turn them back into the binaries you've provided. Have you contacted AM Logic to see if they can post the firmware files themselves or confirm the license should be GPLv2? josh > for you to fetch changes up to b99cf8dcfb6e7a3dd00bdb6aa4f6c71cb6b42e58: > > amlogic: add video decoder firmwares (2018-10-01 17:06:18 +0200) > > > Maxime Jourdan (1): > amlogic: add video decoder firmwares > > WHENCE | 16 > amlogic/gx/h263_mc | Bin 0 -> 16384 bytes > amlogic/gx/vh265_mc | Bin 0 -> 16384 bytes > amlogic/gx/vh265_mc_mmu | Bin 0 -> 16384 bytes > amlogic/gx/vmjpeg_mc| Bin 0 -> 16384 bytes > amlogic/gx/vmpeg12_mc | Bin 0 -> 16384 bytes > amlogic/gx/vmpeg4_mc_5 | Bin 0 -> 16384 bytes > amlogic/gxbb/vh264_mc | Bin 0 -> 36864 bytes > amlogic/gxl/vh264_mc| Bin 0 -> 36864 bytes > amlogic/gxm/vh264_mc| Bin 0 -> 36864 bytes > 10 files changed, 16 insertions(+) > create mode 100644 amlogic/gx/h263_mc > create mode 100644 amlogic/gx/vh265_mc > create mode 100644 amlogic/gx/vh265_mc_mmu > create mode 100644 amlogic/gx/vmjpeg_mc > create mode 100644 amlogic/gx/vmpeg12_mc > create mode 100644 amlogic/gx/vmpeg4_mc_5 > create mode 100644 amlogic/gxbb/vh264_mc > create mode 100644 amlogic/gxl/vh264_mc > create mode 100644 amlogic/gxm/vh264_mc
[linux-firmware] [GIT PULL] amlogic: add video decoder firmwares
Hello, Below is a pull request to add the firmwares required by the Amlogic video decoder. The firmwares were dumped from GPLv2+ in-kernel source files from Amlogic's vendor kernel, in their buildroot package "buildroot_openlinux_kernel_4.9_wayland_20180316" You can find an example of such a file in an older kernel here: https://github.com/hardkernel/linux/blob/odroidc2-3.14.y/drivers/amlogic/amports/arch/ucode/mpeg12/vmpeg12_mc.c The corresponding driver is currently being upstreamed: https://lore.kernel.org/patchwork/cover/993093/ Regards, Maxime The following changes since commit 7c81f23ad903f72e87e2102d8f52408305c0f7a2: ti-connectivity: add firmware for CC2560(A) Bluetooth (2018-10-01 10:08:30 -0400) are available in the Git repository at: https://github.com/Elyotna/linux-firmware.git for you to fetch changes up to b99cf8dcfb6e7a3dd00bdb6aa4f6c71cb6b42e58: amlogic: add video decoder firmwares (2018-10-01 17:06:18 +0200) Maxime Jourdan (1): amlogic: add video decoder firmwares WHENCE | 16 amlogic/gx/h263_mc | Bin 0 -> 16384 bytes amlogic/gx/vh265_mc | Bin 0 -> 16384 bytes amlogic/gx/vh265_mc_mmu | Bin 0 -> 16384 bytes amlogic/gx/vmjpeg_mc| Bin 0 -> 16384 bytes amlogic/gx/vmpeg12_mc | Bin 0 -> 16384 bytes amlogic/gx/vmpeg4_mc_5 | Bin 0 -> 16384 bytes amlogic/gxbb/vh264_mc | Bin 0 -> 36864 bytes amlogic/gxl/vh264_mc| Bin 0 -> 36864 bytes amlogic/gxm/vh264_mc| Bin 0 -> 36864 bytes 10 files changed, 16 insertions(+) create mode 100644 amlogic/gx/h263_mc create mode 100644 amlogic/gx/vh265_mc create mode 100644 amlogic/gx/vh265_mc_mmu create mode 100644 amlogic/gx/vmjpeg_mc create mode 100644 amlogic/gx/vmpeg12_mc create mode 100644 amlogic/gx/vmpeg4_mc_5 create mode 100644 amlogic/gxbb/vh264_mc create mode 100644 amlogic/gxl/vh264_mc create mode 100644 amlogic/gxm/vh264_mc
Re: [PATCH v3] media: docs: add glossary.rst with common terms used at V4L2 spec
On 09/25/2018 09:14 PM, Mauro Carvalho Chehab wrote: > 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. s/a // > + > + For V4L2 hardware, this is also known as V4L2 main driver. s/as/as the/ > + > +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. To be added to this glossary in the future: - Frontend - Demux - Conditional Access > + > + 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 Intelectual -> Intellectual > + 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
Re: [PATCH 3/4] media: dt-bindings: media: Document pclk-max-frequency property
Hi Sakari, On 09/28/2018 09:03 AM, Sakari Ailus wrote: > Hi Hugues, > > On Thu, Sep 27, 2018 at 04:46:06PM +0200, Hugues Fruchet wrote: >> This optional property aims to inform parallel video devices >> of the maximum pixel clock frequency admissible by host video >> interface. If bandwidth of data to be transferred requires a >> pixel clock which is higher than this value, parallel video >> device could then typically adapt framerate to reach >> this constraint. >> >> Signed-off-by: Hugues Fruchet >> --- >> Documentation/devicetree/bindings/media/video-interfaces.txt | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt >> b/Documentation/devicetree/bindings/media/video-interfaces.txt >> index baf9d97..fa4c112 100644 >> --- a/Documentation/devicetree/bindings/media/video-interfaces.txt >> +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt >> @@ -147,6 +147,8 @@ Optional endpoint properties >> as 0 (normal). This property is valid for serial busses only. >> - strobe: Whether the clock signal is used as clock (0) or strobe (1). Used >> with CCP2, for instance. >> +- pclk-max-frequency: maximum pixel clock frequency admissible by video >> + host interface. > > Is there a limit on the pixel clock or the link frequency? The constraint is the frequency of the clock in input of the SoC (pixel clock line). > > We do have a property for the link frequency and a control for the pixel > lock as well as for the link frequency. Could these be used for the > purpose? As this was documented mainly for MIPI-CSI2 I was not clear if this could be used or not, but video-interface.txt binding let open the door to parallel port usage... I had also some hesitations to use this property because what I was searching for here was a maximum limit to not exceed while "link-frequencies" is described as frequencies to use: "Allowed data bus frequencies". The fact that there was several entries for this property was also quite confusing. What I can do is to use this property and add a comment explaining that this can also be used for parallel port as the frequency to not exceed on pixel clock signal, what do you think about it ? Checking drivers which are implementing "link-frequencies", I've found OV2659 sensor which is doing almost what I want to, ie compute the clock rate depending on link-frequency, see ov2659_pll_calc_params(). > > The link frequency in general should be specified for the board, and that > limits the pixel clock as well in the case the bus transfers a given number > of pixels per clock. > > The OMAP3ISP driver also address this by reading back the pixel clock from > the sensor before starting streaming. > BR, Hugues.
Re: [PATCH v3 00/12] media: ov5640: Misc cleanup and improvements
Hi Maxime, On 09/28/2018 06:05 PM, Maxime Ripard wrote: > Hi Hugues, > > On Thu, Sep 27, 2018 at 03:59:04PM +, Hugues FRUCHET wrote: >> Hi Maxime & all OV5640 stakeholders, >> >> I've just pushed a new patchset also related to rate/pixel clock >> handling [1], based on your V3 great work: >> >media: ov5640: Adjust the clock based on the expected rate >> >media: ov5640: Remove the clocks registers initialization >> >media: ov5640: Remove redundant defines >> >media: ov5640: Remove redundant register setup >> >media: ov5640: Compute the clock rate at runtime >> >media: ov5640: Remove pixel clock rates >> >media: ov5640: Enhance FPS handling >> >> This is working perfectly fine on my parallel setup and allows me to >> well support VGA@30fps (instead 27) and also support XGA(1024x768)@15fps >> that I never seen working before. >> So at least for the parallel setup, this serie is working fine for all >> the discrete resolutions and framerate exposed by the driver for the moment: >> * QCIF 176x144 15/30fps >> * QVGA 320x240 15/30fps >> * VGA 640x480 15/30fps >> * 480p 720x480 15/30fps >> * XGA 1024x768 15/30fps >> * 720p 1280x720 15/30fps >> * 1080p 1920x1080 15/30fps >> * 5Mp 2592x1944 15fps > > I'm glad this is working for you as well. I guess I'll resubmit these > patches, but this time making sure someone with a CSI setup tests > before merging. I crtainly don't want to repeat the previous disaster. > > Do you have those patches rebased somewhere? I'm not quite sure how to > fix the conflict with the v4l2_find_nearest_size addition. > >> Moreover I'm not clear on relationship between rate and pixel clock >> frequency. >> I've understood that to DVP_PCLK_DIVIDER (0x3824) register >> and VFIFO_CTRL0C (0x460c) affects the effective pixel clock frequency. >> All the resolutions up to 720x576 are forcing a manual value of 2 for >> divider (0x460c=0x22), but including 720p and more, the divider value is >> controlled by "auto-mode" (0x460c=0x20)... from what I measured and >> understood, for those resolutions, the divider must be set to 1 in order >> that your rate computation match the effective pixel clock on output, >> see [2]. >> >> So I wonder if this PCLK divider register should be included >> or not into your rate computation, what do you think ? > > Have you tried change the PCLK divider while in auto-mode? IIRC, I did > that and it was affecting the PCLK rate on my scope, but I wouldn't be > definitive about it. I have tested to change PCLK divider while in auto mode but no effect. > > Can we always set the mode to auto and divider to 1, even for the > lower resolutions? This is breaking 176x144@30fps on my side, because of pixel clock too high (112MHz vs 70 MHz max). Instead of using auto mode, my proposal was the inverse: use manual mode with the proper divider to fit the max pixel clock constraint. BR, Hugues.
Re: [PATCH] [media] v4l: xilinx: fix typo in formats table
On 1.10.2018 15:36, Laurent Pinchart wrote: > Hi Michal, > > On Monday, 1 October 2018 16:28:32 EEST Michal Simek wrote: >> On 1.10.2018 15:26, Laurent Pinchart wrote: >>> On Monday, 1 October 2018 15:45:49 EEST Michal Simek wrote: On 28.9.2018 14:52, Laurent Pinchart wrote: > On Friday, 28 September 2018 10:32:13 EEST Andrea Merello wrote: >> In formats table the entry for CFA pattern "rggb" has GRBG fourcc. >> This patch fixes it. >> >> Cc: linux-media@vger.kernel.org >> Signed-off-by: Mirco Di Salvo >> Signed-off-by: Andrea Merello > > Reviewed-by: Laurent Pinchart > > Michal, should I take the patch in my tree ? definitely. I am not collecting patches for media tree. >>> >>> Taken in my tree. >>> >>> By the way, have we reached any conclusion regarding >>> https://lkml.org/lkml/ >>> 2017/12/18/112 ? >> >> Xilinx has started to use SPDX without any issue. It means conversion >> should be fine to do. > > That's good to know, I'll resubmit the patch then, and CC you to get an ack. > Sure go ahead. M
Re: [PATCH] [media] v4l: xilinx: fix typo in formats table
Hi Michal, On Monday, 1 October 2018 16:28:32 EEST Michal Simek wrote: > On 1.10.2018 15:26, Laurent Pinchart wrote: > > On Monday, 1 October 2018 15:45:49 EEST Michal Simek wrote: > >> On 28.9.2018 14:52, Laurent Pinchart wrote: > >>> On Friday, 28 September 2018 10:32:13 EEST Andrea Merello wrote: > In formats table the entry for CFA pattern "rggb" has GRBG fourcc. > This patch fixes it. > > Cc: linux-media@vger.kernel.org > Signed-off-by: Mirco Di Salvo > Signed-off-by: Andrea Merello > >>> > >>> Reviewed-by: Laurent Pinchart > >>> > >>> Michal, should I take the patch in my tree ? > >> > >> definitely. I am not collecting patches for media tree. > > > > Taken in my tree. > > > > By the way, have we reached any conclusion regarding > > https://lkml.org/lkml/ > > 2017/12/18/112 ? > > Xilinx has started to use SPDX without any issue. It means conversion > should be fine to do. That's good to know, I'll resubmit the patch then, and CC you to get an ack. -- Regards, Laurent Pinchart
Re: [RFC] V4L2_PIX_FMT_MJPEG vs V4L2_PIX_FMT_JPEG
Hello, On Monday, 1 October 2018 15:42:56 EEST Nicolas Dufresne wrote: > Le lundi 01 octobre 2018 à 10:43 +0200, Hans Verkuil a écrit : > > It turns out that we have both JPEG and Motion-JPEG pixel formats defined. > > > > Furthermore, some drivers support one, some the other and some both. > > > > These pixelformats both mean the same. > > > > I propose that we settle on JPEG (since it seems to be used most often) > > and add JPEG support to those drivers that currently only use MJPEG. > > Thanks for looking into this. As per GStreamer code, I see 3 alias for > JPEG. V4L2_PIX_FMT_MJPEG/JPEG/PJPG. I don't know the context, this code > was written before I knew GStreamer existed. It's possible there is a > subtle difference, I have never looked at it, but clearly all our JPEG > decoder handle these as being the same. > > https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/sys/v4l2/gstv4l > 2object.c#n956 Some old code to give a bit of context: https://github.com/TimSC/mjpeg/ It should be feasible to implement a decoder that inserts the right Huffman table when none exists, but it has to be explicitly handled. An out-of-band mechanism to convey the information seems potentially useful to me. > > We also need to update the V4L2_PIX_FMT_JPEG documentation since it just > > says TBD: > > > > https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/pixfmt-compres > > sed.html > > > > $ git grep -l V4L2_PIX_FMT_MJPEG > > drivers/media/pci/meye/meye.c > > drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c > > drivers/media/platform/sti/delta/delta-cfg.h > > drivers/media/platform/sti/delta/delta-mjpeg-dec.c > > drivers/media/usb/cpia2/cpia2_v4l.c > > drivers/media/usb/go7007/go7007-driver.c > > drivers/media/usb/go7007/go7007-fw.c > > drivers/media/usb/go7007/go7007-v4l2.c > > drivers/media/usb/s2255/s2255drv.c > > drivers/media/usb/uvc/uvc_driver.c > > drivers/staging/media/zoran/zoran_driver.c > > drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c > > drivers/usb/gadget/function/uvc_v4l2.c > > > > It looks like s2255 and cpia2 support both already, so that would leave > > 8 drivers that need to be modified, uvc being the most important of the > > lot. > > > > Any comments? -- Regards, Laurent Pinchart
Re: [PATCH] [media] v4l: xilinx: fix typo in formats table
Hi Laurent, On 1.10.2018 15:26, Laurent Pinchart wrote: > Hi Michal, > > On Monday, 1 October 2018 15:45:49 EEST Michal Simek wrote: >> On 28.9.2018 14:52, Laurent Pinchart wrote: >>> On Friday, 28 September 2018 10:32:13 EEST Andrea Merello wrote: In formats table the entry for CFA pattern "rggb" has GRBG fourcc. This patch fixes it. Cc: linux-media@vger.kernel.org Signed-off-by: Mirco Di Salvo Signed-off-by: Andrea Merello >>> >>> Reviewed-by: Laurent Pinchart >>> >>> Michal, should I take the patch in my tree ? >> >> definitely. I am not collecting patches for media tree. > > Taken in my tree. > > By the way, have we reached any conclusion regarding https://lkml.org/lkml/ > 2017/12/18/112 ? Xilinx has started to use SPDX without any issue. It means conversion should be fine to do. Thanks, Michal
Re: [PATCH] [media] v4l: xilinx: fix typo in formats table
Hi Michal, On Monday, 1 October 2018 15:45:49 EEST Michal Simek wrote: > On 28.9.2018 14:52, Laurent Pinchart wrote: > > On Friday, 28 September 2018 10:32:13 EEST Andrea Merello wrote: > >> In formats table the entry for CFA pattern "rggb" has GRBG fourcc. > >> This patch fixes it. > >> > >> Cc: linux-media@vger.kernel.org > >> Signed-off-by: Mirco Di Salvo > >> Signed-off-by: Andrea Merello > > > > Reviewed-by: Laurent Pinchart > > > > Michal, should I take the patch in my tree ? > > definitely. I am not collecting patches for media tree. Taken in my tree. By the way, have we reached any conclusion regarding https://lkml.org/lkml/ 2017/12/18/112 ? -- Regards, Laurent Pinchart
Re: [PATCH] [media] v4l: xilinx: fix typo in formats table
Hi Laurent, On 28.9.2018 14:52, Laurent Pinchart wrote: > Hi Andrea, > > Thank you for the patch. > > On Friday, 28 September 2018 10:32:13 EEST Andrea Merello wrote: >> In formats table the entry for CFA pattern "rggb" has GRBG fourcc. >> This patch fixes it. >> >> Cc: linux-media@vger.kernel.org >> Signed-off-by: Mirco Di Salvo >> Signed-off-by: Andrea Merello > > Reviewed-by: Laurent Pinchart > > Michal, should I take the patch in my tree ? definitely. I am not collecting patches for media tree. Thanks, Michal
Re: [RFC] V4L2_PIX_FMT_MJPEG vs V4L2_PIX_FMT_JPEG
Hello Hans, Le lundi 01 octobre 2018 à 10:43 +0200, Hans Verkuil a écrit : > It turns out that we have both JPEG and Motion-JPEG pixel formats defined. > > Furthermore, some drivers support one, some the other and some both. > > These pixelformats both mean the same. > > I propose that we settle on JPEG (since it seems to be used most often) and > add JPEG support to those drivers that currently only use MJPEG. Thanks for looking into this. As per GStreamer code, I see 3 alias for JPEG. V4L2_PIX_FMT_MJPEG/JPEG/PJPG. I don't know the context, this code was written before I knew GStreamer existed. It's possible there is a subtle difference, I have never looked at it, but clearly all our JPEG decoder handle these as being the same. https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/sys/v4l2/gstv4l2object.c#n956 > > We also need to update the V4L2_PIX_FMT_JPEG documentation since it just says > TBD: > > https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/pixfmt-compressed.html > > $ git grep -l V4L2_PIX_FMT_MJPEG > drivers/media/pci/meye/meye.c > drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c > drivers/media/platform/sti/delta/delta-cfg.h > drivers/media/platform/sti/delta/delta-mjpeg-dec.c > drivers/media/usb/cpia2/cpia2_v4l.c > drivers/media/usb/go7007/go7007-driver.c > drivers/media/usb/go7007/go7007-fw.c > drivers/media/usb/go7007/go7007-v4l2.c > drivers/media/usb/s2255/s2255drv.c > drivers/media/usb/uvc/uvc_driver.c > drivers/staging/media/zoran/zoran_driver.c > drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c > drivers/usb/gadget/function/uvc_v4l2.c > > It looks like s2255 and cpia2 support both already, so that would leave > 8 drivers that need to be modified, uvc being the most important of the > lot. > > Any comments? > > Regards, > > Hans
[ANN] Draft Agenda (v2) for the media summit on Thursday Oct 25th in Edinburgh
Hi all, We are organizing a media mini-summit on Thursday October 25th in Edinburgh, Edinburgh International Conference Centre. If you plan to attend, please register on the ELCE/OSS site since we're using there tracking system: https://events.linuxfoundation.org/events/elc-openiot-europe-2018/register/ Name of the room for the summit: Tinto, Level 0 of the EICC We had 75 people sign up for the summit as of a week ago, which is quite amazing. I'm not listing all of them here, just those that I know are active media developers: Sakari Ailus Neil Armstrong Kieran Bingham Mauro Carvalho Chehab Nicolas Dufresne (Collabora) Ezequiel Garcia Helen Koike Michael Ira Krufky (Vimeo/Livestream) Brad Love Jacopo Mondi Laurent Pinchart Ricardo Ribalda Delgado (Qtechnology A/S) Maxime Ripard Niklas Söderlund Hans Verkuil (Cisco) Sean Young (Monax) Agenda == General remarks: the given start/end times for the various topics are approximate since it is always hard to predict how long a discussion will take. If people are attending other summits and those conflict with specific topics they want to be part of, then let me know and we can rearrange the schedule to (hopefully) accomodate that. Let me know asap if there are problems with this schedule, or if new topics are requested. 9:00-9:20: Introduction (Hans Verkuil) Settling in, hooking everything up, getting wifi/projector/etc. to work, drinking coffee/tea/water and a short intro :-) 9:20-9:30: Status of the HDMI CEC kernel support (Hans Verkuil) Give a quick overview of the status: what has been merged, what is still pending, what is under development. 9:35-9:45: Status of the RC kernel support (Sean Young) A 10 minute status update on rc-core, present and future. I'll give a brief presentation and leave some time for discussion. 9:45-10:00: Save/restore controls from MTD (Ricardo Ribalda Delgado) Industrial/Scientific sensors usually come with very extensive calibration information such as: per column gain, list of dead pixels, temperature sensor offset... etc We are saving that information on an flash device that is located by the sensor. Show how we are integrating that calibration flash with v4l2-ctrl. And if this feature is useful for someone else and upstream it. 10:00-11:00: Complex Cameras (Mauro Carvalho Chehab) The idea is to discuss about the undergoing work with complex camera development is happening. As we're working to merge request API, another topic for discussion is how to add support for requests on it (or on a separate but related library). 11:00-11:15: Break 11:15-12:00: Automated Testing (Ezequiel Garcia) There is a lot of discussion going on around testing, so it's a good opportunity for us to talk about our current testing infrastructure. We are already doing a good job with v4l2-compliance. Can we do more? Lunch 13:30-14:30: Stateless Codec userspace (Hans Verkuil) Support for stateless codecs and Request API should be merged for 4.20, and the next step is to discuss how to organize the userspace support. Hopefully by the time the media summit starts we'll have some better ideas of what we want in this area. 14:30-15:15: Which ioctls should be replaced with better versions? (Hans Verkuil) Some parts of the V4L2 API are awkward to use and I think it would be a good idea to look at possible candidates for that. Examples are the ioctls that use struct v4l2_buffer: the multiplanar support is really horrible, and writing code to support both single and multiplanar is hard. We are also running out of fields and the timeval isn't y2038 compliant. A proof-of-concept is here: https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=v4l2-buffer=a95549df06d9900f3559afdbb9da06bd4b22d1f3 It's a bit old, but it gives a good impression of what I have in mind. Another candidate is VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL/VIDIOC_ENUM_FRAMEINTERVALS: expressing frame intervals as a fraction is really awkward and so is the fact that the subdev and 'normal' ioctls are not the same. Discuss what possible other ioctls are candidates for a refresh. 15:15-15:30: Break 15:30-16:00: Fault tolerant V4L2 (Kieran Bingham) In other words, how should we handle complex devices which do not 'fully probe' since one or more subdevices (e.g. sensors) are broken (or break while in use!). 16:00-16:30: Discuss the media development process Since we are all here, discuss any issues there may be with the media subsystem development process. Anything to improve? 16:30-16:45: Wrap up Create action items (and who will take care of them) if needed. Summarize and
Re: [PATCH v5] media: imx208: Add imx208 camera sensor driver
Hi, On Mon, Oct 01, 2018 at 12:50:02PM +0200, Helmut Grohne wrote: > Hi Laurent, > > On Fri, Sep 28, 2018 at 03:49:38PM +0200, Laurent Pinchart wrote: > > I don't think we'll reach an agreement here if we don't start talking about > > real use cases. Would you have some to share ? > > Fair enough, but at that point, we very much disconnect from the imx208 > in the subject. > > I'm working with a stereo camera. In that setup, you have two image > sensors and infer a three dimensional structure from images captured at > equal time points. For that to happen, it is important that the image > sensors use the same settings. In particular, settings such as expoure > and gain must match. That in turn means that you cannot use the > automatic exposure mode that comes with your image sensor. > > This is one reason for implementing exposure control outside of the > image sensor. Typically you can categorize your parameters into three > classes that affect the brightness of an image: aperture, shutter speed > and some kind of gain. If you know the units of these parameters, you > can estimate the effect of changing them on the resulting image. > > The algorithm for controlling brightness can be quite generic if you > know the units. V4L2_CID_EXPOSURE_ABSOLUTE is given in 100 µs. That > tends to work well. Typically, you prefer increasing exposure over > increasing gain to avoid noise. Similarly, you prefer increasing > analogue gain over increasing digital gain. On the other hand, there is > a limit on exposure to avoid motion blur. If an algorithm knows valid > values for these parameters, it can produce settings independently of > what concrete image sensor you use. > > > > 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. > > > > > > This approach is the one where users will need to know which sensor they > > > talk to. The one where the hardware abstraction happens in userspace. > > > Can we please not do that? > > > > Let's talk about it based on real use cases. > > So if you change your gain from 0 to 1, your image becomes roughly twice > as bright. In the typical scenario that's too bright, so when increasing > gain, you simultaneously decrease something else (e.g. exposure). But if > you don't know the effect of your gain change, you cannot tell how much > your exposure needs to be reduced. The only way out here is just doing > it and reducing exposure afterwards. Users tend to not like the > flickering resulting from this approach. > > > > * If it is non-linear and has fewer than X (1025?) values, use the > > >integer menu. > > > > 1024 ioctl calls to query the menu values ? :-( We need a better API than > > that. I'm also concerned that it wouldn't be very usable by userspace. > > Having > > a list of supported values is one thing, making efficient use of it is > > another. Again, use cases :-) > > You only need to query it once, but I'm not opposed to a better API > either. I just don't think it is that important or urgent. > > > I expect many algorithms to need a mathematical view of the valid values, > > not > > just a list. What particular algorithms do you have in mind ? > > A very simple algorithm could go like this: > * Assume that exposure time and gain have a linear effect on the >brightness of a captured image. This tends to not hold exactly, but >close enough. > * Compare brightness of the previous frame with a target value. > * Compute the product of current exposure time and gain. Adapt the >product according to the brightness error. > * Distribute this product to exposure time and gain such that exposure >time is maximal below a user-defined limit and that gain is one of >the valid values. > > All you need to know for using this besides V4L2_CID_EXPOSURE_ABSOLUTE, > is the valid gain values. > I agree with Helmut, and have exactly the same problem, even without stereo involved. But : V4L2_CID_EXPOSURE_ABSOLUTE unit is too high for the sensors I use, which provides a exposure time of 15,625 us, that I often need to use. one of my sensor provides an analog gain which can take the values 1, 1.5, 2, 3, 4, 6 and 8 and a digital gain which is a floating point number with 2 bits for the exponent and 6 bits for the mantissa, giving values from 1 to (1 + 63/64) * (1, 2, 4 or 8). I currently combine them and indicate the unit in the name of the control "gain (64th)", but a more robust solution would be welcome. the other sensor provides an analog gain which is expressed in tenth of dB (cB ?) from 0 to 480. Clearly this is difficult to comunicate to the user app using the current definition of V4L2_CID_GAIN. I think I'd need to be able to
Re: [RFC] V4L2_PIX_FMT_MJPEG vs V4L2_PIX_FMT_JPEG
Hi Hans, On Monday, 1 October 2018 14:54:29 EEST Hans Verkuil wrote: > On 10/01/2018 01:48 PM, Laurent Pinchart wrote: > > On Monday, 1 October 2018 11:43:04 EEST Hans Verkuil wrote: > >> It turns out that we have both JPEG and Motion-JPEG pixel formats > >> defined. > >> > >> Furthermore, some drivers support one, some the other and some both. > >> > >> These pixelformats both mean the same. > > > > Do they ? I thought MJPEG was JPEG using fixed Huffman tables that were > > not included in the JPEG headers. > > I'm not aware of any difference. If there is one, then it is certainly not > documented. What I can tell for sure is that many UVC devices don't include Huffman tables in their JPEG headers. > Ezequiel, since you've been working with this recently, do you know anything > about this? -- Regards, Laurent Pinchart
Re: [RFC] V4L2_PIX_FMT_MJPEG vs V4L2_PIX_FMT_JPEG
On 10/01/2018 01:48 PM, Laurent Pinchart wrote: > Hi Hans, > > On Monday, 1 October 2018 11:43:04 EEST Hans Verkuil wrote: >> It turns out that we have both JPEG and Motion-JPEG pixel formats defined. >> >> Furthermore, some drivers support one, some the other and some both. >> >> These pixelformats both mean the same. > > Do they ? I thought MJPEG was JPEG using fixed Huffman tables that were not > included in the JPEG headers. I'm not aware of any difference. If there is one, then it is certainly not documented. Ezequiel, since you've been working with this recently, do you know anything about this? Regards, Hans > >> I propose that we settle on JPEG (since it seems to be used most often) and >> add JPEG support to those drivers that currently only use MJPEG. >> >> We also need to update the V4L2_PIX_FMT_JPEG documentation since it just >> says TBD: >> >> https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/pixfmt-compresse >> d.html >> >> $ git grep -l V4L2_PIX_FMT_MJPEG >> drivers/media/pci/meye/meye.c >> drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c >> drivers/media/platform/sti/delta/delta-cfg.h >> drivers/media/platform/sti/delta/delta-mjpeg-dec.c >> drivers/media/usb/cpia2/cpia2_v4l.c >> drivers/media/usb/go7007/go7007-driver.c >> drivers/media/usb/go7007/go7007-fw.c >> drivers/media/usb/go7007/go7007-v4l2.c >> drivers/media/usb/s2255/s2255drv.c >> drivers/media/usb/uvc/uvc_driver.c >> drivers/staging/media/zoran/zoran_driver.c >> drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c >> drivers/usb/gadget/function/uvc_v4l2.c >> >> It looks like s2255 and cpia2 support both already, so that would leave >> 8 drivers that need to be modified, uvc being the most important of the >> lot. >> >> Any comments? >
Re: [RFC] V4L2_PIX_FMT_MJPEG vs V4L2_PIX_FMT_JPEG
Hi Hans, On Monday, 1 October 2018 11:43:04 EEST Hans Verkuil wrote: > It turns out that we have both JPEG and Motion-JPEG pixel formats defined. > > Furthermore, some drivers support one, some the other and some both. > > These pixelformats both mean the same. Do they ? I thought MJPEG was JPEG using fixed Huffman tables that were not included in the JPEG headers. > I propose that we settle on JPEG (since it seems to be used most often) and > add JPEG support to those drivers that currently only use MJPEG. > > We also need to update the V4L2_PIX_FMT_JPEG documentation since it just > says TBD: > > https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/pixfmt-compresse > d.html > > $ git grep -l V4L2_PIX_FMT_MJPEG > drivers/media/pci/meye/meye.c > drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c > drivers/media/platform/sti/delta/delta-cfg.h > drivers/media/platform/sti/delta/delta-mjpeg-dec.c > drivers/media/usb/cpia2/cpia2_v4l.c > drivers/media/usb/go7007/go7007-driver.c > drivers/media/usb/go7007/go7007-fw.c > drivers/media/usb/go7007/go7007-v4l2.c > drivers/media/usb/s2255/s2255drv.c > drivers/media/usb/uvc/uvc_driver.c > drivers/staging/media/zoran/zoran_driver.c > drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c > drivers/usb/gadget/function/uvc_v4l2.c > > It looks like s2255 and cpia2 support both already, so that would leave > 8 drivers that need to be modified, uvc being the most important of the > lot. > > Any comments? -- Regards, Laurent Pinchart
[GIT PULL v2 for 4.20] Big V4L2 fwnode patchset
Hi Mauro, This set contains the big V4L2 fwnode framework rework, including mine and Steve's patches. What is now possible includes tonnes of bugs fixed, default V4L2 fwnode endpoint configuration as well as less manual DT parsing in the i.MX driver. Since v1: - Updated fwnode patches from Steve, to address review comments (most importantly author vs. SoB difference). - Rebase on current media-tree master. - Added Jacopo's patchset adding default OF configuration for the renesas-ceu driver --- dependent on the rest of the set. Please pull. The following changes since commit 4158757395b300b6eb308fc20b96d1d231484413: media: davinci: Fix implicit enum conversion warning (2018-09-24 09:43:13 -0400) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git tags/v4l2-fwnode-v3.1-3-sign for you to fetch changes up to 0159592728d2acd15defca7172d38ad6fb7bbe36: media: renesas-ceu: Use default mbus settings (2018-10-01 13:44:06 +0300) Big v4l2 fwnode set plus Jacopo's renesas-ceu patches Jacopo Mondi (3): dt-bindings: media: renesas-ceu: Refer to video-interfaces.txt dt-bindings: media: renesas-ceu: Add more endpoint properties media: renesas-ceu: Use default mbus settings Sakari Ailus (23): v4l: fwnode: Add debug prints for V4L2 endpoint property parsing v4l: fwnode: Use fwnode_graph_for_each_endpoint v4l: fwnode: The CSI-2 clock is continuous if it's not non-continuous dt-bindings: media: Specify bus type for MIPI D-PHY, others, explicitly v4l: fwnode: Add definitions for CSI-2 D-PHY, parallel and Bt.656 busses v4l: mediabus: Recognise CSI-2 D-PHY and C-PHY v4l: fwnode: Let the caller provide V4L2 fwnode endpoint v4l: fwnode: Detect bus type correctly v4l: fwnode: Make use of newly specified bus types v4l: fwnode: Read lane inversion information despite lane numbering v4l: fwnode: Only assign configuration if there is no error v4l: fwnode: Support driver-defined lane mapping defaults v4l: fwnode: Support default CSI-2 lane mapping for drivers v4l: fwnode: Parse the graph endpoint as last v4l: fwnode: Use default parallel flags v4l: fwnode: Initialise the V4L2 fwnode endpoints to zero v4l: fwnode: Only zero the struct if bus type is set to V4L2_MBUS_UNKNOWN v4l: fwnode: Use media bus type for bus parser selection v4l: fwnode: Print bus type v4l: fwnode: Use V4L2 fwnode endpoint media bus type if set v4l: fwnode: Support parsing of CSI-2 C-PHY endpoints v4l: fwnode: Update V4L2 fwnode endpoint parsing documentation smiapp: Query the V4L2 endpoint for a specific bus type Steve Longerbeam (17): media: v4l2-fwnode: ignore endpoints that have no remote port parent media: v4l2: async: Allow searching for asd of any type media: v4l2: async: Add v4l2_async_notifier_add_subdev media: v4l2: async: Add convenience functions to allocate and add asd's media: v4l2-fwnode: Switch to v4l2_async_notifier_add_subdev media: v4l2-fwnode: Add a convenience function for registering subdevs with notifiers media: platform: video-mux: Register a subdev notifier media: imx: csi: Register a subdev notifier media: imx: mipi csi-2: Register a subdev notifier media: staging/imx: of: Remove recursive graph walk media: staging/imx: Loop through all registered subdevs for media links media: staging/imx: Rename root notifier media: staging/imx: Switch to v4l2_async_notifier_add_*_subdev media: staging/imx: TODO: Remove one assumption about OF graph parsing media: platform: Switch to v4l2_async_notifier_add_subdev media: v4l2: async: Remove notifier subdevs array v4l2-subdev.rst: Update doc regarding subdev descriptors .../devicetree/bindings/media/renesas,ceu.txt | 14 +- .../devicetree/bindings/media/video-interfaces.txt | 4 +- Documentation/media/kapi/v4l2-subdev.rst | 30 +- arch/arm/boot/dts/gr-peach-audiocamerashield.dtsi | 4 - drivers/gpu/ipu-v3/ipu-csi.c | 6 +- drivers/media/i2c/adv7180.c| 2 +- drivers/media/i2c/adv7604.c| 2 +- drivers/media/i2c/mt9v032.c| 2 +- drivers/media/i2c/ov2659.c | 14 +- drivers/media/i2c/ov5640.c | 6 +- drivers/media/i2c/ov5645.c | 2 +- drivers/media/i2c/ov5647.c | 2 +- drivers/media/i2c/ov7251.c | 4 +- drivers/media/i2c/ov7670.c | 2 +- drivers/media/i2c/s5c73m3/s5c73m3-core.c | 4 +- drivers/media/i2c/s5k5baf.c| 6 +- drivers/media/i2c/s5k6aa.c
Re: [PATCH v5] media: imx208: Add imx208 camera sensor driver
Hi Laurent, On Fri, Sep 28, 2018 at 03:49:38PM +0200, Laurent Pinchart wrote: > I don't think we'll reach an agreement here if we don't start talking about > real use cases. Would you have some to share ? Fair enough, but at that point, we very much disconnect from the imx208 in the subject. I'm working with a stereo camera. In that setup, you have two image sensors and infer a three dimensional structure from images captured at equal time points. For that to happen, it is important that the image sensors use the same settings. In particular, settings such as expoure and gain must match. That in turn means that you cannot use the automatic exposure mode that comes with your image sensor. This is one reason for implementing exposure control outside of the image sensor. Typically you can categorize your parameters into three classes that affect the brightness of an image: aperture, shutter speed and some kind of gain. If you know the units of these parameters, you can estimate the effect of changing them on the resulting image. The algorithm for controlling brightness can be quite generic if you know the units. V4L2_CID_EXPOSURE_ABSOLUTE is given in 100 µs. That tends to work well. Typically, you prefer increasing exposure over increasing gain to avoid noise. Similarly, you prefer increasing analogue gain over increasing digital gain. On the other hand, there is a limit on exposure to avoid motion blur. If an algorithm knows valid values for these parameters, it can produce settings independently of what concrete image sensor you use. > > 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. > > > > This approach is the one where users will need to know which sensor they > > talk to. The one where the hardware abstraction happens in userspace. > > Can we please not do that? > > Let's talk about it based on real use cases. So if you change your gain from 0 to 1, your image becomes roughly twice as bright. In the typical scenario that's too bright, so when increasing gain, you simultaneously decrease something else (e.g. exposure). But if you don't know the effect of your gain change, you cannot tell how much your exposure needs to be reduced. The only way out here is just doing it and reducing exposure afterwards. Users tend to not like the flickering resulting from this approach. > > * If it is non-linear and has fewer than X (1025?) values, use the > >integer menu. > > 1024 ioctl calls to query the menu values ? :-( We need a better API than > that. I'm also concerned that it wouldn't be very usable by userspace. Having > a list of supported values is one thing, making efficient use of it is > another. Again, use cases :-) You only need to query it once, but I'm not opposed to a better API either. I just don't think it is that important or urgent. > I expect many algorithms to need a mathematical view of the valid values, not > just a list. What particular algorithms do you have in mind ? A very simple algorithm could go like this: * Assume that exposure time and gain have a linear effect on the brightness of a captured image. This tends to not hold exactly, but close enough. * Compare brightness of the previous frame with a target value. * Compute the product of current exposure time and gain. Adapt the product according to the brightness error. * Distribute this product to exposure time and gain such that exposure time is maximal below a user-defined limit and that gain is one of the valid values. All you need to know for using this besides V4L2_CID_EXPOSURE_ABSOLUTE, is the valid gain values. Now I wonder, does this help in reaching a conclusion about whether querying valid gain values is a relevant use case? Helmut
Re: [PATCH v3 00/14] imx-media: Fixes for interlaced capture
Hi Steve, On 08/01/2018 09:12 PM, Steve Longerbeam wrote: > A set of patches that fixes some bugs with capturing from an > interlaced source, and incompatibilites between IDMAC interlace > interweaving and 4:2:0 data write reduction. I reviewed this series and it looks fine to me. It appears that the ipu* patches are already merged, so can you rebase and repost? I would also like to see the 'v4l2-compliance -f' for an interlaced source, if at all possible. For that matter, were you able to test all the field formats? Regards, Hans > > History: > v3: > - add support for/fix interweaved scan with YUV planar output. > - fix bug in 4:2:0 U/V offset macros. > - add patch that generalizes behavior of field swap in > ipu_csi_init_interface(). > - add support for interweaved scan with field order swap. > Suggested by Philipp Zabel. > - in v2, inteweave scan was determined using field types of > CSI (and PRPENCVF) at the sink and source pads. In v3, this > has been moved one hop downstream: interweave is now determined > using field type at source pad, and field type selected at > capture interface. Suggested by Philipp. > - make sure to double CSI crop target height when input field > type in alternate. > - more updates to media driver doc to reflect above. > > v2: > - update media driver doc. > - enable idmac interweave only if input field is sequential/alternate, > and output field is 'interlaced*'. > - move field try logic out of *try_fmt and into separate function. > - fix bug with resetting crop/compose rectangles. > - add a patch that fixes a field order bug in VDIC indirect mode. > - remove alternate field type from V4L2_FIELD_IS_SEQUENTIAL() macro > Suggested-by: Nicolas Dufresne . > - add macro V4L2_FIELD_IS_INTERLACED(). > > > Philipp Zabel (1): > gpu: ipu-v3: Allow negative offsets for interlaced scanning > > Steve Longerbeam (13): > media: videodev2.h: Add more field helper macros > gpu: ipu-csi: Check for field type alternate > gpu: ipu-csi: Swap fields according to input/output field types > gpu: ipu-v3: Fix U/V offset macros for planar 4:2:0 > gpu: ipu-v3: Add planar support to interlaced scan > media: imx: Fix field negotiation > media: imx-csi: Double crop height for alternate fields at sink > media: imx: interweave and odd-chroma-row skip are incompatible > media: imx-csi: Allow skipping odd chroma rows for YVU420 > media: imx: vdic: rely on VDIC for correct field order > media: imx-csi: Move crop/compose reset after filling default mbus > fields > media: imx: Allow interweave with top/bottom lines swapped > media: imx.rst: Update doc to reflect fixes to interlaced capture > > Documentation/media/v4l-drivers/imx.rst | 93 ++- > drivers/gpu/ipu-v3/ipu-cpmem.c| 45 ++- > drivers/gpu/ipu-v3/ipu-csi.c | 136 ++--- > drivers/staging/media/imx/imx-ic-prpencvf.c | 48 ++-- > drivers/staging/media/imx/imx-media-capture.c | 14 +++ > drivers/staging/media/imx/imx-media-csi.c | 166 > ++ > drivers/staging/media/imx/imx-media-vdic.c| 12 +- > include/uapi/linux/videodev2.h| 7 ++ > include/video/imx-ipu-v3.h| 6 +- > 9 files changed, 377 insertions(+), 150 deletions(-) >
[GIT PULL FOR v4.20] Various fixes
The following changes since commit 4158757395b300b6eb308fc20b96d1d231484413: media: davinci: Fix implicit enum conversion warning (2018-09-24 09:43:13 -0400) are available in the Git repository at: git://linuxtv.org/hverkuil/media_tree.git tags/tag-v4.20d for you to fetch changes up to f7a1170fcc19617647c78262a79abdec7b0a08cd: media: i2c: adv748x: fix typo in comment for TXB CSI-2 transmitter power down (2018-10-01 11:09:09 +0200) Tag branch Arnd Bergmann (1): media: imx-pxp: include linux/interrupt.h Benjamin Gaignard (1): MAINTAINERS: fix reference to STI CEC driver Colin Ian King (1): media: zoran: fix spelling mistake "queing" -> "queuing" Dan Carpenter (1): VPU: mediatek: don't pass an unused parameter Hans Verkuil (1): vidioc-dqevent.rst: clarify V4L2_EVENT_SRC_CH_RESOLUTION Hugues Fruchet (1): media: stm32-dcmi: only enable IT frame on JPEG capture Jacopo Mondi (4): media: i2c: adv748x: Support probing a single output media: i2c: adv748x: Handle TX[A|B] power management media: i2c: adv748x: Conditionally enable only CSI-2 outputs media: i2c: adv748x: Register only enabled inputs Laurent Pinchart (1): MAINTAINERS: Remove stale file entry for the Atmel ISI driver Nathan Chancellor (1): media: pxa_camera: Fix check for pdev->dev.of_node Niklas Söderlund (2): rcar-vin: fix redeclaration of symbol media: i2c: adv748x: fix typo in comment for TXB CSI-2 transmitter power down Philipp Zabel (1): media: imx: use well defined 32-bit RGB pixel format zhong jiang (1): media: qcom: remove duplicated include file Documentation/media/uapi/v4l/vidioc-dqevent.rst | 12 +++- MAINTAINERS | 3 +- drivers/media/i2c/adv748x/adv748x-afe.c | 2 +- drivers/media/i2c/adv748x/adv748x-core.c| 85 +++-- drivers/media/i2c/adv748x/adv748x-csi2.c| 29 ++ drivers/media/i2c/adv748x/adv748x-hdmi.c| 2 +- drivers/media/i2c/adv748x/adv748x.h | 19 drivers/media/platform/imx-pxp.c| 1 + drivers/media/platform/mtk-vpu/mtk_vpu.c| 7 ++--- drivers/media/platform/pxa_camera.c | 2 +- drivers/media/platform/qcom/camss/camss.h | 1 - drivers/media/platform/rcar-vin/rcar-core.c | 1 - drivers/media/platform/stm32/stm32-dcmi.c | 5 +++- drivers/staging/media/imx/imx-media-utils.c | 4 +-- drivers/staging/media/zoran/zoran_driver.c | 2 +- 15 files changed, 93 insertions(+), 82 deletions(-)
Re: [PATCH 2/5] v4l: controls: Add support for exponential bases, prefixes and units
On 10/01/2018 11:27 AM, Helmut Grohne wrote: > On Fri, Sep 28, 2018 at 04:00:17PM +0200, Hans Verkuil wrote: >> On 09/25/2018 12:14 PM, Sakari Ailus wrote: >>> +/* 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 >> >> I would prefer PREFIX_NONE, since there is no prefix in this case. >> >> I assume this prefix is only valid if the unit is not UNDEFINED and not >> NONE? > > Why should it? The prefix is concerned with rescaling a value prior to > presenting it to a user. Even a unitless quantity or a value of > undefined unit can be reasonably scaled. Displaying a unit and scaling > look like orthogonal concepts to me. What's the point? If I have a unit-less control with values 1-1000, then what would a prefix 'milli' tell me as a user? Why would 0.001-1 be better compared to 1-1000? Without a unit it is just an integer range and scaling is meaningless. > >> Is 'base' also dependent on a valid unit? (it doesn't appear to be) > > I'd argue it should not depend on a valid unit like the prefix. I think I agree with that, although I am dubious about the value of the base field as I commented on elsewhere. Regards, Hans
Re: [PATCH v2 0/6] media: video-i2c: support changing frame interval and runtime PM
On 09/23/2018 06:34 PM, Akinobu Mita wrote: > This patchset adds support for changing frame interval and runtime PM for > video-i2c driver. This also adds an helper macro to v4l2 common > internal API that is used to to find a suitable frame interval. > > There are a couple of unrelated changes that are included for simplifying > driver initialization code and register accesses. > > * v2 > - Add Acked-by and Reviewed-by tags > - Update commit log to clarify the use after free > - Add thermistor and termperature register address definisions > - Stop adding v4l2_find_closest_fract() in v4l2 common internal API > - Add V4L2_FRACT_COMPARE() macro in v4l2 common internal API > - Use V4L2_FRACT_COMPARE() to find suitable frame interval instead of > v4l2_find_closest_fract() 1) What's wrong with v4l2_find_closest_fract()? 2) Please test this with the latest v4l2-compliance: I recently improved the S_PARM checks, so I want to make sure this driver passes those tests. Regards, Hans > - Add comment for register address definisions > > Akinobu Mita (6): > media: video-i2c: avoid accessing released memory area when removing > driver > media: video-i2c: use i2c regmap > media: v4l2-common: add V4L2_FRACT_COMPARE > media: vivid: use V4L2_FRACT_COMPARE > media: video-i2c: support changing frame interval > media: video-i2c: support runtime PM > > drivers/media/i2c/video-i2c.c| 286 > ++- > drivers/media/platform/vivid/vivid-vid-cap.c | 9 +- > include/media/v4l2-common.h | 5 + > 3 files changed, 247 insertions(+), 53 deletions(-) > > Cc: Matt Ranostay > Cc: Sakari Ailus > Cc: Hans Verkuil > Cc: Mauro Carvalho Chehab >
Re: [PATCH v2 1/6] media: video-i2c: avoid accessing released memory area when removing driver
On 09/23/2018 06:34 PM, Akinobu Mita wrote:
> The video_i2c_data is allocated by kzalloc and released by the video
> device's release callback. The release callback is called when
> video_unregister_device() is called, but it will still be accessed after
> calling video_unregister_device().
>
> Fix the use after free by allocating video_i2c_data by devm_kzalloc() with
> i2c_client->dev so that it will automatically be released when the i2c
> driver is removed.
Hmm. The patch is right, but the explanation isn't. The core problem is
that vdev.release was set to video_i2c_release, but that should only be
used if struct video_device was kzalloc'ed. But in this case it is embedded
in a larger struct, and then vdev.release should always be set to
video_device_release_empty.
That was the real reason for the invalid access.
Regards,
Hans
>
> Fixes: 5cebaac60974 ("media: video-i2c: add video-i2c driver")
> Cc: Matt Ranostay
> Cc: Sakari Ailus
> Cc: Hans Verkuil
> Cc: Mauro Carvalho Chehab
> Acked-by: Matt Ranostay
> Signed-off-by: Akinobu Mita
> ---
> * v2
> - Update commit log to clarify the use after free
> - Add Acked-by tag
>
> drivers/media/i2c/video-i2c.c | 18 +-
> 1 file changed, 5 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
> index 06d29d8..b7a2af9 100644
> --- a/drivers/media/i2c/video-i2c.c
> +++ b/drivers/media/i2c/video-i2c.c
> @@ -508,20 +508,15 @@ static const struct v4l2_ioctl_ops video_i2c_ioctl_ops
> = {
> .vidioc_streamoff = vb2_ioctl_streamoff,
> };
>
> -static void video_i2c_release(struct video_device *vdev)
> -{
> - kfree(video_get_drvdata(vdev));
> -}
> -
> static int video_i2c_probe(struct i2c_client *client,
>const struct i2c_device_id *id)
> {
> struct video_i2c_data *data;
> struct v4l2_device *v4l2_dev;
> struct vb2_queue *queue;
> - int ret = -ENODEV;
> + int ret;
>
> - data = kzalloc(sizeof(*data), GFP_KERNEL);
> + data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
> if (!data)
> return -ENOMEM;
>
> @@ -530,7 +525,7 @@ static int video_i2c_probe(struct i2c_client *client,
> else if (id)
> data->chip = _i2c_chip[id->driver_data];
> else
> - goto error_free_device;
> + return -ENODEV;
>
> data->client = client;
> v4l2_dev = >v4l2_dev;
> @@ -538,7 +533,7 @@ static int video_i2c_probe(struct i2c_client *client,
>
> ret = v4l2_device_register(>dev, v4l2_dev);
> if (ret < 0)
> - goto error_free_device;
> + return ret;
>
> mutex_init(>lock);
> mutex_init(>queue_lock);
> @@ -568,7 +563,7 @@ static int video_i2c_probe(struct i2c_client *client,
> data->vdev.fops = _i2c_fops;
> data->vdev.lock = >lock;
> data->vdev.ioctl_ops = _i2c_ioctl_ops;
> - data->vdev.release = video_i2c_release;
> + data->vdev.release = video_device_release_empty;
> data->vdev.device_caps = V4L2_CAP_VIDEO_CAPTURE |
>V4L2_CAP_READWRITE | V4L2_CAP_STREAMING;
>
> @@ -597,9 +592,6 @@ static int video_i2c_probe(struct i2c_client *client,
> mutex_destroy(>lock);
> mutex_destroy(>queue_lock);
>
> -error_free_device:
> - kfree(data);
> -
> return ret;
> }
>
>
Re: [PATCH 2/5] v4l: controls: Add support for exponential bases, prefixes and units
On Fri, Sep 28, 2018 at 04:00:17PM +0200, Hans Verkuil wrote: > On 09/25/2018 12:14 PM, Sakari Ailus wrote: > > +/* 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 > > I would prefer PREFIX_NONE, since there is no prefix in this case. > > I assume this prefix is only valid if the unit is not UNDEFINED and not > NONE? Why should it? The prefix is concerned with rescaling a value prior to presenting it to a user. Even a unitless quantity or a value of undefined unit can be reasonably scaled. Displaying a unit and scaling look like orthogonal concepts to me. > Is 'base' also dependent on a valid unit? (it doesn't appear to be) I'd argue it should not depend on a valid unit like the prefix. Helmut
[RFC] V4L2_PIX_FMT_MJPEG vs V4L2_PIX_FMT_JPEG
It turns out that we have both JPEG and Motion-JPEG pixel formats defined. Furthermore, some drivers support one, some the other and some both. These pixelformats both mean the same. I propose that we settle on JPEG (since it seems to be used most often) and add JPEG support to those drivers that currently only use MJPEG. We also need to update the V4L2_PIX_FMT_JPEG documentation since it just says TBD: https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/pixfmt-compressed.html $ git grep -l V4L2_PIX_FMT_MJPEG drivers/media/pci/meye/meye.c drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c drivers/media/platform/sti/delta/delta-cfg.h drivers/media/platform/sti/delta/delta-mjpeg-dec.c drivers/media/usb/cpia2/cpia2_v4l.c drivers/media/usb/go7007/go7007-driver.c drivers/media/usb/go7007/go7007-fw.c drivers/media/usb/go7007/go7007-v4l2.c drivers/media/usb/s2255/s2255drv.c drivers/media/usb/uvc/uvc_driver.c drivers/staging/media/zoran/zoran_driver.c drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c drivers/usb/gadget/function/uvc_v4l2.c It looks like s2255 and cpia2 support both already, so that would leave 8 drivers that need to be modified, uvc being the most important of the lot. Any comments? Regards, Hans
[GIT PULL for 4.20] Unlocked V4L2 control grab, imx{319, 355} drivers
Hi Mauro,
Here are drivers for Sony imx319 and imx355 sensors and an unlocked version
of v4l2_ctrl_grab() which is used by the driver.
Please pull.
The following changes since commit 985cdcb08a0488558d1005139596b64d73bee267:
media: ov5640: fix restore of last mode set (2018-09-17 15:33:38 -0400)
are available in the git repository at:
ssh://linuxtv.org/git/sailus/media_tree.git tags/for-4.20-10-sign
for you to fetch changes up to d96444e7c6c6381e16d09c46feee46979ae3672b:
media: add imx355 camera sensor driver (2018-10-01 10:30:40 +0300)
unlocked v4l2 ctrl grab, imx{319, 355}
Bingbu Cao (2):
media: add imx319 camera sensor driver
media: add imx355 camera sensor driver
Sakari Ailus (2):
v4l: ctrl: Remove old documentation from v4l2_ctrl_grab
v4l: ctrl: Provide unlocked variant of v4l2_ctrl_grab
MAINTAINERS | 14 +
drivers/media/i2c/Kconfig| 22 +
drivers/media/i2c/Makefile |2 +
drivers/media/i2c/imx319.c | 2558 ++
drivers/media/i2c/imx355.c | 1858
drivers/media/v4l2-core/v4l2-ctrls.c | 14 +-
include/media/v4l2-ctrls.h | 26 +-
7 files changed, 4483 insertions(+), 11 deletions(-)
create mode 100644 drivers/media/i2c/imx319.c
create mode 100644 drivers/media/i2c/imx355.c
--
Regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi
Re: [PATCH v3] media: add imx355 camera sensor driver
Hi Bingbu,
On Sat, Sep 29, 2018 at 06:03:54PM +0800, bingbu@intel.com wrote:
> From: Bingbu Cao
>
> Add a v4l2 sub-device driver for the Sony imx355 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:
> - 3268x2448, 3264x2448, 3280x2464 @ 30fps
> - 1940x1096, 1936x1096, 1924x1080, 1920x1080 @ 60fps
> - 1640x1232, 1640x922, 1300x736, 1296x736,
> 1284x720, 1280x720 820x616 @ 120fps
> - support 4 bayer orders output (via change v/hflip)
> - SRGGB10(default), SGRBG10, SGBRG10, SBGGR10
>
> Cc: Tomasz Figa
> Cc: Sakari Ailus
> Signed-off-by: Tianshu Qiu
> Signed-off-by: Bingbu Cao
>
> ---
>
> This patch is based on sakari's media-tree git:
> https://git.linuxtv.org/sailus/media_tree.git/log/?h=for-4.20-8
>
> changes since v2:
> - get CSI-2 link frequencies and external clock
>from firmware
> - select digital gain mode when streaming
>
> changes v1 -> v2:
> - 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
> - correct link frequency
> - add more info into commit message
Thanks for the update.
I've applied the patch with the following diff, to make it work on systems
without 64-bit division:
diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
index 858cd0f8bc10..6878b444ea78 100644
--- a/drivers/media/i2c/imx355.c
+++ b/drivers/media/i2c/imx355.c
@@ -1360,7 +1360,8 @@ imx355_set_pad_format(struct v4l2_subdev *sd,
*framefmt = fmt->format;
} else {
imx355->cur_mode = mode;
- pixel_rate = (imx355->link_def_freq * 2 * 4) / 10;
+ pixel_rate = imx355->link_def_freq * 2 * 4;
+ do_div(pixel_rate, 10);
__v4l2_ctrl_s_ctrl_int64(imx355->pixel_rate, pixel_rate);
/* Update limits and set FPS to default */
height = imx355->cur_mode->height;
@@ -1587,7 +1588,8 @@ static int imx355_init_controls(struct imx355 *imx355)
imx355->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
/* pixel_rate = link_freq * 2 * nr_of_lanes / bits_per_sample */
- pixel_rate = (imx355->link_def_freq * 2 * 4) / 10;
+ pixel_rate = imx355->link_def_freq * 2 * 4;
+ do_div(pixel_rate, 10);
/* By default, PIXEL_RATE is read only */
imx355->pixel_rate = v4l2_ctrl_new_std(ctrl_hdlr, _ctrl_ops,
V4L2_CID_PIXEL_RATE, pixel_rate,
--
Kind regards,
Sakari Ailus
sakari.ai...@linux.intel.com
