Re: [Intel-gfx] [PATCH v2] drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters.

On ti, 2017-02-14 at 20:17 -0800, Kenneth Graunke wrote: > This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0 > (indicating the optional feature is not supported), and makes execbuf > always return -EINVAL if the flags are used. > > Apparently, no userspace ever shipped which

[Intel-gfx] [GIT PULL] more GVT-g fixes for 4.11

Hi, This contains recent gvt fixes that target for 4.11. Team is busy on know issues fixing and improve usability. This includes IOMMU workaround fix with proper dma mapping from Chuanxiao, some log message cleanup, one kernel oops fix in error path of workload submission from Changbin, and with

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters. (rev2)

== Series Details == Series: drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters. (rev2) URL : https://patchwork.freedesktop.org/series/19676/ State : success == Summary == Series 19676v2 drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters.

[Intel-gfx] [PATCH v2] drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters.

This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0 (indicating the optional feature is not supported), and makes execbuf always return -EINVAL if the flags are used. Apparently, no userspace ever shipped which used this optional feature: I checked the git history of Mesa,

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters.

== Series Details == Series: drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters. URL : https://patchwork.freedesktop.org/series/19676/ State : failure == Summary == CC [M] drivers/gpu/drm/i915/gvt/trace_points.o CC [M] drivers/gpu/drm/i915/gvt/vgpu.o CC [M]

[Intel-gfx] [PATCH] drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters.

This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0 (indicating the optional feature is not supported), and makes execbuf always return -EINVAL if the flags are used. Apparently, no userspace ever shipped which used this optional feature: I checked the git history of Mesa,

[Intel-gfx] [drm-intel:drm-intel-next-queued 11/59] drivers/gpu/drm/i915/selftests/i915_mock_selftests.h:11: warning: missing braces around initializer

tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: d892e9398ecf6defc7972a62227b77dad6be20bd commit: 953c7f82eb890085c60dbe22578e883d6837c674 [11/59] drm/i915: Provide a hook for selftests config: x86_64-randconfig-s1-02150712 (attached as .config) compiler: gcc-4.4

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Add DPCD definitions for DP 1.4 DSC feature

== Series Details == Series: drm: Add DPCD definitions for DP 1.4 DSC feature URL : https://patchwork.freedesktop.org/series/19666/ State : success == Summary == Series 19666v1 drm: Add DPCD definitions for DP 1.4 DSC feature

[Intel-gfx] [PATCH] drm: Add DPCD definitions for DP 1.4 DSC feature

Display stream compression is supported on DP 1.4 DP devices. This patch adds the corersponding DPCD register definitions for DSC. Signed-off-by: Manasi Navare Cc: Jani Nikula Cc: Paulo Zanoni ---

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Enable fine-tuned RPS for cherryview

On Fri, Feb 10, 2017 at 10:52:02PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [1/3] drm/i915: Enable fine-tuned RPS for > cherryview > URL : https://patchwork.freedesktop.org/series/19461/ > State : success > > == Summary == > > Series 19461v1 Series

Re: [Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

On Tue, 2017-02-14 at 20:51 +0100, Daniel Vetter wrote: > On Mon, Feb 13, 2017 at 10:26 PM, Pandiyan, Dhinakaran > wrote: > > On Mon, 2017-02-13 at 09:05 +, Lankhorst, Maarten wrote: > >> Pandiyan, Dhinakaran schreef op do 09-02-2017 om 18:55 [+]: > >> > On

Re: [Intel-gfx] [PATCH] drm: Reduce EDID warnings from DRM_ERROR to DRM_NOTE

On Tue, Feb 14, 2017 at 09:43:45PM +, Chris Wilson wrote: > On Tue, Feb 14, 2017 at 10:36:09PM +0100, Daniel Vetter wrote: > > On Mon, Feb 13, 2017 at 12:17:27PM -0500, Sean Paul wrote: > > > On Mon, Feb 13, 2017 at 3:59 AM, Chris Wilson > > > wrote: > > > > On Mon,

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: The return of i915_gpu_info to debugfs (rev3)

== Series Details == Series: drm/i915: The return of i915_gpu_info to debugfs (rev3) URL : https://patchwork.freedesktop.org/series/18833/ State : warning == Summary == Series 18833v3 drm/i915: The return of i915_gpu_info to debugfs

Re: [Intel-gfx] [PATCH 1/5] drm/i915/uc: Rename intel_?uc_{setup, load}() to _init_hw()

On Tue, Feb 14, 2017 at 05:15:37PM +0100, Arkadiusz Hiler wrote: > GuC historically has two "startup" functions called _init() and _setup() > > Then HuC came with it's _init() and _load(). > > To make naming more consistent this commit renames intel_guc_setup() and > intel_huc_load() to

Re: [Intel-gfx] [PATCH] drm: Reduce EDID warnings from DRM_ERROR to DRM_NOTE

On Tue, Feb 14, 2017 at 10:36:09PM +0100, Daniel Vetter wrote: > On Mon, Feb 13, 2017 at 12:17:27PM -0500, Sean Paul wrote: > > On Mon, Feb 13, 2017 at 3:59 AM, Chris Wilson > > wrote: > > > On Mon, Feb 13, 2017 at 08:41:10AM +0100, Thierry Reding wrote: > > >> On Fri,

Re: [Intel-gfx] [PATCH RESEND] drm/dp/mst: fix kernel oops when turning off secondary monitor

On Tue, Feb 14, 2017 at 02:49:21PM +0200, Jani Nikula wrote: > From: Pierre-Louis Bossart > > 100% reproducible issue found on SKL SkullCanyon NUC with two external > DP daisy-chained monitors in DP/MST mode. When turning off or changing > the input of the

Re: [Intel-gfx] [PATCH] drm: Reduce EDID warnings from DRM_ERROR to DRM_NOTE

On Mon, Feb 13, 2017 at 12:17:27PM -0500, Sean Paul wrote: > On Mon, Feb 13, 2017 at 3:59 AM, Chris Wilson > wrote: > > On Mon, Feb 13, 2017 at 08:41:10AM +0100, Thierry Reding wrote: > >> On Fri, Feb 10, 2017 at 07:59:13PM +, Chris Wilson wrote: > >> > The warnings

Re: [Intel-gfx] [PATCH v3] drm/i915/chv: Set min freq to RPn on CHV.

On Fri, Aug 12, 2016 at 06:46:41PM +0530, deepa...@linux.intel.com wrote: > From: Deepak S > > With latest Punit FW, vgg input voltag drop falling to minimum is fixed. > So reverting the WA patch & moving to turbo freq opreation range to [RPn -> > RP0] > > This is not

[Intel-gfx] ✓ Fi.CI.BAT: success for GuC Scrub vol. 1 (rev2)

== Series Details == Series: GuC Scrub vol. 1 (rev2) URL : https://patchwork.freedesktop.org/series/16856/ State : success == Summary == Series 16856v2 GuC Scrub vol. 1 https://patchwork.freedesktop.org/api/1.0/series/16856/revisions/2/mbox/ fi-bdw-5557u total:252 pass:241 dwarn:0

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915: Dump more configuration information for DSI

On Wed, Dec 21, 2016 at 04:31:14PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Dump out more of the DSI configuration details during init. > This includes pclk, burst_mode_ratio, lane_count, pixel_overlap, > video_mode_format and

Re: [Intel-gfx] [PATCH v2] drm/i915: fix for WaDisableDopClockGating:bdw

On Mon, Feb 13, 2017 at 02:54:01PM +, Robert Bragg wrote: > On Mon, Feb 13, 2017 at 2:28 PM, Ville Syrjälä > wrote: > > On Sun, Feb 12, 2017 at 01:32:52PM +, Robert Bragg wrote: > >> This workaround for BDW was incomplete as it also requires EUTC clock > >>

Re: [Intel-gfx] [PATCH 5/5] drm/i915/uc: Simplify fw_path

On Tue, Feb 14, 2017 at 05:15:41PM +0100, Arkadiusz Hiler wrote: > Currently fw_path values can represent one of three possible states: > > 1) NULL - device without the uC > 2) '\0' - device with the uC but have no firmware > 3) else - device with the uC and we have firmware > > Second case

Re: [Intel-gfx] [PATCH 4/5] drm/i915/guc: Simplify intel_guc_init_hw()

On Tue, Feb 14, 2017 at 05:15:40PM +0100, Arkadiusz Hiler wrote: > Current version of intel_guc_init_hw() does a lot: > - cares about submission > - loads huc > - implement WA > > This change offloads some of the logic to intel_uc_load(), which now > cares about the above. > > Cc: Anusha

Re: [Intel-gfx] [PATCH v3 3/7] drm/atomic: Use new atomic iterator macros.

Hi Daniel, On Tuesday 14 Feb 2017 21:03:07 Daniel Vetter wrote: > On Tue, Jan 17, 2017 at 01:55:50AM +0200, Laurent Pinchart wrote: > > On Monday 16 Jan 2017 10:37:40 Maarten Lankhorst wrote: > > > > Could we please get a description ? Apart from that, > > Typed something small and merged the

Re: [Intel-gfx] [PATCH v3 3/7] drm/atomic: Use new atomic iterator macros.

On Tue, Jan 17, 2017 at 01:55:50AM +0200, Laurent Pinchart wrote: > Hi Maarten, > > Thank you for the patch. > > On Monday 16 Jan 2017 10:37:40 Maarten Lankhorst wrote: > > Could we please get a description ? Apart from that, Typed something small and merged the first 3 patches from this

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Remove duplicate intel_logical_ring_workarounds_emit

HI, > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Patchwork > Sent: Tuesday, February 14, 2017 8:52 PM > To: Tvrtko Ursulin > Cc: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] ✗ Fi.CI.BAT: failure for

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix not finding the VBT when it overlaps with OPREGION_ASLE_EXT

== Series Details == Series: drm/i915: Fix not finding the VBT when it overlaps with OPREGION_ASLE_EXT URL : https://patchwork.freedesktop.org/series/19645/ State : success == Summary == Series 19645v1 drm/i915: Fix not finding the VBT when it overlaps with OPREGION_ASLE_EXT

Re: [Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

On Mon, Feb 13, 2017 at 10:26 PM, Pandiyan, Dhinakaran wrote: > On Mon, 2017-02-13 at 09:05 +, Lankhorst, Maarten wrote: >> Pandiyan, Dhinakaran schreef op do 09-02-2017 om 18:55 [+]: >> > On Thu, 2017-02-09 at 09:01 +, Lankhorst, Maarten wrote: >> > >

Re: [Intel-gfx] [PATCH 3/5] drm/i915/guc: Extract param logic form guc_init

On Tue, Feb 14, 2017 at 05:15:39PM +0100, Arkadiusz Hiler wrote: > Let intel_guc_init() focus on determining and fetching the correct > firmware. > > This patch introduces intel_sanitize_uc_params() that is called from > intel_uc_init(). > > Then, if we have GuC, we can call intel_guc_init()

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix uninitialized return from mi_set_context

On 14/02/2017 19:22, Patchwork wrote: == Series Details == Series: drm/i915: Fix uninitialized return from mi_set_context URL : https://patchwork.freedesktop.org/series/19642/ State : success == Summary == Series 19642v1 drm/i915: Fix uninitialized return from mi_set_context

Re: [Intel-gfx] [PATCH] drm/i915/dp: Reset the link params on HPD/connected boot/resume

On Tue, Feb 14, 2017 at 09:08:25PM +0200, Ville Syrjälä wrote: > On Tue, Feb 07, 2017 at 04:54:11PM -0800, Manasi Navare wrote: > > The max link parameters should be set/reset only on HPD or > > connected boot case or on system resume. > > > > Add a flag reset_link_params to intel_dp to decide

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix uninitialized return from mi_set_context

== Series Details == Series: drm/i915: Fix uninitialized return from mi_set_context URL : https://patchwork.freedesktop.org/series/19642/ State : success == Summary == Series 19642v1 drm/i915: Fix uninitialized return from mi_set_context

Re: [Intel-gfx] [PATCH 1/5] drm/i915/uc: Rename intel_?uc_{setup, load}() to _init_hw()

On Tue, Feb 14, 2017 at 05:15:37PM +0100, Arkadiusz Hiler wrote: > GuC historically has two "startup" functions called _init() and _setup() > > Then HuC came with it's _init() and _load(). > > To make naming more consistent this commit renames intel_guc_setup() and > intel_huc_load() to

Re: [Intel-gfx] [PATCH] drm/i915/dp: Reset the link params on HPD/connected boot/resume

On Tue, Feb 07, 2017 at 04:54:11PM -0800, Manasi Navare wrote: > The max link parameters should be set/reset only on HPD or > connected boot case or on system resume. > > Add a flag reset_link_params to intel_dp to decide when > to reset the max link parameters. This prevents the parameters >

Re: [Intel-gfx] [PATCH] drm/i915: Fix DisplayPort Hotplug

On Tue, Feb 14, 2017 at 10:48:10AM -0800, Palmer Dabbelt wrote: > On Tue, 14 Feb 2017 07:01:54 PST (-0800), ville.syrj...@linux.intel.com wrote: > > On Fri, Feb 10, 2017 at 02:44:20PM -0800, Palmer Dabbelt wrote: > >> DisplayPort no longer hotplugs on my machine (a 2014 MacBook Pro > >> attached

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Remove duplicate intel_logical_ring_workarounds_emit

== Series Details == Series: drm/i915: Remove duplicate intel_logical_ring_workarounds_emit URL : https://patchwork.freedesktop.org/series/19640/ State : failure == Summary == Series 19640v1 drm/i915: Remove duplicate intel_logical_ring_workarounds_emit

Re: [Intel-gfx] [PATCH] drm/i915: Fix DisplayPort Hotplug

On Tue, 14 Feb 2017 07:01:54 PST (-0800), ville.syrj...@linux.intel.com wrote: > On Fri, Feb 10, 2017 at 02:44:20PM -0800, Palmer Dabbelt wrote: >> DisplayPort no longer hotplugs on my machine (a 2014 MacBook Pro >> attached to an ASUS PB287Q). I believe the problem is that long pulses >> are no

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Silence compiler warning for seltests/i915_gem_coherency

== Series Details == Series: drm/i915: Silence compiler warning for seltests/i915_gem_coherency URL : https://patchwork.freedesktop.org/series/19639/ State : success == Summary == Series 19639v1 drm/i915: Silence compiler warning for seltests/i915_gem_coherency

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Sanitize GuC client initialization (rev2)

== Series Details == Series: drm/i915: Sanitize GuC client initialization (rev2) URL : https://patchwork.freedesktop.org/series/19452/ State : success == Summary == Series 19452v2 drm/i915: Sanitize GuC client initialization

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Don't take struct_mutex for object unreference (rev2)

== Series Details == Series: drm/i915/guc: Don't take struct_mutex for object unreference (rev2) URL : https://patchwork.freedesktop.org/series/15071/ State : success == Summary == Series 15071v2 drm/i915/guc: Don't take struct_mutex for object unreference

[Intel-gfx] [CI] drm/i915: The return of i915_gpu_info to debugfs

Once upon a time before we had automated GPU state capture upon hangs, we had intel_gpu_dump. Now we come almost full circle and reinstate that view of the current GPU queues and registers by using the error capture facility to snapshot the GPU state when debugfs/.../i915_gpu_info is opened -

Re: [Intel-gfx] [PATCH] drm/i915: Silence compiler warning for seltests/i915_gem_coherency

On 14 February 2017 at 14:35, Chris Wilson wrote: > In general, the compiler should not be able to detect if we do any > passes through the test loops: > > In file included from drivers/gpu/drm/i915/i915_gem.c:5029: >

Re: [Intel-gfx] [PATCH] drm/i915: Avoid overflow in computing pot_hole loop termination

On 14 February 2017 at 09:23, Chris Wilson wrote: > When using the mock_ppgtt selftest, the GTT is large enough to cause an > overflow in pot_hole() when adding 2 pages to the address. Avoid the > overflow by computing the final valid address and iterating up to that >

[Intel-gfx] ✗ Fi.CI.BAT: failure for GLK MIPI DSI VIDEO MODE PATCHES (rev5)

== Series Details == Series: GLK MIPI DSI VIDEO MODE PATCHES (rev5) URL : https://patchwork.freedesktop.org/series/16542/ State : failure == Summary == CC [M] drivers/gpu/drm/i915/gvt/trace_points.o CC [M] drivers/gpu/drm/i915/gvt/vgpu.o CC [M] drivers/gpu/drm/i915/gvt/interrupt.o

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp/mst: fix kernel oops when turning off secondary monitor (rev3)

== Series Details == Series: drm/dp/mst: fix kernel oops when turning off secondary monitor (rev3) URL : https://patchwork.freedesktop.org/series/16337/ State : success == Summary == Series 16337v3 drm/dp/mst: fix kernel oops when turning off secondary monitor

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Only apply the jump to the "efficient RPS" frequency on startup

On Fri, 2017-02-10 at 15:03 +, Chris Wilson wrote: > Currently we apply the jump to rpe if we are below it and the GPU needs > more power. For some GPUs, the rpe is 75% of the maximum range causing > us to dramatically overshoot low power applications *and* unable to > reach the low frequency

Re: [Intel-gfx] [PATCH v3 21/23] drm/i915: Only preallocate the aliasing GTT to the extents of the global GTT

Chris Wilson writes: > As the aliasing GTT is only accessed via the global GTT, we will never > use more of it than we expose via the Global GTT and so we only need to > preallocate sufficient space within the ppgtt for the full GTT. Equally, > if the aliasing GTT is

[Intel-gfx] [PATCH 5/5] drm/i915/uc: Simplify fw_path

Currently fw_path values can represent one of three possible states: 1) NULL - device without the uC 2) '\0' - device with the uC but have no firmware 3) else - device with the uC and we have firmware Second case is used only to WARN at a later stage. We can WARN right away and merge cases 1

[Intel-gfx] [PATCH 4/5] drm/i915/guc: Simplify intel_guc_init_hw()

Current version of intel_guc_init_hw() does a lot: - cares about submission - loads huc - implement WA This change offloads some of the logic to intel_uc_load(), which now cares about the above. Cc: Anusha Srivatsa Cc: Michal Winiarski

[Intel-gfx] [PATCH 2/5] drm/i915/uc: Introduce intel_uc_init()

We will be able to bulk call all firmware _init() function from single point and offset some general logic there as needed Cc: Anusha Srivatsa Cc: Michal Winiarski Cc: Michal Wajdeczko Signed-off-by: Arkadiusz

[Intel-gfx] [PATCH 3/5] drm/i915/guc: Extract param logic form guc_init

Let intel_guc_init() focus on determining and fetching the correct firmware. This patch introduces intel_sanitize_uc_params() that is called from intel_uc_init(). Then, if we have GuC, we can call intel_guc_init() conditionally and we do not have to do internal checks. Cc: Michal Winiarski

[Intel-gfx] [PATCH v2 0/5] GuC Scrub vol. 1

After having HuC merged and taking feedback into account, it's time to respin this series. General GuC/HuC cleanup simplifying logic, and moving chunks around, as the area is pretty rusty. A lot of logic were extracted from intel_guc_load() to other functions - it not only did handle the actual

[Intel-gfx] [PATCH 1/5] drm/i915/uc: Rename intel_?uc_{setup, load}() to _init_hw()

GuC historically has two "startup" functions called _init() and _setup() Then HuC came with it's _init() and _load(). To make naming more consistent this commit renames intel_guc_setup() and intel_huc_load() to *uc_init_hw() as it it seams more fitting - they are called from the

Re: [Intel-gfx] [PATCH v3 09/23] drm/i915: Always preallocate gen6/7 ppgtt

Chris Wilson writes: > The hardware does not cope very well with us changing the PD within an > active context (the context must be idle for it to re-read the PD). As > we only check whether the page is idle before changing the entry (and on > through the PD tree), we

[Intel-gfx] [PATCH v3] drm/i915: Fix not finding the VBT when it overlaps with OPREGION_ASLE_EXT

From: Hans de Goede If there is no OPREGION_ASLE_EXT then a VBT stored in mailbox #4 may use the ASLE_EXT parts of the opregion. Adjust the vbt_size calculation for a vbt in mailbox #4 for this. This fixes the driver not finding the VBT on a jumper ezpad mini3 cherrytrail

Re: [Intel-gfx] [PATCH v3 03/23] drm/i915: Micro-optimise gen8_ppgtt_insert_entries()

Chris Wilson writes: > Improve the sg iteration and in hte process eliminate a bug in > miscomputing the pml4 length as orig_nents< full length of the sg table. > > v2: Check for the end of the fourth level page table (the final pdpe) > and move onto the next. > >

Re: [Intel-gfx] [PATCH v2 21/22] drm/i915: Only preallocate the aliasing GTT to the extents of the global GTT

On 10 February 2017 at 19:38, Chris Wilson wrote: > As the aliasing GTT is only accessed via the global GTT, we will never > use more of it than we expose via the Global GTT and so we only need to > preallocate sufficient space within the ppgtt for the full GTT. Equally,

[Intel-gfx] ✓ Fi.CI.BAT: success for dma-buf/fence: Avoid use of uninitialised timestamp

== Series Details == Series: dma-buf/fence: Avoid use of uninitialised timestamp URL : https://patchwork.freedesktop.org/series/19626/ State : success == Summary == Series 19626v1 dma-buf/fence: Avoid use of uninitialised timestamp

Re: [Intel-gfx] [PATCH] drm/i915: Fix uninitialized return from mi_set_context

On Tue, Feb 14, 2017 at 03:29:01PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > For some reason my compiler (and CI as well) failed to spot the > uninitialized ret in mi_set_context. > > Signed-off-by: Tvrtko Ursulin > Fixes:

Re: [Intel-gfx] [PATCH] drm/i915: The return of i915_gpu_info to debugfs

On Tue, Feb 14, 2017 at 05:00:35PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > -static int i915_error_state_release(struct inode *inode, struct file *file) > > +static int i915_gpu_info_open(struct inode *inode, struct file *file) > > { > > - struct

Re: [Intel-gfx] [PATCH] drm/i915: Remove duplicate intel_logical_ring_workarounds_emit

On Tue, Feb 14, 2017 at 05:08:27PM +0200, Mika Kuoppala wrote: > Tvrtko Ursulin writes: > > > From: Tvrtko Ursulin > > > > intel_ring_workarounds_emit is exactly the same code. > > > > Signed-off-by: Tvrtko Ursulin > >

[Intel-gfx] [PATCH] drm/i915: Fix uninitialized return from mi_set_context

From: Tvrtko Ursulin For some reason my compiler (and CI as well) failed to spot the uninitialized ret in mi_set_context. Signed-off-by: Tvrtko Ursulin Fixes: 73dec95e6ba3 ("drm/i915: Emit to ringbuffer directly") Cc: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Enable fine-tuned RPS for cherryview

On Fri, 2017-02-10 at 15:03 +, Chris Wilson wrote: > When the RPS tuning was applied to Baytrail, in commit 8fb55197e64d > ("drm/i915: Agressive downclocking on Baytrail"), concern was given that > it might cause Cherryview excess wakeups of the common power well. > However, the static

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Don't accidentally increase the frequency in handling DOWN rps

On Fri, 2017-02-10 at 15:03 +, Chris Wilson wrote: > If we receive a DOWN_TIMEOUT rps interrupt, we respond by reducing the > GPU clocks significantly. Before we do, double check that the frequency > we pick is actually a decrease. > > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH] drm/i915: Remove duplicate intel_logical_ring_workarounds_emit

Tvrtko Ursulin writes: > From: Tvrtko Ursulin > > intel_ring_workarounds_emit is exactly the same code. > > Signed-off-by: Tvrtko Ursulin This was entertaining. Reviewed-by: Mika Kuoppala >

Re: [Intel-gfx] [PATCH] drm/i915: Fix DisplayPort Hotplug

On Fri, Feb 10, 2017 at 02:44:20PM -0800, Palmer Dabbelt wrote: > DisplayPort no longer hotplugs on my machine (a 2014 MacBook Pro > attached to an ASUS PB287Q). I believe the problem is that long pulses > are no longer triggering intel_dp_check_link_status. That shouldn't itsefl cause problems

Re: [Intel-gfx] [PATCH] drm/i915: The return of i915_gpu_info to debugfs

Chris Wilson writes: > Once upon a time before we had automated GPU state capture upon hangs, > we had intel_gpu_dump. Now we come almost full circle and reinstate that > view of the current GPU queues and registers by using the error capture > facility to snapshot the

[Intel-gfx] [PATCH] drm/i915: Remove duplicate intel_logical_ring_workarounds_emit

From: Tvrtko Ursulin intel_ring_workarounds_emit is exactly the same code. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_lrc.c| 35 + drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] HAX enable guc submission for CI

== Series Details == Series: series starting with [1/2] HAX enable guc submission for CI URL : https://patchwork.freedesktop.org/series/19620/ State : failure == Summary == Series 19620v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/19620/revisions/1/mbox/

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Emit to ringbuffer directly (rev11)

On 14/02/2017 13:52, Patchwork wrote: == Series Details == Series: drm/i915: Emit to ringbuffer directly (rev11) URL : https://patchwork.freedesktop.org/series/12186/ State : success == Summary == Series 12186v11 drm/i915: Emit to ringbuffer directly

[Intel-gfx] [PATCH] drm/i915: Silence compiler warning for seltests/i915_gem_coherency

In general, the compiler should not be able to detect if we do any passes through the test loops: In file included from drivers/gpu/drm/i915/i915_gem.c:5029: drivers/gpu/drm/i915/selftests/i915_gem_coherency.c: In function 'igt_gem_coherency':

Re: [Intel-gfx] [PATCH] dma-buf/fence: Avoid use of uninitialised timestamp

On Tue, Feb 14, 2017 at 12:22:02PM -0200, Gustavo Padovan wrote: > 2017-02-14 Chris Wilson : > > > On Tue, Feb 14, 2017 at 11:40:38AM -0200, Gustavo Padovan wrote: > > > Hi Chris, > > > > > > 2017-02-14 Chris Wilson : > > One thing that occurs

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Silence compiler for GTT selftests

== Series Details == Series: drm/i915: Silence compiler for GTT selftests URL : https://patchwork.freedesktop.org/series/19616/ State : success == Summary == Series 19616v1 drm/i915: Silence compiler for GTT selftests https://patchwork.freedesktop.org/api/1.0/series/19616/revisions/1/mbox/

Re: [Intel-gfx] [PATCH] dma-buf/fence: Avoid use of uninitialised timestamp

2017-02-14 Chris Wilson : > On Tue, Feb 14, 2017 at 11:40:38AM -0200, Gustavo Padovan wrote: > > Hi Chris, > > > > 2017-02-14 Chris Wilson : > > > diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c > > > index

Re: [Intel-gfx] [PATCH] drm/i915/guc: In the submission cleanup, do not bail out if there is no execbuf_client

On ma, 2017-02-13 at 07:55 -0800, Oscar Mateo wrote: > > On 02/10/2017 04:04 AM, Chris Wilson wrote: > > > > On Thu, Feb 09, 2017 at 02:24:25AM -0800, Oscar Mateo wrote: > > > > > > There is other stuff that potentially needs cleaning, even if we didn't > > > get to the point of > > > creating

[Intel-gfx] [drm-intel:drm-intel-next-queued 31/59] drivers/gpu/drm/i915/selftests/i915_gem_coherency.c:274: error: 'err' may be used uninitialized in this function

tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: d892e9398ecf6defc7972a62227b77dad6be20bd commit: 170594502cf591fd0789d7e5239937b1a87af4c6 [31/59] drm/i915: Test coherency of and barriers between cache domains config: x86_64-randconfig-s2-02141638 (attached as

[Intel-gfx] [PATCH i-g-t v2] Add atomic modesetting testlist

This is atomic modesetting acceptance tests added to feat_profile.json. v2: Add all kms test --- tests/feat_profile.json | 5 + 1 file changed, 5 insertions(+) diff --git a/tests/feat_profile.json b/tests/feat_profile.json index 251dfd9..a2685db 100644 --- a/tests/feat_profile.json +++

Re: [Intel-gfx] [PATCH 2/2] drm/i915/scheduler: emulate a scheduler for guc

On ti, 2017-02-14 at 11:44 +, Chris Wilson wrote: > This emulates execlists on top of the GuC in order to defer submission of > requests to the hardware. This deferral allows time for high priority > requests to gazump their way to the head of the queue, however it nerfs > the GuC by

Re: [Intel-gfx] [PATCH] drm/i915/guc: Don't take struct_mutex for object unreference

On ti, 2017-02-14 at 13:34 +, Chris Wilson wrote: > We no longer need to take the struct_mutex for freeing objects, and on > the finalisation paths here the mutex is not been used for serialisation > of the pointer access, so remove the BKL wart. > > Signed-off-by: Chris Wilson

[Intel-gfx] ACPI problem causing non functional backlight control on win10 cherrytrail devices

Hi All, On cherrytrail tablets / laptops the backlight typically is controlled by the lpss pwm module, this is listed as an acpi device with a HID of 80862288. All 3 cherrytrail devices I've access to have the following dsdt code for this: Device (PWM1) { Name (_HID,

Re: [Intel-gfx] [RFC/CI] drm/i915: Sanitize GuC client initialization

On pe, 2017-02-10 at 14:36 +, Chris Wilson wrote: > On Fri, Feb 10, 2017 at 03:30:10PM +0200, Joonas Lahtinen wrote: > > > > +static unsigned long __reserve_cacheline(struct intel_guc* guc) > >  { > > - const uint32_t cacheline_size = cache_line_size(); > > - uint32_t offset; > > +

Re: [Intel-gfx] [PATCH] dma-buf/fence: Avoid use of uninitialised timestamp

On Tue, Feb 14, 2017 at 11:40:38AM -0200, Gustavo Padovan wrote: > Hi Chris, > > 2017-02-14 Chris Wilson : > > diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c > > index c769dc653b34..bfead12390f2 100644 > > --- a/drivers/dma-buf/sync_debug.c > >

[Intel-gfx] [PATCH v2] drm/i915: Sanitize GuC client initialization

Started adding proper teardown to guc_client_alloc, ended up removing quite a few dead ends where errors communicating with the GuC were silently ignored. There also seemed to be quite a few erronous teardown actions performed in case of an error (ordering wrong). v2: - Increase function

Re: [Intel-gfx] [RFC/CI] drm/i915: Sanitize GuC client initialization

On pe, 2017-02-10 at 16:11 +0100, Michal Wajdeczko wrote: > On Fri, Feb 10, 2017 at 03:30:10PM +0200, Joonas Lahtinen wrote: > > > > Started adding proper teardown to guc_client_alloc, ended up removing > > quite a few dead ends where errors communicating with the GuC were > > silently ignored.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Emit to ringbuffer directly (rev11)

== Series Details == Series: drm/i915: Emit to ringbuffer directly (rev11) URL : https://patchwork.freedesktop.org/series/12186/ State : success == Summary == Series 12186v11 drm/i915: Emit to ringbuffer directly https://patchwork.freedesktop.org/api/1.0/series/12186/revisions/11/mbox/

Re: [Intel-gfx] [PATCH] dma-buf/fence: Avoid use of uninitialised timestamp

Hi Chris, 2017-02-14 Chris Wilson : > [ 236.821534] WARNING: kmemcheck: Caught 64-bit read from uninitialized > memory (8802538683d0) > [ 236.828642] > 42001e7f0008 > [ 236.839543] i i i i u u u u i i i i i i

[Intel-gfx] kbl_guc and bxt_guc firmware missing from linux-firmware

Hi, I've noted that kbl_guc_ver9_14.bin and bxt_guc_ver8_7.bin are not in linux-firmware despite being available here: https://01.org/linuxgraphics/downloads/firmware Is there some reason they haven't been pusehd out to linux-firmware, e.g. are they not yet stable or something like that? Any

[Intel-gfx] [PATCH] drm/i915/guc: Don't take struct_mutex for object unreference

We no longer need to take the struct_mutex for freeing objects, and on the finalisation paths here the mutex is not been used for serialisation of the pointer access, so remove the BKL wart. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_guc_loader.c | 14

Re: [Intel-gfx] [RFC/CI] drm/i915: Sanitize GuC client initialization

On pe, 2017-02-10 at 12:03 -0800, Daniele Ceraolo Spurio wrote: > > > > > > > > > + > > >  /* > > >   * Tell the GuC to allocate or deallocate a specific doorbell > > >   */ > > > > > > -static int guc_allocate_doorbell(struct intel_guc *guc, > > > -  struct

Re: [Intel-gfx] [RFC/CI] drm/i915: Sanitize GuC client initialization

On pe, 2017-02-10 at 11:55 -0800, Daniele Ceraolo Spurio wrote: > > On 10/02/17 05:30, Joonas Lahtinen wrote: > > +static bool __test_doorbell(struct i915_guc_client *client) > > +{ > > + return test_bit(client->doorbell_id, client->guc->doorbell_bitmap); > > +} > > bikeshed: this helper is

[Intel-gfx] [GLK MIPI DSI V5 8/8] drm/i915/glk: Validate only DSI PORT A PLL divider

As per BSPEC, GLK supports MIPI DSI 8X clk only on PORT A. Therefore only for PORT A PLL divider value should be validated. Signed-off-by: Madhav Chauhan --- drivers/gpu/drm/i915/intel_dsi_pll.c | 19 +-- 1 file changed, 13 insertions(+), 6 deletions(-)

[Intel-gfx] [GLK MIPI DSI V5 5/8] drm/i915/glk: Add DSI PLL divider range for glk

From: Deepak M PLL divider range for GLK is different than that of BXT, hence adding the GLK range check in this patch. v2: Code restructure using min and max ratio variables (Ander) Signed-off-by: Deepak M Signed-off-by: Madhav Chauhan

[Intel-gfx] [GLK MIPI DSI V5 4/8] drm/i915: Set the Z inversion overlap field

From: Deepak M Dual link Z-inversion overlap field is present in MIPI_CTRL register unlike the older platforms, hence setting the same in this patch. Signed-off-by: Deepak M Signed-off-by: Madhav Chauhan ---

[Intel-gfx] [GLK MIPI DSI V5 0/8] GLK MIPI DSI VIDEO MODE PATCHES

The patches in this list enable MIPI DSI video mode support for GLK platform. Tesed locally. v2: Renamed bitfields macros as per review comments(Jani) v3: Code alignment/abstraction as per arch (Jani review comments) v4: Fix MIPI DSI disable sequence. Review comments(Jani) v5: Review comments

[Intel-gfx] [GLK MIPI DSI V5 2/8] drm/i915/glk: Program new MIPI DSI PHY registers for GLK

From: Deepak M Program the clk lane and tlpx time count registers to configure DSI PHY. v2: Addressed Jani's Review comments(renamed bit field macros) v3: Program clk lane timing reg same as dphy param reg. v4: Removed "line over 80 character" warning Signed-off-by: Deepak

[Intel-gfx] [GLK MIPI DSI V5 3/8] drm/i915/glk: Add MIPIIO Enable/disable sequence

From: Deepak M v2: Addressed Jani's Review comments(renamed bit field macros) v3: Jani's Review comment for aligning code to platforms and added wrapper functions. v4: Corrected enable/disable seuqence as per BSPEC Signed-off-by: Deepak M Signed-off-by:

[Intel-gfx] [GLK MIPI DSI V5 7/8] drm/i915/glk: Program txesc clock divider for GLK

From: Deepak M v2: Addressed Jani's Review comments(renamed bit field macros) Txesc clock divider is calculated and programmed for geminilake platform. Signed-off-by: Deepak M Signed-off-by: Madhav Chauhan ---

[Intel-gfx] [GLK MIPI DSI V5 6/8] drm/i915i/glk: Program MIPI_CLOCK_CTRL only for BXT

From: Deepak M Register MIPI_CLOCK_CTRL is applicable only for BXT platform. Future platform have other registers to program the escape clock dividers. Signed-off-by: Deepak M Signed-off-by: Madhav Chauhan ---

[Intel-gfx] [GLK MIPI DSI V5 1/8] drm/i915/glk: Program dphy param reg for GLK

From: Deepak M For GEMINILAKE, dphy param reg values are programmed in terms of HS byte clock count while for older platforms in terms of HS ddr clk count. v2: Added comments to clarify ddr clock count calculation v3: Use multiplier variable instead of IS_GEMINILAKE() check

Re: [Intel-gfx] [PATCH] drm/i915: Convert remaining users of 32bit power domain masks

On Tue, 2017-02-14 at 14:05 +0200, Joonas Lahtinen wrote: > On ma, 2017-02-13 at 16:57 +0200, Ander Conselvan de Oliveira wrote: > > I screwed up the rebase of commit d8fc70b7367b ("drm/i915: Make power > > domain masks 64 bit long") before sending v2, causing a couple of > > conversions from 32

  1   2   >