cron job: media_tree daily build: WARNINGS

2017-05-17 Thread 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 May 18 05:00:23 CEST 2017
media-tree git hash:3622d3e77ecef090b5111e3c5423313f11711dfa
media_build git hash:   ab988a3d089232ce9e1aec2f259e947c06983dbc
v4l-utils git hash: d16a17abd1d8d7885ca2f44fb295035278baa89c
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: WARNINGS
linux-git-arm-davinci: WARNINGS
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: WARNINGS
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: WARNINGS
linux-3.12.67-i686: WARNINGS
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: WARNINGS
linux-4.9.26-i686: WARNINGS
linux-4.10.14-i686: WARNINGS
linux-4.11-i686: WARNINGS
linux-4.12-rc1-i686: WARNINGS
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: WARNINGS
linux-3.12.67-x86_64: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9.26-x86_64: WARNINGS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12-rc1-x86_64: WARNINGS
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


[PATCH] Staging: media: fix missing blank line coding style issue in atomisp_tpg.c

2017-05-17 Thread Manny Vindiola
This is a patch to the atomisp_tpg.c file that fixes up a missing
blank line warning found by the checkpatch.pl tool

Signed-off-by: Manny Vindiola 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_tpg.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_tpg.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_tpg.c
index 996d1bd..48b9604 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_tpg.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_tpg.c
@@ -56,6 +56,7 @@ static int tpg_set_fmt(struct v4l2_subdev *sd,
   struct v4l2_subdev_format *format)
 {
struct v4l2_mbus_framefmt *fmt = >format;
+
if (format->pad)
return -EINVAL;
/* only raw8 grbg is supported by TPG */
-- 
2.7.4



Re: [PATCH v1 1/3] of: base: Provide of_graph_get_port_parent()

2017-05-17 Thread Kuninori Morimoto

Hi Kieran

> >> From: Kieran Bingham 
> >>
> >> When handling endpoints, the v4l2 async framework needs to identify the
> >> parent device of a port endpoint.
> >>
> >> Adapt the existing of_graph_get_remote_port_parent() such that a caller
> >> can obtain the parent of a port without parsing the remote-endpoint
> >> first.
> > 
> > A similar patch is already applied as part of the ASoC graph card support.
> > 
> > Rob
> 
> Ah yes, a quick google finds it...
> :  https://patchwork.kernel.org/patch/9658907/
> 
> Surprisingly similar patch ... and a familiar name.
> 
> Morimoto-san - you beat me to it :D !

Interesting.
It was applies today to Mark's (= ALSA SoC Maintainer) branch !
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/?h=topic/of-graph=0ef472a973ebbfc20f2f12769e77a8cfd3612778


Best regards
---
Kuninori Morimoto


[PATCH] media: platform: coda: remove variable self assignment

2017-05-17 Thread Gustavo A. R. Silva
Remove variable self assignment.

Addresses-Coverity-ID: 1408817
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/platform/coda/coda-common.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index d523e99..a6699d8 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -612,7 +612,6 @@ static int coda_try_fmt_vid_cap(struct file *file, void 
*priv,
 
/* The h.264 decoder only returns complete 16x16 macroblocks */
if (codec && codec->src_fourcc == V4L2_PIX_FMT_H264) {
-   f->fmt.pix.width = f->fmt.pix.width;
f->fmt.pix.height = round_up(f->fmt.pix.height, 16);
f->fmt.pix.bytesperline = round_up(f->fmt.pix.width, 16);
f->fmt.pix.sizeimage = f->fmt.pix.bytesperline *
-- 
2.5.0



Re: [PATCH v3 2/2] v4l: vsp1: Provide a writeback video device

2017-05-17 Thread Kieran Bingham
Hi Geert,

On 16/05/17 16:30, Geert Uytterhoeven wrote:
> Hi Kieran,
> 
> On Tue, May 9, 2017 at 6:39 PM, Kieran Bingham
>  wrote:
>> When the VSP1 is used in an active display pipeline, the output of the
>> WPF can supply the LIF entity directly and simultaneously write to
>> memory.
>>
>> Support this functionality in the VSP1 driver, by extending the WPF
>> source pads, and establishing a V4L2 video device node connected to the
>> new source.
>>
>> The source will be able to perform pixel format conversion, but not
>> rescaling, and as such the output from the memory node will always be
>> of the same dimensions as the display output.
>>
>> Signed-off-by: Kieran Bingham 
> 
>> --- a/drivers/media/platform/vsp1/vsp1_video.c
>> +++ b/drivers/media/platform/vsp1/vsp1_video.c
> 
>> @@ -900,6 +901,147 @@ static const struct vb2_ops vsp1_video_queue_qops = {
>> .stop_streaming = vsp1_video_stop_streaming,
>>  };
>>
>> +
>> +/* 
>> -
>> + * videobuf2 queue operations for writeback nodes
>> + */
>> +
>> +static void vsp1_video_wb_process_buffer(struct vsp1_video *video)
>> +{
>> +   struct vsp1_vb2_buffer *buf;
>> +   unsigned long flags;
>> +
>> +   /*
>> +* Writeback uses a running stream, unlike the M2M interface which
>> +* controls a pipeline process manually though the use of
>> +* vsp1_pipeline_run().
>> +*
>> +* Instead writeback will commence at the next frame interval, and 
>> can
>> +* be marked complete at the interval following that. To handle this 
>> we
>> +* store the configured buffer as pending until the next callback.
>> +*
>> +* |||||
>> +*  A   |<-->|
>> +*   B   |<-->|
>> +*C   |<-->| : Only at interrupt C can A be marked done
>> +*/
>> +
>> +   spin_lock_irqsave(>irqlock, flags);
>> +
>> +   /* Move the pending image to the active hw queue */
>> +   if (video->pending) {
>> +   list_add_tail(>pending->queue, >irqqueue);
>> +   video->pending = NULL;
>> +   }
>> +
>> +   buf = list_first_entry_or_null(>wbqueue, struct 
>> vsp1_vb2_buffer,
>> +   queue);
>> +
>> +   if (buf) {
>> +   video->rwpf->mem = buf->mem;
>> +
>> +   /*
>> +* Store this buffer as pending. It will commence at the next
>> +* frame start interrupt
>> +*/
>> +   video->pending = buf;
>> +   list_del(>queue);
>> +   } else {
>> +   /* Disable writeback with no buffer */
>> +   video->rwpf->mem = (struct vsp1_rwpf_memory) { 0 };
> 
> With gcc 4.9.0:
> 
> drivers/media/platform/vsp1/vsp1_video.c: In function
> 'vsp1_video_wb_process_buffer':
> drivers/media/platform/vsp1/vsp1_video.c:942:30: warning: missing
> braces around initializer [-Wmissing-braces]
>video->rwpf->mem = (struct vsp1_rwpf_memory) { 0 };
> 
> -   video->rwpf->mem = (struct vsp1_rwpf_memory) { 0 };
> +   video->rwpf->mem = (struct vsp1_rwpf_memory) { { 0, } };
> 

I've updated these to use a memset(, 0, sizeof(mem)) instead.



>> +static void vsp1_video_wb_stop_streaming(struct vb2_queue *vq)
>> +{
>> +   struct vsp1_video *video = vb2_get_drv_priv(vq);
>> +   struct vsp1_rwpf *rwpf = video->rwpf;
>> +   struct vsp1_pipeline *pipe = rwpf->pipe;
>> +   struct vsp1_vb2_buffer *buffer;
>> +   unsigned long flags;
>> +
>> +   /*
>> +* Disable the completion interrupts, and clear the WPF memory to
>> +* prevent writing out frames
>> +*/
>> +   spin_lock_irqsave(>irqlock, flags);
>> +   video->frame_end = NULL;
>> +   rwpf->mem = (struct vsp1_rwpf_memory) { 0 };
> 
> Likewise:
> 
> -   rwpf->mem = (struct vsp1_rwpf_memory) { 0 };
> +   rwpf->mem = (struct vsp1_rwpf_memory) { { 0, } };
> 

Now memset...

> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> 


Re: [PATCH] rc-core: cleanup rc_register_device (v2)

2017-05-17 Thread Sean Young
Hi David,

On Wed, May 03, 2017 at 12:04:00PM +0200, David Härdeman wrote:
> The device core infrastructure is based on the presumption that
> once a driver calls device_add(), it must be ready to accept
> userspace interaction.
> 
> This requires splitting rc_setup_rx_device() into two functions
> and reorganizing rc_register_device() so that as much work
> as possible is performed before calling device_add().
> 
> Version 2: switch the order in which rc_prepare_rx_device() and
> ir_raw_event_prepare() gets called so that dev->change_protocol()
> gets called before device_add().

I've looked at this patch and I don't see what problem it solves;
what user-space interaction is problematic?


Sean

> 
> Signed-off-by: David Härdeman 
> ---
>  drivers/media/rc/rc-core-priv.h |2 +
>  drivers/media/rc/rc-ir-raw.c|   34 --
>  drivers/media/rc/rc-main.c  |   75 
> +--
>  3 files changed, 73 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/media/rc/rc-core-priv.h b/drivers/media/rc/rc-core-priv.h
> index 0455b273c2fc..b3e7cac2c3ee 100644
> --- a/drivers/media/rc/rc-core-priv.h
> +++ b/drivers/media/rc/rc-core-priv.h
> @@ -263,7 +263,9 @@ int ir_raw_gen_pl(struct ir_raw_event **ev, unsigned int 
> max,
>   * Routines from rc-raw.c to be used internally and by decoders
>   */
>  u64 ir_raw_get_allowed_protocols(void);
> +int ir_raw_event_prepare(struct rc_dev *dev);
>  int ir_raw_event_register(struct rc_dev *dev);
> +void ir_raw_event_free(struct rc_dev *dev);
>  void ir_raw_event_unregister(struct rc_dev *dev);
>  int ir_raw_handler_register(struct ir_raw_handler *ir_raw_handler);
>  void ir_raw_handler_unregister(struct ir_raw_handler *ir_raw_handler);
> diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
> index 90f66dc7c0d7..ae7785c4fbe7 100644
> --- a/drivers/media/rc/rc-ir-raw.c
> +++ b/drivers/media/rc/rc-ir-raw.c
> @@ -486,14 +486,18 @@ EXPORT_SYMBOL(ir_raw_encode_scancode);
>  /*
>   * Used to (un)register raw event clients
>   */
> -int ir_raw_event_register(struct rc_dev *dev)
> +int ir_raw_event_prepare(struct rc_dev *dev)
>  {
> - int rc;
> - struct ir_raw_handler *handler;
> + static bool raw_init; /* 'false' default value, raw decoders loaded? */
>  
>   if (!dev)
>   return -EINVAL;
>  
> + if (!raw_init) {
> + request_module("ir-lirc-codec");
> + raw_init = true;
> + }
> +
>   dev->raw = kzalloc(sizeof(*dev->raw), GFP_KERNEL);
>   if (!dev->raw)
>   return -ENOMEM;
> @@ -502,6 +506,13 @@ int ir_raw_event_register(struct rc_dev *dev)
>   dev->change_protocol = change_protocol;
>   INIT_KFIFO(dev->raw->kfifo);
>  
> + return 0;
> +}
> +
> +int ir_raw_event_register(struct rc_dev *dev)
> +{
> + struct ir_raw_handler *handler;
> +
>   /*
>* raw transmitters do not need any event registration
>* because the event is coming from userspace
> @@ -510,10 +521,8 @@ int ir_raw_event_register(struct rc_dev *dev)
>   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;
> - }
> + if (IS_ERR(dev->raw->thread))
> + return PTR_ERR(dev->raw->thread);
>   }
>  
>   mutex_lock(_raw_handler_lock);
> @@ -524,11 +533,15 @@ int ir_raw_event_register(struct rc_dev *dev)
>   mutex_unlock(_raw_handler_lock);
>  
>   return 0;
> +}
> +
> +void ir_raw_event_free(struct rc_dev *dev)
> +{
> + if (!dev)
> + return;
>  
> -out:
>   kfree(dev->raw);
>   dev->raw = NULL;
> - return rc;
>  }
>  
>  void ir_raw_event_unregister(struct rc_dev *dev)
> @@ -547,8 +560,7 @@ void ir_raw_event_unregister(struct rc_dev *dev)
>   handler->raw_unregister(dev);
>   mutex_unlock(_raw_handler_lock);
>  
> - kfree(dev->raw);
> - dev->raw = NULL;
> + ir_raw_event_free(dev);
>  }
>  
>  /*
> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
> index 802e559cc30e..f3bc9f4e2b96 100644
> --- a/drivers/media/rc/rc-main.c
> +++ b/drivers/media/rc/rc-main.c
> @@ -1663,7 +1663,7 @@ struct rc_dev *devm_rc_allocate_device(struct device 
> *dev,
>  }
>  EXPORT_SYMBOL_GPL(devm_rc_allocate_device);
>  
> -static int rc_setup_rx_device(struct rc_dev *dev)
> +static int rc_prepare_rx_device(struct rc_dev *dev)
>  {
>   int rc;
>   struct rc_map *rc_map;
> @@ -1708,10 +1708,22 @@ static int rc_setup_rx_device(struct rc_dev *dev)
>   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 int rc_setup_rx_device(struct 

Re: [PATCH v1 1/3] of: base: Provide of_graph_get_port_parent()

2017-05-17 Thread Kieran Bingham
On 17/05/17 17:36, Rob Herring wrote:
> On Wed, May 17, 2017 at 10:03 AM, Kieran Bingham  wrote:
>> From: Kieran Bingham 
>>
>> When handling endpoints, the v4l2 async framework needs to identify the
>> parent device of a port endpoint.
>>
>> Adapt the existing of_graph_get_remote_port_parent() such that a caller
>> can obtain the parent of a port without parsing the remote-endpoint
>> first.
> 
> A similar patch is already applied as part of the ASoC graph card support.
> 
> Rob

Ah yes, a quick google finds it...
:  https://patchwork.kernel.org/patch/9658907/

Surprisingly similar patch ... and a familiar name.

Morimoto-san - you beat me to it :D !

Thanks Rob, (And Morimoto!)

--
Kieran


Re: [PATCH v3.1 1/2] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev

2017-05-17 Thread Sakari Ailus
Hi Kieran,

On Wed, May 17, 2017 at 04:38:14PM +0100, Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> Return NULL, if a null entity is parsed for it's v4l2_subdev
> 
> Signed-off-by: Kieran Bingham 
> ---
>  include/media/v4l2-subdev.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> index 5f1669c45642..72d7f28f38dc 100644
> --- a/include/media/v4l2-subdev.h
> +++ b/include/media/v4l2-subdev.h
> @@ -829,7 +829,7 @@ struct v4l2_subdev {
>  };
>  
>  #define media_entity_to_v4l2_subdev(ent) \
> - container_of(ent, struct v4l2_subdev, entity)
> + (ent ? container_of(ent, struct v4l2_subdev, entity) : NULL)
>  #define vdev_to_v4l2_subdev(vdev) \
>   ((struct v4l2_subdev *)video_get_drvdata(vdev))
>  

The problem with this is that ent is now referenced twice. If the ent macro
argument has side effect, this would introduce bugs. It's unlikely, but
worth avoiding. Either use a macro or a function.

I think I'd use function for there's little use for supporting for const and
non-const arguments presumably. A simple static inline function should do.

-- 
Regards,

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


Adding a cropping capability to the atmel-isc driver

2017-05-17 Thread Patrick Doyle
>From reading the discussion of the comparison of the selection API
with the cropping API, (at
https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/selection-api-005.html)
it seems that the cropping API has been deprecated in favor of the
selection API, so if I want to add a cropping capability to the
atmel-isc, I should look at adding support for vidio_g_selection and
vidio_s_selction to the driver.

How do I manage the fact that the video frame size (from which I
should derive TGT_CROP_BOUNDS, TGT_CROP_DEFAULT, and perhaps even
TGT_NATIVE_SIZE) must be specified by atmel-isc's sub device?  Should
I v4l2subdev_call the get_selection function of the underlying sensor?

Is that what is typically done?  Or is there a better way to do this?

--wpd


[PATCH 2/5] [media] sir_ir: use dev managed resources

2017-05-17 Thread Sean Young
Several error paths do not free up resources. This simplifies the code
and fixes this.

Signed-off-by: Sean Young 
---
 drivers/media/rc/sir_ir.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/media/rc/sir_ir.c b/drivers/media/rc/sir_ir.c
index c27d6b4..1ee41adb 100644
--- a/drivers/media/rc/sir_ir.c
+++ b/drivers/media/rc/sir_ir.c
@@ -334,14 +334,13 @@ static int init_port(void)
setup_timer(, sir_timeout, 0);
 
/* get I/O port access and IRQ line */
-   if (!request_region(io, 8, KBUILD_MODNAME)) {
+   if (!devm_request_region(_ir_dev->dev, io, 8, KBUILD_MODNAME)) {
pr_err("i/o port 0x%.4x already in use.\n", io);
return -EBUSY;
}
-   retval = request_irq(irq, sir_interrupt, 0,
-KBUILD_MODNAME, NULL);
+   retval = devm_request_irq(_ir_dev->dev, irq, sir_interrupt, 0,
+ KBUILD_MODNAME, NULL);
if (retval < 0) {
-   release_region(io, 8);
pr_err("IRQ %d already in use.\n", irq);
return retval;
}
@@ -352,9 +351,7 @@ static int init_port(void)
 
 static void drop_port(void)
 {
-   free_irq(irq, NULL);
del_timer_sync();
-   release_region(io, 8);
 }
 
 static int init_sir_ir(void)
-- 
2.9.4



[PATCH 5/5] [media] staging: remove todo and replace with lirc_zilog todo

2017-05-17 Thread Sean Young
The lirc_zilog driver is the last remaining lirc driver, so the existing
todo is no longer relevant.

Signed-off-by: Sean Young 
---
 drivers/staging/media/lirc/TODO| 47 ++
 drivers/staging/media/lirc/TODO.lirc_zilog | 36 ---
 2 files changed, 35 insertions(+), 48 deletions(-)
 delete mode 100644 drivers/staging/media/lirc/TODO.lirc_zilog

diff --git a/drivers/staging/media/lirc/TODO b/drivers/staging/media/lirc/TODO
index cbea5d8..a97800a 100644
--- a/drivers/staging/media/lirc/TODO
+++ b/drivers/staging/media/lirc/TODO
@@ -1,13 +1,36 @@
-- All drivers should either be ported to ir-core, or dropped entirely
-  (see drivers/media/IR/mceusb.c vs. lirc_mceusb.c in lirc cvs for an
-  example of a previously completed port).
-
-- lirc_bt829 uses registers on a Mach64 VT, which has a separate kernel
-  framebuffer driver (atyfb) and userland X driver (mach64).  It can't
-  simply be converted to a normal PCI driver, but ideally it should be
-  coordinated with the other drivers.
-
-Please send patches to:
-Jarod Wilson 
-Greg Kroah-Hartman 
+1. Both ir-kbd-i2c and lirc_zilog provide support for RX events for
+the chips supported by lirc_zilog.  Before moving lirc_zilog out of staging:
+
+a. ir-kbd-i2c needs a module parameter added to allow the user to tell
+   ir-kbd-i2c to ignore Z8 IR units.
+
+b. lirc_zilog should provide Rx key presses to the rc core like ir-kbd-i2c
+   does.
+
+
+2. lirc_zilog module ref-counting need examination.  It has not been
+verified that cdev and lirc_dev will take the proper module references on
+lirc_zilog to prevent removal of lirc_zilog when the /dev/lircN device node
+is open.
+
+(The good news is ref-counting of lirc_zilog internal structures appears to be
+complete.  Testing has shown the cx18 module can be unloaded out from under
+irw + lircd + lirc_dev, with the /dev/lirc0 device node open, with no adverse
+effects.  The cx18 module could then be reloaded and irw properly began
+receiving button presses again and ir_send worked without error.)
+
+
+3. Bridge drivers, if able, should provide a chip reset() callback
+to lirc_zilog via struct IR_i2c_init_data.  cx18 and ivtv already have routines
+to perform Z8 chip resets via GPIO manipulations.  This would allow lirc_zilog
+to bring the chip back to normal when it hangs, in the same places the
+original lirc_pvr150 driver code does.  This is not strictly needed, so it
+is not required to move lirc_zilog out of staging.
+
+Note: Both lirc_zilog and ir-kbd-i2c support the Zilog Z8 for IR, as programmed
+and installed on Hauppauge products.  When working on either module, developers
+must consider at least the following bridge drivers which mention an IR Rx unit
+at address 0x71 (indicative of a Z8):
+
+   ivtv cx18 hdpvr pvrusb2 bt8xx cx88 saa7134
 
diff --git a/drivers/staging/media/lirc/TODO.lirc_zilog 
b/drivers/staging/media/lirc/TODO.lirc_zilog
deleted file mode 100644
index a97800a..000
--- a/drivers/staging/media/lirc/TODO.lirc_zilog
+++ /dev/null
@@ -1,36 +0,0 @@
-1. Both ir-kbd-i2c and lirc_zilog provide support for RX events for
-the chips supported by lirc_zilog.  Before moving lirc_zilog out of staging:
-
-a. ir-kbd-i2c needs a module parameter added to allow the user to tell
-   ir-kbd-i2c to ignore Z8 IR units.
-
-b. lirc_zilog should provide Rx key presses to the rc core like ir-kbd-i2c
-   does.
-
-
-2. lirc_zilog module ref-counting need examination.  It has not been
-verified that cdev and lirc_dev will take the proper module references on
-lirc_zilog to prevent removal of lirc_zilog when the /dev/lircN device node
-is open.
-
-(The good news is ref-counting of lirc_zilog internal structures appears to be
-complete.  Testing has shown the cx18 module can be unloaded out from under
-irw + lircd + lirc_dev, with the /dev/lirc0 device node open, with no adverse
-effects.  The cx18 module could then be reloaded and irw properly began
-receiving button presses again and ir_send worked without error.)
-
-
-3. Bridge drivers, if able, should provide a chip reset() callback
-to lirc_zilog via struct IR_i2c_init_data.  cx18 and ivtv already have routines
-to perform Z8 chip resets via GPIO manipulations.  This would allow lirc_zilog
-to bring the chip back to normal when it hangs, in the same places the
-original lirc_pvr150 driver code does.  This is not strictly needed, so it
-is not required to move lirc_zilog out of staging.
-
-Note: Both lirc_zilog and ir-kbd-i2c support the Zilog Z8 for IR, as programmed
-and installed on Hauppauge products.  When working on either module, developers
-must consider at least the following bridge drivers which mention an IR Rx unit
-at address 0x71 (indicative of a Z8):
-
-   ivtv cx18 hdpvr pvrusb2 bt8xx cx88 saa7134
-
-- 
2.9.4



[PATCH 0/5] sir_ir fixes and update todo

2017-05-17 Thread Sean Young
Just some minor cleanups.

Sean Young (5):
  [media] sir_ir: attempt to free already free_irq
  [media] sir_ir: use dev managed resources
  [media] sir_ir: remove init_port and drop_port functions
  [media] sir_ir: remove init_chrdev and init_sir_ir functions
  [media] staging: remove todo and replace with lirc_zilog todo

 drivers/media/rc/sir_ir.c  | 90 ++
 drivers/staging/media/lirc/TODO| 47 
 drivers/staging/media/lirc/TODO.lirc_zilog | 36 
 3 files changed, 63 insertions(+), 110 deletions(-)
 delete mode 100644 drivers/staging/media/lirc/TODO.lirc_zilog

-- 
2.9.4



[PATCH 1/5] [media] sir_ir: attempt to free already free_irq

2017-05-17 Thread Sean Young
If the probe fails (e.g. port already in use), rmmod causes null deref.

Signed-off-by: Sean Young 
---
 drivers/media/rc/sir_ir.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/sir_ir.c b/drivers/media/rc/sir_ir.c
index 90a5f8f..c27d6b4 100644
--- a/drivers/media/rc/sir_ir.c
+++ b/drivers/media/rc/sir_ir.c
@@ -381,6 +381,8 @@ static int sir_ir_probe(struct platform_device *dev)
 
 static int sir_ir_remove(struct platform_device *dev)
 {
+   drop_hardware();
+   drop_port();
return 0;
 }
 
@@ -421,8 +423,6 @@ static int __init sir_ir_init(void)
 
 static void __exit sir_ir_exit(void)
 {
-   drop_hardware();
-   drop_port();
platform_device_unregister(sir_ir_dev);
platform_driver_unregister(_ir_driver);
 }
-- 
2.9.4



[PATCH 3/5] [media] sir_ir: remove init_port and drop_port functions

2017-05-17 Thread Sean Young
These functions are too short and removing them makes the code more
readable.

Signed-off-by: Sean Young 
---
 drivers/media/rc/sir_ir.c | 27 +--
 1 file changed, 5 insertions(+), 22 deletions(-)

diff --git a/drivers/media/rc/sir_ir.c b/drivers/media/rc/sir_ir.c
index 1ee41adb..fdac570 100644
--- a/drivers/media/rc/sir_ir.c
+++ b/drivers/media/rc/sir_ir.c
@@ -58,11 +58,9 @@ static int init_chrdev(void);
 static irqreturn_t sir_interrupt(int irq, void *dev_id);
 static void send_space(unsigned long len);
 static void send_pulse(unsigned long len);
-static int init_hardware(void);
+static void init_hardware(void);
 static void drop_hardware(void);
 /* Initialisation */
-static int init_port(void);
-static void drop_port(void);
 
 static inline unsigned int sinp(int offset)
 {
@@ -288,7 +286,7 @@ static void send_pulse(unsigned long len)
}
 }
 
-static int init_hardware(void)
+static void init_hardware(void)
 {
unsigned long flags;
 
@@ -310,7 +308,6 @@ static int init_hardware(void)
/* turn on UART */
outb(UART_MCR_DTR | UART_MCR_RTS | UART_MCR_OUT2, io + UART_MCR);
spin_unlock_irqrestore(_lock, flags);
-   return 0;
 }
 
 static void drop_hardware(void)
@@ -327,7 +324,7 @@ static void drop_hardware(void)
 
 /* SECTION: Initialisation */
 
-static int init_port(void)
+static int init_sir_ir(void)
 {
int retval;
 
@@ -346,22 +343,8 @@ static int init_port(void)
}
pr_info("I/O port 0x%.4x, IRQ %d.\n", io, irq);
 
-   return 0;
-}
-
-static void drop_port(void)
-{
-   del_timer_sync();
-}
-
-static int init_sir_ir(void)
-{
-   int retval;
-
-   retval = init_port();
-   if (retval < 0)
-   return retval;
init_hardware();
+
return 0;
 }
 
@@ -379,7 +362,7 @@ static int sir_ir_probe(struct platform_device *dev)
 static int sir_ir_remove(struct platform_device *dev)
 {
drop_hardware();
-   drop_port();
+   del_timer_sync();
return 0;
 }
 
-- 
2.9.4



[PATCH 4/5] [media] sir_ir: remove init_chrdev and init_sir_ir functions

2017-05-17 Thread Sean Young
Inlining these functions into the probe function makes it much
more readable.

Signed-off-by: Sean Young 
---
 drivers/media/rc/sir_ir.c | 58 ++-
 1 file changed, 22 insertions(+), 36 deletions(-)

diff --git a/drivers/media/rc/sir_ir.c b/drivers/media/rc/sir_ir.c
index fdac570..5ee3a23 100644
--- a/drivers/media/rc/sir_ir.c
+++ b/drivers/media/rc/sir_ir.c
@@ -53,7 +53,6 @@ static DEFINE_SPINLOCK(hardware_lock);
 
 /* Communication with user-space */
 static void add_read_queue(int flag, unsigned long val);
-static int init_chrdev(void);
 /* Hardware */
 static irqreturn_t sir_interrupt(int irq, void *dev_id);
 static void send_space(unsigned long len);
@@ -120,28 +119,6 @@ static void add_read_queue(int flag, unsigned long val)
ir_raw_event_store_with_filter(rcdev, );
 }
 
-static int init_chrdev(void)
-{
-   rcdev = devm_rc_allocate_device(_ir_dev->dev, RC_DRIVER_IR_RAW);
-   if (!rcdev)
-   return -ENOMEM;
-
-   rcdev->input_name = "SIR IrDA port";
-   rcdev->input_phys = KBUILD_MODNAME "/input0";
-   rcdev->input_id.bustype = BUS_HOST;
-   rcdev->input_id.vendor = 0x0001;
-   rcdev->input_id.product = 0x0001;
-   rcdev->input_id.version = 0x0100;
-   rcdev->tx_ir = sir_tx_ir;
-   rcdev->allowed_protocols = RC_BIT_ALL_IR_DECODER;
-   rcdev->driver_name = KBUILD_MODNAME;
-   rcdev->map_name = RC_MAP_RC6_MCE;
-   rcdev->timeout = IR_DEFAULT_TIMEOUT;
-   rcdev->dev.parent = _ir_dev->dev;
-
-   return devm_rc_register_device(_ir_dev->dev, rcdev);
-}
-
 /* SECTION: Hardware */
 static void sir_timeout(unsigned long data)
 {
@@ -323,11 +300,27 @@ static void drop_hardware(void)
 }
 
 /* SECTION: Initialisation */
-
-static int init_sir_ir(void)
+static int sir_ir_probe(struct platform_device *dev)
 {
int retval;
 
+   rcdev = devm_rc_allocate_device(_ir_dev->dev, RC_DRIVER_IR_RAW);
+   if (!rcdev)
+   return -ENOMEM;
+
+   rcdev->input_name = "SIR IrDA port";
+   rcdev->input_phys = KBUILD_MODNAME "/input0";
+   rcdev->input_id.bustype = BUS_HOST;
+   rcdev->input_id.vendor = 0x0001;
+   rcdev->input_id.product = 0x0001;
+   rcdev->input_id.version = 0x0100;
+   rcdev->tx_ir = sir_tx_ir;
+   rcdev->allowed_protocols = RC_BIT_ALL_IR_DECODER;
+   rcdev->driver_name = KBUILD_MODNAME;
+   rcdev->map_name = RC_MAP_RC6_MCE;
+   rcdev->timeout = IR_DEFAULT_TIMEOUT;
+   rcdev->dev.parent = _ir_dev->dev;
+
setup_timer(, sir_timeout, 0);
 
/* get I/O port access and IRQ line */
@@ -343,20 +336,13 @@ static int init_sir_ir(void)
}
pr_info("I/O port 0x%.4x, IRQ %d.\n", io, irq);
 
-   init_hardware();
-
-   return 0;
-}
-
-static int sir_ir_probe(struct platform_device *dev)
-{
-   int retval;
-
-   retval = init_chrdev();
+   retval = devm_rc_register_device(_ir_dev->dev, rcdev);
if (retval < 0)
return retval;
 
-   return init_sir_ir();
+   init_hardware();
+
+   return 0;
 }
 
 static int sir_ir_remove(struct platform_device *dev)
-- 
2.9.4



Re: [PATCH v1 1/3] of: base: Provide of_graph_get_port_parent()

2017-05-17 Thread Rob Herring
On Wed, May 17, 2017 at 10:03 AM, Kieran Bingham  wrote:
> From: Kieran Bingham 
>
> When handling endpoints, the v4l2 async framework needs to identify the
> parent device of a port endpoint.
>
> Adapt the existing of_graph_get_remote_port_parent() such that a caller
> can obtain the parent of a port without parsing the remote-endpoint
> first.

A similar patch is already applied as part of the ASoC graph card support.

Rob


[PATCH v3.1 1/2] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev

2017-05-17 Thread Kieran Bingham
From: Kieran Bingham 

Return NULL, if a null entity is parsed for it's v4l2_subdev

Signed-off-by: Kieran Bingham 
---
 include/media/v4l2-subdev.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 5f1669c45642..72d7f28f38dc 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -829,7 +829,7 @@ struct v4l2_subdev {
 };
 
 #define media_entity_to_v4l2_subdev(ent) \
-   container_of(ent, struct v4l2_subdev, entity)
+   (ent ? container_of(ent, struct v4l2_subdev, entity) : NULL)
 #define vdev_to_v4l2_subdev(vdev) \
((struct v4l2_subdev *)video_get_drvdata(vdev))
 
-- 
git-series 0.9.1


[PATCH v5 3/3] [media] platform: video-mux: include temporary mmio-mux support

2017-05-17 Thread Philipp Zabel
As long as the mux framework is not merged, add temporary mmio-mux
support to the video-mux driver itself. This patch is to be reverted
once the "mux: minimal mux subsystem" and "mux: mmio-based syscon mux
controller" patches are merged.

Signed-off-by: Philipp Zabel 
---
This patch allows the video-mux driver to be built and used on i.MX6 before
the mux framework [1][2] is merged. It can be dropped after that happened,
but until then, it should help to avoid a dependency of the i.MX6 capture
drivers on the mux framework, so that the two can be merged independently.

[1] https://patchwork.kernel.org/patch/9725911/
[2] https://patchwork.kernel.org/patch/9725893/
---
 drivers/media/platform/Kconfig |  2 +-
 drivers/media/platform/video-mux.c | 62 ++
 2 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 259c0ff780937..fea1dc05ea7b7 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -76,7 +76,7 @@ config VIDEO_M32R_AR_M64278
 
 config VIDEO_MUX
tristate "Video Multiplexer"
-   depends on OF && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER && 
MULTIPLEXER
+   depends on OF && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER
help
  This driver provides support for N:1 video bus multiplexers.
 
diff --git a/drivers/media/platform/video-mux.c 
b/drivers/media/platform/video-mux.c
index e35ffa18126f3..b997ff881ad24 100644
--- a/drivers/media/platform/video-mux.c
+++ b/drivers/media/platform/video-mux.c
@@ -17,7 +17,12 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_MULTIPLEXER
 #include 
+#else
+#include 
+#include 
+#endif
 #include 
 #include 
 #include 
@@ -29,7 +34,11 @@ struct video_mux {
struct v4l2_subdev subdev;
struct media_pad *pads;
struct v4l2_mbus_framefmt *format_mbus;
+#ifdef CONFIG_MULTIPLEXER
struct mux_control *mux;
+#else
+   struct regmap_field *field;
+#endif
struct mutex lock;
int active;
 };
@@ -70,7 +79,11 @@ static int video_mux_link_setup(struct media_entity *entity,
}
 
dev_dbg(sd->dev, "setting %d active\n", local->index);
+#ifdef CONFIG_MULTIPLEXER
ret = mux_control_try_select(vmux->mux, local->index);
+#else
+   ret = regmap_field_write(vmux->field, local->index);
+#endif
if (ret < 0)
goto out;
vmux->active = local->index;
@@ -79,7 +92,9 @@ static int video_mux_link_setup(struct media_entity *entity,
goto out;
 
dev_dbg(sd->dev, "going inactive\n");
+#ifdef CONFIG_MULTIPLEXER
mux_control_deselect(vmux->mux);
+#endif
vmux->active = -1;
}
 
@@ -193,6 +208,48 @@ static const struct v4l2_subdev_ops video_mux_subdev_ops = 
{
.video = _mux_subdev_video_ops,
 };
 
+#ifndef CONFIG_MULTIPLEXER
+static int video_mux_probe_mmio_mux(struct video_mux *vmux)
+{
+   struct device *dev = vmux->subdev.dev;
+   struct of_phandle_args args;
+   struct reg_field field;
+   struct regmap *regmap;
+   u32 reg, mask;
+   int ret;
+
+   ret = of_parse_phandle_with_args(dev->of_node, "mux-controls",
+"#mux-control-cells", 0, );
+   if (ret)
+   return ret;
+
+   if (!of_device_is_compatible(args.np, "mmio-mux"))
+   return -EINVAL;
+
+   regmap = syscon_node_to_regmap(args.np->parent);
+   if (IS_ERR(regmap))
+   return PTR_ERR(regmap);
+
+   ret = of_property_read_u32_index(args.np, "mux-reg-masks",
+2 * args.args[0], );
+   if (!ret)
+   ret = of_property_read_u32_index(args.np, "mux-reg-masks",
+2 * args.args[0] + 1, );
+   if (ret < 0)
+   return ret;
+
+   field.reg = reg;
+   field.msb = fls(mask) - 1;
+   field.lsb = ffs(mask) - 1;
+
+   vmux->field = devm_regmap_field_alloc(dev, regmap, field);
+   if (IS_ERR(vmux->field))
+   return PTR_ERR(vmux->field);
+
+   return 0;
+}
+#endif
+
 static int video_mux_probe(struct platform_device *pdev)
 {
struct device_node *np = pdev->dev.of_node;
@@ -230,9 +287,14 @@ static int video_mux_probe(struct platform_device *pdev)
return -EINVAL;
}
 
+#ifdef CONFIG_MULTIPLEXER
vmux->mux = devm_mux_control_get(dev, NULL);
if (IS_ERR(vmux->mux)) {
ret = PTR_ERR(vmux->mux);
+#else
+   ret = video_mux_probe_mmio_mux(vmux);
+   if (ret) {
+#endif
if (ret != -EPROBE_DEFER)
dev_err(dev, "Failed to get mux: %d\n", ret);
return ret;
-- 
2.11.0



[PATCH v5 1/3] dt-bindings: Add bindings for video-multiplexer device

2017-05-17 Thread Philipp Zabel
Add bindings documentation for the video multiplexer device.

Signed-off-by: Sascha Hauer 
Signed-off-by: Philipp Zabel 
Signed-off-by: Steve Longerbeam 
Acked-by: Sakari Ailus 
Reviewed-by: Sebastian Reichel 
Acked-by: Rob Herring 
---
No changes since v4 [1].

[1] https://patchwork.kernel.org/patch/9712129/
---
 .../devicetree/bindings/media/video-mux.txt| 60 ++
 1 file changed, 60 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/video-mux.txt

diff --git a/Documentation/devicetree/bindings/media/video-mux.txt 
b/Documentation/devicetree/bindings/media/video-mux.txt
new file mode 100644
index 0..63b9dc913e456
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/video-mux.txt
@@ -0,0 +1,60 @@
+Video Multiplexer
+=
+
+Video multiplexers allow to select between multiple input ports. Video received
+on the active input port is passed through to the output port. Muxes described
+by this binding are controlled by a multiplexer controller that is described by
+the bindings in Documentation/devicetree/bindings/mux/mux-controller.txt
+
+Required properties:
+- compatible : should be "video-mux"
+- mux-controls : mux controller node to use for operating the mux
+- #address-cells: should be <1>
+- #size-cells: should be <0>
+- port@*: at least three port nodes containing endpoints connecting to the
+  source and sink devices according to of_graph bindings. The last port is
+  the output port, all others are inputs.
+
+Optionally, #address-cells, #size-cells, and port nodes can be grouped under a
+ports node as described in Documentation/devicetree/bindings/graph.txt.
+
+Example:
+
+   mux: mux-controller {
+   compatible = "gpio-mux";
+   #mux-control-cells = <0>;
+
+   mux-gpios = < 15 GPIO_ACTIVE_HIGH>;
+   };
+
+   video-mux {
+   compatible = "video-mux";
+   mux-controls = <>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   mux_in0: endpoint {
+   remote-endpoint = <_source0_out>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   mux_in1: endpoint {
+   remote-endpoint = <_source1_out>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   mux_out: endpoint {
+   remote-endpoint = <_interface_in>;
+   };
+   };
+   };
+};
-- 
2.11.0



[PATCH v5 2/3] platform: add video-multiplexer subdevice driver

2017-05-17 Thread Philipp Zabel
This driver can handle SoC internal and external video bus multiplexers,
controlled by mux controllers provided by the mux controller framework,
such as MMIO register bitfields or GPIOs. The subdevice passes through
the mbus configuration of the active input to the output side.

Signed-off-by: Sascha Hauer 
Signed-off-by: Philipp Zabel 
Signed-off-by: Steve Longerbeam 
---
No changes since v4 [1]:

This patch depends on the mux subsystem [2] and on the mmio-mux driver [3]
to work on i.MX6. The follow-up patch will make this usable until the mux
framework is merged.

[1] https://patchwork.kernel.org/patch/9712131/
[2] https://patchwork.kernel.org/patch/9725911/
[3] https://patchwork.kernel.org/patch/9725893/
---
 drivers/media/platform/Kconfig |   6 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/video-mux.c | 295 +
 3 files changed, 303 insertions(+)
 create mode 100644 drivers/media/platform/video-mux.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ac026ee1ca074..259c0ff780937 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -74,6 +74,12 @@ config VIDEO_M32R_AR_M64278
  To compile this driver as a module, choose M here: the
  module will be called arv.
 
+config VIDEO_MUX
+   tristate "Video Multiplexer"
+   depends on OF && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER && 
MULTIPLEXER
+   help
+ This driver provides support for N:1 video bus multiplexers.
+
 config VIDEO_OMAP3
tristate "OMAP 3 Camera support"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 63303d63c64cf..a6363023f981e 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -28,6 +28,8 @@ obj-$(CONFIG_VIDEO_SH_VEU)+= sh_veu.o
 
 obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)+= m2m-deinterlace.o
 
+obj-$(CONFIG_VIDEO_MUX)+= video-mux.o
+
 obj-$(CONFIG_VIDEO_S3C_CAMIF)  += s3c-camif/
 obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG)   += s5p-jpeg/
diff --git a/drivers/media/platform/video-mux.c 
b/drivers/media/platform/video-mux.c
new file mode 100644
index 0..e35ffa18126f3
--- /dev/null
+++ b/drivers/media/platform/video-mux.c
@@ -0,0 +1,295 @@
+/*
+ * video stream multiplexer controlled via mux control
+ *
+ * Copyright (C) 2013 Pengutronix, Sascha Hauer 
+ * Copyright (C) 2016-2017 Pengutronix, Philipp Zabel 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * 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 
+
+struct video_mux {
+   struct v4l2_subdev subdev;
+   struct media_pad *pads;
+   struct v4l2_mbus_framefmt *format_mbus;
+   struct mux_control *mux;
+   struct mutex lock;
+   int active;
+};
+
+static inline struct video_mux *v4l2_subdev_to_video_mux(struct v4l2_subdev 
*sd)
+{
+   return container_of(sd, struct video_mux, subdev);
+}
+
+static int video_mux_link_setup(struct media_entity *entity,
+   const struct media_pad *local,
+   const struct media_pad *remote, u32 flags)
+{
+   struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
+   struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
+   int ret = 0;
+
+   /*
+* The mux state is determined by the enabled sink pad link.
+* Enabling or disabling the source pad link has no effect.
+*/
+   if (local->flags & MEDIA_PAD_FL_SOURCE)
+   return 0;
+
+   dev_dbg(sd->dev, "link setup '%s':%d->'%s':%d[%d]",
+   remote->entity->name, remote->index, local->entity->name,
+   local->index, flags & MEDIA_LNK_FL_ENABLED);
+
+   mutex_lock(>lock);
+
+   if (flags & MEDIA_LNK_FL_ENABLED) {
+   if (vmux->active == local->index)
+   goto out;
+
+   if (vmux->active >= 0) {
+   ret = -EBUSY;
+   goto out;
+   }
+
+   dev_dbg(sd->dev, "setting %d active\n", local->index);
+   ret = mux_control_try_select(vmux->mux, local->index);
+ 

[PATCH v1 1/3] of: base: Provide of_graph_get_port_parent()

2017-05-17 Thread Kieran Bingham
From: Kieran Bingham 

When handling endpoints, the v4l2 async framework needs to identify the
parent device of a port endpoint.

Adapt the existing of_graph_get_remote_port_parent() such that a caller
can obtain the parent of a port without parsing the remote-endpoint
first.

Signed-off-by: Kieran Bingham 
---
 drivers/of/base.c| 30 ++
 include/linux/of_graph.h |  1 +
 2 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index d7c4629a3a2d..f81100500999 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2455,6 +2455,27 @@ struct device_node *of_graph_get_endpoint_by_regs(
 EXPORT_SYMBOL(of_graph_get_endpoint_by_regs);
 
 /**
+ * of_graph_get_port_parent() - get port's parent node
+ * @node: pointer to a local endpoint device_node
+ *
+ * Return: device node associated with endpoint @node.
+ *Use of_node_put() on it when done.
+ */
+struct device_node *of_graph_get_port_parent(struct device_node *node)
+{
+   unsigned int depth;
+
+   /* Walk 3 levels up only if there is 'ports' node. */
+   for (depth = 3; depth && node; depth--) {
+   node = of_get_next_parent(node);
+   if (depth == 2 && of_node_cmp(node->name, "ports"))
+   break;
+   }
+   return node;
+}
+EXPORT_SYMBOL(of_graph_get_port_parent);
+
+/**
  * of_graph_get_remote_port_parent() - get remote port's parent node
  * @node: pointer to a local endpoint device_node
  *
@@ -2465,18 +2486,11 @@ struct device_node *of_graph_get_remote_port_parent(
   const struct device_node *node)
 {
struct device_node *np;
-   unsigned int depth;
 
/* Get remote endpoint node. */
np = of_parse_phandle(node, "remote-endpoint", 0);
 
-   /* Walk 3 levels up only if there is 'ports' node. */
-   for (depth = 3; depth && np; depth--) {
-   np = of_get_next_parent(np);
-   if (depth == 2 && of_node_cmp(np->name, "ports"))
-   break;
-   }
-   return np;
+   return of_graph_get_port_parent(np);
 }
 EXPORT_SYMBOL(of_graph_get_remote_port_parent);
 
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index abdb02eaef06..49bf34880ebc 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -48,6 +48,7 @@ struct device_node *of_graph_get_next_endpoint(const struct 
device_node *parent,
struct device_node *previous);
 struct device_node *of_graph_get_endpoint_by_regs(
const struct device_node *parent, int port_reg, int reg);
+struct device_node *of_graph_get_port_parent(struct device_node *node);
 struct device_node *of_graph_get_remote_port_parent(
const struct device_node *node);
 struct device_node *of_graph_get_remote_port(const struct device_node *node);
-- 
git-series 0.9.1


[PATCH v1 2/3] device property: Add fwnode_graph_get_port_parent

2017-05-17 Thread Kieran Bingham
From: Kieran Bingham 

V4L2 async notifiers can pass the endpoint fwnode rather than the device
fwnode.

Provide a helper to obtain the parent device fwnode without first
parsing the remote-endpoint as per fwnode_graph_get_remote_port_parent.

Signed-off-by: Kieran Bingham 
---
 drivers/base/property.c  | 25 +
 include/linux/property.h |  2 ++
 2 files changed, 27 insertions(+)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index 627ebc9b570d..caf4316fe565 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -1245,6 +1245,31 @@ fwnode_graph_get_next_endpoint(struct fwnode_handle 
*fwnode,
 EXPORT_SYMBOL_GPL(fwnode_graph_get_next_endpoint);
 
 /**
+ * fwnode_graph_get_port_parent - Return device node of a port endpoint
+ * @fwnode: Endpoint firmware node pointing of the port
+ *
+ * Extracts firmware node of the device the @fwnode belongs to.
+ */
+struct fwnode_handle *
+fwnode_graph_get_port_parent(struct fwnode_handle *fwnode)
+{
+   struct fwnode_handle *parent = NULL;
+
+   if (is_of_node(fwnode)) {
+   struct device_node *node;
+
+   node = of_graph_get_port_parent(to_of_node(fwnode));
+   if (node)
+   parent = >fwnode;
+   } else if (is_acpi_node(fwnode)) {
+   parent = acpi_node_get_parent(fwnode);
+   }
+
+   return parent;
+}
+EXPORT_SYMBOL_GPL(fwnode_graph_get_port_parent);
+
+/**
  * fwnode_graph_get_remote_port_parent - Return fwnode of a remote device
  * @fwnode: Endpoint firmware node pointing to the remote endpoint
  *
diff --git a/include/linux/property.h b/include/linux/property.h
index 2f482616a2f2..624129b86c82 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -274,6 +274,8 @@ void *device_get_mac_address(struct device *dev, char 
*addr, int alen);
 
 struct fwnode_handle *fwnode_graph_get_next_endpoint(
struct fwnode_handle *fwnode, struct fwnode_handle *prev);
+struct fwnode_handle *fwnode_graph_get_port_parent(
+   struct fwnode_handle *fwnode);
 struct fwnode_handle *fwnode_graph_get_remote_port_parent(
struct fwnode_handle *fwnode);
 struct fwnode_handle *fwnode_graph_get_remote_port(
-- 
git-series 0.9.1


[PATCH v1 3/3] v4l: async: Match parent devices

2017-05-17 Thread Kieran Bingham
From: Kieran Bingham 

Devices supporting multiple endpoints on a single device node must set
their subdevice fwnode to the endpoint to allow distinct comparisons.

Adapt the match_fwnode call to compare against the provided fwnodes
first, but also to search for a comparison against the parent fwnode.

This allows notifiers to pass the endpoint for comparison and still
support existing subdevices which store their default parent device
node.

Signed-off-by: Kieran Bingham 
---
 drivers/media/v4l2-core/v4l2-async.c | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index e1e181db90f7..65735a5c4350 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -41,14 +41,26 @@ static bool match_devname(struct v4l2_subdev *sd,
return !strcmp(asd->match.device_name.name, dev_name(sd->dev));
 }
 
+static bool match_of(struct device_node *a, struct device_node *b)
+{
+   return !of_node_cmp(of_node_full_name(a), of_node_full_name(b));
+}
+
 static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
 {
+   struct device_node *sdnode;
+   struct fwnode_handle *async_device;
+
+   async_device = fwnode_graph_get_port_parent(asd->match.fwnode.fwnode);
+
if (!is_of_node(sd->fwnode) || !is_of_node(asd->match.fwnode.fwnode))
-   return sd->fwnode == asd->match.fwnode.fwnode;
+   return sd->fwnode == asd->match.fwnode.fwnode ||
+  sd->fwnode == async_device;
+
+   sdnode = to_of_node(sd->fwnode);
 
-   return !of_node_cmp(of_node_full_name(to_of_node(sd->fwnode)),
-   of_node_full_name(
-   to_of_node(asd->match.fwnode.fwnode)));
+   return match_of(sdnode, to_of_node(asd->match.fwnode.fwnode)) ||
+  match_of(sdnode, to_of_node(async_device));
 }
 
 static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
-- 
git-series 0.9.1


[PATCH v1 0/3] v4l: async: Match parent devices

2017-05-17 Thread Kieran Bingham
From: Kieran Bingham 

To support using endpoints in the V4L2 Async subdev framework,
we need to be able to parse a fwnode for the device from the
endpoint.

To enable this, provide an alternative of_graph_get_remote_port_parent
which walks up the port hierarchy without parsing the 'remote-endpoint'
first.

Using this new of_graph_get_port_parent() implementation we can then
add the corresponding fwnode_graph_get_port_parent() call for use
by the async framework.

Kieran Bingham (3):
  of: base: Provide of_graph_get_port_parent()
  device property: Add fwnode_graph_get_port_parent
  v4l: async: Match parent devices

 drivers/base/property.c  | 25 -
 drivers/media/v4l2-core/v4l2-async.c | 20 +++
 drivers/of/base.c| 30 +
 include/linux/of_graph.h |  1 +-
 include/linux/property.h |  2 ++-
 5 files changed, 66 insertions(+), 12 deletions(-)

base-commit: ff0b1f922c42a59bbf8ad675df79441790baed86
-- 
git-series 0.9.1


Re: [PATCH v3 1/2] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev

2017-05-17 Thread Kieran Bingham


On 17/05/17 15:25, Geert Uytterhoeven wrote:
> Hi Kieran,
> 
> On Wed, May 17, 2017 at 4:13 PM, Kieran Bingham  wrote:
>> --- a/include/media/v4l2-subdev.h
>> +++ b/include/media/v4l2-subdev.h
>> @@ -829,7 +829,7 @@ struct v4l2_subdev {
>>  };
>>
>>  #define media_entity_to_v4l2_subdev(ent) \
>> -   container_of(ent, struct v4l2_subdev, entity)
>> +   ent ? container_of(ent, struct v4l2_subdev, entity) : NULL
> 
> Due to the low precedence level of the ternary operator, you want
> to enclose this in parentheses.

Thanks Geert - That's quick to respin ;)

--
Kieran

> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> 


Re: [PATCH v3 1/2] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev

2017-05-17 Thread Geert Uytterhoeven
Hi Kieran,

On Wed, May 17, 2017 at 4:13 PM, Kieran Bingham  wrote:
> --- a/include/media/v4l2-subdev.h
> +++ b/include/media/v4l2-subdev.h
> @@ -829,7 +829,7 @@ struct v4l2_subdev {
>  };
>
>  #define media_entity_to_v4l2_subdev(ent) \
> -   container_of(ent, struct v4l2_subdev, entity)
> +   ent ? container_of(ent, struct v4l2_subdev, entity) : NULL

Due to the low precedence level of the ternary operator, you want
to enclose this in parentheses.

Gr{oetje,eeting}s,

Geert

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

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


[PATCH v3 1/2] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev

2017-05-17 Thread Kieran Bingham
From: Kieran Bingham 

Return NULL, if a null entity is parsed for it's v4l2_subdev

Signed-off-by: Kieran Bingham 
---
 include/media/v4l2-subdev.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 5f1669c45642..d43fa7ca3a92 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -829,7 +829,7 @@ struct v4l2_subdev {
 };
 
 #define media_entity_to_v4l2_subdev(ent) \
-   container_of(ent, struct v4l2_subdev, entity)
+   ent ? container_of(ent, struct v4l2_subdev, entity) : NULL
 #define vdev_to_v4l2_subdev(vdev) \
((struct v4l2_subdev *)video_get_drvdata(vdev))
 
-- 
git-series 0.9.1


[PATCH v3 2/2] media: i2c: adv748x: add adv748x driver

2017-05-17 Thread Kieran Bingham
From: Kieran Bingham 

Provide basic support for the ADV7481 and ADV7482.

The driver is modelled with 2 subdevices to allow simultaneous streaming
from the AFE (Analog front end) and HDMI inputs.

Presently the HDMI is hardcoded to link to the TXA CSI bus, whilst the
AFE is linked to the TXB CSI bus.

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

Signed-off-by: Kieran Bingham 

---

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

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

 Documentation/devicetree/bindings/media/i2c/adv748x.txt |  72 +-
 MAINTAINERS |   6 +-
 drivers/media/i2c/Kconfig   |  10 +-
 drivers/media/i2c/Makefile  |   1 +-
 drivers/media/i2c/adv748x/Makefile  |   7 +-
 drivers/media/i2c/adv748x/adv748x-afe.c | 575 +++-
 drivers/media/i2c/adv748x/adv748x-core.c| 711 +-
 drivers/media/i2c/adv748x/adv748x-csi2.c| 283 -
 drivers/media/i2c/adv748x/adv748x-hdmi.c| 647 -
 drivers/media/i2c/adv748x/adv748x.h | 218 +++-
 10 files changed, 2530 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/adv748x.txt
 create mode 100644 drivers/media/i2c/adv748x/Makefile
 create mode 100644 drivers/media/i2c/adv748x/adv748x-afe.c
 create mode 100644 drivers/media/i2c/adv748x/adv748x-core.c
 create mode 100644 drivers/media/i2c/adv748x/adv748x-csi2.c
 create mode 100644 drivers/media/i2c/adv748x/adv748x-hdmi.c
 create mode 100644 drivers/media/i2c/adv748x/adv748x.h

diff --git a/Documentation/devicetree/bindings/media/i2c/adv748x.txt 
b/Documentation/devicetree/bindings/media/i2c/adv748x.txt
new file mode 100644
index ..98d4600b7d26
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adv748x.txt
@@ -0,0 +1,72 @@
+* Analog Devices ADV748X video decoder with HDMI receiver
+
+The ADV7481, and ADV7482 are multi format video decoders with an integrated
+HDMI receiver. It can output CSI-2 on two independent outputs TXA and TXB from
+three input sources HDMI, analog and TTL.
+
+Required Properties:
+
+  - compatible: Must contain one of the following
+- "adi,adv7481" for the ADV7481
+- "adi,adv7482" for the ADV7482
+
+  - reg: I2C slave address
+
+  - interrupt-names: Should specify the interrupts as "intrq1" and/or "intrq2"
+ "intrq3" is only available on the adv7480 and adv7481
+  - interrupts: Specify the interrupt lines for the ADV748x
+
+The device node must contain one 'port' child node per device input and output
+port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes
+are numbered as follows.
+
+  Name  TypePort
+
+  HDMI  sink0
+  AIN1  sink1
+  AIN2  sink2
+  AIN3  sink3
+  AIN4  sink4
+  AIN5  sink5
+  AIN6  sink6
+  AIN7  sink7
+  AIN8  sink8
+  TTL   sink9
+  TXA   source  10
+  TXB   source  11
+
+The digital output port node must contain at least one source endpoint.
+

[PATCH v3 0/2] ADV748x HDMI/Analog video receiver

2017-05-17 Thread Kieran Bingham
From: Kieran Bingham 

This is a driver for the Analog Devices ADV748x device, and follows on from a
previous posting by Niklas Söderlund [0] of an earlier incarnation of this
driver.

Aside from a few bug fixes, and considerable refactoring this driver:
 - is refactored to multiple object files
 - defines multiple sub devices for the output paths.
 - has independent controls for both HDMI and Analog video paths

 - Specifies 'endpoint' matching instead of 'device' in async framework

These patches are based up on Niklas' pending RVin work [1] and Sakari's fwnode
series [2]

This version sees lots of review comments addressed from previous reviews, and
the removal of the async notifiers to register the AFE/HDMI entities (which was
functional - but overkill)

Updates to the core to support matching will be provided in a separate series

ADV748x
===
The ADV7481 and ADV7482 support two video pipelines which can run independently
of each other, with each pipeline terminating in a CSI-2 output: TXA (4-Lane)
and TXB (1-Lane)

The ADV7480 (Not yet included here), ADV7481, and ADV7482 are all derivatives,
with the following features

Analog   HDMI  MHL  4-Lane  1-Lane
  In  In CSI CSI
 ADV7480   XX X
 ADV7481  XXX X   X
 ADV7482  XX  X   X

Implementation
==

This RFC creates 4 entities. AFE (CVBS/Analog In), HDMI, TXA and TXB.  At probe
time, the DT is parsed to identify the endpoints for each of these nodes, and
those are used for async matching of the CSI2 (TXA/TXB) entities in the master
driver. The HDMI and AFE entities are then registered after a successful
registration of both the CSI2 entities.

(Known) Future Todo's
=

Further potential development areas include:
 - ADV7480 Support (No AFE)
 - MHL support (Not present on ADV7482)
 - EDID support
 - CEC Support
 - Configurable I2C addressing
 - Interrupt handling for format changes and hotplug detect.

However, this driver and series is functional without the above, though if
there are mandatory areas which block mainline integration please let me know
and I will prioritise that in development.

References
==
[0] http://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg05196.html
[1] https://git.ragnatech.se/linux rcar-vin-elinux-v7
[2] https://www.mail-archive.com/linux-media@vger.kernel.org/msg111332.html

Kieran Bingham (2):
  v4l: subdev: tolerate null in media_entity_to_v4l2_subdev
  media: i2c: adv748x: add adv748x driver

 Documentation/devicetree/bindings/media/i2c/adv748x.txt |  72 +-
 MAINTAINERS |   6 +-
 drivers/media/i2c/Kconfig   |  10 +-
 drivers/media/i2c/Makefile  |   1 +-
 drivers/media/i2c/adv748x/Makefile  |   7 +-
 drivers/media/i2c/adv748x/adv748x-afe.c | 575 +++-
 drivers/media/i2c/adv748x/adv748x-core.c| 711 +-
 drivers/media/i2c/adv748x/adv748x-csi2.c| 283 -
 drivers/media/i2c/adv748x/adv748x-hdmi.c| 647 -
 drivers/media/i2c/adv748x/adv748x.h | 218 +++-
 include/media/v4l2-subdev.h |   2 +-
 11 files changed, 2531 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/adv748x.txt
 create mode 100644 drivers/media/i2c/adv748x/Makefile
 create mode 100644 drivers/media/i2c/adv748x/adv748x-afe.c
 create mode 100644 drivers/media/i2c/adv748x/adv748x-core.c
 create mode 100644 drivers/media/i2c/adv748x/adv748x-csi2.c
 create mode 100644 drivers/media/i2c/adv748x/adv748x-hdmi.c
 create mode 100644 drivers/media/i2c/adv748x/adv748x.h

base-commit: 4db2a777a71b51a864caae16385b60b4b7e9f992
-- 
git-series 0.9.1


[GIT PULL FOR v4.12] Hang in sir_ir

2017-05-17 Thread Sean Young
Hi Mauro,

0day found an issue which causes an infinite loop in the interrupt handler.

Thanks,

Sean

The following changes since commit 3622d3e77ecef090b5111e3c5423313f11711dfa:

  [media] ov2640: print error if devm_*_optional*() fails (2017-04-25 07:08:21 
-0300)

are available in the git repository at:

  git://linuxtv.org/syoung/media_tree.git for-v4.12e

for you to fetch changes up to cb01c5786d5dca202d020b86fcdfda05bfd576e8:

  [media] sir_ir: infinite loop in interrupt handler (2017-05-17 14:37:07 +0100)


Sean Young (1):
  [media] sir_ir: infinite loop in interrupt handler

 drivers/media/rc/sir_ir.c | 6 ++
 1 file changed, 6 insertions(+)


Re: Sensor sub-device - what are the mandatory ops?

2017-05-17 Thread Dave Stevenson
Hi Sakari .
Thanks for taking the time to respond.

On 17 May 2017 at 00:04, Sakari Ailus  wrote:
> Hi Dave,
>
> On Thu, May 11, 2017 at 04:51:27PM +0100, Dave Stevenson wrote:
>> Hi All.
>>
>> As previously discussed, I'm working on a V4L2 driver for the
>> CSI-2/CCP2 receiver on BCM283x, as used on Raspberry Pi.
>> It's a relatively simple hardware block that writes received data into
>> SDRAM, and only accepts connection from one "sensor" sub device, so no
>> need to involve the media controller API. (The peripheral can do
>> cropping and format conversion between the CSI-2 Bayer formats too,
>> but I'm ignoring those for now, and even so they don't really need
>> media controller).
>
> If the sensor exposes multiple sub-devices or you have e.g. a more complex
> TV tuner with internal data routing such as some of the ADV chips, you
> won't be able to support them in this model.
>
> On the other hand, using Media controller brings some extra complexity and
> requires generally a lot more decision making and configuration from the
> user space as well. (This is something that needs to be more or less
> resolved over time but how long it'll take I can't say.)
>
> Just FYI.

Thanks for the warning.
I was aware that I might be limiting the use of some drivers, but I'm
also aware that the majority of users on the Pi are not "power users",
and if it takes much more than opening /dev/video0 then they'll lose
interest.
The CSI-2 sensor drivers that I've looked at haven't had vast
complexity. As and when any get added we can look at adding in media
controller support.

>> I was previously advised by Hans to take am437x as a base, and that
>> seems to have worked pretty well when combined with some of the ti-vpe
>> driver too. It's up and running, although with some rough edges. I'm
>> hoping to sort an RFC in a week or so.
>>
>> My main issue is determining what calls are mandatory to be supported
>> by the sensor sub-device drivers that attach to the CSI-2 receiver.
>> I'm either taking the wrong approach, or there seem to be missing ops
>> in the drivers I'm trying to use. The set of devices I have available
>> are Omnivision OV5647, Toshiba TC358743 HDMI to CSI2 bridge, and
>> ADV7282-M analogue video to CSI-2 decoder.
>>
>> The TC358743 driver doesn't support:
>> - enum_mbus_code to report the supported formats
>> (MEDIA_BUS_FMT_RGB888_1X24 and MEDIA_BUS_FMT_UYVY8_1X16)
>
> Without knowing any details on the chip nor its driver, if it supports the
> two, it'd be reasonable that it also provided such enumeration of mbus
> codes.

It does support both formats, so, I'll submit that patch.

>> - s_power. The docs [1] say the device must be powered up before
>> calling v4l2_subdev_video_ops->s_stream, but is s_power optional so
>> ENOIOCTLCMD is not to be considered a failure?
>
> Correct.

Easy enough to handle.

>> - enum_frame_size
>> and doesn't set the state->mbus_fmt_code until after
>> v4l2_async_register_subdev. A connected subdevice calling get_fmt
>> during the notifier.complete callback gets a code of 0.
>>
>> The OV5647 driver doesn't support:
>> - set_fmt or get_fmt. I can't see any code that returns the 640x480
>> sensor resolution that is listed in the commit text.
>
> get_fmt is essential. Without that link validation can't work. If the driver
> doesn't support setting the format, the get_fmt callback can be used for
> set_fmt as well.

Another patch to submit then.
Using get_fmt in the absence of set_fmt feels a little nasty, but
probably a sensible precaution.

>> - g_mbus_config, so no information on the number of CSI-2 lanes in use
>> beyond that in DT. Do we just assume all lines specified in DT are in
>> use in this situation? In which case should the driver be checking
>> that the configured number of lanes matches the register set it will
>> request over I2C, as a mismatch will result in it not working?
>
> The assumption is that all lanes are in use. g_mbus_config is from SoC
> camera and, well, frankly should not look like how it looks now. It's used
> by a couple of drivers and needs to be replaced by more generic and
> informative means to let the receiver know the frame structure the
> transmitter is about to start sending.

So it is what it is, but isn't mandatory.
Dropping it is likely to cause issues with the TC358743. It receives
HDMI data in at whatever rate is required for the format, stores it in
a small FIFO, and when a trigger point is reached in the FIFO it is
read out over CSI2 with N data lanes at a defined rate. Under or over
flow that FIFO and you get corrupted images. It dynamically sets how
many data lanes to use to roughly match the HDMI and CSI2 data rates
without causing FIFO issues. (I am getting issues with some
resolution/framerate/pixelformat combinations, so something seems a
little off. That's for a different discussion though).

I'll update my driver to take the DT config, and update if
g_mbus_config is supported. I'll drop my OV5647 

Re: [PATCH 0/4] Support for Synopsys DW CSI-2 Host

2017-05-17 Thread Mauro Carvalho Chehab
Em Wed, 17 May 2017 00:48:17 +0300
Sakari Ailus  escreveu:

> Hi Ramiro,
> 
> On Tue, Mar 07, 2017 at 02:37:47PM +, Ramiro Oliveira wrote:
> > This patchset adds support for the DW CSI-2 Host and also for a video
> > device associated with it. 
> > 
> > The first 2 patches are only for the DW CSI-2 Host and the last 2 are for
> > the video device.
> > 
> > Although this patchset is named as v1 there were already two patchsets
> > previous to this one, but with a different name: "Add support for the DW
> > IP Prototyping Kits for MIPI CSI-2 Host".  
> 
> Could you briefly describe the hardware and which IP blocks you have there?
> Three devices to capture images from CSI-2 bus seems a lot.

Just a quick notice here... calling the driver as "dwc" sounds confusing,
we have already a "dwc2" and a "dwc3" driver (and an OOT "otg-dwc" driver
at RPi tree).

Ok, those are USB drivers, but, as we had some patches for it (or due
to it) at linux-media, I would prefer if you could use some other name
here, to avoid confusion :-)

Thanks,
Mauro


Re: [RFC PATCH v2 1/4] media: i2c: adv748x: add adv748x driver

2017-05-17 Thread Kieran Bingham
Hi Sakari,

Ok - V3 is now closer :)

I'm just trying to do a first spin of adding fwnode_graph_get_port_parent(),
then I can post a v3 series.



On 16/05/17 23:26, Sakari Ailus wrote:
> Hi Kieran,
> 
> On Tue, May 16, 2017 at 01:56:05PM +0100, Kieran Bingham wrote:
> ...
>> +static int adv748x_afe_g_input_status(struct v4l2_subdev *sd, u32 
>> *status)
>> +{
>> +struct adv748x_state *state = adv748x_afe_to_state(sd);
>> +int ret;
>> +
>> +ret = mutex_lock_interruptible(>mutex);
>
> I wonder if this is necessary. Do you expect the mutex to be taken for
> extended periods of time?

 It looks like the only other adv* driver to take a lock here is the 7180.
 Perhaps that is where the heritage of this code derived from.

 I don't think the locking should be held for a long time anywhere, but I 
 will
 try to go through and consider all the locking throughout the code base.

 At the moment I think anything that calls adv748x_afe_status() should be 
 locked
 to ensure serialisation through adv748x_afe_read_ro_map().
>>>
>>> I meant whether you need the "_interruptible" part. It's quite a bit of
>>> repeating error handling that looks mostly unnecessary.
>>>
>>
>> Aha - I see what you mean now...
>>
>> Most of these use I2C transactions though, so that would be our source of 
>> any delay.
>>
>> If it's acceptable to expect an I2C bus to never hang, or if the I2C 
>> subsystem
>> can handle that, then we can chop the interruptible ... but I'm not sure I2C 
>> bus
>> transactions are guaranteed like that ? Don't things like clock stretching, 
>> and
>> unreliable hardware leave us vulnerable there...
> 
> $ git grep mutex_lock_interruptible -- drivers/media/i2c/
> drivers/media/i2c/adv7180.c:int err = 
> mutex_lock_interruptible(>mutex);
> drivers/media/i2c/adv7180.c:int ret = 
> mutex_lock_interruptible(>mutex);
> drivers/media/i2c/adv7180.c:int ret = 
> mutex_lock_interruptible(>mutex);
> drivers/media/i2c/adv7180.c:int ret = 
> mutex_lock_interruptible(>mutex);
> drivers/media/i2c/adv7180.c:ret = mutex_lock_interruptible(>mutex);
> drivers/media/i2c/adv7180.c:int ret = 
> mutex_lock_interruptible(>mutex);
> drivers/media/i2c/adv7180.c:ret = mutex_lock_interruptible(>mutex);
> 
> That's all.
> 

Ok - I've stripped out the _interruptibles, and adapted the control lock to use
the state lock - that cleaned up the controls too :)

> ...
> 
>> +int adv748x_afe_probe(struct adv748x_state *state, struct device_node 
>> *ep)
>> +{
>> +int ret;
>> +unsigned int i;
>> +
>> +state->afe.streaming = false;
>> +state->afe.curr_norm = V4L2_STD_ALL;
>> +
>> +adv748x_subdev_init(>afe.sd, state, _afe_ops, 
>> "afe");
>> +
>> +/* Ensure that matching is based upon the endpoint fwnodes */
>> +state->afe.sd.fwnode = >fwnode;
>
> I wonder if you really need to convert all users of async matching to use
> endpoints --- could you opportunistically peek if the device node matches,
> just in case? You can't have an accidental positive match anyway.
>
> So, the match is now for plain fwnode pointers, and it would be:
>
> return async->fwnode == fwnode ||
>   port_parent(parent(async->fwnode)) == fwnode ||
>   async->fwnode == port_parent(parent(fwnode));


 If we adapt the core to match against endpoint comparisons and device node
 comparisons then yes we wouldn't have to adapt everything, I.e. we 
 wouldn't have
 to change all the async devices - but we would have to adapt all the 
 bus/bridge
 drivers (those who perform the v4l2_async_notifier_register() call) as 
 they must
 register their notifier against an endpoint if they are to ever be able to
 connect to an ADV748x or other device which will rely upon multiple 
 endpoints.
>>>
>>> If there really is a need to, we can add a new framework helper function for
>>> that --- as I think Niklas proposed. I'm not really sure it should be really
>>> needed though; e.g. the omap3isp driver does without that.
>>>
>>
>> I'm afraid I don't understand what you mean by omap3isp doing without ...
> 
> Sorry. I think I lost you somewhere --- I meant matching in the few drivers
> that compare fwnodes. That'd break as a result unless the matching was
> updated accordingly.
> 
> It'd be nice to remove that matching as well though but I think it'd be
> safer not to.
> 

Ah ok - The bit I missed then is that there are *other* matches elsewhere...

>>
>> In omap3isp/isp.c: isp_fwnodes_parse() the async notifier is registered 
>> looking
>> at the endpoints parent fwnode:
>>
>>  isd->asd.match.fwnode.fwnode =
>>  fwnode_graph_get_remote_port_parent(fwnode);
>>
>> This would therefore not support ADV748x ... (it wouldn't know which TX/CSI
>> 

Re: [PATCH 2/4] media: platform: dwc: Support for DW CSI-2 Host

2017-05-17 Thread Sakari Ailus

Hi Hans,

On Wed, May 17, 2017 at 09:00:59AM +0200, Hans Verkuil wrote:
> Hi Sakari,
> 
> Can you comment on this? You are much more a CSI sensor expert than I am.

Sure. Thanks for the ping.

> 
> On 16/05/17 20:18, Ramiro Oliveira wrote:
> > Hi Hans,
> > 
> > Thank you very much for your feedback.
> > 
> > On 5/8/2017 11:38 AM, Hans Verkuil wrote:
> >> Hi Ramiro,
> >>
> >> My sincere apologies for the long delay in reviewing this. The good news 
> >> is that
> >> I should have more time for reviews going forward, so I hope I'll be a lot 
> >> quicker
> >> in the future.
> >>
> >> On 03/07/2017 03:37 PM, Ramiro Oliveira wrote:
> 
> 
> 
> >>> + if (mf->width == bt->width && mf->height == bt->width) {
> >>
> >> This is way too generic. There are many preset timings that have the same
> >> width and height but different blanking periods.
> >>
> >> I am really not sure how this is supposed to work. If you want to support
> >> HDMI here, then I would expect to see support for the s_dv_timings op and 
> >> friends
> >> in this driver. And I don't see support for that in the host driver either.
> >>
> >> Is this a generic csi driver, or specific for hdmi? Or supposed to handle 
> >> both?
> > 
> > This is a generic CSI driver.
> > 
> >>
> >> Can you give some background and clarification of this?
> > 
> > This piece of code might seem strange but I'm just using it fill our 
> > controller
> > timing configuration.
> > 
> > I don't have any specific requirements, but they should match, more or 
> > less, the
> > sensor configurations, so I decided to re-use the HDMI blanking values, 
> > since,
> > usually, they match with the sensor configurations
> > 
> > So, my intention is to check if there is any HDMI preset that matches the
> > required width and height, and then use the blanking values to configure our
> > controller. I know this might not be very common, and I'm open to use 
> > different
> > approaches, but from my perspective it seems to work fine.

What kind of timing information do you need to configure the receiver?

If you pick a random HDMI configuration it can't be expected to match an
unrelated configuration of a sensor. Generally CSI-2 bus frequency, number
of lanes and horizontal and vertical blanking are enough to calculate what
the hardware needs regarding timing. The received image size is necessary
for other purposes.

Do you see that you'd need something else in addition to that?

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


[PATCH v1 5/5] configure.ac: fix build of v4l-utils on uclinux

2017-05-17 Thread Hugues Fruchet
Build of v4-utils is conditional to "linux_os=yes" which was
not set in case of uclinux, fix this.

Signed-off-by: Hugues Fruchet 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 26dc18d..1af7408 100644
--- a/configure.ac
+++ b/configure.ac
@@ -150,7 +150,7 @@ AC_HEADER_MAJOR
 
 # Check host os
 case "$host_os" in
-  linux*)
+  *linux*)
 linux_os="yes"
 ;;
   *freebsd*)
-- 
1.9.1



[PATCH v1 2/5] configure.ac: revisit v4l2-ctl/compliance using libv4l variable naming

2017-05-17 Thread Hugues Fruchet
USE_V4L2_CTL and USE_V4L2_COMPLIANCE are used to trig the fact that
v4l2-ctl and v4l2-compliance are using libv4l2, change namings to not
confuse with overall v4l2-ctl/compliance utilities building.

Signed-off-by: Hugues Fruchet 
---
 configure.ac | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index e8b86a5..0ce5082 100644
--- a/configure.ac
+++ b/configure.ac
@@ -471,8 +471,8 @@ AM_COND_IF([WITH_QV4L2], [USE_QV4L2="yes"], 
[USE_QV4L2="no"])
 AM_COND_IF([WITH_V4L_PLUGINS], [USE_V4L_PLUGINS="yes"], [USE_V4L_PLUGINS="no"])
 AM_COND_IF([WITH_V4L_WRAPPERS], [USE_V4L_WRAPPERS="yes"], 
[USE_V4L_WRAPPERS="no"])
 AM_COND_IF([WITH_GCONV], [USE_GCONV="yes"], [USE_GCONV="no"])
-AM_COND_IF([WITH_V4L2_CTL_LIBV4L], [USE_V4L2_CTL="yes"], [USE_V4L2_CTL="no"])
-AM_COND_IF([WITH_V4L2_COMPLIANCE_LIBV4L], [USE_V4L2_COMPLIANCE="yes"], 
[USE_V4L2_COMPLIANCE="no"])
+AM_COND_IF([WITH_V4L2_CTL_LIBV4L], [USE_V4L2_CTL_LIBV4L="yes"], 
[USE_V4L2_CTL_LIBV4L="no"])
+AM_COND_IF([WITH_V4L2_COMPLIANCE_LIBV4L], [USE_V4L2_COMPLIANCE_LIBV4L="yes"], 
[USE_V4L2_COMPLIANCE_LIBV4L="no"])
 AS_IF([test "x$alsa_pkgconfig" = "xtrue"], [USE_ALSA="yes"], [USE_ALSA="no"])
 
 AC_OUTPUT
@@ -507,6 +507,6 @@ compile time options summary
 dvbv5-daemon   : $USE_DVBV5_REMOTE
 v4lutils   : $USE_V4LUTILS
 qv4l2  : $USE_QV4L2
-v4l2-ctl uses libv4l   : $USE_V4L2_CTL
-v4l2-compliance uses libv4l: $USE_V4L2_COMPLIANCE
+v4l2-ctl uses libv4l   : $USE_V4L2_CTL_LIBV4L
+v4l2-compliance uses libv4l: $USE_V4L2_COMPLIANCE_LIBV4L
 EOF
-- 
1.9.1



[PATCH v1 3/5] configure.ac: revisit --disable-libv4l to --disable-dyn-libv4l

2017-05-17 Thread Hugues Fruchet
--disable-libv4l is not disabling libv4l compilation, but only
dynamic library support of libv4l libraries.

Signed-off-by: Hugues Fruchet 
---
 configure.ac  | 16 
 lib/libv4l1/Makefile.am   |  2 +-
 lib/libv4l2/Makefile.am   |  2 +-
 lib/libv4l2rds/Makefile.am|  2 +-
 lib/libv4lconvert/Makefile.am |  2 +-
 5 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/configure.ac b/configure.ac
index 0ce5082..033d13c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -372,11 +372,11 @@ AC_ARG_ENABLE(libdvbv5,
esac]
 )
 
-AC_ARG_ENABLE(libv4l,
-  AS_HELP_STRING([--disable-libv4l], [disable dynamic libv4l compilation]),
+AC_ARG_ENABLE(dyn-libv4l,
+  AS_HELP_STRING([--disable-dyn-libv4l], [disable dynamic libv4l support]),
   [case "${enableval}" in
  yes | no ) ;;
- *) AC_MSG_ERROR(bad value ${enableval} for --disable-libv4l) ;;
+ *) AC_MSG_ERROR(bad value ${enableval} for --disable-dyn-libv4l) ;;
esac]
 )
 
@@ -436,11 +436,11 @@ AC_SEARCH_LIBS([backtrace], [execinfo], [
 AM_CONDITIONAL([WITH_LIBDVBV5], [test x$enable_libdvbv5  != xno -a 
x$have_libudev = xyes])
 AM_CONDITIONAL([WITH_DVBV5_REMOTE], [test x$enable_libdvbv5  != xno -a 
x$have_libudev = xyes -a x$have_pthread = xyes])
 
-AM_CONDITIONAL([WITH_LIBV4L],   [test x$enable_libv4l!= xno])
+AM_CONDITIONAL([WITH_DYN_LIBV4L],   [test x$enable_dyn_libv4l != xno])
 AM_CONDITIONAL([WITH_V4LUTILS],[test x$enable_v4l_utils != xno -a 
x$linux_os = xyes])
 AM_CONDITIONAL([WITH_QV4L2],   [test x${qt_pkgconfig} = xtrue -a 
x$enable_qv4l2 != xno])
-AM_CONDITIONAL([WITH_V4L_PLUGINS],  [test x$enable_libv4l != xno -a 
x$enable_shared != xno])
-AM_CONDITIONAL([WITH_V4L_WRAPPERS], [test x$enable_libv4l != xno -a 
x$enable_shared != xno])
+AM_CONDITIONAL([WITH_V4L_PLUGINS],  [test x$enable_dyn_libv4l != xno -a 
x$enable_shared != xno])
+AM_CONDITIONAL([WITH_V4L_WRAPPERS], [test x$enable_dyn_libv4l != xno -a 
x$enable_shared != xno])
 AM_CONDITIONAL([WITH_QTGL],[test x${qt_pkgconfig_gl} = xtrue])
 AM_CONDITIONAL([WITH_GCONV],[test x${enable_gconv} = xyes])
 AM_CONDITIONAL([WITH_V4L2_CTL_LIBV4L], [test x${enable_v4l2_ctl_libv4l} != 
xno])
@@ -465,7 +465,7 @@ AM_COND_IF([WITH_LIBDVBV5], [USE_LIBDVBV5="yes"], 
[USE_LIBDVBV5="no"])
 AM_COND_IF([WITH_DVBV5_REMOTE], [USE_DVBV5_REMOTE="yes"
 AC_DEFINE([HAVE_DVBV5_REMOTE], [1], [Usage of 
DVBv5 remote enabled])],
[USE_DVBV5_REMOTE="no"])
-AM_COND_IF([WITH_LIBV4L], [USE_LIBV4L="yes"], [USE_LIBV4L="no"])
+AM_COND_IF([WITH_DYN_LIBV4L], [USE_DYN_LIBV4L="yes"], [USE_DYN_LIBV4L="no"])
 AM_COND_IF([WITH_V4LUTILS], [USE_V4LUTILS="yes"], [USE_V4LUTILS="no"])
 AM_COND_IF([WITH_QV4L2], [USE_QV4L2="yes"], [USE_QV4L2="no"])
 AM_COND_IF([WITH_V4L_PLUGINS], [USE_V4L_PLUGINS="yes"], [USE_V4L_PLUGINS="no"])
@@ -500,7 +500,7 @@ compile time options summary
 
 gconv  : $USE_GCONV
 
-dynamic libv4l : $USE_LIBV4L
+dynamic libv4l : $USE_DYN_LIBV4L
 v4l_plugins: $USE_V4L_PLUGINS
 v4l_wrappers   : $USE_V4L_WRAPPERS
 libdvbv5   : $USE_LIBDVBV5
diff --git a/lib/libv4l1/Makefile.am b/lib/libv4l1/Makefile.am
index f768eaa..42cb3db 100644
--- a/lib/libv4l1/Makefile.am
+++ b/lib/libv4l1/Makefile.am
@@ -1,4 +1,4 @@
-if WITH_LIBV4L
+if WITH_DYN_LIBV4L
 lib_LTLIBRARIES = libv4l1.la
 include_HEADERS = ../include/libv4l1.h ../include/libv4l1-videodev.h
 pkgconfig_DATA = libv4l1.pc
diff --git a/lib/libv4l2/Makefile.am b/lib/libv4l2/Makefile.am
index 1314a99..811c45c 100644
--- a/lib/libv4l2/Makefile.am
+++ b/lib/libv4l2/Makefile.am
@@ -1,4 +1,4 @@
-if WITH_LIBV4L
+if WITH_DYN_LIBV4L
 lib_LTLIBRARIES = libv4l2.la
 include_HEADERS = ../include/libv4l2.h ../include/libv4l-plugin.h
 pkgconfig_DATA = libv4l2.pc
diff --git a/lib/libv4l2rds/Makefile.am b/lib/libv4l2rds/Makefile.am
index 4f23a3f..73fdd3e 100644
--- a/lib/libv4l2rds/Makefile.am
+++ b/lib/libv4l2rds/Makefile.am
@@ -1,4 +1,4 @@
-if WITH_LIBV4L
+if WITH_DYN_LIBV4L
 lib_LTLIBRARIES = libv4l2rds.la
 include_HEADERS = ../include/libv4l2rds.h
 pkgconfig_DATA = libv4l2rds.pc
diff --git a/lib/libv4lconvert/Makefile.am b/lib/libv4lconvert/Makefile.am
index 5c8a1cf..4f332fa 100644
--- a/lib/libv4lconvert/Makefile.am
+++ b/lib/libv4lconvert/Makefile.am
@@ -1,4 +1,4 @@
-if WITH_LIBV4L
+if WITH_DYN_LIBV4L
 lib_LTLIBRARIES = libv4lconvert.la
 libv4lconvertpriv_PROGRAMS = ov511-decomp ov518-decomp
 include_HEADERS = ../include/libv4lconvert.h
-- 
1.9.1



[PATCH v1 1/5] configure.ac: fix wrong summary if --disable-v4l2-ctl-stream-to

2017-05-17 Thread Hugues Fruchet
If --disable-v4l2-ctl-stream-to option is set, summary shows:
v4l2-ctl uses libv4l   : no
due to USE_V4L2_CTL set to "no", fix this.

Signed-off-by: Hugues Fruchet 
---
 configure.ac | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 36b0c71..e8b86a5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -472,7 +472,6 @@ AM_COND_IF([WITH_V4L_PLUGINS], [USE_V4L_PLUGINS="yes"], 
[USE_V4L_PLUGINS="no"])
 AM_COND_IF([WITH_V4L_WRAPPERS], [USE_V4L_WRAPPERS="yes"], 
[USE_V4L_WRAPPERS="no"])
 AM_COND_IF([WITH_GCONV], [USE_GCONV="yes"], [USE_GCONV="no"])
 AM_COND_IF([WITH_V4L2_CTL_LIBV4L], [USE_V4L2_CTL="yes"], [USE_V4L2_CTL="no"])
-AM_COND_IF([WITH_V4L2_CTL_STREAM_TO], [USE_V4L2_CTL="yes"], 
[USE_V4L2_CTL="no"])
 AM_COND_IF([WITH_V4L2_COMPLIANCE_LIBV4L], [USE_V4L2_COMPLIANCE="yes"], 
[USE_V4L2_COMPLIANCE="no"])
 AS_IF([test "x$alsa_pkgconfig" = "xtrue"], [USE_ALSA="yes"], [USE_ALSA="no"])
 
-- 
1.9.1



[PATCH v1 0/5] v4l-utils build on buildroot with no-MMU devices

2017-05-17 Thread Hugues Fruchet
In order to pass V4L2 compliancy tests on STM32 devices -which are MMU less-,
compliancy utilities -at least v4l2-compliance and cec-compliance- have to be 
built.
Unfortunately the support of shared libraries (dlopen()) and fork() is a must
have in v4l-utils.
This have been fixed by:
- revisiting --disable-libv4l to --disable-dyn-libv4l; first naming
  suggests that libv4l will not be built which is not the case
  (only the dynamic support of libv4l is disabled in this case)
- for the sake of coherency, configure.ac variables USE_V4L2_CTL & 
USE_V4L2_COMPLIANCE
  have been changed to USE_V4L2_CTL_LIBV4L & USE_V4L2_COMPLIANCE_LIBV4L
  for the same reason.
- adding an option --disable-libv4l to really not build libv4l
  - libraries which require dlopen() and libv4lconvert which
require fork(). For the sake of simplicity, the entire lib/ folder
is not built with this option.
  - The contrib/ folder is also not built in that case because of its dependency
on libv4l/libv4lconvert libraries.
  - The utility rds-ctl is also not built for the same reason.
  - configure.ac is also fixed to not trig error on dlopen() missing, further
test on "enable_shared" will automatically disable the build of libv4l
and items which have libv4l has dependency.
- fix configure.ac to allow build of v4l-utils utilities with uclinux.


This have been tested on buildroot build system with following patch
to let throw build even if no MMU and no shared libraries support
(those patches will be upstreamed on buildroot side):
package/libv4l/Config.in
config BR2_PACKAGE_LIBV4L
bool "libv4l"
depends on BR2_TOOLCHAIN_HAS_THREADS
-   depends on BR2_USE_MMU # fork()
-   depends on !BR2_STATIC_LIBS # dlopen()

config BR2_PACKAGE_LIBV4L_UTILS
bool "v4l-utils tools"
-   depends on BR2_ENABLE_LOCALE


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


Hugues Fruchet (5):
  configure.ac: fix wrong summary if --disable-v4l2-ctl-stream-to
  configure.ac: revisit v4l2-ctl/compliance using libv4l variable naming
  configure.ac: revisit --disable-libv4l to --disable-dyn-libv4l
  configure.ac: add --disable-libv4l option
  configure.ac: fix build of v4l-utils on uclinux

 Makefile.am   | 11 +--
 configure.ac  | 33 +
 lib/libv4l1/Makefile.am   |  2 +-
 lib/libv4l2/Makefile.am   |  2 +-
 lib/libv4l2rds/Makefile.am|  2 +-
 lib/libv4lconvert/Makefile.am |  2 +-
 utils/Makefile.am |  6 +-
 utils/v4l2-compliance/Makefile.am |  4 
 utils/v4l2-ctl/Makefile.am|  4 
 9 files changed, 47 insertions(+), 19 deletions(-)

-- 
1.9.1



[PATCH v1 4/5] configure.ac: add --disable-libv4l option

2017-05-17 Thread Hugues Fruchet
Add an option to disable libv4l libraries and plugins compilation.
If system is not supporting dynamic shared libraries, this option
is automatically set.
dlopen() is no more a mandatory dependency (warning is kept).
lib/ and contrib/ folders are no more built with this option set
because of libv4l dependency.
utils/ folder is still built with this options set but without
rds-ctl because of its libv4l dependency.
v4l2-compliance and v4l2-ctl are also built but without any links
on libv4l and libv4lconvert libraries.

Signed-off-by: Hugues Fruchet 
---
 Makefile.am   | 11 +--
 configure.ac  | 12 +++-
 utils/Makefile.am |  6 +-
 utils/v4l2-compliance/Makefile.am |  4 
 utils/v4l2-ctl/Makefile.am|  4 
 5 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index e603472..07c3ef8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,10 +1,17 @@
 AUTOMAKE_OPTIONS = foreign
 ACLOCAL_AMFLAGS = -I m4
 
-SUBDIRS = v4l-utils-po libdvbv5-po lib
+SUBDIRS = v4l-utils-po libdvbv5-po
+
+if WITH_LIBV4L
+SUBDIRS += lib
+endif
 
 if WITH_V4LUTILS
-SUBDIRS += utils contrib
+SUBDIRS += utils
+if WITH_LIBV4L
+SUBDIRS += contrib
+endif
 endif
 
 EXTRA_DIST = android-config.h bootstrap.sh doxygen_libdvbv5.cfg include 
COPYING.libv4l \
diff --git a/configure.ac b/configure.ac
index 033d13c..26dc18d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -286,7 +286,7 @@ dl_saved_libs=$LIBS
   AC_SEARCH_LIBS([dlopen],
  [dl],
  [test "$ac_cv_search_dlopen" = "none required" || 
DLOPEN_LIBS=$ac_cv_search_dlopen],
- [AC_MSG_ERROR([unable to find the dlopen() function])])
+ [AC_MSG_WARN([unable to find the dlopen() function])])
   AC_SUBST([DLOPEN_LIBS])
 LIBS=$dl_saved_libs
 
@@ -372,6 +372,14 @@ AC_ARG_ENABLE(libdvbv5,
esac]
 )
 
+AC_ARG_ENABLE(libv4l,
+  AS_HELP_STRING([--disable-libv4l], [disable libv4l compilation]),
+  [case "${enableval}" in
+ yes | no ) ;;
+ *) AC_MSG_ERROR(bad value ${enableval} for --disable-libv4l) ;;
+   esac]
+)
+
 AC_ARG_ENABLE(dyn-libv4l,
   AS_HELP_STRING([--disable-dyn-libv4l], [disable dynamic libv4l support]),
   [case "${enableval}" in
@@ -437,6 +445,7 @@ AM_CONDITIONAL([WITH_LIBDVBV5], [test x$enable_libdvbv5 
 != xno -a x$have_li
 AM_CONDITIONAL([WITH_DVBV5_REMOTE], [test x$enable_libdvbv5  != xno -a 
x$have_libudev = xyes -a x$have_pthread = xyes])
 
 AM_CONDITIONAL([WITH_DYN_LIBV4L],   [test x$enable_dyn_libv4l != xno])
+AM_CONDITIONAL([WITH_LIBV4L],   [test x$enable_libv4l!= xno -a 
x$enable_shared != xno])
 AM_CONDITIONAL([WITH_V4LUTILS],[test x$enable_v4l_utils != xno -a 
x$linux_os = xyes])
 AM_CONDITIONAL([WITH_QV4L2],   [test x${qt_pkgconfig} = xtrue -a 
x$enable_qv4l2 != xno])
 AM_CONDITIONAL([WITH_V4L_PLUGINS],  [test x$enable_dyn_libv4l != xno -a 
x$enable_shared != xno])
@@ -465,6 +474,7 @@ AM_COND_IF([WITH_LIBDVBV5], [USE_LIBDVBV5="yes"], 
[USE_LIBDVBV5="no"])
 AM_COND_IF([WITH_DVBV5_REMOTE], [USE_DVBV5_REMOTE="yes"
 AC_DEFINE([HAVE_DVBV5_REMOTE], [1], [Usage of 
DVBv5 remote enabled])],
[USE_DVBV5_REMOTE="no"])
+AM_COND_IF([WITH_LIBV4L], [USE_LIBV4L="yes"], [USE_LIBV4L="no"])
 AM_COND_IF([WITH_DYN_LIBV4L], [USE_DYN_LIBV4L="yes"], [USE_DYN_LIBV4L="no"])
 AM_COND_IF([WITH_V4LUTILS], [USE_V4LUTILS="yes"], [USE_V4LUTILS="no"])
 AM_COND_IF([WITH_QV4L2], [USE_QV4L2="yes"], [USE_QV4L2="no"])
diff --git a/utils/Makefile.am b/utils/Makefile.am
index d7708cc..ce710c2 100644
--- a/utils/Makefile.am
+++ b/utils/Makefile.am
@@ -13,8 +13,12 @@ SUBDIRS = \
v4l2-sysfs-path \
cec-ctl \
cec-compliance \
-   cec-follower \
+   cec-follower
+
+if WITH_LIBV4L
+SUBDIRS += \
rds-ctl
+endif
 
 if WITH_LIBDVBV5
 SUBDIRS += \
diff --git a/utils/v4l2-compliance/Makefile.am 
b/utils/v4l2-compliance/Makefile.am
index 58bad86..0671fda 100644
--- a/utils/v4l2-compliance/Makefile.am
+++ b/utils/v4l2-compliance/Makefile.am
@@ -7,12 +7,16 @@ v4l2_compliance_SOURCES = v4l2-compliance.cpp 
v4l2-test-debug.cpp v4l2-test-inpu
v4l2-test-codecs.cpp v4l2-test-colors.cpp v4l2-compliance.h
 v4l2_compliance_CPPFLAGS = -I$(top_srcdir)/utils/common
 
+if WITH_LIBV4L
 if WITH_V4L2_COMPLIANCE_LIBV4L
 v4l2_compliance_LDADD = ../../lib/libv4l2/libv4l2.la 
../../lib/libv4lconvert/libv4lconvert.la -lrt -lpthread
 else
 v4l2_compliance_LDADD = -lrt -lpthread
 DEFS += -DNO_LIBV4L2
 endif
+else
+DEFS += -DNO_LIBV4L2
+endif
 
 EXTRA_DIST = Android.mk fixme.txt v4l2-compliance.1
 
diff --git a/utils/v4l2-ctl/Makefile.am b/utils/v4l2-ctl/Makefile.am
index 83fa49a..cae4e74 100644
--- a/utils/v4l2-ctl/Makefile.am
+++ b/utils/v4l2-ctl/Makefile.am
@@ -9,11 +9,15 @@ v4l2_ctl_SOURCES = v4l2-ctl.cpp v4l2-ctl.h 
v4l2-ctl-common.cpp v4l2-ctl-tuner.cp
v4l2-tpg-colors.c v4l2-tpg-core.c 

Re: [PATCH 2/4] media: platform: dwc: Support for DW CSI-2 Host

2017-05-17 Thread Hans Verkuil
Hi Sakari,

Can you comment on this? You are much more a CSI sensor expert than I am.

On 16/05/17 20:18, Ramiro Oliveira wrote:
> Hi Hans,
> 
> Thank you very much for your feedback.
> 
> On 5/8/2017 11:38 AM, Hans Verkuil wrote:
>> Hi Ramiro,
>>
>> My sincere apologies for the long delay in reviewing this. The good news is 
>> that
>> I should have more time for reviews going forward, so I hope I'll be a lot 
>> quicker
>> in the future.
>>
>> On 03/07/2017 03:37 PM, Ramiro Oliveira wrote:



>>> +   if (mf->width == bt->width && mf->height == bt->width) {
>>
>> This is way too generic. There are many preset timings that have the same
>> width and height but different blanking periods.
>>
>> I am really not sure how this is supposed to work. If you want to support
>> HDMI here, then I would expect to see support for the s_dv_timings op and 
>> friends
>> in this driver. And I don't see support for that in the host driver either.
>>
>> Is this a generic csi driver, or specific for hdmi? Or supposed to handle 
>> both?
> 
> This is a generic CSI driver.
> 
>>
>> Can you give some background and clarification of this?
> 
> This piece of code might seem strange but I'm just using it fill our 
> controller
> timing configuration.
> 
> I don't have any specific requirements, but they should match, more or less, 
> the
> sensor configurations, so I decided to re-use the HDMI blanking values, since,
> usually, they match with the sensor configurations
> 
> So, my intention is to check if there is any HDMI preset that matches the
> required width and height, and then use the blanking values to configure our
> controller. I know this might not be very common, and I'm open to use 
> different
> approaches, but from my perspective it seems to work fine.

Regards,

Hans