[PATCH] [media] coda: add missing header dependencies

We get 1 warning when building kernel with W=1: drivers/media/platform/coda/coda-h264.c:21:5: warning: no previous prototype for 'coda_h264_padding' [-Wmissing-prototypes] In fact, this function is declared in drivers/media/platform/coda/coda.h, so this patch adds missing header dependencies.

[PATCH] dma-buf/sw_sync: mark sync_timeline_create() static

We get 1 warning when building kernel with W=1: drivers/dma-buf/sw_sync.c:87:23: warning: no previous prototype for 'sync_timeline_create' [-Wmissing-prototypes] In fact, this function is only used in the file in which it is declared and don't need a declaration, but can be made static. So this

[PATCH 2/2] media: mt9m111: add regulator support

In the soc_camera removal, the board specific power callback was dropped. This at least will remove the power optimization from ezx and em-x270 pxa based boards. As to recreate the same level of functionality, make the mt9m111 have a regulator providing it its power, so that board designers can

[PATCH 1/2] media: platform: pxa_camera: add missing sensor power on

During sensors binding, there is a window where the sensor is switched off, while there is a call it to set a new format, which can end up in an access to the sensor, especially an I2C based sensor. Remove this window by activating the sensor. Signed-off-by: Robert Jarzmik

Re: [PATCH] pxa_camera: merge soc_mediabus.c into pxa_camera.c

Hans Verkuil writes: >> Hi Hans, >> >> I wonder why you chose to copy-paste this code instead of adding in the >> Kconfig >> a "depends on !SOC_CAMERA". Any specific reason ? As this will have to be >> dealt >> with later anyway as you pointed out earlier, this format

Re: [Intel-gfx] [PATCH 11/11] dma-buf: Do a fast lockless check for poll with timeout=0

Am 23.09.2016 um 17:20 schrieb Chris Wilson: On Fri, Sep 23, 2016 at 03:50:44PM +0200, Daniel Vetter wrote: On Mon, Aug 29, 2016 at 08:08:34AM +0100, Chris Wilson wrote: Currently we install a callback for performing poll on a dma-buf, irrespective of the timeout. This involves taking a

Re: [Intel-gfx] [PATCH 11/11] dma-buf: Do a fast lockless check for poll with timeout=0

On Fri, Sep 23, 2016 at 03:50:44PM +0200, Daniel Vetter wrote: > On Mon, Aug 29, 2016 at 08:08:34AM +0100, Chris Wilson wrote: > > Currently we install a callback for performing poll on a dma-buf, > > irrespective of the timeout. This involves taking a spinlock, as well as > > unnecessary work,

Re: [Intel-gfx] [PATCH 11/11] dma-buf: Do a fast lockless check for poll with timeout=0

On Fri, Sep 23, 2016 at 03:50:44PM +0200, Daniel Vetter wrote: > On Mon, Aug 29, 2016 at 08:08:34AM +0100, Chris Wilson wrote: > > Currently we install a callback for performing poll on a dma-buf, > > irrespective of the timeout. This involves taking a spinlock, as well as > > unnecessary work,

Re: [Intel-gfx] [PATCH 11/11] dma-buf: Do a fast lockless check for poll with timeout=0

On Fri, Sep 23, 2016 at 03:50:44PM +0200, Daniel Vetter wrote: > On Mon, Aug 29, 2016 at 08:08:34AM +0100, Chris Wilson wrote: > > Currently we install a callback for performing poll on a dma-buf, > > irrespective of the timeout. This involves taking a spinlock, as well as > > unnecessary work,

Re: [Linaro-mm-sig] [PATCH 10/11] dma-buf: Use seqlock to close RCU race in test_signaled_single

On Fri, Sep 23, 2016 at 03:49:26PM +0200, Daniel Vetter wrote: > On Mon, Aug 29, 2016 at 08:08:33AM +0100, Chris Wilson wrote: > > With the seqlock now extended to cover the lookup of the fence and its > > testing, we can perform that testing solely under the seqlock guard and > > avoid the

Re: [Intel-gfx] [PATCH 11/11] dma-buf: Do a fast lockless check for poll with timeout=0

On Mon, Aug 29, 2016 at 08:08:34AM +0100, Chris Wilson wrote: > Currently we install a callback for performing poll on a dma-buf, > irrespective of the timeout. This involves taking a spinlock, as well as > unnecessary work, and greatly reduces scaling of poll(.timeout=0) across > multiple

Re: [Linaro-mm-sig] [PATCH 10/11] dma-buf: Use seqlock to close RCU race in test_signaled_single

On Mon, Aug 29, 2016 at 08:08:33AM +0100, Chris Wilson wrote: > With the seqlock now extended to cover the lookup of the fence and its > testing, we can perform that testing solely under the seqlock guard and > avoid the effective locking and serialisation of acquiring a reference to > the

Re: [PATCH 09/11] dma-buf: Restart reservation_object_test_signaled_rcu() after writes

On Mon, Aug 29, 2016 at 08:08:32AM +0100, Chris Wilson wrote: > In order to be completely generic, we have to double check the read > seqlock after acquiring a reference to the fence. If the driver is > allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then > within an RCU grace

Re: [PATCH 06/11] dma-buf: Introduce fence_get_rcu_safe()

Am 23.09.2016 um 14:59 schrieb Daniel Vetter : >> >> /** >> - * fence_put - decreases refcount of the fence >> - * @fence: [in]fence to reduce refcount of >> + * fence_get_rcu_safe - acquire a reference to an RCU tracked fence >> + * @fence: [in]pointer to fence to

Re: [PATCH 08/11] dma-buf: Restart reservation_object_wait_timeout_rcu() after writes

On Mon, Aug 29, 2016 at 08:08:31AM +0100, Chris Wilson wrote: > In order to be completely generic, we have to double check the read > seqlock after acquiring a reference to the fence. If the driver is > allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then > within an RCU grace

Re: [PATCH 07/11] dma-buf: Restart reservation_object_get_fences_rcu() after writes

On Mon, Aug 29, 2016 at 08:08:30AM +0100, Chris Wilson wrote: > In order to be completely generic, we have to double check the read > seqlock after acquiring a reference to the fence. If the driver is > allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then > within an RCU grace

Re: [PATCH 06/11] dma-buf: Introduce fence_get_rcu_safe()

On Mon, Aug 29, 2016 at 08:08:29AM +0100, Chris Wilson wrote: > This variant of fence_get_rcu() takes an RCU protected pointer to a > fence and carefully returns a reference to the fence ensuring that it is > not reallocated as it does. This is required when mixing fences and > SLAB_DESTROY_BY_RCU

Re: [PATCH v1.1 5/5] smiapp: Implement support for autosuspend

Sebastian Reichel wrote: Hi, On Tue, Sep 20, 2016 at 03:29:58PM +0300, Sakari Ailus wrote: Delay suspending the device by 1000 ms by default. Signed-off-by: Sakari Ailus --- since v1: - Increment usage count before register write using

Re: g_webcam Isoch high bandwidth transfer

Hi, yfw writes: >> Here's one that actually compiles, sorry about that. > > No worries, I was sleeping ;-) > > I will test it out early next week. Thanks. meanwhile, how about some instructions on how to test this out myself? How are you

Re: g_webcam Isoch high bandwidth transfer

Hi Felipe, On 2016/9/23 15:49, Felipe Balbi wrote: Hi, Bin Liu writes: +Fengwei Yin per his request. On Thu, Sep 22, 2016 at 10:48:40PM +0300, Felipe Balbi wrote: Hi, Bin Liu writes: [...] Here's one that actually compiles, sorry about that. No worries,

Re: g_webcam Isoch high bandwidth transfer

Hi, Bin Liu writes: > +Fengwei Yin per his request. > > On Thu, Sep 22, 2016 at 10:48:40PM +0300, Felipe Balbi wrote: >> >> Hi, >> >> Bin Liu writes: >> >> [...] >> >> >> Here's one that actually compiles, sorry about that. >> > >> > No worries, I was sleeping

Re: [RFC PATCH 6/7] atmel-isi: remove dependency of the soc-camera framework

On 9/21/2016 15:04, Hans Verkuil wrote: On 08/18/2016 07:53 AM, Wu, Songjun wrote: Hi Hans, Thank you for the patch. On 8/17/2016 14:29, Hans Verkuil wrote: From: Hans Verkuil This patch converts the atmel-isi driver from a soc-camera driver to a driver that is