[Intel-gfx] [PATCH] kms_atomic : Added subtest for Single Pipe DBUF validation

Existing DDB algorithm divide the DDB wrt data rate, hence the planes with the less height but same width will be allocated less blocks and watermark are based on width which requires more DDB. With this data the flip may fail. In new DDB algorithm, the DDB is divided based on watermark

Re: [Intel-gfx] [i-g-t PATCH 3/3] igt/drv_module_reload_basic: let intel_ips removal errors through

On ma, 2016-10-03 at 17:20 +0300, Jani Nikula wrote: > Only try removing intel_ips if it's actually loaded, and let the errors > through to the logs if removal fails. > > Signed-off-by: Jani Nikula Reviewed-by: Joonas Lahtinen Regards,

Re: [Intel-gfx] [i-g-t PATCH 2/3] igt/drv_module_reload_basic: let snd_hda_intel removal errors through

On ma, 2016-10-03 at 17:20 +0300, Jani Nikula wrote: > Only try removing snd_hda_intel if it's actually loaded, and let the > errors through to the logs if removal fails. This is a clue if i915 > removal fails later. > > Signed-off-by: Jani Nikula Reviewed-by: Joonas

Re: [Intel-gfx] [i-g-t PATCH 1/3] igt/drv_module_reload_basic: add helper for checking module reloaded

On ma, 2016-10-03 at 17:20 +0300, Jani Nikula wrote: > Add a helper for checking whether a module is reloaded, using > lsmod. Also make the grep stricter than before. > > Signed-off-by: Jani Nikula Reviewed-by: Joonas Lahtinen Regards,

Re: [Intel-gfx] [PULL] topic/drm-misc

On 3 October 2016 at 23:39, Daniel Vetter wrote: > Hi Dave, > > As promised another pull request. A bit late because flu. > - generic pipe crc from Tomeu, required a backmerge to apply > - fixes for my fumbled drm_plane.c extraction > - display_info cleanup/fixes from

Re: [Intel-gfx] [PATCH 2/2] drm/i915: KBL - Recommended buffer translation programming for DisplayPort

On Mon, 2016-10-03 at 13:50 +0300, Jani Nikula wrote: > On Fri, 30 Sep 2016, Rodrigo Vivi wrote: > > According to spec: "KBL re-uses SKL values, except where > > specific KBL values are listed." > > > > And recently spec has changed adding different table for Display Port

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/dp/psr: Enable n + 1 active frame capture for PSR

== Series Details == Series: drm/i915/dp/psr: Enable n + 1 active frame capture for PSR URL : https://patchwork.freedesktop.org/series/13249/ State : warning == Summary == Series 13249v1 drm/i915/dp/psr: Enable n + 1 active frame capture for PSR

Re: [Intel-gfx] [PATCH v7 1/6] drm/i915: Fallback to lower link rate and lane count during link training

On Thu, Sep 29, 2016 at 04:17:06PM -0700, Manasi Navare wrote: > On Thu, Sep 29, 2016 at 09:05:01AM -0700, Manasi Navare wrote: > > On Thu, Sep 29, 2016 at 06:48:43PM +0300, Jani Nikula wrote: > > > On Thu, 29 Sep 2016, Ville Syrjälä wrote: > > > > On Thu, Sep 29,

[Intel-gfx] [PATCH RFC] drm/i915/dp/psr: Enable n + 1 active frame capture for PSR

On some system + panel combinations the vblank interval is too short for PSR setup to occur. While reading the eDP v1.3 spec I saw that Figure 4-7 describes a solution to this very problem by configuring PSR to capture the second active frame after the PSR entry indication in order to provide

[Intel-gfx] ✗ Fi.CI.BAT: warning for HuC Loading Patches

== Series Details == Series: HuC Loading Patches URL : https://patchwork.freedesktop.org/series/13244/ State : warning == Summary == Series 13244v1 HuC Loading Patches https://patchwork.freedesktop.org/api/1.0/series/13244/revisions/1/mbox/ Test drv_module_reload_basic: skip

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

From: Peter Antoine This patch returns the GuC status to the caller. It is used so that the userspace knows if the GuC has been loaded. v4: rebase. v5: rebased. Signed-off-by: Anusha Srivatsa Signed-off-by: Peter Antoine

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

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 Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,

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

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 ready for use. You cannot use the loaded status as with the GuC as

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

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 version 1.7. v3: rebased on top of drm-intel-nightly. v4: changed

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

From: Peter Antoine 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 before loading any of them. v2: rebased on-top of drm-intel-nightly.

[Intel-gfx] [PATCH 4/8] drm/i915/huc: Add debugfs for HuC loading status check

From: Peter Antoine Add debugfs entry for HuC loading status check. v2: rebase on-top of drm-intel-nightly. v3: rebased again. v7: rebased. v8: rebased. Tested-by: Xiang Haihao Signed-off-by: Anusha Srivatsa

[Intel-gfx] [PATCH 6/8] drm/i915/huc: Add BXT HuC Loading Support

From: Peter Antoine This patch adds the HuC Loading for the BXT. Version 1.7 of the HuC firmware. v2: rebased. v3: rebased. changed file name to match the install package format. v7: rebased. v8: rebased. Signed-off-by: Anusha Srivatsa

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

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 is. So, the loader will pull right sw_version from header. v2:

[Intel-gfx] [PATCH 0/8] HuC Loading Patches

These patches add HuC loading support. The userspace patches that check for a fully loaded HuC firmware and use it can be found at: https://lists.freedesktop.org/archives/libva/2016-September/004554.html https://lists.freedesktop.org/archives/libva/2016-September/004555.html v2: rebased. Peter

Re: [Intel-gfx] [PATCH i-g-t] Update MAINTAINERS file

On Mon, Oct 3, 2016 at 3:06 PM, Petri Latvala wrote: > Add myself, remove Daniel by request. > > Signed-off-by: Petri Latvala > --- > > For the record. > > Daniel requested to be removed from the list (Daniel, please confirm, > that's how I

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/8] drm/i915: Share the computation of ring size for RING_CTL register

== Series Details == Series: series starting with [1/8] drm/i915: Share the computation of ring size for RING_CTL register URL : https://patchwork.freedesktop.org/series/13231/ State : warning == Summary == Series 13231v1 Series without cover letter

[Intel-gfx] [PATCH i-g-t] tests: kms_pipe_color: fix ctm tests

Some of the Intel platforms have odd numbers of LUT entries and we need to tests a couple of values around the expected result. Bring back the CRC equal function we need that doesn't trigger an assert right away, while we still assert if we can't find a correct result in the outter loop. v2:

[Intel-gfx] [i-g-t PATCH 0/3] igt/drv_module_reload_basic: let more error messages through

Thes might leave us some more breadcrumbs on module removal errors. BR, Jani. Jani Nikula (3): igt/drv_module_reload_basic: add helper for checking module reloaded igt/drv_module_reload_basic: let snd_hda_intel removal errors through igt/drv_module_reload_basic: let intel_ips removal

[Intel-gfx] [i-g-t PATCH 2/3] igt/drv_module_reload_basic: let snd_hda_intel removal errors through

Only try removing snd_hda_intel if it's actually loaded, and let the errors through to the logs if removal fails. This is a clue if i915 removal fails later. Signed-off-by: Jani Nikula --- tests/drv_module_reload_basic | 4 +++- 1 file changed, 3 insertions(+), 1

[Intel-gfx] [i-g-t PATCH 1/3] igt/drv_module_reload_basic: add helper for checking module reloaded

Add a helper for checking whether a module is reloaded, using lsmod. Also make the grep stricter than before. Signed-off-by: Jani Nikula --- tests/drv_module_reload_basic | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git

[Intel-gfx] [i-g-t PATCH 3/3] igt/drv_module_reload_basic: let intel_ips removal errors through

Only try removing intel_ips if it's actually loaded, and let the errors through to the logs if removal fails. Signed-off-by: Jani Nikula --- tests/drv_module_reload_basic | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/3] drm/i915: Just clear the mmiodebug before a register access

== Series Details == Series: series starting with [CI,1/3] drm/i915: Just clear the mmiodebug before a register access URL : https://patchwork.freedesktop.org/series/13230/ State : warning == Summary == Series 13230v1 Series without cover letter

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Double check hangcheck.seqno after reset

On Mon, Oct 03, 2016 at 04:14:39PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > Check that there was not a late recovery between us declaring the GPU > > hung and processing the reset. If the GPU did recover by itself, let the > > request remain on the

Re: [Intel-gfx] [drm-intel:topic/drm-misc 3/3] htmldocs: include/drm/drm_fb_helper.h:222: warning: Cannot understand * @DRM_FB_HELPER_DEFAULT_OPS:

On Mon, Oct 3, 2016 at 11:35 AM, Jani Nikula wrote: >>220/** >>221 * @DRM_FB_HELPER_DEFAULT_OPS: > > Superfluous @. Stefan, pls fix this and run $ make htmldocs to make sure the output looks correct. Cargo-culting kerneldoc without checking

[Intel-gfx] [PULL] topic/drm-misc

Hi Dave, As promised another pull request. A bit late because flu. - generic pipe crc from Tomeu, required a backmerge to apply - fixes for my fumbled drm_plane.c extraction - display_info cleanup/fixes from Ville - misc stuff all over Cheers, Daniel The following changes since commit

Re: [Intel-gfx] [PATCH i-g-t] Update MAINTAINERS file

On Mon, 03 Oct 2016, Petri Latvala wrote: > Add myself, remove Daniel by request. > > Signed-off-by: Petri Latvala Acked-by: Jani Nikula > --- > > For the record. > > Daniel requested to be removed from the list

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Double check hangcheck.seqno after reset

Chris Wilson writes: > Check that there was not a late recovery between us declaring the GPU > hung and processing the reset. If the GPU did recover by itself, let the > request remain on the active list and see if it hangs again! > Did you see this in action? Makes

Re: [Intel-gfx] [PATCH 4/8] drm/i915: Disable irqs across GPU reset

Chris Wilson writes: > Whilst we reset the GPU, we want to prevent execlists from submitting > new work (which it does via an interrupt handler). To achieve this we > disable the irq (and drain the irq tasklet) around the reset. When we > enable it again afters, the

Re: [Intel-gfx] [PATCH 3/8] drm/i915/execlists: Move clearing submission count from reset to init

Chris Wilson writes: > After a GPU reset, we want to replay our queue of requests. However, the > GPU reset clobbered the state and we only fixup the state for the > guitly s/guitly/guilty. Reviewed-by: Mika Kuoppala > request - and engines

[Intel-gfx] [PATCH i-g-t] Update MAINTAINERS file

Add myself, remove Daniel by request. Signed-off-by: Petri Latvala --- For the record. Daniel requested to be removed from the list (Daniel, please confirm, that's how I understood), and I'm going to be maintaining IGT with Marius until Marius steps down. MAINTAINERS

Re: [Intel-gfx] [PATCH 1/8] drm/i915: Share the computation of ring size for RING_CTL register

Chris Wilson writes: > Since both legacy and execlists want to poopulate the RING_CTL > register, A bit too graphic, lets switch to populate. Reviewed-by: Mika Kuoppala > share the computation of the right bits for the ring->size. We can

Re: [Intel-gfx] [PATCH 1/8] drm/i915: Share the computation of ring size for RING_CTL register

On Mon, Oct 03, 2016 at 01:52:39PM +0100, Chris Wilson wrote: > Since both legacy and execlists want to poopulate the RING_CTL register, > share the computation of the right bits for the ring->size. We can then > stop masking errors and explicitly forbid them during creation! > > Signed-off-by:

Re: [Intel-gfx] [PATCH v2 13/22] drm/i915: Update reset path to fix incomplete requests

On Mon, Oct 03, 2016 at 01:44:14PM +0100, Tvrtko Ursulin wrote: > >+static void i915_gem_cleanup_engine(struct intel_engine_cs *engine) > > I am aware this is a late comment, but wanted to say that the name > above is not ideal since we have both i915_gem_cleanup_engines and >

[Intel-gfx] [PATCH 2/8] drm/i915/execlists: Reinitialise context image after GPU hang

On Braswell, at least, we observe that the context image is written in multiple phases. The first phase is to clear the register state, and subsequently rewrite it. A GPU reset at the right moment can interrupt the context update leaving it corrupt, and our update of the RING_HEAD is not

[Intel-gfx] [PATCH 7/8] drm/i915: Show RING registers through debugfs

Knowing where the RINGs are pointing is extremely useful in diagnosing if the engines are executing the ringbuffers you expect - and igt may be suppressing the usual method of looking in the GPU error state. Signed-off-by: Chris Wilson Cc: Mika Kuoppala

[Intel-gfx] [PATCH 8/8] drm/i915: Show waiters in i915_hangcheck_info

Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 9c95ce73f2aa..39b76c24c84f 100644 ---

[Intel-gfx] [PATCH 4/8] drm/i915: Disable irqs across GPU reset

Whilst we reset the GPU, we want to prevent execlists from submitting new work (which it does via an interrupt handler). To achieve this we disable the irq (and drain the irq tasklet) around the reset. When we enable it again afters, the interrupt queue should be empty and we can reinitialise from

[Intel-gfx] [PATCH 3/8] drm/i915/execlists: Move clearing submission count from reset to init

After a GPU reset, we want to replay our queue of requests. However, the GPU reset clobbered the state and we only fixup the state for the guitly request - and engines deemed innocent we try to leave untouched so that we recover as completely as possible. However, we need to clear the sw tracking

[Intel-gfx] [PATCH 1/8] drm/i915: Share the computation of ring size for RING_CTL register

Since both legacy and execlists want to poopulate the RING_CTL register, share the computation of the right bits for the ring->size. We can then stop masking errors and explicitly forbid them during creation! Signed-off-by: Chris Wilson Cc: Mika Kuoppala

[Intel-gfx] [PATCH 6/8] drm/i915: Show bounds of active request in the ring on GPU hang

Include the position of the active request in the ring, and display that alongside the current RING registers (on a GPU hang). Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- drivers/gpu/drm/i915/i915_drv.h | 3 +++

[Intel-gfx] [PATCH 5/8] drm/i915: Double check hangcheck.seqno after reset

Check that there was not a late recovery between us declaring the GPU hung and processing the reset. If the GPU did recover by itself, let the request remain on the active list and see if it hangs again! Signed-off-by: Chris Wilson Cc: Mika Kuoppala

[Intel-gfx] [CI 1/3] drm/i915: Just clear the mmiodebug before a register access

When we enable the per-register access mmiodebug, it is to detect which access is illegal. Reporting on earlier untraced access outside of the mmiodebug does not help debugging (as the suspicion is immediately put upon the current register which is not at fault)! References:

[Intel-gfx] [CI 3/3] drm/i915: Use correct index for backtracking HUNG semaphores

When decoding the semaphores inside hangcheck, we need to use the hw-id and not the local array index. Fixes: de1add360522 ("drm/i915: Decouple execbuf uAPI ...") Testcase: igt/gem_exec_whisper/hang # gen6-7 Signed-off-by: Chris Wilson Cc: Mika Kuoppala

[Intel-gfx] [CI 2/3] drm/i915: Unalias obj->phys_handle and obj->userptr

We use obj->phys_handle to choose the pread/pwrite path, but as obj->phys_handle is a union with obj->userptr, we then mistakenly use the phys_handle path for userptr objects within pread/pwrite. Testcase: igt/gem_userptr_blits/forbidden-operations Bugzilla:

Re: [Intel-gfx] [PATCH v2 13/22] drm/i915: Update reset path to fix incomplete requests

On 07/09/2016 15:45, Chris Wilson wrote: Update reset path in preparation for engine reset which requires identification of incomplete requests and associated context and fixing their state so that engine can resume correctly after reset. The request that caused the hang will be skipped and

Re: [Intel-gfx] [PATCH] drm/i915: Disable irqs across GPU reset

Chris Wilson writes: > Whilst we reset the GPU, we want to prevent execlists from submitting > new work (which it does via an interrupt handler). To achieve this we > disable the irq (and drain the irq tasklet) around the reset. When we > enable it again afters, the

Re: [Intel-gfx] [PATCH 1/3] drm/i915/execlists: Reinitialise context image after GPU hang

Chris Wilson writes: > On Braswell, at least, we observe that the context image is written in > multiple phases. The first phase is to clear the register state, and > subsequently rewrite it. A GPU reset at the right moment can interrupt > the context update leaving it

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move long hpd handling into the hotplug work

On Mon, 2016-10-03 at 10:55 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > We can't rely on connector->status in the detect() hook if the long hpd > was already handled by the dig_port_work as that won't update > connector->status. Thus we

Re: [Intel-gfx] [PATCH 0/7] drm/i915: Add pipe scaler for Gen9 in atomic path

On Wed, Sep 21, 2016 at 07:47:37PM +0530, Maiti, Nabendu Bikash wrote: > Hi, > > > On 9/20/2016 1:55 PM, Ville Syrjälä wrote: > > On Tue, Aug 30, 2016 at 10:30:54AM +0530, Nabendu Maiti wrote: > >> Following patch series add pipe scaler functionality in atomic path.The > >> pipe > >> scaler can

Re: [Intel-gfx] [PATCH 2/2] drm/i915: KBL - Recommended buffer translation programming for DisplayPort

On Fri, 30 Sep 2016, Rodrigo Vivi wrote: > According to spec: "KBL re-uses SKL values, except where > specific KBL values are listed." > > And recently spec has changed adding different table for Display Port only. > But for all SKUs (H,S,U,Y) we have slightly different

Re: [Intel-gfx] [PATCH] drm/i915: Just clear the mmiodebug before a register access

Chris Wilson writes: > When we enable the per-register access mmiodebug, it is to detect which > access is illegal. Reporting on earlier untraced access outside of the > mmiodebug does not help debugging (as the suspicion is immediately put > upon the current register

Re: [Intel-gfx] [PATCH] drm/i915: Just clear the mmiodebug before a register access

On Mon, Oct 03, 2016 at 01:09:31PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > When we enable the per-register access mmiodebug, it is to detect which > > access is illegal. Reporting on earlier untraced access outside of the > > mmiodebug does not help

Re: [Intel-gfx] [PATCH] drm/i915: Just clear the mmiodebug before a register access

Chris Wilson writes: > When we enable the per-register access mmiodebug, it is to detect which > access is illegal. Reporting on earlier untraced access outside of the > mmiodebug does not help debugging (as the suspicion is immediately put > upon the current register

Re: [Intel-gfx] [drm-intel:topic/drm-misc 3/3] htmldocs: include/drm/drm_fb_helper.h:222: warning: Cannot understand * @DRM_FB_HELPER_DEFAULT_OPS:

On Fri, 30 Sep 2016, kbuild test robot wrote: > tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc > head: 6c4d6f9f997c5dafccb54b52167f0c4d0ea37874 > commit: 6c4d6f9f997c5dafccb54b52167f0c4d0ea37874 [3/3] drm/fb-helper: add > DRM_FB_HELPER_DEFAULT_OPS for

[Intel-gfx] ✗ Fi.CI.BAT: warning for Forcewake binary search & code shrink (rev6)

== Series Details == Series: Forcewake binary search & code shrink (rev6) URL : https://patchwork.freedesktop.org/series/13080/ State : warning == Summary == Series 13080v6 Forcewake binary search & code shrink https://patchwork.freedesktop.org/api/1.0/series/13080/revisions/6/mbox/ Test

[Intel-gfx] [PATCH 12/14] drm/i915: Sort the shadow register table

From: Tvrtko Ursulin Also verify the order at runtime. This was we can start using binary search on it in a following patch. v2: Add comment on the sorted array and only check it when debug option is enabled. v3: Use IS_ENABLED. (Chris Wilson) Signed-off-by:

[Intel-gfx] [PATCH 08/14] drm/i915: Store the active forcewake range table pointer

From: Tvrtko Ursulin If we store this in the uncore structure we are on a good way to show more commonality between the per-platform implementations. v2: Constify table pointer and correct coding style. (Chris Wilson) v3: Rebase. Signed-off-by: Tvrtko Ursulin

[Intel-gfx] [PATCH 05/14] drm/i915: Sort forcewake mapping tables

From: Tvrtko Ursulin Sorting the tables (verified at runtime to help during development) is another prerequisite for interesting work which will follow. v2: * Remove const away cast and improve comments. (Chris Wilson) * Check tables only when debug option is

Re: [Intel-gfx] [PATCH 13/14] drm/i915: Use binary search when looking for shadowed registers

On 03/10/2016 09:05, Joonas Lahtinen wrote: On pe, 2016-09-30 at 19:08 +0100, Chris Wilson wrote: On Fri, Sep 30, 2016 at 06:48:48PM +0100, Tvrtko Ursulin wrote: +static int mmio_reg_cmp(const void *key, const void *elt) +{ + u32 offset = (u32)(unsigned long)key; + i915_reg_t *reg

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Move long hpd handling into the hotplug work

== Series Details == Series: series starting with [1/2] drm/i915: Move long hpd handling into the hotplug work URL : https://patchwork.freedesktop.org/series/13225/ State : success == Summary == Series 13225v1 Series without cover letter

Re: [Intel-gfx] [PATCH 13/14] drm/i915: Use binary search when looking for shadowed registers

On pe, 2016-09-30 at 19:08 +0100, Chris Wilson wrote: > On Fri, Sep 30, 2016 at 06:48:48PM +0100, Tvrtko Ursulin wrote:  > > +static int mmio_reg_cmp(const void *key, const void *elt) > > +{ > > + u32 offset = (u32)(unsigned long)key; > > + i915_reg_t *reg = (i915_reg_t *)elt; > > + > > + if

Re: [Intel-gfx] [PATCH 04/14] drm/i915: Data driven register to forcewake domains lookup

On pe, 2016-09-30 at 18:48 +0100, Tvrtko Ursulin wrote: > > +find_fw_domain(u32 offset, const struct intel_forcewake_range *ranges, > +    unsigned int num_ranges) Gotta remind that generally "fw" is associated with firmware. "forcewake" might be appropriate word in function names too.

[Intel-gfx] [PATCH 1/2] drm/i915: Move long hpd handling into the hotplug work

From: Ville Syrjälä We can't rely on connector->status in the detect() hook if the long hpd was already handled by the dig_port_work as that won't update connector->status. Thus we have to defer the long hpd handling entirely until the hotplug work runs to avoid

[Intel-gfx] [PATCH 2/2] drm/i915: Allow DP to work w/o EDID

From: Ville Syrjälä Allow returning "connected" or "unknown" connector status for DP branch devices that don't have an EDID. Currently we'd claim the thing as "disconnected" if there is no EDID. This stuff used to broken already, I think, but it got more broken by

Re: [Intel-gfx] [PATCH] drm/prime: Passing the right owner through to dma_buf_export()

On pe, 2016-09-30 at 11:38 +0100, Chris Wilson wrote: > dma_buf_export() adds a reference to the owning module to the dmabuf (to > prevent the driver from being unloaded whilst a third party still refers > to the dmabuf). However, drm_gem_prime_export() was passing its own > THIS_MODULE (i.e.

Re: [Intel-gfx] [PATCH] drm/i915: Use correct index for backtracking HUNG semaphores

On la, 2016-10-01 at 20:42 +0100, Chris Wilson wrote: > When decoding the semaphores inside hangcheck, we need to use the hw-id > and not the local array index. > > Fixes: de1add360522 ("drm/i915: Decouple execbuf uAPI ...") > Testcase: igt/gem_exec_whisper/hang # gen6-7 > Signed-off-by: Chris

Re: [Intel-gfx] [PATCH] drm/i915: Unalias obj->phys_handle and obj->userptr

On pe, 2016-09-30 at 18:31 +0100, Chris Wilson wrote: > We use obj->phys_handle to choose the pread/pwrite path, but as > obj->phys_handle is a union with obj->userptr, we then mistakenly use > the phys_handle path for userptr objects within pread/pwrite. > > Testcase: