cron job: media_tree daily build: WARNINGS
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
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->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()
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&id=0ef472a973ebbfc20f2f12769e77a8cfd3612778 Best regards --- Kuninori Morimoto
[PATCH] media: platform: coda: remove variable self assignment
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
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(&video->irqlock, flags); >> + >> + /* Move the pending image to the active hw queue */ >> + if (video->pending) { >> + list_add_tail(&video->pending->queue, &video->irqqueue); >> + video->pending = NULL; >> + } >> + >> + buf = list_first_entry_or_null(&video->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(&buf->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(&mem, 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(&video->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)
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(&ir_raw_handler_lock); > @@ -524,11 +533,15 @@ int ir_raw_event_register(struct rc_dev *dev) > mutex_unlock(&ir_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(&ir_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(&dev->rc_map); > + > + return rc; > +} > + > +static int rc_setup_rx_device(struct rc_dev *
Re: [PATCH v1 1/3] of: base: Provide of_graph_get_port_parent()
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
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
>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
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(&timerlist, sir_timeout, 0); /* get I/O port access and IRQ line */ - if (!request_region(io, 8, KBUILD_MODNAME)) { + if (!devm_request_region(&sir_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(&sir_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(&timerlist); - 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
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
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
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(&sir_ir_driver); } -- 2.9.4
[PATCH 3/5] [media] sir_ir: remove init_port and drop_port functions
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(&hardware_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(&timerlist); -} - -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(&timerlist); return 0; } -- 2.9.4
[PATCH 4/5] [media] sir_ir: remove init_chrdev and init_sir_ir functions
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, &ev); } -static int init_chrdev(void) -{ - rcdev = devm_rc_allocate_device(&sir_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 = &sir_ir_dev->dev; - - return devm_rc_register_device(&sir_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(&sir_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 = &sir_ir_dev->dev; + setup_timer(&timerlist, 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(&sir_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()
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
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
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 = &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, &args); + 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, &mask); + 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 2/3] platform: add video-multiplexer subdevice driver
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(&vmux->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); + if (ret < 0) + goto out; + vmux->active = local->index; + } else
[PATCH v5 1/3] dt-bindings: Add bindings for video-multiplexer device
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 = <&gpio1 15 GPIO_ACTIVE_HIGH>; + }; + + video-mux { + compatible = "video-mux"; + mux-controls = <&mux>; + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + mux_in0: endpoint { + remote-endpoint = <&video_source0_out>; + }; + }; + + port@1 { + reg = <1>; + + mux_in1: endpoint { + remote-endpoint = <&video_source1_out>; + }; + }; + + port@2 { + reg = <2>; + + mux_out: endpoint { + remote-endpoint = <&capture_interface_in>; + }; + }; + }; +}; -- 2.11.0
[PATCH v1 1/3] of: base: Provide of_graph_get_port_parent()
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
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 = &node->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
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
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
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
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
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
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. + +Example: + +video_receiver@70 { +compatible = "adi,adv7482"; +
[PATCH v3 0/2] ADV748x HDMI/Analog video receiver
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
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?
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 patch for this. >> -
Re: [PATCH 0/4] Support for Synopsys DW CSI-2 Host
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
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(&state->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(&state->mutex); > drivers/media/i2c/adv7180.c:int ret = > mutex_lock_interruptible(&state->mutex); > drivers/media/i2c/adv7180.c:int ret = > mutex_lock_interruptible(&state->mutex); > drivers/media/i2c/adv7180.c:int ret = > mutex_lock_interruptible(&state->mutex); > drivers/media/i2c/adv7180.c:ret = mutex_lock_interruptible(&state->mutex); > drivers/media/i2c/adv7180.c:int ret = > mutex_lock_interruptible(&state->mutex); > drivers/media/i2c/adv7180.c:ret = mutex_lock_interruptible(&state->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(&state->afe.sd, state, &adv748x_afe_ops, >> "afe"); >> + >> +/* Ensure that matching is based upon the endpoint fwnodes */ >> +state->afe.sd.fwnode = &ep->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
Re: [PATCH 2/4] media: platform: dwc: Support for DW CSI-2 Host
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
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
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
--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
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
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
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 v4l-stream.c v4l2-ctl-meta.cpp
Re: [PATCH 2/4] media: platform: dwc: Support for DW CSI-2 Host
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