Re: [Intel-gfx] [PATCH v8 5/6] drm/i915/guc: Check the locking status of GuC WOPCM registers

On 2/6/2018 5:32 AM, Jackie Li wrote: GuC WOPCM registers are write-once registers. Current driver code accesses these registers without checking the accessibility to these registers, this will lead unpredictable driver behaviors if these registers were touch by other components (such as

Re: [Intel-gfx] [PATCH v8 4/6] drm/i915/guc: Add dynamic GuC WOPCM offset and size support for CNL

On 2/6/2018 5:32 AM, Jackie Li wrote: CNL has its own specific reserved GuC WOPCM size and hardware restrictions on GuC WOPCM size. On CNL A0 and Gen9, there's a hardware restriction that requires the available GuC WOPCM size to be larger than or equal to HuC firmware size. This patch updates

Re: [Intel-gfx] [PATCH v8 3/6] drm/i915/guc: Implement dynamic GuC WOPCM offset and size

change looks good to me. minor updates suggested with r-b. On 2/6/2018 5:32 AM, Jackie Li wrote: Hardware may have specific restrictions on GuC WOPCM offset and size. On Gen9, the value of the GuC WOPCM size register needs to be larger than the value of GuC WOPCM offset register + a Gen9

[Intel-gfx] [PATCH v3] drm/i915/icl: remove port A/E lane sharing limitation.

Platforms before Gen11 were sharing lanes between port-A & port-E. This limitation is no more there. Changes since V1: - optimize the code (Shashank/Jani) - create helper function to get max lanes (ville) Changes since V2: - Include BIOS fail fix-up in same helper function (ville) Changes

Re: [Intel-gfx] [PATCH v8 2/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

On 2/6/2018 5:32 AM, Jackie Li wrote: GuC related exported functions should start with "intel_guc_" prefix and pass intel_guc as the first parameter since its guc related. Current guc_ggtt_offset() failed to follow this code convention and this is a problem for future patches that needs to

Re: [Intel-gfx] [PATCH v8 1/6] drm/i915/guc: Move GuC WOPCM related code into separate files

On 2/6/2018 5:32 AM, Jackie Li wrote: intel_guc_reg.h should only include definition for GuC registers and related register bits. Non-register related GuC WOPCM macro definitions should not be defined in intel_guc_reg.h This patch creates a better file structure by moving non-register related

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern (rev3)

== Series Details == Series: drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern (rev3) URL : https://patchwork.freedesktop.org/series/37148/ State : warning == Summary == Test kms_atomic_transition: Subgroup plane-use-after-nonblocking-unbind-fencing: pass ->

Re: [Intel-gfx] Enabling i915 Panel Self Refresh by default on some devices ?

On Thu, 2018-02-01 at 13:31 +0100, Hans de Goede wrote: > Hi All, > > As you may have heard I've recently been working on improving > Linux laptop battery life, specifically the OOTB experience > without tweaking any options such as e.g. powertop --auto-tune > would do, see: > >

Re: [Intel-gfx] i915 PSR test results and cursor lag

On Mon, Feb 05, 2018 at 11:54:04PM +, Andy Lutomirski wrote: > > > > On Feb 5, 2018, at 2:50 PM, Rodrigo Vivi wrote: > > > >> On Sat, Feb 03, 2018 at 05:33:08PM +, Andy Lutomirski wrote: > >>> On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v8,1/6] drm/i915/guc: Move GuC WOPCM related code into separate files

== Series Details == Series: series starting with [v8,1/6] drm/i915/guc: Move GuC WOPCM related code into separate files URL : https://patchwork.freedesktop.org/series/37704/ State : failure == Summary == Series 37704v1 series starting with [v8,1/6] drm/i915/guc: Move GuC WOPCM related code

[Intel-gfx] [PATCH v8 4/6] drm/i915/guc: Add dynamic GuC WOPCM offset and size support for CNL

CNL has its own specific reserved GuC WOPCM size and hardware restrictions on GuC WOPCM size. On CNL A0 and Gen9, there's a hardware restriction that requires the available GuC WOPCM size to be larger than or equal to HuC firmware size. This patch updates GuC WOPCM init code to return the CNL

[Intel-gfx] [PATCH v8 3/6] drm/i915/guc: Implement dynamic GuC WOPCM offset and size

Hardware may have specific restrictions on GuC WOPCM offset and size. On Gen9, the value of the GuC WOPCM size register needs to be larger than the value of GuC WOPCM offset register + a Gen9 specific offset (144KB) for reserved GuC WOPCM. Fail to enforce such a restriction on GuC WOPCM size will

[Intel-gfx] [PATCH v8 5/6] drm/i915/guc: Check the locking status of GuC WOPCM registers

GuC WOPCM registers are write-once registers. Current driver code accesses these registers without checking the accessibility to these registers, this will lead unpredictable driver behaviors if these registers were touch by other components (such as faulty BIOS code). This patch moves the GuC

[Intel-gfx] [PATCH v8 6/6] HAX Enable GuC Submission for CI

Signed-off-by: Jackie Li --- drivers/gpu/drm/i915/i915_params.c | 2 +- drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_guc_wopcm.c | 6 ++ 3 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c

[Intel-gfx] [PATCH v8 2/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

GuC related exported functions should start with "intel_guc_" prefix and pass intel_guc as the first parameter since its guc related. Current guc_ggtt_offset() failed to follow this code convention and this is a problem for future patches that needs to access intel_guc data to verify the GGTT

[Intel-gfx] [PATCH v8 1/6] drm/i915/guc: Move GuC WOPCM related code into separate files

intel_guc_reg.h should only include definition for GuC registers and related register bits. Non-register related GuC WOPCM macro definitions should not be defined in intel_guc_reg.h This patch creates a better file structure by moving non-register related GuC WOPCM macro definitions into a new

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern (rev3)

== Series Details == Series: drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern (rev3) URL : https://patchwork.freedesktop.org/series/37148/ State : success == Summary == Series 37148v3 drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern

Re: [Intel-gfx] i915 PSR test results and cursor lag

> On Feb 5, 2018, at 2:50 PM, Rodrigo Vivi wrote: > >> On Sat, Feb 03, 2018 at 05:33:08PM +, Andy Lutomirski wrote: >>> On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski wrote: On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski

Re: [Intel-gfx] [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

Rodrigo Vivi writes: > I didn't checked the drm one close enough yet to decide for that. > DK or Keith? do you guys see anyone suitable for fixes? Yeah, we should probably get 1, 3 and 7 into fixes. 2, 4, 5 and 6 add explicit casts where the compiler would already

[Intel-gfx] [PATCH v3] drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern

This workaround should prevent a bug that can be hit on a context restore. To avoid the issue, we must emit a PIPE_CONTROL with CS stall (0x7a04 0x0010 0x 0x) followed by 12DW's of NOOP(0x0) in the indirect context batch buffer, to ensure the engine is idle prior to

Re: [Intel-gfx] Enabling i915 Panel Self Refresh by default on some devices ?

Hi Hans, On Fri, Feb 02, 2018 at 09:55:32AM +, Hans de Goede wrote: > Hi, > > On 01-02-18 13:31, Hans de Goede wrote: > > Hi All, > > > > As you may have heard I've recently been working on improving > > Linux laptop battery life, specifically the OOTB experience > > without tweaking any

Re: [Intel-gfx] [PATCH 2/6] drm/i915/icl: add the main CDCLK functions

On Mon, Feb 05, 2018 at 01:40:42PM -0200, Paulo Zanoni wrote: > This commit adds the basic CDCLK functions, but it's still missing > pieces of the display initialization sequence. > > v2: > - Implement the voltage levels. > - Rebase. > v3: > - Adjust to the new "bypass" clock (Imre). > - Call

Re: [Intel-gfx] i915 PSR test results and cursor lag

On Thu, Feb 01, 2018 at 05:43:56PM +, Andy Lutomirski wrote: > On Thu, Feb 1, 2018 at 9:40 AM, Andy Lutomirski wrote: > > Hi- > > > > As requested in your blog post, I tested PSR. I see something like > > 2.69W with PSR off and 2.17W with PSR on. Screen blanking, > >

Re: [Intel-gfx] i915 PSR test results and cursor lag

On Sat, Feb 03, 2018 at 05:33:08PM +, Andy Lutomirski wrote: > On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski wrote: > > On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski wrote: > >> On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson >

Re: [Intel-gfx] i915 PSR test results and cursor lag

On Mon, Feb 05, 2018 at 08:35:25PM +, Andy Lutomirski wrote: Andy, first of all thank you very much for those findings. > On Mon, Feb 5, 2018 at 6:53 PM, Pandiyan, Dhinakaran > wrote: > > > > > > > > On Sun, 2018-02-04 at 21:50 +, Andy Lutomirski wrote: >

Re: [Intel-gfx] i915 PSR test results and cursor lag

On Thu, Feb 01, 2018 at 08:33:29PM +, Chris Wilson wrote: > Quoting Kristian Høgsberg (2018-02-01 20:22:40) > > On Thu, Feb 1, 2018 at 9:53 AM Chris Wilson > > wrote: > > > > > Quoting Andy Lutomirski (2018-02-01 17:40:22) > > > > *However*, I do see one unfortunate

Re: [Intel-gfx] [PATCH 4/4] drm/i915: introduce INTEL_PCH_ID() and use it

On Mon, Feb 05, 2018 at 05:31:39PM +, Jani Nikula wrote: > Cleanup similar to INTEL_PCH_TYPE(). No functional changes. > > Signed-off-by: Jani Nikula Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/i915_drv.h | 11 ++- > 1

Re: [Intel-gfx] [PATCH 3/4] drm/i915: have virtual PCH detection return a PCH id

On Mon, Feb 05, 2018 at 05:31:38PM +, Jani Nikula wrote: > Simplify intel_virt_detect_pch() by making it return a PCH id rather > than returning the PCH type and setting PCH id for some PCHs. Map the > PCH id to PCH type using the shared routine. This gives us sanity check > on the supported

Re: [Intel-gfx] [PATCH 2/4] drm/i915: abstract virtual PCH id detection

On Mon, Feb 05, 2018 at 05:31:37PM +, Jani Nikula wrote: > Make the code slightly more pleasant to look at. indeed > No functional changes. > > Signed-off-by: Jani Nikula Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/i915_drv.c |

Re: [Intel-gfx] [PATCH 1/4] drm/i915: abstract PCH type detection from PCH id

On Mon, Feb 05, 2018 at 05:31:36PM +, Jani Nikula wrote: > Make the logic in intel_detect_pch() easier to follow, and make the PCH > id to type mapping reusable. No functional changes. I wondered here if we should change intel_pch from enum to array { pch_id, pch_type, supported_platforms,

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Improve PSR activation timing

== Series Details == Series: drm/i915: Improve PSR activation timing URL : https://patchwork.freedesktop.org/series/37693/ State : failure == Summary == Applying: drm/i915: Improve PSR activation timing error: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_drv.h). error:

[Intel-gfx] [PATCH] drm/i915: Improve PSR activation timing

The current PSR code has a two call sites that each schedule delayed work to activate PSR. As far as I can tell, each call site intends to keep PSR inactive for the given amount of time and then allow it to be activated. The call sites are: - intel_psr_enable(), which explicitly states in a

Re: [Intel-gfx] i915 PSR test results and cursor lag

On Mon, Feb 5, 2018 at 9:17 PM, Pandiyan, Dhinakaran wrote: > > On Mon, 2018-02-05 at 20:35 +, Andy Lutomirski wrote: >> On Mon, Feb 5, 2018 at 6:53 PM, Pandiyan, Dhinakaran >> wrote: >> > >> > >> > >> > On Sun, 2018-02-04 at

Re: [Intel-gfx] [PATCH igt 2/2] igt/kms_frontbuffer_tracking: Bump the wait time for FBC

On Sat, Feb 03, 2018 at 10:13:36AM +, Chris Wilson wrote: > Quoting Chris Wilson (2018-01-26 21:39:28) > > Quoting Chris Wilson (2018-01-25 21:28:49) > > > It is taking longer than a couple of seconds for the FBC worker to be > > > executed after scheduling; and then will take a minimum of a

[Intel-gfx] ✗ Fi.CI.IGT: warning for Adhering to HDCP1.4 Compliance Test Spec (rev5)

== Series Details == Series: Adhering to HDCP1.4 Compliance Test Spec (rev5) URL : https://patchwork.freedesktop.org/series/37539/ State : warning == Summary == Test kms_plane_multiple: Subgroup atomic-pipe-c-tiling-none: fail -> PASS (shard-apl) fdo#103166

Re: [Intel-gfx] i915 PSR test results and cursor lag

On Mon, 2018-02-05 at 20:35 +, Andy Lutomirski wrote: > On Mon, Feb 5, 2018 at 6:53 PM, Pandiyan, Dhinakaran > wrote: > > > > > > > > On Sun, 2018-02-04 at 21:50 +, Andy Lutomirski wrote: > >> On Sat, Feb 3, 2018 at 5:08 PM, Andy Lutomirski

Re: [Intel-gfx] [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

On Mon, 2018-02-05 at 12:49 -0800, Rodrigo Vivi wrote: > On Mon, Feb 05, 2018 at 08:37:13PM +, Dave Airlie wrote: > > On 6 February 2018 at 06:32, Rodrigo Vivi wrote: > > > On Sat, Feb 03, 2018 at 08:14:48AM +, Keith Packard wrote: > > >> Dhinakaran Pandiyan

Re: [Intel-gfx] [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

On Mon, Feb 05, 2018 at 08:37:13PM +, Dave Airlie wrote: > On 6 February 2018 at 06:32, Rodrigo Vivi wrote: > > On Sat, Feb 03, 2018 at 08:14:48AM +, Keith Packard wrote: > >> Dhinakaran Pandiyan writes: > >> > >> > From: "Pandiyan,

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: pch detection refactoring

== Series Details == Series: drm/i915: pch detection refactoring URL : https://patchwork.freedesktop.org/series/37673/ State : warning == Summary == Test drv_suspend: Subgroup fence-restore-untiled: skip -> PASS (shard-snb) fdo#102365 Test perf:

Re: [Intel-gfx] [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

On 6 February 2018 at 06:32, Rodrigo Vivi wrote: > On Sat, Feb 03, 2018 at 08:14:48AM +, Keith Packard wrote: >> Dhinakaran Pandiyan writes: >> >> > From: "Pandiyan, Dhinakaran" >> > >> >

Re: [Intel-gfx] i915 PSR test results and cursor lag

On Mon, Feb 5, 2018 at 6:53 PM, Pandiyan, Dhinakaran wrote: > > > > On Sun, 2018-02-04 at 21:50 +, Andy Lutomirski wrote: >> On Sat, Feb 3, 2018 at 5:08 PM, Andy Lutomirski wrote: >> > On Sat, Feb 3, 2018 at 5:20 AM, Pandiyan, Dhinakaran >> >

Re: [Intel-gfx] [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

On Sat, Feb 03, 2018 at 08:14:48AM +, Keith Packard wrote: > Dhinakaran Pandiyan writes: > > > From: "Pandiyan, Dhinakaran" > > > > drm_vblank_count() has an u32 type returning what is a 64-bit vblank count. > > The effect of

Re: [Intel-gfx] clang warning: implicit conversion in intel_ddi.c:1481

On Fri, 2018-02-02 at 12:44 +0200, Jani Nikula wrote: > +Knut, Fengguang > > On Fri, 02 Feb 2018, Greg KH wrote: > > - If clang now builds the kernel "cleanly", yes, I want to take > > warning fixes in the stable tree. And even better yet, if you > >

Re: [Intel-gfx] clang warning: implicit conversion in intel_ddi.c:1481

> > We are interested who is we? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] clang warning: implicit conversion in intel_ddi.c:1481

On Fri, 2 Feb 2018, Jani Nikula wrote: > Being brutally honest, please write shorter reports and shorter emails > to the lists. > > The static analysis reports are welcome, but only when 1) we didn't > already fix it in linux-next, or 2) it reveals an actual bug, not just a > warning, warranting

Re: [Intel-gfx] clang warning: implicit conversion in intel_ddi.c:1481

> > What is the goal of these types of emails? > even more so on this mailing list. It almost feels like guerilla advertising for Clang. > thanks, > > greg k-h > > ___ > Kernelnewbies mailing list > kernelnewb...@kernelnewbies.org >

Re: [Intel-gfx] clang warning: implicit conversion in intel_ddi.c:1481

On Fri, 2018-02-02 at 16:50 +0100, Greg KH wrote: > On Fri, Feb 02, 2018 at 04:37:55PM +0200, Jani Nikula wrote: > > On Fri, 02 Feb 2018, Greg KH wrote: > > > On Fri, Feb 02, 2018 at 12:44:38PM +0200, Jani Nikula wrote: > > >> > > >> +Knut, Fengguang > > >> > > >> On

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/pmu: Fix PMU enable vs execlists tasklet race (rev4)

== Series Details == Series: drm/i915/pmu: Fix PMU enable vs execlists tasklet race (rev4) URL : https://patchwork.freedesktop.org/series/37575/ State : warning == Summary == Series 37575v4 drm/i915/pmu: Fix PMU enable vs execlists tasklet race

Re: [Intel-gfx] [PATCH 4/9] drm/i915/psr: Check for the specific AUX_FRAME_SYNC cap bit.

On Wed, 2018-01-31 at 22:48 -0800, Rodrigo Vivi wrote: > On Sat, Jan 27, 2018 at 02:49:18AM +, Dhinakaran Pandiyan wrote: > > The cap check should be specifically for bit 0 instead of any bit. > > > > Any "Fixes:" ? Fixes: 474d1ec4a3d7 ("drm/i915/skl: Enabling PSR2 SU with frame sync")

Re: [Intel-gfx] [PATCH] drm/i915: Deprecate I915_SET_COLORKEY_NONE

On Fri, Feb 02, 2018 at 09:17:08PM +, Chris Wilson wrote: > Quoting Ville Syrjala (2018-02-02 20:42:31) > > From: Ville Syrjälä > > > > Deprecate the silly I915_SET_COLORKEY_NONE flag. The obvious > > way to disable colorkey is to just set flags to 0, which is

[Intel-gfx] ✓ Fi.CI.BAT: success for Adhering to HDCP1.4 Compliance Test Spec (rev5)

== Series Details == Series: Adhering to HDCP1.4 Compliance Test Spec (rev5) URL : https://patchwork.freedesktop.org/series/37539/ State : success == Summary == Series 37539v5 Adhering to HDCP1.4 Compliance Test Spec https://patchwork.freedesktop.org/api/1.0/series/37539/revisions/5/mbox/

Re: [Intel-gfx] i915 PSR test results and cursor lag

On Sun, 2018-02-04 at 21:50 +, Andy Lutomirski wrote: > On Sat, Feb 3, 2018 at 5:08 PM, Andy Lutomirski wrote: > > On Sat, Feb 3, 2018 at 5:20 AM, Pandiyan, Dhinakaran > > wrote: > >> > >> On Fri, 2018-02-02 at 19:18 +, Andy Lutomirski

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/2] drm/i915/cmdparser: Check reg_table_count before derefencing.

== Series Details == Series: series starting with [CI,1/2] drm/i915/cmdparser: Check reg_table_count before derefencing. URL : https://patchwork.freedesktop.org/series/37669/ State : failure == Summary == Test kms_flip: Subgroup 2x-plain-flip-fb-recreate: pass

Re: [Intel-gfx] [PATCH v3 0/8] Adhering to HDCP1.4 Compliance Test Spec

On Sat, Feb 03, 2018 at 03:39:02AM +0530, Ramalingam C wrote: > This series is developed to address the expectations from HDCP compliance > test specification. > > 6/8 patches are for fixing failures in one or more compliance test cases > 2 patches are Good to have kind. Not related to

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: pch detection refactoring

== Series Details == Series: drm/i915: pch detection refactoring URL : https://patchwork.freedesktop.org/series/37673/ State : success == Summary == Series 37673v1 drm/i915: pch detection refactoring https://patchwork.freedesktop.org/api/1.0/series/37673/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH 04/10] drm/amdgpu: Handle 64-bit return from drm_crtc_vblank_count()

On Sat, Feb 3, 2018 at 12:12 AM, Dhinakaran Pandiyan wrote: > 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the > return type for drm_crtc_vblank_count() to u64. This could cause > potential problems if the return value is used in arithmetic

[Intel-gfx] ✗ Fi.CI.BAT: failure for ICL display initialization, selected patches (rev2)

== Series Details == Series: ICL display initialization, selected patches (rev2) URL : https://patchwork.freedesktop.org/series/37668/ State : failure == Summary == Series 37668v2 ICL display initialization, selected patches

[Intel-gfx] [CI] drm/i915/pmu: Fix PMU enable vs execlists tasklet race

From: Tvrtko Ursulin Commit 99e48bf98dd0 ("drm/i915: Lock out execlist tasklet while peeking inside for busy-stats") added a tasklet_disable call in busy stats enabling, but we failed to understand that the PMU enable callback runs as an hard IRQ (IPI). Consequence of

[Intel-gfx] [PATCH v5] drm/i915: Retry HDCP bksv read

HDCP specification says that when bksv is identified as invalid (not with 20 1s), bksv should be re-read and verified. This patch adds the above mentioned re-read for bksv. v2: Rephrased the commit msg [Seanpaul] v3: do-while to for-loop [Seanpaul] v4: retry only if bksv is invalid and

[Intel-gfx] [PATCH 3/4] drm/i915: have virtual PCH detection return a PCH id

Simplify intel_virt_detect_pch() by making it return a PCH id rather than returning the PCH type and setting PCH id for some PCHs. Map the PCH id to PCH type using the shared routine. This gives us sanity check on the supported combinations also in the virtualized setting. Signed-off-by: Jani

[Intel-gfx] [PATCH 4/4] drm/i915: introduce INTEL_PCH_ID() and use it

Cleanup similar to INTEL_PCH_TYPE(). No functional changes. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_drv.h | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h

[Intel-gfx] [PATCH 2/4] drm/i915: abstract virtual PCH id detection

Make the code slightly more pleasant to look at. No functional changes. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_drv.c | 19 --- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c

[Intel-gfx] [PATCH 1/4] drm/i915: abstract PCH type detection from PCH id

Make the logic in intel_detect_pch() easier to follow, and make the PCH id to type mapping reusable. No functional changes. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_drv.c | 148 1 file changed, 73 insertions(+), 75

[Intel-gfx] [PATCH 0/4] drm/i915: pch detection refactoring

This series supersedes https://patchwork.freedesktop.org/series/37581/ BR, Jani. Jani Nikula (4): drm/i915: abstract PCH type detection from PCH id drm/i915: abstract virtual PCH id detection drm/i915: have virtual PCH detection return a PCH id drm/i915: introduce INTEL_PCH_ID() and use

Re: [Intel-gfx] [PATCH v4] drm/i915: Retry HDCP bksv read

On Monday 05 February 2018 10:54 PM, Sean Paul wrote: On Mon, Feb 05, 2018 at 10:44:41PM +0530, Ramalingam C wrote: HDCP specification says that when bksv is identified as invalid (not with 20 1s), bksv should be re-read and verified. This patch adds the above mentioned re-read for bksv.

Re: [Intel-gfx] [PATCH v4] drm/i915: Retry HDCP bksv read

On Mon, Feb 05, 2018 at 10:44:41PM +0530, Ramalingam C wrote: > HDCP specification says that when bksv is identified as invalid > (not with 20 1s), bksv should be re-read and verified. > > This patch adds the above mentioned re-read for bksv. > > v2: > Rephrased the commit msg [Seanpaul] > >

[Intel-gfx] [PATCH 6/6] drm/i915/icl: program mbus during pipe enable

From: Mahesh Kumar This patch program default values of MBus credit during pipe enable. Changes Since V1: - Add WARN_ON (Paulo) - Remove TODO comment - Program 0 during pipe disable - Rebase Changes since V2: - We don't need to do anything when disabling the pipe

[Intel-gfx] [PATCH v4] drm/i915: Retry HDCP bksv read

HDCP specification says that when bksv is identified as invalid (not with 20 1s), bksv should be re-read and verified. This patch adds the above mentioned re-read for bksv. v2: Rephrased the commit msg [Seanpaul] v3: do-while to for-loop [Seanpaul] v4: retry only if bksv is invalid and

Re: [Intel-gfx] [PATCH v3 0/8] Adhering to HDCP1.4 Compliance Test Spec

> -Original Message- > From: Sean Paul [mailto:seanp...@chromium.org] > Sent: Monday, February 5, 2018 10:21 PM > To: C, Ramalingam > Cc: intel-gfx@lists.freedesktop.org; seanp...@chromium.org; Vivi, Rodrigo > ; Sharma, Shashank

Re: [Intel-gfx] [PATCH v3 0/8] Adhering to HDCP1.4 Compliance Test Spec

On Sat, Feb 03, 2018 at 03:39:02AM +0530, Ramalingam C wrote: > This series is developed to address the expectations from HDCP compliance > test specification. > > 6/8 patches are for fixing failures in one or more compliance test cases > 2 patches are Good to have kind. Not related to

Re: [Intel-gfx] [PATCH v3 4/8] drm/i915: Retry HDCP bksv read

On Sat, Feb 03, 2018 at 03:39:06AM +0530, Ramalingam C wrote: > HDCP specification says that when bksv is identified as invalid > (not with 20 1s), bksv should be re-read and verified. > > This patch adds the above mentioned re-read for bksv. > > v2: > Rephrased the commit msg [Seanpaul] > >

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/cmdparser: Check reg_table_count before derefencing.

== Series Details == Series: series starting with [CI,1/2] drm/i915/cmdparser: Check reg_table_count before derefencing. URL : https://patchwork.freedesktop.org/series/37669/ State : success == Summary == Series 37669v1 series starting with [CI,1/2] drm/i915/cmdparser: Check reg_table_count

Re: [Intel-gfx] [PATCH v2] drm/i915/breadcrumbs: Drop request reference for the signaler thread

Quoting Tvrtko Ursulin (2018-02-05 13:45:16) > > On 05/02/2018 13:36, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-02-05 13:23:54) > >> How would you view taking the request->lock over this block in the > >> signaler and then being able to call simply > >> intel_engine_cancel_signaling -

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/breadcrumbs: Drop request reference for the signaler thread (rev2)

Quoting Patchwork (2018-02-03 11:32:01) > == Series Details == > > Series: drm/i915/breadcrumbs: Drop request reference for the signaler thread > (rev2) > URL : https://patchwork.freedesktop.org/series/36908/ > State : failure > > == Summary == > > Test perf_pmu: > Subgroup

[Intel-gfx] [CI 2/2] drm/i915/cmdparser: Do not check past the cmd length.

From: Michal Srb The command MEDIA_VFE_STATE checks bits at offset +2 dwords. However, it is possible to have MEDIA_VFE_STATE command with length = 0 + LENGTH_BIAS = 2. In that case check_cmd will read bits from the following command, or even past the end of the buffer. If the

[Intel-gfx] [CI 1/2] drm/i915/cmdparser: Check reg_table_count before derefencing.

From: Michal Srb The find_reg function was assuming that there is always at least one table in reg_tables. It is not always true. In case of VCS or VECS, the reg_tables is NULL and reg_table_count is 0, implying that no register-accessing commands are allowed. However, the

Re: [Intel-gfx] [PATCH 6/6] drm/i915/icl: program mbus during pipe enable

On Mon, Feb 05, 2018 at 01:40:46PM -0200, Paulo Zanoni wrote: > From: Mahesh Kumar > > This patch program default values of MBus credit during pipe enable. > > Changes since V2: > - We don't need to do anything when disabling the pipe > Changes Since V1: > - Add

[Intel-gfx] ✗ Fi.CI.BAT: warning for ICL display initialization, selected patches

== Series Details == Series: ICL display initialization, selected patches URL : https://patchwork.freedesktop.org/series/37668/ State : warning == Summary == Series 37668v1 ICL display initialization, selected patches https://patchwork.freedesktop.org/api/1.0/series/37668/revisions/1/mbox/

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/4] drm/i915/selftests: Flush old resets between engines

== Series Details == Series: series starting with [CI,1/4] drm/i915/selftests: Flush old resets between engines URL : https://patchwork.freedesktop.org/series/37667/ State : warning == Summary == Series 37667v1 series starting with [CI,1/4] drm/i915/selftests: Flush old resets between

[Intel-gfx] [PATCH 3/6] drm/i915/icl: implement the display init/uninit sequences

This code is similar enough to the CNL code that I considered just adding ICL support to the CNL function, but I think it's still different enough, and having a function specific to ICL allows us to more easily adapt code in case the spec changes more later. We're still missing the power wells

[Intel-gfx] [PATCH 4/6] drm/i915/icl: Enable both DBuf slices during init

From: Mahesh Kumar ICL has 2 slices of DBuf, enable both the slices during display init. Ideally we should only enable the second slice when needed in order to save power, but while we're not there yet, adopt the simpler solution to keep us bug-free. v2 (from Paulo):

[Intel-gfx] [PATCH 6/6] drm/i915/icl: program mbus during pipe enable

From: Mahesh Kumar This patch program default values of MBus credit during pipe enable. Changes since V2: - We don't need to do anything when disabling the pipe Changes Since V1: - Add WARN_ON (Paulo) - Remove TODO comment - Program 0 during pipe disable - Rebase

[Intel-gfx] [PATCH 1/6] drm/i915/icl: add ICL support to cnl_set_procmon_ref_values

On ICL we have two sets of registers: one for port A and another for port B. The set of port A registers is the same as the CNL registers. Since the procmon table on ICL is the same we want to reuse the CNL function. To do that we add a port argument and make CNL always call the function passing

[Intel-gfx] [PATCH 5/6] drm/i915/icl: initialize MBus during display init

From: Mahesh Kumar This patch initializes MBus during display initialization. Changes since V2 (from Paulo): - Don't forget to remove the WARN_ON(1) call. Changes since V1: - Rebase to use function like Macros Reviewed-by: Paulo Zanoni

[Intel-gfx] [PATCH 2/6] drm/i915/icl: add the main CDCLK functions

This commit adds the basic CDCLK functions, but it's still missing pieces of the display initialization sequence. v2: - Implement the voltage levels. - Rebase. v3: - Adjust to the new "bypass" clock (Imre). - Call intel_dump_cdclk_state() too. - Rename a variable to avoid confusion. -

[Intel-gfx] [PATCH 0/6] ICL display initialization, selected patches

Hi These are 6 selected patches form the series "ICL display initialization and some plane bits". Only patch 2 still needs review, the others are already reviewed. The original series of 17 patches triggered some CI errors that definitely seem to be the fault of the series. Some of the patches

[Intel-gfx] [CI 1/4] drm/i915/selftests: Flush old resets between engines

When injecting rapid resets, we must be careful to at least wait for the previous reset to have taken effect and the engine restarted. If we perform a second reset before that has happened, we will notice that the engine hasn't recovered and declare it lost, wedging the device and failing. In

[Intel-gfx] [CI 4/4] drm/i915: Skip post-reset request emission if the engine is not idle

Since commit 7b6da818d86f ("drm/i915: Restore the kernel context after a GPU reset on an idle engine") we submit a request following the engine reset. The intent is that we don't submit a request if the engine is busy (as it will restart active by itself) but we only checked to see if there were

[Intel-gfx] [CI 3/4] drm/i915/execlists: Move the reset bits to a more natural home

In preparation for the next patch, we want the engine to appear idle after a reset (if there are no requests in flight). For execlists, this entails clearing the active status on reset, it will be regenerated on restarting the engine after the reset. In the process, note that a couple of other

Re: [Intel-gfx] [PATCH 04/10] drm/amdgpu: Handle 64-bit return from drm_crtc_vblank_count()

On 2018-02-03 12:12 AM, Dhinakaran Pandiyan wrote: > 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the > return type for drm_crtc_vblank_count() to u64. This could cause > potential problems if the return value is used in arithmetic operations > with a 32-bit reference HW vblank

Re: [Intel-gfx] [PATCH 3/7] drm/i915/execlists: Move the reset bits to a more natural home

Chris Wilson writes: > In preparation for the next patch, we want the engine to appear idle > after a reset (if there are no requests in flight). For execlists, this > entails clearing the active status on reset, it will be regenerated on > restarting the engine after

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/2] drm/i915/selftests: Flush old resets between engines

== Series Details == Series: series starting with [CI,1/2] drm/i915/selftests: Flush old resets between engines URL : https://patchwork.freedesktop.org/series/37661/ State : warning == Summary == Series 37661v1 series starting with [CI,1/2] drm/i915/selftests: Flush old resets between

Re: [Intel-gfx] [PATCH] drm/crc: Add support for polling on the data fd.

Op 05-02-18 om 15:16 schreef Ville Syrjälä: > On Mon, Feb 05, 2018 at 01:59:05PM +0100, Maarten Lankhorst wrote: >> Op 02-02-18 om 15:46 schreef Ville Syrjälä: >>> On Fri, Feb 02, 2018 at 03:27:43PM +0100, Maarten Lankhorst wrote: This will make it possible for userspace to know whether

[Intel-gfx] [CI 1/2] drm/i915/selftests: Flush old resets between engines

When injecting rapid resets, we must be careful to at least wait for the previous reset to have taken effect and the engine restarted. If we perform a second reset before that has happened, we will notice that the engine hasn't recovered and declare it lost, wedging the device and failing. In

[Intel-gfx] [CI 2/2] drm/i915/selftests: Use a sacrificial context for hang testing

Avoid injecting hangs in to the i915->kernel_context in case the GPU reset leaves corruption in the context image in its wake (leading to continual failures and system hangs after the selftests are ostensibly complete). Use a sacrificial kernel_context instead. v2: Closing a context is tricky;

Re: [Intel-gfx] [PATCH 1/7] drm/i915/selftests: Flush old resets between engines

Chris Wilson writes: > When injecting rapid resets, we must be careful to at least wait for the > previous reset to have taken effect and the engine restarted. If we > perform a second reset before that has happened, we will notice that the > engine hasn't recovered and

Re: [Intel-gfx] [PATCH] drm/crc: Add support for polling on the data fd.

On Mon, Feb 05, 2018 at 01:59:05PM +0100, Maarten Lankhorst wrote: > Op 02-02-18 om 15:46 schreef Ville Syrjälä: > > On Fri, Feb 02, 2018 at 03:27:43PM +0100, Maarten Lankhorst wrote: > >> This will make it possible for userspace to know whether reading > >> will block, without blocking on the fd.

Re: [Intel-gfx] [PATCH 2/7] drm/i915/selftests: Use a sacrificial context for hang testing

Quoting Mika Kuoppala (2018-02-05 14:02:55) > Chris Wilson writes: > > diff --git a/drivers/gpu/drm/i915/selftests/mock_context.c > > b/drivers/gpu/drm/i915/selftests/mock_context.c > > index bbf80d42e793..501becc47c0c 100644 > > ---

Re: [Intel-gfx] [PATCH 2/7] drm/i915/selftests: Use a sacrificial context for hang testing

Chris Wilson writes: > Avoid injecting hangs in to the i915->kernel_context in case the GPU > reset leaves corruption in the context image in its wake (leading to > continual failures and system hangs after the selftests are ostensibly > complete). Use a sacrificial

Re: [Intel-gfx] [PATCH v2] drm/i915/breadcrumbs: Drop request reference for the signaler thread

On 05/02/2018 13:36, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-02-05 13:23:54) On 03/02/2018 10:19, Chris Wilson wrote: @@ -656,41 +705,21 @@ static int intel_breadcrumbs_signaler(void *arg) * a new client. */ rcu_read_lock(); -

  1   2   >