[Intel-gfx] [PATCH v2] drm/i915: Refactor wakeup of the next breadcrumb waiter

Since extracting the reset wakeup into a independent waitqueue, we only need to consider the possibility of there being an outstanding breadcrumb interrupt when advancing onto the next waiter. Both paths can now use the same code, so refactor it to a common function. Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH] drm/i915: Always wakeup the next breadcrumb waiter

On Thu, Mar 02, 2017 at 11:02:11PM +, Chris Wilson wrote: > Whenever we advance from one completed waiter to the next, give it a > kick so that it can check to see if its seqno completed during the > switch. We used to rely on faking an interrupt to determine when the > wake up was required,

[Intel-gfx] ✓ Fi.CI.BAT: success for HDMI 2.0: Scrambling in DRM layer (rev6)

== Series Details == Series: HDMI 2.0: Scrambling in DRM layer (rev6) URL : https://patchwork.freedesktop.org/series/19161/ State : success == Summary == Series 19161v6 HDMI 2.0: Scrambling in DRM layer https://patchwork.freedesktop.org/api/1.0/series/19161/revisions/6/mbox/ Test

[Intel-gfx] [PATCH v6 6/6] drm/i915: allow HDMI 2.0 clock rates

Geminilake has a native HDMI 2.0 controller, which is capable of driving clocks upto 594Mhz. This patch updates the max tmds clock limit for the same. V2: rebase V3: rebase V4: added r-b from Ander V5: rebase V6: rebase Cc: Ander Conselvan De Oliveira

[Intel-gfx] [PATCH v6 0/6] HDMI 2.0: Scrambling in DRM layer

HDMI 2.0 spec defines a method to reduce the RF footprint while operating at higher pixel clocks, which is called Scrambling. Scrambling can be controlled over a new set of I2C registers which are accessible over existing DDC I2C lines, called SCDC register set. This patch series contains 6

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

From: Thierry Reding SCDC is a mechanism defined in the HDMI 2.0 specification that allows the source and sink devices to communicate. This commit introduces helpers to access the SCDC and provides the symbolic names for the various registers defined in the specification.

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

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 clocks, for reduced RF footprint. This patch checks if the monitor supports scrambling, and if required, enables it during the modeset.

[Intel-gfx] [PATCH v6 2/6] drm/edid: check for HF-VSDB block

From: Thierry Reding This patch implements a small function that finds if a given CEA db is hdmi-forum vendor specific data block or not. V2: Rebase. V3: Added R-B from Jose. V4: Rebase V5: Rebase V6: Rebase Signed-off-by: Thierry Reding Signed-off-by:

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

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 features - Adds another structure drm_scdc within drm_hdmi_info, to reflect scdc support and capabilities in connected

[Intel-gfx] [PATCH v6 4/6] drm/edid: detect SCDC support in HF-VSDB

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 features - Adds another structure drm_scdc within drm_hdmi_info, to reflect scdc support and capabilities in connected

Re: [Intel-gfx] [PATCH] drm/i915: suppress atomic commit error message under gvt-g env

that depends on whether native can accept this log level degraded. let's see if there another opinions from community~ -Original Message- From: Wang, Zhi A Sent: Friday, March 03, 2017 10:56 AM To: Niu, Bing ; intel-gfx@lists.freedesktop.org Cc: Lv, Zhiyuan

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: suppress atomic commit error message under gvt-g env

== Series Details == Series: drm/i915: suppress atomic commit error message under gvt-g env URL : https://patchwork.freedesktop.org/series/20600/ State : warning == Summary == Series 20600v1 drm/i915: suppress atomic commit error message under gvt-g env

Re: [Intel-gfx] [PATCH] drm/i915: suppress atomic commit error message under gvt-g env

Can we directly use DRM_DEBUG_KMS() for this periodic error message? On 03/03/17 19:53, bing@intel.com wrote: From: Bing Niu under virtualization enviroment, it is possible guest update pipe registers across vblank intervals due to overhead of mmio traps or vm schedule

[Intel-gfx] [PATCH] drm/i915: suppress atomic commit error message under gvt-g env

From: Bing Niu under virtualization enviroment, it is possible guest update pipe registers across vblank intervals due to overhead of mmio traps or vm schedule out. However, it is safe since those pipe update happen in virual registers and will not be committed to hardware.

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: suppress automic commit error message under gvt-g env

error is irrelevant . but will resend a patch to correct commit message this patch just suppresses one error message under virtualization environment, not functionality change. and below error already happen in previous testing and has a bug tracking that. -Original Message- From:

[Intel-gfx] [PATCH i-g-t] igt/gem_bad_address: Remove test

The intent of the test is to provide an incorrect input to a command. Since the driver doesn't do any command validation, this test is removed as non applicable. Signed-off-by: Antonio Argenziano --- tests/Makefile.sources | 1 - tests/gem_bad_address.c | 75

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Always wakeup the next breadcrumb waiter

== Series Details == Series: drm/i915: Always wakeup the next breadcrumb waiter URL : https://patchwork.freedesktop.org/series/20590/ State : success == Summary == Series 20590v1 drm/i915: Always wakeup the next breadcrumb waiter

[Intel-gfx] [PATCH] drm/i915: Always wakeup the next breadcrumb waiter

Whenever we advance from one completed waiter to the next, give it a kick so that it can check to see if its seqno completed during the switch. We used to rely on faking an interrupt to determine when the wake up was required, but now the irq should always be enabled and so no longer receive the

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Drop spinlocks around adding to the client request list

On Thu, Mar 02, 2017 at 12:48:31PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Drop spinlocks around adding to the client request list > URL : https://patchwork.freedesktop.org/series/20555/ > State : failure > > == Summary == > > Series 20555v1 drm/i915: Drop

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

IRC acked by Harry Wentland " dhnkrn, the patch for driver-private atomic state object makes sense to me. Didn't realize that's the same one from early February. Feel free to add my Acked-by" -DK On Wed, 2017-02-08 at 22:38 -0800, Dhinakaran Pandiyan wrote: > It is necessary to track states

Re: [Intel-gfx] [PATCH] drm/i915: Differentiate between hangcheck waiting for timer or scheduler

On Thu, Mar 02, 2017 at 09:01:06PM +, Chris Wilson wrote: > Check timer_pending() as well as work_pending() to see if the timer for > the hangcheck has already expired and the work is pending execution on > some list somewhere. > > Signed-off-by: Chris Wilson > Cc:

Re: [Intel-gfx] [PATCH] drm/i915: move the {skl, bxt}_{i, uni}nit_cdclk declarations

Didn't spot anything wrong with this, Reviewed-by: Dhinakaran Pandiyan -DK On Tue, 2017-02-21 at 18:23 -0300, Paulo Zanoni wrote: > Move the {skl,bxt}_{i,uni}nit_cdclk declarations to the place where > the intel_cdclk.c functions are declared since these

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Differentiate between hangcheck waiting for timer or scheduler

== Series Details == Series: drm/i915: Differentiate between hangcheck waiting for timer or scheduler URL : https://patchwork.freedesktop.org/series/20585/ State : success == Summary == Series 20585v1 drm/i915: Differentiate between hangcheck waiting for timer or scheduler

[Intel-gfx] [PATCH] drm/i915: Differentiate between hangcheck waiting for timer or scheduler

Check timer_pending() as well as work_pending() to see if the timer for the hangcheck has already expired and the work is pending execution on some list somewhere. Signed-off-by: Chris Wilson Cc: Mika Kuoppala ---

Re: [Intel-gfx] [PATCH 1/3] drm/i915: unify the x_modeset_calc_cdclk() functions

On Mon, Feb 20, 2017 at 05:00:40PM -0300, Paulo Zanoni wrote: > There's a lot of duplicated platform-independent logic in the current > modeset_calc_cdclk() functions. Adding cdclk support for more > platforms will only add more copies of this code. > > To solve this problem, in this patch we

Re: [Intel-gfx] [PATCH] drm/i915: Move bxt exclusive workarounds from gen9 func to bxt one.

On Thu, 2017-03-02 at 21:20 +0200, Ville Syrjälä wrote: > On Thu, Mar 02, 2017 at 11:15:29AM -0800, Rodrigo Vivi wrote: > > No functional change. Just a proper organization of the gen9 workarounds. > > > > Cc: Imre Deak > > Cc: Mika Kuoppala > > Cc:

Re: [Intel-gfx] [PATCH] drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks

On Mon, Feb 20, 2017 at 04:04:43PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Currently ILK-BDW explicitly disable LP1+ watermarks from their > .init_clock_gating() hooks. Unfortunately that hook gets called way too > late since by that

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Move bxt exclusive workarounds from gen9 func to bxt one.

== Series Details == Series: drm/i915: Move bxt exclusive workarounds from gen9 func to bxt one. URL : https://patchwork.freedesktop.org/series/20582/ State : success == Summary == Series 20582v1 drm/i915: Move bxt exclusive workarounds from gen9 func to bxt one.

[Intel-gfx] [PATCH i-g-t v3] lib: Define a common bit operations library

Bring the test/set/clear bit functions we have into a single place. v2: Add gtk-doc comment blocks (Daniel) v3: Restore inline keyword. Cc: Daniel Vetter Reviewed-by: Joonas Lahtinen (v1) Signed-off-by: Michel Thierry

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Extend residency counter ranges on chv and byt

== Series Details == Series: drm/i915: Extend residency counter ranges on chv and byt URL : https://patchwork.freedesktop.org/series/20578/ State : success == Summary == Series 20578v1 drm/i915: Extend residency counter ranges on chv and byt

Re: [Intel-gfx] [PATCH i-g-t v2] lib: Define a common bit operations library

On 01/03/17 23:45, Daniel Vetter wrote: On Wed, Mar 01, 2017 at 04:14:31PM +, Chris Wilson wrote: On Wed, Mar 01, 2017 at 07:52:26AM -0800, Michel Thierry wrote: Bring the test/set/clear bit functions we have into a single place. v2: Add gtk-doc comment blocks (Daniel) Hiss, boo! Will

Re: [Intel-gfx] [PATCH] drm/i915: Move bxt exclusive workarounds from gen9 func to bxt one.

On Thu, Mar 02, 2017 at 11:15:29AM -0800, Rodrigo Vivi wrote: > No functional change. Just a proper organization of the gen9 workarounds. > > Cc: Imre Deak > Cc: Mika Kuoppala > Cc: Dhinakaran Pandiyan >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: VLV/CHV two-stage watermarks (rev3)

== Series Details == Series: drm/i915: VLV/CHV two-stage watermarks (rev3) URL : https://patchwork.freedesktop.org/series/16712/ State : success == Summary == Series 16712v3 drm/i915: VLV/CHV two-stage watermarks https://patchwork.freedesktop.org/api/1.0/series/16712/revisions/3/mbox/ Test

[Intel-gfx] [PATCH] drm/i915: Move bxt exclusive workarounds from gen9 func to bxt one.

No functional change. Just a proper organization of the gen9 workarounds. Cc: Imre Deak Cc: Mika Kuoppala Cc: Dhinakaran Pandiyan Signed-off-by: Rodrigo Vivi ---

Re: [Intel-gfx] [PATCH] drm/i915: Extend residency counter ranges on chv and byt

On Thu, Mar 02, 2017 at 06:21:37PM +, Chris Wilson wrote: > On Thu, Mar 02, 2017 at 08:13:31PM +0200, Ville Syrjälä wrote: > > On Thu, Mar 02, 2017 at 08:01:40PM +0200, Mika Kuoppala wrote: > > > We were passively acting on the high counter value bit > > > and as it was never set, we were only

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Disable irq for __i915_guc_submit wq_lock

On Thu, Mar 02, 2017 at 04:18:05PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915/guc: Disable irq for __i915_guc_submit wq_lock > URL : https://patchwork.freedesktop.org/series/20564/ > State : success > > == Summary == > > Series 20564v1 drm/i915/guc: Disable irq for

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for GuC Scrub vol. 1 (rev8)

On Thu, Mar 02, 2017 at 06:02:09PM +, Patchwork wrote: > == Series Details == > > Series: GuC Scrub vol. 1 (rev8) > URL : https://patchwork.freedesktop.org/series/16856/ > State : failure > > == Summary == > > CC [M] drivers/gpu/drm/i915/gvt/execlist.o > LD

Re: [Intel-gfx] [PATCH] drm/i915: Extend residency counter ranges on chv and byt

On Thu, Mar 02, 2017 at 08:20:24PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > On Thu, Mar 02, 2017 at 08:01:40PM +0200, Mika Kuoppala wrote: > >> We were passively acting on the high counter value bit > >> and as it was never set, we were only utilizing

Re: [Intel-gfx] [PATCH] drm/i915: Extend residency counter ranges on chv and byt

On Thu, Mar 02, 2017 at 08:13:31PM +0200, Ville Syrjälä wrote: > On Thu, Mar 02, 2017 at 08:01:40PM +0200, Mika Kuoppala wrote: > > We were passively acting on the high counter value bit > > and as it was never set, we were only utilizing the > > the 32bits of resolution. As the divisor with these

Re: [Intel-gfx] [PATCH] drm/i915: Extend residency counter ranges on chv and byt

Chris Wilson writes: > On Thu, Mar 02, 2017 at 08:01:40PM +0200, Mika Kuoppala wrote: >> We were passively acting on the high counter value bit >> and as it was never set, we were only utilizing the >> the 32bits of resolution. As the divisor with these platforms >> is

Re: [Intel-gfx] [PATCH] drm/i915: Extend residency counter ranges on chv and byt

Ville Syrjälä writes: > On Thu, Mar 02, 2017 at 08:01:40PM +0200, Mika Kuoppala wrote: >> We were passively acting on the high counter value bit >> and as it was never set, we were only utilizing the >> the 32bits of resolution. As the divisor with these platforms

Re: [Intel-gfx] [PATCH] drm/i915: Extend residency counter ranges on chv and byt

On Thu, Mar 02, 2017 at 06:13:15PM +, Chris Wilson wrote: > On Thu, Mar 02, 2017 at 08:01:40PM +0200, Mika Kuoppala wrote: > > We were passively acting on the high counter value bit > > and as it was never set, we were only utilizing the > > the 32bits of resolution. As the divisor with these

Re: [Intel-gfx] [PATCH] drm/i915: Extend residency counter ranges on chv and byt

On Thu, Mar 02, 2017 at 08:01:40PM +0200, Mika Kuoppala wrote: > We were passively acting on the high counter value bit > and as it was never set, we were only utilizing the > the 32bits of resolution. As the divisor with these platforms > is quite high, the wrap around happened in the less than

Re: [Intel-gfx] [PATCH] drm/i915: Extend residency counter ranges on chv and byt

On Thu, Mar 02, 2017 at 08:01:40PM +0200, Mika Kuoppala wrote: > We were passively acting on the high counter value bit > and as it was never set, we were only utilizing the > the 32bits of resolution. As the divisor with these platforms > is quite high, the wrap around happened in the less than

[Intel-gfx] [PATCH] drm/i915: Extend residency counter ranges on chv and byt

We were passively acting on the high counter value bit and as it was never set, we were only utilizing the the 32bits of resolution. As the divisor with these platforms is quite high, the wrap around happened in the less than 13 seconds. If we toggle the resolution bit in the control register and

[Intel-gfx] ✗ Fi.CI.BAT: failure for GuC Scrub vol. 1 (rev8)

== Series Details == Series: GuC Scrub vol. 1 (rev8) URL : https://patchwork.freedesktop.org/series/16856/ State : failure == Summary == CC [M] drivers/gpu/drm/i915/gvt/execlist.o LD drivers/misc/built-in.o LD drivers/pinctrl/built-in.o CC [M]

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Include GT/seqno activity in engine/hangcheck debugfs (rev2)

== Series Details == Series: drm/i915: Include GT/seqno activity in engine/hangcheck debugfs (rev2) URL : https://patchwork.freedesktop.org/series/20562/ State : success == Summary == Series 20562v2 drm/i915: Include GT/seqno activity in engine/hangcheck debugfs

[Intel-gfx] [PATCH v2 18/18] drm/i915: Add FIFO underrun tracepoints

From: Ville Syrjälä Add tracepoints for display FIFO underruns. Makes it more convenient to correlate the underruns with other display tracepoints. v2: s/i915/intel/ in the tracepoint name Signed-off-by: Ville Syrjälä Reviewed-by:

[Intel-gfx] [PATCH 17/18] drm/i915: Add cxsr toggle tracepoint

From: Ville Syrjälä Add a tracepoint for observing changes in the cxsr state. The tracepoint will dump out the frame and scanline counters for each pipe so that the information can be compared with eg. plane update tracepoints. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 16/18] drm/i915: Add VLV/CHV watermark/FIFO programming tracepoints

From: Ville Syrjälä Add tracepoints for observing the WM/FIFO programming on VLV/CHV. When compared with the plane and pipe update tracepoints this can be used to verify that everything is performed in the right sequence. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH v2 08/18] drm/i915: Skip useless watermark/FIFO related work on VLV/CHV when not needed

From: Ville Syrjälä Check whether anything relevant has actually change when we compute new watermarks for each plane in the state. If the watermarks for no primary/sprite planes changed we don't have to recompute the FIFO split or reprogram the DSBARB registers.

[Intel-gfx] [PATCH v2 15/18] drm/i915: Add plane update/disable tracepoints

From: Ville Syrjälä Add tracepoints for plane programming. The tracepoints will dump the frame and scanline counters, so this can be used to verify eg. that the plane gets reprogrammed at the right time with respect to watermark programming (if we have appropriate

[Intel-gfx] [PATCH 14/18] drm/i915: Kill level 0 wm hack for VLV/CHV

From: Ville Syrjälä We now compute the watermarks correctly, so just return an error if we can't support the configuration. Signed-off-by: Ville Syrjälä Reviewed-by: Maarten Lankhorst ---

[Intel-gfx] [PATCH 09/18] drm/i915: Compute proper intermediate wms for vlv/cvh

From: Ville Syrjälä Since the watermark registers arent double buffered on VLV/CHV, we'll need to play around with intermediate watermarks same was as we do on ILK-BDW. The watermark registers on VLV/CHV contain inverted values, so to find the intermediate

[Intel-gfx] [PATCH 01/18] drm/i915: Track visible planes in a bitmask

From: Ville Syrjälä In a lot of place we wish to know which planes on the crtc are actually visible, or how many of them there are. Let's start tracking that in a bitmask in the crtc state. We already track enabled planes (ie. ones with an fb and crtc specified by

[Intel-gfx] [PATCH 05/18] drm/i915: Plop vlv/chv fifo sizes into crtc state

From: Ville Syrjälä Move the vlv/chv FIFO size tracking into the crtc_state. As with the wms for now this just acts as temporary storage. Signed-off-by: Ville Syrjälä Reviewed-by: Maarten Lankhorst

[Intel-gfx] [PATCH v2 12/18] drm/i915: Sanitize VLV/CHV watermarks properly

From: Ville Syrjälä Clear out the watermark for all disabled planes to 0. This is required to avoid falsely thinking that the inherited watermarks are bogus in case the watermark is actually higher than the FIFO size. v2: s/noninverted/raw/ for consistency with

[Intel-gfx] [PATCH v2 13/18] drm/i915: Workaround VLV/CHV sprite1->sprite0 enable underrun

From: Ville Syrjälä On VLV/CHV enabling sprite0 when sprite1 has already been enabled may lead to an underrun. This only happens when sprite0 FIFO size is zero prior to enabling it. Hence an effective workaround is to always allocate at least one cacheline for

[Intel-gfx] [PATCH 11/18] drm/i915: Only use update_wm_{pre, post} for pre-ilk platforms

From: Ville Syrjälä Now that vlv/chv have more proper wm programming support, let's reduce the the update_wm_{pre,post} flags to only cover the pre-ilk platforms. When we finally convert those as well we can drop these flags entirely. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH v2 02/18] drm/i915: Track plane fifo sizes under intel_crtc

From: Ville Syrjälä Track the plane fifo sizes under intel_crtc instead of under each intel_plane. Avoids looping over the planes in a bunch of places, and later we'll move this tracking into the crtc state properly. v2: Nuke intel_plane_wm_parameters (Maarten)

[Intel-gfx] [PATCH 03/18] drm/i915: Move vlv wms from crtc->wm_state to crtc->wm.active.vlv

From: Ville Syrjälä In an effort to make the vlv/chv wm code look and behave more like the ilk+ code, let's move the current active wms next to the corresponding ilk wms. Signed-off-by: Ville Syrjälä Reviewed-by: Maarten Lankhorst

[Intel-gfx] [PATCH 10/18] drm/i915: Nuke crtc->wm.cxsr_allowed

From: Ville Syrjälä Remove crtc->wm.cxsr_allowed and just rely on crtc_state->disable_cxsr instead. This was used only by vlv/chv to indicate whether to enable cxsr in the wm computation. That doesn't really work anymore, and as far as the optimal watermarks go

[Intel-gfx] [PATCH v2 06/18] drm/i915: Compute VLV/CHV FIFO sizes based on the PM2 watermarks

From: Ville Syrjälä Let's compute the watermarks first and the FIFO size second. This way we can make sure the FIFO split is the most accommodating to the watermarks. Previously we could have potentially computed a FIFO split that couldn't accommodate the PM2

[Intel-gfx] [PATCH v2 07/18] drm/i915: Compute vlv/chv wms the atomic way

From: Ville Syrjälä Start computing the vlv/chv watermarks the atomic way, from the .compute_pipe_wm() hook. We'll recompute the actual watermarks for only planes that are part of the state, the other planes will keep their watermark from the last time it was

[Intel-gfx] [PATCH v3 00/18] drm/i915: VLV/CHV two-stage watermarks (v3)

From: Ville Syrjälä Everything is r-b'd already, but I wanted to do a few mostly cosmetic changes so that things will look more similar to my upcoming g4x two stage watermarks work. The changes are: * rename the 'noninverted' watermarks to 'raw' since g4x

[Intel-gfx] [PATCH 04/18] drm/i915: Plop vlv wm state into crtc_state

From: Ville Syrjälä Relocate the vlv/chv wm state to live under intel_crtc_state. Note that for now this just behaves as a temporary storage. But it'll be easier to conver the thing over to properly pre-computing the state when it's already in the right place.

Re: [Intel-gfx] [PATCH 01/10] drm/i915/uc: Rename intel_?uc_{setup, load}() to _init_hw()

On Thu, Mar 02, 2017 at 05:03:45PM +0100, Arkadiusz Hiler wrote: > GuC historically has two "startup" functions called _init() and _setup() > > Then HuC came with it's _init() and _load(). > > This commit renames intel_guc_setup() and intel_huc_load() to > *uc_init_hw() as they called from the

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Assert that fence->lock is held in an irq-safe manner

== Series Details == Series: series starting with [CI,1/2] drm/i915: Assert that fence->lock is held in an irq-safe manner URL : https://patchwork.freedesktop.org/series/20566/ State : success == Summary == Series 20566v1 Series without cover letter

Re: [Intel-gfx] [PATCH] drm/i915: Include power-management state in gpu error dump

Chris Wilson writes: > On Thu, Mar 02, 2017 at 05:29:18PM +0200, Mika Kuoppala wrote: >> Chris Wilson writes: >> >> > Useful for double checking that the device is powered up when it hung, >> > include both the status of the power management

Re: [Intel-gfx] [PATCH 04/10] drm/i915/uc: Move intel_uc_fw_fetch() to intel_uc.c

On Thu, Mar 02, 2017 at 04:36:05PM +, Chris Wilson wrote: > On Thu, Mar 02, 2017 at 05:03:48PM +0100, Arkadiusz Hiler wrote: > > The file fits better. > > > > Additionally rename it to intel_uc_prepare_fw(), as the function does > > more than simple fetch. > > > > v2: remove second

Re: [Intel-gfx] [PATCH 04/10] drm/i915/uc: Move intel_uc_fw_fetch() to intel_uc.c

On Thu, Mar 02, 2017 at 05:03:48PM +0100, Arkadiusz Hiler wrote: > The file fits better. > > Additionally rename it to intel_uc_prepare_fw(), as the function does > more than simple fetch. > > v2: remove second declaration, reorder (M. Wajdeczko) > > Cc: Michal Wajdeczko

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Disable irq for __i915_guc_submit wq_lock

== Series Details == Series: drm/i915/guc: Disable irq for __i915_guc_submit wq_lock URL : https://patchwork.freedesktop.org/series/20564/ State : success == Summary == Series 20564v1 drm/i915/guc: Disable irq for __i915_guc_submit wq_lock

[Intel-gfx] [PATCH 10/10] drm/i915/uc: Add params for specifying firmware

`guc_firmware_path` and `huc_firmware_path` module parameters are added. Using the parameter disabled version checks and loads desired firmware instead of the default one. v2: make params unsafe && notice about disabled fw check (J. Lahtinen) Cc: Chris Wilson Cc:

[Intel-gfx] [PATCH 09/10] drm/i915/uc: Separate firmware selection and preparation

intel_{h,g}uc_init_fw selects correct firmware and then triggers it's preparation (fetch + initial parsing). This change separates out select steps, so those can be called by the sanitize_options(). Then, during the init_fw() we prepare the firmware if the firmware was selected. Cc: Michal

[Intel-gfx] [PATCH 05/10] drm/i915/uc: Introduce intel_uc_init_fw()

Instead of calling intel_guc_init() and intel_huc_init() one by one this patch introduces intel_uc_init_fw() function that calls them both. Called functions are renamed accordingly. Trying to have subject_verb_object ordering and more descriptive names, the intel_huc_init() and intel_guc_init()

[Intel-gfx] [PATCH 08/10] drm/i915/uc: Simplify firmware path handling

Currently fw->path values can represent one of three possible states: 1) NULL - device without the uC 2) '\0' - device with the uC but have no firmware 3) else - device with the uC and we have firmware Second case is used only to WARN at a later stage. We can WARN right away and merge cases

[Intel-gfx] [PATCH 06/10] drm/i915/guc: Extract param logic form guc_init_fw()

Let intel_guc_init_fw() focus on determining and fetching the correct firmware. This patch introduces intel_uc_sanitize_options() that is called from intel_sanitize_options(). Then, if we have GuC, we can call intel_guc_init_fw() conditionally and we do not have to do the internal checks. v2:

[Intel-gfx] [PATCH 07/10] drm/i915/guc: Simplify intel_guc_init_hw()

Current version of intel_guc_init_hw() does a lot: - cares about submission - loads huc - implement WA This change offloads some of the logic to intel_uc_init_hw(), which now cares about the above. v2: rename guc_hw_reset and fix typo in define name (M. Wajdeczko) v3: rename once again v4:

[Intel-gfx] [PATCH 03/10] drm/i915/huc: Add huc_to_i915

Used to obtain "dev_priv" from huc struct pointer. We already have similar thing for guc. Cc: Michal Wajdeczko Signed-off-by: Arkadiusz Hiler Reviewed-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_drv.h |

[Intel-gfx] [PATCH v6 00/10] GuC Scrub vol. 1

General GuC/HuC cleanup simplifying logic, and moving chunks around as the area got pretty rusty. A lot of logic were extracted from intel_guc_load() to other functions - it did not only handle the actual loading but had WA implementations and the code that enabled submission baked into it. This

[Intel-gfx] [PATCH 04/10] drm/i915/uc: Move intel_uc_fw_fetch() to intel_uc.c

The file fits better. Additionally rename it to intel_uc_prepare_fw(), as the function does more than simple fetch. v2: remove second declaration, reorder (M. Wajdeczko) Cc: Michal Wajdeczko Signed-off-by: Arkadiusz Hiler ---

[Intel-gfx] [PATCH 01/10] drm/i915/uc: Rename intel_?uc_{setup, load}() to _init_hw()

GuC historically has two "startup" functions called _init() and _setup() Then HuC came with it's _init() and _load(). This commit renames intel_guc_setup() and intel_huc_load() to *uc_init_hw() as they called from the i915_gem_init_hw(). The aim is to be consistent in that entry points called

[Intel-gfx] [PULL] topic/designware-baytrail for 4.12 [UPDATED]

Hi Dave, topic/designware-baytrail-2017-03-02: Baytrail PMIC vs. PMU race fixes from Hans de Goede This time the right version (v4), with the compile fix. Updated pull request with new tag, same story as before Cheers, Daniel The following changes since commit

Re: [Intel-gfx] [PATCH] drm/i915: Include power-management state in gpu error dump

On Thu, Mar 02, 2017 at 05:29:18PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > Useful for double checking that the device is powered up when it hung, > > include both the status of the power management and our rpm wakelock. > > > > Signed-off-by: Chris

Re: [Intel-gfx] [PATCH] drm/i915: Include power-management state in gpu error dump

Chris Wilson writes: > Useful for double checking that the device is powered up when it hung, > include both the status of the power management and our rpm wakelock. > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala

Re: [Intel-gfx] [PATCH v2] drm/i915: Include GT/seqno activity in engine/hangcheck debugfs

Chris Wilson writes: > Whilst investigating some mysterious failures with hangcheck not running > during gem_busy/basic-hang-default, the question is why did we decide to > cancel the retire_work (which queues the hangcheck)? That decision is > based around GT activity,

Re: [Intel-gfx] [PULL] topic/designware-baytrail for 4.12

Hi, On 02-03-17 15:47, Daniel Vetter wrote: On Thu, Mar 2, 2017 at 3:38 PM, Hans de Goede wrote: On 02-03-17 08:00, Daniel Vetter wrote: On Wed, Mar 01, 2017 at 11:42:48AM +0100, Daniel Vetter wrote: Hi all, topic/designware-baytrail-2017-03-01: Baytrail PMIC vs. PMU

[Intel-gfx] [PATCH] drm/i915: Include power-management state in gpu error dump

Useful for double checking that the device is powered up when it hung, include both the status of the power management and our rpm wakelock. Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- drivers/gpu/drm/i915/i915_drv.h | 2 ++

[Intel-gfx] [PATCH v2] drm/i915: Include GT/seqno activity in engine/hangcheck debugfs

Whilst investigating some mysterious failures with hangcheck not running during gem_busy/basic-hang-default, the question is why did we decide to cancel the retire_work (which queues the hangcheck)? That decision is based around GT activity, so include that information in the debug report. v2:

Re: [Intel-gfx] [PATCH] drm/i915/guc: Disable irq for __i915_guc_submit wq_lock

On 02/03/2017 16:53, Chris Wilson wrote: __i915_guc_submit may be, despite my assertion, called from outside of an irq-safe spinlock so we need to use a full spin_lock_irqsave and not cheat using a spin_lock. (The initial notify callback from the completed fence is called before the spinlock is

[Intel-gfx] [CI 2/2] drm/i915: s/assert_spin_locked/lockdep_assert_held/

assert_spin_locked() becomes an unconditionally compiled BUG_ON(), adding debug code right into the heart of critical routines like interrupt handlers. textdata bss dec hex 1296480 199442272 1318696 141f28 before (lockdep disabled) 1295984 199442272 1318200 141d38

[Intel-gfx] [CI 1/2] drm/i915: Assert that fence->lock is held in an irq-safe manner

Everytime we take the fence->lock (aka request->lock), we must do so with irqs disabled since it may be used from within an hardirq context. As sometimes we are taking the lock in a nested manner, assert that the caller did disable the irqs for us. Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH] drm/i915: Fix legacy cursor vs. watermarks for ILK-BDW

On Sat, Feb 25, 2017 at 04:31:04PM +0100, Maarten Lankhorst wrote: > Op 24-02-17 om 14:11 schreef Ville Syrjälä: > > On Mon, Feb 20, 2017 at 03:30:58PM +0100, Maarten Lankhorst wrote: > >> Op 20-02-17 om 14:38 schreef Ville Syrjälä: > >>> On Mon, Feb 20, 2017 at 10:04:06AM +0100, Maarten Lankhorst

Re: [Intel-gfx] [PATCH] drm/i915/guc: Disable irq for __i915_guc_submit wq_lock

On Thu, Mar 02, 2017 at 02:53:23PM +, Chris Wilson wrote: > __i915_guc_submit may be, despite my assertion, called from outside of > an irq-safe spinlock so we need to use a full spin_lock_irqsave and not > cheat using a spin_lock. (The initial notify callback from the completed > fence is

[Intel-gfx] [PATCH] drm/i915/guc: Disable irq for __i915_guc_submit wq_lock

__i915_guc_submit may be, despite my assertion, called from outside of an irq-safe spinlock so we need to use a full spin_lock_irqsave and not cheat using a spin_lock. (The initial notify callback from the completed fence is called before the spinlock is taken to wake up all waiters and call their

Re: [Intel-gfx] [PULL] topic/designware-baytrail for 4.12

On Thu, Mar 2, 2017 at 3:38 PM, Hans de Goede wrote: > On 02-03-17 08:00, Daniel Vetter wrote: >> >> On Wed, Mar 01, 2017 at 11:42:48AM +0100, Daniel Vetter wrote: >>> >>> Hi all, >>> >>> topic/designware-baytrail-2017-03-01: >>> Baytrail PMIC vs. PMU race fixes from Hans de

Re: [Intel-gfx] [PATCH] drm/i915/glk: Fix DSI enable I/O sequence

On Wed, 01 Mar 2017, Madhav Chauhan wrote: > One of the if statement covers the next line in enable I/O sequence. > This patch correct the same by adding error message. > > Signed-off-by: Madhav Chauhan Pushed, thanks for the patch. BR, Jani.

Re: [Intel-gfx] [PULL] topic/designware-baytrail for 4.12

Hi, On 02-03-17 08:00, Daniel Vetter wrote: On Wed, Mar 01, 2017 at 11:42:48AM +0100, Daniel Vetter wrote: Hi all, topic/designware-baytrail-2017-03-01: Baytrail PMIC vs. PMU race fixes from Hans de Goede I opted to put all the patches for all subsystems into the topic branches, so that if

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: suppress automic commit error message under gvt-g env

== Series Details == Series: drm/i915: suppress automic commit error message under gvt-g env URL : https://patchwork.freedesktop.org/series/20558/ State : failure == Summary == Series 20558v1 drm/i915: suppress automic commit error message under gvt-g env

[Intel-gfx] [PATCH] drm/i915: Include GT/seqno activity in engine/hangcheck debugfs

Whilst investigating some mysterious failures with hangcheck not running during gem_busy/basic-hang-default, the question is why did we decide to cancel the retire_work (which queues the hangcheck)? That decision is based around GT activity, so include that information in the debug report.

  1   2   >