Re: [PATCH v3 1/2] media: rc: introduce BPF_PROG_RAWIR_EVENT

[Y Song]

On Thu, May 17, 2018 at 2:45 PM, Sean Young  wrote:
> Hi,
>
> Again thanks for a thoughtful review. This will definitely will improve
> the code.
>
> On Thu, May 17, 2018 at 10:02:52AM -0700, Y Song wrote:
>> On Wed, May 16, 2018 at 2:04 PM, Sean Young  wrote:
>> > Add support for BPF_PROG_RAWIR_EVENT. This type of BPF program can call
>> > rc_keydown() to reported decoded IR scancodes, or rc_repeat() to report
>> > that the last key should be repeated.
>> >
>> > The bpf program can be attached to using the bpf(BPF_PROG_ATTACH) syscall;
>> > the target_fd must be the /dev/lircN device.
>> >
>> > Signed-off-by: Sean Young 
>> > ---
>> >  drivers/media/rc/Kconfig   |  13 ++
>> >  drivers/media/rc/Makefile  |   1 +
>> >  drivers/media/rc/bpf-rawir-event.c | 363 +
>> >  drivers/media/rc/lirc_dev.c|  24 ++
>> >  drivers/media/rc/rc-core-priv.h|  24 ++
>> >  drivers/media/rc/rc-ir-raw.c   |  14 +-
>> >  include/linux/bpf_rcdev.h  |  30 +++
>> >  include/linux/bpf_types.h  |   3 +
>> >  include/uapi/linux/bpf.h   |  55 -
>> >  kernel/bpf/syscall.c   |   7 +
>> >  10 files changed, 531 insertions(+), 3 deletions(-)
>> >  create mode 100644 drivers/media/rc/bpf-rawir-event.c
>> >  create mode 100644 include/linux/bpf_rcdev.h
>> >
>> > diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
>> > index eb2c3b6eca7f..2172d65b0213 100644
>> > --- a/drivers/media/rc/Kconfig
>> > +++ b/drivers/media/rc/Kconfig
>> > @@ -25,6 +25,19 @@ config LIRC
>> >passes raw IR to and from userspace, which is needed for
>> >IR transmitting (aka "blasting") and for the lirc daemon.
>> >
>> > +config BPF_RAWIR_EVENT
>> > +   bool "Support for eBPF programs attached to lirc devices"
>> > +   depends on BPF_SYSCALL
>> > +   depends on RC_CORE=y
>> > +   depends on LIRC
>> > +   help
>> > +  Allow attaching eBPF programs to a lirc device using the bpf(2)
>> > +  syscall command BPF_PROG_ATTACH. This is supported for raw IR
>> > +  receivers.
>> > +
>> > +  These eBPF programs can be used to decode IR into scancodes, for
>> > +  IR protocols not supported by the kernel decoders.
>> > +
>> >  menuconfig RC_DECODERS
>> > bool "Remote controller decoders"
>> > depends on RC_CORE
>> > diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
>> > index 2e1c87066f6c..74907823bef8 100644
>> > --- a/drivers/media/rc/Makefile
>> > +++ b/drivers/media/rc/Makefile
>> > @@ -5,6 +5,7 @@ obj-y += keymaps/
>> >  obj-$(CONFIG_RC_CORE) += rc-core.o
>> >  rc-core-y := rc-main.o rc-ir-raw.o
>> >  rc-core-$(CONFIG_LIRC) += lirc_dev.o
>> > +rc-core-$(CONFIG_BPF_RAWIR_EVENT) += bpf-rawir-event.o
>> >  obj-$(CONFIG_IR_NEC_DECODER) += ir-nec-decoder.o
>> >  obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
>> >  obj-$(CONFIG_IR_RC6_DECODER) += ir-rc6-decoder.o
>> > diff --git a/drivers/media/rc/bpf-rawir-event.c 
>> > b/drivers/media/rc/bpf-rawir-event.c
>> > new file mode 100644
>> > index ..7cb48b8d87b5
>> > --- /dev/null
>> > +++ b/drivers/media/rc/bpf-rawir-event.c
>> > @@ -0,0 +1,363 @@
>> > +// SPDX-License-Identifier: GPL-2.0
>> > +// bpf-rawir-event.c - handles bpf
>> > +//
>> > +// Copyright (C) 2018 Sean Young 
>> > +
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include "rc-core-priv.h"
>> > +
>> > +/*
>> > + * BPF interface for raw IR
>> > + */
>> > +const struct bpf_prog_ops rawir_event_prog_ops = {
>> > +};
>> > +
>> > +BPF_CALL_1(bpf_rc_repeat, struct bpf_rawir_event*, event)
>> > +{
>> > +   struct ir_raw_event_ctrl *ctrl;
>> > +
>> > +   ctrl = container_of(event, struct ir_raw_event_ctrl, 
>> > bpf_rawir_event);
>> > +
>> > +   rc_repeat(ctrl->dev);
>> > +
>> > +   return 0;
>> > +}
>> > +
>> > +static const struct bpf_func_proto rc_repeat_proto = {
>> > +   .func  = bpf_rc_repeat,
>> > +   .gpl_only  = true, /* rc_repeat is EXPORT_SYMBOL_GPL */
>> > +   .ret_type  = RET_INTEGER,
>> > +   .arg1_type = ARG_PTR_TO_CTX,
>> > +};
>> > +
>> > +BPF_CALL_4(bpf_rc_keydown, struct bpf_rawir_event*, event, u32, protocol,
>> > +  u32, scancode, u32, toggle)
>> > +{
>> > +   struct ir_raw_event_ctrl *ctrl;
>> > +
>> > +   ctrl = container_of(event, struct ir_raw_event_ctrl, 
>> > bpf_rawir_event);
>> > +
>> > +   rc_keydown(ctrl->dev, protocol, scancode, toggle != 0);
>> > +
>> > +   return 0;
>> > +}
>> > +
>> > +static const struct bpf_func_proto rc_keydown_proto = {
>> > +   .func  = bpf_rc_keydown,
>> > +   .gpl_only  = true, /* rc_keydown is EXPORT_SYMBOL_GPL */
>> > +   .ret_type  = RET_INTEGER,
>> > +   .arg1_type = ARG_PTR_TO_CTX,
>> > +   .arg2_type = ARG_ANYTHING,
>> > +   .arg3_type = ARG_ANYTHING,
>> > +   .arg4_type = ARG_ANYTHING,
>> > +};
>> > +
>> > +static 

Re: [PATCH 1/4] soc: qcom: mdt_loader: Add check to make scm calls

[Bjorn Andersson]

On Thu 17 May 04:32 PDT 2018, Vikash Garodia wrote:

> In order to invoke scm calls, ensure that the platform
> has the required support to invoke the scm calls in
> secure world.
> 
> Signed-off-by: Vikash Garodia 
> ---
>  drivers/soc/qcom/mdt_loader.c | 21 +
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
> index 17b314d..db55d53 100644
> --- a/drivers/soc/qcom/mdt_loader.c
> +++ b/drivers/soc/qcom/mdt_loader.c
> @@ -121,10 +121,12 @@ int qcom_mdt_load(struct device *dev, const struct 
> firmware *fw,
>   if (!fw_name)
>   return -ENOMEM;
>  
> - ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size);
> - if (ret) {
> - dev_err(dev, "invalid firmware metadata\n");
> - goto out;
> + if (qcom_scm_is_available()) {

qcom_scm_is_available() tells you if the qcom_scm driver has been
probed, not if your platform implements PAS.

Please add a DT property to tell the driver if it should require PAS or
not (the absence of such property should indicate PAS is required, for
backwards compatibility purposes). For the MDT loader we need to merge
the following patch to make this work:

https://patchwork.kernel.org/patch/10397889/ 

Regards,
Bjorn

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Fri May 18 05:00:11 CEST 2018
media-tree git hash:7e6b6b945272c20f6b78d319e07f27897a8373c9
media_build git hash:   d72556c0502c096c089c99c58ee4a02a13133361
v4l-utils git hash: e2038ec6451293787b929338c2a671c732b8693d
gcc version:i686-linux-gcc (GCC) 8.1.0
sparse version: 0.5.2-RC1
smatch version: 0.5.1
host hardware:  x86_64
host os:4.15.0-3-amd64

linux-git-arm-at91: WARNINGS
linux-git-arm-davinci: OK
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: WARNINGS
linux-git-arm-stm32: OK
linux-git-arm64: WARNINGS
linux-git-i686: WARNINGS
linux-git-mips: OK
linux-git-powerpc64: WARNINGS
linux-git-sh: OK
linux-git-x86_64: WARNINGS
Check COMPILE_TEST: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.101-i686: ERRORS
linux-3.0.101-x86_64: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.101-i686: ERRORS
linux-3.2.101-x86_64: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.113-i686: ERRORS
linux-3.4.113-x86_64: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.10-i686: ERRORS
linux-3.7.10-x86_64: ERRORS
linux-3.8.13-i686: ERRORS
linux-3.8.13-x86_64: ERRORS
linux-3.9.11-i686: ERRORS
linux-3.9.11-x86_64: ERRORS
linux-3.10.108-i686: ERRORS
linux-3.10.108-x86_64: ERRORS
linux-3.11.10-i686: ERRORS
linux-3.11.10-x86_64: ERRORS
linux-3.12.74-i686: ERRORS
linux-3.12.74-x86_64: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.79-i686: ERRORS
linux-3.14.79-x86_64: ERRORS
linux-3.15.10-i686: ERRORS
linux-3.15.10-x86_64: ERRORS
linux-3.16.56-i686: ERRORS
linux-3.16.56-x86_64: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.102-i686: ERRORS
linux-3.18.102-x86_64: ERRORS
linux-3.19.8-i686: ERRORS
linux-3.19.8-x86_64: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.51-i686: ERRORS
linux-4.1.51-x86_64: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.109-i686: ERRORS
linux-4.4.109-x86_64: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.10-i686: ERRORS
linux-4.7.10-x86_64: ERRORS
linux-4.8.17-i686: ERRORS
linux-4.8.17-x86_64: ERRORS
linux-4.9.91-i686: ERRORS
linux-4.9.91-x86_64: ERRORS
linux-4.10.17-i686: ERRORS
linux-4.10.17-x86_64: ERRORS
linux-4.11.12-i686: ERRORS
linux-4.11.12-x86_64: ERRORS
linux-4.12.14-i686: ERRORS
linux-4.12.14-x86_64: ERRORS
linux-4.13.16-i686: ERRORS
linux-4.13.16-x86_64: ERRORS
linux-4.14.31-i686: WARNINGS
linux-4.14.31-x86_64: WARNINGS
linux-4.15.14-i686: WARNINGS
linux-4.15.14-x86_64: WARNINGS
linux-4.16.8-i686: WARNINGS
linux-4.16.8-x86_64: WARNINGS
linux-4.17-rc4-i686: WARNINGS
linux-4.17-rc4-x86_64: WARNINGS
apps: OK
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

[no subject]

[Sherri Gallagher]

Please reply me back

6666777778888889999900000011111122222333333444445555556666666777778

[Qfjw]

Yunlong

Re: [PATCH 4/4] media: venus: add PIL support

[Trilok Soni]

Hi Vikash,

On 5/17/2018 4:32 AM, Vikash Garodia wrote:

This adds support to load the video firmware
and bring ARM9 out of reset. This is useful
for platforms which does not have trustzone
to reset the ARM9.


ARM9 = video core here? May be commit text needs little bit more detail.

  
+static int store_firmware_dev(struct device *dev, void *data)

+{
+   struct venus_core *core;
+
+   core = (struct venus_core *)data;


No need of casting.


+   if (!core)
+   return -EINVAL;
+
+   if (of_device_is_compatible(dev->of_node, "qcom,venus-pil-no-tz"))
+   core->fw.dev = dev;
+
+   return 0;
+}
+



  
-	ret = venus_boot(dev, core->res->fwname);

+   ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
+   if (ret)
+   goto err_runtime_disable;
+
+   /* Attempt to register child devices */
+   ret = device_for_each_child(dev, core, store_firmware_dev);
+


and not ret check needed?


+   ret = venus_boot(core);
if (ret)
goto err_runtime_disable;
  
  
  


--
---Trilok Soni
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH v3 1/2] media: rc: introduce BPF_PROG_RAWIR_EVENT

[Sean Young]

Hi,

Again thanks for a thoughtful review. This will definitely will improve
the code.

On Thu, May 17, 2018 at 10:02:52AM -0700, Y Song wrote:
> On Wed, May 16, 2018 at 2:04 PM, Sean Young  wrote:
> > Add support for BPF_PROG_RAWIR_EVENT. This type of BPF program can call
> > rc_keydown() to reported decoded IR scancodes, or rc_repeat() to report
> > that the last key should be repeated.
> >
> > The bpf program can be attached to using the bpf(BPF_PROG_ATTACH) syscall;
> > the target_fd must be the /dev/lircN device.
> >
> > Signed-off-by: Sean Young 
> > ---
> >  drivers/media/rc/Kconfig   |  13 ++
> >  drivers/media/rc/Makefile  |   1 +
> >  drivers/media/rc/bpf-rawir-event.c | 363 +
> >  drivers/media/rc/lirc_dev.c|  24 ++
> >  drivers/media/rc/rc-core-priv.h|  24 ++
> >  drivers/media/rc/rc-ir-raw.c   |  14 +-
> >  include/linux/bpf_rcdev.h  |  30 +++
> >  include/linux/bpf_types.h  |   3 +
> >  include/uapi/linux/bpf.h   |  55 -
> >  kernel/bpf/syscall.c   |   7 +
> >  10 files changed, 531 insertions(+), 3 deletions(-)
> >  create mode 100644 drivers/media/rc/bpf-rawir-event.c
> >  create mode 100644 include/linux/bpf_rcdev.h
> >
> > diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> > index eb2c3b6eca7f..2172d65b0213 100644
> > --- a/drivers/media/rc/Kconfig
> > +++ b/drivers/media/rc/Kconfig
> > @@ -25,6 +25,19 @@ config LIRC
> >passes raw IR to and from userspace, which is needed for
> >IR transmitting (aka "blasting") and for the lirc daemon.
> >
> > +config BPF_RAWIR_EVENT
> > +   bool "Support for eBPF programs attached to lirc devices"
> > +   depends on BPF_SYSCALL
> > +   depends on RC_CORE=y
> > +   depends on LIRC
> > +   help
> > +  Allow attaching eBPF programs to a lirc device using the bpf(2)
> > +  syscall command BPF_PROG_ATTACH. This is supported for raw IR
> > +  receivers.
> > +
> > +  These eBPF programs can be used to decode IR into scancodes, for
> > +  IR protocols not supported by the kernel decoders.
> > +
> >  menuconfig RC_DECODERS
> > bool "Remote controller decoders"
> > depends on RC_CORE
> > diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> > index 2e1c87066f6c..74907823bef8 100644
> > --- a/drivers/media/rc/Makefile
> > +++ b/drivers/media/rc/Makefile
> > @@ -5,6 +5,7 @@ obj-y += keymaps/
> >  obj-$(CONFIG_RC_CORE) += rc-core.o
> >  rc-core-y := rc-main.o rc-ir-raw.o
> >  rc-core-$(CONFIG_LIRC) += lirc_dev.o
> > +rc-core-$(CONFIG_BPF_RAWIR_EVENT) += bpf-rawir-event.o
> >  obj-$(CONFIG_IR_NEC_DECODER) += ir-nec-decoder.o
> >  obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
> >  obj-$(CONFIG_IR_RC6_DECODER) += ir-rc6-decoder.o
> > diff --git a/drivers/media/rc/bpf-rawir-event.c 
> > b/drivers/media/rc/bpf-rawir-event.c
> > new file mode 100644
> > index ..7cb48b8d87b5
> > --- /dev/null
> > +++ b/drivers/media/rc/bpf-rawir-event.c
> > @@ -0,0 +1,363 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// bpf-rawir-event.c - handles bpf
> > +//
> > +// Copyright (C) 2018 Sean Young 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include "rc-core-priv.h"
> > +
> > +/*
> > + * BPF interface for raw IR
> > + */
> > +const struct bpf_prog_ops rawir_event_prog_ops = {
> > +};
> > +
> > +BPF_CALL_1(bpf_rc_repeat, struct bpf_rawir_event*, event)
> > +{
> > +   struct ir_raw_event_ctrl *ctrl;
> > +
> > +   ctrl = container_of(event, struct ir_raw_event_ctrl, 
> > bpf_rawir_event);
> > +
> > +   rc_repeat(ctrl->dev);
> > +
> > +   return 0;
> > +}
> > +
> > +static const struct bpf_func_proto rc_repeat_proto = {
> > +   .func  = bpf_rc_repeat,
> > +   .gpl_only  = true, /* rc_repeat is EXPORT_SYMBOL_GPL */
> > +   .ret_type  = RET_INTEGER,
> > +   .arg1_type = ARG_PTR_TO_CTX,
> > +};
> > +
> > +BPF_CALL_4(bpf_rc_keydown, struct bpf_rawir_event*, event, u32, protocol,
> > +  u32, scancode, u32, toggle)
> > +{
> > +   struct ir_raw_event_ctrl *ctrl;
> > +
> > +   ctrl = container_of(event, struct ir_raw_event_ctrl, 
> > bpf_rawir_event);
> > +
> > +   rc_keydown(ctrl->dev, protocol, scancode, toggle != 0);
> > +
> > +   return 0;
> > +}
> > +
> > +static const struct bpf_func_proto rc_keydown_proto = {
> > +   .func  = bpf_rc_keydown,
> > +   .gpl_only  = true, /* rc_keydown is EXPORT_SYMBOL_GPL */
> > +   .ret_type  = RET_INTEGER,
> > +   .arg1_type = ARG_PTR_TO_CTX,
> > +   .arg2_type = ARG_ANYTHING,
> > +   .arg3_type = ARG_ANYTHING,
> > +   .arg4_type = ARG_ANYTHING,
> > +};
> > +
> > +static const struct bpf_func_proto *
> > +rawir_event_func_proto(enum bpf_func_id func_id, const struct bpf_prog 
> > *prog)
> > +{
> > +   switch (func_id) {
> > +   case BPF_FUNC_rc_repeat:
> > +   

Re: [ANN] Meeting to discuss improvements to support MC-based cameras on generic apps

[Nicolas Dufresne]

Le jeudi 17 mai 2018 à 16:07 -0300, Mauro Carvalho Chehab a écrit :
> Hi all,
> 
> The goal of this e-mail is to schedule a meeting in order to discuss
> improvements at the media subsystem in order to support complex
> camera
> hardware by usual apps.
> 
> The main focus here is to allow supporting devices with MC-based
> hardware connected to a camera.
> 
> In short, my proposal is to meet with the interested parties on
> solving
> this issue during the Open Source Summit in Japan, e. g. between
> June, 19-22, in Tokyo.
> 
> I'd like to know who is interested on joining us for such meeting,
> and to hear a proposal of themes for discussions.
> 
> I'm enclosing a detailed description of the problem, in order to
> allow the interested parties to be at the same page.

It's unlikely I'll be able to attend this meeting, but I'd like to
provide some initial input on this. Find inline some clarification on
why libv4l2 is disabled by default in Gst, as it's not just
performance.

A major aspect that is totally absent of this mail is PipeWire. With
the venue of sandboxed application, there is a need to control access
to cameras through a daemon. The same daemon is also used to control
access to screen capture on Wayland (instead of letting any random
application capture your screen, like on X11). The effort is lead by
the desktop team at RedHat (folks CCed). PipeWire already have V4L2
native support and is integrated in GStreamer already in a way that it
can totally replace the V4L2 capture component there. PipeWire is
plugin base, so more type of camera support (including proprietary
ones) can be added. Remote daemon can also provide streams, as this is
the case for compositors and screen casting. An extra benefit is that
you can have multiple application reading frames from the same camera.
It also allow sandboxed application (the do not have access to /dev) to
use the cameras. PipeWire is much more then that, but let's focus on
that.

This is the direction we are heading on the "generic" / Desktop Linux.
Porting Firefox and Chrome is obviously planed, as these beast are
clear candidate for being sand-boxed and requires screen share feature
for WebRTC.

In this context, proprietary or HW specific algorithm could be
implemented in userspace as PipeWire plugins, and then application will
automatically be enable to enumerate and use these. I'm not saying the
libv4l2 stuff is not needed short term, but it's just a short term
thing in my opinion.

> 
> Regards,
> Mauro
> 
> ---
> 
> 
> 1. Introduction
> ===
> 
> 1.1 V4L2 Kernel aspects
> ---
> 
> The media subsystem supports two types of devices:
> 
> - "traditional" media hardware, supported via V4L2 API. On such
> hardware, 
>   opening a single device node (usually /dev/video0) is enough to
> control
>   the entire device. We call it as devnode-based devices.
> 
> - Media-controller based devices. On those devices, there are several
>   /dev/video? nodes and several /dev/v4l2-subdev? nodes, plus a media
>   controller device node (usually /dev/media0).
>   We call it as mc-based devices. Controlling the hardware require
>   opening the media device (/dev/media0), setup the pipeline and
> adjust
>   the sub-devices via /dev/v4l2-subdev?. Only streaming is controlled
>   by /dev/video?.
> 
> All "standard" media applications, including open source ones
> (Camorama,
> Cheese, Xawtv, Firefox, Chromium, ...) and closed source ones
> (Skype, 
> Chrome, ...) supports devnode-based devices.
> 
> Support for mc-based devices currently require an specialized
> application 
> in order to prepare the device for its usage (setup pipelines, adjust
> hardware controls, etc). Once pipeline is set, the streaming goes via
> /dev/video?, although usually some /dev/v4l2-subdev? devnodes should
> also
> be opened, in order to implement algorithms designed to make video
> quality
> reasonable. On such devices, it is not uncommon that the device used
> by the
> application to be a random number (on OMAP3 driver, typically, is
> either
> /dev/video4 or /dev/video6).
> 
> One example of such hardware is at the OMAP3-based hardware:
> 
>   http://www.infradead.org/~mchehab/mc-next-gen/omap3-igepv2-with
> -tvp5150.png
> 
> On the picture, there's a graph with the hardware blocks in
> blue/dark/blue
> and the corresponding devnode interfaces in yellow.
> 
> The mc-based approach was taken when support for Nokia N9/N900
> cameras 
> was added (with has OMAP3 SoC). It is required because the camera
> hardware
> on SoC comes with a media processor (ISP), with does a lot more than
> just
> capturing, allowing complex algorithms to enhance image quality in
> runtime.
> Those algorithms are known as 3A - an acronym for 3 other acronyms:
> 
>   - AE (Auto Exposure);
>   - AF (Auto Focus);
>   - AWB (Auto White Balance).
> 
> Setting a camera with such ISPs are harder because the pipelines to
> be
> set actually depends the requirements for those 3A 

Re: [PATCH v3 2/2] bpf: add selftest for rawir_event type program

[Sean Young]

On Thu, May 17, 2018 at 10:17:59AM -0700, Y Song wrote:
> On Wed, May 16, 2018 at 2:04 PM, Sean Young  wrote:
> > This is simple test over rc-loopback.
> >
> > Signed-off-by: Sean Young 
> > ---
> >  tools/bpf/bpftool/prog.c  |   1 +
> >  tools/include/uapi/linux/bpf.h|  57 +++-
> >  tools/lib/bpf/libbpf.c|   1 +
> >  tools/testing/selftests/bpf/Makefile  |   8 +-
> >  tools/testing/selftests/bpf/bpf_helpers.h |   6 +
> >  tools/testing/selftests/bpf/test_rawir.sh |  37 +
> >  .../selftests/bpf/test_rawir_event_kern.c |  26 
> >  .../selftests/bpf/test_rawir_event_user.c | 130 ++
> >  8 files changed, 261 insertions(+), 5 deletions(-)
> >  create mode 100755 tools/testing/selftests/bpf/test_rawir.sh
> >  create mode 100644 tools/testing/selftests/bpf/test_rawir_event_kern.c
> >  create mode 100644 tools/testing/selftests/bpf/test_rawir_event_user.c
> 
> Could you copy include/uapi/linux/lirc.h file to tools directory as well.
> Otherwise, I will get the following compilation error:
> 
> gcc -Wall -O2 -I../../../include/uapi -I../../../lib
> -I../../../lib/bpf -I../../../../include/generated  -I../../../include
>test_rawir_event_user.c
> /home/yhs/work/bpf-next/tools/testing/selftests/bpf/libbpf.a -lcap
> -lelf -lrt -lpthread -o
> /home/yhs/work/bpf-next/tools/testing/selftests/bpf/test_rawir_event_user
> test_rawir_event_user.c: In function ‘main’:
> test_rawir_event_user.c:60:15: error: ‘LIRC_MODE_SCANCODE’ undeclared
> (first use in this function); did you mean ‘LIRC_MODE_LIRCCODE’?
> mode = LIRC_MODE_SCANCODE;
>^~
>LIRC_MODE_LIRCCODE
> test_rawir_event_user.c:60:15: note: each undeclared identifier is
> reported only once for each function it appears in
> test_rawir_event_user.c:93:29: error: storage size of ‘lsc’ isn’t known
> struct lirc_scancode lsc;
>  ^~~
> test_rawir_event_user.c:93:29: warning: unused variable ‘lsc’
> [-Wunused-variable]

Ah, good catch. Thanks for testing this.
> 
> >
> > diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c
> > index 9bdfdf2d3fbe..8889a4ee8577 100644
> > --- a/tools/bpf/bpftool/prog.c
> > +++ b/tools/bpf/bpftool/prog.c
> > @@ -71,6 +71,7 @@ static const char * const prog_type_name[] = {
> > [BPF_PROG_TYPE_SK_MSG]  = "sk_msg",
> > [BPF_PROG_TYPE_RAW_TRACEPOINT]  = "raw_tracepoint",
> > [BPF_PROG_TYPE_CGROUP_SOCK_ADDR] = "cgroup_sock_addr",
> > +   [BPF_PROG_TYPE_RAWIR_EVENT] = "rawir_event",
> >  };
> >
> >  static void print_boot_time(__u64 nsecs, char *buf, unsigned int size)
> > diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
> > index 1205d86a7a29..243e141e8a5b 100644
> > --- a/tools/include/uapi/linux/bpf.h
> > +++ b/tools/include/uapi/linux/bpf.h
> > @@ -141,6 +141,7 @@ enum bpf_prog_type {
> > BPF_PROG_TYPE_SK_MSG,
> > BPF_PROG_TYPE_RAW_TRACEPOINT,
> > BPF_PROG_TYPE_CGROUP_SOCK_ADDR,
> > +   BPF_PROG_TYPE_RAWIR_EVENT,
> >  };
> >
> >  enum bpf_attach_type {
> > @@ -158,6 +159,7 @@ enum bpf_attach_type {
> > BPF_CGROUP_INET6_CONNECT,
> > BPF_CGROUP_INET4_POST_BIND,
> > BPF_CGROUP_INET6_POST_BIND,
> > +   BPF_RAWIR_EVENT,
> > __MAX_BPF_ATTACH_TYPE
> >  };
> >
> > @@ -1829,7 +1831,6 @@ union bpf_attr {
> >   * Return
> >   * 0 on success, or a negative error in case of failure.
> >   *
> > - *
> >   * int bpf_fib_lookup(void *ctx, struct bpf_fib_lookup *params, int plen, 
> > u32 flags)
> >   * Description
> >   * Do FIB lookup in kernel tables using parameters in *params*.
> > @@ -1856,6 +1857,7 @@ union bpf_attr {
> >   * Egress device index on success, 0 if packet needs to 
> > continue
> >   * up the stack for further processing or a negative error in 
> > case
> >   * of failure.
> > + *
> >   * int bpf_sock_hash_update(struct bpf_sock_ops_kern *skops, struct 
> > bpf_map *map, void *key, u64 flags)
> >   * Description
> >   * Add an entry to, or update a sockhash *map* referencing 
> > sockets.
> > @@ -1902,6 +1904,35 @@ union bpf_attr {
> >   * egress otherwise). This is the only flag supported for now.
> >   * Return
> >   * **SK_PASS** on success, or **SK_DROP** on error.
> > + *
> > + * int bpf_rc_keydown(void *ctx, u32 protocol, u32 scancode, u32 toggle)
> > + * Description
> > + * Report decoded scancode with toggle value. For use in
> > + * BPF_PROG_TYPE_RAWIR_EVENT, to report a successfully
> > + * decoded scancode. This is will generate a keydown event,
> > + * and a keyup event once the scancode is no longer repeated.
> > + *
> > + * *ctx* pointer to bpf_rawir_event, *protocol* is decoded
> > + 

Re: [PATCHv13 25/28] vim2m: support requests

[Sakari Ailus]

Hi Hans,

On Thu, May 03, 2018 at 04:53:15PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Add support for requests to vim2m.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/media/platform/vim2m.c | 34 ++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/drivers/media/platform/vim2m.c b/drivers/media/platform/vim2m.c
> index a1b0bb08668d..7c86c711a4cd 100644
> --- a/drivers/media/platform/vim2m.c
> +++ b/drivers/media/platform/vim2m.c
> @@ -387,8 +387,26 @@ static void device_run(void *priv)
>   src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
>   dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
>  
> + /* Apply request controls if needed */
> + if (src_buf->vb2_buf.req_obj.req)
> + v4l2_ctrl_request_setup(src_buf->vb2_buf.req_obj.req,
> + >hdl);
> + if (dst_buf->vb2_buf.req_obj.req &&
> + dst_buf->vb2_buf.req_obj.req != src_buf->vb2_buf.req_obj.req)
> + v4l2_ctrl_request_setup(dst_buf->vb2_buf.req_obj.req,
> + >hdl);

This seems wrong: you're making use of control values from two *different*,
*unrelated* requests.

I'd rather like that we didn't end up a request API for the mem2mem devices
and another for the rest... albeit the kernel implementation could be the
same or similar, it's still the uAPI that would have differing semantics
between the two.

> +
>   device_process(ctx, src_buf, dst_buf);
>  
> + /* Complete request controls if needed */
> + if (src_buf->vb2_buf.req_obj.req)
> + v4l2_ctrl_request_complete(src_buf->vb2_buf.req_obj.req,
> + >hdl);
> + if (dst_buf->vb2_buf.req_obj.req &&
> + dst_buf->vb2_buf.req_obj.req != src_buf->vb2_buf.req_obj.req)
> + v4l2_ctrl_request_complete(dst_buf->vb2_buf.req_obj.req,
> + >hdl);
> +
>   /* Run a timer, which simulates a hardware irq  */
>   schedule_irq(dev, ctx->transtime);
>  }
> @@ -823,12 +841,21 @@ static void vim2m_stop_streaming(struct vb2_queue *q)
>   vbuf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
>   if (vbuf == NULL)
>   return;
> + v4l2_ctrl_request_complete(vbuf->vb2_buf.req_obj.req,
> +>hdl);
>   spin_lock_irqsave(>dev->irqlock, flags);
>   v4l2_m2m_buf_done(vbuf, VB2_BUF_STATE_ERROR);
>   spin_unlock_irqrestore(>dev->irqlock, flags);
>   }
>  }
>  
> +static void vim2m_buf_request_complete(struct vb2_buffer *vb)
> +{
> + struct vim2m_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
> +
> + v4l2_ctrl_request_complete(vb->req_obj.req, >hdl);
> +}
> +
>  static const struct vb2_ops vim2m_qops = {
>   .queue_setup = vim2m_queue_setup,
>   .buf_prepare = vim2m_buf_prepare,
> @@ -837,6 +864,7 @@ static const struct vb2_ops vim2m_qops = {
>   .stop_streaming  = vim2m_stop_streaming,
>   .wait_prepare= vb2_ops_wait_prepare,
>   .wait_finish = vb2_ops_wait_finish,
> + .buf_request_complete = vim2m_buf_request_complete,
>  };
>  
>  static int queue_init(void *priv, struct vb2_queue *src_vq, struct vb2_queue 
> *dst_vq)
> @@ -1003,6 +1031,11 @@ static const struct v4l2_m2m_ops m2m_ops = {
>   .job_abort  = job_abort,
>  };
>  
> +static const struct media_device_ops m2m_media_ops = {
> + .req_validate = vb2_request_validate,
> + .req_queue = vb2_m2m_request_queue,
> +};
> +
>  static int vim2m_probe(struct platform_device *pdev)
>  {
>   struct vim2m_dev *dev;
> @@ -1027,6 +1060,7 @@ static int vim2m_probe(struct platform_device *pdev)
>   dev->mdev.dev = >dev;
>   strlcpy(dev->mdev.model, "vim2m", sizeof(dev->mdev.model));
>   media_device_init(>mdev);
> + dev->mdev.ops = _media_ops;
>   dev->v4l2_dev.mdev = >mdev;
>   dev->pad[0].flags = MEDIA_PAD_FL_SINK;
>   dev->pad[1].flags = MEDIA_PAD_FL_SOURCE;

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v7 8/8] media: vsp1: Move video configuration to a cached dlb

[Laurent Pinchart]

Hi Kieran,

On Thursday, 17 May 2018 20:06:46 EEST Kieran Bingham wrote:
> On 17/05/18 15:35, Laurent Pinchart wrote:
> > On Monday, 30 April 2018 20:48:03 EEST Kieran Bingham wrote:
> >> On 07/04/18 01:23, Laurent Pinchart wrote:
> >>> On Thursday, 8 March 2018 02:05:31 EEST Kieran Bingham wrote:
>  We are now able to configure a pipeline directly into a local display
>  list body. Take advantage of this fact, and create a cacheable body to
>  store the configuration of the pipeline in the video object.
>  
>  vsp1_video_pipeline_run() is now the last user of the pipe->dl object.
>  Convert this function to use the cached video->config body and obtain a
>  local display list reference.
>  
>  Attach the video->config body to the display list when needed before
>  committing to hardware.
>  
>  The pipe object is marked as un-configured when resuming from a
>  suspend. This ensures that when the hardware is reset - our cached
>  configuration will be re-attached to the next committed DL.
>  
>  Signed-off-by: Kieran Bingham 
>  ---
>  
>  v3:
>   - 's/fragment/body/', 's/fragments/bodies/'
>   - video dlb cache allocation increased from 2 to 3 dlbs
>  
>  Our video DL usage now looks like the below output:
>  
>  dl->body0 contains our disposable runtime configuration. Max 41.
>  dl_child->body0 is our partition specific configuration. Max 12.
>  dl->bodies shows our constant configuration and LUTs.
>  
>    These two are LUT/CLU:
>   * dl->bodies[x]->num_entries 256 / max 256
>   * dl->bodies[x]->num_entries 4914 / max 4914
>  
>  Which shows that our 'constant' configuration cache is currently
>  utilised to a maximum of 64 entries.
>  
>  trace-cmd report | \
>  
>  grep max | sed 's/.*vsp1_dl_list_commit://g' | sort | uniq;
>    
>    dl->body0->num_entries 13 / max 128
>    dl->body0->num_entries 14 / max 128
>    dl->body0->num_entries 16 / max 128
>    dl->body0->num_entries 20 / max 128
>    dl->body0->num_entries 27 / max 128
>    dl->body0->num_entries 34 / max 128
>    dl->body0->num_entries 41 / max 128
>    dl_child->body0->num_entries 10 / max 128
>    dl_child->body0->num_entries 12 / max 128
>    dl->bodies[x]->num_entries 15 / max 128
>    dl->bodies[x]->num_entries 16 / max 128
>    dl->bodies[x]->num_entries 17 / max 128
>    dl->bodies[x]->num_entries 18 / max 128
>    dl->bodies[x]->num_entries 20 / max 128
>    dl->bodies[x]->num_entries 21 / max 128
>    dl->bodies[x]->num_entries 256 / max 256
>    dl->bodies[x]->num_entries 31 / max 128
>    dl->bodies[x]->num_entries 32 / max 128
>    dl->bodies[x]->num_entries 39 / max 128
>    dl->bodies[x]->num_entries 40 / max 128
>    dl->bodies[x]->num_entries 47 / max 128
>    dl->bodies[x]->num_entries 48 / max 128
>    dl->bodies[x]->num_entries 4914 / max 4914
>    dl->bodies[x]->num_entries 55 / max 128
>    dl->bodies[x]->num_entries 56 / max 128
>    dl->bodies[x]->num_entries 63 / max 128
>    dl->bodies[x]->num_entries 64 / max 128
> >>> 
> >>> This might be useful to capture in the main part of the commit message.
> >>> 
>  v4:
>   - Adjust pipe configured flag to be reset on resume rather than
>   suspend
>   - rename dl_child, dl_next
>   
>   drivers/media/platform/vsp1/vsp1_pipe.c  |  7 +++-
>   drivers/media/platform/vsp1/vsp1_pipe.h  |  4 +-
>   drivers/media/platform/vsp1/vsp1_video.c | 67 ++-
>   drivers/media/platform/vsp1/vsp1_video.h |  2 +-
>   4 files changed, 54 insertions(+), 26 deletions(-)
>  
>  diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c
>  b/drivers/media/platform/vsp1/vsp1_pipe.c index
>  5012643583b6..fa445b1a2e38
>  100644
>  --- a/drivers/media/platform/vsp1/vsp1_pipe.c
>  +++ b/drivers/media/platform/vsp1/vsp1_pipe.c
>  @@ -249,6 +249,7 @@ void vsp1_pipeline_run(struct vsp1_pipeline *pipe)
>   vsp1_write(vsp1, VI6_CMD(pipe->output->entity.index),
>  VI6_CMD_STRCMD);
>   pipe->state = VSP1_PIPELINE_RUNNING;
>  +pipe->configured = true;
>   }
>   
>   pipe->buffers_ready = 0;
>  @@ -470,6 +471,12 @@ void vsp1_pipelines_resume(struct vsp1_device
>  *vsp1)
>   continue;
>   
>   spin_lock_irqsave(>irqlock, flags);
>  +/*
>  + * The hardware may have been reset during a suspend 
>  and will
>  + * need a full reconfiguration
>  + */
> >>> 
> >>> s/reconfiguration/reconfiguration./
> >>> 
>  +

Re: [Intel-gfx] [PATCH v2 5/5] media: platform: Add Chrome OS EC CEC driver

[kbuild test robot]

Hi Neil,

I love your patch! Yet something to improve:

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.17-rc5 next-20180517]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Neil-Armstrong/Add-ChromeOS-EC-CEC-Support/20180516-180519
base:   git://linuxtv.org/media_tree.git master
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All errors (new ones prefixed by >>):

   drivers/media//platform/cros-ec-cec/cros-ec-cec.c: In function 
'cros_ec_cec_get_notifier':
>> drivers/media//platform/cros-ec-cec/cros-ec-cec.c:231:33: error: 
>> 'pci_bus_type' undeclared (first use in this function); did you mean 
>> 'pci_pcie_type'?
   d = bus_find_device_by_name(_bus_type, NULL,
^~~~
pci_pcie_type
   drivers/media//platform/cros-ec-cec/cros-ec-cec.c:231:33: note: each 
undeclared identifier is reported only once for each function it appears in

vim +231 drivers/media//platform/cros-ec-cec/cros-ec-cec.c

   217  
   218  static int cros_ec_cec_get_notifier(struct device *dev,
   219  struct cec_notifier **notify)
   220  {
   221  int i;
   222  
   223  for (i = 0 ; i < ARRAY_SIZE(cec_dmi_match_table) ; ++i) {
   224  const struct cec_dmi_match *m = _dmi_match_table[i];
   225  
   226  if (dmi_match(DMI_SYS_VENDOR, m->sys_vendor) &&
   227  dmi_match(DMI_PRODUCT_NAME, m->product_name)) {
   228  struct device *d;
   229  
   230  /* Find the device, bail out if not yet 
registered */
 > 231  d = bus_find_device_by_name(_bus_type, NULL,
   232  m->devname);
   233  if (!d)
   234  return -EPROBE_DEFER;
   235  
   236  *notify = cec_notifier_get_conn(d, m->conn);
   237  return 0;
   238  }
   239  }
   240  
   241  /* Hardware support must be added in the cec_dmi_match_table */
   242  dev_warn(dev, "CEC notifier not configured for this 
hardware\n");
   243  
   244  return -ENODEV;
   245  }
   246  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v10 8/8] media: vsp1: Move video configuration to a cached dlb

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Thursday, 17 May 2018 20:24:01 EEST Kieran Bingham wrote:
> We are now able to configure a pipeline directly into a local display
> list body. Take advantage of this fact, and create a cacheable body to
> store the configuration of the pipeline in the video object.
> 
> vsp1_video_pipeline_run() is now the last user of the pipe->dl object.
> Convert this function to use the cached video->config body and obtain a
> local display list reference.
> 
> Attach the video->config body to the display list when needed before
> committing to hardware.
> 
> The pipe object is marked as un-configured when resuming from a suspend.

Is this comment still valid ?

> This ensures that when the hardware is reset - our cached configuration
> will be re-attached to the next committed DL.
> 
> Our video DL usage now looks like the below output:
> 
> dl->body0 contains our disposable runtime configuration. Max 41.
> dl_child->body0 is our partition specific configuration. Max 12.
> dl->bodies shows our constant configuration and LUTs.
> 
>   These two are LUT/CLU:
>  * dl->bodies[x]->num_entries 256 / max 256
>  * dl->bodies[x]->num_entries 4914 / max 4914
> 
> Which shows that our 'constant' configuration cache is currently
> utilised to a maximum of 64 entries.
> 
> trace-cmd report | \
> grep max | sed 's/.*vsp1_dl_list_commit://g' | sort | uniq;
> 
>   dl->body0->num_entries 13 / max 128
>   dl->body0->num_entries 14 / max 128
>   dl->body0->num_entries 16 / max 128
>   dl->body0->num_entries 20 / max 128
>   dl->body0->num_entries 27 / max 128
>   dl->body0->num_entries 34 / max 128
>   dl->body0->num_entries 41 / max 128
>   dl_child->body0->num_entries 10 / max 128
>   dl_child->body0->num_entries 12 / max 128
>   dl->bodies[x]->num_entries 15 / max 128
>   dl->bodies[x]->num_entries 16 / max 128
>   dl->bodies[x]->num_entries 17 / max 128
>   dl->bodies[x]->num_entries 18 / max 128
>   dl->bodies[x]->num_entries 20 / max 128
>   dl->bodies[x]->num_entries 21 / max 128
>   dl->bodies[x]->num_entries 256 / max 256
>   dl->bodies[x]->num_entries 31 / max 128
>   dl->bodies[x]->num_entries 32 / max 128
>   dl->bodies[x]->num_entries 39 / max 128
>   dl->bodies[x]->num_entries 40 / max 128
>   dl->bodies[x]->num_entries 47 / max 128
>   dl->bodies[x]->num_entries 48 / max 128
>   dl->bodies[x]->num_entries 4914 / max 4914
>   dl->bodies[x]->num_entries 55 / max 128
>   dl->bodies[x]->num_entries 56 / max 128
>   dl->bodies[x]->num_entries 63 / max 128
>   dl->bodies[x]->num_entries 64 / max 128
> 
> Signed-off-by: Kieran Bingham 
> ---
> v10:
>  - Removed pipe->configured flag, and use
>pipe->state == VSP1_PIPELINE_STOPPED instead.
> 
> v8:
>  - Fix comments
>  - Rename video->pipe_config -> video->stream_config
> 
> v4:
>  - Adjust pipe configured flag to be reset on resume rather than suspend
>  - rename dl_child, dl_next
> 
> v3:
>  - 's/fragment/body/', 's/fragments/bodies/'
>  - video dlb cache allocation increased from 2 to 3 dlbs
> 
>  drivers/media/platform/vsp1/vsp1_pipe.h  |  3 +-
>  drivers/media/platform/vsp1/vsp1_video.c | 67 +++--
>  drivers/media/platform/vsp1/vsp1_video.h |  2 +-
>  3 files changed, 43 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h
> b/drivers/media/platform/vsp1/vsp1_pipe.h index e00010693eef..be6ecab3cbed
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_pipe.h
> +++ b/drivers/media/platform/vsp1/vsp1_pipe.h
> @@ -102,7 +102,6 @@ struct vsp1_partition {
>   * @uds: UDS entity, if present
>   * @uds_input: entity at the input of the UDS, if the UDS is present
>   * @entities: list of entities in the pipeline
> - * @dl: display list associated with the pipeline
>   * @partitions: The number of partitions used to process one frame
>   * @partition: The current partition for configuration to process
>   * @part_table: The pre-calculated partitions used by the pipeline
> @@ -139,8 +138,6 @@ struct vsp1_pipeline {
>*/
>   struct list_head entities;
> 
> - struct vsp1_dl_list *dl;
> -
>   unsigned int partitions;
>   struct vsp1_partition *partition;
>   struct vsp1_partition *part_table;
> diff --git a/drivers/media/platform/vsp1/vsp1_video.c
> b/drivers/media/platform/vsp1/vsp1_video.c index 72f29773eb1c..f2bc26d28396
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_video.c
> +++ b/drivers/media/platform/vsp1/vsp1_video.c
> @@ -390,44 +390,48 @@ static void vsp1_video_pipeline_run_partition(struct
> vsp1_pipeline *pipe, static void vsp1_video_pipeline_run(struct
> vsp1_pipeline *pipe)
>  {
>   struct vsp1_device *vsp1 = pipe->output->entity.vsp1;
> + struct vsp1_video *video = pipe->output->video;
>   struct vsp1_entity *entity;
>   struct vsp1_dl_body *dlb;
> + struct vsp1_dl_list *dl;
>   unsigned int partition;
> 
> - if (!pipe->dl)
> - pipe->dl = 

[ANN] Meeting to discuss improvements to support MC-based cameras on generic apps

[Mauro Carvalho Chehab]

Hi all,

The goal of this e-mail is to schedule a meeting in order to discuss
improvements at the media subsystem in order to support complex camera
hardware by usual apps.

The main focus here is to allow supporting devices with MC-based
hardware connected to a camera.

In short, my proposal is to meet with the interested parties on solving
this issue during the Open Source Summit in Japan, e. g. between
June, 19-22, in Tokyo.

I'd like to know who is interested on joining us for such meeting,
and to hear a proposal of themes for discussions.

I'm enclosing a detailed description of the problem, in order to
allow the interested parties to be at the same page.

Regards,
Mauro

---


1. Introduction
===

1.1 V4L2 Kernel aspects
---

The media subsystem supports two types of devices:

- "traditional" media hardware, supported via V4L2 API. On such hardware, 
  opening a single device node (usually /dev/video0) is enough to control
  the entire device. We call it as devnode-based devices.

- Media-controller based devices. On those devices, there are several
  /dev/video? nodes and several /dev/v4l2-subdev? nodes, plus a media
  controller device node (usually /dev/media0).
  We call it as mc-based devices. Controlling the hardware require
  opening the media device (/dev/media0), setup the pipeline and adjust
  the sub-devices via /dev/v4l2-subdev?. Only streaming is controlled
  by /dev/video?.

All "standard" media applications, including open source ones (Camorama,
Cheese, Xawtv, Firefox, Chromium, ...) and closed source ones (Skype, 
Chrome, ...) supports devnode-based devices.

Support for mc-based devices currently require an specialized application 
in order to prepare the device for its usage (setup pipelines, adjust
hardware controls, etc). Once pipeline is set, the streaming goes via
/dev/video?, although usually some /dev/v4l2-subdev? devnodes should also
be opened, in order to implement algorithms designed to make video quality
reasonable. On such devices, it is not uncommon that the device used by the
application to be a random number (on OMAP3 driver, typically, is either
/dev/video4 or /dev/video6).

One example of such hardware is at the OMAP3-based hardware:


http://www.infradead.org/~mchehab/mc-next-gen/omap3-igepv2-with-tvp5150.png

On the picture, there's a graph with the hardware blocks in blue/dark/blue
and the corresponding devnode interfaces in yellow.

The mc-based approach was taken when support for Nokia N9/N900 cameras 
was added (with has OMAP3 SoC). It is required because the camera hardware
on SoC comes with a media processor (ISP), with does a lot more than just
capturing, allowing complex algorithms to enhance image quality in runtime.
Those algorithms are known as 3A - an acronym for 3 other acronyms:

- AE (Auto Exposure);
- AF (Auto Focus);
- AWB (Auto White Balance).

Setting a camera with such ISPs are harder because the pipelines to be
set actually depends the requirements for those 3A algorithms to run.
Also, usually, the 3A algorithms use some chipset-specific userspace API,
that exports some image properties, calculated by the ISP, to speed up
the convergence of those algorithms.

Btw, usually, the 3A algorithms are IP-protected, provided by vendors
as binary only blobs, although there are a few OSS implementations.

1.2 V4L2 userspace aspects
--

Back when USB cameras were introduced, the hardware were really simple:
they had a CCD camera sensor and a chip that bridges the data though
USB. CCD camera sensors typically provide data using a bayer format,
but they usually have their own proprietary ways to pack the data,
in order to reduce the USB bandwidth (original cameras were USB 1.1).

So, V4L2 has a myriad of different formats, in order to match each
CCD camera sensor format. At the end of the day, applications were
able to use only a subset of the available hardware, since they need
to come with format converters for all formats the developer uses
(usually a very small subset of the available ones).

To end with this mess, an userspace library was written, called libv4l.
It supports all those proprietary formats. So, applications can use
a RGB or YUV format, without needing to concern about conversions.

The way it works is by adding wrappers to system calls: open, close,
ioctl, mmap, mmunmap. So, a conversion to use it is really simple:
at the source code of the apps, all it was needed is to prepend the
existing calls with "v4l2_", e. g. v4l2_open, v4l2_close, etc.

All open source apps we know now supports libv4l. On a few (like
gstreamer), support for it is optional.

In order to support closed source, another wrapper was added, allowing
to call any closed source application to use it, by using LD_PRELOAD.
For example, using skype with it is as simple as calling it with:

$ LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so /usr/bin/skypeforlinux

2. Current problems

[linux-next:master 875/8111] drivers/media//platform/fsl-viu.c:41:0: warning: "out_be32" redefined

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 
master
head:   fbbe3b8c2c9c5f84caf668703c26154cb4fbb9d1
commit: 29d750686331a1a9ceeb97e81d3770f57bed5f72 [875/8111] media: fsl-viu: 
allow building it with COMPILE_TEST
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 29d750686331a1a9ceeb97e81d3770f57bed5f72
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All warnings (new ones prefixed by >>):

>> drivers/media//platform/fsl-viu.c:41:0: warning: "out_be32" redefined
#define out_be32(v, a) iowrite32be(a, (void __iomem *)v)

   In file included from arch/m68k/include/asm/io_mm.h:27:0,
from arch/m68k/include/asm/io.h:5,
from include/linux/io.h:25,
from drivers/media//platform/fsl-viu.c:23:
   arch/m68k/include/asm/raw_io.h:46:0: note: this is the location of the 
previous definition
#define out_be32(addr,l) (void)((*(__force volatile u32 *) (addr)) = (l))

>> drivers/media//platform/fsl-viu.c:42:0: warning: "in_be32" redefined
#define in_be32(a) ioread32be((void __iomem *)a)

   In file included from arch/m68k/include/asm/io_mm.h:27:0,
from arch/m68k/include/asm/io.h:5,
from include/linux/io.h:25,
from drivers/media//platform/fsl-viu.c:23:
   arch/m68k/include/asm/raw_io.h:37:0: note: this is the location of the 
previous definition
#define in_be32(addr) \


vim +/out_be32 +41 drivers/media//platform/fsl-viu.c

  > 23  #include 
24  #include 
25  #include 
26  #include 
27  #include 
28  #include 
29  #include 
30  #include 
31  #include 
32  #include 
33  #include 
34  #include 
35  
36  #define DRV_NAME"fsl_viu"
37  #define VIU_VERSION "0.5.1"
38  
39  /* Allow building this driver with COMPILE_TEST */
40  #ifndef CONFIG_PPC
  > 41  #define out_be32(v, a)  iowrite32be(a, (void __iomem *)v)
  > 42  #define in_be32(a)  ioread32be((void __iomem *)a)
43  #endif
44  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1

[Gustavo A. R. Silva]

On 05/17/2018 07:13 AM, Mauro Carvalho Chehab wrote:

Em Thu, 17 May 2018 08:43:24 -0300
Mauro Carvalho Chehab  escreveu:


On 05/15/2018 02:39 PM, Dan Carpenter wrote:
   

You'd need to rebuild the db (possibly twice but definitely once).


How? Here, I just pull from your git tree and do a "make". At most,
make clean; make.


Never mind. Found it using grep. I'm running this:

make allyesconfig
/devel/smatch/smatch_scripts/build_kernel_data.sh
/devel/smatch/smatch_scripts/build_kernel_data.sh


It seems that something is broken... getting this error/warning:

DBD::SQLite::db do failed: unrecognized token: "'end + strlen("
" at /devel/smatch/smatch_scripts/../smatch_data/db/fill_db_sql.pl line 32, 
 line 2938054.



Yep. I get the same warning multiple times.

BTW, Mauro, you sent a patch to fix an spectre v1 issue in this file 
yesterday: dvb_ca_en50221.c:1480, but it seems there is another instance 
of the same issue some lines above:


diff --git a/drivers/media/dvb-core/dvb_ca_en50221.c 
b/drivers/media/dvb-core/dvb_ca_en50221.c

index 1310526..7edd9db 100644
--- a/drivers/media/dvb-core/dvb_ca_en50221.c
+++ b/drivers/media/dvb-core/dvb_ca_en50221.c
@@ -1398,6 +1398,7 @@ static int dvb_ca_en50221_io_do_ioctl(struct file 
*file,


info->type = CA_CI_LINK;
info->flags = 0;
+   slot = array_index_nospec(slot, ca->slot_count + 1);
sl = >slot_info[slot];
if ((sl->slot_state != DVB_CA_SLOTSTATE_NONE) &&
(sl->slot_state != DVB_CA_SLOTSTATE_INVALID)) {


Thanks
--
Gustavo

Re: [PATCH v4 03/12] clk: imx7d: fix mipi dphy div parent

[Stephen Boyd]

Quoting Rui Miguel Silva (2018-05-17 05:50:24)
> Fix the mipi dphy root divider to mipi_dphy_pre_div, this would remove a 
> orphan
> clock and set the correct parent.
> 
> before:
> cat clk_orphan_summary
>  enable  prepare  protect
>clock  countcountcountrate   
> accuracy   phase
> 
>  mipi_dphy_post_div   110   0 
>  0 0
> mipi_dphy_root_clk110   0 
>  0 0
> 
> cat clk_dump | grep mipi_dphy
> mipi_dphy_post_div110   0 
>  0 0
> mipi_dphy_root_clk110   0 
>  0 0
> 
> after:
> cat clk_dump | grep mipi_dphy
>mipi_dphy_src 1102400  
> 0 0
>mipi_dphy_cg  1102400  
> 0 0
>   mipi_dphy_pre_div  1102400  
> 0 0
>  mipi_dphy_post_div  1102400  
> 0 0
> mipi_dphy_root_clk   1102400  
> 0 0
> 
> Fixes: 8f6d8094b215 ("ARM: imx: add imx7d clk tree support")
> 
> Cc: linux-...@vger.kernel.org
> Acked-by: Dong Aisheng 
> Signed-off-by: Rui Miguel Silva 
> ---

I only get two patches out of the 12 and I don't get a cover letter.
Did you want me to pick up these clk patches into clk-next? Where are
the other patches? Can you cc lkml on all your kernel emails so I can
easily find them?

[PATCH v10 6/8] media: vsp1: Refactor display list configure operations

[Kieran Bingham]

The entities provide a single .configure operation which configures the
object into the target display list, based on the vsp1_entity_params
selection.

Split the configure function into three parts, '.configure_stream()',
'.configure_frame()', and '.configure_partition()' to facilitate
splitting the configuration of each parameter class into separate
display list bodies.

Signed-off-by: Kieran Bingham 
[Blank line reformatting, remote unneeded local variable initialization]
Reviewed-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_brx.c|  12 +-
 drivers/media/platform/vsp1/vsp1_clu.c|  78 ++
 drivers/media/platform/vsp1/vsp1_drm.c|  12 +-
 drivers/media/platform/vsp1/vsp1_entity.c |  24 ++-
 drivers/media/platform/vsp1/vsp1_entity.h |  39 +--
 drivers/media/platform/vsp1/vsp1_hgo.c|  12 +-
 drivers/media/platform/vsp1/vsp1_hgt.c|  12 +-
 drivers/media/platform/vsp1/vsp1_hsit.c   |  12 +-
 drivers/media/platform/vsp1/vsp1_lif.c|  12 +-
 drivers/media/platform/vsp1/vsp1_lut.c|  47 +---
 drivers/media/platform/vsp1/vsp1_rpf.c| 168 ++---
 drivers/media/platform/vsp1/vsp1_sru.c|  12 +-
 drivers/media/platform/vsp1/vsp1_uds.c|  56 ++--
 drivers/media/platform/vsp1/vsp1_uif.c|  16 +-
 drivers/media/platform/vsp1/vsp1_video.c  |  28 +--
 drivers/media/platform/vsp1/vsp1_wpf.c| 302 ---
 16 files changed, 422 insertions(+), 420 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_brx.c 
b/drivers/media/platform/vsp1/vsp1_brx.c
index 3beec18fd863..011edac5ebc1 100644
--- a/drivers/media/platform/vsp1/vsp1_brx.c
+++ b/drivers/media/platform/vsp1/vsp1_brx.c
@@ -281,19 +281,15 @@ static const struct v4l2_subdev_ops brx_ops = {
  * VSP1 Entity Operations
  */
 
-static void brx_configure(struct vsp1_entity *entity,
- struct vsp1_pipeline *pipe,
- struct vsp1_dl_list *dl,
- enum vsp1_entity_params params)
+static void brx_configure_stream(struct vsp1_entity *entity,
+struct vsp1_pipeline *pipe,
+struct vsp1_dl_list *dl)
 {
struct vsp1_brx *brx = to_brx(>subdev);
struct v4l2_mbus_framefmt *format;
unsigned int flags;
unsigned int i;
 
-   if (params != VSP1_ENTITY_PARAMS_INIT)
-   return;
-
format = vsp1_entity_get_pad_format(>entity, brx->entity.config,
brx->entity.source_pad);
 
@@ -400,7 +396,7 @@ static void brx_configure(struct vsp1_entity *entity,
 }
 
 static const struct vsp1_entity_operations brx_entity_ops = {
-   .configure = brx_configure,
+   .configure_stream = brx_configure_stream,
 };
 
 /* 
-
diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index ea83f1b7d125..34f17a82ac1f 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -169,57 +169,50 @@ static const struct v4l2_subdev_ops clu_ops = {
  * VSP1 Entity Operations
  */
 
-static void clu_configure(struct vsp1_entity *entity,
- struct vsp1_pipeline *pipe,
- struct vsp1_dl_list *dl,
- enum vsp1_entity_params params)
+static void clu_configure_stream(struct vsp1_entity *entity,
+struct vsp1_pipeline *pipe,
+struct vsp1_dl_list *dl)
+{
+   struct vsp1_clu *clu = to_clu(>subdev);
+   struct v4l2_mbus_framefmt *format;
+
+   /*
+* The yuv_mode can't be changed during streaming. Cache it internally
+* for future runtime configuration calls.
+*/
+   format = vsp1_entity_get_pad_format(>entity,
+   clu->entity.config,
+   CLU_PAD_SINK);
+   clu->yuv_mode = format->code == MEDIA_BUS_FMT_AYUV8_1X32;
+}
+
+static void clu_configure_frame(struct vsp1_entity *entity,
+   struct vsp1_pipeline *pipe,
+   struct vsp1_dl_list *dl)
 {
struct vsp1_clu *clu = to_clu(>subdev);
struct vsp1_dl_body *dlb;
unsigned long flags;
u32 ctrl = VI6_CLU_CTRL_AAI | VI6_CLU_CTRL_MVS | VI6_CLU_CTRL_EN;
 
-   switch (params) {
-   case VSP1_ENTITY_PARAMS_INIT: {
-   /*
-* The format can't be changed during streaming, only verify it
-* at setup time and store the information internally for future
-* runtime configuration calls.
-*/
-   struct v4l2_mbus_framefmt *format;
-
-   format = 

[PATCH v10 2/8] media: vsp1: Protect bodies against overflow

[Kieran Bingham]

The body write function relies on the code never asking it to write more
than the entries available in the list.

Currently with each list body containing 256 entries, this is fine, but
we can reduce this number greatly saving memory. In preparation of this
add a level of protection to catch any buffer overflows.

Signed-off-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_dl.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 083da4f05c20..51965c30dec2 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -46,6 +46,7 @@ struct vsp1_dl_entry {
  * @dma: DMA address of the entries
  * @size: size of the DMA memory in bytes
  * @num_entries: number of stored entries
+ * @max_entries: number of entries available
  */
 struct vsp1_dl_body {
struct list_head list;
@@ -56,6 +57,7 @@ struct vsp1_dl_body {
size_t size;
 
unsigned int num_entries;
+   unsigned int max_entries;
 };
 
 /**
@@ -138,6 +140,7 @@ static int vsp1_dl_body_init(struct vsp1_device *vsp1,
 
dlb->vsp1 = vsp1;
dlb->size = size;
+   dlb->max_entries = num_entries;
 
dlb->entries = dma_alloc_wc(vsp1->bus_master, dlb->size, >dma,
GFP_KERNEL);
@@ -219,6 +222,10 @@ void vsp1_dl_body_free(struct vsp1_dl_body *dlb)
  */
 void vsp1_dl_body_write(struct vsp1_dl_body *dlb, u32 reg, u32 data)
 {
+   if (WARN_ONCE(dlb->num_entries >= dlb->max_entries,
+ "DLB size exceeded (max %u)", dlb->max_entries))
+   return;
+
dlb->entries[dlb->num_entries].addr = reg;
dlb->entries[dlb->num_entries].data = data;
dlb->num_entries++;
-- 
git-series 0.9.1

[PATCH v10 3/8] media: vsp1: Provide a body pool

[Kieran Bingham]

Each display list allocates a body to store register values in a dma
accessible buffer from a dma_alloc_wc() allocation. Each of these
results in an entry in the IOMMU TLB, and a large number of display list
allocations adds pressure to this resource.

Reduce TLB pressure on the IPMMUs by allocating multiple display list
bodies in a single allocation, and providing these to the display list
through a 'body pool'. A pool can be allocated by the display list
manager or entities which require their own body allocations.

Signed-off-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_dl.c | 163 +++-
 drivers/media/platform/vsp1/vsp1_dl.h |   8 +-
 2 files changed, 171 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 51965c30dec2..41ace89a585b 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -41,6 +41,8 @@ struct vsp1_dl_entry {
 /**
  * struct vsp1_dl_body - Display list body
  * @list: entry in the display list list of bodies
+ * @free: entry in the pool free body list
+ * @pool: pool to which this body belongs
  * @vsp1: the VSP1 device
  * @entries: array of entries
  * @dma: DMA address of the entries
@@ -50,6 +52,9 @@ struct vsp1_dl_entry {
  */
 struct vsp1_dl_body {
struct list_head list;
+   struct list_head free;
+
+   struct vsp1_dl_body_pool *pool;
struct vsp1_device *vsp1;
 
struct vsp1_dl_entry *entries;
@@ -61,6 +66,30 @@ struct vsp1_dl_body {
 };
 
 /**
+ * struct vsp1_dl_body_pool - display list body pool
+ * @dma: DMA address of the entries
+ * @size: size of the full DMA memory pool in bytes
+ * @mem: CPU memory pointer for the pool
+ * @bodies: Array of DLB structures for the pool
+ * @free: List of free DLB entries
+ * @lock: Protects the free list
+ * @vsp1: the VSP1 device
+ */
+struct vsp1_dl_body_pool {
+   /* DMA allocation */
+   dma_addr_t dma;
+   size_t size;
+   void *mem;
+
+   /* Body management */
+   struct vsp1_dl_body *bodies;
+   struct list_head free;
+   spinlock_t lock;
+
+   struct vsp1_device *vsp1;
+};
+
+/**
  * struct vsp1_dl_list - Display list
  * @list: entry in the display list manager lists
  * @dlm: the display list manager
@@ -104,6 +133,7 @@ enum vsp1_dl_mode {
  * @active: list currently being processed (loaded) by hardware
  * @queued: list queued to the hardware (written to the DL registers)
  * @pending: list waiting to be queued to the hardware
+ * @pool: body pool for the display list bodies
  * @gc_work: bodies garbage collector work struct
  * @gc_bodies: array of display list bodies waiting to be freed
  */
@@ -119,6 +149,8 @@ struct vsp1_dl_manager {
struct vsp1_dl_list *queued;
struct vsp1_dl_list *pending;
 
+   struct vsp1_dl_body_pool *pool;
+
struct work_struct gc_work;
struct list_head gc_bodies;
 };
@@ -127,6 +159,137 @@ struct vsp1_dl_manager {
  * Display List Body Management
  */
 
+/**
+ * vsp1_dl_body_pool_create - Create a pool of bodies from a single allocation
+ * @vsp1: The VSP1 device
+ * @num_bodies: The number of bodies to allocate
+ * @num_entries: The maximum number of entries that a body can contain
+ * @extra_size: Extra allocation provided for the bodies
+ *
+ * Allocate a pool of display list bodies each with enough memory to contain 
the
+ * requested number of entries plus the @extra_size.
+ *
+ * Return a pointer to a pool on success or NULL if memory can't be allocated.
+ */
+struct vsp1_dl_body_pool *
+vsp1_dl_body_pool_create(struct vsp1_device *vsp1, unsigned int num_bodies,
+unsigned int num_entries, size_t extra_size)
+{
+   struct vsp1_dl_body_pool *pool;
+   size_t dlb_size;
+   unsigned int i;
+
+   pool = kzalloc(sizeof(*pool), GFP_KERNEL);
+   if (!pool)
+   return NULL;
+
+   pool->vsp1 = vsp1;
+
+   /*
+* TODO: 'extra_size' is only used by vsp1_dlm_create(), to allocate
+* extra memory for the display list header. We need only one header per
+* display list, not per display list body, thus this allocation is
+* extraneous and should be reworked in the future.
+*/
+   dlb_size = num_entries * sizeof(struct vsp1_dl_entry) + extra_size;
+   pool->size = dlb_size * num_bodies;
+
+   pool->bodies = kcalloc(num_bodies, sizeof(*pool->bodies), GFP_KERNEL);
+   if (!pool->bodies) {
+   kfree(pool);
+   return NULL;
+   }
+
+   pool->mem = dma_alloc_wc(vsp1->bus_master, pool->size, >dma,
+GFP_KERNEL);
+   if (!pool->mem) {
+   kfree(pool->bodies);
+   kfree(pool);
+   

[PATCH v10 0/8] vsp1: TLB optimisation and DL caching

[Kieran Bingham]

Each display list currently allocates an area of DMA memory to store register
settings for the VSP1 to process. Each of these allocations adds pressure to
the IPMMU TLB entries.

We can reduce the pressure by pre-allocating larger areas and dividing the area
across multiple bodies represented as a pool.

With this reconfiguration of bodies, we can adapt the configuration code to
separate out constant hardware configuration and cache it for re-use.

The patches provided in this series can be found at:
  git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git  
tags/vsp1/tlb-optimise/v10

Changelog:
--
v10:
 - Rebase to latest linux-media/master
 - Remove pipe->configured flag, as pipe->state is suitable for the
   same purpose, as:
(!pipe->configured) == (pipe->state == VSP1_PIPELINE_STOPPED)

v9:
 - Pass the DL through configure_partition() calls
 - Remove redundant reference to gc_bodies

v8:
 - Fix formatting and white space
 - Reword vsp1_dl_list_add_body() documentation
 - Update commit message on "Provide a body pool"
 - No longer pass unnecessary dlm->pool through vsp1_dl_list_alloc()
 - Add support for the new UIF entity
 - Fix comment location for clu_configure_stream()
 - Implement configure_partition separation
 - Rename video->pipe_config to video->stream_config

v7:
 - Rebased on to linux-media/master (v4.16-rc4)
 - Clean up the formatting of the vsp1_dl_list_add_body()
 - Fix formatting and white space
 -  s/prepare/configure_stream/
 -  s/configure/configure_frame/

v6:
 - Rebased on to linux-media/master (v4.16-rc1)
 - Removed DRM/UIF (DISCOM/ColorKey) updates

v5:
 - Rebased on to renesas-drivers-2018-01-09-v4.15-rc7 to fix conflicts
   with DRM and UIF updates on VSP1 driver

v4:
 - Rebased to v4.14
 * v4l: vsp1: Use reference counting for bodies
   - Fix up reference handling comments

 * v4l: vsp1: Provide a body pool
   - Provide comment explaining extra allocation on body pool
 highlighting area for optimisation later.

 * v4l: vsp1: Refactor display list configure operations
   - Fix up comment to describe yuv_mode caching rather than format

 * vsp1: Adapt entities to configure into a body
   - Rename vsp1_dl_list_get_body() to vsp1_dl_list_get_body0()

 * v4l: vsp1: Move video configuration to a cached dlb
   - Adjust pipe configured flag to be reset on resume rather than suspend
   - rename dl_child, dl_next

Testing:

The VSP unit tests have been run on this patch set with the following results:

root@Ubuntu-ARM64:~/vsp-tests# ./vsp-tests.sh
--- Test loop 1 ---
- vsp-unit-test-.sh
Test Conditions:
  Platform  Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+
  Kernel release4.17.0-rc4-arm64-renesas-00397-g3d2f6f2901b0
  convert   /usr/bin/convert
  compare   /usr/bin/compare
  killall   /usr/bin/killall
  raw2rgbpnm/usr/bin/raw2rgbpnm
  stress/usr/bin/stress
  yavta /usr/bin/yavta
- vsp-unit-test-0001.sh
Testing WPF packing in RGB332: pass
Testing WPF packing in ARGB555: pass
Testing WPF packing in XRGB555: pass
Testing WPF packing in RGB565: pass
Testing WPF packing in BGR24: pass
Testing WPF packing in RGB24: pass
Testing WPF packing in ABGR32: pass
Testing WPF packing in ARGB32: pass
Testing WPF packing in XBGR32: pass
Testing WPF packing in XRGB32: pass
- vsp-unit-test-0002.sh
Testing WPF packing in NV12M: pass
Testing WPF packing in NV16M: pass
Testing WPF packing in NV21M: pass
Testing WPF packing in NV61M: pass
Testing WPF packing in UYVY: pass
Testing WPF packing in VYUY: skip
Testing WPF packing in YUV420M: pass
Testing WPF packing in YUV422M: pass
Testing WPF packing in YUV444M: pass
Testing WPF packing in YVU420M: pass
Testing WPF packing in YVU422M: pass
Testing WPF packing in YVU444M: pass
Testing WPF packing in YUYV: pass
Testing WPF packing in YVYU: pass
- vsp-unit-test-0003.sh
Testing scaling from 640x640 to 640x480 in RGB24: pass
Testing scaling from 1024x768 to 640x480 in RGB24: pass
Testing scaling from 640x480 to 1024x768 in RGB24: pass
Testing scaling from 640x640 to 640x480 in YUV444M: pass
Testing scaling from 1024x768 to 640x480 in YUV444M: pass
Testing scaling from 640x480 to 1024x768 in YUV444M: pass
- vsp-unit-test-0004.sh
Testing histogram in RGB24: pass
Testing histogram in YUV444M: pass
- vsp-unit-test-0005.sh
Testing RPF.0: pass
Testing RPF.1: pass
Testing RPF.2: pass
Testing RPF.3: pass
Testing RPF.4: pass
- vsp-unit-test-0006.sh
Testing invalid pipeline with no RPF: pass
Testing invalid pipeline with no WPF: pass
- vsp-unit-test-0007.sh
Testing BRU in RGB24 with 1 inputs: pass
Testing BRU in RGB24 with 2 inputs: pass
Testing BRU in RGB24 with 3 inputs: pass
Testing BRU in RGB24 with 4 inputs: pass
Testing BRU in RGB24 with 5 inputs: pass
Testing BRU in YUV444M with 1 inputs: pass
Testing BRU in YUV444M with 2 inputs: pass
Testing BRU in YUV444M with 3 inputs: pass
Testing BRU in YUV444M with 4 inputs: pass
Testing BRU in YUV444M with 

[PATCH v10 7/8] media: vsp1: Adapt entities to configure into a body

[Kieran Bingham]

Currently the entities store their configurations into a display list.
Adapt this such that the code can be configured into a body directly,
allowing greater flexibility and control of the content.

All users of vsp1_dl_list_write() are removed in this process, thus it
too is removed.

A helper, vsp1_dl_list_get_body0() is provided to access the internal body0
from the display list.

Signed-off-by: Kieran Bingham 
[Don't remove blank line unnecessarily]
Reviewed-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_brx.c| 22 ++--
 drivers/media/platform/vsp1/vsp1_clu.c| 23 ++---
 drivers/media/platform/vsp1/vsp1_dl.c | 12 ++-
 drivers/media/platform/vsp1/vsp1_dl.h |  2 +-
 drivers/media/platform/vsp1/vsp1_drm.c| 12 ---
 drivers/media/platform/vsp1/vsp1_entity.c | 22 ++--
 drivers/media/platform/vsp1/vsp1_entity.h | 18 ++
 drivers/media/platform/vsp1/vsp1_hgo.c| 16 -
 drivers/media/platform/vsp1/vsp1_hgt.c| 18 +-
 drivers/media/platform/vsp1/vsp1_hsit.c   | 10 +++---
 drivers/media/platform/vsp1/vsp1_lif.c| 15 
 drivers/media/platform/vsp1/vsp1_lut.c| 23 ++---
 drivers/media/platform/vsp1/vsp1_pipe.c   |  4 +-
 drivers/media/platform/vsp1/vsp1_pipe.h   |  3 +-
 drivers/media/platform/vsp1/vsp1_rpf.c| 43 
 drivers/media/platform/vsp1/vsp1_sru.c| 14 
 drivers/media/platform/vsp1/vsp1_uds.c| 25 +++---
 drivers/media/platform/vsp1/vsp1_uds.h|  2 +-
 drivers/media/platform/vsp1/vsp1_uif.c| 21 ++--
 drivers/media/platform/vsp1/vsp1_video.c  | 16 ++---
 drivers/media/platform/vsp1/vsp1_wpf.c| 42 ---
 21 files changed, 194 insertions(+), 169 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_brx.c 
b/drivers/media/platform/vsp1/vsp1_brx.c
index 011edac5ebc1..359917b5d842 100644
--- a/drivers/media/platform/vsp1/vsp1_brx.c
+++ b/drivers/media/platform/vsp1/vsp1_brx.c
@@ -26,10 +26,10 @@
  * Device Access
  */
 
-static inline void vsp1_brx_write(struct vsp1_brx *brx, struct vsp1_dl_list 
*dl,
- u32 reg, u32 data)
+static inline void vsp1_brx_write(struct vsp1_brx *brx,
+ struct vsp1_dl_body *dlb, u32 reg, u32 data)
 {
-   vsp1_dl_list_write(dl, brx->base + reg, data);
+   vsp1_dl_body_write(dlb, brx->base + reg, data);
 }
 
 /* 
-
@@ -283,7 +283,7 @@ static const struct v4l2_subdev_ops brx_ops = {
 
 static void brx_configure_stream(struct vsp1_entity *entity,
 struct vsp1_pipeline *pipe,
-struct vsp1_dl_list *dl)
+struct vsp1_dl_body *dlb)
 {
struct vsp1_brx *brx = to_brx(>subdev);
struct v4l2_mbus_framefmt *format;
@@ -305,7 +305,7 @@ static void brx_configure_stream(struct vsp1_entity *entity,
 * format at the pipeline output is premultiplied.
 */
flags = pipe->output ? pipe->output->format.flags : 0;
-   vsp1_brx_write(brx, dl, VI6_BRU_INCTRL,
+   vsp1_brx_write(brx, dlb, VI6_BRU_INCTRL,
   flags & V4L2_PIX_FMT_FLAG_PREMUL_ALPHA ?
   0 : VI6_BRU_INCTRL_NRM);
 
@@ -313,12 +313,12 @@ static void brx_configure_stream(struct vsp1_entity 
*entity,
 * Set the background position to cover the whole output image and
 * configure its color.
 */
-   vsp1_brx_write(brx, dl, VI6_BRU_VIRRPF_SIZE,
+   vsp1_brx_write(brx, dlb, VI6_BRU_VIRRPF_SIZE,
   (format->width << VI6_BRU_VIRRPF_SIZE_HSIZE_SHIFT) |
   (format->height << VI6_BRU_VIRRPF_SIZE_VSIZE_SHIFT));
-   vsp1_brx_write(brx, dl, VI6_BRU_VIRRPF_LOC, 0);
+   vsp1_brx_write(brx, dlb, VI6_BRU_VIRRPF_LOC, 0);
 
-   vsp1_brx_write(brx, dl, VI6_BRU_VIRRPF_COL, brx->bgcolor |
+   vsp1_brx_write(brx, dlb, VI6_BRU_VIRRPF_COL, brx->bgcolor |
   (0xff << VI6_BRU_VIRRPF_COL_A_SHIFT));
 
/*
@@ -328,7 +328,7 @@ static void brx_configure_stream(struct vsp1_entity *entity,
 * unit.
 */
if (entity->type == VSP1_ENTITY_BRU)
-   vsp1_brx_write(brx, dl, VI6_BRU_ROP,
+   vsp1_brx_write(brx, dlb, VI6_BRU_ROP,
   VI6_BRU_ROP_DSTSEL_BRUIN(1) |
   VI6_BRU_ROP_CROP(VI6_ROP_NOP) |
   VI6_BRU_ROP_AROP(VI6_ROP_NOP));
@@ -370,7 +370,7 @@ static void brx_configure_stream(struct vsp1_entity *entity,
if (!(entity->type == VSP1_ENTITY_BRU && i == 1))
ctrl |= VI6_BRU_CTRL_SRCSEL_BRUIN(i);
 
-   

[PATCH v10 5/8] media: vsp1: Use reference counting for bodies

[Kieran Bingham]

Extend the display list body with a reference count, allowing bodies to
be kept as long as a reference is maintained. This provides the ability
to keep a cached copy of bodies which will not change, so that they can
be re-applied to multiple display lists.

Signed-off-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_clu.c |  7 ++-
 drivers/media/platform/vsp1/vsp1_dl.c  | 16 ++--
 drivers/media/platform/vsp1/vsp1_lut.c |  7 ++-
 3 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index 8efa12f5e53f..ea83f1b7d125 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -212,8 +212,13 @@ static void clu_configure(struct vsp1_entity *entity,
clu->clu = NULL;
spin_unlock_irqrestore(>lock, flags);
 
-   if (dlb)
+   if (dlb) {
vsp1_dl_list_add_body(dl, dlb);
+
+   /* Release our local reference. */
+   vsp1_dl_body_put(dlb);
+   }
+
break;
}
 }
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 617c46a03dec..1407c90c6880 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -54,6 +55,8 @@ struct vsp1_dl_body {
struct list_head list;
struct list_head free;
 
+   refcount_t refcnt;
+
struct vsp1_dl_body_pool *pool;
struct vsp1_device *vsp1;
 
@@ -258,6 +261,7 @@ struct vsp1_dl_body *vsp1_dl_body_get(struct 
vsp1_dl_body_pool *pool)
if (!list_empty(>free)) {
dlb = list_first_entry(>free, struct vsp1_dl_body, free);
list_del(>free);
+   refcount_set(>refcnt, 1);
}
 
spin_unlock_irqrestore(>lock, flags);
@@ -278,6 +282,9 @@ void vsp1_dl_body_put(struct vsp1_dl_body *dlb)
if (!dlb)
return;
 
+   if (!refcount_dec_and_test(>refcnt))
+   return;
+
dlb->num_entries = 0;
 
spin_lock_irqsave(>pool->lock, flags);
@@ -463,8 +470,11 @@ void vsp1_dl_list_write(struct vsp1_dl_list *dl, u32 reg, 
u32 data)
  * which bodies are added.
  *
  * Adding a body to a display list passes ownership of the body to the list. 
The
- * caller must not touch the body after this call, and must not release it
- * explicitly with vsp1_dl_body_put().
+ * caller retains its reference to the fragment when adding it to the display
+ * list, but is not allowed to add new entries to the body.
+ *
+ * The reference must be explicitly released by a call to vsp1_dl_body_put()
+ * when the body isn't needed anymore.
  *
  * Additional bodies are only usable for display lists in header mode.
  * Attempting to add a body to a header-less display list will return an error.
@@ -475,6 +485,8 @@ int vsp1_dl_list_add_body(struct vsp1_dl_list *dl, struct 
vsp1_dl_body *dlb)
if (dl->dlm->mode != VSP1_DL_MODE_HEADER)
return -EINVAL;
 
+   refcount_inc(>refcnt);
+
list_add_tail(>list, >bodies);
 
return 0;
diff --git a/drivers/media/platform/vsp1/vsp1_lut.c 
b/drivers/media/platform/vsp1/vsp1_lut.c
index 6b358617ce15..b3ea90172439 100644
--- a/drivers/media/platform/vsp1/vsp1_lut.c
+++ b/drivers/media/platform/vsp1/vsp1_lut.c
@@ -168,8 +168,13 @@ static void lut_configure(struct vsp1_entity *entity,
lut->lut = NULL;
spin_unlock_irqrestore(>lock, flags);
 
-   if (dlb)
+   if (dlb) {
vsp1_dl_list_add_body(dl, dlb);
+
+   /* Release our local reference. */
+   vsp1_dl_body_put(dlb);
+   }
+
break;
}
 }
-- 
git-series 0.9.1

[PATCH v10 8/8] media: vsp1: Move video configuration to a cached dlb

[Kieran Bingham]

We are now able to configure a pipeline directly into a local display
list body. Take advantage of this fact, and create a cacheable body to
store the configuration of the pipeline in the video object.

vsp1_video_pipeline_run() is now the last user of the pipe->dl object.
Convert this function to use the cached video->config body and obtain a
local display list reference.

Attach the video->config body to the display list when needed before
committing to hardware.

The pipe object is marked as un-configured when resuming from a suspend.
This ensures that when the hardware is reset - our cached configuration
will be re-attached to the next committed DL.

Our video DL usage now looks like the below output:

dl->body0 contains our disposable runtime configuration. Max 41.
dl_child->body0 is our partition specific configuration. Max 12.
dl->bodies shows our constant configuration and LUTs.

  These two are LUT/CLU:
 * dl->bodies[x]->num_entries 256 / max 256
 * dl->bodies[x]->num_entries 4914 / max 4914

Which shows that our 'constant' configuration cache is currently
utilised to a maximum of 64 entries.

trace-cmd report | \
grep max | sed 's/.*vsp1_dl_list_commit://g' | sort | uniq;

  dl->body0->num_entries 13 / max 128
  dl->body0->num_entries 14 / max 128
  dl->body0->num_entries 16 / max 128
  dl->body0->num_entries 20 / max 128
  dl->body0->num_entries 27 / max 128
  dl->body0->num_entries 34 / max 128
  dl->body0->num_entries 41 / max 128
  dl_child->body0->num_entries 10 / max 128
  dl_child->body0->num_entries 12 / max 128
  dl->bodies[x]->num_entries 15 / max 128
  dl->bodies[x]->num_entries 16 / max 128
  dl->bodies[x]->num_entries 17 / max 128
  dl->bodies[x]->num_entries 18 / max 128
  dl->bodies[x]->num_entries 20 / max 128
  dl->bodies[x]->num_entries 21 / max 128
  dl->bodies[x]->num_entries 256 / max 256
  dl->bodies[x]->num_entries 31 / max 128
  dl->bodies[x]->num_entries 32 / max 128
  dl->bodies[x]->num_entries 39 / max 128
  dl->bodies[x]->num_entries 40 / max 128
  dl->bodies[x]->num_entries 47 / max 128
  dl->bodies[x]->num_entries 48 / max 128
  dl->bodies[x]->num_entries 4914 / max 4914
  dl->bodies[x]->num_entries 55 / max 128
  dl->bodies[x]->num_entries 56 / max 128
  dl->bodies[x]->num_entries 63 / max 128
  dl->bodies[x]->num_entries 64 / max 128

Signed-off-by: Kieran Bingham 
---
v10:
 - Removed pipe->configured flag, and use
   pipe->state == VSP1_PIPELINE_STOPPED instead.

v8:
 - Fix comments
 - Rename video->pipe_config -> video->stream_config

v4:
 - Adjust pipe configured flag to be reset on resume rather than suspend
 - rename dl_child, dl_next

v3:
 - 's/fragment/body/', 's/fragments/bodies/'
 - video dlb cache allocation increased from 2 to 3 dlbs

 drivers/media/platform/vsp1/vsp1_pipe.h  |  3 +-
 drivers/media/platform/vsp1/vsp1_video.c | 67 +++--
 drivers/media/platform/vsp1/vsp1_video.h |  2 +-
 3 files changed, 43 insertions(+), 29 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h 
b/drivers/media/platform/vsp1/vsp1_pipe.h
index e00010693eef..be6ecab3cbed 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -102,7 +102,6 @@ struct vsp1_partition {
  * @uds: UDS entity, if present
  * @uds_input: entity at the input of the UDS, if the UDS is present
  * @entities: list of entities in the pipeline
- * @dl: display list associated with the pipeline
  * @partitions: The number of partitions used to process one frame
  * @partition: The current partition for configuration to process
  * @part_table: The pre-calculated partitions used by the pipeline
@@ -139,8 +138,6 @@ struct vsp1_pipeline {
 */
struct list_head entities;
 
-   struct vsp1_dl_list *dl;
-
unsigned int partitions;
struct vsp1_partition *partition;
struct vsp1_partition *part_table;
diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index 72f29773eb1c..f2bc26d28396 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -390,44 +390,48 @@ static void vsp1_video_pipeline_run_partition(struct 
vsp1_pipeline *pipe,
 static void vsp1_video_pipeline_run(struct vsp1_pipeline *pipe)
 {
struct vsp1_device *vsp1 = pipe->output->entity.vsp1;
+   struct vsp1_video *video = pipe->output->video;
struct vsp1_entity *entity;
struct vsp1_dl_body *dlb;
+   struct vsp1_dl_list *dl;
unsigned int partition;
 
-   if (!pipe->dl)
-   pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
+   dl = vsp1_dl_list_get(pipe->output->dlm);
+
+   /* Attach our pipe configuration to fully initialise the hardware. */
+   if (pipe->state == VSP1_PIPELINE_STOPPED)
+   vsp1_dl_list_add_body(dl, video->stream_config);
 
-   dlb = vsp1_dl_list_get_body0(pipe->dl);
+   dlb = 

[PATCH v10 4/8] media: vsp1: Convert display lists to use new body pool

[Kieran Bingham]

Adapt the dl->body0 object to use an object from the body pool. This
greatly reduces the pressure on the TLB for IPMMU use cases, as all of
the lists use a single allocation for the main body.

The CLU and LUT objects pre-allocate a pool containing three bodies,
allowing a userspace update before the hardware has committed a previous
set of tables.

Bodies are no longer 'freed' in interrupt context, but instead released
back to their respective pools. This allows us to remove the garbage
collector in the DLM.

Signed-off-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_clu.c |  27 ++-
 drivers/media/platform/vsp1/vsp1_clu.h |   1 +-
 drivers/media/platform/vsp1/vsp1_dl.c  | 221 ++
 drivers/media/platform/vsp1/vsp1_dl.h  |   3 +-
 drivers/media/platform/vsp1/vsp1_lut.c |  27 ++-
 drivers/media/platform/vsp1/vsp1_lut.h |   1 +-
 6 files changed, 100 insertions(+), 180 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index ebfbb915dcdc..8efa12f5e53f 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -19,6 +19,8 @@
 #define CLU_MIN_SIZE   4U
 #define CLU_MAX_SIZE   8190U
 
+#define CLU_SIZE   (17 * 17 * 17)
+
 /* 
-
  * Device Access
  */
@@ -43,19 +45,19 @@ static int clu_set_table(struct vsp1_clu *clu, struct 
v4l2_ctrl *ctrl)
struct vsp1_dl_body *dlb;
unsigned int i;
 
-   dlb = vsp1_dl_body_alloc(clu->entity.vsp1, 1 + 17 * 17 * 17);
+   dlb = vsp1_dl_body_get(clu->pool);
if (!dlb)
return -ENOMEM;
 
vsp1_dl_body_write(dlb, VI6_CLU_ADDR, 0);
-   for (i = 0; i < 17 * 17 * 17; ++i)
+   for (i = 0; i < CLU_SIZE; ++i)
vsp1_dl_body_write(dlb, VI6_CLU_DATA, ctrl->p_new.p_u32[i]);
 
spin_lock_irq(>lock);
swap(clu->clu, dlb);
spin_unlock_irq(>lock);
 
-   vsp1_dl_body_free(dlb);
+   vsp1_dl_body_put(dlb);
return 0;
 }
 
@@ -216,8 +218,16 @@ static void clu_configure(struct vsp1_entity *entity,
}
 }
 
+static void clu_destroy(struct vsp1_entity *entity)
+{
+   struct vsp1_clu *clu = to_clu(>subdev);
+
+   vsp1_dl_body_pool_destroy(clu->pool);
+}
+
 static const struct vsp1_entity_operations clu_entity_ops = {
.configure = clu_configure,
+   .destroy = clu_destroy,
 };
 
 /* 
-
@@ -243,6 +253,17 @@ struct vsp1_clu *vsp1_clu_create(struct vsp1_device *vsp1)
if (ret < 0)
return ERR_PTR(ret);
 
+   /*
+* Pre-allocate a body pool, with 3 bodies allowing a userspace update
+* before the hardware has committed a previous set of tables, handling
+* both the queued and pending dl entries. One extra entry is added to
+* the CLU_SIZE to allow for the VI6_CLU_ADDR header.
+*/
+   clu->pool = vsp1_dl_body_pool_create(clu->entity.vsp1, 3, CLU_SIZE + 1,
+0);
+   if (!clu->pool)
+   return ERR_PTR(-ENOMEM);
+
/* Initialize the control handler. */
v4l2_ctrl_handler_init(>ctrls, 2);
v4l2_ctrl_new_custom(>ctrls, _table_control, NULL);
diff --git a/drivers/media/platform/vsp1/vsp1_clu.h 
b/drivers/media/platform/vsp1/vsp1_clu.h
index c45e6e707592..cef2f44481ba 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.h
+++ b/drivers/media/platform/vsp1/vsp1_clu.h
@@ -32,6 +32,7 @@ struct vsp1_clu {
spinlock_t lock;
unsigned int mode;
struct vsp1_dl_body *clu;
+   struct vsp1_dl_body_pool *pool;
 };
 
 static inline struct vsp1_clu *to_clu(struct v4l2_subdev *subdev)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 41ace89a585b..617c46a03dec 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -108,7 +108,7 @@ struct vsp1_dl_list {
struct vsp1_dl_header *header;
dma_addr_t dma;
 
-   struct vsp1_dl_body body0;
+   struct vsp1_dl_body *body0;
struct list_head bodies;
 
bool has_chain;
@@ -128,14 +128,12 @@ enum vsp1_dl_mode {
  * @mode: display list operation mode (header or headerless)
  * @singleshot: execute the display list in single-shot mode
  * @vsp1: the VSP1 device
- * @lock: protects the free, active, queued, pending and gc_bodies lists
+ * @lock: protects the free, active, queued, and pending lists
  * @free: array of all free display lists
  * @active: list currently being processed (loaded) by hardware
  * @queued: list queued 

[PATCH v10 1/8] media: vsp1: Reword uses of 'fragment' as 'body'

[Kieran Bingham]

Throughout the codebase, the term 'fragment' is used to represent a
display list body. This term duplicates the 'body' which is already in
use.

The datasheet references these objects as a body, therefore replace all
mentions of a fragment with a body, along with the corresponding
pluralised terms.

Signed-off-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_clu.c |  10 +-
 drivers/media/platform/vsp1/vsp1_dl.c  | 111 --
 drivers/media/platform/vsp1/vsp1_dl.h  |  13 +--
 drivers/media/platform/vsp1/vsp1_lut.c |   8 +-
 4 files changed, 70 insertions(+), 72 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index 96a448e1504c..ebfbb915dcdc 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -43,19 +43,19 @@ static int clu_set_table(struct vsp1_clu *clu, struct 
v4l2_ctrl *ctrl)
struct vsp1_dl_body *dlb;
unsigned int i;
 
-   dlb = vsp1_dl_fragment_alloc(clu->entity.vsp1, 1 + 17 * 17 * 17);
+   dlb = vsp1_dl_body_alloc(clu->entity.vsp1, 1 + 17 * 17 * 17);
if (!dlb)
return -ENOMEM;
 
-   vsp1_dl_fragment_write(dlb, VI6_CLU_ADDR, 0);
+   vsp1_dl_body_write(dlb, VI6_CLU_ADDR, 0);
for (i = 0; i < 17 * 17 * 17; ++i)
-   vsp1_dl_fragment_write(dlb, VI6_CLU_DATA, ctrl->p_new.p_u32[i]);
+   vsp1_dl_body_write(dlb, VI6_CLU_DATA, ctrl->p_new.p_u32[i]);
 
spin_lock_irq(>lock);
swap(clu->clu, dlb);
spin_unlock_irq(>lock);
 
-   vsp1_dl_fragment_free(dlb);
+   vsp1_dl_body_free(dlb);
return 0;
 }
 
@@ -211,7 +211,7 @@ static void clu_configure(struct vsp1_entity *entity,
spin_unlock_irqrestore(>lock, flags);
 
if (dlb)
-   vsp1_dl_list_add_fragment(dl, dlb);
+   vsp1_dl_list_add_body(dl, dlb);
break;
}
 }
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 801dea475740..083da4f05c20 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -65,7 +65,7 @@ struct vsp1_dl_body {
  * @header: display list header, NULL for headerless lists
  * @dma: DMA address for the header
  * @body0: first display list body
- * @fragments: list of extra display list bodies
+ * @bodies: list of extra display list bodies
  * @has_chain: if true, indicates that there's a partition chain
  * @chain: entry in the display list partition chain
  * @internal: whether the display list is used for internal purpose
@@ -78,7 +78,7 @@ struct vsp1_dl_list {
dma_addr_t dma;
 
struct vsp1_dl_body body0;
-   struct list_head fragments;
+   struct list_head bodies;
 
bool has_chain;
struct list_head chain;
@@ -97,13 +97,13 @@ enum vsp1_dl_mode {
  * @mode: display list operation mode (header or headerless)
  * @singleshot: execute the display list in single-shot mode
  * @vsp1: the VSP1 device
- * @lock: protects the free, active, queued, pending and gc_fragments lists
+ * @lock: protects the free, active, queued, pending and gc_bodies lists
  * @free: array of all free display lists
  * @active: list currently being processed (loaded) by hardware
  * @queued: list queued to the hardware (written to the DL registers)
  * @pending: list waiting to be queued to the hardware
- * @gc_work: fragments garbage collector work struct
- * @gc_fragments: array of display list fragments waiting to be freed
+ * @gc_work: bodies garbage collector work struct
+ * @gc_bodies: array of display list bodies waiting to be freed
  */
 struct vsp1_dl_manager {
unsigned int index;
@@ -118,7 +118,7 @@ struct vsp1_dl_manager {
struct vsp1_dl_list *pending;
 
struct work_struct gc_work;
-   struct list_head gc_fragments;
+   struct list_head gc_bodies;
 };
 
 /* 
-
@@ -156,18 +156,17 @@ static void vsp1_dl_body_cleanup(struct vsp1_dl_body *dlb)
 }
 
 /**
- * vsp1_dl_fragment_alloc - Allocate a display list fragment
+ * vsp1_dl_body_alloc - Allocate a display list body
  * @vsp1: The VSP1 device
- * @num_entries: The maximum number of entries that the fragment can contain
+ * @num_entries: The maximum number of entries that the body can contain
  *
- * Allocate a display list fragment with enough memory to contain the requested
+ * Allocate a display list body with enough memory to contain the requested
  * number of entries.
  *
- * Return a pointer to a fragment on success or NULL if memory can't be
- * allocated.
+ * Return a pointer to a body on success or NULL if memory can't be allocated.
  */
-struct 

Re: [PATCH v3 2/2] bpf: add selftest for rawir_event type program

[Y Song]

On Wed, May 16, 2018 at 2:04 PM, Sean Young  wrote:
> This is simple test over rc-loopback.
>
> Signed-off-by: Sean Young 
> ---
>  tools/bpf/bpftool/prog.c  |   1 +
>  tools/include/uapi/linux/bpf.h|  57 +++-
>  tools/lib/bpf/libbpf.c|   1 +
>  tools/testing/selftests/bpf/Makefile  |   8 +-
>  tools/testing/selftests/bpf/bpf_helpers.h |   6 +
>  tools/testing/selftests/bpf/test_rawir.sh |  37 +
>  .../selftests/bpf/test_rawir_event_kern.c |  26 
>  .../selftests/bpf/test_rawir_event_user.c | 130 ++
>  8 files changed, 261 insertions(+), 5 deletions(-)
>  create mode 100755 tools/testing/selftests/bpf/test_rawir.sh
>  create mode 100644 tools/testing/selftests/bpf/test_rawir_event_kern.c
>  create mode 100644 tools/testing/selftests/bpf/test_rawir_event_user.c

Could you copy include/uapi/linux/lirc.h file to tools directory as well.
Otherwise, I will get the following compilation error:

gcc -Wall -O2 -I../../../include/uapi -I../../../lib
-I../../../lib/bpf -I../../../../include/generated  -I../../../include
   test_rawir_event_user.c
/home/yhs/work/bpf-next/tools/testing/selftests/bpf/libbpf.a -lcap
-lelf -lrt -lpthread -o
/home/yhs/work/bpf-next/tools/testing/selftests/bpf/test_rawir_event_user
test_rawir_event_user.c: In function ‘main’:
test_rawir_event_user.c:60:15: error: ‘LIRC_MODE_SCANCODE’ undeclared
(first use in this function); did you mean ‘LIRC_MODE_LIRCCODE’?
mode = LIRC_MODE_SCANCODE;
   ^~
   LIRC_MODE_LIRCCODE
test_rawir_event_user.c:60:15: note: each undeclared identifier is
reported only once for each function it appears in
test_rawir_event_user.c:93:29: error: storage size of ‘lsc’ isn’t known
struct lirc_scancode lsc;
 ^~~
test_rawir_event_user.c:93:29: warning: unused variable ‘lsc’
[-Wunused-variable]

>
> diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c
> index 9bdfdf2d3fbe..8889a4ee8577 100644
> --- a/tools/bpf/bpftool/prog.c
> +++ b/tools/bpf/bpftool/prog.c
> @@ -71,6 +71,7 @@ static const char * const prog_type_name[] = {
> [BPF_PROG_TYPE_SK_MSG]  = "sk_msg",
> [BPF_PROG_TYPE_RAW_TRACEPOINT]  = "raw_tracepoint",
> [BPF_PROG_TYPE_CGROUP_SOCK_ADDR] = "cgroup_sock_addr",
> +   [BPF_PROG_TYPE_RAWIR_EVENT] = "rawir_event",
>  };
>
>  static void print_boot_time(__u64 nsecs, char *buf, unsigned int size)
> diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
> index 1205d86a7a29..243e141e8a5b 100644
> --- a/tools/include/uapi/linux/bpf.h
> +++ b/tools/include/uapi/linux/bpf.h
> @@ -141,6 +141,7 @@ enum bpf_prog_type {
> BPF_PROG_TYPE_SK_MSG,
> BPF_PROG_TYPE_RAW_TRACEPOINT,
> BPF_PROG_TYPE_CGROUP_SOCK_ADDR,
> +   BPF_PROG_TYPE_RAWIR_EVENT,
>  };
>
>  enum bpf_attach_type {
> @@ -158,6 +159,7 @@ enum bpf_attach_type {
> BPF_CGROUP_INET6_CONNECT,
> BPF_CGROUP_INET4_POST_BIND,
> BPF_CGROUP_INET6_POST_BIND,
> +   BPF_RAWIR_EVENT,
> __MAX_BPF_ATTACH_TYPE
>  };
>
> @@ -1829,7 +1831,6 @@ union bpf_attr {
>   * Return
>   * 0 on success, or a negative error in case of failure.
>   *
> - *
>   * int bpf_fib_lookup(void *ctx, struct bpf_fib_lookup *params, int plen, 
> u32 flags)
>   * Description
>   * Do FIB lookup in kernel tables using parameters in *params*.
> @@ -1856,6 +1857,7 @@ union bpf_attr {
>   * Egress device index on success, 0 if packet needs to continue
>   * up the stack for further processing or a negative error in 
> case
>   * of failure.
> + *
>   * int bpf_sock_hash_update(struct bpf_sock_ops_kern *skops, struct bpf_map 
> *map, void *key, u64 flags)
>   * Description
>   * Add an entry to, or update a sockhash *map* referencing 
> sockets.
> @@ -1902,6 +1904,35 @@ union bpf_attr {
>   * egress otherwise). This is the only flag supported for now.
>   * Return
>   * **SK_PASS** on success, or **SK_DROP** on error.
> + *
> + * int bpf_rc_keydown(void *ctx, u32 protocol, u32 scancode, u32 toggle)
> + * Description
> + * Report decoded scancode with toggle value. For use in
> + * BPF_PROG_TYPE_RAWIR_EVENT, to report a successfully
> + * decoded scancode. This is will generate a keydown event,
> + * and a keyup event once the scancode is no longer repeated.
> + *
> + * *ctx* pointer to bpf_rawir_event, *protocol* is decoded
> + * protocol (see RC_PROTO_* enum).
> + *
> + * Some protocols include a toggle bit, in case the button
> + * was released and pressed again between consecutive scancodes,
> + * copy this bit into *toggle* if it exists, else set to 0.
> + *
> + * Return
> + *  

[PATCH v4] media: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Note:
  - The various VIDEOBUF*DMA* symbols had to loose their dependencies on
HAS_DMA, as they are selected by several individual drivers.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
From: kbuild test robot 

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git  
no-dma-compile-testing-v4-media
branch HEAD: 9fd4215b490cae0bb6dd058a18a19e60dbcd3020  media: Remove depends on 
HAS_DMA in case of platform dependency

elapsed time: 41m

configs tested: 99

---
v4:
  - Rebase to media-next on 2018-05-17,

v3:
  - Rebase to v4.17-rc1,
  - Handle new VIDEO_RENESAS_CEU symbol,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Drop dependency of VIDEOBUF{,2}_DMA_{CONTIG,SG} on HAS_DMA,
  - Drop new dependencies of VIDEO_IPU3_CIO2 and DVB_C8SECTPFE on
HAS_DMA,
  - Split per subsystem.
---
 drivers/media/common/videobuf2/Kconfig   |  2 --
 drivers/media/pci/dt3155/Kconfig |  1 -
 drivers/media/pci/intel/ipu3/Kconfig |  1 -
 drivers/media/pci/solo6x10/Kconfig   |  1 -
 drivers/media/pci/sta2x11/Kconfig|  1 -
 drivers/media/pci/tw5864/Kconfig |  1 -
 drivers/media/pci/tw686x/Kconfig |  1 -
 drivers/media/platform/Kconfig   | 43 +---
 drivers/media/platform/am437x/Kconfig|  2 +-
 drivers/media/platform/atmel/Kconfig |  4 +--
 drivers/media/platform/davinci/Kconfig   |  6 
 drivers/media/platform/marvell-ccic/Kconfig  |  2 --
 drivers/media/platform/rcar-vin/Kconfig  |  2 +-
 drivers/media/platform/soc_camera/Kconfig|  3 +-
 drivers/media/platform/sti/c8sectpfe/Kconfig |  2 +-
 drivers/media/v4l2-core/Kconfig  |  2 --
 drivers/staging/media/davinci_vpfe/Kconfig   |  1 -
 drivers/staging/media/omap4iss/Kconfig   |  1 -
 18 files changed, 20 insertions(+), 56 deletions(-)

diff --git a/drivers/media/common/videobuf2/Kconfig 
b/drivers/media/common/videobuf2/Kconfig
index 17c32ea58395d78f..4ed11b46676ac4d0 100644
--- a/drivers/media/common/videobuf2/Kconfig
+++ b/drivers/media/common/videobuf2/Kconfig
@@ -12,7 +12,6 @@ config VIDEOBUF2_MEMOPS
 
 config VIDEOBUF2_DMA_CONTIG
tristate
-   depends on HAS_DMA
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
select DMA_SHARED_BUFFER
@@ -25,7 +24,6 @@ config VIDEOBUF2_VMALLOC
 
 config VIDEOBUF2_DMA_SG
tristate
-   depends on HAS_DMA
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
 
diff --git a/drivers/media/pci/dt3155/Kconfig b/drivers/media/pci/dt3155/Kconfig
index 5145e0dfa2aa9e12..858b0f2f15bef9c8 100644
--- a/drivers/media/pci/dt3155/Kconfig
+++ b/drivers/media/pci/dt3155/Kconfig
@@ -1,7 +1,6 @@
 config VIDEO_DT3155
tristate "DT3155 frame grabber"
depends on PCI && VIDEO_DEV && VIDEO_V4L2
-   depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
default n
---help---
diff --git a/drivers/media/pci/intel/ipu3/Kconfig 
b/drivers/media/pci/intel/ipu3/Kconfig
index 45cf99a512e484d5..c8bd98d7564afdfb 100644
--- a/drivers/media/pci/intel/ipu3/Kconfig
+++ b/drivers/media/pci/intel/ipu3/Kconfig
@@ -4,7 +4,6 @@ config VIDEO_IPU3_CIO2
depends on VIDEO_V4L2_SUBDEV_API
depends on (X86 && ACPI) || COMPILE_TEST
depends on MEDIA_CONTROLLER
-   depends on HAS_DMA
select V4L2_FWNODE
select VIDEOBUF2_DMA_SG
 
diff --git a/drivers/media/pci/solo6x10/Kconfig 
b/drivers/media/pci/solo6x10/Kconfig
index 0fb91dc7ca73529e..d9e06a6bf1ebc1a7 100644
--- a/drivers/media/pci/solo6x10/Kconfig
+++ b/drivers/media/pci/solo6x10/Kconfig
@@ -1,7 +1,6 @@
 config VIDEO_SOLO6X10
tristate "Bluecherry / Softlogic 6x10 capture cards (MPEG-4/H.264)"
depends on PCI && VIDEO_DEV && SND && I2C
-   depends on HAS_DMA
select BITREVERSE
select FONT_SUPPORT
select FONT_8x16
diff --git a/drivers/media/pci/sta2x11/Kconfig 
b/drivers/media/pci/sta2x11/Kconfig
index 7af3f1cbcea824b9..4407b9f881e400d8 100644
--- a/drivers/media/pci/sta2x11/Kconfig
+++ b/drivers/media/pci/sta2x11/Kconfig
@@ -1,7 +1,6 @@
 config STA2X11_VIP
tristate "STA2X11 VIP Video For Linux"
depends on STA2X11 || COMPILE_TEST
-   depends on HAS_DMA
select VIDEO_ADV7180 if MEDIA_SUBDRV_AUTOSELECT
select VIDEOBUF2_DMA_CONTIG
depends on PCI && VIDEO_V4L2 && 

Re: [PATCH v7 8/8] media: vsp1: Move video configuration to a cached dlb

[Kieran Bingham]

Hi Laurent,

On 17/05/18 15:35, Laurent Pinchart wrote:
> Hi Kieran,
> 
> On Monday, 30 April 2018 20:48:03 EEST Kieran Bingham wrote:
>> On 07/04/18 01:23, Laurent Pinchart wrote:
>>> On Thursday, 8 March 2018 02:05:31 EEST Kieran Bingham wrote:
 We are now able to configure a pipeline directly into a local display
 list body. Take advantage of this fact, and create a cacheable body to
 store the configuration of the pipeline in the video object.

 vsp1_video_pipeline_run() is now the last user of the pipe->dl object.
 Convert this function to use the cached video->config body and obtain a
 local display list reference.

 Attach the video->config body to the display list when needed before
 committing to hardware.

 The pipe object is marked as un-configured when resuming from a suspend.
 This ensures that when the hardware is reset - our cached configuration
 will be re-attached to the next committed DL.

 Signed-off-by: Kieran Bingham 
 ---

 v3:
  - 's/fragment/body/', 's/fragments/bodies/'
  - video dlb cache allocation increased from 2 to 3 dlbs

 Our video DL usage now looks like the below output:

 dl->body0 contains our disposable runtime configuration. Max 41.
 dl_child->body0 is our partition specific configuration. Max 12.
 dl->bodies shows our constant configuration and LUTs.

   These two are LUT/CLU:
  * dl->bodies[x]->num_entries 256 / max 256
  * dl->bodies[x]->num_entries 4914 / max 4914

 Which shows that our 'constant' configuration cache is currently
 utilised to a maximum of 64 entries.

 trace-cmd report | \

 grep max | sed 's/.*vsp1_dl_list_commit://g' | sort | uniq;
   
   dl->body0->num_entries 13 / max 128
   dl->body0->num_entries 14 / max 128
   dl->body0->num_entries 16 / max 128
   dl->body0->num_entries 20 / max 128
   dl->body0->num_entries 27 / max 128
   dl->body0->num_entries 34 / max 128
   dl->body0->num_entries 41 / max 128
   dl_child->body0->num_entries 10 / max 128
   dl_child->body0->num_entries 12 / max 128
   dl->bodies[x]->num_entries 15 / max 128
   dl->bodies[x]->num_entries 16 / max 128
   dl->bodies[x]->num_entries 17 / max 128
   dl->bodies[x]->num_entries 18 / max 128
   dl->bodies[x]->num_entries 20 / max 128
   dl->bodies[x]->num_entries 21 / max 128
   dl->bodies[x]->num_entries 256 / max 256
   dl->bodies[x]->num_entries 31 / max 128
   dl->bodies[x]->num_entries 32 / max 128
   dl->bodies[x]->num_entries 39 / max 128
   dl->bodies[x]->num_entries 40 / max 128
   dl->bodies[x]->num_entries 47 / max 128
   dl->bodies[x]->num_entries 48 / max 128
   dl->bodies[x]->num_entries 4914 / max 4914
   dl->bodies[x]->num_entries 55 / max 128
   dl->bodies[x]->num_entries 56 / max 128
   dl->bodies[x]->num_entries 63 / max 128
   dl->bodies[x]->num_entries 64 / max 128
>>>
>>> This might be useful to capture in the main part of the commit message.
>>>
 v4:
  - Adjust pipe configured flag to be reset on resume rather than suspend
  - rename dl_child, dl_next
  
  drivers/media/platform/vsp1/vsp1_pipe.c  |  7 +++-
  drivers/media/platform/vsp1/vsp1_pipe.h  |  4 +-
  drivers/media/platform/vsp1/vsp1_video.c | 67 -
  drivers/media/platform/vsp1/vsp1_video.h |  2 +-
  4 files changed, 54 insertions(+), 26 deletions(-)

 diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c
 b/drivers/media/platform/vsp1/vsp1_pipe.c index
 5012643583b6..fa445b1a2e38
 100644
 --- a/drivers/media/platform/vsp1/vsp1_pipe.c
 +++ b/drivers/media/platform/vsp1/vsp1_pipe.c
 @@ -249,6 +249,7 @@ void vsp1_pipeline_run(struct vsp1_pipeline *pipe)
vsp1_write(vsp1, VI6_CMD(pipe->output->entity.index),
   VI6_CMD_STRCMD);
pipe->state = VSP1_PIPELINE_RUNNING;
 +  pipe->configured = true;
}

pipe->buffers_ready = 0;
 @@ -470,6 +471,12 @@ void vsp1_pipelines_resume(struct vsp1_device *vsp1)
continue;

spin_lock_irqsave(>irqlock, flags);
 +  /*
 +   * The hardware may have been reset during a suspend and will
 +   * need a full reconfiguration
 +   */
>>>
>>> s/reconfiguration/reconfiguration./
>>>
 +  pipe->configured = false;
 +
>>>
>>> Where does that full reconfiguration occur, given that the
>>> vsp1_pipeline_run() right below sets pipe->configured to true without
>>> performing reconfiguration ?
> Q 
>> It's magic isn't it :D
>>
>> If the pipe->configured flag gets set to false, the next execution of
>> vsp1_pipeline_run() attaches the video->pipe_config (the cached
>> 

Re: [PATCH v3 1/2] media: rc: introduce BPF_PROG_RAWIR_EVENT

[Y Song]

On Wed, May 16, 2018 at 2:04 PM, Sean Young  wrote:
> Add support for BPF_PROG_RAWIR_EVENT. This type of BPF program can call
> rc_keydown() to reported decoded IR scancodes, or rc_repeat() to report
> that the last key should be repeated.
>
> The bpf program can be attached to using the bpf(BPF_PROG_ATTACH) syscall;
> the target_fd must be the /dev/lircN device.
>
> Signed-off-by: Sean Young 
> ---
>  drivers/media/rc/Kconfig   |  13 ++
>  drivers/media/rc/Makefile  |   1 +
>  drivers/media/rc/bpf-rawir-event.c | 363 +
>  drivers/media/rc/lirc_dev.c|  24 ++
>  drivers/media/rc/rc-core-priv.h|  24 ++
>  drivers/media/rc/rc-ir-raw.c   |  14 +-
>  include/linux/bpf_rcdev.h  |  30 +++
>  include/linux/bpf_types.h  |   3 +
>  include/uapi/linux/bpf.h   |  55 -
>  kernel/bpf/syscall.c   |   7 +
>  10 files changed, 531 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/media/rc/bpf-rawir-event.c
>  create mode 100644 include/linux/bpf_rcdev.h
>
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index eb2c3b6eca7f..2172d65b0213 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -25,6 +25,19 @@ config LIRC
>passes raw IR to and from userspace, which is needed for
>IR transmitting (aka "blasting") and for the lirc daemon.
>
> +config BPF_RAWIR_EVENT
> +   bool "Support for eBPF programs attached to lirc devices"
> +   depends on BPF_SYSCALL
> +   depends on RC_CORE=y
> +   depends on LIRC
> +   help
> +  Allow attaching eBPF programs to a lirc device using the bpf(2)
> +  syscall command BPF_PROG_ATTACH. This is supported for raw IR
> +  receivers.
> +
> +  These eBPF programs can be used to decode IR into scancodes, for
> +  IR protocols not supported by the kernel decoders.
> +
>  menuconfig RC_DECODERS
> bool "Remote controller decoders"
> depends on RC_CORE
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index 2e1c87066f6c..74907823bef8 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -5,6 +5,7 @@ obj-y += keymaps/
>  obj-$(CONFIG_RC_CORE) += rc-core.o
>  rc-core-y := rc-main.o rc-ir-raw.o
>  rc-core-$(CONFIG_LIRC) += lirc_dev.o
> +rc-core-$(CONFIG_BPF_RAWIR_EVENT) += bpf-rawir-event.o
>  obj-$(CONFIG_IR_NEC_DECODER) += ir-nec-decoder.o
>  obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
>  obj-$(CONFIG_IR_RC6_DECODER) += ir-rc6-decoder.o
> diff --git a/drivers/media/rc/bpf-rawir-event.c 
> b/drivers/media/rc/bpf-rawir-event.c
> new file mode 100644
> index ..7cb48b8d87b5
> --- /dev/null
> +++ b/drivers/media/rc/bpf-rawir-event.c
> @@ -0,0 +1,363 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// bpf-rawir-event.c - handles bpf
> +//
> +// Copyright (C) 2018 Sean Young 
> +
> +#include 
> +#include 
> +#include 
> +#include "rc-core-priv.h"
> +
> +/*
> + * BPF interface for raw IR
> + */
> +const struct bpf_prog_ops rawir_event_prog_ops = {
> +};
> +
> +BPF_CALL_1(bpf_rc_repeat, struct bpf_rawir_event*, event)
> +{
> +   struct ir_raw_event_ctrl *ctrl;
> +
> +   ctrl = container_of(event, struct ir_raw_event_ctrl, bpf_rawir_event);
> +
> +   rc_repeat(ctrl->dev);
> +
> +   return 0;
> +}
> +
> +static const struct bpf_func_proto rc_repeat_proto = {
> +   .func  = bpf_rc_repeat,
> +   .gpl_only  = true, /* rc_repeat is EXPORT_SYMBOL_GPL */
> +   .ret_type  = RET_INTEGER,
> +   .arg1_type = ARG_PTR_TO_CTX,
> +};
> +
> +BPF_CALL_4(bpf_rc_keydown, struct bpf_rawir_event*, event, u32, protocol,
> +  u32, scancode, u32, toggle)
> +{
> +   struct ir_raw_event_ctrl *ctrl;
> +
> +   ctrl = container_of(event, struct ir_raw_event_ctrl, bpf_rawir_event);
> +
> +   rc_keydown(ctrl->dev, protocol, scancode, toggle != 0);
> +
> +   return 0;
> +}
> +
> +static const struct bpf_func_proto rc_keydown_proto = {
> +   .func  = bpf_rc_keydown,
> +   .gpl_only  = true, /* rc_keydown is EXPORT_SYMBOL_GPL */
> +   .ret_type  = RET_INTEGER,
> +   .arg1_type = ARG_PTR_TO_CTX,
> +   .arg2_type = ARG_ANYTHING,
> +   .arg3_type = ARG_ANYTHING,
> +   .arg4_type = ARG_ANYTHING,
> +};
> +
> +static const struct bpf_func_proto *
> +rawir_event_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
> +{
> +   switch (func_id) {
> +   case BPF_FUNC_rc_repeat:
> +   return _repeat_proto;
> +   case BPF_FUNC_rc_keydown:
> +   return _keydown_proto;
> +   case BPF_FUNC_map_lookup_elem:
> +   return _map_lookup_elem_proto;
> +   case BPF_FUNC_map_update_elem:
> +   return _map_update_elem_proto;
> +   case BPF_FUNC_map_delete_elem:
> +   return _map_delete_elem_proto;
> +   case BPF_FUNC_ktime_get_ns:
> 

Re: [PATCH 2/4] media: venus: add a routine to reset ARM9

[Jordan Crouse]

On Thu, May 17, 2018 at 05:02:18PM +0530, Vikash Garodia wrote:
> Add a new routine to reset the ARM9 and brings it
> out of reset. This is in preparation to add PIL
> functionality in venus driver.
> 
> Signed-off-by: Vikash Garodia 
> ---
>  drivers/media/platform/qcom/venus/firmware.c | 26 
> 
>  drivers/media/platform/qcom/venus/firmware.h |  1 +
>  drivers/media/platform/qcom/venus/hfi_venus_io.h |  5 +
>  3 files changed, 32 insertions(+)
> 
> diff --git a/drivers/media/platform/qcom/venus/firmware.c 
> b/drivers/media/platform/qcom/venus/firmware.c
> index c4a5778..8f25375 100644
> --- a/drivers/media/platform/qcom/venus/firmware.c
> +++ b/drivers/media/platform/qcom/venus/firmware.c
> @@ -14,6 +14,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -22,11 +23,36 @@
>  #include 
>  #include 
>  
> +#include "core.h"
>  #include "firmware.h"
> +#include "hfi_venus_io.h"
>  
>  #define VENUS_PAS_ID 9
>  #define VENUS_FW_MEM_SIZE(6 * SZ_1M)
>  
> +void venus_reset_hw(struct venus_core *core)
> +{
> + void __iomem *reg_base = core->base;
> +
> + writel(0, reg_base + WRAPPER_FW_START_ADDR);
> + writel(VENUS_FW_MEM_SIZE, reg_base + WRAPPER_FW_END_ADDR);
> + writel(0, reg_base + WRAPPER_CPA_START_ADDR);
> + writel(VENUS_FW_MEM_SIZE, reg_base + WRAPPER_CPA_END_ADDR);
> + writel(0x0, reg_base + WRAPPER_CPU_CGC_DIS);
> + writel(0x0, reg_base + WRAPPER_CPU_CLOCK_CONFIG);

If you are going to have a bunch of writel() functions followed by a barrier it
wouldn't hurt to use writel_relaxed() instead.

Jordan

> + /* Make sure all register writes are committed. */
> + mb();
> +
> + /*
> +  * Need to wait 10 cycles of internal clocks before bringing ARM9
> +  * out of reset.
> +  */
> + udelay(1);
> +
> + /* Bring Arm9 out of reset */
> + writel_relaxed(0, reg_base + WRAPPER_A9SS_SW_RESET);
> +}
>  int venus_boot(struct device *dev, const char *fwname)
>  {
>   const struct firmware *mdt;
> diff --git a/drivers/media/platform/qcom/venus/firmware.h 
> b/drivers/media/platform/qcom/venus/firmware.h
> index 428efb5..d56f5b2 100644
> --- a/drivers/media/platform/qcom/venus/firmware.h
> +++ b/drivers/media/platform/qcom/venus/firmware.h
> @@ -18,5 +18,6 @@
>  
>  int venus_boot(struct device *dev, const char *fwname);
>  int venus_shutdown(struct device *dev);
> +void venus_reset_hw(struct venus_core *core);
>  
>  #endif
> diff --git a/drivers/media/platform/qcom/venus/hfi_venus_io.h 
> b/drivers/media/platform/qcom/venus/hfi_venus_io.h
> index 76f4793..39afa5d 100644
> --- a/drivers/media/platform/qcom/venus/hfi_venus_io.h
> +++ b/drivers/media/platform/qcom/venus/hfi_venus_io.h
> @@ -109,6 +109,11 @@
>  #define WRAPPER_CPU_CGC_DIS  (WRAPPER_BASE + 0x2010)
>  #define WRAPPER_CPU_STATUS   (WRAPPER_BASE + 0x2014)
>  #define WRAPPER_SW_RESET (WRAPPER_BASE + 0x3000)
> +#define WRAPPER_CPA_START_ADDR   (WRAPPER_BASE + 0x1020)
> +#define WRAPPER_CPA_END_ADDR (WRAPPER_BASE + 0x1024)
> +#define WRAPPER_FW_START_ADDR(WRAPPER_BASE + 0x1028)
> +#define WRAPPER_FW_END_ADDR  (WRAPPER_BASE + 0x102C)
> +#define WRAPPER_A9SS_SW_RESET(WRAPPER_BASE + 0x3000)
>  
>  /* Venus 4xx */
>  #define WRAPPER_VCODEC0_MMCC_POWER_STATUS(WRAPPER_BASE + 0x90)

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 1/4] soc: qcom: mdt_loader: Add check to make scm calls

[Jordan Crouse]

On Thu, May 17, 2018 at 05:02:17PM +0530, Vikash Garodia wrote:
> In order to invoke scm calls, ensure that the platform
> has the required support to invoke the scm calls in
> secure world.
> 
> Signed-off-by: Vikash Garodia 
> ---
>  drivers/soc/qcom/mdt_loader.c | 21 +
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
> index 17b314d..db55d53 100644
> --- a/drivers/soc/qcom/mdt_loader.c
> +++ b/drivers/soc/qcom/mdt_loader.c
> @@ -121,10 +121,12 @@ int qcom_mdt_load(struct device *dev, const struct 
> firmware *fw,
>   if (!fw_name)
>   return -ENOMEM;
>  
> - ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size);
> - if (ret) {
> - dev_err(dev, "invalid firmware metadata\n");
> - goto out;
> + if (qcom_scm_is_available()) {
> + ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size);
> + if (ret) {
> + dev_err(dev, "invalid firmware metadata\n");
> + goto out;
> + }
>   }
>
>   for (i = 0; i < ehdr->e_phnum; i++) {
> @@ -144,10 +146,13 @@ int qcom_mdt_load(struct device *dev, const struct 
> firmware *fw,
>   }
>  
>   if (relocate) {
> - ret = qcom_scm_pas_mem_setup(pas_id, mem_phys, max_addr - 
> min_addr);
> - if (ret) {
> - dev_err(dev, "unable to setup relocation\n");
> - goto out;
> + if (qcom_scm_is_available()) {
> + ret = qcom_scm_pas_mem_setup(pas_id, mem_phys,
> + max_addr - min_addr);
> + if (ret) {
> + dev_err(dev, "unable to setup relocation\n");
> + goto out;
> + }
>   }
>  

As far as I can tell you can make it all the way through the function with
'ret' uninitialized if qcom_scm_is_available() returns false which is a bug, but
I'm confused why you would even bother loading the firmware even if you didn't
have SCM.

Jordan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v7 8/8] media: vsp1: Move video configuration to a cached dlb

[Laurent Pinchart]

Hi Kieran,

On Monday, 30 April 2018 20:48:03 EEST Kieran Bingham wrote:
> On 07/04/18 01:23, Laurent Pinchart wrote:
> > On Thursday, 8 March 2018 02:05:31 EEST Kieran Bingham wrote:
> >> We are now able to configure a pipeline directly into a local display
> >> list body. Take advantage of this fact, and create a cacheable body to
> >> store the configuration of the pipeline in the video object.
> >> 
> >> vsp1_video_pipeline_run() is now the last user of the pipe->dl object.
> >> Convert this function to use the cached video->config body and obtain a
> >> local display list reference.
> >> 
> >> Attach the video->config body to the display list when needed before
> >> committing to hardware.
> >> 
> >> The pipe object is marked as un-configured when resuming from a suspend.
> >> This ensures that when the hardware is reset - our cached configuration
> >> will be re-attached to the next committed DL.
> >> 
> >> Signed-off-by: Kieran Bingham 
> >> ---
> >> 
> >> v3:
> >>  - 's/fragment/body/', 's/fragments/bodies/'
> >>  - video dlb cache allocation increased from 2 to 3 dlbs
> >> 
> >> Our video DL usage now looks like the below output:
> >> 
> >> dl->body0 contains our disposable runtime configuration. Max 41.
> >> dl_child->body0 is our partition specific configuration. Max 12.
> >> dl->bodies shows our constant configuration and LUTs.
> >> 
> >>   These two are LUT/CLU:
> >>  * dl->bodies[x]->num_entries 256 / max 256
> >>  * dl->bodies[x]->num_entries 4914 / max 4914
> >> 
> >> Which shows that our 'constant' configuration cache is currently
> >> utilised to a maximum of 64 entries.
> >> 
> >> trace-cmd report | \
> >> 
> >> grep max | sed 's/.*vsp1_dl_list_commit://g' | sort | uniq;
> >>   
> >>   dl->body0->num_entries 13 / max 128
> >>   dl->body0->num_entries 14 / max 128
> >>   dl->body0->num_entries 16 / max 128
> >>   dl->body0->num_entries 20 / max 128
> >>   dl->body0->num_entries 27 / max 128
> >>   dl->body0->num_entries 34 / max 128
> >>   dl->body0->num_entries 41 / max 128
> >>   dl_child->body0->num_entries 10 / max 128
> >>   dl_child->body0->num_entries 12 / max 128
> >>   dl->bodies[x]->num_entries 15 / max 128
> >>   dl->bodies[x]->num_entries 16 / max 128
> >>   dl->bodies[x]->num_entries 17 / max 128
> >>   dl->bodies[x]->num_entries 18 / max 128
> >>   dl->bodies[x]->num_entries 20 / max 128
> >>   dl->bodies[x]->num_entries 21 / max 128
> >>   dl->bodies[x]->num_entries 256 / max 256
> >>   dl->bodies[x]->num_entries 31 / max 128
> >>   dl->bodies[x]->num_entries 32 / max 128
> >>   dl->bodies[x]->num_entries 39 / max 128
> >>   dl->bodies[x]->num_entries 40 / max 128
> >>   dl->bodies[x]->num_entries 47 / max 128
> >>   dl->bodies[x]->num_entries 48 / max 128
> >>   dl->bodies[x]->num_entries 4914 / max 4914
> >>   dl->bodies[x]->num_entries 55 / max 128
> >>   dl->bodies[x]->num_entries 56 / max 128
> >>   dl->bodies[x]->num_entries 63 / max 128
> >>   dl->bodies[x]->num_entries 64 / max 128
> > 
> > This might be useful to capture in the main part of the commit message.
> > 
> >> v4:
> >>  - Adjust pipe configured flag to be reset on resume rather than suspend
> >>  - rename dl_child, dl_next
> >>  
> >>  drivers/media/platform/vsp1/vsp1_pipe.c  |  7 +++-
> >>  drivers/media/platform/vsp1/vsp1_pipe.h  |  4 +-
> >>  drivers/media/platform/vsp1/vsp1_video.c | 67 -
> >>  drivers/media/platform/vsp1/vsp1_video.h |  2 +-
> >>  4 files changed, 54 insertions(+), 26 deletions(-)
> >> 
> >> diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c
> >> b/drivers/media/platform/vsp1/vsp1_pipe.c index
> >> 5012643583b6..fa445b1a2e38
> >> 100644
> >> --- a/drivers/media/platform/vsp1/vsp1_pipe.c
> >> +++ b/drivers/media/platform/vsp1/vsp1_pipe.c
> >> @@ -249,6 +249,7 @@ void vsp1_pipeline_run(struct vsp1_pipeline *pipe)
> >>vsp1_write(vsp1, VI6_CMD(pipe->output->entity.index),
> >>   VI6_CMD_STRCMD);
> >>pipe->state = VSP1_PIPELINE_RUNNING;
> >> +  pipe->configured = true;
> >>}
> >>
> >>pipe->buffers_ready = 0;
> >> @@ -470,6 +471,12 @@ void vsp1_pipelines_resume(struct vsp1_device *vsp1)
> >>continue;
> >>
> >>spin_lock_irqsave(>irqlock, flags);
> >> +  /*
> >> +   * The hardware may have been reset during a suspend and will
> >> +   * need a full reconfiguration
> >> +   */
> > 
> > s/reconfiguration/reconfiguration./
> > 
> >> +  pipe->configured = false;
> >> +
> > 
> > Where does that full reconfiguration occur, given that the
> > vsp1_pipeline_run() right below sets pipe->configured to true without
> > performing reconfiguration ?
Q 
> It's magic isn't it :D
> 
> If the pipe->configured flag gets set to false, the next execution of
> vsp1_pipeline_run() attaches the video->pipe_config (the cached
> configuration, containing the route_setup() and the 

Re: [PATCH 0/7] i2c: clean up include/linux/i2c-*

[Wolfram Sang]

On Thu, Apr 19, 2018 at 10:00:06PM +0200, Wolfram Sang wrote:
> Move all plain platform_data includes to the platform_data-dir
> (except for i2c-pnx which can be moved into the driver itself).
> 
> My preference is to take these patches via the i2c tree. I can provide an
> immutable branch if needed. But we can also discuss those going in via
> arch-trees if dependencies are against us.

All applied to for-next!

The immutable branch is here:

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
i2c/platform_data-immutable

Thanks,

   Wolfram



signature.asc
Description: PGP signature

[PATCH v2 2/2] v4l: Add support for STD ioctls on subdev nodes

[Niklas Söderlund]

There is no way to control the standard of subdevices which are part of
a media device. The ioctls which exists all target video devices
explicitly and the idea is that the video device should talk to the
subdevice. For subdevices part of a media graph this is not possible and
the standard must be controlled on the subdev device directly.

Add four new ioctls to be able to directly interact with subdevices and
control the video standard; VIDIOC_SUBDEV_ENUMSTD, VIDIOC_SUBDEV_G_STD,
VIDIOC_SUBDEV_S_STD and VIDIOC_SUBDEV_QUERYSTD.

Signed-off-by: Niklas Söderlund 

---

* Changes since v1
- Added VIDIOC_SUBDEV_ENUMSTD.
---
 .../media/uapi/v4l/vidioc-enumstd.rst | 11 ++
 Documentation/media/uapi/v4l/vidioc-g-std.rst | 14 
 .../media/uapi/v4l/vidioc-querystd.rst| 11 ++
 drivers/media/v4l2-core/v4l2-subdev.c | 22 +++
 include/uapi/linux/v4l2-subdev.h  |  4 
 5 files changed, 50 insertions(+), 12 deletions(-)

diff --git a/Documentation/media/uapi/v4l/vidioc-enumstd.rst 
b/Documentation/media/uapi/v4l/vidioc-enumstd.rst
index b7fda29f46a139a0..2644a62acd4b6822 100644
--- a/Documentation/media/uapi/v4l/vidioc-enumstd.rst
+++ b/Documentation/media/uapi/v4l/vidioc-enumstd.rst
@@ -2,14 +2,14 @@
 
 .. _VIDIOC_ENUMSTD:
 
-
-ioctl VIDIOC_ENUMSTD
-
+***
+ioctl VIDIOC_ENUMSTD, VIDIOC_SUBDEV_ENUMSTD
+***
 
 Name
 
 
-VIDIOC_ENUMSTD - Enumerate supported video standards
+VIDIOC_ENUMSTD - VIDIOC_SUBDEV_ENUMSTD - Enumerate supported video standards
 
 
 Synopsis
@@ -18,6 +18,9 @@ Synopsis
 .. c:function:: int ioctl( int fd, VIDIOC_ENUMSTD, struct v4l2_standard *argp )
 :name: VIDIOC_ENUMSTD
 
+.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_ENUMSTD, struct v4l2_standard 
*argp )
+:name: VIDIOC_SUBDEV_ENUMSTD
+
 
 Arguments
 =
diff --git a/Documentation/media/uapi/v4l/vidioc-g-std.rst 
b/Documentation/media/uapi/v4l/vidioc-g-std.rst
index 90791ab51a5371b8..8d94f0404df270db 100644
--- a/Documentation/media/uapi/v4l/vidioc-g-std.rst
+++ b/Documentation/media/uapi/v4l/vidioc-g-std.rst
@@ -2,14 +2,14 @@
 
 .. _VIDIOC_G_STD:
 
-
-ioctl VIDIOC_G_STD, VIDIOC_S_STD
-
+**
+ioctl VIDIOC_G_STD, VIDIOC_S_STD, VIDIOC_SUBDEV_G_STD, VIDIOC_SUBDEV_S_STD
+**
 
 Name
 
 
-VIDIOC_G_STD - VIDIOC_S_STD - Query or select the video standard of the 
current input
+VIDIOC_G_STD - VIDIOC_S_STD - VIDIOC_SUBDEV_G_STD - VIDIOC_SUBDEV_S_STD - 
Query or select the video standard of the current input
 
 
 Synopsis
@@ -21,6 +21,12 @@ Synopsis
 .. c:function:: int ioctl( int fd, VIDIOC_S_STD, const v4l2_std_id *argp )
 :name: VIDIOC_S_STD
 
+.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_G_STD, v4l2_std_id *argp )
+:name: VIDIOC_SUBDEV_G_STD
+
+.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_S_STD, const v4l2_std_id 
*argp )
+:name: VIDIOC_SUBDEV_S_STD
+
 
 Arguments
 =
diff --git a/Documentation/media/uapi/v4l/vidioc-querystd.rst 
b/Documentation/media/uapi/v4l/vidioc-querystd.rst
index cf40bca19b9f8665..a8385cc7481869dd 100644
--- a/Documentation/media/uapi/v4l/vidioc-querystd.rst
+++ b/Documentation/media/uapi/v4l/vidioc-querystd.rst
@@ -2,14 +2,14 @@
 
 .. _VIDIOC_QUERYSTD:
 
-*
-ioctl VIDIOC_QUERYSTD
-*
+*
+ioctl VIDIOC_QUERYSTD, VIDIOC_SUBDEV_QUERYSTD
+*
 
 Name
 
 
-VIDIOC_QUERYSTD - Sense the video standard received by the current input
+VIDIOC_QUERYSTD - VIDIOC_SUBDEV_QUERYSTD - Sense the video standard received 
by the current input
 
 
 Synopsis
@@ -18,6 +18,9 @@ Synopsis
 .. c:function:: int ioctl( int fd, VIDIOC_QUERYSTD, v4l2_std_id *argp )
 :name: VIDIOC_QUERYSTD
 
+.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_QUERYSTD, v4l2_std_id *argp )
+:name: VIDIOC_SUBDEV_QUERYSTD
+
 
 Arguments
 =
diff --git a/drivers/media/v4l2-core/v4l2-subdev.c 
b/drivers/media/v4l2-core/v4l2-subdev.c
index f9eed938d3480b74..27a2c633f2323f5f 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -494,6 +494,28 @@ static long subdev_do_ioctl(struct file *file, unsigned 
int cmd, void *arg)
 
case VIDIOC_SUBDEV_S_DV_TIMINGS:
return v4l2_subdev_call(sd, video, s_dv_timings, arg);
+
+   case VIDIOC_SUBDEV_G_STD:
+   return v4l2_subdev_call(sd, video, g_std, arg);
+
+   case VIDIOC_SUBDEV_S_STD: {
+   v4l2_std_id *std = arg;
+
+   return v4l2_subdev_call(sd, video, s_std, *std);
+   }
+
+   case VIDIOC_SUBDEV_ENUMSTD: 

[PATCH v2 1/2] v4l2-ioctl: create helper to fill in v4l2_standard for ENUMSTD

[Niklas Söderlund]

Prepare for adding a new IOCTL VIDIOC_SUBDEV_ENUMSTD which would
enumerate the standards for a subdevice by breaking out the code which
could be shared between the video and subdevice versions of this IOCTL.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 66 
 include/media/v4l2-ioctl.h   | 11 +
 2 files changed, 48 insertions(+), 29 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index a40dbec271f1d9fe..1b5893373358ad5e 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -125,6 +125,42 @@ int v4l2_video_std_construct(struct v4l2_standard *vs,
 }
 EXPORT_SYMBOL(v4l2_video_std_construct);
 
+/* Fill in the fields of a v4l2_standard structure according to the
+ * 'id' and 'vs->index' parameters. Returns negative on error. */
+int v4l_video_std_enumstd(struct v4l2_standard *vs, v4l2_std_id id)
+{
+   v4l2_std_id curr_id = 0;
+   unsigned int index = vs->index, i, j = 0;
+   const char *descr = "";
+
+   /* Return -ENODATA if the id for the current input
+  or output is 0, meaning that it doesn't support this API. */
+   if (id == 0)
+   return -ENODATA;
+
+   /* Return norm array in a canonical way */
+   for (i = 0; i <= index && id; i++) {
+   /* last std value in the standards array is 0, so this
+  while always ends there since (id & 0) == 0. */
+   while ((id & standards[j].std) != standards[j].std)
+   j++;
+   curr_id = standards[j].std;
+   descr = standards[j].descr;
+   j++;
+   if (curr_id == 0)
+   break;
+   if (curr_id != V4L2_STD_PAL &&
+   curr_id != V4L2_STD_SECAM &&
+   curr_id != V4L2_STD_NTSC)
+   id &= ~curr_id;
+   }
+   if (i <= index)
+   return -EINVAL;
+
+   v4l2_video_std_construct(vs, curr_id, descr);
+   return 0;
+}
+
 /* - */
 /* some arrays for pretty-printing debug messages of enum types  */
 
@@ -1753,36 +1789,8 @@ static int v4l_enumstd(const struct v4l2_ioctl_ops *ops,
 {
struct video_device *vfd = video_devdata(file);
struct v4l2_standard *p = arg;
-   v4l2_std_id id = vfd->tvnorms, curr_id = 0;
-   unsigned int index = p->index, i, j = 0;
-   const char *descr = "";
-
-   /* Return -ENODATA if the tvnorms for the current input
-  or output is 0, meaning that it doesn't support this API. */
-   if (id == 0)
-   return -ENODATA;
 
-   /* Return norm array in a canonical way */
-   for (i = 0; i <= index && id; i++) {
-   /* last std value in the standards array is 0, so this
-  while always ends there since (id & 0) == 0. */
-   while ((id & standards[j].std) != standards[j].std)
-   j++;
-   curr_id = standards[j].std;
-   descr = standards[j].descr;
-   j++;
-   if (curr_id == 0)
-   break;
-   if (curr_id != V4L2_STD_PAL &&
-   curr_id != V4L2_STD_SECAM &&
-   curr_id != V4L2_STD_NTSC)
-   id &= ~curr_id;
-   }
-   if (i <= index)
-   return -EINVAL;
-
-   v4l2_video_std_construct(p, curr_id, descr);
-   return 0;
+   return v4l_video_std_enumstd(p, vfd->tvnorms);
 }
 
 static int v4l_s_std(const struct v4l2_ioctl_ops *ops,
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index a7b3f7c75d628b06..fa0463a1b19dc880 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -642,6 +642,17 @@ void v4l2_video_std_frame_period(int id, struct v4l2_fract 
*frameperiod);
 int v4l2_video_std_construct(struct v4l2_standard *vs,
int id, const char *name);
 
+/**
+ * v4l_video_std_enumstd - Ancillary routine that fills in the fields of
+ * a _standard structure according to the @id and @vs->index
+ * parameters.
+ *
+ * @vs: struct _standard pointer to be filled.
+ * @id: analog TV sdandard ID.
+ *
+ */
+int v4l_video_std_enumstd(struct v4l2_standard *vs, v4l2_std_id id);
+
 /**
  * v4l_printk_ioctl - Ancillary routine that prints the ioctl in a
  * human-readable format.
-- 
2.17.0

[PATCH v2 0/2] v4l: Add support for STD ioctls on subdev nodes

[Niklas Söderlund]

Hi Hans,

This series enables the video standards to be controlled directly on the 
subdev device node. This is needed as there is no way to control the 
standard of a subdevice if it's part of a media controller centric setup 
as oppose to a video centric one.

I have tested this on Renesas Gen3 Salvator-XS M3-N using the AFE
subdevice from the adv748x driver together with the R-Car VIN and CSI-2
pipeline. And verified ENUMSTD still works for video device centric 
devices on Renesas Gen2 Koelsch board.

I wrote a prototype patch for v4l2-ctl which adds four new options
(--get-subdev-standard, --get-subdev-standard, --set-subdev-standard and
--get-subdev-detected-standard) to ease testing which I plan to submit
after some cleanup if this patch receives positive feedback.

If you or anyone else is interested in testing this patch the v4l2-utils
prototype patches are available at

git://git.ragnatech.se/v4l-utils#subdev-std

* Changes since v1
- Add VIDIOC_SUBDEV_ENUMSTD.

Niklas Söderlund (2):
  v4l2-ioctl: create helper to fill in v4l2_standard for ENUMSTD
  v4l: Add support for STD ioctls on subdev nodes

 .../media/uapi/v4l/vidioc-enumstd.rst | 11 ++--
 Documentation/media/uapi/v4l/vidioc-g-std.rst | 14 ++--
 .../media/uapi/v4l/vidioc-querystd.rst| 11 ++--
 drivers/media/v4l2-core/v4l2-ioctl.c  | 66 +++
 drivers/media/v4l2-core/v4l2-subdev.c | 22 +++
 include/media/v4l2-ioctl.h| 11 
 include/uapi/linux/v4l2-subdev.h  |  4 ++
 7 files changed, 98 insertions(+), 41 deletions(-)

-- 
2.17.0

Re: [PATCH v3 1/2] media: rc: introduce BPF_PROG_RAWIR_EVENT

[Sean Young]

Hi Quentin,

On Thu, May 17, 2018 at 01:10:56PM +0100, Quentin Monnet wrote:
> 2018-05-16 22:04 UTC+0100 ~ Sean Young 
> > Add support for BPF_PROG_RAWIR_EVENT. This type of BPF program can call
> > rc_keydown() to reported decoded IR scancodes, or rc_repeat() to report
> > that the last key should be repeated.
> > 
> > The bpf program can be attached to using the bpf(BPF_PROG_ATTACH) syscall;
> > the target_fd must be the /dev/lircN device.
> > 
> > Signed-off-by: Sean Young 
> > ---
> >  drivers/media/rc/Kconfig   |  13 ++
> >  drivers/media/rc/Makefile  |   1 +
> >  drivers/media/rc/bpf-rawir-event.c | 363 +
> >  drivers/media/rc/lirc_dev.c|  24 ++
> >  drivers/media/rc/rc-core-priv.h|  24 ++
> >  drivers/media/rc/rc-ir-raw.c   |  14 +-
> >  include/linux/bpf_rcdev.h  |  30 +++
> >  include/linux/bpf_types.h  |   3 +
> >  include/uapi/linux/bpf.h   |  55 -
> >  kernel/bpf/syscall.c   |   7 +
> >  10 files changed, 531 insertions(+), 3 deletions(-)
> >  create mode 100644 drivers/media/rc/bpf-rawir-event.c
> >  create mode 100644 include/linux/bpf_rcdev.h
> > 
> 
> [...]
> 
> Hi Sean,
> 
> Please find below some nitpicks on the documentation for the two helpers.

I agree with all your points. I will reword and fix this for v4.

Thanks,

Sean
> 
> > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > index d94d333a8225..243e141e8a5b 100644
> > --- a/include/uapi/linux/bpf.h
> > +++ b/include/uapi/linux/bpf.h
> 
> [...]
> 
> > @@ -1902,6 +1904,35 @@ union bpf_attr {
> >   * egress otherwise). This is the only flag supported for now.
> >   * Return
> >   * **SK_PASS** on success, or **SK_DROP** on error.
> > + *
> > + * int bpf_rc_keydown(void *ctx, u32 protocol, u32 scancode, u32 toggle)
> > + * Description
> > + * Report decoded scancode with toggle value. For use in
> > + * BPF_PROG_TYPE_RAWIR_EVENT, to report a successfully
> 
> Could you please use bold RST markup for constants and function names?
> Typically for BPF_PROG_TYPE_RAWIR_EVENT here and the enum below.
> 
> > + * decoded scancode. This is will generate a keydown event,
> 
> s/This is will/This will/?
> 
> > + * and a keyup event once the scancode is no longer repeated.
> > + *
> > + * *ctx* pointer to bpf_rawir_event, *protocol* is decoded
> > + * protocol (see RC_PROTO_* enum).
> 
> This documentation is intended to be compiled as a man page. Could you
> please use a complete sentence here?
> Also, this could do with additional markup as well: **struct
> bpf_rawir_event**.
> 
> > + *
> > + * Some protocols include a toggle bit, in case the button
> > + * was released and pressed again between consecutive scancodes,
> > + * copy this bit into *toggle* if it exists, else set to 0.
> > + *
> > + * Return
> 
> The "Return" lines here and in the second helper use space indent
> instead as tabs (as all other lines do). Would you mind fixing it for
> consistency?
> 
> > + * Always return 0 (for now)
> 
> Other helpers use just "0" in that case, but I do not really mind.
> Out of curiosity, do you have anything specific in mind for changing the
> return value here in the future?

I don't expect this is to change, so I should just "0".

> 
> > + *
> > + * int bpf_rc_repeat(void *ctx)
> > + * Description
> > + * Repeat the last decoded scancode; some IR protocols like
> > + * NEC have a special IR message for repeat last button,
> 
> s/repeat/repeating/?
> 
> > + * in case user is holding a button down; the scancode is
> > + * not repeated.
> > + *
> > + * *ctx* pointer to bpf_rawir_event.
> 
> Please use a complete sentence here as well, if you do not mind.
> 
> > + *
> > + * Return
> > + * Always return 0 (for now)
> >   */
> Thanks,
> Quentin

Re: [PATCH v2 11/12] media: ov5640: Add 60 fps support

[Hugues FRUCHET]

Hi Maxime,

Thanks for fixes !

No special modification of v4l2-ctl, I'm using currently v4l-utils 1.12.3.
What output do you have ?

Best regards,
Hugues.

On 05/17/2018 10:52 AM, Maxime Ripard wrote:
> Hi Hugues,
> 
> On Tue, May 15, 2018 at 01:33:55PM +, Hugues FRUCHET wrote:
>> I've taken the whole serie and made some tests on STM32 platform using
>> DVP parallel interface.
>> Now JPEG is OK and I've not seen any regressions appart on framerate
>> control linked to this current patchset.
> 
> Thanks a lot for your feedback, I've (hopefully) fixed all the issues
> you reported here, most of the time taking your fix directly, except
> for 2 where I reworked the code instead.
> 
>> Here are issues observed around framerate control:
>> 1) Framerate enumeration is buggy and all resolutions are claimed
>> supporting 15/30/60:
>> v4l2-ctl --list-formats-ext
>> ioctl: VIDIOC_ENUM_FMT
>>   Index   : 0
>>   Type: Video Capture
>>   Pixel Format: 'JPEG' (compressed)
>>   Name: JFIF JPEG
>>   Size: Discrete 176x144
>>   Interval: Discrete 0.067s (15.000 fps)
>>   Interval: Discrete 0.033s (30.000 fps)
>>   Interval: Discrete 0.017s (60.000 fps)
> 
> One small question though, I don't seem to have that output for
> v4l2-ctl, is some hook needed in the v4l2 device for it to work?
> 
> Maxime
> 

Re: [PATCH v9 6/8] media: vsp1: Refactor display list configure operations

[Kieran Bingham]

Hi Laurent,

Thanks for the review,

On 17/05/18 10:41, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Thursday, 3 May 2018 16:35:45 EEST Kieran Bingham wrote:
>> The entities provide a single .configure operation which configures the
>> object into the target display list, based on the vsp1_entity_params
>> selection.
>>
>> Split the configure function into three parts, '.configure_stream()',
>> '.configure_frame()', and '.configure_partition()' to facilitate
>> splitting the configuration of each parameter class into separate
>> display list bodies.
>>
>> Signed-off-by: Kieran Bingham 
>>
>> ---
>> The checkpatch warning:
>>
>> WARNING: function definition argument 'struct vsp1_dl_list *' should
>> also have an identifier name
>>
>> has been ignored to match the existing code style.
>>
>> v8:
>>  - Add support for the UIF
>>  - Remove unrelated whitespace change
>>  - Fix comment location for clu_configure_stream()
>>  - Update configure documentations
>>  - Implement configure_partition separation.
>>
>> v7
>>  - Fix formatting and white space
>>  - s/prepare/configure_stream/
>>  - s/configure/configure_frame/
>> ---
>>  drivers/media/platform/vsp1/vsp1_brx.c|  12 +-
>>  drivers/media/platform/vsp1/vsp1_clu.c|  77 ++
>>  drivers/media/platform/vsp1/vsp1_drm.c|  12 +-
>>  drivers/media/platform/vsp1/vsp1_entity.c |  24 ++-
>>  drivers/media/platform/vsp1/vsp1_entity.h |  39 +--
>>  drivers/media/platform/vsp1/vsp1_hgo.c|  12 +-
>>  drivers/media/platform/vsp1/vsp1_hgt.c|  12 +-
>>  drivers/media/platform/vsp1/vsp1_hsit.c   |  12 +-
>>  drivers/media/platform/vsp1/vsp1_lif.c|  12 +-
>>  drivers/media/platform/vsp1/vsp1_lut.c|  47 +---
>>  drivers/media/platform/vsp1/vsp1_rpf.c| 168 ++---
>>  drivers/media/platform/vsp1/vsp1_sru.c|  12 +-
>>  drivers/media/platform/vsp1/vsp1_uds.c|  56 ++--
>>  drivers/media/platform/vsp1/vsp1_uif.c|  16 +-
>>  drivers/media/platform/vsp1/vsp1_video.c  |  28 +--
>>  drivers/media/platform/vsp1/vsp1_wpf.c| 303 ---
>>  16 files changed, 422 insertions(+), 420 deletions(-)
> 
> [snip]
> 
>> diff --git a/drivers/media/platform/vsp1/vsp1_clu.c
>> b/drivers/media/platform/vsp1/vsp1_clu.c index ea83f1b7d125..0a978980d447
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_clu.c
>> +++ b/drivers/media/platform/vsp1/vsp1_clu.c
>> @@ -168,58 +168,50 @@ static const struct v4l2_subdev_ops clu_ops = {
>>  /* 
>>   * VSP1 Entity Operations
>>   */
>> +static void clu_configure_stream(struct vsp1_entity *entity,
>> + struct vsp1_pipeline *pipe,
>> + struct vsp1_dl_list *dl)
>> +{
>> +struct vsp1_clu *clu = to_clu(>subdev);
>> +struct v4l2_mbus_framefmt *format;
>>
> 
> I would have kept this blank line before the function.

I would have thought I would too :)

> 
>> -static void clu_configure(struct vsp1_entity *entity,
>> -  struct vsp1_pipeline *pipe,
>> -  struct vsp1_dl_list *dl,
>> -  enum vsp1_entity_params params)
>> +/*
>> + * The yuv_mode can't be changed during streaming. Cache it internally
>> + * for future runtime configuration calls.
>> + */
>> +format = vsp1_entity_get_pad_format(>entity,
>> +clu->entity.config,
>> +CLU_PAD_SINK);
>> +clu->yuv_mode = format->code == MEDIA_BUS_FMT_AYUV8_1X32;
>> +}
> 
> [snip]
> 
>> diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c
>> b/drivers/media/platform/vsp1/vsp1_wpf.c index 65ed2f849551..da287c27b324
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_wpf.c
>> +++ b/drivers/media/platform/vsp1/vsp1_wpf.c
> 
> [snip]
> 
>> +static void wpf_configure_frame(struct vsp1_entity *entity,
>> +struct vsp1_pipeline *pipe,
>> +struct vsp1_dl_list *dl)
>> +{
>> +struct vsp1_rwpf *wpf = to_rwpf(>subdev);
>> +unsigned long flags;
>> +u32 outfmt = 0;
> 
> No need to initialize outfmt to 0.

Ah yes, indeed!.

>> +
> 
> This blank line isn't needed.
> 
>> +const unsigned int mask = BIT(WPF_CTRL_VFLIP)
>> +| BIT(WPF_CTRL_HFLIP);
>> +
>> +spin_lock_irqsave(>flip.lock, flags);
>> +wpf->flip.active = (wpf->flip.active & ~mask)
>> + | (wpf->flip.pending & mask);
>> +spin_unlock_irqrestore(>flip.lock, flags);
>> +
>> +outfmt = (wpf->alpha << VI6_WPF_OUTFMT_PDV_SHIFT) | wpf->outfmt;
>> +
>> +if (wpf->flip.active & BIT(WPF_CTRL_VFLIP))
>> +outfmt |= VI6_WPF_OUTFMT_FLP;
>> +if (wpf->flip.active & BIT(WPF_CTRL_HFLIP))
>> +outfmt |= VI6_WPF_OUTFMT_HFLP;
>> +
>> +vsp1_wpf_write(wpf, dl, VI6_WPF_OUTFMT, outfmt);
>> +}
> 
> [snip]
> 
> Apart from 

[PATCH v4 09/12] ARM: dts: imx7: Add video mux, csi and mipi_csi and connections

[Rui Miguel Silva]

This patch adds the device tree nodes for csi, video multiplexer and mipi-csi
besides the graph connecting the necessary endpoints to make the media capture
entities to work in imx7 Warp board.

Also add the pin control related with the mipi_csi in that board.

Signed-off-by: Rui Miguel Silva 
---
 arch/arm/boot/dts/imx7s-warp.dts | 51 
 arch/arm/boot/dts/imx7s.dtsi | 28 ++
 2 files changed, 79 insertions(+)

diff --git a/arch/arm/boot/dts/imx7s-warp.dts b/arch/arm/boot/dts/imx7s-warp.dts
index 8a30b148534d..cb175ee2fc9d 100644
--- a/arch/arm/boot/dts/imx7s-warp.dts
+++ b/arch/arm/boot/dts/imx7s-warp.dts
@@ -310,6 +310,57 @@
status = "okay";
 };
 
+ {
+   csi_mux {
+   compatible = "video-mux";
+   mux-controls = < 0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+
+   csi_mux_from_mipi_vc0: endpoint {
+   remote-endpoint = <_vc0_to_csi_mux>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   csi_mux_to_csi: endpoint {
+   remote-endpoint = <_from_csi_mux>;
+   };
+   };
+   };
+};
+
+ {
+   status = "okay";
+
+   port {
+   csi_from_csi_mux: endpoint {
+   remote-endpoint = <_mux_to_csi>;
+   };
+   };
+};
+
+_csi {
+   clock-frequency = <16600>;
+   status = "okay";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   fsl,csis-hs-settle = <3>;
+
+   port@1 {
+   reg = <1>;
+
+   mipi_vc0_to_csi_mux: endpoint {
+   remote-endpoint = <_mux_from_mipi_vc0>;
+   };
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_wdog>;
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 3590dab529f9..0bae41f2944c 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -46,6 +46,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "imx7d-pinfunc.h"
 
 / {
@@ -738,6 +739,17 @@
status = "disabled";
};
 
+   csi: csi@3071 {
+   compatible = "fsl,imx7-csi";
+   reg = <0x3071 0x1>;
+   interrupts = ;
+   clocks = < IMX7D_CLK_DUMMY>,
+   < IMX7D_CSI_MCLK_ROOT_CLK>,
+   < IMX7D_CLK_DUMMY>;
+   clock-names = "axi", "mclk", "dcic";
+   status = "disabled";
+   };
+
lcdif: lcdif@3073 {
compatible = "fsl,imx7d-lcdif", 
"fsl,imx28-lcdif";
reg = <0x3073 0x1>;
@@ -747,6 +759,22 @@
clock-names = "pix", "axi";
status = "disabled";
};
+
+   mipi_csi: mipi-csi@3075 {
+   compatible = "fsl,imx7-mipi-csi2";
+   reg = <0x3075 0x1>;
+   interrupts = ;
+   clocks = < IMX7D_IPG_ROOT_CLK>,
+   < IMX7D_MIPI_CSI_ROOT_CLK>,
+   < 
IMX7D_MIPI_DPHY_ROOT_CLK>;
+   clock-names = "pclk", "wrap", "phy";
+   power-domains = <_mipi_phy>;
+   phy-supply = <_1p0d>;
+   resets = < IMX7_RESET_MIPI_PHY_MRST>;
+   reset-names = "mrst";
+   bus-width = <2>;
+   status = "disabled";
+   };
};
 
aips3: aips-bus@3080 {
-- 
2.17.0

[PATCH v4 03/12] clk: imx7d: fix mipi dphy div parent

[Rui Miguel Silva]

Fix the mipi dphy root divider to mipi_dphy_pre_div, this would remove a orphan
clock and set the correct parent.

before:
cat clk_orphan_summary
 enable  prepare  protect
   clock  countcountcountrate   
accuracy   phase

 mipi_dphy_post_div   110   0  
0 0
mipi_dphy_root_clk110   0  
0 0

cat clk_dump | grep mipi_dphy
mipi_dphy_post_div110   0  
0 0
mipi_dphy_root_clk110   0  
0 0

after:
cat clk_dump | grep mipi_dphy
   mipi_dphy_src 1102400  0 0
   mipi_dphy_cg  1102400  0 0
  mipi_dphy_pre_div  1102400  0 0
 mipi_dphy_post_div  1102400  0 0
mipi_dphy_root_clk   1102400  0 0

Fixes: 8f6d8094b215 ("ARM: imx: add imx7d clk tree support")

Cc: linux-...@vger.kernel.org
Acked-by: Dong Aisheng 
Signed-off-by: Rui Miguel Silva 
---
 drivers/clk/imx/clk-imx7d.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index 975a20d3cc94..f7f4db2e6fa6 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -729,7 +729,7 @@ static void __init imx7d_clocks_init(struct device_node 
*ccm_node)
clks[IMX7D_LCDIF_PIXEL_ROOT_DIV] = 
imx_clk_divider2("lcdif_pixel_post_div", "lcdif_pixel_pre_div", base + 0xa300, 
0, 6);
clks[IMX7D_MIPI_DSI_ROOT_DIV] = imx_clk_divider2("mipi_dsi_post_div", 
"mipi_dsi_pre_div", base + 0xa380, 0, 6);
clks[IMX7D_MIPI_CSI_ROOT_DIV] = imx_clk_divider2("mipi_csi_post_div", 
"mipi_csi_pre_div", base + 0xa400, 0, 6);
-   clks[IMX7D_MIPI_DPHY_ROOT_DIV] = imx_clk_divider2("mipi_dphy_post_div", 
"mipi_csi_dphy_div", base + 0xa480, 0, 6);
+   clks[IMX7D_MIPI_DPHY_ROOT_DIV] = imx_clk_divider2("mipi_dphy_post_div", 
"mipi_dphy_pre_div", base + 0xa480, 0, 6);
clks[IMX7D_SAI1_ROOT_DIV] = imx_clk_divider2("sai1_post_div", 
"sai1_pre_div", base + 0xa500, 0, 6);
clks[IMX7D_SAI2_ROOT_DIV] = imx_clk_divider2("sai2_post_div", 
"sai2_pre_div", base + 0xa580, 0, 6);
clks[IMX7D_SAI3_ROOT_DIV] = imx_clk_divider2("sai3_post_div", 
"sai3_pre_div", base + 0xa600, 0, 6);
-- 
2.17.0

[PATCH v4 11/12] media: imx7.rst: add documentation for i.MX7 media driver

[Rui Miguel Silva]

Add rst document to describe the i.MX7 media driver and also a working
example from the Warp7 board usage with a OV2680 sensor.

Signed-off-by: Rui Miguel Silva 
---
 .../devicetree/bindings/media/imx7.txt|  20 ---
 Documentation/media/v4l-drivers/imx7.rst  | 157 ++
 Documentation/media/v4l-drivers/index.rst |   1 +
 3 files changed, 158 insertions(+), 20 deletions(-)
 create mode 100644 Documentation/media/v4l-drivers/imx7.rst

diff --git a/Documentation/devicetree/bindings/media/imx7.txt 
b/Documentation/devicetree/bindings/media/imx7.txt
index 161cff8e6442..a26372630377 100644
--- a/Documentation/devicetree/bindings/media/imx7.txt
+++ b/Documentation/devicetree/bindings/media/imx7.txt
@@ -1,26 +1,6 @@
 Freescale i.MX7 Media Video Device
 ==
 
-Video Media Controller node

-
-This is the media controller node for video capture support. It is a
-virtual device that lists the camera serial interface nodes that the
-media device will control.
-
-Required properties:
-- compatible : "fsl,imx7-capture-subsystem";
-- ports  : Should contain a list of phandles pointing to camera
-   sensor interface port of CSI
-
-example:
-
-capture-subsystem {
-   compatible = "fsl,imx7-capture-subsystem";
-   ports = <>;
-};
-
-
 mipi_csi2 node
 --
 
diff --git a/Documentation/media/v4l-drivers/imx7.rst 
b/Documentation/media/v4l-drivers/imx7.rst
new file mode 100644
index ..cd1195d391c5
--- /dev/null
+++ b/Documentation/media/v4l-drivers/imx7.rst
@@ -0,0 +1,157 @@
+i.MX7 Video Capture Driver
+==
+
+Introduction
+
+
+The i.MX7 contrary to the i.MX5/6 family does not contain an Image Processing
+Unit (IPU); because of that the capabilities to perform operations or
+manipulation of the capture frames are less feature rich.
+
+For image capture the i.MX7 has three units:
+- CMOS Sensor Interface (CSI)
+- Video Multiplexer
+- MIPI CSI-2 Receiver
+
+::
+   |\
+   MIPI Camera Input ---> MIPI CSI-2 --- > | \
+   |  \
+   | M |
+   | U | -->  CSI ---> Capture
+   | X |
+   |  /
+   Parallel Camera Input > | /
+   |/
+
+For additional information, please refer to the latest versions of the i.MX7
+reference manual [#f1]_.
+
+Entities
+
+
+imx7-mipi-csi2
+--
+
+This is the MIPI CSI-2 receiver entity. It has one sink pad to receive the 
pixel
+data from MIPI CSI-2 camera sensor. It has one source pad, corresponding to the
+virtual channel 0. This module is compliant to previous version of Samsung
+D-phy, and supports two D-PHY Rx Data lanes.
+
+csi_mux
+---
+
+This is the video multiplexer. It has two sink pads to select from either 
camera
+sensor with a parallel interface or from MIPI CSI-2 virtual channel 0.  It has
+a single source pad that routes to the CSI.
+
+csi
+---
+
+The CSI enables the chip to connect directly to external CMOS image sensor. CSI
+can interface directly with Parallel and MIPI CSI-2 buses. It has 256 x 64 FIFO
+to store received image pixel data and embedded DMA controllers to transfer 
data
+from the FIFO through AHB bus.
+
+This entity has one sink pad that receives from the csi_mux entity and a single
+source pad that routes video frames directly to memory buffers. This pad is
+routed to a capture device node.
+
+Usage Notes
+---
+
+To aid in configuration and for backward compatibility with V4L2 applications
+that access controls only from video device nodes, the capture device 
interfaces
+inherit controls from the active entities in the current pipeline, so controls
+can be accessed either directly from the subdev or from the active capture
+device interface. For example, the sensor controls are available either from 
the
+sensor subdevs or from the active capture device.
+
+Warp7 with OV2680
+-
+
+On this platform an OV2680 MIPI CSI-2 module is connected to the internal MIPI
+CSI-2 receiver. The following example configures a video capture pipeline with
+an output of 800x600, and BGGR 10 bit bayer format:
+
+.. code-block:: none
+   # Setup links
+   media-ctl -l "'ov2680 1-0036':0 -> 'imx7-mipi-csis.0':0[1]"
+   media-ctl -l "'imx7-mipi-csis.0':1 -> 'csi_mux':1[1]"
+   media-ctl -l "'csi_mux':2 -> 'csi':0[1]"
+   media-ctl -l "'csi':1 -> 'csi capture':0[1]"
+
+   # Configure pads for pipeline
+   media-ctl -V "'ov2680 1-0036':0 [fmt:SBGGR10_1X10/800x600 field:none]"
+   media-ctl -V "'csi_mux':1 [fmt:SBGGR10_1X10/800x600 field:none]"
+   media-ctl -V "'csi_mux':2 [fmt:SBGGR10_1X10/800x600 field:none]"
+   media-ctl -V "'imx7-mipi-csis.0':0 [fmt:SBGGR10_1X10/800x600 

[PATCH v4 12/12] media: staging/imx: add i.MX7 entries to TODO file

[Rui Miguel Silva]

Add some i.MX7 related entries to TODO file.

Signed-off-by: Rui Miguel Silva 
---
 drivers/staging/media/imx/TODO | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/staging/media/imx/TODO b/drivers/staging/media/imx/TODO
index aeeb15494a49..6f29b5ca5324 100644
--- a/drivers/staging/media/imx/TODO
+++ b/drivers/staging/media/imx/TODO
@@ -45,3 +45,12 @@
 
  Which means a port must not contain mixed-use endpoints, they
  must all refer to media links between V4L2 subdevices.
+
+- i.MX7: all of the above, since it uses the imx media core
+
+- i.MX7: use Frame Interval Monitor
+
+- i.MX7: runtime testing with parallel sensor, links setup and streaming
+
+- i.MX7: runtime testing with different formats, for the time only 10-bit bayer
+  is tested
-- 
2.17.0

[PATCH v4 02/12] media: staging/imx7: add imx7 CSI subdev driver

[Rui Miguel Silva]

This add the media entity subdevice and control driver for the i.MX7
CMOS Sensor Interface.

Signed-off-by: Rui Miguel Silva 
---
 drivers/staging/media/imx/Kconfig  |9 +-
 drivers/staging/media/imx/Makefile |2 +
 drivers/staging/media/imx/imx7-media-csi.c | 1352 
 3 files changed, 1362 insertions(+), 1 deletion(-)
 create mode 100644 drivers/staging/media/imx/imx7-media-csi.c

diff --git a/drivers/staging/media/imx/Kconfig 
b/drivers/staging/media/imx/Kconfig
index bfc17de56b17..40a11f988fc6 100644
--- a/drivers/staging/media/imx/Kconfig
+++ b/drivers/staging/media/imx/Kconfig
@@ -11,7 +11,7 @@ config VIDEO_IMX_MEDIA
  driver for the i.MX5/6 SOC.
 
 if VIDEO_IMX_MEDIA
-menu "i.MX5/6 Media Sub devices"
+menu "i.MX5/6/7 Media Sub devices"
 
 config VIDEO_IMX_CSI
tristate "i.MX5/6 Camera Sensor Interface driver"
@@ -20,5 +20,12 @@ config VIDEO_IMX_CSI
---help---
  A video4linux camera sensor interface driver for i.MX5/6.
 
+config VIDEO_IMX7_CSI
+   tristate "i.MX7 Camera Sensor Interface driver"
+   depends on VIDEO_IMX_MEDIA && VIDEO_DEV && I2C
+   default y
+   ---help---
+ A video4linux camera sensor interface driver for i.MX7.
+
 endmenu
 endif
diff --git a/drivers/staging/media/imx/Makefile 
b/drivers/staging/media/imx/Makefile
index a30b3033f9a3..074f016d3519 100644
--- a/drivers/staging/media/imx/Makefile
+++ b/drivers/staging/media/imx/Makefile
@@ -12,3 +12,5 @@ obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-ic.o
 
 obj-$(CONFIG_VIDEO_IMX_CSI) += imx-media-csi.o
 obj-$(CONFIG_VIDEO_IMX_CSI) += imx6-mipi-csi2.o
+
+obj-$(CONFIG_VIDEO_IMX7_CSI) += imx7-media-csi.o
diff --git a/drivers/staging/media/imx/imx7-media-csi.c 
b/drivers/staging/media/imx/imx7-media-csi.c
new file mode 100644
index ..d739eb8be402
--- /dev/null
+++ b/drivers/staging/media/imx/imx7-media-csi.c
@@ -0,0 +1,1352 @@
+// SPDX-License-Identifier: GPL
+/*
+ * V4L2 Capture CSI Subdev for Freescale i.MX7 SOC
+ *
+ * Copyright (c) 2018 Linaro Ltd
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include "imx-media.h"
+
+#define IMX7_CSI_PAD_SINK  0
+#define IMX7_CSI_PAD_SRC   1
+#define IMX7_CSI_PADS_NUM  2
+
+/* reset values */
+#define CSICR1_RESET_VAL   0x4800
+#define CSICR2_RESET_VAL   0x0
+#define CSICR3_RESET_VAL   0x0
+
+/* csi control reg 1 */
+#define BIT_SWAP16_EN  BIT(31)
+#define BIT_EXT_VSYNC  BIT(30)
+#define BIT_EOF_INT_EN BIT(29)
+#define BIT_PRP_IF_EN  BIT(28)
+#define BIT_CCIR_MODE  BIT(27)
+#define BIT_COF_INT_EN BIT(26)
+#define BIT_SF_OR_INTENBIT(25)
+#define BIT_RF_OR_INTENBIT(24)
+#define BIT_SFF_DMA_DONE_INTEN  BIT(22)
+#define BIT_STATFF_INTEN   BIT(21)
+#define BIT_FB2_DMA_DONE_INTEN  BIT(20)
+#define BIT_FB1_DMA_DONE_INTEN  BIT(19)
+#define BIT_RXFF_INTEN BIT(18)
+#define BIT_SOF_POLBIT(17)
+#define BIT_SOF_INTEN  BIT(16)
+#define BIT_MCLKDIV(0xF << 12)
+#define BIT_HSYNC_POL  BIT(11)
+#define BIT_CCIR_ENBIT(10)
+#define BIT_MCLKEN BIT(9)
+#define BIT_FCCBIT(8)
+#define BIT_PACK_DIR   BIT(7)
+#define BIT_CLR_STATFIFO   BIT(6)
+#define BIT_CLR_RXFIFO BIT(5)
+#define BIT_GCLK_MODE  BIT(4)
+#define BIT_INV_DATA   BIT(3)
+#define BIT_INV_PCLK   BIT(2)
+#define BIT_REDGE  BIT(1)
+#define BIT_PIXEL_BIT  BIT(0)
+
+#define SHIFT_MCLKDIV  12
+
+/* control reg 3 */
+#define BIT_FRMCNT (0x << 16)
+#define BIT_FRMCNT_RST BIT(15)
+#define BIT_DMA_REFLASH_RFFBIT(14)
+#define BIT_DMA_REFLASH_SFFBIT(13)
+#define BIT_DMA_REQ_EN_RFF BIT(12)
+#define BIT_DMA_REQ_EN_SFF BIT(11)
+#define BIT_STATFF_LEVEL   (0x7 << 8)
+#define BIT_HRESP_ERR_EN   BIT(7)
+#define BIT_RXFF_LEVEL (0x7 << 4)
+#define BIT_TWO_8BIT_SENSORBIT(3)
+#define BIT_ZERO_PACK_EN   BIT(2)
+#define BIT_ECC_INT_EN BIT(1)
+#define BIT_ECC_AUTO_ENBIT(0)
+
+#define SHIFT_FRMCNT   16
+#define SHIFT_RXFIFO_LEVEL 4
+
+/* csi status reg */
+#define BIT_ADDR_CH_ERR_INTBIT(28)
+#define BIT_FIELD0_INT BIT(27)
+#define BIT_FIELD1_INT BIT(26)
+#define BIT_SFF_OR_INT BIT(25)
+#define BIT_RFF_OR_INT BIT(24)
+#define BIT_DMA_TSF_DONE_SFF   BIT(22)
+#define BIT_STATFF_INT BIT(21)
+#define BIT_DMA_TSF_DONE_FB2   BIT(20)
+#define BIT_DMA_TSF_DONE_FB1   BIT(19)
+#define BIT_RXFF_INT   BIT(18)
+#define BIT_EOF_INTBIT(17)
+#define BIT_SOF_INTBIT(16)
+#define BIT_F2_INT BIT(15)
+#define BIT_F1_INT BIT(14)
+#define 

[PATCH v4 05/12] media: staging/imx7: add MIPI CSI-2 receiver subdev for i.MX7

[Rui Miguel Silva]

Adds MIPI CSI-2 subdev for i.MX7 to connect with sensors with a MIPI CSI-2
interface.

Signed-off-by: Rui Miguel Silva 
---
 drivers/staging/media/imx/Makefile |1 +
 drivers/staging/media/imx/imx7-mipi-csis.c | 1154 
 2 files changed, 1155 insertions(+)
 create mode 100644 drivers/staging/media/imx/imx7-mipi-csis.c

diff --git a/drivers/staging/media/imx/Makefile 
b/drivers/staging/media/imx/Makefile
index 074f016d3519..d2d909a36239 100644
--- a/drivers/staging/media/imx/Makefile
+++ b/drivers/staging/media/imx/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_VIDEO_IMX_CSI) += imx-media-csi.o
 obj-$(CONFIG_VIDEO_IMX_CSI) += imx6-mipi-csi2.o
 
 obj-$(CONFIG_VIDEO_IMX7_CSI) += imx7-media-csi.o
+obj-$(CONFIG_VIDEO_IMX7_CSI) += imx7-mipi-csis.o
diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c 
b/drivers/staging/media/imx/imx7-mipi-csis.c
new file mode 100644
index ..e56facea36ba
--- /dev/null
+++ b/drivers/staging/media/imx/imx7-mipi-csis.c
@@ -0,0 +1,1154 @@
+// SPDX-License-Identifier: GPL
+/*
+ * Freescale i.MX7 SoC series MIPI-CSI V3.3 receiver driver
+ *
+ * Copyright (C) 2018 Linaro Ltd
+ * Copyright (C) 2015-2016 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright (C) 2011 - 2013 Samsung Electronics Co., Ltd.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "imx-media.h"
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "Debug level (0-2)");
+
+#define CSIS_DRIVER_NAME   "imx7-mipi-csis"
+#define CSIS_SUBDEV_NAME   CSIS_DRIVER_NAME
+
+#define CSIS_PAD_SINK  0
+#define CSIS_PAD_SOURCE1
+#define CSIS_PADS_NUM  2
+
+#define MIPI_CSIS_DEF_PIX_WIDTH640
+#define MIPI_CSIS_DEF_PIX_HEIGHT   480
+
+/* Register map definition */
+
+/* CSIS common control */
+#define MIPI_CSIS_CMN_CTRL 0x04
+#define MIPI_CSIS_CMN_CTRL_UPDATE_SHADOW   BIT(16)
+#define MIPI_CSIS_CMN_CTRL_INTER_MODE  BIT(10)
+#define MIPI_CSIS_CMN_CTRL_UPDATE_SHADOW_CTRL  BIT(2)
+#define MIPI_CSIS_CMN_CTRL_RESET   BIT(1)
+#define MIPI_CSIS_CMN_CTRL_ENABLE  BIT(0)
+
+#define MIPI_CSIS_CMN_CTRL_LANE_NR_OFFSET  8
+#define MIPI_CSIS_CMN_CTRL_LANE_NR_MASK(3 << 8)
+
+/* CSIS clock control */
+#define MIPI_CSIS_CLK_CTRL 0x08
+#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH3(x)(x << 28)
+#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH2(x)(x << 24)
+#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH1(x)(x << 20)
+#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH0(x)(x << 16)
+#define MIPI_CSIS_CLK_CTRL_CLKGATE_EN_MSK  (0xf << 4)
+#define MIPI_CSIS_CLK_CTRL_WCLK_SRCBIT(0)
+
+/* CSIS Interrupt mask */
+#define MIPI_CSIS_INTMSK   0x10
+#define MIPI_CSIS_INTMSK_EVEN_BEFORE   BIT(31)
+#define MIPI_CSIS_INTMSK_EVEN_AFTERBIT(30)
+#define MIPI_CSIS_INTMSK_ODD_BEFOREBIT(29)
+#define MIPI_CSIS_INTMSK_ODD_AFTER BIT(28)
+#define MIPI_CSIS_INTMSK_FRAME_START   BIT(24)
+#define MIPI_CSIS_INTMSK_FRAME_END BIT(20)
+#define MIPI_CSIS_INTMSK_ERR_SOT_HSBIT(16)
+#define MIPI_CSIS_INTMSK_ERR_LOST_FS   BIT(12)
+#define MIPI_CSIS_INTMSK_ERR_LOST_FE   BIT(8)
+#define MIPI_CSIS_INTMSK_ERR_OVER  BIT(4)
+#define MIPI_CSIS_INTMSK_ERR_WRONG_CFG BIT(3)
+#define MIPI_CSIS_INTMSK_ERR_ECC   BIT(2)
+#define MIPI_CSIS_INTMSK_ERR_CRC   BIT(1)
+#define MIPI_CSIS_INTMSK_ERR_UNKNOWN   BIT(0)
+
+/* CSIS Interrupt source */
+#define MIPI_CSIS_INTSRC   0x14
+#define MIPI_CSIS_INTSRC_EVEN_BEFORE   BIT(31)
+#define MIPI_CSIS_INTSRC_EVEN_AFTERBIT(30)
+#define MIPI_CSIS_INTSRC_EVEN  BIT(30)
+#define MIPI_CSIS_INTSRC_ODD_BEFOREBIT(29)
+#define MIPI_CSIS_INTSRC_ODD_AFTER BIT(28)
+#define MIPI_CSIS_INTSRC_ODD   (0x3 << 28)
+#define MIPI_CSIS_INTSRC_NON_IMAGE_DATA(0xf << 28)
+#define MIPI_CSIS_INTSRC_FRAME_START   BIT(24)
+#define MIPI_CSIS_INTSRC_FRAME_END BIT(20)
+#define MIPI_CSIS_INTSRC_ERR_SOT_HSBIT(16)
+#define MIPI_CSIS_INTSRC_ERR_LOST_FS   BIT(12)
+#define MIPI_CSIS_INTSRC_ERR_LOST_FE   BIT(8)
+#define MIPI_CSIS_INTSRC_ERR_OVER  BIT(4)
+#define MIPI_CSIS_INTSRC_ERR_WRONG_CFG BIT(3)
+#define MIPI_CSIS_INTSRC_ERR_ECC   BIT(2)
+#define MIPI_CSIS_INTSRC_ERR_CRC   BIT(1)
+#define MIPI_CSIS_INTSRC_ERR_UNKNOWN   BIT(0)
+#define MIPI_CSIS_INTSRC_ERRORS0xf
+
+/* D-PHY status control */
+#define MIPI_CSIS_DPHYSTATUS   0x20
+#define MIPI_CSIS_DPHYSTATUS_ULPS_DAT  BIT(8)
+#define MIPI_CSIS_DPHYSTATUS_STOPSTATE_DAT BIT(4)
+#define MIPI_CSIS_DPHYSTATUS_ULPS_CLK  BIT(1)
+#define MIPI_CSIS_DPHYSTATUS_STOPSTATE_CLK BIT(0)
+
+/* D-PHY common control */
+#define MIPI_CSIS_DPHYCTRL

[PATCH v4 06/12] media: dt-bindings: add bindings for i.MX7 media driver

[Rui Miguel Silva]

Add bindings documentation for i.MX7 media drivers.

Signed-off-by: Rui Miguel Silva 
---
 .../devicetree/bindings/media/imx7.txt| 145 ++
 1 file changed, 145 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/imx7.txt

diff --git a/Documentation/devicetree/bindings/media/imx7.txt 
b/Documentation/devicetree/bindings/media/imx7.txt
new file mode 100644
index ..161cff8e6442
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/imx7.txt
@@ -0,0 +1,145 @@
+Freescale i.MX7 Media Video Device
+==
+
+Video Media Controller node
+---
+
+This is the media controller node for video capture support. It is a
+virtual device that lists the camera serial interface nodes that the
+media device will control.
+
+Required properties:
+- compatible : "fsl,imx7-capture-subsystem";
+- ports  : Should contain a list of phandles pointing to camera
+   sensor interface port of CSI
+
+example:
+
+capture-subsystem {
+   compatible = "fsl,imx7-capture-subsystem";
+   ports = <>;
+};
+
+
+mipi_csi2 node
+--
+
+This is the device node for the MIPI CSI-2 receiver core in i.MX7 SoC. It is
+compatible with previous version of Samsung D-phy.
+
+Required properties:
+
+- compatible: "fsl,imx7-mipi-csi2";
+- reg   : base address and length of the register set for the device;
+- interrupts: should contain MIPI CSIS interrupt;
+- clocks: list of clock specifiers, see
+Documentation/devicetree/bindings/clock/clock-bindings.txt for details;
+- clock-names   : must contain "pclk", "wrap" and "phy" entries, matching
+  entries in the clock property;
+- power-domains : a phandle to the power domain, see
+  Documentation/devicetree/bindings/power/power_domain.txt for details.
+- reset-names   : should include following entry "mrst";
+- resets: a list of phandle, should contain reset entry of
+  reset-names;
+- phy-supply: from the generic phy bindings, a phandle to a regulator that
+ provides power to MIPI CSIS core;
+- bus-width : maximum number of data lanes supported (SoC specific);
+
+Optional properties:
+
+- clock-frequency : The IP's main (system bus) clock frequency in Hz, default
+   value when this property is not specified is 166 MHz;
+
+port node
+-
+
+- reg: (required) can take the values 0 or 1, where 0 is the
+ related sink port and port 1 should be the source one;
+
+endpoint node
+-
+
+- data-lanes: (required) an array specifying active physical MIPI-CSI2
+   data input lanes and their mapping to logical lanes; the
+   array's content is unused, only its length is meaningful;
+
+- fsl,csis-hs-settle : (optional) differential receiver (HS-RX) settle time;
+
+example:
+
+mipi_csi: mipi-csi@3075 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+compatible = "fsl,imx7-mipi-csi2";
+reg = <0x3075 0x1>;
+interrupts = ;
+clocks = < IMX7D_IPG_ROOT_CLK>,
+< IMX7D_MIPI_CSI_ROOT_CLK>,
+< IMX7D_MIPI_DPHY_ROOT_CLK>;
+clock-names = "pclk", "wrap", "phy";
+clock-names = "mipi", "phy";
+clock-frequency = <16600>;
+power-domains = <_mipi_phy>;
+phy-supply = <_1p0d>;
+resets = < IMX7_RESET_MIPI_PHY_MRST>;
+reset-names = "mrst";
+bus-width = <4>;
+fsl,csis-hs-settle = <3>;
+fsl,csis-clk-settle = <0>;
+
+port@0 {
+reg = <0>;
+
+mipi_from_sensor: endpoint {
+remote-endpoint = <_to_mipi>;
+data-lanes = <1>;
+};
+};
+
+port@1 {
+reg = <1>;
+
+mipi_vc0_to_csi_mux: endpoint {
+remote-endpoint = <_mux_from_mipi_vc0>;
+};
+};
+};
+
+
+csi node
+
+
+This is device node for the CMOS Sensor Interface (CSI) which enables the chip
+to connect directly to external CMOS image sensors.
+
+Required properties:
+
+- compatible: "fsl,imx7-csi";
+- reg   : base address and length of the register set for the device;
+- interrupts: should contain CSI interrupt;
+- clocks: list of clock specifiers, see
+Documentation/devicetree/bindings/clock/clock-bindings.txt for details;
+- clock-names   : must contain "axi", "mclk" and "dcic" entries, matching
+ entries in the clock property;
+
+example:
+
+ 

[PATCH v4 08/12] ARM: dts: imx7s: add multiplexer controls

[Rui Miguel Silva]

The IOMUXC General Purpose Register has bitfield to control video bus
multiplexer to control the CSI input between the MIPI-CSI2 and parallel
interface. Add that register and mask.

Signed-off-by: Rui Miguel Silva 
Reviewed-by: Philipp Zabel 
---
 arch/arm/boot/dts/imx7s.dtsi | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 67450ad89940..3590dab529f9 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -520,8 +520,14 @@
 
gpr: iomuxc-gpr@3034 {
compatible = "fsl,imx7d-iomuxc-gpr",
-   "fsl,imx6q-iomuxc-gpr", "syscon";
+   "fsl,imx6q-iomuxc-gpr", "syscon", 
"simple-mfd";
reg = <0x3034 0x1>;
+
+   mux: mux-controller {
+   compatible = "mmio-mux";
+   #mux-control-cells = <1>;
+   mux-reg-masks = <0x14 0x0010>;
+   };
};
 
ocotp: ocotp-ctrl@3035 {
-- 
2.17.0

[PATCH v4 10/12] ARM: dts: imx7s-warp: add ov2680 sensor node

[Rui Miguel Silva]

Warp7 comes with a Omnivision OV2680 sensor, add the node here to make complete
the camera data path for this system. Add the needed regulator to the analog
voltage supply, the port and endpoints in mipi_csi node and the pinctrl for the
reset gpio.

Signed-off-by: Rui Miguel Silva 
---
 arch/arm/boot/dts/imx7s-warp.dts | 44 
 1 file changed, 44 insertions(+)

diff --git a/arch/arm/boot/dts/imx7s-warp.dts b/arch/arm/boot/dts/imx7s-warp.dts
index cb175ee2fc9d..bf04e13afd02 100644
--- a/arch/arm/boot/dts/imx7s-warp.dts
+++ b/arch/arm/boot/dts/imx7s-warp.dts
@@ -91,6 +91,14 @@
regulator-always-on;
};
 
+   reg_peri_3p15v: regulator-peri-3p15v {
+   compatible = "regulator-fixed";
+   regulator-name = "peri_3p15v_reg";
+   regulator-min-microvolt = <315>;
+   regulator-max-microvolt = <315>;
+   regulator-always-on;
+   };
+
sound {
compatible = "simple-audio-card";
simple-audio-card,name = "imx7-sgtl5000";
@@ -218,6 +226,27 @@
pinctrl-names = "default";
pinctrl-0 = <_i2c2>;
status = "okay";
+
+   ov2680: camera@36 {
+   compatible = "ovti,ov2680";
+   pinctrl-names = "default";
+   pinctrl-0 = <_ov2680>;
+   reg = <0x36>;
+   clocks = <>;
+   clock-names = "xvclk";
+   reset-gpios = < 3 GPIO_ACTIVE_LOW>;
+   DOVDD-supply = <_reg>;
+   DVDD-supply = <_reg>;
+   AVDD-supply = <_peri_3p15v>;
+
+   port {
+   ov2680_to_mipi: endpoint {
+   remote-endpoint = <_from_sensor>;
+   clock-lanes = <0>;
+   data-lanes = <1>;
+   };
+   };
+   };
 };
 
  {
@@ -352,6 +381,15 @@
#size-cells = <0>;
fsl,csis-hs-settle = <3>;
 
+   port@0 {
+   reg = <0>;
+
+   mipi_from_sensor: endpoint {
+   remote-endpoint = <_to_mipi>;
+   data-lanes = <1>;
+   };
+   };
+
port@1 {
reg = <1>;
 
@@ -408,6 +446,12 @@
>;
};
 
+   pinctrl_ov2680: ov2660grp {
+   fsl,pins = <
+   MX7D_PAD_LPSR_GPIO1_IO03__GPIO1_IO3 0x14
+   >;
+   };
+
pinctrl_sai1: sai1grp {
fsl,pins = <
MX7D_PAD_SAI1_RX_DATA__SAI1_RX_DATA00x1f
-- 
2.17.0

[PATCH v4 04/12] clk: imx7d: reset parent for mipi csi root

[Rui Miguel Silva]

To guarantee that we do not get Overflow in image FIFO the outer bandwidth has
to be faster than inputer bandwidth. For that it must be possible to set a
faster frequency clock. So set new parent to sys_pfd3 clock for the mipi csi
block.

Cc: linux-...@vger.kernel.org
Acked-by: Shawn Guo 
Signed-off-by: Rui Miguel Silva 
---
 drivers/clk/imx/clk-imx7d.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index f7f4db2e6fa6..27877d05faa2 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -891,6 +891,8 @@ static void __init imx7d_clocks_init(struct device_node 
*ccm_node)
clk_set_parent(clks[IMX7D_PLL_AUDIO_MAIN_BYPASS], 
clks[IMX7D_PLL_AUDIO_MAIN]);
clk_set_parent(clks[IMX7D_PLL_VIDEO_MAIN_BYPASS], 
clks[IMX7D_PLL_VIDEO_MAIN]);
 
+   clk_set_parent(clks[IMX7D_MIPI_CSI_ROOT_SRC], 
clks[IMX7D_PLL_SYS_PFD3_CLK]);
+
/* use old gpt clk setting, gpt1 root clk must be twice as gpt counter 
freq */
clk_set_parent(clks[IMX7D_GPT1_ROOT_SRC], clks[IMX7D_OSC_24M_CLK]);
 
-- 
2.17.0

[PATCH v4 07/12] ARM: dts: imx7s: add mipi phy power domain

[Rui Miguel Silva]

Add power domain index 0 related with mipi-phy to imx7s.

Signed-off-by: Rui Miguel Silva 
---
 arch/arm/boot/dts/imx7s.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 4d42335c0dee..67450ad89940 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -636,6 +636,12 @@
#address-cells = <1>;
#size-cells = <0>;
 
+   pgc_mipi_phy: pgc-power-domain@0 {
+   #power-domain-cells = <0>;
+   reg = <0>;
+   power-supply = <_1p0d>;
+   };
+
pgc_pcie_phy: pgc-power-domain@1 {
#power-domain-cells = <0>;
reg = <1>;
-- 
2.17.0

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

[Rui Miguel Silva]

Hi,
This series introduces the Media driver to work with the i.MX7 SoC. it uses the
already existing imx media core drivers but since the i.MX7, contrary to
i.MX5/6, do not have an IPU and because of that some changes in the imx media
core are made along this series to make it support that case.

This patches adds CSI and MIPI-CSI2 drivers for i.MX7, along with several
configurations changes for this to work as a capture subsystem. Some bugs are
also fixed along the line. And necessary documentation.

For a more detailed view of the capture paths, pads links in the i.MX7 please
take a look at the documentation in PATCH 14.

The system used to test and develop this was the Warp7 board with an OV2680
sensor, which output format is 10-bit bayer. So, only MIPI interface was
tested, a scenario with an parallel input would nice to have.

*Important note*, this code depends on Steve Longerbeam series [0]:
[PATCH v4 00/13] media: imx: Switch to subdev notifiers
which the merging status is not clear to me, but the changes in there make
senses to this series

Bellow goes an example of the output of the pads and links and the output of
v4l2-compliance testing.

The v4l-utils version used is:
v4l2-compliance SHA   : 47d43b130dc6e9e0edc900759fb37649208371e4 from Apr 4th.

The Media Driver fail some tests but this failures are coming from code out of
scope of this series (video-mux, imx-capture), and some from the sensor OV2680
but that I think not related with the sensor driver but with the testing and
core.

The csi and mipi-csi entities pass all compliance tests.

Cheers,
Rui

[0]: https://www.mail-archive.com/linux-media@vger.kernel.org/msg131186.html

v3->v4:
Philipp Zabel:
 - refactor initialization code from media device probe to be possible to used
   from other modules
 - Remove index of csi from all accurrencs (dts, code, documentation)
 - Remove need for capture node for imx7
 - fix pinctrl for ov2680
 - add reviewed tag to add multiplexer controls patch

Fabio Estevam:
 - remove always on from new regulator

Randy Dunlap:
 - several text editing fixes in documentation

Myself:
 - rebase on top of v4 of Steve series
 - change CSI probe to initialize imx media device
 - remove csi mux parallel endpoint from mux to avoid warning message

v2->v3:
Philipp Zabel:
 - use of_match_device in imx-media-dev instead of of_device_match
 - fix number of data lanes from 4 to 2
 - change the clock definitions and use of mipi
 - move hs-settle from endpoint

Rob Herring:
 - fix phy-supply description
 - add vendor properties
 - fix examples indentations

Stephen Boyd: patch 3/14
 - fix double sign-off
 - add fixes tag

Dong Aisheng: patch 3/14
 - fix double sign-off
 - add Acked-by tag

Shawn Guo:
patch 4/14
 - remove line breakage in parent redifiniton
 - added Acked-by tag

 - dropped CMA area increase and add more verbose information in case of
   dma allocation failure
patch 9/14
 - remove extra line between cells and reg masks

Myself:
 - rework on frame end in csi
 - add rxcount in csi driver
 - add power supplies to ov2680 node and fix gpio polarity

v1->v2:
Dan Carpenter:
 - fix return paths and codes;
 - fix clk_frequency validation and return code;
 - handle the csi remove (release resources that was missing)
 - revert the logic arround the ipu_present flag

Philipp Zabel:
 - drop patch that changed the rgb formats and address the pixel/bus format in
   mipi_csis code.

MySelf:
 - add patch that add ov2680 node to the warp7 dts, so the all data path is
   complete.
 - add linux-clk mailing list to the clock patches cc:

 media-ctl -p
Media controller API version 4.17.0

Media device information

driver  imx-media
model   imx-media
serial
bus info
hw revision 0x0
driver version  4.17.0

Device topology
- entity 1: csi (2 pads, 2 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev0
pad0: Sink
[fmt:SBGGR10_1X10/800x600 field:none]
<- "csi_mux":2 [ENABLED]
pad1: Source
[fmt:SBGGR10_1X10/800x600 field:none]
-> "csi capture":0 [ENABLED]

- entity 4: csi capture (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video0
pad0: Sink
<- "csi":1 [ENABLED]

- entity 10: csi_mux (3 pads, 2 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev1
pad0: Sink
[fmt:unknown/0x0]
pad1: Sink
[fmt:SBGGR10_1X10/800x600 field:none]
<- "imx7-mipi-csis.0":1 [ENABLED]
pad2: Source
[fmt:SBGGR10_1X10/800x600 field:none]
-> "csi":0 [ENABLED]

- entity 14: imx7-mipi-csis.0 (2 pads, 2 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev2
pad0: Sink
[fmt:SBGGR10_1X10/800x600 

[PATCH v4 01/12] media: staging/imx: refactor imx media device probe

[Rui Miguel Silva]

Refactor and move media device initialization code to a new common module, so it
can be used by other devices, this will allow for example a near to introduce
imx7 CSI driver, to use this media device.

Also introduce a new flag to control the presence of IPU or not (imx6/5 has
this but imx7 does not).

Signed-off-by: Rui Miguel Silva 
---
 drivers/staging/media/imx/Makefile|   1 +
 .../staging/media/imx/imx-media-dev-common.c  | 102 ++
 drivers/staging/media/imx/imx-media-dev.c |  89 ---
 .../staging/media/imx/imx-media-internal-sd.c |   3 +
 drivers/staging/media/imx/imx-media-of.c  |   6 +-
 drivers/staging/media/imx/imx-media.h |  18 
 6 files changed, 150 insertions(+), 69 deletions(-)
 create mode 100644 drivers/staging/media/imx/imx-media-dev-common.c

diff --git a/drivers/staging/media/imx/Makefile 
b/drivers/staging/media/imx/Makefile
index 698a4210316e..a30b3033f9a3 100644
--- a/drivers/staging/media/imx/Makefile
+++ b/drivers/staging/media/imx/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 imx-media-objs := imx-media-dev.o imx-media-internal-sd.o imx-media-of.o
+imx-media-objs += imx-media-dev-common.o
 imx-media-common-objs := imx-media-utils.o imx-media-fim.o
 imx-media-ic-objs := imx-ic-common.o imx-ic-prp.o imx-ic-prpencvf.o
 
diff --git a/drivers/staging/media/imx/imx-media-dev-common.c 
b/drivers/staging/media/imx/imx-media-dev-common.c
new file mode 100644
index ..7e9613ca5b5f
--- /dev/null
+++ b/drivers/staging/media/imx/imx-media-dev-common.c
@@ -0,0 +1,102 @@
+// SPDX-License-Identifier: GPL
+/*
+ * V4L2 Media Controller Driver for Freescale common i.MX5/6/7 SOC
+ *
+ * Copyright (c) 2018 Linaro Ltd
+ * Copyright (c) 2016 Mentor Graphics Inc.
+ */
+
+#include 
+#include 
+#include "imx-media.h"
+
+static const struct v4l2_async_notifier_operations imx_media_subdev_ops = {
+   .bound = imx_media_subdev_bound,
+   .complete = imx_media_probe_complete,
+};
+
+static const struct media_device_ops imx_media_md_ops = {
+   .link_notify = imx_media_link_notify,
+};
+
+struct imx_media_dev *imx_media_dev_init(struct device *dev, bool ipu_present)
+{
+   struct imx_media_dev *imxmd;
+   int ret;
+
+   imxmd = devm_kzalloc(dev, sizeof(*imxmd), GFP_KERNEL);
+   if (!imxmd)
+   return ERR_PTR(-ENOMEM);
+
+   dev_set_drvdata(dev, imxmd);
+
+   strlcpy(imxmd->md.model, "imx-media", sizeof(imxmd->md.model));
+   imxmd->md.ops = _media_md_ops;
+   imxmd->md.dev = dev;
+
+   imxmd->ipu_present = ipu_present;
+
+   mutex_init(>mutex);
+
+   imxmd->v4l2_dev.mdev = >md;
+   strlcpy(imxmd->v4l2_dev.name, "imx-media",
+   sizeof(imxmd->v4l2_dev.name));
+
+   media_device_init(>md);
+
+   ret = v4l2_device_register(dev, >v4l2_dev);
+   if (ret < 0) {
+   v4l2_err(>v4l2_dev,
+"Failed to register v4l2_device: %d\n", ret);
+   goto cleanup;
+   }
+
+   dev_set_drvdata(imxmd->v4l2_dev.dev, imxmd);
+
+   INIT_LIST_HEAD(>vdev_list);
+
+   return imxmd;
+
+cleanup:
+   media_device_cleanup(>md);
+
+   return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(imx_media_dev_init);
+
+int imx_media_dev_notifier_register(struct imx_media_dev *imxmd)
+{
+   int ret;
+
+   /* no subdevs? just bail */
+   if (imxmd->notifier.num_subdevs == 0) {
+   v4l2_err(>v4l2_dev, "no subdevs\n");
+   return -ENODEV;
+   }
+
+   /* prepare the async subdev notifier and register it */
+   imxmd->notifier.ops = _media_subdev_ops;
+   ret = v4l2_async_notifier_register(>v4l2_dev,
+  >notifier);
+   if (ret) {
+   v4l2_err(>v4l2_dev,
+"v4l2_async_notifier_register failed with %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(imx_media_dev_notifier_register);
+
+void imx_media_dev_cleanup(struct imx_media_dev *imxmd)
+{
+   v4l2_device_unregister(>v4l2_dev);
+   media_device_cleanup(>md);
+}
+EXPORT_SYMBOL_GPL(imx_media_dev_cleanup);
+
+void imx_media_dev_notifier_unregister(struct imx_media_dev *imxmd)
+{
+   v4l2_async_notifier_cleanup(>notifier);
+}
+EXPORT_SYMBOL_GPL(imx_media_dev_notifier_unregister);
diff --git a/drivers/staging/media/imx/imx-media-dev.c 
b/drivers/staging/media/imx/imx-media-dev.c
index 7e7bd1c6c81b..6160070b72fb 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -87,6 +87,9 @@ static int imx_media_get_ipu(struct imx_media_dev *imxmd,
struct ipu_soc *ipu;
int ipu_id;
 
+   if (!imxmd->ipu_present)
+   return 0;
+
ipu = dev_get_drvdata(csi_sd->dev->parent);
if (!ipu) {
v4l2_err(>v4l2_dev,
@@ -107,9 +110,9 @@ static int imx_media_get_ipu(struct imx_media_dev 

Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1

[Mauro Carvalho Chehab]

Em Thu, 17 May 2018 08:43:24 -0300
Mauro Carvalho Chehab  escreveu:

> > > > On 05/15/2018 02:39 PM, Dan Carpenter wrote:  
> >   
> > > >> You'd need to rebuild the db (possibly twice but definitely once).  
> > 
> > How? Here, I just pull from your git tree and do a "make". At most,
> > make clean; make.  
> 
> Never mind. Found it using grep. I'm running this:
> 
>   make allyesconfig
>   /devel/smatch/smatch_scripts/build_kernel_data.sh
>   /devel/smatch/smatch_scripts/build_kernel_data.sh

It seems that something is broken... getting this error/warning:

DBD::SQLite::db do failed: unrecognized token: "'end + strlen("
" at /devel/smatch/smatch_scripts/../smatch_data/db/fill_db_sql.pl line 32, 
 line 2938054.


Thanks,
Mauro

Re: [PATCH v3 1/2] media: rc: introduce BPF_PROG_RAWIR_EVENT

[Quentin Monnet]

2018-05-16 22:04 UTC+0100 ~ Sean Young 
> Add support for BPF_PROG_RAWIR_EVENT. This type of BPF program can call
> rc_keydown() to reported decoded IR scancodes, or rc_repeat() to report
> that the last key should be repeated.
> 
> The bpf program can be attached to using the bpf(BPF_PROG_ATTACH) syscall;
> the target_fd must be the /dev/lircN device.
> 
> Signed-off-by: Sean Young 
> ---
>  drivers/media/rc/Kconfig   |  13 ++
>  drivers/media/rc/Makefile  |   1 +
>  drivers/media/rc/bpf-rawir-event.c | 363 +
>  drivers/media/rc/lirc_dev.c|  24 ++
>  drivers/media/rc/rc-core-priv.h|  24 ++
>  drivers/media/rc/rc-ir-raw.c   |  14 +-
>  include/linux/bpf_rcdev.h  |  30 +++
>  include/linux/bpf_types.h  |   3 +
>  include/uapi/linux/bpf.h   |  55 -
>  kernel/bpf/syscall.c   |   7 +
>  10 files changed, 531 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/media/rc/bpf-rawir-event.c
>  create mode 100644 include/linux/bpf_rcdev.h
> 

[...]

Hi Sean,

Please find below some nitpicks on the documentation for the two helpers.

> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index d94d333a8225..243e141e8a5b 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h

[...]

> @@ -1902,6 +1904,35 @@ union bpf_attr {
>   *   egress otherwise). This is the only flag supported for now.
>   *   Return
>   *   **SK_PASS** on success, or **SK_DROP** on error.
> + *
> + * int bpf_rc_keydown(void *ctx, u32 protocol, u32 scancode, u32 toggle)
> + *   Description
> + *   Report decoded scancode with toggle value. For use in
> + *   BPF_PROG_TYPE_RAWIR_EVENT, to report a successfully

Could you please use bold RST markup for constants and function names?
Typically for BPF_PROG_TYPE_RAWIR_EVENT here and the enum below.

> + *   decoded scancode. This is will generate a keydown event,

s/This is will/This will/?

> + *   and a keyup event once the scancode is no longer repeated.
> + *
> + *   *ctx* pointer to bpf_rawir_event, *protocol* is decoded
> + *   protocol (see RC_PROTO_* enum).

This documentation is intended to be compiled as a man page. Could you
please use a complete sentence here?
Also, this could do with additional markup as well: **struct
bpf_rawir_event**.

> + *
> + *   Some protocols include a toggle bit, in case the button
> + *   was released and pressed again between consecutive scancodes,
> + *   copy this bit into *toggle* if it exists, else set to 0.
> + *
> + * Return

The "Return" lines here and in the second helper use space indent
instead as tabs (as all other lines do). Would you mind fixing it for
consistency?

> + *   Always return 0 (for now)

Other helpers use just "0" in that case, but I do not really mind.
Out of curiosity, do you have anything specific in mind for changing the
return value here in the future?

> + *
> + * int bpf_rc_repeat(void *ctx)
> + *   Description
> + *   Repeat the last decoded scancode; some IR protocols like
> + *   NEC have a special IR message for repeat last button,

s/repeat/repeating/?

> + *   in case user is holding a button down; the scancode is
> + *   not repeated.
> + *
> + *   *ctx* pointer to bpf_rawir_event.

Please use a complete sentence here as well, if you do not mind.

> + *
> + * Return
> + *   Always return 0 (for now)
>   */
Thanks,
Quentin

Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1

[Mauro Carvalho Chehab]

Em Thu, 17 May 2018 08:34:40 -0300
Mauro Carvalho Chehab  escreveu:

> Em Thu, 17 May 2018 05:36:03 -0500
> "Gustavo A. R. Silva"  escreveu:
> 
> > 
> > 
> > On 05/16/2018 08:14 PM, Gustavo A. R. Silva wrote:
> > > 
> > > 
> > > On 05/15/2018 02:39 PM, Dan Carpenter wrote:
> 
> > >> You'd need to rebuild the db (possibly twice but definitely once).
> 
> How? Here, I just pull from your git tree and do a "make". At most,
> make clean; make.

Never mind. Found it using grep. I'm running this:

make allyesconfig
/devel/smatch/smatch_scripts/build_kernel_data.sh
/devel/smatch/smatch_scripts/build_kernel_data.sh


> 
> > >>
> > > 
> > > Hi Dan,
> > > 
> > > After rebuilding the db (once), these are all the Spectre media warnings 
> > > I get:
> > > 
> > > drivers/media/pci/ddbridge/ddbridge-core.c:233 ddb_redirect() warn: 
> > > potential spectre issue 'ddbs'
> > > drivers/media/pci/ddbridge/ddbridge-core.c:243 ddb_redirect() warn: 
> > > potential spectre issue 'pdev->port'
> > > drivers/media/pci/ddbridge/ddbridge-core.c:252 ddb_redirect() warn: 
> > > potential spectre issue 'idev->input'
> > > drivers/media/dvb-core/dvb_ca_en50221.c:1400 
> > > dvb_ca_en50221_io_do_ioctl() warn: potential spectre issue 
> > > 'ca->slot_info' (local cap)
> > > drivers/media/dvb-core/dvb_ca_en50221.c:1479 dvb_ca_en50221_io_write() 
> > > warn: potential spectre issue 'ca->slot_info' (local cap)
> > > drivers/media/dvb-core/dvb_net.c:252 handle_one_ule_extension() warn: 
> > > potential spectre issue 'p->ule_next_hdr'
> > > drivers/media/dvb-core/dvb_net.c:1483 dvb_net_do_ioctl() warn: potential 
> > > spectre issue 'dvbnet->device' (local cap)
> > > drivers/media/cec/cec-pin-error-inj.c:170 cec_pin_error_inj_parse_line() 
> > > warn: potential spectre issue 'pin->error_inj_args'
> > > 
> > > I just want to double check if you are getting the same output. In case 
> > > you are getting the same, then what Mauro commented about these issues:
> > > 
> > > https://patchwork.linuxtv.org/project/linux-media/list/?submitter=7277
> > > 
> > > being resolved by commit 3ad3b7a2ebaefae37a7eafed0779324987ca5e56 seems 
> > > to be correct.
> > > 
> > 
> > Interesting, I've rebuild the db twice and now I get a total of 75 
> > Spectre warnings in drivers/media
> 
> That makes more sense to me, as the same pattern is used by almost all
> VIDIOC_ENUM_foo ioctls.
> 
> Thanks,
> Mauro



Thanks,
Mauro

Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1

[Mauro Carvalho Chehab]

Em Thu, 17 May 2018 05:36:03 -0500
"Gustavo A. R. Silva"  escreveu:

> 
> 
> On 05/16/2018 08:14 PM, Gustavo A. R. Silva wrote:
> > 
> > 
> > On 05/15/2018 02:39 PM, Dan Carpenter wrote:

> >> You'd need to rebuild the db (possibly twice but definitely once).

How? Here, I just pull from your git tree and do a "make". At most,
make clean; make.

> >>
> > 
> > Hi Dan,
> > 
> > After rebuilding the db (once), these are all the Spectre media warnings 
> > I get:
> > 
> > drivers/media/pci/ddbridge/ddbridge-core.c:233 ddb_redirect() warn: 
> > potential spectre issue 'ddbs'
> > drivers/media/pci/ddbridge/ddbridge-core.c:243 ddb_redirect() warn: 
> > potential spectre issue 'pdev->port'
> > drivers/media/pci/ddbridge/ddbridge-core.c:252 ddb_redirect() warn: 
> > potential spectre issue 'idev->input'
> > drivers/media/dvb-core/dvb_ca_en50221.c:1400 
> > dvb_ca_en50221_io_do_ioctl() warn: potential spectre issue 
> > 'ca->slot_info' (local cap)
> > drivers/media/dvb-core/dvb_ca_en50221.c:1479 dvb_ca_en50221_io_write() 
> > warn: potential spectre issue 'ca->slot_info' (local cap)
> > drivers/media/dvb-core/dvb_net.c:252 handle_one_ule_extension() warn: 
> > potential spectre issue 'p->ule_next_hdr'
> > drivers/media/dvb-core/dvb_net.c:1483 dvb_net_do_ioctl() warn: potential 
> > spectre issue 'dvbnet->device' (local cap)
> > drivers/media/cec/cec-pin-error-inj.c:170 cec_pin_error_inj_parse_line() 
> > warn: potential spectre issue 'pin->error_inj_args'
> > 
> > I just want to double check if you are getting the same output. In case 
> > you are getting the same, then what Mauro commented about these issues:
> > 
> > https://patchwork.linuxtv.org/project/linux-media/list/?submitter=7277
> > 
> > being resolved by commit 3ad3b7a2ebaefae37a7eafed0779324987ca5e56 seems 
> > to be correct.
> > 
> 
> Interesting, I've rebuild the db twice and now I get a total of 75 
> Spectre warnings in drivers/media

That makes more sense to me, as the same pattern is used by almost all
VIDIOC_ENUM_foo ioctls.

Thanks,
Mauro

[PATCH 4/4] media: venus: add PIL support

[Vikash Garodia]

This adds support to load the video firmware
and bring ARM9 out of reset. This is useful
for platforms which does not have trustzone
to reset the ARM9.

Signed-off-by: Vikash Garodia 
---
 .../devicetree/bindings/media/qcom,venus.txt   |   8 +-
 drivers/media/platform/qcom/venus/core.c   |  67 +++--
 drivers/media/platform/qcom/venus/core.h   |   6 +
 drivers/media/platform/qcom/venus/firmware.c   | 163 +
 drivers/media/platform/qcom/venus/firmware.h   |  10 +-
 5 files changed, 217 insertions(+), 37 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt 
b/Documentation/devicetree/bindings/media/qcom,venus.txt
index 00d0d1b..0ff0f2d 100644
--- a/Documentation/devicetree/bindings/media/qcom,venus.txt
+++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
@@ -53,7 +53,7 @@
 
 * Subnodes
 The Venus video-codec node must contain two subnodes representing
-video-decoder and video-encoder.
+video-decoder and video-encoder, one optional firmware subnode.
 
 Every of video-encoder or video-decoder subnode should have:
 
@@ -79,6 +79,8 @@ Every of video-encoder or video-decoder subnode should have:
power domain which is responsible for collapsing
and restoring power to the subcore.
 
+The firmware sub node must contain the iommus specifiers for ARM9.
+
 * An Example
video-codec@1d0 {
compatible = "qcom,msm8916-venus";
@@ -105,4 +107,8 @@ Every of video-encoder or video-decoder subnode should have:
clock-names = "core";
power-domains = < VENUS_CORE1_GDSC>;
};
+   firmware {
+   compatible = "qcom,venus-pil-no-tz";
+   iommus = <_smmu 0x10b2 0x0>;
+   }
};
diff --git a/drivers/media/platform/qcom/venus/core.c 
b/drivers/media/platform/qcom/venus/core.c
index 1308488..16910558 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -30,6 +31,7 @@
 #include "vdec.h"
 #include "venc.h"
 #include "firmware.h"
+#include "hfi_venus.h"
 
 static void venus_event_notify(struct venus_core *core, u32 event)
 {
@@ -76,7 +78,7 @@ static void venus_sys_error_handler(struct work_struct *work)
hfi_core_deinit(core, true);
hfi_destroy(core);
mutex_lock(>lock);
-   venus_shutdown(core->dev);
+   venus_shutdown(core);
 
pm_runtime_put_sync(core->dev);
 
@@ -84,7 +86,7 @@ static void venus_sys_error_handler(struct work_struct *work)
 
pm_runtime_get_sync(core->dev);
 
-   ret |= venus_boot(core->dev, core->res->fwname);
+   ret |= venus_boot(core);
 
ret |= hfi_core_resume(core, true);
 
@@ -179,6 +181,20 @@ static u32 to_v4l2_codec_type(u32 codec)
}
 }
 
+static int store_firmware_dev(struct device *dev, void *data)
+{
+   struct venus_core *core;
+
+   core = (struct venus_core *)data;
+   if (!core)
+   return -EINVAL;
+
+   if (of_device_is_compatible(dev->of_node, "qcom,venus-pil-no-tz"))
+   core->fw.dev = dev;
+
+   return 0;
+}
+
 static int venus_enumerate_codecs(struct venus_core *core, u32 type)
 {
const struct hfi_inst_ops dummy_ops = {};
@@ -229,6 +245,7 @@ static int venus_probe(struct platform_device *pdev)
struct device *dev = >dev;
struct venus_core *core;
struct resource *r;
+   struct iommu_domain *iommu_domain;
int ret;
 
core = devm_kzalloc(dev, sizeof(*core), GFP_KERNEL);
@@ -279,7 +296,14 @@ static int venus_probe(struct platform_device *pdev)
if (ret < 0)
goto err_runtime_disable;
 
-   ret = venus_boot(dev, core->res->fwname);
+   ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
+   if (ret)
+   goto err_runtime_disable;
+
+   /* Attempt to register child devices */
+   ret = device_for_each_child(dev, core, store_firmware_dev);
+
+   ret = venus_boot(core);
if (ret)
goto err_runtime_disable;
 
@@ -303,14 +327,17 @@ static int venus_probe(struct platform_device *pdev)
if (ret)
goto err_core_deinit;
 
-   ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
+   ret = pm_runtime_put_sync(dev);
if (ret)
goto err_dev_unregister;
 
-   ret = pm_runtime_put_sync(dev);
-   if (ret)
+   iommu_domain = iommu_get_domain_for_dev(dev);
+   if (!iommu_domain)
goto err_dev_unregister;
 
+   iommu_domain->geometry.aperture_start = VENUS_FW_MEM_SIZE;
+   iommu_domain->geometry.aperture_end = VENUS_MAX_MEM_REGION;
+
return 0;
 
 err_dev_unregister:
@@ -318,7 +345,7 @@ static int venus_probe(struct platform_device 

[PATCH 1/4] soc: qcom: mdt_loader: Add check to make scm calls

[Vikash Garodia]

In order to invoke scm calls, ensure that the platform
has the required support to invoke the scm calls in
secure world.

Signed-off-by: Vikash Garodia 
---
 drivers/soc/qcom/mdt_loader.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
index 17b314d..db55d53 100644
--- a/drivers/soc/qcom/mdt_loader.c
+++ b/drivers/soc/qcom/mdt_loader.c
@@ -121,10 +121,12 @@ int qcom_mdt_load(struct device *dev, const struct 
firmware *fw,
if (!fw_name)
return -ENOMEM;
 
-   ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size);
-   if (ret) {
-   dev_err(dev, "invalid firmware metadata\n");
-   goto out;
+   if (qcom_scm_is_available()) {
+   ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size);
+   if (ret) {
+   dev_err(dev, "invalid firmware metadata\n");
+   goto out;
+   }
}
 
for (i = 0; i < ehdr->e_phnum; i++) {
@@ -144,10 +146,13 @@ int qcom_mdt_load(struct device *dev, const struct 
firmware *fw,
}
 
if (relocate) {
-   ret = qcom_scm_pas_mem_setup(pas_id, mem_phys, max_addr - 
min_addr);
-   if (ret) {
-   dev_err(dev, "unable to setup relocation\n");
-   goto out;
+   if (qcom_scm_is_available()) {
+   ret = qcom_scm_pas_mem_setup(pas_id, mem_phys,
+   max_addr - min_addr);
+   if (ret) {
+   dev_err(dev, "unable to setup relocation\n");
+   goto out;
+   }
}
 
/*
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 2/4] media: venus: add a routine to reset ARM9

[Vikash Garodia]

Add a new routine to reset the ARM9 and brings it
out of reset. This is in preparation to add PIL
functionality in venus driver.

Signed-off-by: Vikash Garodia 
---
 drivers/media/platform/qcom/venus/firmware.c | 26 
 drivers/media/platform/qcom/venus/firmware.h |  1 +
 drivers/media/platform/qcom/venus/hfi_venus_io.h |  5 +
 3 files changed, 32 insertions(+)

diff --git a/drivers/media/platform/qcom/venus/firmware.c 
b/drivers/media/platform/qcom/venus/firmware.c
index c4a5778..8f25375 100644
--- a/drivers/media/platform/qcom/venus/firmware.c
+++ b/drivers/media/platform/qcom/venus/firmware.c
@@ -14,6 +14,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -22,11 +23,36 @@
 #include 
 #include 
 
+#include "core.h"
 #include "firmware.h"
+#include "hfi_venus_io.h"
 
 #define VENUS_PAS_ID   9
 #define VENUS_FW_MEM_SIZE  (6 * SZ_1M)
 
+void venus_reset_hw(struct venus_core *core)
+{
+   void __iomem *reg_base = core->base;
+
+   writel(0, reg_base + WRAPPER_FW_START_ADDR);
+   writel(VENUS_FW_MEM_SIZE, reg_base + WRAPPER_FW_END_ADDR);
+   writel(0, reg_base + WRAPPER_CPA_START_ADDR);
+   writel(VENUS_FW_MEM_SIZE, reg_base + WRAPPER_CPA_END_ADDR);
+   writel(0x0, reg_base + WRAPPER_CPU_CGC_DIS);
+   writel(0x0, reg_base + WRAPPER_CPU_CLOCK_CONFIG);
+
+   /* Make sure all register writes are committed. */
+   mb();
+
+   /*
+* Need to wait 10 cycles of internal clocks before bringing ARM9
+* out of reset.
+*/
+   udelay(1);
+
+   /* Bring Arm9 out of reset */
+   writel_relaxed(0, reg_base + WRAPPER_A9SS_SW_RESET);
+}
 int venus_boot(struct device *dev, const char *fwname)
 {
const struct firmware *mdt;
diff --git a/drivers/media/platform/qcom/venus/firmware.h 
b/drivers/media/platform/qcom/venus/firmware.h
index 428efb5..d56f5b2 100644
--- a/drivers/media/platform/qcom/venus/firmware.h
+++ b/drivers/media/platform/qcom/venus/firmware.h
@@ -18,5 +18,6 @@
 
 int venus_boot(struct device *dev, const char *fwname);
 int venus_shutdown(struct device *dev);
+void venus_reset_hw(struct venus_core *core);
 
 #endif
diff --git a/drivers/media/platform/qcom/venus/hfi_venus_io.h 
b/drivers/media/platform/qcom/venus/hfi_venus_io.h
index 76f4793..39afa5d 100644
--- a/drivers/media/platform/qcom/venus/hfi_venus_io.h
+++ b/drivers/media/platform/qcom/venus/hfi_venus_io.h
@@ -109,6 +109,11 @@
 #define WRAPPER_CPU_CGC_DIS(WRAPPER_BASE + 0x2010)
 #define WRAPPER_CPU_STATUS (WRAPPER_BASE + 0x2014)
 #define WRAPPER_SW_RESET   (WRAPPER_BASE + 0x3000)
+#define WRAPPER_CPA_START_ADDR (WRAPPER_BASE + 0x1020)
+#define WRAPPER_CPA_END_ADDR   (WRAPPER_BASE + 0x1024)
+#define WRAPPER_FW_START_ADDR  (WRAPPER_BASE + 0x1028)
+#define WRAPPER_FW_END_ADDR(WRAPPER_BASE + 0x102C)
+#define WRAPPER_A9SS_SW_RESET  (WRAPPER_BASE + 0x3000)
 
 /* Venus 4xx */
 #define WRAPPER_VCODEC0_MMCC_POWER_STATUS  (WRAPPER_BASE + 0x90)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 3/4] venus: add check to make scm calls

[Vikash Garodia]

In order to invoke scm calls, ensure that the platform
has the required support to invoke the scm calls in
secure world. This code is in preparation to add PIL
functionality in venus driver.

Signed-off-by: Vikash Garodia 
---
 drivers/media/platform/qcom/venus/hfi_venus.c | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c 
b/drivers/media/platform/qcom/venus/hfi_venus.c
index f61d34b..9bcce94 100644
--- a/drivers/media/platform/qcom/venus/hfi_venus.c
+++ b/drivers/media/platform/qcom/venus/hfi_venus.c
@@ -27,6 +27,7 @@
 #include "hfi_msgs.h"
 #include "hfi_venus.h"
 #include "hfi_venus_io.h"
+#include "firmware.h"
 
 #define HFI_MASK_QHDR_TX_TYPE  0xff00
 #define HFI_MASK_QHDR_RX_TYPE  0x00ff
@@ -570,13 +571,19 @@ static int venus_halt_axi(struct venus_hfi_device *hdev)
 static int venus_power_off(struct venus_hfi_device *hdev)
 {
int ret;
+   void __iomem *reg_base;
 
if (!hdev->power_enabled)
return 0;
 
-   ret = qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_SUSPEND, 0);
-   if (ret)
-   return ret;
+   if (qcom_scm_is_available()) {
+   ret = qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_SUSPEND, 0);
+   if (ret)
+   return ret;
+   } else {
+   reg_base = hdev->core->base;
+   writel_relaxed(1, reg_base + WRAPPER_A9SS_SW_RESET);
+   }
 
ret = venus_halt_axi(hdev);
if (ret)
@@ -594,9 +601,13 @@ static int venus_power_on(struct venus_hfi_device *hdev)
if (hdev->power_enabled)
return 0;
 
-   ret = qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_RESUME, 0);
-   if (ret)
-   goto err;
+   if (qcom_scm_is_available()) {
+   ret = qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_RESUME, 0);
+   if (ret)
+   goto err;
+   } else {
+   venus_reset_hw(hdev->core);
+   }
 
ret = venus_run(hdev);
if (ret)
@@ -607,7 +618,8 @@ static int venus_power_on(struct venus_hfi_device *hdev)
return 0;
 
 err_suspend:
-   qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_SUSPEND, 0);
+   if (qcom_scm_is_available())
+   qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_SUSPEND, 0);
 err:
hdev->power_enabled = false;
return ret;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 0/4] Venus updates - PIL

[Vikash Garodia]

Hello,

The patch set mainly adds PIL functionality in video driver. 
There are boards with qcom video hardware but does not have
trustzone. For such boards, the PIL added now will load the
video firmware and reset the ARM9.

The patch set is based on top of recent venus updates v2 patches
posted by Stanimir Varbanov.

Comments are welcome!

regards,
Vikash

Vikash Garodia (4):
  soc: qcom: mdt_loader: Add check to make scm calls
  media: venus: add a routine to reset ARM9
  venus: add check to make scm calls
  media: venus: add PIL support

 .../devicetree/bindings/media/qcom,venus.txt   |   8 +-
 drivers/media/platform/qcom/venus/core.c   |  67 +++-
 drivers/media/platform/qcom/venus/core.h   |   6 +
 drivers/media/platform/qcom/venus/firmware.c   | 189 ++---
 drivers/media/platform/qcom/venus/firmware.h   |  11 +-
 drivers/media/platform/qcom/venus/hfi_venus.c  |  26 ++-
 drivers/media/platform/qcom/venus/hfi_venus_io.h   |   5 +
 drivers/soc/qcom/mdt_loader.c  |  21 ++-
 8 files changed, 281 insertions(+), 52 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 00/12] media: ov5640: Misc cleanup and improvements

[Sakari Ailus]

On Thu, May 17, 2018 at 01:22:07PM +0200, Maxime Ripard wrote:
> Hi,
> 
> On Thu, May 17, 2018 at 11:24:04AM +0200, Daniel Mack wrote:
> > Hi,
> > 
> > On Thursday, May 17, 2018 10:53 AM, Maxime Ripard wrote:
> > > Here is a "small" series that mostly cleans up the ov5640 driver code,
> > > slowly getting rid of the big data array for more understandable code
> > > (hopefully).
> > > 
> > > The biggest addition would be the clock rate computation at runtime,
> > > instead of relying on those arrays to setup the clock tree
> > > properly. As a side effect, it fixes the framerate that was off by
> > > around 10% on the smaller resolutions, and we now support 60fps.
> > > 
> > > This also introduces a bunch of new features.
> > 
> > I'd like to give this a try. What tree should this patch set be applied on?
> > I had no luck with media_tree/for-4.18-6.
> 
> Maybe it wasn't the latest after all, sorry. It's based on Sakari's
> for-4.18-3 PR (67f76c65e94f).

I've pushed these here:



-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v3 00/12] media: ov5640: Misc cleanup and improvements

[Maxime Ripard]

Hi,

On Thu, May 17, 2018 at 11:24:04AM +0200, Daniel Mack wrote:
> Hi,
> 
> On Thursday, May 17, 2018 10:53 AM, Maxime Ripard wrote:
> > Here is a "small" series that mostly cleans up the ov5640 driver code,
> > slowly getting rid of the big data array for more understandable code
> > (hopefully).
> > 
> > The biggest addition would be the clock rate computation at runtime,
> > instead of relying on those arrays to setup the clock tree
> > properly. As a side effect, it fixes the framerate that was off by
> > around 10% on the smaller resolutions, and we now support 60fps.
> > 
> > This also introduces a bunch of new features.
> 
> I'd like to give this a try. What tree should this patch set be applied on?
> I had no luck with media_tree/for-4.18-6.

Maybe it wasn't the latest after all, sorry. It's based on Sakari's
for-4.18-3 PR (67f76c65e94f).

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH] v4l: Add support for STD ioctls on subdev nodes

[Niklas Söderlund]

Hi Hans,

Thanks for your feedback.

On 2018-05-17 10:04:35 +0200, Hans Verkuil wrote:
> On 17/05/18 04:00, Niklas Söderlund wrote:
> 
> Missing commit log.

I checked other commits doing the same thing, they had no commit log and 
that was enough reason for me to be lazy. Will fix in v2. And thanks for 
forcing me to improve :-)

> 
> > Signed-off-by: Niklas Söderlund 
> > ---
> >  Documentation/media/uapi/v4l/vidioc-g-std.rst| 14 ++
> >  Documentation/media/uapi/v4l/vidioc-querystd.rst | 11 +++
> 
> What about ENUMSTD?

I did check about the possibility to add support for ENUMSTD. When 
digging around I got the feeling ENUMSTD was a videodev specific ioctl.  
As you bring it up here I assume that is not the case, I will see if I 
can add it for v2.

> 
> Regards,
> 
>   Hans
> 
> >  drivers/media/v4l2-core/v4l2-subdev.c| 12 
> >  include/uapi/linux/v4l2-subdev.h |  3 +++
> >  4 files changed, 32 insertions(+), 8 deletions(-)
> > 
> > ---
> > 
> > Hi Hans,
> > 
> > I have tested this on Renesas Gen3 Salvator-XS M3-N using the AFE 
> > subdevice from the adv748x driver together with the R-Car VIN and CSI-2 
> > pipeline.  
> > 
> > I wrote a prototype patch for v4l2-ctl which adds three new options 
> > (--get-subdev-standard, --set-subdev-standard and 
> > --get-subdev-detected-standard) to ease testing which I plan to submit 
> > after some cleanup if this patch receives positive feedback.
> > 
> > If you or anyone else is interested in testing this patch the v4l2-utils 
> > prototype patches are available at
> > 
> > git://git.ragnatech.se/v4l-utils#subdev-std
> > 
> > Regards,
> > // Niklas
> > 
> > diff --git a/Documentation/media/uapi/v4l/vidioc-g-std.rst 
> > b/Documentation/media/uapi/v4l/vidioc-g-std.rst
> > index 90791ab51a5371b8..8d94f0404df270db 100644
> > --- a/Documentation/media/uapi/v4l/vidioc-g-std.rst
> > +++ b/Documentation/media/uapi/v4l/vidioc-g-std.rst
> > @@ -2,14 +2,14 @@
> >  
> >  .. _VIDIOC_G_STD:
> >  
> > -
> > -ioctl VIDIOC_G_STD, VIDIOC_S_STD
> > -
> > +**
> > +ioctl VIDIOC_G_STD, VIDIOC_S_STD, VIDIOC_SUBDEV_G_STD, VIDIOC_SUBDEV_S_STD
> > +**
> >  
> >  Name
> >  
> >  
> > -VIDIOC_G_STD - VIDIOC_S_STD - Query or select the video standard of the 
> > current input
> > +VIDIOC_G_STD - VIDIOC_S_STD - VIDIOC_SUBDEV_G_STD - VIDIOC_SUBDEV_S_STD - 
> > Query or select the video standard of the current input
> >  
> >  
> >  Synopsis
> > @@ -21,6 +21,12 @@ Synopsis
> >  .. c:function:: int ioctl( int fd, VIDIOC_S_STD, const v4l2_std_id *argp )
> >  :name: VIDIOC_S_STD
> >  
> > +.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_G_STD, v4l2_std_id *argp )
> > +:name: VIDIOC_SUBDEV_G_STD
> > +
> > +.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_S_STD, const v4l2_std_id 
> > *argp )
> > +:name: VIDIOC_SUBDEV_S_STD
> > +
> >  
> >  Arguments
> >  =
> > diff --git a/Documentation/media/uapi/v4l/vidioc-querystd.rst 
> > b/Documentation/media/uapi/v4l/vidioc-querystd.rst
> > index cf40bca19b9f8665..a8385cc7481869dd 100644
> > --- a/Documentation/media/uapi/v4l/vidioc-querystd.rst
> > +++ b/Documentation/media/uapi/v4l/vidioc-querystd.rst
> > @@ -2,14 +2,14 @@
> >  
> >  .. _VIDIOC_QUERYSTD:
> >  
> > -*
> > -ioctl VIDIOC_QUERYSTD
> > -*
> > +*
> > +ioctl VIDIOC_QUERYSTD, VIDIOC_SUBDEV_QUERYSTD
> > +*
> >  
> >  Name
> >  
> >  
> > -VIDIOC_QUERYSTD - Sense the video standard received by the current input
> > +VIDIOC_QUERYSTD - VIDIOC_SUBDEV_QUERYSTD - Sense the video standard 
> > received by the current input
> >  
> >  
> >  Synopsis
> > @@ -18,6 +18,9 @@ Synopsis
> >  .. c:function:: int ioctl( int fd, VIDIOC_QUERYSTD, v4l2_std_id *argp )
> >  :name: VIDIOC_QUERYSTD
> >  
> > +.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_QUERYSTD, v4l2_std_id 
> > *argp )
> > +:name: VIDIOC_SUBDEV_QUERYSTD
> > +
> >  
> >  Arguments
> >  =
> > diff --git a/drivers/media/v4l2-core/v4l2-subdev.c 
> > b/drivers/media/v4l2-core/v4l2-subdev.c
> > index f9eed938d3480b74..a156b1812e923721 100644
> > --- a/drivers/media/v4l2-core/v4l2-subdev.c
> > +++ b/drivers/media/v4l2-core/v4l2-subdev.c
> > @@ -494,6 +494,18 @@ static long subdev_do_ioctl(struct file *file, 
> > unsigned int cmd, void *arg)
> >  
> > case VIDIOC_SUBDEV_S_DV_TIMINGS:
> > return v4l2_subdev_call(sd, video, s_dv_timings, arg);
> > +
> > +   case VIDIOC_SUBDEV_G_STD:
> > +   return v4l2_subdev_call(sd, video, g_std, arg);
> > +
> > +   case VIDIOC_SUBDEV_S_STD: {
> > +   v4l2_std_id *std = arg;
> > +
> > +   return 

Re: [PATCH v2 1/4] media: rcar-vin: Parse digital input in mc-path

[Niklas Söderlund]

Hi Jacopo,

On 2018-05-17 12:13:06 +0200, Jacopo Mondi wrote:
> Hi Niklas,
>thanks for review.
> 
> On Wed, May 16, 2018 at 10:32:49PM +0200, Niklas Söderlund wrote:
> > Hi Jacopo,
> >
> > Thanks for your work!
> >
> > First let me apologies for the use of the keyword 'digital' in the
> > driver it should have been parallel... Someday we should remedy this.
> >
> > If you touch any parts of the code where such a transition make sens I
> > would not complain about the intermixed use of digital/parallel. Once
> > your work is done we could follow up with a cleanup patch to complete
> > the transition. Or if you rather stick with digital here I'm fine with
> > that too.
> 
> I would go with a major s/digital/parallel/ after this has been
> merged, if that' fine with you.

I'm totally fine whit that.

> >
> > On 2018-05-16 14:16:53 +0200, Jacopo Mondi wrote:
> > > Add support for digital input subdevices to Gen-3 rcar-vin.
> > > The Gen-3, media-controller compliant, version has so far only accepted
> > > CSI-2 input subdevices. Remove assumptions on the supported bus_type and
> > > accepted number of subdevices, and allow digital input connections on 
> > > port@0.
> > >
> > > Signed-off-by: Jacopo Mondi 
> > > ---
> > >  drivers/media/platform/rcar-vin/rcar-core.c | 99 
> > > +++--
> > >  drivers/media/platform/rcar-vin/rcar-vin.h  | 15 +
> > >  2 files changed, 93 insertions(+), 21 deletions(-)
> > >
> > > diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> > > b/drivers/media/platform/rcar-vin/rcar-core.c
> > > index d3072e1..0ea21ab 100644
> > > --- a/drivers/media/platform/rcar-vin/rcar-core.c
> > > +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> > > @@ -562,7 +562,7 @@ static int rvin_digital_graph_init(struct rvin_dev 
> > > *vin)
> > >   return ret;
> > >
> > >   if (!vin->digital)
> > > - return -ENODEV;
> > > + return -ENOTCONN;
> > >
> > >   vin_dbg(vin, "Found digital subdevice %pOF\n",
> > >   to_of_node(vin->digital->asd.match.fwnode));
> > > @@ -703,15 +703,13 @@ static int rvin_mc_parse_of_endpoint(struct device 
> > > *dev,
> > >  {
> > >   struct rvin_dev *vin = dev_get_drvdata(dev);
> > >
> > > - if (vep->base.port != 1 || vep->base.id >= RVIN_CSI_MAX)
> > > + if (vep->base.port != RVIN_PORT_CSI2 || vep->base.id >= RVIN_CSI_MAX)
> >
> > I don't like this RVIN_PORT_CSI2. It makes the code harder to read as I
> > have have to go and lookup which port RVIN_PORT_CSI2 represents. I would
> 
> Why do you have to go and look? It's an enum, it abstracts away the numerical
> value it represents with a human readable string. If you want to check
> which number it represent you can got and look at the enum definition,
> once. While reading the code, the most important part is "this is the CSI-2
> port" or "this is port 1"? You wrote the driver and for you there is
> no ambiguity there, I understand.
> 
> > rater just keep vep->base.port != 1 as I think it's much clearer whats
> > going on. And it's not as we will move the CSI-2 input to a different
> > port as it's described in the bindings.
> 
> That's one more reason to have an enum for that.
> 
> Anyway, that's pure bikeshedding, I like discussing these things
> too but I'm surely not making an argument for this. If you don't like
> the enum I'll remove that.

I'm sorry, I don't like the enum :-(

> 
> >
> > >   return -EINVAL;
> > >
> > >   if (!of_device_is_available(to_of_node(asd->match.fwnode))) {
> > > -
> > >   vin_dbg(vin, "OF device %pOF disabled, ignoring\n",
> > >   to_of_node(asd->match.fwnode));
> > >   return -ENOTCONN;
> > > -
> > >   }
> > >
> > >   if (vin->group->csi[vep->base.id].fwnode) {
> > > @@ -720,6 +718,8 @@ static int rvin_mc_parse_of_endpoint(struct device 
> > > *dev,
> > >   return -ENOTCONN;
> > >   }
> > >
> > > + vin->mbus_cfg.type = V4L2_MBUS_CSI2;
> > > + vin->mbus_cfg.flags = 0;
> >
> > I like this move of mbus_cfg handling! Makes the two cases more aligned
> > which are good. Unfortunately I fear it needs more work :-(
> >
> > With this series addition of parallel input support. There are now two
> > input types CSI-2 and parallel which can be changed at runtime for the
> > same VIN. The mbus connected to the VIN will therefor be different
> 
> Wait, are you suggesting the parallel input connection can be switched
> with CSI-2 ones at runtime? I undestand the CSI-2 - VIN routing as the
> physical connections are already in place in the SoC, but if we're
> connecting a parallel input to a VIN instance that accepts an input
> connection then that hardly can be switched to another port with a
> software configuration.

Sure it can. Check 'Figure 26.2.1 Functional Block Diagram of Video 
Input Modules 4 to 7 (VIN4 to VIN7) (R-Car H3, M3-W)'. Here VIN4 and 
VIN5 can have both a parallel input and a CSI-2 input.

In the block diagram the "CSI or Digial Pin" is the 

[PATCH 0/3] dw9807 and imx258 drivers

[Sakari Ailus]

Re-submitting with correct SoB lines. The removal of the unused retry
variable has been merged to the dw9807 driver patch.

Alan Chiang (2):
  media: dt-bindings: Add bindings for Dongwoon DW9807 voice coil
  media: dw9807: Add dw9807 vcm driver

Jason Chen (1):
  media: imx258: Add imx258 camera sensor driver

 .../bindings/media/i2c/dongwoon,dw9807.txt |9 +
 MAINTAINERS|   14 +
 drivers/media/i2c/Kconfig  |   21 +
 drivers/media/i2c/Makefile |2 +
 drivers/media/i2c/dw9807.c |  329 +
 drivers/media/i2c/imx258.c | 1320 
 6 files changed, 1695 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
 create mode 100644 drivers/media/i2c/dw9807.c
 create mode 100644 drivers/media/i2c/imx258.c

-- 
2.11.0

[PATCH 2/3] media: dw9807: Add dw9807 vcm driver

[Sakari Ailus]

From: Alan Chiang 

DW9807 is a 10 bit DAC from Dongwoon, 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: Alan Chiang 
Signed-off-by: Andy Yeh 
Reviewed-by: Jacopo Mondi 
Reviewed-by: Tomasz Figa 
Signed-off-by: Sakari Ailus 
---
 MAINTAINERS|   7 +
 drivers/media/i2c/Kconfig  |  10 ++
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/dw9807.c | 329 +
 4 files changed, 347 insertions(+)
 create mode 100644 drivers/media/i2c/dw9807.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 519f172c9267..6304b696c698 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4382,6 +4382,13 @@ T:   git git://linuxtv.org/media_tree.git
 S: Maintained
 F: drivers/media/i2c/dw9714.c
 
+DONGWOON DW9807 LENS VOICE COIL DRIVER
+M: Sakari Ailus 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/dw9807.c
+
 DOUBLETALK DRIVER
 M: "James R. Van Zandt" 
 L: blinux-l...@redhat.com
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index b95b44702ccb..e6a721c5e3b0 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -336,6 +336,16 @@ config VIDEO_DW9714
  capability. This is designed for linear control of
  voice coil motors, controlled via I2C serial interface.
 
+config VIDEO_DW9807
+   tristate "DW9807 lens voice coil support"
+   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+   depends on VIDEO_V4L2_SUBDEV_API
+   ---help---
+ This is a driver for the DW9807 camera lens voice coil.
+ DW9807 is a 10 bit DAC with 100mA 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 ff6e2914abda..5cf15edacb2b 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -24,6 +24,7 @@ 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_DW9807)  += dw9807.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/dw9807.c b/drivers/media/i2c/dw9807.c
new file mode 100644
index ..6ebb98717fb1
--- /dev/null
+++ b/drivers/media/i2c/dw9807.c
@@ -0,0 +1,329 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Intel Corporation
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DW9807_MAX_FOCUS_POS   1023
+/*
+ * This sets the minimum granularity for the focus positions.
+ * A value of 1 gives maximum accuracy for a desired focus position.
+ */
+#define DW9807_FOCUS_STEPS 1
+/*
+ * This acts as the minimum granularity of lens movement.
+ * Keep this value power of 2, so the control steps can be
+ * uniformly adjusted for gradual lens movement, with desired
+ * number of control steps.
+ */
+#define DW9807_CTRL_STEPS  16
+#define DW9807_CTRL_DELAY_US   1000
+
+#define DW9807_CTL_ADDR0x02
+/*
+ * DW9807 separates two registers to control the VCM position.
+ * One for MSB value, another is LSB value.
+ */
+#define DW9807_MSB_ADDR0x03
+#define DW9807_LSB_ADDR0x04
+#define DW9807_STATUS_ADDR 0x05
+#define DW9807_MODE_ADDR   0x06
+#define DW9807_RESONANCE_ADDR  0x07
+
+#define MAX_RETRY  10
+
+struct dw9807_device {
+   struct v4l2_ctrl_handler ctrls_vcm;
+   struct v4l2_subdev sd;
+   u16 current_val;
+};
+
+static inline struct dw9807_device *sd_to_dw9807_vcm(
+   struct v4l2_subdev *subdev)
+{
+   return container_of(subdev, struct dw9807_device, sd);
+}
+
+static int dw9807_i2c_check(struct i2c_client *client)
+{
+   const char status_addr = DW9807_STATUS_ADDR;
+   char status_result;
+   int ret;
+
+   ret = i2c_master_send(client, _addr, sizeof(status_addr));
+   if (ret < 0) {
+   dev_err(>dev, "I2C write STATUS address fail ret = 
%d\n",
+   ret);
+   return ret;
+   }
+
+   ret = i2c_master_recv(client, _result, sizeof(status_result));
+   if (ret < 0) {
+   dev_err(>dev, "I2C read STATUS value fail ret = %d\n",
+   ret);
+   return ret;
+   }
+
+   return status_result;
+}
+

[PATCH 1/3] media: dt-bindings: Add bindings for Dongwoon DW9807 voice coil

[Sakari Ailus]

From: Alan Chiang 

Dongwoon DW9807 is a voice coil lens driver.

Signed-off-by: Alan Chiang 
Signed-off-by: Andy Yeh 
Reviewed-by: Rob Herring 
Signed-off-by: Sakari Ailus 
---
 Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt | 9 +
 1 file changed, 9 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt 
b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
new file mode 100644
index ..0a1a860beaff
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
@@ -0,0 +1,9 @@
+Dongwoon Anatech DW9807 voice coil lens driver
+
+DW9807 is a 10-bit DAC with current sink capability. It is intended for
+controlling voice coil lenses.
+
+Mandatory properties:
+
+- compatible: "dongwoon,dw9807"
+- reg: I2C slave address
-- 
2.11.0

[PATCH 3/3] media: imx258: Add imx258 camera sensor driver

[Sakari Ailus]

From: Jason Chen 

Add a V4L2 sub-device driver for the Sony IMX258 image sensor.
This is a camera sensor using the I2C bus for control and the
CSI-2 bus for data.

Signed-off-by: Jason Chen 
Signed-off-by: Andy Yeh 
Signed-off-by: Alan Chiang 
Reviewed-by: Tomasz Figa 
Signed-off-by: Sakari Ailus 
---
 MAINTAINERS|7 +
 drivers/media/i2c/Kconfig  |   11 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/imx258.c | 1320 
 4 files changed, 1339 insertions(+)
 create mode 100644 drivers/media/i2c/imx258.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 6304b696c698..c82c30059679 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13076,6 +13076,13 @@ S: Maintained
 F: drivers/ssb/
 F: include/linux/ssb/
 
+SONY IMX258 SENSOR DRIVER
+M: Sakari Ailus 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/imx258.c
+
 SONY IMX274 SENSOR DRIVER
 M: Leon Luo 
 L: linux-media@vger.kernel.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index e6a721c5e3b0..1f9d7c6aa31a 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -585,6 +585,17 @@ config VIDEO_APTINA_PLL
 config VIDEO_SMIAPP_PLL
tristate
 
+config VIDEO_IMX258
+   tristate "Sony IMX258 sensor support"
+   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the Sony
+ IMX258 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called imx258.
+
 config VIDEO_IMX274
tristate "Sony IMX274 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 5cf15edacb2b..16fc34eda5cc 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -102,6 +102,7 @@ obj-$(CONFIG_VIDEO_I2C) += video-i2c.o
 obj-$(CONFIG_VIDEO_ML86V7667)  += ml86v7667.o
 obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
 obj-$(CONFIG_VIDEO_TC358743)   += tc358743.o
+obj-$(CONFIG_VIDEO_IMX258) += imx258.o
 obj-$(CONFIG_VIDEO_IMX274) += imx274.o
 
 obj-$(CONFIG_SDR_MAX2175) += max2175.o
diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
new file mode 100644
index ..fad3012f4fe5
--- /dev/null
+++ b/drivers/media/i2c/imx258.c
@@ -0,0 +1,1320 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Intel Corporation
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IMX258_REG_VALUE_08BIT 1
+#define IMX258_REG_VALUE_16BIT 2
+
+#define IMX258_REG_MODE_SELECT 0x0100
+#define IMX258_MODE_STANDBY0x00
+#define IMX258_MODE_STREAMING  0x01
+
+/* Chip ID */
+#define IMX258_REG_CHIP_ID 0x0016
+#define IMX258_CHIP_ID 0x0258
+
+/* V_TIMING internal */
+#define IMX258_VTS_30FPS   0x0c98
+#define IMX258_VTS_30FPS_2K0x0638
+#define IMX258_VTS_30FPS_VGA   0x034c
+#define IMX258_VTS_MAX 0x
+
+/*Frame Length Line*/
+#define IMX258_FLL_MIN 0x08a6
+#define IMX258_FLL_MAX 0x
+#define IMX258_FLL_STEP1
+#define IMX258_FLL_DEFAULT 0x0c98
+
+/* HBLANK control - read only */
+#define IMX258_PPL_DEFAULT 5352
+
+/* Exposure control */
+#define IMX258_REG_EXPOSURE0x0202
+#define IMX258_EXPOSURE_MIN4
+#define IMX258_EXPOSURE_STEP   1
+#define IMX258_EXPOSURE_DEFAULT0x640
+#define IMX258_EXPOSURE_MAX65535
+
+/* Analog gain control */
+#define IMX258_REG_ANALOG_GAIN 0x0204
+#define IMX258_ANA_GAIN_MIN0
+#define IMX258_ANA_GAIN_MAX0x1fff
+#define IMX258_ANA_GAIN_STEP   1
+#define IMX258_ANA_GAIN_DEFAULT0x0
+
+/* Digital gain control */
+#define IMX258_REG_GR_DIGITAL_GAIN 0x020e
+#define IMX258_REG_R_DIGITAL_GAIN  0x0210
+#define IMX258_REG_B_DIGITAL_GAIN  0x0212
+#define IMX258_REG_GB_DIGITAL_GAIN 0x0214
+#define IMX258_DGTL_GAIN_MIN   0
+#define IMX258_DGTL_GAIN_MAX   4096/* Max = 0xFFF */
+#define IMX258_DGTL_GAIN_DEFAULT   1024
+#define IMX258_DGTL_GAIN_STEP  1
+
+/* Test Pattern Control */
+#define IMX258_REG_TEST_PATTERN0x0600
+#define IMX258_TEST_PATTERN_DISABLE0
+#define IMX258_TEST_PATTERN_SOLID_COLOR1
+#define IMX258_TEST_PATTERN_COLOR_BARS 2
+#define IMX258_TEST_PATTERN_GREY_COLOR 3
+#define IMX258_TEST_PATTERN_PN94
+
+/* 

Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1

[Gustavo A. R. Silva]

On 05/16/2018 08:14 PM, Gustavo A. R. Silva wrote:



On 05/15/2018 02:39 PM, Dan Carpenter wrote:

Dan,

These are all the Spectre media issues I see smatch is reporting in
linux-next-20180515:

drivers/media/cec/cec-pin-error-inj.c:170 cec_pin_error_inj_parse_line()
warn: potential spectre issue 'pin->error_inj_args'
drivers/media/dvb-core/dvb_ca_en50221.c:1479 
dvb_ca_en50221_io_write() warn:

potential spectre issue 'ca->slot_info' (local cap)
drivers/media/dvb-core/dvb_net.c:252 handle_one_ule_extension() warn:
potential spectre issue 'p->ule_next_hdr'

I pulled the latest changes from the smatch repository and compiled it.

I'm running smatch v0.5.0-4459-g2f66d40 now. Is this the latest version?

I wonder if there is anything I might be missing.



You'd need to rebuild the db (possibly twice but definitely once).



Hi Dan,

After rebuilding the db (once), these are all the Spectre media warnings 
I get:


drivers/media/pci/ddbridge/ddbridge-core.c:233 ddb_redirect() warn: 
potential spectre issue 'ddbs'
drivers/media/pci/ddbridge/ddbridge-core.c:243 ddb_redirect() warn: 
potential spectre issue 'pdev->port'
drivers/media/pci/ddbridge/ddbridge-core.c:252 ddb_redirect() warn: 
potential spectre issue 'idev->input'
drivers/media/dvb-core/dvb_ca_en50221.c:1400 
dvb_ca_en50221_io_do_ioctl() warn: potential spectre issue 
'ca->slot_info' (local cap)
drivers/media/dvb-core/dvb_ca_en50221.c:1479 dvb_ca_en50221_io_write() 
warn: potential spectre issue 'ca->slot_info' (local cap)
drivers/media/dvb-core/dvb_net.c:252 handle_one_ule_extension() warn: 
potential spectre issue 'p->ule_next_hdr'
drivers/media/dvb-core/dvb_net.c:1483 dvb_net_do_ioctl() warn: potential 
spectre issue 'dvbnet->device' (local cap)
drivers/media/cec/cec-pin-error-inj.c:170 cec_pin_error_inj_parse_line() 
warn: potential spectre issue 'pin->error_inj_args'


I just want to double check if you are getting the same output. In case 
you are getting the same, then what Mauro commented about these issues:


https://patchwork.linuxtv.org/project/linux-media/list/?submitter=7277

being resolved by commit 3ad3b7a2ebaefae37a7eafed0779324987ca5e56 seems 
to be correct.




Interesting, I've rebuild the db twice and now I get a total of 75 
Spectre warnings in drivers/media


--
Gustavo

Re: [PATCH v2 1/4] media: rcar-vin: Parse digital input in mc-path

[jacopo mondi]

Hi Niklas,
   thanks for review.

On Wed, May 16, 2018 at 10:32:49PM +0200, Niklas Söderlund wrote:
> Hi Jacopo,
>
> Thanks for your work!
>
> First let me apologies for the use of the keyword 'digital' in the
> driver it should have been parallel... Someday we should remedy this.
>
> If you touch any parts of the code where such a transition make sens I
> would not complain about the intermixed use of digital/parallel. Once
> your work is done we could follow up with a cleanup patch to complete
> the transition. Or if you rather stick with digital here I'm fine with
> that too.

I would go with a major s/digital/parallel/ after this has been
merged, if that' fine with you.
>
> On 2018-05-16 14:16:53 +0200, Jacopo Mondi wrote:
> > Add support for digital input subdevices to Gen-3 rcar-vin.
> > The Gen-3, media-controller compliant, version has so far only accepted
> > CSI-2 input subdevices. Remove assumptions on the supported bus_type and
> > accepted number of subdevices, and allow digital input connections on 
> > port@0.
> >
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  drivers/media/platform/rcar-vin/rcar-core.c | 99 
> > +++--
> >  drivers/media/platform/rcar-vin/rcar-vin.h  | 15 +
> >  2 files changed, 93 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> > b/drivers/media/platform/rcar-vin/rcar-core.c
> > index d3072e1..0ea21ab 100644
> > --- a/drivers/media/platform/rcar-vin/rcar-core.c
> > +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> > @@ -562,7 +562,7 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
> > return ret;
> >
> > if (!vin->digital)
> > -   return -ENODEV;
> > +   return -ENOTCONN;
> >
> > vin_dbg(vin, "Found digital subdevice %pOF\n",
> > to_of_node(vin->digital->asd.match.fwnode));
> > @@ -703,15 +703,13 @@ static int rvin_mc_parse_of_endpoint(struct device 
> > *dev,
> >  {
> > struct rvin_dev *vin = dev_get_drvdata(dev);
> >
> > -   if (vep->base.port != 1 || vep->base.id >= RVIN_CSI_MAX)
> > +   if (vep->base.port != RVIN_PORT_CSI2 || vep->base.id >= RVIN_CSI_MAX)
>
> I don't like this RVIN_PORT_CSI2. It makes the code harder to read as I
> have have to go and lookup which port RVIN_PORT_CSI2 represents. I would

Why do you have to go and look? It's an enum, it abstracts away the numerical
value it represents with a human readable string. If you want to check
which number it represent you can got and look at the enum definition,
once. While reading the code, the most important part is "this is the CSI-2
port" or "this is port 1"? You wrote the driver and for you there is
no ambiguity there, I understand.

> rater just keep vep->base.port != 1 as I think it's much clearer whats
> going on. And it's not as we will move the CSI-2 input to a different
> port as it's described in the bindings.

That's one more reason to have an enum for that.

Anyway, that's pure bikeshedding, I like discussing these things
too but I'm surely not making an argument for this. If you don't like
the enum I'll remove that.

>
> > return -EINVAL;
> >
> > if (!of_device_is_available(to_of_node(asd->match.fwnode))) {
> > -
> > vin_dbg(vin, "OF device %pOF disabled, ignoring\n",
> > to_of_node(asd->match.fwnode));
> > return -ENOTCONN;
> > -
> > }
> >
> > if (vin->group->csi[vep->base.id].fwnode) {
> > @@ -720,6 +718,8 @@ static int rvin_mc_parse_of_endpoint(struct device *dev,
> > return -ENOTCONN;
> > }
> >
> > +   vin->mbus_cfg.type = V4L2_MBUS_CSI2;
> > +   vin->mbus_cfg.flags = 0;
>
> I like this move of mbus_cfg handling! Makes the two cases more aligned
> which are good. Unfortunately I fear it needs more work :-(
>
> With this series addition of parallel input support. There are now two
> input types CSI-2 and parallel which can be changed at runtime for the
> same VIN. The mbus connected to the VIN will therefor be different

Wait, are you suggesting the parallel input connection can be switched
with CSI-2 ones at runtime? I undestand the CSI-2 - VIN routing as the
physical connections are already in place in the SoC, but if we're
connecting a parallel input to a VIN instance that accepts an input
connection then that hardly can be switched to another port with a
software configuration.

My understanding was even different: when a port has a digital video
input connected, a CSI-2 input cannot be routed there, because, well,
there is already a non modifiable connection, possibly part of the PCB
design.

> depending on which media graph link is connected to a particular VIN and
> this effects hardware configuration, see 'vin->mbus_cfg.type ==
> V4L2_MBUS_CSI2' in rvin_setup().
>
> Maybe the best solution is to move mbus_cfg into struct
> rvin_graph_entity, rename that struct rvin_parallel_input and cache the
> parallel input settings in there, much 

[ragnatech:media-tree 13/389] drivers/video/fbdev//omap2/omapfb/dss/dispc.c:1859:2: warning: this 'else' clause does not guard...

[kbuild test robot]

tree:   git://git.ragnatech.se/linux media-tree
head:   7e6b6b945272c20f6b78d319e07f27897a8373c9
commit: 7378f1149884b183631c6c16c0f1c62bcd7d759d [13/389] media: omap2: omapfb: 
allow building it with COMPILE_TEST
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 7378f1149884b183631c6c16c0f1c62bcd7d759d
# save the attached .config to linux build tree
make.cross ARCH=mips 

All warnings (new ones prefixed by >>):

   drivers/video/fbdev//omap2/omapfb/dss/dispc.c: In function 'pixinc':
>> drivers/video/fbdev//omap2/omapfb/dss/dispc.c:1859:2: warning: this 'else' 
>> clause does not guard... [-Wmisleading-indentation]
 else
 ^~~~
   drivers/video/fbdev//omap2/omapfb/dss/dispc.c:1861:3: note: ...this 
statement, but the latter is misleadingly indented as if it were guarded by the 
'else'
  return 0;
  ^~

vim +/else +1859 drivers/video/fbdev//omap2/omapfb/dss/dispc.c

f76ee892 Tomi Valkeinen 2015-12-09  1850  
f76ee892 Tomi Valkeinen 2015-12-09  1851  static s32 pixinc(int pixels, u8 ps)
f76ee892 Tomi Valkeinen 2015-12-09  1852  {
f76ee892 Tomi Valkeinen 2015-12-09  1853if (pixels == 1)
f76ee892 Tomi Valkeinen 2015-12-09  1854return 1;
f76ee892 Tomi Valkeinen 2015-12-09  1855else if (pixels > 1)
f76ee892 Tomi Valkeinen 2015-12-09  1856return 1 + (pixels - 1) 
* ps;
f76ee892 Tomi Valkeinen 2015-12-09  1857else if (pixels < 0)
f76ee892 Tomi Valkeinen 2015-12-09  1858return 1 - (-pixels + 
1) * ps;
f76ee892 Tomi Valkeinen 2015-12-09 @1859else
f76ee892 Tomi Valkeinen 2015-12-09  1860BUG();
f76ee892 Tomi Valkeinen 2015-12-09  1861return 0;
f76ee892 Tomi Valkeinen 2015-12-09  1862  }
f76ee892 Tomi Valkeinen 2015-12-09  1863  

:: The code at line 1859 was first introduced by commit
:: f76ee892a99e68b55402b8d4b8aeffcae2aff34d omapfb: copy omapdss & displays 
for omapfb

:: TO: Tomi Valkeinen 
:: CC: Tomi Valkeinen 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v9 7/8] media: vsp1: Adapt entities to configure into a body

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Thursday, 3 May 2018 16:35:46 EEST Kieran Bingham wrote:
> Currently the entities store their configurations into a display list.
> Adapt this such that the code can be configured into a body directly,
> allowing greater flexibility and control of the content.
> 
> All users of vsp1_dl_list_write() are removed in this process, thus it
> too is removed.
> 
> A helper, vsp1_dl_list_get_body0() is provided to access the internal body0
> from the display list.
> 
> Signed-off-by: Kieran Bingham 
> Reviewed-by: Laurent Pinchart 
> ---
> v9:
>  - Pass the DL through configure_partition() calls
> 
> v8:
>  - Fixed comment style and indentation
>  - Supported UIF
>  - Supported new configure_partition() functionality
> 
> v7:
>  - Rebase
>  - s/prepare/configure_stream/
>  - s/configure/configure_frame/
> ---
>  drivers/media/platform/vsp1/vsp1_brx.c| 22 ++--
>  drivers/media/platform/vsp1/vsp1_clu.c| 23 ++---
>  drivers/media/platform/vsp1/vsp1_dl.c | 12 ++-
>  drivers/media/platform/vsp1/vsp1_dl.h |  2 +-
>  drivers/media/platform/vsp1/vsp1_drm.c| 12 ---
>  drivers/media/platform/vsp1/vsp1_entity.c | 22 ++--
>  drivers/media/platform/vsp1/vsp1_entity.h | 18 ++
>  drivers/media/platform/vsp1/vsp1_hgo.c| 16 -
>  drivers/media/platform/vsp1/vsp1_hgt.c| 18 +-
>  drivers/media/platform/vsp1/vsp1_hsit.c   | 10 ++---
>  drivers/media/platform/vsp1/vsp1_lif.c| 15 
>  drivers/media/platform/vsp1/vsp1_lut.c| 23 ++---
>  drivers/media/platform/vsp1/vsp1_pipe.c   |  4 +-
>  drivers/media/platform/vsp1/vsp1_pipe.h   |  3 +-
>  drivers/media/platform/vsp1/vsp1_rpf.c| 44 
>  drivers/media/platform/vsp1/vsp1_sru.c| 14 
>  drivers/media/platform/vsp1/vsp1_uds.c| 25 +++---
>  drivers/media/platform/vsp1/vsp1_uds.h|  2 +-
>  drivers/media/platform/vsp1/vsp1_uif.c| 21 +--
>  drivers/media/platform/vsp1/vsp1_video.c  | 16 ++---
>  drivers/media/platform/vsp1/vsp1_wpf.c| 42 ---
>  21 files changed, 194 insertions(+), 170 deletions(-)

[snip]

> diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c
> b/drivers/media/platform/vsp1/vsp1_rpf.c index deb86cc235ef..8fae7c485642
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_rpf.c
> +++ b/drivers/media/platform/vsp1/vsp1_rpf.c

[snip]

> @@ -192,7 +195,6 @@ static void rpf_configure_partition(struct vsp1_entity
> *entity, const struct vsp1_format_info *fmtinfo = rpf->fmtinfo;
>   const struct v4l2_pix_format_mplane *format = >format;
>   struct v4l2_rect crop;
> -

No need to remove this blank line.

Apart from that,

Reviewed-by: Laurent Pinchart 

There's no need to resubmit, I'll fix when applying.

>   /*
>* Source size and crop offsets.
>*

[snip]

-- 
Regards,

Laurent Pinchart

[PATCH] media: v4l2-ctrl: Add control for VP9 profile

[Keiichi Watanabe]

Add a new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE for selecting desired
profile for VP9 encoder and querying for supported profiles by VP9 encoder
or decoder.

An existing control V4L2_CID_MPEG_VIDEO_VPX_PROFILE cannot be
used for querying since it is not a menu control but an integer
control, which cannot return an arbitrary set of supported profiles.

The new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE is a menu control as
with controls for other codec profiles. (e.g. H264)

Signed-off-by: Keiichi Watanabe 
---

 .../media/uapi/v4l/extended-controls.rst  | 26 +++
 drivers/media/v4l2-core/v4l2-ctrls.c  | 12 +
 include/uapi/linux/v4l2-controls.h|  8 ++
 3 files changed, 46 insertions(+)

diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
b/Documentation/media/uapi/v4l/extended-controls.rst
index 03931f9b1285..4f7f128a4998 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -1959,6 +1959,32 @@ enum v4l2_vp8_golden_frame_sel -
 Select the desired profile for VPx encoder. Acceptable values are 0,
 1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.
 
+.. _v4l2-mpeg-video-vp9-profile:
+
+``V4L2_CID_MPEG_VIDEO_VP9_PROFILE``
+(enum)
+
+enum v4l2_mpeg_video_vp9_profile -
+This control allows to select the profile for VP9 encoder.
+This is also used to enumerate supported profiles by VP9 encoder or 
decoder.
+Possible values are:
+
+
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+
+* - ``V4L2_MPEG_VIDEO_VP9_PROFILE_0``
+  - Profile 0
+* - ``V4L2_MPEG_VIDEO_VP9_PROFILE_1``
+  - Profile 1
+* - ``V4L2_MPEG_VIDEO_VP9_PROFILE_2``
+  - Profile 2
+* - ``V4L2_MPEG_VIDEO_VP9_PROFILE_3``
+  - Profile 3
+
+
 
 High Efficiency Video Coding (HEVC/H.265) Control Reference
 ---
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index d29e45516eb7..401ce21c2e63 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -431,6 +431,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Use Previous Specific Frame",
NULL,
};
+   static const char * const vp9_profile[] = {
+   "0",
+   "1",
+   "2",
+   "3",
+   NULL,
+   };
 
static const char * const flash_led_mode[] = {
"Off",
@@ -614,6 +621,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return mpeg4_profile;
case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
return vpx_golden_frame_sel;
+   case V4L2_CID_MPEG_VIDEO_VP9_PROFILE:
+   return vp9_profile;
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
return jpeg_chroma_subsampling;
case V4L2_CID_DV_TX_MODE:
@@ -841,6 +850,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:return "VPX 
P-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:   return "VPX 
Profile";
 
+   case V4L2_CID_MPEG_VIDEO_VP9_PROFILE:   return "VP9 
Profile";
+
/* HEVC controls */
case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP:   return "HEVC 
I-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP:   return "HEVC 
P-Frame QP Value";
@@ -1180,6 +1191,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_DEINTERLACING_MODE:
case V4L2_CID_TUNE_DEEMPHASIS:
case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
+   case V4L2_CID_MPEG_VIDEO_VP9_PROFILE:
case V4L2_CID_DETECT_MD_MODE:
case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
diff --git a/include/uapi/linux/v4l2-controls.h 
b/include/uapi/linux/v4l2-controls.h
index 8d473c979b61..56203b7b715c 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -589,6 +589,14 @@ enum v4l2_vp8_golden_frame_sel {
 #define V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP (V4L2_CID_MPEG_BASE+510)
 #define V4L2_CID_MPEG_VIDEO_VPX_PROFILE
(V4L2_CID_MPEG_BASE+511)
 
+#define V4L2_CID_MPEG_VIDEO_VP9_PROFILE
(V4L2_CID_MPEG_BASE+512)
+enum v4l2_mpeg_video_vp9_profile {
+   V4L2_MPEG_VIDEO_VP9_PROFILE_0   = 0,
+   V4L2_MPEG_VIDEO_VP9_PROFILE_1   = 1,
+   V4L2_MPEG_VIDEO_VP9_PROFILE_2   = 2,
+   V4L2_MPEG_VIDEO_VP9_PROFILE_3   = 3,
+};
+
 /* CIDs for HEVC encoding. */
 
 #define V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP(V4L2_CID_MPEG_BASE + 
600)
-- 
2.17.0.441.gb46fe60e1d-goog

Re: [PATCH v9 6/8] media: vsp1: Refactor display list configure operations

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Thursday, 3 May 2018 16:35:45 EEST Kieran Bingham wrote:
> The entities provide a single .configure operation which configures the
> object into the target display list, based on the vsp1_entity_params
> selection.
> 
> Split the configure function into three parts, '.configure_stream()',
> '.configure_frame()', and '.configure_partition()' to facilitate
> splitting the configuration of each parameter class into separate
> display list bodies.
> 
> Signed-off-by: Kieran Bingham 
> 
> ---
> The checkpatch warning:
> 
> WARNING: function definition argument 'struct vsp1_dl_list *' should
> also have an identifier name
> 
> has been ignored to match the existing code style.
> 
> v8:
>  - Add support for the UIF
>  - Remove unrelated whitespace change
>  - Fix comment location for clu_configure_stream()
>  - Update configure documentations
>  - Implement configure_partition separation.
> 
> v7
>  - Fix formatting and white space
>  - s/prepare/configure_stream/
>  - s/configure/configure_frame/
> ---
>  drivers/media/platform/vsp1/vsp1_brx.c|  12 +-
>  drivers/media/platform/vsp1/vsp1_clu.c|  77 ++
>  drivers/media/platform/vsp1/vsp1_drm.c|  12 +-
>  drivers/media/platform/vsp1/vsp1_entity.c |  24 ++-
>  drivers/media/platform/vsp1/vsp1_entity.h |  39 +--
>  drivers/media/platform/vsp1/vsp1_hgo.c|  12 +-
>  drivers/media/platform/vsp1/vsp1_hgt.c|  12 +-
>  drivers/media/platform/vsp1/vsp1_hsit.c   |  12 +-
>  drivers/media/platform/vsp1/vsp1_lif.c|  12 +-
>  drivers/media/platform/vsp1/vsp1_lut.c|  47 +---
>  drivers/media/platform/vsp1/vsp1_rpf.c| 168 ++---
>  drivers/media/platform/vsp1/vsp1_sru.c|  12 +-
>  drivers/media/platform/vsp1/vsp1_uds.c|  56 ++--
>  drivers/media/platform/vsp1/vsp1_uif.c|  16 +-
>  drivers/media/platform/vsp1/vsp1_video.c  |  28 +--
>  drivers/media/platform/vsp1/vsp1_wpf.c| 303 ---
>  16 files changed, 422 insertions(+), 420 deletions(-)

[snip]

> diff --git a/drivers/media/platform/vsp1/vsp1_clu.c
> b/drivers/media/platform/vsp1/vsp1_clu.c index ea83f1b7d125..0a978980d447
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_clu.c
> +++ b/drivers/media/platform/vsp1/vsp1_clu.c
> @@ -168,58 +168,50 @@ static const struct v4l2_subdev_ops clu_ops = {
>  /* 
>   * VSP1 Entity Operations
>   */
> +static void clu_configure_stream(struct vsp1_entity *entity,
> +  struct vsp1_pipeline *pipe,
> +  struct vsp1_dl_list *dl)
> +{
> + struct vsp1_clu *clu = to_clu(>subdev);
> + struct v4l2_mbus_framefmt *format;
> 

I would have kept this blank line before the function.

> -static void clu_configure(struct vsp1_entity *entity,
> -   struct vsp1_pipeline *pipe,
> -   struct vsp1_dl_list *dl,
> -   enum vsp1_entity_params params)
> + /*
> +  * The yuv_mode can't be changed during streaming. Cache it internally
> +  * for future runtime configuration calls.
> +  */
> + format = vsp1_entity_get_pad_format(>entity,
> + clu->entity.config,
> + CLU_PAD_SINK);
> + clu->yuv_mode = format->code == MEDIA_BUS_FMT_AYUV8_1X32;
> +}

[snip]

> diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c
> b/drivers/media/platform/vsp1/vsp1_wpf.c index 65ed2f849551..da287c27b324
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_wpf.c
> +++ b/drivers/media/platform/vsp1/vsp1_wpf.c

[snip]

> +static void wpf_configure_frame(struct vsp1_entity *entity,
> + struct vsp1_pipeline *pipe,
> + struct vsp1_dl_list *dl)
> +{
> + struct vsp1_rwpf *wpf = to_rwpf(>subdev);
> + unsigned long flags;
> + u32 outfmt = 0;

No need to initialize outfmt to 0.

> +

This blank line isn't needed.

> + const unsigned int mask = BIT(WPF_CTRL_VFLIP)
> + | BIT(WPF_CTRL_HFLIP);
> +
> + spin_lock_irqsave(>flip.lock, flags);
> + wpf->flip.active = (wpf->flip.active & ~mask)
> +  | (wpf->flip.pending & mask);
> + spin_unlock_irqrestore(>flip.lock, flags);
> +
> + outfmt = (wpf->alpha << VI6_WPF_OUTFMT_PDV_SHIFT) | wpf->outfmt;
> +
> + if (wpf->flip.active & BIT(WPF_CTRL_VFLIP))
> + outfmt |= VI6_WPF_OUTFMT_FLP;
> + if (wpf->flip.active & BIT(WPF_CTRL_HFLIP))
> + outfmt |= VI6_WPF_OUTFMT_HFLP;
> +
> + vsp1_wpf_write(wpf, dl, VI6_WPF_OUTFMT, outfmt);
> +}

[snip]

Apart from that,

Reviewed-by: Laurent Pinchart 

If you agree with those small changes there's no need to resubmit, I'll fix 
when applying.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v3 00/12] media: ov5640: Misc cleanup and improvements

[Daniel Mack]

Hi,

On Thursday, May 17, 2018 10:53 AM, Maxime Ripard wrote:

Here is a "small" series that mostly cleans up the ov5640 driver code,
slowly getting rid of the big data array for more understandable code
(hopefully).

The biggest addition would be the clock rate computation at runtime,
instead of relying on those arrays to setup the clock tree
properly. As a side effect, it fixes the framerate that was off by
around 10% on the smaller resolutions, and we now support 60fps.

This also introduces a bunch of new features.


I'd like to give this a try. What tree should this patch set be applied 
on? I had no luck with media_tree/for-4.18-6.


Thanks,
Daniel




Let me know what you think,
Maxime

Changes from v2:
   - Rebased on latest Sakari PR
   - Fixed the issues reported by Hugues: improper FPS returned for
 formats, improper rounding of the FPS, some with his suggestions,
 some by simplifying the logic.
   - Expanded the clock tree comments based on the feedback from Samuel
 Bobrowicz and Loic Poulain
   - Merged some of the changes made by Samuel Bobrowicz to fix the
 MIPI rate computation, fix the call sites of the
 ov5640_set_timings function, the auto-exposure calculation call,
 etc.
   - Split the patches into smaller ones in order to make it more
 readable (hopefully)

Changes from v1:
   - Integrated Hugues' suggestions to fix v4l2-compliance
   - Fixed the bus width with JPEG
   - Dropped the clock rate calculation loops for something simpler as
 suggested by Sakari
   - Cache the exposure value instead of using the control value
   - Rebased on top of 4.17

Maxime Ripard (11):
   media: ov5640: Adjust the clock based on the expected rate
   media: ov5640: Remove the clocks registers initialization
   media: ov5640: Remove redundant defines
   media: ov5640: Remove redundant register setup
   media: ov5640: Compute the clock rate at runtime
   media: ov5640: Remove pixel clock rates
   media: ov5640: Enhance FPS handling
   media: ov5640: Make the return rate type more explicit
   media: ov5640: Make the FPS clamping / rounding more extendable
   media: ov5640: Add 60 fps support
   media: ov5640: Remove duplicate auto-exposure setup

Samuel Bobrowicz (1):
   media: ov5640: Fix timings setup code

  drivers/media/i2c/ov5640.c | 701 +
  1 file changed, 392 insertions(+), 309 deletions(-)

Re: [PATCH 5/6] ARM: dts: rcar-gen2: Remove unused VIN properties

[jacopo mondi]

Hi Niklas,

On Thu, May 17, 2018 at 12:13:07AM +0200, Niklas Söderlund wrote:
> Hi Jacopo,
>
> Thanks for your work.
>
> On 2018-05-16 18:32:31 +0200, Jacopo Mondi wrote:
> > The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN
> > driver and only confuse users. Remove them in all Gen2 SoC that used
> > them.
> >
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  arch/arm/boot/dts/r8a7790-lager.dts   | 3 ---
> >  arch/arm/boot/dts/r8a7791-koelsch.dts | 3 ---
> >  arch/arm/boot/dts/r8a7791-porter.dts  | 1 -
> >  arch/arm/boot/dts/r8a7793-gose.dts| 3 ---
> >  arch/arm/boot/dts/r8a7794-alt.dts | 1 -
> >  arch/arm/boot/dts/r8a7794-silk.dts| 1 -
> >  6 files changed, 12 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
> > b/arch/arm/boot/dts/r8a7790-lager.dts
> > index 063fdb6..b56b309 100644
> > --- a/arch/arm/boot/dts/r8a7790-lager.dts
> > +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> > @@ -873,10 +873,8 @@
> > port {
> > vin0ep2: endpoint {
> > remote-endpoint = <_out>;
> > -   bus-width = <24>;
>
> I can't really make up my mind if this is a good thing or not. Device
> tree describes the hardware and not what the drivers make use of. And
> the fact is that this bus is 24 bits wide. So I'm not sure we should
> remove these properties. But I would love to hear what others think
> about this.
>

Just to point out those properties are not even documented in rcar-vin
bindings (actually, none of them was).

I feel it's wrong to have them here, as someone may think that
changing their value should actually change the VIN interface behavior,
which it's not true, leading to massive confusion and quite some code
digging for no reason (and they will get mad at us at some point, probably :)

Thanks
   j

> > hsync-active = <0>;
> > vsync-active = <0>;
> > -   pclk-sample = <1>;
> > data-active = <1>;
> > };
> > };
> > @@ -895,7 +893,6 @@
> >
> > vin1ep0: endpoint {
> > remote-endpoint = <>;
> > -   bus-width = <8>;
> > };
> > };
> >  };
> > diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
> > b/arch/arm/boot/dts/r8a7791-koelsch.dts
> > index f40321a..9967666 100644
> > --- a/arch/arm/boot/dts/r8a7791-koelsch.dts
> > +++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
> > @@ -849,10 +849,8 @@
> >
> > vin0ep2: endpoint {
> > remote-endpoint = <_out>;
> > -   bus-width = <24>;
> > hsync-active = <0>;
> > vsync-active = <0>;
> > -   pclk-sample = <1>;
> > data-active = <1>;
> > };
> > };
> > @@ -870,7 +868,6 @@
> >
> > vin1ep: endpoint {
> > remote-endpoint = <>;
> > -   bus-width = <8>;
> > };
> > };
> >  };
> > diff --git a/arch/arm/boot/dts/r8a7791-porter.dts 
> > b/arch/arm/boot/dts/r8a7791-porter.dts
> > index c14e6fe..055a7f1 100644
> > --- a/arch/arm/boot/dts/r8a7791-porter.dts
> > +++ b/arch/arm/boot/dts/r8a7791-porter.dts
> > @@ -391,7 +391,6 @@
> >
> > vin0ep: endpoint {
> > remote-endpoint = <>;
> > -   bus-width = <8>;
> > };
> > };
> >  };
> > diff --git a/arch/arm/boot/dts/r8a7793-gose.dts 
> > b/arch/arm/boot/dts/r8a7793-gose.dts
> > index 9ed6961..9d3fba2 100644
> > --- a/arch/arm/boot/dts/r8a7793-gose.dts
> > +++ b/arch/arm/boot/dts/r8a7793-gose.dts
> > @@ -759,10 +759,8 @@
> >
> > vin0ep2: endpoint {
> > remote-endpoint = <_out>;
> > -   bus-width = <24>;
> > hsync-active = <0>;
> > vsync-active = <0>;
> > -   pclk-sample = <1>;
> > data-active = <1>;
> > };
> > };
> > @@ -781,7 +779,6 @@
> >
> > vin1ep: endpoint {
> > remote-endpoint = <_out>;
> > -   bus-width = <8>;
> > };
> > };
> >  };
> > diff --git a/arch/arm/boot/dts/r8a7794-alt.dts 
> > b/arch/arm/boot/dts/r8a7794-alt.dts
> > index 26a8834..4bbb9cc 100644
> > --- a/arch/arm/boot/dts/r8a7794-alt.dts
> > +++ b/arch/arm/boot/dts/r8a7794-alt.dts
> > @@ -380,7 +380,6 @@
> >
> > vin0ep: endpoint {
> > remote-endpoint = <>;
> > -   bus-width = <8>;
> > };
> > };
> >  };
> > diff --git a/arch/arm/boot/dts/r8a7794-silk.dts 
> > b/arch/arm/boot/dts/r8a7794-silk.dts
> > index 351cb3b..c0c5d31 100644
> > --- a/arch/arm/boot/dts/r8a7794-silk.dts
> > +++ b/arch/arm/boot/dts/r8a7794-silk.dts
> > @@ -480,7 +480,6 @@
> >
> > vin0ep: endpoint {
> > remote-endpoint = <>;
> > -   bus-width = <8>;
> > };
> > 

[PATCH] media: v4l2-ioctl: prevent underflow in v4l_enumoutput()

[Dan Carpenter]

My Smatch allmodconfig build only detects one function implementing
vpbe_device_ops->enum_outputs and that's vpbe_enum_outputs().  The
problem really happens in that function when we do:

int temp_index = output->index;

if (temp_index >= cfg->num_outputs)
return -EINVAL;

Unfortunately, both temp_index and cfg->num_outputs are type int so we
have a potential read before the start of the array if "temp_index" is
negative.

I could have fixed the bug in that function but it's more secure and
future proof to block that bug earlier in a central place.  There is no
one who need p->index to be more than INT_MAX.

Fixes: 66715cdc3224 ("[media] davinci vpbe: VPBE display driver")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index a40dbec271f1..115757ab8bc0 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1099,6 +1099,9 @@ static int v4l_enumoutput(const struct v4l2_ioctl_ops 
*ops,
if (is_valid_ioctl(vfd, VIDIOC_S_STD))
p->capabilities |= V4L2_OUT_CAP_STD;
 
+   if (p->index > INT_MAX)
+   return -EINVAL;
+
return ops->vidioc_enum_output(file, fh, p);
 }
 

Re: [PATCH] dt-bindings: media: rcar_vin: fix style for ports and endpoints

[Sergei Shtylyov]

On 5/17/2018 2:32 AM, Niklas Söderlund wrote:


The style for referring to ports and endpoint are wrong. Refer to them
using lowercase and a unit address, port@x and endpoint@x.

Signed-off-by: Niklas Söderlund 
Reported-by: Geert Uytterhoeven 


   More typos, yay! :-)


---
  .../devicetree/bindings/media/rcar_vin.txt| 20 +--
  1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
b/Documentation/devicetree/bindings/media/rcar_vin.txt
index c2c57dcf73f4851b..a574b9c037c05a3c 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -45,23 +45,23 @@ The per-board settings Gen2 platforms:
  The per-board settings Gen3 platforms:
  
  Gen3 platforms can support both a single connected parallel input source

-from external SoC pins (port0) and/or multiple parallel input sources
-from local SoC CSI-2 receivers (port1) depending on SoC.
+from external SoC pins (port@0) and/or multiple parallel input sources
+from local SoC CSI-2 receivers (port@1) depending on SoC.
  
  - renesas,id - ID number of the VIN, VINx in the documentation.

  - ports
-- port 0 - sub-node describing a single endpoint connected to the VIN
+- port@0 - sub-node describing a single endpoint connected to the VIN
from external SoC pins described in video-interfaces.txt[1].
-  Describing more then one endpoint in port 0 is invalid. Only VIN
-  instances that are connected to external pins should have port 0.
-- port 1 - sub-nodes describing one or more endpoints connected to
+  Describing more then one endpoint in port@0 is invalid. Only VIN


   s/then/than/.


+  instances that are connected to external pins should have port@0.
+- port@1 - sub-nodes describing one or more endpoints connected to
the VIN from local SoC CSI-2 receivers. The endpoint numbers must
use the following schema.

[...]

MBR, Sergei

Re: [PATCH] rcar-vin: sync which hardware buffer to start capture from

[Sergei Shtylyov]

Hello!

On 5/17/2018 2:22 AM, Niklas Söderlund wrote:


When starting the VIN capture procedure we are not guaranteed that the
first buffer writing to is VnMB1 to which we assigned the first buffer


   Written, perhaps?


queued. This is problematic for two reasons. Buffers might not be
dequeued in the same order they where queued for capture. Future
features planed for the VIN driver is support for outputing frames in


   Outputting.


SEQ_TB/BT format and to do that it's important that capture starts from
the first buffer slot, VnMB1.

We are guaranteed that capturing always happens in sequence (VnMB1 ->
VnMB2 -> VnMB3 -> VnMB1). So drop up to two frames when starting
capturing so that the driver always returns buffers in the same order
they are queued and prepare for SEQ_TB/BT output.

Signed-off-by: Niklas Söderlund 
---
  drivers/media/platform/rcar-vin/rcar-dma.c | 16 +++-
  drivers/media/platform/rcar-vin/rcar-vin.h |  2 ++
  2 files changed, 17 insertions(+), 1 deletion(-)


[...]

MBR, Sergei

[PATCH] media: vivid: potential integer overflow in vidioc_g_edid()

[Dan Carpenter]

If we pick a very large "edid->blocks" value then the "edid->start_block
+ edid->blocks" addition could wrap around.

Fixes: ef834f7836ec ("[media] vivid: add the video capture and output parts")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/media/platform/vivid/vivid-vid-common.c 
b/drivers/media/platform/vivid/vivid-vid-common.c
index e5914be0e12d..be531caa2cdf 100644
--- a/drivers/media/platform/vivid/vivid-vid-common.c
+++ b/drivers/media/platform/vivid/vivid-vid-common.c
@@ -860,7 +860,7 @@ int vidioc_g_edid(struct file *file, void *_fh,
return -ENODATA;
if (edid->start_block >= dev->edid_blocks)
return -EINVAL;
-   if (edid->start_block + edid->blocks > dev->edid_blocks)
+   if (edid->blocks > dev->edid_blocks - edid->start_block)
edid->blocks = dev->edid_blocks - edid->start_block;
if (adap)
cec_set_edid_phys_addr(dev->edid, dev->edid_blocks * 128, 
adap->phys_addr);

[PATCH v3 00/12] media: ov5640: Misc cleanup and improvements

[Maxime Ripard]

Hi,

Here is a "small" series that mostly cleans up the ov5640 driver code,
slowly getting rid of the big data array for more understandable code
(hopefully).

The biggest addition would be the clock rate computation at runtime,
instead of relying on those arrays to setup the clock tree
properly. As a side effect, it fixes the framerate that was off by
around 10% on the smaller resolutions, and we now support 60fps.

This also introduces a bunch of new features.

Let me know what you think,
Maxime

Changes from v2:
  - Rebased on latest Sakari PR
  - Fixed the issues reported by Hugues: improper FPS returned for
formats, improper rounding of the FPS, some with his suggestions,
some by simplifying the logic.
  - Expanded the clock tree comments based on the feedback from Samuel
Bobrowicz and Loic Poulain
  - Merged some of the changes made by Samuel Bobrowicz to fix the
MIPI rate computation, fix the call sites of the
ov5640_set_timings function, the auto-exposure calculation call,
etc.
  - Split the patches into smaller ones in order to make it more
readable (hopefully)

Changes from v1:
  - Integrated Hugues' suggestions to fix v4l2-compliance
  - Fixed the bus width with JPEG
  - Dropped the clock rate calculation loops for something simpler as
suggested by Sakari
  - Cache the exposure value instead of using the control value
  - Rebased on top of 4.17

Maxime Ripard (11):
  media: ov5640: Adjust the clock based on the expected rate
  media: ov5640: Remove the clocks registers initialization
  media: ov5640: Remove redundant defines
  media: ov5640: Remove redundant register setup
  media: ov5640: Compute the clock rate at runtime
  media: ov5640: Remove pixel clock rates
  media: ov5640: Enhance FPS handling
  media: ov5640: Make the return rate type more explicit
  media: ov5640: Make the FPS clamping / rounding more extendable
  media: ov5640: Add 60 fps support
  media: ov5640: Remove duplicate auto-exposure setup

Samuel Bobrowicz (1):
  media: ov5640: Fix timings setup code

 drivers/media/i2c/ov5640.c | 701 +
 1 file changed, 392 insertions(+), 309 deletions(-)

-- 
2.17.0

[PATCH v3 01/12] media: ov5640: Fix timings setup code

[Maxime Ripard]

From: Samuel Bobrowicz 

The current code, when changing the mode and changing the scaling or
sampling parameters, will look at the horizontal and vertical total size,
which, since 5999f381e023 ("media: ov5640: Add horizontal and vertical
totals") has been moved from the static register initialization to after
the mode change.

That means that the values are no longer set up before the code retrieves
them, which is obviously a bug.

Fixes: 5999f381e023 ("media: ov5640: Add horizontal and vertical totals")
Signed-off-by: Samuel Bobrowicz 
Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index e480e53b369b..4bd968b478db 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -1462,6 +1462,10 @@ static int ov5640_set_mode_exposure_calc(struct 
ov5640_dev *sensor,
if (ret < 0)
return ret;
 
+   ret = ov5640_set_timings(sensor, mode);
+   if (ret < 0)
+   return ret;
+
/* read capture VTS */
ret = ov5640_get_vts(sensor);
if (ret < 0)
@@ -1589,6 +1593,10 @@ static int ov5640_set_mode_direct(struct ov5640_dev 
*sensor,
if (ret < 0)
return ret;
 
+   ret = ov5640_set_timings(sensor, mode);
+   if (ret < 0)
+   return ret;
+
/* turn auto gain/exposure back on for direct mode */
ret = __v4l2_ctrl_s_ctrl(sensor->ctrls.auto_gain, 1);
if (ret)
@@ -1633,10 +1641,6 @@ static int ov5640_set_mode(struct ov5640_dev *sensor,
ret = ov5640_set_mode_direct(sensor, mode, exposure);
}
 
-   if (ret < 0)
-   return ret;
-
-   ret = ov5640_set_timings(sensor, mode);
if (ret < 0)
return ret;
 
-- 
2.17.0

[PATCH v3 03/12] media: ov5640: Remove the clocks registers initialization

[Maxime Ripard]

Part of the hardcoded initialization sequence is to set up the proper clock
dividers. However, this is now done dynamically through proper code and as
such, the static one is now redundant.

Let's remove it.

Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 46 ++
 1 file changed, 22 insertions(+), 24 deletions(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 63923d85a31f..45e5ba32b8d1 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -256,8 +256,7 @@ static inline struct v4l2_subdev *ctrl_to_sd(struct 
v4l2_ctrl *ctrl)
 static const struct reg_value ov5640_init_setting_30fps_VGA[] = {
{0x3103, 0x11, 0, 0}, {0x3008, 0x82, 0, 5}, {0x3008, 0x42, 0, 0},
{0x3103, 0x03, 0, 0}, {0x3017, 0x00, 0, 0}, {0x3018, 0x00, 0, 0},
-   {0x3034, 0x18, 0, 0}, {0x3035, 0x14, 0, 0}, {0x3036, 0x38, 0, 0},
-   {0x3037, 0x13, 0, 0}, {0x3630, 0x36, 0, 0},
+   {0x3630, 0x36, 0, 0},
{0x3631, 0x0e, 0, 0}, {0x3632, 0xe2, 0, 0}, {0x3633, 0x12, 0, 0},
{0x3621, 0xe0, 0, 0}, {0x3704, 0xa0, 0, 0}, {0x3703, 0x5a, 0, 0},
{0x3715, 0x78, 0, 0}, {0x3717, 0x01, 0, 0}, {0x370b, 0x60, 0, 0},
@@ -340,7 +339,7 @@ static const struct reg_value 
ov5640_init_setting_30fps_VGA[] = {
 };
 
 static const struct reg_value ov5640_setting_30fps_VGA_640_480[] = {
-   {0x3035, 0x14, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0},
+   {0x3c07, 0x08, 0, 0},
{0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
{0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0},
{0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
@@ -359,7 +358,7 @@ static const struct reg_value 
ov5640_setting_30fps_VGA_640_480[] = {
 };
 
 static const struct reg_value ov5640_setting_15fps_VGA_640_480[] = {
-   {0x3035, 0x22, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0},
+   {0x3c07, 0x08, 0, 0},
{0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
{0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0},
{0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
@@ -378,7 +377,7 @@ static const struct reg_value 
ov5640_setting_15fps_VGA_640_480[] = {
 };
 
 static const struct reg_value ov5640_setting_30fps_XGA_1024_768[] = {
-   {0x3035, 0x14, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0},
+   {0x3c07, 0x08, 0, 0},
{0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
{0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0},
{0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
@@ -394,11 +393,10 @@ static const struct reg_value 
ov5640_setting_30fps_XGA_1024_768[] = {
{0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x4713, 0x03, 0, 0},
{0x4407, 0x04, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0},
{0x3824, 0x02, 0, 0}, {0x5001, 0xa3, 0, 0}, {0x3503, 0x00, 0, 0},
-   {0x3035, 0x12, 0, 0},
 };
 
 static const struct reg_value ov5640_setting_15fps_XGA_1024_768[] = {
-   {0x3035, 0x22, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0},
+   {0x3c07, 0x08, 0, 0},
{0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
{0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0},
{0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
@@ -417,7 +415,7 @@ static const struct reg_value 
ov5640_setting_15fps_XGA_1024_768[] = {
 };
 
 static const struct reg_value ov5640_setting_30fps_QVGA_320_240[] = {
-   {0x3035, 0x14, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0},
+   {0x3c07, 0x08, 0, 0},
{0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
{0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0},
{0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
@@ -436,7 +434,7 @@ static const struct reg_value 
ov5640_setting_30fps_QVGA_320_240[] = {
 };
 
 static const struct reg_value ov5640_setting_15fps_QVGA_320_240[] = {
-   {0x3035, 0x22, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0},
+   {0x3c07, 0x08, 0, 0},
{0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
{0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0},
{0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
@@ -455,7 +453,7 @@ static const struct reg_value 
ov5640_setting_15fps_QVGA_320_240[] = {
 };
 
 static const struct reg_value ov5640_setting_30fps_QCIF_176_144[] = {
-   {0x3035, 0x14, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0},
+   {0x3c07, 0x08, 0, 0},
{0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
{0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0},
{0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
@@ -474,7 +472,7 @@ static const struct 

[PATCH v3 02/12] media: ov5640: Adjust the clock based on the expected rate

[Maxime Ripard]

The clock structure for the PCLK is quite obscure in the documentation, and
was hardcoded through the bytes array of each and every mode.

This is troublesome, since we cannot adjust it at runtime based on other
parameters (such as the number of bytes per pixel), and we can't support
either framerates that have not been used by the various vendors, since we
don't have the needed initialization sequence.

We can however understand how the clock tree works, and then implement some
functions to derive the various parameters from a given rate. And now that
those parameters are calculated at runtime, we can remove them from the
initialization sequence.

The modes also gained a new parameter which is the clock that they are
running at, from the register writes they were doing, so for now the switch
to the new algorithm should be transparent.

Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 289 -
 1 file changed, 288 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 4bd968b478db..63923d85a31f 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -174,6 +174,7 @@ struct ov5640_mode_info {
u32 htot;
u32 vact;
u32 vtot;
+   u32 pixel_clock;
const struct reg_value *reg_data;
u32 reg_data_size;
 };
@@ -695,6 +696,7 @@ static const struct reg_value 
ov5640_setting_15fps_QSXGA_2592_1944[] = {
 /* power-on sensor init reg table */
 static const struct ov5640_mode_info ov5640_mode_init_data = {
0, SUBSAMPLING, 640, 1896, 480, 984,
+   5600,
ov5640_init_setting_30fps_VGA,
ARRAY_SIZE(ov5640_init_setting_30fps_VGA),
 };
@@ -704,74 +706,91 @@ ov5640_mode_data[OV5640_NUM_FRAMERATES][OV5640_NUM_MODES] 
= {
{
{OV5640_MODE_QCIF_176_144, SUBSAMPLING,
 176, 1896, 144, 984,
+2800,
 ov5640_setting_15fps_QCIF_176_144,
 ARRAY_SIZE(ov5640_setting_15fps_QCIF_176_144)},
{OV5640_MODE_QVGA_320_240, SUBSAMPLING,
 320, 1896, 240, 984,
+2800,
 ov5640_setting_15fps_QVGA_320_240,
 ARRAY_SIZE(ov5640_setting_15fps_QVGA_320_240)},
{OV5640_MODE_VGA_640_480, SUBSAMPLING,
 640, 1896, 480, 1080,
+2800,
 ov5640_setting_15fps_VGA_640_480,
 ARRAY_SIZE(ov5640_setting_15fps_VGA_640_480)},
{OV5640_MODE_NTSC_720_480, SUBSAMPLING,
 720, 1896, 480, 984,
+2800,
 ov5640_setting_15fps_NTSC_720_480,
 ARRAY_SIZE(ov5640_setting_15fps_NTSC_720_480)},
{OV5640_MODE_PAL_720_576, SUBSAMPLING,
 720, 1896, 576, 984,
+2800,
 ov5640_setting_15fps_PAL_720_576,
 ARRAY_SIZE(ov5640_setting_15fps_PAL_720_576)},
{OV5640_MODE_XGA_1024_768, SUBSAMPLING,
 1024, 1896, 768, 1080,
+2800,
 ov5640_setting_15fps_XGA_1024_768,
 ARRAY_SIZE(ov5640_setting_15fps_XGA_1024_768)},
{OV5640_MODE_720P_1280_720, SUBSAMPLING,
 1280, 1892, 720, 740,
+2100,
 ov5640_setting_15fps_720P_1280_720,
 ARRAY_SIZE(ov5640_setting_15fps_720P_1280_720)},
{OV5640_MODE_1080P_1920_1080, SCALING,
 1920, 2500, 1080, 1120,
+4200,
 ov5640_setting_15fps_1080P_1920_1080,
 ARRAY_SIZE(ov5640_setting_15fps_1080P_1920_1080)},
{OV5640_MODE_QSXGA_2592_1944, SCALING,
 2592, 2844, 1944, 1968,
+8400,
 ov5640_setting_15fps_QSXGA_2592_1944,
 ARRAY_SIZE(ov5640_setting_15fps_QSXGA_2592_1944)},
}, {
{OV5640_MODE_QCIF_176_144, SUBSAMPLING,
 176, 1896, 144, 984,
+5600,
 ov5640_setting_30fps_QCIF_176_144,
 ARRAY_SIZE(ov5640_setting_30fps_QCIF_176_144)},
{OV5640_MODE_QVGA_320_240, SUBSAMPLING,
 320, 1896, 240, 984,
+5600,
 ov5640_setting_30fps_QVGA_320_240,
 ARRAY_SIZE(ov5640_setting_30fps_QVGA_320_240)},
{OV5640_MODE_VGA_640_480, SUBSAMPLING,
 640, 1896, 480, 1080,
+5600,
 ov5640_setting_30fps_VGA_640_480,
 ARRAY_SIZE(ov5640_setting_30fps_VGA_640_480)},
{OV5640_MODE_NTSC_720_480, SUBSAMPLING,
 720, 1896, 480, 984,
+5600,
 ov5640_setting_30fps_NTSC_720_480,
 ARRAY_SIZE(ov5640_setting_30fps_NTSC_720_480)},

[PATCH v3 07/12] media: ov5640: Remove pixel clock rates

[Maxime Ripard]

The pixel clock rates were introduced to report the initially static clock
rate.

Since this is now handled dynamically, we can remove them entirely.

Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 21 +
 1 file changed, 1 insertion(+), 20 deletions(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index e9bd0aa55409..48f3c9e640ed 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -171,7 +171,6 @@ struct ov5640_mode_info {
u32 htot;
u32 vact;
u32 vtot;
-   u32 pixel_clock;
const struct reg_value *reg_data;
u32 reg_data_size;
 };
@@ -691,7 +690,6 @@ static const struct reg_value 
ov5640_setting_15fps_QSXGA_2592_1944[] = {
 /* power-on sensor init reg table */
 static const struct ov5640_mode_info ov5640_mode_init_data = {
0, SUBSAMPLING, 640, 1896, 480, 984,
-   5600,
ov5640_init_setting_30fps_VGA,
ARRAY_SIZE(ov5640_init_setting_30fps_VGA),
 };
@@ -701,91 +699,74 @@ ov5640_mode_data[OV5640_NUM_FRAMERATES][OV5640_NUM_MODES] 
= {
{
{OV5640_MODE_QCIF_176_144, SUBSAMPLING,
 176, 1896, 144, 984,
-2800,
 ov5640_setting_15fps_QCIF_176_144,
 ARRAY_SIZE(ov5640_setting_15fps_QCIF_176_144)},
{OV5640_MODE_QVGA_320_240, SUBSAMPLING,
 320, 1896, 240, 984,
-2800,
 ov5640_setting_15fps_QVGA_320_240,
 ARRAY_SIZE(ov5640_setting_15fps_QVGA_320_240)},
{OV5640_MODE_VGA_640_480, SUBSAMPLING,
 640, 1896, 480, 1080,
-2800,
 ov5640_setting_15fps_VGA_640_480,
 ARRAY_SIZE(ov5640_setting_15fps_VGA_640_480)},
{OV5640_MODE_NTSC_720_480, SUBSAMPLING,
 720, 1896, 480, 984,
-2800,
 ov5640_setting_15fps_NTSC_720_480,
 ARRAY_SIZE(ov5640_setting_15fps_NTSC_720_480)},
{OV5640_MODE_PAL_720_576, SUBSAMPLING,
 720, 1896, 576, 984,
-2800,
 ov5640_setting_15fps_PAL_720_576,
 ARRAY_SIZE(ov5640_setting_15fps_PAL_720_576)},
{OV5640_MODE_XGA_1024_768, SUBSAMPLING,
 1024, 1896, 768, 1080,
-2800,
 ov5640_setting_15fps_XGA_1024_768,
 ARRAY_SIZE(ov5640_setting_15fps_XGA_1024_768)},
{OV5640_MODE_720P_1280_720, SUBSAMPLING,
 1280, 1892, 720, 740,
-2100,
 ov5640_setting_15fps_720P_1280_720,
 ARRAY_SIZE(ov5640_setting_15fps_720P_1280_720)},
{OV5640_MODE_1080P_1920_1080, SCALING,
 1920, 2500, 1080, 1120,
-4200,
 ov5640_setting_15fps_1080P_1920_1080,
 ARRAY_SIZE(ov5640_setting_15fps_1080P_1920_1080)},
{OV5640_MODE_QSXGA_2592_1944, SCALING,
 2592, 2844, 1944, 1968,
-8400,
 ov5640_setting_15fps_QSXGA_2592_1944,
 ARRAY_SIZE(ov5640_setting_15fps_QSXGA_2592_1944)},
}, {
{OV5640_MODE_QCIF_176_144, SUBSAMPLING,
 176, 1896, 144, 984,
-5600,
 ov5640_setting_30fps_QCIF_176_144,
 ARRAY_SIZE(ov5640_setting_30fps_QCIF_176_144)},
{OV5640_MODE_QVGA_320_240, SUBSAMPLING,
 320, 1896, 240, 984,
-5600,
 ov5640_setting_30fps_QVGA_320_240,
 ARRAY_SIZE(ov5640_setting_30fps_QVGA_320_240)},
{OV5640_MODE_VGA_640_480, SUBSAMPLING,
 640, 1896, 480, 1080,
-5600,
 ov5640_setting_30fps_VGA_640_480,
 ARRAY_SIZE(ov5640_setting_30fps_VGA_640_480)},
{OV5640_MODE_NTSC_720_480, SUBSAMPLING,
 720, 1896, 480, 984,
-5600,
 ov5640_setting_30fps_NTSC_720_480,
 ARRAY_SIZE(ov5640_setting_30fps_NTSC_720_480)},
{OV5640_MODE_PAL_720_576, SUBSAMPLING,
 720, 1896, 576, 984,
-5600,
 ov5640_setting_30fps_PAL_720_576,
 ARRAY_SIZE(ov5640_setting_30fps_PAL_720_576)},
{OV5640_MODE_XGA_1024_768, SUBSAMPLING,
 1024, 1896, 768, 1080,
-5600,
 ov5640_setting_30fps_XGA_1024_768,
 ARRAY_SIZE(ov5640_setting_30fps_XGA_1024_768)},
{OV5640_MODE_720P_1280_720, SUBSAMPLING,
 1280, 1892, 720, 740,
-4200,
 ov5640_setting_30fps_720P_1280_720,
 ARRAY_SIZE(ov5640_setting_30fps_720P_1280_720)},

[PATCH v3 08/12] media: ov5640: Enhance FPS handling

[Maxime Ripard]

Now that we have moved the clock generation logic out of the bytes array,
these arrays are identical between the 15fps and 30fps variants.

Remove the duplicate entries, and convert the code accordingly.

Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 316 +++--
 1 file changed, 60 insertions(+), 256 deletions(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 48f3c9e640ed..785a692946b6 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -334,64 +334,7 @@ static const struct reg_value 
ov5640_init_setting_30fps_VGA[] = {
{0x3a1f, 0x14, 0, 0}, {0x3008, 0x02, 0, 0}, {0x3c00, 0x04, 0, 300},
 };
 
-static const struct reg_value ov5640_setting_30fps_VGA_640_480[] = {
-   {0x3c07, 0x08, 0, 0},
-   {0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
-   {0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0},
-   {0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
-   {0x3802, 0x00, 0, 0}, {0x3803, 0x04, 0, 0}, {0x3804, 0x0a, 0, 0},
-   {0x3805, 0x3f, 0, 0}, {0x3806, 0x07, 0, 0}, {0x3807, 0x9b, 0, 0},
-   {0x3810, 0x00, 0, 0},
-   {0x3811, 0x10, 0, 0}, {0x3812, 0x00, 0, 0}, {0x3813, 0x06, 0, 0},
-   {0x3618, 0x00, 0, 0}, {0x3612, 0x29, 0, 0}, {0x3708, 0x64, 0, 0},
-   {0x3709, 0x52, 0, 0}, {0x370c, 0x03, 0, 0}, {0x3a02, 0x03, 0, 0},
-   {0x3a03, 0xd8, 0, 0}, {0x3a08, 0x01, 0, 0}, {0x3a09, 0x0e, 0, 0},
-   {0x3a0a, 0x00, 0, 0}, {0x3a0b, 0xf6, 0, 0}, {0x3a0e, 0x03, 0, 0},
-   {0x3a0d, 0x04, 0, 0}, {0x3a14, 0x03, 0, 0}, {0x3a15, 0xd8, 0, 0},
-   {0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x4713, 0x03, 0, 0},
-   {0x4407, 0x04, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0},
-   {0x3824, 0x02, 0, 0}, {0x5001, 0xa3, 0, 0}, {0x3503, 0x00, 0, 0},
-};
-
-static const struct reg_value ov5640_setting_15fps_VGA_640_480[] = {
-   {0x3c07, 0x08, 0, 0},
-   {0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
-   {0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0},
-   {0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
-   {0x3802, 0x00, 0, 0}, {0x3803, 0x04, 0, 0}, {0x3804, 0x0a, 0, 0},
-   {0x3805, 0x3f, 0, 0}, {0x3806, 0x07, 0, 0}, {0x3807, 0x9b, 0, 0},
-   {0x3810, 0x00, 0, 0},
-   {0x3811, 0x10, 0, 0}, {0x3812, 0x00, 0, 0}, {0x3813, 0x06, 0, 0},
-   {0x3618, 0x00, 0, 0}, {0x3612, 0x29, 0, 0}, {0x3708, 0x64, 0, 0},
-   {0x3709, 0x52, 0, 0}, {0x370c, 0x03, 0, 0}, {0x3a02, 0x03, 0, 0},
-   {0x3a03, 0xd8, 0, 0}, {0x3a08, 0x01, 0, 0}, {0x3a09, 0x27, 0, 0},
-   {0x3a0a, 0x00, 0, 0}, {0x3a0b, 0xf6, 0, 0}, {0x3a0e, 0x03, 0, 0},
-   {0x3a0d, 0x04, 0, 0}, {0x3a14, 0x03, 0, 0}, {0x3a15, 0xd8, 0, 0},
-   {0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x4713, 0x03, 0, 0},
-   {0x4407, 0x04, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0},
-   {0x3824, 0x02, 0, 0}, {0x5001, 0xa3, 0, 0},
-};
-
-static const struct reg_value ov5640_setting_30fps_XGA_1024_768[] = {
-   {0x3c07, 0x08, 0, 0},
-   {0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
-   {0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0},
-   {0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
-   {0x3802, 0x00, 0, 0}, {0x3803, 0x04, 0, 0}, {0x3804, 0x0a, 0, 0},
-   {0x3805, 0x3f, 0, 0}, {0x3806, 0x07, 0, 0}, {0x3807, 0x9b, 0, 0},
-   {0x3810, 0x00, 0, 0},
-   {0x3811, 0x10, 0, 0}, {0x3812, 0x00, 0, 0}, {0x3813, 0x06, 0, 0},
-   {0x3618, 0x00, 0, 0}, {0x3612, 0x29, 0, 0}, {0x3708, 0x64, 0, 0},
-   {0x3709, 0x52, 0, 0}, {0x370c, 0x03, 0, 0}, {0x3a02, 0x03, 0, 0},
-   {0x3a03, 0xd8, 0, 0}, {0x3a08, 0x01, 0, 0}, {0x3a09, 0x0e, 0, 0},
-   {0x3a0a, 0x00, 0, 0}, {0x3a0b, 0xf6, 0, 0}, {0x3a0e, 0x03, 0, 0},
-   {0x3a0d, 0x04, 0, 0}, {0x3a14, 0x03, 0, 0}, {0x3a15, 0xd8, 0, 0},
-   {0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x4713, 0x03, 0, 0},
-   {0x4407, 0x04, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0},
-   {0x3824, 0x02, 0, 0}, {0x5001, 0xa3, 0, 0}, {0x3503, 0x00, 0, 0},
-};
-
-static const struct reg_value ov5640_setting_15fps_XGA_1024_768[] = {
+static const struct reg_value ov5640_setting_VGA_640_480[] = {
{0x3c07, 0x08, 0, 0},
{0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
{0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0},
@@ -410,7 +353,7 @@ static const struct reg_value 
ov5640_setting_15fps_XGA_1024_768[] = {
{0x3824, 0x02, 0, 0}, {0x5001, 0xa3, 0, 0},
 };
 
-static const struct reg_value ov5640_setting_30fps_QVGA_320_240[] = {
+static const struct reg_value ov5640_setting_XGA_1024_768[] = {
{0x3c07, 0x08, 0, 0},
{0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
{0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 

[PATCH v3 06/12] media: ov5640: Compute the clock rate at runtime

[Maxime Ripard]

The clock rate, while hardcoded until now, is actually a function of the
resolution, framerate and bytes per pixel. Now that we have an algorithm to
adjust our clock rate, we can select it dynamically when we change the
mode.

This changes a bit the clock rate being used, with the following effect:

+--+--+--+--+-+-++---+
| Hact | Vact | Htot | Vtot | FPS | Hardcoded clock | Computed clock | 
Deviation |
+--+--+--+--+-+-++---+
|  640 |  480 | 1896 | 1080 |  15 |5600 |   61430400 | 8.84 %   
 |
|  640 |  480 | 1896 | 1080 |  30 |   11200 |  122860800 | 8.84 %   
 |
| 1024 |  768 | 1896 | 1080 |  15 |5600 |   61430400 | 8.84 %   
 |
| 1024 |  768 | 1896 | 1080 |  30 |   11200 |  122860800 | 8.84 %   
 |
|  320 |  240 | 1896 |  984 |  15 |5600 |   55969920 | 0.05 %   
 |
|  320 |  240 | 1896 |  984 |  30 |   11200 |  111939840 | 0.05 %   
 |
|  176 |  144 | 1896 |  984 |  15 |5600 |   55969920 | 0.05 %   
 |
|  176 |  144 | 1896 |  984 |  30 |   11200 |  111939840 | 0.05 %   
 |
|  720 |  480 | 1896 |  984 |  15 |5600 |   55969920 | 0.05 %   
 |
|  720 |  480 | 1896 |  984 |  30 |   11200 |  111939840 | 0.05 %   
 |
|  720 |  576 | 1896 |  984 |  15 |5600 |   55969920 | 0.05 %   
 |
|  720 |  576 | 1896 |  984 |  30 |   11200 |  111939840 | 0.05 %   
 |
| 1280 |  720 | 1892 |  740 |  15 |4200 |   42002400 | 0.01 %   
 |
| 1280 |  720 | 1892 |  740 |  30 |8400 |   84004800 | 0.01 %   
 |
| 1920 | 1080 | 2500 | 1120 |  15 |8400 |   8400 | 0.00 %   
 |
| 1920 | 1080 | 2500 | 1120 |  30 |   16800 |  16800 | 0.00 %   
 |
| 2592 | 1944 | 2844 | 1944 |  15 |8400 |  165862080 | 49.36 %  
 |
+--+--+--+--+-+-++---+

Only the 640x480, 1024x768 and 2592x1944 modes are significantly affected
by the new formula.

In this case, 640x480 and 1024x768 are actually fixed by this change.
Indeed, the sensor was sending data at, for example, 27.33fps instead of
30fps. This is -9%, which is roughly what we're seeing in the array.
Testing these modes with the new clock setup actually fix that error, and
data are now sent at around 30fps.

2592x1944, on the other hand, is probably due to the fact that this mode
can only be used using MIPI-CSI2, in a two lane mode, and never really
tested with a DVP bus.

Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 77864a1a5eb0..e9bd0aa55409 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -1886,7 +1886,8 @@ static int ov5640_set_mode(struct ov5640_dev *sensor,
 * which is 8 bits per pixel.
 */
bpp = sensor->fmt.code == MEDIA_BUS_FMT_JPEG_1X8 ? 8 : 16;
-   rate = mode->pixel_clock * bpp;
+   rate = mode->vtot * mode->htot * bpp;
+   rate *= ov5640_framerates[sensor->current_fr];
if (sensor->ep.bus_type == V4L2_MBUS_CSI2) {
rate = rate / sensor->ep.bus.mipi_csi2.num_data_lanes;
ret = ov5640_set_mipi_pclk(sensor, rate);
-- 
2.17.0

[PATCH v3 09/12] media: ov5640: Make the return rate type more explicit

[Maxime Ripard]

In the ov5640_try_frame_interval function, the ret variable actually holds
the frame rate index to use, which is represented by the enum
ov5640_frame_rate in the driver.

Make it more obvious.

Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 785a692946b6..b9a8f3feed74 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -1889,8 +1889,8 @@ static int ov5640_try_frame_interval(struct ov5640_dev 
*sensor,
 u32 width, u32 height)
 {
const struct ov5640_mode_info *mode;
+   enum ov5640_frame_rate rate = OV5640_30_FPS;
u32 minfps, maxfps, fps;
-   int ret;
 
minfps = ov5640_framerates[OV5640_15_FPS];
maxfps = ov5640_framerates[OV5640_30_FPS];
@@ -1913,10 +1913,10 @@ static int ov5640_try_frame_interval(struct ov5640_dev 
*sensor,
else
fi->denominator = minfps;
 
-   ret = (fi->denominator == minfps) ? OV5640_15_FPS : OV5640_30_FPS;
+   rate = (fi->denominator == minfps) ? OV5640_15_FPS : OV5640_30_FPS;
 
-   mode = ov5640_find_mode(sensor, ret, width, height, false);
-   return mode ? ret : -EINVAL;
+   mode = ov5640_find_mode(sensor, rate, width, height, false);
+   return mode ? rate : -EINVAL;
 }
 
 static int ov5640_get_fmt(struct v4l2_subdev *sd,
-- 
2.17.0

[PATCH v3 12/12] media: ov5640: Remove duplicate auto-exposure setup

[Maxime Ripard]

The autoexposure setup in the 1080p init array is redundant with the
default value of the sensor.

Remove it.

Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index a8852ded60b6..6df227b22303 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -498,7 +498,7 @@ static const struct reg_value 
ov5640_setting_1080P_1920_1080[] = {
{0x3a0e, 0x03, 0, 0}, {0x3a0d, 0x04, 0, 0}, {0x3a14, 0x04, 0, 0},
{0x3a15, 0x60, 0, 0}, {0x4713, 0x02, 0, 0}, {0x4407, 0x04, 0, 0},
{0x460b, 0x37, 0, 0}, {0x460c, 0x20, 0, 0}, {0x3824, 0x04, 0, 0},
-   {0x4005, 0x1a, 0, 0}, {0x3008, 0x02, 0, 0}, {0x3503, 0, 0, 0},
+   {0x4005, 0x1a, 0, 0}, {0x3008, 0x02, 0, 0},
 };
 
 static const struct reg_value ov5640_setting_QSXGA_2592_1944[] = {
-- 
2.17.0

[PATCH v3 11/12] media: ov5640: Add 60 fps support

[Maxime Ripard]

Now that we have everything in place to compute the clock rate at runtime,
we can enable the 60fps framerate for the mode we tested it with.

Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 30 --
 1 file changed, 24 insertions(+), 6 deletions(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 0f6c39080d69..a8852ded60b6 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -109,6 +109,7 @@ enum ov5640_mode_id {
 enum ov5640_frame_rate {
OV5640_15_FPS = 0,
OV5640_30_FPS,
+   OV5640_60_FPS,
OV5640_NUM_FRAMERATES,
 };
 
@@ -137,6 +138,7 @@ MODULE_PARM_DESC(virtual_channel,
 static const int ov5640_framerates[] = {
[OV5640_15_FPS] = 15,
[OV5640_30_FPS] = 30,
+   [OV5640_60_FPS] = 60,
 };
 
 /* regulator supplies */
@@ -1439,12 +1441,23 @@ ov5640_find_mode(struct ov5640_dev *sensor, enum 
ov5640_frame_rate fr,
/* try to find another mode */
continue;
 
+   /* Only 640x480 can operate at 60fps (for now) */
+   if (fr == OV5640_60_FPS &&
+   !(width == 640 && height == 480))
+   /* try to find another mode */
+   continue;
+
break;
}
}
 
-   if (nearest && i < 0)
-   mode = _mode_data[0];
+   /* VGA is the only mode that supports all the framerates */
+   if (i < 0) {
+   if (!nearest)
+   return NULL;
+
+   mode = _mode_data[OV5640_MODE_VGA_640_480];
+   }
 
return mode;
 }
@@ -1894,12 +1907,13 @@ static int ov5640_try_frame_interval(struct ov5640_dev 
*sensor,
int i;
 
minfps = ov5640_framerates[OV5640_15_FPS];
-   maxfps = ov5640_framerates[OV5640_30_FPS];
+   maxfps = ov5640_framerates[OV5640_60_FPS];
 
if (fi->numerator == 0) {
fi->denominator = maxfps;
fi->numerator = 1;
-   return OV5640_30_FPS;
+   rate = OV5640_60_FPS;
+   goto find_mode;
}
 
fps = clamp_val(DIV_ROUND_CLOSEST(fi->denominator, fi->numerator),
@@ -1918,6 +1932,7 @@ static int ov5640_try_frame_interval(struct ov5640_dev 
*sensor,
fi->numerator = 1;
fi->denominator = best_fps;
 
+find_mode:
mode = ov5640_find_mode(sensor, rate, width, height, false);
return mode ? rate : -EINVAL;
 }
@@ -2495,8 +2510,11 @@ static int ov5640_s_frame_interval(struct v4l2_subdev 
*sd,
 
frame_rate = ov5640_try_frame_interval(sensor, >interval,
   mode->hact, mode->vact);
-   if (frame_rate < 0)
-   frame_rate = OV5640_15_FPS;
+   if (frame_rate < 0) {
+   /* Always return a valid frame interval value */
+   fi->interval = sensor->frame_interval;
+   goto out;
+   }
 
sensor->current_fr = frame_rate;
sensor->frame_interval = fi->interval;
-- 
2.17.0

[PATCH v3 05/12] media: ov5640: Remove redundant register setup

[Maxime Ripard]

The MIPI divider is also cleared as part of the clock setup sequence, so we
can remove that code.

Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index ce9bfaafb675..77864a1a5eb0 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -1281,16 +1281,6 @@ static int ov5640_set_stream_dvp(struct ov5640_dev 
*sensor, bool on)
 */
 
if (on) {
-   /*
-* reset MIPI PCLK/SERCLK divider
-*
-* SC PLL CONTRL1 0
-* - [3..0]:MIPI PCLK/SERCLK divider
-*/
-   ret = ov5640_mod_reg(sensor, OV5640_REG_SC_PLL_CTRL1, 0x0f, 0);
-   if (ret)
-   return ret;
-
/*
 * configure parallel port control lines polarity
 *
-- 
2.17.0

[PATCH v3 10/12] media: ov5640: Make the FPS clamping / rounding more extendable

[Maxime Ripard]

The current code uses an algorithm to clamp the FPS values and round them
to the closest supported one that isn't really allows to be extended to
more than two values.

Rework it a bit to make it much easier to extend the amount of FPS options
we support.

Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 27 +++
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index b9a8f3feed74..0f6c39080d69 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -1890,7 +1890,8 @@ static int ov5640_try_frame_interval(struct ov5640_dev 
*sensor,
 {
const struct ov5640_mode_info *mode;
enum ov5640_frame_rate rate = OV5640_30_FPS;
-   u32 minfps, maxfps, fps;
+   int minfps, maxfps, best_fps, fps;
+   int i;
 
minfps = ov5640_framerates[OV5640_15_FPS];
maxfps = ov5640_framerates[OV5640_30_FPS];
@@ -1901,19 +1902,21 @@ static int ov5640_try_frame_interval(struct ov5640_dev 
*sensor,
return OV5640_30_FPS;
}
 
-   fps = DIV_ROUND_CLOSEST(fi->denominator, fi->numerator);
+   fps = clamp_val(DIV_ROUND_CLOSEST(fi->denominator, fi->numerator),
+   minfps, maxfps);
+
+   best_fps = minfps;
+   for (i = 0; i < ARRAY_SIZE(ov5640_framerates); i++) {
+   int curr_fps = ov5640_framerates[i];
+
+   if (abs(curr_fps - fps) < abs(best_fps - fps)) {
+   best_fps = curr_fps;
+   rate = i;
+   }
+   }
 
fi->numerator = 1;
-   if (fps > maxfps)
-   fi->denominator = maxfps;
-   else if (fps < minfps)
-   fi->denominator = minfps;
-   else if (2 * fps >= 2 * minfps + (maxfps - minfps))
-   fi->denominator = maxfps;
-   else
-   fi->denominator = minfps;
-
-   rate = (fi->denominator == minfps) ? OV5640_15_FPS : OV5640_30_FPS;
+   fi->denominator = best_fps;
 
mode = ov5640_find_mode(sensor, rate, width, height, false);
return mode ? rate : -EINVAL;
-- 
2.17.0

[PATCH v3 04/12] media: ov5640: Remove redundant defines

[Maxime Ripard]

The OV5640_SCLK2X_ROOT_DIVIDER_DEFAULT and OV5640_SCLK_ROOT_DIVIDER_DEFAULT
defines represent exactly the same setup, and are at the same value, than
the more consistent with the rest of the driver OV5640_SCLK2X_ROOT_DIV and
OV5640_SCLK_ROOT_DIV.

Remove them.

Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 45e5ba32b8d1..ce9bfaafb675 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -93,9 +93,6 @@
 #define OV5640_REG_SDE_CTRL5   0x5585
 #define OV5640_REG_AVG_READOUT 0x56a1
 
-#define OV5640_SCLK2X_ROOT_DIVIDER_DEFAULT 1
-#define OV5640_SCLK_ROOT_DIVIDER_DEFAULT   2
-
 enum ov5640_mode_id {
OV5640_MODE_QCIF_176_144 = 0,
OV5640_MODE_QVGA_320_240,
@@ -1961,8 +1958,8 @@ static int ov5640_restore_mode(struct ov5640_dev *sensor)
return ret;
 
ret = ov5640_mod_reg(sensor, OV5640_REG_SYS_ROOT_DIVIDER, 0x3f,
-(ilog2(OV5640_SCLK2X_ROOT_DIVIDER_DEFAULT) << 2) |
-ilog2(OV5640_SCLK_ROOT_DIVIDER_DEFAULT));
+(ilog2(OV5640_SCLK2X_ROOT_DIV) << 2) |
+ilog2(OV5640_SCLK_ROOT_DIV));
if (ret)
return ret;
 
-- 
2.17.0

Re: [PATCH v2 11/12] media: ov5640: Add 60 fps support

[Maxime Ripard]

Hi Hugues,

On Tue, May 15, 2018 at 01:33:55PM +, Hugues FRUCHET wrote:
> I've taken the whole serie and made some tests on STM32 platform using 
> DVP parallel interface.
> Now JPEG is OK and I've not seen any regressions appart on framerate 
> control linked to this current patchset.

Thanks a lot for your feedback, I've (hopefully) fixed all the issues
you reported here, most of the time taking your fix directly, except
for 2 where I reworked the code instead.

> Here are issues observed around framerate control:
> 1) Framerate enumeration is buggy and all resolutions are claimed 
> supporting 15/30/60:
> v4l2-ctl --list-formats-ext
> ioctl: VIDIOC_ENUM_FMT
>  Index   : 0
>  Type: Video Capture
>  Pixel Format: 'JPEG' (compressed)
>  Name: JFIF JPEG
>  Size: Discrete 176x144
>  Interval: Discrete 0.067s (15.000 fps)
>  Interval: Discrete 0.033s (30.000 fps)
>  Interval: Discrete 0.017s (60.000 fps)

One small question though, I don't seem to have that output for
v4l2-ctl, is some hook needed in the v4l2 device for it to work?

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH v2 00/12] media: ov5640: Misc cleanup and improvements

[Maxime Ripard]

Hi,

On Mon, May 07, 2018 at 06:00:55PM -0700, Sam Bobrowicz wrote:
> > Hi,
> >
> > Here is a "small" series that mostly cleans up the ov5640 driver code,
> > slowly getting rid of the big data array for more understandable code
> > (hopefully).
> >
> > The biggest addition would be the clock rate computation at runtime,
> > instead of relying on those arrays to setup the clock tree
> > properly. As a side effect, it fixes the framerate that was off by
> > around 10% on the smaller resolutions, and we now support 60fps.
> >
> > This also introduces a bunch of new features.
> >
> > Let me know what you think,
> > Maxime
> >
> > Changes from v1:
> >   - Integrated Hugues' suggestions to fix v4l2-compliance
> >   - Fixed the bus width with JPEG
> >   - Dropped the clock rate calculation loops for something simpler as
> > suggested by Sakari
> >   - Cache the exposure value instead of using the control value
> >   - Rebased on top of 4.17
> >
> > Maxime Ripard (10):
> >   media: ov5640: Don't force the auto exposure state at start time
> >   media: ov5640: Init properly the SCLK dividers
> >   media: ov5640: Change horizontal and vertical resolutions name
> >   media: ov5640: Add horizontal and vertical totals
> >   media: ov5640: Program the visible resolution
> >   media: ov5640: Adjust the clock based on the expected rate
> >   media: ov5640: Compute the clock rate at runtime
> >   media: ov5640: Enhance FPS handling
> >   media: ov5640: Add 60 fps support
> >   media: ov5640: Remove duplicate auto-exposure setup
> >
> > Mylène Josserand (2):
> >   media: ov5640: Add auto-focus feature
> >   media: ov5640: Add light frequency control
> >
> >  drivers/media/i2c/ov5640.c | 752 +
> >  1 file changed, 422 insertions(+), 330 deletions(-)
> >
> > --
> > 2.17.0
> >
> 
> As discussed, MIPI required some additional work. Please see the
> patches here which add support for MIPI:
> https://www.dropbox.com/s/73epty7808yzq1t/ov5640_mipi_fixes.zip?dl=0
> 
> The first 3 patches are fixes I believe should be made to earlier
> patches prior to submitting v2 of this series. The remaining 4 patches
> should probably just be added onto the end of this series as-is (or
> with feedback incorporated if needed).
> 
> I will note that this is still not working correctly on my system for
> any resolution that requires a 672 Mbps mipi rate. This includes
> 1080p@30hz, full@15hz, and 720p@60hz. My CSI2 receiver is reporting
> CRC errors though, so this could be an integrity issue on my module.
> I'm curious to hear if others have success at these resolutions.
> 
> Please try this out on other MIPI and DVP platforms with as many
> different resolutions as possible and let me know if it works.

I've took some of your changes to remain as feature stable as possible
in my series. Some other changes (like the PLL2 setup), while totally
welcome, should be in a separate, subsequent series.

DVP works as expected, after looking at the feedback from Loic (and
the clock tree especially), some of the comments you made (like the
bit divider being meaningless for DVP) are not totally accurate, so
I've tried to make the best blend of all the feedback you gave. It
still works properly with DVP, but I still don't have a MIPI camera to
test, so I'm not sure this works, even though I should have the same
setup than the one you reported.

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 3/6] media: rcar-vin: Handle data-active property

[Sergei Shtylyov]

Hello!

On 5/16/2018 7:32 PM, Jacopo Mondi wrote:


The data-active property has to be specified when running with embedded


   Prop names are typically enclosed in "".


synchronization. The VIN peripheral can use HSYNC in place of CLOCKENB


   CLKENB, maybe?


when the CLOCKENB pin is not connected, this requires explicit
synchronization to be in use.

Now that the driver supports 'data-active' property, it makes not sense


   "data-active", s/not/no/.


to zero the mbus configuration flags when running with implicit synch


   Sync is better. :-)


(V4L2_MBUS_BT656).

Signed-off-by: Jacopo Mondi 

[...]

MBR, Sergei

Re: [PATCH 4/6] media: rcar-vin: Handle CLOCKENB pin polarity

[jacopo mondi]

Hi Niklas,

On Thu, May 17, 2018 at 12:11:03AM +0200, Niklas Söderlund wrote:
> Hi Jacopo,
>
> Thanks for your patch.
>
> I'm happy that you dig into this as it clearly needs doing!
>
> On 2018-05-16 18:32:30 +0200, Jacopo Mondi wrote:
> > Handle CLOCKENB pin polarity, or use HSYNC in its place if polarity is
> > not specified.
> >
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  drivers/media/platform/rcar-vin/rcar-dma.c | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
> > b/drivers/media/platform/rcar-vin/rcar-dma.c
> > index ac07f99..7a84eae 100644
> > --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> > +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> > @@ -123,6 +123,8 @@
> >  /* Video n Data Mode Register 2 bits */
> >  #define VNDMR2_VPS (1 << 30)
> >  #define VNDMR2_HPS (1 << 29)
> > +#define VNDMR2_CES (1 << 28)
> > +#define VNDMR2_CHS (1 << 23)
> >  #define VNDMR2_FTEV(1 << 17)
> >  #define VNDMR2_VLV(n)  ((n & 0xf) << 12)
> >
> > @@ -691,6 +693,15 @@ static int rvin_setup(struct rvin_dev *vin)
> > dmr2 |= VNDMR2_VPS;
> >
> > /*
> > +* Clock-enable active level select.
> > +* Use HSYNC as enable if not specified
> > +*/
> > +   if (vin->mbus_cfg.flags & V4L2_MBUS_DATA_ACTIVE_LOW)
> > +   dmr2 |= VNDMR2_CES;
> > +   else if (!(vin->mbus_cfg.flags & V4L2_MBUS_DATA_ACTIVE_HIGH))
> > +   dmr2 |= VNDMR2_CHS;
>
> After studying the datasheet for a while I'm getting more and more
> convinced this should be (with context leftout in this patch context)
> something like this:
>
>   /* Hsync Signal Polarity Select */
>   if (!(vin->mbus_cfg.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
>   dmr2 |= VNDMR2_HPS;
>
>   /* Vsync Signal Polarity Select */
>   if (!(vin->mbus_cfg.flags & V4L2_MBUS_VSYNC_ACTIVE_LOW))
>   dmr2 |= VNDMR2_VPS;
>
>   /* Clock Enable Signal Polarity Select */
>   if (!(vin->mbus_cfg.flags & V4L2_MBUS_DATA_ACTIVE_LOW))
>   dmr2 |= VNDMR2_CES;

No, set CES if V4L2_MBUS_DATA_ACTIVE_LOW is specified, not the other
way around. See the CES bit description:

Clock Enable Signal Polarity Select
This bit specifies the polarity of the input clock enable signal in the 
ITU-
R BT.601.
0: Active high
1: Active low
>
>   /* Use HSYNC as clock enable if VIn_CLKENB is not available. */
>   if (!(vin->mbus_cfg.flags & (V4L2_MBUS_DATA_ACTIVE_LOW | 
> V4L2_MBUS_DATA_ACTIVE_HIGH)))
>   dmr2 |= VNDMR2_CHS;
>
> Or am I misunderstanding something?

Isn't that what my code is doing?

if (flags & LOW)
dmr2 |= CES;
else if (!(flags & HIGH)) // if we get here, LOW is not set too
dmr2 |= CHS;

Anyway, if you agree with my previous replies, we should set CHS only
when running with explicit syncs (V4L2_MBUS_PARALLEL).

Thanks
  j
>
> > +
> > +   /*
> >  * Output format
> >  */
> > switch (vin->format.pixelformat) {
> > --
> > 2.7.4
> >
>
> --
> Regards,
> Niklas Söderlund


signature.asc
Description: PGP signature

Re: [PATCH 3/6] media: rcar-vin: Handle data-active property

[jacopo mondi]

Hi Niklas,

On Wed, May 16, 2018 at 11:58:47PM +0200, Niklas Söderlund wrote:
> Hi Jacopo,
>
> Thanks for your work.
>
> On 2018-05-16 18:32:29 +0200, Jacopo Mondi wrote:
> > The data-active property has to be specified when running with embedded
> > synchronization. The VIN peripheral can use HSYNC in place of CLOCKENB
> > when the CLOCKENB pin is not connected, this requires explicit
> > synchronization to be in use.
>
> Is this really the intent of the data-active property? I read the
> video-interfaces.txt document as such as if no hsync-active,
> vsync-active and data-active we should use the embedded synchronization
> else set the polarity for the requested pins. What am I not
> understanding here?

Almost correct.

The presence of hsync-active, vsync-active and field-evev-active
properties determinate the bus type we're running on. If none of the
is specified, the bus is marked 'BT656' and we assume the system is
using embedded synchronization.

data-active does not take part in the bus identification, and my
reasoning was the other way around as explained in reply to your
comment on [2/6], and as explained there my reasoning is probably
wrong, and we should set CHS -only- when running with explicit
synchronization, instead of making it mandatory when running with
embedded syncs.

Thanks and sorry for my confusion.

j
>
> >
> > Now that the driver supports 'data-active' property, it makes not sense
> > to zero the mbus configuration flags when running with implicit synch
> > (V4L2_MBUS_BT656).
> >
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  drivers/media/platform/rcar-vin/rcar-core.c | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> > b/drivers/media/platform/rcar-vin/rcar-core.c
> > index d3072e1..075d08f 100644
> > --- a/drivers/media/platform/rcar-vin/rcar-core.c
> > +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> > @@ -531,15 +531,21 @@ static int rvin_digital_parse_v4l2(struct device *dev,
> > return -ENOTCONN;
> >
> > vin->mbus_cfg.type = vep->bus_type;
> > +   vin->mbus_cfg.flags = vep->bus.parallel.flags;
> >
> > switch (vin->mbus_cfg.type) {
> > case V4L2_MBUS_PARALLEL:
> > vin_dbg(vin, "Found PARALLEL media bus\n");
> > -   vin->mbus_cfg.flags = vep->bus.parallel.flags;
> > break;
> > case V4L2_MBUS_BT656:
> > vin_dbg(vin, "Found BT656 media bus\n");
> > -   vin->mbus_cfg.flags = 0;
> > +
> > +   if (!(vin->mbus_cfg.flags & V4L2_MBUS_DATA_ACTIVE_HIGH) &&
> > +   !(vin->mbus_cfg.flags & V4L2_MBUS_DATA_ACTIVE_LOW)) {
> > +   vin_err(vin,
> > +   "Missing data enable signal polarity 
> > property\n");
>
> I fear this can't be an error as that would break backward comp ability
> with existing dtb's.
>
> > +   return -EINVAL;
> > +   }
> > break;
> > default:
> > vin_err(vin, "Unknown media bus type\n");
> > --
> > 2.7.4
> >
>
> --
> Regards,
> Niklas Söderlund


signature.asc
Description: PGP signature