Re: [Intel-gfx] [PATCH] drm/i915: Don't try to handle GuC when GuC is not supported.

Em Qua, 2016-09-21 às 11:22 -0700, Rodrigo Vivi escreveu: > Avoid any kind of GuC handling if GuC is not supported > on a giving platform. > > Besides being useless handling, our driver needs > to be smarter than the user trying to use an invalid paramenter. So the problem is when a platform

Re: [Intel-gfx] [PATCH v4] drm/i915/bxt: Implement Transition WM

Em Qua, 2016-09-14 às 17:24 +0530, Kumar, Mahesh escreveu: > From: Mahesh Kumar > > This patch enables Transition WM for SKL+ platforms. > > Transition WM are used if IPC is enabled, to decide, number of blocks > to be fetched before reducing the priority of display to

Re: [Intel-gfx] [PATCH v3 8/9] drm/i915/bxt: set chicken bit as IPC y-tile WA

Em Sex, 2016-09-09 às 13:31 +0530, Kumar, Mahesh escreveu: > From: Mahesh Kumar > > It implements the WA to enable IDLE_WAKEMEM bit of CHICKEN_DCPR_1 > register for Broxton platform. When IPC is enabled & Y-tile is > enabled in any of the enabled plane, above bit should

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: DP audio API changes for MST (rev8)

== Series Details == Series: drm/i915/dp: DP audio API changes for MST (rev8) URL : https://patchwork.freedesktop.org/series/10571/ State : success == Summary == Series 10571v8 drm/i915/dp: DP audio API changes for MST https://patchwork.freedesktop.org/api/1.0/series/10571/revisions/8/mbox/

Re: [Intel-gfx] [PATCH v3 7/9] drm/i915/bxt: Enable IPC support

Hi Lots of nitpicking in my review. Feel free to disagree with them. Em Sex, 2016-09-09 às 13:31 +0530, Kumar, Mahesh escreveu: > From: Mahesh Kumar > > This patch adds IPC support for platforms. This patch enables IPC > only for BXT platform as for SKL recommendation

[Intel-gfx] [CI-1 v5] drm/i915/dp: DP audio API changes for MST

From: "Pandiyan, Dhinakaran" DP MST provides the capability to send multiple video and audio streams through a single port. This requires the API's between i915 and audio drivers to distinguish between multiple audio capable displays that can be connected to a

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/audio: audio cleanups, 4k fixes

== Series Details == Series: drm/i915/audio: audio cleanups, 4k fixes URL : https://patchwork.freedesktop.org/series/12754/ State : warning == Summary == Series 12754v1 drm/i915/audio: audio cleanups, 4k fixes https://patchwork.freedesktop.org/api/1.0/series/12754/revisions/1/mbox/ Test

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Don't try to handle GuC when GuC is not supported.

== Series Details == Series: drm/i915: Don't try to handle GuC when GuC is not supported. URL : https://patchwork.freedesktop.org/series/12753/ State : success == Summary == Series 12753v1 drm/i915: Don't try to handle GuC when GuC is not supported.

Re: [Intel-gfx] [PATCH v4 0/3] drm/i915: fix some audio support 4K resolution issues

On Mon, 12 Sep 2016, "Yang, Libin" wrote: > Any comments? Apologies for the way too long delay. I felt it would have been unfair to ask you to do the changes I thought were necessary after such a delay, so I sent them as patches... The last one still needs review, but at

[Intel-gfx] [PATCH 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 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 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 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 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 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 9/9] drm/i915: set proper N/M in modeset

From: Libin Yang 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

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

I started to review Libin's series at [1], but decided that intel_audio.c is badly in need of some cleanup before moving forward with the patches. I think the prep work makes Libin's patches cleaner too. I ended up rebasing the patches myself, but it was a rather quick job, with no testing, so

[Intel-gfx] [PATCH 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 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

Re: [Intel-gfx] [PATCH v3 6/9] drm/i915/skl+: change WM calc to fixed point 16.16

Hi Em Sex, 2016-09-09 às 13:31 +0530, Kumar, Mahesh escreveu: > From: Mahesh Kumar First of all, good catch with this patch! > > This patch changes Watermak calculation to fixed point calculation. > Problem with current calculation is during plane_blocks_per_line >

[Intel-gfx] [PATCH] drm/i915: Don't try to handle GuC when GuC is not supported.

Avoid any kind of GuC handling if GuC is not supported on a giving platform. Besides being useless handling, our driver needs to be smarter than the user trying to use an invalid paramenter. Cc: Jani Nikula Cc: Anusha Srivatsa Cc: Christophe

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/3] drm/i915: Restore current RPS state after reset

== Series Details == Series: series starting with [CI,1/3] drm/i915: Restore current RPS state after reset URL : https://patchwork.freedesktop.org/series/12741/ State : failure == Summary == Series 12741v1 Series without cover letter

Re: [Intel-gfx] [PATCH 0/7] drm/i915: Add pipe scaler for Gen9 in atomic path

Hi, On 9/20/2016 1:55 PM, Ville Syrjälä wrote: On Tue, Aug 30, 2016 at 10:30:54AM +0530, Nabendu Maiti wrote: Following patch series add pipe scaler functionality in atomic path.The pipe scaler can be changed dynamically without modeset.Apart from default panel fitter supported scaling modes

Re: [Intel-gfx] [PATCH v3 1/9] drm/i915/skl: pass pipe_wm in skl_compute_(wm_level/plane_wm) functions

Em Qua, 2016-09-21 às 19:18 +0530, Mahesh Kumar escreveu: > there are two main reason I want to pass complete pipe_wm to compute  > function > > 1. for transition WM calculation, else we need to pass  > trans_wm.plane_res_b &  trans_wm.plane_res_l also as a parameter, > >  that will increase

[Intel-gfx] [CI 1/3] drm/i915: Restore current RPS state after reset

Following commit 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests") we no longer mark the context as lost on reset as we keep the requests (and contexts) alive. However, RPS remains reset and we need to restore the current state to match the in-flight requests. Signed-off-by:

[Intel-gfx] [CI 3/3] drm/i915/execlists: Reset RING registers upon resume

There is a disparity in the context image saved to disk and our own bookkeeping - that is we presume the RING_HEAD and RING_TAIL match our stored ce->ring->tail value. However, as we emit WA_TAIL_DWORDS into the ring but may not tell the GPU about them, the GPU may be lagging behind our

[Intel-gfx] [CI 2/3] drm/i915: Only shrink the unbound objects during freeze

At the point of creating the hibernation image, the runtime power manage core is disabled - and using the rpm functions triggers a warn. i915_gem_shrink_all() tries to unbind objects, which requires device access and so tries to how an rpm reference triggering a warning: [ 44.235420]

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Queue page flip work with high priority (rev3)

On ti, 2016-09-20 at 12:24 +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Queue page flip work with high priority (rev3) > URL   : https://patchwork.freedesktop.org/series/12336/ > State : warning > > == Summary == > > Series 12336v3 drm/i915: Queue page flip work with

Re: [Intel-gfx] [PATCH v3 1/9] drm/i915/skl: pass pipe_wm in skl_compute_(wm_level/plane_wm) functions

there are two main reason I want to pass complete pipe_wm to compute function 1. for transition WM calculation, else we need to pass trans_wm.plane_res_b & trans_wm.plane_res_l also as a parameter, that will increase the parameter-list. And trans_wm will be used (calculation will

Re: [Intel-gfx] [PATCH v4] drm/i915/skl: New ddb allocation algorithm

Hi Maarten, thanks for pointing out the issue, not only start value, end value is also incorrect. I got the root-cause for both. but this end value issue seems to be always there. end value should be -1 (because start block should also be counted) Will fix both & upload the reworked patches.

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v2,RESEND,1/2] drm/i915: Cleanup instdone collection

On ti, 2016-09-20 at 14:23 +, Patchwork wrote: > == Series Details == > > Series: series starting with [v2,RESEND,1/2] drm/i915: Cleanup > instdone collection > URL   : https://patchwork.freedesktop.org/series/12714/ > State : warning > > == Summary == > > Series 12714v1 Series without

Re: [Intel-gfx] [PATCH 13/38] drm/i915: Markup GEM API with lockdep asserts

On ti, 2016-09-20 at 09:29 +0100, Chris Wilson wrote: > Add lockdep_assert_held(struct_mutex) to the API preamble of the > internal GEM interfaces. > Heck yeah! Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center

Re: [Intel-gfx] [PATCH 11/38] drm/i915: Introduce an internal allocator for disposable private objects

On ti, 2016-09-20 at 09:29 +0100, Chris Wilson wrote: > Quite a few of our objects used for internal hardware programming do not > benefit from being swappable or from being zero initialised. As such > they do not benefit from using a shmemfs backing storage and since they > are internal and never

Re: [Intel-gfx] [PATCH v12 5/7] drm/i915/skl: Ensure pipes with changed wms get added to the state

I've raised https://bugs.freedesktop.org/show_bug.cgi?id=97888 I'll attach the info you requested once I get back to my machine On 21 September 2016 at 07:56, Maarten Lankhorst wrote: > Hey, > > Op 20-09-16 om 20:45 schreef Mike Lothian: >> Hi >> >> I've

Re: [Intel-gfx] [PATCH] drm: Fix typo in encoder docs

On Mon, Sep 19, 2016 at 03:40:48PM -0700, Dhinakaran Pandiyan wrote: > Corrected typo in bridge and encoder comparison. Also, added a one-line > encoder description from the previous documentation. > > Cc: Daniel Vetter > Cc: Archit Taneja > >

Re: [Intel-gfx] [PATCH 10/38] drm/i915: Defer active reference until required

Kerneldoc could help with getting grip of the convention introduced here. Does this really have visible results in real world workloads? It adds further complexity. On ti, 2016-09-20 at 09:29 +0100, Chris Wilson wrote: > @@ -2383,6 +2390,28 @@ i915_gem_object_has_active_engine(const struct >

Re: [Intel-gfx] [PATCH 08/38] drm/i915: Rearrange i915_wait_request() accounting with callers

On ti, 2016-09-20 at 09:29 +0100, Chris Wilson wrote: > Our low-level wait routine has evolved from our generic wait interface > that handled unlocked, RPS boosting, waits with time tracking. If we > push our GEM fence tracking to use reservation_objects (required for > handling multiple

Re: [Intel-gfx] [PATCH 06/38] drm/i915: Support asynchronous waits on struct fence from i915_gem_request

On ti, 2016-09-20 at 09:29 +0100, Chris Wilson wrote: > + if (!fence_is_array(fence)) { > + ret = i915_sw_fence_await_dma_fence(>submit, > + fence, 10*HZ, #define I915_MAX_USERSPACE_WAIT or something. We already have two instances of

Re: [Intel-gfx] [PATCH 05/38] drm/i915: Compress GPU objects in error state

On ti, 2016-09-20 at 09:29 +0100, Chris Wilson wrote: > @@ -175,6 +176,110 @@ static void i915_error_puts(struct > drm_i915_error_state_buf *e, >  #define err_printf(e, ...) i915_error_printf(e, __VA_ARGS__) >  #define err_puts(e, s) i915_error_puts(e, s) >   > +#ifdef

Re: [Intel-gfx] [PATCH 04/10] drm: Extract drm_plane.[hc]

On Mon, Sep 19, 2016 at 4:11 PM, Daniel Vetter wrote: > On Tue, Sep 06, 2016 at 12:59:31PM -0400, Sean Paul wrote: >> On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter >> wrote: >> > Just pure code movement, cleanup and polish will happen in later >> >

Re: [Intel-gfx] [PATCH 25/38] drm: Add reference counting to drm_atomic_state

On Tue, Sep 20, 2016 at 11:29 AM, Chris Wilson wrote: > drm_atomic_state has a complicated single owner model that tracks the > single reference from allocation through to destruction on another > thread - or perhaps on a local error path. We can simplify this tracking >

Re: [Intel-gfx] [PATCH 03/38] drm/i915: Always use the GTT for error capture

On ti, 2016-09-20 at 09:29 +0100, Chris Wilson wrote:  > + /* Reserve a mappable slot for our lockless error capture */ > + ret = drm_mm_insert_node_in_range_generic(>base.mm, > +   >gpu_error, 'error_page' would arguably be better name, or

Re: [Intel-gfx] [PATCH v12 5/7] drm/i915/skl: Ensure pipes with changed wms get added to the state

Will do. On Wed, 21 Sep 2016 at 07:56 Maarten Lankhorst < maarten.lankho...@linux.intel.com> wrote: > Hey, > > Op 20-09-16 om 20:45 schreef Mike Lothian: > > Hi > > > > I've bisected back to this commit in the drm-intel-nightly branch > > > > 05a76d3d6ad1ee9f9814f88949cc9305fc165460 is the first

Re: [Intel-gfx] [PATCH v12 5/7] drm/i915/skl: Ensure pipes with changed wms get added to the state

Hey, Op 20-09-16 om 20:45 schreef Mike Lothian: > Hi > > I've bisected back to this commit in the drm-intel-nightly branch > > 05a76d3d6ad1ee9f9814f88949cc9305fc165460 is the first bad commit > commit 05a76d3d6ad1ee9f9814f88949cc9305fc165460 > Author: Lyude > Date: Wed Aug 17

Re: [Intel-gfx] [PATCH 05/10] drm/doc: Polish for drm_plane.[hc]

On 09/19/2016 06:43 PM, Daniel Vetter wrote: On Fri, Sep 02, 2016 at 03:00:38PM +0530, Archit Taneja wrote: On 8/31/2016 9:39 PM, Daniel Vetter wrote: Big thing is untangling and carefully documenting the different uapi types of planes. I also sprinkled a few more cross references around

Re: [Intel-gfx] [PATCH 01/38] drm/i915: Allow disabling error capture

On ti, 2016-09-20 at 09:29 +0100, Chris Wilson wrote: > We currently capture the GPU state after we detect a hang. This is vital > for us to both triage and debug hangs in the wild (post-mortem > debugging). However, it comes at the cost of running some potentially > dangerous code (since it has