Re: [Intel-gfx] [PATCH v6 1/1] drm/i915/bxt: Check BIOS RC6 setup before enabling RC6

Thanks for the review Imre. I Kept that BSD2 check thinking some BXT revision might support it :) Will remove the check and send the patch. Thanks Sagar On 2/2/2016 9:48 PM, Imre Deak wrote: On pe, 2016-01-29 at 23:22 +0530, Sagar Arun Kamble wrote: RC6 setup is shared between BIOS and

Re: [Intel-gfx] [PATCH 1/2] drm/i915/BXT: Fixed COS blanking issue

Hi Uma, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on v4.5-rc2 next-20160201] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url:

[Intel-gfx] [PATCH v7 1/1] drm/i915/bxt: Check BIOS RC6 setup before enabling RC6

RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6 setup registers. If those are not setup Driver should not enable RC6. For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values to know if BIOS has enabled HW/SW RC6. This will also enable user to control RC6 using

Re: [Intel-gfx] [PATCH 1/2] drm/i915/BXT: Fixed COS blanking issue

Hi Uma, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on v4.5-rc2 next-20160201] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url:

Re: [Intel-gfx] [PATCH 4/8] drm/i915: Add i915 perf event for Haswell OA unit

Hi Robert, [auto build test WARNING on v4.4-rc8] [cannot apply to drm-intel/for-linux-next v4.5-rc2 v4.5-rc1 next-20160202] [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/Robert-Bragg/Enable

[Intel-gfx] [PATCH 8/8] drm/i915: Add more Haswell OA metric sets

This adds 'compute', 'compute extended', 'memory reads', 'memory writes' and 'sampler balance' metric sets for Haswell. Signed-off-by: Robert Bragg --- drivers/gpu/drm/i915/i915_oa_hsw.c | 483 - 1 file changed, 482 insertions(+), 1

[Intel-gfx] [PATCH 1/8] drm/i915: Add i915 perf infrastructure

Adds base i915 perf infrastructure for Gen performance metrics. This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64 properties to configure a stream of metrics and returns a new fd usable with standard VFS system calls including read() to read typed and sized records; ioctl()

[Intel-gfx] [PATCH 7/8] drm/i915: add oa_event_min_timer_exponent sysctl

The minimal sampling period is now configurable via a dev.i915.oa_min_timer_exponent sysctl parameter. Following the precedent set by perf, the default is the minimum that won't (on its own) exceed the default kernel.perf_event_max_sample_rate default of 10 samples/s. Signed-off-by: Robert

[Intel-gfx] [PATCH 6/8] drm/i915: Add dev.i915.perf_event_paranoid sysctl option

Consistent with the kernel.perf_event_paranoid sysctl option that can allow non-root users to access system wide cpu metrics, this can optionally allow non-root users to access system wide OA counter metrics from Gen graphics hardware. Signed-off-by: Robert Bragg ---

[Intel-gfx] [PATCH 4/8] drm/i915: Add i915 perf event for Haswell OA unit

Gen graphics hardware can be set up to periodically write snapshots of performance counters into a circular buffer via its Observation Architecture and this patch exposes that capability to userspace via the i915 perf interface. Cc: Chris Wilson Signed-off-by: Robert

[Intel-gfx] [PATCH 5/8] drm/i915: advertise available metrics via sysfs

Each metric set is given a sysfs entry like: /sys/class/drm/card0/metrics//id This allows userspace to enumerate the specific sets that are available for the current system. The 'id' file contains an unsigned integer that can be used to open the associated metric set via

[Intel-gfx] [PATCH 3/8] drm/i915: Add 'render basic' Haswell OA unit config

Adds a static OA unit, MUX + B Counter configuration for basic render metrics on Haswell. This is autogenerated from an internal XML description of metric sets. Signed-off-by: Robert Bragg --- drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/i915_drv.h

[Intel-gfx] [PATCH 2/8] drm/i915: rename OACONTROL GEN7_OACONTROL

OACONTROL changes quite a bit for gen8, with some bits split out into a per-context OACTXCONTROL register. Rename now before add more gen7 OA registers Signed-off-by: Robert Bragg --- drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++-- drivers/gpu/drm/i915/i915_reg.h|

[Intel-gfx] [PATCH 0/8] Enable Gen 7 Observation Architecture

This series enables support for the Observation Architecture on Haswell Compared to the last series I sent out, the main changes are: * The terminology changed so we open a 'stream' not an 'event'. * A stream is configured with an array of u64 properties after finding the previous config

Re: [Intel-gfx] regression bisected: display sync drops after 7221fc33

On Tue, Jan 26, 2016 at 09:40:27AM -0700, dann frazier wrote: > On Tue, Jan 26, 2016 at 08:10:04AM -0700, dann frazier wrote: > > On Tue, Jan 26, 2016 at 01:17:01PM +0200, Ville Syrjälä wrote: > > > On Mon, Jan 25, 2016 at 09:35:26AM -0700, dann frazier wrote: > > > > I've got a Lenovo T410 w/ an

Re: [Intel-gfx] regression bisected: display sync drops after 7221fc33

On Tue, Feb 02, 2016 at 03:21:30PM -0700, dann frazier wrote: > On Tue, Jan 26, 2016 at 09:40:27AM -0700, dann frazier wrote: > > On Tue, Jan 26, 2016 at 08:10:04AM -0700, dann frazier wrote: > > > On Tue, Jan 26, 2016 at 01:17:01PM +0200, Ville Syrjälä wrote: > > > > On Mon, Jan 25, 2016 at

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dsi: Add audio reference in dsi encoder

Again like previous patch can you add checks for IS_BROXTON for all of these changes so it does not affect CHV/VLV ? regards, Sivakumar On 2/2/2016 11:24 PM, Ramalingam C wrote: From: "Kumar, Mahesh" We are re-using Mipi encoder enabled by GOP driver, but not

Re: [Intel-gfx] [PATCH 1/2] drm/i915/BXT: Fixed COS blanking issue

On 2/2/2016 11:24 PM, Ramalingam C wrote: From: Uma Shankar During Charging OS mode, mipi display was blanking.This is because during driver load, though encoder, connector were active but crtc returned inactive. This caused sanitize function to disable the DSI panel.

Re: [Intel-gfx] [PATCH] drm/i915: Check DDI max lanes after applying BXT workaround

On Fri, Jan 29, 2016 at 04:49:29PM +0200, Ville Syrjälä wrote: > On Thu, Jan 28, 2016 at 03:09:37PM -0800, Matt Roper wrote: > > In commit bfb9faab8 we added a workaround for some BXT BIOS that fail to > > properly initialize the DDI_A_4_LANES bit of the control register (4 > > lanes is the only

[Intel-gfx] [PATCH] drm/i915/bxt: Additional MIPI clock divider form B0 stepping onwards

The MIPI clock calculations for the addtional clock are revised from B0 stepping onwards, the bit definitions have changed compared to old stepping. v2: Fixing compilation warning. Signed-off-by: Deepak M --- drivers/gpu/drm/i915/i915_reg.h | 104

[Intel-gfx] [PATCH 1/1] drm/i915/skl: fix RC6 residency time calculation

The RC6 residency time unit is 1.33us on SKL according to the specification, so update the calculation accordingly. Cc: Imre Deak Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/i915_sysfs.c | 3 ++- 1 file changed, 2 insertions(+), 1

Re: [Intel-gfx] [RFC 01/29] drm/i915/gvt: Introduce the basic architecture of GVT-g

Hi Joonas: Thanks you very much! We're very excited for receiving your advice and continue to be open to any comments. :) I'm supposed that we should make the agreements on i915 host change at the very beginning, as I'm concerned during the discussion of i915 host change, you know, maybe

[Intel-gfx] [PATCH] drm/i915: Pretend cursor is always on for ILK-style WM calculations (v2)

Due to our lack of two-step watermark programming, our driver has historically pretended that the cursor plane is always on for the purpose of watermark calculations; this helps avoid serious flickering when the cursor turns off/on (e.g., when the user moves the mouse pointer to a different

[Intel-gfx] [PATCH 1/2] drm/i915/BXT: Fixed COS blanking issue

From: Uma Shankar During Charging OS mode, mipi display was blanking.This is because during driver load, though encoder, connector were active but crtc returned inactive. This caused sanitize function to disable the DSI panel. In AOS, this is fine since HWC will do a

[Intel-gfx] [PATCH 2/2] drm/i915/dsi: Add audio reference in dsi encoder

From: "Kumar, Mahesh" We are re-using Mipi encoder enabled by GOP driver, but not incrementing reference count for Audio Power domain, so audio was not working. This patch increments the reference count during DSI init and Adds get/put in DSI enable/disable functions as

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Don't save/restore eDP panel power during suspend (v3)

On to, 2016-01-07 at 10:15 +0200, Jani Nikula wrote: > On Wed, 06 Jan 2016, Matt Roper wrote: > > Our attempts save/restore panel power state in i915_suspend.c are > > causing unclaimed register warnings on BXT since the registers for > > this > > platform differ from

[Intel-gfx] [APL PO PATCH] drm/i915/bxt: Additional MIPI clock divider form B0 stepping onwards

The MIPI clock calculations for the addtional clock are revised from B0 stepping onwards, the bit definitions have changed compared to old stepping. Signed-off-by: Deepak M --- drivers/gpu/drm/i915/i915_reg.h | 104 +--

Re: [Intel-gfx] [APL PO PATCH] drm/i915/bxt: Additional MIPI clock divider form B0 stepping onwards

Hi Deepak, [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on v4.5-rc2 next-20160202] [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/Deepak-M/drm-i915-bxt

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/BXT: Configure DSI after enabling DSI pll

== Summary == Series 3016v1 drm/i915/BXT: Configure DSI after enabling DSI pll http://patchwork.freedesktop.org/api/1.0/series/3016/revisions/1/mbox/ Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE Test

[Intel-gfx] intel_fbdev_restore_mode derefence null pointer

I met one kenel panic issue in iVGT, usually can be easily reproduced with multi-vms. unable to handle kernel NULL pointer dereference at 00a0IP: [< (d29) a025a52b>] intel_fbdev_restore_mode+0x57/0x73 [i915] The drm_device ->dev_private -> fbdev ->fb access function run

[Intel-gfx] [PATCH v4 07/12] drm/i915: GEM operations need to be done under the big lock

From: Tvrtko Ursulin VMA creation and GEM list management need the big lock. v2: Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall) Not to mention drm_gem_object_unreference was there in existing code with no mutex held. v3: Some callers of

[Intel-gfx] [PATCH v3 06/12] drm/i915: Do not lie about atomic wait granularity

From: Tvrtko Ursulin Currently the wait_for_atomic_us only allows for a millisecond granularity which is not nice towards callers requesting small micro-second waits. Re-implement it so micro-second granularity is really supported and not just in the name of the macro.

Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina MacBook Pro

Hi Dave, On Tue, Feb 02, 2016 at 11:10:19AM +1000, Dave Airlie wrote: > On 2 February 2016 at 08:49, Lukas Wunner wrote: > > On Mon, Jan 11, 2016 at 08:09:20PM +0100, Lukas Wunner wrote: > >> Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013), v5. > > > > This

[Intel-gfx] [PATCH v2 01/12] drm/i915: Add wait_for_us

From: Tvrtko Ursulin This is for callers who want micro-second precision but are not waiting from the atomic context. v2: * Fix atomic waits. (Dave Gordon) * Use USEC_PER_SEC and USEC_PER_MSEC. (Chris Wilson) Signed-off-by: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH 08/12] drm/i915: Fix struct mutex vs. RPS lock inversion

On Tue, Feb 02, 2016 at 02:13:43PM +, Tvrtko Ursulin wrote: > > On 02/02/16 13:16, Chris Wilson wrote: > >On Tue, Feb 02, 2016 at 11:06:26AM +, Tvrtko Ursulin wrote: > >>@@ -5244,8 +5243,10 @@ static void valleyview_cleanup_pctx(struct > >>drm_device *dev) > >>if

Re: [Intel-gfx] [PATCH v3] drm/i915/skl/kbl: Add support for pipe fusing

On Thu, 28 Jan 2016, Damien Lespiau wrote: > On Wed, Jan 20, 2016 at 03:31:20PM +0100, Patrik Jakobsson wrote: >> On SKL and KBL we can have pipe A/B/C disabled by fuse settings. The >> pipes must be fused in descending order (e.g. C, B+C, A+B+C). We simply >> decrease

Re: [Intel-gfx] [PATCH] drm/i915: Support HDMI EDID injection

On Tue, 02 Feb 2016, Marius Vlad wrote: > Use the drm_property_blob data for user-supplied EDID blobs. > > Signed-off-by: Marius Vlad > --- > drivers/gpu/drm/i915/intel_hdmi.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff

Re: [Intel-gfx] [PATCH 08/12] drm/i915: Fix struct mutex vs. RPS lock inversion

On 02/02/16 13:16, Chris Wilson wrote: On Tue, Feb 02, 2016 at 11:06:26AM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin RPS lock must be taken before the struct_mutex to avoid locking inversion. So stop grabbing it for the whole powersave initialization and

[Intel-gfx] [PATCH 1/2] drm/i915/skl: Don't skip mst encoders in skl_ddi_pll_select()

We don't actually check for INTEL_OUTPUT_DP_MST at all in here, as a result we skip assigning a DPLL to any DP MST ports, which makes link training fail, after which things just keep going downhill from there. Consequently, this fixes DisplayPort MST causing kernel panics, machine check errors,

[Intel-gfx] [PATCH 2/2] drm/i915/skl: Explicitly check for eDP in skl_ddi_pll_select()

Assuming any connector that isn't DP, MST, or HDMI is eDP definitely seems likely to cover up other bugs in the future. Signed-off-by: Lyude --- drivers/gpu/drm/i915/intel_ddi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

[Intel-gfx] [PATCH v3 08/12] drm/i915: Fix struct mutex vs. RPS lock inversion

From: Tvrtko Ursulin RPS lock must be taken before the struct_mutex to avoid locking inversion. So stop grabbing it for the whole powersave initialization and instead only take it during the sections which need it. Also, struct_mutex is not needed any more since

Re: [Intel-gfx] [PATCH 1/2] drm/i915/skl: Don't skip mst encoders in skl_ddi_pll_select()

On Tue, 02 Feb 2016, Lyude wrote: > We don't actually check for INTEL_OUTPUT_DP_MST at all in here, as a > result we skip assigning a DPLL to any DP MST ports, which makes link > training fail, after which things just keep going downhill from there. Apparently broken since

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Use atomic state to obtain load detection crtc.

Op 01-02-16 om 17:08 schreef Ville Syrjälä: > On Mon, Feb 01, 2016 at 02:43:57PM +0100, Maarten Lankhorst wrote: >> Instead of restoring dpms and a flag for whether a temp fb is allocated >> duplicate >> the old plane_state and crtc_state, and restore the members we potentially >> touched. >> >>

Re: [Intel-gfx] [PATCH igt 1/3] lib/igt_fb: also call __gem_set_tiling for Y tiling

On 01/02/16 17:57, Ville Syrjälä wrote: On Mon, Feb 01, 2016 at 05:44:42PM +, Tvrtko Ursulin wrote: On 01/02/16 17:16, Zanoni, Paulo R wrote: Em Sex, 2016-01-29 às 21:06 +0200, Ville Syrjälä escreveu: On Fri, Jan 29, 2016 at 04:46:30PM -0200, Paulo Zanoni wrote: The interesting thing

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Kconfig for extra driver debugging

On 02/02/16 09:18, Jani Nikula wrote: On Mon, 01 Feb 2016, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/Kconfig | 12 1 file changed, 12

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Kconfig for extra driver debugging

On Mon, 01 Feb 2016, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Signed-off-by: Tvrtko Ursulin > --- > drivers/gpu/drm/i915/Kconfig | 12 > 1 file changed, 12 insertions(+) > > diff --git

Re: [Intel-gfx] [PATCH 1/3] drm/i915: don't deactivate FBC at skylake_disable_primary_plane

Hey, Op 29-01-16 om 21:57 schreef Paulo Zanoni: > FBC is already deactivated at this point. > > Besides, nothing should be calling these lower-level function > pointers. A few months ago, the only caller of > dev_priv->fbc.deactivate was intel_pipe_set_base_atomic(), which was > the kgdboc

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Kconfig for extra driver debugging

On Tue, 02 Feb 2016, Tvrtko Ursulin wrote: > On 02/02/16 09:18, Jani Nikula wrote: >> On Mon, 01 Feb 2016, Tvrtko Ursulin wrote: >>> From: Tvrtko Ursulin >>> >>> Signed-off-by: Tvrtko Ursulin

[Intel-gfx] ✗ Fi.CI.BAT: failure for RFC list: Add a customisable debugging list iterator

== Summary == Series 3015v1 RFC list: Add a customisable debugging list iterator 2016-02-02T16:10:12.409215 http://patchwork.freedesktop.org/api/1.0/series/3015/revisions/1/mbox/ Applying: RFC list: Add a customisable debugging list iterator Repository lacks necessary blobs to fall back on 3-way

Re: [Intel-gfx] [PATCH 01/12] drm/i915: Add wait_for_us

On Tue, Feb 02, 2016 at 02:04:55PM +, Tvrtko Ursulin wrote: > > > On 02/02/16 11:57, Chris Wilson wrote: > >On Tue, Feb 02, 2016 at 11:06:19AM +, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>This is for callers who want micro-second precision but are

Re: [Intel-gfx] [PATCH v6 1/1] drm/i915/bxt: Check BIOS RC6 setup before enabling RC6

On pe, 2016-01-29 at 23:22 +0530, Sagar Arun Kamble wrote: > RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6 > setup registers. If those are not setup Driver should not enable RC6. > For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values > to know if BIOS has

Re: [Intel-gfx] [PATCH v4 0/6] Check pixel clock when setting mode

On Tue, Feb 02, 2016 at 03:16:37PM +0200, Mika Kahola wrote: > From EDID we can read and request higher pixel clock than > our HW can support. This set of patches add checks if > requested pixel clock is lower than the one supported by the HW. > The requested mode is discarded if we cannot support

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bxt: update list of PCIIDs

On pe, 2016-01-29 at 10:14 +, Patchwork wrote: > == Summary == > > Series 2901v1 drm/i915/bxt: update list of PCIIDs > http://patchwork.freedesktop.org/api/1.0/series/2901/revisions/1/mbox > / > > Test kms_flip: > Subgroup basic-flip-vs-dpms: > pass   ->

[Intel-gfx] [PATCH 01/12] drm/i915: Add wait_for_us

From: Tvrtko Ursulin This is for callers who want micro-second precision but are not waiting from the atomic context. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_dp.c | 3 +-- drivers/gpu/drm/i915/intel_drv.h | 9 +

[Intel-gfx] [PATCH 06/12] drm/i915: Do not lie about atomic wait granularity

From: Tvrtko Ursulin Currently the wait_for_atomic_us only allows for a millisecond granularity which is not nice towards callers requesting small micro-second waits. Re-implement it so micro-second granularity is really supported and not just in the name of the macro.

[Intel-gfx] [PATCH 02/12] drm/i915: Do not wait atomically for display clocks

From: Tvrtko Ursulin Looks like this code does not need to wait atomically since it otherwise takes the mutex. Signed-off-by: Tvrtko Ursulin Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä

[Intel-gfx] [PATCH 00/12] Misc locking fixes and GEM debugging

From: Tvrtko Ursulin A collection of patches addressing locking inversions, missing locking, un-needed atomic waiting, more precision for the latter and adding some infrastructure to catch some of these during driver development. Tvrtko Ursulin (12): drm/i915: Add

[Intel-gfx] [PATCH 07/12] drm/i915: GEM operations need to be done under the big lock

From: Tvrtko Ursulin VMA creation and GEM list management need the big lock. v2: Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall) Not to mention drm_gem_object_unreference was there in existing code with no mutex held. v3: Some callers of

[Intel-gfx] [PATCH 11/12] drm/i915: Introduce dedicated safe object VMA iterator

From: Tvrtko Ursulin Purpose is to catch places which iterate the object VMA list without holding the big lock. Implemented by open coding list_for_each_entry_safe to make the macro compatible with existing call sites. v2: Replace WARN_ON with lockdep_assert_held.

[Intel-gfx] [PATCH 12/12] drm/i915: Add BKL asserts to get page helpers

From: Tvrtko Ursulin Purpose is catching illegal callers. v2: Replace WARN_ON with lockdep_assert_held. (Chris Wilson, Daniel Vetter) v3: Moved under dedicated CONFIG_DRM_I915_DEBUG and back to WARN_ON. Signed-off-by: Tvrtko Ursulin Cc:

[Intel-gfx] [PATCH 04/12] drm/i915/lrc: Do not wait atomically when stopping engines

From: Tvrtko Ursulin I do not see that this needs to be done atomically and up to one second is quite a long time to busy loop. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_lrc.c | 2 +- 1 file changed, 1 insertion(+), 1

[Intel-gfx] [PATCH 10/12] drm/i915: Introduce dedicated object VMA iterator

From: Tvrtko Ursulin Purpose is to catch places which iterate the object VMA list without holding the big lock. Implemented by open coding list_for_each_entry to make the macro compatible with existing call sites. v2: Error capture runs without the mutex so iterate

[Intel-gfx] [PATCH 08/12] drm/i915: Fix struct mutex vs. RPS lock inversion

From: Tvrtko Ursulin RPS lock must be taken before the struct_mutex to avoid locking inversion. So stop grabbing it for the whole powersave initialization and instead only take it during the sections which need it. Also, struct_mutex is not needed any more since

[Intel-gfx] [PATCH 09/12] drm/i915/ilk: Move register read under spinlock

From: Tvrtko Ursulin Code does read-modify-write but the read was outside the lock. It is fine since the caller holds struct mutex, but if we correct this we open up the opportunity for decreasing the mutex duration time since the call to ironlake_enable_drps does not

[Intel-gfx] [PATCH 05/12] drm/i915: Kconfig for extra driver debugging

From: Tvrtko Ursulin v2: Added a submenu based on an idea by Chris Wilson. Signed-off-by: Tvrtko Ursulin Cc: Chris Wilson Cc: Jani Nikula --- drivers/gpu/drm/i915/Kconfig | 6 ++

[Intel-gfx] [PATCH 03/12] drm/i915/guc: Do not wait for firmware load atomically

From: Tvrtko Ursulin It does not look like this code needs to wait atomically? Higher in the call chain it calls the GEM API and I do not see that the section is under any spin locks or such. Signed-off-by: Tvrtko Ursulin Cc: Alex Dai

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Kconfig for extra driver debugging

On 02/02/16 09:40, Jani Nikula wrote: On Tue, 02 Feb 2016, Tvrtko Ursulin wrote: On 02/02/16 09:18, Jani Nikula wrote: On Mon, 01 Feb 2016, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Signed-off-by:

Re: [Intel-gfx] [PATCH 12/12] drm/i915: Add BKL asserts to get page helpers

On Tue, Feb 02, 2016 at 11:06:30AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Purpose is catching illegal callers. > > v2: Replace WARN_ON with lockdep_assert_held. (Chris Wilson, Daniel Vetter) > v3: Moved under dedicated CONFIG_DRM_I915_DEBUG and back to

Re: [Intel-gfx] [PATCH 09/12] drm/i915/ilk: Move register read under spinlock

On Tue, Feb 02, 2016 at 11:06:27AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Code does read-modify-write but the read was outside the lock. > > It is fine since the caller holds struct mutex, but if we > correct this we open up the opportunity for

Re: [Intel-gfx] [PATCH 12/12] drm/i915: Add BKL asserts to get page helpers

On 02/02/16 11:39, Chris Wilson wrote: On Tue, Feb 02, 2016 at 11:06:30AM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Purpose is catching illegal callers. v2: Replace WARN_ON with lockdep_assert_held. (Chris Wilson, Daniel Vetter) v3: Moved under dedicated

[Intel-gfx] ✓ Fi.CI.BAT: success for Misc locking fixes and GEM debugging

== Summary == Series 3006v1 Misc locking fixes and GEM debugging http://patchwork.freedesktop.org/api/1.0/series/3006/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b-frame-sequence: dmesg-warn -> PASS (skl-i5k-2) Subgroup

Re: [Intel-gfx] [PATCH 07/12] drm/i915: GEM operations need to be done under the big lock

On Tue, Feb 02, 2016 at 11:06:25AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > VMA creation and GEM list management need the big lock. > > v2: > > Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall) > > Not to mention

Re: [Intel-gfx] [PATCH 10/12] drm/i915: Introduce dedicated object VMA iterator

On 02/02/16 11:36, Chris Wilson wrote: On Tue, Feb 02, 2016 at 11:06:28AM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Purpose is to catch places which iterate the object VMA list without holding the big lock. Implemented by open coding list_for_each_entry to

Re: [Intel-gfx] [PATCH 10/12] drm/i915: Introduce dedicated object VMA iterator

On Tue, Feb 02, 2016 at 11:06:28AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Purpose is to catch places which iterate the object VMA list > without holding the big lock. > > Implemented by open coding list_for_each_entry to make the > macro compatible

Re: [Intel-gfx] [PATCH 01/12] drm/i915: Add wait_for_us

On Tue, Feb 02, 2016 at 11:06:19AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > This is for callers who want micro-second precision but are not > waiting from the atomic context. linux/time.h provides us with USEC_PER_MSEC that would help to break up these

Re: [Intel-gfx] [PATCH 02/12] drm/i915: Do not wait atomically for display clocks

On Tue, Feb 02, 2016 at 11:06:20AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Looks like this code does not need to wait atomically since it > otherwise takes the mutex. > > Signed-off-by: Tvrtko Ursulin > Cc: Ville Syrjälä

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Support HDMI EDID injection

== Summary == Series 3007v1 drm/i915: Support HDMI EDID injection http://patchwork.freedesktop.org/api/1.0/series/3007/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b-frame-sequence: dmesg-warn -> PASS (skl-i5k-2) Subgroup

Re: [Intel-gfx] [PATCH 01/12] drm/i915: Add wait_for_us

On 02/02/16 11:06, Tvrtko Ursulin wrote: From: Tvrtko Ursulin This is for callers who want micro-second precision but are not waiting from the atomic context. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_dp.c | 3 +--

[Intel-gfx] ✓ Fi.CI.BAT: success for Check pixel clock when setting mode

== Summary == Series 3009v1 Check pixel clock when setting mode http://patchwork.freedesktop.org/api/1.0/series/3009/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b-frame-sequence: dmesg-warn -> PASS (skl-i5k-2) Subgroup

Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: Use atomic state to obtain load detection crtc, v2.

On Tue, Feb 02, 2016 at 01:48:17PM +0100, Maarten Lankhorst wrote: > drm/i915: Use atomic state to obtain load detection crtc, v2. > > Instead of restoring dpms and a flag for whether a temp fb is allocated > duplicate > an atomic state before the new state is committed, and commit it the old

Re: [Intel-gfx] [PATCH 02/12] drm/i915: Do not wait atomically for display clocks

On Tue, Feb 02, 2016 at 02:08:44PM +, Dave Gordon wrote: > On 02/02/16 12:00, Chris Wilson wrote: > >On Tue, Feb 02, 2016 at 11:06:20AM +, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>Looks like this code does not need to wait atomically since it >

Re: [Intel-gfx] [PATCH v4 07/12] drm/i915: GEM operations need to be done under the big lock

On Tue, Feb 02, 2016 at 02:46:19PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > VMA creation and GEM list management need the big lock. > > v2: > > Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall) > > Not to mention

[Intel-gfx] [PATCH v2 1/2] drm/i915/skl: Don't skip mst encoders in skl_ddi_pll_select()

We don't actually check for INTEL_OUTPUT_DP_MST at all in here, as a result we skip assigning a DPLL to any DP MST ports, which makes link training fail: [ 1442.933896] [drm:intel_power_well_enable] enabling DDI D power well [ 1442.933905] [drm:skl_set_power_well] Enabling DDI D power well [

Re: [Intel-gfx] [PATCH] lib/igt_kms: Add COMIT_ATOMIC to igt_display_commit2()

Op 01-02-16 om 06:50 schreef Mayuresh Gharpure: > Co-Author : Marius Vlad > > So far we have had only two commit styles, COMMIT_LEGACY > and COMMIT_UNIVERSAL. This patch adds another commit style > COMMIT_ATOMIC which makes use of drmModeAtomicCommit() > > Signed-off-by:

[Intel-gfx] [PATCH] RFC list: Add a customisable debugging list iterator

list_for_each_entry_check() is a variant of list_for_each_entry() modelled after the ideas for RCU checking, that first evaluates an expression before iterating. This can be used to both document and verify the appropriate locks are held for the list. In order to make the macro more versatile,

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Sanity check DP AUX message buffer and size

On pe, 2016-01-29 at 13:19 +, Patchwork wrote: > == Summary == > > Series 2922v1 Series without cover letter > http://patchwork.freedesktop.org/api/1.0/series/2922/revisions/1/mbox > / Thanks for the review, I pushed the patchset to dinq. --Imre > > > bdw- > nuci7total:156  

Re: [Intel-gfx] [PATCH] drm/i915: Pretend cursor is always on for ILK-style WM calculations

On Mon, Feb 01, 2016 at 07:31:47PM -0800, Matt Roper wrote: > On Mon, Feb 01, 2016 at 04:22:22PM +0200, Ville Syrjälä wrote: > > On Mon, Feb 01, 2016 at 01:26:14AM -0800, Matt Roper wrote: > > > Due to our lack of two-step watermark programming, our driver has > > > historically pretended that the

[Intel-gfx] [PATCH] drm/i915/BXT: Configure DSI after enabling DSI pll

We need to enable DSI PLL before configuring the DSI registers. Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/intel_dsi.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c

Re: [Intel-gfx] [RFC 01/29] drm/i915/gvt: Introduce the basic architecture of GVT-g

Hi Chris: Thanks for your feedback. :) Currently there are some host i915 changes we need to discussion, need your advice and feedback. For GVT LRC context, as you see, we need it to do shadow context. All the modifications of LRC are for it. Need inputs to think a better approach or code

[Intel-gfx] [PATCH] drm/i915: Pretend cursor is always on for ILK-style WM calculations (v2)

Due to our lack of two-step watermark programming, our driver has historically pretended that the cursor plane is always on for the purpose of watermark calculations; this helps avoid serious flickering when the cursor turns off/on (e.g., when the user moves the mouse pointer to a different

Re: [Intel-gfx] [RFC 01/29] drm/i915/gvt: Introduce the basic architecture of GVT-g

On Wed, Feb 03, 2016 at 02:01:15PM +0800, Zhi Wang wrote: > Hi Joonas: > Thanks you very much! We're very excited for receiving your > advice and continue to be open to any comments. :) > > I'm supposed that we should make the agreements on i915 host change > at the very beginning, as I'm

Re: [Intel-gfx] [PATCH] drm/i915/BXT: Configure DSI after enabling DSI pll

This change is needed to enable DSI/MIPI display on BXT Reviewed-by: Mika Kahola On Tue, 2016-02-02 at 23:21 +0530, Ramalingam C wrote: > We need to enable DSI PLL before configuring the DSI registers. > > Signed-off-by: Ramalingam C > --- >

Re: [Intel-gfx] regression bisected: display sync drops after 7221fc33

On Tue, Feb 02, 2016 at 02:51:20PM -0800, Matt Roper wrote: > On Tue, Feb 02, 2016 at 03:21:30PM -0700, dann frazier wrote: > > On Tue, Jan 26, 2016 at 09:40:27AM -0700, dann frazier wrote: > > > On Tue, Jan 26, 2016 at 08:10:04AM -0700, dann frazier wrote: > > > > On Tue, Jan 26, 2016 at

Re: [Intel-gfx] [PATCH] drm/i915/BXT: Configure DSI after enabling DSI pll

just realized that intel_dsi_init is not called from setup outputs for BXT. is this expected ? if so when is it expected to be added ? Again, the current code in intel_setup_outputs calls intel_dsi_init from vlv/chv section so please confirm if this is needed for all platforms or just in BXT.

Re: [Intel-gfx] regression bisected: display sync drops after 7221fc33

On Tue, Feb 02, 2016 at 05:35:49PM -0700, dann frazier wrote: > On Tue, Feb 02, 2016 at 02:51:20PM -0800, Matt Roper wrote: > > On Tue, Feb 02, 2016 at 03:21:30PM -0700, dann frazier wrote: > > > On Tue, Jan 26, 2016 at 09:40:27AM -0700, dann frazier wrote: > > > > On Tue, Jan 26, 2016 at

Re: [Intel-gfx] [PATCH 10/12] drm/i915: Introduce dedicated object VMA iterator

On Tue, Feb 02, 2016 at 12:10:19PM +, Tvrtko Ursulin wrote: > On 02/02/16 11:36, Chris Wilson wrote: > >#define list_for_each_entry_check(pos, list, member, lock) \ > >for (typeof(*lock) == typeof(struct mutex) ? assert_lockdep_held(lock) : > >assert_spin_locked(lock); \ > > pos =

[Intel-gfx] [PATCH 1/3] lib/igt_kms: Add support for 4K and audio HDMI EDID injection.

Signed-off-by: Marius Vlad --- lib/igt_kms.c | 176 ++ lib/igt_kms.h | 2 + 2 files changed, 178 insertions(+) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index 90c8da7..64aa5d1 100644 --- a/lib/igt_kms.c +++

[Intel-gfx] [PATCH 2/3] tests/kms_hdmi_inject: Test to make use of HDMI injection capabilities.

Signed-off-by: Marius Vlad --- tests/Makefile.sources | 1 + tests/kms_hdmi_inject.c | 165 2 files changed, 166 insertions(+) create mode 100644 tests/kms_hdmi_inject.c diff --git a/tests/Makefile.sources

[Intel-gfx] [PATCH v4 1/6] drm/i915: DisplayPort pixel clock check

It is possible the we request to have a mode that has higher pixel clock than our HW can support. This patch checks if requested pixel clock is lower than the one supported by the HW. The requested mode is discarded if we cannot support the requested pixel clock. This patch applies to

[Intel-gfx] [PATCH v4 0/6] Check pixel clock when setting mode

From EDID we can read and request higher pixel clock than our HW can support. This set of patches add checks if requested pixel clock is lower than the one supported by the HW. The requested mode is discarded if we cannot support the requested pixel clock. For example for Cherryview 'cvt 2560

  1   2   >