cron job: media_tree daily build: OK

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: Wed Mar 9 04:00:19 CET 2016 git branch: test git hash: de08b5a8be0df1eb7c796b0fe6b30cf1d03d14a6 gcc

[PATCH] Revert "[media] au0828: use v4l2_mc_create_media_graph()"

This reverts commit 9822f4173f84cb7c592edb5e1478b7903f69d018. This commit breaks au0828_enable_handler() logic to find the tuner. Audio, Video, and Digital applications are broken and fail to start streaming with tuner busy error even when tuner is free. Signed-off-by: Shuah Khan

Re: i.mx6 camera interface (CSI) and mainline kernel

On 03/07/2016 08:19 AM, Tim Harvey wrote: > On Thu, Mar 3, 2016 at 9:45 AM, Steve Longerbeam > wrote: >> Hi Philippe, >> >> On 03/03/2016 12:36 AM, Philippe De Muyter wrote: >>> Just to be sure : do you mean https://github.com/slongerbeam/mediatree.git >>> or

Re: HVR-850 2040:b140 fails to initialize

> Appreciate some advice. Return it and get an HVR-950q. This has been a known issue for more than 5 years and nobody's gotten around to fixing it (largely because of limitations inside the V4L2 framework). Devin (a.k.a. the guy who added the original support for the HVR-850). -- Devin J.

HVR-850 2040:b140 fails to initialize

I am trying to above device with kernel 4.1.13-100.fc21.x86_64. kernel: usb 2-2: New USB device found, idVendor=2040, idProduct=b140 kernel: usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 kernel: usb 2-2: Product: Hauppauge Device kernel: usb 2-2: Manufacturer: Hauppauge

[RFC 4/7] drivers/media/pci/zoran: avoid fragile snprintf use

Appending to a string by doing snprintf(buf, bufsize, "%s...", buf, ...) is not guaranteed to work. Signed-off-by: Rasmus Villemoes --- drivers/media/pci/zoran/videocodec.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git

[RFC 6/7] [media] ati_remote: avoid fragile snprintf use

Passing overlapping source and destination to snprintf is fragile. Replace with a single (mostly) equivalent call. If one wants to preserve the space preceding udev->product whether or not there was a manufacturer, just remove udev->manufacturer from the && expression. Signed-off-by: Rasmus

Re: [PATCH 4/7] scatterlist: add sg_alloc_table_from_buf() helper

Hi Laurent, On Tue, 08 Mar 2016 18:51:49 +0200 Laurent Pinchart wrote: > Hi Boris, > > Thank you for the patch. > > On Tuesday 08 March 2016 12:15:12 Boris Brezillon wrote: > > sg_alloc_table_from_buf() provides an easy solution to create an sg_table > >

Re: [PATCH 4/7] scatterlist: add sg_alloc_table_from_buf() helper

Hi Boris, Thank you for the patch. On Tuesday 08 March 2016 12:15:12 Boris Brezillon wrote: > sg_alloc_table_from_buf() provides an easy solution to create an sg_table > from a virtual address pointer. This function takes care of dealing with > vmallocated buffers, buffer alignment, or DMA

Re: Question regarding internal webcams of tablet devices

Hi, On Tue, Mar 08, 2016 at 04:21:01PM +0100, Dennis Wassenberg wrote: > However, at first there is the need to get a driver for the camera IO > host controller PCI device. Is there anybody how knows a driver for that > pci device or known if there will be a driver for that in the future? Is >

Question regarding internal webcams of tablet devices

Hi, I have a couple of questions regarding support of internal webcams of new/current generation of tablet devices. For example Lenovo X1, HP Elite x2 1012 G1. There are internal webcams which are not connected via USB. In fact they are connected via the (00:14.3 Multimedia controller [0480]:

Re: Kernel docs: muddying the waters a bit

Em Tue, 8 Mar 2016 10:39:22 -0300 Mauro Carvalho Chehab escreveu: > Em Tue, 08 Mar 2016 05:13:13 -0700 > Dan Allen escreveu: > > > On Tue, Mar 8, 2016 at 4:29 AM, Mauro Carvalho Chehab < > > mche...@osg.samsung.com> wrote: > > > > > pandoc

Re: [PATCH 5/7] mtd: provide helper to prepare buffers for DMA operations

On Tue, 8 Mar 2016 19:48:53 +0530 Vinod Koul wrote: > On Tue, Mar 08, 2016 at 12:15:13PM +0100, Boris Brezillon wrote: > > > > +#ifdef CONFIG_HAS_DMA > > Shouldn't this be CONFIG_DMA_ENGINE as you are preparing these descriptors > for DMA transfer? > Nope, scatterlist

Re: Build regressions/improvements in v4.5-rc7

Hi, On Mon, Mar 07, 2016 at 10:01:09AM +0100, Geert Uytterhoeven wrote: > On Mon, Mar 7, 2016 at 9:55 AM, Geert Uytterhoeven > wrote: > > JFYI, when comparing v4.5-rc7[1] to v4.5-rc6[3], the summaries are: > > - build errors: +8/-7 > + error: debugfs.c: undefined

[PATCH] [media] em28xx_dvb: add support for PLEX PX-BCUD (ISDB-S usb dongle)

Hi Mauro, Akihiro, I added em28xx_dvb to support for PLEX PX-BCUD (ISDB-S usb dongle). Please move forward with this patch if there is no problem. Or something wrong, please advise me what I should do. PX-BCUD has the following components: USB interface: Empia EM28178 Demodulator: Toshiba

Re: [PATCH 5/7] mtd: provide helper to prepare buffers for DMA operations

On Tue, Mar 08, 2016 at 12:15:13PM +0100, Boris Brezillon wrote: > > +#ifdef CONFIG_HAS_DMA Shouldn't this be CONFIG_DMA_ENGINE as you are preparing these descriptors for DMA transfer? -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message

Re: Kernel docs: muddying the waters a bit

On Tue, 08 Mar 2016, Dan Allen wrote: > That's not entirely true. First, you can pre-split at the source level > using includes and generate output for each of the masters. That's what I > tend to do and it works really well since these are logical split points. I need to

Re: Kernel docs: muddying the waters a bit

Em Tue, 08 Mar 2016 05:13:13 -0700 Dan Allen escreveu: > On Tue, Mar 8, 2016 at 4:29 AM, Mauro Carvalho Chehab < > mche...@osg.samsung.com> wrote: > > > pandoc did a really crap job on the conversion. To convert this > > into something useful, we'll need to spend a lot of

Re: Kernel docs: muddying the waters a bit

Em Tue, 08 Mar 2016 05:09:40 -0700 Dan Allen escreveu: > Jani wrote: > > > there was no support for chunked, or split > > to chapters, HTML, and the single page result was simply way too big. > > > > That's not entirely true. First, you can pre-split at the source level >

Re: Kernel docs: muddying the waters a bit

Em Tue, 08 Mar 2016 11:49:35 +0200 Jani Nikula escreveu: > On Tue, 08 Mar 2016, Dan Allen wrote: > > One of the key goals of the Asciidoctor project is to be able to directly > > produce a wide variety of outputs from the same source (without DocBook).

[PATCH 0/7] mtd: nand: sunxi: add support for DMA operations

Hello, This patch series aims at adding support for DMA assisted operations to the sunxi_nand driver. The first 3 patches are just reworks in the existing driver preparing things for DMA ->read/write_page() operations. Those ones are mainly re-arranging existing functions, and moving some code

[PATCH 4/7] scatterlist: add sg_alloc_table_from_buf() helper

sg_alloc_table_from_buf() provides an easy solution to create an sg_table from a virtual address pointer. This function takes care of dealing with vmallocated buffers, buffer alignment, or DMA engine limitations (maximum DMA transfer size). Signed-off-by: Boris Brezillon

[PATCH 7/7] mtd: nand: sunxi: update DT bindings

Document dmas and dma-names properties. Signed-off-by: Boris Brezillon --- Documentation/devicetree/bindings/mtd/sunxi-nand.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/mtd/sunxi-nand.txt

[PATCH 6/7] mtd: nand: sunxi: add support for DMA assisted operations

The sunxi NAND controller is able to pipeline ECC operations only when operated in DMA mode, which improves a lot NAND throughput while keeping CPU usage low. Signed-off-by: Boris Brezillon --- drivers/mtd/nand/sunxi_nand.c | 301

[PATCH 1/7] mtd: nand: sunxi: move some ECC related operations to their own functions

In order to support DMA operations in a clean way we need to extract some of the logic coded in sunxi_nfc_hw_ecc_read/write_page() into their own function. Signed-off-by: Boris Brezillon --- drivers/mtd/nand/sunxi_nand.c | 163

[PATCH 2/7] mtd: nand: sunxi: make OOB retrieval optional

sunxi_nfc_hw_ecc_read_chunk() always retrieves the ECC and protected free bytes, no matter if the user really asked for it or not. This can take a non negligible amount of time, especially on NAND chips exposing large OOB areas (> 1KB). Make it optional. Signed-off-by: Boris Brezillon

[PATCH 3/7] mtd: nand: sunxi: make cur_off parameter optional in extra oob helpers

Allow for NULL cur_offs values when the caller does not know where the NAND page register pointer point to. Signed-off-by: Boris Brezillon --- drivers/mtd/nand/sunxi_nand.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git

Re: videobuf2-dma-sg and multiple planes semantics

Hans Verkuil writes: > Hi Robert, > > In the case of PIX_FMT_YUV422P there is only *one* buffer and the planes are > laid out in > that single buffer. So from the point of view of v4l2/vb2 this is a single > planar > format and you have a single sglist.h That's the piece of

Re: Kernel docs: muddying the waters a bit

On Tue, 08 Mar 2016, Dan Allen wrote: > One of the key goals of the Asciidoctor project is to be able to directly > produce a wide variety of outputs from the same source (without DocBook). > We've added flexibility and best practices into the syntax and matured the >

Re: videobuf2-dma-sg and multiple planes semantics

Hi Robert, On 03/07/16 19:08, Robert Jarzmik wrote: > Robert Jarzmik writes: > >> Hi, >> >> I've been converting pxa_camera driver from videobuf to videobuf2, and I >> have a >> question about multiple plane semantics. >> >> I have a case where I have 3 planes for a

Re: [PATCH v2] media: sh_mobile_ceu_camera: Remove dependency on SUPERH

On Tue, Mar 8, 2016 at 2:03 AM, Simon Horman wrote: > A dependency on ARCH_SHMOBILE seems to be the best option for > sh_mobile_ceu_camera: > > * For Super H based SoCs: sh_mobile_ceu is used on SH_AP325RXA, SH_ECOVEC, > SH_KFR2R09, SH_MIGOR, and

Re: [PATCH v2] media: rcar_vin: Use ARCH_RENESAS

On Tue, Mar 8, 2016 at 2:03 AM, Simon Horman wrote: > Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. > > This is part of an ongoing process to migrate from ARCH_SHMOBILE to > ARCH_RENESAS the motivation for which being that RENESAS seems to be a more > appropriate