[Intel-gfx] [PATCH v2] drm/i915/guc: Update syntax of GuC log functions

We moved GuC log related data and code to separate files and definition but we didn't change functions syntax to follow object-verb pattern. Let's fix that before we continue with next round of code refactoring. v2: rebased Signed-off-by: Michal Wajdeczko Cc: Michal

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Engine discovery query

== Series Details == Series: drm/i915: Engine discovery query URL : https://patchwork.freedesktop.org/series/39958/ State : success == Summary == Series 39958v1 drm/i915: Engine discovery query https://patchwork.freedesktop.org/api/1.0/series/39958/revisions/1/mbox/ Known issues: Test

Re: [Intel-gfx] [PATCH] drm/i915/guc: Update syntax of GuC log functions

On Tue, Mar 13, 2018 at 12:26:37PM +, Michal Wajdeczko wrote: > We moved GuC log related data and code to separate files and > definition but we didn't change functions syntax to follow > object-verb pattern. Let's fix that before we continue with > next round of code refactoring. > >

Re: [Intel-gfx] [PATCH] drm/i915: Check rq->timeline before deference

Quoting Mika Kuoppala (2018-03-14 14:16:08) > Chris Wilson writes: > > > Not only is the context suspect to disappearing, but so is it's > > timeline. Under a lockless inspection of the requests for > > debugging from intel_engine_dump(), the context may already have

Re: [Intel-gfx] [PATCH] drm/i915: Check rq->timeline before deference

Chris Wilson writes: > Not only is the context suspect to disappearing, but so is it's > timeline. Under a lockless inspection of the requests for > debugging from intel_engine_dump(), the context may already have been > freed and we have to check before chasing the

[Intel-gfx] [PATCH v8 11/11] drm: Add and handle new aspect ratios in DRM layer

From: "Sharma, Shashank" HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch: - Adds new DRM flags for to represent these new aspect ratios. - Adds new cases to handle these aspect ratios while converting from user->kernel mode or vise

[Intel-gfx] [PATCH v8 10/11] drm: Add aspect ratio parsing in DRM layer

From: "Sharma, Shashank" Current DRM layer functions don't parse aspect ratio information while converting a user mode->kernel mode or vice versa. This causes modeset to pick mode with wrong aspect ratio, eventually causing failures in HDMI compliance test cases, due

[Intel-gfx] [PATCH v8 09/11] drm: Expose modes with aspect ratio, only if requested

From: Ankit Nautiyal We parse the EDID and add all the modes in the connector's modelist. This adds CEA modes with aspect ratio information too, regadless of whether user space requested this information or not. This patch prunes the modes with aspect-ratio

[Intel-gfx] [PATCH v8 08/11] drm: Handle aspect ratio info in legacy and atomic modeset paths

From: Ankit Nautiyal If the user-space does not support aspect-ratio, and requests for a modeset with mode having aspect ratio bits set, then the given user-mode must be rejected. Secondly, while preparing a user-mode from kernel mode, the aspect-ratio info must not

[Intel-gfx] [PATCH v8 04/11] drm/edid: Don't send bogus aspect ratios in AVI infoframes

From: Ville Syrjälä If the user mode would specify an aspect ratio other than 4:3 or 16:9 we now silently ignore it. Maybe a better apporoach is to return an error? Let's try that. Also we must be careful that we don't try to send illegal picture aspect in the

[Intel-gfx] [PATCH v8 03/11] drm/edid: Fix cea mode aspect ratio handling

From: Ville Syrjälä commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer") cause us to not send out any VICs in the AVI infoframes. That commit was since reverted, but if and when we add aspect ratio handing back we need to be more careful. Let's

[Intel-gfx] [PATCH v8 06/11] drm: Add DRM client cap for aspect-ratio

From: Ankit Nautiyal To enable aspect-ratio support in DRM, blindly exposing the aspect ratio information along with mode, can break things in existing user-spaces which have no intention or support to use this aspect ratio information. To avoid this, a new drm

[Intel-gfx] [PATCH v8 02/11] drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy

From: Ville Syrjälä Use drm_mode_equal_no_clocks_no_stereo() in drm_match_hdmi_mode_clock_tolerance() for consistency as we also use it in drm_match_hdmi_mode() and the cea mode matching functions. This doesn't actually change anything since the input mode comes

[Intel-gfx] [PATCH v8 07/11] drm: Handle aspect-ratio info in getblob

From: Ankit Nautiyal If the user-space does not support aspect-ratio, then getblob called with the blob id of a user-mode, should clear the aspect-ratio information in the blob data. Currently for a given blob id, there is no way to determine if the blob stores

[Intel-gfx] [PATCH v8 05/11] video/hdmi: Reject illegal picture aspect ratios

From: Ville Syrjälä AVI infoframe can only carry none, 4:3, or 16:9 picture aspect ratios. Return an error if the user asked for something different. Cc: Shashank Sharma Cc: "Lin, Jia" Cc: Akashdeep Sharma

[Intel-gfx] [PATCH v8 01/11] drm/modes: Introduce drm_mode_match()

From: Ville Syrjälä Make mode matching less confusing by allowing the caller to specify which parts of the modes should match via some flags. Signed-off-by: Ville Syrjälä Reviewed-by: Shashank Sharma ---

[Intel-gfx] [PATCH v8 00/11] Aspect ratio support in DRM layer

From: Ankit Nautiyal This patch series is a re-attempt to enable aspect ratio support in DRM layer. Currently the aspect ratio information gets lost in translation during a user->kernel mode or vice versa. The old patch series

[Intel-gfx] [RFC] drm/i915: Engine discovery query

From: Tvrtko Ursulin Engine discovery query allows userspace to enumerate engines, probe their configuration features, all without needing to maintain the internal PCI ID based database. A new query for the generic i915 query ioctl is added named

Re: [Intel-gfx] [PATCH 2/3] drm: Make drm_mode_vrefresh() a bit more accurate

On Tue, Mar 13, 2018 at 05:07:58PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Do the refresh rate calculation with a single division. This gives > us slightly more accurate results, especially for interlaced since > we don't just double the final

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v13,1/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

Quoting Joonas Lahtinen (2018-03-14 15:10:46) > Quoting Michal Wajdeczko (2018-03-14 14:47:28) > > On Wed, 14 Mar 2018 13:31:46 +0100, Joonas Lahtinen > > wrote: > > > > > Quoting Patchwork (2018-03-14 06:23:25) > > >> == Series Details == > > >> > > >> Series:

Re: [Intel-gfx] [PATCH] drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.

On Tue, Mar 13, 2018 at 10:48:25PM -0700, Dhinakaran Pandiyan wrote: > If bios sets up an MST output and hardware state readout code sees this is > an SST configuration, when disabling the encoder we end up calling > ->post_disable_dp() hook instead of the MST version. Consequently, we write > to

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v13,1/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

Quoting Michal Wajdeczko (2018-03-14 14:47:28) > On Wed, 14 Mar 2018 13:31:46 +0100, Joonas Lahtinen > wrote: > > > Quoting Patchwork (2018-03-14 06:23:25) > >> == Series Details == > >> > >> Series: series starting with [v13,1/6] drm/i915/guc: Rename > >>

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Check rq->timeline before deference

== Series Details == Series: drm/i915: Check rq->timeline before deference URL : https://patchwork.freedesktop.org/series/39949/ State : warning == Summary == Possible new issues: Test gem_pwrite: Subgroup big-cpu-backwards: pass -> SKIP (shard-apl)

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v13,1/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

On Wed, 14 Mar 2018 13:31:46 +0100, Joonas Lahtinen wrote: Quoting Patchwork (2018-03-14 06:23:25) == Series Details == Series: series starting with [v13,1/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset URL :

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

Quoting Jackie Li (2018-03-14 02:32:53) > GuC WOPCM registers are write-once registers. Current driver code accesses > these registers without checking the accessibility to these registers which > will lead to unpredictable driver behaviors if these registers were touch > by other components (such

Re: [Intel-gfx] [PATCH v13 4/6] drm/i915: Add HuC firmware size related restriction for Gen9 and CNL A0

Quoting Jackie Li (2018-03-14 02:32:52) > 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 adds new verification code to ensure the available GuC WOPCM > size to be larger than or equal

Re: [Intel-gfx] [PATCH v13 3/6] drm/i915: Add support to return CNL specific reserved WOPCM size

Quoting Jackie Li (2018-03-14 02:32:51) > CNL has its specific reserved GuC WOPCM size for RC6 and other hardware > contexts. > > This patch updates the code to return CNL specific reserved GuC WOPCM size > for RC6 and other hardware contexts so that the GuC WOPCM size can be > calculated

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

Quoting Jackie Li (2018-03-14 02:32:49) > 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

Re: [Intel-gfx] [PATCH v13 2/6] drm/i915: Implement dynamic GuC WOPCM offset and size calculation

Quoting Jackie Li (2018-03-14 02:32:50) > 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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Control PSR at runtime through debugfs only

== Series Details == Series: drm/i915: Control PSR at runtime through debugfs only URL : https://patchwork.freedesktop.org/series/39955/ State : failure == Summary == Series 39955v1 drm/i915: Control PSR at runtime through debugfs only

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v13,1/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

Quoting Patchwork (2018-03-14 06:23:25) > == Series Details == > > Series: series starting with [v13,1/6] drm/i915/guc: Rename guc_ggtt_offset > to intel_guc_ggtt_offset > URL : https://patchwork.freedesktop.org/series/39919/ > State : failure > > == Summary == > > Possible new issues:

Re: [Intel-gfx] [PATCH] drm/i915: drop various VLAs in i915_debugfs.c

Quoting Salvatore Mesoraca (2018-03-13 21:51:28) > Avoid 3 VLAs[1] by using real constant expressions instead of variables. > The compiler should be able to optimize the original code and avoid using > any actual VLAs. Anyway this change is useful because it will avoid a false > positives with

Re: [Intel-gfx] [PATCH] drm/i915: drop various VLAs in i915_debugfs.c

On Tue, 13 Mar 2018, Salvatore Mesoraca wrote: > Avoid 3 VLAs[1] by using real constant expressions instead of variables. > The compiler should be able to optimize the original code and avoid using > any actual VLAs. Anyway this change is useful because it will avoid a

[Intel-gfx] [PATCH] drm/i915: Control PSR at runtime through debugfs only

Allow controlling link status through i915_edp_psr_status, in the same way kernel does. This replaces changing the module parameter at runtime, then forcing a modeset. Writing -1 restores the original PSR mode set through the module parameter. Writing 0 disables PSR. Writing 1 enables PSR with

[Intel-gfx] drm-intel geared towards v4.18

All, as Joonas sent the final drm-intel feature pull request for v4.17 [1], the drm-intel-next-queued branch is now geared towards v4.18. As Joonas follows through with fixes for v4.17, I take over features for v4.18. Rodrigo continues with the final v4.16 development cycles. The merge deadline

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/36] drm/i915/stolen: Switch from DEBUG_KMS to DEBUG_DRIVER

== Series Details == Series: series starting with [01/36] drm/i915/stolen: Switch from DEBUG_KMS to DEBUG_DRIVER URL : https://patchwork.freedesktop.org/series/39948/ State : failure == Summary == Possible new issues: Test drv_selftest: Subgroup live_hangcheck:

Re: [Intel-gfx] [PATCH] drm/i915/pmu: Work around compiler warnings on some kernel configs

Quoting Tvrtko Ursulin (2018-03-14 08:05:35) > From: Tvrtko Ursulin > > Arnd Bergman reports: > """ > The conditional spinlock confuses gcc into thinking the 'flags' value > might contain uninitialized data: > > drivers/gpu/drm/i915/i915_pmu.c: In function

Re: [Intel-gfx] [PATCH i-g-t] HACK: enable the chamelium HDMI-CRC-multiple test

A reminder that there's a separate IGT mailing list at https://lists.freedesktop.org/mailman/listinfo/igt-dev -- Petri Latvala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH i-g-t 3/3] tests: Add vc4 test suite

On Tue, Mar 13, 2018 at 04:18:54PM +0100, Maxime Ripard wrote: > Hi, > > On Tue, Mar 13, 2018 at 12:42:02PM +0200, Petri Latvala wrote: > > On Mon, Mar 05, 2018 at 03:21:29PM +0100, Maxime Ripard wrote: > > > Add some various test suites relevant for the vc4 drm driver. > > > > > >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Check rq->timeline before deference

== Series Details == Series: drm/i915: Check rq->timeline before deference URL : https://patchwork.freedesktop.org/series/39949/ State : success == Summary == Series 39949v1 drm/i915: Check rq->timeline before deference https://patchwork.freedesktop.org/api/1.0/series/39949/revisions/1/mbox/

Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max scale for NV12

> -Original Message- > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com] > Sent: Wednesday, March 14, 2018 4:03 PM > To: Srinivas, Vidya ; intel- > g...@lists.freedesktop.org > Cc: Syrjala, Ville ; Lankhorst, Maarten >

[Intel-gfx] ✗ Fi.CI.IGT: warning for CNL port refactoring (rev4)

== Series Details == Series: CNL port refactoring (rev4) URL : https://patchwork.freedesktop.org/series/38334/ State : warning == Summary == Possible new issues: Test gem_pwrite: Subgroup big-cpu-backwards: skip -> PASS (shard-apl) Test

Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max scale for NV12

Op 14-03-18 om 11:31 schreef Srinivas, Vidya: > >> -Original Message- >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com] >> Sent: Wednesday, March 14, 2018 3:55 PM >> To: Srinivas, Vidya ; intel- >> g...@lists.freedesktop.org >> Cc: Syrjala,

Re: [Intel-gfx] [PATCH v13 17/17] drm/i915: Display WA 827

> -Original Message- > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com] > Sent: Wednesday, March 14, 2018 2:43 PM > To: Srinivas, Vidya ; intel- > g...@lists.freedesktop.org > Cc: Syrjala, Ville ; Lankhorst, Maarten >

Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max scale for NV12

> -Original Message- > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com] > Sent: Wednesday, March 14, 2018 3:55 PM > To: Srinivas, Vidya ; intel- > g...@lists.freedesktop.org > Cc: Syrjala, Ville ; Lankhorst, Maarten >

Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max scale for NV12

Op 14-03-18 om 10:52 schreef Maarten Lankhorst: > Op 09-03-18 om 09:48 schreef Vidya Srinivas: >> From: Chandra Konduru >> >> This patch updates scaler max limit support for NV12 >> >> v2: Rebased (me) >> >> v3: Rebased (me) >> >> v4: Missed the Tested-by/Reviewed-by in

Re: [Intel-gfx] [CI] drm/i915: Split GPU commands definitions into separate header

Quoting Chris Wilson (2018-03-13 23:19:20) > From: Michal Wajdeczko > > We should not mix MMIO with MI_INSTR definitions. > > v2: sanitize comment, change include order (Chris) > > Suggested-by: Chris Wilson > Signed-off-by: Michal

[Intel-gfx] [PATCH] drm/i915: Check rq->timeline before deference

Not only is the context suspect to disappearing, but so is it's timeline. Under a lockless inspection of the requests for debugging from intel_engine_dump(), the context may already have been freed and we have to check before chasing the dangling pointer. [28033.681755] Modules linked in: vgem

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/36] drm/i915/stolen: Switch from DEBUG_KMS to DEBUG_DRIVER

== Series Details == Series: series starting with [01/36] drm/i915/stolen: Switch from DEBUG_KMS to DEBUG_DRIVER URL : https://patchwork.freedesktop.org/series/39948/ State : success == Summary == Series 39948v1 series starting with [01/36] drm/i915/stolen: Switch from DEBUG_KMS to

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/36] drm/i915/stolen: Switch from DEBUG_KMS to DEBUG_DRIVER

== Series Details == Series: series starting with [01/36] drm/i915/stolen: Switch from DEBUG_KMS to DEBUG_DRIVER URL : https://patchwork.freedesktop.org/series/39948/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/stolen: Switch from DEBUG_KMS to DEBUG_DRIVER

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/pmu: Work around compiler warnings on some kernel configs

== Series Details == Series: drm/i915/pmu: Work around compiler warnings on some kernel configs URL : https://patchwork.freedesktop.org/series/39939/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight-contexts: pass -> INCOMPLETE

Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max scale for NV12

Op 09-03-18 om 09:48 schreef Vidya Srinivas: > From: Chandra Konduru > > This patch updates scaler max limit support for NV12 > > v2: Rebased (me) > > v3: Rebased (me) > > v4: Missed the Tested-by/Reviewed-by in the previous series > Adding the same to commit message in

Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

On 3/14/2018 2:33 PM, Chris Wilson wrote: Quoting Sagar Arun Kamble (2018-03-14 08:15:15) On 3/13/2018 7:28 PM, Chris Wilson wrote: Exercise some new API that allows applications to request that individual contexts are executed within a desired frequency range. v2: Split single/continuous

[Intel-gfx] [PATCH 26/36] drm/i915: Reorder GT interface code

Try to order the intel_gt_pm code to match the order it is used: init enable disable cleanup Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_gt_pm.c | 170 ++---

[Intel-gfx] [PATCH 24/36] drm/i915: Track HAS_RPS alongside HAS_RC6 in the device info

For consistency (and elegance!), add intel_device_info.has_rps. The immediate boon is that RPS support is now emitted along the other capabilities in the debug log and after errors. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 2 ++

[Intel-gfx] [PATCH 29/36] drm/i915: Simplify rc6/rps enabling

As we know that whenever the GT is awake, rc6 and rps are enabled (if available), then we can remove the individual tracking and enabling to the gen6_rps_busy/gen6_rps_idle() (now called intel_gt_pm_busy and intel_gt_pm_idle) entry points. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 01/36] drm/i915/stolen: Switch from DEBUG_KMS to DEBUG_DRIVER

i915_gem_stolen is an allocator for the reserved portion of memory ("stolen" from the system by the BIOS). It is not tied to KMS but central to the driver, so prefer DRM_DEBUG_DRIVER. Signed-off-by: Chris Wilson Reviewed-by: Ville Syrjälä

[Intel-gfx] [PATCH 35/36] drm/i915: Remove unwarranted clamping for hsw/bdw

We always start off at an "efficient frequency" and can let the system autotune from there, eliminating the need to clamp the available range. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_gt_pm.c | 9 + 1 file changed, 1 insertion(+), 8

[Intel-gfx] [PATCH 30/36] drm/i915: Refactor frequency bounds computation

When choosing the initial frequency in intel_gt_pm_busy() we also need to calculate the current min/max bounds. As this calculation is going to become more complex with the intersection of several different limits, refactor it to a common function. The alternative wold be to feed the initial

[Intel-gfx] [PATCH 25/36] drm/i915: Remove defunct intel_suspend_gt_powersave()

Since commit b7137e0cf1e5 ("drm/i915: Defer enabling rc6 til after we submit the first batch/context"), intel_suspend_gt_powersave() has been a no-op. As we still do not need to do anything explicitly on suspend (we do everything required on idling), remove the defunct function. References:

[Intel-gfx] [PATCH 23/36] drm/i915: Move all the RPS irq handlers to intel_gt_pm

Since all the RPS handling code is in intel_gt_pm, move the irq handlers there as well so that it all contained within one file. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 10 +- drivers/gpu/drm/i915/i915_irq.c | 287

[Intel-gfx] [PATCH 28/36] drm/i915: Enabling rc6 and rps have different requirements, so separate them

On Ironlake, we are required to not enable rc6 until the GPU is loaded with a valid context; after that point it can start to use a powersaving context for rc6. This seems a reasonable requirement to impose on all generations as we are already priming the system by loading a context on resume. We

[Intel-gfx] [PATCH 34/36] drm/i915, intel_ips: Enable GPU wait-boosting with IPS

Refactor the reclocking logic used by RPS on Ironlake to reuse the infrastructure developed for RPS on Sandybridge+, along with the waitboosting support for stalled clients and missed frames. Reported-by: di...@gmx.net Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90137 Signed-off-by:

[Intel-gfx] [PATCH 27/36] drm/i915: Split control of rps and rc6

Allow ourselves to individually toggle rps or rc6. This will be used later when we want to enable rps/rc6 at different phases during the device bring up. Whilst here, convert the intel_$verb_gt_powersave over to intel_gt_pm_$verb scheme. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 22/36] drm/i915: Move rps worker to intel_gt_pm.c

The RPS worker exists to do the bidding of the GT powermanagement, so move it from i915_irq to intel_gt_pm.c where it can be hidden from the rest of the world. The goal being that the RPS worker is the one true way though which all RPS updates are coordinated. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 33/36] drm/i915: Pull IPS into RPS

IPS was the precursor to RPS on Ironlake. It serves the same function, and so should be pulled under the intel_gt_pm umbrella. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h| 37 - drivers/gpu/drm/i915/i915_irq.c| 21 +-

[Intel-gfx] [PATCH 32/36] drm/i915: Rename rps min/max frequencies

In preparation for more layers of limits, rename the existing limits to hw and user. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 34 drivers/gpu/drm/i915/i915_drv.h | 21 +++-- drivers/gpu/drm/i915/i915_pmu.c | 4 +-

[Intel-gfx] [PATCH 36/36] drm/i915: Support per-context user requests for GPU frequency control

Often, we find ourselves facing a workload where the user knows in advance what GPU frequency they require for it to complete in a timely manner, and using past experience they can outperform the HW assisted RPS autotuning. An example might be kodi (HTPC) where they know that video decoding and

[Intel-gfx] [PATCH 31/36] drm/i915: Don't fiddle with rps/rc6 across GPU reset

Resetting the GPU doesn't affect the RPS/RC6 state, so we can stop forcibly reloading the registers. Signed-off-by: Chris Wilson Cc: Ville Syrjälä --- drivers/gpu/drm/i915/i915_gem.c | 4 1 file changed, 4 deletions(-) diff --git

[Intel-gfx] [PATCH 18/36] drm/i915: Enable render context support for Ironlake (gen5)

Ironlake does support being able to saving and reloading context specific registers between contexts, providing isolation of the basic GPU state (as programmable by userspace). This allows userspace to assume that the GPU retains their state from one batch to the next, minimising the amount of

[Intel-gfx] [PATCH 17/36] drm/i915: Generalize i915_gem_sanitize() to reset contexts

While we believe that we need to always reset the GPU to scrub the state on transition to/from the driver, it is essential when we enable contexts. Generalize the gen test to be on context-support instead. References: d2b4b97933f5 ("drm/i915: Record the default hw state after reset upon load"

[Intel-gfx] [PATCH 20/36] drm/i915: Remove obsolete min/max freq setters from debugfs

A more complete, and more importantly stable, interface for controlling the RPS frequency range is available in sysfs, obsoleting the unstable debugfs. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 115 1

[Intel-gfx] [PATCH 15/36] drm/i915: Mark up Ironlake ips with rpm wakerefs

Currently Ironlake operates under the assumption that rpm awake (and its error checking is disabled). As such, we have missed a few places where we access registers without taking the rpm wakeref and thus trigger warnings. intel_ips being one culprit. As this involved adding a potentially

[Intel-gfx] [PATCH 19/36] drm/i915: Enable render context support for gen4 (Broadwater to Cantiga)

Broadwater and the rest of gen4 do support being able to saving and reloading context specific registers between contexts, providing isolation of the basic GPU state (as programmable by userspace). This allows userspace to assume that the GPU retains their state from one batch to the next,

[Intel-gfx] [PATCH 12/36] drm/i915: Merge sbi read/write into a single accessor

Since intel_sideband_read and intel_sideband_write differ by only a couple of lines (depending on whether we feed the value in or out), merge the two into a single common accessor. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_sideband.c | 93

[Intel-gfx] [PATCH 07/36] drm/i915: Lift sideband locking for vlv_punit_(read|write)

Lift the sideband acquisition for vlv_punit_read and vlv_punit_write into their callers, so that we can lock the sideband once for a sequence of operations, rather than perform the heavyweight acquisition on each request. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 06/36] drm/i915: Lift acquiring the vlv punit magic to a common sb-get

As we now employ a very heavy pm_qos around the punit access, we want to minimise the number of synchronous requests by performing one for the whole punit sequence rather than around individual accesses. The sideband lock is used for this, so push the pm_qos into the sideband lock acquisition and

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

With the vlv sideband fixed to avoid sleeping while we talk to the punit, the system should be much more stable and be able to utilise the punit without risk. This reverts commit 6067a27d1f01 ("drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3") References: 6067a27d1f01 ("drm/i915:

[Intel-gfx] [PATCH 13/36] drm/i915: Merge sandybridge_pcode_(read|write)

These routines are identical except in the nature of the value parameter. For writes it is a pure in-param, but for a read, we need an out-param. Since they differ in a single line, merge the two routines into one. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 08/36] drm/i915: Reduce RPS update frequency on Valleyview/Cherryview

Valleyview and Cherryview update the GPU frequency via the punit, which is very expensive as we have to ensure the cores do not sleep during the comms. If we perform frequent RPS evaluations, the frequent punit requests cause measurable system overhead for little benefit, so increase the

[Intel-gfx] [PATCH 16/36] drm/i915: Record logical context support in driver caps

Avoid looking at the magical engines[RCS] to decide if the HW and driver supports logical contexts, and instead record that knowledge during initialisation. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 1 +

[Intel-gfx] [PATCH 14/36] drm/i915: Move sandybride pcode access to intel_sideband.c

sandybride_pcode is another sideband, so move it to their new home. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 10 -- drivers/gpu/drm/i915/intel_hdcp.c | 3 +- drivers/gpu/drm/i915/intel_pm.c | 194

[Intel-gfx] [PATCH 04/36] drm/i915: Trim error mask to known engines

For the convenience of userspace passing in an arbitrary reset mask, remove unknown engines from the set of engines that are to be reset. This means that we always follow a per-engine reset with a full-device reset when userspace writes -1 into debugfs/i915_wedged. Reported-by: Michał Winiarski

[Intel-gfx] [PATCH 11/36] drm/i915: Separate sideband declarations to intel_sideband.h

Split the sideback declarations out of the ginormous i915_drv.h Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 2 + drivers/gpu/drm/i915/i915_drv.h | 62 drivers/gpu/drm/i915/i915_sysfs.c | 2 +

[Intel-gfx] [PATCH 10/36] drm/i915: Replace pcu_lock with sb_lock

We now have two locks for sideband access. The general one covering sideband access across all generation, sb_lock, and a specific one covering sideband access via the punit on vlv/chv. After lifting the sb_lock around the punit into the callers, the pcu_lock is now redudant and can be separated

[Intel-gfx] [PATCH 02/36] drm/i915/stolen: Checkpatch cleansing

In the next patch, we will introduce a new vlv_get_stolen_reserved, so before we do, make sure checkpatch is happy with the surrounding code. Sneak in some debug output while we are here. Signed-off-by: Chris Wilson Cc: Ville Syrjälä ---

[Intel-gfx] [PATCH 05/36] drm/i915: Disable preemption and sleeping while using the punit sideband

While we talk to the punit over its sideband, we need to prevent the cpu from sleeping in order to prevent a potential machine hang. Note that by itself, it appears that pm_qos_update_request (via intel_idle) doesn't provide a sufficient barrier to ensure that all core are indeed awake (out of

[Intel-gfx] [PATCH 03/36] drm/i915/stolen: Deduce base of reserved portion as top-size on vlv

On Valleyview, the HW deduces the base of the reserved portion of stolen memory as being (top - size) and the address field within GEN6_STOLEN_RESERVED is set to 0. Add yet another GEN6_STOLEN_RESERVED reader to cope with the subtly different path required for vlv. v2: Avoid using reserved_base =

Re: [Intel-gfx] [PATCH v3 1/1] drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric

On 3/2/2018 3:44 PM, Sagar Arun Kamble wrote: On 3/2/2018 2:01 PM, Chris Wilson wrote: Quoting Sagar Arun Kamble (2018-03-01 16:45:45) +static int huc_fw_xfer(struct intel_uc_fw *huc_fw, struct i915_vma *vma) +{ +   struct intel_huc *huc = container_of(huc_fw, struct intel_huc, fw);

Re: [Intel-gfx] [PATCH v13 17/17] drm/i915: Display WA 827

Op 09-03-18 om 09:49 schreef Vidya Srinivas: > Display WA 827 applies to GEN9 (excluede GLK) and CNL. > Switching the plane format from NV12 to RGB and leaving system idle > results in display underrun and corruption. > WA: Set the bit 15 & bit 19 to 1b in the CLKGATE_DIS_PSL > register for the

Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

Quoting Sagar Arun Kamble (2018-03-14 08:15:15) > > > On 3/13/2018 7:28 PM, Chris Wilson wrote: > > Exercise some new API that allows applications to request that > > individual contexts are executed within a desired frequency range. > > > > v2: Split single/continuous set_freq subtests > > v3:

Re: [Intel-gfx] [DIM PATCH 3/3] dim: loosen some drm-intel checkpatch rules

On Tue, 13 Mar 2018, Daniel Vetter wrote: > On Tue, Mar 13, 2018 at 01:30:10PM +0200, Jani Nikula wrote: >> Set max line length to 100. I don't want to silence the LONG_LINE >> warning altogether, and I'd still prefer to keep lines under 80 >> characters, but I also don't want to

Re: [Intel-gfx] [DIM PATCH 2/3] dim: add checkpatch profiles to allow different checkpatch options

On Wed, 14 Mar 2018, Daniel Vetter wrote: > On Tue, Mar 13, 2018 at 4:07 PM, Jani Nikula wrote: >> On Tue, 13 Mar 2018, Daniel Vetter wrote: >>> On Tue, Mar 13, 2018 at 01:30:09PM +0200, Jani Nikula wrote: To reduce noise on CI

[Intel-gfx] ✓ Fi.CI.BAT: success for CNL port refactoring (rev4)

== Series Details == Series: CNL port refactoring (rev4) URL : https://patchwork.freedesktop.org/series/38334/ State : success == Summary == Series 38334v4 CNL port refactoring https://patchwork.freedesktop.org/api/1.0/series/38334/revisions/4/mbox/ Known issues: Test debugfs_test:

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.

== Series Details == Series: drm/i915/dp: Write to SET_POWER dpcd to enable MST hub. URL : https://patchwork.freedesktop.org/series/39927/ State : failure == Summary == Possible new issues: Test gem_pwrite: Subgroup big-cpu-backwards: skip -> PASS

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Work around compiler warnings on some kernel configs

== Series Details == Series: drm/i915/pmu: Work around compiler warnings on some kernel configs URL : https://patchwork.freedesktop.org/series/39939/ State : success == Summary == Series 39939v1 drm/i915/pmu: Work around compiler warnings on some kernel configs

Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

On 3/13/2018 7:28 PM, Chris Wilson wrote: Exercise some new API that allows applications to request that individual contexts are executed within a desired frequency range. v2: Split single/continuous set_freq subtests v3: Do an up/down ramp for individual freq request, check nothing changes

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/pmu: Work around compiler warnings on some kernel configs

== Series Details == Series: drm/i915/pmu: Work around compiler warnings on some kernel configs URL : https://patchwork.freedesktop.org/series/39939/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/pmu: Work around compiler warnings on some kernel configs

[Intel-gfx] [PATCH v4 1/2] drm/i915/cnl; Add macro to get PORT_TX register

This patch creates a new macro to get PORT_TX register for any given DW. This removes the need of defining register address for each port & DW. Changes since V1: - Use underscope prefix, as macro isn't returning an mmio reg(Lucas) - Merge patch 1 & 2 of the series Changes since V2: - remove

[Intel-gfx] [PATCH v4 2/2] drm/i915/cnl: Kill _MMIO_PORT6 macro

This patch replaces use of remaining _MMIO_PORT6 macro and removes the macro. Changes Since V1: - Rebase Signed-off-by: Mahesh Kumar Reviewed-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_reg.h | 10 +- 1 file changed, 5

<    1   2   3   >