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:   Thu Mar 30 05:00:20 CEST 2017
media-tree git hash:c3d4fb0fb41f4b5eafeee51173c14e50be12f839
media_build git hash:   bc4c2a205c087c8deff3cd14ed663c4767dd2016
v4l-utils git hash: 8fc88615b49843acb82cd8316d0bc4ab8474cba2
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: 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: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
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: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9-i686: OK
linux-4.10.1-i686: OK
linux-4.11-rc1-i686: OK
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
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: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9-x86_64: WARNINGS
linux-4.10.1-x86_64: WARNINGS
linux-4.11-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH 22/22] usb: document that URB transfer_buffer should be aligned

[Mauro Carvalho Chehab]

Em Thu, 30 Mar 2017 01:15:27 +0300
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> Thank you for the patch.
> 
> On Wednesday 29 Mar 2017 15:54:21 Mauro Carvalho Chehab wrote:
> > Several host controllers, commonly found on ARM, like dwc2,
> > require buffers that are CPU-word aligned for they to work.
> > 
> > Failing to do that will cause random troubles at the caller
> > drivers, causing them to fail.
> > 
> > Document it.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  Documentation/driver-api/usb/URB.rst | 18 ++
> >  drivers/usb/core/message.c   | 15 +++
> >  include/linux/usb.h  | 18 ++
> >  3 files changed, 51 insertions(+)
> > 
> > diff --git a/Documentation/driver-api/usb/URB.rst
> > b/Documentation/driver-api/usb/URB.rst index d9ea6a3996e7..b83b557e9891
> > 100644
> > --- a/Documentation/driver-api/usb/URB.rst
> > +++ b/Documentation/driver-api/usb/URB.rst
> > @@ -274,6 +274,24 @@ If you specify your own start frame, make sure it's
> > several frames in advance of the current frame.  You might want this model
> > if you're synchronizing ISO data with some other event stream.
> > 
> > +.. note::
> > +
> > +   Several host drivers require that the ``transfer_buffer`` to be aligned
> > +   with the CPU word size (e. g. DWORD for 32 bits, QDWORD for 64 bits).  
> 
> Is it the CPU word size or the DMA transfer size ? I assume the latter, and I 
> wouldn't be surprised if the alignment requirement was 32-bit on at least 
> some 
> of the 64-bit platforms.

Yeah, it is actually the DMA transfer size. Yet, worse case scenario is that
the DMA transfer size to be 64 bits on 64 bits CPU.

> 
> > +   It is up to USB drivers should ensure that they'll only pass buffers
> > +   with such alignments.
> > +
> > +   Please also notice that, due to such restriction, the host driver  
> 
> s/notice/note/ (and below as well) ?

OK.

> > +   may also override PAD bytes at the end of the ``transfer_buffer``, up to
> > the
> > +   size of the CPU word.  
> 
> "May" is quite weak here. If some host controller drivers require buffers to 
> be aligned, then it's an API requirement, and all buffers must be aligned. 
> I'm 
> not even sure I would mention that some host drivers require it, I think we 
> should just state that the API requires buffers to be aligned.

What I'm trying to say here is that, on a 32-bits system, if the driver do
a USB_DIR_IN transfer using some code similar to:

size = 4;
buffer = kmalloc(size, GFP_KERNEL);

usb_control_msg(udev, pipe, req, type, val, idx, buffer + 2, 2, 
timeout);
usb_control_msg(udev, pipe, req, type, val, idx, buffer, size, timeout);

Drivers like dwc2 will mess with the buffer.

The first transfer will actually work, due to a workaround inside the
driver that will create a temporary DWORD-aligned buffer, avoiding it
to go past the buffer.

However, the second transfer will destroy the data received from the
first usb_control_msg(), as it will write 4 bytes at the buffer.

Not all drivers would do that, though.

Please notice that, as kmalloc will always return a CPU-aligned buffer,
if the client do something like:

size = 2;
buffer = kmalloc(size, GFP_KERNEL);

usb_control_msg(udev, pipe, req, type, val, idx, buffer, 2, timeout);

What happens there is that the DMA engine will still write 4 bytes at
the buffer, but the 2 bytes that go past the end of buffer will be
written on a memory that will never be used.

> 
> > +   Please notice that ancillary routines that transfer URBs, like
> > +   usb_control_msg() also have such restriction.
> > +
> > +   Such word alignment condition is normally ensured if the buffer is
> > +   allocated with kmalloc(), but this may not be the case if the driver
> > +   allocates a bigger buffer and point to a random place inside it.
> > +
> > 
> >  How to start interrupt (INT) transfers?
> >  ===
> > diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
> > index 4c38ea41ae96..1662a4446475 100644
> > --- a/drivers/usb/core/message.c
> > +++ b/drivers/usb/core/message.c
> > @@ -128,6 +128,21 @@ static int usb_internal_control_msg(struct usb_device
> > *usb_dev, * make sure your disconnect() method can wait for it to complete.
> > Since you * don't have a handle on the URB used, you can't cancel the
> > request. *
> > + * .. note::
> > + *
> > + *   Several host drivers require that the @data buffer to be aligned
> > + *   with the CPU word size (e. g. DWORD for 32 bits, QDWORD for 64 bits).
> > + *   It is up to USB drivers should ensure that they'll only pass buffers
> > + *   with such alignments.
> > + *
> > + *   Please also notice that, due to such restriction, the host driver
> > + *   may also override PAD bytes at the end of the @data buffer, up to the
> > + *   size of the CPU word.
> > + *
> > + 

build_media compilation issues

[Nigel Terry]

I'm trying to use build_media to build the media drivers, specifically
usb/em28xx, for Centos7. I'm getting compile errors, see below. Can
anyone help me?

Kernel:
$ uname -a
Linux mythpbx.lan 3.10.0-514.10.2.el7.x86_64 #1 SMP Fri Mar 3 00:04:05
UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Errors:
...
  CC [M]  /home/mythtv/buildmedia/media_build/v4l/dvb_usb_core.o
/home/mythtv/buildmedia/media_build/v4l/dvb_usb_core.c: In function
'dvb_usb_start_feed':
/home/mythtv/buildmedia/media_build/v4l/dvb_usb_core.c:274:2: warning:
passing argument 3 of 'wait_on_bit' makes integer from pointer without
a cast [enabled by default]
  wait_on_bit(>state_bits, ADAP_INIT, wait_schedule,
TASK_UNINTERRUPTIBLE);
  ^
In file included from include/linux/kobject.h:27:0,
 from include/linux/device.h:17,
 from include/linux/input.h:22,
 from /home/mythtv/buildmedia/media_build/v4l/compat.h:10,
 from :0:
include/linux/wait.h:1044:1: note: expected 'unsigned int' but
argument is of type 'int (*)(void *)'
 wait_on_bit(void *word, int bit, unsigned mode)
 ^
/home/mythtv/buildmedia/media_build/v4l/dvb_usb_core.c:274:2: error:
too many arguments to function 'wait_on_bit'
  wait_on_bit(>state_bits, ADAP_INIT, wait_schedule,
TASK_UNINTERRUPTIBLE);
  ^
In file included from include/linux/kobject.h:27:0,
 from include/linux/device.h:17,
 from include/linux/input.h:22,
 from /home/mythtv/buildmedia/media_build/v4l/compat.h:10,
 from :0:
include/linux/wait.h:1044:1: note: declared here
 wait_on_bit(void *word, int bit, unsigned mode)
 ^
/home/mythtv/buildmedia/media_build/v4l/dvb_usb_core.c: In function
'dvb_usb_fe_sleep':
/home/mythtv/buildmedia/media_build/v4l/dvb_usb_core.c:623:5: warning:
passing argument 3 of 'wait_on_bit' makes integer from pointer without
a cast [enabled by default]
 wait_schedule, TASK_UNINTERRUPTIBLE);
 ^
In file included from include/linux/kobject.h:27:0,
 from include/linux/device.h:17,
 from include/linux/input.h:22,
 from /home/mythtv/buildmedia/media_build/v4l/compat.h:10,
 from :0:
include/linux/wait.h:1044:1: note: expected 'unsigned int' but
argument is of type 'int (*)(void *)'
 wait_on_bit(void *word, int bit, unsigned mode)
 ^
/home/mythtv/buildmedia/media_build/v4l/dvb_usb_core.c:623:5: error:
too many arguments to function 'wait_on_bit'
 wait_schedule, TASK_UNINTERRUPTIBLE);
 ^
In file included from include/linux/kobject.h:27:0,
 from include/linux/device.h:17,
 from include/linux/input.h:22,
 from /home/mythtv/buildmedia/media_build/v4l/compat.h:10,
 from :0:
include/linux/wait.h:1044:1: note: declared here
 wait_on_bit(void *word, int bit, unsigned mode)
 ^
make[3]: *** [/home/mythtv/buildmedia/media_build/v4l/dvb_usb_core.o] Error 1
make[2]: *** [_module_/home/mythtv/buildmedia/media_build/v4l] Error 2
make[2]: Leaving directory `/usr/src/kernels/3.10.0-514.10.2.el7.x86_64'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/home/mythtv/buildmedia/media_build/v4l'
make: *** [all] Error 2
build failed at ./build line 491.

Re: [PATCH 22/22] usb: document that URB transfer_buffer should be aligned

[Laurent Pinchart]

Hi Mauro,

Thank you for the patch.

On Wednesday 29 Mar 2017 15:54:21 Mauro Carvalho Chehab wrote:
> Several host controllers, commonly found on ARM, like dwc2,
> require buffers that are CPU-word aligned for they to work.
> 
> Failing to do that will cause random troubles at the caller
> drivers, causing them to fail.
> 
> Document it.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/driver-api/usb/URB.rst | 18 ++
>  drivers/usb/core/message.c   | 15 +++
>  include/linux/usb.h  | 18 ++
>  3 files changed, 51 insertions(+)
> 
> diff --git a/Documentation/driver-api/usb/URB.rst
> b/Documentation/driver-api/usb/URB.rst index d9ea6a3996e7..b83b557e9891
> 100644
> --- a/Documentation/driver-api/usb/URB.rst
> +++ b/Documentation/driver-api/usb/URB.rst
> @@ -274,6 +274,24 @@ If you specify your own start frame, make sure it's
> several frames in advance of the current frame.  You might want this model
> if you're synchronizing ISO data with some other event stream.
> 
> +.. note::
> +
> +   Several host drivers require that the ``transfer_buffer`` to be aligned
> +   with the CPU word size (e. g. DWORD for 32 bits, QDWORD for 64 bits).

Is it the CPU word size or the DMA transfer size ? I assume the latter, and I 
wouldn't be surprised if the alignment requirement was 32-bit on at least some 
of the 64-bit platforms.

> +   It is up to USB drivers should ensure that they'll only pass buffers
> +   with such alignments.
> +
> +   Please also notice that, due to such restriction, the host driver

s/notice/note/ (and below as well) ?

> +   may also override PAD bytes at the end of the ``transfer_buffer``, up to
> the
> +   size of the CPU word.

"May" is quite weak here. If some host controller drivers require buffers to 
be aligned, then it's an API requirement, and all buffers must be aligned. I'm 
not even sure I would mention that some host drivers require it, I think we 
should just state that the API requires buffers to be aligned.

> +   Please notice that ancillary routines that transfer URBs, like
> +   usb_control_msg() also have such restriction.
> +
> +   Such word alignment condition is normally ensured if the buffer is
> +   allocated with kmalloc(), but this may not be the case if the driver
> +   allocates a bigger buffer and point to a random place inside it.
> +
> 
>  How to start interrupt (INT) transfers?
>  ===
> diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
> index 4c38ea41ae96..1662a4446475 100644
> --- a/drivers/usb/core/message.c
> +++ b/drivers/usb/core/message.c
> @@ -128,6 +128,21 @@ static int usb_internal_control_msg(struct usb_device
> *usb_dev, * make sure your disconnect() method can wait for it to complete.
> Since you * don't have a handle on the URB used, you can't cancel the
> request. *
> + * .. note::
> + *
> + *   Several host drivers require that the @data buffer to be aligned
> + *   with the CPU word size (e. g. DWORD for 32 bits, QDWORD for 64 bits).
> + *   It is up to USB drivers should ensure that they'll only pass buffers
> + *   with such alignments.
> + *
> + *   Please also notice that, due to such restriction, the host driver
> + *   may also override PAD bytes at the end of the @data buffer, up to the
> + *   size of the CPU word.
> + *
> + *   Such word alignment condition is normally ensured if the buffer is
> + *   allocated with kmalloc(), but this may not be the case if the driver
> + *   allocates a bigger buffer and point to a random place inside it.
> + *
>   * Return: If successful, the number of bytes transferred. Otherwise, a
> negative * error number.
>   */
> diff --git a/include/linux/usb.h b/include/linux/usb.h
> index 7e68259360de..8b5ad6624708 100644
> --- a/include/linux/usb.h
> +++ b/include/linux/usb.h
> @@ -1373,6 +1373,24 @@ typedef void (*usb_complete_t)(struct urb *);
>   * capable, assign NULL to it, so that usbmon knows not to use the value.
>   * The setup_packet must always be set, so it cannot be located in highmem.
> *
> + * .. note::
> + *
> + *   Several host drivers require that the @transfer_buffer to be aligned
> + *   with the CPU word size (e. g. DWORD for 32 bits, QDWORD for 64 bits).
> + *   It is up to USB drivers should ensure that they'll only pass buffers
> + *   with such alignments.
> + *
> + *   Please also notice that, due to such restriction, the host driver
> + *   may also override PAD bytes at the end of the @transfer_buffer, up to
> the + *   size of the CPU word.
> + *
> + *   Please notice that ancillary routines that start URB transfers, like
> + *   usb_control_msg() also have such restriction.
> + *
> + *   Such word alignment condition is normally ensured if the buffer is
> + *   allocated with kmalloc(), but this may not be the case if the driver
> + *   allocates a bigger buffer and point to a random place inside it.
> + *

Couldn't 

Re: [PATCH 1/3] [media] mceusb: RX -EPIPE (urb status = -32) lockup failure fix

[A Sun]

On 3/29/2017 5:06 PM, Sean Young wrote:

> 
> Anyway, you're right and this patch looks ok. It would be nice to have the
> tx case handled too though.
> 
> Thanks
> Sean
> 

Thanks; I'm looking at handling the tx case. If I can figure out the details, 
I'll post a new patch proposal separate, and likely dependent, on this one.

My main obstacle at the moment, is I'm looking for a way to get mceusb device 
to respond with a USB TX error halt/stall (rather than the typical ACK and NAK) 
on a TX endpoint, in order to test halt/stall error detection and recovery for 
TX. ..A Sun

[GIT PULL for v4.12] Make use of refcount_t in V4L2

[Sakari Ailus]

Hi Mauro,

These patches begin using refcount_t in counting references to VB2 buffers
as well as cx88 core.

Please pull.


The following changes since commit c3d4fb0fb41f4b5eafeee51173c14e50be12f839:

  [media] rc: sunxi-cir: simplify optional reset handling (2017-03-24 08:30:03 
-0300)

are available in the git repository at:

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

for you to fetch changes up to e1588d503639483a5a826dc0a2cd17eab0e44504:

  vb2: convert vb2_vmarea_handler refcount from atomic_t to refcount_t 
(2017-03-27 19:55:35 +0300)


Elena Reshetova (2):
  cx88: convert struct cx88_core.refcount from atomic_t to refcount_t
  vb2: convert vb2_vmarea_handler refcount from atomic_t to refcount_t

 drivers/media/pci/cx88/cx88-cards.c|  2 +-
 drivers/media/pci/cx88/cx88-core.c |  4 ++--
 drivers/media/pci/cx88/cx88.h  |  3 ++-
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 11 ++-
 drivers/media/v4l2-core/videobuf2-dma-sg.c | 11 ++-
 drivers/media/v4l2-core/videobuf2-memops.c |  6 +++---
 drivers/media/v4l2-core/videobuf2-vmalloc.c| 11 ++-
 include/media/videobuf2-memops.h   |  3 ++-
 8 files changed, 28 insertions(+), 23 deletions(-)

-- 
Kind regards,

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

[PATCH v2] staging: atomisp: avoid false-positive maybe-uninitialized warning

[Arnd Bergmann]

In combination with CONFIG_PROFILE_ANNOTATED_BRANCHES=y, the unlikely()
inside of the WARN() macro becomes too complex for gcc to see that
we don't use the output arguments of mt9m114_to_res() are used
correctly:

drivers/staging/media/atomisp/i2c/mt9m114.c: In function 'mt9m114_get_fmt':
drivers/staging/media/atomisp/i2c/mt9m114.c:817:13: error: 'height' may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
  int width, height;
 ^~
drivers/staging/media/atomisp/i2c/mt9m114.c: In function 
'mt9m114_s_exposure_selection':
drivers/staging/media/atomisp/i2c/mt9m114.c:1179:13: error: 'height' may be 
used uninitialized in this function [-Werror=maybe-uninitialized]

Without WARN_ON(), there is no problem, so by simply replacing it with
v4l2_err(), the warnings go away. The WARN() output is also not needed
here, as we'd probably catch the problem before even getting here,
and other checks for the same condition already use v4l2_err.

Signed-off-by: Arnd Bergmann 
---
v2: fix new build regression found by 0day kbuild bot
---
 drivers/staging/media/atomisp/i2c/mt9m114.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/mt9m114.c 
b/drivers/staging/media/atomisp/i2c/mt9m114.c
index c4f4c888a59a..ced175c268d1 100644
--- a/drivers/staging/media/atomisp/i2c/mt9m114.c
+++ b/drivers/staging/media/atomisp/i2c/mt9m114.c
@@ -689,12 +689,13 @@ static struct mt9m114_res_struct *mt9m114_to_res(u32 w, 
u32 h)
return _res[index];
 }
 
-static int mt9m114_res2size(unsigned int res, int *h_size, int *v_size)
+static int mt9m114_res2size(struct v4l2_subdev *sd, int *h_size, int *v_size)
 {
+   struct mt9m114_device *dev = to_mt9m114_sensor(sd);
unsigned short hsize;
unsigned short vsize;
 
-   switch (res) {
+   switch (dev->res) {
case MT9M114_RES_736P:
hsize = MT9M114_RES_736P_SIZE_H;
vsize = MT9M114_RES_736P_SIZE_V;
@@ -708,7 +709,8 @@ static int mt9m114_res2size(unsigned int res, int *h_size, 
int *v_size)
vsize = MT9M114_RES_960P_SIZE_V;
break;
default:
-   WARN(1, "%s: Resolution 0x%08x unknown\n", __func__, res);
+   v4l2_err(sd, "%s: Resolution 0x%08x unknown\n", __func__,
+dev->res);
return -EINVAL;
}
 
@@ -812,15 +814,14 @@ static int mt9m114_get_fmt(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_format *format)
 {
-struct v4l2_mbus_framefmt *fmt = >format;
-   struct mt9m114_device *dev = to_mt9m114_sensor(sd);
+   struct v4l2_mbus_framefmt *fmt = >format;
int width, height;
int ret;
if (format->pad)
return -EINVAL;
fmt->code = MEDIA_BUS_FMT_SGRBG10_1X10;
 
-   ret = mt9m114_res2size(dev->res, , );
+   ret = mt9m114_res2size(sd, , );
if (ret)
return ret;
fmt->width = width;
@@ -1174,7 +1175,6 @@ static int mt9m114_s_exposure_selection(struct 
v4l2_subdev *sd,
struct v4l2_subdev_selection *sel)
 {
struct i2c_client *client = v4l2_get_subdevdata(sd);
-   struct mt9m114_device *dev = to_mt9m114_sensor(sd);
struct misensor_reg exp_reg;
int width, height;
int grid_width, grid_height;
@@ -1192,7 +1192,7 @@ static int mt9m114_s_exposure_selection(struct 
v4l2_subdev *sd,
grid_right = sel->r.left + sel->r.width - 1;
grid_bottom = sel->r.top + sel->r.height - 1;
 
-   ret = mt9m114_res2size(dev->res, , );
+   ret = mt9m114_res2size(sd, , );
if (ret)
return ret;
 
-- 
2.9.0

Re: [PATCH 1/3] [media] mceusb: RX -EPIPE (urb status = -32) lockup failure fix

[Sean Young]

On Tue, Mar 28, 2017 at 09:40:05PM -0400, A Sun wrote:
> On 3/28/2017 4:25 PM, Sean Young wrote:
> 
> >  
> >> The unused EVENT_TX_HALT and the apparently extra _kevent functions and 
> >> kevent_flags are necessary for a later:
> >> [PATCH] [media] mceusb: TX -EPIPE lockup fix
> >> ...not yet written, transmit side equivalent bug. I respectfully recommend 
> >> keeping these hooks in place.
> > 
> > Have you observed this happening?
> > 
> 
> Not yet for my Infrared Transceiver device only. USB halt/stall errors 
> apparently are not USB device specific, and can occur with both TX and RX 
> according to the Linux Urb errors documentation. Calling usb_clear_halt() is 
> required for both cases to recover and restore operation of the stalled 
> endpoint.

Yes, I did not realise this, but you're right, they can happen in both
cases.

> The TX -EPIPE error is already separated out by code in the mceusb driver, 
> but with no error recovery handling.
> In mce_async_callback()
> case -EPIPE:
> default:
> dev_err(ir->dev, "Error: request urb status = %d", 
> urb->status);
> break;
> }
> 
> I believe I can trigger the condition by stress test flooding or otherwise 
> misusing the device's TX end-point in the driver (like the RX case), but I 
> haven't put much work into that yet.

The problem in the rx case is that in the EPIPE error case, the urb simply
resubmitted from the urb callback. In the tx case this does not happen
so I wouldn't expect a flood. Also after initialisation, no commands are
sent to the mceusb device except for IR transmit or tx carrier.

> > Speaking of which, how do you reproduce the original -EPIPE issue? I've
> > tried to reproduce on my raspberry pi 3 with a very similar mceusb
> > device, but I haven't had any luck.
> > 
> 
> Reproduction of the RX -EPIPE is "hard" to get. I haven't found a consistent 
> way to reproduce, other than inconsistently by:
>Bug trigger appears to be normal, but heavy, IR receiver use.
> In particular, punch up a bunch of buttons at random on a remote control (I 
> used a Sony TV remote) and include some long button presses in the process. 
> Do for say about 1 minute at the time. The bug won't trigger for idle or 
> occasional IR receiver activity.
> Some mceusb devices may be more susceptible to the problem than others.
> 
> > What's the lsusb -vv for this device?
> 
> Here it is, on my raspberry pi 3:
> 
> ...
> Bus 001 Device 006: ID 2304:0225 Pinnacle Systems, Inc. Remote Kit Infrared 
> Transceiver
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   2.00
>   bDeviceClass0 (Defined at Interface level)
>   bDeviceSubClass 0
>   bDeviceProtocol 0
>   bMaxPacketSize0 8
>   idVendor   0x2304 Pinnacle Systems, Inc.
>   idProduct  0x0225 Remote Kit Infrared Transceiver
>   bcdDevice0.01
>   iManufacturer   1 Pinnacle Systems
>   iProduct2 PCTV Remote USB
>   iSerial 5 7FFF
>   bNumConfigurations  1
>   Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength   32
> bNumInterfaces  1
> bConfigurationValue 1
> iConfiguration  3 StandardConfiguration
> bmAttributes 0xa0
>   (Bus Powered)
>   Remote Wakeup
> MaxPower  100mA
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber0
>   bAlternateSetting   0
>   bNumEndpoints   2
>   bInterfaceClass   255 Vendor Specific Class
>   bInterfaceSubClass  0
>   bInterfaceProtocol  0
>   iInterface  4 StandardInterface
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81  EP 1 IN
> bmAttributes2
>   Transfer TypeBulk
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0040  1x 64 bytes
> bInterval  10
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02  EP 2 OUT
> bmAttributes2
>   Transfer TypeBulk
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0040  1x 64 bytes
> bInterval  10
> Device Status: 0x
>   (Bus Powered)
> ...
> 
> The most recent bug replication I got was while testing the fix methodology 
> for [patch 1/3]. The fault, when it occurs, is between IR data blocks during 
> receive.
> 
> ...
> Mar 22 12:16:35 raspberrypi kernel: [ 4863.489177] mceusb 1-1.2:1.0: rx data: 
> 90 7f 7f 7f 7f 7f 7f 7f 7f 7f 

Re: [PATCHv5 00/11] video/exynos/sti/cec: add CEC notifier & use in drivers

[Hans Verkuil]

Hi Daniel,

On 29/03/17 19:47, Daniel Vetter wrote:
> On Wed, Mar 29, 2017 at 04:15:32PM +0200, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> This patch series adds the CEC physical address notifier code, based on
>> Russell's code:
>>
>> https://patchwork.kernel.org/patch/9277043/
>>
>> It adds support for it to the exynos_hdmi drm driver, adds support for
>> it to the CEC framework and finally adds support to the s5p-cec driver,
>> which now can be moved out of staging.
>>
>> Also included is similar code for the STI platform, contributed by
>> Benjamin Gaignard.
>>
>> Tested the exynos code with my Odroid U3 exynos4 devboard.
>>
>> After discussions with Daniel Vetter and Russell King I have removed
>> the EDID/ELD/HPD connect/disconnect events from the notifier and now
>> just use it to report the CEC physical address. This also means that
>> it is now renamed to CEC notifier instead of HPD notifier and that
>> it is now in drivers/media. The block_notifier was dropped as well
>> and instead a simple callback is registered. This means that the
>> relationship between HDMI and CEC is now 1:1 and no longer 1:n, but
>> should this be needed in the future, then that can easily be added
>> back.
>>
>> Daniel, regarding your suggestions here:
>>
>> http://www.spinics.net/lists/dri-devel/msg133907.html
>>
>> this patch series maps to your mail above as follows:
>>
>> struct cec_pin == struct cec_notifier
>> cec_(un)register_pin == cec_notifier_get/put
>> cec_set_address == cec_notifier_set_phys_addr
>> cec_(un)register_callbacks == cec_notifier_(un)register
>>
>> Comments are welcome. I'd like to get this in for the 4.12 kernel as
>> this is a missing piece needed to integrate CEC drivers.
>>
>> Regards,
>>
>>  Hans
>>
>> Changes since v4:
>> - Dropped EDID/ELD/connect/disconnect support. Instead, just report the
>>   CEC physical address (and use INVALID when disconnecting).
>> - Since this is now completely CEC specific, move it to drivers/media
>>   and rename to cec-notifier.
>> - Drop block_notifier. Instead just set a callback for the notifier.
>> - Use 'hdmi-phandle' in the bindings for both exynos and sti. So no
>>   vendor prefix and 'hdmi-phandle' instead of 'hdmi-handle'.
>> - Make struct cec_notifier opaque. Add a helper function to get the
>>   physical address from a cec_notifier struct.
>> - Provide dummy functions in cec-notifier.h so it can be used when
>>   CONFIG_MEDIA_CEC_NOTIFIER is undefined.
>> - Don't select the CEC notifier in the HDMI drivers. It should only
>>   be enabled by actual CEC drivers.
> 
> I just quickly scaned through it, but this seems to address all my
> concerns fully. Thanks for respinning. On the entire pile (or just the
> core cec notifier bits):
> 
> Acked-by: Daniel Vetter 

Fantastic! Thank you very much for your comments.

One last question: the patches for drivers/gpu/drm: can they go through
the media subsystem or do you want to take them? They do depend on the first
two patches of this series (cec-edid and cec-notifier), so it is a bit more
coordination if they have to go through the drm subsystem.

Regards,

Hans

> 
>>
>> Changes since v3:
>> - Added the STI patches
>> - Split the exynos4 binding patches in one for documentation and one
>>   for the dts change itself, also use the correct subject and CC to
>>   the correct mailinglists (I hope  )
>>
>> Changes since v2:
>> - Split off the dts changes of the s5p-cec patch into a separate patch
>> - Renamed HPD_NOTIFIERS to HPD_NOTIFIER to be consistent with the name
>>   of the source.
>>
>> Changes since v1:
>>
>> Renamed HDMI notifier to HPD (hotplug detect) notifier since this code is
>> not HDMI specific, but is interesting for any video source that has to
>> deal with hotplug detect and EDID/ELD (HDMI, DVI, VGA, DP, ).
>> Only the use with CEC adapters is HDMI specific, but the HPD notifier
>> is more generic.
>>
>>
>>
>>
>> Benjamin Gaignard (4):
>>   sti: hdmi: add CEC notifier support
>>   stih-cec.txt: document new hdmi phandle
>>   stih-cec: add CEC notifier support
>>   arm: sti: update sti-cec for CEC notifier support
>>
>> Hans Verkuil (7):
>>   cec-edid: rename cec_get_edid_phys_addr
>>   media: add CEC notifier support
>>   cec: integrate CEC notifier support
>>   exynos_hdmi: add CEC notifier support
>>   ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi
>>   s5p-cec.txt: document the HDMI controller phandle
>>   s5p-cec: add cec-notifier support, move out of staging
>>
>>  .../devicetree/bindings/media/s5p-cec.txt  |   2 +
>>  .../devicetree/bindings/media/stih-cec.txt |   2 +
>>  MAINTAINERS|   4 +-
>>  arch/arm/boot/dts/exynos4.dtsi |   1 +
>>  arch/arm/boot/dts/stih407-family.dtsi  |  12 ---
>>  arch/arm/boot/dts/stih410.dtsi |  13 +++
>>  drivers/gpu/drm/exynos/exynos_hdmi.c   |  20 +++-
>> 

[PATCH 09/22] usb/callbacks.txt: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core functions. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../callbacks.txt => driver-api/usb/callbacks.rst} | 61 +++---
 Documentation/driver-api/usb/index.rst |  1 +
 2 files changed, 43 insertions(+), 19 deletions(-)
 rename Documentation/{usb/callbacks.txt => driver-api/usb/callbacks.rst} (78%)

diff --git a/Documentation/usb/callbacks.txt 
b/Documentation/driver-api/usb/callbacks.rst
similarity index 78%
rename from Documentation/usb/callbacks.txt
rename to Documentation/driver-api/usb/callbacks.rst
index 9e85846bdb98..93a8d53e27e7 100644
--- a/Documentation/usb/callbacks.txt
+++ b/Documentation/driver-api/usb/callbacks.rst
@@ -1,3 +1,6 @@
+USB core callbacks
+~~
+
 What callbacks will usbcore do?
 ===
 
@@ -11,30 +14,42 @@ The callbacks defined in the driver structure are:
 
 1. Hotplugging callbacks:
 
- * @probe: Called to see if the driver is willing to manage a particular
- * interface on a device.
- * @disconnect: Called when the interface is no longer accessible, usually
- * because its device has been (or is being) disconnected or the
- * driver module is being unloaded.
+ - @probe:
+   Called to see if the driver is willing to manage a particular
+   interface on a device.
+
+ - @disconnect:
+   Called when the interface is no longer accessible, usually
+   because its device has been (or is being) disconnected or the
+   driver module is being unloaded.
 
 2. Odd backdoor through usbfs:
 
- * @ioctl: Used for drivers that want to talk to userspace through
- * the "usbfs" filesystem.  This lets devices provide ways to
- * expose information to user space regardless of where they
- * do (or don't) show up otherwise in the filesystem.
+ - @ioctl:
+   Used for drivers that want to talk to userspace through
+   the "usbfs" filesystem.  This lets devices provide ways to
+   expose information to user space regardless of where they
+   do (or don't) show up otherwise in the filesystem.
 
 3. Power management (PM) callbacks:
 
- * @suspend: Called when the device is going to be suspended.
- * @resume: Called when the device is being resumed.
- * @reset_resume: Called when the suspended device has been reset instead
- * of being resumed.
+ - @suspend:
+   Called when the device is going to be suspended.
+
+ - @resume:
+   Called when the device is being resumed.
+
+ - @reset_resume:
+   Called when the suspended device has been reset instead
+   of being resumed.
 
 4. Device level operations:
 
- * @pre_reset: Called when the device is about to be reset.
- * @post_reset: Called after the device has been reset
+ - @pre_reset:
+   Called when the device is about to be reset.
+
+ - @post_reset:
+   Called after the device has been reset
 
 The ioctl interface (2) should be used only if you have a very good
 reason. Sysfs is preferred these days. The PM callbacks are covered
@@ -58,7 +73,9 @@ an interface. A driver's bond to an interface is exclusive.
 The probe() callback
 
 
-int (*probe) (struct usb_interface *intf,
+::
+
+  int (*probe) (struct usb_interface *intf,
const struct usb_device_id *id);
 
 Accept or decline an interface. If you accept the device return 0,
@@ -75,7 +92,9 @@ initialisation that doesn't take too long is a good idea here.
 The disconnect() callback
 -
 
-void (*disconnect) (struct usb_interface *intf);
+::
+
+  void (*disconnect) (struct usb_interface *intf);
 
 This callback is a signal to break any connection with an interface.
 You are not allowed any IO to a device after returning from this
@@ -93,7 +112,9 @@ Device level callbacks
 pre_reset
 -
 
-int (*pre_reset)(struct usb_interface *intf);
+::
+
+  int (*pre_reset)(struct usb_interface *intf);
 
 A driver or user space is triggering a reset on the device which
 contains the interface passed as an argument. Cease IO, wait for all
@@ -107,7 +128,9 @@ are in atomic context.
 post_reset
 --
 
-int (*post_reset)(struct usb_interface *intf);
+::
+
+  int (*post_reset)(struct usb_interface *intf);
 
 The reset has completed.  Restore any saved device state and begin
 using the device again.
diff --git a/Documentation/driver-api/usb/index.rst 
b/Documentation/driver-api/usb/index.rst
index 6fe7611f7332..441c5dacdf27 100644
--- a/Documentation/driver-api/usb/index.rst
+++ b/Documentation/driver-api/usb/index.rst
@@ -8,6 +8,7 @@ Linux USB API
gadget
anchors
bulk-streams
+   callbacks
writing_usb_driver
writing_musb_glue_layer
 
-- 
2.9.3

[PATCH 08/22] usb/bulk-streams.txt: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core functions. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../bulk-streams.txt => driver-api/usb/bulk-streams.rst}| 13 +
 Documentation/driver-api/usb/index.rst  |  1 +
 2 files changed, 10 insertions(+), 4 deletions(-)
 rename Documentation/{usb/bulk-streams.txt => driver-api/usb/bulk-streams.rst} 
(94%)

diff --git a/Documentation/usb/bulk-streams.txt 
b/Documentation/driver-api/usb/bulk-streams.rst
similarity index 94%
rename from Documentation/usb/bulk-streams.txt
rename to Documentation/driver-api/usb/bulk-streams.rst
index ffc02021863e..99b515babdeb 100644
--- a/Documentation/usb/bulk-streams.txt
+++ b/Documentation/driver-api/usb/bulk-streams.rst
@@ -1,3 +1,6 @@
+USB bulk streams
+
+
 Background
 ==
 
@@ -25,7 +28,9 @@ time.
 Driver implications
 ===
 
-int usb_alloc_streams(struct usb_interface *interface,
+::
+
+  int usb_alloc_streams(struct usb_interface *interface,
struct usb_host_endpoint **eps, unsigned int num_eps,
unsigned int num_streams, gfp_t mem_flags);
 
@@ -53,7 +58,7 @@ controller driver, and may change in the future.
 
 
 Picking new Stream IDs to use
-
+=
 
 Stream ID 0 is reserved, and should not be used to communicate with devices.  
If
 usb_alloc_streams() returns with a value of N, you may use streams 1 though N.
@@ -68,9 +73,9 @@ Clean up
 
 
 If a driver wishes to stop using streams to communicate with the device, it
-should call
+should call::
 
-void usb_free_streams(struct usb_interface *interface,
+  void usb_free_streams(struct usb_interface *interface,
struct usb_host_endpoint **eps, unsigned int num_eps,
gfp_t mem_flags);
 
diff --git a/Documentation/driver-api/usb/index.rst 
b/Documentation/driver-api/usb/index.rst
index 5dfb04b2d730..6fe7611f7332 100644
--- a/Documentation/driver-api/usb/index.rst
+++ b/Documentation/driver-api/usb/index.rst
@@ -7,6 +7,7 @@ Linux USB API
usb
gadget
anchors
+   bulk-streams
writing_usb_driver
writing_musb_glue_layer
 
-- 
2.9.3

[PATCH 10/22] usb/power-management.txt: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core functions. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/usb/index.rst |   1 +
 .../usb/power-management.rst}  | 403 +++--
 2 files changed, 214 insertions(+), 190 deletions(-)
 rename Documentation/{usb/power-management.txt => 
driver-api/usb/power-management.rst} (69%)

diff --git a/Documentation/driver-api/usb/index.rst 
b/Documentation/driver-api/usb/index.rst
index 441c5dacdf27..23c76c17fc19 100644
--- a/Documentation/driver-api/usb/index.rst
+++ b/Documentation/driver-api/usb/index.rst
@@ -9,6 +9,7 @@ Linux USB API
anchors
bulk-streams
callbacks
+   power-management
writing_usb_driver
writing_musb_glue_layer
 
diff --git a/Documentation/usb/power-management.txt 
b/Documentation/driver-api/usb/power-management.rst
similarity index 69%
rename from Documentation/usb/power-management.txt
rename to Documentation/driver-api/usb/power-management.rst
index 00e706997130..7c547d6b8372 100644
--- a/Documentation/usb/power-management.txt
+++ b/Documentation/driver-api/usb/power-management.rst
@@ -1,10 +1,13 @@
-   Power Management for USB
+.. _usb-power-management:
 
-Alan Stern 
+Power Management for USB
+
 
-  Last-updated: February 2014
+Alan Stern 
 
+Last-updated: February 2014
 
+..
Contents:
-
* What is Power Management?
@@ -25,14 +28,14 @@
* Suggested Userspace Port Power Policy
 
 
-   What is Power Management?
-   -
+What is Power Management?
+-
 
 Power Management (PM) is the practice of saving energy by suspending
 parts of a computer system when they aren't being used.  While a
-component is "suspended" it is in a nonfunctional low-power state; it
+component is ``suspended`` it is in a nonfunctional low-power state; it
 might even be turned off completely.  A suspended component can be
-"resumed" (returned to a functional full-power state) when the kernel
+``resumed`` (returned to a functional full-power state) when the kernel
 needs to use it.  (There also are forms of PM in which components are
 placed in a less functional but still usable state instead of being
 suspended; an example would be reducing the CPU's clock rate.  This
@@ -44,22 +47,25 @@ device is turned off while the system as a whole remains 
running, we
 call it a "dynamic suspend" (also known as a "runtime suspend" or
 "selective suspend").  This document concentrates mostly on how
 dynamic PM is implemented in the USB subsystem, although system PM is
-covered to some extent (see Documentation/power/*.txt for more
+covered to some extent (see ``Documentation/power/*.txt`` for more
 information about system PM).
 
-System PM support is present only if the kernel was built with CONFIG_SUSPEND
-or CONFIG_HIBERNATION enabled.  Dynamic PM support for USB is present whenever
-the kernel was built with CONFIG_PM enabled.
+System PM support is present only if the kernel was built with
+``CONFIG_SUSPEND`` or ``CONFIG_HIBERNATION`` enabled.  Dynamic PM support
+
+for USB is present whenever
+the kernel was built with ``CONFIG_PM`` enabled.
 
 [Historically, dynamic PM support for USB was present only if the
-kernel had been built with CONFIG_USB_SUSPEND enabled (which depended on
-CONFIG_PM_RUNTIME).  Starting with the 3.10 kernel release, dynamic PM support
-for USB was present whenever the kernel was built with CONFIG_PM_RUNTIME
-enabled.  The CONFIG_USB_SUSPEND option had been eliminated.]
+kernel had been built with ``CONFIG_USB_SUSPEND`` enabled (which depended on
+``CONFIG_PM_RUNTIME``).  Starting with the 3.10 kernel release, dynamic PM
+support for USB was present whenever the kernel was built with
+``CONFIG_PM_RUNTIME`` enabled.  The ``CONFIG_USB_SUSPEND`` option had been
+eliminated.]
 
 
-   What is Remote Wakeup?
-   --
+What is Remote Wakeup?
+--
 
 When a device has been suspended, it generally doesn't resume until
 the computer tells it to.  Likewise, if the entire computer has been
@@ -76,8 +82,8 @@ event.  Examples include a suspended keyboard resuming when a 
key is
 pressed, or a suspended USB hub resuming when a device is plugged in.
 
 
-   When is a USB device idle?
-   --
+When is a USB device idle?
+--
 
 A device is idle whenever the kernel thinks it's not busy doing
 anything important and thus is a candidate for being suspended.  The
@@ -92,11 +98,11 @@ If a USB device has no driver, its usbfs file isn't open, 
and it isn't
 being accessed through sysfs, then it definitely is idle.
 
 
-   Forms of dynamic PM
-   ---
+Forms of dynamic PM
+---
 
 Dynamic suspends 

[PATCH 01/22] driver-api/basics.rst: add device table header

[Mauro Carvalho Chehab]

The structs there at device table are used by other documentation
at the Kernel. So, add it to the driver API.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/basics.rst | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/driver-api/basics.rst 
b/Documentation/driver-api/basics.rst
index 935b9b8d456c..472e7a664d13 100644
--- a/Documentation/driver-api/basics.rst
+++ b/Documentation/driver-api/basics.rst
@@ -7,6 +7,12 @@ Driver Entry and Exit points
 .. kernel-doc:: include/linux/init.h
:internal:
 
+Driver device table
+---
+
+.. kernel-doc:: include/linux/mod_devicetable.h
+   :internal:
+
 Atomic and pointer manipulation
 ---
 
-- 
2.9.3

[PATCH 19/22] usb: composite.h: fix two warnings when building docs

[Mauro Carvalho Chehab]

By definition, we use /* private: */ tag when we won't be documenting
a parameter. However, those two parameters are documented:

./include/linux/usb/composite.h:510: warning: Excess struct/union/enum/typedef 
member 'setup_pending' description in 'usb_composite_dev'
./include/linux/usb/composite.h:510: warning: Excess struct/union/enum/typedef 
member 'os_desc_pending' description in 'usb_composite_dev'

So, we need to use /* public: */ to avoid a warning.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/linux/usb/composite.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 30a063e98c19..f665d2ceac20 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -504,8 +504,9 @@ struct usb_composite_dev {
/* protects deactivations and delayed_status counts*/
spinlock_t  lock;
 
-   unsignedsetup_pending:1;
-   unsignedos_desc_pending:1;
+   /* public: */
+   unsigned intsetup_pending:1;
+   unsigned intos_desc_pending:1;
 };
 
 extern int usb_string_id(struct usb_composite_dev *c);
-- 
2.9.3

[PATCH 05/22] writing_usb_driver.rst: Enrich its ReST representation

[Mauro Carvalho Chehab]

The pandoc conversion is not perfect. Do handwork in order to:

- add a title to this chapter;
- adjust function and struct references;
- use monospaced fonts for C code names;
- some other minor adjustments to make it better to read in
  text mode and in html.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../driver-api/usb/writing_usb_driver.rst  | 97 +-
 1 file changed, 41 insertions(+), 56 deletions(-)

diff --git a/Documentation/driver-api/usb/writing_usb_driver.rst 
b/Documentation/driver-api/usb/writing_usb_driver.rst
index 48f2fdb4745b..180859f664db 100644
--- a/Documentation/driver-api/usb/writing_usb_driver.rst
+++ b/Documentation/driver-api/usb/writing_usb_driver.rst
@@ -1,3 +1,8 @@
+.. _writing-usb-driver:
+
+Writing USB drivers
+~~~
+
 Introduction
 
 
@@ -42,10 +47,8 @@ The first thing a Linux USB driver needs to do is register 
itself with
 the Linux USB subsystem, giving it some information about which devices
 the driver supports and which functions to call when a device supported
 by the driver is inserted or removed from the system. All of this
-information is passed to the USB subsystem in the usb\_driver structure.
-The skeleton driver declares a usb\_driver as:
-
-::
+information is passed to the USB subsystem in the :c:type:`usb_driver`
+structure. The skeleton driver declares a :c:type:`usb_driver` as::
 
 static struct usb_driver skel_driver = {
.name= "skeleton",
@@ -60,7 +63,7 @@ The skeleton driver declares a usb\_driver as:
 The variable name is a string that describes the driver. It is used in
 informational messages printed to the system log. The probe and
 disconnect function pointers are called when a device that matches the
-information provided in the id\_table variable is either seen or
+information provided in the ``id_table`` variable is either seen or
 removed.
 
 The fops and minor variables are optional. Most USB drivers hook into
@@ -70,15 +73,13 @@ subsystem, and any user-space interactions are provided 
through that
 interface. But for drivers that do not have a matching kernel subsystem,
 such as MP3 players or scanners, a method of interacting with user space
 is needed. The USB subsystem provides a way to register a minor device
-number and a set of file\_operations function pointers that enable this
-user-space interaction. The skeleton driver needs this kind of
+number and a set of :c:type:`file_operations` function pointers that enable
+this user-space interaction. The skeleton driver needs this kind of
 interface, so it provides a minor starting number and a pointer to its
-file\_operations functions.
+:c:type:`file_operations` functions.
 
-The USB driver is then registered with a call to usb\_register, usually
-in the driver's init function, as shown here:
-
-::
+The USB driver is then registered with a call to :c:func:`usb_register`,
+usually in the driver's init function, as shown here::
 
 static int __init usb_skel_init(void)
 {
@@ -98,10 +99,8 @@ in the driver's init function, as shown here:
 
 
 When the driver is unloaded from the system, it needs to deregister
-itself with the USB subsystem. This is done with the usb\_deregister
-function:
-
-::
+itself with the USB subsystem. This is done with the :c:func:`usb_deregister`
+function::
 
 static void __exit usb_skel_exit(void)
 {
@@ -112,11 +111,9 @@ function:
 
 
 To enable the linux-hotplug system to load the driver automatically when
-the device is plugged in, you need to create a MODULE\_DEVICE\_TABLE.
+the device is plugged in, you need to create a ``MODULE_DEVICE_TABLE``.
 The following code tells the hotplug scripts that this module supports a
-single device with a specific vendor and product ID:
-
-::
+single device with a specific vendor and product ID::
 
 /* table of devices that work with this driver */
 static struct usb_device_id skel_table [] = {
@@ -126,19 +123,17 @@ single device with a specific vendor and product ID:
 MODULE_DEVICE_TABLE (usb, skel_table);
 
 
-There are other macros that can be used in describing a usb\_device\_id
-for drivers that support a whole class of USB drivers. See usb.h for
-more information on this.
+There are other macros that can be used in describing a struct
+:c:type:`usb_device_id` for drivers that support a whole class of USB
+drivers. See :ref:`usb.h ` for more information on this.
 
 Device operation
 
 
 When a device is plugged into the USB bus that matches the device ID
 pattern that your driver registered with the USB core, the probe
-function is called. The usb\_device structure, interface number and the
-interface ID are passed to the function:
-
-::
+function is called. The :c:type:`usb_device` structure, interface number and
+the interface ID are passed to the function::
 
 static int skel_probe(struct usb_interface *interface,
const struct usb_device_id *id)
@@ -160,16 +155,14 

[PATCH 21/22] docs-rst: fix usb cross-references

[Mauro Carvalho Chehab]

As some USB documentation files got moved, adjust their
cross-references to their new place.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/ABI/stable/sysfs-bus-usb| 2 +-
 Documentation/driver-api/usb/URB.rst  | 2 ++
 Documentation/driver-api/usb/callbacks.rst| 4 ++--
 Documentation/driver-api/usb/error-codes.rst  | 2 ++
 Documentation/driver-api/usb/persist.rst  | 2 ++
 Documentation/driver-api/usb/power-management.rst | 2 +-
 Documentation/driver-api/usb/usb.rst  | 4 ++--
 Documentation/power/swsusp.txt| 2 +-
 drivers/staging/most/hdm-usb/hdm_usb.c| 2 +-
 drivers/usb/core/Kconfig  | 2 +-
 10 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/Documentation/ABI/stable/sysfs-bus-usb 
b/Documentation/ABI/stable/sysfs-bus-usb
index 831f15d9672f..b832eeff 100644
--- a/Documentation/ABI/stable/sysfs-bus-usb
+++ b/Documentation/ABI/stable/sysfs-bus-usb
@@ -9,7 +9,7 @@ Description:
hubs this facility is always enabled and their device
directories will not contain this file.
 
-   For more information, see Documentation/usb/persist.txt.
+   For more information, see 
Documentation/driver-api/usb/persist.rst.
 
 What:  /sys/bus/usb/devices/.../power/autosuspend
 Date:  March 2007
diff --git a/Documentation/driver-api/usb/URB.rst 
b/Documentation/driver-api/usb/URB.rst
index c5d2b68b4dae..d9ea6a3996e7 100644
--- a/Documentation/driver-api/usb/URB.rst
+++ b/Documentation/driver-api/usb/URB.rst
@@ -1,3 +1,5 @@
+.. _usb-urb:
+
 USB Request Block (URB)
 ~~~
 
diff --git a/Documentation/driver-api/usb/callbacks.rst 
b/Documentation/driver-api/usb/callbacks.rst
index 93a8d53e27e7..2b80cf54bcc3 100644
--- a/Documentation/driver-api/usb/callbacks.rst
+++ b/Documentation/driver-api/usb/callbacks.rst
@@ -8,7 +8,7 @@ Usbcore will call into a driver through callbacks defined in 
the driver
 structure and through the completion handler of URBs a driver submits.
 Only the former are in the scope of this document. These two kinds of
 callbacks are completely independent of each other. Information on the
-completion callback can be found in Documentation/usb/URB.txt.
+completion callback can be found in :ref:`usb-urb`.
 
 The callbacks defined in the driver structure are:
 
@@ -53,7 +53,7 @@ The callbacks defined in the driver structure are:
 
 The ioctl interface (2) should be used only if you have a very good
 reason. Sysfs is preferred these days. The PM callbacks are covered
-separately in Documentation/usb/power-management.txt.
+separately in :ref:`usb-power-management`.
 
 Calling conventions
 ===
diff --git a/Documentation/driver-api/usb/error-codes.rst 
b/Documentation/driver-api/usb/error-codes.rst
index 715cc35b29b0..5bc5eda58520 100644
--- a/Documentation/driver-api/usb/error-codes.rst
+++ b/Documentation/driver-api/usb/error-codes.rst
@@ -1,3 +1,5 @@
+.. _usb-error-codes:
+
 USB Error codes
 ~~~
 
diff --git a/Documentation/driver-api/usb/persist.rst 
b/Documentation/driver-api/usb/persist.rst
index af02baf61f57..8ee2a62d889b 100644
--- a/Documentation/driver-api/usb/persist.rst
+++ b/Documentation/driver-api/usb/persist.rst
@@ -1,3 +1,5 @@
+.. _usb-persist:
+
 USB device persistence during system suspend
 
 
diff --git a/Documentation/driver-api/usb/power-management.rst 
b/Documentation/driver-api/usb/power-management.rst
index 7c547d6b8372..3e4ebbf47b76 100644
--- a/Documentation/driver-api/usb/power-management.rst
+++ b/Documentation/driver-api/usb/power-management.rst
@@ -329,7 +329,7 @@ possible to work around the hibernation-forces-disconnect 
problem by
 using the USB Persist facility.)
 
 The ``reset_resume`` method is used by the USB Persist facility (see
-``Documentation/usb/persist.txt``) and it can also be used under certain
+:ref:`usb-persist`) and it can also be used under certain
 circumstances when ``CONFIG_USB_PERSIST`` is not enabled.  Currently, if a
 device is reset during a resume and the driver does not have a
 ``reset_resume`` method, the driver won't receive any notification about
diff --git a/Documentation/driver-api/usb/usb.rst 
b/Documentation/driver-api/usb/usb.rst
index 5ebaf669704c..6824089ef4c8 100644
--- a/Documentation/driver-api/usb/usb.rst
+++ b/Documentation/driver-api/usb/usb.rst
@@ -424,8 +424,8 @@ header.
 Unless noted otherwise, the ioctl requests described here will update
 the modification time on the usbfs file to which they are applied
 (unless they fail). A return of zero indicates success; otherwise, a
-standard USB error code is returned. (These are documented in
-``Documentation/usb/error-codes.txt`` in your kernel sources.)
+standard USB error code is returned (These are documented in
+:ref:`usb-error-codes`).
 
 Each of these files multiplexes 

[PATCH 16/22] usb/gadget.rst: remove unused kernel-doc tags

[Mauro Carvalho Chehab]

The DocBook file used to have "!E" include tags for usb gadget functions.
However, there's nothing there to be documented:

./drivers/usb/gadget/function/f_acm.c:1: warning: no structured 
comments found
./drivers/usb/gadget/function/f_ecm.c:1: warning: no structured 
comments found
./drivers/usb/gadget/function/f_subset.c:1: warning: no structured 
comments found
./drivers/usb/gadget/function/f_obex.c:1: warning: no structured 
comments found
./drivers/usb/gadget/function/f_serial.c:1: warning: no structured 
comments found

So, let's remove it. If someone wants do document the function
there, they may just revert this patch in the future.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/usb/gadget.rst | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/Documentation/driver-api/usb/gadget.rst 
b/Documentation/driver-api/usb/gadget.rst
index c4c76ebb51d3..0488b89de21c 100644
--- a/Documentation/driver-api/usb/gadget.rst
+++ b/Documentation/driver-api/usb/gadget.rst
@@ -356,21 +356,6 @@ At this writing, a few of the current gadget drivers have 
been converted
 to this framework. Near-term plans include converting all of them,
 except for "gadgetfs".
 
-.. kernel-doc:: drivers/usb/gadget/function/f_acm.c
-   :export:
-
-.. kernel-doc:: drivers/usb/gadget/function/f_ecm.c
-   :export:
-
-.. kernel-doc:: drivers/usb/gadget/function/f_subset.c
-   :export:
-
-.. kernel-doc:: drivers/usb/gadget/function/f_obex.c
-   :export:
-
-.. kernel-doc:: drivers/usb/gadget/function/f_serial.c
-   :export:
-
 Peripheral Controller Drivers
 =
 
-- 
2.9.3

[PATCH 13/22] usb/hotplug.txt: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core features. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../hotplug.txt => driver-api/usb/hotplug.rst} | 66 --
 Documentation/driver-api/usb/index.rst |  1 +
 2 files changed, 37 insertions(+), 30 deletions(-)
 rename Documentation/{usb/hotplug.txt => driver-api/usb/hotplug.rst} (76%)

diff --git a/Documentation/usb/hotplug.txt 
b/Documentation/driver-api/usb/hotplug.rst
similarity index 76%
rename from Documentation/usb/hotplug.txt
rename to Documentation/driver-api/usb/hotplug.rst
index 5b243f315b2c..79663e653ca1 100644
--- a/Documentation/usb/hotplug.txt
+++ b/Documentation/driver-api/usb/hotplug.rst
@@ -1,4 +1,9 @@
-LINUX HOTPLUGGING
+USB hotplugging
+~~~
+
+Linux Hotplugging
+=
+
 
 In hotpluggable busses like USB (and Cardbus PCI), end-users plug devices
 into the bus with power on.  In most cases, users expect the devices to become
@@ -30,11 +35,11 @@ Because some of those actions rely on information about 
drivers (metadata)
 that is currently available only when the drivers are dynamically linked,
 you get the best hotplugging when you configure a highly modular system.
 
+Kernel Hotplug Helper (``/sbin/hotplug``)
+=
 
-KERNEL HOTPLUG HELPER (/sbin/hotplug)
-
-There is a kernel parameter: /proc/sys/kernel/hotplug, which normally
-holds the pathname "/sbin/hotplug".  That parameter names a program
+There is a kernel parameter: ``/proc/sys/kernel/hotplug``, which normally
+holds the pathname ``/sbin/hotplug``.  That parameter names a program
 which the kernel may invoke at various times.
 
 The /sbin/hotplug program can be invoked by any subsystem as part of its
@@ -51,26 +56,26 @@ Hotplug software and other resources is available at:
 Mailing list information is also available at that site.
 
 
---
+USB Policy Agent
+
 
-
-USB POLICY AGENT
-
-The USB subsystem currently invokes /sbin/hotplug when USB devices
+The USB subsystem currently invokes ``/sbin/hotplug`` when USB devices
 are added or removed from system.  The invocation is done by the kernel
 hub workqueue [hub_wq], or else as part of root hub initialization
 (done by init, modprobe, kapmd, etc).  Its single command line parameter
 is the string "usb", and it passes these environment variables:
 
-ACTION ... "add", "remove"
-PRODUCT ... USB vendor, product, and version codes (hex)
-TYPE ... device class codes (decimal)
-INTERFACE ... interface 0 class codes (decimal)
+== 
+ACTION ``add``, ``remove``
+PRODUCTUSB vendor, product, and version codes (hex)
+TYPE   device class codes (decimal)
+INTERFACE  interface 0 class codes (decimal)
+== 
 
 If "usbdevfs" is configured, DEVICE and DEVFS are also passed.  DEVICE is
 the pathname of the device, and is useful for devices with multiple and/or
 alternate interfaces that complicate driver selection.  By design, USB
-hotplugging is independent of "usbdevfs":  you can do most essential parts
+hotplugging is independent of ``usbdevfs``:  you can do most essential parts
 of USB device setup without using that filesystem, and without running a
 user mode daemon to detect changes in system configuration.
 
@@ -79,19 +84,20 @@ modules, and can invoke driver-specific setup scripts.  The 
newest ones
 leverage USB module-init-tools support.  Later agents might unload drivers.
 
 
-USB MODUTILS SUPPORT
+USB Modutils Support
+
 
-Current versions of module-init-tools will create a "modules.usbmap" file
-which contains the entries from each driver's MODULE_DEVICE_TABLE.  Such
+Current versions of module-init-tools will create a ``modules.usbmap`` file
+which contains the entries from each driver's ``MODULE_DEVICE_TABLE``.  Such
 files can be used by various user mode policy agents to make sure all the
 right driver modules get loaded, either at boot time or later.
 
-See  for full information about such table entries; or look
+See ``linux/usb.h`` for full information about such table entries; or look
 at existing drivers.  Each table entry describes one or more criteria to
 be used when matching a driver to a device or class of devices.  The
 specific criteria are identified by bits set in "match_flags", paired
 with field values.  You can construct the criteria directly, or with
-macros such as these, and use driver_info to store more information.
+macros such as these, and use driver_info to store more information::
 
 USB_DEVICE (vendorId, productId)
... matching devices with specified vendor and product ids
@@ -103,7 +109,7 @@ macros such as these, and use driver_info to store more 
information.
... matching specified device class info
 
 A short example, 

[PATCH 11/22] usb/dma.txt: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core features. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../{usb/dma.txt => driver-api/usb/dma.rst}| 51 --
 Documentation/driver-api/usb/index.rst |  1 +
 2 files changed, 28 insertions(+), 24 deletions(-)
 rename Documentation/{usb/dma.txt => driver-api/usb/dma.rst} (79%)

diff --git a/Documentation/usb/dma.txt b/Documentation/driver-api/usb/dma.rst
similarity index 79%
rename from Documentation/usb/dma.txt
rename to Documentation/driver-api/usb/dma.rst
index 444651e70d95..59d5aee89e37 100644
--- a/Documentation/usb/dma.txt
+++ b/Documentation/driver-api/usb/dma.rst
@@ -1,16 +1,19 @@
+USB DMA
+~~~
+
 In Linux 2.5 kernels (and later), USB device drivers have additional control
 over how DMA may be used to perform I/O operations.  The APIs are detailed
 in the kernel usb programming guide (kerneldoc, from the source code).
 
-
-API OVERVIEW
+API overview
+
 
 The big picture is that USB drivers can continue to ignore most DMA issues,
 though they still must provide DMA-ready buffers (see
-Documentation/DMA-API-HOWTO.txt).  That's how they've worked through
-the 2.4 (and earlier) kernels.
+``Documentation/DMA-API-HOWTO.txt``).  That's how they've worked through
+the 2.4 (and earlier) kernels, or they can now be DMA-aware.
 
-OR:  they can now be DMA-aware.
+DMA-aware usb drivers:
 
 - New calls enable DMA-aware drivers, letting them allocate dma buffers and
   manage dma mappings for existing dma-ready buffers (see below).
@@ -20,15 +23,15 @@ OR:  they can now be DMA-aware.
   drivers must not use it.)
 
 - "usbcore" will map this DMA address, if a DMA-aware driver didn't do
-  it first and set URB_NO_TRANSFER_DMA_MAP.  HCDs
+  it first and set ``URB_NO_TRANSFER_DMA_MAP``.  HCDs
   don't manage dma mappings for URBs.
 
 - There's a new "generic DMA API", parts of which are usable by USB device
   drivers.  Never use dma_set_mask() on any USB interface or device; that
   would potentially break all devices sharing that bus.
 
-
-ELIMINATING COPIES
+Eliminating copies
+==
 
 It's good to avoid making CPUs copy data needlessly.  The costs can add up,
 and effects like cache-trashing can impose subtle penalties.
@@ -41,7 +44,7 @@ and effects like cache-trashing can impose subtle penalties.
   For those specific cases, USB has primitives to allocate less expensive
   memory.  They work like kmalloc and kfree versions that give you the right
   kind of addresses to store in urb->transfer_buffer and urb->transfer_dma.
-  You'd also set URB_NO_TRANSFER_DMA_MAP in urb->transfer_flags:
+  You'd also set ``URB_NO_TRANSFER_DMA_MAP`` in urb->transfer_flags::
 
void *usb_alloc_coherent (struct usb_device *dev, size_t size,
int mem_flags, dma_addr_t *dma);
@@ -49,15 +52,15 @@ and effects like cache-trashing can impose subtle penalties.
void usb_free_coherent (struct usb_device *dev, size_t size,
void *addr, dma_addr_t dma);
 
-  Most drivers should *NOT* be using these primitives; they don't need
+  Most drivers should **NOT** be using these primitives; they don't need
   to use this type of memory ("dma-coherent"), and memory returned from
-  kmalloc() will work just fine.
+  :c:func:`kmalloc` will work just fine.
 
   The memory buffer returned is "dma-coherent"; sometimes you might need to
   force a consistent memory access ordering by using memory barriers.  It's
   not using a streaming DMA mapping, so it's good for small transfers on
   systems where the I/O would otherwise thrash an IOMMU mapping.  (See
-  Documentation/DMA-API-HOWTO.txt for definitions of "coherent" and
+  ``Documentation/DMA-API-HOWTO.txt`` for definitions of "coherent" and
   "streaming" DMA mappings.)
 
   Asking for 1/Nth of a page (as well as asking for N pages) is reasonably
@@ -75,15 +78,15 @@ and effects like cache-trashing can impose subtle penalties.
   way to expose these capabilities ... and in any case, HIGHMEM is mostly a
   design wart specific to x86_32.  So your best bet is to ensure you never
   pass a highmem buffer into a USB driver.  That's easy; it's the default
-  behavior.  Just don't override it; e.g. with NETIF_F_HIGHDMA.
+  behavior.  Just don't override it; e.g. with ``NETIF_F_HIGHDMA``.
 
   This may force your callers to do some bounce buffering, copying from
   high memory to "normal" DMA memory.  If you can come up with a good way
   to fix this issue (for x86_32 machines with over 1 GByte of memory),
   feel free to submit patches.
 
-
-WORKING WITH EXISTING BUFFERS
+Working with existing buffers
+=
 
 Existing buffers aren't usable for DMA without first being mapped into the
 DMA address space of the device.  However, most buffers passed to your
@@ -92,7 +95,7 @@ of Documentation/DMA-API-HOWTO.txt, titled "What memory is 
DMA-able?")
 
 - When you're using scatterlists, you can 

[PATCH 04/22] gadget.rst: Enrich its ReST representation and add kernel-doc tag

[Mauro Carvalho Chehab]

The pandoc conversion is not perfect. Do handwork in order to:

- add a title to this chapter;
- use the proper warning and note markups;
- use kernel-doc to include Kernel header and c files;
- remove legacy notes with regards to DocBook;
- some other minor adjustments to make it better to read in
  text mode and in html.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/usb/gadget.rst | 69 +
 1 file changed, 45 insertions(+), 24 deletions(-)

diff --git a/Documentation/driver-api/usb/gadget.rst 
b/Documentation/driver-api/usb/gadget.rst
index 4fd9862f3f21..c4c76ebb51d3 100644
--- a/Documentation/driver-api/usb/gadget.rst
+++ b/Documentation/driver-api/usb/gadget.rst
@@ -1,3 +1,7 @@
+Linux-USB "Gadget" kernel mode API
+~~
+
+
 Introduction
 
 
@@ -175,16 +179,12 @@ the gadget, and submitting one or more *struct 
usb\_request* buffers to
 transfer data. Understand those four data types, and their operations,
 and you will understand how this API works.
 
-**Note**
+.. Note::
 
-This documentation was prepared using the standard Linux kernel
-``docproc`` tool, which turns text and in-code comments into SGML
-DocBook and then into usable formats such as HTML or PDF. Other than
-the "Chapter 9" data types, most of the significant data types and
-functions are described here.
+Other than the "Chapter 9" data types, most of the significant data
+types and functions are described here.
 
-However, docproc does not understand all the C constructs that are
-used, so some relevant information is likely omitted from what you
+However, some relevant information is likely omitted from what you
 are reading. One example of such information is endpoint
 autoconfiguration. You'll have to read the header file, and use
 example source code (such as that for "Gadget Zero"), to fully
@@ -192,10 +192,10 @@ and you will understand how this API works.
 
 The part of the API implementing some basic driver capabilities is
 specific to the version of the Linux kernel that's in use. The 2.6
-kernel includes a *driver model* framework that has no analogue on
-earlier kernels; so those parts of the gadget API are not fully
-portable. (They are implemented on 2.4 kernels, but in a different
-way.) The driver model state is another part of this API that is
+and upper kernel versions include a *driver model* framework that has
+no analogue on earlier kernels; so those parts of the gadget API are
+not fully portable. (They are implemented on 2.4 kernels, but in a
+different way.) The driver model state is another part of this API that is
 ignored by the kerneldoc tools.
 
 The core API does not expose every possible hardware feature, only the
@@ -301,18 +301,19 @@ USB 2.0 Chapter 9 Types and Constants
 -
 
 Gadget drivers rely on common USB structures and constants defined in
-the  header file, which is standard in Linux 2.6
-kernels. These are the same types and constants used by host side
+the :ref:`linux/usb/ch9.h ` header file, which is standard in
+Linux 2.6+ kernels. These are the same types and constants used by host side
 drivers (and usbcore).
 
-!Iinclude/linux/usb/ch9.h
 Core Objects and Methods
 
 
 These are declared in , and are used by gadget
 drivers to interact with USB peripheral controller drivers.
 
-!Iinclude/linux/usb/gadget.h
+.. kernel-doc:: include/linux/usb/gadget.h
+   :internal:
+
 Optional Utilities
 --
 
@@ -320,7 +321,12 @@ The core API is sufficient for writing a USB Gadget 
Driver, but some
 optional utilities are provided to simplify common tasks. These
 utilities include endpoint autoconfiguration.
 
-!Edrivers/usb/gadget/usbstring.c !Edrivers/usb/gadget/config.c
+.. kernel-doc:: drivers/usb/gadget/usbstring.c
+   :export:
+
+.. kernel-doc:: drivers/usb/gadget/config.c
+   :export:
+
 Composite Device Framework
 --
 
@@ -337,7 +343,12 @@ usb\_function*, which packages a user visible role such as 
"network
 link" or "mass storage device". Management functions may also exist,
 such as "Device Firmware Upgrade".
 
-!Iinclude/linux/usb/composite.h !Edrivers/usb/gadget/composite.c
+.. kernel-doc:: include/linux/usb/composite.h
+   :internal:
+
+.. kernel-doc:: drivers/usb/gadget/composite.c
+   :export:
+
 Composite Device Functions
 --
 
@@ -345,11 +356,21 @@ At this writing, a few of the current gadget drivers have 
been converted
 to this framework. Near-term plans include converting all of them,
 except for "gadgetfs".
 
-!Edrivers/usb/gadget/function/f\_acm.c
-!Edrivers/usb/gadget/function/f\_ecm.c
-!Edrivers/usb/gadget/function/f\_subset.c
-!Edrivers/usb/gadget/function/f\_obex.c
-!Edrivers/usb/gadget/function/f\_serial.c
+.. kernel-doc:: 

[PATCH 15/22] usb/URB.txt: convert to ReST and update it

[Mauro Carvalho Chehab]

The URB doc describes the Kernel mechanism that do USB transfers.
While the functions are already described at urb.h, there are a
number of concepts and theory that are important for USB driver
developers.

Convert it to ReST and use C ref links to point to the places
at usb.h where each function and struct is located.

A few of those descriptions were incomplete. While here, update
to reflect the current API status.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../{usb/URB.txt => driver-api/usb/URB.rst}| 204 -
 Documentation/driver-api/usb/index.rst |   1 +
 Documentation/driver-api/usb/usb.rst   |   2 +
 3 files changed, 120 insertions(+), 87 deletions(-)
 rename Documentation/{usb/URB.txt => driver-api/usb/URB.rst} (52%)

diff --git a/Documentation/usb/URB.txt b/Documentation/driver-api/usb/URB.rst
similarity index 52%
rename from Documentation/usb/URB.txt
rename to Documentation/driver-api/usb/URB.rst
index 50da0d455444..c5d2b68b4dae 100644
--- a/Documentation/usb/URB.txt
+++ b/Documentation/driver-api/usb/URB.rst
@@ -1,16 +1,25 @@
-Revised: 2000-Dec-05.
+USB Request Block (URB)
+~~~
+
+Revised: 2000-Dec-05
+
 Again:   2002-Jul-06
+
 Again:   2005-Sep-19
 
-NOTE:
+Again:   2017-Mar-29
 
-The USB subsystem now has a substantial section in "The Linux Kernel API"
-guide (in Documentation/DocBook), generated from the current source
-code.  This particular documentation file isn't particularly current or
-complete; don't rely on it except for a quick overview.
 
+.. note::
 
-1.1. Basic concept or 'What is an URB?'
+The USB subsystem now has a substantial section at :ref:`usb-hostside-api`
+section, generated from the current source code.
+This particular documentation file isn't complete and may not be
+updated to the last version; don't rely on it except for a quick
+overview.
+
+Basic concept or 'What is an URB?'
+==
 
 The basic idea of the new driver is message passing, the message itself is 
 called USB Request Block, or URB for short. 
@@ -19,10 +28,11 @@ called USB Request Block, or URB for short.
   and deliver the data and status back. 
 
 - Execution of an URB is inherently an asynchronous operation, i.e. the 
-  usb_submit_urb(urb) call returns immediately after it has successfully
+  :c:func:`usb_submit_urb` call returns immediately after it has successfully
   queued the requested action.
 
-- Transfers for one URB can be canceled with usb_unlink_urb(urb) at any time. 
+- Transfers for one URB can be canceled with :c:func:`usb_unlink_urb`
+  at any time.
 
 - Each URB has a completion handler, which is called after the action
   has been successfully completed or canceled. The URB also contains a
@@ -35,53 +45,55 @@ called USB Request Block, or URB for short.
   of data to (or from) devices when using periodic transfer modes.
 
 
-1.2. The URB structure
+The URB structure
+=
 
-Some of the fields in an URB are:
+Some of the fields in struct :c:type:`urb` are::
 
-struct urb
-{
-// (IN) device and pipe specify the endpoint queue
+  struct urb
+  {
+  // (IN) device and pipe specify the endpoint queue
struct usb_device *dev; // pointer to associated USB device
unsigned int pipe;  // endpoint information
 
-   unsigned int transfer_flags;// ISO_ASAP, SHORT_NOT_OK, etc.
+   unsigned int transfer_flags;// URB_ISO_ASAP, URB_SHORT_NOT_OK, etc.
 
-// (IN) all urbs need completion routines
+  // (IN) all urbs need completion routines
void *context;  // context for completion routine
-   void (*complete)(struct urb *); // pointer to completion routine
+   usb_complete_t complete;// pointer to completion routine
 
-// (OUT) status after each completion
+  // (OUT) status after each completion
int status; // returned status
 
-// (IN) buffer used for data transfers
+  // (IN) buffer used for data transfers
void *transfer_buffer;  // associated data buffer
-   int transfer_buffer_length; // data buffer length
+   u32 transfer_buffer_length; // data buffer length
int number_of_packets;  // size of iso_frame_desc
 
-// (OUT) sometimes only part of CTRL/BULK/INTR transfer_buffer is used
-   int actual_length;  // actual data buffer length
+  // (OUT) sometimes only part of CTRL/BULK/INTR transfer_buffer is used
+   u32 actual_length;  // actual data buffer length
 
-// (IN) setup stage for CTRL (pass a struct usb_ctrlrequest)
-   unsigned char* setup_packet;// setup packet (control only)
+  // (IN) setup stage for CTRL (pass a struct usb_ctrlrequest)
+   unsigned char *setup_packet;// setup packet (control only)
 
-// Only for PERIODIC transfers (ISO, INTERRUPT)
-// (IN/OUT) start_frame is set unless ISO_ASAP 

[PATCH 18/22] usb: get rid of some ReST doc build errors

[Mauro Carvalho Chehab]

We need an space before a numbered list to avoid those warnings:

./drivers/usb/core/message.c:478: ERROR: Unexpected indentation.
./drivers/usb/core/message.c:479: WARNING: Block quote ends without a blank 
line; unexpected unindent.
./include/linux/usb/composite.h:455: ERROR: Unexpected indentation.
./include/linux/usb/composite.h:456: WARNING: Block quote ends without a blank 
line; unexpected unindent.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/usb/core/message.c| 1 +
 include/linux/usb/composite.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index 2184ef40a82a..4c38ea41ae96 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -474,6 +474,7 @@ EXPORT_SYMBOL_GPL(usb_sg_init);
  * significantly improve USB throughput.
  *
  * There are three kinds of completion for this function.
+ *
  * (1) success, where io->status is zero.  The number of io->bytes
  * transferred is as requested.
  * (2) error, where io->status is a negative errno value.  The number
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 4616a49a1c2e..30a063e98c19 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -451,6 +451,7 @@ static inline struct usb_composite_driver *to_cdriver(
  * sure doing that won't hurt too much.
  *
  * One notion for how to handle Wireless USB devices involves:
+ *
  * (a) a second gadget here, discovery mechanism TBD, but likely
  * needing separate "register/unregister WUSB gadget" calls;
  * (b) updates to usb_gadget to include flags "is it wireless",
-- 
2.9.3

[PATCH 12/22] error-codes.rst: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core features. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/usb/error-codes.rst | 205 +++
 Documentation/driver-api/usb/index.rst   |   1 +
 Documentation/usb/error-codes.txt| 175 ---
 3 files changed, 206 insertions(+), 175 deletions(-)
 create mode 100644 Documentation/driver-api/usb/error-codes.rst
 delete mode 100644 Documentation/usb/error-codes.txt

diff --git a/Documentation/driver-api/usb/error-codes.rst 
b/Documentation/driver-api/usb/error-codes.rst
new file mode 100644
index ..715cc35b29b0
--- /dev/null
+++ b/Documentation/driver-api/usb/error-codes.rst
@@ -0,0 +1,205 @@
+USB Error codes
+~~~
+
+Revised: 2004-Oct-21
+
+This is the documentation of (hopefully) all possible error codes (and
+their interpretation) that can be returned from usbcore.
+
+Some of them are returned by the Host Controller Drivers (HCDs), which
+device drivers only see through usbcore.  As a rule, all the HCDs should
+behave the same except for transfer speed dependent behaviors and the
+way certain faults are reported.
+
+
+Error codes returned by :c:func:`usb_submit_urb`
+
+
+Non-USB-specific:
+
+
+=== ===
+0  URB submission went fine
+
+``-ENOMEM``no memory for allocation of internal structures
+=== ===
+
+USB-specific:
+
+===
===
+``-EBUSY`` The URB is already active.
+
+``-ENODEV``specified USB-device or bus doesn't exist
+
+``-ENOENT``specified interface or endpoint does not exist or
+   is not enabled
+
+``-ENXIO`` host controller driver does not support queuing of
+   this type of urb.  (treat as a host controller bug.)
+
+``-EINVAL``a) Invalid transfer type specified (or not supported)
+   b) Invalid or unsupported periodic transfer interval
+   c) ISO: attempted to change transfer interval
+   d) ISO: ``number_of_packets`` is < 0
+   e) various other cases
+
+``-EXDEV`` ISO: ``URB_ISO_ASAP`` wasn't specified and all the
+   frames the URB would be scheduled in have already
+   expired.
+
+``-EFBIG`` Host controller driver can't schedule that many ISO
+   frames.
+
+``-EPIPE`` The pipe type specified in the URB doesn't match the
+   endpoint's actual type.
+
+``-EMSGSIZE``  (a) endpoint maxpacket size is zero; it is not usable
+   in the current interface altsetting.
+   (b) ISO packet is larger than the endpoint maxpacket.
+   (c) requested data transfer length is invalid: negative
+   or too large for the host controller.
+
+``-ENOSPC``This request would overcommit the usb bandwidth reserved
+   for periodic transfers (interrupt, isochronous).
+
+``-ESHUTDOWN`` The device or host controller has been disabled due to
+   some problem that could not be worked around.
+
+``-EPERM`` Submission failed because ``urb->reject`` was set.
+
+``-EHOSTUNREACH``  URB was rejected because the device is suspended.
+
+``-ENOEXEC``   A control URB doesn't contain a Setup packet.
+===
===
+
+Error codes returned by ``in urb->status`` or in ``iso_frame_desc[n].status`` 
(for ISO)
+===
+
+USB device drivers may only test urb status values in completion handlers.
+This is because otherwise there would be a race between HCDs updating
+these values on one CPU, and device drivers testing them on another CPU.
+
+A transfer's actual_length may be positive even when an error has been
+reported.  That's because transfers often involve several packets, so that
+one or more packets could finish before an error stops further endpoint I/O.
+
+For isochronous URBs, the urb status value is non-zero only if the URB is
+unlinked, the device is removed, the host controller is disabled, or the total
+transferred length is less than the requested length and the
+``URB_SHORT_NOT_OK`` flag is set.  Completion handlers for isochronous URBs
+should only see ``urb->status`` set to zero, ``-ENOENT``, ``-ECONNRESET``,
+``-ESHUTDOWN``, or ``-EREMOTEIO``. Individual frame descriptor status fields
+may report more status codes.
+
+
+===

[PATCH 06/22] writing_musb_glue_layer.rst: Enrich its ReST representation

[Mauro Carvalho Chehab]

This file is actually quite complex, and required several
manual handwork:

- add a title for the document;
- use the right tags for monospaced fonts;
- use c references where needed;
- adjust cross-reference to writing_usb_driver.rst
- hightlight cross-referenced lines.

With regards to C code snippet line highlights, the better would be
to use :linenos: for the C code snippets that are referenced by
the line number. However, at least with Sphinx 1.4.9, enabling
it cause the line number to be misaligned with the code,
making it even more confusing. So, instead, let's use
:emphasize-lines: tag to mark the lines that are referenced
at the text.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../driver-api/usb/writing_musb_glue_layer.rst | 251 ++---
 1 file changed, 120 insertions(+), 131 deletions(-)

diff --git a/Documentation/driver-api/usb/writing_musb_glue_layer.rst 
b/Documentation/driver-api/usb/writing_musb_glue_layer.rst
index 2546a102394f..89333a69d4ba 100644
--- a/Documentation/driver-api/usb/writing_musb_glue_layer.rst
+++ b/Documentation/driver-api/usb/writing_musb_glue_layer.rst
@@ -1,3 +1,6 @@
+Writing MUSB Glue Layer
+~~~
+
 Introduction
 
 
@@ -15,10 +18,12 @@ design.
 As a self-taught exercise I have written an MUSB glue layer for the
 Ingenic JZ4740 SoC, modelled after the many MUSB glue layers in the
 kernel source tree. This layer can be found at
-drivers/usb/musb/jz4740.c. In this documentation I will walk through the
-basics of the jz4740.c glue layer, explaining the different pieces and
+``drivers/usb/musb/jz4740.c``. In this documentation I will walk through the
+basics of the ``jz4740.c`` glue layer, explaining the different pieces and
 what needs to be done in order to write your own device glue layer.
 
+.. _musb-basics:
+
 Linux MUSB Basics
 =
 
@@ -33,9 +38,7 @@ USB Device Drivers documentation (again, see Resources).
 
 Linux USB stack is a layered architecture in which the MUSB controller
 hardware sits at the lowest. The MUSB controller driver abstract the
-MUSB controller hardware to the Linux USB stack.
-
-::
+MUSB controller hardware to the Linux USB stack::
 
  
  |  | <--- drivers/usb/gadget
@@ -59,7 +62,6 @@ MUSB controller hardware to the Linux USB stack.
   |   MUSB Controller Hardware|
   -
 
-
 As outlined above, the glue layer is actually the platform specific code
 sitting in between the controller driver and the controller hardware.
 
@@ -72,9 +74,7 @@ about an embedded controller chip here, so no insertion or 
removal at
 run-time.
 
 All of this information is passed to the MUSB controller driver through
-a platform\_driver structure defined in the glue layer as:
-
-::
+a :c:type:`platform_driver` structure defined in the glue layer as::
 
 static struct platform_driver jz4740_driver = {
.probe  = jz4740_probe,
@@ -84,20 +84,17 @@ a platform\_driver structure defined in the glue layer as:
},
 };
 
-
 The probe and remove function pointers are called when a matching device
 is detected and, respectively, released. The name string describes the
 device supported by this glue layer. In the current case it matches a
-platform\_device structure declared in arch/mips/jz4740/platform.c. Note
+platform_device structure declared in ``arch/mips/jz4740/platform.c``. Note
 that we are not using device tree bindings here.
 
 In order to register itself to the controller driver, the glue layer
 goes through a few steps, basically allocating the controller hardware
 resources and initialising a couple of circuits. To do so, it needs to
 keep track of the information used throughout these steps. This is done
-by defining a private jz4740\_glue structure:
-
-::
+by defining a private ``jz4740_glue`` structure::
 
 struct jz4740_glue {
struct device   *dev;
@@ -115,10 +112,13 @@ information related to the device clock operation.
 Let's go through the steps of the probe function that leads the glue
 layer to register itself to the controller driver.
 
-N.B.: For the sake of readability each function will be split in logical
-parts, each part being shown as if it was independent from the others.
+.. note::
 
-::
+   For the sake of readability each function will be split in logical
+   parts, each part being shown as if it was independent from the others:
+
+   .. code-block:: c
+:emphasize-lines: 8,12,18
 
 static int jz4740_probe(struct platform_device *pdev)
 {
@@ -163,21 +163,23 @@ parts, each part being shown as if it was independent 
from the others.
return ret;
 }
 
+   The first few lines of the probe function allocate and assign the glue,
+   musb and clk variables. The ``GFP_KERNEL`` flag (line 8) allows the
+   allocation process to sleep and wait for memory, thus being usable in a
+   locking 

[PATCH 03/22] usb.rst: Enrich its ReST representation

[Mauro Carvalho Chehab]

- use the proper warning and note markups;
- add references for parts of the document that will be
  cross-referenced on other USB docs;
- some minor adjustments to make it better to read in
  text mode and in html.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/usb/usb.rst | 48 +---
 1 file changed, 17 insertions(+), 31 deletions(-)

diff --git a/Documentation/driver-api/usb/usb.rst 
b/Documentation/driver-api/usb/usb.rst
index b856abb3200e..7e820768ee4f 100644
--- a/Documentation/driver-api/usb/usb.rst
+++ b/Documentation/driver-api/usb/usb.rst
@@ -102,6 +102,8 @@ disconnect testing (while the device is active) with each 
different host
 controller driver, to make sure drivers don't have bugs of their own as
 well as to make sure they aren't relying on some HCD-specific behavior.
 
+.. _usb_chapter9:
+
 USB-Standard Types
 ==
 
@@ -112,6 +114,8 @@ USB, and in APIs including this host side API, gadget APIs, 
and usbfs.
 .. kernel-doc:: include/linux/usb/ch9.h
:internal:
 
+.. _usb_header:
+
 Host-Side Data Types and Macros
 ===
 
@@ -209,7 +213,7 @@ library that wraps it. Such libraries include
 `libusb `__ for C/C++, and
 `jUSB `__ for Java.
 
-**Note**
+.. note::
 
 This particular documentation is incomplete, especially with respect
 to the asynchronous mode. As of kernel 2.5.66 the code and this
@@ -319,9 +323,7 @@ files. For information about the current format of this 
file, see the
 sources.
 
 This file, in combination with the poll() system call, can also be used
-to detect when devices are added or removed:
-
-::
+to detect when devices are added or removed::
 
 int fd;
 struct pollfd pfd;
@@ -407,9 +409,7 @@ The ioctl() Requests
 
 
 To use these ioctls, you need to include the following headers in your
-userspace program:
-
-::
+userspace program::
 
 #include 
 #include 
@@ -458,9 +458,7 @@ USBDEVFS_CLAIMINTERFACE
 
 USBDEVFS_CONNECTINFO
 Says whether the device is lowspeed. The ioctl parameter points to a
-structure like this:
-
-::
+structure like this::
 
struct usbdevfs_connectinfo {
unsigned int   devnum;
@@ -477,9 +475,7 @@ USBDEVFS_CONNECTINFO
 USBDEVFS_GETDRIVER
 Returns the name of the kernel driver bound to a given interface (a
 string). Parameter is a pointer to this structure, which is
-modified:
-
-::
+modified::
 
struct usbdevfs_getdriver {
unsigned int  interface;
@@ -490,9 +486,7 @@ USBDEVFS_GETDRIVER
 
 USBDEVFS_IOCTL
 Passes a request from userspace through to a kernel driver that has
-an ioctl entry in the *struct usb_driver* it registered.
-
-::
+an ioctl entry in the *struct usb_driver* it registered::
 
struct usbdevfs_ioctl {
int ifno;
@@ -534,7 +528,7 @@ USBDEVFS_RELEASEINTERFACE
 the number of the interface (bInterfaceNumber from descriptor); File
 modification time is not updated by this request.
 
-   **Warning**
+.. warning::
 
*No security check is made to ensure that the task which made
the claim is the one which is releasing it. This means that user
@@ -574,9 +568,7 @@ a time.
 
 USBDEVFS_BULK
 Issues a bulk read or write request to the device. The ioctl
-parameter is a pointer to this structure:
-
-::
+parameter is a pointer to this structure::
 
struct usbdevfs_bulktransfer {
unsigned int  ep;
@@ -606,9 +598,7 @@ USBDEVFS_CLEAR_HALT
 
 USBDEVFS_CONTROL
 Issues a control request to the device. The ioctl parameter points
-to a structure like this:
-
-::
+to a structure like this::
 
struct usbdevfs_ctrltransfer {
__u8   bRequestType;
@@ -638,7 +628,7 @@ USBDEVFS_RESET
 the reset, this rebinds all device interfaces. File modification
 time is not updated by this request.
 
-   **Warning**
+.. warning::
 
*Avoid using this call* until some usbcore bugs get fixed, since
it does not fully synchronize device, interface, and driver (not
@@ -646,9 +636,7 @@ USBDEVFS_RESET
 
 USBDEVFS_SETINTERFACE
 Sets the alternate setting for an interface. The ioctl parameter is
-a pointer to a structure like this:
-
-::
+a pointer to a structure like this::
 
struct usbdevfs_setinterface {
unsigned int  interface;
@@ -669,7 +657,7 @@ USBDEVFS_SETCONFIGURATION
 configuration (bConfigurationValue from descriptor). File
 modification time is not updated by this request.
 
-   **Warning**
+.. warning::
 
*Avoid using this call* until some usbcore bugs get fixed, since
it does not fully synchronize device, interface, and driver (not
@@ -702,9 +690,7 @@ When usbfs returns these urbs, the status value is updated, 
and the
 buffer 

[PATCH 17/22] usb.rst: get rid of some Sphinx errors

[Mauro Carvalho Chehab]

Get rid of those warnings:

Documentation/driver-api/usb/usb.rst:615: ERROR: Unknown target name: 
"usb_type".
Documentation/driver-api/usb/usb.rst:615: ERROR: Unknown target name: 
"usb_dir".
Documentation/driver-api/usb/usb.rst:615: ERROR: Unknown target name: 
"usb_recip".
Documentation/driver-api/usb/usb.rst:679: ERROR: Unknown target name: 
"usbdevfs_urb_type".

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/usb/usb.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/driver-api/usb/usb.rst 
b/Documentation/driver-api/usb/usb.rst
index d15ab8ae5239..5ebaf669704c 100644
--- a/Documentation/driver-api/usb/usb.rst
+++ b/Documentation/driver-api/usb/usb.rst
@@ -615,8 +615,8 @@ USBDEVFS_CONTROL
 The first eight bytes of this structure are the contents of the
 SETUP packet to be sent to the device; see the USB 2.0 specification
 for details. The bRequestType value is composed by combining a
-USB_TYPE_\* value, a USB_DIR_\* value, and a USB_RECIP_\*
-value (from **). If wLength is nonzero, it describes
+``USB_TYPE_*`` value, a ``USB_DIR_*`` value, and a ``USB_RECIP_*``
+value (from ``linux/usb.h``). If wLength is nonzero, it describes
 the length of the data buffer, which is either written to the device
 (USB_DIR_OUT) or read from the device (USB_DIR_IN).
 
@@ -678,7 +678,7 @@ the blocking is separate.
 
 These requests are packaged into a structure that resembles the URB used
 by kernel device drivers. (No POSIX Async I/O support here, sorry.) It
-identifies the endpoint type (USBDEVFS_URB_TYPE_\*), endpoint
+identifies the endpoint type (``USBDEVFS_URB_TYPE_*``), endpoint
 (number, masked with USB_DIR_IN as appropriate), buffer and length,
 and a user "context" value serving to uniquely identify each request.
 (It's usually a pointer to per-request data.) Flags can modify requests
-- 
2.9.3

[PATCH 14/22] usb/persist.txt: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core features. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/usb/index.rst |  1 +
 .../persist.txt => driver-api/usb/persist.rst} | 22 +-
 2 files changed, 14 insertions(+), 9 deletions(-)
 rename Documentation/{usb/persist.txt => driver-api/usb/persist.rst} (94%)

diff --git a/Documentation/driver-api/usb/index.rst 
b/Documentation/driver-api/usb/index.rst
index 43f0a8b72b11..3f08cb5d5feb 100644
--- a/Documentation/driver-api/usb/index.rst
+++ b/Documentation/driver-api/usb/index.rst
@@ -12,6 +12,7 @@ Linux USB API
dma
power-management
hotplug
+   persist
error-codes
writing_usb_driver
writing_musb_glue_layer
diff --git a/Documentation/usb/persist.txt 
b/Documentation/driver-api/usb/persist.rst
similarity index 94%
rename from Documentation/usb/persist.txt
rename to Documentation/driver-api/usb/persist.rst
index 35d70eda9ad6..af02baf61f57 100644
--- a/Documentation/usb/persist.txt
+++ b/Documentation/driver-api/usb/persist.rst
@@ -1,11 +1,12 @@
-   USB device persistence during system suspend
+USB device persistence during system suspend
+
 
-  Alan Stern 
+Alan Stern 
+September 2, 2006 (Updated February 25, 2008)
 
-   September 2, 2006 (Updated February 25, 2008)
 
-
-   What is the problem?
+What is the problem?
+
 
 According to the USB specification, when a USB bus is suspended the
 bus must continue to supply suspend current (around 1-5 mA).  This
@@ -63,7 +64,8 @@ suspended -- but it will crash as soon as it wakes up, which 
isn't
 much better.)
 
 
-   What is the solution?
+What is the solution?
+=
 
 The kernel includes a feature called USB-persist.  It tries to work
 around these issues by allowing the core USB device data structures to
@@ -99,7 +101,7 @@ now a good and happy place.
 
 Note that the "USB-persist" feature will be applied only to those
 devices for which it is enabled.  You can enable the feature by doing
-(as root):
+(as root)::
 
echo 1 >/sys/bus/usb/devices/.../power/persist
 
@@ -110,7 +112,8 @@ doesn't even exist, so you only have to worry about setting 
it for
 devices where it really matters.
 
 
-   Is this the best solution?
+Is this the best solution?
+==
 
 Perhaps not.  Arguably, keeping track of mounted filesystems and
 memory mappings across device disconnects should be handled by a
@@ -130,7 +133,8 @@ just mass-storage devices.  It might turn out to be equally 
useful for
 other device types, such as network interfaces.
 
 
-   WARNING: USB-persist can be dangerous!!
+WARNING: USB-persist can be dangerous!!
+===
 
 When recovering an interrupted power session the kernel does its best
 to make sure the USB device hasn't been changed; that is, the same
-- 
2.9.3

[PATCH 22/22] usb: document that URB transfer_buffer should be aligned

[Mauro Carvalho Chehab]

Several host controllers, commonly found on ARM, like dwc2,
require buffers that are CPU-word aligned for they to work.

Failing to do that will cause random troubles at the caller
drivers, causing them to fail.

Document it.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/usb/URB.rst | 18 ++
 drivers/usb/core/message.c   | 15 +++
 include/linux/usb.h  | 18 ++
 3 files changed, 51 insertions(+)

diff --git a/Documentation/driver-api/usb/URB.rst 
b/Documentation/driver-api/usb/URB.rst
index d9ea6a3996e7..b83b557e9891 100644
--- a/Documentation/driver-api/usb/URB.rst
+++ b/Documentation/driver-api/usb/URB.rst
@@ -274,6 +274,24 @@ If you specify your own start frame, make sure it's 
several frames in advance
 of the current frame.  You might want this model if you're synchronizing
 ISO data with some other event stream.
 
+.. note::
+
+   Several host drivers require that the ``transfer_buffer`` to be aligned
+   with the CPU word size (e. g. DWORD for 32 bits, QDWORD for 64 bits).
+   It is up to USB drivers should ensure that they'll only pass buffers
+   with such alignments.
+
+   Please also notice that, due to such restriction, the host driver
+   may also override PAD bytes at the end of the ``transfer_buffer``, up to the
+   size of the CPU word.
+
+   Please notice that ancillary routines that transfer URBs, like
+   usb_control_msg() also have such restriction.
+
+   Such word alignment condition is normally ensured if the buffer is
+   allocated with kmalloc(), but this may not be the case if the driver
+   allocates a bigger buffer and point to a random place inside it.
+
 
 How to start interrupt (INT) transfers?
 ===
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index 4c38ea41ae96..1662a4446475 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -128,6 +128,21 @@ static int usb_internal_control_msg(struct usb_device 
*usb_dev,
  * make sure your disconnect() method can wait for it to complete. Since you
  * don't have a handle on the URB used, you can't cancel the request.
  *
+ * .. note::
+ *
+ *   Several host drivers require that the @data buffer to be aligned
+ *   with the CPU word size (e. g. DWORD for 32 bits, QDWORD for 64 bits).
+ *   It is up to USB drivers should ensure that they'll only pass buffers
+ *   with such alignments.
+ *
+ *   Please also notice that, due to such restriction, the host driver
+ *   may also override PAD bytes at the end of the @data buffer, up to the
+ *   size of the CPU word.
+ *
+ *   Such word alignment condition is normally ensured if the buffer is
+ *   allocated with kmalloc(), but this may not be the case if the driver
+ *   allocates a bigger buffer and point to a random place inside it.
+ *
  * Return: If successful, the number of bytes transferred. Otherwise, a 
negative
  * error number.
  */
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 7e68259360de..8b5ad6624708 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -1373,6 +1373,24 @@ typedef void (*usb_complete_t)(struct urb *);
  * capable, assign NULL to it, so that usbmon knows not to use the value.
  * The setup_packet must always be set, so it cannot be located in highmem.
  *
+ * .. note::
+ *
+ *   Several host drivers require that the @transfer_buffer to be aligned
+ *   with the CPU word size (e. g. DWORD for 32 bits, QDWORD for 64 bits).
+ *   It is up to USB drivers should ensure that they'll only pass buffers
+ *   with such alignments.
+ *
+ *   Please also notice that, due to such restriction, the host driver
+ *   may also override PAD bytes at the end of the @transfer_buffer, up to the
+ *   size of the CPU word.
+ *
+ *   Please notice that ancillary routines that start URB transfers, like
+ *   usb_control_msg() also have such restriction.
+ *
+ *   Such word alignment condition is normally ensured if the buffer is
+ *   allocated with kmalloc(), but this may not be the case if the driver
+ *   allocates a bigger buffer and point to a random place inside it.
+ *
  * Initialization:
  *
  * All URBs submitted must initialize the dev, pipe, transfer_flags (may be
-- 
2.9.3

[PATCH 07/22] usb/anchors.txt: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core functions. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../anchors.txt => driver-api/usb/anchors.rst} | 36 --
 Documentation/driver-api/usb/index.rst |  1 +
 2 files changed, 21 insertions(+), 16 deletions(-)
 rename Documentation/{usb/anchors.txt => driver-api/usb/anchors.rst} (75%)

diff --git a/Documentation/usb/anchors.txt 
b/Documentation/driver-api/usb/anchors.rst
similarity index 75%
rename from Documentation/usb/anchors.txt
rename to Documentation/driver-api/usb/anchors.rst
index fe6a99a32bbd..4b248e691bd6 100644
--- a/Documentation/usb/anchors.txt
+++ b/Documentation/driver-api/usb/anchors.rst
@@ -1,3 +1,6 @@
+USB Anchors
+~~~
+
 What is anchor?
 ===
 
@@ -13,7 +16,7 @@ Allocation and Initialisation
 =
 
 There's no API to allocate an anchor. It is simply declared
-as struct usb_anchor. init_usb_anchor() must be called to
+as struct usb_anchor. :c:func:`init_usb_anchor` must be called to
 initialise the data structure.
 
 Deallocation
@@ -26,52 +29,53 @@ Association and disassociation of URBs with anchors
 ===
 
 An association of URBs to an anchor is made by an explicit
-call to usb_anchor_urb(). The association is maintained until
+call to :c:func:`usb_anchor_urb`. The association is maintained until
 an URB is finished by (successful) completion. Thus disassociation
 is automatic. A function is provided to forcibly finish (kill)
 all URBs associated with an anchor.
-Furthermore, disassociation can be made with usb_unanchor_urb()
+Furthermore, disassociation can be made with :c:func:`usb_unanchor_urb`
 
 Operations on multitudes of URBs
 
 
-usb_kill_anchored_urbs()
-
+:c:func:`usb_kill_anchored_urbs`
+
 
 This function kills all URBs associated with an anchor. The URBs
 are called in the reverse temporal order they were submitted.
 This way no data can be reordered.
 
-usb_unlink_anchored_urbs()
---
+:c:func:`usb_unlink_anchored_urbs`
+--
+
 
 This function unlinks all URBs associated with an anchor. The URBs
 are processed in the reverse temporal order they were submitted.
-This is similar to usb_kill_anchored_urbs(), but it will not sleep.
+This is similar to :c:func:`usb_kill_anchored_urbs`, but it will not sleep.
 Therefore no guarantee is made that the URBs have been unlinked when
 the call returns. They may be unlinked later but will be unlinked in
 finite time.
 
-usb_scuttle_anchored_urbs()

+:c:func:`usb_scuttle_anchored_urbs`
+---
 
 All URBs of an anchor are unanchored en masse.
 
-usb_wait_anchor_empty_timeout()

+:c:func:`usb_wait_anchor_empty_timeout`
+---
 
 This function waits for all URBs associated with an anchor to finish
 or a timeout, whichever comes first. Its return value will tell you
 whether the timeout was reached.
 
-usb_anchor_empty()
---
+:c:func:`usb_anchor_empty`
+--
 
 Returns true if no URBs are associated with an anchor. Locking
 is the caller's responsibility.
 
-usb_get_from_anchor()
--
+:c:func:`usb_get_from_anchor`
+-
 
 Returns the oldest anchored URB of an anchor. The URB is unanchored
 and returned with a reference. As you may mix URBs to several
diff --git a/Documentation/driver-api/usb/index.rst 
b/Documentation/driver-api/usb/index.rst
index cf2fa2e8d236..5dfb04b2d730 100644
--- a/Documentation/driver-api/usb/index.rst
+++ b/Documentation/driver-api/usb/index.rst
@@ -6,6 +6,7 @@ Linux USB API
 
usb
gadget
+   anchors
writing_usb_driver
writing_musb_glue_layer
 
-- 
2.9.3

[PATCH 20/22] usb: gadget.h: be consistent at kernel doc macros

[Mauro Carvalho Chehab]

There's one value that use spaces instead of tabs to ident.
That causes the following warning:

./include/linux/usb/gadget.h:193: ERROR: Unexpected indentation.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/linux/usb/gadget.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index e4516e9ded0f..fbc22a39e7bc 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -188,7 +188,7 @@ struct usb_ep_caps {
  * @caps:The structure describing types and directions supported by endoint.
  * @maxpacket:The maximum packet size used on this endpoint.  The initial
  * value can sometimes be reduced (hardware allowing), according to
- *  the endpoint descriptor used to configure the endpoint.
+ * the endpoint descriptor used to configure the endpoint.
  * @maxpacket_limit:The maximum packet size value which can be handled by this
  * endpoint. It's set once by UDC driver when endpoint is initialized, and
  * should not be changed. Should not be confused with maxpacket.
-- 
2.9.3

Re: [PATCH RFC] dwc2: Don't assume URB transfer_buffer are dword-aligned

[Mauro Carvalho Chehab]

Em Wed, 29 Mar 2017 11:57:22 +0200
Greg Kroah-Hartman  escreveu:

> On Tue, Mar 28, 2017 at 06:48:02AM -0300, Mauro Carvalho Chehab wrote:
> > Em Fri, 17 Mar 2017 10:24:15 +0900
> > Greg Kroah-Hartman  escreveu:
> >   
> > > On Thu, Mar 16, 2017 at 09:08:40PM -0300, Mauro Carvalho Chehab wrote:  
> > > > The dwc2 hardware doesn't like to do DMA transfers without
> > > > aligning data in DWORD. The driver also assumes that, even
> > > > when there's no DMA, at dwc2_read_packet().
> > > > 
> > > > That cause buffer overflows, preventing some drivers to work.
> > > 
> > > Why aren't the drivers being fixed?  This is a well-known (hopefully)
> > > restriction on USB data buffers, can't the uvc_driver be fixed?  
> > 
> > I talked to Laurent about on IRC. He told that he is willing to consider
> > that option, if the USB API explicitly states that all buffers must be
> > dword-aligned (and/or buffer sizes).
> > 
> > IMHO, he has a point: if this is a restriction of for usb transfer
> > buffers, it should be documented somewhere.
> > 
> > Yet, a quick check with:
> > $ git grep -i dword Documentation/usb/
> > $ git grep -i align Documentation/usb/
> > 
> > Didn't hit anything related to it.   
> 
> Hm, most of the USB documentation is in the kerneldoc in the USB code
> itself, and is built that way.  I'm pretty sure this is documented
> somewhere, but I can't seem to find it at the moment either :(
> 
> Care to write a patch for that?  :)

Sure. Btw, I noticed that not all USB documents were converted
yet to ReST, so I took the time to convert the core documents to ReST
too.

I kept the driver-specific documentation at Documentation/usb.
The final result is at:
http://www.infradead.org/~mchehab/kernel_docs/driver-api/usb/index.html

I'll be sending the documentation patches in a few.

Thanks,
Mauro

Re: dvb-tools: dvbv5-scan segfaults with DVB-T2 HD service that just started in Germany

[Gregor Jasny]

Hello Mauro & list,

could you please have a look at the dvbv5-scan crash report below?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859008

Is there anything else you need to debug this?

Thanks,
Gregor

On 3/29/17 4:42 PM, Tino Mettler wrote:
> 
> $ gdb --args ./utils/dvb/dvbv5-scan ~/tmp/dvb-t2/init2 
> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ./utils/dvb/dvbv5-scan...done.
> (gdb) run
> Starting program: /home/scorpion/build/9643/v4l-utils/utils/dvb/dvbv5-scan 
> /home/scorpion/tmp/dvb-t2/init2
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Scanning frequency #1 55400
> Lock   (0x1f) C/N= 23.75dB
> Service Das Erste HD, provider BR: reserved
> Service arte HD, provider BR: reserved
> Service PHOENIX HD, provider BR: reserved
> Service tagesschau24 HD, provider BR: reserved
> Service ONE HD, provider BR: reserved
> New transponder/channel found: #11: -1776415946
> New transponder/channel found: #12: 504706590
> New transponder/channel found: #13: 523640360
> New transponder/channel found: #14: 907948854
> New transponder/channel found: #15: -397832490
> New transponder/channel found: #16: 0
> New transponder/channel found: #17: 0
> New transponder/channel found: #18: 0
> New transponder/channel found: #19: 0
> New transponder/channel found: #20: 0
> New transponder/channel found: #21: 0
> New transponder/channel found: #22: 0
> New transponder/channel found: #23: 0
> New transponder/channel found: #24: 0
> New transponder/channel found: #25: 0
> New transponder/channel found: #26: 0
> New transponder/channel found: #27: 0
> New transponder/channel found: #28: 0
> New transponder/channel found: #29: 0
> New transponder/channel found: #30: 0
> New transponder/channel found: #31: 0
> New transponder/channel found: #32: 0
> New transponder/channel found: #33: 0
> New transponder/channel found: #34: 0
> New transponder/channel found: #35: 0
> New transponder/channel found: #36: 0
> New transponder/channel found: #37: 0
> New transponder/channel found: #38: 0
> New transponder/channel found: #39: 0
> New transponder/channel found: #40: 0
> New transponder/channel found: #41: 0
> New transponder/channel found: #42: 0
> New transponder/channel found: #43: 0
> New transponder/channel found: #44: 0
> New transponder/channel found: #45: 0
> New transponder/channel found: #46: 0
> New transponder/channel found: #47: 0
> New transponder/channel found: #48: 0
> New transponder/channel found: #49: 0
> New transponder/channel found: #50: 0
> New transponder/channel found: #51: 0
> New transponder/channel found: #52: 0
> New transponder/channel found: #53: 0
> New transponder/channel found: #54: 0
> New transponder/channel found: #55: 0
> New transponder/channel found: #56: 0
> New transponder/channel found: #57: 0
> New transponder/channel found: #58: 0
> New transponder/channel found: #59: 0
> New transponder/channel found: #60: 0
> New transponder/channel found: #61: 0
> New transponder/channel found: #62: 0
> New transponder/channel found: #63: 0
> New transponder/channel found: #64: 0
> New transponder/channel found: #65: 0
> New transponder/channel found: #66: 0
> New transponder/channel found: #67: 0
> New transponder/channel found: #68: 0
> New transponder/channel found: #69: 0
> New transponder/channel found: #70: 0
> New transponder/channel found: #71: 0
> New transponder/channel found: #72: 0
> New transponder/channel found: #73: 0
> New transponder/channel found: #74: 0
> New transponder/channel found: #75: 0
> Scanning frequency #2 65000
>(0x00) Signal= -69.00dBm
> Scanning frequency #3 73800
>(0x00) Signal= -76.00dBm
> Scanning frequency #4 57800
> Lock   (0x1f) Signal= -76.00dBm C/N= 27.25dB
> *** Error in `/home/scorpion/build/9643/v4l-utils/utils/dvb/dvbv5-scan': 
> malloc(): memory corruption: 0x557a6b70 ***
> === Backtrace: =
> /lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7759fbcb]
> /lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x775a5f96]
> /lib/x86_64-linux-gnu/libc.so.6(+0x78f69)[0x775a7f69]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_calloc+0x27b)[0x775aa99b]
> 

Re: [PATCHv5 00/11] video/exynos/sti/cec: add CEC notifier & use in drivers

[Daniel Vetter]

On Wed, Mar 29, 2017 at 04:15:32PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> This patch series adds the CEC physical address notifier code, based on
> Russell's code:
> 
> https://patchwork.kernel.org/patch/9277043/
> 
> It adds support for it to the exynos_hdmi drm driver, adds support for
> it to the CEC framework and finally adds support to the s5p-cec driver,
> which now can be moved out of staging.
> 
> Also included is similar code for the STI platform, contributed by
> Benjamin Gaignard.
> 
> Tested the exynos code with my Odroid U3 exynos4 devboard.
> 
> After discussions with Daniel Vetter and Russell King I have removed
> the EDID/ELD/HPD connect/disconnect events from the notifier and now
> just use it to report the CEC physical address. This also means that
> it is now renamed to CEC notifier instead of HPD notifier and that
> it is now in drivers/media. The block_notifier was dropped as well
> and instead a simple callback is registered. This means that the
> relationship between HDMI and CEC is now 1:1 and no longer 1:n, but
> should this be needed in the future, then that can easily be added
> back.
> 
> Daniel, regarding your suggestions here:
> 
> http://www.spinics.net/lists/dri-devel/msg133907.html
> 
> this patch series maps to your mail above as follows:
> 
> struct cec_pin == struct cec_notifier
> cec_(un)register_pin == cec_notifier_get/put
> cec_set_address == cec_notifier_set_phys_addr
> cec_(un)register_callbacks == cec_notifier_(un)register
> 
> Comments are welcome. I'd like to get this in for the 4.12 kernel as
> this is a missing piece needed to integrate CEC drivers.
> 
> Regards,
> 
>   Hans
> 
> Changes since v4:
> - Dropped EDID/ELD/connect/disconnect support. Instead, just report the
>   CEC physical address (and use INVALID when disconnecting).
> - Since this is now completely CEC specific, move it to drivers/media
>   and rename to cec-notifier.
> - Drop block_notifier. Instead just set a callback for the notifier.
> - Use 'hdmi-phandle' in the bindings for both exynos and sti. So no
>   vendor prefix and 'hdmi-phandle' instead of 'hdmi-handle'.
> - Make struct cec_notifier opaque. Add a helper function to get the
>   physical address from a cec_notifier struct.
> - Provide dummy functions in cec-notifier.h so it can be used when
>   CONFIG_MEDIA_CEC_NOTIFIER is undefined.
> - Don't select the CEC notifier in the HDMI drivers. It should only
>   be enabled by actual CEC drivers.

I just quickly scaned through it, but this seems to address all my
concerns fully. Thanks for respinning. On the entire pile (or just the
core cec notifier bits):

Acked-by: Daniel Vetter 

> 
> Changes since v3:
> - Added the STI patches
> - Split the exynos4 binding patches in one for documentation and one
>   for the dts change itself, also use the correct subject and CC to
>   the correct mailinglists (I hope  )
> 
> Changes since v2:
> - Split off the dts changes of the s5p-cec patch into a separate patch
> - Renamed HPD_NOTIFIERS to HPD_NOTIFIER to be consistent with the name
>   of the source.
> 
> Changes since v1:
> 
> Renamed HDMI notifier to HPD (hotplug detect) notifier since this code is
> not HDMI specific, but is interesting for any video source that has to
> deal with hotplug detect and EDID/ELD (HDMI, DVI, VGA, DP, ).
> Only the use with CEC adapters is HDMI specific, but the HPD notifier
> is more generic.
> 
> 
> 
> 
> Benjamin Gaignard (4):
>   sti: hdmi: add CEC notifier support
>   stih-cec.txt: document new hdmi phandle
>   stih-cec: add CEC notifier support
>   arm: sti: update sti-cec for CEC notifier support
> 
> Hans Verkuil (7):
>   cec-edid: rename cec_get_edid_phys_addr
>   media: add CEC notifier support
>   cec: integrate CEC notifier support
>   exynos_hdmi: add CEC notifier support
>   ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi
>   s5p-cec.txt: document the HDMI controller phandle
>   s5p-cec: add cec-notifier support, move out of staging
> 
>  .../devicetree/bindings/media/s5p-cec.txt  |   2 +
>  .../devicetree/bindings/media/stih-cec.txt |   2 +
>  MAINTAINERS|   4 +-
>  arch/arm/boot/dts/exynos4.dtsi |   1 +
>  arch/arm/boot/dts/stih407-family.dtsi  |  12 ---
>  arch/arm/boot/dts/stih410.dtsi |  13 +++
>  drivers/gpu/drm/exynos/exynos_hdmi.c   |  20 +++-
>  drivers/gpu/drm/sti/sti_hdmi.c |  11 ++
>  drivers/gpu/drm/sti/sti_hdmi.h |   3 +
>  drivers/media/Kconfig  |   3 +
>  drivers/media/Makefile |   4 +
>  drivers/media/cec-edid.c   |  15 ++-
>  drivers/media/cec-notifier.c   | 116 
> +
>  drivers/media/cec/cec-core.c   |  21 
>  drivers/media/i2c/adv7511.c 

Re: [PATCH v2] staging: media: atomisp: Fix style. remove space before ',' and convert to tabs.

[Alan Cox]

On Wed, 2017-03-29 at 09:57 -0700, Daniel Cashman wrote:
> From: Dan Cashman 
> 
> Signed-off-by: Dan Cashman 


As the TODO asks - please no whitespace cleanups yet. They make it
harder to keep other cleanups that fix (or mostly remove) code
applying.

Nothing wrong with the patch otherwise - but it should also have
something in the commit message.

Alan

[PATCH v2] staging: media: atomisp: Fix style. remove space before ',' and convert to tabs.

[Daniel Cashman]

From: Dan Cashman 

Signed-off-by: Dan Cashman 
---
 drivers/staging/media/atomisp/i2c/ap1302.c | 4 ++--
 drivers/staging/media/atomisp/i2c/gc0310.c | 2 +-
 drivers/staging/media/atomisp/i2c/gc2235.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/ap1302.c 
b/drivers/staging/media/atomisp/i2c/ap1302.c
index bacffbe..8432ee9 100644
--- a/drivers/staging/media/atomisp/i2c/ap1302.c
+++ b/drivers/staging/media/atomisp/i2c/ap1302.c
@@ -606,8 +606,8 @@ static s32 ap1302_try_mbus_fmt_locked(struct v4l2_subdev 
*sd,
 
 
 static int ap1302_get_fmt(struct v4l2_subdev *sd,
-struct v4l2_subdev_pad_config *cfg,
-struct v4l2_subdev_format *format)
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *format)
 
 {
 struct v4l2_mbus_framefmt *fmt = >format;
diff --git a/drivers/staging/media/atomisp/i2c/gc0310.c 
b/drivers/staging/media/atomisp/i2c/gc0310.c
index add8b90..1ec616a 100644
--- a/drivers/staging/media/atomisp/i2c/gc0310.c
+++ b/drivers/staging/media/atomisp/i2c/gc0310.c
@@ -54,7 +54,7 @@ static int gc0310_read_reg(struct i2c_client *client,
return -EINVAL;
}
 
-   memset(msg, 0 , sizeof(msg));
+   memset(msg, 0, sizeof(msg));
 
msg[0].addr = client->addr;
msg[0].flags = 0;
diff --git a/drivers/staging/media/atomisp/i2c/gc2235.c 
b/drivers/staging/media/atomisp/i2c/gc2235.c
index 9b41023..50f4317 100644
--- a/drivers/staging/media/atomisp/i2c/gc2235.c
+++ b/drivers/staging/media/atomisp/i2c/gc2235.c
@@ -55,7 +55,7 @@ static int gc2235_read_reg(struct i2c_client *client,
return -EINVAL;
}
 
-   memset(msg, 0 , sizeof(msg));
+   memset(msg, 0, sizeof(msg));
 
msg[0].addr = client->addr;
msg[0].flags = 0;
-- 
2.7.4

[PATCH v3 12/13] [media] ddbridge: add i2c_read_regs()

[Daniel Scheller]

From: Daniel Scheller 

Adds new i2c_read_regs() function and make i2c_read_reg() wrap into this
with len=1. Required for the tuner_tda18212_ping() and XO2 handling
functions (part of the Sony CXD28xx support patch series).

Signed-off-by: Daniel Scheller 
---
 drivers/media/pci/ddbridge/ddbridge-core.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c 
b/drivers/media/pci/ddbridge/ddbridge-core.c
index 340cff0..acb9cbe 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -54,15 +54,21 @@ static int i2c_read(struct i2c_adapter *adapter, u8 adr, u8 
*val)
return (i2c_transfer(adapter, msgs, 1) == 1) ? 0 : -1;
 }
 
-static int i2c_read_reg(struct i2c_adapter *adapter, u8 adr, u8 reg, u8 *val)
+static int i2c_read_regs(struct i2c_adapter *adapter,
+u8 adr, u8 reg, u8 *val, u8 len)
 {
struct i2c_msg msgs[2] = {{.addr = adr,  .flags = 0,
   .buf  = , .len   = 1 },
  {.addr = adr,  .flags = I2C_M_RD,
-  .buf  = val,  .len   = 1 } };
+  .buf  = val,  .len   = len } };
return (i2c_transfer(adapter, msgs, 2) == 2) ? 0 : -1;
 }
 
+static int i2c_read_reg(struct i2c_adapter *adapter, u8 adr, u8 reg, u8 *val)
+{
+   return i2c_read_regs(adapter, adr, reg, val, 1);
+}
+
 static int i2c_read_reg16(struct i2c_adapter *adapter, u8 adr,
  u16 reg, u8 *val)
 {
-- 
2.10.2

[PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware

[Daniel Scheller]

From: Daniel Scheller 

Third iteration of the DD CineCTv6/FlexCT support patches with mostly
all things cleaned up that popped up so far. Obsoletes V1 and V2 series.

These patches enhance the functionality of dvb-frontends/stv0367 to work
with Digital Devices hardware driven by the ST STV0367 demodulator chip
and adds probe & attach bits to ddbridge to make use of them, effectively
enabling full support for CineCTv6 PCIe bridges and (older) DuoFlex CT
addon modules.

While the stv0367 code basically works with the DD hardware (e.g. setup
of demodulation works for both -C and -T delivery systems), some bits
(mostly initialisation) have to be done differently. Also, the static
if_khz configuration is not sufficient as the TDA18212 tuner works at
different IF speeds depending on the delivery system and carrier
bandwidth, so functionality is added to read that speed from the tuner.

The most important part is the addition of register default tabs for
the DD boards, the DD demod initialisation code and the automated
operation mode switch (OFDM vs. QAM) to be able to provide both systems
in one DVB frontend. Everything else is provided by the existing code
or the existing code is enhanced where it didn't suffice. So instead
of duplicating the driver, the existing one is reused. Patches are
laid out in a way to add each enhancement in small increments so they
should be fairly easy to review.

A note on the i2c_gatectrl flag: In the meantime (since v1) I got
clarification why this is needed (reception issues), so I'd prefer to
not diverge from that behaviour to not cause issues for anyone.

Checkpatch complains about some minor style issues, however the patches
were cleaned up beforehand and - where it still complains - match the
rest of the code style throughout the respective files.

In patches where code parts have been picked from other places, proper
credits to the original author is given and permissions where granted
beforehand.

Resulting STV0367/DD support was successfully tested with TVHeadend
and VDR setups by some users, with -C and -T combinations and two+four
port tuner setups (CTv6 with and without attached CT modules). I even
received some more very positive results on this since posting V1.

Apologizes if anything regarding the patch submission is/went wrong,
as this is my first time contribution to OSS via patch emails.

I'd appreciate any comments or even reviews on this to see if the way
the device support is done is acceptable at all, and how to proceed with
this. Having this as part of the 4.12 merge window would ofc be great.

Changes from v2 to v3:
 - refactored tda18212 ping in ddbridge which now even works, added
   i2c_read_regs for this (which is also required in another series)
   and wrapped i2c_read_reg to this
 - missing curly braces added as complained by the kbuild test bot
 - read_status() moved before get_frontend() for further signal stats
   readout (another series)
 - removed superfluous chip_id readout
 - added missing kfree(cab_state) to error cleanup in ddb_attach()
 - "invalid symbol rate" message changed from pr_err to printk to
   match the rest of the file

Changes from v1 to v2:
 - tda18212 modification/hack removed and implemented into ddbridge
   where it shouldn't harm but still is needed due to HW quirks
 - symbolrate_min/max added to dvb_frontend_ops
 - updated commit message body of the i2c_gatectrl flag patch (1/12) so
   it is more clear why this is needed and relevant, updated commit
   message body of 12/12 (ddbridge patch) aswell

Daniel Scheller (13):
  [media] dvb-frontends/stv0367: add flag to make i2c_gatectrl optional
  [media] dvb-frontends/stv0367: print CPAMP status only if stv_debug is
enabled
  [media] dvb-frontends/stv0367: refactor defaults table handling
  [media] dvb-frontends/stv0367: move out tables, support multiple tab
variants
  [media] dvb-frontends/stv0367: make PLLSETUP a function, add 58MHz IC
speed
  [media] dvb-frontends/stv0367: make full reinit on set_frontend()
optional
  [media] dvb-frontends/stv0367: support reading if_khz from tuner
config
  [media] dvb-frontends/stv0367: selectable QAM FEC Lock status register
  [media] dvb-frontends/stv0367: fix symbol rate conditions in
cab_SetQamSize()
  [media] dvb-frontends/stv0367: add defaults for use w/DD-branded
devices
  [media] dvb-frontends/stv0367: add Digital Devices compatibility
  [media] ddbridge: add i2c_read_regs()
  [media] ddbridge: support STV0367-based cards and modules

 drivers/media/dvb-frontends/stv0367.c  | 1168 ++---
 drivers/media/dvb-frontends/stv0367.h  |   13 +
 drivers/media/dvb-frontends/stv0367_defs.h | 1301 
 drivers/media/dvb-frontends/stv0367_regs.h |4 -
 drivers/media/pci/ddbridge/Kconfig |3 +
 drivers/media/pci/ddbridge/ddbridge-core.c |  168 +++-
 drivers/media/pci/ddbridge/ddbridge.h  |1 +
 7 files changed, 1943 

[PATCH v3 09/13] [media] dvb-frontends/stv0367: fix symbol rate conditions in cab_SetQamSize()

[Daniel Scheller]

From: Daniel Scheller 

The values used for comparing symbol rates and the resulting conditional
reg writes seem wrong (rates multiplied by ten), so fix those values.
While this doesn't seem to influence operation, it should be fixed anyway.

Signed-off-by: Daniel Scheller 
---
 drivers/media/dvb-frontends/stv0367.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv0367.c 
b/drivers/media/dvb-frontends/stv0367.c
index fb41c7b..ffc046a 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -1838,11 +1838,11 @@ static enum stv0367cab_mod stv0367cab_SetQamSize(struct 
stv0367_state *state,
case FE_CAB_MOD_QAM64:
stv0367_writereg(state, R367CAB_IQDEM_ADJ_AGC_REF, 0x82);
stv0367_writereg(state, R367CAB_AGC_PWR_REF_L, 0x5a);
-   if (SymbolRate > 4500) {
+   if (SymbolRate > 450) {
stv0367_writereg(state, R367CAB_FSM_STATE, 0xb0);
stv0367_writereg(state, R367CAB_EQU_CTR_LPF_GAIN, 0xc1);
stv0367_writereg(state, R367CAB_EQU_CRL_LPF_GAIN, 0xa5);
-   } else if (SymbolRate > 2500) {
+   } else if (SymbolRate > 250) {
stv0367_writereg(state, R367CAB_FSM_STATE, 0xa0);
stv0367_writereg(state, R367CAB_EQU_CTR_LPF_GAIN, 0xc1);
stv0367_writereg(state, R367CAB_EQU_CRL_LPF_GAIN, 0xa6);
@@ -1860,9 +1860,9 @@ static enum stv0367cab_mod stv0367cab_SetQamSize(struct 
stv0367_state *state,
stv0367_writereg(state, R367CAB_AGC_PWR_REF_L, 0x76);
stv0367_writereg(state, R367CAB_FSM_STATE, 0x90);
stv0367_writereg(state, R367CAB_EQU_CTR_LPF_GAIN, 0xb1);
-   if (SymbolRate > 4500)
+   if (SymbolRate > 450)
stv0367_writereg(state, R367CAB_EQU_CRL_LPF_GAIN, 0xa7);
-   else if (SymbolRate > 2500)
+   else if (SymbolRate > 250)
stv0367_writereg(state, R367CAB_EQU_CRL_LPF_GAIN, 0xa6);
else
stv0367_writereg(state, R367CAB_EQU_CRL_LPF_GAIN, 0x97);
@@ -1875,9 +1875,9 @@ static enum stv0367cab_mod stv0367cab_SetQamSize(struct 
stv0367_state *state,
stv0367_writereg(state, R367CAB_IQDEM_ADJ_AGC_REF, 0x94);
stv0367_writereg(state, R367CAB_AGC_PWR_REF_L, 0x5a);
stv0367_writereg(state, R367CAB_FSM_STATE, 0xa0);
-   if (SymbolRate > 4500)
+   if (SymbolRate > 450)
stv0367_writereg(state, R367CAB_EQU_CTR_LPF_GAIN, 0xc1);
-   else if (SymbolRate > 2500)
+   else if (SymbolRate > 250)
stv0367_writereg(state, R367CAB_EQU_CTR_LPF_GAIN, 0xc1);
else
stv0367_writereg(state, R367CAB_EQU_CTR_LPF_GAIN, 0xd1);
-- 
2.10.2

[PATCH v3 10/13] [media] dvb-frontends/stv0367: add defaults for use w/DD-branded devices

[Daniel Scheller]

From: Daniel Scheller 

Digital Devices uses defaults tables in their stv0367dd demod driver
variant which differ in a few registers, at least enough that no stable
operation can be provided with the tables already present in the driver
(init succeeds and DVB reception works but at least when the driver is
reloaded using rmmod/modprobe, the demod goes into a crashed state in a
way it doesn't react on any I2C command anymore, while even more
side-effects may occur), so there's a good reason to better have another
set of defaults.

Defaults originating from the stv0367dd driver. Permission to reuse them
was formally granted by Ralph Metzler .

Signed-off-by: Daniel Scheller 
---
 drivers/media/dvb-frontends/stv0367_defs.h | 610 -
 1 file changed, 609 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/stv0367_defs.h 
b/drivers/media/dvb-frontends/stv0367_defs.h
index 53faad6..277d297 100644
--- a/drivers/media/dvb-frontends/stv0367_defs.h
+++ b/drivers/media/dvb-frontends/stv0367_defs.h
@@ -25,7 +25,8 @@
 #include "stv0367_regs.h"
 
 #define STV0367_DEFTAB_GENERIC 0
-#define STV0367_DEFTAB_MAX 1
+#define STV0367_DEFTAB_DDB 1
+#define STV0367_DEFTAB_MAX 2
 
 #define STV0367_TAB_TER0
 #define STV0367_TAB_CAB1
@@ -680,6 +681,611 @@ static const struct st_register def0367cab[] = {
{0x,0x00},
 };
 
+/**
+ *
+ * Defaults / Tables for Digital Devices C/T Cine/Flex devices
+ *
+ **/
+
+static const struct st_register def0367dd_ofdm[] = {
+   {R367TER_AGC2MAX,0xff},
+   {R367TER_AGC2MIN,0x00},
+   {R367TER_AGC1MAX,0xff},
+   {R367TER_AGC1MIN,0x00},
+   {R367TER_AGCR,   0xbc},
+   {R367TER_AGC2TH, 0x00},
+   {R367TER_AGCCTRL1,   0x85},
+   {R367TER_AGCCTRL2,   0x1f},
+   {R367TER_AGC1VAL1,   0x00},
+   {R367TER_AGC1VAL2,   0x00},
+   {R367TER_AGC2VAL1,   0x6f},
+   {R367TER_AGC2VAL2,   0x05},
+   {R367TER_AGC2PGA,0x00},
+   {R367TER_OVF_RATE1,  0x00},
+   {R367TER_OVF_RATE2,  0x00},
+   {R367TER_GAIN_SRC1,  0x2b},
+   {R367TER_GAIN_SRC2,  0x04},
+   {R367TER_INC_DEROT1, 0x55},
+   {R367TER_INC_DEROT2, 0x55},
+   {R367TER_PPM_CPAMP_DIR,  0x2c},
+   {R367TER_PPM_CPAMP_INV,  0x00},
+   {R367TER_FREESTFE_1, 0x00},
+   {R367TER_FREESTFE_2, 0x1c},
+   {R367TER_DCOFFSET,   0x00},
+   {R367TER_EN_PROCESS, 0x05},
+   {R367TER_SDI_SMOOTHER,   0x80},
+   {R367TER_FE_LOOP_OPEN,   0x1c},
+   {R367TER_FREQOFF1,   0x00},
+   {R367TER_FREQOFF2,   0x00},
+   {R367TER_FREQOFF3,   0x00},
+   {R367TER_TIMOFF1,0x00},
+   {R367TER_TIMOFF2,0x00},
+   {R367TER_EPQ,0x02},
+   {R367TER_EPQAUTO,0x01},
+   {R367TER_SYR_UPDATE, 0xf5},
+   {R367TER_CHPFREE,0x00},
+   {R367TER_PPM_STATE_MAC,  0x23},
+   {R367TER_INR_THRESHOLD,  0xff},
+   {R367TER_EPQ_TPS_ID_CELL,0xf9},
+   {R367TER_EPQ_CFG,0x00},
+   {R367TER_EPQ_STATUS, 0x01},
+   {R367TER_AUTORELOCK, 0x81},
+   {R367TER_BER_THR_VMSB,   0x00},
+   {R367TER_BER_THR_MSB,0x00},
+   {R367TER_BER_THR_LSB,0x00},
+   {R367TER_CCD,0x83},
+   {R367TER_SPECTR_CFG, 0x00},
+   {R367TER_CHC_DUMMY,  0x18},
+   {R367TER_INC_CTL,0x88},
+   {R367TER_INCTHRES_COR1,  0xb4},
+   {R367TER_INCTHRES_COR2,  0x96},
+   {R367TER_INCTHRES_DET1,  0x0e},
+   {R367TER_INCTHRES_DET2,  0x11},
+   {R367TER_IIR_CELLNB, 0x8d},
+   {R367TER_IIRCX_COEFF1_MSB,   0x00},
+   {R367TER_IIRCX_COEFF1_LSB,   0x00},
+   {R367TER_IIRCX_COEFF2_MSB,   0x09},
+   {R367TER_IIRCX_COEFF2_LSB,   0x18},
+   {R367TER_IIRCX_COEFF3_MSB,   0x14},
+   {R367TER_IIRCX_COEFF3_LSB,   0x9c},
+   {R367TER_IIRCX_COEFF4_MSB,   0x00},
+   {R367TER_IIRCX_COEFF4_LSB,   0x00},
+   {R367TER_IIRCX_COEFF5_MSB,   0x36},
+   {R367TER_IIRCX_COEFF5_LSB,   0x42},
+   {R367TER_FEPATH_CFG, 0x00},
+   {R367TER_PMC1_FUNC,  0x65},
+   {R367TER_PMC1_FOR,   0x00},
+   {R367TER_PMC2_FUNC,  0x00},
+   {R367TER_STATUS_ERR_DA,  0xe0},
+   {R367TER_DIG_AGC_R,

[PATCH v3 13/13] [media] ddbridge: support STV0367-based cards and modules

[Daniel Scheller]

From: Daniel Scheller 

This adds detection and activation for STV0367-based tuner hardware (namely
CineCTv6 bridge cards and older DuoFlex CT addon modules). Utilises the
extended stv0367 demod driver.

TDA18212 i2c_client/regmap-api code was originally implemented by
Antti Palosaari  in a variant to update the ddbridge code
from the vendor dddvb package (formal ack for these parts received).
Original patch at [1].

When boards with STV0367 are cold-started, there might be issues with the
I2C gate, causing the TDA18212 detection/probe to fail. For these demods,
a workaround (tuner_tda18212_ping) is implemented which probes the tuner
twice on this hardware constellation which will resolve the problem and
put all components into a working state. Other demod/port types won't be
retried.

Signed-off-by: Daniel Scheller 

[1] https://patchwork.linuxtv.org/patch/25146/
---
 drivers/media/pci/ddbridge/Kconfig |   3 +
 drivers/media/pci/ddbridge/ddbridge-core.c | 158 -
 drivers/media/pci/ddbridge/ddbridge.h  |   1 +
 3 files changed, 161 insertions(+), 1 deletion(-)

diff --git a/drivers/media/pci/ddbridge/Kconfig 
b/drivers/media/pci/ddbridge/Kconfig
index 44e5dc1..16ede23 100644
--- a/drivers/media/pci/ddbridge/Kconfig
+++ b/drivers/media/pci/ddbridge/Kconfig
@@ -6,6 +6,8 @@ config DVB_DDBRIDGE
select DVB_STV090x if MEDIA_SUBDRV_AUTOSELECT
select DVB_DRXK if MEDIA_SUBDRV_AUTOSELECT
select DVB_TDA18271C2DD if MEDIA_SUBDRV_AUTOSELECT
+   select DVB_STV0367 if MEDIA_SUBDRV_AUTOSELECT
+   select MEDIA_TUNER_TDA18212 if MEDIA_SUBDRV_AUTOSELECT
---help---
  Support for cards with the Digital Devices PCI express bridge:
  - Octopus PCIe Bridge
@@ -14,5 +16,6 @@ config DVB_DDBRIDGE
  - DuoFlex S2 Octopus
  - DuoFlex CT Octopus
  - cineS2(v6)
+ - CineCTv6 and DuoFlex CT (STV0367-based)
 
  Say Y if you own such a card and want to use it.
diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c 
b/drivers/media/pci/ddbridge/ddbridge-core.c
index acb9cbe..12f5aa3 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -39,6 +39,9 @@
 #include "stv090x.h"
 #include "lnbh24.h"
 #include "drxk.h"
+#include "stv0367.h"
+#include "stv0367_priv.h"
+#include "tda18212.h"
 
 DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 
@@ -615,6 +618,120 @@ static int tuner_attach_tda18271(struct ddb_input *input)
 
/**/
 
/**/
 
+static struct stv0367_config ddb_stv0367_config[] = {
+   {
+   .demod_address = 0x1f,
+   .xtal = 2700,
+   .if_khz = 0,
+   .if_iq_mode = FE_TER_NORMAL_IF_TUNER,
+   .ts_mode = STV0367_SERIAL_PUNCT_CLOCK,
+   .clk_pol = STV0367_CLOCKPOLARITY_DEFAULT,
+   }, {
+   .demod_address = 0x1e,
+   .xtal = 2700,
+   .if_khz = 0,
+   .if_iq_mode = FE_TER_NORMAL_IF_TUNER,
+   .ts_mode = STV0367_SERIAL_PUNCT_CLOCK,
+   .clk_pol = STV0367_CLOCKPOLARITY_DEFAULT,
+   },
+};
+
+static int demod_attach_stv0367(struct ddb_input *input)
+{
+   struct i2c_adapter *i2c = >port->i2c->adap;
+
+   /* attach frontend */
+   input->fe = dvb_attach(stv0367ddb_attach,
+   _stv0367_config[(input->nr & 1)], i2c);
+
+   if (!input->fe) {
+   printk(KERN_ERR "stv0367ddb_attach failed (not found?)\n");
+   return -ENODEV;
+   }
+
+   input->fe->sec_priv = input;
+   input->gate_ctrl = input->fe->ops.i2c_gate_ctrl;
+   input->fe->ops.i2c_gate_ctrl = drxk_gate_ctrl;
+
+   return 0;
+}
+
+static int tuner_tda18212_ping(struct ddb_input *input, unsigned short adr)
+{
+   struct i2c_adapter *adapter = >port->i2c->adap;
+   u8 tda_id[2];
+   u8 subaddr = 0x00;
+
+   printk(KERN_DEBUG "stv0367-tda18212 tuner ping\n");
+   if (input->fe->ops.i2c_gate_ctrl)
+   input->fe->ops.i2c_gate_ctrl(input->fe, 1);
+
+   if (i2c_read_regs(adapter, adr, subaddr, tda_id, sizeof(tda_id)) < 0)
+   printk(KERN_DEBUG "tda18212 ping 1 fail\n");
+   if (i2c_read_regs(adapter, adr, subaddr, tda_id, sizeof(tda_id)) < 0)
+   printk(KERN_DEBUG "tda18212 ping 2 fail\n");
+
+   if (input->fe->ops.i2c_gate_ctrl)
+   input->fe->ops.i2c_gate_ctrl(input->fe, 0);
+
+   return 0;
+}
+
+static int tuner_attach_tda18212(struct ddb_input *input, u32 porttype)
+{
+   struct i2c_adapter *adapter = >port->i2c->adap;
+   struct i2c_client *client;
+   struct tda18212_config config = {
+   .fe = input->fe,
+   .if_dvbt_6 = 3550,
+   .if_dvbt_7 = 

[PATCH v3 04/13] [media] dvb-frontends/stv0367: move out tables, support multiple tab variants

[Daniel Scheller]

From: Daniel Scheller 

Move the *ter and *cab st_register tables into a separate header file and
additionally organize them via a multidimensional array, allowing to add
more tables with differing init values, and also prepare for a base init
table which should contain general setup values. Also add a state var to
store the table triplet to be used.

Also fixes three minor style problems reported by checkpatch.

Signed-off-by: Daniel Scheller 
---
 drivers/media/dvb-frontends/stv0367.c  | 658 +--
 drivers/media/dvb-frontends/stv0367_defs.h | 693 +
 2 files changed, 701 insertions(+), 650 deletions(-)
 create mode 100644 drivers/media/dvb-frontends/stv0367_defs.h

diff --git a/drivers/media/dvb-frontends/stv0367.c 
b/drivers/media/dvb-frontends/stv0367.c
index 5ed52ec..5b52673 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -26,6 +26,7 @@
 #include 
 
 #include "stv0367.h"
+#include "stv0367_defs.h"
 #include "stv0367_regs.h"
 #include "stv0367_priv.h"
 
@@ -91,462 +92,7 @@ struct stv0367_state {
struct stv0367ter_state *ter_state;
/* flags for operation control */
u8 use_i2c_gatectrl;
-};
-
-struct st_register {
-   u16 addr;
-   u8  value;
-};
-
-/* values for STV4100 XTAL=30M int clk=53.125M*/
-static const struct st_register def0367ter[] = {
-   {R367TER_ID,0x60},
-   {R367TER_I2CRPT,0xa0},
-   /* {R367TER_I2CRPT, 0x22},*/
-   {R367TER_TOPCTRL,   0x00},/* for xc5000; was 0x02 */
-   {R367TER_IOCFG0,0x40},
-   {R367TER_DAC0R, 0x00},
-   {R367TER_IOCFG1,0x00},
-   {R367TER_DAC1R, 0x00},
-   {R367TER_IOCFG2,0x62},
-   {R367TER_SDFR,  0x00},
-   {R367TER_STATUS,0xf8},
-   {R367TER_AUX_CLK,   0x0a},
-   {R367TER_FREESYS1,  0x00},
-   {R367TER_FREESYS2,  0x00},
-   {R367TER_FREESYS3,  0x00},
-   {R367TER_GPIO_CFG,  0x55},
-   {R367TER_GPIO_CMD,  0x00},
-   {R367TER_AGC2MAX,   0xff},
-   {R367TER_AGC2MIN,   0x00},
-   {R367TER_AGC1MAX,   0xff},
-   {R367TER_AGC1MIN,   0x00},
-   {R367TER_AGCR,  0xbc},
-   {R367TER_AGC2TH,0x00},
-   {R367TER_AGC12C,0x00},
-   {R367TER_AGCCTRL1,  0x85},
-   {R367TER_AGCCTRL2,  0x1f},
-   {R367TER_AGC1VAL1,  0x00},
-   {R367TER_AGC1VAL2,  0x00},
-   {R367TER_AGC2VAL1,  0x6f},
-   {R367TER_AGC2VAL2,  0x05},
-   {R367TER_AGC2PGA,   0x00},
-   {R367TER_OVF_RATE1, 0x00},
-   {R367TER_OVF_RATE2, 0x00},
-   {R367TER_GAIN_SRC1, 0xaa},/* for xc5000; was 0x2b */
-   {R367TER_GAIN_SRC2, 0xd6},/* for xc5000; was 0x04 */
-   {R367TER_INC_DEROT1,0x55},
-   {R367TER_INC_DEROT2,0x55},
-   {R367TER_PPM_CPAMP_DIR, 0x2c},
-   {R367TER_PPM_CPAMP_INV, 0x00},
-   {R367TER_FREESTFE_1,0x00},
-   {R367TER_FREESTFE_2,0x1c},
-   {R367TER_DCOFFSET,  0x00},
-   {R367TER_EN_PROCESS,0x05},
-   {R367TER_SDI_SMOOTHER,  0x80},
-   {R367TER_FE_LOOP_OPEN,  0x1c},
-   {R367TER_FREQOFF1,  0x00},
-   {R367TER_FREQOFF2,  0x00},
-   {R367TER_FREQOFF3,  0x00},
-   {R367TER_TIMOFF1,   0x00},
-   {R367TER_TIMOFF2,   0x00},
-   {R367TER_EPQ,   0x02},
-   {R367TER_EPQAUTO,   0x01},
-   {R367TER_SYR_UPDATE,0xf5},
-   {R367TER_CHPFREE,   0x00},
-   {R367TER_PPM_STATE_MAC, 0x23},
-   {R367TER_INR_THRESHOLD, 0xff},
-   {R367TER_EPQ_TPS_ID_CELL, 0xf9},
-   {R367TER_EPQ_CFG,   0x00},
-   {R367TER_EPQ_STATUS,0x01},
-   {R367TER_AUTORELOCK,0x81},
-   {R367TER_BER_THR_VMSB,  0x00},
-   {R367TER_BER_THR_MSB,   0x00},
-   {R367TER_BER_THR_LSB,   0x00},
-   {R367TER_CCD,   0x83},
-   {R367TER_SPECTR_CFG,0x00},
-   {R367TER_CHC_DUMMY, 0x18},
-   {R367TER_INC_CTL,   0x88},
-   {R367TER_INCTHRES_COR1, 0xb4},
-   {R367TER_INCTHRES_COR2, 0x96},
-   {R367TER_INCTHRES_DET1, 0x0e},
-   {R367TER_INCTHRES_DET2, 0x11},
-   {R367TER_IIR_CELLNB,0x8d},
-   {R367TER_IIRCX_COEFF1_MSB, 0x00},
-   {R367TER_IIRCX_COEFF1_LSB, 0x00},
-   {R367TER_IIRCX_COEFF2_MSB, 0x09},
-   {R367TER_IIRCX_COEFF2_LSB, 0x18},
-   {R367TER_IIRCX_COEFF3_MSB, 0x14},
-   {R367TER_IIRCX_COEFF3_LSB, 0x9c},
-   {R367TER_IIRCX_COEFF4_MSB, 0x00},
-   {R367TER_IIRCX_COEFF4_LSB, 0x00},
-   {R367TER_IIRCX_COEFF5_MSB, 0x36},
-   {R367TER_IIRCX_COEFF5_LSB, 0x42},
-   {R367TER_FEPATH_CFG,0x00},
-   {R367TER_PMC1_FUNC, 0x65},
-   {R367TER_PMC1_FOR,  0x00},
-   {R367TER_PMC2_FUNC, 0x00},
-   {R367TER_STATUS_ERR_DA, 0xe0},
-   {R367TER_DIG_AGC_R, 0xfe},
-  

[PATCH v3 06/13] [media] dvb-frontends/stv0367: make full reinit on set_frontend() optional

[Daniel Scheller]

From: Daniel Scheller 

Every time dvb_frontend_ops.set_frontend() is called, an almost full reinit
of the demodulator will be performed. While this might cause a slight delay
when switching channels due to all involved tables being rewritten, it can
even be dangerous in certain causes in that the demod may lock up and
requires to be powercycled (this can happen on Digital Devices hardware).
So this adds a flag if it should be done, and to not change behaviour with
existing card support, it'll be enabled in all cases.

Signed-off-by: Daniel Scheller 
---
 drivers/media/dvb-frontends/stv0367.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv0367.c 
b/drivers/media/dvb-frontends/stv0367.c
index da10d9a..9370afa 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -93,6 +93,7 @@ struct stv0367_state {
/* flags for operation control */
u8 use_i2c_gatectrl;
u8 deftabs;
+   u8 reinit_on_setfrontend;
 };
 
 #define RF_LOOKUP_TABLE_SIZE  31
@@ -1217,7 +1218,8 @@ static int stv0367ter_set_frontend(struct dvb_frontend 
*fe)
s8 num_trials, index;
u8 SenseTrials[] = { INVERSION_ON, INVERSION_OFF };
 
-   stv0367ter_init(fe);
+   if (state->reinit_on_setfrontend)
+   stv0367ter_init(fe);
 
if (fe->ops.tuner_ops.set_params) {
if (state->use_i2c_gatectrl && fe->ops.i2c_gate_ctrl)
@@ -1717,6 +1719,7 @@ struct dvb_frontend *stv0367ter_attach(const struct 
stv0367_config *config,
/* demod operation options */
state->use_i2c_gatectrl = 1;
state->deftabs = STV0367_DEFTAB_GENERIC;
+   state->reinit_on_setfrontend = 1;
 
dprintk("%s: chip_id = 0x%x\n", __func__, state->chip_id);
 
@@ -2511,7 +2514,8 @@ static int stv0367cab_set_frontend(struct dvb_frontend 
*fe)
break;
}
 
-   stv0367cab_init(fe);
+   if (state->reinit_on_setfrontend)
+   stv0367cab_init(fe);
 
/* Tuner Frequency Setting */
if (fe->ops.tuner_ops.set_params) {
@@ -2835,6 +2839,7 @@ struct dvb_frontend *stv0367cab_attach(const struct 
stv0367_config *config,
/* demod operation options */
state->use_i2c_gatectrl = 1;
state->deftabs = STV0367_DEFTAB_GENERIC;
+   state->reinit_on_setfrontend = 1;
 
dprintk("%s: chip_id = 0x%x\n", __func__, state->chip_id);
 
-- 
2.10.2

[PATCH v3 11/13] [media] dvb-frontends/stv0367: add Digital Devices compatibility

[Daniel Scheller]

From: Daniel Scheller 

This - in conjunction with the previous changes - makes it possible to use
the STV0367 DVB-C/T demodulator driver with Digital Devices hardware having
this demodulator soldered on them (namely CineCTv6 bridges and some earlier
DuoFlex CT addon modules).

The changes do the following:

- add a third *_attach function which will make use of a third frontend_ops
  struct which announces both -C and -T support (the same as with DD's own
  driver stv0367dd). This is necessary to support both delivery systems
  on one FE without having to do large conversions to VB2 or the need to
  select either -C or -T mode via modparams and the like. Additionally,
  the frontend_ops point to new "glue" functions which will then call into
  the existing functionality depending on the active delivery system/demod
  state (all used functionality works almost OOTB).
- Demod initialisation has been ported from stv0367dd. DD's driver always
  does a full init of both OFDM and QAM cores, with some additional things.
  The active delivery system is remembered and upon switch, the Demod will
  be reconfigured to work in OFDM or QAM mode (that's what the ddb_setup_XX
  functions are used for). Note that in QAM mode, the DD demods work with
  an IC speed of 58Mhz. It's not very good to perform full reinits upon
  Demod mode changes since in very rare occasions this can lead to the I2C
  interface or the whole Demod to crash, requiring a powercycle, thus the
  flag to perform full reinit is set to disabled.
- A little enum is added for named identifiers of the current Demod state.

Initialisation code/register writes originate from stv0367dd. Permission
to reuse was formally granted by Ralph Metzler .

Signed-off-by: Daniel Scheller 
---
 drivers/media/dvb-frontends/stv0367.c | 324 ++
 drivers/media/dvb-frontends/stv0367.h |  10 ++
 2 files changed, 334 insertions(+)

diff --git a/drivers/media/dvb-frontends/stv0367.c 
b/drivers/media/dvb-frontends/stv0367.c
index ffc046a..e726c2e 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -46,6 +46,8 @@ module_param_named(i2c_debug, i2cdebug, int, 0644);
} while (0)
/* DVB-C */
 
+enum active_demod_state { demod_none, demod_ter, demod_cab };
+
 struct stv0367cab_state {
enum stv0367_cab_signal_typestate;
u32 mclk;
@@ -96,6 +98,7 @@ struct stv0367_state {
u8 deftabs;
u8 reinit_on_setfrontend;
u8 auto_if_khz;
+   enum active_demod_state activedemod;
 };
 
 #define RF_LOOKUP_TABLE_SIZE  31
@@ -2880,6 +2883,327 @@ struct dvb_frontend *stv0367cab_attach(const struct 
stv0367_config *config,
 }
 EXPORT_SYMBOL(stv0367cab_attach);
 
+/*
+ * Functions for operation on Digital Devices hardware
+ */
+
+static void stv0367ddb_setup_ter(struct stv0367_state *state)
+{
+   stv0367_writereg(state, R367TER_DEBUG_LT4, 0x00);
+   stv0367_writereg(state, R367TER_DEBUG_LT5, 0x00);
+   stv0367_writereg(state, R367TER_DEBUG_LT6, 0x00); /* R367CAB_CTRL_1 */
+   stv0367_writereg(state, R367TER_DEBUG_LT7, 0x00); /* R367CAB_CTRL_2 */
+   stv0367_writereg(state, R367TER_DEBUG_LT8, 0x00);
+   stv0367_writereg(state, R367TER_DEBUG_LT9, 0x00);
+
+   /* Tuner Setup */
+   /* Buffer Q disabled, I Enabled, unsigned ADC */
+   stv0367_writereg(state, R367TER_ANADIGCTRL, 0x89);
+   stv0367_writereg(state, R367TER_DUAL_AD12, 0x04); /* ADCQ disabled */
+
+   /* Clock setup */
+   /* PLL bypassed and disabled */
+   stv0367_writereg(state, R367TER_ANACTRL, 0x0D);
+   stv0367_writereg(state, R367TER_TOPCTRL, 0x00); /* Set OFDM */
+
+   /* IC runs at 54 MHz with a 27 MHz crystal */
+   stv0367_pll_setup(state, STV0367_ICSPEED_53125, state->config->xtal);
+
+   msleep(50);
+   /* PLL enabled and used */
+   stv0367_writereg(state, R367TER_ANACTRL, 0x00);
+
+   state->activedemod = demod_ter;
+}
+
+static void stv0367ddb_setup_cab(struct stv0367_state *state)
+{
+   stv0367_writereg(state, R367TER_DEBUG_LT4, 0x00);
+   stv0367_writereg(state, R367TER_DEBUG_LT5, 0x01);
+   stv0367_writereg(state, R367TER_DEBUG_LT6, 0x06); /* R367CAB_CTRL_1 */
+   stv0367_writereg(state, R367TER_DEBUG_LT7, 0x03); /* R367CAB_CTRL_2 */
+   stv0367_writereg(state, R367TER_DEBUG_LT8, 0x00);
+   stv0367_writereg(state, R367TER_DEBUG_LT9, 0x00);
+
+   /* Tuner Setup */
+   /* Buffer Q disabled, I Enabled, signed ADC */
+   stv0367_writereg(state, R367TER_ANADIGCTRL, 0x8B);
+   /* ADCQ disabled */
+   stv0367_writereg(state, R367TER_DUAL_AD12, 0x04);
+
+   /* Clock setup */
+   /* PLL bypassed and disabled */
+   stv0367_writereg(state, R367TER_ANACTRL, 0x0D);
+   /* Set QAM */
+   stv0367_writereg(state, R367TER_TOPCTRL, 0x10);
+
+   /* IC runs at 58 MHz with a 27 MHz crystal */
+   

[PATCH v3 01/13] [media] dvb-frontends/stv0367: add flag to make i2c_gatectrl optional

[Daniel Scheller]

From: Daniel Scheller 

Some hardware and bridges (namely ddbridge) require that tuner access is
limited to one concurrent access and wrap i2c gate control with a
mutex_lock when attaching frontends. According to vendor information, this
is required as concurrent tuner reconfiguration can interfere each other
and at worst cause tuning fails or bad reception quality.

If the demod driver does gate_ctrl before setting up tuner parameters, and
the tuner does another I2C enable, it will deadlock forever when gate_ctrl
is wrapped into the mutex_lock. This adds a flag and a conditional before
triggering gate_ctrl in the demodulator driver.

Signed-off-by: Daniel Scheller 
---
 drivers/media/dvb-frontends/stv0367.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv0367.c 
b/drivers/media/dvb-frontends/stv0367.c
index fd49c43..fc80934 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -89,6 +89,8 @@ struct stv0367_state {
struct stv0367cab_state *cab_state;
/* DVB-T */
struct stv0367ter_state *ter_state;
+   /* flags for operation control */
+   u8 use_i2c_gatectrl;
 };
 
 struct st_register {
@@ -1827,10 +1829,10 @@ static int stv0367ter_set_frontend(struct dvb_frontend 
*fe)
stv0367ter_init(fe);
 
if (fe->ops.tuner_ops.set_params) {
-   if (fe->ops.i2c_gate_ctrl)
+   if (state->use_i2c_gatectrl && fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 1);
fe->ops.tuner_ops.set_params(fe);
-   if (fe->ops.i2c_gate_ctrl)
+   if (state->use_i2c_gatectrl && fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 0);
}
 
@@ -2321,6 +2323,9 @@ struct dvb_frontend *stv0367ter_attach(const struct 
stv0367_config *config,
state->fe.demodulator_priv = state;
state->chip_id = stv0367_readreg(state, 0xf000);
 
+   /* demod operation options */
+   state->use_i2c_gatectrl = 1;
+
dprintk("%s: chip_id = 0x%x\n", __func__, state->chip_id);
 
/* check if the demod is there */
@@ -3120,10 +3125,10 @@ static int stv0367cab_set_frontend(struct dvb_frontend 
*fe)
 
/* Tuner Frequency Setting */
if (fe->ops.tuner_ops.set_params) {
-   if (fe->ops.i2c_gate_ctrl)
+   if (state->use_i2c_gatectrl && fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 1);
fe->ops.tuner_ops.set_params(fe);
-   if (fe->ops.i2c_gate_ctrl)
+   if (state->use_i2c_gatectrl && fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 0);
}
 
@@ -3437,6 +3442,9 @@ struct dvb_frontend *stv0367cab_attach(const struct 
stv0367_config *config,
state->fe.demodulator_priv = state;
state->chip_id = stv0367_readreg(state, 0xf000);
 
+   /* demod operation options */
+   state->use_i2c_gatectrl = 1;
+
dprintk("%s: chip_id = 0x%x\n", __func__, state->chip_id);
 
/* check if the demod is there */
-- 
2.10.2

[PATCH v3 02/13] [media] dvb-frontends/stv0367: print CPAMP status only if stv_debug is enabled

[Daniel Scheller]

From: Daniel Scheller 

The CPAMP log lines generated in stv0367_ter_check_cpamp() are printed
everytime tuning succeeds or fails, quite cluttering the normal kernel log.
Use dprintk() instead of printk(KERN_ERR...) so that if the information is
needed, it'll be printed when the stv_debug modparam is enabled.

Signed-off-by: Daniel Scheller 
---
 drivers/media/dvb-frontends/stv0367.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv0367.c 
b/drivers/media/dvb-frontends/stv0367.c
index fc80934..0064d9d 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -1262,9 +1262,9 @@ stv0367_ter_signal_type stv0367ter_check_cpamp(struct 
stv0367_state *state,
dprintk("**last CPAMPvalue= %d at wd=%d\n", CPAMPvalue, wd);
if (CPAMPvalue < CPAMPMin) {
CPAMPStatus = FE_TER_NOCPAMP;
-   printk(KERN_ERR "CPAMP failed\n");
+   dprintk("%s: CPAMP failed\n", __func__);
} else {
-   printk(KERN_ERR "CPAMP OK !\n");
+   dprintk("%s: CPAMP OK !\n", __func__);
CPAMPStatus = FE_TER_CPAMPOK;
}
 
-- 
2.10.2

[PATCH v3 08/13] [media] dvb-frontends/stv0367: selectable QAM FEC Lock status register

[Daniel Scheller]

From: Daniel Scheller 

In some configurations (due to different PIN config, wiring or so), the
QAM FECLock might be signalled using a different register than
F367CAB_QAMFEC_LOCK (e.g. F367CAB_DESCR_SYNCSTATE on Digital Devices hw),
so make that register selectable.

Signed-off-by: Daniel Scheller 
---
 drivers/media/dvb-frontends/stv0367.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv0367.c 
b/drivers/media/dvb-frontends/stv0367.c
index 74fee3f..fb41c7b 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -57,6 +57,7 @@ struct stv0367cab_state {
u32 freq_khz;   /* found frequency (in kHz) */
u32 symbol_rate;/* found symbol rate (in Bds)   */
enum fe_spectral_inversion spect_inv; /* Spectrum Inversion */
+   u32 qamfec_status_reg;  /* status reg to poll for FEC Lock */
 };
 
 struct stv0367ter_state {
@@ -2145,7 +2146,8 @@ static int stv0367cab_read_status(struct dvb_frontend *fe,
 
*status = 0;
 
-   if (stv0367_readbits(state, F367CAB_QAMFEC_LOCK)) {
+   if (stv0367_readbits(state, (state->cab_state->qamfec_status_reg ?
+   state->cab_state->qamfec_status_reg : F367CAB_QAMFEC_LOCK))) {
*status |= FE_HAS_LOCK;
dprintk("%s: stv0367 has locked\n", __func__);
}
@@ -2410,7 +2412,9 @@ enum stv0367_cab_signal_type stv0367cab_algo(struct 
stv0367_state *state,
usleep_range(5000, 7000);
LockTime += 5;
QAMFEC_Lock = stv0367_readbits(state,
-   F367CAB_QAMFEC_LOCK);
+   (state->cab_state->qamfec_status_reg ?
+   state->cab_state->qamfec_status_reg :
+   F367CAB_QAMFEC_LOCK));
} while (!QAMFEC_Lock && (LockTime < FECTimeOut));
} else
QAMFEC_Lock = 0;
@@ -2849,6 +2853,7 @@ struct dvb_frontend *stv0367cab_attach(const struct 
stv0367_config *config,
state->i2c = i2c;
state->config = config;
cab_state->search_range = 28;
+   cab_state->qamfec_status_reg = F367CAB_QAMFEC_LOCK;
state->cab_state = cab_state;
state->fe.ops = stv0367cab_ops;
state->fe.demodulator_priv = state;
-- 
2.10.2

[PATCH v3 03/13] [media] dvb-frontends/stv0367: refactor defaults table handling

[Daniel Scheller]

From: Daniel Scheller 

Change defaults table writing so tables can be of dynamic length without
having to keep track of their lengths by adding and evaluating an end
marker (reg 0x), also move table writing to a dedicated function to
remove code duplication. Additionally mark st_register tables const since
they're used read-only.

Signed-off-by: Daniel Scheller 
---
 drivers/media/dvb-frontends/stv0367.c  | 30 --
 drivers/media/dvb-frontends/stv0367_regs.h |  4 
 2 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv0367.c 
b/drivers/media/dvb-frontends/stv0367.c
index 0064d9d..5ed52ec 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -99,7 +99,7 @@ struct st_register {
 };
 
 /* values for STV4100 XTAL=30M int clk=53.125M*/
-static struct st_register def0367ter[STV0367TER_NBREGS] = {
+static const struct st_register def0367ter[] = {
{R367TER_ID,0x60},
{R367TER_I2CRPT,0xa0},
/* {R367TER_I2CRPT, 0x22},*/
@@ -546,6 +546,7 @@ static struct st_register def0367ter[STV0367TER_NBREGS] = {
{R367TER_DEBUG_LT7, 0x00},
{R367TER_DEBUG_LT8, 0x00},
{R367TER_DEBUG_LT9, 0x00},
+   {0x,0x00},
 };
 
 #define RF_LOOKUP_TABLE_SIZE  31
@@ -573,7 +574,7 @@ static const s32 
stv0367cab_RF_LookUp2[RF_LOOKUP_TABLE2_SIZE][RF_LOOKUP_TABLE2_S
}
 };
 
-static struct st_register def0367cab[STV0367CAB_NBREGS] = {
+static const struct st_register def0367cab[] = {
{R367CAB_ID,0x60},
{R367CAB_I2CRPT,0xa0},
/*{R367CAB_I2CRPT,  0x22},*/
@@ -762,6 +763,7 @@ static struct st_register def0367cab[STV0367CAB_NBREGS] = {
{R367CAB_T_O_ID_1,  0x00},
{R367CAB_T_O_ID_2,  0x00},
{R367CAB_T_O_ID_3,  0x00},
+   {0x,0x00},
 };
 
 static
@@ -901,6 +903,20 @@ static u8 stv0367_getbits(u8 reg, u32 label)
return (reg & mask) >> pos;
 }
 #endif
+
+static void stv0367_write_table(struct stv0367_state *state,
+   const struct st_register *deftab)
+{
+   int i = 0;
+
+   while (1) {
+   if (!deftab[i].addr)
+   break;
+   stv0367_writereg(state, deftab[i].addr, deftab[i].value);
+   i++;
+   }
+}
+
 static int stv0367ter_gate_ctrl(struct dvb_frontend *fe, int enable)
 {
struct stv0367_state *state = fe->demodulator_priv;
@@ -1540,15 +1556,12 @@ static int stv0367ter_init(struct dvb_frontend *fe)
 {
struct stv0367_state *state = fe->demodulator_priv;
struct stv0367ter_state *ter_state = state->ter_state;
-   int i;
 
dprintk("%s:\n", __func__);
 
ter_state->pBER = 0;
 
-   for (i = 0; i < STV0367TER_NBREGS; i++)
-   stv0367_writereg(state, def0367ter[i].addr,
-   def0367ter[i].value);
+   stv0367_write_table(state, def0367ter);
 
switch (state->config->xtal) {
/*set internal freq to 53.125MHz */
@@ -2782,13 +2795,10 @@ static int stv0367cab_init(struct dvb_frontend *fe)
 {
struct stv0367_state *state = fe->demodulator_priv;
struct stv0367cab_state *cab_state = state->cab_state;
-   int i;
 
dprintk("%s:\n", __func__);
 
-   for (i = 0; i < STV0367CAB_NBREGS; i++)
-   stv0367_writereg(state, def0367cab[i].addr,
-   def0367cab[i].value);
+   stv0367_write_table(state, def0367cab);
 
switch (state->config->ts_mode) {
case STV0367_DVBCI_CLOCK:
diff --git a/drivers/media/dvb-frontends/stv0367_regs.h 
b/drivers/media/dvb-frontends/stv0367_regs.h
index 1d15862..cc66d93 100644
--- a/drivers/media/dvb-frontends/stv0367_regs.h
+++ b/drivers/media/dvb-frontends/stv0367_regs.h
@@ -2639,8 +2639,6 @@
 #defineR367TER_DEBUG_LT9   0xf405
 #defineF367TER_F_DEBUG_LT9 0xf40500ff
 
-#define STV0367TER_NBREGS  445
-
 /* ID */
 #defineR367CAB_ID  0xf000
 #defineF367CAB_IDENTIFICATIONREGISTER  0xf0ff
@@ -3605,6 +3603,4 @@
 #defineR367CAB_T_O_ID_30xf4d3
 #defineF367CAB_TS_ID_I_H   0xf4d300ff
 
-#define STV0367CAB_NBREGS  187
-
 #endif
-- 
2.10.2

[PATCH v3 07/13] [media] dvb-frontends/stv0367: support reading if_khz from tuner config

[Daniel Scheller]

From: Daniel Scheller 

Currently, if_khz is set and provided using the configuration var in
struct stv0367_config. However, in some constellations, the value might be
different for differing channel bandwidths or even -T and -C operation.
When e.g. used in conjunction with TDA18212 tuners, the tuner frontend
might be aware of the different freqs. This factors if_khz retrieval in a
function, which checks a new flag if an automatic retrieval attempt should
be made, and if the tuner provides it, use it whenever needed.

Signed-off-by: Daniel Scheller 
---
 drivers/media/dvb-frontends/stv0367.c | 45 +--
 1 file changed, 32 insertions(+), 13 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv0367.c 
b/drivers/media/dvb-frontends/stv0367.c
index 9370afa..74fee3f 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -94,6 +94,7 @@ struct stv0367_state {
u8 use_i2c_gatectrl;
u8 deftabs;
u8 reinit_on_setfrontend;
+   u8 auto_if_khz;
 };
 
 #define RF_LOOKUP_TABLE_SIZE  31
@@ -319,6 +320,17 @@ static void stv0367_pll_setup(struct stv0367_state *state,
stv0367_writereg(state, R367TER_PLLSETUP, 0x18);
 }
 
+static int stv0367_get_if_khz(struct stv0367_state *state, u32 *ifkhz)
+{
+   if (state->auto_if_khz && state->fe.ops.tuner_ops.get_if_frequency) {
+   state->fe.ops.tuner_ops.get_if_frequency(>fe, ifkhz);
+   *ifkhz = *ifkhz / 1000; /* hz -> khz */
+   } else
+   *ifkhz = state->config->if_khz;
+
+   return 0;
+}
+
 static int stv0367ter_gate_ctrl(struct dvb_frontend *fe, int enable)
 {
struct stv0367_state *state = fe->demodulator_priv;
@@ -992,10 +1004,12 @@ static int stv0367ter_algo(struct dvb_frontend *fe)
u8 /*constell,*/ counter;
s8 step;
s32 timing_offset = 0;
-   u32 trl_nomrate = 0, InternalFreq = 0, temp = 0;
+   u32 trl_nomrate = 0, InternalFreq = 0, temp = 0, ifkhz = 0;
 
dprintk("%s:\n", __func__);
 
+   stv0367_get_if_khz(state, );
+
ter_state->frequency = p->frequency;
ter_state->force = FE_TER_FORCENONE
+ stv0367_readbits(state, F367TER_FORCE) * 2;
@@ -1098,8 +1112,7 @@ static int stv0367ter_algo(struct dvb_frontend *fe)
stv0367_readbits(state, F367TER_GAIN_SRC_LO);
 
temp = (int)
-   ((InternalFreq - state->config->if_khz) * (1 << 16)
-   / (InternalFreq));
+   ((InternalFreq - ifkhz) * (1 << 16) / (InternalFreq));
 
dprintk("DEROT temp=0x%x\n", temp);
stv0367_writebits(state, F367TER_INC_DEROT_HI, temp / 256);
@@ -1720,6 +1733,7 @@ struct dvb_frontend *stv0367ter_attach(const struct 
stv0367_config *config,
state->use_i2c_gatectrl = 1;
state->deftabs = STV0367_DEFTAB_GENERIC;
state->reinit_on_setfrontend = 1;
+   state->auto_if_khz = 0;
 
dprintk("%s: chip_id = 0x%x\n", __func__, state->chip_id);
 
@@ -2229,7 +2243,7 @@ enum stv0367_cab_signal_type stv0367cab_algo(struct 
stv0367_state *state,
 {
struct stv0367cab_state *cab_state = state->cab_state;
enum stv0367_cab_signal_type signalType = FE_CAB_NOAGC;
-   u32 QAMFEC_Lock, QAM_Lock, u32_tmp,
+   u32 QAMFEC_Lock, QAM_Lock, u32_tmp, ifkhz,
LockTime, TRLTimeOut, AGCTimeOut, CRLSymbols,
CRLTimeOut, EQLTimeOut, DemodTimeOut, FECTimeOut;
u8  TrackAGCAccum;
@@ -2237,6 +2251,8 @@ enum stv0367_cab_signal_type stv0367cab_algo(struct 
stv0367_state *state,
 
dprintk("%s:\n", __func__);
 
+   stv0367_get_if_khz(state, );
+
/* Timeouts calculation */
/* A max lock time of 25 ms is allowed for delayed AGC */
AGCTimeOut = 25;
@@ -2315,7 +2331,7 @@ enum stv0367_cab_signal_type stv0367cab_algo(struct 
stv0367_state *state,
/* The sweep function is never used, Sweep rate must be set to 0 */
/* Set the derotator frequency in Hz */
stv0367cab_set_derot_freq(state, cab_state->adc_clk,
-   (1000 * (s32)state->config->if_khz + cab_state->derot_offset));
+   (1000 * (s32)ifkhz + cab_state->derot_offset));
/* Disable the Allpass Filter when the symbol rate is out of range */
if ((p->symbol_rate > 1080) | (p->symbol_rate < 180)) {
stv0367_writebits(state, F367CAB_ADJ_EN, 0);
@@ -2405,17 +2421,17 @@ enum stv0367_cab_signal_type stv0367cab_algo(struct 
stv0367_state *state,
F367CAB_QUAD_INV);
 #if 0
 /* not clear for me */
-   if (state->config->if_khz != 0) {
-   if (state->config->if_khz > cab_state->adc_clk / 1000) {
+   if (ifkhz != 0) {
+   if (ifkhz > cab_state->adc_clk / 1000) {
   

[PATCH v3 05/13] [media] dvb-frontends/stv0367: make PLLSETUP a function, add 58MHz IC speed

[Daniel Scheller]

From: Daniel Scheller 

This moves the PLL SETUP code from stv0367ter_init() into a dedicated
function, and also make it possible to configure 58Mhz IC speed at
27MHz Xtal (used on STV0367-based DDB cards/modules in QAM mode).

Signed-off-by: Daniel Scheller 
---
 drivers/media/dvb-frontends/stv0367.c | 73 +++
 drivers/media/dvb-frontends/stv0367.h |  3 ++
 2 files changed, 51 insertions(+), 25 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv0367.c 
b/drivers/media/dvb-frontends/stv0367.c
index 5b52673..da10d9a 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -271,6 +271,53 @@ static void stv0367_write_table(struct stv0367_state 
*state,
}
 }
 
+static void stv0367_pll_setup(struct stv0367_state *state,
+   u32 icspeed, u32 xtal)
+{
+   /* note on regs: R367TER_* and R367CAB_* defines each point to
+* 0xf0d8, so just use R367TER_ for both cases
+*/
+
+   switch (icspeed) {
+   case STV0367_ICSPEED_58000:
+   switch (xtal) {
+   default:
+   case 2700:
+   dprintk("STV0367 SetCLKgen for 58MHz IC and 27Mhz 
crystal\n");
+   /* PLLMDIV: 27, PLLNDIV: 232 */
+   stv0367_writereg(state, R367TER_PLLMDIV, 0x1b);
+   stv0367_writereg(state, R367TER_PLLNDIV, 0xe8);
+   break;
+   }
+   break;
+   default:
+   case STV0367_ICSPEED_53125:
+   switch (xtal) {
+   /* set internal freq to 53.125MHz */
+   case 1600:
+   stv0367_writereg(state, R367TER_PLLMDIV, 0x2);
+   stv0367_writereg(state, R367TER_PLLNDIV, 0x1b);
+   break;
+   case 2500:
+   stv0367_writereg(state, R367TER_PLLMDIV, 0xa);
+   stv0367_writereg(state, R367TER_PLLNDIV, 0x55);
+   break;
+   default:
+   case 2700:
+   dprintk("FE_STV0367TER_SetCLKgen for 27Mhz\n");
+   stv0367_writereg(state, R367TER_PLLMDIV, 0x1);
+   stv0367_writereg(state, R367TER_PLLNDIV, 0x8);
+   break;
+   case 3000:
+   stv0367_writereg(state, R367TER_PLLMDIV, 0xc);
+   stv0367_writereg(state, R367TER_PLLNDIV, 0x55);
+   break;
+   }
+   }
+
+   stv0367_writereg(state, R367TER_PLLSETUP, 0x18);
+}
+
 static int stv0367ter_gate_ctrl(struct dvb_frontend *fe, int enable)
 {
struct stv0367_state *state = fe->demodulator_priv;
@@ -918,31 +965,7 @@ static int stv0367ter_init(struct dvb_frontend *fe)
stv0367_write_table(state,
stv0367_deftabs[state->deftabs][STV0367_TAB_TER]);
 
-   switch (state->config->xtal) {
-   /*set internal freq to 53.125MHz */
-   case 1600:
-   stv0367_writereg(state, R367TER_PLLMDIV, 0x2);
-   stv0367_writereg(state, R367TER_PLLNDIV, 0x1b);
-   stv0367_writereg(state, R367TER_PLLSETUP, 0x18);
-   break;
-   case 2500:
-   stv0367_writereg(state, R367TER_PLLMDIV, 0xa);
-   stv0367_writereg(state, R367TER_PLLNDIV, 0x55);
-   stv0367_writereg(state, R367TER_PLLSETUP, 0x18);
-   break;
-   default:
-   case 2700:
-   dprintk("FE_STV0367TER_SetCLKgen for 27Mhz\n");
-   stv0367_writereg(state, R367TER_PLLMDIV, 0x1);
-   stv0367_writereg(state, R367TER_PLLNDIV, 0x8);
-   stv0367_writereg(state, R367TER_PLLSETUP, 0x18);
-   break;
-   case 3000:
-   stv0367_writereg(state, R367TER_PLLMDIV, 0xc);
-   stv0367_writereg(state, R367TER_PLLNDIV, 0x55);
-   stv0367_writereg(state, R367TER_PLLSETUP, 0x18);
-   break;
-   }
+   stv0367_pll_setup(state, STV0367_ICSPEED_53125, state->config->xtal);
 
stv0367_writereg(state, R367TER_I2CRPT, 0xa0);
stv0367_writereg(state, R367TER_ANACTRL, 0x00);
diff --git a/drivers/media/dvb-frontends/stv0367.h 
b/drivers/media/dvb-frontends/stv0367.h
index 26c38a0..aaa0236 100644
--- a/drivers/media/dvb-frontends/stv0367.h
+++ b/drivers/media/dvb-frontends/stv0367.h
@@ -25,6 +25,9 @@
 #include 
 #include "dvb_frontend.h"
 
+#define STV0367_ICSPEED_53125  53125000
+#define STV0367_ICSPEED_58000  5800
+
 struct stv0367_config {
u8 demod_address;
u32 xtal;
-- 
2.10.2

Re: [PATCHv5 00/11] video/exynos/sti/cec: add CEC notifier & use in drivers

[Benjamin Gaignard]

2017-03-29 16:15 GMT+02:00 Hans Verkuil :
> From: Hans Verkuil 
>
> This patch series adds the CEC physical address notifier code, based on
> Russell's code:
>
> https://patchwork.kernel.org/patch/9277043/
>
> It adds support for it to the exynos_hdmi drm driver, adds support for
> it to the CEC framework and finally adds support to the s5p-cec driver,
> which now can be moved out of staging.
>
> Also included is similar code for the STI platform, contributed by
> Benjamin Gaignard.
>
> Tested the exynos code with my Odroid U3 exynos4 devboard.
>
> After discussions with Daniel Vetter and Russell King I have removed
> the EDID/ELD/HPD connect/disconnect events from the notifier and now
> just use it to report the CEC physical address. This also means that
> it is now renamed to CEC notifier instead of HPD notifier and that
> it is now in drivers/media. The block_notifier was dropped as well
> and instead a simple callback is registered. This means that the
> relationship between HDMI and CEC is now 1:1 and no longer 1:n, but
> should this be needed in the future, then that can easily be added
> back.
>
> Daniel, regarding your suggestions here:
>
> http://www.spinics.net/lists/dri-devel/msg133907.html
>
> this patch series maps to your mail above as follows:
>
> struct cec_pin == struct cec_notifier
> cec_(un)register_pin == cec_notifier_get/put
> cec_set_address == cec_notifier_set_phys_addr
> cec_(un)register_callbacks == cec_notifier_(un)register
>
> Comments are welcome. I'd like to get this in for the 4.12 kernel as
> this is a missing piece needed to integrate CEC drivers.

I have been able to compile and test sti cec driver so you can add
my tested-by on this serie.

Thanks,

Benjamin

>
> Regards,
>
> Hans
>
> Changes since v4:
> - Dropped EDID/ELD/connect/disconnect support. Instead, just report the
>   CEC physical address (and use INVALID when disconnecting).
> - Since this is now completely CEC specific, move it to drivers/media
>   and rename to cec-notifier.
> - Drop block_notifier. Instead just set a callback for the notifier.
> - Use 'hdmi-phandle' in the bindings for both exynos and sti. So no
>   vendor prefix and 'hdmi-phandle' instead of 'hdmi-handle'.
> - Make struct cec_notifier opaque. Add a helper function to get the
>   physical address from a cec_notifier struct.
> - Provide dummy functions in cec-notifier.h so it can be used when
>   CONFIG_MEDIA_CEC_NOTIFIER is undefined.
> - Don't select the CEC notifier in the HDMI drivers. It should only
>   be enabled by actual CEC drivers.
>
> Changes since v3:
> - Added the STI patches
> - Split the exynos4 binding patches in one for documentation and one
>   for the dts change itself, also use the correct subject and CC to
>   the correct mailinglists (I hope  )
>
> Changes since v2:
> - Split off the dts changes of the s5p-cec patch into a separate patch
> - Renamed HPD_NOTIFIERS to HPD_NOTIFIER to be consistent with the name
>   of the source.
>
> Changes since v1:
>
> Renamed HDMI notifier to HPD (hotplug detect) notifier since this code is
> not HDMI specific, but is interesting for any video source that has to
> deal with hotplug detect and EDID/ELD (HDMI, DVI, VGA, DP, ).
> Only the use with CEC adapters is HDMI specific, but the HPD notifier
> is more generic.
>
>
>
>
> Benjamin Gaignard (4):
>   sti: hdmi: add CEC notifier support
>   stih-cec.txt: document new hdmi phandle
>   stih-cec: add CEC notifier support
>   arm: sti: update sti-cec for CEC notifier support
>
> Hans Verkuil (7):
>   cec-edid: rename cec_get_edid_phys_addr
>   media: add CEC notifier support
>   cec: integrate CEC notifier support
>   exynos_hdmi: add CEC notifier support
>   ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi
>   s5p-cec.txt: document the HDMI controller phandle
>   s5p-cec: add cec-notifier support, move out of staging
>
>  .../devicetree/bindings/media/s5p-cec.txt  |   2 +
>  .../devicetree/bindings/media/stih-cec.txt |   2 +
>  MAINTAINERS|   4 +-
>  arch/arm/boot/dts/exynos4.dtsi |   1 +
>  arch/arm/boot/dts/stih407-family.dtsi  |  12 ---
>  arch/arm/boot/dts/stih410.dtsi |  13 +++
>  drivers/gpu/drm/exynos/exynos_hdmi.c   |  20 +++-
>  drivers/gpu/drm/sti/sti_hdmi.c |  11 ++
>  drivers/gpu/drm/sti/sti_hdmi.h |   3 +
>  drivers/media/Kconfig  |   3 +
>  drivers/media/Makefile |   4 +
>  drivers/media/cec-edid.c   |  15 ++-
>  drivers/media/cec-notifier.c   | 116 
> +
>  drivers/media/cec/cec-core.c   |  21 
>  drivers/media/i2c/adv7511.c|   5 +-
>  drivers/media/i2c/adv7604.c|   3 +-
>  drivers/media/i2c/adv7842.c

[PATCHv5.1 03/11] cec: integrate CEC notifier support

[Hans Verkuil]

Support the CEC notifier framework, simplifying drivers that
depend on this.

Signed-off-by: Hans Verkuil 
Tested-by: Marek Szyprowski 
---
Accidentally removed adap->notifier causing this to fail. Fixed this
stupid mistake.
---
 drivers/media/cec/cec-core.c | 22 ++
 include/media/cec.h  | 10 ++
 2 files changed, 32 insertions(+)

diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index 37217e205040..e5070b374276 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -195,6 +195,24 @@ static void cec_devnode_unregister(struct cec_devnode 
*devnode)
put_device(>dev);
 }

+#ifdef CONFIG_MEDIA_CEC_NOTIFIER
+static void cec_cec_notify(struct cec_adapter *adap, u16 pa)
+{
+   cec_s_phys_addr(adap, pa, false);
+}
+
+void cec_register_cec_notifier(struct cec_adapter *adap,
+  struct cec_notifier *notifier)
+{
+   if (WARN_ON(!adap->devnode.registered))
+   return;
+
+   adap->notifier = notifier;
+   cec_notifier_register(adap->notifier, adap, cec_cec_notify);
+}
+EXPORT_SYMBOL_GPL(cec_register_cec_notifier);
+#endif
+
 struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops,
 void *priv, const char *name, u32 caps,
 u8 available_las)
@@ -343,6 +361,10 @@ void cec_unregister_adapter(struct cec_adapter *adap)
adap->rc = NULL;
 #endif
debugfs_remove_recursive(adap->cec_dir);
+#ifdef CONFIG_MEDIA_CEC_NOTIFIER
+   if (adap->notifier)
+   cec_notifier_unregister(adap->notifier);
+#endif
cec_devnode_unregister(>devnode);
 }
 EXPORT_SYMBOL_GPL(cec_unregister_adapter);
diff --git a/include/media/cec.h b/include/media/cec.h
index 96a0aa770d61..307f5dcaf034 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 

 /**
  * struct cec_devnode - cec device node
@@ -173,6 +174,10 @@ struct cec_adapter {
bool passthrough;
struct cec_log_addrs log_addrs;

+#ifdef CONFIG_MEDIA_CEC_NOTIFIER
+   struct cec_notifier *notifier;
+#endif
+
struct dentry *cec_dir;
struct dentry *status_file;

@@ -213,6 +218,11 @@ void cec_transmit_done(struct cec_adapter *adap, u8 
status, u8 arb_lost_cnt,
   u8 nack_cnt, u8 low_drive_cnt, u8 error_cnt);
 void cec_received_msg(struct cec_adapter *adap, struct cec_msg *msg);

+#ifdef CONFIG_MEDIA_CEC_NOTIFIER
+void cec_register_cec_notifier(struct cec_adapter *adap,
+  struct cec_notifier *notifier);
+#endif
+
 #else

 static inline int cec_register_adapter(struct cec_adapter *adap,
-- 
2.11.0

[RESEND PATCH] staging: media: davinci_vpfe: Replace a bit shift

[Arushi Singhal]

This patch replaces bit shifting on 1 with the BIT(x) macro.
This was done with coccinelle:
@@
constant c;
@@

-1 << c
+BIT(c)

Signed-off-by: Arushi Singhal 
---
 drivers/staging/media/davinci_vpfe/dm365_ipipe.c   |  2 +-
 drivers/staging/media/davinci_vpfe/dm365_ipipeif.c |  2 +-
 drivers/staging/media/davinci_vpfe/dm365_isif.c| 10 +-
 drivers/staging/media/davinci_vpfe/dm365_resizer.c |  6 +++---
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
index 6a3434cebd79..7eeb53217168 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
@@ -1815,7 +1815,7 @@ vpfe_ipipe_init(struct vpfe_ipipe_device *ipipe, struct 
platform_device *pdev)
v4l2_subdev_init(sd, _v4l2_ops);
sd->internal_ops = _v4l2_internal_ops;
strlcpy(sd->name, "DAVINCI IPIPE", sizeof(sd->name));
-   sd->grp_id = 1 << 16;   /* group ID for davinci subdevs */
+   sd->grp_id = BIT(16);   /* group ID for davinci subdevs */
v4l2_set_subdevdata(sd, ipipe);
sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
 
diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c
index 46fd2c7f69c3..c07f028dd6be 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c
@@ -1021,7 +1021,7 @@ int vpfe_ipipeif_init(struct vpfe_ipipeif_device *ipipeif,
 
sd->internal_ops = _v4l2_internal_ops;
strlcpy(sd->name, "DAVINCI IPIPEIF", sizeof(sd->name));
-   sd->grp_id = 1 << 16;   /* group ID for davinci subdevs */
+   sd->grp_id = BIT(16);   /* group ID for davinci subdevs */
 
v4l2_set_subdevdata(sd, ipipeif);
 
diff --git a/drivers/staging/media/davinci_vpfe/dm365_isif.c 
b/drivers/staging/media/davinci_vpfe/dm365_isif.c
index 569bcdc9ce2f..74b1247203b1 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_isif.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_isif.c
@@ -821,7 +821,7 @@ isif_config_dfc(struct vpfe_isif_device *isif, struct 
vpfe_isif_dfc *vdfc)
 
/* Correct whole line or partial */
if (vdfc->corr_whole_line)
-   val |= 1 << ISIF_VDFC_CORR_WHOLE_LN_SHIFT;
+   val |= BIT(ISIF_VDFC_CORR_WHOLE_LN_SHIFT);
 
/* level shift value */
val |= (vdfc->def_level_shift & ISIF_VDFC_LEVEL_SHFT_MASK) <<
@@ -849,7 +849,7 @@ isif_config_dfc(struct vpfe_isif_device *isif, struct 
vpfe_isif_dfc *vdfc)
 
val = isif_read(isif->isif_cfg.base_addr, DFCMEMCTL);
/* set DFCMARST and set DFCMWR */
-   val |= 1 << ISIF_DFCMEMCTL_DFCMARST_SHIFT;
+   val |= BIT(ISIF_DFCMEMCTL_DFCMARST_SHIFT);
val |= 1;
isif_write(isif->isif_cfg.base_addr, val, DFCMEMCTL);
 
@@ -880,7 +880,7 @@ isif_config_dfc(struct vpfe_isif_device *isif, struct 
vpfe_isif_dfc *vdfc)
}
val = isif_read(isif->isif_cfg.base_addr, DFCMEMCTL);
/* clear DFCMARST and set DFCMWR */
-   val &= ~(1 << ISIF_DFCMEMCTL_DFCMARST_SHIFT);
+   val &= ~BIT(ISIF_DFCMEMCTL_DFCMARST_SHIFT);
val |= 1;
isif_write(isif->isif_cfg.base_addr, val, DFCMEMCTL);
 
@@ -1140,7 +1140,7 @@ static int isif_config_raw(struct v4l2_subdev *sd, int 
mode)
isif_write(isif->isif_cfg.base_addr, val, CGAMMAWD);
/* Configure DPCM compression settings */
if (params->v4l2_pix_fmt == V4L2_PIX_FMT_SGRBG10DPCM8) {
-   val =  1 << ISIF_DPCM_EN_SHIFT;
+   val =  BIT(ISIF_DPCM_EN_SHIFT);
val |= (params->dpcm_predictor &
ISIF_DPCM_PREDICTOR_MASK) << ISIF_DPCM_PREDICTOR_SHIFT;
}
@@ -2044,7 +2044,7 @@ int vpfe_isif_init(struct vpfe_isif_device *isif, struct 
platform_device *pdev)
v4l2_subdev_init(sd, _v4l2_ops);
sd->internal_ops = _v4l2_internal_ops;
strlcpy(sd->name, "DAVINCI ISIF", sizeof(sd->name));
-   sd->grp_id = 1 << 16;   /* group ID for davinci subdevs */
+   sd->grp_id = BIT(16);   /* group ID for davinci subdevs */
v4l2_set_subdevdata(sd, isif);
sd->flags |= V4L2_SUBDEV_FL_HAS_EVENTS | V4L2_SUBDEV_FL_HAS_DEVNODE;
pads[ISIF_PAD_SINK].flags = MEDIA_PAD_FL_SINK;
diff --git a/drivers/staging/media/davinci_vpfe/dm365_resizer.c 
b/drivers/staging/media/davinci_vpfe/dm365_resizer.c
index 857b0e847c5e..3b3469adaf91 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_resizer.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_resizer.c
@@ -1903,7 +1903,7 @@ int vpfe_resizer_init(struct vpfe_resizer_device 
*vpfe_rsz,
v4l2_subdev_init(sd, _v4l2_ops);
sd->internal_ops = _v4l2_internal_ops;
strlcpy(sd->name, "DAVINCI RESIZER CROP", sizeof(sd->name));
-   sd->grp_id = 1 << 16;   /* group ID 

[RESEND PATCH] staging: media: omap4iss: Replace a bit shift by a use of BIT

[Arushi Singhal]

This patch replaces bit shifting on 1 with the BIT(x) macro.
This was done with coccinelle:
@@
constant c;
@@

-1 << c
+BIT(c)

Signed-off-by: Arushi Singhal 
---
 drivers/staging/media/omap4iss/iss_csi2.c| 2 +-
 drivers/staging/media/omap4iss/iss_ipipe.c   | 2 +-
 drivers/staging/media/omap4iss/iss_ipipeif.c | 2 +-
 drivers/staging/media/omap4iss/iss_resizer.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/omap4iss/iss_csi2.c 
b/drivers/staging/media/omap4iss/iss_csi2.c
index f71d5f2f179f..f6acc541e8a2 100644
--- a/drivers/staging/media/omap4iss/iss_csi2.c
+++ b/drivers/staging/media/omap4iss/iss_csi2.c
@@ -1268,7 +1268,7 @@ static int csi2_init_entities(struct iss_csi2_device 
*csi2, const char *subname)
snprintf(name, sizeof(name), "CSI2%s", subname);
snprintf(sd->name, sizeof(sd->name), "OMAP4 ISS %s", name);
 
-   sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
+   sd->grp_id = BIT(16);   /* group ID for iss subdevs */
v4l2_set_subdevdata(sd, csi2);
sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
 
diff --git a/drivers/staging/media/omap4iss/iss_ipipe.c 
b/drivers/staging/media/omap4iss/iss_ipipe.c
index d38782e8e84c..d86ef8a031f2 100644
--- a/drivers/staging/media/omap4iss/iss_ipipe.c
+++ b/drivers/staging/media/omap4iss/iss_ipipe.c
@@ -508,7 +508,7 @@ static int ipipe_init_entities(struct iss_ipipe_device 
*ipipe)
v4l2_subdev_init(sd, _v4l2_ops);
sd->internal_ops = _v4l2_internal_ops;
strlcpy(sd->name, "OMAP4 ISS ISP IPIPE", sizeof(sd->name));
-   sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
+   sd->grp_id = BIT(16);   /* group ID for iss subdevs */
v4l2_set_subdevdata(sd, ipipe);
sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
 
diff --git a/drivers/staging/media/omap4iss/iss_ipipeif.c 
b/drivers/staging/media/omap4iss/iss_ipipeif.c
index 23de8330731d..cb88b2bd0d82 100644
--- a/drivers/staging/media/omap4iss/iss_ipipeif.c
+++ b/drivers/staging/media/omap4iss/iss_ipipeif.c
@@ -739,7 +739,7 @@ static int ipipeif_init_entities(struct iss_ipipeif_device 
*ipipeif)
v4l2_subdev_init(sd, _v4l2_ops);
sd->internal_ops = _v4l2_internal_ops;
strlcpy(sd->name, "OMAP4 ISS ISP IPIPEIF", sizeof(sd->name));
-   sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
+   sd->grp_id = BIT(16);   /* group ID for iss subdevs */
v4l2_set_subdevdata(sd, ipipeif);
sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
 
diff --git a/drivers/staging/media/omap4iss/iss_resizer.c 
b/drivers/staging/media/omap4iss/iss_resizer.c
index f1d352c711d5..4bbfa20b3c38 100644
--- a/drivers/staging/media/omap4iss/iss_resizer.c
+++ b/drivers/staging/media/omap4iss/iss_resizer.c
@@ -782,7 +782,7 @@ static int resizer_init_entities(struct iss_resizer_device 
*resizer)
v4l2_subdev_init(sd, _v4l2_ops);
sd->internal_ops = _v4l2_internal_ops;
strlcpy(sd->name, "OMAP4 ISS ISP resizer", sizeof(sd->name));
-   sd->grp_id = 1 << 16;   /* group ID for iss subdevs */
+   sd->grp_id = BIT(16);   /* group ID for iss subdevs */
v4l2_set_subdevdata(sd, resizer);
sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
 
-- 
2.11.0

[PATCHv5 04/11] exynos_hdmi: add CEC notifier support

[Hans Verkuil]

From: Hans Verkuil 

Implement the CEC notifier support to allow CEC drivers to
be informed when there is a new physical address.

Signed-off-by: Hans Verkuil 
Tested-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 88ccc0469316..2afc8b8052c2 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -43,6 +43,8 @@
 
 #include 
 
+#include 
+
 #include "exynos_drm_drv.h"
 #include "exynos_drm_crtc.h"
 
@@ -119,6 +121,7 @@ struct hdmi_context {
booldvi_mode;
struct delayed_work hotplug_work;
struct drm_display_mode current_mode;
+   struct cec_notifier *notifier;
const struct hdmi_driver_data   *drv_data;
 
void __iomem*regs;
@@ -822,6 +825,7 @@ static enum drm_connector_status hdmi_detect(struct 
drm_connector *connector,
if (gpiod_get_value(hdata->hpd_gpio))
return connector_status_connected;
 
+   cec_notifier_set_phys_addr(hdata->notifier, CEC_PHYS_ADDR_INVALID);
return connector_status_disconnected;
 }
 
@@ -860,6 +864,8 @@ static int hdmi_get_modes(struct drm_connector *connector)
edid->width_cm, edid->height_cm);
 
drm_mode_connector_update_edid_property(connector, edid);
+   cec_notifier_set_phys_addr(hdata->notifier,
+  cec_get_edid_phys_addr(edid));
 
ret = drm_add_edid_modes(connector, edid);
 
@@ -1503,6 +1509,7 @@ static void hdmi_disable(struct drm_encoder *encoder)
if (funcs && funcs->disable)
(*funcs->disable)(crtc);
 
+   cec_notifier_set_phys_addr(hdata->notifier, CEC_PHYS_ADDR_INVALID);
cancel_delayed_work(>hotplug_work);
 
hdmiphy_disable(hdata);
@@ -1878,15 +1885,22 @@ static int hdmi_probe(struct platform_device *pdev)
}
}
 
+   hdata->notifier = cec_notifier_get(>dev);
+   if (hdata->notifier == NULL) {
+   ret = -ENOMEM;
+   goto err_hdmiphy;
+   }
+
pm_runtime_enable(dev);
 
ret = component_add(>dev, _component_ops);
if (ret)
-   goto err_disable_pm_runtime;
+   goto err_notifier_put;
 
return ret;
 
-err_disable_pm_runtime:
+err_notifier_put:
+   cec_notifier_put(hdata->notifier);
pm_runtime_disable(dev);
 
 err_hdmiphy:
@@ -1905,9 +1919,11 @@ static int hdmi_remove(struct platform_device *pdev)
struct hdmi_context *hdata = platform_get_drvdata(pdev);
 
cancel_delayed_work_sync(>hotplug_work);
+   cec_notifier_set_phys_addr(hdata->notifier, CEC_PHYS_ADDR_INVALID);
 
component_del(>dev, _component_ops);
 
+   cec_notifier_put(hdata->notifier);
pm_runtime_disable(>dev);
 
if (!IS_ERR(hdata->reg_hdmi_en))
-- 
2.11.0

[PATCHv5 01/11] cec-edid: rename cec_get_edid_phys_addr

[Hans Verkuil]

From: Hans Verkuil 

Rename cec_get_edid_phys_addr to cec_get_raw_edid_phys_addr.

Add a new cec_get_edid_phys_addr function that takes a struct edid pointer.

This reflects the fact that some drivers have a struct edid pointer and
others a u8 pointer to the raw edid data.

Signed-off-by: Hans Verkuil 
---
 drivers/media/cec-edid.c | 15 +--
 drivers/media/i2c/adv7511.c  |  5 ++---
 drivers/media/i2c/adv7604.c  |  3 ++-
 drivers/media/i2c/adv7842.c  |  2 +-
 drivers/media/platform/vivid/vivid-vid-cap.c |  3 ++-
 include/media/cec-edid.h | 17 ++---
 6 files changed, 34 insertions(+), 11 deletions(-)

diff --git a/drivers/media/cec-edid.c b/drivers/media/cec-edid.c
index 5719b991e340..d7b369f53831 100644
--- a/drivers/media/cec-edid.c
+++ b/drivers/media/cec-edid.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * This EDID is expected to be a CEA-861 compliant, which means that there are
@@ -82,8 +83,8 @@ static unsigned int cec_get_edid_spa_location(const u8 *edid, 
unsigned int size)
return 0;
 }
 
-u16 cec_get_edid_phys_addr(const u8 *edid, unsigned int size,
-  unsigned int *offset)
+u16 cec_get_raw_edid_phys_addr(const u8 *edid, unsigned int size,
+  unsigned int *offset)
 {
unsigned int loc = cec_get_edid_spa_location(edid, size);
 
@@ -93,6 +94,16 @@ u16 cec_get_edid_phys_addr(const u8 *edid, unsigned int size,
return CEC_PHYS_ADDR_INVALID;
return (edid[loc] << 8) | edid[loc + 1];
 }
+EXPORT_SYMBOL_GPL(cec_get_raw_edid_phys_addr);
+
+u16 cec_get_edid_phys_addr(const struct edid *edid)
+{
+   if (!edid || edid->extensions == 0)
+   return CEC_PHYS_ADDR_INVALID;
+
+   return cec_get_raw_edid_phys_addr((u8 *)edid,
+   EDID_LENGTH * (edid->extensions + 1), NULL);
+}
 EXPORT_SYMBOL_GPL(cec_get_edid_phys_addr);
 
 void cec_set_edid_phys_addr(u8 *edid, unsigned int size, u16 phys_addr)
diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index 8c9e28949ab1..4723e826804a 100644
--- a/drivers/media/i2c/adv7511.c
+++ b/drivers/media/i2c/adv7511.c
@@ -1712,9 +1712,8 @@ static bool adv7511_check_edid_status(struct v4l2_subdev 
*sd)
 
v4l2_dbg(1, debug, sd, "%s: edid complete with %d 
segment(s)\n", __func__, state->edid.segments);
state->edid.complete = true;
-   ed.phys_addr = cec_get_edid_phys_addr(state->edid.data,
- state->edid.segments * 
256,
- NULL);
+   ed.phys_addr = cec_get_raw_edid_phys_addr(state->edid.data,
+ state->edid.segments * 256, NULL);
/* report when we have all segments
   but report only for segment 0
 */
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index d8bf435db86d..ac60c9116f9c 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2305,7 +2305,8 @@ static int adv76xx_set_edid(struct v4l2_subdev *sd, 
struct v4l2_edid *edid)
edid->blocks = 2;
return -E2BIG;
}
-   pa = cec_get_edid_phys_addr(edid->edid, edid->blocks * 128, _loc);
+   pa = cec_get_raw_edid_phys_addr(edid->edid,
+   edid->blocks * 128, _loc);
err = cec_phys_addr_validate(pa, , NULL);
if (err)
return err;
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index 2d61f0cc2b5b..440870d1d988 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -802,7 +802,7 @@ static int edid_write_hdmi_segment(struct v4l2_subdev *sd, 
u8 port)
if (!state->hdmi_edid.present)
return 0;
 
-   pa = cec_get_edid_phys_addr(edid, 256, _loc);
+   pa = cec_get_raw_edid_phys_addr(edid, 256, _loc);
err = cec_phys_addr_validate(pa, , NULL);
if (err)
return err;
diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c 
b/drivers/media/platform/vivid/vivid-vid-cap.c
index 01419455e545..6a7310e212cf 100644
--- a/drivers/media/platform/vivid/vivid-vid-cap.c
+++ b/drivers/media/platform/vivid/vivid-vid-cap.c
@@ -1736,7 +1736,8 @@ int vidioc_s_edid(struct file *file, void *_fh,
edid->blocks = dev->edid_max_blocks;
return -E2BIG;
}
-   phys_addr = cec_get_edid_phys_addr(edid->edid, edid->blocks * 128, 
NULL);
+   phys_addr = cec_get_raw_edid_phys_addr(edid->edid,
+  edid->blocks * 128, NULL);
ret = cec_phys_addr_validate(phys_addr, _addr, NULL);
if (ret)
return ret;
diff --git 

[PATCHv5 02/11] media: add CEC notifier support

[Hans Verkuil]

From: Hans Verkuil 

Add support for CEC notifiers, which is used to convey CEC physical address
information from video drivers to their CEC counterpart driver(s).

Based on an earlier version from Russell King:

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

The cec_notifier is a reference counted object containing the CEC physical 
address
state of a video device.

When a new notifier is registered the current state will be reported to
that notifier at registration time.

Signed-off-by: Hans Verkuil 
Tested-by: Marek Szyprowski 
---
 MAINTAINERS  |   4 +-
 drivers/media/Kconfig|   3 ++
 drivers/media/Makefile   |   4 ++
 drivers/media/cec-notifier.c | 116 +++
 include/media/cec-notifier.h |  93 ++
 5 files changed, 219 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/cec-notifier.c
 create mode 100644 include/media/cec-notifier.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 83a42ef1d1a7..cfb2670aa372 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3066,7 +3066,7 @@ F:drivers/net/ieee802154/cc2520.c
 F: include/linux/spi/cc2520.h
 F: Documentation/devicetree/bindings/net/ieee802154/cc2520.txt
 
-CEC DRIVER
+CEC FRAMEWORK
 M: Hans Verkuil 
 L: linux-media@vger.kernel.org
 T: git git://linuxtv.org/media_tree.git
@@ -3076,9 +3076,11 @@ F:   Documentation/media/kapi/cec-core.rst
 F: Documentation/media/uapi/cec
 F: drivers/media/cec/
 F: drivers/media/cec-edid.c
+F: drivers/media/cec-notifier.c
 F: drivers/media/rc/keymaps/rc-cec.c
 F: include/media/cec.h
 F: include/media/cec-edid.h
+F: include/media/cec-notifier.h
 F: include/uapi/linux/cec.h
 F: include/uapi/linux/cec-funcs.h
 
diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 3512316e7a46..799429f51d1a 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -99,6 +99,9 @@ config MEDIA_CEC_DEBUG
 config MEDIA_CEC_EDID
bool
 
+config MEDIA_CEC_NOTIFIER
+   bool
+
 #
 # Media controller
 #  Selectable only for webcam/grabbers, as other drivers don't use it
diff --git a/drivers/media/Makefile b/drivers/media/Makefile
index d87ccb8eeabe..8b36a571d443 100644
--- a/drivers/media/Makefile
+++ b/drivers/media/Makefile
@@ -6,6 +6,10 @@ ifeq ($(CONFIG_MEDIA_CEC_EDID),y)
   obj-$(CONFIG_MEDIA_SUPPORT) += cec-edid.o
 endif
 
+ifeq ($(CONFIG_MEDIA_CEC_NOTIFIER),y)
+  obj-$(CONFIG_MEDIA_SUPPORT) += cec-notifier.o
+endif
+
 ifeq ($(CONFIG_MEDIA_CEC_SUPPORT),y)
   obj-$(CONFIG_MEDIA_SUPPORT) += cec/
 endif
diff --git a/drivers/media/cec-notifier.c b/drivers/media/cec-notifier.c
new file mode 100644
index ..a5938c4d3ab4
--- /dev/null
+++ b/drivers/media/cec-notifier.c
@@ -0,0 +1,116 @@
+/*
+ * cec-notifier.c - notify CEC drivers of physical address changes
+ *
+ * Copyright 2016 Russell King 
+ * Copyright 2016-2017 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * 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 
+
+struct cec_notifier {
+   struct mutex lock;
+   struct list_head head;
+   struct kref kref;
+   struct device *dev;
+   struct cec_adapter *cec_adap;
+   void (*callback)(struct cec_adapter *adap, u16 pa);
+
+   u16 phys_addr;
+};
+
+static LIST_HEAD(cec_notifiers);
+static DEFINE_MUTEX(cec_notifiers_lock);
+
+struct cec_notifier *cec_notifier_get(struct device *dev)
+{
+   struct cec_notifier *n;
+
+   mutex_lock(_notifiers_lock);
+   list_for_each_entry(n, _notifiers, head) {
+   if (n->dev == dev) {
+   mutex_unlock(_notifiers_lock);
+   kref_get(>kref);
+   return n;
+   }
+   }
+   n = kzalloc(sizeof(*n), GFP_KERNEL);
+   if (!n)
+   goto unlock;
+   n->dev = dev;
+   n->phys_addr = CEC_PHYS_ADDR_INVALID;
+   mutex_init(>lock);
+   kref_init(>kref);
+   list_add_tail(>head, _notifiers);
+unlock:
+   mutex_unlock(_notifiers_lock);
+   return n;
+}
+EXPORT_SYMBOL_GPL(cec_notifier_get);
+

[PATCHv5 07/11] s5p-cec: add cec-notifier support, move out of staging

[Hans Verkuil]

From: Hans Verkuil 

By using the CEC notifier framework there is no longer any reason
to manually set the physical address. This was the one blocking
issue that prevented this driver from going out of staging, so do
this move as well.

Update the bindings documenting the new hdmi phandle and
update exynos4.dtsi accordingly.

Tested with my Odroid U3.

Signed-off-by: Hans Verkuil 
Tested-by: Marek Szyprowski 
CC: linux-samsung-...@vger.kernel.org
CC: Krzysztof Kozlowski 
---
 drivers/media/platform/Kconfig | 18 +++
 drivers/media/platform/Makefile|  1 +
 .../media => media/platform}/s5p-cec/Makefile  |  0
 .../platform}/s5p-cec/exynos_hdmi_cec.h|  0
 .../platform}/s5p-cec/exynos_hdmi_cecctrl.c|  0
 .../media => media/platform}/s5p-cec/regs-cec.h|  0
 .../media => media/platform}/s5p-cec/s5p_cec.c | 35 ++
 .../media => media/platform}/s5p-cec/s5p_cec.h |  3 ++
 drivers/staging/media/Kconfig  |  2 --
 drivers/staging/media/Makefile |  1 -
 drivers/staging/media/s5p-cec/Kconfig  |  9 --
 drivers/staging/media/s5p-cec/TODO |  7 -
 12 files changed, 52 insertions(+), 24 deletions(-)
 rename drivers/{staging/media => media/platform}/s5p-cec/Makefile (100%)
 rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cec.h 
(100%)
 rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cecctrl.c 
(100%)
 rename drivers/{staging/media => media/platform}/s5p-cec/regs-cec.h (100%)
 rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.c (89%)
 rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.h (97%)
 delete mode 100644 drivers/staging/media/s5p-cec/Kconfig
 delete mode 100644 drivers/staging/media/s5p-cec/TODO

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ab0bb4879b54..2c449b88fc94 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -460,6 +460,24 @@ config VIDEO_TI_SC
 config VIDEO_TI_CSC
tristate
 
+menuconfig V4L_CEC_DRIVERS
+   bool "Platform HDMI CEC drivers"
+   depends on MEDIA_CEC_SUPPORT
+
+if V4L_CEC_DRIVERS
+
+config VIDEO_SAMSUNG_S5P_CEC
+   tristate "Samsung S5P CEC driver"
+   depends on VIDEO_DEV && MEDIA_CEC_SUPPORT && (PLAT_S5P || ARCH_EXYNOS 
|| COMPILE_TEST)
+   select MEDIA_CEC_NOTIFIER
+   ---help---
+ This is a driver for Samsung S5P HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
+endif #V4L_CEC_DRIVERS
+
 menuconfig V4L_TEST_DRIVERS
bool "Media test drivers"
depends on MEDIA_CAMERA_SUPPORT
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 8959f6e6692a..2f94d82afa4c 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG)  += s5p-jpeg/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/
 
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)+= s5p-g2d/
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec/
 obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/
 
 obj-$(CONFIG_VIDEO_STI_BDISP)  += sti/bdisp/
diff --git a/drivers/staging/media/s5p-cec/Makefile 
b/drivers/media/platform/s5p-cec/Makefile
similarity index 100%
rename from drivers/staging/media/s5p-cec/Makefile
rename to drivers/media/platform/s5p-cec/Makefile
diff --git a/drivers/staging/media/s5p-cec/exynos_hdmi_cec.h 
b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
similarity index 100%
rename from drivers/staging/media/s5p-cec/exynos_hdmi_cec.h
rename to drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
diff --git a/drivers/staging/media/s5p-cec/exynos_hdmi_cecctrl.c 
b/drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
similarity index 100%
rename from drivers/staging/media/s5p-cec/exynos_hdmi_cecctrl.c
rename to drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
diff --git a/drivers/staging/media/s5p-cec/regs-cec.h 
b/drivers/media/platform/s5p-cec/regs-cec.h
similarity index 100%
rename from drivers/staging/media/s5p-cec/regs-cec.h
rename to drivers/media/platform/s5p-cec/regs-cec.h
diff --git a/drivers/staging/media/s5p-cec/s5p_cec.c 
b/drivers/media/platform/s5p-cec/s5p_cec.c
similarity index 89%
rename from drivers/staging/media/s5p-cec/s5p_cec.c
rename to drivers/media/platform/s5p-cec/s5p_cec.c
index 2a07968b5ac6..f7adf61caaa8 100644
--- a/drivers/staging/media/s5p-cec/s5p_cec.c
+++ b/drivers/media/platform/s5p-cec/s5p_cec.c
@@ -19,11 +19,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "exynos_hdmi_cec.h"
 #include "regs-cec.h"
@@ -167,10 

[PATCHv5 06/11] s5p-cec.txt: document the HDMI controller phandle

[Hans Verkuil]

From: Hans Verkuil 

Update the bindings documenting the new hdmi phandle.

Signed-off-by: Hans Verkuil 
CC: linux-samsung-...@vger.kernel.org
CC: devicet...@vger.kernel.org
CC: Krzysztof Kozlowski 
---
 Documentation/devicetree/bindings/media/s5p-cec.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt 
b/Documentation/devicetree/bindings/media/s5p-cec.txt
index 925ab4d72eaa..4bb08d9d940b 100644
--- a/Documentation/devicetree/bindings/media/s5p-cec.txt
+++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
@@ -15,6 +15,7 @@ Required properties:
   - clock-names : from common clock binding: must contain "hdmicec",
  corresponding to entry in the clocks property.
   - samsung,syscon-phandle - phandle to the PMU system controller
+  - hdmi-phandle - phandle to the HDMI controller
 
 Example:
 
@@ -25,6 +26,7 @@ hdmicec: cec@100B {
clocks = < CLK_HDMI_CEC>;
clock-names = "hdmicec";
samsung,syscon-phandle = <_system_controller>;
+   hdmi-phandle = <>;
pinctrl-names = "default";
pinctrl-0 = <_cec>;
status = "okay";
-- 
2.11.0

[PATCHv5 05/11] ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi

[Hans Verkuil]

From: Hans Verkuil 

Add the new hdmi phandle to exynos4.dtsi. This phandle is needed by the
s5p-cec driver to initialize the CEC notifier framework.

Tested with my Odroid U3.

Signed-off-by: Hans Verkuil 
Tested-by: Marek Szyprowski 
CC: linux-samsung-...@vger.kernel.org
CC: devicet...@vger.kernel.org
CC: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 18def1c774d5..84fcdff140ae 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -771,6 +771,7 @@
clocks = < CLK_HDMI_CEC>;
clock-names = "hdmicec";
samsung,syscon-phandle = <_system_controller>;
+   hdmi-phandle = <>;
pinctrl-names = "default";
pinctrl-0 = <_cec>;
status = "disabled";
-- 
2.11.0

[PATCHv5 03/11] cec: integrate CEC notifier support

[Hans Verkuil]

From: Hans Verkuil 

Support the CEC notifier framework, simplifying drivers that
depend on this.

Signed-off-by: Hans Verkuil 
Tested-by: Marek Szyprowski 
---
 drivers/media/cec/cec-core.c | 21 +
 include/media/cec.h  |  6 ++
 2 files changed, 27 insertions(+)

diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index 37217e205040..2bab6e00b663 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -195,6 +195,23 @@ static void cec_devnode_unregister(struct cec_devnode 
*devnode)
put_device(>dev);
 }
 
+#ifdef CONFIG_MEDIA_CEC_NOTIFIER
+static void cec_cec_notify(struct cec_adapter *adap, u16 pa)
+{
+   cec_s_phys_addr(adap, pa, false);
+}
+
+void cec_register_cec_notifier(struct cec_adapter *adap,
+  struct cec_notifier *notifier)
+{
+   if (WARN_ON(!adap->devnode.registered))
+   return;
+
+   cec_notifier_register(adap->notifier, adap, cec_cec_notify);
+}
+EXPORT_SYMBOL_GPL(cec_register_cec_notifier);
+#endif
+
 struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops,
 void *priv, const char *name, u32 caps,
 u8 available_las)
@@ -343,6 +360,10 @@ void cec_unregister_adapter(struct cec_adapter *adap)
adap->rc = NULL;
 #endif
debugfs_remove_recursive(adap->cec_dir);
+#ifdef CONFIG_MEDIA_CEC_NOTIFIER
+   if (adap->notifier)
+   cec_notifier_unregister(adap->notifier);
+#endif
cec_devnode_unregister(>devnode);
 }
 EXPORT_SYMBOL_GPL(cec_unregister_adapter);
diff --git a/include/media/cec.h b/include/media/cec.h
index 96a0aa770d61..e6474b567a25 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * struct cec_devnode - cec device node
@@ -213,6 +214,11 @@ void cec_transmit_done(struct cec_adapter *adap, u8 
status, u8 arb_lost_cnt,
   u8 nack_cnt, u8 low_drive_cnt, u8 error_cnt);
 void cec_received_msg(struct cec_adapter *adap, struct cec_msg *msg);
 
+#ifdef CONFIG_MEDIA_CEC_NOTIFIER
+void cec_register_cec_notifier(struct cec_adapter *adap,
+  struct cec_notifier *notifier);
+#endif
+
 #else
 
 static inline int cec_register_adapter(struct cec_adapter *adap,
-- 
2.11.0

[PATCHv5 09/11] stih-cec.txt: document new hdmi phandle

[Hans Verkuil]

From: Benjamin Gaignard 

Update the bindings documentation with the new hdmi phandle.

Signed-off-by: Benjamin Gaignard 
Signed-off-by: Hans Verkuil 
Acked-by: Rob Herring 
CC: devicet...@vger.kernel.org
---
 Documentation/devicetree/bindings/media/stih-cec.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/stih-cec.txt 
b/Documentation/devicetree/bindings/media/stih-cec.txt
index 71c4b2f4bcef..289a08b33651 100644
--- a/Documentation/devicetree/bindings/media/stih-cec.txt
+++ b/Documentation/devicetree/bindings/media/stih-cec.txt
@@ -9,6 +9,7 @@ Required properties:
  - pinctrl-names: Contains only one value - "default"
  - pinctrl-0: Specifies the pin control groups used for CEC hardware.
  - resets: Reference to a reset controller
+ - hdmi-phandle: Phandle to the HDMI controller
 
 Example for STIH407:
 
@@ -22,4 +23,5 @@ sti-cec@094a087c {
pinctrl-names = "default";
pinctrl-0 = <_cec0_default>;
resets = < STIH407_LPM_SOFTRESET>;
+   hdmi-phandle = <>;
 };
-- 
2.11.0

[PATCHv5 08/11] sti: hdmi: add CEC notifier support

[Hans Verkuil]

From: Benjamin Gaignard 

Implement the CEC notifier support to allow CEC drivers to
be informed when there is a new physical address.

Signed-off-by: Benjamin Gaignard 
Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/sti/sti_hdmi.c | 11 +++
 drivers/gpu/drm/sti/sti_hdmi.h |  3 +++
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index ce2dcba679d5..345d3631cf50 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -771,6 +771,8 @@ static void sti_hdmi_disable(struct drm_bridge *bridge)
clk_disable_unprepare(hdmi->clk_pix);
 
hdmi->enabled = false;
+
+   cec_notifier_set_phys_addr(hdmi->notifier, CEC_PHYS_ADDR_INVALID);
 }
 
 /**
@@ -973,6 +975,7 @@ static int sti_hdmi_connector_get_modes(struct 
drm_connector *connector)
DRM_DEBUG_KMS("%s : %dx%d cm\n",
  (hdmi->hdmi_monitor ? "hdmi monitor" : "dvi monitor"),
  edid->width_cm, edid->height_cm);
+   cec_notifier_set_phys_addr(hdmi->notifier, 
cec_get_edid_phys_addr(edid));
 
count = drm_add_edid_modes(connector, edid);
drm_mode_connector_update_edid_property(connector, edid);
@@ -1035,6 +1038,7 @@ sti_hdmi_connector_detect(struct drm_connector 
*connector, bool force)
}
 
DRM_DEBUG_DRIVER("hdmi cable disconnected\n");
+   cec_notifier_set_phys_addr(hdmi->notifier, CEC_PHYS_ADDR_INVALID);
return connector_status_disconnected;
 }
 
@@ -1423,6 +1427,10 @@ static int sti_hdmi_probe(struct platform_device *pdev)
goto release_adapter;
}
 
+   hdmi->notifier = cec_notifier_get(>dev);
+   if (!hdmi->notifier)
+   goto release_adapter;
+
hdmi->reset = devm_reset_control_get(dev, "hdmi");
/* Take hdmi out of reset */
if (!IS_ERR(hdmi->reset))
@@ -1442,11 +1450,14 @@ static int sti_hdmi_remove(struct platform_device *pdev)
 {
struct sti_hdmi *hdmi = dev_get_drvdata(>dev);
 
+   cec_notifier_set_phys_addr(hdmi->notifier, CEC_PHYS_ADDR_INVALID);
+
i2c_put_adapter(hdmi->ddc_adapt);
if (hdmi->audio_pdev)
platform_device_unregister(hdmi->audio_pdev);
component_del(>dev, _hdmi_ops);
 
+   cec_notifier_put(hdmi->notifier);
return 0;
 }
 
diff --git a/drivers/gpu/drm/sti/sti_hdmi.h b/drivers/gpu/drm/sti/sti_hdmi.h
index 407012350f1a..c6469b56ce7e 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.h
+++ b/drivers/gpu/drm/sti/sti_hdmi.h
@@ -11,6 +11,7 @@
 #include 
 
 #include 
+#include 
 
 #define HDMI_STA   0x0010
 #define HDMI_STA_DLL_LCK   BIT(5)
@@ -64,6 +65,7 @@ static const struct drm_prop_enum_list 
colorspace_mode_names[] = {
  * @audio_pdev: ASoC hdmi-codec platform device
  * @audio: hdmi audio parameters.
  * @drm_connector: hdmi connector
+ * @notifier: hotplug detect notifier
  */
 struct sti_hdmi {
struct device dev;
@@ -89,6 +91,7 @@ struct sti_hdmi {
struct platform_device *audio_pdev;
struct hdmi_audio_params audio;
struct drm_connector *drm_connector;
+   struct cec_notifier *notifier;
 };
 
 u32 hdmi_read(struct sti_hdmi *hdmi, int offset);
-- 
2.11.0

[PATCHv5 10/11] stih-cec: add CEC notifier support

[Hans Verkuil]

From: Benjamin Gaignard 

By using the CEC notifier framework there is no longer any reason
to manually set the physical address. This was the one blocking
issue that prevented this driver from going out of staging, so do
this move as well.

Signed-off-by: Benjamin Gaignard 
Signed-off-by: Hans Verkuil 
CC: devicet...@vger.kernel.org
---
 drivers/media/platform/Kconfig | 10 +++
 drivers/media/platform/Makefile|  1 +
 .../st-cec => media/platform/sti/cec}/Makefile |  0
 .../st-cec => media/platform/sti/cec}/stih-cec.c   | 31 +++---
 drivers/staging/media/Kconfig  |  2 --
 drivers/staging/media/Makefile |  1 -
 drivers/staging/media/st-cec/Kconfig   |  8 --
 drivers/staging/media/st-cec/TODO  |  7 -
 8 files changed, 39 insertions(+), 21 deletions(-)
 rename drivers/{staging/media/st-cec => media/platform/sti/cec}/Makefile (100%)
 rename drivers/{staging/media/st-cec => media/platform/sti/cec}/stih-cec.c 
(93%)
 delete mode 100644 drivers/staging/media/st-cec/Kconfig
 delete mode 100644 drivers/staging/media/st-cec/TODO

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 2c449b88fc94..7321f6123659 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -476,6 +476,16 @@ config VIDEO_SAMSUNG_S5P_CEC
  CEC bus is present in the HDMI connector and enables communication
  between compatible devices.
 
+config VIDEO_STI_HDMI_CEC
+   tristate "STMicroelectronics STiH4xx HDMI CEC driver"
+   depends on VIDEO_DEV && MEDIA_CEC_SUPPORT && (ARCH_STI || COMPILE_TEST)
+   select MEDIA_CEC_NOTIFIER
+   ---help---
+ This is a driver for STIH4xx HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 endif #V4L_CEC_DRIVERS
 
 menuconfig V4L_TEST_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 2f94d82afa4c..940724ab9b70 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC)+= exynos-gsc/
 obj-$(CONFIG_VIDEO_STI_BDISP)  += sti/bdisp/
 obj-$(CONFIG_VIDEO_STI_HVA)+= sti/hva/
 obj-$(CONFIG_DVB_C8SECTPFE)+= sti/c8sectpfe/
+obj-$(CONFIG_VIDEO_STI_HDMI_CEC)   += sti/cec/
 
 obj-$(CONFIG_VIDEO_STI_DELTA)  += sti/delta/
 
diff --git a/drivers/staging/media/st-cec/Makefile 
b/drivers/media/platform/sti/cec/Makefile
similarity index 100%
rename from drivers/staging/media/st-cec/Makefile
rename to drivers/media/platform/sti/cec/Makefile
diff --git a/drivers/staging/media/st-cec/stih-cec.c 
b/drivers/media/platform/sti/cec/stih-cec.c
similarity index 93%
rename from drivers/staging/media/st-cec/stih-cec.c
rename to drivers/media/platform/sti/cec/stih-cec.c
index 3c25638a9610..636281c64c04 100644
--- a/drivers/staging/media/st-cec/stih-cec.c
+++ b/drivers/media/platform/sti/cec/stih-cec.c
@@ -1,6 +1,4 @@
 /*
- * drivers/staging/media/st-cec/stih-cec.c
- *
  * STIH4xx CEC driver
  * Copyright (C) STMicroelectronic SA 2016
  *
@@ -15,9 +13,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
+#include 
 
 #define CEC_NAME   "stih-cec"
 
@@ -129,6 +129,7 @@ struct stih_cec {
void __iomem*regs;
int irq;
u32 irq_status;
+   struct cec_notifier *notifier;
 };
 
 static int stih_cec_adap_enable(struct cec_adapter *adap, bool enable)
@@ -303,12 +304,29 @@ static int stih_cec_probe(struct platform_device *pdev)
struct device *dev = >dev;
struct resource *res;
struct stih_cec *cec;
+   struct device_node *np;
+   struct platform_device *hdmi_dev;
int ret;
 
cec = devm_kzalloc(dev, sizeof(*cec), GFP_KERNEL);
if (!cec)
return -ENOMEM;
 
+   np = of_parse_phandle(pdev->dev.of_node, "hdmi-phandle", 0);
+
+   if (!np) {
+   dev_err(>dev, "Failed to find hdmi node in device 
tree\n");
+   return -ENODEV;
+   }
+
+   hdmi_dev = of_find_device_by_node(np);
+   if (!hdmi_dev)
+   return -EPROBE_DEFER;
+
+   cec->notifier = cec_notifier_get(_dev->dev);
+   if (!cec->notifier)
+   return -ENOMEM;
+
cec->dev = dev;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -335,7 +353,7 @@ static int stih_cec_probe(struct platform_device *pdev)
cec->adap = cec_allocate_adapter(_cec_adap_ops, cec,
CEC_NAME,
CEC_CAP_LOG_ADDRS | CEC_CAP_PASSTHROUGH |
-   CEC_CAP_PHYS_ADDR | 

[PATCHv5 11/11] arm: sti: update sti-cec for CEC notifier support

[Hans Verkuil]

From: Benjamin Gaignard 

To use CEC notifier sti CEC driver needs to get phandle
of the hdmi device.

Signed-off-by: Benjamin Gaignard 
Signed-off-by: Hans Verkuil 
CC: devicet...@vger.kernel.org
---
 arch/arm/boot/dts/stih407-family.dtsi | 12 
 arch/arm/boot/dts/stih410.dtsi| 13 +
 2 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
b/arch/arm/boot/dts/stih407-family.dtsi
index d753ac36788f..044184580326 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -742,18 +742,6 @@
 <_s_c0_flexgen CLK_ETH_PHY>;
};
 
-   cec: sti-cec@094a087c {
-   compatible = "st,stih-cec";
-   reg = <0x94a087c 0x64>;
-   clocks = <_sysin>;
-   clock-names = "cec-clk";
-   interrupts = ;
-   interrupt-names = "cec-irq";
-   pinctrl-names = "default";
-   pinctrl-0 = <_cec0_default>;
-   resets = < STIH407_LPM_SOFTRESET>;
-   };
-
rng10: rng@08a89000 {
compatible  = "st,rng";
reg = <0x08a89000 0x1000>;
diff --git a/arch/arm/boot/dts/stih410.dtsi b/arch/arm/boot/dts/stih410.dtsi
index 3c9672c5b09f..21fe72b183d8 100644
--- a/arch/arm/boot/dts/stih410.dtsi
+++ b/arch/arm/boot/dts/stih410.dtsi
@@ -281,5 +281,18 @@
 <_s_c0_flexgen CLK_ST231_DMU>,
 <_s_c0_flexgen CLK_FLASH_PROMIP>;
};
+
+   sti-cec@094a087c {
+   compatible = "st,stih-cec";
+   reg = <0x94a087c 0x64>;
+   clocks = <_sysin>;
+   clock-names = "cec-clk";
+   interrupts = ;
+   interrupt-names = "cec-irq";
+   pinctrl-names = "default";
+   pinctrl-0 = <_cec0_default>;
+   resets = < STIH407_LPM_SOFTRESET>;
+   hdmi-phandle = <_hdmi>;
+   };
};
 };
-- 
2.11.0

[PATCHv5 00/11] video/exynos/sti/cec: add CEC notifier & use in drivers

[Hans Verkuil]

From: Hans Verkuil 

This patch series adds the CEC physical address notifier code, based on
Russell's code:

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

It adds support for it to the exynos_hdmi drm driver, adds support for
it to the CEC framework and finally adds support to the s5p-cec driver,
which now can be moved out of staging.

Also included is similar code for the STI platform, contributed by
Benjamin Gaignard.

Tested the exynos code with my Odroid U3 exynos4 devboard.

After discussions with Daniel Vetter and Russell King I have removed
the EDID/ELD/HPD connect/disconnect events from the notifier and now
just use it to report the CEC physical address. This also means that
it is now renamed to CEC notifier instead of HPD notifier and that
it is now in drivers/media. The block_notifier was dropped as well
and instead a simple callback is registered. This means that the
relationship between HDMI and CEC is now 1:1 and no longer 1:n, but
should this be needed in the future, then that can easily be added
back.

Daniel, regarding your suggestions here:

http://www.spinics.net/lists/dri-devel/msg133907.html

this patch series maps to your mail above as follows:

struct cec_pin == struct cec_notifier
cec_(un)register_pin == cec_notifier_get/put
cec_set_address == cec_notifier_set_phys_addr
cec_(un)register_callbacks == cec_notifier_(un)register

Comments are welcome. I'd like to get this in for the 4.12 kernel as
this is a missing piece needed to integrate CEC drivers.

Regards,

Hans

Changes since v4:
- Dropped EDID/ELD/connect/disconnect support. Instead, just report the
  CEC physical address (and use INVALID when disconnecting).
- Since this is now completely CEC specific, move it to drivers/media
  and rename to cec-notifier.
- Drop block_notifier. Instead just set a callback for the notifier.
- Use 'hdmi-phandle' in the bindings for both exynos and sti. So no
  vendor prefix and 'hdmi-phandle' instead of 'hdmi-handle'.
- Make struct cec_notifier opaque. Add a helper function to get the
  physical address from a cec_notifier struct.
- Provide dummy functions in cec-notifier.h so it can be used when
  CONFIG_MEDIA_CEC_NOTIFIER is undefined.
- Don't select the CEC notifier in the HDMI drivers. It should only
  be enabled by actual CEC drivers.

Changes since v3:
- Added the STI patches
- Split the exynos4 binding patches in one for documentation and one
  for the dts change itself, also use the correct subject and CC to
  the correct mailinglists (I hope  )

Changes since v2:
- Split off the dts changes of the s5p-cec patch into a separate patch
- Renamed HPD_NOTIFIERS to HPD_NOTIFIER to be consistent with the name
  of the source.

Changes since v1:

Renamed HDMI notifier to HPD (hotplug detect) notifier since this code is
not HDMI specific, but is interesting for any video source that has to
deal with hotplug detect and EDID/ELD (HDMI, DVI, VGA, DP, ).
Only the use with CEC adapters is HDMI specific, but the HPD notifier
is more generic.




Benjamin Gaignard (4):
  sti: hdmi: add CEC notifier support
  stih-cec.txt: document new hdmi phandle
  stih-cec: add CEC notifier support
  arm: sti: update sti-cec for CEC notifier support

Hans Verkuil (7):
  cec-edid: rename cec_get_edid_phys_addr
  media: add CEC notifier support
  cec: integrate CEC notifier support
  exynos_hdmi: add CEC notifier support
  ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi
  s5p-cec.txt: document the HDMI controller phandle
  s5p-cec: add cec-notifier support, move out of staging

 .../devicetree/bindings/media/s5p-cec.txt  |   2 +
 .../devicetree/bindings/media/stih-cec.txt |   2 +
 MAINTAINERS|   4 +-
 arch/arm/boot/dts/exynos4.dtsi |   1 +
 arch/arm/boot/dts/stih407-family.dtsi  |  12 ---
 arch/arm/boot/dts/stih410.dtsi |  13 +++
 drivers/gpu/drm/exynos/exynos_hdmi.c   |  20 +++-
 drivers/gpu/drm/sti/sti_hdmi.c |  11 ++
 drivers/gpu/drm/sti/sti_hdmi.h |   3 +
 drivers/media/Kconfig  |   3 +
 drivers/media/Makefile |   4 +
 drivers/media/cec-edid.c   |  15 ++-
 drivers/media/cec-notifier.c   | 116 +
 drivers/media/cec/cec-core.c   |  21 
 drivers/media/i2c/adv7511.c|   5 +-
 drivers/media/i2c/adv7604.c|   3 +-
 drivers/media/i2c/adv7842.c|   2 +-
 drivers/media/platform/Kconfig |  28 +
 drivers/media/platform/Makefile|   2 +
 .../media => media/platform}/s5p-cec/Makefile  |   0
 .../platform}/s5p-cec/exynos_hdmi_cec.h|   0
 .../platform}/s5p-cec/exynos_hdmi_cecctrl.c|   0
 .../media => media/platform}/s5p-cec/regs-cec.h|   0
 

Re: [PATCHv6 11/14] ov2640: convert from soc-camera to a standard subdev sensor driver.

[Hugues FRUCHET]

Y're welcome, thanks Hans for this work, this allows us to drop our 
camera interface driver directly based on subdev.

BR,
Hugues.

On 03/29/2017 03:44 PM, Hans Verkuil wrote:
> On 29/03/17 15:42, Hugues FRUCHET wrote:
>> Acked-by: Hugues Fruchet 
>>
>> Tested successfully on STM324x9I-EVAL evaluation board embedding
>> an OV2640 camera sensor.
>>
>> I don't understand the comment around s_power op that has been dropped
>> (it is there in code), and no problem is observed doing several
>> open/close, tell me if I miss something.
>
> Darn, I forgot to remove that comment in the commit log. It's a leftover from
> an earlier version.
>
> Regards,
>
>   Hans
>
>>
>> BR,
>> Hugues.
>>
>> On 03/28/2017 10:23 AM, Hans Verkuil wrote:
>>> From: Hans Verkuil 
>>>
>>> Convert ov2640 to a standard subdev driver. The soc-camera driver no longer
>>> uses this driver, so it can safely be converted.
>>>
>>> Note: the s_power op has been dropped: this never worked. When the last 
>>> open()
>>> is closed, then the power is turned off, and when it is opened again the 
>>> power
>>> is turned on again, but the old state isn't restored.
>>>
>>> Someone else can figure out in the future how to get this working correctly,
>>> but I don't want to spend more time on this.
>>>
>>> Signed-off-by: Hans Verkuil 
>>> Acked-by: Sakari Ailus 
>>> ---
>>>  drivers/media/i2c/Kconfig   | 11 
>>>  drivers/media/i2c/Makefile  |  1 +
>>>  drivers/media/i2c/{soc_camera => }/ov2640.c | 89 
>>> +
>>>  drivers/media/i2c/soc_camera/Kconfig|  6 --
>>>  drivers/media/i2c/soc_camera/Makefile   |  1 -
>>>  5 files changed, 27 insertions(+), 81 deletions(-)
>>>  rename drivers/media/i2c/{soc_camera => }/ov2640.c (94%)
>>>
>>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
>>> index cee1dae6e014..db2c63f592c5 100644
>>> --- a/drivers/media/i2c/Kconfig
>>> +++ b/drivers/media/i2c/Kconfig
>>> @@ -520,6 +520,17 @@ config VIDEO_APTINA_PLL
>>>  config VIDEO_SMIAPP_PLL
>>> tristate
>>>
>>> +config VIDEO_OV2640
>>> +   tristate "OmniVision OV2640 sensor support"
>>> +   depends on VIDEO_V4L2 && I2C && GPIOLIB
>>> +   depends on MEDIA_CAMERA_SUPPORT
>>> +   help
>>> + This is a Video4Linux2 sensor-level driver for the OmniVision
>>> + OV2640 camera.
>>> +
>>> + To compile this driver as a module, choose M here: the
>>> + module will be called ov2640.
>>> +
>>>  config VIDEO_OV2659
>>> tristate "OmniVision OV2659 sensor support"
>>> depends on VIDEO_V4L2 && I2C
>>> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
>>> index 5bc7bbeb5499..50af1e11c85a 100644
>>> --- a/drivers/media/i2c/Makefile
>>> +++ b/drivers/media/i2c/Makefile
>>> @@ -57,6 +57,7 @@ obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o
>>>  obj-$(CONFIG_VIDEO_SONY_BTF_MPX) += sony-btf-mpx.o
>>>  obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
>>>  obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
>>> +obj-$(CONFIG_VIDEO_OV2640) += ov2640.o
>>>  obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
>>>  obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
>>>  obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
>>> diff --git a/drivers/media/i2c/soc_camera/ov2640.c 
>>> b/drivers/media/i2c/ov2640.c
>>> similarity index 94%
>>> rename from drivers/media/i2c/soc_camera/ov2640.c
>>> rename to drivers/media/i2c/ov2640.c
>>> index b9a0069f5b33..83f88efbce69 100644
>>> --- a/drivers/media/i2c/soc_camera/ov2640.c
>>> +++ b/drivers/media/i2c/ov2640.c
>>> @@ -24,8 +24,8 @@
>>>  #include 
>>>  #include 
>>>
>>> -#include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -287,7 +287,6 @@ struct ov2640_priv {
>>> struct v4l2_clk *clk;
>>> const struct ov2640_win_size*win;
>>>
>>> -   struct soc_camera_subdev_desc   ssdd_dt;
>>> struct gpio_desc *resetb_gpio;
>>> struct gpio_desc *pwdn_gpio;
>>>  };
>>> @@ -677,13 +676,8 @@ static int ov2640_reset(struct i2c_client *client)
>>>  }
>>>
>>>  /*
>>> - * soc_camera_ops functions
>>> + * functions
>>>   */
>>> -static int ov2640_s_stream(struct v4l2_subdev *sd, int enable)
>>> -{
>>> -   return 0;
>>> -}
>>> -
>>>  static int ov2640_s_ctrl(struct v4l2_ctrl *ctrl)
>>>  {
>>> struct v4l2_subdev *sd =
>>> @@ -744,10 +738,16 @@ static int ov2640_s_register(struct v4l2_subdev *sd,
>>>  static int ov2640_s_power(struct v4l2_subdev *sd, int on)
>>>  {
>>> struct i2c_client *client = v4l2_get_subdevdata(sd);
>>> -   struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
>>> struct ov2640_priv *priv = to_ov2640(client);
>>>
>>> -   return soc_camera_set_power(>dev, ssdd, priv->clk, on);
>>> +   gpiod_direction_output(priv->pwdn_gpio, !on);
>>> +   if (on && priv->resetb_gpio) {
>>> +   /* Active the resetb pin to perform a reset pulse */
>>> +   

Re: [PATCHv6 11/14] ov2640: convert from soc-camera to a standard subdev sensor driver.

[Hans Verkuil]

On 29/03/17 15:42, Hugues FRUCHET wrote:
> Acked-by: Hugues Fruchet 
> 
> Tested successfully on STM324x9I-EVAL evaluation board embedding
> an OV2640 camera sensor.
> 
> I don't understand the comment around s_power op that has been dropped 
> (it is there in code), and no problem is observed doing several 
> open/close, tell me if I miss something.

Darn, I forgot to remove that comment in the commit log. It's a leftover from
an earlier version.

Regards,

Hans

> 
> BR,
> Hugues.
> 
> On 03/28/2017 10:23 AM, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> Convert ov2640 to a standard subdev driver. The soc-camera driver no longer
>> uses this driver, so it can safely be converted.
>>
>> Note: the s_power op has been dropped: this never worked. When the last 
>> open()
>> is closed, then the power is turned off, and when it is opened again the 
>> power
>> is turned on again, but the old state isn't restored.
>>
>> Someone else can figure out in the future how to get this working correctly,
>> but I don't want to spend more time on this.
>>
>> Signed-off-by: Hans Verkuil 
>> Acked-by: Sakari Ailus 
>> ---
>>  drivers/media/i2c/Kconfig   | 11 
>>  drivers/media/i2c/Makefile  |  1 +
>>  drivers/media/i2c/{soc_camera => }/ov2640.c | 89 
>> +
>>  drivers/media/i2c/soc_camera/Kconfig|  6 --
>>  drivers/media/i2c/soc_camera/Makefile   |  1 -
>>  5 files changed, 27 insertions(+), 81 deletions(-)
>>  rename drivers/media/i2c/{soc_camera => }/ov2640.c (94%)
>>
>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
>> index cee1dae6e014..db2c63f592c5 100644
>> --- a/drivers/media/i2c/Kconfig
>> +++ b/drivers/media/i2c/Kconfig
>> @@ -520,6 +520,17 @@ config VIDEO_APTINA_PLL
>>  config VIDEO_SMIAPP_PLL
>>  tristate
>>
>> +config VIDEO_OV2640
>> +tristate "OmniVision OV2640 sensor support"
>> +depends on VIDEO_V4L2 && I2C && GPIOLIB
>> +depends on MEDIA_CAMERA_SUPPORT
>> +help
>> +  This is a Video4Linux2 sensor-level driver for the OmniVision
>> +  OV2640 camera.
>> +
>> +  To compile this driver as a module, choose M here: the
>> +  module will be called ov2640.
>> +
>>  config VIDEO_OV2659
>>  tristate "OmniVision OV2659 sensor support"
>>  depends on VIDEO_V4L2 && I2C
>> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
>> index 5bc7bbeb5499..50af1e11c85a 100644
>> --- a/drivers/media/i2c/Makefile
>> +++ b/drivers/media/i2c/Makefile
>> @@ -57,6 +57,7 @@ obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o
>>  obj-$(CONFIG_VIDEO_SONY_BTF_MPX) += sony-btf-mpx.o
>>  obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
>>  obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
>> +obj-$(CONFIG_VIDEO_OV2640) += ov2640.o
>>  obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
>>  obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
>>  obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
>> diff --git a/drivers/media/i2c/soc_camera/ov2640.c 
>> b/drivers/media/i2c/ov2640.c
>> similarity index 94%
>> rename from drivers/media/i2c/soc_camera/ov2640.c
>> rename to drivers/media/i2c/ov2640.c
>> index b9a0069f5b33..83f88efbce69 100644
>> --- a/drivers/media/i2c/soc_camera/ov2640.c
>> +++ b/drivers/media/i2c/ov2640.c
>> @@ -24,8 +24,8 @@
>>  #include 
>>  #include 
>>
>> -#include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -287,7 +287,6 @@ struct ov2640_priv {
>>  struct v4l2_clk *clk;
>>  const struct ov2640_win_size*win;
>>
>> -struct soc_camera_subdev_desc   ssdd_dt;
>>  struct gpio_desc *resetb_gpio;
>>  struct gpio_desc *pwdn_gpio;
>>  };
>> @@ -677,13 +676,8 @@ static int ov2640_reset(struct i2c_client *client)
>>  }
>>
>>  /*
>> - * soc_camera_ops functions
>> + * functions
>>   */
>> -static int ov2640_s_stream(struct v4l2_subdev *sd, int enable)
>> -{
>> -return 0;
>> -}
>> -
>>  static int ov2640_s_ctrl(struct v4l2_ctrl *ctrl)
>>  {
>>  struct v4l2_subdev *sd =
>> @@ -744,10 +738,16 @@ static int ov2640_s_register(struct v4l2_subdev *sd,
>>  static int ov2640_s_power(struct v4l2_subdev *sd, int on)
>>  {
>>  struct i2c_client *client = v4l2_get_subdevdata(sd);
>> -struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
>>  struct ov2640_priv *priv = to_ov2640(client);
>>
>> -return soc_camera_set_power(>dev, ssdd, priv->clk, on);
>> +gpiod_direction_output(priv->pwdn_gpio, !on);
>> +if (on && priv->resetb_gpio) {
>> +/* Active the resetb pin to perform a reset pulse */
>> +gpiod_direction_output(priv->resetb_gpio, 1);
>> +usleep_range(3000, 5000);
>> +gpiod_direction_output(priv->resetb_gpio, 0);
>> +}
>> +return 0;
>>  }
>>
>>  /* Select the nearest higher resolution for capture */
>> @@ -994,26 +994,6 @@ static struct v4l2_subdev_core_ops 
>> 

Re: [PATCHv6 12/14] ov2640: use standard clk and enable it.

[Hugues FRUCHET]

Acked-by: Hugues Fruchet 

Tested successfully on STM324x9I-EVAL evaluation board embedding
an OV2640 camera sensor.

BR,
Hugues.

On 03/28/2017 10:23 AM, Hans Verkuil wrote:
> From: Hans Verkuil 
>
> Convert v4l2_clk to normal clk and enable the clock.
>
> Signed-off-by: Hans Verkuil 
> Acked-by: Sakari Ailus 
> ---
>  drivers/media/i2c/ov2640.c | 31 ++-
>  1 file changed, 14 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
> index 83f88efbce69..0445963c5fae 100644
> --- a/drivers/media/i2c/ov2640.c
> +++ b/drivers/media/i2c/ov2640.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -24,7 +25,6 @@
>  #include 
>  #include 
>
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -284,7 +284,7 @@ struct ov2640_priv {
>   struct v4l2_subdev  subdev;
>   struct v4l2_ctrl_handlerhdl;
>   u32 cfmt_code;
> - struct v4l2_clk *clk;
> + struct clk  *clk;
>   const struct ov2640_win_size*win;
>
>   struct gpio_desc *resetb_gpio;
> @@ -1051,14 +1051,11 @@ static int ov2640_probe(struct i2c_client *client,
>   return -ENOMEM;
>   }
>
> - priv->clk = v4l2_clk_get(>dev, "xvclk");
> - if (IS_ERR(priv->clk))
> - return -EPROBE_DEFER;
> -
> - if (!client->dev.of_node) {
> - dev_err(>dev, "Missing platform_data for driver\n");
> - ret = -EINVAL;
> - goto err_clk;
> + if (client->dev.of_node) {
> + priv->clk = devm_clk_get(>dev, "xvclk");
> + if (IS_ERR(priv->clk))
> + return -EPROBE_DEFER;
> + clk_prepare_enable(priv->clk);
>   }
>
>   ret = ov2640_probe_dt(client, priv);
> @@ -1074,25 +1071,25 @@ static int ov2640_probe(struct i2c_client *client,
>   priv->subdev.ctrl_handler = >hdl;
>   if (priv->hdl.error) {
>   ret = priv->hdl.error;
> - goto err_clk;
> + goto err_hdl;
>   }
>
>   ret = ov2640_video_probe(client);
>   if (ret < 0)
> - goto err_videoprobe;
> + goto err_hdl;
>
>   ret = v4l2_async_register_subdev(>subdev);
>   if (ret < 0)
> - goto err_videoprobe;
> + goto err_hdl;
>
>   dev_info(>dev, "OV2640 Probed\n");
>
>   return 0;
>
> -err_videoprobe:
> +err_hdl:
>   v4l2_ctrl_handler_free(>hdl);
>  err_clk:
> - v4l2_clk_put(priv->clk);
> + clk_disable_unprepare(priv->clk);
>   return ret;
>  }
>
> @@ -1101,9 +1098,9 @@ static int ov2640_remove(struct i2c_client *client)
>   struct ov2640_priv   *priv = to_ov2640(client);
>
>   v4l2_async_unregister_subdev(>subdev);
> - v4l2_clk_put(priv->clk);
> - v4l2_device_unregister_subdev(>subdev);
>   v4l2_ctrl_handler_free(>hdl);
> + v4l2_device_unregister_subdev(>subdev);
> + clk_disable_unprepare(priv->clk);
>   return 0;
>  }
>
>

Re: [PATCHv6 11/14] ov2640: convert from soc-camera to a standard subdev sensor driver.

[Hugues FRUCHET]

Acked-by: Hugues Fruchet 

Tested successfully on STM324x9I-EVAL evaluation board embedding
an OV2640 camera sensor.

I don't understand the comment around s_power op that has been dropped 
(it is there in code), and no problem is observed doing several 
open/close, tell me if I miss something.

BR,
Hugues.

On 03/28/2017 10:23 AM, Hans Verkuil wrote:
> From: Hans Verkuil 
>
> Convert ov2640 to a standard subdev driver. The soc-camera driver no longer
> uses this driver, so it can safely be converted.
>
> Note: the s_power op has been dropped: this never worked. When the last open()
> is closed, then the power is turned off, and when it is opened again the power
> is turned on again, but the old state isn't restored.
>
> Someone else can figure out in the future how to get this working correctly,
> but I don't want to spend more time on this.
>
> Signed-off-by: Hans Verkuil 
> Acked-by: Sakari Ailus 
> ---
>  drivers/media/i2c/Kconfig   | 11 
>  drivers/media/i2c/Makefile  |  1 +
>  drivers/media/i2c/{soc_camera => }/ov2640.c | 89 
> +
>  drivers/media/i2c/soc_camera/Kconfig|  6 --
>  drivers/media/i2c/soc_camera/Makefile   |  1 -
>  5 files changed, 27 insertions(+), 81 deletions(-)
>  rename drivers/media/i2c/{soc_camera => }/ov2640.c (94%)
>
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index cee1dae6e014..db2c63f592c5 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -520,6 +520,17 @@ config VIDEO_APTINA_PLL
>  config VIDEO_SMIAPP_PLL
>   tristate
>
> +config VIDEO_OV2640
> + tristate "OmniVision OV2640 sensor support"
> + depends on VIDEO_V4L2 && I2C && GPIOLIB
> + depends on MEDIA_CAMERA_SUPPORT
> + help
> +   This is a Video4Linux2 sensor-level driver for the OmniVision
> +   OV2640 camera.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called ov2640.
> +
>  config VIDEO_OV2659
>   tristate "OmniVision OV2659 sensor support"
>   depends on VIDEO_V4L2 && I2C
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 5bc7bbeb5499..50af1e11c85a 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -57,6 +57,7 @@ obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o
>  obj-$(CONFIG_VIDEO_SONY_BTF_MPX) += sony-btf-mpx.o
>  obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
>  obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
> +obj-$(CONFIG_VIDEO_OV2640) += ov2640.o
>  obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
>  obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
>  obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
> diff --git a/drivers/media/i2c/soc_camera/ov2640.c 
> b/drivers/media/i2c/ov2640.c
> similarity index 94%
> rename from drivers/media/i2c/soc_camera/ov2640.c
> rename to drivers/media/i2c/ov2640.c
> index b9a0069f5b33..83f88efbce69 100644
> --- a/drivers/media/i2c/soc_camera/ov2640.c
> +++ b/drivers/media/i2c/ov2640.c
> @@ -24,8 +24,8 @@
>  #include 
>  #include 
>
> -#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -287,7 +287,6 @@ struct ov2640_priv {
>   struct v4l2_clk *clk;
>   const struct ov2640_win_size*win;
>
> - struct soc_camera_subdev_desc   ssdd_dt;
>   struct gpio_desc *resetb_gpio;
>   struct gpio_desc *pwdn_gpio;
>  };
> @@ -677,13 +676,8 @@ static int ov2640_reset(struct i2c_client *client)
>  }
>
>  /*
> - * soc_camera_ops functions
> + * functions
>   */
> -static int ov2640_s_stream(struct v4l2_subdev *sd, int enable)
> -{
> - return 0;
> -}
> -
>  static int ov2640_s_ctrl(struct v4l2_ctrl *ctrl)
>  {
>   struct v4l2_subdev *sd =
> @@ -744,10 +738,16 @@ static int ov2640_s_register(struct v4l2_subdev *sd,
>  static int ov2640_s_power(struct v4l2_subdev *sd, int on)
>  {
>   struct i2c_client *client = v4l2_get_subdevdata(sd);
> - struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
>   struct ov2640_priv *priv = to_ov2640(client);
>
> - return soc_camera_set_power(>dev, ssdd, priv->clk, on);
> + gpiod_direction_output(priv->pwdn_gpio, !on);
> + if (on && priv->resetb_gpio) {
> + /* Active the resetb pin to perform a reset pulse */
> + gpiod_direction_output(priv->resetb_gpio, 1);
> + usleep_range(3000, 5000);
> + gpiod_direction_output(priv->resetb_gpio, 0);
> + }
> + return 0;
>  }
>
>  /* Select the nearest higher resolution for capture */
> @@ -994,26 +994,6 @@ static struct v4l2_subdev_core_ops 
> ov2640_subdev_core_ops = {
>   .s_power= ov2640_s_power,
>  };
>
> -static int ov2640_g_mbus_config(struct v4l2_subdev *sd,
> - struct v4l2_mbus_config *cfg)
> -{
> - struct i2c_client *client = v4l2_get_subdevdata(sd);
> - struct 

[PATCH v1 4/8] ARM: dts: stm32: Enable DCMI camera interface on STM32F429-EVAL board

[Hugues Fruchet]

Signed-off-by: Hugues Fruchet 
---
 arch/arm/boot/dts/stm32429i-eval.dts | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/stm32429i-eval.dts 
b/arch/arm/boot/dts/stm32429i-eval.dts
index 3c99466..87733d3 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -141,6 +141,15 @@
clock-frequency = <2500>;
 };
 
+ {
+   status = "okay";
+
+   port {
+   dcmi_0: endpoint@0 {
+   };
+   };
+};
+
  {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
-- 
1.9.1

[PATCH v1 8/8] ARM: configs: stm32: DCMI + OV2640 camera support

[Hugues Fruchet]

Enable DCMI camera interface and OV2640 camera sensor drivers.

Signed-off-by: Hugues Fruchet 
---
 arch/arm/configs/stm32_defconfig | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index 84adc88..3f2e4ce 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -53,6 +53,13 @@ CONFIG_GPIO_STMPE=y
 CONFIG_MFD_STMPE=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
 # CONFIG_USB_SUPPORT is not set
+CONFIG_VIDEO_V4L2=y
+CONFIG_MEDIA_SUBDRV_AUTOSELECT=n
+CONFIG_V4L_PLATFORM_DRIVERS=y
+CONFIG_MEDIA_SUPPORT=y
+CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_VIDEO_STM32_DCMI=y
+CONFIG_VIDEO_OV2640=y
 CONFIG_NEW_LEDS=y
 CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_GPIO=y
-- 
1.9.1

[PATCH v1 3/8] ARM: dts: stm32: Enable DCMI support on STM32F429 MCU

[Hugues Fruchet]

Signed-off-by: Hugues Fruchet 
---
 arch/arm/boot/dts/stm32f429.dtsi | 37 +
 1 file changed, 37 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index ee0da97..e1ff978 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -736,6 +736,29 @@
slew-rate = <3>;
};
};
+
+   dcmi_pins: dcmi_pins@0 {
+   pins {
+   pinmux = 
,
+
,
+
,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+   bias-disable;
+   drive-push-pull;
+   slew-rate = <3>;
+   };
+   };
};
 
rcc: rcc@40023810 {
@@ -805,6 +828,20 @@
status = "disabled";
};
 
+   dcmi: dcmi@5005 {
+   compatible = "st,stm32-dcmi";
+   reg = <0x5005 0x400>;
+   interrupts = <78>;
+   resets = < STM32F4_AHB2_RESET(DCMI)>;
+   clocks = < 0 STM32F4_AHB2_CLOCK(DCMI)>;
+   clock-names = "mclk";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   dmas = < 1 1 0x414 0x3>;
+   dma-names = "tx";
+   status = "disabled";
+   };
+
rng: rng@50060800 {
compatible = "st,stm32-rng";
reg = <0x50060800 0x400>;
-- 
1.9.1

[PATCH v1 5/8] ARM: dts: stm32: Enable stmpe1600 gpio expandor of STM32F429-EVAL board

[Hugues Fruchet]

Signed-off-by: Hugues Fruchet 
---
 arch/arm/boot/dts/stm32429i-eval.dts | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/stm32429i-eval.dts 
b/arch/arm/boot/dts/stm32429i-eval.dts
index 87733d3..7ffcf07 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -154,6 +154,23 @@
pinctrl-0 = <_pins>;
pinctrl-names = "default";
status = "okay";
+
+   stmpe1600: stmpe1600@42 {
+   compatible = "st,stmpe1600";
+   reg = <0x42>;
+   irq-gpio = < 8 0>;
+   irq-trigger = <3>;
+   interrupts = <8 3>;
+   interrupt-parent = <>;
+   interrupt-controller;
+   wakeup-source;
+
+   stmpegpio: stmpe_gpio {
+   compatible = "st,stmpe-gpio";
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+   };
 };
 
  {
-- 
1.9.1

[PATCH v1 1/8] dt-bindings: Document STM32 DCMI bindings

[Hugues Fruchet]

This adds documentation of device tree bindings for the STM32 DCMI
(Digital Camera Memory Interface).

Signed-off-by: Hugues Fruchet 
---
 .../devicetree/bindings/media/st,stm32-dcmi.txt| 77 ++
 1 file changed, 77 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/st,stm32-dcmi.txt

diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.txt 
b/Documentation/devicetree/bindings/media/st,stm32-dcmi.txt
new file mode 100644
index 000..f0dc709
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.txt
@@ -0,0 +1,77 @@
+STMicroelectronics STM32 Digital Camera Memory Interface (DCMI)
+
+Required properties:
+- compatible: "st,stm32-dcmi"
+- reg: physical base address and length of the registers set for the device;
+- interrupts: should contain IRQ line for the DCMI;
+- clocks: list of clock specifiers, corresponding to entries in
+  the clock-names property;
+- clock-names: must contain "mclk", which is the DCMI peripherial clock.
+- resets: Reference to a reset controller
+- reset-names: see Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
+
+DCMI supports a single port node with parallel bus. It should contain one
+'port' child node with child 'endpoint' node. Please refer to the bindings
+defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+Device node example
+---
+   dcmi: dcmi@5005 {
+   compatible = "st,stm32-dcmi";
+   reg = <0x5005 0x400>;
+   interrupts = <78>;
+   resets = < STM32F4_AHB2_RESET(DCMI)>;
+   clocks = < 0 STM32F4_AHB2_CLOCK(DCMI)>;
+   clock-names = "mclk";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   dmas = < 1 1 0x414 0x3>;
+   dma-names = "tx";
+   status = "disabled";
+   };
+
+Board setup example
+---
+
+ {
+   status = "okay";
+
+   port {
+   dcmi_0: endpoint@0 {
+   remote-endpoint = <_0>;
+   bus-width = <8>;
+   hsync-active = <0>;
+   vsync-active = <0>;
+   pclk-sample = <1>;
+   };
+   };
+};
+
+{
+   [...]
+   i2c@0 {
+   ov2640: camera@30 {
+   compatible = "ovti,ov2640";
+   reg = <0x30>;
+   resetb-gpios = < 2 GPIO_ACTIVE_HIGH>;
+   pwdn-gpios = < 0 GPIO_ACTIVE_LOW>;
+   clocks = <_ext_camera>;
+   clock-names = "xvclk";
+   status = "okay";
+
+   port {
+   ov2640_0: endpoint {
+   remote-endpoint = <_0>;
+   };
+   };
+   };
+   };
+
+   clk_ext_camera: clk-ext-camera {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2400>;
+   };
+}
-- 
1.9.1

[PATCH v1 7/8] ARM: configs: stm32: stmpe 1600 GPIO expandor

[Hugues Fruchet]

Enable STMPE1600 GPIO expandor.

Signed-off-by: Hugues Fruchet 
---
 arch/arm/configs/stm32_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index a9d8e3c..84adc88 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -49,6 +49,8 @@ CONFIG_SERIAL_STM32_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
 # CONFIG_HWMON is not set
 CONFIG_REGULATOR=y
+CONFIG_GPIO_STMPE=y
+CONFIG_MFD_STMPE=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
 # CONFIG_USB_SUPPORT is not set
 CONFIG_NEW_LEDS=y
-- 
1.9.1

[PATCH v1 0/8] Add support for DCMI camera interface of STMicroelectronics STM32 SoC series

[Hugues Fruchet]

This patchset introduces a basic support for Digital Camera Memory Interface
(DCMI) of STMicroelectronics STM32 SoC series.

This first basic support implements RGB565 & YUV frame grabbing.
Cropping and JPEG support will be added later on.

This has been tested on STM324x9I-EVAL evaluation board embedding
an OV2640 camera sensor.

This driver depends on:
  - [PATCHv6 00/14] atmel-isi/ov7670/ov2640: convert to standalone drivers 
http://www.spinics.net/lists/linux-media/msg113480.html

===
= history =
===
version 1:
  - Initial submission

===
= v4l2-compliance =
===
Below is the v4l2-compliance report for this current version of the DCMI camera 
interface.
v4l2-compliance has been built from v4l-utils-1.12.3.

v4l2-compliance SHA   : f5f45e17ee98a0ebad7836ade2b34ceec909d751

Driver Info:
Driver name   : stm32-dcmi
Card type : STM32 Digital Camera Memory Int
Bus info  : platform:dcmi
Driver version: 4.11.0
Capabilities  : 0x8521
Video Capture
Read/Write
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x0521
Video Capture
Read/Write
Streaming
Extended Pix Format

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

Required ioctls:
test VIDIOC_QUERYCAP: OK

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

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK

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

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

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

Test input 0:

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

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

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

Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK

Test input 0:

Streaming ioctls:
test read/write: OK
test MMAP: OK
test USERPTR: OK (Not Supported)
test DMABUF: Cannot test, specify --expbuf-device


Total: 46, Succeeded: 46, Failed: 0, Warnings: 0

Hugues Fruchet (8):
  dt-bindings: Document STM32 DCMI bindings
  [media] stm32-dcmi: STM32 DCMI camera interface driver
  ARM: dts: stm32: Enable DCMI support on STM32F429 MCU
  ARM: dts: stm32: Enable DCMI camera interface on STM32F429-EVAL board
  ARM: dts: stm32: Enable stmpe1600 gpio expandor of STM32F429-EVAL
board
  ARM: dts: stm32: Enable ov2640 camera support of STM32F429-EVAL board
  ARM: configs: stm32: stmpe 1600 GPIO expandor
  ARM: configs: stm32: DCMI + OV2640 camera support

 .../devicetree/bindings/media/st,stm32-dcmi.txt|   77 ++
 arch/arm/boot/dts/stm32429i-eval.dts   |   56 +
 arch/arm/boot/dts/stm32f429.dtsi   |   37 +
 arch/arm/configs/stm32_defconfig   |9 +
 drivers/media/platform/Kconfig

Re: [PATCH 0/3] Handling of reduced FPS in V4L2

[Jose Abreu]

Hi Hans,


On 28-03-2017 11:07, Hans Verkuil wrote:
> On 27/03/17 13:58, Jose Abreu wrote:
>> Hi Hans,
>>
>>
>> On 24-03-2017 12:28, Hans Verkuil wrote:
>>> On 03/24/17 13:21, Jose Abreu wrote:
 Hi Hans,


 On 24-03-2017 12:12, Hans Verkuil wrote:
> On 03/24/17 12:52, Jose Abreu wrote:
>> Hi Hans,
>>
>>
 Can you please review this series, when possible? And if you
 could test it on cobalt it would be great :)
>>> Hopefully next week. 
>> Thanks :)
>>
>>> Did you have some real-world numbers w.r.t. measured
>>> pixelclock frequencies and 60 vs 59.94 Hz and 24 vs 23.976 Hz?
>> I did make some measurements but I'm afraid I didn't yet test
>> with many sources (I mostly tested with signal generators which
>> should have a higher precision clock than real sources). I have a
>> bunch of players here, I will test them as soon as I can.
>> Regarding precision: for our controller is theoretically and
>> effectively enough: The worst case is for 640x480, and even in
>> that case the difference between 60Hz and 59.94Hz is > 1 unit of
>> the measuring register. This still doesn't solve the problem of
>> having a bad source with a bad clock, but I don't know if we can
>> do much more about that.
> I would really like to see a table with different sources sending
> these different framerates and the value that your HW detects.
>
> If there is an obvious and clear difference, then this feature makes
> sense. If it is all over the place, then I need to think about this
> some more.
>
> To be honest, I expect that you will see 'an obvious and clear'
> difference, but that is no more than a gut feeling at the moment and
> I would like to see some proper test results.
 Ok, I will make a table. The test procedure will be like this:
 - Measure pixel clock value using certified HDMI analyzer
 - Measure pixel clock using our controller
 - Compare the values obtained from analyzer, controller and
 the values that the source is telling to send (the value
 displayed in source menu for example [though, some of them may
 not discriminate the exact frame rate, thats why analyzer should
 be used also]).

 Seems ok? I will need some time, something like a week because my
 setup was "borrowed".
>>> That sounds good. Sorry for adding to your workload, but there is no
>>> point to have a flag that in practice is meaningless.
>>>
>>> I'm actually very curious about the results!
>> I managed to do the tests but unfortunately I can't publish the
>> full results (at least until I get approval).
>>
>> I can say that the results look good. As you expected we have
>> some sources with a bad clock but this is correctly detected by
>> the controller (and also by the HDMI analyzer).
>>
>> Using the v4l2_calc_framerate function I managed to get this:
>>
>> | Source   | Resolution  | v4l2_calc_framerate()
>> --
>> | Analyzer 1 | 640x480@59.94 | 59.92
>> | Analyzer 1 | 640x480@60  | 60
>> | Analyzer 1 | 1920x1080@60  | 60
>> | Player 1 | 1920x1080@59.94 | 59.94
>> | Player 2 | 1920x1080@59.94 | 59.93
>> | Player 3 | 3840x2160@59.94 | 59.94
>> | Player 4 | 1920x1080@59.94 | 59.94
>> | Player 5 | 1920x1080@59.94 | 59.93
>> | Player 6 | 1280x720@50| 50
>> | Player 7 | 1920x1080@59.94 | 59.93
>> | Player 8 | 1920x1080@60  | 60
>> | Analyzer 2 | 720x480@59.94 | 59.94
>> | Analyzer 2 | 720x480@60  | 60
>> | Analyzer 2 | 1920x1080@59.94 | 59.93
>> | Analyzer 2 | 1920x180@60| 60
>> | Analyzer 2 | 3840x2160@23.98 | 23.97
>> | Analyzer 2 | 3840x2160@24  | 24
>> | Analyzer 2 | 3840x2160@29.97 | 29.96
>> | Analyzer 2 | 3840x2160@30  | 30
>> | Analyzer 2 | 3840x2160@59.94 | 59.93
>> | Analyzer 2 | 3840x2160@60  | 60
> Nice!
>
> Are the sources with a bad clock included in these results? I only see 
> deviations
> of 0.02 at most, so I don't think so.

The results include all the sources I have to test (Player x
indicates a real player available in the market while Analyzer x
indicates HDMI protocol analyzer). From the data I've collected
the players are the ones with the less precise clock, thats what
I was referring as a bad clock. But even with that deviations the
algorithm computes the value ok. I think I don't have any player
else to test here. Maybe, if you could, test the patch series
with cobalt + adv with a player and check the precision? ( I
think cobalt uses an adv as subdev, right? )

>
>> --
>>
>> What do you think? Shall we continue integrating this new patch
>> or drop it?
> Yes, we can continue. This is what 

[PATCH v1 6/8] ARM: dts: stm32: Enable ov2640 camera support of STM32F429-EVAL board

[Hugues Fruchet]

Signed-off-by: Hugues Fruchet 
---
 arch/arm/boot/dts/stm32429i-eval.dts | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/stm32429i-eval.dts 
b/arch/arm/boot/dts/stm32429i-eval.dts
index 7ffcf07..b7d127c 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -48,6 +48,7 @@
 /dts-v1/;
 #include "stm32f429.dtsi"
 #include 
+#include 
 
 / {
model = "STMicroelectronics STM32429i-EVAL board";
@@ -66,6 +67,14 @@
serial0 = 
};
 
+   clocks {
+   clk_ext_camera: clk-ext-camera {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2400>;
+   };
+   };
+
soc {
dma-ranges = <0xc000 0x0 0x1000>;
};
@@ -146,6 +155,11 @@
 
port {
dcmi_0: endpoint@0 {
+   remote-endpoint = <_0>;
+   bus-width = <8>;
+   hsync-active = <0>;
+   vsync-active = <0>;
+   pclk-sample = <1>;
};
};
 };
@@ -155,6 +169,22 @@
pinctrl-names = "default";
status = "okay";
 
+   ov2640: camera@30 {
+   compatible = "ovti,ov2640";
+   reg = <0x30>;
+   resetb-gpios = < 2 GPIO_ACTIVE_HIGH>;
+   pwdn-gpios = < 0 GPIO_ACTIVE_LOW>;
+   clocks = <_ext_camera>;
+   clock-names = "xvclk";
+   status = "okay";
+
+   port {
+   ov2640_0: endpoint {
+   remote-endpoint = <_0>;
+   };
+   };
+   };
+
stmpe1600: stmpe1600@42 {
compatible = "st,stmpe1600";
reg = <0x42>;
-- 
1.9.1

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

[Hugues Fruchet]

This V4L2 subdev driver enables Digital Camera Memory Interface (DCMI)
of STMicroelectronics STM32 SoC series.

Signed-off-by: Yannick Fertre 
Signed-off-by: Hugues Fruchet 
---
 drivers/media/platform/Kconfig|   12 +
 drivers/media/platform/Makefile   |2 +
 drivers/media/platform/stm32/Makefile |1 +
 drivers/media/platform/stm32/stm32-dcmi.c | 1417 +
 4 files changed, 1432 insertions(+)
 create mode 100644 drivers/media/platform/stm32/Makefile
 create mode 100644 drivers/media/platform/stm32/stm32-dcmi.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ab0bb48..3421965 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -114,6 +114,18 @@ config VIDEO_S3C_CAMIF
  To compile this driver as a module, choose M here: the module
  will be called s3c-camif.
 
+config VIDEO_STM32_DCMI
+   tristate "Digital Camera Memory Interface (DCMI) support"
+   depends on VIDEO_V4L2 && OF && HAS_DMA
+   depends on ARCH_STM32 || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   ---help---
+ This module makes the STM32 Digital Camera Memory Interface (DCMI)
+ available as a v4l2 device.
+
+ To compile this driver as a module, choose M here: the module
+ will be called stm32-dcmi.
+
 source "drivers/media/platform/soc_camera/Kconfig"
 source "drivers/media/platform/exynos4-is/Kconfig"
 source "drivers/media/platform/am437x/Kconfig"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 8959f6e..d747715 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -64,6 +64,8 @@ obj-$(CONFIG_VIDEO_RCAR_VIN)  += rcar-vin/
 
 obj-$(CONFIG_VIDEO_ATMEL_ISC)  += atmel/
 
+obj-$(CONFIG_VIDEO_STM32_DCMI) += stm32/
+
 ccflags-y += -I$(srctree)/drivers/media/i2c
 
 obj-$(CONFIG_VIDEO_MEDIATEK_VPU)   += mtk-vpu/
diff --git a/drivers/media/platform/stm32/Makefile 
b/drivers/media/platform/stm32/Makefile
new file mode 100644
index 000..9b606a7
--- /dev/null
+++ b/drivers/media/platform/stm32/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_STM32_DCMI) += stm32-dcmi.o
diff --git a/drivers/media/platform/stm32/stm32-dcmi.c 
b/drivers/media/platform/stm32/stm32-dcmi.c
new file mode 100644
index 000..2f0286b
--- /dev/null
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -0,0 +1,1417 @@
+/*
+ * Driver for STM32 Digital Camera Memory Interface
+ *
+ * Copyright (C) STMicroelectronics SA 2017
+ * Authors: Yannick Fertre 
+ *  Hugues Fruchet 
+ *  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ *
+ * This driver is based on atmel_isi.c
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME "stm32-dcmi"
+
+/* Registers offset for DCMI */
+#define DCMI_CR0x00 /* Control Register */
+#define DCMI_SR0x04 /* Status Register */
+#define DCMI_RIS   0x08 /* Raw Interrupt Status register */
+#define DCMI_IER   0x0C /* Interrupt Enable Register */
+#define DCMI_MIS   0x10 /* Masked Interrupt Status register */
+#define DCMI_ICR   0x14 /* Interrupt Clear Register */
+#define DCMI_ESCR  0x18 /* Embedded Synchronization Code Register */
+#define DCMI_ESUR  0x1C /* Embedded Synchronization Unmask Register */
+#define DCMI_CWSTRT0x20 /* Crop Window STaRT */
+#define DCMI_CWSIZE0x24 /* Crop Window SIZE */
+#define DCMI_DR0x28 /* Data Register */
+#define DCMI_IDR   0x2c /* IDentifier Register */
+
+/* Bits definition for control register (DCMI_CR) */
+#define CR_CAPTURE BIT(0)
+#define CR_CM  BIT(1)
+#define CR_CROPBIT(2)
+#define CR_JPEGBIT(3)
+#define CR_ESS BIT(4)
+#define CR_PCKPOL  BIT(5)
+#define CR_HSPOL   BIT(6)
+#define CR_VSPOL   BIT(7)
+#define CR_FCRC_0  BIT(8)
+#define CR_FCRC_1  BIT(9)
+#define CR_EDM_0   BIT(10)
+#define CR_EDM_1   BIT(11)
+#define CR_ENABLE  BIT(14)
+
+/* Bits definition for status register (DCMI_SR) */
+#define SR_HSYNC   BIT(0)
+#define SR_VSYNC   BIT(1)
+#define SR_FNE BIT(2)
+
+/*
+ * Bits definition for interrupt registers
+ * (DCMI_RIS, DCMI_IER, DCMI_MIS, DCMI_ICR)
+ */
+#define IT_FRAME   BIT(0)
+#define IT_OVR BIT(1)
+#define IT_ERR BIT(2)
+#define IT_VSYNC   BIT(3)
+#define IT_LINEBIT(4)
+
+enum state {
+   STOPPED = 0,
+   RUNNING,
+   STOPPING,
+};
+
+#define MAX_BUS_WIDTH  14
+#define MAX_SUPPORT_WIDTH  2048
+#define MAX_SUPPORT_HEIGHT 2048

Re: [PATCH RFC] [media] m5mols: add missing dependency on VIDEO_IR_I2C

[Nicholas Mc Guire]

On Wed, Mar 29, 2017 at 11:56:08AM +0200, Sylwester Nawrocki wrote:
> On 12/13/2016 06:44 AM, Nicholas Mc Guire wrote:
> >The Depends on: tag in Kconfig for CONFIG_VIDEO_M5MOLS does not list
> >VIDEO_IR_I2C so Kconfig displays the dependencies needed so the M-5MOLS
> >driver can not be found.
> >
> >Fixes: commit cb7a01ac324b ("[media] move i2c files into drivers/media/i2c")
> >Signed-off-by: Nicholas Mc Guire 
> >---
> >
> >searching for VIDEO_M5MOLS in menuconfig currently shows the following
> >dependencies
> > Depends on: MEDIA_SUPPORT [=m] && I2C [=y] && VIDEO_V4L2 [=m] && \
> > VIDEO_V4L2_SUBDEV_API [=y] && MEDIA_CAMERA_SUPPORT [=y]
> >but as the default settings include MEDIA_SUBDRV_AUTOSELECT=y the
> >"I2C module for IR" submenu (CONFIG_VIDEO_IR_I2C) is not displayed
> >adding the VIDEO_IR_I2C to the dependency list makes this clear
> 
> > drivers/media/i2c/m5mols/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/drivers/media/i2c/m5mols/Kconfig 
> >b/drivers/media/i2c/m5mols/Kconfig
> >index dc8c250..6847a1b 100644
> >--- a/drivers/media/i2c/m5mols/Kconfig
> >+++ b/drivers/media/i2c/m5mols/Kconfig
> >@@ -1,6 +1,6 @@
> > config VIDEO_M5MOLS
> > tristate "Fujitsu M-5MOLS 8MP sensor support"
> >-depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> >+depends on I2C && VIDEO_IR_I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> 
> There should be no need to enable the "I2C module for IR" to use m5mols
> driver, so the bug fix needs to be somewhere else.
>
yup - my bad - not clear how I came to that conclusion, guess it was due
to the indirection of VIDEO_M5MOLS needing !CONFIG_MEDIA_SUBDRV_AUTOSELECT

Step-by-step its:

0) x86_64_defconfig
  Depends on: MEDIA_SUPPORT [=n] && I2C [=y] && VIDEO_V4L2 [=n] && 
VIDEO_V4L2_SUBDEV_API [=n] && MEDIA_CAMERA_SUPPORT [=n]

1)  Multimedia support  --->
 Depends on: MEDIA_SUPPORT [=m] && I2C [=y] && VIDEO_V4L2 [=n] && 
VIDEO_V4L2_SUBDEV_API [=n] && MEDIA_CAMERA_SUPPORT [=n]

2)[*]   Cameras/video grabbers support
 Depends on: MEDIA_SUPPORT [=m] && I2C [=y] && VIDEO_V4L2 [=m] && 
VIDEO_V4L2_SUBDEV_API [=n] && MEDIA_CAMERA_SUPPORT [=y]

3)[*]   Media Controller API (NEW)
  [*]   V4L2 sub-device userspace API (NEW)
 Depends on: MEDIA_SUPPORT [=m] && I2C [=y] && VIDEO_V4L2 [=m] && 
VIDEO_V4L2_SUBDEV_API [=y] && MEDIA_CAMERA_SUPPORT [=y]

So now all listed dependencies are satisfied but the M-5MOLS drive is not
visible du to default CONFIG_MEDIA_SUBDRV_AUTOSELECT=y

Not sure how I ended up with the VIDEO_IR_I2C dependency - which as you 
state - is wrong. though VIDEO_M5MOLS probably needs a 
!CONFIG_MEDIA_SUBDRV_AUTOSELECT in the dependency list though.

thx!
hofrat 

Re: [PATCH RFC] [media] m5mols: add missing dependency on VIDEO_IR_I2C

[Sylwester Nawrocki]

On 12/13/2016 06:44 AM, Nicholas Mc Guire wrote:

The Depends on: tag in Kconfig for CONFIG_VIDEO_M5MOLS does not list
VIDEO_IR_I2C so Kconfig displays the dependencies needed so the M-5MOLS
driver can not be found.

Fixes: commit cb7a01ac324b ("[media] move i2c files into drivers/media/i2c")
Signed-off-by: Nicholas Mc Guire 
---

searching for VIDEO_M5MOLS in menuconfig currently shows the following
dependencies
 Depends on: MEDIA_SUPPORT [=m] && I2C [=y] && VIDEO_V4L2 [=m] && \
 VIDEO_V4L2_SUBDEV_API [=y] && MEDIA_CAMERA_SUPPORT [=y]
but as the default settings include MEDIA_SUBDRV_AUTOSELECT=y the
"I2C module for IR" submenu (CONFIG_VIDEO_IR_I2C) is not displayed
adding the VIDEO_IR_I2C to the dependency list makes this clear



 drivers/media/i2c/m5mols/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/m5mols/Kconfig b/drivers/media/i2c/m5mols/Kconfig
index dc8c250..6847a1b 100644
--- a/drivers/media/i2c/m5mols/Kconfig
+++ b/drivers/media/i2c/m5mols/Kconfig
@@ -1,6 +1,6 @@
 config VIDEO_M5MOLS
tristate "Fujitsu M-5MOLS 8MP sensor support"
-   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on I2C && VIDEO_IR_I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API


There should be no need to enable the "I2C module for IR" to use m5mols driver, 
so the bug fix needs to be somewhere else.


--
Thanks,
Sylwester

Re: [RFC PATCHv2 00/21] Ion clean in preparation for moving out of staging

[Benjamin Gaignard]

2017-03-18 1:54 GMT+01:00 Laura Abbott :
>
> Hi,
>
> This is v2 of the series to do some serious Ion clean up in preparation for
> moving out of staging. I got good feedback last time so this series mostly
> attempts to address that feedback and do more still more cleanup. Highlights:
>
> - All calls to DMA APIs should now be with a real actual proper device
>   structure
> - Patch to stop setting sg_dma_address manually now included
> - Fix for a bug in the query interface
> - Removal of custom ioctl interface
> - Removal of import interface
> - Removal of any notion of using Ion as an in kernel interface.
> - Cleanup of ABI so compat interface is no longer needed
> - Deletion of a bit more platform code
> - Combined heap enumeration and heap registration code up so there are fewer
>   layers of abstraction
> - Some general cleanup and header reduction.
> - Removal of both the ion_client and ion_handle structures since these mostly
>   become redundant. As a result, Ion only returns a dma_buf fd. The overall
>   result is that the only Ion interfaces are the query ioctl and the alloc
>   ioctl.
>
> The following are still TODOs/open problems:
> - Sumit's comments about the CMA naming.
> - Bindings/platform for chunk and carveout heap
> - There was some discussion about making the sg_table duplication generic. I
>   got bogged down in handling some of the edge cases for generic handling
>   so I put this aside. Making it generic is still something that should 
> happen.
> - More fine-grained support for restricting heap access. There are good
>   arguments to be made for having a way for having good integration with
>   selinux and other policy mechanisms.
> - While not on the original list, there is still no good good test standalone
>   test framework. I noticed that the existing ion_test was fairly generic so I
>   proposed moving it to dma_buf. Daniel Vetter suggested just using the VGEM
>   module instead. Ideally, the tests can live as part of some other existing
>   test set (drm tests maybe?)
>
> Feedback appreciated as always.

Thanks for this v2, it really clean up and simplify ION.

For me the last question mark is about restricting heap access with
SElinux policy.
Since I haven't see other proposals I still believe that we should
have a /dev/ion/$heapname
per heap.

>
> Thanks,
> Laura
>
> Laura Abbott (21):
>   cma: Store a name in the cma structure
>   cma: Introduce cma_for_each_area
>   staging: android: ion: Remove dmap_cnt
>   staging: android: ion: Remove alignment from allocation field
>   staging: android: ion: Duplicate sg_table
>   staging: android: ion: Call dma_map_sg for syncing and mapping
>   staging: android: ion: Remove page faulting support
>   staging: android: ion: Remove crufty cache support
>   staging: android: ion: Remove custom ioctl interface
>   staging: android: ion: Remove import interface
>   staging: android: ion: Remove duplicate ION_IOC_MAP
>   staging: android: ion: Remove old platform support
>   staging: android: ion: Use CMA APIs directly
>   staging: android: ion: Stop butchering the DMA address
>   staging: android: ion: Break the ABI in the name of forward progress
>   staging: android: ion: Get rid of ion_phys_addr_t
>   staging: android: ion: Collapse internal header files
>   staging: android: ion: Rework heap registration/enumeration
>   staging: android: ion: Drop ion_map_kernel interface
>   staging: android: ion: Remove ion_handle and ion_client
>   staging: android: ion: Set query return value
>
>  drivers/base/dma-contiguous.c  |5 +-
>  drivers/staging/android/ion/Kconfig|   56 +-
>  drivers/staging/android/ion/Makefile   |   18 +-
>  drivers/staging/android/ion/compat_ion.c   |  195 
>  drivers/staging/android/ion/compat_ion.h   |   29 -
>  drivers/staging/android/ion/hisilicon/Kconfig  |5 -
>  drivers/staging/android/ion/hisilicon/Makefile |1 -
>  drivers/staging/android/ion/hisilicon/hi6220_ion.c |  113 --
>  drivers/staging/android/ion/ion-ioctl.c|   85 +-
>  drivers/staging/android/ion/ion.c  | 1164 
> +++-
>  drivers/staging/android/ion/ion.h  |  393 +--
>  drivers/staging/android/ion/ion_carveout_heap.c|   37 +-
>  drivers/staging/android/ion/ion_chunk_heap.c   |   27 +-
>  drivers/staging/android/ion/ion_cma_heap.c |  125 +--
>  drivers/staging/android/ion/ion_dummy_driver.c |  156 ---
>  drivers/staging/android/ion/ion_heap.c |   68 --
>  drivers/staging/android/ion/ion_of.c   |  184 
>  drivers/staging/android/ion/ion_of.h   |   37 -
>  drivers/staging/android/ion/ion_page_pool.c|6 +-
>  drivers/staging/android/ion/ion_priv.h |  473 
>  drivers/staging/android/ion/ion_system_heap.c  |   53 +-
>  drivers/staging/android/ion/ion_test.c |  305 -
>  

Re: [RFC PATCHv2 02/21] cma: Introduce cma_for_each_area

[Benjamin Gaignard]

2017-03-18 1:54 GMT+01:00 Laura Abbott :
>
> Frameworks (e.g. Ion) may want to iterate over each possible CMA area to
> allow for enumeration. Introduce a function to allow a callback.

even outside ION rework that could be useful

Reviewed-by: Benjamin Gaignard 

>
> Signed-off-by: Laura Abbott 
> ---
>  include/linux/cma.h |  2 ++
>  mm/cma.c| 14 ++
>  2 files changed, 16 insertions(+)
>
> diff --git a/include/linux/cma.h b/include/linux/cma.h
> index d41d1f8..3e8fbf5 100644
> --- a/include/linux/cma.h
> +++ b/include/linux/cma.h
> @@ -34,4 +34,6 @@ extern int cma_init_reserved_mem(phys_addr_t base, 
> phys_addr_t size,
>  extern struct page *cma_alloc(struct cma *cma, size_t count, unsigned int 
> align,
>   gfp_t gfp_mask);
>  extern bool cma_release(struct cma *cma, const struct page *pages, unsigned 
> int count);
> +
> +extern int cma_for_each_area(int (*it)(struct cma *cma, void *data), void 
> *data);
>  #endif
> diff --git a/mm/cma.c b/mm/cma.c
> index 0d187b1..9a040e1 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -498,3 +498,17 @@ bool cma_release(struct cma *cma, const struct page 
> *pages, unsigned int count)
>
> return true;
>  }
> +
> +int cma_for_each_area(int (*it)(struct cma *cma, void *data), void *data)
> +{
> +   int i;
> +
> +   for (i = 0; i < cma_area_count; i++) {
> +   int ret = it(_areas[i], data);
> +
> +   if (ret)
> +   return ret;
> +   }
> +
> +   return 0;
> +}
> --
> 2.7.4
>



-- 
Benjamin Gaignard

Graphic Study Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v7] [media] vimc: Virtual Media Controller core, capture and sensor

[Sakari Ailus]

Hi Hans,

On Wed, Mar 29, 2017 at 09:49:05AM +0200, Hans Verkuil wrote:
> On 28/03/17 22:37, Sakari Ailus wrote:
> > Hi Mauro,
> > 
> > On Tue, Mar 28, 2017 at 08:38:26AM -0300, Mauro Carvalho Chehab wrote:
> >> Em Tue, 28 Mar 2017 12:00:36 +0200
> >> Hans Verkuil  escreveu:
> >>
> >>> On 27/03/17 20:09, Mauro Carvalho Chehab wrote:
>  Em Mon, 27 Mar 2017 12:19:51 -0300
>  Helen Koike  escreveu:
>    
> > Hi Sakari,
> >
> > On 2017-03-26 10:31 AM, Sakari Ailus wrote:  
> >> Hi Helen,
> >>
> >> ...
> >>> +static int vimc_cap_enum_input(struct file *file, void *priv,
> >>> +struct v4l2_input *i)
> >>> +{
> >>> + /* We only have one input */
> >>> + if (i->index > 0)
> >>> + return -EINVAL;
> >>> +
> >>> + i->type = V4L2_INPUT_TYPE_CAMERA;
> >>> + strlcpy(i->name, "VIMC capture", sizeof(i->name));
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static int vimc_cap_g_input(struct file *file, void *priv, unsigned 
> >>> int *i)
> >>> +{
> >>> + /* We only have one input */
> >>> + *i = 0;
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static int vimc_cap_s_input(struct file *file, void *priv, unsigned 
> >>> int i)
> >>> +{
> >>> + /* We only have one input */
> >>> + return i ? -EINVAL : 0;
> >>> +}
> >>
> >> You can drop the input IOCTLs altogether here. If you had e.g. a TV
> >> tuner, it'd be the TV tuner driver's responsibility to implement them.
> >>
> >
> > input IOCTLs seems to be mandatory from v4l2-compliance when capability 
> > V4L2_CAP_VIDEO_CAPTURE is set (which is the case):
> >
> > https://git.linuxtv.org/v4l-utils.git/tree/utils/v4l2-compliance/v4l2-test-input-output.cpp#n418
> >
> > https://git.linuxtv.org/v4l-utils.git/tree/utils/v4l2-compliance/v4l2-compliance.cpp#n989
> >   
> 
>  The V4L2 spec doesn't actually define what's mandatory and what's
>  optional. The idea that was agreed on one of the media summits
>  were to define a set of profiles for different device types,
>  matching the features required by existing applications to work,
>  but this was never materialized.
> 
>  So, my understanding is that any driver can implement
>  any V4L2 ioctl.
> 
>  Yet, some applications require enum/get/set inputs, or otherwise
>  they wouldn't work. It is too late to change this behavior. 
>  So, either the driver or the core should implement those
>  ioctls, in order to avoid breaking backward-compatibility.  
> >>>
> >>> The closest we have to determining which ioctls are mandatory or not is
> >>> v4l2-compliance.
> >>
> >> Yes, but we should explicitly document what's mandatory at the V4L2
> >> API spec and mention the v4l2-compliance tool there.
> >>
> >>> That said, v4l2-compliance is actually a bit more strict
> >>> in some cases than the spec since some ioctls are optional in the spec, 
> >>> but
> >>> required in v4l2-compliance for the simple reason that there is no reason
> >>> for drivers NOT to implement those ioctls.
> >>>
> >>> However, the v4l2-compliance test was never written for MC devices. It 
> >>> turns
> >>> out that it works reasonably well as long as a working pipeline is 
> >>> configured
> >>> first, but these input ioctls are a bit iffy.
> >>
> >> The way I see, v4l2-compliance V4L2 API check[1] should not be modified to
> >> explicitly support devices with MC and/or subdev API.
> > 
> > The V4L2 API documentation states that
> > 
> > Video inputs and outputs are physical connectors of a device. ...
> > Drivers must implement all the input ioctls when the device has one
> > or more inputs, all the output ioctls when the device has one or
> > more outputs.
> > 
> > "Inputs" and "outputs", as the spec defines them, mean physical connectors
> > to the device.
> > 
> > Does e.g. a camera have a physical connector? I don't think one could
> > imagine it does, meaning also there is no need to implement these IOCTLs.
> > 
> > That said, I looked at a few drivers and even the omap3isp driver implements
> > the input IOCTLs. It provides no useful information whatsoever through them,
> > just like most drivers whose hardware has no physical connectors.
> > 
> > Still the bottom line is that the spec does not require them.
> 
> The spec isn't gospel. The reality is that all non-MC drivers have these 
> ioctls
> and a sensor is considered to be an input.
> 
> Section 4.1.2 says: "The video input and video standard ioctls must be 
> supported
> by all video capture devices.". Which actually is also wrong since the video
> standard ioctls do not make sense for DV inputs or sensors.
> 
> I'll make a patch correcting these issues.

I'm far from certain that providing an additional 

Re: [PATCH v6 02/39] [media] dt-bindings: Add bindings for i.MX media driver

[Russell King - ARM Linux]

On Tue, Mar 28, 2017 at 07:21:34PM -0500, Rob Herring wrote:
> On Mon, Mar 27, 2017 at 7:40 PM, Steve Longerbeam  
> wrote:
> > Add bindings documentation for the i.MX media driver.
> >
> > Signed-off-by: Steve Longerbeam 
> > ---
> >  Documentation/devicetree/bindings/media/imx.txt | 74 
> > +
> >  1 file changed, 74 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/media/imx.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/imx.txt 
> > b/Documentation/devicetree/bindings/media/imx.txt
> > new file mode 100644
> > index 000..3059c06
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/imx.txt
> > @@ -0,0 +1,74 @@
> > +Freescale i.MX Media Video Device
> > +=
> > +
> > +Video Media Controller node
> > +---
> > +
> > +This is the media controller node for video capture support. It is a
> > +virtual device that lists the camera serial interface nodes that the
> > +media device will control.
> > +
> > +Required properties:
> > +- compatible : "fsl,imx-capture-subsystem";
> > +- ports  : Should contain a list of phandles pointing to camera
> > +   sensor interface ports of IPU devices
> > +
> > +example:
> > +
> > +capture-subsystem {
> > +   compatible = "fsl,imx-capture-subsystem";
> > +   ports = <_csi0>, <_csi1>;
> > +};
> > +
> > +fim child node
> > +--
> > +
> > +This is an optional child node of the ipu_csi port nodes. If present and
> > +available, it enables the Frame Interval Monitor. Its properties can be
> > +used to modify the method in which the FIM measures frame intervals.
> > +Refer to Documentation/media/v4l-drivers/imx.rst for more info on the
> > +Frame Interval Monitor.
> > +
> > +Optional properties:
> > +- fsl,input-capture-channel: an input capture channel and channel flags,
> > +specified as . The channel number
> > +must be 0 or 1. The flags can be
> > +IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING, or
> > +IRQ_TYPE_EDGE_BOTH, and specify which input
> > +capture signal edge will trigger the input
> > +capture event. If an input capture channel is
> > +specified, the FIM will use this method to
> > +measure frame intervals instead of via the EOF
> > +interrupt. The input capture method is much
> > +preferred over EOF as it is not subject to
> > +interrupt latency errors. However it requires
> > +routing the VSYNC or FIELD output signals of
> > +the camera sensor to one of the i.MX input
> > +capture pads (SD1_DAT0, SD1_DAT1), which also
> > +gives up support for SD1.
> > +
> > +
> > +mipi_csi2 node
> > +--
> > +
> > +This is the device node for the MIPI CSI-2 Receiver, required for MIPI
> > +CSI-2 sensors.
> > +
> > +Required properties:
> > +- compatible   : "fsl,imx6-mipi-csi2", "snps,dw-mipi-csi2";
> 
> As I mentioned in v5, there's a DW CSI2 binding in progress. This
> needs to be based on that.

Maybe someone can provide some kind of reference to it, and it's
associated driver?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v7] [media] vimc: Virtual Media Controller core, capture and sensor

[Hans Verkuil]

On 29/03/17 00:35, Nicolas Dufresne wrote:
> 
> 
> Le 28 mars 2017 4:38 PM, "Sakari Ailus"  > a écrit :
> 
> Hi Mauro,
> 
> On Tue, Mar 28, 2017 at 08:38:26AM -0300, Mauro Carvalho Chehab wrote:
> > Em Tue, 28 Mar 2017 12:00:36 +0200
> > Hans Verkuil > escreveu:
> >
> > > On 27/03/17 20:09, Mauro Carvalho Chehab wrote:
> > > > Em Mon, 27 Mar 2017 12:19:51 -0300
> > > > Helen Koike  > escreveu:
> > > >
> > > >> Hi Sakari,
> > > >>
> > > >> On 2017-03-26 10:31 AM, Sakari Ailus wrote:
> > > >>> Hi Helen,
> > > >>>
> > > >>> ...
> > >  +static int vimc_cap_enum_input(struct file *file, void *priv,
> > >  + struct v4l2_input *i)
> > >  +{
> > >  +  /* We only have one input */
> > >  +  if (i->index > 0)
> > >  +  return -EINVAL;
> > >  +
> > >  +  i->type = V4L2_INPUT_TYPE_CAMERA;
> > >  +  strlcpy(i->name, "VIMC capture", sizeof(i->name));
> > >  +
> > >  +  return 0;
> > >  +}
> > >  +
> > >  +static int vimc_cap_g_input(struct file *file, void *priv, 
> unsigned int *i)
> > >  +{
> > >  +  /* We only have one input */
> > >  +  *i = 0;
> > >  +  return 0;
> > >  +}
> > >  +
> > >  +static int vimc_cap_s_input(struct file *file, void *priv, 
> unsigned int i)
> > >  +{
> > >  +  /* We only have one input */
> > >  +  return i ? -EINVAL : 0;
> > >  +}
> > > >>>
> > > >>> You can drop the input IOCTLs altogether here. If you had e.g. a 
> TV
> > > >>> tuner, it'd be the TV tuner driver's responsibility to implement 
> them.
> > > >>>
> > > >>
> > > >> input IOCTLs seems to be mandatory from v4l2-compliance when 
> capability
> > > >> V4L2_CAP_VIDEO_CAPTURE is set (which is the case):
> > > >>
> > > >> 
> https://git.linuxtv.org/v4l-utils.git/tree/utils/v4l2-compliance/v4l2-test-input-output.cpp#n418
> 
> 
> > > >>
> > > >> 
> https://git.linuxtv.org/v4l-utils.git/tree/utils/v4l2-compliance/v4l2-compliance.cpp#n989
>  
> 
> > > >
> > > > The V4L2 spec doesn't actually define what's mandatory and what's
> > > > optional. The idea that was agreed on one of the media summits
> > > > were to define a set of profiles for different device types,
> > > > matching the features required by existing applications to work,
> > > > but this was never materialized.
> > > >
> > > > So, my understanding is that any driver can implement
> > > > any V4L2 ioctl.
> > > >
> > > > Yet, some applications require enum/get/set inputs, or otherwise
> > > > they wouldn't work. It is too late to change this behavior.
> > > > So, either the driver or the core should implement those
> > > > ioctls, in order to avoid breaking backward-compatibility.
> > >
> > > The closest we have to determining which ioctls are mandatory or not 
> is
> > > v4l2-compliance.
> >
> > Yes, but we should explicitly document what's mandatory at the V4L2
> > API spec and mention the v4l2-compliance tool there.
> >
> > > That said, v4l2-compliance is actually a bit more strict
> > > in some cases than the spec since some ioctls are optional in the 
> spec, but
> > > required in v4l2-compliance for the simple reason that there is no 
> reason
> > > for drivers NOT to implement those ioctls.
> > >
> > > However, the v4l2-compliance test was never written for MC devices. 
> It turns
> > > out that it works reasonably well as long as a working pipeline is 
> configured
> > > first, but these input ioctls are a bit iffy.
> >
> > The way I see, v4l2-compliance V4L2 API check[1] should not be modified 
> to
> > explicitly support devices with MC and/or subdev API.
> 
> The V4L2 API documentation states that
> 
> Video inputs and outputs are physical connectors of a device. ...
> Drivers must implement all the input ioctls when the device has 
> one
> or more inputs, all the output ioctls when the device has one or
> more outputs.
> 
> "Inputs" and "outputs", as the spec defines them, mean physical connectors
> to the device.
> 
> Does e.g. a camera have a physical connector? I don't think one could
> imagine it does, meaning also there is no need to implement these IOCTLs.
> 
> 
> In the case of MC drivers, could that be used to allow selecting the 

[PATCH] video.rst: a sensor is also considered to be a physical input

[Hans Verkuil]

Add the line "Camera sensors are also considered to be a video input."

In practice all non-MC drivers for sensors support the input ioctls, and the
compliance test actually tests for the presence of these ioctls. So clarify
the documentation by explicitly mentioning sensors.

Signed-off-by: Hans Verkuil 
---
diff --git a/Documentation/media/uapi/v4l/video.rst 
b/Documentation/media/uapi/v4l/video.rst
index a205fb87d566..d2bc06b064ad 100644
--- a/Documentation/media/uapi/v4l/video.rst
+++ b/Documentation/media/uapi/v4l/video.rst
@@ -8,9 +8,10 @@ Video Inputs and Outputs

 Video inputs and outputs are physical connectors of a device. These can
 be for example RF connectors (antenna/cable), CVBS a.k.a. Composite
-Video, S-Video or RGB connectors. Video and VBI capture devices have
-inputs. Video and VBI output devices have outputs, at least one each.
-Radio devices have no video inputs or outputs.
+Video, S-Video and RGB connectors. Camera sensors are also considered to
+be a video input. Video and VBI capture devices have inputs. Video and
+VBI output devices have outputs, at least one each. Radio devices have
+no video inputs or outputs.

 To learn about the number and attributes of the available inputs and
 outputs applications can enumerate them with the

[PATCH] dev-capture.rst/dev-output.rst: video standards ioctls are optional

[Hans Verkuil]

The documentation for video capture and output devices claims that the video 
standard
ioctls are required. This is not the case, they are only required for 
PAL/NTSC/SECAM
type inputs and outputs. Sensors do not implement this at all and e.g. HDMI 
inputs
implement the DV Timings ioctls.

Just drop the mention of 'video standard' ioctls.

Signed-off-by: Hans Verkuil 
---
diff --git a/Documentation/media/uapi/v4l/dev-capture.rst 
b/Documentation/media/uapi/v4l/dev-capture.rst
index 32b32055d070..4218742ab5d9 100644
--- a/Documentation/media/uapi/v4l/dev-capture.rst
+++ b/Documentation/media/uapi/v4l/dev-capture.rst
@@ -42,8 +42,8 @@ Video capture devices shall support :ref:`audio input 
`,
 :ref:`tuner`, :ref:`controls `,
 :ref:`cropping and scaling ` and
 :ref:`streaming parameter ` ioctls as needed. The
-:ref:`video input ` and :ref:`video standard `
-ioctls must be supported by all video capture devices.
+:ref:`video input ` ioctls must be supported by all video
+capture devices.


 Image Format Negotiation
diff --git a/Documentation/media/uapi/v4l/dev-output.rst 
b/Documentation/media/uapi/v4l/dev-output.rst
index 25ae8ec96fdf..342eb4931f5c 100644
--- a/Documentation/media/uapi/v4l/dev-output.rst
+++ b/Documentation/media/uapi/v4l/dev-output.rst
@@ -40,8 +40,8 @@ Video output devices shall support :ref:`audio output 
`,
 :ref:`modulator `, :ref:`controls `,
 :ref:`cropping and scaling ` and
 :ref:`streaming parameter ` ioctls as needed. The
-:ref:`video output ` and :ref:`video standard `
-ioctls must be supported by all video output devices.
+:ref:`video output ` ioctls must be supported by all video
+output devices.


 Image Format Negotiation

[PATCH v3] [media] staging: css2400: fix checkpatch error

[Haim Daniel]

isp_capture_defs.h: clean up ERROR: Macros with complex values should be 
enclosed in parentheses

Signed-off-by: Haim Daniel 
---
 .../pci/atomisp2/css2400/css_2401_csi2p_system/hrt/isp_capture_defs.h   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/css_2401_csi2p_system/hrt/isp_capture_defs.h
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/css_2401_csi2p_system/hrt/isp_capture_defs.h
index aa413df..117c7a2 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/css_2401_csi2p_system/hrt/isp_capture_defs.h
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/css_2401_csi2p_system/hrt/isp_capture_defs.h
@@ -19,7 +19,7 @@
 #define _ISP_CAPTURE_BITS_PER_ELEM32  /* only for data, not 
SOP */
 #define _ISP_CAPTURE_BYTES_PER_ELEM   
(_ISP_CAPTURE_BITS_PER_ELEM/8)  
 #define _ISP_CAPTURE_BYTES_PER_WORD   32   /* 256/8 */ 
-#define _ISP_CAPTURE_ELEM_PER_WORD_ISP_CAPTURE_BYTES_PER_WORD 
/ _ISP_CAPTURE_BYTES_PER_ELEM   
+#define _ISP_CAPTURE_ELEM_PER_WORD(_ISP_CAPTURE_BYTES_PER_WORD 
/ _ISP_CAPTURE_BYTES_PER_ELEM)
 
 //#define CAPT_RCV_ACK  1
 //#define CAPT_WRT_ACK  2   
-- 
1.9.1

Re: [PATCH v7] [media] vimc: Virtual Media Controller core, capture and sensor

[Hans Verkuil]

On 28/03/17 22:37, Sakari Ailus wrote:
> Hi Mauro,
> 
> On Tue, Mar 28, 2017 at 08:38:26AM -0300, Mauro Carvalho Chehab wrote:
>> Em Tue, 28 Mar 2017 12:00:36 +0200
>> Hans Verkuil  escreveu:
>>
>>> On 27/03/17 20:09, Mauro Carvalho Chehab wrote:
 Em Mon, 27 Mar 2017 12:19:51 -0300
 Helen Koike  escreveu:
   
> Hi Sakari,
>
> On 2017-03-26 10:31 AM, Sakari Ailus wrote:  
>> Hi Helen,
>>
>> ...
>>> +static int vimc_cap_enum_input(struct file *file, void *priv,
>>> +  struct v4l2_input *i)
>>> +{
>>> +   /* We only have one input */
>>> +   if (i->index > 0)
>>> +   return -EINVAL;
>>> +
>>> +   i->type = V4L2_INPUT_TYPE_CAMERA;
>>> +   strlcpy(i->name, "VIMC capture", sizeof(i->name));
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +static int vimc_cap_g_input(struct file *file, void *priv, unsigned 
>>> int *i)
>>> +{
>>> +   /* We only have one input */
>>> +   *i = 0;
>>> +   return 0;
>>> +}
>>> +
>>> +static int vimc_cap_s_input(struct file *file, void *priv, unsigned 
>>> int i)
>>> +{
>>> +   /* We only have one input */
>>> +   return i ? -EINVAL : 0;
>>> +}
>>
>> You can drop the input IOCTLs altogether here. If you had e.g. a TV
>> tuner, it'd be the TV tuner driver's responsibility to implement them.
>>
>
> input IOCTLs seems to be mandatory from v4l2-compliance when capability 
> V4L2_CAP_VIDEO_CAPTURE is set (which is the case):
>
> https://git.linuxtv.org/v4l-utils.git/tree/utils/v4l2-compliance/v4l2-test-input-output.cpp#n418
>
> https://git.linuxtv.org/v4l-utils.git/tree/utils/v4l2-compliance/v4l2-compliance.cpp#n989
>   

 The V4L2 spec doesn't actually define what's mandatory and what's
 optional. The idea that was agreed on one of the media summits
 were to define a set of profiles for different device types,
 matching the features required by existing applications to work,
 but this was never materialized.

 So, my understanding is that any driver can implement
 any V4L2 ioctl.

 Yet, some applications require enum/get/set inputs, or otherwise
 they wouldn't work. It is too late to change this behavior. 
 So, either the driver or the core should implement those
 ioctls, in order to avoid breaking backward-compatibility.  
>>>
>>> The closest we have to determining which ioctls are mandatory or not is
>>> v4l2-compliance.
>>
>> Yes, but we should explicitly document what's mandatory at the V4L2
>> API spec and mention the v4l2-compliance tool there.
>>
>>> That said, v4l2-compliance is actually a bit more strict
>>> in some cases than the spec since some ioctls are optional in the spec, but
>>> required in v4l2-compliance for the simple reason that there is no reason
>>> for drivers NOT to implement those ioctls.
>>>
>>> However, the v4l2-compliance test was never written for MC devices. It turns
>>> out that it works reasonably well as long as a working pipeline is 
>>> configured
>>> first, but these input ioctls are a bit iffy.
>>
>> The way I see, v4l2-compliance V4L2 API check[1] should not be modified to
>> explicitly support devices with MC and/or subdev API.
> 
> The V4L2 API documentation states that
> 
>   Video inputs and outputs are physical connectors of a device. ...
>   Drivers must implement all the input ioctls when the device has one
>   or more inputs, all the output ioctls when the device has one or
>   more outputs.
> 
> "Inputs" and "outputs", as the spec defines them, mean physical connectors
> to the device.
> 
> Does e.g. a camera have a physical connector? I don't think one could
> imagine it does, meaning also there is no need to implement these IOCTLs.
> 
> That said, I looked at a few drivers and even the omap3isp driver implements
> the input IOCTLs. It provides no useful information whatsoever through them,
> just like most drivers whose hardware has no physical connectors.
> 
> Still the bottom line is that the spec does not require them.

The spec isn't gospel. The reality is that all non-MC drivers have these ioctls
and a sensor is considered to be an input.

Section 4.1.2 says: "The video input and video standard ioctls must be supported
by all video capture devices.". Which actually is also wrong since the video
standard ioctls do not make sense for DV inputs or sensors.

I'll make a patch correcting these issues.

Regards,

Hans

Re: [PATCH v7] [media] vimc: Virtual Media Controller core, capture and sensor

[Hans Verkuil]

On 28/03/17 16:23, Sakari Ailus wrote:
> Hi Hans,
> 
> On Tue, Mar 28, 2017 at 12:00:36PM +0200, Hans Verkuil wrote:
>> On 27/03/17 20:09, Mauro Carvalho Chehab wrote:
>>> Em Mon, 27 Mar 2017 12:19:51 -0300
>>> Helen Koike  escreveu:
>>>
 Hi Sakari,

 On 2017-03-26 10:31 AM, Sakari Ailus wrote:
> Hi Helen,
>
> ...  
>> +static int vimc_cap_enum_input(struct file *file, void *priv,
>> +   struct v4l2_input *i)
>> +{
>> +/* We only have one input */
>> +if (i->index > 0)
>> +return -EINVAL;
>> +
>> +i->type = V4L2_INPUT_TYPE_CAMERA;
>> +strlcpy(i->name, "VIMC capture", sizeof(i->name));
>> +
>> +return 0;
>> +}
>> +
>> +static int vimc_cap_g_input(struct file *file, void *priv, unsigned int 
>> *i)
>> +{
>> +/* We only have one input */
>> +*i = 0;
>> +return 0;
>> +}
>> +
>> +static int vimc_cap_s_input(struct file *file, void *priv, unsigned int 
>> i)
>> +{
>> +/* We only have one input */
>> +return i ? -EINVAL : 0;
>> +}  
>
> You can drop the input IOCTLs altogether here. If you had e.g. a TV
> tuner, it'd be the TV tuner driver's responsibility to implement them.
>  

 input IOCTLs seems to be mandatory from v4l2-compliance when capability 
 V4L2_CAP_VIDEO_CAPTURE is set (which is the case):

 https://git.linuxtv.org/v4l-utils.git/tree/utils/v4l2-compliance/v4l2-test-input-output.cpp#n418

 https://git.linuxtv.org/v4l-utils.git/tree/utils/v4l2-compliance/v4l2-compliance.cpp#n989
>>>
>>> The V4L2 spec doesn't actually define what's mandatory and what's
>>> optional. The idea that was agreed on one of the media summits
>>> were to define a set of profiles for different device types,
>>> matching the features required by existing applications to work,
>>> but this was never materialized.
>>>
>>> So, my understanding is that any driver can implement
>>> any V4L2 ioctl.
>>>
>>> Yet, some applications require enum/get/set inputs, or otherwise
>>> they wouldn't work. It is too late to change this behavior. 
>>> So, either the driver or the core should implement those
>>> ioctls, in order to avoid breaking backward-compatibility.
>>
>> The closest we have to determining which ioctls are mandatory or not is
>> v4l2-compliance. That said, v4l2-compliance is actually a bit more strict
>> in some cases than the spec since some ioctls are optional in the spec, but
>> required in v4l2-compliance for the simple reason that there is no reason
>> for drivers NOT to implement those ioctls.
>>
>> However, the v4l2-compliance test was never written for MC devices. It turns
>> out that it works reasonably well as long as a working pipeline is configured
>> first, but these input ioctls are a bit iffy.
>>
>> There are really two options: don't implement them, or implement it as a 
>> single
>> input. Multiple inputs make no sense for MC devices: the video node is the
>> endpoint of a video pipeline, you never switch 'inputs' there.
>>
>> The way the input ioctls are implemented here would fit nicely for an MC
>> device IMHO.
>>
>> So should we define these ioctls or not?
>>
>> I am inclined to define them for the following reasons:
>>
>> - Some applications expect them, so adding them to the driver costs little 
>> but
>>   allows these applications to work, provided the correct pipeline is 
>> configured
>>   first.
>>
>> - If a plugin is needed, then that plugin can always override these ioctls 
>> and
>>   for different 'inputs' reconfigure the pipeline.
>>
>> I really don't see implementing this as a problem. Reporting that an MC 
>> video node
>> has a "VIMC capture" input seems perfectly reasonable to me.
> 
> If we implement it in order to be make an application happy, I would have
> expected to hear complaints from someone using existing MC based drivers
> that do not implement the input IOCTLs.

It's for the same reason no one complained about the missing plugin: 'regular'
applications aren't used for these MC devices since they tend to be used on
embedded systems with custom software.

> It is also confusing from application point of view since this interface
> would not be the interface to configure the input of the pipeline as it
> might look like.
> 

The whole point is that, once a video pipeline is set up with media-ctl, the
driver will act just like a non-MC driver with a single input. Which is the
whole point. Applications that are MC aware won't use this, they would program
the media controller/subdevs directly.

It costs us next to nothing and it makes life easier for all. I really don't
see a downside to this.

Regards,

Hans

Re: [PATCH]: staging: media: css2400: fix checkpatch error

[Greg KH]

On Wed, Mar 29, 2017 at 08:36:27AM +0300, Haim Daniel wrote:

> >From 41d35b455f8eb139912909639e914469ef5e06fb Mon Sep 17 00:00:00 2001
> From: Haim Daniel 
> Date: Tue, 28 Mar 2017 19:27:57 +0300
> Subject: [PATCH] [media] staging: css2400: fix checkpatch error
> 
> isp_capture_defs.h:

What is this line for?

> 
> enclose macro with complex values in parentheses.
> 
> Signed-off-by: Haim Daniel 
> ---
>  .../pci/atomisp2/css2400/css_2401_csi2p_system/hrt/isp_capture_defs.h   | 2 
> +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Please don't attach your patch, use 'git send-email' to send it
properly.

thanks,

greg k-h

Re: [PATCH v3] Revert "staging: radio-bcm2048: fixed bare use of unsigned int"

[Greg Kroah-Hartman]

On Mon, Mar 27, 2017 at 05:20:29PM +1100, Eddie Youseph wrote:
> This reverts previous changes to checkpatch warning:
> WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
> ---
> Changes in v2:
>   - Added changelog
> 
> Changes in v3:
>   - Revert changes to using bare unsigned

I don't understand, this patch fails to apply.  What are you making it
aginst?

confused,

greg k-h

Re: [PATCH v2] [media] staging: css2400: fix checkpatch error

[Greg KH]

On Wed, Mar 29, 2017 at 10:12:28AM +0300, Haim Daniel wrote:
> isp_capture_defs.h:

What is this line for?

> fix checkpatch ERROR: 

Trailing whitespace?

> Macros with complex values should be enclosed in parentheses
> 
> Signed-off-by: Haim Daniel 
> ---
>  .../pci/atomisp2/css2400/css_2401_csi2p_system/hrt/isp_capture_defs.h   | 2 
> +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git 
> a/drivers/staging/media/atomisp/pci/atomisp2/css2400/css_2401_csi2p_system/hrt/isp_capture_defs.h
>  
> b/drivers/staging/media/atomisp/pci/atomisp2/css2400/css_2401_csi2p_system/hrt/isp_capture_defs.h
> index aa413df..78cbbf6 100644
> --- 
> a/drivers/staging/media/atomisp/pci/atomisp2/css2400/css_2401_csi2p_system/hrt/isp_capture_defs.h
> +++ 
> b/drivers/staging/media/atomisp/pci/atomisp2/css2400/css_2401_csi2p_system/hrt/isp_capture_defs.h
> @@ -19,7 +19,7 @@
>  #define _ISP_CAPTURE_BITS_PER_ELEM32  /* only for data, not 
> SOP */  
>  #define _ISP_CAPTURE_BYTES_PER_ELEM   
> (_ISP_CAPTURE_BITS_PER_ELEM/8  )  
>  #define _ISP_CAPTURE_BYTES_PER_WORD   32 /* 256/8 */ 
> -#define _ISP_CAPTURE_ELEM_PER_WORD
> _ISP_CAPTURE_BYTES_PER_WORD / _ISP_CAPTURE_BYTES_PER_ELEM 
> +#define _ISP_CAPTURE_ELEM_PER_WORD
> (_ISP_CAPTURE_BYTES_PER_WORD / _ISP_CAPTURE_BYTES_PER_ELEM) 

Does this change really make sense?  Why keep the trailing whitespace if
you touch the line?

thanks,

greg k-h

[PATCH v2] [media] staging: css2400: fix checkpatch error

[Haim Daniel]

isp_capture_defs.h:

fix checkpatch ERROR: 
Macros with complex values should be enclosed in parentheses

Signed-off-by: Haim Daniel 
---
 .../pci/atomisp2/css2400/css_2401_csi2p_system/hrt/isp_capture_defs.h   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/css_2401_csi2p_system/hrt/isp_capture_defs.h
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/css_2401_csi2p_system/hrt/isp_capture_defs.h
index aa413df..78cbbf6 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/css_2401_csi2p_system/hrt/isp_capture_defs.h
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/css_2401_csi2p_system/hrt/isp_capture_defs.h
@@ -19,7 +19,7 @@
 #define _ISP_CAPTURE_BITS_PER_ELEM32  /* only for data, not 
SOP */
 #define _ISP_CAPTURE_BYTES_PER_ELEM   
(_ISP_CAPTURE_BITS_PER_ELEM/8)  
 #define _ISP_CAPTURE_BYTES_PER_WORD   32   /* 256/8 */ 
-#define _ISP_CAPTURE_ELEM_PER_WORD_ISP_CAPTURE_BYTES_PER_WORD 
/ _ISP_CAPTURE_BYTES_PER_ELEM   
+#define _ISP_CAPTURE_ELEM_PER_WORD(_ISP_CAPTURE_BYTES_PER_WORD 
/ _ISP_CAPTURE_BYTES_PER_ELEM) 
 
 //#define CAPT_RCV_ACK  1
 //#define CAPT_WRT_ACK  2   
-- 
1.9.1

Re: [PATCH] Remove atomisp/i2c style errors.

[Greg KH]

On Tue, Mar 28, 2017 at 08:31:37PM -0700, Daniel Cashman wrote:
> From: Dan Cashman 

Please list what the issue you fixed in the subject line.

Also change the subject to match others for this driver, a 'git log'
will show you what to do there.

> 
> Remove two ' , ' issues and change spaces to tabs found by poking around in
> drivers/staging/. Warnings left untouched.
> 
> Test: Run checkpatch script in drivers/staging/media/atomisp/i2c before and
> after change.  Errors go from 3 to 0.

This isn't needed, and really, you didn't test the code, only a random
perl script :)

thanks,

greg k-h

Re: [PATCH] staging: media: atomisp: i2c: removed unnecessary white space before comma in memset()

[Greg KH]

On Tue, Mar 28, 2017 at 11:02:45AM +0530, vaibhavd...@gmail.com wrote:
> From: Vaibhav Kothari 
> 
> Removed extra space before comma in memset() as a part of
> checkpatch.pl fix-up.
> 
> Signed-off-by: Vaibhav Kothari 
> ---
>  drivers/staging/media/atomisp/i2c/gc2235.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

What changed from your prior emails with the same subject?  Always
version your patches, as SubmittingPatches describes how to do.

Please fix up and resend.

thanks,

greg k-h