[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/dp: DP audio API changes for MST (rev3)

== Series Details == Series: drm/i915/dp: DP audio API changes for MST (rev3) URL : https://patchwork.freedesktop.org/series/10571/ State : failure == Summary == Applying: drm/i915/dp: DP audio API changes for MST fatal: sha1 information is lacking or useless

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: DP audio API changes for MST

On Wed, 2016-08-10 at 17:21 +0300, Ville Syrjälä wrote: > On Tue, Aug 09, 2016 at 01:58:33PM -0700, Dhinakaran Pandiyan wrote: > > DP MST provides the capability to send multiple video and audio streams > > through a single port. This requires the API's between i915 and audio > > drivers to

[Intel-gfx] [PATCH v3] drm/i915/dp: DP audio API changes for MST

DP MST provides the capability to send multiple video and audio streams through a single port. This requires the API's between i915 and audio drivers to distinguish between multiple audio capable displays that can be connected to a port. Currently only the port identity is shared in the APIs. This

Re: [Intel-gfx] Correct DMC version for Skylake (1.23 vs 1.26)

Just FYI: 1.23 with 4.8-rc1 always causes unrecoverable i915 crashes on my machine as soon as X loads (divide error: ). I don't know if it's just my machine, but there already is a bug report about this on Bugzilla. The interesting thing is: patching the kernel to load 1.26 instead of 1.23

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Store number of active engines in device info

== Series Details == Series: drm/i915: Store number of active engines in device info URL : https://patchwork.freedesktop.org/series/10921/ State : failure == Summary == Series 10921v1 drm/i915: Store number of active engines in device info

[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915/guc: Consolidate firmware major-minor to one place (rev2)

== Series Details == Series: drm/i915/guc: Consolidate firmware major-minor to one place (rev2) URL : https://patchwork.freedesktop.org/series/9318/ State : warning == Summary == Series 9318v2 drm/i915/guc: Consolidate firmware major-minor to one place

Re: [Intel-gfx] [PATCH v2 05/15] drm/atmel-hlcdc: Use per-plane rotation property

On Wed, 10 Aug 2016 16:04:37 +0200 Daniel Vetter wrote: > On Wed, Aug 10, 2016 at 01:52:45PM +0200, Boris Brezillon wrote: > > On Wed, 10 Aug 2016 14:41:52 +0300 > > Ville Syrjälä wrote: > > > > > On Wed, Aug 10, 2016 at 11:25:03AM +0200, Boris

[Intel-gfx] ✗ Ro.CI.BAT: failure for Reclassify messages from GuC loader/submission

== Series Details == Series: Reclassify messages from GuC loader/submission URL : https://patchwork.freedesktop.org/series/10918/ State : failure == Summary == Series 10918v1 Reclassify messages from GuC loader/submission http://patchwork.freedesktop.org/api/1.0/series/10918/revisions/1/mbox

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Restore DMC required version for Skylake (1.26) (rev2)

== Series Details == Series: drm/i915: Restore DMC required version for Skylake (1.26) (rev2) URL : https://patchwork.freedesktop.org/series/10889/ State : failure == Summary == Series 10889v2 drm/i915: Restore DMC required version for Skylake (1.26)

Re: [Intel-gfx] Correct DMC version for Skylake (1.23 vs 1.26)

On 10/08/16 11:26, Daniel Vetter wrote: On Tue, Aug 09, 2016 at 10:57:13PM -0700, Rodrigo Vivi wrote: On Tue, Aug 9, 2016 at 1:48 AM, Jani Nikula wrote: On Tue, 09 Aug 2016, Daniel Klaffenbach wrote: Hi, which one is the correct DMC

Re: [Intel-gfx] [PATCH] drm/i915: Store number of active engines in device info

On Wed, Aug 10, 2016 at 04:22:10PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Until now code was calling hweight32 to figure out the > number from device_info->ring_mask at runtime. Instead > we can cache it at engine init time and use directly. And

Re: [Intel-gfx] [PATCH] drm/i915: Store number of active engines in device info

On 10/08/16 16:22, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Until now code was calling hweight32 to figure out the number from device_info->ring_mask at runtime. Instead we can cache it at engine init time and use directly. Signed-off-by: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH 00/20] more drm doc work

On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote: > First part is just a bit of rst fallout to make drm doc builds warning free. > But > then I started to split out parts of drm_crtc into their own files. > framebuffers > and connectors are done, next up on my plans

Re: [Intel-gfx] [PATCH] vgaarbiter: rst-ifiy and polish kerneldoc

On Tue, Aug 9, 2016 at 9:50 AM, Daniel Vetter wrote: > Move the documentation into Documentation/gpu, link it up and pull in > the kernel doc. > > No actual text changes except that I did polish the kerneldoc a bit, > especially for vga_client_register(). > > v2: Remove

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Consolidate firmware major-minor to one place

On 10/08/16 16:16, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Currently to change the firmware one has to update the exported module firmware string and the major-minor versions used for verification after load. Consolidate that to a single place defining correct

Re: [Intel-gfx] [PATCH] drm/i915: Restore DMC file names and the proper 1.26 for SKL.

On 10/08/16 15:41, Rodrigo Vivi wrote: With commit 4aa7fb9c ("drm/i915/dmc: Step away from symbolic links") we started loading the firmware version directly instead of symbolic links. With this VERSION_REQUIRED variables changed the meaning from minimal required to exact version required. Along

[Intel-gfx] [PATCH] drm/i915: Store number of active engines in device info

From: Tvrtko Ursulin Until now code was calling hweight32 to figure out the number from device_info->ring_mask at runtime. Instead we can cache it at engine init time and use directly. Signed-off-by: Tvrtko Ursulin ---

Re: [Intel-gfx] [PATCH 17/20] drm: Update connector documentation

On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote: > - Shuffle docs from drm-kms.rst into the structure docs where it makes > sense. > - Put the remaining bits into a new overview section. > > One thing I've changed is around probing: Old docs says that you > _must_

[Intel-gfx] [PATCH v4 1/4] drm: extra printk() wrapper macros

We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk() provides several other useful intermediate levels such as NOTICE and WARNING. So this patch fills out the set by providing both regular and once-only macros for each of the levels INFO, NOTICE, and WARNING, using a common

[Intel-gfx] [PATCH v4 2/4] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

Where we're going to continue regardless of the problem, rather than fail, then the message should be a WARNing rather than an ERROR. Signed-off-by: Dave Gordon Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_guc_submission.c | 18

Re: [Intel-gfx] [PATCH 19/20] drm: docume drm_display_info

On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote: > We seem to have a bit a mess in how to describe the bus formats, with > a multitude of competing ways. Might be best to consolidate it all and > use MEDIA_BUS_FMT_ also for the hdmi color formats and high color >

[Intel-gfx] [PATCH v2] drm/i915/guc: Consolidate firmware major-minor to one place

From: Tvrtko Ursulin Currently to change the firmware one has to update the exported module firmware string and the major-minor versions used for verification after load. Consolidate that to a single place defining correct major and minor versions per platform. v2:

Re: [Intel-gfx] [PATCH 12/20] drm/doc: Update drm_framebuffer docs

On Tue, Aug 09, 2016 at 03:41:23PM +0200, Daniel Vetter wrote: > - Move the intro section into a DOC comment, and update it slightly. > - kernel-doc for struct drm_framebuffer! > > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/drm-kms.rst | 26 +-- >

[Intel-gfx] [PATCH v4 3/4] drm/i915/guc: revisit GuC loader message levels

Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(), a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(), and one eliminated completely. v2: different permutation of levels :) v3: convert a couple of "this shouldn't happen" messages to WARN() Signed-off-by: Dave Gordon

[Intel-gfx] [PATCH v4 4/4] NOMERGE: re-enable GuC loading and submission by default

Re-enables GuC loading and submission by default on suitable platforms, since it's Intel's Plan of Record that GuC submission shall be used where available. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_params.c | 4 ++-- 1 file changed, 2 insertions(+), 2

[Intel-gfx] [PATCH v4 0/4] Reclassify messages from GuC loader/submission

Various downgrading, upgrading, or general reorganisation of the messages emitted by the GuC code. Mostly: * "can't happen" cases (inconsistencies/misconfiguration) are ERRORs * recoverable (ignored) errors are downgraded to WARNINGs * important auxiliary messages about failure or mode change are

Re: [Intel-gfx] [PATCH 16/20] drm: Don't export dp-aux devnode functions

On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote: > They're only used internally within the dp helpers. Also nuke the > kerneldoc (we only document the driver interface in the drm shared > functions). And move the header file from the public include/ > directory to the

[Intel-gfx] ✗ Fi.CI.BAT: failure for more drm doc work (rev2)

== Series Details == Series: more drm doc work (rev2) URL : https://patchwork.freedesktop.org/series/10844/ State : failure == Summary == LD net/ipv6/ipv6.o CC drivers/acpi/acpica/uterror.o CC drivers/acpi/acpica/uteval.o CC drivers/acpi/acpica/utglobal.o CC

Re: [Intel-gfx] [PATCH 11/20] drm: Extract drm_framebuffer.[hc]

On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote: > Also start with drm_modeset.h with the core bits, since we need > to untangle this mess somehow. That allows us to move the drm_modes.h > include to the right spot, except for the temporary connector status > enum.

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

== Series Details == Series: Finally fix watermarks (rev8) URL : https://patchwork.freedesktop.org/series/10276/ State : failure == Summary == Series 10276v8 Finally fix watermarks http://patchwork.freedesktop.org/api/1.0/series/10276/revisions/8/mbox Test gem_exec_suspend: Subgroup

Re: [Intel-gfx] [PATCH 12/20] drm/doc: Update drm_framebuffer docs

On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote: > - Move the intro section into a DOC comment, and update it slightly. > - kernel-doc for struct drm_framebuffer! > > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/drm-kms.rst | 26

Re: [Intel-gfx] [PATCH 03/20] drm/kms-helpers: Extract drm_modeset_helper.[hc]

On Wed, Aug 10, 2016 at 4:23 PM, Sean Paul wrote: > Is there a reason we create drm_kms_helper.c/h in patch 2 and then > rename it in patch 3? Could you squash this? My own incompetence ;-) It's already squashed here in my tree. -Daniel -- Daniel Vetter Software Engineer,

[Intel-gfx] [PATCH] drm/i915: Restore DMC file names and the proper 1.26 for SKL.

With commit 4aa7fb9c ("drm/i915/dmc: Step away from symbolic links") we started loading the firmware version directly instead of symbolic links. With this VERSION_REQUIRED variables changed the meaning from minimal required to exact version required. Along with this change we started using the

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Fix nesting of rps.mutex and struct_mutex during powersave init

== Series Details == Series: drm/i915: Fix nesting of rps.mutex and struct_mutex during powersave init URL : https://patchwork.freedesktop.org/series/10909/ State : failure == Summary == Series 10909v1 drm/i915: Fix nesting of rps.mutex and struct_mutex during powersave init

[Intel-gfx] [PATCH REBASED v10 4/6] drm/i915/skl: Ensure pipes with changed wms get added to the state

If we're enabling a pipe, we'll need to modify the watermarks on all active planes. Since those planes won't be added to the state on their own, we need to add them ourselves. Signed-off-by: Lyude Reviewed-by: Matt Roper Cc: sta...@vger.kernel.org

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

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

[Intel-gfx] [PATCH REBASED v10 0/6] Finally fix watermarks

Rebased version of https://patchwork.freedesktop.org/series/10276/ . No changes Lyude (5): drm/i915/skl: Add support for the SAGV, fix underrun hangs drm/i915/skl: Update plane watermarks atomically during plane updates drm/i915/skl: Ensure pipes with changed wms get added to the state

[Intel-gfx] [PATCH REBASED v10 2/6] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

From: Matt Roper When we write watermark values to the hardware, those values are stored in dev_priv->wm.skl_hw. However with recent watermark changes, the results structure we're copying from only contains valid watermark and DDB values for the pipes that are

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

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

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

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

[Intel-gfx] [PATCH REBASED v10 2/6] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

From: Matt Roper When we write watermark values to the hardware, those values are stored in dev_priv->wm.skl_hw. However with recent watermark changes, the results structure we're copying from only contains valid watermark and DDB values for the pipes that are

[Intel-gfx] [PATCH REBASED v10 4/6] drm/i915/skl: Ensure pipes with changed wms get added to the state

If we're enabling a pipe, we'll need to modify the watermarks on all active planes. Since those planes won't be added to the state on their own, we need to add them ourselves. Signed-off-by: Lyude Reviewed-by: Matt Roper Cc: sta...@vger.kernel.org

[Intel-gfx] [PATCH REBASED v10 5/6] drm/i915: Move CRTC updating in atomic_commit into it's own hook

Since we have to write ddb allocations at the same time as we do other plane updates, we're going to need to be able to control the order in which we execute modesets on each pipe. The easiest way to do this is to just factor this section of intel_atomic_commit_tail() (intel_atomic_commit() for

[Intel-gfx] [PATCH REBASED v10 3/6] drm/i915/skl: Update plane watermarks atomically during plane updates

Thanks to Ville for suggesting this as a potential solution to pipe underruns on Skylake. On Skylake all of the registers for configuring planes, including the registers for configuring their watermarks, are double buffered. New values written to them won't take effect until said registers are

[Intel-gfx] [PATCH REBASED v10 5/6] drm/i915: Move CRTC updating in atomic_commit into it's own hook

Since we have to write ddb allocations at the same time as we do other plane updates, we're going to need to be able to control the order in which we execute modesets on each pipe. The easiest way to do this is to just factor this section of intel_atomic_commit_tail() (intel_atomic_commit() for

[Intel-gfx] [PATCH REBASED v10 3/6] drm/i915/skl: Update plane watermarks atomically during plane updates

Thanks to Ville for suggesting this as a potential solution to pipe underruns on Skylake. On Skylake all of the registers for configuring planes, including the registers for configuring their watermarks, are double buffered. New values written to them won't take effect until said registers are

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

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

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: DP audio API changes for MST

On Tue, Aug 09, 2016 at 01:58:33PM -0700, Dhinakaran Pandiyan wrote: > DP MST provides the capability to send multiple video and audio streams > through a single port. This requires the API's between i915 and audio > drivers to distinguish between multiple audio capable displays that can be >

[Intel-gfx] [PATCH i-g-t] tools/intel_display_poller: Poll DSPARB across mixed pipe vblank

From: Ville Syrjälä Add another mode which changes the DSPARB registers at specific scanlines, to determine if the individual bits get latches only on the vblank of the relevant pipe, of if other pipes would cause premature latching to happen when their vblank

Re: [Intel-gfx] [PATCH] drm/i915: Fix nesting of rps.mutex and struct_mutex during powersave init

On Wed, Aug 10, 2016 at 01:58:24PM +0100, Chris Wilson wrote: > During intel_gt_powersave_init() we take the RPS mutex to ensure that > all locking requirements are met as we talk to the punit, but we also > require the struct_mutex for allocating a slice of the global GTT for a > power context on

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [CI,v3,1/6] drm/i915: Merge the PPS register definitions

On ke, 2016-08-10 at 12:08 +, Patchwork wrote: > == Series Details == > > Series: series starting with [CI,v3,1/6] drm/i915: Merge the PPS > register definitions > URL   : https://patchwork.freedesktop.org/series/10901/ > State : failure > > == Summary == > > Series 10901v1 Series without

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Record the position of the start of the request

On Wed, Aug 10, 2016 at 03:19:34PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > Not only does it make for good documentation and debugging aide, but it is > > also vital for when we want to unwind requests - such as when throwing away > > an incomplete

[Intel-gfx] [PATCH] drm/i915: Fix nesting of rps.mutex and struct_mutex during powersave init

During intel_gt_powersave_init() we take the RPS mutex to ensure that all locking requirements are met as we talk to the punit, but we also require the struct_mutex for allocating a slice of the global GTT for a power context on Valleyview. struct_mutex must be the outer lock here, as we nest

[Intel-gfx] [CI 2/2] drm/i915: Move setting of request->batch into its single callsite

request->batch_obj is only set by execbuffer for the convenience of debugging hangs. By moving that operation to the callsite, we can simplify all other callers and future patches. We also move the complications of reference handling of the request->batch_obj next to where the active tracking is

[Intel-gfx] [CI 1/2] drm/i915: Mark unmappable GGTT entries as PIN_HIGH

We allocate a few objects into the GGTT that we never need to access via the mappable aperture (such as contexts, status pages). We can request that these are bound high in the VM to increase the amount of mappable aperture available. However, anything that may be frequently pinned (such as

Re: [Intel-gfx] [PATCH] drm/i915: Restore DMC required version for Skylake (1.26)

On ke, 2016-08-10 at 12:26 +0100, Dave Gordon wrote: > On 10/08/16 06:57, Rodrigo Vivi wrote: > > With commit 4aa7fb9c ("drm/i915/dmc: Step away from symbolic > > links") we started loading the firmware version directly > > instead of symbolic links. > > However the pathnames in the patch context

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Handle fb->offsets[] and rewrite fb rotation handling to be more generic (v5)

On Wed, Aug 10, 2016 at 11:46:25AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Handle fb->offsets[] and rewrite fb rotation handling to be > more generic (v5) > URL : https://patchwork.freedesktop.org/series/10895/ > State : failure > > == Summary == > > Series

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/9] drm/i915: Cache kmap between relocations

== Series Details == Series: series starting with [1/9] drm/i915: Cache kmap between relocations URL : https://patchwork.freedesktop.org/series/10904/ State : failure == Summary == Applying: drm/i915: Cache kmap between relocations fatal: sha1 information is lacking or useless

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Cleanup DisplayPort AUX channel initialization

== Series Details == Series: drm/i915: Cleanup DisplayPort AUX channel initialization URL : https://patchwork.freedesktop.org/series/10902/ State : failure == Summary == Series 10902v1 drm/i915: Cleanup DisplayPort AUX channel initialization

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Record the position of the start of the request

Chris Wilson writes: > Not only does it make for good documentation and debugging aide, but it is > also vital for when we want to unwind requests - such as when throwing away > an incomplete request. > > Signed-off-by: Chris Wilson > Link: >

Re: [Intel-gfx] [PATCH] drm/i915: Acquire audio powerwell for HD-Audio registers

Hi, On 04-08-16 23:03, Takashi Iwai wrote: [dropped stable ML and add a few other relevant people to Cc] On Thu, 04 Aug 2016 20:05:27 +0200, Takashi Iwai wrote: On Thu, 04 Aug 2016 18:44:11 +0200, Daniel Vetter wrote: On Wed, Aug 03, 2016 at 05:09:00PM +0100, Chris Wilson wrote: On

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [CI,v3,1/6] drm/i915: Merge the PPS register definitions

== Series Details == Series: series starting with [CI,v3,1/6] drm/i915: Merge the PPS register definitions URL : https://patchwork.freedesktop.org/series/10901/ State : failure == Summary == Series 10901v1 Series without cover letter

Re: [Intel-gfx] [PATCH 09/20] drm/kms: Nuke dirty_info property

On 08/09/2016 04:08 PM, Daniel Vetter wrote: > On Tue, Aug 9, 2016 at 3:59 PM, Thomas Hellstrom > wrote: >> Hmm. >> >> I don't have a strong opinion on this, but IMO the original idea of >> allowing a user-space driver to optimize away the dirty calls isn't a >> bad one.

Re: [Intel-gfx] [PATCH v2 05/15] drm/atmel-hlcdc: Use per-plane rotation property

On Wed, 10 Aug 2016 13:52:45 +0200 Boris Brezillon wrote: > On Wed, 10 Aug 2016 14:41:52 +0300 > Ville Syrjälä wrote: > > > On Wed, Aug 10, 2016 at 11:25:03AM +0200, Boris Brezillon wrote: > > > On Wed, 10 Aug 2016 12:09:41

[Intel-gfx] [PATCH 5/9] drm/i915: Pin the pages first in shmem prepare read/write

There is an improbable, but not impossible, case that if we leave the pages unpin as we operate on the object, then somebody may steal the lock and change the cache domains after we have already inspected them. (Whilst here, avail ourselves of the opportunity to take a couple of steps to make the

[Intel-gfx] [PATCH 8/9] drm/i915: Fallback to single page GTT mmappings for relocations

If we cannot pin the entire object into the mappable region of the GTT, try to pin a single page instead. This is much more likely to succeed, and prevents us falling back to the clflush slow path. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 7/9] drm/i915: Refactor execbuffer relocation writing

With in the introduction of the reloc page cache, we are just one step away from refactoring the relocation write functions into one. Not only does it tidy the code (slightly), but it greatly simplifies the control logic much to gcc's satisfaction. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 3/9] drm/i915: Before accessing an object via the cpu, flush GTT writes

If we want to read the pages directly via the CPU, we have to be sure that we have to flush the writes via the GTT (as the CPU can not see the address aliasing). Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 4 1 file changed, 4 insertions(+)

[Intel-gfx] [PATCH 2/9] drm/i915: Extract i915_gem_obj_prepare_shmem_write()

This is a companion to i915_gem_obj_prepare_shmem_read() that prepares the backing storage for direct writes. It first serialises with the GPU, pins the backing storage and then indicates what clfushes are required in order for the writes to be coherent. Whilst here, fix support for ancient CPUs

[Intel-gfx] Small execbuf coherency fixes

Execbuf suffers from a coherency problem which in theory is handled by the prepare for direct access implemented by pwrite. The issue being not only is that function non-existent (implemented inline for pwrite) it is missing a barrier or two. -Chris ___

[Intel-gfx] [PATCH 4/9] drm/i915: Wait for writes through the GTT to land before reading back

If we quickly switch from writing through the GTT to a read of the physical page directly with the CPU (e.g. performing relocations through the GTT and then running the command parser), we can observe that the writes are not visible to the CPU. It is not a coherency problem, as extensive

[Intel-gfx] [PATCH 9/9] drm/i915: Disallow direct CPU access to stolen pages for relocations

As we cannot access the backing pages behind stolen objects, we should not attempt to do so for relocations. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

[Intel-gfx] [PATCH 1/9] drm/i915: Cache kmap between relocations

When doing relocations, we have to obtain a mapping to the page containing the target address. This is either a kmap or iomap depending on GPU and its cache coherency. Neighbouring relocation entries are typically within the same page and so we can cache our kmapping between them and avoid those

[Intel-gfx] [PATCH 6/9] drm/i915: Tidy up flush cpu/gtt write domains

Since we know the write domain, we can drop the local variable and make the code look a tiny bit simpler. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 15 --- 1 file changed, 4 insertions(+), 11 deletions(-) diff --git

Re: [Intel-gfx] [PATCH v2 05/15] drm/atmel-hlcdc: Use per-plane rotation property

On Wed, 10 Aug 2016 14:41:52 +0300 Ville Syrjälä wrote: > On Wed, Aug 10, 2016 at 11:25:03AM +0200, Boris Brezillon wrote: > > On Wed, 10 Aug 2016 12:09:41 +0300 > > Ville Syrjälä wrote: > > > > > On Wed, Aug 10, 2016 at

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Handle fb->offsets[] and rewrite fb rotation handling to be more generic (v5)

== Series Details == Series: drm/i915: Handle fb->offsets[] and rewrite fb rotation handling to be more generic (v5) URL : https://patchwork.freedesktop.org/series/10895/ State : failure == Summary == Series 10895v1 drm/i915: Handle fb->offsets[] and rewrite fb rotation handling to be more

Re: [Intel-gfx] [PATCH v2 05/15] drm/atmel-hlcdc: Use per-plane rotation property

On Wed, Aug 10, 2016 at 11:25:03AM +0200, Boris Brezillon wrote: > On Wed, 10 Aug 2016 12:09:41 +0300 > Ville Syrjälä wrote: > > > On Wed, Aug 10, 2016 at 10:35:22AM +0200, Boris Brezillon wrote: > > > Hi Ville, > > > > > > On Fri, 22 Jul 2016 18:47:01 +0300 > > >

[Intel-gfx] [PATCH] drm/i915: Cleanup DisplayPort AUX channel initialization

Let's remove reference to "struct intel_connector *connector" from intel_dp_aux_init() function as it is no longer required. Signed-off-by: Mika Kahola --- drivers/gpu/drm/i915/intel_dp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [Intel-gfx] [PATCH v2 12/12] drm/i915: Make sure fb offset is (macro)pixel aligned

On Wed, Aug 10, 2016 at 02:02:43PM +0300, Ville Syrjälä wrote: > On Wed, Aug 10, 2016 at 12:04:32PM +0200, Daniel Vetter wrote: > > On Wed, Aug 10, 2016 at 12:23:21PM +0300, ville.syrj...@linux.intel.com > > wrote: > > > From: Ville Syrjälä > > > > > > We convert

Re: [Intel-gfx] [PATCH 33/33] drm/i915: Compress GPU objects in error state

On ke, 2016-08-10 at 11:52 +0100, Chris Wilson wrote: > On Wed, Aug 10, 2016 at 01:32:29PM +0300, Joonas Lahtinen wrote: > > > > On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote: > > > > > > @@ -309,12 +310,30 @@ void i915_error_printf(struct > > > drm_i915_error_state_buf *e, const char

Re: [Intel-gfx] [PATCH v2 11/12] drm/i915: Deal with NV12 CbCr plane AUX surface on SKL+

On Wed, Aug 10, 2016 at 12:03:08PM +0200, Daniel Vetter wrote: > On Wed, Aug 10, 2016 at 12:23:20PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > With NV12 we have two color planes to deal with so we must compute the > > surface and

Re: [Intel-gfx] [PATCH] drm/i915: Restore DMC required version for Skylake (1.26)

On 10/08/16 06:57, Rodrigo Vivi wrote: With commit 4aa7fb9c ("drm/i915/dmc: Step away from symbolic links") we started loading the firmware version directly instead of symbolic links. However the pathnames in the patch context below are still the symlink names -- is this correct? Or did some

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Restore DMC required version for Skylake (1.26)

== Series Details == Series: drm/i915: Restore DMC required version for Skylake (1.26) URL : https://patchwork.freedesktop.org/series/10889/ State : failure == Summary == Series 10889v1 drm/i915: Restore DMC required version for Skylake (1.26)

Re: [Intel-gfx] [PATCH 08/12] drm/i915: Allow calling intel_adjust_tile_offset() multiple times

On Wed, Aug 10, 2016 at 11:48:56AM +0200, Daniel Vetter wrote: > On Wed, Aug 10, 2016 at 12:23:17PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Minimize the resulting X coordinate after intel_adjust_tile_offset() is > > done with

[Intel-gfx] [PATCH CI v3 2/6] drm/i915: Merge TARGET_POWER_ON and PANEL_POWER_ON flag definitions

These two flags mean the same thing, so remove the duplication. Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_reg.h | 1 - drivers/gpu/drm/i915/intel_dp.c | 6 +++--- drivers/gpu/drm/i915/intel_lvds.c |

[Intel-gfx] [PATCH CI v3 6/6] drm/i915: Remove LVDS and PPS suspend time save/restore

In the preceeding patches we made sure that: - the LVDS encoder takes care of reiniting both the LVDS register and its PPS - the eDP encoder takes care of reiniting its PPS - the PPS register unlocking workaround is applied explicitly whenever the PPS context is lost Based on the above we can

[Intel-gfx] [PATCH CI v3 5/6] drm/i915: Apply the PPS register unlock workaround more consistently

Atm, we apply this workaround somewhat inconsistently at the following points: driver loading, LVDS init, eDP PPS init, system resume. As this workaround also affects registers other than PPS (timing, PLL) a more consistent way is to apply it early after the PPS HW context is known to be lost:

[Intel-gfx] [PATCH CI v3 4/6] drm/i915/dp: Restore PPS HW state from the encoder resume hook

Similarly to the previous patch, initialize the PPS from the DP encoder's resume hook. Note that as opposed to LVDS we can't do this during encoder enabling, since we need the PPS for DP detection as well. The PPS init code is now the same for init and resume, so factor out a new

[Intel-gfx] [PATCH CI v3 3/6] drm/i915/lvds: Restore initial HW state during encoder enabling

Atm the LVDS encoder depends on the PPS HW context being saved/restored from generic suspend/resume code. Since the PPS is specific to the LVDS and eDP encoders a cleaner way is to reinitialize it during encoder enabling, so do this here for LVDS. Follow-up patches will init the PPS for the eDP

[Intel-gfx] [PATCH CI v3 1/6] drm/i915: Merge the PPS register definitions

The PPS registers are pretty much the same everywhere, the differences being: - Register fields appearing, disappearing from one platform to the next: panel-reset-on-powerdown, backlight-on, panel-port, register-unlock - Different register base addresses - Different number of PPS instances: 2

Re: [Intel-gfx] [PATCH v2 12/12] drm/i915: Make sure fb offset is (macro)pixel aligned

On Wed, Aug 10, 2016 at 12:04:32PM +0200, Daniel Vetter wrote: > On Wed, Aug 10, 2016 at 12:23:21PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > We convert the fb->offsets[] into x/y offsets, so they must be > > (macro)pixel aligned.

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Fix braces in conditonal branches

== Series Details == Series: drm/i915: Fix braces in conditonal branches URL : https://patchwork.freedesktop.org/series/10875/ State : failure == Summary == Series 10875v1 drm/i915: Fix braces in conditonal branches http://patchwork.freedesktop.org/api/1.0/series/10875/revisions/1/mbox Test

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

On ke, 2016-08-10 at 12:13 +0200, Daniel Vetter wrote: > On Wed, Aug 10, 2016 at 12:12:37PM +0200, Daniel Vetter wrote: > > > > On Tue, Aug 09, 2016 at 10:05:30AM +0100, Chris Wilson wrote: > > > > > > On Tue, Aug 09, 2016 at 11:48:56AM +0300, Joonas Lahtinen wrote: > > > > > > > > On ti,

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

On ma, 2016-08-08 at 10:09 +0100, Chris Wilson wrote: > On Mon, Aug 08, 2016 at 12:01:07PM +0300, Joonas Lahtinen wrote: > > > > On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote: > > > +++ b/drivers/gpu/drm/i915/i915_drv.h > > > @@ -3903,4 +3903,6 @@ static inline bool > > >

Re: [Intel-gfx] [PATCH 32/33] drm/i915: Consolidate error object printing

On ti, 2016-08-09 at 12:53 +0100, Chris Wilson wrote: > On Tue, Aug 09, 2016 at 02:44:41PM +0300, Joonas Lahtinen wrote: > > > > On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote: > > > @@ -446,15 +458,7 @@ int i915_error_state_to_str(struct > > > drm_i915_error_state_buf *m, > > >  

Re: [Intel-gfx] [PATCH 18/33] drm/i915: Use VMA as the primary object for context state

On ke, 2016-08-10 at 09:25 +0100, Chris Wilson wrote: > On Wed, Aug 10, 2016 at 11:03:39AM +0300, Joonas Lahtinen wrote: > > > > On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote: > > > > > > - if (!i915_gem_obj_ggtt_bound(ctx_obj)) > > > - seq_puts(m, "\tNot bound in GGTT\n"); > > >

Re: [Intel-gfx] [PATCH 33/33] drm/i915: Compress GPU objects in error state

On Wed, Aug 10, 2016 at 01:32:29PM +0300, Joonas Lahtinen wrote: > On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote: > > @@ -309,12 +310,30 @@ void i915_error_printf(struct > > drm_i915_error_state_buf *e, const char *f, ...) > >   va_end(args); > >  } > >   > > +static bool > >

Re: [Intel-gfx] [PATCH 05/33] drm/i915: Reduce amount of duplicate buffer information captured on error

On ke, 2016-08-10 at 09:36 +0100, Chris Wilson wrote: > On Wed, Aug 10, 2016 at 11:07:46AM +0300, Joonas Lahtinen wrote: > > > > On ke, 2016-08-10 at 08:15 +0100, Chris Wilson wrote: > > > > > > On Wed, Aug 10, 2016 at 10:04:16AM +0300, Joonas Lahtinen wrote: > > > > > > > > > > > > On su,

Re: [Intel-gfx] [PATCH 19/33] drm/i915: Only clflush the context object when binding

On ke, 2016-08-10 at 10:02 +0100, Chris Wilson wrote: > On Wed, Aug 10, 2016 at 11:41:39AM +0300, Joonas Lahtinen wrote: > > > > On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote: > > > > > > @@ -771,6 +771,13 @@ static int do_rcs_switch(struct drm_i915_gem_request > > > *req) > > >   if

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/dp: DP audio API changes for MST (rev2)

== Series Details == Series: drm/i915/dp: DP audio API changes for MST (rev2) URL : https://patchwork.freedesktop.org/series/10571/ State : failure == Summary == Applying: drm/i915/dp: DP audio API changes for MST fatal: sha1 information is lacking or useless

  1   2   >