Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

Hi Shuah, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc5] [cannot apply to next-20170405] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Shuah-Khan/arm-dma-fix

cron job: media_tree daily build: ERRORS

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 Apr 6 05:00:16 CEST 2017 media-tree git hash:2f65ec0567f77b75f459c98426053a3787af356a media_build

Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

On Wed, Apr 05, 2017 at 10:02:42AM -0600, Shuah Khan wrote: > When coherent DMA memory without struct page is shared, importer > fails to find the page and runs into kernel page fault when it > tries to dmabuf_ops_attach/map_sg/map_page the invalid page found > in the sg_table. Please see

Re: [RFC 00/10] V4L2 explicit synchronization support

Hi Gustavo, On Wed, Apr 05, 2017 at 05:24:57PM +0200, Gustavo Padovan wrote: > Hi Sakari, > > 2017-04-04 Sakari Ailus : > > > Hi Gustavo, > > > > Thank you for the patchset. Please see my comments below. > > > > On Mon, Mar 13, 2017 at 04:20:25PM -0300, Gustavo Padovan

[PATCH 1/2] [media] dvb_frontend: add kernel-doc tag for a missing parameter

Changeset 1f862a68df24 ("[media] dvb_frontend: move kref to struct dvb_frontend") added a kref to the struct dvb_frontend, but it didn't document it. Fixes: 1f862a68df24 ("[media] dvb_frontend: move kref to struct dvb_frontend") Signed-off-by: Mauro Carvalho Chehab ---

[PATCH 2/2] [media] tveeprom: get rid of documentation of an unused parameter

Changeset 446aba663b82 ("[media] tveeprom: get rid of unused arg on tveeprom_hauppauge_analog()") removed the now unused I2C adapter struct from struct tveeprom. Remove the corresponding kernel-doc tag. Fixes: 446aba663b82 ("[media] tveeprom: get rid of unused arg on

Re: [PATCH v6 17/39] platform: add video-multiplexer subdevice driver

On Wed 2017-04-05 13:58:39, Lucas Stach wrote: > Am Mittwoch, den 05.04.2017, 13:18 +0200 schrieb Pavel Machek: > > Hi! > > > > > + * video stream multiplexer controlled via gpio or syscon > > > + * > > > + * Copyright (C) 2013 Pengutronix, Sascha Hauer > > > + * Copyright

Re: [GIT PULL for v4.12] Staging lirc cleanup

Hi Sean, Em Sat, 25 Mar 2017 21:31:46 + Sean Young escreveu: > Hi Mauro, > > This pull promotes lirc_sir out of staging and removes lirc_sasem; Applied, thanks! > this > only leaves lirc_zilog in staging. I'm attempting to write a new driver for > this, > maybe we

Re: [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1

Em Wed, 5 Apr 2017 13:02:52 -0400 Devin Heitmueller escreveu: > > I remember I looked on this when I wrote the driver, but I was > > unable to find a way for em28xx to parse (or forward) such > > data packets. > > I'm pretty sure it's possible, but I haven't

Re: [RFC 00/10] V4L2 explicit synchronization support

Hello Gustavo, On 04/05/2017 11:09 AM, Gustavo Padovan wrote: > 2017-04-03 Javier Martinez Canillas : > >> Hello Mauro and Gustavo, >> >> On 04/03/2017 07:16 AM, Mauro Carvalho Chehab wrote: >>> Hi Gustavo, >>> >>> Em Mon, 13 Mar 2017 16:20:25 -0300 >>> Gustavo Padovan

[PATCH 28/38] Annotate hardware config module parameters in drivers/staging/media/

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a

Re: [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1

>> For what it's worth, I doubt most of the em28xx designs have the >> tvp5150 interrupt request line connected in any way. > > True. But, on embedded hardware, such line may be connected into the > SoC. Actually, from the IGEPv3 expansion diagram: > > >

[PATCH 13/38] Annotate hardware config module parameters in drivers/media/

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a

Re: [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1

Em Wed, 5 Apr 2017 11:39:06 -0400 Devin Heitmueller escreveu: > > Currently, the driver doesn't support (2), because, at the time > > I wrote the driver, I didn't find a way to read the interrupts generated > > by tvp5150 at em28xx[1], due to the lack of em28xx

[PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

When coherent DMA memory without struct page is shared, importer fails to find the page and runs into kernel page fault when it tries to dmabuf_ops_attach/map_sg/map_page the invalid page found in the sg_table. Please see www.spinics.net/lists/stable/msg164204.html for more information on this

Re: [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1

> Currently, the driver doesn't support (2), because, at the time > I wrote the driver, I didn't find a way to read the interrupts generated > by tvp5150 at em28xx[1], due to the lack of em28xx documentation, > but adding support for it shoudn't be hard. I may eventually do it > when I have some

Re: [RFC 00/10] V4L2 explicit synchronization support

Hi Sakari, 2017-04-04 Sakari Ailus : > Hi Gustavo, > > Thank you for the patchset. Please see my comments below. > > On Mon, Mar 13, 2017 at 04:20:25PM -0300, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > Hi, > > > > This RFC

Re: [RFC 00/10] V4L2 explicit synchronization support

2017-04-03 Javier Martinez Canillas : > Hello Mauro and Gustavo, > > On 04/03/2017 07:16 AM, Mauro Carvalho Chehab wrote: > > Hi Gustavo, > > > > Em Mon, 13 Mar 2017 16:20:25 -0300 > > Gustavo Padovan escreveu: > > > >> From: Gustavo Padovan

Re: [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1

Em Wed, 05 Apr 2017 11:34:19 +0200 Philipp Zabel escreveu: > On Wed, 2017-04-05 at 09:21 +0100, Russell King - ARM Linux wrote: > [...] > > > Actually what was I thinking, the TVP5150 is already an example of > > > such a device. > > > > > > All of this could be solved

Re: [PATCH 3/3] [media] coda/imx-vdoa: always wait for job completion

On Wed, 2017-04-05 at 15:09 +0200, Lucas Stach wrote: > As long as only one CODA context is running we get alternating device_run() > and wait_for_completion() calls, but when more then one CODA context is > active, other VDOA slots can be inserted between those calls for one context. > > Make

Re: [RFC 01/10] [media] vb2: add explicit fence user API

Hi Philipp, 2017-04-03 Philipp Zabel : > Hi Gustavo, > > On Mon, 2017-03-13 at 16:20 -0300, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > Turn the reserved2 field into fence_fd that we will use to send > > an in-fence to the

Re: [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1

Hello Philipp, On Wed, Apr 5, 2017 at 5:34 AM, Philipp Zabel wrote: > On Wed, 2017-04-05 at 09:21 +0100, Russell King - ARM Linux wrote: [snip] > I think the output part is accurate, as the audio pad is an artifact of > an unrelated change. I'm not so sure about the VBI

[PATCH v3] usb: document that URB transfer_buffer should be aligned

Several host controllers, commonly found on ARM, like dwc2, require buffers that are CPU-word aligned for they to work. Failing to do that will cause buffer overflows at the caller drivers, with could cause data corruption. Such data corruption was found, in practice, with the uvcdriver.

Re: [PATCH 2/3] [media] coda: first step at error recovery

Hi Lucas, On Wed, 2017-04-05 at 15:09 +0200, Lucas Stach wrote: > This implements a simple handler for the case where decode did not finish > sucessfully. This might be helpful during normal streaming, but for now it > only handles the case where the context would deadlock with userspace, > i.e.

Re: [PATCH] [media] coda: bump maximum number of internal framebuffers to 17

On Wed, 2017-04-05 at 15:11 +0200, Lucas Stach wrote: > The h.264 standard allows up to 16 reference frame for the high profile > and we need one additional internal framebuffer when the VDOA is in use. > > Lift the current maximum of 8 internal framebuffers to allow playback > of those video

Re: [PATCH 1/3] [media] coda: use correct offset for mvcol buffer

On Wed, 2017-04-05 at 15:09 +0200, Lucas Stach wrote: > The mvcol buffer needs to be placed behind the chroma plane(s), so > use the real offset including any required rounding. > > Signed-off-by: Lucas Stach Reviewed-by: Philipp Zabel regards

[PATCH v2 21/21] docs-rst: fix usb cross-references

As some USB documentation files got moved, adjust their cross-references to their new place. Signed-off-by: Mauro Carvalho Chehab --- Documentation/ABI/stable/sysfs-bus-usb| 2 +- Documentation/driver-api/usb/URB.rst | 2 ++

[PATCH v2 05/21] gadget.rst: Enrich its ReST representation and add kernel-doc tag

The pandoc conversion is not perfect. Do handwork in order to: - add a title to this chapter; - use the proper warning and note markups; - use kernel-doc to include Kernel header and c files; - remove legacy notes with regards to DocBook; - some other minor adjustments to make it better to read

[PATCH v2 16/21] usb/URB.txt: convert to ReST and update it

The URB doc describes the Kernel mechanism that do USB transfers. While the functions are already described at urb.h, there are a number of concepts and theory that are important for USB driver developers. Convert it to ReST and use C ref links to point to the places at usb.h where each function

[PATCH v2 12/21] usb/dma.txt: convert to ReST and add to driver-api book

This document describe some USB core features. Add it to the driver-api book. Signed-off-by: Mauro Carvalho Chehab --- .../{usb/dma.txt => driver-api/usb/dma.rst}| 51 -- Documentation/driver-api/usb/index.rst | 1 + 2 files

[PATCH v2 00/21] Convert USB documentation to ReST format

Currently, there are several USB core documents that are at either written in plain text or in DocBook format. Convert them to ReST and add to the driver-api book. Mauro Carvalho Chehab (21): tmplcvt: make the tool more robust driver-api/basics.rst: add device table header docs-rst: convert

[PATCH v2 08/21] usb/anchors.txt: convert to ReST and add to driver-api book

This document describe some USB core functions. Add it to the driver-api book. Signed-off-by: Mauro Carvalho Chehab --- .../anchors.txt => driver-api/usb/anchors.rst} | 36 -- Documentation/driver-api/usb/index.rst | 1 + 2 files

[PATCH v2 04/21] usb.rst: Enrich its ReST representation

- use the proper warning and note markups; - add references for parts of the document that will be cross-referenced on other USB docs; - some minor adjustments to make it better to read in text mode and in html. Signed-off-by: Mauro Carvalho Chehab ---

[PATCH v2 17/21] usb.rst: get rid of some Sphinx errors

Get rid of those warnings: Documentation/driver-api/usb/usb.rst:615: ERROR: Unknown target name: "usb_type". Documentation/driver-api/usb/usb.rst:615: ERROR: Unknown target name: "usb_dir". Documentation/driver-api/usb/usb.rst:615: ERROR: Unknown target name: "usb_recip".

[PATCH v2 18/21] usb: get rid of some ReST doc build errors

We need an space before a numbered list to avoid those warnings: ./drivers/usb/core/message.c:478: ERROR: Unexpected indentation. ./drivers/usb/core/message.c:479: WARNING: Block quote ends without a blank line; unexpected unindent. ./include/linux/usb/composite.h:455: ERROR: Unexpected

[PATCH v2 14/21] usb/hotplug.txt: convert to ReST and add to driver-api book

This document describe some USB core features. Add it to the driver-api book. Signed-off-by: Mauro Carvalho Chehab --- .../hotplug.txt => driver-api/usb/hotplug.rst} | 66 -- Documentation/driver-api/usb/index.rst | 1 + 2 files

[PATCH v2 10/21] usb/callbacks.txt: convert to ReST and add to driver-api book

This document describe some USB core functions. Add it to the driver-api book. Signed-off-by: Mauro Carvalho Chehab --- .../callbacks.txt => driver-api/usb/callbacks.rst} | 61 +++--- Documentation/driver-api/usb/index.rst | 1 + 2 files

[PATCH v2 19/21] usb: composite.h: fix two warnings when building docs

By definition, we use /* private: */ tag when we won't be documenting a parameter. However, those two parameters are documented: ./include/linux/usb/composite.h:510: warning: Excess struct/union/enum/typedef member 'setup_pending' description in 'usb_composite_dev'

[PATCH v2 15/21] usb/persist.txt: convert to ReST and add to driver-api book

This document describe some USB core features. Add it to the driver-api book. Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/usb/index.rst | 1 + .../persist.txt => driver-api/usb/persist.rst} | 22 +- 2 files

[PATCH v2 01/21] tmplcvt: make the tool more robust

Currently, the script just assumes to be called at Documentation/sphinx/. Change it to work on any directory, and make it abort if something gets wrong. Also, be sure that both parameters are specified. That should avoid troubles like this: $ Documentation/sphinx/tmplcvt

[PATCH v2 20/21] usb: gadget.h: be consistent at kernel doc macros

There's one value that use spaces instead of tabs to ident. That causes the following warning: ./include/linux/usb/gadget.h:193: ERROR: Unexpected indentation. Signed-off-by: Mauro Carvalho Chehab --- include/linux/usb/gadget.h | 2 +- 1 file changed, 1 insertion(+),

[PATCH v2 09/21] usb/bulk-streams.txt: convert to ReST and add to driver-api book

This document describe some USB core functions. Add it to the driver-api book. Signed-off-by: Mauro Carvalho Chehab --- .../bulk-streams.txt => driver-api/usb/bulk-streams.rst}| 13 + Documentation/driver-api/usb/index.rst | 1 + 2

[PATCH v2 02/21] driver-api/basics.rst: add device table header

The structs there at device table are used by other documentation at the Kernel. So, add it to the driver API. Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/basics.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git

[PATCH v2 07/21] writing_musb_glue_layer.rst: Enrich its ReST representation

This file is actually quite complex, and required several manual handwork: - add a title for the document; - use the right tags for monospaced fonts; - use c references where needed; - adjust cross-reference to writing_usb_driver.rst - hightlight cross-referenced lines. With regards to C code

[PATCH v2 06/21] writing_usb_driver.rst: Enrich its ReST representation

The pandoc conversion is not perfect. Do handwork in order to: - add a title to this chapter; - adjust function and struct references; - use monospaced fonts for C code names; - some other minor adjustments to make it better to read in text mode and in html. Signed-off-by: Mauro Carvalho

[PATCH v2 13/21] error-codes.rst: convert to ReST and add to driver-api book

This document describe some USB core features. Add it to the driver-api book. Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/usb/error-codes.rst | 205 +++ Documentation/driver-api/usb/index.rst | 1 +

[PATCH v2 11/21] usb/power-management.txt: convert to ReST and add to driver-api book

This document describe some USB core functions. Add it to the driver-api book. Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/usb/index.rst | 1 + .../usb/power-management.rst} | 404 +++-- 2 files

Re: [RFC, v2, 10/11] vb2: dma-contig: Let drivers decide DMA attrs of MMAP and USERPTR bufs

Hi Ricky, On Mon, Dec 26, 2016 at 03:58:07PM +0800, Ricky Liang wrote: > Hi Laurent, > > On Fri, Dec 16, 2016 at 9:24 AM, Laurent Pinchart > wrote: > > From: Sakari Ailus > > > > The desirable DMA attributes are not

[PATCH] [media] coda: bump maximum number of internal framebuffers to 17

The h.264 standard allows up to 16 reference frame for the high profile and we need one additional internal framebuffer when the VDOA is in use. Lift the current maximum of 8 internal framebuffers to allow playback of those video streams. Signed-off-by: Lucas Stach ---

[PATCH 3/3] [media] coda/imx-vdoa: always wait for job completion

As long as only one CODA context is running we get alternating device_run() and wait_for_completion() calls, but when more then one CODA context is active, other VDOA slots can be inserted between those calls for one context. Make sure to wait on job completion before running a different context

[PATCH 1/3] [media] coda: use correct offset for mvcol buffer

The mvcol buffer needs to be placed behind the chroma plane(s), so use the real offset including any required rounding. Signed-off-by: Lucas Stach --- drivers/media/platform/coda/coda-bit.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

[PATCH 2/3] [media] coda: first step at error recovery

This implements a simple handler for the case where decode did not finish sucessfully. This might be helpful during normal streaming, but for now it only handles the case where the context would deadlock with userspace, i.e. userspace issued DEC_CMD_STOP and waits for EOS, but after the failed

Re: [PATCH v2 01/22] tmplcvt: make the tool more robust

Em Sun, 2 Apr 2017 15:32:31 -0600 Jonathan Corbet escreveu: > On Thu, 30 Mar 2017 07:45:35 -0300 > Mauro Carvalho Chehab wrote: > > > Currently, the script just assumes to be called at > > Documentation/sphinx/. Change it to work on any directory, > >

Re: [PATCH v6 17/39] platform: add video-multiplexer subdevice driver

Am Mittwoch, den 05.04.2017, 13:18 +0200 schrieb Pavel Machek: > Hi! > > > + * video stream multiplexer controlled via gpio or syscon > > + * > > + * Copyright (C) 2013 Pengutronix, Sascha Hauer > > + * Copyright (C) 2016 Pengutronix, Philipp Zabel

Re: [PATCH v6 19/39] media: Add i.MX media core driver

Hi! > +https://boundarydevices.com/products/nit6x_5mp I'd use /product/ in url, as it redirects there. > +https://boundarydevices.com/product/nit6x_5mp_mipi ..and for consistency. > +The following example configures a direct conversion pipeline to capture > +from the OV5640, transmitting on

Re: [PATCH v6 19/39] media: Add i.MX media core driver

Hi! > +References > +-- > + > +[1] "i.MX 6Dual/6Quad Applications Processor Reference Manual" > +[2] "i.MX 6Solo/6DualLite Applications Processor Reference Manual" [2] is not present in the text above. [1] is there many times. What is purpose of this section?

Re: [PATCH v6 17/39] platform: add video-multiplexer subdevice driver

Hi! > + * video stream multiplexer controlled via gpio or syscon > + * > + * Copyright (C) 2013 Pengutronix, Sascha Hauer > + * Copyright (C) 2016 Pengutronix, Philipp Zabel This is actually quite interesting. Same email address for two people...

Re: [PATCH] media: mtk-vcodec: remove informative log

On Wed, 2017-04-05 at 18:54 +0800, Minghsiu Tsai wrote: > Driver is stable. Remove DEBUG definition from driver. > > There are debug message in /var/log/messages if DEBUG is defined, > such as: > [MTK_V4L2] level=0 fops_vcodec_open(),170: decoder capability 0 > [MTK_V4L2] level=0

[PATCH] media: mtk-vcodec: remove informative log

Driver is stable. Remove DEBUG definition from driver. There are debug message in /var/log/messages if DEBUG is defined, such as: [MTK_V4L2] level=0 fops_vcodec_open(),170: decoder capability 0 [MTK_V4L2] level=0 fops_vcodec_open(),177: 1600.vcodec decoder [0] [MTK_V4L2] level=0

[PATCH 1/2] [media] rc-core: Add inlined stubs for core rc_* functions

Currently users have to use all sorts of ugly #ifery within their drivers in order to avoid linking issues at build time. This patch allows users to safely call these functions when !CONFIG_RC_CORE and make decisions based on the return value instead. This is a much more common and clean way of

[PATCH 2/2] [media] cec: Handle RC capability more elegantly

If a user specifies the use of RC as a capability, they should really be enabling RC Core code. If they do not we WARN() them of this and disable the capability for them. Once we know RC Core code has not been enabled, we can update the user's capabilities and use them as a term of reference for

Re: [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1

On Tue, 2017-04-04 at 15:11 -0700, Steve Longerbeam wrote: > > On 03/30/2017 10:25 AM, Philipp Zabel wrote: > > The TVP5150 DT bindings specify a single output port (port 0) that > > corresponds to the video output pad (pad 1, DEMOD_PAD_VID_OUT). > > > > Signed-off-by: Philipp Zabel

Re: [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1

On Wed, 2017-04-05 at 09:21 +0100, Russell King - ARM Linux wrote: [...] > > Actually what was I thinking, the TVP5150 is already an example of > > such a device. > > > > All of this could be solved if there was some direction information > > in port nodes. > > I disagree. > > Philipp identified

Re: [PATCH 2/2] [media] cec: Handle RC capability more elegantly

On Tue, 04 Apr 2017, Russell King - ARM Linux wrote: > On Tue, Apr 04, 2017 at 05:10:05PM +0100, Lee Jones wrote: > > @@ -237,7 +241,6 @@ struct cec_adapter *cec_allocate_adapter(const struct > > cec_adap_ops *ops, > > if (!(caps & CEC_CAP_RC)) > > return adap; > > > > -#if

Re: [PATCH] [media] cec: Handle RC capability more elegantly

On Tue, 04 Apr 2017, Russell King - ARM Linux wrote: > On Tue, Apr 04, 2017 at 04:19:39PM +0100, Lee Jones wrote: > > On Tue, 04 Apr 2017, Hans Verkuil wrote: > > > > > On 04/04/2017 04:43 PM, Lee Jones wrote: > > > > If a user specifies the use of RC as a capability, they should > > > > really

Re: [PATCH] [media] cec: Handle RC capability more elegantly

On Tue, 04 Apr 2017, Hans Verkuil wrote: > On 04/04/2017 05:36 PM, Russell King - ARM Linux wrote: > > On Tue, Apr 04, 2017 at 04:19:39PM +0100, Lee Jones wrote: > >> On Tue, 04 Apr 2017, Hans Verkuil wrote: > >> > >>> On 04/04/2017 04:43 PM, Lee Jones wrote: > If a user specifies the use of

Re: [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1

On Tue, Apr 04, 2017 at 05:44:05PM -0700, Steve Longerbeam wrote: > > > On 04/04/2017 05:40 PM, Steve Longerbeam wrote: > > > > > >On 04/04/2017 04:10 PM, Russell King - ARM Linux wrote: > >>On Thu, Mar 30, 2017 at 07:25:49PM +0200, Philipp Zabel wrote: > >>>The TVP5150 DT bindings specify a

Re: [PATCH 2/2] rainshadow-cec: new RainShadow Tech HDMI CEC driver

On 04/05/2017 02:26 AM, Dmitry Torokhov wrote: > Hi Hans, > > On Fri, Feb 03, 2017 at 03:46:01PM +0100, Hans Verkuil wrote: >> Hi Dmitry, >> >> Thanks for the feedback. See my comments below: >> >> On 03/01/17 07:51, Dmitry Torokhov wrote: >>> Hi Hans, >>> >>> On Thu, Dec 15, 2016 at 02:02:07PM