cron job: media_tree daily build: ERRORS

2018-07-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:   Wed Jul  4 05:00:11 CEST 2018
media-tree git hash:3c4a737267e89aafa6308c6c456d2ebea3fcd085
media_build git hash:   90c56d1e6345747b6af929867f5b7c16017dcf02
v4l-utils git hash: 924e0e570cd92ee7d7728cdfa29d5deb57b850fe
edid-decode git hash:   ab18befbcacd6cd4dff63faa82e32700369d6f25
gcc version:i686-linux-gcc (GCC) 8.1.0
sparse version: 0.5.2
smatch version: 0.5.1
host hardware:  x86_64
host os:4.16.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-2.6.36.4-i686: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-i686: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-i686: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-i686: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.101-i686: OK
linux-3.0.101-x86_64: OK
linux-3.1.10-i686: OK
linux-3.1.10-x86_64: OK
linux-3.2.101-i686: OK
linux-3.2.101-x86_64: OK
linux-3.3.8-i686: OK
linux-3.3.8-x86_64: OK
linux-3.4.113-i686: OK
linux-3.4.113-x86_64: OK
linux-3.5.7-i686: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-i686: OK
linux-3.6.11-x86_64: OK
linux-3.7.10-i686: OK
linux-3.7.10-x86_64: OK
linux-3.8.13-i686: OK
linux-3.8.13-x86_64: OK
linux-3.9.11-i686: OK
linux-3.9.11-x86_64: 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.56-i686: OK
linux-3.16.56-x86_64: OK
linux-3.17.8-i686: ERRORS
linux-3.17.8-x86_64: OK
linux-3.18.102-i686: ERRORS
linux-3.18.102-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.51-i686: OK
linux-4.1.51-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.109-i686: OK
linux-4.4.109-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.91-i686: OK
linux-4.9.91-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.42-i686: OK
linux-4.14.42-x86_64: OK
linux-4.15.14-i686: OK
linux-4.15.14-x86_64: OK
linux-4.16.8-i686: OK
linux-4.16.8-x86_64: OK
linux-4.17.2-i686: OK
linux-4.17.2-x86_64: OK
linux-4.18-rc1-i686: OK
linux-4.18-rc1-x86_64: OK
apps: OK
spec-git: OK

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 20/22] [media] tvp5150: Add input port connectors DT bindings

2018-07-03 Thread Rob Herring
On Thu, Jun 28, 2018 at 06:20:52PM +0200, Marco Felsch wrote:
> The TVP5150/1 decoders support different video input sources to their
> AIP1A/B pins.
> 
> Possible configurations are as follows:
>   - Analog Composite signal connected to AIP1A.
>   - Analog Composite signal connected to AIP1B.
>   - Analog S-Video Y (luminance) and C (chrominance)
> signals connected to AIP1A and AIP1B respectively.
> 
> This patch extends the device tree bindings documentation to describe
> how the input connectors for these devices should be defined in a DT.
> 
> Signed-off-by: Marco Felsch 
> ---
>  .../devicetree/bindings/media/i2c/tvp5150.txt | 118 +-
>  1 file changed, 113 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt 
> b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
> index 8c0fc1a26bf0..feed8c911c5e 100644
> --- a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
> +++ b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
> @@ -12,11 +12,23 @@ Optional Properties:
>  - pdn-gpios: phandle for the GPIO connected to the PDN pin, if any.
>  - reset-gpios: phandle for the GPIO connected to the RESETB pin, if any.
>  
> -The device node must contain one 'port' child node for its digital output
> -video port, in accordance with the video interface bindings defined in
> -Documentation/devicetree/bindings/media/video-interfaces.txt.
> +The device node must contain one 'port' child node per device input and 
> output
> +port, in accordance with the video interface bindings defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes
> +are numbered as follows
>  
> -Required Endpoint Properties for parallel synchronization:
> +   Name  TypePort
> + --
> +   AIP1A sink0
> +   AIP1B sink1
> +   S-VIDEO   sink2
> +   Y-OUT src 3
> +
> +The device node must contain at least the Y-OUT port. Each input port must be
> +linked to an endpoint defined in
> +Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt.
> +
> +Required Endpoint Properties for parallel synchronization on output port:
>  
>  - hsync-active: active state of the HSYNC signal. Must be <1> (HIGH).
>  - vsync-active: active state of the VSYNC signal. Must be <1> (HIGH).
> @@ -26,7 +38,9 @@ Required Endpoint Properties for parallel synchronization:
>  If none of hsync-active, vsync-active and field-even-active is specified,
>  the endpoint is assumed to use embedded BT.656 synchronization.
>  
> -Example:
> +Examples:
> +
> +Only Output:
>  
>   {
>   ...
> @@ -37,6 +51,100 @@ Example:
>   reset-gpios = < 7 GPIO_ACTIVE_LOW>;
>  
>   port {
> + reg = <3>;
> + tvp5150_1: endpoint {
> + remote-endpoint = <_ep>;
> + };
> + };
> + };
> +};
> +
> +One Input:
> +
> +connector@0 {

Drop the unit-address as there is no reg property.

> + compatible = "composite-video-connector";
> + label = "Composite0";
> +
> + port {
> + comp0_out: endpoint {
> + remote-endpoint = <_comp0_in>;
> + };
> + };
> +};
> +
> + {
> + ...
> + tvp5150@5c {
> + compatible = "ti,tvp5150";
> + reg = <0x5c>;
> + pdn-gpios = < 30 GPIO_ACTIVE_LOW>;
> + reset-gpios = < 7 GPIO_ACTIVE_LOW>;
> +
> + port@0 {
> + reg = <0>;
> + tvp5150_comp0_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@3 {
> + reg = <3>;
> + tvp5150_1: endpoint {
> + remote-endpoint = <_ep>;
> + };
> + };
> + };
> +};
> +
> +
> +Two Inputs, different connector 12 on input AIP1A:
> +
> +connector@1 {

ditto

> + compatible = "svideo-connector";
> + label = "S-Video";
> +
> + port {
> + svideo_out: endpoint {
> + remote-endpoint = <_svideo_in>;
> + };
> + };
> +};
> +
> +connector@12 {

ditto

> + compatible = "composite-video-connector";
> + label = "Composite12";
> +
> + port {
> + comp12_out: endpoint {
> + remote-endpoint = <_comp12_in>;
> + };
> + };
> +};
> +
> + {
> + ...
> + tvp5150@5c {
> + compatible = "ti,tvp5150";
> + reg = <0x5c>;
> + pdn-gpios = < 30 GPIO_ACTIVE_LOW>;
> + reset-gpios = < 7 GPIO_ACTIVE_LOW>;
> +
> + port@0 {
> + reg = <0>;
> + tvp5150_comp12_in: endpoint {
> + 

Re: [PATCH 18/22] partial revert of "[media] tvp5150: add HW input connectors support"

2018-07-03 Thread Rob Herring
On Thu, Jun 28, 2018 at 06:20:50PM +0200, Marco Felsch wrote:
> From: Javier Martinez Canillas 
> 
> Commit f7b4b54e6364 ("[media] tvp5150: add HW input connectors support")
> added input signals support for the tvp5150, but the approach was found
> to be incorrect so the corresponding DT binding commit 82c2ffeb217a
> ("[media] tvp5150: document input connectors DT bindings") was reverted.
> 
> This left the driver with an undocumented (and wrong) DT parsing logic,
> so lets get rid of this code as well until the input connectors support
> is implemented properly.
> 
> It's a partial revert due other patches added on top of mentioned commit
> not allowing the commit to be reverted cleanly anymore. But all the code
> related to the DT parsing logic and input entities creation are removed.
> 
> Suggested-by: Laurent Pinchart 
> Signed-off-by: Javier Martinez Canillas 
> Acked-by: Laurent Pinchart 
> [m.fel...@pengutronix.de: rm TVP5150_INPUT_NUM define]
> Signed-off-by: Marco Felsch 
> ---
>  drivers/media/i2c/tvp5150.c | 141 

>  include/dt-bindings/media/tvp5150.h |   2 -

Acked-by: Rob Herring 

>  2 files changed, 143 deletions(-)


Re: [PATCH v7 1/2] media: ov2680: dt: Add bindings for OV2680

2018-07-03 Thread Rob Herring
On Tue, Jul 03, 2018 at 03:08:02PM +0100, Rui Miguel Silva wrote:
> Add device tree binding documentation for the OV2680 camera sensor.
> 
> CC: devicet...@vger.kernel.org
> Signed-off-by: Rui Miguel Silva 
> ---
>  .../devicetree/bindings/media/i2c/ov2680.txt  | 46 +++
>  1 file changed, 46 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2680.txt

Please add acks/reviews when posting new versions.

Rob


Re: [PATCHv15 29/35] Documentation: v4l: document request API

2018-07-03 Thread Hans Verkuil
On 03/07/18 16:08, Mauro Carvalho Chehab wrote:
> Em Tue, 3 Jul 2018 15:02:05 +0200
> Hans Verkuil  escreveu:
> 
>> On 03/07/18 13:50, Mauro Carvalho Chehab wrote:
>>> Em Mon,  4 Jun 2018 13:46:42 +0200
>>> Hans Verkuil  escreveu:
>>>   
 From: Alexandre Courbot 

 Document the request API for V4L2 devices, and amend the documentation
 of system calls influenced by it.  
>>>
>>> I'm starting reviewing the patch series from this patch, as it defines
>>> how the request API is supposed to work. Some of my comments below may
>>> reflect on code changes, in order for the core (and drivers) to be
>>> compliant with the uAPI specified here.
>>>
>>> So, I prefer to discuss first the contents of this patch, before start
>>> reviewing the remaining patches.
>>>   

 Signed-off-by: Alexandre Courbot 
 Signed-off-by: Hans Verkuil 
 ---
  .../media/uapi/mediactl/media-controller.rst  |   1 +
  .../media/uapi/mediactl/media-funcs.rst   |   3 +
  .../uapi/mediactl/media-ioc-request-alloc.rst |  71 ++
  .../uapi/mediactl/media-request-ioc-queue.rst |  50 
  .../mediactl/media-request-ioc-reinit.rst |  51 
  .../media/uapi/mediactl/request-api.rst   | 219 ++
  Documentation/media/uapi/v4l/buffer.rst   |  18 +-
  .../media/uapi/v4l/vidioc-g-ext-ctrls.rst |  28 ++-
  Documentation/media/uapi/v4l/vidioc-qbuf.rst  |  11 +
  .../media/videodev2.h.rst.exceptions  |   1 +
  10 files changed, 447 insertions(+), 6 deletions(-)
  create mode 100644 
 Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
  create mode 100644 
 Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
  create mode 100644 
 Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst
  create mode 100644 Documentation/media/uapi/mediactl/request-api.rst

 diff --git a/Documentation/media/uapi/mediactl/media-controller.rst 
 b/Documentation/media/uapi/mediactl/media-controller.rst
 index 0eea4f9a07d5..66aff38cd499 100644
 --- a/Documentation/media/uapi/mediactl/media-controller.rst
 +++ b/Documentation/media/uapi/mediactl/media-controller.rst
 @@ -21,6 +21,7 @@ Part IV - Media Controller API
  media-controller-intro
  media-controller-model
  media-types
 +request-api
  media-funcs
  media-header
  
 diff --git a/Documentation/media/uapi/mediactl/media-funcs.rst 
 b/Documentation/media/uapi/mediactl/media-funcs.rst
 index 076856501cdb..f4da9b3e17ec 100644
 --- a/Documentation/media/uapi/mediactl/media-funcs.rst
 +++ b/Documentation/media/uapi/mediactl/media-funcs.rst
 @@ -16,3 +16,6 @@ Function Reference
  media-ioc-enum-entities
  media-ioc-enum-links
  media-ioc-setup-link
 +media-ioc-request-alloc
 +media-request-ioc-queue
 +media-request-ioc-reinit
 diff --git a/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst 
 b/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
 new file mode 100644
 index ..d45a94c9e23c
 --- /dev/null
 +++ b/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
 @@ -0,0 +1,71 @@
 +.. SPDX-License-Identifier: GPL-2.0-only
 +
 +.. _media_ioc_request_alloc:
 +
 +*
 +ioctl MEDIA_IOC_REQUEST_ALLOC
 +*
 +
 +Name
 +
 +
 +MEDIA_IOC_REQUEST_ALLOC - Allocate a request
 +
 +
 +Synopsis
 +
 +
 +.. c:function:: int ioctl( int fd, MEDIA_IOC_REQUEST_ALLOC, struct 
 media_request_alloc *argp )
 +:name: MEDIA_IOC_REQUEST_ALLOC
 +
 +
 +Arguments
 +=
 +
 +``fd``
 +File descriptor returned by :ref:`open() `.
 +
 +``argp``
 +
 +
 +Description
 +===
 +
 +If the media device supports :ref:`requests `, then
 +this ioctl can be used to allocate a request.   
>>>
>>> Perhaps we should mention that otherwise it would set errno to ENOTTY.  
>>
>> Will add.
>>
>>>   
 A request is accessed through
 +a file descriptor that is returned in struct 
 :c:type:`media_request_alloc`.
 +
 +If the request was successfully allocated, then the request file 
 descriptor
 +can be passed to :ref:`ioctl VIDIOC_QBUF `,
 +:ref:`ioctl VIDIOC_G_EXT_CTRLS `,
 +:ref:`ioctl VIDIOC_S_EXT_CTRLS ` and
 +:ref:`ioctl VIDIOC_TRY_EXT_CTRLS `.
 +
 +In addition, the request can be queued by calling
 +:ref:`MEDIA_REQUEST_IOC_QUEUE` and re-initialized by calling
 +:ref:`MEDIA_REQUEST_IOC_REINIT`.
 +
 +Finally, the file descriptor can be polled to wait for the request to
 +complete.
 +
 +To free the request the file descriptor has to be closed.  
>>>
>>> Hmm... I don't think this is clear 

Re: [PATCHv15 29/35] Documentation: v4l: document request API

2018-07-03 Thread Mauro Carvalho Chehab
Em Tue, 3 Jul 2018 15:02:05 +0200
Hans Verkuil  escreveu:

> On 03/07/18 13:50, Mauro Carvalho Chehab wrote:
> > Em Mon,  4 Jun 2018 13:46:42 +0200
> > Hans Verkuil  escreveu:
> >   
> >> From: Alexandre Courbot 
> >>
> >> Document the request API for V4L2 devices, and amend the documentation
> >> of system calls influenced by it.  
> > 
> > I'm starting reviewing the patch series from this patch, as it defines
> > how the request API is supposed to work. Some of my comments below may
> > reflect on code changes, in order for the core (and drivers) to be
> > compliant with the uAPI specified here.
> > 
> > So, I prefer to discuss first the contents of this patch, before start
> > reviewing the remaining patches.
> >   
> >>
> >> Signed-off-by: Alexandre Courbot 
> >> Signed-off-by: Hans Verkuil 
> >> ---
> >>  .../media/uapi/mediactl/media-controller.rst  |   1 +
> >>  .../media/uapi/mediactl/media-funcs.rst   |   3 +
> >>  .../uapi/mediactl/media-ioc-request-alloc.rst |  71 ++
> >>  .../uapi/mediactl/media-request-ioc-queue.rst |  50 
> >>  .../mediactl/media-request-ioc-reinit.rst |  51 
> >>  .../media/uapi/mediactl/request-api.rst   | 219 ++
> >>  Documentation/media/uapi/v4l/buffer.rst   |  18 +-
> >>  .../media/uapi/v4l/vidioc-g-ext-ctrls.rst |  28 ++-
> >>  Documentation/media/uapi/v4l/vidioc-qbuf.rst  |  11 +
> >>  .../media/videodev2.h.rst.exceptions  |   1 +
> >>  10 files changed, 447 insertions(+), 6 deletions(-)
> >>  create mode 100644 
> >> Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
> >>  create mode 100644 
> >> Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
> >>  create mode 100644 
> >> Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst
> >>  create mode 100644 Documentation/media/uapi/mediactl/request-api.rst
> >>
> >> diff --git a/Documentation/media/uapi/mediactl/media-controller.rst 
> >> b/Documentation/media/uapi/mediactl/media-controller.rst
> >> index 0eea4f9a07d5..66aff38cd499 100644
> >> --- a/Documentation/media/uapi/mediactl/media-controller.rst
> >> +++ b/Documentation/media/uapi/mediactl/media-controller.rst
> >> @@ -21,6 +21,7 @@ Part IV - Media Controller API
> >>  media-controller-intro
> >>  media-controller-model
> >>  media-types
> >> +request-api
> >>  media-funcs
> >>  media-header
> >>  
> >> diff --git a/Documentation/media/uapi/mediactl/media-funcs.rst 
> >> b/Documentation/media/uapi/mediactl/media-funcs.rst
> >> index 076856501cdb..f4da9b3e17ec 100644
> >> --- a/Documentation/media/uapi/mediactl/media-funcs.rst
> >> +++ b/Documentation/media/uapi/mediactl/media-funcs.rst
> >> @@ -16,3 +16,6 @@ Function Reference
> >>  media-ioc-enum-entities
> >>  media-ioc-enum-links
> >>  media-ioc-setup-link
> >> +media-ioc-request-alloc
> >> +media-request-ioc-queue
> >> +media-request-ioc-reinit
> >> diff --git a/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst 
> >> b/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
> >> new file mode 100644
> >> index ..d45a94c9e23c
> >> --- /dev/null
> >> +++ b/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
> >> @@ -0,0 +1,71 @@
> >> +.. SPDX-License-Identifier: GPL-2.0-only
> >> +
> >> +.. _media_ioc_request_alloc:
> >> +
> >> +*
> >> +ioctl MEDIA_IOC_REQUEST_ALLOC
> >> +*
> >> +
> >> +Name
> >> +
> >> +
> >> +MEDIA_IOC_REQUEST_ALLOC - Allocate a request
> >> +
> >> +
> >> +Synopsis
> >> +
> >> +
> >> +.. c:function:: int ioctl( int fd, MEDIA_IOC_REQUEST_ALLOC, struct 
> >> media_request_alloc *argp )
> >> +:name: MEDIA_IOC_REQUEST_ALLOC
> >> +
> >> +
> >> +Arguments
> >> +=
> >> +
> >> +``fd``
> >> +File descriptor returned by :ref:`open() `.
> >> +
> >> +``argp``
> >> +
> >> +
> >> +Description
> >> +===
> >> +
> >> +If the media device supports :ref:`requests `, then
> >> +this ioctl can be used to allocate a request.   
> > 
> > Perhaps we should mention that otherwise it would set errno to ENOTTY.  
> 
> Will add.
> 
> >   
> >> A request is accessed through
> >> +a file descriptor that is returned in struct 
> >> :c:type:`media_request_alloc`.
> >> +
> >> +If the request was successfully allocated, then the request file 
> >> descriptor
> >> +can be passed to :ref:`ioctl VIDIOC_QBUF `,
> >> +:ref:`ioctl VIDIOC_G_EXT_CTRLS `,
> >> +:ref:`ioctl VIDIOC_S_EXT_CTRLS ` and
> >> +:ref:`ioctl VIDIOC_TRY_EXT_CTRLS `.
> >> +
> >> +In addition, the request can be queued by calling
> >> +:ref:`MEDIA_REQUEST_IOC_QUEUE` and re-initialized by calling
> >> +:ref:`MEDIA_REQUEST_IOC_REINIT`.
> >> +
> >> +Finally, the file descriptor can be polled to wait for the request to
> >> +complete.
> >> +
> >> +To free the request the file descriptor has to be closed.  
> > 
> > Hmm... I don't think this is clear enough. After reading this paragraph,
> > I came back 

[PATCH v7 2/2] media: ov2680: Add Omnivision OV2680 sensor driver

2018-07-03 Thread Rui Miguel Silva
This patch adds V4L2 sub-device driver for OV2680 image sensor.
The OV2680 is a 1/5" CMOS color sensor from Omnivision.
Supports output format: 10-bit Raw RGB.
The OV2680 has a single lane MIPI interface.

The driver exposes following V4L2 controls:
- auto/manual exposure,
- exposure,
- auto/manual gain,
- gain,
- horizontal/vertical flip,
- test pattern menu.
Supported resolution are only: QUXGA, 720P, UXGA.

Signed-off-by: Rui Miguel Silva 
---
 drivers/media/i2c/Kconfig  |   12 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov2680.c | 1186 
 3 files changed, 1199 insertions(+)
 create mode 100644 drivers/media/i2c/ov2680.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 541f0d28afd8..3a815825ad1b 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -606,6 +606,18 @@ config VIDEO_OV2659
  To compile this driver as a module, choose M here: the
  module will be called ov2659.
 
+config VIDEO_OV2680
+   tristate "OmniVision OV2680 sensor support"
+   depends on VIDEO_V4L2 && I2C && MEDIA_CONTROLLER
+   depends on MEDIA_CAMERA_SUPPORT
+   select V4L2_FWNODE
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV2680 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov2680.
+
 config VIDEO_OV2685
tristate "OmniVision OV2685 sensor support"
depends on VIDEO_V4L2 && I2C && MEDIA_CONTROLLER
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index ea34aee1a85a..9539c0855e63 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_VIDEO_SONY_BTF_MPX) += sony-btf-mpx.o
 obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
 obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
 obj-$(CONFIG_VIDEO_OV2640) += ov2640.o
+obj-$(CONFIG_VIDEO_OV2680) += ov2680.o
 obj-$(CONFIG_VIDEO_OV2685) += ov2685.o
 obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
 obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
diff --git a/drivers/media/i2c/ov2680.c b/drivers/media/i2c/ov2680.c
new file mode 100644
index ..f753a1c333ef
--- /dev/null
+++ b/drivers/media/i2c/ov2680.c
@@ -0,0 +1,1186 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Omnivision OV2680 CMOS Image Sensor driver
+ *
+ * Copyright (C) 2018 Linaro Ltd
+ *
+ * Based on OV5640 Sensor Driver
+ * Copyright (C) 2011-2013 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright (C) 2014-2017 Mentor Graphics Inc.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define OV2680_XVCLK_VALUE 2400
+
+#define OV2680_CHIP_ID 0x2680
+
+#define OV2680_REG_STREAM_CTRL 0x0100
+#define OV2680_REG_SOFT_RESET  0x0103
+
+#define OV2680_REG_CHIP_ID_HIGH0x300a
+#define OV2680_REG_CHIP_ID_LOW 0x300b
+
+#define OV2680_REG_R_MANUAL0x3503
+#define OV2680_REG_GAIN_PK 0x350a
+#define OV2680_REG_EXPOSURE_PK_HIGH0x3500
+#define OV2680_REG_TIMING_HTS  0x380c
+#define OV2680_REG_TIMING_VTS  0x380e
+#define OV2680_REG_FORMAT1 0x3820
+#define OV2680_REG_FORMAT2 0x3821
+
+#define OV2680_REG_ISP_CTRL00  0x5080
+
+#define OV2680_FRAME_RATE  30
+
+#define OV2680_REG_VALUE_8BIT  1
+#define OV2680_REG_VALUE_16BIT 2
+#define OV2680_REG_VALUE_24BIT 3
+
+#define OV2680_WIDTH_MAX   1600
+#define OV2680_HEIGHT_MAX  1200
+
+enum ov2680_mode_id {
+   OV2680_MODE_QUXGA_800_600,
+   OV2680_MODE_720P_1280_720,
+   OV2680_MODE_UXGA_1600_1200,
+   OV2680_MODE_MAX,
+};
+
+struct reg_value {
+   u16 reg_addr;
+   u8 val;
+};
+
+static const char * const ov2680_supply_name[] = {
+   "DOVDD",
+   "DVDD",
+   "AVDD",
+};
+
+#define OV2680_NUM_SUPPLIES ARRAY_SIZE(ov2680_supply_name)
+
+struct ov2680_mode_info {
+   const char *name;
+   enum ov2680_mode_id id;
+   u32 width;
+   u32 height;
+   const struct reg_value *reg_data;
+   u32 reg_data_size;
+};
+
+struct ov2680_ctrls {
+   struct v4l2_ctrl_handler handler;
+   struct {
+   struct v4l2_ctrl *auto_exp;
+   struct v4l2_ctrl *exposure;
+   };
+   struct {
+   struct v4l2_ctrl *auto_gain;
+   struct v4l2_ctrl *gain;
+   };
+
+   struct v4l2_ctrl *hflip;
+   struct v4l2_ctrl *vflip;
+   struct v4l2_ctrl *test_pattern;
+};
+
+struct ov2680_dev {
+   struct i2c_client   *i2c_client;
+   struct v4l2_subdev  sd;
+
+   struct media_padpad;
+   struct clk  *xvclk;
+   u32 xvclk_freq;
+   struct regulator_bulk_data  supplies[OV2680_NUM_SUPPLIES];
+
+ 

[PATCH v7 1/2] media: ov2680: dt: Add bindings for OV2680

2018-07-03 Thread Rui Miguel Silva
Add device tree binding documentation for the OV2680 camera sensor.

CC: devicet...@vger.kernel.org
Signed-off-by: Rui Miguel Silva 
---
 .../devicetree/bindings/media/i2c/ov2680.txt  | 46 +++
 1 file changed, 46 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2680.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/ov2680.txt 
b/Documentation/devicetree/bindings/media/i2c/ov2680.txt
new file mode 100644
index ..11e925ed9dad
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov2680.txt
@@ -0,0 +1,46 @@
+* Omnivision OV2680 MIPI CSI-2 sensor
+
+Required Properties:
+- compatible: should be "ovti,ov2680".
+- clocks: reference to the xvclk input clock.
+- clock-names: should be "xvclk".
+- DOVDD-supply: Digital I/O voltage supply.
+- DVDD-supply: Digital core voltage supply.
+- AVDD-supply: Analog voltage supply.
+
+Optional Properties:
+- reset-gpios: reference to the GPIO connected to the powerdown/reset pin,
+   if any. This is an active low signal to the OV2680.
+
+The device node must contain one 'port' child node for its digital output
+video port, and this port must have a single endpoint in accordance with
+ the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Endpoint node required properties for CSI-2 connection are:
+- remote-endpoint: a phandle to the bus receiver's endpoint node.
+- clock-lanes: should be set to <0> (clock lane on hardware lane 0).
+- data-lanes: should be set to <1> (one CSI-2 lane supported).
+
+Example:
+
+ {
+   ov2680: camera-sensor@36 {
+   compatible = "ovti,ov2680";
+   reg = <0x36>;
+   clocks = <>;
+   clock-names = "xvclk";
+   reset-gpios = < 3 GPIO_ACTIVE_LOW>;
+   DOVDD-supply = <_reg>;
+   DVDD-supply = <_reg>;
+   AVDD-supply = <_peri_3p15v>;
+
+   port {
+   ov2680_to_mipi: endpoint {
+   remote-endpoint = <_from_sensor>;
+   clock-lanes = <0>;
+   data-lanes = <1>;
+   };
+   };
+   };
+};
-- 
2.18.0



[PATCH v7 0/2] media: Introduce Omnivision OV2680 driver

2018-07-03 Thread Rui Miguel Silva
Add driver and bindings for the OV2680 2 megapixel CMOS 1/5" sensor, which has
a single MIPI lane interface and output format of 10-bit Raw RGB.

Features supported are described in PATCH 2/2.

v7->v6:
Fixes for compilation:
- compilation fixes when SUBDEV_API is not enabled
v5->v6:
Fabio Estevam:
- add power supplies (code and bindings)
- fix csi gpio polarity (code and bindings)
- rename powerdown to reset gpio

- Removed Rob Herring Reviewed-by tag, since bindings have changed since his
  ack.

v4->v5:
Fixes for v4l2-compliance tests:
- add init_cfg
- add some input arguments validations
- fix format_try set

v3->v4:
Sakari Ailus:
   - remove auto_{exposure|gain}_enable and direct call the set functions
   - add separe control sets to gain and exposure
   - fix number of controls allocated
   - check the exact frequency that it is supported

v2->v3:
Rob Herring:
- add Reviewed-by tag to dts PATCH 1/1

Sakari Ailus:
- align register values with bracket
- redone the {write|read}_reg i2c functions
- add bayer order handling with flip and mirror controls
- fix error path in probe release resources
- remove i2c_device_id and use probe_new

Myself:
- remove ; at the end of macros

v1->v2:
Fabio Estevam:
- s/OV5640/OV2680 in PATCH 1/2 changelog

Sakari Ailus:
- add description on endpoint properties in bindings
- add single endpoint in bindings
- drop OF dependency
- cleanup includes
- fix case in Color Bars
- remove frame rate selection
- 8/16/24 bit register access in the same transaction
- merge _reset and _soft_reset to _enable and rename it to power_on
- _gain_set use only the gain value (drop & 0x7ff)
- _gain_get remove the (0x377)
- single write/read at _exposure_set/get use write_reg24/read_reg24
- move mode_set_direct to _mode_set
- _mode_set set auto exposure/gain based on ctrl value
- s_frame_interval equal to g_frame_interval
- use closest match from: v4l: common: Add a function to obtain best size 
from a list
- check v4l2_ctrl_new_std return in _init

- fix gain manual value in auto_cluster

Cheers,
Rui


Rui Miguel Silva (2):
  media: ov2680: dt: Add bindings for OV2680
  media: ov2680: Add Omnivision OV2680 sensor driver

 .../devicetree/bindings/media/i2c/ov2680.txt  |   46 +
 drivers/media/i2c/Kconfig |   12 +
 drivers/media/i2c/Makefile|1 +
 drivers/media/i2c/ov2680.c| 1186 +
 4 files changed, 1245 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2680.txt
 create mode 100644 drivers/media/i2c/ov2680.c

-- 
2.18.0



[PATCH 1/1] smiapp: Set correct MODULE_LICENSE

2018-07-03 Thread Sakari Ailus
The smiapp driver is licensed under GNU GPL v2 only, as stated by the
header. Reflect this in the MODULE_LICENSE macro.

Signed-off-by: Sakari Ailus 
---
 drivers/media/i2c/smiapp/smiapp-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index e9e0f21efc2a..f2daad49ff18 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -3187,4 +3187,4 @@ module_i2c_driver(smiapp_i2c_driver);
 
 MODULE_AUTHOR("Sakari Ailus ");
 MODULE_DESCRIPTION("Generic SMIA/SMIA++ camera module driver");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
-- 
2.11.0



Re: [PATCH 2/4] dma-buf: lock the reservation object during (un)map_dma_buf v2

2018-07-03 Thread Christian König

Am 03.07.2018 um 14:52 schrieb Daniel Vetter:

On Tue, Jul 03, 2018 at 01:46:44PM +0200, Christian König wrote:

Am 25.06.2018 um 11:12 schrieb Daniel Vetter:

On Mon, Jun 25, 2018 at 10:22:31AM +0200, Daniel Vetter wrote:

On Fri, Jun 22, 2018 at 04:11:01PM +0200, Christian König wrote:

First step towards unpinned DMA buf operation.

I've checked the DRM drivers to potential locking of the reservation
object, but essentially we need to audit all implementations of the
dma_buf _ops for this to work.

v2: reordered

Signed-off-by: Christian König 

Reviewed-by: Daniel Vetter 

Ok I did review drivers a bit, but apparently not well enough by far. i915
CI is unhappy:

https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9400/fi-whl-u/igt@gem_mmap_...@basic-small-bo-tiledx.html

So yeah inserting that lock in there isn't the most trivial thing :-/

I kinda assume that other drivers will have similar issues, e.g. omapdrm's
use of dev->struct_mutex also very much looks like it'll result in a new
locking inversion.

Ah, crap. Already feared that this wouldn't be easy, but yeah that it is as
bad as this is rather disappointing.

Thanks for the info, going to keep thinking about how to solve those issues.

Side note: We want to make sure that drivers don't get the reservation_obj
locking hierarchy wrong in other places (using dev->struct_mutex is kinda
a pre-existing mis-use that we can't wish away retroactively
unfortunately). One really important thing is that shrinker vs resv_obj
must work with trylocks in the shrinker, so that you can allocate memory
while holding reservation objects.

One neat trick to teach lockdep about this would be to have a dummy

if (IS_ENABLED(CONFIG_PROVE_LOCKING)) {
ww_mutex_lock(dma_buf->resv_obj);
fs_reclaim_acquire(GFP_KERNEL);
fs_reclaim_release(GFP_KERNEL);
ww_mutex_unlock(dma_buf->resv_obj);
}

in dma_buf_init(). We're using the fs_reclaim_acquire/release check very
successfully to improve our igt test coverage for i915.ko in other areas.

Totally unrelated to dev->struct_mutex, but thoughts? Well for
dev->struct_mutex we could at least decide on one true way to nest
resv_obj vs. dev->struct_mutex as maybe an interim step, but not sure how
much that would help.


I don't think that would help. As far as I can see we only have two choices:

1. Either have a big patch which fixes all DMA-buf implementations to 
allow the reservation lock to be held during map/unmap (unrealistic).


2. Add a flag to at least in the mid term tell the DMA-buf helper 
functions what to do. E.g. create the mapping without the reservation 
lock held.



How about moving the SGL caching from the DRM layer into the DMA-buf 
layer and add a flag if the exporter wants/needs this caching?


Then only the implementations which can deal with dynamic invalidation 
disable SGL caching and with it enable creating the sgl with the 
reservation object locked.


This way we can kill two birds with one stone by both avoiding the SGL 
caching in the DRM layer as well as having a sane handling for the locking.


Thoughts?

Christian.



-Daniel




Re: [PATCHv15 29/35] Documentation: v4l: document request API

2018-07-03 Thread Hans Verkuil
On 03/07/18 13:50, Mauro Carvalho Chehab wrote:
> Em Mon,  4 Jun 2018 13:46:42 +0200
> Hans Verkuil  escreveu:
> 
>> From: Alexandre Courbot 
>>
>> Document the request API for V4L2 devices, and amend the documentation
>> of system calls influenced by it.
> 
> I'm starting reviewing the patch series from this patch, as it defines
> how the request API is supposed to work. Some of my comments below may
> reflect on code changes, in order for the core (and drivers) to be
> compliant with the uAPI specified here.
> 
> So, I prefer to discuss first the contents of this patch, before start
> reviewing the remaining patches.
> 
>>
>> Signed-off-by: Alexandre Courbot 
>> Signed-off-by: Hans Verkuil 
>> ---
>>  .../media/uapi/mediactl/media-controller.rst  |   1 +
>>  .../media/uapi/mediactl/media-funcs.rst   |   3 +
>>  .../uapi/mediactl/media-ioc-request-alloc.rst |  71 ++
>>  .../uapi/mediactl/media-request-ioc-queue.rst |  50 
>>  .../mediactl/media-request-ioc-reinit.rst |  51 
>>  .../media/uapi/mediactl/request-api.rst   | 219 ++
>>  Documentation/media/uapi/v4l/buffer.rst   |  18 +-
>>  .../media/uapi/v4l/vidioc-g-ext-ctrls.rst |  28 ++-
>>  Documentation/media/uapi/v4l/vidioc-qbuf.rst  |  11 +
>>  .../media/videodev2.h.rst.exceptions  |   1 +
>>  10 files changed, 447 insertions(+), 6 deletions(-)
>>  create mode 100644 
>> Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
>>  create mode 100644 
>> Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
>>  create mode 100644 
>> Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst
>>  create mode 100644 Documentation/media/uapi/mediactl/request-api.rst
>>
>> diff --git a/Documentation/media/uapi/mediactl/media-controller.rst 
>> b/Documentation/media/uapi/mediactl/media-controller.rst
>> index 0eea4f9a07d5..66aff38cd499 100644
>> --- a/Documentation/media/uapi/mediactl/media-controller.rst
>> +++ b/Documentation/media/uapi/mediactl/media-controller.rst
>> @@ -21,6 +21,7 @@ Part IV - Media Controller API
>>  media-controller-intro
>>  media-controller-model
>>  media-types
>> +request-api
>>  media-funcs
>>  media-header
>>  
>> diff --git a/Documentation/media/uapi/mediactl/media-funcs.rst 
>> b/Documentation/media/uapi/mediactl/media-funcs.rst
>> index 076856501cdb..f4da9b3e17ec 100644
>> --- a/Documentation/media/uapi/mediactl/media-funcs.rst
>> +++ b/Documentation/media/uapi/mediactl/media-funcs.rst
>> @@ -16,3 +16,6 @@ Function Reference
>>  media-ioc-enum-entities
>>  media-ioc-enum-links
>>  media-ioc-setup-link
>> +media-ioc-request-alloc
>> +media-request-ioc-queue
>> +media-request-ioc-reinit
>> diff --git a/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst 
>> b/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
>> new file mode 100644
>> index ..d45a94c9e23c
>> --- /dev/null
>> +++ b/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
>> @@ -0,0 +1,71 @@
>> +.. SPDX-License-Identifier: GPL-2.0-only
>> +
>> +.. _media_ioc_request_alloc:
>> +
>> +*
>> +ioctl MEDIA_IOC_REQUEST_ALLOC
>> +*
>> +
>> +Name
>> +
>> +
>> +MEDIA_IOC_REQUEST_ALLOC - Allocate a request
>> +
>> +
>> +Synopsis
>> +
>> +
>> +.. c:function:: int ioctl( int fd, MEDIA_IOC_REQUEST_ALLOC, struct 
>> media_request_alloc *argp )
>> +:name: MEDIA_IOC_REQUEST_ALLOC
>> +
>> +
>> +Arguments
>> +=
>> +
>> +``fd``
>> +File descriptor returned by :ref:`open() `.
>> +
>> +``argp``
>> +
>> +
>> +Description
>> +===
>> +
>> +If the media device supports :ref:`requests `, then
>> +this ioctl can be used to allocate a request. 
> 
> Perhaps we should mention that otherwise it would set errno to ENOTTY.

Will add.

> 
>> A request is accessed through
>> +a file descriptor that is returned in struct :c:type:`media_request_alloc`.
>> +
>> +If the request was successfully allocated, then the request file descriptor
>> +can be passed to :ref:`ioctl VIDIOC_QBUF `,
>> +:ref:`ioctl VIDIOC_G_EXT_CTRLS `,
>> +:ref:`ioctl VIDIOC_S_EXT_CTRLS ` and
>> +:ref:`ioctl VIDIOC_TRY_EXT_CTRLS `.
>> +
>> +In addition, the request can be queued by calling
>> +:ref:`MEDIA_REQUEST_IOC_QUEUE` and re-initialized by calling
>> +:ref:`MEDIA_REQUEST_IOC_REINIT`.
>> +
>> +Finally, the file descriptor can be polled to wait for the request to
>> +complete.
>> +
>> +To free the request the file descriptor has to be closed.
> 
> Hmm... I don't think this is clear enough. After reading this paragraph,
> I came back to patch 1, in order to see what's the ioctl to be called
> to free the request, only to notice that there's none.
> 
> So, I guess what you wanted to say, instead, is that:
> 
> "A request will remain allocated until the associated file descriptor is
>  closed by ::c:func:`close() ` and after the Kernel stops
>  using the request."

That's a lot 

Re: [PATCHv15 29/35] Documentation: v4l: document request API

2018-07-03 Thread Mauro Carvalho Chehab
Em Mon,  4 Jun 2018 13:46:42 +0200
Hans Verkuil  escreveu:

> From: Alexandre Courbot 
> 
> Document the request API for V4L2 devices, and amend the documentation
> of system calls influenced by it.

I'm starting reviewing the patch series from this patch, as it defines
how the request API is supposed to work. Some of my comments below may
reflect on code changes, in order for the core (and drivers) to be
compliant with the uAPI specified here.

So, I prefer to discuss first the contents of this patch, before start
reviewing the remaining patches.

> 
> Signed-off-by: Alexandre Courbot 
> Signed-off-by: Hans Verkuil 
> ---
>  .../media/uapi/mediactl/media-controller.rst  |   1 +
>  .../media/uapi/mediactl/media-funcs.rst   |   3 +
>  .../uapi/mediactl/media-ioc-request-alloc.rst |  71 ++
>  .../uapi/mediactl/media-request-ioc-queue.rst |  50 
>  .../mediactl/media-request-ioc-reinit.rst |  51 
>  .../media/uapi/mediactl/request-api.rst   | 219 ++
>  Documentation/media/uapi/v4l/buffer.rst   |  18 +-
>  .../media/uapi/v4l/vidioc-g-ext-ctrls.rst |  28 ++-
>  Documentation/media/uapi/v4l/vidioc-qbuf.rst  |  11 +
>  .../media/videodev2.h.rst.exceptions  |   1 +
>  10 files changed, 447 insertions(+), 6 deletions(-)
>  create mode 100644 
> Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
>  create mode 100644 
> Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
>  create mode 100644 
> Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst
>  create mode 100644 Documentation/media/uapi/mediactl/request-api.rst
> 
> diff --git a/Documentation/media/uapi/mediactl/media-controller.rst 
> b/Documentation/media/uapi/mediactl/media-controller.rst
> index 0eea4f9a07d5..66aff38cd499 100644
> --- a/Documentation/media/uapi/mediactl/media-controller.rst
> +++ b/Documentation/media/uapi/mediactl/media-controller.rst
> @@ -21,6 +21,7 @@ Part IV - Media Controller API
>  media-controller-intro
>  media-controller-model
>  media-types
> +request-api
>  media-funcs
>  media-header
>  
> diff --git a/Documentation/media/uapi/mediactl/media-funcs.rst 
> b/Documentation/media/uapi/mediactl/media-funcs.rst
> index 076856501cdb..f4da9b3e17ec 100644
> --- a/Documentation/media/uapi/mediactl/media-funcs.rst
> +++ b/Documentation/media/uapi/mediactl/media-funcs.rst
> @@ -16,3 +16,6 @@ Function Reference
>  media-ioc-enum-entities
>  media-ioc-enum-links
>  media-ioc-setup-link
> +media-ioc-request-alloc
> +media-request-ioc-queue
> +media-request-ioc-reinit
> diff --git a/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst 
> b/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
> new file mode 100644
> index ..d45a94c9e23c
> --- /dev/null
> +++ b/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
> @@ -0,0 +1,71 @@
> +.. SPDX-License-Identifier: GPL-2.0-only
> +
> +.. _media_ioc_request_alloc:
> +
> +*
> +ioctl MEDIA_IOC_REQUEST_ALLOC
> +*
> +
> +Name
> +
> +
> +MEDIA_IOC_REQUEST_ALLOC - Allocate a request
> +
> +
> +Synopsis
> +
> +
> +.. c:function:: int ioctl( int fd, MEDIA_IOC_REQUEST_ALLOC, struct 
> media_request_alloc *argp )
> +:name: MEDIA_IOC_REQUEST_ALLOC
> +
> +
> +Arguments
> +=
> +
> +``fd``
> +File descriptor returned by :ref:`open() `.
> +
> +``argp``
> +
> +
> +Description
> +===
> +
> +If the media device supports :ref:`requests `, then
> +this ioctl can be used to allocate a request. 

Perhaps we should mention that otherwise it would set errno to ENOTTY.

> A request is accessed through
> +a file descriptor that is returned in struct :c:type:`media_request_alloc`.
> +
> +If the request was successfully allocated, then the request file descriptor
> +can be passed to :ref:`ioctl VIDIOC_QBUF `,
> +:ref:`ioctl VIDIOC_G_EXT_CTRLS `,
> +:ref:`ioctl VIDIOC_S_EXT_CTRLS ` and
> +:ref:`ioctl VIDIOC_TRY_EXT_CTRLS `.
> +
> +In addition, the request can be queued by calling
> +:ref:`MEDIA_REQUEST_IOC_QUEUE` and re-initialized by calling
> +:ref:`MEDIA_REQUEST_IOC_REINIT`.
> +
> +Finally, the file descriptor can be polled to wait for the request to
> +complete.
> +
> +To free the request the file descriptor has to be closed.

Hmm... I don't think this is clear enough. After reading this paragraph,
I came back to patch 1, in order to see what's the ioctl to be called
to free the request, only to notice that there's none.

So, I guess what you wanted to say, instead, is that:

"A request will remain allocated until the associated file descriptor is
 closed by ::c:func:`close() ` and after the Kernel stops
 using the request."

(see below for a discussion about the close() reference)

> +
> +.. c:type:: media_request_alloc
> +
> +.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
> +
> +.. flat-table:: struct media_request_alloc
> +:header-rows:  0
> +

[RFC PATCH 3/4] vicodec: add the FWHT software codec

2018-07-03 Thread Hans Verkuil
From: Hans Verkuil 

Add a software codec based on the Fast Walsh Hadamard Transform.

Signed-off-by: Tom aan de Wiel 
Signed-off-by: Hans Verkuil 
---
 .../media/platform/vicodec/vicodec-codec.c| 743 ++
 .../media/platform/vicodec/vicodec-codec.h|  71 ++
 2 files changed, 814 insertions(+)
 create mode 100644 drivers/media/platform/vicodec/vicodec-codec.c
 create mode 100644 drivers/media/platform/vicodec/vicodec-codec.h

diff --git a/drivers/media/platform/vicodec/vicodec-codec.c 
b/drivers/media/platform/vicodec/vicodec-codec.c
new file mode 100644
index ..6f9334338555
--- /dev/null
+++ b/drivers/media/platform/vicodec/vicodec-codec.c
@@ -0,0 +1,743 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2016 Tom aan de Wiel
+ * Copyright 2018 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ */
+
+#include 
+#include "vicodec-codec.h"
+
+#define ALL_ZEROS 15
+#define DEADZONE_WIDTH 20
+
+static const uint8_t zigzag[64] = {
+   0,
+   1,  8,
+   2,  9, 16,
+   3, 10, 17, 24,
+   4, 11, 18, 25, 32,
+   5, 12, 19, 26, 33, 40,
+   6, 13, 20, 27, 34, 41, 48,
+   7, 14, 21, 28, 35, 42, 49, 56,
+   15, 22, 29, 36, 43, 50, 57,
+   23, 30, 37, 44, 51, 58,
+   31, 38, 45, 52, 59,
+   39, 46, 53, 60,
+   47, 54, 61,
+   55, 62,
+   63,
+};
+
+
+static int rlc(s16 *in, s16 *output, int blocktype)
+{
+   s16 block[8 * 8];
+   s16 *wp = block;
+   int i = 0;
+   int x, y;
+   int ret = 0;
+
+   /* read in block from framebuffer */
+   int lastzero_run = 0;
+   int to_encode;
+
+   for (y = 0; y < 8; y++) {
+   for (x = 0; x < 8; x++) {
+   *wp = in[x + y * 8];
+   wp++;
+   }
+   }
+
+   /* keep track of amount of trailing zeros */
+   for (i = 63; i >= 0 && !block[zigzag[i]]; i--)
+   lastzero_run++;
+
+   *output++ = (blocktype == PBLOCK ? (s16)htons(PFRAME_BIT) : 0);
+   ret++;
+
+   to_encode = 8 * 8 - (lastzero_run > 14 ? lastzero_run : 0);
+
+   i = 0;
+   while (i < to_encode) {
+   int cnt = 0;
+   int tmp;
+
+   /* count leading zeros */
+   while ((tmp = block[zigzag[i]]) == 0 && cnt < 14) {
+   cnt++;
+   i++;
+   if (i == to_encode) {
+   cnt--;
+   break;
+   }
+   }
+   /* 4 bits for run, 12 for coefficient (quantization by 4) */
+   *output++ = htons((cnt | tmp << 4));
+   i++;
+   ret++;
+   }
+   if (lastzero_run > 14) {
+   *output = htons(ALL_ZEROS | 0);
+   ret++;
+   }
+
+   return ret;
+}
+
+/*
+ * This function will worst-case increase rlc_in by 65*2 bytes:
+ * one s16 value for the header and 8 * 8 coefficients of type s16.
+ */
+static s16 derlc(s16 **rlc_in, s16 *dwht_out)
+{
+   /* header */
+   s16 *input = *rlc_in;
+   s16 ret = ntohs(*input++);
+   int dec_count = 0;
+   s16 block[8 * 8 + 16];
+   s16 *wp = block;
+   int i;
+
+   /*
+* Now de-compress, it expands one byte to up to 15 bytes
+* (or fills the remainder of the 64 bytes with zeroes if it
+* is the last byte to expand).
+*
+* So block has to be 8 * 8 + 16 bytes, the '+ 16' is to
+* allow for overflow if the incoming data was malformed.
+*/
+   while (dec_count < 8 * 8) {
+   s16 in = ntohs(*input++);
+   int length = in & 0xf;
+   int coeff = in >> 4;
+
+   /* fill remainder with zeros */
+   if (length == 15) {
+   for (i = 0; i < 64 - dec_count; i++)
+   *wp++ = 0;
+   break;
+   }
+
+   for (i = 0; i < length; i++)
+   *wp++ = 0;
+   *wp++ = coeff;
+   dec_count += length + 1;
+   }
+
+   wp = block;
+
+   for (i = 0; i < 64; i++) {
+   int pos = zigzag[i];
+   int y = pos / 8;
+   int x = pos % 8;
+
+   dwht_out[x + y * 8] = *wp++;
+   }
+   *rlc_in = input;
+   return ret;
+}
+
+static const int quant_table[] = {
+   2, 2, 2, 2, 2, 2,  2,  2,
+   2, 2, 2, 2, 2, 2,  2,  2,
+   2, 2, 2, 2, 2, 2,  2,  3,
+   2, 2, 2, 2, 2, 2,  3,  6,
+   2, 2, 2, 2, 2, 3,  6,  6,
+   2, 2, 2, 2, 3, 6,  6,  6,
+   2, 2, 2, 3, 6, 6,  6,  6,
+   2, 2, 3, 6, 6, 6,  6,  8,
+};
+
+static const int quant_table_p[] = {
+   3, 3, 3, 3, 3, 3,  3,  3,
+   3, 3, 3, 3, 3, 3,  3,  3,
+   3, 3, 3, 3, 3, 3,  3,  3,
+   3, 3, 3, 3, 3, 3,  3,  6,
+   3, 3, 3, 3, 3, 3,  6,  6,
+   3, 3, 3, 3, 3, 6,  6,  9,
+   

[RFC PATCH 4/4] vicodec: add the virtual codec driver

2018-07-03 Thread Hans Verkuil
From: Hans Verkuil 

Add the virtual codec driver that uses the Fast Walsh Hadamard Transform.

Signed-off-by: Hans Verkuil 
---
 MAINTAINERS   |8 +
 drivers/media/platform/Kconfig|3 +
 drivers/media/platform/Makefile   |1 +
 drivers/media/platform/vicodec/Kconfig|   12 +
 drivers/media/platform/vicodec/Makefile   |4 +
 drivers/media/platform/vicodec/vicodec-core.c | 1167 +
 6 files changed, 1195 insertions(+)
 create mode 100644 drivers/media/platform/vicodec/Kconfig
 create mode 100644 drivers/media/platform/vicodec/Makefile
 create mode 100644 drivers/media/platform/vicodec/vicodec-core.c

diff --git a/MAINTAINERS b/MAINTAINERS
index bd147aee7f80..c57437e69f9e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15145,6 +15145,14 @@ L: net...@vger.kernel.org
 S: Maintained
 F: drivers/net/ethernet/via/via-velocity.*
 
+VICODEC VIRTUAL CODEC DRIVER
+M: Hans Verkuil 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: https://linuxtv.org
+S: Maintained
+F: drivers/media/platform/vicodec/*
+
 VIDEO MULTIPLEXER DRIVER
 M: Philipp Zabel 
 L: linux-media@vger.kernel.org
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 210b44a457eb..3e456aaa99d8 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -514,6 +514,9 @@ config VIDEO_VIM2M
---help---
  This is a virtual test device for the memory-to-memory driver
  framework.
+
+source "drivers/media/platform/vicodec/Kconfig"
+
 endif #V4L_TEST_DRIVERS
 
 menuconfig DVB_PLATFORM_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 04bc1502a30e..8e5f88eb7559 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_VIDEO_VIU) += fsl-viu.o
 obj-$(CONFIG_VIDEO_VIMC)   += vimc/
 obj-$(CONFIG_VIDEO_VIVID)  += vivid/
 obj-$(CONFIG_VIDEO_VIM2M)  += vim2m.o
+obj-$(CONFIG_VIDEO_VICODEC)+= vicodec/
 
 obj-$(CONFIG_VIDEO_TI_VPE) += ti-vpe/
 
diff --git a/drivers/media/platform/vicodec/Kconfig 
b/drivers/media/platform/vicodec/Kconfig
new file mode 100644
index ..767338f48b3f
--- /dev/null
+++ b/drivers/media/platform/vicodec/Kconfig
@@ -0,0 +1,12 @@
+config VIDEO_VICODEC
+   tristate "Virtual Codec Driver"
+   depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   select VIDEOBUF2_VMALLOC
+   default n
+   help
+ Driver for a Virtual Codec
+
+ This driver can be compared to the vim2m driver for emulating
+ a video device node that exposes an emulated hardware codec.
+
+ When in doubt, say N.
diff --git a/drivers/media/platform/vicodec/Makefile 
b/drivers/media/platform/vicodec/Makefile
new file mode 100644
index ..197229428953
--- /dev/null
+++ b/drivers/media/platform/vicodec/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+vicodec-objs := vicodec-core.o vicodec-codec.o
+
+obj-$(CONFIG_VIDEO_VICODEC) += vicodec.o
diff --git a/drivers/media/platform/vicodec/vicodec-core.c 
b/drivers/media/platform/vicodec/vicodec-core.c
new file mode 100644
index ..476f5fbb879d
--- /dev/null
+++ b/drivers/media/platform/vicodec/vicodec-core.c
@@ -0,0 +1,1167 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * A virtual codec example device.
+ *
+ * Copyright 2018 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This is a virtual codec device driver for testing the codec framework.
+ * It simulates a device that uses memory buffers for both source and
+ * destination and encodes or decodes the data.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vicodec-codec.h"
+
+MODULE_DESCRIPTION("Virtual codec device");
+MODULE_AUTHOR("Hans Verkuil ");
+MODULE_LICENSE("GPL v2");
+
+static unsigned int debug;
+module_param(debug, uint, 0644);
+MODULE_PARM_DESC(debug, "activates debug info");
+
+#define VICODEC_NAME   "vicodec"
+#define MAX_WIDTH  4096U
+#define MIN_WIDTH  640U
+#define MAX_HEIGHT 2160U
+#define MIN_HEIGHT 480U
+
+#define dprintk(dev, fmt, arg...) \
+   v4l2_dbg(1, debug, >v4l2_dev, "%s: " fmt, __func__, ## arg)
+
+
+static void vicodec_dev_release(struct device *dev)
+{
+}
+
+static struct platform_device vicodec_pdev = {
+   .name   = VICODEC_NAME,
+   .dev.release= vicodec_dev_release,
+};
+
+/* Per-queue, driver-specific private data */
+struct vicodec_q_data {
+   unsigned intwidth;
+   unsigned intheight;
+   unsigned intsizeimage;
+   unsigned intsequence;
+   u32 fourcc;
+};
+

[RFC PATCH 0/4] vicodec driver

2018-07-03 Thread Hans Verkuil
From: Hans Verkuil 

This is the first RFC version of the new vicodec driver, a driver that
emulates a HW codec.

This patch series sits on top of this pull request:

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

since it needs the new m2m helpers to set up the MC topology.

The software codec was developed two years ago by Tom aan de Wiel
as a university project for this specific purpose but it took
until now to turn it into a proper driver. Many thanks to Tom for
creating this codec based on the patent-free Fast Walsh Hadamard
Transform.

The goal is to make this a reference driver for stateful codecs,
and in the near future also for stateless codecs.

This is an early version of this driver and there are several
things that need to be done:

- make it conform to the codec API (currently in the process
  of being documented by Tomasz Figa).
- create proper encoder/decoder functions for actual encoder/
  decoder entities (currently I'm abusing the scaler entity function).
- only tested for 1280x720 resolutions. I suspect I'm missing some
  code to have it work correctly for other resolutions, although
  it advertises anything from VGA to 4096x2160.
- the new V4L2_PIX_FMT_FWHT fourcc needs to be documented.
- later: add support for resolution changes while encoding or
  decoding.
- others?

Anyway, as long as you stick to 720p it works quite nicely.
It supports YUV420 (default), YVU420, NV12 and NV21 raw formats.

To encode:

v4l2-ctl --stream-mmap --stream-out-mmap --stream-to-hdr out.comp --stream-from 
in.yuv

To encode from an nv12 raw file:

v4l2-ctl -v pixelformat=NV12 --stream-mmap --stream-out-mmap --stream-to-hdr 
out.comp --stream-from in.nv12

You can leave out the --stream-from option, in that case the built-in test
pattern generator is used to generate the raw frames.

To decode:

v4l2-ctl -d1 --stream-mmap --stream-out-mmap --stream-from-hdr out.comp 
--stream-to out.yuv

To decode to an nv12 raw file:

v4l2-ctl -x pixelformat=NV12 -d1 --stream-mmap --stream-out-mmap 
--stream-from-hdr out.comp --stream-to out.yuv

Note: this requires the latest v4l-utils code.

The --stream-from/to-hdr options expect a header in front of each compressed
frame that contains the size of that frame. Normally sizeimage is used, but
that doesn't work for compressed frames, so I made these new options.

If you have some 720p mkv/mp4/whatever file that you want to test vicodec
with, then you can extract a raw YUV420 file from it as follows:

ffmpeg -i test.mkv -c:v rawvideo -frames 150 -pix_fmt yuv420p in.yuv

That command extracts the first 150 frames from the mkv.

To play back the result from the decoder use:

mplayer -demuxer rawvideo -rawvideo format=i420:w=1280:h=720:fps=25 out.yuv

Feedback is welcome!

Regards,

Hans

Hans Verkuil (4):
  videodev.h: add PIX_FMT_FWHT for use with vicodec
  v4l2-mem2mem: add v4l2_m2m_last_buf()
  vicodec: add the FWHT software codec
  vicodec: add the virtual codec driver

 MAINTAINERS   |8 +
 drivers/media/platform/Kconfig|3 +
 drivers/media/platform/Makefile   |1 +
 drivers/media/platform/vicodec/Kconfig|   12 +
 drivers/media/platform/vicodec/Makefile   |4 +
 .../media/platform/vicodec/vicodec-codec.c|  743 +++
 .../media/platform/vicodec/vicodec-codec.h|   71 +
 drivers/media/platform/vicodec/vicodec-core.c | 1167 +
 drivers/media/v4l2-core/v4l2-ioctl.c  |1 +
 drivers/media/v4l2-core/v4l2-mem2mem.c|   18 +
 include/media/v4l2-mem2mem.h  |   29 +
 include/uapi/linux/videodev2.h|1 +
 12 files changed, 2058 insertions(+)
 create mode 100644 drivers/media/platform/vicodec/Kconfig
 create mode 100644 drivers/media/platform/vicodec/Makefile
 create mode 100644 drivers/media/platform/vicodec/vicodec-codec.c
 create mode 100644 drivers/media/platform/vicodec/vicodec-codec.h
 create mode 100644 drivers/media/platform/vicodec/vicodec-core.c

-- 
2.18.0



[RFC PATCH 2/4] v4l2-mem2mem: add v4l2_m2m_last_buf()

2018-07-03 Thread Hans Verkuil
From: Hans Verkuil 

This can be used to mark the last queued source buffer as the last
buffer.

Signed-off-by: Hans Verkuil 
---
 drivers/media/v4l2-core/v4l2-mem2mem.c | 18 
 include/media/v4l2-mem2mem.h   | 29 ++
 2 files changed, 47 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c 
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 725da74d15d8..3b5b610665f3 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -129,6 +129,24 @@ void *v4l2_m2m_next_buf(struct v4l2_m2m_queue_ctx *q_ctx)
 }
 EXPORT_SYMBOL_GPL(v4l2_m2m_next_buf);
 
+void *v4l2_m2m_last_buf(struct v4l2_m2m_queue_ctx *q_ctx)
+{
+   struct v4l2_m2m_buffer *b;
+   unsigned long flags;
+
+   spin_lock_irqsave(_ctx->rdy_spinlock, flags);
+
+   if (list_empty(_ctx->rdy_queue)) {
+   spin_unlock_irqrestore(_ctx->rdy_spinlock, flags);
+   return NULL;
+   }
+
+   b = list_last_entry(_ctx->rdy_queue, struct v4l2_m2m_buffer, list);
+   spin_unlock_irqrestore(_ctx->rdy_spinlock, flags);
+   return >vb;
+}
+EXPORT_SYMBOL_GPL(v4l2_m2m_last_buf);
+
 void *v4l2_m2m_buf_remove(struct v4l2_m2m_queue_ctx *q_ctx)
 {
struct v4l2_m2m_buffer *b;
diff --git a/include/media/v4l2-mem2mem.h b/include/media/v4l2-mem2mem.h
index af48b1eca025..bbf300c7b12c 100644
--- a/include/media/v4l2-mem2mem.h
+++ b/include/media/v4l2-mem2mem.h
@@ -449,6 +449,35 @@ static inline void *v4l2_m2m_next_dst_buf(struct 
v4l2_m2m_ctx *m2m_ctx)
return v4l2_m2m_next_buf(_ctx->cap_q_ctx);
 }
 
+/**
+ * v4l2_m2m_last_buf() - return last buffer from the list of ready buffers
+ *
+ * @q_ctx: pointer to struct @v4l2_m2m_queue_ctx
+ */
+void *v4l2_m2m_last_buf(struct v4l2_m2m_queue_ctx *q_ctx);
+
+/**
+ * v4l2_m2m_last_src_buf() - return last destination buffer from the list of
+ * ready buffers
+ *
+ * @m2m_ctx: m2m context assigned to the instance given by struct _m2m_ctx
+ */
+static inline void *v4l2_m2m_last_src_buf(struct v4l2_m2m_ctx *m2m_ctx)
+{
+   return v4l2_m2m_last_buf(_ctx->out_q_ctx);
+}
+
+/**
+ * v4l2_m2m_last_dst_buf() - return last destination buffer from the list of
+ * ready buffers
+ *
+ * @m2m_ctx: m2m context assigned to the instance given by struct _m2m_ctx
+ */
+static inline void *v4l2_m2m_last_dst_buf(struct v4l2_m2m_ctx *m2m_ctx)
+{
+   return v4l2_m2m_last_buf(_ctx->cap_q_ctx);
+}
+
 /**
  * v4l2_m2m_for_each_dst_buf() - iterate over a list of destination ready
  * buffers
-- 
2.18.0



[RFC PATCH 1/4] videodev.h: add PIX_FMT_FWHT for use with vicodec

2018-07-03 Thread Hans Verkuil
From: Hans Verkuil 

Add a new pixelformat for the vicodec software codec using the
Fast Walsh Hadamard Transform.

Signed-off-by: Hans Verkuil 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
 include/uapi/linux/videodev2.h   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index eeed14468a17..8af24e6018f0 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1310,6 +1310,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_VP8:  descr = "VP8"; break;
case V4L2_PIX_FMT_VP9:  descr = "VP9"; break;
case V4L2_PIX_FMT_HEVC: descr = "HEVC"; break; /* aka 
H.265 */
+   case V4L2_PIX_FMT_FWHT: descr = "FWHT"; break; /* used 
in vicodec */
case V4L2_PIX_FMT_CPIA1:descr = "GSPCA CPiA YUV"; break;
case V4L2_PIX_FMT_WNVA: descr = "WNVA"; break;
case V4L2_PIX_FMT_SN9C10X:  descr = "GSPCA SN9C10X"; break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 600877be5c22..3ea8097c2470 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -636,6 +636,7 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_VP8  v4l2_fourcc('V', 'P', '8', '0') /* VP8 */
 #define V4L2_PIX_FMT_VP9  v4l2_fourcc('V', 'P', '9', '0') /* VP9 */
 #define V4L2_PIX_FMT_HEVC v4l2_fourcc('H', 'E', 'V', 'C') /* HEVC aka 
H.265 */
+#define V4L2_PIX_FMT_FWHT v4l2_fourcc('F', 'W', 'H', 'T') /* Fast Walsh 
Hadamard Transform (vicodec) */
 
 /*  Vendor-specific formats   */
 #define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */
-- 
2.18.0



Re: [PATCHv15 01/35] uapi/linux/media.h: add request API

2018-07-03 Thread Mauro Carvalho Chehab
Em Tue, 3 Jul 2018 11:33:13 +0200
Hans Verkuil  escreveu:

> On 03/07/18 11:21, Mauro Carvalho Chehab wrote:
> > Em Mon,  4 Jun 2018 13:46:14 +0200
> > Hans Verkuil  escreveu:
> >   
> >> From: Hans Verkuil 
> >>
> >> Define the public request API.
> >>
> >> This adds the new MEDIA_IOC_REQUEST_ALLOC ioctl to allocate a request
> >> and two ioctls that operate on a request in order to queue the
> >> contents of the request to the driver and to re-initialize the
> >> request.  
> > 
> > It would be better if you had added the documentation stuff here...
> > I can't review this patch without first reviewing the documentation
> > for the new ioctls...  
> 
> I moved patch 29 to the front for the next version.

Thanks! Be sure to move other documentation patches to be together
with the respective code changes. Reviewing a /35 patch series
is hard enough even without needing to review stuff on some
random order.

Thanks,
Mauro


Re: [PATCHv15 01/35] uapi/linux/media.h: add request API

2018-07-03 Thread Hans Verkuil
On 03/07/18 11:21, Mauro Carvalho Chehab wrote:
> Em Mon,  4 Jun 2018 13:46:14 +0200
> Hans Verkuil  escreveu:
> 
>> From: Hans Verkuil 
>>
>> Define the public request API.
>>
>> This adds the new MEDIA_IOC_REQUEST_ALLOC ioctl to allocate a request
>> and two ioctls that operate on a request in order to queue the
>> contents of the request to the driver and to re-initialize the
>> request.
> 
> It would be better if you had added the documentation stuff here...
> I can't review this patch without first reviewing the documentation
> for the new ioctls...

I moved patch 29 to the front for the next version.

Regards,

Hans


Re: [PATCHv15 01/35] uapi/linux/media.h: add request API

2018-07-03 Thread Mauro Carvalho Chehab
Em Mon,  4 Jun 2018 13:46:14 +0200
Hans Verkuil  escreveu:

> From: Hans Verkuil 
> 
> Define the public request API.
> 
> This adds the new MEDIA_IOC_REQUEST_ALLOC ioctl to allocate a request
> and two ioctls that operate on a request in order to queue the
> contents of the request to the driver and to re-initialize the
> request.

It would be better if you had added the documentation stuff here...
I can't review this patch without first reviewing the documentation
for the new ioctls...

> 
> Signed-off-by: Hans Verkuil 
> Acked-by: Sakari Ailus 
> Reviewed-by: Laurent Pinchart 
> ---
>  include/uapi/linux/media.h | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> index c7e9a5cba24e..0f0117742fa7 100644
> --- a/include/uapi/linux/media.h
> +++ b/include/uapi/linux/media.h
> @@ -342,11 +342,23 @@ struct media_v2_topology {
>  
>  /* ioctls */
>  
> +struct __attribute__ ((packed)) media_request_alloc {
> + __s32 fd;
> +};
> +
>  #define MEDIA_IOC_DEVICE_INFO_IOWR('|', 0x00, struct 
> media_device_info)
>  #define MEDIA_IOC_ENUM_ENTITIES  _IOWR('|', 0x01, struct 
> media_entity_desc)
>  #define MEDIA_IOC_ENUM_LINKS _IOWR('|', 0x02, struct media_links_enum)
>  #define MEDIA_IOC_SETUP_LINK _IOWR('|', 0x03, struct media_link_desc)
>  #define MEDIA_IOC_G_TOPOLOGY _IOWR('|', 0x04, struct media_v2_topology)
> +#define MEDIA_IOC_REQUEST_ALLOC  _IOWR('|', 0x05, struct 
> media_request_alloc)
> +
> +/*
> + * These ioctls are called on the request file descriptor as returned
> + * by MEDIA_IOC_REQUEST_ALLOC.
> + */
> +#define MEDIA_REQUEST_IOC_QUEUE  _IO('|',  0x80)
> +#define MEDIA_REQUEST_IOC_REINIT _IO('|',  0x81)
>  
>  #if !defined(__KERNEL__) || defined(__NEED_MEDIA_LEGACY_API)
>  



Thanks,
Mauro