Re: [Intel-gfx] [PATCH v3 3/4] drm/i915: Add code to accept valid locked WOPCM register values

On Tue, 10 Apr 2018 02:42:19 +0200, Jackie Li wrote: In current code, we only compare the locked WOPCM register values with the calculated values. However, we can continue loading GuC/HuC firmware if the locked (or partially locked) values were valid for current

Re: [Intel-gfx] [PATCH 0/9] GPU-bound energy efficiency improvements for the intel_pstate driver.

Hi Francisco, [...] > Are you no longer interested in improving those aspects of the non- > HWP > governor?  Is it that you're planning to delete it and move back to a > generic cpufreq governor for non-HWP platforms in the near future? Yes that is the plan for Atom platforms, which are only

Re: [Intel-gfx] [PATCH v3 2/4] drm/i915: Always set HUC_LOADING_AGENT_GUC bit in WOPCM offset register

On Tue, 10 Apr 2018 02:42:18 +0200, Jackie Li wrote: The enable_guc modparam is used to enable/disable GuC/HuC FW uploading dynamcially during i915 module loading. If WOPCM offset register was typo locked without having HUC_LOADING_AGENT_GUC bit set to 1, the

Re: [Intel-gfx] [PATCH v3 1/4] drm/i915: Always do WOPCM partitioning based on real firmware sizes

On Tue, 10 Apr 2018 02:42:17 +0200, Jackie Li wrote: After enabled the WOPCM write-once registers locking status checking, reloading of the i915 module will fail with modparam enable_guc set to 3 (enable GuC and HuC firmware loading) if the module was originally loaded

Re: [Intel-gfx] [PATCH 0/9] GPU-bound energy efficiency improvements for the intel_pstate driver.

Hi Srinivas, Srinivas Pandruvada writes: > On Wed, 2018-04-11 at 09:26 -0700, Francisco Jerez wrote: >> >> "just like" here is possibly somewhat unfair to the schedutil >> governor, >> admittedly its progressive IOWAIT boosting behavior seems somewhat >>

Re: [Intel-gfx] [PATCH 0/9] GPU-bound energy efficiency improvements for the intel_pstate driver.

Peter Zijlstra writes: > On Thu, Apr 12, 2018 at 12:55:39PM -0700, Francisco Jerez wrote: >> Actually assuming that a single geometric feature of the power curve is >> known -- it being convex in the frequency range allowed by the policy >> (which is almost always the case,

Re: [Intel-gfx] [PATCH v3 3/4] drm/i915: Add code to accept valid locked WOPCM register values

On Mon, 2018-04-09 at 17:42 -0700, Jackie Li wrote: > In current code, we only compare the locked WOPCM register values > with the > calculated values. However, we can continue loading GuC/HuC firmware > if the > locked (or partially locked) values were valid for current GuC/HuC > firmware >

Re: [Intel-gfx] [PATCH v3 2/4] drm/i915: Always set HUC_LOADING_AGENT_GUC bit in WOPCM offset register

On Mon, 2018-04-09 at 17:42 -0700, Jackie Li wrote: > The enable_guc modparam is used to enable/disable GuC/HuC FW > uploading > dynamcially during i915 module loading. If WOPCM offset register was > locked > without having HUC_LOADING_AGENT_GUC bit set to 1, the module > reloading > with both GuC

Re: [Intel-gfx] [PATCH v3 1/4] drm/i915: Always do WOPCM partitioning based on real firmware sizes

On Mon, 2018-04-09 at 17:42 -0700, Jackie Li wrote: > After enabled the WOPCM write-once registers locking status checking, > reloading of the i915 module will fail with modparam enable_guc set > to 3 > (enable GuC and HuC firmware loading) if the module was originally > loaded > with enable_guc

Re: [Intel-gfx] [PATCH] drm/i915: content-type property for HDMI connector

On Sat, Apr 14, 2018 at 01:00:19AM +0300, StanLis wrote: > From: Stanislav Lisovskiy > > Added content_type property to > drm_connector_state in order to properly handle > external HDMI TV content-type setting. > > Signed-off-by: Stanislav Lisovskiy

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: content-type property for HDMI connector

== Series Details == Series: drm/i915: content-type property for HDMI connector URL : https://patchwork.freedesktop.org/series/41677/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4053_full -> Patchwork_8687_full = == Summary - SUCCESS == No regressions found.

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/22] drm/i915/icl: Introduce initial Icelake Workarounds

== Series Details == Series: series starting with [01/22] drm/i915/icl: Introduce initial Icelake Workarounds URL : https://patchwork.freedesktop.org/series/41687/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4053_full -> Patchwork_8688_full = == Summary - WARNING ==

Re: [Intel-gfx] [PATCH i-g-t] [RFC] CONTRIBUTING: commit rights docs

On 2018-04-13 06:00 AM, Daniel Vetter wrote: > This tries to align with the X.org communities's long-standing > tradition of trying to be an inclusive community and handing out > commit rights fairly freely. > > We also tend to not revoke commit rights for people no longer > regularly active in a

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: content-type property for HDMI connector

== Series Details == Series: drm/i915: content-type property for HDMI connector URL : https://patchwork.freedesktop.org/series/41677/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4053_full -> Patchwork_8687_full = == Summary - SUCCESS == No regressions found.

[Intel-gfx] ✓ Fi.CI.IGT: success for igt/prime_mmap: Test for userptr support first

== Series Details == Series: igt/prime_mmap: Test for userptr support first URL : https://patchwork.freedesktop.org/series/41638/ State : success == Summary == = CI Bug Log - changes from IGT_4426_full -> IGTPW_1251_full = == Summary - SUCCESS == No regressions found. External URL:

Re: [Intel-gfx] [PATCH 0/9] GPU-bound energy efficiency improvements for the intel_pstate driver.

On Thu, Apr 12, 2018 at 12:55:39PM -0700, Francisco Jerez wrote: > Actually assuming that a single geometric feature of the power curve is > known -- it being convex in the frequency range allowed by the policy > (which is almost always the case, not only for Intel CPUs), the optimal > frequency

Re: [Intel-gfx] [PATCH v2] drm/i915: Check whitelist registers across resets

Quoting Oscar Mateo (2018-04-13 18:04:16) > > > On 4/13/2018 9:54 AM, Chris Wilson wrote: > > Quoting Oscar Mateo (2018-04-13 17:46:42) > >> > >> On 4/12/2018 8:21 AM, Chris Wilson wrote: > >>> Add a selftest to ensure that we restore the whitelisted registers after > >>> rewrite the registers

Re: [Intel-gfx] [PATCH igt] igt/gem_exec_schedule: Exercise preemption timeout

Quoting Antonio Argenziano (2018-04-13 18:20:02) > > > On 13/04/18 08:59, Chris Wilson wrote: > > die. What we expect to happen is spin[0] is (more or less, there is still > > dmesg) silently killed by the preempt timeout. If that timeout doesn't > > The silent part is interesting, how do we

Re: [Intel-gfx] [PATCH 0/9] GPU-bound energy efficiency improvements for the intel_pstate driver.

Hi, On 11/04/18 09:26, Francisco Jerez wrote: > Francisco Jerez writes: > > > Hi Srinivas, > > > > Srinivas Pandruvada writes: > > > >> On Tue, 2018-04-10 at 15:28 -0700, Francisco Jerez wrote: > >>> Francisco Jerez

Re: [Intel-gfx] [PATCH igt] igt/gem_exec_schedule: Exercise preemption timeout

On 13/04/18 08:59, Chris Wilson wrote: Quoting Antonio Argenziano (2018-04-13 16:54:27) On 13/04/18 07:14, Chris Wilson wrote: Set up a unpreemptible spinner such that the only way we can inject a high priority request onto the GPU is by resetting the spinner. The test fails if we trigger

Re: [Intel-gfx] [RFC v4 03/25] drm/fb-helper: No need to cache rotation and sw_rotations

Hi Noralf, 1 comment inline. On 13-04-18 18:53, Noralf Trønnes wrote: Getting rotation info is cheap so we can do it on demand. This is done in preparation for the removal of struct drm_fb_helper_crtc. Cc: Hans de Goede Signed-off-by: Noralf Trønnes

Re: [Intel-gfx] [RFC v4 00/25] drm: Add generic fbdev emulation

Argh, it didn't go through this time either. I'll just have to strip off recipients and just send to the lists when the cool off period is over. Sorry about the noise, I'll have to investigate this further. Noralf. Den 13.04.2018 18.53, skrev Noralf Trønnes: This patchset explores the

Re: [Intel-gfx] [PATCH v2] drm/i915: Check whitelist registers across resets

On 4/13/2018 9:54 AM, Chris Wilson wrote: Quoting Oscar Mateo (2018-04-13 17:46:42) On 4/12/2018 8:21 AM, Chris Wilson wrote: Add a selftest to ensure that we restore the whitelisted registers after rewrite the registers everytime they might be scrubbed, e.g. module load, reset and resume.

[Intel-gfx] [RFC v4 20/25] drm/prime: Don't pin module on export for in-kernel clients

Avoid pinning the module when exporting a GEM object as a dmabuf. This makes it possible to unload drivers that has in-kernel clients using it. The client is removed on drm_dev_unregister() so no need to pin the driver. Signed-off-by: Noralf Trønnes ---

[Intel-gfx] [RFC v4 18/25] drm/client: Make the display modes available to clients

Give clients easy access to the display modes. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_client.c | 159 +-- include/drm/drm_client.h | 25 +++ 2 files changed, 148 insertions(+), 36 deletions(-) diff --git

[Intel-gfx] [RFC v4 17/25] drm/client: Bail out if there's a DRM master

If there's a DRM master, return -EBUSY. Block userspace from becoming master by taking the master lock while the client is setting the mode. Suggested-by: Daniel Vetter Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_auth.c | 33

[Intel-gfx] [RFC v4 16/25] drm: Make ioctls available for in-kernel clients

Make ioctl wrappers for functions that will be used by the in-kernel API. The following functions are touched: - drm_mode_create_dumb_ioctl() - drm_mode_destroy_dumb_ioctl() - drm_mode_addfb2() - drm_mode_rmfb() - drm_prime_handle_to_fd_ioctl() drm_mode_addfb2() also gets the ability to override

[Intel-gfx] [RFC v4 21/25] drm/fb-helper: Add drm_fb_helper_fb_open/release()

These helpers keep track of fbdev users and drm_driver.last_close will only restore fbdev when actually in use. Additionally the display is turned off when the last user is closing. fbcon is a user in this context. If struct fb_ops is defined in a library, fb_open() takes a ref on the library

[Intel-gfx] [RFC v4 15/25] drm/fb-helper: Move modeset config code to drm_client

Call the function drm_client_find_display(). No functional change apart from making width/height arguments optional. Some function name/signature changes and whitespace adjustments. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_client.c| 399

[Intel-gfx] [RFC v4 14/25] drm/fb-helper: Remove struct drm_fb_helper_connector

No need to maintain a list of registered connectors. Just use the connector iterator. TODO: Remove: - drm_fb_helper_add_one_connector() - drm_fb_helper_single_add_all_connectors() - drm_fb_helper_remove_one_connector() Signed-off-by: Noralf Trønnes ---

[Intel-gfx] [RFC v4 13/25] drm/fb-helper: Remove struct drm_fb_helper_crtc

The stage is now set for a clean removal of drm_fb_helper_crtc. struct drm_client_display is doing its job now. Also remove the drm_fb_helper_funcs->initial_config which has been superseded by drm_driver->initial_client_display. Signed-off-by: Noralf Trønnes ---

[Intel-gfx] [RFC v4 19/25] drm/client: Finish the in-kernel client API

The modesetting code is already present, this adds the rest of the API. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_client.c | 573 + drivers/gpu/drm/drm_debugfs.c | 7 + drivers/gpu/drm/drm_drv.c | 11 +

[Intel-gfx] [RFC v4 12/25] drm/i915: Add drm_driver->initial_client_display callback

As part of moving the modesetting code out of drm_fb_helper and into drm_client, the drm_fb_helper_funcs->initial_config callback needs to go. Replace it with a drm_driver->initial_client_display callback that can work for all in-kernel clients. TODO: - Add a patch that moves the function out of

[Intel-gfx] [RFC v4 08/25] drm/fb-helper: Use struct drm_client_display

Prepare to move the modeset committing code to drm_client. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_fb_helper.c | 161 include/drm/drm_fb_helper.h | 8 ++ 2 files changed, 89 insertions(+), 80 deletions(-) diff

[Intel-gfx] [RFC v4 10/25] drm/connector: Add drm_connector_has_preferred_mode/pick_cmdline_mode()

Move them over from drm_fb_helper since they are connector functions. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_connector.c| 94 ++ drivers/gpu/drm/drm_fb_helper.c| 75 ++

[Intel-gfx] [RFC v4 11/25] drm/connector: Add connector array functions

Add functions to deal with the registred connectors as an array: - drm_connector_get_all() - drm_connector_put_all() And to get the enabled status of those connectors: drm_connector_get_enabled_status() This is prep work to remove struct drm_fb_helper_connector. Signed-off-by: Noralf Trønnes

[Intel-gfx] [RFC v4 07/25] drm: Begin an API for in-kernel clients

This the beginning of an API for in-kernel clients. First out is a display representation that will be used by drm_fb_helper in order to move out its mode setting code. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_client.c |

[Intel-gfx] [RFC v4 05/25] drm/fb-helper: dpms_legacy(): Only set on connectors in use

For each enabled crtc the functions sets dpms on all registered connectors. Limit this to only doing it once and on the connectors actually in use. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_fb_helper.c | 11 +-- 1 file changed, 5 insertions(+), 6

[Intel-gfx] [RFC v4 00/25] drm: Add generic fbdev emulation

This patchset explores the possibility of having generic fbdev emulation in DRM for drivers that supports dumb buffers which they can export. An API is added to support in-kernel clients in general. In this version I was able to reuse the modesetting code from drm_fb_helper in the client API.

[Intel-gfx] [RFC v4 03/25] drm/fb-helper: No need to cache rotation and sw_rotations

Getting rotation info is cheap so we can do it on demand. This is done in preparation for the removal of struct drm_fb_helper_crtc. Cc: Hans de Goede Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_fb_helper.c | 131

[Intel-gfx] [RFC v4 04/25] drm/fb-helper: Remove drm_fb_helper_debug_enter/leave()

Atomic drivers can't use them so finish what was started in commit 9c79e0b1d096 ("drm/fb-helper: Give up on kgdb for atomic drivers"). This prepares the ground for creating modesets on demand. TODO: - Actually remove the functions, not just the contents. - Nuke

[Intel-gfx] [RFC v4 09/25] drm/fb-helper: Move modeset commit code to drm_client

This moves the committing part of the modesetting code to drm_client. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_client.c| 242 drivers/gpu/drm/drm_fb_helper.c | 216 +--

[Intel-gfx] [RFC v4 06/25] drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()

Prepare for moving drm_fb_helper modesetting code to drm_client. drm_client will be linked to drm.ko, so move __drm_atomic_helper_disable_plane() and __drm_atomic_helper_set_config() out of drm_kms_helper.ko. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_atomic.c

[Intel-gfx] [RFC v4 01/25] drm: provide management functions for drm_file

From: David Herrmann Rather than doing drm_file allocation/destruction right in the fops, lets provide separate helpers. This decouples drm_file management from the still-mandatory drm-fops. It prepares for use of drm_file without the fops, both by possible separate fops

[Intel-gfx] [RFC v4 02/25] drm/file: Don't set master on in-kernel clients

It only makes sense for userspace clients. Signed-off-by: Noralf Trønnes Reviewed-by: Daniel Vetter --- drivers/gpu/drm/drm_file.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/drm_file.c

Re: [Intel-gfx] [PATCH v2] drm/i915: Check whitelist registers across resets

Quoting Oscar Mateo (2018-04-13 17:46:42) > > > On 4/12/2018 8:21 AM, Chris Wilson wrote: > > Add a selftest to ensure that we restore the whitelisted registers after > > rewrite the registers everytime they might be scrubbed, e.g. module > > load, reset and resume. For the other volatile

Re: [Intel-gfx] [PATCH v2] drm/i915: Check whitelist registers across resets

On 4/12/2018 8:21 AM, Chris Wilson wrote: Add a selftest to ensure that we restore the whitelisted registers after rewrite the registers everytime they might be scrubbed, e.g. module load, reset and resume. For the other volatile workaround registers, we export their presence via debugfs and

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/22] drm/i915/icl: Introduce initial Icelake Workarounds

== Series Details == Series: series starting with [01/22] drm/i915/icl: Introduce initial Icelake Workarounds URL : https://patchwork.freedesktop.org/series/41687/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4053 -> Patchwork_8688 = == Summary - SUCCESS == No

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/22] drm/i915/icl: Introduce initial Icelake Workarounds

== Series Details == Series: series starting with [01/22] drm/i915/icl: Introduce initial Icelake Workarounds URL : https://patchwork.freedesktop.org/series/41687/ State : warning == Summary == $ dim checkpatch origin/drm-tip bc09764ddda4 drm/i915/icl: Introduce initial Icelake Workarounds

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915: Add NV12 as supported format for primary plane

On Fri, Apr 13, 2018 at 5:17 AM Vidya Srinivas wrote: > From: Chandra Konduru > This patch adds NV12 to list of supported formats for > primary plane Reviewed-by: Kristian H. Kristensen > v2: Rebased (Chandra

Re: [Intel-gfx] [PATCH v2 3/6] drm/i915: Add NV12 as supported format for sprite plane

On Fri, Apr 13, 2018 at 5:18 AM Vidya Srinivas wrote: > From: Chandra Konduru > This patch adds NV12 to list of supported formats for sprite plane. > v2: Rebased (me) > v3: Review comments by Ville addressed > - Removed

[Intel-gfx] [PATCH 09/22] drm/i915/icl: Wa_1405779004

Disable MSC clock gating to prevent data corruption. BSpec: 19257 v2: Rebased on top of the WA refactoring Cc: Mika Kuoppala Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/i915_reg.h | 1 +

[Intel-gfx] [PATCH 13/22] drm/i915/icl: WaForwardProgressSoftReset

Avoids a hang during soft reset. v2: Rebased on top of the WA refactoring Cc: Mika Kuoppala Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/i915_reg.h | 5 + drivers/gpu/drm/i915/intel_workarounds.c | 8 2 files

[Intel-gfx] [PATCH 19/22] drm/i915/icl: WaAllowUMDToModifyHalfSliceChicken2

Required to dinamically set 'Small PL Lossless Fix Enable' Do Linux UMDs make use of this? This change has been security reviewed and the whitelisting approved. Virtualization of other OSes could certainly use it. v2: For whatever reason, this ended up in KBL (??!!) v3: Rebased on top of the WA

[Intel-gfx] [PATCH 05/22] drm/i915/icl: WaModifyGamTlbPartitioning

Adjust default GAM TLB partitioning for performance reasons. v2: Only touch the bits that we really need v3: Rebased on top of the WA refactoring Cc: Mika Kuoppala Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/i915_reg.h | 5

[Intel-gfx] [PATCH 12/22] drm/i915/icl: Wa_1406838659

Disable CGPSF unit clock gating to prevent an issue. v2: Rebased on top of the WA refactoring Cc: Mika Kuoppala Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/i915_reg.h | 13 -

[Intel-gfx] [PATCH 11/22] drm/i915/icl: Wa_1604302699

Disable I2M Write for performance reasons. v2: Rebased on top of the WA refactoring Cc: Mika Kuoppala Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/i915_reg.h | 4 +++- drivers/gpu/drm/i915/intel_workarounds.c | 5 + 2

[Intel-gfx] [PATCH 18/22] drm/i915/icl: WaSendPushConstantsFromMMIO

Allows UMDs to set 'Disable Gather at Set Shader Common Slice'. Do Linux UMDs make use of this? This change has been security reviewed and the whitelisting approved. Virtualization of other OSes could certainly use it... v2: Rebased v3: Rebased on top of the WA refactoring Cc: Mika Kuoppala

[Intel-gfx] [PATCH 20/22] drm/i915/icl: WaAllowUMDToModifyHalfSliceChicken7

Required to dinamically set 'Trilinear Filter Quality Mode' Do Linux UMDs make use of this? This change has been security reviewed and the whitelisting approved. Virtualization of other OSes could certainly use it. v2: For whatever reason, this ended up in KBL (??!!) v3: Rebased on top of the WA

[Intel-gfx] [PATCH 01/22] drm/i915/icl: Introduce initial Icelake Workarounds

Inherit workarounds from previous platforms that are still valid for Icelake. v2: GEN7_ROW_CHICKEN2 is masked v3: - Since it has been fixed already in upstream, removed the TODO comment about WA_SET_BIT for WaInPlaceDecompressionHang. - Squashed with this patch: drm/i915/icl: add

[Intel-gfx] [PATCH 17/22] drm/i915/icl: WaEnableFloatBlendOptimization

Enables blend optimization for floating point RTs v2: Rebased on top of the WA refactoring Cc: Mika Kuoppala Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/i915_reg.h | 3 +++ drivers/gpu/drm/i915/intel_workarounds.c | 3 +++

[Intel-gfx] [PATCH 21/22] drm/i915/icl: WaAllowUmdWriteTRTTRootTable

Required for TR-TT (Tiled Resource Translation Table) support. Do Linux UMDs make use of this? This change has been security reviewed and the whitelisting approved. Virtualization of other OSes could certainly use it. v2: For whatever reason, this ended up in KBL (??!!) v3: Rebased on top of the

[Intel-gfx] [PATCH 06/22] drm/i915/icl: WaDisableCleanEvicts

Avoids an undefined LLC behavior. BSpec: 9613 v2: Renamed to Wa_1405733216 v3: Spaces around '<<' and fix surrounding code v4: Rebased on top of the WA refactoring Cc: Mika Kuoppala Signed-off-by: Oscar Mateo ---

[Intel-gfx] [PATCH 10/22] drm/i915/icl: Wa_1406680159 and Wa_2201832410

Disable GWL clock gating to prevent two different issues that might cause hangs. Please notice that one of the issues is pre-production only. v2: Rebased on top of the WA refactoring Cc: Mika Kuoppala Signed-off-by: Oscar Mateo ---

[Intel-gfx] [PATCH 02/22] drm/i915/icl: Enable Sampler DFR

Sampler Dynamic Frequency Rebalancing (DFR) aims to reduce Sampler power by dynamically changing its clock frequency in low-throughput conditions. This patches enables it by default on Gen11. v2: Wrong operation to clear the bit (Praveen) v3: Rebased on top of the WA refactoring Cc: Sagar Arun

[Intel-gfx] [PATCH 04/22] drm/i915/icl: WaL3BankAddressHashing

Revert to an L3 non-hash model, for performance reasons. v2: - Place the WA name above the actual change - Improve the register naming v3: - Rebased - Renamed to Wa_1604223664 v4: Rebased on top of the WA refactoring Cc: Mika Kuoppala Signed-off-by: Oscar

[Intel-gfx] [PATCH 07/22] drm/i915/icl: WaCL2SFHalfMaxAlloc

This workarounds an issue with insufficient storage for the CL2 and SF units. v2: Renamed to Wa_1405766107 v3: Wrapped the commit message v4: Rebased on top of the WA refactoring Cc: Mika Kuoppala Signed-off-by: Oscar Mateo ---

[Intel-gfx] [PATCH 03/22] drm/i915/icl: WaGAPZPriorityScheme

The default GAPZ arbitrer priority value at power-on has been found to be incorrect. v2: Now renamed to Wa_1405543622 v3: Rebased on top of the WA refactoring Cc: Mika Kuoppala Signed-off-by: Oscar Mateo ---

[Intel-gfx] [PATCH 22/22] drm/i915/icl: WaAllowUMDToModifySamplerMode

Required for Bindless samplers. Do Linux UMDs make use of this? This change has been security reviewed and the whitelisting approved. Virtualization of other OSes could certainly use it. v2: Rebased on top of the WA refactoring Cc: Mika Kuoppala Signed-off-by:

[Intel-gfx] [PATCH 16/22] drm/i915/icl: Wa_2006665173

Disable blend embellishment in RCC. v2: Rebased on top of the WA refactoring Cc: Mika Kuoppala Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/i915_reg.h | 18 +++--- drivers/gpu/drm/i915/intel_workarounds.c | 5

[Intel-gfx] [PATCH 08/22] drm/i915/icl: WaDisCtxReload

Revert to the legacy implementation to avoid a system hang. v2: Correct the address for GAMW_ECO_DEV_RW_IA_REG v3: Renamed to Wa_220166154 v4: Rebased on top of the WA refactoring Cc: Mika Kuoppala Signed-off-by: Oscar Mateo ---

[Intel-gfx] [PATCH 14/22] drm/i915/icl: WaDisableImprovedTdlClkGating

Revert to the legacy implementation. v2: GEN7_ROW_CHICKEN2 is masked v3: - Rebased - Renamed to Wa_2006611047 - A0 and B0 only v4: - Add spaces around '<<' (and fix the surrounding code as well) - Mark the WA as pre-prod v5: Rebased on top of the WA refactoring Cc: Mika Kuoppala

[Intel-gfx] [PATCH 15/22] drm/i915/icl: WaEnableStateCacheRedirectToCS

Redirects the state cache to the CS Command buffer section for performance reasons. v2: Rebased v3: Rebased on top of the WA refactoring Cc: Mika Kuoppala Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/i915_reg.h | 1 +

Re: [Intel-gfx] [PATCH igt] igt/gem_exec_schedule: Exercise preemption timeout

Quoting Antonio Argenziano (2018-04-13 16:54:27) > > > On 13/04/18 07:14, Chris Wilson wrote: > > Set up a unpreemptible spinner such that the only way we can inject a > > high priority request onto the GPU is by resetting the spinner. The test > > fails if we trigger hangcheck rather than the

Re: [Intel-gfx] [PATCH igt] igt/gem_exec_schedule: Exercise preemption timeout

On 13/04/18 07:14, Chris Wilson wrote: Set up a unpreemptible spinner such that the only way we can inject a high priority request onto the GPU is by resetting the spinner. The test fails if we trigger hangcheck rather than the fast timeout mechanism. Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH v2 3/4] drm/i915: Check hdcp key loadability

On Wed, Apr 11, 2018 at 01:57:15PM +0530, Ramalingam C wrote: > > > On Monday 09 April 2018 01:58 PM, Daniel Vetter wrote: > > On Fri, Apr 06, 2018 at 07:02:02PM +0300, Ville Syrjälä wrote: > > > On Mon, Apr 02, 2018 at 02:35:42PM +0530, Ramalingam C wrote: > > > > > > > > On Thursday 29 March

[Intel-gfx] ✗ Fi.CI.BAT: failure for igt/gem_exec_schedule: Exercise preemption timeout

== Series Details == Series: igt/gem_exec_schedule: Exercise preemption timeout URL : https://patchwork.freedesktop.org/series/41679/ State : failure == Summary == Applying: igt/gem_exec_schedule: Exercise preemption timeout Using index info to reconstruct a base tree... M

[Intel-gfx] [PATCH igt] igt/gem_exec_schedule: Exercise preemption timeout

Set up a unpreemptible spinner such that the only way we can inject a high priority request onto the GPU is by resetting the spinner. The test fails if we trigger hangcheck rather than the fast timeout mechanism. Signed-off-by: Chris Wilson --- lib/i915/gem_context.c

[Intel-gfx] ✗ Fi.CI.BAT: failure for igt: Add gem_ctx_freq to exercise requesting freq on a ctx (rev3)

== Series Details == Series: igt: Add gem_ctx_freq to exercise requesting freq on a ctx (rev3) URL : https://patchwork.freedesktop.org/series/39571/ State : failure == Summary == IGT patchset build failed on latest successful build 80e4910581c7310258375a003a5de9a57ed24546 lib: Adjust

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: content-type property for HDMI connector

== Series Details == Series: drm/i915: content-type property for HDMI connector URL : https://patchwork.freedesktop.org/series/41677/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4053 -> Patchwork_8687 = == Summary - SUCCESS == No regressions found. External URL:

[Intel-gfx] ✓ Fi.CI.IGT: success for Enable NV12 support

== Series Details == Series: Enable NV12 support URL : https://patchwork.freedesktop.org/series/41674/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4052_full -> Patchwork_8686_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8686_full need to

[Intel-gfx] [PATCH] drm/i915: content-type property for HDMI connector

From: Stanislav Lisovskiy Added content_type property to drm_connector_state in order to properly handle external HDMI TV content-type setting. Signed-off-by: Stanislav Lisovskiy --- drivers/gpu/drm/drm_atomic.c| 4

Re: [Intel-gfx] [RFC v2 2/2] drm/i915/gmbus: Enable burst read

On Thu, 12 Apr 2018, Ramalingam C wrote: > Support for Burst read in HW is added for HDCP2.2 compliance > requirement. > > This patch enables the burst read for all the gmbus read of more than > 511Bytes, on capable platforms. > > v2: > Extra line is removed. > >

[Intel-gfx] ✓ Fi.CI.BAT: success for Enable NV12 support

== Series Details == Series: Enable NV12 support URL : https://patchwork.freedesktop.org/series/41674/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4052 -> Patchwork_8686 = == Summary - SUCCESS == No regressions found. External URL:

Re: [Intel-gfx] [RFC 1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op

On Thu, 12 Apr 2018, Ramalingam C wrote: > From BXT onwards Bspec says HW supports Max Bytes per single RD/WR op is > 511Bytes instead of previous 256Bytes used in SW. "BXT onwards" and "SKL onwards" are always slightly confusing, because it's not always clear if one

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable NV12 support

== Series Details == Series: Enable NV12 support URL : https://patchwork.freedesktop.org/series/41674/ State : warning == Summary == $ dim checkpatch origin/drm-tip d24b3eca473a drm/i915: Enable display workaround 827 for all planes, v2. -:58: CHECK:PARENTHESIS_ALIGNMENT: Alignment should

[Intel-gfx] Updated drm-intel-testing

Hi all, The following changes tagged drm-intel-testing-2018-04-13: drm-intel-next-2018-04-13: First drm/i915 feature batch heading for v4.18: - drm-next backmerge to fix build (Rodrigo) - GPU documentation improvements (Kevin) - GuC and HuC refactoring, host/GuC communication, logging, fixes,

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

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 after each invalid request v4: Check the

Re: [Intel-gfx] [PATCH v4] drm/i915/guc: Remove GUC_CTL_DEVICE_INFO parameter

Quoting Piotr Piórkowski (2018-04-13 09:52:45) > It looks that GuC does not actively use GUC_CTL_DEVICE_INFO parameter > where we are passing GT type and Core family values. > Let's stop/remove setup of this parameter and remove related > definitions. > > v2: (this time without squashed HAX) >

[Intel-gfx] [PATCH v2 3/6] drm/i915: Add NV12 as supported format for sprite plane

From: Chandra Konduru This patch adds NV12 to list of supported formats for sprite plane. v2: Rebased (me) v3: Review comments by Ville addressed - Removed skl_plane_formats_with_nv12 and added NV12 case in existing skl_plane_formats - Added the 10bpc RGB formats

[Intel-gfx] [PATCH v2 5/6] drm/i915: Enable Display WA 0528

Possible hang with NV12 plane surface formats. WA: When the plane source pixel format is NV12, the CHICKEN_PIPESL_* register bit 22 must be set to 1 and the render decompression must not be enabled on any of the planes in that pipe. v2: removed unnecessary POSTING_READ Credits-to: Maarten

[Intel-gfx] [PATCH v2 0/6] Enable NV12 support

Enabling NV12 support: - Framebuffer creation - Primary and Sprite plane support Patch series depend on Enable display workaround 827 patch mentioned below submitted by Maarten Chandra Konduru (3): drm/i915: Add NV12 as supported format for primary plane drm/i915: Add NV12 as supported format

[Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

We skip src trunction/adjustments for NV12 case and handle the sizes directly. Without this, pipe fifo underruns are seen on APL/KBL. v2: For NV12, making the src coordinates multiplier of 4 Credits-to: Maarten Lankhorst Signed-off-by: Vidya Srinivas

[Intel-gfx] [PATCH v2 4/6] drm/i915: Add NV12 support to intel_framebuffer_init

From: Chandra Konduru This patch adds NV12 as supported format to intel_framebuffer_init and performs various checks. v2: -Fix an issue in checks added (Chandra Konduru) v3: rebased (me) v4: Review comments by Ville addressed Added platform check for NV12 in

[Intel-gfx] [PATCH v2 2/6] drm/i915: Add NV12 as supported format for primary plane

From: Chandra Konduru This patch adds NV12 to list of supported formats for primary plane v2: Rebased (Chandra Konduru) v3: Rebased (me) v4: Review comments by Ville addressed Removed the skl_primary_formats_with_nv12 and added NV12 case in existing

[Intel-gfx] [PATCH v2 1/6] drm/i915: Enable display workaround 827 for all planes, v2.

From: Maarten Lankhorst The workaround was applied only to the primary plane, but is required on all planes. Iterate over all planes in the crtc atomic check to see if the workaround is enabled, and only perform the actual toggling in the pre/post plane update

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc: Removed unused GuC parameters. (rev4)

== Series Details == Series: drm/i915/guc: Removed unused GuC parameters. (rev4) URL : https://patchwork.freedesktop.org/series/39154/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4052_full -> Patchwork_8685_full = == Summary - WARNING == Minor unknown changes coming

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Removed unused GuC parameters. (rev4)

== Series Details == Series: drm/i915/guc: Removed unused GuC parameters. (rev4) URL : https://patchwork.freedesktop.org/series/39154/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4052 -> Patchwork_8685 = == Summary - SUCCESS == No regressions found. External URL:

Re: [Intel-gfx] [RFC v2 2/2] drm/i915/gmbus: Enable burst read

On Thursday 12 April 2018 09:31 PM, Ramalingam C wrote: Support for Burst read in HW is added for HDCP2.2 compliance requirement. This patch enables the burst read for all the gmbus read of more than 511Bytes, on capable platforms. v2: Extra line is removed. Signed-off-by: Ramalingam C

[Intel-gfx] [PATCH i-g-t] [RFC] CONTRIBUTING: commit rights docs

This tries to align with the X.org communities's long-standing tradition of trying to be an inclusive community and handing out commit rights fairly freely. We also tend to not revoke commit rights for people no longer regularly active in a given project, as long as they're still part of the

  1   2   >