[RFC PATCH 09/11] drm: mali-dp: Add RGB writeback formats for DP550/DP650

Add a layer bit for the SE memory-write, and add it to the pixel format matrix for DP550/DP650. Signed-off-by: Brian Starkey --- drivers/gpu/drm/arm/malidp_hw.c | 28 ++-- drivers/gpu/drm/arm/malidp_hw.h |1 + 2 files changed, 15

[RFC PATCH 10/11] drm: mali-dp: Add support for writeback on DP550/DP650

From: Liviu Dudau Mali-DP display processors are able to write the composition result to a memory buffer via the SE. Add entry points in the HAL for enabling/disabling this feature, and implement support for it on DP650 and DP550. DP500 acts differently and so is omitted

[RFC PATCH 03/11] drm: Extract CRTC/plane disable from drm_framebuffer_remove

In preparation for adding an atomic version of the disable code, extract the actual disable operation into a separate function. Signed-off-by: Brian Starkey --- drivers/gpu/drm/drm_framebuffer.c | 87 +++-- 1 file changed, 54

[RFC PATCH 11/11] drm: mali-dp: Add writeback connector

Mali-DP has a memory writeback engine which can be used to write the composition result to a memory buffer. Expose this functionality as a DRM writeback connector on supported hardware. Signed-off-by: Brian Starkey --- drivers/gpu/drm/arm/Makefile |1 +

[RFC PATCH 05/11] drm: Add fb to connector state

Add a framebuffer to the connector state, for use as the output target by writeback connectors. If a framebuffer is in use by a writeback connector when userspace removes it, it is handled by removing the framebuffer from the connector. Signed-off-by: Brian Starkey ---

[RFC PATCH 06/11] drm: Expose fb_id property for writeback connectors

Expose the framebuffer for writeback connectors to userspace by attaching the fb_id property to them. Signed-off-by: Brian Starkey --- drivers/gpu/drm/drm_atomic.c|9 + drivers/gpu/drm/drm_connector.c |4 2 files changed, 13 insertions(+) diff

[RFC PATCH 00/11] Introduce writeback connectors

Hi, This RFC series introduces a new connector type: DRM_MODE_CONNECTOR_WRITEBACK It is a follow-on from a previous discussion: [1] Writeback connectors are used to expose the memory writeback engines found in some display controllers, which can write a CRTC's composition result to a memory

[RFC PATCH 07/11] drm: Add writeback-connector pixel format properties

So that userspace can determine what pixel formats are supported for a writeback connector's framebuffer, add a pixel format list to writeback connectors. This is in the form of an immutable blob containing an array of formats, and an immutable uint holding the array size. Signed-off-by: Brian

[RFC PATCH 08/11] drm: mali-dp: Rename malidp_input_format

We're going to use the same format list for output formats, so rename everything related to input formats to avoid confusion. Signed-off-by: Brian Starkey Reviewed-by: Liviu Dudau --- drivers/gpu/drm/arm/malidp_hw.c | 24

Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts

Em Tue, 11 Oct 2016 09:26:48 +0200 Markus Heiser escreveu: > Am 07.10.2016 um 07:56 schrieb Jani Nikula : > > > On Thu, 06 Oct 2016, Mauro Carvalho Chehab wrote: > >> Em Thu, 06 Oct 2016 17:21:36 +0300 > >> Jani Nikula

[RFC PATCH 04/11] drm: Add __drm_framebuffer_remove_atomic

Implement the CRTC/Plane disable functionality of drm_framebuffer_remove using the atomic API, and use it if possible. For atomic drivers, this removes the possibility of several commits when a framebuffer is in use by more than one CRTC/plane. Additionally, this will provide a suitable place to

[RFC PATCH 01/11] drm: Add writeback connector type

Writeback connectors represent writeback engines which can write the CRTC output to a memory framebuffer. Add a writeback connector type, hidden from userspace behind a client cap. They are hidden from non-aware clients so that they do not attempt to use writeback connectors to provide visual

Re: [RFC PATCH 07/11] drm: Add writeback-connector pixel format properties

On Tue, Oct 11, 2016 at 03:54:04PM +0100, Brian Starkey wrote: > So that userspace can determine what pixel formats are supported for a > writeback connector's framebuffer, add a pixel format list to writeback > connectors. This is in the form of an immutable blob containing an array > of formats,

Re: [RFC PATCH 02/11] drm/fb-helper: Skip writeback connectors

On Tue, Oct 11, 2016 at 03:53:59PM +0100, Brian Starkey wrote: > Writeback connectors aren't much use to the fbdev helpers, as they won't > show anything to the user. Skip them when looking for candidate output > configurations. > > Signed-off-by: Brian Starkey > --- >

Re: [RFC PATCH 00/11] Introduce writeback connectors

On Tue, Oct 11, 2016 at 03:53:57PM +0100, Brian Starkey wrote: > Hi, > > This RFC series introduces a new connector type: > DRM_MODE_CONNECTOR_WRITEBACK > It is a follow-on from a previous discussion: [1] > > Writeback connectors are used to expose the memory writeback engines > found in some

[RFC PATCH 02/11] drm/fb-helper: Skip writeback connectors

Writeback connectors aren't much use to the fbdev helpers, as they won't show anything to the user. Skip them when looking for candidate output configurations. Signed-off-by: Brian Starkey --- drivers/gpu/drm/drm_fb_helper.c |4 1 file changed, 4 insertions(+)

Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts

On Tue, 11 Oct 2016, Mauro Carvalho Chehab wrote: > Em Tue, 11 Oct 2016 09:26:48 +0200 > Markus Heiser escreveu: > >> Am 07.10.2016 um 07:56 schrieb Jani Nikula : >> >> > On Thu, 06 Oct 2016, Mauro Carvalho Chehab

[PATCH v2 10/31] dibusb: handle error code on RC query

There's no sense on decoding and generating a RC key code if there was an error on the URB control message. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/usb/dvb-usb/dibusb-common.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git

[PATCH v2 18/31] gp8psk: don't do DMA on stack

The USB control messages require DMA to work. We cannot pass a stack-allocated buffer, as it is not warranted that the stack would be into a DMA enabled area. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/usb/dvb-usb/gp8psk.c | 14 -- 1 file

[PATCH v2 14/31] dtt200u-fe: handle errors on USB control messages

If something goes wrong, return an error code, instead of assuming that everything went fine. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/usb/dvb-usb/dtt200u-fe.c | 40 ++ 1 file changed, 31 insertions(+), 9 deletions(-) diff

[PATCH v2 12/31] dtt200u-fe: don't keep waiting for lock at set_frontend()

It is up to the frontend kthread to wait for lock. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/usb/dvb-usb/dtt200u-fe.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/media/usb/dvb-usb/dtt200u-fe.c

[PATCH v2 16/31] dtt200u: handle USB control message errors

If something bad happens while an USB control message is transfered, return an error code. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/usb/dvb-usb/dtt200u.c | 26 ++ 1 file changed, 18 insertions(+), 8 deletions(-) diff --git

[PATCH v2 25/31] nova-t-usb2: handle error code on RC query

There's no sense on decoding and generating a RC key code if there was an error on the URB control message. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/usb/dvb-usb/nova-t-usb2.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git

[PATCH v2 22/31] pctv452e: don't call BUG_ON() on non-fatal error

There are some conditions on this driver that are tested with BUG_ON() with are not serious enough to hang a machine. So, just return an error if this happens. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/usb/dvb-usb/pctv452e.c | 7 --- 1 file changed, 4

[PATCH v2 24/31] dvb-usb: warn if return value for USB read/write routines is not checked

the return values for dvb_usb_generic_rw() and dvb_usb_generic_write() should be checked, as otherwise the drivers won't be doing the right thing in the case of errors. So, add __must_check to both declarations. Signed-off-by: Mauro Carvalho Chehab ---

[PATCH v2 07/31] dib0700: be sure that dib0700_ctrl_rd() users can do DMA

dib0700_ctrl_rd() takes a RX and a TX pointer. Be sure that both will point to a memory allocated via kmalloc(). Reviewed-By: Patrick Boettcher Signed-off-by: Mauro Carvalho Chehab --- drivers/media/usb/dvb-usb/dib0700_core.c| 4 +++-

[PATCH v2 30/31] stk-webcam: don't use stack for DMA

From: Mauro Carvalho Chehab The USB control messages require DMA to work. We cannot pass a stack-allocated buffer, as it is not warranted that the stack would be into a DMA enabled area. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Mauro

[PATCH v2 26/31] dw2102: return error if su3000_power_ctrl() fails

Instead of silently ignoring the error, return it. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/usb/dvb-usb/dw2102.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/usb/dvb-usb/dw2102.c b/drivers/media/usb/dvb-usb/dw2102.c

[PATCH v2 01/31] af9005: don't do DMA on stack

The USB control messages require DMA to work. We cannot pass a stack-allocated buffer, as it is not warranted that the stack would be into a DMA enabled area. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/usb/dvb-usb/af9005.c | 317

[PATCH v2 28/31] cpia2_usb: don't use stack for DMA

From: Mauro Carvalho Chehab The USB control messages require DMA to work. We cannot pass a stack-allocated buffer, as it is not warranted that the stack would be into a DMA enabled area. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Mauro

Re: [linux-review:Mauro-Carvalho-Chehab/Don-t-use-stack-for-DMA-transers-on-media-usb-drivers/20161011-182408 3/31] drivers/media/usb/dvb-usb/cinergyT2-core.c:174:2-8: preceding lock on line 169

To: kbu...@01.org > Cc: Julia Lawall <julia.law...@lip6.fr> > Subject: > > [linux-review:Mauro-Carvalho-Chehab/Don-t-use-stack-for-DMA-transers-on-medi > a-usb-drivers/20161011-182408 3/31] > drivers/media/usb/dvb-usb/cinergyT2-core.c:174:2-8: preceding lock o

[linux-review:Mauro-Carvalho-Chehab/Don-t-use-stack-for-DMA-transers-on-media-usb-drivers/20161011-182408 3/31] drivers/media/usb/dvb-usb/cinergyT2-core.c:174:2-8: preceding lock on line 169

o-Chehab/Don-t-use-stack-for-DMA-transers-on-medi a-usb-drivers/20161011-182408 3/31] drivers/media/usb/dvb-usb/cinergyT2-core.c:174:2-8: preceding lock on line 169 CC: kbuild-...@01.org TO: Mauro Carvalho Chehab <m.che...@samsung.com> CC: linux-media@vger.kernel.org CC: 0da

[PATCH v2 05/31] cinergyT2-fe: don't do DMA on stack

The USB control messages require DMA to work. We cannot pass a stack-allocated buffer, as it is not warranted that the stack would be into a DMA enabled area. Reviewed-By: Patrick Boettcher Signed-off-by: Mauro Carvalho Chehab ---

[PATCH v2 00/31] Don't use stack for DMA transers on media usb drivers

Sending URB control messages from stack was never supported. Yet, on x86, the stack was usually at a memory region that allows DMA transfer. So, several drivers got it wrong. On Kernel 4.9, if VMAP_STACK=y, none of those drivers will work, as the stack won't be on a DMA-able area anymore. So,

[PATCH v2 04/31] cinergyT2-fe: cache stats at cinergyt2_fe_read_status()

Instead of sending USB commands for every stats call, collect them once, when status is updated. As the frontend kthread will call it on every few seconds, the stats will still be collected. Besides reducing the amount of USB/I2C transfers, this also warrants that all stats will be collected at

[PATCH v2 06/31] cxusb: don't do DMA on stack

The USB control messages require DMA to work. We cannot pass a stack-allocated buffer, as it is not warranted that the stack would be into a DMA enabled area. Reviewed-By: Patrick Boettcher Signed-off-by: Mauro Carvalho Chehab ---

[PATCH v2 31/31] flexcop-usb: don't use stack for DMA

The USB control messages require DMA to work. We cannot pass a stack-allocated buffer, as it is not warranted that the stack would be into a DMA enabled area. While here, remove a dead function calling usb_control_msg(). Signed-off-by: Mauro Carvalho Chehab ---

[PATCH v2 29/31] s2255drv: don't use stack for DMA

From: Mauro Carvalho Chehab The USB control messages require DMA to work. We cannot pass a stack-allocated buffer, as it is not warranted that the stack would be into a DMA enabled area. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Mauro

[PATCH v2 23/31] technisat-usb2: use DMA buffers for I2C transfers

The USB control messages require DMA to work. We cannot pass a stack-allocated buffer, as it is not warranted that the stack would be into a DMA enabled area. On this driver, most of the transfers are OK, but the I2C one was using stack. Reviewed-By: Patrick Boettcher

[PATCH v2 27/31] digitv: handle error code on RC query

There's no sense on decoding and generating a RC key code if there was an error on the URB control message. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/usb/dvb-usb/digitv.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git

[linux-review:Mauro-Carvalho-Chehab/Don-t-use-stack-for-DMA-transers-on-media-usb-drivers/20161011-182408 22/31] drivers/media/usb/dvb-usb/pctv452e.c:115:2-3: Unneeded semicolon

tree: https://github.com/0day-ci/linux Mauro-Carvalho-Chehab/Don-t-use-stack-for-DMA-transers-on-media-usb-drivers/20161011-182408 head: ff49f775552fe4ebe2944527cf882073679cb1e5 commit: 4bafb476079bf7e4aa258248cfa853f130c46c8c [22/31] pctv452e: don't call BUG_ON() on non-fatal error

[PATCH] pctv452e: fix semicolon.cocci warnings

drivers/media/usb/dvb-usb/pctv452e.c:115:2-3: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci CC: Mauro Carvalho Chehab Signed-off-by: Fengguang Wu --- pctv452e.c |2 +- 1 file

[PATCH v2 11/31] digitv: don't do DMA on stack

The USB control messages require DMA to work. We cannot pass a stack-allocated buffer, as it is not warranted that the stack would be into a DMA enabled area. Reviewed-By: Patrick Boettcher Signed-off-by: Mauro Carvalho Chehab ---

[PATCH v2 19/31] gp8psk: don't go past the buffer size

Add checks to avoid going out of the buffer. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/usb/dvb-usb/gp8psk.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/media/usb/dvb-usb/gp8psk.c b/drivers/media/usb/dvb-usb/gp8psk.c index

[PATCH v2 15/31] dtt200u: don't do DMA on stack

From: Mauro Carvalho Chehab The USB control messages require DMA to work. We cannot pass a stack-allocated buffer, as it is not warranted that the stack would be into a DMA enabled area. Reviewed-By: Patrick Boettcher Signed-off-by: Mauro

[PATCH v2 17/31] dtv5100: don't do DMA on stack

From: Mauro Carvalho Chehab The USB control messages require DMA to work. We cannot pass a stack-allocated buffer, as it is not warranted that the stack would be into a DMA enabled area. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Mauro

[PATCH v2 21/31] pctv452e: don't do DMA on stack

The USB control messages require DMA to work. We cannot pass a stack-allocated buffer, as it is not warranted that the stack would be into a DMA enabled area. Reviewed-By: Patrick Boettcher Signed-off-by: Mauro Carvalho Chehab ---

[PATCH v2 13/31] dtt200u-fe: don't do DMA on stack

The USB control messages require DMA to work. We cannot pass a stack-allocated buffer, as it is not warranted that the stack would be into a DMA enabled area. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/usb/dvb-usb/dtt200u-fe.c | 95

[PATCH v2 02/31] cinergyT2-core: don't do DMA on stack

The USB control messages require DMA to work. We cannot pass a stack-allocated buffer, as it is not warranted that the stack would be into a DMA enabled area. Reviewed-By: Patrick Boettcher Signed-off-by: Mauro Carvalho Chehab ---

[PATCH v2 08/31] dib0700_core: don't use stack on I2C reads

Be sure that I2C reads won't use stack by passing a pointer to the state buffer, that we know it was allocated via kmalloc, instead of relying on the buffer allocated by an I2C client. Reviewed-By: Patrick Boettcher Signed-off-by: Mauro Carvalho Chehab

[PATCH v2 09/31] dibusb: don't do DMA on stack

The USB control messages require DMA to work. We cannot pass a stack-allocated buffer, as it is not warranted that the stack would be into a DMA enabled area. Reviewed-By: Patrick Boettcher Signed-off-by: Mauro Carvalho Chehab ---

[PATCH v2 03/31] cinergyT2-core: handle error code on RC query

There's no sense on decoding and generating a RC key code if there was an error on the URB control message. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/usb/dvb-usb/cinergyT2-core.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git

Re: [PATCH 00/26] Don't use stack for DMA transers on dvb-usb drivers

Em Mon, 10 Oct 2016 07:44:53 -0400 Michael Ira Krufky escreveu: > Antti makes a very good point. If we consider a situation where we > are streaming data while concurrently checking frontend status and > polling for IR codes, some locking will certainly be required in all >

Re: [RFC PATCH 00/11] Introduce writeback connectors

On Tue, Oct 11, 2016 at 10:02:43PM +0200, Daniel Vetter wrote: On Tue, Oct 11, 2016 at 9:44 PM, Brian Starkey wrote: Hi, On Tue, Oct 11, 2016 at 07:01:33PM +0200, Daniel Vetter wrote: On Tue, Oct 11, 2016 at 6:43 PM, Brian Starkey wrote: Hi

Re: [RFC PATCH 00/11] Introduce writeback connectors

Hi Daniel, Firstly thanks very much for having a look. On Tue, Oct 11, 2016 at 05:43:59PM +0200, Daniel Vetter wrote: On Tue, Oct 11, 2016 at 03:53:57PM +0100, Brian Starkey wrote: Hi, This RFC series introduces a new connector type: DRM_MODE_CONNECTOR_WRITEBACK It is a follow-on from a

Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts

Em Tue, 11 Oct 2016 18:06:46 +0200 Markus Heiser escreveu: > Am 11.10.2016 um 17:34 schrieb Jani Nikula : > > > On Tue, 11 Oct 2016, Mauro Carvalho Chehab wrote: > >> Em Tue, 11 Oct 2016 09:26:48 +0200 > >> Markus

Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts

Am 11.10.2016 um 17:34 schrieb Jani Nikula : > On Tue, 11 Oct 2016, Mauro Carvalho Chehab wrote: >> Em Tue, 11 Oct 2016 09:26:48 +0200 >> Markus Heiser escreveu: >> >>> Am 07.10.2016 um 07:56 schrieb Jani Nikula

Re: [RFC PATCH 00/11] Introduce writeback connectors

On Tue, Oct 11, 2016 at 6:25 PM, Ville Syrjälä wrote: >> Writeback connector usage: >> -- >> Due to connector routing changes being treated as "full modeset" >> operations, any client which wishes to use a writeback connector >> should

Re: [RFC PATCH 02/11] drm/fb-helper: Skip writeback connectors

On Tue, Oct 11, 2016 at 6:47 PM, Brian Starkey wrote: > On Tue, Oct 11, 2016 at 05:44:48PM +0200, Daniel Vetter wrote: >> >> On Tue, Oct 11, 2016 at 03:53:59PM +0100, Brian Starkey wrote: >>> >>> Writeback connectors aren't much use to the fbdev helpers, as they won't >>>

[GIT PULL for v4.9-rc1] media updates

Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v4.9-1 For media patches for Kernel 4.9: - Documentation improvements: conversion of all non-DocBook documents to Sphinx and lots of fixes to the uAPI media book; - New PCI driver for

Re: [RFC PATCH 00/11] Introduce writeback connectors

On Tue, Oct 11, 2016 at 03:53:57PM +0100, Brian Starkey wrote: > Hi, > > This RFC series introduces a new connector type: > DRM_MODE_CONNECTOR_WRITEBACK > It is a follow-on from a previous discussion: [1] > > Writeback connectors are used to expose the memory writeback engines > found in some

Re: [RFC PATCH 02/11] drm/fb-helper: Skip writeback connectors

On Tue, Oct 11, 2016 at 05:44:48PM +0200, Daniel Vetter wrote: On Tue, Oct 11, 2016 at 03:53:59PM +0100, Brian Starkey wrote: Writeback connectors aren't much use to the fbdev helpers, as they won't show anything to the user. Skip them when looking for candidate output configurations.

Re: [RFC PATCH 04/11] drm: Add __drm_framebuffer_remove_atomic

On Tue, Oct 11, 2016 at 03:54:01PM +0100, Brian Starkey wrote: > Implement the CRTC/Plane disable functionality of drm_framebuffer_remove > using the atomic API, and use it if possible. > > For atomic drivers, this removes the possibility of several commits when > a framebuffer is in use by more

Re: [RFC PATCH 00/11] Introduce writeback connectors

On Tue, Oct 11, 2016 at 6:43 PM, Brian Starkey wrote: > Hi Daniel, > > Firstly thanks very much for having a look. > > > On Tue, Oct 11, 2016 at 05:43:59PM +0200, Daniel Vetter wrote: >> >> On Tue, Oct 11, 2016 at 03:53:57PM +0100, Brian Starkey wrote: >>> >>> Hi, >>> >>>

Re: [RFC PATCH 00/11] Introduce writeback connectors

Brian Starkey writes: > Hi, > > This RFC series introduces a new connector type: > DRM_MODE_CONNECTOR_WRITEBACK > It is a follow-on from a previous discussion: [1] > > Writeback connectors are used to expose the memory writeback engines > found in some display

Re: [RFC PATCH 00/11] Introduce writeback connectors

Hi, On Tue, Oct 11, 2016 at 07:01:33PM +0200, Daniel Vetter wrote: On Tue, Oct 11, 2016 at 6:43 PM, Brian Starkey wrote: Hi Daniel, Firstly thanks very much for having a look. On Tue, Oct 11, 2016 at 05:43:59PM +0200, Daniel Vetter wrote: On Tue, Oct 11, 2016 at

Re: [RFC 0/6] Module for tracking/accounting shared memory buffers

On Tue, Oct 11, 2016 at 04:50:04PM -0700, Ruchi Kandoi wrote: > memtrack maintains a per-process list of shared buffer references, which is > exported to userspace as /proc/[pid]/memtrack. Buffers can be optionally > "tagged" with a short string: for example, Android userspace would use this >

[RFC 2/6] drivers: misc: add memtrack

Shared-buffer allocators like ion or GEM traditionally call into CMA or alloc_pages() to get backing memory, meaning these allocations will not show up in any process's mm counters. But since these allocations are often used for things like graphics buffers that can be extremely large, the user

[RFC 3/6] dma-buf: add memtrack support

Signed-off-by: Greg Hackmann Signed-off-by: Ruchi Kandoi --- drivers/dma-buf/dma-buf.c | 37 ++ drivers/staging/android/ion/ion.c | 14 + drivers/staging/android/ion/ion_priv.h | 2 ++

[RFC 6/6] drivers: staging: ion: add ION_IOC_TAG ioctl

From: Greg Hackmann ION_IOC_TAG provides a userspace interface for tagging buffers with their memtrack usage after allocation. Signed-off-by: Ruchi Kandoi --- drivers/staging/android/ion/ion-ioctl.c | 17 +

[RFC 1/6] fs: add installed and uninstalled file_operations

These optional file_operations notify a file implementation when it is installed or uninstalled from a task's fd table. This can be used for accounting of file-backed shared resources like dma-buf. This involves some changes to the __fd_install() and __close_fd() APIs to actually pass along the

[RFC 0/6] Module for tracking/accounting shared memory buffers

This patchstack introduces a new "memtrack" module for tracking and accounting memory exported to userspace as shared buffers, like dma-buf fds or GEM handles. Any process holding a reference to these buffers will keep the kernel from reclaiming its backing pages. mm counters don't provide a

[RFC 5/6] memtrack: Add memtrack accounting for forked processes.

When a process is forked, all the buffers are shared with the forked process too. Adds the functionality to add memtrack accounting for the forked processes. Forked process gets a copy of the mapped pages of the parent process. This patch makes sure that the new mapped pages are attributed to the

[RFC 4/6] memtrack: Adds the accounting to keep track of all mmaped/unmapped pages.

Since mmaped pages will be accounted by the PSS, memtrack needs a way to differentiate the total memory that hasn't been accounted for. Signed-off-by: Ruchi Kandoi Signed-off-by: Greg Hackmann --- drivers/misc/memtrack.c | 175

Re: [PATCH v2 28/31] cpia2_usb: don't use stack for DMA

Hi, > The USB control messages require DMA to work. We cannot pass > a stack-allocated buffer, as it is not warranted that the > stack would be into a DMA enabled area. > > Signed-off-by: Mauro Carvalho Chehab > Signed-off-by: Mauro Carvalho Chehab

Re: [RFC 0/6] Module for tracking/accounting shared memory buffers

On Tue, Oct 11, 2016 at 7:50 PM, Ruchi Kandoi wrote: > This patchstack introduces a new "memtrack" module for tracking and accounting > memory exported to userspace as shared buffers, like dma-buf fds or GEM > handles. btw, I wouldn't care much about the non-dmabuf

Re: [linux-review:Mauro-Carvalho-Chehab/Don-t-use-stack-for-DMA-transers-on-media-usb-drivers/20161011-182408 3/31] drivers/media/usb/dvb-usb/cinergyT2-core.c:174:2-8: preceding lock on line 169

Em Tue, 11 Oct 2016 23:41:53 +0200 (CEST) Julia Lawall escreveu: > On Tue, 11 Oct 2016, Mauro Carvalho Chehab wrote: > > > Em Tue, 11 Oct 2016 15:16:24 +0200 (CEST) > > Julia Lawall escreveu: > > > > > On Tue, 11 Oct 2016, Julia Lawall wrote: > > >

[PATCH v2 .1 28/31] cpia2_usb: don't use stack for DMA

The USB control messages require DMA to work. We cannot pass a stack-allocated buffer, as it is not warranted that the stack would be into a DMA enabled area. Signed-off-by: Mauro Carvalho Chehab -- v2.1: As pointed by Kosuke Tatsukawa, I forgot to replace "registers"

Re: [RFC 6/6] drivers: staging: ion: add ION_IOC_TAG ioctl

On Wednesday, October 12, 2016 7:50 AM Ruchi Kandoi wrote: > +/** > + * struct ion_fd_data - metadata passed from userspace for a handle s/fd/tag/ ? > + * @handle: a handle > + * @tag: a string describing the buffer > + * > + * For ION_IOC_TAG userspace populates the handle field with > + * the

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: Wed Oct 12 05:00:22 CEST 2016 media-tree git hash:9fce0c226536fc36c7fb0a8ca38a995be43e media_build

Re: [PATCH v2 28/31] cpia2_usb: don't use stack for DMA

Em Tue, 11 Oct 2016 22:56:06 + Kosuke Tatsukawa escreveu: > Hi, > > > The USB control messages require DMA to work. We cannot pass > > a stack-allocated buffer, as it is not warranted that the > > stack would be into a DMA enabled area. > > > > Signed-off-by: Mauro

[PATCH v2.1 03/31] cinergyT2-core: handle error code on RC query

There's no sense on decoding and generating a RC key code if there was an error on the URB control message. Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/usb/dvb-usb/cinergyT2-core.c b/drivers/media/usb/dvb-usb/cinergyT2-core.c index

Re: [linux-review:Mauro-Carvalho-Chehab/Don-t-use-stack-for-DMA-transers-on-media-usb-drivers/20161011-182408 3/31] drivers/media/usb/dvb-usb/cinergyT2-core.c:174:2-8: preceding lock on line 169

t;julia.law...@lip6.fr> > > > Subject: > > > > > > [linux-review:Mauro-Carvalho-Chehab/Don-t-use-stack-for-DMA-transers-on-medi > > > a-usb-drivers/20161011-182408 3/31] > > > drivers/media/usb/dvb-usb/cinergyT2-core.c:174:2-8: preceding l

Re: [linux-review:Mauro-Carvalho-Chehab/Don-t-use-stack-for-DMA-transers-on-media-usb-drivers/20161011-182408 3/31] drivers/media/usb/dvb-usb/cinergyT2-core.c:174:2-8: preceding lock on line 169

ot <fengguang...@intel.com> > > To: kbu...@01.org > > Cc: Julia Lawall <julia.law...@lip6.fr> > > Subject: > > > > [linux-review:Mauro-Carvalho-Chehab/Don-t-use-stack-for-DMA-transers-on-medi > > a-usb-drivers/20161011-182408 3/31] > &g

Re: [RFC PATCH 00/11] Introduce writeback connectors

On Tue, Oct 11, 2016 at 9:44 PM, Brian Starkey wrote: > Hi, > > > On Tue, Oct 11, 2016 at 07:01:33PM +0200, Daniel Vetter wrote: >> >> On Tue, Oct 11, 2016 at 6:43 PM, Brian Starkey >> wrote: >>> >>> Hi Daniel, >>> >>> Firstly thanks very much for

Re: [PATCH 2/6] ipr: use pci_irq_allocate_vectors

> "Christoph" == Christoph Hellwig writes: Christoph> Switch the ipr driver to use pci_alloc_irq_vectors. We need Christoph> to two calls to pci_alloc_irq_vectors as ipr only supports Christoph> multiple MSI-X vectors, but not multiple MSI vectors. Christoph> Otherwise this

Re: [PATCH 1/6] arcmsr: use pci_alloc_irq_vectors

> "Christoph" == Christoph Hellwig writes: Christoph> Switch the arcmsr driver to use pci_alloc_irq_vectors. We Christoph> need to two calls to pci_alloc_irq_vectors as arcmsr only Christoph> supports multiple MSI-X vectors, but not multiple MSI Christoph> vectors. Christoph>

Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts

Am 07.10.2016 um 07:56 schrieb Jani Nikula : > On Thu, 06 Oct 2016, Mauro Carvalho Chehab wrote: >> Em Thu, 06 Oct 2016 17:21:36 +0300 >> Jani Nikula escreveu: >>> We've seen what happens when we make it easy to add random