cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Fri Dec 22 05:00:15 CET 2017
media-tree git hash:ae49432810c5cca2143afc1445edad6582c9f270
media_build git hash:   fd6010ac1bcdf54a3a2b2752088def1b21b5e457
v4l-utils git hash: 6049ea8bd64f9d78ef87ef0c2b3dc9b5de1ca4a1
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0-3911-g6f737e1f
smatch version: v0.5.0-3911-g6f737e1f
host hardware:  x86_64
host os:4.13.0-164

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-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: ERRORS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: OK
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: OK
linux-4.7.5-i686: OK
linux-4.8-i686: OK
linux-4.9.26-i686: OK
linux-4.10.14-i686: OK
linux-4.11-i686: OK
linux-4.12.1-i686: OK
linux-4.13-i686: OK
linux-4.14-i686: OK
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9.26-x86_64: WARNINGS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12.1-x86_64: WARNINGS
linux-4.13-x86_64: OK
linux-4.14-x86_64: OK
apps: OK
spec-git: OK
smatch: OK

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH 1/2] [media] Add Rockchip RK1608 driver

[Jacob Chen]

Hi leo,


2017-12-12 14:28 GMT+08:00 Leo Wen :
> Rk1608 is used as a PreISP to link on Soc, which mainly has two functions.
> One is to download the firmware of RK1608, and the other is to match the
> extra sensor such as camera and enable sensor by calling sensor's s_power.
>
> use below v4l2-ctl command to capture frames.
>
> v4l2-ctl --verbose -d /dev/video1 --stream-mmap=2
> --stream-to=/tmp/stream.out --stream-count=60 --stream-poll
>
> use below command to playback the video on your PC.
>
> mplayer ./stream.out -loop 0 -demuxer rawvideo -rawvideo
> w=640:h=480:size=$((640*480*3/2)):format=NV12
>
> Signed-off-by: Leo Wen 
> ---
>  MAINTAINERS|6 +
>  drivers/media/spi/Makefile |1 +
>  drivers/media/spi/rk1608.c | 1165 
> 
>  drivers/media/spi/rk1608.h |  366 ++
>  4 files changed, 1538 insertions(+)
>  create mode 100644 drivers/media/spi/rk1608.c
>  create mode 100644 drivers/media/spi/rk1608.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 82ad0ea..48235d8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -128,6 +128,12 @@ Maintainers List (try to look for most precise areas 
> first)
>
> ---
>
> +ROCKCHIP RK1608 DRIVER
> +M: Leo Wen 
> +S: Maintained
> +F: drivers/media/platform/spi/rk1608.c
> +F: drivers/media/platform/spi/rk1608.h
> +
>  3C59X NETWORK DRIVER
>  M: Steffen Klassert 
>  L: net...@vger.kernel.org
> diff --git a/drivers/media/spi/Makefile b/drivers/media/spi/Makefile
> index ea64013..9d9d9ec 100644
> --- a/drivers/media/spi/Makefile
> +++ b/drivers/media/spi/Makefile
> @@ -1 +1,2 @@
>  obj-$(CONFIG_VIDEO_GS1662) += gs1662.o
> +obj-$(CONFIG_ROCKCHIP_RK1608) += rk1608.o
> diff --git a/drivers/media/spi/rk1608.c b/drivers/media/spi/rk1608.c
> new file mode 100644
> index 000..e646204
> --- /dev/null
> +++ b/drivers/media/spi/rk1608.c
> @@ -0,0 +1,1165 @@
> +/**
> + * Rockchip rk1608 driver
> + *
> + * Copyright (C) 2017 Rockchip Electronics Co., Ltd.
> + *
> + * This software is available to you under a choice of one of two
> + * licenses.  You may choose to be licensed under the terms of the GNU
> + * General Public License (GPL) Version 2, available from the file
> + * COPYING in the main directory of this source tree, or the
> + * OpenIB.org BSD license below:
> + *
> + * Redistribution and use in source and binary forms, with or
> + * without modification, are permitted provided that the following
> + * conditions are met:
> + *
> + *  - Redistributions of source code must retain the above
> + *copyright notice, this list of conditions and the following
> + *disclaimer.
> + *
> + *  - Redistributions in binary form must reproduce the above
> + *copyright notice, this list of conditions and the following
> + *disclaimer in the documentation and/or other materials
> + *provided with the distribution.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
> + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> + * SOFTWARE.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "rk1608.h"
> +
> +/**
> + * Rk1608 is used as the Pre-ISP to link on Soc, which mainly has two
> + * functions. One is to download the firmware of RK1608, and the other
> + * is to match the extra sensor such as camera and enable sensor by
> + * calling sensor's s_power.
> + * |---|
> + * | Sensor Camera |
> + * |---|
> + * |---||--|
> + * |---||--|
> + * |---\/--|
> + * | Pre-ISP RK1608|
> + * |---|
> + * |---||--|
> + * |---||--|
> + * |---\/--|
> + * |  Rockchip Soc |
> + * |---|
> + * Data Transfer As shown above. In RK1608, the data received from the
> + * extra sensor,and it is passed to the Soc through ISP.
> + */
> +struct rk1608_state {
> +   struct v4l2_subdev  sd;
> +   struct v4l2_subdev  *sensor_sd;
> +   struct device   *dev;
> +   struct spi_device   *spi;
> +   struct media_padpad;
> +   struct clk  *mclk;
> +   struct mutex

[GIT PULL v2 for 4.16] An ordinary pile of atomisp cleanups and fixes

[Sakari Ailus]

Hi Mauro,

Here's the regular pile of atomisp cleanups and some fixes, too.

since v1:

- Add Andy's cleanups and fixes.

Please pull.


The following changes since commit ae49432810c5cca2143afc1445edad6582c9f270:

  media: ddbridge: improve ddb_ports_attach() failure handling (2017-12-19 
07:18:38 -0500)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git atomisp

for you to fetch changes up to e4e1b698c1a67f1d58ca5c232c1b44fa77bd1a7b:

  staging: atomisp: Fix DMI matching entry for MRD7 (2017-12-21 23:44:26 +0200)


Aishwarya Pant (1):
  staging: atomisp2: replace DEVICE_ATTR with DEVICE_ATTR_RO

Andy Shevchenko (10):
  staging: atomisp: Don't leak GPIO resources if clk_get() failed
  staging: atomisp: Remove duplicate NULL-check
  staging: atomisp: lm3554: Fix control values
  staging: atomisp: Disable custom format for now
  staging: atomisp: Remove non-ACPI leftovers
  staging: atomisp: Switch to use struct device_driver directly
  staging: atomisp: Remove redundant PCI code
  staging: atomisp: Unexport local function
  staging: atomisp: Use standard DMI match table
  staging: atomisp: Fix DMI matching entry for MRD7

Arnd Bergmann (1):
  staging: atomisp: convert timestamps to ktime_t

Jeremy Sowden (2):
  media: staging: atomisp: fix for sparse "using plain integer as NULL 
pointer" warnings.
  media: staging: atomisp: fixes for "symbol was not declared. Should it be 
static?" sparse warnings.

Riccardo Schirone (4):
  staging: add missing blank line after declarations in atomisp-ov5693
  staging: improve comments usage in atomisp-ov5693
  staging: improves comparisons readability in atomisp-ov5693
  staging: fix indentation in atomisp-ov5693

Sergiy Redko (1):
  Staging: media: atomisp: made function static

Sinan Kaya (1):
  atomisp: deprecate pci_get_bus_and_slot()

 drivers/staging/media/atomisp/i2c/atomisp-gc0310.c |  10 +-
 drivers/staging/media/atomisp/i2c/atomisp-gc2235.c |   8 +-
 drivers/staging/media/atomisp/i2c/atomisp-lm3554.c |  38 +++---
 .../staging/media/atomisp/i2c/atomisp-mt9m114.c|   8 +-
 drivers/staging/media/atomisp/i2c/atomisp-ov2680.c |  10 +-
 drivers/staging/media/atomisp/i2c/atomisp-ov2722.c |  17 +--
 drivers/staging/media/atomisp/i2c/ov2680.h |   1 -
 .../media/atomisp/i2c/ov5693/atomisp-ov5693.c  |  94 ---
 drivers/staging/media/atomisp/i2c/ov5693/ov5693.h  |   2 +-
 drivers/staging/media/atomisp/i2c/ov8858.c |  43 ---
 .../staging/media/atomisp/include/linux/atomisp.h  |   2 +
 .../atomisp/include/linux/atomisp_gmin_platform.h  |   1 -
 .../media/atomisp/pci/atomisp2/atomisp_drvfs.c |  17 ++-
 .../media/atomisp/pci/atomisp2/atomisp_drvfs.h |   5 +-
 .../media/atomisp/pci/atomisp2/atomisp_internal.h  |   1 -
 .../media/atomisp/pci/atomisp2/atomisp_ioctl.c |   5 +-
 .../media/atomisp/pci/atomisp2/atomisp_subdev.c|   2 +
 .../media/atomisp/pci/atomisp2/atomisp_v4l2.c  |  12 +-
 .../isp/kernels/eed1_8/ia_css_eed1_8.host.c|  24 ++--
 .../css2400/runtime/debug/src/ia_css_debug.c   |   1 +
 .../isp_param/interface/ia_css_isp_param_types.h   |   2 +-
 .../staging/media/atomisp/pci/atomisp2/hmm/hmm.c   |   8 +-
 .../platform/intel-mid/atomisp_gmin_platform.c | 129 +
 23 files changed, 221 insertions(+), 219 deletions(-)

-- 
Kind regards,

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

Re: [PATCH v1 05/10] staging: atomisp: Remove non-ACPI leftovers

[Sakari Ailus]

Hi Andy and Dan,

On Wed, Dec 20, 2017 at 12:24:36PM +0200, Andy Shevchenko wrote:
> On Wed, Dec 20, 2017 at 6:54 AM, Dan Carpenter  
> wrote:
> > On Tue, Dec 19, 2017 at 10:59:52PM +0200, Andy Shevchenko wrote:
> >> @@ -1147,10 +1145,8 @@ static int gc2235_probe(struct i2c_client *client)
> >>   if (ret)
> >>   gc2235_remove(client);
> >
> > This error handling is probably wrong...
> >
> 
> Thanks for pointing to this, but I'm not going to fix this by the
> following reasons:
> 1. I admit the driver's code is ugly
> 2. It's staging code
> 3. My patch does not touch those lines
> 4. My purpose is to get it working first.
> 
> Feel free to send a followup with a good clean up which I agree with.

Yeah, there's a lot of ugly stuff in this driver... I understand Andy's
patches address problems with functionality, let's make error handling
fixes separately.

So I'm applying these now.

Thanks!

-- 
Kind regards,

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

Re: [PATCH v4 00/18] kernel-doc: add supported to document nested structs

[Mauro Carvalho Chehab]

Em Thu, 21 Dec 2017 14:08:43 -0700
Jonathan Corbet  escreveu:

> On Mon, 18 Dec 2017 10:30:01 -0200
> Mauro Carvalho Chehab  wrote:
> 
> > This is a rebased version of my patch series that add support for
> > nested structs on kernel-doc. With this version, it won't produce anymore
> > hundreds of identical warnings, as patch 17 removes the warning
> > duplication.
> > 
> > Excluding warnings about duplicated Note: section at hash.h, before
> > this series, it reports 166 kernel-doc warnings. After this patch series,
> > it reports 123 kernel-doc warnings, being 51 from DVB. I have already a 
> > patch
> > series that will cleanup those new DVB warnings due to nested structs.
> > 
> > So, the net result is that the number of warnings is reduced with
> > this version.  
> 
> This seems like a great set of improvements overall, and I love getting
> rid of all that old kernel-doc code. 

> I will note that it makes a full
> htmldocs build take 20-30 seconds longer, which is not entirely
> welcome, but so be it. Someday, I guess, $SOMEBODY should see if there's
> some low-hanging optimization fruit there.

Yeah. Well, I used a recursive algorithm, with can be painfull if there
are mang things to parse.

Anyway, I didn't notice it, because there was a major performance regression
that happened recently that it is affecting all my sphinx builds: trying to
compile stuff in parallel with SPHINXOPTS=-j5 is crashing with:

# Loaded extensions:
#   kfigure (1.0.0) from /devel/v4l/patchwork/Documentation/sphinx/kfigure.py
#   kernel_include (1.0) from 
/devel/v4l/patchwork/Documentation/sphinx/kernel_include.py
#   rstFlatTable (1.0) from 
/devel/v4l/patchwork/Documentation/sphinx/rstFlatTable.py
#   cdomain (1.0) from /devel/v4l/patchwork/Documentation/sphinx/cdomain.py
#   kerneldoc (1.0) from /devel/v4l/patchwork/Documentation/sphinx/kerneldoc.py
#   alabaster (0.7.10) from 
/devel/v4l/docs/sphinx_1.4/lib/python2.7/site-packages/alabaster/__init__.pyc
#   sphinx.ext.imgmath (1.4.9) from 
/devel/v4l/docs/sphinx_1.4/lib/python2.7/site-packages/sphinx/ext/imgmath.pyc
Traceback (most recent call last):
  File 
"/devel/v4l/docs/sphinx_1.4/lib/python2.7/site-packages/sphinx/cmdline.py", 
line 244, in main
app.build(opts.force_all, filenames)
  File 
"/devel/v4l/docs/sphinx_1.4/lib/python2.7/site-packages/sphinx/application.py", 
line 297, in build
self.builder.build_update()
  File 
"/devel/v4l/docs/sphinx_1.4/lib/python2.7/site-packages/sphinx/builders/__init__.py",
 line 251, in build_update
'out of date' % len(to_build))
  File 
"/devel/v4l/docs/sphinx_1.4/lib/python2.7/site-packages/sphinx/builders/__init__.py",
 line 265, in build
self.doctreedir, self.app))
  File 
"/devel/v4l/docs/sphinx_1.4/lib/python2.7/site-packages/sphinx/environment.py", 
line 567, in update
self._read_parallel(docnames, app, nproc=app.parallel)
  File 
"/devel/v4l/docs/sphinx_1.4/lib/python2.7/site-packages/sphinx/environment.py", 
line 625, in _read_parallel
tasks.join()
  File 
"/devel/v4l/docs/sphinx_1.4/lib/python2.7/site-packages/sphinx/util/parallel.py",
 line 92, in join
self._join_one()
  File 
"/devel/v4l/docs/sphinx_1.4/lib/python2.7/site-packages/sphinx/util/parallel.py",
 line 97, in _join_one
exc, result = pipe.recv()
EOFError

I had to change my build scripts to remove parallel build, with increased
*a lot* the building time. So, right now, I just go out to take a coffee
or two when building documentation, as, without -j (even without this
patch series), is really slow.

If someone wants to look into it, the breakage happened by the time
I upgraded to Fedora 27 and Kernel 4.14 was released. Yet, I'm using
pip for Sphinx.

So, I dunno what's the culprit. I didn't have time yet to investigate.

> Applied, thanks.

Thank you!

Regards,
Mauro

Re: [PATCH v4 00/18] kernel-doc: add supported to document nested structs

[Jonathan Corbet]

On Mon, 18 Dec 2017 10:30:01 -0200
Mauro Carvalho Chehab  wrote:

> This is a rebased version of my patch series that add support for
> nested structs on kernel-doc. With this version, it won't produce anymore
> hundreds of identical warnings, as patch 17 removes the warning
> duplication.
> 
> Excluding warnings about duplicated Note: section at hash.h, before
> this series, it reports 166 kernel-doc warnings. After this patch series,
> it reports 123 kernel-doc warnings, being 51 from DVB. I have already a patch
> series that will cleanup those new DVB warnings due to nested structs.
> 
> So, the net result is that the number of warnings is reduced with
> this version.

This seems like a great set of improvements overall, and I love getting
rid of all that old kernel-doc code.  I will note that it makes a full
htmldocs build take 20-30 seconds longer, which is not entirely
welcome, but so be it.  Someday, I guess, $SOMEBODY should see if there's
some low-hanging optimization fruit there.

Applied, thanks.

jon

Re: [PATCH v6 4/6] [media] vb2: add in-fence support to QBUF

[Gustavo Padovan]

2017-12-21 Mauro Carvalho Chehab :

> Em Mon, 11 Dec 2017 16:27:39 -0200
> Gustavo Padovan  escreveu:
> 
> > From: Gustavo Padovan 
> > 
> > Receive in-fence from userspace and add support for waiting on them
> > before queueing the buffer to the driver. Buffers can't be queued to the
> > driver before its fences signal. And a buffer can't be queue to the driver
> > out of the order they were queued from userspace. That means that even if
> > it fence signal it must wait all other buffers, ahead of it in the queue,
> > to signal first.
> > 
> > If the fence for some buffer fails we do not queue it to the driver,
> > instead we mark it as error and wait until the previous buffer is done
> > to notify userspace of the error. We wait here to deliver the buffers back
> > to userspace in order.
> > 
> > v7:
> > - get rid of the fence array stuff for ordering and just use
> > get_num_buffers_ready() (Hans)
> > - fix issue of queuing the buffer twice (Hans)
> > - avoid the dma_fence_wait() in core_qbuf() (Alex)
> > - merge preparation commit in
> > 
> > v6:
> > - With fences always keep the order userspace queues the buffers.
> > - Protect in_fence manipulation with a lock (Brian Starkey)
> > - check if fences have the same context before adding a fence array
> > - Fix last_fence ref unbalance in __set_in_fence() (Brian Starkey)
> > - Clean up fence if __set_in_fence() fails (Brian Starkey)
> > - treat -EINVAL from dma_fence_add_callback() (Brian Starkey)
> > 
> > v5: - use fence_array to keep buffers ordered in vb2 core when
> > needed (Brian Starkey)
> > - keep backward compat on the reserved2 field (Brian Starkey)
> > - protect fence callback removal with lock (Brian Starkey)
> > 
> > v4:
> > - Add a comment about dma_fence_add_callback() not returning a
> > error (Hans)
> > - Call dma_fence_put(vb->in_fence) if fence signaled (Hans)
> > - select SYNC_FILE under config VIDEOBUF2_CORE (Hans)
> > - Move dma_fence_is_signaled() check to __enqueue_in_driver() (Hans)
> > - Remove list_for_each_entry() in __vb2_core_qbuf() (Hans)
> > -  Remove if (vb->state != VB2_BUF_STATE_QUEUED) from
> > vb2_start_streaming() (Hans)
> > - set IN_FENCE flags on __fill_v4l2_buffer (Hans)
> > - Queue buffers to the driver as soon as they are ready (Hans)
> > - call fill_user_buffer() after queuing the buffer (Hans)
> > - add err: label to clean up fence
> > - add dma_fence_wait() before calling vb2_start_streaming()
> > 
> > v3: - document fence parameter
> > - remove ternary if at vb2_qbuf() return (Mauro)
> > - do not change if conditions behaviour (Mauro)
> > 
> > v2:
> > - fix vb2_queue_or_prepare_buf() ret check
> > - remove check for VB2_MEMORY_DMABUF only (Javier)
> > - check num of ready buffers to start streaming
> > - when queueing, start from the first ready buffer
> > - handle queue cancel
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/media/v4l2-core/Kconfig  |   1 +
> >  drivers/media/v4l2-core/videobuf2-core.c | 154 
> > +++
> >  drivers/media/v4l2-core/videobuf2-v4l2.c |  29 +-
> >  include/media/videobuf2-core.h   |  14 ++-
> >  4 files changed, 177 insertions(+), 21 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/Kconfig 
> > b/drivers/media/v4l2-core/Kconfig
> > index a35c33686abf..3f988c407c80 100644
> > --- a/drivers/media/v4l2-core/Kconfig
> > +++ b/drivers/media/v4l2-core/Kconfig
> > @@ -83,6 +83,7 @@ config VIDEOBUF_DVB
> >  # Used by drivers that need Videobuf2 modules
> >  config VIDEOBUF2_CORE
> > select DMA_SHARED_BUFFER
> > +   select SYNC_FILE
> > tristate
> >  
> >  config VIDEOBUF2_MEMOPS
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> > b/drivers/media/v4l2-core/videobuf2-core.c
> > index a8589d96ef72..520aa3c7d9f0 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -346,6 +346,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum 
> > vb2_memory memory,
> > vb->index = q->num_buffers + buffer;
> > vb->type = q->type;
> > vb->memory = memory;
> > +   spin_lock_init(>fence_cb_lock);
> > for (plane = 0; plane < num_planes; ++plane) {
> > vb->planes[plane].length = plane_sizes[plane];
> > vb->planes[plane].min_length = plane_sizes[plane];
> > @@ -928,7 +929,7 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
> > vb2_buffer_state state)
> >  
> > switch (state) {
> > case VB2_BUF_STATE_QUEUED:
> > -   return;
> > +   break;
> > case VB2_BUF_STATE_REQUEUEING:
> > if (q->start_streaming_called)
> > __enqueue_in_driver(vb);
> > @@ -938,6 +939,16 @@ 

Re: [PATCH v6 3/6] [media] vb2: add explicit fence user API

[Gustavo Padovan]

2017-12-21 Mauro Carvalho Chehab :

> Em Mon, 11 Dec 2017 16:27:38 -0200
> Gustavo Padovan  escreveu:
> 
> > From: Gustavo Padovan 
> > 
> > Turn the reserved2 field into fence_fd that we will use to send
> > an in-fence to the kernel and return an out-fence from the kernel to
> > userspace.
> > 
> > Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that should be used
> > when sending a fence to the kernel to be waited on, and
> > V4L2_BUF_FLAG_OUT_FENCE, to ask the kernel to give back an out-fence.
> > 
> > v4:
> > - make it a union with reserved2 and fence_fd (Hans Verkuil)
> > 
> > v3:
> > - make the out_fence refer to the current buffer (Hans Verkuil)
> > 
> > v2: add documentation
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  Documentation/media/uapi/v4l/buffer.rst   | 15 +++
> >  drivers/media/usb/cpia2/cpia2_v4l.c   |  2 +-
> >  drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  4 ++--
> >  drivers/media/v4l2-core/videobuf2-v4l2.c  |  2 +-
> >  include/uapi/linux/videodev2.h|  7 ++-
> >  5 files changed, 25 insertions(+), 5 deletions(-)
> > 
> > diff --git a/Documentation/media/uapi/v4l/buffer.rst 
> > b/Documentation/media/uapi/v4l/buffer.rst
> > index ae6ee73f151c..eeefbd2547e7 100644
> > --- a/Documentation/media/uapi/v4l/buffer.rst
> > +++ b/Documentation/media/uapi/v4l/buffer.rst
> > @@ -648,6 +648,21 @@ Buffer Flags
> >- Start Of Exposure. The buffer timestamp has been taken when the
> > exposure of the frame has begun. This is only valid for the
> > ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` buffer type.
> > +* .. _`V4L2-BUF-FLAG-IN-FENCE`:
> > +
> > +  - ``V4L2_BUF_FLAG_IN_FENCE``
> > +  - 0x0020
> > +  - Ask V4L2 to wait on fence passed in ``fence_fd`` field. The buffer
> > +   won't be queued to the driver until the fence signals.
> > +
> > +* .. _`V4L2-BUF-FLAG-OUT-FENCE`:
> > +
> > +  - ``V4L2_BUF_FLAG_OUT_FENCE``
> > +  - 0x0040
> > +  - Request a fence to be attached to the buffer. The ``fence_fd``
> > +   field on
> > +   :ref:`VIDIOC_QBUF` is used as a return argument to send the out-fence
> > +   fd to userspace.
> >  
> >  
> >  
> > diff --git a/drivers/media/usb/cpia2/cpia2_v4l.c 
> > b/drivers/media/usb/cpia2/cpia2_v4l.c
> > index a1c59f19cf2d..7d7459fa2077 100644
> > --- a/drivers/media/usb/cpia2/cpia2_v4l.c
> > +++ b/drivers/media/usb/cpia2/cpia2_v4l.c
> > @@ -948,7 +948,7 @@ static int cpia2_dqbuf(struct file *file, void *fh, 
> > struct v4l2_buffer *buf)
> > buf->sequence = cam->buffers[buf->index].seq;
> > buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer;
> > buf->length = cam->frame_size;
> > -   buf->reserved2 = 0;
> > +   buf->fence_fd = -1;
> > buf->reserved = 0;
> > memset(>timecode, 0, sizeof(buf->timecode));
> >  
> > diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> > b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> > index 821f2aa299ae..3a31d318df2a 100644
> > --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> > +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> > @@ -370,7 +370,7 @@ struct v4l2_buffer32 {
> > __s32   fd;
> > } m;
> > __u32   length;
> > -   __u32   reserved2;
> > +   __s32   fence_fd;
> > __u32   reserved;
> >  };
> >  
> > @@ -533,7 +533,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer *kp, 
> > struct v4l2_buffer32 __user
> > put_user(kp->timestamp.tv_usec, >timestamp.tv_usec) ||
> > copy_to_user(>timecode, >timecode, sizeof(struct 
> > v4l2_timecode)) ||
> > put_user(kp->sequence, >sequence) ||
> > -   put_user(kp->reserved2, >reserved2) ||
> > +   put_user(kp->fence_fd, >fence_fd) ||
> > put_user(kp->reserved, >reserved) ||
> > put_user(kp->length, >length))
> > return -EFAULT;
> > diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
> > b/drivers/media/v4l2-core/videobuf2-v4l2.c
> > index 4075314a6989..4a5244ee2c58 100644
> > --- a/drivers/media/v4l2-core/videobuf2-v4l2.c
> > +++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
> > @@ -203,7 +203,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, 
> > void *pb)
> > b->timestamp = ns_to_timeval(vb->timestamp);
> > b->timecode = vbuf->timecode;
> > b->sequence = vbuf->sequence;
> > -   b->reserved2 = 0;
> > +   b->fence_fd = -1;
> 
> The patch itself looks ok. I'm just in doubt here, but it is probably
> ok to change its default to -1.

Right. What we can do is return 0 if the OUT_FENCE flag is not set.

Gustavo

Re: [PATCH v6 1/6] [media] vb2: add is_unordered callback for drivers

[Gustavo Padovan]

2017-12-21 Mauro Carvalho Chehab :

> Em Mon, 11 Dec 2017 16:27:36 -0200
> Gustavo Padovan  escreveu:
> 
> > From: Gustavo Padovan 
> > 
> > Explicit synchronization benefits a lot from ordered queues, they fit
> > better in a pipeline with DRM for example so create a opt-in way for
> > drivers notify videobuf2 that the queue is unordered.
> > 
> > Drivers don't need implement it if the queue is ordered.
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  include/media/videobuf2-core.h | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> > index ef9b64398c8c..eddb38a2a2f3 100644
> > --- a/include/media/videobuf2-core.h
> > +++ b/include/media/videobuf2-core.h
> > @@ -368,6 +368,9 @@ struct vb2_buffer {
> >   * callback by calling vb2_buffer_done() with either
> >   * %VB2_BUF_STATE_DONE or %VB2_BUF_STATE_ERROR; may use
> >   * vb2_wait_for_all_buffers() function
> > + * @is_unordered:  tell if the queue format is unordered. The default is
> > + * assumed to be ordered and this function only needs to
> > + * be implemented for unordered queues.
> >   * @buf_queue: passes buffer vb to the driver; driver may start
> >   * hardware operation on this buffer; driver should give
> >   * the buffer back by calling vb2_buffer_done() function;
> > @@ -391,6 +394,7 @@ struct vb2_ops {
> >  
> > int (*start_streaming)(struct vb2_queue *q, unsigned int count);
> > void (*stop_streaming)(struct vb2_queue *q);
> > +   int (*is_unordered)(struct vb2_queue *q);
> >  
> > void (*buf_queue)(struct vb2_buffer *vb);
> >  };
> > @@ -564,6 +568,7 @@ struct vb2_queue {
> > u32 cnt_wait_finish;
> > u32 cnt_start_streaming;
> > u32 cnt_stop_streaming;
> > +   u32 cnt_is_unordered;
> 
> If I understand, this is just a bit, right?
> 
> if so, better to declare it as:
> 
>   u32 cnt_is_unordered : 1;

no, is_unordered() is a vb2 callback to ask drivers if their current
queue is not ordered and cnt_is_unordered is the counter of how many
times this callback was called. This happens for all vb2 callbacks, see
the other counters above, so I decided to add one for is_unordered() as
well.

Gustavo

Re: [PATCH v6 0/6] V4L2 Explicit Synchronization

[Gustavo Padovan]

2017-12-21 Mauro Carvalho Chehab :

> Em Mon, 11 Dec 2017 16:27:35 -0200
> Gustavo Padovan  escreveu:
> 
> > From: Gustavo Padovan 
> > 
> > Hi,
> > 
> > One more iteration of the explicit fences patches, please refer
> > to the previous version[1] for more details about the general
> > mechanism
> > 
> > This version makes the patchset and the implementation much more
> > simple, to start we are not using a ordered capability anymore,
> > but instead we have a VIDIOC_ENUM_FMT flag to tell when the
> > queue in not ordered. Drivers with ordered queues/formats don't
> > need implement anything. See patches 1 and 2 for more details.
> > 
> > The implementation of in-fences and out-fences were condensed in
> > just patches 4 and 5, making it more self-contained and easy to
> > understand. See the patches for detailed changelog.
> > 
> > Please review! Thanks.
> 
> Hi Gustavo,
> 
> As I was afraid, the changes at the VB2 core makes it non-generic,
> breaking support for the DVB VB2 patchset. That's a branch with
> both patchsets applied:
> 
>   
> https://git.linuxtv.org/mchehab/experimental.git/log/?h=dvb_mmap%2bexplicit_fences
> 
> 
> With the explicit fences patchset, the DVB streaming breaks:
> 
>   $ sudo perf stat dvbv5-zap -c ~/dvb_channel.conf "TV Brasilia RedeTV!"  
> -o /dev/null -t120 -R
>   Usando demux 'dvb0.demux0'
>   lendo canais do arquivo  '/home/mchehab/dvb_channel.conf'
>   sintonizando em 557142857 Hz
>   PID de vídeo 273
> dvb_set_pesfilter 273
>   PID de áudio 274
> dvb_set_pesfilter 274
>   Travado  (0x1f) Sinal= -85,22dBm C/N= 18,57dB UCB= 8589933955 pós-BER= 0
>   Travado  (0x1f) Sinal= -85,24dBm C/N= 18,57dB UCB= 8589933955 pós-BER= 0
>   Gravação iniciada para o arquivo '/dev/null'
>   ERRO:DMX_REQBUFS failed: error=-1 (Invalid argument)
>   ERRO:[stream_to_file] Failed to setup buffers!!! (Invalid argument)
>   start streaming!!!
>   copied 0 bytes (0 Kbytes/sec)
>   Travado  (0x1f) Sinal= -85,25dBm C/N= 18,57dB UCB= 8589933955 pós-BER= 0

I haven't tried it, not sure what could break it. I'll take a look on
it.

>  Performance counter stats for 'dvbv5-zap -c /home/mchehab/dvb_channel.conf 
> TV Brasilia RedeTV! -o /dev/null -t120 -R':
> 
>7.001647  task-clock-msecs #  0.003 CPUs 
> 251  context-switches #  0.036 M/sec
>  18  CPU-migrations   #  0.003 M/sec
> 181  page-faults  #  0.026 M/sec
>17001058  cycles   #   2428.151 M/sec
>11342660  instructions #  0.667 IPC  
>  349075  cache-references # 49.856 M/sec
>   70802  cache-misses # 10.112 M/sec
> 
> 2.133343557  seconds time elapsed
> 
> It also breaks support on V4L2, when fences is not used:
> 
> $ ./contrib/test/v4l2grab 
> (kernel crashes)
> 
> I don't have a serial console on this machine to print what's
> wrong, but clearly there's something not right there :-)

2 days ago I fixed the a crash when not using fences:

https://git.kernel.org/pub/scm/linux/kernel/git/padovan/linux.git/commit/?h=v4l2-fences=704419e59437e9f7bdc369b44a612685e8663880

Gustavo

[PATCH 2/2] media: dvb-frontends/stv0910: report FEC 1/4 and 1/3 in get_frontend()

[Daniel Scheller]

From: Daniel Scheller 

The first two missing FECs in the modcod2fec fe_code_rate table were 1/4
and 1/3. Add them as they're now defined by the API.

Signed-off-by: Daniel Scheller 
---
 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 a8c99f41478b..7cf90d435083 100644
--- a/drivers/media/dvb-frontends/stv0910.c
+++ b/drivers/media/dvb-frontends/stv0910.c
@@ -1551,7 +1551,7 @@ static int get_frontend(struct dvb_frontend *fe,
APSK_32,
};
const enum fe_code_rate modcod2fec[0x20] = {
-   FEC_NONE, FEC_NONE, FEC_NONE, FEC_2_5,
+   FEC_NONE, FEC_1_4, FEC_1_3, FEC_2_5,
FEC_1_2, FEC_3_5, FEC_2_3, FEC_3_4,
FEC_4_5, FEC_5_6, FEC_8_9, FEC_9_10,
FEC_3_5, FEC_2_3, FEC_3_4, FEC_5_6,
-- 
2.13.6

[PATCH 0/2] Add FEC rates, S2X modulations and 64K transmission

[Daniel Scheller]

From: Daniel Scheller 

As the DVB API is bumped to 5.11 for the next cycle.

dddvb brings a few additional FEC rates (1/4 and 1/3), 64/128/256APSK
modulations (DVB-S2X) and the 64K transmission mode. These two rather
trivial patches bring them to mainline, and puts these missing bits
into the stv0910's get_frontend() callback (FEC 1/4 and 1/3 are handled
throughout the rest of the demod driver already).

Let's have these enums as a part of DVB core 5.11.

Daniel Scheller (2):
  media: dvb_frontend: add FEC modes, S2X modulations and 64K
transmission
  media: dvb-frontends/stv0910: report FEC 1/4 and 1/3 in get_frontend()

 Documentation/media/frontend.h.rst.exceptions |  6 ++
 drivers/media/dvb-frontends/stv0910.c |  2 +-
 include/uapi/linux/dvb/frontend.h | 13 +
 3 files changed, 20 insertions(+), 1 deletion(-)

-- 
2.13.6

[PATCH 1/2] media: dvb_frontend: add FEC modes, S2X modulations and 64K transmission

[Daniel Scheller]

From: Daniel Scheller 

Add 1/4 and 1/3 FEC ratios, 64/128/256-APSK S2X modulations and 64K
transmission mode. Update relevant doc items aswell.

Signed-off-by: Daniel Scheller 
---
 Documentation/media/frontend.h.rst.exceptions |  6 ++
 include/uapi/linux/dvb/frontend.h | 13 +
 2 files changed, 19 insertions(+)

diff --git a/Documentation/media/frontend.h.rst.exceptions 
b/Documentation/media/frontend.h.rst.exceptions
index f7c4df620a52..ae1148be0a39 100644
--- a/Documentation/media/frontend.h.rst.exceptions
+++ b/Documentation/media/frontend.h.rst.exceptions
@@ -84,6 +84,9 @@ ignore symbol APSK_16
 ignore symbol APSK_32
 ignore symbol DQPSK
 ignore symbol QAM_4_NR
+ignore symbol APSK_64
+ignore symbol APSK_128
+ignore symbol APSK_256
 
 ignore symbol SEC_VOLTAGE_13
 ignore symbol SEC_VOLTAGE_18
@@ -117,6 +120,8 @@ ignore symbol FEC_AUTO
 ignore symbol FEC_3_5
 ignore symbol FEC_9_10
 ignore symbol FEC_2_5
+ignore symbol FEC_1_4
+ignore symbol FEC_1_3
 
 ignore symbol TRANSMISSION_MODE_AUTO
 ignore symbol TRANSMISSION_MODE_1K
@@ -129,6 +134,7 @@ ignore symbol TRANSMISSION_MODE_C1
 ignore symbol TRANSMISSION_MODE_C3780
 ignore symbol TRANSMISSION_MODE_2K
 ignore symbol TRANSMISSION_MODE_8K
+ignore symbol TRANSMISSION_MODE_64K
 
 ignore symbol GUARD_INTERVAL_AUTO
 ignore symbol GUARD_INTERVAL_1_128
diff --git a/include/uapi/linux/dvb/frontend.h 
b/include/uapi/linux/dvb/frontend.h
index 4f9b4551c534..227268a657cd 100644
--- a/include/uapi/linux/dvb/frontend.h
+++ b/include/uapi/linux/dvb/frontend.h
@@ -296,6 +296,8 @@ enum fe_spectral_inversion {
  * @FEC_3_5:  Forward Error Correction Code 3/5
  * @FEC_9_10: Forward Error Correction Code 9/10
  * @FEC_2_5:  Forward Error Correction Code 2/5
+ * @FEC_1_4:  Forward Error Correction Code 1/4
+ * @FEC_1_3:  Forward Error Correction Code 1/3
  *
  * Please note that not all FEC types are supported by a given standard.
  */
@@ -313,6 +315,8 @@ enum fe_code_rate {
FEC_3_5,
FEC_9_10,
FEC_2_5,
+   FEC_1_4,
+   FEC_1_3,
 };
 
 /**
@@ -331,6 +335,9 @@ enum fe_code_rate {
  * @APSK_32:   32-APSK modulation
  * @DQPSK: DQPSK modulation
  * @QAM_4_NR:  4-QAM-NR modulation
+ * @APSK_64:   64-APSK modulation
+ * @APSK_128:  128-APSK modulation
+ * @APSK_256:  256-APSK modulation
  *
  * Please note that not all modulations are supported by a given standard.
  *
@@ -350,6 +357,9 @@ enum fe_modulation {
APSK_32,
DQPSK,
QAM_4_NR,
+   APSK_64,
+   APSK_128,
+   APSK_256,
 };
 
 /**
@@ -374,6 +384,8 @@ enum fe_modulation {
  * Single Carrier (C=1) transmission mode (DTMB only)
  * @TRANSMISSION_MODE_C3780:
  * Multi Carrier (C=3780) transmission mode (DTMB only)
+ * @TRANSMISSION_MODE_64K:
+ * Transmission mode 64K
  *
  * Please note that not all transmission modes are supported by a given
  * standard.
@@ -388,6 +400,7 @@ enum fe_transmit_mode {
TRANSMISSION_MODE_32K,
TRANSMISSION_MODE_C1,
TRANSMISSION_MODE_C3780,
+   TRANSMISSION_MODE_64K,
 };
 
 /**
-- 
2.13.6

Re: [PATCH v4 1/3] media: atomisp: convert default struct values to use compound-literals with designated initializers.

[Jeremy Sowden]

On 2017-12-19, at 14:07:49 +0200, Sakari Ailus wrote:
> On Sat, Dec 02, 2017 at 10:11:59PM +, Jeremy Sowden wrote:
> > The CSS API uses a lot of nested anonymous structs defined in object
> > macros to assign default values to its data-structures.  These have
> > been changed to use compound-literals and designated initializers to
> > make them more comprehensible and less fragile.
> >
> > The compound-literals can also be used in assignment, which means we
> > can get rid of some temporary variables whose only purpose is to be
> > initialized by one of these anonymous structs and then serve as the
> > rvalue in an assignment expression.
> >
> > Signed-off-by: Jeremy Sowden 
>
> I don't think it's useful to change the struct definition macros only
> to remove a large number of assigned fields in the next patch. How
> about merging the two patches?

I squashed all three, as you suggested.

> Please also start a new thread when re-posting a set.

Done.

J.


signature.asc
Description: PGP signature

Re: [PATCH v6 0/6] V4L2 Explicit Synchronization

[Mauro Carvalho Chehab]

Em Thu, 21 Dec 2017 16:49:31 -0200
Mauro Carvalho Chehab  escreveu:

> Em Mon, 11 Dec 2017 16:27:35 -0200
> Gustavo Padovan  escreveu:
> 
> > From: Gustavo Padovan 
> > 
> > Hi,
> > 
> > One more iteration of the explicit fences patches, please refer
> > to the previous version[1] for more details about the general
> > mechanism
> > 
> > This version makes the patchset and the implementation much more
> > simple, to start we are not using a ordered capability anymore,
> > but instead we have a VIDIOC_ENUM_FMT flag to tell when the
> > queue in not ordered. Drivers with ordered queues/formats don't
> > need implement anything. See patches 1 and 2 for more details.
> > 
> > The implementation of in-fences and out-fences were condensed in
> > just patches 4 and 5, making it more self-contained and easy to
> > understand. See the patches for detailed changelog.
> > 
> > Please review! Thanks.  
> 
> Hi Gustavo,
> 
> As I was afraid, the changes at the VB2 core makes it non-generic,
> breaking support for the DVB VB2 patchset. That's a branch with
> both patchsets applied:
> 
>   
> https://git.linuxtv.org/mchehab/experimental.git/log/?h=dvb_mmap%2bexplicit_fences
> 
> 
> With the explicit fences patchset, the DVB streaming breaks:
> 
>   $ sudo perf stat dvbv5-zap -c ~/dvb_channel.conf "TV Brasilia RedeTV!"  
> -o /dev/null -t120 -R
>   Usando demux 'dvb0.demux0'
>   lendo canais do arquivo  '/home/mchehab/dvb_channel.conf'
>   sintonizando em 557142857 Hz
>   PID de vídeo 273
> dvb_set_pesfilter 273
>   PID de áudio 274
> dvb_set_pesfilter 274
>   Travado  (0x1f) Sinal= -85,22dBm C/N= 18,57dB UCB= 8589933955 pós-BER= 0
>   Travado  (0x1f) Sinal= -85,24dBm C/N= 18,57dB UCB= 8589933955 pós-BER= 0
>   Gravação iniciada para o arquivo '/dev/null'
>   ERRO:DMX_REQBUFS failed: error=-1 (Invalid argument)
>   ERRO:[stream_to_file] Failed to setup buffers!!! (Invalid argument)
>   start streaming!!!
>   copied 0 bytes (0 Kbytes/sec)
>   Travado  (0x1f) Sinal= -85,25dBm C/N= 18,57dB UCB= 8589933955 pós-BER= 0
> 
>  Performance counter stats for 'dvbv5-zap -c /home/mchehab/dvb_channel.conf 
> TV Brasilia RedeTV! -o /dev/null -t120 -R':
> 
>7.001647  task-clock-msecs #  0.003 CPUs 
> 251  context-switches #  0.036 M/sec
>  18  CPU-migrations   #  0.003 M/sec
> 181  page-faults  #  0.026 M/sec
>17001058  cycles   #   2428.151 M/sec
>11342660  instructions #  0.667 IPC  
>  349075  cache-references # 49.856 M/sec
>   70802  cache-misses # 10.112 M/sec
> 
> 2.133343557  seconds time elapsed

Hmm... this may be unrelated. I'll need to do more tests here to know
for sure.

> 
> It also breaks support on V4L2, when fences is not used:
> 
> $ ./contrib/test/v4l2grab 
> (kernel crashes)
> 
> I don't have a serial console on this machine to print what's
> wrong, but clearly there's something not right there :-)
> 



Thanks,
Mauro

Re: [PATCH v6 4/6] [media] vb2: add in-fence support to QBUF

[Mauro Carvalho Chehab]

Em Mon, 11 Dec 2017 16:27:39 -0200
Gustavo Padovan  escreveu:

> From: Gustavo Padovan 
> 
> Receive in-fence from userspace and add support for waiting on them
> before queueing the buffer to the driver. Buffers can't be queued to the
> driver before its fences signal. And a buffer can't be queue to the driver
> out of the order they were queued from userspace. That means that even if
> it fence signal it must wait all other buffers, ahead of it in the queue,
> to signal first.
> 
> If the fence for some buffer fails we do not queue it to the driver,
> instead we mark it as error and wait until the previous buffer is done
> to notify userspace of the error. We wait here to deliver the buffers back
> to userspace in order.
> 
> v7:
>   - get rid of the fence array stuff for ordering and just use
>   get_num_buffers_ready() (Hans)
>   - fix issue of queuing the buffer twice (Hans)
>   - avoid the dma_fence_wait() in core_qbuf() (Alex)
>   - merge preparation commit in
> 
> v6:
>   - With fences always keep the order userspace queues the buffers.
>   - Protect in_fence manipulation with a lock (Brian Starkey)
>   - check if fences have the same context before adding a fence array
>   - Fix last_fence ref unbalance in __set_in_fence() (Brian Starkey)
>   - Clean up fence if __set_in_fence() fails (Brian Starkey)
>   - treat -EINVAL from dma_fence_add_callback() (Brian Starkey)
> 
> v5:   - use fence_array to keep buffers ordered in vb2 core when
>   needed (Brian Starkey)
>   - keep backward compat on the reserved2 field (Brian Starkey)
>   - protect fence callback removal with lock (Brian Starkey)
> 
> v4:
>   - Add a comment about dma_fence_add_callback() not returning a
>   error (Hans)
>   - Call dma_fence_put(vb->in_fence) if fence signaled (Hans)
>   - select SYNC_FILE under config VIDEOBUF2_CORE (Hans)
>   - Move dma_fence_is_signaled() check to __enqueue_in_driver() (Hans)
>   - Remove list_for_each_entry() in __vb2_core_qbuf() (Hans)
>   -  Remove if (vb->state != VB2_BUF_STATE_QUEUED) from
>   vb2_start_streaming() (Hans)
>   - set IN_FENCE flags on __fill_v4l2_buffer (Hans)
>   - Queue buffers to the driver as soon as they are ready (Hans)
>   - call fill_user_buffer() after queuing the buffer (Hans)
>   - add err: label to clean up fence
>   - add dma_fence_wait() before calling vb2_start_streaming()
> 
> v3:   - document fence parameter
>   - remove ternary if at vb2_qbuf() return (Mauro)
>   - do not change if conditions behaviour (Mauro)
> 
> v2:
>   - fix vb2_queue_or_prepare_buf() ret check
>   - remove check for VB2_MEMORY_DMABUF only (Javier)
>   - check num of ready buffers to start streaming
>   - when queueing, start from the first ready buffer
>   - handle queue cancel
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/media/v4l2-core/Kconfig  |   1 +
>  drivers/media/v4l2-core/videobuf2-core.c | 154 
> +++
>  drivers/media/v4l2-core/videobuf2-v4l2.c |  29 +-
>  include/media/videobuf2-core.h   |  14 ++-
>  4 files changed, 177 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
> index a35c33686abf..3f988c407c80 100644
> --- a/drivers/media/v4l2-core/Kconfig
> +++ b/drivers/media/v4l2-core/Kconfig
> @@ -83,6 +83,7 @@ config VIDEOBUF_DVB
>  # Used by drivers that need Videobuf2 modules
>  config VIDEOBUF2_CORE
>   select DMA_SHARED_BUFFER
> + select SYNC_FILE
>   tristate
>  
>  config VIDEOBUF2_MEMOPS
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> b/drivers/media/v4l2-core/videobuf2-core.c
> index a8589d96ef72..520aa3c7d9f0 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -346,6 +346,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum 
> vb2_memory memory,
>   vb->index = q->num_buffers + buffer;
>   vb->type = q->type;
>   vb->memory = memory;
> + spin_lock_init(>fence_cb_lock);
>   for (plane = 0; plane < num_planes; ++plane) {
>   vb->planes[plane].length = plane_sizes[plane];
>   vb->planes[plane].min_length = plane_sizes[plane];
> @@ -928,7 +929,7 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
> vb2_buffer_state state)
>  
>   switch (state) {
>   case VB2_BUF_STATE_QUEUED:
> - return;
> + break;
>   case VB2_BUF_STATE_REQUEUEING:
>   if (q->start_streaming_called)
>   __enqueue_in_driver(vb);
> @@ -938,6 +939,16 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
> vb2_buffer_state state)
>   wake_up(>done_wq);
>   break;
>   }
> +
> + /*
> +  * If the 

Re: [PATCH v6 3/6] [media] vb2: add explicit fence user API

[Mauro Carvalho Chehab]

Em Mon, 11 Dec 2017 16:27:38 -0200
Gustavo Padovan  escreveu:

> From: Gustavo Padovan 
> 
> Turn the reserved2 field into fence_fd that we will use to send
> an in-fence to the kernel and return an out-fence from the kernel to
> userspace.
> 
> Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that should be used
> when sending a fence to the kernel to be waited on, and
> V4L2_BUF_FLAG_OUT_FENCE, to ask the kernel to give back an out-fence.
> 
> v4:
>   - make it a union with reserved2 and fence_fd (Hans Verkuil)
> 
> v3:
>   - make the out_fence refer to the current buffer (Hans Verkuil)
> 
> v2: add documentation
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  Documentation/media/uapi/v4l/buffer.rst   | 15 +++
>  drivers/media/usb/cpia2/cpia2_v4l.c   |  2 +-
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  4 ++--
>  drivers/media/v4l2-core/videobuf2-v4l2.c  |  2 +-
>  include/uapi/linux/videodev2.h|  7 ++-
>  5 files changed, 25 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/media/uapi/v4l/buffer.rst 
> b/Documentation/media/uapi/v4l/buffer.rst
> index ae6ee73f151c..eeefbd2547e7 100644
> --- a/Documentation/media/uapi/v4l/buffer.rst
> +++ b/Documentation/media/uapi/v4l/buffer.rst
> @@ -648,6 +648,21 @@ Buffer Flags
>- Start Of Exposure. The buffer timestamp has been taken when the
>   exposure of the frame has begun. This is only valid for the
>   ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` buffer type.
> +* .. _`V4L2-BUF-FLAG-IN-FENCE`:
> +
> +  - ``V4L2_BUF_FLAG_IN_FENCE``
> +  - 0x0020
> +  - Ask V4L2 to wait on fence passed in ``fence_fd`` field. The buffer
> + won't be queued to the driver until the fence signals.
> +
> +* .. _`V4L2-BUF-FLAG-OUT-FENCE`:
> +
> +  - ``V4L2_BUF_FLAG_OUT_FENCE``
> +  - 0x0040
> +  - Request a fence to be attached to the buffer. The ``fence_fd``
> + field on
> + :ref:`VIDIOC_QBUF` is used as a return argument to send the out-fence
> + fd to userspace.
>  
>  
>  
> diff --git a/drivers/media/usb/cpia2/cpia2_v4l.c 
> b/drivers/media/usb/cpia2/cpia2_v4l.c
> index a1c59f19cf2d..7d7459fa2077 100644
> --- a/drivers/media/usb/cpia2/cpia2_v4l.c
> +++ b/drivers/media/usb/cpia2/cpia2_v4l.c
> @@ -948,7 +948,7 @@ static int cpia2_dqbuf(struct file *file, void *fh, 
> struct v4l2_buffer *buf)
>   buf->sequence = cam->buffers[buf->index].seq;
>   buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer;
>   buf->length = cam->frame_size;
> - buf->reserved2 = 0;
> + buf->fence_fd = -1;
>   buf->reserved = 0;
>   memset(>timecode, 0, sizeof(buf->timecode));
>  
> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> index 821f2aa299ae..3a31d318df2a 100644
> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> @@ -370,7 +370,7 @@ struct v4l2_buffer32 {
>   __s32   fd;
>   } m;
>   __u32   length;
> - __u32   reserved2;
> + __s32   fence_fd;
>   __u32   reserved;
>  };
>  
> @@ -533,7 +533,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer *kp, 
> struct v4l2_buffer32 __user
>   put_user(kp->timestamp.tv_usec, >timestamp.tv_usec) ||
>   copy_to_user(>timecode, >timecode, sizeof(struct 
> v4l2_timecode)) ||
>   put_user(kp->sequence, >sequence) ||
> - put_user(kp->reserved2, >reserved2) ||
> + put_user(kp->fence_fd, >fence_fd) ||
>   put_user(kp->reserved, >reserved) ||
>   put_user(kp->length, >length))
>   return -EFAULT;
> diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
> b/drivers/media/v4l2-core/videobuf2-v4l2.c
> index 4075314a6989..4a5244ee2c58 100644
> --- a/drivers/media/v4l2-core/videobuf2-v4l2.c
> +++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
> @@ -203,7 +203,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, 
> void *pb)
>   b->timestamp = ns_to_timeval(vb->timestamp);
>   b->timecode = vbuf->timecode;
>   b->sequence = vbuf->sequence;
> - b->reserved2 = 0;
> + b->fence_fd = -1;

The patch itself looks ok. I'm just in doubt here, but it is probably
ok to change its default to -1.


>   b->reserved = 0;
>  
>   if (q->is_multiplanar) {
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index a8ea632c14f0..17e163b5036d 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -926,7 +926,10 @@ struct v4l2_buffer {
>   __s32   fd;
>   } m;
>   __u32   length;
> - __u32   reserved2;
> + union {
> + __s32   fence_fd;
> +  

Re: [PATCH v6 1/6] [media] vb2: add is_unordered callback for drivers

[Mauro Carvalho Chehab]

Em Mon, 11 Dec 2017 16:27:36 -0200
Gustavo Padovan  escreveu:

> From: Gustavo Padovan 
> 
> Explicit synchronization benefits a lot from ordered queues, they fit
> better in a pipeline with DRM for example so create a opt-in way for
> drivers notify videobuf2 that the queue is unordered.
> 
> Drivers don't need implement it if the queue is ordered.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  include/media/videobuf2-core.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> index ef9b64398c8c..eddb38a2a2f3 100644
> --- a/include/media/videobuf2-core.h
> +++ b/include/media/videobuf2-core.h
> @@ -368,6 +368,9 @@ struct vb2_buffer {
>   *   callback by calling vb2_buffer_done() with either
>   *   %VB2_BUF_STATE_DONE or %VB2_BUF_STATE_ERROR; may use
>   *   vb2_wait_for_all_buffers() function
> + * @is_unordered:tell if the queue format is unordered. The default is
> + *   assumed to be ordered and this function only needs to
> + *   be implemented for unordered queues.
>   * @buf_queue:   passes buffer vb to the driver; driver may start
>   *   hardware operation on this buffer; driver should give
>   *   the buffer back by calling vb2_buffer_done() function;
> @@ -391,6 +394,7 @@ struct vb2_ops {
>  
>   int (*start_streaming)(struct vb2_queue *q, unsigned int count);
>   void (*stop_streaming)(struct vb2_queue *q);
> + int (*is_unordered)(struct vb2_queue *q);
>  
>   void (*buf_queue)(struct vb2_buffer *vb);
>  };
> @@ -564,6 +568,7 @@ struct vb2_queue {
>   u32 cnt_wait_finish;
>   u32 cnt_start_streaming;
>   u32 cnt_stop_streaming;
> + u32 cnt_is_unordered;

If I understand, this is just a bit, right?

if so, better to declare it as:

u32 cnt_is_unordered : 1;

>  #endif
>  };
>  


-- 
Thanks,
Mauro

Re: [PATCH v6 0/6] V4L2 Explicit Synchronization

[Mauro Carvalho Chehab]

Em Mon, 11 Dec 2017 16:27:35 -0200
Gustavo Padovan  escreveu:

> From: Gustavo Padovan 
> 
> Hi,
> 
> One more iteration of the explicit fences patches, please refer
> to the previous version[1] for more details about the general
> mechanism
> 
> This version makes the patchset and the implementation much more
> simple, to start we are not using a ordered capability anymore,
> but instead we have a VIDIOC_ENUM_FMT flag to tell when the
> queue in not ordered. Drivers with ordered queues/formats don't
> need implement anything. See patches 1 and 2 for more details.
> 
> The implementation of in-fences and out-fences were condensed in
> just patches 4 and 5, making it more self-contained and easy to
> understand. See the patches for detailed changelog.
> 
> Please review! Thanks.

Hi Gustavo,

As I was afraid, the changes at the VB2 core makes it non-generic,
breaking support for the DVB VB2 patchset. That's a branch with
both patchsets applied:


https://git.linuxtv.org/mchehab/experimental.git/log/?h=dvb_mmap%2bexplicit_fences


With the explicit fences patchset, the DVB streaming breaks:

$ sudo perf stat dvbv5-zap -c ~/dvb_channel.conf "TV Brasilia RedeTV!"  
-o /dev/null -t120 -R
Usando demux 'dvb0.demux0'
lendo canais do arquivo  '/home/mchehab/dvb_channel.conf'
sintonizando em 557142857 Hz
PID de vídeo 273
  dvb_set_pesfilter 273
PID de áudio 274
  dvb_set_pesfilter 274
Travado  (0x1f) Sinal= -85,22dBm C/N= 18,57dB UCB= 8589933955 pós-BER= 0
Travado  (0x1f) Sinal= -85,24dBm C/N= 18,57dB UCB= 8589933955 pós-BER= 0
Gravação iniciada para o arquivo '/dev/null'
ERRO:DMX_REQBUFS failed: error=-1 (Invalid argument)
ERRO:[stream_to_file] Failed to setup buffers!!! (Invalid argument)
start streaming!!!
copied 0 bytes (0 Kbytes/sec)
Travado  (0x1f) Sinal= -85,25dBm C/N= 18,57dB UCB= 8589933955 pós-BER= 0

 Performance counter stats for 'dvbv5-zap -c /home/mchehab/dvb_channel.conf TV 
Brasilia RedeTV! -o /dev/null -t120 -R':

   7.001647  task-clock-msecs #  0.003 CPUs 
251  context-switches #  0.036 M/sec
 18  CPU-migrations   #  0.003 M/sec
181  page-faults  #  0.026 M/sec
   17001058  cycles   #   2428.151 M/sec
   11342660  instructions #  0.667 IPC  
 349075  cache-references # 49.856 M/sec
  70802  cache-misses # 10.112 M/sec

2.133343557  seconds time elapsed

It also breaks support on V4L2, when fences is not used:

$ ./contrib/test/v4l2grab 
(kernel crashes)

I don't have a serial console on this machine to print what's
wrong, but clearly there's something not right there :-)

-- 
Thanks,
Mauro

Re: [PATCH v6 2/6] [media] v4l: add 'unordered' flag to format description ioctl

[Mauro Carvalho Chehab]

Em Mon, 11 Dec 2017 16:27:37 -0200
Gustavo Padovan  escreveu:

> From: Gustavo Padovan 
> 
> For explicit synchronization it important for userspace to know if the
> format being used by the driver can deliver the buffers back to userspace
> in the same order they were queued with QBUF.
> 
> Ordered streams fits nicely in a pipeline with DRM for example, where
> ordered buffer are expected.
> 
> Signed-off-by: Gustavo Padovan 

Looks OK to me.

> ---
>  Documentation/media/uapi/v4l/vidioc-enum-fmt.rst | 3 +++
>  include/uapi/linux/videodev2.h   | 1 +
>  2 files changed, 4 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst 
> b/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
> index 019c513df217..368115f44fc0 100644
> --- a/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
> @@ -116,6 +116,9 @@ one until ``EINVAL`` is returned.
>- This format is not native to the device but emulated through
>   software (usually libv4l2), where possible try to use a native
>   format instead for better performance.
> +* - ``V4L2_FMT_FLAG_UNORDERED``
> +  - 0x0004
> +  - This is a format that doesn't guarantee timely order of frames.
>  
>  
>  Return Value
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 1c095b5a99c5..a8ea632c14f0 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -709,6 +709,7 @@ struct v4l2_fmtdesc {
>  
>  #define V4L2_FMT_FLAG_COMPRESSED 0x0001
>  #define V4L2_FMT_FLAG_EMULATED   0x0002
> +#define V4L2_FMT_FLAG_UNORDERED  0x0004
>  
>   /* Frame Size and frame rate enumeration */
>  /*


-- 
Thanks,
Mauro

Re: [PATCH] devicetree: Add video bus switch

[Ivaylo Dimitrov]

Hi,

On 20.12.2017 19:54, Laurent Pinchart wrote:

Hi Pavel,

On Saturday, 4 February 2017 23:56:10 EET Pavel Machek wrote:

Hi!


+Required properties
+===
+
+compatible : must contain "video-bus-switch"


How generic is this? Should we have e.g. nokia,video-bus-switch? And
if so, change the file name accordingly.


Generic for "single GPIO controls the switch", AFAICT. But that should
be common enough...


Um, yes. Then... how about: video-bus-switch-gpio? No Nokia prefix.


Ok, done. I also fixed the english a bit.


+reg: The interface:
+ 0 - port for image signal processor
+ 1 - port for first camera sensor
+ 2 - port for second camera sensor


I'd say this must be pretty much specific to the one in N900. You
could have more ports. Or you could say that ports beyond 0 are
camera sensors. I guess this is good enough for now though, it can be
changed later on with the source if a need arises.


Well, I'd say that selecting between two sensors is going to be the
common case. If someone needs more than two, it will no longer be
simple GPIO, so we'll have some fixing to do.


It could be two GPIOs --- that's how the GPIO I2C mux works.

But I'd be surprised if someone ever uses something like that
again. ;-)


I'd say.. lets handle that when we see hardware like that.


Btw. was it still considered a problem that the endpoint properties
for the sensors can be different? With the g_routing() pad op which is
to be added, the ISP driver (should actually go to a framework
somewhere) could parse the graph and find the proper endpoint there.


I don't know about g_routing. I added g_endpoint_config method that
passes the configuration, and that seems to work for me.

I don't see g_routing in next-20170201 . Is there place to look?


I think there was a patch by Laurent to LMML quite some time ago. I
suppose that set will be repicked soonish.

I don't really object using g_endpoint_config() as a temporary solution;
I'd like to have Laurent's opinion on that though. Another option is to
wait, but we've already waited a looong time (as in total).


Laurent, do you have some input here? We have simple "2 cameras
connected to one signal processor" situation here. We need some way of
passing endpoint configuration from the sensors through the switch. I
did this:


Could you give me a bit more information about the platform you're targeting:
how the switch is connected, what kind of switch it is, and what endpoint



http://plan9.stanleylieber.com/hardware/n900/n900.schematics.pdf, on 
page 2, see N5801 and N5802.



configuration data you need ?


@@ -415,6 +416,8 @@ struct v4l2_subdev_video_ops {
  const struct v4l2_mbus_config *cfg);
 int (*s_rx_buffer)(struct v4l2_subdev *sd, void *buf,
unsigned int *size);
+   int (*g_endpoint_config)(struct v4l2_subdev *sd,
+   struct v4l2_of_endpoint *cfg);


Google of g_routing tells me:

9) Highly reconfigurable hardware - Julien Beraud

- 44 sub-devices connected with an interconnect.
- As long as formats match, any sub-device could be connected to any
- other sub-device through a link.
- The result is 44 * 44 links at worst.
- A switch sub-device proposed as the solution to model the
- interconnect. The sub-devices are connected to the switch
- sub-devices through the hardware links that connect to the
- interconnect.
- The switch would be controlled through new IOCTLs S_ROUTING and
- G_ROUTING.
- Patches available:
  http://git.linuxtv.org/cgit.cgi/pinchartl/media.git/log/?h=xilinx-wip

but the patches are from 2005. So I guess I'll need some guidance here...


You made me feel very old for a moment. The patches are from 2015 :-)


I'll reply to the other patch containing the code.




Regards,
Ivo

Re: [PATCH v1 03/10] v4l: platform: Add Renesas CEU driver

[jacopo mondi]

Hi Laurent,

On Mon, Dec 18, 2017 at 05:28:43PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> On Monday, 18 December 2017 14:25:12 EET jacopo mondi wrote:
> > On Mon, Dec 11, 2017 at 06:15:23PM +0200, Laurent Pinchart wrote:
[snip]
> > >> +/**
> > >> + * ceu_soft_reset() - Software reset the CEU interface
> > >> + */
> > >> +static int ceu_soft_reset(struct ceu_device *ceudev)
> > >> +{
> > >> +unsigned int reset_done;
> > >> +unsigned int i;
> > >> +
> > >> +ceu_write(ceudev, CEU_CAPSR, CEU_CAPSR_CPKIL);
> > >> +
> > >> +reset_done = 0;
> > >> +for (i = 0; i < 1000 && !reset_done; i++) {
> > >> +udelay(1);
> > >> +if (!(ceu_read(ceudev, CEU_CSTSR) & CEU_CSTRST_CPTON))
> > >> +reset_done++;
> > >> +}
> > >
> > > How many iterations does this typically require ? Wouldn't a sleep be
> > > better than a delay ? As far as I can tell the ceu_soft_reset() function
> > > is only called with interrupts disabled (in interrupt context) from
> > > ceu_capture() in an error path, and that code should be reworked to make
> > > it possible to sleep if a reset takes too long.
> >
> > The HW manual does not provide any indication about absolute timings.
> > I can empirically try and see, but that would just be a hint.
>
> That's why I asked how many iterations it typically takes :-) A hint is enough
> to start with, preferably on both SH and ARM SoCs.

I've seen only 0s when printing out how many cycles it takes to clear
both registers. This means 1usec is enough, therefore I would keep using
udelay here. Also, I would reduce the attempts to 100 here (or even
10), as if a single one is typically enough, 1000 is definitely an
overkill.

>
> > Also, the reset function is called in many places (runtime_pm
> > suspend/resume) s_stream(0) and in error path of ceu_capture().
> >
> > In ceu_capture() we reset the interface if the previous frame was bad,
> > and we do that before re-enabling the capture interrupt (so interrupts
> > are not -disabled-, just the one we care about is not enabled yet..)
>
> The ceu_capture() function is called from the driver's interrupt handler, so
> interrupts are disabled in that code path.
>

I have removed that reset call from capture and re-worked the irq
handler to manage state before calling capture().

> > But that's not big deal, as if we fail there, we are about to abort
> > capture anyhow and so if we miss some spurious capture interrupt it's
> > ok...
> >
> > >> +if (!reset_done) {
> > >> +v4l2_err(>v4l2_dev, "soft reset time out\n");
> > >
> > > How about dev_err() instead ?
> >
> > Is dev_err/dev_dbg preferred over v4l2_err/v4l2_dbg? Is this because
> > of dynamic debug?
>
> Yes, and the fact that the V4L2 macros don't provide us anymore with much
> compared to the dev_* macros.
>
> > >> +
> > >> +/**
> > >> + * ceu_capture() - Trigger start of a capture sequence
> > >> + *
> > >> + * Return value doesn't reflect the success/failure to queue the new
> > >> buffer,
> > >> + * but rather the status of the previous capture.
> > >> + */
> > >> +static int ceu_capture(struct ceu_device *ceudev)
> > >> +{
> > >> +struct v4l2_pix_format_mplane *pix = >v4l2_pix;
> > >> +dma_addr_t phys_addr_top;
> > >> +u32 status;
> > >> +
> > >> +/* Clean interrupt status and re-enable interrupts */
> > >> +status = ceu_read(ceudev, CEU_CETCR);
> > >> +ceu_write(ceudev, CEU_CEIER,
> > >> +  ceu_read(ceudev, CEU_CEIER) & ~CEU_CEIER_MASK);
> > >> +ceu_write(ceudev, CEU_CETCR, ~status & CEU_CETCR_MAGIC);
> > >> +ceu_write(ceudev, CEU_CEIER, CEU_CEIER_MASK);
> > >
> > > I wonder why there's a need to disable and reenable interrupts here.
> >
> > The original driver clearly said "The hardware is -very- picky about
> > this sequence" and I got scared and nerver touched this.
>
> How about experimenting to see how the hardware reacts ?

Turns out this was not needed at all, both on RZ and SH4. I captured
several images without any issues in both platforms just clearing the
interrupt state without disabling interrutps.

>
> > Also, I very much dislike the CEU_CETRC_MAGIC mask, but again the old driver
> > said "Acknoledge magical interrupt sources" and I was afraid to change it
> > (I can rename it though, to something lioke CEU_CETCR_ALL_INT because that's
> > what it is, a mask with all available interrupt source enabled).
>
> I think renaming it is a good idea. Additionally, regardless of whether there
> is any hidden interrupt source, the datasheet mentions for all reserved bits
> that "The write  value  should always  be 0". They should read as 0, but
> masking them would be an additional safeguard.

The HW manual is a bit confused (and confusing) on this point.
Yes, there is the statement you have cited here, but there's also
"to clear only the CPE bit to 0, write H' FFFE to CETCR" a few
lines 

[PATCH 09/11] media: dvb-core: get rid of mmap reserved field

[Mauro Carvalho Chehab]

The "reserved" field was a way, used at V4L2 API, to add new
data to existing structs without breaking userspace. However,
there are now clever ways of doing that, without needing to add
an uneeded overhead. So, get rid of them.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/dvb/dmx-expbuf.rst   | 2 --
 Documentation/media/uapi/dvb/dmx-qbuf.rst | 2 --
 Documentation/media/uapi/dvb/dmx-querybuf.rst | 2 --
 Documentation/media/uapi/dvb/dmx-reqbufs.rst  | 2 --
 drivers/media/dvb-core/dvb_vb2.c  | 1 -
 include/uapi/linux/dvb/dmx.h  | 3 ---
 6 files changed, 12 deletions(-)

diff --git a/Documentation/media/uapi/dvb/dmx-expbuf.rst 
b/Documentation/media/uapi/dvb/dmx-expbuf.rst
index 51df34c6fb59..2d96cfe891df 100644
--- a/Documentation/media/uapi/dvb/dmx-expbuf.rst
+++ b/Documentation/media/uapi/dvb/dmx-expbuf.rst
@@ -36,8 +36,6 @@ This ioctl is an extension to the memory mapping I/O method.
 It can be used to export a buffer as a DMABUF file at any time after
 buffers have been allocated with the :ref:`DMX_REQBUFS` ioctl.
 
-The ``reserved`` array must be zeroed before calling it.
-
 To export a buffer, applications fill struct :c:type:`dmx_exportbuffer`.
 Applications must set the ``index`` field. Valid index numbers
 range from zero to the number of buffers allocated with :ref:`DMX_REQBUFS`
diff --git a/Documentation/media/uapi/dvb/dmx-qbuf.rst 
b/Documentation/media/uapi/dvb/dmx-qbuf.rst
index b20b8153d48d..b48c4931658e 100644
--- a/Documentation/media/uapi/dvb/dmx-qbuf.rst
+++ b/Documentation/media/uapi/dvb/dmx-qbuf.rst
@@ -45,8 +45,6 @@ numbers range from zero to the number of buffers allocated 
with
 one. The contents of the struct :c:type:`dmx_buffer` returned
 by a :ref:`DMX_QUERYBUF` ioctl will do as well.
 
-The and ``reserved`` field must be set to 0.
-
 When ``DMX_QBUF`` is called with a pointer to this structure, it locks the
 memory pages of the buffer in physical memory, so they cannot be swapped
 out to disk. Buffers remain locked until dequeued, until the
diff --git a/Documentation/media/uapi/dvb/dmx-querybuf.rst 
b/Documentation/media/uapi/dvb/dmx-querybuf.rst
index 46a50f191b10..89481e24bb86 100644
--- a/Documentation/media/uapi/dvb/dmx-querybuf.rst
+++ b/Documentation/media/uapi/dvb/dmx-querybuf.rst
@@ -36,8 +36,6 @@ This ioctl is part of the mmap streaming I/O method. It can
 be used to query the status of a buffer at any time after buffers have
 been allocated with the :ref:`DMX_REQBUFS` ioctl.
 
-The ``reserved`` array must be zeroed before calling it.
-
 Applications set the ``index`` field. Valid index numbers range from zero
 to the number of buffers allocated with :ref:`DMX_REQBUFS`
 (struct :c:type:`dvb_requestbuffers` ``count``) minus one.
diff --git a/Documentation/media/uapi/dvb/dmx-reqbufs.rst 
b/Documentation/media/uapi/dvb/dmx-reqbufs.rst
index 0749623d9d83..14b80d60bf35 100644
--- a/Documentation/media/uapi/dvb/dmx-reqbufs.rst
+++ b/Documentation/media/uapi/dvb/dmx-reqbufs.rst
@@ -42,8 +42,6 @@ allocated by applications through a device driver, and this 
ioctl only
 configures the driver into DMABUF I/O mode without performing any direct
 allocation.
 
-The ``reserved`` array must be zeroed before calling it.
-
 To allocate device buffers applications initialize all fields of the
 struct :c:type:`dmx_requestbuffers` structure. They set the  ``count`` field
 to the desired number of buffers,  and ``size`` to the size of each
diff --git a/drivers/media/dvb-core/dvb_vb2.c b/drivers/media/dvb-core/dvb_vb2.c
index 277d33b83089..7b1663f64e84 100644
--- a/drivers/media/dvb-core/dvb_vb2.c
+++ b/drivers/media/dvb-core/dvb_vb2.c
@@ -140,7 +140,6 @@ static void _fill_dmx_buffer(struct vb2_buffer *vb, void 
*pb)
b->length = vb->planes[0].length;
b->bytesused = vb->planes[0].bytesused;
b->offset = vb->planes[0].m.offset;
-   memset(b->reserved, 0, sizeof(b->reserved));
dprintk(3, "[%s]\n", ctx->name);
 }
 
diff --git a/include/uapi/linux/dvb/dmx.h b/include/uapi/linux/dvb/dmx.h
index e212aa18ad78..5f3c5a918f00 100644
--- a/include/uapi/linux/dvb/dmx.h
+++ b/include/uapi/linux/dvb/dmx.h
@@ -229,7 +229,6 @@ struct dmx_buffer {
__u32   bytesused;
__u32   offset;
__u32   length;
-   __u32   reserved[4];
 };
 
 /**
@@ -244,7 +243,6 @@ struct dmx_buffer {
 struct dmx_requestbuffers {
__u32   count;
__u32   size;
-   __u32   reserved[2];
 };
 
 /**
@@ -266,7 +264,6 @@ struct dmx_exportbuffer {
__u32   index;
__u32   flags;
__s32   fd;
-   __u32   reserved[5];
 };
 
 #define DMX_START_IO('o', 41)
-- 
2.14.3

[PATCH 05/11] media: dvb_vb2: fix a warning about streamoff logic

[Mauro Carvalho Chehab]

The streamoff logic is causing those warnings:

 WARNING: CPU: 3 PID: 3382 at drivers/media/v4l2-core/videobuf2-core.c:1652 
__vb2_queue_cancel+0x177/0x250 [videobuf2_core]
 Modules linked in: bnep fuse xt_CHECKSUM iptable_mangle tun ebtable_filter 
ebtables ip6table_filter ip6_tables xt_physdev br_netfilter bluetooth bridge 
rfkill ecdh_generic stp llc nf_log_ipv4 nf_log_common xt_LOG xt_conntrack 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c sunrpc vfat fat 
snd_hda_codec_hdmi rc_dib0700_nec i915 rc_pinnacle_pctv_hd em28xx_rc a8293 
ts2020 m88ds3103 i2c_mux em28xx_dvb dib8000 dvb_usb_dib0700 dib0070 dib7000m 
dib0090 dvb_usb dvb_core uvcvideo snd_usb_audio videobuf2_v4l2 dib3000mc 
videobuf2_vmalloc videobuf2_memops dibx000_common videobuf2_core rc_core 
snd_usbmidi_lib snd_rawmidi em28xx tveeprom v4l2_common videodev media 
intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_intel
 kvm_intel snd_hda_codec kvm snd_hwdep snd_hda_core snd_seq irqbypass 
crct10dif_pclmul crc32_pclmul i2c_algo_bit ghash_clmulni_intel snd_seq_device 
drm_kms_helper snd_pcm intel_cstate intel_uncore snd_timer tpm_tis drm mei_wdt 
iTCO_wdt iTCO_vendor_support tpm_tis_core snd intel_rapl_perf mei_me mei tpm 
i2c_i801 soundcore lpc_ich video binfmt_misc hid_logitech_hidpp hid_logitech_dj 
e1000e crc32c_intel ptp pps_core analog gameport joydev
 CPU: 3 PID: 3382 Comm: lt-dvbv5-zap Not tainted 4.14.0+ #3
 Hardware name:  /D53427RKE, BIOS 
RKPPT10H.86A.0048.2017.0506.1545 05/06/2017
 task: 94b93bbe1e40 task.stack: b7a98320c000
 RIP: 0010:__vb2_queue_cancel+0x177/0x250 [videobuf2_core]
 RSP: 0018:b7a98320fd40 EFLAGS: 00010202
 RAX: 0001 RBX: 94b92ff72428 RCX: 
 RDX: 0001 RSI: 0001 RDI: 94b92ff72428
 RBP: b7a98320fd68 R08: 94b92ff725d8 R09: b7a98320fcc8
 R10: 94b978003d98 R11: 94b92ff72428 R12: 94b92ff72428
 R13: 0282 R14: 94b92059ae20 R15: dead0100
 FS:  () GS:94b99e38() knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2: 555953007d70 CR3: 00012be09004 CR4: 001606e0
 Call Trace:
  vb2_core_streamoff+0x28/0x90 [videobuf2_core]
  dvb_vb2_stream_off+0xd1/0x150 [dvb_core]
  dvb_dvr_release+0x114/0x120 [dvb_core]
  __fput+0xdf/0x1e0
  fput+0xe/0x10
  task_work_run+0x94/0xc0
  do_exit+0x2dc/0xba0
  do_group_exit+0x47/0xb0
  SyS_exit_group+0x14/0x20
  entry_SYSCALL_64_fastpath+0x1a/0xa5
 RIP: 0033:0x7f775e931ed8
 RSP: 002b:7fff07019d68 EFLAGS: 0246 ORIG_RAX: 00e7
 RAX: ffda RBX: 01d02690 RCX: 7f775e931ed8
 RDX: 0001 RSI: 003c RDI: 0001
 RBP: 7fff0701a500 R08: 00e7 R09: ff70
 R10: 7f775e854dd8 R11: 0246 R12: 
 R13: 035fa000 R14: 000a R15: 000a
 Code: 00 00 04 74 1c 44 89 e8 49 83 c5 01 41 39 84 24 88 01 00 00 77 8a 5b 41 
5c 41 5d 41 5e 41 5f 5d c3 48 89 df e8 bb fd ff ff eb da <0f> ff 41 8b b4 24 88 
01 00 00 85 f6 74 34 bb 01 00 00 00 eb 10

There are actually two issues here:

1) list_del() should be called when changing the buffer state;

2) The logic with marks the buffers as done is at the wrong place.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-core/dvb_vb2.c | 33 -
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/drivers/media/dvb-core/dvb_vb2.c b/drivers/media/dvb-core/dvb_vb2.c
index 34193a4acc47..277d33b83089 100644
--- a/drivers/media/dvb-core/dvb_vb2.c
+++ b/drivers/media/dvb-core/dvb_vb2.c
@@ -89,8 +89,19 @@ static int _start_streaming(struct vb2_queue *vq, unsigned 
int count)
 static void _stop_streaming(struct vb2_queue *vq)
 {
struct dvb_vb2_ctx *ctx = vb2_get_drv_priv(vq);
+   struct dvb_buffer *buf;
+   unsigned long flags = 0;
 
dprintk(3, "[%s]\n", ctx->name);
+
+   spin_lock_irqsave(>slock, flags);
+   while (!list_empty(>dvb_q)) {
+   buf = list_entry(ctx->dvb_q.next,
+struct dvb_buffer, list);
+   vb2_buffer_done(>vb, VB2_BUF_STATE_ERROR);
+   list_del(>list);
+   }
+   spin_unlock_irqrestore(>slock, flags);
 }
 
 static void _dmxdev_lock(struct vb2_queue *vq)
@@ -224,21 +235,8 @@ int dvb_vb2_stream_off(struct dvb_vb2_ctx *ctx)
 {
struct vb2_queue *q = (struct vb2_queue *)>vb_q;
int ret;
-   unsigned long flags = 0;
 
ctx->state &= ~DVB_VB2_STATE_STREAMON;
-   spin_lock_irqsave(>slock, flags);
-   while (!list_empty(>dvb_q)) {
-   struct dvb_buffer   *buf;
-
-   buf = list_entry(ctx->dvb_q.next,
-struct dvb_buffer, list);
-   

[PATCH 07/11] media: dvb uAPI docs: document demux mmap/munmap syscalls

[Mauro Carvalho Chehab]

With the new dmx mmap interface, those two syscalls are now
handled by the subsystem. Document them.

This patch is based on the V4L2 text for those ioctls.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/dvb/dmx-mmap.rst   | 116 
 Documentation/media/uapi/dvb/dmx-munmap.rst |  54 +
 Documentation/media/uapi/dvb/dmx_fcalls.rst |   2 +
 3 files changed, 172 insertions(+)
 create mode 100644 Documentation/media/uapi/dvb/dmx-mmap.rst
 create mode 100644 Documentation/media/uapi/dvb/dmx-munmap.rst

diff --git a/Documentation/media/uapi/dvb/dmx-mmap.rst 
b/Documentation/media/uapi/dvb/dmx-mmap.rst
new file mode 100644
index ..15d107348b9f
--- /dev/null
+++ b/Documentation/media/uapi/dvb/dmx-mmap.rst
@@ -0,0 +1,116 @@
+.. _dmx-mmap:
+
+*
+Digital TV mmap()
+*
+
+Name
+
+
+dmx-mmap - Map device memory into application address space
+
+.. warning:: this API is still experimental
+
+Synopsis
+
+
+.. code-block:: c
+
+#include 
+#include 
+
+
+.. c:function:: void *mmap( void *start, size_t length, int prot, int flags, 
int fd, off_t offset )
+:name: dmx-mmap
+
+Arguments
+=
+
+``start``
+Map the buffer to this address in the application's address space.
+When the ``MAP_FIXED`` flag is specified, ``start`` must be a
+multiple of the pagesize and mmap will fail when the specified
+address cannot be used. Use of this option is discouraged;
+applications should just specify a ``NULL`` pointer here.
+
+``length``
+Length of the memory area to map. This must be a multiple of the
+DVB packet length (188, on most drivers).
+
+``prot``
+The ``prot`` argument describes the desired memory protection.
+Regardless of the device type and the direction of data exchange it
+should be set to ``PROT_READ`` | ``PROT_WRITE``, permitting read
+and write access to image buffers. Drivers should support at least
+this combination of flags.
+
+``flags``
+The ``flags`` parameter specifies the type of the mapped object,
+mapping options and whether modifications made to the mapped copy of
+the page are private to the process or are to be shared with other
+references.
+
+``MAP_FIXED`` requests that the driver selects no other address than
+the one specified. If the specified address cannot be used,
+:ref:`mmap() ` will fail. If ``MAP_FIXED`` is specified,
+``start`` must be a multiple of the pagesize. Use of this option is
+discouraged.
+
+One of the ``MAP_SHARED`` or ``MAP_PRIVATE`` flags must be set.
+``MAP_SHARED`` allows applications to share the mapped memory with
+other (e. g. child-) processes.
+
+.. note::
+
+   The Linux Digital TV applications should not set the
+   ``MAP_PRIVATE``, ``MAP_DENYWRITE``, ``MAP_EXECUTABLE`` or ``MAP_ANON``
+   flags.
+
+``fd``
+File descriptor returned by :ref:`open() `.
+
+``offset``
+Offset of the buffer in device memory, as returned by
+:ref:`DMX_QUERYBUF` ioctl.
+
+
+Description
+===
+
+The :ref:`mmap() ` function asks to map ``length`` bytes starting at
+``offset`` in the memory of the device specified by ``fd`` into the
+application address space, preferably at address ``start``. This latter
+address is a hint only, and is usually specified as 0.
+
+Suitable length and offset parameters are queried with the
+:ref:`DMX_QUERYBUF` ioctl. Buffers must be allocated with the
+:ref:`DMX_REQBUFS` ioctl before they can be queried.
+
+To unmap buffers the :ref:`munmap() ` function is used.
+
+
+Return Value
+
+
+On success :ref:`mmap() ` returns a pointer to the mapped buffer. On
+error ``MAP_FAILED`` (-1) is returned, and the ``errno`` variable is set
+appropriately. Possible error codes are:
+
+EBADF
+``fd`` is not a valid file descriptor.
+
+EACCES
+``fd`` is not open for reading and writing.
+
+EINVAL
+The ``start`` or ``length`` or ``offset`` are not suitable. (E. g.
+they are too large, or not aligned on a ``PAGESIZE`` boundary.)
+
+The ``flags`` or ``prot`` value is not supported.
+
+No buffers have been allocated with the
+:ref:`DMX_REQBUFS` ioctl.
+
+ENOMEM
+Not enough physical or virtual memory was available to complete the
+request.
diff --git a/Documentation/media/uapi/dvb/dmx-munmap.rst 
b/Documentation/media/uapi/dvb/dmx-munmap.rst
new file mode 100644
index ..d77218732bb6
--- /dev/null
+++ b/Documentation/media/uapi/dvb/dmx-munmap.rst
@@ -0,0 +1,54 @@
+.. _dmx-munmap:
+
+
+DVB munmap()
+
+
+Name
+
+
+dmx-munmap - Unmap device memory
+
+.. warning:: This API is still experimental.
+
+
+Synopsis
+
+
+.. code-block:: c
+
+#include 
+#include 
+
+
+.. c:function:: int munmap( void *start, size_t length )
+:name: dmx-munmap
+
+Arguments
+=
+
+``start``
+Address of the mapped buffer as 

[PATCH 10/11] fs: compat_ioctl: add new DVB demux ioctls

[Mauro Carvalho Chehab]

Use trivial handling for the new DVB demux ioctls, as none
of them passes a pointer inside their structures.

Signed-off-by: Mauro Carvalho Chehab 
---
 fs/compat_ioctl.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index bd5d91e119ca..cc71c3676ce2 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -1333,6 +1333,11 @@ COMPATIBLE_IOCTL(DMX_SET_PES_FILTER)
 COMPATIBLE_IOCTL(DMX_SET_BUFFER_SIZE)
 COMPATIBLE_IOCTL(DMX_GET_PES_PIDS)
 COMPATIBLE_IOCTL(DMX_GET_STC)
+COMPATIBLE_IOCTL(DMX_REQBUFS)
+COMPATIBLE_IOCTL(DMX_QUERYBUF)
+COMPATIBLE_IOCTL(DMX_EXPBUF)
+COMPATIBLE_IOCTL(DMX_QBUF)
+COMPATIBLE_IOCTL(DMX_DQBUF)
 COMPATIBLE_IOCTL(FE_GET_INFO)
 COMPATIBLE_IOCTL(FE_DISEQC_RESET_OVERLOAD)
 COMPATIBLE_IOCTL(FE_DISEQC_SEND_MASTER_CMD)
-- 
2.14.3

[PATCH 02/11] media: videobuf2: Add new uAPI for DVB streaming I/O

[Mauro Carvalho Chehab]

From: Satendra Singh Thakur 

Adds a new uAPI for DVB to use streaming I/O which is implemented
based on videobuf2, using those new ioctls:

- DMX_REQBUFS:  Request kernel to allocate buffers which count and size
are dedicated by user.
- DMX_QUERYBUF: Get the buffer information like a memory offset which
will mmap() and be shared with user-space.
- DMX_EXPBUF:   Just for testing whether buffer-exporting success or not.
- DMX_QBUF: Pass the buffer to kernel-space.
- DMX_DQBUF:Get back the buffer which may contain TS data.

Originally developed by: Junghak Sung , as
seen at:
https://patchwork.linuxtv.org/patch/31613/
https://patchwork.kernel.org/patch/7334301/

The original patch was written before merging VB2-core functionalities
upstream. When such series was added, several adjustments were made,
fixing some issues with V4L2, causing the original patch to be
non-trivially rebased.

After rebased, a few bugs in the patch were fixed. The patch was
also enhanced it and polling functionality got added.

The main changes over the original patch are:

dvb_vb2_fill_buffer():
- Set the size of the outgoing buffer after while loop using
  vb2_set_plane_payload;

- Added NULL check for source buffer as per normal convention
  of demux driver, this is called twice, first time with valid
  buffer second time with NULL pointer, if its not handled,
  it will result in  crash

- Restricted spinlock for only list_* operations

dvb_vb2_init():
- Restricted q->io_modes to only VB2_MMAP as its the only
  supported mode

dvb_vb2_release():
- Replaced the && in if condiion with &, because otherwise
  it was always getting satisfied.

dvb_vb2_stream_off():
- Added list_del code for enqueud buffers upon stream off

dvb_vb2_poll():
- Added this new function in order to support polling

dvb_demux_poll() and dvb_dvr_poll()
- dvb_vb2_poll() is now called from these functions

- Ported this patch and latest videobuf2 to lower kernel versions and
  tested auto scan.

[mche...@s-opensource.com: checkpatch fixes]
Co-developed-by: Junghak Sung 
Signed-off-by: Junghak Sung 
Signed-off-by: Geunyoung Kim 
Acked-by: Seung-Woo Kim 
Acked-by: Inki Dae 
Signed-off-by: Satendra Singh Thakur 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-core/Makefile  |   2 +-
 drivers/media/dvb-core/dmxdev.c  | 196 +++---
 drivers/media/dvb-core/dmxdev.h  |   4 +
 drivers/media/dvb-core/dvb_vb2.c | 423 +++
 drivers/media/dvb-core/dvb_vb2.h |  72 +++
 include/uapi/linux/dvb/dmx.h |  66 +-
 6 files changed, 733 insertions(+), 30 deletions(-)
 create mode 100644 drivers/media/dvb-core/dvb_vb2.c
 create mode 100644 drivers/media/dvb-core/dvb_vb2.h

diff --git a/drivers/media/dvb-core/Makefile b/drivers/media/dvb-core/Makefile
index 47e2e391bfb8..bbc65dfa0a8e 100644
--- a/drivers/media/dvb-core/Makefile
+++ b/drivers/media/dvb-core/Makefile
@@ -7,6 +7,6 @@ dvb-net-$(CONFIG_DVB_NET) := dvb_net.o
 
 dvb-core-objs := dvbdev.o dmxdev.o dvb_demux.o \
 dvb_ca_en50221.o dvb_frontend.o\
-$(dvb-net-y) dvb_ringbuffer.o dvb_math.o
+$(dvb-net-y) dvb_ringbuffer.o dvb_vb2.o dvb_math.o
 
 obj-$(CONFIG_DVB_CORE) += dvb-core.o
diff --git a/drivers/media/dvb-core/dmxdev.c b/drivers/media/dvb-core/dmxdev.c
index 18e4230865be..4cbb9003a1ed 100644
--- a/drivers/media/dvb-core/dmxdev.c
+++ b/drivers/media/dvb-core/dmxdev.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include "dmxdev.h"
+#include "dvb_vb2.h"
 
 static int debug;
 
@@ -138,14 +139,8 @@ static int dvb_dvr_open(struct inode *inode, struct file 
*file)
return -ENODEV;
}
 
-   if ((file->f_flags & O_ACCMODE) == O_RDWR) {
-   if (!(dmxdev->capabilities & DMXDEV_CAP_DUPLEX)) {
-   mutex_unlock(>mutex);
-   return -EOPNOTSUPP;
-   }
-   }
-
-   if ((file->f_flags & O_ACCMODE) == O_RDONLY) {
+   if (((file->f_flags & O_ACCMODE) == O_RDONLY) ||
+   ((file->f_flags & O_ACCMODE) == O_RDWR)) {
void *mem;
 
if (!dvbdev->readers) {
@@ -158,6 +153,8 @@ static int dvb_dvr_open(struct inode *inode, struct file 
*file)
return -ENOMEM;
}
dvb_ringbuffer_init(>dvr_buffer, mem, DVR_BUFFER_SIZE);
+   dvb_vb2_init(>dvr_vb2_ctx, "dvr",
+file->f_flags & O_NONBLOCK);
dvbdev->readers--;
}
 
@@ -195,7 +192,11 @@ static int dvb_dvr_release(struct inode *inode, 

[PATCH 01/11] media: vb2-core: Fix a bug about unnecessary calls to queue cancel and free

[Mauro Carvalho Chehab]

From: Satendra Singh Thakur 

When the func vb2_core_reqbufs is called first time after
vb2_core_queue_init(), the condition q->memory != memory always gets
satisfied, since q->memory was set to 0 at vb2_core_queue_init().

After the condition is true, unnecessary calls to __vb2_queue_cancel()
and  __vb2_queue_free() are done. in such case, *count is non-zero,
q->num_buffers is zero and q->memory is 0, which is not equal to
memory field *count=N, q->num_buffers=0, q->memory != memory.

[mche...@s-opensource.com: fix checkpatch issues]
Signed-off-by: Satendra Singh Thakur 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/videobuf2-core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index cb115ba6a1d2..21017b478a34 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -662,7 +662,8 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory 
memory,
return -EBUSY;
}
 
-   if (*count == 0 || q->num_buffers != 0 || q->memory != memory) {
+   if (*count == 0 || q->num_buffers != 0 ||
+   (q->memory && q->memory != memory)) {
/*
 * We already have buffers allocated, so first check if they
 * are not in use and can be freed.
-- 
2.14.3

[PATCH 04/11] media: vb2-core: add a new warning about pending buffers

[Mauro Carvalho Chehab]

There's a logic at the VB2 core that produces a WARN_ON if
there are still buffers waiting to be filled. However, it doesn't
indicate what buffers are still opened, with makes harder to
identify issues inside caller drivers.

So, add a new pr_warn() pointing to such buffers. That, together
with debug instrumentation inside the drivers can make easier to
identify where the problem is.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/videobuf2-core.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 319ab8bf220f..064d3c6f1e74 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1653,8 +1653,11 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
 */
if (WARN_ON(atomic_read(>owned_by_drv_count))) {
for (i = 0; i < q->num_buffers; ++i)
-   if (q->bufs[i]->state == VB2_BUF_STATE_ACTIVE)
+   if (q->bufs[i]->state == VB2_BUF_STATE_ACTIVE) {
+   pr_warn("driver bug: stop_streaming operation 
is leaving buf %p in active state\n",
+   q->bufs[i]);
vb2_buffer_done(q->bufs[i], 
VB2_BUF_STATE_ERROR);
+   }
/* Must be zero now */
WARN_ON(atomic_read(>owned_by_drv_count));
}
-- 
2.14.3

[PATCH 11/11] media: dvb_vb2: add SPDX headers

[Mauro Carvalho Chehab]

This code is released under GPL. Add the corresponding SPDX
headers.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-core/dvb_vb2.c | 1 +
 drivers/media/dvb-core/dvb_vb2.h | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/media/dvb-core/dvb_vb2.c b/drivers/media/dvb-core/dvb_vb2.c
index 7b1663f64e84..10d8f627af3a 100644
--- a/drivers/media/dvb-core/dvb_vb2.c
+++ b/drivers/media/dvb-core/dvb_vb2.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL
 /*
  * dvb-vb2.c - dvb-vb2
  *
diff --git a/drivers/media/dvb-core/dvb_vb2.h b/drivers/media/dvb-core/dvb_vb2.h
index d68653926d91..a5164effee16 100644
--- a/drivers/media/dvb-core/dvb_vb2.h
+++ b/drivers/media/dvb-core/dvb_vb2.h
@@ -1,4 +1,6 @@
 /*
+ * SPDX-License-Identifier: GPL
+ *
  * dvb-vb2.h - DVB driver helper framework for streaming I/O
  *
  * Copyright (C) 2015 Samsung Electronics
-- 
2.14.3

[PATCH 06/11] media: move videobuf2 to drivers/media/common

[Mauro Carvalho Chehab]

Now that VB2 is used by both V4L2 and DVB core, move it to
the common part of the subsystem.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/common/Kconfig   |  1 +
 drivers/media/common/Makefile  |  2 +-
 drivers/media/common/videobuf/Kconfig  | 31 +
 drivers/media/common/videobuf/Makefile |  7 +
 .../videobuf}/videobuf2-core.c |  0
 .../videobuf}/videobuf2-dma-contig.c   |  0
 .../videobuf}/videobuf2-dma-sg.c   |  0
 .../{v4l2-core => common/videobuf}/videobuf2-dvb.c |  0
 .../videobuf}/videobuf2-memops.c   |  0
 .../videobuf}/videobuf2-v4l2.c |  0
 .../videobuf}/videobuf2-vmalloc.c  |  0
 drivers/media/v4l2-core/Kconfig| 32 --
 drivers/media/v4l2-core/Makefile   |  7 -
 13 files changed, 40 insertions(+), 40 deletions(-)
 create mode 100644 drivers/media/common/videobuf/Kconfig
 create mode 100644 drivers/media/common/videobuf/Makefile
 rename drivers/media/{v4l2-core => common/videobuf}/videobuf2-core.c (100%)
 rename drivers/media/{v4l2-core => common/videobuf}/videobuf2-dma-contig.c 
(100%)
 rename drivers/media/{v4l2-core => common/videobuf}/videobuf2-dma-sg.c (100%)
 rename drivers/media/{v4l2-core => common/videobuf}/videobuf2-dvb.c (100%)
 rename drivers/media/{v4l2-core => common/videobuf}/videobuf2-memops.c (100%)
 rename drivers/media/{v4l2-core => common/videobuf}/videobuf2-v4l2.c (100%)
 rename drivers/media/{v4l2-core => common/videobuf}/videobuf2-vmalloc.c (100%)

diff --git a/drivers/media/common/Kconfig b/drivers/media/common/Kconfig
index 326df0ad75c0..cdfc905967dc 100644
--- a/drivers/media/common/Kconfig
+++ b/drivers/media/common/Kconfig
@@ -16,6 +16,7 @@ config CYPRESS_FIRMWARE
tristate "Cypress firmware helper routines"
depends on USB
 
+source "drivers/media/common/videobuf/Kconfig"
 source "drivers/media/common/b2c2/Kconfig"
 source "drivers/media/common/saa7146/Kconfig"
 source "drivers/media/common/siano/Kconfig"
diff --git a/drivers/media/common/Makefile b/drivers/media/common/Makefile
index 2d1b0a025084..f24b5ed39982 100644
--- a/drivers/media/common/Makefile
+++ b/drivers/media/common/Makefile
@@ -1,4 +1,4 @@
-obj-y += b2c2/ saa7146/ siano/ v4l2-tpg/
+obj-y += b2c2/ saa7146/ siano/ v4l2-tpg/ videobuf/
 obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o
 obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
 obj-$(CONFIG_CYPRESS_FIRMWARE) += cypress_firmware.o
diff --git a/drivers/media/common/videobuf/Kconfig 
b/drivers/media/common/videobuf/Kconfig
new file mode 100644
index ..5df05250de94
--- /dev/null
+++ b/drivers/media/common/videobuf/Kconfig
@@ -0,0 +1,31 @@
+# Used by drivers that need Videobuf2 modules
+config VIDEOBUF2_CORE
+   select DMA_SHARED_BUFFER
+   tristate
+
+config VIDEOBUF2_MEMOPS
+   tristate
+   select FRAME_VECTOR
+
+config VIDEOBUF2_DMA_CONTIG
+   tristate
+   depends on HAS_DMA
+   select VIDEOBUF2_CORE
+   select VIDEOBUF2_MEMOPS
+   select DMA_SHARED_BUFFER
+
+config VIDEOBUF2_VMALLOC
+   tristate
+   select VIDEOBUF2_CORE
+   select VIDEOBUF2_MEMOPS
+   select DMA_SHARED_BUFFER
+
+config VIDEOBUF2_DMA_SG
+   tristate
+   depends on HAS_DMA
+   select VIDEOBUF2_CORE
+   select VIDEOBUF2_MEMOPS
+
+config VIDEOBUF2_DVB
+   tristate
+   select VIDEOBUF2_CORE
diff --git a/drivers/media/common/videobuf/Makefile 
b/drivers/media/common/videobuf/Makefile
new file mode 100644
index ..19de5ccda20b
--- /dev/null
+++ b/drivers/media/common/videobuf/Makefile
@@ -0,0 +1,7 @@
+
+obj-$(CONFIG_VIDEOBUF2_CORE) += videobuf2-core.o videobuf2-v4l2.o
+obj-$(CONFIG_VIDEOBUF2_MEMOPS) += videobuf2-memops.o
+obj-$(CONFIG_VIDEOBUF2_VMALLOC) += videobuf2-vmalloc.o
+obj-$(CONFIG_VIDEOBUF2_DMA_CONTIG) += videobuf2-dma-contig.o
+obj-$(CONFIG_VIDEOBUF2_DMA_SG) += videobuf2-dma-sg.o
+obj-$(CONFIG_VIDEOBUF2_DVB) += videobuf2-dvb.o
diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/common/videobuf/videobuf2-core.c
similarity index 100%
rename from drivers/media/v4l2-core/videobuf2-core.c
rename to drivers/media/common/videobuf/videobuf2-core.c
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/common/videobuf/videobuf2-dma-contig.c
similarity index 100%
rename from drivers/media/v4l2-core/videobuf2-dma-contig.c
rename to drivers/media/common/videobuf/videobuf2-dma-contig.c
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c 
b/drivers/media/common/videobuf/videobuf2-dma-sg.c
similarity index 100%
rename from drivers/media/v4l2-core/videobuf2-dma-sg.c
rename to drivers/media/common/videobuf/videobuf2-dma-sg.c
diff --git a/drivers/media/v4l2-core/videobuf2-dvb.c 
b/drivers/media/common/videobuf/videobuf2-dvb.c
similarity index 100%
rename from 

[PATCH 08/11] media: dvb uAPI docs: document mmap-related ioctls

[Mauro Carvalho Chehab]

5 new ioctls were added to the DVB demux API, in order to
handle memory maped I/O. Add documentation for them.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/dvb/dmx-expbuf.rst   | 90 +++
 Documentation/media/uapi/dvb/dmx-qbuf.rst | 85 +
 Documentation/media/uapi/dvb/dmx-querybuf.rst | 65 +++
 Documentation/media/uapi/dvb/dmx-reqbufs.rst  | 76 ++
 Documentation/media/uapi/dvb/dmx_fcalls.rst   |  4 ++
 5 files changed, 320 insertions(+)
 create mode 100644 Documentation/media/uapi/dvb/dmx-expbuf.rst
 create mode 100644 Documentation/media/uapi/dvb/dmx-qbuf.rst
 create mode 100644 Documentation/media/uapi/dvb/dmx-querybuf.rst
 create mode 100644 Documentation/media/uapi/dvb/dmx-reqbufs.rst

diff --git a/Documentation/media/uapi/dvb/dmx-expbuf.rst 
b/Documentation/media/uapi/dvb/dmx-expbuf.rst
new file mode 100644
index ..51df34c6fb59
--- /dev/null
+++ b/Documentation/media/uapi/dvb/dmx-expbuf.rst
@@ -0,0 +1,90 @@
+.. _DMX_EXPBUF:
+
+
+ioctl DMX_EXPBUF
+
+
+Name
+
+
+DMX_EXPBUF - Export a buffer as a DMABUF file descriptor.
+
+.. warning:: this API is still experimental
+
+
+Synopsis
+
+
+.. c:function:: int ioctl( int fd, DMX_EXPBUF, struct dmx_exportbuffer *argp )
+:name: DMX_EXPBUF
+
+
+Arguments
+=
+
+``fd``
+File descriptor returned by :ref:`open() `.
+
+``argp``
+Pointer to struct :c:type:`dmx_exportbuffer`.
+
+
+Description
+===
+
+This ioctl is an extension to the memory mapping I/O method.
+It can be used to export a buffer as a DMABUF file at any time after
+buffers have been allocated with the :ref:`DMX_REQBUFS` ioctl.
+
+The ``reserved`` array must be zeroed before calling it.
+
+To export a buffer, applications fill struct :c:type:`dmx_exportbuffer`.
+Applications must set the ``index`` field. Valid index numbers
+range from zero to the number of buffers allocated with :ref:`DMX_REQBUFS`
+(struct :c:type:`dmx_requestbuffers` ``count``) minus one.
+Additional flags may be posted in the ``flags`` field. Refer to a manual
+for open() for details. Currently only O_CLOEXEC, O_RDONLY, O_WRONLY,
+and O_RDWR are supported.
+All other fields must be set to zero. In the
+case of multi-planar API, every plane is exported separately using
+multiple :ref:`DMX_EXPBUF` calls.
+
+After calling :ref:`DMX_EXPBUF` the ``fd`` field will be set by a
+driver, on success. This is a DMABUF file descriptor. The application may
+pass it to other DMABUF-aware devices. It is recommended to close a DMABUF
+file when it is no longer used to allow the associated memory to be reclaimed.
+
+
+Examples
+
+
+
+.. code-block:: c
+
+int buffer_export(int v4lfd, enum dmx_buf_type bt, int index, int *dmafd)
+{
+   struct dmx_exportbuffer expbuf;
+
+   memset(, 0, sizeof(expbuf));
+   expbuf.type = bt;
+   expbuf.index = index;
+   if (ioctl(v4lfd, DMX_EXPBUF, ) == -1) {
+   perror("DMX_EXPBUF");
+   return -1;
+   }
+
+   *dmafd = expbuf.fd;
+
+   return 0;
+}
+
+Return Value
+
+
+On success 0 is returned, on error -1 and the ``errno`` variable is set
+appropriately. The generic error codes are described at the
+:ref:`Generic Error Codes ` chapter.
+
+EINVAL
+A queue is not in MMAP mode or DMABUF exporting is not supported or
+``flags`` or ``index`` fields are invalid.
diff --git a/Documentation/media/uapi/dvb/dmx-qbuf.rst 
b/Documentation/media/uapi/dvb/dmx-qbuf.rst
new file mode 100644
index ..b20b8153d48d
--- /dev/null
+++ b/Documentation/media/uapi/dvb/dmx-qbuf.rst
@@ -0,0 +1,85 @@
+.. _DMX_QBUF:
+
+*
+ioctl DMX_QBUF, DMX_DQBUF
+*
+
+Name
+
+
+DMX_QBUF - DMX_DQBUF - Exchange a buffer with the driver
+
+.. warning:: this API is still experimental
+
+
+Synopsis
+
+
+.. c:function:: int ioctl( int fd, DMX_QBUF, struct dmx_buffer *argp )
+:name: DMX_QBUF
+
+.. c:function:: int ioctl( int fd, DMX_DQBUF, struct dmx_buffer *argp )
+:name: DMX_DQBUF
+
+
+Arguments
+=
+
+``fd``
+File descriptor returned by :ref:`open() `.
+
+``argp``
+Pointer to struct :c:type:`dmx_buffer`.
+
+
+Description
+===
+
+Applications call the ``DMX_QBUF`` ioctl to enqueue an empty
+(capturing) or filled (output) buffer in the driver's incoming queue.
+The semantics depend on the selected I/O method.
+
+To enqueue a buffer applications set the ``index`` field. Valid index
+numbers range from zero to the number of buffers allocated with
+:ref:`DMX_REQBUFS` (struct :c:type:`dmx_requestbuffers` ``count``) minus
+one. The contents of the struct :c:type:`dmx_buffer` returned
+by a :ref:`DMX_QUERYBUF` ioctl will do as well.
+
+The and ``reserved`` field must be set to 0.
+
+When ``DMX_QBUF`` is called with a pointer to this structure, it locks the
+memory pages of 

[PATCH 03/11] media: vb2-core: add pr_fmt() macro

[Mauro Carvalho Chehab]

Simplify the pr_foo() macros by adding a pr_fmt() macro.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/videobuf2-core.c | 30 --
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 21017b478a34..319ab8bf220f 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -14,6 +14,8 @@
  * the Free Software Foundation.
  */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -32,10 +34,10 @@
 static int debug;
 module_param(debug, int, 0644);
 
-#define dprintk(level, fmt, arg...)  \
-   do {  \
-   if (debug >= level)   \
-   pr_info("vb2-core: %s: " fmt, __func__, ## arg); \
+#define dprintk(level, fmt, arg...)\
+   do {\
+   if (debug >= level) \
+   pr_info("%s: " fmt, __func__, ## arg);  \
} while (0)
 
 #ifdef CONFIG_VIDEO_ADV_DEBUG
@@ -460,12 +462,12 @@ static int __vb2_queue_free(struct vb2_queue *q, unsigned 
int buffers)
  q->cnt_wait_prepare != q->cnt_wait_finish;
 
if (unbalanced || debug) {
-   pr_info("vb2: counters for queue %p:%s\n", q,
+   pr_info("counters for queue %p:%s\n", q,
unbalanced ? " UNBALANCED!" : "");
-   pr_info("vb2: setup: %u start_streaming: %u 
stop_streaming: %u\n",
+   pr_info(" setup: %u start_streaming: %u 
stop_streaming: %u\n",
q->cnt_queue_setup, q->cnt_start_streaming,
q->cnt_stop_streaming);
-   pr_info("vb2: wait_prepare: %u wait_finish: %u\n",
+   pr_info(" wait_prepare: %u wait_finish: %u\n",
q->cnt_wait_prepare, q->cnt_wait_finish);
}
q->cnt_queue_setup = 0;
@@ -486,23 +488,23 @@ static int __vb2_queue_free(struct vb2_queue *q, unsigned 
int buffers)
  vb->cnt_buf_init != vb->cnt_buf_cleanup;
 
if (unbalanced || debug) {
-   pr_info("vb2:   counters for queue %p, buffer %d:%s\n",
+   pr_info("   counters for queue %p, buffer %d:%s\n",
q, buffer, unbalanced ? " UNBALANCED!" : "");
-   pr_info("vb2: buf_init: %u buf_cleanup: %u 
buf_prepare: %u buf_finish: %u\n",
+   pr_info(" buf_init: %u buf_cleanup: %u buf_prepare: 
%u buf_finish: %u\n",
vb->cnt_buf_init, vb->cnt_buf_cleanup,
vb->cnt_buf_prepare, vb->cnt_buf_finish);
-   pr_info("vb2: buf_queue: %u buf_done: %u\n",
+   pr_info(" buf_queue: %u buf_done: %u\n",
vb->cnt_buf_queue, vb->cnt_buf_done);
-   pr_info("vb2: alloc: %u put: %u prepare: %u finish: 
%u mmap: %u\n",
+   pr_info(" alloc: %u put: %u prepare: %u finish: %u 
mmap: %u\n",
vb->cnt_mem_alloc, vb->cnt_mem_put,
vb->cnt_mem_prepare, vb->cnt_mem_finish,
vb->cnt_mem_mmap);
-   pr_info("vb2: get_userptr: %u put_userptr: %u\n",
+   pr_info(" get_userptr: %u put_userptr: %u\n",
vb->cnt_mem_get_userptr, 
vb->cnt_mem_put_userptr);
-   pr_info("vb2: attach_dmabuf: %u detach_dmabuf: %u 
map_dmabuf: %u unmap_dmabuf: %u\n",
+   pr_info(" attach_dmabuf: %u detach_dmabuf: %u 
map_dmabuf: %u unmap_dmabuf: %u\n",
vb->cnt_mem_attach_dmabuf, 
vb->cnt_mem_detach_dmabuf,
vb->cnt_mem_map_dmabuf, 
vb->cnt_mem_unmap_dmabuf);
-   pr_info("vb2: get_dmabuf: %u num_users: %u vaddr: 
%u cookie: %u\n",
+   pr_info(" get_dmabuf: %u num_users: %u vaddr: %u 
cookie: %u\n",
vb->cnt_mem_get_dmabuf,
vb->cnt_mem_num_users,
vb->cnt_mem_vaddr,
-- 
2.14.3

Re: [BUG] atomisp_ov2680 not initializing correctly

[Andy Shevchenko]

On Thu, 2017-12-21 at 13:54 +0100, Kristian Beilke wrote:
> On Tue, Dec 19, 2017 at 10:37:01PM +0200, Andy Shevchenko wrote:
> > On Tue, 2017-12-19 at 14:00 +0200, Sakari Ailus wrote:
> > > Cc Alan and Andy.
> > > 
> > > On Sat, Dec 16, 2017 at 04:50:04PM +0100, Kristian Beilke wrote:
> > > > Dear all,
> > > > 
> > > > I am trying to get the cameras in a Lenovo IdeaPad Miix 320
> > > > (Atom
> > > > x5-Z8350 BayTrail) to work. The front camera is an ov2680. With
> > > > kernel
> > > > 4.14.4 and 4.15rc3 I see the following dmesg output:
> > 
> > It seems I forgot to send the rest of the patches I did while ago
> > against AtomISP code.
> > 
> > It includes switch to normal DMI matching instead of the crap we
> > have
> > there right now.
> > 
> > WRT to the messages below it seems we have no platform data for that
> > device. It needs to be added.
> > 
> > In any case, I have no firmware to test BayTrail hardware I have
> > (MRD7).
> > 
> > The driver claims it needs:
> > 
> > Firmware file: shisp_2400b0_v21.bin
> > Version string: irci_stable_candrpv_0415_20150521_0458
> > 
> > What I have is:
> > 
> > Version string: irci_stable_candrpv_0415_20150423_1753
> > SHA1: 548d26a9b5daedbeb59a46ea1da69757d92cd4d6  shisp_2400b0_v21.bin
> > 
> 
> I am a bit at a loss here. The TODO file says
> 
> 7. The ISP code depends on the exact FW version. The version defined
> in
>BYT:
>drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.
> c
>static const char *release_version =
> STR(irci_stable_candrpv_0415_20150521_0458);
>CHT:
>drivers/staging/media/atomisp/pci/atomisp2/css/sh_css_firmware.c
>static const char *release_version = STR(irci_ecr-
> master_20150911_0724);
> 
> The different files obviously have been merged into the first:
> 
> /* The string STR is a place holder
>  * which will be replaced with the actual RELEASE_VERSION
>  * during package generation. Please do not modify  */
> #ifndef ISP2401
> static const char *release_version =
> STR(irci_stable_candrpv_0415_20150521_0458);
> #else
> static const char *release_version = STR(irci_ecr-
> master_20150911_0724);
> #endif
> 
> Trying to find the firmware files I came up with:
> 
> strings shisp_2400b0_v21.bin | grep irci
> irci_stable_candrpv_0415_20150423_1753
> 
> strings shisp_2401a0_v21.bin | grep irci
> irci_stable_candrpv_0415_20150521_0458
> 
> which seems to be an odd match. The CherryTrail FW is older than the
> one
> expected, but I could not find a newer one. The BayTrail FW is the
> same
> you have (but it should at least be compatible).
> Any hints on where to find the expected FW files? As my hardware is
> no android device, I can not look into an update kit.

For now we are all using that firmware I mentioned (with, of course,
hack-patch applied to make driver swallow it).

 Can I somehow help to improve
> > > > the driver?
> > 
> > Yes, definitely, but first of all we need to find at least one
> > device
> > and corresponding firmware where it actually works.
> > 
> > For me it doesn't generate any interrupt (after huge hacking to make
> > that firmware loaded and settings / platform data applied).
> > 
> 
> What exactly are you looking for?

For anything that *somehow* works.

>  An Android device where the ov2680
> works?

First of all, I most likely do not have hardware with such sensor.
Second, I'm using one of the prototype HW based on BayTrail with PCI
enumerable AtomISP.

>  Some x86_64 hardware, where the matching firmware is available and
> the driver in 4.15 works?

Yes, that's what I would like to have before moving forward with any new
sensor drivers, clean ups or alike type of changes to the driver.

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [BUG] atomisp_ov2680 not initializing correctly

[Kristian Beilke]

On Tue, Dec 19, 2017 at 10:37:01PM +0200, Andy Shevchenko wrote:
> On Tue, 2017-12-19 at 14:00 +0200, Sakari Ailus wrote:
> > Cc Alan and Andy.
> > 
> > On Sat, Dec 16, 2017 at 04:50:04PM +0100, Kristian Beilke wrote:
> > > Dear all,
> > > 
> > > I am trying to get the cameras in a Lenovo IdeaPad Miix 320 (Atom
> > > x5-Z8350 BayTrail) to work. The front camera is an ov2680. With
> > > kernel
> > > 4.14.4 and 4.15rc3 I see the following dmesg output:
> 
> It seems I forgot to send the rest of the patches I did while ago
> against AtomISP code.
> 
> It includes switch to normal DMI matching instead of the crap we have
> there right now.
> 
> WRT to the messages below it seems we have no platform data for that
> device. It needs to be added.
> 
> In any case, I have no firmware to test BayTrail hardware I have (MRD7).
> 
> The driver claims it needs:
> 
> Firmware file: shisp_2400b0_v21.bin
> Version string: irci_stable_candrpv_0415_20150521_0458
> 
> What I have is:
> 
> Version string: irci_stable_candrpv_0415_20150423_1753
> SHA1: 548d26a9b5daedbeb59a46ea1da69757d92cd4d6  shisp_2400b0_v21.bin
>

I am a bit at a loss here. The TODO file says

7. The ISP code depends on the exact FW version. The version defined in
   BYT:
   drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
   static const char *release_version = 
STR(irci_stable_candrpv_0415_20150521_0458);
   CHT:
   drivers/staging/media/atomisp/pci/atomisp2/css/sh_css_firmware.c
   static const char *release_version = STR(irci_ecr-master_20150911_0724);

The different files obviously have been merged into the first:

/* The string STR is a place holder
 * which will be replaced with the actual RELEASE_VERSION
 * during package generation. Please do not modify  */
#ifndef ISP2401
static const char *release_version = 
STR(irci_stable_candrpv_0415_20150521_0458);
#else
static const char *release_version = STR(irci_ecr-master_20150911_0724);
#endif

Trying to find the firmware files I came up with:

strings shisp_2400b0_v21.bin | grep irci
irci_stable_candrpv_0415_20150423_1753

strings shisp_2401a0_v21.bin | grep irci
irci_stable_candrpv_0415_20150521_0458

which seems to be an odd match. The CherryTrail FW is older than the one
expected, but I could not find a newer one. The BayTrail FW is the same
you have (but it should at least be compatible).
Any hints on where to find the expected FW files? As my hardware is
no android device, I can not look into an update kit.

> > > [   21.469907] ov2680: module is from the staging directory, the
> > > quality
> > >  is unknown, you have been warned.
> > > [   21.492774] ov2680 i2c-OVTI2680:00: gmin: initializing atomisp
> > > module
> > > subdev data.PMIC ID 1
> > > [   21.492891] acpi OVTI2680:00: Failed to find gmin variable
> > > OVTI2680:00_CamClk
> > > [   21.492974] acpi OVTI2680:00: Failed to find gmin variable
> > > OVTI2680:00_ClkSrc
> > > [   21.493090] acpi OVTI2680:00: Failed to find gmin variable
> > > OVTI2680:00_CsiPort
> > > [   21.493209] acpi OVTI2680:00: Failed to find gmin variable
> > > OVTI2680:00_CsiLanes
> > > [   21.493511] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V1P8SX
> > > not
> > > found, using dummy regulator
> > > [   21.493550] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V2P8SX
> > > not
> > > found, using dummy regulator
> > > [   21.493569] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V1P2A
> > > not
> > > found, using dummy regulator
> > > [   21.493585] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply
> > > VPROG4B
> > > not found, using dummy regulator
> > > [   21.568134] ov2680 i2c-OVTI2680:00: camera pdata: port: 0 lanes:
> > > 1
> > > order: 0002
> > > [   21.568257] ov2680 i2c-OVTI2680:00: read from offset 0x300a error
> > > -121
> > > [   21.568265] ov2680 i2c-OVTI2680:00: sensor_id_high = 0x
> > > [   21.568269] ov2680 i2c-OVTI2680:00: ov2680_detect err s_config.
> > > [   21.568291] ov2680 i2c-OVTI2680:00: sensor power-gating failed
> > > 
> > > Afterwards I do not get a camera device.
> > > 
> > > Am I missing some firmware or dependency?
> 
> See above.
> 
> > >  Can I somehow help to improve
> > > the driver?
> 
> Yes, definitely, but first of all we need to find at least one device
> and corresponding firmware where it actually works.
> 
> For me it doesn't generate any interrupt (after huge hacking to make
> that firmware loaded and settings / platform data applied).
> 

What exactly are you looking for? An Android device where the ov2680
works? Some x86_64 hardware, where the matching firmware is available and
the driver in 4.15 works?

> -- 
> Andy Shevchenko 
> Intel Finland Oy


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH v1] media: videobuf2: Add new uAPI for DVB streaming I/O

[Mauro Carvalho Chehab]

Em Tue, 19 Dec 2017 09:05:53 +0530
Satendra Singh Thakur  escreveu:

> -Ported below mentioned patch to latest kernel:
>  commit ace52288edf0 ("Merge tag 'for-linus-20171218' of
>  git://git.infradead.org/linux-mtd")
> 
> -Fixed few bugs in the patch, enhanced it and added polling
> --dvb_vb2.c:dvb_vb2_fill_buffer=>  
> Set the size of the outgoing buffer after while loop using
>  vb2_set_plane_payload
> Added NULL check for source buffer as per normal convention of
>  demux driver, this is called twice, first time with valid buffer
>  second time with NULL pointer, if its not handled, it will result in
>  crash
> ---Restricted spinlock for only list_* operations
> 
> --dvb_vb2.c:dvb_vb2_init=>  
> Restricted q->io_modes to only VB2_MMAP as its the only
>  supported mode
> 
> --dvb_vb2.c:dvb_vb2_release=>Replaced the && in if condiion with &,  
>  because it was always getting satisfied.
> 
> --dvb_vb2.c:dvb_vb2_stream_off=>Added list_del code for enqueud buffers  
>  upon stream off
> 
> -Added polling functionality
> --dvb_vb2.c:dvb_vb2_poll=>added this function  
> --dmxdev.c:dvb_demux_poll, dvb_dvr_poll=>Called dvb_vb2_poll from
>  these functions
> 
> -Ported this patch and latest videobuf2 to lower kernel versions and
>  tested auto scan
> 
> -Original patch=>
> --https://patchwork.linuxtv.org/patch/31613/
> 
> Signed-off-by: Junghak Sung 
> Signed-off-by: Geunyoung Kim 
> Acked-by: Seung-Woo Kim 
> Acked-by: Inki Dae 
> Signed-off-by: Satendra Singh Thakur 

Thanks for the patch!

I applied it on the top of Kernel 4.14 and fixed one bug that were causing 
an annoying WARN_ON() print.

Btw, as you wrote a poll() function, I suspect that you used some app to
test it. Care to ship the patches for your test application?

-

For now, I added on my experimental repository:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=dvb_mmap

I also applied the testing patch from 2015 on this tree:

https://git.linuxtv.org/mchehab/experimental-v4l-utils.git/log/?h=dvb_mmap

I ended by rewriting the patch description to make it clearer/more
complete.

And I took some statistics using "perf stats" command, using a DiBcom 8000
ISDB-T device (Prolink Microsystems Corp. PV-D231U(RN)-F), running on an
Intel NUC D53427RKE with an i5-3427U CPU @ 1.80GHz (2 cores, 2 threads/core),
equipped with SSD disks.

Those are the results:

1) Writing to a file, using read() syscalls

 Performance counter stats for 'dvbv5-zap -c /home/mchehab/dvb_channel.conf TV 
Brasilia RedeTV! -o /tmp/out -t120':

 117.253780  task-clock-msecs #  0.001 CPUs 
   4593  context-switches #  0.039 M/sec
425  CPU-migrations   #  0.004 M/sec
194  page-faults  #  0.002 M/sec
  284427111  cycles   #   2425.739 M/sec
  143947266  instructions #  0.506 IPC  
   11975002  cache-references #102.129 M/sec
3571404  cache-misses # 30.459 M/sec

  120.114989264  seconds time elapsed

2) Writing to a file, using mmap() syscalls

 Performance counter stats for 'dvbv5-zap -c /home/mchehab/dvb_channel.conf TV 
Brasilia RedeTV! -o /tmp/out -t120 -R':

  69.258796  task-clock-msecs #  0.001 CPUs 
999  context-switches #  0.014 M/sec
190  CPU-migrations   #  0.003 M/sec
182  page-faults  #  0.003 M/sec
  176921677  cycles   #   2554.501 M/sec
  125926300  instructions #  0.712 IPC  
5053616  cache-references # 72.967 M/sec
3123259  cache-misses # 45.095 M/sec

  120.235712497  seconds time elapsed

All performance indicators reduced. The most impressive ones are
the number of context switches, that reduced by about 4.5x, and the 
number of cache references by about 2,5x! 

3) Writing to /dev/null, using read() syscalls

 Performance counter stats for 'dvbv5-zap -c /home/mchehab/dvb_channel.conf TV 
Brasilia RedeTV! -o /dev/null -t120':

  67.633678  task-clock-msecs #  0.001 CPUs 
   4583  context-switches #  0.068 M/sec
113  CPU-migrations   #  0.002 M/sec
199  page-faults  #  0.003 M/sec
  152635399  cycles   #   2256.796 M/sec
   30920291  instructions #  0.203 IPC  
6273962  cache-references # 92.764 M/sec
1666393  cache-misses # 24.639 M/sec


4) writing to /dev/null, using mmap() syscalls

 Performance counter stats for 'dvbv5-zap -c /home/mchehab/dvb_channel.conf TV 
Brasilia RedeTV! -o /dev/null -t120 -R':

  19.198192  task-clock-msecs #  0.000 CPUs 
991  

[PATCH 1/1] v4l: fwnode: Use fwnode_graph_for_each_endpoint

[Sakari Ailus]

Use fwnode_graph_for_each_endpoint iterator for better readability.

Signed-off-by: Sakari Ailus 
---
 drivers/media/v4l2-core/v4l2-fwnode.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
b/drivers/media/v4l2-core/v4l2-fwnode.c
index 3cc8b6b69b41..c33d519281a2 100644
--- a/drivers/media/v4l2-core/v4l2-fwnode.c
+++ b/drivers/media/v4l2-core/v4l2-fwnode.c
@@ -472,8 +472,7 @@ static int __v4l2_async_notifier_parse_fwnode_endpoints(
if (WARN_ON(asd_struct_size < sizeof(struct v4l2_async_subdev)))
return -EINVAL;
 
-   for (fwnode = NULL; (fwnode = fwnode_graph_get_next_endpoint(
-dev_fwnode(dev), fwnode)); ) {
+   fwnode_graph_for_each_endpoint(dev_fwnode(dev), fwnode) {
struct fwnode_handle *dev_fwnode;
bool is_available;
 
-- 
2.11.0

[PATCH V2 3/3] media: dvb-core: Added documentation for ca sysfs timer nodes

[Jasmin J.]

From: Jasmin Jessich 

Added the documentation for the new ca? sysfs nodes in
/sys/class/dvb/dvb?/ca?/tim_wr_.

Signed-off-by: Jasmin Jessich 
---
 Documentation/ABI/testing/sysfs-class-ca| 63 ++
 Documentation/media/uapi/dvb/ca-sysfs-nodes.rst | 85 +
 Documentation/media/uapi/dvb/ca.rst |  1 +
 3 files changed, 149 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-ca
 create mode 100644 Documentation/media/uapi/dvb/ca-sysfs-nodes.rst

diff --git a/Documentation/ABI/testing/sysfs-class-ca 
b/Documentation/ABI/testing/sysfs-class-ca
new file mode 100644
index 000..7a2a52c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-ca
@@ -0,0 +1,63 @@
+What:  /sys/class/dvb/dvbN/
+Date:  Dec 2017
+KernelVersion: 4.15
+Contact:   Jasmin Jessich 
+Description:
+The dvbN/ class sub-directory belongs to the Adapter with the
+index N. It is created for each found Adapter and depends on
+the DVB hardware.
+
+What:  /sys/class/dvb/dvbN/caM
+Date:  Dec 2017
+KernelVersion: 4.15
+Contact:   Jasmin Jessich 
+Description:
+The dvbN/caM/ class sub-directory belongs to the CA device with
+the index M on the Adapter with the index N. It is created for
+each found Conditional Access Interface where M is the number
+of the CA Interface.
+
+What:  /sys/class/dvb/dvbN/caM/tim_wr_high
+Date:  Dec 2017
+KernelVersion: 4.15
+Contact:   Jasmin Jessich 
+Description:
+Reading this file returns the wait time after writing the
+length high byte to the CAM. The default timeout it '0', which
+means no 'no timeout'. Any other value specifies the timeout in
+micro seconds.
+  
+Writing a value will change the timeout.
+ 
+Write fails with ``EINVAL`` if an invalid value has been written
+(valid values are 0..10).
+
+What:  /sys/class/dvb/dvbN/caM/tim_wr_low
+Date:  Dec 2017
+KernelVersion: 4.15
+Contact:   Jasmin Jessich 
+Description:
+Reading this file returns the wait time after writing the
+length low byte to the CAM. The default timeout it '0', which
+means no 'no timeout'. Any other  value specifies the timeout in
+micro seconds.
+  
+Writing a value will change the timeout.
+ 
+Write fails with ``EINVAL`` if an invalid value has been written
+(valid values are 0..10).
+
+What:  /sys/class/dvb/dvbN/caM/tim_wr_data
+Date:  Dec 2017
+KernelVersion: 4.15
+Contact:   Jasmin Jessich 
+Description:
+Reading this file returns the wait time between data bytes sent
+to the CAM. The default timeout it '0', which means no 'no timeout'.
+Any other value specifies the timeout in micro seconds.
+
+Writing a value will change the timeout.
+ 
+Write fails with ``EINVAL`` if an invalid value has been written
+(valid values are 0..10).
+
diff --git a/Documentation/media/uapi/dvb/ca-sysfs-nodes.rst 
b/Documentation/media/uapi/dvb/ca-sysfs-nodes.rst
new file mode 100644
index 000..4a26afd
--- /dev/null
+++ b/Documentation/media/uapi/dvb/ca-sysfs-nodes.rst
@@ -0,0 +1,85 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _ca_sysfs_nodes:
+
+**
+Conditional Access sysfs nodes
+**
+
+As defined at ``Documentation/ABI/testing/sysfs-class-ca``, those are
+the sysfs nodes that control the en50221 CA driver:
+
+
+.. _sys_class_dvb_dvbN:
+
+/sys/class/dvb/dvbN/
+
+
+The ``/sys/class/dvb/dvbN/`` class sub-directory belongs to the Adapter
+with the index N. It is created for each found Adapter and depends on the
+DVB hardware.
+
+
+.. _sys_class_dvb_dvbN_caM:
+
+/sys/class/dvb/dvbN/caM
+===
+
+The ``/sys/class/dvb/dvbN/caM`` class sub-directory belongs to the CA device
+with the index M on the Adapter with the index N. It is created for each
+found Conditional Access Interface where M is the number of the CA Interface.
+A Conditional Access Module (CAM) will be inserted into the CI interface. The
+caM device is used to communicate to the CAM.
+
+The communication protocol contains a length field followed by the data bytes.
+The length is written in two parts. First the high byte of the length
+followed by the low byte. The following sysfs nodes define three timeouts
+which may be used to extend the communication to the CAM. Modern CAMs usually
+do not need those timeouts, but older CAMs will produce communication errors,
+when the bytes are written too fast. The underliying hardware has also a big
+impact due to the access speed.
+
+
+.. _sys_class_dvb_dvbN_caM_tim_wr_high:
+

[PATCH V2 1/3] media: dvb-core: Store device structure in dvb_register_device

[Jasmin J.]

From: Jasmin Jessich 

The device created by device_create in dvb_register_device was not
available for DVB device drivers.
Added "struct device *dev" to "struct dvb_device" and store the created
device.

Signed-off-by: Jasmin Jessich 
Acked-by: Ralph Metzler 
---
 drivers/media/dvb-core/dvbdev.c | 1 +
 drivers/media/dvb-core/dvbdev.h | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c
index 060c60d..f55eff1 100644
--- a/drivers/media/dvb-core/dvbdev.c
+++ b/drivers/media/dvb-core/dvbdev.c
@@ -538,6 +538,7 @@ int dvb_register_device(struct dvb_adapter *adap, struct 
dvb_device **pdvbdev,
   __func__, adap->num, dnames[type], id, PTR_ERR(clsdev));
return PTR_ERR(clsdev);
}
+   dvbdev->dev = clsdev;
dprintk("DVB: register adapter%d/%s%d @ minor: %i (0x%02x)\n",
adap->num, dnames[type], id, minor, minor);
 
diff --git a/drivers/media/dvb-core/dvbdev.h b/drivers/media/dvb-core/dvbdev.h
index bbc1c20..1f2d2ff 100644
--- a/drivers/media/dvb-core/dvbdev.h
+++ b/drivers/media/dvb-core/dvbdev.h
@@ -147,10 +147,11 @@ struct dvb_adapter {
  * @tsout_num_entities: Number of Transport Stream output entities
  * @tsout_entity: array with MC entities associated to each TS output node
  * @tsout_pads: array with the source pads for each @tsout_entity
+ * @dev:   pointer to struct device that is associated with the dvb device
  *
  * This structure is used by the DVB core (frontend, CA, net, demux) in
  * order to create the device nodes. Usually, driver should not initialize
- * this struct diretly.
+ * this struct directly.
  */
 struct dvb_device {
struct list_head list_head;
@@ -183,6 +184,7 @@ struct dvb_device {
 #endif
 
void *priv;
+   struct device *dev;
 };
 
 /**
-- 
2.7.4

[PATCH V2 2/3] media: dvb-core: Added timers for dvb_ca_en50221_write_data

[Jasmin J.]

From: Jasmin Jessich 

Some (older) CAMs are really slow in accepting data. The CI interface
specification doesn't define a handshake for accepted data. Thus, the
en50221 protocol driver can't control if a data byte has been correctly
written to the CAM.

The current implementation writes the length and the data quick after
each other. Thus, the slow CAMs may generate a WR error, which leads to
the known error logging
   "CAM tried to send a buffer larger than the ecount size".

To solve this issue the en50221 protocol driver needs to wait some CAM
depending time between the different bytes to be written. Because the
time is CAM dependent, an individual value per CAM needs to be set. For
that SysFS is used in favor of ioctl's to allow the control of the timer
values independent from any user space application.

This patch adds the timers and the SysFS nodes to set/get the timeout
values and the timer waiting between the different steps of the CAM write
access. A timer value of 0 (default) means "no timeout".

Signed-off-by: Jasmin Jessich 
Acked-by: Ralph Metzler 
---
 drivers/media/dvb-core/dvb_ca_en50221.c | 132 +++-
 1 file changed, 131 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-core/dvb_ca_en50221.c 
b/drivers/media/dvb-core/dvb_ca_en50221.c
index a3b2754..9b45d6b 100644
--- a/drivers/media/dvb-core/dvb_ca_en50221.c
+++ b/drivers/media/dvb-core/dvb_ca_en50221.c
@@ -86,6 +86,13 @@ MODULE_PARM_DESC(cam_debug, "enable verbose debug messages");
 #define DVB_CA_SLOTSTATE_WAITFR 6
 #define DVB_CA_SLOTSTATE_LINKINIT   7
 
+enum dvb_ca_timers {
+   DVB_CA_TIM_WR_HIGH  /* wait after writing length high */
+,  DVB_CA_TIM_WR_LOW   /* wait after writing length low */
+,  DVB_CA_TIM_WR_DATA  /* wait between data bytes */
+,  DVB_CA_TIM_MAX
+};
+
 /* Information on a CA slot */
 struct dvb_ca_slot {
/* current state of the CAM */
@@ -119,6 +126,11 @@ struct dvb_ca_slot {
unsigned long timeout;
 };
 
+struct dvb_ca_timer {
+   unsigned long min;
+   unsigned long max;
+};
+
 /* Private CA-interface information */
 struct dvb_ca_private {
struct kref refcount;
@@ -161,6 +173,14 @@ struct dvb_ca_private {
 
/* mutex serializing ioctls */
struct mutex ioctl_mutex;
+
+   struct dvb_ca_timer timers[DVB_CA_TIM_MAX];
+};
+
+static const char dvb_ca_tim_names[DVB_CA_TIM_MAX][15] = {
+   "tim_wr_high"
+,  "tim_wr_low"
+,  "tim_wr_data"
 };
 
 static void dvb_ca_private_free(struct dvb_ca_private *ca)
@@ -223,6 +243,14 @@ static char *findstr(char *haystack, int hlen, char 
*needle, int nlen)
return NULL;
 }
 
+static void dvb_ca_sleep(struct dvb_ca_private *ca, enum dvb_ca_timers tim)
+{
+   unsigned long min = ca->timers[tim].min;
+
+   if (min)
+   usleep_range(min, ca->timers[tim].max);
+}
+
 /* ** 
*/
 /* EN50221 physical interface functions */
 
@@ -869,10 +897,13 @@ static int dvb_ca_en50221_write_data(struct 
dvb_ca_private *ca, int slot,
bytes_write >> 8);
if (status)
goto exit;
+   dvb_ca_sleep(ca, DVB_CA_TIM_WR_HIGH);
+
status = ca->pub->write_cam_control(ca->pub, slot, CTRLIF_SIZE_LOW,
bytes_write & 0xff);
if (status)
goto exit;
+   dvb_ca_sleep(ca, DVB_CA_TIM_WR_LOW);
 
/* send the buffer */
for (i = 0; i < bytes_write; i++) {
@@ -880,6 +911,7 @@ static int dvb_ca_en50221_write_data(struct dvb_ca_private 
*ca, int slot,
buf[i]);
if (status)
goto exit;
+   dvb_ca_sleep(ca, DVB_CA_TIM_WR_DATA);
}
 
/* check for write error (WE should now be 0) */
@@ -1834,6 +1866,97 @@ static const struct dvb_device dvbdev_ca = {
 };
 
 /* ** 
*/
+/* EN50221 device attributes (SysFS) */
+
+static int dvb_ca_tim_idx(struct dvb_ca_private *ca, const char *name)
+{
+   int tim_idx;
+
+   for (tim_idx = 0; tim_idx < DVB_CA_TIM_MAX; tim_idx++) {
+   if (!strcmp(dvb_ca_tim_names[tim_idx], name))
+   return tim_idx;
+   }
+   return -1;
+}
+
+static ssize_t dvb_ca_tim_show(struct device *device,
+  struct device_attribute *attr, char *buf)
+{
+   struct dvb_device *dvbdev = dev_get_drvdata(device);
+   struct dvb_ca_private *ca = dvbdev->priv;
+   int tim_idx = dvb_ca_tim_idx(ca, attr->attr.name);
+
+   if (tim_idx < 0)
+   return -ENXIO;
+
+   return sprintf(buf, "%ld\n", ca->timers[tim_idx].min);
+}
+
+static ssize_t dvb_ca_tim_store(struct device *device,
+   struct 

[PATCH V2 0/3] Add timers to en50221 protocol driver

[Jasmin J.]

From: Jasmin Jessich 

Some (older) CAMs are really slow in accepting data. I got sometimes the 
already known error "CAM tried to send a buffer larger than the ecount 
size". I could track it down to the dvb_ca_en50221_write_data function not 
waiting between sending the data length high/low and data bytes. In fact
the CAM reported a WR error, which triggered later on the mentioned error.
 
The problem is that a simple module parameter can't be used to solve this
by adding timer values, because the protocol handler is used for any CI
interface. A module parameter would be influence all the CAMs on all CI
interfaces. Thus individual timer definitions per CI interface and CAM are
required.
There are two possibilities to implement that, ioctl's and SysFS.
ioctl's require changes in usermode programs and it may take a lot of time
to get this implemented there.
SysFS can be used by simple "cat" and "echo" commands and can be therefore
simply controlled by scripting, which is immediately available.

I decided to go for the SysFS approach, but the required device to add the
SysFS files was not available in the "struct dvb_device". The first patch
of this series adds this device to the structure and also the setting code.

The second patch adds the functions to create the SysFS nodes for all
timers and the new timeouts in the en50221 protocol driver.

The third patch adds the SysFS node documentation.

Jasmin Jessich (3):
  media: dvb-core: Store device structure in dvb_register_device
  media: dvb-core: Added timers for dvb_ca_en50221_write_data
  media: dvb-core: Added documentation for ca sysfs timer nodes

 Documentation/ABI/testing/sysfs-class-ca|  63 +++
 Documentation/media/uapi/dvb/ca-sysfs-nodes.rst |  85 +++
 Documentation/media/uapi/dvb/ca.rst |   1 +
 drivers/media/dvb-core/dvb_ca_en50221.c | 132 +++-
 drivers/media/dvb-core/dvbdev.c |   1 +
 drivers/media/dvb-core/dvbdev.h |   4 +-
 6 files changed, 284 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-class-ca
 create mode 100644 Documentation/media/uapi/dvb/ca-sysfs-nodes.rst

-- 
2.7.4

Re: [PATCH v4 16/18] scripts: kernel-doc: improve nested logic to handle multiple identifiers

[kbuild test robot]

Hi Mauro,

I love your patch! Perhaps something to improve:

[auto build test WARNING on lwn/docs-next]
[also build test WARNING on v4.15-rc4 next-20171221]
[cannot apply to linus/master]
[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/Mauro-Carvalho-Chehab/kernel-doc-add-supported-to-document-nested-structs/20171221-055609
base:   git://git.lwn.net/linux-2.6 docs-next
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
   include/crypto/hash.h:89: warning: duplicate section name 'Note'
   include/crypto/hash.h:95: warning: duplicate section name 'Note'
   include/crypto/hash.h:102: warning: duplicate section name 'Note'
   include/crypto/hash.h:89: warning: duplicate section name 'Note'
   include/crypto/hash.h:95: warning: duplicate section name 'Note'
   include/crypto/hash.h:102: warning: duplicate section name 'Note'
   include/crypto/hash.h:89: warning: duplicate section name 'Note'
   include/crypto/hash.h:95: warning: duplicate section name 'Note'
   include/crypto/hash.h:102: warning: duplicate section name 'Note'
   include/crypto/hash.h:89: warning: duplicate section name 'Note'
   include/crypto/hash.h:95: warning: duplicate section name 'Note'
   include/crypto/hash.h:102: warning: duplicate section name 'Note'
   include/crypto/hash.h:89: warning: duplicate section name 'Note'
   include/crypto/hash.h:95: warning: duplicate section name 'Note'
   include/crypto/hash.h:102: warning: duplicate section name 'Note'
   include/crypto/hash.h:89: warning: duplicate section name 'Note'
   include/crypto/hash.h:95: warning: duplicate section name 'Note'
   include/crypto/hash.h:102: warning: duplicate section name 'Note'
   include/crypto/hash.h:89: warning: duplicate section name 'Note'
   include/crypto/hash.h:95: warning: duplicate section name 'Note'
   include/crypto/hash.h:102: warning: duplicate section name 'Note'
   include/crypto/hash.h:89: warning: duplicate section name 'Note'
   include/crypto/hash.h:95: warning: duplicate section name 'Note'
   include/crypto/hash.h:102: warning: duplicate section name 'Note'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.ablkcipher' not described in 'crypto_alg'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.blkcipher' not described in 'crypto_alg'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.cipher' not described in 'crypto_alg'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.compress' not described in 'crypto_alg'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.ablkcipher' not described in 'crypto_alg'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.blkcipher' not described in 'crypto_alg'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.cipher' not described in 'crypto_alg'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.compress' not described in 'crypto_alg'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.ablkcipher' not described in 'crypto_alg'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.blkcipher' not described in 'crypto_alg'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.cipher' not described in 'crypto_alg'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.compress' not described in 'crypto_alg'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.ablkcipher' not described in 'crypto_alg'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.blkcipher' not described in 'crypto_alg'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.cipher' not described in 'crypto_alg'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.compress' not described in 'crypto_alg'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.ablkcipher' not described in 'crypto_alg'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.blkcipher' not described in 'crypto_alg'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.cipher' not described in 'crypto_alg'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.compress' not described in 'crypto_alg'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.ablkcipher' not described in 'crypto_alg'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.blkcipher' not described in 'crypto_alg'
   include/linux/crypto.h:469: warning: Function parameter or member 
'cra_u.cipher' not described in 'cryp

Re: [PATCH] media: ov9650: support VIDIOC_DBG_G/S_REGISTER ioctls

[Sakari Ailus]

Hi Hans,

On Tue, Dec 19, 2017 at 04:50:19PM +0100, Hans Verkuil wrote:
> On 19/12/17 16:39, Akinobu Mita wrote:
> > Hi Sakari,
> > 
> > 2017-12-19 19:35 GMT+09:00 Sakari Ailus :
> >> Hi Akinobu,
> >>
> >> On Thu, Dec 14, 2017 at 01:00:49AM +0900, Akinobu Mita wrote:
> >>> This adds support VIDIOC_DBG_G/S_REGISTER ioctls.
> >>>
> >>> There are many device control registers contained in the OV9650.  So
> >>> this helps debugging the lower level issues by getting and setting the
> >>> registers.
> >>>
> >>> Cc: Sylwester Nawrocki 
> >>> Cc: Sakari Ailus 
> >>> Cc: Mauro Carvalho Chehab 
> >>> Signed-off-by: Akinobu Mita 
> >>
> >> Just wondering --- doesn't the I涎 user space interface offer essentially
> >> the same functionality?
> > 
> > You are right.  I thought /dev/i2c-X interface is not allowed for the
> > i2c device that is currently in use by a driver.  But I found that
> > there is I2C_SLAVE_FORCE ioctl to bypass the check and the i2cget and
> > i2cset with '-f' option use I2C_SLAVE_FORCE ioctls.
> > 
> > So I can live without the proposed patch.
> 
> Sakari, there are lots of drivers that use this. There is nothing wrong with
> it and it is easier to use than the i2c interface (although that's my 
> opinion).
> It certainly is more consistent with other drivers.
> 
> It is also possible to use registernames instead of addresses if the necessary
> patch is applied to v4l2-dbg.

There are existing generic interfaces that provide the same functionality,
in this case without driver changes. With debugfs, you can also use
register names if needed. That's why I'm slightly reluctant in supporting
s_register and g_register.

Let's discuss this on #v4l when you're available.

-- 
Regards,

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

Re: [PATCH] devicetree: Add video bus switch

[Sakari Ailus]

On Wed, Dec 20, 2017 at 07:54:12PM +0200, Laurent Pinchart wrote:
> Hi Pavel,
> 
> On Saturday, 4 February 2017 23:56:10 EET Pavel Machek wrote:
> > Hi!
> > 
> >  +Required properties
> >  +===
> >  +
> >  +compatible: must contain "video-bus-switch"
> > >>> 
> > >>> How generic is this? Should we have e.g. nokia,video-bus-switch? And
> > >>> if so, change the file name accordingly.
> > >> 
> > >> Generic for "single GPIO controls the switch", AFAICT. But that should
> > >> be common enough...
> > > 
> > > Um, yes. Then... how about: video-bus-switch-gpio? No Nokia prefix.
> > 
> > Ok, done. I also fixed the english a bit.
> > 
> >  +reg   : The interface:
> >  +0 - port for image signal processor
> >  +1 - port for first camera sensor
> >  +2 - port for second camera sensor
> > >>> 
> > >>> I'd say this must be pretty much specific to the one in N900. You
> > >>> could have more ports. Or you could say that ports beyond 0 are
> > >>> camera sensors. I guess this is good enough for now though, it can be
> > >>> changed later on with the source if a need arises.
> > >> 
> > >> Well, I'd say that selecting between two sensors is going to be the
> > >> common case. If someone needs more than two, it will no longer be
> > >> simple GPIO, so we'll have some fixing to do.
> > > 
> > > It could be two GPIOs --- that's how the GPIO I2C mux works.
> > > 
> > > But I'd be surprised if someone ever uses something like that
> > > again. ;-)
> > 
> > I'd say.. lets handle that when we see hardware like that.
> > 
> > >>> Btw. was it still considered a problem that the endpoint properties
> > >>> for the sensors can be different? With the g_routing() pad op which is
> > >>> to be added, the ISP driver (should actually go to a framework
> > >>> somewhere) could parse the graph and find the proper endpoint there.
> > >> 
> > >> I don't know about g_routing. I added g_endpoint_config method that
> > >> passes the configuration, and that seems to work for me.
> > >> 
> > >> I don't see g_routing in next-20170201 . Is there place to look?
> > > 
> > > I think there was a patch by Laurent to LMML quite some time ago. I
> > > suppose that set will be repicked soonish.
> > > 
> > > I don't really object using g_endpoint_config() as a temporary solution;
> > > I'd like to have Laurent's opinion on that though. Another option is to
> > > wait, but we've already waited a looong time (as in total).
> > 
> > Laurent, do you have some input here? We have simple "2 cameras
> > connected to one signal processor" situation here. We need some way of
> > passing endpoint configuration from the sensors through the switch. I
> > did this:
> 
> Could you give me a bit more information about the platform you're targeting: 
> how the switch is connected, what kind of switch it is, and what endpoint 
> configuration data you need ?
> 
> > >> @@ -415,6 +416,8 @@ struct v4l2_subdev_video_ops {
> > >>  const struct v4l2_mbus_config *cfg);
> > >> int (*s_rx_buffer)(struct v4l2_subdev *sd, void *buf,
> > >>unsigned int *size);
> > >> +   int (*g_endpoint_config)(struct v4l2_subdev *sd,
> > >> +   struct v4l2_of_endpoint *cfg);
> > 
> > Google of g_routing tells me:
> > 
> > 9) Highly reconfigurable hardware - Julien Beraud
> > 
> > - 44 sub-devices connected with an interconnect.
> > - As long as formats match, any sub-device could be connected to any
> > - other sub-device through a link.
> > - The result is 44 * 44 links at worst.
> > - A switch sub-device proposed as the solution to model the
> > - interconnect. The sub-devices are connected to the switch
> > - sub-devices through the hardware links that connect to the
> > - interconnect.
> > - The switch would be controlled through new IOCTLs S_ROUTING and
> > - G_ROUTING.
> > - Patches available:
> >  http://git.linuxtv.org/cgit.cgi/pinchartl/media.git/log/?h=xilinx-wip
> > 
> > but the patches are from 2005. So I guess I'll need some guidance here...
> 
> You made me feel very old for a moment. The patches are from 2015 :-)

There are up-to-date patches here:



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