Re: [Intel-gfx] [PATCH 6/6] drm/i915: force full detect on sink count change

On Thursday 14 January 2016 07:20 PM, Ander Conselvan De Oliveira wrote: On Tue, 2016-01-05 at 18:20 +0530, Shubhangi Shrivastava wrote: This patch checks for changes in sink count between short pulse hpds and forces full detect when there is a change. This will allow both detection of

Re: [Intel-gfx] [PATCH 10/11] acpi: Export acpi_bus_type

On Mon, 2016-01-18 at 19:26 +0100, Lukas Wunner wrote: Hi, > Hi, > > On Mon, Jan 18, 2016 at 03:57:29PM +0100, Rafael J. Wysocki wrote: > > On Monday, January 18, 2016 02:31:00 PM Ankitprasad Sharma wrote: > > > On Fri, 2016-01-15 at 15:51 +0100, Rafael J. Wysocki wrote: > > > > On Thursday,

Re: [Intel-gfx] [PATCH] drm/i915: Splitting intel_dp_check_link_status

On Tue, Jan 19, 2016 at 10:14:30AM +0530, Thulasimani, Sivakumar wrote: > > > On 1/19/2016 2:35 AM, Lukas Wunner wrote: > >Hi, > > > >On Mon, Jan 18, 2016 at 04:22:19PM +0530, Shubhangi Shrivastava wrote: > >>When created originally intel_dp_check_link_status() > >>was supposed to handle only

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Splitting intel_dp_detect

On Friday 15 January 2016 03:37 PM, Ander Conselvan De Oliveira wrote: On Thu, 2016-01-14 at 19:20 +0530, Shubhangi Shrivastava wrote: On Wednesday 13 January 2016 07:03 PM, Ander Conselvan De Oliveira wrote: On Wed, 2016-01-13 at 13:20 +0200, Ander Conselvan De Oliveira wrote: On Tue,

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Fix a memory leak where guc->execbuf_client is not freed

On Mon, Jan 18, 2016 at 10:01:24AM +, Tvrtko Ursulin wrote: > > On 13/01/16 19:11, Dave Gordon wrote: > >On 13/01/16 19:01, yu@intel.com wrote: > >>From: Alex Dai > >> > >>During driver unloading, the guc_client created for command submission > >>needs to be released to

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915: abolish separate per-ring default_context pointers

On Mon, Jan 18, 2016 at 04:16:39PM +, Nick Hoath wrote: > On 07/01/2016 10:20, Dave Gordon wrote: > >Now that we've eliminated a lot of uses of ring->default_context, > >we can eliminate the pointer itself. > > > >All the engines share the same default intel_context, so we can just > >keep a

Re: [Intel-gfx] [PATCH] drm/i915: Splitting intel_dp_check_link_status

On 1/19/2016 2:14 PM, Daniel Vetter wrote: On Tue, Jan 19, 2016 at 10:14:30AM +0530, Thulasimani, Sivakumar wrote: On 1/19/2016 2:35 AM, Lukas Wunner wrote: Hi, On Mon, Jan 18, 2016 at 04:22:19PM +0530, Shubhangi Shrivastava wrote: When created originally intel_dp_check_link_status() was

Re: [Intel-gfx] [PATCH] drm/i915: Splitting intel_dp_check_link_status

On Tue, Jan 19, 2016 at 02:29:22PM +0530, Thulasimani, Sivakumar wrote: > > > On 1/19/2016 2:14 PM, Daniel Vetter wrote: > >On Tue, Jan 19, 2016 at 10:14:30AM +0530, Thulasimani, Sivakumar wrote: > >> > >>On 1/19/2016 2:35 AM, Lukas Wunner wrote: > >>>Hi, > >>> > >>>On Mon, Jan 18, 2016 at

Re: [Intel-gfx] [PATCH 5/6] drm/i915: read sink_count dpcd always

On Monday 18 January 2016 06:30 PM, Ander Conselvan De Oliveira wrote: On Mon, 2016-01-18 at 18:14 +0530, Shubhangi Shrivastava wrote: On Thursday 14 January 2016 06:34 PM, Ander Conselvan De Oliveira wrote: On Tue, 2016-01-05 at 18:20 +0530, Shubhangi Shrivastava wrote: This patch reads

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Splitting intel_dp_check_link_status

On Wednesday 13 January 2016 08:34 PM, Ander Conselvan De Oliveira wrote: On Tue, 2016-01-05 at 18:20 +0530, Shubhangi Shrivastava wrote: When created originally intel_dp_check_link_status() was supposed to handle only link training for short pulse but has grown into handler for short pulse

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Save sink_count for tracking changes to it

On Thursday 14 January 2016 06:30 PM, Ander Conselvan De Oliveira wrote: On Tue, 2016-01-05 at 18:20 +0530, Shubhangi Shrivastava wrote: Sink count can change between short pulse hpd hence this patch adds a member variable to intel_dp so we can track any changes between short pulse

Re: [Intel-gfx] [PATCH v4 1/8] drm/i915/gen9: Add framework to whitelist specific GPU registers

On Thu, Jan 14, 2016 at 03:27:35PM +, Arun Siluvery wrote: > Some of the HW registers are privileged and cannot be written to from > non-privileged batch buffers coming from userspace unless they are added to > the HW whitelist. This whitelist is maintained by HW and it is different from > SW

Re: [Intel-gfx] ✗ failure: Fi.CI.BAT

On Thu, Jan 14, 2016 at 11:31:07AM +, Nick Hoath wrote: > On 14/01/2016 07:20, Patchwork wrote: > >== Summary == Our BKM is to link to bugzilla entries to make sure these are all real failures which are tracked already. Otherwise stuff falls through the cracks. > > > >Built on

Re: [Intel-gfx] [PATCH] drm/i915: Dump power well states on unclaimed trace

On Wed, Jan 13, 2016 at 06:33:10PM +0200, Mika Kuoppala wrote: > It is beneficial to know the exact sw states of power wells > at the moment when unclaimed register access is detect. > > When the backtrace has been printed to dmesg, it is > followed by a power well states, for example: > > >

Re: [Intel-gfx] [PATCH] drm/i915: Splitting intel_dp_check_link_status

On 1/19/2016 2:35 PM, Daniel Vetter wrote: On Tue, Jan 19, 2016 at 02:29:22PM +0530, Thulasimani, Sivakumar wrote: On 1/19/2016 2:14 PM, Daniel Vetter wrote: On Tue, Jan 19, 2016 at 10:14:30AM +0530, Thulasimani, Sivakumar wrote: On 1/19/2016 2:35 AM, Lukas Wunner wrote: Hi, On Mon, Jan

Re: [Intel-gfx] [PATCH] drm/i915: Demote user facing DMC firmware load failure message

On Wed, Jan 13, 2016 at 05:41:44PM +, Damien Lespiau wrote: > On Wed, Jan 13, 2016 at 05:38:15PM +, Chris Wilson wrote: > > This is an expected error given the lack of the firmware so emit it at > > KERN_NOTICE and not KERN_ERROR. Also include the firmware URL in the > > user facing

Re: [Intel-gfx] [PATCH] drm/i915: Sink CRC: tune down error message at stop to debug_kms.

On Wed, Jan 13, 2016 at 02:05:04PM -0800, Rodrigo Vivi wrote: > When we stop the sink CRC calculation we wait a while until the counter > is reset to zero and return -ETIMEDOUT. However the sink crc was > calculated already by this point so we just ignore this return at > the main function. > >

[Intel-gfx] [PATCH 2/5] drm/i915: Cleaning up intel_dp_hpd_pulse

Current DP detection has DPCD operations split across intel_dp_hpd_pulse and intel_dp_detect which contains duplicates as well. Also intel_dp_detect is called during modes enumeration as well which will result in multiple dpcd operations. So this patch tries to solve both these by bringing all

[Intel-gfx] [PATCH 4/5] drm/i915: Save sink_count for tracking changes to it and read sink_count dpcd always

Sink count can change between short pulse hpd hence this patch adds a member variable to intel_dp so we can track any changes between short pulse interrupts. This patch reads sink_count dpcd always and removes its read operation based on values in downstream port dpcd. SINK_COUNT dpcd is not

[Intel-gfx] [PATCH 5/5] drm/i915: force full detect on sink count change

This patch checks for changes in sink count between short pulse hpds and forces full detect when there is a change. This will allow both detection of hotplug and unplug of panels through dongles that give only short pulse for such events. v2: changed variable type from u8 to bool (Jani)

[Intel-gfx] [PATCH 1/5] drm/i915: Splitting intel_dp_detect

intel_dp_detect() is called for not just detection but during modes enumeration as well. Repeating the whole sequence during each of these calls is wasteful and time consuming. This patch moves probing for panel, DPCD read etc done in intel_dp_detect() to a new function intel_dp_long_pulse(). Note

Re: [Intel-gfx] [PATCH v4 1/8] drm/i915/gen9: Add framework to whitelist specific GPU registers

On 19/01/2016 09:00, Daniel Vetter wrote: On Thu, Jan 14, 2016 at 03:27:35PM +, Arun Siluvery wrote: Some of the HW registers are privileged and cannot be written to from non-privileged batch buffers coming from userspace unless they are added to the HW whitelist. This whitelist is

[Intel-gfx] [PATCH 3/5] drm/i915: Reorganizing intel_dp_check_link_status

When created originally intel_dp_check_link_status() was supposed to handle only link training for short pulse but has grown into handler for short pulse itself. This patch cleans up this function by splitting it into two halves. First intel_dp_short_pulse() is called, which will be entry point

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Fixing sink count related detection over (rev8)

Sure Ander.. Have resent this series of patches.. Will ensure to resend the series for multiple patch changes.. :) Thanks and Regards, Shubhangi Shrivastava. -Original Message- From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com] Sent: Tuesday, January 19, 2016 3:09 PM To:

Re: [Intel-gfx] [PATCH v10] drm/i915: Extend LRC pinning to cover GPU context writeback

On 18/01/16 20:47, Chris Wilson wrote: On Mon, Jan 18, 2016 at 05:14:26PM +, Tvrtko Ursulin wrote: On 18/01/16 16:53, Chris Wilson wrote: On Mon, Jan 18, 2016 at 03:02:25PM +, Tvrtko Ursulin wrote: - while (!list_empty(>request_list)) { - struct

Re: [Intel-gfx] [RFC] drm/i915: Render decompression support for Gen9 and above

Hi, On 10 September 2015 at 16:02, Daniel Vetter wrote: > On Wed, Sep 09, 2015 at 10:04:23AM -0700, Jesse Barnes wrote: >> On 09/09/2015 09:36 AM, Smith, Gary K wrote: >> > I don't understand why this is an issue. Surely the fb is to describe >> > static state about the buffer,

[Intel-gfx] [PATCH 1/5] drm/i915: Splitting intel_dp_detect

intel_dp_detect() is called for not just detection but during modes enumeration as well. Repeating the whole sequence during each of these calls is wasteful and time consuming. This patch moves probing for panel, DPCD read etc done in intel_dp_detect() to a new function intel_dp_long_pulse(). Note

[Intel-gfx] [PATCH 3/5] drm/i915: Reorganizing intel_dp_check_link_status

When created originally intel_dp_check_link_status() was supposed to handle only link training for short pulse but has grown into handler for short pulse itself. This patch cleans up this function by splitting it into two halves. First intel_dp_short_pulse() is called, which will be entry point

[Intel-gfx] [PATCH 4/5] drm/i915: Save sink_count for tracking changes to it and read sink_count dpcd always

Sink count can change between short pulse hpd hence this patch adds a member variable to intel_dp so we can track any changes between short pulse interrupts. This patch reads sink_count dpcd always and removes its read operation based on values in downstream port dpcd. SINK_COUNT dpcd is not

[Intel-gfx] [PATCH 2/5] drm/i915: Cleaning up intel_dp_hpd_pulse

Current DP detection has DPCD operations split across intel_dp_hpd_pulse and intel_dp_detect which contains duplicates as well. Also intel_dp_detect is called during modes enumeration as well which will result in multiple dpcd operations. So this patch tries to solve both these by bringing all

[Intel-gfx] [PATCH 5/5] drm/i915: force full detect on sink count change

This patch checks for changes in sink count between short pulse hpds and forces full detect when there is a change. This will allow both detection of hotplug and unplug of panels through dongles that give only short pulse for such events. v2: changed variable type from u8 to bool (Jani)

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/5] drm/i915: Splitting intel_dp_detect

== Summary == Built on 00a0c7d1ae09b1259c7af8e5a088b0b225d805df drm-intel-nightly: 2016y-01m-18d-16h-50m-37s UTC integration manifest Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> PASS (skl-i5k-2) Test kms_pipe_crc_basic: Subgroup

Re: [Intel-gfx] [PATCH] drm/i915: skl_update_scaler() wants a rotation bitmask instead of bit number

On Mon, Jan 18, 2016 at 04:21:40PM +0200, Ville Syrjälä wrote: > On Fri, Jan 15, 2016 at 03:15:00PM -0800, Matt Roper wrote: > > On Fri, Jan 15, 2016 at 08:48:26PM +0200, Ville Syrjälä wrote: > > > On Thu, Oct 15, 2015 at 05:01:58PM +0300, ville.syrj...@linux.intel.com > > > wrote: > > > > From:

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Fixing sink count related detection over (rev8)

Hi Shubhangi, On Mon, 2016-01-18 at 13:01 +, Patchwork wrote: > == Summary == > > HEAD is now at 2dd73be drm-intel-nightly: 2016y-01m-18d-09h-59m-27s UTC > integration manifest > Applying: drm/i915: Splitting intel_dp_detect > Applying: drm/i915: Cleaning up intel_dp_hpd_pulse > Applying:

[Intel-gfx] [PATCH] drm/i915: Reorganizing intel_dp_check_link_status

When created originally intel_dp_check_link_status() was supposed to handle only link training for short pulse but has grown into handler for short pulse itself. This patch cleans up this function by splitting it into two halves. First intel_dp_short_pulse() is called, which will be entry point

Re: [Intel-gfx] [PATCH 1/7] drm/i915/skl+: Use proper bytes_per_pixel during WM calculation

On 01/15/2016 12:37 AM, Matt Roper wrote: On Thu, Jan 14, 2016 at 05:32:42PM +0530, Shobhit Kumar wrote: From: "Kumar, Mahesh" Don't always use bytes_per_pixel using y_plane=0, instead use it according to pixel format. If NV12 use y_plane eqal to 1 Signed-off-by:

[Intel-gfx] ✗ Fi.CI.BAT: failure for Fixing sink count related detection over (rev9)

== Summary == HEAD is now at 00a0c7d drm-intel-nightly: 2016y-01m-18d-16h-50m-37s UTC integration manifest Applying: drm/i915: Splitting intel_dp_detect Applying: drm/i915: Cleaning up intel_dp_hpd_pulse Applying: drm/i915: Reorganizing intel_dp_check_link_status Applying: drm/i915: Save

Re: [Intel-gfx] ✗ warning: Fi.CI.BAT

On 14/01/16 09:49, Patchwork wrote: == Summary == Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (bdw-nuci7) Test

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/5] drm/i915: Splitting intel_dp_detect

== Summary == Built on 00a0c7d1ae09b1259c7af8e5a088b0b225d805df drm-intel-nightly: 2016y-01m-18d-16h-50m-37s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (skl-i5k-2) UNSTABLE pass -> DMESG-WARN

[Intel-gfx] [PATCH v11] drm/i915: Extend LRC pinning to cover GPU context writeback

Use the first retired request on a new context to unpin the old context. This ensures that the hw context remains bound until it has been written back to by the GPU. Now that the context is pinned until later in the request/context lifecycle, it no longer needs to be pinned from context_queue to

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Extend LRC pinning to cover GPU context writeback (rev6)

== Summary == HEAD is now at 00a0c7d drm-intel-nightly: 2016y-01m-18d-16h-50m-37s UTC integration manifest Applying: drm/i915: Extend LRC pinning to cover GPU context writeback Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_drv.h M

Re: [Intel-gfx] [PATCH v4 1/8] drm/i915/gen9: Add framework to whitelist specific GPU registers

On Tue, Jan 19, 2016 at 10:16:52AM +, Arun Siluvery wrote: > On 19/01/2016 09:00, Daniel Vetter wrote: > >On Thu, Jan 14, 2016 at 03:27:35PM +, Arun Siluvery wrote: > >>Some of the HW registers are privileged and cannot be written to from > >>non-privileged batch buffers coming from

Re: [Intel-gfx] [PATCH] drm/i915: Clear pending reset requests during suspend

On Thu, Jan 14, 2016 at 10:49:45AM +, Arun Siluvery wrote: > Pending reset requests are cleared before suspending, they should be picked up > after resume when new work is submitted. > > This is originally added as part of TDR patches for Gen8 from Tomas Elf which > are under review, as

Re: [Intel-gfx] [PATCH] drm/i915: Fix NULL plane->fb oops on SKL

On Tue, Jan 19, 2016 at 06:23:17PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > In this atomic age, we can't trust the plane->fb pointer anymore. > It might get update too late. Instead we are supposed to use the > plane_state->fb pointer

Re: [Intel-gfx] [PATCH 1/2] Revert "FROM_UPSTREAM [VPG]: drm/i915/kbl: drm/i915: Avoid GuC loading for now on Kabylake."

On Tue, Jan 19, 2016 at 09:18:50PM +, Peter Antoine wrote: > This reverts commit a92d3f32eafc57cca55e654ecfd916f283100365. Shouldnt' this be patch 2/2? Enabling guc loading before it's fixed isn't awesome. Either way needs a proper commit message (why is it ok to enable now?) plus s-o-b.

Re: [Intel-gfx] [PATCH 1/2] Revert "FROM_UPSTREAM [VPG]: drm/i915/kbl: drm/i915: Avoid GuC loading for now on Kabylake."

On 01/19/2016 01:25 PM, Daniel Vetter wrote: On Tue, Jan 19, 2016 at 09:18:50PM +, Peter Antoine wrote: > This reverts commit a92d3f32eafc57cca55e654ecfd916f283100365. Shouldnt' this be patch 2/2? Enabling guc loading before it's fixed isn't awesome. Either way needs a proper commit

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix NULL plane->fb oops on SKL

On Tue, Jan 19, 2016 at 04:49:56PM -, Patchwork wrote: > == Summary == > > Built on 20c388faff9d8c41ab27e825c685526561b892a2 drm-intel-nightly: > 2016y-01m-19d-13h-31m-46s UTC integration manifest > > Test gem_storedw_loop: > Subgroup basic-render: > dmesg-warn ->

Re: [Intel-gfx] [PATCH] i915/guc: Add Kabylake GuC Loading

Yup, I missed a patch. Just sent a new sequence. Peter. -Original Message- From: Dai, Yu Sent: Tuesday, January 19, 2016 6:18 PM To: Antoine, Peter; intel-gfx@lists.freedesktop.org Cc: daniel.vet...@ffwll.ch; Gordon, Dave; Thierry, Michel Subject: Re: [PATCH] i915/guc: Add Kabylake GuC

[Intel-gfx] [PATCH 0/2] Enable GuC Loading on Kabylake

This patchset reverts the disabling of the GuC loading for Kabylake and then adds then specifically enables Kabylake GuC loading and specifies the Kabylake firmware filename. Peter Antoine (2): Revert "FROM_UPSTREAM [VPG]: drm/i915/kbl: drm/i915: Avoid GuC loading for now on Kabylake."

[Intel-gfx] [PATCH 1/2] Revert "FROM_UPSTREAM [VPG]: drm/i915/kbl: drm/i915: Avoid GuC loading for now on Kabylake."

This reverts commit a92d3f32eafc57cca55e654ecfd916f283100365. --- drivers/gpu/drm/i915/i915_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index af30148..f99a988 100644 ---

[Intel-gfx] [PATCH 2/2] i915/guc: Add Kabylake GuC Loading

This patch added the loading of the GuC for Kabylake. It loads a 2.4 firmware. Signed-off-by: Peter Antoine Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/intel_guc_loader.c | 6 ++ 1 file changed, 6 insertions(+) diff --git

Re: [Intel-gfx] [PATCH] i915/guc: Add Kabylake GuC Loading

Please look at v2, had to change the order of the patches. -Original Message- From: Antoine, Peter Sent: Tuesday, January 19, 2016 9:20 PM To: Dai, Yu; intel-gfx@lists.freedesktop.org Cc: daniel.vet...@ffwll.ch; Gordon, Dave; Thierry, Michel Subject: RE: [PATCH] i915/guc: Add Kabylake

Re: [Intel-gfx] [PATCH] drm/i915: Do not put big intel_crtc_state on the stack

On Tue, Jan 19, 2016 at 03:25:17PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Having this on stack triggers the -Wframe-larger-than=1024 and > is not nice to put such big things on the kernel stack anyway. > > This required a little bit of refactoring to

Re: [Intel-gfx] [PATCH 10/11] acpi: Export acpi_bus_type

On Tuesday, January 19, 2016 05:31:04 PM Lukas Wunner wrote: > Hi Rafael, > > On Tue, Jan 19, 2016 at 12:59:13AM +0100, Rafael J. Wysocki wrote: > > On Tuesday, January 19, 2016 12:00:47 AM Lukas Wunner wrote: > > > Hi, > > > > > > On Mon, Jan 18, 2016 at 11:46:18PM +0100, Rafael J. Wysocki

Re: [Intel-gfx] [PATCH] drm/i915: Sink CRC: tune down error message at stop to debug_kms.

On Tue, 2016-01-19 at 17:46 +, Zanoni, Paulo R wrote: > Em Qua, 2016-01-13 às 14:05 -0800, Rodrigo Vivi escreveu: > > When we stop the sink CRC calculation we wait a while until the > > counter > > is reset to zero and return -ETIMEDOUT. However the sink crc was > > calculated already by this

[Intel-gfx] [PATCH v2 2/2] Revert "FROM_UPSTREAM [VPG]: drm/i915/kbl: drm/i915: Avoid GuC loading for now on Kabylake."

Enabling Kabylake GuC loading as fw now available. This reverts commit a92d3f32eafc57cca55e654ecfd916f283100365. --- drivers/gpu/drm/i915/i915_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index

[Intel-gfx] [PATCH v2 0/2] Enable GuC Loading on Kabylake

This patchset reverts the disabling of the GuC loading for Kabylake and then adds then specifically enables Kabylake GuC loading and specifies the Kabylake firmware filename. v2: Change order of the patchset. (D.Vetter) Peter Antoine (2): i915/guc: Add Kabylake GuC Loading Revert

[Intel-gfx] [PATCH v2 1/2] i915/guc: Add Kabylake GuC Loading

This patch added the loading of the GuC for Kabylake. It loads a 2.4 firmware. Signed-off-by: Peter Antoine Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/intel_guc_loader.c | 6 ++ 1 file changed, 6 insertions(+) diff --git

Re: [Intel-gfx] [PATCH] drm/i915: Retry few time if gpiod_get fails during intel_dsi_init

On Tue, Jan 19, 2016 at 09:00:40PM +0530, Kumar, Shobhit wrote: > On 01/19/2016 08:45 PM, Shobhit Kumar wrote: > >INTEL_SOC_PMIC is loading later than I915 failing the gpiod_get and > >pwm_get calls in i915. Add a retry to give time for the INTEL_SOC_PMIC > >to load. This was fine till now but

Re: [Intel-gfx] [PATCH v4] drm/i915: edp resume/On time optimization.

On 1/12/2016 5:57 PM, Kumar, Abhay wrote: From: Abhay Kumar Make resume/on codepath not to wait for panel_power_cycle_delay(t11_t12) if this time is already spent in suspend/poweron time. v2: Use CLOCK_BOOTTIME and remove jiffies for panel power cycle delay

[Intel-gfx] [PATCH 0/2] DMC/DC state hardening

Hi, There is not known root cause to why we end up in a situation where the dmc doesn't anymore obey us on dc state setup. https://bugs.freedesktop.org/show_bug.cgi?id=93698 https://bugs.freedesktop.org/show_bug.cgi?id=93697 But here are few patches to alleviate the consequences if that

[Intel-gfx] [PATCH 2/2] drm/i915: Use init power domain during reset

If we have driver failure in our power well and/or dc state keeping, we might try to reset without powers. Evidence shows that resetting the chip with dc6 enabled don't lead to desired results. The dmc kept it's enabled dc6 state over the reset. On subsequent init the rings just hanged right from

Re: [Intel-gfx] [PATCH] drm/i915: Sink CRC: tune down error message at stop to debug_kms.

Em Qua, 2016-01-13 às 14:05 -0800, Rodrigo Vivi escreveu: > When we stop the sink CRC calculation we wait a while until the > counter > is reset to zero and return -ETIMEDOUT. However the sink crc was > calculated already by this point so we just ignore this return at > the main function. > > So,

Re: [Intel-gfx] [PATCH] drm/i915/bios: Fix the sequence size calculations for MIPI seq v3

On Tue, 19 Jan 2016, Daniel Vetter wrote: > On Fri, Jan 15, 2016 at 11:51:31AM +0200, Jani Nikula wrote: >> On Thu, 14 Jan 2016, Ville Syrjälä wrote: >> > On Thu, Jan 14, 2016 at 05:12:07PM +0200, Jani Nikula wrote: >> >> Two errors in a single

Re: [Intel-gfx] [PATCH] drm/i915: Remove obsolete starting offset from struct i915_address_space

On Fri, Jan 15, 2016 at 11:57:49AM +, Chris Wilson wrote: > Since the removal of UMS, we have always had sole ownership of the GTTs. > We no longer have to track the subsection we are allowed to use (denoted > by start + total). vGPU does restrict the range of the global GTT we can > use (as

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Correct max save/restore register count during gpu reset with GuC

Thanks for capture the typo. LGTM. Reviewed-by: Alex Dai On 01/18/2016 07:59 AM, Arun Siluvery wrote: In GuC submission mode, driver has to provide a list of registers to be save/restored during gpu reset, make the max no. of registers value consistent with that of the value

[Intel-gfx] [PATCH] Revert "drm/i915: Add two-stage ILK-style watermark programming (v10)"

This reverts commit 396e33ae204f52abebec9e578f44c749305500f4. This commit was triggering some FIFO underrun warnings on ILK-IVB platforms (but surprisingly not on HSW/BDW that share more or less the same codepaths). These underruns were caught by the continuous integration (CI) system and could

Re: [Intel-gfx] [PATCH i-g-t 2/2] lib/igt_kms: Short description between Intel/DRM terminology.

On Tue, Jan 19, 2016 at 05:18:09PM +0200, Ville Syrjälä wrote: > On Tue, Jan 19, 2016 at 05:04:33PM +0200, Marius Vlad wrote: > > On Fri, Jan 15, 2016 at 02:46:45PM +0200, Ville Syrjälä wrote: > > > On Fri, Jan 15, 2016 at 11:06:42AM +0200, Marius Vlad wrote: > > > > lib/igt_kms: Briefly describe

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gen9: Correct max save/restore register count during gpu reset with GuC

On 18/01/2016 16:20, Patchwork wrote: == Summary == Built on 98ee62c2326e0b6881eb0f427895aab745febf6f drm-intel-nightly: 2016y-01m-18d-14h-18m-27s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (skl-i5k-2) UNSTABLE

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use init power domain during reset

On Tue, Jan 19, 2016 at 09:50:09PM +0200, Mika Kuoppala wrote: > If we have driver failure in our power well and/or dc > state keeping, we might try to reset without powers. > > Evidence shows that resetting the chip with dc6 enabled > don't lead to desired results. The dmc kept it's enabled >

Re: [Intel-gfx] [PATCH] i915/guc: Add Kabylake GuC Loading

I am OK with change here. However, in i915_drv.h, please check definition of HAS_GUC_UCODE() and HAS_GUC_SCHED(). I believe they are disabled for KBL. Thanks, Alex On 01/18/2016 06:41 AM, Peter Antoine wrote: This patch added the loading of the GuC for Kabylake. It loads a 2.4 firmware.

[Intel-gfx] [PATCH v4 0/3] improve handling of the driver's default (kernel) context

During startup, the driver creates a unique "intel_context" that will provide a home for orphan requests (i.e. those generated by the driver internally, not associated with user batchbuffers). However, one of the infelicities of the current code is that the driver keeps a per-engine pointer to

[Intel-gfx] [PATCH v4 2/3] drm/i915: abolish separate per-ring default_context pointers

Now that we've eliminated a lot of uses of ring->default_context, we can eliminate the pointer itself. All the engines share the same default intel_context, so we can just keep a single reference to it in the dev_priv structure rather than one in each of the engine[] elements. This make

[Intel-gfx] [PATCH v4 3/3] drm/i915: tidy up a few leftovers

There are a few bits of code which the transformations implemented by the previous patch reveal to be suboptimal, once the notion of a per- ring default context has gone away. So this tidies up the leftovers. It could have been squashed into the previous patch, but that would have made that patch

[Intel-gfx] [PATCH v4 1/3] drm/i915: simplify allocation of driver-internal requests

There are a number of places where the driver needs a request, but isn't working on behalf of any specific user or in a specific context. At present, we associate them with the per-engine default context. A future patch will abolish those per-engine context pointers; but we can already eliminate a

Re: [Intel-gfx] [PATCH] drm/i915: Don't do pre plane update on disabled crtcs

On Mon, Jan 18, 2016 at 11:23:21AM +0100, Maarten Lankhorst wrote: > Op 14-01-16 om 17:52 schreef Ville Syrjälä: > > On Thu, Jan 14, 2016 at 06:32:10PM +0200, Mika Kuoppala wrote: > >> CI/Bat got following (shortened) trace on byt and also > >> on bsw: > >> > >> [ cut here ]---

[Intel-gfx] [PATCH] drm/i915: Tune down "GT register while GT waking disabled" message

We've had this since forever, and's randomly reporting issues and as such causing piles of CI noise. Mika is working on proper debug infrastructure for this, and on fixing this properly. Meanwhile make CI more useful for everyone else. Cc: Mika Kuoppala Bugzilla:

Re: [Intel-gfx] [PATCH 3/3] drm/i915: add DOC: headline to RC6 kernel-doc

On Mon, Jan 18, 2016 at 09:19:48AM +0200, Jani Nikula wrote: > Without the DOC:, kernel-doc confuses the documentation block for > something else. > > Signed-off-by: Jani Nikula Hm, we don't pull intel_pm.c into the gpu.tmpl at all, which means kernel-CI won't test this

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/3] drm/i915/sdvo: revert bogus kernel-doc comments to normal comments

On Mon, Jan 18, 2016 at 07:49:49AM -, Patchwork wrote: > == Summary == > > Built on 9fe57aed43d1c3c9af66aae16ec511dd0357e13b drm-intel-nightly: > 2016y-01m-18d-06h-56m-50s UTC integration manifest > > Test gem_storedw_loop: > Subgroup basic-render: > dmesg-warn ->

Re: [Intel-gfx] [PATCH] drm/i915: Don't do pre plane update on disabled crtcs

Maarten Lankhorst writes: > Op 14-01-16 om 17:52 schreef Ville Syrjälä: >> On Thu, Jan 14, 2016 at 06:32:10PM +0200, Mika Kuoppala wrote: >>> CI/Bat got following (shortened) trace on byt and also >>> on bsw: >>> >>> [ cut here ]--- >>>

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Correct max save/restore register count during gpu reset with GuC

On Tue, Jan 19, 2016 at 10:13:43AM -0800, Yu Dai wrote: > Thanks for capture the typo. LGTM. > > Reviewed-by: Alex Dai > > On 01/18/2016 07:59 AM, Arun Siluvery wrote: > >In GuC submission mode, driver has to provide a list of registers to be > >save/restored during gpu reset,

[Intel-gfx] [PATCH 1/2] drm/i915: Stop using DC states if firmware disagrees on the state

Sometimes we get dmesg warnings claiming that DC6 was already enabled prior to our enabling. Investigations using readback of the written dc state value indicate that sometimes when we disable the dc6, the write doesn't stick, or it does but for a very short time. This leads to state keeping

Re: [Intel-gfx] [PATCH] drm/i915/bios: Fix the sequence size calculations for MIPI seq v3

On Tue, Jan 19, 2016 at 07:55:58PM +0200, Jani Nikula wrote: > On Tue, 19 Jan 2016, Daniel Vetter wrote: > > On Fri, Jan 15, 2016 at 11:51:31AM +0200, Jani Nikula wrote: > >> On Thu, 14 Jan 2016, Ville Syrjälä wrote: > >> > On Thu, Jan 14, 2016 at

Re: [Intel-gfx] [PATCH] drm/i915/skl: Tune down DC6 already enabled warning

On Mon, Jan 18, 2016 at 05:08:42PM +0100, Patrik Jakobsson wrote: > For unknown reasons the DMC firmware overwrites our DC5/6 bits in > the DC_STATE_EN register. This happens from time to time during the > igt@kms_flip@basic-flip-vs-dpms test. We manually fix up the register > when this occurs and

Re: [Intel-gfx] [PATCH 2/3] drm/i915: resize the GuC WOPCM for rc6

On 01/08/2016 07:03 AM, Peter Antoine wrote: This patch resizes the GuC WOPCM to so that the GuC and the RC6 memory spaces do not overlap. Issue: https://jira01.devtools.intel.com/browse/VIZ-6638 Signed-off-by: Peter Antoine --- drivers/gpu/drm/i915/i915_guc_reg.h

Re: [Intel-gfx] [PATCH] drm/i915: Don't do pre plane update on disabled crtcs

Op 19-01-16 om 20:22 schreef Ville Syrjälä: > On Mon, Jan 18, 2016 at 11:23:21AM +0100, Maarten Lankhorst wrote: >> Op 14-01-16 om 17:52 schreef Ville Syrjälä: >>> On Thu, Jan 14, 2016 at 06:32:10PM +0200, Mika Kuoppala wrote: CI/Bat got following (shortened) trace on byt and also on

[Intel-gfx] ✗ Fi.CI.BAT: warning for improve handling of the driver's default (kernel) context

== Summary == Built on 7d26528d30b0d8119c858115b6e5e22deb74ec71 drm-intel-nightly: 2016y-01m-19d-19h-38m-52s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (bdw-nuci7) UNSTABLE Test kms_flip: Subgroup

[Intel-gfx] [PATCH 3/7] drm/i915: Sanitize GEM shrinker init and clean-up

Factor out the common GEM shrinker clean-up code and call the shrinker init function from the same function from where the corresponding shrinker clean-up function is called. Also add sanity checking to the shrinker and OOM registration calls. Signed-off-by: Imre Deak ---

[Intel-gfx] [PATCH 4/7] drm/i915: Sanitize i915_gem_load() init and clean-up

Factor out common clean-up code for the GEM load time init function. Also rename i915_gem_load() to i915_gem_load_init() to have a better match with its new clean-up function. No functional change. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_dma.c | 10

[Intel-gfx] [PATCH 7/7] drm/i915: Move stolen memory initialization earlier during loading

The only device specific dependency of the stolen memory setup is the MMIO mapping and the stolen memory size. Both are already available in i915_gtt_init(), so move the stolen initialization to there. The clean-up code for i915_gtt_init() is in i915_global_gtt_cleanup(), so move the stolen memory

[Intel-gfx] [PATCH 1/7] drm/i915: Sanitize up DMC/CSR ucode cleanup code

commit ebae38d061df3deffa7c17b030ea14a5216ee55f Author: Animesh Manna Date: Wed Oct 28 23:58:55 2015 +0200 drm/i915/gen9: csr_init after runtime pm enable moved the DMC/CSR initialization later during driver loading, but didn't move the cleanup earlier

[Intel-gfx] [PATCH 6/7] drm/i915: Move MCHBAR setup earlier during init

Move the MCHBAR setup right after the MMIO setup, since the two things are logically related and the MCHBAR setup code doesn't depend on any other device specific resource. We'll also need MCHBAR to be ready earlier in an upcoming patch, so this is also a preparation for that. Factor out the

[Intel-gfx] [PATCH 2/7] drm/i915: Sanitize i915_get_bridge_dev() error path

Clarify the name of the label on the error path, making it clear what's being cleaned up. The kmem_cache_destroy() calls are NOPs on the corresponding error path. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_dma.c | 5 ++--- 1 file changed, 2 insertions(+), 3

[Intel-gfx] [PATCH 0/7] drm/i915: Move load time stolen memory init earlier

For Sagar's BXT RC6 setup sanitization patch [1], we'll need the details about the GTT/stolen memory reservation early during driver loading, so this patchset moves the required init calls earlier accordingly. It also sanitizes a few MMIO/GEM init/clean-up steps on the way. [1]

[Intel-gfx] [PATCH 5/7] drm/i915: Move allocation of various workqueues earlier during init

Workqueue initalization doesn't depend on any other device specific resource, so move it close to the beginning, so we don't need to consider them when thinking about dependencies for other resources. Also factor out things to separate init/cleanup functions to make i915_driver_load()/unload()

[Intel-gfx] [PATCH 00/25] FBC crtc/fb locking + smaller fixes

Hi Here's yet another patch series randomly modifying the FBC code. We start by refactoring things in order to fix the locking problems, then fix a few other smaller problems and apply some polishing. Just to keep the tradition of the past 10 cover letters, I guess I should say that this series

[Intel-gfx] [PATCH 04/25] drm/i915/fbc: introduce struct intel_fbc_reg_params

The early return inside __intel_fbc_update does not completely check all the parameters that affect the FBC register values. For example, we currently lack looking at crtc->adjusted_y (for the fence Y offset) and all the parameters that affect the CFB size (for i8xx). Instead of just adding the

[Intel-gfx] [PATCH 05/25] drm/i915/fbc: replace frequent dev_priv->fbc.x with fbc->x

We say "dev_priv->fbc.something" way too many times in our code while we could be saying just "fbc->something" with a previous declaration of fbc. This has been bothering me for a while but I didn't want to patch it since I wanted to fix the real problems first. But as I add more code I keep

[Intel-gfx] [PATCH 02/25] drm/i915/fbc: extract intel_fbc_can_activate()

Extract all the code that checks if the FBC configuration is valid to its own function, making __intel_fbc_update() much simpler. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_fbc.c | 92 ++-- 1 file changed, 50

[Intel-gfx] [PATCH 01/25] drm/i915/fbc: wait for a vblank instead of 50ms when enabling

Instead of waiting for 50ms, just wait until the next vblank, since it's the minimum requirement. The whole infrastructure of FBC is based on vblanks, so waiting for X vblanks instead of X milliseconds sounds like the correct way to go. Besides, 50ms may be less than a vblank on super slow modes

  1   2   >