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

if the crtc has audio is enabled. Otherwise, when the first atomic modeset happens it will warn when trying to drop the audio power domain. Signed-off-by: Bob Paauwe --- drivers/gpu/drm/i915/intel_display.c | 5 + 1 file changed, 5 insertions(+) diff --git

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] [CI-ping 12/15] drm/i915: Force ringbuffers to not be at offset 0

For reasons unknown Sandybridge GT1 (at least) will eventually hang when it encounters a ring wraparound at offset 0. The test case that reproduces the bug reliably forces a large number of interrupted context switches, thereby causing very frequent ring wraparounds, but there are similar bug

[Intel-gfx] [CI-ping 09/15] drm/i915: Prevent leaking of -EIO from i915_wait_request()

Reporting -EIO from i915_wait_request() has proven very troublematic over the years, with numerous hard-to-reproduce bugs cropping up in the corner case of where a reset occurs and the code wasn't expecting such an error. If the we reset the GPU or have detected a hang and wish to reset the GPU,

[Intel-gfx] [CI-ping 10/15] drm/i915: Suppress error message when GPU resets are disabled

If we do not have lowlevel support for reseting the GPU, or if the user has explicitly disabled reseting the device, the failure is expected. Since it is an expected failure, we should be using a lower priority message than *ERROR*, perhaps NOTICE. In the absence of DRM_NOTICE, just emit the

Re: [Intel-gfx] [PATCH v2] drm/i915/dp/mst: Fix MST logic in intel_dp_long_pulse()

I'm going to take back the NAK on this, apparently this hotplugging issue has been around longer then this patchset. Reviewed-by: Lyude On Tue, 2016-04-12 at 10:11 +0300, Ander Conselvan De Oliveira wrote: > On Mon, 2016-04-11 at 10:11 -0700, Jim Bride wrote: > > > > In

[Intel-gfx] [CI-ping 08/15] drm/i915: Simplify reset_counter handling during atomic modesetting

Now that the reset_counter is stored on the request, we can rearrange the code to handle reading the counter versus waiting during the atomic modesetting for readibility (by deleting the hairiest of codes). Signed-off-by: Chris Wilson Cc: Daniel Vetter

[Intel-gfx] [CI-ping 11/15] drm/i915: Prevent machine death on Ivybridge context switching

Two concurrent writes into the same register cacheline has the chance of killing the machine on Ivybridge and other gen7. This includes LRI emitted from the command parser. The MI_SET_CONTEXT itself serves as serialising barrier and prevents the pair of register writes in the first packet from

[Intel-gfx] [CI-ping 01/15] drm/i915: Force clean compilation with -Werror

Our driver compiles clean (nowadays thanks to 0day) but for me, at least, it would be beneficial if the compiler threw an error rather than a warning when it found a piece of suspect code. (I use this to compile-check patch series and want to break on the first compiler error in order to fix the

[Intel-gfx] [CI-ping 07/15] drm/i915: Store the reset counter when constructing a request

As the request is only valid during the same global reset epoch, we can record the current reset_counter when constructing the request and reuse it when waiting upon that request in future. This removes a very hairy atomic check serialised by the struct_mutex at the time of waiting and allows us

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

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 the list of pending commands, we may modify state outside of the request and make references to the pending

[Intel-gfx] [CI-ping 05/15] drm/i915: Simplify checking of GPU reset_counter in display pageflips

If we, when we store the reset_counter for the operation, we ensure that it is not in a wedged or in the middle of a reset, we can then assert that if any reset occurs the reset_counter must change. Later we can just compare the operation's reset epoch against the current counter to see if we need

[Intel-gfx] [CI-ping 06/15] drm/i915: Tighten reset_counter for reset status

In the reset_counter, we use two bits to track a GPU hang and reset. The low bit is a "reset-in-progress" flag that we set to signal when we need to break waiters in order for the recovery task to grab the mutex. As soon as the recovery task has the mutex, we can clear that flag (which we do by

[Intel-gfx] [CI-ping 02/15] drm/i915: Disentangle i915_drv.h includes

Separate out the layers of includes (linux, drm, intel, i915) so that it is a little easier to order our definitions between our multiple reentrant headers. A couple of headers needed fixes to make them more standalone (forgotten includes, forward declarations etc). Signed-off-by: Chris Wilson

[Intel-gfx] [CI-ping 13/15] drm/i915: Move the mb() following release-mmap into release-mmap

As paranoia, we want to ensure that the CPU's PTEs have been revoked for the object before we return from i915_gem_release_mmap(). This allows us to rely on there being no outstanding memory accesses and guarantees serialisation of the code against concurrent access just by calling

[Intel-gfx] [CI-ping 03/15] drm/i915: Add GEM debugging Kconfig option

Currently there is a #define to enable extra BUG_ON for debugging requests and associated activities. I want to expand its use to cover all of GEM internals (so that we can saturate the code with asserts). We can add a Kconfig option to make it easier to enable - with the usual caveats of not

[Intel-gfx] [CI-ping 04/15] drm/i915: Hide the atomic_read(reset_counter) behind a helper

This is principally a little bit of syntatic sugar to hide the atomic_read()s throughout the code to retrieve the current reset_counter. It also provides the other utility functions to check the reset state on the already read reset_counter, so that (in later patches) we can read it once and do

[Intel-gfx] [CI-ping 14/15] 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

Re: [Intel-gfx] [PATCH 10/10] Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"

On Tue, Apr 12, 2016 at 08:08:01PM +0300, Ville Syrjälä wrote: > On Tue, Apr 12, 2016 at 03:04:10PM +0300, Imre Deak wrote: > > On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote: > > > From: Ville Syrjälä > > > > > > Enable the unclaimd register

[Intel-gfx] [PATCH 5/5] drm/i915: Reject 'Center' scaling mode for eDP/DSI on GMCH platforms

From: Ville Syrjälä We don't have a LVDS_BORDER_ENABLE type of bit for either eDP or DSI, and just trying to frob the display timings to include borders results in a corrupted picture. So reject the 'Center' scaling mode on GMCH platforms for eDP and DSI. TODO:

[Intel-gfx] [PATCH 5/5] drm-i915: Add sys IPS toggle interface

This interface allows enabling/disabling of IPS feature. It allows to see immediately the power management savings and will allow to expose this through sysfs interface for powertop to leverage its functionality. Signed-off-by: Alexandra Yates ---

[Intel-gfx] [PATCH 4/5] drm/i915: Hook up pfit for DSI

From: Ville Syrjälä Add the scaling mode property to DSI connectors, handle changes in the property value, and compute the panel fitter state during .compute_config(). v2: Handle BXT as well Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 2/5] drm/i915: Compute DSI PLL parameters during .compute_config()

From: Ville Syrjälä Compute the DSI PLL parameters during .compute_config() rather than .pre_pll_enable() so that we can fail gracefully if we can't find suitable parameters. In order to do that we need to store the DSI PLL parameters in pipe_config. v2: Handle

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

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: Alexandra Yates ---

[Intel-gfx] [PATCH 3/5] drm/i915: Eliminate {vlv, bxt}_configure_dsi_pll()

From: Ville Syrjälä Fold the DSI PLL configuration functions into the DSI PLL enable functions since they are small and not called from anywhere else. Signed-off-by: Ville Syrjälä Reviewed-by: Jani Nikula ---

[Intel-gfx] [PATCH 1/5] drm/i915: Setup DPLL/DPLLMD for DSI too on VLV/CHV

From: Ville Syrjälä Set up DPLL and DPLL_MD even when driving DSI output on VLV/CHV. While the DPLL isn't used to provide the clock we still need the refclock, and it appears that the pixel repeat factor also has an effect on DSI output. So set up eveyrhing in DPLL

[Intel-gfx] [PATCH 4/5] drm/i915: Add sys drrs toggle interface

This interface allows enabling/disabling of DRRS feature. It allows to see immediately the power management savings and will allow to expose this through sysfs interface for powertop to leverage its functionality. Signed-off-by: Alexandra Yates ---

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

This interface allows an immediate enabling of FBC feature. What allow us to see immediately the FBC power management savings and will allow us to expose this through sysfs interface for powertop to leverage its functionality. Signed-off-by: Alexandra Yates ---

[Intel-gfx] [PATCH 3/5] drm/i915: Add sys RC6 toggle interface

This interface allows enabling/disabling of RC6 feature. It allows to see immediately the RC6 power management savings and will allow to expose this through sysfs interface for powertop to leverage its functionality. Signed-off-by: Alexandra Yates ---

[Intel-gfx] [PATCH 0/5] drm/i915: Rest of my DSI and DPLL stuff

From: Ville Syrjälä Here is the remainder of my DSI/DPLL series [1]. Everything else got merged already. The first patch in the series is the only one to lack an r-b. Tested on BYT FFRD8 only, BXT stuff is not tested. [1]

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

This project is explained in detail on the HAS https://docs.google.com/a/intel.com/document/d/1E-en_xqfHgCnhD1Tes3f08UYrOc-etv2W-pU0ZErKdE/edit?usp=sharing Summary: Permits the user to identify and toggle values for PSR, FBC, RC6, DRRS, and IPS under /sys/class/drm/card0/power/. By enabling

Re: [Intel-gfx] [PATCH 00/16] drm/i915: DSI and DPLL stuff for VLV/CHV mostly

On Tue, Mar 15, 2016 at 04:39:53PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Here's a pile of pending VLV/CHV DSI and DPLL patches I had lying around. > Most of these have been posted before. Would be nice to finally get them > in. > >

Re: [Intel-gfx] [PATCH 10/10] Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"

On Tue, Apr 12, 2016 at 03:04:10PM +0300, Imre Deak wrote: > On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Enable the unclaimd register detection stuff on vlv/chv since we've > > now > > fixed the known

[Intel-gfx] [PATCH 00/14] Gen8 Execlist based Engine reset and recovery support

This series for Engine reset functionality from Gen8 onwards. Some of the prep patches are already sent and merged, now follows more of them and implementation patches. Many many thanks to Mika and Chris for their time in review, these patches have become much more simpler than they were

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Replace ILK eDP underrun suppression with something better

On Tue, Apr 12, 2016 at 10:16:26AM +0200, Patrik Jakobsson wrote: > On Fri, Apr 01, 2016 at 09:53:19PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > The underruns we were seeing when enabling eDP port A on ILK seem to > > have been

[Intel-gfx] [PATCH 12/14] drm/i915/tdr: Add engine reset count to error state

Driver maintains count of how many times a given engine is reset, useful to capture this in error state also. It gives an idea of how engine is coping up with the workloads it is executing before this error state. Signed-off-by: Arun Siluvery ---

[Intel-gfx] [PATCH 14/14] drm/i915/tdr: Enable Engine reset and recovery support

Everything in place, flip the switch. This feature is available only from Gen8, for previous gen devices driver falls back to legacy full gpu reset. Signed-off-by: Tomas Elf Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/i915_drv.h

[Intel-gfx] [PATCH 11/14] drm/i915: Port of Added scheduler support to __wait_request() calls

This is a partial port of the following patch from John Harrison's GPU scheduler patch series: (patch sent to Intel-GFX with the subject line "[Intel-gfx] [RFC 19/39] drm/i915: Added scheduler support to __wait_request() calls" on Fri 17 July 2015) Author: John Harrison

[Intel-gfx] [PATCH 13/14] drm/i915/tdr: Export reset count info to debugfs

A new variable is added to export the reset counts to debugfs, this includes full gpu reset and engine reset count. This is useful for tests where they areexpected to trigger reset; these counts are checked before and after the test to ensure the same. Signed-off-by: Arun Siluvery

[Intel-gfx] [PATCH 06/14] drm/i915/tdr: Capture engine state before reset

Minimal state of engine is saved before resetting it, this state includes head, current active request. A consistency check is performed on the active request to make sure that the context HW is executing is same as the one for the active request. This check is important because engine recovery

[Intel-gfx] [PATCH 10/14] drm/i915: Extending i915_gem_check_wedge to check engine reset in progress

i915_gem_check_wedge now returns a non-zero result in three different cases: 1. Legacy: A hang has been detected and full GPU reset is in progress. 2. Per-engine recovery: a. A single engine reference can be passed to the function, in which case only that engine will be checked. If that

[Intel-gfx] [PATCH 08/14] drm/i915/tdr: Add support for per engine reset recovery

This change implements support for per-engine reset as an initial, less intrusive hang recovery option to be attempted before falling back to the legacy full GPU reset recovery mode if necessary. This is only supported from Gen8 onwards. Hangchecker determines which engines are hung and invokes

[Intel-gfx] [PATCH 07/14] drm/i915/tdr: Restore engine state and start after reset

We capture the state of an engine before resetting it, once the reset is successful engine is restored with the same state and restarted. The state includes head register and active request. We also nudge the head forward if it hasn't advanced, otherwise when the engine is restarted HW executes

[Intel-gfx] [PATCH 05/14] drm/i915/tdr: Prepare execlist submission to handle tdr resubmission after reset

To resume execution after engine reset we resubmit the context and this needs to be treated differently otherwise we would count it as a completely new submission. This change modifies the submission path to account for this. During resubmission we only submit the head request that caused the

[Intel-gfx] [PATCH 09/14] drm/i915: Skip reset request if there is one already

From: Mika Kuoppala To perform engine reset we first disable engine to capture its state. This is done by issuing a reset request. Because we are reusing existing infrastructure, again when we actually reset an engine, reset function checks engine mask and issues

[Intel-gfx] [PATCH 04/14] drm/i915/tdr: Modify error handler for per engine hang recovery

This is a preparatory patch which modifies error handler to do per engine hang recovery. The actual patch which implements this sequence follows later in the series. The aim is to prepare existing recovery function to adapt to this new function where applicable (which fails at this point because

[Intel-gfx] [PATCH 02/14] drm/i915/tdr: Extend the idea of reset_counter to engine reset

This change extends the idea of reset_counter variable to engine reset by creating additional variables for each engine. Least significant bit is set to mark the engine reset is pending and once reset is successful it is incremented again, this is further used to count the no of engine resets.

[Intel-gfx] [PATCH 03/14] drm/i915: Reinstate hang recovery work queue.

From: Tomas Elf There used to be a work queue separating the error handler from the hang recovery path, which was removed a while back in this commit: commit b8d24a06568368076ebd5a858a011699a97bfa42 Author: Mika Kuoppala Date: Wed Jan 28

[Intel-gfx] [PATCH 01/14] drm/i915: Update i915.reset to handle engine resets

In preparation for engine reset work update this parameter to handle more than one type of reset. Default at the moment is still full gpu reset. Cc: Chris Wilson Cc: Mika Kuoppala Signed-off-by: Arun Siluvery ---

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Split execlists hardware status page initialisation from setup

== Series Details == Series: series starting with [1/2] drm/i915: Split execlists hardware status page initialisation from setup URL : https://patchwork.freedesktop.org/series/5596/ State : failure == Summary == Series 5596v1 Series without cover letter

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport (rev3)

== Series Details == Series: drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport (rev3) URL : https://patchwork.freedesktop.org/series/5367/ State : failure == Summary == Series 5367v3 drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport

Re: [Intel-gfx] [PATCH v3] drm/core: Add drm_accurate_vblank_count, v3.

Hi Maarten, [auto build test WARNING on drm/drm-next] [also build test WARNING on v4.6-rc3 next-20160412] [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/Maarten-Lankhorst/drm-core-Add

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with drm/i915: check for ERR_PTR from i915_gem_object_pin_map() (rev2)

On 12/04/16 17:03, Patchwork wrote: == Series Details == Series: series starting with drm/i915: check for ERR_PTR from i915_gem_object_pin_map() (rev2) URL : https://patchwork.freedesktop.org/series/5591/ State : failure == Summary == Series 5591v2 Series without cover letter

Re: [Intel-gfx] [RFC 2/2] drm/i915: Use i915_vma_iomap from the ringbuffer

On Tue, Apr 12, 2016 at 04:56:52PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Similarly to i915_gem_object_pin_map on LLC platforms, we can > use the new VMA based io mapping on !LLC to decrease the cost > of ringbuf pinning and unpinning. If you are going

Re: [Intel-gfx] [RFC 1/2] drm/i915: Move ioremap_wc tracking onto VMA

On Tue, Apr 12, 2016 at 04:56:51PM +0100, Tvrtko Ursulin wrote: > From: Chris Wilson > > 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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix VLV/CHV unclaimed register errors

On Mon, Apr 11, 2016 at 02:30:51PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Fix VLV/CHV unclaimed register errors > URL : https://patchwork.freedesktop.org/series/5531/ > State : failure > > == Summary == > > Series 5531v1 drm/i915: Fix VLV/CHV unclaimed register

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

On 12/04/16 14:51, 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 7c17d377374d ("drm/i915: Use ordered seqno write interrupt generation on gen8+ execlists"). On

Re: [Intel-gfx] [PATCH] drm: atomic: fix legacy gamma set helper

On Tue, Apr 12, 2016 at 01:51:02PM +0100, Lionel Landwerlin wrote: > On 12/04/16 12:57, Daniel Vetter wrote: > >On Mon, Apr 11, 2016 at 02:43:39PM +0100, Lionel Landwerlin wrote: > >>Color management properties are a bit of an odd use case because > >>they're not marked as atomic properties.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write (rev4)

== Series Details == Series: drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write (rev4) URL : https://patchwork.freedesktop.org/series/4446/ State : success == Summary == Series 4446v4 drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with drm/i915: check for ERR_PTR from i915_gem_object_pin_map() (rev2)

== Series Details == Series: series starting with drm/i915: check for ERR_PTR from i915_gem_object_pin_map() (rev2) URL : https://patchwork.freedesktop.org/series/5591/ State : failure == Summary == Series 5591v2 Series without cover letter

Re: [Intel-gfx] [PATCH v4 RESEND 0/5] Move workarounds from intel_dp_dpcd_read_wake() into drm's DP helpers

Sounds good, I'll have the rebased versions posted in a bit On Tue, 2016-04-12 at 13:17 +0300, Jani Nikula wrote: > On Mon, 28 Mar 2016, Lyude wrote: > > > > Resending this because it looks like replying to my previous series > > of patches > > causes patchwork to pick up

[Intel-gfx] [PATCH 3/5] drm/i915: bail in alloc_pdp when !FULL_48BIT_PPGTT

If we are not in FULL_48BIT_PPGTT mode then we really shouldn't continue on with our allocations, given that the call to free_dpd would bail early without freeing everything, thus leaking memory. Cc: Chris Wilson Cc: Joonas Lahtinen

[Intel-gfx] [PATCH 4/5] drm/i915: call kunmap_px on pt_vaddr

We need to kunmap pt_vaddr and not pt itself, otherwise we end up mapping a bunch of pages without ever unmapping them. Cc: Chris Wilson Cc: Joonas Lahtinen Signed-off-by: Matthew Auld ---

[Intel-gfx] [PATCH 2/5] drm/i915: harden allocation paths in allocate_va_range

For the gen6/gen8_allocate_va_range functions remove the WARN_ON range sanity checks in favour of simply hardening the allocation paths. This also fixes the inconsistency in which we don't always handle the potential overflow in our checks. Cc: Chris Wilson Cc: Joonas

[Intel-gfx] [PATCH 1/5] drm/i915: use dev_priv directly in gen8_ppgtt_notify_vgt

Remove dev local and use to_i915() in gen8_ppgtt_notify_vgt. v2: use dev_priv directly for QUESTION_MACROS (Joonas Lahtinen) Cc: Joonas Lahtinen Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 5 ++--- 1 file

[Intel-gfx] [PATCH v2 04/10] drm/i915: Move vlv/chv display irq code to a more logical place

From: Ville Syrjälä Reshuffle the code a bit to move the vlv/chv display irq functions away from the main irq hooks, next to the other sub (de,gt,etc.) hooks. v2: Rebased due to changes in vlv_display_irq_reset() Signed-off-by: Ville Syrjälä

[Intel-gfx] [RFC 1/2] drm/i915: Move ioremap_wc tracking onto VMA

From: Chris Wilson 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

[Intel-gfx] [RFC 2/2] drm/i915: Use i915_vma_iomap from the ringbuffer

From: Tvrtko Ursulin Similarly to i915_gem_object_pin_map on LLC platforms, we can use the new VMA based io mapping on !LLC to decrease the cost of ringbuf pinning and unpinning. Signed-off-by: Tvrtko Ursulin ---

[Intel-gfx] [PATCH v2 02/10] drm/i915: Fix up vlv/chv display irq setup

From: Ville Syrjälä The vlv/chv display irq setup was a bit of mess after I ran out of steam when working on it last. Fix it up so that we just have a _reset() and _postinstall() hooks for the display irqs, and use those consistently. v2: Clear out

Re: [Intel-gfx] [PATCH 15/16] Revert "drm/i915/bxt: Disable power well support"

On Fri, Apr 01, 2016 at 04:02:46PM +0300, Imre Deak wrote: > With the preceding fixes power well support should be functional on > Broxton, I could enter/exit DC5 without problems. > > This reverts commit 18024199579882265653bfe9e2b1a3dcb5697cd9. > > CC: Matt Roper >

Re: [Intel-gfx] [PATCH 16/16] drm/i915/bxt: Enable runtime PM

On Fri, Apr 01, 2016 at 04:02:47PM +0300, Imre Deak wrote: > With the preceding fixes runtime PM should be functional, I could > runtime suspend/resume the device without problems. > > Signed-off-by: Imre Deak Reviewed-by: David Weinehall > ---

Re: [Intel-gfx] [PATCH v3 14/16] drm/i915/bxt: Add HW state verification for DDI PHY and CDCLK

On Mon, Apr 04, 2016 at 05:27:10PM +0300, Imre Deak wrote: > I caught a few errors in our current PHY/CDCLK programming by sanity > checking the actual programmed state, so I thought it would be also > useful for the future. In addition to verifying the state after > programming it also verify it

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Mark obj->mapping as dirtying the backing storage

On Tue, Apr 12, 2016 at 02:32:31PM +0100, Chris Wilson wrote: > When reviewing some of Tvrtko's usage for i915_gem_object_pin_map(), he > suggested replacing some use of kmap(i915_gem_object_get_dirty_page()) > with a plain i915_gem_object_pin_map(). This raised the question of who > should mark

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

On Tue, Apr 12, 2016 at 04:58:07PM +0300, Mika Kuoppala wrote: > Michał Winiarski writes: > > > [ text/plain ] > > 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

Re: [Intel-gfx] [PATCH 09/16] drm/i915/bxt: Pass drm_i915_private to DDI PHY, CDCLK helpers

On Fri, Apr 01, 2016 at 04:02:40PM +0300, Imre Deak wrote: > For internal APIs passing dev_priv is preferred to reduce indirections, > so convert over a few DDI PHY, CDCLK helpers. > > No functional change. > > Signed-off-by: Imre Deak Reviewed-by: David Weinehall

Re: [Intel-gfx] [PATCH 03/16] drm/i915/bxt: Add a note about BXT_PORT_CL1CM_DW30 being read-only

On Fri, Apr 01, 2016 at 04:02:34PM +0300, Imre Deak wrote: > This register is read-only, so we have never actually set > OCL2_LDOFUSE_PWR_DIS in it as specified by the specification. Add a code > comment about this. I filed a specification update request to clarify > this there. > > CC: Arthur J

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use new i915_gem_object_pin_map for LRC

On Tue, Apr 12, 2016 at 03:40:42PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > We can use the new pin/lazy unpin API for simplicity > and more performance in the execlist submission paths. > > v2: > * Fix error handling and convert more users. > *

Re: [Intel-gfx] [PATCH v3] drm/core: Add drm_accurate_vblank_count, v3.

On Tue, Apr 12, 2016 at 04:32:19PM +0200, Maarten Lankhorst wrote: > This function is useful for gen2 intel devices which have no frame > counter, but need a way to determine the current vblank count without > racing with the vblank interrupt handler. > > intel_pipe_update_start checks if no

Re: [Intel-gfx] [PATCH 07/10] drm/virtio: Drop dummy gamma table support

On Tue, 12 Apr 2016, Emil Velikov wrote: > On 30 March 2016 at 10:51, Daniel Vetter wrote: > > No need to confuse userspace like this. > > > > Cc: Gerd Hoffmann > > Cc: Dave Airlie > > Signed-off-by: Daniel Vetter

[Intel-gfx] [PATCH 2/2] drm/i915: Use new i915_gem_object_pin_map for LRC

From: Tvrtko Ursulin We can use the new pin/lazy unpin API for simplicity and more performance in the execlist submission paths. v2: * Fix error handling and convert more users. * Compact some names for readability. v3: * intel_lr_context_free was not unpinning.

[Intel-gfx] [PATCH 1/2] drm/i915: Split execlists hardware status page initialisation from setup

From: Tvrtko Ursulin Split the hardware status page into setup and initialisation, where setup means setting up the driver state to support the engine, and initialization means programming the hardware with the before set up state. This way the design matches the

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [resend-for-CI,1/3] drm/i915: Extract knowledge of register forcewake domains

On 12/04/16 15:29, Patchwork wrote: == Series Details == Series: series starting with [resend-for-CI,1/3] drm/i915: Extract knowledge of register forcewake domains URL : https://patchwork.freedesktop.org/series/5593/ State : failure == Summary == Series 5593v1 Series without cover letter

Re: [Intel-gfx] [PATCHv3 2/4] drm/i915: Store the dpll config in crtc_state->shared_dpll

>-Original Message- >From: Conselvan De Oliveira, Ander >Sent: Monday, April 11, 2016 6:07 PM >To: intel-gfx@lists.freedesktop.org; R, Durgadoss >Cc: ville.syrj...@linux.intel.com >Subject: Re: [PATCHv3 2/4] drm/i915: Store the dpll config in

[Intel-gfx] [PATCH v3] drm/core: Add drm_accurate_vblank_count, v3.

This function is useful for gen2 intel devices which have no frame counter, but need a way to determine the current vblank count without racing with the vblank interrupt handler. intel_pipe_update_start checks if no vblank interrupt will occur during vblank evasion, but cannot check whether the

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [resend-for-CI,1/3] drm/i915: Extract knowledge of register forcewake domains

== Series Details == Series: series starting with [resend-for-CI,1/3] drm/i915: Extract knowledge of register forcewake domains URL : https://patchwork.freedesktop.org/series/5593/ State : failure == Summary == Series 5593v1 Series without cover letter

[Intel-gfx] [PATCH] drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport

From: Tim Gore WaEnableSamplerGPGPUPreemptionSupport fixes a problem related to mid thread pre-emption. Signed-off-by: Tim Gore --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_ringbuffer.c | 7 --- 2 files changed, 5

Re: [Intel-gfx] [PATCH v5 03/46] backlight: lm3630a_bl: stop messing with the pwm->period field

On Tue, Apr 12, 2016 at 03:16:13PM +0100, Lee Jones wrote: > On Tue, 12 Apr 2016, Thierry Reding wrote: > > > On Wed, Mar 30, 2016 at 10:03:26PM +0200, Boris Brezillon wrote: > > > pwm->period field is not supposed to be changed by PWM users. The only > > > ones authorized to change it are the

Re: [Intel-gfx] [PATCH v5 02/46] backlight: pwm_bl: remove useless call to pwm_set_period()

On Tue, Apr 12, 2016 at 03:16:53PM +0100, Lee Jones wrote: > On Tue, 12 Apr 2016, Thierry Reding wrote: > > > On Wed, Mar 30, 2016 at 10:03:25PM +0200, Boris Brezillon wrote: > > > The PWM period will be set when calling pwm_config. Remove this useless > > > call to pwm_set_period(), which might

Re: [Intel-gfx] [PATCH v5 02/46] backlight: pwm_bl: remove useless call to pwm_set_period()

On Tue, 12 Apr 2016, Thierry Reding wrote: > On Wed, Mar 30, 2016 at 10:03:25PM +0200, Boris Brezillon wrote: > > The PWM period will be set when calling pwm_config. Remove this useless > > call to pwm_set_period(), which might mess up with the internal PWM state. > > > > Signed-off-by: Boris

Re: [Intel-gfx] [PATCH v5 15/46] pwm: introduce the pwm_state concept

On Tue, 12 Apr 2016 16:05:46 +0200 Thierry Reding wrote: > On Tue, Apr 12, 2016 at 03:26:44PM +0200, Boris Brezillon wrote: > > On Tue, 12 Apr 2016 15:11:18 +0200 > > Thierry Reding wrote: > > > > > On Tue, Apr 12, 2016 at 02:45:08PM +0200,

Re: [Intel-gfx] [PATCH v5 03/46] backlight: lm3630a_bl: stop messing with the pwm->period field

On Tue, 12 Apr 2016, Thierry Reding wrote: > On Wed, Mar 30, 2016 at 10:03:26PM +0200, Boris Brezillon wrote: > > pwm->period field is not supposed to be changed by PWM users. The only > > ones authorized to change it are the PWM core and PWM drivers. > > > > Signed-off-by: Boris Brezillon

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Use new i915_gem_object_pin_map for LRC (rev2)

== Series Details == Series: drm/i915: Use new i915_gem_object_pin_map for LRC (rev2) URL : https://patchwork.freedesktop.org/series/5580/ State : failure == Summary == Series 5580v2 drm/i915: Use new i915_gem_object_pin_map for LRC

Re: [Intel-gfx] [PATCH v5 15/46] pwm: introduce the pwm_state concept

On Tue, Apr 12, 2016 at 03:26:44PM +0200, Boris Brezillon wrote: > On Tue, 12 Apr 2016 15:11:18 +0200 > Thierry Reding wrote: > > > On Tue, Apr 12, 2016 at 02:45:08PM +0200, Boris Brezillon wrote: > > > On Tue, 12 Apr 2016 14:21:41 +0200 > > > Thierry Reding

Re: [Intel-gfx] [PATCH 07/10] drm/virtio: Drop dummy gamma table support

On 30 March 2016 at 10:51, Daniel Vetter wrote: > No need to confuse userspace like this. > > Cc: Gerd Hoffmann > Cc: Dave Airlie > Signed-off-by: Daniel Vetter > --- >

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

Michał Winiarski writes: > [ text/plain ] > 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 7c17d377374d ("drm/i915: Use ordered seqno write interrupt >

Re: [Intel-gfx] [PATCH] drm/i915: check for ERR_PTR from i915_gem_object_pin_map()

On Tue, Apr 12, 2016 at 02:46:16PM +0100, Dave Gordon wrote: > The newly-introduced function i915_gem_object_pin_map() returns an > ERR_PTR (not NULL) if the pin-and-map opertaion fails, so that's what we > must check for. And it's nicer not to assign such a pointer-or-error to > a structure being

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

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 7c17d377374d ("drm/i915: Use ordered seqno write interrupt generation on gen8+ execlists"). On gen8+ size of PIPE_CONTROL with Post Sync

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [resend-for-CI,1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs

On 12/04/16 14:43, Ville Syrjälä wrote: On Tue, Apr 12, 2016 at 02:33:45PM +0100, Tvrtko Ursulin wrote: On 08/04/16 08:02, Patchwork wrote: Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE Old friend unclaimed access

[Intel-gfx] [PATCH] drm/i915: check for ERR_PTR from i915_gem_object_pin_map()

The newly-introduced function i915_gem_object_pin_map() returns an ERR_PTR (not NULL) if the pin-and-map opertaion fails, so that's what we must check for. And it's nicer not to assign such a pointer-or-error to a structure being filled in until after it's been validated, so we should keep it

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [resend-for-CI,1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs

On Tue, Apr 12, 2016 at 02:33:45PM +0100, Tvrtko Ursulin wrote: > > On 08/04/16 08:02, Patchwork wrote: > > Test kms_flip: > > Subgroup basic-flip-vs-dpms: > > pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE > > Old friend unclaimed access prior to suspending: >

  1   2   >