[Intel-gfx] [PATCH i-g-t] lib/igt_gt: Define HANG_ALLOW_* as bit flags

As that is what they are meant to be. It will prevent any confusion if we have to add other flags in the future. Signed-off-by: Michel Thierry --- lib/igt_gt.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/igt_gt.h b/lib/igt_gt.h index

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Reset the link params on HPD/connected boot/resume

== Series Details == Series: drm/i915/dp: Reset the link params on HPD/connected boot/resume URL : https://patchwork.freedesktop.org/series/19277/ State : success == Summary == Series 19277v1 drm/i915/dp: Reset the link params on HPD/connected boot/resume

[Intel-gfx] [PATCH] drm/i915/dp: Reset the link params on HPD/connected boot/resume

The max link parameters should be set/reset only on HPD or connected boot case or on system resume. Add a flag reset_link_params to intel_dp to decide when to reset the max link parameters. This prevents the parameters from getting reset/overwritten through all other connector->funcs->detect()

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Clean up/Get rid of detect_done flag

== Series Details == Series: drm/i915/dp: Clean up/Get rid of detect_done flag URL : https://patchwork.freedesktop.org/series/19276/ State : success == Summary == Series 19276v1 drm/i915/dp: Clean up/Get rid of detect_done flag

Re: [Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info

On 7 February 2017 at 14:49, Chris Wilson wrote: > On Tue, Feb 07, 2017 at 02:38:16PM +, Emil Velikov wrote: >> On 7 February 2017 at 14:29, Daniel Vetter wrote: >> > Noticed that everyone duplicates the same logic here and we could safe >> >

[Intel-gfx] [PATCH] drm/i915/dp: Clean up/Get rid of detect_done flag

Detect_done flag was added previously when intel_dp_long_pulse was called from multiple places. However now it is called only from intel_dp_detect(). So this flag becomes redundant. Anyway now, we set this to false right away after intel_dp_long_pulse so it calls long pulse handler always for all

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Move calling engine->init_hw() to its own function

== Series Details == Series: series starting with [1/3] drm/i915: Move calling engine->init_hw() to its own function URL : https://patchwork.freedesktop.org/series/19263/ State : success == Summary == Series 19263v1 Series without cover letter

[Intel-gfx] linux-firmware pull request (bxt guc,huc; kbl guc,huc; skl huc)

Hi, Please consider pulling i915 updates to linux-firmware.git. The following changes since commit 6d3bc8886517d171068fd1263176b8b5c51df204: Fix permissions on ti-connectivity firmware from 05e9fe59 (2017-01-13 10:14:07 -0500) are available in the git repository at:

Re: [Intel-gfx] [PATCH v4] drm/i915: Restore context and pd for ringbuffer submission after reset

On Tue, Feb 07, 2017 at 05:54:10PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > Following a reset, the context and page directory registers are lost. > > However, the queue of requests that we resubmit after the reset may > > depend upon them - the registers

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Split GEM resetting into 3 phases

On Tue, Feb 07, 2017 at 09:12:25PM +, Chris Wilson wrote: > Currently we do a reset prepare/finish around the call to reset the GPU, > but it looks like we need a later stage after the hw has been > reinitialised to allow GEM to restart itself. Start by splitting the 2 > GEM phases into 3: >

[Intel-gfx] [PATCH 3/3] drm/i915: Disable engine->irq_tasklet around resets

When we restart the engines, and we have active requests, a request on the first engine may complete and queue a request to the second engine before we try to restart the second engine. That queueing of the request may race with the engine to restart, and so may corrupt the current state.

[Intel-gfx] [PATCH 1/3] drm/i915: Move calling engine->init_hw() to its own function

Just a simple refactor to move a loop and some support code out of i915_gem_init_hw(). This is in preparation for avoiding a race between the tasklet writing to ELSP whilst simultaneously being written by engine->init_hw() following a GPU reset. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 2/3] drm/i915: Split GEM resetting into 3 phases

Currently we do a reset prepare/finish around the call to reset the GPU, but it looks like we need a later stage after the hw has been reinitialised to allow GEM to restart itself. Start by splitting the 2 GEM phases into 3: prepare - before the reset, check if GEM recovered, then stop GEM

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Always convert incoming exec offsets to non-canonical

== Series Details == Series: drm/i915: Always convert incoming exec offsets to non-canonical URL : https://patchwork.freedesktop.org/series/19259/ State : failure == Summary == Series 19259v1 drm/i915: Always convert incoming exec offsets to non-canonical

Re: [Intel-gfx] [PATCH] drm/i915/guc: Dynamically alloc GuC descriptor

On Tue, Feb 07, 2017 at 01:37:52AM -0800, Oscar Mateo wrote: > > > On 02/07/2017 09:25 AM, Chris Wilson wrote: > >On Tue, Feb 07, 2017 at 12:55:21AM -0800, Oscar Mateo wrote: > >> > >>On 02/02/2017 11:33 PM, Chris Wilson wrote: > >>>On Thu, Feb 02, 2017 at 07:27:45AM -0800, Oscar Mateo wrote: >

Re: [Intel-gfx] [PATCH] drm/i915: Always convert incoming exec offsets to non-canonical

On Tue, Feb 07, 2017 at 08:55:59PM +0100, Michał Winiarski wrote: > We're using non-canonical addresses in drm_mm, and we're making sure that > userspace is using canonical addressing - both in case of softpin > (verifying incoming offset) and when relocating (converting to canonical > when

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Introduce intel_cdclk_state (rev12)

== Series Details == Series: drm/i915: Introduce intel_cdclk_state (rev12) URL : https://patchwork.freedesktop.org/series/16994/ State : warning == Summary == Series 16994v12 drm/i915: Introduce intel_cdclk_state https://patchwork.freedesktop.org/api/1.0/series/16994/revisions/12/mbox/ Test

Re: [Intel-gfx] [PATCH v2 12/13] drm/i915/dp: localize link rate index variable more

This has been tested to correctly execute the compliance request. Reviewed-by: Manasi Navare Manasi On Fri, Feb 03, 2017 at 04:19:35PM +0200, Jani Nikula wrote: > Localize link_rate_index to the if block, and rename to just index to > reduce indent. > > Cc: Manasi

Re: [Intel-gfx] [PATCH v2 00/13] drm/i915/dp: link rate and lane count refactoring

Hi Jani, Thanks for this patch series. This definitely makes use of lane count and link rate cleaner while handling the link failures. I have tested these patches with compliance device along with my pending DRM link-status patches and it does the fallback as expected. It does not solve the

[Intel-gfx] [PATCH] drm/i915: Always convert incoming exec offsets to non-canonical

We're using non-canonical addresses in drm_mm, and we're making sure that userspace is using canonical addressing - both in case of softpin (verifying incoming offset) and when relocating (converting to canonical when updating offset returned to userspace). Unfortunately when considering the need

Re: [Intel-gfx] [PATCH v1½ 03/13] drm/i915/dp: rename rate_to_index() to intel_dp_find_rate() and reuse

On Thu, 2017-02-02 at 10:44 +0200, Jani Nikula wrote: > On Wed, 01 Feb 2017, "Pandiyan, Dhinakaran" > wrote: > > On Thu, 2017-01-26 at 21:44 +0200, Jani Nikula wrote: > >> Rename the function, move it at the top, and reuse in > >> intel_dp_link_rate_index(). If

[Intel-gfx] [PATCH v4 07/14] drm/i915: Start moving the cdclk stuff into a distinct state structure

From: Ville Syrjälä Introduce intel_cdclk state which for now will track the cdclk frequency, the vco frequency and the reference frequency (not sure we want the last one, but I put it there anyway). We'll also make the .get_cdclk() function fill out this state

[Intel-gfx] [PATCH v4 05/14] drm/i915: Move most cdclk/rawclk related code to intel_cdclk.c

From: Ville Syrjälä Let's try to shrink intel_display.c a bit by moving the cdclk/rawclk stuff to a new file. It's all reasonably self contained so we don't even have to add that many non-static symbols. We'll also take the opportunity to shuffle around the

[Intel-gfx] [PATCH v2 04/14] drm/i915: Clean up the .get_cdclk() assignment if ladder

From: Ville Syrjälä Let's clean up the mess we have in the if ladder that assigns the .get_cdclk() hooks. The grouping of the platforms by the function results in a thing that's not really legible, so let's do it the other way around and order the if ladder by

[Intel-gfx] [PATCH v3 03/14] drm/i915: s/get_display_clock_speed/get_cdclk/

From: Ville Syrjälä Rename the .get_display_clock_speed() hook to .get_cdclk(). .get_cdclk() is more specific (which clock) and it's much shorter. v2: Deal with IS_GEN9_BC() v3: Deal with i945gm_get_display_clock_speed() Signed-off-by: Ville Syrjälä

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Make intel_guc_send a function pointer (rev2)

== Series Details == Series: drm/i915/guc: Make intel_guc_send a function pointer (rev2) URL : https://patchwork.freedesktop.org/series/19024/ State : failure == Summary == Series 19024v2 drm/i915/guc: Make intel_guc_send a function pointer

[Intel-gfx] [PATCH i-g-t] igt/core: Return condition result from igt_warn_on*()

This allows us to be a little more flexible with how we use igt_warn_on() and igt_warn_on_f() by allowing us to write statements like this: if (igt_warn_on(scary_condition)) { /* some error handling... */ } Signed-off-by: Lyude ---

Re: [Intel-gfx] [PATCH] drm/i915: Get correct display clock on 945gm

On Wed, Feb 01, 2017 at 12:50:26AM +0100, Arthur Heymans wrote: > This is according to Mobile Intel® 945 Express Chipset > Family datasheet. > > Signed-off-by: Arthur Heymans Reviewed-by: Ville Syrjälä and pushed to dinq. Thanks for the

Re: [Intel-gfx] [PATCH RFC] drm/i915: reduce cursor size for GEN5 hardware

On Tue, Feb 07, 2017 at 06:51:25PM +0100, Maarten Lankhorst wrote: > Op 07-02-17 om 16:35 schreef Ville Syrjälä: > > On Tue, Feb 07, 2017 at 05:03:09PM +0200, Martin Peres wrote: > >> On 07/02/17 15:22, Uwe Kleine-König wrote: > >>> Hello, > >>> > >>> On 02/01/2017 03:37 PM, Ville Syrjälä wrote: >

Re: [Intel-gfx] [PATCH RFC] drm/i915: reduce cursor size for GEN5 hardware

Op 07-02-17 om 16:35 schreef Ville Syrjälä: > On Tue, Feb 07, 2017 at 05:03:09PM +0200, Martin Peres wrote: >> On 07/02/17 15:22, Uwe Kleine-König wrote: >>> Hello, >>> >>> On 02/01/2017 03:37 PM, Ville Syrjälä wrote: On Wed, Feb 01, 2017 at 01:41:08PM +0100, Maarten Lankhorst wrote: > Op

Re: [Intel-gfx] [PATCH] drm/i915/guc: Dynamically alloc GuC descriptor

On 02/07/2017 09:25 AM, Chris Wilson wrote: On Tue, Feb 07, 2017 at 12:55:21AM -0800, Oscar Mateo wrote: On 02/02/2017 11:33 PM, Chris Wilson wrote: On Thu, Feb 02, 2017 at 07:27:45AM -0800, Oscar Mateo wrote: From: Michal Wajdeczko The GuC descriptor is big

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/fb-helper: Explain unload sequence a bit better (rev3)

== Series Details == Series: series starting with [1/2] drm/fb-helper: Explain unload sequence a bit better (rev3) URL : https://patchwork.freedesktop.org/series/19242/ State : failure == Summary == CC drivers/acpi/acpica/uterror.o CC drivers/acpi/acpica/utglobal.o CC

Re: [Intel-gfx] [PATCH] drm/i915/guc: Dynamically alloc GuC descriptor

On Tue, Feb 07, 2017 at 12:55:21AM -0800, Oscar Mateo wrote: > > > On 02/02/2017 11:33 PM, Chris Wilson wrote: > >On Thu, Feb 02, 2017 at 07:27:45AM -0800, Oscar Mateo wrote: > >>From: Michal Wajdeczko > >> > >>The GuC descriptor is big in size. If we use local

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Restart all engines atomically

== Series Details == Series: drm/i915: Restart all engines atomically URL : https://patchwork.freedesktop.org/series/19249/ State : success == Summary == Series 19249v1 drm/i915: Restart all engines atomically https://patchwork.freedesktop.org/api/1.0/series/19249/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/i915: Restart all engines atomically

On Tue, Feb 07, 2017 at 05:58:58PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > When we restart the engines, and we have active requests, a request on > > the first engine may complete and queue a request to the second engine > > before we try to restart the

[Intel-gfx] [PATCH v2] drm/i915/guc: Make intel_guc_send a function pointer

From: Michal Wajdeczko Prepare for an alternate GuC communication interface. v2: Make a few functions static and name them correctly while we are at it (Oscar) v3: Leave an intel_guc_send_mmio interface for users that require old-style communication Signed-off-by:

Re: [Intel-gfx] [PATCH] drm/i915/guc: Dynamically alloc GuC descriptor

On 02/02/2017 11:33 PM, Chris Wilson wrote: On Thu, Feb 02, 2017 at 07:27:45AM -0800, Oscar Mateo wrote: From: Michal Wajdeczko The GuC descriptor is big in size. If we use local definition of guc_desc we have a chance to overflow stack. Use allocated one. v2:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Restore context and pd for ringbuffer submission after reset (rev3)

== Series Details == Series: drm/i915: Restore context and pd for ringbuffer submission after reset (rev3) URL : https://patchwork.freedesktop.org/series/19110/ State : success == Summary == Series 19110v3 drm/i915: Restore context and pd for ringbuffer submission after reset

Re: [Intel-gfx] [PATCH] drm/i915/guc: Make intel_guc_send a function pointer

On 02/03/2017 03:48 AM, Michal Wajdeczko wrote: On Thu, Feb 02, 2017 at 07:42:46AM -0800, Oscar Mateo wrote: From: Michal Wajdeczko Prepare for an alternate GuC communication interface. v2: Make a few functions static and name them correctly while we are at it

Re: [Intel-gfx] [PATCH v2 3/6] drm/edid: detect SCDC support in HF-VSDB

On Tue, Feb 07, 2017 at 09:43:15PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 2/7/2017 4:31 PM, Jose Abreu wrote: > > Hi Shashank, > > > > > > > > On 06-02-2017 13:59, Shashank Sharma wrote: > > > This patch does following: > > > - Adds a new structure (drm_hdmi_info) in

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Avoid BIT(max) - 1 and use GENMASK(max, 0)

== Series Details == Series: drm/i915: Avoid BIT(max) - 1 and use GENMASK(max, 0) URL : https://patchwork.freedesktop.org/series/19240/ State : failure == Summary == Series 19240v1 drm/i915: Avoid BIT(max) - 1 and use GENMASK(max, 0)

Re: [Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info

On Tue, Feb 07, 2017 at 05:16:03PM +0100, Daniel Vetter wrote: > Noticed that everyone duplicates the same logic here and we could safe > a few lines per driver. Yay for lots of drivers to make such tiny > refactors worth-while! > > v2: Forgot to git add everything :( > > v3: Actually remove

Re: [Intel-gfx] [PATCH v2 4/6] drm: scrambling support in drm layer

Regards Shashank On 2/7/2017 4:44 PM, Jose Abreu wrote: Hi Shashank, On 06-02-2017 13:59, Shashank Sharma wrote: HDMI 2.0 spec mandates scrambling for modes with pixel clock higher than 340 MHz. This patch adds few new functions in drm layer for core drivers to enable/disable scrambling.

[Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info

Noticed that everyone duplicates the same logic here and we could safe a few lines per driver. Yay for lots of drivers to make such tiny refactors worth-while! v2: Forgot to git add everything :( v3: Actually remove release_fbi (Sean, Emil, Chris) ... Cc: Chris Wilson

Re: [Intel-gfx] [PATCH v2 3/6] drm/edid: detect SCDC support in HF-VSDB

Regards Shashank On 2/7/2017 4:31 PM, Jose Abreu wrote: Hi Shashank, On 06-02-2017 13:59, Shashank Sharma wrote: This patch does following: - Adds a new structure (drm_hdmi_info) in drm_display_info. This structure will be used to save and indicate if sink supports advanced HDMI 2.0

Re: [Intel-gfx] [PATCH v2 1/6] drm: Add SCDC helpers

Thanks for the review Jose, my comments inline. Regards Shashank On 2/7/2017 4:24 PM, Jose Abreu wrote: Hi Shashank, Sorry for the late review. On 06-02-2017 13:59, Shashank Sharma wrote: From: Thierry Reding SCDC is a mechanism defined in the HDMI 2.0

Re: [Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info

On Tue, Feb 07, 2017 at 02:49:38PM +, Chris Wilson wrote: > On Tue, Feb 07, 2017 at 02:38:16PM +, Emil Velikov wrote: > > On 7 February 2017 at 14:29, Daniel Vetter wrote: > > > Noticed that everyone duplicates the same logic here and we could safe > > > a few

Re: [Intel-gfx] [PATCH v2 5/6] drm/i915: enable scrambling

Regards Shashank On 2/7/2017 3:51 PM, Jani Nikula wrote: On Mon, 06 Feb 2017, Shashank Sharma wrote: Geminilake platform sports a native HDMI 2.0 controller, and is capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec mendates scrambling for these higher

Re: [Intel-gfx] [PATCH] drm/i915: Restart all engines atomically

Chris Wilson writes: > When we restart the engines, and we have active requests, a request on > the first engine may complete and queue a request to the second engine > before we try to restart the second engine. That queueing of the > request may itself cause the

Re: [Intel-gfx] [PATCH 2/2] drm/fb-helper: Automatically clean up fb_info

On Tue, Feb 07, 2017 at 03:10:50PM +0100, Daniel Vetter wrote: > Noticed that everyone duplicates the same logic here and we could safe > a few lines per driver. Yay for lots of drivers to make such tiny > refactors worth-while! > > Cc: Chris Wilson > Cc: Sean Paul

Re: [Intel-gfx] [PATCH v4] drm/i915: Restore context and pd for ringbuffer submission after reset

Chris Wilson writes: > Following a reset, the context and page directory registers are lost. > However, the queue of requests that we resubmit after the reset may > depend upon them - the registers are restored from a context image, but > that restore may be inhibited

[Intel-gfx] [PATCH] drm/i915: Restart all engines atomically

When we restart the engines, and we have active requests, a request on the first engine may complete and queue a request to the second engine before we try to restart the second engine. That queueing of the request may itself cause the engine to restart, and so the subsequent handling by

Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Add render decompression support

On Thu, Jan 05, 2017 at 05:14:54PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > SKL+ display engine can scan out certain kinds of compressed surfaces > produced by the render engine. This involved telling the display engine > the location

Re: [Intel-gfx] [PATCH RFC] drm/i915: reduce cursor size for GEN5 hardware

On Tue, Feb 07, 2017 at 05:03:09PM +0200, Martin Peres wrote: > On 07/02/17 15:22, Uwe Kleine-König wrote: > > Hello, > > > > On 02/01/2017 03:37 PM, Ville Syrjälä wrote: > >> On Wed, Feb 01, 2017 at 01:41:08PM +0100, Maarten Lankhorst wrote: > >>> Op 31-01-17 om 20:13 schreef Uwe Kleine-König: >

Re: [Intel-gfx] [PATCH 01/19] drm/i915: Micro-optimise i915_get_ggtt_vma_pages()

Chris Wilson writes: > The predominant VMA class is normal GTT, so allow gcc to emphasize that > path and avoid unnecessary stack movement. > > Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala > --- >

[Intel-gfx] [PATCH v4] drm/i915: Restore context and pd for ringbuffer submission after reset

Following a reset, the context and page directory registers are lost. However, the queue of requests that we resubmit after the reset may depend upon them - the registers are restored from a context image, but that restore may be inhibited and may simply be absent from the request if it was in the

[Intel-gfx] [PATCH i-g-t] lib: Add basic support for valgrind annotations.

SIGRTMAX appears to be used by valgrind now for its internal tracking, so avoid it in the helpers. Also add some valgrind annotations in gem_mmap, to make sure that its accesses are tracked correctly. Signed-off-by: Maarten Lankhorst --- diff --git

Re: [Intel-gfx] [PATCH RFC] drm/i915: reduce cursor size for GEN5 hardware

On 07/02/17 15:22, Uwe Kleine-König wrote: Hello, On 02/01/2017 03:37 PM, Ville Syrjälä wrote: On Wed, Feb 01, 2017 at 01:41:08PM +0100, Maarten Lankhorst wrote: Op 31-01-17 om 20:13 schreef Uwe Kleine-König: On Tue, Jan 31, 2017 at 10:03:26AM +0100, Maarten Lankhorst wrote: Op 31-01-17 om

Re: [Intel-gfx] [PATCH v2 4/6] drm: scrambling support in drm layer

On Tue, 07 Feb 2017, Jose Abreu wrote: > Hi Jani, > > > On 07-02-2017 13:35, Jani Nikula wrote: >> On Tue, 07 Feb 2017, Jose Abreu wrote: +bool drm_scdc_check_scrambling_status(struct i2c_adapter *adapter) +{ + u8 status; +

Re: [Intel-gfx] [PATCH i-g-t v2] tests: Clean up shell scripts

On Tue, 07 Feb 2017, Joonas Lahtinen wrote: > On ti, 2017-02-07 at 15:32 +0200, Jani Nikula wrote: >> > On Tue, 07 Feb 2017, Joonas Lahtinen >> > wrote: >> > >> > On ma, 2017-02-06 at 17:40 +0100, Daniel Vetter wrote: >> > > >>

Re: [Intel-gfx] [PATCH v2 4/6] drm: scrambling support in drm layer

Hi Jani, On 07-02-2017 13:35, Jani Nikula wrote: > On Tue, 07 Feb 2017, Jose Abreu wrote: >>> +bool drm_scdc_check_scrambling_status(struct i2c_adapter *adapter) >>> +{ >>> + u8 status; >>> + int ret; >>> + >>> + ret = drm_scdc_readb(adapter,

Re: [Intel-gfx] [GIT PULL] GVT-g fixes for 4.11 merge

On Tue, 07 Feb 2017, Zhenyu Wang wrote: > Hi, > > These are GVT-g changes for 4.11 merge window, mostly for gvt init > order fix that impacted resource handling for device model, the one > i915 change has been reviewed and acked. > > I can't find good tag on dinf for this

[Intel-gfx] [patch v2] drm/i915/gvt/kvmgt: remove some dead code

"caps.buf" is always NULL here and "caps.size" is always zero. The code is a no-op and can be removed. Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c index 3f656e3a6e5a..773a45aa18f8 100644 ---

Re: [Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info

On Tue, Feb 07, 2017 at 02:38:16PM +, Emil Velikov wrote: > On 7 February 2017 at 14:29, Daniel Vetter wrote: > > Noticed that everyone duplicates the same logic here and we could safe > > a few lines per driver. Yay for lots of drivers to make such tiny > > refactors

Re: [Intel-gfx] [patch] drm/i915/gvt/kvmgt: remove some dead code

On Tue, Feb 07, 2017 at 04:34:57PM +0200, Joonas Lahtinen wrote: > On ti, 2017-02-07 at 16:16 +0300, Dan Carpenter wrote: > > If "caps.buf" is already NULL then it doesn't need to be freed or set to > > NULL. > > > > Signed-off-by: Dan Carpenter > > > > > @@ -965,11

Re: [Intel-gfx] [PATCH i-g-t v2] tests: Clean up shell scripts

On ti, 2017-02-07 at 15:32 +0200, Jani Nikula wrote: > > On Tue, 07 Feb 2017, Joonas Lahtinen > > wrote: > > > > On ma, 2017-02-06 at 17:40 +0100, Daniel Vetter wrote: > > > > > > On Mon, Feb 06, 2017 at 03:25:27PM +0200, Jani Nikula wrote: > > > > > > > > On

Re: [Intel-gfx] [PATCH 2/2] drm/fb-helper: Automatically clean up fb_info

On Tue, Feb 07, 2017 at 03:10:50PM +0100, Daniel Vetter wrote: > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index 5220a7b5e6ff..074ab22a7cf3 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -781,7 +781,9 @@

Re: [Intel-gfx] [PATCH] drm/i915: Remove overzealous fence warn on runtime suspend

On Tue, Feb 07, 2017 at 04:24:25PM +0200, Joonas Lahtinen wrote: > On pe, 2017-02-03 at 12:57 +, Chris Wilson wrote: > > @@ -2024,8 +2024,16 @@ void i915_gem_runtime_suspend(struct > > drm_i915_private *dev_priv) > >   for (i = 0; i < dev_priv->num_fence_regs; i++) { > >   struct

Re: [Intel-gfx] [PATCH] drm/i915: Avoid BIT(max) - 1 and use GENMASK(max, 0)

On ti, 2017-02-07 at 14:03 +, Chris Wilson wrote: > On Tue, Feb 07, 2017 at 03:51:41PM +0200, Joonas Lahtinen wrote: > > > > "BIT(max) - 1" will overflow when max = 32, and GCC will complain. > > We already have GENMASK for generating the mask, use it! > > > > Signed-off-by: Joonas Lahtinen

Re: [Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info

On 7 February 2017 at 14:29, Daniel Vetter wrote: > Noticed that everyone duplicates the same logic here and we could safe > a few lines per driver. Yay for lots of drivers to make such tiny > refactors worth-while! > > v2: Forgot to git add everything :( > Hmm afaict this

Re: [Intel-gfx] [patch] drm/i915/gvt/kvmgt: remove some dead code

On ti, 2017-02-07 at 16:16 +0300, Dan Carpenter wrote: > If "caps.buf" is already NULL then it doesn't need to be freed or set to > NULL. > > Signed-off-by: Dan Carpenter > @@ -965,11 +965,8 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, > unsigned int

[Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info

Noticed that everyone duplicates the same logic here and we could safe a few lines per driver. Yay for lots of drivers to make such tiny refactors worth-while! v2: Forgot to git add everything :( Cc: Chris Wilson Cc: Sean Paul Cc: Noralf Trønnes

Re: [Intel-gfx] [PATCH 1/2] drm/fb-helper: Explain unload sequence a bit better

On Tue, Feb 07, 2017 at 03:10:49PM +0100, Daniel Vetter wrote: > While reviewing Chris' patches to properly cancel our async workers I > checked that this happens after the fbdev is already unregistered. > That's the case, but I found a small gap in our docs, fill that in. > > Note that I don't

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm: Cancel drm_fb_helper_dirty_work on unload

== Series Details == Series: series starting with [1/2] drm: Cancel drm_fb_helper_dirty_work on unload URL : https://patchwork.freedesktop.org/series/19230/ State : failure == Summary == Series 19230v1 Series without cover letter

Re: [Intel-gfx] [PATCH] drm/i915: Remove overzealous fence warn on runtime suspend

On pe, 2017-02-03 at 12:57 +, Chris Wilson wrote: > The goal of the WARN was to catch when we are still actively using the > fence as we go into the runtime suspend. However, the reg->pin_count is > too coarse as it does not distinguish between exclusive ownership of the > fence register from

Re: [Intel-gfx] [PATCH] drm/i915: Rename conditional GEM execution macros

On ti, 2017-02-07 at 10:23 +, Chris Wilson wrote: > After a brief discussion, we settled on a naming convention for the > conditional GEM debugging data that should be clearer to the casual > user: GEM_DEBUG > > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen

[Intel-gfx] [PATCH 1/2] drm/fb-helper: Explain unload sequence a bit better

While reviewing Chris' patches to properly cancel our async workers I checked that this happens after the fbdev is already unregistered. That's the case, but I found a small gap in our docs, fill that in. Note that I don't explain what release_fbi does, because that function will disappear in the

[Intel-gfx] [PATCH 2/2] drm/fb-helper: Automatically clean up fb_info

Noticed that everyone duplicates the same logic here and we could safe a few lines per driver. Yay for lots of drivers to make such tiny refactors worth-while! Cc: Chris Wilson Cc: Sean Paul Cc: Noralf Trønnes Signed-off-by:

Re: [Intel-gfx] [PATCH 2/2] drm: Cancel drm_fb_helper_resume_work on unload

On Tue, Feb 07, 2017 at 12:49:56PM +, Chris Wilson wrote: > We can not allow the worker to run after its fbdev, or even the module, > has been removed. > > Fixes: cfe63423d9be ("drm/fb-helper: Add > drm_fb_helper_set_suspend_unlocked()") > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH] drm/i915: Avoid BIT(max) - 1 and use GENMASK(max, 0)

On Tue, Feb 07, 2017 at 03:51:41PM +0200, Joonas Lahtinen wrote: > "BIT(max) - 1" will overflow when max = 32, and GCC will complain. > We already have GENMASK for generating the mask, use it! > > Signed-off-by: Joonas Lahtinen > Cc: Chris Wilson

[Intel-gfx] [PATCH] drm/i915: Avoid BIT(max) - 1 and use GENMASK(max, 0)

"BIT(max) - 1" will overflow when max = 32, and GCC will complain. We already have GENMASK for generating the mask, use it! Signed-off-by: Joonas Lahtinen Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_device_info.c | 2 +-

Re: [Intel-gfx] [PATCH] drm/i915/debugfs: Add i915_hpd_storm_ctl

On Sat, 04 Feb 2017, Lyude wrote: > This adds a file in i915's debugfs directory that allows userspace to > manually control HPD storm detection. This is mainly for hotplugging > tests, where we might want to test HPD storm functionality or disable > storm detection to speed up

Re: [Intel-gfx] [PATCH v2 4/6] drm: scrambling support in drm layer

On Tue, 07 Feb 2017, Jose Abreu wrote: >> +bool drm_scdc_check_scrambling_status(struct i2c_adapter *adapter) >> +{ >> +u8 status; >> +int ret; >> + >> +ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, ); >> +if (ret < 0) { >> +

Re: [Intel-gfx] [PATCH i-g-t v2] tests: Clean up shell scripts

On Tue, 07 Feb 2017, Joonas Lahtinen wrote: > On ma, 2017-02-06 at 17:40 +0100, Daniel Vetter wrote: >> On Mon, Feb 06, 2017 at 03:25:27PM +0200, Jani Nikula wrote: >> > >> > On Mon, 06 Feb 2017, Joonas Lahtinen >> > wrote: >> >

[Intel-gfx] [PATCH i-g-t] tests/kms_plane_lowres: Add DRM_MODE_ATOMIC_ALLOW_MODESET test

When doing a full atomic modeset, kernel should fail if the flag DRM_MODE_ATOMIC_ALLOW_MODESET is not set. Let's add this test as part of 'kms_plane_lowres' testset. The testcases are 'pipe-x-allow-modeset' where x stands for pipe in question. For: VIZ-6955 Signed-off-by: Mika Kahola

[Intel-gfx] ✗ Fi.CI.BAT: failure for GLK MIPI DSI VIDEO MODE PATCHES (rev4)

== Series Details == Series: GLK MIPI DSI VIDEO MODE PATCHES (rev4) URL : https://patchwork.freedesktop.org/series/16542/ State : failure == Summary == Series 16542v4 GLK MIPI DSI VIDEO MODE PATCHES https://patchwork.freedesktop.org/api/1.0/series/16542/revisions/4/mbox/ Test drv_hangman:

Re: [Intel-gfx] [PATCH RFC] drm/i915: reduce cursor size for GEN5 hardware

Hello, On 02/01/2017 03:37 PM, Ville Syrjälä wrote: > On Wed, Feb 01, 2017 at 01:41:08PM +0100, Maarten Lankhorst wrote: >> Op 31-01-17 om 20:13 schreef Uwe Kleine-König: >>> On Tue, Jan 31, 2017 at 10:03:26AM +0100, Maarten Lankhorst wrote: Op 31-01-17 om 09:09 schreef Uwe Kleine-König:

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Do RPM Wake during GuC/HuC status read

On Mon, Feb 06, 2017 at 10:34:31AM +0530, Kamble, Sagar A wrote: > > > On 2/4/2017 7:40 PM, Arkadiusz Hiler wrote: > > On Fri, Feb 03, 2017 at 01:58:33PM +0530, Sagar Arun Kamble wrote: > > > HUC_STATUS, GUC_STATUS, SOFT_SCRATCH registers are read in debugfs > > > and getparam ioctl. This patch

[Intel-gfx] [patch] drm/i915/gvt/kvmgt: remove some dead code

If "caps.buf" is already NULL then it doesn't need to be freed or set to NULL. Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c index 3f656e3a6e5a..de2a55178a37 100644 --- a/drivers/gpu/drm/i915/gvt/kvmgt.c

[Intel-gfx] [PATCH 2/2] drm: Cancel drm_fb_helper_resume_work on unload

We can not allow the worker to run after its fbdev, or even the module, has been removed. Fixes: cfe63423d9be ("drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked()") Signed-off-by: Chris Wilson Cc: Noralf Trønnes Cc: Daniel Vetter

[Intel-gfx] [PATCH 1/2] drm: Cancel drm_fb_helper_dirty_work on unload

We can not allow the worker to run after its fbdev, or even the module, has been removed. Fixes: eaa434defaca ("drm/fb-helper: Add fb_deferred_io support") Signed-off-by: Chris Wilson Cc: Noralf Trønnes Cc: Daniel Vetter Cc:

[Intel-gfx] [GLK MIPI DSI V4 8/8] drm/i915/glk: Validate only DSI PORT A PLL divider

As per BSPEC, GLK supports MIPI DSI 8X clk only on PORT A. Therefore only for PORT A PLL divider value should be validated. Signed-off-by: Madhav Chauhan --- drivers/gpu/drm/i915/intel_dsi_pll.c | 19 +-- 1 file changed, 13 insertions(+), 6 deletions(-)

[Intel-gfx] [GLK MIPI DSI V4 6/8] drm/i915i/glk: Program MIPI_CLOCK_CTRL only for BXT

From: Deepak M Register MIPI_CLOCK_CTRL is applicable only for BXT platform. Future platform have other registers to program the escape clock dividers. Signed-off-by: Deepak M Signed-off-by: Madhav Chauhan ---

[Intel-gfx] [GLK MIPI DSI V4 7/8] drm/i915/glk: Program txesc clock divider for GLK

From: Deepak M v2: Addressed Jani's Review comments(renamed bit field macros) Txesc clock divider is calculated and programmed for geminilake platform. Signed-off-by: Deepak M Signed-off-by: Madhav Chauhan ---

[Intel-gfx] [GLK MIPI DSI V4 3/8] drm/i915/glk: Add MIPIIO Enable/disable sequence

From: Deepak M v2: Addressed Jani's Review comments(renamed bit field macros) v3: Jani's Review comment for aligning code to platforms and added wrapper functions. v4: Corrected enable/disable seuqence as per BSPEC Signed-off-by: Deepak M Signed-off-by:

[Intel-gfx] [GLK MIPI DSI V4 4/8] drm/i915: Set the Z inversion overlap field

From: Deepak M Dual link Z-inversion overlap field is present in MIPI_CTRL register unlike the older platforms, hence setting the same in this patch. Signed-off-by: Deepak M Signed-off-by: Madhav Chauhan ---

[Intel-gfx] [GLK MIPI DSI V4 2/8] drm/i915/glk: Program new MIPI DSI PHY registers for GLK

From: Deepak M Program the clk lane and tlpx time count registers to configure DSI PHY. v2: Addressed Jani's Review comments(renamed bit field macros) v3: Program clk lane timing reg same as dphy param reg. Signed-off-by: Deepak M Signed-off-by: Madhav

[Intel-gfx] [GLK MIPI DSI V4 1/8] drm/i915/glk: Program dphy param reg for GLK

From: Deepak M For GEMINILAKE, dphy param reg values are programmed in terms of HS byte clock count while for older platforms in terms of HS ddr clk count. v2: Added comments to clarify ddr clock count calculation Signed-off-by: Deepak M Signed-off-by:

[Intel-gfx] [GLK MIPI DSI V4 5/8] drm/i915/glk: Add DSI PLL divider range for glk

From: Deepak M PLL divider range for GLK is different than that of BXT, hence adding the GLK range check in this patch. Signed-off-by: Deepak M Signed-off-by: Madhav Chauhan --- drivers/gpu/drm/i915/i915_reg.h | 4

[Intel-gfx] [GLK MIPI DSI V4 0/8] GLK MIPI DSI VIDEO MODE PATCHES

The patches in this list enable MIPI DSI video mode support for GLK platform. Tesed locally. v2: Renamed bitfields macros as per review comments(Jani) v3: Code alignment/abstraction as per arch (Jani review comments) v4: Fix DSI disable sequence, pll divider checks. Review comments(Jani) Deepak M

  1   2   >