Re: [Intel-gfx] [PATCH] drm/i915/hdmi: Fix weak connector detection

On 5 April 2016 at 11:54, Ezequiel Garcia wrote: > (Adding Jani again, who got dropped for some reason) > > On 1 April 2016 at 16:50, Ezequiel Garcia > wrote: >> On 01 Apr 06:46 PM, Ville Syrjälä wrote: >>> On Fri, Apr 01, 2016 at

Re: [Intel-gfx] [PATCH 07/16] drm/i915/gen9: Allow skl_allocate_pipe_ddb() to operate on in-flight state

On Tue, Apr 05, 2016 at 11:35:31AM +0200, Maarten Lankhorst wrote: > Op 01-04-16 om 03:46 schreef Matt Roper: > > We eventually want to calculate watermark values at atomic 'check' time > > instead of atomic 'commit' time so that any requested configurations > > that result in impossible watermark

Re: [Intel-gfx] [PATCH 0/5] PowerManagement Toggle for PowerTOP

On Wed, 2016-04-13 at 22:46 +0200, Daniel Vetter wrote: > On Wed, Apr 13, 2016 at 10:38 PM, Vivi, Rodrigo < > rodrigo.v...@intel.com> wrote: > > On Wed, 2016-04-13 at 16:50 +0200, Daniel Vetter wrote: > > > On Wed, Apr 13, 2016 at 12:59:18PM +, Zanoni, Paulo R wrote: > > > > Em Ter, 2016-04-12

Re: [Intel-gfx] [PATCH 11/12] drm/i915: Eliminate passing dev+dev_priv to {snb, ilk}_gt_irq_handler()

On Wed, Apr 13, 2016 at 09:19:57PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > It looks silly to pass both dev and dev_priv to the snb/ilk gt irq > handlers. Just pass dev_priv. > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 4/8] drm/i915/skl+: Use scaling amount for plane data rate calculation (v3)

This commit introduced a divide-by-zero crash on plugging in an external display to the system. Below is the crash. [ 122.320882] divide error: [#1] PREEMPT SMP [ 122.320893] Modules linked in: rfcomm i2c_dev uinput snd_soc_hdac_hdmi snd_soc_dmic aesni_intel aes_x86_64

Re: [Intel-gfx] [PATCH 05/12] drm/i915: Clear VLV_IER around irq processing

On Wed, Apr 13, 2016 at 09:19:51PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > On VLV/CHV the master interrupt enable bit only affects GT/PM > interrupts. Display interrupts are not affected by the master > irq control. > > Also it seems

Re: [Intel-gfx] [PATCH 1/2] drm/i915: introduce and use i915_gem_object_map_range()

On 13/04/16 21:14, Chris Wilson wrote: On Wed, Apr 13, 2016 at 09:00:53PM +0100, Dave Gordon wrote: From: Alex Dai The recent pin-and-map unification didn't include the command parser's own custom vmapping code, which essentially duplicates the same algorithm but without

Re: [Intel-gfx] [PATCH 0/5] PowerManagement Toggle for PowerTOP

On Wed, Apr 13, 2016 at 10:46 PM, Daniel Vetter wrote: > I fully agree that we can try to do a better job on documenting this > stuff, and maybe exposing more information through stable interfaces. > > But adding new abi to enable/disable stuff sounds like jumping into > the

Re: [Intel-gfx] [PATCH 0/5] PowerManagement Toggle for PowerTOP

On Wed, Apr 13, 2016 at 10:38 PM, Vivi, Rodrigo wrote: > On Wed, 2016-04-13 at 16:50 +0200, Daniel Vetter wrote: >> On Wed, Apr 13, 2016 at 12:59:18PM +, Zanoni, Paulo R wrote: >> > Em Ter, 2016-04-12 às 12:18 -0700, Alexandra Yates escreveu: >> > > This project is

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Add sys PSR toggle interface

On Wed, 2016-04-13 at 13:26 +, Zanoni, Paulo R wrote: > Em Ter, 2016-04-12 às 12:18 -0700, Alexandra Yates escreveu: > > This interface allows an immediate enabling of PSR feature. What > > allow us > > to see immediately the PSR savings and will allow us to expose this > > through sysfs

Re: [Intel-gfx] [PATCH 0/5] PowerManagement Toggle for PowerTOP

On Wed, 2016-04-13 at 16:50 +0200, Daniel Vetter wrote: > On Wed, Apr 13, 2016 at 12:59:18PM +, Zanoni, Paulo R wrote: > > Em Ter, 2016-04-12 às 12:18 -0700, Alexandra Yates escreveu: > > > This project is explained in detail on the HAS > > >

Re: [Intel-gfx] [PATCH v4 4/6] drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission

On 04/13/2016 12:46 PM, Dave Gordon wrote: On 13/04/16 18:50, Yu Dai wrote: > > > On 04/07/2016 10:21 AM, Dave Gordon wrote: >> During a hibernate/resume cycle, the whole system is reset, including >> the GuC and the doorbell hardware. Then the system is booted up, drivers >> are loaded, etc

Re: [Intel-gfx] [PATCH 1/2] drm/i915: introduce and use i915_gem_object_map_range()

On Wed, Apr 13, 2016 at 09:00:53PM +0100, Dave Gordon wrote: > From: Alex Dai > > The recent pin-and-map unification didn't include the command parser's > own custom vmapping code, which essentially duplicates the same > algorithm but without some of the optimisations. No.

[Intel-gfx] [PATCH 1/2] drm/i915: introduce and use i915_gem_object_map_range()

From: Alex Dai The recent pin-and-map unification didn't include the command parser's own custom vmapping code, which essentially duplicates the same algorithm but without some of the optimisations. To unify this further, this patch puts the mapping/unmapping operations from

[Intel-gfx] [PATCH 2/2] drm/i915: optimise i915_gem_object_map_range() for small objects

We're using this function for ringbuffers and other "small" objects, so it's worth avoiding an extra malloc()/free() cycle if the page array is small enough to put on the stack. Here we've chosen an arbitrary cutoff of 32 (4k) pages, which is big enough for a ringbuffer (4 pages) or a context

Re: [Intel-gfx] [PATCH v4 4/6] drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission

On 13/04/16 18:50, Yu Dai wrote: On 04/07/2016 10:21 AM, Dave Gordon wrote: During a hibernate/resume cycle, the whole system is reset, including the GuC and the doorbell hardware. Then the system is booted up, drivers are loaded, etc -- the GuC firmware may be loaded and set running at this

[Intel-gfx] [PATCH 4/4] drm/i915/fbc: enable FBC on gen 9+ too

Now that we're more protected against user space doing frontbuffer mmap rendering, the last - how many times did I say this before? - SKL problem seems to be solved. So let's give it a try. And since the other newer platforms are still under preliminary support, let's enable FBC on them too to

[Intel-gfx] [PATCH 2/4] drm/i915/fbc: sanitize i915.enable_fbc during FBC init

The DDX driver changes its behavior depending on the value it reads from i915.enable_fbc, so sanitize the value in order to allow it to know what's going on. It uses this in order to choose the defaults for the TearFree option. Before this patch, it would read -1 and always assume that FBC was

Re: [Intel-gfx] [PATCH] drm/i915: Get audio power domain during initial hw readout

On Wed, Apr 13, 2016 at 11:19:20AM -0700, Bob Paauwe wrote: > On Wed, 13 Apr 2016 11:59:43 +0300 > Ville Syrjälä wrote: > > > On Tue, Apr 12, 2016 at 03:52:48PM -0700, Bob Paauwe wrote: > > > if the crtc has audio is enabled. Otherwise, when the first atomic > > >

[Intel-gfx] [PATCH 11/12] drm/i915: Eliminate passing dev+dev_priv to {snb, ilk}_gt_irq_handler()

From: Ville Syrjälä It looks silly to pass both dev and dev_priv to the snb/ilk gt irq handlers. Just pass dev_priv. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_irq.c | 27 --- 1 file changed,

[Intel-gfx] [PATCH 09/12] drm/i915: Split VLV/CVH PIPESTAT handling into ack+handler

From: Ville Syrjälä Minimize the amount of stuff we do with interrupt sources disabled by splitting the PIPESTAT irq handling into ack+handler phases. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_irq.c | 21

[Intel-gfx] [PATCH 10/12] drm/i915: Move gt/pm irq handling out from irq disabled section on VLV

From: Ville Syrjälä No need to actually handle the GT/PM interrupt while we have interrupt sources disabled. Move the actual processing to happen after we've restored VLV_IER and master interrupt enable. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 08/12] drm/i915: Split PORT_HOTPLUG_STAT ack out from i9xx_hpd_irq_handler()

From: Ville Syrjälä Split the VLV/CHV hoplug irq handling to ack and handler phases. This way we can move the actual irq handling outside the section where we have disabled the interrupt sources. For now, we leave things as is for pre-VLV GMCH platforms, but

[Intel-gfx] [PATCH 02/12] drm/i915: Set up VLV_MASTER_IER consistently

From: Ville Syrjälä We're lacking VLV_MASTER_IER setup from valleyview_irq_preinstall(), so add it there. Also cargo cult in some POSTING_READ()s to match the other platforms. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 05/12] drm/i915: Clear VLV_IER around irq processing

From: Ville Syrjälä On VLV/CHV the master interrupt enable bit only affects GT/PM interrupts. Display interrupts are not affected by the master irq control. Also it seems that the CPU interrupt will only be generated when the combined result of all GT/PM/display

[Intel-gfx] [PATCH 03/12] drm/i915: Clear VLV_IIR after PIPESTAT

From: Ville Syrjälä On VLV/CHV VLV_IIR is not double double buffered, and it doesn't detect edges from PIPESTAT & co. like it does on gen4. Instead it just directly latches the level from PIPESTAT & co. That means we must clear VLV_IIR after PIPESTAT & co. or else

[Intel-gfx] [PATCH 12/12] drm/i915: Split gen8_gt_irq_handler into ack+handle

From: Ville Syrjälä As we did on VLV, split the gt irq handling to ack and handler phases on CHV. Leave the BDW+ codepath mostly intact for now. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_irq.c | 79

[Intel-gfx] [PATCH 01/12] drm/i915: Use GEN8_MASTER_IRQ_CONTROL consistently

From: Ville Syrjälä Use GEN8_MASTER_IRQ_CONTROL instead of DE_MASTER_IRQ_CONTROL or MASTER_INTERRUPT_ENABLE with the GEN8_MASTER_IRQ register. They're all bit 31 so there's no actual bug here, but let's be consistent which name we use for the bit. Signed-off-by:

[Intel-gfx] [PATCH 04/12] drm/i915: Clear VLV_MASTER_IER around irq processing

From: Ville Syrjälä Like on CHV, let's clear out the master irq enable bit when we ack GT/PM interrupts. This will allow GT/PM interrupts to re-raise the CPU interrupt if we fail to clear all the bits from the IIR(s). Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 07/12] drm/i915: Move variables to narrower scope in VLV/CHV irq handlers

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_irq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index

[Intel-gfx] [PATCH 00/12] drm/i915: VLV/CHV irq handler fixes

From: Ville Syrjälä The main motivation here is to fix CHV irq handling which got a bit broken by the removal of the loop. The loop is still gone after I'm done, and I also killed the loop from the VLV code. That's roughly the first half of the series. The second

Re: [Intel-gfx] [PATCH] drm/i915: Get audio power domain during initial hw readout

On Wed, 13 Apr 2016 11:59:43 +0300 Ville Syrjälä wrote: > On Tue, Apr 12, 2016 at 03:52:48PM -0700, Bob Paauwe wrote: > > if the crtc has audio is enabled. Otherwise, when the first atomic > > modeset happens it will warn when trying to drop the audio power > >

[Intel-gfx] [PATCH] drm/i915: Ignore GTFIFODBG FIFO free entry fields on CHV

From: Ville Syrjälä On CHV GTFIFODBG has some read-only bits to indicate the number of free FIFO entries. Ignore these when checking to see if any of the sticky error bits are set. This gets rid of these during device resume: [drm:cherryview_enable_rps] GT fifo

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dp/mst: Fix MST logic in intel_dp_long_pulse() (rev3)

On Tue, Apr 12, 2016 at 07:39:35AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915/dp/mst: Fix MST logic in intel_dp_long_pulse() (rev3) > URL : https://patchwork.freedesktop.org/series/5390/ > State : failure > > == Summary == > > Series 5390v3 drm/i915/dp/mst: Fix MST

[Intel-gfx] [PATCH 1/1] change the order to cleanup drm_property_blob after drm_crtc

From: "Xiong, James" Previously drm_mode_config_cleanup freed drm_property_blob first, then the drm_crtc which triggered unref calls to its associated drm_propery_blob, and could potentially cause memory corruption. Signed-off-by: Xiong, James ---

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Rework page flip to be more atomic like, and remove cs flips.

== Series Details == Series: drm/i915: Rework page flip to be more atomic like, and remove cs flips. URL : https://patchwork.freedesktop.org/series/5647/ State : failure == Summary == Series 5647v1 drm/i915: Rework page flip to be more atomic like, and remove cs flips.

Re: [Intel-gfx] [PATCH v4 2/6] drm/i915/guc: move guc_ring_doorbell() nearer to callsite

LGTM. Reviewed-by: Alex Dai On 04/07/2016 10:21 AM, Dave Gordon wrote: Just code movement, no actual change to the function. This is in preparation for the next patch, which will reorganise all the other doorbell code, but doesn't change this function. So let's shuffle it

Re: [Intel-gfx] [PATCH v4 1/6] drm/i915/guc: add doorbell map to debugfs/i915_guc_info

LGTM. Reviewed-by: Alex Dai On 04/07/2016 10:21 AM, Dave Gordon wrote: To properly verify the driver->doorbell->GuC functionality, validation needs to know how the driver has assigned the doorbell cache lines and registers, so make them visible through debugfs.

Re: [Intel-gfx] [PATCH v4 5/6] drm/i915/guc: disable GuC submission earlier during GuC (re)load

LGTM. Reviewed-by: Alex Dai On 04/07/2016 10:21 AM, Dave Gordon wrote: When resetting and reloading the GuC, the GuC submission management code also needs to destroy and recreate the GuC client(s). Currently this is done by a separate call from the GuC loader, but really,

Re: [Intel-gfx] [PATCH v4 4/6] drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission

On 04/07/2016 10:21 AM, Dave Gordon wrote: During a hibernate/resume cycle, the whole system is reset, including the GuC and the doorbell hardware. Then the system is booted up, drivers are loaded, etc -- the GuC firmware may be loaded and set running at this point. But then, the booted kernel

[Intel-gfx] [PATCH v2 10/10] drm/i915: Move VLV HDMI lane reset work around logic to intel_dpio_phy.c

This moves the last dpio phy specific code from the encoders to the phy specific file. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_dpio_phy.c | 15 +++

Re: [Intel-gfx] [PATCH] drm/i915: Provide a modparam to disable firmware loading

On Wed, Apr 13, 2016 at 06:45:32PM +0100, Dave Gordon wrote: > On 13/04/16 17:57, Ben Widawsky wrote: > > For debug and development purposes only. > > > > Cc: Mika Kuoppala > > Signed-off-by: Ben Widawsky > > --- > >

[Intel-gfx] [PATCH v2 05/10] drm/i915: Unduplicate CHV pre-encoder enabling phy logic

The only difference between the DP and HDMI versions was the lane count. Since lane_count is now set appropriately for HDMI too, get rid of the duplication and move this to intel_dpio_phy.c v2: Don't move comments about 2nd common lane staying alive. (Ville) Signed-off-by: Ander Conselvan de

[Intel-gfx] [PATCH v2 08/10] drm/i915: Unduplicate VLV phy pre pll enabling code

The code used by the DP and HDMI paths was very similar, so make them share it. Note that this removes the write to signal level registers from the HDMI pre pll enable path, but that's OK since those are set in vlv_hdmi_pre_enable() function. Signed-off-by: Ander Conselvan de Oliveira

[Intel-gfx] [PATCH v2 06/10] drm/i915: Undiplicate CHV encoders' post pll disable code

The exact same code was used by HDMI and DP encoders, so move it to intel_dpio_phy.c. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_dp.c | 30 +-

[Intel-gfx] [PATCH v2 07/10] drm/i915: Undiplicate VLV signal level code

The logic for setting signal levels is used for both HDMI and DP with small variations. But it is similar enough to put behind a function called from the encoders. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/i915_drv.h | 4

[Intel-gfx] [PATCH v2 09/10] drm/i915: Unduplicate pre encoder enabling phy code

The phy code in vlv_pre_enable_dp() and vlv_hdmi_pre_enable() is exectly the same, so extract it to intel_dpio_phy.c. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_dp.c | 24

[Intel-gfx] [PATCH v2 04/10] drm/i915: Unduplicate CHV phy-releated pre pll enabling code

The same logic is used for DP and HDMI so move it to intel_dpio_phy.c. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_dp.c | 83 +--

[Intel-gfx] [PATCH v2 01/10] drm/i915: Set crtc_state->lane_count for HDMI

Set the lane count for HDMI to 4. This will make it easier to unduplicate CHV phy code. v2: Set lane_count in *_get_config() to please state checker. (0day) v3: Set lane_count for DDI in DVI mode too. (CI) Signed-off-by: Ander Conselvan de Oliveira ---

[Intel-gfx] [PATCH v2 03/10] drm/i915: Unduplicate chv_data_lane_soft_reset()

The function chv_data_lane_soft_reset() was duplicated in DP and HDMI code. Move it to intel_dpio_phy.c. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/intel_dp.c | 44

[Intel-gfx] [PATCH v2 02/10] drm/i915: Unduplicate CHV signal level code

The code for programming voltage swing and emphasis was duplicated between DP and HDMI code. Move that to a new file, intel_dpio_phy.c. v2: Keep the "Use 800mV-0dB" comment in the HDMI code. (Ville) Signed-off-by: Ander Conselvan de Oliveira ---

[Intel-gfx] [PATCH v2 00/10] Unduplicate CHV phy code

Hi, Here's an updated series with comments addressed. It alsos gives VLV code the same treatment. Thanks, Ander Cc: Ville Syrjälä Ander Conselvan de Oliveira (10): drm/i915: Set crtc_state->lane_count for HDMI drm/i915: Unduplicate CHV signal level code

Re: [Intel-gfx] [PATCH] drm/i915: Provide a modparam to disable firmware loading

On 13/04/16 17:57, Ben Widawsky wrote: For debug and development purposes only. Cc: Mika Kuoppala Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_debugfs.c | 13 + drivers/gpu/drm/i915/i915_gpu_error.c | 3 +++

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix eDP low vswing for Broadwell (rev3)

== Series Details == Series: drm/i915: Fix eDP low vswing for Broadwell (rev3) URL : https://patchwork.freedesktop.org/series/4499/ State : failure == Summary == CC drivers/usb/host/xhci-trace.o CC drivers/usb/storage/usual-tables.o CC drivers/usb/host/xhci-pci.o CONMK

[Intel-gfx] [PATCH] drm/i915: Provide a modparam to disable firmware loading

For debug and development purposes only. Cc: Mika Kuoppala Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_debugfs.c | 13 + drivers/gpu/drm/i915/i915_gpu_error.c | 3 +++ drivers/gpu/drm/i915/i915_params.c | 6

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [RESEND,FOR,CI,1/2] drm/i915/dp/mst: Fix MST logic in intel_dp_long_pulse()

== Series Details == Series: series starting with [RESEND,FOR,CI,1/2] drm/i915/dp/mst: Fix MST logic in intel_dp_long_pulse() URL : https://patchwork.freedesktop.org/series/5642/ State : failure == Summary == Series 5642v1 Series without cover letter

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Rest of my DSI and DPLL stuff

On Wed, Apr 13, 2016 at 04:02:17PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Rest of my DSI and DPLL stuff > URL : https://patchwork.freedesktop.org/series/5610/ > State : failure > > == Summary == > > Series 5610v1 drm/i915: Rest of my DSI and DPLL stuff >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Get audio power domain during initial hw readout

== Series Details == Series: drm/i915: Get audio power domain during initial hw readout URL : https://patchwork.freedesktop.org/series/5622/ State : failure == Summary == Series 5622v1 drm/i915: Get audio power domain during initial hw readout

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Rest of my DSI and DPLL stuff

== Series Details == Series: drm/i915: Rest of my DSI and DPLL stuff URL : https://patchwork.freedesktop.org/series/5610/ State : failure == Summary == Series 5610v1 drm/i915: Rest of my DSI and DPLL stuff http://patchwork.freedesktop.org/api/1.0/series/5610/revisions/1/mbox/ Test

[Intel-gfx] [PATCH] drm/i915/skl: Update eDRAM calculation

The two behavioral changes here are the correct detection of the eDRAM size on gen9 (SKL + KBL), and unconditional printing of the eLLC size. Cc: Eero Tamminen Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/intel_uncore.c | 16

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Add sys PSR toggle interface

== Series Details == Series: series starting with [1/5] drm/i915: Add sys PSR toggle interface URL : https://patchwork.freedesktop.org/series/5609/ State : failure == Summary == Series 5609v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/5609/revisions/1/mbox/

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Reorganise legacy context switch to cope with late failure

On Wed, Apr 13, 2016 at 05:05:05PM +0200, Daniel Vetter wrote: > > static bool > > -needs_pd_load_post(struct intel_engine_cs *engine, struct intel_context > > *to, > > - u32 hw_flags) > > +needs_pd_load_post(struct intel_context *to, u32 hw_flags) > > { > > - struct

Re: [Intel-gfx] [PATCH] drm/i915: Move ioremap_wc tracking onto VMA

On Wed, Apr 13, 2016 at 03:47:58PM +0100, Chris Wilson wrote: > + /* We also want to clear any cached iomaps as they wrap vmap */ > + list_for_each_entry_safe(vma, next, > + _priv->ggtt.base.inactive_list, vm_link) > + if (vma->iomap &&

Re: [Intel-gfx] [PATCH] drm/i915: Move ioremap_wc tracking onto VMA

Hi Chris, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20160413] [cannot apply to v4.6-rc3] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Chris-Wilson

[Intel-gfx] [PATCH v5 2/4] drm/dp_helper: Retry aux transactions on all errors

This is part of a patch series to migrate all of the workarounds for commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to drm's DP helper. We cannot rely on sinks NACKing or deferring when they can't receive transactions, nor can we rely on any other sort of consistent error to

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Reorganise legacy context switch to cope with late failure

hw_flags) > return ret; > } > > -static inline bool skip_rcs_switch(struct intel_engine_cs *engine, > -struct intel_context *from, > +static inline bool skip_rcs_switch(struct intel_context *from, > struct intel_context *to)

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Split out !RCS legacy context switching

On Wed, Apr 13, 2016 at 04:56:05PM +0200, Daniel Vetter wrote: > On Wed, Apr 13, 2016 at 03:16:30PM +0100, Chris Wilson wrote: > > + if (needs_pd_load_pre(engine, to)) { > > Hm, I'd inline this condition now since it's a bit confusing if there's no > POST. Assuming I read code correctly

[Intel-gfx] [PATCH v5 1/4] drm/dp_helper: Always wait before retrying native aux transactions

This is part of a patch series to migrate all of the workarounds for commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to drm's DP helper. Some sinks need some time during the process of resuming the system from sleep before they're ready to handle transactions. While it would be

[Intel-gfx] [PATCH v5 3/4] drm/dp_helper: Perform throw-away read before actual read in drm_dp_dpcd_read()

This is part of a patch series to migrate all of the workarounds for commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to drm's DP helper. Some sinks will just return garbage for the first aux tranaction they receive when coming out of sleep mode, so we need to perform an

[Intel-gfx] [PATCH v5 4/4] drm/i915: Get rid of intel_dp_dpcd_read_wake()

Since we've fixed up drm_dp_dpcd_read() to allow for retries when things timeout, there's no use for having this function anymore. Good riddens. Signed-off-by: Lyude --- drivers/gpu/drm/i915/intel_dp.c | 81 - 1 file changed, 23

[Intel-gfx] [PATCH v5 0/4] Move workarounds from intel_dp_dpcd_read_wake() into drm's DP helpers

Rebased the patches to apply against drm-intel-nightly Lyude (4): drm/dp_helper: Always wait before retrying native aux transactions drm/dp_helper: Retry aux transactions on all errors drm/dp_helper: Perform throw-away read before actual read in drm_dp_dpcd_read() drm/i915: Get rid of

[Intel-gfx] ✗ Fi.CI.BAT: failure for Gen8 Execlist based Engine reset and recovery support

== Series Details == Series: Gen8 Execlist based Engine reset and recovery support URL : https://patchwork.freedesktop.org/series/5603/ State : failure == Summary == Series 5603v1 Gen8 Execlist based Engine reset and recovery support

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Split out !RCS legacy context switching

On Wed, Apr 13, 2016 at 03:16:30PM +0100, Chris Wilson wrote: > Having the !RCS legacy context switch threaded through the RCS switching > code makes it much harder to follow and understand. In the next patch, I > want to fix a bug handling the incomplete switch, this is made much > simpler if we

Re: [Intel-gfx] [PATCH 0/5] PowerManagement Toggle for PowerTOP

On Wed, Apr 13, 2016 at 12:59:18PM +, Zanoni, Paulo R wrote: > Em Ter, 2016-04-12 às 12:18 -0700, Alexandra Yates escreveu: > > This project is explained in detail on the HAS > > https://docs.google.com/a/intel.com/document/d/1E-en_xqfHgCnhD1Tes3f0 > > 8UYrOc-etv2W-pU0ZErKdE/edit?usp=sharing  

[Intel-gfx] [PATCH] drm/i915: Move ioremap_wc tracking onto VMA

By tracking the iomapping on the VMA itself, we can share that area between multiple users. Also by only revoking the iomapping upon unbinding from the mappable portion of the GGTT, we can keep that iomap across multiple invocations (e.g. execlists context pinning). Note that by moving the

Re: [Intel-gfx] [PATCH 2/2] drm/i915/BXT: Tolerance at BXT DSI pipe_config comparison

On Wed, Apr 13, 2016 at 06:34:25PM +0530, Ramalingam C wrote: > > On Wednesday 13 April 2016 05:27 PM, Daniel Vetter wrote: > >On Wed, Apr 13, 2016 at 1:48 PM, Daniel Vetter wrote: > >>On Wed, Apr 13, 2016 at 1:06 PM, Jani Nikula wrote: > Then fix

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: use dev_priv directly in gen8_ppgtt_notify_vgt

== Series Details == Series: series starting with [1/5] drm/i915: use dev_priv directly in gen8_ppgtt_notify_vgt URL : https://patchwork.freedesktop.org/series/5601/ State : failure == Summary == Series 5601v1 Series without cover letter

[Intel-gfx] [CI-RUN PATCH 0/3] ci-run of edram size patches

Mika Kuoppala (3): drm/i915: Don't program eLLC IDI hash mask for gen9+ drm/i915: Store and use edram capabilities drm/i915: Calculate edram size drivers/gpu/drm/i915/i915_debugfs.c | 5 ++-- drivers/gpu/drm/i915/i915_drv.h | 7 +++-- drivers/gpu/drm/i915/i915_gem.c | 2 +-

[Intel-gfx] [PATCH 1/3] drm/i915: Don't program eLLC IDI hash mask for gen9+

For gen9 onwards, eDRAM is a true memory side cache. So there is no need to program idi hash mask as it is for eLLC only. v2: INTEL_GEN (Chris), s/has/hash (Matthew) Signed-off-by: Mika Kuoppala Reviewed-by: Matthew Auld ---

[Intel-gfx] [PATCH 2/3] drm/i915: Store and use edram capabilities

Store the edram capabilities instead of only the size of edram. This is preparatory patch to allow edram size calculation based on edram capability bits for gen9+. With gen9 the edram is behind llc and is a separate entity. With hsw/bdw it was more of a victim cache for LLC so the name 'eLLC'

[Intel-gfx] [PATCH 3/3] drm/i915: Calculate edram size

With gen9+ the edram capabilities are defined so that we can calculate the edram (ellc) size accordingly. Note that there are undefined combinations for some subset of edram capability bits. Return the closest size for undefined indexes. Even if we get it wrong with beginning of future gen

Re: [Intel-gfx] [CI-ping 15/15] drm/i915: Late request cancellations are harmful

On 13/04/2016 10:57, Daniel Vetter wrote: On Tue, Apr 12, 2016 at 09:03:09PM +0100, Chris Wilson wrote: Conceptually, each request is a record of a hardware transaction - we build up a list of pending commands and then either commit them to hardware, or cancel them. However, whilst building up

[Intel-gfx] [PATCH 2/2] drm/i915: Reorganise legacy context switch to cope with late failure

After mi_set_context() succeeds, we need to update the state of the engine's last_context. This ensures that we hold a pin on the context whilst the hardware may write to it. However, since we didn't complete the post-switch setup of the context, we need to force the subsequent use of the same

[Intel-gfx] [PATCH 1/2] drm/i915: Split out !RCS legacy context switching

Having the !RCS legacy context switch threaded through the RCS switching code makes it much harder to follow and understand. In the next patch, I want to fix a bug handling the incomplete switch, this is made much simpler if we segregate the two paths now. Signed-off-by: Chris Wilson

[Intel-gfx] [for-CI-v2] drm/i915/mocs: Program MOCS for all engines on init

From: Peter Antoine Allow for the MOCS to be programmed for all engines. Currently we program the MOCS when the first render batch goes through. This works on most platforms but fails on platforms that do not run a render batch early, i.e. headless servers. The patch now

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add rpm get/put in i915_shrinker_oom

On Wed, Apr 13, 2016 at 04:54:07PM +0300, Mika Kuoppala wrote: > From: Praveen Paneri > > i915_gem_shrink_all() will scan the bound list only if device is not > suspended but in OOM scenarios it becomes absolutely necessary to > release as much memory as possible. So,

Re: [Intel-gfx] [PATCH v2 0/6] HPD support during suspend.

On 4/13/2016 7:17 PM, Animesh Manna wrote: On 4/8/2016 2:35 AM, Imre Deak wrote: On Thu, 2016-04-07 at 20:22 +0530, Animesh Manna wrote: Along with below patches sharing some background details/design. - On BXT, Display cannot generate an interrupt when in D3. - Without display in D3, S0ix

Re: [Intel-gfx] [PATCH v2 0/6] HPD support during suspend.

On 4/8/2016 2:35 AM, Imre Deak wrote: On Thu, 2016-04-07 at 20:22 +0530, Animesh Manna wrote: Along with below patches sharing some background details/design. - On BXT, Display cannot generate an interrupt when in D3. - Without display in D3, S0ix can be achieved, Power impact will be zero if

[Intel-gfx] [CI-RUN PATCH 0/2] ci-run of shrinker rpm fixes

Praveen Paneri (2): drm/i915: Unbind objects in shrinker only if device is runtime active drm/i915: Add rpm get/put in i915_shrinker_oom drivers/gpu/drm/i915/i915_gem_shrinker.c | 14 ++ 1 file changed, 14 insertions(+) -- 2.5.0

[Intel-gfx] [PATCH 2/2] drm/i915: Add rpm get/put in i915_shrinker_oom

From: Praveen Paneri i915_gem_shrink_all() will scan the bound list only if device is not suspended but in OOM scenarios it becomes absolutely necessary to release as much memory as possible. So, adding rpm get/put in i915_shrinker_oom() to ensure shrinking of bound

[Intel-gfx] [PATCH 1/2] drm/i915: Unbind objects in shrinker only if device is runtime active

From: Praveen Paneri When the system is running low on memory, gem shrinker is invoked. In this process objects will be unbounded from GTT and unbinding process will require access to GTT(GTTADR) and also to fence register potentially. That requires a resume of gfx

Re: [Intel-gfx] [PATCH v4] drm/i915/mocs: Program MOCS for all engines on init

On Tue, Apr 12, 2016 at 12:52:24PM +0100, Peter Antoine wrote: > Chris, > > If the test is ok, can you review-by this patch. Yup, my box decided that was good time to suffer fs corruption. Patched up and resent for CI with my r-b. -Chris -- Chris Wilson, Intel Open Source Technology Centre

[Intel-gfx] [for-CI] drm/i915/mocs: Program MOCS for all engines on init

From: Peter Antoine Allow for the MOCS to be programmed for all engines. Currently we program the MOCS when the first render batch goes through. This works on most platforms but fails on platforms that do not run a render batch early, i.e. headless servers. The patch now

[Intel-gfx] [for-CI] no-used-pml4

--- drivers/gpu/drm/i915/i915_gem_gtt.c | 47 + drivers/gpu/drm/i915/i915_gem_gtt.h | 2 -- 2 files changed, 16 insertions(+), 33 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Add sys PSR toggle interface

Em Ter, 2016-04-12 às 12:18 -0700, Alexandra Yates escreveu: > This interface allows an immediate enabling of PSR feature. What > allow us > to see immediately the PSR savings and will allow us to expose this > through sysfs interface for powertop to leverage its functionality. > > Signed-off-by:

Re: [Intel-gfx] [PATCH 2/2] drm/i915/BXT: Tolerance at BXT DSI pipe_config comparison

On Wednesday 13 April 2016 05:27 PM, Daniel Vetter wrote: On Wed, Apr 13, 2016 at 1:48 PM, Daniel Vetter wrote: On Wed, Apr 13, 2016 at 1:06 PM, Jani Nikula wrote: Then fix adjusted_mode to have the timings in terms of txbyteclkhs already. Problem

Re: [Intel-gfx] [PATCH] drm/i915/opregion: remove unnecessary ifdefs on CONFIG_ACPI

On Tue, 12 Apr 2016, Jani Nikula wrote: > On Tue, 12 Apr 2016, Chris Wilson wrote: >> On Fri, Apr 08, 2016 at 05:59:49PM +0300, Jani Nikula wrote: >>> The whole file is ignored on CONFIG_ACPI=n. >> >> That's an issue as we can't then acquire the

Re: [Intel-gfx] [PATCH 0/5] PowerManagement Toggle for PowerTOP

Em Ter, 2016-04-12 às 12:18 -0700, Alexandra Yates escreveu: > This project is explained in detail on the HAS > https://docs.google.com/a/intel.com/document/d/1E-en_xqfHgCnhD1Tes3f0 > 8UYrOc-etv2W-pU0ZErKdE/edit?usp=sharing   > > Summary:  > Permits the user to identify and toggle values for PSR,

Re: [Intel-gfx] [PATCH v4] drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write

Abdiel Janulgue writes: > [ text/plain ] > > > On 04/12/2016 04:51 PM, Michał Winiarski wrote: >> We started to use PIPE_CONTROL to write render ring seqno in order to >> combat seqno write vs interrupt generation problems. This was introduced >> by commit

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Add sys FBC toggle interface

Em Ter, 2016-04-12 às 12:18 -0700, Alexandra Yates escreveu: > This interface allows an immediate enabling of FBC feature. What > allow us > to see immediately the FBC There's no way to guarantee the user will immediately see any FBC savings. FBC depends on a lot of conditions (e.g., X tiling,

  1   2   >