Re: [RFC 0/4] Exynos DRM: add Picture Processor extension

[Tomasz Figa]

Hi Everyone,

On Wed, May 10, 2017 at 9:24 AM, Inki Dae  wrote:
>
>
> 2017년 04월 26일 07:21에 Sakari Ailus 이(가) 쓴 글:
>> Hi Marek,
>>
>> On Thu, Apr 20, 2017 at 01:23:09PM +0200, Marek Szyprowski wrote:
>>> Hi Laurent,
>>>
>>> On 2017-04-20 12:25, Laurent Pinchart wrote:
 Hi Marek,

 (CC'ing Sakari Ailus)

 Thank you for the patches.

 On Thursday 20 Apr 2017 11:13:36 Marek Szyprowski wrote:
> Dear all,
>
> This is an updated proposal for extending EXYNOS DRM API with generic
> support for hardware modules, which can be used for processing image data
 >from the one memory buffer to another. Typical memory-to-memory operations
> are: rotation, scaling, colour space conversion or mix of them. This is a
> follow-up of my previous proposal "[RFC 0/2] New feature: Framebuffer
> processors", which has been rejected as "not really needed in the DRM
> core":
> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg146286.html
>
> In this proposal I moved all the code to Exynos DRM driver, so now this
> will be specific only to Exynos DRM. I've also changed the name from
> framebuffer processor (fbproc) to picture processor (pp) to avoid 
> confusion
> with fbdev API.
>
> Here is a bit more information what picture processors are:
>
> Embedded SoCs are known to have a number of hardware blocks, which perform
> such operations. They can be used in paralel to the main GPU module to
> offload CPU from processing grapics or video data. One of example use of
> such modules is implementing video overlay, which usually requires color
> space conversion from NV12 (or similar) to RGB32 color space and scaling 
> to
> target window size.
>
> The proposed API is heavily inspired by atomic KMS approach - it is also
> based on DRM objects and their properties. A new DRM object is introduced:
> picture processor (called pp for convenience). Such objects have a set of
> standard DRM properties, which describes the operation to be performed by
> respective hardware module. In typical case those properties are a source
> fb id and rectangle (x, y, width, height) and destination fb id and
> rectangle. Optionally a rotation property can be also specified if
> supported by the given hardware. To perform an operation on image data,
> userspace provides a set of properties and their values for given fbproc
> object in a similar way as object and properties are provided for
> performing atomic page flip / mode setting.
>
> The proposed API consists of the 3 new ioctls:
> - DRM_IOCTL_EXYNOS_PP_GET_RESOURCES: to enumerate all available picture
>   processors,
> - DRM_IOCTL_EXYNOS_PP_GET: to query capabilities of given picture
>   processor,
> - DRM_IOCTL_EXYNOS_PP_COMMIT: to perform operation described by given
>   property set.
>
> The proposed API is extensible. Drivers can attach their own, custom
> properties to add support for more advanced picture processing (for 
> example
> blending).
>
> This proposal aims to replace Exynos DRM IPP (Image Post Processing)
> subsystem. IPP API is over-engineered in general, but not really 
> extensible
> on the other side. It is also buggy, with significant design flaws - the
> biggest issue is the fact that the API covers memory-2-memory picture
> operations together with CRTC writeback and duplicating features, which
> belongs to video plane. Comparing with IPP subsystem, the PP framework is
> smaller (1807 vs 778 lines) and allows driver simplification (Exynos
> rotator driver smaller by over 200 lines).
 This seems to be the kind of hardware that is typically supported by V4L2.
 Stupid question, why DRM ?
>>>
>>> Let me elaborate a bit on the reasons for implementing it in Exynos DRM:
>>>
>>> 1. we want to replace existing Exynos IPP subsystem:
>>>  - it is used only in some internal/vendor trees, not in open-source
>>>  - we want it to have sane and potentially extensible userspace API
>>>  - but we don't want to loose its functionality
>>>
>>> 2. we want to have simple API for performing single image processing
>>> operation:
>>>  - typically it will be used by compositing window manager, this means that
>>>some parameters of the processing might change on each vblank (like
>>>destination rectangle for example). This api allows such change on each
>>>operation without any additional cost. V4L2 requires to reinitialize
>>>queues with new configuration on such change, what means that a bunch of
>>>ioctls has to be called.
>>
>> What do you mean by re-initialising the queue? Format, buffers or something
>> else?
>>
>> If you need a larger buffer than what you have already allocated, you'll
>> need to re-allocate, V4L2 or not.
>>
>> We also do lack a way to destroy individual 

cron job: media_tree daily build: WARNINGS

[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 May 10 05:00:23 CEST 2017
media-tree git hash:3622d3e77ecef090b5111e3c5423313f11711dfa
media_build git hash:   ab988a3d089232ce9e1aec2f259e947c06983dbc
v4l-utils git hash: fba2bdde45aaf6b56608c3cf8b906d7e5ee0e21f
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: WARNINGS
linux-git-arm-davinci: WARNINGS
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: WARNINGS
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: WARNINGS
linux-3.12.67-i686: WARNINGS
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: WARNINGS
linux-4.9.26-i686: WARNINGS
linux-4.10.14-i686: WARNINGS
linux-4.11-i686: WARNINGS
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.12.67-x86_64: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9.26-x86_64: WARNINGS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.log

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [RFC 0/4] Exynos DRM: add Picture Processor extension

[Inki Dae]

2017년 04월 26일 07:21에 Sakari Ailus 이(가) 쓴 글:
> Hi Marek,
> 
> On Thu, Apr 20, 2017 at 01:23:09PM +0200, Marek Szyprowski wrote:
>> Hi Laurent,
>>
>> On 2017-04-20 12:25, Laurent Pinchart wrote:
>>> Hi Marek,
>>>
>>> (CC'ing Sakari Ailus)
>>>
>>> Thank you for the patches.
>>>
>>> On Thursday 20 Apr 2017 11:13:36 Marek Szyprowski wrote:
 Dear all,

 This is an updated proposal for extending EXYNOS DRM API with generic
 support for hardware modules, which can be used for processing image data
>>> >from the one memory buffer to another. Typical memory-to-memory operations
 are: rotation, scaling, colour space conversion or mix of them. This is a
 follow-up of my previous proposal "[RFC 0/2] New feature: Framebuffer
 processors", which has been rejected as "not really needed in the DRM
 core":
 http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg146286.html

 In this proposal I moved all the code to Exynos DRM driver, so now this
 will be specific only to Exynos DRM. I've also changed the name from
 framebuffer processor (fbproc) to picture processor (pp) to avoid confusion
 with fbdev API.

 Here is a bit more information what picture processors are:

 Embedded SoCs are known to have a number of hardware blocks, which perform
 such operations. They can be used in paralel to the main GPU module to
 offload CPU from processing grapics or video data. One of example use of
 such modules is implementing video overlay, which usually requires color
 space conversion from NV12 (or similar) to RGB32 color space and scaling to
 target window size.

 The proposed API is heavily inspired by atomic KMS approach - it is also
 based on DRM objects and their properties. A new DRM object is introduced:
 picture processor (called pp for convenience). Such objects have a set of
 standard DRM properties, which describes the operation to be performed by
 respective hardware module. In typical case those properties are a source
 fb id and rectangle (x, y, width, height) and destination fb id and
 rectangle. Optionally a rotation property can be also specified if
 supported by the given hardware. To perform an operation on image data,
 userspace provides a set of properties and their values for given fbproc
 object in a similar way as object and properties are provided for
 performing atomic page flip / mode setting.

 The proposed API consists of the 3 new ioctls:
 - DRM_IOCTL_EXYNOS_PP_GET_RESOURCES: to enumerate all available picture
   processors,
 - DRM_IOCTL_EXYNOS_PP_GET: to query capabilities of given picture
   processor,
 - DRM_IOCTL_EXYNOS_PP_COMMIT: to perform operation described by given
   property set.

 The proposed API is extensible. Drivers can attach their own, custom
 properties to add support for more advanced picture processing (for example
 blending).

 This proposal aims to replace Exynos DRM IPP (Image Post Processing)
 subsystem. IPP API is over-engineered in general, but not really extensible
 on the other side. It is also buggy, with significant design flaws - the
 biggest issue is the fact that the API covers memory-2-memory picture
 operations together with CRTC writeback and duplicating features, which
 belongs to video plane. Comparing with IPP subsystem, the PP framework is
 smaller (1807 vs 778 lines) and allows driver simplification (Exynos
 rotator driver smaller by over 200 lines).
>>> This seems to be the kind of hardware that is typically supported by V4L2.
>>> Stupid question, why DRM ?
>>
>> Let me elaborate a bit on the reasons for implementing it in Exynos DRM:
>>
>> 1. we want to replace existing Exynos IPP subsystem:
>>  - it is used only in some internal/vendor trees, not in open-source
>>  - we want it to have sane and potentially extensible userspace API
>>  - but we don't want to loose its functionality
>>
>> 2. we want to have simple API for performing single image processing
>> operation:
>>  - typically it will be used by compositing window manager, this means that
>>some parameters of the processing might change on each vblank (like
>>destination rectangle for example). This api allows such change on each
>>operation without any additional cost. V4L2 requires to reinitialize
>>queues with new configuration on such change, what means that a bunch of
>>ioctls has to be called.
> 
> What do you mean by re-initialising the queue? Format, buffers or something
> else?
> 
> If you need a larger buffer than what you have already allocated, you'll
> need to re-allocate, V4L2 or not.
> 
> We also do lack a way to destroy individual buffers in V4L2. It'd be up to
> implementing that and some work in videobuf2.
> 
> Another thing is that V4L2 is very stream oriented. For most devices that's
> fine as a lot of the parameters are not 

Re: [PATCH v5 3/7] media: i2c: max2175: Add MAX2175 support

[Sakari Ailus]

Hi Ramesh,

On Tue, May 09, 2017 at 02:37:34PM +0100, Ramesh Shanmugasundaram wrote:
> This patch adds driver support for the MAX2175 chip. This is Maxim
> Integrated's RF to Bits tuner front end chip designed for software-defined
> radio solutions. This driver exposes the tuner as a sub-device instance
> with standard and custom controls to configure the device.
> 
> Signed-off-by: Ramesh Shanmugasundaram 
> 
> ---
> v5:
>  - sck -> Sample clock is clarified in driver documentation (Hans)
>  - "refout-load-pF" is renamed to "refout-load" as per updated bindings.
> ---
>  Documentation/media/v4l-drivers/index.rst   |1 +
>  Documentation/media/v4l-drivers/max2175.rst |   60 ++
>  drivers/media/i2c/Kconfig   |4 +
>  drivers/media/i2c/Makefile  |2 +
>  drivers/media/i2c/max2175/Kconfig   |8 +
>  drivers/media/i2c/max2175/Makefile  |4 +
>  drivers/media/i2c/max2175/max2175.c | 1437 
> +++
>  drivers/media/i2c/max2175/max2175.h |  108 ++

If the driver consists of two files, I think it'd be reasonable to have it
directly under drivers/media/i2c rather than in its own directory.

>  8 files changed, 1624 insertions(+)
>  create mode 100644 Documentation/media/v4l-drivers/max2175.rst
>  create mode 100644 drivers/media/i2c/max2175/Kconfig
>  create mode 100644 drivers/media/i2c/max2175/Makefile
>  create mode 100644 drivers/media/i2c/max2175/max2175.c
>  create mode 100644 drivers/media/i2c/max2175/max2175.h
> 
> diff --git a/Documentation/media/v4l-drivers/index.rst 
> b/Documentation/media/v4l-drivers/index.rst
> index a606d1cdac13..d8cade53d496 100644
> --- a/Documentation/media/v4l-drivers/index.rst
> +++ b/Documentation/media/v4l-drivers/index.rst
> @@ -42,6 +42,7 @@ For more details see the file COPYING in the source 
> distribution of Linux.
>   davinci-vpbe
>   fimc
>   ivtv
> +max2175

Tabs, please!

>   meye
>   omap3isp
>   omap4_camera
> diff --git a/Documentation/media/v4l-drivers/max2175.rst 
> b/Documentation/media/v4l-drivers/max2175.rst
> new file mode 100644
> index ..94fb815f043b
> --- /dev/null
> +++ b/Documentation/media/v4l-drivers/max2175.rst
> @@ -0,0 +1,60 @@
> +Maxim Integrated MAX2175 RF to bits tuner driver
> +
> +
> +The MAX2175 driver implements the following driver-specific controls:
> +
> +``V4L2_CID_MAX2175_I2S_ENABLE``

You're documenting driver specific controls. Should you provide a header
under include/uapi/linux to make these usable for the user space?

> +---
> +Enable/Disable I2S output of the tuner.
> +
> +.. flat-table::
> +:header-rows:  0
> +:stub-columns: 0
> +:widths:   1 4
> +
> +* - ``(0)``
> +  - I2S output is disabled.
> +* - ``(1)``
> +  - I2S output is enabled.
> +
> +``V4L2_CID_MAX2175_HSLS``
> +-
> +The high-side/low-side (HSLS) control of the tuner for a given band.
> +
> +.. flat-table::
> +:header-rows:  0
> +:stub-columns: 0
> +:widths:   1 4
> +
> +* - ``(0)``
> +  - The LO frequency position is below the desired frequency.
> +* - ``(1)``
> +  - The LO frequency position is above the desired frequency.
> +
> +``V4L2_CID_MAX2175_RX_MODE (menu)``
> +---
> +The Rx mode controls a number of preset parameters of the tuner like
> +sample clock (sck), sampling rate etc. These multiple settings are
> +provided under one single label called Rx mode in the datasheet. The
> +list below shows the supported modes with a brief description.
> +
> +.. flat-table::
> +:header-rows:  0
> +:stub-columns: 0
> +:widths:   1 4
> +
> +* - ``"Europe modes"``
> +* - ``"FM 1.2" (0)``
> +  - This configures FM band with a sample rate of 0.512 million
> +samples/sec with a 10.24 MHz sck.
> +* - ``"DAB 1.2" (1)``
> +  - This configures VHF band with a sample rate of 2.048 million
> +samples/sec with a 32.768 MHz sck.
> +
> +* - ``"North America modes"``
> +* - ``"FM 1.0" (0)``
> +  - This configures FM band with a sample rate of 0.7441875 million
> +samples/sec with a 14.88375 MHz sck.
> +* - ``"DAB 1.2" (1)``
> +  - This configures FM band with a sample rate of 0.372 million
> +samples/sec with a 7.441875 MHz sck.
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index b358d1a40688..d9fc1311794f 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -785,6 +785,10 @@ config VIDEO_SAA6752HS
> To compile this driver as a module, choose M here: the
> module will be called saa6752hs.
>  
> +comment "SDR tuner chips"
> +
> +source "drivers/media/i2c/max2175/Kconfig"
> +
>  comment "Miscellaneous helper chips"
>  
>  config 

[PATCH] media: usb: au0828: remove dead code

[Gustavo A. R. Silva]

Local variable _ret_ is assigned to a constant value and it is never
updated again. Remove this variable and the dead code it guards.

Addresses-Coverity-ID: 112968
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/usb/au0828/au0828-video.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/media/usb/au0828/au0828-video.c 
b/drivers/media/usb/au0828/au0828-video.c
index 16f9125..abc80b0 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -809,16 +809,10 @@ static void au0828_analog_stream_reset(struct au0828_dev 
*dev)
  */
 static int au0828_stream_interrupt(struct au0828_dev *dev)
 {
-   int ret = 0;
-
dev->stream_state = STREAM_INTERRUPT;
if (test_bit(DEV_DISCONNECTED, >dev_state))
return -ENODEV;
-   else if (ret) {
-   set_bit(DEV_MISCONFIGURED, >dev_state);
-   dprintk(1, "%s device is misconfigured!\n", __func__);
-   return ret;
-   }
+
return 0;
 }
 
-- 
2.5.0

Re: [PATCH v5 2/7] dt-bindings: media: Add MAX2175 binding description

[Sakari Ailus]

Hi Ramesh,

On Tue, May 09, 2017 at 02:37:33PM +0100, Ramesh Shanmugasundaram wrote:
> Add device tree binding documentation for MAX2175 RF to bits tuner
> device.
> 
> Signed-off-by: Ramesh Shanmugasundaram 
> 
> Acked-by: Rob Herring 
> ---
> v5:
>  - pF in property-units.txt is renamed to pico-farads (Geert)
>  - "maxim,refout-load-pF" is renamed to "maxim,refout-load".
> ---
>  .../devicetree/bindings/media/i2c/max2175.txt  | 61 
> ++
>  .../devicetree/bindings/property-units.txt |  1 +
>  2 files changed, 62 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/max2175.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/max2175.txt 
> b/Documentation/devicetree/bindings/media/i2c/max2175.txt
> new file mode 100644
> index ..dce421857efe
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt
> @@ -0,0 +1,61 @@
> +Maxim Integrated MAX2175 RF to Bits tuner
> +-
> +
> +The MAX2175 IC is an advanced analog/digital hybrid-radio receiver with
> +RF to Bits® front-end designed for software-defined radio solutions.
> +
> +Required properties:
> +
> +- compatible: "maxim,max2175" for MAX2175 RF-to-bits tuner.
> +- clocks: phandle to the fixed xtal clock.

How about "clock specifier"

> +- clock-names: name of the fixed xtal clock, shall be "xtal".

If you have a single clock you could drop clock-names. You can obtain it
in the driver using  clk_get(dev, NULL) . Up to you.

> +- port: child port node corresponding to the I2S output, in accordance with
> + the video interface bindings defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt. The port
> + node must contain at least one endpoint.
> +
> +Optional properties:
> +
> +- maxim,master : phandle to the master tuner if it is a slave. 
> This
> + is used to define two tuners in diversity mode
> + (1 master, 1 slave). By default each tuner is an
> + individual master.
> +- maxim,refout-load   : load capacitance value (in pico-farads) on reference
> + output drive level. The possible load values are:
> +  0 (default - refout disabled)
> + 10
> + 20
> + 30
> + 40
> + 60
> + 70
> +- maxim,am-hiz-filter : empty property indicates the AM Hi-Z filter is used
> + in this hardware for AM antenna input.
> +
> +Example:
> +
> +
> +Board specific DTS file
> +
> +/* Fixed XTAL clock node */
> +maxim_xtal: clock {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <36864000>;
> +};
> +
> +/* A tuner device instance under i2c bus */
> +max2175_0: tuner@60 {
> + compatible = "maxim,max2175";
> + reg = <0x60>;
> + clocks = <_xtal>;
> + clock-names = "xtal";
> + maxim,refout-load = <10>;
> +
> + port {
> + max2175_0_ep: endpoint {
> + remote-endpoint = <_rx_device>;
> + };
> + };
> +
> +};
> diff --git a/Documentation/devicetree/bindings/property-units.txt 
> b/Documentation/devicetree/bindings/property-units.txt
> index 0849618a9df0..2d1d28843c96 100644
> --- a/Documentation/devicetree/bindings/property-units.txt
> +++ b/Documentation/devicetree/bindings/property-units.txt
> @@ -30,6 +30,7 @@ Electricity
>  -micro-ohms  : micro Ohms
>  -microwatt-hours: micro Watt-hours
>  -microvolt   : micro volts
> +-pico-farads : picofarads

Why pico-farads and not picofarads? Most of the existing definitions have
no dash. (Just wondering.)

-- 
Kind regards,

Sakari Ailus
sakari.ai...@linux.intel.com

Dearest

[mariawarlor...@ono.com]

Dearest ,

I am constrained to contact you because of the maltreatment which I am 
receiving from my step mother. She planned to take away all my late 
father's treasury and properties from me since the  unexpected death of 
my beloved Father ,my mother died 10years ago and I was left alone with 
my step mother to take care of me. Meanwhile I wanted to travel to 
Europe, but she hide  away my  international passport and other 
valuable documents.  Luckily she did not discover where I kept my 
father's File which contained very important documents . Now I am 
presently staying in the Refugee Mission Camp in Burkina Faso. I am 
seeking for long term relationship and investment assistance. My father 
of blessed memory deposited the sum of US$ 27.5 Million in one bank 
here in Burkina Faso with my name as the next of kin. I had contacted 
the Bank to clear the deposit but the Branch Manager told me that being 
a refugee, my status according to the local law does not authorize me 
to carry out the operation ,However, he advised me to provide a trustee 
who will stand on my behalf. I had wanted to inform my stepmother about 
this deposit but I am afraid that she will not offer me anything after 
the release of the money ,I will give you details in my next mail after 
receiving your acceptance mail to help me.

Best Regards
Miss. Maria Warlord I. Coulibaly 

Re: [PATCH] staging: media: cxd2099: Use __func__ macro in messages

[Jasmin J.]

Hi Alexandre!

The current cxd2099 driver is an old version. DD provides a newer variant.
Please see my patch series
  http://www.mail-archive.com/linux-media@vger.kernel.org/msg112410.html
Especially this patch
  http://www.mail-archive.com/linux-media@vger.kernel.org/msg112409.html
where I remove this useless printing already.

I kept the "slot_shutdown" print in my series, because it is useful and called
only if someone removes the CAM.

So I can agree with your first hunk.

BR,
   Jasmin

[PATCH v3 1/2] Revert "[media] v4l: vsp1: Supply frames to the DU continuously"

[Kieran Bingham]

This reverts commit 3299ba5c0b21 ("[media] v4l: vsp1: Supply frames to
the DU continuously")

The DU output mode does not rely on frames being supplied on the WPF as
its pipeline is supplied from DRM. For the upcoming WPF writeback
functionality, we will choose to enable writeback mode if there is an
output buffer, or disable it (leaving the existing display pipeline
unharmed) otherwise.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_video.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index eab3c3ea85d7..47b5c24043d7 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -304,11 +304,6 @@ static struct v4l2_rect vsp1_video_partition(struct 
vsp1_pipeline *pipe,
  * This function completes the current buffer by filling its sequence number,
  * time stamp and payload size, and hands it back to the videobuf core.
  *
- * When operating in DU output mode (deep pipeline to the DU through the LIF),
- * the VSP1 needs to constantly supply frames to the display. In that case, if
- * no other buffer is queued, reuse the one that has just been processed 
instead
- * of handing it back to the videobuf core.
- *
  * Return the next queued buffer or NULL if the queue is empty.
  */
 static struct vsp1_vb2_buffer *
@@ -330,12 +325,6 @@ vsp1_video_complete_buffer(struct vsp1_video *video)
done = list_first_entry(>irqqueue,
struct vsp1_vb2_buffer, queue);
 
-   /* In DU output mode reuse the buffer if the list is singular. */
-   if (pipe->lif && list_is_singular(>irqqueue)) {
-   spin_unlock_irqrestore(>irqlock, flags);
-   return done;
-   }
-
list_del(>queue);
 
if (!list_empty(>irqqueue))
-- 
git-series 0.9.1

[PATCH v3 0/2] vsp1 writeback prototype

[Kieran Bingham]

This short series extends the VSP1 on the RCar platforms to allow creating a
V4L2 video node on display pipelines where the hardware allows writing to
memory simultaneously.

In this instance, the hardware restricts the output to match the display size
(no rescaling) but does allow pixel format conversion.

A current limitation (that the DRI devs might have ideas about) is that the vb2
buffers are swapped on the atomic_flush() calls rather than on vsync events.

Ideally swapping buffers would occur on every vsync such that the output rate
of the video node would match the display rate, however the timing here proves
more difficult to synchronise the updates from a vsync and flush without adding
latency to the flush.

Is there anything I can do to synchronise the v4l2 buffers with the DRM/KMS
interfaces currently? Or does anyone have any suggestions for extending as
such?

And of course ideas on anything that could be done generically to support other
targets as well would be worth considering - though currently this
implementation is very RCar/VSP1 specific.

v3:
 - Rebased to v4.12-rc1

v2:
 - Fix checkpatch.pl warnings
 - Adapt to use a single source pad for the Writeback and LIF
 - Use WPF properties to determine when to create links instead of VSP
 - Remove incorrect vsp1_video_verify_format() changes
 - Spelling and grammar fixes

Kieran Bingham (2):
  Revert "[media] v4l: vsp1: Supply frames to the DU continuously"
  v4l: vsp1: Provide a writeback video device

Kieran Bingham (2):
  Revert "[media] v4l: vsp1: Supply frames to the DU continuously"
  v4l: vsp1: Provide a writeback video device

 drivers/media/platform/vsp1/vsp1.h   |   1 +-
 drivers/media/platform/vsp1/vsp1_drm.c   |  18 +++-
 drivers/media/platform/vsp1/vsp1_drv.c   |   5 +-
 drivers/media/platform/vsp1/vsp1_rwpf.h  |   1 +-
 drivers/media/platform/vsp1/vsp1_video.c | 161 ++--
 drivers/media/platform/vsp1/vsp1_video.h |   5 +-
 drivers/media/platform/vsp1/vsp1_wpf.c   |  19 ++-
 7 files changed, 192 insertions(+), 18 deletions(-)

base-commit: 13e0988140374123bead1dd27c287354cb95108e
-- 
git-series 0.9.1

[PATCH v3 2/2] v4l: vsp1: Provide a writeback video device

[Kieran Bingham]

When the VSP1 is used in an active display pipeline, the output of the
WPF can supply the LIF entity directly and simultaneously write to
memory.

Support this functionality in the VSP1 driver, by extending the WPF
source pads, and establishing a V4L2 video device node connected to the
new source.

The source will be able to perform pixel format conversion, but not
rescaling, and as such the output from the memory node will always be
of the same dimensions as the display output.

Signed-off-by: Kieran Bingham 

---
Changes since RFC
 - Fix checkpatch.pl warnings
 - Adapt to use a single source pad for the Writeback and LIF
 - Use WPF properties to determine when to create links instead of VSP
 - Remove incorrect vsp1_video_verify_format() changes
 - Spelling and grammar fixes

 - Rebased to v4.12-rc1
---
 drivers/media/platform/vsp1/vsp1.h   |   1 +-
 drivers/media/platform/vsp1/vsp1_drm.c   |  18 +++-
 drivers/media/platform/vsp1/vsp1_drv.c   |   5 +-
 drivers/media/platform/vsp1/vsp1_rwpf.h  |   1 +-
 drivers/media/platform/vsp1/vsp1_video.c | 150 +++-
 drivers/media/platform/vsp1/vsp1_video.h |   5 +-
 drivers/media/platform/vsp1/vsp1_wpf.c   |  19 ++-
 7 files changed, 192 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1.h 
b/drivers/media/platform/vsp1/vsp1.h
index 85387a64179a..a2d462264312 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -54,6 +54,7 @@ struct vsp1_uds;
 #define VSP1_HAS_WPF_HFLIP (1 << 6)
 #define VSP1_HAS_HGO   (1 << 7)
 #define VSP1_HAS_HGT   (1 << 8)
+#define VSP1_HAS_WPF_WRITEBACK (1 << 9)
 
 struct vsp1_device_info {
u32 version;
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 9d235e830f5a..539890b27864 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -25,6 +25,7 @@
 #include "vsp1_lif.h"
 #include "vsp1_pipe.h"
 #include "vsp1_rwpf.h"
+#include "vsp1_video.h"
 
 
 /* 
-
@@ -483,6 +484,13 @@ void vsp1_du_atomic_flush(struct device *dev)
__func__, rpf->entity.index);
}
 
+   /*
+* If we have a writeback node attached, we use this opportunity to
+* update the video buffers.
+*/
+   if (pipe->output->video && pipe->output->video->frame_end)
+   pipe->output->video->frame_end(pipe);
+
/* Configure all entities in the pipeline. */
list_for_each_entry(entity, >entities, list_pipe) {
/* Disconnect unused RPFs from the pipeline. */
@@ -572,6 +580,16 @@ int vsp1_drm_create_links(struct vsp1_device *vsp1)
if (ret < 0)
return ret;
 
+   if (vsp1->wpf[0]->has_writeback) {
+   /* Connect the video device to the WPF for Writeback support */
+   ret = media_create_pad_link(>wpf[0]->entity.subdev.entity,
+   RWPF_PAD_SOURCE,
+   >wpf[0]->video->video.entity,
+   0, flags);
+   if (ret < 0)
+   return ret;
+   }
+
return 0;
 }
 
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 048446af5ae7..240045e82cc2 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -411,7 +411,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
vsp1->wpf[i] = wpf;
list_add_tail(>entity.list_dev, >entities);
 
-   if (vsp1->info->uapi) {
+   if (vsp1->info->uapi || wpf->has_writeback) {
struct vsp1_video *video = vsp1_video_create(vsp1, wpf);
 
if (IS_ERR(video)) {
@@ -709,7 +709,8 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
.version = VI6_IP_VERSION_MODEL_VSPD_GEN3,
.model = "VSP2-D",
.gen = 3,
-   .features = VSP1_HAS_BRU | VSP1_HAS_LIF | VSP1_HAS_WPF_VFLIP,
+   .features = VSP1_HAS_BRU | VSP1_HAS_LIF | VSP1_HAS_WPF_VFLIP
+ | VSP1_HAS_WPF_WRITEBACK,
.rpf_count = 5,
.wpf_count = 2,
.num_bru_inputs = 5,
diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.h 
b/drivers/media/platform/vsp1/vsp1_rwpf.h
index 58215a7ab631..d26a92cd5c7d 100644
--- a/drivers/media/platform/vsp1/vsp1_rwpf.h
+++ b/drivers/media/platform/vsp1/vsp1_rwpf.h
@@ -53,6 +53,7 @@ struct vsp1_rwpf {
 
u32 mult_alpha;
u32 outfmt;
+   bool has_writeback;
 
struct {
spinlock_t lock;
diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index 

Re: [PATCH 1/4] v4l: vsp1: Implement partition algorithm restrictions

[Kieran Bingham]

Hi Laurent,

On 13/02/17 19:17, Laurent Pinchart wrote:
> Hi Kieran,
> 
> (CC'ing Morimoto-san)
> 
> Thank you for the patch.
> 
> On Friday 04 Nov 2016 18:19:27 Kieran Bingham wrote:
>> The partition algorithm introduced to support scaling, and rotation on
> 
> s/,// if I'm not mistaken.
> 
>> Gen3 hardware has some restrictions on pipeline configuration.
> 
> Strictly speaking this shouldn't be a limitation of the partition algorithm, 
> but a limitation of the Gen3 hardware. The limitations relate to image 
> partitioning as partitions are needed when using the UDS or SRU in a 
> pipeline, 
> but as far as I understand, that's the whole extent of the relationship 
> between the two.

How about swapping those two sentences over:

Gen3 hardware has some restrictions on pipeline configuration when using the
partition algorithm.


>> The UDS must not be connected after the SRU in a pipeline, and whilst an
>> SRU can be connected before the UDS, it can only do so in identity mode.
> 
> I assume you mean after instead of before.

Indeed - I'm rather contradicting myself in the above sentence otherwise :)


> I've tested the SRU-UDS and UDS-SRU pipelines with all combinations for 
> downscaling, identity and upscaling for the UDS and identity and upscaling 
> for 
> the UDS. On Gen2 everything works correctly.
> 
> On Gen3 the results are as follows:
> 
> Testing SRU-UDS scaling 768x576 - 768x576 - 640x480 in RGB24: fail
> Testing SRU-UDS scaling 768x576 - 768x576 - 768x576 in RGB24: pass
> Testing SRU-UDS scaling 768x576 - 768x576 - 1024x768 in RGB24: pass
> Testing SRU-UDS scaling 768x576 - 1536x1152 - 1280x960 in RGB24: pass
> Testing SRU-UDS scaling 768x576 - 1536x1152 - 1536x1152 in RGB24: pass
> Testing SRU-UDS scaling 768x576 - 1536x1152 - 2048x1536 in RGB24: pass
> Testing UDS-SRU scaling 768x576 - 640x480 - 640x480 in RGB24: pass
> Testing UDS-SRU scaling 768x576 - 640x480 - 1280x960 in RGB24: pass
> Testing UDS-SRU scaling 768x576 - 768x576 - 768x576 in RGB24: pass
> Testing UDS-SRU scaling 768x576 - 768x576 - 1536x1152 in RGB24: pass
> Testing UDS-SRU scaling 768x576 - 1024x768 - 1024x768 in RGB24: pass
> Testing UDS-SRU scaling 768x576 - 1024x768 - 2048x1536 in RGB24: pass
> Testing SRU-UDS scaling 768x576 - 768x576 - 640x480 in YUV444M: fail
> Testing SRU-UDS scaling 768x576 - 768x576 - 768x576 in YUV444M: pass
> Testing SRU-UDS scaling 768x576 - 768x576 - 1024x768 in YUV444M: pass
> Testing SRU-UDS scaling 768x576 - 1536x1152 - 1280x960 in YUV444M: pass
> Testing SRU-UDS scaling 768x576 - 1536x1152 - 1536x1152 in YUV444M: pass
> Testing SRU-UDS scaling 768x576 - 1536x1152 - 2048x1536 in YUV444M: hangs
> Testing UDS-SRU scaling 768x576 - 640x480 - 640x480 in YUV444M: pass
> Testing UDS-SRU scaling 768x576 - 640x480 - 1280x960 in YUV444M: fail
> Testing UDS-SRU scaling 768x576 - 768x576 - 768x576 in YUV444M: pass
> Testing UDS-SRU scaling 768x576 - 768x576 - 1536x1152 in YUV444M: pass
> Testing UDS-SRU scaling 768x576 - 1024x768 - 1024x768 in YUV444M: pass
> Testing UDS-SRU scaling 768x576 - 1024x768 - 2048x1536 in YUV444M: hangs


 Do you still have the patch to vsp-tests for all these extra tests/checks?


> Two of the tests hang the VSP completely, for a reason I don't understand 
> yet. 
> Among the three tests that fail, the "UDS-SRU scaling 768x576 - 640x480 - 
> 1280x960 in YUV444M" tests is a false positives due to differences in scaling 
> algorithms between the VSP and gen-image.

Did the YUV444M tests hang repeatedly on the same test? I have seen 'random'
hangs on seemingly correct pipelines with YUV444M ... But reset/repeat test -
and it will work again. Most distressing, but perhaps might need deeper
investigation with the hardware.



> The only two tests that really fail are thus "SRU-UDS scaling 768x576 - 
> 768x576 - 640x480" in RGB24 and YUV444M.
> 
> The "20151116_VSP-IMG_Image_Partition_Information.pptx" document mentions the 
> following restrictions:
> 
> - double-scaled super resolution and UDS cannot be used at same time.
> - UDS cannot be connected after SRU.
> 
> However, from the above tests it looks like the hardware can live with more 
> relaxed restrictions than the ones implemented here. I haven't tested all UDS 
> scaling ratios, and certainly not under all memory bus load conditions, I 
> might thus be too optimistic. Morimoto-san, would it be possible to get more 
> information about this from the hardware team, to check whether the above two 
> restrictions need to be honoured, or whether they come from an older hardware 
> version ?


Well, the updated documentation is certainly more descriptive than the first set
I saw when I started this. So I'll try to look at how I can update in this 
regards.

My theory would have been that the SRU / UDS can be used in combination, as long
as the input/output requirements are correctly met for both cells, whilst taking
into consideration the scaling up or down that they perform.

Thus I had thought that perhaps this 

[PATCH v9 5/9] media: venus: vdec: add video decoder files

[Stanimir Varbanov]

This consists of video decoder implementation plus decoder
controls.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/vdec.c   | 1154 
 drivers/media/platform/qcom/venus/vdec.h   |   23 +
 drivers/media/platform/qcom/venus/vdec_ctrls.c |  150 +++
 3 files changed, 1327 insertions(+)
 create mode 100644 drivers/media/platform/qcom/venus/vdec.c
 create mode 100644 drivers/media/platform/qcom/venus/vdec.h
 create mode 100644 drivers/media/platform/qcom/venus/vdec_ctrls.c

diff --git a/drivers/media/platform/qcom/venus/vdec.c 
b/drivers/media/platform/qcom/venus/vdec.c
new file mode 100644
index ..96e7e7e71e5f
--- /dev/null
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -0,0 +1,1154 @@
+/*
+ * Copyright (c) 2012-2016, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2017 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hfi_venus_io.h"
+#include "core.h"
+#include "helpers.h"
+#include "vdec.h"
+
+static u32 get_framesize_uncompressed(unsigned int plane, u32 width, u32 
height)
+{
+   u32 y_stride, uv_stride, y_plane;
+   u32 y_sclines, uv_sclines, uv_plane;
+   u32 size;
+
+   y_stride = ALIGN(width, 128);
+   uv_stride = ALIGN(width, 128);
+   y_sclines = ALIGN(height, 32);
+   uv_sclines = ALIGN(((height + 1) >> 1), 16);
+
+   y_plane = y_stride * y_sclines;
+   uv_plane = uv_stride * uv_sclines + SZ_4K;
+   size = y_plane + uv_plane + SZ_8K;
+
+   return ALIGN(size, SZ_4K);
+}
+
+static u32 get_framesize_compressed(unsigned int width, unsigned int height)
+{
+   return ((width * height * 3 / 2) / 2) + 128;
+}
+
+/*
+ * Three resons to keep MPLANE formats (despite that the number of planes
+ * currently is one):
+ * - the MPLANE formats allow only one plane to be used
+ * - the downstream driver use MPLANE formats too
+ * - future firmware versions could add support for >1 planes
+ */
+static const struct venus_format vdec_formats[] = {
+   {
+   .pixfmt = V4L2_PIX_FMT_NV12,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_MPEG4,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_MPEG2,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_H263,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_VC1_ANNEX_G,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_VC1_ANNEX_L,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_H264,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_VP8,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_VP9,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_XVID,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   },
+};
+
+static const struct venus_format *find_format(u32 pixfmt, u32 type)
+{
+   const struct venus_format *fmt = vdec_formats;
+   unsigned int size = ARRAY_SIZE(vdec_formats);
+   unsigned int i;
+
+   for (i = 0; i < size; i++) {
+   if (fmt[i].pixfmt == pixfmt)
+   break;
+   }
+
+   if (i == size || fmt[i].type != type)
+   return NULL;
+
+   return [i];
+}
+
+static const struct venus_format *
+find_format_by_index(unsigned int index, u32 type)
+{
+   const struct venus_format *fmt = vdec_formats;
+   unsigned int size = ARRAY_SIZE(vdec_formats);
+   unsigned int i, k = 0;
+
+   if (index > size)
+   return NULL;
+
+   for (i = 0; i < size; i++) {
+   if (fmt[i].type != type)
+   continue;
+   if (k == index)
+  

[PATCH v9 1/9] media: v4l2-mem2mem: extend m2m APIs for more accurate buffer management

[Stanimir Varbanov]

this add functions for:
  - remove buffers from src/dst queue by index
  - remove exact buffer from src/dst queue

also extends m2m API to iterate over a list of src/dst buffers
in safely and non-safely manner.

Reviewed-by: Hans Verkuil 
Signed-off-by: Stanimir Varbanov 
---
 drivers/media/v4l2-core/v4l2-mem2mem.c | 37 ++
 include/media/v4l2-mem2mem.h   | 92 ++
 2 files changed, 129 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c 
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 6bc27e7b2a33..f62e68aa04c4 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -126,6 +126,43 @@ void *v4l2_m2m_buf_remove(struct v4l2_m2m_queue_ctx *q_ctx)
 }
 EXPORT_SYMBOL_GPL(v4l2_m2m_buf_remove);
 
+void v4l2_m2m_buf_remove_by_buf(struct v4l2_m2m_queue_ctx *q_ctx,
+   struct vb2_v4l2_buffer *vbuf)
+{
+   struct v4l2_m2m_buffer *b;
+   unsigned long flags;
+
+   spin_lock_irqsave(_ctx->rdy_spinlock, flags);
+   b = container_of(vbuf, struct v4l2_m2m_buffer, vb);
+   list_del(>list);
+   q_ctx->num_rdy--;
+   spin_unlock_irqrestore(_ctx->rdy_spinlock, flags);
+}
+EXPORT_SYMBOL_GPL(v4l2_m2m_buf_remove_by_buf);
+
+struct vb2_v4l2_buffer *
+v4l2_m2m_buf_remove_by_idx(struct v4l2_m2m_queue_ctx *q_ctx, unsigned int idx)
+
+{
+   struct v4l2_m2m_buffer *b, *tmp;
+   struct vb2_v4l2_buffer *ret = NULL;
+   unsigned long flags;
+
+   spin_lock_irqsave(_ctx->rdy_spinlock, flags);
+   list_for_each_entry_safe(b, tmp, _ctx->rdy_queue, list) {
+   if (b->vb.vb2_buf.index == idx) {
+   list_del(>list);
+   q_ctx->num_rdy--;
+   ret = >vb;
+   break;
+   }
+   }
+   spin_unlock_irqrestore(_ctx->rdy_spinlock, flags);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(v4l2_m2m_buf_remove_by_idx);
+
 /*
  * Scheduling handlers
  */
diff --git a/include/media/v4l2-mem2mem.h b/include/media/v4l2-mem2mem.h
index 3ccd01bd245e..e157d5c9b224 100644
--- a/include/media/v4l2-mem2mem.h
+++ b/include/media/v4l2-mem2mem.h
@@ -437,6 +437,47 @@ static inline void *v4l2_m2m_next_dst_buf(struct 
v4l2_m2m_ctx *m2m_ctx)
 }
 
 /**
+ * v4l2_m2m_for_each_dst_buf() - iterate over a list of destination ready
+ * buffers
+ *
+ * @m2m_ctx: m2m context assigned to the instance given by struct _m2m_ctx
+ * @b: current buffer of type struct v4l2_m2m_buffer
+ */
+#define v4l2_m2m_for_each_dst_buf(m2m_ctx, b)  \
+   list_for_each_entry(b, _ctx->cap_q_ctx.rdy_queue, list)
+
+/**
+ * v4l2_m2m_for_each_src_buf() - iterate over a list of source ready buffers
+ *
+ * @m2m_ctx: m2m context assigned to the instance given by struct _m2m_ctx
+ * @b: current buffer of type struct v4l2_m2m_buffer
+ */
+#define v4l2_m2m_for_each_src_buf(m2m_ctx, b)  \
+   list_for_each_entry(b, _ctx->out_q_ctx.rdy_queue, list)
+
+/**
+ * v4l2_m2m_for_each_dst_buf_safe() - iterate over a list of destination ready
+ * buffers safely
+ *
+ * @m2m_ctx: m2m context assigned to the instance given by struct _m2m_ctx
+ * @b: current buffer of type struct v4l2_m2m_buffer
+ * @n: used as temporary storage
+ */
+#define v4l2_m2m_for_each_dst_buf_safe(m2m_ctx, b, n)  \
+   list_for_each_entry_safe(b, n, _ctx->cap_q_ctx.rdy_queue, list)
+
+/**
+ * v4l2_m2m_for_each_src_buf_safe() - iterate over a list of source ready
+ * buffers safely
+ *
+ * @m2m_ctx: m2m context assigned to the instance given by struct _m2m_ctx
+ * @b: current buffer of type struct v4l2_m2m_buffer
+ * @n: used as temporary storage
+ */
+#define v4l2_m2m_for_each_src_buf_safe(m2m_ctx, b, n)  \
+   list_for_each_entry_safe(b, n, _ctx->out_q_ctx.rdy_queue, list)
+
+/**
  * v4l2_m2m_get_src_vq() - return vb2_queue for source buffers
  *
  * @m2m_ctx: m2m context assigned to the instance given by struct _m2m_ctx
@@ -488,6 +529,57 @@ static inline void *v4l2_m2m_dst_buf_remove(struct 
v4l2_m2m_ctx *m2m_ctx)
return v4l2_m2m_buf_remove(_ctx->cap_q_ctx);
 }
 
+/**
+ * v4l2_m2m_buf_remove_by_buf() - take off exact buffer from the list of ready
+ * buffers
+ *
+ * @q_ctx: pointer to struct @v4l2_m2m_queue_ctx
+ * @vbuf: the buffer to be removed
+ */
+void v4l2_m2m_buf_remove_by_buf(struct v4l2_m2m_queue_ctx *q_ctx,
+   struct vb2_v4l2_buffer *vbuf);
+
+/**
+ * v4l2_m2m_src_buf_remove_by_buf() - take off exact source buffer from the 
list
+ * of ready buffers
+ *
+ * @m2m_ctx: m2m context assigned to the instance given by struct _m2m_ctx
+ * @vbuf: the buffer to be removed
+ */
+static inline void v4l2_m2m_src_buf_remove_by_buf(struct v4l2_m2m_ctx *m2m_ctx,
+ struct vb2_v4l2_buffer *vbuf)
+{
+   v4l2_m2m_buf_remove_by_buf(_ctx->out_q_ctx, vbuf);
+}
+
+/**
+ * v4l2_m2m_dst_buf_remove_by_buf() - take off exact 

[PATCH v9 8/9] media: venus: hfi: add Venus HFI files

[Stanimir Varbanov]

Here is the implementation of Venus video accelerator low-level
functionality. It contanins code which setup the registers and
startup uthe processor, allocate and manipulates with the shared
memory used for sending commands and receiving messages.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/hfi_venus.c| 1571 ++
 drivers/media/platform/qcom/venus/hfi_venus.h|   23 +
 drivers/media/platform/qcom/venus/hfi_venus_io.h |  113 ++
 3 files changed, 1707 insertions(+)
 create mode 100644 drivers/media/platform/qcom/venus/hfi_venus.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi_venus.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_venus_io.h

diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c 
b/drivers/media/platform/qcom/venus/hfi_venus.c
new file mode 100644
index ..ab209f3d9498
--- /dev/null
+++ b/drivers/media/platform/qcom/venus/hfi_venus.c
@@ -0,0 +1,1571 @@
+/*
+ * Copyright (c) 2012-2016, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2017 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "core.h"
+#include "hfi_cmds.h"
+#include "hfi_msgs.h"
+#include "hfi_venus.h"
+#include "hfi_venus_io.h"
+
+#define HFI_MASK_QHDR_TX_TYPE  0xff00
+#define HFI_MASK_QHDR_RX_TYPE  0x00ff
+#define HFI_MASK_QHDR_PRI_TYPE 0xff00
+#define HFI_MASK_QHDR_ID_TYPE  0x00ff
+
+#define HFI_HOST_TO_CTRL_CMD_Q 0
+#define HFI_CTRL_TO_HOST_MSG_Q 1
+#define HFI_CTRL_TO_HOST_DBG_Q 2
+#define HFI_MASK_QHDR_STATUS   0x00ff
+
+#define IFACEQ_NUM 3
+#define IFACEQ_CMD_IDX 0
+#define IFACEQ_MSG_IDX 1
+#define IFACEQ_DBG_IDX 2
+#define IFACEQ_MAX_BUF_COUNT   50
+#define IFACEQ_MAX_PARALLEL_CLNTS  16
+#define IFACEQ_DFLT_QHDR   0x0101
+
+#define POLL_INTERVAL_US   50
+
+#define IFACEQ_MAX_PKT_SIZE1024
+#define IFACEQ_MED_PKT_SIZE768
+#define IFACEQ_MIN_PKT_SIZE8
+#define IFACEQ_VAR_SMALL_PKT_SIZE  100
+#define IFACEQ_VAR_LARGE_PKT_SIZE  512
+#define IFACEQ_VAR_HUGE_PKT_SIZE   (1024 * 12)
+
+enum tzbsp_video_state {
+   TZBSP_VIDEO_STATE_SUSPEND = 0,
+   TZBSP_VIDEO_STATE_RESUME
+};
+
+struct hfi_queue_table_header {
+   u32 version;
+   u32 size;
+   u32 qhdr0_offset;
+   u32 qhdr_size;
+   u32 num_q;
+   u32 num_active_q;
+};
+
+struct hfi_queue_header {
+   u32 status;
+   u32 start_addr;
+   u32 type;
+   u32 q_size;
+   u32 pkt_size;
+   u32 pkt_drop_cnt;
+   u32 rx_wm;
+   u32 tx_wm;
+   u32 rx_req;
+   u32 tx_req;
+   u32 rx_irq_status;
+   u32 tx_irq_status;
+   u32 read_idx;
+   u32 write_idx;
+};
+
+#define IFACEQ_TABLE_SIZE  \
+   (sizeof(struct hfi_queue_table_header) +\
+sizeof(struct hfi_queue_header) * IFACEQ_NUM)
+
+#define IFACEQ_QUEUE_SIZE  (IFACEQ_MAX_PKT_SIZE *  \
+   IFACEQ_MAX_BUF_COUNT * IFACEQ_MAX_PARALLEL_CLNTS)
+
+#define IFACEQ_GET_QHDR_START_ADDR(ptr, i) \
+   (void *)(((ptr) + sizeof(struct hfi_queue_table_header)) +  \
+   ((i) * sizeof(struct hfi_queue_header)))
+
+#define QDSS_SIZE  SZ_4K
+#define SFR_SIZE   SZ_4K
+#define QUEUE_SIZE \
+   (IFACEQ_TABLE_SIZE + (IFACEQ_QUEUE_SIZE * IFACEQ_NUM))
+
+#define ALIGNED_QDSS_SIZE  ALIGN(QDSS_SIZE, SZ_4K)
+#define ALIGNED_SFR_SIZE   ALIGN(SFR_SIZE, SZ_4K)
+#define ALIGNED_QUEUE_SIZE ALIGN(QUEUE_SIZE, SZ_4K)
+#define SHARED_QSIZE   ALIGN(ALIGNED_SFR_SIZE + ALIGNED_QUEUE_SIZE + \
+ ALIGNED_QDSS_SIZE, SZ_1M)
+
+struct mem_desc {
+   dma_addr_t da;  /* device address */
+   void *kva;  /* kernel virtual address */
+   u32 size;
+   unsigned long attrs;
+};
+
+struct iface_queue {
+   struct hfi_queue_header *qhdr;
+   struct mem_desc qmem;
+};
+
+enum venus_state {
+   VENUS_STATE_DEINIT = 1,
+   VENUS_STATE_INIT,
+};
+
+struct venus_hfi_device {
+   struct venus_core *core;
+   u32 irq_status;
+   u32 last_packet_type;
+   bool power_enabled;
+   bool suspended;
+   enum venus_state state;
+   /* serialize read / write to the shared memory */
+   struct mutex lock;

[PATCH v9 9/9] media: venus: enable building of Venus video driver

[Stanimir Varbanov]

This adds Venus driver Makefile and changes v4l2 platform
Makefile/Kconfig in order to enable building of the driver.

Note that in this initial version the COMPILE_TEST-ing is not
supported because the drivers specific to ARM builds are still
in process of enabling the aforementioned compile testing.
Once that disadvantage is fixed the Venus driver compile testing
will be possible with follow-up changes.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/Kconfig | 13 +
 drivers/media/platform/Makefile|  2 ++
 drivers/media/platform/qcom/venus/Makefile | 11 +++
 3 files changed, 26 insertions(+)
 create mode 100644 drivers/media/platform/qcom/venus/Makefile

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ac026ee1ca07..fd33f3ec828d 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -448,6 +448,19 @@ config VIDEO_TI_VPE_DEBUG
---help---
  Enable debug messages on VPE driver.
 
+config VIDEO_QCOM_VENUS
+   tristate "Qualcomm Venus V4L2 encoder/decoder driver"
+   depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
+   depends on ARCH_QCOM && IOMMU_DMA
+   select QCOM_MDT_LOADER
+   select VIDEOBUF2_DMA_SG
+   select V4L2_MEM2MEM_DEV
+   ---help---
+ This is a V4L2 driver for Qualcomm Venus video accelerator
+ hardware. It accelerates encoding and decoding operations
+ on various Qualcomm SoCs.
+ To compile this driver as a module choose m here.
+
 endif # V4L_MEM2MEM_DRIVERS
 
 # TI VIDEO PORT Helper Modules
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 63303d63c64c..c49de824af16 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -77,3 +77,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)   += mtk-vcodec/
 obj-$(CONFIG_VIDEO_MEDIATEK_MDP)   += mtk-mdp/
 
 obj-$(CONFIG_VIDEO_MEDIATEK_JPEG)  += mtk-jpeg/
+
+obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
diff --git a/drivers/media/platform/qcom/venus/Makefile 
b/drivers/media/platform/qcom/venus/Makefile
new file mode 100644
index ..0fe9afb83697
--- /dev/null
+++ b/drivers/media/platform/qcom/venus/Makefile
@@ -0,0 +1,11 @@
+# Makefile for Qualcomm Venus driver
+
+venus-core-objs += core.o helpers.o firmware.o \
+  hfi_venus.o hfi_msgs.o hfi_cmds.o hfi.o
+
+venus-dec-objs += vdec.o vdec_ctrls.o
+venus-enc-objs += venc.o venc_ctrls.o
+
+obj-$(CONFIG_VIDEO_QCOM_VENUS) += venus-core.o
+obj-$(CONFIG_VIDEO_QCOM_VENUS) += venus-dec.o
+obj-$(CONFIG_VIDEO_QCOM_VENUS) += venus-enc.o
-- 
2.7.4

[PATCH v9 4/9] media: venus: adding core part and helper functions

[Stanimir Varbanov]

 * core.c has implemented the platform driver methods, file
operations and v4l2 registration.

 * helpers.c has implemented common helper functions for:
   - buffer management

   - vb2_ops and functions for format propagation,

   - functions for allocating and freeing buffers for
   internal usage. The buffer parameters describing internal
   buffers depends on current format, resolution and codec.

   - functions for calculation of current load of the
   hardware. Depending on the count of instances and
   resolutions it selects the best clock rate for the video
   core.

 * firmware loader

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/core.c | 388 ++
 drivers/media/platform/qcom/venus/core.h | 323 
 drivers/media/platform/qcom/venus/firmware.c | 109 
 drivers/media/platform/qcom/venus/firmware.h |  22 +
 drivers/media/platform/qcom/venus/helpers.c  | 727 +++
 drivers/media/platform/qcom/venus/helpers.h  |  45 ++
 6 files changed, 1614 insertions(+)
 create mode 100644 drivers/media/platform/qcom/venus/core.c
 create mode 100644 drivers/media/platform/qcom/venus/core.h
 create mode 100644 drivers/media/platform/qcom/venus/firmware.c
 create mode 100644 drivers/media/platform/qcom/venus/firmware.h
 create mode 100644 drivers/media/platform/qcom/venus/helpers.c
 create mode 100644 drivers/media/platform/qcom/venus/helpers.h

diff --git a/drivers/media/platform/qcom/venus/core.c 
b/drivers/media/platform/qcom/venus/core.c
new file mode 100644
index ..48391d87d5c3
--- /dev/null
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -0,0 +1,388 @@
+/*
+ * Copyright (c) 2012-2016, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2017 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "core.h"
+#include "vdec.h"
+#include "venc.h"
+#include "firmware.h"
+
+static void venus_event_notify(struct venus_core *core, u32 event)
+{
+   struct venus_inst *inst;
+
+   switch (event) {
+   case EVT_SYS_WATCHDOG_TIMEOUT:
+   case EVT_SYS_ERROR:
+   break;
+   default:
+   return;
+   }
+
+   mutex_lock(>lock);
+   core->sys_error = true;
+   list_for_each_entry(inst, >instances, list)
+   inst->ops->event_notify(inst, EVT_SESSION_ERROR, NULL);
+   mutex_unlock(>lock);
+
+   disable_irq_nosync(core->irq);
+
+   /*
+* Delay recovery to ensure venus has completed any pending cache
+* operations. Without this sleep, we see device reset when firmware is
+* unloaded after a system error.
+*/
+   schedule_delayed_work(>work, msecs_to_jiffies(100));
+}
+
+static const struct hfi_core_ops venus_core_ops = {
+   .event_notify = venus_event_notify,
+};
+
+static void venus_sys_error_handler(struct work_struct *work)
+{
+   struct venus_core *core =
+   container_of(work, struct venus_core, work.work);
+   int ret = 0;
+
+   dev_warn(core->dev, "system error has occurred, starting recovery!\n");
+
+   pm_runtime_get_sync(core->dev);
+
+   hfi_core_deinit(core, true);
+   hfi_destroy(core);
+   mutex_lock(>lock);
+   venus_shutdown(>dev_fw);
+
+   pm_runtime_put_sync(core->dev);
+
+   ret |= hfi_create(core, _core_ops);
+
+   pm_runtime_get_sync(core->dev);
+
+   ret |= venus_boot(core->dev, >dev_fw);
+
+   ret |= hfi_core_resume(core, true);
+
+   enable_irq(core->irq);
+
+   mutex_unlock(>lock);
+
+   ret |= hfi_core_init(core);
+
+   pm_runtime_put_sync(core->dev);
+
+   if (ret) {
+   disable_irq_nosync(core->irq);
+   dev_warn(core->dev, "recovery failed (%d)\n", ret);
+   schedule_delayed_work(>work, msecs_to_jiffies(10));
+   return;
+   }
+
+   mutex_lock(>lock);
+   core->sys_error = false;
+   mutex_unlock(>lock);
+}
+
+static int venus_clks_get(struct venus_core *core)
+{
+   const struct venus_resources *res = core->res;
+   struct device *dev = core->dev;
+   unsigned int i;
+
+   for (i = 0; i < res->clks_num; i++) {
+   core->clks[i] = devm_clk_get(dev, res->clks[i]);
+   if (IS_ERR(core->clks[i]))
+   return PTR_ERR(core->clks[i]);
+   }
+
+   return 0;
+}
+

[PATCH v9 7/9] media: venus: hfi: add Host Firmware Interface (HFI)

[Stanimir Varbanov]

This is the implementation of HFI. It is charged with the
responsibility to comunicate with the firmware through an
interface commands and messages.

 - hfi.c has interface functions used by the core, decoder
and encoder parts to comunicate with the firmware. For example
there are functions for session and core initialisation.

 - hfi_cmds has packetization operations which preparing
packets to be send from host to firmware.

 - hfi_msgs takes care of messages sent from firmware to the
host.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/hfi.c|  522 ++
 drivers/media/platform/qcom/venus/hfi.h|  175 
 drivers/media/platform/qcom/venus/hfi_cmds.c   | 1255 
 drivers/media/platform/qcom/venus/hfi_cmds.h   |  304 ++
 drivers/media/platform/qcom/venus/hfi_helper.h | 1050 
 drivers/media/platform/qcom/venus/hfi_msgs.c   | 1054 
 drivers/media/platform/qcom/venus/hfi_msgs.h   |  283 ++
 7 files changed, 4643 insertions(+)
 create mode 100644 drivers/media/platform/qcom/venus/hfi.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_cmds.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi_cmds.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_helper.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_msgs.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi_msgs.h

diff --git a/drivers/media/platform/qcom/venus/hfi.c 
b/drivers/media/platform/qcom/venus/hfi.c
new file mode 100644
index ..20c9205fdbb4
--- /dev/null
+++ b/drivers/media/platform/qcom/venus/hfi.c
@@ -0,0 +1,522 @@
+/*
+ * Copyright (c) 2012-2016, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2017 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "core.h"
+#include "hfi.h"
+#include "hfi_cmds.h"
+#include "hfi_venus.h"
+
+#define TIMEOUTmsecs_to_jiffies(1000)
+
+static u32 to_codec_type(u32 pixfmt)
+{
+   switch (pixfmt) {
+   case V4L2_PIX_FMT_H264:
+   case V4L2_PIX_FMT_H264_NO_SC:
+   return HFI_VIDEO_CODEC_H264;
+   case V4L2_PIX_FMT_H263:
+   return HFI_VIDEO_CODEC_H263;
+   case V4L2_PIX_FMT_MPEG1:
+   return HFI_VIDEO_CODEC_MPEG1;
+   case V4L2_PIX_FMT_MPEG2:
+   return HFI_VIDEO_CODEC_MPEG2;
+   case V4L2_PIX_FMT_MPEG4:
+   return HFI_VIDEO_CODEC_MPEG4;
+   case V4L2_PIX_FMT_VC1_ANNEX_G:
+   case V4L2_PIX_FMT_VC1_ANNEX_L:
+   return HFI_VIDEO_CODEC_VC1;
+   case V4L2_PIX_FMT_VP8:
+   return HFI_VIDEO_CODEC_VP8;
+   case V4L2_PIX_FMT_VP9:
+   return HFI_VIDEO_CODEC_VP9;
+   case V4L2_PIX_FMT_XVID:
+   return HFI_VIDEO_CODEC_DIVX;
+   default:
+   return 0;
+   }
+}
+
+int hfi_core_init(struct venus_core *core)
+{
+   int ret = 0;
+
+   mutex_lock(>lock);
+
+   if (core->state >= CORE_INIT)
+   goto unlock;
+
+   reinit_completion(>done);
+
+   ret = core->ops->core_init(core);
+   if (ret)
+   goto unlock;
+
+   ret = wait_for_completion_timeout(>done, TIMEOUT);
+   if (!ret) {
+   ret = -ETIMEDOUT;
+   goto unlock;
+   }
+
+   ret = 0;
+
+   if (core->error != HFI_ERR_NONE) {
+   ret = -EIO;
+   goto unlock;
+   }
+
+   core->state = CORE_INIT;
+unlock:
+   mutex_unlock(>lock);
+   return ret;
+}
+
+static int core_deinit_wait_atomic_t(atomic_t *p)
+{
+   schedule();
+   return 0;
+}
+
+int hfi_core_deinit(struct venus_core *core, bool blocking)
+{
+   int ret = 0, empty;
+
+   mutex_lock(>lock);
+
+   if (core->state == CORE_UNINIT)
+   goto unlock;
+
+   empty = list_empty(>instances);
+
+   if (!empty && !blocking) {
+   ret = -EBUSY;
+   goto unlock;
+   }
+
+   if (!empty) {
+   mutex_unlock(>lock);
+   wait_on_atomic_t(>insts_count, core_deinit_wait_atomic_t,
+TASK_UNINTERRUPTIBLE);
+   mutex_lock(>lock);
+   }
+
+   ret = core->ops->core_deinit(core);
+
+   if (!ret)
+   core->state = CORE_UNINIT;
+
+unlock:
+   mutex_unlock(>lock);
+   return ret;
+}
+
+int 

[PATCH v9 6/9] media: venus: venc: add video encoder files

[Stanimir Varbanov]

This adds encoder part of the driver plus encoder controls.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/venc.c   | 1283 
 drivers/media/platform/qcom/venus/venc.h   |   23 +
 drivers/media/platform/qcom/venus/venc_ctrls.c |  270 +
 3 files changed, 1576 insertions(+)
 create mode 100644 drivers/media/platform/qcom/venus/venc.c
 create mode 100644 drivers/media/platform/qcom/venus/venc.h
 create mode 100644 drivers/media/platform/qcom/venus/venc_ctrls.c

diff --git a/drivers/media/platform/qcom/venus/venc.c 
b/drivers/media/platform/qcom/venus/venc.c
new file mode 100644
index ..d5b4b5bf10a2
--- /dev/null
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -0,0 +1,1283 @@
+/*
+ * Copyright (c) 2012-2016, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2017 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hfi_venus_io.h"
+#include "core.h"
+#include "helpers.h"
+#include "venc.h"
+
+#define NUM_B_FRAMES_MAX   4
+
+static u32 get_framesize_uncompressed(unsigned int plane, u32 width, u32 
height)
+{
+   u32 y_stride, uv_stride, y_plane;
+   u32 y_sclines, uv_sclines, uv_plane;
+   u32 size;
+
+   y_stride = ALIGN(width, 128);
+   uv_stride = ALIGN(width, 128);
+   y_sclines = ALIGN(height, 32);
+   uv_sclines = ALIGN(((height + 1) >> 1), 16);
+
+   y_plane = y_stride * y_sclines;
+   uv_plane = uv_stride * uv_sclines + SZ_4K;
+   size = y_plane + uv_plane + SZ_8K;
+   size = ALIGN(size, SZ_4K);
+
+   return size;
+}
+
+static u32 get_framesize_compressed(u32 width, u32 height)
+{
+   u32 sz = ALIGN(height, 32) * ALIGN(width, 32) * 3 / 2 / 2;
+
+   return ALIGN(sz, SZ_4K);
+}
+
+/*
+ * Three resons to keep MPLANE formats (despite that the number of planes
+ * currently is one):
+ * - the MPLANE formats allow only one plane to be used
+ * - the downstream driver use MPLANE formats too
+ * - future firmware versions could add support for >1 planes
+ */
+static const struct venus_format venc_formats[] = {
+   {
+   .pixfmt = V4L2_PIX_FMT_NV12,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_MPEG4,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_H263,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_H264,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_VP8,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_VP9,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
+   },
+};
+
+static const struct venus_format *find_format(u32 pixfmt, u32 type)
+{
+   const struct venus_format *fmt = venc_formats;
+   unsigned int size = ARRAY_SIZE(venc_formats);
+   unsigned int i;
+
+   for (i = 0; i < size; i++) {
+   if (fmt[i].pixfmt == pixfmt)
+   break;
+   }
+
+   if (i == size || fmt[i].type != type)
+   return NULL;
+
+   return [i];
+}
+
+static const struct venus_format *
+find_format_by_index(unsigned int index, u32 type)
+{
+   const struct venus_format *fmt = venc_formats;
+   unsigned int size = ARRAY_SIZE(venc_formats);
+   unsigned int i, k = 0;
+
+   if (index > size)
+   return NULL;
+
+   for (i = 0; i < size; i++) {
+   if (fmt[i].type != type)
+   continue;
+   if (k == index)
+   break;
+   k++;
+   }
+
+   if (i == size)
+   return NULL;
+
+   return [i];
+}
+
+static int venc_v4l2_to_hfi(int id, int value)
+{
+   switch (id) {
+   case V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL:
+   switch (value) {
+   case V4L2_MPEG_VIDEO_MPEG4_LEVEL_0:
+   default:
+   return HFI_MPEG4_LEVEL_0;
+   case V4L2_MPEG_VIDEO_MPEG4_LEVEL_0B:
+   return HFI_MPEG4_LEVEL_0b;
+  

[PATCH v9 2/9] doc: DT: venus: binding document for Qualcomm video driver

[Stanimir Varbanov]

Add binding document for Venus video encoder/decoder driver

Acked-by: Rob Herring 
Signed-off-by: Stanimir Varbanov 
---
 .../devicetree/bindings/media/qcom,venus.txt   | 107 +
 1 file changed, 107 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/qcom,venus.txt

diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt 
b/Documentation/devicetree/bindings/media/qcom,venus.txt
new file mode 100644
index ..2693449daf73
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
@@ -0,0 +1,107 @@
+* Qualcomm Venus video encoder/decoder accelerators
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: Value should contain one of:
+   - "qcom,msm8916-venus"
+   - "qcom,msm8996-venus"
+- reg:
+   Usage: required
+   Value type: 
+   Definition: Register base address and length of the register map.
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: Should contain interrupt line number.
+- clocks:
+   Usage: required
+   Value type: 
+   Definition: A List of phandle and clock specifier pairs as listed
+   in clock-names property.
+- clock-names:
+   Usage: required for msm8916
+   Value type: 
+   Definition: Should contain the following entries:
+   - "core"Core video accelerator clock
+   - "iface"   Video accelerator AHB clock
+   - "bus" Video accelerator AXI clock
+- clock-names:
+   Usage: required for msm8996
+   Value type: 
+   Definition: Should contain the following entries:
+   - "core"Core video accelerator clock
+   - "iface"   Video accelerator AHB clock
+   - "bus" Video accelerator AXI clock
+   - "mbus"Video MAXI clock
+- power-domains:
+   Usage: required
+   Value type: 
+   Definition: A phandle and power domain specifier pairs to the
+   power domain which is responsible for collapsing
+   and restoring power to the peripheral.
+- iommus:
+   Usage: required
+   Value type: 
+   Definition: A list of phandle and IOMMU specifier pairs.
+- memory-region:
+   Usage: required
+   Value type: 
+   Definition: reference to the reserved-memory for the firmware
+   memory region.
+
+* Subnodes
+The Venus video-codec node must contain two subnodes representing
+video-decoder and video-encoder.
+
+Every of video-encoder or video-decoder subnode should have:
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: Value should contain "venus-decoder" or "venus-encoder"
+- clocks:
+   Usage: required for msm8996
+   Value type: 
+   Definition: A List of phandle and clock specifier pairs as listed
+   in clock-names property.
+- clock-names:
+   Usage: required for msm8996
+   Value type: 
+   Definition: Should contain the following entries:
+   - "core"Subcore video accelerator clock
+
+- power-domains:
+   Usage: required for msm8996
+   Value type: 
+   Definition: A phandle and power domain specifier pairs to the
+   power domain which is responsible for collapsing
+   and restoring power to the subcore.
+
+* An Example
+   video-codec@1d0 {
+   compatible = "qcom,msm8916-venus";
+   reg = <0x01d0 0xff000>;
+   interrupts = ;
+   clocks = < GCC_VENUS0_VCODEC0_CLK>,
+< GCC_VENUS0_AHB_CLK>,
+< GCC_VENUS0_AXI_CLK>;
+   clock-names = "core", "iface", "bus";
+   power-domains = < VENUS_GDSC>;
+   iommus = <_iommu 5>;
+   memory-region = <_mem>;
+
+   video-decoder {
+   compatible = "venus-decoder";
+   clocks = < VIDEO_SUBCORE0_CLK>;
+   clock-names = "core";
+   power-domains = < VENUS_CORE0_GDSC>;
+   };
+
+   video-encoder {
+   compatible = "venus-encoder";
+   clocks = < VIDEO_SUBCORE1_CLK>;
+   clock-names = "core";
+   power-domains = < VENUS_CORE1_GDSC>;
+   };
+   };
-- 
2.7.4

[PATCH v9 3/9] MAINTAINERS: Add Qualcomm Venus video accelerator driver

[Stanimir Varbanov]

Add an entry for Venus video encoder/decoder accelerator driver.

Signed-off-by: Stanimir Varbanov 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 58590cfed9f8..cff2be4a44d0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10590,6 +10590,14 @@ T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/rkuo/linux-hexagon-kernel.g
 S: Supported
 F: arch/hexagon/
 
+QUALCOMM VENUS VIDEO ACCELERATOR DRIVER
+M: Stanimir Varbanov 
+L: linux-media@vger.kernel.org
+L: linux-arm-...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/platform/qcom/venus/
+
 QUALCOMM WCN36XX WIRELESS DRIVER
 M: Eugene Krasnikov 
 L: wcn3...@lists.infradead.org
-- 
2.7.4

[PATCH v9 0/9] Qualcomm video decoder/encoder driver

[Stanimir Varbanov]

Hello everyone,

The changes since v8 are:
  * no functional changes.
  * dropped COMPILE_TEST support until the drivers which Venus
  driver selects got compile test support.
  * added venus_ prefix to the exported helper functions as
  suggested by Sakari.
  * fixed few signed-unsigned compare warnings.

Patches applies cleanly on next-20170509 and media_tree.
  
regards,
Stan

Stanimir Varbanov (9):
  media: v4l2-mem2mem: extend m2m APIs for more accurate buffer
management
  doc: DT: venus: binding document for Qualcomm video driver
  MAINTAINERS: Add Qualcomm Venus video accelerator driver
  media: venus: adding core part and helper functions
  media: venus: vdec: add video decoder files
  media: venus: venc: add video encoder files
  media: venus: hfi: add Host Firmware Interface (HFI)
  media: venus: hfi: add Venus HFI files
  media: venus: enable building of Venus video driver

 .../devicetree/bindings/media/qcom,venus.txt   |  107 ++
 MAINTAINERS|8 +
 drivers/media/platform/Kconfig |   13 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/qcom/venus/Makefile |   11 +
 drivers/media/platform/qcom/venus/core.c   |  388 +
 drivers/media/platform/qcom/venus/core.h   |  323 
 drivers/media/platform/qcom/venus/firmware.c   |  109 ++
 drivers/media/platform/qcom/venus/firmware.h   |   22 +
 drivers/media/platform/qcom/venus/helpers.c|  727 +
 drivers/media/platform/qcom/venus/helpers.h|   45 +
 drivers/media/platform/qcom/venus/hfi.c|  522 +++
 drivers/media/platform/qcom/venus/hfi.h|  175 +++
 drivers/media/platform/qcom/venus/hfi_cmds.c   | 1255 
 drivers/media/platform/qcom/venus/hfi_cmds.h   |  304 
 drivers/media/platform/qcom/venus/hfi_helper.h | 1050 +
 drivers/media/platform/qcom/venus/hfi_msgs.c   | 1054 +
 drivers/media/platform/qcom/venus/hfi_msgs.h   |  283 
 drivers/media/platform/qcom/venus/hfi_venus.c  | 1571 
 drivers/media/platform/qcom/venus/hfi_venus.h  |   23 +
 drivers/media/platform/qcom/venus/hfi_venus_io.h   |  113 ++
 drivers/media/platform/qcom/venus/vdec.c   | 1154 ++
 drivers/media/platform/qcom/venus/vdec.h   |   23 +
 drivers/media/platform/qcom/venus/vdec_ctrls.c |  150 ++
 drivers/media/platform/qcom/venus/venc.c   | 1283 
 drivers/media/platform/qcom/venus/venc.h   |   23 +
 drivers/media/platform/qcom/venus/venc_ctrls.c |  270 
 drivers/media/v4l2-core/v4l2-mem2mem.c |   37 +
 include/media/v4l2-mem2mem.h   |   92 ++
 29 files changed, 11137 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/qcom,venus.txt
 create mode 100644 drivers/media/platform/qcom/venus/Makefile
 create mode 100644 drivers/media/platform/qcom/venus/core.c
 create mode 100644 drivers/media/platform/qcom/venus/core.h
 create mode 100644 drivers/media/platform/qcom/venus/firmware.c
 create mode 100644 drivers/media/platform/qcom/venus/firmware.h
 create mode 100644 drivers/media/platform/qcom/venus/helpers.c
 create mode 100644 drivers/media/platform/qcom/venus/helpers.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_cmds.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi_cmds.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_helper.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_msgs.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi_msgs.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_venus.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi_venus.h
 create mode 100644 drivers/media/platform/qcom/venus/hfi_venus_io.h
 create mode 100644 drivers/media/platform/qcom/venus/vdec.c
 create mode 100644 drivers/media/platform/qcom/venus/vdec.h
 create mode 100644 drivers/media/platform/qcom/venus/vdec_ctrls.c
 create mode 100644 drivers/media/platform/qcom/venus/venc.c
 create mode 100644 drivers/media/platform/qcom/venus/venc.h
 create mode 100644 drivers/media/platform/qcom/venus/venc_ctrls.c

-- 
2.7.4

Re: [PATCH 3/3] [media] intel-ipu3: cio2: Add new MIPI-CSI2 driver

[Tomasz Figa]

On Tue, May 2, 2017 at 9:00 PM, Sakari Ailus  wrote:
> Hi Yong,
>
> Thanks for the patches! Some comments below.
>
> On Sat, Apr 29, 2017 at 06:34:36PM -0500, Yong Zhi wrote:
>> +
>> +/ FBPT operations /
>> +
>> +static void cio2_fbpt_exit_dummy(struct cio2_device *cio2)
>> +{
>> + if (cio2->dummy_lop) {
>> + dma_free_noncoherent(>pci_dev->dev, PAGE_SIZE,
>> + cio2->dummy_lop, cio2->dummy_lop_bus_addr);
>> + cio2->dummy_lop = NULL;
>> + }
>> + if (cio2->dummy_page) {
>> + dma_free_noncoherent(>pci_dev->dev, PAGE_SIZE,
>> + cio2->dummy_page, cio2->dummy_page_bus_addr);
>> + cio2->dummy_page = NULL;
>> + }
>> +}
>> +
>> +static int cio2_fbpt_init_dummy(struct cio2_device *cio2)
>> +{
>> + unsigned int i;
>> +
>> + cio2->dummy_page = dma_alloc_noncoherent(>pci_dev->dev, 
>> PAGE_SIZE,
>> + >dummy_page_bus_addr, 
>> GFP_KERNEL);
>> + cio2->dummy_lop = dma_alloc_noncoherent(>pci_dev->dev, PAGE_SIZE,
>> + >dummy_lop_bus_addr, GFP_KERNEL);
>> + if (!cio2->dummy_page || !cio2->dummy_lop) {
>> + cio2_fbpt_exit_dummy(cio2);
>> + return -ENOMEM;
>> + }
>> + /*
>> +  * List of Pointers(LOP) contains 1024x32b pointers to 4KB page each
>> +  * Initialize each entry to dummy_page bus base address.
>> +  */
>> + for (i = 0; i < PAGE_SIZE / sizeof(*cio2->dummy_lop); i++)
>> + cio2->dummy_lop[i] = cio2->dummy_page_bus_addr >> PAGE_SHIFT;
>> +
>> + dma_sync_single_for_device(>pci_dev->dev, /* DMA phy addr */
>> + cio2->dummy_lop_bus_addr, PAGE_SIZE, DMA_TO_DEVICE);
>> +
>> + return 0;
>> +}
>> +
>> +static void cio2_fbpt_entry_enable(struct cio2_device *cio2,
>> +struct cio2_fbpt_entry entry[CIO2_MAX_LOPS])
>> +{
>> + dma_wmb();
>
> Is there a particular reason to have this?
>
> The documentation states that (Documentation/memory-barriers.txt):
>
>  These are for use with consistent memory to guarantee the ordering
>  of writes or reads of shared memory accessible to both the CPU and a
>  DMA capable device.
>
> This is while the device does not do cache coherent DMA.

I think the first question we should ask is why the driver allocates
non-consistent memory for this kind of structures. Looks like a waste
of cachelines, given that it seems to be a primarily write-only memory
(from CPU point of view), with rare read backs of entry[0] to check
the flags, which can be modified by the device. Moreover, the fact
that the memory is being cached actually defeats the barrier, as you
first write entry[1..N], call the barrier, write entry[0] and then
flush the cache starting from entry[0], which means that the hardware
sees entry[0] (+/- the size of the cacheline) before further entries.

Other than that, I think the barrier makes sense, as the compiler (or
even the CPU or buses) could reorder the writes without it, regardless
of whether the memory is consistent or not. (Of course the cache
flushing problem above remains if the memory is non-consistent.)

Best regards,
Tomasz

Re: [PATCH v5 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding

[Rob Herring]

On Tue, May 9, 2017 at 8:37 AM, Ramesh Shanmugasundaram
 wrote:
> Add binding documentation for Renesas R-Car Digital Radio Interface
> (DRIF) controller.
>
> Signed-off-by: Ramesh Shanmugasundaram 
> 
> ---
> v5:
>  - Addressed Rob's comments on v4:
> - Formatted compatible string entries.
> - Removed "status".
> - Removed board and SoC specific bindings classification example.
> - Removed pinctrl nodes.
> ---
>  .../devicetree/bindings/media/renesas,drif.txt | 177 
> +
>  1 file changed, 177 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt

Acked-by: Rob Herring 

[PATCH v3] dw9714: Initial driver for dw9714 VCM

[Rajmohan Mani]

DW9714 is a 10 bit DAC, designed for linear
control of voice coil motor.

This driver creates a V4L2 subdevice and
provides control to set the desired focus.

Signed-off-by: Rajmohan Mani 
---
Changes in v3:
- Addressed most of the review comments from Sakari
  on v1 of this patch
Changes in v2:
- Addressed review comments from Hans Verkuil
- Fixed a debug message typo
- Got rid of a return variable
---
 drivers/media/i2c/Kconfig  |   9 ++
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/dw9714.c | 332 +
 3 files changed, 342 insertions(+)
 create mode 100644 drivers/media/i2c/dw9714.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index fd181c9..516e2f2 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -300,6 +300,15 @@ config VIDEO_AD5820
  This is a driver for the AD5820 camera lens voice coil.
  It is used for example in Nokia N900 (RX-51).
 
+config VIDEO_DW9714
+   tristate "DW9714 lens voice coil support"
+   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER && 
VIDEO_V4L2_SUBDEV_API
+   ---help---
+ This is a driver for the DW9714 camera lens voice coil.
+ DW9714 is a 10 bit DAC with 120mA output current sink
+ capability. This is designed for linear control of
+ voice coil motors, controlled via I2C serial interface.
+
 config VIDEO_SAA7110
tristate "Philips SAA7110 video decoder"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 62323ec..987bd1f 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_VIDEO_SAA7127) += saa7127.o
 obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o
 obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o
 obj-$(CONFIG_VIDEO_AD5820)  += ad5820.o
+obj-$(CONFIG_VIDEO_DW9714)  += dw9714.o
 obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
 obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
 obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o
diff --git a/drivers/media/i2c/dw9714.c b/drivers/media/i2c/dw9714.c
new file mode 100644
index 000..a7ca247
--- /dev/null
+++ b/drivers/media/i2c/dw9714.c
@@ -0,0 +1,332 @@
+/*
+ * Copyright (c) 2015--2017 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DW9714_NAME"dw9714"
+#define DW9714_MAX_FOCUS_POS   1023
+#define DW9714_CTRL_STEPS  16  /* Keep this value power of 2 */
+#define DW9714_CTRL_DELAY_US   1000
+/*
+ * S[3:2] = 0x00, codes per step for "Linear Slope Control"
+ * S[1:0] = 0x00, step period
+ */
+#define DW9714_DEFAULT_S 0x0
+#define DW9714_VAL(data, s) (u16)((data) << 4 | (s))
+
+/* dw9714 device structure */
+struct dw9714_device {
+   struct i2c_client *client;
+   struct v4l2_ctrl_handler ctrls_vcm;
+   struct v4l2_subdev sd;
+   u16 current_val;
+};
+
+#define to_dw9714_vcm(_ctrl)   \
+   container_of(_ctrl->handler, struct dw9714_device, ctrls_vcm)
+
+static int dw9714_i2c_write(struct i2c_client *client, u16 data)
+{
+   const int num_msg = 1;
+   int ret;
+   u16 val = cpu_to_be16(data);
+   struct i2c_msg msg = {
+   .addr = client->addr,
+   .flags = 0,
+   .len = sizeof(val),
+   .buf = (u8 *) ,
+   };
+
+   ret = i2c_transfer(client->adapter, , num_msg);
+
+   /*One retry */
+   if (ret != num_msg)
+   ret = i2c_transfer(client->adapter, , num_msg);
+
+   if (ret != num_msg) {
+   dev_err(>dev, "I2C write fail\n");
+   return -EIO;
+   }
+   return 0;
+}
+
+static int dw9714_t_focus_vcm(struct dw9714_device *dw9714_dev, u16 val)
+{
+   struct i2c_client *client = dw9714_dev->client;
+
+   dw9714_dev->current_val = val;
+
+   return dw9714_i2c_write(client, DW9714_VAL(val, DW9714_DEFAULT_S));
+}
+
+static int dw9714_set_ctrl(struct v4l2_ctrl *ctrl)
+{
+   struct dw9714_device *dev_vcm = to_dw9714_vcm(ctrl);
+
+   if (ctrl->id == V4L2_CID_FOCUS_ABSOLUTE)
+   return dw9714_t_focus_vcm(dev_vcm, ctrl->val);
+
+   return -EINVAL;
+}
+
+static const struct v4l2_ctrl_ops dw9714_vcm_ctrl_ops = {
+   .s_ctrl = dw9714_set_ctrl,
+};
+
+static int dw9714_init_controls(struct dw9714_device *dev_vcm)
+{
+   struct v4l2_ctrl_handler *hdl = _vcm->ctrls_vcm;
+   const struct v4l2_ctrl_ops *ops = _vcm_ctrl_ops;
+   

[PATCH v5 7/7] media: platform: rcar_drif: Add DRIF support

[Ramesh Shanmugasundaram]

This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3 SoCs.
The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF
device represents a channel and each channel can have one or two
sub-channels respectively depending on the target board.

DRIF supports only Rx functionality. It receives samples from a RF
frontend tuner chip it is interfaced with. The combination of DRIF and the
tuner device, which is registered as a sub-device, determines the receive
sample rate and format.

In order to be compliant as a V4L2 SDR device, DRIF needs to bind with
the tuner device, which can be provided by a third party vendor. DRIF acts
as a slave device and the tuner device acts as a master transmitting the
samples. The driver allows asynchronous binding of a tuner device that
is registered as a v4l2 sub-device. The driver can learn about the tuner
it is interfaced with based on port endpoint properties of the device in
device tree. The V4L2 SDR device inherits the controls exposed by the
tuner device.

The device can also be configured to use either one or both of the data
pins at runtime based on the master (tuner) configuration.

Signed-off-by: Ramesh Shanmugasundaram 
---
 drivers/media/platform/Kconfig |   25 +
 drivers/media/platform/Makefile|1 +
 drivers/media/platform/rcar_drif.c | 1488 
 3 files changed, 1514 insertions(+)
 create mode 100644 drivers/media/platform/rcar_drif.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 73c3bc5deadf..433397802ef2 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -520,3 +520,28 @@ menuconfig DVB_PLATFORM_DRIVERS
 if DVB_PLATFORM_DRIVERS
 source "drivers/media/platform/sti/c8sectpfe/Kconfig"
 endif #DVB_PLATFORM_DRIVERS
+
+menuconfig SDR_PLATFORM_DRIVERS
+   bool "SDR platform devices"
+   depends on MEDIA_SDR_SUPPORT
+   default n
+   ---help---
+ Say Y here to enable support for platform-specific SDR Drivers.
+
+if SDR_PLATFORM_DRIVERS
+
+config VIDEO_RCAR_DRIF
+   tristate "Renesas Digitial Radio Interface (DRIF)"
+   depends on VIDEO_V4L2 && HAS_DMA
+   depends on ARCH_RENESAS
+   select VIDEOBUF2_VMALLOC
+   ---help---
+ Say Y if you want to enable R-Car Gen3 DRIF support. DRIF is Digital
+ Radio Interface that interfaces with an RF front end chip. It is a
+ receiver of digital data which uses DMA to transfer received data to
+ a configured location for an application to use.
+
+ To compile this driver as a module, choose M here; the module
+ will be called rcar_drif.
+
+endif # SDR_PLATFORM_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 63303d63c64c..6349698bb37a 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_VIDEO_SH_VOU)+= sh_vou.o
 
 obj-$(CONFIG_SOC_CAMERA)   += soc_camera/
 
+obj-$(CONFIG_VIDEO_RCAR_DRIF)  += rcar_drif.o
 obj-$(CONFIG_VIDEO_RENESAS_FCP)+= rcar-fcp.o
 obj-$(CONFIG_VIDEO_RENESAS_FDP1)   += rcar_fdp1.o
 obj-$(CONFIG_VIDEO_RENESAS_JPU)+= rcar_jpu.o
diff --git a/drivers/media/platform/rcar_drif.c 
b/drivers/media/platform/rcar_drif.c
new file mode 100644
index ..d357e247f339
--- /dev/null
+++ b/drivers/media/platform/rcar_drif.c
@@ -0,0 +1,1488 @@
+/*
+ * R-Car Gen3 Digital Radio Interface (DRIF) driver
+ *
+ * Copyright (C) 2017 Renesas Electronics Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * The R-Car DRIF is a receive only MSIOF like controller with an
+ * external master device driving the SCK. It receives data into a FIFO,
+ * then this driver uses the SYS-DMAC engine to move the data from
+ * the device to memory.
+ *
+ * Each DRIF channel DRIFx (as per datasheet) contains two internal
+ * channels DRIFx0 & DRIFx1 within itself with each having its own resources
+ * like module clk, register set, irq and dma. These internal channels share
+ * common CLK & SYNC from master. The two data pins D0 & D1 shall be
+ * considered to represent the two internal channels. This internal split
+ * is not visible to the master device.
+ *
+ * Depending on the master device, a DRIF channel can use
+ *  (1) both internal channels (D0 & D1) to receive data in parallel (or)
+ *  (2) one internal channel (D0 or D1) to receive data
+ *

[PATCH v5 5/7] doc_rst: media: New SDR formats PC16, PC18 & PC20

[Ramesh Shanmugasundaram]

This patch adds documentation for the three new SDR formats

V4L2_SDR_FMT_PCU16BE
V4L2_SDR_FMT_PCU18BE
V4L2_SDR_FMT_PCU20BE

Signed-off-by: Ramesh Shanmugasundaram 
---
 .../media/uapi/v4l/pixfmt-sdr-pcu16be.rst  | 55 ++
 .../media/uapi/v4l/pixfmt-sdr-pcu18be.rst  | 55 ++
 .../media/uapi/v4l/pixfmt-sdr-pcu20be.rst  | 54 +
 Documentation/media/uapi/v4l/sdr-formats.rst   |  3 ++
 4 files changed, 167 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst

diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst 
b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
new file mode 100644
index ..2de1b1a0f517
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
@@ -0,0 +1,55 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-SDR-FMT-PCU16BE:
+
+**
+V4L2_SDR_FMT_PCU16BE ('PC16')
+**
+
+Planar complex unsigned 16-bit big endian IQ sample
+
+Description
+===
+
+This format contains a sequence of complex number samples. Each complex
+number consist of two parts called In-phase and Quadrature (IQ). Both I
+and Q are represented as a 16 bit unsigned big endian number stored in
+32 bit space. The remaining unused bits within the 32 bit space will be
+padded with 0. I value starts first and Q value starts at an offset
+equalling half of the buffer size (i.e.) offset = buffersize/2. Out of
+the 16 bits, bit 15:2 (14 bit) is data and bit 1:0 (2 bit) can be any
+value.
+
+**Byte Order.**
+Each cell is one byte.
+
+.. flat-table::
+:header-rows:  1
+:stub-columns: 0
+
+* -  Offset:
+  -  Byte B0
+  -  Byte B1
+  -  Byte B2
+  -  Byte B3
+* -  start + 0:
+  -  I'\ :sub:`0[13:6]`
+  -  I'\ :sub:`0[5:0]; B1[1:0]=pad`
+  -  pad
+  -  pad
+* -  start + 4:
+  -  I'\ :sub:`1[13:6]`
+  -  I'\ :sub:`1[5:0]; B1[1:0]=pad`
+  -  pad
+  -  pad
+* -  ...
+* - start + offset:
+  -  Q'\ :sub:`0[13:6]`
+  -  Q'\ :sub:`0[5:0]; B1[1:0]=pad`
+  -  pad
+  -  pad
+* - start + offset + 4:
+  -  Q'\ :sub:`1[13:6]`
+  -  Q'\ :sub:`1[5:0]; B1[1:0]=pad`
+  -  pad
+  -  pad
diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst 
b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
new file mode 100644
index ..da8b26bf6b95
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
@@ -0,0 +1,55 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-SDR-FMT-PCU18BE:
+
+**
+V4L2_SDR_FMT_PCU18BE ('PC18')
+**
+
+Planar complex unsigned 18-bit big endian IQ sample
+
+Description
+===
+
+This format contains a sequence of complex number samples. Each complex
+number consist of two parts called In-phase and Quadrature (IQ). Both I
+and Q are represented as a 18 bit unsigned big endian number stored in
+32 bit space. The remaining unused bits within the 32 bit space will be
+padded with 0. I value starts first and Q value starts at an offset
+equalling half of the buffer size (i.e.) offset = buffersize/2. Out of
+the 18 bits, bit 17:2 (16 bit) is data and bit 1:0 (2 bit) can be any
+value.
+
+**Byte Order.**
+Each cell is one byte.
+
+.. flat-table::
+:header-rows:  1
+:stub-columns: 0
+
+* -  Offset:
+  -  Byte B0
+  -  Byte B1
+  -  Byte B2
+  -  Byte B3
+* -  start + 0:
+  -  I'\ :sub:`0[17:10]`
+  -  I'\ :sub:`0[9:2]`
+  -  I'\ :sub:`0[1:0]; B2[5:0]=pad`
+  -  pad
+* -  start + 4:
+  -  I'\ :sub:`1[17:10]`
+  -  I'\ :sub:`1[9:2]`
+  -  I'\ :sub:`1[1:0]; B2[5:0]=pad`
+  -  pad
+* -  ...
+* - start + offset:
+  -  Q'\ :sub:`0[17:10]`
+  -  Q'\ :sub:`0[9:2]`
+  -  Q'\ :sub:`0[1:0]; B2[5:0]=pad`
+  -  pad
+* - start + offset + 4:
+  -  Q'\ :sub:`1[17:10]`
+  -  Q'\ :sub:`1[9:2]`
+  -  Q'\ :sub:`1[1:0]; B2[5:0]=pad`
+  -  pad
diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst 
b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst
new file mode 100644
index ..5499eed39477
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst
@@ -0,0 +1,54 @@
+.. -*- coding: utf-8; mode: rst -*-
+.. _V4L2-SDR-FMT-PCU20BE:
+
+**
+V4L2_SDR_FMT_PCU20BE ('PC20')
+**
+
+Planar complex unsigned 20-bit big endian IQ sample
+
+Description
+===
+
+This format contains a sequence of complex number samples. Each complex
+number consist of two parts called In-phase and Quadrature (IQ). Both I
+and Q are represented as a 20 bit unsigned big endian number stored in
+32 

[PATCH v5 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding

[Ramesh Shanmugasundaram]

Add binding documentation for Renesas R-Car Digital Radio Interface
(DRIF) controller.

Signed-off-by: Ramesh Shanmugasundaram 
---
v5:
 - Addressed Rob's comments on v4:
- Formatted compatible string entries.
- Removed "status".
- Removed board and SoC specific bindings classification example.
- Removed pinctrl nodes.
---
 .../devicetree/bindings/media/renesas,drif.txt | 177 +
 1 file changed, 177 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt

diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt 
b/Documentation/devicetree/bindings/media/renesas,drif.txt
new file mode 100644
index ..ec718c8bd937
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
@@ -0,0 +1,177 @@
+Renesas R-Car Gen3 Digital Radio Interface controller (DRIF)
+
+
+R-Car Gen3 DRIF is a SPI like receive only slave device. A general
+representation of DRIF interfacing with a master device is shown below.
+
++-++-+
+| |-SCK--->|CLK  |
+|   Master|-SS>|SYNC  DRIFn (slave)  |
+| |-SD0--->|D0   |
+| |-SD1--->|D1   |
++-++-+
+
+As per datasheet, each DRIF channel (drifn) is made up of two internal
+channels (drifn0 & drifn1). These two internal channels share the common
+CLK & SYNC. Each internal channel has its own dedicated resources like
+irq, dma channels, address space & clock. This internal split is not
+visible to the external master device.
+
+The device tree model represents each internal channel as a separate node.
+The internal channels sharing the CLK & SYNC are tied together by their
+phandles using a property called "renesas,bonding". For the rest of
+the documentation, unless explicitly stated, the word channel implies an
+internal channel.
+
+When both internal channels are enabled they need to be managed together
+as one (i.e.) they cannot operate alone as independent devices. Out of the
+two, one of them needs to act as a primary device that accepts common
+properties of both the internal channels. This channel is identified by a
+property called "renesas,primary-bond".
+
+To summarize,
+   - When both the internal channels that are bonded together are enabled,
+ the zeroth channel is selected as primary-bond. This channels accepts
+ properties common to all the members of the bond.
+   - When only one of the bonded channels need to be enabled, the property
+ "renesas,bonding" or "renesas,primary-bond" will have no effect. That
+ enabled channel can act alone as any other independent device.
+
+Required properties of an internal channel:
+---
+- compatible:  "renesas,r8a7795-drif" if DRIF controller is a part of R8A7795 
SoC.
+   "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible 
device.
+
+   When compatible with the generic version, nodes must list the
+   SoC-specific version corresponding to the platform first
+   followed by the generic version.
+
+- reg: offset and length of that channel.
+- interrupts: associated with that channel.
+- clocks: phandle and clock specifier of that channel.
+- clock-names: clock input name string: "fck".
+- dmas: phandles to the DMA channels.
+- dma-names: names of the DMA channel: "rx".
+- renesas,bonding: phandle to the other channel.
+
+Optional properties of an internal channel:
+---
+- power-domains: phandle to the respective power domain.
+
+Required properties of an internal channel when:
+   - It is the only enabled channel of the bond (or)
+   - If it acts as primary among enabled bonds
+
+- pinctrl-0: pin control group to be used for this channel.
+- pinctrl-names: must be "default".
+- renesas,primary-bond: empty property indicating the channel acts as primary
+   among the bonded channels.
+- port: child port node corresponding to the data input, in accordance with
+   the video interface bindings defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt. The port
+   node must contain at least one endpoint.
+
+Optional endpoint property:
+---
+- sync-active: Indicates sync signal polarity, 0/1 for low/high respectively.
+  This property maps to SYNCAC bit in the hardware manual. The
+  default is 1 (active high).
+
+Example:
+
+
+(1) Both internal channels enabled:
+---
+
+When interfacing with a third party tuner 

[PATCH v5 2/7] dt-bindings: media: Add MAX2175 binding description

[Ramesh Shanmugasundaram]

Add device tree binding documentation for MAX2175 RF to bits tuner
device.

Signed-off-by: Ramesh Shanmugasundaram 
Acked-by: Rob Herring 
---
v5:
 - pF in property-units.txt is renamed to pico-farads (Geert)
 - "maxim,refout-load-pF" is renamed to "maxim,refout-load".
---
 .../devicetree/bindings/media/i2c/max2175.txt  | 61 ++
 .../devicetree/bindings/property-units.txt |  1 +
 2 files changed, 62 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/max2175.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/max2175.txt 
b/Documentation/devicetree/bindings/media/i2c/max2175.txt
new file mode 100644
index ..dce421857efe
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt
@@ -0,0 +1,61 @@
+Maxim Integrated MAX2175 RF to Bits tuner
+-
+
+The MAX2175 IC is an advanced analog/digital hybrid-radio receiver with
+RF to Bits® front-end designed for software-defined radio solutions.
+
+Required properties:
+
+- compatible: "maxim,max2175" for MAX2175 RF-to-bits tuner.
+- clocks: phandle to the fixed xtal clock.
+- clock-names: name of the fixed xtal clock, shall be "xtal".
+- port: child port node corresponding to the I2S output, in accordance with
+   the video interface bindings defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt. The port
+   node must contain at least one endpoint.
+
+Optional properties:
+
+- maxim,master   : phandle to the master tuner if it is a slave. This
+   is used to define two tuners in diversity mode
+   (1 master, 1 slave). By default each tuner is an
+   individual master.
+- maxim,refout-load   : load capacitance value (in pico-farads) on reference
+   output drive level. The possible load values are:
+0 (default - refout disabled)
+   10
+   20
+   30
+   40
+   60
+   70
+- maxim,am-hiz-filter : empty property indicates the AM Hi-Z filter is used
+   in this hardware for AM antenna input.
+
+Example:
+
+
+Board specific DTS file
+
+/* Fixed XTAL clock node */
+maxim_xtal: clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <36864000>;
+};
+
+/* A tuner device instance under i2c bus */
+max2175_0: tuner@60 {
+   compatible = "maxim,max2175";
+   reg = <0x60>;
+   clocks = <_xtal>;
+   clock-names = "xtal";
+   maxim,refout-load = <10>;
+
+   port {
+   max2175_0_ep: endpoint {
+   remote-endpoint = <_rx_device>;
+   };
+   };
+
+};
diff --git a/Documentation/devicetree/bindings/property-units.txt 
b/Documentation/devicetree/bindings/property-units.txt
index 0849618a9df0..2d1d28843c96 100644
--- a/Documentation/devicetree/bindings/property-units.txt
+++ b/Documentation/devicetree/bindings/property-units.txt
@@ -30,6 +30,7 @@ Electricity
 -micro-ohms: micro Ohms
 -microwatt-hours: micro Watt-hours
 -microvolt : micro volts
+-pico-farads   : picofarads
 
 Temperature
 
-- 
2.12.2

[PATCH v5 4/7] media: Add new SDR formats PC16, PC18 & PC20

[Ramesh Shanmugasundaram]

This patch adds support for the three new SDR formats. These formats
were prefixed with "planar" indicating I & Q data are not interleaved
as in other formats. Here, I & Q data constitutes the top half and bottom
half of the received buffer respectively.

V4L2_SDR_FMT_PCU16BE - 14-bit complex (I & Q) unsigned big-endian sample
inside 16-bit. V4L2 FourCC: PC16

V4L2_SDR_FMT_PCU18BE - 16-bit complex (I & Q) unsigned big-endian sample
inside 18-bit. V4L2 FourCC: PC18

V4L2_SDR_FMT_PCU20BE - 18-bit complex (I & Q) unsigned big-endian sample
inside 20-bit. V4L2 FourCC: PC20

Signed-off-by: Ramesh Shanmugasundaram 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 3 +++
 include/uapi/linux/videodev2.h   | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index e5a2187381db..ca1e920d3e7c 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1229,6 +1229,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_SDR_FMT_CS8:  descr = "Complex S8"; break;
case V4L2_SDR_FMT_CS14LE:   descr = "Complex S14LE"; break;
case V4L2_SDR_FMT_RU12LE:   descr = "Real U12LE"; break;
+   case V4L2_SDR_FMT_PCU16BE:  descr = "Planar Complex U16BE"; break;
+   case V4L2_SDR_FMT_PCU18BE:  descr = "Planar Complex U18BE"; break;
+   case V4L2_SDR_FMT_PCU20BE:  descr = "Planar Complex U20BE"; break;
case V4L2_TCH_FMT_DELTA_TD16:   descr = "16-bit signed deltas"; break;
case V4L2_TCH_FMT_DELTA_TD08:   descr = "8-bit signed deltas"; break;
case V4L2_TCH_FMT_TU16: descr = "16-bit unsigned touch data"; 
break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 2b8feb86d09e..45cf7359822c 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -669,6 +669,9 @@ struct v4l2_pix_format {
 #define V4L2_SDR_FMT_CS8  v4l2_fourcc('C', 'S', '0', '8') /* complex 
s8 */
 #define V4L2_SDR_FMT_CS14LE   v4l2_fourcc('C', 'S', '1', '4') /* complex 
s14le */
 #define V4L2_SDR_FMT_RU12LE   v4l2_fourcc('R', 'U', '1', '2') /* real 
u12le */
+#define V4L2_SDR_FMT_PCU16BE v4l2_fourcc('P', 'C', '1', '6') /* planar 
complex u16be */
+#define V4L2_SDR_FMT_PCU18BE v4l2_fourcc('P', 'C', '1', '8') /* planar 
complex u18be */
+#define V4L2_SDR_FMT_PCU20BE v4l2_fourcc('P', 'C', '2', '0') /* planar 
complex u20be */
 
 /* Touch formats - used for Touch devices */
 #define V4L2_TCH_FMT_DELTA_TD16v4l2_fourcc('T', 'D', '1', '6') /* 
16-bit signed deltas */
-- 
2.12.2

[PATCH v5 3/7] media: i2c: max2175: Add MAX2175 support

[Ramesh Shanmugasundaram]

This patch adds driver support for the MAX2175 chip. This is Maxim
Integrated's RF to Bits tuner front end chip designed for software-defined
radio solutions. This driver exposes the tuner as a sub-device instance
with standard and custom controls to configure the device.

Signed-off-by: Ramesh Shanmugasundaram 
---
v5:
 - sck -> Sample clock is clarified in driver documentation (Hans)
 - "refout-load-pF" is renamed to "refout-load" as per updated bindings.
---
 Documentation/media/v4l-drivers/index.rst   |1 +
 Documentation/media/v4l-drivers/max2175.rst |   60 ++
 drivers/media/i2c/Kconfig   |4 +
 drivers/media/i2c/Makefile  |2 +
 drivers/media/i2c/max2175/Kconfig   |8 +
 drivers/media/i2c/max2175/Makefile  |4 +
 drivers/media/i2c/max2175/max2175.c | 1437 +++
 drivers/media/i2c/max2175/max2175.h |  108 ++
 8 files changed, 1624 insertions(+)
 create mode 100644 Documentation/media/v4l-drivers/max2175.rst
 create mode 100644 drivers/media/i2c/max2175/Kconfig
 create mode 100644 drivers/media/i2c/max2175/Makefile
 create mode 100644 drivers/media/i2c/max2175/max2175.c
 create mode 100644 drivers/media/i2c/max2175/max2175.h

diff --git a/Documentation/media/v4l-drivers/index.rst 
b/Documentation/media/v4l-drivers/index.rst
index a606d1cdac13..d8cade53d496 100644
--- a/Documentation/media/v4l-drivers/index.rst
+++ b/Documentation/media/v4l-drivers/index.rst
@@ -42,6 +42,7 @@ For more details see the file COPYING in the source 
distribution of Linux.
davinci-vpbe
fimc
ivtv
+max2175
meye
omap3isp
omap4_camera
diff --git a/Documentation/media/v4l-drivers/max2175.rst 
b/Documentation/media/v4l-drivers/max2175.rst
new file mode 100644
index ..94fb815f043b
--- /dev/null
+++ b/Documentation/media/v4l-drivers/max2175.rst
@@ -0,0 +1,60 @@
+Maxim Integrated MAX2175 RF to bits tuner driver
+
+
+The MAX2175 driver implements the following driver-specific controls:
+
+``V4L2_CID_MAX2175_I2S_ENABLE``
+---
+Enable/Disable I2S output of the tuner.
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 4
+
+* - ``(0)``
+  - I2S output is disabled.
+* - ``(1)``
+  - I2S output is enabled.
+
+``V4L2_CID_MAX2175_HSLS``
+-
+The high-side/low-side (HSLS) control of the tuner for a given band.
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 4
+
+* - ``(0)``
+  - The LO frequency position is below the desired frequency.
+* - ``(1)``
+  - The LO frequency position is above the desired frequency.
+
+``V4L2_CID_MAX2175_RX_MODE (menu)``
+---
+The Rx mode controls a number of preset parameters of the tuner like
+sample clock (sck), sampling rate etc. These multiple settings are
+provided under one single label called Rx mode in the datasheet. The
+list below shows the supported modes with a brief description.
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 4
+
+* - ``"Europe modes"``
+* - ``"FM 1.2" (0)``
+  - This configures FM band with a sample rate of 0.512 million
+samples/sec with a 10.24 MHz sck.
+* - ``"DAB 1.2" (1)``
+  - This configures VHF band with a sample rate of 2.048 million
+samples/sec with a 32.768 MHz sck.
+
+* - ``"North America modes"``
+* - ``"FM 1.0" (0)``
+  - This configures FM band with a sample rate of 0.7441875 million
+samples/sec with a 14.88375 MHz sck.
+* - ``"DAB 1.2" (1)``
+  - This configures FM band with a sample rate of 0.372 million
+samples/sec with a 7.441875 MHz sck.
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index b358d1a40688..d9fc1311794f 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -785,6 +785,10 @@ config VIDEO_SAA6752HS
  To compile this driver as a module, choose M here: the
  module will be called saa6752hs.
 
+comment "SDR tuner chips"
+
+source "drivers/media/i2c/max2175/Kconfig"
+
 comment "Miscellaneous helper chips"
 
 config VIDEO_THS7303
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 62323ec66be8..39567c415425 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_VIDEO_CX25840) += cx25840/
 obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/
 obj-y  += soc_camera/
 
+obj-$(CONFIG_SDR_MAX2175)  += max2175/
+
 obj-$(CONFIG_VIDEO_APTINA_PLL) += aptina-pll.o
 obj-$(CONFIG_VIDEO_TVAUDIO) += tvaudio.o
 obj-$(CONFIG_VIDEO_TDA7432) += tda7432.o
diff --git a/drivers/media/i2c/max2175/Kconfig 
b/drivers/media/i2c/max2175/Kconfig
new file mode 100644
index 

[PATCH v5 1/7] media: v4l2-ctrls: Reserve controls for MAX217X

[Ramesh Shanmugasundaram]

Reserve controls for MAX217X RF to Bits tuner family. These hybrid
radio receiver chips are highly programmable and hence reserving 32
controls.

Signed-off-by: Ramesh Shanmugasundaram 
Acked-by: Laurent Pinchart 
---
 include/uapi/linux/v4l2-controls.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/uapi/linux/v4l2-controls.h 
b/include/uapi/linux/v4l2-controls.h
index 0d2e1e01fbd5..83b28b41123f 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -180,6 +180,11 @@ enum v4l2_colorfx {
  * We reserve 16 controls for this driver. */
 #define V4L2_CID_USER_TC358743_BASE(V4L2_CID_USER_BASE + 0x1080)
 
+/* The base for the max217x driver controls.
+ * We reserve 32 controls for this driver
+ */
+#define V4L2_CID_USER_MAX217X_BASE (V4L2_CID_USER_BASE + 0x1090)
+
 /* MPEG-class control IDs */
 /* The MPEG controls are applicable to all codec controls
  * and the 'MPEG' part of the define is historical */
-- 
2.12.2

[PATCH v5 0/7] Add V4L2 SDR (DRIF & MAX2175) driver

[Ramesh Shanmugasundaram]

Hi Media, DT maintainers, All,

This patch set contains two drivers
 - Renesas R-Car Digital Radio Interface (DRIF) driver
 - Maxim's MAX2175 RF to Bits tuner driver

These patches were based on top of media-next repo
commit:6d95b3f24881c0fd0f345eca959a2a803a040930

These two drivers combined together expose a V4L2 SDR device that is compliant 
with the V4L2 framework [1]. Agreed review comments are incorporated in this 
series.

The rcar_drif device is modelled using "renesas,bonding" property. The 
discussion on this property is available here [2].

Change history:

v4 -> v5:
 - Minor documentation changes. Refer individual patches.

v3 -> v4:
 - Added ACKs
rcar_drif:
 - Incorporated a number of review comments from Laurent on DRIF driver.
 - Addressed comments from Rob and Laurent on bindings.
max2175:
 - Minor changes addressing Hans and Laurent's comments

v2 -> v3:
rcar_drif:
 - Reduced DRIF DT properties to expose tested I2S mode only (Hans - discussion 
on #v4l)
 - Fixed error path clean up of ctrl_hdl on rcar_drif

v1 -> v2:
 - SDR formats renamed as "planar" instead of sliced (Hans)
 - Documentation formatting correction (Laurent)

 rcar_drif:
 - DT model using "bonding" property
 - Addressed Laurent's coments on bindings - DT optional parameters rename & 
rework
 - Addressed Han's comments on driver
 - Addressed Geert's comments on DT

 max2175:
 - Avoided scaling using method proposed by Antti. Thanks
 - Bindings is a separate patch (Rob)
 - Addressed Rob's comment on bindings
 - Added Custom controls documentation (Laurent)

[1] v4l2-compliance report:
root@salvator-x:~# v4l2-compliance -S /dev/swradio0
v4l2-compliance SHA   : b514d615166bdc0901a4c71261b87db31e89f464

Driver Info:
Driver name   : rcar_drif
Card type : R-Car DRIF
Bus info  : platform:R-Car DRIF
Driver version: 4.11.0
Capabilities  : 0x8531
SDR Capture
Tuner
Read/Write
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x0531
SDR Capture
Tuner
Read/Write
Streaming
Extended Pix Format

Compliance test for device /dev/swradio0 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second sdr open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK
test VIDIOC_LOG_STATUS: OK

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK
test VIDIOC_G/S_FREQUENCY: OK
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 1

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 5 Private Controls: 3

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK (Not Supported)

Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK (Not Supported)

Test input 0:


Total: 43, Succeeded: 43, Failed: 0, Warnings: 0
root@salvator-x:~#

[2] "bonding" DT property discussion 

RE: [PATCH] dw9714: Initial driver for dw9714 VCM

[Mani, Rajmohan]

Hi Sakari,
Please see comments inline below.

> -Original Message-
> From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
> Sent: Tuesday, May 09, 2017 4:55 AM
> To: Mani, Rajmohan 
> Cc: linux-media@vger.kernel.org; mche...@kernel.org
> Subject: Re: [PATCH] dw9714: Initial driver for dw9714 VCM
> 
> Hi Rajmohan,
> 
> A few comments below...
> 
> On Sun, May 07, 2017 at 04:33:24AM -0700, rajmohan.m...@intel.com
> wrote:
> > From: Rajmohan Mani 
> >
> > DW9714 is a 10 bit DAC, designed for linear control of voice coil
> > motor.
> >
> > This driver creates a V4L2 subdevice and provides control to set the
> > desired focus.
> >
> > Signed-off-by: Rajmohan Mani 
> > ---
> >  drivers/media/i2c/Kconfig  |   9 ++
> >  drivers/media/i2c/Makefile |   1 +
> >  drivers/media/i2c/dw9714.c | 333
> > +
> >  3 files changed, 343 insertions(+)
> >  create mode 100644 drivers/media/i2c/dw9714.c
> >
> > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> > index fd181c9..4f0a7ad 100644
> > --- a/drivers/media/i2c/Kconfig
> > +++ b/drivers/media/i2c/Kconfig
> > @@ -300,6 +300,15 @@ config VIDEO_AD5820
> >   This is a driver for the AD5820 camera lens voice coil.
> >   It is used for example in Nokia N900 (RX-51).
> >
> > +config VIDEO_DW9714
> > +   tristate "DW9714 lens voice coil support"
> > +   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
> 
> You should also depend on VIDEO_V4L2_SUBDEV_API .

Ack

> 
> > +   ---help---
> > + This is a driver for the DW9714 camera lens voice coil.
> > + DW9714 is a 10 bit DAC with 120mA output current sink
> > + capability. This is designed for linear control of
> > + voice coil motors, controlled via I2C serial interface.
> > +
> >  config VIDEO_SAA7110
> > tristate "Philips SAA7110 video decoder"
> > depends on VIDEO_V4L2 && I2C
> > diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> > index 62323ec..987bd1f 100644
> > --- a/drivers/media/i2c/Makefile
> > +++ b/drivers/media/i2c/Makefile
> > @@ -21,6 +21,7 @@ obj-$(CONFIG_VIDEO_SAA7127) += saa7127.o
> >  obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o
> >  obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o
> >  obj-$(CONFIG_VIDEO_AD5820)  += ad5820.o
> > +obj-$(CONFIG_VIDEO_DW9714)  += dw9714.o
> >  obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
> >  obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
> >  obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o diff --git
> > a/drivers/media/i2c/dw9714.c b/drivers/media/i2c/dw9714.c new file
> > mode 100644 index 000..276d3f2
> > --- /dev/null
> > +++ b/drivers/media/i2c/dw9714.c
> > @@ -0,0 +1,333 @@
> > +/*
> > + * Copyright (c) 2015--2017 Intel Corporation.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > +version
> > + * 2 as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define DW9714_NAME"dw9714"
> > +#define DW9714_MAX_FOCUS_POS   1023
> > +#define DW9714_CTRL_STEPS  16  /* Keep this value power of 2
> */
> > +#define DW9714_CTRL_DELAY_US   1000
> > +/*
> > + * S[3:2] = 0x00, codes per step for "Linear Slope Control"
> > + * S[1:0] = 0x00, step period
> > + */
> > +#define DW9714_DEFAULT_S 0x0
> > +#define DW9714_VAL(data, s) (u16)((data) << 4 | (s))
> > +
> > +/* dw9714 device structure */
> > +struct dw9714_device {
> > +   struct i2c_client *client;
> > +   struct v4l2_ctrl_handler ctrls_vcm;
> > +   struct v4l2_subdev sd;
> > +   u16 current_val;
> > +};
> > +
> > +#define to_dw9714_vcm(_ctrl)   \
> > +   container_of(_ctrl->handler, struct dw9714_device, ctrls_vcm)
> > +
> > +static int dw9714_i2c_write(struct i2c_client *client, u16 data) {
> > +   const int num_msg = 1;
> > +   int ret;
> > +   u16 val = cpu_to_be16(data);
> > +   struct i2c_msg msg = {
> > +   .addr = client->addr,
> > +   .flags = 0,
> > +   .len = sizeof(val),
> > +   .buf = (u8 *) ,
> > +   };
> > +
> > +   ret = i2c_transfer(client->adapter, , num_msg);
> > +
> > +   /*One retry */
> > +   if (ret != num_msg)
> > +   ret = i2c_transfer(client->adapter, , num_msg);
> > +
> > +   if (ret != num_msg) {
> > +   dev_err(>dev, "I2C write fail fail\n");
> > +   return -EIO;
> > +   } else {
> > +   return 0;
> > +   }
> > +}
> > +
> > +static int dw9714_t_focus_vcm(struct dw9714_device *dw9714_dev, u16
> > +val) {
> > +   struct i2c_client *client = 

Re: [PATCH] dw9714: Initial driver for dw9714 VCM

[Tomasz Figa]

On Tue, May 9, 2017 at 9:22 PM, Tomasz Figa  wrote:
> +Rafael, Kevin and Ulf,
>
> On Tue, May 9, 2017 at 8:16 PM, Sakari Ailus  wrote:
>> Hi Tomasz,
>>
>> On Tue, May 09, 2017 at 07:38:26PM +0800, Tomasz Figa wrote:
>>> On Tue, May 9, 2017 at 6:40 PM, Sakari Ailus  wrote:
>>> > Hi Tomasz,
>>> >
>>> > On Tue, May 09, 2017 at 04:30:40PM +0800, Tomasz Figa wrote:
>>> >> Hi Sakari,
>>> >>
>>> >> On Tue, May 9, 2017 at 4:55 AM, Sakari Ailus  wrote:
>>> >> > Hi Rajmohan,
>>> >> >
>>> >> > A few comments below...
>>> >> >
>>> >> > On Sun, May 07, 2017 at 04:33:24AM -0700, rajmohan.m...@intel.com 
>>> >> > wrote:
>>> >> >> +#ifdef CONFIG_PM
>>> >> >> +
>>> >> >> +static int dw9714_runtime_suspend(struct device *dev)
>>> >> >> +{
>>> >> >> + return 0;
>>> >> >> +}
>>> >> >> +
>>> >> >> +static int dw9714_runtime_resume(struct device *dev)
>>> >> >> +{
>>> >> >> + return 0;
>>> >> >
>>> >> > I think it'd be fine to remove empty callbacks.
>>> >>
>>> >> It's actually a bit more complicated (if a PM domain is attached, the
>>> >> callbacks must be present), however in case of external I2C devices it
>>> >> should be fine indeed. However, AFAIK, pm_runtime_no_callbacks()
>>> >> should be called.
>>> >
>>> > I wonder if I'm missing something --- acpi_subsys_runtime_resume() first
>>> > calls acpi_dev_runtime_resume() and if all goes well, the proceeds to call
>>> > pm_generic_runtime_resume() which calls device's runtime_resume() if it's
>>> > non-NULL.
>>> >
>>> > In other words, having a runtime_resume() and runtime_suspend() callbacks
>>> > that return zero is equivalent of having neither of the callbacks.
>>>
>>> Ah, I missed the fact this device is instantiated by ACPI and it has
>>> different handling of runtime PM, which apparently means it doesn't
>>> use the code paths affected by the PM domain thing I mentioned.
>>
>> I have to admit I'm no expert in the topic but I'd presume that other
>> implementations should still maintain consistent behaviour towards drivers.
>> acpi_subsys_runtime_resume() is the PM domain runtime_resume() callback in
>> acpi_general_pm_domain.
>
> Let's see. For platform bus this seems to be reasonable indeed -
> __rpm_get_callback() will use the callbacks of PM domain, device type,
> device class or device bus, whichever is available first, in this
> order. Looking at platform_bus_type, the equivalent resume callback is
> pm_generic_runtime_resume() and it will indeed silently return 0 if
> there is no dev->pm->runtime_resume.
>
> However for I2C bus, i2c_bus_type doesn't seem to have .pm defined.
> Type and class are device/driver-specific things, so let's assume they
> don't have .pm set. If the driver doesn't have .pm, then the only way
> __rpm_get_callback() can return a non-NULL value is when
> dev->pm_domain is non NULL (which seems to be the ACPI case actually).
> Otherwise, if __rpm_get_callback() returns NULL, pm_runtime_get*()
> will fail with -ENOSYS. This is because rpm_resume() calls
> rpm_callback(callback, dev), where callback is the value returned by
> __rpm_get_callback() and rpm_callback() returns -ENOSYS if callback is
> NULL. This is where pm_runtime_no_callbacks() comes handy, as it
> bypasses the code getting and calling the callback, so it doesn't
> return the error anymore.
>
> There is however the other side of the coin. If
> pm_runtime_no_callbacks() is called, all kind of callbacks are
> bypassed, so even the PM domain code is not invoked. This is kind of
> tricky, because the driver must be now aware of whether it's running
> under a PM domain or not and call this pm_runtime_no_callbacks()
> depending on the outcome, to guarantee correct operation (PM domain
> callbacks must be called, even if device driver doesn't have its
> own)... Which IMHO doesn't make sense.
>
> I guess the correct way to proceed here would be adding .pm ops to
> i2c_bus_type, just as it's done with platform_bus_type.

Ah, sorry, I mean, the correct way to proceed here to make the
behavior consistent. For Raj's patch, since a) the driver needs to
restore the control value and b) it's supposed to be primarily
instantiated by ACPI, we shouldn't hit the above problem for now.

Best regards,
Tomasz

Re: [PATCH] dw9714: Initial driver for dw9714 VCM

[Tomasz Figa]

+Rafael, Kevin and Ulf,

On Tue, May 9, 2017 at 8:16 PM, Sakari Ailus  wrote:
> Hi Tomasz,
>
> On Tue, May 09, 2017 at 07:38:26PM +0800, Tomasz Figa wrote:
>> On Tue, May 9, 2017 at 6:40 PM, Sakari Ailus  wrote:
>> > Hi Tomasz,
>> >
>> > On Tue, May 09, 2017 at 04:30:40PM +0800, Tomasz Figa wrote:
>> >> Hi Sakari,
>> >>
>> >> On Tue, May 9, 2017 at 4:55 AM, Sakari Ailus  wrote:
>> >> > Hi Rajmohan,
>> >> >
>> >> > A few comments below...
>> >> >
>> >> > On Sun, May 07, 2017 at 04:33:24AM -0700, rajmohan.m...@intel.com wrote:
>> >> [snip]
>> >> >> + rval = v4l2_async_register_subdev(_dev->sd);
>> >> >> + if (rval < 0)
>> >> >> + goto err_cleanup;
>> >> >> +
>> >> >> + pm_runtime_enable(>dev);
>> >> >
>> >> > Getting PM runtime right doesn't seem to be easy. :-I
>> >> >
>> >> > pm_runtime_enable() alone doesn't do the trick. I wonder if adding
>> >> > pm_runtime_suspend() would do the trick.
>> >>
>> >> Is this something specific for I2C devices? For platform devices,
>> >> typically pm_runtime_enable() is the only thing you would need to do.
>> >
>> > I think you're right --- driver_probe_device() will call pm_request_idle()
>> > to the device right after probe. So indeed calling pm_runtime_enable() is
>> > enough.
>> >
>> >> >> +
>> >> >> + return 0;
>> >> >> +
>> >> >> +err_cleanup:
>> >> >> + dw9714_subdev_cleanup(dw9714_dev);
>> >> >> + dev_err(>dev, "Probe failed: %d\n", rval);
>> >> >> + return rval;
>> >> >> +}
>> >> >> +
>> >> >> +static int dw9714_remove(struct i2c_client *client)
>> >> >> +{
>> >> >> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
>> >> >> + struct dw9714_device *dw9714_dev = container_of(sd,
>> >> >> + struct 
>> >> >> dw9714_device,
>> >> >> + sd);
>> >> >> +
>> >> >> + pm_runtime_disable(>dev);
>> >> >> + dw9714_subdev_cleanup(dw9714_dev);
>> >> >> +
>> >> >> + return 0;
>> >> >> +}
>> >> >> +
>> >> >> +#ifdef CONFIG_PM
>> >> >> +
>> >> >> +static int dw9714_runtime_suspend(struct device *dev)
>> >> >> +{
>> >> >> + return 0;
>> >> >> +}
>> >> >> +
>> >> >> +static int dw9714_runtime_resume(struct device *dev)
>> >> >> +{
>> >> >> + return 0;
>> >> >
>> >> > I think it'd be fine to remove empty callbacks.
>> >>
>> >> It's actually a bit more complicated (if a PM domain is attached, the
>> >> callbacks must be present), however in case of external I2C devices it
>> >> should be fine indeed. However, AFAIK, pm_runtime_no_callbacks()
>> >> should be called.
>> >
>> > I wonder if I'm missing something --- acpi_subsys_runtime_resume() first
>> > calls acpi_dev_runtime_resume() and if all goes well, the proceeds to call
>> > pm_generic_runtime_resume() which calls device's runtime_resume() if it's
>> > non-NULL.
>> >
>> > In other words, having a runtime_resume() and runtime_suspend() callbacks
>> > that return zero is equivalent of having neither of the callbacks.
>>
>> Ah, I missed the fact this device is instantiated by ACPI and it has
>> different handling of runtime PM, which apparently means it doesn't
>> use the code paths affected by the PM domain thing I mentioned.
>
> I have to admit I'm no expert in the topic but I'd presume that other
> implementations should still maintain consistent behaviour towards drivers.
> acpi_subsys_runtime_resume() is the PM domain runtime_resume() callback in
> acpi_general_pm_domain.

Let's see. For platform bus this seems to be reasonable indeed -
__rpm_get_callback() will use the callbacks of PM domain, device type,
device class or device bus, whichever is available first, in this
order. Looking at platform_bus_type, the equivalent resume callback is
pm_generic_runtime_resume() and it will indeed silently return 0 if
there is no dev->pm->runtime_resume.

However for I2C bus, i2c_bus_type doesn't seem to have .pm defined.
Type and class are device/driver-specific things, so let's assume they
don't have .pm set. If the driver doesn't have .pm, then the only way
__rpm_get_callback() can return a non-NULL value is when
dev->pm_domain is non NULL (which seems to be the ACPI case actually).
Otherwise, if __rpm_get_callback() returns NULL, pm_runtime_get*()
will fail with -ENOSYS. This is because rpm_resume() calls
rpm_callback(callback, dev), where callback is the value returned by
__rpm_get_callback() and rpm_callback() returns -ENOSYS if callback is
NULL. This is where pm_runtime_no_callbacks() comes handy, as it
bypasses the code getting and calling the callback, so it doesn't
return the error anymore.

There is however the other side of the coin. If
pm_runtime_no_callbacks() is called, all kind of callbacks are
bypassed, so even the PM domain code is not invoked. This is kind of
tricky, because the driver must be now aware of whether it's running
under a PM domain or not and call this 

Re: [systemd-devel] [PATCH] 50-udev-default.rules.in: set correct group for mediaX/cecX

[Lennart Poettering]

On Tue, 09.05.17 09:40, Hans Verkuil (hverk...@xs4all.nl) wrote:

> The /dev/mediaX and /dev/cecX devices belong to the video group.
> Add two default rules for that.
> 
> The /dev/cecX devices were introduced in kernel 4.8 in staging and moved
> out of staging in 4.10. These devices support the HDMI CEC bus.
> 
> The /dev/mediaX devices are much older, but because they are not used very
> frequently nobody got around to adding this rule to systemd. They let the
> user control complex media pipelines.

Next time, please submit patches as PRs on github. I created one for
your patch now:

https://github.com/systemd/systemd/pull/5921

patch looks good btw.

Lennart

-- 
Lennart Poettering, Red Hat

[PATCH v5 2/2] v4l: vsp1: Repair suspend resume operations for video pipelines

[Kieran Bingham]

When a suspend/resume action is taken, the pipeline is reset and never
reconfigured.

To correct this, we establish a new flag pipe->configured and utilise
this to establish when we write a full configuration set to the current
display list.

Signed-off-by: Kieran Bingham 
---

Laurent,

Pasting your previous comments on this patch for convenience:

> As discussed face to face, I think a better approach would be to cache the 
> display list instead of recomputing it a resume time. However, given that 
> this 
> will require more work, I could be convinced to merge this patch in the 
> meantime. Let's check in a couple of weeks whether we will have moved forward 
> with display list caching in time for v4.12, and merge this patch otherwise.
> Your previous 

I agree that this could be cached - but that would be a larger development
reworking all of the display list handling. As such I think this patch still
provides progression, and we can rework if necessary when we have looked at
list reuse in more detail.

As I have just re-discovered - this patch requires the DRM/DU to be disabled
as that does not yet support suspend/resume on that side - (Another topic to
be revisited)

--
Kieran


 drivers/media/platform/vsp1/vsp1_drv.c   |  4 ++-
 drivers/media/platform/vsp1/vsp1_pipe.c  |  1 +-
 drivers/media/platform/vsp1/vsp1_pipe.h  |  4 +-
 drivers/media/platform/vsp1/vsp1_video.c | 56 ++---
 4 files changed, 31 insertions(+), 34 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 048446af5ae7..a77c40c2a39a 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -463,6 +463,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
 
 int vsp1_reset_wpf(struct vsp1_device *vsp1, unsigned int index)
 {
+   struct vsp1_rwpf *wpf = vsp1->wpf[index];
unsigned int timeout;
u32 status;
 
@@ -479,6 +480,9 @@ int vsp1_reset_wpf(struct vsp1_device *vsp1, unsigned int 
index)
usleep_range(1000, 2000);
}
 
+   if (wpf->pipe)
+   wpf->pipe->configured = false;
+
if (!timeout) {
dev_err(vsp1->dev, "failed to reset wpf.%u\n", index);
return -ETIMEDOUT;
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c 
b/drivers/media/platform/vsp1/vsp1_pipe.c
index edebf3fa926f..11b2dbf8f322 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/vsp1/vsp1_pipe.c
@@ -238,6 +238,7 @@ void vsp1_pipeline_init(struct vsp1_pipeline *pipe)
 
INIT_LIST_HEAD(>entities);
pipe->state = VSP1_PIPELINE_STOPPED;
+   pipe->configured = false;
 }
 
 /* Must be called with the pipe irqlock held. */
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h 
b/drivers/media/platform/vsp1/vsp1_pipe.h
index 91a784a13422..f715d2ba1044 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -62,6 +62,7 @@ enum vsp1_pipeline_state {
  * @pipe: the media pipeline
  * @irqlock: protects the pipeline state
  * @state: current state
+ * @configured: true if the pipeline has been set up for video streaming
  * @wq: wait queue to wait for state change completion
  * @frame_end: frame end interrupt handler
  * @lock: protects the pipeline use count and stream count
@@ -89,6 +90,7 @@ struct vsp1_pipeline {
 
spinlock_t irqlock;
enum vsp1_pipeline_state state;
+   bool configured;
wait_queue_head_t wq;
 
void (*frame_end)(struct vsp1_pipeline *pipe);
@@ -111,8 +113,6 @@ struct vsp1_pipeline {
 
struct list_head entities;
 
-   struct vsp1_dl_list *dl;
-
unsigned int div_size;
unsigned int partitions;
struct v4l2_rect partition;
diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index 3e9919c613fe..226e6e0b23aa 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -368,18 +368,14 @@ static void vsp1_video_frame_end(struct vsp1_pipeline 
*pipe,
pipe->buffers_ready |= 1 << video->pipe_index;
 }
 
-static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe)
+static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe,
+struct vsp1_dl_list *dl)
 {
struct vsp1_entity *entity;
 
/* Determine this pipelines sizes for image partitioning support. */
vsp1_video_pipeline_setup_partitions(pipe);
 
-   /* Prepare the display list. */
-   pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
-   if (!pipe->dl)
-   return -ENOMEM;
-
if (pipe->uds) {
struct vsp1_uds *uds = to_uds(>uds->subdev);
 
@@ -399,13 +395,15 @@ static int vsp1_video_setup_pipeline(struct vsp1_pipeline 
*pipe)
}
 
list_for_each_entry(entity, >entities, list_pipe) {

[PATCH v5 1/2] v4l: vsp1: Move vsp1_video_setup_pipeline()

[Kieran Bingham]

Move the static vsp1_video_setup_pipeline() function in preparation for
the callee updates so that the vsp1_video_pipeline_run() call can
configure pipelines following suspend resume actions.

This commit is just a code move for clarity performing no functional
change.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_video.c | 83 -
 1 file changed, 41 insertions(+), 42 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index eab3c3ea85d7..3e9919c613fe 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -368,6 +368,47 @@ static void vsp1_video_frame_end(struct vsp1_pipeline 
*pipe,
pipe->buffers_ready |= 1 << video->pipe_index;
 }
 
+static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe)
+{
+   struct vsp1_entity *entity;
+
+   /* Determine this pipelines sizes for image partitioning support. */
+   vsp1_video_pipeline_setup_partitions(pipe);
+
+   /* Prepare the display list. */
+   pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
+   if (!pipe->dl)
+   return -ENOMEM;
+
+   if (pipe->uds) {
+   struct vsp1_uds *uds = to_uds(>uds->subdev);
+
+   /* If a BRU is present in the pipeline before the UDS, the alpha
+* component doesn't need to be scaled as the BRU output alpha
+* value is fixed to 255. Otherwise we need to scale the alpha
+* component only when available at the input RPF.
+*/
+   if (pipe->uds_input->type == VSP1_ENTITY_BRU) {
+   uds->scale_alpha = false;
+   } else {
+   struct vsp1_rwpf *rpf =
+   to_rwpf(>uds_input->subdev);
+
+   uds->scale_alpha = rpf->fmtinfo->alpha;
+   }
+   }
+
+   list_for_each_entry(entity, >entities, list_pipe) {
+   vsp1_entity_route_setup(entity, pipe, pipe->dl);
+
+   if (entity->ops->configure)
+   entity->ops->configure(entity, pipe, pipe->dl,
+  VSP1_ENTITY_PARAMS_INIT);
+   }
+
+   return 0;
+}
+
 static void vsp1_video_pipeline_run_partition(struct vsp1_pipeline *pipe,
  struct vsp1_dl_list *dl)
 {
@@ -780,48 +821,6 @@ static void vsp1_video_buffer_queue(struct vb2_buffer *vb)
spin_unlock_irqrestore(>irqlock, flags);
 }
 
-static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe)
-{
-   struct vsp1_entity *entity;
-
-   /* Determine this pipelines sizes for image partitioning support. */
-   vsp1_video_pipeline_setup_partitions(pipe);
-
-   /* Prepare the display list. */
-   pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
-   if (!pipe->dl)
-   return -ENOMEM;
-
-   if (pipe->uds) {
-   struct vsp1_uds *uds = to_uds(>uds->subdev);
-
-   /*
-* If a BRU is present in the pipeline before the UDS, the alpha
-* component doesn't need to be scaled as the BRU output alpha
-* value is fixed to 255. Otherwise we need to scale the alpha
-* component only when available at the input RPF.
-*/
-   if (pipe->uds_input->type == VSP1_ENTITY_BRU) {
-   uds->scale_alpha = false;
-   } else {
-   struct vsp1_rwpf *rpf =
-   to_rwpf(>uds_input->subdev);
-
-   uds->scale_alpha = rpf->fmtinfo->alpha;
-   }
-   }
-
-   list_for_each_entry(entity, >entities, list_pipe) {
-   vsp1_entity_route_setup(entity, pipe, pipe->dl);
-
-   if (entity->ops->configure)
-   entity->ops->configure(entity, pipe, pipe->dl,
-  VSP1_ENTITY_PARAMS_INIT);
-   }
-
-   return 0;
-}
-
 static int vsp1_video_start_streaming(struct vb2_queue *vq, unsigned int count)
 {
struct vsp1_video *video = vb2_get_drv_priv(vq);
-- 
git-series 0.9.1

[PATCH v5 0/2] v4l: vsp1: Fix suspend/resume and race on M2M pipelines

[Kieran Bingham]

This small patchset helps rework the VSP1 driver to repair an issue on
suspend/resume operations whereby the pipeline does not get reconfigured after
it has been re-initialised following a resume operation.

Patch [1/2] is a code move only, with no functional change.
Patch [2/2] fixes the suspend/resume operations for video pipelines by marking
the new pipe configured flag as false, and configuring the pipe
during the vsp1_video_pipeline_run() call.

v5:
 - Rebased for v4.12-rc1
 - Dropped two patches from v4 as they are integrated already:
- BRU streamon race
- DRM scoped pipe->dl removal

v4:
 - Rework and separate out the BRU race back to v1 style implementation
 - Split BRU race and Suspend Resume fixes into separate commits.

v3:
 - Move configured=false from vsp1_device_init to vsp1_reset_wpf()
 - Clean up flag dereferencing with a local struct *

v2:
 - Refactor video pipeline configuration implementation to solve both suspend
   resume and the VSP BRU race in a single change

v1:
 - Original pipeline configuration rework

Kieran Bingham (2):
  v4l: vsp1: Move vsp1_video_setup_pipeline()
  v4l: vsp1: Repair suspend resume operations for video pipelines

 drivers/media/platform/vsp1/vsp1_drv.c   |   4 +-
 drivers/media/platform/vsp1/vsp1_pipe.c  |   1 +-
 drivers/media/platform/vsp1/vsp1_pipe.h  |   4 +-
 drivers/media/platform/vsp1/vsp1_video.c | 123 +++-
 4 files changed, 64 insertions(+), 68 deletions(-)

base-commit: 13e0988140374123bead1dd27c287354cb95108e
-- 
git-series 0.9.1

[PATCH] staging: media: cxd2099: Use __func__ macro in messages

[Alexandre Ghiti]

Replace hardcoded function names in print info with __func__.

Signed-off-by: Alexandre Ghiti 
---
 drivers/staging/media/cxd2099/cxd2099.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/media/cxd2099/cxd2099.c 
b/drivers/staging/media/cxd2099/cxd2099.c
index 18186d0..370ecb9 100644
--- a/drivers/staging/media/cxd2099/cxd2099.c
+++ b/drivers/staging/media/cxd2099/cxd2099.c
@@ -473,7 +473,7 @@ static int slot_shutdown(struct dvb_ca_en50221 *ca, int 
slot)
 {
struct cxd *ci = ca->data;
 
-   dev_info(>i2c->dev, "slot_shutdown\n");
+   dev_info(>i2c->dev, "%s\n", __func__);
mutex_lock(>lock);
write_regm(ci, 0x09, 0x08, 0x08);
write_regm(ci, 0x20, 0x80, 0x80); /* Reset CAM Mode */
@@ -564,7 +564,7 @@ static int read_data(struct dvb_ca_en50221 *ca, int slot, 
u8 *ebuf, int ecount)
campoll(ci);
mutex_unlock(>lock);
 
-   dev_info(>i2c->dev, "read_data\n");
+   dev_info(>i2c->dev, "%s\n", __func__);
if (!ci->dr)
return 0;
 
@@ -584,7 +584,7 @@ static int write_data(struct dvb_ca_en50221 *ca, int slot, 
u8 *ebuf, int ecount)
struct cxd *ci = ca->data;
 
mutex_lock(>lock);
-   dev_info(>i2c->dev, "write_data %d\n", ecount);
+   dev_info(>i2c->dev, "%s %d\n", __func__, ecount);
write_reg(ci, 0x0d, ecount >> 8);
write_reg(ci, 0x0e, ecount & 0xff);
write_block(ci, 0x11, ebuf, ecount);
-- 
2.1.4

Re: [PATCH] dw9714: Initial driver for dw9714 VCM

[Sakari Ailus]

Hi Tomasz,

On Tue, May 09, 2017 at 07:38:26PM +0800, Tomasz Figa wrote:
> On Tue, May 9, 2017 at 6:40 PM, Sakari Ailus  wrote:
> > Hi Tomasz,
> >
> > On Tue, May 09, 2017 at 04:30:40PM +0800, Tomasz Figa wrote:
> >> Hi Sakari,
> >>
> >> On Tue, May 9, 2017 at 4:55 AM, Sakari Ailus  wrote:
> >> > Hi Rajmohan,
> >> >
> >> > A few comments below...
> >> >
> >> > On Sun, May 07, 2017 at 04:33:24AM -0700, rajmohan.m...@intel.com wrote:
> >> [snip]
> >> >> + rval = v4l2_async_register_subdev(_dev->sd);
> >> >> + if (rval < 0)
> >> >> + goto err_cleanup;
> >> >> +
> >> >> + pm_runtime_enable(>dev);
> >> >
> >> > Getting PM runtime right doesn't seem to be easy. :-I
> >> >
> >> > pm_runtime_enable() alone doesn't do the trick. I wonder if adding
> >> > pm_runtime_suspend() would do the trick.
> >>
> >> Is this something specific for I2C devices? For platform devices,
> >> typically pm_runtime_enable() is the only thing you would need to do.
> >
> > I think you're right --- driver_probe_device() will call pm_request_idle()
> > to the device right after probe. So indeed calling pm_runtime_enable() is
> > enough.
> >
> >> >> +
> >> >> + return 0;
> >> >> +
> >> >> +err_cleanup:
> >> >> + dw9714_subdev_cleanup(dw9714_dev);
> >> >> + dev_err(>dev, "Probe failed: %d\n", rval);
> >> >> + return rval;
> >> >> +}
> >> >> +
> >> >> +static int dw9714_remove(struct i2c_client *client)
> >> >> +{
> >> >> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> >> >> + struct dw9714_device *dw9714_dev = container_of(sd,
> >> >> + struct 
> >> >> dw9714_device,
> >> >> + sd);
> >> >> +
> >> >> + pm_runtime_disable(>dev);
> >> >> + dw9714_subdev_cleanup(dw9714_dev);
> >> >> +
> >> >> + return 0;
> >> >> +}
> >> >> +
> >> >> +#ifdef CONFIG_PM
> >> >> +
> >> >> +static int dw9714_runtime_suspend(struct device *dev)
> >> >> +{
> >> >> + return 0;
> >> >> +}
> >> >> +
> >> >> +static int dw9714_runtime_resume(struct device *dev)
> >> >> +{
> >> >> + return 0;
> >> >
> >> > I think it'd be fine to remove empty callbacks.
> >>
> >> It's actually a bit more complicated (if a PM domain is attached, the
> >> callbacks must be present), however in case of external I2C devices it
> >> should be fine indeed. However, AFAIK, pm_runtime_no_callbacks()
> >> should be called.
> >
> > I wonder if I'm missing something --- acpi_subsys_runtime_resume() first
> > calls acpi_dev_runtime_resume() and if all goes well, the proceeds to call
> > pm_generic_runtime_resume() which calls device's runtime_resume() if it's
> > non-NULL.
> >
> > In other words, having a runtime_resume() and runtime_suspend() callbacks
> > that return zero is equivalent of having neither of the callbacks.
> 
> Ah, I missed the fact this device is instantiated by ACPI and it has
> different handling of runtime PM, which apparently means it doesn't
> use the code paths affected by the PM domain thing I mentioned.

I have to admit I'm no expert in the topic but I'd presume that other
implementations should still maintain consistent behaviour towards drivers.
acpi_subsys_runtime_resume() is the PM domain runtime_resume() callback in
acpi_general_pm_domain.

> 
> >
> >>
> >> >
> >> >> +}
> >> >> +
> >> >> +/* This function sets the vcm position, so it consumes least current */
> >> >> +static int dw9714_suspend(struct device *dev)
> >> >> +{
> >> >> + struct i2c_client *client = to_i2c_client(dev);
> >> >> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> >> >> + struct dw9714_device *dw9714_dev = container_of(sd,
> >> >> + struct 
> >> >> dw9714_device,
> >> >> + sd);
> >> >> + int ret, val;
> >> >> +
> >> >> + dev_dbg(dev, "%s\n", __func__);
> >> >> +
> >> >> + for (val = dw9714_dev->current_val & ~(DW9714_CTRL_STEPS - 1);
> >> >> +  val >= 0; val -= DW9714_CTRL_STEPS) {
> >> >> + ret = dw9714_i2c_write(client,
> >> >> +DW9714_VAL((u16) val, 
> >> >> DW9714_DEFAULT_S));
> >> >> + if (ret)
> >> >> + dev_err(dev, "%s I2C failure: %d", __func__, ret);
> >> >> + usleep_range(DW9714_CTRL_DELAY_US, DW9714_CTRL_DELAY_US + 
> >> >> 10);
> >> >> + }
> >> >> + return 0;
> >> >> +}
> >> >> +
> >> >> +/*
> >> >> + * This function sets the vcm position, so the focus position is set
> >> >> + * closer to the camera
> >> >> + */
> >> >> +static int dw9714_resume(struct device *dev)
> >> >> +{
> >> >> + struct i2c_client *client = to_i2c_client(dev);
> >> >> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> >> >> + struct dw9714_device *dw9714_dev = container_of(sd,
> >> >> + 

Greetings

[elodinewarlor...@ono.com]

 Dearest ,

I am constrained to contact you because of the maltreatment which I am 
receiving from my step mother. She planned to take away all my late 
father's treasurer and properties from me since the  unexpected death 
of my beloved Father ,my mother died 10years ago and I was left alone 
with my step mother to take care of me. Meanwhile I wanted to travel to 
Europe, but she hide  away my  international passport and other 
valuable documents.  Luckily she did not discover where I kept my
father's File which contained very important documents . Now I am 
presently staying in the Refugee Mission Camp in Burkina Faso. I am 
seeking for long term relationship and investment assistance. My father 
of blessed memory deposited the sum of US$ 27.5 Million in one bank 
here in Burkina Faso with my name as the next of kin. I had contacted 
the Bank to clear the deposit but the Branch Manager told me that being 
a refugee, my status according to the local law does not authorize me 
to carry out the operation ,However, he advised me to provide a trustee 
who will stand on my behalf. I had wanted to inform my stepmother about 
this deposit but I am afraid that she will not offer me anything after 
the release of the money ,I will give you details in my next mail after 
receiving your acceptance mail to help me,

Best Regards
Miss. Elodine I. Coulibaly

Re: [PATCH] dw9714: Initial driver for dw9714 VCM

[Tomasz Figa]

On Tue, May 9, 2017 at 6:40 PM, Sakari Ailus  wrote:
> Hi Tomasz,
>
> On Tue, May 09, 2017 at 04:30:40PM +0800, Tomasz Figa wrote:
>> Hi Sakari,
>>
>> On Tue, May 9, 2017 at 4:55 AM, Sakari Ailus  wrote:
>> > Hi Rajmohan,
>> >
>> > A few comments below...
>> >
>> > On Sun, May 07, 2017 at 04:33:24AM -0700, rajmohan.m...@intel.com wrote:
>> [snip]
>> >> + rval = v4l2_async_register_subdev(_dev->sd);
>> >> + if (rval < 0)
>> >> + goto err_cleanup;
>> >> +
>> >> + pm_runtime_enable(>dev);
>> >
>> > Getting PM runtime right doesn't seem to be easy. :-I
>> >
>> > pm_runtime_enable() alone doesn't do the trick. I wonder if adding
>> > pm_runtime_suspend() would do the trick.
>>
>> Is this something specific for I2C devices? For platform devices,
>> typically pm_runtime_enable() is the only thing you would need to do.
>
> I think you're right --- driver_probe_device() will call pm_request_idle()
> to the device right after probe. So indeed calling pm_runtime_enable() is
> enough.
>
>> >> +
>> >> + return 0;
>> >> +
>> >> +err_cleanup:
>> >> + dw9714_subdev_cleanup(dw9714_dev);
>> >> + dev_err(>dev, "Probe failed: %d\n", rval);
>> >> + return rval;
>> >> +}
>> >> +
>> >> +static int dw9714_remove(struct i2c_client *client)
>> >> +{
>> >> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
>> >> + struct dw9714_device *dw9714_dev = container_of(sd,
>> >> + struct 
>> >> dw9714_device,
>> >> + sd);
>> >> +
>> >> + pm_runtime_disable(>dev);
>> >> + dw9714_subdev_cleanup(dw9714_dev);
>> >> +
>> >> + return 0;
>> >> +}
>> >> +
>> >> +#ifdef CONFIG_PM
>> >> +
>> >> +static int dw9714_runtime_suspend(struct device *dev)
>> >> +{
>> >> + return 0;
>> >> +}
>> >> +
>> >> +static int dw9714_runtime_resume(struct device *dev)
>> >> +{
>> >> + return 0;
>> >
>> > I think it'd be fine to remove empty callbacks.
>>
>> It's actually a bit more complicated (if a PM domain is attached, the
>> callbacks must be present), however in case of external I2C devices it
>> should be fine indeed. However, AFAIK, pm_runtime_no_callbacks()
>> should be called.
>
> I wonder if I'm missing something --- acpi_subsys_runtime_resume() first
> calls acpi_dev_runtime_resume() and if all goes well, the proceeds to call
> pm_generic_runtime_resume() which calls device's runtime_resume() if it's
> non-NULL.
>
> In other words, having a runtime_resume() and runtime_suspend() callbacks
> that return zero is equivalent of having neither of the callbacks.

Ah, I missed the fact this device is instantiated by ACPI and it has
different handling of runtime PM, which apparently means it doesn't
use the code paths affected by the PM domain thing I mentioned.

>
>>
>> >
>> >> +}
>> >> +
>> >> +/* This function sets the vcm position, so it consumes least current */
>> >> +static int dw9714_suspend(struct device *dev)
>> >> +{
>> >> + struct i2c_client *client = to_i2c_client(dev);
>> >> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
>> >> + struct dw9714_device *dw9714_dev = container_of(sd,
>> >> + struct 
>> >> dw9714_device,
>> >> + sd);
>> >> + int ret, val;
>> >> +
>> >> + dev_dbg(dev, "%s\n", __func__);
>> >> +
>> >> + for (val = dw9714_dev->current_val & ~(DW9714_CTRL_STEPS - 1);
>> >> +  val >= 0; val -= DW9714_CTRL_STEPS) {
>> >> + ret = dw9714_i2c_write(client,
>> >> +DW9714_VAL((u16) val, 
>> >> DW9714_DEFAULT_S));
>> >> + if (ret)
>> >> + dev_err(dev, "%s I2C failure: %d", __func__, ret);
>> >> + usleep_range(DW9714_CTRL_DELAY_US, DW9714_CTRL_DELAY_US + 
>> >> 10);
>> >> + }
>> >> + return 0;
>> >> +}
>> >> +
>> >> +/*
>> >> + * This function sets the vcm position, so the focus position is set
>> >> + * closer to the camera
>> >> + */
>> >> +static int dw9714_resume(struct device *dev)
>> >> +{
>> >> + struct i2c_client *client = to_i2c_client(dev);
>> >> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
>> >> + struct dw9714_device *dw9714_dev = container_of(sd,
>> >> + struct 
>> >> dw9714_device,
>> >> + sd);
>> >> + int ret, val;
>> >> +
>> >> + dev_dbg(dev, "%s\n", __func__);
>> >> +
>> >> + for (val = dw9714_dev->current_val % DW9714_CTRL_STEPS;
>> >> +  val < dw9714_dev->current_val + DW9714_CTRL_STEPS - 1;
>> >> +  val += DW9714_CTRL_STEPS) {
>> >> + ret = dw9714_i2c_write(client,
>> >> +DW9714_VAL((u16) val, 
>> >> DW9714_DEFAULT_S));
>> >> + if (ret)
>> >> + 

Re: [patch, libv4l]: fix integer overflow

[Pavel Machek]

Hi!

> > This bit me while trying to use absolute exposure time on Nokia N900:
> > 
> > Can someone apply it to libv4l2 tree? Could I get some feedback on the
> > other patches? Is this the way to submit patches to libv4l2?
> 
> Yes, it is. But I do need a Signed-off-by from you.

Ok, that should be it for today.

I also put all but the first patch into the git, at

https://gitlab.com/tui/v4l-utils/tree/merge

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[patch, libv4l]: Introduce define for lookup table size

[Pavel Machek]

Make lookup table size configurable at compile-time.

Signed-off-by: Pavel Machek 

diff --git a/lib/libv4lconvert/processing/libv4lprocessing-priv.h 
b/lib/libv4lconvert/processing/libv4lprocessing-priv.h
index e4a29dd..55e1687 100644
--- a/lib/libv4lconvert/processing/libv4lprocessing-priv.h
+++ b/lib/libv4lconvert/processing/libv4lprocessing-priv.h
@@ -25,6 +25,8 @@
 #include "../libv4lsyscall-priv.h"
 
 #define V4L2PROCESSING_UPDATE_RATE 10
+/* Size of lookup tables */
+#define LSIZE 256
 
 struct v4lprocessing_data {
struct v4lcontrol_data *control;
@@ -32,15 +34,15 @@ struct v4lprocessing_data {
int do_process;
int controls_changed;
/* True if any of the lookup tables does not contain
-  linear 0-255 */
+  linear 0-LSIZE-1 */
int lookup_table_active;
/* Counts the number of processed frames until a
   V4L2PROCESSING_UPDATE_RATE overflow happens */
int lookup_table_update_counter;
/* RGB/BGR lookup tables */
-   unsigned char comp1[256];
-   unsigned char green[256];
-   unsigned char comp2[256];
+   unsigned char comp1[LSIZE];
+   unsigned char green[LSIZE];
+   unsigned char comp2[LSIZE];
/* Filter private data for filters which need it */
/* whitebalance.c data */
int green_avg;
@@ -48,7 +50,7 @@ struct v4lprocessing_data {
int comp2_avg;
/* gamma.c data */
int last_gamma;
-   unsigned char gamma_table[256];
+   unsigned char gamma_table[LSIZE];
/* autogain.c data */
int last_gain_correction;
 };
diff --git a/lib/libv4lconvert/processing/libv4lprocessing.c 
b/lib/libv4lconvert/processing/libv4lprocessing.c
index b061f50..6d0ad20 100644
--- a/lib/libv4lconvert/processing/libv4lprocessing.c
+++ b/lib/libv4lconvert/processing/libv4lprocessing.c
@@ -74,7 +74,7 @@ static void v4lprocessing_update_lookup_tables(struct 
v4lprocessing_data *data,
 {
int i;
 
-   for (i = 0; i < 256; i++) {
+   for (i = 0; i < LSIZE; i++) {
data->comp1[i] = i;
data->green[i] = i;
data->comp2[i] = i;
diff --git a/lib/libv4lconvert/processing/whitebalance.c 
b/lib/libv4lconvert/processing/whitebalance.c
index c74069a..2dd33c1 100644
--- a/lib/libv4lconvert/processing/whitebalance.c
+++ b/lib/libv4lconvert/processing/whitebalance.c
@@ -27,7 +27,7 @@
 #include "libv4lprocessing-priv.h"
 #include "../libv4lconvert-priv.h" /* for PIX_FMT defines */
 
-#define CLIP256(color) (((color) > 0xff) ? 0xff : (((color) < 0) ? 0 : 
(color)))
+#define CLIPLSIZE(color) (((color) > LSIZE) ? LSIZE : (((color) < 0) ? 0 : 
(color)))
 #define CLIP(color, min, max) (((color) > (max)) ? (max) : (((color) < (min)) 
? (min) : (color)))
 
 static int whitebalance_active(struct v4lprocessing_data *data)
@@ -111,10 +111,10 @@ static int whitebalance_calculate_lookup_tables_generic(
 
avg_avg = (data->green_avg + data->comp1_avg + data->comp2_avg) / 3;
 
-   for (i = 0; i < 256; i++) {
-   data->comp1[i] = CLIP256(data->comp1[i] * avg_avg / 
data->comp1_avg);
-   data->green[i] = CLIP256(data->green[i] * avg_avg / 
data->green_avg);
-   data->comp2[i] = CLIP256(data->comp2[i] * avg_avg / 
data->comp2_avg);
+   for (i = 0; i < LSIZE; i++) {
+   data->comp1[i] = CLIPLSIZE(data->comp1[i] * avg_avg / 
data->comp1_avg);
+   data->green[i] = CLIPLSIZE(data->green[i] * avg_avg / 
data->green_avg);
+   data->comp2[i] = CLIPLSIZE(data->comp2[i] * avg_avg / 
data->comp2_avg);
}
 
return 1;

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[patch, libv4l]: Add support for GRBG10 format conversion

[Pavel Machek]

Add support for GRBG10 format conversion.

Signed-off-by: Pavel Machek 

diff --git a/lib/libv4lconvert/libv4lconvert.c 
b/lib/libv4lconvert/libv4lconvert.c
index d3d8936..a7376b8 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -123,6 +123,7 @@ static const struct v4lconvert_pixfmt 
supported_src_pixfmts[] = {
{ V4L2_PIX_FMT_SGRBG8,   8,  8,  8, 1 },
{ V4L2_PIX_FMT_SRGGB8,   8,  8,  8, 1 },
{ V4L2_PIX_FMT_STV0680,  8,  8,  8, 1 },
+   { V4L2_PIX_FMT_SGRBG10, 16,  8,  8, 1 },
/* compressed bayer */
{ V4L2_PIX_FMT_SPCA561,  0,  9,  9, 1 },
{ V4L2_PIX_FMT_SN9C10X,  0,  9,  9, 1 },
@@ -694,6 +695,16 @@ unsigned char *v4lconvert_alloc_buffer(int needed,
return *buf;
 }
 
+static void v4lconvert_10to8(void *_src, unsigned char *dst, int width, int 
height)
+{
+   int i;
+   uint16_t *src = _src;
+   
+   for (i=0; i> 2;
+   }
+}
+
 int v4lconvert_oom_error(struct v4lconvert_data *data)
 {
V4LCONVERT_ERR("could not allocate memory\n");
@@ -867,7 +878,8 @@ static int v4lconvert_convert_pixfmt(struct v4lconvert_data 
*data,
 #endif
case V4L2_PIX_FMT_SN9C2028:
case V4L2_PIX_FMT_SQ905C:
-   case V4L2_PIX_FMT_STV0680: { /* Not compressed but needs some shuffling 
*/
+   case V4L2_PIX_FMT_STV0680:
+   case V4L2_PIX_FMT_SGRBG10: { /* Not compressed but needs some shuffling 
*/
unsigned char *tmpbuf;
struct v4l2_format tmpfmt = *fmt;
 
@@ -877,6 +889,11 @@ static int v4lconvert_convert_pixfmt(struct 
v4lconvert_data *data,
return v4lconvert_oom_error(data);
 
switch (src_pix_fmt) {
+   case V4L2_PIX_FMT_SGRBG10:
+   v4lconvert_10to8(src, tmpbuf, width, height);
+   tmpfmt.fmt.pix.pixelformat = V4L2_PIX_FMT_SGRBG8;
+   bytesperline = width;
+   break;
case V4L2_PIX_FMT_SPCA561:
v4lconvert_decode_spca561(src, tmpbuf, width, height);
tmpfmt.fmt.pix.pixelformat = V4L2_PIX_FMT_SGBRG8;

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[patch, libv4l]: fix typos

[Pavel Machek]

Fix random typos. (I searched, and the ALSA define does not seem to be
used anywhere, so this should not break anything.)

Signed-off-by: Pavel Machek 

diff --git a/lib/libv4l2/libv4l2.c b/lib/libv4l2/libv4l2.c
index 0ba0a88..1b06b6f 100644
--- a/lib/libv4l2/libv4l2.c
+++ b/lib/libv4l2/libv4l2.c
@@ -789,7 +789,7 @@ no_capture:
 
/* Note we always tell v4lconvert to optimize src fmt selection for
   our default fps, the only exception is the app explicitly selecting
-  a fram erate using the S_PARM ioctl after a S_FMT */
+  a frame rate using the S_PARM ioctl after a S_FMT */
if (devices[index].convert)
v4lconvert_set_fps(devices[index].convert, V4L2_DEFAULT_FPS);
v4l2_update_fps(index, );
diff --git a/utils/qv4l2/qv4l2.cpp b/utils/qv4l2/qv4l2.cpp
index bf8b85a..d1c89da 100644
--- a/utils/qv4l2/qv4l2.cpp
+++ b/utils/qv4l2/qv4l2.cpp
@@ -17,7 +17,7 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, 
USA.
  */
 
-#ifdef ENABLE_ASLA
+#ifdef ENABLE_ALSA
 extern "C" {
 #include "alsa_stream.h"
 }

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v2] dw9714: Initial driver for dw9714 VCM

[Sakari Ailus]

Hi Tomasz,

On Tue, May 09, 2017 at 04:44:13PM +0800, Tomasz Figa wrote:
...
> > +/* This function sets the vcm position, so it consumes least current */
> > +static int dw9714_suspend(struct device *dev)
> > +{
> > +   struct i2c_client *client = to_i2c_client(dev);
> > +   struct v4l2_subdev *sd = i2c_get_clientdata(client);
> > +   struct dw9714_device *dw9714_dev = container_of(sd,
> > +   struct 
> > dw9714_device,
> > +   sd);
> > +   int ret, val;
> > +
> > +   dev_dbg(dev, "%s\n", __func__);
> > +
> > +   for (val = dw9714_dev->current_val & ~(DW9714_CTRL_STEPS - 1);
> > +val >= 0; val -= DW9714_CTRL_STEPS) {
> > +   ret = dw9714_i2c_write(client,
> > +  DW9714_VAL((u16) val, 
> > DW9714_DEFAULT_S));
> > +   if (ret)
> > +   dev_err(dev, "%s I2C failure: %d", __func__, ret);
> > +   usleep_range(DW9714_CTRL_DELAY_US, DW9714_CTRL_DELAY_US + 
> > 10);
> 
> Is it necessary to change the value in such steps? If so, shouldn't
> the control handler behave in the same way, making sure that userspace
> does not request changes in bigger steps?

I believe the reason for this is to gradually move the lens to the resting
position in order to avoid an audible click that results from the lens
hitting the mechanical stopper.

That said, this chip should have ringing compensation so I wonder if
gradually setting the desired value necessary. I let Rajmohan to comment on
that.

What still might be needed is to delay powering the device off by a small
amount of time.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH] dw9714: Initial driver for dw9714 VCM

[Sakari Ailus]

Hi Tomasz,

On Tue, May 09, 2017 at 04:30:40PM +0800, Tomasz Figa wrote:
> Hi Sakari,
> 
> On Tue, May 9, 2017 at 4:55 AM, Sakari Ailus  wrote:
> > Hi Rajmohan,
> >
> > A few comments below...
> >
> > On Sun, May 07, 2017 at 04:33:24AM -0700, rajmohan.m...@intel.com wrote:
> [snip]
> >> + rval = v4l2_async_register_subdev(_dev->sd);
> >> + if (rval < 0)
> >> + goto err_cleanup;
> >> +
> >> + pm_runtime_enable(>dev);
> >
> > Getting PM runtime right doesn't seem to be easy. :-I
> >
> > pm_runtime_enable() alone doesn't do the trick. I wonder if adding
> > pm_runtime_suspend() would do the trick.
> 
> Is this something specific for I2C devices? For platform devices,
> typically pm_runtime_enable() is the only thing you would need to do.

I think you're right --- driver_probe_device() will call pm_request_idle()
to the device right after probe. So indeed calling pm_runtime_enable() is
enough.

> >> +
> >> + return 0;
> >> +
> >> +err_cleanup:
> >> + dw9714_subdev_cleanup(dw9714_dev);
> >> + dev_err(>dev, "Probe failed: %d\n", rval);
> >> + return rval;
> >> +}
> >> +
> >> +static int dw9714_remove(struct i2c_client *client)
> >> +{
> >> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> >> + struct dw9714_device *dw9714_dev = container_of(sd,
> >> + struct dw9714_device,
> >> + sd);
> >> +
> >> + pm_runtime_disable(>dev);
> >> + dw9714_subdev_cleanup(dw9714_dev);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +#ifdef CONFIG_PM
> >> +
> >> +static int dw9714_runtime_suspend(struct device *dev)
> >> +{
> >> + return 0;
> >> +}
> >> +
> >> +static int dw9714_runtime_resume(struct device *dev)
> >> +{
> >> + return 0;
> >
> > I think it'd be fine to remove empty callbacks.
> 
> It's actually a bit more complicated (if a PM domain is attached, the
> callbacks must be present), however in case of external I2C devices it
> should be fine indeed. However, AFAIK, pm_runtime_no_callbacks()
> should be called.

I wonder if I'm missing something --- acpi_subsys_runtime_resume() first
calls acpi_dev_runtime_resume() and if all goes well, the proceeds to call
pm_generic_runtime_resume() which calls device's runtime_resume() if it's
non-NULL.

In other words, having a runtime_resume() and runtime_suspend() callbacks
that return zero is equivalent of having neither of the callbacks.

> 
> >
> >> +}
> >> +
> >> +/* This function sets the vcm position, so it consumes least current */
> >> +static int dw9714_suspend(struct device *dev)
> >> +{
> >> + struct i2c_client *client = to_i2c_client(dev);
> >> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> >> + struct dw9714_device *dw9714_dev = container_of(sd,
> >> + struct dw9714_device,
> >> + sd);
> >> + int ret, val;
> >> +
> >> + dev_dbg(dev, "%s\n", __func__);
> >> +
> >> + for (val = dw9714_dev->current_val & ~(DW9714_CTRL_STEPS - 1);
> >> +  val >= 0; val -= DW9714_CTRL_STEPS) {
> >> + ret = dw9714_i2c_write(client,
> >> +DW9714_VAL((u16) val, 
> >> DW9714_DEFAULT_S));
> >> + if (ret)
> >> + dev_err(dev, "%s I2C failure: %d", __func__, ret);
> >> + usleep_range(DW9714_CTRL_DELAY_US, DW9714_CTRL_DELAY_US + 
> >> 10);
> >> + }
> >> + return 0;
> >> +}
> >> +
> >> +/*
> >> + * This function sets the vcm position, so the focus position is set
> >> + * closer to the camera
> >> + */
> >> +static int dw9714_resume(struct device *dev)
> >> +{
> >> + struct i2c_client *client = to_i2c_client(dev);
> >> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> >> + struct dw9714_device *dw9714_dev = container_of(sd,
> >> + struct dw9714_device,
> >> + sd);
> >> + int ret, val;
> >> +
> >> + dev_dbg(dev, "%s\n", __func__);
> >> +
> >> + for (val = dw9714_dev->current_val % DW9714_CTRL_STEPS;
> >> +  val < dw9714_dev->current_val + DW9714_CTRL_STEPS - 1;
> >> +  val += DW9714_CTRL_STEPS) {
> >> + ret = dw9714_i2c_write(client,
> >> +DW9714_VAL((u16) val, 
> >> DW9714_DEFAULT_S));
> >> + if (ret)
> >> + dev_err(dev, "%s I2C failure: %d", __func__, ret);
> >> + usleep_range(DW9714_CTRL_DELAY_US, DW9714_CTRL_DELAY_US + 
> >> 10);
> >> + }
> >> +
> >> + /* restore v4l2 control values */
> >> + ret = v4l2_ctrl_handler_setup(_dev->ctrls_vcm);
> >
> > Doesn't this need to be done for runtime_resume as well?
> 
> This driver doesn't seem to be doing any physical power off in its
> runtime_suspend and I don't expect an 

Re: [PATCH v2] dw9714: Initial driver for dw9714 VCM

[Tomasz Figa]

Hi Rajmohan,

Some comments below.

On Mon, May 8, 2017 at 10:36 PM, Rajmohan Mani  wrote:
> DW9714 is a 10 bit DAC, designed for linear
> control of voice coil motor.
>
> This driver creates a V4L2 subdevice and
> provides control to set the desired focus.
>
> Signed-off-by: Rajmohan Mani 
> ---
> Changes in v2:
> - Addressed review comments from Hans Verkuil
> - Fixed a debug message typo
> - Got rid of a return variable
> ---
>  drivers/media/i2c/Kconfig  |   9 ++
>  drivers/media/i2c/Makefile |   1 +
>  drivers/media/i2c/dw9714.c | 320 
> +
>  3 files changed, 330 insertions(+)
>  create mode 100644 drivers/media/i2c/dw9714.c
[snip]
> diff --git a/drivers/media/i2c/dw9714.c b/drivers/media/i2c/dw9714.c
> new file mode 100644
> index 000..cd6cde7
> --- /dev/null
> +++ b/drivers/media/i2c/dw9714.c
> @@ -0,0 +1,320 @@
> +/*
> + * Copyright (c) 2015--2017 Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DW9714_NAME"dw9714"
> +#define DW9714_MAX_FOCUS_POS   1023
> +#define DW9714_CTRL_STEPS  16  /* Keep this value power of 2 */

Because?

> +#define DW9714_CTRL_DELAY_US   1000
> +/*
> + * S[3:2] = 0x00, codes per step for "Linear Slope Control"
> + * S[1:0] = 0x00, step period
> + */
> +#define DW9714_DEFAULT_S 0x0
> +#define DW9714_VAL(data, s) (u16)((data) << 4 | (s))

Do we need this cast?

> +
> +/* dw9714 device structure */
> +struct dw9714_device {
> +   struct i2c_client *client;
> +   struct v4l2_ctrl_handler ctrls_vcm;
> +   struct v4l2_subdev sd;
> +   u16 current_val;
> +};
> +
> +#define to_dw9714_vcm(_ctrl)   \
> +   container_of(_ctrl->handler, struct dw9714_device, ctrls_vcm)

Please use a static inline function for type safety.

> +
> +static int dw9714_i2c_write(struct i2c_client *client, u16 data)
> +{
> +   const int num_msg = 1;
> +   int ret;
> +   u16 val = cpu_to_be16(data);
> +   struct i2c_msg msg = {
> +   .addr = client->addr,
> +   .flags = 0,
> +   .len = sizeof(val),
> +   .buf = (u8 *) ,
> +   };
> +
> +   ret = i2c_transfer(client->adapter, , num_msg);
> +
> +   /*One retry */
> +   if (ret != num_msg)
> +   ret = i2c_transfer(client->adapter, , num_msg);
> +
> +   if (ret != num_msg) {
> +   dev_err(>dev, "I2C write fail\n");
> +   return -EIO;
> +   }

I believe i2c_master_send() would simplify this function significantly.

> +   return 0;
> +}
> +
> +static int dw9714_t_focus_vcm(struct dw9714_device *dw9714_dev, u16 val)
> +{
> +   struct i2c_client *client = dw9714_dev->client;
> +
> +   dev_dbg(>dev, "Setting new value VCM: %d\n", val);
> +   dw9714_dev->current_val = val;
> +
> +   return dw9714_i2c_write(client, DW9714_VAL(val, DW9714_DEFAULT_S));
> +}
> +
> +static int dw9714_set_ctrl(struct v4l2_ctrl *ctrl)
> +{
> +   struct dw9714_device *dev_vcm = to_dw9714_vcm(ctrl);
> +
> +   if (ctrl->id == V4L2_CID_FOCUS_ABSOLUTE)
> +   return dw9714_t_focus_vcm(dev_vcm, ctrl->val);
> +
> +   return -EINVAL;
> +}
> +
> +static const struct v4l2_ctrl_ops dw9714_vcm_ctrl_ops = {
> +   .s_ctrl = dw9714_set_ctrl,
> +};
> +
> +static int dw9714_init_controls(struct dw9714_device *dev_vcm)
> +{
> +   struct v4l2_ctrl_handler *hdl = _vcm->ctrls_vcm;
> +   const struct v4l2_ctrl_ops *ops = _vcm_ctrl_ops;
> +   struct i2c_client *client = dev_vcm->client;
> +
> +   v4l2_ctrl_handler_init(hdl, 1);
> +
> +   v4l2_ctrl_new_std(hdl, ops, V4L2_CID_FOCUS_ABSOLUTE,
> + 0, DW9714_MAX_FOCUS_POS, 1, 0);
> +
> +   if (hdl->error)
> +   dev_err(>dev, "dw9714_init_controls fail\n");
> +   dev_vcm->sd.ctrl_handler = hdl;
> +   return hdl->error;
> +}
> +
> +static void dw9714_subdev_cleanup(struct dw9714_device *dw9714_dev)
> +{
> +   v4l2_ctrl_handler_free(_dev->ctrls_vcm);
> +   v4l2_async_unregister_subdev(_dev->sd);
> +   v4l2_device_unregister_subdev(_dev->sd);
> +   media_entity_cleanup(_dev->sd.entity);
> +}
> +
> +static int dw9714_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
> +{
> +   struct dw9714_device *dw9714_dev = container_of(sd,
> +   struct dw9714_device,
> +

Re: [PATCH] dw9714: Initial driver for dw9714 VCM

[Tomasz Figa]

Hi Sakari,

On Tue, May 9, 2017 at 4:55 AM, Sakari Ailus  wrote:
> Hi Rajmohan,
>
> A few comments below...
>
> On Sun, May 07, 2017 at 04:33:24AM -0700, rajmohan.m...@intel.com wrote:
[snip]
>> + rval = v4l2_async_register_subdev(_dev->sd);
>> + if (rval < 0)
>> + goto err_cleanup;
>> +
>> + pm_runtime_enable(>dev);
>
> Getting PM runtime right doesn't seem to be easy. :-I
>
> pm_runtime_enable() alone doesn't do the trick. I wonder if adding
> pm_runtime_suspend() would do the trick.

Is this something specific for I2C devices? For platform devices,
typically pm_runtime_enable() is the only thing you would need to do.

>
>> +
>> + return 0;
>> +
>> +err_cleanup:
>> + dw9714_subdev_cleanup(dw9714_dev);
>> + dev_err(>dev, "Probe failed: %d\n", rval);
>> + return rval;
>> +}
>> +
>> +static int dw9714_remove(struct i2c_client *client)
>> +{
>> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
>> + struct dw9714_device *dw9714_dev = container_of(sd,
>> + struct dw9714_device,
>> + sd);
>> +
>> + pm_runtime_disable(>dev);
>> + dw9714_subdev_cleanup(dw9714_dev);
>> +
>> + return 0;
>> +}
>> +
>> +#ifdef CONFIG_PM
>> +
>> +static int dw9714_runtime_suspend(struct device *dev)
>> +{
>> + return 0;
>> +}
>> +
>> +static int dw9714_runtime_resume(struct device *dev)
>> +{
>> + return 0;
>
> I think it'd be fine to remove empty callbacks.

It's actually a bit more complicated (if a PM domain is attached, the
callbacks must be present), however in case of external I2C devices it
should be fine indeed. However, AFAIK, pm_runtime_no_callbacks()
should be called.

>
>> +}
>> +
>> +/* This function sets the vcm position, so it consumes least current */
>> +static int dw9714_suspend(struct device *dev)
>> +{
>> + struct i2c_client *client = to_i2c_client(dev);
>> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
>> + struct dw9714_device *dw9714_dev = container_of(sd,
>> + struct dw9714_device,
>> + sd);
>> + int ret, val;
>> +
>> + dev_dbg(dev, "%s\n", __func__);
>> +
>> + for (val = dw9714_dev->current_val & ~(DW9714_CTRL_STEPS - 1);
>> +  val >= 0; val -= DW9714_CTRL_STEPS) {
>> + ret = dw9714_i2c_write(client,
>> +DW9714_VAL((u16) val, 
>> DW9714_DEFAULT_S));
>> + if (ret)
>> + dev_err(dev, "%s I2C failure: %d", __func__, ret);
>> + usleep_range(DW9714_CTRL_DELAY_US, DW9714_CTRL_DELAY_US + 10);
>> + }
>> + return 0;
>> +}
>> +
>> +/*
>> + * This function sets the vcm position, so the focus position is set
>> + * closer to the camera
>> + */
>> +static int dw9714_resume(struct device *dev)
>> +{
>> + struct i2c_client *client = to_i2c_client(dev);
>> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
>> + struct dw9714_device *dw9714_dev = container_of(sd,
>> + struct dw9714_device,
>> + sd);
>> + int ret, val;
>> +
>> + dev_dbg(dev, "%s\n", __func__);
>> +
>> + for (val = dw9714_dev->current_val % DW9714_CTRL_STEPS;
>> +  val < dw9714_dev->current_val + DW9714_CTRL_STEPS - 1;
>> +  val += DW9714_CTRL_STEPS) {
>> + ret = dw9714_i2c_write(client,
>> +DW9714_VAL((u16) val, 
>> DW9714_DEFAULT_S));
>> + if (ret)
>> + dev_err(dev, "%s I2C failure: %d", __func__, ret);
>> + usleep_range(DW9714_CTRL_DELAY_US, DW9714_CTRL_DELAY_US + 10);
>> + }
>> +
>> + /* restore v4l2 control values */
>> + ret = v4l2_ctrl_handler_setup(_dev->ctrls_vcm);
>
> Doesn't this need to be done for runtime_resume as well?

This driver doesn't seem to be doing any physical power off in its
runtime_suspend and I don't expect an I2C device to be put in a PM
domain, so possibly no need for it.

Best regards,
Tomasz

Re: [patch, libv4l]: fix integer overflow

[Pavel Machek]

Fix integer overflow with EXPOSURE_ABSOLUTE. This is problem for
example with Nokia N900.

Signed-off-by: Pavel Machek 

diff --git a/lib/libv4l2/libv4l2.c b/lib/libv4l2/libv4l2.c
index e795aee..189fc06 100644
--- a/lib/libv4l2/libv4l2.c
+++ b/lib/libv4l2/libv4l2.c
@@ -1776,7 +1776,7 @@ int v4l2_set_control(int fd, int cid, int value)
if (qctrl.type == V4L2_CTRL_TYPE_BOOLEAN)
ctrl.value = value ? 1 : 0;
else
-   ctrl.value = (value * (qctrl.maximum - qctrl.minimum) + 
32767) / 65535 +
+   ctrl.value = ((long long) value * (qctrl.maximum - 
qctrl.minimum) + 32767) / 65535 +
qctrl.minimum;
 
result = v4lconvert_vidioc_s_ctrl(devices[index].convert, 
);
@@ -1812,7 +1812,7 @@ int v4l2_get_control(int fd, int cid)
if (v4l2_propagate_ioctl(index, VIDIOC_G_CTRL, ))
return -1;
 
-   return ((ctrl.value - qctrl.minimum) * 65535 +
+   return (((long long) ctrl.value - qctrl.minimum) * 65535 +
(qctrl.maximum - qctrl.minimum) / 2) /
(qctrl.maximum - qctrl.minimum);
 }





-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

RE: [PATCH v2] dw9714: Initial driver for dw9714 VCM

[Mani, Rajmohan]

Hi Sakari,

> -Original Message-
> From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
> Sent: Tuesday, May 09, 2017 4:56 AM
> To: Mani, Rajmohan 
> Cc: linux-media@vger.kernel.org; mche...@kernel.org; hverk...@xs4all.nl
> Subject: Re: [PATCH v2] dw9714: Initial driver for dw9714 VCM
> 
> On Mon, May 08, 2017 at 07:36:48AM -0700, Rajmohan Mani wrote:
> > +   dev_dbg(dev, "%s ret = %d\n", __func__, ret);
> 
> Please remove such debug prints.

I have removed all dev_dbg prints and this will be addressed in v3 of this 
patch.
> 
> --
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi   XMPP: sai...@retiisi.org.uk

Re: [patch, libv4l]: fix integer overflow

[Pavel Machek]

On Tue 2017-05-09 08:32:20, Hans Verkuil wrote:
> On 05/09/2017 08:29 AM, Hans Verkuil wrote:
> > On 05/09/2017 12:28 AM, Pavel Machek wrote:
> >> Hi!
> >>
> >> This bit me while trying to use absolute exposure time on Nokia N900:
> >>
> >> Can someone apply it to libv4l2 tree? Could I get some feedback on the
> >> other patches? Is this the way to submit patches to libv4l2?
> > 
> > Yes, it is. But I do need a Signed-off-by from you.
> 
> I saw other patches from you for libv4l without a Signed-off-by. Can you
> check them and reply with the Signed-off-by line?

Thanks for quick reply. Yes, will do.

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[GIT PULL FOR v4.13] Add new STM32 DCMI camera driver

[Hans Verkuil]

The following changes since commit 3622d3e77ecef090b5111e3c5423313f11711dfa:

  [media] ov2640: print error if devm_*_optional*() fails (2017-04-25 07:08:21 
-0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git stm32

for you to fetch changes up to e48842d83dc4ccd0519f8721f42a3a89b2f2329c:

  stm32-dcmi: STM32 DCMI camera interface driver (2017-05-06 10:55:27 +0200)


Hugues Fruchet (2):
  dt-bindings: Document STM32 DCMI bindings
  stm32-dcmi: STM32 DCMI camera interface driver

 Documentation/devicetree/bindings/media/st,stm32-dcmi.txt |   45 ++
 drivers/media/platform/Kconfig|   12 +
 drivers/media/platform/Makefile   |2 +
 drivers/media/platform/stm32/Makefile |1 +
 drivers/media/platform/stm32/stm32-dcmi.c | 1403 
+
 5 files changed, 1463 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/st,stm32-dcmi.txt
 create mode 100644 drivers/media/platform/stm32/Makefile
 create mode 100644 drivers/media/platform/stm32/stm32-dcmi.c

[PATCH] 50-udev-default.rules.in: set correct group for mediaX/cecX

[Hans Verkuil]

The /dev/mediaX and /dev/cecX devices belong to the video group.
Add two default rules for that.

The /dev/cecX devices were introduced in kernel 4.8 in staging and moved
out of staging in 4.10. These devices support the HDMI CEC bus.

The /dev/mediaX devices are much older, but because they are not used very
frequently nobody got around to adding this rule to systemd. They let the
user control complex media pipelines.

---
 rules/50-udev-default.rules.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/rules/50-udev-default.rules.in b/rules/50-udev-default.rules.in
index 064f66a97..e55653302 100644
--- a/rules/50-udev-default.rules.in
+++ b/rules/50-udev-default.rules.in
@@ -34,6 +34,8 @@ SUBSYSTEM=="video4linux", GROUP="video"
 SUBSYSTEM=="graphics", GROUP="video"
 SUBSYSTEM=="drm", GROUP="video"
 SUBSYSTEM=="dvb", GROUP="video"
+SUBSYSTEM=="media", GROUP="video"
+SUBSYSTEM=="cec", GROUP="video"

 SUBSYSTEM=="sound", GROUP="audio", \
   OPTIONS+="static_node=snd/seq", OPTIONS+="static_node=snd/timer"
-- 
2.11.0

Re: [PATCH v5 2/8] [media] stm32-dcmi: STM32 DCMI camera interface driver

[Hugues FRUCHET]

Hi Hans,
It's OK, feel free to change.
BR
Hugues.


On 05/06/2017 10:54 AM, Hans Verkuil wrote:
> Hi Hugues,
>
> On 05/05/2017 05:31 PM, Hugues Fruchet wrote:
>> This V4L2 subdev driver enables Digital Camera Memory Interface (DCMI)
>> of STMicroelectronics STM32 SoC series.
>>
>> Reviewed-by: Hans Verkuil 
>> Signed-off-by: Yannick Fertre 
>> Signed-off-by: Hugues Fruchet 
>> ---
>>  drivers/media/platform/Kconfig|   12 +
>>  drivers/media/platform/Makefile   |2 +
>>  drivers/media/platform/stm32/Makefile |1 +
>>  drivers/media/platform/stm32/stm32-dcmi.c | 1403 
>> +
>>  4 files changed, 1418 insertions(+)
>>  create mode 100644 drivers/media/platform/stm32/Makefile
>>  create mode 100644 drivers/media/platform/stm32/stm32-dcmi.c
>>
>> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
>> index ac026ee..de6e18b 100644
>> --- a/drivers/media/platform/Kconfig
>> +++ b/drivers/media/platform/Kconfig
>> @@ -114,6 +114,18 @@ config VIDEO_S3C_CAMIF
>>To compile this driver as a module, choose M here: the module
>>will be called s3c-camif.
>>
>> +config VIDEO_STM32_DCMI
>> +tristate "Digital Camera Memory Interface (DCMI) support"
>
> Is it OK with you if I change this to:
>
>   tristate "STM32 Digital Camera Memory Interface (DCMI) support"
>
> Right now the text gives no indication that this driver is for an STM32 
> platform.
>
> No need to spin a new patch, just let me know you're OK with it and I'll make
> the change.
>
> Regards,
>
>   Hans
>
>> +depends on VIDEO_V4L2 && OF && HAS_DMA
>> +depends on ARCH_STM32 || COMPILE_TEST
>> +select VIDEOBUF2_DMA_CONTIG
>> +---help---
>> +  This module makes the STM32 Digital Camera Memory Interface (DCMI)
>> +  available as a v4l2 device.
>> +
>> +  To compile this driver as a module, choose M here: the module
>> +  will be called stm32-dcmi.
>> +
>>  source "drivers/media/platform/soc_camera/Kconfig"
>>  source "drivers/media/platform/exynos4-is/Kconfig"
>>  source "drivers/media/platform/am437x/Kconfig"

RE: [PATCH v2 0/2] rcar-du, vsp1: rcar-gen3: Add support for colorkey alpha blending

[Gheorghe, Alexandru]

Hello Daniel, Eric,

On Mon, Monday, May 8, 2017 9:29 PM +0200, Daniel Vetter wrote:
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: 8 mai 2017 21:30
> To: Eric Anholt 
> Cc: Gheorghe, Alexandru ;
> laurent.pinch...@ideasonboard.com; linux-renesas-...@vger.kernel.org;
> dri-de...@lists.freedesktop.org; linux-media@vger.kernel.org; geert@linux-
> m68k.org; sergei.shtyl...@cogentembedded.com
> Subject: Re: [PATCH v2 0/2] rcar-du, vsp1: rcar-gen3: Add support for
> colorkey alpha blending
> 
> On Mon, May 08, 2017 at 09:33:37AM -0700, Eric Anholt wrote:
> > Alexandru Gheorghe  writes:
> >
> > > Currently, rcar-du supports colorkeying  only for rcar-gen2 and it
> > > uses some hw capability of the display unit(DU) which is not available on
> gen3.
> > > In order to implement colorkeying for gen3 we need to use the
> > > colorkey capability of the VSPD, hence the need to change both
> > > drivers rcar-du and vsp1.
> > >
> > > This patchset had been developed and tested on top of
> > > v4.9/rcar-3.5.1 from
> > > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git
> >
> > A few questions:
> >
> > Are other drivers interested in supporting this property?  VC4 has the
> > 24-bit RGB colorkey, but I don't see YCBCR support.  Should it be
> > documented in a generic location?


As far as I identified  armada, i815, nouveau, rcar-du, vmwgfx drivers have 
this notion of colorkey. 
There could be other HW which don't have this implemented yet.

> >
> > Does your colorkey end up forcing alpha to 1 for the plane when it's
> > not matched?

I think this  behavior is HW dependent, on R-CAR Gen3, the alpha for pixel that 
don't match is not touch. 

> 
> I think generic color-key for plane compositioning would be nice, but I'm not
> sure that's possible due to differences in how the key works.

I'm thinking of starting from the drivers that do have this property and see if 
there is any common ground for a generic color-key property/ies

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Alex Gheorghe

[PATCH] 50-udev-default.rules.in: set correct group for mediaX/cecX

[Hans Verkuil]

The /dev/mediaX and /dev/cecX devices belong to the video group.
Add two default rules for that.

The /dev/cecX devices were introduced in kernel 4.8 in staging and moved
out of staging in 4.10. These devices support the HDMI CEC bus.

The /dev/mediaX devices are much older, but because they are not used very
frequently nobody got around to adding this rule to systemd. They let the
user control complex media pipelines.

---
 rules/50-udev-default.rules.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/rules/50-udev-default.rules.in b/rules/50-udev-default.rules.in
index 064f66a97..e55653302 100644
--- a/rules/50-udev-default.rules.in
+++ b/rules/50-udev-default.rules.in
@@ -34,6 +34,8 @@ SUBSYSTEM=="video4linux", GROUP="video"
 SUBSYSTEM=="graphics", GROUP="video"
 SUBSYSTEM=="drm", GROUP="video"
 SUBSYSTEM=="dvb", GROUP="video"
+SUBSYSTEM=="media", GROUP="video"
+SUBSYSTEM=="cec", GROUP="video"

 SUBSYSTEM=="sound", GROUP="audio", \
   OPTIONS+="static_node=snd/seq", OPTIONS+="static_node=snd/timer"
-- 
2.11.0

Re: [patch, libv4l]: fix integer overflow

[Hans Verkuil]

On 05/09/2017 08:29 AM, Hans Verkuil wrote:
> On 05/09/2017 12:28 AM, Pavel Machek wrote:
>> Hi!
>>
>> This bit me while trying to use absolute exposure time on Nokia N900:
>>
>> Can someone apply it to libv4l2 tree? Could I get some feedback on the
>> other patches? Is this the way to submit patches to libv4l2?
> 
> Yes, it is. But I do need a Signed-off-by from you.

I saw other patches from you for libv4l without a Signed-off-by. Can you
check them and reply with the Signed-off-by line?

Thanks!

Hans

> 
> Regards,
> 
>   Hans
> 
>>
>> Thanks,
>>  Pavel
>>
>> commit 0484e39ec05fdc644191e7c334a7ebfff9cb2ec5
>> Author: Pavel 
>> Date:   Mon May 8 21:52:02 2017 +0200
>>
>> Fix integer overflow with EXPOSURE_ABSOLUTE.
>>
>> diff --git a/lib/libv4l2/libv4l2.c b/lib/libv4l2/libv4l2.c
>> index e795aee..189fc06 100644
>> --- a/lib/libv4l2/libv4l2.c
>> +++ b/lib/libv4l2/libv4l2.c
>> @@ -1776,7 +1776,7 @@ int v4l2_set_control(int fd, int cid, int value)
>>  if (qctrl.type == V4L2_CTRL_TYPE_BOOLEAN)
>>  ctrl.value = value ? 1 : 0;
>>  else
>> -ctrl.value = (value * (qctrl.maximum - qctrl.minimum) + 
>> 32767) / 65535 +
>> +ctrl.value = ((long long) value * (qctrl.maximum - 
>> qctrl.minimum) + 32767) / 65535 +
>>  qctrl.minimum;
>>  
>>  result = v4lconvert_vidioc_s_ctrl(devices[index].convert, 
>> );
>> @@ -1812,7 +1812,7 @@ int v4l2_get_control(int fd, int cid)
>>  if (v4l2_propagate_ioctl(index, VIDIOC_G_CTRL, ))
>>  return -1;
>>  
>> -return ((ctrl.value - qctrl.minimum) * 65535 +
>> +return (((long long) ctrl.value - qctrl.minimum) * 65535 +
>>  (qctrl.maximum - qctrl.minimum) / 2) /
>>  (qctrl.maximum - qctrl.minimum);
>>  }
>>
>>
> 

Re: [patch, libv4l]: fix integer overflow

[Hans Verkuil]

On 05/09/2017 12:28 AM, Pavel Machek wrote:
> Hi!
> 
> This bit me while trying to use absolute exposure time on Nokia N900:
> 
> Can someone apply it to libv4l2 tree? Could I get some feedback on the
> other patches? Is this the way to submit patches to libv4l2?

Yes, it is. But I do need a Signed-off-by from you.

Regards,

Hans

> 
> Thanks,
>   Pavel
> 
> commit 0484e39ec05fdc644191e7c334a7ebfff9cb2ec5
> Author: Pavel 
> Date:   Mon May 8 21:52:02 2017 +0200
> 
> Fix integer overflow with EXPOSURE_ABSOLUTE.
> 
> diff --git a/lib/libv4l2/libv4l2.c b/lib/libv4l2/libv4l2.c
> index e795aee..189fc06 100644
> --- a/lib/libv4l2/libv4l2.c
> +++ b/lib/libv4l2/libv4l2.c
> @@ -1776,7 +1776,7 @@ int v4l2_set_control(int fd, int cid, int value)
>   if (qctrl.type == V4L2_CTRL_TYPE_BOOLEAN)
>   ctrl.value = value ? 1 : 0;
>   else
> - ctrl.value = (value * (qctrl.maximum - qctrl.minimum) + 
> 32767) / 65535 +
> + ctrl.value = ((long long) value * (qctrl.maximum - 
> qctrl.minimum) + 32767) / 65535 +
>   qctrl.minimum;
>  
>   result = v4lconvert_vidioc_s_ctrl(devices[index].convert, 
> );
> @@ -1812,7 +1812,7 @@ int v4l2_get_control(int fd, int cid)
>   if (v4l2_propagate_ioctl(index, VIDIOC_G_CTRL, ))
>   return -1;
>  
> - return ((ctrl.value - qctrl.minimum) * 65535 +
> + return (((long long) ctrl.value - qctrl.minimum) * 65535 +
>   (qctrl.maximum - qctrl.minimum) / 2) /
>   (qctrl.maximum - qctrl.minimum);
>  }
> 
>