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

On 15/02/2017 21:18, Chris Wilson wrote: On Wed, Feb 15, 2017 at 04:06:33PM +, 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

[Intel-gfx] ✗ Fi.CI.BAT: failure 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 : failure == Summary == Series 19226v2 drm/i915/glk: CDCLK calculation changes for glk

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

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 pc6[6] = { GFX_OP_PIPE_CONTROL(6), 0, 0, 0, 0, 0 }; + + memcpy(batch, pc6,

Re: [Intel-gfx] [PATCH v2] drm/i915: Sanitize GuC client initialization

On Wed, Feb 15, 2017 at 06:28:59PM -0800, Daniele Ceraolo Spurio wrote: > On 14/02/17 05:53, Joonas Lahtinen wrote: > >-static void guc_disable_doorbell(struct intel_guc *guc, > >- struct i915_guc_client *client) > >+static int __destroy_doorbell(struct i915_guc_client

Re: [Intel-gfx] [PATCH] drm/i915/gvt: set ring buffer size to default for guc submission

On Thu, Feb 16, 2017 at 02:36:40PM +0800, Chuanxiao Dong wrote: > When not using GuC submission, the ring buffer size for GVT context is > 512KB which is the max size. When switching to GuC submission, the ring > buffer size is required to be less than 16KB. So use the GVT context > default ring

[Intel-gfx] ✗ Fi.CI.BAT: failure 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 : failure == Summary == Series 3007v3 drm/i915: Support HDMI EDID injection https://patchwork.freedesktop.org/api/1.0/series/3007/revisions/3/mbox/ Test

[Intel-gfx] [PATCH] drm/i915/glk: CDCLK calculation changes for glk

As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 Mhz. Practically we can achive only 99% of these cdclk values(HW team checking on this). So cdclk should be calculated for the given pixclk as per that otherwise it may lead to screen corruption for some scenarios. v2: Rebased to new

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

From: marius vlad Make a copy of drm_property_blob data for user-supplied EDID blobs. Signed-off-by: Abdiel Janulgue Signed-off-by: Marius Vlad --- drivers/gpu/drm/i915/intel_hdmi.c | 10 ++ 1 file

[Intel-gfx] [PATCH] drm/i915/gvt: set ring buffer size to default for guc submission

When not using GuC submission, the ring buffer size for GVT context is 512KB which is the max size. When switching to GuC submission, the ring buffer size is required to be less than 16KB. So use the GVT context default ring buffer size if GuC submission is enabled. Signed-off-by: Chuanxiao Dong

Re: [Intel-gfx] [PATCH v2] drm/i915: Sanitize GuC client initialization

On 14/02/17 05:53, Joonas Lahtinen 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

[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

[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 |

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote: > Hi, > > On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote: > > It is necessary to track states for objects other than connector, crtc > > and plane for atomic modesets. But adding objects like DP MST link > > bandwidth to drm_atomic_state

Re: [Intel-gfx] kbl_guc and bxt_guc firmware missing from linux-firmware

On Wed, 2017-02-15 at 07:01 -0600, Seth Forshee wrote: > On Wed, Feb 15, 2017 at 12:28:42PM +0200, Jani Nikula wrote: > > On Tue, 14 Feb 2017, Seth Forshee wrote: > > > Hi, > > > > > > I've noted that kbl_guc_ver9_14.bin and bxt_guc_ver8_7.bin are not in > > >

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

On Wed, Feb 15, 2017 at 09:49:41PM +, Chris Wilson wrote: > > >-static int reserve_global_seqno(struct drm_i915_private *i915) > > >+static int reserve_global_seqno(struct intel_engine_cs *engine) > > > > Rename to reserve_engine_seqno? > > Yes. > > > >- u32 active_requests =

[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 01/14] drm/i915: Keep a global seqno per-engine

On Wed, Feb 15, 2017 at 09:49:41PM +, Chris Wilson wrote: > > Protected by the timeline spinlock? > > struct_mutex. (Still thinking about what mutex it will be in the > future.) Hmm, was thinking it have already replaced active_requests. However, it is still tied to request

[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

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

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 each timeline has separate

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

On snb? flip-flops/false-positives? On Wed, 2017-02-15 at 20:22 +, Patchwork wrote: > == Series Details == > > Series: drm/i915: DMC 1.03 for Geminilake (rev3) > URL : https://patchwork.freedesktop.org/series/19081/ > State : failure > > == Summary == > > Series 19081v3 drm/i915: DMC

Re: [Intel-gfx] [PATCH] ALSA: x86: Fix spinlock usage in the trigger callback

On Wed, 15 Feb 2017 20:15:50 +0100, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > Simply doing 'xset dpms force off' while playback is active seems > sufficient to anger lockdep [1]. And it's of course correct that it's > not safe to use regular

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

On Wed, Feb 15, 2017 at 04:06:33PM +, 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 2/2] drm/i915: Consolidate gen8_emit_pipe_control

On Wed, Feb 15, 2017 at 04:06:34PM +, Tvrtko Ursulin wrote: > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c > b/drivers/gpu/drm/i915/intel_ringbuffer.c > index f7499829ecc2..a359527948b9 100644 > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c > +++

Re: [Intel-gfx] [PATCH] ALSA: x86: Fix spinlock usage in the trigger callback

On Wed, Feb 15, 2017 at 09:15:50PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Simply doing 'xset dpms force off' while playback is active seems > sufficient to anger lockdep [1]. And it's of course correct that it's > not safe to use

[Intel-gfx] ✗ Fi.CI.BAT: failure for ALSA: x86: Fix spinlock usage in the trigger callback

== Series Details == Series: ALSA: x86: Fix spinlock usage in the trigger callback URL : https://patchwork.freedesktop.org/series/19736/ State : failure == Summary == Series 19736v1 ALSA: x86: Fix spinlock usage in the trigger callback

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

Hi Chris, [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on v4.10-rc8 next-20170215] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Unwind

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

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

[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

[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

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

On Wed, Feb 15, 2017 at 09:34:23AM -0800, Rodrigo Vivi wrote: > There is a new version of DMC available for Kabylake. s/Kabylake/Gemini Lake/ > > It's release notes only mention: > - Enhancement in the FW to restore the PG2 state > > v2: cook on top of drm-tip without depending on kbl one so

[Intel-gfx] [PATCH] ALSA: x86: Fix spinlock usage in the trigger callback

From: Ville Syrjälä Simply doing 'xset dpms force off' while playback is active seems sufficient to anger lockdep [1]. And it's of course correct that it's not safe to use regular spin_lock() outside the irq handler when the irq handler also wants to acquire the

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

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 > > BR, > Jani. > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org >

Re: [Intel-gfx] [PATCH 9/9] drm/i915/bxt: Fix the DSI enable sequence

On Wed, 8 Feb 2017 16:20:58 +0530 Vidya Srinivas wrote: > From: Uma Shankar > > Device ready to be done after panel power on and before > sending the OTP commands. Patch fixes the enable sequence > as per this. > > Signed-off-by: Uma Shankar

[Intel-gfx] ✗ Fi.CI.BAT: failure 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 : failure == Summary == Series 19715v1 Series without cover letter

Re: [Intel-gfx] [PATCH 4/9] drm/i915: Add DSI panel power on/off sequence callbacks

On Wed, 8 Feb 2017 16:20:53 +0530 Vidya Srinivas wrote: > From: Uma Shankar > > Panel Power On/Off sequences are part of Panel spec. > These are present in VBT v3 of the Intel VBT spec. > Some DSI controller/panels require making SOC specific >

Re: [Intel-gfx] [PATCH 8/9] drm/i915/bxt: Enable BXT DSI dual link

On Wed, 8 Feb 2017 16:20:57 +0530 Vidya Srinivas wrote: > From: Uma Shankar > > Enable support for BXT DSI dual link mode. > > Signed-off-by: Uma Shankar > Signed-off-by: Vidya Srinivas

Re: [Intel-gfx] [PATCH 7/9] drm/i915/bxt: Disable device ready before shutdown command

On Wed, 8 Feb 2017 16:20:56 +0530 Vidya Srinivas wrote: > From: Uma Shankar > > Disable device ready before MIPI port shutdown command. > This helps to avoid mipi split screen issues. > > Signed-off-by: Uma Shankar >

Re: [Intel-gfx] [PATCH 6/9] drm/i915/bxt: Fix BXT DSI disable sequence

On Wed, 8 Feb 2017 16:20:55 +0530 Vidya Srinivas wrote: > From: Uma Shankar > > Fix BXT DSI disable sequence as per latest updates in BSpec. > > Signed-off-by: Uma Shankar > Signed-off-by: Vidya Srinivas

[Intel-gfx] [PATCH i-g-t v2] gitignore: Add files starting with .

I cant be the only one that have added .tags by mistake. v2: Do not ignore .gitignore Cc: Petri Latvala Cc: Joonas Lahtinen Signed-off-by: Michel Thierry --- .gitignore | 2 ++ 1 file changed, 2 insertions(+)

[Intel-gfx] ✗ Fi.CI.BAT: failure 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 : failure == Summary == Series 19706v2 Moving the common engine/ring code to intel_engine_cs.c

Re: [Intel-gfx] [PATCH i-g-t] gitignore: Add files starting with .

On 15/02/17 04:24, Joonas Lahtinen wrote: On pe, 2017-02-10 at 12:37 -0800, Michel Thierry wrote: I cant be the only one that have added .tags by mistake. Cc: Marius Vlad Cc: Petri Latvala Signed-off-by: Michel Thierry

Re: [Intel-gfx] [PATCH 5/9] drm/i915/bxt: Fix BXT DSI ULPS sequence

On Wed, 8 Feb 2017 16:20:54 +0530 Vidya Srinivas wrote: > From: Uma Shankar > > Fix the Sequence to program BXT DSI Latch and ULPS. > > Signed-off-by: Uma Shankar > Signed-off-by: Vidya Srinivas

Re: [Intel-gfx] [PATCH 1/9] drm/i915: Check for platform specific GPIO config

On Wed, 8 Feb 2017 16:20:50 +0530 Vidya Srinivas wrote: > From: Uma Shankar > > Panel GPIO control should be done based on platform. Add a check > to restrict VLV and CHT specific GPIO confirguration, so that > they dont apply to other

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

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 merged as: > > > > commit f2d580b9a8149735cbc4b59c4a8df60173658140

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/bxt: apply clock gating workaround to all revisions

== Series Details == Series: series starting with [1/3] drm/i915/bxt: apply clock gating workaround to all revisions URL : https://patchwork.freedesktop.org/series/19712/ State : failure == Summary == Series 19712v1 Series without cover letter

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

There is a new version of DMC available for Kabylake. It's release notes only mention: - Enhancement in the FW to restore the PG2 state v2: cook on top of drm-tip without depending on kbl one so CI can check. Cc: Ander Conselvan de Oliveira Signed-off-by:

[Intel-gfx] [PATCH] 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. Signed-off-by: Manasi Navare Cc: Jani Nikula Cc: Paulo Zanoni Cc:

[Intel-gfx] ✗ Fi.CI.BAT: failure 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 : failure == 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:

Re: [Intel-gfx] [PATCH v2 03/14] drm/i915: Add ourselves to the gpu error waitqueue for the entire wait

On 14/02/2017 09:54, Chris Wilson wrote: Add ourselves to the gpu error waitqueue earllier on, even before we determine we have to wait on the seqno. This is so that we can then share the waitqueue between stages in subsequent patches. Signed-off-by: Chris Wilson ---

Re: [Intel-gfx] [PATCH v2 02/14] drm/i915: Use a local to shorten req->i915->gpu_error.wait_queue

On 14/02/2017 09:54, Chris Wilson wrote: Use a local variable to avoid having to type out the full name of the gpu_error wait_queue. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_request.c | 8 1 file changed, 4 insertions(+), 4 deletions(-)

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

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 each timeline has separate fence-contexts for each engine and a seqno is only ordered within a

Re: [Intel-gfx] [PATCH] drm/i915: DMC 1.02 for Kabylake

On Fri, 2017-02-03 at 10:56 -0800, Rodrigo Vivi wrote: > There is a new version of DMC available for Kabylake. > > It's release notes only mention: > > - Fix for glitch in AUX > > Signed-off-by: Rodrigo Vivi Patch looks correct. I understand this needs a tested-by from

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

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 Reported-by: Mika Kuoppala Signed-off-by:

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

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 pc6[6] = { GFX_OP_PIPE_CONTROL(6), 0, 0, 0, 0, 0 }; > + > + memcpy(batch, pc6, sizeof(pc6)); > + > + batch[1] =

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

== Series Details == Series: drm/i915: Unwind conversion to i915_gem_phys_ops on failure URL : https://patchwork.freedesktop.org/series/19708/ State : failure == Summary == LD drivers/video/fbdev/built-in.o LD drivers/usb/gadget/libcomposite.o LD drivers/spi/built-in.o

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Use a heavyweight irq-seqno barrier for gen6+

On Wed, Feb 15, 2017 at 04:03:33PM +, Chris Wilson wrote: > On Wed, Feb 15, 2017 at 01:52:12PM -, Patchwork wrote: > > == Series Details == > > > > Series: series starting with [1/2] drm/i915: Use a heavyweight irq-seqno > > barrier for gen6+ > > URL :

[Intel-gfx] [PATCH 2/2] 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 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] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Use a heavyweight irq-seqno barrier for gen6+

On Wed, Feb 15, 2017 at 01:52:12PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [1/2] drm/i915: Use a heavyweight irq-seqno > barrier for gen6+ > URL : https://patchwork.freedesktop.org/series/19697/ > State : failure > > == Summary == > > Series 19697v1

[Intel-gfx] [PATCH 2/3] 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] ✓ Fi.CI.BAT: success for drm/i915: Avoid tweaking evaluation thresholds on Baytrail v2 (rev2)

== Series Details == Series: drm/i915: Avoid tweaking evaluation thresholds on Baytrail v2 (rev2) URL : https://patchwork.freedesktop.org/series/19702/ State : success == Summary == Series 19702v2 drm/i915: Avoid tweaking evaluation thresholds on Baytrail v2

Re: [Intel-gfx] [PATCH] drm/i915/dp: Reset the link params on HPD/connected boot/resume

On Tue, 14 Feb 2017, Manasi Navare wrote: > On Tue, Feb 14, 2017 at 09:08:25PM +0200, Ville Syrjälä wrote: >> On Tue, Feb 07, 2017 at 04:54:11PM -0800, Manasi Navare wrote: >> > The max link parameters should be set/reset only on HPD or >> > connected boot case or on

[Intel-gfx] [PATCH 1/3] drm/i915/bxt: apply clock gating workaround to all revisions

No need to cater for old A revisions. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_pm.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 3d311e100643..fe243c65de1a

[Intel-gfx] [PATCH 3/3] drm/i915/bxt: remove WaRsDisableCoarsePowerGating for early BXT

No need to cater for old A revisions. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_drv.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 7aa79033c166..7495a16b869a

[Intel-gfx] [PATCH 2/3] drm/i915/bxt: remove snooping workaround on old A revisions

No need to cater for old A revisions. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_device_info.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c index

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

Remove some rev A specific workarounds. BR, Jani. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only enable hotplug interrupts if the display interrupts are enabled (rev3)

== Series Details == Series: drm/i915: Only enable hotplug interrupts if the display interrupts are enabled (rev3) URL : https://patchwork.freedesktop.org/series/19687/ State : success == Summary == Series 19687v3 drm/i915: Only enable hotplug interrupts if the display interrupts are

Re: [Intel-gfx] [PATCH 3/5] drm/i915/guc: Extract param logic form guc_init

On Wed, Feb 15, 2017 at 02:48:59PM +0200, Joonas Lahtinen wrote: > On ti, 2017-02-14 at 20:37 +0100, Michal Wajdeczko wrote: > > On Tue, Feb 14, 2017 at 05:15:39PM +0100, Arkadiusz Hiler wrote: > > > > > > Let intel_guc_init() focus on determining and fetching the correct > > > firmware. > > > >

Re: [Intel-gfx] i915: Dealing with 90° rotated display ?

On Wed, Feb 15, 2017 at 03:54:17PM +0100, Hans de Goede wrote: > Hi Jani, > > As discussed here: > > https://bugs.freedesktop.org/show_bug.cgi?id=94894 > > I've a mini-laptop which uses a phone-screen, > so the native orientation of the screen is portrait, > where as for a clam-shell device one

Re: [Intel-gfx] [PATCH v7 8/8] drm/i915/gen9: WM memory bandwidth related workaround

Hi, On Thursday 15 December 2016 10:37 PM, Paulo Zanoni wrote: Em Qui, 2016-12-01 às 21:19 +0530, Mahesh Kumar escreveu: This patch implemnets Workariunds related to display arbitrated memory bandwidth. These WA are applicabe for all gen-9 based platforms. 3 typos above. The WA is already

Re: [Intel-gfx] [PATCH v7 7/8] drm/i915: Decode system memory bandwidth

Hi, On Friday 09 December 2016 05:25 AM, Paulo Zanoni wrote: Em Qui, 2016-12-01 às 21:19 +0530, Mahesh Kumar escreveu: This patch adds support to decode system memory bandwidth which will be used for arbitrated display memory percentage calculation in GEN9 based system. Changes from v1: -

[Intel-gfx] [PATCH 2/3] drm/i915: Decode system memory bandwidth

This patch adds support to decode system memory bandwidth which will be used for arbitrated display memory percentage calculation in GEN9 based system. Changes from v1: - Address comments from Paulo - implement decode function for SKL/KBL also Changes from v2: - Rewrite the code as per HW team

[Intel-gfx] i915: Dealing with 90° rotated display ?

Hi Jani, As discussed here: https://bugs.freedesktop.org/show_bug.cgi?id=94894 I've a mini-laptop which uses a phone-screen, so the native orientation of the screen is portrait, where as for a clam-shell device one wants it to be landscape. Ideally there would be a flag somewhere to tell the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix clearing of BIOS power well requests

== Series Details == Series: drm/i915: Fix clearing of BIOS power well requests URL : https://patchwork.freedesktop.org/series/19699/ State : success == Summary == Series 19699v1 drm/i915: Fix clearing of BIOS power well requests

[Intel-gfx] [PATCH 3/3] drm/i915/gen9: WM memory bandwidth related workaround

This patch disables workarounds related to display arbitrated memory bandwidth if it's not required. WA's are applicable for all GEN9 based platforms. Changes since v1: - Rebase on top of Paulo's patch series Changes since v2: - Address review comments - Rebase/rework as per other patch

[Intel-gfx] [PATCH 1/3] drm/i915/bxt: Enable IPC support

This patch adds IPC support for platforms. This patch enables IPC only for BXT/KBL platform as for SKL recommendation is to keep it disabled. IPC (Isochronous Priority Control) is the hardware feature, which dynamically controls the memory read priority of Display. When IPC is enabled, plane read

[Intel-gfx] [PATCH 0/3] Enable IPC & WM related WA's

This series include remaining patches from following series to enable IPC and Enable/update memory BW related WA's for WM. https://patchwork.freedesktop.org/series/15562/ Mahesh Kumar (3): drm/i915/bxt: Enable IPC support drm/i915: Decode system memory bandwidth drm/i915/gen9: WM memory

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

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. Reported-by: Mika Kuoppala Signed-off-by: Chris Wilson

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

On 08/02/2017 14:44, Tvrtko Ursulin wrote: On 08/02/2017 13:20, Chris Wilson wrote: On Wed, Feb 08, 2017 at 01:13:48PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin -static int gen9_init_perctx_bb(struct intel_engine_cs *engine, - struct

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Move common engine and ring code into intel_engine_cs

On Wed, Feb 15, 2017 at 02:05:52PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > This leaves the ringbuff submission code in intel_ringbuffer.c > > Signed-off-by: Tvrtko Ursulin > --- > drivers/gpu/drm/i915/intel_engine_cs.c | 834

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Move common engine and ring code into intel_engine_cs

On Wed, Feb 15, 2017 at 02:05:52PM +, Tvrtko Ursulin wrote: > +u32 *intel_ring_begin(struct drm_i915_gem_request *req, int num_dwords) > +{ I'd leave this out for the moment (and all the associated ring space) since imo this is a i915_gem_request_emit() (it takes i915_gem_request!). That

Re: [Intel-gfx] [PATCH 5/5] drm/i915/uc: Simplify fw_path

On Tue, Feb 14, 2017 at 09:23:33PM +0100, Michal Wajdeczko wrote: > On Tue, Feb 14, 2017 at 05:15:41PM +0100, 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

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

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 interrupts are enabled. > > [4.740136] WARNING: CPU: 1 PID: 221 at >

[Intel-gfx] [drm-intel:drm-intel-next-queued 3/23] drivers/gpu/drm/i915/i915_gem_gtt.c:964: warning: 'iter.sg' is used uninitialized in this function

tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: 75c7b0b8620ce5a672da02e721a775acb7863c64 commit: 894ccebee2b0e606ba9638d20dd87b33568482d7 [3/23] drm/i915: Micro-optimise gen8_ppgtt_insert_entries() config: x86_64-randconfig-v0-02151136 (attached as .config) compiler:

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

On Wed, Feb 15, 2017 at 03:59:23PM +0200, Joonas Lahtinen wrote: > On ke, 2017-02-15 at 10:59 +, 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

[Intel-gfx] [PULL] drm-intel-next-fixes

Hi Dave, I'm flushing out the GVT fixes for the v4.11 merge window. I'll probably have more pure i915 fixes still. Heads up, for some reason your merge of drm-rockchip-next-2017-02-07 shows up in the stats below. I'm not quite sure what's going on here. Let me know if you want me to do something

[Intel-gfx] [PATCH 3/3] 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 2/3] drm/i915: Move common engine and ring code into intel_engine_cs

From: Tvrtko Ursulin This leaves the ringbuff submission code in intel_ringbuffer.c Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_engine_cs.c | 834 drivers/gpu/drm/i915/intel_ringbuffer.c |

[Intel-gfx] [PATCH 1/3] 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 0/3] Moving the common engine/ring code to intel_engine_cs.c

From: Tvrtko Ursulin Chris suggested that we should do this but it is a lot of churn so I don't know. There is more re-org we could do to make things more logical, like maybe move struct intel_ring code to intel_ring.c, but said, I am not sure it is worth the

Re: [Intel-gfx] ppgtt allocation fixes and speedups

On Tue, Feb 14, 2017 at 11:04:34AM +, Chris Wilson wrote: > And finally it should even compile! (Having merged the selftests.) And pushed (after applying the couple of improvements Mika and Matthew suggested). Thanks all for the help! -Chris -- Chris Wilson, Intel Open Source Technology

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

On ke, 2017-02-15 at 10:59 +, 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. > >

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

On Wed, 25 Jan 2017, Maarten Lankhorst wrote: > This was somehow lost between v3 and the merged version in Maarten's > patch merged as: > > commit f2d580b9a8149735cbc4b59c4a8df60173658140 > Author: Maarten Lankhorst > Date:

[Intel-gfx] [PULL] drm-misc-next-fixes

Hi Dave, a couple of drm core fixes for the v4.11 merge window. BR, Jani. The following changes since commit 13f62f54d174d3417c3caaafedf5e22a0a03e442: Merge branch 'drm-next-4.11' of git://people.freedesktop.org/~agd5f/linux into drm-next (2017-02-10 10:13:30 +1000) are available in the

[Intel-gfx] [PATCH] drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3

Certain Baytrails, namely the 4 cpu core variants, have been plaqued by spurious system hangs, mostly occurring with light loads. Multiple bisects by various people point to a commit which changes the reclocking strategy for Baytrail to follow its bigger brethen: commit 8fb55197e64d ("drm/i915:

Re: [Intel-gfx] [PATCH] drm/i915: Avoid tweaking evaluation thresholds on Baytrail v2

Chris Wilson writes: > On Wed, Feb 15, 2017 at 02:37:50PM +0200, Mika Kuoppala wrote: >> Certain Baytrails, namely the 4 cpu core variants, have been >> plaqued by spurious system hangs, mostly occurring with light loads. >> >> Multiple bisects by various people point

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Use a heavyweight irq-seqno barrier for gen6+

== Series Details == Series: series starting with [1/2] drm/i915: Use a heavyweight irq-seqno barrier for gen6+ URL : https://patchwork.freedesktop.org/series/19697/ State : failure == Summary == Series 19697v1 Series without cover letter

[Intel-gfx] [PULL] drm-misc-fixes for v4.10

Hi Dave, one dp/mst oops fix for v4.10. If it doesn't make it to v4.10, then please get this in during the merge window. BR, Jani. The following changes since commit 7089db84e356562f8ba737c29e472cc42d530dbc: Linux 4.10-rc8 (2017-02-12 13:03:20 -0800) are available in the git repository at:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Remove struct_mutex for destroying framebuffers

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

[Intel-gfx] [PATCH v2] 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]

  1   2   >