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: Fri Nov 30 05:00:11 CET 2018 media-tree git hash:708d75fe1c7c6e9abc5381b6fcc32b49830383d0 media_build git hash: 466e4e6f12eeffd6e9f6d91378c9169f7e6b8527 v4l-utils git hash: 767eb8be92cd04917885ddf82235ea539a6c0644 edid-decode git hash: 5eeb151a748788666534d6ea3da07f90400d24c2 gcc version:i686-linux-gcc (GCC) 8.2.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.18.0-2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-arm64: OK linux-git-i686: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK Check COMPILE_TEST: OK linux-3.10.108-i686: OK linux-3.10.108-x86_64: OK linux-3.11.10-i686: OK linux-3.11.10-x86_64: OK linux-3.12.74-i686: OK linux-3.12.74-x86_64: OK linux-3.13.11-i686: OK linux-3.13.11-x86_64: OK linux-3.14.79-i686: OK linux-3.14.79-x86_64: OK linux-3.15.10-i686: OK linux-3.15.10-x86_64: OK linux-3.16.57-i686: OK linux-3.16.57-x86_64: OK linux-3.17.8-i686: OK linux-3.17.8-x86_64: OK linux-3.18.123-i686: OK linux-3.18.123-x86_64: OK linux-3.19.8-i686: ERRORS linux-3.19.8-x86_64: ERRORS linux-4.0.9-i686: ERRORS linux-4.0.9-x86_64: ERRORS linux-4.1.52-i686: OK linux-4.1.52-x86_64: OK linux-4.2.8-i686: OK linux-4.2.8-x86_64: OK linux-4.3.6-i686: OK linux-4.3.6-x86_64: OK linux-4.4.159-i686: OK linux-4.4.159-x86_64: OK linux-4.5.7-i686: OK linux-4.5.7-x86_64: OK linux-4.6.7-i686: OK linux-4.6.7-x86_64: OK linux-4.7.10-i686: OK linux-4.7.10-x86_64: OK linux-4.8.17-i686: OK linux-4.8.17-x86_64: OK linux-4.9.131-i686: OK linux-4.9.131-x86_64: OK linux-4.10.17-i686: OK linux-4.10.17-x86_64: OK linux-4.11.12-i686: OK linux-4.11.12-x86_64: OK linux-4.12.14-i686: OK linux-4.12.14-x86_64: OK linux-4.13.16-i686: OK linux-4.13.16-x86_64: OK linux-4.14.74-i686: OK linux-4.14.74-x86_64: OK linux-4.15.18-i686: OK linux-4.15.18-x86_64: OK linux-4.16.18-i686: OK linux-4.16.18-x86_64: OK linux-4.17.19-i686: OK linux-4.17.19-x86_64: OK linux-4.18.12-i686: OK linux-4.18.12-x86_64: OK linux-4.19.1-i686: OK linux-4.19.1-x86_64: OK linux-4.20-rc1-i686: OK linux-4.20-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
[GIT PULL FOR v4.21] uvcvideo updates
Hi Mauro, The following changes since commit 708d75fe1c7c6e9abc5381b6fcc32b49830383d0: media: dvb-pll: don't re-validate tuner frequencies (2018-11-23 12:27:18 -0500) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git uvc/next for you to fetch changes up to dd3bd1ac29aa9a0f83a55f100e69091c0567a27c: media: uvcvideo: Refactor teardown of uvc on USB disconnect (2018-11-30 04:12:08 +0200) Daniel Axtens (1): media: uvcvideo: Refactor teardown of uvc on USB disconnect Sergey Dorodnicov (2): media: v4l: Add 4bpp packed depth confidence format CNF4 media: uvcvideo: Add support for the CNF4 format Documentation/media/uapi/v4l/depth-formats.rst | 1 + Documentation/media/uapi/v4l/pixfmt-cnf4.rst | 31 + drivers/media/usb/uvc/uvc_driver.c | 18 ++ drivers/media/usb/uvc/uvc_status.c | 12 drivers/media/usb/uvc/uvcvideo.h | 4 drivers/media/v4l2-core/v4l2-ioctl.c | 1 + include/uapi/linux/videodev2.h | 1 + 7 files changed, 60 insertions(+), 8 deletions(-) create mode 100644 Documentation/media/uapi/v4l/pixfmt-cnf4.rst -- Regards, Laurent Pinchart
[GIT PULL FOR v4.21] Xilinx media drivers updates
Hi Mauro, The following changes since commit 708d75fe1c7c6e9abc5381b6fcc32b49830383d0: media: dvb-pll: don't re-validate tuner frequencies (2018-11-23 12:27:18 -0500) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git xilinx/next for you to fetch changes up to 672d25bacfce9b50168b0ab7db872d66ae3aa4a6: media: xilinx: fix typo in formats table (2018-11-30 03:37:24 +0200) Andrea Merello (1): media: xilinx: fix typo in formats table Dhaval Shah (1): media: xilinx: Use SPDX-License-Identifier drivers/media/platform/xilinx/Kconfig | 2 ++ drivers/media/platform/xilinx/Makefile | 2 ++ drivers/media/platform/xilinx/xilinx-dma.c | 5 + drivers/media/platform/xilinx/xilinx-dma.h | 5 + drivers/media/platform/xilinx/xilinx-tpg.c | 5 + drivers/media/platform/xilinx/xilinx-vip.c | 7 ++- drivers/media/platform/xilinx/xilinx-vip.h | 5 + drivers/media/platform/xilinx/xilinx-vipp.c | 5 + drivers/media/platform/xilinx/xilinx-vipp.h | 5 + drivers/media/platform/xilinx/xilinx-vtc.c | 5 + drivers/media/platform/xilinx/xilinx-vtc.h | 5 + include/dt-bindings/media/xilinx-vip.h | 5 + 12 files changed, 15 insertions(+), 41 deletions(-) -- Regards, Laurent Pinchart
[PATCH v2] media: venus: Support V4L2 QP parameters in Venus encoder
Support V4L2 QP parameters in Venus encoder:
* V4L2_CID_MPEG_VIDEO_H264_I_FRAME_QP
* V4L2_CID_MPEG_VIDEO_H264_B_FRAME_QP
* V4L2_CID_MPEG_VIDEO_H264_MIN_QP
* V4L2_CID_MPEG_VIDEO_H264_MAX_QP
Signed-off-by: Kelvin Lawson
---
drivers/media/platform/qcom/venus/venc.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/media/platform/qcom/venus/venc.c
b/drivers/media/platform/qcom/venus/venc.c
index 41249d1..15deba7 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -651,6 +651,8 @@ static int venc_set_properties(struct venus_inst *inst)
struct hfi_framerate frate;
struct hfi_bitrate brate;
struct hfi_idr_period idrp;
+ struct hfi_quantization quant;
+ struct hfi_quantization_range quant_range;
u32 ptype, rate_control, bitrate, profile = 0, level = 0;
int ret;
@@ -770,6 +772,23 @@ static int venc_set_properties(struct venus_inst *inst)
if (ret)
return ret;
+ ptype = HFI_PROPERTY_PARAM_VENC_SESSION_QP;
+ quant.qp_i = ctr->h264_i_qp;
+ quant.qp_p = ctr->h264_p_qp;
+ quant.qp_b = ctr->h264_b_qp;
+ quant.layer_id = 0;
+ ret = hfi_session_set_property(inst, ptype, );
+ if (ret)
+ return ret;
+
+ ptype = HFI_PROPERTY_PARAM_VENC_SESSION_QP_RANGE;
+ quant_range.min_qp = ctr->h264_min_qp;
+ quant_range.max_qp = ctr->h264_max_qp;
+ quant_range.layer_id = 0;
+ ret = hfi_session_set_property(inst, ptype, _range);
+ if (ret)
+ return ret;
+
if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_H264) {
profile = venc_v4l2_to_hfi(V4L2_CID_MPEG_VIDEO_H264_PROFILE,
ctr->profile.h264);
--
2.7.4
Re: [PATCH] media: venus: Support V4L2 QP parameters in Venus encoder
Hi Stanimir, > As functional changes the patch is fine, but it has many coding style > issues. Did you read [1]? Yes, the patch was indented properly but it looks like it got mangled by the webmail interface. I'll re-submit. Thanks, Kelvin --- Kelvin Lawson Embedded Linux Consultant https://lisden.com
Re: [yavta PATCH 1/1] Zero dev in main()
Hi Sakari,
Thank you for the patch.
On Thursday, 22 November 2018 17:29:56 EET Sakari Ailus wrote:
> From: Sakari Ailus
>
> This is necessary since video_open() may not be always called soon
Do you mean video_init() ? Isn't it called at the very first line of main() ?
> Signed-off-by: Sakari Ailus
> ---
> yavta.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/yavta.c b/yavta.c
> index c7986bd..de5376d 100644
> --- a/yavta.c
> +++ b/yavta.c
> @@ -342,7 +342,6 @@ static bool video_has_valid_buf_type(struct device *dev)
>
> static void video_init(struct device *dev)
> {
> - memset(dev, 0, sizeof *dev);
> dev->fd = -1;
> dev->memtype = V4L2_MEMORY_MMAP;
> dev->buffers = NULL;
> @@ -1903,7 +1902,7 @@ static struct option opts[] = {
> int main(int argc, char *argv[])
> {
> struct sched_param sched;
> - struct device dev;
> + struct device dev = { 0 };
> int ret;
>
> /* Options parsings */
--
Regards,
Laurent Pinchart
RE: [PATCH v7 01/16] v4l: Add Intel IPU3 meta buffer formats
Hi, Laurent,
Thanks for the review.
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: Thursday, November 29, 2018 1:17 PM
> To: Zhi, Yong
> Cc: linux-media@vger.kernel.org; sakari.ai...@linux.intel.com;
> tf...@chromium.org; mche...@kernel.org; hans.verk...@cisco.com; Mani,
> Rajmohan ; Zheng, Jian Xu
> ; Hu, Jerry W ; Toivonen,
> Tuukka ; Qiu, Tian Shu
> ; Cao, Bingbu
> Subject: Re: [PATCH v7 01/16] v4l: Add Intel IPU3 meta buffer formats
>
> Hello Yong,
>
> Thank you for the patch.
>
> On Tuesday, 30 October 2018 00:22:55 EET Yong Zhi wrote:
> > Add IPU3-specific meta formats for parameter processing and 3A, DVS
> > statistics:
>
> Unless I'm mistaken DVS support has been removed. You can write this as
>
> Add IPU3-specific meta formats for processing parameters and 3A statistics.
>
Ack.
> >
> > V4L2_META_FMT_IPU3_PARAMS
> > V4L2_META_FMT_IPU3_STAT_3A
> >
> > Signed-off-by: Yong Zhi
> > ---
> > drivers/media/v4l2-core/v4l2-ioctl.c | 2 ++
> > include/uapi/linux/videodev2.h | 4
> > 2 files changed, 6 insertions(+)
>
> I would squash this with patch 03/16.
>
OK, will squash patch 01 and 03 into single patch for v8.
> > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> > b/drivers/media/v4l2-core/v4l2-ioctl.c index 6489f25..abff64b 100644
> > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > @@ -1299,6 +1299,8 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc
> *fmt)
> > case V4L2_META_FMT_VSP1_HGO:descr = "R-Car VSP1 1-D Histogram";
> break;
> > case V4L2_META_FMT_VSP1_HGT:descr = "R-Car VSP1 2-D Histogram";
> break;
> > case V4L2_META_FMT_UVC: descr = "UVC payload header
> metadata"; break;
> > + case V4L2_META_FMT_IPU3_PARAMS: descr = "IPU3 processing
> parameters";
> > break;
> > + case V4L2_META_FMT_IPU3_STAT_3A:descr = "IPU3 3A statistics";
> break;
> >
> > default:
> > /* Compressed formats */
> > diff --git a/include/uapi/linux/videodev2.h
> > b/include/uapi/linux/videodev2.h index f0a968a..bdccd7a 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -718,6 +718,10 @@ struct v4l2_pix_format {
> > #define V4L2_META_FMT_UVC v4l2_fourcc('U', 'V', 'C', 'H') /* UVC
> > Payload Header metadata */ #define V4L2_META_FMT_D4XX
> > v4l2_fourcc('D', '4', 'X', 'X') /* D4XX Payload Header metadata */
> >
> > +/* Vendor specific - used for IPU3 camera sub-system */
> > +#define V4L2_META_FMT_IPU3_PARAMS v4l2_fourcc('i', 'p', '3', 'p') /*
> IPU3
> > params */
>
> Maybe "IPU3 processing parameters" in full ?
>
Ack, thanks!!
> Apart from that the patch looks good to me.
>
> Reviewed-by: Laurent Pinchart
>
> > +#define V4L2_META_FMT_IPU3_STAT_3A v4l2_fourcc('i', 'p', '3', 's') /*
> IPU3
> > 3A statistics */
> > +
> > /* priv field value to indicates that subsequent fields are valid. */
> > #define V4L2_PIX_FMT_PRIV_MAGIC0xfeedcafe
>
>
> --
> Regards,
>
> Laurent Pinchart
>
>
Re: [PATCH v7 00/16] Intel IPU3 ImgU patchset
Hi Sakari, On Friday, 9 November 2018 12:09:54 EET Sakari Ailus wrote: > On Wed, Nov 07, 2018 at 12:16:47PM +0800, Bing Bu Cao wrote: > > On 11/01/2018 08:03 PM, Sakari Ailus wrote: > >> On Mon, Oct 29, 2018 at 03:22:54PM -0700, Yong Zhi wrote: [snip] > >>> ImgU media topology print: > >>> > >>> # media-ctl -d /dev/media0 -p > >>> Media controller API version 4.19.0 > >>> > >>> Media device information > >>> > >>> driver ipu3-imgu > >>> model ipu3-imgu > >>> serial > >>> bus infoPCI::00:05.0 > >>> hw revision 0x80862015 > >>> driver version 4.19.0 > >>> > >>> Device topology > >>> - entity 1: ipu3-imgu 0 (5 pads, 5 links) > >>> type V4L2 subdev subtype Unknown flags 0 > >>> device node name /dev/v4l-subdev0 > >>> pad0: Sink > >>> [fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown > >> > >> This doesn't seem right. Which formats can be enumerated from the pad? > > Looking at the code, the OUTPUT video nodes have 10-bit GRBG (or a variant) > format whereas the CAPTURE video nodes always have NV12. Can you confirm? > > If the OUTPUT video node format selection has no effect on the rest of the > pipeline (device capabilities, which processing blocks are in use, CAPTURE > video nodes formats etc.), I think you could simply use the FIXED media bus > code for each pad. That would actually make sense: this device always works > from memory to memory, and thus does not really have a pixel data bus > external to the device which is what the media bus codes really are for. Isn't the Bayer variant useful information to configure debayering ? I would expect it to be passed through the format on pad 0. -- Regards, Laurent Pinchart
Re: [PATCH v7 00/16] Intel IPU3 ImgU patchset
Hello Bing, On Wednesday, 7 November 2018 06:16:47 EET Bing Bu Cao wrote: > On 11/01/2018 08:03 PM, Sakari Ailus wrote: > > On Mon, Oct 29, 2018 at 03:22:54PM -0700, Yong Zhi wrote: [snip] > >> ImgU media topology print: > >> > >> # media-ctl -d /dev/media0 -p > >> Media controller API version 4.19.0 > >> > >> Media device information > >> > >> driver ipu3-imgu > >> model ipu3-imgu > >> serial > >> bus infoPCI::00:05.0 > >> hw revision 0x80862015 > >> driver version 4.19.0 > >> > >> Device topology > >> - entity 1: ipu3-imgu 0 (5 pads, 5 links) > >> type V4L2 subdev subtype Unknown flags 0 > >> device node name /dev/v4l-subdev0 > >>pad0: Sink > >>[fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown > > > > This doesn't seem right. Which formats can be enumerated from the pad? > > > >> crop:(0,0)/1920x1080 > >> compose:(0,0)/1920x1080] > > > > Does the compose rectangle affect the scaling on all outputs? > > Sakari, driver use crop and compose targets to help set input-feeder and BDS > output resolutions which are 2 key block of whole imaging pipeline, not the > actual ending output, but they will impact the final output. > > >><- "ipu3-imgu 0 input":0 [] > > > > Are there links that have no useful link configuration? If so, you should > > set them enabled and immutable in the driver. > > The enabled status of input pads is used to get which pipe that user is > trying to enable (ipu3_link_setup()), so it could not been set as immutable. Each pipe needs an input in order to operate, so from that point of view the input is mandatory. Why can't we make this link immutable, and use the stream state (VIDIOC_STREAMON/VIDIOC_STREAMOFF) to enable/disable the pipes ? > >>pad1: Sink > >>[fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown] > > > > I'd suggest to use MEDIA_BUS_FMT_FIXED here. > > > >><- "ipu3-imgu 0 parameters":0 [] > >> > >>pad2: Source > >>[fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown] > >>-> "ipu3-imgu 0 output":0 [] > >> > >>pad3: Source > >>[fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown] > >>-> "ipu3-imgu 0 viewfinder":0 [] > > > > Are there other differences between output and viewfinder? > > output and viewfinder are the main and secondary output of output system. > 'main' output is not allowed to be scaled, only support crop. secondary > output 'viewfinder' can support both cropping and scaling. User can select > different nodes to use as preview and capture flexibly based on the actual > use cases. This is very useful information, thank you. Could it be added to the documentation (patch 02/16) with a block diagram ? > >>pad4: Source > >>[fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown] > >>-> "ipu3-imgu 0 3a stat":0 [] > > > > FIXED here, too. > > > >> - entity 7: ipu3-imgu 1 (5 pads, 5 links) > >> type V4L2 subdev subtype Unknown flags 0 > >> device node name /dev/v4l-subdev1 > >> > >>pad0: Sink > >>[fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown > >> crop:(0,0)/1920x1080 > >> compose:(0,0)/1920x1080] > >><- "ipu3-imgu 1 input":0 [] > >> > >>pad1: Sink > >>[fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown] > >><- "ipu3-imgu 1 parameters":0 [] > >> > >>pad2: Source > >>[fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown] > >>-> "ipu3-imgu 1 output":0 [] > >> > >>pad3: Source > >>[fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown] > >>-> "ipu3-imgu 1 viewfinder":0 [] > >> > >>pad4: Source > >>[fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown] > >>-> "ipu3-imgu 1 3a stat":0 [] > > > > This is a minor matter but --- could you create the second sub-device > > after the video device nodes related to the first one have been already > > created? That'd make reading the output easier. > > > >> - entity 17: ipu3-imgu 0 input (1 pad, 1 link) > >> > >> type Node subtype V4L flags 0 > >> device node name /dev/video0 > >> > >>pad0: Source > >>-> "ipu3-imgu 0":0 [] > >> > >> - entity 23: ipu3-imgu 0 parameters (1 pad, 1 link) > >> type Node subtype V4L flags 0 > >> device node name /dev/video1 > >> > >>pad0: Source > >>-> "ipu3-imgu 0":1 [] > >> > >> - entity 29: ipu3-imgu 0 output (1 pad, 1 link) > >> type Node subtype V4L flags 0 > >> device node name /dev/video2 > >> > >>pad0: Sink > >><- "ipu3-imgu 0":2 [] > >> > >> - entity 35: ipu3-imgu 0 viewfinder (1 pad, 1 link) > >> type Node subtype V4L flags 0 > >>
RE: [PATCH v7 03/16] v4l: Add Intel IPU3 meta data uAPI
Hi, Sakari,
> -Original Message-
> From: Sakari Ailus [mailto:sakari.ai...@linux.intel.com]
> Sent: Thursday, November 29, 2018 4:46 PM
> To: Zhi, Yong
> Cc: linux-media@vger.kernel.org; tf...@chromium.org;
> mche...@kernel.org; hans.verk...@cisco.com;
> laurent.pinch...@ideasonboard.com; Mani, Rajmohan
> ; Zheng, Jian Xu ; Hu,
> Jerry W ; Toivonen, Tuukka
> ; Qiu, Tian Shu ; Cao,
> Bingbu ; Li, Chao C
> Subject: Re: [PATCH v7 03/16] v4l: Add Intel IPU3 meta data uAPI
>
> Hi Yong,
>
> On Fri, Nov 16, 2018 at 10:37:00PM +, Zhi, Yong wrote:
> ...
> > > > +/**
> > > > + * struct ipu3_uapi_shd_grid_config - Bayer shading(darkening)
> > > > +correction
> > > > + *
> > > > + * @width: Grid horizontal dimensions, u8, [8, 128], default 73
> > > > + * @height:Grid vertical dimensions, u8, [8, 128], default 56
> > > > + * @block_width_log2: Log2 of the width of the grid cell in pixel
> > > count
> > > > + * u4, [0, 15], default value 5.
> > > > + * @__reserved0: reserved
> > > > + * @block_height_log2: Log2 of the height of the grid cell in pixel
> > > count
> > > > + * u4, [0, 15], default value 6.
> > > > + * @__reserved1: reserved
> > > > + * @grid_height_per_slice: SHD_MAX_CELLS_PER_SET/width.
> > > > + * (with SHD_MAX_CELLS_PER_SET =
> 146).
> > > > + * @x_start: X value of top left corner of sensor relative to ROI
> > > > + * u12, [-4096, 0]. default 0, only negative values.
> > > > + * @y_start: Y value of top left corner of sensor relative to ROI
> > > > + * u12, [-4096, 0]. default 0, only negative values.
> > >
> > > I suppose u12 is incorrect here, if the value is signed --- and
> > > negative (sign bit) if not 0?
> > >
> >
> > The value will be written to 13 bit register, should use s12.0.
>
> If you have s12, that means the most significant bit is the sign bit. So if
> the
> smallest value is -4096, you'd need s13.
>
> But where is the sign bit, i.e. is this either s13 or s16?
>
The notation of s12.0 means 13 bit with fraction bit as 0 right?
> >
> > > > + */
> > > > +struct ipu3_uapi_shd_grid_config {
> > > > + /* reg 0 */
> > > > + __u8 width;
> > > > + __u8 height;
> > > > + __u8 block_width_log2:3;
> > > > + __u8 __reserved0:1;
> > > > + __u8 block_height_log2:3;
> > > > + __u8 __reserved1:1;
> > > > + __u8 grid_height_per_slice;
> > > > + /* reg 1 */
> > > > + __s16 x_start;
> > > > + __s16 y_start;
> > > > +} __packed;
>
> ...
>
> > > > +/**
> > > > + * struct ipu3_uapi_iefd_cux2_1 - Calculate power of non-directed
> denoise
> > > > + * element apply.
> > > > + * @x0: X0 point of Config Unit, u9.0, default 0.
> > > > + * @x1: X1 point of Config Unit, u9.0, default 0.
> > > > + * @a01: Slope A of Config Unit, s4.4, default 0.
> > >
> > > The field is marked unsigned below. Which one is correct?
> > >
> >
> > They are both correct, however, s4.4 is the internal representation
> > used by CU, the inputs are unsigned, I will add a note in v8, same
> > applies to the few other places as you commented.
>
> I still find this rather confusing. Is there a sign bit or is there not?
>
It's unsigned number from driver perspective, all CU inputs are unsigned,
however, they will be "converted" to signed for FW/HW to use. I have to consult
FW expert if more clarification is needed.
> >
> > > > + * @__reserved1: reserved
> > > > + * @b01: offset B0 of Config Unit, u7.0, default 0.
> > > > + * @__reserved2: reserved
> > > > + */
> > > > +struct ipu3_uapi_iefd_cux2_1 {
> > > > + __u32 x0:9;
> > > > + __u32 x1:9;
> > > > + __u32 a01:9;
> > > > + __u32 __reserved1:5;
> > > > +
> > > > + __u32 b01:8;
> > > > + __u32 __reserved2:24;
> > > > +} __packed;
> > > > +
> > > > +/**
> > > > + * struct ipu3_uapi_iefd_cux4 - Calculate power of non-directed
> > > sharpening
> > > > + * element.
> > > > + *
> > > > + * @x0:X0 point of Config Unit, u9.0, default 0.
> > > > + * @x1:X1 point of Config Unit, u9.0, default 0.
> > > > + * @x2:X2 point of Config Unit, u9.0, default 0.
> > > > + * @__reserved0: reserved
> > > > + * @x3:X3 point of Config Unit, u9.0, default 0.
> > > > + * @a01: Slope A0 of Config Unit, s4.4, default 0.
> > > > + * @a12: Slope A1 of Config Unit, s4.4, default 0.
> > >
> > > Same here, suggest __s32 below if this is signed.
> > >
> >
> > Ack, same reason as ipu3_uapi_iefd_cux2_1, will add a comments.
> >
> > > > + * @__reserved1: reserved
> > > > + * @a23: Slope A2 of Config Unit, s4.4, default 0.
> > > > + * @b01: Offset B0 of Config Unit, s7.0, default 0.
> > > > + * @b12: Offset B1 of Config Unit, s7.0, default 0.
> > > > + * @__reserved2: reserved
> > > > + * @b23: Offset B2 of Config Unit, s7.0, default 0.
>
RE: [PATCH v7 00/16] Intel IPU3 ImgU patchset
Hi Laurent, Tomasz, Thanks for the reviews. > Subject: Re: [PATCH v7 00/16] Intel IPU3 ImgU patchset > > Hi Tomasz, > > On Thursday, 29 November 2018 21:51:32 EET Tomasz Figa wrote: > > On Thu, Nov 29, 2018 at 6:43 AM Laurent Pinchart wrote: > > > On Tuesday, 30 October 2018 00:22:54 EET Yong Zhi wrote: > > [snip] > > > >> 1. Link pad flag of video nodes (i.e. ipu3-imgu 0 output) need to > > >> be enabled prior to the test. > > >> 2. Stream tests are not performed since it requires > > >> pre-configuration for each case. > > > > > > And that's a bit of an issue. I've tested the driver with a small > > > script based on media-ctl to configure links and yavta to interface > > > with the video nodes, and got the following oops: > > > > > > [ 136.927788] divide error: [#1] PREEMPT SMP PTI [ > > > 136.927801] CPU: 2 PID: 2069 Comm: yavta Not tainted 4.20.0-rc1+ #9 > > > [ 136.927806] Hardware name: HP Soraka/Soraka, BIOS 08/30/2018 [ > > > 136.927820] RIP: 0010:ipu3_css_osys_calc+0xc54/0xe14 [ipu3_imgu] [ > > > 136.927825] Code: 89 44 24 28 42 8b 44 86 6c f7 54 24 04 81 64 24 28 > > > 00 fd ff ff 81 64 24 04 00 03 00 00 8d 44 03 ff 81 44 24 28 80 03 00 > > > 00 99 fb 0f af c3 bb 20 00 00 00 99 f7 fb 8b 5c 24 40 83 fd 01 > > > 19 d2 [ 136.927830] RSP: 0018:9af2c0b837c8 EFLAGS: 00010202 [ > > > 136.927835] RAX: RBX: RCX: > > > 9af2c3e353c0 > > > [ 136.927839] RDX: RSI: 9af2c0b838e0 RDI: > > > 9af2c3e353c0 > > > [ 136.927843] RBP: 0001 R08: R09: > > > 9af2c0b83880 > > > [ 136.927846] R10: 9af2c3e353c0 R11: 9af2c3e357c0 R12: > > > 03a0 > > > [ 136.927849] R13: 00025a0a R14: R15: > > > > > > [ 136.927854] FS: 7f1eca167700() GS:8c19fab0() > > > knlGS: > > > > > > [ 136.927858] CS: 0010 DS: ES: CR0: 80050033 [ > > > 136.927862] CR2: 7f1ec776c000 CR3: 0001312a4003 CR4: > > > 003606e0 > > > [ 136.927865] Call Trace: > > > [ 136.927884] ? __accumulate_pelt_segments+0x29/0x3a > > > [ 136.927892] ? __switch_to_asm+0x40/0x70 [ 136.927899] ? > > > alloc_vmap_area+0x78/0x2f6 [ 136.927903] ? > > > __switch_to_asm+0x40/0x70 [ 136.927907] ? > > > __switch_to_asm+0x34/0x70 [ 136.927911] ? > > > __switch_to_asm+0x40/0x70 [ 136.927915] ? > > > __switch_to_asm+0x34/0x70 [ 136.927923] ? > > > __inc_numa_state+0x28/0x70 [ 136.927929] ? > > > preempt_latency_start+0x1e/0x3d [ 136.927936] ? > > > get_page_from_freelist+0x821/0xb62 > > > [ 136.927943] ? slab_pre_alloc_hook+0x12/0x3b [ 136.927948] ? > > > kmem_cache_alloc_node_trace+0xf6/0x108 > > > [ 136.927954] ? alloc_vmap_area+0x78/0x2f6 > > > > Is it just me or the backtrace above doesn't seem to make sense? I > > don't see any allocations inside ipu3_css_cfg_acc(). > > I suppose that's why it's prefixed with '?' :-) > > > > [ 136.927965] ipu3_css_cfg_acc+0xa0/0x1b5f [ipu3_imgu] [ > > > 136.927981] ipu3_css_set_parameters+0x286/0x6e7 [ipu3_imgu] [ > > > 136.927995] ipu3_css_start_streaming+0x1230/0x130a [ipu3_imgu] [ > > > 136.928010] imgu_s_stream+0x104/0x2f7 [ipu3_imgu] [ 136.928022] > > > ipu3_vb2_start_streaming+0x168/0x1bd [ipu3_imgu] [ 136.928034] > > > vb2_start_streaming+0x6c/0xf2 [videobuf2_common] [ 136.928044] > > > vb2_core_streamon+0xcf/0x109 [videobuf2_common] [ 136.928061] > > > __video_do_ioctl+0x239/0x388 [videodev] [ 136.928081] > > > video_usercopy+0x25d/0x47a [videodev] [ 136.928097] ? > > > copy_overflow+0x14/0x14 [videodev] [ 136.928115] > > > v4l2_ioctl+0x4d/0x58 [videodev] [ 136.928123] vfs_ioctl+0x1b/0x28 > > > [ 136.928130] do_vfs_ioctl+0x4de/0x566 [ 136.928139] > > > ksys_ioctl+0x50/0x70 [ 136.928146] __x64_sys_ioctl+0x16/0x19 [ > > > 136.928152] do_syscall_64+0x4d/0x5a [ 136.928158] > > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > [ 136.928164] RIP: 0033:0x7f1ec9a84f47 [ 136.928169] Code: 00 00 > > > 00 48 8b 05 51 6f 2c 00 64 c7 00 26 00 00 00 48 > > > c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f > > > 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 21 6f 2c 00 f7 d8 64 89 01 > > > 48 [ 136.928173] RSP: 002b:7ffe279e6188 EFLAGS: 0246 > ORIG_RAX: > > > 0010 > > > [ 136.928178] RAX: ffda RBX: 0007 RCX: > > > 7f1ec9a84f47 > > > [ 136.928181] RDX: 7ffe279e6194 RSI: 40045612 RDI: > > > 0003 > > > [ 136.928184] RBP: R08: 7f1ec776d000 R09: > > > > > > [ 136.928188] R10: 0020 R11: 0246 R12: > > > 7ffe279e6360 > > > [ 136.928191] R13: 0004 R14: 7ffe279e6360 R15: > > > 7ffe279e8826 > > > [ 136.928198] Modules linked in: ccm zram arc4 iwlmvm mac80211 > > > intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp iwlwifi > > > cfg80211 hid_multitouch ipu3_imgu ipu3_cio2 8250_dw
Re: [PATCH v7 00/16] Intel IPU3 ImgU patchset
Hi Tomasz, On Thursday, 29 November 2018 21:51:32 EET Tomasz Figa wrote: > On Thu, Nov 29, 2018 at 6:43 AM Laurent Pinchart wrote: > > On Tuesday, 30 October 2018 00:22:54 EET Yong Zhi wrote: [snip] > >> 1. Link pad flag of video nodes (i.e. ipu3-imgu 0 output) need to be > >> enabled prior to the test. > >> 2. Stream tests are not performed since it requires pre-configuration > >> for each case. > > > > And that's a bit of an issue. I've tested the driver with a small script > > based on media-ctl to configure links and yavta to interface with the > > video nodes, and got the following oops: > > > > [ 136.927788] divide error: [#1] PREEMPT SMP PTI > > [ 136.927801] CPU: 2 PID: 2069 Comm: yavta Not tainted 4.20.0-rc1+ #9 > > [ 136.927806] Hardware name: HP Soraka/Soraka, BIOS 08/30/2018 > > [ 136.927820] RIP: 0010:ipu3_css_osys_calc+0xc54/0xe14 [ipu3_imgu] > > [ 136.927825] Code: 89 44 24 28 42 8b 44 86 6c f7 54 24 04 81 64 24 28 00 > > fd ff ff 81 64 24 04 00 03 00 00 8d 44 03 ff 81 44 24 28 80 03 00 00 99 > > fb 0f af c3 bb 20 00 00 00 99 f7 fb 8b 5c 24 40 83 fd 01 19 d2 > > [ 136.927830] RSP: 0018:9af2c0b837c8 EFLAGS: 00010202 > > [ 136.927835] RAX: RBX: RCX: > > 9af2c3e353c0 > > [ 136.927839] RDX: RSI: 9af2c0b838e0 RDI: > > 9af2c3e353c0 > > [ 136.927843] RBP: 0001 R08: R09: > > 9af2c0b83880 > > [ 136.927846] R10: 9af2c3e353c0 R11: 9af2c3e357c0 R12: > > 03a0 > > [ 136.927849] R13: 00025a0a R14: R15: > > > > [ 136.927854] FS: 7f1eca167700() GS:8c19fab0() > > knlGS: > > > > [ 136.927858] CS: 0010 DS: ES: CR0: 80050033 > > [ 136.927862] CR2: 7f1ec776c000 CR3: 0001312a4003 CR4: > > 003606e0 > > [ 136.927865] Call Trace: > > [ 136.927884] ? __accumulate_pelt_segments+0x29/0x3a > > [ 136.927892] ? __switch_to_asm+0x40/0x70 > > [ 136.927899] ? alloc_vmap_area+0x78/0x2f6 > > [ 136.927903] ? __switch_to_asm+0x40/0x70 > > [ 136.927907] ? __switch_to_asm+0x34/0x70 > > [ 136.927911] ? __switch_to_asm+0x40/0x70 > > [ 136.927915] ? __switch_to_asm+0x34/0x70 > > [ 136.927923] ? __inc_numa_state+0x28/0x70 > > [ 136.927929] ? preempt_latency_start+0x1e/0x3d > > [ 136.927936] ? get_page_from_freelist+0x821/0xb62 > > [ 136.927943] ? slab_pre_alloc_hook+0x12/0x3b > > [ 136.927948] ? kmem_cache_alloc_node_trace+0xf6/0x108 > > [ 136.927954] ? alloc_vmap_area+0x78/0x2f6 > > Is it just me or the backtrace above doesn't seem to make sense? I > don't see any allocations inside ipu3_css_cfg_acc(). I suppose that's why it's prefixed with '?' :-) > > [ 136.927965] ipu3_css_cfg_acc+0xa0/0x1b5f [ipu3_imgu] > > [ 136.927981] ipu3_css_set_parameters+0x286/0x6e7 [ipu3_imgu] > > [ 136.927995] ipu3_css_start_streaming+0x1230/0x130a [ipu3_imgu] > > [ 136.928010] imgu_s_stream+0x104/0x2f7 [ipu3_imgu] > > [ 136.928022] ipu3_vb2_start_streaming+0x168/0x1bd [ipu3_imgu] > > [ 136.928034] vb2_start_streaming+0x6c/0xf2 [videobuf2_common] > > [ 136.928044] vb2_core_streamon+0xcf/0x109 [videobuf2_common] > > [ 136.928061] __video_do_ioctl+0x239/0x388 [videodev] > > [ 136.928081] video_usercopy+0x25d/0x47a [videodev] > > [ 136.928097] ? copy_overflow+0x14/0x14 [videodev] > > [ 136.928115] v4l2_ioctl+0x4d/0x58 [videodev] > > [ 136.928123] vfs_ioctl+0x1b/0x28 > > [ 136.928130] do_vfs_ioctl+0x4de/0x566 > > [ 136.928139] ksys_ioctl+0x50/0x70 > > [ 136.928146] __x64_sys_ioctl+0x16/0x19 > > [ 136.928152] do_syscall_64+0x4d/0x5a > > [ 136.928158] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > [ 136.928164] RIP: 0033:0x7f1ec9a84f47 > > [ 136.928169] Code: 00 00 00 48 8b 05 51 6f 2c 00 64 c7 00 26 00 00 00 48 > > c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 > > <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 21 6f 2c 00 f7 d8 64 89 01 48 > > [ 136.928173] RSP: 002b:7ffe279e6188 EFLAGS: 0246 ORIG_RAX: > > 0010 > > [ 136.928178] RAX: ffda RBX: 0007 RCX: > > 7f1ec9a84f47 > > [ 136.928181] RDX: 7ffe279e6194 RSI: 40045612 RDI: > > 0003 > > [ 136.928184] RBP: R08: 7f1ec776d000 R09: > > > > [ 136.928188] R10: 0020 R11: 0246 R12: > > 7ffe279e6360 > > [ 136.928191] R13: 0004 R14: 7ffe279e6360 R15: > > 7ffe279e8826 > > [ 136.928198] Modules linked in: ccm zram arc4 iwlmvm mac80211 intel_rapl > > x86_pkg_temp_thermal intel_powerclamp coretemp iwlwifi cfg80211 > > hid_multitouch ipu3_imgu ipu3_cio2 8250_dw videobuf2_dma_sg > > videobuf2_memops videobuf2_v4l2 processor_thermal_device > > intel_soc_dts_iosf videobuf2_common ov5670 ov13858 dw9714 v4l2_fwnode > > v4l2_common videodev media at24 cros_ec_lpcs cros_ec_core int3403_thermal > > int340x_thermal_zone int3400_thermal
Re: [PATCH v7 02/16] doc-rst: Add Intel IPU3 documentation
Hello Yong, Thank you for the patch. On Tuesday, 30 October 2018 00:22:56 EET Yong Zhi wrote: > From: Rajmohan Mani > > This patch adds the details about the IPU3 Imaging Unit driver. Strictly speaking this documents both the CIO2 and the IMGU. As they're handled by two separate drivers, should they be split in two separate files ? If you prefer keeping them together you should update the commit message accordingly. I would in that case also split the documentation in a CIO2 and a IMGU section in the file, instead of mixing them. > Change-Id: I560cecf673df2dcc3ec72767cf8077708d649656 The Change-Id: tag isn't suitable for mainline, you can drop it. > Signed-off-by: Rajmohan Mani > --- > Documentation/media/v4l-drivers/index.rst | 1 + > Documentation/media/v4l-drivers/ipu3.rst | 326 +++ > 2 files changed, 327 insertions(+) > create mode 100644 Documentation/media/v4l-drivers/ipu3.rst > > diff --git a/Documentation/media/v4l-drivers/index.rst > b/Documentation/media/v4l-drivers/index.rst index 679238e..179a393 100644 > --- a/Documentation/media/v4l-drivers/index.rst > +++ b/Documentation/media/v4l-drivers/index.rst > @@ -44,6 +44,7 @@ For more details see the file COPYING in the source > distribution of Linux. davinci-vpbe > fimc > imx > + ipu3 > ivtv > max2175 > meye > diff --git a/Documentation/media/v4l-drivers/ipu3.rst > b/Documentation/media/v4l-drivers/ipu3.rst new file mode 100644 > index 000..045bf42 > --- /dev/null > +++ b/Documentation/media/v4l-drivers/ipu3.rst > @@ -0,0 +1,326 @@ > +.. include:: > + > +=== > +Intel Image Processing Unit 3 (IPU3) Imaging Unit (ImgU) driver > +=== > + > +Copyright |copy| 2018 Intel Corporation > + > +Introduction > + > + > +This file documents Intel IPU3 (3rd generation Image Processing Unit) > Imaging s/documents Intel/documents the Intel/ > +Unit driver located under drivers/media/pci/intel/ipu3. > + > +The Intel IPU3 found in certain Kaby Lake (as well as certain Sky Lake) > +platforms (U/Y processor lines) is made up of two parts namely Imaging Unit > +(ImgU) and CIO2 device (MIPI CSI2 receiver). s/namely Imaging Unit/, namely the Imaging Unit/ s/and CIO2/and the CIO2/ > + > +The CIO2 device receives the raw bayer data from the sensors and outputs > the +frames in a format that is specific to IPU3 (for consumption by IPU3 > ImgU). s/to IPU3/to the IPU3/ s/by IPU3/by the IPU3/ > +CIO2 driver is available as drivers/media/pci/intel/ipu3/ipu3-cio2* > and is +enabled through the CONFIG_VIDEO_IPU3_CIO2 config option. s/CIO2 driver/The CIO2 driver/ > + > +The Imaging Unit (ImgU) is responsible for processing images captured s/images/the images/ > +through IPU3 CIO2 device. The ImgU driver sources can be found under s/IPU3 CIO2/the IPU3 CIO2/ > +drivers/media/pci/intel/ipu3 directory. The driver is enabled through the > +CONFIG_VIDEO_IPU3_IMGU config option. > + > +The two driver modules are named ipu3-csi2 and ipu3-imgu, respectively. > + > +The driver has been tested on Kaby Lake platforms (U/Y processor lines). I assume both drivers have been tested, so I would write s/The driver has/The drivers have/ > +The driver implements V4L2, Media controller and V4L2 sub-device > interfaces. As this is true for both drivers, s/The driver implements V4L2/Both drivers implement the V4L2/ s/Media controller/Media Controller/ > +Camera sensors that have CSI-2 bus, which are connected to the IPU3 CIO2 > +device are supported. I would rephrase this slightly, as "The IPU3 CIO2 driver supports camera sensors connected to the CIO2 MIPI CSI-2 interfaces through V4L2 sub-device sensor drivers." > Support for lens and flash drivers depends on the > +above sensors. That's a very good introduction ! I would follow with two sections, "IPU3 CIO2" followed by "IPU3 ImgU". > +ImgU device nodes > += > + > +The ImgU is represented as two V4L2 subdevs, each of which provides a V4L2 > +subdev interface to the user space. Not just subdevs, but video nodes too. I would rephrase as follows (please note that this might not be valid .rst content, I haven't tried compiling it, it might need to be reworked slightly) : "The ImgU contains two independent pipes, each modelled as a V4L2 sub-device exposed to userspace as a V4L2 sub-device node. Each pipe has two input pads and three output pads for the following purpose: Pad 0 (input): Input raw video stream Pad 1 (input): Processing parameters Pad 2 (output): Output processed video stream Pad 3 (output): Output viewfinder video stream Pad 4 (output): 3A statistics Each pad is connected to a corresponding V4L2 video interface, exposed to userspace as a V4L2 video device node." > +Each V4L2 subdev represents a pipe, which can support a maximum of 2 > +streams. A private ioctl can be used to
[PATCH 1/4] media: lmedm04: Add missing usb_free_urb to free, interrupt urb
The interrupt urb is killed but never freed add the function
Cc: sta...@vger.kernel.org
Signed-off-by: Malcolm Priestley
---
drivers/media/usb/dvb-usb-v2/lmedm04.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/usb/dvb-usb-v2/lmedm04.c
b/drivers/media/usb/dvb-usb-v2/lmedm04.c
index f109c04f05ae..8b405e131439 100644
--- a/drivers/media/usb/dvb-usb-v2/lmedm04.c
+++ b/drivers/media/usb/dvb-usb-v2/lmedm04.c
@@ -1264,6 +1264,7 @@ static void *lme2510_exit_int(struct dvb_usb_device *d)
if (st->lme_urb != NULL) {
usb_kill_urb(st->lme_urb);
+ usb_free_urb(st->lme_urb);
usb_free_coherent(d->udev, 128, st->buffer,
st->lme_urb->transfer_dma);
info("Interrupt Service Stopped");
--
2.19.1
[PATCH 2/4] media: lmedm04: Move usb buffer to lme2510_state.
lme2510_state exists for the entire duration of driver.
Move usb_buffer to lme2510_state removing the need for
lme2510_exit_int for removing the buffer.
Signed-off-by: Malcolm Priestley
---
drivers/media/usb/dvb-usb-v2/lmedm04.c | 35 +++---
1 file changed, 3 insertions(+), 32 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/lmedm04.c
b/drivers/media/usb/dvb-usb-v2/lmedm04.c
index 8b405e131439..8fb53b83c914 100644
--- a/drivers/media/usb/dvb-usb-v2/lmedm04.c
+++ b/drivers/media/usb/dvb-usb-v2/lmedm04.c
@@ -136,7 +136,7 @@ struct lme2510_state {
u8 pid_off;
void *buffer;
struct urb *lme_urb;
- void *usb_buffer;
+ u8 usb_buffer[64];
/* Frontend original calls */
int (*fe_read_status)(struct dvb_frontend *, enum fe_status *);
int (*fe_read_signal_strength)(struct dvb_frontend *, u16 *);
@@ -169,18 +169,9 @@ static int lme2510_usb_talk(struct dvb_usb_device *d,
u8 *wbuf, int wlen, u8 *rbuf, int rlen)
{
struct lme2510_state *st = d->priv;
- u8 *buff;
+ u8 *buff = st->usb_buffer;
int ret = 0;
- if (st->usb_buffer == NULL) {
- st->usb_buffer = kmalloc(64, GFP_KERNEL);
- if (st->usb_buffer == NULL) {
- info("MEM Error no memory");
- return -ENOMEM;
- }
- }
- buff = st->usb_buffer;
-
ret = mutex_lock_interruptible(>usb_mutex);
if (ret < 0)
@@ -1245,23 +1236,15 @@ static int lme2510_get_rc_config(struct dvb_usb_device
*d,
return 0;
}
-static void *lme2510_exit_int(struct dvb_usb_device *d)
+static void lme2510_exit(struct dvb_usb_device *d)
{
struct lme2510_state *st = d->priv;
struct dvb_usb_adapter *adap = >adapter[0];
- void *buffer = NULL;
if (adap != NULL) {
lme2510_kill_urb(>stream);
}
- if (st->usb_buffer != NULL) {
- st->i2c_talk_onoff = 1;
- st->signal_level = 0;
- st->signal_sn = 0;
- buffer = st->usb_buffer;
- }
-
if (st->lme_urb != NULL) {
usb_kill_urb(st->lme_urb);
usb_free_urb(st->lme_urb);
@@ -1269,18 +1252,6 @@ static void *lme2510_exit_int(struct dvb_usb_device *d)
st->lme_urb->transfer_dma);
info("Interrupt Service Stopped");
}
-
- return buffer;
-}
-
-static void lme2510_exit(struct dvb_usb_device *d)
-{
- void *usb_buffer;
-
- if (d != NULL) {
- usb_buffer = lme2510_exit_int(d);
- kfree(usb_buffer);
- }
}
static struct dvb_usb_device_properties lme2510_props = {
--
2.19.1
[PATCH 3/4] media: lmedm04: Move interrupt buffer to priv buffer.
Interrupt is always present throught life time of
there is no dma element move this buffer to private
area of driver.
Signed-off-by: Malcolm Priestley
---
drivers/media/usb/dvb-usb-v2/lmedm04.c | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/lmedm04.c
b/drivers/media/usb/dvb-usb-v2/lmedm04.c
index 8fb53b83c914..7b1aaed259db 100644
--- a/drivers/media/usb/dvb-usb-v2/lmedm04.c
+++ b/drivers/media/usb/dvb-usb-v2/lmedm04.c
@@ -134,7 +134,7 @@ struct lme2510_state {
u8 stream_on;
u8 pid_size;
u8 pid_off;
- void *buffer;
+ u8 int_buffer[128];
struct urb *lme_urb;
u8 usb_buffer[64];
/* Frontend original calls */
@@ -408,20 +408,14 @@ static int lme2510_int_read(struct dvb_usb_adapter *adap)
if (lme_int->lme_urb == NULL)
return -ENOMEM;
- lme_int->buffer = usb_alloc_coherent(d->udev, 128, GFP_ATOMIC,
- _int->lme_urb->transfer_dma);
-
- if (lme_int->buffer == NULL)
- return -ENOMEM;
-
usb_fill_int_urb(lme_int->lme_urb,
- d->udev,
- usb_rcvintpipe(d->udev, 0xa),
- lme_int->buffer,
- 128,
- lme2510_int_response,
- adap,
- 8);
+d->udev,
+usb_rcvintpipe(d->udev, 0xa),
+lme_int->int_buffer,
+sizeof(lme_int->int_buffer),
+lme2510_int_response,
+adap,
+8);
/* Quirk of pipe reporting PIPE_BULK but behaves as interrupt */
ep = usb_pipe_endpoint(d->udev, lme_int->lme_urb->pipe);
@@ -1245,11 +1239,9 @@ static void lme2510_exit(struct dvb_usb_device *d)
lme2510_kill_urb(>stream);
}
- if (st->lme_urb != NULL) {
+ if (st->lme_urb) {
usb_kill_urb(st->lme_urb);
usb_free_urb(st->lme_urb);
- usb_free_coherent(d->udev, 128, st->buffer,
- st->lme_urb->transfer_dma);
info("Interrupt Service Stopped");
}
}
--
2.19.1
[PATCH 4/4] media: lmedm04: use dvb_usbv2_generic_rw_locked
Use dvb-usb-v2 generic usb function for bulk transfers and simplify logic.
Signed-off-by: Malcolm Priestley
---
drivers/media/usb/dvb-usb-v2/lmedm04.c | 42 --
1 file changed, 12 insertions(+), 30 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/lmedm04.c
b/drivers/media/usb/dvb-usb-v2/lmedm04.c
index 7b1aaed259db..8ca0cc67541f 100644
--- a/drivers/media/usb/dvb-usb-v2/lmedm04.c
+++ b/drivers/media/usb/dvb-usb-v2/lmedm04.c
@@ -147,50 +147,30 @@ struct lme2510_state {
u8 dvb_usb_lme2510_firmware;
};
-static int lme2510_bulk_write(struct usb_device *dev,
- u8 *snd, int len, u8 pipe)
-{
- int actual_l;
-
- return usb_bulk_msg(dev, usb_sndbulkpipe(dev, pipe),
- snd, len, _l, 100);
-}
-
-static int lme2510_bulk_read(struct usb_device *dev,
- u8 *rev, int len, u8 pipe)
-{
- int actual_l;
-
- return usb_bulk_msg(dev, usb_rcvbulkpipe(dev, pipe),
- rev, len, _l, 200);
-}
-
static int lme2510_usb_talk(struct dvb_usb_device *d,
- u8 *wbuf, int wlen, u8 *rbuf, int rlen)
+ u8 *wbuf, int wlen, u8 *rbuf, int rlen)
{
struct lme2510_state *st = d->priv;
- u8 *buff = st->usb_buffer;
int ret = 0;
- ret = mutex_lock_interruptible(>usb_mutex);
+ if (max(wlen, rlen) > sizeof(st->usb_buffer))
+ return -EINVAL;
+ ret = mutex_lock_interruptible(>usb_mutex);
if (ret < 0)
return -EAGAIN;
- /* the read/write capped at 64 */
- memcpy(buff, wbuf, (wlen < 64) ? wlen : 64);
+ memcpy(st->usb_buffer, wbuf, wlen);
- ret |= lme2510_bulk_write(d->udev, buff, wlen , 0x01);
+ ret = dvb_usbv2_generic_rw_locked(d, st->usb_buffer, wlen,
+ st->usb_buffer, rlen);
- ret |= lme2510_bulk_read(d->udev, buff, (rlen < 64) ?
- rlen : 64 , 0x01);
-
- if (rlen > 0)
- memcpy(rbuf, buff, rlen);
+ if (rlen)
+ memcpy(rbuf, st->usb_buffer, rlen);
mutex_unlock(>usb_mutex);
- return (ret < 0) ? -ENODEV : 0;
+ return ret;
}
static int lme2510_stream_restart(struct dvb_usb_device *d)
@@ -1252,6 +1232,8 @@ static struct dvb_usb_device_properties lme2510_props = {
.bInterfaceNumber = 0,
.adapter_nr = adapter_nr,
.size_of_priv = sizeof(struct lme2510_state),
+ .generic_bulk_ctrl_endpoint = 0x01,
+ .generic_bulk_ctrl_endpoint_response = 0x01,
.download_firmware = lme2510_download_firmware,
--
2.19.1
Re: [PATCH v7 00/16] Intel IPU3 ImgU patchset
On Thu, Nov 29, 2018 at 6:43 AM Laurent Pinchart wrote: > > Hello Yong, > > On Tuesday, 30 October 2018 00:22:54 EET Yong Zhi wrote: > > Hi, > > > > This series 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 11. > > > > All IPU3 pipeline default settings can be found in patch 10. > > > > To access DDR via ImgU's own memory space, IPU3 is also equipped with > > its own MMU unit, the driver is implemented in patch 6. > > > > Patch 7 uses above driver for DMA mapping operation. > > > > The communication between IPU3 firmware and driver is implemented with > > circular queues in patch 8. > > > > Patch 9 provide some utility functions and manage IPU3 fw download and > > install. > > > > The firmware which is called ipu3-fw.bin can be downloaded from: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git > > (commit 2c27b0cb02f18c022d8378e0e1abaf8b7ae8188f) > > > > Firmware ABI is defined in patches 4 and 5. > > > > Patches 12 and 13 are of the same file, the former contains all h/w > > programming related code, the latter implements interface functions for > > access fw & hw capabilities. > > > > Patch 14 has a dependency on Sakari's V4L2_BUF_TYPE_META_OUTPUT work: > > > > https://patchwork.kernel.org/patch/9976295/> > > > > Patch 15 represents the top level that glues all of the other components > > together, passing arguments between the components. > > > > Patch 16 is a recent effort to extend v6 for advanced camera features like > > Continuous View Finder (CVF) and Snapshot During Video(SDV) support. > > > > Link to user space implementation: > > > > git clone https://chromium.googlesource.com/chromiumos/platform/arc-camera > > > > ImgU media topology print: > > [snip] > > > v4l2-compliance utility is built with Sakari's patches for meta data > > output support(rebased): > > > > https://patchwork.linuxtv.org/patch/43370/> > > https://patchwork.linuxtv.org/patch/43369/> > > > > The test (v4l2-compliance -m 0) passes without error, outputs are appended > > at the end of revision history. > > > > Note: > > > > 1. Link pad flag of video nodes (i.e. ipu3-imgu 0 output) need to be enabled > > prior to the test. > > 2. Stream tests are not performed since it requires pre-configuration for > > each case. > > And that's a bit of an issue. I've tested the driver with a small script based > on media-ctl to configure links and yavta to interface with the video nodes, > and got the following oops: > > [ 136.927788] divide error: [#1] PREEMPT SMP PTI > [ 136.927801] CPU: 2 PID: 2069 Comm: yavta Not tainted 4.20.0-rc1+ #9 > [ 136.927806] Hardware name: HP Soraka/Soraka, BIOS 08/30/2018 > [ 136.927820] RIP: 0010:ipu3_css_osys_calc+0xc54/0xe14 [ipu3_imgu] > [ 136.927825] Code: 89 44 24 28 42 8b 44 86 6c f7 54 24 04 81 64 24 28 00 fd > ff ff 81 64 24 04 00 03 00 00 8d 44 03 ff 81 44 24 28 80 03 00 00 99 fb > 0f af c3 bb 20 00 00 00 99 f7 fb 8b 5c 24 40 83 fd 01 19 d2 > [ 136.927830] RSP: 0018:9af2c0b837c8 EFLAGS: 00010202 > [ 136.927835] RAX: RBX: RCX: > 9af2c3e353c0 > [ 136.927839] RDX: RSI: 9af2c0b838e0 RDI: > 9af2c3e353c0 > [ 136.927843] RBP: 0001 R08: R09: > 9af2c0b83880 > [ 136.927846] R10: 9af2c3e353c0 R11: 9af2c3e357c0 R12: > 03a0 > [ 136.927849] R13: 00025a0a R14: R15: > > [ 136.927854] FS: 7f1eca167700() GS:8c19fab0() knlGS: > > [ 136.927858] CS: 0010 DS: ES:
Re: [PATCH v7 01/16] v4l: Add Intel IPU3 meta buffer formats
Hello Yong,
Thank you for the patch.
On Tuesday, 30 October 2018 00:22:55 EET Yong Zhi wrote:
> Add IPU3-specific meta formats for parameter
> processing and 3A, DVS statistics:
Unless I'm mistaken DVS support has been removed. You can write this as
Add IPU3-specific meta formats for processing parameters and 3A
statistics.
>
> V4L2_META_FMT_IPU3_PARAMS
> V4L2_META_FMT_IPU3_STAT_3A
>
> Signed-off-by: Yong Zhi
> ---
> drivers/media/v4l2-core/v4l2-ioctl.c | 2 ++
> include/uapi/linux/videodev2.h | 4
> 2 files changed, 6 insertions(+)
I would squash this with patch 03/16.
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> b/drivers/media/v4l2-core/v4l2-ioctl.c index 6489f25..abff64b 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1299,6 +1299,8 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
> case V4L2_META_FMT_VSP1_HGO: descr = "R-Car VSP1 1-D Histogram"; break;
> case V4L2_META_FMT_VSP1_HGT: descr = "R-Car VSP1 2-D Histogram"; break;
> case V4L2_META_FMT_UVC: descr = "UVC payload header metadata";
> break;
> + case V4L2_META_FMT_IPU3_PARAMS: descr = "IPU3 processing parameters";
> break;
> + case V4L2_META_FMT_IPU3_STAT_3A:descr = "IPU3 3A statistics";
> break;
>
> default:
> /* Compressed formats */
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index f0a968a..bdccd7a 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -718,6 +718,10 @@ struct v4l2_pix_format {
> #define V4L2_META_FMT_UVC v4l2_fourcc('U', 'V', 'C', 'H') /* UVC
> Payload Header metadata */ #define V4L2_META_FMT_D4XX
> v4l2_fourcc('D', '4', 'X', 'X') /* D4XX Payload Header metadata */
>
> +/* Vendor specific - used for IPU3 camera sub-system */
> +#define V4L2_META_FMT_IPU3_PARAMSv4l2_fourcc('i', 'p', '3', 'p') /* IPU3
> params */
Maybe "IPU3 processing parameters" in full ?
Apart from that the patch looks good to me.
Reviewed-by: Laurent Pinchart
> +#define V4L2_META_FMT_IPU3_STAT_3A v4l2_fourcc('i', 'p', '3', 's') /* IPU3
> 3A statistics */
> +
> /* priv field value to indicates that subsequent fields are valid. */
> #define V4L2_PIX_FMT_PRIV_MAGIC 0xfeedcafe
--
Regards,
Laurent Pinchart
Re: [PATCH 0/2] media: ov5640: MIPI fixes on top of Maxime's v5
On Thu, Nov 29, 2018 at 8:48 AM Jacopo Mondi wrote: > > Hello ov5640-ers, >these two patches should be applied on top of Maxime's clock tree rework v5 > and 'fix' MIPI CSI-2 clock tree configuration. > > The first patch is a fix that appeard in various forms on the list several > times: if the image sizes gets updated but not the image format, the size > update gets ignored. I had to fix this to run my FPS tests, and thus I'm > sending the two together. I wish in future a re-work of the image format > handling part, but for now, let's just fix it for v4.21. > > The second patch slightly reworks the MIPI clock tree configuration, based on > inputs from Sam. The currently submitted v5 in which Maxime squashed my > previous > changes is 'broken'. That's my bad, as explained in the patch change log. > > Test results are attacched to patch [2/2]. > Changelog for [2/2] is included in the patch itself. > > I wish these patches to go in with Maxime awesome clock tree re-work, pending > his ack. > > Also, I have tested with an i.MX6Q board, with a CSI-2 2 data lanes setup. > There > are still a few things not clear to me in the MIPI clock tree, and I welcome > more testing, preferibly with 1-lanes setups. > > Also, I had to re-apply Maxime's series and latest ov5640 patches on v4.19, > as my test board is sort of broken with v4.20-rcX (it shouldn't make any > difference in regard to this series, but I'm pointing it out anyhow). Greg KH is pulling in some of the first round of fixes to the 4.19.y branch. If they're working, we may want to consider having Greg Apply these there as well. > > Recently Adam has been testing quite some ov5640 patches, if you fill like > testing these as well on your setup (which I understand is a MIPI CSI-2 one) > please report the results. Same for all other interested ones :) You are correct, I have an i.MX6 with CSI2 interface. I'll test against 4.20-RCx and my 4.19 version with some of the newer patches pulled down. I will try to get to these before Monday. adam > > Thanks > j > > Jacopo Mondi (2): > media: i2c: ov5640: Fix set format regression > media: ov5640: make MIPI clock depend on mode > > drivers/media/i2c/ov5640.c | 110 > ++--- > 1 file changed, 54 insertions(+), 56 deletions(-) > > -- > 2.7.4 >
Re: Astrometa DVB-T2 2018 update
On Mon, Nov 05, 2018 at 07:12:52PM +, Bob Goddard wrote:
> Enable Sony CXD2837ER slave demon on the Astrometa DVB-T2, known as the 2018
> update.
>
> Originally based on the patch by kapitanf at
> https://github.com/torvalds/linux/pull/567, it was not quite right. This is
> more correct, but probably still wrong. I'm not a kernel dev, but someone may
> be better positioned to handle the niceties.
Before this patch can be accepted, we need a Signed-off-by: from the
original author, see:
https://www.kernel.org/doc/html/v4.12/process/submitting-patches.html?highlight=signed%20off#sign-your-work-the-developer-s-certificate-of-origin
>
>
>
> diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig
> b/drivers/media/usb/dvb-usb-v2/Kconfig
> index df4412245a8a..d44ddd5ee29e 100644
> --- a/drivers/media/usb/dvb-usb-v2/Kconfig
> +++ b/drivers/media/usb/dvb-usb-v2/Kconfig
> @@ -137,6 +137,7 @@ config DVB_USB_RTL28XXU
> select DVB_RTL2832
> select DVB_RTL2832_SDR if (MEDIA_SUBDRV_AUTOSELECT && MEDIA_SDR_SUPPORT)
> select DVB_SI2168 if MEDIA_SUBDRV_AUTOSELECT
> + select DVB_CXD2841ER if MEDIA_SUBDRV_AUTOSELECT
> select MEDIA_TUNER_E4000 if MEDIA_SUBDRV_AUTOSELECT
> select MEDIA_TUNER_FC0012 if MEDIA_SUBDRV_AUTOSELECT
> select MEDIA_TUNER_FC0013 if MEDIA_SUBDRV_AUTOSELECT
> diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
> b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
> index a970224a94bd..db4f4da43781 100644
> --- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
> +++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
> @@ -386,6 +386,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
> struct rtl28xxu_req req_mn88473 = {0xff38, CMD_I2C_RD, 1, buf};
> struct rtl28xxu_req req_si2157 = {0x00c0, CMD_I2C_RD, 1, buf};
> struct rtl28xxu_req req_si2168 = {0x00c8, CMD_I2C_RD, 1, buf};
> + struct rtl28xxu_req req_cxd2837er = {0x68d8, CMD_I2C_RD, 1, buf};
>
> dev_dbg(>intf->dev, "\n");
>
> @@ -567,6 +568,13 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
> dev->slave_demod = SLAVE_DEMOD_MN88473;
> goto demod_found;
> }
> +
> + ret = rtl28xxu_ctrl_msg(d, _cxd2837er);
> + if (ret == 0 && buf[0] == 0x03) {
> + dev_dbg(>intf->dev, "CXD2837ER found");
> + dev->slave_demod = SLAVE_DEMOD_CXD2841ER;
> + goto demod_found;
> + }
> }
> if (dev->tuner == TUNER_RTL2832_SI2157) {
> /* check Si2168 ID register; reg=c8 val=80 */
> @@ -988,6 +996,27 @@ static int rtl2832u_frontend_attach(struct
> dvb_usb_adapter *adap)
> goto err_slave_demod_failed;
> }
>
> + dev->i2c_client_slave_demod = client;
> + } else if (dev->slave_demod == SLAVE_DEMOD_CXD2841ER) {
> + struct cxd2841er_config cxd2837er_config = {};
> + cxd2837er_config.i2c_addr = 0xd8;
> + cxd2837er_config.xtal = SONY_XTAL_20500;
> + cxd2837er_config.flags = CXD2841ER_AUTO_IFHZ|
> CXD2841ER_EARLY_TUNE |
> + CXD2841ER_NO_WAIT_LOCK |
> CXD2841ER_NO_AGCNEG |
> + CXD2841ER_TSBITS |
> CXD2841ER_TS_SERIAL;
> +
> + adap->fe[1] = dvb_attach( cxd2841er_attach_t_c,
> _config, >i2c_adap );
Unneeded spaces around function arguments.
> + if (!adap->fe[1]) {
> + dev_err(>intf->dev, "CXD2837ER attach
> failed!\n");
> + return -ENODEV;
> + }
> +
> + if (!try_module_get(client->dev.driver->owner)) {
> + i2c_unregister_device(client);
> + dev->slave_demod = SLAVE_DEMOD_NONE;
> + goto err_slave_demod_failed;
> + }
> +
> dev->i2c_client_slave_demod = client;
> } else {
> struct si2168_config si2168_config = {};
> @@ -1046,10 +1075,14 @@ static int rtl28xxu_frontend_detach(struct
> dvb_usb_adapter *adap)
> dev_dbg(>intf->dev, "\n");
>
> /* remove I2C slave demod */
> - client = dev->i2c_client_slave_demod;
> - if (client) {
> - module_put(client->dev.driver->owner);
> - i2c_unregister_device(client);
> + if (dev->slave_demod == SLAVE_DEMOD_CXD2841ER) {
> + dev_info(>intf->dev,"Sony CXD2837ER detached
> automatically.");
For one thing the reference count for the module was increased on attach,
so we should also decrease it on dettach. Why are we not unregistering
the i2c device?
> + } else {
> + client = dev->i2c_client_slave_demod;
> + if (client) {
> + module_put(client->dev.driver->owner);
[PATCH 2/2] media: ov5640: make MIPI clock depend on mode
The MIPI clock generation tree uses the MIPI_DIV divider to generate both the MIPI SCALER CLOCK and the PIXEL_CLOCK. It seems the MIPI BIT CLK frequency is generated by either the MIPI SCALER or the PIXEL CLOCK, depending if the currently applied image mode uses the scaler or not. Make the MIPI_DIV selection value depend on the subsampling mode used by the currently applied image mode. Tested with: 172x144 320x240, 640x480, 1024x756, 1024x768, 1280x720, 1920x1080 in YUYV mode at 10, 15, 20, and 30 FPS with MIPI CSI-2 2 lanes mode. Signed-off-by: Jacopo Mondi --- Maxime, this patch is not just a cosmetic updates to the 'set_mipi_pclk()' comment block as I anticipated, but it actually fix the framerate handling compared for CSI-2, which in you v5 results halved for most modes. I have not included any "Fixes:" tag, as I hope this patch will get in with your v5. That's my bad, as in the patches I sent to be applied on top of your v4 I forgot to add a change, and the requested SCLK rate was always half of what it was actually required. Also, I have left out from this patches most of Sam's improvements (better SCLK selection policies, and programming of register OV5640_REG_PCLK_PERIOD as for from testing they're not required, and I don't want to pile more patches than necessary for the next merge window, not to slow down the clock tree rework inclusion. We can get back to it after it got merged. This are the test result obtained by capturing 100 frames with yavta and inspecting the reported fps results. Results are pretty neat, 2592x1944 mode apart, which runs a bit slow. capturing 176x144 @ 10FPS Captured 100 frames in 10.019398 seconds (9.980640 fps, 505898.657683 B/s). capturing 176x144 @ 15FPS Captured 100 frames in 6.681860 seconds (14.965892 fps, 758591.132803 B/s). capturing 176x144 @ 20FPS Captured 100 frames in 5.056204 seconds (19.777683 fps, 1002491.196755 B/s). capturing 176x144 @ 30FPS Captured 100 frames in 3.357204 seconds (29.786686 fps, 1509827.521040 B/s). capturing 320x240 @ 10FPS Captured 100 frames in 10.015432 seconds (9.984591 fps, 1533633.245951 B/s). capturing 320x240 @ 15FPS Captured 100 frames in 6.684035 seconds (14.961021 fps, 2298012.872049 B/s). capturing 320x240 @ 20FPS Captured 100 frames in 5.019164 seconds (19.923635 fps, 3060270.391218 B/s). capturing 320x240 @ 30FPS Captured 100 frames in 3.352991 seconds (29.824115 fps, 4580984.103432 B/s). capturing 640x480 @ 10FPS Captured 100 frames in 9.990389 seconds (10.009620 fps, 6149910.678538 B/s). capturing 640x480 @ 15FPS Captured 100 frames in 6.856242 seconds (14.585249 fps, 8961176.838123 B/s). capturing 640x480 @ 20FPS Captured 100 frames in 5.030264 seconds (19.879670 fps, 12214069.053476 B/s). capturing 640x480 @ 30FPS Captured 100 frames in 3.364612 seconds (29.721103 fps, 18260645.750580 B/s). capturing 720x480 @ 10FPS Captured 100 frames in 10.022488 seconds (9.977562 fps, 6896491.169279 B/s). capturing 720x480 @ 15FPS Captured 100 frames in 6.891968 seconds (14.509643 fps, 10029065.232208 B/s). capturing 720x480 @ 20FPS Captured 100 frames in 5.234133 seconds (19.105360 fps, 13205624.616211 B/s). capturing 720x480 @ 30FPS Captured 100 frames in 3.602298 seconds (27.760055 fps, 19187750.044688 B/s). capturing 720x576 @ 10FPS Captured 100 frames in 10.197244 seconds (9.806571 fps, 8133961.937805 B/s). capturing 720x576 @ 15FPS Captured 100 frames in 6.925244 seconds (14.439924 fps, 11977050.339261 B/s). capturing 720x576 @ 20FPS Captured 100 frames in 4.68 seconds (20.000127 fps, 16588905.060854 B/s). capturing 720x576 @ 30FPS Captured 100 frames in 3.487568 seconds (28.673276 fps, 23782762.085212 B/s). capturing 1024x768 @ 10FPS Captured 100 frames in 10.107128 seconds (9.894007 fps, 15561928.174298 B/s). capturing 1024x768 @ 15FPS Captured 100 frames in 6.810568 seconds (14.683062 fps, 23094459.169337 B/s). capturing 1024x768 @ 20FPS Captured 100 frames in 5.012039 seconds (19.951960 fps, 31381719.096759 B/s). capturing 1024x768 @ 30FPS Captured 100 frames in 3.346338 seconds (29.883407 fps, 47002534.905114 B/s). capturing 1280x720 @ 10FPS Captured 100 frames in 9.957613 seconds (10.042567 fps, 18510459.665283 B/s). capturing 1280x720 @ 15FPS Captured 100 frames in 6.597751 seconds (15.156679 fps, 27936790.986673 B/s). capturing 1280x720 @ 20FPS Captured 100 frames in 4.946115 seconds (20.217888 fps, 37265611.495083 B/s). capturing 1280x720 @ 30FPS Captured 100 frames in 3.301329 seconds (30.290825 fps, 55832049.080847 B/s). capturing 1920x1080 @ 10FPS Captured 100 frames in 10.024745 seconds (9.975316 fps, 41369629.470131 B/s). capturing 1920x1080 @ 15FPS Captured 100 frames in 6.674363 seconds (14.982702 fps, 62136260.577244 B/s). capturing 1920x1080 @ 20FPS Captured 100 frames in 5.102174 seconds (19.599488 fps, 81282998.172684 B/s). capturing 1920x1080 @ 30FPS Captured 100 frames in 3.341157 seconds (29.929746 fps, 124124642.214916 B/s). capturing 2592x1944 @ 10FPS Captured 100 frames in
[PATCH 0/2] media: ov5640: MIPI fixes on top of Maxime's v5
Hello ov5640-ers, these two patches should be applied on top of Maxime's clock tree rework v5 and 'fix' MIPI CSI-2 clock tree configuration. The first patch is a fix that appeard in various forms on the list several times: if the image sizes gets updated but not the image format, the size update gets ignored. I had to fix this to run my FPS tests, and thus I'm sending the two together. I wish in future a re-work of the image format handling part, but for now, let's just fix it for v4.21. The second patch slightly reworks the MIPI clock tree configuration, based on inputs from Sam. The currently submitted v5 in which Maxime squashed my previous changes is 'broken'. That's my bad, as explained in the patch change log. Test results are attacched to patch [2/2]. Changelog for [2/2] is included in the patch itself. I wish these patches to go in with Maxime awesome clock tree re-work, pending his ack. Also, I have tested with an i.MX6Q board, with a CSI-2 2 data lanes setup. There are still a few things not clear to me in the MIPI clock tree, and I welcome more testing, preferibly with 1-lanes setups. Also, I had to re-apply Maxime's series and latest ov5640 patches on v4.19, as my test board is sort of broken with v4.20-rcX (it shouldn't make any difference in regard to this series, but I'm pointing it out anyhow). Recently Adam has been testing quite some ov5640 patches, if you fill like testing these as well on your setup (which I understand is a MIPI CSI-2 one) please report the results. Same for all other interested ones :) Thanks j Jacopo Mondi (2): media: i2c: ov5640: Fix set format regression media: ov5640: make MIPI clock depend on mode drivers/media/i2c/ov5640.c | 110 ++--- 1 file changed, 54 insertions(+), 56 deletions(-) -- 2.7.4
[PATCH 1/2] media: ov5640: Fix set format regression
The set_fmt operations updates the sensor format only when the image format
is changed. When only the image sizes gets changed, the format do not get
updated causing the sensor to always report the one that was previously in
use.
Without this patch, updating frame size only fails:
[fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:srgb xfer:srgb ...]
With this patch applied:
[fmt:UYVY8_2X8/1024x768@1/30 field:none colorspace:srgb xfer:srgb ...]
Fixes: 6949d864776e ("media: ov5640: do not change mode if format or frame
interval is unchanged")
Signed-off-by: Jacopo Mondi
---
drivers/media/i2c/ov5640.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 03a031a42b3e..c659efe918a4 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -2160,6 +2160,7 @@ static int ov5640_set_fmt(struct v4l2_subdev *sd,
struct ov5640_dev *sensor = to_ov5640_dev(sd);
const struct ov5640_mode_info *new_mode;
struct v4l2_mbus_framefmt *mbus_fmt = >format;
+ struct v4l2_mbus_framefmt *fmt;
int ret;
if (format->pad != 0)
@@ -2177,22 +2178,20 @@ static int ov5640_set_fmt(struct v4l2_subdev *sd,
if (ret)
goto out;
- if (format->which == V4L2_SUBDEV_FORMAT_TRY) {
- struct v4l2_mbus_framefmt *fmt =
- v4l2_subdev_get_try_format(sd, cfg, 0);
+ if (format->which == V4L2_SUBDEV_FORMAT_TRY)
+ fmt = v4l2_subdev_get_try_format(sd, cfg, 0);
+ else
+ fmt = >fmt;
- *fmt = *mbus_fmt;
- goto out;
- }
+ *fmt = *mbus_fmt;
if (new_mode != sensor->current_mode) {
sensor->current_mode = new_mode;
sensor->pending_mode_change = true;
}
- if (mbus_fmt->code != sensor->fmt.code) {
- sensor->fmt = *mbus_fmt;
+ if (mbus_fmt->code != sensor->fmt.code)
sensor->pending_fmt_change = true;
- }
+
out:
mutex_unlock(>lock);
return ret;
--
2.7.4
Re: [PATCH v7 00/16] Intel IPU3 ImgU patchset
Hello Yong, On Tuesday, 30 October 2018 00:22:54 EET Yong Zhi wrote: > Hi, > > This series 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 11. > > All IPU3 pipeline default settings can be found in patch 10. > > To access DDR via ImgU's own memory space, IPU3 is also equipped with > its own MMU unit, the driver is implemented in patch 6. > > Patch 7 uses above driver for DMA mapping operation. > > The communication between IPU3 firmware and driver is implemented with > circular queues in patch 8. > > Patch 9 provide some utility functions and manage IPU3 fw download and > install. > > The firmware which is called ipu3-fw.bin can be downloaded from: > > git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git > (commit 2c27b0cb02f18c022d8378e0e1abaf8b7ae8188f) > > Firmware ABI is defined in patches 4 and 5. > > Patches 12 and 13 are of the same file, the former contains all h/w > programming related code, the latter implements interface functions for > access fw & hw capabilities. > > Patch 14 has a dependency on Sakari's V4L2_BUF_TYPE_META_OUTPUT work: > > https://patchwork.kernel.org/patch/9976295/> > > Patch 15 represents the top level that glues all of the other components > together, passing arguments between the components. > > Patch 16 is a recent effort to extend v6 for advanced camera features like > Continuous View Finder (CVF) and Snapshot During Video(SDV) support. > > Link to user space implementation: > > git clone https://chromium.googlesource.com/chromiumos/platform/arc-camera > > ImgU media topology print: [snip] > v4l2-compliance utility is built with Sakari's patches for meta data > output support(rebased): > > https://patchwork.linuxtv.org/patch/43370/> > https://patchwork.linuxtv.org/patch/43369/> > > The test (v4l2-compliance -m 0) passes without error, outputs are appended > at the end of revision history. > > Note: > > 1. Link pad flag of video nodes (i.e. ipu3-imgu 0 output) need to be enabled > prior to the test. > 2. Stream tests are not performed since it requires pre-configuration for > each case. And that's a bit of an issue. I've tested the driver with a small script based on media-ctl to configure links and yavta to interface with the video nodes, and got the following oops: [ 136.927788] divide error: [#1] PREEMPT SMP PTI [ 136.927801] CPU: 2 PID: 2069 Comm: yavta Not tainted 4.20.0-rc1+ #9 [ 136.927806] Hardware name: HP Soraka/Soraka, BIOS 08/30/2018 [ 136.927820] RIP: 0010:ipu3_css_osys_calc+0xc54/0xe14 [ipu3_imgu] [ 136.927825] Code: 89 44 24 28 42 8b 44 86 6c f7 54 24 04 81 64 24 28 00 fd ff ff 81 64 24 04 00 03 00 00 8d 44 03 ff 81 44 24 28 80 03 00 00 99 fb 0f af c3 bb 20 00 00 00 99 f7 fb 8b 5c 24 40 83 fd 01 19 d2 [ 136.927830] RSP: 0018:9af2c0b837c8 EFLAGS: 00010202 [ 136.927835] RAX: RBX: RCX: 9af2c3e353c0 [ 136.927839] RDX: RSI: 9af2c0b838e0 RDI: 9af2c3e353c0 [ 136.927843] RBP: 0001 R08: R09: 9af2c0b83880 [ 136.927846] R10: 9af2c3e353c0 R11: 9af2c3e357c0 R12: 03a0 [ 136.927849] R13: 00025a0a R14: R15: [ 136.927854] FS: 7f1eca167700() GS:8c19fab0() knlGS: [ 136.927858] CS: 0010 DS: ES: CR0: 80050033 [ 136.927862] CR2: 7f1ec776c000 CR3: 0001312a4003 CR4: 003606e0 [ 136.927865] Call Trace: [ 136.927884] ? __accumulate_pelt_segments+0x29/0x3a [ 136.927892] ? __switch_to_asm+0x40/0x70 [ 136.927899] ?
Re: [PATCH] media: venus: Support V4L2 QP parameters in Venus encoder
Hi Kelvin,
Thanks for the patch!
On 11/12/18 12:59 PM, Kelvin Lawson wrote:
> Support V4L2 QP parameters in Venus encoder:
> * V4L2_CID_MPEG_VIDEO_H264_I_FRAME_QP
> * V4L2_CID_MPEG_VIDEO_H264_B_FRAME_QP
> * V4L2_CID_MPEG_VIDEO_H264_MIN_QP
> * V4L2_CID_MPEG_VIDEO_H264_MAX_QP
>
> Signed-off-by: Kelvin Lawson
> ---
> drivers/media/platform/qcom/venus/venc.c | 19 +++
> 1 file changed, 19 insertions(+)
As functional changes the patch is fine, but it has many coding style
issues. Did you read [1]?
>
> diff --git a/drivers/media/platform/qcom/venus/venc.c
> b/drivers/media/platform/qcom/venus/venc.c
> index ce85962..321d612 100644
> --- a/drivers/media/platform/qcom/venus/venc.c
> +++ b/drivers/media/platform/qcom/venus/venc.c
> @@ -651,6 +651,8 @@ static int venc_set_properties(struct venus_inst *inst)
> struct hfi_framerate frate;
> struct hfi_bitrate brate;
> struct hfi_idr_period idrp;
> + struct hfi_quantization quant;
> + struct hfi_quantization_range quant_range;
> u32 ptype, rate_control, bitrate, profile = 0, level = 0;
> int ret;
>
> @@ -770,6 +772,23 @@ static int venc_set_properties(struct venus_inst *inst)
> if (ret)
> return ret;
>
> + ptype = HFI_PROPERTY_PARAM_VENC_SESSION_QP;
> + quant.qp_i = ctr->h264_i_qp;
> + quant.qp_p = ctr->h264_p_qp;
> + quant.qp_b = ctr->h264_b_qp;
> + quant.layer_id = 0;
> + ret = hfi_session_set_property(inst, ptype, );
> + if (ret)
> + return ret;
please fix the indentation according to coding style
> +
> + ptype = HFI_PROPERTY_PARAM_VENC_SESSION_QP_RANGE;
> + quant_range.min_qp = ctr->h264_min_qp;
> + quant_range.max_qp = ctr->h264_max_qp;
> + quant_range.layer_id = 0;
> + ret = hfi_session_set_property(inst, ptype, _range);
> + if (ret)
> + return ret;
ditto
> +
> if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_H264) {
> profile = venc_v4l2_to_hfi(V4L2_CID_MPEG_VIDEO_H264_PROFILE,
> ctr->profile.h264);
>
Maybe your mail server is mangling the patches, but also please run
checkpatch before sending patches.
--
regards,
Stan
[1] https://www.kernel.org/doc/html/v4.19/process/submitting-patches.html
[GIT PULL FOR v4.21] Various fixes/enhancements
The following changes since commit 708d75fe1c7c6e9abc5381b6fcc32b49830383d0: media: dvb-pll: don't re-validate tuner frequencies (2018-11-23 12:27:18 -0500) are available in the Git repository at: git://linuxtv.org/hverkuil/media_tree.git tags/br-v4.21g for you to fetch changes up to e5b4ae2f474785d61653e8fcb762427ee537e156: vicodec: move the GREY format to the end of the list (2018-11-29 10:09:18 +0100) Tag branch Alexey Khoroshilov (1): DaVinci-VPBE: fix error handling in vpbe_initialize() Arnd Bergmann (1): media: i2c: TDA1997x: select CONFIG_HDMI Colin Ian King (4): exynos4-is: fix spelling mistake ACTURATOR -> ACTUATOR media: dib0700: fix spelling mistake "Amplifyer" -> "Amplifier" media: em28xx: fix spelling mistake, "Cinnergy" -> "Cinergy" tda7432: fix spelling mistake "maximium" -> "maximum" Hans Verkuil (3): vivid: fix smatch warnings vivid: add req_validate error injection vicodec: move the GREY format to the end of the list Jasmin Jessich (1): media: adv7604 added include of linux/interrupt.h Jonas Karlman (1): media: v4l: Fix MPEG-2 slice Intra DC Precision validation Michael Tretter (2): v4l2-pci-skeleton: replace vb2_buffer with vb2_v4l2_buffer v4l2-pci-skeleton: depend on CONFIG_SAMPLES Sakari Ailus (1): v4l: ioctl: Allow drivers to fill in the format description Tim Harvey (1): media: adv7180: add g_skip_frames support Todor Tomov (1): media: camss: Take in account sensor skip frames Tomasz Figa (1): media: mtk-vcodec: Remove VA from encoder frame buffers Documentation/media/v4l-drivers/em28xx-cardlist.rst | 2 +- drivers/media/i2c/Kconfig | 1 + drivers/media/i2c/adv7180.c | 15 +++ drivers/media/i2c/adv7604.c | 1 + drivers/media/i2c/tda7432.c | 4 ++-- drivers/media/platform/davinci/vpbe.c | 7 +-- drivers/media/platform/exynos4-is/fimc-is-errno.c | 4 ++-- drivers/media/platform/exynos4-is/fimc-is-errno.h | 2 +- drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 6 +- drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 5 + drivers/media/platform/mtk-vcodec/venc_drv_if.h | 2 +- drivers/media/platform/qcom/camss/camss-vfe.c | 23 ++- drivers/media/platform/qcom/camss/camss.c | 2 +- drivers/media/platform/qcom/camss/camss.h | 1 + drivers/media/platform/vicodec/codec-v4l2-fwht.c| 3 +-- drivers/media/platform/vivid/vivid-core.c | 37 ++--- drivers/media/platform/vivid/vivid-core.h | 2 ++ drivers/media/platform/vivid/vivid-ctrls.c | 16 drivers/media/usb/dvb-usb/dib0700_devices.c | 2 +- drivers/media/usb/em28xx/em28xx-cards.c | 2 +- drivers/media/v4l2-core/Kconfig | 1 + drivers/media/v4l2-core/v4l2-ctrls.c| 3 ++- drivers/media/v4l2-core/v4l2-ioctl.c| 2 +- samples/v4l/v4l2-pci-skeleton.c | 11 ++- 24 files changed, 116 insertions(+), 38 deletions(-)
[PATCHv2] videodev2.h: add V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF/CREATE_BUFS
Add new buffer capability flags to indicate if the VIDIOC_PREPARE_BUF or
VIDIOC_CREATE_BUFS ioctls are supported.
The reason for this is that there is currently no way for an application
to detect if VIDIOC_PREPARE_BUF is implemented other than trying it, but
then the buffer is already prepared. You would like to know this before
taking an irreversible action.
Since we need V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF it makes sense to add
V4L2_BUF_CAP_SUPPORTS_CREATE_BUFS as well because not all drivers support
this ioctl.
Signed-off-by: Hans Verkuil
Acked-by: Sakari Ailus
---
Changes since v1:
- rebased
- improved commit msg
- added missing include for media/v4l2-ioctl.h
---
Documentation/media/uapi/v4l/vidioc-reqbufs.rst | 8
drivers/media/common/videobuf2/videobuf2-v4l2.c | 15 +--
include/uapi/linux/videodev2.h | 12 +++-
3 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
index e62a15782790..092d6373380a 100644
--- a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
+++ b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
@@ -118,6 +118,8 @@ aborting or finishing any DMA in progress, an implicit
.. _V4L2-BUF-CAP-SUPPORTS-DMABUF:
.. _V4L2-BUF-CAP-SUPPORTS-REQUESTS:
.. _V4L2-BUF-CAP-SUPPORTS-ORPHANED-BUFS:
+.. _V4L2-BUF-CAP-SUPPORTS-PREPARE-BUF:
+.. _V4L2-BUF-CAP-SUPPORTS-CREATE-BUFS:
.. cssclass:: longtable
@@ -143,6 +145,12 @@ aborting or finishing any DMA in progress, an implicit
- The kernel allows calling :ref:`VIDIOC_REQBUFS` while buffers are still
mapped or exported via DMABUF. These orphaned buffers will be freed
when they are unmapped or when the exported DMABUF fds are closed.
+* - ``V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF``
+ - 0x0020
+ - This buffer type supports :ref:`VIDIOC_PREPARE_BUF`.
+* - ``V4L2_BUF_CAP_SUPPORTS_CREATE_BUFS``
+ - 0x0040
+ - This buffer type supports :ref:`VIDIOC_CREATE_BUFS`.
Return Value
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 1244c246d0c4..5273f574fb7a 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -870,6 +871,16 @@ static inline bool vb2_queue_is_busy(struct video_device
*vdev, struct file *fil
return vdev->queue->owner && vdev->queue->owner != file->private_data;
}
+static void fill_buf_caps_vdev(struct video_device *vdev, u32 *caps)
+{
+ *caps = 0;
+ fill_buf_caps(vdev->queue, caps);
+ if (vdev->ioctl_ops->vidioc_prepare_buf)
+ *caps |= V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF;
+ if (vdev->ioctl_ops->vidioc_create_bufs)
+ *caps |= V4L2_BUF_CAP_SUPPORTS_CREATE_BUFS;
+}
+
/* vb2 ioctl helpers */
int vb2_ioctl_reqbufs(struct file *file, void *priv,
@@ -878,7 +889,7 @@ int vb2_ioctl_reqbufs(struct file *file, void *priv,
struct video_device *vdev = video_devdata(file);
int res = vb2_verify_memory_type(vdev->queue, p->memory, p->type);
- fill_buf_caps(vdev->queue, >capabilities);
+ fill_buf_caps_vdev(vdev, >capabilities);
if (res)
return res;
if (vb2_queue_is_busy(vdev, file))
@@ -900,7 +911,7 @@ int vb2_ioctl_create_bufs(struct file *file, void *priv,
p->format.type);
p->index = vdev->queue->num_buffers;
- fill_buf_caps(vdev->queue, >capabilities);
+ fill_buf_caps_vdev(vdev, >capabilities);
/*
* If count == 0, then just check if memory and type are valid.
* Any -EBUSY result from vb2_verify_memory_type can be mapped to 0.
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 2a223835214c..8ebc66e311e0 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -875,11 +875,13 @@ struct v4l2_requestbuffers {
};
/* capabilities for struct v4l2_requestbuffers and v4l2_create_buffers */
-#define V4L2_BUF_CAP_SUPPORTS_MMAP (1 << 0)
-#define V4L2_BUF_CAP_SUPPORTS_USERPTR (1 << 1)
-#define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
-#define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
-#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
+#define V4L2_BUF_CAP_SUPPORTS_MMAP (1 << 0)
+#define V4L2_BUF_CAP_SUPPORTS_USERPTR (1 << 1)
+#define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
+#define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
+#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS(1 << 4)
+#define V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF (1 << 5)
+#define V4L2_BUF_CAP_SUPPORTS_CREATE_BUFS (1 << 6)
/**
* struct v4l2_plane - plane info for multi-planar buffers
--
2.19.1
[GIT FIXES FOR v4.20] Various fixes
Hi Mauro, Some more fixes for 4.20. Four of these are related to the new Request API. Found after extending the Request API tests in v4l2-compliance. Most relate to a new test where I check what happens if STREAMON returns an error the first time it is called. v4l2-compliance now has code to detect that it is testing the vivid driver and it can now do error injection. It turned out that handling this error (STREAMON fails) has been broken since forever, both with and without the Request API. These patches fix this. The biggest change is "vb2: keep a reference to the request until dqbuf" which was discovered after I added a test where I close the request fd after the request was queued. Then the last reference to the request itself goes away when vb2_buffer_done() was called, but that requires the ability to use mutexes, and since that's not allowed from vb2_buffer_done (both because a spinlock is held and because it can be called from irq context) I got a BUG. So this required some more work to keep a request reference while vb2 owns the buffer. It all makes sense, but it takes a bit of time to figure it all out. Regards, Hans The following changes since commit 708d75fe1c7c6e9abc5381b6fcc32b49830383d0: media: dvb-pll: don't re-validate tuner frequencies (2018-11-23 12:27:18 -0500) are available in the Git repository at: git://linuxtv.org/hverkuil/media_tree.git tags/br-v4.20o for you to fetch changes up to 759683e3fa1695014690dfc5b22bbe09d55681e8: vicodec: set state resolution from raw format (2018-11-29 09:00:20 +0100) Tag branch Dan Carpenter (1): media: cedrus: Fix a NULL vs IS_ERR() check Hans Verkuil (6): vb2: don't call __vb2_queue_cancel if vb2_start_streaming failed vb2: skip request checks for VIDIOC_PREPARE_BUF vb2: keep a reference to the request until dqbuf vb2: don't unbind/put the object when going to state QUEUED vivid: drop v4l2_ctrl_request_complete() from start_streaming vicodec: set state resolution from raw format drivers/media/common/videobuf2/videobuf2-core.c | 44 +++- drivers/media/common/videobuf2/videobuf2-v4l2.c | 11 +++ drivers/media/platform/vicodec/vicodec-core.c | 13 ++--- drivers/media/platform/vivid/vivid-sdr-cap.c| 2 -- drivers/media/platform/vivid/vivid-vbi-cap.c| 2 -- drivers/media/platform/vivid/vivid-vbi-out.c| 2 -- drivers/media/platform/vivid/vivid-vid-cap.c| 2 -- drivers/media/platform/vivid/vivid-vid-out.c| 2 -- drivers/staging/media/sunxi/cedrus/cedrus_hw.c | 4 ++-- include/media/videobuf2-core.h | 2 ++ 10 files changed, 56 insertions(+), 28 deletions(-)
