Re: [Intel-gfx] [PATCH v2 01/14] drm/i915: Keep a global seqno per-engine

On Thu, Feb 16, 2017 at 08:10:07AM +, Tvrtko Ursulin wrote: > > On 15/02/2017 21:49, Chris Wilson wrote: > >On Wed, Feb 15, 2017 at 05:05:40PM +, Tvrtko Ursulin wrote: > >> > >>On 14/02/2017 09:54, Chris Wilson wrote: > >>>Replace the global device seqno with one for each engine, and

Re: [Intel-gfx] [PATCH v2 01/14] drm/i915: Keep a global seqno per-engine

On 15/02/2017 21:49, Chris Wilson wrote: On Wed, Feb 15, 2017 at 05:05:40PM +, Tvrtko Ursulin wrote: On 14/02/2017 09:54, Chris Wilson wrote: Replace the global device seqno with one for each engine, and account for in-flight seqno on each separately. This is consistent with dma-fence as

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Consolidate gen8_emit_pipe_control

On Thu, Feb 16, 2017 at 07:53:13AM +, Tvrtko Ursulin wrote: > > On 15/02/2017 16:33, Chris Wilson wrote: > >On Wed, Feb 15, 2017 at 04:06:34PM +, Tvrtko Ursulin wrote: > >>+static inline u32 *gen8_emit_pipe_control(u32 *batch, u32 flags, u32 > >>offset) > >>+{ > >>+ static const u32

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Tidy workaround batch buffer emission

On Thu, Feb 16, 2017 at 07:59:30AM +, Tvrtko Ursulin wrote: > > On 15/02/2017 21:18, Chris Wilson wrote: > >Reviewed-by: Chris Wilson > > Thanks. So you think it is worth it? Yes. As you say, it brings it into line with the rest of the command emission sequences -

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: VLV/CHV two-stage watermarks (rev2)

== Series Details == Series: drm/i915: VLV/CHV two-stage watermarks (rev2) URL : https://patchwork.freedesktop.org/series/16712/ State : success == Summary == Series 16712v2 drm/i915: VLV/CHV two-stage watermarks https://patchwork.freedesktop.org/api/1.0/series/16712/revisions/2/mbox/

[Intel-gfx] [PATCH] i915/drm/HuC: Motivation behind having HuC

Correct the comment in intel_huc.c that tells the motivation behind having HuC, a dedicated firmware for media. Cc: Lyncoln Cheng Cc: Rodrigo Vivi Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/intel_huc.c |

[Intel-gfx] [PATCH] drm/i915: DMC 1.03 for Geminilake

There is a new version of DMC available for Geminilake. It's release notes only mention: - Enhancement in the FW to restore the PG2 state v2: Fixed the platform name on commit message. Noticed by Jani S. v3: cook on top of drm-tip without depending on kbl one so CI can check. v4: make v3

[Intel-gfx] ✓ Fi.CI.BAT: success for i915/drm/HuC: Motivation behind having HuC (rev2)

== Series Details == Series: i915/drm/HuC: Motivation behind having HuC (rev2) URL : https://patchwork.freedesktop.org/series/19746/ State : success == Summary == Series 19746v2 i915/drm/HuC: Motivation behind having HuC https://patchwork.freedesktop.org/api/1.0/series/19746/revisions/2/mbox/

Re: [Intel-gfx] [PULL] drm-misc-next-fixes, take 2

On 16 February 2017 at 19:49, Jani Nikula wrote: > > Hi Dave, this one superseeds [1]. Better to flush out the single uapi > fix for v4.11 now so it's not forgotten. Looks like I had already pulled, I just reverted Maarten's patch on top of drm-next. Dave.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Add DPCD definitions for DP 1.4 DSC feature (rev3)

== Series Details == Series: drm: Add DPCD definitions for DP 1.4 DSC feature (rev3) URL : https://patchwork.freedesktop.org/series/19666/ State : success == Summary == Series 19666v3 drm: Add DPCD definitions for DP 1.4 DSC feature

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: DMC 1.03 for Geminilake (rev5)

== Series Details == Series: drm/i915: DMC 1.03 for Geminilake (rev5) URL : https://patchwork.freedesktop.org/series/19081/ State : success == Summary == Series 19081v5 drm/i915: DMC 1.03 for Geminilake https://patchwork.freedesktop.org/api/1.0/series/19081/revisions/5/mbox/ fi-bdw-5557u

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Keep the ctx_pool_vaddr mapped, for easy access

On Thu, Feb 16, 2017 at 06:15:05AM -0800, Oscar Mateo wrote: > static void guc_ctx_desc_init(struct intel_guc *guc, > struct i915_guc_client *client) > { > struct drm_i915_private *dev_priv = guc_to_i915(guc); > struct intel_engine_cs *engine; >

[Intel-gfx] [PATCH v2] drm/i915/guc: Keep the ctx_pool_vaddr mapped, for easy access

The GuC descriptor is big in size. If we use a local definition of guc_desc we have a chance to overflow stack, so avoid it. Also, Chris abhors scatterlists :) v2: Rebased, helper function to retrieve the context descriptor, s/ctx_pool_vma/ctx_pool/ Signed-off-by: Oscar Mateo

[Intel-gfx] [PATCH i-g-t] tools/intel_guc_logger: Fix the assert for the verbosity level

I guess no one has needed to change the verbosity level of the GuC logs. Signed-off-by: Oscar Mateo --- tools/intel_guc_logger.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/intel_guc_logger.c b/tools/intel_guc_logger.c index 159a54e..c9ea60d

[Intel-gfx] [PATCH v2] drm: Add DPCD definitions for DP 1.4 DSC feature

Display stream compression is supported on DP 1.4 DP devices. This patch adds the corersponding DPCD register definitions for DSC. v2: * Rebased on drm-tip Signed-off-by: Manasi Navare Cc: Jani Nikula Cc: Paulo Zanoni

[Intel-gfx] [PATCH] drm/i915/guc: Add onion teardown to the GuC setup

Starting with intel_guc_loader, down to intel_guc_submission and finally to intel_guc_log. Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/i915_guc_submission.c | 94 + drivers/gpu/drm/i915/intel_guc_loader.c| 19 +- drivers/gpu/drm/i915/intel_guc_log.c

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Keep the ctx_pool_vaddr mapped, for easy access

Onion teardown in a separate patch (since it addresses a separate problem). On 02/16/2017 06:15 AM, Oscar Mateo wrote: The GuC descriptor is big in size. If we use a local definition of guc_desc we have a chance to overflow stack, so avoid it. Also, Chris abhors scatterlists :) v2: Rebased,

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for GLK MIPI DSI VIDEO MODE PATCHES (rev5)

> -Original Message- > From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > Sent: Thursday, February 16, 2017 11:45 PM > To: Chauhan, Madhav ; Patchwork > > Cc: intel-gfx@lists.freedesktop.org > Subject: RE: [Intel-gfx] ✗

Re: [Intel-gfx] [GLK MIPI DSI V5 3/8] drm/i915/glk: Add MIPIIO Enable/disable sequence

> -Original Message- > From: Nikula, Jani > Sent: Thursday, February 16, 2017 8:38 PM > To: Chauhan, Madhav ; intel- > g...@lists.freedesktop.org > Cc: Conselvan De Oliveira, Ander ; > Shankar, Uma ;

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Make int __intel_ring_space static

On Thu, Feb 16, 2017 at 12:23:21PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > It is only used within intel_ringbuffer.c > > Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson -Chris -- Chris

Re: [Intel-gfx] [PATCH v2] drm/i915: Break i915_spin_request() if we see an interrupt

On 16/02/2017 13:42, Chris Wilson wrote: If an interrupt has been posted, and we were spinning on the active seqno waiting for it to advance but it did not, then we can expect that it will not see its advance in the immediate future and should call into the irq-seqno barrier. We can stop

[Intel-gfx] [PATCH] lib/igt_kms: Fix regression on kms_plane_lowres test

kms_plane_lowres subtest pipe-C-tiling-none crashes when reading out number of crtc. This patch fixes the bug on crtc readout. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99653 Fixes: 9de635976c426b4c835083792c7d4d6e32aec615 ("lib/igt_kms: Avoid depencency on static plane

Re: [Intel-gfx] [PATCH v2] drm/i915: Unwind conversion to i915_gem_phys_ops on failure

Chris Wilson writes: > The physical object is treated as permanently pinned. If we fail to take > this initial pin during i915_gem_object_attach_phys() we need to revert > it back to an ordinary shmemfs object before reporting the failure. > > v2: git-add > >

[Intel-gfx] [PATCH] drm/i915: Squelch any ktime/jiffie rounding errors for wait-ioctl

We wait upon jiffies, but report the time elapsed using a high-resolution timer. This discrepancy can lead to us timing out the wait prior to us reporting the elapsed time as complete. This restores the squelching lost in commit e95433c73a11 ("drm/i915: Rearrange i915_wait_request() accounting

Re: [Intel-gfx] [PATCH] drm/i915: Break i915_spin_request() if we see an interrupt

On 16/02/2017 13:17, Mika Kuoppala wrote: Chris Wilson writes: If an interrupt has been posted, and we were spinning on the active seqno waiting for it to advance but it did not, then we can expect that it will not see its advance in the immediate future Why we

[Intel-gfx] [PATCH v4 1/2] drm/i915: Tidy workaround batch buffer emission

From: Tvrtko Ursulin Use the "*batch++ = " style as in the ring emission for better readability and also simplify the logic a bit by consolidating the offset and size calculations and overflow checking. The latter is a programming error so it is not required to check

[Intel-gfx] [PATCH 2/2] drm/i915: Break i915_spin_request() if we see an interrupt

If an interrupt has been posted, and we were spinning on the active seqno waiting for it to advance but it did not, then we can expect that it will not see its advance in the immediate future and should call into the irq-seqno barrier. We can stop spinning at this point, and leave the difficulty

[Intel-gfx] [PATCH 1/2] drm/i915: Postpone fake breadcrumb interrupt until real interrupts cease

When the timer expires for checking on interrupt processing, check to see if any interrupts arrived within the last time period. If real interrupts are still being delivered, we can be reassured that we haven't missed the final interrupt as the waiter will still be woken. Only once all activity

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Postpone fake breadcrumb interrupt until real interrupts cease

On Thu, Feb 16, 2017 at 02:22:52PM +, Chris Wilson wrote: > When the timer expires for checking on interrupt processing, check to > see if any interrupts arrived within the last time period. If real > interrupts are still being delivered, we can be reassured that we > haven't missed the final

[Intel-gfx] ✗ Fi.CI.BAT: warning for Enable IPC & WM related WA's (rev3)

== Series Details == Series: Enable IPC & WM related WA's (rev3) URL : https://patchwork.freedesktop.org/series/18842/ State : warning == Summary == Series 18842v3 Enable IPC & WM related WA's https://patchwork.freedesktop.org/api/1.0/series/18842/revisions/3/mbox/ Test core_prop_blob:

[Intel-gfx] [PATCH] drm/i915: Break i915_spin_request() if we see an interrupt

If an interrupt has been posted, and we were spinning on the active seqno waiting for it to advance but it did not, then we can expect that it will not see its advance in the immediate future and should call into the irq-seqno barrier. We can stop spinning at this point, and leave the difficulty

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Tidy workaround batch buffer emission

On 16/02/2017 13:20, Chris Wilson wrote: On Thu, Feb 16, 2017 at 12:23:24PM +, Tvrtko Ursulin wrote: + /* +* Emit the two workaround batch buffers, recording the offset from the +* start of the workaround batch buffer object for each and their +* respective

[Intel-gfx] [PATCH v2] drm/i915: Break i915_spin_request() if we see an interrupt

If an interrupt has been posted, and we were spinning on the active seqno waiting for it to advance but it did not, then we can expect that it will not see its advance in the immediate future and should call into the irq-seqno barrier. We can stop spinning at this point, and leave the difficulty

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

== Series Details == Series: drm/i915: Support HDMI EDID injection (rev3) URL : https://patchwork.freedesktop.org/series/3007/ State : success == Summary == Series 3007v3 drm/i915: Support HDMI EDID injection https://patchwork.freedesktop.org/api/1.0/series/3007/revisions/3/mbox/

Re: [Intel-gfx] [PATCH v2] drm/i915: Break i915_spin_request() if we see an interrupt

Chris Wilson writes: > If an interrupt has been posted, and we were spinning on the active > seqno waiting for it to advance but it did not, then we can expect that > it will not see its advance in the immediate future and should call into > the irq-seqno barrier. We

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2] drm/i915: Remove struct_mutex for destroying framebuffers (rev2)

== Series Details == Series: series starting with [v2] drm/i915: Remove struct_mutex for destroying framebuffers (rev2) URL : https://patchwork.freedesktop.org/series/19692/ State : success == Summary == Series 19692v2 Series without cover letter

[Intel-gfx] ✓ Fi.CI.BAT: success for Moving the common engine/ring code to intel_engine_cs.c (rev2)

== Series Details == Series: Moving the common engine/ring code to intel_engine_cs.c (rev2) URL : https://patchwork.freedesktop.org/series/19706/ State : success == Summary == Series 19706v2 Moving the common engine/ring code to intel_engine_cs.c

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Move common workaround code to intel_engine_cs

On Thu, Feb 16, 2017 at 12:23:23PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > It is used by all submission backends. > > Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson > +int

Re: [Intel-gfx] [PATCH] drm/i915: Break i915_spin_request() if we see an interrupt

Chris Wilson writes: > If an interrupt has been posted, and we were spinning on the active > seqno waiting for it to advance but it did not, then we can expect that > it will not see its advance in the immediate future Why we can expect this? -Mika > and should call

Re: [Intel-gfx] [PATCH] drm/i915: Break i915_spin_request() if we see an interrupt

On Thu, Feb 16, 2017 at 03:17:30PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > If an interrupt has been posted, and we were spinning on the active > > seqno waiting for it to advance but it did not, then we can expect that > > it will not see its advance in

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/glk: CDCLK calculation changes for glk (rev2)

== Series Details == Series: drm/i915/glk: CDCLK calculation changes for glk (rev2) URL : https://patchwork.freedesktop.org/series/19226/ State : success == Summary == Series 19226v2 drm/i915/glk: CDCLK calculation changes for glk

Re: [Intel-gfx] [PATCH] drm/i915: Squelch any ktime/jiffie rounding errors for wait-ioctl

On to, 2017-02-16 at 12:54 +, Chris Wilson wrote: > We wait upon jiffies, but report the time elapsed using a > high-resolution timer. This discrepancy can lead to us timing out the > wait prior to us reporting the elapsed time as complete. > > This restores the squelching lost in commit

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Drop struct_mutex around frontbuffer flushes

On ke, 2017-02-15 at 10:59 +, Chris Wilson wrote: > Since the frontbuffer has self-contained locking, it does not require us > to hold the BKL struct_mutex as we send invalidate and flush messages. > > Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

Re: [Intel-gfx] [PATCH 2/3] drm/i915: struct_mutex is not required for allocating the framebuffer

On ke, 2017-02-15 at 10:59 +, Chris Wilson wrote: > We do not need the BKL struct_mutex in order to allocate a GEM object, > nor to create the framebuffer, so resist the temptation to take the BKL > willy nilly. As this changes the locking contract around internal API > calls, the patch is a

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Simplify cleanup path in intel_engines_init

On Thu, Feb 16, 2017 at 12:23:22PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > We can call the engine cleanup vfunc instead of duplicating the > decision making here. > > Signed-off-by: Tvrtko Ursulin Ok, but

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Tidy workaround batch buffer emission

On Thu, Feb 16, 2017 at 12:23:24PM +, Tvrtko Ursulin wrote: > + /* > + * Emit the two workaround batch buffers, recording the offset from the > + * start of the workaround batch buffer object for each and their > + * respective sizes. > + */ > + for (i = 0; i <

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Tidy workaround batch buffer emission

On Thu, Feb 16, 2017 at 01:23:51PM +, Tvrtko Ursulin wrote: > > On 16/02/2017 13:20, Chris Wilson wrote: > >On Thu, Feb 16, 2017 at 12:23:24PM +, Tvrtko Ursulin wrote: > >>+ /* > >>+* Emit the two workaround batch buffers, recording the offset from the > >>+* start of the

Re: [Intel-gfx] [PATCH] drm/i915: Break i915_spin_request() if we see an interrupt

On Thu, Feb 16, 2017 at 01:26:58PM +, Tvrtko Ursulin wrote: > > > On 16/02/2017 13:17, Mika Kuoppala wrote: > >Chris Wilson writes: > > > >>If an interrupt has been posted, and we were spinning on the active > >>seqno waiting for it to advance but it did not, then

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Tidy workaround batch buffer emission

On 16/02/2017 13:28, Chris Wilson wrote: On Thu, Feb 16, 2017 at 01:23:51PM +, Tvrtko Ursulin wrote: On 16/02/2017 13:20, Chris Wilson wrote: On Thu, Feb 16, 2017 at 12:23:24PM +, Tvrtko Ursulin wrote: + /* +* Emit the two workaround batch buffers, recording the offset

[Intel-gfx] [PATCH v5 1/2] drm/i915: Tidy workaround batch buffer emission

From: Tvrtko Ursulin Use the "*batch++ = " style as in the ring emission for better readability and also simplify the logic a bit by consolidating the offset and size calculations and overflow checking. The latter is a programming error so it is not required to check

Re: [Intel-gfx] [PATCH v5 1/2] drm/i915: Tidy workaround batch buffer emission

On Thu, Feb 16, 2017 at 01:54:02PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Use the "*batch++ = " style as in the ring emission for better > readability and also simplify the logic a bit by consolidating > the offset and size calculations and overflow

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Store aux power domain in intel_dp

On Fri, Feb 10, 2017 at 03:29:54PM +0200, Ander Conselvan de Oliveira wrote: > The aux power domain only makes sense in the DP code. Storing it in > struct intel_dp avoids some indirection. > > v2: Rebase > Signed-off-by: Ander Conselvan de Oliveira > >

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Call the sync_hw hook for power wells without a domain

On Wed, 2017-02-15 at 13:59 +0200, Imre Deak wrote: > So far the sync_hw hook wasn't called for power wells not belonging to > any power domain, that is the GEN9 PW1 and MISC_IO power wells. This > wasn't a problem so far since the goal of the sync_hw hook - to clear > the corresponding BIOS

[Intel-gfx] [PULL] drm-misc-next-fixes, take 2

Hi Dave, this one superseeds [1]. Better to flush out the single uapi fix for v4.11 now so it's not forgotten. BR, Jani. [1] 87mvdnpnix.fsf@intel.com">http://mid.mail-archive.com/87mvdnpnix.fsf@intel.com The following changes since commit 13f62f54d174d3417c3caaafedf5e22a0a03e442: Merge

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/1] drm/i915: Do RPM Wake during GuC/HuC status read

On 03/02/2017 08:54, Patchwork wrote: == Series Details == Series: series starting with [v2,1/1] drm/i915: Do RPM Wake during GuC/HuC status read URL : https://patchwork.freedesktop.org/series/19037/ State : success == Summary == Series 19037v1 Series without cover letter

Re: [Intel-gfx] [PATCH 3/6] drm/i915/glk: Implement WaDDIIOTimeout

On Fri, Feb 10, 2017 at 03:29:56PM +0200, Ander Conselvan de Oliveira wrote: > Implement WaDDIIOTimeout to avoid a timeout when enabling the DDI IO > power domains. > > Signed-off-by: Ander Conselvan de Oliveira > Reviewed-by: Imre Deak

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

On Thu, 16 Feb 2017, Abdiel Janulgue wrote: > From: marius vlad > > Make a copy of drm_property_blob data for user-supplied EDID blobs. I'd like to stop this approach from spreading by handling the EDID overrides at a lower level [1].

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Preserve the state of power wells not explicitly enabled

On Thu, Feb 16, 2017 at 02:18:53PM +0200, Ander Conselvan De Oliveira wrote: > On Wed, 2017-02-15 at 13:59 +0200, Imre Deak wrote: > > Atm, power wells that BIOS has enabled, but which we don't explicitly > > enable during power domain initialization would get disabled as we clear > > the BIOS

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Recheck breadcrumb seqno after an interrupt

On 16/02/2017 11:21, Chris Wilson wrote: On Thu, Feb 16, 2017 at 10:45:56AM +, Tvrtko Ursulin wrote: On 16/02/2017 10:36, Chris Wilson wrote: On Thu, Feb 16, 2017 at 10:21:17AM +, Tvrtko Ursulin wrote: On 16/02/2017 09:29, Chris Wilson wrote: If an interrupt arrives whilst we are

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Recheck breadcrumb seqno after an interrupt

On Thu, Feb 16, 2017 at 12:47:41PM +, Tvrtko Ursulin wrote: > > On 16/02/2017 11:21, Chris Wilson wrote: > >On Thu, Feb 16, 2017 at 10:45:56AM +, Tvrtko Ursulin wrote: > >> > >>On 16/02/2017 10:36, Chris Wilson wrote: > >>>On Thu, Feb 16, 2017 at 10:21:17AM +, Tvrtko Ursulin wrote: >

Re: [Intel-gfx] [PATCH v3 6/7] drm/atomic: Convert get_existing_state callers to get_old/new_state, v2.

Op 17-01-17 om 02:27 schreef Laurent Pinchart: > Hi Maarten, > > One more thing. > > On Monday 16 Jan 2017 10:37:43 Maarten Lankhorst wrote: >> This is a straightforward conversion that converts all the users of >> get_existing_state in atomic core to use get_old_state or get_new_state >> >>

Re: [Intel-gfx] [PATCH v3 6/7] drm/atomic: Convert get_existing_state callers to get_old/new_state, v2.

Op 17-01-17 om 02:12 schreef Laurent Pinchart: > Hi Maarten, > > Thank you for the patch. > > I don't think you need the "v2" at the end of the subject line. > > On Monday 16 Jan 2017 10:37:43 Maarten Lankhorst wrote: >> This is a straightforward conversion that converts all the users of >>

[Intel-gfx] ✗ Fi.CI.BAT: failure for i915/drm/HuC: Motivation behind having HuC

== Series Details == Series: i915/drm/HuC: Motivation behind having HuC URL : https://patchwork.freedesktop.org/series/19746/ State : failure == Summary == Series 19746v1 i915/drm/HuC: Motivation behind having HuC https://patchwork.freedesktop.org/api/1.0/series/19746/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH v3 4/4] drm: Resurrect atomic rmfb code, v3

On Wed, 15 Feb 2017, Sinclair Yeh wrote: > On Wed, Feb 15, 2017 at 03:56:09PM +0200, Jani Nikula wrote: >> On Wed, 25 Jan 2017, Maarten Lankhorst >> wrote: >> > This was somehow lost between v3 and the merged version in Maarten's >> > patch

[Intel-gfx] [PATCH v2] drm/i915: Remove struct_mutex for destroying framebuffers

We do not need to hold struct_mutex for destroying drm_i915_gem_objects any longer, and with a little care taken over tracking obj->framebuffer_references, we can relinquish BKL locking around the destroy of intel_framebuffer. v2: Use atomic check for WARN_ON framebuffer miscounting

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Only enable DDI IO power domains after enabling DPLL

On Fri, Feb 10, 2017 at 03:29:59PM +0200, Ander Conselvan de Oliveira wrote: > According to bspec, the DDI IO power domains should be enabled after > enabling the DPLL and mapping it to the DDI. The current order doesn't > seem to create problems with Skylake and Kabylake, but causes enable >

Re: [Intel-gfx] drm/i915/bxt: drop some old workarounds

On Wed, 15 Feb 2017, Imre Deak wrote: > On Wed, Feb 15, 2017 at 05:21:36PM +0200, Jani Nikula wrote: >> Remove some rev A specific workarounds. > > On the series: > Reviewed-by: Imre Deak Thanks, pushed to dinq. BR, Jani. > >> >> BR, >> Jani. >> >>

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Postpone fake breadcrumb interrupt if a real interrupt is pending

On 16/02/2017 10:47, Chris Wilson wrote: On Thu, Feb 16, 2017 at 10:38:08AM +, Tvrtko Ursulin wrote: On 16/02/2017 09:29, Chris Wilson wrote: If the timer expires for enabling the fake interrupt, check to see if there is a real interrupt queued before making the decision to start

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Postpone fake breadcrumb interrupt if a real interrupt is pending

On Thu, Feb 16, 2017 at 11:17:11AM +, Tvrtko Ursulin wrote: > > On 16/02/2017 10:47, Chris Wilson wrote: > >On Thu, Feb 16, 2017 at 10:38:08AM +, Tvrtko Ursulin wrote: > >> > >>On 16/02/2017 09:29, Chris Wilson wrote: > >>>If the timer expires for enabling the fake interrupt, check to see

Re: [Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

Daniel Vetter schreef op di 14-02-2017 om 20:51 [+0100]: > On Mon, Feb 13, 2017 at 10:26 PM, Pandiyan, Dhinakaran > wrote: > > On Mon, 2017-02-13 at 09:05 +, Lankhorst, Maarten wrote: > > > Pandiyan, Dhinakaran schreef op do 09-02-2017 om 18:55 [+]: > > > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: DMC 1.03 for Geminilake (rev4)

== Series Details == Series: drm/i915: DMC 1.03 for Geminilake (rev4) URL : https://patchwork.freedesktop.org/series/19081/ State : failure == Summary == Series 19081v4 drm/i915: DMC 1.03 for Geminilake https://patchwork.freedesktop.org/api/1.0/series/19081/revisions/4/mbox/ Test

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

On Wed, Feb 15, 2017 at 04:12:04PM +0200, Ville Syrjälä wrote: > On Wed, Feb 15, 2017 at 01:15:47PM +, Chris Wilson wrote: > > 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

Re: [Intel-gfx] [PATCH v2] drm/i915: Remove struct_mutex for destroying framebuffers

On to, 2017-02-16 at 09:46 +, Chris Wilson wrote: > We do not need to hold struct_mutex for destroying drm_i915_gem_objects > any longer, and with a little care taken over tracking > obj->framebuffer_references, we can relinquish BKL locking around the > destroy of intel_framebuffer. > > v2:

[Intel-gfx] [PATCH 1/3] drm: move edid property update and add modes out of edid firmware loader

Make the firmware loader more generic and generally useful. Signed-off-by: Jani Nikula --- drivers/gpu/drm/drm_edid_load.c| 17 - drivers/gpu/drm/drm_probe_helper.c | 8 +++- include/drm/drm_edid.h | 7 --- 3 files changed, 15

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Recheck breadcrumb seqno after an interrupt

On Thu, Feb 16, 2017 at 10:21:17AM +, Tvrtko Ursulin wrote: > > On 16/02/2017 09:29, Chris Wilson wrote: > >If an interrupt arrives whilst we are performing the irq-seqno barrier, > >recheck the seqno again before returning. > > > >Signed-off-by: Chris Wilson > >Cc:

[Intel-gfx] [PATCH 0/3] drm: handle override/firmware edid at the lowest level

This is a simplified version of the perhaps too ambitious RFC [1]. Here we simply handle debugfs override edid and the firmware edid at the drm_do_get_edid() level, not at the probe helper level. With this, everything from EDID gets transparently overridden. BR, Jani. [1]

[Intel-gfx] [PATCH v2] drm/i915: Postpone fake breadcrumb interrupt until real interrupts cease

When the timer expires for checking on interrupt processing, check to see if any interrupts arrived within the last time period. If real interrupts are still being delivered, we can be reassured that we haven't missed the final interrupt as the waiter will still be woken. Only once all activity

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Recheck breadcrumb seqno after an interrupt

On Thu, Feb 16, 2017 at 11:19:41AM +, Tvrtko Ursulin wrote: > > On 16/02/2017 10:50, Chris Wilson wrote: > >On Thu, Feb 16, 2017 at 10:45:56AM +, Tvrtko Ursulin wrote: > >> > >>On 16/02/2017 10:36, Chris Wilson wrote: > >>>On Thu, Feb 16, 2017 at 10:21:17AM +, Tvrtko Ursulin wrote: >

Re: [Intel-gfx] [PATCH v2] drm/i915: Postpone fake breadcrumb interrupt until real interrupts cease

On Thu, Feb 16, 2017 at 11:13:47AM +, Chris Wilson wrote: > When the timer expires for checking on interrupt processing, check to > see if any interrupts arrived within the last time period. If real > interrupts are still being delivered, we can be reassured that we > haven't missed the final

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Tidy workaround batch buffer emission

== Series Details == Series: series starting with [1/2] drm/i915: Tidy workaround batch buffer emission URL : https://patchwork.freedesktop.org/series/19715/ State : success == Summary == Series 19715v1 Series without cover letter

Re: [Intel-gfx] [PATCH 5/6] drm/i915/glk: Don't attempt to sync DDI IO power well hw state

On Fri, Feb 10, 2017 at 03:29:58PM +0200, Ander Conselvan de Oliveira wrote: > Geminilake's DDI IO power wells can only be enabled after a DPLL is > running and must be disabled before disabling the DPLL. Attempting to > change its state outside of this conditions will result in timeouts. > That

[Intel-gfx] [patch added to 3.12-stable] drm/i915: Don't leak edid in intel_crt_detect_ddc()

From: Ander Conselvan de Oliveira This patch has been added to the 3.12 stable tree. If you have any objections, please let us know. === commit c34f078675f505c4437919bb1897b1351f16a050 upstream. In the path where intel_crt_detect_ddc()

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Recheck breadcrumb seqno after an interrupt

On Thu, Feb 16, 2017 at 10:45:56AM +, Tvrtko Ursulin wrote: > > On 16/02/2017 10:36, Chris Wilson wrote: > >On Thu, Feb 16, 2017 at 10:21:17AM +, Tvrtko Ursulin wrote: > >> > >>On 16/02/2017 09:29, Chris Wilson wrote: > >>>If an interrupt arrives whilst we are performing the irq-seqno

Re: [Intel-gfx] [PATCH v2] drm/i915: Postpone fake breadcrumb interrupt until real interrupts cease

On 16/02/2017 12:00, Chris Wilson wrote: On Thu, Feb 16, 2017 at 11:44:31AM +, Tvrtko Ursulin wrote: On 16/02/2017 11:13, Chris Wilson wrote: When the timer expires for checking on interrupt processing, check to see if any interrupts arrived within the last time period. If real

[Intel-gfx] [PATCH 2/5] drm/i915: Simplify cleanup path in intel_engines_init

From: Tvrtko Ursulin We can call the engine cleanup vfunc instead of duplicating the decision making here. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_engine_cs.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)

[Intel-gfx] [PATCH 1/5] drm/i915: Make int __intel_ring_space static

From: Tvrtko Ursulin It is only used within intel_ringbuffer.c Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +- drivers/gpu/drm/i915/intel_ringbuffer.h | 1 - 2 files changed, 1 insertion(+), 2 deletions(-)

[Intel-gfx] [PATCH 3/5] drm/i915: Move common workaround code to intel_engine_cs

From: Tvrtko Ursulin It is used by all submission backends. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_engine_cs.c | 550 drivers/gpu/drm/i915/intel_ringbuffer.c | 550

[Intel-gfx] [PATCH 4/5] drm/i915: Tidy workaround batch buffer emission

From: Tvrtko Ursulin Use the "*batch++ = " style as in the ring emission for better readability and also simplify the logic a bit by consolidating the offset and size calculations and overflow checking. The latter is a programming error so it is not required to check

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Store aux power domain in intel_dp

On Thu, 2017-02-16 at 11:05 +0200, Imre Deak wrote: > On Fri, Feb 10, 2017 at 03:29:54PM +0200, Ander Conselvan de Oliveira wrote: > > The aux power domain only makes sense in the DP code. Storing it in > > struct intel_dp avoids some indirection. > > > > v2: Rebase > > Signed-off-by: Ander

[Intel-gfx] [PATCH 5/5] drm/i915: Consolidate gen8_emit_pipe_control

From: Tvrtko Ursulin We have a few open coded instances in the execlists code and an almost suitable helper in intel_ringbuf.c We can consolidate to a single helper if we change the existing helper to emit directly to ring buffer memory and move the space reservation

[Intel-gfx] [PATCH 0/5] Assorted engine tidy

From: Tvrtko Ursulin A few previously posted patches to tidy the code, extract some commonality, and make workaround batch buffer emission more compact and readable. textdata bss dec hex filename 1080898 240802852 1107830 10e776 i915.ko.0

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Remove redundant toggling from the power well sync_hw hooks

On Wed, 2017-02-15 at 13:59 +0200, Imre Deak wrote: > Doing an explicit enable/disable in the power well sync_hw hook based on > the power well's reference count is redundant, since by the time these > hooks are called all the power wells are enabled and have a reference. > So remove the redundant

Re: [Intel-gfx] [PATCH 3/4] drm/i915/gen9: Fix clearing of the BIOS power well request register

On Wed, 2017-02-15 at 13:59 +0200, Imre Deak wrote: > Atm, in the power well sync_hw hook we are clearing all BIOS request > bits, not just the one corresponding to the given power well. This could > turn off an unrelated power well inadvertently if it didn't have a > request bit set in the driver

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Store encoder power domain in struct intel_encoder

On Fri, Feb 10, 2017 at 03:29:55PM +0200, Ander Conselvan de Oliveira wrote: > The encoder power domain is obviously tied to the encoder, so store it > in struct intel_encoder. This avoids some indirection. > > v2: Rebase > Signed-off-by: Ander Conselvan de Oliveira >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Add DPCD definitions for DP 1.4 DSC feature (rev2)

== Series Details == Series: drm: Add DPCD definitions for DP 1.4 DSC feature (rev2) URL : https://patchwork.freedesktop.org/series/19666/ State : failure == Summary == Series 19666v2 drm: Add DPCD definitions for DP 1.4 DSC feature

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Recheck breadcrumb seqno after an interrupt

On 16/02/2017 09:29, Chris Wilson wrote: If an interrupt arrives whilst we are performing the irq-seqno barrier, recheck the seqno again before returning. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.h |

Re: [Intel-gfx] [PATCH 3/3] drm: handle override edid and firmware adid at drm_do_get_edid()

On Thu, 16 Feb 2017, Jani Nikula wrote: > Handle override edid and firmware edid at the low level to transparently > and completely replace the real edid. This also prevents actual edid > reads for them, but retains ddc probe. Please ignore this stray patch, and look at

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Recheck breadcrumb seqno after an interrupt

On Thu, Feb 16, 2017 at 10:45:56AM +, Tvrtko Ursulin wrote: > > On 16/02/2017 10:36, Chris Wilson wrote: > >On Thu, Feb 16, 2017 at 10:21:17AM +, Tvrtko Ursulin wrote: > >> > >>On 16/02/2017 09:29, Chris Wilson wrote: > >>>If an interrupt arrives whilst we are performing the irq-seqno

Re: [Intel-gfx] [PATCH v3 4/4] drm: Resurrect atomic rmfb code, v3

Op 16-02-17 om 10:45 schreef Jani Nikula: > On Wed, 15 Feb 2017, Sinclair Yeh wrote: >> On Wed, Feb 15, 2017 at 03:56:09PM +0200, Jani Nikula wrote: >>> On Wed, 25 Jan 2017, Maarten Lankhorst >>> wrote: This was somehow lost between v3

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Unwind conversion to i915_gem_phys_ops on failure (rev2)

== Series Details == Series: drm/i915: Unwind conversion to i915_gem_phys_ops on failure (rev2) URL : https://patchwork.freedesktop.org/series/19708/ State : failure == Summary == Series 19708v2 drm/i915: Unwind conversion to i915_gem_phys_ops on failure

  1   2   3   >