[Intel-gfx] unreadable external HDMI display in recent kernels, work around

I hope this email finds you well. I apologize as I'm not a graphics kernel developer. I hope we don't discover that this email is a complete newbie email. Problem: External HDMI display is unreadable. You can make out edges of windows and other stuff. Other than that it looks like a garbled mess

Re: [Intel-gfx] [PATCH 5/7] drm: Don't compute obj counts expensively in get_resources

On Fri, Dec 09, 2016 at 09:47:56PM +, Chris Wilson wrote: > On Fri, Dec 09, 2016 at 03:19:42PM +0100, Daniel Vetter wrote: > > Looping when we keep track of this is silly. Only thing we have to > > be careful is with sampling the connector count. To avoid inconsisten > > results due to gcc

Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

>-Original Message- >From: Michal Wajdeczko [mailto:michal.wajdec...@linux.intel.com] >Sent: Friday, December 9, 2016 4:18 AM >To: Srivatsa, Anusha >Cc: intel-gfx@lists.freedesktop.org; Alex Dai ; Peter Antoine >

[Intel-gfx] [PATCH v2 1/5] drm/i915: Move all the DP compliance data to a separate struct

This patch does not change anything functionally, just cleans up the DP compliance related variables and stores them all together in a separate struct intel_dp_compliance. There is another struct intel_dp_compliance_data to store all the test data. This makes it easy to reset the compliance

[Intel-gfx] [PATCH v3 5/5] drm/i915: Add support for DP Video pattern compliance tests

The intel_dp_autotest_video_pattern() function gets invoked through the compliance test handler on a HPD short pulse if the test type is set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers reads to read the requested test pattern, video pattern resolution, frame rate and bits per color

[Intel-gfx] [PATCH v3 1/5] drm/i915: Move all the DP compliance data to a separate struct

This patch does not change anything functionally, just cleans up the DP compliance related variables and stores them all together in a separate struct intel_dp_compliance. There is another struct intel_dp_compliance_data to store all the test data. This makes it easy to reset the compliance

[Intel-gfx] [PATCH v3 0/5] Add Automation Support for DP Compliance Testing (Rev 3)

This addresses all the review comments from the earlier patch series: https://patchwork.freedesktop.org/series/16591/ DP 1.2 compliance testing can be acheived using DPR-120's CTS suite. This compliance unit sends a short pulse to initiate link training and video pattern generation compliance

[Intel-gfx] [PATCH v3 4/5] drm: Add definitions for DP compliance Video pattern tests

v2: * Add all the other DP Complianec TEST register defs (Jani Nikula) Cc: dri-de...@lists.freedesktop.org Cc: Jani Nikula Cc: Daniel Vetter Cc: Ville Syrjala Signed-off-by: Manasi Navare

[Intel-gfx] [PATCH v3 2/5] drm/i915: Add support for DP link training compliance

This patch adds support to handle automated DP compliance link training test requests. This patch has been tested with Unigraf DPR-120 DP Compliance device for testing Link Training Compliance. After we get a short pulse Compliance test request, test request values are read and hotplug uevent is

[Intel-gfx] [PATCH v3 3/5] drm/i915: Fixes to support DP Compliance EDID tests

This patch addresses a few issues from the original patch for DP Compliance EDID test support submitted by Todd Previte Video Mode requested in the EDID test handler for the EDID Read test (CTS 4.2.2.3) should be set to PREFERRED as per the CTS spec. v2: * Added read

Re: [Intel-gfx] [PATCH] drm/i915/psr: report psr2 hw enabled from psr2_ctl

Reviewed-by: Rodrigo Vivi On Fri, Dec 09, 2016 at 11:42:09PM +0530, vathsala nagaraju wrote: > For PSR2 , as per spec, PSR2_CTL bit 31 to be set. > for psr1, bit 31 in SRD_CTL to be set. Reporting > "HW Enabled & Active bit" status for psr2 from SRD_CTL > gives wrong

Re: [Intel-gfx] [PATCH] drm/i915/psr: report psr2 hw enabled from psr2_ctl

merged to dinq, thanks for the patch. On Fri, Dec 9, 2016 at 4:39 PM Rodrigo Vivi wrote: > > > Reviewed-by: Rodrigo Vivi > > On Fri, Dec 09, 2016 at 11:42:09PM +0530, vathsala nagaraju wrote: > > For PSR2 , as per spec, PSR2_CTL bit 31 to be set.

Re: [Intel-gfx] [PATCH v3 2/5] drm/i915: Add support for DP link training compliance

Jani, I have addressed few comments you had on the previous set of patches about validating the test lane count so I am checking it against min and max lane count values. Also made the debug prints less verbose. Could you please review this patch? Regards Manasi On Fri, Dec 09, 2016 at

Re: [Intel-gfx] [PATCH v3 3/5] drm/i915: Fixes to support DP Compliance EDID tests

Jani, This patch has just a few fixes to make the EDID tests follow the DP CTS spec. where for the valid EDID it should set the EDID data to PREFERRED Mode as opposed to STANDARD. Also it sets the data to EDID if it is EDID test. Fairly simple and is verified to be passing compliance with

[Intel-gfx] ✓ Fi.CI.BAT: success for sphinxification for dma-buf docs (rev2)

== Series Details == Series: sphinxification for dma-buf docs (rev2) URL : https://patchwork.freedesktop.org/series/16629/ State : success == Summary == Series 16629v2 sphinxification for dma-buf docs https://patchwork.freedesktop.org/api/1.0/series/16629/revisions/2/mbox/ fi-bdw-5557u

Re: [Intel-gfx] [PATCH v3 4/5] drm: Add definitions for DP compliance Video pattern tests

Jani, I have added the defs for all compliance video pattern test registers as you had commented on previous version of this patch. It also fixes the indentation. Could you please review this patch? Regards Manasi On Fri, Dec 09, 2016 at 04:32:59PM -0800, Manasi Navare wrote: > v2: > * Add

Re: [Intel-gfx] [PATCH v3 5/5] drm/i915: Add support for DP Video pattern compliance tests

Jani, I have addressed all your review comments and using the proper # defines from the header file for register and masks definitions. Could you please review this patch? Regards Manasi On Fri, Dec 09, 2016 at 04:33:00PM -0800, Manasi Navare wrote: > The intel_dp_autotest_video_pattern()

[Intel-gfx] [PATCH v2 3/5] drm/i915: Fixes to support DP Compliance EDID tests

This patch addresses a few issues from the original patch for DP Compliance EDID test support submitted by Todd Previte Video Mode requested in the EDID test handler for the EDID Read test (CTS 4.2.2.3) should be set to PREFERRED as per the CTS spec. v2: * Added read

[Intel-gfx] ✗ Fi.CI.BAT: warning for Add Automation Support for DP Compliance Testing (Rev 3)

== Series Details == Series: Add Automation Support for DP Compliance Testing (Rev 3) URL : https://patchwork.freedesktop.org/series/16643/ State : warning == Summary == Series 16643v1 Add Automation Support for DP Compliance Testing (Rev 3)

Re: [Intel-gfx] [PATCH igt] intel-ci: Do module loads first + last

> On Wed, Dec 07, 2016 at 09:41:42PM +0200, Jani Nikula wrote: > > I see your point, and maybe I worry too much, but running stuff with a > > reloaded module is never the normal use case. This makes all the test > > run with a reloaded module. Currently, the reload tests are in positions 6-8 due

Re: [Intel-gfx] [PATCH 7/8] drm/i915/huc: Support HuC authentication

On Thu, Dec 08, 2016 at 03:02:18PM -0800, anushasr wrote: > From: Peter Antoine > > The HuC authentication is done by host2guc call. The HuC RSA keys > are sent to GuC for authentication. > > v2: rebased on top of drm-intel-nightly. > changed name format and upped

[Intel-gfx] [PATCH v2] drm/i915: Respect num_pipes when install or reset dispaly IRQ

From: Elaine Wang Some platforms don't have display. To avoid accessing the non-existent registers, check whether num_pipes isn't zero before invoking dispaly IRQ install or reset function. Cc: Joonas Lahtinen Signed-off-by: Elaine Wang

Re: [Intel-gfx] [PATCH 2/6] drm/atomic: Unconditionally call prepare_fb.

On Fri, Dec 09, 2016 at 12:42:19AM +0200, Laurent Pinchart wrote: > Hi Daniel, > > On Thursday 08 Dec 2016 16:41:04 Daniel Vetter wrote: > > On Thu, Dec 08, 2016 at 02:45:25PM +0100, Maarten Lankhorst wrote: > > > Atomic drivers may set properties like rotation on the same fb, which > > > may

Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

On Thu, Dec 08, 2016 at 03:02:12PM -0800, anushasr wrote: > From: Peter Antoine > > Rename some of the GuC fw loading code to make them more general. We > will utilise them for HuC loading as well. > s/intel_guc_fw/intel_uc_fw/g > s/GUC_FIRMWARE/UC_FIRMWARE/g >

Re: [Intel-gfx] [PATCH] drm: Add fake controlD* symlinks for backwards compat

Hi Greg On Fri, Dec 9, 2016 at 11:53 AM, Greg Kroah-Hartman wrote: > On Fri, Dec 09, 2016 at 11:42:01AM +0100, Daniel Vetter wrote: >> We thought that no userspace is using them, but oops libdrm is using >> them to figure out whether a driver supports modesetting.

Re: [Intel-gfx] [PATCH 05/16] drm/i915: Add unit tests for the breadcrumb rbtree, wakeups

On 08/12/2016 21:04, Chris Wilson wrote: On Thu, Dec 08, 2016 at 05:38:34PM +, Tvrtko Ursulin wrote: On 07/12/2016 13:58, Chris Wilson wrote: Third retroactive test, make sure that the seqno waiters are woken. Signed-off-by: Chris Wilson ---

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Test all fw tables during mock selftests

On 09/12/2016 10:18, Chris Wilson wrote: On Fri, Dec 09, 2016 at 09:41:30AM +, Tvrtko Ursulin wrote: On 08/12/2016 22:29, Chris Wilson wrote: On Thu, Dec 08, 2016 at 04:52:24PM +, Tvrtko Ursulin wrote: Idea for another late test: for (offset = 0; offset < 0x4; offset++) {

Re: [Intel-gfx] [PATCH] drm: Add fake controlD* symlinks for backwards compat

On Fri, Dec 09, 2016 at 11:42:01AM +0100, Daniel Vetter wrote: > We thought that no userspace is using them, but oops libdrm is using > them to figure out whether a driver supports modesetting. Check out > drmCheckModesettingSupported but maybe don't because it's horrible and > totally runs

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Respect num_pipes when install or reset dispaly IRQ

== Series Details == Series: drm/i915: Respect num_pipes when install or reset dispaly IRQ URL : https://patchwork.freedesktop.org/series/16599/ State : warning == Summary == Series 16599v1 drm/i915: Respect num_pipes when install or reset dispaly IRQ

Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_plane_lowres: Plane visibility after atomic modesets

Hi, Thanks for review comments! > -Original Message- > From: Daniel Stone [mailto:dan...@fooishbar.org] > Sent: Wednesday, December 7, 2016 5:02 PM > To: Kahola, Mika > Cc: intel-gfx > Subject: Re: [PATCH i-g-t v2]

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Test all fw tables during mock selftests

On Fri, Dec 09, 2016 at 09:41:30AM +, Tvrtko Ursulin wrote: > > On 08/12/2016 22:29, Chris Wilson wrote: > >On Thu, Dec 08, 2016 at 04:52:24PM +, Tvrtko Ursulin wrote: > >>Idea for another late test: > >> > >>for (offset = 0; offset < 0x4; offset++) { > >>fw_domain =

[Intel-gfx] [PATCH] drm: Add fake controlD* symlinks for backwards compat

We thought that no userspace is using them, but oops libdrm is using them to figure out whether a driver supports modesetting. Check out drmCheckModesettingSupported but maybe don't because it's horrible and totally runs counter to where we want to go with libdrm device handling. The function

Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

On Thu, Dec 08, 2016 at 03:02:14PM -0800, anushasr wrote: > From: Anusha Srivatsa > > The HuC loading process is similar to GuC. The intel_uc_fw_fetch() > is used for both cases. > > HuC loading needs to be before GuC loading. The WOPCM setting must > be done early

Re: [Intel-gfx] [PATCH] drm: Add fake controlD* symlinks for backwards compat

Hey On Fri, Dec 9, 2016 at 11:42 AM, Daniel Vetter wrote: > We thought that no userspace is using them, but oops libdrm is using > them to figure out whether a driver supports modesetting. Check out > drmCheckModesettingSupported but maybe don't because it's horrible and

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Test all fw tables during mock selftests

On Fri, Dec 09, 2016 at 10:35:49AM +, Tvrtko Ursulin wrote: > On 09/12/2016 10:18, Chris Wilson wrote: > >Hmm. Could we use the mmio debug. Something like > > > > valid_reg = bitmap_create(0x4) > > FORCEWAKE_ALL > > for_each_offset() > > read reg > > if

Re: [Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC

On Thu, Dec 08, 2016 at 03:02:13PM -0800, anushasr wrote: > From: Peter Antoine > > HuC firmware css header has almost exactly same definition as GuC > firmware except for the sw_version. Also, add a new member fw_type > into intel_uc_fw to indicate what kind of fw it

Re: [Intel-gfx] [PATCH] drm: Add fake controlD* symlinks for backwards compat

On Fri, Dec 09, 2016 at 11:42:01AM +0100, Daniel Vetter wrote: > We thought that no userspace is using them, but oops libdrm is using > them to figure out whether a driver supports modesetting. Check out > drmCheckModesettingSupported but maybe don't because it's horrible and > totally runs

Re: [Intel-gfx] [PATCH 08/16] drm/i915: Unify active context tracking between legacy/execlists/guc

On 07/12/2016 13:58, Chris Wilson wrote: The requests conversion introduced a nasty bug where we could generate a new request in the middle of constructing a request. The new request would be executed (and waited upon) before the current one, creating a minor havoc in the seqno accounting.

Re: [Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC

On Thu, Dec 08, 2016 at 03:02:13PM -0800, anushasr wrote: > From: Peter Antoine > > HuC firmware css header has almost exactly same definition as GuC > firmware except for the sw_version. Also, add a new member fw_type > into intel_uc_fw to indicate what kind of fw it

Re: [Intel-gfx] [PATCH 08/16] drm/i915: Unify active context tracking between legacy/execlists/guc

On Fri, Dec 09, 2016 at 11:48:15AM +, Tvrtko Ursulin wrote: > > On 07/12/2016 13:58, Chris Wilson wrote: > >The requests conversion introduced a nasty bug where we could generate a > >new request in the middle of constructing a request. The new request > >would be executed (and waited upon)

Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

On Thu, Dec 08, 2016 at 03:02:14PM -0800, anushasr wrote: > From: Anusha Srivatsa > > The HuC loading process is similar to GuC. The intel_uc_fw_fetch() > is used for both cases. > > HuC loading needs to be before GuC loading. The WOPCM setting must > be done early

Re: [Intel-gfx] [PATCH 7/8] drm/i915/huc: Support HuC authentication

On Thu, Dec 08, 2016 at 03:02:18PM -0800, anushasr wrote: > From: Peter Antoine > > The HuC authentication is done by host2guc call. The HuC RSA keys > are sent to GuC for authentication. > > v2: rebased on top of drm-intel-nightly. > changed name format and upped

[Intel-gfx] [PATCH 8/9] drm: kselftest for drm_mm and top-down alignment

Check that if we request top-down allocation with a particular alignment from drm_mm_insert_node() that the start of the node matches our request. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm_selftests.h | 1 + drivers/gpu/drm/test-drm_mm.c | 92

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Add fake controlD* symlinks for backwards compat

== Series Details == Series: drm: Add fake controlD* symlinks for backwards compat URL : https://patchwork.freedesktop.org/series/16605/ State : success == Summary == Series 16605v1 drm: Add fake controlD* symlinks for backwards compat

Re: [Intel-gfx] [PATCH igt] intel-ci: Do module loads first + last

On Fri, Dec 09, 2016 at 12:04:58PM +0200, Petri Latvala wrote: > We should move all drv_module_reload@* tests to the bottom > really. That would make the other tests run in a usual configuration, > and as a nice side-effect, with the admin-specified global module > parameters (kernel cmdline,

Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

On Thu, Dec 08, 2016 at 03:02:12PM -0800, anushasr wrote: > From: Peter Antoine > > Rename some of the GuC fw loading code to make them more general. We > will utilise them for HuC loading as well. > s/intel_guc_fw/intel_uc_fw/g > s/GUC_FIRMWARE/UC_FIRMWARE/g >

Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

On Fri, Dec 09, 2016 at 12:28:52PM +0100, Michal Wajdeczko wrote: > On Thu, Dec 08, 2016 at 03:02:12PM -0800, anushasr wrote: > > From: Peter Antoine > > > > Rename some of the GuC fw loading code to make them more general. We > > will utilise them for HuC loading as

Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

On Fri, Dec 09, 2016 at 02:06:29PM +0100, Michal Wajdeczko wrote: > On Fri, Dec 09, 2016 at 12:49:02PM +0100, Arkadiusz Hiler wrote: > > On Fri, Dec 09, 2016 at 12:28:52PM +0100, Michal Wajdeczko wrote: > > > On Thu, Dec 08, 2016 at 03:02:12PM -0800, anushasr wrote: > > > > From: Peter Antoine

[Intel-gfx] [PATCH 9/9] drm: kselftest for drm_mm and color adjustment

Check that after applying the driver's color adjustment, fitting of the node and its alignment are still correct. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm_selftests.h | 1 + drivers/gpu/drm/test-drm_mm.c | 178 +

[Intel-gfx] [PATCH 7/9] drm: kselftest for drm_mm and top-down allocation

Check that if we request top-down allocation from drm_mm_insert_node() we receive the next available hole from the top. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm_selftests.h | 1 + drivers/gpu/drm/test-drm_mm.c | 96

[Intel-gfx] [PATCH 5/9] drm: kselftest for drm_mm and alignment

Check that we can request alignment to any power-of-two or prime using a plain drm_mm_node_insert(). Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm_selftests.h | 3 + drivers/gpu/drm/test-drm_mm.c | 113 + 2 files

[Intel-gfx] [PATCH 3/9] drm: kselftest for drm_mm_insert_node()

Exercise drm_mm_insert_node(), check that we can't overfill a range and that the lists are correct after reserving/removing. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm_selftests.h | 1 + drivers/gpu/drm/test-drm_mm.c | 271

[Intel-gfx] [PATCH 6/9] drm: kselftest for drm_mm and eviction

Check that we add arbitrary blocks to the eviction scanner in order to find the first minimal hole that matches our request. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm_selftests.h | 1 + drivers/gpu/drm/test-drm_mm.c | 167

[Intel-gfx] [PATCH 4/9] drm: kselftest for drm_mm_insert_node_in_range()

Exercise drm_mm_insert_node_in_range(), check that we only allocate from the specified range. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm_selftests.h | 1 + drivers/gpu/drm/test-drm_mm.c | 188 + 2 files changed,

[Intel-gfx] [PATCH] drm/i915: Use the MRU stack search after evicting

When we evict from the GTT to make room for an object, the hole we create is put onto the MRU stack inside the drm_mm range manager. On the next search pass, we can speed up a PIN_HIGH allocation by referencing that stack for the new hole. Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

On Fri, Dec 09, 2016 at 11:10:03AM +, Chris Wilson wrote: > On Fri, Dec 09, 2016 at 11:56:10AM +0100, Arkadiusz Hiler wrote: > > On Thu, Dec 08, 2016 at 03:02:14PM -0800, anushasr wrote: > > > -static u32 guc_wopcm_size(struct drm_i915_private *dev_priv) > > > +u32 guc_wopcm_size(struct

Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

On Fri, Dec 09, 2016 at 12:34:55PM +0100, Arkadiusz Hiler wrote: > On Fri, Dec 09, 2016 at 11:10:03AM +, Chris Wilson wrote: > > On Fri, Dec 09, 2016 at 11:56:10AM +0100, Arkadiusz Hiler wrote: > > > On Thu, Dec 08, 2016 at 03:02:14PM -0800, anushasr wrote: > > > > -static u32

Re: [Intel-gfx] [PATCH] drm/i915/perf: More documentation hooked to i915.rst

On Thu, Dec 8, 2016 at 3:53 PM, Daniel Vetter wrote: > On Wed, Dec 07, 2016 at 09:40:33PM +, Robert Bragg wrote: >> This adds a 'Perf' section to i915.rst with the following sub sections: >> - Overview >> - Comparison with Core Perf >> - i915 Driver Entry Points >> - i915

Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

On Thu, Dec 08, 2016 at 03:02:19PM -0800, anushasr wrote: > From: Peter Antoine > > This patch will allow for getparams to return the status of the HuC. > As the HuC has to be validated by the GuC this patch uses the validated > status to show when the HuC is loaded and

[Intel-gfx] [drm-intel:drm-intel-next-queued 1/1] htmldocs: drivers/gpu/drm/i915/i915_drv.h:1106: warning: No description found for parameter 'i915'

tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: 16d98b31f807756269106f9a71b1a3dc0d19c629 commit: 16d98b31f807756269106f9a71b1a3dc0d19c629 [1/1] drm/i915/perf: More documentation hooked to i915.rst reproduce: make htmldocs All warnings (new ones prefixed by >>):

[Intel-gfx] [PATCH 1/9] drm: kselftest for drm_mm_init()

Simple first test to just exercise initialisation of struct drm_mm. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm_selftests.h | 1 + drivers/gpu/drm/test-drm_mm.c | 41 ++ 2 files changed, 42 insertions(+) diff --git

[Intel-gfx] [PATCH 2/9] drm: kselftest for drm_mm_reserve_node()

Exercise drm_mm_reserve_node(), check that we can't reserve an already occupied range and that the lists are correct after reserving/removing. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm_selftests.h | 1 + drivers/gpu/drm/test-drm_mm.c | 143

[Intel-gfx] [PATCH] drm/i915: Retire before attempting to evict from the active lists

Some object retain an extra pin whilst they are active (e.g. contexts). This excludes them from being considered for eviction unless we idle the GPU. If before we look at the active list, before we retire we can hopefully remove a few excess pins and reduce the amount of searching required..

Re: [Intel-gfx] [PATCH 1/9] drm: kselftest for drm_mm_init()

On pe, 2016-12-09 at 13:08 +, Chris Wilson wrote: > Simple first test to just exercise initialisation of struct drm_mm. > > Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source

Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

On Fri, Dec 09, 2016 at 11:56:10AM +0100, Arkadiusz Hiler wrote: > On Thu, Dec 08, 2016 at 03:02:14PM -0800, anushasr wrote: > > -static u32 guc_wopcm_size(struct drm_i915_private *dev_priv) > > +u32 guc_wopcm_size(struct drm_i915_private *dev_priv) > > { > > u32 wopcm_size = GUC_WOPCM_TOP; >

Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

On Fri, Dec 09, 2016 at 12:49:02PM +0100, Arkadiusz Hiler wrote: > On Fri, Dec 09, 2016 at 12:28:52PM +0100, Michal Wajdeczko wrote: > > On Thu, Dec 08, 2016 at 03:02:12PM -0800, anushasr wrote: > > > From: Peter Antoine > > > > > > Rename some of the GuC fw loading code

Re: [Intel-gfx] [PATCH] drm: Add fake controlD* symlinks for backwards compat

On Fri, Dec 09, 2016 at 11:57:34AM +0100, David Herrmann wrote: > Hi Greg > > On Fri, Dec 9, 2016 at 11:53 AM, Greg Kroah-Hartman > wrote: > > On Fri, Dec 09, 2016 at 11:42:01AM +0100, Daniel Vetter wrote: > >> We thought that no userspace is using them, but oops

Re: [Intel-gfx] [PATCH] drm/i915: Respect ring_mask and num_pipes when install IRQ

> On Thu, Dec 08, 2016 at 06:46:49PM +0800, Wang Elaine wrote: > > From: Elaine Wang > > > > Some platforms only have VCS ring in VDBox. To avoid accessing the > > non-existent rings or display registers, check the ring_mask and > > num_pipes in gen8 IRQ install and reset

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Test all fw tables during mock selftests

On 08/12/2016 22:29, Chris Wilson wrote: On Thu, Dec 08, 2016 at 04:52:24PM +, Tvrtko Ursulin wrote: Idea for another late test: for (offset = 0; offset < 0x4; offset++) { fw_domain = intel_uncore_forcewake_for_reg(dev_priv, { .reg = offset }, FW_REG_READ | FW_REG_WRITE);

Re: [Intel-gfx] [PATCH v7 3/4] drm/i915: Find fallback link rate/lane count

On Fri, 09 Dec 2016, Manasi Navare wrote: > If link training fails, then we need to fallback to lower > link rate first and if link training fails at RBR, then > fallback to lower lane count. > This function finds the next lower link rate/lane count > value after link

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Move all the DP compliance data to a separate struct

On Fri, 09 Dec 2016, Manasi Navare wrote: > This patch does not change anything functionally, just cleans up > the DP compliance related variables and stores them all together > in a separate struct intel_dp_compliance. There is another struct > intel_dp_compliance_data

[Intel-gfx] [PATCH] drm: Add fake controlD* symlinks for backwards compat

We thought that no userspace is using them, but oops libdrm is using them to figure out whether a driver supports modesetting. Check out drmCheckModesettingSupported but maybe don't because it's horrible and totally runs counter to where we want to go with libdrm device handling. The function

[Intel-gfx] [PATCH 2/7] drm: Protect master->unique with dev->master_mutex

No one looks at the major/minor versions except the unique/busid stuff. If we protect that with the master_mutex (since it also affects the unique of each master, oh well) we can mark these two IOCTL with DRM_UNLOCKED. While doing this I realized that the comment for the magic_map is outdated,

Re: [Intel-gfx] [PATCH 12/16] drm/i915: Swap if(enable_execlists) in i915_gem_request_alloc for a vfunc

On 09/12/2016 15:25, Chris Wilson wrote: On Fri, Dec 09, 2016 at 03:16:33PM +, Tvrtko Ursulin wrote: On 07/12/2016 13:58, Chris Wilson wrote: A fairly trivial move of a matching pair of routines (for preparing a request for construction) onto an engine vfunc. The ulterior motive is to be

Re: [Intel-gfx] [PATCH 11/16] drm/i915/execlists: Request the kernel context be pinned high

On 07/12/2016 13:58, Chris Wilson wrote: PIN_HIGH is an expensive operation (in comparison to allocating from the hole stack) unsuitable for frequent use (such as switching between contexts). However, the kernel context should be pinned just once for the lifetime of the driver, and here it is

Re: [Intel-gfx] [PATCH 12/16] drm/i915: Swap if(enable_execlists) in i915_gem_request_alloc for a vfunc

On 07/12/2016 13:58, Chris Wilson wrote: A fairly trivial move of a matching pair of routines (for preparing a request for construction) onto an engine vfunc. The ulterior motive is to be able to create a mock request implementation. Signed-off-by: Chris Wilson ---

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/7] drm/hisilicon: Don't set drm_device->platformdev

== Series Details == Series: series starting with [1/7] drm/hisilicon: Don't set drm_device->platformdev URL : https://patchwork.freedesktop.org/series/16619/ State : failure == Summary == Series 16619v1 Series without cover letter

Re: [Intel-gfx] [PATCH 8/9] drm: kselftest for drm_mm and top-down alignment

On pe, 2016-12-09 at 13:08 +, Chris Wilson wrote: > Check that if we request top-down allocation with a particular alignment > from drm_mm_insert_node() that the start of the node matches our > request. > > Signed-off-by: Chris Wilson > @@ -1038,6 +1038,98 @@

Re: [Intel-gfx] [PATCH v2] drm/i915: Respect num_pipes when install or reset dispaly IRQ

On Fri, Dec 09, 2016 at 05:45:56PM +0200, Joonas Lahtinen wrote: > On pe, 2016-12-09 at 18:01 +0800, Wang Elaine wrote: > > From: Elaine Wang > > > > Some platforms don't have display. To avoid accessing the > > non-existent registers, check whether num_pipes isn't zero >

Re: [Intel-gfx] [PATCH] drm: Add fake controlD* symlinks for backwards compat

Hey On Fri, Dec 9, 2016 at 2:56 PM, Daniel Vetter wrote: > We thought that no userspace is using them, but oops libdrm is using > them to figure out whether a driver supports modesetting. Check out > drmCheckModesettingSupported but maybe don't because it's horrible and >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Add fake controlD* symlinks for backwards compat (rev2)

== Series Details == Series: drm: Add fake controlD* symlinks for backwards compat (rev2) URL : https://patchwork.freedesktop.org/series/16605/ State : success == Summary == Series 16605v2 drm: Add fake controlD* symlinks for backwards compat

Re: [Intel-gfx] [PATCH] drm: Add fake controlD* symlinks for backwards compat

On Fri, Dec 09, 2016 at 02:56:56PM +0100, Daniel Vetter wrote: > We thought that no userspace is using them, but oops libdrm is using > them to figure out whether a driver supports modesetting. Check out > drmCheckModesettingSupported but maybe don't because it's horrible and > totally runs

[Intel-gfx] [PATCH 7/7] drm: Resurrect atomic rmfb code

This was somehow lost between v3 and the merged version in Maarten's patch merged as: commit f2d580b9a8149735cbc4b59c4a8df60173658140 Author: Maarten Lankhorst Date: Wed May 4 14:38:26 2016 +0200 drm/core: Do not preserve framebuffer on rmfb, v4. Actual

[Intel-gfx] [PATCH 5/7] drm: Don't compute obj counts expensively in get_resources

Looping when we keep track of this is silly. Only thing we have to be careful is with sampling the connector count. To avoid inconsisten results due to gcc re-computing this, use READ_ONCE. And to avoid surprising userspace, make sure we don't copy more connectors than planned, and report the

Re: [Intel-gfx] [PATCH 2/9] drm: kselftest for drm_mm_reserve_node()

On pe, 2016-12-09 at 13:08 +, Chris Wilson wrote: > Exercise drm_mm_reserve_node(), check that we can't reserve an already > occupied range and that the lists are correct after reserving/removing. > > Signed-off-by: Chris Wilson > --- >  

Re: [Intel-gfx] [PATCH 2/7] drm: Protect master->unique with dev->master_mutex

On 9 December 2016 at 14:19, Daniel Vetter wrote: > No one looks at the major/minor versions except the unique/busid > stuff. If we protect that with the master_mutex (since it also affects > the unique of each master, oh well) we can mark these two IOCTL with >

Re: [Intel-gfx] [PATCH 09/16] drm/i915: Simplify releasing context reference

On 07/12/2016 13:58, Chris Wilson wrote: A few users only take the struct_mutex in order to release a reference to a context. We can expose a kref_put_mutex() wrapper in order to simplify these users, and optimise taking of the mutex to the final unref. Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 10/16] drm/i915: Mark the shadow gvt context as closed

On 07/12/2016 13:58, Chris Wilson wrote: As the shadow gvt is not user accessible and does not have an associated vm, we can mark it as closed during its construction. This saves leaking the internal knowledge of i915_gem_context into gvt/. Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 12/16] drm/i915: Swap if(enable_execlists) in i915_gem_request_alloc for a vfunc

On Fri, Dec 09, 2016 at 03:16:33PM +, Tvrtko Ursulin wrote: > > On 07/12/2016 13:58, Chris Wilson wrote: > >A fairly trivial move of a matching pair of routines (for preparing a > >request for construction) onto an engine vfunc. The ulterior motive is > >to be able to create a mock request

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Use the MRU stack search after evicting

== Series Details == Series: drm/i915: Use the MRU stack search after evicting URL : https://patchwork.freedesktop.org/series/16613/ State : warning == Summary == Series 16613v1 drm/i915: Use the MRU stack search after evicting

Re: [Intel-gfx] [PATCH] drm: Add fake controlD* symlinks for backwards compat

On 9 December 2016 at 13:56, Daniel Vetter wrote: > We thought that no userspace is using them, but oops libdrm is using > them to figure out whether a driver supports modesetting. Check out > drmCheckModesettingSupported but maybe don't because it's horrible and > totally

[Intel-gfx] [PATCH 6/7] drm: Don't walk fb list twice in getresources

We can be more clever than that and merge the 2 list walking loops. It's all under the one mutex critical section anyway, so nothing funny can happen. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_mode_config.c | 28 +++- 1 file changed,

[Intel-gfx] [PATCH 4/7] drm: Enforce BKL-less ioctls for modern drivers

With the last round of changes all ioctls called by modern drivers now have their own locking. Everything else is only allowed for legacy drivers and hence the lack of locking doesn't matter. One exception is nouveau, due to the DRIVER_KMS_LEGACY_CONTEXT flag. But that only works its magic on the

[Intel-gfx] [PATCH 3/7] drm: setclientcap doesn't need the drm BKL

It only updates per-file feature flags. And all the ioctl which change behaviour depending upon these flags (they're all kms features) do _not_ hold the BKL. Therefor this is pure cargo-cult and can be removed. Note that there's a risk that the ioctl will behave inconsistently, but that's ok. The

[Intel-gfx] [PATCH 1/7] drm/hisilicon: Don't set drm_device->platformdev

It's deprecated and only should be used by drivers which still use drm_platform_init, not by anyone else. And indeed it's entirely unused and can be nuked. This required a bit more fudging, but I guess kirin_dc_ops really wants to operate on the platform_device, not something else. Also bonus

Re: [Intel-gfx] [PATCH 2/9] drm: kselftest for drm_mm_reserve_node()

On Fri, Dec 09, 2016 at 04:31:50PM +0200, Joonas Lahtinen wrote: > On pe, 2016-12-09 at 13:08 +, Chris Wilson wrote: > > +static int igt_reserve(void *ignored) > > +{ > > + int n, ret; > > + > > + for (n = 1; n < 50; n++) { > > The right amount of loops might be something to discuss. The

[Intel-gfx] [PATCH v2] drm/i915: Retire before attempting to evict from the active lists

Some object retain an extra pin whilst they are active (e.g. contexts). This excludes them from being considered for eviction unless we idle the GPU. If before we look at the active list, before we retire we can hopefully remove a few excess pins and reduce the amount of searching required. v2:

Re: [Intel-gfx] [PATCH 13/16] drm/i915: Add selftests for i915_gem_request

On 07/12/2016 13:58, Chris Wilson wrote: Simple starting point for adding seltests for i915_gem_request, first mock a device (with engines and contexts) that allows us to construct and execute a request, along with waiting for the request to complete. Signed-off-by: Chris Wilson

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/psr: report psr2 hw enabled from psr2_ctl

== Series Details == Series: drm/i915/psr: report psr2 hw enabled from psr2_ctl URL : https://patchwork.freedesktop.org/series/16628/ State : warning == Summary == Series 16628v1 drm/i915/psr: report psr2 hw enabled from psr2_ctl

[Intel-gfx] [PATCH 1/5] dma-buf: Extract dma-buf.rst

Just prep work to polish and consolidate all the dma-buf related documenation. Unfortunately I didn't discover a way to both integrate this new file into the overall toc while keeping it at the current place. Work around that by moving it into the overall driver-api/index.rst. Cc:

  1   2   >