[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: get a runtime PM ref in i915_wedged_set

== Series Details == Series: drm/i915: get a runtime PM ref in i915_wedged_set URL : https://patchwork.freedesktop.org/series/21184/ State : success == Summary == Series 21184v1 drm/i915: get a runtime PM ref in i915_wedged_set

[Intel-gfx] [PATCH] drm/i915: get a runtime PM ref in i915_wedged_set

At least in bxt (with decoupled mmio), it prevents a warning while capturing the reg state: [ ] WARNING: assert_rpm_wakelock_held.part.4+0x1e/0x20 [i915] [ ] RPM wakelock ref not held during HW access [ ] Call Trace: [ ] dump_stack+0x63/0x87 [ ] __warn+0xd1/0xf0 [ ] ?

Re: [Intel-gfx] [PATCH v2] drm/i915: Perform link quality check unconditionally during long pulse

On Mon, Mar 13, 2017 at 10:53:23PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Apparently some DP sinks are a little nuts and cause HPD to drop > intermittently during modesets. This happens eg. on an ASUS PB287Q. > In oder to recover from

[Intel-gfx] Potential BUG in drm/i915/execlists: Reset RING registers upon resume

I am writing regarding this kernel patch: https://git.kernel.org/pub/sc m/linux/kernel/git/stable/stable-queue.git/tree/releases/4.9.9/drm- i915-execlists-reset-ring-registers-upon-resume.patch . I have identified this by bisect to be the cause of a suspend and resume issue. Please see

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix DisplayPort Hotplug (rev3)

== Series Details == Series: drm/i915: Fix DisplayPort Hotplug (rev3) URL : https://patchwork.freedesktop.org/series/19601/ State : success == Summary == Series 19601v3 drm/i915: Fix DisplayPort Hotplug https://patchwork.freedesktop.org/api/1.0/series/19601/revisions/3/mbox/ fi-bdw-5557u

Re: [Intel-gfx] [07/11] drm/i915/guc: Improve the GuC documentation & comments about proxy submissions

On 10/03/17 08:28, Oscar Mateo wrote: While at it, fix a typo (s/ring_lcra/ring_lrca) and improve the naming of one firware interface field (s/ring_tail/submit_element_info, since it can contain more than just the ring tail). No change in functionality. Signed-off-by: Oscar Mateo

Re: [Intel-gfx] Fixes that failed to backport to v4.11-rc1

On Mon, Mar 13, 2017 at 06:14:56PM +0200, Jani Nikula wrote: > 1f7b847d72c3 ("drm/i915: Disable engine->irq_tasklet around resets") Done. > 370a81fb89cb ("drm/i915: Remove unused function intel_ddi_get_link_dpll()") Don't bother, just code tidy? > 262fd485ac6b ("drm/i915: Only enable hotplug

Re: [Intel-gfx] [PATCH v2] drm/i915: Perform link quality check unconditionally during long pulse

On Mon, Mar 13, 2017 at 10:53:23PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Apparently some DP sinks are a little nuts and cause HPD to drop > intermittently during modesets. This happens eg. on an ASUS PB287Q. > In oder to recover from

[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm/i915: Ignore panel type from OpRegion on SKL"

== Series Details == Series: Revert "drm/i915: Ignore panel type from OpRegion on SKL" URL : https://patchwork.freedesktop.org/series/20912/ State : success == Summary == Series 20912v1 Revert "drm/i915: Ignore panel type from OpRegion on SKL"

Re: [Intel-gfx] [06/11 v3] drm/i915/guc: Make intel_guc_send a function pointer

On 10/03/17 08:28, Oscar Mateo wrote: Prepare for an alternate GuC communication interface. v2: Make a few functions static and name them correctly while we are at it (Oscar), but leave an intel_guc_send_mmio interface for users that require old-style communication. v3: Send

[Intel-gfx] [PATCH v2] drm/i915: Perform link quality check unconditionally during long pulse

From: Ville Syrjälä Apparently some DP sinks are a little nuts and cause HPD to drop intermittently during modesets. This happens eg. on an ASUS PB287Q. In oder to recover from this we can't really use the previous connector status to determine if the link needs

Re: [Intel-gfx] [01/11 v3] drm/i915/guc: Sanitize GuC client initialization

On 10/03/17 08:28, Oscar Mateo wrote: Started adding proper teardown to guc_client_alloc, ended up removing quite a few dead ends where errors communicating with the GuC were silently ignored. There also seemed to be quite a few erronous teardown actions performed in case of an error (ordering

Re: [Intel-gfx] [PATCH 24/24] drm/gem: Add DEFINE_DRM_GEM_FOPS

On Wed, Mar 08, 2017 at 03:12:57PM +0100, Daniel Vetter wrote: > Sadly there's only 1 driver which can use it, everyone else is special > for some reason: > > - gma500 has a horrible runtime PM ioctl wrapper that probably doesn't > really work but meh. > - i915 needs special compat_ioctl

Re: [Intel-gfx] [PATCH 23/24] drm: Create DEFINE_DRM_GEM_CMA_FOPS and roll it out to drivers

On Mon, Mar 13, 2017 at 03:31:40PM -0400, Sean Paul wrote: > On Wed, Mar 08, 2017 at 03:12:56PM +0100, Daniel Vetter wrote: > > Less code ftw. > > > > This converts all drivers except the tinydrm helper module. That one > > needs more work, since it gets the THIS_MODULE reference from > >

Re: [Intel-gfx] [PATCH 23/24] drm: Create DEFINE_DRM_GEM_CMA_FOPS and roll it out to drivers

On Wed, Mar 08, 2017 at 03:12:56PM +0100, Daniel Vetter wrote: > Less code ftw. > > This converts all drivers except the tinydrm helper module. That one > needs more work, since it gets the THIS_MODULE reference from > tinydrm.ko instead of the actual driver module like it should. > Probably

Re: [Intel-gfx] [PATCH 22/24] drm: Nerf the preclose callback for modern drivers

On Wed, Mar 08, 2017 at 03:12:55PM +0100, Daniel Vetter wrote: > With all drivers converted there's only legacy dri1 drivers using it. > Not going to touch those, instead just hide it like we've done with > other dri1 driver hooks like firstopen. > > In all this I didn't find any real reason why

Re: [Intel-gfx] [PATCH 21/24] drm/msm: Simplify vblank event delivery

On Wed, Mar 08, 2017 at 03:12:54PM +0100, Daniel Vetter wrote: > The core takes care of handling the send_event vs. close() issues, we > can remove that driver code. > > Cc: Rob Clark > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Signed-off-by:

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Optimize VLV/CHV display FIFO updates

On Fri, Mar 10, 2017 at 12:07:53PM +0200, Ville Syrjälä wrote: > On Thu, Mar 09, 2017 at 09:26:36PM +, Chris Wilson wrote: > > On Thu, Mar 09, 2017 at 05:44:34PM +0200, ville.syrj...@linux.intel.com > > wrote: > > > From: Ville Syrjälä > > > > > > Use

Re: [Intel-gfx] [PATCH 20/24] drm/exynos: Merge pre/postclose hooks

On Wed, Mar 08, 2017 at 03:12:53PM +0100, Daniel Vetter wrote: > Again no apparent explanation for the split except hysterical raisins. > Merging them also makes it a bit more obviuos what's going on wrt the > runtime pm refdancing. Commit message copypasta. The code is Reviewed-by: Sean Paul

Re: [Intel-gfx] [PATCH 17/24] drm/vgem: switch to postclose

On Wed, Mar 08, 2017 at 03:12:50PM +0100, Daniel Vetter wrote: > I didn't spot anything that would require ordering here (well not > anywhere else either), and I'm trying to unify at least modern drivers > on one close hook. > > Cc: Chris Wilson > Signed-off-by: Daniel

Re: [Intel-gfx] [PATCH 16/24] drm/tegra: switch to postclose

On Wed, Mar 08, 2017 at 03:12:49PM +0100, Daniel Vetter wrote: > I didn't spot anything that would require ordering here (well not > anywhere else either), and I'm trying to unify at least modern drivers > on one close hook. > > Cc: Thierry Reding > Cc:

Re: [Intel-gfx] [PATCH 14/24] drm/nouveau: Merge pre/postclose hooks

On Wed, Mar 08, 2017 at 03:12:47PM +0100, Daniel Vetter wrote: > Again no apparent explanation for the split except hysterical raisins. > Merging them also makes it a bit more obviuos what's going on wrt the > runtime pm refdancing. Yeah, holding the pm reference from preclose to postclose had me

Re: [Intel-gfx] [PATCH 13/24] drm/msm: switch to postclose

On Wed, Mar 08, 2017 at 03:12:46PM +0100, Daniel Vetter wrote: > I didn't spot anything that would require ordering here (well not > anywhere else either), and I'm trying to unify at least modern drivers > on one close hook. > > Cc: Rob Clark > Cc:

Re: [Intel-gfx] [PATCH 11/24] drm/doc: Document drm_file.[hc]

On Wed, Mar 08, 2017 at 03:12:44PM +0100, Daniel Vetter wrote: > Well, mostly drm_file.h, and clean up all related things: > > - I didnt' figure out the difference between preclose and postclose. > The existing explanation in drm-internals.rst didn't convince me, > since it's also really

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Optimize plane updates a bit

== Series Details == Series: drm/i915: Optimize plane updates a bit URL : https://patchwork.freedesktop.org/series/21002/ State : success == Summary == Series 21002v1 drm/i915: Optimize plane updates a bit https://patchwork.freedesktop.org/api/1.0/series/21002/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Convert intel_tv connector properties to atomic, v2.

Op 13-03-17 om 17:44 schreef Ville Syrjälä: > On Mon, Mar 13, 2017 at 05:35:42PM +0100, Maarten Lankhorst wrote: >> Op 13-03-17 om 17:22 schreef Ville Syrjälä: >>> On Mon, Mar 13, 2017 at 05:10:28PM +0100, Maarten Lankhorst wrote: As a proof of concept, first try to convert intel_tv, which is

[Intel-gfx] [PATCH] drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters.

From: Kenneth Graunke This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0 (indicating the optional feature is not supported), and makes execbuf always return -EINVAL if the flags are used. Apparently, no userspace ever shipped which used this optional

Re: [Intel-gfx] [PATCH 10/24] drm: Remove drm_pending_event->pid

On Wed, Mar 08, 2017 at 03:12:43PM +0100, Daniel Vetter wrote: > We might as well dump the drm_file pointer, that's about as useful > a cookie as the pid. Noticed while typing docs for drm_file and friends. > > Since the only consumer of this is the tracepoints I think we can safely > change this

Re: [Intel-gfx] [PATCH 23/24] drm: Create DEFINE_DRM_GEM_CMA_FOPS and roll it out to drivers

On Wed, Mar 08, 2017 at 03:12:56PM +0100, Daniel Vetter wrote: > Less code ftw. > > This converts all drivers except the tinydrm helper module. That one > needs more work, since it gets the THIS_MODULE reference from > tinydrm.ko instead of the actual driver module like it should. > Probably

[Intel-gfx] [PATCH] drm/i915: Stop using RP_DOWN_EI on Baytrail

On Baytrail, we manually calculate busyness over the evaluation interval to avoid issues with miscaluations with RC6 enabled. However, it turns out that the DOWN_EI interrupt generator is completely bust - it operates in two modes, continuous or never. Neither of which are conducive to good

[Intel-gfx] [PATCH] drm/i915: Only enable hotplug interrupts if the display interrupts are enabled

In order to prevent accessing the hpd registers outside of the display power wells, we should refrain from writing to the registers before the display interrupts are enabled. [4.740136] WARNING: CPU: 1 PID: 221 at drivers/gpu/drm/i915/intel_uncore.c:795 __unclaimed_reg_debug+0x44/0x50 [i915]

[Intel-gfx] [PATCH 2/2] drm/i915: Disable engine->irq_tasklet around resets

When we restart the engines, and we have active requests, a request on the first engine may complete and queue a request to the second engine before we try to restart the second engine. That queueing of the request may race with the engine to restart, and so may corrupt the current state.

[Intel-gfx] [PATCH 1/2] drm/i915: Split GEM resetting into 3 phases

Currently we do a reset prepare/finish around the call to reset the GPU, but it looks like we need a later stage after the hw has been reinitialised to allow GEM to restart itself. Start by splitting the 2 GEM phases into 3: prepare - before the reset, check if GEM recovered, then stop GEM

Re: [Intel-gfx] [10/11] drm/i915/guc: Refactor the concept "GuC context descriptor" into "GuC stage descriptor"

On 03/13/2017 04:49 AM, Chris Wilson wrote: On Fri, Mar 10, 2017 at 08:28:57AM -0800, Oscar Mateo wrote: A GuC context and a HW context are in no way related, so the name "GuC context descriptor" is very unfortunate, because a new reader of the code gets overwhelmed very quickly with a lot

Re: [Intel-gfx] [PATCH 08/24] drm: Remove DRM_MINOR_CNT

On Wed, Mar 08, 2017 at 03:12:41PM +0100, Daniel Vetter wrote: > This was originally added by David Herrmann for range checks, but > entirely unused. It confused me, so let's remove it. > > Cc: David Herrmann > Signed-off-by: Daniel Vetter

Re: [Intel-gfx] [08/11] drm/i915/guc: Wait for doorbell to be inactive before deallocating

On 03/13/2017 04:46 AM, Chris Wilson wrote: On Fri, Mar 10, 2017 at 08:28:55AM -0800, Oscar Mateo wrote: Doorbell release flow requires that we wait for GEN8_DRB_VALID bit to go to zero after updating db_status before we call the GuC to release the doorbell. Does this fix some of the '110'

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Convert intel_tv connector properties to atomic, v2.

On Mon, Mar 13, 2017 at 05:35:42PM +0100, Maarten Lankhorst wrote: > Op 13-03-17 om 17:22 schreef Ville Syrjälä: > > On Mon, Mar 13, 2017 at 05:10:28PM +0100, Maarten Lankhorst wrote: > >> As a proof of concept, first try to convert intel_tv, which is a rarely > >> used connector. It has 5

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Convert intel_tv connector properties to atomic, v2.

Op 13-03-17 om 17:22 schreef Ville Syrjälä: > On Mon, Mar 13, 2017 at 05:10:28PM +0100, Maarten Lankhorst wrote: >> As a proof of concept, first try to convert intel_tv, which is a rarely >> used connector. It has 5 properties, tv format and 4 margins. >> >> I'm less certain about the state

Re: [Intel-gfx] [PATCH 02/24] drm: Extract drm_prime.h

On Wed, Mar 08, 2017 at 03:12:35PM +0100, Daniel Vetter wrote: > Plus a little bit more documentation. > > v2: Untangle the missing forward decls to make drm_prime|gem.h > free-standing. > > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/drm-mm.rst | 3 ++ >

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Convert intel_tv connector properties to atomic, v2.

Op 13-03-17 om 17:22 schreef Ville Syrjälä: > On Mon, Mar 13, 2017 at 05:10:28PM +0100, Maarten Lankhorst wrote: >> As a proof of concept, first try to convert intel_tv, which is a rarely >> used connector. It has 5 properties, tv format and 4 margins. >> >> I'm less certain about the state

Re: [Intel-gfx] [PATCH 2/2] drm/i915/vbt: split out defaults that are set when there is no VBT

On Mon, Mar 13, 2017 at 11:55:31AM +0200, Jani Nikula wrote: > On Sat, 11 Mar 2017, Manasi Navare wrote: > > On Fri, Mar 10, 2017 at 03:27:58PM +0200, Jani Nikula wrote: > >> The main thing are the DDI ports. If there's a VBT that says there are > >> no outputs, we

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Convert intel_tv connector properties to atomic, v2.

On Mon, Mar 13, 2017 at 05:10:28PM +0100, Maarten Lankhorst wrote: > As a proof of concept, first try to convert intel_tv, which is a rarely > used connector. It has 5 properties, tv format and 4 margins. > > I'm less certain about the state behavior itself, should we pass a size > parameter to

[Intel-gfx] Fixes that failed to backport to v4.11-rc1

I'm already scripting my fixes backports quite a bit, and frankly don't really manually backport anything that doesn't apply cleanly. I'm thinking of automating some "failed to backport" reporting to authors, not unlike the failed stable backport reports. This is a manual report that the

[Intel-gfx] [PATCH 1/3] drm/i915: Convert intel_tv connector properties to atomic, v2.

As a proof of concept, first try to convert intel_tv, which is a rarely used connector. It has 5 properties, tv format and 4 margins. I'm less certain about the state behavior itself, should we pass a size parameter to intel_connector_alloc instead, so duplicate_state can be done globally if it

Re: [Intel-gfx] FW: [PATCH] drm/i915: Reject HDMI 12bpc if the sink doesn't indicate support

On Mon, Mar 13, 2017 at 01:09:10PM +0200, Sharma, Shashank wrote: > Regards > > Shashank > > > On 3/13/2017 12:53 PM, Ville Syrjälä wrote: > > On Mon, Mar 13, 2017 at 12:22:53PM +0200, Sharma, Shashank wrote: > >> Regards > >> > >> Shashank > >> > >>> From: Ville Syrjälä

Re: [Intel-gfx] [PATCH i-g-t v2 0/2] Kernel selftest plumbing

On Mon, Mar 13, 2017 at 04:29:47PM +0200, Petri Latvala wrote: > On Mon, Mar 13, 2017 at 02:15:34PM +, Chris Wilson wrote: > > On Mon, Mar 13, 2017 at 01:02:04PM +0200, Petri Latvala wrote: > > > On Mon, Mar 13, 2017 at 10:50:04AM +, Chris Wilson wrote: > > > > Still completely lacking

Re: [Intel-gfx] [PATCH i-g-t v2 0/2] Kernel selftest plumbing

For the record, I pushed this series so I could get the IGT release out. I'm sure there are various ways this functionality can be improved, so constructive suggestions are still definitely welcome. -- Petri Latvala ___ Intel-gfx mailing list

[Intel-gfx] [ANNOUNCE] intel-gpu-tools 1.18

A new intel-gpu-tools quarterly release is available with the following changes: Library changes: - Various changes to library functions so that they don't assume Intel hardware. (Lyude) - Added helper functions for managing synchronization primitives. (Robert Foss) - Added support for the

Re: [Intel-gfx] [PATCH] drm/i915: Rename REDIRECT_TO_GUC bit

On Mon, Mar 13, 2017 at 10:17:25AM +0530, Kamble, Sagar A wrote: > LGTM. > Reviewed-by: Sagar Arun Kamble [1] Thanks, pushed -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list

Re: [Intel-gfx] [PATCH] drm/i915: Move whole object to CPU domain for coherent shmem access

On Mon, Mar 13, 2017 at 11:06:20AM +0200, Joonas Lahtinen wrote: > On pe, 2017-03-10 at 00:09 +, Chris Wilson wrote: > > If the object is coherent, we can simply update the cache domain on the > > whole object rather than calculate the before/after clflushes. The > > advantage is that we then

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix error path for ggtt walk_hole()

On Mon, Mar 13, 2017 at 10:33:35AM +, Matthew Auld wrote: > On 13 March 2017 at 10:07, Chris Wilson wrote: > > The patch 6e32ab3d4777: "drm/i915: Fill different pages of the GTT" > > from Feb 13, 2017, leads to the following static checker warning: > > > >

Re: [Intel-gfx] [PATCH i-g-t v2 0/2] Kernel selftest plumbing

On Mon, Mar 13, 2017 at 02:15:34PM +, Chris Wilson wrote: > On Mon, Mar 13, 2017 at 01:02:04PM +0200, Petri Latvala wrote: > > On Mon, Mar 13, 2017 at 10:50:04AM +, Chris Wilson wrote: > > > Still completely lacking justification. The above is a non sequitur; > > > static testlist

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Catch error from mock_file()

On Mon, Mar 13, 2017 at 12:54:15PM +, Tvrtko Ursulin wrote: > > On 13/03/2017 12:47, Chris Wilson wrote: > >The patch 791ff39ae32a: "drm/i915: Live testing for context > >execution" from Feb 13, 2017, leads to the following static checker > >warning: > > > >

Re: [Intel-gfx] [PATCH] drm/i915: Inline gen6_sanitize_rps_pm_mask()

On Mon, Mar 13, 2017 at 01:24:41PM +, Chris Wilson wrote: > On Mon, Mar 13, 2017 at 03:15:32PM +0200, Mika Kuoppala wrote: > > Chris Wilson writes: > > > > > gen6_sanitize_rps_pm_mask() is small enough that inlining it shrinks the > > > object code. > > > > > >

Re: [Intel-gfx] [PATCH] drm/i915: Extend rpm wakelock for debugfs/i915_drpc_info

On Mon, Mar 13, 2017 at 03:41:34PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > i915_drpc_info missed covering a few register read with the runtime pm > > wakelock. Be simple and cover the entire function with a single wakelock > > so that new additions are

Re: [Intel-gfx] intel graphics hd 530 problem: screen splitted 2 parts horizontally

Hi Jani you are right, your weird(!) recommendation has worked! Thanks for your help.. On 13-03-2017 13:45, Jani Nikula wrote: On Mon, 13 Mar 2017, "M. selcuk karaca" wrote: we have "HP ProOne 600 G2 21.5-in Touch AiO" PC, equipped with "Intel HD Graphics

Re: [Intel-gfx] [PATCH i-g-t v2 0/2] Kernel selftest plumbing

On Mon, Mar 13, 2017 at 01:02:04PM +0200, Petri Latvala wrote: > On Mon, Mar 13, 2017 at 10:50:04AM +, Chris Wilson wrote: > > Still completely lacking justification. The above is a non sequitur; > > static testlist generation can be done just from the source. > > Static testlist generation

Re: [Intel-gfx] [PATCH] drm/i915: Extend rpm wakelock for debugfs/i915_drpc_info

On Mon, Mar 13, 2017 at 03:41:34PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > i915_drpc_info missed covering a few register read with the runtime pm > > wakelock. Be simple and cover the entire function with a single wakelock > > so that new additions are

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

On 13/03/2017 13:48, Arkadiusz Hiler wrote: On Mon, Mar 13, 2017 at 01:39:45PM +, Tvrtko Ursulin wrote: On 13/03/2017 13:15, Arkadiusz Hiler wrote: Currently fw->path values can represent one of three possible states: 1) NULL - device without the uC 2) '\0' - device with the uC but

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

== Series Details == Series: GuC Scrub vol. 1 (rev12) URL : https://patchwork.freedesktop.org/series/16856/ State : failure == Summary == Series 16856v12 GuC Scrub vol. 1 https://patchwork.freedesktop.org/api/1.0/series/16856/revisions/12/mbox/ Test drv_module_reload: Subgroup

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

On Mon, Mar 13, 2017 at 01:39:45PM +, Tvrtko Ursulin wrote: > > On 13/03/2017 13:15, Arkadiusz Hiler wrote: > > Currently fw->path values can represent one of three possible states: > > > > 1) NULL - device without the uC > > 2) '\0' - device with the uC but have no firmware > > 3) else -

Re: [Intel-gfx] [libdrm PATCH] intel: Make unsynchronized GTT mappings work on systems with snooping.

On Sun, Mar 12, 2017 at 06:19:17PM +0100, David Weinehall wrote: > On Sun, Mar 12, 2017 at 01:21:12PM +, Chris Wilson wrote: > > On Fri, Mar 10, 2017 at 05:14:32PM -0800, Kenneth Graunke wrote: > > > On systems without LLC, drm_intel_gem_bo_map_unsynchronized() has > > > had the surprising

Re: [Intel-gfx] [PATCH] drm/i915: Extend rpm wakelock for debugfs/i915_drpc_info

Chris Wilson writes: > i915_drpc_info missed covering a few register read with the runtime pm > wakelock. Be simple and cover the entire function with a single wakelock > so that new additions are not similarly missed in future. > > WARNING: CPU: 2 PID: 1334 at

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

On 13/03/2017 13:15, Arkadiusz Hiler wrote: Currently fw->path values can represent one of three possible states: 1) NULL - device without the uC 2) '\0' - device with the uC but have no firmware 3) else - device with the uC and we have firmware Second case is used only to WARN at a later

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix vGPU balloon for ggtt guard page

On Fri, Mar 10, 2017 at 10:22:38AM +0800, Zhenyu Wang wrote: > From commit a6508ded2a66 ("drm/i915: Use page coloring to provide the guard > page at the end of the GTT"), we no longer explicitly subtract guard page > at end for GGTT address space init, so shouldn't subtract that for vGPU > balloon

Re: [Intel-gfx] [03/11 v3] drm/i915/guc: Add onion teardown to the GuC setup

On Fri, Mar 10, 2017 at 08:28:50AM -0800, Oscar Mateo wrote: > Starting with intel_guc_loader, down to intel_guc_submission > and finally to intel_guc_log. > > v2: > - Null execbuf client outside guc_client_free (Daniele) > - Assert if things try to get allocated twice (Daniele/Joonas) > -

Re: [Intel-gfx] [PATCH] drm/i915: Inline gen6_sanitize_rps_pm_mask()

On Mon, Mar 13, 2017 at 03:15:32PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > gen6_sanitize_rps_pm_mask() is small enough that inlining it shrinks the > > object code. > > > > Signed-off-by: Chris Wilson > > Cc: Tvrtko Ursulin

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Catch error from mock_file()

== Series Details == Series: drm/i915/selftests: Catch error from mock_file() URL : https://patchwork.freedesktop.org/series/21156/ State : success == Summary == Series 21156v1 drm/i915/selftests: Catch error from mock_file()

Re: [Intel-gfx] [PATCH] drm/i915: Inline gen6_sanitize_rps_pm_mask()

Chris Wilson writes: > gen6_sanitize_rps_pm_mask() is small enough that inlining it shrinks the > object code. > > Signed-off-by: Chris Wilson > Cc: Tvrtko Ursulin > --- > drivers/gpu/drm/i915/i915_irq.c | 5 -

[Intel-gfx] [PATCH 11/11] HAX enable GuC for CI

--- drivers/gpu/drm/i915/i915_params.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index b6a7e36..9dcc8a0 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c

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

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

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

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

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

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

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

The file fits better. Additionally rename it to intel_uc_prepare_fw(), as the function does more than simple fetch. `obj` cleanup in the function is also fixed (i.e. removed). In the fail scenario it was always 'put' but there's no possible flow that initializes the obj properly and then goes to

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

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

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

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

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

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

[Intel-gfx] [PATCH v8 00/11] GuC Scrub vol. 1

Reasoning = General GuC/HuC cleanup simplifying logic and moving chunks around as the area got pretty rusty. This is the first part of effort to clean it up. A lot of logic were extracted from intel_guc_load() to other functions - it did not only handle the actual loading but had WA

[Intel-gfx] [PATCH 02/11] drm/i915/huc: Add huc_to_i915

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

[Intel-gfx] [PATCH 01/11] drm/i915/uc: Drop superfluous externs in intel_uc.h

Externs are implicit and we generally try to avoid them. Cc: Michal Wajdeczko Signed-off-by: Arkadiusz Hiler Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_uc.h | 12 ++-- 1 file

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

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

Re: [Intel-gfx] [PATCH] drm/i915: Add i810/i815 pci-ids for completeness

On Mon, Mar 13, 2017 at 03:04:21PM +0200, Jani Nikula wrote: > On Mon, 13 Mar 2017, Chris Wilson wrote: > > To improve our historical record and to simplify userspace that wants to > > include i915_pciids.h as its canonical breakdown of PCI IDs and their > > respective

Re: [Intel-gfx] [PATCH] drm/i915: Add i810/i815 pci-ids for completeness

On Mon, 13 Mar 2017, Chris Wilson wrote: > To improve our historical record and to simplify userspace that wants to > include i915_pciids.h as its canonical breakdown of PCI IDs and their > respective generations, include the gen1 ids for i810 and i815. Is this how you

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Catch error from mock_file()

On 13/03/2017 12:47, Chris Wilson wrote: The patch 791ff39ae32a: "drm/i915: Live testing for context execution" from Feb 13, 2017, leads to the following static checker warning: drivers/gpu/drm/i915/selftests/i915_gem_context.c:347 igt_ctx_exec() error: 'file' dereferencing

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add i810/i815 pci-ids for completeness

== Series Details == Series: drm/i915: Add i810/i815 pci-ids for completeness URL : https://patchwork.freedesktop.org/series/21149/ State : failure == Summary == Series 21149v1 drm/i915: Add i810/i815 pci-ids for completeness

[Intel-gfx] [PATCH] drm/i915/selftests: Catch error from mock_file()

The patch 791ff39ae32a: "drm/i915: Live testing for context execution" from Feb 13, 2017, leads to the following static checker warning: drivers/gpu/drm/i915/selftests/i915_gem_context.c:347 igt_ctx_exec() error: 'file' dereferencing possible ERR_PTR() Reported-by: Dan Carpenter

Re: [Intel-gfx] [bug report] drm/i915: Live testing for context execution

On Mon, Mar 13, 2017 at 03:34:29PM +0300, Dan Carpenter wrote: > Hello Chris Wilson, > > The patch 791ff39ae32a: "drm/i915: Live testing for context > execution" from Feb 13, 2017, leads to the following static checker > warning: > > drivers/gpu/drm/i915/selftests/i915_gem_context.c:347

Re: [Intel-gfx] [PATCH v6] drm/i915/guc: Simplify intel_guc_init_hw()

On Fri, Mar 10, 2017 at 01:11:06PM +0100, Michal Wajdeczko wrote: > On Fri, Mar 10, 2017 at 12:46:06PM +0100, Arkadiusz Hiler wrote: > > Current version of intel_guc_init_hw() does a lot: > > - cares about submission > > - loads huc > > - implement WA > > > > This change offloads some of the

[Intel-gfx] [bug report] drm/i915: Live testing for context execution

Hello Chris Wilson, The patch 791ff39ae32a: "drm/i915: Live testing for context execution" from Feb 13, 2017, leads to the following static checker warning: drivers/gpu/drm/i915/selftests/i915_gem_context.c:347 igt_ctx_exec() error: 'file' dereferencing possible ERR_PTR()

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Convert intel_tv connector properties to atomic.

Op 13-03-17 om 11:55 schreef Ville Syrjälä: > On Mon, Mar 13, 2017 at 11:38:33AM +0100, Maarten Lankhorst wrote: >> Op 13-03-17 om 10:29 schreef Ville Syrjälä: >>> On Mon, Mar 13, 2017 at 10:22:51AM +0100, Maarten Lankhorst wrote: Op 09-03-17 om 18:36 schreef Ville Syrjälä: > On Thu, Mar

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

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

Re: [Intel-gfx] [10/11] drm/i915/guc: Refactor the concept "GuC context descriptor" into "GuC stage descriptor"

On Fri, Mar 10, 2017 at 08:28:57AM -0800, Oscar Mateo wrote: > A GuC context and a HW context are in no way related, so the name "GuC > context descriptor" > is very unfortunate, because a new reader of the code gets overwhelmed very > quickly with > a lot of things called "context" that refer

Re: [Intel-gfx] [08/11] drm/i915/guc: Wait for doorbell to be inactive before deallocating

On Fri, Mar 10, 2017 at 08:28:55AM -0800, Oscar Mateo wrote: > Doorbell release flow requires that we wait for GEN8_DRB_VALID bit to go > to zero after updating db_status before we call the GuC to release the > doorbell. Does this fix some of the '110' errors? -Chris -- Chris Wilson, Intel Open

[Intel-gfx] [PATCH] drm/i915: Add i810/i815 pci-ids for completeness

To improve our historical record and to simplify userspace that wants to include i915_pciids.h as its canonical breakdown of PCI IDs and their respective generations, include the gen1 ids for i810 and i815. Signed-off-by: Chris Wilson --- include/drm/i915_pciids.h | 8

[Intel-gfx] [PATCH i-g-t] Update MAINTAINERS file

Signed-off-by: Petri Latvala --- Marius has stepped down from being a maintainer a while ago, it's time to make the file match reality. I'd like to take this opportunity to thank Marius for his work and wish him the best in his new endeavours. MAINTAINERS | 1 - 1

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Fix error path for ggtt walk_hole()

== Series Details == Series: drm/i915/selftests: Fix error path for ggtt walk_hole() URL : https://patchwork.freedesktop.org/series/21140/ State : success == Summary == Series 21140v1 drm/i915/selftests: Fix error path for ggtt walk_hole()

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

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

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

Geminilake platform sports a native HDMI 2.0 controller, and is capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec mendates scrambling for these higher clocks, for reduced RF footprint. This patch checks if the monitor supports scrambling, and if required, enables it during the modeset.

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

This patch does following: - Adds a new structure (drm_hdmi_info) in drm_display_info. This structure will be used to save and indicate if sink supports advanced HDMI 2.0 features - Adds another structure drm_scdc within drm_hdmi_info, to reflect scdc support and capabilities in connected

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

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

  1   2   >