[Intel-gfx] ✗ Ro.CI.BAT: failure for Enable upfront link training on DDI platforms

== Series Details == Series: Enable upfront link training on DDI platforms URL : https://patchwork.freedesktop.org/series/10821/ State : failure == Summary == Applying: drm/i915: Don't pass crtc_state to intel_dp_set_link_params() Applying: drm/i915: Remove ddi_pll_sel from intel_crtc_state

[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915/skl: Add support for the SAGV, fix underrun hangs (rev6)

== Series Details == Series: drm/i915/skl: Add support for the SAGV, fix underrun hangs (rev6) URL : https://patchwork.freedesktop.org/series/9736/ State : success == Summary == Series 9736v6 drm/i915/skl: Add support for the SAGV, fix underrun hangs

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Maarten's pre-g4x GPU reset regression fix + other reset stuff

On Sat, Aug 06, 2016 at 08:45:37AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Maarten's pre-g4x GPU reset regression fix + other reset > stuff > URL : https://patchwork.freedesktop.org/series/10731/ > State : failure > > == Summary == > > Series 10731v1 drm/i915:

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Account for TSEG size when determining 865G stolen base

On Mon, Aug 08, 2016 at 11:25:22AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Account for TSEG size when determining 865G stolen base > URL : https://patchwork.freedesktop.org/series/10779/ > State : failure > > == Summary == > > Series 10779v1 drm/i915: Account for

[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable upfront link training on DDI platforms

== Series Details == Series: Enable upfront link training on DDI platforms URL : https://patchwork.freedesktop.org/series/10821/ State : failure == Summary == CC [M] drivers/gpu/drm/i915/intel_dsi.o CC [M] drivers/gpu/drm/i915/intel_dsi_dcs_backlight.o LD drivers/net/built-in.o

Re: [Intel-gfx] include/drm/i915_drm.h:96: possible bad bitmask ?

On 8 August 2016 at 19:40, Daniel Vetter wrote: > On Mon, Aug 08, 2016 at 10:31:32AM +0100, David Binderman wrote: >> Hello there, >> >> Recent versions of gcc say this: >> >> include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’ >> requires 37 bits to represent, but

[Intel-gfx] [PATCH 0/9] Enable upfront link training on DDI platforms

This patch series enables upfront link training on DDI platforms (SKL/BDW/HSW/BXT). They are based on some of the pacthes submitted earlier by Ander and Durgadoss. The upfront link training had to be factored out of long pulse hanlder because of deadlock issues seen on DP MST cases. Now the

[Intel-gfx] [PATCH v2 4/9] drm/i915: Split intel_ddi_pre_enable() into DP and HDMI versions

From: Ander Conselvan de Oliveira Split intel_ddi_pre_enable() into encoder type specific versions that don't depend on crtc_state. The necessary parameters are passed as function arguments. This split will be necessary for implementing DP upfront link

[Intel-gfx] [PATCH 1/9] drm/i915: Don't pass crtc_state to intel_dp_set_link_params()

From: Ander Conselvan de Oliveira Decouple intel_dp_set_link_params() from struct intel_crtc_state. This will be useful for implementing DP upfront link training. Reviewed-by: Durgadoss R Signed-off-by: Ander Conselvan de Oliveira

[Intel-gfx] [PATCH v8 5/9] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

From: Durgadoss R To support USB type C alternate DP mode, the display driver needs to know the number of lanes required by the DP panel as well as number of lanes that can be supported by the type-C cable. Sometimes, the type-C cable may limit the bandwidth even if Panel

[Intel-gfx] [PATCH 7/9] drm/i915/dp: Enable upfront link training on SKL

From: Jim Bride Split the PLL selection code out of the BXT upfront link training implementation and into a stand-alone function in order to allow for the implementation of a platform neutral upfront link training function, and then enable upfront link training for

[Intel-gfx] [PATCH 9/9] drm/i915: Enable upfront link training support for HSW/BDW

Get the PLLs for HSW/BDW using the platform specific function and add hooks for enabling upfront link training on HSW and BDW. Signed-off-by: Manasi Navare --- drivers/gpu/drm/i915/intel_ddi.c | 2 ++ drivers/gpu/drm/i915/intel_dp.c | 4 +++- 2 files changed, 5

[Intel-gfx] [PATCH 6/9] drm/i915: Split skl_get_dpll()

From: Jim Bride Split out the DisplayPort and HDMI pll setup code into separate functions and refactor the DP code does not directly depend on crtc state, so that the code can be used for upfront link training. Signed-off-by: Jim Bride

[Intel-gfx] [PATCH v2 2/9] drm/i915: Remove ddi_pll_sel from intel_crtc_state

From: Ander Conselvan de Oliveira The value of ddi_pll_sel is derived from the selection of shared dpll, so just calculate the final value when necessary. v2: Actually remove it from crtc state and delete remaining usages. (CI) Reviewed-by: Durgadoss R

[Intel-gfx] [PATCH 8/9] drm/i915: Split hsw_get_dpll()

Split out the DisplayPort and HDMI pll setup code into separate functions and refactor the DP code that calculates the pll so that it doesn't depend on crtc state. This will be used for acquiring port pll when doing upfront link training. Signed-off-by: Manasi Navare

[Intel-gfx] [PATCH v2 3/9] drm/i915: Split intel_ddi_pre_enable() into DP and HDMI versions

From: Ander Conselvan de Oliveira Split intel_ddi_pre_enable() into encoder type specific versions that don't depend on crtc_state. The necessary parameters are passed as function arguments. This split will be necessary for implementing DP upfront link

[Intel-gfx] [drm-intel:topic/drm-misc 5/18] drivers/gpu/drm/i915/intel_display.c:14148:23: error: 'struct drm_plane_state' has no member named 'clip'

tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: cfc5adea1955ee8ddb62cc0d20ee454472033b6a commit: 936e71e314d393cd74c42c81b00b2092330c802d [5/18] drm/i915: Use drm_plane_state.{src,dst,visible} config: i386-randconfig-s0-201632 (attached as .config) compiler: gcc-6 (Debian

[Intel-gfx] [drm-intel:topic/drm-misc 4/18] DocBook: drivers/gpu/drm/drm_plane_helper.c:248: warning: No description found for parameter 'dst'

tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: cfc5adea1955ee8ddb62cc0d20ee454472033b6a commit: df86af9133b4958a04c44828d29617eb1a6ff31c [4/18] drm/plane-helper: Add drm_plane_helper_check_state() reproduce: make htmldocs All warnings (new ones prefixed by >>): >>

[Intel-gfx] [PATCH v10] drm/i915/skl: Add support for the SAGV, fix underrun hangs

Since the watermark calculations for Skylake are still broken, we're apt to hitting underruns very easily under multi-monitor configurations. While it would be lovely if this was fixed, it's not. Another problem that's been coming from this however, is the mysterious issue of underruns causing

[Intel-gfx] [PATCH v10] drm/i915/skl: Add support for the SAGV, fix underrun hangs

Since the watermark calculations for Skylake are still broken, we're apt to hitting underruns very easily under multi-monitor configurations. While it would be lovely if this was fixed, it's not. Another problem that's been coming from this however, is the mysterious issue of underruns causing

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Give one extra block per line for SKL plane WM calculations

Em Seg, 2016-08-08 às 19:35 +0100, Chris Wilson escreveu: > On Mon, Aug 08, 2016 at 06:25:49PM +, Zanoni, Paulo R wrote: > > > > Em Qui, 2016-08-04 às 16:51 -0700, Matt Roper escreveu: > > > > > > On Thu, Aug 04, 2016 at 07:36:15PM -0400, Lyude wrote: > > > > > > > > > > > > Reviewed-by:

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Give one extra block per line for SKL plane WM calculations

Em Seg, 2016-08-08 às 18:25 +, Zanoni, Paulo R escreveu: > Em Qui, 2016-08-04 às 16:51 -0700, Matt Roper escreveu: > > > > On Thu, Aug 04, 2016 at 07:36:15PM -0400, Lyude wrote: > > > > > > > > > Reviewed-by: Lyude > > > > Merged to dinq.  Thanks for the quick review. >

Re: [Intel-gfx] [PATCH] drm: Make sure drm_vblank_no_hw_counter isn't abused

On Mon, Aug 8, 2016 at 12:27 PM, Vivi, Rodrigo wrote: > Reviewed-by: Rodrigo Vivi > > On Mon, 2016-08-08 at 18:24 +0200, Daniel Vetter wrote: >> Shouldn't be possible since everyone kzallocs this, but better safe >> than sorry. Random drive-by-idea

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Give one extra block per line for SKL plane WM calculations

On Mon, Aug 08, 2016 at 06:25:49PM +, Zanoni, Paulo R wrote: > Em Qui, 2016-08-04 às 16:51 -0700, Matt Roper escreveu: > > On Thu, Aug 04, 2016 at 07:36:15PM -0400, Lyude wrote: > > > > > > Reviewed-by: Lyude > > > > Merged to dinq.  Thanks for the quick review. > >

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Give one extra block per line for SKL plane WM calculations

Em Qui, 2016-08-04 às 16:51 -0700, Matt Roper escreveu: > On Thu, Aug 04, 2016 at 07:36:15PM -0400, Lyude wrote: > > > > Reviewed-by: Lyude > > Merged to dinq.  Thanks for the quick review. Regression? This patch makes my SKL machine fail any modesets. I now boot to a

[Intel-gfx] ✓ Ro.CI.BAT: success for drm: Make sure drm_vblank_no_hw_counter isn't abused

== Series Details == Series: drm: Make sure drm_vblank_no_hw_counter isn't abused URL : https://patchwork.freedesktop.org/series/10800/ State : success == Summary == Series 10800v1 drm: Make sure drm_vblank_no_hw_counter isn't abused

Re: [Intel-gfx] [PATCH] drm: Make sure drm_vblank_no_hw_counter isn't abused

Reviewed-by: Rodrigo Vivi On Mon, 2016-08-08 at 18:24 +0200, Daniel Vetter wrote: > Shouldn't be possible since everyone kzallocs this, but better safe > than sorry. Random drive-by-idea really. > > Cc: Rodrigo Vivi > Signed-off-by: Daniel Vetter

[Intel-gfx] [PATCH] drm: Make sure drm_vblank_no_hw_counter isn't abused

Shouldn't be possible since everyone kzallocs this, but better safe than sorry. Random drive-by-idea really. Cc: Rodrigo Vivi Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_irq.c | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Drop reference to current state wait req as soon as it goes unused

Daniel Vetter writes: > We still need to clean up the reference in case of failure, which > means latest in intel_plane_destroy_state(). Also hanging onto a > request isn't that evil really, why can't we just only clean up in the > destroy function? Sticking a cleanup there as

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Drop reference to current state wait req as soon as it goes unused

On Mon, Aug 8, 2016 at 1:23 PM, Maarten Lankhorst wrote: > There are two paths into intel_cleanup_plane_fb, the normal completion > path and the failure path. > > In the failure case, intel_cleanup_plane_fb is called before > drm_atomic_helper_swap_state, so any

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Move common seqno reset to intel_engine_cs.c

On 8 August 2016 at 11:15, Chris Wilson wrote: > On Mon, Aug 08, 2016 at 10:40:35AM +0100, Matthew Auld wrote: >> In which header does the prototype for intel_engine_init_seqno now exist? > > Same as before, intel_ringbuffer.h. We haven't yet decided upon > splitting

Re: [Intel-gfx] [PATCH 5/5] drm/i915: debugfs spring cleaning

On Mon, Aug 08, 2016 at 04:20:01PM +0300, David Weinehall wrote: > @@ -136,13 +140,14 @@ static void > describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj) > { > struct drm_i915_private *dev_priv = to_i915(obj->base.dev); > + struct drm_device *dev = _priv->drm; >

Re: [Intel-gfx] [PATCH 4/5] drm/i915: pdev cleanup

On Mon, Aug 08, 2016 at 04:20:00PM +0300, David Weinehall wrote: > In an effort to simplify things for a future push of dev_priv instead > of dev wherever possible, always take pdev via dev_priv where > feasible, eliminating the direct access from dev. Right now this > only eliminates a few cases

Re: [Intel-gfx] [PATCH 3/5] drm/i915: sysfs spring cleaning

On Mon, Aug 08, 2016 at 04:19:59PM +0300, David Weinehall wrote: > -static inline struct drm_minor *kdev_to_drm_minor(struct device *kdev) > +static inline struct drm_i915_private *kdev_to_i915_dm(struct device *kdev) Grumble. What is i915_dm? minor_kdev_to_i915() kdev_minor_to_i915() The

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Consistent struct device * naming

On Mon, Aug 08, 2016 at 04:19:58PM +0300, David Weinehall wrote: > We currently have a mix of struct device *device, struct device *kdev, > and struct device *dev (the latter forcing us to refer to > struct drm_device as something else than the normal dev). > > To simplify things, always use kdev

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Cosmetic fixes in i915_drv.h

On Mon, Aug 08, 2016 at 04:19:57PM +0300, David Weinehall wrote: > Fix minor whitespace issues plus a typo in i915_drv.h. > > Signed-off-by: David Weinehall Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source

[Intel-gfx] ✗ Fi.CI.BAT: failure for Finally fix watermarks (rev7)

== Series Details == Series: Finally fix watermarks (rev7) URL : https://patchwork.freedesktop.org/series/10276/ State : failure == Summary == CC [M] drivers/net/ethernet/intel/e1000e/phy.o CC [M] drivers/net/ethernet/realtek/r8169.o CC [M] drivers/net/ethernet/intel/igb/e1000_i210.o

[Intel-gfx] ✗ Ro.CI.BAT: failure for Finally fix watermarks (rev7)

== Series Details == Series: Finally fix watermarks (rev7) URL : https://patchwork.freedesktop.org/series/10276/ State : failure == Summary == Applying: drm/i915/skl: Add support for the SAGV, fix underrun hangs Applying: drm/i915/skl: Update DDB values atomically with wms/plane attrs Using

[Intel-gfx] [PATCH v9] drm/i915/skl: Update DDB values atomically with wms/plane attrs

Now that we can hook into update_crtcs and control the order in which we update CRTCs at each modeset, we can finish the final step of fixing Skylake's watermark handling by performing DDB updates at the same time as plane updates and watermark updates. The first major change in this patch is

[Intel-gfx] [PATCH v9] drm/i915/skl: Update DDB values atomically with wms/plane attrs

Now that we can hook into update_crtcs and control the order in which we update CRTCs at each modeset, we can finish the final step of fixing Skylake's watermark handling by performing DDB updates at the same time as plane updates and watermark updates. The first major change in this patch is

[Intel-gfx] ✗ Ro.CI.BAT: failure for Various cleanup (rev2)

== Series Details == Series: Various cleanup (rev2) URL : https://patchwork.freedesktop.org/series/10458/ State : failure == Summary == Series 10458v2 Various cleanup http://patchwork.freedesktop.org/api/1.0/series/10458/revisions/2/mbox Test drv_module_reload_basic: pass

[Intel-gfx] [PATCH 1/5] drm/i915: Cosmetic fixes in i915_drv.h

Fix minor whitespace issues plus a typo in i915_drv.h. Signed-off-by: David Weinehall --- drivers/gpu/drm/i915/i915_drv.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h

[Intel-gfx] [PATCH 0/5] Various cleanup

This patch series aims to do some cleanup of our driver. Patch 1, 2, and 4 should be fairly non-controversial. Patch 3 and 5 does major cleanups of i915_sysfs and i915_debugfs, respectively. Due to the nature of these patches they are rather big, but that's mainly because they change the parameter

[Intel-gfx] [PATCH 3/5] drm/i915: sysfs spring cleaning

Pass dev_priv instead of dev to all feature macros (IS_, HAS_, INTEL_, etc.). This has the side effect that a bunch of functions now get dev_priv passed instead of dev. The main use of kdev_to_drm_minor() was as an intermediate step when extracting dev_priv, so make that helper do that bit too,

[Intel-gfx] [PATCH 5/5] drm/i915: debugfs spring cleaning

Just like with sysfs, we do some major overhaul. Pass dev_priv instead of dev to all feature macros (IS_, HAS_, INTEL_, etc.). This has the side effect that a bunch of functions now get dev_priv passed instead of dev. All calls to INTEL_INFO()->gen have been replaced with INTEL_GEN(). We want

[Intel-gfx] [PATCH 2/5] drm/i915: Consistent struct device * naming

We currently have a mix of struct device *device, struct device *kdev, and struct device *dev (the latter forcing us to refer to struct drm_device as something else than the normal dev). To simplify things, always use kdev when referring to struct device. While at it make dev_to_drm_minor() an

[Intel-gfx] [PATCH 4/5] drm/i915: pdev cleanup

In an effort to simplify things for a future push of dev_priv instead of dev wherever possible, always take pdev via dev_priv where feasible, eliminating the direct access from dev. Right now this only eliminates a few cases of dev, but it also obviates that we pass dev into a lot of functions

Re: [Intel-gfx] [PATCH] drm/i915: Shut down displays gracefully on reboot

On Mon, Aug 08, 2016 at 03:52:41PM +0300, Ville Syrjälä wrote: > On Fri, Aug 05, 2016 at 03:45:19PM -0700, Clint Taylor wrote: > > On 08/03/2016 06:36 AM, ville.syrj...@linux.intel.com wrote: > > > From: Ville Syrjälä > > > > > > Dell UP2414Q doesn't like it when

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: DP branch devices (rev7)

== Series Details == Series: drm/i915: DP branch devices (rev7) URL : https://patchwork.freedesktop.org/series/6658/ State : failure == Summary == Applying: drm: Read DP branch device HW revision fatal: sha1 information is lacking or useless (drivers/gpu/drm/drm_dp_helper.c). error: could not

[Intel-gfx] [PATCH v7 4/5] drm: Update bits per component for display info

DisplayPort branch device may define max supported bits per component. Update display info based on this value if bpc is defined. v2: cleanup to match the drm_dp_helper.c patches introduced earlier in this series v3: Fill bpc for connector's display info in separate drm_dp_helper function

[Intel-gfx] [PATCH v7 5/5] drm: Add DP branch device info on debugfs

Read DisplayPort branch device info from through debugfs interface. v2: use drm_dp_helper routines to collect data v3: cleanup to match the drm_dp_helper.c patches introduced earlier in this series v4: move DP branch device info to function 'intel_dp_branch_device_info()' v5: initial step to

[Intel-gfx] [PATCH v7 3/5] drm/i915: Check pixel rate for DP to VGA dongle

Filter out a mode that exceeds the max pixel rate setting for DP to VGA dongle. This is defined in DPCD register 0x81 if detailed cap info i.e. info field is 4 bytes long and it is available for DP downstream port. The register defines the pixel rate divided by 8 in MP/s. v2: DPCD read outs and

[Intel-gfx] [PATCH v7 0/5] drm/i915: DP branch devices

Prep work for DP branch device handling This series of patches reads DPCD register 0x80h for receiver capabilities for DP branch devices. The branch device types are converters for the following standards - DP to VGA - DP to DVI - DP to HDMI - DP++ dual mode - Wireless WiGig DPCD register

[Intel-gfx] [PATCH v7 2/5] drm: Read DP branch device SW revision

SW revision is mandatory field for DisplayPort branch devices. This is defined in DPCD register field 0x50A. v2: move drm_dp_ds_revision structure to be part of drm_dp_link structure (Daniel) Signed-off-by: Mika Kahola --- drivers/gpu/drm/drm_dp_helper.c | 27

[Intel-gfx] [PATCH v7 1/5] drm: Read DP branch device HW revision

HW revision is mandatory field for DisplayPort branch devices. This is defined in DPCD register field 0x509. v2: move drm_dp_ds_revision structure to be part of drm_dp_link structure (Daniel) Signed-off-by: Mika Kahola --- drivers/gpu/drm/drm_dp_helper.c | 27

Re: [Intel-gfx] [PATCH] drm/i915: Shut down displays gracefully on reboot

On Fri, Aug 05, 2016 at 03:45:19PM -0700, Clint Taylor wrote: > On 08/03/2016 06:36 AM, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Dell UP2414Q doesn't like it when we're driving it in MST mode, and then > > reboot the machine. After

Re: [Intel-gfx] [PATCH] drm/i915: Shut down displays gracefully on reboot

On Mon, Aug 08, 2016 at 12:47:09PM +0100, Dave Gordon wrote: > On 06/08/16 09:29, Chris Wilson wrote: > > On Sat, Aug 06, 2016 at 10:09:16AM +0200, Lukas Wunner wrote: > >> On Wed, Aug 03, 2016 at 04:36:18PM +0300, ville.syrj...@linux.intel.com > >> wrote: > >>> From: Ville Syrjälä

Re: [Intel-gfx] [PATCH] drm/i915: Shut down displays gracefully on reboot

On 06/08/16 09:29, Chris Wilson wrote: On Sat, Aug 06, 2016 at 10:09:16AM +0200, Lukas Wunner wrote: On Wed, Aug 03, 2016 at 04:36:18PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä Dell UP2414Q doesn't like it when we're driving it in MST

Re: [Intel-gfx] [PATCH 30/33] drm/i915: Record the RING_MODE register for post-mortem debugging

On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote: > Just another useful register to inspect following a GPU hang. > > Signed-off-by: Chris Wilson > --- >  drivers/gpu/drm/i915/i915_drv.h   | 1 + >  drivers/gpu/drm/i915/i915_gpu_error.c | 4 >  2 files

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Fix wait_req unreferencing.

== Series Details == Series: drm/i915: Fix wait_req unreferencing. URL : https://patchwork.freedesktop.org/series/10781/ State : failure == Summary == Applying: drm/i915: Remove early return in prepare/cleanup plane Applying: drm/i915: Drop reference to current state wait req as soon as it

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Account for TSEG size when determining 865G stolen base

== Series Details == Series: drm/i915: Account for TSEG size when determining 865G stolen base URL : https://patchwork.freedesktop.org/series/10779/ State : failure == Summary == Series 10779v1 drm/i915: Account for TSEG size when determining 865G stolen base

[Intel-gfx] [PATCH 1/2] drm/i915: Remove early return in prepare/cleanup plane

This is a noop in prepare_plane, which already carefully handles this with if guards and early return. cleanup_plane_fb has it as a noop too, it only unpins old_fb and unsets wait_req. The latter is a noop because prepare_plane won't set wait_req when obj == NULL. It's also dangerous to keep

[Intel-gfx] [PATCH 0/2] drm/i915: Fix wait_req unreferencing.

Small cleanup plus a fix for the reference dropping. This removes a source of heisenbugs. :-) Maarten Lankhorst (2): drm/i915: Remove early return in prepare/cleanup plane drm/i915: Drop reference to current state wait req as soon as it goes unused drivers/gpu/drm/i915/intel_display.c |

[Intel-gfx] [PATCH 2/2] drm/i915: Drop reference to current state wait req as soon as it goes unused

There are two paths into intel_cleanup_plane_fb, the normal completion path and the failure path. In the failure case, intel_cleanup_plane_fb is called before drm_atomic_helper_swap_state, so any wait_req reference made in intel_prepare_plane_fb will be in old_intel_state->wait_req. In the

Re: [Intel-gfx] [PATCH v5 1/4] drm/i915: Fix modeset handling during gpu reset, v5.

On Mon, Aug 08, 2016 at 11:08:33AM +0200, Maarten Lankhorst wrote: > Op 08-08-16 om 10:57 schreef Ville Syrjälä: > > On Mon, Aug 08, 2016 at 10:40:42AM +0200, Maarten Lankhorst wrote: > >> Op 08-08-16 om 10:05 schreef Ville Syrjälä: > >>> On Mon, Aug 08, 2016 at 09:52:49AM +0200, Maarten Lankhorst

Re: [Intel-gfx] [PATCH v3] drm/i915/gen9: Update i915_drpc_info debugfs for coarse pg & forcewake info

On Fri, Aug 05, 2016 at 11:24:12AM +0300, Jani Nikula wrote: > On Thu, 04 Aug 2016, David Weinehall wrote: > > On Tue, Aug 02, 2016 at 04:09:49PM +0200, Daniel Vetter wrote: > >> On Mon, Aug 01, 2016 at 11:18:15PM +0530, Kamble, Sagar A wrote: > >> > Reviewed-by:

[Intel-gfx] [PATCH] drm/i915: Account for TSEG size when determining 865G stolen base

From: Ville Syrjälä Looks like the TSEG lives just above TOUD, stolen comes after TSEG. The spec seems somewhat self-contradictory in places, in the ESMRAMC register desctription it says: TSEG Size: 10=(TOUD + 512 KB) to TOUD 11 =(TOUD + 1 MB) to TOUD so

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/33] drm/i915: Add smp_rmb() to busy ioctl's RCU dance (rev4)

== Series Details == Series: series starting with [01/33] drm/i915: Add smp_rmb() to busy ioctl's RCU dance (rev4) URL : https://patchwork.freedesktop.org/series/10770/ State : failure == Summary == CC drivers/usb/storage/usb.o LD [M] drivers/net/ethernet/intel/e1000/e1000.o CC

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Move common seqno reset to intel_engine_cs.c

On Mon, Aug 08, 2016 at 10:40:35AM +0100, Matthew Auld wrote: > In which header does the prototype for intel_engine_init_seqno now exist? Same as before, intel_ringbuffer.h. We haven't yet decided upon splitting that between engine submission and actual ring operations yet. -Chris -- Chris

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Store clipped coordinates in drm_plane_state (rev3)

== Series Details == Series: drm: Store clipped coordinates in drm_plane_state (rev3) URL : https://patchwork.freedesktop.org/series/10279/ State : failure == Summary == CC drivers/gpio/gpiolib-acpi.o CC drivers/input/mouse/alps.o CC drivers/input/mouse/focaltech.o CC

Re: [Intel-gfx] [PATCH 02/33] drm/i915: Do not overwrite the request with zero on reallocation

On Mon, Aug 08, 2016 at 11:25:56AM +0200, Daniel Vetter wrote: > On Sun, Aug 07, 2016 at 03:45:10PM +0100, Chris Wilson wrote: > > When using RCU lookup for the request, commit 0eafec6d3244 ("drm/i915: > > Enable lockless lookup of request tracking via RCU"), we acknowledge that > > we may race

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [01/33] drm/i915: Add smp_rmb() to busy ioctl's RCU dance (rev4)

== Series Details == Series: series starting with [01/33] drm/i915: Add smp_rmb() to busy ioctl's RCU dance (rev4) URL : https://patchwork.freedesktop.org/series/10770/ State : failure == Summary == Applying: drm/i915: Add smp_rmb() to busy ioctl's RCU dance Applying: drm/i915: Do not

Re: [Intel-gfx] [PATCH 01/33] drm/i915: Add smp_rmb() to busy ioctl's RCU dance

On Mon, Aug 08, 2016 at 10:30:25AM +0100, Chris Wilson wrote: > On Mon, Aug 08, 2016 at 11:12:59AM +0200, Daniel Vetter wrote: > > On Sun, Aug 07, 2016 at 03:45:09PM +0100, Chris Wilson wrote: > > > In the debate as to whether the second read of active->request is > > > ordered after the dependent

Re: [Intel-gfx] include/drm/i915_drm.h:96: possible bad bitmask ?

On Mon, Aug 08, 2016 at 10:31:32AM +0100, David Binderman wrote: > Hello there, > > Recent versions of gcc say this: > > include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’ > requires 37 bits to represent, but ‘int’ only has 32 bits > [-Wshift-overflow=] > > Source code is > >

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Move common seqno reset to intel_engine_cs.c

In which header does the prototype for intel_engine_init_seqno now exist? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 04/33] drm/i915: Use RCU to annotate and enforce protection for breadcrumb's bh

On Sun, Aug 07, 2016 at 03:45:12PM +0100, Chris Wilson wrote: > The bottom-half we use for processing the breadcrumb interrupt is a > task, which is an RCU protected struct. When accessing this struct, we > need to be holding the RCU read lock to prevent it disappearing beneath > us. We can use

[Intel-gfx] include/drm/i915_drm.h:96: possible bad bitmask ?

Hello there, Recent versions of gcc say this: include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’ requires 37 bits to represent, but ‘int’ only has 32 bits [-Wshift-overflow=] Source code is #define INTEL_BSM_MASK (0x << 20) Maybe something like #define INTEL_BSM_MASK

Re: [Intel-gfx] [PATCH 01/33] drm/i915: Add smp_rmb() to busy ioctl's RCU dance

On Mon, Aug 08, 2016 at 11:12:59AM +0200, Daniel Vetter wrote: > On Sun, Aug 07, 2016 at 03:45:09PM +0100, Chris Wilson wrote: > > In the debate as to whether the second read of active->request is > > ordered after the dependent reads of the first read of active->request, > > just give in and

Re: [Intel-gfx] [PATCH 02/33] drm/i915: Do not overwrite the request with zero on reallocation

On Sun, Aug 07, 2016 at 03:45:10PM +0100, Chris Wilson wrote: > When using RCU lookup for the request, commit 0eafec6d3244 ("drm/i915: > Enable lockless lookup of request tracking via RCU"), we acknowledge that > we may race with another thread that could have reallocated the request. > In order

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Move common scratch allocation/destroy to intel_engine_cs.c

I take it that this patch belongs in the previous series where you introduce the nullify helper? Assuming that: Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH 01/33] drm/i915: Add smp_rmb() to busy ioctl's RCU dance

On Sun, Aug 07, 2016 at 03:45:09PM +0100, Chris Wilson wrote: > In the debate as to whether the second read of active->request is > ordered after the dependent reads of the first read of active->request, > just give in and throw a smp_rmb() in there so that ordering of loads is > assured. > > v2:

Re: [Intel-gfx] [PATCH 14/33] drm/i915: Create a VMA for an object

On Mon, Aug 08, 2016 at 12:01:07PM +0300, Joonas Lahtinen wrote: > On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote: > > In many places, we wish to store the VMA in preference to the object > > itself and so being able to create the persistent VMA is useful. > > > > Signed-off-by: Chris

Re: [Intel-gfx] [PATCH 09/33] drm/i915: Mark unmappable GGTT entries as PIN_HIGH

On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote: > We allocate a few objects into the GGTT that we never need to access via > the mappable aperture (such as contexts, status pages). We can request > that these are bound high in the VM to increase the amount of mappable > aperture available.

Re: [Intel-gfx] [PATCH v5 1/4] drm/i915: Fix modeset handling during gpu reset, v5.

Op 08-08-16 om 10:57 schreef Ville Syrjälä: > On Mon, Aug 08, 2016 at 10:40:42AM +0200, Maarten Lankhorst wrote: >> Op 08-08-16 om 10:05 schreef Ville Syrjälä: >>> On Mon, Aug 08, 2016 at 09:52:49AM +0200, Maarten Lankhorst wrote: Hey, Op 05-08-16 om 22:28 schreef

Re: [Intel-gfx] [PATCH 13/33] drm/i915: Remove redundant WARN_ON from __i915_add_request()

On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote: > It's an outright programming error, so explode if it is ever hit. > > Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen > --- >  drivers/gpu/drm/i915/i915_gem_request.c |

Re: [Intel-gfx] [PATCH 14/33] drm/i915: Create a VMA for an object

On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote: > In many places, we wish to store the VMA in preference to the object > itself and so being able to create the persistent VMA is useful. > > Signed-off-by: Chris Wilson > --- >  drivers/gpu/drm/i915/i915_drv.h | 

Re: [Intel-gfx] [PATCH v5 1/4] drm/i915: Fix modeset handling during gpu reset, v5.

On Mon, Aug 08, 2016 at 10:40:42AM +0200, Maarten Lankhorst wrote: > Op 08-08-16 om 10:05 schreef Ville Syrjälä: > > On Mon, Aug 08, 2016 at 09:52:49AM +0200, Maarten Lankhorst wrote: > >> Hey, > >> > >> Op 05-08-16 om 22:28 schreef ville.syrj...@linux.intel.com: > >>> From: Maarten Lankhorst

Re: [Intel-gfx] [PATCH v5 1/4] drm/i915: Fix modeset handling during gpu reset, v5.

Op 08-08-16 om 10:05 schreef Ville Syrjälä: > On Mon, Aug 08, 2016 at 09:52:49AM +0200, Maarten Lankhorst wrote: >> Hey, >> >> Op 05-08-16 om 22:28 schreef ville.syrj...@linux.intel.com: >>> From: Maarten Lankhorst >>> >>> This function would call

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Check PSR setup time vs. vblank length

On Sat, 06 Aug 2016, Rodrigo Vivi wrote: > This patch is blocking PSR on panels that we know that our hardware support. And it also fixes a regression on Linus' laptop, and it's been merged upstream... BR, Jani. > > I wonder if: > 1. This restrictions was for older

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm: Store clipped coordinates in drm_plane_state (rev3)

== Series Details == Series: drm: Store clipped coordinates in drm_plane_state (rev3) URL : https://patchwork.freedesktop.org/series/10279/ State : failure == Summary == Applying: drm: Warn about negative sizes when calculating scale factor Applying: drm: Store clipped src/dst coordinatee in

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Sanitize drm crtc vblank counter after DC reset frame count.

On Fri, Aug 05, 2016 at 02:49:44PM -0700, Rodrigo Vivi wrote: > On Thu, Aug 4, 2016 at 1:26 AM, Daniel Vetter wrote: > > On Wed, Aug 03, 2016 at 02:33:39PM -0700, Rodrigo Vivi wrote: > >> DC state reset the frame counter that is a read-only register. > >> > >> So, besides

Re: [Intel-gfx] [PATCH v5 1/4] drm/i915: Fix modeset handling during gpu reset, v5.

On Mon, Aug 08, 2016 at 09:52:49AM +0200, Maarten Lankhorst wrote: > Hey, > > Op 05-08-16 om 22:28 schreef ville.syrj...@linux.intel.com: > > From: Maarten Lankhorst > > > > This function would call drm_modeset_lock_all, while the suspend/resume > > functions

[Intel-gfx] [PATCH 2/3] drm/i915: Move common scratch allocation/destroy to intel_engine_cs.c

Since the scratch allocation and cleanup is shared by all engine submission backends, move it out of the legacy intel_ringbuffer.c and into the new home for common routines, intel_engine_cs.c Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_engine_cs.c | 50

[Intel-gfx] [PATCH 1/3] drm/i915: Use VMA for scratch page tracking

Signed-off-by: Chris Wilson --- Accidental squashing during rebase. -Chris --- drivers/gpu/drm/i915/i915_gem_context.c | 2 +- drivers/gpu/drm/i915/i915_gpu_error.c | 2 +- drivers/gpu/drm/i915/intel_display.c| 2 +- drivers/gpu/drm/i915/intel_lrc.c|

[Intel-gfx] [PATCH 3/3] drm/i915: Move common seqno reset to intel_engine_cs.c

Since the intel_engine_init_seqno() is shared by all engine submission backends, move it out of the legacy intel_ringbuffer.c and into the new home for common routines, intel_engine_cs.c Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_engine_cs.c | 42

[Intel-gfx] Updated drm-intel-testing

Hi all, New -testing cycle with cool stuff: - refactor ddi buffer programming a bit (Ville) - large-scale renaming to untangle naming in the gem code (Chris) - rework vma/active tracking for accurately reaping idle mappings of shared objects (Chris) - misc dp sst/mst probing corner case fixes

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/2] drm/i915: Wrap the protected active RCU dereference in a helper

== Series Details == Series: series starting with [1/2] drm/i915: Wrap the protected active RCU dereference in a helper URL : https://patchwork.freedesktop.org/series/10777/ State : failure == Summary == Series 10777v1 Series without cover letter

[Intel-gfx] [PATCH v3 3/9] drm/plane-helper: Add drm_plane_helper_check_state()

From: Ville Syrjälä Add a version of drm_plane_helper_check_update() which takes a plane state instead of having the caller pass in everything. And to reduce code duplication, let's reimplement drm_plane_helper_check_update() in terms of the new function, by

Re: [Intel-gfx] [PATCH v5 1/4] drm/i915: Fix modeset handling during gpu reset, v5.

Hey, Op 05-08-16 om 22:28 schreef ville.syrj...@linux.intel.com: > From: Maarten Lankhorst > > This function would call drm_modeset_lock_all, while the suspend/resume > functions already have their own locking. Fix this by factoring out >

Re: [Intel-gfx] [PATCH v2 3/9] drm/plane-helper: Add drm_plane_helper_check_state()

On Mon, Aug 08, 2016 at 03:29:24PM +0800, Daniel Kurtz wrote: > Hi Ville, > > Two fixes inline... > > On Wed, Jul 27, 2016 at 1:34 AM, wrote: > > > > From: Ville Syrjälä > > > > Add a version of drm_plane_helper_check_update() which

  1   2   >