Re: [PATCHv3 RFC 4/4] media: Catch null pipes on pipeline stop

[Sakari Ailus]

On Wed, Dec 14, 2016 at 05:53:00PM +, Kieran Bingham wrote:
> Hi Sakari,
> 
> On 14/12/16 12:43, Sakari Ailus wrote:
> > Hi Kieran,
> > 
> > On Wed, Dec 14, 2016 at 12:27:37PM +, Kieran Bingham wrote:
> >> Hi Sakari,
> >>
> >> On 14/12/16 07:28, Sakari Ailus wrote:
> >>> Hi Kieran,
> >>>
> >>> On Tue, Dec 13, 2016 at 05:59:44PM +, Kieran Bingham wrote:
>  media_entity_pipeline_stop() can be called through error paths with a
>  NULL entity pipe object. In this instance, stopping is a no-op, so
>  simply return without any action
> >>>
> >>> The approach of returning silently is wrong; the streaming count is 
> >>> indeed a
> >>> count: you have to decrement it the exactly same number of times it's been
> >>> increased. Code that attempts to call __media_entity_pipeline_stop() on an
> >>> entity that's not streaming is simply buggy.
> >>
> >> Ok, Thanks for the heads up on where to look, as I suspected we are in
> >> section B) of my comments below :D
> >>
> >>> I've got a patch here that adds a warning to graph traversal on streaming
> >>> count being zero. I sent a pull request including that some days ago:
> >>>
> >>> 
> >>> 
> >>
> >> Excellent, thanks, I've merged your branch into mine, and I'll
> >> investigate where the error is actually coming from.
> >>
> >> --
> >> Ok - so I've merged your patches, (and dropped this patch) but they
> >> don't fire any warning before I hit my null-pointer dereference in
> >> __media_pipeline_stop(), on the WARN_ON(!pipe->streaming_count);
> >>
> >> So I think this is a case of calling stop on an invalid entity rather
> >> than an unbalanced start/stop somehow:
> > 
> > Not necessarily. The pipe is set to NULL if the count goes to zero.
> > 
> > This check should be dropped, it's ill-placed anyway: if streaming count is
> > zero the pipe is expected to be NULL anyway in which case you get a NULL
> > pointer exception (that you saw there). With the check removed, you should
> > get the warning instead.
> 
> Ahh, yes, I'd missed the part there that was setting it to NULL.
> 
> However, it will still segfault ... (though hopefully after the warning)
> as the last line of the function states:
> 
>   if (!--pipe->streaming_count)
>   media_entity_graph_walk_cleanup(graph);
> 
> So we will hit a null deref on the pipe->streaming_count there, which
> still leaves an unbalanced stop as a kernel panic.

Right, indeed. The graph is part of the pipeline, so if pipe was NULL you
don't have graph either. How about changing the check to:

if (WARN_ON(!pipe))
return;

Instead of removing it. Nothing in that function really makes sense if
there's no pipeline. The driver bug still exists. That's just to make the
framework behaving a little bit better in the presence of that sort of bug.

> 
> In fact, I've just tested removing that WARN_ON(!pipe->streaming_count);
>  - it doesn't even get that far - and segfaults in
> 
>   media_entity_graph_walk_cleanup(graph);
> 
> [   80.916558] Unable to handle kernel NULL pointer dereference at
> virtual address 0110
> 
> [   81.769492] [] media_graph_walk_start+0x20/0xf0
> [   81.776615] [] __media_pipeline_stop+0x3c/0xd8
> [   81.783644] [] media_pipeline_stop+0x34/0x48
> [   81.790505] [] vsp1_du_setup_lif+0x68/0x5a8
> [   81.797279] [] rcar_du_vsp_disable+0x2c/0x38
> [   81.804137] [] rcar_du_crtc_stop+0x198/0x1e8
> [   81.810984] [] rcar_du_crtc_disable+0x20/0x38
> 
> due to the fact that 'graph' is dereferenced through the 'pipe'.
> 
> {
>   /* Entity->pipe is NULL, therefore 'graph' is invalid */
>   struct media_graph *graph = >pipe->graph;
>   struct media_pipeline *pipe = entity->pipe;
> 
>   media_graph_walk_start(graph, entity);
> ...
> }
> 
> So I suspect we do still need a warning or check in there somewhere.
> Something to tell the developer that there is an unbalanced stop, would
> be much better than a panic/segfault...
> 
> (And of course, we still need to look at the actual unbalanced stop in
> vsp1_du_setup_lif!)

Indeed.

> 

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv6] support for AD5820 camera auto-focus coil

[Sakari Ailus]

Hi Pali and Tony,

On Wed, Dec 14, 2016 at 07:08:19AM -0800, Tony Lindgren wrote:
> * Pali Rohár  [161214 05:38]:
> > On Monday 08 August 2016 23:41:32 Pavel Machek wrote:
> > > On Mon 2016-08-08 11:09:56, Sakari Ailus wrote:
> > > > On Fri, Aug 05, 2016 at 12:26:11PM +0200, Pavel Machek wrote:
> > > > > This adds support for AD5820 autofocus coil, found for example in
> > > > > Nokia N900 smartphone.
> > > > 
> > > > Thanks, Pavel!
> > > > 
> > > > Let's use V4L2_CID_FOCUS_ABSOLUTE, as is in the patch. If we get
> > > > something better in the future, we'll switch to that then.
> > > > 
> > > > I've applied this to ad5820 branch in my tree.
> > > 
> > > Thanks. If I understands things correctly, both DTS patch and this
> > > patch are waiting in your tree, so we should be good to go for 4.9
> > > (unless some unexpected problems surface)?
> > > 
> > > Best regards,
> > >   Pavel
> > 
> > Was DTS patch merged into 4.9? At least I do not see updated that dts 
> > file omap3-n900.dts in linus tree...
> 
> If it's not in current mainline or next, it's off my radar so sounds
> like I've somehow missed it and needs resending..

Where's this patch? I remember seeing the driver patch and the DT
documentation but no actual DT source patch for the N900.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cron job: media_tree daily build: WARNINGS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Thu Dec 15 05:00:22 CET 2016
media-tree git hash:d183e4efcae8d88a2f252e546978658ca6d273cc
media_build git hash:   1606032398b1d79149c1507be2029e1a00d8dff0
v4l-utils git hash: 188e604d57bec065078ff772c802b93ddb6def4b
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.8.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: OK
linux-3.12.67-i686: OK
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9-i686: OK
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: OK
linux-3.12.67-x86_64: OK
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: OK
linux-4.9-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC] [media] s5k6aa: set usleep_range greater 0

[Nicholas Mc Guire]

On Tue, Dec 13, 2016 at 03:53:47PM +0100, Sylwester Nawrocki wrote:
> Hi Laurent,
> 
> On 12/13/2016 03:10 PM, Laurent Pinchart wrote:
> > As pointed out by Ian Arkver, the datasheet states the delay should be 
> > >50µs. 
> > Would it make sense to reduce the sleep duration to (3000, 4000) for 
> > instance 
> > (or possibly even lower), instead of increasing it ?
> 
> Theoretically it would make sense, I believe the delay call should really
> be part of the set_power callback.  I think it is safe to decrease the
> delay value now, the boards using that driver have been dropped with commit
> 
> commit ca9143501c30a2ce5886757961408488fac2bb4c
> ARM: EXYNOS: Remove unused board files
> 
> As far as I am concerned you can do whatever you want with that delay
> call, remove it or decrease value, whatever helps to stop triggering
> warnings from the static analysis tools.
>
if its actually unused then it might be best to completely drop the code
raher than fixing up dead-code. Is the EXYNOS the only system that had
this device in use ? If it shold stay in then setting it to the above
proposed 3000, 4000 would seem the most resonable to me as I asume this
change would stay untested.

thx!
hofrat
 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 4/4] staging: android: ion: Call dma_map_sg for syncing and mapping

[Laura Abbott]

Technically, calling dma_buf_map_attachment should return a buffer
properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to
ensure this happens. As a side effect, this lets Ion buffers take
advantage of the dma_buf sync ioctls.

Not-signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion.c | 61 ++-
 1 file changed, 47 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 86dba07..5177d79 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -776,6 +776,11 @@ static struct sg_table *dup_sg_table(struct sg_table 
*table)
return new_table;
 }
 
+static void free_duped_table(struct sg_table *table)
+{
+   sg_free_table(table);
+   kfree(table);
+}
 
 static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
enum dma_data_direction direction)
@@ -784,15 +789,29 @@ static struct sg_table *ion_map_dma_buf(struct 
dma_buf_attachment *attachment,
struct ion_buffer *buffer = dmabuf->priv;
struct sg_table *table;
 
-   return dup_sg_table(buffer->sg_table);
+   /*
+* TODO: Need to sync wrt CPU or device completely owning?
+*/
+
+   table = dup_sg_table(buffer->sg_table);
+
+   if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
+   direction)){
+   ret = -ENOMEM;
+   goto err;
+   }
+
+err:
+   free_duped_table(table);
+   return ERR_PTR(ret);
 }
 
 static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
  struct sg_table *table,
  enum dma_data_direction direction)
 {
-   sg_free_table(table);
-   kfree(table);
+   dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
+   free_duped_table(table);
 }
 
 struct ion_vma_list {
@@ -889,16 +908,24 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf 
*dmabuf,
struct ion_buffer *buffer = dmabuf->priv;
void *vaddr;
 
-   if (!buffer->heap->ops->map_kernel) {
-   pr_err("%s: map kernel is not implemented by this heap.\n",
-  __func__);
-   return -ENODEV;
+   /*
+* TODO: Move this elsewhere because we don't always need a vaddr
+*/
+   if (buffer->heap->ops->map_kernel) {
+   mutex_lock(>lock);
+   vaddr = ion_buffer_kmap_get(buffer);
+   mutex_unlock(>lock);
}
 
-   mutex_lock(>lock);
-   vaddr = ion_buffer_kmap_get(buffer);
-   mutex_unlock(>lock);
-   return PTR_ERR_OR_ZERO(vaddr);
+   /*
+* Close enough right now? Flag to skip sync?
+*/
+   if (!dma_map_sg(buffer->dev->dev.this_device, buffer->sg_table->sgl,
+   buffer->sg_table->nents,
+DMA_BIDIRECTIONAL))
+   return -ENOMEM;
+
+   return 0;
 }
 
 static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf,
@@ -906,9 +933,15 @@ static int ion_dma_buf_end_cpu_access(struct dma_buf 
*dmabuf,
 {
struct ion_buffer *buffer = dmabuf->priv;
 
-   mutex_lock(>lock);
-   ion_buffer_kmap_put(buffer);
-   mutex_unlock(>lock);
+   if (buffer->heap->ops->map_kernel) {
+   mutex_lock(>lock);
+   ion_buffer_kmap_put(buffer);
+   mutex_unlock(>lock);
+   }
+
+   dma_unmap_sg(buffer->dev->dev.this_device, buffer->sg_table->sgl,
+   buffer->sg_table->nents,
+   DMA_BIDIRECTIONAL);
 
return 0;
 }
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 3/4] staging: android: ion: Remove page faulting support

[Laura Abbott]

Unclear if this is wanted or needed?

Not-signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion.c | 74 ---
 1 file changed, 74 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 76b874a0..86dba07 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -41,37 +41,11 @@
 #include "ion_priv.h"
 #include "compat_ion.h"
 
-bool ion_buffer_fault_user_mappings(struct ion_buffer *buffer)
-{
-   return (buffer->flags & ION_FLAG_CACHED) &&
-   !(buffer->flags & ION_FLAG_CACHED_NEEDS_SYNC);
-}
-
 bool ion_buffer_cached(struct ion_buffer *buffer)
 {
return !!(buffer->flags & ION_FLAG_CACHED);
 }
 
-static inline struct page *ion_buffer_page(struct page *page)
-{
-   return (struct page *)((unsigned long)page & ~(1UL));
-}
-
-static inline bool ion_buffer_page_is_dirty(struct page *page)
-{
-   return !!((unsigned long)page & 1UL);
-}
-
-static inline void ion_buffer_page_dirty(struct page **page)
-{
-   *page = (struct page *)((unsigned long)(*page) | 1UL);
-}
-
-static inline void ion_buffer_page_clean(struct page **page)
-{
-   *page = (struct page *)((unsigned long)(*page) & ~(1UL));
-}
-
 /* this function should only be called while dev->lock is held */
 static void ion_buffer_add(struct ion_device *dev,
   struct ion_buffer *buffer)
@@ -139,25 +113,6 @@ static struct ion_buffer *ion_buffer_create(struct 
ion_heap *heap,
buffer->dev = dev;
buffer->size = len;
 
-   if (ion_buffer_fault_user_mappings(buffer)) {
-   int num_pages = PAGE_ALIGN(buffer->size) / PAGE_SIZE;
-   struct scatterlist *sg;
-   int i, j, k = 0;
-
-   buffer->pages = vmalloc(sizeof(struct page *) * num_pages);
-   if (!buffer->pages) {
-   ret = -ENOMEM;
-   goto err1;
-   }
-
-   for_each_sg(table->sgl, sg, table->nents, i) {
-   struct page *page = sg_page(sg);
-
-   for (j = 0; j < sg->length / PAGE_SIZE; j++)
-   buffer->pages[k++] = page++;
-   }
-   }
-
buffer->dev = dev;
buffer->size = len;
INIT_LIST_HEAD(>vmas);
@@ -845,25 +800,6 @@ struct ion_vma_list {
struct vm_area_struct *vma;
 };
 
-static int ion_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
-{
-   struct ion_buffer *buffer = vma->vm_private_data;
-   unsigned long pfn;
-   int ret;
-
-   mutex_lock(>lock);
-   ion_buffer_page_dirty(buffer->pages + vmf->pgoff);
-   BUG_ON(!buffer->pages || !buffer->pages[vmf->pgoff]);
-
-   pfn = page_to_pfn(ion_buffer_page(buffer->pages[vmf->pgoff]));
-   ret = vm_insert_pfn(vma, (unsigned long)vmf->virtual_address, pfn);
-   mutex_unlock(>lock);
-   if (ret)
-   return VM_FAULT_ERROR;
-
-   return VM_FAULT_NOPAGE;
-}
-
 static void ion_vm_open(struct vm_area_struct *vma)
 {
struct ion_buffer *buffer = vma->vm_private_data;
@@ -900,7 +836,6 @@ static void ion_vm_close(struct vm_area_struct *vma)
 static const struct vm_operations_struct ion_vma_ops = {
.open = ion_vm_open,
.close = ion_vm_close,
-   .fault = ion_vm_fault,
 };
 
 static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
@@ -914,15 +849,6 @@ static int ion_mmap(struct dma_buf *dmabuf, struct 
vm_area_struct *vma)
return -EINVAL;
}
 
-   if (ion_buffer_fault_user_mappings(buffer)) {
-   vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND |
-   VM_DONTDUMP;
-   vma->vm_private_data = buffer;
-   vma->vm_ops = _vma_ops;
-   ion_vm_open(vma);
-   return 0;
-   }
-
if (!(buffer->flags & ION_FLAG_CACHED))
vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 1/4] staging: android: ion: Some cleanup

[Laura Abbott]

- dmap_cnt isn't used. Remove it.
- Ion has been using dma apis incorrectly to sync the caches.
  Remove bad usage in preparation for something better.
- The alignment field doesn't actually change the alignment of an
  allocation, it only serves as an error check. This is basically
  pointless. Remove the field.

Not-signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion-ioctl.c |  6 --
 drivers/staging/android/ion/ion.c   | 92 ++---
 drivers/staging/android/ion/ion.h   |  5 +-
 drivers/staging/android/ion/ion_carveout_heap.c | 16 +
 drivers/staging/android/ion/ion_chunk_heap.c| 15 +---
 drivers/staging/android/ion/ion_cma_heap.c  |  5 +-
 drivers/staging/android/ion/ion_page_pool.c |  3 -
 drivers/staging/android/ion/ion_priv.h  |  4 +-
 drivers/staging/android/ion/ion_system_heap.c   | 14 +---
 9 files changed, 16 insertions(+), 144 deletions(-)

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 7e7431d..a27db9d 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -95,7 +95,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned 
long arg)
struct ion_handle *handle;
 
handle = ion_alloc(client, data.allocation.len,
-   data.allocation.align,
data.allocation.heap_id_mask,
data.allocation.flags);
if (IS_ERR(handle))
@@ -146,11 +145,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
data.handle.handle = handle->id;
break;
}
-   case ION_IOC_SYNC:
-   {
-   ret = ion_sync_for_device(client, data.fd.fd);
-   break;
-   }
case ION_IOC_CUSTOM:
{
if (!dev->custom_ioctl)
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index d5cc307..8dd0932 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -102,7 +102,6 @@ static void ion_buffer_add(struct ion_device *dev,
 static struct ion_buffer *ion_buffer_create(struct ion_heap *heap,
struct ion_device *dev,
unsigned long len,
-   unsigned long align,
unsigned long flags)
 {
struct ion_buffer *buffer;
@@ -118,15 +117,14 @@ static struct ion_buffer *ion_buffer_create(struct 
ion_heap *heap,
buffer->flags = flags;
kref_init(>ref);
 
-   ret = heap->ops->allocate(heap, buffer, len, align, flags);
+   ret = heap->ops->allocate(heap, buffer, len, flags);
 
if (ret) {
if (!(heap->flags & ION_HEAP_FLAG_DEFER_FREE))
goto err2;
 
ion_heap_freelist_drain(heap, 0);
-   ret = heap->ops->allocate(heap, buffer, len, align,
- flags);
+   ret = heap->ops->allocate(heap, buffer, len, flags);
if (ret)
goto err2;
}
@@ -400,7 +398,7 @@ static int ion_handle_add(struct ion_client *client, struct 
ion_handle *handle)
 }
 
 struct ion_handle *ion_alloc(struct ion_client *client, size_t len,
-size_t align, unsigned int heap_id_mask,
+unsigned int heap_id_mask,
 unsigned int flags)
 {
struct ion_handle *handle;
@@ -409,8 +407,8 @@ struct ion_handle *ion_alloc(struct ion_client *client, 
size_t len,
struct ion_heap *heap;
int ret;
 
-   pr_debug("%s: len %zu align %zu heap_id_mask %u flags %x\n", __func__,
-len, align, heap_id_mask, flags);
+   pr_debug("%s: len %zu heap_id_mask %u flags %x\n", __func__,
+len, heap_id_mask, flags);
/*
 * traverse the list of heaps available in this system in priority
 * order.  If the heap type is supported by the client, and matches the
@@ -427,7 +425,7 @@ struct ion_handle *ion_alloc(struct ion_client *client, 
size_t len,
/* if the caller didn't specify this heap id */
if (!((1 << heap->id) & heap_id_mask))
continue;
-   buffer = ion_buffer_create(heap, dev, len, align, flags);
+   buffer = ion_buffer_create(heap, dev, len, flags);
if (!IS_ERR(buffer))
break;
}
@@ -797,17 +795,12 @@ void ion_client_destroy(struct ion_client *client)
 }
 EXPORT_SYMBOL(ion_client_destroy);
 
-static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
-  

[RFC PATCH 2/4] staging: android: ion: Duplicate sg_table

[Laura Abbott]

Ion currently returns a single sg_table on each dma_map call. This is
incorrect for later usage.

Not-signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion.c | 32 +++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 8dd0932..76b874a0 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -795,19 +795,49 @@ void ion_client_destroy(struct ion_client *client)
 }
 EXPORT_SYMBOL(ion_client_destroy);
 
+static struct sg_table *dup_sg_table(struct sg_table *table)
+{
+   struct sg_table *new_table;
+   int ret, i;
+   struct scatterlisg *sg, *new_sg;
+
+   new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
+   if (!new_table)
+   return ERR_PTR(-ENOMEM);
+
+   ret = sg_alloc_table(new_table, table->nents, GFP_KERNEL);
+   if (ret) {
+   kfree(table);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   new_sg = new_table->sgl;
+   for_each_sg(table->sgl, sg, table->nents, i) {
+   memcpy(new_sg, sg, sizeof(*sg));
+   sg->dma_address = 0;
+   new_sg = sg_next(new_sg);
+   }
+
+   return new_table;
+}
+
+
 static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
enum dma_data_direction direction)
 {
struct dma_buf *dmabuf = attachment->dmabuf;
struct ion_buffer *buffer = dmabuf->priv;
+   struct sg_table *table;
 
-   return buffer->sg_table;
+   return dup_sg_table(buffer->sg_table);
 }
 
 static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
  struct sg_table *table,
  enum dma_data_direction direction)
 {
+   sg_free_table(table);
+   kfree(table);
 }
 
 struct ion_vma_list {
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 0/4] Ion caching (yet again) proof of concept

[Laura Abbott]

Hi,

I've been (once again) looking at alternate caching models for Ion. Part of
this work is also to make Ion fit better in to the dma_buf model.

Ion is a bit unusual for dma_buf. Most drivers that support dma_buf have two
parts: exporting buffers that a driver allocates and importing buffers
allocated elsewhere for use by the driver. Ion is basically designed to export
only and not import buffers from other drivers (the need for import is also
on my TODO list) Even more unusual, there is no actual 'driver' to map into.
Ion currently does nothing except pass back the same sg_table each time without
calling dma_map.

The description of the .map_dma_buf function in dma_buf_ops

 * @map_dma_buf: returns list of scatter pages allocated, increases usecount
 *   of the buffer. Requires atleast one attach to be called
 *   before. Returned sg list should already be mapped into
 *   _device_ address space. This call may sleep. May also return
 *   -EINTR. Should return -EINVAL if attach hasn't been called yet.


So Ion is definitely not doing this correctly. This ties back into correcting
the caching model. If we call dma_map_sg/dma_unmap_sg with begin_cpu_access,
this should be enough to allow the caches to always be properly synchronized
and means we can drop the various dma_sync calls floating around. This is going
to violate one of the big fat comments in ion_buffer_create

/*
 * this will set up dma addresses for the sglist -- it is not
 * technically correct as per the dma api -- a specific
 * device isn't really taking ownership here.  However, in practice on
 * our systems the only dma_address space is physical addresses.
 * Additionally, we can't afford the overhead of invalidating every
 * allocation via dma_map_sg. The implicit contract here is that
 * memory coming from the heaps is ready for dma, ie if it has a
 * cached mapping that mapping has been invalidated
 */
for_each_sg(buffer->sg_table->sgl, sg, buffer->sg_table->nents, i) {
sg_dma_address(sg) = sg_phys(sg);
sg_dma_len(sg) = sg->length;
}


The overhead of invalidating is a valid concern. I'm hoping that the
architecture has either evolved such that this won't be a problem or we can
figure out some clever use of DMA_ATTR_SKIP_CPU_SYNC.

As part of this, I'm considering dropping the fault synchronization. If we have
explicit use begin_cpu_access and use of the dma_buf sync ioctls, I don't think
it should be necessary.

I have a 'pre-RFC' tree at 
https://pagure.io/kernel-ion/branch/ion_cache_proof_dec14
Yes, the patches are not bisectable and there is more to be done. These have
been compile tested only and haven't been hooked up to anything to actually run
(another actually big TODO). I'm mostly looking for feedback if this looks like
the right direction and if there are going to be major problems with this
approach. I don't actually anticipate this getting merged into
drivers/staging/android/ion but this is the easiest way to continue discussion.

Thanks,
Laura

Laura Abbott (4):
  staging: android: ion: Some cleanup
  staging: android: ion: Duplicate sg_table
  staging: android: ion: Remove page faulting support
  staging: android: ion: Call dma_map_sg for syncing and mapping

 drivers/staging/android/ion/ion-ioctl.c |   6 -
 drivers/staging/android/ion/ion.c   | 251 
 drivers/staging/android/ion/ion.h   |   5 +-
 drivers/staging/android/ion/ion_carveout_heap.c |  16 +-
 drivers/staging/android/ion/ion_chunk_heap.c|  15 +-
 drivers/staging/android/ion/ion_cma_heap.c  |   5 +-
 drivers/staging/android/ion/ion_page_pool.c |   3 -
 drivers/staging/android/ion/ion_priv.h  |   4 +-
 drivers/staging/android/ion/ion_system_heap.c   |  14 +-
 9 files changed, 90 insertions(+), 229 deletions(-)

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] v4l: vsp1: Add VIDIOC_EXPBUF support

[jac...@jmondi.org]

Hi Laurent,
  Yes, thanks you, I'm now able to use that ioctl and export dmabuf 
file descriptors


On 12/12/2016 11:37, Laurent Pinchart wrote:

Use the vb2 ioctl handler directly.

Signed-off-by: Laurent Pinchart 


Tested-by: Jacopo Mondi 


---
 drivers/media/platform/vsp1/vsp1_video.c | 1 +
 1 file changed, 1 insertion(+)

Jacopo,

Does this fix your issue ?

diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index fd3acf1a98a6..0113a55b19c9 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -1021,6 +1021,7 @@ static const struct v4l2_ioctl_ops vsp1_video_ioctl_ops = 
{
.vidioc_querybuf= vb2_ioctl_querybuf,
.vidioc_qbuf= vb2_ioctl_qbuf,
.vidioc_dqbuf   = vb2_ioctl_dqbuf,
+   .vidioc_expbuf  = vb2_ioctl_expbuf,
.vidioc_create_bufs = vb2_ioctl_create_bufs,
.vidioc_prepare_buf = vb2_ioctl_prepare_buf,
.vidioc_streamon= vsp1_video_streamon,



--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5] media: Driver for Toshiba et8ek8 5MP sensor

[Pavel Machek]

Hi!

> > > Rather some dev_warn()? Do we need stack trace here?
> > 
> > I don't see what is wrong with WARN(). These are not expected to
> > trigger, if they do we'll fix it. If you feel strongly about this,
> > feel free to suggest a patch.
> 
> One thing is consistency with other parts of code... On all other places
> is used dev_warn and on above 4 places WARN. dev_warn automatically adds
> device name for easy debugging...
> 
> Another thing is that above WARNs do not write why it is warning. It
> just write that some condition is not truth...

As I said, I believe it is fine as is.

> > > It was me who copied these sensors settings to kernel driver. And I
> > > chose only Stingray as this is what was needed for my N900 for
> > > testing... Btw, you could add somewhere my and Ivo's Signed-off and
> > > copyright state as we both modified et8ek8.c code...
> > 
> > Normally, people add copyrights when they modify the code. If you want
> > to do it now, please send me a patch. (With those warn_ons too, if you
> > care, but I think the code is fine as is).
> 
> I think sending patch in unified diff format for such change is
> overkill. Just place to header it.

Then the change does not happen. Sorry, I do not know what you
modified and when, and if it is copyrightable.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v5] media: Driver for Toshiba et8ek8 5MP sensor

[Pali Rohár]

On Wednesday 14 December 2016 21:12:02 Pavel Machek wrote:
> Hi!
> 
> > On Wednesday 14 December 2016 13:24:51 Pavel Machek wrote:
> > >  
> > > Add driver for et8ek8 sensor, found in Nokia N900 main camera. Can be
> > > used for taking photos in 2.5MP resolution with fcam-dev.
> > > 
> > > Signed-off-by: Ivaylo Dimitrov 
> > > Signed-off-by: Pavel Machek 
> > > 
> > > ---
> > > From v4 I did cleanups to coding style and removed various oddities.
> > > 
> > > Exposure value is now in native units, which simplifies the code.
> > > 
> > > The patch to add device tree bindings was already acked by device tree
> > > people.
> 
> > > + default:
> > > + WARN_ONCE(1, ET8EK8_NAME ": %s: invalid message length.\n",
> > > +   __func__);
> > 
> > dev_warn_once()
> ...
> > > + if (WARN_ONCE(cnt > ET8EK8_MAX_MSG,
> > > +   ET8EK8_NAME ": %s: too many messages.\n", __func__)) {
> > 
> > Maybe replace it with dev_warn_once() too? That condition in WARN_ONCE
> > does not look nice...
> ...
> > > + if (WARN(next->type != ET8EK8_REG_8BIT &&
> > > +  next->type != ET8EK8_REG_16BIT,
> > > +  "Invalid type = %d", next->type)) {
> > dev_warn()
> >
> > > + WARN_ON(sensor->power_count < 0);
> > 
> > Rather some dev_warn()? Do we need stack trace here?
> 
> I don't see what is wrong with WARN(). These are not expected to
> trigger, if they do we'll fix it. If you feel strongly about this,
> feel free to suggest a patch.

One thing is consistency with other parts of code... On all other places
is used dev_warn and on above 4 places WARN. dev_warn automatically adds
device name for easy debugging...

Another thing is that above WARNs do not write why it is warning. It
just write that some condition is not truth...

> > > +static int et8ek8_i2c_reglist_find_write(struct i2c_client *client,
> > > +  struct et8ek8_meta_reglist *meta,
> > > +  u16 type)
> > > +{
> > > + struct et8ek8_reglist *reglist;
> > > +
> > > + reglist = et8ek8_reglist_find_type(meta, type);
> > > + if (!reglist)
> > > + return -EINVAL;
> > > +
> > > + return et8ek8_i2c_write_regs(client, reglist->regs);
> > > +}
> > > +
> > > +static struct et8ek8_reglist **et8ek8_reglist_first(
> > > + struct et8ek8_meta_reglist *meta)
> > > +{
> > > + return >reglist[0].ptr;
> > > +}
> > 
> > Above code looks like re-implementation of linked-list. Does not kernel
> > already provide some?
> 
> Its actually array of pointers as far as I can tell. I don't think any
> helpers would be useful here.

Ok.

> > > + new = et8ek8_gain_table[gain];
> > > +
> > > + /* FIXME: optimise I2C writes! */
> > 
> > Is this FIMXE still valid?
> 
> Probably. Lets optimize it after merge.
> 
> > > + if (sensor->power_count) {
> > > + WARN_ON(1);
> > 
> > Such warning is probably not useful...
> 
> It should not happen, AFAICT. That's why I'd like to know if it does.

I mean: warning should have better description, what happened. Such
warning for somebody who does not see this code is not useful...

> > > +#include "et8ek8_reg.h"
> > > +
> > > +/*
> > > + * Stingray sensor mode settings for Scooby
> > > + */
> > 
> > Are settings for this sensor Stingray enough?
> 
> Seems to work well enough for me. If more modes are needed, we can add
> them later.

Ok.

> > It was me who copied these sensors settings to kernel driver. And I
> > chose only Stingray as this is what was needed for my N900 for
> > testing... Btw, you could add somewhere my and Ivo's Signed-off and
> > copyright state as we both modified et8ek8.c code...
> 
> Normally, people add copyrights when they modify the code. If you want
> to do it now, please send me a patch. (With those warn_ons too, if you
> care, but I think the code is fine as is).

I think sending patch in unified diff format for such change is
overkill. Just place to header it.

-- 
Pali Rohár
pali.ro...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 RFC 4/4] media: Catch null pipes on pipeline stop

[Laurent Pinchart]

Hi Kieran,

On Wednesday 14 Dec 2016 19:56:51 Kieran Bingham wrote:
> Hello Me.
> 
> Ok, so a bit of investigation into *why* we have an unbalanced
> media_pipeline stop call.
> 
> After a suspend/resume cycle, the function vsp1_pm_runtime_resume() is
> called by the PM framework.
> 
> The hardware is unable to reset successfully and the reset call returns
> -ETIMEDOUT which gets passed back to the PM framework as a failure and
> thus the device is not 'resumed'
> 
> This process is commenced, as the DU driver tries to enable the VSP, we
> get the following call stack:
> 
> rcar_du_crtc_resume()
>   rcar_du_vsp_enable()
> vsp1_du_setup_lif() // returns void
>   vsp1_device_get() // returns -ETIMEDOUT,

I suspect the call stack to not be entirely accurate as the 
rcar_du_crtc_resume() is never called :-)

> As the vsp1_du_setup_lif() returns void, the fact that the hardware
> failed to start is ignored.
> 
> Later we get a call to  rcar_du_vsp_disable(), which again calls into
> vsp1_du_setup_lif(), this time to disable the pipeline. And it is here,
> that the call to media_pipeline_stop() is an unbalanced call, as the
> corresponding media_pipeline_start() would only have been called if the
> vsp1_device_get() had succeeded, thus we find ourselves with a kernel
> panic on a null dereference.
> 
> Sorry for the terse notes, they are possibly/probably really for me if I
> get tasked to look back at this.
> --
> Regards
> 
> Kieran
> 
> On 13/12/16 17:59, Kieran Bingham wrote:
> > media_entity_pipeline_stop() can be called through error paths with a
> > NULL entity pipe object. In this instance, stopping is a no-op, so
> > simply return without any action
> > 
> > Signed-off-by: Kieran Bingham 
> > ---
> > 
> > I've marked this patch as RFC, although if deemed suitable, by all means
> > integrate it as is.
> > 
> > When testing suspend/resume operations on VSP1, I encountered a segfault
> > on the WARN_ON(!pipe->streaming_count) line, where 'pipe == NULL'. The
> > simple protection fix is to return early in this instance, as this patch
> > does however:
> > 
> > A) Does this early return path warrant a WARN() statement itself, to
> > identify drivers which are incorrectly calling
> > media_entity_pipeline_stop() with an invalid entity, or would this just
> > be noise ...
> > 
> > and therefore..
> > 
> > B) I also partly assume this patch could simply get NAK'd with a request
> > to go and dig out the root cause of calling media_entity_pipeline_stop()
> > with an invalid entity.
> > 
> > My brief investigation so far here so far shows that it's almost a second
> > order fault - where the first suspend resume cycle completes but leaves
> > the entity in an invalid state having followed an error path - and then
> > on a second suspend/resume - the stop fails with the affected segfault.
> > 
> > If statement A) or B) apply here, please drop this patch from the series,
> > and don't consider it a blocking issue for the other 3 patches.
> > 
> > Kieran
> > 
> >  drivers/media/media-entity.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
> > index c68239e60487..93c9cbf4bf46 100644
> > --- a/drivers/media/media-entity.c
> > +++ b/drivers/media/media-entity.c
> > @@ -508,6 +508,8 @@ void __media_entity_pipeline_stop(struct media_entity
> > *entity)> 
> > struct media_entity_graph *graph = >pipe->graph;
> > struct media_pipeline *pipe = entity->pipe;
> > 
> > +   if (!pipe)
> > +   return;
> > 
> > WARN_ON(!pipe->streaming_count);
> > media_entity_graph_walk_start(graph, entity);

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 1/4] v4l: vsp1: Move vsp1_video_setup_pipeline()

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Tuesday 13 Dec 2016 17:59:41 Kieran Bingham wrote:
> Move the static vsp1_video_setup_pipeline() function in preparation for
> the callee updates so that the vsp1_video_pipeline_run() call can
> configure pipelines following suspend resume actions.
> 
> This commit is just a code move for clarity performing no functional
> change.
> 
> Signed-off-by: Kieran Bingham 

Reviewed-by: Laurent Pinchart 

provided of course we still need this after the rework of 2/4.

> ---
>  drivers/media/platform/vsp1/vsp1_video.c | 82 ++---
>  1 file changed, 41 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_video.c
> b/drivers/media/platform/vsp1/vsp1_video.c index d351b9c768d2..44b687c0b8df
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_video.c
> +++ b/drivers/media/platform/vsp1/vsp1_video.c
> @@ -350,6 +350,47 @@ static void vsp1_video_frame_end(struct vsp1_pipeline
> *pipe, pipe->buffers_ready |= 1 << video->pipe_index;
>  }
> 
> +static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe)
> +{
> + struct vsp1_entity *entity;
> +
> + /* Determine this pipelines sizes for image partitioning support. */
> + vsp1_video_pipeline_setup_partitions(pipe);
> +
> + /* Prepare the display list. */
> + pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
> + if (!pipe->dl)
> + return -ENOMEM;
> +
> + if (pipe->uds) {
> + struct vsp1_uds *uds = to_uds(>uds->subdev);
> +
> + /* If a BRU is present in the pipeline before the UDS, the 
alpha
> +  * component doesn't need to be scaled as the BRU output alpha
> +  * value is fixed to 255. Otherwise we need to scale the alpha
> +  * component only when available at the input RPF.
> +  */
> + if (pipe->uds_input->type == VSP1_ENTITY_BRU) {
> + uds->scale_alpha = false;
> + } else {
> + struct vsp1_rwpf *rpf =
> + to_rwpf(>uds_input->subdev);
> +
> + uds->scale_alpha = rpf->fmtinfo->alpha;
> + }
> + }
> +
> + list_for_each_entry(entity, >entities, list_pipe) {
> + vsp1_entity_route_setup(entity, pipe->dl);
> +
> + if (entity->ops->configure)
> + entity->ops->configure(entity, pipe, pipe->dl,
> +VSP1_ENTITY_PARAMS_INIT);
> + }
> +
> + return 0;
> +}
> +
>  static void vsp1_video_pipeline_run_partition(struct vsp1_pipeline *pipe,
> struct vsp1_dl_list *dl)
>  {
> @@ -747,47 +788,6 @@ static void vsp1_video_buffer_queue(struct vb2_buffer
> *vb) spin_unlock_irqrestore(>irqlock, flags);
>  }
> 
> -static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe)
> -{
> - struct vsp1_entity *entity;
> -
> - /* Determine this pipelines sizes for image partitioning support. */
> - vsp1_video_pipeline_setup_partitions(pipe);
> -
> - /* Prepare the display list. */
> - pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
> - if (!pipe->dl)
> - return -ENOMEM;
> -
> - if (pipe->uds) {
> - struct vsp1_uds *uds = to_uds(>uds->subdev);
> -
> - /* If a BRU is present in the pipeline before the UDS, the 
alpha
> -  * component doesn't need to be scaled as the BRU output alpha
> -  * value is fixed to 255. Otherwise we need to scale the alpha
> -  * component only when available at the input RPF.
> -  */
> - if (pipe->uds_input->type == VSP1_ENTITY_BRU) {
> - uds->scale_alpha = false;
> - } else {
> - struct vsp1_rwpf *rpf =
> - to_rwpf(>uds_input->subdev);
> -
> - uds->scale_alpha = rpf->fmtinfo->alpha;
> - }
> - }
> -
> - list_for_each_entry(entity, >entities, list_pipe) {
> - vsp1_entity_route_setup(entity, pipe->dl);
> -
> - if (entity->ops->configure)
> - entity->ops->configure(entity, pipe, pipe->dl,
> -VSP1_ENTITY_PARAMS_INIT);
> - }
> -
> - return 0;
> -}
> -
>  static int vsp1_video_start_streaming(struct vb2_queue *vq, unsigned int
> count) {
>   struct vsp1_video *video = vb2_get_drv_priv(vq);

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5] media: Driver for Toshiba et8ek8 5MP sensor

[Pavel Machek]

Hi!

> On Wednesday 14 December 2016 13:24:51 Pavel Machek wrote:
> >  
> > Add driver for et8ek8 sensor, found in Nokia N900 main camera. Can be
> > used for taking photos in 2.5MP resolution with fcam-dev.
> > 
> > Signed-off-by: Ivaylo Dimitrov 
> > Signed-off-by: Pavel Machek 
> > 
> > ---
> > From v4 I did cleanups to coding style and removed various oddities.
> > 
> > Exposure value is now in native units, which simplifies the code.
> > 
> > The patch to add device tree bindings was already acked by device tree
> > people.

> > +   default:
> > +   WARN_ONCE(1, ET8EK8_NAME ": %s: invalid message length.\n",
> > + __func__);
> 
> dev_warn_once()
...
> > +   if (WARN_ONCE(cnt > ET8EK8_MAX_MSG,
> > + ET8EK8_NAME ": %s: too many messages.\n", __func__)) {
> 
> Maybe replace it with dev_warn_once() too? That condition in WARN_ONCE
> does not look nice...
...
> > +   if (WARN(next->type != ET8EK8_REG_8BIT &&
> > +next->type != ET8EK8_REG_16BIT,
> > +"Invalid type = %d", next->type)) {
> dev_warn()
>
> > +   WARN_ON(sensor->power_count < 0);
> 
> Rather some dev_warn()? Do we need stack trace here?

I don't see what is wrong with WARN(). These are not expected to
trigger, if they do we'll fix it. If you feel strongly about this,
feel free to suggest a patch.

> > +static int et8ek8_i2c_reglist_find_write(struct i2c_client *client,
> > +struct et8ek8_meta_reglist *meta,
> > +u16 type)
> > +{
> > +   struct et8ek8_reglist *reglist;
> > +
> > +   reglist = et8ek8_reglist_find_type(meta, type);
> > +   if (!reglist)
> > +   return -EINVAL;
> > +
> > +   return et8ek8_i2c_write_regs(client, reglist->regs);
> > +}
> > +
> > +static struct et8ek8_reglist **et8ek8_reglist_first(
> > +   struct et8ek8_meta_reglist *meta)
> > +{
> > +   return >reglist[0].ptr;
> > +}
> 
> Above code looks like re-implementation of linked-list. Does not kernel
> already provide some?

Its actually array of pointers as far as I can tell. I don't think any
helpers would be useful here.

> > +   new = et8ek8_gain_table[gain];
> > +
> > +   /* FIXME: optimise I2C writes! */
> 
> Is this FIMXE still valid?

Probably. Lets optimize it after merge.

> > +   if (sensor->power_count) {
> > +   WARN_ON(1);
> 
> Such warning is probably not useful...

It should not happen, AFAICT. That's why I'd like to know if it does.

> > +#include "et8ek8_reg.h"
> > +
> > +/*
> > + * Stingray sensor mode settings for Scooby
> > + */
> 
> Are settings for this sensor Stingray enough?

Seems to work well enough for me. If more modes are needed, we can add
them later.

> It was me who copied these sensors settings to kernel driver. And I
> chose only Stingray as this is what was needed for my N900 for
> testing... Btw, you could add somewhere my and Ivo's Signed-off and
> copyright state as we both modified et8ek8.c code...

Normally, people add copyrights when they modify the code. If you want
to do it now, please send me a patch. (With those warn_ons too, if you
care, but I think the code is fine as is).

I got code from Dmitry, so it has his signed-off.

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCHv3 RFC 4/4] media: Catch null pipes on pipeline stop

[Kieran Bingham]

Hello Me.

Ok, so a bit of investigation into *why* we have an unbalanced
media_pipeline stop call.

After a suspend/resume cycle, the function vsp1_pm_runtime_resume() is
called by the PM framework.

The hardware is unable to reset successfully and the reset call returns
-ETIMEDOUT which gets passed back to the PM framework as a failure and
thus the device is not 'resumed'

This process is commenced, as the DU driver tries to enable the VSP, we
get the following call stack:

rcar_du_crtc_resume()
  rcar_du_vsp_enable()
vsp1_du_setup_lif() // returns void
  vsp1_device_get() // returns -ETIMEDOUT,

As the vsp1_du_setup_lif() returns void, the fact that the hardware
failed to start is ignored.

Later we get a call to  rcar_du_vsp_disable(), which again calls into
vsp1_du_setup_lif(), this time to disable the pipeline. And it is here,
that the call to media_pipeline_stop() is an unbalanced call, as the
corresponding media_pipeline_start() would only have been called if the
vsp1_device_get() had succeeded, thus we find ourselves with a kernel
panic on a null dereference.

Sorry for the terse notes, they are possibly/probably really for me if I
get tasked to look back at this.
--
Regards

Kieran


On 13/12/16 17:59, Kieran Bingham wrote:
> media_entity_pipeline_stop() can be called through error paths with a
> NULL entity pipe object. In this instance, stopping is a no-op, so
> simply return without any action
> 
> Signed-off-by: Kieran Bingham 
> ---
> 
> I've marked this patch as RFC, although if deemed suitable, by all means
> integrate it as is.
> 
> When testing suspend/resume operations on VSP1, I encountered a segfault on 
> the
> WARN_ON(!pipe->streaming_count) line, where 'pipe == NULL'. The simple
> protection fix is to return early in this instance, as this patch does 
> however:
> 
> A) Does this early return path warrant a WARN() statement itself, to identify
> drivers which are incorrectly calling media_entity_pipeline_stop() with an
> invalid entity, or would this just be noise ...
> 
> and therefore..
> 
> B) I also partly assume this patch could simply get NAK'd with a request to go
> and dig out the root cause of calling media_entity_pipeline_stop() with an
> invalid entity. 
> 
> My brief investigation so far here so far shows that it's almost a second 
> order
> fault - where the first suspend resume cycle completes but leaves the entity 
> in
> an invalid state having followed an error path - and then on a second
> suspend/resume - the stop fails with the affected segfault.
> 
> If statement A) or B) apply here, please drop this patch from the series, and
> don't consider it a blocking issue for the other 3 patches.
> 
> Kieran
> 
> 
>  drivers/media/media-entity.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
> index c68239e60487..93c9cbf4bf46 100644
> --- a/drivers/media/media-entity.c
> +++ b/drivers/media/media-entity.c
> @@ -508,6 +508,8 @@ void __media_entity_pipeline_stop(struct media_entity 
> *entity)
>   struct media_entity_graph *graph = >pipe->graph;
>   struct media_pipeline *pipe = entity->pipe;
>  
> + if (!pipe)
> + return;
>  
>   WARN_ON(!pipe->streaming_count);
>   media_entity_graph_walk_start(graph, entity);
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 RFC 4/4] media: Catch null pipes on pipeline stop

[Kieran Bingham]

Hi Sakari,

On 14/12/16 12:43, Sakari Ailus wrote:
> Hi Kieran,
> 
> On Wed, Dec 14, 2016 at 12:27:37PM +, Kieran Bingham wrote:
>> Hi Sakari,
>>
>> On 14/12/16 07:28, Sakari Ailus wrote:
>>> Hi Kieran,
>>>
>>> On Tue, Dec 13, 2016 at 05:59:44PM +, Kieran Bingham wrote:
 media_entity_pipeline_stop() can be called through error paths with a
 NULL entity pipe object. In this instance, stopping is a no-op, so
 simply return without any action
>>>
>>> The approach of returning silently is wrong; the streaming count is indeed a
>>> count: you have to decrement it the exactly same number of times it's been
>>> increased. Code that attempts to call __media_entity_pipeline_stop() on an
>>> entity that's not streaming is simply buggy.
>>
>> Ok, Thanks for the heads up on where to look, as I suspected we are in
>> section B) of my comments below :D
>>
>>> I've got a patch here that adds a warning to graph traversal on streaming
>>> count being zero. I sent a pull request including that some days ago:
>>>
>>> 
>>> 
>>
>> Excellent, thanks, I've merged your branch into mine, and I'll
>> investigate where the error is actually coming from.
>>
>> --
>> Ok - so I've merged your patches, (and dropped this patch) but they
>> don't fire any warning before I hit my null-pointer dereference in
>> __media_pipeline_stop(), on the WARN_ON(!pipe->streaming_count);
>>
>> So I think this is a case of calling stop on an invalid entity rather
>> than an unbalanced start/stop somehow:
> 
> Not necessarily. The pipe is set to NULL if the count goes to zero.
> 
> This check should be dropped, it's ill-placed anyway: if streaming count is
> zero the pipe is expected to be NULL anyway in which case you get a NULL
> pointer exception (that you saw there). With the check removed, you should
> get the warning instead.

Ahh, yes, I'd missed the part there that was setting it to NULL.

However, it will still segfault ... (though hopefully after the warning)
as the last line of the function states:

if (!--pipe->streaming_count)
media_entity_graph_walk_cleanup(graph);

So we will hit a null deref on the pipe->streaming_count there, which
still leaves an unbalanced stop as a kernel panic.

In fact, I've just tested removing that WARN_ON(!pipe->streaming_count);
 - it doesn't even get that far - and segfaults in

media_entity_graph_walk_cleanup(graph);

[   80.916558] Unable to handle kernel NULL pointer dereference at
virtual address 0110

[   81.769492] [] media_graph_walk_start+0x20/0xf0
[   81.776615] [] __media_pipeline_stop+0x3c/0xd8
[   81.783644] [] media_pipeline_stop+0x34/0x48
[   81.790505] [] vsp1_du_setup_lif+0x68/0x5a8
[   81.797279] [] rcar_du_vsp_disable+0x2c/0x38
[   81.804137] [] rcar_du_crtc_stop+0x198/0x1e8
[   81.810984] [] rcar_du_crtc_disable+0x20/0x38

due to the fact that 'graph' is dereferenced through the 'pipe'.

{
/* Entity->pipe is NULL, therefore 'graph' is invalid */
struct media_graph *graph = >pipe->graph;
struct media_pipeline *pipe = entity->pipe;

media_graph_walk_start(graph, entity);
...
}

So I suspect we do still need a warning or check in there somewhere.
Something to tell the developer that there is an unbalanced stop, would
be much better than a panic/segfault...

(And of course, we still need to look at the actual unbalanced stop in
vsp1_du_setup_lif!)

--
Kieran
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 2/4] v4l: vsp1: Refactor video pipeline configuration

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Tuesday 13 Dec 2016 17:59:42 Kieran Bingham wrote:
> With multiple inputs through the BRU it is feasible for the streams to
> race each other at stream-on.

Could you please explain the race condition in the commit message ? The issue 
is that multiple VIDIOC_STREAMON calls racing each other could have process 
N-1 skipping over the pipeline setup section and then start the pipeline, if 
videobuf2 has already enqueued buffers to the driver for process N but not 
called the .start_streaming() operation yet.

> In the case of the video pipelines, this
> can present two serious issues.
> 
>  1) A null-dereference if the pipe->dl is committed at the same time as
> the vsp1_video_setup_pipeline() is processing
> 
>  2) A hardware hang, where a display list is committed without having
> called vsp1_video_setup_pipeline() first
> 
> Along side these race conditions, the work done by
> vsp1_video_setup_pipeline() is undone by the re-initialisation during a
> suspend resume cycle, and an active pipeline does not attempt to
> reconfigure the correct routing and init parameters for the entities.
> 
> To repair all of these issues, we can move the call to a conditional
> inside vsp1_video_pipeline_run() and ensure that this can only be called
> on the last stream which calls into vsp1_video_start_streaming()
> 
> As a convenient side effect of this, by specifying that the
> configuration has been lost during suspend/resume actions - the
> vsp1_video_pipeline_run() call can re-initialise pipelines when
> necessary thus repairing resume actions for active m2m pipelines.
> 
> Signed-off-by: Kieran Bingham 
> 
> ---
> v3:
>  - Move 'flag reset' to be inside the vsp1_reset_wpf() function call
>  - Tidy up the wpf->pipe reference for the configured flag
> 
>  drivers/media/platform/vsp1/vsp1_drv.c   |  4 
>  drivers/media/platform/vsp1/vsp1_pipe.c  |  1 +
>  drivers/media/platform/vsp1/vsp1_pipe.h  |  2 ++
>  drivers/media/platform/vsp1/vsp1_video.c | 20 +---
>  4 files changed, 16 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
> b/drivers/media/platform/vsp1/vsp1_drv.c index 57c713a4e1df..1dc3726c4e83
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_drv.c
> +++ b/drivers/media/platform/vsp1/vsp1_drv.c
> @@ -413,6 +413,7 @@ static int vsp1_create_entities(struct vsp1_device
> *vsp1)
> 
>  int vsp1_reset_wpf(struct vsp1_device *vsp1, unsigned int index)
>  {
> + struct vsp1_rwpf *wpf = vsp1->wpf[index];
>   unsigned int timeout;
>   u32 status;
> 
> @@ -429,6 +430,9 @@ int vsp1_reset_wpf(struct vsp1_device *vsp1, unsigned
> int index) usleep_range(1000, 2000);
>   }
> 
> + if (wpf->pipe)
> + wpf->pipe->configured = false;
> +
>   if (!timeout) {
>   dev_err(vsp1->dev, "failed to reset wpf.%u\n", index);
>   return -ETIMEDOUT;
> diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c
> b/drivers/media/platform/vsp1/vsp1_pipe.c index 756ca4ea7668..7ddf862ee403
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_pipe.c
> +++ b/drivers/media/platform/vsp1/vsp1_pipe.c
> @@ -208,6 +208,7 @@ void vsp1_pipeline_init(struct vsp1_pipeline *pipe)
> 
>   INIT_LIST_HEAD(>entities);
>   pipe->state = VSP1_PIPELINE_STOPPED;
> + pipe->configured = false;
>  }
> 
>  /* Must be called with the pipe irqlock held. */
> diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h
> b/drivers/media/platform/vsp1/vsp1_pipe.h index ac4ad261..0743b9fcb655
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_pipe.h
> +++ b/drivers/media/platform/vsp1/vsp1_pipe.h
> @@ -61,6 +61,7 @@ enum vsp1_pipeline_state {
>   * @pipe: the media pipeline
>   * @irqlock: protects the pipeline state
>   * @state: current state
> + * @configured: determines routing configuration active on cell.

I'm not sure to understand that. How about "true if the pipeline has been set 
up" ? Or maybe "true if the pipeline has been set up for video streaming" as 
it only applies to pipelines handled through the V4L2 API ?

>   * @wq: wait queue to wait for state change completion
>   * @frame_end: frame end interrupt handler
>   * @lock: protects the pipeline use count and stream count
> @@ -86,6 +87,7 @@ struct vsp1_pipeline {
> 
>   spinlock_t irqlock;
>   enum vsp1_pipeline_state state;
> + bool configured;
>   wait_queue_head_t wq;
> 
>   void (*frame_end)(struct vsp1_pipeline *pipe);
> diff --git a/drivers/media/platform/vsp1/vsp1_video.c
> b/drivers/media/platform/vsp1/vsp1_video.c index 44b687c0b8df..7ff9f4c19ff0
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_video.c
> +++ b/drivers/media/platform/vsp1/vsp1_video.c
> @@ -388,6 +388,8 @@ static int vsp1_video_setup_pipeline(struct
> vsp1_pipeline *pipe) VSP1_ENTITY_PARAMS_INIT);
>   }
> 
> + pipe->configured = true;
> +
>   return 0;
>  }
> 
> @@ -411,6 +413,9 @@ static void 

Re: [PATCH v5] media: Driver for Toshiba et8ek8 5MP sensor

[Ivaylo Dimitrov]

Hi

On 14.12.2016 15:03, Pali Rohár wrote:

Hi! See inlined some my notes.




+
+#ifdef USE_CRC
+   rval = et8ek8_i2c_read_reg(client, ET8EK8_REG_8BIT, 0x1263, );
+   if (rval)
+   goto out;
+#if USE_CRC /* TODO get crc setting from DT */
+   val |= BIT(4);
+#else
+   val &= ~BIT(4);
+#endif
+   rval = et8ek8_i2c_write_reg(client, ET8EK8_REG_8BIT, 0x1263, val);
+   if (rval)
+   goto out;
+#endif


USE_CRC is defined to 1. Do we need that #ifdef check at all?

What with above TODO?


+


It becomes a bit more complicated :) - on n900, front camera doesn't use 
CRC, while back camera does. Right now there is no way, even if we use 
video bus switch driver, to tell ISP to have 2 ports with different 
settings, not only for CRC, but for strobe, etc. Look at that commit 
https://github.com/freemangordon/linux-n900/commit/e5582fa56bbc0161d6c567157df42433829ee4de. 
What I think here is that ISP should take settings from the remote 
endpoints rather from it's local port. So far it does not.


So, until there is a way for ISP to have more than one CCP channel with 
different settings, I can't think of anything we can do here but to 
place TODO.


Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC] omap3isp: prevent releasing MC too early

[Mauro Carvalho Chehab]

Avoid calling streamoff without having the media structs allocated.

Signed-off-by: Mauro Carvalho Chehab 
---

Javier,

Could you please test this patch?

Thanks!
Mauro

 drivers/media/platform/omap3isp/ispvideo.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/omap3isp/ispvideo.c 
b/drivers/media/platform/omap3isp/ispvideo.c
index 7354469670b7..f60995ed0a1f 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -1488,11 +1488,17 @@ int omap3isp_video_register(struct isp_video *video, 
struct v4l2_device *vdev)
"%s: could not register video device (%d)\n",
__func__, ret);
 
+   /* Prevent destroying MC before unregistering */
+   kobject_get(vdev->v4l2_dev->mdev->devnode->dev.parent);
+
return ret;
 }
 
 void omap3isp_video_unregister(struct isp_video *video)
 {
-   if (video_is_registered(>video))
-   video_unregister_device(>video);
+   if (!video_is_registered(>video))
+   return;
+
+   video_unregister_device(>video);
+   kobject_put(vdev->v4l2_dev->mdev->devnode->dev.parent);
 }
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv6] support for AD5820 camera auto-focus coil

[Tony Lindgren]

* Pali Rohár  [161214 05:38]:
> On Monday 08 August 2016 23:41:32 Pavel Machek wrote:
> > On Mon 2016-08-08 11:09:56, Sakari Ailus wrote:
> > > On Fri, Aug 05, 2016 at 12:26:11PM +0200, Pavel Machek wrote:
> > > > This adds support for AD5820 autofocus coil, found for example in
> > > > Nokia N900 smartphone.
> > > 
> > > Thanks, Pavel!
> > > 
> > > Let's use V4L2_CID_FOCUS_ABSOLUTE, as is in the patch. If we get
> > > something better in the future, we'll switch to that then.
> > > 
> > > I've applied this to ad5820 branch in my tree.
> > 
> > Thanks. If I understands things correctly, both DTS patch and this
> > patch are waiting in your tree, so we should be good to go for 4.9
> > (unless some unexpected problems surface)?
> > 
> > Best regards,
> > Pavel
> 
> Was DTS patch merged into 4.9? At least I do not see updated that dts 
> file omap3-n900.dts in linus tree...

If it's not in current mainline or next, it's off my radar so sounds
like I've somehow missed it and needs resending..

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 4/6] [media] rc-ir-raw: do not generate any receiving thread for raw transmitters

[Andi Shyti]

Raw IR transmitters do not need any thread listening for
occurring events. Check the driver type before running the
thread.

Signed-off-by: Andi Shyti 
Reviewed-by: Sean Young 
---
 drivers/media/rc/rc-ir-raw.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index 1c42a9f..9938e42 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -270,12 +270,19 @@ int ir_raw_event_register(struct rc_dev *dev)
INIT_KFIFO(dev->raw->kfifo);
 
spin_lock_init(>raw->lock);
-   dev->raw->thread = kthread_run(ir_raw_event_thread, dev->raw,
-  "rc%u", dev->minor);
 
-   if (IS_ERR(dev->raw->thread)) {
-   rc = PTR_ERR(dev->raw->thread);
-   goto out;
+   /*
+* raw transmitters do not need any event registration
+* because the event is coming from userspace
+*/
+   if (dev->driver_type != RC_DRIVER_IR_RAW_TX) {
+   dev->raw->thread = kthread_run(ir_raw_event_thread, dev->raw,
+  "rc%u", dev->minor);
+
+   if (IS_ERR(dev->raw->thread)) {
+   rc = PTR_ERR(dev->raw->thread);
+   goto out;
+   }
}
 
mutex_lock(_raw_handler_lock);
-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/6] [media] rc-main: assign driver type during allocation

[Andi Shyti]

The driver type can be assigned immediately when an RC device
requests to the framework to allocate the device.

This is an 'enum rc_driver_type' data type and specifies whether
the device is a raw receiver or scancode receiver. The type will
be given as parameter to the rc_allocate_device device.

Change accordingly all the drivers calling rc_allocate_device()
so that the device type is specified during the rc device
allocation. Whenever the device type is not specified, it will be
set as RC_DRIVER_SCANCODE which was the default '0' value.

Suggested-by: Sean Young 
Signed-off-by: Andi Shyti 
Reviewed-by: Sean Young 
---
 drivers/hid/hid-picolcd_cir.c   |  3 +--
 drivers/media/cec/cec-core.c|  3 +--
 drivers/media/common/siano/smsir.c  |  3 +--
 drivers/media/i2c/ir-kbd-i2c.c  |  2 +-
 drivers/media/pci/bt8xx/bttv-input.c|  2 +-
 drivers/media/pci/cx23885/cx23885-input.c   | 11 +--
 drivers/media/pci/cx88/cx88-input.c |  3 +--
 drivers/media/pci/dm1105/dm1105.c   |  3 +--
 drivers/media/pci/mantis/mantis_input.c |  2 +-
 drivers/media/pci/saa7134/saa7134-input.c   |  2 +-
 drivers/media/pci/smipcie/smipcie-ir.c  |  3 +--
 drivers/media/pci/ttpci/budget-ci.c |  2 +-
 drivers/media/rc/ati_remote.c   |  3 +--
 drivers/media/rc/ene_ir.c   |  3 +--
 drivers/media/rc/fintek-cir.c   |  3 +--
 drivers/media/rc/gpio-ir-recv.c |  3 +--
 drivers/media/rc/igorplugusb.c  |  3 +--
 drivers/media/rc/iguanair.c |  3 +--
 drivers/media/rc/img-ir/img-ir-hw.c |  2 +-
 drivers/media/rc/img-ir/img-ir-raw.c|  3 +--
 drivers/media/rc/imon.c |  3 +--
 drivers/media/rc/ir-hix5hd2.c   |  3 +--
 drivers/media/rc/ite-cir.c  |  3 +--
 drivers/media/rc/mceusb.c   |  3 +--
 drivers/media/rc/meson-ir.c |  3 +--
 drivers/media/rc/nuvoton-cir.c  |  3 +--
 drivers/media/rc/rc-loopback.c  |  3 +--
 drivers/media/rc/rc-main.c  |  9 ++---
 drivers/media/rc/redrat3.c  |  3 +--
 drivers/media/rc/serial_ir.c|  3 +--
 drivers/media/rc/st_rc.c|  3 +--
 drivers/media/rc/streamzap.c|  3 +--
 drivers/media/rc/sunxi-cir.c|  3 +--
 drivers/media/rc/ttusbir.c  |  3 +--
 drivers/media/rc/winbond-cir.c  |  3 +--
 drivers/media/usb/au0828/au0828-input.c |  3 +--
 drivers/media/usb/cx231xx/cx231xx-input.c   |  2 +-
 drivers/media/usb/dvb-usb-v2/dvb_usb_core.c |  3 +--
 drivers/media/usb/dvb-usb/dvb-usb-remote.c  |  3 +--
 drivers/media/usb/em28xx/em28xx-input.c |  2 +-
 drivers/media/usb/tm6000/tm6000-input.c |  3 +--
 include/media/rc-core.h |  6 --
 42 files changed, 50 insertions(+), 85 deletions(-)

diff --git a/drivers/hid/hid-picolcd_cir.c b/drivers/hid/hid-picolcd_cir.c
index 9628651..38b0ea8 100644
--- a/drivers/hid/hid-picolcd_cir.c
+++ b/drivers/hid/hid-picolcd_cir.c
@@ -108,12 +108,11 @@ int picolcd_init_cir(struct picolcd_data *data, struct 
hid_report *report)
struct rc_dev *rdev;
int ret = 0;
 
-   rdev = rc_allocate_device();
+   rdev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rdev)
return -ENOMEM;
 
rdev->priv = data;
-   rdev->driver_type  = RC_DRIVER_IR_RAW;
rdev->allowed_protocols = RC_BIT_ALL;
rdev->open = picolcd_cir_open;
rdev->close= picolcd_cir_close;
diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index b0137e2..09bc0ba 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -244,7 +244,7 @@ struct cec_adapter *cec_allocate_adapter(const struct 
cec_adap_ops *ops,
 
 #if IS_REACHABLE(CONFIG_RC_CORE)
/* Prepare the RC input device */
-   adap->rc = rc_allocate_device();
+   adap->rc = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!adap->rc) {
pr_err("cec-%s: failed to allocate memory for rc_dev\n",
   name);
@@ -265,7 +265,6 @@ struct cec_adapter *cec_allocate_adapter(const struct 
cec_adap_ops *ops,
adap->rc->input_id.product = 0;
adap->rc->input_id.version = 1;
adap->rc->dev.parent = parent;
-   adap->rc->driver_type = RC_DRIVER_SCANCODE;
adap->rc->driver_name = CEC_NAME;
adap->rc->allowed_protocols = RC_BIT_CEC;
adap->rc->priv = adap;
diff --git a/drivers/media/common/siano/smsir.c 
b/drivers/media/common/siano/smsir.c
index 41f2a39..ee30c7b 100644
--- a/drivers/media/common/siano/smsir.c
+++ b/drivers/media/common/siano/smsir.c
@@ -58,7 +58,7 @@ int sms_ir_init(struct smscore_device_t *coredev)
struct rc_dev *dev;
 

[PATCH v4 2/6] [media] rc-main: split setup and unregister functions

[Andi Shyti]

Move the input device allocation, map and protocol handling to
different functions.

Signed-off-by: Andi Shyti 
Reviewed-by: Sean Young 
---
 drivers/media/rc/rc-main.c | 143 +
 1 file changed, 81 insertions(+), 62 deletions(-)

diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index a6bbceb..59fac96 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1436,16 +1436,12 @@ struct rc_dev *devm_rc_allocate_device(struct device 
*dev,
 }
 EXPORT_SYMBOL_GPL(devm_rc_allocate_device);
 
-int rc_register_device(struct rc_dev *dev)
+static int rc_setup_rx_device(struct rc_dev *dev)
 {
-   static bool raw_init = false; /* raw decoders loaded? */
-   struct rc_map *rc_map;
-   const char *path;
-   int attr = 0;
-   int minor;
int rc;
+   struct rc_map *rc_map;
 
-   if (!dev || !dev->map_name)
+   if (!dev->map_name)
return -EINVAL;
 
rc_map = rc_map_get(dev->map_name);
@@ -1454,6 +1450,19 @@ int rc_register_device(struct rc_dev *dev)
if (!rc_map || !rc_map->scan || rc_map->size == 0)
return -EINVAL;
 
+   rc = ir_setkeytable(dev, rc_map);
+   if (rc)
+   return rc;
+
+   if (dev->change_protocol) {
+   u64 rc_type = (1ll << rc_map->rc_type);
+
+   rc = dev->change_protocol(dev, _type);
+   if (rc < 0)
+   goto out_table;
+   dev->enabled_protocols = rc_type;
+   }
+
set_bit(EV_KEY, dev->input_dev->evbit);
set_bit(EV_REP, dev->input_dev->evbit);
set_bit(EV_MSC, dev->input_dev->evbit);
@@ -1463,6 +1472,61 @@ int rc_register_device(struct rc_dev *dev)
if (dev->close)
dev->input_dev->close = ir_close;
 
+   /*
+* Default delay of 250ms is too short for some protocols, especially
+* since the timeout is currently set to 250ms. Increase it to 500ms,
+* to avoid wrong repetition of the keycodes. Note that this must be
+* set after the call to input_register_device().
+*/
+   dev->input_dev->rep[REP_DELAY] = 500;
+
+   /*
+* As a repeat event on protocols like RC-5 and NEC take as long as
+* 110/114ms, using 33ms as a repeat period is not the right thing
+* to do.
+*/
+   dev->input_dev->rep[REP_PERIOD] = 125;
+
+   /* rc_open will be called here */
+   rc = input_register_device(dev->input_dev);
+   if (rc)
+   goto out_table;
+
+   dev->input_dev->dev.parent = >dev;
+   memcpy(>input_dev->id, >input_id, sizeof(dev->input_id));
+   dev->input_dev->phys = dev->input_phys;
+   dev->input_dev->name = dev->input_name;
+
+   return 0;
+
+out_table:
+   ir_free_table(>rc_map);
+
+   return rc;
+}
+
+static void rc_free_rx_device(struct rc_dev *dev)
+{
+   if (!dev)
+   return;
+
+   ir_free_table(>rc_map);
+
+   input_unregister_device(dev->input_dev);
+   dev->input_dev = NULL;
+}
+
+int rc_register_device(struct rc_dev *dev)
+{
+   static bool raw_init = false; /* raw decoders loaded? */
+   const char *path;
+   int attr = 0;
+   int minor;
+   int rc;
+
+   if (!dev)
+   return -EINVAL;
+
minor = ida_simple_get(_ida, 0, RC_DEV_MAX, GFP_KERNEL);
if (minor < 0)
return minor;
@@ -1486,39 +1550,15 @@ int rc_register_device(struct rc_dev *dev)
if (rc)
goto out_unlock;
 
-   rc = ir_setkeytable(dev, rc_map);
-   if (rc)
-   goto out_dev;
-
-   dev->input_dev->dev.parent = >dev;
-   memcpy(>input_dev->id, >input_id, sizeof(dev->input_id));
-   dev->input_dev->phys = dev->input_phys;
-   dev->input_dev->name = dev->input_name;
-
-   rc = input_register_device(dev->input_dev);
-   if (rc)
-   goto out_table;
-
-   /*
-* Default delay of 250ms is too short for some protocols, especially
-* since the timeout is currently set to 250ms. Increase it to 500ms,
-* to avoid wrong repetition of the keycodes. Note that this must be
-* set after the call to input_register_device().
-*/
-   dev->input_dev->rep[REP_DELAY] = 500;
-
-   /*
-* As a repeat event on protocols like RC-5 and NEC take as long as
-* 110/114ms, using 33ms as a repeat period is not the right thing
-* to do.
-*/
-   dev->input_dev->rep[REP_PERIOD] = 125;
-
path = kobject_get_path(>dev.kobj, GFP_KERNEL);
dev_info(>dev, "%s as %s\n",
dev->input_name ?: "Unspecified device", path ?: "N/A");
kfree(path);
 
+   rc = rc_setup_rx_device(dev);
+   if (rc)
+   goto out_dev;
+
if (dev->driver_type == RC_DRIVER_IR_RAW) {
if (!raw_init) {
 

[PATCH v4 0/6] Add support for IR transmitters

[Andi Shyti]

Hi,

The main goal is to add support in the rc framework for IR
transmitters, which currently is only supported by lirc but that
is not the preferred way.

The last patch adds support for an IR transmitter driven by
the MOSI line of an SPI controller, it's the case of the Samsung
TM2(e) board which support is currently ongoing.

The last patch adds support for an IR transmitter driven by
the MOSI line of an SPI controller, it's the case of the Samsung
TM2(e) board which support is currently ongoing.

Thanks,
Andi

Changelog from version 1:
-
The RFC is now PATCH. The main difference is that this version
doesn't try to add the any bit streaming protocol and doesn't
modify any LIRC interface specification.

patch 1: updates all the drivers using rc_allocate_device
patch 2: fixed errors and warning reported from the kbuild test
 robot
patch 5: this patch has been dropped and replaced with a new one
 which avoids waiting for transmitters.
patch 6: added new properties to the dts specification
patch 7: the driver uses the pulse/space input and converts it to
 a bit stream.


Changelog from version 2:
-
The original patch number 5 has been abandoned because it was not
bringing much benenfit.

patch 1: rebased on the new kernel.
patch 3: removed the sysfs attribute protocol for transmitters
patch 5: the binding has been moved to the leds section instead
 of the media. Fixed all the comments from Rob
patch 6: fixed all the comments from Sean added also Sean's
 review.

Changelog from version 3:
-
Added the patches Sean's review.

patch 1: commit ddbf7d5a has introduced the devm_* managed version
 of rc_allocate_device and rc_register_device, this patch
 has been rebased on top of it and adds the driver type
 as a parameter of the devm_rc_allocate_device.
patch 3: fixes a warning from the kbuild test robot
patch 5: after a discussion with Rob, despite mine, Jacek's and
 Mauro's objections [*] the binding has been placed under
 leds/irled/spi-ir-led.txt
patch 6: uses the new devm_* allocation and registration rc
 functions

[*] https://www.spinics.net/lists/linux-leds/msg07062.html
https://www.spinics.net/lists/linux-leds/msg07164.html
https://www.spinics.net/lists/linux-leds/msg07167.html

Andi Shyti (6):
  [media] rc-main: assign driver type during allocation
  [media] rc-main: split setup and unregister functions
  [media] rc-core: add support for IR raw transmitters
  [media] rc-ir-raw: do not generate any receiving thread for raw
transmitters
  Documentation: bindings: add documentation for ir-spi device driver
  [media] rc: add support for IR LEDs driven through SPI

 .../devicetree/bindings/leds/irled/spi-ir-led.txt  |  29 +++
 drivers/hid/hid-picolcd_cir.c  |   3 +-
 drivers/media/cec/cec-core.c   |   3 +-
 drivers/media/common/siano/smsir.c |   3 +-
 drivers/media/i2c/ir-kbd-i2c.c |   2 +-
 drivers/media/pci/bt8xx/bttv-input.c   |   2 +-
 drivers/media/pci/cx23885/cx23885-input.c  |  11 +-
 drivers/media/pci/cx88/cx88-input.c|   3 +-
 drivers/media/pci/dm1105/dm1105.c  |   3 +-
 drivers/media/pci/mantis/mantis_input.c|   2 +-
 drivers/media/pci/saa7134/saa7134-input.c  |   2 +-
 drivers/media/pci/smipcie/smipcie-ir.c |   3 +-
 drivers/media/pci/ttpci/budget-ci.c|   2 +-
 drivers/media/rc/Kconfig   |   9 +
 drivers/media/rc/Makefile  |   1 +
 drivers/media/rc/ati_remote.c  |   3 +-
 drivers/media/rc/ene_ir.c  |   3 +-
 drivers/media/rc/fintek-cir.c  |   3 +-
 drivers/media/rc/gpio-ir-recv.c|   3 +-
 drivers/media/rc/igorplugusb.c |   3 +-
 drivers/media/rc/iguanair.c|   3 +-
 drivers/media/rc/img-ir/img-ir-hw.c|   2 +-
 drivers/media/rc/img-ir/img-ir-raw.c   |   3 +-
 drivers/media/rc/imon.c|   3 +-
 drivers/media/rc/ir-hix5hd2.c  |   3 +-
 drivers/media/rc/ir-spi.c  | 199 +
 drivers/media/rc/ite-cir.c |   3 +-
 drivers/media/rc/mceusb.c  |   3 +-
 drivers/media/rc/meson-ir.c|   3 +-
 drivers/media/rc/nuvoton-cir.c |   3 +-
 drivers/media/rc/rc-ir-raw.c   |  17 +-
 drivers/media/rc/rc-loopback.c |   3 +-
 drivers/media/rc/rc-main.c | 186 +++
 drivers/media/rc/redrat3.c |   3 +-
 drivers/media/rc/serial_ir.c   |   3 +-
 drivers/media/rc/st_rc.c  

[PATCH v4 3/6] [media] rc-core: add support for IR raw transmitters

[Andi Shyti]

IR raw transmitter driver type is specified in the enum
rc_driver_type as RC_DRIVER_IR_RAW_TX which includes all those
devices that transmit raw stream of bit to a receiver.

The data are provided by userspace applications, therefore they
don't need any input device allocation, but still they need to be
registered as raw devices.

Suggested-by: Sean Young 
Signed-off-by: Andi Shyti 
Reviewed-by: Sean Young 
---
 drivers/media/rc/rc-main.c | 42 +-
 include/media/rc-core.h|  9 ++---
 2 files changed, 31 insertions(+), 20 deletions(-)

diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 59fac96..1ddecca 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1365,20 +1365,24 @@ struct rc_dev *rc_allocate_device(enum rc_driver_type 
type)
if (!dev)
return NULL;
 
-   dev->input_dev = input_allocate_device();
-   if (!dev->input_dev) {
-   kfree(dev);
-   return NULL;
-   }
+   if (type != RC_DRIVER_IR_RAW_TX) {
+   dev->input_dev = input_allocate_device();
+   if (!dev->input_dev) {
+   kfree(dev);
+   return NULL;
+   }
+
+   dev->input_dev->getkeycode = ir_getkeycode;
+   dev->input_dev->setkeycode = ir_setkeycode;
+   input_set_drvdata(dev->input_dev, dev);
 
-   dev->input_dev->getkeycode = ir_getkeycode;
-   dev->input_dev->setkeycode = ir_setkeycode;
-   input_set_drvdata(dev->input_dev, dev);
+   setup_timer(>timer_keyup, ir_timer_keyup,
+   (unsigned long)dev);
 
-   spin_lock_init(>rc_map.lock);
-   spin_lock_init(>keylock);
+   spin_lock_init(>rc_map.lock);
+   spin_lock_init(>keylock);
+   }
mutex_init(>lock);
-   setup_timer(>timer_keyup, ir_timer_keyup, (unsigned long)dev);
 
dev->dev.type = _dev_type;
dev->dev.class = _class;
@@ -1507,7 +1511,7 @@ static int rc_setup_rx_device(struct rc_dev *dev)
 
 static void rc_free_rx_device(struct rc_dev *dev)
 {
-   if (!dev)
+   if (!dev || dev->driver_type == RC_DRIVER_IR_RAW_TX)
return;
 
ir_free_table(>rc_map);
@@ -1537,7 +1541,8 @@ int rc_register_device(struct rc_dev *dev)
atomic_set(>initialized, 0);
 
dev->dev.groups = dev->sysfs_groups;
-   dev->sysfs_groups[attr++] = _dev_protocol_attr_grp;
+   if (dev->driver_type != RC_DRIVER_IR_RAW_TX)
+   dev->sysfs_groups[attr++] = _dev_protocol_attr_grp;
if (dev->s_filter)
dev->sysfs_groups[attr++] = _dev_filter_attr_grp;
if (dev->s_wakeup_filter)
@@ -1555,11 +1560,14 @@ int rc_register_device(struct rc_dev *dev)
dev->input_name ?: "Unspecified device", path ?: "N/A");
kfree(path);
 
-   rc = rc_setup_rx_device(dev);
-   if (rc)
-   goto out_dev;
+   if (dev->driver_type != RC_DRIVER_IR_RAW_TX) {
+   rc = rc_setup_rx_device(dev);
+   if (rc)
+   goto out_dev;
+   }
 
-   if (dev->driver_type == RC_DRIVER_IR_RAW) {
+   if (dev->driver_type == RC_DRIVER_IR_RAW ||
+   dev->driver_type == RC_DRIVER_IR_RAW_TX) {
if (!raw_init) {
request_module_nowait("ir-lirc-codec");
raw_init = true;
diff --git a/include/media/rc-core.h b/include/media/rc-core.h
index ba92c86..e6cb336 100644
--- a/include/media/rc-core.h
+++ b/include/media/rc-core.h
@@ -32,13 +32,16 @@ do {
\
 /**
  * enum rc_driver_type - type of the RC output
  *
- * @RC_DRIVER_SCANCODE:Driver or hardware generates a scancode
- * @RC_DRIVER_IR_RAW:  Driver or hardware generates pulse/space sequences.
- * It needs a Infra-Red pulse/space decoder
+ * @RC_DRIVER_SCANCODE: Driver or hardware generates a scancode
+ * @RC_DRIVER_IR_RAW:   Driver or hardware generates pulse/space sequences.
+ *  It needs a Infra-Red pulse/space decoder
+ * @RC_DRIVER_IR_RAW_TX: Device transmitter only,
+ *  driver requires pulse/space data sequence.
  */
 enum rc_driver_type {
RC_DRIVER_SCANCODE = 0,
RC_DRIVER_IR_RAW,
+   RC_DRIVER_IR_RAW_TX,
 };
 
 /**
-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 5/6] Documentation: bindings: add documentation for ir-spi device driver

[Andi Shyti]

Document the ir-spi driver's binding which is a IR led driven
through the SPI line.

Signed-off-by: Andi Shyti 
Reviewed-by: Sean Young 
---
 .../devicetree/bindings/leds/irled/spi-ir-led.txt  | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/irled/spi-ir-led.txt

diff --git a/Documentation/devicetree/bindings/leds/irled/spi-ir-led.txt 
b/Documentation/devicetree/bindings/leds/irled/spi-ir-led.txt
new file mode 100644
index 000..896b699
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/irled/spi-ir-led.txt
@@ -0,0 +1,29 @@
+Device tree bindings for IR LED connected through SPI bus which is used as
+remote controller.
+
+The IR LED switch is connected to the MOSI line of the SPI device and the data
+are delivered thourgh that.
+
+Required properties:
+   - compatible: should be "ir-spi-led".
+
+Optional properties:
+   - duty-cycle: 8 bit balue that represents the percentage of one period
+ in which the signal is active.  It can be 50, 60, 70, 75, 80 or 90.
+   - led-active-low: boolean value that specifies whether the output is
+ negated with a NOT gate.
+   - power-supply: specifies the power source. It can either be a regulator
+ or a gpio which enables a regulator, i.e. a regulator-fixed as
+ described in
+ Documentation/devicetree/bindings/regulator/fixed-regulator.txt
+
+Example:
+
+   irled@0 {
+   compatible = "ir-spi-led";
+   reg = <0x0>;
+   spi-max-frequency = <500>;
+   power-supply = <_led>;
+   led-active-low;
+   duty-cycle = /bits/ 8 <60>;
+   };
-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 6/6] [media] rc: add support for IR LEDs driven through SPI

[Andi Shyti]

The ir-spi is a simple device driver which supports the
connection between an IR LED and the MOSI line of an SPI device.

The driver, indeed, uses the SPI framework to stream the raw data
provided by userspace through an rc character device. The chardev
is handled by the LIRC framework and its functionality basically
provides:

 - write: the driver gets a pulse/space signal and translates it
   to a binary signal that will be streamed to the IR led through
   the SPI framework.
 - set frequency: sets the frequency whith which the data should
   be sent. This is handle with ioctl with the
   LIRC_SET_SEND_CARRIER flag (as per lirc documentation)
 - set duty cycle: this is also handled with ioctl with the
   LIRC_SET_SEND_DUTY_CYCLE flag. The driver handles duty cycles
   of 50%, 60%, 70%, 75%, 80% and 90%, calculated on 16bit data.

The character device is created under /dev/lircX name, where X is
and ID assigned by the LIRC framework.

Example of usage:

fd = open("/dev/lirc0", O_RDWR);
if (fd < 0)
return -1;

val = 608000;
ret = ioctl(fd, LIRC_SET_SEND_CARRIER, );
if (ret < 0)
return -1;

val = 60;
ret = ioctl(fd, LIRC_SET_SEND_DUTY_CYCLE, );
if (ret < 0)
return -1;

n = write(fd, buffer, BUF_LEN);
if (n < 0 || n != BUF_LEN)
ret = -1;

close(fd);

Signed-off-by: Andi Shyti 
Reviewed-by: Sean Young 
---
 drivers/media/rc/Kconfig  |   9 +++
 drivers/media/rc/Makefile |   1 +
 drivers/media/rc/ir-spi.c | 199 ++
 3 files changed, 209 insertions(+)
 create mode 100644 drivers/media/rc/ir-spi.c

diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 629e8ca..3351e25 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -261,6 +261,15 @@ config IR_REDRAT3
   To compile this driver as a module, choose M here: the
   module will be called redrat3.
 
+config IR_SPI
+   tristate "SPI connected IR LED"
+   depends on SPI && LIRC
+   ---help---
+ Say Y if you want to use an IR LED connected through SPI bus.
+
+ To compile this driver as a module, choose M here: the module will be
+ called ir-spi.
+
 config IR_STREAMZAP
tristate "Streamzap PC Remote IR Receiver"
depends on USB_ARCH_HAS_HCD
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 3a984ee..938c98b 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_IR_NUVOTON) += nuvoton-cir.o
 obj-$(CONFIG_IR_ENE) += ene_ir.o
 obj-$(CONFIG_IR_REDRAT3) += redrat3.o
 obj-$(CONFIG_IR_RX51) += ir-rx51.o
+obj-$(CONFIG_IR_SPI) += ir-spi.o
 obj-$(CONFIG_IR_STREAMZAP) += streamzap.o
 obj-$(CONFIG_IR_WINBOND_CIR) += winbond-cir.o
 obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
diff --git a/drivers/media/rc/ir-spi.c b/drivers/media/rc/ir-spi.c
new file mode 100644
index 000..d45c603
--- /dev/null
+++ b/drivers/media/rc/ir-spi.c
@@ -0,0 +1,199 @@
+/*
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Author: Andi Shyti 
+ *
+ * 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.
+ *
+ * SPI driven IR LED device driver
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IR_SPI_DRIVER_NAME "ir-spi"
+
+/* pulse value for different duty cycles */
+#define IR_SPI_PULSE_DC_50 0xff00
+#define IR_SPI_PULSE_DC_60 0xfc00
+#define IR_SPI_PULSE_DC_70 0xf800
+#define IR_SPI_PULSE_DC_75 0xf000
+#define IR_SPI_PULSE_DC_80 0xc000
+#define IR_SPI_PULSE_DC_90 0x8000
+
+#define IR_SPI_DEFAULT_FREQUENCY   38000
+#define IR_SPI_BIT_PER_WORD8
+#define IR_SPI_MAX_BUFSIZE  4096
+
+struct ir_spi_data {
+   u32 freq;
+   u8 duty_cycle;
+   bool negated;
+
+   u16 tx_buf[IR_SPI_MAX_BUFSIZE];
+   u16 pulse;
+   u16 space;
+
+   struct rc_dev *rc;
+   struct spi_device *spi;
+   struct regulator *regulator;
+};
+
+static int ir_spi_tx(struct rc_dev *dev,
+   unsigned int *buffer, unsigned int count)
+{
+   int i;
+   int ret;
+   unsigned int len = 0;
+   struct ir_spi_data *idata = dev->priv;
+   struct spi_transfer xfer;
+
+   /* convert the pulse/space signal to raw binary signal */
+   for (i = 0; i < count; i++) {
+   int j;
+   u16 val = ((i+1) % 2) ? idata->pulse : idata->space;
+
+   if (len + buffer[i] >= IR_SPI_MAX_BUFSIZE)
+   return -EINVAL;
+
+   /*
+* the first value in buffer is a pulse, so that 0, 2, 4, 

Re: [PATCHv6] support for AD5820 camera auto-focus coil

[Pali Rohár]

On Monday 08 August 2016 23:41:32 Pavel Machek wrote:
> On Mon 2016-08-08 11:09:56, Sakari Ailus wrote:
> > On Fri, Aug 05, 2016 at 12:26:11PM +0200, Pavel Machek wrote:
> > > This adds support for AD5820 autofocus coil, found for example in
> > > Nokia N900 smartphone.
> > 
> > Thanks, Pavel!
> > 
> > Let's use V4L2_CID_FOCUS_ABSOLUTE, as is in the patch. If we get
> > something better in the future, we'll switch to that then.
> > 
> > I've applied this to ad5820 branch in my tree.
> 
> Thanks. If I understands things correctly, both DTS patch and this
> patch are waiting in your tree, so we should be good to go for 4.9
> (unless some unexpected problems surface)?
> 
> Best regards,
>   Pavel

Was DTS patch merged into 4.9? At least I do not see updated that dts 
file omap3-n900.dts in linus tree...

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

[v4l-utils PATCH 2/3] dvb-sat: change the LNBf logic to make it more generic

[Mauro Carvalho Chehab]

There are some new LNBf models with more than two frequency
ranges. Change the logic there to allow adding those new
LNBf types.

Signed-off-by: Mauro Carvalho Chehab 
---
 lib/include/libdvbv5/dvb-sat.h |  14 +++
 lib/libdvbv5/dvb-fe.c  |   5 +-
 lib/libdvbv5/dvb-sat.c | 213 +++--
 3 files changed, 137 insertions(+), 95 deletions(-)

diff --git a/lib/include/libdvbv5/dvb-sat.h b/lib/include/libdvbv5/dvb-sat.h
index 7f83369fce39..424c4f454c03 100644
--- a/lib/include/libdvbv5/dvb-sat.h
+++ b/lib/include/libdvbv5/dvb-sat.h
@@ -132,6 +132,20 @@ const char *dvb_sat_get_lnb_name(int index);
  */
 int dvb_sat_set_parms(struct dvb_v5_fe_parms *parms);
 
+/**
+ * @brief return the real satellite frequency
+ * @ingroup satellite
+ *
+ * @param parmsstruct dvb_v5_fe_parms pointer.
+ *
+ * This function is called internally by the library to get the satellite
+ * frequency, considering the LO frequency.
+ *
+ * @return frequency.
+ */
+int dvb_sat_real_freq(struct dvb_v5_fe_parms *p, int freq);
+
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/libdvbv5/dvb-fe.c b/lib/libdvbv5/dvb-fe.c
index b0b8f5956d32..1e29c9f0186f 100644
--- a/lib/libdvbv5/dvb-fe.c
+++ b/lib/libdvbv5/dvb-fe.c
@@ -705,9 +705,8 @@ int __dvb_fe_get_parms(struct dvb_v5_fe_parms *p)
 
/* copy back params from temporary fe_prop */
for (i = 0; i < n; i++) {
-   if (dvb_fe_is_satellite(p->current_sys)
-   && fe_prop[i].cmd == DTV_FREQUENCY)
-   fe_prop[i].u.data += parms->freq_offset;
+   if (fe_prop[i].cmd == DTV_FREQUENCY)
+   fe_prop[i].u.data = dvb_sat_real_freq(p, 
fe_prop[i].u.data);
dvb_fe_store_parm(>p, fe_prop[i].cmd, 
fe_prop[i].u.data);
}
 
diff --git a/lib/libdvbv5/dvb-sat.c b/lib/libdvbv5/dvb-sat.c
index 254a1e2c7df7..bde0cfa3accb 100644
--- a/lib/libdvbv5/dvb-sat.c
+++ b/lib/libdvbv5/dvb-sat.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2011-2012 - Mauro Carvalho Chehab
+ * Copyright (c) 2011-2016 - Mauro Carvalho Chehab
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU Lesser General Public License as published by
@@ -39,19 +39,15 @@
 # define N_(string) string
 
 struct dvbsat_freqrange {
-   unsigned low, high;
+   unsigned low, high, int_freq, rangeswitch;
+   enum dvb_sat_polarization pol;
 };
 
 struct dvb_sat_lnb_priv {
struct dvb_sat_lnb desc;
 
/* Private members used internally */
-
-   unsigned lowfreq, highfreq;
-
-   unsigned rangeswitch;
-
-   struct dvbsat_freqrange freqrange[2];
+   struct dvbsat_freqrange freqrange[4];
 };
 
 static const struct dvb_sat_lnb_priv lnb[] = {
@@ -60,107 +56,92 @@ static const struct dvb_sat_lnb_priv lnb[] = {
.name = N_("Universal, Europe"),
.alias = "UNIVERSAL",
},
-   .lowfreq = 9750,
-   .highfreq = 10600,
-   .rangeswitch = 11700,
.freqrange = {
-   { 10800, 11800 },
-   { 11600, 12700 },
+   { 10800, 11800, 9750, 11700 },
+   { 11600, 12700, 10600, 0 },
}
}, {
.desc = {
.name = N_("Expressvu, North America"),
.alias = "DBS",
},
-   .lowfreq = 11250,
.freqrange = {
-   { 12200, 12700 }
+   { 12200, 12700, 11250 }
}
}, {
.desc = {
.name = N_("Astra 1E, European Universal Ku 
(extended)"),
.alias = "EXTENDED",
},
-   .lowfreq = 9750,
-   .highfreq = 10600,
-   .rangeswitch = 11700,
.freqrange = {
-   { 10700, 11700 },
-   { 11700, 12750 },
+   { 10700, 11700, 9750, 11700},
+   { 11700, 12750, 10600, 0 },
}
}, {
.desc = {
.name = N_("Standard"),
.alias = "STANDARD",
},
-   .lowfreq = 1,
.freqrange = {
-   { 10945, 11450 }
+   { 10945, 11450, 1, 0 }
},
}, {
.desc = {
.name = N_("L10700"),
.alias = "L10700",
},
-   .lowfreq = 10700,
.freqrange = {
-  { 11750, 12750 }
+  { 11750, 12750, 10700, 0 }
},
}, {
.desc = {
.name = 

[v4l-utils PATCH 0/3] Add support for LNBfs with more than 2 LO

[Mauro Carvalho Chehab]

When dvb-sat was written, it assumed that the LNBf entries would have
only 2 local oscilators, as this is what other tools did.

However, there are some widely LNBf models used in Brazil more local
oscilators, meant to be used on multipoint arrangements.

Add support for them.

Please notice that this change breaks the libdvbv5 API. Not sure how
to handle this incompatibility. That's basically why I'm not commiting
it directly.

Suggestions?

Mauro Carvalho Chehab (3):
  dvb-sat: embeed most stuff internally at struct LNBf
  dvb-sat: change the LNBf logic to make it more generic
  dvb-sat: add support for several BrasilSat LNBf models

 lib/include/libdvbv5/dvb-sat.h |  39 ++---
 lib/libdvbv5/dvb-fe.c  |   5 +-
 lib/libdvbv5/dvb-sat.c | 340 +++--
 3 files changed, 244 insertions(+), 140 deletions(-)

-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[v4l-utils PATCH 3/3] dvb-sat: add support for several BrasilSat LNBf models

[Mauro Carvalho Chehab]

There are some LNBf manufactured by BrasilSat that are
widely used in Brazil. Add support for them, based on what's
described on this document:
http://www.brasilsat.com.br/arquivo/DataSheet1.pdf

I tested myself the custom GVT model.

Signed-off-by: Mauro Carvalho Chehab 
---
 lib/libdvbv5/dvb-sat.c | 49 +
 1 file changed, 49 insertions(+)

diff --git a/lib/libdvbv5/dvb-sat.c b/lib/libdvbv5/dvb-sat.c
index bde0cfa3accb..7eb02284e3c4 100644
--- a/lib/libdvbv5/dvb-sat.c
+++ b/lib/libdvbv5/dvb-sat.c
@@ -143,6 +143,55 @@ static const struct dvb_sat_lnb_priv lnb[] = {
.freqrange = {
{ 11710, 12751, 10678, 0 }
}
+   }, {
+   .desc = {
+   .name = N_("BrasilSat Stacked"),
+   .alias = "STACKED-BRASILSAT",
+   },
+   .freqrange = {
+   { 10700, 11700, 9710, 0, POLARIZATION_H },
+   { 10700, 11700, 9750, 0, POLARIZATION_H },
+   },
+   }, {
+   .desc = {
+   .name = N_("BrasilSat Oi"),
+   .alias = "OI-BRASILSAT",
+   },
+   .freqrange = {
+   { 10950, 11200, 1, 11700 },
+   { 11800, 12200, 10445, 0 },
+   }
+   }, {
+   .desc = {
+   .name = N_("BrasilSat Amazonas 1/2 - 3 Oscilators"),
+   .alias = "AMAZONAS",
+   },
+   .freqrange = {
+   { 11037, 11450, 9670, 0, POLARIZATION_V },
+   { 11770, 12070, 9922, 0, POLARIZATION_H },
+   { 10950, 11280, 1, 0, POLARIZATION_H },
+   },
+   }, {
+   .desc = {
+   .name = N_("BrasilSat Amazonas 1/2 - 2 Oscilators"),
+   .alias = "AMAZONAS",
+   },
+   .freqrange = {
+   { 11037, 11360, 9670, 0, POLARIZATION_V },
+   { 11780, 12150, 1, 0, POLARIZATION_H },
+   { 10950, 11280, 1, 0, POLARIZATION_H },
+   },
+   }, {
+   .desc = {
+   .name = N_("BrasilSat custom GVT"),
+   .alias = "GVT-BRASILSAT",
+   },
+   .freqrange = {
+   { 11010.5, 11067.5, 12860, 0, POLARIZATION_V },
+   { 11704.0, 11941.0, 13435, 0, POLARIZATION_V },
+   { 10962.5, 11199.5, 13112, 0, POLARIZATION_H },
+   { 11704.0, 12188.0, 13138, 0, POLARIZATION_H },
+   },
},
 };
 
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[v4l-utils PATCH 1/3] dvb-sat: embeed most stuff internally at struct LNBf

[Mauro Carvalho Chehab]

We'll need to change the way dvb-sat.c handle LNBfs, in order
to be able to support more advanced LNBf with 4 oscilators.

So, let's first use an obscure most stuff for userspace.
Please notice that, unfortunately, this will break the API.

Signed-off-by: Mauro Carvalho Chehab 
---
 lib/include/libdvbv5/dvb-sat.h | 25 ---
 lib/libdvbv5/dvb-sat.c | 94 +-
 2 files changed, 66 insertions(+), 53 deletions(-)

diff --git a/lib/include/libdvbv5/dvb-sat.h b/lib/include/libdvbv5/dvb-sat.h
index 3f796435fa77..7f83369fce39 100644
--- a/lib/include/libdvbv5/dvb-sat.h
+++ b/lib/include/libdvbv5/dvb-sat.h
@@ -36,32 +36,12 @@
  */
 
 /**
- * @struct dvbsat_freqrange
- * @brief Defines a frequency range used by Satellite
- * @ingroup satellite
- *
- * @param low  low frequency, in kHz
- * @param high high frequency, in kHz
- */
-struct dvbsat_freqrange {
-   unsigned low, high;
-};
-
-/**
  * @struct dvb_sat_lnb
  * @brief Stores the information of a LNBf
  * @ingroup satellite
  *
  * @param name long name of the LNBf type
  * @param aliasshort name for the LNBf type
- * @param lowfreq  Low frequency Intermediate Frequency of the LNBf, in kHz
- * @param highfreq High frequency Intermediate frequency of the LNBf,
- * in kHz
- * @param rangeswitch  For LNBf that has multiple frequency ranges controlled
- * by a voltage change, specify the start frequency where
- * the second range will be applied.
- * @param freqrangeContains the range(s) of frequencies supported by a
- * given LNBf.
  *
  * The LNBf (low-noise block downconverter) is a type of amplifier that is
  * installed inside the parabolic dishes. It converts the antenna signal to
@@ -73,11 +53,6 @@ struct dvbsat_freqrange {
 struct dvb_sat_lnb {
const char *name;
const char *alias;
-   unsigned lowfreq, highfreq;
-
-   unsigned rangeswitch;
-
-   struct dvbsat_freqrange freqrange[2];
 };
 
 struct dvb_v5_fe_parms;
diff --git a/lib/libdvbv5/dvb-sat.c b/lib/libdvbv5/dvb-sat.c
index 557bc7765e23..254a1e2c7df7 100644
--- a/lib/libdvbv5/dvb-sat.c
+++ b/lib/libdvbv5/dvb-sat.c
@@ -38,10 +38,28 @@
 
 # define N_(string) string
 
-static const struct dvb_sat_lnb lnb[] = {
+struct dvbsat_freqrange {
+   unsigned low, high;
+};
+
+struct dvb_sat_lnb_priv {
+   struct dvb_sat_lnb desc;
+
+   /* Private members used internally */
+
+   unsigned lowfreq, highfreq;
+
+   unsigned rangeswitch;
+
+   struct dvbsat_freqrange freqrange[2];
+};
+
+static const struct dvb_sat_lnb_priv lnb[] = {
{
-   .name = N_("Universal, Europe"),
-   .alias = "UNIVERSAL",
+   .desc = {
+   .name = N_("Universal, Europe"),
+   .alias = "UNIVERSAL",
+   },
.lowfreq = 9750,
.highfreq = 10600,
.rangeswitch = 11700,
@@ -50,15 +68,19 @@ static const struct dvb_sat_lnb lnb[] = {
{ 11600, 12700 },
}
}, {
-   .name = N_("Expressvu, North America"),
-   .alias = "DBS",
+   .desc = {
+   .name = N_("Expressvu, North America"),
+   .alias = "DBS",
+   },
.lowfreq = 11250,
.freqrange = {
{ 12200, 12700 }
}
}, {
-   .name = N_("Astra 1E, European Universal Ku (extended)"),
-   .alias = "EXTENDED",
+   .desc = {
+   .name = N_("Astra 1E, European Universal Ku 
(extended)"),
+   .alias = "EXTENDED",
+   },
.lowfreq = 9750,
.highfreq = 10600,
.rangeswitch = 11700,
@@ -67,59 +89,75 @@ static const struct dvb_sat_lnb lnb[] = {
{ 11700, 12750 },
}
}, {
-   .name = N_("Standard"),
-   .alias = "STANDARD",
+   .desc = {
+   .name = N_("Standard"),
+   .alias = "STANDARD",
+   },
.lowfreq = 1,
.freqrange = {
{ 10945, 11450 }
},
}, {
-   .name = N_("L10700"),
-   .alias = "L10700",
+   .desc = {
+   .name = N_("L10700"),
+   .alias = "L10700",
+   },
.lowfreq = 10700,
.freqrange = {
   { 11750, 12750 }
},
}, {
-   .name = N_("L11300"),
-   .alias = "L11300",
+   .desc = {
+   .name = N_("L11300"),
+   .alias = "L11300",
+  

Re: [PATCH v5] media: Driver for Toshiba et8ek8 5MP sensor

[Pali Rohár]

Hi! See inlined some my notes.

On Wednesday 14 December 2016 13:24:51 Pavel Machek wrote:
>  
> Add driver for et8ek8 sensor, found in Nokia N900 main camera. Can be
> used for taking photos in 2.5MP resolution with fcam-dev.
> 
> Signed-off-by: Ivaylo Dimitrov 
> Signed-off-by: Pavel Machek 
> 
> ---
> From v4 I did cleanups to coding style and removed various oddities.
> 
> Exposure value is now in native units, which simplifies the code.
> 
> The patch to add device tree bindings was already acked by device tree
> people.
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 2669b4b..6d01e15 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -667,6 +667,7 @@ config VIDEO_S5K5BAF
> camera sensor with an embedded SoC image signal processor.
>  
>  source "drivers/media/i2c/smiapp/Kconfig"
> +source "drivers/media/i2c/et8ek8/Kconfig"
>  
>  config VIDEO_S5C73M3
>   tristate "Samsung S5C73M3 sensor support"
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 92773b2..5bc7bbe 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -2,6 +2,7 @@ msp3400-objs  :=  msp3400-driver.o msp3400-kthreads.o
>  obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o
>  
>  obj-$(CONFIG_VIDEO_SMIAPP)   += smiapp/
> +obj-$(CONFIG_VIDEO_ET8EK8)   += et8ek8/
>  obj-$(CONFIG_VIDEO_CX25840) += cx25840/
>  obj-$(CONFIG_VIDEO_M5MOLS)   += m5mols/
>  obj-y+= soc_camera/
> diff --git a/drivers/media/i2c/et8ek8/Kconfig 
> b/drivers/media/i2c/et8ek8/Kconfig
> new file mode 100644
> index 000..1439936
> --- /dev/null
> +++ b/drivers/media/i2c/et8ek8/Kconfig
> @@ -0,0 +1,6 @@
> +config VIDEO_ET8EK8
> + tristate "ET8EK8 camera sensor support"
> + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> + ---help---
> +   This is a driver for the Toshiba ET8EK8 5 MP camera sensor.
> +   It is used for example in Nokia N900 (RX-51).
> diff --git a/drivers/media/i2c/et8ek8/Makefile 
> b/drivers/media/i2c/et8ek8/Makefile
> new file mode 100644
> index 000..66d1b7d
> --- /dev/null
> +++ b/drivers/media/i2c/et8ek8/Makefile
> @@ -0,0 +1,2 @@
> +et8ek8-objs  += et8ek8_mode.o et8ek8_driver.o
> +obj-$(CONFIG_VIDEO_ET8EK8)   += et8ek8.o
> diff --git a/drivers/media/i2c/et8ek8/et8ek8_driver.c 
> b/drivers/media/i2c/et8ek8/et8ek8_driver.c
> new file mode 100644
> index 000..4a638f8
> --- /dev/null
> +++ b/drivers/media/i2c/et8ek8/et8ek8_driver.c
> @@ -0,0 +1,1515 @@
> +/*
> + * et8ek8_driver.c
> + *
> + * Copyright (C) 2008 Nokia Corporation
> + *
> + * Contact: Sakari Ailus 
> + *  Tuukka Toivonen 
> + *  Pavel Machek 
> + *
> + * Based on code from Toni Leinonen .
> + *
> + * This driver is based on the Micron MT9T012 camera imager driver
> + * (C) Texas Instruments.
> + *
> + * 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "et8ek8_reg.h"
> +
> +#define ET8EK8_NAME  "et8ek8"
> +#define ET8EK8_PRIV_MEM_SIZE 128
> +#define ET8EK8_MAX_MSG   48
> +
> +struct et8ek8_sensor {
> + struct v4l2_subdev subdev;
> + struct media_pad pad;
> + struct v4l2_mbus_framefmt format;
> + struct gpio_desc *reset;
> + struct regulator *vana;
> + struct clk *ext_clk;
> + u32 xclk_freq;
> +
> + u16 version;
> +
> + struct v4l2_ctrl_handler ctrl_handler;
> + struct v4l2_ctrl *exposure;
> + struct v4l2_ctrl *pixel_rate;
> + struct et8ek8_reglist *current_reglist;
> +
> + u8 priv_mem[ET8EK8_PRIV_MEM_SIZE];
> +
> + struct mutex power_lock;
> + int power_count;
> +};
> +
> +#define to_et8ek8_sensor(sd) container_of(sd, struct et8ek8_sensor, subdev)
> +
> +enum et8ek8_versions {
> + ET8EK8_REV_1 = 0x0001,
> + ET8EK8_REV_2,
> +};
> +
> +/*
> + * This table describes what should be written to the sensor register
> + * for each gain value. The gain(index in the table) is in terms of
> + * 0.1EV, i.e. 10 indexes in the table give 2 time more gain [0] in
> + * the *analog gain, [1] in the digital gain
> + *
> + * Analog gain [dB] = 20*log10(regvalue/32); 0x20..0x100
> + */
> +static struct et8ek8_gain {
> + u16 analog;
> + u16 digital;
> +} 

[PATCH 0/2] video/sti/cec: add HDMI notifier support

[Benjamin Gaignard]

Following (copying !) what Hans have done in this serie of patches
http://www.spinics.net/lists/linux-media/msg109141.html
I have implemented hdmi notifier in hdmi controled and stih-cec drivers.

Those patches should be applied on top of Hans patches for exynos.

I have tested hdmi notifier by pluging/unpluging HDMI cable and check
the value of the physical address with "cec-ctl --tuner".
"cec-compliance -A" is also functional.

Hans, I haven't move stih-cec out of staging because I don't have the
exact branch to test it, can you do the move for stih-cec after applying
those patches ?

Regards,
Benjamin

Benjamin Gaignard (2):
  sti: hdmi: add HDMI notifier support
  stih-cec: add hdmi-notifier support

 .../devicetree/bindings/media/stih-cec.txt |  2 ++
 arch/arm/boot/dts/stih407-family.dtsi  | 12 -
 arch/arm/boot/dts/stih410.dtsi | 15 ++-
 drivers/gpu/drm/sti/Kconfig|  1 +
 drivers/gpu/drm/sti/sti_hdmi.c | 15 +++
 drivers/gpu/drm/sti/sti_hdmi.h |  2 ++
 drivers/staging/media/st-cec/Kconfig   |  1 +
 drivers/staging/media/st-cec/stih-cec.c| 29 +-
 8 files changed, 63 insertions(+), 14 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] sti: hdmi: add HDMI notifier support

[Benjamin Gaignard]

Implement the HDMI notifier support to allow CEC drivers to
be informed when there is a new EDID and when a connect or
disconnect happens.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/Kconfig|  1 +
 drivers/gpu/drm/sti/sti_hdmi.c | 15 +++
 drivers/gpu/drm/sti/sti_hdmi.h |  2 ++
 3 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index acd7286..59ceffc 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -8,5 +8,6 @@ config DRM_STI
select DRM_PANEL
select FW_LOADER
select SND_SOC_HDMI_CODEC if SND_SOC
+   select HDMI_NOTIFIERS
help
  Choose this option to enable DRM on STM stiH4xx chipset
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 376b076..6667371 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -786,6 +786,8 @@ static void sti_hdmi_disable(struct drm_bridge *bridge)
clk_disable_unprepare(hdmi->clk_pix);
 
hdmi->enabled = false;
+
+   hdmi_event_disconnect(hdmi->notifier);
 }
 
 static void sti_hdmi_pre_enable(struct drm_bridge *bridge)
@@ -892,6 +894,10 @@ static int sti_hdmi_connector_get_modes(struct 
drm_connector *connector)
if (!edid)
goto fail;
 
+   hdmi_event_connect(hdmi->notifier);
+   hdmi_event_new_edid(hdmi->notifier, edid,
+   EDID_LENGTH * (edid->extensions + 1));
+
count = drm_add_edid_modes(connector, edid);
drm_mode_connector_update_edid_property(connector, edid);
drm_edid_to_eld(connector, edid);
@@ -949,10 +955,12 @@ struct drm_connector_helper_funcs 
sti_hdmi_connector_helper_funcs = {
 
if (hdmi->hpd) {
DRM_DEBUG_DRIVER("hdmi cable connected\n");
+   hdmi_event_connect(hdmi->notifier);
return connector_status_connected;
}
 
DRM_DEBUG_DRIVER("hdmi cable disconnected\n");
+   hdmi_event_disconnect(hdmi->notifier);
return connector_status_disconnected;
 }
 
@@ -1464,6 +1472,10 @@ static int sti_hdmi_probe(struct platform_device *pdev)
goto release_adapter;
}
 
+   hdmi->notifier = hdmi_notifier_get(>dev);
+   if (!hdmi->notifier)
+   goto release_adapter;
+
hdmi->reset = devm_reset_control_get(dev, "hdmi");
/* Take hdmi out of reset */
if (!IS_ERR(hdmi->reset))
@@ -1483,11 +1495,14 @@ static int sti_hdmi_remove(struct platform_device *pdev)
 {
struct sti_hdmi *hdmi = dev_get_drvdata(>dev);
 
+   hdmi_event_disconnect(hdmi->notifier);
+
i2c_put_adapter(hdmi->ddc_adapt);
if (hdmi->audio_pdev)
platform_device_unregister(hdmi->audio_pdev);
component_del(>dev, _hdmi_ops);
 
+   hdmi_notifier_put(hdmi->notifier);
return 0;
 }
 
diff --git a/drivers/gpu/drm/sti/sti_hdmi.h b/drivers/gpu/drm/sti/sti_hdmi.h
index 119bc35..70aac98 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.h
+++ b/drivers/gpu/drm/sti/sti_hdmi.h
@@ -8,6 +8,7 @@
 #define _STI_HDMI_H_
 
 #include 
+#include 
 #include 
 
 #include 
@@ -102,6 +103,7 @@ struct sti_hdmi {
struct platform_device *audio_pdev;
struct hdmi_audio_params audio;
struct drm_connector *drm_connector;
+   struct hdmi_notifier *notifier;
 };
 
 u32 hdmi_read(struct sti_hdmi *hdmi, int offset);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] stih-cec: add hdmi-notifier support

[Benjamin Gaignard]

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

Update the bindings documenting the new hdmi phandle and
update stih410.dtsi and stih407-family.dtsi accordingly.

Signed-off-by: Benjamin Gaignard 
---
 .../devicetree/bindings/media/stih-cec.txt |  2 ++
 arch/arm/boot/dts/stih407-family.dtsi  | 12 -
 arch/arm/boot/dts/stih410.dtsi | 15 ++-
 drivers/staging/media/st-cec/Kconfig   |  1 +
 drivers/staging/media/st-cec/stih-cec.c| 29 +-
 5 files changed, 45 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/stih-cec.txt 
b/Documentation/devicetree/bindings/media/stih-cec.txt
index 71c4b2f..7d82121 100644
--- a/Documentation/devicetree/bindings/media/stih-cec.txt
+++ b/Documentation/devicetree/bindings/media/stih-cec.txt
@@ -9,6 +9,7 @@ Required properties:
  - pinctrl-names: Contains only one value - "default"
  - pinctrl-0: Specifies the pin control groups used for CEC hardware.
  - resets: Reference to a reset controller
+ - st,hdmi-handle: Phandle to the HMDI controller
 
 Example for STIH407:
 
@@ -22,4 +23,5 @@ sti-cec@094a087c {
pinctrl-names = "default";
pinctrl-0 = <_cec0_default>;
resets = < STIH407_LPM_SOFTRESET>;
+   st,hdmi-handle = <>;
 };
diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
b/arch/arm/boot/dts/stih407-family.dtsi
index 8f79b41..ef7c79a 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -756,18 +756,6 @@
 <_s_c0_flexgen CLK_ETH_PHY>;
};
 
-   cec: sti-cec@094a087c {
-   compatible = "st,stih-cec";
-   reg = <0x94a087c 0x64>;
-   clocks = <_sysin>;
-   clock-names = "cec-clk";
-   interrupts = ;
-   interrupt-names = "cec-irq";
-   pinctrl-names = "default";
-   pinctrl-0 = <_cec0_default>;
-   resets = < STIH407_LPM_SOFTRESET>;
-   };
-
rng10: rng@08a89000 {
compatible  = "st,rng";
reg = <0x08a89000 0x1000>;
diff --git a/arch/arm/boot/dts/stih410.dtsi b/arch/arm/boot/dts/stih410.dtsi
index a3ef734..c98d86e 100644
--- a/arch/arm/boot/dts/stih410.dtsi
+++ b/arch/arm/boot/dts/stih410.dtsi
@@ -193,7 +193,7 @@
 <_s_d2_quadfs 0>;
};
 
-   sti-hdmi@8d04000 {
+   hdmi: sti-hdmi@8d04000 {
compatible = "st,stih407-hdmi";
reg = <0x8d04000 0x1000>;
reg-names = "hdmi-reg";
@@ -259,5 +259,18 @@
clocks = <_sysin>;
interrupts = ;
};
+
+   sti-cec@094a087c {
+   compatible = "st,stih-cec";
+   reg = <0x94a087c 0x64>;
+   clocks = <_sysin>;
+   clock-names = "cec-clk";
+   interrupts = ;
+   interrupt-names = "cec-irq";
+   pinctrl-names = "default";
+   pinctrl-0 = <_cec0_default>;
+   resets = < STIH407_LPM_SOFTRESET>;
+   st,hdmi-handle = <>;
+   };
};
 };
diff --git a/drivers/staging/media/st-cec/Kconfig 
b/drivers/staging/media/st-cec/Kconfig
index 784d2c6..3072387 100644
--- a/drivers/staging/media/st-cec/Kconfig
+++ b/drivers/staging/media/st-cec/Kconfig
@@ -1,6 +1,7 @@
 config VIDEO_STI_HDMI_CEC
tristate "STMicroelectronics STiH4xx HDMI CEC driver"
depends on VIDEO_DEV && MEDIA_CEC && (ARCH_STI || COMPILE_TEST)
+   select HDMI_NOTIFIERS
---help---
  This is a driver for STIH4xx HDMI CEC interface. It uses the
  generic CEC framework interface.
diff --git a/drivers/staging/media/st-cec/stih-cec.c 
b/drivers/staging/media/st-cec/stih-cec.c
index 2143448..ce94097 100644
--- a/drivers/staging/media/st-cec/stih-cec.c
+++ b/drivers/staging/media/st-cec/stih-cec.c
@@ -10,11 +10,13 @@
  * (at your option) any later version.
  */
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -130,6 +132,7 @@ struct stih_cec {
void __iomem*regs;
int irq;
u32 irq_status;
+   struct hdmi_notifier*notifier;
 };
 
 static int stih_cec_adap_enable(struct cec_adapter *adap, bool enable)
@@ -304,12 

Re: [PATCHv3 RFC 4/4] media: Catch null pipes on pipeline stop

[Sakari Ailus]

Hi Kieran,

On Wed, Dec 14, 2016 at 12:27:37PM +, Kieran Bingham wrote:
> Hi Sakari,
> 
> On 14/12/16 07:28, Sakari Ailus wrote:
> > Hi Kieran,
> > 
> > On Tue, Dec 13, 2016 at 05:59:44PM +, Kieran Bingham wrote:
> >> media_entity_pipeline_stop() can be called through error paths with a
> >> NULL entity pipe object. In this instance, stopping is a no-op, so
> >> simply return without any action
> > 
> > The approach of returning silently is wrong; the streaming count is indeed a
> > count: you have to decrement it the exactly same number of times it's been
> > increased. Code that attempts to call __media_entity_pipeline_stop() on an
> > entity that's not streaming is simply buggy.
> 
> Ok, Thanks for the heads up on where to look, as I suspected we are in
> section B) of my comments below :D
> 
> > I've got a patch here that adds a warning to graph traversal on streaming
> > count being zero. I sent a pull request including that some days ago:
> > 
> > 
> > 
> 
> Excellent, thanks, I've merged your branch into mine, and I'll
> investigate where the error is actually coming from.
> 
> --
> Ok - so I've merged your patches, (and dropped this patch) but they
> don't fire any warning before I hit my null-pointer dereference in
> __media_pipeline_stop(), on the WARN_ON(!pipe->streaming_count);
> 
> So I think this is a case of calling stop on an invalid entity rather
> than an unbalanced start/stop somehow:

Not necessarily. The pipe is set to NULL if the count goes to zero.

This check should be dropped, it's ill-placed anyway: if streaming count is
zero the pipe is expected to be NULL anyway in which case you get a NULL
pointer exception (that you saw there). With the check removed, you should
get the warning instead.

> 
> [  613.830334] vsp1 fea38000.vsp: failed to reset wpf.0
> [  613.838137] PM: resume of devices complete after 124.410 msecs
> [  613.847390] PM: Finishing wakeup.
> [  613.852247] Restarting tasks ... done.
> [  615.864801] ravb e680.ethernet eth0: Link is Up - 100Mbps/Full -
> flow control rx/tx
> [  617.011299] vsp1 fea38000.vsp: failed to reset wpf.0
> [  617.01] vsp1 fea38000.vsp: DRM pipeline stop timeout
> [  617.024649] Unable to handle kernel NULL pointer dereference at
> virtual address 
> [  617.034273] pgd = ff80098c5000
> [  617.039171] [] *pgd=00073fffe003[  617.043336] ,
> *pud=00073fffe003
> , *pmd=[  617.050353]
> [  617.053282] Internal error: Oops: 9605 [#1] PREEMPT SMP
> [  617.060309] Modules linked in:
> [  617.064793] CPU: 1 PID: 683 Comm: kworker/1:2 Not tainted
> 4.9.0-00506-g4d2a939ea654 #350
> [  617.074320] Hardware name: Renesas Salvator-X board based on r8a7795 (DT)
> [  617.082578] Workqueue: events drm_mode_rmfb_work_fn
> [  617.04] task: ffc6fabd2b00 task.stack: ffc6f9d9
> [  617.096246] PC is at __media_pipeline_stop+0x24/0xe8
> [  617.102644] LR is at media_pipeline_stop+0x34/0x48
> 
> 
> 
> [  617.863386] [] __media_pipeline_stop+0x24/0xe8
> [  617.870417] [] media_pipeline_stop+0x34/0x48
> [  617.877272] [] vsp1_du_setup_lif+0x68/0x5a8
> [  617.884047] [] rcar_du_vsp_disable+0x2c/0x38
> [  617.890898] [] rcar_du_crtc_stop+0x198/0x1e8
> [  617.897749] [] rcar_du_crtc_disable+0x20/0x38
> [  617.904683] []
> drm_atomic_helper_commit_modeset_disables+0x1b0/0x3d8
> [  617.913634] [] rcar_du_atomic_complete+0x34/0xc8
> [  617.920828] [] rcar_du_atomic_commit+0x2c0/0x2d0
> [  617.928012] [] drm_atomic_commit+0x5c/0x68
> [  617.934663] [] drm_atomic_helper_set_config+0x90/0xd0
> [  617.942288] [] drm_mode_set_config_internal+0x70/0x100
> [  617.949996] [] drm_crtc_force_disable+0x30/0x40
> [  617.957084] [] drm_framebuffer_remove+0x100/0x128
> [  617.964347] [] drm_mode_rmfb_work_fn+0x48/0x60
> [  617.971352] [] process_one_work+0x1e0/0x738
> [  617.978084] [] worker_thread+0x25c/0x4a0
> [  617.984546] [] kthread+0xd4/0xe8
> [  617.990305] [] ret_from_fork+0x10/0x50
> 
> 
> So, I'll have to schedule some time to investigate this deeper and find
> out where we are calling stop on an invalid entity object.
> 
> I agree that this patch should simply be dropped though, it was more to
> promote a bit of discussion on the area to help me understand what was
> going on, which it has!.
> 
> Thankyou Sakari!
> 
> --
> Regards
> 
> Kieran
> 
> 
> > I think the check here could simply be removed as the check is done for
> > every entity in the pipeline with the above patch.
> > 
> > If there's still a wish to check for the pipe field which should not be
> > written by drivers, it should be done during pipeline traversal so that it
> > applies to all entities in the pipeline, not just where traversal starts.
> > 
> >>
> >> Signed-off-by: Kieran Bingham 
> >> ---
> >>
> >> I've marked this patch as RFC, although if deemed suitable, by 

[PATCH v5] media: Driver for Toshiba et8ek8 5MP sensor

[Pavel Machek]

 
Add driver for et8ek8 sensor, found in Nokia N900 main camera. Can be
used for taking photos in 2.5MP resolution with fcam-dev.

Signed-off-by: Ivaylo Dimitrov 
Signed-off-by: Pavel Machek 

---
From v4 I did cleanups to coding style and removed various oddities.

Exposure value is now in native units, which simplifies the code.

The patch to add device tree bindings was already acked by device tree
people.

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 2669b4b..6d01e15 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -667,6 +667,7 @@ config VIDEO_S5K5BAF
  camera sensor with an embedded SoC image signal processor.
 
 source "drivers/media/i2c/smiapp/Kconfig"
+source "drivers/media/i2c/et8ek8/Kconfig"
 
 config VIDEO_S5C73M3
tristate "Samsung S5C73M3 sensor support"
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 92773b2..5bc7bbe 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -2,6 +2,7 @@ msp3400-objs:=  msp3400-driver.o msp3400-kthreads.o
 obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o
 
 obj-$(CONFIG_VIDEO_SMIAPP) += smiapp/
+obj-$(CONFIG_VIDEO_ET8EK8) += et8ek8/
 obj-$(CONFIG_VIDEO_CX25840) += cx25840/
 obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/
 obj-y  += soc_camera/
diff --git a/drivers/media/i2c/et8ek8/Kconfig b/drivers/media/i2c/et8ek8/Kconfig
new file mode 100644
index 000..1439936
--- /dev/null
+++ b/drivers/media/i2c/et8ek8/Kconfig
@@ -0,0 +1,6 @@
+config VIDEO_ET8EK8
+   tristate "ET8EK8 camera sensor support"
+   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   ---help---
+ This is a driver for the Toshiba ET8EK8 5 MP camera sensor.
+ It is used for example in Nokia N900 (RX-51).
diff --git a/drivers/media/i2c/et8ek8/Makefile 
b/drivers/media/i2c/et8ek8/Makefile
new file mode 100644
index 000..66d1b7d
--- /dev/null
+++ b/drivers/media/i2c/et8ek8/Makefile
@@ -0,0 +1,2 @@
+et8ek8-objs+= et8ek8_mode.o et8ek8_driver.o
+obj-$(CONFIG_VIDEO_ET8EK8) += et8ek8.o
diff --git a/drivers/media/i2c/et8ek8/et8ek8_driver.c 
b/drivers/media/i2c/et8ek8/et8ek8_driver.c
new file mode 100644
index 000..4a638f8
--- /dev/null
+++ b/drivers/media/i2c/et8ek8/et8ek8_driver.c
@@ -0,0 +1,1515 @@
+/*
+ * et8ek8_driver.c
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ *
+ * Contact: Sakari Ailus 
+ *  Tuukka Toivonen 
+ *  Pavel Machek 
+ *
+ * Based on code from Toni Leinonen .
+ *
+ * This driver is based on the Micron MT9T012 camera imager driver
+ * (C) Texas Instruments.
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "et8ek8_reg.h"
+
+#define ET8EK8_NAME"et8ek8"
+#define ET8EK8_PRIV_MEM_SIZE   128
+#define ET8EK8_MAX_MSG 48
+
+struct et8ek8_sensor {
+   struct v4l2_subdev subdev;
+   struct media_pad pad;
+   struct v4l2_mbus_framefmt format;
+   struct gpio_desc *reset;
+   struct regulator *vana;
+   struct clk *ext_clk;
+   u32 xclk_freq;
+
+   u16 version;
+
+   struct v4l2_ctrl_handler ctrl_handler;
+   struct v4l2_ctrl *exposure;
+   struct v4l2_ctrl *pixel_rate;
+   struct et8ek8_reglist *current_reglist;
+
+   u8 priv_mem[ET8EK8_PRIV_MEM_SIZE];
+
+   struct mutex power_lock;
+   int power_count;
+};
+
+#define to_et8ek8_sensor(sd)   container_of(sd, struct et8ek8_sensor, subdev)
+
+enum et8ek8_versions {
+   ET8EK8_REV_1 = 0x0001,
+   ET8EK8_REV_2,
+};
+
+/*
+ * This table describes what should be written to the sensor register
+ * for each gain value. The gain(index in the table) is in terms of
+ * 0.1EV, i.e. 10 indexes in the table give 2 time more gain [0] in
+ * the *analog gain, [1] in the digital gain
+ *
+ * Analog gain [dB] = 20*log10(regvalue/32); 0x20..0x100
+ */
+static struct et8ek8_gain {
+   u16 analog;
+   u16 digital;
+} const et8ek8_gain_table[] = {
+   { 32,0},  /* x1 */
+   { 34,0},
+   { 37,0},
+   { 39,0},
+   { 42,0},
+   { 45,0},
+   { 49,0},
+   { 52,0},
+   { 56,0},
+   { 60,0},
+   { 64,0},  /* x2 */
+   { 69,0},
+   { 74,0},
+   { 79,0},
+ 

Re: [PATCHv3 RFC 4/4] media: Catch null pipes on pipeline stop

[Kieran Bingham]

Hi Sakari,

On 14/12/16 07:28, Sakari Ailus wrote:
> Hi Kieran,
> 
> On Tue, Dec 13, 2016 at 05:59:44PM +, Kieran Bingham wrote:
>> media_entity_pipeline_stop() can be called through error paths with a
>> NULL entity pipe object. In this instance, stopping is a no-op, so
>> simply return without any action
> 
> The approach of returning silently is wrong; the streaming count is indeed a
> count: you have to decrement it the exactly same number of times it's been
> increased. Code that attempts to call __media_entity_pipeline_stop() on an
> entity that's not streaming is simply buggy.

Ok, Thanks for the heads up on where to look, as I suspected we are in
section B) of my comments below :D

> I've got a patch here that adds a warning to graph traversal on streaming
> count being zero. I sent a pull request including that some days ago:
> 
> 
> 

Excellent, thanks, I've merged your branch into mine, and I'll
investigate where the error is actually coming from.

--
Ok - so I've merged your patches, (and dropped this patch) but they
don't fire any warning before I hit my null-pointer dereference in
__media_pipeline_stop(), on the WARN_ON(!pipe->streaming_count);

So I think this is a case of calling stop on an invalid entity rather
than an unbalanced start/stop somehow:

[  613.830334] vsp1 fea38000.vsp: failed to reset wpf.0
[  613.838137] PM: resume of devices complete after 124.410 msecs
[  613.847390] PM: Finishing wakeup.
[  613.852247] Restarting tasks ... done.
[  615.864801] ravb e680.ethernet eth0: Link is Up - 100Mbps/Full -
flow control rx/tx
[  617.011299] vsp1 fea38000.vsp: failed to reset wpf.0
[  617.01] vsp1 fea38000.vsp: DRM pipeline stop timeout
[  617.024649] Unable to handle kernel NULL pointer dereference at
virtual address 
[  617.034273] pgd = ff80098c5000
[  617.039171] [] *pgd=00073fffe003[  617.043336] ,
*pud=00073fffe003
, *pmd=[  617.050353]
[  617.053282] Internal error: Oops: 9605 [#1] PREEMPT SMP
[  617.060309] Modules linked in:
[  617.064793] CPU: 1 PID: 683 Comm: kworker/1:2 Not tainted
4.9.0-00506-g4d2a939ea654 #350
[  617.074320] Hardware name: Renesas Salvator-X board based on r8a7795 (DT)
[  617.082578] Workqueue: events drm_mode_rmfb_work_fn
[  617.04] task: ffc6fabd2b00 task.stack: ffc6f9d9
[  617.096246] PC is at __media_pipeline_stop+0x24/0xe8
[  617.102644] LR is at media_pipeline_stop+0x34/0x48



[  617.863386] [] __media_pipeline_stop+0x24/0xe8
[  617.870417] [] media_pipeline_stop+0x34/0x48
[  617.877272] [] vsp1_du_setup_lif+0x68/0x5a8
[  617.884047] [] rcar_du_vsp_disable+0x2c/0x38
[  617.890898] [] rcar_du_crtc_stop+0x198/0x1e8
[  617.897749] [] rcar_du_crtc_disable+0x20/0x38
[  617.904683] []
drm_atomic_helper_commit_modeset_disables+0x1b0/0x3d8
[  617.913634] [] rcar_du_atomic_complete+0x34/0xc8
[  617.920828] [] rcar_du_atomic_commit+0x2c0/0x2d0
[  617.928012] [] drm_atomic_commit+0x5c/0x68
[  617.934663] [] drm_atomic_helper_set_config+0x90/0xd0
[  617.942288] [] drm_mode_set_config_internal+0x70/0x100
[  617.949996] [] drm_crtc_force_disable+0x30/0x40
[  617.957084] [] drm_framebuffer_remove+0x100/0x128
[  617.964347] [] drm_mode_rmfb_work_fn+0x48/0x60
[  617.971352] [] process_one_work+0x1e0/0x738
[  617.978084] [] worker_thread+0x25c/0x4a0
[  617.984546] [] kthread+0xd4/0xe8
[  617.990305] [] ret_from_fork+0x10/0x50


So, I'll have to schedule some time to investigate this deeper and find
out where we are calling stop on an invalid entity object.

I agree that this patch should simply be dropped though, it was more to
promote a bit of discussion on the area to help me understand what was
going on, which it has!.

Thankyou Sakari!

--
Regards

Kieran


> I think the check here could simply be removed as the check is done for
> every entity in the pipeline with the above patch.
> 
> If there's still a wish to check for the pipe field which should not be
> written by drivers, it should be done during pipeline traversal so that it
> applies to all entities in the pipeline, not just where traversal starts.
> 
>>
>> Signed-off-by: Kieran Bingham 
>> ---
>>
>> I've marked this patch as RFC, although if deemed suitable, by all means
>> integrate it as is.
>>
>> When testing suspend/resume operations on VSP1, I encountered a segfault on 
>> the
>> WARN_ON(!pipe->streaming_count) line, where 'pipe == NULL'. The simple
>> protection fix is to return early in this instance, as this patch does 
>> however:
>>
>> A) Does this early return path warrant a WARN() statement itself, to identify
>> drivers which are incorrectly calling media_entity_pipeline_stop() with an
>> invalid entity, or would this just be noise ...
>>
>> and therefore..
>>
>> B) I also partly assume this patch could simply get NAK'd with a request to 
>> go
>> and 

[PATCH] media: platform: s3c-camif: constify v4l2_subdev_ops structures

[Bhumika Goyal]

Check for v4l2_subdev_ops structures that are only passed as an
argument to the function v4l2_subdev_init. This argument is of type
const, so v4l2_subdev_ops structures having this property can also  be
declared const.
Done using Coccinelle:

@r1 disable optional_qualifier @
identifier i;
position p;
@@
static struct v4l2_subdev_ops i@p = {...};

@ok1@
identifier r1.i;
position p;
@@
v4l2_subdev_init(...,@p)

@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct v4l2_subdev_ops i;

File size before:
   textdata bss dec hex filename
  171711912  20   191034a9f
platform/s3c-camif/camif-capture.o

File size after:
   textdata bss dec hex filename
  172351848  20   191034a9f
platform/s3c-camif/camif-capture.o

Signed-off-by: Bhumika Goyal 
---
 drivers/media/platform/s3c-camif/camif-capture.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/s3c-camif/camif-capture.c 
b/drivers/media/platform/s3c-camif/camif-capture.c
index 0413a86..6125e72 100644
--- a/drivers/media/platform/s3c-camif/camif-capture.c
+++ b/drivers/media/platform/s3c-camif/camif-capture.c
@@ -1488,7 +1488,7 @@ static int s3c_camif_subdev_set_selection(struct 
v4l2_subdev *sd,
.set_fmt = s3c_camif_subdev_set_fmt,
 };
 
-static struct v4l2_subdev_ops s3c_camif_subdev_ops = {
+static const struct v4l2_subdev_ops s3c_camif_subdev_ops = {
.pad = _camif_subdev_pad_ops,
 };
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/6] media/cobalt: use pci_irq_allocate_vectors

[Hans Verkuil]

On 14/12/16 11:47, Christoph Hellwig wrote:

On Wed, Dec 14, 2016 at 11:37:17AM +0100, Hans Verkuil wrote:

Completely forgot this. Is it OK to queue it for 4.11? Or is it blocking
other follow-up work you want to do for 4.10?


My plan was to see if Bjorn would take the patch to do the trivial removal
of pci_enable_msix_exact and pci_enable_msix_range even as a late 4.10 patch
given it's so harmless, but either way there is follow work pending ASAP
so getting it in for 4.10 would be very helpful.



OK, then I'll make a pull request for 4.10 tomorrow.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/6] media/cobalt: use pci_irq_allocate_vectors

[Christoph Hellwig]

On Wed, Dec 14, 2016 at 11:37:17AM +0100, Hans Verkuil wrote:
> Completely forgot this. Is it OK to queue it for 4.11? Or is it blocking
> other follow-up work you want to do for 4.10?

My plan was to see if Bjorn would take the patch to do the trivial removal
of pci_enable_msix_exact and pci_enable_msix_range even as a late 4.10 patch
given it's so harmless, but either way there is follow work pending ASAP
so getting it in for 4.10 would be very helpful.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/6] media/cobalt: use pci_irq_allocate_vectors

[Hans Verkuil]

On 14/12/16 11:29, Christoph Hellwig wrote:

Hi Hans,

just checked the current Linux tree and cobalt still uses the old
pci_enable_msi_range call.  Did you queue this patch up for 4.10?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



Completely forgot this. Is it OK to queue it for 4.11? Or is it blocking
other follow-up work you want to do for 4.10?

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/6] media/cobalt: use pci_irq_allocate_vectors

[Christoph Hellwig]

Hi Hans,

just checked the current Linux tree and cobalt still uses the old
pci_enable_msi_range call.  Did you queue this patch up for 4.10?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Admin Institutionen © 3M 1995-2016. Alla rättigheter reserverade.

[Devaraj Veerasamy, Dr]

Microsoft Office:
Som en del av våra ansträngningar att förbättra din upplevelse över våra 
konsumenttjänster, uppdaterar vi för Microsoft-tjänster och Microsofts 
sekretesspolicy. Vi

vill passa på att meddela dig om dessa uppdateringar. genom att KLICKA 
HÄR, om du för uppdateringar och 
verifiering avbryts underlåtenhet att göra detta e-postkontot.
Vi ber om ursäkt för eventuella besvär detta kan orsaka dig.
Admin Institutionen
© 3M 1995-2016. Alla rättigheter reserverade.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 0/4] Add Mediatek JPEG Decoder

[Rick Chang]

This series of patches provide a v4l2 driver to control Mediatek JPEG decoder
for decoding JPEG image and Motion JPEG bitstream.

changes since v8:
- Fix state error in first bit stream when capture buffer has been stream on.
  This will trigger device run inadvertently.

changes since v7:
- Update MAINTAINERS

changes since v6:
- fix kbuild test fail
- Add patch for MAINTAINERS

changes since v5:
- remove redundant name from struct mtk_jpeg_fmt
- Set state of all buffers to VB2_BUF_STATE_QUEUED if fail in start streaming
- Remove VB2_USERPTR
- Add check for buffer index

changes since v4:
- Change file name of binding documentation
- Revise DT binding documentation
- Revise compatible string

changes since v3:
- Revise DT binding documentation
- Revise compatible string

changes since v2:
- Revise DT binding documentation 

changes since v1:
- Rebase for v4.9-rc1.
- Update Compliance test version and result
- Remove redundant path in Makefile
- Fix potential build error without CONFIG_PM_RUNTIME and CONFIG_PM_SLEEP
- Fix warnings from patch check and smatch check

* Dependency
The patch "arm: dts: mt2701: Add node for JPEG decoder" depends on: 
  CCF "Add clock support for Mediatek MT2701"[1]
  iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]

[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
[2] https://patchwork.kernel.org/patch/9164013/

* Compliance test
v4l2-compliance SHA   : 4ad7174b908a36c4f315e3fe2efa7e2f8a6f375a

Driver Info:
Driver name   : mtk-jpeg decode
Card type : mtk-jpeg decoder
Bus info  : platform:15004000.jpegdec
Driver version: 4.9.0
Capabilities  : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format

Compliance test for device /dev/video3 (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 (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 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)

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 VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK
test Scaling: OK

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

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

Test input 0:


Total: 43, Succeeded: 43, Failed: 0, Warnings: 0

Rick Chang (4):
  dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder
  vcodec: mediatek: Add Mediatek JPEG Decoder Driver
  arm: dts: mt2701: Add node for Mediatek JPEG Decoder
  vcodec: mediatek: Add Maintainers 

[PATCH v9 2/4] vcodec: mediatek: Add Mediatek JPEG Decoder Driver

[Rick Chang]

Add v4l2 driver for Mediatek JPEG Decoder

Signed-off-by: Rick Chang 
Signed-off-by: Minghsiu Tsai 
---
 drivers/media/platform/Kconfig   |   15 +
 drivers/media/platform/Makefile  |2 +
 drivers/media/platform/mtk-jpeg/Makefile |2 +
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c  | 1306 ++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h  |  139 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c|  417 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h|   91 ++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c |  160 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h |   25 +
 drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h   |   58 +
 10 files changed, 2215 insertions(+)
 create mode 100644 drivers/media/platform/mtk-jpeg/Makefile
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 754edbf1..96c9887 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -162,6 +162,21 @@ config VIDEO_CODA
   Coda is a range of video codec IPs that supports
   H.264, MPEG-4, and other video formats.
 
+config VIDEO_MEDIATEK_JPEG
+   tristate "Mediatek JPEG Codec driver"
+   depends on MTK_IOMMU_V1 || COMPILE_TEST
+   depends on VIDEO_DEV && VIDEO_V4L2
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   depends on HAS_DMA
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_MEM2MEM_DEV
+   ---help---
+ Mediatek jpeg codec driver provides HW capability to decode
+ JPEG format
+
+ To compile this driver as a module, choose M here: the
+ module will be called mtk-jpeg
+
 config VIDEO_MEDIATEK_VPU
tristate "Mediatek Video Processor Unit"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index f842933..cf701e3 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -68,3 +68,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VPU)  += mtk-vpu/
 obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)+= mtk-vcodec/
 
 obj-$(CONFIG_VIDEO_MEDIATEK_MDP)   += mtk-mdp/
+
+obj-$(CONFIG_VIDEO_MEDIATEK_JPEG)  += mtk-jpeg/
diff --git a/drivers/media/platform/mtk-jpeg/Makefile 
b/drivers/media/platform/mtk-jpeg/Makefile
new file mode 100644
index 000..b2e6069
--- /dev/null
+++ b/drivers/media/platform/mtk-jpeg/Makefile
@@ -0,0 +1,2 @@
+mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_hw.o mtk_jpeg_parse.o
+obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk_jpeg.o
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
new file mode 100644
index 000..b10183f
--- /dev/null
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -0,0 +1,1306 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Ming Hsiu Tsai 
+ * Rick Chang 
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mtk_jpeg_hw.h"
+#include "mtk_jpeg_core.h"
+#include "mtk_jpeg_parse.h"
+
+static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
+   {
+   .fourcc = V4L2_PIX_FMT_JPEG,
+   .colplanes  = 1,
+   .flags  = MTK_JPEG_FMT_FLAG_DEC_OUTPUT,
+   },
+   {
+   .fourcc = V4L2_PIX_FMT_YUV420M,
+   .h_sample   = {4, 2, 2},
+   .v_sample   = {4, 2, 2},
+   .colplanes  = 3,
+   .h_align= 5,
+   .v_align= 4,
+   .flags  = MTK_JPEG_FMT_FLAG_DEC_CAPTURE,
+   },
+   {
+   .fourcc = V4L2_PIX_FMT_YUV422M,
+   .h_sample   = {4, 2, 2},
+   .v_sample   = {4, 4, 4},
+   .colplanes  = 3,
+   .h_align= 

[PATCH v9 1/4] dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder

[Rick Chang]

Add a DT binding documentation for Mediatek JPEG Decoder of
MT2701 SoC.

Signed-off-by: Rick Chang 
Signed-off-by: Minghsiu Tsai 
Acked-by: Rob Herring 
---
 .../bindings/media/mediatek-jpeg-decoder.txt   | 37 ++
 1 file changed, 37 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt

diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt 
b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
new file mode 100644
index 000..3813947
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
@@ -0,0 +1,37 @@
+* Mediatek JPEG Decoder
+
+Mediatek JPEG Decoder is the JPEG decode hardware present in Mediatek SoCs
+
+Required properties:
+- compatible : must be one of the following string:
+   "mediatek,mt8173-jpgdec"
+   "mediatek,mt2701-jpgdec"
+- reg : physical base address of the jpeg decoder registers and length of
+  memory mapped region.
+- interrupts : interrupt number to the interrupt controller.
+- clocks: device clocks, see
+  Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
+- clock-names: must contain "jpgdec-smi" and "jpgdec".
+- power-domains: a phandle to the power domain, see
+  Documentation/devicetree/bindings/power/power_domain.txt for details.
+- mediatek,larb: must contain the local arbiters in the current Socs, see
+  Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
+  for details.
+- iommus: should point to the respective IOMMU block with master port as
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  for details.
+
+Example:
+   jpegdec: jpegdec@15004000 {
+   compatible = "mediatek,mt2701-jpgdec";
+   reg = <0 0x15004000 0 0x1000>;
+   interrupts = ;
+   clocks =  < CLK_IMG_JPGDEC_SMI>,
+ < CLK_IMG_JPGDEC>;
+   clock-names = "jpgdec-smi",
+ "jpgdec";
+   power-domains = < MT2701_POWER_DOMAIN_ISP>;
+   mediatek,larb = <>;
+   iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
+< MT2701_M4U_PORT_JPGDEC_BSDMA>;
+   };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 3/4] arm: dts: mt2701: Add node for Mediatek JPEG Decoder

[Rick Chang]

Signed-off-by: Rick Chang 
Signed-off-by: Minghsiu Tsai 
---
This patch depends on: 
  CCF "Add clock support for Mediatek MT2701"[1]
  iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]

[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
[2] https://patchwork.kernel.org/patch/9164013/
---
 arch/arm/boot/dts/mt2701.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 8f13c70..4dd5048 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -298,6 +298,20 @@
power-domains = < MT2701_POWER_DOMAIN_ISP>;
};
 
+   jpegdec: jpegdec@15004000 {
+   compatible = "mediatek,mt2701-jpgdec";
+   reg = <0 0x15004000 0 0x1000>;
+   interrupts = ;
+   clocks =  < CLK_IMG_JPGDEC_SMI>,
+ < CLK_IMG_JPGDEC>;
+   clock-names = "jpgdec-smi",
+ "jpgdec";
+   power-domains = < MT2701_POWER_DOMAIN_ISP>;
+   mediatek,larb = <>;
+   iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
+< MT2701_M4U_PORT_JPGDEC_BSDMA>;
+   };
+
vdecsys: syscon@1600 {
compatible = "mediatek,mt2701-vdecsys", "syscon";
reg = <0 0x1600 0 0x1000>;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 4/4] vcodec: mediatek: Add Maintainers entry for Mediatek JPEG driver

[Rick Chang]

Signed-off-by: Rick Chang 
Signed-off-by: Minghsiu Tsai 
Signed-off-by: Bin Liu 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 93e9f42..6f68fb6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7818,6 +7818,13 @@ L:   net...@vger.kernel.org
 S: Maintained
 F: drivers/net/ethernet/mediatek/
 
+MEDIATEK JPEG DRIVER
+M: Rick Chang 
+M: Bin Liu 
+S: Supported
+F: drivers/media/platform/mtk-jpeg/
+F: Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
+
 MEDIATEK MEDIA DRIVER
 M: Tiffany Lin 
 M: Andrew-CT Chen 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html