cron job: media_tree daily build: ERRORS

2018-12-07 Thread Hans Verkuil
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:   Sat Dec  8 05:00:14 CET 2018
media-tree git hash:e159b6074c82fe31b79aad672e02fa204dbbc6d8
media_build git hash:   4b9237c73e29ea969f6a7b3d00030e14be50
v4l-utils git hash: 516595495957cbc18b578e6c1598bec21858b4e5
edid-decode git hash:   6def7bc83dfb0338632e06a8b14c93faa6af8879
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-3-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: ERRORS
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: ERRORS
linux-3.10.108-x86_64: ERRORS
linux-3.11.10-i686: ERRORS
linux-3.11.10-x86_64: ERRORS
linux-3.12.74-i686: ERRORS
linux-3.12.74-x86_64: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.79-i686: ERRORS
linux-3.14.79-x86_64: ERRORS
linux-3.15.10-i686: ERRORS
linux-3.15.10-x86_64: ERRORS
linux-3.16.57-i686: ERRORS
linux-3.16.57-x86_64: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.123-i686: ERRORS
linux-3.18.123-x86_64: ERRORS
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: ERRORS
linux-4.1.52-x86_64: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.159-i686: ERRORS
linux-4.4.159-x86_64: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.10-i686: ERRORS
linux-4.7.10-x86_64: ERRORS
linux-4.8.17-i686: ERRORS
linux-4.8.17-x86_64: ERRORS
linux-4.9.131-i686: ERRORS
linux-4.9.131-x86_64: ERRORS
linux-4.10.17-i686: ERRORS
linux-4.10.17-x86_64: ERRORS
linux-4.11.12-i686: ERRORS
linux-4.11.12-x86_64: ERRORS
linux-4.12.14-i686: ERRORS
linux-4.12.14-x86_64: ERRORS
linux-4.13.16-i686: ERRORS
linux-4.13.16-x86_64: ERRORS
linux-4.14.74-i686: ERRORS
linux-4.14.74-x86_64: ERRORS
linux-4.15.18-i686: ERRORS
linux-4.15.18-x86_64: ERRORS
linux-4.16.18-i686: ERRORS
linux-4.16.18-x86_64: ERRORS
linux-4.17.19-i686: ERRORS
linux-4.17.19-x86_64: ERRORS
linux-4.18.12-i686: ERRORS
linux-4.18.12-x86_64: ERRORS
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/Saturday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html


Re: [PATCH v2] [RFC v2] v4l2: add support for colorspace conversion for video capture

2018-12-07 Thread Hans Verkuil
On 12/07/2018 03:30 PM, Mauro Carvalho Chehab wrote:
> Em Thu, 6 Sep 2018 11:02:28 +0200
> Hans Verkuil  escreveu:
> 
>> Hi Philipp,
>>
>> It is much appreciated that this old RFC of mine is picked up again.
>> I always wanted to get this in, but I never had a driver where it would
>> make sense to do so.
> 
> What's the status of this?

Changes were requested, and there was some discussion. I'm basically
waiting for an update.

I've delegated it to me.

Regards,

Hans

> 
> Hans,
> As this is an old RFC from you, I'll delegate it to you at patchwork,
> for you to track it.
> 
> Regards,
> Mauro
> 
>>
>> On 09/05/2018 07:09 PM, Philipp Zabel wrote:
>>> For video capture it is the driver that reports the colorspace,  
>>
>> add: "transfer function,"
>>
>>> Y'CbCr/HSV encoding and quantization range used by the video, and there
>>> is no way to request something different, even though many HDTV
>>> receivers have some sort of colorspace conversion capabilities.
>>>
>>> For output video this feature already exists since the application
>>> specifies this information for the video format it will send out, and
>>> the transmitter will enable any available CSC if a format conversion has
>>> to be performed in order to match the capabilities of the sink.
>>>
>>> For video capture we propose adding new pix_format flags:
>>> V4L2_PIX_FMT_FLAG_CSC_COLORSPACE, V4L2_PIX_FMT_FLAG_CSC_YCBCR_ENC,
>>> V4L2_PIX_FMT_FLAG_CSC_HSV_ENC, V4L2_PIX_FMT_FLAG_CSC_QUANTIZATION, and
>>> V4L2_PIX_FMT_FLAG_CSC_XFER_FUNC. These are set by the driver to indicate
>>> its conversion features. When set by the application, the driver will
>>> interpret the colorspace, ycbcr_enc/hsv_enc, quantization and xfer_func
>>> fields as the requested colorspace information and will attempt to do
>>> the conversion it supports.
>>>
>>> Drivers do not have to actually look at the flags: if the flags are not
>>> set, then the colorspace, ycbcr_enc and quantization fields are set to
>>> the default values by the core, i.e. just pass on the received format
>>> without conversion.  
>>
>> Thinking about this some more, I don't think this is quite the right 
>> approach.
>> Having userspace set these flags with S_FMT if they want to do explicit
>> conversions makes sense, and that part we can keep.
>>
>> But to signal the capabilities I think should be done via new flags for
>> VIDIOC_ENUM_FMT. Basically the same set of flags, but for the flags field
>> of struct v4l2_fmtdesc.
>>
>> One thing that's not clear to me is what happens if userspace sets one or
>> more flags and calls S_FMT for a driver that doesn't support this. Are the
>> flags zeroed in that case upon return? I don't think so, but I think that
>> is already true for the existing flag V4L2_PIX_FMT_FLAG_PREMUL_ALPHA.
>>
>> I wonder if V4L2_PIX_FMT_FLAG_PREMUL_ALPHA should also get an equivalent
>> flag for v4l2_fmtdesc.
>>
>> Then we can just document that v4l2_format flags are only valid if they
>> are also defined in v4l2_fmtdesc.
>>
>> Does anyone have better ideas for this?
>>
>> Regards,
>>
>>  Hans
>>
>>>
>>> Signed-off-by: Hans Verkuil 
>>> Signed-off-by: Philipp Zabel 
>>> ---
>>> Changes since v1 [1]
>>>  - convert to rst
>>>  - split V4L2_PIX_FMT_FLAG_REQUEST_CSC into four separate flags for
>>>colorspace, ycbcr_enc/hsv_enc, quantization, and xfer_func
>>>  - let driver set flags to indicate supported features
>>>
>>> [1] https://patchwork.linuxtv.org/patch/28847/
>>> ---
>>>  .../media/uapi/v4l/pixfmt-reserved.rst| 41 +++
>>>  .../media/uapi/v4l/pixfmt-v4l2-mplane.rst | 16 ++--
>>>  Documentation/media/uapi/v4l/pixfmt-v4l2.rst  | 37 ++---
>>>  drivers/media/v4l2-core/v4l2-ioctl.c  | 12 ++
>>>  include/uapi/linux/videodev2.h|  5 +++
>>>  5 files changed, 94 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/Documentation/media/uapi/v4l/pixfmt-reserved.rst 
>>> b/Documentation/media/uapi/v4l/pixfmt-reserved.rst
>>> index 38af1472a4b4..c1090027626c 100644
>>> --- a/Documentation/media/uapi/v4l/pixfmt-reserved.rst
>>> +++ b/Documentation/media/uapi/v4l/pixfmt-reserved.rst
>>> @@ -261,3 +261,44 @@ please make a proposal on the linux-media mailing list.
>>> by RGBA values (128, 192, 255,

Re: [PATCH v5 00/12] imx-media: Fixes for interlaced capture

2018-12-07 Thread Hans Verkuil
Hi Steve,

How to proceed with this w.r.t. the two gpu ipu patches? Are those going
in first through the gpu tree? Or do they have to go in through our tree?

In that case I need Acks from whoever maintains that code.

Regards,

Hans

On 10/17/2018 02:00 AM, Steve Longerbeam wrote:
> A set of patches that fixes some bugs with capturing from an
> interlaced source, and incompatibilites between IDMAC interlace
> interweaving and 4:2:0 data write reduction.
> 
> History:
> v5:
> - Added a regression fix to allow empty endpoints to CSI (fix for imx6q
>   SabreAuto).
> - Cleaned up some convoluted code in ipu_csi_init_interface(), suggested
>   by Philipp Zabel.
> - Fixed a regression in csi_setup(), caught by Philipp.
> - Removed interweave_offset and replace with boolean interweave_swap,
>   suggested by Philipp.
> - Make clear that it is IDMAC channel that does pixel reordering and
>   interweave, not the CSI, in the imx.rst doc, caught by Philipp.
> 
> v4:
> - rebased to latest media-tree master branch.
> - Make patch author and SoB email addresses the same.
> 
> v3:
> - add support for/fix interweaved scan with YUV planar output.
> - fix bug in 4:2:0 U/V offset macros.
> - add patch that generalizes behavior of field swap in
>   ipu_csi_init_interface().
> - add support for interweaved scan with field order swap.
>   Suggested by Philipp Zabel.
> - in v2, inteweave scan was determined using field types of
>   CSI (and PRPENCVF) at the sink and source pads. In v3, this
>   has been moved one hop downstream: interweave is now determined
>   using field type at source pad, and field type selected at
>   capture interface. Suggested by Philipp.
> - make sure to double CSI crop target height when input field
>   type in alternate.
> - more updates to media driver doc to reflect above.
> 
> v2:
> - update media driver doc.
> - enable idmac interweave only if input field is sequential/alternate,
>   and output field is 'interlaced*'.
> - move field try logic out of *try_fmt and into separate function.
> - fix bug with resetting crop/compose rectangles.
> - add a patch that fixes a field order bug in VDIC indirect mode.
> - remove alternate field type from V4L2_FIELD_IS_SEQUENTIAL() macro
>   Suggested-by: Nicolas Dufresne .
> - add macro V4L2_FIELD_IS_INTERLACED().
> 
> 
> Steve Longerbeam (12):
>   media: videodev2.h: Add more field helper macros
>   gpu: ipu-csi: Swap fields according to input/output field types
>   gpu: ipu-v3: Add planar support to interlaced scan
>   media: imx: Fix field negotiation
>   media: imx-csi: Input connections to CSI should be optional
>   media: imx-csi: Double crop height for alternate fields at sink
>   media: imx: interweave and odd-chroma-row skip are incompatible
>   media: imx-csi: Allow skipping odd chroma rows for YVU420
>   media: imx: vdic: rely on VDIC for correct field order
>   media: imx-csi: Move crop/compose reset after filling default mbus
> fields
>   media: imx: Allow interweave with top/bottom lines swapped
>   media: imx.rst: Update doc to reflect fixes to interlaced capture
> 
>  Documentation/media/v4l-drivers/imx.rst   | 103 +++
>  drivers/gpu/ipu-v3/ipu-cpmem.c|  26 ++-
>  drivers/gpu/ipu-v3/ipu-csi.c  | 119 +
>  drivers/staging/media/imx/imx-ic-prpencvf.c   |  46 +++--
>  drivers/staging/media/imx/imx-media-capture.c |  14 ++
>  drivers/staging/media/imx/imx-media-csi.c | 168 +-
>  drivers/staging/media/imx/imx-media-vdic.c|  12 +-
>  include/uapi/linux/videodev2.h|   7 +
>  include/video/imx-ipu-v3.h|   6 +-
>  9 files changed, 354 insertions(+), 147 deletions(-)
> 



Re: [RFC PATCH] media/Kconfig: always enable MEDIA_CONTROLLER and VIDEO_V4L2_SUBDEV_API

2018-12-07 Thread Hans Verkuil
On 12/07/2018 01:42 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 7 Dec 2018 12:47:24 +0100
> Hans Verkuil  escreveu:
> 
>> On 12/07/2018 12:26 PM, Mauro Carvalho Chehab wrote:
>>> Em Fri, 7 Dec 2018 10:09:04 +0100
>>> Hans Verkuil  escreveu:
>>>   
>>>> This patch selects MEDIA_CONTROLLER for all camera, analog TV and
>>>> digital TV drivers and selects VIDEO_V4L2_SUBDEV_API automatically.
>>>>
>>>> This will allow us to simplify drivers that currently have to add
>>>> #ifdef CONFIG_MEDIA_CONTROLLER or #ifdef VIDEO_V4L2_SUBDEV_API
>>>> to their code, since now this will always be available.
>>>>
>>>> The original intent of allowing these to be configured by the
>>>> user was (I think) to save a bit of memory.   
>>>
>>> No. The original intent was/is to be sure that adding the media
>>> controller support won't be breaking existing working drivers.  
>>
>> That doesn't make sense. If enabling this option would break existing
>> drivers, then something is really wrong, isn't it?
> 
> It is the opposite: disabling it should not break any driver that don't
> depend on them to work.
> 
>>
>>>   
>>>> But as more and more
>>>> drivers have a media controller and all regular distros already
>>>> enable one or more of those drivers, the memory for the MC code is
>>>> there anyway.
>>>>
>>>> Complexity has always been the bane of media drivers, so reducing
>>>> complexity at the expense of a bit more memory (which is a rounding
>>>> error compared to the amount of video buffer memory needed) is IMHO
>>>> a good thing.
>>>>
>>>> Signed-off-by: Hans Verkuil 
>>>> ---
>>>> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
>>>> index 8add62a18293..56eb01cc8bb4 100644
>>>> --- a/drivers/media/Kconfig
>>>> +++ b/drivers/media/Kconfig
>>>> @@ -31,6 +31,7 @@ comment "Multimedia core support"
>>>>  #
>>>>  config MEDIA_CAMERA_SUPPORT
>>>>bool "Cameras/video grabbers support"
>>>> +  select MEDIA_CONTROLLER
>>>>---help---
>>>>  Enable support for webcams and video grabbers.
>>>>
>>>> @@ -38,6 +39,7 @@ config MEDIA_CAMERA_SUPPORT
>>>>
>>>>  config MEDIA_ANALOG_TV_SUPPORT
>>>>bool "Analog TV support"
>>>> +  select MEDIA_CONTROLLER
>>>>---help---
>>>>  Enable analog TV support.
>>>>
>>>> @@ -50,6 +52,7 @@ config MEDIA_ANALOG_TV_SUPPORT
>>>>
>>>>  config MEDIA_DIGITAL_TV_SUPPORT
>>>>bool "Digital TV support"
>>>> +  select MEDIA_CONTROLLER
>>>>---help---
>>>>  Enable digital TV support.  
>>>
>>> See my comments below.
>>>   
>>>>
>>>> @@ -95,7 +98,6 @@ source "drivers/media/cec/Kconfig"
>>>>
>>>>  config MEDIA_CONTROLLER
>>>>bool "Media Controller API"
>>>> -  depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || 
>>>> MEDIA_DIGITAL_TV_SUPPORT
>>>>---help---
>>>>  Enable the media controller API used to query media devices internal
>>>>  topology and configure it dynamically.  
>>>
>>> I have split comments with regards to it. Yeah, nowadays media controller
>>> has becoming more important. Still, a lot of media drivers work fine
>>> without them.
>>>
>>> Anyway, if we're willing to make it mandatory, better to just remove the
>>> entire config option or to make it a silent one.   
>>
>> Well, that assumes that the media controller will only be used by media
>> drivers, and not alsa or anyone else who wants to experiment with the MC.
>>
>> I won't object to making it silent (since it does reflect the current
>> situation), but since this functionality is not actually specific to media
>> drivers I think that is a good case to be made to allow it to be selected
>> manually.
>>
>>>   
>>>> @@ -119,16 +121,11 @@ config VIDEO_DEV
>>>>tristate
>>>>depends on MEDIA_SUPPORT
>>>>depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || 
>>>> MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT
>>>> +  select VIDEO_V4L2_SUBDEV_API if MEDIA_CONTROLLER
>>>>default y

Re: [PATCH v9 00/13] media: staging/imx7: add i.MX7 media driver

2018-12-07 Thread Hans Verkuil
On 11/22/2018 04:18 PM, Rui Miguel Silva wrote:
> Hi,
> This series introduces the Media driver to work with the i.MX7 SoC. it uses 
> the
> already existing imx media core drivers but since the i.MX7, contrary to
> i.MX5/6, do not have an IPU and because of that some changes in the imx media
> core are made along this series to make it support that case.
> 
> This patches adds CSI and MIPI-CSI2 drivers for i.MX7, along with several
> configurations changes for this to work as a capture subsystem. Some bugs are
> also fixed along the line. And necessary documentation.
> 
> For a more detailed view of the capture paths, pads links in the i.MX7 please
> take a look at the documentation in PATCH 10.
> 
> The system used to test and develop this was the Warp7 board with an OV2680
> sensor, which output format is 10-bit bayer. So, only MIPI interface was
> tested, a scenario with an parallel input would nice to have.

I got a few checkpatch warnings about coding style:

CHECK: Alignment should match open parenthesis
#953: FILE: drivers/staging/media/imx/imx7-media-csi.c:911:
+static struct v4l2_mbus_framefmt *imx7_csi_get_format(struct imx7_csi *csi,
+   struct v4l2_subdev_pad_config *cfg,

CHECK: Alignment should match open parenthesis
#1341: FILE: drivers/staging/media/imx/imx7-media-csi.c:1299:
+   ret = v4l2_async_register_fwnode_subdev(>sd,
+   sizeof(struct v4l2_async_subdev),

CHECK: Lines should not end with a '('
#684: FILE: drivers/staging/media/imx/imx7-mipi-csis.c:669:
+static struct csis_pix_format const *mipi_csis_try_format(

CHECK: Alignment should match open parenthesis
#708: FILE: drivers/staging/media/imx/imx7-mipi-csis.c:693:
+static struct v4l2_mbus_framefmt *mipi_csis_get_format(struct csi_state *state,
+   struct v4l2_subdev_pad_config *cfg,

CHECK: Alignment should match open parenthesis
#936: FILE: drivers/staging/media/imx/imx7-mipi-csis.c:921:
+   ret = v4l2_async_register_fwnode_subdev(mipi_sd,
+   sizeof(struct v4l2_async_subdev), _port, 1,

Apparently the latest coding style is that alignment is more important than
line length, although I personally do not agree. But since you need to
respin in any case due to the wrong SPDX identifier you used you might as
well take this into account.

I was really hoping I could merge this, but the SPDX license issue killed it.

Regards,

Hans

> 
> 
> Bellow goes an example of the output of the pads and links and the output of
> v4l2-compliance testing.
> 
> The v4l-utils version used is:
> v4l2-compliance SHA   : 044d5ab7b0d02683070d01a369c73d462d7a0cee from Nov 19th
> 
> The Media Driver fail some tests but this failures are coming from code out of
> scope of this series (imx-capture), and some from the sensor OV2680
> but that I think not related with the sensor driver but with the testing and
> core.
> 
> The csi and mipi-csi entities pass all compliance tests.
> 
> Cheers,
> Rui
> 
> v8->v9:
> Hans Verkuil:
>  - Fix issues detected by checkpatch strict, still some left:
>  - bigger kconfig option description
>  - some alignement parenthesis that were left as they are, to be more
>  readable 
>  - added new patch (PATCH13) for Maintainers update
>  - SPDX in documentation rst file
> Sakari Ailus:
>  - remove pad check in csi, this is done by core already
>  - destroy mutex in probe error path (add label)
>  - swap order in driver release
>  - initialize endpoint in stack
>  - use clk_bulk
> kbuild test robot:
>  - add the missing imx-media-dev-common.c in patch 1/13
>  - remove OWNER of module csis
> Myself:
>  - add MAINTAINERS entries - new patch
> 
> v7->v8:
> Myself:
>  - rebase to latest linux-next (s/V4L2_MBUS_CSI2/V4L2_MBUS_CSI2_DPHY/)
>  - Rebuild and test with latest v4l2-compliance
>  - add Sakari reviewed-by tag to dt-bindings
> 
> v6->v7:
> Myself:
>  - Clock patches removed from this version since they were already merged
>  - Rebuild and test with the latest v4l2-compliance
>  - Add patch to video-mux regarding bayer formats
>  - remove reference to dependent patch serie (was already merged)
> 
> Sakari Ailus:
>  - add port and endpoint explanantions
>  - fix some wording should -> shall
> 
> v5->v6:
> Rob Herring:
>  - rename power-domain node name from: pgc-power-domain to power-domain
>  - change mux-control-cells to 0
>  - remove bus-width from mipi bindings and dts
>  - remove err... regarding clock names line
>  - remove clk-settle from example
>  - split mipi-csi2 and csi bindings per file
>  - add OF graph description to CSI
> 
> Philipp Zabel:
>  - rework group IDs and renam

Re: [PATCH v9 05/13] media: dt-bindings: add bindings for i.MX7 media driver

2018-12-07 Thread Hans Verkuil
On 11/22/2018 04:18 PM, Rui Miguel Silva wrote:
> Add bindings documentation for i.MX7 media drivers.
> The imx7 MIPI CSI2 and imx7 CMOS Sensor Interface.
> 
> Signed-off-by: Rui Miguel Silva 
> Reviewed-by: Rob Herring 
> Acked-by: Sakari Ailus 

Please move this patch to the beginning of the series to avoid
checkpatch warnings:

WARNING: DT compatible string "fsl,imx7-csi" appears un-documented -- check 
./Documentation/devicetree/bindings/
#1378: FILE: drivers/staging/media/imx/imx7-media-csi.c:1336:
+   { .compatible = "fsl,imx7-csi" },

Thanks!

Hans


> ---
>  .../devicetree/bindings/media/imx7-csi.txt| 45 ++
>  .../bindings/media/imx7-mipi-csi2.txt | 90 +++
>  2 files changed, 135 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/imx7-csi.txt
>  create mode 100644 Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/imx7-csi.txt 
> b/Documentation/devicetree/bindings/media/imx7-csi.txt
> new file mode 100644
> index ..3c07bc676bc3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/imx7-csi.txt
> @@ -0,0 +1,45 @@
> +Freescale i.MX7 CMOS Sensor Interface
> +=
> +
> +csi node
> +
> +
> +This is device node for the CMOS Sensor Interface (CSI) which enables the 
> chip
> +to connect directly to external CMOS image sensors.
> +
> +Required properties:
> +
> +- compatible: "fsl,imx7-csi";
> +- reg   : base address and length of the register set for the device;
> +- interrupts: should contain CSI interrupt;
> +- clocks: list of clock specifiers, see
> +Documentation/devicetree/bindings/clock/clock-bindings.txt for 
> details;
> +- clock-names   : must contain "axi", "mclk" and "dcic" entries, matching
> + entries in the clock property;
> +
> +The device node shall contain one 'port' child node with one child 'endpoint'
> +node, according to the bindings defined in:
> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +In the following example a remote endpoint is a video multiplexer.
> +
> +example:
> +
> +csi: csi@3071 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +compatible = "fsl,imx7-csi";
> +reg = <0x3071 0x1>;
> +interrupts = ;
> +clocks = < IMX7D_CLK_DUMMY>,
> +< IMX7D_CSI_MCLK_ROOT_CLK>,
> +< IMX7D_CLK_DUMMY>;
> +clock-names = "axi", "mclk", "dcic";
> +
> +port {
> +csi_from_csi_mux: endpoint {
> +remote-endpoint = <_mux_to_csi>;
> +};
> +};
> +};
> diff --git a/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt 
> b/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
> new file mode 100644
> index ..71fd74ed3ec8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
> @@ -0,0 +1,90 @@
> +Freescale i.MX7 Mipi CSI2
> +=
> +
> +mipi_csi2 node
> +--
> +
> +This is the device node for the MIPI CSI-2 receiver core in i.MX7 SoC. It is
> +compatible with previous version of Samsung D-phy.
> +
> +Required properties:
> +
> +- compatible: "fsl,imx7-mipi-csi2";
> +- reg   : base address and length of the register set for the device;
> +- interrupts: should contain MIPI CSIS interrupt;
> +- clocks: list of clock specifiers, see
> +Documentation/devicetree/bindings/clock/clock-bindings.txt for 
> details;
> +- clock-names   : must contain "pclk", "wrap" and "phy" entries, matching
> +  entries in the clock property;
> +- power-domains : a phandle to the power domain, see
> +  Documentation/devicetree/bindings/power/power_domain.txt for 
> details.
> +- reset-names   : should include following entry "mrst";
> +- resets: a list of phandle, should contain reset entry of
> +  reset-names;
> +- phy-supply: from the generic phy bindings, a phandle to a regulator 
> that
> +   provides power to MIPI CSIS core;
> +
> +Optional properties:
> +
> +- clock-frequency : The IP's main (system bus) clock frequency in Hz, default
> + value when this property is not specified is 166 MHz;
> +- fsl,csis-hs-settle : differential receiver (HS-RX) settle time;
> +
> +The device node should contain two 'port' child nodes with one child 
> 'endpoint'
> +node, according to the bindings defined in:
> + Documentation/devicetree/bindings/ media/video-interfaces.txt.
> + The following are properties specific to those nodes.
> 

Re: [PATCH v9 01/13] media: staging/imx: refactor imx media device probe

2018-12-07 Thread Hans Verkuil
On 11/22/2018 04:18 PM, Rui Miguel Silva wrote:
> Refactor and move media device initialization code to a new common
> module, so it can be used by other devices, this will allow for example
> a near to introduce imx7 CSI driver, to use this media device.
> 
> Signed-off-by: Rui Miguel Silva 
> ---
>  drivers/staging/media/imx/Makefile|   1 +
>  .../staging/media/imx/imx-media-dev-common.c  | 102 ++
>  drivers/staging/media/imx/imx-media-dev.c |  88 ---
>  drivers/staging/media/imx/imx-media-of.c  |   6 +-
>  drivers/staging/media/imx/imx-media.h |  15 +++
>  5 files changed, 141 insertions(+), 71 deletions(-)
>  create mode 100644 drivers/staging/media/imx/imx-media-dev-common.c
> 
> diff --git a/drivers/staging/media/imx/Makefile 
> b/drivers/staging/media/imx/Makefile
> index 698a4210316e..a30b3033f9a3 100644
> --- a/drivers/staging/media/imx/Makefile
> +++ b/drivers/staging/media/imx/Makefile
> @@ -1,5 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0
>  imx-media-objs := imx-media-dev.o imx-media-internal-sd.o imx-media-of.o
> +imx-media-objs += imx-media-dev-common.o
>  imx-media-common-objs := imx-media-utils.o imx-media-fim.o
>  imx-media-ic-objs := imx-ic-common.o imx-ic-prp.o imx-ic-prpencvf.o
>  
> diff --git a/drivers/staging/media/imx/imx-media-dev-common.c 
> b/drivers/staging/media/imx/imx-media-dev-common.c
> new file mode 100644
> index ..55fe94fb72f2
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-media-dev-common.c
> @@ -0,0 +1,102 @@
> +// SPDX-License-Identifier: GPL

This is an invalid SPDX license identifier. You probably want to use GPL-2.0.

This happens in more patches, please check!

Regards,

Hans



[GIT PULL FOR v4.21] Various fixes/enhancements

2018-12-07 Thread Hans Verkuil
Note: there are a few patches that combine bindings with code changes.
But since these are older patches and the bindings have already been
reviewed I am not going to require the author to split them up. That's a
bit overkill.

If new patches arrive that have this problem, then I will request this
going forward.

Regards,

Hans

The following changes since commit 3c28b91380dd1183347d32d87d820818031ebecf:

  media: stkwebcam: Bugfix for wrong return values (2018-12-05 14:10:48 -0500)

are available in the Git repository at:

  git://linuxtv.org/hverkuil/media_tree.git tags/br-v4.21i

for you to fetch changes up to 54efad597804e6846ab860e7c2af84af529c669c:

  media: cedrus: Add device-tree compatible and variant for A64 support 
(2018-12-07 13:12:34 +0100)


Tag branch


Akinobu Mita (1):
  media: video-i2c: support runtime PM

Colin Ian King (2):
  media: pvrusb2: fix spelling mistake "statuss" -> "status"
  media: sun6i: fix spelling mistake "droped" -> "dropped"

Dmitry Osipenko (1):
  media: staging: tegra-vde: Replace debug messages with trace points

Ezequiel Garcia (1):
  v4l2-ioctl: Zero v4l2_plane_pix_format reserved fields

Gabriel Francisco Mandaji (1):
  media: vivid: Improve timestamping

Kelvin Lawson (1):
  media: venus: Support V4L2 QP parameters in Venus encoder

Lubomir Rintel (1):
  marvell-ccic: trivial fix to the datasheet URL

Luca Ceresoli (1):
  media: v4l2-subdev: document controls need _FL_HAS_DEVNODE

Malathi Gottam (1):
  media: venus: add support for key frame

Matt Ranostay (1):
  media: video-i2c: check if chip struct has set_power function

Paul Kocialkowski (4):
  media: cedrus: Remove global IRQ spin lock from the driver
  dt-bindings: media: cedrus: Add compatibles for the A64 and H5
  media: cedrus: Add device-tree compatible and variant for H5 support
  media: cedrus: Add device-tree compatible and variant for A64 support

Philipp Zabel (2):
  media: v4l2: clarify H.264 loop filter offset controls
  media: coda: fix H.264 deblocking filter controls

Rob Herring (2):
  media: Use of_node_name_eq for node name comparisons
  staging: media: imx: Use of_node_name_eq for node name comparisons

Sergei Shtylyov (2):
  rcar-csi2: add R8A77980 support
  rcar-vin: add R8A77980 support

Todor Tomov (1):
  MAINTAINERS: Change Todor Tomov's email address

Vivek Gautam (1):
  media: venus: core: Set dma maximum segment size

 Documentation/devicetree/bindings/media/cedrus.txt|   2 +
 Documentation/devicetree/bindings/media/rcar_vin.txt  |   1 +
 Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt |   1 +
 Documentation/media/uapi/v4l/extended-controls.rst|   6 ++
 MAINTAINERS   |   2 +-
 drivers/media/i2c/video-i2c.c | 153 
+-
 drivers/media/platform/coda/coda-bit.c|  19 ++--
 drivers/media/platform/coda/coda-common.c |  15 ++-
 drivers/media/platform/coda/coda.h|   6 +-
 drivers/media/platform/coda/coda_regs.h   |   2 +-
 drivers/media/platform/exynos4-is/media-dev.c |  12 +--
 drivers/media/platform/marvell-ccic/cafe-driver.c |   2 +-
 drivers/media/platform/qcom/venus/core.c  |   8 ++
 drivers/media/platform/qcom/venus/venc.c  |  19 
 drivers/media/platform/qcom/venus/venc_ctrls.c|  19 +++-
 drivers/media/platform/rcar-vin/rcar-core.c   |  32 ++
 drivers/media/platform/rcar-vin/rcar-csi2.c   |  11 ++
 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c  |   4 +-
 drivers/media/platform/ti-vpe/cal.c   |   4 +-
 drivers/media/platform/vivid/vivid-core.h |   3 +
 drivers/media/platform/vivid/vivid-kthread-cap.c  |  51 ++---
 drivers/media/platform/vivid/vivid-vbi-cap.c  |   4 -
 drivers/media/platform/xilinx/xilinx-tpg.c|   2 +-
 drivers/media/usb/pvrusb2/pvrusb2-hdw.c   |   2 +-
 drivers/media/v4l2-core/v4l2-fwnode.c |   6 +-
 drivers/media/v4l2-core/v4l2-ioctl.c  |  10 ++
 drivers/staging/media/imx/imx-media-of.c  |   2 +-
 drivers/staging/media/sunxi/cedrus/cedrus.c   |  17 ++-
 drivers/staging/media/sunxi/cedrus/cedrus.h   |   2 -
 drivers/staging/media/sunxi/cedrus/cedrus_dec.c   |   9 --
 drivers/staging/media/sunxi/cedrus/cedrus_hw.c|  13 +--
 drivers/staging/media/sunxi/cedrus/cedrus_video.c |   5 -
 

Re: [RFC PATCH] media/Kconfig: always enable MEDIA_CONTROLLER and VIDEO_V4L2_SUBDEV_API

2018-12-07 Thread Hans Verkuil
On 12/07/2018 12:26 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 7 Dec 2018 10:09:04 +0100
> Hans Verkuil  escreveu:
> 
>> This patch selects MEDIA_CONTROLLER for all camera, analog TV and
>> digital TV drivers and selects VIDEO_V4L2_SUBDEV_API automatically.
>>
>> This will allow us to simplify drivers that currently have to add
>> #ifdef CONFIG_MEDIA_CONTROLLER or #ifdef VIDEO_V4L2_SUBDEV_API
>> to their code, since now this will always be available.
>>
>> The original intent of allowing these to be configured by the
>> user was (I think) to save a bit of memory. 
> 
> No. The original intent was/is to be sure that adding the media
> controller support won't be breaking existing working drivers.

That doesn't make sense. If enabling this option would break existing
drivers, then something is really wrong, isn't it?

> 
>> But as more and more
>> drivers have a media controller and all regular distros already
>> enable one or more of those drivers, the memory for the MC code is
>> there anyway.
>>
>> Complexity has always been the bane of media drivers, so reducing
>> complexity at the expense of a bit more memory (which is a rounding
>> error compared to the amount of video buffer memory needed) is IMHO
>> a good thing.
>>
>> Signed-off-by: Hans Verkuil 
>> ---
>> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
>> index 8add62a18293..56eb01cc8bb4 100644
>> --- a/drivers/media/Kconfig
>> +++ b/drivers/media/Kconfig
>> @@ -31,6 +31,7 @@ comment "Multimedia core support"
>>  #
>>  config MEDIA_CAMERA_SUPPORT
>>  bool "Cameras/video grabbers support"
>> +select MEDIA_CONTROLLER
>>  ---help---
>>Enable support for webcams and video grabbers.
>>
>> @@ -38,6 +39,7 @@ config MEDIA_CAMERA_SUPPORT
>>
>>  config MEDIA_ANALOG_TV_SUPPORT
>>  bool "Analog TV support"
>> +select MEDIA_CONTROLLER
>>  ---help---
>>Enable analog TV support.
>>
>> @@ -50,6 +52,7 @@ config MEDIA_ANALOG_TV_SUPPORT
>>
>>  config MEDIA_DIGITAL_TV_SUPPORT
>>  bool "Digital TV support"
>> +select MEDIA_CONTROLLER
>>  ---help---
>>Enable digital TV support.
> 
> See my comments below.
> 
>>
>> @@ -95,7 +98,6 @@ source "drivers/media/cec/Kconfig"
>>
>>  config MEDIA_CONTROLLER
>>  bool "Media Controller API"
>> -depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || 
>> MEDIA_DIGITAL_TV_SUPPORT
>>  ---help---
>>Enable the media controller API used to query media devices internal
>>topology and configure it dynamically.
> 
> I have split comments with regards to it. Yeah, nowadays media controller
> has becoming more important. Still, a lot of media drivers work fine
> without them.
> 
> Anyway, if we're willing to make it mandatory, better to just remove the
> entire config option or to make it a silent one. 

Well, that assumes that the media controller will only be used by media
drivers, and not alsa or anyone else who wants to experiment with the MC.

I won't object to making it silent (since it does reflect the current
situation), but since this functionality is not actually specific to media
drivers I think that is a good case to be made to allow it to be selected
manually.

> 
>> @@ -119,16 +121,11 @@ config VIDEO_DEV
>>  tristate
>>  depends on MEDIA_SUPPORT
>>  depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || 
>> MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT
>> +select VIDEO_V4L2_SUBDEV_API if MEDIA_CONTROLLER
>>  default y
>>
>>  config VIDEO_V4L2_SUBDEV_API
>> -bool "V4L2 sub-device userspace API"
>> -depends on VIDEO_DEV && MEDIA_CONTROLLER
>> ----help---
>> -  Enables the V4L2 sub-device pad-level userspace API used to configure
>> -  video format, size and frame rate between hardware blocks.
>> -
>> -  This API is mostly used by camera interfaces in embedded platforms.
>> +bool
> 
> NACK. 
> 
> There is a very good reason why the subdev API is optional: there
> are drivers that use camera sensors but are not MC-centric. On those,
> the USB bridge driver is responsible to setup the subdevice. 
> 
> This options helps to ensure that camera sensors used by such drivers
> won't stop working because of the lack of the subdev-API.

But they won't stop working if this is enabled. This option is used as
a dependency by drivers that require this functionality, but enabling
it will never break other drivers that don't need this. Those drivers
simply won't use it.

Also note that it is the bridge driver that controls whether or not
the v4l-subdevX devices are created. If the bridge driver doesn't
explicitly enable it AND the subdev driver explicitly supports it,
those devices will not be created.

Regards,

Hans

> 
>>
>>  source "drivers/media/v4l2-core/Kconfig"
>>
> 
> 
> 
> Thanks,
> Mauro
> 



Re: [PATCH] media: cedrus: don't initialize pointers with zero

2018-12-07 Thread Hans Verkuil
On 12/07/2018 12:31 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 7 Dec 2018 12:14:50 +0100
> Hans Verkuil  escreveu:
> 
>> On 12/07/2018 11:56 AM, Mauro Carvalho Chehab wrote:
>>> A common mistake is to assume that initializing a var with:
>>> struct foo f = { 0 };
>>>
>>> Would initialize a zeroed struct. Actually, what this does is
>>> to initialize the first element of the struct to zero.
>>>
>>> According to C99 Standard 6.7.8.21:
>>>
>>> "If there are fewer initializers in a brace-enclosed
>>>  list than there are elements or members of an aggregate,
>>>  or fewer characters in a string literal used to initialize
>>>  an array of known size than there are elements in the array,
>>>  the remainder of the aggregate shall be initialized implicitly
>>>  the same as objects that have static storage duration."
>>>
>>> So, in practice, it could zero the entire struct, but, if the
>>> first element is not an integer, it will produce warnings:
>>>
>>> 
>>> drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49:
>>>   warning: Using plain integer as NULL pointer
>>> 
>>> drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35:
>>>   warning: Using plain integer as NULL pointer
>>>
>>> A proper way to initialize it with gcc is to use:
>>>
>>> struct foo f = { };
>>>
>>> But that seems to be a gcc extension. So, I decided to check upstream  
>>
>> No, this is not a gcc extension. It's part of the latest C standard.
> 
> Sure? Where the C standard spec states that? I've been seeking for
> such info for a while, as '= {}' is also my personal preference.

I believe it was added in C11, but I've loaned the book that stated
that to someone else, so I can't check.

In any case, it's used everywhere:

git grep '= *{ *}' drivers/

So it is really pointless to *not* use it.

Regards,

Hans

> I tried to build the Kernel with clang, just to be sure that this
> won't cause issues with the clang support, but, unfortunately, the
> clang compiler (not even the upstream version) is able to build
> the upstream Kernel yet, as it lacks asm-goto support (there is an
> OOT patch for llvm solving it - but it sounds too much effort for
> my time to have to build llvm from their sources just for a simple
> check like this).
> 
>> It's used all over in the kernel, so please use {} instead of { NULL }.
>>
>> Personally I think {} is a fantastic invention and I wish C++ had it as
>> well.
> 
> Fully agreed on that.
> 
>>
>> Regards,
>>
>>  Hans
>>
>>> what's the most commonly pattern. The gcc pattern has about 2000 entries:
>>>
>>> $ git grep -E "=\s*\{\s*\}"|wc -l
>>> 1951
>>>
>>> The standard-C compliant pattern has about 2500 entries:
>>>
>>> $ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l
>>> 137
>>> $ git grep -E "=\s*\{\s*0\s*\}"|wc -l
>>> 2323
>>>
>>> So, let's initialize those structs with:
>>>  = { NULL }
>>>
>>> Signed-off-by: Mauro Carvalho Chehab 
>>> ---
>>>  drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
>>>  drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 +-
>>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c 
>>> b/drivers/staging/media/sunxi/cedrus/cedrus.c
>>> index b538eb0321d8..44c45c687503 100644
>>> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
>>> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
>>> @@ -75,7 +75,7 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, 
>>> struct cedrus_ctx *ctx)
>>> memset(ctx->ctrls, 0, ctrl_size);
>>>  
>>> for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
>>> -   struct v4l2_ctrl_config cfg = { 0 };
>>> +   struct v4l2_ctrl_config cfg = { NULL };
>>>  
>>> cfg.elem_size = cedrus_controls[i].elem_size;
>>> cfg.id = cedrus_controls[i].id;
>>> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c 
>>> b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
>>> index e40180a33951..4099a42dba2d 100644
>>> --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
>>> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
>>> @@ -26,7 +26,7 @@ void cedrus_device_run(void *priv)
>>>  {
>>> struct cedrus_ctx *ctx = priv;
>>> struct cedrus_dev *dev = ctx->dev;
>>> -   struct cedrus_run run = { 0 };
>>> +   struct cedrus_run run = { NULL };
>>> struct media_request *src_req;
>>> unsigned long flags;
>>>  
>>>   
>>
> 
> 
> 
> Thanks,
> Mauro
> 



Re: [PATCH 4/5 RESEND] si470x-i2c: Add optional reset-gpio support

2018-12-07 Thread Hans Verkuil
Adding the actual author :-)

Regards,

Hans

On 12/07/2018 12:25 PM, Michael Nazzareno Trimarchi wrote:
> Hi
> 
> On Fri, Dec 7, 2018 at 12:12 PM Hans Verkuil  wrote:
>>
>> Subject: [PATCH 4/5] si470x-i2c: Add optional reset-gpio support
>> Date: Wed,  5 Dec 2018 16:47:49 +0100
>> From: Paweł Chmiel 
>> To: mche...@kernel.org, robh...@kernel.org, mark.rutl...@arm.com
>> CC: hverk...@xs4all.nl, fischerdougl...@gmail.com, keesc...@chromium.org, 
>> linux-media@vger.kernel.org, linux-ker...@vger.kernel.org,
>> devicet...@vger.kernel.org, Paweł Chmiel 
>>
>> If reset-gpio is defined, use it to bring device out of reset.
>> Without this, it's not possible to access si470x registers.
>>
>> Signed-off-by: Paweł Chmiel 
>> ---
>> For some reason this patch was not picked up by patchwork. Resending to see 
>> if
>> it is picked up now.
>> ---
>>  drivers/media/radio/si470x/radio-si470x-i2c.c | 15 +++
>>  drivers/media/radio/si470x/radio-si470x.h |  1 +
>>  2 files changed, 16 insertions(+)
>>
>> diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c 
>> b/drivers/media/radio/si470x/radio-si470x-i2c.c
>> index a7ac09c55188..15eea2b2c90f 100644
>> --- a/drivers/media/radio/si470x/radio-si470x-i2c.c
>> +++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
>> @@ -28,6 +28,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>   #include "radio-si470x.h"
>> @@ -392,6 +393,17 @@ static int si470x_i2c_probe(struct i2c_client *client,
>> radio->videodev.release = video_device_release_empty;
>> video_set_drvdata(>videodev, radio);
>>  +  radio->gpio_reset = devm_gpiod_get_optional(>dev, "reset",
>> +   GPIOD_OUT_LOW);
>> +   if (IS_ERR(radio->gpio_reset)) {
>> +   retval = PTR_ERR(radio->gpio_reset);
>> +   dev_err(>dev, "Failed to request gpio: %d\n", 
>> retval);
>> +   goto err_all;
>> +   }
>> +
>> +   if (radio->gpio_reset)
>> +   gpiod_set_value(radio->gpio_reset, 1);
>> +
>> /* power up : need 110ms */
>> radio->registers[POWERCFG] = POWERCFG_ENABLE;
>> if (si470x_set_register(radio, POWERCFG) < 0) {
>> @@ -478,6 +490,9 @@ static int si470x_i2c_remove(struct i2c_client *client)
>> video_unregister_device(>videodev);
>>  +  if (radio->gpio_reset)
>> +   gpiod_set_value(radio->gpio_reset, 0);
> 
> I have a question for you. If the gpio is the last of the bank
> acquired for this cpu, when you put to 0, then the gpio will
> be free on remove and the clock of the logic will be deactivated so I
> think that you don't have any
> garantee that the state will be 0
> 
> Michael
> 
>> +
>> return 0;
>>  }
>>  diff --git a/drivers/media/radio/si470x/radio-si470x.h 
>> b/drivers/media/radio/si470x/radio-si470x.h
>> index 35fa0f3bbdd2..6fd6a399cb77 100644
>> --- a/drivers/media/radio/si470x/radio-si470x.h
>> +++ b/drivers/media/radio/si470x/radio-si470x.h
>> @@ -189,6 +189,7 @@ struct si470x_device {
>>   #if IS_ENABLED(CONFIG_I2C_SI470X)
>> struct i2c_client *client;
>> +   struct gpio_desc *gpio_reset;
>>  #endif
>>  };
>>  -- 2.17.1
>>
> 
> 



Re: [PATCH v2 2/2] media: video-i2c: add Melexis MLX90640 thermal camera support

2018-12-07 Thread Hans Verkuil
On 11/22/2018 04:52 AM, Matt Ranostay wrote:
> Add initial support for MLX90640 thermal cameras which output an 32x24
> greyscale pixel image along with 2 rows of coefficent data.
> 
> Because of this the data outputed is really 32x26 and needs the two rows
> removed after using the coefficent information to generate processed
> images in userspace.
> 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Matt Ranostay 
> ---
>  .../bindings/media/i2c/melexis,mlx90640.txt   |  20 
>  drivers/media/i2c/Kconfig |   1 +
>  drivers/media/i2c/video-i2c.c | 110 +-
>  3 files changed, 130 insertions(+), 1 deletion(-)
>  create mode 100644 
> Documentation/devicetree/bindings/media/i2c/melexis,mlx90640.txt

This patch needs to be split up in two: one for the bindings, one for
the driver changes.

Once the bindings for the v3 of this patch are accepted, I can merge this.

Note that I am in the process of merging '[PATCH v3] media: video-i2c: check if 
chip
struct has set_power function', so it shouldn't be necessary to repost that 
patch.

Regards,

Hans

> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/melexis,mlx90640.txt 
> b/Documentation/devicetree/bindings/media/i2c/melexis,mlx90640.txt
> new file mode 100644
> index ..060d2b7a5893
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/melexis,mlx90640.txt
> @@ -0,0 +1,20 @@
> +* Melexis MLX90640 FIR Sensor
> +
> +Melexis MLX90640 FIR sensor support which allows recording of thermal data
> +with 32x24 resolution excluding 2 lines of coefficient data that is used by
> +userspace to render processed frames.
> +
> +Required Properties:
> + - compatible : Must be "melexis,mlx90640"
> + - reg : i2c address of the device
> +
> +Example:
> +
> + i2c0@1c22000 {
> + ...
> + mlx90640@33 {
> + compatible = "melexis,mlx90640";
> + reg = <0x33>;
> + };
> + ...
> + };
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 66bbbec487ec..24342f283f2a 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -1097,6 +1097,7 @@ config VIDEO_I2C
> Enable the I2C transport video support which supports the
> following:
>  * Panasonic AMG88xx Grid-Eye Sensors
> +* Melexis MLX90640 Thermal Cameras
>  
> To compile this driver as a module, choose M here: the
> module will be called video-i2c
> diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
> index a64e1a725a20..d58f40334e8b 100644
> --- a/drivers/media/i2c/video-i2c.c
> +++ b/drivers/media/i2c/video-i2c.c
> @@ -6,6 +6,7 @@
>   *
>   * Supported:
>   * - Panasonic AMG88xx Grid-Eye Sensors
> + * - Melexis MLX90640 Thermal Cameras
>   */
>  
>  #include 
> @@ -18,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -66,12 +68,26 @@ static const struct v4l2_frmsize_discrete amg88xx_size = {
>   .height = 8,
>  };
>  
> +static const struct v4l2_fmtdesc mlx90640_format = {
> + .pixelformat = V4L2_PIX_FMT_Y16_BE,
> +};
> +
> +static const struct v4l2_frmsize_discrete mlx90640_size = {
> + .width = 32,
> + .height = 26, /* 24 lines of pixel data + 2 lines of processing data */
> +};
> +
>  static const struct regmap_config amg88xx_regmap_config = {
>   .reg_bits = 8,
>   .val_bits = 8,
>   .max_register = 0xff
>  };
>  
> +static const struct regmap_config mlx90640_regmap_config = {
> + .reg_bits = 16,
> + .val_bits = 16,
> +};
> +
>  struct video_i2c_chip {
>   /* video dimensions */
>   const struct v4l2_fmtdesc *format;
> @@ -88,6 +104,7 @@ struct video_i2c_chip {
>   unsigned int bpp;
>  
>   const struct regmap_config *regmap_config;
> + struct nvmem_config *nvmem_config;
>  
>   /* setup function */
>   int (*setup)(struct video_i2c_data *data);
> @@ -102,6 +119,22 @@ struct video_i2c_chip {
>   int (*hwmon_init)(struct video_i2c_data *data);
>  };
>  
> +static int mlx90640_nvram_read(void *priv, unsigned int offset, void *val,
> +  size_t bytes)
> +{
> + struct video_i2c_data *data = priv;
> +
> + return regmap_bulk_read(data->regmap, 0x2400 + offset, val, bytes);
> +}
> +
> +static struct nvmem_config mlx90640_nvram_config = {
> + .name = "mlx90640_nvram",
> + .word_size = 2,
> + .stride = 1,
> + .size = 1664,
> + .reg_read = mlx90640_nvram_read,
> +};
> +
>  /* Power control register */
>  #define AMG88XX_REG_PCTL 0x00
>  #define AMG88XX_PCTL_NORMAL  0x00
> @@ -122,12 +155,23 @@ struct video_i2c_chip {
>  /* Temperature register */
>  #define AMG88XX_REG_T01L 0x80
>  
> +/* Control register */
> +#define MLX90640_REG_CTL10x800d
> +#define MLX90640_REG_CTL1_MASK   0x0380
> +#define MLX90640_REG_CTL1_MASK_SHIFT 7

Re: [PATCH] media: cedrus: don't initialize pointers with zero

2018-12-07 Thread Hans Verkuil
On 12/07/2018 11:56 AM, Mauro Carvalho Chehab wrote:
> A common mistake is to assume that initializing a var with:
>   struct foo f = { 0 };
> 
> Would initialize a zeroed struct. Actually, what this does is
> to initialize the first element of the struct to zero.
> 
> According to C99 Standard 6.7.8.21:
> 
> "If there are fewer initializers in a brace-enclosed
>  list than there are elements or members of an aggregate,
>  or fewer characters in a string literal used to initialize
>  an array of known size than there are elements in the array,
>  the remainder of the aggregate shall be initialized implicitly
>  the same as objects that have static storage duration."
> 
> So, in practice, it could zero the entire struct, but, if the
> first element is not an integer, it will produce warnings:
> 
>   
> drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49:
>   warning: Using plain integer as NULL pointer
>   
> drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35:
>   warning: Using plain integer as NULL pointer
> 
> A proper way to initialize it with gcc is to use:
> 
>   struct foo f = { };
> 
> But that seems to be a gcc extension. So, I decided to check upstream

No, this is not a gcc extension. It's part of the latest C standard.

It's used all over in the kernel, so please use {} instead of { NULL }.

Personally I think {} is a fantastic invention and I wish C++ had it as
well.

Regards,

Hans

> what's the most commonly pattern. The gcc pattern has about 2000 entries:
> 
>   $ git grep -E "=\s*\{\s*\}"|wc -l
>   1951
> 
> The standard-C compliant pattern has about 2500 entries:
> 
>   $ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l
>   137
>   $ git grep -E "=\s*\{\s*0\s*\}"|wc -l
>   2323
> 
> So, let's initialize those structs with:
>= { NULL }
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
>  drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c 
> b/drivers/staging/media/sunxi/cedrus/cedrus.c
> index b538eb0321d8..44c45c687503 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> @@ -75,7 +75,7 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct 
> cedrus_ctx *ctx)
>   memset(ctx->ctrls, 0, ctrl_size);
>  
>   for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
> - struct v4l2_ctrl_config cfg = { 0 };
> + struct v4l2_ctrl_config cfg = { NULL };
>  
>   cfg.elem_size = cedrus_controls[i].elem_size;
>   cfg.id = cedrus_controls[i].id;
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c 
> b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> index e40180a33951..4099a42dba2d 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> @@ -26,7 +26,7 @@ void cedrus_device_run(void *priv)
>  {
>   struct cedrus_ctx *ctx = priv;
>   struct cedrus_dev *dev = ctx->dev;
> - struct cedrus_run run = { 0 };
> + struct cedrus_run run = { NULL };
>   struct media_request *src_req;
>   unsigned long flags;
>  
> 



[PATCH 4/5 RESEND] si470x-i2c: Add optional reset-gpio support

2018-12-07 Thread Hans Verkuil
Subject: [PATCH 4/5] si470x-i2c: Add optional reset-gpio support
Date: Wed,  5 Dec 2018 16:47:49 +0100
From: Paweł Chmiel 
To: mche...@kernel.org, robh...@kernel.org, mark.rutl...@arm.com
CC: hverk...@xs4all.nl, fischerdougl...@gmail.com, keesc...@chromium.org, 
linux-media@vger.kernel.org, linux-ker...@vger.kernel.org,
devicet...@vger.kernel.org, Paweł Chmiel 

If reset-gpio is defined, use it to bring device out of reset.
Without this, it's not possible to access si470x registers.

Signed-off-by: Paweł Chmiel 
---
For some reason this patch was not picked up by patchwork. Resending to see if
it is picked up now.
---
 drivers/media/radio/si470x/radio-si470x-i2c.c | 15 +++
 drivers/media/radio/si470x/radio-si470x.h |  1 +
 2 files changed, 16 insertions(+)

diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c 
b/drivers/media/radio/si470x/radio-si470x-i2c.c
index a7ac09c55188..15eea2b2c90f 100644
--- a/drivers/media/radio/si470x/radio-si470x-i2c.c
+++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
  #include "radio-si470x.h"
@@ -392,6 +393,17 @@ static int si470x_i2c_probe(struct i2c_client *client,
radio->videodev.release = video_device_release_empty;
video_set_drvdata(>videodev, radio);
 +  radio->gpio_reset = devm_gpiod_get_optional(>dev, "reset",
+   GPIOD_OUT_LOW);
+   if (IS_ERR(radio->gpio_reset)) {
+   retval = PTR_ERR(radio->gpio_reset);
+   dev_err(>dev, "Failed to request gpio: %d\n", retval);
+   goto err_all;
+   }
+
+   if (radio->gpio_reset)
+   gpiod_set_value(radio->gpio_reset, 1);
+
/* power up : need 110ms */
radio->registers[POWERCFG] = POWERCFG_ENABLE;
if (si470x_set_register(radio, POWERCFG) < 0) {
@@ -478,6 +490,9 @@ static int si470x_i2c_remove(struct i2c_client *client)
video_unregister_device(>videodev);
 +  if (radio->gpio_reset)
+   gpiod_set_value(radio->gpio_reset, 0);
+
return 0;
 }
 diff --git a/drivers/media/radio/si470x/radio-si470x.h 
b/drivers/media/radio/si470x/radio-si470x.h
index 35fa0f3bbdd2..6fd6a399cb77 100644
--- a/drivers/media/radio/si470x/radio-si470x.h
+++ b/drivers/media/radio/si470x/radio-si470x.h
@@ -189,6 +189,7 @@ struct si470x_device {
  #if IS_ENABLED(CONFIG_I2C_SI470X)
struct i2c_client *client;
+   struct gpio_desc *gpio_reset;
 #endif
 };
 -- 2.17.1



[RFC PATCH] media/Kconfig: always enable MEDIA_CONTROLLER and VIDEO_V4L2_SUBDEV_API

2018-12-07 Thread Hans Verkuil
This patch selects MEDIA_CONTROLLER for all camera, analog TV and
digital TV drivers and selects VIDEO_V4L2_SUBDEV_API automatically.

This will allow us to simplify drivers that currently have to add
#ifdef CONFIG_MEDIA_CONTROLLER or #ifdef VIDEO_V4L2_SUBDEV_API
to their code, since now this will always be available.

The original intent of allowing these to be configured by the
user was (I think) to save a bit of memory. But as more and more
drivers have a media controller and all regular distros already
enable one or more of those drivers, the memory for the MC code is
there anyway.

Complexity has always been the bane of media drivers, so reducing
complexity at the expense of a bit more memory (which is a rounding
error compared to the amount of video buffer memory needed) is IMHO
a good thing.

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 8add62a18293..56eb01cc8bb4 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -31,6 +31,7 @@ comment "Multimedia core support"
 #
 config MEDIA_CAMERA_SUPPORT
bool "Cameras/video grabbers support"
+   select MEDIA_CONTROLLER
---help---
  Enable support for webcams and video grabbers.

@@ -38,6 +39,7 @@ config MEDIA_CAMERA_SUPPORT

 config MEDIA_ANALOG_TV_SUPPORT
bool "Analog TV support"
+   select MEDIA_CONTROLLER
---help---
  Enable analog TV support.

@@ -50,6 +52,7 @@ config MEDIA_ANALOG_TV_SUPPORT

 config MEDIA_DIGITAL_TV_SUPPORT
bool "Digital TV support"
+   select MEDIA_CONTROLLER
---help---
  Enable digital TV support.

@@ -95,7 +98,6 @@ source "drivers/media/cec/Kconfig"

 config MEDIA_CONTROLLER
bool "Media Controller API"
-   depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || 
MEDIA_DIGITAL_TV_SUPPORT
---help---
  Enable the media controller API used to query media devices internal
  topology and configure it dynamically.
@@ -119,16 +121,11 @@ config VIDEO_DEV
tristate
depends on MEDIA_SUPPORT
depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || 
MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT
+   select VIDEO_V4L2_SUBDEV_API if MEDIA_CONTROLLER
default y

 config VIDEO_V4L2_SUBDEV_API
-   bool "V4L2 sub-device userspace API"
-   depends on VIDEO_DEV && MEDIA_CONTROLLER
-   ---help---
- Enables the V4L2 sub-device pad-level userspace API used to configure
- video format, size and frame rate between hardware blocks.
-
- This API is mostly used by camera interfaces in embedded platforms.
+   bool

 source "drivers/media/v4l2-core/Kconfig"



cron job: media_tree daily build: ERRORS

2018-12-06 Thread Hans Verkuil
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 Dec  7 05:00:15 CET 2018
media-tree git hash:3c28b91380dd1183347d32d87d820818031ebecf
media_build git hash:   4b9237c73e29ea969f6a7b3d00030e14be50
v4l-utils git hash: 7086a1ee8dda5ae34852379410432d259215ff5e
edid-decode git hash:   6def7bc83dfb0338632e06a8b14c93faa6af8879
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: ERRORS
linux-3.10.108-x86_64: ERRORS
linux-3.11.10-i686: ERRORS
linux-3.11.10-x86_64: ERRORS
linux-3.12.74-i686: ERRORS
linux-3.12.74-x86_64: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.79-i686: ERRORS
linux-3.14.79-x86_64: ERRORS
linux-3.15.10-i686: ERRORS
linux-3.15.10-x86_64: ERRORS
linux-3.16.57-i686: ERRORS
linux-3.16.57-x86_64: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.123-i686: ERRORS
linux-3.18.123-x86_64: ERRORS
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: ERRORS
linux-4.1.52-x86_64: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.159-i686: ERRORS
linux-4.4.159-x86_64: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.10-i686: ERRORS
linux-4.7.10-x86_64: ERRORS
linux-4.8.17-i686: ERRORS
linux-4.8.17-x86_64: ERRORS
linux-4.9.131-i686: ERRORS
linux-4.9.131-x86_64: ERRORS
linux-4.10.17-i686: ERRORS
linux-4.10.17-x86_64: ERRORS
linux-4.11.12-i686: ERRORS
linux-4.11.12-x86_64: ERRORS
linux-4.12.14-i686: ERRORS
linux-4.12.14-x86_64: ERRORS
linux-4.13.16-i686: ERRORS
linux-4.13.16-x86_64: ERRORS
linux-4.14.74-i686: ERRORS
linux-4.14.74-x86_64: ERRORS
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


Invite for IRC meeting: Re: [PATCHv4 01/10] videodev2.h: add tag support

2018-12-06 Thread Hans Verkuil
Mauro raised a number of objections on irc regarding tags:

https://linuxtv.org/irc/irclogger_log/media-maint?date=2018-12-06,Thu

I would like to setup an irc meeting to discuss this and come to a
conclusion, since we need to decide this soon since this is critical
for stateless codec support.

Unfortunately timezone-wise this is a bit of a nightmare. I think
that at least Mauro, myself and Tomasz Figa should be there, so UTC-2,
UTC+1 and UTC+9 (if I got that right).

I propose 9 AM UTC which I think will work for everyone except Nicolas.
Any day next week works for me, and (for now) as well for Mauro. Let's pick
Monday to start with, and if you want to join in, then let me know. If that
day doesn't work for you, let me know what other days next week do work for
you.

Regards,

Hans

On 12/05/18 11:20, hverkuil-ci...@xs4all.nl wrote:
> From: Hans Verkuil 
> 
> Add support for 'tags' to struct v4l2_buffer. These can be used
> by m2m devices so userspace can set a tag for an output buffer and
> this value will then be copied to the capture buffer(s).
> 
> This tag can be used to refer to capture buffers, something that
> is needed by stateless HW codecs.
> 
> The new V4L2_BUF_CAP_SUPPORTS_TAGS capability indicates whether
> or not tags are supported.
> 
> Signed-off-by: Hans Verkuil 
> Reviewed-by: Paul Kocialkowski 
> Reviewed-by: Alexandre Courbot 
> ---
>  include/uapi/linux/videodev2.h | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 2db1635de956..9095d7abe10d 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -881,6 +881,7 @@ struct v4l2_requestbuffers {
>  #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_TAGS   (1 << 5)
>  
>  /**
>   * struct v4l2_plane - plane info for multi-planar buffers
> @@ -940,6 +941,7 @@ struct v4l2_plane {
>   * @length:  size in bytes of the buffer (NOT its payload) for single-plane
>   *   buffers (when type != *_MPLANE); number of elements in the
>   *   planes array for multi-plane buffers
> + * @tag: buffer tag
>   * @request_fd: fd of the request that this buffer should use
>   *
>   * Contains data exchanged by application and driver using one of the 
> Streaming
> @@ -964,7 +966,10 @@ struct v4l2_buffer {
>   __s32   fd;
>   } m;
>   __u32   length;
> - __u32   reserved2;
> + union {
> + __u32   reserved2;
> + __u32   tag;
> + };
>   union {
>   __s32   request_fd;
>   __u32   reserved;
> @@ -990,6 +995,8 @@ struct v4l2_buffer {
>  #define V4L2_BUF_FLAG_IN_REQUEST 0x0080
>  /* timecode field is valid */
>  #define V4L2_BUF_FLAG_TIMECODE   0x0100
> +/* tag field is valid */
> +#define V4L2_BUF_FLAG_TAG0x0200
>  /* Buffer is prepared for queuing */
>  #define V4L2_BUF_FLAG_PREPARED   0x0400
>  /* Cache handling flags */
> 



Re: [PATCH v5] media: imx: add mem2mem device

2018-12-06 Thread Hans Verkuil
On 12/06/18 00:13, Steve Longerbeam wrote:
> 
> 
> On 12/5/18 10:50 AM, Hans Verkuil wrote:
>> On 12/05/2018 02:20 AM, Steve Longerbeam wrote:
>>> Hi Hans, Philipp,
>>>
>>> One comment on my side...
>>>
>>> On 12/3/18 7:21 AM, Hans Verkuil wrote:
>>>> 
>>>>> +void imx_media_mem2mem_device_unregister(struct imx_media_video_dev 
>>>>> *vdev)
>>>>> +{
>>>>> + struct mem2mem_priv *priv = to_mem2mem_priv(vdev);
>>>>> + struct video_device *vfd = priv->vdev.vfd;
>>>>> +
>>>>> + mutex_lock(>mutex);
>>>>> +
>>>>> + if (video_is_registered(vfd)) {
>>>>> + video_unregister_device(vfd);
>>>>> + media_entity_cleanup(>entity);
>>>> Is this needed?
>>>>
>>>> If this is to be part of the media controller, then I expect to see a call
>>>> to v4l2_m2m_register_media_controller() somewhere.
>>>>
>>> Yes, I agree there should be a call to
>>> v4l2_m2m_register_media_controller(). This driver does not connect with
>>> any of the imx-media entities, but calling it will at least make the
>>> mem2mem output/capture device entities (and processing entity) visible
>>> in the media graph.
>>>
>>> Philipp, can you pick/squash the following from my media-tree github fork?
>>>
>>> 6fa05f5170 ("media: imx: mem2mem: Add missing media-device header")
>>> d355bf8b15 ("media: imx: Add missing unregister and remove of mem2mem
>>> device")
>>> 6787a50cdc ("media: imx: mem2mem: Register with media control")
>>>
>>> Steve
>>>
>> Why is this driver part of the imx driver? Since it doesn't connect with
>> any of the imx-media entities, doesn't that mean that this is really a
>> stand-alone driver?
> 
> It is basically a stand-alone m2m driver, but it makes use of some 
> imx-media utility functions like imx_media_enum_format(). Also making it 
> a true stand-alone driver would require creating a second /dev/mediaN 
> device.

If it is standalone, is it reused in newer iMX versions? (7 or 8)

And if it is just a regular m2m device, then it doesn't need to create a
media device either (doesn't hurt, but it is not required).

Regards,

Hans

> 
> Steve
> 



Re: [PATCHv4 00/10] vb2/cedrus: add tag support

2018-12-06 Thread Hans Verkuil
(fix copy and paste error in the cover letter)

As was discussed here (among other places):

https://lkml.org/lkml/2018/10/19/440

using capture queue buffer indices to refer to reference frames is
not a good idea. A better idea is to use a 'tag' where the
application can assign a u32 tag to an output buffer, which is then
copied to the capture buffer(s) derived from the output buffer.

It has been suggested that the timestamp can be used for this. But
there are a number of reasons why this is a bad idea:

1) the struct timeval is converted to a u64 in vb2. So there can be
   all sorts of unexpected conversion issues. In particular, the
   output of ns_to_timeval(timeval_to_ns(tv)) does not necessarily
   match the input.

2) it gets worse with the y2038 code where userspace either deals
   with a 32 bit tv_sec value or a 64 bit value.

In other words, using timestamp for this is not a good idea.

This implementation adds a new tag field in a union with the reserved2
field. The interpretation of that union depends on the flags field, so
it still can be used for other things as well. In addition, in the previous
patches the tag was in a union with the timecode field (again determined
by the flags field), so if we need to cram additional information in this
struct we can always put it in a union with the timecode field as well.
It worked for the tag, it should work for other things.

But we really need to start looking at a struct v4l2_ext_buffer.

The first three patches add core tag support, the next two patches document
the tag support, then a new helper function is added to v4l2-mem2mem.c
to easily copy data from a source to a destination buffer that drivers
can use.

Next a new supports_tags vb2_queue flag is added to indicate that
the driver supports tags. Ideally this should not be necessary, but
that would require that all m2m drivers are converted to using the
new helper function introduced in the previous patch. That takes more
time then I have now.

Finally the vim2m, vicodec and cedrus drivers are converted to support
tags.

I also removed the 'pad' fields from the mpeg2 control structs (it
should never been added in the first place) and aligned the structs
to a u32 boundary.

Note that this might change further (Paul suggested using bitfields).

Also note that the cedrus code doesn't set the sequence counter, that's
something that should still be added before this driver can be moved
out of staging.

Note: if no buffer is found for a certain tag, then the dma address
is just set to 0. That happened before as well with invalid buffer
indices. This should be checked in the driver!

Regards,

Hans

Changes since v3:

- use reserved2 for the tag
- split the documentation in two: one documenting the tag, one
  cleaning up the timecode documentation.

Changes since v2:

- rebased
- added Reviewed-by tags
- fixed a few remaining references in the documentation to the old
  v4l2_buffer_tag struct that was used in early versions of this
  series.

Changes since v1:

- changed to a u32 tag. Using a 64 bit tag was overly complicated due
  to the bad layout of the v4l2_buffer struct, and there is no real
  need for it by applications.

Main changes since the RFC:

- Added new buffer capability flag
- Added m2m helper to copy data between buffers
- Added documentation
- Added tag logging in v4l2-ioctl.c


Hans Verkuil (10):
  videodev2.h: add tag support
  vb2: add tag support
  v4l2-ioctl.c: log v4l2_buffer tag
  buffer.rst: document the new buffer tag feature.
  buffer.rst: clean up timecode documentation
  v4l2-mem2mem: add v4l2_m2m_buf_copy_data helper function
  vb2: add new supports_tags queue flag
  vim2m: add tag support
  vicodec: add tag support
  cedrus: add tag support

 Documentation/media/uapi/v4l/buffer.rst   | 28 +
 .../media/uapi/v4l/vidioc-reqbufs.rst |  4 ++
 .../media/common/videobuf2/videobuf2-v4l2.c   | 41 ---
 drivers/media/platform/vicodec/vicodec-core.c | 14 ++-
 drivers/media/platform/vim2m.c| 14 ++-
 drivers/media/v4l2-core/v4l2-ctrls.c  |  9 
 drivers/media/v4l2-core/v4l2-ioctl.c  |  9 ++--
 drivers/media/v4l2-core/v4l2-mem2mem.c| 23 +++
 drivers/staging/media/sunxi/cedrus/cedrus.h   |  9 ++--
 .../staging/media/sunxi/cedrus/cedrus_dec.c   |  2 +
 .../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 21 --
 .../staging/media/sunxi/cedrus/cedrus_video.c |  2 +
 include/media/v4l2-mem2mem.h  | 21 ++
 include/media/videobuf2-core.h|  2 +
 include/media/videobuf2-v4l2.h| 21 +-
 include/uapi/linux/v4l2-controls.h| 14 +++
 include/uapi/linux/videodev2.h|  9 +++-
 17 files changed, 168 insertions(+), 75 deletions(-)

-- 
2.19.1


cron job: media_tree daily build: ERRORS

2018-12-05 Thread Hans Verkuil
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:   Thu Dec  6 05:00:13 CET 2018
media-tree git hash:3c28b91380dd1183347d32d87d820818031ebecf
media_build git hash:   4b9237c73e29ea969f6a7b3d00030e14be50
v4l-utils git hash: 9f0354c3320f3cc62983f726bfed66e1d0c21f83
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: ERRORS
linux-3.10.108-x86_64: ERRORS
linux-3.11.10-i686: ERRORS
linux-3.11.10-x86_64: ERRORS
linux-3.12.74-i686: ERRORS
linux-3.12.74-x86_64: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.79-i686: ERRORS
linux-3.14.79-x86_64: ERRORS
linux-3.15.10-i686: ERRORS
linux-3.15.10-x86_64: ERRORS
linux-3.16.57-i686: ERRORS
linux-3.16.57-x86_64: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.123-i686: ERRORS
linux-3.18.123-x86_64: ERRORS
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: ERRORS
linux-4.1.52-x86_64: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.159-i686: ERRORS
linux-4.4.159-x86_64: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.10-i686: ERRORS
linux-4.7.10-x86_64: ERRORS
linux-4.8.17-i686: ERRORS
linux-4.8.17-x86_64: ERRORS
linux-4.9.131-i686: ERRORS
linux-4.9.131-x86_64: ERRORS
linux-4.10.17-i686: ERRORS
linux-4.10.17-x86_64: ERRORS
linux-4.11.12-i686: ERRORS
linux-4.11.12-x86_64: ERRORS
linux-4.12.14-i686: ERRORS
linux-4.12.14-x86_64: ERRORS
linux-4.13.16-i686: ERRORS
linux-4.13.16-x86_64: ERRORS
linux-4.14.74-i686: ERRORS
linux-4.14.74-x86_64: ERRORS
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/Thursday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html


Re: [PATCH v5] media: imx: add mem2mem device

2018-12-05 Thread Hans Verkuil
On 12/05/2018 02:20 AM, Steve Longerbeam wrote:
> Hi Hans, Philipp,
> 
> One comment on my side...
> 
> On 12/3/18 7:21 AM, Hans Verkuil wrote:
>> 
>>> +void imx_media_mem2mem_device_unregister(struct imx_media_video_dev *vdev)
>>> +{
>>> +   struct mem2mem_priv *priv = to_mem2mem_priv(vdev);
>>> +   struct video_device *vfd = priv->vdev.vfd;
>>> +
>>> +   mutex_lock(>mutex);
>>> +
>>> +   if (video_is_registered(vfd)) {
>>> +   video_unregister_device(vfd);
>>> +   media_entity_cleanup(>entity);
>> Is this needed?
>>
>> If this is to be part of the media controller, then I expect to see a call
>> to v4l2_m2m_register_media_controller() somewhere.
>>
> 
> Yes, I agree there should be a call to 
> v4l2_m2m_register_media_controller(). This driver does not connect with 
> any of the imx-media entities, but calling it will at least make the 
> mem2mem output/capture device entities (and processing entity) visible 
> in the media graph.
> 
> Philipp, can you pick/squash the following from my media-tree github fork?
> 
> 6fa05f5170 ("media: imx: mem2mem: Add missing media-device header")
> d355bf8b15 ("media: imx: Add missing unregister and remove of mem2mem 
> device")
> 6787a50cdc ("media: imx: mem2mem: Register with media control")
> 
> Steve
> 

Why is this driver part of the imx driver? Since it doesn't connect with
any of the imx-media entities, doesn't that mean that this is really a
stand-alone driver?

Regards,

Hans


Re: [PATCH] media: rockchip/vpu: fix a few alignments

2018-12-05 Thread Hans Verkuil
On 12/05/2018 07:43 PM, Mauro Carvalho Chehab wrote:
> As reported by checkpatch.pl, some function calls have a wrong
> alignment.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 4 ++--
>  drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c 
> b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> index 8919151e1631..e27c10855de5 100644
> --- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> +++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> @@ -106,8 +106,8 @@ void rk3288_vpu_jpeg_enc_run(struct rockchip_vpu_ctx *ctx)
>   rk3288_vpu_set_src_img_ctrl(vpu, ctx);
>   rk3288_vpu_jpeg_enc_set_buffers(vpu, ctx, src_buf);
>   rk3288_vpu_jpeg_enc_set_qtable(vpu,
> - rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> - rockchip_vpu_jpeg_get_qtable(_ctx, 1));
> +rockchip_vpu_jpeg_get_qtable(_ctx, 
> 0),
> +rockchip_vpu_jpeg_get_qtable(_ctx, 
> 1));

But now you get warnings because this is > 80 columns.

I think the 'cure' is worse than the disease.

I see this is already merged, but I don't think this patch improves readability,
which is more important than a checkpatch warning IMHO.

Regards,

Hans

>  
>   reg = VEPU_REG_AXI_CTRL_OUTPUT_SWAP16
>   | VEPU_REG_AXI_CTRL_INPUT_SWAP16
> diff --git a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c 
> b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> index 8afa2162bf9f..5f75e4d11d76 100644
> --- a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> +++ b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> @@ -137,8 +137,8 @@ void rk3399_vpu_jpeg_enc_run(struct rockchip_vpu_ctx *ctx)
>   rk3399_vpu_set_src_img_ctrl(vpu, ctx);
>   rk3399_vpu_jpeg_enc_set_buffers(vpu, ctx, src_buf);
>   rk3399_vpu_jpeg_enc_set_qtable(vpu,
> - rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> - rockchip_vpu_jpeg_get_qtable(_ctx, 1));
> +rockchip_vpu_jpeg_get_qtable(_ctx, 
> 0),
> +rockchip_vpu_jpeg_get_qtable(_ctx, 
> 1));
>  
>   reg = VEPU_REG_OUTPUT_SWAP32
>   | VEPU_REG_OUTPUT_SWAP16
> 



[GIT PULL FOR v4.21] Rockchip VPU JPEG encoder driver

2018-12-05 Thread Hans Verkuil
Note regarding the first 'Revert' patch: that is this patch:

https://patchwork.linuxtv.org/patch/52869/

It is currently pending for 4.20 as a fix, but since it is not merged upstream
yet, our master branch still has those old bindings.

I decided to first apply the Revert patch, then add the new patch on top.

Regards,

Hans

The following changes since commit da2c94c8f9739e4099ea3cfefc208fc721b22a9c:

  media: v4l2: async: remove locking when initializing async notifier 
(2018-12-05 06:51:28 -0500)

are available in the Git repository at:

  git://linuxtv.org/hverkuil/media_tree.git tags/br-rkjpeg2

for you to fetch changes up to 7f608cfd52c08e7d84bd38438e330c26263eddcb:

  media: add Rockchip VPU JPEG encoder driver (2018-12-05 17:18:46 +0100)


Tag branch


Ezequiel Garcia (3):
  Revert "media: dt-bindings: Document the Rockchip VPU bindings"
  media: dt-bindings: Document the Rockchip VPU bindings
  media: add Rockchip VPU JPEG encoder driver

 MAINTAINERS |   7 +
 drivers/staging/media/Kconfig   |   2 +
 drivers/staging/media/Makefile  |   1 +
 drivers/staging/media/rockchip/vpu/Kconfig  |  13 +
 drivers/staging/media/rockchip/vpu/Makefile |  10 +
 drivers/staging/media/rockchip/vpu/TODO |  13 +
 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c  | 118 +++
 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 130 
 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h| 442 
++
 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c  | 118 +++
 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 164 ++
 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h| 600 
+++
 drivers/staging/media/rockchip/vpu/rockchip_vpu.h   | 232 
++
 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h|  29 ++
 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c   | 537 
+++
 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c   | 676 

 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h|  58 
 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c  | 290 
+
 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h  |  14 +
 19 files changed, 3454 insertions(+)
 create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig
 create mode 100644 drivers/staging/media/rockchip/vpu/Makefile
 create mode 100644 drivers/staging/media/rockchip/vpu/TODO
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h


Re: [PATCH v11 4/4] media: add Rockchip VPU JPEG encoder driver

2018-12-05 Thread Hans Verkuil
On 11/30/18 18:34, Ezequiel Garcia wrote:
> Add a mem2mem driver for the VPU available on Rockchip SoCs.
> Currently only JPEG encoding is supported, for RK3399 and RK3288
> platforms.
> 
> Signed-off-by: Ezequiel Garcia 
> ---



> diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c 
> b/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
> new file mode 100644
> index ..f2752a0c71c0
> --- /dev/null
> +++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
> @@ -0,0 +1,531 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Rockchip VPU codec driver
> + *
> + * Copyright (C) 2018 Collabora, Ltd.
> + * Copyright 2018 Google LLC.
> + *   Tomasz Figa 
> + *
> + * Based on s5p-mfc driver by Samsung Electronics Co., Ltd.
> + * Copyright (C) 2011 Samsung Electronics Co., Ltd.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "rockchip_vpu_common.h"
> +#include "rockchip_vpu.h"
> +#include "rockchip_vpu_hw.h"
> +
> +#define DRIVER_NAME "rockchip-vpu"
> +
> +int rockchip_vpu_debug;
> +module_param_named(debug, rockchip_vpu_debug, int, 0644);
> +MODULE_PARM_DESC(debug,
> +  "Debug level - higher value produces more verbose messages");
> +
> +static void rockchip_vpu_job_finish(struct rockchip_vpu_dev *vpu,
> + struct rockchip_vpu_ctx *ctx,
> + unsigned int bytesused,
> + enum vb2_buffer_state result)
> +{
> + struct vb2_v4l2_buffer *src, *dst;
> + size_t avail_size;
> +
> + pm_runtime_mark_last_busy(vpu->dev);
> + pm_runtime_put_autosuspend(vpu->dev);
> + clk_bulk_disable(vpu->variant->num_clocks, vpu->clocks);
> +
> + src = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> + dst = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> +
> + if (WARN_ON(!src))
> + return;
> + if (WARN_ON(!dst))
> + return;
> +
> + src->sequence = ctx->sequence_out++;
> + dst->sequence = ctx->sequence_cap++;
> +
> + dst->field = src->field;
> + if (dst->flags & V4L2_BUF_FLAG_TIMECODE)

That should be src->flags

> + dst->timecode = src->timecode;
> + dst->vb2_buf.timestamp = src->vb2_buf.timestamp;
> + dst->flags &= ~V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
> + dst->flags |= src->flags & V4L2_BUF_FLAG_TSTAMP_SRC_MASK;

And this should clear and copy V4L2_BUF_FLAG_TIMECODE as well.

> +
> + avail_size = vb2_plane_size(>vb2_buf, 0) -
> +  ctx->vpu_dst_fmt->header_size;
> + if (bytesused <= avail_size) {
> + if (ctx->bounce_buf) {
> + memcpy(vb2_plane_vaddr(>vb2_buf, 0) +
> +ctx->vpu_dst_fmt->header_size,
> +ctx->bounce_buf, bytesused);
> + }
> + dst->vb2_buf.planes[0].bytesused =
> + ctx->vpu_dst_fmt->header_size + bytesused;
> + } else {
> + result = VB2_BUF_STATE_ERROR;
> + }
> +
> + v4l2_m2m_buf_done(src, result);
> + v4l2_m2m_buf_done(dst, result);
> +
> + v4l2_m2m_job_finish(vpu->m2m_dev, ctx->fh.m2m_ctx);
> +}
> +
> +void rockchip_vpu_irq_done(struct rockchip_vpu_dev *vpu,
> +unsigned int bytesused,
> +enum vb2_buffer_state result)
> +{
> + struct rockchip_vpu_ctx *ctx =
> + v4l2_m2m_get_curr_priv(vpu->m2m_dev);
> +
> + /*
> +  * If cancel_delayed_work returns false
> +  * the timeout expired. The watchdog is running,
> +  * and will take care of finishing the job.
> +  */
> + if (cancel_delayed_work(>watchdog_work))
> + rockchip_vpu_job_finish(vpu, ctx, bytesused, result);
> +}
> +
> +void rockchip_vpu_watchdog(struct work_struct *work)
> +{
> + struct rockchip_vpu_dev *vpu;
> + struct rockchip_vpu_ctx *ctx;
> +
> + vpu = container_of(to_delayed_work(work),
> +struct rockchip_vpu_dev, watchdog_work);
> + ctx = v4l2_m2m_get_curr_priv(vpu->m2m_dev);
> + if (ctx) {
> + vpu_err("frame processing timed out!\n");
> + ctx->codec_ops->reset(ctx);
> + rockchip_vpu_job_finish(vpu, ctx, 0, VB2_BUF_STATE_ERROR);
> + }
> +}
> +
> +static void device_run(void *priv)
> +{
> + struct rockchip_vpu_ctx *ctx = priv;
> + int ret;
> +
> + ret = clk_bulk_enable(ctx->dev->variant->num_clocks, ctx->dev->clocks);
> + if (ret)
> + goto err_cancel_job;
> + ret = pm_runtime_get_sync(ctx->dev->dev);
> + if (ret < 0)
> + goto err_cancel_job;
> +
> + ctx->codec_ops->run(ctx);
> + return;
> +
> +err_cancel_job:
> + rockchip_vpu_job_finish(ctx->dev, ctx, 0, VB2_BUF_STATE_ERROR);
> +}
> +
> +static struct v4l2_m2m_ops vpu_m2m_ops = {
> + .device_run = device_run,

[GIT FIXES FOR v4.20] cedrus: move control definitions to mpeg2-ctrls.h

2018-12-05 Thread Hans Verkuil
This API is not stable enough yet to be exposed in the uAPI. Move it
to a kAPI header.

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.21q2

for you to fetch changes up to f9a88dc4e8703bfa6a40229806fbb496e4111664:

  extended-controls.rst: add note to the MPEG2 state controls (2018-12-05 
13:59:16 +0100)


Tag branch


Hans Verkuil (2):
  mpeg2-ctrls.h: move MPEG2 state controls to non-public header
  extended-controls.rst: add note to the MPEG2 state controls

 Documentation/media/uapi/v4l/extended-controls.rst | 10 +++
 drivers/media/v4l2-core/v4l2-ctrls.c   |  4 +--
 include/media/mpeg2-ctrls.h| 86 
++
 include/media/v4l2-ctrls.h |  6 
 include/uapi/linux/v4l2-controls.h | 68 
--
 include/uapi/linux/videodev2.h |  4 ---
 6 files changed, 104 insertions(+), 74 deletions(-)
 create mode 100644 include/media/mpeg2-ctrls.h


Re: [PATCH 1/1] media: Add a Kconfig option for the Request API

2018-12-05 Thread Hans Verkuil
On 12/05/18 13:24, Sakari Ailus wrote:
> The Request API is now merged to the kernel but the confidence on the
> stability of that API is not great, especially regarding the interaction
> with V4L2.
> 
> Add a Kconfig option for the API, with a scary-looking warning.
> 
> The patch itself disables request creation as well as does not advertise
> them as buffer flags. The driver requiring requests (cedrus) now depends
> on the Kconfig option as well.
> 
> Signed-off-by: Sakari Ailus 

Acked-by: Hans Verkuil 

> ---
> I hope this covers now everything... I was thinking how to make the option
> name itself more worrisome but I couldn't come up with a better language
> that would be compact enough. The "(EXPERIMENTAL)" notion is a bit too
> worn to be effective. :-I
> 
> The patch can and should be reverted once we're entirely happy and
> confident with the API.
> 
>  drivers/media/Kconfig   | 13 +
>  drivers/media/common/videobuf2/videobuf2-v4l2.c |  2 ++
>  drivers/media/media-device.c|  2 ++
>  drivers/staging/media/sunxi/cedrus/Kconfig  |  1 +
>  4 files changed, 18 insertions(+)
> 
> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
> index 8add62a18293..102eb35fcf3f 100644
> --- a/drivers/media/Kconfig
> +++ b/drivers/media/Kconfig
> @@ -110,6 +110,19 @@ config MEDIA_CONTROLLER_DVB
>  
> This is currently experimental.
>  
> +config MEDIA_CONTROLLER_REQUEST_API
> + bool "Enable Media controller Request API (EXPERIMENTAL)"
> + depends on MEDIA_CONTROLLER && STAGING_MEDIA
> + default n
> + ---help---
> +   DO NOT ENABLE THIS OPTION UNLESS YOU KNOW WHAT YOU'RE DOING.
> +
> +   This option enables the Request API for the Media controller and V4L2
> +   interfaces. It is currently needed by a few stateless codec drivers.
> +
> +   There is currently no intention to provide API or ABI stability for
> +   this new API as of yet.
> +
>  #
>  # Video4Linux support
>  #Only enables if one of the V4L2 types (ATV, webcam, radio) is selected
> diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c 
> b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> index 1244c246d0c4..83c3c0c49e56 100644
> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> @@ -630,8 +630,10 @@ static void fill_buf_caps(struct vb2_queue *q, u32 *caps)
>   *caps |= V4L2_BUF_CAP_SUPPORTS_USERPTR;
>   if (q->io_modes & VB2_DMABUF)
>   *caps |= V4L2_BUF_CAP_SUPPORTS_DMABUF;
> +#ifdef CONFIG_MEDIA_CONTROLLER_REQUEST_API
>   if (q->supports_requests)
>   *caps |= V4L2_BUF_CAP_SUPPORTS_REQUESTS;
> +#endif
>  }
>  
>  int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req)
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index bed24372e61f..2ef114ce38d0 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -381,7 +381,9 @@ static long media_device_get_topology(struct media_device 
> *mdev, void *arg)
>  static long media_device_request_alloc(struct media_device *mdev,
>  int *alloc_fd)
>  {
> +#ifndef CONFIG_MEDIA_CONTROLLER_REQUEST_API
>   if (!mdev->ops || !mdev->ops->req_validate || !mdev->ops->req_queue)
> +#endif
>   return -ENOTTY;
>  
>   return media_request_alloc(mdev, alloc_fd);
> diff --git a/drivers/staging/media/sunxi/cedrus/Kconfig 
> b/drivers/staging/media/sunxi/cedrus/Kconfig
> index a7a34e89c42d..3252efa422f9 100644
> --- a/drivers/staging/media/sunxi/cedrus/Kconfig
> +++ b/drivers/staging/media/sunxi/cedrus/Kconfig
> @@ -3,6 +3,7 @@ config VIDEO_SUNXI_CEDRUS
>   depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER
>   depends on HAS_DMA
>   depends on OF
> + depends on MEDIA_CONTROLLER_REQUEST_API
>   select SUNXI_SRAM
>   select VIDEOBUF2_DMA_CONTIG
>   select V4L2_MEM2MEM_DEV
> 



[GIT PULL FOR v4.21] vicodec cleanup

2018-12-05 Thread Hans Verkuil
The following changes since commit b2e9a4eda11fd2cb1e6714e9ad3f455c402568ff:

  media: firewire: Fix app_info parameter type in avc_ca{,_app}_info 
(2018-12-05 05:34:33 -0500)

are available in the Git repository at:

  git://linuxtv.org/hverkuil/media_tree.git tags/br-v4.21h

for you to fetch changes up to a1e9f0504e413d4ae9f7e8879be59253f676f429:

  media: vicodec: Change variable names (2018-12-05 12:44:42 +0100)


Tag branch


Dafna Hirschfeld (1):
  media: vicodec: Change variable names

 drivers/media/platform/vicodec/vicodec-core.c | 94 
---
 1 file changed, 48 insertions(+), 46 deletions(-)


[PATCHv4 11/10] extended-controls.rst: update the mpeg2 compound controls

2018-12-05 Thread Hans Verkuil
The layout of the compound controls has changed to fix
32/64 bit alignment issues and the use of tags instead of
buffer indices to refer to buffers. Note that these controls
are only used by the cedrus staging driver.

Signed-off-by: Hans Verkuil 
---
 .../media/uapi/v4l/extended-controls.rst  | 24 ++-
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
b/Documentation/media/uapi/v4l/extended-controls.rst
index 65a1d873196b..b9e3af29a704 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -1528,17 +1528,19 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
   - ``picture``
   - Structure with MPEG-2 picture metadata, merging relevant fields from
the picture header and picture coding extension parts of the bitstream.
-* - __u8
+* - __u32
+  - ``backward_ref_tag``
+  - Tag for the V4L2 buffer to use as backward reference, used with
+   B-coded and P-coded frames. The tag refers to the ``tag`` field in
+   struct :c:type:`v4l2_buffer`.
+* - __u32
+  - ``forward_ref_tag``
+  - Tag for the V4L2 buffer to use as forward reference, used with
+   B-coded frames. The tag refers to the ``tag`` field in
+   struct :c:type:`v4l2_buffer`.
+* - __u32
   - ``quantiser_scale_code``
   - Code used to determine the quantization scale to use for the IDCT.
-* - __u8
-  - ``backward_ref_index``
-  - Index for the V4L2 buffer to use as backward reference, used with
-   B-coded and P-coded frames.
-* - __u8
-  - ``forward_ref_index``
-  - Index for the V4L2 buffer to use as forward reference, used with
-   B-coded frames.

 .. c:type:: v4l2_mpeg2_sequence

@@ -1559,7 +1561,7 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
   - ``vbv_buffer_size``
   - Used to calculate the required size of the video buffering verifier,
defined (in bits) as: 16 * 1024 * vbv_buffer_size.
-* - __u8
+* - __u16
   - ``profile_and_level_indication``
   - The current profile and level indication as extracted from the
bitstream.
@@ -1617,7 +1619,7 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
 * - __u8
   - ``repeat_first_field``
   - This flag affects the decoding process of progressive frames.
-* - __u8
+* - __u16
   - ``progressive_frame``
   - Indicates whether the current frame is progressive.

-- 
2.19.1




cron job: media_tree daily build: ERRORS

2018-12-04 Thread Hans Verkuil
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 Dec  5 05:00:10 CET 2018
media-tree git hash:9b90dc85c718443a3e573a0ccf55900ff4fa73ae
media_build git hash:   47bf46ff21f75d1fe4ae3275a8692cb6ff77b6e8
v4l-utils git hash: cff58fcfbdf75381d5351f5ea8e7846f59cb7905
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: ERRORS
linux-3.10.108-x86_64: ERRORS
linux-3.11.10-i686: ERRORS
linux-3.11.10-x86_64: ERRORS
linux-3.12.74-i686: ERRORS
linux-3.12.74-x86_64: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.79-i686: ERRORS
linux-3.14.79-x86_64: ERRORS
linux-3.15.10-i686: ERRORS
linux-3.15.10-x86_64: ERRORS
linux-3.16.57-i686: ERRORS
linux-3.16.57-x86_64: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.123-i686: ERRORS
linux-3.18.123-x86_64: ERRORS
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: ERRORS
linux-4.1.52-x86_64: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.159-i686: ERRORS
linux-4.4.159-x86_64: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.10-i686: ERRORS
linux-4.7.10-x86_64: ERRORS
linux-4.8.17-i686: ERRORS
linux-4.8.17-x86_64: ERRORS
linux-4.9.131-i686: ERRORS
linux-4.9.131-x86_64: ERRORS
linux-4.10.17-i686: ERRORS
linux-4.10.17-x86_64: ERRORS
linux-4.11.12-i686: ERRORS
linux-4.11.12-x86_64: ERRORS
linux-4.12.14-i686: ERRORS
linux-4.12.14-x86_64: ERRORS
linux-4.13.16-i686: ERRORS
linux-4.13.16-x86_64: ERRORS
linux-4.14.74-i686: ERRORS
linux-4.14.74-x86_64: ERRORS
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/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


cron job: media_tree daily build: ERRORS

2018-12-03 Thread Hans Verkuil
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Tue Dec  4 05:00:13 CET 2018
media-tree git hash:9b90dc85c718443a3e573a0ccf55900ff4fa73ae
media_build git hash:   47bf46ff21f75d1fe4ae3275a8692cb6ff77b6e8
v4l-utils git hash: cff58fcfbdf75381d5351f5ea8e7846f59cb7905
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: ERRORS
linux-3.10.108-x86_64: ERRORS
linux-3.11.10-i686: ERRORS
linux-3.11.10-x86_64: ERRORS
linux-3.12.74-i686: ERRORS
linux-3.12.74-x86_64: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.79-i686: ERRORS
linux-3.14.79-x86_64: ERRORS
linux-3.15.10-i686: ERRORS
linux-3.15.10-x86_64: ERRORS
linux-3.16.57-i686: ERRORS
linux-3.16.57-x86_64: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.123-i686: ERRORS
linux-3.18.123-x86_64: ERRORS
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: ERRORS
linux-4.1.52-x86_64: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.159-i686: ERRORS
linux-4.4.159-x86_64: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.10-i686: ERRORS
linux-4.7.10-x86_64: ERRORS
linux-4.8.17-i686: ERRORS
linux-4.8.17-x86_64: ERRORS
linux-4.9.131-i686: ERRORS
linux-4.9.131-x86_64: ERRORS
linux-4.10.17-i686: ERRORS
linux-4.10.17-x86_64: ERRORS
linux-4.11.12-i686: ERRORS
linux-4.11.12-x86_64: ERRORS
linux-4.12.14-i686: ERRORS
linux-4.12.14-x86_64: ERRORS
linux-4.13.16-i686: ERRORS
linux-4.13.16-x86_64: ERRORS
linux-4.14.74-i686: ERRORS
linux-4.14.74-x86_64: ERRORS
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/Tuesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html


[GIT FIXES FOR v4.20] seco-cec: add missing header

2018-12-03 Thread Hans Verkuil
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.20p

for you to fetch changes up to 783f306b4e480b964daa5ac45d13edd1579f42e4:

  media: seco-cec: add missing header file to fix build (2018-12-03 20:26:37 
+0100)


Tag branch


Randy Dunlap (1):
  media: seco-cec: add missing header file to fix build

 drivers/media/platform/seco-cec/seco-cec.c | 1 +
 1 file changed, 1 insertion(+)


Re: [PATCH v5] media: imx: add mem2mem device

2018-12-03 Thread Hans Verkuil
On 12/03/2018 12:48 PM, Philipp Zabel wrote:
> Add a single imx-media mem2mem video device that uses the IPU IC PP
> (image converter post processing) task for scaling and colorspace
> conversion.
> On i.MX6Q/DL SoCs with two IPUs currently only the first IPU is used.
> 
> The hardware only supports writing to destination buffers up to
> 1024x1024 pixels in a single pass, arbitrary sizes can be achieved
> by rendering multiple tiles per frame.
> 
> Signed-off-by: Philipp Zabel 
> [slongerb...@gmail.com: use ipu_image_convert_adjust(), fix
>  device_run() error handling]
> Signed-off-by: Steve Longerbeam 
> ---
> Changes since v4:
>  - No functional changes.
>  - Dropped deprecated TODO comment. This driver has no interaction with
>the IC task v4l2 subdevices.
>  - Dropped ipu-v3 patches, those are merged independently via imx-drm.

These land in kernel 4.21? Or are they already in 4.20?

> ---
>  drivers/staging/media/imx/Kconfig |   1 +
>  drivers/staging/media/imx/Makefile|   1 +
>  drivers/staging/media/imx/imx-media-dev.c |  10 +
>  drivers/staging/media/imx/imx-media-mem2mem.c | 873 ++

Please give this file a better name! imx-media-csc-scaler.c or something is
much more descriptive. Calling it mem2mem doesn't tell me what it actually does!

>  drivers/staging/media/imx/imx-media.h |  10 +
>  5 files changed, 895 insertions(+)
>  create mode 100644 drivers/staging/media/imx/imx-media-mem2mem.c
> 
> diff --git a/drivers/staging/media/imx/Kconfig 
> b/drivers/staging/media/imx/Kconfig
> index bfc17de56b17..07013cb3cb66 100644
> --- a/drivers/staging/media/imx/Kconfig
> +++ b/drivers/staging/media/imx/Kconfig
> @@ -6,6 +6,7 @@ config VIDEO_IMX_MEDIA
>   depends on HAS_DMA
>   select VIDEOBUF2_DMA_CONTIG
>   select V4L2_FWNODE
> + select V4L2_MEM2MEM_DEV
>   ---help---
> Say yes here to enable support for video4linux media controller
> driver for the i.MX5/6 SOC.
> diff --git a/drivers/staging/media/imx/Makefile 
> b/drivers/staging/media/imx/Makefile
> index 698a4210316e..f2e722d0fa19 100644
> --- a/drivers/staging/media/imx/Makefile
> +++ b/drivers/staging/media/imx/Makefile
> @@ -6,6 +6,7 @@ imx-media-ic-objs := imx-ic-common.o imx-ic-prp.o 
> imx-ic-prpencvf.o
>  obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media.o
>  obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-common.o
>  obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-capture.o
> +obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-mem2mem.o
>  obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-vdic.o
>  obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-ic.o
>  
> diff --git a/drivers/staging/media/imx/imx-media-dev.c 
> b/drivers/staging/media/imx/imx-media-dev.c
> index 4b344a4a3706..0376b52cb784 100644
> --- a/drivers/staging/media/imx/imx-media-dev.c
> +++ b/drivers/staging/media/imx/imx-media-dev.c
> @@ -318,6 +318,16 @@ static int imx_media_probe_complete(struct 
> v4l2_async_notifier *notifier)
>   goto unlock;
>  
>   ret = v4l2_device_register_subdev_nodes(>v4l2_dev);
> + if (ret)
> + goto unlock;
> +
> + imxmd->m2m_vdev = imx_media_mem2mem_device_init(imxmd);
> + if (IS_ERR(imxmd->m2m_vdev)) {
> + ret = PTR_ERR(imxmd->m2m_vdev);
> + goto unlock;
> + }
> +
> + ret = imx_media_mem2mem_device_register(imxmd->m2m_vdev);
>  unlock:
>   mutex_unlock(>mutex);
>   if (ret)
> diff --git a/drivers/staging/media/imx/imx-media-mem2mem.c 
> b/drivers/staging/media/imx/imx-media-mem2mem.c
> new file mode 100644
> index ..a2a4dca017ce
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-media-mem2mem.c
> @@ -0,0 +1,873 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * i.MX IPUv3 mem2mem Scaler/CSC driver
> + *
> + * Copyright (C) 2011 Pengutronix, Sascha Hauer
> + * Copyright (C) 2018 Pengutronix, Philipp Zabel
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "imx-media.h"
> +
> +#define fh_to_ctx(__fh)  container_of(__fh, struct mem2mem_ctx, fh)
> +
> +enum {
> + V4L2_M2M_SRC = 0,
> + V4L2_M2M_DST = 1,
> +};
> +
> +struct mem2mem_priv {
> + struct imx_media_video_dev vdev;
> +
> + struct v4l2_m2m_dev   *m2m_dev;
> + struct device *dev;
> +
> + struct imx_media_dev  *md;
> +
> + struct mutex  mutex;   /* mem2mem device mutex */
> +
> + atomic_t  num_inst;
> +};
> +
> +#define to_mem2mem_priv(v) container_of(v, struct mem2mem_priv, vdev)
> +
> +/* Per-queue, driver-specific private data */
> +struct mem2mem_q_data {
> + struct v4l2_pix_format  cur_fmt;
> + struct v4l2_rectrect;
> +};
> +
> +struct mem2mem_ctx {
> + struct mem2mem_priv *priv;
> +
> + struct v4l2_fh  fh;
> + struct mem2mem_q_data   q_data[2];
> + int 

Re: [PATCHv2] videodev2.h: add V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF/CREATE_BUFS

2018-12-03 Thread Hans Verkuil
On 11/29/2018 10:30 AM, Hans Verkuil wrote:
> 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

Re: v4l controls API

2018-12-03 Thread Hans Verkuil
On 12/03/2018 11:03 AM, Sebastian Süsens wrote:
> Hey,
> 
> I use the driver mx6s_capture kernel 4.9.88 
> On the device tree it is registered with following name "fsl,imx6s-csi".

Ah, that's probably the freescale driver. We don't support that. It's known
to be quite buggy.

Sorry, you're on your own here.

Regards,

Hans

> 
> Hint:
> I have no sub-devices on my systems only /dev/video0
> 
> 
>Sebastian Süsens   Tel.   +49 4321 559 56-27
>mycable GmbH   Fax+49 4321 559 56-10
>Gartenstrasse 10
>24534 Neumuenster, Germany Email  s...@mycable.de
> 
>mycable GmbH, Managing Director: Michael Carstens-Behrens
>USt-IdNr: DE 214 231 199, Amtsgericht Kiel, HRB 1797 NM
> 
>This e-mail and any files transmitted with it are confidential and
>intended solely for the use of the individual or entity to whom
>they are addressed. If you have received this e-mail in error,
>please notify the sender and delete all copies from your system.
> --------
> 
> - Ursprüngliche Mail -
> Von: "Hans Verkuil" 
> An: "Sebastian Süsens" , "linux-media" 
> 
> Gesendet: Montag, 3. Dezember 2018 09:29:14
> Betreff: Re: v4l controls API
> 
> On 12/03/2018 09:02 AM, Sebastian Süsens wrote:
>> Hello,
>>
>> I don't know how to get access to the v4l controls on a I2C camera sensor.
>>
>> My driver structure looks following:
>>
>> bridge driver-> csi-driver   
>>-> sensor driver (includes controls)
>> register-async-notifer for csi driverregister-async-notifer for 
>> sensor driver
>> register video device
>>
>> The v4l2 API say:
>> When a sub-device is registered with a V4L2 driver by calling 
>> v4l2_device_register_subdev() and the ctrl_handler fields of both 
>> v4l2_subdev and v4l2_device are set, then the controls of the subdev will 
>> become automatically available in the V4L2 driver as well. If the subdev 
>> driver contains controls that already exist in the V4L2 driver, then those 
>> will be skipped (so a V4L2 driver can always override a subdev control).
>>
>> But how can I get access to the controls by asynchronous registration, 
>> because the controls are not added to the video device automatically?
> 
> Yes, they are via v4l2_device_register_subdev(), which is called by the async 
> code
> when the subdev driver arrives.
> 
> Note that this assumes that the bridge driver has a control handler that 
> struct
> v4l2_device points to (the ctrl_handler field).
> 
> Also note that certain types of drivers (media controller-based) such as the 
> imx
> driver do not 'inherit' controls since each subdev has its own v4l-subdevX 
> device node
> through which its controls can be set. You do not mention which bridge driver 
> you are
> using, so I can't tell whether or not it falls in this category.
> 
> Regards,
> 
>   Hans
> 
>>
>> Normally I can use:
>>
>> v4l2-ctl -l -d /dev/video0
>>
>> I don't know if this forum is the right place for this question, so please 
>> answer with a private e-mail s...@mycable.de
>>
>> 
>>Sebastian Süsens   Tel.   +49 4321 559 56-27
>>mycable GmbH   Fax+49 4321 559 56-10
>>Gartenstrasse 10
>>24534 Neumuenster, Germany Email  s...@mycable.de
>> 
>>mycable GmbH, Managing Director: Michael Carstens-Behrens
>>USt-IdNr: DE 214 231 199, Amtsgericht Kiel, HRB 1797 NM
>> 
>>This e-mail and any files transmitted with it are confidential and
>>intended solely for the use of the individual or entity to whom
>>they are addressed. If you have received this e-mail in error,
>>please notify the sender and delete all copies from your system.
>> 
>>



Re: v4l controls API

2018-12-03 Thread Hans Verkuil
On 12/03/2018 09:02 AM, Sebastian Süsens wrote:
> Hello,
> 
> I don't know how to get access to the v4l controls on a I2C camera sensor.
> 
> My driver structure looks following:
> 
> bridge driver-> csi-driver
>   -> sensor driver (includes controls)
> register-async-notifer for csi driverregister-async-notifer for 
> sensor driver
> register video device
> 
> The v4l2 API say:
> When a sub-device is registered with a V4L2 driver by calling 
> v4l2_device_register_subdev() and the ctrl_handler fields of both v4l2_subdev 
> and v4l2_device are set, then the controls of the subdev will become 
> automatically available in the V4L2 driver as well. If the subdev driver 
> contains controls that already exist in the V4L2 driver, then those will be 
> skipped (so a V4L2 driver can always override a subdev control).
> 
> But how can I get access to the controls by asynchronous registration, 
> because the controls are not added to the video device automatically?

Yes, they are via v4l2_device_register_subdev(), which is called by the async 
code
when the subdev driver arrives.

Note that this assumes that the bridge driver has a control handler that struct
v4l2_device points to (the ctrl_handler field).

Also note that certain types of drivers (media controller-based) such as the imx
driver do not 'inherit' controls since each subdev has its own v4l-subdevX 
device node
through which its controls can be set. You do not mention which bridge driver 
you are
using, so I can't tell whether or not it falls in this category.

Regards,

Hans

> 
> Normally I can use:
> 
> v4l2-ctl -l -d /dev/video0
> 
> I don't know if this forum is the right place for this question, so please 
> answer with a private e-mail s...@mycable.de
> 
> 
>Sebastian Süsens   Tel.   +49 4321 559 56-27
>mycable GmbH   Fax+49 4321 559 56-10
>Gartenstrasse 10
>24534 Neumuenster, Germany Email  s...@mycable.de
> 
>mycable GmbH, Managing Director: Michael Carstens-Behrens
>USt-IdNr: DE 214 231 199, Amtsgericht Kiel, HRB 1797 NM
> 
>This e-mail and any files transmitted with it are confidential and
>intended solely for the use of the individual or entity to whom
>they are addressed. If you have received this e-mail in error,
>please notify the sender and delete all copies from your system.
> 
> 



cron job: media_tree daily build: OK

2018-12-02 Thread Hans Verkuil
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:   Mon Dec  3 05:00:11 CET 2018
media-tree git hash:708d75fe1c7c6e9abc5381b6fcc32b49830383d0
media_build git hash:   47bf46ff21f75d1fe4ae3275a8692cb6ff77b6e8
v4l-utils git hash: cff58fcfbdf75381d5351f5ea8e7846f59cb7905
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: OK
linux-3.19.8-x86_64: OK
linux-4.0.9-i686: OK
linux-4.0.9-x86_64: OK
linux-4.1.52-i686: OK
linux-4.1.52-x86_64: OK
linux-4.2.8-i686: OK
linux-4.2.8-x86_64: OK
linux-4.3.6-i686: OK
linux-4.3.6-x86_64: OK
linux-4.4.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/Monday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html


Re: [PATCH] pulse8-cec: return 0 when invalidating the logical address

2018-12-02 Thread Hans Verkuil
On 12/02/2018 04:25 PM, Torbjorn Jansson wrote:
> On 2018-11-14 14:25, Hans Verkuil wrote:
>> Return 0 when invalidating the logical address. The cec core produces
>> a warning for drivers that do this.
>>
>> Signed-off-by: Hans Verkuil 
>> Reported-by: Torbjorn Jansson 
>> ---
>> diff --git a/drivers/media/usb/pulse8-cec/pulse8-cec.c 
>> b/drivers/media/usb/pulse8-cec/pulse8-cec.c
>> index 365c78b748dd..b085b14f3f87 100644
>> --- a/drivers/media/usb/pulse8-cec/pulse8-cec.c
>> +++ b/drivers/media/usb/pulse8-cec/pulse8-cec.c
>> @@ -586,7 +586,7 @@ static int pulse8_cec_adap_log_addr(struct cec_adapter 
>> *adap, u8 log_addr)
>>  else
>>  pulse8->config_pending = true;
>>  mutex_unlock(>config_lock);
>> -return err;
>> +return log_addr == CEC_LOG_ADDR_INVALID ? 0 : err;
>>   }
>>
>>   static int pulse8_cec_adap_transmit(struct cec_adapter *adap, u8 attempts,
>>
> 
> 
> question, is below warning also fixed by this patch? or is it a different 
> problem?
> note that this warning showed up without me unplugging the usb device.
> and cec-ctl have stopped working (again...)

Yes, same problem. Nothing to do with cec-ctl having stopped working.

The real problem is this (quoted from 
https://hverkuil.home.xs4all.nl/cec-status.txt,
end of the section "USB CEC Dongles"):

"I'm no systemd hero and sometimes it won't pick up the device, esp. at boot
time. I would be very happy if someone can take a good look at this and
come up with better ideas. As far as I can tell the CEC device is picked
up the first time it is connected to a USB port. But unplugging it, then
replugging it into the same USB port will not pick it up again. You need
to run inputattach manually in that case. It's something in udev/systemd,
but I have no idea how to fix it."

I have no time to chase this issue down. It probably requires contacting
some systemd mailinglist and talk to people who actually understand
systemd. If you want, you can give that a go.

Regards,

Hans


cron job: media_tree daily build: OK

2018-12-01 Thread Hans Verkuil
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:   Sun Dec  2 05:00:10 CET 2018
media-tree git hash:708d75fe1c7c6e9abc5381b6fcc32b49830383d0
media_build git hash:   47bf46ff21f75d1fe4ae3275a8692cb6ff77b6e8
v4l-utils git hash: cff58fcfbdf75381d5351f5ea8e7846f59cb7905
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: OK
linux-3.19.8-x86_64: OK
linux-4.0.9-i686: OK
linux-4.0.9-x86_64: OK
linux-4.1.52-i686: OK
linux-4.1.52-x86_64: OK
linux-4.2.8-i686: OK
linux-4.2.8-x86_64: OK
linux-4.3.6-i686: OK
linux-4.3.6-x86_64: OK
linux-4.4.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/Sunday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html


cron job: media_tree daily build: OK

2018-11-30 Thread Hans Verkuil
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:   Sat Dec  1 05:00:11 CET 2018
media-tree git hash:708d75fe1c7c6e9abc5381b6fcc32b49830383d0
media_build git hash:   47bf46ff21f75d1fe4ae3275a8692cb6ff77b6e8
v4l-utils git hash: cff58fcfbdf75381d5351f5ea8e7846f59cb7905
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: OK
linux-3.19.8-x86_64: OK
linux-4.0.9-i686: OK
linux-4.0.9-x86_64: OK
linux-4.1.52-i686: OK
linux-4.1.52-x86_64: OK
linux-4.2.8-i686: OK
linux-4.2.8-x86_64: OK
linux-4.3.6-i686: OK
linux-4.3.6-x86_64: OK
linux-4.4.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/Saturday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html


cron job: media_tree daily build: ERRORS

2018-11-29 Thread Hans Verkuil
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] Various fixes/enhancements

2018-11-29 Thread Hans Verkuil
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

2018-11-29 Thread Hans Verkuil
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

2018-11-29 Thread Hans Verkuil
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(-)


cron job: media_tree daily build: ERRORS

2018-11-28 Thread Hans Verkuil
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:   Thu Nov 29 05:00:11 CET 2018
media-tree git hash:708d75fe1c7c6e9abc5381b6fcc32b49830383d0
media_build git hash:   466e4e6f12eeffd6e9f6d91378c9169f7e6b8527
v4l-utils git hash: f2af3d3e99fb1a7ec215b4b47659e6e19783494b
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: WARNINGS
linux-git-arm-davinci: WARNINGS
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: WARNINGS
linux-git-arm-stm32: WARNINGS
linux-git-arm64: OK
linux-git-i686: WARNINGS
linux-git-mips: OK
linux-git-powerpc64: WARNINGS
linux-git-sh: OK
linux-git-x86_64: WARNINGS
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/Thursday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html


vicodec: set state resolution from raw format

2018-11-28 Thread Hans Verkuil
The state structure contains the resolution expected by the decoder
and encoder. For an encoder that resolution should be taken from the
OUTPUT format, and for a decoder from the CAPTURE format.

If the wrong format is picked, a buffer overrun can occur if there is
a mismatch between the CAPTURE and OUTPUT formats.

The real fix would be to correctly implement the stateful codec
specification, but that will take more time. For now just prevent the
buffer overrun.

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/media/platform/vicodec/vicodec-core.c 
b/drivers/media/platform/vicodec/vicodec-core.c
index 0f74fbe2e74c..e75bc263a113 100644
--- a/drivers/media/platform/vicodec/vicodec-core.c
+++ b/drivers/media/platform/vicodec/vicodec-core.c
@@ -1004,11 +1004,18 @@ static int vicodec_start_streaming(struct vb2_queue *q,

q_data->sequence = 0;

-   if (!V4L2_TYPE_IS_OUTPUT(q->type))
+   if (!V4L2_TYPE_IS_OUTPUT(q->type)) {
+   if (!ctx->is_enc) {
+   state->width = q_data->width;
+   state->height = q_data->height;
+   }
return 0;
+   }

-   state->width = q_data->width;
-   state->height = q_data->height;
+   if (ctx->is_enc) {
+   state->width = q_data->width;
+   state->height = q_data->height;
+   }
state->ref_frame.width = state->ref_frame.height = 0;
state->ref_frame.luma = kvmalloc(total_planes_size, GFP_KERNEL);
ctx->comp_max_size = total_planes_size + sizeof(struct fwht_cframe_hdr);


[PATCH] vicodec: move the GREY format to the end of the list

2018-11-28 Thread Hans Verkuil
With the GREY format at the beginning, the default format selected
by vicodec would be GREY instead of YUV420. That didn't make sense,
so move it to the end of the list.

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/media/platform/vicodec/codec-v4l2-fwht.c 
b/drivers/media/platform/vicodec/codec-v4l2-fwht.c
index ac5bb6836549..8cb0212df67f 100644
--- a/drivers/media/platform/vicodec/codec-v4l2-fwht.c
+++ b/drivers/media/platform/vicodec/codec-v4l2-fwht.c
@@ -11,7 +11,6 @@
 #include "codec-v4l2-fwht.h"

 static const struct v4l2_fwht_pixfmt_info v4l2_fwht_pixfmts[] = {
-   { V4L2_PIX_FMT_GREY,1, 1, 1, 1, 0, 1, 1, 1},
{ V4L2_PIX_FMT_YUV420,  1, 3, 2, 1, 1, 2, 2, 3},
{ V4L2_PIX_FMT_YVU420,  1, 3, 2, 1, 1, 2, 2, 3},
{ V4L2_PIX_FMT_YUV422P, 1, 2, 1, 1, 1, 2, 1, 3},
@@ -35,7 +34,7 @@ static const struct v4l2_fwht_pixfmt_info v4l2_fwht_pixfmts[] 
= {
{ V4L2_PIX_FMT_HSV32,   4, 4, 1, 4, 4, 1, 1, 3},
{ V4L2_PIX_FMT_ARGB32,  4, 4, 1, 4, 4, 1, 1, 4},
{ V4L2_PIX_FMT_ABGR32,  4, 4, 1, 4, 4, 1, 1, 4},
-
+   { V4L2_PIX_FMT_GREY,1, 1, 1, 1, 0, 1, 1, 1},
 };

 const struct v4l2_fwht_pixfmt_info *v4l2_fwht_find_pixfmt(u32 pixelformat)


[PATCH] vivid: add req_validate error injection

2018-11-28 Thread Hans Verkuil
Add a new vivid button control to inject an error into the req_validate request
callback.

This will help testing with v4l2-compliance.

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/media/platform/vivid/vivid-core.c 
b/drivers/media/platform/vivid/vivid-core.c
index c1b5976af3e6..1adf7cd86f60 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -629,8 +629,19 @@ static void vivid_dev_release(struct v4l2_device *v4l2_dev)
 }

 #ifdef CONFIG_MEDIA_CONTROLLER
+static int vivid_req_validate(struct media_request *req)
+{
+   struct vivid_dev *dev = container_of(req->mdev, struct vivid_dev, mdev);
+
+   if (dev->req_validate_error) {
+   dev->req_validate_error = false;
+   return -EINVAL;
+   }
+   return vb2_request_validate(req);
+}
+
 static const struct media_device_ops vivid_media_ops = {
-   .req_validate = vb2_request_validate,
+   .req_validate = vivid_req_validate,
.req_queue = vb2_request_queue,
 };
 #endif
diff --git a/drivers/media/platform/vivid/vivid-core.h 
b/drivers/media/platform/vivid/vivid-core.h
index 1891254c8f0b..a6b8d8625ec4 100644
--- a/drivers/media/platform/vivid/vivid-core.h
+++ b/drivers/media/platform/vivid/vivid-core.h
@@ -294,6 +294,7 @@ struct vivid_dev {
boolbuf_prepare_error;
boolstart_streaming_error;
booldqbuf_error;
+   boolreq_validate_error;
boolseq_wrap;
booltime_wrap;
u64 time_wrap_offset;
diff --git a/drivers/media/platform/vivid/vivid-ctrls.c 
b/drivers/media/platform/vivid/vivid-ctrls.c
index bfffeda12f14..4cd526ff248b 100644
--- a/drivers/media/platform/vivid/vivid-ctrls.c
+++ b/drivers/media/platform/vivid/vivid-ctrls.c
@@ -81,6 +81,7 @@
 #define VIVID_CID_START_STR_ERROR  (VIVID_CID_VIVID_BASE + 69)
 #define VIVID_CID_QUEUE_ERROR  (VIVID_CID_VIVID_BASE + 70)
 #define VIVID_CID_CLEAR_FB (VIVID_CID_VIVID_BASE + 71)
+#define VIVID_CID_REQ_VALIDATE_ERROR   (VIVID_CID_VIVID_BASE + 72)

 #define VIVID_CID_RADIO_SEEK_MODE  (VIVID_CID_VIVID_BASE + 90)
 #define VIVID_CID_RADIO_SEEK_PROG_LIM  (VIVID_CID_VIVID_BASE + 91)
@@ -1002,6 +1003,9 @@ static int vivid_streaming_s_ctrl(struct v4l2_ctrl *ctrl)
case VIVID_CID_START_STR_ERROR:
dev->start_streaming_error = true;
break;
+   case VIVID_CID_REQ_VALIDATE_ERROR:
+   dev->req_validate_error = true;
+   break;
case VIVID_CID_QUEUE_ERROR:
if (vb2_start_streaming_called(>vb_vid_cap_q))
vb2_queue_error(>vb_vid_cap_q);
@@ -1087,6 +1091,15 @@ static const struct v4l2_ctrl_config 
vivid_ctrl_queue_error = {
.type = V4L2_CTRL_TYPE_BUTTON,
 };

+#ifdef CONFIG_MEDIA_CONTROLLER
+static const struct v4l2_ctrl_config vivid_ctrl_req_validate_error = {
+   .ops = _streaming_ctrl_ops,
+   .id = VIVID_CID_REQ_VALIDATE_ERROR,
+   .name = "Inject req_validate() Error",
+   .type = V4L2_CTRL_TYPE_BUTTON,
+};
+#endif
+
 static const struct v4l2_ctrl_config vivid_ctrl_seq_wrap = {
.ops = _streaming_ctrl_ops,
.id = VIVID_CID_SEQ_WRAP,
@@ -1516,6 +1529,9 @@ int vivid_create_controls(struct vivid_dev *dev, bool 
show_ccs_cap,
v4l2_ctrl_new_custom(hdl_streaming, 
_ctrl_buf_prepare_error, NULL);
v4l2_ctrl_new_custom(hdl_streaming, 
_ctrl_start_streaming_error, NULL);
v4l2_ctrl_new_custom(hdl_streaming, _ctrl_queue_error, 
NULL);
+#ifdef CONFIG_MEDIA_CONTROLLER
+   v4l2_ctrl_new_custom(hdl_streaming, 
_ctrl_req_validate_error, NULL);
+#endif
v4l2_ctrl_new_custom(hdl_streaming, _ctrl_seq_wrap, NULL);
v4l2_ctrl_new_custom(hdl_streaming, _ctrl_time_wrap, 
NULL);
}


cron job: media_tree daily build: ERRORS

2018-11-27 Thread Hans Verkuil
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 Nov 28 05:00:12 CET 2018
media-tree git hash:708d75fe1c7c6e9abc5381b6fcc32b49830383d0
media_build git hash:   466e4e6f12eeffd6e9f6d91378c9169f7e6b8527
v4l-utils git hash: ff41164e10010be7209d3b7b98c209f98407a320
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: WARNINGS
linux-git-arm-davinci: WARNINGS
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: WARNINGS
linux-git-arm-stm32: WARNINGS
linux-git-arm64: OK
linux-git-i686: WARNINGS
linux-git-mips: OK
linux-git-powerpc64: WARNINGS
linux-git-sh: OK
linux-git-x86_64: WARNINGS
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/Wednesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html


[PATCH for v4.20] vb2: skip request checks for VIDIOC_PREPARE_BUF

2018-11-27 Thread Hans Verkuil
VIDIOC_PREPARE_BUF should ignore V4L2_BUF_FLAG_REQUEST_FD since it isn't
doing anything with requests. So inform vb2_queue_or_prepare_buf whether
it is called from vb2_prepare_buf or vb2_qbuf and just return 0 in the
first case.

This was found when adding new v4l2-compliance checks.

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c 
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 1244c246d0c4..1ac1b3f334f6 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -332,10 +332,10 @@ static int vb2_fill_vb2_v4l2_buffer(struct vb2_buffer 
*vb, struct v4l2_buffer *b
 }

 static int vb2_queue_or_prepare_buf(struct vb2_queue *q, struct media_device 
*mdev,
-   struct v4l2_buffer *b,
-   const char *opname,
+   struct v4l2_buffer *b, bool is_prepare,
struct media_request **p_req)
 {
+   const char *opname = is_prepare ? "prepare_buf" : "qbuf";
struct media_request *req;
struct vb2_v4l2_buffer *vbuf;
struct vb2_buffer *vb;
@@ -377,6 +377,9 @@ static int vb2_queue_or_prepare_buf(struct vb2_queue *q, 
struct media_device *md
return ret;
}

+   if (is_prepare)
+   return 0;
+
if (!(b->flags & V4L2_BUF_FLAG_REQUEST_FD)) {
if (q->uses_requests) {
dprintk(1, "%s: queue uses requests\n", opname);
@@ -656,7 +659,7 @@ int vb2_prepare_buf(struct vb2_queue *q, struct 
media_device *mdev,
if (b->flags & V4L2_BUF_FLAG_REQUEST_FD)
return -EINVAL;

-   ret = vb2_queue_or_prepare_buf(q, mdev, b, "prepare_buf", NULL);
+   ret = vb2_queue_or_prepare_buf(q, mdev, b, true, NULL);

return ret ? ret : vb2_core_prepare_buf(q, b->index, b);
 }
@@ -728,7 +731,7 @@ int vb2_qbuf(struct vb2_queue *q, struct media_device *mdev,
return -EBUSY;
}

-   ret = vb2_queue_or_prepare_buf(q, mdev, b, "qbuf", );
+   ret = vb2_queue_or_prepare_buf(q, mdev, b, false, );
if (ret)
return ret;
ret = vb2_core_qbuf(q, b->index, b, req);


cron job: media_tree daily build: ERRORS

2018-11-26 Thread Hans Verkuil
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Tue Nov 27 05:00:11 CET 2018
media-tree git hash:708d75fe1c7c6e9abc5381b6fcc32b49830383d0
media_build git hash:   466e4e6f12eeffd6e9f6d91378c9169f7e6b8527
v4l-utils git hash: dce0945e8220735174667cdc57e887cc11f720ee
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: WARNINGS
linux-git-arm-davinci: WARNINGS
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: WARNINGS
linux-git-arm-stm32: WARNINGS
linux-git-arm64: OK
linux-git-i686: WARNINGS
linux-git-mips: OK
linux-git-powerpc64: WARNINGS
linux-git-sh: OK
linux-git-x86_64: WARNINGS
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/Tuesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html


[GIT PULL FOR v4.21] venus fixes

2018-11-26 Thread Hans Verkuil
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.21f

for you to fetch changes up to 6d26aaad0d1e1d0588c07f6cffdfce0839fdb21c:

  media: venus: fix reported size of 0-length buffers (2018-11-26 14:31:00 
+0100)


Tag branch


Alexandre Courbot (1):
  media: venus: fix reported size of 0-length buffers

Malathi Gottam (3):
  media: venus: add support for USERPTR to queue
  media: venus: handle peak bitrate set property
  media: venus: dynamic handling of bitrate

 drivers/media/platform/qcom/venus/hfi_cmds.c   |  2 +-
 drivers/media/platform/qcom/venus/hfi_venus.c  |  2 ++
 drivers/media/platform/qcom/venus/vdec.c   |  4 +---
 drivers/media/platform/qcom/venus/venc.c   |  4 ++--
 drivers/media/platform/qcom/venus/venc_ctrls.c | 15 +++
 5 files changed, 21 insertions(+), 6 deletions(-)


Re: [PATCH v3] media: video-i2c: check if chip struct has set_power function

2018-11-26 Thread Hans Verkuil
On 11/25/2018 05:55 PM, Sakari Ailus wrote:
> Hi Matt,
> 
> On Sat, Nov 24, 2018 at 02:03:23PM -0800, Matt Ranostay wrote:
>> Not all future supported video chips will always have power management
>> support, and so it is important to check before calling set_power() is
>> defined.
>>
>> Cc: Sakari Ailus 
>> Cc: Hans Verkuil 
>> Cc: Mauro Carvalho Chehab 
>> Cc: Akinobu Mita 
>> Signed-off-by: Matt Ranostay 
>> ---
>>
>> Changes from v2:
>> - split out from mlx90640 patch series
>> - added to Cc list
>>
>> Changes from v1:
>> - none
>>
>>  drivers/media/i2c/video-i2c.c | 22 +-
>>  1 file changed, 17 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
>> index b6ebb8d53e90..01dcf179f203 100644
>> --- a/drivers/media/i2c/video-i2c.c
>> +++ b/drivers/media/i2c/video-i2c.c
>> @@ -736,9 +736,11 @@ static int video_i2c_probe(struct i2c_client *client,
>>  video_set_drvdata(>vdev, data);
>>  i2c_set_clientdata(client, data);
>>  
>> -ret = data->chip->set_power(data, true);
>> -if (ret)
>> -goto error_unregister_device;
>> +if (data->chip->set_power) {
>> +ret = data->chip->set_power(data, true);
>> +if (ret)
>> +goto error_unregister_device;
>> +}
> 
> How about adding a macro to call the op if it's set? It could be used to
> call other ops when they're set, and ignore them when they're not. Just an
> idea. See e.g. v4l2_subdev_call() in include/media/v4l2-subdev.h .

Matt, is this something you want to do? If so, then I'll wait for a v4.

Regards,

Hans

> 
>>  
>>  pm_runtime_get_noresume(>dev);
>>  pm_runtime_set_active(>dev);
>> @@ -767,7 +769,9 @@ static int video_i2c_probe(struct i2c_client *client,
>>  pm_runtime_disable(>dev);
>>  pm_runtime_set_suspended(>dev);
>>  pm_runtime_put_noidle(>dev);
>> -data->chip->set_power(data, false);
>> +
>> +if (data->chip->set_power)
>> +data->chip->set_power(data, false);
>>  
>>  error_unregister_device:
>>  v4l2_device_unregister(v4l2_dev);
>> @@ -791,7 +795,9 @@ static int video_i2c_remove(struct i2c_client *client)
>>  pm_runtime_disable(>dev);
>>  pm_runtime_set_suspended(>dev);
>>  pm_runtime_put_noidle(>dev);
>> -data->chip->set_power(data, false);
>> +
>> +if (data->chip->set_power)
>> +data->chip->set_power(data, false);
>>  
>>  video_unregister_device(>vdev);
>>  
>> @@ -804,6 +810,9 @@ static int video_i2c_pm_runtime_suspend(struct device 
>> *dev)
>>  {
>>  struct video_i2c_data *data = i2c_get_clientdata(to_i2c_client(dev));
>>  
>> +if (!data->chip->set_power)
>> +return 0;
>> +
>>  return data->chip->set_power(data, false);
>>  }
>>  
>> @@ -811,6 +820,9 @@ static int video_i2c_pm_runtime_resume(struct device 
>> *dev)
>>  {
>>  struct video_i2c_data *data = i2c_get_clientdata(to_i2c_client(dev));
>>  
>> +if (!data->chip->set_power)
>> +return 0;
>> +
>>  return data->chip->set_power(data, true);
>>  }
>>  
>> -- 
>> 2.17.1
>>
> 



cron job: media_tree daily build: ERRORS

2018-11-25 Thread Hans Verkuil
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:   Mon Nov 26 05:00:10 CET 2018
media-tree git hash:708d75fe1c7c6e9abc5381b6fcc32b49830383d0
media_build git hash:   a8aef9cea0a4a2f3ea86c0b37bd6a1378018c0c1
v4l-utils git hash: cdc046863805b3a3082890ce91f71538e0dbf88c
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: WARNINGS
linux-git-arm-davinci: WARNINGS
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: WARNINGS
linux-git-arm-stm32: WARNINGS
linux-git-arm64: OK
linux-git-i686: WARNINGS
linux-git-mips: OK
linux-git-powerpc64: WARNINGS
linux-git-sh: OK
linux-git-x86_64: WARNINGS
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: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.123-i686: ERRORS
linux-3.18.123-x86_64: ERRORS
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: ERRORS
linux-4.1.52-x86_64: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.159-i686: ERRORS
linux-4.4.159-x86_64: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.10-i686: ERRORS
linux-4.7.10-x86_64: ERRORS
linux-4.8.17-i686: ERRORS
linux-4.8.17-x86_64: ERRORS
linux-4.9.131-i686: ERRORS
linux-4.9.131-x86_64: ERRORS
linux-4.10.17-i686: ERRORS
linux-4.10.17-x86_64: ERRORS
linux-4.11.12-i686: ERRORS
linux-4.11.12-x86_64: ERRORS
linux-4.12.14-i686: ERRORS
linux-4.12.14-x86_64: ERRORS
linux-4.13.16-i686: ERRORS
linux-4.13.16-x86_64: ERRORS
linux-4.14.74-i686: ERRORS
linux-4.14.74-x86_64: ERRORS
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/Monday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html


cron job: media_tree daily build: ERRORS

2018-11-24 Thread Hans Verkuil
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:   Sun Nov 25 05:00:10 CET 2018
media-tree git hash:708d75fe1c7c6e9abc5381b6fcc32b49830383d0
media_build git hash:   a8aef9cea0a4a2f3ea86c0b37bd6a1378018c0c1
v4l-utils git hash: cdc046863805b3a3082890ce91f71538e0dbf88c
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: WARNINGS
linux-git-arm-davinci: WARNINGS
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: WARNINGS
linux-git-arm-stm32: WARNINGS
linux-git-arm64: OK
linux-git-i686: WARNINGS
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-sh: OK
linux-git-x86_64: WARNINGS
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: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.123-i686: ERRORS
linux-3.18.123-x86_64: ERRORS
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: ERRORS
linux-4.1.52-x86_64: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.159-i686: ERRORS
linux-4.4.159-x86_64: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.10-i686: ERRORS
linux-4.7.10-x86_64: ERRORS
linux-4.8.17-i686: ERRORS
linux-4.8.17-x86_64: ERRORS
linux-4.9.131-i686: ERRORS
linux-4.9.131-x86_64: ERRORS
linux-4.10.17-i686: ERRORS
linux-4.10.17-x86_64: ERRORS
linux-4.11.12-i686: ERRORS
linux-4.11.12-x86_64: ERRORS
linux-4.12.14-i686: ERRORS
linux-4.12.14-x86_64: ERRORS
linux-4.13.16-i686: ERRORS
linux-4.13.16-x86_64: ERRORS
linux-4.14.74-i686: ERRORS
linux-4.14.74-x86_64: ERRORS
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/Sunday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html


Re: [ragnatech:media-tree 32/140] drivers/media/platform/seco-cec/seco-cec.c:237:4: error: implicit declaration of function 'cec_transmit_attempt_done'

2018-11-24 Thread Hans Verkuil
On 11/24/2018 07:14 PM, Ettore Chimenti wrote:
> Hi all,
> Is this error relevant?
> I tried compiling on 'ragnatech/media-tree' 
> (708d75fe1c7c6e9abc5381b6fcc32b49830383d0) without getting errors.

This was fixed by this patch:

https://patchwork.linuxtv.org/patch/53117/

Which is why it now works.

Regards,

Hans

> 
> Thanks,
> Ettore
> 
> Il giorno sab 24 nov 2018 alle ore 18:07 kbuild test robot  > ha scritto:
> 
> tree:   git://git.ragnatech.se/linux  
> media-tree
> head:   708d75fe1c7c6e9abc5381b6fcc32b49830383d0
> commit: b03c2fb97adcc65d3c4098c4aa41fbaa6623ebf2 [32/140] media: add SECO 
> cec driver
> config: i386-randconfig-x006-201847 (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> reproduce:
> git checkout b03c2fb97adcc65d3c4098c4aa41fbaa6623ebf2
> # save the attached .config to linux build tree
> make ARCH=i386
> 
> Note: the ragnatech/media-tree HEAD 
> 708d75fe1c7c6e9abc5381b6fcc32b49830383d0 builds fine.
>   It only hurts bisectibility.
> 
> All error/warnings (new ones prefixed by >>):
> 
>drivers/media/platform/seco-cec/seco-cec.c: In function 
> 'secocec_tx_done':
> >> drivers/media/platform/seco-cec/seco-cec.c:237:4: error: implicit 
> declaration of function 'cec_transmit_attempt_done'
> [-Werror=implicit-function-declaration]
>cec_transmit_attempt_done(adap, CEC_TX_STATUS_NACK);
>^
>drivers/media/platform/seco-cec/seco-cec.c: In function 
> 'secocec_rx_done':
> >> drivers/media/platform/seco-cec/seco-cec.c:316:2: error: implicit 
> declaration of function 'cec_received_msg'; did you mean
> 'free_reserved_page'? [-Werror=implicit-function-declaration]
>  cec_received_msg(cec->cec_adap, );
>  ^~~~
>  free_reserved_page
>drivers/media/platform/seco-cec/seco-cec.c: In function 
> 'secocec_probe':
> >> drivers/media/platform/seco-cec/seco-cec.c:527:22: error: implicit 
> declaration of function 'cec_allocate_adapter'; did you mean
> 'cec_delete_adapter'? [-Werror=implicit-function-declaration]
>  secocec->cec_adap = cec_allocate_adapter(_cec_adap_ops,
>  ^~~~
>  cec_delete_adapter
> >> drivers/media/platform/seco-cec/seco-cec.c:527:20: warning: assignment 
> makes pointer from integer without a cast [-Wint-conversion]
>  secocec->cec_adap = cec_allocate_adapter(_cec_adap_ops,
>^
>cc1: some warnings being treated as errors
> 
> vim +/cec_transmit_attempt_done +237 
> drivers/media/platform/seco-cec/seco-cec.c
> 
>232 
>233  static void secocec_tx_done(struct cec_adapter *adap, u16 
> status_val)
>234  {
>235  if (status_val & SECOCEC_STATUS_TX_ERROR_MASK) {
>236  if (status_val & SECOCEC_STATUS_TX_NACK_ERROR)
>  > 237  cec_transmit_attempt_done(adap, 
> CEC_TX_STATUS_NACK);
>238  else
>239  cec_transmit_attempt_done(adap, 
> CEC_TX_STATUS_ERROR);
>240  } else {
>241  cec_transmit_attempt_done(adap, CEC_TX_STATUS_OK);
>242  }
>243 
>244  /* Reset status reg */
>245  status_val = SECOCEC_STATUS_TX_ERROR_MASK |
>246  SECOCEC_STATUS_MSG_SENT_MASK |
>247  SECOCEC_STATUS_TX_NACK_ERROR;
>248  smb_wr16(SECOCEC_STATUS, status_val);
>249  }
>250 
>251  static void secocec_rx_done(struct cec_adapter *adap, u16 
> status_val)
>252  {
>253  struct secocec_data *cec = cec_get_drvdata(adap);
>254  struct device *dev = cec->dev;
>255  struct cec_msg msg = { };
>256  bool flag_overflow = false;
>257  u8 payload_len, i = 0;
>258  u8 *payload_msg;
>259  u16 val = 0;
>260  int status;
>261 
>262  if (status_val & SECOCEC_STATUS_RX_OVERFLOW_MASK) {
>263  /* NOTE: Untested, it also might not be necessary 
> */
>264  dev_warn(dev, "Received more than 16 bytes. 
> Discarding");
>265  flag_overflow = true;
>266  }
>267 
>268  if (status_val & SECOCEC_STATUS_RX_ERROR_MASK) {
>269  dev_warn(dev, "Message received with errors. 
> Discarding");
>270  status = -EIO;
>271  goto rxerr;
>272  }
>273 
>274  /* Read message length */
>275  status = smb_rd16(SECOCEC_READ_DATA_LENGTH, );
>   

cron job: media_tree daily build: ERRORS

2018-11-23 Thread Hans Verkuil
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:   Sat Nov 24 05:00:11 CET 2018
media-tree git hash:708d75fe1c7c6e9abc5381b6fcc32b49830383d0
media_build git hash:   a8aef9cea0a4a2f3ea86c0b37bd6a1378018c0c1
v4l-utils git hash: cdc046863805b3a3082890ce91f71538e0dbf88c
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: WARNINGS
linux-git-arm-davinci: WARNINGS
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: WARNINGS
linux-git-arm-stm32: WARNINGS
linux-git-arm64: WARNINGS
linux-git-i686: WARNINGS
linux-git-mips: OK
linux-git-powerpc64: WARNINGS
linux-git-sh: OK
linux-git-x86_64: WARNINGS
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: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.123-i686: ERRORS
linux-3.18.123-x86_64: ERRORS
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: ERRORS
linux-4.1.52-x86_64: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.159-i686: ERRORS
linux-4.4.159-x86_64: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.10-i686: ERRORS
linux-4.7.10-x86_64: ERRORS
linux-4.8.17-i686: ERRORS
linux-4.8.17-x86_64: ERRORS
linux-4.9.131-i686: ERRORS
linux-4.9.131-x86_64: ERRORS
linux-4.10.17-i686: ERRORS
linux-4.10.17-x86_64: ERRORS
linux-4.11.12-i686: ERRORS
linux-4.11.12-x86_64: ERRORS
linux-4.12.14-i686: ERRORS
linux-4.12.14-x86_64: ERRORS
linux-4.13.16-i686: ERRORS
linux-4.13.16-x86_64: ERRORS
linux-4.14.74-i686: ERRORS
linux-4.14.74-x86_64: ERRORS
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/Saturday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html


Re: [PATCH] media: vb2: be sure to free on errors

2018-11-23 Thread Hans Verkuil
On 11/23/2018 01:07 PM, Mauro Carvalho Chehab wrote:
> As reported by smatch:
> drivers/media/common/videobuf2/videobuf2-core.c: 
> drivers/media/common/videobuf2/videobuf2-core.c:2159 vb2_mmap() warn: 
> inconsistent returns 'mutex:>mmap_lock'.
>   Locked on:   line 2148
>   Unlocked on: line 2100
>line 2108
>line 2113
>line 2118
>line 2156
>line 2159
> 
> There is one error condition that doesn't unlock a mutex.
> 
> Fixes: cd26d1c4d1bc ("media: vb2: vb2_mmap: move lock up")
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Hans Verkuil 

Hmm, that's embarrassing... I should have seen that smatch warning.

Regards,

Hans

> ---
>  drivers/media/common/videobuf2/videobuf2-core.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
> b/drivers/media/common/videobuf2/videobuf2-core.c
> index 04d1250747cf..0ca81d495bda 100644
> --- a/drivers/media/common/videobuf2/videobuf2-core.c
> +++ b/drivers/media/common/videobuf2/videobuf2-core.c
> @@ -2145,7 +2145,8 @@ int vb2_mmap(struct vb2_queue *q, struct vm_area_struct 
> *vma)
>   if (length < (vma->vm_end - vma->vm_start)) {
>   dprintk(1,
>   "MMAP invalid, as it would overflow buffer length\n");
> - return -EINVAL;
> + ret = -EINVAL;
> + goto unlock;
>   }
>  
>   ret = call_memop(vb, mmap, vb->planes[plane].mem_priv, vma);
> 



[PATCH] vivid: fix smatch warnings

2018-11-23 Thread Hans Verkuil
Reorganize code to fix two smatch warnings:

drivers/media/platform/vivid/vivid-core.c: 
drivers/media/platform/vivid/vivid-core.c:889 vivid_create_instance() warn: 
potentially one past the end of array
'dev->query_dv_timings_qmenu[dev->query_dv_timings_size]'
drivers/media/platform/vivid/vivid-core.c: 
drivers/media/platform/vivid/vivid-core.c:889 vivid_create_instance() warn: 
potentially one past the end of array
'dev->query_dv_timings_qmenu[dev->query_dv_timings_size]'

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/vivid/vivid-core.c | 24 +--
 drivers/media/platform/vivid/vivid-core.h |  1 +
 2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/vivid/vivid-core.c 
b/drivers/media/platform/vivid/vivid-core.c
index bc7307183b1d..e64137611026 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -625,6 +625,7 @@ static void vivid_dev_release(struct v4l2_device *v4l2_dev)
vfree(dev->bitmap_out);
tpg_free(>tpg);
kfree(dev->query_dv_timings_qmenu);
+   kfree(dev->query_dv_timings_qmenu_strings);
kfree(dev);
 }

@@ -874,20 +875,31 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
if (!dev->edid)
goto free_dev;

-   /* create a string array containing the names of all the preset timings 
*/
while (v4l2_dv_timings_presets[dev->query_dv_timings_size].bt.width)
dev->query_dv_timings_size++;
+
+   /*
+* Create a char pointer array that points to the names of all the
+* preset timings
+*/
dev->query_dv_timings_qmenu = kmalloc_array(dev->query_dv_timings_size,
-   (sizeof(void *) + 32),
-   GFP_KERNEL);
-   if (dev->query_dv_timings_qmenu == NULL)
+   sizeof(char *), GFP_KERNEL);
+   /*
+* Create a string array containing the names of all the preset
+* timings. Each name is max 31 chars long (+ terminating 0).
+*/
+   dev->query_dv_timings_qmenu_strings =
+   kmalloc_array(dev->query_dv_timings_size, 32, GFP_KERNEL);
+
+   if (!dev->query_dv_timings_qmenu ||
+   !dev->query_dv_timings_qmenu_strings)
goto free_dev;
+
for (i = 0; i < dev->query_dv_timings_size; i++) {
const struct v4l2_bt_timings *bt = 
_dv_timings_presets[i].bt;
-   char *p = (char 
*)>query_dv_timings_qmenu[dev->query_dv_timings_size];
+   char *p = dev->query_dv_timings_qmenu_strings + i * 32;
u32 htot, vtot;

-   p += i * 32;
dev->query_dv_timings_qmenu[i] = p;

htot = V4L2_DV_BT_FRAME_WIDTH(bt);
diff --git a/drivers/media/platform/vivid/vivid-core.h 
b/drivers/media/platform/vivid/vivid-core.h
index 1891254c8f0b..0bec2c3401d2 100644
--- a/drivers/media/platform/vivid/vivid-core.h
+++ b/drivers/media/platform/vivid/vivid-core.h
@@ -305,6 +305,7 @@ struct vivid_dev {

enum vivid_signal_mode  dv_timings_signal_mode;
char**query_dv_timings_qmenu;
+   char*query_dv_timings_qmenu_strings;
unsignedquery_dv_timings_size;
unsignedquery_dv_timings_last;
unsignedquery_dv_timings;
-- 
2.19.1



[PATCH] seco-cec: fix Makefile

2018-11-23 Thread Hans Verkuil
Fix the incorrect obj-y.

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/media/platform/seco-cec/Makefile 
b/drivers/media/platform/seco-cec/Makefile
index 09900b087d02..a3f2c6bd3ac0 100644
--- a/drivers/media/platform/seco-cec/Makefile
+++ b/drivers/media/platform/seco-cec/Makefile
@@ -1 +1 @@
-obj-y += seco-cec.o
+obj-$(CONFIG_VIDEO_SECO_CEC) += seco-cec.o



[GIT PULL FOR v4.21 v2] mem2mem, venus and vb2 fixes/improvements

2018-11-23 Thread Hans Verkuil
(Fixed my SoB mess)

The following changes since commit fbe57dde7126d1b2712ab5ea93fb9d15f89de708:

  media: ov7740: constify structures stored in fields of v4l2_subdev_ops 
structure (2018-11-06 07:17:02 -0500)

are available in the Git repository at:

  git://linuxtv.org/hverkuil/media_tree.git tags/br-v4.21e2

for you to fetch changes up to 67a4b0da269c44e3efb59ec471566d48268bd23d:

  videobuf2-v4l2: drop WARN_ON in vb2_warn_zero_bytesused() (2018-11-23 
09:44:43 +0100)


Tag branch


Ezequiel Garcia (4):
  mem2mem: Require capture and output mutexes to match
  v4l2-ioctl.c: Simplify locking for m2m devices
  v4l2-mem2mem: Avoid calling .device_run in v4l2_m2m_job_finish
  media: cedrus: Get rid of interrupt bottom-half

Hans Verkuil (1):
  videobuf2-v4l2: drop WARN_ON in vb2_warn_zero_bytesused()

John Sheu (1):
  media: vb2: Allow reqbufs(0) with "in use" MMAP buffers

Sakari Ailus (1):
  v4l2-mem2mem: Simplify exiting the function in __v4l2_m2m_try_schedule

Stanimir Varbanov (1):
  venus: firmware: register separate platform_device for firmware loader

vgaro...@codeaurora.org (4):
  venus: firmware: add routine to reset ARM9
  venus: firmware: move load firmware in a separate function
  venus: firmware: add no TZ boot and shutdown routine
  dt-bindings: media: Document bindings for venus firmware device

 Documentation/devicetree/bindings/media/qcom,venus.txt |  14 ++-
 Documentation/media/uapi/v4l/vidioc-reqbufs.rst|  17 +++-
 drivers/media/common/videobuf2/videobuf2-core.c|   8 +-
 drivers/media/common/videobuf2/videobuf2-v4l2.c|   3 +-
 drivers/media/platform/qcom/venus/core.c   |  24 +++--
 drivers/media/platform/qcom/venus/core.h   |   6 ++
 drivers/media/platform/qcom/venus/firmware.c   | 235 
+++-
 drivers/media/platform/qcom/venus/firmware.h   |  17 +++-
 drivers/media/platform/qcom/venus/hfi_venus.c  |  13 +--
 drivers/media/platform/qcom/venus/hfi_venus_io.h   |   8 ++
 drivers/media/v4l2-core/v4l2-ioctl.c   |  47 +-
 drivers/media/v4l2-core/v4l2-mem2mem.c |  66 +-
 drivers/staging/media/sunxi/cedrus/cedrus_hw.c |  26 ++
 include/uapi/linux/videodev2.h |   1 +
 14 files changed, 344 insertions(+), 141 deletions(-)


[GIT PULL FOR v4.21 v2] Various fixes/improvements

2018-11-23 Thread Hans Verkuil
The following changes since commit 5200ab6a32d6055428896a49ec9e3b1652c1a100:

  media: vidioc_cropcap -> vidioc_g_pixelaspect (2018-11-20 13:57:21 -0500)

are available in the Git repository at:

  git://linuxtv.org/hverkuil/media_tree.git tags/br-v4.20d3

for you to fetch changes up to d5d871b0c676aed893d928a2ad3ac69c55f1da8c:

  media: vicodec: Add support for 4 planes formats (2018-11-23 09:37:43 +0100)


Tag branch


Akinobu Mita (5):
  media: video-i2c: avoid accessing released memory area when removing 
driver
  media: video-i2c: use i2c regmap
  media: v4l2-common: add V4L2_FRACT_COMPARE
  media: vivid: use V4L2_FRACT_COMPARE
  media: video-i2c: support changing frame interval

Alexey Khoroshilov (1):
  media: mtk-vcodec: Release device nodes in mtk_vcodec_init_enc_pm()

Dafna Hirschfeld (3):
  media: vicodec: prepare support for various number of planes
  media: vicodec: Add support of greyscale format
  media: vicodec: Add support for 4 planes formats

Eric Biggers (1):
  media: v4l: constify v4l2_ioctls[]

Hans Verkuil (2):
  vim2m/vicodec: set device_caps in video_device struct
  vidioc-enum-fmt.rst: update list of valid buftypes

Julia Lawall (1):
  media: video-i2c: hwmon: constify vb2_ops structure

Malathi Gottam (1):
  media: venus: change the default value of GOP size

 Documentation/media/uapi/v4l/vidioc-enum-fmt.rst  |   8 ++-
 drivers/media/i2c/video-i2c.c | 153 
+++--
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c |  10 ++--
 drivers/media/platform/qcom/venus/venc_ctrls.c|   2 +-
 drivers/media/platform/vicodec/codec-fwht.c   |  84 
+--
 drivers/media/platform/vicodec/codec-fwht.h   |  15 +++--
 drivers/media/platform/vicodec/codec-v4l2-fwht.c  | 123 
+--
 drivers/media/platform/vicodec/codec-v4l2-fwht.h  |   3 +-
 drivers/media/platform/vicodec/vicodec-core.c |  45 +++
 drivers/media/platform/vim2m.c|   3 +-
 drivers/media/platform/vivid/vivid-vid-cap.c  |   9 +--
 drivers/media/v4l2-core/v4l2-ioctl.c  |   2 +-
 include/media/v4l2-common.h   |   5 ++
 13 files changed, 328 insertions(+), 134 deletions(-)


[GIT PULL FOR v4.21 v2] Various fixes

2018-11-23 Thread Hans Verkuil
(fixed my SoB mess in this v2)

Various fixes, mostly related to issues found by syzbot.

The following changes since commit fbe57dde7126d1b2712ab5ea93fb9d15f89de708:

  media: ov7740: constify structures stored in fields of v4l2_subdev_ops 
structure (2018-11-06 07:17:02 -0500)

are available in the Git repository at:

  git://linuxtv.org/hverkuil/media_tree.git tags/br-v4.21b2

for you to fetch changes up to 3f444acfa6f43e2e9b23907fc820e3e51339565c:

  vivid: free bitmap_cap when updating std/timings/etc. (2018-11-23 09:31:39 
+0100)


Tag branch


Hans Verkuil (6):
  vim2m: use cancel_delayed_work_sync instead of flush_schedule_work
  adv*/tc358743/ths8200: fill in min width/height/pixelclock
  vb2: check memory model for VIDIOC_CREATE_BUFS
  MAINTAINERS fixups
  v4l2-tpg: array index could become negative
  vivid: free bitmap_cap when updating std/timings/etc.

 MAINTAINERS | 10 --
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c   |  2 +-
 drivers/media/common/videobuf2/videobuf2-core.c |  3 +++
 drivers/media/i2c/ad9389b.c |  2 +-
 drivers/media/i2c/adv7511.c |  2 +-
 drivers/media/i2c/adv7604.c |  4 ++--
 drivers/media/i2c/adv7842.c |  4 ++--
 drivers/media/i2c/tc358743.c|  2 +-
 drivers/media/i2c/ths8200.c |  2 +-
 drivers/media/platform/vim2m.c  |  3 ++-
 drivers/media/platform/vivid/vivid-vid-cap.c|  2 ++
 11 files changed, 20 insertions(+), 16 deletions(-)


[GIT PULL FOR v4.21 v2] Various fixes

2018-11-23 Thread Hans Verkuil
(fixed up my SoB mess)

Just one note: the "cec: keep track of outstanding transmits" is CC-ed to stable
for v4.18 and up, but I prefer to wait until v4.21 before merging it to give it
more test time. It is not something that happens in normal usage, so delaying
this isn't a problem.

Regards,

Hans

The following changes since commit fbe57dde7126d1b2712ab5ea93fb9d15f89de708:

  media: ov7740: constify structures stored in fields of v4l2_subdev_ops 
structure (2018-11-06 07:17:02 -0500)

are available in the Git repository at:

  git://linuxtv.org/hverkuil/media_tree.git tags/br-v4.21a2

for you to fetch changes up to 9001e4d520f11d344f10092d3217156ec10c6934:

  vivid: fill in media_device bus_info (2018-11-23 09:26:54 +0100)


Tag branch

----
Hans Verkuil (7):
  adv7604: add CEC support for adv7611/adv7612
  cec: report Vendor ID after initialization
  cec: add debug_phys_addr module option
  cec: keep track of outstanding transmits
  vivid: fix error handling of kthread_run
  vivid: set min width/height to a value > 0
  vivid: fill in media_device bus_info

Julia Lawall (4):
  media: vicodec: constify v4l2_ctrl_ops structure
  media: rockchip/rga: constify v4l2_m2m_ops structure
  media: vimc: constify structures stored in fields of v4l2_subdev_ops 
structure
  media: rockchip/rga: constify video_device structure

Sean Young (1):
  media: v4l uapi docs: few minor corrections and typos

 Documentation/media/uapi/v4l/app-pri.rst |  2 +-
 Documentation/media/uapi/v4l/audio.rst   |  2 +-
 Documentation/media/uapi/v4l/dev-capture.rst |  2 +-
 Documentation/media/uapi/v4l/dev-teletext.rst|  2 +-
 Documentation/media/uapi/v4l/format.rst  |  2 +-
 Documentation/media/uapi/v4l/mmap.rst| 22 +--
 Documentation/media/uapi/v4l/open.rst|  2 +-
 Documentation/media/uapi/v4l/tuner.rst   |  4 ++--
 Documentation/media/uapi/v4l/userp.rst   |  8 +++
 Documentation/media/uapi/v4l/video.rst   |  4 ++--
 drivers/media/cec/cec-adap.c | 34 
++
 drivers/media/cec/cec-core.c |  6 ++
 drivers/media/i2c/adv7604.c  | 63 
++-
 drivers/media/platform/rockchip/rga/rga.c|  4 ++--
 drivers/media/platform/vicodec/vicodec-core.c|  2 +-
 drivers/media/platform/vimc/vimc-sensor.c|  2 +-
 drivers/media/platform/vivid/vivid-core.c|  2 ++
 drivers/media/platform/vivid/vivid-kthread-cap.c |  5 -
 drivers/media/platform/vivid/vivid-kthread-out.c |  5 -
 drivers/media/platform/vivid/vivid-vid-common.c  |  2 +-
 include/media/cec.h  |  1 +
 21 files changed, 125 insertions(+), 51 deletions(-)


[GIT PULL FOR v4.21 v2] Various fixes (coda, rcar, pxp, others)

2018-11-23 Thread Hans Verkuil
Fixed my SoB mess.

Regards,

Hans

The following changes since commit fbe57dde7126d1b2712ab5ea93fb9d15f89de708:

  media: ov7740: constify structures stored in fields of v4l2_subdev_ops 
structure (2018-11-06 07:17:02 -0500)

are available in the Git repository at:

  git://linuxtv.org/hverkuil/media_tree.git tags/br-v4.21c

for you to fetch changes up to fb248101254782a3939c40eaaa7e347260b27b77:

  pulse8-cec: return 0 when invalidating the logical address (2018-11-14 
16:07:47 +0100)


Tag branch


Fabio Estevam (3):
  media: imx-pxp: Check the return value from clk_prepare_enable()
  media: imx-pxp: Check for pxp_soft_reset() error
  media: imx-pxp: Improve pxp_soft_reset() error message

Hans Verkuil (3):
  vb2: vb2_mmap: move lock up
  cec-pin: fix broken tx_ignore_nack_until_eom error injection
  pulse8-cec: return 0 when invalidating the logical address

Jacopo Mondi (6):
  media: dt-bindings: rcar-vin: Add R8A77990 support
  media: rcar-vin: Add support for R-Car R8A77990
  media: dt-bindings: rcar-csi2: Add R8A77990
  media: rcar-csi2: Add R8A77990 support
  media: rcar: rcar-csi2: Update V3M/E3 PHTW tables
  media: rcar-csi2: Handle per-SoC number of channels

Lucas Stach (2):
  media: coda: limit queueing into internal bitstream buffer
  media: coda: don't disable IRQs across buffer meta handling

Michael Tretter (1):
  media: coda: print SEQ_INIT error code as hex value

Philipp Zabel (12):
  media: coda: fix memory corruption in case more than 32 instances are 
opened
  media: coda: store unmasked fifo position in meta
  media: coda: always hold back decoder jobs until we have enough bitstream 
payload
  media: coda: reduce minimum frame size to 48x16 pixels.
  media: coda: remove unused instances list
  media: coda: set V4L2_CAP_TIMEPERFRAME flag in coda_s_parm
  media: coda: implement ENUM_FRAMEINTERVALS
  media: coda: never set infinite timeperframe
  media: coda: fail S_SELECTION for read-only targets
  media: coda: improve queue busy error message
  media: coda: normalise debug output
  media: coda: debug output when setting visible size via crop selection

Ricardo Ribalda Delgado (1):
  media: doc-rst: Fix broken references

kbuild test robot (1):
  media: platform: fix platform_no_drv_owner.cocci warnings

 Documentation/devicetree/bindings/media/rcar_vin.txt  |   1 +
 Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt |   1 +
 Documentation/media/v4l-drivers/sh_mobile_ceu_camera.rst  |   2 +-
 drivers/media/cec/cec-pin.c   |   5 +-
 drivers/media/common/videobuf2/videobuf2-core.c   |  11 +-
 drivers/media/platform/coda/coda-bit.c| 113 
+++-
 drivers/media/platform/coda/coda-common.c | 231 
++---
 drivers/media/platform/coda/coda.h|  28 -
 drivers/media/platform/coda/trace.h   |  10 +-
 drivers/media/platform/imx-pxp.c  |  17 ++-
 drivers/media/platform/rcar-vin/rcar-core.c   |  20 
 drivers/media/platform/rcar-vin/rcar-csi2.c   |  86 
+--
 drivers/media/platform/sh_vou.c   |   2 +-
 drivers/media/usb/pulse8-cec/pulse8-cec.c |   2 +-
 drivers/staging/media/sunxi/cedrus/cedrus.c   |   1 -
 15 files changed, 319 insertions(+), 211 deletions(-)


cron job: media_tree daily build: WARNINGS

2018-11-22 Thread Hans Verkuil
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 23 05:00:11 CET 2018
media-tree git hash:8e782fcf78275f505194e767c515202d4fd274bc
media_build git hash:   a8aef9cea0a4a2f3ea86c0b37bd6a1378018c0c1
v4l-utils git hash: f3d77d6df975b6fb8fbf9f9f8fe2c4a809136b86
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: WARNINGS
linux-git-arm-davinci: WARNINGS
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: WARNINGS
linux-git-arm-stm32: WARNINGS
linux-git-arm64: OK
linux-git-i686: WARNINGS
linux-git-mips: OK
linux-git-powerpc64: WARNINGS
linux-git-sh: OK
linux-git-x86_64: WARNINGS
Check COMPILE_TEST: OK
linux-3.10.108-i686: OK
linux-3.10.108-x86_64: OK
linux-3.11.10-i686: OK
linux-3.11.10-x86_64: OK
linux-3.12.74-i686: OK
linux-3.12.74-x86_64: OK
linux-3.13.11-i686: OK
linux-3.13.11-x86_64: OK
linux-3.14.79-i686: OK
linux-3.14.79-x86_64: OK
linux-3.15.10-i686: OK
linux-3.15.10-x86_64: OK
linux-3.16.57-i686: OK
linux-3.16.57-x86_64: OK
linux-3.17.8-i686: OK
linux-3.17.8-x86_64: OK
linux-3.18.123-i686: OK
linux-3.18.123-x86_64: OK
linux-3.19.8-i686: OK
linux-3.19.8-x86_64: OK
linux-4.0.9-i686: OK
linux-4.0.9-x86_64: OK
linux-4.1.52-i686: OK
linux-4.1.52-x86_64: OK
linux-4.2.8-i686: OK
linux-4.2.8-x86_64: OK
linux-4.3.6-i686: OK
linux-4.3.6-x86_64: OK
linux-4.4.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


Re: [GIT PULL FOR v4.18] v2: Various fixes/improvements

2018-11-22 Thread Hans Verkuil
On 11/22/2018 09:52 PM, Mauro Carvalho Chehab wrote:
> Em Tue, 8 May 2018 12:48:45 +0200
> Hans Verkuil  escreveu:
> 
>> Fixes/improvements all over the place.
>>
>> Changes since v1:
>>
>> Replaced "media: media-device: fix ioctl function types" with the v2 version
>> of that patch. My fault, I missed Sakari's request for a change of v1.
> 
> You should seriously review how you're adding SOBs... there are
> even some like:
> 
> Signed-off-by Hans Verkuil 
> Reported-by: syzbot+69780d144754b8071...@syzkaller.appspotmail.com
> Cc:   # for v4.20 and up
> Signed-off-by Hans Verkuil 

You seem to have replied to a different git pull request (v4.18?!) then
what these lines above indicate, but it appears that this refers to patch
"vim2m: use cancel_delayed_work_sync instead of flush_schedule_work".

It looks like I just completely mistyped the SoB in that patch. Nothing to do
with the xs4all vs cisco SoBs and AFAICS it is an issue just with that patch.

Regarding those, the core problem is that I want to show that what I'm doing is
paid for by Cisco, but I don't want to use the cisco email address to actually
send patches, pull requests, etc., since that requires a vpn which is really 
annoying.

I've made a new email alias hverkuil-ci...@xs4all.nl (I'm not allowed to use a 
'+'
unfortunately) and I think I will use that as my git email address to avoid
cisco.com entirely.

Regarding the outstanding pull requests with SoB/Author mismatches: should I 
redo
those and repost? It's a pain, but if you want it I'll do that tomorrow.

Regards,

Hans

> 
> On this series. Again, none matching the Author's email.
> 
> PS.: one quick way to fix it is by using git filter.
> 
> You could do something like:
> 
> $ git filter-branch -f --msg-filter 'cat|grep -v "Signed-off-by: Your Name"; 
> echo "Signed-off-by: Your Name "' origin/master..
> 
> And fix all of them with a single command.
> 
>>
>> Regards,
>>
>>  Hans
>>
>> The following changes since commit f10379aad39e9da8bc7d1822e251b5f0673067ef:
>>
>>   media: include/video/omapfb_dss.h: use IS_ENABLED() (2018-05-05 11:45:51 
>> -0400)
>>
>> are available in the Git repository at:
>>
>>   git://linuxtv.org/hverkuil/media_tree.git for-v4.18b
>>
>> for you to fetch changes up to 171d364998d1e2373c12b93924fe63cc71586101:
>>
>>   media: media-device: fix ioctl function types (2018-05-08 12:40:23 +0200)
>>
>> 
>> Arvind Yadav (2):
>>   platform: Use gpio_is_valid()
>>   sta2x11: Use gpio_is_valid() and remove unnecessary check
>>
>> Brad Love (4):
>>   em28xx: Fix DualHD broken second tuner
>>   intel-ipu3: Kconfig coding style issue
>>   cec: Kconfig coding style issue
>>   saa7164: Fix driver name in debug output
>>
>> Colin Ian King (1):
>>   media/usbvision: fix spelling mistake: "compresion" -> "compression"
>>
>> Dan Carpenter (1):
>>   media: vpbe_venc: potential uninitialized variable in 
>> ven_sub_dev_init()
>>
>> Fengguang Wu (1):
>>   media: vcodec: fix ptr_ret.cocci warnings
>>
>> Hans Verkuil (2):
>>   cec-gpio: use GPIOD_OUT_HIGH_OPEN_DRAIN
>>   v4l2-dev.h: fix doc warning
>>
>> Jacopo Mondi (1):
>>   media: renesas-ceu: Set mbus_fmt on subdev operations
>>
>> Jan Luebbe (1):
>>   media: imx-csi: fix burst size for 16 bit
>>
>> Jasmin Jessich (2):
>>   media: Use ktime_set() in pt1.c
>>   media: Revert cleanup ktime_set() usage
>>
>> Julia Lawall (1):
>>   pvrusb2: delete unneeded include
>>
>> Niklas Söderlund (1):
>>   media: entity: fix spelling for media_entity_get_fwnode_pad()
>>
>> Philipp Zabel (4):
>>   media: coda: reuse coda_s_fmt_vid_cap to propagate format in 
>> coda_s_fmt_vid_out
>>   media: coda: do not try to propagate format if capture queue busy
>>   media: coda: set colorimetry on coded queue
>>   media: imx: add 16-bit grayscale support
>>
>> Robin Murphy (1):
>>   media: videobuf-dma-sg: Fix dma_{sync,unmap}_sg() calls
>>
>> Sami Tolvanen (1):
>>   media: media-device: fix ioctl function types
>>
>> Simon Que (1):
>>   v4l2-core: Rename array 'video_driver' to 'video_drivers'
>>
>> Souptick Joarder (1):
>>   videobuf: Change return type to vm_fault_t
>>
>> Wolfram Sang (1):
>>   media: platform: am437x: simplify gettin

Re: [PATCH] vim2m: use cancel_delayed_work_sync instead of flush_schedule_work

2018-11-22 Thread Hans Verkuil
On 11/07/2018 03:04 PM, Hans Verkuil wrote:
> The use of flush_schedule_work() made no sense and caused a syzkaller error.
> Replace with the correct cancel_delayed_work_sync().
> 
> Signed-off-by: Hans Verkuil 

Mistyped that SoB, this should of course be:

Signed-off-by: Hans Verkuil 

Regards,

Hans

> Reported-by: syzbot+69780d144754b8071...@syzkaller.appspotmail.com
> ---
> diff --git a/drivers/media/platform/vim2m.c b/drivers/media/platform/vim2m.c
> index d82db738f174..f938a2c54314 100644
> --- a/drivers/media/platform/vim2m.c
> +++ b/drivers/media/platform/vim2m.c
> @@ -805,10 +805,11 @@ static int vim2m_start_streaming(struct vb2_queue *q, 
> unsigned count)
>  static void vim2m_stop_streaming(struct vb2_queue *q)
>  {
>   struct vim2m_ctx *ctx = vb2_get_drv_priv(q);
> + struct vim2m_dev *dev = ctx->dev;
>   struct vb2_v4l2_buffer *vbuf;
>   unsigned long flags;
> 
> - flush_scheduled_work();
> + cancel_delayed_work_sync(>work_run);
>   for (;;) {
>   if (V4L2_TYPE_IS_OUTPUT(q->type))
>   vbuf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> 



Re: [PATCH] media: video-i2c: don't use msleep for 1ms - 20ms

2018-11-22 Thread Hans Verkuil
On 11/20/2018 04:27 PM, Akinobu Mita wrote:
> Documentation/timers/timers-howto.txt says:
> 
> "msleep(1~20) may not do what the caller intends, and will often sleep
> longer (~20 ms actual sleep for any value given in the 1~20ms range)."
> 
> So replace msleep(2) by usleep_range(2000, 3000).

Please just repost patch 6/6 with this change merged in.

Thanks!

Hans

> 
> Reported-by: Hans Verkuil 
> Cc: Matt Ranostay 
> Cc: Sakari Ailus 
> Cc: Hans Verkuil 
> Cc: Mauro Carvalho Chehab 
> Signed-off-by: Akinobu Mita 
> ---
> This fixes "[PATCH v4 6/6] media: video-i2c: support runtime PM" in the
> patchset "[PATCH v4 0/6] media: video-i2c: support changing frame interval
> and runtime PM".
> 
>  drivers/media/i2c/video-i2c.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
> index 0c82131..77080d7 100644
> --- a/drivers/media/i2c/video-i2c.c
> +++ b/drivers/media/i2c/video-i2c.c
> @@ -155,7 +155,7 @@ static int amg88xx_set_power_on(struct video_i2c_data 
> *data)
>   if (ret)
>   return ret;
>  
> - msleep(2);
> + usleep_range(2000, 3000);
>  
>   ret = regmap_write(data->regmap, AMG88XX_REG_RST, AMG88XX_RST_FLAG);
>   if (ret)
> 



[GIT FIXES FOR v4.20] Revert "media: dt-bindings: Document the Rockchip VPU bindings"

2018-11-22 Thread Hans Verkuil
The following changes since commit 5200ab6a32d6055428896a49ec9e3b1652c1a100:

  media: vidioc_cropcap -> vidioc_g_pixelaspect (2018-11-20 13:57:21 -0500)

are available in the Git repository at:

  git://linuxtv.org/hverkuil/media_tree.git tags/br-v4.20n

for you to fetch changes up to a91f8d8762388bedff87e967a8655514775568fc:

  Revert "media: dt-bindings: Document the Rockchip VPU bindings" (2018-11-22 
13:00:10 +0100)


Tag branch


Ezequiel Garcia (1):
  Revert "media: dt-bindings: Document the Rockchip VPU bindings"

 Documentation/devicetree/bindings/media/rockchip-vpu.txt | 29 
-
 1 file changed, 29 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/media/rockchip-vpu.txt


[PATCH for v4.4] Revert "media: videobuf2-core: don't call memop 'finish' when queueing"

2018-11-22 Thread Hans Verkuil
This reverts commit 46431d9c28f6859f8e568ac7db92137f1da31100.

This commit fixes a bug in upstream commit a136f59c0a1f ("vb2: Move
buffer cache synchronisation to prepare from queue") which isn't
present in 4.4.

So as a result you get an UNBALANCED message in the kernel log if
this patch is applied:

vb2:   counters for queue ffc0f3687478, buffer 3: UNBALANCED!
vb2: buf_init: 1 buf_cleanup: 1 buf_prepare: 805 buf_finish: 805
vb2: buf_queue: 806 buf_done: 806
vb2: alloc: 0 put: 0 prepare: 806 finish: 805 mmap: 0
vb2: get_userptr: 0 put_userptr: 0
vb2: attach_dmabuf: 1 detach_dmabuf: 1 map_dmabuf: 805 unmap_dmabuf: 805
vb2: get_dmabuf: 0 num_users: 1609 vaddr: 0 cookie: 805

Reverting this patch solves this regression.

Signed-off-by: Hans Verkuil 
---
Probably two reasons why this slipped through:

1) The patch was missing a Fixes: tag
2) I was probably CC-ed about this when it was about to be added to 4.9
   but didn't realize that that was wrong.
---
 drivers/media/v4l2-core/videobuf2-core.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 1c37d5a..8ce9c63 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -870,12 +870,9 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
vb2_buffer_state state)
dprintk(4, "done processing on buffer %d, state: %d\n",
vb->index, state);

-   if (state != VB2_BUF_STATE_QUEUED &&
-   state != VB2_BUF_STATE_REQUEUEING) {
-   /* sync buffers */
-   for (plane = 0; plane < vb->num_planes; ++plane)
-   call_void_memop(vb, finish, vb->planes[plane].mem_priv);
-   }
+   /* sync buffers */
+   for (plane = 0; plane < vb->num_planes; ++plane)
+   call_void_memop(vb, finish, vb->planes[plane].mem_priv);

spin_lock_irqsave(>done_lock, flags);
if (state == VB2_BUF_STATE_QUEUED ||
-- 
2.10.2



[PATCH for v4.9] Revert "media: videobuf2-core: don't call memop 'finish' when queueing"

2018-11-22 Thread Hans Verkuil
This reverts commit 9ac47200b51cb09d2f15dbefa67e0412741d98aa.

This commit fixes a bug in upstream commit a136f59c0a1f ("vb2: Move
buffer cache synchronisation to prepare from queue") which isn't
present in 4.9.

So as a result you get an UNBALANCED message in the kernel log if
this patch is applied:

vb2:   counters for queue ffc0f3687478, buffer 3: UNBALANCED!
vb2: buf_init: 1 buf_cleanup: 1 buf_prepare: 805 buf_finish: 805
vb2: buf_queue: 806 buf_done: 806
vb2: alloc: 0 put: 0 prepare: 806 finish: 805 mmap: 0
vb2: get_userptr: 0 put_userptr: 0
vb2: attach_dmabuf: 1 detach_dmabuf: 1 map_dmabuf: 805 unmap_dmabuf: 805
vb2: get_dmabuf: 0 num_users: 1609 vaddr: 0 cookie: 805

Reverting this patch solves this regression.

Signed-off-by: Hans Verkuil 
---
Probably two reasons why this slipped through:

1) The patch was missing a Fixes: tag
2) I was probably CC-ed about this when it was about to be added to 4.9
   but didn't realize that that was wrong.
---
 drivers/media/v4l2-core/videobuf2-core.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index f7ca1fa..4df4a1f 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -914,12 +914,9 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
vb2_buffer_state state)
dprintk(4, "done processing on buffer %d, state: %d\n",
vb->index, state);

-   if (state != VB2_BUF_STATE_QUEUED &&
-   state != VB2_BUF_STATE_REQUEUEING) {
-   /* sync buffers */
-   for (plane = 0; plane < vb->num_planes; ++plane)
-   call_void_memop(vb, finish, vb->planes[plane].mem_priv);
-   }
+   /* sync buffers */
+   for (plane = 0; plane < vb->num_planes; ++plane)
+   call_void_memop(vb, finish, vb->planes[plane].mem_priv);

spin_lock_irqsave(>done_lock, flags);
if (state == VB2_BUF_STATE_QUEUED ||
-- 
2.10.2




Re: [GIT PULL FOR v4.21] Add Rockchip VPU JPEG encoder

2018-11-22 Thread Hans Verkuil
Hi Ezeguiel,

Just saw Tomasz' in-depth review and decided to drop this pull request.

He found a few too many issues and I prefer those are addressed first.

Sorry, still more work for you, on to v11!

Regards,

Hans

On 11/22/2018 10:39 AM, Hans Verkuil wrote:
> The following changes since commit 5200ab6a32d6055428896a49ec9e3b1652c1a100:
> 
>   media: vidioc_cropcap -> vidioc_g_pixelaspect (2018-11-20 13:57:21 -0500)
> 
> are available in the Git repository at:
> 
>   git://linuxtv.org/hverkuil/media_tree.git tags/br-jpeg
> 
> for you to fetch changes up to cbf7592cb57ec9986c4d1becfd80b85486fd318a:
> 
>   media: add Rockchip VPU JPEG encoder driver (2018-11-22 10:12:29 +0100)
> 
> 
> Tag branch
> 
> 
> Ezequiel Garcia (1):
>   media: add Rockchip VPU JPEG encoder driver
> 
>  MAINTAINERS |   7 +
>  drivers/staging/media/Kconfig   |   2 +
>  drivers/staging/media/Makefile  |   1 +
>  drivers/staging/media/rockchip/vpu/Kconfig  |  13 +
>  drivers/staging/media/rockchip/vpu/Makefile |  10 +
>  drivers/staging/media/rockchip/vpu/TODO |   6 +
>  drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c  | 118 
>  drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 133 
>  drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h| 442 
> +++
>  drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c  | 118 
>  drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 160 ++
>  drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h| 600 
> 
>  drivers/staging/media/rockchip/vpu/rockchip_vpu.h   | 237 
> +++
>  drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h|  29 ++
>  drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c   | 535 
> +
>  drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c   | 702 
> +++
>  drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h|  58 
>  drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c  | 290 
> ++
>  drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h  |  14 +
>  19 files changed, 3475 insertions(+)
>  create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig
>  create mode 100644 drivers/staging/media/rockchip/vpu/Makefile
>  create mode 100644 drivers/staging/media/rockchip/vpu/TODO
>  create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c
>  create mode 100644 
> drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
>  create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h
>  create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c
>  create mode 100644 
> drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
>  create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h
>  create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h
>  create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h
>  create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
>  create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
>  create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h
>  create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c
>  create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h
> 



[PATCH] dib0900: fix smatch warnings

2018-11-22 Thread Hans Verkuil
drivers/media/dvb-frontends/dib0090.c: 
drivers/media/dvb-frontends/dib0090.c:1075 dib0090_pwm_gain_reset() warn: 
'*_ramp_pwm_normal' 2590696709486571520 can't fit into 65535 '*bb_ramp'
drivers/media/dvb-frontends/dib0090.c: 
drivers/media/dvb-frontends/dib0090.c:1083 dib0090_pwm_gain_reset() warn: 
'*_ramp_pwm_normal_socs' 2590696709486571520 can't fit into 65535 '*bb_ramp'
drivers/media/dvb-frontends/dib0090.c: 
drivers/media/dvb-frontends/dib0090.c:1085 dib0090_pwm_gain_reset() warn: 
'*_ramp_pwm_cband_8090' 2590696709486571520 can't fit into 65535 '*rf_ramp'
drivers/media/dvb-frontends/dib0090.c: 
drivers/media/dvb-frontends/dib0090.c:1089 dib0090_pwm_gain_reset() warn: 
'*_ramp_pwm_cband_7090e_sensitivity' 2590696709486571520 can't fit into 
65535 '*rf_ramp'
drivers/media/dvb-frontends/dib0090.c: 
drivers/media/dvb-frontends/dib0090.c:1093 dib0090_pwm_gain_reset() warn: 
'*_ramp_pwm_cband_7090p' 2590696709486571520 can't fit into 65535 '*rf_ramp'
drivers/media/dvb-frontends/dib0090.c: 
drivers/media/dvb-frontends/dib0090.c:1096 dib0090_pwm_gain_reset() warn: 
'*_ramp_pwm_cband' 2590696709486571520 can't fit into 65535 '*rf_ramp'
drivers/media/dvb-frontends/dib0090.c: 
drivers/media/dvb-frontends/dib0090.c:1101 dib0090_pwm_gain_reset() warn: 
'*_ramp_pwm_normal_socs' 2590696709486571520 can't fit into 65535 '*bb_ramp'
drivers/media/dvb-frontends/dib0090.c: 
drivers/media/dvb-frontends/dib0090.c:1104 dib0090_pwm_gain_reset() warn: 
'*_ramp_pwm_vhf' 2590696709486571520 can't fit into 65535 '*rf_ramp'
drivers/media/dvb-frontends/dib0090.c: 
drivers/media/dvb-frontends/dib0090.c:1107 dib0090_pwm_gain_reset() warn: 
'*_ramp_pwm_normal_socs' 2590696709486571520 can't fit into 65535 '*bb_ramp'
drivers/media/dvb-frontends/dib0090.c: 
drivers/media/dvb-frontends/dib0090.c:1109 dib0090_pwm_gain_reset() warn: 
'*_ramp_pwm_uhf_8090' 2590696709486571520 can't fit into 65535 '*rf_ramp'
drivers/media/dvb-frontends/dib0090.c: 
drivers/media/dvb-frontends/dib0090.c: dib0090_pwm_gain_reset() warn: 
'*_ramp_pwm_uhf_7090' 2590696709486571520 can't fit into 65535 '*rf_ramp'
drivers/media/dvb-frontends/dib0090.c: 
drivers/media/dvb-frontends/dib0090.c:1113 dib0090_pwm_gain_reset() warn: 
'*_ramp_pwm_uhf' 2590696709486571520 can't fit into 65535 '*rf_ramp'
drivers/media/dvb-frontends/dib0090.c: 
drivers/media/dvb-frontends/dib0090.c:1419 dib0090_update_rframp_7090() warn: 
'*_ramp_pwm_cband_7090e_sensitivity' 2590696709486571520 can't fit into 65535
'*state->rf_ramp'
drivers/media/dvb-frontends/dib0090.c: 
drivers/media/dvb-frontends/dib0090.c:1421 dib0090_update_rframp_7090() warn: 
'*_ramp_pwm_cband_7090e_aci' 2590696709486571520 can't fit into 65535
'*state->rf_ramp'

For no apparent reason this code casts away the const of the const u16 arrays, 
and it
also takes the address of an array. While that's ignored in C I think smatch 
gets confused
by it.

Signed-off-by: Hans Verkuil 
---
 drivers/media/dvb-frontends/dib0090.c | 32 +--
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/media/dvb-frontends/dib0090.c 
b/drivers/media/dvb-frontends/dib0090.c
index 44a074261e69..4813a88eb9f7 100644
--- a/drivers/media/dvb-frontends/dib0090.c
+++ b/drivers/media/dvb-frontends/dib0090.c
@@ -1072,45 +1072,45 @@ static void dib0090_set_bbramp_pwm(struct dib0090_state 
*state, const u16 * cfg)
 void dib0090_pwm_gain_reset(struct dvb_frontend *fe)
 {
struct dib0090_state *state = fe->tuner_priv;
-   u16 *bb_ramp = (u16 *)_ramp_pwm_normal; /* default baseband config */
-   u16 *rf_ramp = NULL;
+   const u16 *bb_ramp = bb_ramp_pwm_normal; /* default baseband config */
+   const u16 *rf_ramp = NULL;
u8 en_pwm_rf_mux = 1;

/* reset the AGC */
if (state->config->use_pwm_agc) {
if (state->current_band == BAND_CBAND) {
if (state->identity.in_soc) {
-   bb_ramp = (u16 *)_ramp_pwm_normal_socs;
+   bb_ramp = bb_ramp_pwm_normal_socs;
if (state->identity.version == 
SOC_8090_P1G_11R1 || state->identity.version == SOC_8090_P1G_21R1)
-   rf_ramp = (u16 
*)_ramp_pwm_cband_8090;
+   rf_ramp = rf_ramp_pwm_cband_8090;
else if (state->identity.version == 
SOC_7090_P1G_11R1 || state->identity.version == SOC_7090_P1G_21R1) {
if (state->config->is_dib7090e) {
if (state->rf_ramp == NULL)
-   rf_ramp = (u16 
*)_ramp_pwm_cband_7090e_sensitivity;
+   rf_ramp = 
rf_ramp_pwm_cband_7090e_sensitivity;
else
- 

[GIT FIXES FOR v4.20] gspca regression fix

2018-11-22 Thread Hans Verkuil
The following changes since commit 5200ab6a32d6055428896a49ec9e3b1652c1a100:

  media: vidioc_cropcap -> vidioc_g_pixelaspect (2018-11-20 13:57:21 -0500)

are available in the Git repository at:

  git://linuxtv.org/hverkuil/media_tree.git tags/br-v4.20m

for you to fetch changes up to e3e33f1da1e0a266435c61394320e64588631a59:

  gspca: fix frame overflow error (2018-11-22 10:50:37 +0100)


Tag branch

----
Hans Verkuil (1):
  gspca: fix frame overflow error

 drivers/media/usb/gspca/gspca.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)


Re: [PATCH v10 1/4] media: dt-bindings: Document the Rockchip VPU bindings

2018-11-22 Thread Hans Verkuil
On 11/21/2018 08:16 PM, Ezequiel Garcia wrote:
> Add devicetree binding documentation for Rockchip Video Processing
> Unit IP.
> 
> Reviewed-by: Rob Herring 
> Signed-off-by: Ezequiel Garcia 

This one has been merged already.

Regards,

Hans

> ---
>  .../bindings/media/rockchip-vpu.txt   | 29 +++
>  1 file changed, 29 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/rockchip-vpu.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.txt 
> b/Documentation/devicetree/bindings/media/rockchip-vpu.txt
> new file mode 100644
> index ..35dc464ad7c8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.txt
> @@ -0,0 +1,29 @@
> +device-tree bindings for rockchip VPU codec
> +
> +Rockchip (Video Processing Unit) present in various Rockchip platforms,
> +such as RK3288 and RK3399.
> +
> +Required properties:
> +- compatible: value should be one of the following
> + "rockchip,rk3288-vpu";
> + "rockchip,rk3399-vpu";
> +- interrupts: encoding and decoding interrupt specifiers
> +- interrupt-names: should be "vepu" and "vdpu"
> +- clocks: phandle to VPU aclk, hclk clocks
> +- clock-names: should be "aclk" and "hclk"
> +- power-domains: phandle to power domain node
> +- iommus: phandle to a iommu node
> +
> +Example:
> +SoC-specific DT entry:
> + vpu: video-codec@ff9a {
> + compatible = "rockchip,rk3288-vpu";
> + reg = <0x0 0xff9a 0x0 0x800>;
> + interrupts = ,
> +  ;
> + interrupt-names = "vepu", "vdpu";
> + clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
> + clock-names = "aclk", "hclk";
> + power-domains = < RK3288_PD_VIDEO>;
> + iommus = <_mmu>;
> + };
> 



[GIT PULL FOR v4.21] Add Rockchip VPU JPEG encoder

2018-11-22 Thread Hans Verkuil
The following changes since commit 5200ab6a32d6055428896a49ec9e3b1652c1a100:

  media: vidioc_cropcap -> vidioc_g_pixelaspect (2018-11-20 13:57:21 -0500)

are available in the Git repository at:

  git://linuxtv.org/hverkuil/media_tree.git tags/br-jpeg

for you to fetch changes up to cbf7592cb57ec9986c4d1becfd80b85486fd318a:

  media: add Rockchip VPU JPEG encoder driver (2018-11-22 10:12:29 +0100)


Tag branch


Ezequiel Garcia (1):
  media: add Rockchip VPU JPEG encoder driver

 MAINTAINERS |   7 +
 drivers/staging/media/Kconfig   |   2 +
 drivers/staging/media/Makefile  |   1 +
 drivers/staging/media/rockchip/vpu/Kconfig  |  13 +
 drivers/staging/media/rockchip/vpu/Makefile |  10 +
 drivers/staging/media/rockchip/vpu/TODO |   6 +
 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c  | 118 
 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 133 
 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h| 442 
+++
 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c  | 118 
 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 160 ++
 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h| 600 

 drivers/staging/media/rockchip/vpu/rockchip_vpu.h   | 237 
+++
 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h|  29 ++
 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c   | 535 
+
 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c   | 702 
+++
 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h|  58 
 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c  | 290 
++
 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h  |  14 +
 19 files changed, 3475 insertions(+)
 create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig
 create mode 100644 drivers/staging/media/rockchip/vpu/Makefile
 create mode 100644 drivers/staging/media/rockchip/vpu/TODO
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h


Re: [PATCH 1/1] v4l: uAPI doc: Changing frame interval won't change format

2018-11-22 Thread Hans Verkuil
On 11/21/2018 06:33 PM, Sakari Ailus wrote:
> Document that changing the frame interval has no effect on frame size.
> While this was the assumption in the API, it was not documented as such.
> 
> Signed-off-by: Sakari Ailus 

Acked-by: Hans Verkuil 

Thanks!

Hans

> ---
>  Documentation/media/uapi/v4l/vidioc-g-parm.rst  | 3 +++
>  Documentation/media/uapi/v4l/vidioc-subdev-g-frame-interval.rst | 3 +++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/vidioc-g-parm.rst 
> b/Documentation/media/uapi/v4l/vidioc-g-parm.rst
> index e831fa5512f0..c31585a7701b 100644
> --- a/Documentation/media/uapi/v4l/vidioc-g-parm.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-g-parm.rst
> @@ -42,6 +42,9 @@ side. This is especially useful when using the :ref:`read() 
> ` or
>  :ref:`write() `, which are not augmented by timestamps or 
> sequence
>  counters, and to avoid unnecessary data copying.
>  
> +Changing the frame interval shall never change the format. Changing the
> +format, on the other hand, may change the frame interval.
> +
>  Further these ioctls can be used to determine the number of buffers used
>  internally by a driver in read/write mode. For implications see the
>  section discussing the :ref:`read() ` function.
> diff --git a/Documentation/media/uapi/v4l/vidioc-subdev-g-frame-interval.rst 
> b/Documentation/media/uapi/v4l/vidioc-subdev-g-frame-interval.rst
> index 5af0a7179941..f889c20f231c 100644
> --- a/Documentation/media/uapi/v4l/vidioc-subdev-g-frame-interval.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-subdev-g-frame-interval.rst
> @@ -63,6 +63,9 @@ doesn't match the device capabilities. They must instead 
> modify the
>  interval to match what the hardware can provide. The modified interval
>  should be as close as possible to the original request.
>  
> +Changing the frame interval shall never change the format. Changing the
> +format, on the other hand, may change the frame interval.
> +
>  Sub-devices that support the frame interval ioctls should implement them
>  on a single pad only. Their behaviour when supported on multiple pads of
>  the same sub-device is not defined.
> 



Re: [PATCH v2 2/2] media: video-i2c: add Melexis MLX90640 thermal camera support

2018-11-22 Thread Hans Verkuil
On 11/22/2018 04:52 AM, Matt Ranostay wrote:
> Add initial support for MLX90640 thermal cameras which output an 32x24
> greyscale pixel image along with 2 rows of coefficent data.
> 
> Because of this the data outputed is really 32x26 and needs the two rows
> removed after using the coefficent information to generate processed
> images in userspace.
> 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Matt Ranostay 
> ---
>  .../bindings/media/i2c/melexis,mlx90640.txt   |  20 
>  drivers/media/i2c/Kconfig |   1 +
>  drivers/media/i2c/video-i2c.c | 110 +-
>  3 files changed, 130 insertions(+), 1 deletion(-)
>  create mode 100644 
> Documentation/devicetree/bindings/media/i2c/melexis,mlx90640.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/melexis,mlx90640.txt 
> b/Documentation/devicetree/bindings/media/i2c/melexis,mlx90640.txt
> new file mode 100644
> index ..060d2b7a5893
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/melexis,mlx90640.txt
> @@ -0,0 +1,20 @@
> +* Melexis MLX90640 FIR Sensor
> +
> +Melexis MLX90640 FIR sensor support which allows recording of thermal data
> +with 32x24 resolution excluding 2 lines of coefficient data that is used by
> +userspace to render processed frames.

So this means that the image doesn't conform to V4L2_PIX_FMT_Y12!

I missed that the first time around.

You have three options here:

1) Create a new V4L2_PIX_FMT define + documentation describing the format that
   this device produces.

2) Split off the image from the meta data and create a new META_CAPTURE device
   node. For the META device node you would again have to document the format

3) Split off the image from the meta data and store the meta data in a V4L2
   control, which again has to be documented.

I'm leaning towards 1 since that's easiest to implement. But the key is that
you should document those two lines. The datasheet is publicly available,
so you can refer to it for details.

Those extra two lines return addresses 0x700-0x73f, right? Is it even sufficient
to calculate the relevant data from just those lines? Looking at 11.2.2 there
is a whole calculation that should be done that is also dependent on the eeprom
values, which are not exported.

I wonder if it isn't the job of the driver to do all the calculations. It has
all the information it needs and looking at the datasheet it seems all the
calculations are integer based, so it shouldn't be too difficult. This would
be a fourth option.

BTW, did we document somewhere what the panasonic device returns? It returns
Y12 data, but what does that data mean? In order to use this in userspace you
need to be able to convert it to temperatures, so how is that done?

Regards,

Hans

> +
> +Required Properties:
> + - compatible : Must be "melexis,mlx90640"
> + - reg : i2c address of the device
> +
> +Example:
> +
> + i2c0@1c22000 {
> + ...
> + mlx90640@33 {
> + compatible = "melexis,mlx90640";
> + reg = <0x33>;
> + };
> + ...
> + };


cron job: media_tree daily build: WARNINGS

2018-11-21 Thread Hans Verkuil
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:   Thu Nov 22 05:00:11 CET 2018
media-tree git hash:5200ab6a32d6055428896a49ec9e3b1652c1a100
media_build git hash:   a8aef9cea0a4a2f3ea86c0b37bd6a1378018c0c1
v4l-utils git hash: fcde9d178adb91cad74ed705c3009f8b05b4b44b
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: WARNINGS
linux-git-arm-davinci: WARNINGS
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: WARNINGS
linux-git-arm-stm32: WARNINGS
linux-git-arm64: OK
linux-git-i686: WARNINGS
linux-git-mips: OK
linux-git-powerpc64: WARNINGS
linux-git-sh: OK
linux-git-x86_64: WARNINGS
Check COMPILE_TEST: OK
linux-3.10.108-i686: OK
linux-3.10.108-x86_64: OK
linux-3.11.10-i686: OK
linux-3.11.10-x86_64: OK
linux-3.12.74-i686: OK
linux-3.12.74-x86_64: OK
linux-3.13.11-i686: OK
linux-3.13.11-x86_64: OK
linux-3.14.79-i686: OK
linux-3.14.79-x86_64: OK
linux-3.15.10-i686: OK
linux-3.15.10-x86_64: OK
linux-3.16.57-i686: OK
linux-3.16.57-x86_64: OK
linux-3.17.8-i686: OK
linux-3.17.8-x86_64: OK
linux-3.18.123-i686: OK
linux-3.18.123-x86_64: OK
linux-3.19.8-i686: OK
linux-3.19.8-x86_64: OK
linux-4.0.9-i686: OK
linux-4.0.9-x86_64: OK
linux-4.1.52-i686: OK
linux-4.1.52-x86_64: OK
linux-4.2.8-i686: OK
linux-4.2.8-x86_64: OK
linux-4.3.6-i686: OK
linux-4.3.6-x86_64: OK
linux-4.4.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/Thursday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html


[RFCv4 PATCH 3/3] vimc: add property test code

2018-11-21 Thread Hans Verkuil
From: Hans Verkuil 

Add properties to entities and pads to be able to test the
properties API.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/vimc/vimc-common.c | 50 +++
 1 file changed, 50 insertions(+)

diff --git a/drivers/media/platform/vimc/vimc-common.c 
b/drivers/media/platform/vimc/vimc-common.c
index dee1b9dfc4f6..2f70e4e64790 100644
--- a/drivers/media/platform/vimc/vimc-common.c
+++ b/drivers/media/platform/vimc/vimc-common.c
@@ -415,6 +415,7 @@ int vimc_ent_sd_register(struct vimc_ent_device *ved,
 const unsigned long *pads_flag,
 const struct v4l2_subdev_ops *sd_ops)
 {
+   struct media_prop *prop = NULL;
int ret;
 
/* Allocate the pads */
@@ -452,6 +453,55 @@ int vimc_ent_sd_register(struct vimc_ent_device *ved,
goto err_clean_m_ent;
}
 
+   ret = media_entity_add_prop_u64(>entity, "u64", ~1);
+   if (!ret)
+   ret = media_entity_add_prop_s64(>entity, "s64", -5);
+   if (!ret)
+   ret = media_entity_add_prop_string(>entity, "string",
+  sd->name);
+   if (!ret) {
+   prop = media_entity_add_prop_group(>entity, "empty-group");
+   ret = PTR_ERR_OR_ZERO(prop);
+   }
+   if (!ret) {
+   prop = media_entity_add_prop_group(>entity, "group");
+   ret = PTR_ERR_OR_ZERO(prop);
+   }
+   if (!ret)
+   ret = media_prop_add_prop_u64(prop, "u64", 42);
+   if (!ret)
+   ret = media_prop_add_prop_s64(prop, "s64", -42);
+   if (!ret)
+   ret = media_prop_add_prop_string(prop, "string", "42");
+   if (!ret)
+   ret = media_pad_add_prop_u64(>entity.pads[num_pads - 1],
+"u64", ~1);
+   if (!ret)
+   ret = media_pad_add_prop_s64(>entity.pads[num_pads - 1],
+"s64", -5);
+   if (!ret) {
+   prop = media_pad_add_prop_group(>entity.pads[num_pads - 1],
+   "group");
+   ret = PTR_ERR_OR_ZERO(prop);
+   }
+   if (!ret)
+   ret = media_prop_add_prop_u64(prop, "u64", 24);
+   if (!ret)
+   ret = media_prop_add_prop_s64(prop, "s64", -24);
+   if (!ret)
+   ret = media_pad_add_prop_string(>entity.pads[0],
+   "string", sd->name);
+   if (!ret)
+   ret = media_prop_add_prop_string(prop, "string", "24");
+   if (!ret) {
+   prop = media_prop_add_prop_group(prop, "subgroup");
+   ret = PTR_ERR_OR_ZERO(prop);
+   }
+   if (!ret)
+   ret = media_prop_add_prop_string(prop, "string", "substring");
+   if (ret)
+   goto err_clean_m_ent;
+
return 0;
 
 err_clean_m_ent:
-- 
2.19.1



[RFCv4 PATCH 0/3] This RFC patch series implements properties for the media controller.

2018-11-21 Thread Hans Verkuil
The main changes since RFCv3 are:

- Add entity index to media_v2_pad
- Add source/sink pad index to media_v2_link
- Add owner_idx and owner type flags to media_v2_prop

An updated v4l2-ctl and v4l2-compliance that can report properties
is available here:

https://git.linuxtv.org/hverkuil/v4l-utils.git/log/?h=props

Currently I support u64, s64 and const char * property types. And also
a 'group' type that groups sub-properties. But it can be extended to any
type including binary data if needed. No array support (as we have for
controls), but there are enough reserved fields in media_v2_prop
to add this if needed.

I added properties for entities and pads to vimc, so I could test this.

Note that the changes to media_device_get_topology() are hard to read
from the patch. It is easier to just look at the source code:

https://git.linuxtv.org/hverkuil/media_tree.git/tree/drivers/media/media-device.c?h=mc-props

I have some ideas to improve this some more:

1) Add the properties directly to media_gobj. This would simplify some
   of the code, but it would require a media_gobj_init function to
   initialize the property list. In general I am a bit unhappy about
   media_gobj_create: it doesn't really create the graph object, instead
   it just adds it to the media_device. It's confusing and it is something
   I would like to change.

2) The links between pads are stored in media_entity instead of in media_pad.
   This is a bit unexpected and makes it harder to traverse the data
   structures since to find the links for a pad you need to walk the entity
   links and find the links for that pad. Putting all links in the entity
   also mixes up pad and interface links, and it would be much cleaner if
   those are separated.

3) I still think adding support for backlinks to G_TOPOLOGY is a good idea.
   Since the current data structure represents a flattened tree that is easy
   to navigate the only thing missing for userspace is backlink support.
   This is still something that userspace needs to figure out when the kernel
   has this readily available. I think that with this in place applications
   can just do all the lookups directly on the topology data structure.

1+2 are internal cleanups that can be done later.

3 is a low-priority future enhancement. This might become easier to implement
once 1+2 are done.

This is pretty much the last RFC. If everyone agree with this approach, then
I can make a final patch series, adding documentation etc.

Regards,

Hans


Hans Verkuil (3):
  uapi/linux/media.h: add property support
  media controller: add properties support
  vimc: add property test code

 drivers/media/media-device.c  | 335 +-
 drivers/media/media-entity.c  | 107 ++-
 drivers/media/platform/vimc/vimc-common.c |  50 
 include/media/media-device.h  |   6 +
 include/media/media-entity.h  | 318 
 include/uapi/linux/media.h|  88 +-
 6 files changed, 819 insertions(+), 85 deletions(-)

-- 
2.19.1



[RFCv4 PATCH 1/3] uapi/linux/media.h: add property support

2018-11-21 Thread Hans Verkuil
From: Hans Verkuil 

Add a new topology struct that includes properties and adds
index fields to quickly find references from one object to
another in the topology arrays.

Signed-off-by: Hans Verkuil 
---
 include/uapi/linux/media.h | 88 --
 1 file changed, 84 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index e5d0c5c611b5..a81e9723204c 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -144,6 +144,8 @@ struct media_device_info {
 /* Entity flags */
 #define MEDIA_ENT_FL_DEFAULT   (1 << 0)
 #define MEDIA_ENT_FL_CONNECTOR (1 << 1)
+#define MEDIA_ENT_FL_PAD_IDX   (1 << 2)
+#define MEDIA_ENT_FL_PROP_IDX  (1 << 3)
 
 /* OR with the entity id value to find the next entity */
 #define MEDIA_ENT_ID_FLAG_NEXT (1 << 31)
@@ -210,6 +212,9 @@ struct media_entity_desc {
 #define MEDIA_PAD_FL_SINK  (1 << 0)
 #define MEDIA_PAD_FL_SOURCE(1 << 1)
 #define MEDIA_PAD_FL_MUST_CONNECT  (1 << 2)
+#define MEDIA_PAD_FL_LINK_IDX  (1 << 3)
+#define MEDIA_PAD_FL_PROP_IDX  (1 << 4)
+#define MEDIA_PAD_FL_ENTITY_IDX(1 << 5)
 
 struct media_pad_desc {
__u32 entity;   /* entity ID */
@@ -221,6 +226,8 @@ struct media_pad_desc {
 #define MEDIA_LNK_FL_ENABLED   (1 << 0)
 #define MEDIA_LNK_FL_IMMUTABLE (1 << 1)
 #define MEDIA_LNK_FL_DYNAMIC   (1 << 2)
+#define MEDIA_LNK_FL_SOURCE_IDX(1 << 3)
+#define MEDIA_LNK_FL_SINK_IDX  (1 << 4)
 
 #define MEDIA_LNK_FL_LINK_TYPE (0xf << 28)
 #  define MEDIA_LNK_FL_DATA_LINK   (0 << 28)
@@ -296,7 +303,9 @@ struct media_v2_entity {
char name[64];
__u32 function; /* Main function of the entity */
__u32 flags;
-   __u32 reserved[5];
+   __u16 pad_idx;
+   __u16 prop_idx;
+   __u32 reserved[4];
 } __attribute__ ((packed));
 
 /* Should match the specific fields at media_intf_devnode */
@@ -305,11 +314,14 @@ struct media_v2_intf_devnode {
__u32 minor;
 } __attribute__ ((packed));
 
+#define MEDIA_INTF_FL_LINK_IDX (1 << 0)
+
 struct media_v2_interface {
__u32 id;
__u32 intf_type;
__u32 flags;
-   __u32 reserved[9];
+   __u16 link_idx;
+   __u16 reserved[17];
 
union {
struct media_v2_intf_devnode devnode;
@@ -331,7 +343,10 @@ struct media_v2_pad {
__u32 entity_id;
__u32 flags;
__u32 index;
-   __u32 reserved[4];
+   __u16 link_idx;
+   __u16 prop_idx;
+   __u16 entity_idx;
+   __u16 reserved[5];
 } __attribute__ ((packed));
 
 struct media_v2_link {
@@ -339,9 +354,68 @@ struct media_v2_link {
__u32 source_id;
__u32 sink_id;
__u32 flags;
-   __u32 reserved[6];
+   __u16 source_idx;
+   __u16 sink_idx;
+   __u32 reserved[5];
 } __attribute__ ((packed));
 
+#define MEDIA_PROP_TYPE_GROUP  1
+#define MEDIA_PROP_TYPE_U642
+#define MEDIA_PROP_TYPE_S643
+#define MEDIA_PROP_TYPE_STRING 4
+
+#define MEDIA_PROP_FL_OWNER0xf
+#  define MEDIA_PROP_FL_ENTITY 0
+#  define MEDIA_PROP_FL_PAD1
+#  define MEDIA_PROP_FL_LINK   2
+#  define MEDIA_PROP_FL_INTF   3
+#  define MEDIA_PROP_FL_PROP   4
+#define MEDIA_PROP_FL_PROP_IDX (1 << 4)
+
+/**
+ * struct media_v2_prop - A media property
+ *
+ * @id:The unique non-zero ID of this property
+ * @owner_id:  The ID of the object this property belongs to
+ * @type:  Property type
+ * @flags: Property flags
+ * @name:  Property name
+ * @payload_size: Property payload size, 0 for U64/S64
+ * @payload_offset: Property payload starts at this offset from 
+ * This is 0 for U64/S64.
+ * @prop_idx:  Index to sub-properties, 0 means there are no sub-properties.
+ * @owner_idx: Index to entities/pads/properties, depending on the owner ID
+ * type.
+ * @reserved:  Property reserved field, will be zeroed.
+ */
+struct media_v2_prop {
+   __u32 id;
+   __u32 owner_id;
+   __u32 type;
+   __u32 flags;
+   char name[32];
+   __u32 payload_size;
+   __u32 payload_offset;
+   __u16 prop_idx;
+   __u16 owner_idx;
+   __u32 reserved[17];
+} __attribute__ ((packed));
+
+static inline const char *media_prop2s(const struct media_v2_prop *prop)
+{
+   return (const char *)prop + prop->payload_offset;
+}
+
+static inline __u64 media_prop2u64(const struct media_v2_prop *prop)
+{
+   return *(const __u64 *)((const char *

[RFCv4 PATCH 2/3] media controller: add properties support

2018-11-21 Thread Hans Verkuil
From: Hans Verkuil 

Add support for properties. In this initial implementation properties
can be added to entities and pads. In addition, properties can be
nested.

Since this patch adds the topology_idx to the graph objects it is now
easy to fill in the index fields in the topology to allow userspace
to quickly look up a reference from one object to another.

Signed-off-by: Hans Verkuil 
---
 drivers/media/media-device.c | 335 +++
 drivers/media/media-entity.c | 107 ++-
 include/media/media-device.h |   6 +
 include/media/media-entity.h | 318 +
 4 files changed, 685 insertions(+), 81 deletions(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index bed24372e61f..099ab3532475 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -235,6 +235,21 @@ static long media_device_setup_link(struct media_device 
*mdev, void *arg)
return __media_entity_setup_link(link, linkd->flags);
 }
 
+static void walk_props(struct list_head *head, u32 *prop_idx, u32 
*payload_size)
+{
+   struct media_prop *prop;
+
+   if (list_empty(head))
+   return;
+
+   list_for_each_entry(prop, head, list) {
+   prop->graph_obj.topology_idx = (*prop_idx)++;
+   *payload_size += prop->payload_size;
+   }
+   list_for_each_entry(prop, head, list)
+   walk_props(>props, prop_idx, payload_size);
+}
+
 static long media_device_get_topology(struct media_device *mdev, void *arg)
 {
struct media_v2_topology *topo = arg;
@@ -242,27 +257,96 @@ static long media_device_get_topology(struct media_device 
*mdev, void *arg)
struct media_interface *intf;
struct media_pad *pad;
struct media_link *link;
+   struct media_prop *prop, *subprop;
struct media_v2_entity kentity, __user *uentity;
struct media_v2_interface kintf, __user *uintf;
struct media_v2_pad kpad, __user *upad;
struct media_v2_link klink, __user *ulink;
+   struct media_v2_prop kprop, __user *uprop;
+   u32 payload_size = 0;
+   u32 payload_offset = 0;
+   u32 entity_idx = 0;
+   u32 interface_idx = 0;
+   u32 pad_idx = 0;
+   u32 link_idx = 0;
+   u32 prop_idx = 0;
unsigned int i;
int ret = 0;
 
topo->topology_version = mdev->topology_version;
 
+   /* Set entity/pad/link indices and number of entities */
+   media_device_for_each_entity(entity, mdev) {
+   entity->graph_obj.topology_idx = entity_idx++;
+   walk_props(>props, _idx, _size);
+   for (i = 0; i < entity->num_pads; i++) {
+   pad = entity->pads + i;
+   pad->graph_obj.topology_idx = pad_idx++;
+   walk_props(>props, _idx, _size);
+   }
+   /* Note: links are ordered by source pad index */
+   list_for_each_entry(link, >links, list)
+   if (!link->is_backlink)
+   link->graph_obj.topology_idx = link_idx++;
+   }
+   if (topo->ptr_entities && entity_idx > topo->num_entities)
+   ret = -ENOSPC;
+   topo->num_entities = entity_idx;
+   topo->reserved1 = 0;
+
+   /* Set interface/link indices and number of interfaces */
+   media_device_for_each_intf(intf, mdev) {
+   intf->graph_obj.topology_idx = interface_idx++;
+   list_for_each_entry(link, >links, list)
+   link->graph_obj.topology_idx = link_idx++;
+   }
+
+   if (topo->ptr_interfaces && interface_idx > topo->num_interfaces)
+   ret = -ENOSPC;
+   topo->num_interfaces = interface_idx;
+   topo->reserved2 = 0;
+
+   /* Set number of pads */
+   if (topo->ptr_pads && pad_idx > topo->num_pads)
+   ret = -ENOSPC;
+   topo->num_pads = pad_idx;
+   topo->reserved3 = 0;
+
+   /* Set number of links */
+   if (topo->ptr_links && link_idx > topo->num_links)
+   ret = -ENOSPC;
+   topo->num_links = link_idx;
+   topo->reserved4 = 0;
+
+   /* Set number of properties */
+   if (topo->ptr_props &&
+   (prop_idx > topo->num_props ||
+payload_size > topo->props_payload_size))
+   ret = -ENOSPC;
+   topo->num_props = prop_idx;
+   topo->props_payload_size = payload_size;
+
+   if (ret)
+   return ret;
+
+   /*
+* We use u16 for the graph object indices,
+* so check that it will fit in 16 bits.
+*/
+   if (WARN_ON(entity_idx >= 0x1 ||
+   interface_idx >= 0x1 ||
+   pad_idx >= 0x1 ||
+   

Re: [PATCH v9 3/3] media: add Rockchip VPU JPEG encoder driver

2018-11-21 Thread Hans Verkuil
On 11/20/2018 10:20 PM, Ezequiel Garcia wrote:
> Add a mem2mem driver for the VPU available on Rockchip SoCs.
> Currently only JPEG encoding is supported, for RK3399 and RK3288
> platforms.
> 
> Signed-off-by: Ezequiel Garcia 
> ---
>  MAINTAINERS   |   7 +
>  drivers/staging/media/Kconfig |   2 +
>  drivers/staging/media/Makefile|   1 +
>  drivers/staging/media/rockchip/vpu/Kconfig|  14 +
>  drivers/staging/media/rockchip/vpu/Makefile   |  10 +
>  drivers/staging/media/rockchip/vpu/TODO   |   6 +
>  .../media/rockchip/vpu/rk3288_vpu_hw.c| 118 +++
>  .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 133 
>  .../media/rockchip/vpu/rk3288_vpu_regs.h  | 442 +++
>  .../media/rockchip/vpu/rk3399_vpu_hw.c| 118 +++
>  .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 160 
>  .../media/rockchip/vpu/rk3399_vpu_regs.h  | 600 +++
>  .../staging/media/rockchip/vpu/rockchip_vpu.h | 237 ++
>  .../media/rockchip/vpu/rockchip_vpu_common.h  |  29 +
>  .../media/rockchip/vpu/rockchip_vpu_drv.c | 535 +
>  .../media/rockchip/vpu/rockchip_vpu_enc.c | 702 ++
>  .../media/rockchip/vpu/rockchip_vpu_hw.h  |  58 ++
>  .../media/rockchip/vpu/rockchip_vpu_jpeg.c| 289 +++
>  .../media/rockchip/vpu/rockchip_vpu_jpeg.h|  12 +
>  19 files changed, 3473 insertions(+)
>  create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig
>  create mode 100644 drivers/staging/media/rockchip/vpu/Makefile
>  create mode 100644 drivers/staging/media/rockchip/vpu/TODO
>  create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c
>  create mode 100644 
> drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
>  create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h
>  create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c
>  create mode 100644 
> drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
>  create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h
>  create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h
>  create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h
>  create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
>  create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
>  create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h
>  create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c
>  create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h
> 



> diff --git a/drivers/staging/media/rockchip/vpu/Kconfig 
> b/drivers/staging/media/rockchip/vpu/Kconfig
> new file mode 100644
> index ..fa65c03d65bf
> --- /dev/null
> +++ b/drivers/staging/media/rockchip/vpu/Kconfig
> @@ -0,0 +1,14 @@
> +config VIDEO_ROCKCHIP_VPU
> + tristate "Rockchip VPU driver"
> + depends on ARCH_ROCKCHIP || COMPILE_TEST
> + depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER
> + select VIDEOBUF2_DMA_CONTIG
> + select VIDEOBUF2_VMALLOC
> + select V4L2_MEM2MEM_DEV
> + default n
> + help
> +   Support for the Video Processing Unit present on Rockchip SoC,
> +   which accelerates video and image encoding and decoding.
> +   To compile this driver as a module, choose M here: the module
> +   will be called rockchip-vpu.
> +

checkpatch warns about empty line at the end of the Kconfig



> diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h 
> b/drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h
> new file mode 100644
> index ..d6cf9c682e7d
> --- /dev/null
> +++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h
> @@ -0,0 +1,442 @@
> +// SPDX-License-Identifier: GPL-2.0

Headers must use /* */ for the SPDX license. Sorry, I didn't make up these 
rules.

In any case, checkpatch.pl --strict complains about it.



> diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c 
> b/drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c
> new file mode 100644
> index ..678d53f3c2c2
> --- /dev/null
> +++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c
> @@ -0,0 +1,289 @@

Missing SPDX license!

> +/*
> + * Copyright (C) Collabora, Ltd.
> + *
> + * Based on GSPCA and CODA drivers:
> + * Copyright (C) Jean-Francois Moine (http://moinejf.free.fr)
> + * Copyright (C) 2014 Philipp Zabel, Pengutronix
> + */



> diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h 
> b/drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h
> new file mode 100644
> index ..a616d85359e8
> --- /dev/null
> +++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h
> @@ -0,0 +1,12 @@

Missing SPDX license!

> +#define JPEG_HEADER_SIZE 601
> +
> +struct rockchip_vpu_jpeg_ctx {
> + int width;
> + int height;
> + int quality;
> + unsigned char *buffer;
> +};
> +
> +unsigned 

Re: [PATCH v8 00/12] media: staging/imx7: add i.MX7 media driver

2018-11-21 Thread Hans Verkuil
On 11/21/2018 12:15 PM, Rui Miguel Silva wrote:
> Hi,
> This series introduces the Media driver to work with the i.MX7 SoC. it uses 
> the
> already existing imx media core drivers but since the i.MX7, contrary to
> i.MX5/6, do not have an IPU and because of that some changes in the imx media
> core are made along this series to make it support that case.

Can you run scripts/checkpatch.pl --strict over these patches? I get too
many messages from it. Most should be easy to fix.

Regards,

Hans


[GIT PULL FOR v4.21] Various fixes/improvements

2018-11-21 Thread Hans Verkuil
Note: this supersedes https://patchwork.linuxtv.org/patch/53017/. The only 
change
is an updated device_caps patch: https://patchwork.linuxtv.org/patch/53057/

Regards,

Hans

The following changes since commit 5200ab6a32d6055428896a49ec9e3b1652c1a100:

  media: vidioc_cropcap -> vidioc_g_pixelaspect (2018-11-20 13:57:21 -0500)

are available in the Git repository at:

  git://linuxtv.org/hverkuil/media_tree.git tags/br-v4.21dv2

for you to fetch changes up to 982a0280d5b59963b32e32b14dd77cc14697dfc7:

  media: vicodec: Add support for 4 planes formats (2018-11-21 09:40:32 +0100)


Tag branch


Akinobu Mita (5):
  media: video-i2c: avoid accessing released memory area when removing 
driver
  media: video-i2c: use i2c regmap
  media: v4l2-common: add V4L2_FRACT_COMPARE
  media: vivid: use V4L2_FRACT_COMPARE
  media: video-i2c: support changing frame interval

Alexey Khoroshilov (1):
  media: mtk-vcodec: Release device nodes in mtk_vcodec_init_enc_pm()

Dafna Hirschfeld (3):
  media: vicodec: prepare support for various number of planes
  media: vicodec: Add support of greyscale format
  media: vicodec: Add support for 4 planes formats

Eric Biggers (1):
  media: v4l: constify v4l2_ioctls[]

Hans Verkuil (2):
  vim2m/vicodec: set device_caps in video_device struct
  vidioc-enum-fmt.rst: update list of valid buftypes

Julia Lawall (1):
  media: video-i2c: hwmon: constify vb2_ops structure

Malathi Gottam (1):
  media: venus: change the default value of GOP size

 Documentation/media/uapi/v4l/vidioc-enum-fmt.rst  |   8 ++-
 drivers/media/i2c/video-i2c.c | 153 
+++--
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c |  10 ++--
 drivers/media/platform/qcom/venus/venc_ctrls.c|   2 +-
 drivers/media/platform/vicodec/codec-fwht.c   |  84 
+--
 drivers/media/platform/vicodec/codec-fwht.h   |  15 +++--
 drivers/media/platform/vicodec/codec-v4l2-fwht.c  | 123 
+--
 drivers/media/platform/vicodec/codec-v4l2-fwht.h  |   3 +-
 drivers/media/platform/vicodec/vicodec-core.c |  45 +++
 drivers/media/platform/vim2m.c|   3 +-
 drivers/media/platform/vivid/vivid-vid-cap.c  |   9 +--
 drivers/media/v4l2-core/v4l2-ioctl.c  |   2 +-
 include/media/v4l2-common.h   |   5 ++
 13 files changed, 328 insertions(+), 134 deletions(-)


[PATCH v2] vim2m/vicodec: set device_caps in video_device struct

2018-11-21 Thread Hans Verkuil
Instead of setting device_caps/capabilities in the querycap ioctl, set
it in struct video_device instead.

Signed-off-by: Hans Verkuil 
---
Changes in v2: vfd->device_caps was only set for the first of the two video
devices. Set it for the second video_device as well.
---
 drivers/media/platform/vicodec/vicodec-core.c | 9 -
 drivers/media/platform/vim2m.c| 3 +--
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/vicodec/vicodec-core.c 
b/drivers/media/platform/vicodec/vicodec-core.c
index b292cff26c86..9b6416ba5901 100644
--- a/drivers/media/platform/vicodec/vicodec-core.c
+++ b/drivers/media/platform/vicodec/vicodec-core.c
@@ -397,11 +397,6 @@ static int vidioc_querycap(struct file *file, void *priv,
strncpy(cap->card, VICODEC_NAME, sizeof(cap->card) - 1);
snprintf(cap->bus_info, sizeof(cap->bus_info),
"platform:%s", VICODEC_NAME);
-   cap->device_caps =  V4L2_CAP_STREAMING |
-   (multiplanar ?
-V4L2_CAP_VIDEO_M2M_MPLANE :
-V4L2_CAP_VIDEO_M2M);
-   cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
return 0;
 }

@@ -1311,6 +1306,8 @@ static int vicodec_probe(struct platform_device *pdev)
vfd->lock = >enc_mutex;
vfd->v4l2_dev = >v4l2_dev;
strscpy(vfd->name, "vicodec-enc", sizeof(vfd->name));
+   vfd->device_caps = V4L2_CAP_STREAMING |
+   (multiplanar ? V4L2_CAP_VIDEO_M2M_MPLANE : V4L2_CAP_VIDEO_M2M);
v4l2_disable_ioctl(vfd, VIDIOC_DECODER_CMD);
v4l2_disable_ioctl(vfd, VIDIOC_TRY_DECODER_CMD);
video_set_drvdata(vfd, dev);
@@ -1327,6 +1324,8 @@ static int vicodec_probe(struct platform_device *pdev)
vfd = >dec_vfd;
vfd->lock = >dec_mutex;
vfd->v4l2_dev = >v4l2_dev;
+   vfd->device_caps = V4L2_CAP_STREAMING |
+   (multiplanar ? V4L2_CAP_VIDEO_M2M_MPLANE : V4L2_CAP_VIDEO_M2M);
strscpy(vfd->name, "vicodec-dec", sizeof(vfd->name));
v4l2_disable_ioctl(vfd, VIDIOC_ENCODER_CMD);
v4l2_disable_ioctl(vfd, VIDIOC_TRY_ENCODER_CMD);
diff --git a/drivers/media/platform/vim2m.c b/drivers/media/platform/vim2m.c
index d82db738f174..035c7b7c8d87 100644
--- a/drivers/media/platform/vim2m.c
+++ b/drivers/media/platform/vim2m.c
@@ -438,8 +438,6 @@ static int vidioc_querycap(struct file *file, void *priv,
strncpy(cap->card, MEM2MEM_NAME, sizeof(cap->card) - 1);
snprintf(cap->bus_info, sizeof(cap->bus_info),
"platform:%s", MEM2MEM_NAME);
-   cap->device_caps = V4L2_CAP_VIDEO_M2M | V4L2_CAP_STREAMING;
-   cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
return 0;
 }

@@ -999,6 +997,7 @@ static const struct video_device vim2m_videodev = {
.ioctl_ops  = _ioctl_ops,
.minor  = -1,
.release= video_device_release_empty,
+   .device_caps= V4L2_CAP_VIDEO_M2M | V4L2_CAP_STREAMING,
 };

 static const struct v4l2_m2m_ops m2m_ops = {
-- 
2.19.1




cron job: media_tree daily build: WARNINGS

2018-11-20 Thread Hans Verkuil
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 Nov 21 05:00:13 CET 2018
media-tree git hash:5200ab6a32d6055428896a49ec9e3b1652c1a100
media_build git hash:   a8aef9cea0a4a2f3ea86c0b37bd6a1378018c0c1
v4l-utils git hash: 7a98cfff67c41b82864a953d606270fbedb151dc
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: WARNINGS
linux-git-arm-davinci: WARNINGS
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: WARNINGS
linux-git-arm-stm32: WARNINGS
linux-git-arm64: OK
linux-git-i686: WARNINGS
linux-git-mips: OK
linux-git-powerpc64: WARNINGS
linux-git-sh: OK
linux-git-x86_64: WARNINGS
Check COMPILE_TEST: OK
linux-3.10.108-i686: OK
linux-3.10.108-x86_64: OK
linux-3.11.10-i686: OK
linux-3.11.10-x86_64: OK
linux-3.12.74-i686: OK
linux-3.12.74-x86_64: OK
linux-3.13.11-i686: OK
linux-3.13.11-x86_64: OK
linux-3.14.79-i686: OK
linux-3.14.79-x86_64: OK
linux-3.15.10-i686: OK
linux-3.15.10-x86_64: OK
linux-3.16.57-i686: OK
linux-3.16.57-x86_64: OK
linux-3.17.8-i686: OK
linux-3.17.8-x86_64: OK
linux-3.18.123-i686: OK
linux-3.18.123-x86_64: OK
linux-3.19.8-i686: OK
linux-3.19.8-x86_64: OK
linux-4.0.9-i686: OK
linux-4.0.9-x86_64: OK
linux-4.1.52-i686: OK
linux-4.1.52-x86_64: OK
linux-4.2.8-i686: OK
linux-4.2.8-x86_64: OK
linux-4.3.6-i686: OK
linux-4.3.6-x86_64: OK
linux-4.4.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/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


Re: [PATCH v8 3/3] media: add Rockchip VPU JPEG encoder driver

2018-11-20 Thread Hans Verkuil
On 11/19/2018 04:29 PM, Ezequiel Garcia wrote:
> Add a mem2mem driver for the VPU available on Rockchip SoCs.
> Currently only JPEG encoding is supported, for RK3399 and RK3288
> platforms.
> 
> Signed-off-by: Ezequiel Garcia 
> ---
>  MAINTAINERS   |   7 +
>  drivers/staging/media/Kconfig |   2 +
>  drivers/staging/media/Makefile|   1 +
>  drivers/staging/media/rockchip/vpu/Kconfig|  14 +
>  drivers/staging/media/rockchip/vpu/Makefile   |  10 +
>  drivers/staging/media/rockchip/vpu/TODO   |   9 +
>  .../media/rockchip/vpu/rk3288_vpu_hw.c| 118 +++
>  .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 133 
>  .../media/rockchip/vpu/rk3288_vpu_regs.h  | 442 +++
>  .../media/rockchip/vpu/rk3399_vpu_hw.c| 118 +++
>  .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 160 
>  .../media/rockchip/vpu/rk3399_vpu_regs.h  | 600 +++
>  .../staging/media/rockchip/vpu/rockchip_vpu.h | 237 ++
>  .../media/rockchip/vpu/rockchip_vpu_common.h  |  29 +
>  .../media/rockchip/vpu/rockchip_vpu_drv.c | 535 +
>  .../media/rockchip/vpu/rockchip_vpu_enc.c | 701 ++
>  .../media/rockchip/vpu/rockchip_vpu_hw.h  |  58 ++
>  .../media/rockchip/vpu/rockchip_vpu_jpeg.c| 289 
>  .../media/rockchip/vpu/rockchip_vpu_jpeg.h|  12 +
>  19 files changed, 3475 insertions(+)
>  create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig
>  create mode 100644 drivers/staging/media/rockchip/vpu/Makefile
>  create mode 100644 drivers/staging/media/rockchip/vpu/TODO
>  create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c
>  create mode 100644 
> drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
>  create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h
>  create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c
>  create mode 100644 
> drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
>  create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h
>  create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h
>  create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h
>  create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
>  create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
>  create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h
>  create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c
>  create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a8588dedc683..e5a294453393 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -12742,6 +12742,13 @@ S:   Maintained
>  F:   drivers/media/platform/rockchip/rga/
>  F:   Documentation/devicetree/bindings/media/rockchip-rga.txt
>  
> +ROCKCHIP VPU CODEC DRIVER
> +M:   Ezequiel Garcia 
> +L:   linux-media@vger.kernel.org
> +S:   Maintained
> +F:   drivers/staging/media/platform/rockchip/vpu/
> +F:   Documentation/devicetree/bindings/media/rockchip-vpu.txt
> +
>  ROCKER DRIVER
>  M:   Jiri Pirko 
>  L:   net...@vger.kernel.org
> diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig
> index b3620a8f2d9f..c6f3404dea43 100644
> --- a/drivers/staging/media/Kconfig
> +++ b/drivers/staging/media/Kconfig
> @@ -31,6 +31,8 @@ source "drivers/staging/media/mt9t031/Kconfig"
>  
>  source "drivers/staging/media/omap4iss/Kconfig"
>  
> +source "drivers/staging/media/rockchip/vpu/Kconfig"
> +
>  source "drivers/staging/media/sunxi/Kconfig"
>  
>  source "drivers/staging/media/tegra-vde/Kconfig"
> diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile
> index 42948f805548..43c7bee1fc8c 100644
> --- a/drivers/staging/media/Makefile
> +++ b/drivers/staging/media/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_VIDEO_OMAP4) += omap4iss/
>  obj-$(CONFIG_VIDEO_SUNXI)+= sunxi/
>  obj-$(CONFIG_TEGRA_VDE)  += tegra-vde/
>  obj-$(CONFIG_VIDEO_ZORAN)+= zoran/
> +obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip/vpu/
> diff --git a/drivers/staging/media/rockchip/vpu/Kconfig 
> b/drivers/staging/media/rockchip/vpu/Kconfig
> new file mode 100644
> index ..fa65c03d65bf
> --- /dev/null
> +++ b/drivers/staging/media/rockchip/vpu/Kconfig
> @@ -0,0 +1,14 @@
> +config VIDEO_ROCKCHIP_VPU
> + tristate "Rockchip VPU driver"
> + depends on ARCH_ROCKCHIP || COMPILE_TEST
> + depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER
> + select VIDEOBUF2_DMA_CONTIG
> + select VIDEOBUF2_VMALLOC
> + select V4L2_MEM2MEM_DEV
> + default n
> + help
> +   Support for the Video Processing Unit present on Rockchip SoC,
> +   which accelerates video and image encoding and decoding.
> +   To compile this driver as a module, choose M here: the module
> +   will be called rockchip-vpu.
> +
> diff --git 

[PATCH for v4.20] gspca: fix frame overflow error

2018-11-20 Thread Hans Verkuil
When converting gspca to vb2 I missed that fact that the buffer sizes
were rounded up to the next page size. As a result some gspca drivers
(spca561 being one of them) reported frame overflows.

Modify the code to align the buffer sizes to the next page size, just
as the original code did.

Fixes: 1f5965c4dfd7 ("media: gspca: convert to vb2")
Signed-off-by: Hans Verkuil 
Tested-off-by: Hans Verkuil 
Reported-by: softwarebugs 
Cc:   # for v4.18 and up
---
diff --git a/drivers/media/usb/gspca/gspca.c b/drivers/media/usb/gspca/gspca.c
index fce9d6f4b7c9..3137f5d89d80 100644
--- a/drivers/media/usb/gspca/gspca.c
+++ b/drivers/media/usb/gspca/gspca.c
@@ -426,10 +426,10 @@ void gspca_frame_add(struct gspca_dev *gspca_dev,

/* append the packet to the frame buffer */
if (len > 0) {
-   if (gspca_dev->image_len + len > gspca_dev->pixfmt.sizeimage) {
+   if (gspca_dev->image_len + len > 
PAGE_ALIGN(gspca_dev->pixfmt.sizeimage)) {
gspca_err(gspca_dev, "frame overflow %d > %d\n",
  gspca_dev->image_len + len,
- gspca_dev->pixfmt.sizeimage);
+ PAGE_ALIGN(gspca_dev->pixfmt.sizeimage));
packet_type = DISCARD_PACKET;
} else {
 /* !! image is NULL only when last pkt is LAST or DISCARD
@@ -1297,18 +1297,19 @@ static int gspca_queue_setup(struct vb2_queue *vq,
 unsigned int sizes[], struct device *alloc_devs[])
 {
struct gspca_dev *gspca_dev = vb2_get_drv_priv(vq);
+   unsigned int size = PAGE_ALIGN(gspca_dev->pixfmt.sizeimage);

if (*nplanes)
-   return sizes[0] < gspca_dev->pixfmt.sizeimage ? -EINVAL : 0;
+   return sizes[0] < size ? -EINVAL : 0;
*nplanes = 1;
-   sizes[0] = gspca_dev->pixfmt.sizeimage;
+   sizes[0] = size;
return 0;
 }

 static int gspca_buffer_prepare(struct vb2_buffer *vb)
 {
struct gspca_dev *gspca_dev = vb2_get_drv_priv(vb->vb2_queue);
-   unsigned long size = gspca_dev->pixfmt.sizeimage;
+   unsigned long size = PAGE_ALIGN(gspca_dev->pixfmt.sizeimage);

if (vb2_plane_size(vb, 0) < size) {
gspca_err(gspca_dev, "buffer too small (%lu < %lu)\n",


Re: [PATCH] videodev2.h: add V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF/CREATE_BUFS

2018-11-20 Thread Hans Verkuil
On 11/20/2018 10:27 AM, Sakari Ailus wrote:
> Hi Hans,
> 
> On Tue, Nov 20, 2018 at 09:58:43AM +0100, Hans Verkuil wrote:
>> Add new buffer capability flags to indicate if the VIDIOC_PREPARE_BUF or
>> VIDIOC_CREATE_BUFS ioctls are supported.
> 
> Are there practical benefits from the change for the user space?

The more important ioctl to know about is PREPARE_BUF. I noticed this when 
working
on v4l2-compliance: the only way to know for an application if PREPARE_BUF 
exists
is by trying it, but then you already have prepared a buffer. That's not what 
you
want in the application, you need a way to know up front if prepare_buf is 
present
or not without having to actually execute it.

CREATE_BUFS was added because not all drivers support it. It can be dropped 
since
it is possible to test for the existence of CREATE_BUFS without actually 
allocating
anything, but if I'm adding V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF anyway, then it is
trivial to add V4L2_BUF_CAP_SUPPORTS_CREATE_BUFS as well to avoid an additional
ioctl call.

Hmm, I should have explained this in the commit log.

Regards,

Hans

> 
>>
>> Signed-off-by: Hans Verkuil 
>> ---
>> Note: the flag bits will change since there are two other patches that add
>> flags, so the numbering will change.
>> ---
>> diff --git a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst 
>> b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
>> index d40c60e8..abf925484aff 100644
>> --- a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
>> +++ b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
>> @@ -112,6 +112,8 @@ any DMA in progress, an implicit
>>  .. _V4L2-BUF-CAP-SUPPORTS-USERPTR:
>>  .. _V4L2-BUF-CAP-SUPPORTS-DMABUF:
>>  .. _V4L2-BUF-CAP-SUPPORTS-REQUESTS:
>> +.. _V4L2-BUF-CAP-SUPPORTS-PREPARE-BUF:
>> +.. _V4L2-BUF-CAP-SUPPORTS-CREATE-BUFS:
>>
>>  .. cssclass:: longtable
>>
>> @@ -132,6 +134,12 @@ any DMA in progress, an implicit
>>  * - ``V4L2_BUF_CAP_SUPPORTS_REQUESTS``
>>- 0x0008
>>- This buffer type supports :ref:`requests `.
>> +* - ``V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF``
>> +  - 0x0010
>> +  - This buffer type supports :ref:`VIDIOC_PREPARE_BUF`.
>> +* - ``V4L2_BUF_CAP_SUPPORTS_CREATE_BUFS``
>> +  - 0x0020
>> +  - 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 a17033ab2c22..27c0fafca0bf 100644
>> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
>> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
>> @@ -871,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;D_PACK
>>  }
>>
>> +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,
>> @@ -879,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))
>> @@ -901,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 c8e8ff810190..6648f8ba2277 100644
>> --- a/include/uapi/linux/videodev2.h
>> +++ b/include/uapi/linux/videodev2.h
>> @@ -879,6 +879,8 @@ struct v4l2_requestbuffers {
>>  #define V4L2_BUF_CAP_SUPPORTS_USERPTR   (1 << 1)
>>  #define V4L2_BUF_CAP_SUPPORTS_DMABUF(1 << 2)
>>  #define V4L2_BUF_CAP_SUPPORTS_REQUESTS  (1 << 3)
> 
> Could you align the previous lines to match the ones below?
> 
>> +#define V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF   (1 << 4)
>> +#define V4L2_BUF_CAP_SUPPORTS_CREATE_BUFS   (1 << 5)
>>
>>  /**
>>   * struct v4l2_plane - plane info for multi-planar buffers
> 



[GIT PULL FOR v4.21] mem2mem, venus and vb2 fixes/improvements

2018-11-20 Thread Hans Verkuil



The following changes since commit fbe57dde7126d1b2712ab5ea93fb9d15f89de708:

  media: ov7740: constify structures stored in fields of v4l2_subdev_ops 
structure (2018-11-06 07:17:02 -0500)

are available in the Git repository at:

  git://linuxtv.org/hverkuil/media_tree.git tags/br-v4.21e

for you to fetch changes up to ef1b25960c21848d5bb748296059cab4a4a0ee4c:

  videobuf2-v4l2: drop WARN_ON in vb2_warn_zero_bytesused() (2018-11-20 
10:04:50 +0100)


Tag branch


Ezequiel Garcia (4):
  mem2mem: Require capture and output mutexes to match
  v4l2-ioctl.c: Simplify locking for m2m devices
  v4l2-mem2mem: Avoid calling .device_run in v4l2_m2m_job_finish
  media: cedrus: Get rid of interrupt bottom-half

Hans Verkuil (1):
  videobuf2-v4l2: drop WARN_ON in vb2_warn_zero_bytesused()

John Sheu (1):
  media: vb2: Allow reqbufs(0) with "in use" MMAP buffers

Sakari Ailus (1):
  v4l2-mem2mem: Simplify exiting the function in __v4l2_m2m_try_schedule

Stanimir Varbanov (1):
  venus: firmware: register separate platform_device for firmware loader

vgaro...@codeaurora.org (4):
  venus: firmware: add routine to reset ARM9
  venus: firmware: move load firmware in a separate function
  venus: firmware: add no TZ boot and shutdown routine
  dt-bindings: media: Document bindings for venus firmware device

 Documentation/devicetree/bindings/media/qcom,venus.txt |  14 ++-
 Documentation/media/uapi/v4l/vidioc-reqbufs.rst|  17 +++-
 drivers/media/common/videobuf2/videobuf2-core.c|   8 +-
 drivers/media/common/videobuf2/videobuf2-v4l2.c|   3 +-
 drivers/media/platform/qcom/venus/core.c   |  24 +++--
 drivers/media/platform/qcom/venus/core.h   |   6 ++
 drivers/media/platform/qcom/venus/firmware.c   | 235 
+++-
 drivers/media/platform/qcom/venus/firmware.h   |  17 +++-
 drivers/media/platform/qcom/venus/hfi_venus.c  |  13 +--
 drivers/media/platform/qcom/venus/hfi_venus_io.h   |   8 ++
 drivers/media/v4l2-core/v4l2-ioctl.c   |  47 +-
 drivers/media/v4l2-core/v4l2-mem2mem.c |  66 +-
 drivers/staging/media/sunxi/cedrus/cedrus_hw.c |  26 ++
 include/uapi/linux/videodev2.h |   1 +
 14 files changed, 344 insertions(+), 141 deletions(-)


[PATCH] videodev2.h: add V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF/CREATE_BUFS

2018-11-20 Thread Hans Verkuil
Add new buffer capability flags to indicate if the VIDIOC_PREPARE_BUF or
VIDIOC_CREATE_BUFS ioctls are supported.

Signed-off-by: Hans Verkuil 
---
Note: the flag bits will change since there are two other patches that add
flags, so the numbering will change.
---
diff --git a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst 
b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
index d40c60e8..abf925484aff 100644
--- a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
+++ b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
@@ -112,6 +112,8 @@ any DMA in progress, an implicit
 .. _V4L2-BUF-CAP-SUPPORTS-USERPTR:
 .. _V4L2-BUF-CAP-SUPPORTS-DMABUF:
 .. _V4L2-BUF-CAP-SUPPORTS-REQUESTS:
+.. _V4L2-BUF-CAP-SUPPORTS-PREPARE-BUF:
+.. _V4L2-BUF-CAP-SUPPORTS-CREATE-BUFS:

 .. cssclass:: longtable

@@ -132,6 +134,12 @@ any DMA in progress, an implicit
 * - ``V4L2_BUF_CAP_SUPPORTS_REQUESTS``
   - 0x0008
   - This buffer type supports :ref:`requests `.
+* - ``V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF``
+  - 0x0010
+  - This buffer type supports :ref:`VIDIOC_PREPARE_BUF`.
+* - ``V4L2_BUF_CAP_SUPPORTS_CREATE_BUFS``
+  - 0x0020
+  - 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 a17033ab2c22..27c0fafca0bf 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -871,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,
@@ -879,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))
@@ -901,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 c8e8ff810190..6648f8ba2277 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -879,6 +879,8 @@ struct v4l2_requestbuffers {
 #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_PREPARE_BUF  (1 << 4)
+#define V4L2_BUF_CAP_SUPPORTS_CREATE_BUFS  (1 << 5)

 /**
  * struct v4l2_plane - plane info for multi-planar buffers


Re: [PATCH 2/2] media: video-i2c: add Melexis MLX90640 thermal camera support

2018-11-20 Thread Hans Verkuil
On 11/19/2018 09:54 PM, Matt Ranostay wrote:
> On Mon, Nov 19, 2018 at 6:26 AM Hans Verkuil  wrote:
>>
>> On 11/01/2018 05:15 AM, Matt Ranostay wrote:
>>> Add initial support for MLX90640 thermal cameras which output an 32x24
>>> greyscale pixel image along with 2 rows of coefficent data.
>>>
>>> Because of this the data outputed is really 32x26 and needs the two rows
>>> removed after using the coefficent information to generate processed
>>> images in userspace.
>>>
>>> Signed-off-by: Matt Ranostay 
>>> ---
>>>  drivers/media/i2c/Kconfig |   1 +
>>>  drivers/media/i2c/video-i2c.c | 110 +-
>>>  2 files changed, 110 insertions(+), 1 deletion(-)
>>
>>
>>
>>>
>>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
>>> index 704af210e270..4bfb2c66d192 100644
>>> --- a/drivers/media/i2c/Kconfig
>>> +++ b/drivers/media/i2c/Kconfig
>>> @@ -1085,6 +1085,7 @@ config VIDEO_I2C
>>> Enable the I2C transport video support which supports the
>>> following:
>>>  * Panasonic AMG88xx Grid-Eye Sensors
>>> +* Melexis MLX90640 Thermal Cameras
>>>
>>> To compile this driver as a module, choose M here: the
>>> module will be called video-i2c
>>> diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
>>> index 6d3b6df0b634..38ade8cb7656 100644
>>> --- a/drivers/media/i2c/video-i2c.c
>>> +++ b/drivers/media/i2c/video-i2c.c
>>> @@ -6,6 +6,7 @@
>>>   *
>>>   * Supported:
>>>   * - Panasonic AMG88xx Grid-Eye Sensors
>>> + * - Melexis MLX90640 Thermal Cameras
>>>   */
>>>
>>>  #include 
>>> @@ -18,6 +19,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -66,12 +68,26 @@ static const struct v4l2_frmsize_discrete amg88xx_size 
>>> = {
>>>   .height = 8,
>>>  };
>>>
>>> +static const struct v4l2_fmtdesc mlx90640_format = {
>>> + .pixelformat = V4L2_PIX_FMT_Y16_BE,
>>> +};
>>> +
>>> +static const struct v4l2_frmsize_discrete mlx90640_size = {
>>> + .width = 32,
>>> + .height = 26, /* 24 lines of pixel data + 2 lines of processing data 
>>> */
>>> +};
>>> +
>>>  static const struct regmap_config amg88xx_regmap_config = {
>>>   .reg_bits = 8,
>>>   .val_bits = 8,
>>>   .max_register = 0xff
>>>  };
>>>
>>> +static const struct regmap_config mlx90640_regmap_config = {
>>> + .reg_bits = 16,
>>> + .val_bits = 16,
>>> +};
>>> +
>>>  struct video_i2c_chip {
>>>   /* video dimensions */
>>>   const struct v4l2_fmtdesc *format;
>>> @@ -88,6 +104,7 @@ struct video_i2c_chip {
>>>   unsigned int bpp;
>>>
>>>   const struct regmap_config *regmap_config;
>>> + struct nvmem_config *nvmem_config;
>>>
>>>   /* setup function */
>>>   int (*setup)(struct video_i2c_data *data);
>>> @@ -102,6 +119,22 @@ struct video_i2c_chip {
>>>   int (*hwmon_init)(struct video_i2c_data *data);
>>>  };
>>>
>>> +static int mlx90640_nvram_read(void *priv, unsigned int offset, void *val,
>>> +  size_t bytes)
>>> +{
>>> + struct video_i2c_data *data = priv;
>>> +
>>> + return regmap_bulk_read(data->regmap, 0x2400 + offset, val, bytes);
>>> +}
>>> +
>>> +static struct nvmem_config mlx90640_nvram_config = {
>>> + .name = "mlx90640_nvram",
>>> + .word_size = 2,
>>> + .stride = 1,
>>> + .size = 1664,
>>> + .reg_read = mlx90640_nvram_read,
>>> +};
>>> +
>>>  /* Power control register */
>>>  #define AMG88XX_REG_PCTL 0x00
>>>  #define AMG88XX_PCTL_NORMAL  0x00
>>> @@ -122,12 +155,23 @@ struct video_i2c_chip {
>>>  /* Temperature register */
>>>  #define AMG88XX_REG_T01L 0x80
>>>
>>> +/* Control register */
>>> +#define MLX90640_REG_CTL10x800d
>>> +#define MLX90640_REG_CTL1_MASK   0x0380
>>> +#define MLX90640_REG_CTL1_MASK_SHIFT 7
>>> +
>>>  static int amg88xx_xfer(struc

cron job: media_tree daily build: WARNINGS

2018-11-19 Thread Hans Verkuil
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Tue Nov 20 05:00:12 CET 2018
media-tree git hash:fbe57dde7126d1b2712ab5ea93fb9d15f89de708
media_build git hash:   a8aef9cea0a4a2f3ea86c0b37bd6a1378018c0c1
v4l-utils git hash: 044d5ab7b0d02683070d01a369c73d462d7a0cee
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: WARNINGS
linux-git-arm-davinci: WARNINGS
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: WARNINGS
linux-git-arm-stm32: WARNINGS
linux-git-arm64: OK
linux-git-i686: WARNINGS
linux-git-mips: OK
linux-git-powerpc64: WARNINGS
linux-git-sh: OK
linux-git-x86_64: WARNINGS
Check COMPILE_TEST: OK
linux-3.10.108-i686: OK
linux-3.10.108-x86_64: OK
linux-3.11.10-i686: OK
linux-3.11.10-x86_64: OK
linux-3.12.74-i686: OK
linux-3.12.74-x86_64: OK
linux-3.13.11-i686: OK
linux-3.13.11-x86_64: OK
linux-3.14.79-i686: OK
linux-3.14.79-x86_64: OK
linux-3.15.10-i686: OK
linux-3.15.10-x86_64: OK
linux-3.16.57-i686: OK
linux-3.16.57-x86_64: OK
linux-3.17.8-i686: OK
linux-3.17.8-x86_64: OK
linux-3.18.123-i686: OK
linux-3.18.123-x86_64: OK
linux-3.19.8-i686: OK
linux-3.19.8-x86_64: OK
linux-4.0.9-i686: OK
linux-4.0.9-x86_64: OK
linux-4.1.52-i686: OK
linux-4.1.52-x86_64: OK
linux-4.2.8-i686: OK
linux-4.2.8-x86_64: OK
linux-4.3.6-i686: OK
linux-4.3.6-x86_64: OK
linux-4.4.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/Tuesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html


[PATCH] videobuf2-v4l2: drop WARN_ON in vb2_warn_zero_bytesused()

2018-11-19 Thread Hans Verkuil
Userspace shouldn't set bytesused to 0 for output buffers.
vb2_warn_zero_bytesused() warns about this (only once!), but it also
calls WARN_ON(1), which is confusing since it is not immediately clear
that it warns about a 0 value for bytesused.

Just drop the WARN_ON as it serves no purpose.

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c 
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index a17033ab2c22..713326ef4e72 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -158,7 +158,6 @@ static void vb2_warn_zero_bytesused(struct vb2_buffer *vb)
return;

check_once = true;
-   WARN_ON(1);

pr_warn("use of bytesused == 0 is deprecated and will be removed in the 
future,\n");
if (vb->vb2_queue->allow_zero_bytesused)


Re: [PATCH v4 6/6] media: video-i2c: support runtime PM

2018-11-19 Thread Hans Verkuil
On 11/19/2018 03:26 PM, Hans Verkuil wrote:
> On 10/20/2018 04:26 PM, Akinobu Mita wrote:
>> AMG88xx has a register for setting operating mode.  This adds support
>> runtime PM by changing the operating mode.
>>
>> The instruction for changing sleep mode to normal mode is from the
>> reference specifications.
>>
>> https://docid81hrs3j1.cloudfront.net/medialibrary/2017/11/PANA-S-A0002141979-1.pdf
>>
>> Cc: Matt Ranostay 
>> Cc: Sakari Ailus 
>> Cc: Hans Verkuil 
>> Cc: Mauro Carvalho Chehab 
>> Reviewed-by: Matt Ranostay 
>> Acked-by: Sakari Ailus 
>> Signed-off-by: Akinobu Mita 

For the record: I've accepted patches 1-5, so no need to repost the whole 
series,
just this patch needs an update.

Regards,

Hans


[GIT PULL FOR v4.21] Various fixes/improvements

2018-11-19 Thread Hans Verkuil
The following changes since commit fbe57dde7126d1b2712ab5ea93fb9d15f89de708:

  media: ov7740: constify structures stored in fields of v4l2_subdev_ops 
structure (2018-11-06 07:17:02 -0500)

are available in the Git repository at:

  git://linuxtv.org/hverkuil/media_tree.git tags/br-v4.21d

for you to fetch changes up to b8e1d6a3dd646b57a7821a4b51796edee64787f4:

  media: vicodec: Add support for 4 planes formats (2018-11-19 15:47:22 +0100)


Tag branch


Akinobu Mita (5):
  media: video-i2c: avoid accessing released memory area when removing 
driver
  media: video-i2c: use i2c regmap
  media: v4l2-common: add V4L2_FRACT_COMPARE
  media: vivid: use V4L2_FRACT_COMPARE
  media: video-i2c: support changing frame interval

Alexey Khoroshilov (1):
  media: mtk-vcodec: Release device nodes in mtk_vcodec_init_enc_pm()

Dafna Hirschfeld (3):
  media: vicodec: prepare support for various number of planes
  media: vicodec: Add support of greyscale format
  media: vicodec: Add support for 4 planes formats

Eric Biggers (1):
  media: v4l: constify v4l2_ioctls[]

Hans Verkuil (2):
  vim2m/vicodec: set device_caps in video_device struct
  vidioc-enum-fmt.rst: update list of valid buftypes

Julia Lawall (1):
  media: video-i2c: hwmon: constify vb2_ops structure

Malathi Gottam (1):
  media: venus: change the default value of GOP size

 Documentation/media/uapi/v4l/vidioc-enum-fmt.rst  |   8 ++-
 drivers/media/i2c/video-i2c.c | 153 
+++--
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c |  10 ++--
 drivers/media/platform/qcom/venus/venc_ctrls.c|   2 +-
 drivers/media/platform/vicodec/codec-fwht.c   |  84 
+--
 drivers/media/platform/vicodec/codec-fwht.h   |  15 +++--
 drivers/media/platform/vicodec/codec-v4l2-fwht.c  | 123 
+--
 drivers/media/platform/vicodec/codec-v4l2-fwht.h  |   3 +-
 drivers/media/platform/vicodec/vicodec-core.c |  43 ++
 drivers/media/platform/vim2m.c|   3 +-
 drivers/media/platform/vivid/vivid-vid-cap.c  |   9 +--
 drivers/media/v4l2-core/v4l2-ioctl.c  |   2 +-
 include/media/v4l2-common.h   |   5 ++
 13 files changed, 326 insertions(+), 134 deletions(-)


Re: [PATCH 2/2] media: video-i2c: add Melexis MLX90640 thermal camera support

2018-11-19 Thread Hans Verkuil
On 11/01/2018 05:15 AM, Matt Ranostay wrote:
> Add initial support for MLX90640 thermal cameras which output an 32x24
> greyscale pixel image along with 2 rows of coefficent data.
> 
> Because of this the data outputed is really 32x26 and needs the two rows
> removed after using the coefficent information to generate processed
> images in userspace.
> 
> Signed-off-by: Matt Ranostay 
> ---
>  drivers/media/i2c/Kconfig |   1 +
>  drivers/media/i2c/video-i2c.c | 110 +-
>  2 files changed, 110 insertions(+), 1 deletion(-)



> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 704af210e270..4bfb2c66d192 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -1085,6 +1085,7 @@ config VIDEO_I2C
> Enable the I2C transport video support which supports the
> following:
>  * Panasonic AMG88xx Grid-Eye Sensors
> +* Melexis MLX90640 Thermal Cameras
>  
> To compile this driver as a module, choose M here: the
> module will be called video-i2c
> diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
> index 6d3b6df0b634..38ade8cb7656 100644
> --- a/drivers/media/i2c/video-i2c.c
> +++ b/drivers/media/i2c/video-i2c.c
> @@ -6,6 +6,7 @@
>   *
>   * Supported:
>   * - Panasonic AMG88xx Grid-Eye Sensors
> + * - Melexis MLX90640 Thermal Cameras
>   */
>  
>  #include 
> @@ -18,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -66,12 +68,26 @@ static const struct v4l2_frmsize_discrete amg88xx_size = {
>   .height = 8,
>  };
>  
> +static const struct v4l2_fmtdesc mlx90640_format = {
> + .pixelformat = V4L2_PIX_FMT_Y16_BE,
> +};
> +
> +static const struct v4l2_frmsize_discrete mlx90640_size = {
> + .width = 32,
> + .height = 26, /* 24 lines of pixel data + 2 lines of processing data */
> +};
> +
>  static const struct regmap_config amg88xx_regmap_config = {
>   .reg_bits = 8,
>   .val_bits = 8,
>   .max_register = 0xff
>  };
>  
> +static const struct regmap_config mlx90640_regmap_config = {
> + .reg_bits = 16,
> + .val_bits = 16,
> +};
> +
>  struct video_i2c_chip {
>   /* video dimensions */
>   const struct v4l2_fmtdesc *format;
> @@ -88,6 +104,7 @@ struct video_i2c_chip {
>   unsigned int bpp;
>  
>   const struct regmap_config *regmap_config;
> + struct nvmem_config *nvmem_config;
>  
>   /* setup function */
>   int (*setup)(struct video_i2c_data *data);
> @@ -102,6 +119,22 @@ struct video_i2c_chip {
>   int (*hwmon_init)(struct video_i2c_data *data);
>  };
>  
> +static int mlx90640_nvram_read(void *priv, unsigned int offset, void *val,
> +  size_t bytes)
> +{
> + struct video_i2c_data *data = priv;
> +
> + return regmap_bulk_read(data->regmap, 0x2400 + offset, val, bytes);
> +}
> +
> +static struct nvmem_config mlx90640_nvram_config = {
> + .name = "mlx90640_nvram",
> + .word_size = 2,
> + .stride = 1,
> + .size = 1664,
> + .reg_read = mlx90640_nvram_read,
> +};
> +
>  /* Power control register */
>  #define AMG88XX_REG_PCTL 0x00
>  #define AMG88XX_PCTL_NORMAL  0x00
> @@ -122,12 +155,23 @@ struct video_i2c_chip {
>  /* Temperature register */
>  #define AMG88XX_REG_T01L 0x80
>  
> +/* Control register */
> +#define MLX90640_REG_CTL10x800d
> +#define MLX90640_REG_CTL1_MASK   0x0380
> +#define MLX90640_REG_CTL1_MASK_SHIFT 7
> +
>  static int amg88xx_xfer(struct video_i2c_data *data, char *buf)
>  {
>   return regmap_bulk_read(data->regmap, AMG88XX_REG_T01L, buf,
>   data->chip->buffer_size);
>  }
>  
> +static int mlx90640_xfer(struct video_i2c_data *data, char *buf)
> +{
> + return regmap_bulk_read(data->regmap, 0x400, buf,
> + data->chip->buffer_size);
> +}
> +
>  static int amg88xx_setup(struct video_i2c_data *data)
>  {
>   unsigned int mask = AMG88XX_FPSC_1FPS;
> @@ -141,6 +185,27 @@ static int amg88xx_setup(struct video_i2c_data *data)
>   return regmap_update_bits(data->regmap, AMG88XX_REG_FPSC, mask, val);
>  }
>  
> +static int mlx90640_setup(struct video_i2c_data *data)
> +{
> + unsigned int n, idx;
> +
> + for (n = 0; n < data->chip->num_frame_intervals - 1; n++) {
> + if (data->frame_interval.numerator
> + != data->chip->frame_intervals[n].numerator)
> + continue;
> +
> + if (data->frame_interval.denominator
> + == data->chip->frame_intervals[n].denominator)
> + break;
> + }
> +
> + idx = data->chip->num_frame_intervals - n - 1;
> +
> + return regmap_update_bits(data->regmap, MLX90640_REG_CTL1,
> +   MLX90640_REG_CTL1_MASK,
> +   idx << MLX90640_REG_CTL1_MASK_SHIFT);
> +}
> +
>  

Re: [PATCH v4 6/6] media: video-i2c: support runtime PM

2018-11-19 Thread Hans Verkuil
On 10/20/2018 04:26 PM, Akinobu Mita wrote:
> AMG88xx has a register for setting operating mode.  This adds support
> runtime PM by changing the operating mode.
> 
> The instruction for changing sleep mode to normal mode is from the
> reference specifications.
> 
> https://docid81hrs3j1.cloudfront.net/medialibrary/2017/11/PANA-S-A0002141979-1.pdf
> 
> Cc: Matt Ranostay 
> Cc: Sakari Ailus 
> Cc: Hans Verkuil 
> Cc: Mauro Carvalho Chehab 
> Reviewed-by: Matt Ranostay 
> Acked-by: Sakari Ailus 
> Signed-off-by: Akinobu Mita 
> ---
> * v4
> - Move set_power() call into release() callback
> 
>  drivers/media/i2c/video-i2c.c | 141 
> +-
>  1 file changed, 139 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
> index 3334fc2..384a046 100644
> --- a/drivers/media/i2c/video-i2c.c
> +++ b/drivers/media/i2c/video-i2c.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -94,10 +95,23 @@ struct video_i2c_chip {
>   /* xfer function */
>   int (*xfer)(struct video_i2c_data *data, char *buf);
>  
> + /* power control function */
> + int (*set_power)(struct video_i2c_data *data, bool on);
> +
>   /* hwmon init function */
>   int (*hwmon_init)(struct video_i2c_data *data);
>  };
>  
> +/* Power control register */
> +#define AMG88XX_REG_PCTL 0x00
> +#define AMG88XX_PCTL_NORMAL  0x00
> +#define AMG88XX_PCTL_SLEEP   0x10
> +
> +/* Reset register */
> +#define AMG88XX_REG_RST  0x01
> +#define AMG88XX_RST_FLAG 0x30
> +#define AMG88XX_RST_INIT 0x3f
> +
>  /* Frame rate register */
>  #define AMG88XX_REG_FPSC 0x02
>  #define AMG88XX_FPSC_1FPSBIT(0)
> @@ -127,6 +141,59 @@ static int amg88xx_setup(struct video_i2c_data *data)
>   return regmap_update_bits(data->regmap, AMG88XX_REG_FPSC, mask, val);
>  }
>  
> +static int amg88xx_set_power_on(struct video_i2c_data *data)
> +{
> + int ret;
> +
> + ret = regmap_write(data->regmap, AMG88XX_REG_PCTL, AMG88XX_PCTL_NORMAL);
> + if (ret)
> + return ret;
> +
> + msleep(50);
> +
> + ret = regmap_write(data->regmap, AMG88XX_REG_RST, AMG88XX_RST_INIT);
> + if (ret)
> + return ret;
> +
> + msleep(2);

WARNING: msleep < 20ms can sleep for up to 20ms; see 
Documentation/timers/timers-howto.txt
#55: FILE: drivers/media/i2c/video-i2c.c:158:
+   msleep(2);

Use usleep_range instead.

Regards,

Hans

> +
> + ret = regmap_write(data->regmap, AMG88XX_REG_RST, AMG88XX_RST_FLAG);
> + if (ret)
> + return ret;
> +
> + /*
> +  * Wait two frames before reading thermistor and temperature registers
> +  */
> + msleep(200);
> +
> + return 0;
> +}
> +
> +static int amg88xx_set_power_off(struct video_i2c_data *data)
> +{
> + int ret;
> +
> + ret = regmap_write(data->regmap, AMG88XX_REG_PCTL, AMG88XX_PCTL_SLEEP);
> + if (ret)
> + return ret;
> + /*
> +  * Wait for a while to avoid resuming normal mode immediately after
> +  * entering sleep mode, otherwise the device occasionally goes wrong
> +  * (thermistor and temperature registers are not updated at all)
> +  */
> + msleep(100);
> +
> + return 0;
> +}
> +
> +static int amg88xx_set_power(struct video_i2c_data *data, bool on)
> +{
> + if (on)
> + return amg88xx_set_power_on(data);
> +
> + return amg88xx_set_power_off(data);
> +}
> +
>  #if IS_ENABLED(CONFIG_HWMON)
>  
>  static const u32 amg88xx_temp_config[] = {
> @@ -158,7 +225,15 @@ static int amg88xx_read(struct device *dev, enum 
> hwmon_sensor_types type,
>   __le16 buf;
>   int tmp;
>  
> + tmp = pm_runtime_get_sync(regmap_get_device(data->regmap));
> + if (tmp < 0) {
> + pm_runtime_put_noidle(regmap_get_device(data->regmap));
> + return tmp;
> + }
> +
>   tmp = regmap_bulk_read(data->regmap, AMG88XX_REG_TTHL, , 2);
> + pm_runtime_mark_last_busy(regmap_get_device(data->regmap));
> + pm_runtime_put_autosuspend(regmap_get_device(data->regmap));
>   if (tmp)
>   return tmp;
>  
> @@ -217,6 +292,7 @@ static const struct video_i2c_chip video_i2c_chip[] = {
>   .regmap_config  = _regmap_config,
>   .setup  = _setup,
>   .xfer   = _xfer,
> + .set_power  = amg88xx_set_power,

  1   2   3   4   5   6   7   8   9   10   >