Re: [PATCH 01/12] [media] vb2: add explicit fence user API

[Tomasz Figa]

Hi Gustavo,

On Tue, Jun 27, 2017 at 12:39 AM, Gustavo Padovan  wrote:
> 2017-06-18 kbuild test robot :
>
>> Hi Gustavo,
>>
>> [auto build test ERROR on linuxtv-media/master]
>> [also build test ERROR on v4.12-rc5 next-20170616]
>> [if your patch is applied to the wrong git tree, please drop us a note to 
>> help improve the system]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/Gustavo-Padovan/vb2-add-explicit-fence-user-API/20170618-210740
>> base:   git://linuxtv.org/media_tree.git master
>> config: x86_64-allmodconfig (attached as .config)
>> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
>> reproduce:
>> # save the attached .config to linux build tree
>> make ARCH=x86_64
>>
>> All error/warnings (new ones prefixed by >>):
>>
>>drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c: In function 
>> 'atomisp_qbuf':
>> >> drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c:1297:10: 
>> >> error: 'struct v4l2_buffer' has no member named 'reserved2'; did you mean 
>> >> 'reserved'?
>>  (buf->reserved2 & ATOMISP_BUFFER_HAS_PER_FRAME_SETTING)) {
>>  ^~
>>drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c:1299:50: 
>> error: 'struct v4l2_buffer' has no member named 'reserved2'; did you mean 
>> 'reserved'?
>>   pipe->frame_request_config_id[buf->index] = buf->reserved2 &
>>  ^~
>>drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c: In function 
>> 'atomisp_dqbuf':
>>drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c:1483:5: 
>> error: 'struct v4l2_buffer' has no member named 'reserved2'; did you mean 
>> 'reserved'?
>>  buf->reserved2 = pipe->frame_config_id[buf->index];
>> ^~
>>In file included from include/linux/printk.h:329:0,
>> from include/linux/kernel.h:13,
>> from include/linux/delay.h:21,
>> from 
>> drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c:24:
>>drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c:1488:6: 
>> error: 'struct v4l2_buffer' has no member named 'reserved2'; did you mean 
>> 'reserved'?
>>   buf->reserved2);
>>  ^
>
> Ouch! Seems the reserved2 was burned down by 2 drivers accessing it
> without any care for the uAPI. I'll change my patches to use the
> 'reserved' field instead.

Given that a reserved field has a clear meaning of being reserved and
the driver in question is in staging. I'd rather vote for fixing the
driver.

Best regards,
Tomasz

Re: [PATCH v2 01/10] [media] dvb-frontends: add ST STV0910 DVB-S/S2 demodulator frontend driver

[Daniel Scheller]

Am Tue, 4 Jul 2017 06:01:32 +0800
schrieb kbuild test robot :

> All errors (new ones prefixed by >>):
> 
>drivers/media/dvb-frontends/stv0910.c: In function
> 'read_signal_strength':
> >> drivers/media/dvb-frontends/stv0910.c:1284: error: 'p' undeclared
> >> (first use in this function)  
>drivers/media/dvb-frontends/stv0910.c:1284: error: (Each
> undeclared identifier is reported only once
> drivers/media/dvb-frontends/stv0910.c:1284: error: for each function
> it appears in.)

Fixed in v3 (by "Add required fe.dtv_propcache vars/references to the
dummy STR function, fixes bisect" in v3-1/10).

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

Re: [PATCH v2 09/19] media: camms: Add core files

[Sakari Ailus]

Hi Todor,

On Mon, Jul 03, 2017 at 05:03:40PM +0300, Todor Tomov wrote:
> >> +  unsigned int i;
> >> +
> >> +  v4l2_of_parse_endpoint(node, );
> >> +
> >> +  csd->interface.csiphy_id = vep.base.port;
> >> +
> >> +  mipi_csi2 = _csi2;
> >> +  lncfg->clk.pos = mipi_csi2->clock_lane;
> >> +  lncfg->clk.pol = mipi_csi2->lane_polarities[0];
> >> +  lncfg->num_data = mipi_csi2->num_data_lanes;
> >> +
> >> +  lncfg->data = devm_kzalloc(dev, lncfg->num_data * sizeof(*lncfg->data),
> >> + GFP_KERNEL);
> >> +  if (!lncfg->data)
> >> +  return -ENOMEM;
> >> +
> >> +  for (i = 0; i < lncfg->num_data; i++) {
> >> +  lncfg->data[i].pos = mipi_csi2->data_lanes[i];
> >> +  lncfg->data[i].pol = mipi_csi2->lane_polarities[i + 1];
> >> +  }
> >> +
> >> +  of_property_read_u32(node, "qcom,settle-cnt", settle_cnt);
> > 
> > Isn't this something that depends on the CSI-2 bus speed, for instance?
> > Could you calculate it instead of putting it to DT?
> 
> Actually, after some digging into this, yes, I can calculate it. I can
> calculate the CSI-2 bus speed based on the sensor's output pixel clock
> and then calculate the settle time and this settle count value.
> So I already have the code to get the sensor's pixel clock using the
> standard v4l2 control V4L2_CID_PIXEL_RATE.

What we have currently in documentation on this is here:



I.e. both should be implemented. The link frequency is rather more relevant
for CSI-2 albeit you can derive one from the other in case of CSI-2. The
pixel rate documentation should probably be rather elsewhere.

> Now the question is what to do if the sensor driver doesn't support this
> control? Just return an error and refuse to work with this "limited"
> sensor driver?

If the sensor driver does not provide enough information to work with a
receiver, it's only fair not to proceed with streaming. That said, it might
be possible to manage with some sensible defaults in some cases but then again
you could have only some units working with this configuration. It'd be
much safer to require the information: not doing so hides the error and
makes it (more) difficult to debug.

...

> >> +struct camss {
> >> +  struct v4l2_device v4l2_dev;
> >> +  struct v4l2_async_notifier notifier;
> >> +  struct media_device media_dev;
> >> +  struct device *dev;
> >> +  struct csiphy_device csiphy[CAMSS_CSIPHY_NUM];
> >> +  struct csid_device csid[CAMSS_CSID_NUM];
> >> +  struct ispif_device ispif;
> >> +  struct vfe_device vfe;
> >> +  atomic_t ref_count;

If this is refcount, then you should use refcount_t instead.

-- 
Regards,

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

Re: [PATCH] media: vb2 dma-sg: Constify dma_buf_ops structures.

[Marek Szyprowski]

Hi Arvind,

On 2017-07-01 14:18, Arvind Yadav wrote:

dma_buf_ops are not supposed to change at runtime. All functions
working with dma_buf_ops provided by  work with
const dma_buf_ops. So mark the non-const structs as const.

File size before:
text   data bss dec hex filename
5238112   4535414ea 
drivers/media/v4l2-core/videobuf2-dma-sg.o

File size After adding 'const':
text   data bss dec hex filename
5358  0   4536214f2 
drivers/media/v4l2-core/videobuf2-dma-sg.o

Signed-off-by: Arvind Yadav 


Acked-by: Marek Szyprowski 


---
  drivers/media/v4l2-core/videobuf2-dma-sg.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c 
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index 8e8798a..f8b4643 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -500,7 +500,7 @@ static int vb2_dma_sg_dmabuf_ops_mmap(struct dma_buf *dbuf,
return vb2_dma_sg_mmap(dbuf->priv, vma);
  }
  
-static struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {

+static const struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {
.attach = vb2_dma_sg_dmabuf_ops_attach,
.detach = vb2_dma_sg_dmabuf_ops_detach,
.map_dma_buf = vb2_dma_sg_dmabuf_ops_map,


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH] media: vb2 dma-contig: Constify dma_buf_ops structures.

[Marek Szyprowski]

Hi Arvind,

On 2017-07-01 13:27, Arvind Yadav wrote:

dma_buf_ops are not supposed to change at runtime. All functions
working with dma_buf_ops provided by  work with
const dma_buf_ops. So mark the non-const structs as const.

File size before:
text   data bss dec hex filename
6035272   0630718a3 
drivers/media/v4l2-core/videobuf2-dma-contig.o

File size After adding 'const':
text   data bss dec hex filename
6155160   0631518ab 
drivers/media/v4l2-core/videobuf2-dma-contig.o

Signed-off-by: Arvind Yadav 


Thanks!
Acked-by: Marek Szyprowski 


---
  drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 4f246d1..5b90a66 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -352,7 +352,7 @@ static int vb2_dc_dmabuf_ops_mmap(struct dma_buf *dbuf,
return vb2_dc_mmap(dbuf->priv, vma);
  }
  
-static struct dma_buf_ops vb2_dc_dmabuf_ops = {

+static const struct dma_buf_ops vb2_dc_dmabuf_ops = {
.attach = vb2_dc_dmabuf_ops_attach,
.detach = vb2_dc_dmabuf_ops_detach,
.map_dma_buf = vb2_dc_dmabuf_ops_map,


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH] media: vb2 vmalloc: Constify dma_buf_ops structures.

[Marek Szyprowski]

Hi Arvind,

On 2017-07-01 13:37, Arvind Yadav wrote:

dma_buf_ops are not supposed to change at runtime. All functions
working with dma_buf_ops provided by  work with
const dma_buf_ops. So mark the non-const structs as const.

File size before:
text   data bss dec hex filename
3171192   03363 d23 
drivers/media/v4l2-core/videobuf2-vmalloc.o

File size After adding 'const':
text   data bss dec hex filename
3291 80   03371 d2b 
drivers/media/v4l2-core/videobuf2-vmalloc.o

Signed-off-by: Arvind Yadav 


Acked-by: Marek Szyprowski 


---
  drivers/media/v4l2-core/videobuf2-vmalloc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c 
b/drivers/media/v4l2-core/videobuf2-vmalloc.c
index b337d78..6bc130f 100644
--- a/drivers/media/v4l2-core/videobuf2-vmalloc.c
+++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c
@@ -338,7 +338,7 @@ static int vb2_vmalloc_dmabuf_ops_mmap(struct dma_buf *dbuf,
return vb2_vmalloc_mmap(dbuf->priv, vma);
  }
  
-static struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {

+static const struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {
.attach = vb2_vmalloc_dmabuf_ops_attach,
.detach = vb2_vmalloc_dmabuf_ops_detach,
.map_dma_buf = vb2_vmalloc_dmabuf_ops_map,


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH v2 01/10] [media] dvb-frontends: add ST STV0910 DVB-S/S2 demodulator frontend driver

[kbuild test robot]

Hi Daniel,

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

url:
https://github.com/0day-ci/linux/commits/Daniel-Scheller/dvb-frontends-add-ST-STV0910-DVB-S-S2-demodulator-frontend-driver/20170703-211611
base:   git://linuxtv.org/media_tree.git master
config: x86_64-randconfig-v0-07040424 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the 
linux-review/Daniel-Scheller/dvb-frontends-add-ST-STV0910-DVB-S-S2-demodulator-frontend-driver/20170703-211611
 HEAD dafb8a36ff9cb533c394de71f2282325ad4a460d builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   drivers/media/dvb-frontends/stv0910.c: In function 'read_signal_strength':
>> drivers/media/dvb-frontends/stv0910.c:1284: error: 'p' undeclared (first use 
>> in this function)
   drivers/media/dvb-frontends/stv0910.c:1284: error: (Each undeclared 
identifier is reported only once
   drivers/media/dvb-frontends/stv0910.c:1284: error: for each function it 
appears in.)

vim +/p +1284 drivers/media/dvb-frontends/stv0910.c

  1278  }
  1279  
  1280  static void read_signal_strength(struct dvb_frontend *fe)
  1281  {
  1282  /* FIXME: add signal strength algo */
  1283  
> 1284  p->strength.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
  1285  }
  1286  
  1287  static int read_status(struct dvb_frontend *fe, enum fe_status *status)

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


.config.gz
Description: application/gzip

Re: [PATCH 00/12] V4L2 explicit synchronization support

[Gustavo Padovan]

Hi Mauro,

2017-06-30 Mauro Carvalho Chehab :

> Em Fri, 16 Jun 2017 16:39:03 +0900
> Gustavo Padovan  escreveu:
> 
> > From: Gustavo Padovan 
> > 
> > Hi,
> > 
> > This adds support for Explicit Synchronization of shared buffers in V4L2.
> > It uses the Sync File Framework[1] as vector to communicate the fences
> > between kernel and userspace.
> > 
> > Explicit Synchronization allows us to control the synchronization of
> > shared buffers from userspace by passing fences to the kernel and/or 
> > receiving them from the the kernel.
> > 
> > Fences passed to the kernel are named in-fences and the kernel should wait
> > them to signal before using the buffer. On the other side, the kernel 
> > creates
> > out-fences for every buffer it receives from userspace. This fence is sent 
> > back
> > to userspace and it will signal when the capture, for example, has finished.
> > 
> > Signalling an out-fence in V4L2 would mean that the job on the buffer is 
> > done
> > and the buffer can be used by other drivers.
> > 
> > The first patch proposes an userspace API for fences, then on patch 2
> > we prepare to the addition of in-fences in patch 3, by introducing the
> > infrastructure on vb2 to wait on an in-fence signal before queueing the 
> > buffer
> > in the driver.
> > 
> > Patch 4 fix uvc v4l2 event handling and patch 5 configure q->dev for vivid
> > drivers to enable to subscribe and dequeue events on it.
> > 
> > Patches 6-7 enables support to notify BUF_QUEUED events, i.e., let userspace
> > know that particular buffer was enqueued in the driver. This is needed,
> > because we return the out-fence fd as an out argument in QBUF, but at the 
> > time
> > it returns we don't know to which buffer the fence will be attached thus
> > the BUF_QUEUED event tells which buffer is associated to the fence received 
> > in
> > QBUF by userspace.
> > 
> > Patches 8-9 add support to mark queues as ordered. Finally patches 10 and 11
> > add more fence infrastructure to support out-fences and finally patch 12 
> > adds
> > support to out-fences.
> > 
> > Changelog are detailed in each patch.
> > 
> > Please review! Thanks.
> 
> Just reviewed the series. Most patches look good.
> 
> I have one additional concern: if the changes here won't cause any
> bad behaviors if fences is not available for some VB2 non V4L2 client.
> I'm actually thinking on this:
> 
>   https://patchwork.linuxtv.org/patch/31613/
> 
> From what I saw, after this patch series, someone could try to 
> inconditionally open an out fences fd for a driver. Maybe this
> should be denied by default, enabling such feature only if the
> VB2 "client" (e. g. videobuf-v4l2) supports it.

Yes, I think we can just reject the request if this non-VB2 client
tries to use the arg flags for fences.

Gustavo

Re: [PATCH 07/12] [media] v4l: add support to BUF_QUEUED event

[Gustavo Padovan]

Hi Mauro,

2017-06-30 Mauro Carvalho Chehab :

> Em Fri, 16 Jun 2017 16:39:10 +0900
> Gustavo Padovan  escreveu:
> 
> > From: Gustavo Padovan 
> > 
> > Implement the needed pieces to let userspace subscribe for
> > V4L2_EVENT_BUF_QUEUED events. Videobuf2 will queue the event for the
> > DQEVENT ioctl.
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/media/v4l2-core/v4l2-ctrls.c |  6 +-
> >  drivers/media/v4l2-core/videobuf2-core.c | 15 +++
> >  2 files changed, 20 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> > b/drivers/media/v4l2-core/v4l2-ctrls.c
> > index 5aed7bd..f55b5da 100644
> > --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> > @@ -3435,8 +3435,12 @@ EXPORT_SYMBOL(v4l2_ctrl_log_status);
> >  int v4l2_ctrl_subscribe_event(struct v4l2_fh *fh,
> > const struct v4l2_event_subscription *sub)
> >  {
> > -   if (sub->type == V4L2_EVENT_CTRL)
> > +   switch (sub->type) {
> > +   case V4L2_EVENT_CTRL:
> > return v4l2_event_subscribe(fh, sub, 0, _ctrl_sub_ev_ops);
> > +   case V4L2_EVENT_BUF_QUEUED:
> > +   return v4l2_event_subscribe(fh, sub, 0, NULL);
> > +   }
> > return -EINVAL;
> >  }
> >  EXPORT_SYMBOL(v4l2_ctrl_subscribe_event);
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> > b/drivers/media/v4l2-core/videobuf2-core.c
> > index 29aa9d4..00d9c35 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -25,6 +25,7 @@
> >  #include 
> >  
> >  #include 
> > +#include 
> >  #include 
> >  
> >  #include 
> > @@ -1221,6 +1222,18 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, 
> > const void *pb)
> > return ret;
> >  }
> >  
> > +static void vb2_buffer_queued_event(struct vb2_buffer *vb)
> > +{
> > +   struct video_device *vdev = to_video_device(vb->vb2_queue->dev);
> > +   struct v4l2_event event;
> > +
> > +   memset(, 0, sizeof(event));
> > +   event.type = V4L2_EVENT_BUF_QUEUED;
> > +   event.u.buf_queued.index = vb->index;
> > +
> > +   v4l2_event_queue(vdev, );
> > +}
> > +
> 
> It doesn't sound right to add a V4L2 event to VB2 core. The hole point
> of splitting the core from V4L2 specific stuff is to allow VB2 to be
> used by non-V4L2 APIs[1]. Please move this to videobuf2-v4l2.

Yes, that makes sense.  My lack of understanding of v4l2 core didn't me
allow realize that. I'll move it to videobuf2-v4l2.

Gustavo

Re: [PATCH 03/12] [media] vb2: add in-fence support to QBUF

[Gustavo Padovan]

Hi Mauro,

2017-06-30 Mauro Carvalho Chehab :

> Em Fri, 16 Jun 2017 16:39:06 +0900
> Gustavo Padovan  escreveu:
> 
> > From: Gustavo Padovan 
> > 
> > Receive in-fence from userspace and add support for waiting on them
> > before queueing the buffer to the driver. Buffers are only queued
> > to the driver once they are ready. A buffer is ready when its
> > in-fence signals.
> > 
> > v2:
> > - fix vb2_queue_or_prepare_buf() ret check
> > - remove check for VB2_MEMORY_DMABUF only (Javier)
> > - check num of ready buffers to start streaming
> > - when queueing, start from the first ready buffer
> > - handle queue cancel
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/media/Kconfig|  1 +
> >  drivers/media/v4l2-core/videobuf2-core.c | 97 
> > +---
> >  drivers/media/v4l2-core/videobuf2-v4l2.c | 15 -
> >  include/media/videobuf2-core.h   |  7 ++-
> >  4 files changed, 99 insertions(+), 21 deletions(-)
> > 
> > diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
> > index 55d9c2b..3cd1d3d 100644
> > --- a/drivers/media/Kconfig
> > +++ b/drivers/media/Kconfig
> > @@ -11,6 +11,7 @@ config CEC_NOTIFIER
> >  menuconfig MEDIA_SUPPORT
> > tristate "Multimedia support"
> > depends on HAS_IOMEM
> > +   select SYNC_FILE
> > help
> >   If you want to use Webcams, Video grabber devices and/or TV devices
> >   enable this option and other options below.
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> > b/drivers/media/v4l2-core/videobuf2-core.c
> > index ea83126..29aa9d4 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -1279,6 +1279,22 @@ static int __buf_prepare(struct vb2_buffer *vb, 
> > const void *pb)
> > return 0;
> >  }
> >  
> > +static int __get_num_ready_buffers(struct vb2_queue *q)
> > +{
> > +   struct vb2_buffer *vb;
> > +   int ready_count = 0;
> > +
> > +   /* count num of buffers ready in front of the queued_list */
> > +   list_for_each_entry(vb, >queued_list, queued_entry) {
> > +   if (vb->in_fence && !dma_fence_is_signaled(vb->in_fence))
> > +   break;
> > +
> > +   ready_count++;
> 
> Hmm... maybe that's one of the reasons why out of order explicit fences is not
> working. With the current logic, if explicit fences is enabled, this function
> will always return 0 or 1, even if more buffers are ready.
> 
> IMHO, the correct logic here should be, instead:
> 
>   if (!vb->in_fence || dma_fence_is_signaled(vb->in_fence))
>   ready_count++;

If we do like you propose then we will be getting the wrong ready_count
and queue buffers unordered (in the next two places this code snipet
appears.

In this function I want to know how many ready buffers are in the front
of the buffer. A buffer will be ready if:

* it has no fence
* it has a fence but it was signaled already

Then we start walking the queue looking for such buffers in order and
stop as soon as we find a buffer that doesn't meet these criteria. Hence
the 'break' command to interrupt the loop. If we don't break we may
queue the next buffer on the queue (if it matches the criteria) without
queueing the current one. So we really need break out from the loop
here.

> 
> > +   }
> > +
> > +   return ready_count;
> > +}
> > +
> >  int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb)
> >  {
> > struct vb2_buffer *vb;
> > @@ -1324,8 +1340,15 @@ static int vb2_start_streaming(struct vb2_queue *q)
> >  * If any buffers were queued before streamon,
> >  * we can now pass them to driver for processing.
> >  */
> > -   list_for_each_entry(vb, >queued_list, queued_entry)
> > +   list_for_each_entry(vb, >queued_list, queued_entry) {
> > +   if (vb->state != VB2_BUF_STATE_QUEUED)
> > +   continue;
> > +
> > +   if (vb->in_fence && !dma_fence_is_signaled(vb->in_fence))
> > +   break;
> > +
> > __enqueue_in_driver(vb);
> 
> Same as before, the correct logic here seems to be:
> 
>   if (!vb->in_fence || dma_fence_is_signaled(vb->in_fence))
>   __enqueue_in_driver(vb);
> 
> > +   }
> >  
> > /* Tell the driver to start streaming */
> > q->start_streaming_called = 1;
> > @@ -1369,33 +1392,55 @@ static int vb2_start_streaming(struct vb2_queue *q)
> >  
> >  static int __vb2_core_qbuf(struct vb2_buffer *vb, struct vb2_queue *q)
> >  {
> > +   struct vb2_buffer *b;
> > int ret;
> >  
> > /*
> >  * If already streaming, give the buffer to driver for processing.
> >  * If not, the buffer will be given to driver on next streamon.
> >  */
> > -   if (q->start_streaming_called)
> > -   __enqueue_in_driver(vb);
> >  
> > -   /*
> > -* 

[PATCH v3 03/10] [media] dvb-frontends/stv0910: add multistream (ISI) and PLS capabilities

[Daniel Scheller]

From: Daniel Scheller 

Implements stream_id filter and scrambling code setup in start() and also
sets FE_CAN_MULTISTREAM in frontend_ops. This enables the driver to
properly receive and handle multistream transponders, functionality has
been reported working fine by testers with access to such streams, in
conjunction with VDR on the userspace side.

The code snippet originates from the original vendor's dddvb driver
package and has been made working properly with the current in-kernel
DVB core API.

Signed-off-by: Daniel Scheller 
Tested-by: Richard Scobie 
---
 drivers/media/dvb-frontends/stv0910.c | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/stv0910.c 
b/drivers/media/dvb-frontends/stv0910.c
index 85439d3b725e..dc848ebe1a44 100644
--- a/drivers/media/dvb-frontends/stv0910.c
+++ b/drivers/media/dvb-frontends/stv0910.c
@@ -119,6 +119,8 @@ struct stv {
int   is_standard_broadcast;
int   is_vcm;
 
+   u32   cur_scrambling_code;
+
u32   last_bernumerator;
u32   last_berdenominator;
u8berscale;
@@ -965,6 +967,7 @@ static int start(struct stv *state, struct 
dtv_frontend_properties *p)
s32 freq;
u8  reg_dmdcfgmd;
u16 symb;
+   u32 scrambling_code = 1;
 
if (p->symbol_rate < 10 || p->symbol_rate > 7000)
return -EINVAL;
@@ -978,6 +981,28 @@ static int start(struct stv *state, struct 
dtv_frontend_properties *p)
 
init_search_param(state);
 
+   if (p->stream_id != NO_STREAM_ID_FILTER) {
+   /* Backwards compatibility to "crazy" API.
+* PRBS X root cannot be 0, so this should always work.
+*/
+   if (p->stream_id & 0xff00)
+   scrambling_code = p->stream_id >> 8;
+   write_reg(state, RSTV0910_P2_ISIENTRY + state->regoff,
+ p->stream_id & 0xff);
+   write_reg(state, RSTV0910_P2_ISIBITENA + state->regoff,
+ 0xff);
+   }
+
+   if (scrambling_code != state->cur_scrambling_code) {
+   write_reg(state, RSTV0910_P2_PLROOT0 + state->regoff,
+ scrambling_code & 0xff);
+   write_reg(state, RSTV0910_P2_PLROOT1 + state->regoff,
+ (scrambling_code >> 8) & 0xff);
+   write_reg(state, RSTV0910_P2_PLROOT2 + state->regoff,
+ (scrambling_code >> 16) & 0x07);
+   state->cur_scrambling_code = scrambling_code;
+   }
+
if (p->symbol_rate <= 100) {  /* SR <=1Msps */
state->demod_timeout = 3000;
state->fec_timeout = 2000;
@@ -1597,7 +1622,8 @@ static struct dvb_frontend_ops stv0910_ops = {
.caps   = FE_CAN_INVERSION_AUTO |
  FE_CAN_FEC_AUTO   |
  FE_CAN_QPSK   |
- FE_CAN_2G_MODULATION
+ FE_CAN_2G_MODULATION  |
+ FE_CAN_MULTISTREAM
},
.sleep  = sleep,
.release= release,
@@ -1655,6 +1681,7 @@ struct dvb_frontend *stv0910_attach(struct i2c_adapter 
*i2c,
state->search_range = 1600;
state->demod_bits = 0x10; /* Inversion : Auto with reset to 0 */
state->receive_mode   = RCVMODE_NONE;
+   state->cur_scrambling_code = (~0U);
state->single = cfg->single ? 1 : 0;
 
base = match_base(i2c, cfg->adr);
-- 
2.13.0

[PATCH v3 07/10] [media] ddbridge: return stv09xx id in port_has_stv0900_aa()

[Daniel Scheller]

From: Daniel Scheller 

The returned value is required for further evaluation of the exact
demodulator chip (stv090x or stv0910).

Signed-off-by: Daniel Scheller 
Tested-by: Richard Scobie 
---
 drivers/media/pci/ddbridge/ddbridge-core.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c 
b/drivers/media/pci/ddbridge/ddbridge-core.c
index cd1723e79a07..3fbac7bee2d4 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -1480,10 +1480,9 @@ static int port_has_stv0900(struct ddb_port *port)
return 1;
 }
 
-static int port_has_stv0900_aa(struct ddb_port *port)
+static int port_has_stv0900_aa(struct ddb_port *port, u8 *id)
 {
-   u8 val;
-   if (i2c_read_reg16(>i2c->adap, 0x68, 0xf100, ) < 0)
+   if (i2c_read_reg16(>i2c->adap, 0x68, 0xf100, id) < 0)
return 0;
return 1;
 }
@@ -1530,7 +1529,7 @@ static void ddb_port_probe(struct ddb_port *port)
 {
struct ddb *dev = port->dev;
char *modname = "NO MODULE";
-   u8 xo2_type, xo2_id, cxd_id;
+   u8 xo2_type, xo2_id, cxd_id, stv_id;
 
port->class = DDB_PORT_NONE;
 
@@ -1622,7 +1621,7 @@ static void ddb_port_probe(struct ddb_port *port)
port->class = DDB_PORT_TUNER;
port->type = DDB_TUNER_DVBS_ST;
ddbwritel(I2C_SPEED_100, port->i2c->regs + I2C_TIMING);
-   } else if (port_has_stv0900_aa(port)) {
+   } else if (port_has_stv0900_aa(port, _id)) {
modname = "DUAL DVB-S2";
port->class = DDB_PORT_TUNER;
port->type = DDB_TUNER_DVBS_ST_AA;
-- 
2.13.0

[PATCH v3 04/10] [media] dvb-frontends/stv0910: Add demod-only signal strength reporting

[Daniel Scheller]

From: Daniel Scheller 

Original code at least has some signed/unsigned issues, resulting in
values like 32dBm. Implement signal strength readout to work without
asking the attached tuner, and use a lookup table instead of log calc.
Values reported appear plausible, gathered from feedback from several
testers.

Signed-off-by: Daniel Scheller 
Tested-by: Richard Scobie 
---
 drivers/media/dvb-frontends/stv0910.c | 48 ---
 1 file changed, 44 insertions(+), 4 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv0910.c 
b/drivers/media/dvb-frontends/stv0910.c
index dc848ebe1a44..dc4d829bb47a 100644
--- a/drivers/media/dvb-frontends/stv0910.c
+++ b/drivers/media/dvb-frontends/stv0910.c
@@ -135,7 +135,7 @@ struct sinit_table {
 
 struct slookup {
s16  value;
-   u16  reg_value;
+   u32  reg_value;
 };
 
 static inline int i2c_write(struct i2c_adapter *adap, u8 adr,
@@ -327,6 +327,25 @@ struct slookup s2_sn_lookup[] = {
{  510,463  },  /*C/N=51.0dB*/
 };
 
+struct slookup padc_lookup[] = {
+   {0,  118000 }, /* PADC=+0dBm  */
+   { -100,  93600  }, /* PADC=-1dBm  */
+   { -200,  74500  }, /* PADC=-2dBm  */
+   { -300,  59100  }, /* PADC=-3dBm  */
+   { -400,  47000  }, /* PADC=-4dBm  */
+   { -500,  37300  }, /* PADC=-5dBm  */
+   { -600,  29650  }, /* PADC=-6dBm  */
+   { -700,  23520  }, /* PADC=-7dBm  */
+   { -900,  14850  }, /* PADC=-9dBm  */
+   { -1100, 9380   }, /* PADC=-11dBm */
+   { -1300, 5910   }, /* PADC=-13dBm */
+   { -1500, 3730   }, /* PADC=-15dBm */
+   { -1700, 2354   }, /* PADC=-17dBm */
+   { -1900, 1485   }, /* PADC=-19dBm */
+   { -2000, 1179   }, /* PADC=-20dBm */
+   { -2100, 1000   }, /* PADC=-21dBm */
+};
+
 /*
  * Tracking carrier loop carrier QPSK 1/4 to 8PSK 9/10 long Frame
  */
@@ -567,7 +586,7 @@ static int tracking_optimization(struct stv *state)
 }
 
 static s32 table_lookup(struct slookup *table,
-  int table_size, u16 reg_value)
+  int table_size, u32 reg_value)
 {
s32 value;
int imin = 0;
@@ -1300,11 +1319,32 @@ static int read_ber(struct dvb_frontend *fe)
 
 static void read_signal_strength(struct dvb_frontend *fe)
 {
-   /* FIXME: add signal strength algo */
struct stv *state = fe->demodulator_priv;
struct dtv_frontend_properties *p = >fe.dtv_property_cache;
+   s64 strength;
+   u8 reg[2];
+   u16 agc;
+   s32 padc, power = 0;
+   int i;
 
-   p->strength.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+   read_regs(state, RSTV0910_P2_AGCIQIN1 + state->regoff, reg, 2);
+
+   agc = (((u32) reg[0]) << 8) | reg[1];
+
+   for (i = 0; i < 5; i += 1) {
+   read_regs(state, RSTV0910_P2_POWERI + state->regoff, reg, 2);
+   power += (u32) reg[0] * (u32) reg[0]
+   + (u32) reg[1] * (u32) reg[1];
+   usleep_range(3000, 4000);
+   }
+   power /= 5;
+
+   padc = table_lookup(padc_lookup, ARRAY_SIZE(padc_lookup), power) + 352;
+
+   strength = (padc - agc);
+
+   p->strength.stat[0].scale = FE_SCALE_DECIBEL;
+   p->strength.stat[0].uvalue = strength;
 }
 
 static int read_status(struct dvb_frontend *fe, enum fe_status *status)
-- 
2.13.0

[PATCH v3 08/10] [media] ddbridge: support for CineS2 V7(A) and DuoFlex S2 V4 hardware

[Daniel Scheller]

From: Daniel Scheller 

This adds all required glue code to support - in conjunction with the new
stv0910 and stv6111 demod/tuner drivers and additionally the lnbh25 LNB
controller driver - all current DVB-S/S2 hardware (bridges and flex
modules) from Digital Devices like the DD CineS2 V7 and V7A, current
S2 V4 DuoFlex modules, and probably all upcoming devices based on this
STV0910/STV6111/LNBH25 hardware stack.

Signed-off-by: Daniel Scheller 
Tested-by: Richard Scobie 
---
 drivers/media/pci/ddbridge/Kconfig |   4 +
 drivers/media/pci/ddbridge/ddbridge-core.c | 135 -
 drivers/media/pci/ddbridge/ddbridge.h  |   2 +
 3 files changed, 138 insertions(+), 3 deletions(-)

diff --git a/drivers/media/pci/ddbridge/Kconfig 
b/drivers/media/pci/ddbridge/Kconfig
index ffed78c2ffb4..c79a58fa5fc3 100644
--- a/drivers/media/pci/ddbridge/Kconfig
+++ b/drivers/media/pci/ddbridge/Kconfig
@@ -8,6 +8,9 @@ config DVB_DDBRIDGE
select DVB_TDA18271C2DD if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV0367 if MEDIA_SUBDRV_AUTOSELECT
select DVB_CXD2841ER if MEDIA_SUBDRV_AUTOSELECT
+   select DVB_STV0910 if MEDIA_SUBDRV_AUTOSELECT
+   select DVB_STV6111 if MEDIA_SUBDRV_AUTOSELECT
+   select DVB_LNBH25 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_TDA18212 if MEDIA_SUBDRV_AUTOSELECT
---help---
  Support for cards with the Digital Devices PCI express bridge:
@@ -20,5 +23,6 @@ config DVB_DDBRIDGE
  - CineCTv6 and DuoFlex CT (STV0367-based)
  - CineCTv7 and DuoFlex CT2/C2T2/C2T2I (Sony CXD28xx-based)
  - MaxA8 series
+ - CineS2 V7/V7A and DuoFlex S2 V4 (ST STV0910-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 3fbac7bee2d4..b3fc6a875279 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -45,6 +45,9 @@
 #include "stv0367_priv.h"
 #include "cxd2841er.h"
 #include "tda18212.h"
+#include "stv0910.h"
+#include "stv6111.h"
+#include "lnbh25.h"
 
 static int xo2_speed = 2;
 module_param(xo2_speed, int, 0444);
@@ -920,6 +923,71 @@ static int tuner_attach_stv6110(struct ddb_input *input, 
int type)
return 0;
 }
 
+static struct stv0910_cfg stv0910_p = {
+   .adr  = 0x68,
+   .parallel = 1,
+   .rptlvl   = 4,
+   .clk  = 3000,
+};
+
+static struct lnbh25_config lnbh25_cfg = {
+   .i2c_address = 0x0c << 1,
+   .data2_config = LNBH25_TEN
+};
+
+static int demod_attach_stv0910(struct ddb_input *input, int type)
+{
+   struct i2c_adapter *i2c = >port->i2c->adap;
+   struct device *dev = >port->dev->pdev->dev;
+   struct stv0910_cfg cfg = stv0910_p;
+   struct lnbh25_config lnbcfg = lnbh25_cfg;
+
+   if (type)
+   cfg.parallel = 2;
+   input->fe = dvb_attach(stv0910_attach, i2c, , (input->nr & 1));
+   if (!input->fe) {
+   cfg.adr = 0x6c;
+   input->fe = dvb_attach(stv0910_attach, i2c,
+   , (input->nr & 1));
+   }
+   if (!input->fe) {
+   dev_err(dev, "No STV0910 found!\n");
+   return -ENODEV;
+   }
+
+   /* attach lnbh25 - leftshift by one as the lnbh25 driver expects 8bit
+* i2c addresses
+*/
+   lnbcfg.i2c_address = (((input->nr & 1) ? 0x0d : 0x0c) << 1);
+   if (!dvb_attach(lnbh25_attach, input->fe, , i2c)) {
+   lnbcfg.i2c_address = (((input->nr & 1) ? 0x09 : 0x08) << 1);
+   if (!dvb_attach(lnbh25_attach, input->fe, , i2c)) {
+   dev_err(dev, "No LNBH25 found!\n");
+   return -ENODEV;
+   }
+   }
+
+   return 0;
+}
+
+static int tuner_attach_stv6111(struct ddb_input *input, int type)
+{
+   struct i2c_adapter *i2c = >port->i2c->adap;
+   struct device *dev = >port->dev->pdev->dev;
+   struct dvb_frontend *fe;
+   u8 adr = (type ? 0 : 4) + ((input->nr & 1) ? 0x63 : 0x60);
+
+   fe = dvb_attach(stv6111_attach, input->fe, i2c, adr);
+   if (!fe) {
+   fe = dvb_attach(stv6111_attach, input->fe, i2c, adr & ~4);
+   if (!fe) {
+   dev_err(dev, "No STV6111 found at 0x%02x!\n", adr);
+   return -ENODEV;
+   }
+   }
+   return 0;
+}
+
 static int my_dvb_dmx_ts_card_init(struct dvb_demux *dvbdemux, char *id,
int (*start_feed)(struct dvb_demux_feed *),
int (*stop_feed)(struct dvb_demux_feed *),
@@ -1086,6 +1154,36 @@ static int dvb_input_attach(struct ddb_input *input)
return -ENODEV;
}
break;
+   case DDB_TUNER_XO2_DVBS_STV0910:
+   if 

[PATCH v3 06/10] [media] dvb-frontends: add ST STV6111 DVB-S/S2 tuner frontend driver

[Daniel Scheller]

From: Daniel Scheller 

This adds a frontend driver for the ST STV6111 DVB-S/S2 tuners. Like the
stv0910 demod frontend driver, this driver originates from the Digital
Devices' dddvb vendor driver package as of version 0.9.29, and was cleaned
up aswell. No functionality had to be removed though. Any camel case has
been converted to kernel_case, fixup patch has been proposed upstream.

Permission to reuse and mainline the driver code was formally granted by
Ralph Metzler .

Signed-off-by: Daniel Scheller 
Tested-by: Richard Scobie 
---
 drivers/media/dvb-frontends/Kconfig   |   9 +
 drivers/media/dvb-frontends/Makefile  |   1 +
 drivers/media/dvb-frontends/stv6111.c | 674 ++
 drivers/media/dvb-frontends/stv6111.h |  20 +
 4 files changed, 704 insertions(+)
 create mode 100644 drivers/media/dvb-frontends/stv6111.c
 create mode 100644 drivers/media/dvb-frontends/stv6111.h

diff --git a/drivers/media/dvb-frontends/Kconfig 
b/drivers/media/dvb-frontends/Kconfig
index 773de5e264e3..d2d3160abdf7 100644
--- a/drivers/media/dvb-frontends/Kconfig
+++ b/drivers/media/dvb-frontends/Kconfig
@@ -44,6 +44,15 @@ config DVB_STV6110x
help
  A Silicon tuner that supports DVB-S and DVB-S2 modes
 
+config DVB_STV6111
+   tristate "STV6111 based tuners"
+   depends on DVB_CORE && I2C
+   default m if !MEDIA_SUBDRV_AUTOSELECT
+   help
+ A Silicon tuner that supports DVB-S and DVB-S2 modes
+
+ Say Y when you want to support these frontends.
+
 config DVB_M88DS3103
tristate "Montage Technology M88DS3103"
depends on DVB_CORE && I2C && I2C_MUX
diff --git a/drivers/media/dvb-frontends/Makefile 
b/drivers/media/dvb-frontends/Makefile
index c302b2d07499..e8bf1d873485 100644
--- a/drivers/media/dvb-frontends/Makefile
+++ b/drivers/media/dvb-frontends/Makefile
@@ -111,6 +111,7 @@ obj-$(CONFIG_DVB_CXD2841ER) += cxd2841er.o
 obj-$(CONFIG_DVB_DRXK) += drxk.o
 obj-$(CONFIG_DVB_TDA18271C2DD) += tda18271c2dd.o
 obj-$(CONFIG_DVB_STV0910) += stv0910.o
+obj-$(CONFIG_DVB_STV6111) += stv6111.o
 obj-$(CONFIG_DVB_SI2165) += si2165.o
 obj-$(CONFIG_DVB_A8293) += a8293.o
 obj-$(CONFIG_DVB_SP2) += sp2.o
diff --git a/drivers/media/dvb-frontends/stv6111.c 
b/drivers/media/dvb-frontends/stv6111.c
new file mode 100644
index ..ce5b5ff936d5
--- /dev/null
+++ b/drivers/media/dvb-frontends/stv6111.c
@@ -0,0 +1,674 @@
+/*
+ * Driver for the ST STV6111 tuner
+ *
+ * Copyright (C) 2014 Digital Devices GmbH
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 only, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "stv6111.h"
+
+#include "dvb_frontend.h"
+
+struct stv {
+   struct i2c_adapter *i2c;
+   u8 adr;
+
+   u8 reg[11];
+   u32 ref_freq;
+   u32 frequency;
+};
+
+struct slookup {
+   s16 value;
+   u16 reg_value;
+};
+
+static struct slookup lnagain_nf_lookup[] = {
+   /*Gain *100dB*/  /*Reg*/
+   { 2572, 0 },
+   { 2575, 1 },
+   { 2580, 2 },
+   { 2588, 3 },
+   { 2596, 4 },
+   { 2611, 5 },
+   { 2633, 6 },
+   { 2664, 7 },
+   { 2701, 8 },
+   { 2753, 9 },
+   { 2816, 10 },
+   { 2902, 11 },
+   { 2995, 12 },
+   { 3104, 13 },
+   { 3215, 14 },
+   { 3337, 15 },
+   { 3492, 16 },
+   { 3614, 17 },
+   { 3731, 18 },
+   { 3861, 19 },
+   { 3988, 20 },
+   { 4124, 21 },
+   { 4253, 22 },
+   { 4386, 23 },
+   { 4505, 24 },
+   { 4623, 25 },
+   { 4726, 26 },
+   { 4821, 27 },
+   { 4903, 28 },
+   { 4979, 29 },
+   { 5045, 30 },
+   { 5102, 31 }
+};
+
+static struct slookup lnagain_iip3_lookup[] = {
+   /*Gain *100dB*/   /*reg*/
+   { 1548, 0 },
+   { 1552, 1 },
+   { 1569, 2 },
+   { 1565, 3 },
+   { 1577, 4 },
+   { 1594, 5 },
+   { 1627, 6 },
+   { 1656, 7 },
+   { 1700, 8 },
+   { 1748, 9 },
+   { 1805, 10 },
+   { 1896, 11 },
+   { 1995, 12 },
+   { 2113, 13 },
+   { 2233, 14 },
+   { 2366, 15 },
+   { 2543, 16 },
+   { 2687, 17 },
+   { 2842, 18 },
+   { 2999, 19 },
+   { 3167, 20 },
+   { 3342, 21 },
+   { 3507, 22 },
+   { 3679, 23 },
+   { 3827, 24 },
+   { 3970, 25 },
+   { 4094, 26 },
+   { 4210, 27 },
+   { 4308, 28 },
+   { 4396, 29 },
+   { 4468, 30 },
+   { 4535, 31 }
+};
+
+static struct slookup 

[PATCH v3 09/10] [media] ddbridge: stv0910 single demod mode module option

[Daniel Scheller]

From: Daniel Scheller 

Adds a stv0910_single modparm which, when set, configures the stv0910 to
run in single demodulator mode, currently intended for high bit rate
testing.

Signed-off-by: Daniel Scheller 
Tested-by: Richard Scobie 
---
 drivers/media/pci/ddbridge/ddbridge-core.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c 
b/drivers/media/pci/ddbridge/ddbridge-core.c
index b3fc6a875279..e762396730db 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -53,6 +53,10 @@ static int xo2_speed = 2;
 module_param(xo2_speed, int, 0444);
 MODULE_PARM_DESC(xo2_speed, "default transfer speed for xo2 based duoflex, 
0=55,1=75,2=90,3=104 MBit/s, default=2, use attribute to change for individual 
cards");
 
+static int stv0910_single;
+module_param(stv0910_single, int, 0444);
+MODULE_PARM_DESC(stv0910_single, "use stv0910 cards as single demods");
+
 DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 
 /* MSI had problems with lost interrupts, fixed but needs testing */
@@ -942,6 +946,9 @@ static int demod_attach_stv0910(struct ddb_input *input, 
int type)
struct stv0910_cfg cfg = stv0910_p;
struct lnbh25_config lnbcfg = lnbh25_cfg;
 
+   if (stv0910_single)
+   cfg.single = 1;
+
if (type)
cfg.parallel = 2;
input->fe = dvb_attach(stv0910_attach, i2c, , (input->nr & 1));
-- 
2.13.0

[PATCH v3 05/10] [media] dvb-frontends/stv0910: Add missing set_frontend fe-op

[Daniel Scheller]

From: Daniel Scheller 

This was missing from the frontend_ops.

Signed-off-by: Daniel Scheller 
Tested-by: Richard Scobie 
---
 drivers/media/dvb-frontends/stv0910.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/dvb-frontends/stv0910.c 
b/drivers/media/dvb-frontends/stv0910.c
index dc4d829bb47a..7e8a460449c5 100644
--- a/drivers/media/dvb-frontends/stv0910.c
+++ b/drivers/media/dvb-frontends/stv0910.c
@@ -1668,6 +1668,7 @@ static struct dvb_frontend_ops stv0910_ops = {
.sleep  = sleep,
.release= release,
.i2c_gate_ctrl  = gate_ctrl,
+   .set_frontend   = set_parameters,
.get_frontend_algo  = get_algo,
.get_frontend   = get_frontend,
.tune   = tune,
-- 
2.13.0

[PATCH v3 10/10] [media] MAINTAINERS: add entries for stv0910 and stv6111

[Daniel Scheller]

From: Daniel Scheller 

Signed-off-by: Daniel Scheller 
---
 MAINTAINERS | 16 
 1 file changed, 16 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c4be6d4af7d2..7b85e578d238 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8246,6 +8246,22 @@ T:   git git://linuxtv.org/media_tree.git
 S: Supported
 F: drivers/media/pci/netup_unidvb/*
 
+MEDIA DRIVERS FOR ST STV0910 DEMODULATOR ICs
+M: Daniel Scheller 
+L: linux-media@vger.kernel.org
+W: https://linuxtv.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/dvb-frontends/stv0910*
+
+MEDIA DRIVERS FOR ST STV6111 TUNER ICs
+M: Daniel Scheller 
+L: linux-media@vger.kernel.org
+W: https://linuxtv.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/dvb-frontends/stv6111*
+
 MEDIA INPUT INFRASTRUCTURE (V4L/DVB)
 M: Mauro Carvalho Chehab 
 M: Mauro Carvalho Chehab 
-- 
2.13.0

[PATCH v3 02/10] [media] dvb-frontends/stv0910: Fix possible buffer overflow

[Daniel Scheller]

From: Daniel Scheller 

Fixes smatch error:

  drivers/media/dvb-frontends/stv0910.c:715 dvbs2_nbch() error: buffer overflow 
'nbch[fectype]' 2 <= 28

Also, fixes the nbch array table by adding the DUMMY_PLF element at the top
to match the enums (table element order was off by one before).

Patch sent upstream aswell.

Cc: Ralph Metzler 
Signed-off-by: Daniel Scheller 
Tested-by: Richard Scobie 
---
 drivers/media/dvb-frontends/stv0910.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/stv0910.c 
b/drivers/media/dvb-frontends/stv0910.c
index 9dfcaf5e067f..85439d3b725e 100644
--- a/drivers/media/dvb-frontends/stv0910.c
+++ b/drivers/media/dvb-frontends/stv0910.c
@@ -671,6 +671,7 @@ static int get_bit_error_rate_s(struct stv *state, u32 
*bernumerator,
 static u32 dvbs2_nbch(enum dvbs2_mod_cod mod_cod, enum dvbs2_fectype fectype)
 {
static u32 nbch[][2] = {
+   {0, 0}, /* DUMMY_PLF */
{16200,  3240}, /* QPSK_1_4, */
{21600,  5400}, /* QPSK_1_3, */
{25920,  6480}, /* QPSK_2_5, */
@@ -703,7 +704,7 @@ static u32 dvbs2_nbch(enum dvbs2_mod_cod mod_cod, enum 
dvbs2_fectype fectype)
 
if (mod_cod >= DVBS2_QPSK_1_4 &&
mod_cod <= DVBS2_32APSK_9_10 && fectype <= DVBS2_16K)
-   return nbch[fectype][mod_cod];
+   return nbch[mod_cod][fectype];
return 64800;
 }
 
-- 
2.13.0

[PATCH v3 00/10] STV0910/STV6111 drivers, ddbridge CineS2 V7 support

[Daniel Scheller]

From: Daniel Scheller 

For Linux 4.14.

This v3 is a fixup for the previously posted v2. Smatch and W=1 uncovered
three additional issues in the stv6111 driver, see the v3 notes below.
While at it, few things have been fixed in patch 1 (initial stv0910
driver). Sorry for the noise and the mail spam, will try harder to
properly test things before posting next time... At least, we're clean of
warnings (smatch and W=1) and bisect issues now.

Superseeds initial (v1) and v2 series.

This series adds drivers for the ST STV0910 DVB-S/S2 demodulator ICs and
the ST STV6111 DVB-S/S2 tuners, and utilises them to enable ddbridge to
support the current line of Digital Devices DVB-S/S2 hardware (e.g. Cine
S2 V7/V7A adapters, DuoFlex S2 V4 addon modules and maybe more, with
similar components).

The two new drivers have been picked up from Digital Devices' vendor-
provided dddvb driver package, as of release 0.9.29. Permission to reuse
(and mainline) them was formally granted by Ralph Metzler
.

Drivers have been cleaned up alot (formatting fixes, dead code removal,
features depending on not-yet-available API changes removed). Checkpatch
complaints left:

  WARNING: please write a paragraph that describes the config symbol fully
  #39: FILE: drivers/media/dvb-frontends/Kconfig:31:
  +config DVB_STV0910

Not sure what checkpatch demands, since a module description exists in
Kconfig... Applies to the stv6111 aswell.

  WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
  #64:
  new file mode 100644

See below.

  WARNING: 'VALIDE' may be misspelled - perhaps 'VALID'?
  #3314: FILE: drivers/media/dvb-frontends/stv0910_regs.h:1467:
  +#define FSTV0910_P2_NOSRAM_VALIDE  0xf30e0004

Picked from upstream. Since I'm not sure if this really is a mistake
(maybe the hardware vendor really wants to name the reg like this?) so
kept as-is.

CamelCase and ALLCAPS are changed into kernel_kase. Patches have been
proposed to the vendor driver package maintainers to keep things synced
as much as possible.

Patch 2 is a fix for an issue found while preparing this series for
posting, and was in parallel submitted to the vendor's GIT repository.

Adding myself to MAINTAINERS for stv0910 and stv6111 as I'll keep track
of any upstream (vendor provided package) changes and propose them
for mainline inclusion.

Tested-by's from Richard Scobie  added to the
commit descriptions.

Mauro, I assume you're the one who reviews this (since these are new
drivers). It'd be very great to have this in for 4.14 to tackle the
ddbridge bump for 4.15. Of course awaiting review yet. I believe this
v3 is at least cleaned up as much as possible, thus an even better
merge candidate than v2 :-)

Changes from v2 to v3:
 - Fixed three warnings in the stv6111 driver, uncovered by W=1 and
   another smatch run:
   * in wait_for_call_done(), int status was redeclared to u8 status
 (due to the camelcase fixup), triggering a -Wtype-limits warning.
 Additional fix proposed to the vendor package maintainers aswell.
   * removed variable "symb" from set_params() (fixes -Wunused-but-set-
 variable)
   * added '#include "stv6111.h"', fixes -Wmissing-prototype for
 *stv6111_attach()
 - Removed unused scrambling_code vars from patch 1
 - Changed "return -1" to "return -EINVAL" in manage_matype_info()
 - Add required fe.dtv_propcache vars/references to the dummy STR
   function, fixes bisect

Changes from v1 to v2:
 - CamelCase and ALLCAPS changed to kernel_case
 - Signal statistics acquisition refactored to comply with standards
 - printk* and pr_* changed to dev_*
 - Add myself to MAINTAINERS for stv0910 and stv6111

Daniel Scheller (10):
  [media] dvb-frontends: add ST STV0910 DVB-S/S2 demodulator frontend
driver
  [media] dvb-frontends/stv0910: Fix possible buffer overflow
  [media] dvb-frontends/stv0910: add multistream (ISI) and PLS
capabilities
  [media] dvb-frontends/stv0910: Add demod-only signal strength
reporting
  [media] dvb-frontends/stv0910: Add missing set_frontend fe-op
  [media] dvb-frontends: add ST STV6111 DVB-S/S2 tuner frontend driver
  [media] ddbridge: return stv09xx id in port_has_stv0900_aa()
  [media] ddbridge: support for CineS2 V7(A) and DuoFlex S2 V4 hardware
  [media] ddbridge: stv0910 single demod mode module option
  [media] MAINTAINERS: add entries for stv0910 and stv6111

 MAINTAINERS|   16 +
 drivers/media/dvb-frontends/Kconfig|   18 +
 drivers/media/dvb-frontends/Makefile   |2 +
 drivers/media/dvb-frontends/stv0910.c  | 1771 +++
 drivers/media/dvb-frontends/stv0910.h  |   32 +
 drivers/media/dvb-frontends/stv0910_regs.h | 4759 
 drivers/media/dvb-frontends/stv6111.c  |  674 
 drivers/media/dvb-frontends/stv6111.h  |   20 +
 drivers/media/pci/ddbridge/Kconfig |4 +
 drivers/media/pci/ddbridge/ddbridge-core.c |  151 +-

Re: [PATCH v6 2/3] media: i2c: adv748x: add adv748x driver

[Hans Verkuil]

On 07/03/2017 05:00 PM, Kieran Bingham wrote:

Hi Hans,

On 03/07/17 15:45, Kieran Bingham wrote:

Hi Hans,

Thanks for your review,

On 03/07/17 14:51, Hans Verkuil wrote:

On 06/27/2017 05:03 PM, Kieran Bingham wrote:

From: Kieran Bingham 

Provide support for the ADV7481 and ADV7482.


...


+/* 
-
+ * HDMI and CP
+ */
+
+#define ADV748X_HDMI_MIN_WIDTH640
+#define ADV748X_HDMI_MAX_WIDTH1920
+#define ADV748X_HDMI_MIN_HEIGHT480
+#define ADV748X_HDMI_MAX_HEIGHT1200
+#define ADV748X_HDMI_MIN_PIXELCLOCK0/* unknown */


0 makes no sense. Something like 1300 would work better (pixelclock rate for
V4L2_DV_BT_CEA_720X480I59_94 is 1350).


This is another one that must have got lost somehow - you'd already told me this
and I'm really sure I changed it to the value you suggested ...

/me is confused at code loss - Must have been a rebase gone bad. :-(



+#define ADV748X_HDMI_MAX_PIXELCLOCK16200


You probably based that on the 1600x1200p60 format?


No idea I'm afraid - it's the value that was set when I recieved the driver...



162MHz is a bit low for an adv receiver. The adv7604 and adv8742 have a max rate
of 225 MHz.
This should be documented in the datasheet.


Hrm ... haven't found it yet - I'll keep digging



I've found this as the most relevant reference:


The ADV7481 HDMI capable receiver supports a maximum pixel clock frequency of
162 MHz, allowing HDTV formats up to 1080p, and display resolutions up to UXGA
(1600 × 1200 at 60 Hz). The device integrates a consumer electronics control
(CEC) controller that supports the capability discovery and control (CDC)
feature. The HDMI input port has dedicated 5 V detect and Hot PlugTM assert 
pins.


So that certainly looks like 162 MHz is the correct value.


Besides, you need a bit of margin since detected pixelclock rates can be a bit 
off.


Does that mean you would you recommend adding 0.5 MHz to the 162 MHz in a
similar way as the minimum, or keep at 162 MHz ?

(I'm assuming stay at 162 MHz, as the 7604 is set at 225MHz)


If the datasheet states that 162 MHz is max, then it should stay that way.

It's a bit peculiar: the HDMI spec allows for some variation (0.5%?) in 
pixelclock
rates. So a source may actually use a pixelclock rate up to 1.005 * 162 MHz. So 
I have
my doubts about whether 162 MHz is really the hard limit. It's hard to test, 
though.

And from the point of view of the API I don't think it matters.

Regards,

Hans

Re: [PATCH] Hauppauge HVR-1975 support

[Steven Toth]

> Yes - it's a 1:1 forward port of the patch Hauppauge released for 3.19
> (apparently with the goal to support as many of their devices as
> possible).

Agreed.

>
>> the patch also contains materials that I
>> suspect Silicon Labs would consider proprietary and confidential, its
>> definitely derived works from proprietary SILABS drivers.
>
> Does anyone know for sure what the legal situation is when a HW
> manufacturer releases a patch (as Hauppauge did) that is clearly
> derived from GPL code yet at the same time derived from non-free code?
> My interpretation is that by putting it out, they've released a GPL
> derived work, which they can legally do only if they agree to comply
> with the GPL, therefore any other license notice would be void.
> But as I pointed out before I'm not a lawyer...

You've raised a valid question, I don't know the answer. Others might.

I'm not a lawyer either, but if Hauppauge are not careful then they
may be violating an NDA, especially as the patch doesn't appear to
come with a sign-off, and leans very heavily on intellectual property
of Silicon Labs. I think in its current format the patch probably
wouldn't be acceptable for merge unless Hauppauge themselves provide a
sign-off.

Side note: obviously the fact it's such a large patch would require it
to be split into patches to each sub-system/card, but that's largely
beside the point of my larger concern.

Perhaps Hauppauge have legal approval to derive GPL drivers from
proprietary ,aterials, in which case I'm just making noise and a
sign-off will be soon to follow.

I'll reach out to them and ask.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

Re: [PATCH v6 2/3] media: i2c: adv748x: add adv748x driver

[Kieran Bingham]

Hi Hans,

On 03/07/17 15:45, Kieran Bingham wrote:
> Hi Hans,
> 
> Thanks for your review,
> 
> On 03/07/17 14:51, Hans Verkuil wrote:
>> On 06/27/2017 05:03 PM, Kieran Bingham wrote:
>>> From: Kieran Bingham 
>>>
>>> Provide support for the ADV7481 and ADV7482.

...

>>> +/* 
>>> -
>>> + * HDMI and CP
>>> + */
>>> +
>>> +#define ADV748X_HDMI_MIN_WIDTH640
>>> +#define ADV748X_HDMI_MAX_WIDTH1920
>>> +#define ADV748X_HDMI_MIN_HEIGHT480
>>> +#define ADV748X_HDMI_MAX_HEIGHT1200
>>> +#define ADV748X_HDMI_MIN_PIXELCLOCK0/* unknown */
>>
>> 0 makes no sense. Something like 1300 would work better (pixelclock rate 
>> for
>> V4L2_DV_BT_CEA_720X480I59_94 is 1350).
> 
> This is another one that must have got lost somehow - you'd already told me 
> this
> and I'm really sure I changed it to the value you suggested ...
> 
> /me is confused at code loss - Must have been a rebase gone bad. :-(
> 
> 
>>> +#define ADV748X_HDMI_MAX_PIXELCLOCK16200
>>
>> You probably based that on the 1600x1200p60 format?
> 
> No idea I'm afraid - it's the value that was set when I recieved the driver...
> 
>>
>> 162MHz is a bit low for an adv receiver. The adv7604 and adv8742 have a max 
>> rate
>> of 225 MHz.
>> This should be documented in the datasheet.
> 
> Hrm ... haven't found it yet - I'll keep digging


I've found this as the most relevant reference:


The ADV7481 HDMI capable receiver supports a maximum pixel clock frequency of
162 MHz, allowing HDTV formats up to 1080p, and display resolutions up to UXGA
(1600 × 1200 at 60 Hz). The device integrates a consumer electronics control
(CEC) controller that supports the capability discovery and control (CDC)
feature. The HDMI input port has dedicated 5 V detect and Hot PlugTM assert 
pins.


So that certainly looks like 162 MHz is the correct value.

>> Besides, you need a bit of margin since detected pixelclock rates can be a 
>> bit off.

Does that mean you would you recommend adding 0.5 MHz to the 162 MHz in a
similar way as the minimum, or keep at 162 MHz ?

(I'm assuming stay at 162 MHz, as the 7604 is set at 225MHz)

--
Regards

Kieran

Re: [PATCH] Hauppauge HVR-1975 support

[Bernhard Rosenkränzer]

On 3 July 2017 at 14:56, Steven Toth  wrote:
> Bernhard, thank you for sharing.
>
> Mauro,
>
> I've reviewed this patch, it has a host of problems.

Yes - it's a 1:1 forward port of the patch Hauppauge released for 3.19
(apparently with the goal to support as many of their devices as
possible).

> the patch also contains materials that I
> suspect Silicon Labs would consider proprietary and confidential, its
> definitely derived works from proprietary SILABS drivers.

Does anyone know for sure what the legal situation is when a HW
manufacturer releases a patch (as Hauppauge did) that is clearly
derived from GPL code yet at the same time derived from non-free code?
My interpretation is that by putting it out, they've released a GPL
derived work, which they can legally do only if they agree to comply
with the GPL, therefore any other license notice would be void.
But as I pointed out before I'm not a lawyer...

ttyl
bero

Re: [PATCH v6 2/3] media: i2c: adv748x: add adv748x driver

[Hans Verkuil]

On 07/03/2017 04:45 PM, Kieran Bingham wrote:

+#define ADV748X_HDMI_MAX_PIXELCLOCK16200


You probably based that on the 1600x1200p60 format?


No idea I'm afraid - it's the value that was set when I recieved the driver...



162MHz is a bit low for an adv receiver. The adv7604 and adv8742 have a max rate
of 225 MHz.
This should be documented in the datasheet.


Hrm ... haven't found it yet - I'll keep digging


This is often documented in the hardware datasheet, not the programming 
datasheet.


+static void adv748x_hdmi_fill_format(struct adv748x_hdmi *hdmi,
+ struct v4l2_mbus_framefmt *fmt)
+{
+memset(fmt, 0, sizeof(*fmt));
+
+fmt->code = MEDIA_BUS_FMT_RGB888_1X24;
+fmt->field = hdmi->timings.bt.interlaced ?
+V4L2_FIELD_INTERLACED : V4L2_FIELD_NONE;


INTERLACED -> ALTERNATE.


OK.

OOI: Is this because of the removal of the interlaced cap - or because
V4L2_FIELD_INTERLACED is deprecated or such?


Unless the adv748x has a deinterlacer you will receive the fields as separate
transfers.

FIELD_INTERLACED means that the two fields are combined into a single frame, but
I doubt that that's what happens. FIELD_ALTERNATE means that the top and bottom
fields are send one after the other.

FIELD_INTERLACED is very common for SDTV, but FIELD_ALTERNATE is almost always
used for HDTV.

That reminds me: in adv748x_afe_fill_format you also set FIELD_INTERLACED, but
is that correct? Shouldn't that also be FIELD_ALTERNATE?




+
+/* The colorspace depends on the AVI InfoFrame contents */


Missed that in the first review: add a 'TODO:' before this comment.


+fmt->colorspace = V4L2_COLORSPACE_SRGB;
+
+fmt->width = hdmi->timings.bt.width;
+fmt->height = hdmi->timings.bt.height;
+}


Regards,

Hans

Re: [PATCH v6 2/3] media: i2c: adv748x: add adv748x driver

[Kieran Bingham]

Hi Hans,

Thanks for your review,

On 03/07/17 14:51, Hans Verkuil wrote:
> On 06/27/2017 05:03 PM, Kieran Bingham wrote:
>> From: Kieran Bingham 
>>
>> Provide support for the ADV7481 and ADV7482.
>>
>> The driver is modelled with 4 subdevices to allow simultaneous streaming
>> from the AFE (Analog front end) and HDMI inputs though two CSI TX
>> entities.
>>
>> The HDMI entity is linked to the TXA CSI bus, whilst the AFE is linked
>> to the TXB CSI bus.
>>
>> The driver is based on a prototype by Koji Matsuoka in the Renesas BSP,
>> and an earlier rework by Niklas Söderlund.
>>
>> Signed-off-by: Kieran Bingham 
>>
>> ---
>>
>> v2:
>>   - Implement DT parsing
>>   - adv748x: Add CSI2 entity
>>   - adv748x: Rework pad allocations and fmts
>>   - Give AFE 8 input pads and move pad defines
>>   - Use the enums to ensure pads are referenced correctly.
>>   - adv748x: Rename AFE/HDMI entities
>> Now they are 'just afe' and 'just hdmi'
>>   - Reorder the entity enum and structures
>>   - Added pad-format for the CSI2 entities
>>   - CSI2 s_stream pass through
>>   - CSI2 control pass through (with link following)
>>
>> v3:
>>   - dt: Extend DT documentation to specify interrupt mappings
>>   - simplify adv748x_parse_dt
>>   - core: Add banner to header file describing ADV748x variants
>>   - Use entity structure pointers rather than global state pointers where
>> possible
>>   - afe: Reduce indent on afe_status
>>   - hdmi: Add error checking to the bt->pixelclock values.
>>   - Remove all unnecessary pad checks: handled by core
>>   - Fix all probe cleanup paths
>>   - adv748x_csi2_probe() now fails if it has no endpoint
>>   - csi2: Fix small oneliners for is_txa and get_remote_sd()
>>   - csi2: Fix checkpatch warnings
>>   - csi2: Fix up s_stream pass-through
>>   - csi2: Fix up Pixel Rate passthrough
>>   - csi2: simplify adv748x_csi2_get_pad_format()
>>   - Remove 'async notifiers' from AFE/HDMI
>> Using async notifiers was overkill, when we have access to the
>> subdevices internally and can register them directly.
>>   - Use state lock in control handlers and clean up s_ctrls
>>   - remove _interruptible mutex locks
>>
>> v4:
>>   - all: Convert hex 0xXX to lowercase
>>   - all: Use defines instead of hardcoded register values
>>   - all: Use regmap
>>   - afe, csi2, hdmi: _probe -> _init
>>   - afe, csi2, hdmi: _remove -> _cleanup
>>   - afe, hdmi: Convert pattern generator to a control
>>   - afe, hdmi: get/set-fmt refactor
>>   - afe, hdmi, csi2: Convert to internal calls for pixelrate
>>   - afe: Allow the AFE to configure the Input Select from DT
>>   - afe: Reduce indent on adv748x_afe_status switch
>>   - afe: Remove ununsed macro definitions AIN0-7
>>   - afe: Remove extraneous control checks handled by core
>>   - afe: Comment fixups
>>   - afe: Rename error label
>>   - afe: Correct control names on the SDP
>>   - afe: Use AIN0-7 rather than AIN1-8 to match ports and MC pads
>>   - core: adv748x_parse_dt references to nodes, and catch multiple
>> endpoints in a port.
>>   - core: adv748x_dt_cleanup to simplify releasing DT nodes
>>   - core: adv748x_print_info renamed to adv748x_identify_chip
>>   - core: reorganise ordering of probe sequence
>>   - core: No need for of_match_ptr
>>   - core: Fix up i2c read/writes (regmap still on todo list)
>>   - core: Set specific functions from the entities on subdev-init
>>   - core: Use kzalloc for state instead of devm
>>   - core: Improve probe error reporting
>>   - core: Track unknown BIT(6) in tx{a,b}_power
>>   - csi2: Improve adv748x_csi2_get_remote_sd as adv748x_csi2_get_source_sd
>>   - csi2: -EPIPE instead of -ENODEV
>>   - csi2: adv_dbg, instead of adv_info
>>   - csi2: adv748x_csi2_set_format fix
>>   - csi2: remove async notifier and sd member variables
>>   - csi2: register links from the CSI2
>>   - csi2: create virtual channel helper function
>>   - dt: Remove numbering from endpoints
>>   - dt: describe ports and interrupts as optional
>>   - dt: Re-tab
>>   - hdmi: adv748x_hdmi_have_signal -> adv748x_hdmi_has_signal
>>   - hdmi: fix adv748x_hdmi_read_pixelclock return checks
>>   - hdmi: improve adv748x_hdmi_set_video_timings
>>   - hdmi: Fix tmp variable as polarity
>>   - hdmi: Improve adv748x_hdmi_s_stream
>>   - hdmi: Clean up adv748x_hdmi_s_ctrl register definitions and usage
>>   - hdmi: Fix up adv748x_hdmi_s_dv_timings with macro names for register
>>   - hdmi: Add locking to adv748x_hdmi_g_dv_timings
>> writes and locking
>>   - hdmi: adv748x_hdmi_set_de_timings function added to clarify DE writes
>>   - hdmi: Use CP in control register naming to match component processor
>>   - hdmi: clean up adv748x_hdmi_query_dv_timings()
>>   - KConfig: Fix up dependency and capitalisation
>>
>> v5:
>>   - afe,hdmi: _set_pixelrate -> _propagate_pixelrate
>>   - hdmi: Fix arm32 compilation failure : Use DIV_ROUND_CLOSEST_ULL
>>   - core: 

Re: [PATCH v2 09/19] media: camms: Add core files

[Todor Tomov]

Hello Hans,

Thank you for the review.

On 07/03/2017 02:24 PM, Hans Verkuil wrote:
> On 06/19/2017 04:48 PM, Todor Tomov wrote:
>> These files implement the platform driver code.
>>
>> Signed-off-by: Todor Tomov 
>> ---
>>   drivers/media/platform/qcom/camss-8x16/camss.c | 630 
>> +
>>   drivers/media/platform/qcom/camss-8x16/camss.h |  96 
>>   2 files changed, 726 insertions(+)
>>   create mode 100644 drivers/media/platform/qcom/camss-8x16/camss.c
>>   create mode 100644 drivers/media/platform/qcom/camss-8x16/camss.h
>>
>> diff --git a/drivers/media/platform/qcom/camss-8x16/camss.c 
>> b/drivers/media/platform/qcom/camss-8x16/camss.c
>> new file mode 100644
>> index 000..a8798d1
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/camss-8x16/camss.c
>> @@ -0,0 +1,630 @@
>> +/*
>> + * camss.c
>> + *
>> + * Qualcomm MSM Camera Subsystem - Core
>> + *
>> + * Copyright (c) 2015, The Linux Foundation. All rights reserved.
>> + * Copyright (C) 2015-2016 Linaro Ltd.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 and
>> + * only version 2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
> 
> v4l2-of.h has been replaced by v4l2-fwnode.h. You need to rebase.

I'll rebase for the next version of the patchset.

> 
> Regards,
> 
> Hans

-- 
Best regards,
Todor Tomov

Re: [PATCH v2 05/19] media: camss: Add CSID files

[Todor Tomov]

Hello Hans,

Thank you for the review.

On 07/03/2017 01:49 PM, Hans Verkuil wrote:
> On 06/19/2017 04:48 PM, Todor Tomov wrote:
>> These files control the CSID modules which handle the protocol and 
>> application
>> layer of the CSI2 receivers.
>>
>> Signed-off-by: Todor Tomov 
>> ---
>>   drivers/media/platform/qcom/camss-8x16/csid.c | 1072 
>> +
>>   drivers/media/platform/qcom/camss-8x16/csid.h |   82 ++
>>   2 files changed, 1154 insertions(+)
>>   create mode 100644 drivers/media/platform/qcom/camss-8x16/csid.c
>>   create mode 100644 drivers/media/platform/qcom/camss-8x16/csid.h
>>
>> diff --git a/drivers/media/platform/qcom/camss-8x16/csid.c 
>> b/drivers/media/platform/qcom/camss-8x16/csid.c
>> new file mode 100644
>> index 000..c637d78
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/camss-8x16/csid.c
>> @@ -0,0 +1,1072 @@
>> +/*
>> + * csid.c
>> + *
>> + * Qualcomm MSM Camera Subsystem - CSID Module
>> + *
>> + * Copyright (c) 2011-2015, The Linux Foundation. All rights reserved.
>> + * Copyright (C) 2015-2016 Linaro Ltd.
> 
> 2016 -> 2017
> 
> This should probably be done elsewhere as well.

Yes, I'll fix it here and on all other places.

> 
> Regards,
> 
> Hans

-- 
Best regards,
Todor Tomov

Re: [PATCH v2 09/19] media: camms: Add core files

[Todor Tomov]

Hi Sakari,

Thank you for the review.

On 06/29/2017 09:33 AM, Sakari Ailus wrote:
> Hi Todor,
> 
> On Mon, Jun 19, 2017 at 05:48:29PM +0300, Todor Tomov wrote:
>> These files implement the platform driver code.
>>
>> Signed-off-by: Todor Tomov 
>> ---
>>  drivers/media/platform/qcom/camss-8x16/camss.c | 630 
>> +
>>  drivers/media/platform/qcom/camss-8x16/camss.h |  96 
>>  2 files changed, 726 insertions(+)
>>  create mode 100644 drivers/media/platform/qcom/camss-8x16/camss.c
>>  create mode 100644 drivers/media/platform/qcom/camss-8x16/camss.h
>>
>> diff --git a/drivers/media/platform/qcom/camss-8x16/camss.c 
>> b/drivers/media/platform/qcom/camss-8x16/camss.c
>> new file mode 100644
>> index 000..a8798d1
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/camss-8x16/camss.c
>> @@ -0,0 +1,630 @@
>> +/*
>> + * camss.c
>> + *
>> + * Qualcomm MSM Camera Subsystem - Core
>> + *
>> + * Copyright (c) 2015, The Linux Foundation. All rights reserved.
>> + * Copyright (C) 2015-2016 Linaro Ltd.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 and
>> + * only version 2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "camss.h"
>> +
>> +static struct resources csiphy_res[] = {
>> +/* CSIPHY0 */
>> +{
>> +.regulator = { NULL },
>> +.clock = { "camss_top_ahb_clk", "ispif_ahb_clk",
>> +   "camss_ahb_clk", "csiphy0_timer_clk" },
>> +.clock_rate = { 0, 0, 0, 2 },
>> +.reg = { "csiphy0", "csiphy0_clk_mux" },
>> +.interrupt = { "csiphy0" }
>> +},
>> +
>> +/* CSIPHY1 */
>> +{
>> +.regulator = { NULL },
>> +.clock = { "camss_top_ahb_clk", "ispif_ahb_clk",
>> +   "camss_ahb_clk", "csiphy1_timer_clk" },
>> +.clock_rate = { 0, 0, 0, 2 },
>> +.reg = { "csiphy1", "csiphy1_clk_mux" },
>> +.interrupt = { "csiphy1" }
>> +}
>> +};
>> +
>> +static struct resources csid_res[] = {
>> +/* CSID0 */
>> +{
>> +.regulator = { "vdda" },
>> +.clock = { "camss_top_ahb_clk", "ispif_ahb_clk",
>> +   "csi0_ahb_clk", "camss_ahb_clk",
>> +   "csi0_clk", "csi0_phy_clk",
>> +   "csi0_pix_clk", "csi0_rdi_clk" },
>> +.clock_rate = { 0, 0, 0, 0, 2, 0, 0, 0 },
>> +.reg = { "csid0" },
>> +.interrupt = { "csid0" }
>> +},
>> +
>> +/* CSID1 */
>> +{
>> +.regulator = { "vdda" },
>> +.clock = { "camss_top_ahb_clk", "ispif_ahb_clk",
>> +   "csi1_ahb_clk", "camss_ahb_clk",
>> +   "csi1_clk", "csi1_phy_clk",
>> +   "csi1_pix_clk", "csi1_rdi_clk" },
>> +.clock_rate = { 0, 0, 0, 0, 2, 0, 0, 0 },
>> +.reg = { "csid1" },
>> +.interrupt = { "csid1" }
>> +},
>> +};
>> +
>> +static struct resources_ispif ispif_res = {
>> +/* ISPIF */
>> +.clock = { "camss_top_ahb_clk", "camss_ahb_clk", "ispif_ahb_clk",
>> +   "csi0_clk", "csi0_pix_clk", "csi0_rdi_clk",
>> +   "csi1_clk", "csi1_pix_clk", "csi1_rdi_clk" },
>> +.clock_for_reset = { "camss_vfe_vfe_clk", "camss_csi_vfe_clk" },
>> +.reg = { "ispif", "csi_clk_mux" },
>> +.interrupt = "ispif"
>> +
>> +};
>> +
>> +static struct resources vfe_res = {
>> +/* VFE0 */
>> +.regulator = { NULL },
>> +.clock = { "camss_top_ahb_clk", "camss_vfe_vfe_clk",
>> +   "camss_csi_vfe_clk", "iface_clk",
>> +   "bus_clk", "camss_ahb_clk" },
>> +.clock_rate = { 0, 32000, 0, 0, 0, 0, 0, 0 },
>> +.reg = { "vfe0" },
>> +.interrupt = { "vfe0" }
>> +};
> 
> Could these be const?

Sure.

> 
>> +
>> +/*
>> + * camss_enable_clocks - Enable multiple clocks
>> + * @nclocks: Number of clocks in clock array
>> + * @clock: Clock array
>> + * @dev: Device
>> + *
>> + * Return 0 on success or a negative error code otherwise
>> + */
>> +int camss_enable_clocks(int nclocks, struct clk **clock, struct device *dev)
>> +{
>> +int ret;
>> +int i;
>> +
>> +for (i = 0; i < nclocks; i++) {
>> +ret = clk_prepare_enable(clock[i]);
>> +if (ret) {
>> +dev_err(dev, "clock enable failed\n");
>> +goto error;
>> +}
>> +}

Re: [PATCH v6 2/3] media: i2c: adv748x: add adv748x driver

[Hans Verkuil]

On 06/27/2017 05:03 PM, Kieran Bingham wrote:

From: Kieran Bingham 

Provide support for the ADV7481 and ADV7482.

The driver is modelled with 4 subdevices to allow simultaneous streaming
from the AFE (Analog front end) and HDMI inputs though two CSI TX
entities.

The HDMI entity is linked to the TXA CSI bus, whilst the AFE is linked
to the TXB CSI bus.

The driver is based on a prototype by Koji Matsuoka in the Renesas BSP,
and an earlier rework by Niklas Söderlund.

Signed-off-by: Kieran Bingham 

---

v2:
  - Implement DT parsing
  - adv748x: Add CSI2 entity
  - adv748x: Rework pad allocations and fmts
  - Give AFE 8 input pads and move pad defines
  - Use the enums to ensure pads are referenced correctly.
  - adv748x: Rename AFE/HDMI entities
Now they are 'just afe' and 'just hdmi'
  - Reorder the entity enum and structures
  - Added pad-format for the CSI2 entities
  - CSI2 s_stream pass through
  - CSI2 control pass through (with link following)

v3:
  - dt: Extend DT documentation to specify interrupt mappings
  - simplify adv748x_parse_dt
  - core: Add banner to header file describing ADV748x variants
  - Use entity structure pointers rather than global state pointers where
possible
  - afe: Reduce indent on afe_status
  - hdmi: Add error checking to the bt->pixelclock values.
  - Remove all unnecessary pad checks: handled by core
  - Fix all probe cleanup paths
  - adv748x_csi2_probe() now fails if it has no endpoint
  - csi2: Fix small oneliners for is_txa and get_remote_sd()
  - csi2: Fix checkpatch warnings
  - csi2: Fix up s_stream pass-through
  - csi2: Fix up Pixel Rate passthrough
  - csi2: simplify adv748x_csi2_get_pad_format()
  - Remove 'async notifiers' from AFE/HDMI
Using async notifiers was overkill, when we have access to the
subdevices internally and can register them directly.
  - Use state lock in control handlers and clean up s_ctrls
  - remove _interruptible mutex locks

v4:
  - all: Convert hex 0xXX to lowercase
  - all: Use defines instead of hardcoded register values
  - all: Use regmap
  - afe, csi2, hdmi: _probe -> _init
  - afe, csi2, hdmi: _remove -> _cleanup
  - afe, hdmi: Convert pattern generator to a control
  - afe, hdmi: get/set-fmt refactor
  - afe, hdmi, csi2: Convert to internal calls for pixelrate
  - afe: Allow the AFE to configure the Input Select from DT
  - afe: Reduce indent on adv748x_afe_status switch
  - afe: Remove ununsed macro definitions AIN0-7
  - afe: Remove extraneous control checks handled by core
  - afe: Comment fixups
  - afe: Rename error label
  - afe: Correct control names on the SDP
  - afe: Use AIN0-7 rather than AIN1-8 to match ports and MC pads
  - core: adv748x_parse_dt references to nodes, and catch multiple
endpoints in a port.
  - core: adv748x_dt_cleanup to simplify releasing DT nodes
  - core: adv748x_print_info renamed to adv748x_identify_chip
  - core: reorganise ordering of probe sequence
  - core: No need for of_match_ptr
  - core: Fix up i2c read/writes (regmap still on todo list)
  - core: Set specific functions from the entities on subdev-init
  - core: Use kzalloc for state instead of devm
  - core: Improve probe error reporting
  - core: Track unknown BIT(6) in tx{a,b}_power
  - csi2: Improve adv748x_csi2_get_remote_sd as adv748x_csi2_get_source_sd
  - csi2: -EPIPE instead of -ENODEV
  - csi2: adv_dbg, instead of adv_info
  - csi2: adv748x_csi2_set_format fix
  - csi2: remove async notifier and sd member variables
  - csi2: register links from the CSI2
  - csi2: create virtual channel helper function
  - dt: Remove numbering from endpoints
  - dt: describe ports and interrupts as optional
  - dt: Re-tab
  - hdmi: adv748x_hdmi_have_signal -> adv748x_hdmi_has_signal
  - hdmi: fix adv748x_hdmi_read_pixelclock return checks
  - hdmi: improve adv748x_hdmi_set_video_timings
  - hdmi: Fix tmp variable as polarity
  - hdmi: Improve adv748x_hdmi_s_stream
  - hdmi: Clean up adv748x_hdmi_s_ctrl register definitions and usage
  - hdmi: Fix up adv748x_hdmi_s_dv_timings with macro names for register
  - hdmi: Add locking to adv748x_hdmi_g_dv_timings
writes and locking
  - hdmi: adv748x_hdmi_set_de_timings function added to clarify DE writes
  - hdmi: Use CP in control register naming to match component processor
  - hdmi: clean up adv748x_hdmi_query_dv_timings()
  - KConfig: Fix up dependency and capitalisation

v5:
  - afe,hdmi: _set_pixelrate -> _propagate_pixelrate
  - hdmi: Fix arm32 compilation failure : Use DIV_ROUND_CLOSEST_ULL
  - core: remove unused link functions
  - csi2: Use immutable links for HDMI->TXA, AFE->TXB

v6:
  - hdmi: Provide EDID support
  - afe: Fix InLock inversion bug
  - afe: Prevent autodetection of input format except in querystd
  - afe,hdmi: Improve pattern generator control strings
  - hdmi: Remove interlaced support capability (it's untested)

  drivers/media/i2c/Kconfig|  11 +-
 

Re: [PATCH] Hauppauge HVR-1975 support

[Steven Toth]

(Resending)

Bernhard, thank you for sharing.

Mauro,

I've reviewed this patch, it has a host of problems.

Ignoring the fact it contains patches to all sorts of different cards
(saa7164, CX231xx, PVR-USB2)... the patch also contains materials that
I suspect Silicon Labs would consider proprietary and confidential,
its definitely derived works from proprietary SILABS drivers.

Proceed with caution.

- Steve

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

On Mon, Jul 3, 2017 at 5:57 AM, Bernhard Rosenkränzer
 wrote:
> Hi,
> Hauppauge HVR-1975 is a USB DVB receiver box,
> http://www.hauppauge.co.uk/site/products/data_hvr1900.html
>
> It is currently not supported by v4l; Hauppauge provides a patch for
> kernel 3.19 at http://www.hauppauge.com/site/support/linux.html
>
> As expected, the patch doesn't work with more recent kernels, so I've
> ported it (verified to work on 4.11.8). Due to the size of the patch,
> I've uploaded my patch to
> http://lindev.ch/hauppauge-hvr-1975.patch
>
> While it works well, there's a potential license problem in one of the files:
> From drivers/media/dvb-frontend/silg.c:
>
> /* MODULE_LICENSE("Proprietary"); */
> /* GPL discussion for silg not finished. Set to GPL for internal usage only. 
> */
> /* The module uses GPL functions and is rejected by the kernel build if the */
> /* license is set to 'Proprietary'. */
> MODULE_LICENSE("GPL");
>
> I'm not a lawyer, but my understanding is that by Hauppauge actually
> releasing that file to the public (and it being so clearly a derivate
> of GPL code that they even have to acknowledge it), their claim that
> it is anything but GPL is null and void - but we may have to make
> sure.
>
> ttyl
> bero

Re: [PATCH v6] media: platform: Renesas IMR driver

[Hans Verkuil]

On 06/23/2017 10:34 PM, Sergei Shtylyov wrote:

Index: media_tree/Documentation/media/v4l-drivers/rcar_imr.rst
===
--- /dev/null
+++ media_tree/Documentation/media/v4l-drivers/rcar_imr.rst
@@ -0,0 +1,86 @@
+Renesas R-Car Image Rendeder (IMR) Driver


Rendeder -> Renderer


+=
+
+This file documents some driver-specific aspects of the IMR driver, such as
+driver-specific ioctls.
+
+The ioctl reference
+~~~
+
+VIDIOC_IMR_MESH - Set mapping data
+^^
+
+Argument: struct imr_map_desc
+
+**Description**:
+
+   This ioctl sets up the mesh using which the input frames will be


s/using/through/


+   transformed into the output frames. The mesh can be strictly rectangular
+   (when IMR_MAP_MESH bit is set in imr_map_desc::type) or arbitrary (when
+   that bit is not set).
+
+   A rectangular mesh consists of the imr_mesh structure followed by M*N
+   vertex objects (where M is imr_mesh::rows and N is imr_mesh::columns).
+   In case either IMR_MAP_AUTOSG or IMR_MAP_AUTODG bits were set in
+   imr_map_desc::type, imr_mesh::{x|y}0 specify the coordinates of the top
+   left corner of the auto-generated mesh and imr_mesh::d{x|y} specify the
+   mesh's X/Y steps.


What if any of the other types are used like IMR_MAP_LUCE?

Is this documented in a Renesas datasheet? If so, add a reference to that in 
this
documentation.


+
+   An arbitrary mesh consists of the imr_vbo structure followed by N
+   triangle objects (where N is imr_vbo::num), consisting of 3 vertex
+   objects each.
+
+   A vertex object has a complex structure:
+
+.. code-block:: none
+
+   __u16   v   vertical   \ source coordinates (only present
+   __u16   u   horizontal / if IMR_MAP_AUTOSG isn't set)
+   __u16   Y   vertical   \ destination coordinates (only here
+   __u16   X   horizontal / if IMR_MAP_AUTODG isn't set)
+   __s8lofst   offset \  luminance correction parameters
+   __u8lscal   scale   > (only present if IMR_MAP_LUCE
+   __u16   reserved   /  is set)
+   __s8vrofs   V value offset \  hue correction parameters
+   __u8vrscl   V value scale   \ (only present if IMR_MAP_CLCE
+   __s8ubofs   U value offset  / is set)
+   __u8ubscl   U value scale  /


Is this the internal structure? Or something that userspace has to fill in?
It's not clear at all.

I recommend giving a few code examples of how this should be used.


+
+**Return value**:
+
+   On success 0 is returned. On error -1 is returned and errno is set
+   appropriately.
+
+**Data types**:
+
+.. code-block:: none
+
+   * struct imr_map_desc
+
+   __u32   typemapping types


This is a bitmask? If so, what combination of bits are allowed?


+   __u32   sizetotal size of the mesh structure
+   __u64   datamap-specific user-pointer
+
+   IMR_MAP_MESHregular mesh specification
+   IMR_MAP_AUTOSG  auto-generated source coordinates
+   IMR_MAP_AUTODG  auto-generated destination coordinates
+   IMR_MAP_LUCEluminance correction flag
+   IMR_MAP_CLCEchromacity correction flag


You probably mean 'chroma'. 'chromacity' isn't a word.


+   IMR_MAP_TCM vertex clockwise-mode order
+   IMR_MAP_UVDPOR(n)   source coordinate decimal point position
+   IMR_MAP_DDP destination coordinate sub-pixel mode
+   IMR_MAP_YLDPO(n)luminance correction offset decimal point
+   position
+   IMR_MAP_UBDPO(n)chromacity (U) correction offset decimal point
+   position
+   IMR_MAP_VRDPO(n)chromacity (V) correction offset decimal point
+   position


There is no documentation what how these types relate to IMR_MAP_MESH and
IMR_MAP_AUTOS/DG.


+
+   * struct imr_mesh   regular mesh specification
+
+   __u16   rows, columns   rectangular mesh sizes
+   __u16   x0, y0, dx, dy  auto-generated mesh parameters
+
+   * struct imr_vbovertex-buffer-object (VBO) descriptor
+
+   __u16   num number of triangles


Sorry, this needs more work.

Regards,

Hans

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

[Maxime Ripard]

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

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

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

Signed-off-by: Maxime Ripard 
---
 drivers/media/platform/Kconfig   |   1 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/cadence/Kconfig   |  12 +
 drivers/media/platform/cadence/Makefile  |   1 +
 drivers/media/platform/cadence/cdns-csi2rx.c | 440 +++
 5 files changed, 456 insertions(+)
 create mode 100644 drivers/media/platform/cadence/Kconfig
 create mode 100644 drivers/media/platform/cadence/Makefile
 create mode 100644 drivers/media/platform/cadence/cdns-csi2rx.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 1313cd533436..a79d96e9b723 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -26,6 +26,7 @@ config VIDEO_VIA_CAMERA
 #
 # Platform multimedia device configuration
 #
+source "drivers/media/platform/cadence/Kconfig"
 
 source "drivers/media/platform/davinci/Kconfig"
 
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 9beadc760467..1d31eb51e9bb 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -2,6 +2,8 @@
 # Makefile for the video capture/playback device drivers.
 #
 
+obj-$(CONFIG_VIDEO_CADENCE)+= cadence/
+
 obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o
 
 obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
diff --git a/drivers/media/platform/cadence/Kconfig 
b/drivers/media/platform/cadence/Kconfig
new file mode 100644
index ..d1b6bbb6a0eb
--- /dev/null
+++ b/drivers/media/platform/cadence/Kconfig
@@ -0,0 +1,12 @@
+config VIDEO_CADENCE
+   bool "Cadence Video Devices"
+
+if VIDEO_CADENCE
+
+config VIDEO_CADENCE_CSI2RX
+   tristate "Cadence MIPI-CSI2 RX Controller v1.3"
+   depends on MEDIA_CONTROLLER
+   depends on VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+
+endif
diff --git a/drivers/media/platform/cadence/Makefile 
b/drivers/media/platform/cadence/Makefile
new file mode 100644
index ..99a4086b7448
--- /dev/null
+++ b/drivers/media/platform/cadence/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_CADENCE_CSI2RX) += cdns-csi2rx.o
diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c 
b/drivers/media/platform/cadence/cdns-csi2rx.c
new file mode 100644
index ..40bf063bd44f
--- /dev/null
+++ b/drivers/media/platform/cadence/cdns-csi2rx.c
@@ -0,0 +1,440 @@
+/*
+ * Driver for Cadence MIPI-CSI2 RX Controller v1.3
+ *
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define CSI2RX_DEVICE_CFG_REG  0x000
+
+#define CSI2RX_SOFT_RESET_REG  0x004
+#define CSI2RX_SOFT_RESET_PROTOCOL BIT(1)
+#define CSI2RX_SOFT_RESET_FRONTBIT(0)
+
+#define CSI2RX_STATIC_CFG_REG  0x008
+
+#define CSI2RX_STREAM_BASE(n)  (((n) + 1) * 0x100)
+
+#define CSI2RX_STREAM_CTRL_REG(n)  (CSI2RX_STREAM_BASE(n) + 0x000)
+#define CSI2RX_STREAM_CTRL_START   BIT(0)
+
+#define CSI2RX_STREAM_DATA_CFG_REG(n)  (CSI2RX_STREAM_BASE(n) + 0x008)
+#define CSI2RX_STREAM_DATA_CFG_EN_VC_SELECTBIT(31)
+#define CSI2RX_STREAM_DATA_CFG_VC_SELECT(n)BIT((n) + 16)
+
+#define CSI2RX_STREAM_CFG_REG(n)   (CSI2RX_STREAM_BASE(n) + 0x00c)
+#define CSI2RX_STREAM_CFG_FIFO_MODE_LARGE_BUF  (1 << 8)
+
+#define CSI2RX_STREAMS_MAX 4
+
+enum csi2rx_pads {
+   CSI2RX_PAD_SINK,
+   CSI2RX_PAD_SOURCE_VC0,
+   CSI2RX_PAD_SOURCE_VC1,
+   CSI2RX_PAD_SOURCE_VC2,
+   CSI2RX_PAD_SOURCE_VC3,
+   CSI2RX_PAD_MAX,
+};
+
+struct csi2rx_priv {
+   struct device   *dev;
+
+   void __iomem*base;
+   struct clk  *sys_clk;
+   struct clk  *p_clk;
+   struct clk  *p_free_clk;
+   struct clk  *pixel_clk[CSI2RX_STREAMS_MAX];
+   struct clk  *dphy_rx_clk;
+
+   u8  lanes;
+   u8  max_lanes;
+   u8  max_streams;
+   boolcdns_dphy;
+
+   struct v4l2_subdev  

[PATCH 1/2] dt-bindings: media: Add Cadence MIPI-CSI2RX Device Tree bindings

[Maxime Ripard]

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

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

Signed-off-by: Maxime Ripard 
---
 .../devicetree/bindings/media/cdns-csi2rx.txt  | 87 ++
 1 file changed, 87 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cdns-csi2rx.txt

diff --git a/Documentation/devicetree/bindings/media/cdns-csi2rx.txt 
b/Documentation/devicetree/bindings/media/cdns-csi2rx.txt
new file mode 100644
index ..b5bcb6ad18fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cdns-csi2rx.txt
@@ -0,0 +1,87 @@
+Cadence CSI2RX controller
+=
+
+The Cadence CSI2RX controller is a CSI-2 bridge supporting up to 4 CSI
+lanes in input, and 4 different pixel streams in output.
+
+Required properties:
+  - compatible: must be set to "cdns,csi2rx"
+  - reg: base address and size of the memory mapped region
+  - clocks: phandles to the clocks driving the controller
+  - clock-names: must contain:
+* sys_clk: main clock
+* p_clk: register bank clock
+* p_free_clk: free running register bank clock
+* pixel_ifX_clk: pixel stream output clock, one for each stream
+ implemented in hardware, between 0 and 3
+* dphy_rx_clk: D-PHY byte clock, if implemented in hardware
+  - phys: phandle to the external D-PHY
+  - phy-names: must contain dphy, if the implementation uses an
+   external D-PHY
+
+Required subnodes:
+  - ports: A ports node with endpoint definitions as defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt. The
+   first port subnode should be the input endpoint, the second one the
+   outputs
+
+  The output port should have as many endpoints as stream supported by
+  the hardware implementation, between 1 and 4, their ID being the
+  stream output number used in the implementation.
+
+Example:
+
+csi2rx: csi-bridge@0d06 {
+   compatible = "cdns,csi2rx";
+   reg = <0x0d06 0x1000>;
+   clocks = <>, <>, <>,
+<>, <>,
+<>, <>;
+   clock-names = "sys_clk", "p_clk", "p_free_clk",
+ "pixel_if0_clk", "pixel_if1_clk",
+ "pixel_if2_clk", "pixel_if3_clk";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   csi2rx_in_sensor: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_csi2rx>;
+   clock-lanes = <0>;
+   data-lanes = <1 2>;
+   };
+   };
+
+   port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   csi2rx_out_grabber0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_in_csi2rx>;
+   };
+
+   csi2rx_out_grabber1: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <_in_csi2rx>;
+   };
+
+   csi2rx_out_grabber2: endpoint@2 {
+   reg = <2>;
+   remote-endpoint = <_in_csi2rx>;
+   };
+
+   csi2rx_out_grabber3: endpoint@3 {
+   reg = <3>;
+   remote-endpoint = <_in_csi2rx>;
+   };
+   };
+   };
+};
-- 
2.13.0

[PATCH 0/2] media: v4l: Add support for the Cadence MIPI-CSI2RX

[Maxime Ripard]

Hi,

Here is an attempt at supporting the MIPI-CSI2 RX block from Cadence.

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

It is able to map streams to both CSI datatypes and virtual channels,
dynamically. This is unclear at this point what the right way to
support it would be, so the driver only uses a static mapping between
the virtual channels and streams, and ignores the data types.

This serie depends on the patch "v4l: async: add subnotifier
registration for subdevices" from Niklas Söderlund.

Let me know what you think!
Maxime

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

 .../devicetree/bindings/media/cdns-csi2rx.txt  |  87 
 drivers/media/platform/Kconfig |   1 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/cadence/Kconfig |  12 +
 drivers/media/platform/cadence/Makefile|   1 +
 drivers/media/platform/cadence/cdns-csi2rx.c   | 440 +
 6 files changed, 543 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cdns-csi2rx.txt
 create mode 100644 drivers/media/platform/cadence/Kconfig
 create mode 100644 drivers/media/platform/cadence/Makefile
 create mode 100644 drivers/media/platform/cadence/cdns-csi2rx.c

-- 
2.13.0

Re: [PATCH] [media] media: Make parameter of media_entity_remote_pad() const

[Sakari Ailus]

On Mon, Jul 03, 2017 at 03:08:11PM +0300, Todor Tomov wrote:
> The local pad parameter in media_entity_remote_pad() is not modified.
> Make that explicit by adding a const modifier.
> 
> Signed-off-by: Todor Tomov 

Thanks!

Acked-by: Sakari Ailus 

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

Re: [PATCH v6] media: platform: Renesas IMR driver

[Hans Verkuil]

Hi Sergei,

Some comments below:

On 06/23/2017 10:34 PM, Sergei Shtylyov wrote:

From: Konstantin Kozhevnikov 

The image renderer, or the distortion correction engine, is a drawing
processor with a simple instruction system capable of referencing video
capture data or data in an external memory as the 2D texture data and
performing texture mapping and drawing with respect to any shape that is
split into triangular objects.

This V4L2 memory-to-memory device driver only supports image renderer light
extended 4 (IMR-LX4) found in the R-Car gen3 SoCs; the R-Car gen2 support
can be added later...

[Sergei: merged 2 original patches, added  the patch description, removed
unrelated parts,  added the binding document and the UAPI documentation,
ported the driver to the modern kernel, renamed the UAPI header file and
the guard macros to match the driver name, extended the copyrights, fixed
up Kconfig prompt/depends/help, made use of the BIT/GENMASK() macros,
sorted  #include's, replaced 'imr_ctx::crop' array with the 'imr_ctx::rect'
structure, replaced imr_{g|s}_crop() with imr_{g|s}_selection(), completely
rewrote imr_queue_setup(), removed 'imr_format_info::name', moved the
applicable code from imr_buf_queue() to imr_buf_prepare() and moved the
rest of imr_buf_queue() after imr_buf_finish(), assigned 'src_vq->dev' and
'dst_vq->dev' in imr_queue_init(), removed imr_start_streaming(), assigned
'src_vq->dev' and 'dst_vq->dev' in imr_queue_init(), clarified the math in
imt_tri_type_{a|b|c}_length(), clarified the pointer math and avoided casts
to 'void *' in imr_tri_set_type_{a|b|c}(), replaced imr_{reqbufs|querybuf|
dqbuf|expbuf|streamon|streamoff}() with the generic helpers, implemented
vidioc_{create_bufs|prepare_buf}() methods, used ALIGN() macro and merged
the matrix size checks and replaced kmalloc()/copy_from_user() calls with
memdup_user() call in imr_ioctl_map(), moved setting device capabilities
from imr_querycap() to imr_probe(), set the valid default queue format in
imr_probe(), removed leading dots and fixed grammar in the comments, fixed
up  the indentation  to use  tabs where possible, renamed DLSR, CMRCR.
DY1{0|2}, and ICR bits to match the manual, changed the prefixes of the
CMRCR[2]/TRI{M|C}R bits/fields to match the manual, removed non-existent
TRIMR.D{Y|U}D{X|V}M bits, added/used the IMR/{UV|CP}DPOR/SUSR bits/fields/
shifts, separated the register offset/bit #define's, sorted instruction
macros by opcode, removed unsupported LINE instruction, masked the register
address in WTL[2]/WTS instruction macros, moved the display list #define's
after the register #define's, removing the redundant comment, avoided
setting reserved bits when writing CMRCCR[2]/TRIMCR, used the SR bits
instead of a bare number, removed *inline* from .c file, fixed lines over
80 columns, removed useless spaces, comments, parens, operators, casts,
braces, variables, #include's, statements, and even 1 function, added
useful local variable, uppercased and spelled out the abbreviations,
made comment wording more consistent/correct, fixed the comment typos,
reformatted some multiline comments, inserted empty line after declaration,
removed extra empty lines,  reordered some local variable desclarations,
removed calls to 4l2_err() on kmalloc() failure, replaced '*' with 'x'
in some format strings for v4l2_dbg(), fixed the error returned by
imr_default(), avoided code duplication in the IRQ handler, used '__packed'
for the UAPI structures, declared 'imr_map_desc::data' as '__u64' instead
of 'void *', switched to '__u{16|32}' in the UAPI header, enclosed the
macro parameters in parens, exchanged the values of IMR_MAP_AUTO{S|D}G
macros.]


As Geert suggested, just replace this with a 'Based-on' line.




Index: media_tree/drivers/media/platform/rcar_imr.c
===
--- /dev/null
+++ media_tree/drivers/media/platform/rcar_imr.c
@@ -0,0 +1,1877 @@





+/* add reference to the current configuration */
+static struct imr_cfg *imr_cfg_ref(struct imr_ctx *ctx)


imr_cfg_ref -> imr_cfg_ref_get


+{
+   struct imr_cfg *cfg = ctx->cfg;
+
+   BUG_ON(!cfg);


Perhaps this can be replaced by:

if (WARN_ON(!cfg))
return NULL;


+   cfg->refcount++;
+   return cfg;
+}
+
+/* mesh configuration destructor */
+static void imr_cfg_unref(struct imr_ctx *ctx, struct imr_cfg *cfg)


imr_cfg_unref -> imr_cfg_ref_put

That follows the standard naming conventions for refcounting.


+{
+   struct imr_device *imr = ctx->imr;
+
+   /* no atomicity is required as operation is locked with device mutex */
+   if (!cfg || --cfg->refcount)
+   return;
+
+   /* release memory allocated for a display list */
+   if (cfg->dl_vaddr)
+   dma_free_writecombine(imr->dev, cfg->dl_size, cfg->dl_vaddr,
+ cfg->dl_dma_addr);
+
+   /* destroy the 

[PATCH] [media] media: Make parameter of media_entity_remote_pad() const

[Todor Tomov]

The local pad parameter in media_entity_remote_pad() is not modified.
Make that explicit by adding a const modifier.

Signed-off-by: Todor Tomov 
---
 drivers/media/media-entity.c | 2 +-
 include/media/media-entity.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index c68239e..60f9de0 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -854,7 +854,7 @@ struct media_link *
 }
 EXPORT_SYMBOL_GPL(media_entity_find_link);
 
-struct media_pad *media_entity_remote_pad(struct media_pad *pad)
+struct media_pad *media_entity_remote_pad(const struct media_pad *pad)
 {
struct media_link *link;
 
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index b2203ee..bb3a57c 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -804,7 +804,7 @@ struct media_link *media_entity_find_link(struct media_pad 
*source,
  * Return: returns a pointer to the pad at the remote end of the first found
  * enabled link, or %NULL if no enabled link has been found.
  */
-struct media_pad *media_entity_remote_pad(struct media_pad *pad);
+struct media_pad *media_entity_remote_pad(const struct media_pad *pad);
 
 /**
  * media_entity_get - Get a reference to the parent module
-- 
1.9.1

Re: [PATCH] media: adv7180: add missing adv7180cp, adv7180st i2c device IDs

[Geert Uytterhoeven]

Hi Ulrich,

On Mon, Jul 3, 2017 at 10:43 AM, Ulrich Hecht
 wrote:
> Fixes a crash on Renesas R8A7793 Gose board that uses these "compatible"
> entries.

Thanks!

> Signed-off-by: Ulrich Hecht 

Tested-by: Geert Uytterhoeven 
(i.e. it no longer crashes during boot).

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v2 00/19] Qualcomm 8x16 Camera Subsystem driver

[Hans Verkuil]

On 06/19/2017 04:48 PM, Todor Tomov wrote:

This patchset adds basic support for the Qualcomm Camera Subsystem found
on Qualcomm MSM8916 and APQ8016 processors.

The driver implements V4L2, Media controller and V4L2 subdev interfaces.
Camera sensor using V4L2 subdev interface in the kernel is supported.

The driver is implemented using as a reference the Qualcomm Camera
Subsystem driver for Android as found in Code Aurora [1].

The driver is tested on Dragonboard 410C (APQ8016) with one and two
OV5645 camera sensors. media-ctl [2] and yavta [3] applications were
used for testing. Also Gstreamer 1.10.4 with v4l2src plugin is supported.

More information is present in the document added by the third patch.

---

Patchset Changelog:

Version 2:
- patches 01-10 are updated from v1 following the review received and bugs
   and limitaitons found after v1 was posted. The updates include:
   - return buffers on unsuccessful stream on;
   - fill device capabilities in struct video_device;
   - simplify v4l2 file handle usage - no custom struct for file handle;
   - use vb2_fop_poll and vb2_fop_mmap v4l2 file operations;
   - add support for read/write I/O;
   - add support for DMABUF streaming I/O;
   - add support for EXPBUF and PREPARE_BUF ioctl;
   - avoid a race condition between device unbind and userspace access
 to the video node;
   - use non-contiguous memory for video buffers;
   - switch to V4L2 multi-planar API;
   - add useful error messages in case of an overflow in ISPIF;
   - other small and style fixes.

- patches 11-19 are new (they were not ready/posted with v1). I'm including
   these in this patchset as they add valuable features and may be desired
   for a real world usage of the driver.

---

The patchset depends on:
v4l: Add packed Bayer raw12 pixel formats [4]

---

V4L2 compliance test result:

$ v4l2-compliance -s -d /dev/video0
v4l2-compliance SHA   : ce237eefc1f6dafafc0e1fe3a5fd9f075d3fd066

Driver Info:
 Driver name   : qcom-camss
 Card type : Qualcomm Camera Subsystem
 Bus info  : platform:1b0ac00.camss
 Driver version: 4.9.27
 Capabilities  : 0x85201000
 Video Capture Multiplanar
 Read/Write
 Streaming
 Extended Pix Format
 Device Capabilities
 Device Caps   : 0x05201000
 Video Capture Multiplanar
 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 (Not Supported)

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 (Not Supported)
 test VIDIOC_QUERYCTRL: OK (Not Supported)
 test VIDIOC_G/S_CTRL: OK (Not Supported)
 test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
 test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
 test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
 Standard Controls: 0 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 

Re: [PATCH v2 08/19] media: camss: Add files which handle the video device nodes

[Hans Verkuil]

On 06/19/2017 04:48 PM, Todor Tomov wrote:

These files handle the video device nodes of the camss driver.

Signed-off-by: Todor Tomov 
---
  drivers/media/platform/qcom/camss-8x16/video.c | 629 +
  drivers/media/platform/qcom/camss-8x16/video.h |  64 +++
  2 files changed, 693 insertions(+)
  create mode 100644 drivers/media/platform/qcom/camss-8x16/video.c
  create mode 100644 drivers/media/platform/qcom/camss-8x16/video.h

diff --git a/drivers/media/platform/qcom/camss-8x16/video.c 
b/drivers/media/platform/qcom/camss-8x16/video.c
new file mode 100644
index 000..07175d3
--- /dev/null
+++ b/drivers/media/platform/qcom/camss-8x16/video.c
@@ -0,0 +1,629 @@
+/*
+ * video.c
+ *
+ * Qualcomm MSM Camera Subsystem - V4L2 device node
+ *
+ * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2015-2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "video.h"
+#include "camss.h"
+
+/*
+ * struct format_info - ISP media bus format information
+ * @code: V4L2 media bus format code
+ * @pixelformat: V4L2 pixel format FCC identifier
+ * @bpp: Bits per pixel when stored in memory
+ */
+static const struct format_info {
+   u32 code;
+   u32 pixelformat;
+   unsigned int bpp;
+} formats[] = {
+   { MEDIA_BUS_FMT_UYVY8_2X8, V4L2_PIX_FMT_UYVY, 16 },
+   { MEDIA_BUS_FMT_VYUY8_2X8, V4L2_PIX_FMT_VYUY, 16 },
+   { MEDIA_BUS_FMT_YUYV8_2X8, V4L2_PIX_FMT_YUYV, 16 },
+   { MEDIA_BUS_FMT_YVYU8_2X8, V4L2_PIX_FMT_YVYU, 16 },
+   { MEDIA_BUS_FMT_SBGGR8_1X8, V4L2_PIX_FMT_SBGGR8, 8 },
+   { MEDIA_BUS_FMT_SGBRG8_1X8, V4L2_PIX_FMT_SGBRG8, 8 },
+   { MEDIA_BUS_FMT_SGRBG8_1X8, V4L2_PIX_FMT_SGRBG8, 8 },
+   { MEDIA_BUS_FMT_SRGGB8_1X8, V4L2_PIX_FMT_SRGGB8, 8 },
+   { MEDIA_BUS_FMT_SBGGR10_1X10, V4L2_PIX_FMT_SBGGR10P, 10 },
+   { MEDIA_BUS_FMT_SGBRG10_1X10, V4L2_PIX_FMT_SGBRG10P, 10 },
+   { MEDIA_BUS_FMT_SGRBG10_1X10, V4L2_PIX_FMT_SGRBG10P, 10 },
+   { MEDIA_BUS_FMT_SRGGB10_1X10, V4L2_PIX_FMT_SRGGB10P, 10 },
+   { MEDIA_BUS_FMT_SBGGR12_1X12, V4L2_PIX_FMT_SRGGB12P, 12 },
+   { MEDIA_BUS_FMT_SGBRG12_1X12, V4L2_PIX_FMT_SGBRG12P, 12 },
+   { MEDIA_BUS_FMT_SGRBG12_1X12, V4L2_PIX_FMT_SGRBG12P, 12 },
+   { MEDIA_BUS_FMT_SRGGB12_1X12, V4L2_PIX_FMT_SRGGB12P, 12 }
+};
+
+/* 
-
+ * Helper functions
+ */
+
+/*
+ * video_mbus_to_pix_mp - Convert v4l2_mbus_framefmt to v4l2_pix_format_mplane
+ * @mbus: v4l2_mbus_framefmt format (input)
+ * @pix: v4l2_pix_format_mplane format (output)
+ *
+ * Fill the output pix structure with information from the input mbus format.
+ *
+ * Return 0 on success or a negative error code otherwise
+ */
+static unsigned int video_mbus_to_pix_mp(const struct v4l2_mbus_framefmt *mbus,
+struct v4l2_pix_format_mplane *pix)
+{
+   unsigned int i;
+   u32 bytesperline;
+
+   memset(pix, 0, sizeof(*pix));
+   pix->width = mbus->width;
+   pix->height = mbus->height;
+
+   for (i = 0; i < ARRAY_SIZE(formats); ++i) {
+   if (formats[i].code == mbus->code)
+   break;
+   }
+
+   if (WARN_ON(i == ARRAY_SIZE(formats)))
+   return -EINVAL;
+
+   pix->pixelformat = formats[i].pixelformat;
+   pix->num_planes = 1;
+   bytesperline = pix->width * formats[i].bpp / 8;
+   bytesperline = ALIGN(bytesperline, 8);
+   pix->plane_fmt[0].bytesperline = bytesperline;
+   pix->plane_fmt[0].sizeimage = bytesperline * pix->height;
+   pix->colorspace = mbus->colorspace;
+   pix->field = mbus->field;
+
+   return 0;
+}


Can you add a v4l2_fill_pix_format_mplane and a v4l2_fill_mbus_format_mplane
static inline to media/v4l2-mediabus.h?

And use v4l2_fill_pix_format_mplane() here?


+
+static struct v4l2_subdev *video_remote_subdev(struct camss_video *video,
+  u32 *pad)
+{
+   struct media_pad *remote;
+
+   remote = media_entity_remote_pad(>pad);
+
+   if (!remote || !is_media_entity_v4l2_subdev(remote->entity))
+   return NULL;
+
+   if (pad)
+   *pad = remote->index;
+
+   return media_entity_to_v4l2_subdev(remote->entity);
+}
+
+static int video_get_subdev_format(struct camss_video *video,
+  struct v4l2_format *format)
+{

Re: [PATCH RFC 1/2] media: V3s: Add support for Allwinner CSI.

[Maxime Ripard]

Hi,

On Mon, Jul 03, 2017 at 06:59:52PM +0800, Yong wrote:
> > > + select VIDEOBUF2_DMA_CONTIG
> > > + select REGMAP_MMIO
> > > + ---help---
> > > +Support for the Allwinner Camera Sensor Interface Controller.
> > 
> > This controller is the same for all Allwinner SoC models?
> 
> No.
> I will change the Kconfig and Makefile.

This is basically a design that has been introduced in the A31 (sun6i
family). I guess we should just call the driver and Kconfig symbols
sun6i_csi (even though we don't support it yet). It also used on the
A23, A33, A80, A83T, H3, and probably the H5 and A64.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH v2 09/19] media: camms: Add core files

[Hans Verkuil]

On 06/19/2017 04:48 PM, Todor Tomov wrote:

These files implement the platform driver code.

Signed-off-by: Todor Tomov 
---
  drivers/media/platform/qcom/camss-8x16/camss.c | 630 +
  drivers/media/platform/qcom/camss-8x16/camss.h |  96 
  2 files changed, 726 insertions(+)
  create mode 100644 drivers/media/platform/qcom/camss-8x16/camss.c
  create mode 100644 drivers/media/platform/qcom/camss-8x16/camss.h

diff --git a/drivers/media/platform/qcom/camss-8x16/camss.c 
b/drivers/media/platform/qcom/camss-8x16/camss.c
new file mode 100644
index 000..a8798d1
--- /dev/null
+++ b/drivers/media/platform/qcom/camss-8x16/camss.c
@@ -0,0 +1,630 @@
+/*
+ * camss.c
+ *
+ * Qualcomm MSM Camera Subsystem - Core
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2015-2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 


v4l2-of.h has been replaced by v4l2-fwnode.h. You need to rebase.

Regards,

Hans

[PATCH v3 2/2] regmap: Avoid namespace collision within macro & tidy up

[Ramesh Shanmugasundaram]

Renamed variable "timeout" to "__timeout" & "pollret" to "__ret" to
avoid namespace collision. Tidy up macro arguments with parentheses.

Signed-off-by: Ramesh Shanmugasundaram 
---
 include/linux/regmap.h | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 978abfbac617..1474ab0a3922 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -120,23 +120,24 @@ struct reg_sequence {
  */
 #define regmap_read_poll_timeout(map, addr, val, cond, sleep_us, timeout_us) \
 ({ \
-   ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
-   int pollret; \
+   ktime_t __timeout = ktime_add_us(ktime_get(), timeout_us); \
+   int __ret; \
might_sleep_if(sleep_us); \
for (;;) { \
-   pollret = regmap_read((map), (addr), &(val)); \
-   if (pollret) \
+   __ret = regmap_read((map), (addr), &(val)); \
+   if (__ret) \
break; \
if (cond) \
break; \
-   if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
-   pollret = regmap_read((map), (addr), &(val)); \
+   if ((timeout_us) && \
+   ktime_compare(ktime_get(), __timeout) > 0) { \
+   __ret = regmap_read((map), (addr), &(val)); \
break; \
} \
if (sleep_us) \
-   usleep_range((sleep_us >> 2) + 1, sleep_us); \
+   usleep_range(((sleep_us) >> 2) + 1, sleep_us); \
} \
-   pollret ?: ((cond) ? 0 : -ETIMEDOUT); \
+   __ret ?: ((cond) ? 0 : -ETIMEDOUT); \
 })
 
 #ifdef CONFIG_REGMAP
-- 
2.12.2

[PATCH v3 0/2] Avoid namespace collision within macros & tidy up

[Ramesh Shanmugasundaram]

Hi Mark,

The readx_poll_timeout & similar macros defines local variable that can
cause name space collision with the caller. Fixed this issue by prefixing
them with underscores. Also tidied couple of instances where the macro
arguments are used in expressions without parentheses.

This patchset is based on top of today's linux-next repo.
commit b18ea5c46031 ("Add linux-next specific files for 20170703")

Change history:

v3:
 - Rebased
 - Corrected parentheses spelling

v2:
 - iopoll.h:
- Enclosed timeout_us & sleep_us arguments with parentheses
 - regmap.h:
- Enclosed timeout_us & sleep_us arguments with parentheses
- Renamed pollret to __ret

Note: timeout_us causes a spare check warning as identified here [1].

[1] https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg15138.html

Thanks,
Ramesh

Ramesh Shanmugasundaram (2):
  iopoll: Avoid namespace collision within macros & tidy up
  regmap: Avoid namespace collision within macro & tidy up

 include/linux/iopoll.h | 12 +++-
 include/linux/regmap.h | 17 +
 2 files changed, 16 insertions(+), 13 deletions(-)

-- 
2.12.2

[PATCH v3 1/2] iopoll: Avoid namespace collision within macros & tidy up

[Ramesh Shanmugasundaram]

Renamed variable "timeout" to "__timeout" to avoid namespace collision.
Tidy up macro arguments with parentheses.

Signed-off-by: Ramesh Shanmugasundaram 
---
 include/linux/iopoll.h | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/include/linux/iopoll.h b/include/linux/iopoll.h
index d29e1e21bf3f..e000172bee54 100644
--- a/include/linux/iopoll.h
+++ b/include/linux/iopoll.h
@@ -42,18 +42,19 @@
  */
 #define readx_poll_timeout(op, addr, val, cond, sleep_us, timeout_us)  \
 ({ \
-   ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
+   ktime_t __timeout = ktime_add_us(ktime_get(), timeout_us); \
might_sleep_if(sleep_us); \
for (;;) { \
(val) = op(addr); \
if (cond) \
break; \
-   if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
+   if ((timeout_us) && \
+   ktime_compare(ktime_get(), __timeout) > 0) { \
(val) = op(addr); \
break; \
} \
if (sleep_us) \
-   usleep_range((sleep_us >> 2) + 1, sleep_us); \
+   usleep_range(((sleep_us) >> 2) + 1, sleep_us); \
} \
(cond) ? 0 : -ETIMEDOUT; \
 })
@@ -77,12 +78,13 @@
  */
 #define readx_poll_timeout_atomic(op, addr, val, cond, delay_us, timeout_us) \
 ({ \
-   ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
+   ktime_t __timeout = ktime_add_us(ktime_get(), timeout_us); \
for (;;) { \
(val) = op(addr); \
if (cond) \
break; \
-   if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
+   if ((timeout_us) && \
+   ktime_compare(ktime_get(), __timeout) > 0) { \
(val) = op(addr); \
break; \
} \
-- 
2.12.2

Re: [PATCH RFC 1/2] media: V3s: Add support for Allwinner CSI.

[Yong]

Hi Hans,

Thanks for your review.

On Mon, 3 Jul 2017 12:18:55 +0200
Hans Verkuil  wrote:

> Hi Yong Deng,
> 
> Thanks for contributing this driver!
> 
> First a high-level comment: you need to rebase this to the latest media_tree
> master branch (https://git.linuxtv.org/media_tree.git/) since v4l2-of.h has
> been replaced by v4l2-fwnode.h. So this driver will not apply as-is.
>
 
OK.

> Also missing is a patch adding a new entry to the MAINTAINERS file.
> 
> I have some more comments below:
> 
> On 06/27/2017 01:07 PM, Yong Deng wrote:
> > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > and CSI1 is used for parallel interface. This is not documented in
> > datatsheet but by testing and guess.
> 
> datatsheet -> datasheet

OK.

> 
> > 
> > This patch implement a v4l2 framework driver for it.
> > 
> > Currently, the driver only support the parallel interface. MIPI-CSI2,
> > ISP's support are not included in this patch.
> > 
> > Signed-off-by: Yong Deng 
> > ---
> >   drivers/media/platform/Kconfig   |   1 +
> >   drivers/media/platform/Makefile  |   2 +
> >   drivers/media/platform/sunxi-csi/Kconfig |   8 +
> >   drivers/media/platform/sunxi-csi/Makefile|   3 +
> >   drivers/media/platform/sunxi-csi/sunxi_csi.c | 535 +++
> >   drivers/media/platform/sunxi-csi/sunxi_csi.h | 203 ++
> >   drivers/media/platform/sunxi-csi/sunxi_csi_v3s.c | 827 
> > +++
> >   drivers/media/platform/sunxi-csi/sunxi_csi_v3s.h | 206 ++
> >   drivers/media/platform/sunxi-csi/sunxi_video.c   | 667 ++
> >   drivers/media/platform/sunxi-csi/sunxi_video.h   |  61 ++
> >   10 files changed, 2513 insertions(+)
> >   create mode 100644 drivers/media/platform/sunxi-csi/Kconfig
> >   create mode 100644 drivers/media/platform/sunxi-csi/Makefile
> >   create mode 100644 drivers/media/platform/sunxi-csi/sunxi_csi.c
> >   create mode 100644 drivers/media/platform/sunxi-csi/sunxi_csi.h
> >   create mode 100644 drivers/media/platform/sunxi-csi/sunxi_csi_v3s.c
> >   create mode 100644 drivers/media/platform/sunxi-csi/sunxi_csi_v3s.h
> >   create mode 100644 drivers/media/platform/sunxi-csi/sunxi_video.c
> >   create mode 100644 drivers/media/platform/sunxi-csi/sunxi_video.h
> 
> 
> 
> > diff --git a/drivers/media/platform/sunxi-csi/Kconfig 
> > b/drivers/media/platform/sunxi-csi/Kconfig
> > new file mode 100644
> > index 000..f26592a
> > --- /dev/null
> > +++ b/drivers/media/platform/sunxi-csi/Kconfig
> > @@ -0,0 +1,8 @@
> > +config VIDEO_SUNXI_CSI
> > +   tristate "Allwinner Camera Sensor Interface driver"
> > +   depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
> > +   depends on ARCH_SUNXI
> 
> If possible change this to:
> 
>   depends on ARCH_SUNXI || COMPILE_TEST

OK.

> 
> to allow this driver to be compiled on e.g. Intel for compile testing.
> 
> > +   select VIDEOBUF2_DMA_CONTIG
> > +   select REGMAP_MMIO
> > +   ---help---
> > +  Support for the Allwinner Camera Sensor Interface Controller.
> 
> This controller is the same for all Allwinner SoC models?

No.
I will change the Kconfig and Makefile.

> 
> 
> 
> > diff --git a/drivers/media/platform/sunxi-csi/sunxi_video.c 
> > b/drivers/media/platform/sunxi-csi/sunxi_video.c
> > new file mode 100644
> > index 000..57d7563
> > --- /dev/null
> > +++ b/drivers/media/platform/sunxi-csi/sunxi_video.c
> > @@ -0,0 +1,667 @@
> > +/*
> > + * Copyright (c) 2017 Magewell Electronics Co., Ltd. (Nanjing).
> > + * All rights reserved.
> > + * Author: Yong Deng 
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "sunxi_csi.h"
> > +#include "sunxi_video.h"
> > +
> > +struct sunxi_csi_buffer {
> > +   struct vb2_v4l2_buffer  vb;
> > +   struct list_headlist;
> > +
> > +   dma_addr_t  dma_addr;
> > +};
> > +
> > +static struct sunxi_csi_format *
> > +find_format_by_fourcc(struct sunxi_video *video, unsigned int fourcc)
> > +{
> > +   unsigned int num_formats = video->num_formats;
> > +   struct sunxi_csi_format *fmt;
> > +   unsigned int i;
> > +
> > +   for (i = 0; i < num_formats; i++) {
> > +   fmt = >formats[i];
> > +   if (fmt->fourcc == fourcc)
> > +   return fmt;
> > +   }
> > +
> > +   return NULL;
> > +}
> > +
> > +static struct 

Re: [PATCH v2 05/19] media: camss: Add CSID files

[Hans Verkuil]

On 06/19/2017 04:48 PM, Todor Tomov wrote:

These files control the CSID modules which handle the protocol and application
layer of the CSI2 receivers.

Signed-off-by: Todor Tomov 
---
  drivers/media/platform/qcom/camss-8x16/csid.c | 1072 +
  drivers/media/platform/qcom/camss-8x16/csid.h |   82 ++
  2 files changed, 1154 insertions(+)
  create mode 100644 drivers/media/platform/qcom/camss-8x16/csid.c
  create mode 100644 drivers/media/platform/qcom/camss-8x16/csid.h

diff --git a/drivers/media/platform/qcom/camss-8x16/csid.c 
b/drivers/media/platform/qcom/camss-8x16/csid.c
new file mode 100644
index 000..c637d78
--- /dev/null
+++ b/drivers/media/platform/qcom/camss-8x16/csid.c
@@ -0,0 +1,1072 @@
+/*
+ * csid.c
+ *
+ * Qualcomm MSM Camera Subsystem - CSID Module
+ *
+ * Copyright (c) 2011-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2015-2016 Linaro Ltd.


2016 -> 2017

This should probably be done elsewhere as well.

Regards,

Hans

Re: [PATCH v5 2/4] [media] platform: Add Synopsys Designware HDMI RX Controller Driver

[Hans Verkuil]

On 07/03/2017 11:53 AM, Jose Abreu wrote:

Hi Hans,


On 03-07-2017 10:27, Hans Verkuil wrote:

On 06/29/2017 12:46 PM, Jose Abreu wrote:

This is an initial submission for the Synopsys Designware HDMI RX
Controller Driver. This driver interacts with a phy driver so
that
a communication between them is created and a video pipeline is
configured.

The controller + phy pipeline can then be integrated into a fully
featured system that can be able to receive video up to 4k@60Hz
with deep color 48bit RGB, depending on the platform. Although,
this initial version does not yet handle deep color modes.

This driver was implemented as a standard V4L2 subdevice and its
main features are:
 - Internal state machine that reconfigures phy until the
 video is not stable
 - JTAG communication with phy
 - Inter-module communication with phy driver
 - Debug write/read ioctls

Some notes:
 - RX sense controller (cable connection/disconnection) must
 be handled by the platform wrapper as this is not integrated
 into the controller RTL
 - The same goes for EDID ROM's
 - ZCAL calibration is needed only in FPGA platforms, in ASIC
 this is not needed
 - The state machine is not an ideal solution as it creates a
 kthread but it is needed because some sources might not be
 very stable at sending the video (i.e. we must react
 accordingly).

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Mauro Carvalho Chehab 
Cc: Hans Verkuil 
Cc: Sylwester Nawrocki 

Changes from v4:
 - Add flag V4L2_SUBDEV_FL_HAS_DEVNODE (Sylwester)
 - Remove some comments and change some messages to dev_dbg
(Sylwester)
 - Use v4l2_async_subnotifier_register() (Sylwester)
Changes from v3:
 - Use v4l2 async API (Sylwester)
 - Do not block waiting for phy
 - Do not use busy waiting delays (Sylwester)
 - Simplify dw_hdmi_power_on (Sylwester)
 - Use clock API (Sylwester)
 - Use compatible string (Sylwester)
 - Minor fixes (Sylwester)
Changes from v2:
 - Address review comments from Hans regarding CEC
 - Use CEC notifier
 - Enable SCDC
Changes from v1:
 - Add support for CEC
 - Correct typo errors
 - Correctly detect interlaced video modes
 - Correct VIC parsing
Changes from RFC:
 - Add support for HDCP 1.4
 - Fixup HDMI_VIC not being parsed (Hans)
 - Send source change signal when powering off (Hans)
 - Add a "wait stable delay"
 - Detect interlaced video modes (Hans)
 - Restrain g/s_register from reading/writing to HDCP regs
(Hans)
---
   drivers/media/platform/dwc/Kconfig  |   15 +
   drivers/media/platform/dwc/Makefile |1 +
   drivers/media/platform/dwc/dw-hdmi-rx.c | 1824
+++
   drivers/media/platform/dwc/dw-hdmi-rx.h |  441 
   include/media/dwc/dw-hdmi-rx-pdata.h|   97 ++
   5 files changed, 2378 insertions(+)
   create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.c
   create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.h
   create mode 100644 include/media/dwc/dw-hdmi-rx-pdata.h

diff --git a/drivers/media/platform/dwc/Kconfig
b/drivers/media/platform/dwc/Kconfig
index 361d38d..3ddccde 100644
--- a/drivers/media/platform/dwc/Kconfig
+++ b/drivers/media/platform/dwc/Kconfig
@@ -6,3 +6,18 @@ config VIDEO_DWC_HDMI_PHY_E405
   To compile this driver as a module, choose M here.
The module
 will be called dw-hdmi-phy-e405.
+
+config VIDEO_DWC_HDMI_RX
+tristate "Synopsys Designware HDMI Receiver driver"
+depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+help
+  Support for Synopsys Designware HDMI RX controller.
+
+  To compile this driver as a module, choose M here. The
module
+  will be called dw-hdmi-rx.
+
+config VIDEO_DWC_HDMI_RX_CEC
+bool
+depends on VIDEO_DWC_HDMI_RX
+select CEC_CORE
+select CEC_NOTIFIER
diff --git a/drivers/media/platform/dwc/Makefile
b/drivers/media/platform/dwc/Makefile
index fc3b62c..cd04ca9 100644
--- a/drivers/media/platform/dwc/Makefile
+++ b/drivers/media/platform/dwc/Makefile
@@ -1 +1,2 @@
   obj-$(CONFIG_VIDEO_DWC_HDMI_PHY_E405) += dw-hdmi-phy-e405.o
+obj-$(CONFIG_VIDEO_DWC_HDMI_RX) += dw-hdmi-rx.o
diff --git a/drivers/media/platform/dwc/dw-hdmi-rx.c
b/drivers/media/platform/dwc/dw-hdmi-rx.c
new file mode 100644
index 000..4a7b8fc
--- /dev/null
+++ b/drivers/media/platform/dwc/dw-hdmi-rx.c






+static int dw_hdmi_g_register(struct v4l2_subdev *sd,
+struct v4l2_dbg_register *reg)
+{
+struct dw_hdmi_dev *dw_dev = to_dw_dev(sd);
+
+switch (reg->reg >> 15) {
+case 0: /* Controller core read */
+if (dw_hdmi_is_reserved_register(dw_dev, reg->reg &
0x7fff))
+return -EINVAL;


Is this necessary? Obviously you shouldn't be able to set it,
but I think it
should be fine to read it. Up to you, though.


Actually some of 

Re: [PATCH RFC 1/2] media: V3s: Add support for Allwinner CSI.

[Hans Verkuil]

Hi Yong Deng,

Thanks for contributing this driver!

First a high-level comment: you need to rebase this to the latest media_tree
master branch (https://git.linuxtv.org/media_tree.git/) since v4l2-of.h has
been replaced by v4l2-fwnode.h. So this driver will not apply as-is.

Also missing is a patch adding a new entry to the MAINTAINERS file.

I have some more comments below:

On 06/27/2017 01:07 PM, Yong Deng wrote:

Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
and CSI1 is used for parallel interface. This is not documented in
datatsheet but by testing and guess.


datatsheet -> datasheet



This patch implement a v4l2 framework driver for it.

Currently, the driver only support the parallel interface. MIPI-CSI2,
ISP's support are not included in this patch.

Signed-off-by: Yong Deng 
---
  drivers/media/platform/Kconfig   |   1 +
  drivers/media/platform/Makefile  |   2 +
  drivers/media/platform/sunxi-csi/Kconfig |   8 +
  drivers/media/platform/sunxi-csi/Makefile|   3 +
  drivers/media/platform/sunxi-csi/sunxi_csi.c | 535 +++
  drivers/media/platform/sunxi-csi/sunxi_csi.h | 203 ++
  drivers/media/platform/sunxi-csi/sunxi_csi_v3s.c | 827 +++
  drivers/media/platform/sunxi-csi/sunxi_csi_v3s.h | 206 ++
  drivers/media/platform/sunxi-csi/sunxi_video.c   | 667 ++
  drivers/media/platform/sunxi-csi/sunxi_video.h   |  61 ++
  10 files changed, 2513 insertions(+)
  create mode 100644 drivers/media/platform/sunxi-csi/Kconfig
  create mode 100644 drivers/media/platform/sunxi-csi/Makefile
  create mode 100644 drivers/media/platform/sunxi-csi/sunxi_csi.c
  create mode 100644 drivers/media/platform/sunxi-csi/sunxi_csi.h
  create mode 100644 drivers/media/platform/sunxi-csi/sunxi_csi_v3s.c
  create mode 100644 drivers/media/platform/sunxi-csi/sunxi_csi_v3s.h
  create mode 100644 drivers/media/platform/sunxi-csi/sunxi_video.c
  create mode 100644 drivers/media/platform/sunxi-csi/sunxi_video.h





diff --git a/drivers/media/platform/sunxi-csi/Kconfig 
b/drivers/media/platform/sunxi-csi/Kconfig
new file mode 100644
index 000..f26592a
--- /dev/null
+++ b/drivers/media/platform/sunxi-csi/Kconfig
@@ -0,0 +1,8 @@
+config VIDEO_SUNXI_CSI
+   tristate "Allwinner Camera Sensor Interface driver"
+   depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
+   depends on ARCH_SUNXI


If possible change this to:

depends on ARCH_SUNXI || COMPILE_TEST

to allow this driver to be compiled on e.g. Intel for compile testing.


+   select VIDEOBUF2_DMA_CONTIG
+   select REGMAP_MMIO
+   ---help---
+  Support for the Allwinner Camera Sensor Interface Controller.


This controller is the same for all Allwinner SoC models?




diff --git a/drivers/media/platform/sunxi-csi/sunxi_video.c 
b/drivers/media/platform/sunxi-csi/sunxi_video.c
new file mode 100644
index 000..57d7563
--- /dev/null
+++ b/drivers/media/platform/sunxi-csi/sunxi_video.c
@@ -0,0 +1,667 @@
+/*
+ * Copyright (c) 2017 Magewell Electronics Co., Ltd. (Nanjing).
+ * All rights reserved.
+ * Author: Yong Deng 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sunxi_csi.h"
+#include "sunxi_video.h"
+
+struct sunxi_csi_buffer {
+   struct vb2_v4l2_buffer  vb;
+   struct list_headlist;
+
+   dma_addr_t  dma_addr;
+};
+
+static struct sunxi_csi_format *
+find_format_by_fourcc(struct sunxi_video *video, unsigned int fourcc)
+{
+   unsigned int num_formats = video->num_formats;
+   struct sunxi_csi_format *fmt;
+   unsigned int i;
+
+   for (i = 0; i < num_formats; i++) {
+   fmt = >formats[i];
+   if (fmt->fourcc == fourcc)
+   return fmt;
+   }
+
+   return NULL;
+}
+
+static struct v4l2_subdev *
+sunxi_video_remote_subdev(struct sunxi_video *video, u32 *pad)
+{
+   struct media_pad *remote;
+
+   remote = media_entity_remote_pad(>pad);
+
+   if (!remote || !is_media_entity_v4l2_subdev(remote->entity))
+   return NULL;
+
+   if (pad)
+   *pad = remote->index;
+
+   return media_entity_to_v4l2_subdev(remote->entity);
+}
+
+static int sunxi_video_queue_setup(struct vb2_queue *vq,
+unsigned int *nbuffers, unsigned int *nplanes,
+

[PATCH] [dtv-scan-tables] Add scan file for EWCom Goms DVB-C

[Bernhard Rosenkränzer]

Add a scan file for EWCom Goms DVB-C

Signed-off-by: Bernhard Rosenkränzer 
---
 dvb-c/ch-Oberwallis-ewcom | 9 +
 1 file changed, 9 insertions(+)
 create mode 100644 dvb-c/ch-Oberwallis-ewcom

diff --git a/dvb-c/ch-Oberwallis-ewcom b/dvb-c/ch-Oberwallis-ewcom
new file mode 100644
index 000..b856e83
--- /dev/null
+++ b/dvb-c/ch-Oberwallis-ewcom
@@ -0,0 +1,9 @@
+# EWCom Goms
+# Network ID 562
+[CHANNEL]
+ DELIVERY_SYSTEM = DVBC/ANNEX_A
+ FREQUENCY = 59400
+ SYMBOL_RATE = 690
+ INNER_FEC = NONE
+ MODULATION = QAM/256
+ INVERSION = AUTO
-- 
2.13.2

[PATCH] Hauppauge HVR-1975 support

[Bernhard Rosenkränzer]

Hi,
Hauppauge HVR-1975 is a USB DVB receiver box,
http://www.hauppauge.co.uk/site/products/data_hvr1900.html

It is currently not supported by v4l; Hauppauge provides a patch for
kernel 3.19 at http://www.hauppauge.com/site/support/linux.html

As expected, the patch doesn't work with more recent kernels, so I've
ported it (verified to work on 4.11.8). Due to the size of the patch,
I've uploaded my patch to
http://lindev.ch/hauppauge-hvr-1975.patch

While it works well, there's a potential license problem in one of the files:
>From drivers/media/dvb-frontend/silg.c:

/* MODULE_LICENSE("Proprietary"); */
/* GPL discussion for silg not finished. Set to GPL for internal usage only. */
/* The module uses GPL functions and is rejected by the kernel build if the */
/* license is set to 'Proprietary'. */
MODULE_LICENSE("GPL");

I'm not a lawyer, but my understanding is that by Hauppauge actually
releasing that file to the public (and it being so clearly a derivate
of GPL code that they even have to acknowledge it), their claim that
it is anything but GPL is null and void - but we may have to make
sure.

ttyl
bero

RE: [PATCH v2 1/2] iopoll: Avoid namespace collision within macros & tidyup

[Ramesh Shanmugasundaram]

Hi Geert,

Thanks for the review. Replying to the thread to update what we discussed in 
IRC sometime back.

> On Tue, Jun 13, 2017 at 3:33 PM, Ramesh Shanmugasundaram
>  wrote:
> > Renamed variable "timeout" to "__timeout" to avoid namespace collision.
> > Tidy up macro arguments with paranthesis.
> >
> > Signed-off-by: Ramesh Shanmugasundaram
> > 
> 
> Thanks for your patches!
> 
> > --- a/include/linux/iopoll.h
> > +++ b/include/linux/iopoll.h
> > @@ -42,18 +42,19 @@
> >   */
> >  #define readx_poll_timeout(op, addr, val, cond, sleep_us, timeout_us)
> > \  ({ \
> > -   ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
> > +   ktime_t __timeout = ktime_add_us(ktime_get(), timeout_us); \
> 
> I think timeout_us should be within parentheses, too.

It is not required as it is passed as an function (ktime_add_us) argument.

> 
> > might_sleep_if(sleep_us); \
> > for (;;) { \
> > (val) = op(addr); \
> > if (cond) \
> > break; \
> > -   if (timeout_us && ktime_compare(ktime_get(), timeout) >
> 0) { \
> > +   if ((timeout_us) && \
> > +   ktime_compare(ktime_get(), __timeout) > 0) { \
> > (val) = op(addr); \
> > break; \
> > } \
> > if (sleep_us) \
> > -   usleep_range((sleep_us >> 2) + 1, sleep_us); \
> > +   usleep_range(((sleep_us) >> 2) + 1, sleep_us);
> > + \
> 
> Same for sleep_us.
> 
> Also in readx_poll_timeout_atomic(), and in your second patch.

Same as the above comment.

Thanks,
Ramesh

Re: [PATCH v5 2/4] [media] platform: Add Synopsys Designware HDMI RX Controller Driver

[Jose Abreu]

Hi Hans,


On 03-07-2017 10:27, Hans Verkuil wrote:
> On 06/29/2017 12:46 PM, Jose Abreu wrote:
>> This is an initial submission for the Synopsys Designware HDMI RX
>> Controller Driver. This driver interacts with a phy driver so
>> that
>> a communication between them is created and a video pipeline is
>> configured.
>>
>> The controller + phy pipeline can then be integrated into a fully
>> featured system that can be able to receive video up to 4k@60Hz
>> with deep color 48bit RGB, depending on the platform. Although,
>> this initial version does not yet handle deep color modes.
>>
>> This driver was implemented as a standard V4L2 subdevice and its
>> main features are:
>> - Internal state machine that reconfigures phy until the
>> video is not stable
>> - JTAG communication with phy
>> - Inter-module communication with phy driver
>> - Debug write/read ioctls
>>
>> Some notes:
>> - RX sense controller (cable connection/disconnection) must
>> be handled by the platform wrapper as this is not integrated
>> into the controller RTL
>> - The same goes for EDID ROM's
>> - ZCAL calibration is needed only in FPGA platforms, in ASIC
>> this is not needed
>> - The state machine is not an ideal solution as it creates a
>> kthread but it is needed because some sources might not be
>> very stable at sending the video (i.e. we must react
>> accordingly).
>>
>> Signed-off-by: Jose Abreu 
>> Cc: Carlos Palminha 
>> Cc: Mauro Carvalho Chehab 
>> Cc: Hans Verkuil 
>> Cc: Sylwester Nawrocki 
>>
>> Changes from v4:
>> - Add flag V4L2_SUBDEV_FL_HAS_DEVNODE (Sylwester)
>> - Remove some comments and change some messages to dev_dbg
>> (Sylwester)
>> - Use v4l2_async_subnotifier_register() (Sylwester)
>> Changes from v3:
>> - Use v4l2 async API (Sylwester)
>> - Do not block waiting for phy
>> - Do not use busy waiting delays (Sylwester)
>> - Simplify dw_hdmi_power_on (Sylwester)
>> - Use clock API (Sylwester)
>> - Use compatible string (Sylwester)
>> - Minor fixes (Sylwester)
>> Changes from v2:
>> - Address review comments from Hans regarding CEC
>> - Use CEC notifier
>> - Enable SCDC
>> Changes from v1:
>> - Add support for CEC
>> - Correct typo errors
>> - Correctly detect interlaced video modes
>> - Correct VIC parsing
>> Changes from RFC:
>> - Add support for HDCP 1.4
>> - Fixup HDMI_VIC not being parsed (Hans)
>> - Send source change signal when powering off (Hans)
>> - Add a "wait stable delay"
>> - Detect interlaced video modes (Hans)
>> - Restrain g/s_register from reading/writing to HDCP regs
>> (Hans)
>> ---
>>   drivers/media/platform/dwc/Kconfig  |   15 +
>>   drivers/media/platform/dwc/Makefile |1 +
>>   drivers/media/platform/dwc/dw-hdmi-rx.c | 1824
>> +++
>>   drivers/media/platform/dwc/dw-hdmi-rx.h |  441 
>>   include/media/dwc/dw-hdmi-rx-pdata.h|   97 ++
>>   5 files changed, 2378 insertions(+)
>>   create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.c
>>   create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.h
>>   create mode 100644 include/media/dwc/dw-hdmi-rx-pdata.h
>>
>> diff --git a/drivers/media/platform/dwc/Kconfig
>> b/drivers/media/platform/dwc/Kconfig
>> index 361d38d..3ddccde 100644
>> --- a/drivers/media/platform/dwc/Kconfig
>> +++ b/drivers/media/platform/dwc/Kconfig
>> @@ -6,3 +6,18 @@ config VIDEO_DWC_HDMI_PHY_E405
>>   To compile this driver as a module, choose M here.
>> The module
>> will be called dw-hdmi-phy-e405.
>> +
>> +config VIDEO_DWC_HDMI_RX
>> +tristate "Synopsys Designware HDMI Receiver driver"
>> +depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
>> +help
>> +  Support for Synopsys Designware HDMI RX controller.
>> +
>> +  To compile this driver as a module, choose M here. The
>> module
>> +  will be called dw-hdmi-rx.
>> +
>> +config VIDEO_DWC_HDMI_RX_CEC
>> +bool
>> +depends on VIDEO_DWC_HDMI_RX
>> +select CEC_CORE
>> +select CEC_NOTIFIER
>> diff --git a/drivers/media/platform/dwc/Makefile
>> b/drivers/media/platform/dwc/Makefile
>> index fc3b62c..cd04ca9 100644
>> --- a/drivers/media/platform/dwc/Makefile
>> +++ b/drivers/media/platform/dwc/Makefile
>> @@ -1 +1,2 @@
>>   obj-$(CONFIG_VIDEO_DWC_HDMI_PHY_E405) += dw-hdmi-phy-e405.o
>> +obj-$(CONFIG_VIDEO_DWC_HDMI_RX) += dw-hdmi-rx.o
>> diff --git a/drivers/media/platform/dwc/dw-hdmi-rx.c
>> b/drivers/media/platform/dwc/dw-hdmi-rx.c
>> new file mode 100644
>> index 000..4a7b8fc
>> --- /dev/null
>> +++ b/drivers/media/platform/dwc/dw-hdmi-rx.c
>
> 
>
>> +static void dw_hdmi_cec_tx_raw_status(struct dw_hdmi_dev
>> *dw_dev, u32 stat)
>> +{
>> +if (hdmi_readl(dw_dev, HDMI_CEC_CTRL) &
>> HDMI_CEC_CTRL_SEND_MASK) {
>> +dev_dbg(dw_dev->dev, "%s: tx 

Re: [PATCH] [media] rc-core: do not depend on MEDIA_SUPPORT

[Hans Verkuil]

On 07/02/2017 09:37 PM, Sean Young wrote:

There is no dependency between the two, so remove the dependency in
Kconfig files.

Signed-off-by: Sean Young 


Acked-by: Hans Verkuil 

It might be nice to go through the 'depends on RC_CORE' Kconfig lines and
see if they can be changed to:

depends on INPUT
select RC_CORE

Regards,

Hans


---
  arch/arm/configs/imx_v6_v7_defconfig  |  2 +-
  arch/arm/configs/omap2plus_defconfig  |  2 +-
  arch/arm/configs/sunxi_defconfig  |  2 +-
  arch/mips/configs/pistachio_defconfig |  4 ++--
  drivers/media/Kconfig | 17 ++---
  drivers/media/rc/Kconfig  | 19 ---
  6 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig 
b/arch/arm/configs/imx_v6_v7_defconfig
index bb6fa56..2392824 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -222,7 +222,7 @@ CONFIG_REGULATOR_MC13892=y
  CONFIG_REGULATOR_PFUZE100=y
  CONFIG_MEDIA_SUPPORT=y
  CONFIG_MEDIA_CAMERA_SUPPORT=y
-CONFIG_MEDIA_RC_SUPPORT=y
+CONFIG_RC_CORE=y
  CONFIG_RC_DEVICES=y
  CONFIG_IR_GPIO_CIR=y
  CONFIG_MEDIA_USB_SUPPORT=y
diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index a120ae8..0414acf 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -304,7 +304,7 @@ CONFIG_REGULATOR_TPS65910=y
  CONFIG_REGULATOR_TWL4030=y
  CONFIG_MEDIA_SUPPORT=m
  CONFIG_MEDIA_CAMERA_SUPPORT=y
-CONFIG_MEDIA_RC_SUPPORT=y
+CONFIG_RC_CORE=m
  CONFIG_MEDIA_CONTROLLER=y
  CONFIG_VIDEO_V4L2_SUBDEV_API=y
  CONFIG_LIRC=m
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 5cd5dd70..6a0920c 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -96,7 +96,7 @@ CONFIG_REGULATOR_FIXED_VOLTAGE=y
  CONFIG_REGULATOR_AXP20X=y
  CONFIG_REGULATOR_GPIO=y
  CONFIG_MEDIA_SUPPORT=y
-CONFIG_MEDIA_RC_SUPPORT=y
+CONFIG_RC_CORE=y
  CONFIG_RC_DEVICES=y
  CONFIG_IR_SUNXI=y
  CONFIG_DRM=y
diff --git a/arch/mips/configs/pistachio_defconfig 
b/arch/mips/configs/pistachio_defconfig
index 7d32fbb..f4c57d1 100644
--- a/arch/mips/configs/pistachio_defconfig
+++ b/arch/mips/configs/pistachio_defconfig
@@ -11,7 +11,7 @@ CONFIG_DEFAULT_HOSTNAME="localhost"
  CONFIG_SYSVIPC=y
  CONFIG_NO_HZ=y
  CONFIG_HIGH_RES_TIMERS=y
-CONFIG_IKCONFIG=m
+CONFIG_IKCONFIGRC_CORE=m
  CONFIG_IKCONFIG_PROC=y
  CONFIG_LOG_BUF_SHIFT=18
  CONFIG_CGROUPS=y
@@ -207,7 +207,7 @@ CONFIG_IMGPDC_WDT=y
  CONFIG_REGULATOR_FIXED_VOLTAGE=y
  CONFIG_REGULATOR_GPIO=y
  CONFIG_MEDIA_SUPPORT=y
-CONFIG_MEDIA_RC_SUPPORT=y
+CONFIG_RC_CORE=y
  # CONFIG_RC_DECODERS is not set
  CONFIG_RC_DEVICES=y
  CONFIG_IR_IMG=y
diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 55d9c2b..421999b 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -8,6 +8,8 @@ config CEC_CORE
  config CEC_NOTIFIER
bool
  
+source "drivers/media/rc/Kconfig"

+
  menuconfig MEDIA_SUPPORT
tristate "Multimedia support"
depends on HAS_IOMEM
@@ -72,20 +74,6 @@ config MEDIA_SDR_SUPPORT
  
  	  Say Y when you have a software defined radio device.
  
-config MEDIA_RC_SUPPORT

-   bool "Remote Controller support"
-   depends on INPUT
-   ---help---
- Enable support for Remote Controllers on Linux. This is
- needed in order to support several video capture adapters,
- standalone IR receivers/transmitters, and RF receivers.
-
- Enable this option if you have a video capture board even
- if you don't need IR, as otherwise, you may not be able to
- compile the driver for your adapter.
-
- Say Y when you have a TV or an IR device.
-
  config MEDIA_CEC_SUPPORT
 bool "HDMI CEC support"
 ---help---
@@ -175,7 +163,6 @@ config TTPCI_EEPROM
  source "drivers/media/dvb-core/Kconfig"
  
  comment "Media drivers"

-source "drivers/media/rc/Kconfig"
  
  #

  # V4L platform/mem2mem drivers
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index c5338e3..bca77f0 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -1,9 +1,20 @@
-config RC_CORE
-   tristate
-   depends on MEDIA_RC_SUPPORT
+
+menuconfig RC_CORE
+   tristate "Remote Controller support"
depends on INPUT
default y
+   ---help---
+ Enable support for Remote Controllers on Linux. This is
+ needed in order to support several video capture adapters,
+ standalone IR receivers/transmitters, and RF receivers.
+
+ Enable this option if you have a video capture board even
+ if you don't need IR, as otherwise, you may not be able to
+ compile the driver for your adapter.
  
+	  Say Y when you have a TV or an IR device.

+
+if RC_CORE
  source "drivers/media/rc/keymaps/Kconfig"
  
  menuconfig RC_DECODERS

@@ -459,3 +470,5 @@ config 

[PATCH] [media] uvcvideo: fix spelling mistake: "entites" -> "entities"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in uvc_printk message

Signed-off-by: Colin Ian King 
---
 drivers/media/usb/uvc/uvc_driver.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/uvc/uvc_driver.c 
b/drivers/media/usb/uvc/uvc_driver.c
index 70842c5af05b..9901025c4605 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -1995,7 +1995,7 @@ static int uvc_register_chains(struct uvc_device *dev)
 #ifdef CONFIG_MEDIA_CONTROLLER
ret = uvc_mc_register_entities(chain);
if (ret < 0) {
-   uvc_printk(KERN_INFO, "Failed to register entites "
+   uvc_printk(KERN_INFO, "Failed to register entities "
"(%d).\n", ret);
}
 #endif
-- 
2.11.0

Re: [PATCH v3 0/2] [media] videobuf2-dc: Add support for cacheable MMAP

[Marek Szyprowski]

Hi All,

On 2016-10-26 10:52, Thierry Escande wrote:

This series adds support for cacheable MMAP in DMA coherent allocator.

The first patch moves the vb2_dc_get_base_sgt() function above mmap
callbacks for calls introduced by the second patch. This avoids a
forward declaration.


I'm sorry for late review. Sylwester kicked me for pending v4l2/vb2 patches
and I've just found this thread in my TODO folder.

The main question here if we want to merge incomplete solution or not. As
for now, there is no support in ARM/ARM64 for NON_CONSISTENT attribute.
Also none of the v4l2 drivers use it. Sadly support for NON_CONSISTENT
attribute is not fully implemented nor even defined in mainline.

I know that it works fine for some vendor kernel trees, but supporting it in
mainline was a bit controversial. There is no proper way to sync cache 
for such

buffers. Calling dma_sync_sg worked so far, but it has to be first agreed as
a proper DMA API.


Changes in v2:
- Put function move in a separate patch
- Added comments

Changes in v3:
- Remove redundant test on NO_KERNEL_MAPPING DMA attribute in mmap()

Heng-Ruey Hsu (1):
   [media] videobuf2-dc: Support cacheable MMAP

Thierry Escande (1):
   [media] videobuf2-dc: Move vb2_dc_get_base_sgt() above mmap callbacks

  drivers/media/v4l2-core/videobuf2-dma-contig.c | 60 --
  1 file changed, 38 insertions(+), 22 deletions(-)



Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH v5 2/4] [media] platform: Add Synopsys Designware HDMI RX Controller Driver

[Hans Verkuil]

On 06/29/2017 12:46 PM, Jose Abreu wrote:

This is an initial submission for the Synopsys Designware HDMI RX
Controller Driver. This driver interacts with a phy driver so that
a communication between them is created and a video pipeline is
configured.

The controller + phy pipeline can then be integrated into a fully
featured system that can be able to receive video up to 4k@60Hz
with deep color 48bit RGB, depending on the platform. Although,
this initial version does not yet handle deep color modes.

This driver was implemented as a standard V4L2 subdevice and its
main features are:
- Internal state machine that reconfigures phy until the
video is not stable
- JTAG communication with phy
- Inter-module communication with phy driver
- Debug write/read ioctls

Some notes:
- RX sense controller (cable connection/disconnection) must
be handled by the platform wrapper as this is not integrated
into the controller RTL
- The same goes for EDID ROM's
- ZCAL calibration is needed only in FPGA platforms, in ASIC
this is not needed
- The state machine is not an ideal solution as it creates a
kthread but it is needed because some sources might not be
very stable at sending the video (i.e. we must react
accordingly).

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Mauro Carvalho Chehab 
Cc: Hans Verkuil 
Cc: Sylwester Nawrocki 

Changes from v4:
- Add flag V4L2_SUBDEV_FL_HAS_DEVNODE (Sylwester)
- Remove some comments and change some messages to dev_dbg (Sylwester)
- Use v4l2_async_subnotifier_register() (Sylwester)
Changes from v3:
- Use v4l2 async API (Sylwester)
- Do not block waiting for phy
- Do not use busy waiting delays (Sylwester)
- Simplify dw_hdmi_power_on (Sylwester)
- Use clock API (Sylwester)
- Use compatible string (Sylwester)
- Minor fixes (Sylwester)
Changes from v2:
- Address review comments from Hans regarding CEC
- Use CEC notifier
- Enable SCDC
Changes from v1:
- Add support for CEC
- Correct typo errors
- Correctly detect interlaced video modes
- Correct VIC parsing
Changes from RFC:
- Add support for HDCP 1.4
- Fixup HDMI_VIC not being parsed (Hans)
- Send source change signal when powering off (Hans)
- Add a "wait stable delay"
- Detect interlaced video modes (Hans)
- Restrain g/s_register from reading/writing to HDCP regs (Hans)
---
  drivers/media/platform/dwc/Kconfig  |   15 +
  drivers/media/platform/dwc/Makefile |1 +
  drivers/media/platform/dwc/dw-hdmi-rx.c | 1824 +++
  drivers/media/platform/dwc/dw-hdmi-rx.h |  441 
  include/media/dwc/dw-hdmi-rx-pdata.h|   97 ++
  5 files changed, 2378 insertions(+)
  create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.c
  create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.h
  create mode 100644 include/media/dwc/dw-hdmi-rx-pdata.h

diff --git a/drivers/media/platform/dwc/Kconfig 
b/drivers/media/platform/dwc/Kconfig
index 361d38d..3ddccde 100644
--- a/drivers/media/platform/dwc/Kconfig
+++ b/drivers/media/platform/dwc/Kconfig
@@ -6,3 +6,18 @@ config VIDEO_DWC_HDMI_PHY_E405
  
  	  To compile this driver as a module, choose M here. The module

  will be called dw-hdmi-phy-e405.
+
+config VIDEO_DWC_HDMI_RX
+   tristate "Synopsys Designware HDMI Receiver driver"
+   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   help
+ Support for Synopsys Designware HDMI RX controller.
+
+ To compile this driver as a module, choose M here. The module
+ will be called dw-hdmi-rx.
+
+config VIDEO_DWC_HDMI_RX_CEC
+   bool
+   depends on VIDEO_DWC_HDMI_RX
+   select CEC_CORE
+   select CEC_NOTIFIER
diff --git a/drivers/media/platform/dwc/Makefile 
b/drivers/media/platform/dwc/Makefile
index fc3b62c..cd04ca9 100644
--- a/drivers/media/platform/dwc/Makefile
+++ b/drivers/media/platform/dwc/Makefile
@@ -1 +1,2 @@
  obj-$(CONFIG_VIDEO_DWC_HDMI_PHY_E405) += dw-hdmi-phy-e405.o
+obj-$(CONFIG_VIDEO_DWC_HDMI_RX) += dw-hdmi-rx.o
diff --git a/drivers/media/platform/dwc/dw-hdmi-rx.c 
b/drivers/media/platform/dwc/dw-hdmi-rx.c
new file mode 100644
index 000..4a7b8fc
--- /dev/null
+++ b/drivers/media/platform/dwc/dw-hdmi-rx.c





+static void dw_hdmi_cec_tx_raw_status(struct dw_hdmi_dev *dw_dev, u32 stat)
+{
+   if (hdmi_readl(dw_dev, HDMI_CEC_CTRL) & HDMI_CEC_CTRL_SEND_MASK) {
+   dev_dbg(dw_dev->dev, "%s: tx is busy\n", __func__);
+   return;
+   }
+
+   if (stat & HDMI_AUD_CEC_ISTS_ARBLST) {
+   dev_dbg(dw_dev->dev, "%s: arbitration lost\n", __func__);
+   

[PATCH] [media] media/i2c/saa717x: fix spelling mistake: "implementd" -> "implemented"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in v4l2_dbg debug message

Signed-off-by: Colin Ian King 
---
 drivers/media/i2c/saa717x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/saa717x.c b/drivers/media/i2c/saa717x.c
index e1f6bc219c64..102467e00fb3 100644
--- a/drivers/media/i2c/saa717x.c
+++ b/drivers/media/i2c/saa717x.c
@@ -1069,7 +1069,7 @@ static int saa717x_s_std(struct v4l2_subdev *sd, 
v4l2_std_id std)
struct saa717x_state *decoder = to_state(sd);
 
v4l2_dbg(1, debug, sd, "decoder set norm ");
-   v4l2_dbg(1, debug, sd, "(not yet implementd)\n");
+   v4l2_dbg(1, debug, sd, "(not yet implemented)\n");
 
decoder->radio = 0;
decoder->std = std;
-- 
2.11.0

[PATCH v2 2/7] [media] ov9650: switch i2c device id to lower case

[Hugues Fruchet]

Switch i2c device id to lower case as it is
done for other omnivision cameras.

Signed-off-by: Hugues Fruchet 
---
 drivers/media/i2c/ov9650.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
index 2de2fbb..1e4e99e 100644
--- a/drivers/media/i2c/ov9650.c
+++ b/drivers/media/i2c/ov9650.c
@@ -1545,8 +1545,8 @@ static int ov965x_remove(struct i2c_client *client)
 }
 
 static const struct i2c_device_id ov965x_id[] = {
-   { "OV9650", 0 },
-   { "OV9652", 0 },
+   { "ov9650", 0 },
+   { "ov9652", 0 },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(i2c, ov965x_id);
-- 
1.9.1

[PATCH v2 1/7] DT bindings: add bindings for ov965x camera module

[Hugues Fruchet]

From: "H. Nikolaus Schaller" 

This adds documentation of device tree bindings
for the OV965X family camera sensor module.

Signed-off-by: H. Nikolaus Schaller 
Signed-off-by: Hugues Fruchet 
---
 .../devicetree/bindings/media/i2c/ov965x.txt   | 45 ++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov965x.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt 
b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
new file mode 100644
index 000..4ceb727
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
@@ -0,0 +1,45 @@
+* Omnivision OV9650/9652/9655 CMOS sensor
+
+The Omnivision OV965x sensor support multiple resolutions output, such as
+CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
+output format.
+
+Required Properties:
+- compatible: should be one of
+   "ovti,ov9650"
+   "ovti,ov9652"
+   "ovti,ov9655"
+- clocks: reference to the mclk input clock.
+
+Optional Properties:
+- resetb-gpios: reference to the GPIO connected to the RESETB pin, if any,
+   polarity is active low.
+- pwdn-gpios: reference to the GPIO connected to the PWDN pin, if any,
+   polarity is active high.
+- avdd-supply: reference to the analog power supply regulator connected
+   to the AVDD pin, if any.
+- dvdd-supply: reference to the digital power supply regulator connected
+   to the DVDD pin, if any.
+- dovdd-supply: reference to the digital I/O power supply regulator
+   connected to the DOVDD pin, if any.
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ {
+   ov9655: camera@30 {
+   compatible = "ovti,ov9655";
+   reg = <0x30>;
+   pwdn-gpios = < 13 GPIO_ACTIVE_HIGH>;
+   clocks = <_ext_camera>;
+
+   port {
+   ov9655: endpoint {
+   remote-endpoint = <_0>;
+   };
+   };
+   };
+};
-- 
1.9.1

[PATCH v2 7/7] [media] ov9650: add analog power supply and clock gating

[Hugues Fruchet]

Add optional analog power supply and clock gating.

Signed-off-by: H. Nikolaus Schaller 
Signed-off-by: Hugues Fruchet 
---
 drivers/media/i2c/ov9650.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
index 9ff0782..56b1eb3 100644
--- a/drivers/media/i2c/ov9650.c
+++ b/drivers/media/i2c/ov9650.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -374,6 +375,7 @@ struct ov965x {
/* External master clock frequency */
unsigned long mclk_frequency;
struct clk *clk;
+   struct regulator *avdd;
 
/* Protects the struct fields below */
struct mutex lock;
@@ -943,13 +945,31 @@ static void ov965x_gpio_set(struct gpio_desc *gpio, int 
val)
 
 static void __ov965x_set_power(struct ov965x *ov965x, int on)
 {
+   int ret;
+
if (on) {
+   /* Bring up the power supply */
+   ret = regulator_enable(ov965x->avdd);
+   if (ret)
+   dev_warn(>client->dev,
+"Failed to enable analog power (%d)\n", ret);
+   msleep(25);
+   /* Enable clock */
+   ret = clk_prepare_enable(ov965x->clk);
+   if (ret)
+   dev_warn(>client->dev,
+"Failed to enable clock (%d)\n", ret);
+   msleep(25);
+
ov965x_gpio_set(ov965x->gpios[GPIO_PWDN], 0);
ov965x_gpio_set(ov965x->gpios[GPIO_RST], 0);
msleep(25);
} else {
ov965x_gpio_set(ov965x->gpios[GPIO_RST], 1);
ov965x_gpio_set(ov965x->gpios[GPIO_PWDN], 1);
+
+   clk_disable_unprepare(ov965x->clk);
+   regulator_disable(ov965x->avdd);
}
 
ov965x->streaming = 0;
@@ -1969,6 +1989,12 @@ static int ov965x_probe(struct i2c_client *client,
devm_gpiod_get_optional(>dev, "pwdn",
GPIOD_OUT_HIGH);
 
+   ov965x->avdd = devm_regulator_get(>dev, "avdd");
+   if (IS_ERR(ov965x->avdd)) {
+   dev_err(>dev, "Could not get analog 
regulator\n");
+   return PTR_ERR(ov965x->avdd);
+   }
+
ov965x->clk = devm_clk_get(>dev, NULL);
if (IS_ERR(ov965x->clk)) {
dev_err(>dev, "Could not get clock\n");
-- 
1.9.1

[PATCH v2 0/7] [PATCH v2 0/7] Add support of OV9655 camera

[Hugues Fruchet]

This patchset enables OV9655 camera support.

OV9655 support has been tested using STM32F4DIS-CAM extension board
plugged on connector P1 of STM32F746G-DISCO board.
Due to lack of OV9650/52 hardware support, the modified related code
could not have been checked for non-regression.

First patches upgrade current support of OV9650/52 to prepare then
introduction of OV9655 variant patch.
Because of OV9655 register set slightly different from OV9650/9652,
not all of the driver features are supported (controls). Supported
resolutions are limited to VGA, QVGA, QQVGA.
Supported format is limited to RGB565.
Controls are limited to color bar test pattern for test purpose.

OV9655 initial support is based on a driver written by H. Nikolaus Schaller [1].
OV9655 registers sequences come from STM32CubeF7 embedded software [2].

[1] 
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/video/ov9655
[2] 
https://developer.mbed.org/teams/ST/code/BSP_DISCO_F746NG/file/e1d9da7fe856/Drivers/BSP/Components/ov9655/ov9655.c

===
= history =
===
version 2:
  - Remove some unneeded semicolons (kbuild test robot):
  http://www.mail-archive.com/linux-media@vger.kernel.org/msg114616.html
  - Remove patch [media] ov9650: select the nearest higher resolution:
it is up to the application to find the best matching resolution
using ENUM_FRAMESIZES/S_FMT/S_SELECTION (S_CROP), see
  http://www.mail-archive.com/linux-media@vger.kernel.org/msg114667.html
  - dt-bindings: Fix remarks from Rob Herring about polarity:
  http://www.mail-archive.com/linux-media@vger.kernel.org/msg114705.html
  - dt-bindings: Add optional regulators avdd, dvdd, dovdd:
  http://www.mail-archive.com/linux-media@vger.kernel.org/msg114785.html
  - fix missing semicolons in if condition:
  http://www.mail-archive.com/linux-media@vger.kernel.org/msg114611.html
  - move ov965x_pixfmt relocation in right patch:
  http://www.mail-archive.com/linux-media@vger.kernel.org/msg114849.html
  - revisit OV965x renaming to ov965x for device id names and DT compatible 
strings,
drop of_device_id .data device identification
  http://www.mail-archive.com/linux-media@vger.kernel.org/msg114635.html
  http://www.mail-archive.com/linux-media@vger.kernel.org/msg114738.html
  - Add analog power supply and clock gating, needed for GTA04 platform:
  http://www.mail-archive.com/linux-media@vger.kernel.org/msg114519.html

version 1:
  - Initial submission.

H. Nikolaus Schaller (1):
  DT bindings: add bindings for ov965x camera module

Hugues Fruchet (6):
  [media] ov9650: switch i2c device id to lower case
  [media] ov9650: add device tree support
  [media] ov9650: use write_array() for resolution sequences
  [media] ov9650: add multiple variant support
  [media] ov9650: add support of OV9655 variant
  [media] ov9650: add analog power supply and clock gating

 .../devicetree/bindings/media/i2c/ov965x.txt   |  45 ++
 drivers/media/i2c/Kconfig  |   6 +-
 drivers/media/i2c/ov9650.c | 816 +
 3 files changed, 736 insertions(+), 131 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov965x.txt

-- 
1.9.1

[PATCH v2 4/7] [media] ov9650: use write_array() for resolution sequences

[Hugues Fruchet]

Align resolution sequences on initialization sequence using
i2c_rv structure NULL terminated .This add flexibility
on resolution sequence size.
Document resolution related registers by using corresponding
define instead of hexa address/value.

Signed-off-by: Hugues Fruchet 
---
 drivers/media/i2c/ov9650.c | 88 +++---
 1 file changed, 59 insertions(+), 29 deletions(-)

diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
index 7e9a902..db96698 100644
--- a/drivers/media/i2c/ov9650.c
+++ b/drivers/media/i2c/ov9650.c
@@ -227,11 +227,16 @@ struct ov965x_ctrls {
u8 update;
 };
 
+struct i2c_rv {
+   u8 addr;
+   u8 value;
+};
+
 struct ov965x_framesize {
u16 width;
u16 height;
u16 max_exp_lines;
-   const u8 *regs;
+   const struct i2c_rv *regs;
 };
 
 struct ov965x_interval {
@@ -280,11 +285,6 @@ struct ov965x {
u8 apply_frame_fmt;
 };
 
-struct i2c_rv {
-   u8 addr;
-   u8 value;
-};
-
 static const struct i2c_rv ov965x_init_regs[] = {
{ REG_COM2, 0x10 }, /* Set soft sleep mode */
{ REG_COM5, 0x00 }, /* System clock options */
@@ -342,30 +342,59 @@ struct i2c_rv {
{ REG_NULL, 0 }
 };
 
-#define NUM_FMT_REGS 14
-/*
- * COM7,  COM3,  COM4, HSTART, HSTOP, HREF, VSTART, VSTOP, VREF,
- * EXHCH, EXHCL, ADC,  OCOM,   OFON
- */
-static const u8 frame_size_reg_addr[NUM_FMT_REGS] = {
-   0x12, 0x0c, 0x0d, 0x17, 0x18, 0x32, 0x19, 0x1a, 0x03,
-   0x2a, 0x2b, 0x37, 0x38, 0x39,
-};
-
-static const u8 ov965x_sxga_regs[NUM_FMT_REGS] = {
-   0x00, 0x00, 0x00, 0x1e, 0xbe, 0xbf, 0x01, 0x81, 0x12,
-   0x10, 0x34, 0x81, 0x93, 0x51,
+static const struct i2c_rv ov965x_sxga_regs[] = {
+   { REG_COM7, 0x00 },
+   { REG_COM3, 0x00 },
+   { REG_COM4, 0x00 },
+   { REG_HSTART, 0x1e },
+   { REG_HSTOP, 0xbe },
+   { 0x32, 0xbf },
+   { REG_VSTART, 0x01 },
+   { REG_VSTOP, 0x81 },
+   { REG_VREF, 0x12 },
+   { REG_EXHCH, 0x10 },
+   { REG_EXHCL, 0x34 },
+   { REG_ADC, 0x81 },
+   { REG_ACOM, 0x93 },
+   { REG_OFON, 0x51 },
+   { REG_NULL, 0 },
 };
 
-static const u8 ov965x_vga_regs[NUM_FMT_REGS] = {
-   0x40, 0x04, 0x80, 0x26, 0xc6, 0xed, 0x01, 0x3d, 0x00,
-   0x10, 0x40, 0x91, 0x12, 0x43,
+static const struct i2c_rv ov965x_vga_regs[] = {
+   { REG_COM7, 0x40 },
+   { REG_COM3, 0x04 },
+   { REG_COM4, 0x80 },
+   { REG_HSTART, 0x26 },
+   { REG_HSTOP, 0xc6 },
+   { 0x32, 0xed },
+   { REG_VSTART, 0x01 },
+   { REG_VSTOP, 0x3d },
+   { REG_VREF, 0x00 },
+   { REG_EXHCH, 0x10 },
+   { REG_EXHCL, 0x40 },
+   { REG_ADC, 0x91 },
+   { REG_ACOM, 0x12 },
+   { REG_OFON, 0x43 },
+   { REG_NULL, 0 },
 };
 
 /* Determined empirically. */
-static const u8 ov965x_qvga_regs[NUM_FMT_REGS] = {
-   0x10, 0x04, 0x80, 0x25, 0xc5, 0xbf, 0x00, 0x80, 0x12,
-   0x10, 0x40, 0x91, 0x12, 0x43,
+static const struct i2c_rv ov965x_qvga_regs[] = {
+   { REG_COM7, 0x10 },
+   { REG_COM3, 0x04 },
+   { REG_COM4, 0x80 },
+   { REG_HSTART, 0x25 },
+   { REG_HSTOP, 0xc5 },
+   { 0x32, 0xbf },
+   { REG_VSTART, 0x00 },
+   { REG_VSTOP, 0x80 },
+   { REG_VREF, 0x12 },
+   { REG_EXHCH, 0x10 },
+   { REG_EXHCL, 0x40 },
+   { REG_ADC, 0x91 },
+   { REG_ACOM, 0x12 },
+   { REG_OFON, 0x43 },
+   { REG_NULL, 0 },
 };
 
 static const struct ov965x_framesize ov965x_framesizes[] = {
@@ -1266,11 +1295,12 @@ static int ov965x_set_fmt(struct v4l2_subdev *sd, 
struct v4l2_subdev_pad_config
 
 static int ov965x_set_frame_size(struct ov965x *ov965x)
 {
-   int i, ret = 0;
+   int ret = 0;
+
+   v4l2_dbg(1, debug, ov965x->client, "%s\n", __func__);
 
-   for (i = 0; ret == 0 && i < NUM_FMT_REGS; i++)
-   ret = ov965x_write(ov965x->client, frame_size_reg_addr[i],
-  ov965x->frame_size->regs[i]);
+   ret = ov965x_write_array(ov965x->client,
+ov965x->frame_size->regs);
return ret;
 }
 
-- 
1.9.1

[PATCH v2 3/7] [media] ov9650: add device tree support

[Hugues Fruchet]

Allows use of device tree configuration data.
If no device tree data is there, configuration is taken from platform data.
In order to keep GPIOs configuration compatible between both way of doing,
GPIOs are switched to descriptor-based interface.

Signed-off-by: H. Nikolaus Schaller 
Signed-off-by: Hugues Fruchet 
---
 drivers/media/i2c/Kconfig  |  2 +-
 drivers/media/i2c/ov9650.c | 77 ++
 2 files changed, 59 insertions(+), 20 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 121b3b5..168115c 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -615,7 +615,7 @@ config VIDEO_OV7670
 
 config VIDEO_OV9650
tristate "OmniVision OV9650/OV9652 sensor support"
-   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on GPIOLIB && I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
---help---
  This is a V4L2 sensor-level driver for the Omnivision
  OV9650 and OV9652 camera sensors.
diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
index 1e4e99e..7e9a902 100644
--- a/drivers/media/i2c/ov9650.c
+++ b/drivers/media/i2c/ov9650.c
@@ -11,12 +11,14 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -249,9 +251,10 @@ struct ov965x {
struct v4l2_subdev sd;
struct media_pad pad;
enum v4l2_mbus_type bus_type;
-   int gpios[NUM_GPIOS];
+   struct gpio_desc *gpios[NUM_GPIOS];
/* External master clock frequency */
unsigned long mclk_frequency;
+   struct clk *clk;
 
/* Protects the struct fields below */
struct mutex lock;
@@ -511,10 +514,10 @@ static int ov965x_set_color_matrix(struct ov965x *ov965x)
return 0;
 }
 
-static void ov965x_gpio_set(int gpio, int val)
+static void ov965x_gpio_set(struct gpio_desc *gpio, int val)
 {
-   if (gpio_is_valid(gpio))
-   gpio_set_value(gpio, val);
+   if (gpio)
+   gpiod_set_value_cansleep(gpio, val);
 }
 
 static void __ov965x_set_power(struct ov965x *ov965x, int on)
@@ -1406,24 +1409,28 @@ static int ov965x_configure_gpios(struct ov965x *ov965x,
  const struct ov9650_platform_data *pdata)
 {
int ret, i;
+   int gpios[NUM_GPIOS];
 
-   ov965x->gpios[GPIO_PWDN] = pdata->gpio_pwdn;
-   ov965x->gpios[GPIO_RST]  = pdata->gpio_reset;
+   gpios[GPIO_PWDN] = pdata->gpio_pwdn;
+   gpios[GPIO_RST]  = pdata->gpio_reset;
 
-   for (i = 0; i < ARRAY_SIZE(ov965x->gpios); i++) {
-   int gpio = ov965x->gpios[i];
+   for (i = 0; i < ARRAY_SIZE(gpios); i++) {
+   int gpio = gpios[i];
 
if (!gpio_is_valid(gpio))
continue;
ret = devm_gpio_request_one(>client->dev, gpio,
-   GPIOF_OUT_INIT_HIGH, "OV965X");
-   if (ret < 0)
+   GPIOF_OUT_INIT_HIGH, DRIVER_NAME);
+   if (ret < 0) {
+   dev_err(>client->dev,
+   "Failed to request gpio%d (%d)\n", gpio, ret);
return ret;
+   }
v4l2_dbg(1, debug, >sd, "set gpio %d to 1\n", gpio);
 
gpio_set_value(gpio, 1);
gpio_export(gpio, 0);
-   ov965x->gpios[i] = gpio;
+   ov965x->gpios[i] = gpio_to_desc(gpio);
}
 
return 0;
@@ -1469,14 +1476,10 @@ static int ov965x_probe(struct i2c_client *client,
struct v4l2_subdev *sd;
struct ov965x *ov965x;
int ret;
+   struct device_node *np = client->dev.of_node;
 
-   if (pdata == NULL) {
-   dev_err(>dev, "platform data not specified\n");
-   return -EINVAL;
-   }
-
-   if (pdata->mclk_frequency == 0) {
-   dev_err(>dev, "MCLK frequency not specified\n");
+   if (!pdata && !np) {
+   dev_err(>dev, "Platform data or device tree data must 
be provided\n");
return -EINVAL;
}
 
@@ -1486,7 +1489,35 @@ static int ov965x_probe(struct i2c_client *client,
 
mutex_init(>lock);
ov965x->client = client;
-   ov965x->mclk_frequency = pdata->mclk_frequency;
+   mutex_init(>lock);
+
+   if (np) {
+   /* Device tree */
+   ov965x->gpios[GPIO_RST] =
+   devm_gpiod_get_optional(>dev, "resetb",
+   GPIOD_OUT_LOW);
+   ov965x->gpios[GPIO_PWDN] =
+   devm_gpiod_get_optional(>dev, "pwdn",
+   GPIOD_OUT_HIGH);
+
+   

[PATCH v2 6/7] [media] ov9650: add support of OV9655 variant

[Hugues Fruchet]

Add a first support of OV9655 variant.
Because of register set slightly different from OV9650/9652,
not all of the driver features are supported (controls).
Supported resolutions are limited to VGA, QVGA, QQVGA.
Supported format is limited to RGB565.
Controls are limited to color bar test pattern for test purpose.

Signed-off-by: H. Nikolaus Schaller 
Signed-off-by: Hugues Fruchet 
---
 drivers/media/i2c/Kconfig  |   4 +-
 drivers/media/i2c/ov9650.c | 487 ++---
 2 files changed, 457 insertions(+), 34 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 168115c..0f7542f 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -614,11 +614,11 @@ config VIDEO_OV7670
  controller.
 
 config VIDEO_OV9650
-   tristate "OmniVision OV9650/OV9652 sensor support"
+   tristate "OmniVision OV9650/OV9652/OV9655 sensor support"
depends on GPIOLIB && I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
---help---
  This is a V4L2 sensor-level driver for the Omnivision
- OV9650 and OV9652 camera sensors.
+ OV9650 and OV9652 and OV9655 camera sensors.
 
 config VIDEO_OV13858
tristate "OmniVision OV13858 sensor support"
diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
index 50397e6..9ff0782 100644
--- a/drivers/media/i2c/ov9650.c
+++ b/drivers/media/i2c/ov9650.c
@@ -1,5 +1,5 @@
 /*
- * Omnivision OV9650/OV9652 CMOS Image Sensor driver
+ * Omnivision OV9650/OV9652/OV9655 CMOS Image Sensor driver
  *
  * Copyright (C) 2013, Sylwester Nawrocki 
  *
@@ -7,6 +7,15 @@
  * by Vladimir Fonov.
  * Copyright (c) 2010, Vladimir Fonov
  *
+ *
+ * Copyright (C) STMicroelectronics SA 2017
+ * Author: Hugues Fruchet  for STMicroelectronics.
+ *
+ * OV9655 initial support based on a driver written by H. Nikolaus Schaller:
+ *   
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/video/ov9655
+ * OV9655 registers sequence from STM32CubeF7 embedded software, see:
+ *   
https://developer.mbed.org/teams/ST/code/BSP_DISCO_F746NG/file/e1d9da7fe856/Drivers/BSP/Components/ov9655/ov9655.c
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
@@ -58,14 +67,21 @@
 #define REG_PID0x0a/* Product ID MSB */
 #define REG_VER0x0b/* Product ID LSB */
 #define REG_COM3   0x0c
-#define  COM3_SWAP 0x40
+#define  COM3_COLORBAR 0x80
+#define  COM3_RGB565   0x00
+#define  COM3_SWAP 0x40/* Doesn't work in RGB */
+#define  COM3_RESETB   0x08
 #define  COM3_VARIOPIXEL1  0x04
+#define  OV9655_SINGLEFRAME0x01
 #define REG_COM4   0x0d/* Vario Pixels  */
 #define  COM4_VARIOPIXEL2  0x80
+#define  OV9655_TRISTATE   /* seems to have a different function */
 #define REG_COM5   0x0e/* System clock options */
 #define  COM5_SLAVE_MODE   0x10
-#define  COM5_SYSTEMCLOCK48MHZ 0x80
+#define  COM5_SYSTEMCLOCK48MHZ 0x80/* not on OV9655 */
+#define  OV9655_EXPOSURESTEP   0x01
 #define REG_COM6   0x0f/* HREF & ADBLC options */
+#define  COM6_BLC_OPTICAL  0x40/* Optical black */
 #define REG_AECH   0x10/* Exposure value, AEC[9:2] */
 #define REG_CLKRC  0x11/* Clock control */
 #define  CLK_EXT   0x40/* Use external clock directly */
@@ -74,13 +90,18 @@
 #define  COM7_RESET0x80
 #define  COM7_FMT_MASK 0x38
 #define  COM7_FMT_VGA  0x40
-#define COM7_FMT_CIF   0x20
+#define  COM7_FMT_CIF  0x20
 #define  COM7_FMT_QVGA 0x10
 #define  COM7_FMT_QCIF 0x08
-#define COM7_RGB   0x04
-#define COM7_YUV   0x00
-#define COM7_BAYER 0x01
-#define COM7_PBAYER0x05
+#define  COM7_RGB  0x04
+#define  COM7_YUV  0x00
+#define  COM7_BAYER0x01
+#define  COM7_PBAYER   0x05
+#define  OV9655_COM7_VGA   0x60
+#define  OV9655_COM7_RAWRGB0x00/* different format encoding */
+#define  OV9655_COM7_RAWRGBINT 0x01
+#define  OV9655_COM7_YUV   0x02
+#define  OV9655_COM7_RGB   0x03
 #define REG_COM8   0x13/* AGC/AEC options */
 #define  COM8_FASTAEC  0x80/* Enable fast AGC/AEC */
 #define  COM8_AECSTEP  0x40/* Unlimited AEC step size */
@@ -89,14 +110,23 @@
 #define  COM8_AWB  0x02/* White balance enable */
 #define  COM8_AEC  0x01/* Auto exposure enable */
 #define REG_COM9   0x14/* Gain ceiling */
-#define  COM9_GAIN_CEIL_MASK   0x70/* */
+#define  

[PATCH v2 5/7] [media] ov9650: add multiple variant support

[Hugues Fruchet]

Ops support and registers set can now be different
from a variant to another.

Signed-off-by: Hugues Fruchet 
---
 drivers/media/i2c/ov9650.c | 156 -
 1 file changed, 99 insertions(+), 57 deletions(-)

diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
index db96698..50397e6 100644
--- a/drivers/media/i2c/ov9650.c
+++ b/drivers/media/i2c/ov9650.c
@@ -38,7 +38,7 @@
 module_param(debug, int, 0644);
 MODULE_PARM_DESC(debug, "Debug level (0-2)");
 
-#define DRIVER_NAME "OV9650"
+#define DRIVER_NAME "ov965x"
 
 /*
  * OV9650/OV9652 register definitions
@@ -239,6 +239,13 @@ struct ov965x_framesize {
const struct i2c_rv *regs;
 };
 
+struct ov965x_pixfmt {
+   u32 code;
+   u32 colorspace;
+   /* REG_TSLB value, only bits [3:2] may be set. */
+   u8 tslb_reg;
+};
+
 struct ov965x_interval {
struct v4l2_fract interval;
/* Maximum resolution for this interval */
@@ -257,6 +264,21 @@ struct ov965x {
struct media_pad pad;
enum v4l2_mbus_type bus_type;
struct gpio_desc *gpios[NUM_GPIOS];
+
+   /* Variant specific regs and ops */
+   const struct i2c_rv *init_regs;
+   const struct ov965x_framesize *framesizes;
+   unsigned int nb_of_framesizes;
+   const struct ov965x_pixfmt *formats;
+   unsigned int nb_of_formats;
+   const struct ov965x_interval *intervals;
+   unsigned int nb_of_intervals;
+   int (*initialize_controls)(struct ov965x *ov965x);
+   int (*set_frame_interval)(struct ov965x *ov965x,
+ struct v4l2_subdev_frame_interval *fi);
+   void (*update_exposure_ctrl)(struct ov965x *ov965x);
+   int (*set_params)(struct ov965x *ov965x);
+
/* External master clock frequency */
unsigned long mclk_frequency;
struct clk *clk;
@@ -416,13 +438,6 @@ struct ov965x {
},
 };
 
-struct ov965x_pixfmt {
-   u32 code;
-   u32 colorspace;
-   /* REG_TSLB value, only bits [3:2] may be set. */
-   u8 tslb_reg;
-};
-
 static const struct ov965x_pixfmt ov965x_formats[] = {
{ MEDIA_BUS_FMT_YUYV8_2X8, V4L2_COLORSPACE_JPEG, 0x00},
{ MEDIA_BUS_FMT_YVYU8_2X8, V4L2_COLORSPACE_JPEG, 0x04},
@@ -576,7 +591,7 @@ static int ov965x_s_power(struct v4l2_subdev *sd, int on)
__ov965x_set_power(ov965x, on);
if (on) {
ret = ov965x_write_array(client,
-ov965x_init_regs);
+ov965x->init_regs);
ov965x->apply_frame_fmt = 1;
ov965x->ctrls.update = 1;
}
@@ -1090,12 +1105,13 @@ static int ov965x_initialize_controls(struct ov965x 
*ov965x)
 /*
  * V4L2 subdev video and pad level operations
  */
-static void ov965x_get_default_format(struct v4l2_mbus_framefmt *mf)
+static void ov965x_get_default_format(struct ov965x *ov965x,
+ struct v4l2_mbus_framefmt *mf)
 {
-   mf->width = ov965x_framesizes[0].width;
-   mf->height = ov965x_framesizes[0].height;
-   mf->colorspace = ov965x_formats[0].colorspace;
-   mf->code = ov965x_formats[0].code;
+   mf->width = ov965x->framesizes[0].width;
+   mf->height = ov965x->framesizes[0].height;
+   mf->colorspace = ov965x->formats[0].colorspace;
+   mf->code = ov965x->formats[0].code;
mf->field = V4L2_FIELD_NONE;
 }
 
@@ -1103,10 +1119,12 @@ static int ov965x_enum_mbus_code(struct v4l2_subdev *sd,
 struct v4l2_subdev_pad_config *cfg,
 struct v4l2_subdev_mbus_code_enum *code)
 {
-   if (code->index >= ARRAY_SIZE(ov965x_formats))
+   struct ov965x *ov965x = to_ov965x(sd);
+
+   if (code->index >= ov965x->nb_of_formats)
return -EINVAL;
 
-   code->code = ov965x_formats[code->index].code;
+   code->code = ov965x->formats[code->index].code;
return 0;
 }
 
@@ -1114,22 +1132,22 @@ static int ov965x_enum_frame_sizes(struct v4l2_subdev 
*sd,
   struct v4l2_subdev_pad_config *cfg,
   struct v4l2_subdev_frame_size_enum *fse)
 {
-   int i = ARRAY_SIZE(ov965x_formats);
+   struct ov965x *ov965x = to_ov965x(sd);
+   int i = ov965x->nb_of_formats;
 
-   if (fse->index >= ARRAY_SIZE(ov965x_framesizes))
+   if (fse->index >= ov965x->nb_of_framesizes)
return -EINVAL;
 
while (--i)
-   if (fse->code == ov965x_formats[i].code)
+   if (fse->code == ov965x->formats[i].code)
break;
 
-   fse->code = ov965x_formats[i].code;
+   fse->code = ov965x->formats[i].code;
 
-   fse->min_width  = ov965x_framesizes[fse->index].width;
+   fse->min_width  = ov965x->framesizes[fse->index].width;

[PATCH] [media] media: i2c: m5mols: fix spelling mistake: "Machanics" -> "Mechanics"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in v4l2_info message

Signed-off-by: Colin Ian King 
---
 drivers/media/i2c/m5mols/m5mols_core.c | 2 +-
 drivers/scsi/qedi/qedi_fw.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/m5mols/m5mols_core.c 
b/drivers/media/i2c/m5mols/m5mols_core.c
index 9ccb5ee55fa9..463534d44756 100644
--- a/drivers/media/i2c/m5mols/m5mols_core.c
+++ b/drivers/media/i2c/m5mols/m5mols_core.c
@@ -457,7 +457,7 @@ static int m5mols_get_version(struct v4l2_subdev *sd)
 
v4l2_info(sd, "Manufacturer\t[%s]\n",
is_manufacturer(info, REG_SAMSUNG_ELECTRO) ?
-   "Samsung Electro-Machanics" :
+   "Samsung Electro-Mechanics" :
is_manufacturer(info, REG_SAMSUNG_OPTICS) ?
"Samsung Fiber-Optics" :
is_manufacturer(info, REG_SAMSUNG_TECHWIN) ?
-- 
2.11.0

Re: Null Pointer Dereference in mceusb

[Johan Hovold]

On Mon, Jul 03, 2017 at 03:41:59PM +0700, Lars Melin wrote:
> On 2017-07-03 15:10, Johan Hovold wrote:
> > On Thu, Jun 29, 2017 at 07:41:24PM +0200, Sebastian wrote:
> >> Sorry for the long delay, Johan.
> >>
> >> 2017-06-01 9:20 GMT+02:00 Johan Hovold :
> >>> [ +CC: media list ]
> >>>
> >>> On Wed, May 31, 2017 at 08:25:42PM +0200, Sebastian wrote:
> >>>
> >>> What is the lsusb -v output for your device? And have you successfully
> >>> used this device with this driver before?
> >>>
> >>
> >> No, the device wasn't successfully used before that- it crashed every time,
> >> so I threw away the usb receiver. This is also the reason why I cannot give
> >> you the lsusb output. But I can give you the VID:PID -> 03ee:2501 if that
> >> is of any help?
> > 
> > Ok, so it's not necessarily a (recent) regression at least. I can't seem
> > to find anyone else posting lsusb -v output for that device
> > unfortunately.
> > 
> 
> Googling "03ee:2501 bDescriptorType" leads us to:
> https://sourceforge.net/p/lirc/mailman/message/12852102/

Thanks, Lars. Appears I didn't google hard enough.

Well that device has both a bulk IN and OUT endpoint, so if Sebastian's
device has the same descriptors, I'm left without an hypothesis as to
what would have caused the crash.

We'd need to get this verified on a recent mainline kernel (rather than
an older Ubuntu one) and then take it from there.

Thanks,
Johan

Re: [PATCH v3 2/4] media: adv7180: add adv7180cp, adv7180st compatible strings

[Ulrich Hecht]

On Fri, Jun 30, 2017 at 11:19 AM, Geert Uytterhoeven
 wrote:
> Hi Ulrich,
>
> On Fri, May 19, 2017 at 3:07 PM, Ulrich Hecht
>  wrote:
>> Used to differentiate between models with 3 and 6 inputs.
>>
>> Signed-off-by: Ulrich Hecht 
>> ---
>>  drivers/media/i2c/adv7180.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
>> index bdbbf8c..78de7dd 100644
>> --- a/drivers/media/i2c/adv7180.c
>> +++ b/drivers/media/i2c/adv7180.c
>> @@ -1452,6 +1452,8 @@ static SIMPLE_DEV_PM_OPS(adv7180_pm_ops, 
>> adv7180_suspend, adv7180_resume);
>>  #ifdef CONFIG_OF
>>  static const struct of_device_id adv7180_of_id[] = {
>> { .compatible = "adi,adv7180", },
>> +   { .compatible = "adi,adv7180cp", },
>> +   { .compatible = "adi,adv7180st", },
>> { .compatible = "adi,adv7182", },
>> { .compatible = "adi,adv7280", },
>> { .compatible = "adi,adv7280-m", },
>
> Adding compatible entries here is not sufficient, and causes a crash on
> r8a7793/gose with renesas-drivers-2017-06-27-v4.12-rc7:
>
> adv7180 2-0020: chip found @ 0x20 (e653.i2c)
> Unable to handle kernel NULL pointer dereference at virtual address 
> 0014
> pgd = c0003000
> [0014] *pgd=8040004003, *pmd=
> Internal error: Oops: 207 [#1] SMP ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc7-rcar2-initrd #37
> Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
> task: df427040 task.stack: df436000
> PC is at adv7180_probe+0x84/0x3cc
>
> In the absence of an entry in adv7180_id[], the passed i2c_device_id
> pointer is NULL, and thus dereferencing it crashes the system.

Thank you for testing this. I have sent a fix (" media: adv7180: add
missing adv7180cp, adv7180st i2c device IDs"), could you please check
if it unbreaks things for you?

CU
Uli

[PATCH] media: adv7180: add missing adv7180cp, adv7180st i2c device IDs

[Ulrich Hecht]

Fixes a crash on Renesas R8A7793 Gose board that uses these "compatible"
entries.

Signed-off-by: Ulrich Hecht 
---
 drivers/media/i2c/adv7180.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index 78de7dd..3df28f2 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -1402,6 +1402,8 @@ static int adv7180_remove(struct i2c_client *client)
 
 static const struct i2c_device_id adv7180_id[] = {
{ "adv7180", (kernel_ulong_t)_info },
+   { "adv7180cp", (kernel_ulong_t)_info },
+   { "adv7180st", (kernel_ulong_t)_info },
{ "adv7182", (kernel_ulong_t)_info },
{ "adv7280", (kernel_ulong_t)_info },
{ "adv7280-m", (kernel_ulong_t)_m_info },
-- 
2.7.4

Re: Null Pointer Dereference in mceusb

[Lars Melin]

On 2017-07-03 15:10, Johan Hovold wrote:

On Thu, Jun 29, 2017 at 07:41:24PM +0200, Sebastian wrote:

Sorry for the long delay, Johan.

2017-06-01 9:20 GMT+02:00 Johan Hovold :

[ +CC: media list ]

On Wed, May 31, 2017 at 08:25:42PM +0200, Sebastian wrote:

What is the lsusb -v output for your device? And have you successfully
used this device with this driver before?



No, the device wasn't successfully used before that- it crashed every time,
so I threw away the usb receiver. This is also the reason why I cannot give
you the lsusb output. But I can give you the VID:PID -> 03ee:2501 if that
is of any help?


Ok, so it's not necessarily a (recent) regression at least. I can't seem
to find anyone else posting lsusb -v output for that device
unfortunately.



Googling "03ee:2501 bDescriptorType" leads us to:
https://sourceforge.net/p/lirc/mailman/message/12852102/

/Lars

Re: Null Pointer Dereference in mceusb

[Johan Hovold]

On Thu, Jun 29, 2017 at 07:41:24PM +0200, Sebastian wrote:
> Sorry for the long delay, Johan.
> 
> 2017-06-01 9:20 GMT+02:00 Johan Hovold :
> > [ +CC: media list ]
> >
> > On Wed, May 31, 2017 at 08:25:42PM +0200, Sebastian wrote:
> >
> > What is the lsusb -v output for your device? And have you successfully
> > used this device with this driver before?
> >
> 
> No, the device wasn't successfully used before that- it crashed every time,
> so I threw away the usb receiver. This is also the reason why I cannot give
> you the lsusb output. But I can give you the VID:PID -> 03ee:2501 if that
> is of any help?

Ok, so it's not necessarily a (recent) regression at least. I can't seem
to find anyone else posting lsusb -v output for that device
unfortunately.

> > Can you reproduce this with a more recent mainline kernel (e.g.
> > 4.11.3)?
> 
> Unfortunately no :(
> 
> >
> > This looks like something which could happen if the device is lacking an
> > OUT endpoint, and a sanity check to catch that recently went in (and was
> > backported to the non-EOL stable trees).
> 
> I could buy the same device again and try?

If you're willing to that, that'd very helpful; either to verify that
the crash is already fixed (as mentioned above), or to allow us to track
down the separate issue.

Thanks,
Johan