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: [Intel-gfx] [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: [Intel-gfx] [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: [Intel-gfx] [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: [Intel-gfx] [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: [Intel-gfx] [PATCH v2] Idleness DRRS test

On Fri, Sep 23, 2016 at 06:10:29PM +0530, Nautiyal Ankit wrote: > From: Ramalingam C > > Idleness DRRS: > By default the DRRS state will be at DRRS_HIGH_RR. When a Display > content is Idle for more than 1Sec Idleness will be declared and > DRRS_LOW_RR

Re: [Intel-gfx] [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: [Intel-gfx] [PATCH 03/11] drm/msm: Remove call to reservation_object_test_signaled_rcu before wait

On Fri, Sep 23, 2016 at 8:55 AM, Daniel Vetter wrote: > On Mon, Aug 29, 2016 at 08:08:26AM +0100, Chris Wilson wrote: >> Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a >> timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not >> need to

Re: [Intel-gfx] [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: [Intel-gfx] [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: [Intel-gfx] [PATCH 05/11] drm/vmwgfx: Remove call to reservation_object_test_signaled_rcu before wait

On Mon, Aug 29, 2016 at 08:08:28AM +0100, Chris Wilson wrote: > Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a > timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not > need to handle such conversion in the caller. The only challenge are > those callers that

Re: [Intel-gfx] [PATCH 03/11] drm/msm: Remove call to reservation_object_test_signaled_rcu before wait

On Mon, Aug 29, 2016 at 08:08:26AM +0100, Chris Wilson wrote: > Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a > timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not > need to handle such conversion in the caller. The only challenge are > those callers that

Re: [Intel-gfx] [PATCH 04/11] drm/nouveau: Remove call to reservation_object_test_signaled_rcu before wait

On Mon, Aug 29, 2016 at 08:08:27AM +0100, Chris Wilson wrote: > Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a > timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not > need to handle such conversion in the caller. The only challenge are > those callers that

Re: [Intel-gfx] [PATCH 02/11] drm/etnaviv: Remove manual call to reservation_object_test_signaled_rcu before wait

On Mon, Aug 29, 2016 at 08:08:25AM +0100, Chris Wilson wrote: > Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a > timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not > need to handle such conversion in the caller. The only challenge are > those callers that

Re: [Intel-gfx] [PATCH 01/11] drm/amdgpu: Remove call to reservation_object_test_signaled_rcu before wait

On Mon, Aug 29, 2016 at 08:08:24AM +0100, Chris Wilson wrote: > Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a > timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not > need to handle such conversion in the caller. The only challenge are > those callers that

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/audio: audio cleanups, 4k fixes (rev2)

== Series Details == Series: drm/i915/audio: audio cleanups, 4k fixes (rev2) URL : https://patchwork.freedesktop.org/series/12754/ State : success == Summary == Series 12754v2 drm/i915/audio: audio cleanups, 4k fixes https://patchwork.freedesktop.org/api/1.0/series/12754/revisions/2/mbox/

[Intel-gfx] [PATCH v2] Idleness DRRS test

From: Ramalingam C Idleness DRRS: By default the DRRS state will be at DRRS_HIGH_RR. When a Display content is Idle for more than 1Sec Idleness will be declared and DRRS_LOW_RR will be invoked, changing the refresh rate to the lower most

[Intel-gfx] [PATCH v2 7/9] drm/i915/audio: add register macros for audio config N value

Have generic macros in line with the rest of the register bit definition macros instead of a dedicated function in intel_audio.c, and use them. No functional changes. Cc: Libin Yang Signed-off-by: Jani Nikula ---

[Intel-gfx] [PATCH v2 8/9] drm/i915/audio: rename N value getter to emphasize it's for hdmi

We'll be getting a function and a table for dp parameters soon enough, so rename the function and table for hdmi. No functional changes. Cc: Libin Yang Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_audio.c | 16 1

[Intel-gfx] [PATCH v2 3/9] drm/i915/audio: use the same code for updating audio config

It gets fragile to duplicate the code for updating HSW_AUD_CFG. The only change should be that the hdmi pixel clock is also updated in i915_audio_component_sync_audio_rate(), but it should not be any different. Cc: Libin Yang Signed-off-by: Jani Nikula

[Intel-gfx] [PATCH v2 1/9] drm/i915/audio: abstract audio config update

Prepare for using the same code for updating HSW_AUD_CFG register. No functional changes. Cc: Libin Yang Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_audio.c | 68 ++ 1 file changed, 40

[Intel-gfx] [PATCH v2 6/9] drm/i915/audio: HDMI audio gets the TMDS clock by crtc_clock

From: Libin Yang HDMI audio should use crtc_clock to get the TMDS clock. This patch renames mode to adjusted_mode to unify the name. Reviewed-by: Ville Syrjälä Signed-off-by: Libin Yang Signed-off-by: Jani

[Intel-gfx] [PATCH v2 9/9] drm/i915: set proper N/M in modeset

When modeset occurs and the LS_CLK is set to some special values in DP mode, the N/M need to be set manually if audio is playing. Otherwise the first several seconds may be silent in audio playback. The relationship of Maud and Naud is expressed in the following equation: Maud/Naud = 512 * fs /

[Intel-gfx] [PATCH v2 2/9] drm/i915/audio: port is going to be just fine, simplify checks

If it was wrong, we'd be screwed already. Cc: Libin Yang Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_audio.c | 12 ++-- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_audio.c

[Intel-gfx] [PATCH v2 5/9] drm/i915/audio: set proper N/MCTS on more platforms

From: Libin Yang This patch applies setting proper N/M, N/CTS on more platforms. Reviewed-by: Ville Syrjälä Signed-off-by: Libin Yang Signed-off-by: Jani Nikula ---

[Intel-gfx] [PATCH v2 4/9] drm/i915/audio: split dp and hdmi audio config update

The code for dp and hdmi are already different, and they're about to diverge even more. Split them for clarity in future work. No functional changes. Cc: Libin Yang Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_audio.c | 55

[Intel-gfx] [PATCH v2 0/9] drm/i915/audio: audio cleanups, 4k fixes

This is v2 of [1], basically just a rebase on top of current nightly. BR, Jani. [1] https://patchwork.freedesktop.org/series/12754/ Jani Nikula (7): drm/i915/audio: abstract audio config update drm/i915/audio: port is going to be just fine, simplify checks drm/i915/audio: use the same

Re: [Intel-gfx] [PATCH 07/15] drm/omap: Use per-plane rotation property

On 12/08/16 19:04, Ville Syrjälä wrote: > On Thu, Aug 11, 2016 at 04:33:32PM +0300, Ville Syrjälä wrote: >> On Thu, Aug 11, 2016 at 02:32:44PM +0300, Tomi Valkeinen wrote: >>> Hi, >>> >>> On 22/07/16 16:43, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä

Re: [Intel-gfx] [PATCH] drm: Convert prime dma-buf <-> handle to rhashtable

On Thu, Sep 22, 2016 at 7:43 AM, Chris Wilson wrote: > Currently we use a linear walk to lookup a handle and return a dma-buf, > and vice versa. A long overdue TODO task is to convert that to a > hashtable. Since the initial implementation of dma-buf/prime, we now > have

Re: [Intel-gfx] [PATCH v2] drm/i915/bxt: Broxton decoupled MMIO

Hi, On 19/09/2016 18:15, Praveen Paneri wrote: Decoupled MMIO is an alternative way to access forcewake domain registers, which requires less cycles and avoids frequent software forcewake. I would like to see a sentence or two on how it works here. v2: - Moved platform check out of the

Re: [Intel-gfx] [CI 10/21] drm/i915: Mark up all locked waiters

On Thu, Sep 22, 2016 at 04:05:51PM -0300, Paulo Zanoni wrote: > Em Qua, 2016-09-14 às 09:40 +0100, ch...@chris-wilson.co.uk escreveu: > > On Tue, Sep 13, 2016 at 03:21:48PM +0300, Mika Kuoppala wrote: > > > > > > Mika Kuoppala writes: > > > > > > > > "Zanoni,

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Fix plane type uabi breakage

== Series Details == Series: drm: Fix plane type uabi breakage URL : https://patchwork.freedesktop.org/series/12816/ State : success == Summary == Series 12816v1 drm: Fix plane type uabi breakage https://patchwork.freedesktop.org/api/1.0/series/12816/revisions/1/mbox/ Test kms_busy:

Re: [Intel-gfx] [PATCH] drm: Fix plane type uabi breakage

On Thu, Sep 22, 2016 at 11:44 PM, Jani Nikula wrote: > On Fri, 23 Sep 2016, Daniel Vetter wrote: >> Turns out assuming that only stuff in uabi is uabi is a bit naive, and >> we have a bunch of properties for which the enum values are placed in

Re: [Intel-gfx] [PATCH] drm: Fix plane type uabi breakage

On 09/23/2016 12:05 PM, Daniel Vetter wrote: Turns out assuming that only stuff in uabi is uabi is a bit naive, and we have a bunch of properties for which the enum values are placed in random headers. A proper fix would be to split out uapi include headers, but meanwhile sprinkle at least

Re: [Intel-gfx] [PATCH] drm: Fix plane type uabi breakage

On Fri, 23 Sep 2016, Daniel Vetter wrote: > Turns out assuming that only stuff in uabi is uabi is a bit naive, and > we have a bunch of properties for which the enum values are placed in > random headers. A proper fix would be to split out uapi include > headers, but

[Intel-gfx] [PATCH] drm: Fix plane type uabi breakage

Turns out assuming that only stuff in uabi is uabi is a bit naive, and we have a bunch of properties for which the enum values are placed in random headers. A proper fix would be to split out uapi include headers, but meanwhile sprinkle at least some warning over them. Fixes: 532b36712ddf