Re: [PATCH 01/12] videodev2.h, v4l2-ioctl: add IPU3 meta buffer format
Hi Tomasz, On Tue, Jun 06, 2017 at 01:30:41PM +0900, Tomasz Figa wrote: > Uhm, +Laurent. Sorry for the noise. > > On Tue, Jun 6, 2017 at 1:30 PM, Tomasz Figa wrote: > > Hi Yong, > > > > On Tue, Jun 6, 2017 at 5:39 AM, Yong Zhi wrote: > >> Add the IPU3 specific processing parameter format > >> V4L2_META_FMT_IPU3_PARAMS and metadata formats > >> for 3A and other statistics: > > > > Please see my comments inline. > > > >> > >> V4L2_META_FMT_IPU3_PARAMS > >> V4L2_META_FMT_IPU3_STAT_3A > >> V4L2_META_FMT_IPU3_STAT_DVS > >> V4L2_META_FMT_IPU3_STAT_LACE > >> > >> Signed-off-by: Yong Zhi > >> --- > >> drivers/media/v4l2-core/v4l2-ioctl.c | 4 > >> include/uapi/linux/videodev2.h | 6 ++ > >> 2 files changed, 10 insertions(+) > > [snip] > >> +/* Vendor specific - used for IPU3 camera sub-system */ > >> +#define V4L2_META_FMT_IPU3_PARAMS v4l2_fourcc('i', 'p', '3', 'p') /* > >> IPU3 params */ > >> +#define V4L2_META_FMT_IPU3_STAT_3A v4l2_fourcc('i', 'p', '3', 's') /* > >> IPU3 3A statistics */ > >> +#define V4L2_META_FMT_IPU3_STAT_DVSv4l2_fourcc('i', 'p', '3', 'd') /* > >> IPU3 DVS statistics */ > >> +#define V4L2_META_FMT_IPU3_STAT_LACE v4l2_fourcc('i', 'p', '3', 'l') /* > >> IPU3 LACE statistics */ > > > > We had some discussion about this with Laurent and if I remember > > correctly, the conclusion was that it might make sense to define one > > FourCC for a vendor specific format, ('v', 'n', 'd', 'r') for example, > > and then have a V4L2-specific enum within the v4l2_pix_format(_mplane) > > struct that specifies the exact vendor data type. It seems saner than > > assigning a new FourCC whenever a new hardware revision comes out, > > especially given that FourCCs tend to be used outside of the V4L2 > > world as well and being kind of (de facto) standardized (with existing > > exceptions, unfortunately). If we have four video nodes with different vendor specific formats, how does the user tell the formats apart? I presume the user space could use the entity names for instance, but that would essentially make them device specific. I'm not sure if there would be any harm from that in practice though: the user will need to find the device nodes somehow and that will be very likely based on e.g. entity names. How should the documentation be arranged? The documentation is arranged by fourccs currently; we'd probably need a separate section for vendor specific formats. I think the device name should be listed there as well. I'd like to have perhaps Hans's comment on that as well. I don't really see a drawback in the current way of doing this either; we may get a few new fourcc codes occasionally of which I'm not really worried about. --- I'd rather ask why should there be an exception on how vendor specific formats are defined. And if we do make an exception, then how do you decide which one is and isn't vendor specific? There are raw bayer format variants that are just raw bayer data but the pixels are arranged differently (e.g. CIO2 driver). -- Regards, Sakari Ailus sakari.ai...@linux.intel.com
Re: Question about Large Custom Coefficients for V4L2 sub-device drivers
On 05/06/17 18:32, Rohit Athavale wrote: > Hello Media Community, > > I am working on a scaler and gamma correction V4L2 sub-device based drivers. > A common theme to both of them is that > the kernel driver is expected bring-up these devices in a working (good) > configuration. As it turns out these coefficients are tailor-made > or are fairly complex to generate dynamically at run-time. > > This implies the driver has to store at least one set of coefficients for > each supported configuration. This could easily become 10-20 KB of data > stored as a large static array of shorts or integers. > > I have a couple of questions to ask all here : > > 1. What is the best practice for embedding large coefficients ( > 10 KB) into > V4L2 sub-device based drivers ? Typically it is just a static const array. For large arrays it is best to put them in a separate source so it doesn't overwhelm the actual driver code. > 2. How can user applications feed coefficients to the sub-device based V4L2 > drivers ? I'm wondering if there is standard ioctl, write or mmap file op > that can be performed to achieve this ? In most cases you can make an extended control (array or compound) for this. If the hardware supports some sort of DMA hardware to load the coefficients quickly into memory, then a video node can be created. But based on what you write that doesn't appear to be necessary. Regards, Hans > > All inputs will be greatly appreciated :) > > Best Regards, > Rohit > > > > This email and any attachments are intended for the sole use of the named > recipient(s) and contain(s) confidential information that may be proprietary, > privileged or copyrighted under applicable law. If you are not the intended > recipient, do not read, copy, or forward this email message or any > attachments. Delete this email message and any attachments immediately. >
Re: [RFC] V4L2 unified low-level decoder API
Hi Randy, Did you get a chance to review interface ? I would really appreciate your feedback in order that we move forward on this topic and get at least one implementation merged. Best regards, Hugues. On 05/19/2017 10:15 AM, Randy Li wrote: > > > On 05/19/2017 04:08 PM, Hugues FRUCHET wrote: >> Hi all, >> >> Here is the latest st-delta MPEG2 code: >> [PATCH v6 0/3] Add support for MPEG-2 in DELTA video decoder >> http://www.mail-archive.com/linux-media@vger.kernel.org/msg112067.html >> [PATCH v2 0/3] Add a libv4l plugin for video bitstream parsing >> http://www.mail-archive.com/linux-media@vger.kernel.org/msg112076.html >> > I would review it. >> Before merging this work Hans would like to have feedback from peers, in >> order to be sure that this is inline with other SoC vendors drivers >> expectations. >> >> Thomasz, Pawel, could you give your view regarding ChromeOS and Rockchip >> driver ? > The work of the rockchip just re-start a few weeks age, I have just > finished the driver probing type as I decide to make a clean beginning. > The video IP of the rockchip is too complext with a different combine. > > The pixel format will begin in JPEG then AVC. I am now more familiar > with those codec now. >> Laurent, could you give your view regarding Renesas driver ? >> >> I have also added in appendice [7] the materials presented by Laurent at >> ELC 2017 in Portland to introduce stateless video codecs and V4L2 >> request API, thanks for this presentation Laurent. >> >> >> Best regards, >> Hugues. >> >>> On 02/07/2017 08:21 AM, Hugues FRUCHET wrote: >>> Hi, >>> >>> Here is an update regarding MPEG-2 implementation based on ST video decoder: >>> * MPEG-2 API + DELTA kernel driver: >>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg107405.html >>> * libv4l-codecparsers plugin including MPEG-2 back-end: >>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg107812.html >>> >>> Please note that this is implemented & functional using currently available >>> V4L2 control framework (no Request API), assuming that user side keeps >>> unicity of S_EXT_CTRL() / QBUF(OUTPUT) pair. >>> Request API will remove this constraint, but the point here is to define >>> control interface, as far as I have understood code, Request API will not >>> affect those control definitions. >>> >>> Some updates inline thereafter regarding activities on this subject; me for >>> MPEG-2 on ST platform and Randy Li, Nicolas Dufresne, Ayaka for H264 on >>> Rockchip platform: >>> >>> >>> On 11/14/2016 10:55 AM, Hans Verkuil wrote: On 10/27/2016 09:42 AM, Hugues FRUCHET wrote: > Hi, > > This RFC aims to start discussions in order to define the codec > specific controls structures to fulfill the low-level decoder API > needed by non "Stream API" based decoders ("stateless" or "Frame API" > based decoders). Let's refer to this as 'stateful' decoders and 'stateless' decoders. This is the preferred terminology (and much more descriptive than 'Stream' vs 'Frame'). It's also not really a new API, although it does rely on the Request API. > Several implementation exists now which runs on several SoC and > various software frameworks. > The idea is to find the communalities between all those > implementations and SoC to define a single unified interface in V4L2 > includes. > Even if "Request API" is needed to pass those codec specific controls > from userspace down to kernel on a per-buffer basis, we can start > discussions and define the controls in parallel of its development. > We can even propose some implementations based on existing V4L2 > control framework (which doesn't support "per-frame" basis) by > ensuring atomicity of sequence S_EXT_CTRL(header[i])/QBUF(stream[i]). > Constraint can then be relaxed when "Request API" is merged. > > I would like to propose to work on a "per-codec" basis, having at > least > 2 different SoC and 2 different frameworks to test and validate controls. > To do so, I have tried to identify some people that have worked on > this subject and have proposed some implementations, feel free to > correct me and enhance the list if needed: > * MPEG2/MPEG4 >- Florent Revest for Allwinner A13 CedarX support [1] tested with > VLC -> libVA + sunxi-cedrus-drv-video -> V4L2 >- Myself for STMicroelectronics Delta support [2] tested with > GStreamer V4L2 -> libv4l2 + libv4l-delta plugin -> V4L2 >>> Available on ST platform with [2] & [2.1] patchset series. >>> > > * VP8 > - Pawel Osciak for Rockchip RK3288, RK3399? VPU Support [3] tested > with Chromium -> V4L2 > - Jung Zhao for Rockchip RK3288 VPU support [4] framework used> > > * H264 > - Pawel Osciak for Rockchip RK3288, RK3399? VPU Support [5] tested > with Chromium -> V4L2 > - Randy Li for Rockchip RK3288 VPU support [6] tested
Re: [PATCH 01/12] videodev2.h, v4l2-ioctl: add IPU3 meta buffer format
On 06/06/17 09:25, Sakari Ailus wrote: > Hi Tomasz, > > On Tue, Jun 06, 2017 at 01:30:41PM +0900, Tomasz Figa wrote: >> Uhm, +Laurent. Sorry for the noise. >> >> On Tue, Jun 6, 2017 at 1:30 PM, Tomasz Figa wrote: >>> Hi Yong, >>> >>> On Tue, Jun 6, 2017 at 5:39 AM, Yong Zhi wrote: Add the IPU3 specific processing parameter format V4L2_META_FMT_IPU3_PARAMS and metadata formats for 3A and other statistics: >>> >>> Please see my comments inline. >>> V4L2_META_FMT_IPU3_PARAMS V4L2_META_FMT_IPU3_STAT_3A V4L2_META_FMT_IPU3_STAT_DVS V4L2_META_FMT_IPU3_STAT_LACE Signed-off-by: Yong Zhi --- drivers/media/v4l2-core/v4l2-ioctl.c | 4 include/uapi/linux/videodev2.h | 6 ++ 2 files changed, 10 insertions(+) >>> [snip] +/* Vendor specific - used for IPU3 camera sub-system */ +#define V4L2_META_FMT_IPU3_PARAMS v4l2_fourcc('i', 'p', '3', 'p') /* IPU3 params */ +#define V4L2_META_FMT_IPU3_STAT_3A v4l2_fourcc('i', 'p', '3', 's') /* IPU3 3A statistics */ +#define V4L2_META_FMT_IPU3_STAT_DVSv4l2_fourcc('i', 'p', '3', 'd') /* IPU3 DVS statistics */ +#define V4L2_META_FMT_IPU3_STAT_LACE v4l2_fourcc('i', 'p', '3', 'l') /* IPU3 LACE statistics */ >>> >>> We had some discussion about this with Laurent and if I remember >>> correctly, the conclusion was that it might make sense to define one >>> FourCC for a vendor specific format, ('v', 'n', 'd', 'r') for example, >>> and then have a V4L2-specific enum within the v4l2_pix_format(_mplane) >>> struct that specifies the exact vendor data type. It seems saner than >>> assigning a new FourCC whenever a new hardware revision comes out, >>> especially given that FourCCs tend to be used outside of the V4L2 >>> world as well and being kind of (de facto) standardized (with existing >>> exceptions, unfortunately). I can't remember that discussion, although I've had other discussions with Laurent related to this on how to handle formats that have many variations on a theme. But speaking for this specific case I see no reason to do something special. There are only four new formats, which seems perfectly reasonable to me. I don't see the advantage of adding another layer of pixel formats. You still need to define something for this, one way or the other. And this way doesn't require API changes. > If we have four video nodes with different vendor specific formats, how does > the user tell the formats apart? I presume the user space could use the > entity names for instance, but that would essentially make them device > specific. Well, they are. There really is no way to avoid that. > I'm not sure if there would be any harm from that in practice though: the > user will need to find the device nodes somehow and that will be very likely > based on e.g. entity names. > > How should the documentation be arranged? The documentation is arranged by > fourccs currently; we'd probably need a separate section for vendor specific > formats. I think the device name should be listed there as well. There already is a separate section for metadata formats: https://hverkuil.home.xs4all.nl/spec/uapi/v4l/meta-formats.html But perhaps that page should be organized by device. And with some more detailed information on how to find the video node (i.e. entity names). > I'd like to have perhaps Hans's comment on that as well. > > I don't really see a drawback in the current way of doing this either; we > may get a few new fourcc codes occasionally of which I'm not really worried > about. --- I'd rather ask why should there be an exception on how vendor > specific formats are defined. And if we do make an exception, then how do > you decide which one is and isn't vendor specific? There are raw bayer > format variants that are just raw bayer data but the pixels are arranged > differently (e.g. CIO2 driver). > For these unique formats I am happy with the way it is today. The problem is more with 'parameterized' formats. A simple example would be the 4:2:2 interleaved YUV formats where you have four different ways of ordering the Y, U and V components. Right now we have four defines for that, but things get out of hand quickly when you have multiple parameters like that. Laurent and myself discussed that with NVidia some time ago, without reaching a clear conclusion. Mostly because we couldn't come up with an API that is simple enough. Regards, Hans
Re: [PATCH 02/12] intel-ipu3: mmu: implement driver
On 05/06/17 22:39, Yong Zhi wrote: > From: Tuukka Toivonen > > This driver translates Intel IPU3 internal virtual > address to physical address. > > Signed-off-by: Yong Zhi > --- > drivers/media/pci/intel/ipu3/Kconfig| 11 + > drivers/media/pci/intel/ipu3/Makefile | 1 + > drivers/media/pci/intel/ipu3/ipu3-mmu.c | 423 > > drivers/media/pci/intel/ipu3/ipu3-mmu.h | 73 ++ > 4 files changed, 508 insertions(+) > create mode 100644 drivers/media/pci/intel/ipu3/ipu3-mmu.c > create mode 100644 drivers/media/pci/intel/ipu3/ipu3-mmu.h > Why is this patch and the next patch (03/12) in drivers/media? I wonder what the reasoning is behind that since it doesn't seem very media specific. Regards, Hans
Re: [RFC] V4L2 unified low-level decoder API
On 06/06/2017 03:59 PM, Hugues FRUCHET wrote: Hi Randy, Did you get a chance to review interface ? Oh, I have had look a quick view on it yesterday. The video IP of that platform doesn't come from the On2, right? I would really appreciate your feedback in order that we move forward on this topic and get at least one implementation merged. I am a little busy recently, I will give you a feedback before the next Monday. btw, only the MPEG-2 is supported? I am not very familiar with MPEG-2 standard, I am more familiar with MPEG-4 PART 10 or HEVC. As the MPEG-2 is more simple, I may not meet any problem to understand it. Best regards, Hugues. On 05/19/2017 10:15 AM, Randy Li wrote: On 05/19/2017 04:08 PM, Hugues FRUCHET wrote: Hi all, Here is the latest st-delta MPEG2 code: [PATCH v6 0/3] Add support for MPEG-2 in DELTA video decoder http://www.mail-archive.com/linux-media@vger.kernel.org/msg112067.html [PATCH v2 0/3] Add a libv4l plugin for video bitstream parsing http://www.mail-archive.com/linux-media@vger.kernel.org/msg112076.html I would review it. Before merging this work Hans would like to have feedback from peers, in order to be sure that this is inline with other SoC vendors drivers expectations. Thomasz, Pawel, could you give your view regarding ChromeOS and Rockchip driver ? The work of the rockchip just re-start a few weeks age, I have just finished the driver probing type as I decide to make a clean beginning. The video IP of the rockchip is too complext with a different combine. The pixel format will begin in JPEG then AVC. I am now more familiar with those codec now. Laurent, could you give your view regarding Renesas driver ? I have also added in appendice [7] the materials presented by Laurent at ELC 2017 in Portland to introduce stateless video codecs and V4L2 request API, thanks for this presentation Laurent. Best regards, Hugues. On 02/07/2017 08:21 AM, Hugues FRUCHET wrote: Hi, Here is an update regarding MPEG-2 implementation based on ST video decoder: * MPEG-2 API + DELTA kernel driver: http://www.mail-archive.com/linux-media@vger.kernel.org/msg107405.html * libv4l-codecparsers plugin including MPEG-2 back-end: http://www.mail-archive.com/linux-media@vger.kernel.org/msg107812.html Please note that this is implemented & functional using currently available V4L2 control framework (no Request API), assuming that user side keeps unicity of S_EXT_CTRL() / QBUF(OUTPUT) pair. Request API will remove this constraint, but the point here is to define control interface, as far as I have understood code, Request API will not affect those control definitions. Some updates inline thereafter regarding activities on this subject; me for MPEG-2 on ST platform and Randy Li, Nicolas Dufresne, Ayaka for H264 on Rockchip platform: On 11/14/2016 10:55 AM, Hans Verkuil wrote: On 10/27/2016 09:42 AM, Hugues FRUCHET wrote: Hi, This RFC aims to start discussions in order to define the codec specific controls structures to fulfill the low-level decoder API needed by non "Stream API" based decoders ("stateless" or "Frame API" based decoders). Let's refer to this as 'stateful' decoders and 'stateless' decoders. This is the preferred terminology (and much more descriptive than 'Stream' vs 'Frame'). It's also not really a new API, although it does rely on the Request API. Several implementation exists now which runs on several SoC and various software frameworks. The idea is to find the communalities between all those implementations and SoC to define a single unified interface in V4L2 includes. Even if "Request API" is needed to pass those codec specific controls from userspace down to kernel on a per-buffer basis, we can start discussions and define the controls in parallel of its development. We can even propose some implementations based on existing V4L2 control framework (which doesn't support "per-frame" basis) by ensuring atomicity of sequence S_EXT_CTRL(header[i])/QBUF(stream[i]). Constraint can then be relaxed when "Request API" is merged. I would like to propose to work on a "per-codec" basis, having at least 2 different SoC and 2 different frameworks to test and validate controls. To do so, I have tried to identify some people that have worked on this subject and have proposed some implementations, feel free to correct me and enhance the list if needed: * MPEG2/MPEG4 - Florent Revest for Allwinner A13 CedarX support [1] tested with VLC -> libVA + sunxi-cedrus-drv-video -> V4L2 - Myself for STMicroelectronics Delta support [2] tested with GStreamer V4L2 -> libv4l2 + libv4l-delta plugin -> V4L2 Available on ST platform with [2] & [2.1] patchset series. * VP8 - Pawel Osciak for Rockchip RK3288, RK3399? VPU Support [3] tested with Chromium -> V4L2 - Jung Zhao for Rockchip RK3288 VPU support [4] * H264 - Pawel Osciak for Rockchip RK3288, RK3399? VPU Support [5] tested with Chromium -> V4L2 - Randy Li for Rockchip RK3288 VPU support [6] test
Re: [PATCH 04/12] intel-ipu3: Add user space ABI definitions
On 05/06/17 22:39, Yong Zhi wrote: Commit message missing. > Signed-off-by: Yong Zhi > --- > include/uapi/linux/intel-ipu3.h | 2182 > +++ > 1 file changed, 2182 insertions(+) > create mode 100644 include/uapi/linux/intel-ipu3.h > > diff --git a/include/uapi/linux/intel-ipu3.h b/include/uapi/linux/intel-ipu3.h > new file mode 100644 > index 000..9e90aec > --- /dev/null > +++ b/include/uapi/linux/intel-ipu3.h > @@ -0,0 +1,2182 @@ > +/* > + * Copyright (c) 2017 Intel Corporation. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License version > + * 2 as published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#ifndef __IPU3_UAPI_H > +#define __IPU3_UAPI_H > + > +#include > + > +#define IPU3_UAPI_ISP_VEC_ELEMS 64 > + > +#define IMGU_ABI_PAD __aligned(IPU3_UAPI_ISP_WORD_BYTES) > +#define IPU3_ALIGN __attribute__((aligned(IPU3_UAPI_ISP_WORD_BYTES))) > + > +#define IPU3_UAPI_ISP_WORD_BYTES 32 > +#define IPU3_UAPI_MAX_STRIPES2 > + > +/*** ipu3_uapi_stats_3a ***/ > + > +#define IPU3_UAPI_MAX_BUBBLE_SIZE10 > + > +#define IPU3_UAPI_AE_COLORS 4 > +#define IPU3_UAPI_AE_BINS256 > + > +#define IPU3_UAPI_AWB_MD_ITEM_SIZE 8 > +#define IPU3_UAPI_AWB_MAX_SETS 60 > +#define IPU3_UAPI_AWB_SET_SIZE 0x500 > +#define IPU3_UAPI_AWB_SPARE_FOR_BUBBLES \ > + (IPU3_UAPI_MAX_BUBBLE_SIZE * IPU3_UAPI_MAX_STRIPES * \ > + IPU3_UAPI_AWB_MD_ITEM_SIZE) > +#define IPU3_UAPI_AWB_MAX_BUFFER_SIZE \ > + (IPU3_UAPI_AWB_MAX_SETS * \ > + (IPU3_UAPI_AWB_SET_SIZE + IPU3_UAPI_AWB_SPARE_FOR_BUBBLES)) > + > +#define IPU3_UAPI_AF_MAX_SETS24 > +#define IPU3_UAPI_AF_MD_ITEM_SIZE4 > +#define IPU3_UAPI_AF_SPARE_FOR_BUBBLES \ > + (IPU3_UAPI_MAX_BUBBLE_SIZE * IPU3_UAPI_MAX_STRIPES * \ > + IPU3_UAPI_AF_MD_ITEM_SIZE) > +#define IPU3_UAPI_AF_Y_TABLE_SET_SIZE0x80 > +#define IPU3_UAPI_AF_Y_TABLE_MAX_SIZE \ > + (IPU3_UAPI_AF_MAX_SETS * \ > + (IPU3_UAPI_AF_Y_TABLE_SET_SIZE + IPU3_UAPI_AF_SPARE_FOR_BUBBLES) * \ > + IPU3_UAPI_MAX_STRIPES) > + > +#define IPU3_UAPI_AWB_FR_MAX_SETS24 > +#define IPU3_UAPI_AWB_FR_MD_ITEM_SIZE8 > +#define IPU3_UAPI_AWB_FR_BAYER_TBL_SIZE 0x100 > +#define IPU3_UAPI_AWB_FR_SPARE_FOR_BUBBLES \ > + (IPU3_UAPI_MAX_BUBBLE_SIZE * IPU3_UAPI_MAX_STRIPES * \ > + IPU3_UAPI_AWB_FR_MD_ITEM_SIZE) > +#define IPU3_UAPI_AWB_FR_BAYER_TABLE_MAX_SIZE \ > + (IPU3_UAPI_AWB_FR_MAX_SETS * \ > + (IPU3_UAPI_AWB_FR_BAYER_TBL_SIZE + \ > + IPU3_UAPI_AWB_FR_SPARE_FOR_BUBBLES) * \ > + IPU3_UAPI_MAX_STRIPES) > + > +struct ipu3_uapi_grid_config { > + __u8 width; /* 6 or 7 (rgbs_grd_cfg) bits */ > + __u8 height; > + __u16 block_width_log2:3; > + __u16 block_height_log2:3; > + __u16 height_per_slice:8; /* default value 1 */ > + __u16 x_start; /* 12 bits */ > + __u16 y_start; > +#define IPU3_UAPI_GRID_START_MASK((1 << 12) - 1) > +#define IPU3_UAPI_GRID_Y_START_EN(1 << 15) > + __u16 x_end;/* 12 bits */ > + __u16 y_end; > +}; You can't use bitfields in a public API. It is up to the compiler to decide how to place bitfields, so this is not a stable API. The other thing that is broken here is 32 vs 64 bit: many of these structures have different layouts depending on that. That's not going to work either. The third part is lack of documentation. Are there public datasheets? If so, then you can point to that. Sakari, how did we do that for the omap3? I believe part of the statistics etc. was in closed documentation as well. Was it documented in the header or did we just refer to that closed documentation? Regards, Hans > + > +struct ipu3_uapi_awb_meta_data { > + __u8 meta_data_buffer[IPU3_UAPI_AWB_MAX_BUFFER_SIZE]; > +}; > + > +struct ipu3_uapi_awb_raw_buffer { > + struct ipu3_uapi_awb_meta_data meta_data; > +}; > + > +struct IPU3_ALIGN ipu3_uapi_awb_config_s { > + __u16 rgbs_thr_gr; > + __u16 rgbs_thr_r; > + __u16 rgbs_thr_gb; > + __u16 rgbs_thr_b; > +/* controls generation of meta_data (like FF enable/disable) */ > +#define IPU3_UAPI_AWB_
Re: [PATCH 07/12] intel-ipu3: css: firmware management
On 05/06/17 22:39, Yong Zhi wrote: > Functions to load and install imgu FW blobs > > Signed-off-by: Yong Zhi > --- > drivers/media/pci/intel/ipu3/ipu3-abi.h| 1572 > > drivers/media/pci/intel/ipu3/ipu3-css-fw.c | 272 + > drivers/media/pci/intel/ipu3/ipu3-css-fw.h | 215 > drivers/media/pci/intel/ipu3/ipu3-css.h| 54 + > 4 files changed, 2113 insertions(+) > create mode 100644 drivers/media/pci/intel/ipu3/ipu3-abi.h > create mode 100644 drivers/media/pci/intel/ipu3/ipu3-css-fw.c > create mode 100644 drivers/media/pci/intel/ipu3/ipu3-css-fw.h > create mode 100644 drivers/media/pci/intel/ipu3/ipu3-css.h Has this been tested for both i686 and x86_64 modes? Regards, Hans
Re: [PATCH 11/12] intel-ipu3: Add imgu v4l2 driver
On 05/06/17 22:39, Yong Zhi wrote: > ipu3 imgu video device based on v4l2, vb2 and > media controller framework. > > Signed-off-by: Yong Zhi > --- > drivers/media/pci/intel/ipu3/ipu3-v4l2.c | 723 > +++ > 1 file changed, 723 insertions(+) > create mode 100644 drivers/media/pci/intel/ipu3/ipu3-v4l2.c > > diff --git a/drivers/media/pci/intel/ipu3/ipu3-v4l2.c > b/drivers/media/pci/intel/ipu3/ipu3-v4l2.c > new file mode 100644 > index 000..bc219c1 > --- /dev/null > +++ b/drivers/media/pci/intel/ipu3/ipu3-v4l2.c > @@ -0,0 +1,723 @@ > +/* > + * Copyright (c) 2017 Intel Corporation. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License version > + * 2 as published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + */ > + > +#include > +#include > +#include > +#include > + > +#include "ipu3.h" > + > +/ v4l2_subdev_ops / > + > +static int ipu3_subdev_s_stream(struct v4l2_subdev *sd, int enable) > +{ > + struct ipu3_mem2mem2_device *m2m2 = > + container_of(sd, struct ipu3_mem2mem2_device, subdev); > + int r = 0; > + > + if (m2m2->ops && m2m2->ops->s_stream) > + r = m2m2->ops->s_stream(m2m2, enable); > + > + if (!r) > + m2m2->streaming = enable; > + > + return r; > +} > + > +static int ipu3_subdev_get_fmt(struct v4l2_subdev *sd, > +struct v4l2_subdev_pad_config *cfg, > +struct v4l2_subdev_format *fmt) > +{ > + struct ipu3_mem2mem2_device *m2m2 = > + container_of(sd, struct ipu3_mem2mem2_device, subdev); > + struct v4l2_mbus_framefmt *mf; > + u32 pad = fmt->pad; > + > + if (fmt->which == V4L2_SUBDEV_FORMAT_ACTIVE) { > + fmt->format = m2m2->nodes[pad].pad_fmt; > + } else { > + mf = v4l2_subdev_get_try_format(sd, cfg, pad); > + fmt->format = *mf; > + } > + > + return 0; > +} > + > +static int ipu3_subdev_set_fmt(struct v4l2_subdev *sd, > +struct v4l2_subdev_pad_config *cfg, > +struct v4l2_subdev_format *fmt) > +{ > + struct ipu3_mem2mem2_device *m2m2 = > + container_of(sd, struct ipu3_mem2mem2_device, subdev); > + struct v4l2_mbus_framefmt *mf; > + u32 pad = fmt->pad; > + > + if (fmt->which == V4L2_SUBDEV_FORMAT_TRY) > + mf = v4l2_subdev_get_try_format(sd, cfg, pad); > + else > + mf = &m2m2->nodes[pad].pad_fmt; > + > + /* Clamp the w and h based on the hardware capabilities */ > + if (m2m2->subdev_pads[pad].flags & MEDIA_PAD_FL_SOURCE) { > + > + fmt->format.width = clamp(fmt->format.width, > + IPU3_OUTPUT_MIN_WIDTH, > + IPU3_OUTPUT_MAX_WIDTH); > + fmt->format.height = clamp(fmt->format.height, > + IPU3_OUTPUT_MIN_HEIGHT, > + IPU3_OUTPUT_MAX_HEIGHT); > + } else { > + fmt->format.width = clamp(fmt->format.width, > + IPU3_INPUT_MIN_WIDTH, > + IPU3_INPUT_MAX_WIDTH); > + fmt->format.height = clamp(fmt->format.height, > + IPU3_INPUT_MIN_HEIGHT, > + IPU3_INPUT_MAX_HEIGHT); > + } > + > + *mf = fmt->format; > + > + return 0; > +} > + > +/ media_entity_operations / > + > +static int ipu3_link_setup(struct media_entity *entity, > + const struct media_pad *local, > + const struct media_pad *remote, u32 flags) > +{ > + struct ipu3_mem2mem2_device *m2m2 = > + container_of(entity, struct ipu3_mem2mem2_device, subdev.entity); > + u32 pad = local->index; > + > + WARN_ON(pad >= m2m2->num_nodes); > + > + m2m2->nodes[pad].enabled = !!(flags & MEDIA_LNK_FL_ENABLED); > + > + return 0; > +} > + > +/ vb2_ops / > + > +/* Transfer buffer ownership to me */ > +static void ipu3_vb2_buf_queue(struct vb2_buffer *vb) > +{ > + struct ipu3_mem2mem2_device *m2m2 = vb2_get_drv_priv(vb->vb2_queue); > + struct imgu_device *imgu = > + container_of(m2m2, struct imgu_device, mem2mem2); > + struct imgu_video_device *node = > + container_of(vb->vb2_queue, struct imgu_video_device, vbq); > + struct ipu3_mem2mem2_buffer *b = > + container_of(vb, struct ipu3_mem2mem2_buffer, vbb
Re: [PATCH 00/12] Intel IPU3 ImgU patchset
On 05/06/17 22:39, Yong Zhi wrote: > This patchset adds support for the Intel IPU3 (Image Processing Unit) > ImgU which is essentially a modern memory-to-memory ISP. It implements > raw Bayer to YUV image format conversion as well as a large number of > other pixel processing algorithms for improving the image quality. > > Meta data formats are defined for image statistics (3A, i.e. automatic > white balance, exposure and focus, histogram and local area contrast > enhancement) as well as for the pixel processing algorithm parameters. > The documentation for these formats is currently not included in the > patchset but will be added in a future version of this set. > > The algorithm parameters need to be considered specific to a given frame > and typically a large number of these parameters change on frame to frame > basis. Additionally, the parameters are highly structured (and not a flat > space of independent configuration primitives). They also reflect the > data structures used by the firmware and the hardware. On top of that, > the algorithms require highly specialized user space to make meaningful > use of them. For these reasons it has been chosen video buffers to pass > the parameters to the device. > > On individual patches: > > The heart of ImgU is the CSS, or Camera Subsystem, which contains the > image processors and HW accelerators. > > The 3A statistics and other firmware parameter computation related > functions are implemented in patch 8. > > All h/w programming related code can be found in patch 9. > > To access DDR via ImgU's own memory space, IPU3 is also equipped with > its own MMU unit, the driver is implemented in patch 2. > > Patch 3 uses above driver for DMA mapping operation. > > Patch 5-10 are basically IPU3 CSS specific implementations: > > 6 and 7 provide some utility functions and manage IPU3 fw download and > install. > > Patch 9 and 10 are of the same file, the latter implements interface > functions for access fw & hw capabilities defined in patch 8. > > Patch 12 uses Kconfig and Makefile created by IPU3 cio2 patch set, > the code path, however is updated to drivers/media/pci/intel/ipu3. > The path change will be reflected in next revision of the cio2 patch as well. I need to see the v4l2-compliance output for the various video devices that are created. Please compile directly from the https://git.linuxtv.org/v4l-utils.git/ repository to be sure you use the latest code. Just run 'v4l2-compliance -d /dev/videoX'. When you post v2 I'd like to see the output of that utility in the cover email. If the utility reports fails and you aren't clear what's going on, then just mail me (with a CC to Sakari). It hasn't been used much (if at all) for video devices streaming metadata, so you may run into issues with that. Regards, Hans > > Tuukka Toivonen (1): > intel-ipu3: mmu: implement driver > > Yong Zhi (11): > videodev2.h, v4l2-ioctl: add IPU3 meta buffer format > intel-ipu3: Add DMA API implementation > intel-ipu3: Add user space ABI definitions > intel-ipu3: css: tables > intel-ipu3: css: imgu dma buff pool > intel-ipu3: css: firmware management > intel-ipu3: params: compute and program ccs > intel-ipu3: css hardware setup > intel-ipu3: css pipeline > intel-ipu3: Add imgu v4l2 driver > intel-ipu3: imgu top level pci device > > drivers/media/pci/intel/ipu3/Kconfig | 32 + > drivers/media/pci/intel/ipu3/Makefile |8 + > drivers/media/pci/intel/ipu3/ipu3-abi.h| 1572 > drivers/media/pci/intel/ipu3/ipu3-css-fw.c | 272 + > drivers/media/pci/intel/ipu3/ipu3-css-fw.h | 215 + > drivers/media/pci/intel/ipu3/ipu3-css-params.c | 3113 > drivers/media/pci/intel/ipu3/ipu3-css-params.h | 105 + > drivers/media/pci/intel/ipu3/ipu3-css-pool.c | 129 + > drivers/media/pci/intel/ipu3/ipu3-css-pool.h | 53 + > drivers/media/pci/intel/ipu3/ipu3-css.c| 2242 ++ > drivers/media/pci/intel/ipu3/ipu3-css.h| 236 + > drivers/media/pci/intel/ipu3/ipu3-dmamap.c | 408 + > drivers/media/pci/intel/ipu3/ipu3-dmamap.h | 20 + > drivers/media/pci/intel/ipu3/ipu3-mmu.c| 423 ++ > drivers/media/pci/intel/ipu3/ipu3-mmu.h| 73 + > drivers/media/pci/intel/ipu3/ipu3-tables.c | 9621 > > drivers/media/pci/intel/ipu3/ipu3-tables.h | 82 + > drivers/media/pci/intel/ipu3/ipu3-v4l2.c | 723 ++ > drivers/media/pci/intel/ipu3/ipu3.c| 712 ++ > drivers/media/pci/intel/ipu3/ipu3.h| 184 + > drivers/media/v4l2-core/v4l2-ioctl.c |4 + > include/uapi/linux/intel-ipu3.h| 2182 ++ > include/uapi/linux/videodev2.h |6 + > 23 files changed, 22415 insertions(+) > create mode 100644 drivers/media/pci/intel/ipu3/ipu3-abi.h > create mode 100644 drivers/media/pci/intel/ipu3/ipu3-css-fw.c > create mode 100644 drivers/media/pci/intel/ipu3/ipu3-css
[GIT PULL for v4.12-rc5] media fixes
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v4.12-2 For some bug fixes: - Don't fail build if atomisp has warnings; - Some CEC Kconfig changes to allow it to be used by DRM without media dependencies; - A race fix at RC initialization code; - A driver fix at rainshadow-cec. IMHO, the one that affects most people in this series is a build fix: if you try to build the Kernel with W=1 or gcc7 and all[yes|mod]config, build will fail due to -Werror at atomisp makefiles. The following changes since commit 5ed02dbb497422bf225783f46e6eadd237d23d6b: Linux 4.12-rc3 (2017-05-28 17:20:53 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v4.12-2 for you to fetch changes up to 963761a0b2e85663ee4a5630f72930885a06598a: [media] rc-core: race condition during ir_raw_event_register() (2017-06-04 15:25:38 -0300) media fixes for v4.12-rc4 Colin Ian King (1): [media] rainshadow-cec: ensure exit_loop is intialized Hans Verkuil (3): [media] cec: select CEC_CORE instead of depend on it [media] cec: rename MEDIA_CEC_NOTIFIER to CEC_NOTIFIER [media] cec: drop MEDIA_CEC_DEBUG Mauro Carvalho Chehab (1): [media] atomisp: don't treat warnings as errors Sean Young (1): [media] rc-core: race condition during ir_raw_event_register() drivers/media/Kconfig | 6 ++ drivers/media/Makefile | 4 ++-- drivers/media/cec/Kconfig | 14 -- drivers/media/cec/Makefile | 2 +- drivers/media/cec/cec-adap.c| 2 +- drivers/media/cec/cec-core.c| 8 drivers/media/i2c/Kconfig | 9 ++--- drivers/media/platform/Kconfig | 10 ++ drivers/media/platform/vivid/Kconfig| 3 ++- drivers/media/rc/rc-ir-raw.c| 13 - drivers/media/usb/pulse8-cec/Kconfig| 3 ++- drivers/media/usb/rainshadow-cec/Kconfig| 3 ++- drivers/media/usb/rainshadow-cec/rainshadow-cec.c | 2 +- drivers/staging/media/atomisp/i2c/Makefile | 2 -- drivers/staging/media/atomisp/i2c/imx/Makefile | 2 -- drivers/staging/media/atomisp/i2c/ov5693/Makefile | 2 -- drivers/staging/media/atomisp/pci/atomisp2/Makefile | 2 +- include/media/cec-notifier.h| 2 +- include/media/cec.h | 4 ++-- 19 files changed, 45 insertions(+), 48 deletions(-)
Re: Support for RGB/YUV 10, 12 BPC(bits per color/component) image data formats in kernel
On 06/06/17 08:35, Ajay kumar wrote: > Hi Sakari, > > On Sat, Jun 3, 2017 at 1:48 PM, Sakari Ailus wrote: >> Hi Ajay, >> >> On Fri, Jun 02, 2017 at 06:38:53PM +0530, Ajay kumar wrote: >>> Hi all, >>> >>> I have tried searching for RGB/YUV 10, 12 BPC formats in videodev2.h, >>> media-bus-format.h and drm_fourcc.h >>> I could only find RGB 10BPC support in drm_fourcc.h. >>> I guess not much support is present for formats with (BPC > 8) in the >>> kernel. >> >> What's "BPC"? Most YUV and RGB formats have only 8 bits per sample. More >> format definitions may be added if there's a driver that makes use of them. > BPC : Bits Per Color/Component > In my project, we have an image capture device which can capture 10 or > 12 bits for each of R, G, B colors, i.e: > R[0:9] G[0:9] B[0:9] and > R[0:11] G[0:11] B[0:11] > > I want to define macros for the above formats in videodev2.h. > But, I am not getting the logic behind the naming convention used to > define v4l2_fourcc macros. > ex: > V4L2_PIX_FMT_ARGB32 v4l2_fourcc('A', 'R', '2', '4'); > > How did they choose the characters 'A', 'R', '2', '4' in the above case? > > I want to know the logic/naming convention behind that, so that I can create > new v4l2_fourcc defines for 10, 12 BPC formats and use in my driver. A = has Alpha channel, R = uses RGB, 24 = uses 24 bits for the RGB part. So for 10 bit you'd get AR30 and for 12 bit per component it's AR36. If there is no alpha channel, then use XR30/XR36. In practice there isn't much of a system behind these formats. Regards, Hans > > Thanks, > Ajay Kumar >>> >>> Are there any plans to add fourcc defines for such formats? >>> Also, I wanted to how to define fourcc code for those formats? >> >> -- >> Regards, >> >> Sakari Ailus >> e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
Re: [PATCH 01/12] videodev2.h, v4l2-ioctl: add IPU3 meta buffer format
On Tue, Jun 6, 2017 at 5:04 PM, Hans Verkuil wrote: > On 06/06/17 09:25, Sakari Ailus wrote: >> Hi Tomasz, >> >> On Tue, Jun 06, 2017 at 01:30:41PM +0900, Tomasz Figa wrote: >>> Uhm, +Laurent. Sorry for the noise. >>> >>> On Tue, Jun 6, 2017 at 1:30 PM, Tomasz Figa wrote: Hi Yong, On Tue, Jun 6, 2017 at 5:39 AM, Yong Zhi wrote: > Add the IPU3 specific processing parameter format > V4L2_META_FMT_IPU3_PARAMS and metadata formats > for 3A and other statistics: Please see my comments inline. > > V4L2_META_FMT_IPU3_PARAMS > V4L2_META_FMT_IPU3_STAT_3A > V4L2_META_FMT_IPU3_STAT_DVS > V4L2_META_FMT_IPU3_STAT_LACE > > Signed-off-by: Yong Zhi > --- > drivers/media/v4l2-core/v4l2-ioctl.c | 4 > include/uapi/linux/videodev2.h | 6 ++ > 2 files changed, 10 insertions(+) [snip] > +/* Vendor specific - used for IPU3 camera sub-system */ > +#define V4L2_META_FMT_IPU3_PARAMS v4l2_fourcc('i', 'p', '3', 'p') > /* IPU3 params */ > +#define V4L2_META_FMT_IPU3_STAT_3A v4l2_fourcc('i', 'p', '3', 's') > /* IPU3 3A statistics */ > +#define V4L2_META_FMT_IPU3_STAT_DVSv4l2_fourcc('i', 'p', '3', 'd') > /* IPU3 DVS statistics */ > +#define V4L2_META_FMT_IPU3_STAT_LACE v4l2_fourcc('i', 'p', '3', 'l') > /* IPU3 LACE statistics */ We had some discussion about this with Laurent and if I remember correctly, the conclusion was that it might make sense to define one FourCC for a vendor specific format, ('v', 'n', 'd', 'r') for example, and then have a V4L2-specific enum within the v4l2_pix_format(_mplane) struct that specifies the exact vendor data type. It seems saner than assigning a new FourCC whenever a new hardware revision comes out, especially given that FourCCs tend to be used outside of the V4L2 world as well and being kind of (de facto) standardized (with existing exceptions, unfortunately). > > I can't remember that discussion I think that was just a casual chat between Lauren, me and few more guys. > although I've had other discussions with > Laurent related to this on how to handle formats that have many variations > on a theme. > > But speaking for this specific case I see no reason to do something special. > There are only four new formats, which seems perfectly reasonable to me. > > I don't see the advantage of adding another layer of pixel formats. You still > need to define something for this, one way or the other. And this way doesn't > require API changes. > >> If we have four video nodes with different vendor specific formats, how does >> the user tell the formats apart? I presume the user space could use the >> entity names for instance, but that would essentially make them device >> specific. > > Well, they are. There really is no way to avoid that. > >> I'm not sure if there would be any harm from that in practice though: the >> user will need to find the device nodes somehow and that will be very likely >> based on e.g. entity names. >> >> How should the documentation be arranged? The documentation is arranged by >> fourccs currently; we'd probably need a separate section for vendor specific >> formats. I think the device name should be listed there as well. > > There already is a separate section for metadata formats: > > https://hverkuil.home.xs4all.nl/spec/uapi/v4l/meta-formats.html > > But perhaps that page should be organized by device. And with some more > detailed information on how to find the video node (i.e. entity names). > >> I'd like to have perhaps Hans's comment on that as well. >> >> I don't really see a drawback in the current way of doing this either; we >> may get a few new fourcc codes occasionally of which I'm not really worried >> about. --- I'd rather ask why should there be an exception on how vendor >> specific formats are defined. And if we do make an exception, then how do >> you decide which one is and isn't vendor specific? There are raw bayer >> format variants that are just raw bayer data but the pixels are arranged >> differently (e.g. CIO2 driver). >> > > For these unique formats I am happy with the way it is today. The problem > is more with 'parameterized' formats. A simple example would be the 4:2:2 > interleaved YUV formats where you have four different ways of ordering the > Y, U and V components. Right now we have four defines for that, but things > get out of hand quickly when you have multiple parameters like that. > > Laurent and myself discussed that with NVidia some time ago, without > reaching a clear conclusion. Mostly because we couldn't come up with an > API that is simple enough. Actually I back off a bit. Still, it looks like we have a metadata interface already, but it's limited to CAPTURE: https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/dev-meta.html#metadata Maybe we can also have V4L2_BUF_TYPE_META_OUTPUT and solve the problem of priva
Re: [PATCH 02/12] intel-ipu3: mmu: implement driver
Hi Yong, Tuukka, +CC IOMMU ML and Joerg. (Technically you should resend this patch including them.) On Tue, Jun 6, 2017 at 5:39 AM, Yong Zhi wrote: > From: Tuukka Toivonen > > This driver translates Intel IPU3 internal virtual > address to physical address. Please see my comments inline. > > Signed-off-by: Yong Zhi Tuukka needs to sign off this patch as well (above the sender's sign-off to maintain the patch flow order) to consent his approval for the submission. > --- > drivers/media/pci/intel/ipu3/Kconfig| 11 + > drivers/media/pci/intel/ipu3/Makefile | 1 + > drivers/media/pci/intel/ipu3/ipu3-mmu.c | 423 > > drivers/media/pci/intel/ipu3/ipu3-mmu.h | 73 ++ > 4 files changed, 508 insertions(+) > create mode 100644 drivers/media/pci/intel/ipu3/ipu3-mmu.c > create mode 100644 drivers/media/pci/intel/ipu3/ipu3-mmu.h > > diff --git a/drivers/media/pci/intel/ipu3/Kconfig > b/drivers/media/pci/intel/ipu3/Kconfig > index 2a895d6..ab2edcb 100644 > --- a/drivers/media/pci/intel/ipu3/Kconfig > +++ b/drivers/media/pci/intel/ipu3/Kconfig > @@ -15,3 +15,14 @@ config VIDEO_IPU3_CIO2 > Say Y or M here if you have a Skylake/Kaby Lake SoC with MIPI CSI-2 > connected camera. > The module will be called ipu3-cio2. > + > +config INTEL_IPU3_MMU > + tristate "Intel ipu3-mmu driver" > + select IOMMU_API > + select IOMMU_IOVA > + ---help--- > + For IPU3, this option enables its MMU driver to translate its > internal > + virtual address to 39 bits wide physical address for 64GBytes space > access. > + > + Say Y here if you have Skylake/Kaby Lake SoC with IPU3. > + Say N if un-sure. Is the MMU optional? I.e. can you still use the IPU3 without the MMU driver? If no, then it doesn't make sense to flood the user with meaningless choice and the driver could simply be selected by other IPU3 drivers. And the other way around, is the IPU3 MMU driver useful for anything else than IPU3? If no (but yes for the above), then it should depend on some other IPU3 drivers being enabled, as otherwise it would just confuse the user. > diff --git a/drivers/media/pci/intel/ipu3/Makefile > b/drivers/media/pci/intel/ipu3/Makefile > index 20186e3..2b669df 100644 > --- a/drivers/media/pci/intel/ipu3/Makefile > +++ b/drivers/media/pci/intel/ipu3/Makefile > @@ -1 +1,2 @@ > obj-$(CONFIG_VIDEO_IPU3_CIO2) += ipu3-cio2.o > +obj-$(CONFIG_INTEL_IPU3_MMU) += ipu3-mmu.o > diff --git a/drivers/media/pci/intel/ipu3/ipu3-mmu.c > b/drivers/media/pci/intel/ipu3/ipu3-mmu.c > new file mode 100644 > index 000..a9fb116 > --- /dev/null > +++ b/drivers/media/pci/intel/ipu3/ipu3-mmu.c > @@ -0,0 +1,423 @@ > +/* > + * Copyright (c) 2017 Intel Corporation. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License version > + * 2 as published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + */ > + > +#include > +#include > +#include > + > +#include "ipu3-mmu.h" > + > +/** > + * ipu3_mmu_tlb_invalidate - invalidate translation look-aside buffer > + * @addr: base address to access REG_TLB_INVALIDATE > + * > + * This function must be called when MMU has power > + */ > +static void ipu3_mmu_tlb_invalidate(void __iomem *addr) Passing a void* argument is kind of shaky. It would make much more sense to instead pass a const struct ipu3_mmu *pointer to this function. > +{ > + writel(TLB_INVALIDATE, addr + REG_TLB_INVALIDATE); > +} > + > +static int ipu3_mmu_add_device(struct device *dev) > +{ > + struct ipu3_mmu *mmu = dev_get_drvdata(dev); The drvdata of dev belongs only to its driver. Other drivers shouldn't expect anything in particular to be there. > + > + /* mapping domain must be prepared */ > + if (!mmu->domain) > + return 0; > + > + return iommu_attach_device(mmu->domain, dev); I believe this should be handled by the IOMMU core. Maybe your iommu_group somehow ends up without a default_domain? > +} > + > +/** > + * ipu3_mmu_alloc_page_table - get page to fill entries with dummy defaults > + * @d: mapping domain to be worked on > + * @l1: True for L1 page table, false for L2 page table. > + * > + * Index of L1 page table points to L2 tbl > + * > + * Return: Pointer to allocated page table > + * or NULL on failure. > + */ > +static uint32_t *ipu3_mmu_alloc_page_table(struct ipu3_mmu_domain *d, bool > l1) > +{ > + uint32_t *pt = (uint32_t *)__get_free_page(GFP_KERNEL); Style: I believe u32 is preferred in the kernel. > + int i; > + > + if (!pt) > + return NULL; > + > + for (i = 0; i < IPU3_MMU_L1PT_PTES; i+
[PATCH 1/1] v4l2: fwnode: Convert stm32-dcmi driver to V4L2 fwnode
The stm32-dcmi driver was still using V4L2 OF, convert it to V4L2 fwnode. Signed-off-by: Sakari Ailus --- I'll squash this to patch "v4l: Switch from V4L2 OF not V4L2 fwnode API" in the pull request I'll send in a moment. drivers/media/platform/Kconfig| 1 + drivers/media/platform/stm32/stm32-dcmi.c | 13 +++-- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 8d50ec8..a4b7cef 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -121,6 +121,7 @@ config VIDEO_STM32_DCMI depends on VIDEO_V4L2 && OF && HAS_DMA depends on ARCH_STM32 || COMPILE_TEST select VIDEOBUF2_DMA_CONTIG + select V4L2_FWNODE ---help--- This module makes the STM32 Digital Camera Memory Interface (DCMI) available as a v4l2 device. diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c index 348f025..83d32a5 100644 --- a/drivers/media/platform/stm32/stm32-dcmi.c +++ b/drivers/media/platform/stm32/stm32-dcmi.c @@ -21,6 +21,7 @@ #include #include #include +#include #include #include #include @@ -29,9 +30,9 @@ #include #include #include +#include #include #include -#include #include #define DRV_NAME "stm32-dcmi" @@ -139,7 +140,7 @@ struct stm32_dcmi { struct mutexlock; struct vb2_queuequeue; - struct v4l2_of_bus_parallel bus; + struct v4l2_fwnode_bus_parallel bus; struct completion complete; struct clk *mclk; enum state state; @@ -1143,8 +1144,8 @@ static int dcmi_graph_parse(struct stm32_dcmi *dcmi, struct device_node *node) /* Remote node to connect */ dcmi->entity.node = remote; - dcmi->entity.asd.match_type = V4L2_ASYNC_MATCH_OF; - dcmi->entity.asd.match.of.node = remote; + dcmi->entity.asd.match_type = V4L2_ASYNC_MATCH_FWNODE; + dcmi->entity.asd.match.fwnode.fwnode = of_fwnode_handle(remote); return 0; } } @@ -1190,7 +1191,7 @@ static int dcmi_probe(struct platform_device *pdev) { struct device_node *np = pdev->dev.of_node; const struct of_device_id *match = NULL; - struct v4l2_of_endpoint ep; + struct v4l2_fwnode_endpoint ep; struct stm32_dcmi *dcmi; struct vb2_queue *q; struct dma_chan *chan; @@ -1222,7 +1223,7 @@ static int dcmi_probe(struct platform_device *pdev) return -ENODEV; } - ret = v4l2_of_parse_endpoint(np, &ep); + ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(np), &ep); if (ret) { dev_err(&pdev->dev, "Could not parse the endpoint\n"); of_node_put(np); -- 2.1.4
[GIT PULL v3 FOR v4.13] V4L2 fwnode support
Hi Mauro, This pull request introduces the V4L2 fwnode framework which has equivalent functionality to V4L2 OF framework. The V4L2 OF framework users are converted to use the V4L2 fwnode framework and the redundant V4L2 OF framework is removed. since v2: - Rebase (no conflicts) and convert the recently merged stm32-dcmi driver to V4L2 fwnode. since v1: - Merge patch to the series ("v4l: flash led class: Use fwnode_handle instead of device_node in init"): https://www.mail-archive.com/linux-media@vger.kernel.org/msg113193.html> Please pull. The following changes since commit 1656df35d689ac6a93d7503725d9e62ce50c7f38: [media] em28xx: fix spelling mistake: "missdetected" -> "misdetected" (2017-06-06 08:13:41 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git v4l2-acpi for you to fetch changes up to e7e234464d82dc2d3f60a9cb4ccf45c8f965dd51: v4l: Remove V4L2 OF framework in favour of V4L2 fwnode framework (2017-06-06 15:08:34 +0300) Sakari Ailus (7): v4l: fwnode: Support generic fwnode for parsing standardised properties v4l: async: Add fwnode match support v4l: flash led class: Use fwnode_handle instead of device_node in init v4l: Switch from V4L2 OF not V4L2 fwnode API docs-rst: media: Sort topic list alphabetically docs-rst: media: Switch documentation to V4L2 fwnode API v4l: Remove V4L2 OF framework in favour of V4L2 fwnode framework Documentation/media/kapi/v4l2-core.rst | 20 +- Documentation/media/kapi/v4l2-fwnode.rst | 3 + Documentation/media/kapi/v4l2-of.rst | 3 - drivers/leds/leds-aat1290.c| 5 +- drivers/leds/leds-max77693.c | 5 +- drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/adv7604.c| 7 +- drivers/media/i2c/mt9v032.c| 7 +- drivers/media/i2c/ov2659.c | 8 +- drivers/media/i2c/ov5645.c | 7 +- drivers/media/i2c/ov5647.c | 7 +- drivers/media/i2c/s5c73m3/s5c73m3-core.c | 7 +- drivers/media/i2c/s5k5baf.c| 6 +- drivers/media/i2c/smiapp/Kconfig | 1 + drivers/media/i2c/smiapp/smiapp-core.c | 29 ++- drivers/media/i2c/tc358743.c | 11 +- drivers/media/i2c/tvp514x.c| 6 +- drivers/media/i2c/tvp5150.c| 7 +- drivers/media/i2c/tvp7002.c| 6 +- drivers/media/platform/Kconfig | 4 + drivers/media/platform/am437x/Kconfig | 1 + drivers/media/platform/am437x/am437x-vpfe.c| 15 +- drivers/media/platform/atmel/Kconfig | 2 + drivers/media/platform/atmel/atmel-isc.c | 13 +- drivers/media/platform/atmel/atmel-isi.c | 11 +- drivers/media/platform/exynos4-is/Kconfig | 2 + drivers/media/platform/exynos4-is/media-dev.c | 13 +- drivers/media/platform/exynos4-is/mipi-csis.c | 6 +- drivers/media/platform/omap3isp/isp.c | 49 ++-- drivers/media/platform/pxa_camera.c| 11 +- drivers/media/platform/rcar-vin/Kconfig| 1 + drivers/media/platform/rcar-vin/rcar-core.c| 19 +- drivers/media/platform/soc_camera/soc_camera.c | 7 +- drivers/media/platform/stm32/stm32-dcmi.c | 13 +- drivers/media/platform/ti-vpe/cal.c| 15 +- drivers/media/platform/xilinx/Kconfig | 1 + drivers/media/platform/xilinx/xilinx-vipp.c| 63 +++-- drivers/media/v4l2-core/Kconfig| 3 + drivers/media/v4l2-core/Makefile | 4 +- drivers/media/v4l2-core/v4l2-async.c | 21 +- drivers/media/v4l2-core/v4l2-flash-led-class.c | 12 +- drivers/media/v4l2-core/v4l2-fwnode.c | 345 + drivers/media/v4l2-core/v4l2-of.c | 327 --- include/media/v4l2-async.h | 8 +- include/media/v4l2-flash-led-class.h | 6 +- include/media/{v4l2-of.h => v4l2-fwnode.h} | 96 +++ include/media/v4l2-subdev.h| 5 +- 47 files changed, 643 insertions(+), 586 deletions(-) create mode 100644 Documentation/media/kapi/v4l2-fwnode.rst delete mode 100644 Documentation/media/kapi/v4l2-of.rst create mode 100644 drivers/media/v4l2-core/v4l2-fwnode.c delete mode 100644 drivers/media/v4l2-core/v4l2-of.c rename include/media/{v4l2-of.h => v4l2-fwnode.h} (50%) -- Regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
Re: [GIT PULL FOR v4.13] Add qualcomm venus codec
Em Mon, 22 May 2017 09:37:48 +0200 Hans Verkuil escreveu: > Hi Mauro, > > This pull requests adds support for the Qualcomm venus codec driver. What's the status of the firmware blobs required by this driver? Are they already at linux-firmware? Regards, Mauro Thanks, Mauro
Re: [PATCH v3 5/7] docs-rst: media: Sort topic list alphabetically
Em Mon, 10 Apr 2017 16:02:54 +0300 Sakari Ailus escreveu: > Bring some order by alphabetically ordering the list of topics. > > Signed-off-by: Sakari Ailus > --- > Documentation/media/kapi/v4l2-core.rst | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/Documentation/media/kapi/v4l2-core.rst > b/Documentation/media/kapi/v4l2-core.rst > index d8f6c46..2fbf532 100644 > --- a/Documentation/media/kapi/v4l2-core.rst > +++ b/Documentation/media/kapi/v4l2-core.rst > @@ -4,23 +4,23 @@ Video4Linux devices > .. toctree:: > :maxdepth: 1 > > -v4l2-intro NACK. The order of the documentation should match what makes sense for the user that will be reading the docs, and *not* an alphabetical order. I didn't check what order you did, but for sure the introduction should come first, and then the stuff that all drivers use, like v4l2-dev, v4l2-device and v4l2-fh. Then, other stuff that it is part of the framework but are used only by a subset of the drivers. That's said, it probably makes sense to use multiple toctrees here, and add some description before each of them, in order to better organize its contents. Something similar to what it was done with Documentation/admin-guide/index.rst I'll rebase patch 6/7 to not depend on this one. Regards Thanks, Mauro
[GIT PULL] [PATCH] saa7164: Bug - Double fetch PCIe access condition
Mauro, A single commit. https://github.com/stoth68000/media-tree/commit/354dd3924a2e43806774953de536257548b5002c This pull request addresses the concern raised by Pengfei Wang via https://bugzilla.kernel.org/show_bug.cgi?id=195559 I've tested this patch with two different SAA7164 based cards in both analog and digital television modes for US and Europe, no regressions were found. $ git diff --stat master drivers/media/pci/saa7164/saa7164-bus.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) Thanks! - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com
Re: [RFC PATCH v3 08/11] [media] vimc: Optimize frame generation through the pipe
On 2017-06-02 11:58 PM, Helen Koike wrote: Add a parameter called vsen_tpg, if true then vimc will work as before: frames will be generated in the sensor nodes then propagated through the pipe and processed by each node until a capture node is reached. If vsen_tpg is false, then the frame is not generated by the sensor, but directly from the capture node, thus saving intermediate memory buffers and process time, allowing a higher frame rate. Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: Optimize frame generation through the pipe - This is a new patch in the series Changes in v2: None --- drivers/media/platform/vimc/vimc-capture.c | 178 + drivers/media/platform/vimc/vimc-common.h | 2 + drivers/media/platform/vimc/vimc-sensor.c | 30 - 3 files changed, 156 insertions(+), 54 deletions(-) diff --git a/drivers/media/platform/vimc/vimc-capture.c b/drivers/media/platform/vimc/vimc-capture.c index e943267..b5da0ea 100644 --- a/drivers/media/platform/vimc/vimc-capture.c +++ b/drivers/media/platform/vimc/vimc-capture.c @@ -15,7 +15,10 @@ * */ +#include +#include #include +#include #include #include @@ -38,6 +41,8 @@ struct vimc_cap_device { struct mutex lock; u32 sequence; struct media_pipeline pipe; + struct tpg_data tpg; + struct task_struct *kthread_cap; }; static const struct v4l2_pix_format fmt_default = { @@ -246,6 +251,91 @@ static void vimc_cap_return_all_buffers(struct vimc_cap_device *vcap, spin_unlock(&vcap->qlock); } +static void vimc_cap_process_frame(struct vimc_ent_device *ved, + struct media_pad *sink, const void *frame) +{ + struct vimc_cap_device *vcap = container_of(ved, struct vimc_cap_device, + ved); + struct vimc_cap_buffer *vimc_buf; + void *vbuf; + + spin_lock(&vcap->qlock); + + /* Get the first entry of the list */ + vimc_buf = list_first_entry_or_null(&vcap->buf_list, + typeof(*vimc_buf), list); + if (!vimc_buf) { + spin_unlock(&vcap->qlock); + return; + } + + /* Remove this entry from the list */ + list_del(&vimc_buf->list); + + spin_unlock(&vcap->qlock); + + /* Fill the buffer */ + vimc_buf->vb2.vb2_buf.timestamp = ktime_get_ns(); + vimc_buf->vb2.sequence = vcap->sequence++; + vimc_buf->vb2.field = vcap->format.field; + + vbuf = vb2_plane_vaddr(&vimc_buf->vb2.vb2_buf, 0); + + if (sink) + memcpy(vbuf, frame, vcap->format.sizeimage); + else + tpg_fill_plane_buffer(&vcap->tpg, V4L2_STD_PAL, 0, vbuf); + + /* Set it as ready */ + vb2_set_plane_payload(&vimc_buf->vb2.vb2_buf, 0, + vcap->format.sizeimage); + vb2_buffer_done(&vimc_buf->vb2.vb2_buf, VB2_BUF_STATE_DONE); +} + + +static int vimc_cap_tpg_thread(void *data) +{ + struct vimc_cap_device *vcap = data; + + set_freezable(); + set_current_state(TASK_UNINTERRUPTIBLE); + + for (;;) { + try_to_freeze(); + if (kthread_should_stop()) + break; + + vimc_cap_process_frame(&vcap->ved, NULL, NULL); + + /* 60 frames per second */ + schedule_timeout(HZ/60); + } + + return 0; +} + +static void vimc_cap_tpg_s_format(struct vimc_cap_device *vcap) +{ + const struct vimc_pix_map *vpix = + vimc_pix_map_by_pixelformat(vcap->format.pixelformat); + + tpg_reset_source(&vcap->tpg, vcap->format.width, vcap->format.height, +vcap->format.field); + tpg_s_bytesperline(&vcap->tpg, 0, vcap->format.width * vpix->bpp); + tpg_s_buf_height(&vcap->tpg, vcap->format.height); + tpg_s_fourcc(&vcap->tpg, vpix->pixelformat); + /* +* TODO: check why the tpg_s_field need this third argument if +* it is already receiving the field +*/ + tpg_s_field(&vcap->tpg, vcap->format.field, + vcap->format.field == V4L2_FIELD_ALTERNATE); + tpg_s_colorspace(&vcap->tpg, vcap->format.colorspace); + tpg_s_ycbcr_enc(&vcap->tpg, vcap->format.ycbcr_enc); + tpg_s_quantization(&vcap->tpg, vcap->format.quantization); + tpg_s_xfer_func(&vcap->tpg, vcap->format.xfer_func); +} + static int vimc_cap_start_streaming(struct vb2_queue *vq, unsigned int count) { struct vimc_cap_device *vcap = vb2_get_drv_priv(vq); @@ -256,20 +346,43 @@ static int vimc_cap_start_streaming(struct vb2_queue *vq, unsigned int count) /* Start the media pipeline */ ret = media_pipeline_start(entity, &vcap->pipe); - if (ret) { - vimc_cap_return_all_buffers(vcap, VB2_BUF_STATE_QUEUED); - return ret; - } + if (ret) +
Re: HauppaugeTV-quadHD DVB-T mpeg risc op code errors
On Fri, Apr 21, 2017 at 7:57 AM, Steven Toth wrote: >> Just a follow up on this. I had a bit more time to dig deeper into this >> today. >> >> Enabling debug output for the cx23885 driver *fixes* the issue. >> >> I added this to my kernel command line: cx23885.debug=8 > > The driver's been around a very long time and is very stable with > almost anything anyone has every added, or I originally added during > the early development. That being said. this sounds like the quad > is producing some kind of race condition, or the PLX bridge is in > someway not as transparent as everyone would like. I happen to have tip installed on a dev box, so I thought I'd install a quad-hd and test for the issues you'd mentioned. I do not see any of the issues you are describing, regardless of whether I tested with w_scan, tzap, dvbtraffic. No unusual module options used, everything 'default'. Everything looks fine to me, no fault found, Ubuntu 16.04 Kernel 4.12-rc1, 64bit. -- Steven Toth - Kernel Labs http://www.kernellabs.com
[PATCH] [media] sir_ir: annotate hardware config module parameters
This module was merged after commit 5a8fc6a3cebb ("Annotate hardware config module parameters in drivers/media/"), so add add the missing hardware annotations. Signed-off-by: Sean Young --- drivers/media/rc/sir_ir.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/rc/sir_ir.c b/drivers/media/rc/sir_ir.c index 5ee3a23..f8738e5 100644 --- a/drivers/media/rc/sir_ir.c +++ b/drivers/media/rc/sir_ir.c @@ -400,10 +400,10 @@ MODULE_DESCRIPTION("Infrared receiver driver for SIR type serial ports"); MODULE_AUTHOR("Milan Pikula"); MODULE_LICENSE("GPL"); -module_param(io, int, 0444); +module_param_hw(io, int, 0444); MODULE_PARM_DESC(io, "I/O address base (0x3f8 or 0x2f8)"); -module_param(irq, int, 0444); +module_param_hw(irq, int, 0444); MODULE_PARM_DESC(irq, "Interrupt (4 or 3)"); module_param(threshold, int, 0444); -- 2.9.4
[PATCH 2/2] [media] coda: copy headers in front of every I-frame
That way we don't have to rely on userspace to inject the headers on IDR requests, and there is always enough information to start decoding at an I-frame. Signed-off-by: Philipp Zabel --- drivers/media/platform/coda/coda-bit.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/media/platform/coda/coda-bit.c b/drivers/media/platform/coda/coda-bit.c index 22e4630f36711..2ec41375a896f 100644 --- a/drivers/media/platform/coda/coda-bit.c +++ b/drivers/media/platform/coda/coda-bit.c @@ -1270,10 +1270,10 @@ static int coda_prepare_encode(struct coda_ctx *ctx) coda_set_gdi_regs(ctx); /* -* Copy headers at the beginning of the first frame for H.264 only. -* In MPEG4 they are already copied by the coda. +* Copy headers in front of the first frame and forced I frames for +* H.264 only. In MPEG4 they are already copied by the CODA. */ - if (src_buf->sequence == 0) { + if (src_buf->sequence == 0 || force_ipicture) { pic_stream_buffer_addr = vb2_dma_contig_plane_dma_addr(&dst_buf->vb2_buf, 0) + ctx->vpu_header_size[0] + @@ -1386,7 +1386,8 @@ static void coda_finish_encode(struct coda_ctx *ctx) wr_ptr = coda_read(dev, CODA_REG_BIT_WR_PTR(ctx->reg_idx)); /* Calculate bytesused field */ - if (dst_buf->sequence == 0) { + if (dst_buf->sequence == 0 || + src_buf->flags & V4L2_BUF_FLAG_KEYFRAME) { vb2_set_plane_payload(&dst_buf->vb2_buf, 0, wr_ptr - start_ptr + ctx->vpu_header_size[0] + ctx->vpu_header_size[1] + -- 2.11.0
[PATCH 1/2] [media] coda: implement forced key frames
Implement the V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME control to force IDR frames. This is useful to implement VFU (Video Fast Update) on RTP transmissions. We already force an IDR frame at the beginning of each GOP to work around a firmware bug on i.MX27, use the same mechanism to service IDR requests from userspace. Signed-off-by: Philipp Zabel --- drivers/media/platform/coda/coda-bit.c| 12 drivers/media/platform/coda/coda-common.c | 3 +++ drivers/media/platform/coda/coda.h| 1 + 3 files changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/media/platform/coda/coda-bit.c b/drivers/media/platform/coda/coda-bit.c index 403214e00e954..22e4630f36711 100644 --- a/drivers/media/platform/coda/coda-bit.c +++ b/drivers/media/platform/coda/coda-bit.c @@ -1247,12 +1247,18 @@ static int coda_prepare_encode(struct coda_ctx *ctx) dst_buf->sequence = ctx->osequence; ctx->osequence++; + force_ipicture = ctx->params.force_ipicture; + if (force_ipicture) + ctx->params.force_ipicture = false; + else if ((src_buf->sequence % ctx->params.gop_size) == 0) + force_ipicture = 1; + /* * Workaround coda firmware BUG that only marks the first * frame as IDR. This is a problem for some decoders that can't * recover when a frame is lost. */ - if (src_buf->sequence % ctx->params.gop_size) { + if (!force_ipicture) { src_buf->flags |= V4L2_BUF_FLAG_PFRAME; src_buf->flags &= ~V4L2_BUF_FLAG_KEYFRAME; } else { @@ -1291,8 +1297,7 @@ static int coda_prepare_encode(struct coda_ctx *ctx) pic_stream_buffer_size = q_data_dst->sizeimage; } - if (src_buf->flags & V4L2_BUF_FLAG_KEYFRAME) { - force_ipicture = 1; + if (force_ipicture) { switch (dst_fourcc) { case V4L2_PIX_FMT_H264: quant_param = ctx->params.h264_intra_qp; @@ -1309,7 +1314,6 @@ static int coda_prepare_encode(struct coda_ctx *ctx) break; } } else { - force_ipicture = 0; switch (dst_fourcc) { case V4L2_PIX_FMT_H264: quant_param = ctx->params.h264_inter_qp; diff --git a/drivers/media/platform/coda/coda-common.c b/drivers/media/platform/coda/coda-common.c index d523e990d5093..f3fe4adf21a7e 100644 --- a/drivers/media/platform/coda/coda-common.c +++ b/drivers/media/platform/coda/coda-common.c @@ -1680,6 +1680,9 @@ static int coda_s_ctrl(struct v4l2_ctrl *ctrl) case V4L2_CID_MPEG_VIDEO_CYCLIC_INTRA_REFRESH_MB: ctx->params.intra_refresh = ctrl->val; break; + case V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME: + ctx->params.force_ipicture = true; + break; case V4L2_CID_JPEG_COMPRESSION_QUALITY: coda_set_jpeg_compression_quality(ctx, ctrl->val); break; diff --git a/drivers/media/platform/coda/coda.h b/drivers/media/platform/coda/coda.h index 20222befb9b2f..dccb105a1a384 100644 --- a/drivers/media/platform/coda/coda.h +++ b/drivers/media/platform/coda/coda.h @@ -135,6 +135,7 @@ struct coda_params { u32 vbv_size; u32 slice_max_bits; u32 slice_max_mb; + boolforce_ipicture; }; struct coda_buffer_meta { -- 2.11.0
Re: [PATCH RFC 1/2] [media] v4l2: add V4L2_INPUT_TYPE_DEFAULT
Hi All, Just reviving this discussion On 2017-04-07 06:53 AM, Laurent Pinchart wrote: Hi Hans, On Friday 07 Apr 2017 11:46:48 Hans Verkuil wrote: On 04/04/2017 03:22 PM, Sakari Ailus wrote: On Mon, Apr 03, 2017 at 12:11:54PM -0300, Helen Koike wrote: On 2017-03-31 06:57 AM, Mauro Carvalho Chehab wrote: Em Fri, 31 Mar 2017 10:29:04 +0200 Hans Verkuil escreveu: On 30/03/17 18:02, Helen Koike wrote: Add V4L2_INPUT_TYPE_DEFAULT and helpers functions for input ioctls to be used when no inputs are available in the device Signed-off-by: Helen Koike --- drivers/media/v4l2-core/v4l2-ioctl.c | 27 +++ include/media/v4l2-ioctl.h | 26 ++ include/uapi/linux/videodev2.h | 1 + 3 files changed, 54 insertions(+) diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index 0c3f238..ccaf04b 100644 --- a/drivers/media/v4l2-core/v4l2-ioctl.c +++ b/drivers/media/v4l2-core/v4l2-ioctl.c @@ -2573,6 +2573,33 @@ struct mutex *v4l2_ioctl_get_lock(struct video_device *vdev, unsigned cmd) return vdev->lock; } +int v4l2_ioctl_enum_input_default(struct file *file, void *priv, + struct v4l2_input *i) +{ + if (i->index > 0) + return -EINVAL; + + memset(i, 0, sizeof(*i)); + i->type = V4L2_INPUT_TYPE_DEFAULT; + strlcpy(i->name, "Default", sizeof(i->name)); + + return 0; +} +EXPORT_SYMBOL(v4l2_ioctl_enum_input_default); + +int v4l2_ioctl_g_input_default(struct file *file, void *priv, unsigned int *i) +{ + *i = 0; + return 0; +} +EXPORT_SYMBOL(v4l2_ioctl_g_input_default); + +int v4l2_ioctl_s_input_default(struct file *file, void *priv, unsigned int i) +{ + return i ? -EINVAL : 0; +} +EXPORT_SYMBOL(v4l2_ioctl_s_input_default); + /* Common ioctl debug function. This function can be used by external ioctl messages as well as internal V4L ioctl */ void v4l_printk_ioctl(const char *prefix, unsigned int cmd) diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h index 6cd94e5..accc470 100644 --- a/include/media/v4l2-ioctl.h +++ b/include/media/v4l2-ioctl.h @@ -652,6 +652,32 @@ struct video_device; */ struct mutex *v4l2_ioctl_get_lock(struct video_device *vdev, unsigned int cmd); + +/** + * v4l2_ioctl_enum_input_default - v4l2 ioctl helper for VIDIOC_ENUM_INPUT ioctl + * + * Plug this function in vidioc_enum_input field of the struct v4l2_ioctl_ops to + * enumerate a single input as V4L2_INPUT_TYPE_DEFAULT + */ +int v4l2_ioctl_enum_input_default(struct file *file, void *priv, + struct v4l2_input *i); + +/** + * v4l2_ioctl_g_input_default - v4l2 ioctl helper for VIDIOC_G_INPUT ioctl + * + * Plug this function in vidioc_g_input field of the struct v4l2_ioctl_ops + * when using v4l2_ioctl_enum_input_default + */ +int v4l2_ioctl_g_input_default(struct file *file, void *priv, unsigned int *i); + +/** + * v4l2_ioctl_s_input_default - v4l2 ioctl helper for VIDIOC_S_INPUT ioctl + * + * Plug this function in vidioc_s_input field of the struct v4l2_ioctl_ops + * when using v4l2_ioctl_enum_input_default + */ +int v4l2_ioctl_s_input_default(struct file *file, void *priv, unsigned int i); + /* names for fancy debug output */ extern const char *v4l2_field_names[]; extern const char *v4l2_type_names[]; diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index 316be62..c10bbde 100644 --- a/include/uapi/linux/videodev2.h +++ b/include/uapi/linux/videodev2.h @@ -1477,6 +1477,7 @@ struct v4l2_input { }; /* Values for the 'type' field */ +#define V4L2_INPUT_TYPE_DEFAULT0 I don't think we should add a new type here. I second that. Just replied the same thing on a comment from Sakari to patch 2/2. The whole point of this exercise is to allow existing apps to work, and existing apps expect a TYPE_CAMERA. BTW, don't read to much in the term 'CAMERA': it's really a catch all for any video stream, whether it is from a sensor, composite input, HDMI, etc. The description for V4L2_INPUT_TYPE_CAMERA in the spec is hopelessly out of date :-( Yeah, we always used "CAMERA" to mean NOT_TUNER. Rather than creating a new type I would add a new V4L2_IN_CAP_MC capability that indicates that this input is controlled via the media controller. That makes much more sense and it wouldn't potentially break applications. Exactly the same can be done for outputs as well: add V4L2_OUT_CAP_MC and use V4L2_OUTPUT_TYPE_ANALOG as the output type (again, a horrible outdated name and the spec is again out of date). I don't see any sense on distinguishing IN and OUT for MC. I mean: should we ever allow that any driver to have their inputs controlled via V4L2 API, and their outputs controlled via MC (or vice-versa)? I don't think so. Either all device inputs/outputs are controlled via V4L2 or via MC. So, let's call it just V4L2_CAP_MC. Regarding the name: should we use the name stor
Re: [GIT PULL] [PATCH] saa7164: Bug - Double fetch PCIe access condition
Em Tue, 6 Jun 2017 09:19:35 -0400 Steven Toth escreveu: > Mauro, > > A single commit. > > https://github.com/stoth68000/media-tree/commit/354dd3924a2e43806774953de536257548b5002c > > This pull request addresses the concern raised by Pengfei Wang > via > https://bugzilla.kernel.org/show_bug.cgi?id=195559 > > I've tested this patch with two different SAA7164 based cards in both > analog and digital television modes for US and Europe, no regressions > were found. > > $ git diff --stat master > drivers/media/pci/saa7164/saa7164-bus.c | 13 + > 1 file changed, 1 insertion(+), 12 deletions(-) Applied, thanks! Next time, please either send as a patch or use the command: $ git request-pull As otherwise I may miss it, as patchwork won't get it. Regards, Mauro
Re: [PATCH 0/4] [media] davinci: vpif_capture: raw camera support
Hi Kevin, On 02/06/17 23:34, Kevin Hilman wrote: > This series fixes/updates the support for raw camera input to the VPIF. > > Tested on da850-evm boards using the add-on UI board. Tested with > both composite video input (on-board tvp514x) and raw camera input > using the camera board from On-Semi based on the aptina,mt9v032 > sensor[1], as this was the only camera board with the right connector > for the da850-evm UI board. > > Verified that composite video capture is still working well after these > updates. Can you rebase this patch series against the latest media master branch? Mauro merged a lot of patches, in particular the one switching v4l2_of_ to v4l2_fwnode_. And that conflicts with patches 2 and 4. Thanks! Hans > > [1] > http://www.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeyMT9V032C12STCH-GEVB > > Kevin Hilman (4): > [media] davinci: vpif_capture: drop compliance hack > [media] davinci: vpif_capture: get subdevs from DT when available > [media] davinci: vpif_capture: cleanup raw camera support > [media] davinci: vpif: adaptions for DT support > > drivers/media/platform/davinci/vpif.c | 49 +- > drivers/media/platform/davinci/vpif_capture.c | 224 > +++--- > drivers/media/platform/davinci/vpif_display.c | 5 + > include/media/davinci/vpif_types.h| 9 +- > 4 files changed, 263 insertions(+), 24 deletions(-) >
[GIT PULL FOR v4.13] Various fixes/improvements
The following changes since commit 6fb05e0dd32e566facb96ea61a48c7488daa5ac3: [media] saa7164: fix double fetch PCIe access condition (2017-06-06 16:55:50 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.13c for you to fetch changes up to 44cdbd59e84ad2562b760455ac24c7114672ca8f: tc358743: Add support for platforms without IRQ line (2017-06-06 22:31:15 +0200) Arvind Yadav (1): tc358743: Handle return value of clk_prepare_enable Dave Stevenson (3): tc358743: Add enum_mbus_code tc358743: Setup default mbus_fmt before registering tc358743: Add support for platforms without IRQ line Hans Verkuil (1): cec: improve debug messages Hugues Fruchet (1): atmel-isi: code cleanup Sakari Ailus (2): v4l2-ctrls.c: Implement unlocked variant of v4l2_ctrl_handler_setup() v4l2-ctrls: Correctly destroy mutex in v4l2_ctrl_handler_free() drivers/media/cec/cec-adap.c | 28 drivers/media/i2c/tc358743.c | 65 +++-- drivers/media/platform/atmel/atmel-isi.c | 24 ++-- drivers/media/v4l2-core/v4l2-ctrls.c | 24 +--- include/media/v4l2-ctrls.h | 13 + 5 files changed, 123 insertions(+), 31 deletions(-)
Re: [PATCH v3 5/7] docs-rst: media: Sort topic list alphabetically
Hi Mauro, Mauro Carvalho Chehab wrote: Em Mon, 10 Apr 2017 16:02:54 +0300 Sakari Ailus escreveu: Bring some order by alphabetically ordering the list of topics. Signed-off-by: Sakari Ailus --- Documentation/media/kapi/v4l2-core.rst | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/Documentation/media/kapi/v4l2-core.rst b/Documentation/media/kapi/v4l2-core.rst index d8f6c46..2fbf532 100644 --- a/Documentation/media/kapi/v4l2-core.rst +++ b/Documentation/media/kapi/v4l2-core.rst @@ -4,23 +4,23 @@ Video4Linux devices .. toctree:: :maxdepth: 1 -v4l2-intro NACK. The order of the documentation should match what makes sense for the user that will be reading the docs, and *not* an alphabetical order. I wrote the patch to address some of the review comments I got over the several versions of the patchset. I have no objections to maintaining the current order. I didn't check what order you did, but for sure the introduction should come first, and then the stuff that all drivers use, like v4l2-dev, v4l2-device and v4l2-fh. Then, other stuff that it is part of the framework but are used only by a subset of the drivers. That's said, it probably makes sense to use multiple toctrees here, and add some description before each of them, in order to better organize its contents. Something similar to what it was done with Documentation/admin-guide/index.rst I'll rebase patch 6/7 to not depend on this one. Thanks! -- Regards, Sakari Ailus sakari.ai...@linux.intel.com
Re: [GIT PULL] [PATCH] saa7164: Bug - Double fetch PCIe access condition
> Applied, thanks! Yay! > > Next time, please either send as a patch or use the command: > > $ git request-pull > > As otherwise I may miss it, as patchwork won't get it. Will do, thank you. -- Steven Toth - Kernel Labs http://www.kernellabs.com
[GIT PULL FOR v4.13] Various RC fixes
Hi Mauro, Some minor fixes that just missed the first pull request, that would be nice to have in v4.13. Thank you Sean The following changes since commit 9e9e6a78143bbb6cb9cffd29ab48d5f32def4e20: [media] Doc*/media/uapi: fix control name (2017-06-06 16:49:46 -0300) are available in the git repository at: git://linuxtv.org/syoung/media_tree.git for-v4.13b for you to fetch changes up to 8e35a2305e02ee0c8cb3bf971acab9fbe708e384: [media] ir-spi: Fix issues with lirc API (2017-06-06 20:55:36 +0100) Anton Blanchard (1): [media] ir-spi: Fix issues with lirc API Johan Hovold (2): [media] mceusb: fix memory leaks in error path [media] mceusb: drop redundant urb reinitialisation Sean Young (1): [media] sir_ir: annotate hardware config module parameters drivers/media/rc/ir-spi.c | 9 ++--- drivers/media/rc/mceusb.c | 5 ++--- drivers/media/rc/sir_ir.c | 4 ++-- 3 files changed, 10 insertions(+), 8 deletions(-)
Re: [PATCH] [media] rc-core: simplify ir_raw_event_store_edge()
On Sun, May 28, 2017 at 05:49:27PM +0100, Sean Young wrote: > There is no need to called ir_raw_event_reset() either after a long > space or on startup. Many rc drivers never do this. > > Signed-off-by: Sean Young > --- > drivers/media/pci/saa7134/saa7134-input.c | 2 +- > drivers/media/rc/gpio-ir-recv.c | 6 +++--- > drivers/media/rc/img-ir/img-ir-raw.c | 4 ++-- > drivers/media/rc/rc-core-priv.h | 1 - > drivers/media/rc/rc-ir-raw.c | 31 > +-- > include/media/rc-core.h | 9 + > 6 files changed, 12 insertions(+), 41 deletions(-) > > diff --git a/drivers/media/pci/saa7134/saa7134-input.c > b/drivers/media/pci/saa7134/saa7134-input.c > index 78849c1..8784bc8 100644 > --- a/drivers/media/pci/saa7134/saa7134-input.c > +++ b/drivers/media/pci/saa7134/saa7134-input.c > @@ -1064,7 +1064,7 @@ static int saa7134_raw_decode_irq(struct saa7134_dev > *dev) > saa_clearb(SAA7134_GPIO_GPMODE3, SAA7134_GPIO_GPRESCAN); > saa_setb(SAA7134_GPIO_GPMODE3, SAA7134_GPIO_GPRESCAN); > space = saa_readl(SAA7134_GPIO_GPSTATUS0 >> 2) & ir->mask_keydown; > - ir_raw_event_store_edge(dev->remote->dev, space ? IR_SPACE : IR_PULSE); > + ir_raw_event_store_edge(dev->remote->dev, !space); > > /* >* Wait 15 ms from the start of the first IR event before processing > diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c > index b4f773b..09889d0 100644 > --- a/drivers/media/rc/gpio-ir-recv.c > +++ b/drivers/media/rc/gpio-ir-recv.c > @@ -77,7 +77,7 @@ static irqreturn_t gpio_ir_recv_irq(int irq, void *dev_id) > struct gpio_rc_dev *gpio_dev = dev_id; > int gval; > int rc = 0; > - enum raw_event_type type = IR_SPACE; > + bool pulse = false; > > gval = gpio_get_value(gpio_dev->gpio_nr); > > @@ -88,9 +88,9 @@ static irqreturn_t gpio_ir_recv_irq(int irq, void *dev_id) > gval = !gval; > > if (gval == 1) > - type = IR_PULSE; > + pulse = true; > > - rc = ir_raw_event_store_edge(gpio_dev->rcdev, type); > + rc = ir_raw_event_store_edge(gpio_dev->rcdev, pulse); > if (rc < 0) > goto err_get_value; > > diff --git a/drivers/media/rc/img-ir/img-ir-raw.c > b/drivers/media/rc/img-ir/img-ir-raw.c > index 8d2f8e2..ddb7fb4 100644 > --- a/drivers/media/rc/img-ir/img-ir-raw.c > +++ b/drivers/media/rc/img-ir/img-ir-raw.c > @@ -40,9 +40,9 @@ static void img_ir_refresh_raw(struct img_ir_priv *priv, > u32 irq_status) > > /* report the edge to the IR raw decoders */ > if (ir_status) /* low */ > - ir_raw_event_store_edge(rc_dev, IR_SPACE); > + ir_raw_event_store_edge(rc_dev, false); > else /* high */ > - ir_raw_event_store_edge(rc_dev, IR_PULSE); > + ir_raw_event_store_edge(rc_dev, true); > ir_raw_event_handle(rc_dev); > } > > diff --git a/drivers/media/rc/rc-core-priv.h b/drivers/media/rc/rc-core-priv.h > index 0455b27..d31ad6a 100644 > --- a/drivers/media/rc/rc-core-priv.h > +++ b/drivers/media/rc/rc-core-priv.h > @@ -41,7 +41,6 @@ struct ir_raw_event_ctrl { > /* fifo for the pulse/space durations */ > DECLARE_KFIFO(kfifo, struct ir_raw_event, MAX_IR_EVENT_SIZE); > ktime_t last_event; /* when last event > occurred */ > - enum raw_event_type last_type; /* last event type */ > struct rc_dev *dev; /* pointer to the > parent rc_dev */ > > /* raw decoder state follows */ > diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c > index 90f66dc..16ef236 100644 > --- a/drivers/media/rc/rc-ir-raw.c > +++ b/drivers/media/rc/rc-ir-raw.c > @@ -88,7 +88,7 @@ EXPORT_SYMBOL_GPL(ir_raw_event_store); > /** > * ir_raw_event_store_edge() - notify raw ir decoders of the start of a > pulse/space > * @dev: the struct rc_dev device descriptor > - * @type:the type of the event that has occurred > + * @pulse: true for pulse, false for space > * > * This routine (which may be called from an interrupt context) is used to > * store the beginning of an ir pulse or space (or the start/end of ir > @@ -96,43 +96,22 @@ EXPORT_SYMBOL_GPL(ir_raw_event_store); > * hardware which does not provide durations directly but only interrupts > * (or similar events) on state change. > */ > -int ir_raw_event_store_edge(struct rc_dev *dev, enum raw_event_type type) > +int ir_raw_event_store_edge(struct rc_dev *dev, bool pulse) > { > ktime_t now; > - s64 delta; /* ns */ > DEFINE_IR_RAW_EVENT(ev); > int rc = 0; > - int delay; > > if (!dev->raw) > return -EINVAL; > > now = ktime_get(); > - delta = ktime_to_ns(ktime_sub(now, dev->raw->last_event)); > - delay = MS_TO_NS
Re: [RFC PATCH] [media] v4l2-subdev: check colorimetry in link validate
Hi Sakari, Thanks for replying On 2017-05-31 03:31 AM, Sakari Ailus wrote: Hi Helen, On Tue, May 30, 2017 at 04:08:08PM -0300, Helen Koike wrote: colorspace, ycbcr_enc, quantization and xfer_func must match across the link. Check if they match in v4l2_subdev_link_validate_default unless they are set as _DEFAULT. Signed-off-by: Helen Koike --- Hi, I think we should validate colorimetry as having different colorimetry across a link doesn't make sense. But I am confused about what to do when they are set to _DEFAULT, what do you think? These fields were added at various points over the course of the past three years or so. User space code that was written before that will certainly not set anything and I'm not sure many drivers care about these fields nor they are relevant for many formats. In practice that means that they are very likely zero in many cases. If they are set to zero then they won't be affected by this patch. Driver changes will probably be necessary for removing the explicit checks for the default value. At least in the drivers/media tree I couldn't find many drivers that implement its own link_validate, there is only platform/omap3isp/ispccdc.c and platform/omap3isp/ispresizer.c that implements a custom value, but from a quick look it doesn't seems that they will be affected. The same applies to checking the colour space: drivers should enforce using the correct colour space before the check can be merged. I might move that to a separate patch. I am not sure if I got what you mean. If driver don't care about colourspace then probably it will be set to zero and won't be affected by this patch, if colourspace is different across the link then the user space must set both ends to the same colourspace. Thanks --- drivers/media/v4l2-core/v4l2-subdev.c | 21 +++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c index da78497..784ae92 100644 --- a/drivers/media/v4l2-core/v4l2-subdev.c +++ b/drivers/media/v4l2-core/v4l2-subdev.c @@ -502,10 +502,27 @@ int v4l2_subdev_link_validate_default(struct v4l2_subdev *sd, struct v4l2_subdev_format *source_fmt, struct v4l2_subdev_format *sink_fmt) { - /* The width, height and code must match. */ + /* The width, height, code and colorspace must match. */ if (source_fmt->format.width != sink_fmt->format.width || source_fmt->format.height != sink_fmt->format.height - || source_fmt->format.code != sink_fmt->format.code) + || source_fmt->format.code != sink_fmt->format.code + || source_fmt->format.colorspace != sink_fmt->format.colorspace) + return -EPIPE; + + /* Colorimetry must match if they are not set to DEFAULT */ + if (source_fmt->format.ycbcr_enc != V4L2_YCBCR_ENC_DEFAULT + && sink_fmt->format.ycbcr_enc != V4L2_YCBCR_ENC_DEFAULT + && source_fmt->format.ycbcr_enc != sink_fmt->format.ycbcr_enc) + return -EPIPE; + + if (source_fmt->format.quantization != V4L2_QUANTIZATION_DEFAULT + && sink_fmt->format.quantization != V4L2_QUANTIZATION_DEFAULT + && source_fmt->format.quantization != sink_fmt->format.quantization) + return -EPIPE; + + if (source_fmt->format.xfer_func != V4L2_XFER_FUNC_DEFAULT + && sink_fmt->format.xfer_func != V4L2_XFER_FUNC_DEFAULT + && source_fmt->format.xfer_func != sink_fmt->format.xfer_func) return -EPIPE; /* The field order must match, or the sink field order must be NONE LN
[PATCH v2 0/4] [media] davinci: vpif_capture: raw camera support
Same as v1, just rebased onto master branch of media tree, as requested by Hans. This series fixes/updates the support for raw camera input to the VPIF. Tested on da850-evm boards using the add-on UI board. Tested with both composite video input (on-board tvp514x) and raw camera input using the camera board from On-Semi based on the aptina,mt9v032 sensor[1], as this was the only camera board with the right connector for the da850-evm UI board. Verified that composite video capture is still working well after these updates. [1] http://www.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeyMT9V032C12STCH-GEVB Kevin Hilman (4): [media] davinci: vpif_capture: drop compliance hack [media] davinci: vpif_capture: get subdevs from DT when available [media] davinci: vpif_capture: cleanup raw camera support [media] davinci: vpif: adaptions for DT support drivers/media/platform/davinci/vpif.c | 49 +- drivers/media/platform/davinci/vpif_capture.c | 223 +++--- drivers/media/platform/davinci/vpif_display.c | 5 + include/media/davinci/vpif_types.h| 9 +- 4 files changed, 262 insertions(+), 24 deletions(-) -- 2.9.3
[PATCH v2 2/4] [media] davinci: vpif_capture: get subdevs from DT when available
Enable getting of subdevs from DT ports and endpoints. The _get_pdata() function was larely inspired by (i.e. stolen from) am437x-vpfe.c Signed-off-by: Kevin Hilman --- drivers/media/platform/davinci/vpif_capture.c | 126 +- drivers/media/platform/davinci/vpif_display.c | 5 + include/media/davinci/vpif_types.h| 9 +- 3 files changed, 134 insertions(+), 6 deletions(-) diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c index fc5c7622660c..b9d927d1e5a8 100644 --- a/drivers/media/platform/davinci/vpif_capture.c +++ b/drivers/media/platform/davinci/vpif_capture.c @@ -22,6 +22,8 @@ #include #include +#include +#include #include "vpif.h" #include "vpif_capture.h" @@ -655,7 +657,7 @@ static int vpif_input_to_subdev( /* loop through the sub device list to get the sub device info */ for (i = 0; i < vpif_cfg->subdev_count; i++) { subdev_info = &vpif_cfg->subdev_info[i]; - if (!strcmp(subdev_info->name, subdev_name)) + if (subdev_info && !strcmp(subdev_info->name, subdev_name)) return i; } return -1; @@ -1308,6 +1310,21 @@ static int vpif_async_bound(struct v4l2_async_notifier *notifier, { int i; + for (i = 0; i < vpif_obj.config->asd_sizes[0]; i++) { + struct v4l2_async_subdev *_asd = vpif_obj.config->asd[i]; + const struct device_node *node = _asd->match.of.node; + + if (node == subdev->of_node) { + vpif_obj.sd[i] = subdev; + vpif_obj.config->chan_config->inputs[i].subdev_name = + (char *)subdev->of_node->full_name; + vpif_dbg(2, debug, +"%s: setting input %d subdev_name = %s\n", +__func__, i, subdev->of_node->full_name); + return 0; + } + } + for (i = 0; i < vpif_obj.config->subdev_count; i++) if (!strcmp(vpif_obj.config->subdev_info[i].name, subdev->name)) { @@ -1403,6 +1420,105 @@ static int vpif_async_complete(struct v4l2_async_notifier *notifier) return vpif_probe_complete(); } +static struct vpif_capture_config * +vpif_capture_get_pdata(struct platform_device *pdev) +{ + struct device_node *endpoint = NULL; + struct v4l2_of_endpoint bus_cfg; + struct vpif_capture_config *pdata; + struct vpif_subdev_info *sdinfo; + struct vpif_capture_chan_config *chan; + unsigned int i; + + /* +* DT boot: OF node from parent device contains +* video ports & endpoints data. +*/ + if (pdev->dev.parent && pdev->dev.parent->of_node) + pdev->dev.of_node = pdev->dev.parent->of_node; + if (!IS_ENABLED(CONFIG_OF) || !pdev->dev.of_node) + return pdev->dev.platform_data; + + pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL); + if (!pdata) + return NULL; + pdata->subdev_info = + devm_kzalloc(&pdev->dev, sizeof(*pdata->subdev_info) * +VPIF_CAPTURE_NUM_CHANNELS, GFP_KERNEL); + + if (!pdata->subdev_info) + return NULL; + + for (i = 0; i < VPIF_CAPTURE_NUM_CHANNELS; i++) { + struct device_node *rem; + unsigned int flags; + int err; + + endpoint = of_graph_get_next_endpoint(pdev->dev.of_node, + endpoint); + if (!endpoint) + break; + + sdinfo = &pdata->subdev_info[i]; + chan = &pdata->chan_config[i]; + chan->inputs = devm_kzalloc(&pdev->dev, + sizeof(*chan->inputs) * + VPIF_CAPTURE_NUM_CHANNELS, + GFP_KERNEL); + + chan->input_count++; + chan->inputs[i].input.type = V4L2_INPUT_TYPE_CAMERA; + chan->inputs[i].input.std = V4L2_STD_ALL; + chan->inputs[i].input.capabilities = V4L2_IN_CAP_STD; + + err = v4l2_of_parse_endpoint(endpoint, &bus_cfg); + if (err) { + dev_err(&pdev->dev, "Could not parse the endpoint\n"); + goto done; + } + dev_dbg(&pdev->dev, "Endpoint %s, bus_width = %d\n", + endpoint->full_name, bus_cfg.bus.parallel.bus_width); + flags = bus_cfg.bus.parallel.flags; + + if (flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH) + chan->vpif_if.hd_pol = 1; + + if (flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH) + chan->vpif_if.vd_pol = 1; + + re
[PATCH v2 1/4] [media] davinci: vpif_capture: drop compliance hack
Capture driver silently overrides pixel format with a hack (according to the comments) to pass v4l2 compliance tests. This isn't needed for normal functionality, and works for composite video and raw camera capture without. In addition, the hack assumes that it only supports raw capture with a single format (SBGGR8) which isn't true. VPIF can also capture 10- and 12-bit raw formats as well. Forthcoming patches will enable VPIF input with raw-camera support and has been tested with 10-bit format from the aptina,mt9v032 sensor. Any compliance failures should be fixed with a real fix. Signed-off-by: Kevin Hilman --- drivers/media/platform/davinci/vpif_capture.c | 15 --- 1 file changed, 15 deletions(-) diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c index 128e92d1dd5a..fc5c7622660c 100644 --- a/drivers/media/platform/davinci/vpif_capture.c +++ b/drivers/media/platform/davinci/vpif_capture.c @@ -936,21 +936,6 @@ static int vpif_try_fmt_vid_cap(struct file *file, void *priv, struct channel_obj *ch = video_get_drvdata(vdev); struct v4l2_pix_format *pixfmt = &fmt->fmt.pix; struct common_obj *common = &(ch->common[VPIF_VIDEO_INDEX]); - struct vpif_params *vpif_params = &ch->vpifparams; - - /* -* to supress v4l-compliance warnings silently correct -* the pixelformat -*/ - if (vpif_params->iface.if_type == VPIF_IF_RAW_BAYER) { - if (pixfmt->pixelformat != V4L2_PIX_FMT_SBGGR8) - pixfmt->pixelformat = V4L2_PIX_FMT_SBGGR8; - } else { - if (pixfmt->pixelformat != V4L2_PIX_FMT_NV16) - pixfmt->pixelformat = V4L2_PIX_FMT_NV16; - } - - common->fmt.fmt.pix.pixelformat = pixfmt->pixelformat; vpif_update_std_info(ch); -- 2.9.3
[PATCH v2 3/4] [media] davinci: vpif_capture: cleanup raw camera support
The current driver has a handful of hard-coded assumptions based on its primary use for capture of video signals. Cleanup those assumptions, and also query the subdev for format information and use that if available. Tested with 10-bit raw bayer input (SGRBG10) using the aptina,mt9v032 sensor, and also tested that composite video input still works from ti,tvp514x decoder. Both tests done on the da850-evm board with the add-on UI board. NOTE: Will need further testing for other sensors with different bus formats. Signed-off-by: Kevin Hilman --- drivers/media/platform/davinci/vpif_capture.c | 82 ++- 1 file changed, 80 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c index b9d927d1e5a8..67624dbf1272 100644 --- a/drivers/media/platform/davinci/vpif_capture.c +++ b/drivers/media/platform/davinci/vpif_capture.c @@ -24,6 +24,9 @@ #include #include #include +#include + +#include #include "vpif.h" #include "vpif_capture.h" @@ -387,7 +390,8 @@ static irqreturn_t vpif_channel_isr(int irq, void *dev_id) common = &ch->common[i]; /* skip If streaming is not started in this channel */ /* Check the field format */ - if (1 == ch->vpifparams.std_info.frm_fmt) { + if (1 == ch->vpifparams.std_info.frm_fmt || + common->fmt.fmt.pix.field == V4L2_FIELD_NONE) { /* Progressive mode */ spin_lock(&common->irqlock); if (list_empty(&common->dma_queue)) { @@ -468,9 +472,38 @@ static int vpif_update_std_info(struct channel_obj *ch) struct vpif_channel_config_params *std_info = &vpifparams->std_info; struct video_obj *vid_ch = &ch->video; int index; + struct v4l2_pix_format *pixfmt = &common->fmt.fmt.pix; vpif_dbg(2, debug, "vpif_update_std_info\n"); + /* +* if called after try_fmt or g_fmt, there will already be a size +* so use that by default. +*/ + if (pixfmt->width && pixfmt->height) { + if (pixfmt->field == V4L2_FIELD_ANY || + pixfmt->field == V4L2_FIELD_NONE) + pixfmt->field = V4L2_FIELD_NONE; + + vpifparams->iface.if_type = VPIF_IF_BT656; + if (pixfmt->pixelformat == V4L2_PIX_FMT_SGRBG10 || + pixfmt->pixelformat == V4L2_PIX_FMT_SBGGR8) + vpifparams->iface.if_type = VPIF_IF_RAW_BAYER; + + if (pixfmt->pixelformat == V4L2_PIX_FMT_SGRBG10) + vpifparams->params.data_sz = 1; /* 10 bits/pixel. */ + + /* +* For raw formats from camera sensors, we don't need +* the std_info from table lookup, so nothing else to do here. +*/ + if (vpifparams->iface.if_type == VPIF_IF_RAW_BAYER) { + memset(std_info, 0, sizeof(struct vpif_channel_config_params)); + vpifparams->std_info.capture_format = 1; /* CCD/raw mode */ + return 0; + } + } + for (index = 0; index < vpif_ch_params_count; index++) { config = &vpif_ch_params[index]; if (config->hd_sd == 0) { @@ -939,6 +972,7 @@ static int vpif_try_fmt_vid_cap(struct file *file, void *priv, struct v4l2_pix_format *pixfmt = &fmt->fmt.pix; struct common_obj *common = &(ch->common[VPIF_VIDEO_INDEX]); + common->fmt = *fmt; vpif_update_std_info(ch); pixfmt->field = common->fmt.fmt.pix.field; @@ -947,8 +981,17 @@ static int vpif_try_fmt_vid_cap(struct file *file, void *priv, pixfmt->width = common->fmt.fmt.pix.width; pixfmt->height = common->fmt.fmt.pix.height; pixfmt->sizeimage = pixfmt->bytesperline * pixfmt->height * 2; + if (pixfmt->pixelformat == V4L2_PIX_FMT_SGRBG10) { + pixfmt->bytesperline = common->fmt.fmt.pix.width * 2; + pixfmt->sizeimage = pixfmt->bytesperline * pixfmt->height; + } pixfmt->priv = 0; + dev_dbg(vpif_dev, "%s: %d x %d; pitch=%d pixelformat=0x%08x, field=%d, size=%d\n", __func__, + pixfmt->width, pixfmt->height, + pixfmt->bytesperline, pixfmt->pixelformat, + pixfmt->field, pixfmt->sizeimage); + return 0; } @@ -965,13 +1008,47 @@ static int vpif_g_fmt_vid_cap(struct file *file, void *priv, struct video_device *vdev = video_devdata(file); struct channel_obj *ch = video_get_drvdata(vdev); struct common_obj *common = &ch->common[VPIF_VIDEO_INDEX]; + struct v4l2_pix_format *pix_fmt = &fmt->fmt.pix; + struct v4l2_subdev_format format = { + .which = V4L2_SUBDEV_FORMAT_ACTIVE, + }; + struct v4l2_mbus_framefmt *mbus_fm
[PATCH v2 4/4] [media] davinci: vpif: adaptions for DT support
The davinci VPIF is a single hardware block, but the existing driver is broken up into a common library (vpif.c), output (vpif_display.c) and intput (vpif_capture.c). When migrating to DT, to better model the hardware, and because registers, interrupts, etc. are all common,it was decided to have a single VPIF hardware node[1]. Because davinci uses legacy, non-DT boot on several SoCs still, the platform_drivers need to remain. But they are also needed in DT boot. Since there are no DT nodes for the display/capture parts in DT boot (there is a single node for the parent/common device) we need to create platform_devices somewhere to instansiate the platform_drivers. When VPIF display/capture are needed for a DT boot, the VPIF node will have endpoints defined for its subdevs. Therefore, vpif_probe() checks for the presence of endpoints, and if detected manually creates the platform_devices for the display and capture platform_drivers. [1] Documentation/devicetree/bindings/media/ti,da850-vpif.txt Signed-off-by: Kevin Hilman --- drivers/media/platform/davinci/vpif.c | 49 ++- 1 file changed, 48 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c index 1b02a6363f77..502917abcb13 100644 --- a/drivers/media/platform/davinci/vpif.c +++ b/drivers/media/platform/davinci/vpif.c @@ -26,6 +26,7 @@ #include #include #include +#include #include "vpif.h" @@ -423,7 +424,9 @@ EXPORT_SYMBOL(vpif_channel_getfid); static int vpif_probe(struct platform_device *pdev) { - static struct resource *res; + static struct resource *res, *res_irq; + struct platform_device *pdev_capture, *pdev_display; + struct device_node *endpoint = NULL; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); vpif_base = devm_ioremap_resource(&pdev->dev, res); @@ -435,6 +438,50 @@ static int vpif_probe(struct platform_device *pdev) spin_lock_init(&vpif_lock); dev_info(&pdev->dev, "vpif probe success\n"); + + /* +* If VPIF Node has endpoints, assume "new" DT support, +* where capture and display drivers don't have DT nodes +* so their devices need to be registered manually here +* for their legacy platform_drivers to work. +*/ + endpoint = of_graph_get_next_endpoint(pdev->dev.of_node, + endpoint); + if (!endpoint) + return 0; + + /* +* For DT platforms, manually create platform_devices for +* capture/display drivers. +*/ + res_irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0); + if (!res_irq) { + dev_warn(&pdev->dev, "Missing IRQ resource.\n"); + return -EINVAL; + } + + pdev_capture = devm_kzalloc(&pdev->dev, sizeof(*pdev_capture), + GFP_KERNEL); + pdev_capture->name = "vpif_capture"; + pdev_capture->id = -1; + pdev_capture->resource = res_irq; + pdev_capture->num_resources = 1; + pdev_capture->dev.dma_mask = pdev->dev.dma_mask; + pdev_capture->dev.coherent_dma_mask = pdev->dev.coherent_dma_mask; + pdev_capture->dev.parent = &pdev->dev; + platform_device_register(pdev_capture); + + pdev_display = devm_kzalloc(&pdev->dev, sizeof(*pdev_display), + GFP_KERNEL); + pdev_display->name = "vpif_display"; + pdev_display->id = -1; + pdev_display->resource = res_irq; + pdev_display->num_resources = 1; + pdev_display->dev.dma_mask = pdev->dev.dma_mask; + pdev_display->dev.coherent_dma_mask = pdev->dev.coherent_dma_mask; + pdev_display->dev.parent = &pdev->dev; + platform_device_register(pdev_display); + return 0; } -- 2.9.3
Re: [PATCH 0/4] [media] davinci: vpif_capture: raw camera support
On Tue, Jun 6, 2017 at 1:34 PM, Hans Verkuil wrote: > Hi Kevin, > > On 02/06/17 23:34, Kevin Hilman wrote: >> This series fixes/updates the support for raw camera input to the VPIF. >> >> Tested on da850-evm boards using the add-on UI board. Tested with >> both composite video input (on-board tvp514x) and raw camera input >> using the camera board from On-Semi based on the aptina,mt9v032 >> sensor[1], as this was the only camera board with the right connector >> for the da850-evm UI board. >> >> Verified that composite video capture is still working well after these >> updates. > > Can you rebase this patch series against the latest media master branch? > > Mauro merged a lot of patches, in particular the one switching v4l2_of_ to > v4l2_fwnode_. And that conflicts with patches 2 and 4. Rebased and resent as v2. Kevin
Re: [PATCH] [media] imx: switch from V4L2 OF to V4L2 fwnode API
Hi Philipp, v4l2_fwnode patch has been merged to mediatree, so I've applied this to my imx-media-staging-md-v16 branch, thanks for the patch! However before I can submit version 8 of the patchset, the video-mux driver also needs conversion. Can you submit a version 8 of your video-mux patchset (your last was v7) containing the switch to v4l2-fwnode, and I will incorporate into the imx-media v8 patchset. Thanks! Steve On 05/04/2017 06:37 AM, Philipp Zabel wrote: Switch from the v4l2_of_ APIs to the v4l2_fwnode_ APIs so this driver can work if the patch "v4l: Switch from V4L2 OF not V4L2 fwnode API" is applied before it. Tested against https://git.linuxtv.org/sailus/media_tree.git/log/?h=v4l2-acpi-merge Signed-off-by: Philipp Zabel --- drivers/staging/media/imx/imx-media-capture.c | 2 +- drivers/staging/media/imx/imx-media-csi.c | 10 +- drivers/staging/media/imx/imx-media-dev.c | 19 ++- drivers/staging/media/imx/imx-media-fim.c | 1 - drivers/staging/media/imx/imx-media-of.c | 6 -- drivers/staging/media/imx/imx-media.h | 4 ++-- drivers/staging/media/imx/imx6-mipi-csi2.c| 9 + 7 files changed, 27 insertions(+), 24 deletions(-) diff --git a/drivers/staging/media/imx/imx-media-capture.c b/drivers/staging/media/imx/imx-media-capture.c index 8b28dbc21566c..ddab4c249da25 100644 --- a/drivers/staging/media/imx/imx-media-capture.c +++ b/drivers/staging/media/imx/imx-media-capture.c @@ -21,8 +21,8 @@ #include #include #include +#include #include -#include #include #include #include diff --git a/drivers/staging/media/imx/imx-media-csi.c b/drivers/staging/media/imx/imx-media-csi.c index 447c597111852..fdf90dc7d212e 100644 --- a/drivers/staging/media/imx/imx-media-csi.c +++ b/drivers/staging/media/imx/imx-media-csi.c @@ -17,8 +17,8 @@ #include #include #include +#include #include -#include #include #include #include @@ -307,7 +307,7 @@ static void csi_idmac_unsetup_vb2_buf(struct csi_priv *priv, static int csi_idmac_setup_channel(struct csi_priv *priv) { struct imx_media_video_dev *vdev = priv->vdev; - struct v4l2_of_endpoint *sensor_ep; + struct v4l2_fwnode_endpoint *sensor_ep; struct v4l2_mbus_framefmt *infmt; struct ipu_image image; u32 passthrough_bits; @@ -557,7 +557,7 @@ static int csi_setup(struct csi_priv *priv) { struct v4l2_mbus_framefmt *infmt, *outfmt; struct v4l2_mbus_config sensor_mbus_cfg; - struct v4l2_of_endpoint *sensor_ep; + struct v4l2_fwnode_endpoint *sensor_ep; struct v4l2_mbus_framefmt if_fmt; const struct csi_skip_desc *skip; @@ -957,7 +957,7 @@ static int csi_link_validate(struct v4l2_subdev *sd, { struct csi_priv *priv = v4l2_get_subdevdata(sd); const struct imx_media_pixfmt *incc; - struct v4l2_of_endpoint *sensor_ep; + struct v4l2_fwnode_endpoint *sensor_ep; struct imx_media_subdev *sensor; bool is_csi2; int ret; @@ -1066,7 +1066,7 @@ static void csi_try_crop(struct csi_priv *priv, struct v4l2_mbus_framefmt *infmt, struct imx_media_subdev *sensor) { - struct v4l2_of_endpoint *sensor_ep; + struct v4l2_fwnode_endpoint *sensor_ep; sensor_ep = &sensor->sensor_ep; diff --git a/drivers/staging/media/imx/imx-media-dev.c b/drivers/staging/media/imx/imx-media-dev.c index d149d2f222f10..488c4d24783d9 100644 --- a/drivers/staging/media/imx/imx-media-dev.c +++ b/drivers/staging/media/imx/imx-media-dev.c @@ -40,14 +40,15 @@ imx_media_find_async_subdev(struct imx_media_dev *imxmd, struct device_node *np, const char *devname) { + struct fwnode_handle *fwnode = np ? of_fwnode_handle(np) : NULL; struct imx_media_subdev *imxsd; int i; for (i = 0; i < imxmd->subdev_notifier.num_subdevs; i++) { imxsd = &imxmd->subdev[i]; switch (imxsd->asd.match_type) { - case V4L2_ASYNC_MATCH_OF: - if (np && imxsd->asd.match.of.node == np) + case V4L2_ASYNC_MATCH_FWNODE: + if (fwnode && imxsd->asd.match.fwnode.fwnode == fwnode) return imxsd; break; case V4L2_ASYNC_MATCH_DEVNAME: @@ -65,8 +66,8 @@ imx_media_find_async_subdev(struct imx_media_dev *imxmd, /* * Adds a subdev to the async subdev list. If np is non-NULL, adds - * the async as a V4L2_ASYNC_MATCH_OF match type, otherwise as a - * V4L2_ASYNC_MATCH_DEVNAME match type using the dev_name of the + * the async as a V4L2_ASYNC_MATCH_FWNODE match type, otherwise as + * a V4L2_ASYNC_MATCH_DEVNAME match type using the dev_name of the * given platform_device. This is called during driver load when * forming the async subdev list. */ @@ -101,8
[PATCH v2 2/3] [media] doc-rst: add IPU3 raw10 bayer pixel format definitions
The formats added by this patch are: V4L2_PIX_FMT_IPU3_SBGGR10 V4L2_PIX_FMT_IPU3_SGBRG10 V4L2_PIX_FMT_IPU3_SGRBG10 V4L2_PIX_FMT_IPU3_SRGGB10 Signed-off-by: Yong Zhi --- Documentation/media/uapi/v4l/pixfmt-rgb.rst| 1 + .../media/uapi/v4l/pixfmt-srggb10-ipu3.rst | 62 ++ 2 files changed, 63 insertions(+) create mode 100644 Documentation/media/uapi/v4l/pixfmt-srggb10-ipu3.rst diff --git a/Documentation/media/uapi/v4l/pixfmt-rgb.rst b/Documentation/media/uapi/v4l/pixfmt-rgb.rst index b0f3513..6900d5c 100644 --- a/Documentation/media/uapi/v4l/pixfmt-rgb.rst +++ b/Documentation/media/uapi/v4l/pixfmt-rgb.rst @@ -16,5 +16,6 @@ RGB Formats pixfmt-srggb10p pixfmt-srggb10alaw8 pixfmt-srggb10dpcm8 +pixfmt-srggb10-ipu3 pixfmt-srggb12 pixfmt-srggb16 diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb10-ipu3.rst b/Documentation/media/uapi/v4l/pixfmt-srggb10-ipu3.rst new file mode 100644 index 000..618e24a --- /dev/null +++ b/Documentation/media/uapi/v4l/pixfmt-srggb10-ipu3.rst @@ -0,0 +1,62 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _V4L2_PIX_FMT_IPU3_SBGGR10: +.. _V4L2_PIX_FMT_IPU3_SGBRG10: +.. _V4L2_PIX_FMT_IPU3_SGRBG10: +.. _V4L2_PIX_FMT_IPU3_SRGGB10: + +** +V4L2_PIX_FMT_IPU3_SBGGR10 ('ip3b'), V4L2_PIX_FMT_IPU3_SGBRG10 ('ip3g'), V4L2_PIX_FMT_IPU3_SGRBG10 ('ip3G'), V4L2_PIX_FMT_IPU3_SRGGB10 ('ip3r') +** + +10-bit Bayer formats + +Description +=== + +These four pixel formats are used by Intel IPU3 driver, they are raw +sRGB / Bayer formats with 10 bits per sample with every 25 pixels packed +to 32 bytes leaving 6 most significant bits padding in the last byte. +The format is little endian. + +In other respects this format is similar to :ref:`V4L2-PIX-FMT-SRGGB10`. + +**Byte Order.** +Each cell is one byte. + +.. raw:: latex + +\newline\newline\begin{adjustbox}{width=\columnwidth} + +.. tabularcolumns:: |p{1.3cm}|p{1.0cm}|p{10.9cm}|p{10.9cm}|p{10.9cm}|p{1.0cm}| + +.. flat-table:: + +* - start + 0: + - B\ :sub:`00low` + - G\ :sub:`01low` \ (bits 7--2) B\ :sub:`00high`\ (bits 1--0) + - B\ :sub:`02low` \ (bits 7--4) G\ :sub:`01high`\ (bits 3--0) + - G\ :sub:`03low` \ (bits 7--6) B\ :sub:`02high`\ (bits 5--0) + - G\ :sub:`03high` +* - start + 5: + - G\ :sub:`10low` + - R\ :sub:`11low` \ (bits 7--2) G\ :sub:`10high`\ (bits 1--0) + - G\ :sub:`12low` \ (bits 7--4) R\ :sub:`11high`\ (bits 3--0) + - R\ :sub:`13low` \ (bits 7--6) G\ :sub:`12high`\ (bits 5--0) + - R\ :sub:`13high` +* - start + 10: + - B\ :sub:`20low` + - G\ :sub:`21low` \ (bits 7--2) B\ :sub:`20high`\ (bits 1--0) + - B\ :sub:`22low` \ (bits 7--4) G\ :sub:`21high`\ (bits 3--0) + - G\ :sub:`23low` \ (bits 7--6) B\ :sub:`22high`\ (bits 5--0) + - G\ :sub:`23high` +* - start + 15: + - G\ :sub:`30low` + - R\ :sub:`31low` \ (bits 7--2) G\ :sub:`30high`\ (bits 1--0) + - G\ :sub:`32low` \ (bits 7--4) R\ :sub:`31high`\ (bits 3--0) + - R\ :sub:`33low` \ (bits 7--6) G\ :sub:`32high`\ (bits 5--0) + - R\ :sub:`33high` + +.. raw:: latex + +\end{adjustbox}\newline\newline -- 2.7.4
[PATCH v2 1/3] [media] videodev2.h, v4l2-ioctl: add IPU3 raw10 color format
Add IPU3 specific formats: V4L2_PIX_FMT_IPU3_SBGGR10 V4L2_PIX_FMT_IPU3_SGBRG10 V4L2_PIX_FMT_IPU3_SGRBG10 V4L2_PIX_FMT_IPU3_SRGGB10 Signed-off-by: Yong Zhi --- drivers/media/v4l2-core/v4l2-ioctl.c | 4 include/uapi/linux/videodev2.h | 5 + 2 files changed, 9 insertions(+) diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index e5a2187..fb1387f 100644 --- a/drivers/media/v4l2-core/v4l2-ioctl.c +++ b/drivers/media/v4l2-core/v4l2-ioctl.c @@ -1202,6 +1202,10 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt) case V4L2_PIX_FMT_SGBRG10P: descr = "10-bit Bayer GBGB/RGRG Packed"; break; case V4L2_PIX_FMT_SGRBG10P: descr = "10-bit Bayer GRGR/BGBG Packed"; break; case V4L2_PIX_FMT_SRGGB10P: descr = "10-bit Bayer RGRG/GBGB Packed"; break; + case V4L2_PIX_FMT_IPU3_SBGGR10: descr = "10-bit bayer BGGR IPU3 Packed"; break; + case V4L2_PIX_FMT_IPU3_SGBRG10: descr = "10-bit bayer GBRG IPU3 Packed"; break; + case V4L2_PIX_FMT_IPU3_SGRBG10: descr = "10-bit bayer GRBG IPU3 Packed"; break; + case V4L2_PIX_FMT_IPU3_SRGGB10: descr = "10-bit bayer RGGB IPU3 Packed"; break; case V4L2_PIX_FMT_SBGGR10ALAW8: descr = "8-bit Bayer BGBG/GRGR (A-law)"; break; case V4L2_PIX_FMT_SGBRG10ALAW8: descr = "8-bit Bayer GBGB/RGRG (A-law)"; break; case V4L2_PIX_FMT_SGRBG10ALAW8: descr = "8-bit Bayer GRGR/BGBG (A-law)"; break; diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index 2b8feb8..7bfa6ad 100644 --- a/include/uapi/linux/videodev2.h +++ b/include/uapi/linux/videodev2.h @@ -663,6 +663,11 @@ struct v4l2_pix_format { #define V4L2_PIX_FMT_MT21Cv4l2_fourcc('M', 'T', '2', '1') /* Mediatek compressed block mode */ #define V4L2_PIX_FMT_INZI v4l2_fourcc('I', 'N', 'Z', 'I') /* Intel Planar Greyscale 10-bit and Depth 16-bit */ +#define V4L2_PIX_FMT_IPU3_SBGGR10 v4l2_fourcc('i', 'p', '3', 'b') /* IPU3 packed 10-bit BGGR bayer */ +#define V4L2_PIX_FMT_IPU3_SGBRG10 v4l2_fourcc('i', 'p', '3', 'g') /* IPU3 packed 10-bit GBRG bayer */ +#define V4L2_PIX_FMT_IPU3_SGRBG10 v4l2_fourcc('i', 'p', '3', 'G') /* IPU3 packed 10-bit GRBG bayer */ +#define V4L2_PIX_FMT_IPU3_SRGGB10 v4l2_fourcc('i', 'p', '3', 'r') /* IPU3 packed 10-bit RGGB bayer */ + /* SDR formats - used only for Software Defined Radio devices */ #define V4L2_SDR_FMT_CU8 v4l2_fourcc('C', 'U', '0', '8') /* IQ u8 */ #define V4L2_SDR_FMT_CU16LE v4l2_fourcc('C', 'U', '1', '6') /* IQ u16le */ -- 2.7.4
[PATCH v2 3/3] [media] intel-ipu3: cio2: Add new MIPI-CSI2 driver
This patch adds CIO2 CSI-2 device driver for Intel's IPU3 camera sub-system support. Signed-off-by: Yong Zhi --- drivers/media/pci/Kconfig|2 + drivers/media/pci/Makefile |3 +- drivers/media/pci/intel/Makefile |5 + drivers/media/pci/intel/ipu3/Kconfig | 17 + drivers/media/pci/intel/ipu3/Makefile|1 + drivers/media/pci/intel/ipu3/ipu3-cio2.c | 1788 ++ drivers/media/pci/intel/ipu3/ipu3-cio2.h | 424 +++ 7 files changed, 2239 insertions(+), 1 deletion(-) create mode 100644 drivers/media/pci/intel/Makefile create mode 100644 drivers/media/pci/intel/ipu3/Kconfig create mode 100644 drivers/media/pci/intel/ipu3/Makefile create mode 100644 drivers/media/pci/intel/ipu3/ipu3-cio2.c create mode 100644 drivers/media/pci/intel/ipu3/ipu3-cio2.h diff --git a/drivers/media/pci/Kconfig b/drivers/media/pci/Kconfig index da28e68..5932e22 100644 --- a/drivers/media/pci/Kconfig +++ b/drivers/media/pci/Kconfig @@ -54,5 +54,7 @@ source "drivers/media/pci/smipcie/Kconfig" source "drivers/media/pci/netup_unidvb/Kconfig" endif +source "drivers/media/pci/intel/ipu3/Kconfig" + endif #MEDIA_PCI_SUPPORT endif #PCI diff --git a/drivers/media/pci/Makefile b/drivers/media/pci/Makefile index a7e8af0..d8f9843 100644 --- a/drivers/media/pci/Makefile +++ b/drivers/media/pci/Makefile @@ -13,7 +13,8 @@ obj-y+= ttpci/ \ ddbridge/ \ saa7146/\ smipcie/\ - netup_unidvb/ + netup_unidvb/ \ + intel/ obj-$(CONFIG_VIDEO_IVTV) += ivtv/ obj-$(CONFIG_VIDEO_ZORAN) += zoran/ diff --git a/drivers/media/pci/intel/Makefile b/drivers/media/pci/intel/Makefile new file mode 100644 index 000..745c8b2 --- /dev/null +++ b/drivers/media/pci/intel/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for the IPU3 cio2 and ImGU drivers +# + +obj-y += ipu3/ diff --git a/drivers/media/pci/intel/ipu3/Kconfig b/drivers/media/pci/intel/ipu3/Kconfig new file mode 100644 index 000..2a895d6 --- /dev/null +++ b/drivers/media/pci/intel/ipu3/Kconfig @@ -0,0 +1,17 @@ +config VIDEO_IPU3_CIO2 + tristate "Intel ipu3-cio2 driver" + depends on VIDEO_V4L2 && PCI + depends on MEDIA_CONTROLLER + depends on HAS_DMA + depends on ACPI + select V4L2_FWNODE + select VIDEOBUF2_DMA_SG + + ---help--- + This is the Intel IPU3 CIO2 CSI-2 receiver unit, found in Intel + Skylake and Kaby Lake SoCs and used for capturing images and + video from a camera sensor. + + Say Y or M here if you have a Skylake/Kaby Lake SoC with MIPI CSI-2 + connected camera. + The module will be called ipu3-cio2. diff --git a/drivers/media/pci/intel/ipu3/Makefile b/drivers/media/pci/intel/ipu3/Makefile new file mode 100644 index 000..20186e3 --- /dev/null +++ b/drivers/media/pci/intel/ipu3/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_VIDEO_IPU3_CIO2) += ipu3-cio2.o diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.c b/drivers/media/pci/intel/ipu3/ipu3-cio2.c new file mode 100644 index 000..69c47fc --- /dev/null +++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.c @@ -0,0 +1,1788 @@ +/* + * Copyright (c) 2017 Intel Corporation. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License version + * 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * Based partially on Intel IPU4 driver written by + * Sakari Ailus + * Samu Onkalo + * Jouni Högander + * Jouni Ukkonen + * Antti Laakso + * et al. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "ipu3-cio2.h" + +/* + * These are raw formats used in Intel's third generation of + * Image Processing Unit known as IPU3. + * 10bit raw bayer packed, 32 bytes for every 25 pixels, + * last LSB 6 bits unused. + */ +static const u32 cio2_csi2_fmts[] = { + V4L2_PIX_FMT_IPU3_SRGGB10, + V4L2_PIX_FMT_IPU3_SGBRG10, + V4L2_PIX_FMT_IPU3_SGRBG10, + V4L2_PIX_FMT_IPU3_SBGGR10, +}; + +static inline u32 cio2_bytesperline(const unsigned int width) +{ + /* +* 64 bytes for every 50 pixels, the line length +* in bytes is multiple of 64 (line end alignment). +*/ + return DIV_ROUND_UP(width, 50) * 64; +} + +/ FBPT operations / + +static void cio2_fbpt_exit_dummy(struct cio2_device *cio2) +{ + if (cio2->dummy_lop) { + dma_free_coherent(&cio2->pci_dev->dev, PAGE_SIZE, + cio2->dummy_lop, cio2->
[PATCH v2 0/3] [media] add IPU3 CIO2 CSI2 driver
This patch adds the driver for the CIO2 device found in some the Skylake and Kaby Kake SoCs. The CIO2 consists of four D-PHY receivers. The CIO2 driver exposes V4L2, V4L2 sub-device and Media controller interfaces to the user space. === = history = === version 2: - remove all explicit DMA flush operations - change dma_free_noncoherent() to dma_free_coherent() - remove cio2_hw_mipi_lanes() - replace v4l2_g_ext_ctrls() with v4l2_ctrl_g_ctrl() in cio2_csi2_calc_timing(). - use ffs() to iterate the port_status in cio2_irq() - add static inline file_to_cio2_queue() function - comment dma_wmb(), cio2_rx_timing() and few other places - use ktime_get_ns() for vb2_buf.timestamp in cio2_buffer_done() - use of SET_RUNTIME_PM_OPS() macro for cio2_pm_ops - use BIT() macro for bit difinitions - remove un-used macros such as CIO2_QUEUE_WIDTH() in ipu3-cio2.h - move the MODULE_AUTHOR() to the end of the file - change file path to drivers/media/pci/intel/ipu3 version 1: - Initial submission Yong Zhi (3): [media] videodev2.h, v4l2-ioctl: add IPU3 raw10 color format [media] doc-rst: add IPU3 raw10 bayer pixel format definitions [media] intel-ipu3: cio2: Add new MIPI-CSI2 driver Documentation/media/uapi/v4l/pixfmt-rgb.rst|1 + .../media/uapi/v4l/pixfmt-srggb10-ipu3.rst | 62 + drivers/media/pci/Kconfig |2 + drivers/media/pci/Makefile |3 +- drivers/media/pci/intel/Makefile |5 + drivers/media/pci/intel/ipu3/Kconfig | 17 + drivers/media/pci/intel/ipu3/Makefile |1 + drivers/media/pci/intel/ipu3/ipu3-cio2.c | 1788 drivers/media/pci/intel/ipu3/ipu3-cio2.h | 424 + drivers/media/v4l2-core/v4l2-ioctl.c |4 + include/uapi/linux/videodev2.h |5 + 11 files changed, 2311 insertions(+), 1 deletion(-) create mode 100644 Documentation/media/uapi/v4l/pixfmt-srggb10-ipu3.rst create mode 100644 drivers/media/pci/intel/Makefile create mode 100644 drivers/media/pci/intel/ipu3/Kconfig create mode 100644 drivers/media/pci/intel/ipu3/Makefile create mode 100644 drivers/media/pci/intel/ipu3/ipu3-cio2.c create mode 100644 drivers/media/pci/intel/ipu3/ipu3-cio2.h -- 2.7.4
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Jun 7 05:00:17 CEST 2017 media-tree git hash:6fb05e0dd32e566facb96ea61a48c7488daa5ac3 media_build git hash: 0d8b3274e29b597780719e7ce1b3b460241a5395 v4l-utils git hash: ef074cf5500b7dd62e6eb3527ec47a914c7189ca gcc version:i686-linux-gcc (GCC) 7.1.0 sparse version: v0.5.0-3553-g78b2ea6 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.9.0-164 linux-git-arm-at91: WARNINGS linux-git-arm-davinci: WARNINGS linux-git-arm-multi: WARNINGS linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: WARNINGS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: ERRORS linux-3.6.11-i686: ERRORS linux-3.7.4-i686: ERRORS linux-3.8-i686: ERRORS linux-3.9.2-i686: ERRORS linux-3.10.1-i686: ERRORS linux-3.11.1-i686: ERRORS linux-3.12.67-i686: ERRORS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: ERRORS linux-3.16.7-i686: ERRORS linux-3.17.8-i686: ERRORS linux-3.18.7-i686: ERRORS linux-3.19-i686: ERRORS linux-4.0.9-i686: ERRORS linux-4.1.33-i686: ERRORS linux-4.2.8-i686: ERRORS linux-4.3.6-i686: ERRORS linux-4.4.22-i686: ERRORS linux-4.5.7-i686: ERRORS linux-4.6.7-i686: ERRORS linux-4.7.5-i686: ERRORS linux-4.8-i686: ERRORS linux-4.9.26-i686: ERRORS linux-4.10.14-i686: ERRORS linux-4.11-i686: ERRORS linux-4.12-rc1-i686: OK linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: ERRORS linux-3.6.11-x86_64: ERRORS linux-3.7.4-x86_64: ERRORS linux-3.8-x86_64: ERRORS linux-3.9.2-x86_64: ERRORS linux-3.10.1-x86_64: ERRORS linux-3.11.1-x86_64: ERRORS linux-3.12.67-x86_64: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: ERRORS linux-3.15.2-x86_64: ERRORS linux-3.16.7-x86_64: ERRORS linux-3.17.8-x86_64: ERRORS linux-3.18.7-x86_64: ERRORS linux-3.19-x86_64: ERRORS linux-4.0.9-x86_64: ERRORS linux-4.1.33-x86_64: ERRORS linux-4.2.8-x86_64: ERRORS linux-4.3.6-x86_64: ERRORS linux-4.4.22-x86_64: ERRORS linux-4.5.7-x86_64: ERRORS linux-4.6.7-x86_64: ERRORS linux-4.7.5-x86_64: ERRORS linux-4.8-x86_64: ERRORS linux-4.9.26-x86_64: ERRORS linux-4.10.14-x86_64: ERRORS linux-4.11-x86_64: ERRORS linux-4.12-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
[GIT PULL FOR v4.13] Added max2175 and rcar_drif drivers
The following changes since commit 6fb05e0dd32e566facb96ea61a48c7488daa5ac3: [media] saa7164: fix double fetch PCIe access condition (2017-06-06 16:55:50 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git rcar-drif for you to fetch changes up to 1607773131567986dac183aa30a20ecdba2de77e: media: platform: rcar_drif: Add DRIF support (2017-06-07 08:49:43 +0200) Ramesh Shanmugasundaram (7): media: v4l2-ctrls: Reserve controls for MAX217X dt-bindings: media: Add MAX2175 binding description media: i2c: max2175: Add MAX2175 support media: Add new SDR formats PC16, PC18 & PC20 doc_rst: media: New SDR formats PC16, PC18 & PC20 dt-bindings: media: Add Renesas R-Car DRIF binding media: platform: rcar_drif: Add DRIF support Documentation/devicetree/bindings/media/i2c/max2175.txt | 59 ++ Documentation/devicetree/bindings/media/renesas,drif.txt | 176 ++ Documentation/devicetree/bindings/property-units.txt |1 + Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst | 55 ++ Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst | 55 ++ Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst | 54 ++ Documentation/media/uapi/v4l/sdr-formats.rst |3 + Documentation/media/v4l-drivers/index.rst|1 + Documentation/media/v4l-drivers/max2175.rst | 60 ++ drivers/media/i2c/Kconfig| 12 + drivers/media/i2c/Makefile |2 + drivers/media/i2c/max2175.c | 1448 +++ drivers/media/i2c/max2175.h | 107 drivers/media/platform/Kconfig | 25 + drivers/media/platform/Makefile |1 + drivers/media/platform/rcar_drif.c | 1500 + drivers/media/v4l2-core/v4l2-ioctl.c |3 + include/uapi/linux/max2175.h | 28 + include/uapi/linux/v4l2-controls.h |5 + include/uapi/linux/videodev2.h |3 + 20 files changed, 3598 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/max2175.txt create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst create mode 100644 Documentation/media/v4l-drivers/max2175.rst create mode 100644 drivers/media/i2c/max2175.c create mode 100644 drivers/media/i2c/max2175.h create mode 100644 drivers/media/platform/rcar_drif.c create mode 100644 include/uapi/linux/max2175.h