[Intel-gfx] [PATCH ddx 2/2] pciids: : Removing PCI IDs that are no longer listed as Kabylake.

This is unusual. Usually IDs listed on early stages of platform definition are kept there as reserved for later use. However these IDs here are not listed anymore in any of steppings and devices IDs tables for Kabylake on configurations overview section of BSpec. So it is better removing them

[Intel-gfx] [PATCH ddx 1/2] pciids: Add more Kabylake PCI IDs.

The spec has been updated adding new PCI IDs. In parity with kernel: commit 33d9391d3020e069dca98fa87a604c037beb2b9e Author: Rodrigo Vivi Date: Thu Jun 23 14:50:35 2016 -0700 drm/i915: Add more Kabylake PCI IDs. Cc: Chris Wilson

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

I don't believe we need to be that extreme here. Daniel asked a cleaner version, but we don't need to block the huc on a full rework of an unified fw loader. On Tue, Jun 28, 2016 at 8:45 AM, Dave Gordon wrote: > On 28/06/16 15:54, Dave Gordon wrote: >> >> On 21/06/16

Re: [Intel-gfx] [PATCH 2/2] lib/intel_chipset: Removing PCI IDs that are no longer listed as Kabylake.

On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote: > This is unusual. Usually IDs listed on early stages of platform > definition are kept there as reserved for later use. > > However these IDs here are not listed anymore in any of steppings > and devices IDs tables for Kabylake on

[Intel-gfx] Using VDBOX/VEBOX with the Open Source Linux Driver

Does anyone have any sample code or demo applications for VDBOX/VEBOX? Are these the only documents on how to use the Media VDBOX and VEBOX? https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol08-media_vdbox.pdf

Re: [Intel-gfx] [PATCH 2/2] i965: Removing PCI IDs that are no longer listed as Kabylake.

On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote: > This is unusual. Usually IDs listed on early stages of platform > definition are kept there as reserved for later use. > > However these IDs here are not listed anymore in any of steppings > and devices IDs tables for Kabylake on

Re: [Intel-gfx] [PATCH 1/2] i956: Add more Kabylake PCI IDs.

On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote: > The spec has been updated adding new PCI IDs. > > Signed-off-by: Rodrigo Vivi > --- > include/pci_ids/i965_pci_ids.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/include/pci_ids/i965_pci_ids.h

Re: [Intel-gfx] [PATCH 2/2] pciids: : Removing PCI IDs that are no longer listed as Kabylake.

On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote: > This is unusual. Usually IDs listed on early stages of platform > definition are kept there as reserved for later use. > > However these IDs here are not listed anymore in any of steppings > and devices IDs tables for Kabylake on

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Removing PCI IDs that are no longer listed as Kabylake.

On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote: > - INTEL_VGA_DEVICE(0x5932, info), /* DT GT4 */ \ > - INTEL_VGA_DEVICE(0x593B, info), /* Halo GT4 */ \ > - INTEL_VGA_DEVICE(0x593A, info), /* SRV GT4 */ \ > - INTEL_VGA_DEVICE(0x593D, info) /* WKS GT4 Reviewed-by:

Re: [Intel-gfx] [PATCH] drm/i915: Skip fbdev core suspend/resume when fbdev emulation is disabled.

On Tue, Jun 28, 2016 at 09:51:34AM -0700, Bob Paauwe wrote: > On Tue, 28 Jun 2016 16:47:28 +0100 > Chris Wilson wrote: > > > On Tue, Jun 28, 2016 at 08:42:01AM -0700, Bob Paauwe wrote: > > > When fbdev emulation is disabled it is not a good idea to call into > > > the

Re: [Intel-gfx] [PATCH v3] drm/i915: Use atomic waits for short non-atomic ones

On Tue, Jun 28, 2016 at 05:20:43PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > usleep_range is not recommended for waits shorten than 10us. > > Make the wait_for_us use the atomic variant for such waits. > > To do so we need to reimplement the

Re: [Intel-gfx] ✓ Ro.CI.BAT: success for series starting with [1/2] drm/i915/debug: Select PREEMPT_COUNT when enabling debugging (rev3)

On Tue, Jun 28, 2016 at 05:03:20PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [1/2] drm/i915/debug: Select PREEMPT_COUNT when > enabling debugging (rev3) > URL : https://patchwork.freedesktop.org/series/9226/ > State : success > > == Summary == > > Series

Re: [Intel-gfx] [PATCH 1/2] intel: Add more Kabylake PCI IDs.

On Mon, 2016-06-27 at 17:10 -0700, Rodrigo Vivi wrote: > The spec has been updated adding new PCI IDs. > > v2: Avoid using "H" instead of HALO to keep names uniform - DK. > > Cc: Dhinakaran Pandiyan > Signed-off-by: Rodrigo Vivi > --- >

Re: [Intel-gfx] [PATCH 2/2] intel: Removing PCI IDs that are no longer listed as Kabylake.

On Mon, 2016-06-27 at 17:10 -0700, Rodrigo Vivi wrote: > This is unusual. Usually IDs listed on early stages of platform > definition are kept there as reserved for later use. > > However these IDs here are not listed anymore in any of steppings > and devices IDs tables for Kabylake on

Re: [Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915: Avoid early timeout due to wait_for_atomic

On Tue, 2016-06-28 at 11:00 +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Avoid early timeout due to wait_for_atomic > URL   : https://patchwork.freedesktop.org/series/9224/ > State : success Thanks for the reviews, I pushed the patchset to -dinq. I also added CC:

Re: [Intel-gfx] [PATCH i-g-t 1/2] lib/intel_chipset: Add more Kabylake PCI IDs.

On Mon, 2016-06-27 at 17:11 -0700, Rodrigo Vivi wrote: > The spec has been updated adding new PCI IDs. > > v2: Avoid using "H" instead of HALO to keep names uniform - DK. > > Cc: Dhinakaran Pandiyan > Signed-off-by: Rodrigo Vivi > --- >

Re: [Intel-gfx] [PATCH i-g-t 2/2] lib/intel_chipset: Removing PCI IDs that are no longer listed as Kabylake.

On Mon, 2016-06-27 at 17:11 -0700, Rodrigo Vivi wrote: > This is unusual. Usually IDs listed on early stages of platform > definition are kept there as reserved for later use. > > However these IDs here are not listed anymore in any of steppings > and devices IDs tables for Kabylake on

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Re-allocate DDB only for changed pipes

On Tue, Jun 28, 2016 at 10:50:20AM +0200, Maarten Lankhorst wrote: > Op 28-06-16 om 01:42 schreef Matt Roper: > > When a display update triggers a DDB re-allocation, we should start by > > assuming that only the updated pipes need to be re-allocated (we have > > logic later that may add additional

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use atomic waits for short non-atomic ones

On Tue, 2016-06-28 at 15:38 +0100, Tvrtko Ursulin wrote: > On 28/06/16 14:53, Imre Deak wrote: > > On ti, 2016-06-28 at 14:29 +0100, Tvrtko Ursulin wrote: > > > On 28/06/16 13:19, Imre Deak wrote: > > > > On ti, 2016-06-28 at 12:51 +0100, Tvrtko Ursulin wrote: > > > > > From: Tvrtko Ursulin

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: hybrid wait-for macro

== Series Details == Series: drm/i915: hybrid wait-for macro URL : https://patchwork.freedesktop.org/series/9237/ State : failure == Summary == Series 9237v1 drm/i915: hybrid wait-for macro http://patchwork.freedesktop.org/api/1.0/series/9237/revisions/1/mbox Test gem_exec_flush:

Re: [Intel-gfx] [RFC] i915: Add fence fds to execbuffer2 uapi

On 27/06/2016 21:18, Chad Versace wrote: On Mon 27 Jun 2016, Chad Versace wrote: Let the hight 32 bits of drm_i915_gem_execbuffer2::rsvd1 contain an input and/or output fence fd, whose presence is controlled by flags. Also add I915_PARAM_HAS_FENCE_FD. Signed-off-by: Chad Versace

[Intel-gfx] ✓ Ro.CI.BAT: success for series starting with [1/2] drm/i915/debug: Select PREEMPT_COUNT when enabling debugging (rev3)

== Series Details == Series: series starting with [1/2] drm/i915/debug: Select PREEMPT_COUNT when enabling debugging (rev3) URL : https://patchwork.freedesktop.org/series/9226/ State : success == Summary == Series 9226v3 Series without cover letter

[Intel-gfx] [RFC] drm/i915: hybrid wait-for macro

Part spin-wait, part sleep-wait. Plus one example of where it might be used. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_guc_submission.c | 2 +- drivers/gpu/drm/i915/intel_drv.h | 10 ++ 2 files changed, 11 insertions(+), 1 deletion(-)

Re: [Intel-gfx] [PATCH] drm/i915: Skip fbdev core suspend/resume when fbdev emulation is disabled.

On Tue, 28 Jun 2016 16:47:28 +0100 Chris Wilson wrote: > On Tue, Jun 28, 2016 at 08:42:01AM -0700, Bob Paauwe wrote: > > When fbdev emulation is disabled it is not a good idea to call into > > the core fb_set_suspend() function as this will cause suspend and > > resume

[Intel-gfx] ✗ Ro.CI.BAT: warning for series starting with [1/2] drm/i915/debug: Select PREEMPT_COUNT when enabling debugging (rev2)

== Series Details == Series: series starting with [1/2] drm/i915/debug: Select PREEMPT_COUNT when enabling debugging (rev2) URL : https://patchwork.freedesktop.org/series/9226/ State : warning == Summary == Series 9226v2 Series without cover letter

[Intel-gfx] [PATCH v3] drm/i915: Use atomic waits for short non-atomic ones

From: Tvrtko Ursulin usleep_range is not recommended for waits shorten than 10us. Make the wait_for_us use the atomic variant for such waits. To do so we need to reimplement the _wait_for_atomic macro to be safe with regards to preemption and interrupts. v2:

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Skip fbdev core suspend/resume when fbdev emulation is disabled.

== Series Details == Series: drm/i915: Skip fbdev core suspend/resume when fbdev emulation is disabled. URL : https://patchwork.freedesktop.org/series/9235/ State : failure == Summary == Series 9235v1 drm/i915: Skip fbdev core suspend/resume when fbdev emulation is disabled.

[Intel-gfx] [PATCH v2] drm/i915: Use atomic waits for short non-atomic ones

From: Tvrtko Ursulin usleep_range is not recommended for waits shorten than 10us. Make the wait_for_us use the atomic variant for such waits. To do so we need to reimplement the _wait_for_atomic macro to be safe with regards to preemption and interrupts. v2:

Re: [Intel-gfx] [PATCH] drm/i915/guc: Do not use wait_for_atomic in host2guc_action

On 28/06/16 16:50, Dave Gordon wrote: On 28/06/16 15:30, Tvrtko Ursulin wrote: From: Tvrtko Ursulin host2guc_action does not appear to be called from atomic context so a more polite wait_for macro should be used. Especially since the timeout is 10ms. Maybe.

Re: [Intel-gfx] [PATCH] drm/i915/guc: Do not use wait_for_atomic in host2guc_action

On 28/06/16 15:30, Tvrtko Ursulin wrote: From: Tvrtko Ursulin host2guc_action does not appear to be called from atomic context so a more polite wait_for macro should be used. Especially since the timeout is 10ms. Maybe. However we don't really want to sleep if the

Re: [Intel-gfx] [PATCH] drm/i915: Skip fbdev core suspend/resume when fbdev emulation is disabled.

On Tue, Jun 28, 2016 at 08:42:01AM -0700, Bob Paauwe wrote: > When fbdev emulation is disabled it is not a good idea to call into > the core fb_set_suspend() function as this will cause suspend and > resume to fail. Also ifbdev->fb is null so the defeference farther > down will oops. Nothing in

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

On 28/06/16 15:54, Dave Gordon wrote: On 21/06/16 19:11, Peter Antoine wrote: From: Alex Dai 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

[Intel-gfx] [PATCH] drm/i915: Skip fbdev core suspend/resume when fbdev emulation is disabled.

When fbdev emulation is disabled it is not a good idea to call into the core fb_set_suspend() function as this will cause suspend and resume to fail. Also ifbdev->fb is null so the defeference farther down will oops. Nothing in that path is needed in this case so bail early when ifbdev->fb is

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use atomic waits for short non-atomic ones

On Tue, Jun 28, 2016 at 03:40:24PM +0100, Tvrtko Ursulin wrote: > > On 28/06/16 15:14, Chris Wilson wrote: > >On Tue, Jun 28, 2016 at 02:55:28PM +0100, Chris Wilson wrote: > >>On Tue, Jun 28, 2016 at 02:29:33PM +0100, Tvrtko Ursulin wrote: > >>>How would you implement it with cpu_clock? What

Re: [Intel-gfx] [PATCH 1/2] drm/i915/debug: Select PREEMPT_COUNT when enabling debugging

Hi, [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on v4.7-rc5 next-20160628] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Tvrtko-Ursulin/drm-i915-debug-Select

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

On 21/06/16 19:11, Peter Antoine wrote: This patch adds the HuC Loading for the BXT. Version 1.x of the HuC firmware. Signed-off-by: Peter Antoine --- drivers/gpu/drm/i915/i915_gem.c | 13 +++-- drivers/gpu/drm/i915/intel_guc_loader.c | 29

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

On 21/06/16 19:11, Peter Antoine wrote: The HuC authentication is done by host2guc call. The HuC RSA keys are sent to GuC for authentication. Signed-off-by: Alex Dai Signed-off-by: Peter Antoine --- drivers/gpu/drm/i915/i915_guc_submission.c | 65

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/guc: Do not use wait_for_atomic in host2guc_action

== Series Details == Series: drm/i915/guc: Do not use wait_for_atomic in host2guc_action URL : https://patchwork.freedesktop.org/series/9233/ State : failure == Summary == Series 9233v1 drm/i915/guc: Do not use wait_for_atomic in host2guc_action

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

On 21/06/16 19:11, Peter Antoine wrote: From: Alex Dai Add debugfs entry for HuC loading status check. Signed-off-by: Alex Dai Signed-off-by: Peter Antoine --- drivers/gpu/drm/i915/i915_debugfs.c | 32

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

On 21/06/16 19:11, Peter Antoine wrote: From: Alex Dai 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. Signed-off-by: Alex

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Use atomic commits for legacy page_flips"

Op 28-06-16 om 10:35 schreef Chris Wilson: > On Tue, Jun 28, 2016 at 09:56:47AM +0200, Maarten Lankhorst wrote: >> Op 24-06-16 om 14:44 schreef Chris Wilson: >>> This reverts commit ee042aa40b66d18d465206845b0752c6a617ba3f. >>> >>> Something appears to be off in the timing, but as far as I can

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use atomic waits for short non-atomic ones

On 28/06/16 14:53, Imre Deak wrote: On ti, 2016-06-28 at 14:29 +0100, Tvrtko Ursulin wrote: On 28/06/16 13:19, Imre Deak wrote: On ti, 2016-06-28 at 12:51 +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin usleep_range is not recommended for waits shorten than

[Intel-gfx] [PATCH] drm/i915/guc: Do not use wait_for_atomic in host2guc_action

From: Tvrtko Ursulin host2guc_action does not appear to be called from atomic context so a more polite wait_for macro should be used. Especially since the timeout is 10ms. Signed-off-by: Tvrtko Ursulin Reported-by: Imre Deak

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use atomic waits for short non-atomic ones

On 28/06/16 15:14, Chris Wilson wrote: On Tue, Jun 28, 2016 at 02:55:28PM +0100, Chris Wilson wrote: On Tue, Jun 28, 2016 at 02:29:33PM +0100, Tvrtko Ursulin wrote: How would you implement it with cpu_clock? What would you do when re-scheduled? unsigned long base; int cpu; int ret;

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

On 21/06/16 19:11, Peter Antoine wrote: From: Alex Dai 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

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

On 21/06/16 19:11, Peter Antoine wrote: Rename some of the GuC fw loading code to make them more general. We will utilize 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, such

[Intel-gfx] ✗ Ro.CI.BAT: warning for Introdcue client-managed fence register

== Series Details == Series: Introdcue client-managed fence register URL : https://patchwork.freedesktop.org/series/9229/ State : warning == Summary == Series 9229v1 Introdcue client-managed fence register http://patchwork.freedesktop.org/api/1.0/series/9229/revisions/1/mbox Test

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use atomic waits for short non-atomic ones

On Tue, Jun 28, 2016 at 02:55:28PM +0100, Chris Wilson wrote: > On Tue, Jun 28, 2016 at 02:29:33PM +0100, Tvrtko Ursulin wrote: > > How would you implement it with cpu_clock? What would you do when > > re-scheduled? > > unsigned long base; > int cpu; > int ret; > > preempt_disable(); > cpu =

Re: [Intel-gfx] [PATCH 0/4] Introdcue client-managed fence register

On Tue, Jun 28, 2016 at 09:51:41AM -0400, Zhi Wang wrote: > The client-managed fence register will be supported in Chris' i915 mark II > revamp patch series. This patchset is based on previous ideas from Joonas > and Chris. Better we can start to discuss them and have a fallback solution > in case

Re: [Intel-gfx] [PATCH 0/4] Introdcue client-managed fence register

Ha, Sure, glad to do that. Have you sent them out? :P I'm worrying about the schedule and I sent these patches for discussion as plan B > -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Tuesday, June 28, 2016 4:58 PM > To: Wang, Zhi A

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use atomic waits for short non-atomic ones

On Tue, Jun 28, 2016 at 02:29:33PM +0100, Tvrtko Ursulin wrote: > How would you implement it with cpu_clock? What would you do when > re-scheduled? unsigned long base; int cpu; int ret; preempt_disable(); cpu = smp_processor_id(); base = local_clock() >> 10; for (;;) { u64 now =

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Use atomic commits for legacy page_flips"

Hi Chris, On 24 June 2016 at 22:44, Chris Wilson wrote: > This reverts commit ee042aa40b66d18d465206845b0752c6a617ba3f. > > Something appears to be off in the timing, but as far as I can tell it > is not along the event delivery path. The net effect appears to be >

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use atomic waits for short non-atomic ones

On ti, 2016-06-28 at 14:29 +0100, Tvrtko Ursulin wrote: > On 28/06/16 13:19, Imre Deak wrote: > > On ti, 2016-06-28 at 12:51 +0100, Tvrtko Ursulin wrote: > > > From: Tvrtko Ursulin > > > > > > usleep_range is not recommended for waits shorten than 10us. > > > > > >

[Intel-gfx] [PATCH 2/4] drm/i915: Directly steal fence register in i915_find_fence_reg()

A client like GVT-g will request fence register from host when creating vGPUs. According to Chris's comments, we'd better not expose the fence stealing function as a dedicated API as the caller may not know if the fence register could be stealed without touching the inner pin_count. This patch

[Intel-gfx] [PATCH 4/4] drm/i915: Expose a API for other client to request a fence register

This patch renames the i915_find_fence_reg() to i915_request_fence_reg(), and expose it in kernel. Cc: Joonas Lahtinen Cc: Tvrtko Ursulin Cc: Chris Wilson Signed-off-by: Zhi Wang

[Intel-gfx] [PATCH 1/4] drm/i915: Introduce for_each_fence_reg()

Introduce a macro for iterating all fence registers. Cc: Joonas Lahtinen Cc: Tvrtko Ursulin Cc: Chris Wilson Signed-off-by: Zhi Wang --- drivers/gpu/drm/i915/i915_drv.h | 4

[Intel-gfx] [PATCH 3/4] drm/i915: Introduce client-managed fence register.

This patche enables a client to request fence register from i915 and manage it by itself. A client should: - Set the client_managed flag and clear the HW fence register after acquiring a fence reg from i915 - Clear the HW fence register and return it to i915 by clearing client_managed flag -

[Intel-gfx] [PATCH 0/4] Introdcue client-managed fence register

The client-managed fence register will be supported in Chris' i915 mark II revamp patch series. This patchset is based on previous ideas from Joonas and Chris. Better we can start to discuss them and have a fallback solution in case the schedule bites us before Chris' work. Zhi Wang (4):

Re: [Intel-gfx] [PATCH 04/11] drm/i915: Support for GuC interrupts

On 28/06/16 12:12, Goel, Akash wrote: On 6/28/2016 3:33 PM, Tvrtko Ursulin wrote: On 27/06/16 13:16, akash.g...@intel.com wrote: From: Sagar Arun Kamble There are certain types of interrupts which Host can recieve from GuC. GuC ukernel sends an interrupt to Host

Re: [Intel-gfx] [PATCH 1/2] drm/i915/debug: Select PREEMPT_COUNT when enabling debugging

On Tue, Jun 28, 2016 at 12:51:49PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Required to enable correct wait_for_atomic checks. > > Signed-off-by: Tvrtko Ursulin > Cc: Chris Wilson Reviewed-by: Chris

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use atomic waits for short non-atomic ones

On 28/06/16 13:19, Imre Deak wrote: On ti, 2016-06-28 at 12:51 +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin usleep_range is not recommended for waits shorten than 10us. Make the wait_for_us use the atomic variant for such waits. To do so we need to disable

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/2] Revert "drm/i915: Workaround CHV pipe C cursor fail" (rev2)

== Series Details == Series: series starting with [1/2] Revert "drm/i915: Workaround CHV pipe C cursor fail" (rev2) URL : https://patchwork.freedesktop.org/series/8431/ State : failure == Summary == Series 8431v2 Series without cover letter

[Intel-gfx] ✓ Ro.CI.BAT: success for series starting with [1/2] drm/i915/debug: Select PREEMPT_COUNT when enabling debugging

== Series Details == Series: series starting with [1/2] drm/i915/debug: Select PREEMPT_COUNT when enabling debugging URL : https://patchwork.freedesktop.org/series/9226/ State : success == Summary == Series 9226v1 Series without cover letter

Re: [Intel-gfx] [RFC] drm/i915/chv: Clip cursor for CHV pipe C HW Cursor pos < 0

Daniel, On 06/28/2016 05:57 PM, Shobhit Kumar wrote: From: Shobhit Kumar CHV pipe C hits underrun when we get negative crtc_x values of cursor. To avoid this we clip and shift the cursor image by negative crtc_x value. v2: Make a copy of cursor plane state and

[Intel-gfx] [RFC] drm/i915/chv: Clip cursor for CHV pipe C HW Cursor pos < 0

From: Shobhit Kumar CHV pipe C hits underrun when we get negative crtc_x values of cursor. To avoid this we clip and shift the cursor image by negative crtc_x value. v2: Make a copy of cursor plane state and allocate new gem object and fb for clipped cursor and use

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use atomic waits for short non-atomic ones

On Tue, Jun 28, 2016 at 12:51:50PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > usleep_range is not recommended for waits shorten than 10us. > > Make the wait_for_us use the atomic variant for such waits. > > To do so we need to disable the !in_atomic

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use atomic waits for short non-atomic ones

On ti, 2016-06-28 at 12:51 +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > usleep_range is not recommended for waits shorten than 10us. > > Make the wait_for_us use the atomic variant for such waits. > > To do so we need to disable the !in_atomic warning for

Re: [Intel-gfx] [PATCH 00/13] Legacy engine initialization refactoring

On Mon, Jun 27, 2016 at 03:04:07PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Preparation step towards unifying what can be unified between > legacy and execlist. > > This series tries to simplify the engine initializers by moving some > of the

Re: [Intel-gfx] [PATCH 09/13] drm/i915: Compact Gen8 semaphore initialization

On Mon, Jun 27, 2016 at 03:04:16PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Replace the macro initializer with a programatic loop which > results in smaller code and hopefully just as clear. > > Signed-off-by: Tvrtko Ursulin >

Re: [Intel-gfx] [PATCH 07/13] drm/i915: Consolidate dispatch_execbuffer vfunc

On Mon, Jun 27, 2016 at 03:04:14PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Signed-off-by: Tvrtko Ursulin > --- > drivers/gpu/drm/i915/intel_ringbuffer.c | 25 ++--- > 1 file changed, 6 insertions(+), 19

Re: [Intel-gfx] [PATCH 04/13] drm/i915: Consolidate get and put irq vfuncs

On Mon, Jun 27, 2016 at 03:04:11PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Signed-off-by: Tvrtko Ursulin > --- > drivers/gpu/drm/i915/intel_ringbuffer.c | 46 > - > 1 file changed, 17

[Intel-gfx] [PATCH 2/2] drm/i915: Use atomic waits for short non-atomic ones

From: Tvrtko Ursulin usleep_range is not recommended for waits shorten than 10us. Make the wait_for_us use the atomic variant for such waits. To do so we need to disable the !in_atomic warning for such uses and also disable preemption since the macro is written in a

[Intel-gfx] [PATCH 1/2] drm/i915/debug: Select PREEMPT_COUNT when enabling debugging

From: Tvrtko Ursulin Required to enable correct wait_for_atomic checks. Signed-off-by: Tvrtko Ursulin Cc: Chris Wilson --- drivers/gpu/drm/i915/Kconfig.debug | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [Intel-gfx] [PATCH 1/4] drm/i915/bxt: Avoid early timeout during PLL enable

On 28/06/16 11:37, Imre Deak wrote: Since wait_for_atomic doesn't re-check the wait-for condition after expiry of the timeout it can fail when called from non-atomic context even if the condition is set correctly before the expiry. Fix this by using the non-atomic wait_for instead. I noticed

Re: [Intel-gfx] [PATCH 1/4] drm/i915/bxt: Avoid early timeout during PLL enable

On 28/06/16 12:16, Imre Deak wrote: On ti, 2016-06-28 at 12:05 +0100, Tvrtko Ursulin wrote: On 28/06/16 11:48, Chris Wilson wrote: On Tue, Jun 28, 2016 at 01:37:30PM +0300, Imre Deak wrote: Since wait_for_atomic doesn't re-check the wait-for condition after expiry of the timeout it can fail

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Avoid early timeout during AUX transfers

On 28/06/16 11:37, Imre Deak wrote: Since wait_for_atomic doesn't re-check the wait-for condition after expiry of the timeout it can fail when called from non-atomic context even if the condition is set correctly before the expiry. Fix this by using the non-atomic wait_for instead. Due to the

Re: [Intel-gfx] [PATCH 3/4] drm/i915/hsw: Avoid early timeout during LCPLL disable/restore

On 28/06/16 11:37, Imre Deak wrote: Since wait_for_atomic doesn't re-check the wait-for condition after expiry of the timeout it can fail when called from non-atomic context even if the condition is set correctly before the expiry. Fix this by using the non-atomic wait_for instead. Fixes:

Re: [Intel-gfx] [PATCH 1/4] drm/i915/bxt: Avoid early timeout during PLL enable

On ti, 2016-06-28 at 12:05 +0100, Tvrtko Ursulin wrote: > On 28/06/16 11:48, Chris Wilson wrote: > > On Tue, Jun 28, 2016 at 01:37:30PM +0300, Imre Deak wrote: > > > Since wait_for_atomic doesn't re-check the wait-for condition after > > > expiry of the timeout it can fail when called from

Re: [Intel-gfx] [PATCH 04/11] drm/i915: Support for GuC interrupts

On 6/28/2016 3:33 PM, Tvrtko Ursulin wrote: On 27/06/16 13:16, akash.g...@intel.com wrote: From: Sagar Arun Kamble There are certain types of interrupts which Host can recieve from GuC. GuC ukernel sends an interrupt to Host for certain events, like for example

Re: [Intel-gfx] [PATCH 2/4] drm/i915/lpt: Avoid early timeout during FDI PHY reset

On 28/06/16 11:37, Imre Deak wrote: Since wait_for_atomic doesn't re-check the wait-for condition after expiry of the timeout it can fail when called from non-atomic context even if the condition is set correctly before the expiry. Fix this by using the non-atomic wait_for instead. Fixes:

Re: [Intel-gfx] [PATCH 1/4] drm/i915/bxt: Avoid early timeout during PLL enable

On Tue, Jun 28, 2016 at 12:05:42PM +0100, Tvrtko Ursulin wrote: > > On 28/06/16 11:48, Chris Wilson wrote: > >On Tue, Jun 28, 2016 at 01:37:30PM +0300, Imre Deak wrote: > >>Since wait_for_atomic doesn't re-check the wait-for condition after > >>expiry of the timeout it can fail when called from

Re: [Intel-gfx] [PATCH] drm/i915: fix build errors when ACPI is not enabled

On Tue, 28 Jun 2016, Chris Wilson wrote: > On Mon, Jun 27, 2016 at 02:53:19PM +0300, Jani Nikula wrote: >> From: Randy Dunlap >> >> Fix build errors when ACPI is not enabled by adding function stubs: >> >> ../drivers/gpu/drm/i915/i915_drv.c: In

Re: [Intel-gfx] [PATCH 1/4] drm/i915/bxt: Avoid early timeout during PLL enable

On 28/06/16 11:48, Chris Wilson wrote: On Tue, Jun 28, 2016 at 01:37:30PM +0300, Imre Deak wrote: Since wait_for_atomic doesn't re-check the wait-for condition after expiry of the timeout it can fail when called from non-atomic context even if the condition is set correctly before the expiry.

Re: [Intel-gfx] [PATCH 2/4] drm/i915/lpt: Avoid early timeout during FDI PHY reset

On ti, 2016-06-28 at 11:50 +0100, Chris Wilson wrote: > On Tue, Jun 28, 2016 at 01:37:31PM +0300, Imre Deak wrote: > > Since wait_for_atomic doesn't re-check the wait-for condition after > > expiry of the timeout it can fail when called from non-atomic > > context > > even if the condition is set

[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915: Avoid early timeout due to wait_for_atomic

== Series Details == Series: drm/i915: Avoid early timeout due to wait_for_atomic URL : https://patchwork.freedesktop.org/series/9224/ State : success == Summary == Series 9224v1 drm/i915: Avoid early timeout due to wait_for_atomic

Re: [Intel-gfx] [PATCH 1/4] drm/i915/bxt: Avoid early timeout during PLL enable

On ti, 2016-06-28 at 11:48 +0100, Chris Wilson wrote: > On Tue, Jun 28, 2016 at 01:37:30PM +0300, Imre Deak wrote: > > Since wait_for_atomic doesn't re-check the wait-for condition after > > expiry of the timeout it can fail when called from non-atomic > > context > > even if the condition is set

Re: [Intel-gfx] [PATCH 2/4] drm/i915/lpt: Avoid early timeout during FDI PHY reset

On Tue, Jun 28, 2016 at 01:37:31PM +0300, Imre Deak wrote: > Since wait_for_atomic doesn't re-check the wait-for condition after > expiry of the timeout it can fail when called from non-atomic context > even if the condition is set correctly before the expiry. Fix this by > using the non-atomic

Re: [Intel-gfx] [PATCH 1/4] drm/i915/bxt: Avoid early timeout during PLL enable

On Tue, Jun 28, 2016 at 01:37:30PM +0300, Imre Deak wrote: > Since wait_for_atomic doesn't re-check the wait-for condition after > expiry of the timeout it can fail when called from non-atomic context > even if the condition is set correctly before the expiry. Fix this by > using the non-atomic

Re: [Intel-gfx] [RFC 8/8] drm/i915/vlv: Add intermediate field in intel_crtc_wm_state and handlers for two-level watermark

Op 23-06-16 om 14:36 schreef Chi Ding: > From: Maarten Lankhorst > > Rename vlv_compute_wm to vlv_compute_pipe_wm to compute optimal watermark > Add vlv_compute_intermediate_wm to computer intermediate watermark > Add vlv_initial_watermarks to write intermediate

Re: [Intel-gfx] [PATCH 10/11] drm/i915: Support to create write combined type vmaps

On Tue, Jun 28, 2016 at 03:55:15PM +0530, Goel, Akash wrote: > >>+ pinned = (obj->pages_pin_count > 1); > > > >Too many () > > Sorry is the above condition not correct ? > If pin count is more than 1 then it implies that pages have been > pinned elsewhere also, so pages were already pinned

[Intel-gfx] [PATCH 3/4] drm/i915/hsw: Avoid early timeout during LCPLL disable/restore

Since wait_for_atomic doesn't re-check the wait-for condition after expiry of the timeout it can fail when called from non-atomic context even if the condition is set correctly before the expiry. Fix this by using the non-atomic wait_for instead. Fixes: 0351b93992aa ("drm/i915: Do not lie about

[Intel-gfx] [PATCH 2/4] drm/i915/lpt: Avoid early timeout during FDI PHY reset

Since wait_for_atomic doesn't re-check the wait-for condition after expiry of the timeout it can fail when called from non-atomic context even if the condition is set correctly before the expiry. Fix this by using the non-atomic wait_for instead. Fixes: 0351b93992aa ("drm/i915: Do not lie about

[Intel-gfx] [PATCH 4/4] drm/i915: Avoid early timeout during AUX transfers

Since wait_for_atomic doesn't re-check the wait-for condition after expiry of the timeout it can fail when called from non-atomic context even if the condition is set correctly before the expiry. Fix this by using the non-atomic wait_for instead. Due to the relatively long 10ms timeout, probably

[Intel-gfx] [PATCH 1/4] drm/i915/bxt: Avoid early timeout during PLL enable

Since wait_for_atomic doesn't re-check the wait-for condition after expiry of the timeout it can fail when called from non-atomic context even if the condition is set correctly before the expiry. Fix this by using the non-atomic wait_for instead. I noticed this via the PLL locking timing out

[Intel-gfx] [PATCH 0/4] drm/i915: Avoid early timeout due to wait_for_atomic

If called from non-atomic context wait_for_atomic{,_us} can fail even though the given condition becomes true before the timeout passes. I noticed this via sporadic timeouts during PLL locking on BXT (fixed by patch 1). The WARN in wait_for_atomic would be also triggered, alas I didn't have extra

Re: [Intel-gfx] [PATCH 10/11] drm/i915: Support to create write combined type vmaps

On 6/28/2016 3:22 PM, Chris Wilson wrote: On Mon, Jun 27, 2016 at 05:46:57PM +0530, akash.g...@intel.com wrote: From: Chris Wilson diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 20c701c..3ef1ee5 100644 ---

Re: [Intel-gfx] [PATCH 04/11] drm/i915: Support for GuC interrupts

On 27/06/16 13:16, akash.g...@intel.com wrote: From: Sagar Arun Kamble There are certain types of interrupts which Host can recieve from GuC. GuC ukernel sends an interrupt to Host for certain events, like for example retrieve/consume the logs generated by ukernel.

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Add WaDisableGatherAtSetShaderCommonSlice

Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/11] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

On 6/28/2016 3:17 PM, Chris Wilson wrote: On Mon, Jun 27, 2016 at 05:46:53PM +0530, akash.g...@intel.com wrote: +static void guc_remove_log_relay_file(struct intel_guc *guc) +{ + relay_close(guc->log_relay_chan); +} + +static void guc_create_log_relay_file(struct intel_guc *guc) +{ +

Re: [Intel-gfx] [PATCH 10/11] drm/i915: Support to create write combined type vmaps

On Mon, Jun 27, 2016 at 05:46:57PM +0530, akash.g...@intel.com wrote: > From: Chris Wilson > > vmaps has a provision for controlling the page protection bits, with which > we can use to control the mapping type, e.g. WB, WC, UC or even WT. > To allow the caller to

  1   2   >