Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Christoph Hellwig]

On Tue, Apr 24, 2018 at 09:32:20PM +0200, Daniel Vetter wrote:
> Out of curiosity, how much virtual flushing stuff is there still out
> there? At least in drm we've pretty much ignore this, and seem to be
> getting away without a huge uproar (at least from driver developers
> and users, core folks are less amused about that).

As I've just been wading through the code, the following architectures
have non-coherent dma that flushes by virtual address for at least some
platforms:

 - arm [1], arm64, hexagon, nds32, nios2, parisc, sh, xtensa, mips,
   powerpc

These have non-coherent dma ops that flush by physical address:

 - arc, arm [1], c6x, m68k, microblaze, openrisc, sparc

And these do not have non-coherent dma ops at all:

 - alpha, h8300, riscv, unicore32, x86

[1] arm ѕeems to do both virtually and physically based ops, further
audit needed.

Note that using virtual addresses in the cache flushing interface
doesn't mean that the cache actually is virtually indexed, but it at
least allows for the possibility.

> > I think the most important thing about such a buffer object is that
> > it can distinguish the underlying mapping types.  While
> > dma_alloc_coherent, dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT,
> > dma_map_page/dma_map_single/dma_map_sg and dma_map_resource all give
> > back a dma_addr_t they are in now way interchangable.  And trying to
> > stuff them all into a structure like struct scatterlist that has
> > no indication what kind of mapping you are dealing with is just
> > asking for trouble.
> 
> Well the idea was to have 1 interface to allow all drivers to share
> buffers with anything else, no matter how exactly they're allocated.

Isn't that interface supposed to be dmabuf?  Currently dma_map leaks
a scatterlist through the sg_table in dma_buf_map_attachment /
->map_dma_buf, but looking at a few of the callers it seems like they
really do not even want a scatterlist to start with, but check that
is contains a physically contiguous range first.  So kicking the
scatterlist our there will probably improve the interface in general.

> dma-buf has all the functions for flushing, so you can have coherent
> mappings, non-coherent mappings and pretty much anything else. Or well
> could, because in practice people hack up layering violations until it
> works for the 2-3 drivers they care about. On top of that there's the
> small issue that x86 insists that dma is coherent (and that's true for
> most devices, including v4l drivers you might want to share stuff
> with), and gpus really, really really do want to make almost
> everything incoherent.

How do discrete GPUs manage to be incoherent when attached over PCIe?

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:   Wed Apr 25 05:00:10 CEST 2018
media-tree git hash:a2b2eff6ac2716f499defa590a6ec4ba379d765e
media_build git hash:   4fb7a3cc8d0f56c7cddc3b5b29e35aa1159bc8d9
v4l-utils git hash: 4b93ba494c108a1ab73c261bb22e25d72750b09d
gcc version:i686-linux-gcc (GCC) 7.3.0
sparse version: 0.5.2-RC1
smatch version: 0.5.1
host hardware:  x86_64
host os:4.15.0-2-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-arm64: OK
linux-git-i686: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
Check COMPILE_TEST: OK
linux-2.6.36.4-i686: 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: OK
linux-3.1.10-x86_64: OK
linux-3.2.101-i686: OK
linux-3.2.101-x86_64: OK
linux-3.3.8-i686: OK
linux-3.3.8-x86_64: OK
linux-3.4.113-i686: OK
linux-3.4.113-x86_64: OK
linux-3.5.7-i686: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-i686: OK
linux-3.6.11-x86_64: OK
linux-3.7.10-i686: OK
linux-3.7.10-x86_64: OK
linux-3.8.13-i686: OK
linux-3.8.13-x86_64: OK
linux-3.9.11-i686: OK
linux-3.9.11-x86_64: OK
linux-3.10.108-i686: WARNINGS
linux-3.10.108-x86_64: WARNINGS
linux-3.11.10-i686: OK
linux-3.11.10-x86_64: OK
linux-3.12.74-i686: OK
linux-3.12.74-x86_64: OK
linux-3.13.11-i686: OK
linux-3.13.11-x86_64: OK
linux-3.14.79-i686: OK
linux-3.14.79-x86_64: OK
linux-3.15.10-i686: OK
linux-3.15.10-x86_64: OK
linux-3.16.56-i686: OK
linux-3.16.56-x86_64: OK
linux-3.17.8-i686: OK
linux-3.17.8-x86_64: OK
linux-3.18.102-i686: OK
linux-3.18.102-x86_64: OK
linux-3.19.8-i686: OK
linux-3.19.8-x86_64: OK
linux-4.0.9-i686: OK
linux-4.0.9-x86_64: OK
linux-4.1.51-i686: OK
linux-4.1.51-x86_64: OK
linux-4.2.8-i686: OK
linux-4.2.8-x86_64: OK
linux-4.3.6-i686: OK
linux-4.3.6-x86_64: OK
linux-4.4.109-i686: OK
linux-4.4.109-x86_64: OK
linux-4.5.7-i686: OK
linux-4.5.7-x86_64: OK
linux-4.6.7-i686: OK
linux-4.6.7-x86_64: OK
linux-4.7.10-i686: OK
linux-4.7.10-x86_64: OK
linux-4.8.17-i686: OK
linux-4.8.17-x86_64: OK
linux-4.9.91-i686: OK
linux-4.9.91-x86_64: OK
linux-4.14.31-i686: OK
linux-4.14.31-x86_64: OK
linux-4.15.14-i686: OK
linux-4.15.14-x86_64: OK
linux-4.16-i686: OK
linux-4.16-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: OK

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

RE: [RESEND PATCH v7 1/2] media: dt-bindings: Add bindings for Dongwoon DW9807 voice coil

[Yeh, Andy]

Hi Rob,

Apologize missed your comment before sent out v8. I will definitely add 
acks/reviewed-bys in next version.

Regards, Andy

-Original Message-
From: Rob Herring [mailto:r...@kernel.org] 
Sent: Friday, April 13, 2018 11:11 PM
To: Yeh, Andy 
Cc: linux-media@vger.kernel.org; sakari.ai...@linux.intel.com; 
devicet...@vger.kernel.org; tf...@chromium.org; jac...@jmondi.org; Chiang, 
AlanX 
Subject: Re: [RESEND PATCH v7 1/2] media: dt-bindings: Add bindings for 
Dongwoon DW9807 voice coil

On Tue, Apr 10, 2018 at 11:48:43PM +0800, Andy Yeh wrote:
> From: Alan Chiang 
> 
> Dongwoon DW9807 is a voice coil lens driver.
> 
> Signed-off-by: Andy Yeh 
> ---
>  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

Please add acks/reviewed-bys when posting new versions.

Rob

RE: [RESEND PATCH v7 2/2] media: dw9807: Add dw9807 vcm driver

[Yeh, Andy]

Hi Jocopo, Tomasz,

Thanks for your comments.
Resend patches to https://patchwork.linuxtv.org/patch/49029/

Most of the comments are addressed. However some remain no change based on the 
discussion with Sakari and Tomasz. Posted as below.

>   if (MAX_RETRY == ++retry) {
>   dev_err(>dev,
>   "Cannot do the write operation because VCM is busy\n");

Jacopo:
Nit: this is over 80 cols, it's fine, but I think you can really
shorten the error messag without losing context.

Sakari:
dev_warn() or dev_info() might be more appropriate actually. Or even
dev_dbg(). This isn't a grave problem; just a sign the user space is trying
to move the lens before it has reached its previous target position.

Tomasz:
On the other hand, we print this only if we reach MAX_RETRY, which probably
means that the lens is stuck or some other unexpected failure.

Sakari:
MAX_RETRY is only ten, so I'd expect you could hit this if you're tring to
move the lens again very quickly. It usually takes several ms (but could
well be more than 10 ms) to reach the target position. This depends on the
lens and the driver, too, and I don't know the properties of this driver
(nor the lens).


> usleep_range(DW9807_CTRL_DELAY_US, DW9807_CTRL_DELAY_US + 10);

Jacopo:
mmm, I wonder if a sleep range of 10usecs is really a strict
requirement. Have a look at Documentation/timers/timers-howto.txt.
With such a small range you're likely fire some unrequired interrupt.

If I got this right, here you're just polling a register every
1msec-ish (usleep_range(1000, 1010)). I think you can enlarge the
range safely (maybe lowering the number of retries if you wish to) and
give more space to coalesce your wakeup with others.

What is a good range? Good question. How effective is this to have
your wakeup coalesced with others? I think this greatly depends on the
system you're running on and its load at this specific time. So I
would reply to both questions with "not sure", but I let you consider
if you could enlarge your range to say 1000-1500 usec at least.

Sakari:
If the user is trying to tell where to move the lens next, no time should
be wasted on waiting. It'd perhaps rather make sense to return an error
(-EBUSY): the user application (as well as the application developer) would
know about the attempt to move the lens too fast and could take an informed
decision on what to do next. This could include changing the target
position, waiting more or changing the program to adjust the 3A loop
behaviour.

Tomasz:
Actually, shouldn't we wait for the lens to finish moving after we set the
position? If we don't do it, we risk the userspace requesting a capture
with the lens still moving.

If "time wasted on waiting" is a concern here, userspace could as well just
have a separate thread for controlling the lens (as something that is
expected to take time due to physical limitations).

Sakari:
For that purpose I'd add a new control. The user process shouldn't wait in
the kernel for just the sake of this. In order to meaningfully control the
focussing process, the user space would have to know some properties of the
lens anyway, so this information would primarily be useful for checking
things are working out as expected.



Regards, Andy


-Original Message-
From: jacopo mondi [mailto:jac...@jmondi.org] 
Sent: Thursday, April 12, 2018 4:57 PM
To: Yeh, Andy 
Cc: linux-media@vger.kernel.org; sakari.ai...@linux.intel.com; 
devicet...@vger.kernel.org; tf...@chromium.org; Chiang, AlanX 

Subject: Re: [RESEND PATCH v7 2/2] media: dw9807: Add dw9807 vcm driver

HI Andy,
   thanks for addressing my comments on v6.
Some more questions below.

On Tue, Apr 10, 2018 at 11:48:44PM +0800, Andy Yeh wrote:
> 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: Andy Yeh 
> ---
> since v1:
> - changed author.
> since v2:
> - addressed outstanding comments.
> - enabled sequential write to update 2 registers in a single transaction.
> since v3:
> - addressed comments for v3.
> - Remove redundant codes and declare some variables as constant variable.
> - separate DT binding to another patch since v4:
> - sent patchset included DT binding with cover page since v6:
> - change the return code of i2c_check
> - fix long cols exceed 80 chars
> - remove #define DW9807_NAME since only used once
>
>  MAINTAINERS|   7 +
>  drivers/media/i2c/Kconfig  |  10 ++
>  drivers/media/i2c/Makefile |   1 +
>  drivers/media/i2c/dw9807.c | 335 
> +
>  4 files changed, 353 insertions(+)
>  create mode 100644 drivers/media/i2c/dw9807.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS index 845fc25..a339bb5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4385,6 

[RESEND PATCH v8 2/2] media: dw9807: Add dw9807 vcm driver

[Andy Yeh]

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: Andy Yeh 
---
since v1:
- changed author.
since v2:
- addressed outstanding comments.
- enabled sequential write to update 2 registers in a single transaction.
since v3:
- addressed comments for v3.
- Remove redundant codes and declare some variables as constant variable.
- separate DT binding to another patch
since v4:
- sent patchset included DT binding with cover page
since v6:
- change the return code of i2c_check
- fix long cols exceed 80 chars
- remove #define DW9807_NAME since only used once
since v7:
- Remove some redundant type cast
- Modify to meet the coding style
- Replace a while loop by readx_poll_timeout function
- Return the i2c error directly.

 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 845fc25..a339bb5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4385,6 +4385,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 cb5d7ff..fd01842 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -325,6 +325,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 548a9ef..1b62639 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -23,6 +23,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 000..28ede2b
--- /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) {
+  

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

[Andy Yeh]

From: Alan Chiang 

Dongwoon DW9807 is a voice coil lens driver.

Signed-off-by: Andy Yeh 
---
 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 000..0a1a860
--- /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.7.4

[RESEND PATCH v8 0/2] DW9807 DT binding and driver patches

[Andy Yeh]

Hi Sakari and Tomasz,

The two patches are the DT binding and driver for DW9807 VCM controller.

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

 .../bindings/media/i2c/dongwoon,dw9807.txt |   9 +
 MAINTAINERS|   7 +
 drivers/media/i2c/Kconfig  |  10 +
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/dw9807.c | 320 +
 5 files changed, 347 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
 create mode 100644 drivers/media/i2c/dw9807.c

-- 
2.7.4

[GIT FIXES FOR v4.17] UVC fixes

[Laurent Pinchart]

Hi Mauro,

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  


  
  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

  


  
are available in the Git repository at: 

  


  
  git://linuxtv.org/pinchartl/media.git uvc/fixes   

  


  
for you to fetch changes up to 3f22b63e8a488156467da43cdf9a3a7bd683f161:

  


  
  media: uvcvideo: Prevent setting unavailable flags (2018-04-25 03:16:42 
+0300)  



  


  
Kieran Bingham (1): 

  
  media: uvcvideo: Prevent setting unavailable flags

  


  
 drivers/media/usb/uvc/uvc_ctrl.c | 17 +

  
 1 file changed, 9 insertions(+), 8 deletions(-)

-- 
Regards,

Laurent Pinchart

Re: a 4.16 kernel with Debian 9.4 "stretch" causes a log explosion

[Laurent Pinchart]

Hi Guennadi,

On Wednesday, 11 April 2018 22:33:43 EEST Guennadi Liakhovetski wrote:
> On Wed, 11 Apr 2018, Kieran Bingham wrote:
> > On 11/04/18 18:06, Guennadi Liakhovetski wrote:
> >  
> >  
> > Just figured out this commit
> > 
> > From: Edgar Thier 
> > Date: Thu, 12 Oct 2017 03:54:17 -0400
> > Subject: [PATCH] media: uvcvideo: Apply flags from device to actual
> > properties
> > 
> > as the culprit. Without it everything is back to normal.
>  
>  I've already investigated and fixed this:
>  
>  Please apply:
>   https://patchwork.kernel.org/patch/10299735/
> >> 
> >> Great, thanks! That seems to fix my problem.
> > 
> > Fantastic. I'm glad it helped.
> > 
> >  - Can I call that a Tested-by: ? :-D
> 
> Now you officially can - I replied to the patch.

Thank you. I've picked the tag and sent a pull request to Mauro.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v3][RESEND] media: i2c: tda1997: replace codec to component

[Kuninori Morimoto]

Hi Tim, Mark

> >> Could you add some detail to the commit explaining why we need to
> >> replace codec to component? I don't really know what that means.
> >> Please refer to a commit if the ASoC API is changing in some way we
> >> need to catch up with.
> >
> > This is a big transition in the ASoC API which is nearing completion -
> > this driver is one of the last users of the CODEC struct, we've (well,
> > mainly Morimoto-san) been migrating things away from it to the more
> > general purpose component.  There's no one commit to point at really as
> > the two have coexisted for a while and we won't be able to finally
> > remove the CODEC struct until all the drivers have transitioned away.

Thank you Mark for explaining.

> Sorry this took so long to get to. Tested on a GW5404
> 
> Tested-by: Tim Harvey 
> Acked-by: Tim Harvey 

Thank you Tim.
And sorry that it couldn't explain detail things on log

[PATCH] rcar-vin: enable field toggle after a set number of lines for Gen3

[Niklas Söderlund]

The VIN Gen3 hardware don't have Line Post-Clip capabilities as VIN Gen2
hardware have. To protect against writing outside the capture window
enable field toggle after a set number of lines have been captured.

Capturing outside the allocated capture buffer where observed on R-Car
Gen3 Salvator-XS H3 from the CVBS input if the standard is
misconfigured. That is if a PAL source is connected to the system but
the adv748x standard is set to NTSC. In this case the format reported by
the adv748x is 720x480 and that is what is used for the media pipeline.
The PAL source generates frames in the format of 720x576 and the field
is not toggled until the VSYNC is detected and at that time data have
already been written outside the allocated capture buffer.

With this change the capture in the situation described above results in
garbage frames but that is far better then writing outside the capture
buffer.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index ac07f99e3516a620..b41ba9a4a2b3ac90 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -124,7 +124,9 @@
 #define VNDMR2_VPS (1 << 30)
 #define VNDMR2_HPS (1 << 29)
 #define VNDMR2_FTEV(1 << 17)
+#define VNDMR2_FTEH(1 << 16)
 #define VNDMR2_VLV(n)  ((n & 0xf) << 12)
+#define VNDMR2_HLV(n)  ((n) & 0xfff)
 
 /* Video n CSI2 Interface Mode Register (Gen3) */
 #define VNCSI_IFMD_DES1(1 << 26)
@@ -612,8 +614,9 @@ void rvin_crop_scale_comp(struct rvin_dev *vin)
 
 static int rvin_setup(struct rvin_dev *vin)
 {
-   u32 vnmc, dmr, dmr2, interrupts;
+   u32 vnmc, dmr, dmr2, interrupts, lines;
bool progressive = false, output_is_yuv = false, input_is_yuv = false;
+   bool halfsize = false;
 
switch (vin->format.field) {
case V4L2_FIELD_TOP:
@@ -628,12 +631,15 @@ static int rvin_setup(struct rvin_dev *vin)
/* Use BT if video standard can be read and is 60 Hz format */
if (!vin->info->use_mc && vin->std & V4L2_STD_525_60)
vnmc = VNMC_IM_FULL | VNMC_FOC;
+   halfsize = true;
break;
case V4L2_FIELD_INTERLACED_TB:
vnmc = VNMC_IM_FULL;
+   halfsize = true;
break;
case V4L2_FIELD_INTERLACED_BT:
vnmc = VNMC_IM_FULL | VNMC_FOC;
+   halfsize = true;
break;
case V4L2_FIELD_NONE:
vnmc = VNMC_IM_ODD_EVEN;
@@ -676,11 +682,15 @@ static int rvin_setup(struct rvin_dev *vin)
break;
}
 
-   /* Enable VSYNC Field Toogle mode after one VSYNC input */
-   if (vin->info->model == RCAR_GEN3)
-   dmr2 = VNDMR2_FTEV;
-   else
+   if (vin->info->model == RCAR_GEN3) {
+   /* Enable HSYNC Field Toggle mode after height HSYNC inputs. */
+   lines = vin->format.height / (halfsize ? 2 : 1);
+   dmr2 = VNDMR2_FTEH | VNDMR2_HLV(lines);
+   vin_dbg(vin, "Field Toogle after %u lines\n", lines);
+   } else {
+   /* Enable VSYNC Field Toogle mode after one VSYNC input. */
dmr2 = VNDMR2_FTEV | VNDMR2_VLV(1);
+   }
 
/* Hsync Signal Polarity Select */
if (!(vin->mbus_cfg.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
-- 
2.17.0

[PATCH] rcar-vin: add support for MEDIA_BUS_FMT_UYVY8_1X16

[Niklas Söderlund]

By setting VNMC_YCAL rcar-vin can support input video in
MEDIA_BUS_FMT_UYVY8_1X16 format.

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

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 55b745ac86a5884d..7bc2774a11232362 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -404,6 +404,7 @@ static int rvin_digital_subdevice_attach(struct rvin_dev 
*vin,
code.index++;
switch (code.code) {
case MEDIA_BUS_FMT_YUYV8_1X16:
+   case MEDIA_BUS_FMT_UYVY8_1X16:
case MEDIA_BUS_FMT_UYVY8_2X8:
case MEDIA_BUS_FMT_UYVY10_2X10:
case MEDIA_BUS_FMT_RGB888_1X24:
diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 4a3a195e7f59047c..ac07f99e3516a620 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -653,6 +653,10 @@ static int rvin_setup(struct rvin_dev *vin)
vnmc |= VNMC_INF_YUV16;
input_is_yuv = true;
break;
+   case MEDIA_BUS_FMT_UYVY8_1X16:
+   vnmc |= VNMC_INF_YUV16 | VNMC_YCAL;
+   input_is_yuv = true;
+   break;
case MEDIA_BUS_FMT_UYVY8_2X8:
/* BT.656 8bit YCbCr422 or BT.601 8bit YCbCr422 */
vnmc |= vin->mbus_cfg.type == V4L2_MBUS_BT656 ?
@@ -1009,6 +1013,7 @@ static int rvin_mc_validate_format(struct rvin_dev *vin, 
struct v4l2_subdev *sd,
 
switch (fmt.format.code) {
case MEDIA_BUS_FMT_YUYV8_1X16:
+   case MEDIA_BUS_FMT_UYVY8_1X16:
case MEDIA_BUS_FMT_UYVY8_2X8:
case MEDIA_BUS_FMT_UYVY10_2X10:
case MEDIA_BUS_FMT_RGB888_1X24:
-- 
2.17.0

[PATCH] rcar-vin: fix null pointer dereference in rvin_group_get()

[Niklas Söderlund]

Store the group pointer before disassociating the VIN from the group.

Fixes: 3bb4c3bc85bf77a7 ("media: rcar-vin: add group allocator functions")
Reported-by: Colin Ian King 
Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 7bc2774a11232362..d3072e166a1ca24f 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -338,19 +338,21 @@ static int rvin_group_get(struct rvin_dev *vin)
 
 static void rvin_group_put(struct rvin_dev *vin)
 {
-   mutex_lock(>group->lock);
+   struct rvin_group *group = vin->group;
+
+   mutex_lock(>lock);
 
vin->group = NULL;
vin->v4l2_dev.mdev = NULL;
 
-   if (WARN_ON(vin->group->vin[vin->id] != vin))
+   if (WARN_ON(group->vin[vin->id] != vin))
goto out;
 
-   vin->group->vin[vin->id] = NULL;
+   group->vin[vin->id] = NULL;
 out:
-   mutex_unlock(>group->lock);
+   mutex_unlock(>lock);
 
-   kref_put(>group->refcount, rvin_group_release);
+   kref_put(>refcount, rvin_group_release);
 }
 
 /* 
-
-- 
2.17.0

[PATCH] rcar-vin: remove generic gen3 compatible string

[Niklas Söderlund]

The compatible string "renesas,rcar-gen3-vin" was added before the
Gen3 driver code was added but it's not possible to use. Each SoC in the
Gen3 series require SoC specific knowledge in the driver to function.
Remove it before it is added to any device tree descriptions.

Signed-off-by: Niklas Söderlund 
---
 Documentation/devicetree/bindings/media/rcar_vin.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
b/Documentation/devicetree/bindings/media/rcar_vin.txt
index ba31431d4b1fbdbb..a19517e1c669eb35 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -24,7 +24,6 @@ on Gen3 platforms to a CSI-2 receiver.
- "renesas,vin-r8a77970" for the R8A77970 device
- "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
  device.
-   - "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
 
When compatible with the generic version nodes must list the
SoC-specific version corresponding to the platform first
-- 
2.17.0

Re: [PATCH] media: i2c: adv748x: Fix pixel rate values

[Niklas Söderlund]

Hi Laurent,

Thanks for your patch.

On 2018-04-21 15:44:44 +0300, Laurent Pinchart wrote:
> The pixel rate, as reported by the V4L2_CID_PIXEL_RATE control, must
> include both horizontal and vertical blanking. Both the AFE and HDMI
> receiver program it incorrectly:
> 
> - The HDMI receiver goes to the trouble of removing blanking to compute
> the rate of active pixels. This is easy to fix by removing the
> computation and returning the incoming pixel clock rate directly.
> 
> - The AFE performs similar calculation, while it should simply return
> the fixed pixel rate for analog sources, mandated by the ADV748x to be
> 28.63636 MHz.
> 
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Niklas Söderlund 

This patch uncovered a calculation error in rcar-csi2 which compensated 
for the removing of the blanking in the adv748x, thanks for that! Good 
thing that it's not merged yet, will include the fix in the next version 
of the CSI-2 driver.

> ---
>  drivers/media/i2c/adv748x/adv748x-afe.c  | 11 +--
>  drivers/media/i2c/adv748x/adv748x-hdmi.c |  8 +---
>  2 files changed, 6 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/media/i2c/adv748x/adv748x-afe.c 
> b/drivers/media/i2c/adv748x/adv748x-afe.c
> index 61514bae7e5c..3e18d5ae813b 100644
> --- a/drivers/media/i2c/adv748x/adv748x-afe.c
> +++ b/drivers/media/i2c/adv748x/adv748x-afe.c
> @@ -321,17 +321,16 @@ static const struct v4l2_subdev_video_ops 
> adv748x_afe_video_ops = {
>  static int adv748x_afe_propagate_pixelrate(struct adv748x_afe *afe)
>  {
>   struct v4l2_subdev *tx;
> - unsigned int width, height, fps;
>  
>   tx = adv748x_get_remote_sd(>pads[ADV748X_AFE_SOURCE]);
>   if (!tx)
>   return -ENOLINK;
>  
> - width = 720;
> - height = afe->curr_norm & V4L2_STD_525_60 ? 480 : 576;
> - fps = afe->curr_norm & V4L2_STD_525_60 ? 30 : 25;
> -
> - return adv748x_csi2_set_pixelrate(tx, width * height * fps);
> + /*
> +  * The ADV748x samples analog video signals using an externally supplied
> +  * clock whose frequency is required to be 28.63636 MHz.
> +  */
> + return adv748x_csi2_set_pixelrate(tx, 28636360);
>  }
>  
>  static int adv748x_afe_enum_mbus_code(struct v4l2_subdev *sd,
> diff --git a/drivers/media/i2c/adv748x/adv748x-hdmi.c 
> b/drivers/media/i2c/adv748x/adv748x-hdmi.c
> index 10d229a4f088..aecc2a84dfec 100644
> --- a/drivers/media/i2c/adv748x/adv748x-hdmi.c
> +++ b/drivers/media/i2c/adv748x/adv748x-hdmi.c
> @@ -402,8 +402,6 @@ static int adv748x_hdmi_propagate_pixelrate(struct 
> adv748x_hdmi *hdmi)
>  {
>   struct v4l2_subdev *tx;
>   struct v4l2_dv_timings timings;
> - struct v4l2_bt_timings *bt = 
> - unsigned int fps;
>  
>   tx = adv748x_get_remote_sd(>pads[ADV748X_HDMI_SOURCE]);
>   if (!tx)
> @@ -411,11 +409,7 @@ static int adv748x_hdmi_propagate_pixelrate(struct 
> adv748x_hdmi *hdmi)
>  
>   adv748x_hdmi_query_dv_timings(>sd, );
>  
> - fps = DIV_ROUND_CLOSEST_ULL(bt->pixelclock,
> - V4L2_DV_BT_FRAME_WIDTH(bt) *
> - V4L2_DV_BT_FRAME_HEIGHT(bt));
> -
> - return adv748x_csi2_set_pixelrate(tx, bt->width * bt->height * fps);
> + return adv748x_csi2_set_pixelrate(tx, timings.bt.pixelclock);
>  }
>  
>  static int adv748x_hdmi_enum_mbus_code(struct v4l2_subdev *sd,
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
Regards,
Niklas Söderlund

[PATCH] cx88: Get rid of spurious call to cx8800_start_vbi_dma()

[Devin Heitmueller]

This was left over from the conversion to VB2, where the call was
getting invoked both in buffer_queue and start_streaming, which
was intermittently causing invalid opcodes on the VBI RISC queue.

This change effectively mirrors the exact same change Hans Verkuil
made in cx88-video.c in 389208e1173e097590856ed24a505551510f78d4.

Thanks to Daniel Glöckner for spotting the actual bug after I spent
several days trying to chase down the issue.

Signed-off-by: Devin Heitmueller 
Thanks-to: Daniel Glöckner 
Cc: Hans Verkuil 
---
 drivers/media/pci/cx88/cx88-vbi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/pci/cx88/cx88-vbi.c 
b/drivers/media/pci/cx88/cx88-vbi.c
index c637679..58489ea 100644
--- a/drivers/media/pci/cx88/cx88-vbi.c
+++ b/drivers/media/pci/cx88/cx88-vbi.c
@@ -178,7 +178,6 @@ static void buffer_queue(struct vb2_buffer *vb)
 
if (list_empty(>active)) {
list_add_tail(>list, >active);
-   cx8800_start_vbi_dma(dev, q, buf);
dprintk(2, "[%p/%d] vbi_queue - first active\n",
buf, buf->vb.vb2_buf.index);
 
-- 
1.9.1

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

[Sam Bobrowicz]

FYI, still hard at work on this. Did some more experiments last week
that seemed to corroborate the clock tree in the spreadsheet. It also
seems that the output of the P divider cell, SCLK cell and MIPI Rate
cell in the spreadsheet must have a ratio of 2x:1x:8x (respectively)
in order for the sensor to work properly on my platform, and that the
SCLK value must be close to the "rate" variable that you calculate and
pass to set_mipi_pclk. Unfortunately, I've only got the sensor working
well for 1080p@15Hz and 720p@30Hz, both with a SCLK of 42MHz (aka
84:42:336). I'm running experiments now trying to adjust the htot and
vtot values to create different required rates, and also to try to get
faster Mipi rates working. Any information you have on the
requirements of the htot and vtot values with respect to vact and hact
values would likely be helpful.

I'm also keeping an eye on the scaler clock, which I think may be
affecting certain resolutions, but haven't been able to see it make a
difference yet (see register 0x3824 and 0x460c)

I plan on pushing a set of patches once I get this figured out, we can
discuss what I should base them on when I get closer to that point.
I'm new to this process :)

--Sam
---
Sam Bobrowicz
Elite Embedded Consulting LLC
elite-embedded.com


On Thu, Apr 19, 2018 at 5:32 AM, Maxime Ripard
 wrote:
> Hi Samuel,
>
> On Wed, Apr 18, 2018 at 04:39:06PM -0700, Samuel Bobrowicz wrote:
>> I applied your patches, and they are a big improvement for what I am
>> trying to do, but things still aren't working right on my platform.
>>
>> How confident are you that the MIPI mode will work with this version
>> of the driver?
>
> Not too confident. Like I said, I did all my tests on a parallel
> camera with a scope, so I'm pretty confident for the parallel bus. But
> I haven't been able to test the MIPI-CSI side of things and tried to
> deduce it from the datasheet.
>
> tl; dr: I might very well be wrong.
>
>> I am having issues that I believe are due to incorrect clock
>> generation. Our engineers did some reverse engineering of the clock
>> tree themselves, and came up with a slightly different model.  I've
>> captured their model in a spreadsheet here:
>> https://tinyurl.com/pll-calc . Just modify the register and xclk
>> values to see the clocks change. Do your tests disagree with this
>> potential model?
>
> At least on the parallel side, it looks fairly similar, so I guess we
> can come to an agreement :)
>
> There's just the SCLK2x divider that is no longer in the path to PCLK
> but has been replaced with BIT Divider that has the same value, so it
> should work as well.
>
>> I'm not sure which model is more correct, but my tests suggest the
>> high speed MIPI clock is generated directly off the PLL. This means
>> the PLL multiplier you are generating in your algorithm is not high
>> enough to satisfy the bandwidth. If this is the case, MIPI mode will
>> require a different set of parameters that enable some of the
>> downstream dividers, so that the PLL multiplier can be higher while
>> the PCLK value still matches the needed rate calculated from the
>> resolution.
>>
>> Any thoughts on this before I dive in and start tweaking the algorithm
>> in mipi mode?
>
> Like I said, I did that analysis by plugging the camera to a scope and
> look at the PCLK generated for various combinations. Your analysis
> seems not too far off for the setup I've tested, so I guess this makes
> sense. And let me know how it works for MIPI-CSI2 so that I can update
> the patches :)
>
> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com

[PATCH] media: zoran: move to dma-mapping interface

[Arnd Bergmann]

No drivers should use virt_to_bus() any more. This converts
one of the few remaining ones to the DMA mapping interface.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/pci/zoran/Kconfig|  2 +-
 drivers/media/pci/zoran/zoran.h| 10 +--
 drivers/media/pci/zoran/zoran_card.c   | 10 +--
 drivers/media/pci/zoran/zoran_device.c | 16 +-
 drivers/media/pci/zoran/zoran_driver.c | 54 +-
 5 files changed, 63 insertions(+), 29 deletions(-)

diff --git a/drivers/media/pci/zoran/Kconfig b/drivers/media/pci/zoran/Kconfig
index 39ec35bd21a5..26f40e124a32 100644
--- a/drivers/media/pci/zoran/Kconfig
+++ b/drivers/media/pci/zoran/Kconfig
@@ -1,6 +1,6 @@
 config VIDEO_ZORAN
tristate "Zoran ZR36057/36067 Video For Linux"
-   depends on PCI && I2C_ALGOBIT && VIDEO_V4L2 && VIRT_TO_BUS
+   depends on PCI && I2C_ALGOBIT && VIDEO_V4L2
depends on !ALPHA
help
  Say Y for support for MJPEG capture cards based on the Zoran
diff --git a/drivers/media/pci/zoran/zoran.h b/drivers/media/pci/zoran/zoran.h
index 9bb3c21aa275..9ff3a9acb60a 100644
--- a/drivers/media/pci/zoran/zoran.h
+++ b/drivers/media/pci/zoran/zoran.h
@@ -183,13 +183,14 @@ struct zoran_buffer {
struct zoran_sync bs;   /* DONE: info to return to application 
*/
union {
struct {
-   __le32 *frag_tab;   /* addresses of frag table */
-   u32 frag_tab_bus;   /* same value cached to save 
time in ISR */
+   __le32 *frag_tab;   /* DMA addresses of frag table 
*/
+   void **frag_virt_tab;   /* virtual addresses of frag 
table */
+   dma_addr_t frag_tab_dma;/* same value cached to save 
time in ISR */
} jpg;
struct {
char *fbuffer;  /* virtual address of frame 
buffer */
unsigned long fbuffer_phys;/* physical address of frame 
buffer */
-   unsigned long fbuffer_bus;/* bus address of frame 
buffer */
+   dma_addr_t fbuffer_dma;/* bus address of frame buffer */
} v4l;
};
 };
@@ -221,6 +222,7 @@ struct zoran_fh {
 
struct zoran_overlay_settings overlay_settings;
u32 *overlay_mask;  /* overlay mask */
+   dma_addr_t overlay_mask_dma;
enum zoran_lock_activity overlay_active;/* feature currently in use? */
 
struct zoran_buffer_col buffers;/* buffers' info */
@@ -307,6 +309,7 @@ struct zoran {
 
struct zoran_overlay_settings overlay_settings;
u32 *overlay_mask;  /* overlay mask */
+   dma_addr_t overlay_mask_dma;
enum zoran_lock_activity overlay_active;/* feature currently in 
use? */
 
wait_queue_head_t v4l_capq;
@@ -346,6 +349,7 @@ struct zoran {
 
/* zr36057's code buffer table */
__le32 *stat_com;   /* stat_com[i] is indexed by 
dma_head/tail & BUZ_MASK_STAT_COM */
+   dma_addr_t stat_com_dma;
 
/* (value & BUZ_MASK_FRAME) corresponds to index in pend[] queue */
int jpg_pend[BUZ_MAX_FRAME];
diff --git a/drivers/media/pci/zoran/zoran_card.c 
b/drivers/media/pci/zoran/zoran_card.c
index a6b9ebd20263..dabd8bf77472 100644
--- a/drivers/media/pci/zoran/zoran_card.c
+++ b/drivers/media/pci/zoran/zoran_card.c
@@ -890,6 +890,7 @@ zoran_open_init_params (struct zoran *zr)
/* User must explicitly set a window */
zr->overlay_settings.is_set = 0;
zr->overlay_mask = NULL;
+   zr->overlay_mask_dma = 0;
zr->overlay_active = ZORAN_FREE;
 
zr->v4l_memgrab_active = 0;
@@ -1028,7 +1029,8 @@ static int zr36057_init (struct zoran *zr)
 
/* allocate memory *before* doing anything to the hardware
 * in case allocation fails */
-   zr->stat_com = kzalloc(BUZ_NUM_STAT_COM * 4, GFP_KERNEL);
+   zr->stat_com = dma_alloc_coherent(>pci_dev->dev,
+   BUZ_NUM_STAT_COM * 4, >stat_com_dma, 
GFP_KERNEL);
zr->video_dev = video_device_alloc();
if (!zr->stat_com || !zr->video_dev) {
dprintk(1,
@@ -1072,7 +1074,8 @@ static int zr36057_init (struct zoran *zr)
return 0;
 
 exit_free:
-   kfree(zr->stat_com);
+   dma_free_coherent(>pci_dev->dev, BUZ_NUM_STAT_COM * 4,
+ zr->stat_com, zr->stat_com_dma);
kfree(zr->video_dev);
return err;
 }
@@ -1107,7 +1110,8 @@ static void zoran_remove(struct pci_dev *pdev)
btwrite(0, ZR36057_SPGPPCR);
free_irq(zr->pci_dev->irq, zr);
/* unmap and free memory */
-   kfree(zr->stat_com);
+   dma_free_coherent(>pci_dev->dev, BUZ_NUM_STAT_COM * 4,
+ zr->stat_com, zr->stat_com_dma);
zoran_proc_cleanup(zr);
iounmap(zr->zr36057_mem);

Re: [PATCH v2 08/12] media: ov5640: Adjust the clock based on the expected rate

[Maxime Ripard]

Hi Sakari,

On Tue, Apr 24, 2018 at 10:21:47AM +0300, Sakari Ailus wrote:
> >  /* download ov5640 settings to sensor through i2c */
> >  static int ov5640_load_regs(struct ov5640_dev *sensor,
> > const struct ov5640_mode_info *mode)
> > @@ -1620,6 +1830,14 @@ static int ov5640_set_mode(struct ov5640_dev *sensor,
> > if (ret)
> > return ret;
> >  
> > +   if (sensor->ep.bus_type == V4L2_MBUS_CSI2)
> > +   ret = ov5640_set_mipi_pclk(sensor, mode->clock);
> 
> What is the value of the mode->clock expected to signify? It'd seem like
> that this changes from this patch to the next. Which one is correct?

It doesn't, this is the clock rate computed through the formula
described above (and that might be incorrect for MIPI-CSI, given
Samuel feedback) from the way the registers are initialized in the
arrays.

This shouldn't bring any change to the clock rate, but instead of
hardcoding it, we now have the infrastructure to calculate the factors
for any given rate.

The subsequent patch will remove that hardcoded clock rate and
generate it dynamically from the timings / format.

Does that make sense? Or maybe I should split this some other way?

> Please also add a comment or two documenting this; it'll be otherwise
> difficult to find out later on.

I'm not sure there's a point in documenting that intermediate step
that is just there for a single commit. Maybe I should expand the
commit log to make it clearer?

Maxime

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

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Daniel Vetter]

On Tue, Apr 24, 2018 at 8:48 PM, Christoph Hellwig  wrote:
> On Fri, Apr 20, 2018 at 05:21:11PM +0200, Daniel Vetter wrote:
>> > At the very lowest level they will need to be handled differently for
>> > many architectures, the questions is at what point we'll do the
>> > branching out.
>>
>> Having at least struct page also in that list with (dma_addr_t, lenght)
>> pairs has a bunch of benefits for drivers in unifying buffer handling
>> code. You just pass that one single list around, use the dma_addr_t side
>> for gpu access (generally bashing it into gpu ptes). And the struct page
>> (if present) for cpu access, using kmap or vm_insert_*. We generally
>> ignore virt, if we do need a full mapping then we construct a vmap for
>> that buffer of our own.
>
> Well, for mapping a resource (which gets back to the start of the
> discussion) you will need an explicit virt pointer.  You also need
> an explicit virt pointer and not just page_address/kmap for users of
> dma_get_sgtable, because for many architectures you will need to flush
> the virtual address used to access the data, which might be a
> vmap/ioremap style mapping retourned from dma_alloc_address, and not
> the directly mapped kernel address.

Out of curiosity, how much virtual flushing stuff is there still out
there? At least in drm we've pretty much ignore this, and seem to be
getting away without a huge uproar (at least from driver developers
and users, core folks are less amused about that).

And at least for gpus that seems to have been the case since forever,
or at least since AGP was a thing 20 years ago: AGP isn't coherent, so
needs explicit cache flushing, and we have our own implementations of
that in drivers/char/agp. Luckily AGP died 10 years ago, so no one yet
proposed to port it all over to the iommu framework and hide it behind
the dma api (which really would be the "clean" way to do this, AGP is
simply an IOMMU + special socket dedicated for the add-on gpu).

> Here is another idea at the low-level dma API level:
>
>  - dma_get_sgtable goes away.  The replacement is a new
>dma_alloc_remap helper that takes the virtual address returned
>from dma_alloc_attrs/coherent and creates a dma_addr_t for the
>given new device.  If the original allocation was a coherent
>one no cache flushing is required either (because the arch
>made sure it is coherent), if the original allocation used
>DMA_ATTR_NON_CONSISTENT the new allocation will need
>dma_cache_sync calls as well.

Yeah I think that should work. dma_get_sgtable is a pretty nasty
layering violation.

>  - you never even try to share a mapping retourned from
>dma_map_resource - instead each device using it creates a new
>mapping, which makes sense as no virtual addresses are involved
>at all.

Yeah the dma-buf exporter always knows what kind of backing storage it
is dealing with, and for which struct device it should set up a new
view. Hence can make sure that it calls the right functions to
establish a new mapping, whether that's dma_map_sg, dma_map_resource
or the new dma_alloc_remap (instead of the dma_get_sgtable layering
mixup). The importer doesn't know.

>> So maybe a list of (struct page *, dma_addr_t, num_pages) would suit best,
>> with struct page * being optional (if it's a resource, or something else
>> that the kernel core mm isn't aware of). But that only has benefits if we
>> really roll it out everywhere, in all the subsystems and drivers, since if
>> we don't we've made the struct pages ** <-> sgt conversion fun only worse
>> by adding a 3 representation of gpu buffer object backing storage.
>
> I think the most important thing about such a buffer object is that
> it can distinguish the underlying mapping types.  While
> dma_alloc_coherent, dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT,
> dma_map_page/dma_map_single/dma_map_sg and dma_map_resource all give
> back a dma_addr_t they are in now way interchangable.  And trying to
> stuff them all into a structure like struct scatterlist that has
> no indication what kind of mapping you are dealing with is just
> asking for trouble.

Well the idea was to have 1 interface to allow all drivers to share
buffers with anything else, no matter how exactly they're allocated.
dma-buf has all the functions for flushing, so you can have coherent
mappings, non-coherent mappings and pretty much anything else. Or well
could, because in practice people hack up layering violations until it
works for the 2-3 drivers they care about. On top of that there's the
small issue that x86 insists that dma is coherent (and that's true for
most devices, including v4l drivers you might want to share stuff
with), and gpus really, really really do want to make almost
everything incoherent.

The end result is pretty epic :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Christoph Hellwig]

On Fri, Apr 20, 2018 at 05:21:11PM +0200, Daniel Vetter wrote:
> > At the very lowest level they will need to be handled differently for
> > many architectures, the questions is at what point we'll do the
> > branching out.
> 
> Having at least struct page also in that list with (dma_addr_t, lenght)
> pairs has a bunch of benefits for drivers in unifying buffer handling
> code. You just pass that one single list around, use the dma_addr_t side
> for gpu access (generally bashing it into gpu ptes). And the struct page
> (if present) for cpu access, using kmap or vm_insert_*. We generally
> ignore virt, if we do need a full mapping then we construct a vmap for
> that buffer of our own.

Well, for mapping a resource (which gets back to the start of the
discussion) you will need an explicit virt pointer.  You also need
an explicit virt pointer and not just page_address/kmap for users of
dma_get_sgtable, because for many architectures you will need to flush
the virtual address used to access the data, which might be a
vmap/ioremap style mapping retourned from dma_alloc_address, and not
the directly mapped kernel address.

Here is another idea at the low-level dma API level:

 - dma_get_sgtable goes away.  The replacement is a new
   dma_alloc_remap helper that takes the virtual address returned
   from dma_alloc_attrs/coherent and creates a dma_addr_t for the
   given new device.  If the original allocation was a coherent
   one no cache flushing is required either (because the arch
   made sure it is coherent), if the original allocation used
   DMA_ATTR_NON_CONSISTENT the new allocation will need
   dma_cache_sync calls as well.
 - you never even try to share a mapping retourned from
   dma_map_resource - instead each device using it creates a new
   mapping, which makes sense as no virtual addresses are involved
   at all.

> So maybe a list of (struct page *, dma_addr_t, num_pages) would suit best,
> with struct page * being optional (if it's a resource, or something else
> that the kernel core mm isn't aware of). But that only has benefits if we
> really roll it out everywhere, in all the subsystems and drivers, since if
> we don't we've made the struct pages ** <-> sgt conversion fun only worse
> by adding a 3 representation of gpu buffer object backing storage.

I think the most important thing about such a buffer object is that
it can distinguish the underlying mapping types.  While
dma_alloc_coherent, dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT,
dma_map_page/dma_map_single/dma_map_sg and dma_map_resource all give
back a dma_addr_t they are in now way interchangable.  And trying to
stuff them all into a structure like struct scatterlist that has
no indication what kind of mapping you are dealing with is just
asking for trouble.

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

[Peter Zijlstra]

On Tue, Apr 24, 2018 at 02:47:55PM -0300, Mauro Carvalho Chehab wrote:
> So, I'm wondering if are there any way to mitigate it inside the 
> core itself, instead of doing it on every driver, e. g. changing
> v4l_enum_fmt() implementation at v4l2-ioctl.
> 
> Ok, a "poor man" approach would be to pass the array directly to
> the core and let the implementation there to implement the array
> fetch logic, calling array_index_nospec() there, but I wonder if
> are there any other way that won't require too much code churn.

Sadly no; the whole crux is the array bound check itself. You could
maybe pass around the array size to the core code and then do something
like:

if (f->index >= f->array_size)
return -EINVAL;

f->index = nospec_array_index(f->index, f->array_size);

in generic code, and have all the drivers use f->index as usual, but
even that would be quite a bit of code churn I guess.

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

[Mauro Carvalho Chehab]

Em Tue, 24 Apr 2018 12:36:09 +0200
Peter Zijlstra  escreveu:

> On Tue, Apr 24, 2018 at 12:35:00PM +0300, Dan Carpenter wrote:
> > On Mon, Apr 23, 2018 at 03:24:55PM -0300, Mauro Carvalho Chehab wrote:  
> > > Em Mon, 23 Apr 2018 12:38:03 -0500
> > > "Gustavo A. R. Silva"  escreveu:  
> 
> > > > @@ -875,6 +876,7 @@ static int vidioc_enum_fmt_vid_cap(struct file 
> > > > *file, void  *priv,
> > > > if (f->index >= ARRAY_SIZE(format))
> > > > return -EINVAL;
> > > >  
> > > > +   f->index = array_index_nospec(f->index, ARRAY_SIZE(format));  
> > >
> > > Please enlighten me: how do you think this could be exploited?  
> 
> TL;DR: read the papers [1] & [2]
> 
> I suspect you didn't get the gist of Spectre V1 [1], let me explain:
> 
> Suppose userspace provides f->index > ARRAY_SIZE(format), and we predict
> the branch to -EINVAL to not be taken.
> 
> Then the CPU _WILL_ load (out of bounds) format[f->index] into
> f->pixelformat and continue onwards to use this bogus value, all the way
> until it figures out the branch was mis-predicted.
> 
> Once it figures out the mispredict, it will throw away the state and
> start over at the condition site. So far, so basic.
> 
> The thing is, is will not (and cannot) throw away all state. Suppose our
> speculation continues into v4l_fill_fmtdesc() and that switch there is
> compiled as another array lookup, it will then feed our f->pixelformat
> (which contains random kernel memory) into that array to find the
> requested descr pointer.
> 
> Now, imagine userspace having flushed cache on the descr pointer array,
> having trained the branch predictor to mis-predict the branch (see
> branchscope paper [2]) and doing that out-of-bounds ioctl().
> 
> It can then speculative do the out-of-bounds array access, followed by
> the desc array load, then figure out it was wrong and redo.
> 
> Then usespace probes which part of the descr[] array is now in cache and
> from that it can infer the initial out-of-bound value.
> 
> So while format[] is static and bound, it can read random kernel memory
> up to format+4g, including your crypto keys.
> 
> As far as V1 goes, this is actually a fairly solid exploit candidate. No
> false positive about it.
> 
> Now kernel policy is to kill any and all speculation on user controlled
> array indexing such that we don't have to go look for subsequent side
> channels (the above cache side channel is the one described in the
> Spectre paper and by far the easiest, but there are other possible side
> channels) and we simply don't want to worry about it.
> 
> So even from that pov, the proposed patch is good.
> 
> 
> [1] https://spectreattack.com/spectre.pdf
> [2] www.cs.ucr.edu/~nael/pubs/asplos18.pdf

> On Tue, Apr 24, 2018 at 12:36:09PM +0200, Peter Zijlstra wrote:
> > 
> > Then usespace probes which part of the descr[] array is now in cache and
> > from that it can infer the initial out-of-bound value.  
> 
> Just had a better look at v4l_fill_fmtdesc() and actually read the
> comment. The code cannot be compiled as a array because it is big and
> sparse. But the log(n) condition tree is a prime candidate for the
> branchscope side-channel, which would be able to reconstruct a
> significant number of bits of the original value. A denser tree gives
> more bits etc.

Peter,

Thanks for a comprehensive explanation about that. It now makes more
sense to me.

Yeah, better to apply a fix to avoid the issue with VIDIOC_ENUM_FMT. 

Btw, on almost all media drivers, the implementation for enumerating
the supported formats are the same (and we have a few other VIDOC_ENUM_foo
ioctls that usually do similar stuff): the V4L2 core calls a driver,
with looks into an array, returning the results to the core.

So, a fix like that should likely go to almost all media drivers
(there are a lot of them!), and, for every new one, to take care
to avoid introducing it again during patch review process.

So, I'm wondering if are there any way to mitigate it inside the 
core itself, instead of doing it on every driver, e. g. changing
v4l_enum_fmt() implementation at v4l2-ioctl.

Ok, a "poor man" approach would be to pass the array directly to
the core and let the implementation there to implement the array
fetch logic, calling array_index_nospec() there, but I wonder if
are there any other way that won't require too much code churn.


Thanks,
Mauro

Re: [PATCH v2 09/13] media: imx274: get rid of mode_index

[kbuild test robot]

Hi Luca,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.17-rc2 next-20180424]
[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/Luca-Ceresoli/media-imx274-cleanups-improvements-and-SELECTION-API-support/20180424-220137
base:   git://linuxtv.org/media_tree.git master
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-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=sparc64 

All warnings (new ones prefixed by >>):

   In file included from include/linux/printk.h:332:0,
from include/linux/kernel.h:14,
from include/linux/clk.h:16,
from drivers/media//i2c/imx274.c:22:
   drivers/media//i2c/imx274.c: In function 'imx274_s_stream':
>> drivers/media//i2c/imx274.c:1027:32: warning: format '%d' expects argument 
>> of type 'int', but argument 6 has type 'long int' [-Wformat=]
 dev_dbg(>client->dev, "%s : %s, mode index = %d\n", __func__,
   ^
   drivers/media//i2c/imx274.c:1029:3:
  imx274->mode - _formats[0]);
  ~
   include/linux/dynamic_debug.h:135:39: note: in definition of macro 
'dynamic_dev_dbg'
  __dynamic_dev_dbg(, dev, fmt, \
  ^~~
   drivers/media//i2c/imx274.c:1027:2: note: in expansion of macro 'dev_dbg'
 dev_dbg(>client->dev, "%s : %s, mode index = %d\n", __func__,
 ^~~

vim +1027 drivers/media//i2c/imx274.c

0985dd30 Leon Luo  2017-10-05  1011  
0985dd30 Leon Luo  2017-10-05  1012  /**
0985dd30 Leon Luo  2017-10-05  1013   * imx274_s_stream - It is used to 
start/stop the streaming.
0985dd30 Leon Luo  2017-10-05  1014   * @sd: V4L2 Sub device
0985dd30 Leon Luo  2017-10-05  1015   * @on: Flag (True / False)
0985dd30 Leon Luo  2017-10-05  1016   *
0985dd30 Leon Luo  2017-10-05  1017   * This function controls the start or 
stop of streaming for the
0985dd30 Leon Luo  2017-10-05  1018   * imx274 sensor.
0985dd30 Leon Luo  2017-10-05  1019   *
0985dd30 Leon Luo  2017-10-05  1020   * Return: 0 on success, errors 
otherwise
0985dd30 Leon Luo  2017-10-05  1021   */
0985dd30 Leon Luo  2017-10-05  1022  static int imx274_s_stream(struct 
v4l2_subdev *sd, int on)
0985dd30 Leon Luo  2017-10-05  1023  {
0985dd30 Leon Luo  2017-10-05  1024 struct stimx274 *imx274 = 
to_imx274(sd);
0985dd30 Leon Luo  2017-10-05  1025 int ret = 0;
0985dd30 Leon Luo  2017-10-05  1026  
0985dd30 Leon Luo  2017-10-05 @1027 dev_dbg(>client->dev, 
"%s : %s, mode index = %d\n", __func__,
f5180bf1 Luca Ceresoli 2018-04-24  1028 on ? "Stream Start" : 
"Stream Stop",
f5180bf1 Luca Ceresoli 2018-04-24  1029 imx274->mode - 
_formats[0]);
0985dd30 Leon Luo  2017-10-05  1030  
0985dd30 Leon Luo  2017-10-05  1031 mutex_lock(>lock);
0985dd30 Leon Luo  2017-10-05  1032  
0985dd30 Leon Luo  2017-10-05  1033 if (on) {
0985dd30 Leon Luo  2017-10-05  1034 /* load mode registers 
*/
da5bbae7 Luca Ceresoli 2018-04-24  1035 ret = 
imx274_mode_regs(imx274);
0985dd30 Leon Luo  2017-10-05  1036 if (ret)
0985dd30 Leon Luo  2017-10-05  1037 goto fail;
0985dd30 Leon Luo  2017-10-05  1038  
0985dd30 Leon Luo  2017-10-05  1039 /*
0985dd30 Leon Luo  2017-10-05  1040  * update frame rate & 
expsoure. if the last mode is different,
0985dd30 Leon Luo  2017-10-05  1041  * HMAX could be 
changed. As the result, frame rate & exposure
0985dd30 Leon Luo  2017-10-05  1042  * are changed.
0985dd30 Leon Luo  2017-10-05  1043  * gain is not affected.
0985dd30 Leon Luo  2017-10-05  1044  */
0985dd30 Leon Luo  2017-10-05  1045 ret = 
imx274_set_frame_interval(imx274,
0985dd30 Leon Luo  2017-10-05  1046 
imx274->frame_interval);
0985dd30 Leon Luo  2017-10-05  1047 if (ret)
0985dd30 Leon Luo  2017-10-05  1048 goto fail;
0985dd30 Leon Luo  2017-10-05  1049  
0985dd30 Leon Luo  2017-10-05  1050 /* update exposure time 
*/
0985dd30 Leon Luo  2017-10-05  1051 ret = 
__v4l2_ctrl_s_ctrl(imx274->ctrls.exposure,
0985dd30 Leon Luo  2017-10-05  1

Re: [PATCH] media: mxl5xx: fix get_algo()'s return type

[Daniel Scheller]

Am Tue, 24 Apr 2018 15:19:31 +0200
schrieb Luc Van Oostenryck :

> The method dvb_frontend_ops::get_frontend_algo() is defined as
> returning an 'enum dvbfe_algo', but the implementation in this
> driver returns an 'int'.
> 
> Fix this by returning 'enum dvbfe_algo' in this driver too.
> 
> Signed-off-by: Luc Van Oostenryck 
> ---
>  drivers/media/dvb-frontends/mxl5xx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/dvb-frontends/mxl5xx.c 
> b/drivers/media/dvb-frontends/mxl5xx.c
> index 483ee7d61..274d8fca0 100644
> --- a/drivers/media/dvb-frontends/mxl5xx.c
> +++ b/drivers/media/dvb-frontends/mxl5xx.c
> @@ -375,7 +375,7 @@ static void release(struct dvb_frontend *fe)
>   kfree(state);
>  }
>  
> -static int get_algo(struct dvb_frontend *fe)
> +static enum dvbfe_algo get_algo(struct dvb_frontend *fe)
>  {
>   return DVBFE_ALGO_HW;
>  }

Acked-by: Daniel Scheller 

Best regards,
Daniel Scheller
-- 
https://github.com/herrnst

Re: [PATCH] media: stv0910: fix get_algo()'s return type

[Daniel Scheller]

Am Tue, 24 Apr 2018 15:19:38 +0200
schrieb Luc Van Oostenryck :

> The method dvb_frontend_ops::get_frontend_algo() is defined as
> returning an 'enum dvbfe_algo', but the implementation in this
> driver returns an 'int'.
> 
> Fix this by returning 'enum dvbfe_algo' in this driver too.
> 
> Signed-off-by: Luc Van Oostenryck 
> ---
>  drivers/media/dvb-frontends/stv0910.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/dvb-frontends/stv0910.c 
> b/drivers/media/dvb-frontends/stv0910.c
> index 52355c14f..50234d311 100644
> --- a/drivers/media/dvb-frontends/stv0910.c
> +++ b/drivers/media/dvb-frontends/stv0910.c
> @@ -1633,7 +1633,7 @@ static int tune(struct dvb_frontend *fe, bool re_tune,
>   return 0;
>  }
>  
> -static int get_algo(struct dvb_frontend *fe)
> +static enum dvbfe_algo get_algo(struct dvb_frontend *fe)
>  {
>   return DVBFE_ALGO_HW;
>  }

Acked-by: Daniel Scheller 

Best regards,
Daniel Scheller
-- 
https://github.com/herrnst

Re: [PATCH 2/8] dt-bindings: display: bridge: thc63lvd1024: Add lvds map property

[Rob Herring]

On Thu, Apr 19, 2018 at 11:31:03AM +0200, Jacopo Mondi wrote:
> The THC63LVD1024 LVDS to RGB bridge supports two different input mapping
> modes, selectable by means of an external pin.
> 
> Describe the LVDS mode map through a newly defined mandatory property in
> device tree bindings.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  .../devicetree/bindings/display/bridge/thine,thc63lvd1024.txt  | 3 
> +++
>  1 file changed, 3 insertions(+)

+1 for what Laurent said.

Reviewed-by: Rob Herring 

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

[Rui Miguel Silva]

Hi Fabio,
On Tue 24 Apr 2018 at 15:53, Fabio Estevam wrote:

Hi Rui,

On Thu, Apr 19, 2018 at 8:00 AM, Rui Miguel Silva 
 wrote:
Add device tree binding documentation for the OV2680 camera 
sensor.


Reviewed-by: Rob Herring 
CC: devicet...@vger.kernel.org
Signed-off-by: Rui Miguel Silva 
---
 .../devicetree/bindings/media/i2c/ov2680.txt  | 40 
 +++

 1 file changed, 40 insertions(+)
 create mode 100644 
 Documentation/devicetree/bindings/media/i2c/ov2680.txt


diff --git 
a/Documentation/devicetree/bindings/media/i2c/ov2680.txt 
b/Documentation/devicetree/bindings/media/i2c/ov2680.txt

new file mode 100644
index ..0e29f1a113c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov2680.txt
@@ -0,0 +1,40 @@
+* Omnivision OV2680 MIPI CSI-2 sensor
+
+Required Properties:
+- compatible: should be "ovti,ov2680".
+- clocks: reference to the xvclk input clock.
+- clock-names: should be "xvclk".


You missed to pass the camera power supplies as required 
properties:


Urgh, yes, you are right, I will add this.

---
Cheers,
Rui



DOVDD-supply
AVDD-supply
DVDD-supply

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

[Fabio Estevam]

Hi Rui,

On Thu, Apr 19, 2018 at 8:00 AM, Rui Miguel Silva  wrote:
> Add device tree binding documentation for the OV2680 camera sensor.
>
> Reviewed-by: Rob Herring 
> CC: devicet...@vger.kernel.org
> Signed-off-by: Rui Miguel Silva 
> ---
>  .../devicetree/bindings/media/i2c/ov2680.txt  | 40 +++
>  1 file changed, 40 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2680.txt
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov2680.txt 
> b/Documentation/devicetree/bindings/media/i2c/ov2680.txt
> new file mode 100644
> index ..0e29f1a113c0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov2680.txt
> @@ -0,0 +1,40 @@
> +* Omnivision OV2680 MIPI CSI-2 sensor
> +
> +Required Properties:
> +- compatible: should be "ovti,ov2680".
> +- clocks: reference to the xvclk input clock.
> +- clock-names: should be "xvclk".

You missed to pass the camera power supplies as required properties:

DOVDD-supply
AVDD-supply
DVDD-supply

[PATCH v3 2/2] media: Add a driver for the ov7251 camera sensor

[Todor Tomov]

The ov7251 sensor is a 1/7.5-Inch B VGA (640x480) CMOS Digital Image
Sensor from Omnivision.

The driver supports the following modes:
- 640x480 30fps
- 640x480 60fps
- 640x480 90fps

Output format is 10bit B RAW - MEDIA_BUS_FMT_Y10_1X10.

The driver supports configuration via user controls for:
- exposure and gain;
- horizontal and vertical flip;
- test pattern.

Signed-off-by: Todor Tomov 
Reviewed-by: Jacopo Mondi 
---
 drivers/media/i2c/Kconfig  |   13 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov7251.c | 1501 
 3 files changed, 1515 insertions(+)
 create mode 100644 drivers/media/i2c/ov7251.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 541f0d28..1ff7aaf 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -688,6 +688,19 @@ config VIDEO_OV5695
  To compile this driver as a module, choose M here: the
  module will be called ov5695.
 
+config VIDEO_OV7251
+   tristate "OmniVision OV7251 sensor support"
+   depends on OF
+   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on MEDIA_CAMERA_SUPPORT
+   select V4L2_FWNODE
+   help
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV7251 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov7251.
+
 config VIDEO_OV772X
tristate "OmniVision OV772x sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index ea34aee..c8585b1 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
 obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
 obj-$(CONFIG_VIDEO_OV5695) += ov5695.o
 obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
+obj-$(CONFIG_VIDEO_OV7251) += ov7251.o
 obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
 obj-$(CONFIG_VIDEO_OV772X) += ov772x.o
diff --git a/drivers/media/i2c/ov7251.c b/drivers/media/i2c/ov7251.c
new file mode 100644
index 000..69e70a0
--- /dev/null
+++ b/drivers/media/i2c/ov7251.c
@@ -0,0 +1,1501 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for the OV7251 camera sensor.
+ *
+ * Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2017-2018, Linaro Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define OV7251_SC_MODE_SELECT  0x0100
+#define OV7251_SC_MODE_SELECT_SW_STANDBY   0x0
+#define OV7251_SC_MODE_SELECT_STREAMING0x1
+
+#define OV7251_CHIP_ID_HIGH0x300a
+#define OV7251_CHIP_ID_HIGH_BYTE   0x77
+#define OV7251_CHIP_ID_LOW 0x300b
+#define OV7251_CHIP_ID_LOW_BYTE0x50
+#define OV7251_SC_GP_IO_IN10x3029
+#define OV7251_AEC_EXPO_0  0x3500
+#define OV7251_AEC_EXPO_1  0x3501
+#define OV7251_AEC_EXPO_2  0x3502
+#define OV7251_AEC_AGC_ADJ_0   0x350a
+#define OV7251_AEC_AGC_ADJ_1   0x350b
+#define OV7251_TIMING_FORMAT1  0x3820
+#define OV7251_TIMING_FORMAT1_VFLIPBIT(2)
+#define OV7251_TIMING_FORMAT2  0x3821
+#define OV7251_TIMING_FORMAT2_MIRROR   BIT(2)
+#define OV7251_PRE_ISP_00  0x5e00
+#define OV7251_PRE_ISP_00_TEST_PATTERN BIT(7)
+
+struct reg_value {
+   u16 reg;
+   u8 val;
+};
+
+struct ov7251_mode_info {
+   u32 width;
+   u32 height;
+   const struct reg_value *data;
+   u32 data_size;
+   u32 pixel_clock;
+   u32 link_freq;
+   u16 exposure_max;
+   u16 exposure_def;
+   struct v4l2_fract timeperframe;
+};
+
+struct ov7251 {
+   struct i2c_client *i2c_client;
+   struct device *dev;
+   struct v4l2_subdev sd;
+   struct media_pad pad;
+   struct v4l2_fwnode_endpoint ep;
+   struct v4l2_mbus_framefmt fmt;
+   struct v4l2_rect crop;
+   struct clk *xclk;
+   u32 xclk_freq;
+
+   struct regulator *io_regulator;
+   struct regulator *core_regulator;
+   struct regulator *analog_regulator;
+
+   const struct ov7251_mode_info *current_mode;
+
+   struct v4l2_ctrl_handler ctrls;
+   struct v4l2_ctrl *pixel_clock;
+   struct v4l2_ctrl *link_freq;
+   struct v4l2_ctrl *exposure;
+   struct v4l2_ctrl *gain;
+
+   /* Cached register values */
+   u8 aec_pk_manual;
+   u8 pre_isp_00;
+   u8 timing_format1;
+   u8 timing_format2;
+
+   struct mutex lock; /* lock to protect power state, ctrls and mode */
+   bool power_on;
+
+   struct gpio_desc *enable_gpio;
+};
+
+static inline struct ov7251 *to_ov7251(struct v4l2_subdev *sd)
+{
+   return container_of(sd, struct ov7251, sd);
+}
+
+static const struct reg_value 

[PATCH v3 0/2] Add support for ov7251 camera sensor

[Todor Tomov]

The ov7251 sensor is a 1/7.5-Inch B VGA (640x480) CMOS Digital Image
Sensor from Omnivision.

--

Version 3:
- DT binding: added that there shall be a single endpoint node in the port node;
- added a comment for regulator enable order;
- set exposure and gain with a single i2c transaction;
- caclulate sleep after gpio config from external clock frequency;
- use MEDIA_BUS_FMT_Y10_1X10 format code;
- lock for power state, controls, mode and start streaming;
- remove regulator_set_voltage();
- use probe_new();
- remove i2c_device_id table;
- change of_property_read_u32 to fwnode_property_read_u32;
- few corrections from checkpatch --strict.

--

Version 2:
- changed ov7251 node's name in DT binding example;
- SPDX licence identifier;
- better names for register value defines;
- remove power reference counting and leave a power state only;
- use v4l2_find_nearest_size() to find sensor mode by requested size;
- set ycbcr_enc, quantization and xfer_func in set_fmt;
- use struct fwnode_handle instead of struct device_node;
- add comment in driver about external clock value.

--

Todor Tomov (2):
  dt-bindings: media: Binding document for OV7251 camera sensor
  media: Add a driver for the ov7251 camera sensor

 .../devicetree/bindings/media/i2c/ov7251.txt   |   52 +
 drivers/media/i2c/Kconfig  |   13 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov7251.c | 1501 
 4 files changed, 1567 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7251.txt
 create mode 100644 drivers/media/i2c/ov7251.c

-- 
2.7.4

[PATCH v3 1/2] dt-bindings: media: Binding document for OV7251 camera sensor

[Todor Tomov]

Add the document for ov7251 device tree binding.

CC: Rob Herring 
CC: Mark Rutland 
CC: devicet...@vger.kernel.org
Signed-off-by: Todor Tomov 
Reviewed-by: Rob Herring 
---
 .../devicetree/bindings/media/i2c/ov7251.txt   | 52 ++
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7251.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/ov7251.txt 
b/Documentation/devicetree/bindings/media/i2c/ov7251.txt
new file mode 100644
index 000..8281151
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov7251.txt
@@ -0,0 +1,52 @@
+* Omnivision 1/7.5-Inch B VGA CMOS Digital Image Sensor
+
+The Omnivision OV7251 is a 1/7.5-Inch CMOS active pixel digital image sensor
+with an active array size of 640H x 480V. It is programmable through a serial
+I2C interface.
+
+Required Properties:
+- compatible: Value should be "ovti,ov7251".
+- clocks: Reference to the xclk clock.
+- clock-names: Should be "xclk".
+- clock-frequency: Frequency of the xclk clock.
+- enable-gpios: Chip enable GPIO. Polarity is GPIO_ACTIVE_HIGH. This 
corresponds
+  to the hardware pin XSHUTDOWN which is physically active low.
+- vdddo-supply: Chip digital IO regulator.
+- vdda-supply: Chip analog regulator.
+- vddd-supply: Chip digital core regulator.
+
+The device node shall contain one 'port' child node with a single 'endpoint'
+subnode for its digital output video port, in accordance with the video
+interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+{
+   ...
+
+   ov7251: camera-sensor@60 {
+   compatible = "ovti,ov7251";
+   reg = <0x60>;
+
+   enable-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_bw_default>;
+
+   clocks = < 200>;
+   clock-names = "xclk";
+   clock-frequency = <2400>;
+
+   vdddo-supply = <_dovdd_1v8>;
+   vdda-supply = <_avdd_2v8>;
+   vddd-supply = <_dvdd_1v2>;
+
+   port {
+   ov7251_ep: endpoint {
+   clock-lanes = <1>;
+   data-lanes = <0>;
+   remote-endpoint = <_ep>;
+   };
+   };
+   };
+   };
-- 
2.7.4

Re: [PATCH v2 13/13] media: imx274: add SELECTION support for cropping

[Luca Ceresoli]

Hi Sakari,

On 24/04/2018 11:59, Sakari Ailus wrote:
> Hi Luca,
> 
> Thank you for the patchset.
> 
> Some comments below... what I propose is that I apply the rest of the
> patches and then the comments to this one could be addressed separately.
> Would that work for you?

Yes, but I suggest you only apply patches 1-6. I noticed a warning in
patch 9, and patches 7-8 are not very useful without it. Will fix it in v3.

I'll wait for the outcome of the discussion below before sending v3.
Tell me if you prefer me to do it earlier.

> On Tue, Apr 24, 2018 at 10:24:18AM +0200, Luca Ceresoli wrote:
>> Currently this driver does not support cropping. The supported modes
>> are the following, all capturing the entire area:
>>
>>  - 3840x2160, 1:1 binning (native sensor resolution)
>>  - 1920x1080, 2:1 binning
>>  - 1280x720,  3:1 binning
>>
>> The set_fmt callback chooses among these 3 configurations the one that
>> matches the requested format.
>>
>> Adding support to VIDIOC_SUBDEV_G_SELECTION and
>> VIDIOC_SUBDEV_S_SELECTION involved a complete rewrite of set_fmt,
>> which now chooses the most appropriate binning based on the ratio
>> between the previously-set cropping size and the format size being
>> requested.
>>
>> Note that the names in enum imx274_mode change from being
>> resolution-based to being binning-based. Without cropping, the two
>> naming are equivalent. With cropping, the resolution could be
>> different, e.g. using 2:1 binning mode to crop 1200x960 and output a
>> 600x480 format. Using binning in the names avoids anny
>> misunderstanding.
>>
>> Signed-off-by: Luca Ceresoli 
>>
>> ---
>> Changed v1 -> v2:
>>  - add "media: " prefix to commit message
>> ---
>>  drivers/media/i2c/imx274.c | 266 
>> -
>>  1 file changed, 192 insertions(+), 74 deletions(-)
>>
>> diff --git a/drivers/media/i2c/imx274.c b/drivers/media/i2c/imx274.c
>> index b6c54712f2aa..ceb5b3e498c6 100644
>> --- a/drivers/media/i2c/imx274.c
>> +++ b/drivers/media/i2c/imx274.c
>> @@ -19,6 +19,7 @@
>>   * along with this program.  If not, see .
>>   */
>>  
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -74,7 +75,7 @@
>>   */
>>  #define IMX274_MIN_EXPOSURE_TIME(4 * 260 / 72)
>>  
>> -#define IMX274_DEFAULT_MODE IMX274_MODE_3840X2160
>> +#define IMX274_DEFAULT_MODE IMX274_MODE_BINNING_OFF
>>  #define IMX274_MAX_WIDTH(3840)
>>  #define IMX274_MAX_HEIGHT   (2160)
>>  #define IMX274_MAX_FRAME_RATE   (120)
>> @@ -111,6 +112,20 @@
>>  #define IMX274_SHR_REG_LSB  0x300C /* SHR */
>>  #define IMX274_SVR_REG_MSB  0x300F /* SVR */
>>  #define IMX274_SVR_REG_LSB  0x300E /* SVR */
>> +#define IMX274_HTRIM_EN_REG 0x3037
>> +#define IMX274_HTRIM_START_REG_LSB  0x3038
>> +#define IMX274_HTRIM_START_REG_MSB  0x3039
>> +#define IMX274_HTRIM_END_REG_LSB0x303A
>> +#define IMX274_HTRIM_END_REG_MSB0x303B
>> +#define IMX274_VWIDCUTEN_REG0x30DD
>> +#define IMX274_VWIDCUT_REG_LSB  0x30DE
>> +#define IMX274_VWIDCUT_REG_MSB  0x30DF
>> +#define IMX274_VWINPOS_REG_LSB  0x30E0
>> +#define IMX274_VWINPOS_REG_MSB  0x30E1
>> +#define IMX274_WRITE_VSIZE_REG_LSB  0x3130
>> +#define IMX274_WRITE_VSIZE_REG_MSB  0x3131
>> +#define IMX274_Y_OUT_SIZE_REG_LSB   0x3132
>> +#define IMX274_Y_OUT_SIZE_REG_MSB   0x3133
>>  #define IMX274_VMAX_REG_1   0x30FA /* VMAX, MSB */
>>  #define IMX274_VMAX_REG_2   0x30F9 /* VMAX */
>>  #define IMX274_VMAX_REG_3   0x30F8 /* VMAX, LSB */
>> @@ -141,9 +156,9 @@ static const struct regmap_config imx274_regmap_config = 
>> {
>>  };
>>  
>>  enum imx274_mode {
>> -IMX274_MODE_3840X2160,
>> -IMX274_MODE_1920X1080,
>> -IMX274_MODE_1280X720,
>> +IMX274_MODE_BINNING_OFF,
>> +IMX274_MODE_BINNING_2_1,
>> +IMX274_MODE_BINNING_3_1,
>>  };
>>  
>>  /*
>> @@ -215,31 +230,14 @@ static const struct reg_8 
>> imx274_mode1_3840x2160_raw10[] = {
>>  {0x3004, 0x01},
>>  {0x3005, 0x01},
>>  {0x3006, 0x00},
>> -{0x3007, 0x02},
>> +{0x3007, 0xa2},
>>  
>>  {0x3018, 0xA2}, /* output XVS, HVS */
>>  
>>  {0x306B, 0x05},
>>  {0x30E2, 0x01},
>> -{0x30F6, 0x07}, /* HMAX, 263 */
>> -{0x30F7, 0x01}, /* HMAX */
>> -
>> -{0x30dd, 0x01}, /* crop to 2160 */
>> -{0x30de, 0x06},
>> -{0x30df, 0x00},
>> -{0x30e0, 0x12},
>> -{0x30e1, 0x00},
>> -{0x3037, 0x01}, /* to crop to 3840 */
>> -{0x3038, 0x0c},
>> -{0x3039, 0x00},
>> -{0x303a, 0x0c},
>> -{0x303b, 0x0f},
>>  
>>  {0x30EE, 0x01},
>> -{0x3130, 0x86},
>> -{0x3131, 0x08},
>> -{0x3132, 0x7E},
>> -{0x3133, 0x08},

[PATCH] media: dvb_net: fix dvb_net_tx()'s return type

[Luc Van Oostenryck]

The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, but the implementation in this
driver returns an 'int'.

Fix this by returning 'netdev_tx_t' in this driver too.

Signed-off-by: Luc Van Oostenryck 
---
 drivers/media/dvb-core/dvb_net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-core/dvb_net.c b/drivers/media/dvb-core/dvb_net.c
index ba39f9942..10f78109b 100644
--- a/drivers/media/dvb-core/dvb_net.c
+++ b/drivers/media/dvb-core/dvb_net.c
@@ -1005,7 +1005,7 @@ static int dvb_net_sec_callback(const u8 *buffer1, size_t 
buffer1_len,
return 0;
 }
 
-static int dvb_net_tx(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t dvb_net_tx(struct sk_buff *skb, struct net_device *dev)
 {
dev_kfree_skb(skb);
return NETDEV_TX_OK;
-- 
2.17.0

Re: [PATCH v11 3/4] dt-bindings: media: Add Cadence MIPI-CSI2 TX Device Tree bindings

[Benoit Parrot]

Acked-by: Benoit Parrot 

Maxime Ripard  wrote on Tue [2018-Apr-24 14:26:59 
+0200]:
> The Cadence MIPI-CSI2 TX controller is a CSI2 bridge that supports up to 4
> video streams and can output on up to 4 CSI-2 lanes, depending on the
> hardware implementation.
> 
> It can operate with an external D-PHY, an internal one or no D-PHY at all
> in some configurations.
> 
> Acked-by: Rob Herring 
> Acked-by: Sakari Ailus 
> Reviewed-by: Niklas Söderlund 
> Signed-off-by: Maxime Ripard 
> ---
>  .../devicetree/bindings/media/cdns,csi2tx.txt | 98 +++
>  1 file changed, 98 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2tx.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/cdns,csi2tx.txt 
> b/Documentation/devicetree/bindings/media/cdns,csi2tx.txt
> new file mode 100644
> index ..459c6e332f52
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/cdns,csi2tx.txt
> @@ -0,0 +1,98 @@
> +Cadence MIPI-CSI2 TX controller
> +===
> +
> +The Cadence MIPI-CSI2 TX controller is a CSI-2 bridge supporting up to
> +4 CSI lanes in output, and up to 4 different pixel streams in input.
> +
> +Required properties:
> +  - compatible: must be set to "cdns,csi2tx"
> +  - reg: base address and size of the memory mapped region
> +  - clocks: phandles to the clocks driving the controller
> +  - clock-names: must contain:
> +* esc_clk: escape mode clock
> +* p_clk: register bank clock
> +* pixel_if[0-3]_clk: pixel stream output clock, one for each stream
> + implemented in hardware, between 0 and 3
> +
> +Optional properties
> +  - phys: phandle to the D-PHY. If it is set, phy-names need to be set
> +  - phy-names: must contain "dphy"
> +
> +Required subnodes:
> +  - ports: A ports node with one port child node per device input and output
> +   port, in accordance with the video interface bindings defined in
> +   Documentation/devicetree/bindings/media/video-interfaces.txt. The
> +   port nodes are numbered as follows.
> +
> +   Port Description
> +   -
> +   0CSI-2 output
> +   1Stream 0 input
> +   2Stream 1 input
> +   3Stream 2 input
> +   4Stream 3 input
> +
> +   The stream input port nodes are optional if they are not
> +   connected to anything at the hardware level or implemented
> +   in the design. Since there is only one endpoint per port,
> +   the endpoints are not numbered.
> +
> +Example:
> +
> +csi2tx: csi-bridge@0d0e1000 {
> + compatible = "cdns,csi2tx";
> + reg = <0x0d0e1000 0x1000>;
> + clocks = <>, <>,
> +  <>, <>,
> +  <>, <>;
> + clock-names = "p_clk", "esc_clk",
> +   "pixel_if0_clk", "pixel_if1_clk",
> +   "pixel_if2_clk", "pixel_if3_clk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + csi2tx_out: endpoint {
> + remote-endpoint = <_in>;
> + clock-lanes = <0>;
> + data-lanes = <1 2>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + csi2tx_in_stream0: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> +
> + csi2tx_in_stream1: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@3 {
> + reg = <3>;
> +
> + csi2tx_in_stream2: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@4 {
> + reg = <4>;
> +
> + csi2tx_in_stream3: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> +};
> -- 
> 2.17.0
> 

[PATCH] media: lgdt3306a: fix lgdt3306a_search()'s return type

[Luc Van Oostenryck]

The method dvb_frontend_ops::search() is defined as
returning an 'enum dvbfe_search', but the implementation in this
driver returns an 'int'.

Fix this by returning 'enum dvbfe_search' in this driver too.

Signed-off-by: Luc Van Oostenryck 
---
 drivers/media/dvb-frontends/lgdt3306a.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
b/drivers/media/dvb-frontends/lgdt3306a.c
index 7eb4e1469..32de82447 100644
--- a/drivers/media/dvb-frontends/lgdt3306a.c
+++ b/drivers/media/dvb-frontends/lgdt3306a.c
@@ -1784,7 +1784,7 @@ static int lgdt3306a_get_tune_settings(struct 
dvb_frontend *fe,
return 0;
 }
 
-static int lgdt3306a_search(struct dvb_frontend *fe)
+static enum dvbfe_search lgdt3306a_search(struct dvb_frontend *fe)
 {
enum fe_status status = 0;
int ret;
-- 
2.17.0

[PATCH] media: cx24117: fix cx24117_get_algo()'s return type

[Luc Van Oostenryck]

The method dvb_frontend_ops::get_frontend_algo() is defined as
returning an 'enum dvbfe_algo', but the implementation in this
driver returns an 'int'.

Fix this by returning 'enum dvbfe_algo' in this driver too.

Signed-off-by: Luc Van Oostenryck 
---
 drivers/media/dvb-frontends/cx24117.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/cx24117.c 
b/drivers/media/dvb-frontends/cx24117.c
index 8935114b7..ba55d75d9 100644
--- a/drivers/media/dvb-frontends/cx24117.c
+++ b/drivers/media/dvb-frontends/cx24117.c
@@ -1555,7 +1555,7 @@ static int cx24117_tune(struct dvb_frontend *fe, bool 
re_tune,
return cx24117_read_status(fe, status);
 }
 
-static int cx24117_get_algo(struct dvb_frontend *fe)
+static enum dvbfe_algo cx24117_get_algo(struct dvb_frontend *fe)
 {
return DVBFE_ALGO_HW;
 }
-- 
2.17.0

[PATCH] media: cx24116: fix cx24116_get_algo()'s return type

[Luc Van Oostenryck]

The method dvb_frontend_ops::get_frontend_algo() is defined as
returning an 'enum dvbfe_algo', but the implementation in this
driver returns an 'int'.

Fix this by returning 'enum dvbfe_algo' in this driver too.

Signed-off-by: Luc Van Oostenryck 
---
 drivers/media/dvb-frontends/cx24116.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/cx24116.c 
b/drivers/media/dvb-frontends/cx24116.c
index 786c56a4e..2dbc7349d 100644
--- a/drivers/media/dvb-frontends/cx24116.c
+++ b/drivers/media/dvb-frontends/cx24116.c
@@ -1456,7 +1456,7 @@ static int cx24116_tune(struct dvb_frontend *fe, bool 
re_tune,
return cx24116_read_status(fe, status);
 }
 
-static int cx24116_get_algo(struct dvb_frontend *fe)
+static enum dvbfe_algo cx24116_get_algo(struct dvb_frontend *fe)
 {
return DVBFE_ALGO_HW;
 }
-- 
2.17.0

Re: [PATCH v11 4/4] v4l: cadence: Add Cadence MIPI-CSI2 TX driver

[Benoit Parrot]

Acked-by: Benoit Parrot 

Maxime Ripard  wrote on Tue [2018-Apr-24 14:27:00 
+0200]:
> The Cadence MIPI-CSI2 TX controller is an hardware block meant to be used
> as a bridge between pixel interfaces and a CSI-2 bus.
> 
> It supports operating with an internal or external D-PHY, with up to 4
> lanes, or without any D-PHY. The current code only supports the latter
> case.
> 
> While the virtual channel input on the pixel interface can be directly
> mapped to CSI2, the datatype input is actually a selection signal (3-bits)
> mapping to a table of up to 8 preconfigured datatypes/formats (programmed
> at start-up)
> 
> The block supports up to 8 input datatypes.
> 
> Acked-by: Sakari Ailus 
> Reviewed-by: Niklas Söderlund 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/media/platform/cadence/Kconfig   |  11 +
>  drivers/media/platform/cadence/Makefile  |   1 +
>  drivers/media/platform/cadence/cdns-csi2tx.c | 563 +++
>  3 files changed, 575 insertions(+)
>  create mode 100644 drivers/media/platform/cadence/cdns-csi2tx.c
> 
> diff --git a/drivers/media/platform/cadence/Kconfig 
> b/drivers/media/platform/cadence/Kconfig
> index 70c95d79c8f7..3bf0f2454384 100644
> --- a/drivers/media/platform/cadence/Kconfig
> +++ b/drivers/media/platform/cadence/Kconfig
> @@ -20,4 +20,15 @@ config VIDEO_CADENCE_CSI2RX
> To compile this driver as a module, choose M here: the module will be
> called cdns-csi2rx.
>  
> +config VIDEO_CADENCE_CSI2TX
> + tristate "Cadence MIPI-CSI2 TX Controller"
> + depends on MEDIA_CONTROLLER
> + depends on VIDEO_V4L2_SUBDEV_API
> + select V4L2_FWNODE
> + help
> +   Support for the Cadence MIPI CSI2 Transceiver controller.
> +
> +   To compile this driver as a module, choose M here: the module will be
> +   called cdns-csi2tx.
> +
>  endif
> diff --git a/drivers/media/platform/cadence/Makefile 
> b/drivers/media/platform/cadence/Makefile
> index 99a4086b7448..7fe992273162 100644
> --- a/drivers/media/platform/cadence/Makefile
> +++ b/drivers/media/platform/cadence/Makefile
> @@ -1 +1,2 @@
>  obj-$(CONFIG_VIDEO_CADENCE_CSI2RX)   += cdns-csi2rx.o
> +obj-$(CONFIG_VIDEO_CADENCE_CSI2TX)   += cdns-csi2tx.o
> diff --git a/drivers/media/platform/cadence/cdns-csi2tx.c 
> b/drivers/media/platform/cadence/cdns-csi2tx.c
> new file mode 100644
> index ..dfa1d88d955b
> --- /dev/null
> +++ b/drivers/media/platform/cadence/cdns-csi2tx.c
> @@ -0,0 +1,563 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Driver for Cadence MIPI-CSI2 TX Controller
> + *
> + * Copyright (C) 2017-2018 Cadence Design Systems Inc.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define CSI2TX_DEVICE_CONFIG_REG 0x00
> +#define CSI2TX_DEVICE_CONFIG_STREAMS_MASKGENMASK(6, 4)
> +#define CSI2TX_DEVICE_CONFIG_HAS_DPHYBIT(3)
> +#define CSI2TX_DEVICE_CONFIG_LANES_MASK  GENMASK(2, 0)
> +
> +#define CSI2TX_CONFIG_REG0x20
> +#define CSI2TX_CONFIG_CFG_REQBIT(2)
> +#define CSI2TX_CONFIG_SRST_REQ   BIT(1)
> +
> +#define CSI2TX_DPHY_CFG_REG  0x28
> +#define CSI2TX_DPHY_CFG_CLK_RESETBIT(16)
> +#define CSI2TX_DPHY_CFG_LANE_RESET(n)BIT((n) + 12)
> +#define CSI2TX_DPHY_CFG_MODE_MASKGENMASK(9, 8)
> +#define CSI2TX_DPHY_CFG_MODE_LPDT(2 << 8)
> +#define CSI2TX_DPHY_CFG_MODE_HS  (1 << 8)
> +#define CSI2TX_DPHY_CFG_MODE_ULPS(0 << 8)
> +#define CSI2TX_DPHY_CFG_CLK_ENABLE   BIT(4)
> +#define CSI2TX_DPHY_CFG_LANE_ENABLE(n)   BIT(n)
> +
> +#define CSI2TX_DPHY_CLK_WAKEUP_REG   0x2c
> +#define CSI2TX_DPHY_CLK_WAKEUP_ULPS_CYCLES(n)((n) & 0x)
> +
> +#define CSI2TX_DT_CFG_REG(n) (0x80 + (n) * 8)
> +#define CSI2TX_DT_CFG_DT(n)  (((n) & 0x3f) << 2)
> +
> +#define CSI2TX_DT_FORMAT_REG(n)  (0x84 + (n) * 8)
> +#define CSI2TX_DT_FORMAT_BYTES_PER_LINE(n)   (((n) & 0x) << 16)
> +#define CSI2TX_DT_FORMAT_MAX_LINE_NUM(n) ((n) & 0x)
> +
> +#define CSI2TX_STREAM_IF_CFG_REG(n)  (0x100 + (n) * 4)
> +#define CSI2TX_STREAM_IF_CFG_FILL_LEVEL(n)   ((n) & 0x1f)
> +
> +#define CSI2TX_LANES_MAX 4
> +#define CSI2TX_STREAMS_MAX   4
> +
> +enum csi2tx_pads {
> + CSI2TX_PAD_SOURCE,
> + CSI2TX_PAD_SINK_STREAM0,
> + CSI2TX_PAD_SINK_STREAM1,
> + CSI2TX_PAD_SINK_STREAM2,
> + CSI2TX_PAD_SINK_STREAM3,
> + CSI2TX_PAD_MAX,
> +};
> +
> +struct csi2tx_fmt {
> + u32 mbus;
> + u32 dt;
> + u32 bpp;
> +};
> +
> +struct csi2tx_priv {
> + struct device   *dev;
> + unsigned intcount;
> +
> + /*
> +   

[PATCH] media: cx24123: fix cx24123_get_algo()'s return type

[Luc Van Oostenryck]

The method dvb_frontend_ops::get_frontend_algo() is defined as
returning an 'enum dvbfe_algo', but the implementation in this
driver returns an 'int'.

Fix this by returning 'enum dvbfe_algo' in this driver too.

Signed-off-by: Luc Van Oostenryck 
---
 drivers/media/dvb-frontends/cx24123.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/cx24123.c 
b/drivers/media/dvb-frontends/cx24123.c
index 228ba1f4b..bf33e7390 100644
--- a/drivers/media/dvb-frontends/cx24123.c
+++ b/drivers/media/dvb-frontends/cx24123.c
@@ -1005,7 +1005,7 @@ static int cx24123_tune(struct dvb_frontend *fe,
return retval;
 }
 
-static int cx24123_get_algo(struct dvb_frontend *fe)
+static enum dvbfe_algo cx24123_get_algo(struct dvb_frontend *fe)
 {
return DVBFE_ALGO_HW;
 }
-- 
2.17.0

[PATCH] media: mb86a20s: fix mb86a20s_get_frontend_algo()'s return type

[Luc Van Oostenryck]

The method dvb_frontend_ops::get_frontend_algo() is defined as
returning an 'enum dvbfe_algo', but the implementation in this
driver returns an 'int'.

Fix this by returning 'enum dvbfe_algo' in this driver too.

Signed-off-by: Luc Van Oostenryck 
---
 drivers/media/dvb-frontends/mb86a20s.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/mb86a20s.c 
b/drivers/media/dvb-frontends/mb86a20s.c
index 36e95196d..c3b1b88e2 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -2055,7 +2055,7 @@ static void mb86a20s_release(struct dvb_frontend *fe)
kfree(state);
 }
 
-static int mb86a20s_get_frontend_algo(struct dvb_frontend *fe)
+static enum dvbfe_algo mb86a20s_get_frontend_algo(struct dvb_frontend *fe)
 {
return DVBFE_ALGO_HW;
 }
-- 
2.17.0

[PATCH] media: mxl5xx: fix get_algo()'s return type

[Luc Van Oostenryck]

The method dvb_frontend_ops::get_frontend_algo() is defined as
returning an 'enum dvbfe_algo', but the implementation in this
driver returns an 'int'.

Fix this by returning 'enum dvbfe_algo' in this driver too.

Signed-off-by: Luc Van Oostenryck 
---
 drivers/media/dvb-frontends/mxl5xx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/mxl5xx.c 
b/drivers/media/dvb-frontends/mxl5xx.c
index 483ee7d61..274d8fca0 100644
--- a/drivers/media/dvb-frontends/mxl5xx.c
+++ b/drivers/media/dvb-frontends/mxl5xx.c
@@ -375,7 +375,7 @@ static void release(struct dvb_frontend *fe)
kfree(state);
 }
 
-static int get_algo(struct dvb_frontend *fe)
+static enum dvbfe_algo get_algo(struct dvb_frontend *fe)
 {
return DVBFE_ALGO_HW;
 }
-- 
2.17.0

[PATCH] media: s921: fix s921_get_algo()'s return type

[Luc Van Oostenryck]

The method dvb_frontend_ops::get_frontend_algo() is defined as
returning an 'enum dvbfe_algo', but the implementation in this
driver returns an 'int'.

Fix this by returning 'enum dvbfe_algo' in this driver too.

Signed-off-by: Luc Van Oostenryck 
---
 drivers/media/dvb-frontends/s921.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/s921.c 
b/drivers/media/dvb-frontends/s921.c
index 2d75ede77..6c9015236 100644
--- a/drivers/media/dvb-frontends/s921.c
+++ b/drivers/media/dvb-frontends/s921.c
@@ -464,7 +464,7 @@ static int s921_tune(struct dvb_frontend *fe,
return rc;
 }
 
-static int s921_get_algo(struct dvb_frontend *fe)
+static enum dvbfe_algo s921_get_algo(struct dvb_frontend *fe)
 {
return DVBFE_ALGO_HW;
 }
-- 
2.17.0

Re: [PATCH v11 2/4] v4l: cadence: Add Cadence MIPI-CSI2 RX driver

[Benoit Parrot]

Maxime Ripard  wrote on Tue [2018-Apr-24 14:26:58 
+0200]:
> The Cadence CSI-2 RX Controller is an hardware block meant to be used as a
> bridge between a CSI-2 bus and pixel grabbers.
> 
> It supports operating with internal or external D-PHY, with up to 4 lanes,
> or without any D-PHY. The current code only supports the latter case.
> 
> It also support dynamic mapping of the CSI-2 virtual channels to the
> associated pixel grabbers, but that isn't allowed at the moment either.
> 
> Acked-by: Sakari Ailus 
> Reviewed-by: Niklas Söderlund 
> Signed-off-by: Maxime Ripard 
> ---
>  MAINTAINERS  |   7 +
>  drivers/media/platform/Kconfig   |   1 +
>  drivers/media/platform/Makefile  |   1 +
>  drivers/media/platform/cadence/Kconfig   |  23 +
>  drivers/media/platform/cadence/Makefile  |   1 +
>  drivers/media/platform/cadence/cdns-csi2rx.c | 500 +++
>  6 files changed, 533 insertions(+)
>  create mode 100644 drivers/media/platform/cadence/Kconfig
>  create mode 100644 drivers/media/platform/cadence/Makefile
>  create mode 100644 drivers/media/platform/cadence/cdns-csi2rx.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0a1410d5a621..2c27d39611eb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3133,6 +3133,13 @@ S: Supported
>  F:   Documentation/filesystems/caching/cachefiles.txt
>  F:   fs/cachefiles/
>  
> +CADENCE MIPI-CSI2 BRIDGES
> +M:   Maxime Ripard 
> +L:   linux-media@vger.kernel.org
> +S:   Maintained
> +F:   Documentation/devicetree/bindings/media/cdns,*.txt
> +F:   drivers/media/platform/cadence/cdns-csi2*
> +
>  CADET FM/AM RADIO RECEIVER DRIVER
>  M:   Hans Verkuil 
>  L:   linux-media@vger.kernel.org
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index c7a1cf8a1b01..029340ec3da4 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -26,6 +26,7 @@ config VIDEO_VIA_CAMERA
>  #
>  # Platform multimedia device configuration
>  #
> +source "drivers/media/platform/cadence/Kconfig"
>  
>  source "drivers/media/platform/davinci/Kconfig"
>  
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 932515df4477..04bc1502a30e 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -3,6 +3,7 @@
>  # Makefile for the video capture/playback device drivers.
>  #
>  
> +obj-$(CONFIG_VIDEO_CADENCE)  += cadence/
>  obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
>  obj-$(CONFIG_VIDEO_CAFE_CCIC) += marvell-ccic/
>  obj-$(CONFIG_VIDEO_MMP_CAMERA) += marvell-ccic/
> diff --git a/drivers/media/platform/cadence/Kconfig 
> b/drivers/media/platform/cadence/Kconfig
> new file mode 100644
> index ..70c95d79c8f7
> --- /dev/null
> +++ b/drivers/media/platform/cadence/Kconfig
> @@ -0,0 +1,23 @@
> +config VIDEO_CADENCE
> + bool "Cadence Video Devices"
> + help
> +   If you have a media device designed by Cadence, say Y.
> +
> +   Note that this option doesn't include new drivers in the kernel:
> +   saying N will just cause Kconfig to skip all the questions about
> +   Cadence media devices.
> +
> +if VIDEO_CADENCE
> +
> +config VIDEO_CADENCE_CSI2RX
> + tristate "Cadence MIPI-CSI2 RX Controller"
> + depends on MEDIA_CONTROLLER
> + depends on VIDEO_V4L2_SUBDEV_API
> + select V4L2_FWNODE
> + help
> +   Support for the Cadence MIPI CSI2 Receiver controller.
> +
> +   To compile this driver as a module, choose M here: the module will be
> +   called cdns-csi2rx.
> +
> +endif
> diff --git a/drivers/media/platform/cadence/Makefile 
> b/drivers/media/platform/cadence/Makefile
> new file mode 100644
> index ..99a4086b7448
> --- /dev/null
> +++ b/drivers/media/platform/cadence/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_VIDEO_CADENCE_CSI2RX)   += cdns-csi2rx.o

You probably want to add an SPDX license tag here also.

At any rate:

Acked-by: Benoit Parrot 

> diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c 
> b/drivers/media/platform/cadence/cdns-csi2rx.c
> new file mode 100644
> index ..01f8321c12da
> --- /dev/null
> +++ b/drivers/media/platform/cadence/cdns-csi2rx.c
> @@ -0,0 +1,500 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Driver for Cadence MIPI-CSI2 RX Controller v1.3
> + *
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define CSI2RX_DEVICE_CFG_REG0x000
> +
> +#define CSI2RX_SOFT_RESET_REG0x004
> +#define CSI2RX_SOFT_RESET_PROTOCOL   BIT(1)
> +#define 

[PATCH] media: bt8xx: fix dst_get_tuning_algo()'s return type

[Luc Van Oostenryck]

The method dvb_frontend_ops::get_frontend_algo() is defined as
returning an 'enum dvbfe_algo', but the implementation in this
driver returns an 'int'.

Fix this by returning 'enum dvbfe_algo' in this driver too.

Signed-off-by: Luc Van Oostenryck 
---
 drivers/media/pci/bt8xx/dst.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/pci/bt8xx/dst.c b/drivers/media/pci/bt8xx/dst.c
index 4f0bba9e4..2e33b7236 100644
--- a/drivers/media/pci/bt8xx/dst.c
+++ b/drivers/media/pci/bt8xx/dst.c
@@ -1657,7 +1657,7 @@ static int dst_tune_frontend(struct dvb_frontend* fe,
return 0;
 }
 
-static int dst_get_tuning_algo(struct dvb_frontend *fe)
+static enum dvbfe_algo dst_get_tuning_algo(struct dvb_frontend *fe)
 {
return dst_algo ? DVBFE_ALGO_HW : DVBFE_ALGO_SW;
 }
-- 
2.17.0

[PATCH] media: stv0910: fix get_algo()'s return type

[Luc Van Oostenryck]

The method dvb_frontend_ops::get_frontend_algo() is defined as
returning an 'enum dvbfe_algo', but the implementation in this
driver returns an 'int'.

Fix this by returning 'enum dvbfe_algo' in this driver too.

Signed-off-by: Luc Van Oostenryck 
---
 drivers/media/dvb-frontends/stv0910.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/stv0910.c 
b/drivers/media/dvb-frontends/stv0910.c
index 52355c14f..50234d311 100644
--- a/drivers/media/dvb-frontends/stv0910.c
+++ b/drivers/media/dvb-frontends/stv0910.c
@@ -1633,7 +1633,7 @@ static int tune(struct dvb_frontend *fe, bool re_tune,
return 0;
 }
 
-static int get_algo(struct dvb_frontend *fe)
+static enum dvbfe_algo get_algo(struct dvb_frontend *fe)
 {
return DVBFE_ALGO_HW;
 }
-- 
2.17.0

[PATCH] media: fix va1j5jf8007t_get_frontend_algo()'s return type

[Luc Van Oostenryck]

The method dvb_frontend_ops::get_frontend_algo() is defined as
returning an 'enum dvbfe_algo', but the implementation in this
driver returns an 'int'.

Fix this by returning 'enum dvbfe_algo' in this driver too.

Signed-off-by: Luc Van Oostenryck 
---
 drivers/media/pci/pt1/va1j5jf8007t.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/pci/pt1/va1j5jf8007t.c 
b/drivers/media/pci/pt1/va1j5jf8007t.c
index a52984a6f..588ee5d9f 100644
--- a/drivers/media/pci/pt1/va1j5jf8007t.c
+++ b/drivers/media/pci/pt1/va1j5jf8007t.c
@@ -88,7 +88,7 @@ static int va1j5jf8007t_read_snr(struct dvb_frontend *fe, u16 
*snr)
return 0;
 }
 
-static int va1j5jf8007t_get_frontend_algo(struct dvb_frontend *fe)
+static enum dvbfe_algo va1j5jf8007t_get_frontend_algo(struct dvb_frontend *fe)
 {
return DVBFE_ALGO_HW;
 }
-- 
2.17.0

[PATCH] media: fix va1j5jf8007s_get_frontend_algo()'s return type

[Luc Van Oostenryck]

The method dvb_frontend_ops::get_frontend_algo() is defined as
returning an 'enum dvbfe_algo', but the implementation in this
driver returns an 'int'.

Fix this by returning 'enum dvbfe_algo' in this driver too.

Signed-off-by: Luc Van Oostenryck 
---
 drivers/media/pci/pt1/va1j5jf8007s.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/pci/pt1/va1j5jf8007s.c 
b/drivers/media/pci/pt1/va1j5jf8007s.c
index f49867aef..3edc0fe2e 100644
--- a/drivers/media/pci/pt1/va1j5jf8007s.c
+++ b/drivers/media/pci/pt1/va1j5jf8007s.c
@@ -98,7 +98,7 @@ static int va1j5jf8007s_read_snr(struct dvb_frontend *fe, u16 
*snr)
return 0;
 }
 
-static int va1j5jf8007s_get_frontend_algo(struct dvb_frontend *fe)
+static enum dvbfe_algo va1j5jf8007s_get_frontend_algo(struct dvb_frontend *fe)
 {
return DVBFE_ALGO_HW;
 }
-- 
2.17.0

[PATCH] media: cxd2820r: fix cxd2820r_get_frontend_algo()'s return type

[Luc Van Oostenryck]

The method dvb_frontend_ops::get_frontend_algo() is defined as
returning an 'enum dvbfe_algo', but the implementation in this
driver returns an 'int'.

Fix this by returning 'enum dvbfe_algo' in this driver too.

Signed-off-by: Luc Van Oostenryck 
---
 drivers/media/dvb-frontends/cxd2820r_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c 
b/drivers/media/dvb-frontends/cxd2820r_core.c
index f6ebbb47b..3e0d8cbd7 100644
--- a/drivers/media/dvb-frontends/cxd2820r_core.c
+++ b/drivers/media/dvb-frontends/cxd2820r_core.c
@@ -403,7 +403,7 @@ static enum dvbfe_search cxd2820r_search(struct 
dvb_frontend *fe)
return DVBFE_ALGO_SEARCH_ERROR;
 }
 
-static int cxd2820r_get_frontend_algo(struct dvb_frontend *fe)
+static enum dvbfe_algo cxd2820r_get_frontend_algo(struct dvb_frontend *fe)
 {
return DVBFE_ALGO_CUSTOM;
 }
-- 
2.17.0

[PATCH] media: cx24120: fix cx24120_get_algo()'s return type

[Luc Van Oostenryck]

The method dvb_frontend_ops::get_frontend_algo() is defined as
returning an 'enum dvbfe_algo', but the implementation in this
driver returns an 'int'.

Fix this by returning 'enum dvbfe_algo' in this driver too.

Signed-off-by: Luc Van Oostenryck 
---
 drivers/media/dvb-frontends/cx24120.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/cx24120.c 
b/drivers/media/dvb-frontends/cx24120.c
index 810f68acd..ccbabdae6 100644
--- a/drivers/media/dvb-frontends/cx24120.c
+++ b/drivers/media/dvb-frontends/cx24120.c
@@ -1491,7 +1491,7 @@ static int cx24120_tune(struct dvb_frontend *fe, bool 
re_tune,
return cx24120_read_status(fe, status);
 }
 
-static int cx24120_get_algo(struct dvb_frontend *fe)
+static enum dvbfe_algo cx24120_get_algo(struct dvb_frontend *fe)
 {
return DVBFE_ALGO_HW;
 }
-- 
2.17.0

[PATCH] remove 2 excess lines in driver module em28xx

[mjs]

From 5103cc546075de0eb800f5a76f3212a3e342b833 Mon Sep 17 00:00:00 2001
From: Marcel Stork 
Date: Tue, 24 Apr 2018 14:43:01 +0200
Subject: [PATCH] remove 2 excess lines in driver module em28xx

A cosmetic change by combining two sets of boards into one set because having 
the same arguments.
 
 Changes to be committed:
modified:   em28xx-cards.c
---
 em28xx-cards.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/em28xx-cards.c b/em28xx-cards.c
index 6e0e67d..7fa9a00 100644
--- a/em28xx-cards.c
+++ b/em28xx-cards.c
@@ -3182,8 +3182,6 @@ void em28xx_setup_xc3028(struct em28xx *dev, struct 
xc2028_ctrl *ctl)
case EM2880_BOARD_EMPIRE_DUAL_TV:
case EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900:
case EM2882_BOARD_TERRATEC_HYBRID_XS:
-   ctl->demod = XC3028_FE_ZARLINK456;
-   break;
case EM2880_BOARD_TERRATEC_HYBRID_XS:
case EM2880_BOARD_TERRATEC_HYBRID_XS_FR:
case EM2881_BOARD_PINNACLE_HYBRID_PRO:
-- 
2.11.0

[PATCH][next] media: ispstat: don't dereference user_cfg before a null check

[Colin King]

From: Colin Ian King 

The pointer user_cfg (a copy of new_conf) is dereference before
new_conf is null checked, hence we may have a null pointer dereference
on user_cfg when assigning buf_size from user_cfg->buf_size. Ensure
this does not occur by moving the assignment of buf_size after the
null check.

Detected by CoverityScan, CID#1468386 ("Dereference before null check")

Fixes: 68e342b3068c ("[media] omap3isp: Statistics")
Signed-off-by: Colin Ian King 
---
 drivers/media/platform/omap3isp/ispstat.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/omap3isp/ispstat.c 
b/drivers/media/platform/omap3isp/ispstat.c
index 0b31f6c5791f..38cb1b2cc672 100644
--- a/drivers/media/platform/omap3isp/ispstat.c
+++ b/drivers/media/platform/omap3isp/ispstat.c
@@ -523,7 +523,7 @@ int omap3isp_stat_config(struct ispstat *stat, void 
*new_conf)
int ret;
unsigned long irqflags;
struct ispstat_generic_config *user_cfg = new_conf;
-   u32 buf_size = user_cfg->buf_size;
+   u32 buf_size;
 
if (!new_conf) {
dev_dbg(stat->isp->dev, "%s: configuration is NULL\n",
@@ -532,6 +532,7 @@ int omap3isp_stat_config(struct ispstat *stat, void 
*new_conf)
}
 
mutex_lock(>ioctl_lock);
+   buf_size = user_cfg->buf_size;
 
dev_dbg(stat->isp->dev,
"%s: configuring module with buffer size=0x%08lx\n",
-- 
2.17.0

Re: [DE] Re: [CN] Re: [DE] Re: coda: i.MX6 decoding performance issues for multi-streaming

[Philipp Zabel]

Hi Javier,

On Mon, 2018-04-23 at 11:29 +0200, Javier Martin wrote:
>   Sorry for resurrecting this thread but I'm still quite interested on 
> making this scenario work:
> 
>  > OK, I've performed some tests with several resolutions and gop sizes, 
> here is the table with the results:
>  >
>  > Always playing 3 streams
>  >
>  > | Resolution   |  QP   | GopSize   |  Kind of content |  Result 
>  |
>  > | 640x368  |  25   |16 |   Waving hands   |   time 
> shifts, no DEC_PIC_SUCCESS   |
>  > | 640x368  |  25   |0  |   Waving hands   |   time 
> shifts, no DEC_PIC_SUCCESS|
>  > | 320x192  |  25   |0  |   Waving hands   |   time 
> shifts, no DEC_PIC_SUCCESS |
>  > | 320x192  |  25   |16 |   Waving hands   |   time 
> shifts, no DEC_PIC_SUCCESS |
>  > | 1280x720 |  25   |16 |   Waving hands   |   macroblock 
> artifacts and lots of DEC_PIC_SUCCESS messages |
>  > | 1280x720 |  25   |0  |   Waving hands   | 
> Surprisingly smooth, no artifacts, time shifts nor DEC_PIC_SUCCESS|
>  >
>  > * The issues always happens in the first stream, the other 2 streams 
> are fine.
>  > * With GopSize = 0 I can even decode 4 720p streams with no artifacts
>  >
>  > It looks like for small resolutions it suffers from time shifts when 
> multi-streaming, always affecting the first stream for some reason. In 
> this case gop size doesn't seem to make any difference.
>  >
>  > For higher resolutions like 720p using GopSize = 0 seems to improve 
> things a lot.
>  >

I've tried to reproduce this with GStreamer 1.14.0:

gst-launch-1.0 filesrc location=test_720p.mp4 ! qtdemux ! h264parse ! tee 
name=t \
  t. ! v4l2h264dec ! fakesink \
  t. ! v4l2h264dec ! fakesink \
  t. ! v4l2h264dec ! fakesink \
  t. ! v4l2h264dec ! fakesink

with sync=false and sync=true, and with waylandsink instead of fakesink,
with various streams, all the same or all different:

gst-launch-1.0 \
  filesrc location=a.mp4 ! qtdemux ! h264parse !
v4l2h264dec ! fakesink \
  filesrc location=b.mp4 ! qtdemux ! h264parse !
v4l2h264dec ! fakesink \
  filesrc location=c.mp4 ! qtdemux ! h264parse !
v4l2h264dec ! fakesink \
  filesrc location=d.mp4 ! qtdemux ! h264parse !
v4l2h264dec ! fakesink

I can't seem to cause the DEC_PIC_SUCCESS issue with this setup, with
CODA-preencoded files. Same when I split this into an UDP sender and
receiver via RTP:

gst-launch-1.0 filesrc location=test_720p.mp4 ! qtdemux ! h264parse ! 
rtph264pay ! udpsink host=10.0.0.1 port=12345

gst-launch-1.0 udpsrc port=12345 ! application/x-rtp,payload=96 ! rtph264depay 
! h264parse ! tee name=t \
  t. ! v4l2h264dec ! fakesink \
  t. ! v4l2h264dec ! fakesink \
  t. ! v4l2h264dec ! fakesink \
  t. ! v4l2h264dec ! fakesink

Could you try to either recreate the issue with GStreamer or with a
simple test program that I can see, or maybe provide a test stream
somewhere that causes the issue for me to download?

> Philipp, you mentioned some possible issue with context switches in a 
> previous e-mail:
>  > I fear this may be some interaction between coda context switches and
>  > bitstream reader unit state.
>
> Philipp, do these results confirm your theory? Are there any more tests 
> I could prepare to help get to the bottom of this or this is something 
> that belongs entirely to the coda firmware domain? Does anyone know if 
> the official BSP from NXP is able to decode 4 flows without issues?

I still have no idea. Maybe print coda_get_bitstream_payload(ctx) when
the DEC_PIC_SUCCESS error is emitted, to check whether this could be
some kind of buffer underrun issue. I assume you are not dropping any
buffers.

regards
Philipp

[PATCH 01/28] venus: hfi_msgs: correct pointer increment

[Stanimir Varbanov]

Data pointer should be incremented by size of the structure not
the size of a pointer, correct the mistake.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/hfi_msgs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/hfi_msgs.c 
b/drivers/media/platform/qcom/venus/hfi_msgs.c
index 90c93d9603dc..589e1a6b36a9 100644
--- a/drivers/media/platform/qcom/venus/hfi_msgs.c
+++ b/drivers/media/platform/qcom/venus/hfi_msgs.c
@@ -60,14 +60,14 @@ static void event_seq_changed(struct venus_core *core, 
struct venus_inst *inst,
frame_sz = (struct hfi_framesize *)data_ptr;
event.width = frame_sz->width;
event.height = frame_sz->height;
-   data_ptr += sizeof(frame_sz);
+   data_ptr += sizeof(*frame_sz);
break;
case HFI_PROPERTY_PARAM_PROFILE_LEVEL_CURRENT:
data_ptr += sizeof(u32);
profile_level = (struct hfi_profile_level *)data_ptr;
event.profile = profile_level->profile;
event.level = profile_level->level;
-   data_ptr += sizeof(profile_level);
+   data_ptr += sizeof(*profile_level);
break;
default:
break;
-- 
2.14.1

[PATCH 03/28] venus: hfi: update sequence event to handle more properties

[Stanimir Varbanov]

HFI version 4xx can pass more properties in the sequence change
event, extend the event structure with them.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/hfi.h  |  9 ++
 drivers/media/platform/qcom/venus/hfi_msgs.c | 46 
 2 files changed, 55 insertions(+)

diff --git a/drivers/media/platform/qcom/venus/hfi.h 
b/drivers/media/platform/qcom/venus/hfi.h
index 5466b7d60dd0..21376d93170f 100644
--- a/drivers/media/platform/qcom/venus/hfi.h
+++ b/drivers/media/platform/qcom/venus/hfi.h
@@ -74,6 +74,15 @@ struct hfi_event_data {
u32 tag;
u32 profile;
u32 level;
+   u32 bit_depth;
+   u32 pic_struct;
+   u32 colour_space;
+   u32 entropy_mode;
+   u32 buf_count;
+   struct {
+   u32 left, top;
+   u32 width, height;
+   } input_crop;
 };
 
 /* define core states */
diff --git a/drivers/media/platform/qcom/venus/hfi_msgs.c 
b/drivers/media/platform/qcom/venus/hfi_msgs.c
index 589e1a6b36a9..5970e9b1716b 100644
--- a/drivers/media/platform/qcom/venus/hfi_msgs.c
+++ b/drivers/media/platform/qcom/venus/hfi_msgs.c
@@ -25,10 +25,17 @@
 static void event_seq_changed(struct venus_core *core, struct venus_inst *inst,
  struct hfi_msg_event_notify_pkt *pkt)
 {
+   enum hfi_version ver = core->res->hfi_version;
struct hfi_event_data event = {0};
int num_properties_changed;
struct hfi_framesize *frame_sz;
struct hfi_profile_level *profile_level;
+   struct hfi_bit_depth *pixel_depth;
+   struct hfi_pic_struct *pic_struct;
+   struct hfi_colour_space *colour_info;
+   struct hfi_buffer_requirements *bufreq;
+   struct hfi_extradata_input_crop *crop;
+   u32 entropy_mode = 0;
u8 *data_ptr;
u32 ptype;
 
@@ -69,6 +76,45 @@ static void event_seq_changed(struct venus_core *core, 
struct venus_inst *inst,
event.level = profile_level->level;
data_ptr += sizeof(*profile_level);
break;
+   case HFI_PROPERTY_PARAM_VDEC_PIXEL_BITDEPTH:
+   data_ptr += sizeof(u32);
+   pixel_depth = (struct hfi_bit_depth *)data_ptr;
+   event.bit_depth = pixel_depth->bit_depth;
+   data_ptr += sizeof(*pixel_depth);
+   break;
+   case HFI_PROPERTY_PARAM_VDEC_PIC_STRUCT:
+   data_ptr += sizeof(u32);
+   pic_struct = (struct hfi_pic_struct *)data_ptr;
+   event.pic_struct = pic_struct->progressive_only;
+   data_ptr += sizeof(*pic_struct);
+   break;
+   case HFI_PROPERTY_PARAM_VDEC_COLOUR_SPACE:
+   data_ptr += sizeof(u32);
+   colour_info = (struct hfi_colour_space *)data_ptr;
+   event.colour_space = colour_info->colour_space;
+   data_ptr += sizeof(*colour_info);
+   break;
+   case HFI_PROPERTY_CONFIG_VDEC_ENTROPY:
+   data_ptr += sizeof(u32);
+   entropy_mode = *(u32 *)data_ptr;
+   event.entropy_mode = entropy_mode;
+   data_ptr += sizeof(u32);
+   break;
+   case HFI_PROPERTY_CONFIG_BUFFER_REQUIREMENTS:
+   data_ptr += sizeof(u32);
+   bufreq = (struct hfi_buffer_requirements *)data_ptr;
+   event.buf_count = HFI_BUFREQ_COUNT_MIN(bufreq, ver);
+   data_ptr += sizeof(*bufreq);
+   break;
+   case HFI_INDEX_EXTRADATA_INPUT_CROP:
+   data_ptr += sizeof(u32);
+   crop = (struct hfi_extradata_input_crop *)data_ptr;
+   event.input_crop.left = crop->left;
+   event.input_crop.top = crop->top;
+   event.input_crop.width = crop->width;
+   event.input_crop.height = crop->height;
+   data_ptr += sizeof(*crop);
+   break;
default:
break;
}
-- 
2.14.1

[PATCH 02/28] venus: hfi: preparation to support venus 4xx

[Stanimir Varbanov]

This covers the differences between 1xx,3xx and 4xx.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/core.h |  4 ++
 drivers/media/platform/qcom/venus/helpers.c  | 37 +++
 drivers/media/platform/qcom/venus/hfi_helper.h   | 84 ++--
 drivers/media/platform/qcom/venus/hfi_venus_io.h | 24 +++
 drivers/media/platform/qcom/venus/vdec.c |  5 +-
 drivers/media/platform/qcom/venus/venc.c |  5 +-
 6 files changed, 137 insertions(+), 22 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/core.h 
b/drivers/media/platform/qcom/venus/core.h
index 0360d295f4c8..8d3e150800c9 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -305,6 +305,10 @@ struct venus_inst {
struct hfi_buffer_requirements bufreq[HFI_BUFFER_TYPE_MAX];
 };
 
+#define IS_V1(core)((core)->res->hfi_version == HFI_VERSION_1XX)
+#define IS_V3(core)((core)->res->hfi_version == HFI_VERSION_3XX)
+#define IS_V4(core)((core)->res->hfi_version == HFI_VERSION_4XX)
+
 #define ctrl_to_inst(ctrl) \
container_of((ctrl)->handler, struct venus_inst, ctrl_handler)
 
diff --git a/drivers/media/platform/qcom/venus/helpers.c 
b/drivers/media/platform/qcom/venus/helpers.c
index 0ce9559a2924..d9065cc8a7d3 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -166,21 +166,37 @@ static int intbufs_unset_buffers(struct venus_inst *inst)
return ret;
 }
 
-static const unsigned int intbuf_types[] = {
-   HFI_BUFFER_INTERNAL_SCRATCH,
-   HFI_BUFFER_INTERNAL_SCRATCH_1,
-   HFI_BUFFER_INTERNAL_SCRATCH_2,
+static const unsigned int intbuf_types_1xx[] = {
+   HFI_BUFFER_INTERNAL_SCRATCH(HFI_VERSION_1XX),
+   HFI_BUFFER_INTERNAL_SCRATCH_1(HFI_VERSION_1XX),
+   HFI_BUFFER_INTERNAL_SCRATCH_2(HFI_VERSION_1XX),
+   HFI_BUFFER_INTERNAL_PERSIST,
+   HFI_BUFFER_INTERNAL_PERSIST_1,
+};
+
+static const unsigned int intbuf_types_4xx[] = {
+   HFI_BUFFER_INTERNAL_SCRATCH(HFI_VERSION_4XX),
+   HFI_BUFFER_INTERNAL_SCRATCH_1(HFI_VERSION_4XX),
+   HFI_BUFFER_INTERNAL_SCRATCH_2(HFI_VERSION_4XX),
HFI_BUFFER_INTERNAL_PERSIST,
HFI_BUFFER_INTERNAL_PERSIST_1,
 };
 
 static int intbufs_alloc(struct venus_inst *inst)
 {
-   unsigned int i;
+   size_t arr_sz;
+   size_t i;
int ret;
 
-   for (i = 0; i < ARRAY_SIZE(intbuf_types); i++) {
-   ret = intbufs_set_buffer(inst, intbuf_types[i]);
+   if (IS_V4(inst->core))
+   arr_sz = ARRAY_SIZE(intbuf_types_4xx);
+   else
+   arr_sz = ARRAY_SIZE(intbuf_types_1xx);
+
+   for (i = 0; i < arr_sz; i++) {
+   ret = intbufs_set_buffer(inst,
+   IS_V4(inst->core) ? intbuf_types_4xx[i] :
+   intbuf_types_1xx[i]);
if (ret)
goto error;
}
@@ -257,12 +273,11 @@ static int load_scale_clocks(struct venus_core *core)
 
 set_freq:
 
-   if (core->res->hfi_version == HFI_VERSION_3XX) {
-   ret = clk_set_rate(clk, freq);
+   ret = clk_set_rate(clk, freq);
+
+   if (IS_V3(core) || IS_V4(core)) {
ret |= clk_set_rate(core->core0_clk, freq);
ret |= clk_set_rate(core->core1_clk, freq);
-   } else {
-   ret = clk_set_rate(clk, freq);
}
 
if (ret) {
diff --git a/drivers/media/platform/qcom/venus/hfi_helper.h 
b/drivers/media/platform/qcom/venus/hfi_helper.h
index 55d8eb21403a..1bc5aab1ce6b 100644
--- a/drivers/media/platform/qcom/venus/hfi_helper.h
+++ b/drivers/media/platform/qcom/venus/hfi_helper.h
@@ -121,6 +121,7 @@
 #define HFI_EXTRADATA_METADATA_FILLER  0x7fe2
 
 #define HFI_INDEX_EXTRADATA_INPUT_CROP 0x070e
+#define HFI_INDEX_EXTRADATA_OUTPUT_CROP0x070f
 #define HFI_INDEX_EXTRADATA_DIGITAL_ZOOM   0x0710
 #define HFI_INDEX_EXTRADATA_ASPECT_RATIO   0x7f13
 
@@ -376,13 +377,18 @@
 #define HFI_BUFFER_OUTPUT2 0x3
 #define HFI_BUFFER_INTERNAL_PERSIST0x4
 #define HFI_BUFFER_INTERNAL_PERSIST_1  0x5
-#define HFI_BUFFER_INTERNAL_SCRATCH0x101
-#define HFI_BUFFER_EXTRADATA_INPUT 0x102
-#define HFI_BUFFER_EXTRADATA_OUTPUT0x103
-#define HFI_BUFFER_EXTRADATA_OUTPUT2   0x104
-#define HFI_BUFFER_INTERNAL_SCRATCH_1  0x105
-#define HFI_BUFFER_INTERNAL_SCRATCH_2  0x106
-
+#define HFI_BUFFER_INTERNAL_SCRATCH(ver)   \
+   (((ver) == HFI_VERSION_4XX) ? 0x6 : 0x101)
+#define HFI_BUFFER_INTERNAL_SCRATCH_1(ver) \
+   (((ver) == HFI_VERSION_4XX) ? 0x7 : 0x105)
+#define HFI_BUFFER_INTERNAL_SCRATCH_2(ver) \
+   (((ver) == HFI_VERSION_4XX) ? 0x8 : 

[PATCH 05/28] venus: hfi: support session continue for 4xx version

[Stanimir Varbanov]

This makes possible to handle session_continue for 4xx as well.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/hfi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/qcom/venus/hfi.c 
b/drivers/media/platform/qcom/venus/hfi.c
index bca894a00c07..cbc6fad05e47 100644
--- a/drivers/media/platform/qcom/venus/hfi.c
+++ b/drivers/media/platform/qcom/venus/hfi.c
@@ -312,7 +312,7 @@ int hfi_session_continue(struct venus_inst *inst)
 {
struct venus_core *core = inst->core;
 
-   if (core->res->hfi_version != HFI_VERSION_3XX)
+   if (core->res->hfi_version == HFI_VERSION_1XX)
return 0;
 
return core->ops->session_continue(inst);
-- 
2.14.1

[PATCH 06/28] venus: hfi: handle buffer output2 type as well

[Stanimir Varbanov]

This adds handling of buffers of type OUTPUT2 which is needed to
support Venus 4xx version.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/hfi.c  | 3 ++-
 drivers/media/platform/qcom/venus/hfi_msgs.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/hfi.c 
b/drivers/media/platform/qcom/venus/hfi.c
index cbc6fad05e47..a570fdad0de0 100644
--- a/drivers/media/platform/qcom/venus/hfi.c
+++ b/drivers/media/platform/qcom/venus/hfi.c
@@ -473,7 +473,8 @@ int hfi_session_process_buf(struct venus_inst *inst, struct 
hfi_frame_data *fd)
 
if (fd->buffer_type == HFI_BUFFER_INPUT)
return ops->session_etb(inst, fd);
-   else if (fd->buffer_type == HFI_BUFFER_OUTPUT)
+   else if (fd->buffer_type == HFI_BUFFER_OUTPUT ||
+fd->buffer_type == HFI_BUFFER_OUTPUT2)
return ops->session_ftb(inst, fd);
 
return -EINVAL;
diff --git a/drivers/media/platform/qcom/venus/hfi_msgs.c 
b/drivers/media/platform/qcom/venus/hfi_msgs.c
index 5970e9b1716b..023802e62833 100644
--- a/drivers/media/platform/qcom/venus/hfi_msgs.c
+++ b/drivers/media/platform/qcom/venus/hfi_msgs.c
@@ -825,7 +825,8 @@ static void hfi_session_ftb_done(struct venus_core *core,
error = HFI_ERR_SESSION_INVALID_PARAMETER;
}
 
-   if (buffer_type != HFI_BUFFER_OUTPUT)
+   if (buffer_type != HFI_BUFFER_OUTPUT &&
+   buffer_type != HFI_BUFFER_OUTPUT2)
goto done;
 
if (hfi_flags & HFI_BUFFERFLAG_EOS)
-- 
2.14.1

[PATCH 08/28] venus: hfi_venus: add suspend function for 4xx version

[Stanimir Varbanov]

This adds suspend (power collapse) function with slightly
different order of calls comparing with Venus 3xx.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/hfi_venus.c | 52 +++
 1 file changed, 52 insertions(+)

diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c 
b/drivers/media/platform/qcom/venus/hfi_venus.c
index 53546174aab8..f61d34bf61b4 100644
--- a/drivers/media/platform/qcom/venus/hfi_venus.c
+++ b/drivers/media/platform/qcom/venus/hfi_venus.c
@@ -1443,6 +1443,55 @@ static int venus_suspend_1xx(struct venus_core *core)
return 0;
 }
 
+static int venus_suspend_4xx(struct venus_core *core)
+{
+   struct venus_hfi_device *hdev = to_hfi_priv(core);
+   struct device *dev = core->dev;
+   u32 val;
+   int ret;
+
+   if (!hdev->power_enabled || hdev->suspended)
+   return 0;
+
+   mutex_lock(>lock);
+   ret = venus_is_valid_state(hdev);
+   mutex_unlock(>lock);
+
+   if (!ret) {
+   dev_err(dev, "bad state, cannot suspend\n");
+   return -EINVAL;
+   }
+
+   ret = venus_prepare_power_collapse(hdev, false);
+   if (ret) {
+   dev_err(dev, "prepare for power collapse fail (%d)\n", ret);
+   return ret;
+   }
+
+   ret = readl_poll_timeout(core->base + CPU_CS_SCIACMDARG0, val,
+val & CPU_CS_SCIACMDARG0_PC_READY,
+POLL_INTERVAL_US, 10);
+   if (ret) {
+   dev_err(dev, "Polling power collapse ready timed out\n");
+   return ret;
+   }
+
+   mutex_lock(>lock);
+
+   ret = venus_power_off(hdev);
+   if (ret) {
+   dev_err(dev, "venus_power_off (%d)\n", ret);
+   mutex_unlock(>lock);
+   return ret;
+   }
+
+   hdev->suspended = true;
+
+   mutex_unlock(>lock);
+
+   return 0;
+}
+
 static int venus_suspend_3xx(struct venus_core *core)
 {
struct venus_hfi_device *hdev = to_hfi_priv(core);
@@ -1507,6 +1556,9 @@ static int venus_suspend(struct venus_core *core)
if (core->res->hfi_version == HFI_VERSION_3XX)
return venus_suspend_3xx(core);
 
+   if (core->res->hfi_version == HFI_VERSION_4XX)
+   return venus_suspend_4xx(core);
+
return venus_suspend_1xx(core);
 }
 
-- 
2.14.1

[PATCH 07/28] venus: hfi_venus: add halt AXI support for Venus 4xx

[Stanimir Varbanov]

Add AXI halt support for version 4xx by using venus wrapper
registers.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/hfi_venus.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c 
b/drivers/media/platform/qcom/venus/hfi_venus.c
index 734ce11b0ed0..53546174aab8 100644
--- a/drivers/media/platform/qcom/venus/hfi_venus.c
+++ b/drivers/media/platform/qcom/venus/hfi_venus.c
@@ -532,6 +532,23 @@ static int venus_halt_axi(struct venus_hfi_device *hdev)
u32 val;
int ret;
 
+   if (hdev->core->res->hfi_version == HFI_VERSION_4XX) {
+   val = venus_readl(hdev, WRAPPER_CPU_AXI_HALT);
+   val |= BIT(16);
+   venus_writel(hdev, WRAPPER_CPU_AXI_HALT, val);
+
+   ret = readl_poll_timeout(base + WRAPPER_CPU_AXI_HALT_STATUS,
+val, val & BIT(24),
+POLL_INTERVAL_US,
+VBIF_AXI_HALT_ACK_TIMEOUT_US);
+   if (ret) {
+   dev_err(dev, "AXI bus port halt timeout\n");
+   return ret;
+   }
+
+   return 0;
+   }
+
/* Halt AXI and AXI IMEM VBIF Access */
val = venus_readl(hdev, VBIF_AXI_HALT_CTRL0);
val |= VBIF_AXI_HALT_CTRL0_HALT_REQ;
-- 
2.14.1

[PATCH 09/28] venus: venc,vdec: adds clocks needed for venus 4xx

[Stanimir Varbanov]

This extends the clocks number to support suspend and resume
on Venus version 4xx.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/core.h |  4 +--
 drivers/media/platform/qcom/venus/vdec.c | 42 ++--
 drivers/media/platform/qcom/venus/venc.c | 42 ++--
 3 files changed, 72 insertions(+), 16 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/core.h 
b/drivers/media/platform/qcom/venus/core.h
index 8d3e150800c9..b5b9a84e9155 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -92,8 +92,8 @@ struct venus_core {
void __iomem *base;
int irq;
struct clk *clks[VIDC_CLKS_NUM_MAX];
-   struct clk *core0_clk;
-   struct clk *core1_clk;
+   struct clk *core0_clk, *core0_bus_clk;
+   struct clk *core1_clk, *core1_bus_clk;
struct video_device *vdev_dec;
struct video_device *vdev_enc;
struct v4l2_device v4l2_dev;
diff --git a/drivers/media/platform/qcom/venus/vdec.c 
b/drivers/media/platform/qcom/venus/vdec.c
index 261a51adeef2..c45452634e7e 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -1081,12 +1081,18 @@ static int vdec_probe(struct platform_device *pdev)
if (!core)
return -EPROBE_DEFER;
 
-   if (core->res->hfi_version == HFI_VERSION_3XX) {
+   if (IS_V3(core) || IS_V4(core)) {
core->core0_clk = devm_clk_get(dev, "core");
if (IS_ERR(core->core0_clk))
return PTR_ERR(core->core0_clk);
}
 
+   if (IS_V4(core)) {
+   core->core0_bus_clk = devm_clk_get(dev, "bus");
+   if (IS_ERR(core->core0_bus_clk))
+   return PTR_ERR(core->core0_bus_clk);
+   }
+
platform_set_drvdata(pdev, core);
 
vdev = video_device_alloc();
@@ -1132,12 +1138,23 @@ static __maybe_unused int vdec_runtime_suspend(struct 
device *dev)
 {
struct venus_core *core = dev_get_drvdata(dev);
 
-   if (core->res->hfi_version == HFI_VERSION_1XX)
+   if (IS_V1(core))
return 0;
 
-   writel(0, core->base + WRAPPER_VDEC_VCODEC_POWER_CONTROL);
+   if (IS_V3(core))
+   writel(0, core->base + WRAPPER_VDEC_VCODEC_POWER_CONTROL);
+   else if (IS_V4(core))
+   writel(0, core->base + WRAPPER_VCODEC0_MMCC_POWER_CONTROL);
+
+   if (IS_V4(core))
+   clk_disable_unprepare(core->core0_bus_clk);
+
clk_disable_unprepare(core->core0_clk);
-   writel(1, core->base + WRAPPER_VDEC_VCODEC_POWER_CONTROL);
+
+   if (IS_V3(core))
+   writel(1, core->base + WRAPPER_VDEC_VCODEC_POWER_CONTROL);
+   else if (IS_V4(core))
+   writel(1, core->base + WRAPPER_VCODEC0_MMCC_POWER_CONTROL);
 
return 0;
 }
@@ -1147,12 +1164,23 @@ static __maybe_unused int vdec_runtime_resume(struct 
device *dev)
struct venus_core *core = dev_get_drvdata(dev);
int ret;
 
-   if (core->res->hfi_version == HFI_VERSION_1XX)
+   if (IS_V1(core))
return 0;
 
-   writel(0, core->base + WRAPPER_VDEC_VCODEC_POWER_CONTROL);
+   if (IS_V3(core))
+   writel(0, core->base + WRAPPER_VDEC_VCODEC_POWER_CONTROL);
+   else if (IS_V4(core))
+   writel(0, core->base + WRAPPER_VCODEC0_MMCC_POWER_CONTROL);
+
ret = clk_prepare_enable(core->core0_clk);
-   writel(1, core->base + WRAPPER_VDEC_VCODEC_POWER_CONTROL);
+
+   if (IS_V4(core))
+   ret |= clk_prepare_enable(core->core0_bus_clk);
+
+   if (IS_V3(core))
+   writel(1, core->base + WRAPPER_VDEC_VCODEC_POWER_CONTROL);
+   else if (IS_V4(core))
+   writel(1, core->base + WRAPPER_VCODEC0_MMCC_POWER_CONTROL);
 
return ret;
 }
diff --git a/drivers/media/platform/qcom/venus/venc.c 
b/drivers/media/platform/qcom/venus/venc.c
index 947001170a77..bc8c2e7a8d2c 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -1225,12 +1225,18 @@ static int venc_probe(struct platform_device *pdev)
if (!core)
return -EPROBE_DEFER;
 
-   if (core->res->hfi_version == HFI_VERSION_3XX) {
+   if (IS_V3(core) || IS_V4(core)) {
core->core1_clk = devm_clk_get(dev, "core");
if (IS_ERR(core->core1_clk))
return PTR_ERR(core->core1_clk);
}
 
+   if (IS_V4(core)) {
+   core->core1_bus_clk = devm_clk_get(dev, "bus");
+   if (IS_ERR(core->core1_bus_clk))
+   return PTR_ERR(core->core1_bus_clk);
+   }
+
platform_set_drvdata(pdev, core);
 
vdev = video_device_alloc();
@@ -1276,12 +1282,23 @@ static __maybe_unused int venc_runtime_suspend(struct 
device *dev)
 {
struct venus_core 

[PATCH 11/28] venus: add common capability parser

[Stanimir Varbanov]

This adds common capability parser for all supported Venus
versions. Having it will help to enumerate better the supported
raw formars and codecs and also the capabilities for every
codec like max/min width/height, framerate, bitrate and so on.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/Makefile |   3 +-
 drivers/media/platform/qcom/venus/core.c   |  80 ++
 drivers/media/platform/qcom/venus/core.h   |  68 +++--
 drivers/media/platform/qcom/venus/hfi.c|   5 +-
 drivers/media/platform/qcom/venus/hfi_helper.h |  28 +-
 drivers/media/platform/qcom/venus/hfi_msgs.c   | 348 ++---
 drivers/media/platform/qcom/venus/hfi_parser.c | 294 +
 drivers/media/platform/qcom/venus/hfi_parser.h |  45 
 drivers/media/platform/qcom/venus/vdec.c   |  38 +--
 drivers/media/platform/qcom/venus/venc.c   |  52 ++--
 10 files changed, 524 insertions(+), 437 deletions(-)
 create mode 100644 drivers/media/platform/qcom/venus/hfi_parser.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi_parser.h

diff --git a/drivers/media/platform/qcom/venus/Makefile 
b/drivers/media/platform/qcom/venus/Makefile
index bfd4edf7c83f..b44b11b03e12 100644
--- a/drivers/media/platform/qcom/venus/Makefile
+++ b/drivers/media/platform/qcom/venus/Makefile
@@ -2,7 +2,8 @@
 # Makefile for Qualcomm Venus driver
 
 venus-core-objs += core.o helpers.o firmware.o \
-  hfi_venus.o hfi_msgs.o hfi_cmds.o hfi.o
+  hfi_venus.o hfi_msgs.o hfi_cmds.o hfi.o \
+  hfi_parser.o
 
 venus-dec-objs += vdec.o vdec_ctrls.o
 venus-enc-objs += venc.o venc_ctrls.o
diff --git a/drivers/media/platform/qcom/venus/core.c 
b/drivers/media/platform/qcom/venus/core.c
index 41eef376eb2d..1b72bfbb6297 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -152,6 +152,78 @@ static void venus_clks_disable(struct venus_core *core)
clk_disable_unprepare(core->clks[i]);
 }
 
+static u32 to_v4l2_codec_type(u32 codec)
+{
+   switch (codec) {
+   case HFI_VIDEO_CODEC_H264:
+   return V4L2_PIX_FMT_H264;
+   case HFI_VIDEO_CODEC_H263:
+   return V4L2_PIX_FMT_H263;
+   case HFI_VIDEO_CODEC_MPEG1:
+   return V4L2_PIX_FMT_MPEG1;
+   case HFI_VIDEO_CODEC_MPEG2:
+   return V4L2_PIX_FMT_MPEG2;
+   case HFI_VIDEO_CODEC_MPEG4:
+   return V4L2_PIX_FMT_MPEG4;
+   case HFI_VIDEO_CODEC_VC1:
+   return V4L2_PIX_FMT_VC1_ANNEX_G;
+   case HFI_VIDEO_CODEC_VP8:
+   return V4L2_PIX_FMT_VP8;
+   case HFI_VIDEO_CODEC_VP9:
+   return V4L2_PIX_FMT_VP9;
+   case HFI_VIDEO_CODEC_DIVX:
+   case HFI_VIDEO_CODEC_DIVX_311:
+   return V4L2_PIX_FMT_XVID;
+   default:
+   return 0;
+   }
+}
+
+static int venus_enumerate_codecs(struct venus_core *core, u32 type)
+{
+   const struct hfi_inst_ops dummy_ops = {};
+   struct venus_inst inst;
+   unsigned int i;
+   u32 codec, codecs;
+   int ret;
+
+   if (core->res->hfi_version != HFI_VERSION_1XX)
+   return 0;
+
+   memset(, 0, sizeof(inst));
+   mutex_init();
+   inst.core = core;
+   inst.session_type = type;
+   if (type == VIDC_SESSION_TYPE_DEC)
+   codecs = core->dec_codecs;
+   else
+   codecs = core->enc_codecs;
+
+   ret = hfi_session_create(, _ops);
+   if (ret)
+   return ret;
+
+   for (i = 0; i < MAX_CODEC_NUM; i++) {
+   codec = (1 << i) & codecs;
+   if (!codec)
+   continue;
+
+   ret = hfi_session_init(, to_v4l2_codec_type(codec));
+   if (ret)
+   goto done;
+
+   ret = hfi_session_deinit();
+   if (ret)
+   goto done;
+   }
+
+done:
+   hfi_session_destroy();
+   mutex_destroy();
+
+   return ret;
+}
+
 static int venus_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -219,6 +291,14 @@ static int venus_probe(struct platform_device *pdev)
if (ret)
goto err_venus_shutdown;
 
+   ret = venus_enumerate_codecs(core, VIDC_SESSION_TYPE_DEC);
+   if (ret)
+   goto err_venus_shutdown;
+
+   ret = venus_enumerate_codecs(core, VIDC_SESSION_TYPE_ENC);
+   if (ret)
+   goto err_venus_shutdown;
+
ret = v4l2_device_register(dev, >v4l2_dev);
if (ret)
goto err_core_deinit;
diff --git a/drivers/media/platform/qcom/venus/core.h 
b/drivers/media/platform/qcom/venus/core.h
index b5b9a84e9155..fe2d2b9e8af8 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -57,6 +57,29 @@ struct venus_format {
u32 type;
 };
 
+#define MAX_PLANES  

[PATCH 10/28] venus: vdec: call session_continue in insufficient event

[Stanimir Varbanov]

Call session_continue for Venus 4xx version even when the event
says that the buffer resources are not sufficient. Leaving a
comment with more information about the workaround.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/vdec.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/media/platform/qcom/venus/vdec.c 
b/drivers/media/platform/qcom/venus/vdec.c
index c45452634e7e..91c7384ff9c8 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -873,6 +873,14 @@ static void vdec_event_notify(struct venus_inst *inst, u32 
event,
 
dev_dbg(dev, "event not sufficient resources (%ux%u)\n",
data->width, data->height);
+   /*
+* Workaround: Even that the firmware send and event for
+* insufficient buffer resources it is safe to call
+* session_continue because actually the event says that
+* the number of capture buffers is lower.
+*/
+   if (IS_V4(core))
+   hfi_session_continue(inst);
break;
case HFI_EVENT_RELEASE_BUFFER_REFERENCE:
venus_helper_release_buf_ref(inst, data->tag);
-- 
2.14.1

[PATCH 04/28] venus: hfi_cmds: add set_properties for 4xx version

[Stanimir Varbanov]

Adds set_properties method to handle newer 4xx properties and
fall-back to 3xx for the rest.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/hfi_cmds.c | 64 +++-
 1 file changed, 63 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/qcom/venus/hfi_cmds.c 
b/drivers/media/platform/qcom/venus/hfi_cmds.c
index 1cfeb7743041..6bd287154796 100644
--- a/drivers/media/platform/qcom/venus/hfi_cmds.c
+++ b/drivers/media/platform/qcom/venus/hfi_cmds.c
@@ -1166,6 +1166,65 @@ pkt_session_set_property_3xx(struct 
hfi_session_set_property_pkt *pkt,
return ret;
 }
 
+static int
+pkt_session_set_property_4xx(struct hfi_session_set_property_pkt *pkt,
+void *cookie, u32 ptype, void *pdata)
+{
+   void *prop_data;
+   int ret = 0;
+
+   if (!pkt || !cookie || !pdata)
+   return -EINVAL;
+
+   prop_data = >data[1];
+
+   pkt->shdr.hdr.size = sizeof(*pkt);
+   pkt->shdr.hdr.pkt_type = HFI_CMD_SESSION_SET_PROPERTY;
+   pkt->shdr.session_id = hash32_ptr(cookie);
+   pkt->num_properties = 1;
+   pkt->data[0] = ptype;
+
+   /*
+* Any session set property which is different in 3XX packetization
+* should be added as a new case below. All unchanged session set
+* properties will be handled in the default case.
+*/
+   switch (ptype) {
+   case HFI_PROPERTY_PARAM_BUFFER_COUNT_ACTUAL: {
+   struct hfi_buffer_count_actual *in = pdata;
+   struct hfi_buffer_count_actual_4xx *count = prop_data;
+
+   count->count_actual = in->count_actual;
+   count->type = in->type;
+   count->count_min_host = in->count_actual;
+   pkt->shdr.hdr.size += sizeof(u32) + sizeof(*count);
+   break;
+   }
+   case HFI_PROPERTY_PARAM_WORK_MODE: {
+   struct hfi_video_work_mode *in = pdata, *wm = prop_data;
+
+   wm->video_work_mode = in->video_work_mode;
+   pkt->shdr.hdr.size += sizeof(u32) + sizeof(*wm);
+   break;
+   }
+   case HFI_PROPERTY_CONFIG_VIDEOCORES_USAGE: {
+   struct hfi_videocores_usage_type *in = pdata, *cu = prop_data;
+
+   cu->video_core_enable_mask = in->video_core_enable_mask;
+   pkt->shdr.hdr.size += sizeof(u32) + sizeof(*cu);
+   break;
+   }
+   case HFI_PROPERTY_CONFIG_VENC_MAX_BITRATE:
+   /* not implemented on Venus 4xx */
+   break;
+   default:
+   ret = pkt_session_set_property_3xx(pkt, cookie, ptype, pdata);
+   break;
+   }
+
+   return ret;
+}
+
 int pkt_session_get_property(struct hfi_session_get_property_pkt *pkt,
 void *cookie, u32 ptype)
 {
@@ -1181,7 +1240,10 @@ int pkt_session_set_property(struct 
hfi_session_set_property_pkt *pkt,
if (hfi_ver == HFI_VERSION_1XX)
return pkt_session_set_property_1x(pkt, cookie, ptype, pdata);
 
-   return pkt_session_set_property_3xx(pkt, cookie, ptype, pdata);
+   if (hfi_ver == HFI_VERSION_3XX)
+   return pkt_session_set_property_3xx(pkt, cookie, ptype, pdata);
+
+   return pkt_session_set_property_4xx(pkt, cookie, ptype, pdata);
 }
 
 void pkt_set_version(enum hfi_version version)
-- 
2.14.1

[PATCH 21/28] venus: helpers: extend set_num_bufs helper with one more argument

[Stanimir Varbanov]

Extend venus_helper_set_num_bufs() helper function with one more
argument to set number of output buffers for the secondary decoder
output.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/helpers.c | 16 ++--
 drivers/media/platform/qcom/venus/helpers.h |  3 ++-
 drivers/media/platform/qcom/venus/vdec.c|  2 +-
 drivers/media/platform/qcom/venus/venc.c|  2 +-
 4 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/helpers.c 
b/drivers/media/platform/qcom/venus/helpers.c
index adf8701a64bb..f04d16953b3a 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -513,7 +513,8 @@ int venus_helper_set_core_usage(struct venus_inst *inst, 
u32 usage)
 EXPORT_SYMBOL_GPL(venus_helper_set_core_usage);
 
 int venus_helper_set_num_bufs(struct venus_inst *inst, unsigned int input_bufs,
- unsigned int output_bufs)
+ unsigned int output_bufs,
+ unsigned int output2_bufs)
 {
u32 ptype = HFI_PROPERTY_PARAM_BUFFER_COUNT_ACTUAL;
struct hfi_buffer_count_actual buf_count;
@@ -529,7 +530,18 @@ int venus_helper_set_num_bufs(struct venus_inst *inst, 
unsigned int input_bufs,
buf_count.type = HFI_BUFFER_OUTPUT;
buf_count.count_actual = output_bufs;
 
-   return hfi_session_set_property(inst, ptype, _count);
+   ret = hfi_session_set_property(inst, ptype, _count);
+   if (ret)
+   return ret;
+
+   if (output2_bufs) {
+   buf_count.type = HFI_BUFFER_OUTPUT2;
+   buf_count.count_actual = output2_bufs;
+
+   ret = hfi_session_set_property(inst, ptype, _count);
+   }
+
+   return ret;
 }
 EXPORT_SYMBOL_GPL(venus_helper_set_num_bufs);
 
diff --git a/drivers/media/platform/qcom/venus/helpers.h 
b/drivers/media/platform/qcom/venus/helpers.h
index d5e727e1ecab..8ff4bd3ef958 100644
--- a/drivers/media/platform/qcom/venus/helpers.h
+++ b/drivers/media/platform/qcom/venus/helpers.h
@@ -41,7 +41,8 @@ int venus_helper_set_output_resolution(struct venus_inst 
*inst,
 int venus_helper_set_work_mode(struct venus_inst *inst, u32 mode);
 int venus_helper_set_core_usage(struct venus_inst *inst, u32 usage);
 int venus_helper_set_num_bufs(struct venus_inst *inst, unsigned int input_bufs,
- unsigned int output_bufs);
+ unsigned int output_bufs,
+ unsigned int output2_bufs);
 int venus_helper_set_raw_format(struct venus_inst *inst, u32 hfi_format,
u32 buftype);
 int venus_helper_set_color_format(struct venus_inst *inst, u32 fmt);
diff --git a/drivers/media/platform/qcom/venus/vdec.c 
b/drivers/media/platform/qcom/venus/vdec.c
index ceaf1a338eb3..8d188b11b85a 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -758,7 +758,7 @@ static int vdec_start_streaming(struct vb2_queue *q, 
unsigned int count)
goto deinit_sess;
 
ret = venus_helper_set_num_bufs(inst, inst->num_input_bufs,
-   VB2_MAX_FRAME);
+   VB2_MAX_FRAME, VB2_MAX_FRAME);
if (ret)
goto deinit_sess;
 
diff --git a/drivers/media/platform/qcom/venus/venc.c 
b/drivers/media/platform/qcom/venus/venc.c
index 3b3299bff1cd..c9c40d1ce7c6 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -963,7 +963,7 @@ static int venc_start_streaming(struct vb2_queue *q, 
unsigned int count)
goto deinit_sess;
 
ret = venus_helper_set_num_bufs(inst, inst->num_input_bufs,
-   inst->num_output_bufs);
+   inst->num_output_bufs, 0);
if (ret)
goto deinit_sess;
 
-- 
2.14.1

[PATCH 12/28] venus: helpers: make a commmon function for power_enable

[Stanimir Varbanov]

Make common function which will enable power when enabling/disabling
clocks and also covers Venus 3xx/4xx versions.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/helpers.c | 51 +
 drivers/media/platform/qcom/venus/helpers.h |  2 ++
 drivers/media/platform/qcom/venus/vdec.c| 25 --
 drivers/media/platform/qcom/venus/venc.c| 25 --
 4 files changed, 67 insertions(+), 36 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/helpers.c 
b/drivers/media/platform/qcom/venus/helpers.c
index d9065cc8a7d3..2b21f6ed7502 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -13,6 +13,7 @@
  *
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -24,6 +25,7 @@
 #include "core.h"
 #include "helpers.h"
 #include "hfi_helper.h"
+#include "hfi_venus_io.h"
 
 struct intbuf {
struct list_head list;
@@ -781,3 +783,52 @@ void venus_helper_init_instance(struct venus_inst *inst)
}
 }
 EXPORT_SYMBOL_GPL(venus_helper_init_instance);
+
+int venus_helper_power_enable(struct venus_core *core, u32 session_type,
+ bool enable)
+{
+   void __iomem *ctrl, *stat;
+   u32 val;
+   int ret;
+
+   if (!IS_V3(core) && !IS_V4(core))
+   return -EINVAL;
+
+   if (IS_V3(core)) {
+   if (session_type == VIDC_SESSION_TYPE_DEC)
+   ctrl = core->base + WRAPPER_VDEC_VCODEC_POWER_CONTROL;
+   else
+   ctrl = core->base + WRAPPER_VENC_VCODEC_POWER_CONTROL;
+   if (enable)
+   writel(0, ctrl);
+   else
+   writel(1, ctrl);
+
+   return 0;
+   }
+
+   if (session_type == VIDC_SESSION_TYPE_DEC) {
+   ctrl = core->base + WRAPPER_VCODEC0_MMCC_POWER_CONTROL;
+   stat = core->base + WRAPPER_VCODEC0_MMCC_POWER_STATUS;
+   } else {
+   ctrl = core->base + WRAPPER_VCODEC1_MMCC_POWER_CONTROL;
+   stat = core->base + WRAPPER_VCODEC1_MMCC_POWER_STATUS;
+   }
+
+   if (enable) {
+   writel(0, ctrl);
+
+   ret = readl_poll_timeout(stat, val, val & BIT(1), 1, 100);
+   if (ret)
+   return ret;
+   } else {
+   writel(1, ctrl);
+
+   ret = readl_poll_timeout(stat, val, !(val & BIT(1)), 1, 100);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(venus_helper_power_enable);
diff --git a/drivers/media/platform/qcom/venus/helpers.h 
b/drivers/media/platform/qcom/venus/helpers.h
index 971392be5df5..0e64aa95624a 100644
--- a/drivers/media/platform/qcom/venus/helpers.h
+++ b/drivers/media/platform/qcom/venus/helpers.h
@@ -43,4 +43,6 @@ int venus_helper_set_color_format(struct venus_inst *inst, 
u32 fmt);
 void venus_helper_acquire_buf_ref(struct vb2_v4l2_buffer *vbuf);
 void venus_helper_release_buf_ref(struct venus_inst *inst, unsigned int idx);
 void venus_helper_init_instance(struct venus_inst *inst);
+int venus_helper_power_enable(struct venus_core *core, u32 session_type,
+ bool enable);
 #endif
diff --git a/drivers/media/platform/qcom/venus/vdec.c 
b/drivers/media/platform/qcom/venus/vdec.c
index cd278a695899..0ddc2c4df934 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -1131,26 +1131,21 @@ static int vdec_remove(struct platform_device *pdev)
 static __maybe_unused int vdec_runtime_suspend(struct device *dev)
 {
struct venus_core *core = dev_get_drvdata(dev);
+   int ret;
 
if (IS_V1(core))
return 0;
 
-   if (IS_V3(core))
-   writel(0, core->base + WRAPPER_VDEC_VCODEC_POWER_CONTROL);
-   else if (IS_V4(core))
-   writel(0, core->base + WRAPPER_VCODEC0_MMCC_POWER_CONTROL);
+   ret = venus_helper_power_enable(core, VIDC_SESSION_TYPE_DEC, true);
 
if (IS_V4(core))
clk_disable_unprepare(core->core0_bus_clk);
 
clk_disable_unprepare(core->core0_clk);
 
-   if (IS_V3(core))
-   writel(1, core->base + WRAPPER_VDEC_VCODEC_POWER_CONTROL);
-   else if (IS_V4(core))
-   writel(1, core->base + WRAPPER_VCODEC0_MMCC_POWER_CONTROL);
+   ret |= venus_helper_power_enable(core, VIDC_SESSION_TYPE_DEC, false);
 
-   return 0;
+   return ret;
 }
 
 static __maybe_unused int vdec_runtime_resume(struct device *dev)
@@ -1161,20 +1156,14 @@ static __maybe_unused int vdec_runtime_resume(struct 
device *dev)
if (IS_V1(core))
return 0;
 
-   if (IS_V3(core))
-   writel(0, core->base + WRAPPER_VDEC_VCODEC_POWER_CONTROL);
-   else if (IS_V4(core))
-   writel(0, core->base + 

[PATCH 19/28] venus: helpers: add a new helper to set raw format

[Stanimir Varbanov]

The new helper will has one more argument for buffer type, that
way the decoder can configure the format on it's secondary
output.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/helpers.c | 52 ++---
 drivers/media/platform/qcom/venus/helpers.h |  2 ++
 2 files changed, 35 insertions(+), 19 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/helpers.c 
b/drivers/media/platform/qcom/venus/helpers.c
index 5512fbfdebb9..0d55604f7484 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -410,6 +410,20 @@ static int session_register_bufs(struct venus_inst *inst)
return ret;
 }
 
+static u32 to_hfi_raw_fmt(u32 v4l2_fmt)
+{
+   switch (v4l2_fmt) {
+   case V4L2_PIX_FMT_NV12:
+   return HFI_COLOR_FORMAT_NV12;
+   case V4L2_PIX_FMT_NV21:
+   return HFI_COLOR_FORMAT_NV21;
+   default:
+   break;
+   }
+
+   return 0;
+}
+
 int venus_helper_get_bufreq(struct venus_inst *inst, u32 type,
struct hfi_buffer_requirements *req)
 {
@@ -491,35 +505,35 @@ int venus_helper_set_num_bufs(struct venus_inst *inst, 
unsigned int input_bufs,
 }
 EXPORT_SYMBOL_GPL(venus_helper_set_num_bufs);
 
-int venus_helper_set_color_format(struct venus_inst *inst, u32 pixfmt)
+int venus_helper_set_raw_format(struct venus_inst *inst, u32 hfi_format,
+   u32 buftype)
 {
-   struct hfi_uncompressed_format_select fmt;
u32 ptype = HFI_PROPERTY_PARAM_UNCOMPRESSED_FORMAT_SELECT;
-   int ret;
+   struct hfi_uncompressed_format_select fmt;
+
+   fmt.buffer_type = buftype;
+   fmt.format = hfi_format;
+
+   return hfi_session_set_property(inst, ptype, );
+}
+EXPORT_SYMBOL_GPL(venus_helper_set_raw_format);
+
+int venus_helper_set_color_format(struct venus_inst *inst, u32 pixfmt)
+{
+   u32 hfi_format, buftype;
 
if (inst->session_type == VIDC_SESSION_TYPE_DEC)
-   fmt.buffer_type = HFI_BUFFER_OUTPUT;
+   buftype = HFI_BUFFER_OUTPUT;
else if (inst->session_type == VIDC_SESSION_TYPE_ENC)
-   fmt.buffer_type = HFI_BUFFER_INPUT;
+   buftype = HFI_BUFFER_INPUT;
else
return -EINVAL;
 
-   switch (pixfmt) {
-   case V4L2_PIX_FMT_NV12:
-   fmt.format = HFI_COLOR_FORMAT_NV12;
-   break;
-   case V4L2_PIX_FMT_NV21:
-   fmt.format = HFI_COLOR_FORMAT_NV21;
-   break;
-   default:
+   hfi_format = to_hfi_raw_fmt(pixfmt);
+   if (!hfi_format)
return -EINVAL;
-   }
 
-   ret = hfi_session_set_property(inst, ptype, );
-   if (ret)
-   return ret;
-
-   return 0;
+   return venus_helper_set_raw_format(inst, hfi_format, buftype);
 }
 EXPORT_SYMBOL_GPL(venus_helper_set_color_format);
 
diff --git a/drivers/media/platform/qcom/venus/helpers.h 
b/drivers/media/platform/qcom/venus/helpers.h
index 0de9989adcdb..79af7845efbd 100644
--- a/drivers/media/platform/qcom/venus/helpers.h
+++ b/drivers/media/platform/qcom/venus/helpers.h
@@ -40,6 +40,8 @@ int venus_helper_set_output_resolution(struct venus_inst 
*inst,
   u32 buftype);
 int venus_helper_set_num_bufs(struct venus_inst *inst, unsigned int input_bufs,
  unsigned int output_bufs);
+int venus_helper_set_raw_format(struct venus_inst *inst, u32 hfi_format,
+   u32 buftype);
 int venus_helper_set_color_format(struct venus_inst *inst, u32 fmt);
 int venus_helper_set_dyn_bufmode(struct venus_inst *inst);
 int venus_helper_set_bufsize(struct venus_inst *inst, u32 bufsize, u32 
buftype);
-- 
2.14.1

[PATCH 18/28] venus: helpers: add buffer type argument to a helper

[Stanimir Varbanov]

This adds one more function argument to pass buffer type to
set_output_resolution() helper function. That is a preparation
to support secondary decoder output.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/helpers.c | 5 +++--
 drivers/media/platform/qcom/venus/helpers.h | 3 ++-
 drivers/media/platform/qcom/venus/venc.c| 3 ++-
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/helpers.c 
b/drivers/media/platform/qcom/venus/helpers.c
index 94664a3ce3e2..5512fbfdebb9 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -456,12 +456,13 @@ int venus_helper_set_input_resolution(struct venus_inst 
*inst,
 EXPORT_SYMBOL_GPL(venus_helper_set_input_resolution);
 
 int venus_helper_set_output_resolution(struct venus_inst *inst,
-  unsigned int width, unsigned int height)
+  unsigned int width, unsigned int height,
+  u32 buftype)
 {
u32 ptype = HFI_PROPERTY_PARAM_FRAME_SIZE;
struct hfi_framesize fs;
 
-   fs.buffer_type = HFI_BUFFER_OUTPUT;
+   fs.buffer_type = buftype;
fs.width = width;
fs.height = height;
 
diff --git a/drivers/media/platform/qcom/venus/helpers.h 
b/drivers/media/platform/qcom/venus/helpers.h
index cd306bd8978f..0de9989adcdb 100644
--- a/drivers/media/platform/qcom/venus/helpers.h
+++ b/drivers/media/platform/qcom/venus/helpers.h
@@ -36,7 +36,8 @@ int venus_helper_get_bufreq(struct venus_inst *inst, u32 type,
 int venus_helper_set_input_resolution(struct venus_inst *inst,
  unsigned int width, unsigned int height);
 int venus_helper_set_output_resolution(struct venus_inst *inst,
-  unsigned int width, unsigned int height);
+  unsigned int width, unsigned int height,
+  u32 buftype);
 int venus_helper_set_num_bufs(struct venus_inst *inst, unsigned int input_bufs,
  unsigned int output_bufs);
 int venus_helper_set_color_format(struct venus_inst *inst, u32 fmt);
diff --git a/drivers/media/platform/qcom/venus/venc.c 
b/drivers/media/platform/qcom/venus/venc.c
index f87d891325ea..8970f14b3a82 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -795,7 +795,8 @@ static int venc_init_session(struct venus_inst *inst)
goto deinit;
 
ret = venus_helper_set_output_resolution(inst, inst->width,
-inst->height);
+inst->height,
+HFI_BUFFER_OUTPUT);
if (ret)
goto deinit;
 
-- 
2.14.1

[PATCH] omap3isp: ispstat: fix potential NULL pointer dereference

[Gustavo A. R. Silva]

new_conf is indirectly dereferenced before it is null checked, hence
there is a potential null pointer dereference.

Fix this by moving the pointer dereference after new_conf has been
properly null checked.

Addresses-Coverity-ID: 1468386 ("Dereference before null check")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/platform/omap3isp/ispstat.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/omap3isp/ispstat.c 
b/drivers/media/platform/omap3isp/ispstat.c
index 0b31f6c..549c7ab 100644
--- a/drivers/media/platform/omap3isp/ispstat.c
+++ b/drivers/media/platform/omap3isp/ispstat.c
@@ -522,8 +522,8 @@ int omap3isp_stat_config(struct ispstat *stat, void 
*new_conf)
 {
int ret;
unsigned long irqflags;
-   struct ispstat_generic_config *user_cfg = new_conf;
-   u32 buf_size = user_cfg->buf_size;
+   struct ispstat_generic_config *user_cfg;
+   u32 buf_size;
 
if (!new_conf) {
dev_dbg(stat->isp->dev, "%s: configuration is NULL\n",
@@ -531,6 +531,9 @@ int omap3isp_stat_config(struct ispstat *stat, void 
*new_conf)
return -EINVAL;
}
 
+   user_cfg = new_conf;
+   buf_size = user_cfg->buf_size;
+
mutex_lock(>ioctl_lock);
 
dev_dbg(stat->isp->dev,
-- 
2.7.4

[PATCH 17/28] venus: delete no longer used bufmode flag from instance

[Stanimir Varbanov]

Delete no longer used flag cap_bufs_mode_dynamic from instance
structure.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/core.h   | 2 --
 drivers/media/platform/qcom/venus/hfi_parser.c | 6 +-
 2 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/core.h 
b/drivers/media/platform/qcom/venus/core.h
index c46334454cd9..255292899204 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -249,7 +249,6 @@ struct venus_buffer {
  * @priv:  a private for HFI operations callbacks
  * @session_type:  the type of the session (decoder or encoder)
  * @hprop: a union used as a holder by get property
- * @cap_bufs_mode_dynamic: buffers allocation mode capability
  */
 struct venus_inst {
struct list_head list;
@@ -298,7 +297,6 @@ struct venus_inst {
const struct hfi_inst_ops *ops;
u32 session_type;
union hfi_get_property hprop;
-   bool cap_bufs_mode_dynamic;
 };
 
 #define IS_V1(core)((core)->res->hfi_version == HFI_VERSION_1XX)
diff --git a/drivers/media/platform/qcom/venus/hfi_parser.c 
b/drivers/media/platform/qcom/venus/hfi_parser.c
index 4b155997abbb..ac92fd347ce1 100644
--- a/drivers/media/platform/qcom/venus/hfi_parser.c
+++ b/drivers/media/platform/qcom/venus/hfi_parser.c
@@ -74,13 +74,9 @@ static void parse_alloc_mode(struct venus_core *core, struct 
venus_inst *inst,
 
while (num_entries--) {
if (mode->buffer_type == HFI_BUFFER_OUTPUT ||
-   mode->buffer_type == HFI_BUFFER_OUTPUT2) {
-   if (*type == HFI_BUFFER_MODE_DYNAMIC && inst)
-   inst->cap_bufs_mode_dynamic = true;
-
+   mode->buffer_type == HFI_BUFFER_OUTPUT2)
for_each_codec(core->caps, ARRAY_SIZE(core->caps),
   codecs, domain, fill_buf_mode, type, 1);
-   }
 
type++;
}
-- 
2.14.1

[PATCH 15/28] venus: add a helper function to set dynamic buffer mode

[Stanimir Varbanov]

Adds a new helper function to set dymaic buffer mode if it is
supported by current HFI version.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/helpers.c | 22 ++
 drivers/media/platform/qcom/venus/helpers.h |  1 +
 drivers/media/platform/qcom/venus/vdec.c| 15 +++
 3 files changed, 26 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/helpers.c 
b/drivers/media/platform/qcom/venus/helpers.c
index 1eda19adbf28..824ad4d2d064 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -522,6 +522,28 @@ int venus_helper_set_color_format(struct venus_inst *inst, 
u32 pixfmt)
 }
 EXPORT_SYMBOL_GPL(venus_helper_set_color_format);
 
+int venus_helper_set_dyn_bufmode(struct venus_inst *inst)
+{
+   u32 ptype = HFI_PROPERTY_PARAM_BUFFER_ALLOC_MODE;
+   struct hfi_buffer_alloc_mode mode;
+   int ret;
+
+   if (!is_dynamic_bufmode(inst))
+   return 0;
+
+   mode.type = HFI_BUFFER_OUTPUT;
+   mode.mode = HFI_BUFFER_MODE_DYNAMIC;
+
+   ret = hfi_session_set_property(inst, ptype, );
+   if (ret)
+   return ret;
+
+   mode.type = HFI_BUFFER_OUTPUT2;
+
+   return hfi_session_set_property(inst, ptype, );
+}
+EXPORT_SYMBOL_GPL(venus_helper_set_dyn_bufmode);
+
 static void delayed_process_buf_func(struct work_struct *work)
 {
struct venus_buffer *buf, *n;
diff --git a/drivers/media/platform/qcom/venus/helpers.h 
b/drivers/media/platform/qcom/venus/helpers.h
index 0e64aa95624a..52b961ed491e 100644
--- a/drivers/media/platform/qcom/venus/helpers.h
+++ b/drivers/media/platform/qcom/venus/helpers.h
@@ -40,6 +40,7 @@ int venus_helper_set_output_resolution(struct venus_inst 
*inst,
 int venus_helper_set_num_bufs(struct venus_inst *inst, unsigned int input_bufs,
  unsigned int output_bufs);
 int venus_helper_set_color_format(struct venus_inst *inst, u32 fmt);
+int venus_helper_set_dyn_bufmode(struct venus_inst *inst);
 void venus_helper_acquire_buf_ref(struct vb2_v4l2_buffer *vbuf);
 void venus_helper_release_buf_ref(struct venus_inst *inst, unsigned int idx);
 void venus_helper_init_instance(struct venus_inst *inst);
diff --git a/drivers/media/platform/qcom/venus/vdec.c 
b/drivers/media/platform/qcom/venus/vdec.c
index 0ddc2c4df934..1de9cc64cf2f 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -557,18 +557,9 @@ static int vdec_set_properties(struct venus_inst *inst)
return ret;
}
 
-   if (core->res->hfi_version == HFI_VERSION_3XX ||
-   inst->cap_bufs_mode_dynamic) {
-   struct hfi_buffer_alloc_mode mode;
-
-   ptype = HFI_PROPERTY_PARAM_BUFFER_ALLOC_MODE;
-   mode.type = HFI_BUFFER_OUTPUT;
-   mode.mode = HFI_BUFFER_MODE_DYNAMIC;
-
-   ret = hfi_session_set_property(inst, ptype, );
-   if (ret)
-   return ret;
-   }
+   ret = venus_helper_set_dyn_bufmode(inst);
+   if (ret)
+   return ret;
 
if (ctr->post_loop_deb_mode) {
ptype = HFI_PROPERTY_CONFIG_VDEC_POST_LOOP_DEBLOCKER;
-- 
2.14.1

[PATCH 14/28] venus: helpers: rename a helper function and use buffer mode from caps

[Stanimir Varbanov]

Rename is_reg_unreg_needed() to better name is_dynamic_bufmode() and
use buffer mode from enumerated per codec capabilities.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/helpers.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/helpers.c 
b/drivers/media/platform/qcom/venus/helpers.c
index 2b21f6ed7502..1eda19adbf28 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -354,18 +354,19 @@ session_process_buf(struct venus_inst *inst, struct 
vb2_v4l2_buffer *vbuf)
return 0;
 }
 
-static inline int is_reg_unreg_needed(struct venus_inst *inst)
+static inline int is_dynamic_bufmode(struct venus_inst *inst)
 {
-   if (inst->session_type == VIDC_SESSION_TYPE_DEC &&
-   inst->core->res->hfi_version == HFI_VERSION_3XX)
-   return 0;
+   struct venus_core *core = inst->core;
+   struct venus_caps *caps;
 
-   if (inst->session_type == VIDC_SESSION_TYPE_DEC &&
-   inst->cap_bufs_mode_dynamic &&
-   inst->core->res->hfi_version == HFI_VERSION_1XX)
+   caps = venus_caps_by_codec(core, inst->hfi_codec, inst->session_type);
+   if (!caps)
return 0;
 
-   return 1;
+   if (caps->cap_bufs_mode_dynamic)
+   return 1;
+
+   return 0;
 }
 
 static int session_unregister_bufs(struct venus_inst *inst)
@@ -374,7 +375,7 @@ static int session_unregister_bufs(struct venus_inst *inst)
struct hfi_buffer_desc bd;
int ret = 0;
 
-   if (!is_reg_unreg_needed(inst))
+   if (is_dynamic_bufmode(inst))
return 0;
 
list_for_each_entry_safe(buf, n, >registeredbufs, reg_list) {
@@ -394,7 +395,7 @@ static int session_register_bufs(struct venus_inst *inst)
struct venus_buffer *buf;
int ret = 0;
 
-   if (!is_reg_unreg_needed(inst))
+   if (is_dynamic_bufmode(inst))
return 0;
 
list_for_each_entry(buf, >registeredbufs, reg_list) {
-- 
2.14.1

[PATCH 13/28] venus: core: delete not used flag for buffer mode

[Stanimir Varbanov]

Delete not used flag for capture buffer allocation mode.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/core.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/core.h 
b/drivers/media/platform/qcom/venus/core.h
index fe2d2b9e8af8..c46334454cd9 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -249,7 +249,6 @@ struct venus_buffer {
  * @priv:  a private for HFI operations callbacks
  * @session_type:  the type of the session (decoder or encoder)
  * @hprop: a union used as a holder by get property
- * @cap_bufs_mode_static:  buffers allocation mode capability
  * @cap_bufs_mode_dynamic: buffers allocation mode capability
  */
 struct venus_inst {
@@ -299,7 +298,6 @@ struct venus_inst {
const struct hfi_inst_ops *ops;
u32 session_type;
union hfi_get_property hprop;
-   bool cap_bufs_mode_static;
bool cap_bufs_mode_dynamic;
 };
 
-- 
2.14.1

Re: [PATCH v2 2/2] media: Add a driver for the ov7251 camera sensor

[Todor Tomov]

Hi Sakari,

On 17.04.2018 23:10, Sakari Ailus wrote:
> Hi Todor,
> 
> On Tue, Apr 17, 2018 at 06:32:07PM +0300, Todor Tomov wrote:
> ...
 +static int ov7251_regulators_enable(struct ov7251 *ov7251)
 +{
 +  int ret;
 +
 +  ret = regulator_enable(ov7251->io_regulator);
>>>
>>> How about regulator_bulk_enable() here, and bulk_disable below?
>>
>> I'm not using the bulk API because usually there is a power up
>> sequence and intervals that must be followed. For this sensor
>> the only constraint is that core regulator must be enabled
>> after io regulator. But the bulk API doesn't guarantee the
>> order.
> 
> Could you add a comment explaining this? Otherwise it won't take long until
> someone "fixes" the code.

Sure :D
I'm adding a comment.

> 
> ...
> 
 +static int ov7251_read_reg(struct ov7251 *ov7251, u16 reg, u8 *val)
 +{
 +  u8 regbuf[2];
 +  int ret;
 +
 +  regbuf[0] = reg >> 8;
 +  regbuf[1] = reg & 0xff;
 +
 +  ret = i2c_master_send(ov7251->i2c_client, regbuf, 2);
 +  if (ret < 0) {
 +  dev_err(ov7251->dev, "%s: write reg error %d: reg=%x\n",
 +  __func__, ret, reg);
 +  return ret;
 +  }
 +
 +  ret = i2c_master_recv(ov7251->i2c_client, val, 1);
 +  if (ret < 0) {
 +  dev_err(ov7251->dev, "%s: read reg error %d: reg=%x\n",
 +  __func__, ret, reg);
 +  return ret;
 +  }
 +
 +  return 0;
 +}
 +
 +static int ov7251_set_exposure(struct ov7251 *ov7251, s32 exposure)
 +{
 +  int ret;
 +
 +  ret = ov7251_write_reg(ov7251, OV7251_AEC_EXPO_0,
 + (exposure & 0xf000) >> 12);
 +  if (ret < 0)
 +  return ret;
 +
 +  ret = ov7251_write_reg(ov7251, OV7251_AEC_EXPO_1,
 + (exposure & 0x0ff0) >> 4);
 +  if (ret < 0)
 +  return ret;
 +
 +  return ov7251_write_reg(ov7251, OV7251_AEC_EXPO_2,
 +  (exposure & 0x000f) << 4);
>>>
>>> It's not a good idea to access multi-octet registers separately. Depending
>>> on the hardware implementation, the hardware could latch the value in the
>>> middle of an update. This is only an issue during streaming in practice
>>> though.
>>
>> Good point. The sensor has a group write functionality which can be used
>> to solve this but in general is intended
>> to apply a group of exposure and gain settings in the same frame. However
>> it seems to me that is not possible to use this functionality efficiently
>> with the currently available user controls. The group write is configured
>> using an id for a group of commands. So if we configure exposure and gain
>> separately (a group for each):
>> - if the driver uses same group id for exposure and gain, if both controls
>>   are received in one frame the second will overwrite the first (the
>>   first will not be applied);
>> - if the driver uses different group id for exposure and gain, it will not
>>   be possible for the user to change exposure and gain in the same frame
>>   (as some exposure algorithms do) and it will lead again to frames with
>>   "incorrect" brightness.
>>
>> To do this correctly we will have to extend the API to be able to apply
>> exposure and gain "atomically":
>> - a single user control which will set both exposure and gain and it will
>>   guarantee that they will be applied in the same frame;
>> - some kind of: begin, set exposure, set gain, end, launch -API
>>
>> What do you think?
>>
>> Actually, I'm a little bit surprised that I didn't find anything
>> like this already. And there are already a number of sensor drivers
>> which update more than one register to set exposure.
> 
> The latter of the two would be preferred as it isn't limited to exposure
> and gain only. Still, you could address the problem for this driver by
> simply writing the register in a single transaction.

Thanks for suggestion. I've tried the single transaction, I will send the
next version of the driver shortly.

-- 
Best regards,
Todor Tomov

[PATCH 27/28] venus: add sdm845 compatible and resource data

[Stanimir Varbanov]

This adds sdm845 DT compatible string with it's resource
data table.

Cc: devicet...@vger.kernel.org
Signed-off-by: Stanimir Varbanov 
---
 .../devicetree/bindings/media/qcom,venus.txt   |  1 +
 drivers/media/platform/qcom/venus/core.c   | 22 ++
 2 files changed, 23 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt 
b/Documentation/devicetree/bindings/media/qcom,venus.txt
index 2693449daf73..00d0d1bf7647 100644
--- a/Documentation/devicetree/bindings/media/qcom,venus.txt
+++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
@@ -6,6 +6,7 @@
Definition: Value should contain one of:
- "qcom,msm8916-venus"
- "qcom,msm8996-venus"
+   - "qcom,sdm845-venus"
 - reg:
Usage: required
Value type: 
diff --git a/drivers/media/platform/qcom/venus/core.c 
b/drivers/media/platform/qcom/venus/core.c
index 1b72bfbb6297..13084880cc42 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -445,9 +445,31 @@ static const struct venus_resources msm8996_res = {
.fwname = "qcom/venus-4.2/venus.mdt",
 };
 
+static const struct freq_tbl sdm845_freq_table[] = {
+   { 1944000, 38000 }, /* 4k UHD @ 60 */
+   {  972000, 32000 }, /* 4k UHD @ 30 */
+   {  489600, 2 }, /* 1080p @ 60 */
+   {  244800, 1 }, /* 1080p @ 30 */
+};
+
+static const struct venus_resources sdm845_res = {
+   .freq_tbl = sdm845_freq_table,
+   .freq_tbl_size = ARRAY_SIZE(sdm845_freq_table),
+   .clks = {"core", "iface", "bus" },
+   .clks_num = 3,
+   .max_load = 2563200,
+   .hfi_version = HFI_VERSION_4XX,
+   .vmem_id = VIDC_RESOURCE_NONE,
+   .vmem_size = 0,
+   .vmem_addr = 0,
+   .dma_mask = 0xe000 - 1,
+   .fwname = "qcom/venus-5.2/venus.mdt",
+};
+
 static const struct of_device_id venus_dt_match[] = {
{ .compatible = "qcom,msm8916-venus", .data = _res, },
{ .compatible = "qcom,msm8996-venus", .data = _res, },
+   { .compatible = "qcom,sdm845-venus", .data = _res, },
{ }
 };
 MODULE_DEVICE_TABLE(of, venus_dt_match);
-- 
2.14.1

[PATCH 20/28] venus: helpers,vdec,venc: add helpers to set work mode and core usage

[Stanimir Varbanov]

These are new properties applicable to Venus version 4xx. Add the
helpers and call them from decoder and encoder drivers.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/helpers.c | 28 
 drivers/media/platform/qcom/venus/helpers.h |  2 ++
 drivers/media/platform/qcom/venus/vdec.c|  8 
 drivers/media/platform/qcom/venus/venc.c|  8 
 4 files changed, 46 insertions(+)

diff --git a/drivers/media/platform/qcom/venus/helpers.c 
b/drivers/media/platform/qcom/venus/helpers.c
index 0d55604f7484..adf8701a64bb 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -484,6 +484,34 @@ int venus_helper_set_output_resolution(struct venus_inst 
*inst,
 }
 EXPORT_SYMBOL_GPL(venus_helper_set_output_resolution);
 
+int venus_helper_set_work_mode(struct venus_inst *inst, u32 mode)
+{
+   u32 ptype = HFI_PROPERTY_PARAM_WORK_MODE;
+   struct hfi_video_work_mode wm;
+
+   if (!IS_V4(inst->core))
+   return 0;
+
+   wm.video_work_mode = mode;
+
+   return hfi_session_set_property(inst, ptype, );
+}
+EXPORT_SYMBOL_GPL(venus_helper_set_work_mode);
+
+int venus_helper_set_core_usage(struct venus_inst *inst, u32 usage)
+{
+   u32 ptype = HFI_PROPERTY_CONFIG_VIDEOCORES_USAGE;
+   struct hfi_videocores_usage_type cu;
+
+   if (!IS_V4(inst->core))
+   return 0;
+
+   cu.video_core_enable_mask = usage;
+
+   return hfi_session_set_property(inst, ptype, );
+}
+EXPORT_SYMBOL_GPL(venus_helper_set_core_usage);
+
 int venus_helper_set_num_bufs(struct venus_inst *inst, unsigned int input_bufs,
  unsigned int output_bufs)
 {
diff --git a/drivers/media/platform/qcom/venus/helpers.h 
b/drivers/media/platform/qcom/venus/helpers.h
index 79af7845efbd..d5e727e1ecab 100644
--- a/drivers/media/platform/qcom/venus/helpers.h
+++ b/drivers/media/platform/qcom/venus/helpers.h
@@ -38,6 +38,8 @@ int venus_helper_set_input_resolution(struct venus_inst *inst,
 int venus_helper_set_output_resolution(struct venus_inst *inst,
   unsigned int width, unsigned int height,
   u32 buftype);
+int venus_helper_set_work_mode(struct venus_inst *inst, u32 mode);
+int venus_helper_set_core_usage(struct venus_inst *inst, u32 usage);
 int venus_helper_set_num_bufs(struct venus_inst *inst, unsigned int input_bufs,
  unsigned int output_bufs);
 int venus_helper_set_raw_format(struct venus_inst *inst, u32 hfi_format,
diff --git a/drivers/media/platform/qcom/venus/vdec.c 
b/drivers/media/platform/qcom/venus/vdec.c
index b43607dee4fe..ceaf1a338eb3 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -550,6 +550,14 @@ static int vdec_set_properties(struct venus_inst *inst)
u32 ptype;
int ret;
 
+   ret = venus_helper_set_work_mode(inst, VIDC_WORK_MODE_2);
+   if (ret)
+   return ret;
+
+   ret = venus_helper_set_core_usage(inst, VIDC_CORE_ID_1);
+   if (ret)
+   return ret;
+
if (core->res->hfi_version == HFI_VERSION_1XX) {
ptype = HFI_PROPERTY_PARAM_VDEC_CONTINUE_DATA_TRANSFER;
ret = hfi_session_set_property(inst, ptype, );
diff --git a/drivers/media/platform/qcom/venus/venc.c 
b/drivers/media/platform/qcom/venus/venc.c
index 8970f14b3a82..3b3299bff1cd 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -643,6 +643,14 @@ static int venc_set_properties(struct venus_inst *inst)
u32 ptype, rate_control, bitrate, profile = 0, level = 0;
int ret;
 
+   ret = venus_helper_set_work_mode(inst, VIDC_WORK_MODE_2);
+   if (ret)
+   return ret;
+
+   ret = venus_helper_set_core_usage(inst, VIDC_CORE_ID_2);
+   if (ret)
+   return ret;
+
ptype = HFI_PROPERTY_CONFIG_FRAME_RATE;
frate.buffer_type = HFI_BUFFER_OUTPUT;
frate.framerate = inst->fps * (1 << 16);
-- 
2.14.1

[PATCH 26/28] venus: implementing multi-stream support

[Stanimir Varbanov]

This is implementing a multi-stream decoder support. The multi
stream gives an option to use the secondary decoder output
with different raw format (or the same in case of crop).

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/core.h|   1 +
 drivers/media/platform/qcom/venus/helpers.c | 204 +++-
 drivers/media/platform/qcom/venus/helpers.h |   6 +
 drivers/media/platform/qcom/venus/vdec.c|  91 -
 drivers/media/platform/qcom/venus/venc.c|   1 +
 5 files changed, 299 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/core.h 
b/drivers/media/platform/qcom/venus/core.h
index 4d6c05f156c4..85e66e2dd672 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -259,6 +259,7 @@ struct venus_inst {
struct list_head list;
struct mutex lock;
struct venus_core *core;
+   struct list_head dpbbufs;
struct list_head internalbufs;
struct list_head registeredbufs;
struct list_head delayed_process;
diff --git a/drivers/media/platform/qcom/venus/helpers.c 
b/drivers/media/platform/qcom/venus/helpers.c
index ed569705ecac..87dcf9973e6f 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -85,6 +85,112 @@ bool venus_helper_check_codec(struct venus_inst *inst, u32 
v4l2_pixfmt)
 }
 EXPORT_SYMBOL_GPL(venus_helper_check_codec);
 
+static int venus_helper_queue_dpb_bufs(struct venus_inst *inst)
+{
+   struct intbuf *buf;
+   int ret = 0;
+
+   if (list_empty(>dpbbufs))
+   return 0;
+
+   list_for_each_entry(buf, >dpbbufs, list) {
+   struct hfi_frame_data fdata;
+
+   memset(, 0, sizeof(fdata));
+   fdata.alloc_len = buf->size;
+   fdata.device_addr = buf->da;
+   fdata.buffer_type = buf->type;
+
+   ret = hfi_session_process_buf(inst, );
+   if (ret)
+   goto fail;
+   }
+
+fail:
+   return ret;
+}
+
+int venus_helper_free_dpb_bufs(struct venus_inst *inst)
+{
+   struct intbuf *buf, *n;
+
+   if (list_empty(>dpbbufs))
+   return 0;
+
+   list_for_each_entry_safe(buf, n, >dpbbufs, list) {
+   list_del_init(>list);
+   dma_free_attrs(inst->core->dev, buf->size, buf->va, buf->da,
+  buf->attrs);
+   kfree(buf);
+   }
+
+   INIT_LIST_HEAD(>dpbbufs);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(venus_helper_free_dpb_bufs);
+
+int venus_helper_alloc_dpb_bufs(struct venus_inst *inst)
+{
+   struct venus_core *core = inst->core;
+   struct device *dev = core->dev;
+   enum hfi_version ver = core->res->hfi_version;
+   struct hfi_buffer_requirements bufreq;
+   u32 buftype = inst->dpb_buftype;
+   unsigned int dpb_size = 0;
+   struct intbuf *buf;
+   unsigned int i;
+   u32 count;
+   int ret;
+
+   /* no need to allocate dpb buffers */
+   if (!inst->dpb_fmt)
+   return 0;
+
+   if (inst->dpb_buftype == HFI_BUFFER_OUTPUT)
+   dpb_size = inst->output_buf_size;
+   else if (inst->dpb_buftype == HFI_BUFFER_OUTPUT2)
+   dpb_size = inst->output2_buf_size;
+
+   if (!dpb_size)
+   return 0;
+
+   ret = venus_helper_get_bufreq(inst, buftype, );
+   if (ret)
+   return ret;
+
+   count = HFI_BUFREQ_COUNT_MIN(, ver);
+
+   for (i = 0; i < count; i++) {
+   buf = kzalloc(sizeof(*buf), GFP_KERNEL);
+   if (!buf) {
+   ret = -ENOMEM;
+   goto fail;
+   }
+
+   buf->type = buftype;
+   buf->size = dpb_size;
+   buf->attrs = DMA_ATTR_WRITE_COMBINE |
+DMA_ATTR_NO_KERNEL_MAPPING;
+   buf->va = dma_alloc_attrs(dev, buf->size, >da, GFP_KERNEL,
+ buf->attrs);
+   if (!buf->va) {
+   kfree(buf);
+   ret = -ENOMEM;
+   goto fail;
+   }
+
+   list_add_tail(>list, >dpbbufs);
+   }
+
+   return 0;
+
+fail:
+   venus_helper_free_dpb_bufs(inst);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(venus_helper_alloc_dpb_bufs);
+
 static int intbufs_set_buffer(struct venus_inst *inst, u32 type)
 {
struct venus_core *core = inst->core;
@@ -342,7 +448,10 @@ session_process_buf(struct venus_inst *inst, struct 
vb2_v4l2_buffer *vbuf)
if (vbuf->flags & V4L2_BUF_FLAG_LAST || !fdata.filled_len)
fdata.flags |= HFI_BUFFERFLAG_EOS;
} else if (type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
-   fdata.buffer_type = HFI_BUFFER_OUTPUT;
+   if (inst->session_type == 

[PATCH 23/28] venus: vdec: get required input buffers as well

[Stanimir Varbanov]

Rework and rename vdec_cap_num_buffers() to get the number of
input buffers too.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/vdec.c | 41 +++-
 1 file changed, 24 insertions(+), 17 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/vdec.c 
b/drivers/media/platform/qcom/venus/vdec.c
index 8d188b11b85a..6ed9b7c4bd6e 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -603,19 +603,32 @@ static int vdec_init_session(struct venus_inst *inst)
return ret;
 }
 
-static int vdec_cap_num_buffers(struct venus_inst *inst, unsigned int *num)
+static int vdec_num_buffers(struct venus_inst *inst, unsigned int *in_num,
+   unsigned int *out_num)
 {
+   enum hfi_version ver = inst->core->res->hfi_version;
struct hfi_buffer_requirements bufreq;
int ret;
 
+   *in_num = *out_num = 0;
+
ret = vdec_init_session(inst);
if (ret)
return ret;
 
+   ret = venus_helper_get_bufreq(inst, HFI_BUFFER_INPUT, );
+   if (ret)
+   goto deinit;
+
+   *in_num = HFI_BUFREQ_COUNT_MIN(, ver);
+
ret = venus_helper_get_bufreq(inst, HFI_BUFFER_OUTPUT, );
+   if (ret)
+   goto deinit;
 
-   *num = bufreq.count_actual;
+   *out_num = HFI_BUFREQ_COUNT_MIN(, ver);
 
+deinit:
hfi_session_deinit(inst);
 
return ret;
@@ -626,7 +639,7 @@ static int vdec_queue_setup(struct vb2_queue *q,
unsigned int sizes[], struct device *alloc_devs[])
 {
struct venus_inst *inst = vb2_get_drv_priv(q);
-   unsigned int p, num;
+   unsigned int p, in_num, out_num;
int ret = 0;
 
if (*num_planes) {
@@ -649,35 +662,29 @@ static int vdec_queue_setup(struct vb2_queue *q,
return 0;
}
 
+   ret = vdec_num_buffers(inst, _num, _num);
+   if (ret)
+   return ret;
+
switch (q->type) {
case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
*num_planes = inst->fmt_out->num_planes;
sizes[0] = get_framesize_compressed(inst->out_width,
inst->out_height);
inst->input_buf_size = sizes[0];
+   *num_buffers = max(*num_buffers, in_num);
inst->num_input_bufs = *num_buffers;
-
-   ret = vdec_cap_num_buffers(inst, );
-   if (ret)
-   break;
-
-   inst->num_output_bufs = num;
+   inst->num_output_bufs = out_num;
break;
case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
*num_planes = inst->fmt_cap->num_planes;
 
-   ret = vdec_cap_num_buffers(inst, );
-   if (ret)
-   break;
-
-   *num_buffers = max(*num_buffers, num);
-
for (p = 0; p < *num_planes; p++)
sizes[p] = get_framesize_uncompressed(p, inst->width,
  inst->height);
-
-   inst->num_output_bufs = *num_buffers;
inst->output_buf_size = sizes[0];
+   *num_buffers = max(*num_buffers, out_num);
+   inst->num_output_bufs = *num_buffers;
break;
default:
ret = -EINVAL;
-- 
2.14.1

[PATCH 22/28] venus: helpers: add a helper to return opb buffer sizes

[Stanimir Varbanov]

Add a helper function to return current output picture buffer size.
OPB sizes can vary depending on the selected decoder output(s).

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/core.h| 10 ++
 drivers/media/platform/qcom/venus/helpers.c | 15 +++
 drivers/media/platform/qcom/venus/helpers.h |  1 +
 3 files changed, 26 insertions(+)

diff --git a/drivers/media/platform/qcom/venus/core.h 
b/drivers/media/platform/qcom/venus/core.h
index 255292899204..4d6c05f156c4 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -234,6 +234,11 @@ struct venus_buffer {
  * @num_output_bufs:   holds number of output buffers
  * @input_buf_size holds input buffer size
  * @output_buf_size:   holds output buffer size
+ * @output2_buf_size:  holds secondary decoder output buffer size
+ * @dpb_buftype:   decoded picture buffer type
+ * @dpb_fmt:   decodec picture buffre raw format
+ * @opb_buftype:   output picture buffer type
+ * @opb_fmt:   output picture buffer raw format
  * @reconfig:  a flag raised by decoder when the stream resolution changed
  * @reconfig_width:holds the new width
  * @reconfig_height:   holds the new height
@@ -282,6 +287,11 @@ struct venus_inst {
unsigned int num_output_bufs;
unsigned int input_buf_size;
unsigned int output_buf_size;
+   unsigned int output2_buf_size;
+   u32 dpb_buftype;
+   u32 dpb_fmt;
+   u32 opb_buftype;
+   u32 opb_fmt;
bool reconfig;
u32 reconfig_width;
u32 reconfig_height;
diff --git a/drivers/media/platform/qcom/venus/helpers.c 
b/drivers/media/platform/qcom/venus/helpers.c
index f04d16953b3a..f0a0fca60c76 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -611,6 +611,21 @@ int venus_helper_set_bufsize(struct venus_inst *inst, u32 
bufsize, u32 buftype)
 }
 EXPORT_SYMBOL_GPL(venus_helper_set_bufsize);
 
+unsigned int venus_helper_get_opb_size(struct venus_inst *inst)
+{
+   /* the encoder has only one output */
+   if (inst->session_type == VIDC_SESSION_TYPE_ENC)
+   return inst->output_buf_size;
+
+   if (inst->opb_buftype == HFI_BUFFER_OUTPUT)
+   return inst->output_buf_size;
+   else if (inst->opb_buftype == HFI_BUFFER_OUTPUT2)
+   return inst->output2_buf_size;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(venus_helper_get_opb_size);
+
 static void delayed_process_buf_func(struct work_struct *work)
 {
struct venus_buffer *buf, *n;
diff --git a/drivers/media/platform/qcom/venus/helpers.h 
b/drivers/media/platform/qcom/venus/helpers.h
index 8ff4bd3ef958..92be45894a69 100644
--- a/drivers/media/platform/qcom/venus/helpers.h
+++ b/drivers/media/platform/qcom/venus/helpers.h
@@ -48,6 +48,7 @@ int venus_helper_set_raw_format(struct venus_inst *inst, u32 
hfi_format,
 int venus_helper_set_color_format(struct venus_inst *inst, u32 fmt);
 int venus_helper_set_dyn_bufmode(struct venus_inst *inst);
 int venus_helper_set_bufsize(struct venus_inst *inst, u32 bufsize, u32 
buftype);
+unsigned int venus_helper_get_opb_size(struct venus_inst *inst);
 void venus_helper_acquire_buf_ref(struct vb2_v4l2_buffer *vbuf);
 void venus_helper_release_buf_ref(struct venus_inst *inst, unsigned int idx);
 void venus_helper_init_instance(struct venus_inst *inst);
-- 
2.14.1

[PATCH 24/28] venus: vdec: new function for output configuration

[Stanimir Varbanov]

Make a new function vdec_output_conf() for decoder output
configuration. vdec_output_conf() will set properties via
HFI interface related to the output configuration, and
keep vdec_set_properties() which will set properties
related to decoding parameters.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/vdec.c | 35 ++--
 1 file changed, 20 insertions(+), 15 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/vdec.c 
b/drivers/media/platform/qcom/venus/vdec.c
index 6ed9b7c4bd6e..ced3330c396a 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -545,6 +545,23 @@ static const struct v4l2_ioctl_ops vdec_ioctl_ops = {
 static int vdec_set_properties(struct venus_inst *inst)
 {
struct vdec_controls *ctr = >controls.dec;
+   struct hfi_enable en = { .enable = 1 };
+   u32 ptype;
+   int ret;
+
+   if (ctr->post_loop_deb_mode) {
+   ptype = HFI_PROPERTY_CONFIG_VDEC_POST_LOOP_DEBLOCKER;
+   en.enable = 1;
+   ret = hfi_session_set_property(inst, ptype, );
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+static int vdec_output_conf(struct venus_inst *inst)
+{
struct venus_core *core = inst->core;
struct hfi_enable en = { .enable = 1 };
u32 ptype;
@@ -569,14 +586,6 @@ static int vdec_set_properties(struct venus_inst *inst)
if (ret)
return ret;
 
-   if (ctr->post_loop_deb_mode) {
-   ptype = HFI_PROPERTY_CONFIG_VDEC_POST_LOOP_DEBLOCKER;
-   en.enable = 1;
-   ret = hfi_session_set_property(inst, ptype, );
-   if (ret)
-   return ret;
-   }
-
return 0;
 }
 
@@ -724,7 +733,6 @@ static int vdec_verify_conf(struct venus_inst *inst)
 static int vdec_start_streaming(struct vb2_queue *q, unsigned int count)
 {
struct venus_inst *inst = vb2_get_drv_priv(q);
-   struct venus_core *core = inst->core;
int ret;
 
mutex_lock(>lock);
@@ -753,12 +761,9 @@ static int vdec_start_streaming(struct vb2_queue *q, 
unsigned int count)
if (ret)
goto deinit_sess;
 
-   if (core->res->hfi_version == HFI_VERSION_3XX) {
-   ret = venus_helper_set_bufsize(inst, inst->output_buf_size,
-  HFI_BUFFER_OUTPUT);
-   if (ret)
-   goto deinit_sess;
-   }
+   ret = vdec_output_conf(inst);
+   if (ret)
+   goto deinit_sess;
 
ret = vdec_verify_conf(inst);
if (ret)
-- 
2.14.1

[PATCH 25/28] venus: move frame size calculations in common place

[Stanimir Varbanov]

move calculations of raw and compressed in a common helper
and make it identical for encoder and decoder.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/helpers.c | 98 +
 drivers/media/platform/qcom/venus/helpers.h |  2 +
 drivers/media/platform/qcom/venus/vdec.c| 54 
 drivers/media/platform/qcom/venus/venc.c| 56 -
 4 files changed, 126 insertions(+), 84 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/helpers.c 
b/drivers/media/platform/qcom/venus/helpers.c
index f0a0fca60c76..ed569705ecac 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -455,6 +455,104 @@ int venus_helper_get_bufreq(struct venus_inst *inst, u32 
type,
 }
 EXPORT_SYMBOL_GPL(venus_helper_get_bufreq);
 
+static u32 get_framesize_raw_nv12(u32 width, u32 height)
+{
+   u32 y_stride, uv_stride, y_plane;
+   u32 y_sclines, uv_sclines, uv_plane;
+   u32 size;
+
+   y_stride = ALIGN(width, 128);
+   uv_stride = ALIGN(width, 128);
+   y_sclines = ALIGN(height, 32);
+   uv_sclines = ALIGN(((height + 1) >> 1), 16);
+
+   y_plane = y_stride * y_sclines;
+   uv_plane = uv_stride * uv_sclines + SZ_4K;
+   size = y_plane + uv_plane + SZ_8K;
+
+   return ALIGN(size, SZ_4K);
+}
+
+static u32 get_framesize_raw_nv12_ubwc(u32 width, u32 height)
+{
+   u32 y_meta_stride, y_meta_plane;
+   u32 y_stride, y_plane;
+   u32 uv_meta_stride, uv_meta_plane;
+   u32 uv_stride, uv_plane;
+   u32 extradata = SZ_16K;
+
+   y_meta_stride = ALIGN(DIV_ROUND_UP(width, 32), 64);
+   y_meta_plane = y_meta_stride * ALIGN(DIV_ROUND_UP(height, 8), 16);
+   y_meta_plane = ALIGN(y_meta_plane, SZ_4K);
+
+   y_stride = ALIGN(width, 128);
+   y_plane = ALIGN(y_stride * ALIGN(height, 32), SZ_4K);
+
+   uv_meta_stride = ALIGN(DIV_ROUND_UP(width / 2, 16), 64);
+   uv_meta_plane = uv_meta_stride * ALIGN(DIV_ROUND_UP(height / 2, 8), 16);
+   uv_meta_plane = ALIGN(uv_meta_plane, SZ_4K);
+
+   uv_stride = ALIGN(width, 128);
+   uv_plane = ALIGN(uv_stride * ALIGN(height / 2, 32), SZ_4K);
+
+   return ALIGN(y_meta_plane + y_plane + uv_meta_plane + uv_plane +
+max(extradata, y_stride * 48), SZ_4K);
+}
+
+u32 venus_helper_get_framesz_raw(u32 hfi_fmt, u32 width, u32 height)
+{
+   switch (hfi_fmt) {
+   case HFI_COLOR_FORMAT_NV12:
+   case HFI_COLOR_FORMAT_NV21:
+   return get_framesize_raw_nv12(width, height);
+   case HFI_COLOR_FORMAT_NV12_UBWC:
+   return get_framesize_raw_nv12_ubwc(width, height);
+   default:
+   return 0;
+   }
+}
+EXPORT_SYMBOL_GPL(venus_helper_get_framesz_raw);
+
+u32 venus_helper_get_framesz(u32 v4l2_fmt, u32 width, u32 height)
+{
+   u32 hfi_fmt, sz;
+   bool compressed;
+
+   switch (v4l2_fmt) {
+   case V4L2_PIX_FMT_MPEG:
+   case V4L2_PIX_FMT_H264:
+   case V4L2_PIX_FMT_H264_NO_SC:
+   case V4L2_PIX_FMT_H264_MVC:
+   case V4L2_PIX_FMT_H263:
+   case V4L2_PIX_FMT_MPEG1:
+   case V4L2_PIX_FMT_MPEG2:
+   case V4L2_PIX_FMT_MPEG4:
+   case V4L2_PIX_FMT_XVID:
+   case V4L2_PIX_FMT_VC1_ANNEX_G:
+   case V4L2_PIX_FMT_VC1_ANNEX_L:
+   case V4L2_PIX_FMT_VP8:
+   case V4L2_PIX_FMT_VP9:
+   case V4L2_PIX_FMT_HEVC:
+   compressed = true;
+   break;
+   default:
+   compressed = false;
+   break;
+   }
+
+   if (compressed) {
+   sz = ALIGN(height, 32) * ALIGN(width, 32) * 3 / 2 / 2;
+   return ALIGN(sz, SZ_4K);
+   }
+
+   hfi_fmt = to_hfi_raw_fmt(v4l2_fmt);
+   if (!hfi_fmt)
+   return 0;
+
+   return venus_helper_get_framesz_raw(hfi_fmt, width, height);
+}
+EXPORT_SYMBOL_GPL(venus_helper_get_framesz);
+
 int venus_helper_set_input_resolution(struct venus_inst *inst,
  unsigned int width, unsigned int height)
 {
diff --git a/drivers/media/platform/qcom/venus/helpers.h 
b/drivers/media/platform/qcom/venus/helpers.h
index 92be45894a69..92b167a47166 100644
--- a/drivers/media/platform/qcom/venus/helpers.h
+++ b/drivers/media/platform/qcom/venus/helpers.h
@@ -33,6 +33,8 @@ void venus_helper_m2m_device_run(void *priv);
 void venus_helper_m2m_job_abort(void *priv);
 int venus_helper_get_bufreq(struct venus_inst *inst, u32 type,
struct hfi_buffer_requirements *req);
+u32 venus_helper_get_framesz_raw(u32 hfi_fmt, u32 width, u32 height);
+u32 venus_helper_get_framesz(u32 v4l2_fmt, u32 width, u32 height);
 int venus_helper_set_input_resolution(struct venus_inst *inst,
  unsigned int width, unsigned int height);
 int venus_helper_set_output_resolution(struct venus_inst *inst,
diff --git a/drivers/media/platform/qcom/venus/vdec.c 

[PATCH 28/28] venus: add HEVC codec support

[Stanimir Varbanov]

This add HEVC codec support for venus versions 3xx and 4xx.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/helpers.c | 3 +++
 drivers/media/platform/qcom/venus/hfi.c | 2 ++
 drivers/media/platform/qcom/venus/vdec.c| 4 
 drivers/media/platform/qcom/venus/venc.c| 4 
 4 files changed, 13 insertions(+)

diff --git a/drivers/media/platform/qcom/venus/helpers.c 
b/drivers/media/platform/qcom/venus/helpers.c
index 87dcf9973e6f..fecadba039cf 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -71,6 +71,9 @@ bool venus_helper_check_codec(struct venus_inst *inst, u32 
v4l2_pixfmt)
case V4L2_PIX_FMT_XVID:
codec = HFI_VIDEO_CODEC_DIVX;
break;
+   case V4L2_PIX_FMT_HEVC:
+   codec = HFI_VIDEO_CODEC_HEVC;
+   break;
default:
return false;
}
diff --git a/drivers/media/platform/qcom/venus/hfi.c 
b/drivers/media/platform/qcom/venus/hfi.c
index 94ca27b0bb99..24207829982f 100644
--- a/drivers/media/platform/qcom/venus/hfi.c
+++ b/drivers/media/platform/qcom/venus/hfi.c
@@ -49,6 +49,8 @@ static u32 to_codec_type(u32 pixfmt)
return HFI_VIDEO_CODEC_VP9;
case V4L2_PIX_FMT_XVID:
return HFI_VIDEO_CODEC_DIVX;
+   case V4L2_PIX_FMT_HEVC:
+   return HFI_VIDEO_CODEC_HEVC;
default:
return 0;
}
diff --git a/drivers/media/platform/qcom/venus/vdec.c 
b/drivers/media/platform/qcom/venus/vdec.c
index 7deee104ac56..a114f421edad 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -77,6 +77,10 @@ static const struct venus_format vdec_formats[] = {
.pixfmt = V4L2_PIX_FMT_XVID,
.num_planes = 1,
.type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_HEVC,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
},
 };
 
diff --git a/drivers/media/platform/qcom/venus/venc.c 
b/drivers/media/platform/qcom/venus/venc.c
index a703bce78abc..fdb76b69786f 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -59,6 +59,10 @@ static const struct venus_format venc_formats[] = {
.pixfmt = V4L2_PIX_FMT_VP8,
.num_planes = 1,
.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
+   }, {
+   .pixfmt = V4L2_PIX_FMT_HEVC,
+   .num_planes = 1,
+   .type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
},
 };
 
-- 
2.14.1

[PATCH 16/28] venus: add helper function to set actual buffer size

[Stanimir Varbanov]

Add and use a helper function to set actual buffer size for
particular buffer type. This is also preparation to use
the second decoder output.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/helpers.c | 12 
 drivers/media/platform/qcom/venus/helpers.h |  1 +
 drivers/media/platform/qcom/venus/vdec.c| 10 ++
 3 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/helpers.c 
b/drivers/media/platform/qcom/venus/helpers.c
index 824ad4d2d064..94664a3ce3e2 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -544,6 +544,18 @@ int venus_helper_set_dyn_bufmode(struct venus_inst *inst)
 }
 EXPORT_SYMBOL_GPL(venus_helper_set_dyn_bufmode);
 
+int venus_helper_set_bufsize(struct venus_inst *inst, u32 bufsize, u32 buftype)
+{
+   u32 ptype = HFI_PROPERTY_PARAM_BUFFER_SIZE_ACTUAL;
+   struct hfi_buffer_size_actual bufsz;
+
+   bufsz.type = buftype;
+   bufsz.size = bufsize;
+
+   return hfi_session_set_property(inst, ptype, );
+}
+EXPORT_SYMBOL_GPL(venus_helper_set_bufsize);
+
 static void delayed_process_buf_func(struct work_struct *work)
 {
struct venus_buffer *buf, *n;
diff --git a/drivers/media/platform/qcom/venus/helpers.h 
b/drivers/media/platform/qcom/venus/helpers.h
index 52b961ed491e..cd306bd8978f 100644
--- a/drivers/media/platform/qcom/venus/helpers.h
+++ b/drivers/media/platform/qcom/venus/helpers.h
@@ -41,6 +41,7 @@ int venus_helper_set_num_bufs(struct venus_inst *inst, 
unsigned int input_bufs,
  unsigned int output_bufs);
 int venus_helper_set_color_format(struct venus_inst *inst, u32 fmt);
 int venus_helper_set_dyn_bufmode(struct venus_inst *inst);
+int venus_helper_set_bufsize(struct venus_inst *inst, u32 bufsize, u32 
buftype);
 void venus_helper_acquire_buf_ref(struct vb2_v4l2_buffer *vbuf);
 void venus_helper_release_buf_ref(struct venus_inst *inst, unsigned int idx);
 void venus_helper_init_instance(struct venus_inst *inst);
diff --git a/drivers/media/platform/qcom/venus/vdec.c 
b/drivers/media/platform/qcom/venus/vdec.c
index 1de9cc64cf2f..b43607dee4fe 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -710,7 +710,6 @@ static int vdec_start_streaming(struct vb2_queue *q, 
unsigned int count)
 {
struct venus_inst *inst = vb2_get_drv_priv(q);
struct venus_core *core = inst->core;
-   u32 ptype;
int ret;
 
mutex_lock(>lock);
@@ -740,13 +739,8 @@ static int vdec_start_streaming(struct vb2_queue *q, 
unsigned int count)
goto deinit_sess;
 
if (core->res->hfi_version == HFI_VERSION_3XX) {
-   struct hfi_buffer_size_actual buf_sz;
-
-   ptype = HFI_PROPERTY_PARAM_BUFFER_SIZE_ACTUAL;
-   buf_sz.type = HFI_BUFFER_OUTPUT;
-   buf_sz.size = inst->output_buf_size;
-
-   ret = hfi_session_set_property(inst, ptype, _sz);
+   ret = venus_helper_set_bufsize(inst, inst->output_buf_size,
+  HFI_BUFFER_OUTPUT);
if (ret)
goto deinit_sess;
}
-- 
2.14.1

[PATCH 00/28] Venus updates

[Stanimir Varbanov]

Hello,

This patch set aims to:

* add initial support for Venus version 4xx (found on sdm845).

* introduce a common capability parser to enumerate better
  supported uncompressed formats, capabilities by codec,
  supported codecs and so on.

* also contains various cleanups, readability improvements
  and fixes.

* adds HEVC codec support for the Venus versions which has
  support for it.

* add multi-stream support (secondary decoder output), which
  will give as an opportunity to use UBWC compressed formats
  to optimize internal interconnect bandwidth on higher
  resolutions.

Comments are welcome!

regards,
Stan

Stanimir Varbanov (28):
  venus: hfi_msgs: correct pointer increment
  venus: hfi: preparation to support venus 4xx
  venus: hfi: update sequence event to handle more properties
  venus: hfi_cmds: add set_properties for 4xx version
  venus: hfi: support session continue for 4xx version
  venus: hfi: handle buffer output2 type as well
  venus: hfi_venus: add halt AXI support for Venus 4xx
  venus: hfi_venus: add suspend function for 4xx version
  venus: venc,vdec: adds clocks needed for venus 4xx
  venus: vdec: call session_continue in insufficient event
  venus: add common capability parser
  venus: helpers: make a commmon function for power_enable
  venus: core: delete not used flag for buffer mode
  venus: helpers: rename a helper function and use buffer mode from caps
  venus: add a helper function to set dynamic buffer mode
  venus: add helper function to set actual buffer size
  venus: delete no longer used bufmode flag from instance
  venus: helpers: add buffer type argument to a helper
  venus: helpers: add a new helper to set raw format
  venus: helpers,vdec,venc: add helpers to set work mode and core usage
  venus: helpers: extend set_num_bufs helper with one more argument
  venus: helpers: add a helper to return opb buffer sizes
  venus: vdec: get required input buffers as well
  venus: vdec: new function for output configuration
  venus: move frame size calculations in common place
  venus: implementing multi-stream support
  venus: add sdm845 compatible and resource data
  venus: add HEVC codec support

 .../devicetree/bindings/media/qcom,venus.txt   |   1 +
 drivers/media/platform/qcom/venus/Makefile |   3 +-
 drivers/media/platform/qcom/venus/core.c   | 102 
 drivers/media/platform/qcom/venus/core.h   |  91 ++--
 drivers/media/platform/qcom/venus/helpers.c| 558 +++--
 drivers/media/platform/qcom/venus/helpers.h|  23 +-
 drivers/media/platform/qcom/venus/hfi.c|  12 +-
 drivers/media/platform/qcom/venus/hfi.h|   9 +
 drivers/media/platform/qcom/venus/hfi_cmds.c   |  64 ++-
 drivers/media/platform/qcom/venus/hfi_helper.h | 112 -
 drivers/media/platform/qcom/venus/hfi_msgs.c   | 401 +++
 drivers/media/platform/qcom/venus/hfi_parser.c | 290 +++
 drivers/media/platform/qcom/venus/hfi_parser.h |  45 ++
 drivers/media/platform/qcom/venus/hfi_venus.c  |  69 +++
 drivers/media/platform/qcom/venus/hfi_venus_io.h   |  24 +
 drivers/media/platform/qcom/venus/vdec.c   | 324 +++-
 drivers/media/platform/qcom/venus/venc.c   | 166 +++---
 17 files changed, 1641 insertions(+), 653 deletions(-)
 create mode 100644 drivers/media/platform/qcom/venus/hfi_parser.c
 create mode 100644 drivers/media/platform/qcom/venus/hfi_parser.h

-- 
2.14.1

[PATCH v11 3/4] dt-bindings: media: Add Cadence MIPI-CSI2 TX Device Tree bindings

[Maxime Ripard]

The Cadence MIPI-CSI2 TX controller is a CSI2 bridge that supports up to 4
video streams and can output on up to 4 CSI-2 lanes, depending on the
hardware implementation.

It can operate with an external D-PHY, an internal one or no D-PHY at all
in some configurations.

Acked-by: Rob Herring 
Acked-by: Sakari Ailus 
Reviewed-by: Niklas Söderlund 
Signed-off-by: Maxime Ripard 
---
 .../devicetree/bindings/media/cdns,csi2tx.txt | 98 +++
 1 file changed, 98 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2tx.txt

diff --git a/Documentation/devicetree/bindings/media/cdns,csi2tx.txt 
b/Documentation/devicetree/bindings/media/cdns,csi2tx.txt
new file mode 100644
index ..459c6e332f52
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cdns,csi2tx.txt
@@ -0,0 +1,98 @@
+Cadence MIPI-CSI2 TX controller
+===
+
+The Cadence MIPI-CSI2 TX controller is a CSI-2 bridge supporting up to
+4 CSI lanes in output, and up to 4 different pixel streams in input.
+
+Required properties:
+  - compatible: must be set to "cdns,csi2tx"
+  - reg: base address and size of the memory mapped region
+  - clocks: phandles to the clocks driving the controller
+  - clock-names: must contain:
+* esc_clk: escape mode clock
+* p_clk: register bank clock
+* pixel_if[0-3]_clk: pixel stream output clock, one for each stream
+ implemented in hardware, between 0 and 3
+
+Optional properties
+  - phys: phandle to the D-PHY. If it is set, phy-names need to be set
+  - phy-names: must contain "dphy"
+
+Required subnodes:
+  - ports: A ports node with one port child node per device input and output
+   port, in accordance with the video interface bindings defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt. The
+   port nodes are numbered as follows.
+
+   Port Description
+   -
+   0CSI-2 output
+   1Stream 0 input
+   2Stream 1 input
+   3Stream 2 input
+   4Stream 3 input
+
+   The stream input port nodes are optional if they are not
+   connected to anything at the hardware level or implemented
+   in the design. Since there is only one endpoint per port,
+   the endpoints are not numbered.
+
+Example:
+
+csi2tx: csi-bridge@0d0e1000 {
+   compatible = "cdns,csi2tx";
+   reg = <0x0d0e1000 0x1000>;
+   clocks = <>, <>,
+<>, <>,
+<>, <>;
+   clock-names = "p_clk", "esc_clk",
+ "pixel_if0_clk", "pixel_if1_clk",
+ "pixel_if2_clk", "pixel_if3_clk";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   csi2tx_out: endpoint {
+   remote-endpoint = <_in>;
+   clock-lanes = <0>;
+   data-lanes = <1 2>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   csi2tx_in_stream0: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   csi2tx_in_stream1: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@3 {
+   reg = <3>;
+
+   csi2tx_in_stream2: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@4 {
+   reg = <4>;
+
+   csi2tx_in_stream3: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+};
-- 
2.17.0

[PATCH v11 4/4] v4l: cadence: Add Cadence MIPI-CSI2 TX driver

[Maxime Ripard]

The Cadence MIPI-CSI2 TX controller is an hardware block meant to be used
as a bridge between pixel interfaces and a CSI-2 bus.

It supports operating with an internal or external D-PHY, with up to 4
lanes, or without any D-PHY. The current code only supports the latter
case.

While the virtual channel input on the pixel interface can be directly
mapped to CSI2, the datatype input is actually a selection signal (3-bits)
mapping to a table of up to 8 preconfigured datatypes/formats (programmed
at start-up)

The block supports up to 8 input datatypes.

Acked-by: Sakari Ailus 
Reviewed-by: Niklas Söderlund 
Signed-off-by: Maxime Ripard 
---
 drivers/media/platform/cadence/Kconfig   |  11 +
 drivers/media/platform/cadence/Makefile  |   1 +
 drivers/media/platform/cadence/cdns-csi2tx.c | 563 +++
 3 files changed, 575 insertions(+)
 create mode 100644 drivers/media/platform/cadence/cdns-csi2tx.c

diff --git a/drivers/media/platform/cadence/Kconfig 
b/drivers/media/platform/cadence/Kconfig
index 70c95d79c8f7..3bf0f2454384 100644
--- a/drivers/media/platform/cadence/Kconfig
+++ b/drivers/media/platform/cadence/Kconfig
@@ -20,4 +20,15 @@ config VIDEO_CADENCE_CSI2RX
  To compile this driver as a module, choose M here: the module will be
  called cdns-csi2rx.
 
+config VIDEO_CADENCE_CSI2TX
+   tristate "Cadence MIPI-CSI2 TX Controller"
+   depends on MEDIA_CONTROLLER
+   depends on VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+   help
+ Support for the Cadence MIPI CSI2 Transceiver controller.
+
+ To compile this driver as a module, choose M here: the module will be
+ called cdns-csi2tx.
+
 endif
diff --git a/drivers/media/platform/cadence/Makefile 
b/drivers/media/platform/cadence/Makefile
index 99a4086b7448..7fe992273162 100644
--- a/drivers/media/platform/cadence/Makefile
+++ b/drivers/media/platform/cadence/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_VIDEO_CADENCE_CSI2RX) += cdns-csi2rx.o
+obj-$(CONFIG_VIDEO_CADENCE_CSI2TX) += cdns-csi2tx.o
diff --git a/drivers/media/platform/cadence/cdns-csi2tx.c 
b/drivers/media/platform/cadence/cdns-csi2tx.c
new file mode 100644
index ..dfa1d88d955b
--- /dev/null
+++ b/drivers/media/platform/cadence/cdns-csi2tx.c
@@ -0,0 +1,563 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Driver for Cadence MIPI-CSI2 TX Controller
+ *
+ * Copyright (C) 2017-2018 Cadence Design Systems Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define CSI2TX_DEVICE_CONFIG_REG   0x00
+#define CSI2TX_DEVICE_CONFIG_STREAMS_MASK  GENMASK(6, 4)
+#define CSI2TX_DEVICE_CONFIG_HAS_DPHY  BIT(3)
+#define CSI2TX_DEVICE_CONFIG_LANES_MASKGENMASK(2, 0)
+
+#define CSI2TX_CONFIG_REG  0x20
+#define CSI2TX_CONFIG_CFG_REQ  BIT(2)
+#define CSI2TX_CONFIG_SRST_REQ BIT(1)
+
+#define CSI2TX_DPHY_CFG_REG0x28
+#define CSI2TX_DPHY_CFG_CLK_RESET  BIT(16)
+#define CSI2TX_DPHY_CFG_LANE_RESET(n)  BIT((n) + 12)
+#define CSI2TX_DPHY_CFG_MODE_MASK  GENMASK(9, 8)
+#define CSI2TX_DPHY_CFG_MODE_LPDT  (2 << 8)
+#define CSI2TX_DPHY_CFG_MODE_HS(1 << 8)
+#define CSI2TX_DPHY_CFG_MODE_ULPS  (0 << 8)
+#define CSI2TX_DPHY_CFG_CLK_ENABLE BIT(4)
+#define CSI2TX_DPHY_CFG_LANE_ENABLE(n) BIT(n)
+
+#define CSI2TX_DPHY_CLK_WAKEUP_REG 0x2c
+#define CSI2TX_DPHY_CLK_WAKEUP_ULPS_CYCLES(n)  ((n) & 0x)
+
+#define CSI2TX_DT_CFG_REG(n)   (0x80 + (n) * 8)
+#define CSI2TX_DT_CFG_DT(n)(((n) & 0x3f) << 2)
+
+#define CSI2TX_DT_FORMAT_REG(n)(0x84 + (n) * 8)
+#define CSI2TX_DT_FORMAT_BYTES_PER_LINE(n) (((n) & 0x) << 16)
+#define CSI2TX_DT_FORMAT_MAX_LINE_NUM(n)   ((n) & 0x)
+
+#define CSI2TX_STREAM_IF_CFG_REG(n)(0x100 + (n) * 4)
+#define CSI2TX_STREAM_IF_CFG_FILL_LEVEL(n) ((n) & 0x1f)
+
+#define CSI2TX_LANES_MAX   4
+#define CSI2TX_STREAMS_MAX 4
+
+enum csi2tx_pads {
+   CSI2TX_PAD_SOURCE,
+   CSI2TX_PAD_SINK_STREAM0,
+   CSI2TX_PAD_SINK_STREAM1,
+   CSI2TX_PAD_SINK_STREAM2,
+   CSI2TX_PAD_SINK_STREAM3,
+   CSI2TX_PAD_MAX,
+};
+
+struct csi2tx_fmt {
+   u32 mbus;
+   u32 dt;
+   u32 bpp;
+};
+
+struct csi2tx_priv {
+   struct device   *dev;
+   unsigned intcount;
+
+   /*
+* Used to prevent race conditions between multiple,
+* concurrent calls to start and stop.
+*/
+   struct mutexlock;
+
+   void __iomem*base;
+
+   struct clk  *esc_clk;
+   struct clk  *p_clk;
+   struct clk   

[PATCH v11 1/4] dt-bindings: media: Add Cadence MIPI-CSI2 RX Device Tree bindings

[Maxime Ripard]

The Cadence MIPI-CSI2 RX controller is a CSI2RX bridge that supports up to
4 CSI-2 lanes, and can route the frames to up to 4 streams, depending on
the hardware implementation.

It can operate with an external D-PHY, an internal one or no D-PHY at all
in some configurations.

Acked-by: Rob Herring 
Acked-by: Benoit Parrot 
Acked-by: Sakari Ailus 
Reviewed-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Maxime Ripard 
---
 .../devicetree/bindings/media/cdns,csi2rx.txt | 100 ++
 1 file changed, 100 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2rx.txt

diff --git a/Documentation/devicetree/bindings/media/cdns,csi2rx.txt 
b/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
new file mode 100644
index ..6b02a0657ad9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
@@ -0,0 +1,100 @@
+Cadence MIPI-CSI2 RX controller
+===
+
+The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI
+lanes in input, and 4 different pixel streams in output.
+
+Required properties:
+  - compatible: must be set to "cdns,csi2rx" and an SoC-specific compatible
+  - reg: base address and size of the memory mapped region
+  - clocks: phandles to the clocks driving the controller
+  - clock-names: must contain:
+* sys_clk: main clock
+* p_clk: register bank clock
+* pixel_if[0-3]_clk: pixel stream output clock, one for each stream
+ implemented in hardware, between 0 and 3
+
+Optional properties:
+  - phys: phandle to the external D-PHY, phy-names must be provided
+  - phy-names: must contain "dphy", if the implementation uses an
+   external D-PHY
+
+Required subnodes:
+  - ports: A ports node with one port child node per device input and output
+   port, in accordance with the video interface bindings defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt. The
+   port nodes are numbered as follows:
+
+   Port Description
+   -
+   0CSI-2 input
+   1Stream 0 output
+   2Stream 1 output
+   3Stream 2 output
+   4Stream 3 output
+
+   The stream output port nodes are optional if they are not
+   connected to anything at the hardware level or implemented
+   in the design.Since there is only one endpoint per port,
+   the endpoints are not numbered.
+
+
+Example:
+
+csi2rx: csi-bridge@0d06 {
+   compatible = "cdns,csi2rx";
+   reg = <0x0d06 0x1000>;
+   clocks = <>, <>
+<>, <>,
+<>, <>;
+   clock-names = "sys_clk", "p_clk",
+ "pixel_if0_clk", "pixel_if1_clk",
+ "pixel_if2_clk", "pixel_if3_clk";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   csi2rx_in_sensor: endpoint {
+   remote-endpoint = <_out_csi2rx>;
+   clock-lanes = <0>;
+   data-lanes = <1 2>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   csi2rx_out_grabber0: endpoint {
+   remote-endpoint = <_in_csi2rx>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   csi2rx_out_grabber1: endpoint {
+   remote-endpoint = <_in_csi2rx>;
+   };
+   };
+
+   port@3 {
+   reg = <3>;
+
+   csi2rx_out_grabber2: endpoint {
+   remote-endpoint = <_in_csi2rx>;
+   };
+   };
+
+   port@4 {
+   reg = <4>;
+
+   csi2rx_out_grabber3: endpoint {
+   remote-endpoint = <_in_csi2rx>;
+   };
+   };
+   };
+};
-- 
2.17.0

[PATCH v11 0/4] media: v4l: Add support for the Cadence MIPI-CSI2 TX controller

[Maxime Ripard]

Hi,

Here is a hopefully final attempt at supporting the MIPI-CSI2 RX and
TX blocks from Cadence.

This is a merged serie of the CSI2-RX and CSI2-TX series I've been
sending for a while now and gathered a significant amount of
Reviewed-by/Acked-by. The merge has been done thanks to Sakari's
suggestion to ease the merge and the dependency between the two
drivers on the MAINTAINERS/Kconfig/Makefile sides.

The CSI2-RX has not received any comment on its previous iteration,
and CSI2-TX received some minor comments from Sakari that have been
fixed in this series. You can have a look at the Changelog below if
needed.

The TX controller is able to receive 4 video streams and stream them over a
MIPI-CSI2 link using up to 4 lanes. Those streams are basically the
interfaces to controllers generating some video signals, like a camera
or a pattern generator.

The RX controller is able to receive CSI data over up to 4 lanes, and
split it to over 4 streams. Those streams are basically the interfaces
to the video grabbers that will perform the capture.

TX is then able to map input streams to CSI2 virtual channels and
datatypes dynamically. The streaming devices choose their virtual
channels through an additional signal that is transparent to the
CSI2-TX. The datatypes however are yet another additional input
signal, and can be mapped to any CSI2 datatypes. RX can do the
opposite, being able to take virtual channel / datatypes and route
them to proper pixel interfaces on demand.

Since v4l2 doesn't really allow for that setup at the moment, this
preliminary version is a rather dumb one in order to start the
discussion on how to address this properly.

Let me know what you think!
Maxime

Changes from CSI2-TX v10:
  - Reword the source pad exception comment
  - Handle the V4L2_SUBDEV_FORMAT_TRY case for get_fmt / set_fmt

Maxime Ripard (4):
  dt-bindings: media: Add Cadence MIPI-CSI2 RX Device Tree bindings
  v4l: cadence: Add Cadence MIPI-CSI2 RX driver
  dt-bindings: media: Add Cadence MIPI-CSI2 TX Device Tree bindings
  v4l: cadence: Add Cadence MIPI-CSI2 TX driver

 .../devicetree/bindings/media/cdns,csi2rx.txt | 100 
 .../devicetree/bindings/media/cdns,csi2tx.txt |  98 +++
 MAINTAINERS   |   7 +
 drivers/media/platform/Kconfig|   1 +
 drivers/media/platform/Makefile   |   1 +
 drivers/media/platform/cadence/Kconfig|  34 ++
 drivers/media/platform/cadence/Makefile   |   2 +
 drivers/media/platform/cadence/cdns-csi2rx.c  | 500 
 drivers/media/platform/cadence/cdns-csi2tx.c  | 563 ++
 9 files changed, 1306 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2rx.txt
 create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2tx.txt
 create mode 100644 drivers/media/platform/cadence/Kconfig
 create mode 100644 drivers/media/platform/cadence/Makefile
 create mode 100644 drivers/media/platform/cadence/cdns-csi2rx.c
 create mode 100644 drivers/media/platform/cadence/cdns-csi2tx.c

-- 
2.17.0

[PATCH v11 2/4] v4l: cadence: Add Cadence MIPI-CSI2 RX driver

[Maxime Ripard]

The Cadence CSI-2 RX Controller is an hardware block meant to be used as a
bridge between a CSI-2 bus and pixel grabbers.

It supports operating with internal or external D-PHY, with up to 4 lanes,
or without any D-PHY. The current code only supports the latter case.

It also support dynamic mapping of the CSI-2 virtual channels to the
associated pixel grabbers, but that isn't allowed at the moment either.

Acked-by: Sakari Ailus 
Reviewed-by: Niklas Söderlund 
Signed-off-by: Maxime Ripard 
---
 MAINTAINERS  |   7 +
 drivers/media/platform/Kconfig   |   1 +
 drivers/media/platform/Makefile  |   1 +
 drivers/media/platform/cadence/Kconfig   |  23 +
 drivers/media/platform/cadence/Makefile  |   1 +
 drivers/media/platform/cadence/cdns-csi2rx.c | 500 +++
 6 files changed, 533 insertions(+)
 create mode 100644 drivers/media/platform/cadence/Kconfig
 create mode 100644 drivers/media/platform/cadence/Makefile
 create mode 100644 drivers/media/platform/cadence/cdns-csi2rx.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 0a1410d5a621..2c27d39611eb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3133,6 +3133,13 @@ S:   Supported
 F: Documentation/filesystems/caching/cachefiles.txt
 F: fs/cachefiles/
 
+CADENCE MIPI-CSI2 BRIDGES
+M: Maxime Ripard 
+L: linux-media@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/media/cdns,*.txt
+F: drivers/media/platform/cadence/cdns-csi2*
+
 CADET FM/AM RADIO RECEIVER DRIVER
 M: Hans Verkuil 
 L: linux-media@vger.kernel.org
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c7a1cf8a1b01..029340ec3da4 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -26,6 +26,7 @@ config VIDEO_VIA_CAMERA
 #
 # Platform multimedia device configuration
 #
+source "drivers/media/platform/cadence/Kconfig"
 
 source "drivers/media/platform/davinci/Kconfig"
 
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 932515df4477..04bc1502a30e 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -3,6 +3,7 @@
 # Makefile for the video capture/playback device drivers.
 #
 
+obj-$(CONFIG_VIDEO_CADENCE)+= cadence/
 obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
 obj-$(CONFIG_VIDEO_CAFE_CCIC) += marvell-ccic/
 obj-$(CONFIG_VIDEO_MMP_CAMERA) += marvell-ccic/
diff --git a/drivers/media/platform/cadence/Kconfig 
b/drivers/media/platform/cadence/Kconfig
new file mode 100644
index ..70c95d79c8f7
--- /dev/null
+++ b/drivers/media/platform/cadence/Kconfig
@@ -0,0 +1,23 @@
+config VIDEO_CADENCE
+   bool "Cadence Video Devices"
+   help
+ If you have a media device designed by Cadence, say Y.
+
+ Note that this option doesn't include new drivers in the kernel:
+ saying N will just cause Kconfig to skip all the questions about
+ Cadence media devices.
+
+if VIDEO_CADENCE
+
+config VIDEO_CADENCE_CSI2RX
+   tristate "Cadence MIPI-CSI2 RX Controller"
+   depends on MEDIA_CONTROLLER
+   depends on VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+   help
+ Support for the Cadence MIPI CSI2 Receiver controller.
+
+ To compile this driver as a module, choose M here: the module will be
+ called cdns-csi2rx.
+
+endif
diff --git a/drivers/media/platform/cadence/Makefile 
b/drivers/media/platform/cadence/Makefile
new file mode 100644
index ..99a4086b7448
--- /dev/null
+++ b/drivers/media/platform/cadence/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_CADENCE_CSI2RX) += cdns-csi2rx.o
diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c 
b/drivers/media/platform/cadence/cdns-csi2rx.c
new file mode 100644
index ..01f8321c12da
--- /dev/null
+++ b/drivers/media/platform/cadence/cdns-csi2rx.c
@@ -0,0 +1,500 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Driver for Cadence MIPI-CSI2 RX Controller v1.3
+ *
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define CSI2RX_DEVICE_CFG_REG  0x000
+
+#define CSI2RX_SOFT_RESET_REG  0x004
+#define CSI2RX_SOFT_RESET_PROTOCOL BIT(1)
+#define CSI2RX_SOFT_RESET_FRONTBIT(0)
+
+#define CSI2RX_STATIC_CFG_REG  0x008
+#define CSI2RX_STATIC_CFG_DLANE_MAP(llane, plane)  ((plane) << (16 + 
(llane) * 4))
+#define CSI2RX_STATIC_CFG_LANES_MASK   GENMASK(11, 8)
+
+#define CSI2RX_STREAM_BASE(n)  (((n) + 1) * 0x100)
+
+#define CSI2RX_STREAM_CTRL_REG(n)  (CSI2RX_STREAM_BASE(n) + 0x000)
+#define 

Re: [PATCH 2/3] media: ov5640: add PIXEL_RATE and LINK_FREQ controls

[Daniel Mack]

Hi,

On Tuesday, April 24, 2018 12:22 PM, Sakari Ailus wrote:
> On Fri, Apr 20, 2018 at 11:44:18AM +0200, Daniel Mack wrote:
>> Add v4l2 controls to report the pixel and MIPI link rates of each mode.
>> The camss camera subsystem needs them to set up the correct hardware
>> clocks.
>>
>> Tested on msm8016 based hardware.
>>
>> Signed-off-by: Daniel Mack 
> 
> Maxime has written a number of patches against the driver that seem very
> much related; could you rebase these on his set (v2)?
> 
> 

I didn't know about the ongoing work in this area, so I think both this
and 3/3 are not needed. If you want, you can still pick the 1st patch in
this series, but that's just a cosmetic cleanup.


Thanks,
Daniel

Re: [PATCH v2 02/12] media: ov5640: Add light frequency control

[Sakari Ailus]

On Fri, Apr 20, 2018 at 09:04:10PM +0200, Maxime Ripard wrote:
> Hi Laurent,
> 
> On Thu, Apr 19, 2018 at 12:44:18PM +0300, Laurent Pinchart wrote:
> > On Monday, 16 April 2018 15:36:51 EEST Maxime Ripard wrote:
> > > From: Mylène Josserand 
> > > 
> > > Add the light frequency control to be able to set the frequency
> > > to manual (50Hz or 60Hz) or auto.
> > > 
> > > Signed-off-by: Mylène Josserand 
> > > Signed-off-by: Maxime Ripard 
> > > ---
> > >  drivers/media/i2c/ov5640.c | 24 
> > >  1 file changed, 24 insertions(+)
> > > 
> > > diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> > > index a33e45f8e2b0..28122341fc35 100644
> > > --- a/drivers/media/i2c/ov5640.c
> > > +++ b/drivers/media/i2c/ov5640.c
> > > @@ -189,6 +189,7 @@ struct ov5640_ctrls {
> > >   };
> > >   struct v4l2_ctrl *auto_focus;
> > >   struct v4l2_ctrl *brightness;
> > > + struct v4l2_ctrl *light_freq;
> > >   struct v4l2_ctrl *saturation;
> > >   struct v4l2_ctrl *contrast;
> > >   struct v4l2_ctrl *hue;
> > > @@ -2163,6 +2164,21 @@ static int ov5640_set_ctrl_focus(struct ov5640_dev
> > > *sensor, int value) BIT(1), value ? BIT(1) : 0);
> > >  }
> > > 
> > > +static int ov5640_set_ctl_light_freq(struct ov5640_dev *sensor, int 
> > > value)
> > 
> > To stay consistent with the other functions, I propose calling this 
> > ov5640_set_ctrl_light_freq().
> > 
> > Apart from that,
> > 
> > Reviewed-by: Laurent Pinchart 
> 
> Consider it fixed in the next iteration, thanks!
> Maxime

Applied patches 2--7 with the following diff to the first applied patch,
i.e. this one:

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index dc3950c20c62..e480e53b369b 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -2178,7 +2178,7 @@ static int ov5640_set_ctrl_test_pattern(struct ov5640_dev 
*sensor, int value)
  0xa4, value ? 0xa4 : 0);
 }
 
-static int ov5640_set_ctl_light_freq(struct ov5640_dev *sensor, int value)
+static int ov5640_set_ctrl_light_freq(struct ov5640_dev *sensor, int value)
 {
int ret;
 
@@ -2262,7 +2262,7 @@ static int ov5640_s_ctrl(struct v4l2_ctrl *ctrl)
ret = ov5640_set_ctrl_test_pattern(sensor, ctrl->val);
break;
case V4L2_CID_POWER_LINE_FREQUENCY:
-   ret = ov5640_set_ctl_light_freq(sensor, ctrl->val);
+   ret = ov5640_set_ctrl_light_freq(sensor, ctrl->val);
break;
default:
ret = -EINVAL;

Thanks!

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

Re: [RESEND PATCH 1/1] ov5640: Use dev_fwnode() to obtain device's fwnode

[Maxime Ripard]

On Tue, Apr 24, 2018 at 02:10:29PM +0300, Sakari Ailus wrote:
> Use dev_fwnode() on the device instead of getting an fwnode handle of the
> device's OF node. The result is the same on OF-based systems and looks
> better, too.
> 
> Signed-off-by: Sakari Ailus 

Reviewed-by: Maxime Ripard 

Maxime

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


signature.asc
Description: PGP signature

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

[Peter Zijlstra]

On Tue, Apr 24, 2018 at 12:36:09PM +0200, Peter Zijlstra wrote:
> 
> Then usespace probes which part of the descr[] array is now in cache and
> from that it can infer the initial out-of-bound value.

Just had a better look at v4l_fill_fmtdesc() and actually read the
comment. The code cannot be compiled as a array because it is big and
sparse. But the log(n) condition tree is a prime candidate for the
branchscope side-channel, which would be able to reconstruct a
significant number of bits of the original value. A denser tree gives
more bits etc.

[RESEND PATCH 1/1] ov5640: Use dev_fwnode() to obtain device's fwnode

[Sakari Ailus]

Use dev_fwnode() on the device instead of getting an fwnode handle of the
device's OF node. The result is the same on OF-based systems and looks
better, too.

Signed-off-by: Sakari Ailus 
---
Fixed Maxime's e-mail.

 drivers/media/i2c/ov5640.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 852026baa2e7..7acd3b44d194 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -2536,8 +2536,8 @@ static int ov5640_probe(struct i2c_client *client,
 
sensor->ae_target = 52;
 
-   endpoint = fwnode_graph_get_next_endpoint(
-   of_fwnode_handle(client->dev.of_node), NULL);
+   endpoint = fwnode_graph_get_next_endpoint(dev_fwnode(>dev),
+ NULL);
if (!endpoint) {
dev_err(dev, "endpoint node not found\n");
return -EINVAL;
-- 
2.11.0

Re: [RESEND PATCH] media: i2c: ov5640: Add pixel clock support

[Loic Poulain]

Hi Sakari,

>> Any comments on this change?
>
> 
>
> There's also another set that adds PIXEL_CLOCK (as well as LINK_FREQ)
> support to the driver, that seems more complete than this patch but
> requires a rebase on Maxime's patches:
>
> 

Thanks, I've just see this patch series. Indeed, patch will need a
rework/rebase.

Regards,
Loic

Re: [PATCH] staging: media: use relevant lock

[Kieran Bingham]

Hi Julia

Thank you for the patch.

On 03/08/17 13:26, Julia Lawall wrote:
> The data protected is video_out2 and the lock that is released is
> _out2->dma_queue_lock, so it seems that that lock should be
> taken as well.

I agree - this certainly looks like there was a copy/paste error perhaps and is
locking the wrong video.

> Signed-off-by: Julia Lawall 

Reviewed-by: Kieran Bingham 




> ---
>  drivers/staging/media/davinci_vpfe/dm365_resizer.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/davinci_vpfe/dm365_resizer.c 
> b/drivers/staging/media/davinci_vpfe/dm365_resizer.c
> index 857b0e8..4910cb7 100644
> --- a/drivers/staging/media/davinci_vpfe/dm365_resizer.c
> +++ b/drivers/staging/media/davinci_vpfe/dm365_resizer.c
> @@ -1059,7 +1059,7 @@ static void resizer_ss_isr(struct vpfe_resizer_device 
> *resizer)
>   /* If resizer B is enabled */
>   if (pipe->output_num > 1 && resizer->resizer_b.output ==
>   RESIZER_OUTPUT_MEMORY) {
> - spin_lock(_out->dma_queue_lock);
> + spin_lock(_out2->dma_queue_lock);
>   vpfe_video_process_buffer_complete(video_out2);
>   video_out2->state = VPFE_VIDEO_BUFFER_NOT_QUEUED;
>   vpfe_video_schedule_next_buffer(video_out2);
> 

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

[Peter Zijlstra]

On Tue, Apr 24, 2018 at 12:35:00PM +0300, Dan Carpenter wrote:
> On Mon, Apr 23, 2018 at 03:24:55PM -0300, Mauro Carvalho Chehab wrote:
> > Em Mon, 23 Apr 2018 12:38:03 -0500
> > "Gustavo A. R. Silva"  escreveu:

> > > @@ -875,6 +876,7 @@ static int vidioc_enum_fmt_vid_cap(struct file *file, 
> > > void  *priv,
> > >   if (f->index >= ARRAY_SIZE(format))
> > >   return -EINVAL;
> > >  
> > > + f->index = array_index_nospec(f->index, ARRAY_SIZE(format));
> >
> > Please enlighten me: how do you think this could be exploited?

TL;DR: read the papers [1] & [2]

I suspect you didn't get the gist of Spectre V1 [1], let me explain:

Suppose userspace provides f->index > ARRAY_SIZE(format), and we predict
the branch to -EINVAL to not be taken.

Then the CPU _WILL_ load (out of bounds) format[f->index] into
f->pixelformat and continue onwards to use this bogus value, all the way
until it figures out the branch was mis-predicted.

Once it figures out the mispredict, it will throw away the state and
start over at the condition site. So far, so basic.

The thing is, is will not (and cannot) throw away all state. Suppose our
speculation continues into v4l_fill_fmtdesc() and that switch there is
compiled as another array lookup, it will then feed our f->pixelformat
(which contains random kernel memory) into that array to find the
requested descr pointer.

Now, imagine userspace having flushed cache on the descr pointer array,
having trained the branch predictor to mis-predict the branch (see
branchscope paper [2]) and doing that out-of-bounds ioctl().

It can then speculative do the out-of-bounds array access, followed by
the desc array load, then figure out it was wrong and redo.

Then usespace probes which part of the descr[] array is now in cache and
from that it can infer the initial out-of-bound value.

So while format[] is static and bound, it can read random kernel memory
up to format+4g, including your crypto keys.

As far as V1 goes, this is actually a fairly solid exploit candidate. No
false positive about it.

Now kernel policy is to kill any and all speculation on user controlled
array indexing such that we don't have to go look for subsequent side
channels (the above cache side channel is the one described in the
Spectre paper and by far the easiest, but there are other possible side
channels) and we simply don't want to worry about it.

So even from that pov, the proposed patch is good.


[1] https://spectreattack.com/spectre.pdf
[2] www.cs.ucr.edu/~nael/pubs/asplos18.pdf

Re: [RESEND PATCH] media: i2c: ov5640: Add pixel clock support

[Sakari Ailus]

On Tue, Apr 24, 2018 at 11:01:18AM +0200, Loic Poulain wrote:
> On 29 March 2018 at 16:55, Manivannan Sadhasivam
>  wrote:
> > Some of the camera subsystems like camss in Qualcommm MSM chipsets
> > require pixel clock support in camera sensor drivers. So, this commit
> > adds a default pixel clock rate of 96MHz to OV5640 camera sensor driver.
> >
> > According to the datasheet, 96MHz can be used as a pixel clock rate for
> > most of the modes.
> >
> > Signed-off-by: Manivannan Sadhasivam 
> 
> Tested-by: Loic Poulain 
> 
> It works for me on Dragonboard 410c + D3 camera mezzanine (ov5640) .
> 
> Any comments on this change?



There's also another set that adds PIXEL_CLOCK (as well as LINK_FREQ)
support to the driver, that seems more complete than this patch but
requires a rebase on Maxime's patches:



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

Re: [PATCH 1/1] media: rc: Add NVIDIA IR keymapping

[Sean Young]

On Fri, Apr 20, 2018 at 11:47:47AM -0700, Vladislav Zhurba wrote:
> From: Jun Yan 
> 
> Add keymap with NEC and SONY12 protocol for NVIDIA IR
> 
> Signed-off-by: Jun Yan 
> Signed-off-by: marting 
> Signed-off-by: Daniel Fu 
> Signed-off-by: Vladislav Zhurba 
> ---
>  drivers/media/rc/keymaps/Makefile|  2 +
>  drivers/media/rc/keymaps/rc-nvidia-nec.c | 66 
>  drivers/media/rc/keymaps/rc-nvidia.c | 66 
>  include/media/rc-map.h   |  2 +
>  4 files changed, 136 insertions(+)
>  create mode 100644 drivers/media/rc/keymaps/rc-nvidia-nec.c
>  create mode 100644 drivers/media/rc/keymaps/rc-nvidia.c
> 
> diff --git a/drivers/media/rc/keymaps/Makefile 
> b/drivers/media/rc/keymaps/Makefile
> index d6b913a3032d..1d08500462fd 100644
> --- a/drivers/media/rc/keymaps/Makefile
> +++ b/drivers/media/rc/keymaps/Makefile
> @@ -75,6 +75,8 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
>   rc-nec-terratec-cinergy-xs.o \
>   rc-norwood.o \
>   rc-npgtech.o \
> + rc-nvidia.o \
> + rc-nvidia-nec.o \
>   rc-pctv-sedna.o \
>   rc-pinnacle-color.o \
>   rc-pinnacle-grey.o \
> diff --git a/drivers/media/rc/keymaps/rc-nvidia-nec.c 
> b/drivers/media/rc/keymaps/rc-nvidia-nec.c
> new file mode 100644
> index ..c910a2a683f6
> --- /dev/null
> +++ b/drivers/media/rc/keymaps/rc-nvidia-nec.c
> @@ -0,0 +1,66 @@
> +/* Keytable for NVIDIA Remote Controller
> + *
> + * Copyright (c) 2014-2018, NVIDIA CORPORATION. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + *
> + */

Would it be possible to use the SPDX-License-Identifier please.

> +#include 
> +#include 
> +
> +static struct rc_map_table foster_table[] = {
> + { 0x807e12, KEY_VOLUMEUP },
> + { 0x807e15, KEY_VOLUMEDOWN },
> + { 0x807e0c, KEY_UP },
> + { 0x807e0e, KEY_DOWN },
> + { 0x807e0b, KEY_LEFT },
> + { 0x807e0d, KEY_RIGHT },
> + { 0x807e09, KEY_HOMEPAGE },
> + { 0x807e06, KEY_POWER },
> + { 0x807e03, KEY_SELECT },
> + { 0x807e02, KEY_BACK },
> + { 0x807e14, KEY_MUTE },
> + { 0x807e20, KEY_PLAYPAUSE },
> + { 0x807e11, KEY_PLAYCD },
> + { 0x807e08, KEY_PAUSECD },
> + { 0x807e07, KEY_STOP },
> + { 0x807e0f, KEY_FASTFORWARD },
> + { 0x807e0a, KEY_REWIND },
> + { 0x807e41, KEY_SLEEP },
> + { 0x807e45, KEY_WAKEUP },
> +};
> +
> +static struct rc_map_list nvidia_map = {
> + .map = {
> + .scan = foster_table,
> + .size = ARRAY_SIZE(foster_table),
> + .rc_type = RC_TYPE_NEC,

This does not compile against mainline any more. Should be RC_PROTO_NEC.

> + .name = RC_MAP_NVIDIA_NEC,

Would it be possible to give it a more descriptive name, not just
nvidia but also the product name.

> + }
> +};
> +
> +static int __init init_rc_map_nvidia(void)
> +{
> + return rc_map_register(_map);
> +}
> +
> +static void __exit exit_rc_map_nvidia(void)
> +{
> + rc_map_unregister(_map);
> +}
> +
> +module_init(init_rc_map_nvidia);
> +module_exit(exit_rc_map_nvidia);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Daniel Fu ");
> diff --git a/drivers/media/rc/keymaps/rc-nvidia.c 
> b/drivers/media/rc/keymaps/rc-nvidia.c
> new file mode 100644
> index ..9767d85a6c9e
> --- /dev/null
> +++ b/drivers/media/rc/keymaps/rc-nvidia.c

Same comments for this file.

> @@ -0,0 +1,66 @@
> +/* Keytable for NVIDIA Remote Controller
> + *
> + * Copyright (c) 2014-2018, NVIDIA CORPORATION. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If 

[PATCH 1/1] ov5640: Use dev_fwnode() to obtain device's fwnode

[Sakari Ailus]

Use dev_fwnode() on the device instead of getting an fwnode handle of the
device's OF node. The result is the same on OF-based systems and looks
better, too.

Signed-off-by: Sakari Ailus 
---
 drivers/media/i2c/ov5640.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 852026baa2e7..7acd3b44d194 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -2536,8 +2536,8 @@ static int ov5640_probe(struct i2c_client *client,
 
sensor->ae_target = 52;
 
-   endpoint = fwnode_graph_get_next_endpoint(
-   of_fwnode_handle(client->dev.of_node), NULL);
+   endpoint = fwnode_graph_get_next_endpoint(dev_fwnode(>dev),
+ NULL);
if (!endpoint) {
dev_err(dev, "endpoint node not found\n");
return -EINVAL;
-- 
2.11.0