Re: [Intel-gfx] [RFC PATCH v3 1/7] drm/i915: setup bridge for HDMI LPE audio driver
On Mon, 28 Nov 2016, "Anand, Jerome" wrote: > Last time , it took close to 10 days when my patches were reflected on > the gfx mailing list. Not sure what is the problem ?? Let me try > sending it again ?? I guess the last time they only ever showed up because Ville bounced them to the list after I'd wondered where the patches were... Clearly the patches go through to people directly, at least Ville, and your replies on the list go through, but there's got to be something going on with how you send patches to the lists. (I'd suspect freedesktop.org, but the patches weren't on alsa-devel archive either.) You already seem to be using 'git send-email'. I don't know what to suggest next, except to maybe try to send a test mail to the list using 'git send-email' and see if it goes through. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm: Fix shift operations for drm_fb_helper::drm_target_preferred()
On su, 2016-11-27 at 17:09 +, Chris Wilson wrote: > smatch correctly warns: > > drivers/gpu/drm/drm_fb_helper.c:1960 drm_target_preferred() warn: > should '1 << i' be a 64 bit type? > drivers/gpu/drm/drm_fb_helper.c:2001 drm_target_preferred() warn: > should '1 << i' be a 64 bit type? > > Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm: Protect fb_helper list manipulation with a mutex
On Mon, Nov 28, 2016 at 08:55:58AM +0100, Daniel Vetter wrote: > On Wed, Nov 23, 2016 at 02:04:17PM +, Chris Wilson wrote: > > Though we only walk the kernel_fb_helper_list inside a panic (or single > > thread debugging), we still need to protect the list manipulation on > > creating/removing a framebuffer device in order to prevent list > > corruption. > > > > Signed-off-by: Chris Wilson > > I guess this explains the moved hunk in patch 1. Still feels misplaced, > but with or without moving that around: No, that had to be moved to pull the register_framebuffer out from underneath the lock (as it causes a lock recursion into the fbdev trying to do a modeset). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm: Track framebuffer references at the point of assignment
On Mon, Nov 28, 2016 at 08:48:34AM +0100, Daniel Vetter wrote:
> On Fri, Nov 25, 2016 at 03:32:31PM +, Chris Wilson wrote:
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1253,7 +1253,7 @@ drm_atomic_set_fb_for_plane(struct drm_plane_state
> > *plane_state,
> > DRM_DEBUG_ATOMIC("Set [NOFB] for plane state %p\n",
> > plane_state);
> >
> > - drm_framebuffer_assign(&plane_state->fb, fb);
> > + drm_framebuffer_assign(__mkwrite_drm_framebuffer(&plane_state->fb), fb);
>
> Feels like const gone the wrong way round? Or I'm not entirely clear on
> what this is supposed to achieve. Just dropping the const would still be a
> nice improvement.
No one is supposed to be writing to it. Adding the const generates a
compiler warning for incorrect code that doesn't do the refcounting -
but doesn't generate a warning for anything simply checking the value.
It is the moral equivalent to calling it _fb to catch all the users.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Promote drm_mm alignment to u64
On su, 2016-11-27 at 19:05 +, Chris Wilson wrote: > In places (e.g. i915.ko), the alignment is exported to userspace as u64 > and there now exists hardware for which we can indeed utilize a u64 > alignment. As such, we need to keep 64bit integers throughout when > handling alignment. > > Testcase: igt/drm_mm/align64 > Testcase: igt/gem_exec_alignment > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [i-g-t PATCH] lib: add option for running generic tests cases only
Pretend to run on a non-intel machine even when running on i915.ko,
so that we could run and gather passrate data.
Signed-off-by: Abdiel Janulgue
---
lib/drmtest.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index 44abc7e..a8b75e8 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -254,8 +254,11 @@ int __drm_open_driver(int chipset)
continue;
if (chipset & DRIVER_INTEL && is_i915_device(fd) &&
- has_known_intel_chipset(fd))
+ has_known_intel_chipset(fd)) {
+ igt_skip_on_f(getenv("IGT_GENERIC_ONLY"),
+ "Generic tests only\n");
return fd;
+ }
if (chipset & DRIVER_VC4 &&
is_vc4_device(fd))
@@ -415,5 +418,6 @@ int drm_open_driver_render(int chipset)
void igt_require_intel(int fd)
{
+ igt_skip_on_f(getenv("IGT_GENERIC_ONLY"), "Generic tests only\n");
igt_require(is_i915_device(fd) && has_known_intel_chipset(fd));
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Regression report] Weekly regression report WW48
On Mon, 28 Nov 2016, Jairo Miramontes wrote: > Total regressions: 47 Repeating my earlier request, please share a fdo bugzilla query link where anyone can get the results in bugzilla. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] "vblank wait timed out" on Intel 965GME/GLE
Hi, In linux-4.8.11, I get the following in my dmesg (and a 20-second delay): [1.932295] Linux agpgart interface v0.103 [1.932448] [drm] Initialized drm 1.1.0 20060810 [1.932799] pci :00:00.0: Intel 965GME/GLE Chipset [1.932902] pci :00:00.0: detected gtt size: 524288K total, 262144K mappable [1.933562] pci :00:00.0: detected 8192K stolen memory [1.933731] [drm] Memory usable by graphics device = 512M [1.933820] [drm] Replacing VGA console driver [1.934697] Console: switching to colour dummy device 80x25 [1.940123] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [1.940133] [drm] Driver supports precise vblank timestamp query. [1.942520] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [1.979784] ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared [1.979798] ACPI: Battery Slot [C245] (battery present) [2.292889] [drm] RC6 disabled, disabling runtime PM support [2.292902] [drm] initialized overlay support [2.342197] ACPI Exception: AE_AML_PACKAGE_LIMIT, Index (0x4) is beyond end of object (length 0x4) (20160422/exoparg2-427) [2.342215] ACPI Error: Method parse/execution failed [\_SB.C003.C09E._DOD] (Node 88003d83ab68), AE_AML_PACKAGE_LIMIT (20160422/psparse-542) [2.342232] ACPI Exception: AE_AML_PACKAGE_LIMIT, Evaluating _DOD (20160422/video-1254) [2.342429] ACPI: Video Device [C09E] (multi-head: yes rom: no post: no) [2.344549] acpi device:01: registered as cooling_device7 [2.344694] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3 [2.344746] [drm] Initialized i915 1.6.0 20160711 for :00:02.0 on minor 0 [3.819223] ALSA device list: [3.819236] No soundcards found. [ 12.640067] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:26:pipe A] flip_done timed out [ 12.742064] [ cut here ] [ 12.742086] WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/drm_irq.c:1224 drm_wait_one_vblank+0xf9/0x150 [ 12.742106] vblank wait timed out on crtc 0 [ 12.742118] Modules linked in: [ 12.742136] CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 4.8.11 #1 [ 12.742149] Hardware name: Hewlett-Packard Compaq 610/308A, BIOS 68PVU Ver. F.05 07/28/2009 [ 12.742174] Workqueue: events_unbound async_run_entry_fn [ 12.742188] 88003d8d7978 81223c01 88003d8d79d8 [ 12.742214] 88003d8d79c8 8104278b 88003d8d7a28 [ 12.742238] 04c88161412c 88003d8d79d8 88003d09 [ 12.742262] Call Trace: [ 12.742281] [] dump_stack+0x4d/0x6c [ 12.742297] [] __warn+0xdb/0x100 [ 12.742312] [] warn_slowpath_fmt+0x44/0x50 [ 12.742329] [] ? finish_wait+0x62/0x80 [ 12.742345] [] drm_wait_one_vblank+0xf9/0x150 [ 12.742361] [] ? add_wait_queue+0x60/0x60 [ 12.742379] [] intel_get_load_detect_pipe+0x64f/0x6c0 [ 12.742397] [] intel_tv_detect+0x113/0x530 [ 12.742413] [] ? mutex_lock+0x11/0x32 [ 12.742431] [] drm_helper_probe_single_connector_modes+0x252/0x4d0 [ 12.742453] [] drm_fb_helper_initial_config+0x8e/0x400 [ 12.742470] [] intel_fbdev_initial_config+0x17/0x30 [ 12.742486] [] async_run_entry_fn+0x36/0xf0 [ 12.742502] [] process_one_work+0x133/0x330 [ 12.742517] [] worker_thread+0x125/0x470 [ 12.742532] [] ? process_scheduled_works+0x40/0x40 [ 12.742548] [] kthread+0xc4/0xe0 [ 12.742564] [] ret_from_fork+0x1f/0x40 [ 12.742580] [] ? kthread_freezable_should_stop+0x70/0x70 [ 12.742595] ---[ end trace 96eae8324e71c040 ]--- [ 12.927424] [ cut here ] [ 12.927445] WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/drm_irq.c:1224 drm_wait_one_vblank+0xf9/0x150 [ 12.927466] vblank wait timed out on crtc 0 [ 12.927477] Modules linked in: [ 12.927493] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW 4.8.11 #1 [ 12.927513] Hardware name: Hewlett-Packard Compaq 610/308A, BIOS 68PVU Ver. F.05 07/28/2009 [ 12.927535] Workqueue: events_unbound async_run_entry_fn [ 12.927549] 88003d8d7818 81223c01 88003d8d7878 [ 12.927574] 88003d8d7868 8104278b 88003d8d78c8 [ 12.927598] 04c88161412c 01ff8800 88003d09 [ 12.927622] Call Trace: [ 12.927637] [] dump_stack+0x4d/0x6c [ 12.927652] [] __warn+0xdb/0x100 [ 12.927667] [] warn_slowpath_fmt+0x44/0x50 [ 12.927683] [] ? finish_wait+0x62/0x80 [ 12.927699] [] drm_wait_one_vblank+0xf9/0x150 [ 12.927714] [] ? add_wait_queue+0x60/0x60 [ 12.927730] [] intel_pre_plane_update+0x18c/0x1b0 [ 12.927746] [] intel_atomic_commit_tail+0xd0/0x1090 [ 12.927760] [] ? mutex_lock+0x11/0x32 [ 12.927776] [] ? intel_fbc_choose_crtc+0x76/0x1b0 [ 12.927792] [] ? intel_prepare_plane_fb+0xa3/0x2a0 [ 12
[Intel-gfx] [PATCH] drm/i915: Revert ea0000f0 "Roll out the helper nonblock tracking"
Commit eaf0 has been causing multiple problems for i915 users. See for
example:
https://bugs.freedesktop.org/show_bug.cgi?id=96781
https://bugs.freedesktop.org/show_bug.cgi?id=97529
https://bugzilla.redhat.com/show_bug.cgi?id=1385228
https://forums.opensuse.org/showthread.php/520969-drm-915-Resetting-chip-after-gpu-hang
Those last two are not confirmed but look like the same problem.
This has only been lightly tested and probably shouldn't go upstream yet.
Signed-off-by: Jim Rees
---
drivers/gpu/drm/i915/intel_display.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 81c1149..c31c9e4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14346,8 +14346,6 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
WARN_ON(ret);
}
- drm_atomic_helper_wait_for_dependencies(state);
-
if (intel_state->modeset) {
memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
sizeof(intel_state->min_pixclk));
@@ -14470,8 +14468,6 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
if (intel_state->modeset && intel_can_enable_sagv(state))
intel_enable_sagv(dev_priv);
- drm_atomic_helper_commit_hw_done(state);
-
if (intel_state->modeset)
intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET);
@@ -14479,8 +14475,6 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
drm_atomic_helper_cleanup_planes(dev, state);
mutex_unlock(&dev->struct_mutex);
- drm_atomic_helper_commit_cleanup_done(state);
-
drm_atomic_state_free(state);
/* As one of the primary mmio accessors, KMS has a high likelihood
@@ -14546,10 +14540,6 @@ static int intel_atomic_commit(struct drm_device *dev,
return -EINVAL;
}
- ret = drm_atomic_helper_setup_commit(state, nonblock);
- if (ret)
- return ret;
-
INIT_WORK(&state->commit_work, intel_atomic_commit_work);
ret = intel_atomic_prepare_commit(dev, state, nonblock);
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] "vblank wait timed out" on Intel 965GME/GLE
On Mon, 28 Nov 2016, Ali Gholami Rudi wrote: > In linux-4.8.11, I get the following in my dmesg (and a > 20-second delay): Please file a bug at [1]. BR, Jani. [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4] Compact userptr object backing store allocation
On 14/11/2016 11:45, Tvrtko Ursulin wrote:
Hi Andrew,
On 11/11/2016 08:50, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Userptr backing store with SWIOTBL active is currently allocated in
the same
inefficient manner, with one sg entry per object page, as what the commit
871dfbd67d4e ("drm/i915: Allow compaction upto SWIOTLB max segment
size") fixed
for regular GEM objects.
We can fix that by adding new a __sg_alloc_table_from_pages core
function which
allows us to control the maximum desired coalesced segment size.
Other than that the series starts with two simple fixes to
sg_alloc_table_from_pages which deal with incorrect data type usage and a
theoretical overflow condition. Fixing the latter enables easy
addition of the
above mentioned __sg_alloc_table_from_pages.
Tvrtko Ursulin (4):
lib/scatterlist: Fix offset type in sg_alloc_table_from_pages
lib/scatterlist: Avoid potential scatterlist entry overflow
lib/scatterlist: Introduce and export __sg_alloc_table_from_pages
drm/i915: Use __sg_alloc_table_from_pages for userptr allocations
drivers/gpu/drm/i915/i915_drv.h| 9 +++
drivers/gpu/drm/i915/i915_gem.c| 15 +
drivers/gpu/drm/i915/i915_gem_userptr.c| 28 ++---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 4 +-
drivers/rapidio/devices/rio_mport_cdev.c | 4 +-
include/linux/scatterlist.h| 11 ++--
lib/scatterlist.c | 78
--
7 files changed, 87 insertions(+), 62 deletions(-)
I have three patches to lib/scatterlist.c in this series which has all
been reviewed and tested.
We would like to merge them via the DRM tree if there are no objections?
Excuse me for the re-ping - still looking for an ack to merge these few
patches via the drm tree. (The code in question does not have a
designated maintainer.)
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: drop the struct_mutex when wedged or trying to reset
We grab the struct_mutex in intel_crtc_page_flip, but if we are wedged
or a reset is in progress we bail early but never seem to actually
release the lock.
Fixes: 7f1847ebf48b ("drm/i915: Simplify checking of GPU reset_counter in
display pageflips")
Cc: Chris Wilson
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5d11002319f7..772a72a21513 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12214,7 +12214,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
intel_crtc->reset_count = i915_reset_count(&dev_priv->gpu_error);
if (i915_reset_in_progress_or_wedged(&dev_priv->gpu_error)) {
ret = -EIO;
- goto cleanup;
+ goto unlock;
}
atomic_inc(&intel_crtc->unpin_work_count);
@@ -12302,6 +12302,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
intel_unpin_fb_obj(fb, crtc->primary->state->rotation);
cleanup_pending:
atomic_dec(&intel_crtc->unpin_work_count);
+unlock:
mutex_unlock(&dev->struct_mutex);
cleanup:
crtc->primary->fb = old_fb;
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Promote drm_mm alignment to u64
Am 27.11.2016 um 20:05 schrieb Chris Wilson:
In places (e.g. i915.ko), the alignment is exported to userspace as u64
and there now exists hardware for which we can indeed utilize a u64
alignment. As such, we need to keep 64bit integers throughout when
handling alignment.
Testcase: igt/drm_mm/align64
Testcase: igt/gem_exec_alignment
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Reviewed-by: Christian König .
And yeah, we have a couple of use cases aligning something to a 4GB
boundary in a large address space as well.
Regards,
Christian.
---
drivers/gpu/drm/drm_mm.c | 37 +
include/drm/drm_mm.h | 16
2 files changed, 25 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 025dcd8cadcb..b5b0b667677d 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -93,12 +93,12 @@
static struct drm_mm_node *drm_mm_search_free_generic(const struct drm_mm *mm,
u64 size,
- unsigned alignment,
+ u64 alignment,
unsigned long color,
enum drm_mm_search_flags flags);
static struct drm_mm_node *drm_mm_search_free_in_range_generic(const struct
drm_mm *mm,
u64 size,
- unsigned alignment,
+ u64 alignment,
unsigned long color,
u64 start,
u64 end,
@@ -227,7 +227,7 @@ static void drm_mm_interval_tree_add_node(struct
drm_mm_node *hole_node,
static void drm_mm_insert_helper(struct drm_mm_node *hole_node,
struct drm_mm_node *node,
-u64 size, unsigned alignment,
+u64 size, u64 alignment,
unsigned long color,
enum drm_mm_allocator_flags flags)
{
@@ -246,10 +246,9 @@ static void drm_mm_insert_helper(struct drm_mm_node
*hole_node,
adj_start = adj_end - size;
if (alignment) {
- u64 tmp = adj_start;
- unsigned rem;
+ u64 rem;
- rem = do_div(tmp, alignment);
+ div64_u64_rem(adj_start, alignment, &rem);
if (rem) {
if (flags & DRM_MM_CREATE_TOP)
adj_start -= rem;
@@ -377,7 +376,7 @@ EXPORT_SYMBOL(drm_mm_reserve_node);
* 0 on success, -ENOSPC if there's no suitable hole.
*/
int drm_mm_insert_node_generic(struct drm_mm *mm, struct drm_mm_node *node,
- u64 size, unsigned alignment,
+ u64 size, u64 alignment,
unsigned long color,
enum drm_mm_search_flags sflags,
enum drm_mm_allocator_flags aflags)
@@ -399,7 +398,7 @@ EXPORT_SYMBOL(drm_mm_insert_node_generic);
static void drm_mm_insert_helper_range(struct drm_mm_node *hole_node,
struct drm_mm_node *node,
- u64 size, unsigned alignment,
+ u64 size, u64 alignment,
unsigned long color,
u64 start, u64 end,
enum drm_mm_allocator_flags flags)
@@ -424,10 +423,9 @@ static void drm_mm_insert_helper_range(struct drm_mm_node
*hole_node,
adj_start = adj_end - size;
if (alignment) {
- u64 tmp = adj_start;
- unsigned rem;
+ u64 rem;
- rem = do_div(tmp, alignment);
+ div64_u64_rem(adj_start, alignment, &rem);
if (rem) {
if (flags & DRM_MM_CREATE_TOP)
adj_start -= rem;
@@ -483,7 +481,7 @@ static void drm_mm_insert_helper_range(struct drm_mm_node
*hole_node,
* 0 on success, -ENOSPC if there's no suitable hole.
*/
int drm_mm_insert_node_in_range_generic(struct drm_mm *mm, struct drm_mm_node
*node,
- u64 size, unsigned alignment,
+ u64 size, u64 alignment,
unsigned long color,
u64 start, u64 end,
enum drm_mm_search_flags sflags,
@@ -550,16 +548,15 @@ void drm_mm_remove_node(struct drm_mm_node *node)
}
EXPORT_SYMBOL(drm_mm_remove_node);
-static int check_free_hole(u64 start, u64 end, u64 s
Re: [Intel-gfx] [PATCH 1/5] drm/i915/bxt: Corrected the guid for bxt.
On 11/23/2016 10:02 PM, Chris Wilson wrote:
On Wed, Nov 23, 2016 at 09:48:23PM +0530, Animesh Manna wrote:
Guid is changed for bxt platform, so corrected the guid for bxt.
v1: Initial version as RFC.
v2: Based on review comment from Jani and David,
have kept guid as binary format.
Signed-off-by: Ananth Krishna R
Signed-off-by: Bharath K Veera
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/intel_acpi.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
mode change 100644 => 100755 drivers/gpu/drm/i915/intel_acpi.c
diff --git a/drivers/gpu/drm/i915/intel_acpi.c
b/drivers/gpu/drm/i915/intel_acpi.c
old mode 100644
new mode 100755
3 people handled this patch and none complained about making
intel_acpi.c executable? What does happen when you try to execute it?
oh, will correct it in the next patchset.
index eb638a1..8c878ab
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -15,7 +15,7 @@
acpi_handle dhandle;
} intel_dsm_priv;
-static const u8 intel_dsm_guid[] = {
+static u8 intel_dsm_guid[] = {
Why drop the const?
intel_dsm_guid is not updated anywhere, it used to assign it to a common
pointer based on platform check in my current implementation.
we can explicitly typecast to avoid compilation warning to a normal
pointer which will be used during dsm probe. Hope it will be fine.
Please let me know for any concern/suggestion.
0xd3, 0x73, 0xd8, 0x7e,
0xd0, 0xc2,
0x4f, 0x4e,
@@ -23,6 +23,14 @@
0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c
};
+static u8 intel_dsm_guid_bxt[] = {
Missing const.
Explained above.
+ 0xc6, 0x41, 0x5b, 0x3e,
+ 0x1d, 0xeb,
+ 0x60, 0x42,
+ 0x9d, 0x15,
+ 0xc7, 0x1f, 0xba, 0xda, 0xe4, 0x14
+};
+
static char *intel_dsm_port_name(u8 id)
{
switch (id) {
@@ -113,12 +121,20 @@ static void intel_dsm_platform_mux_info(void)
static bool intel_dsm_pci_probe(struct pci_dev *pdev)
{
acpi_handle dhandle;
+ struct drm_device *dev = pci_get_drvdata(pdev);
+ struct drm_i915_private *dev_priv = dev->dev_private;
dev == dev_priv, just a rose by another name. Use to_i915();
+ u8 *guid;
Missing const.
Explained above.
dhandle = ACPI_HANDLE(&pdev->dev);
if (!dhandle)
return false;
- if (!acpi_check_dsm(dhandle, intel_dsm_guid, INTEL_DSM_REVISION_ID,
+ if (IS_BROXTON(dev_priv))
+ guid = intel_dsm_guid_bxt;
+ else
+ guid = intel_dsm_guid;
+
+ if (!acpi_check_dsm(dhandle, guid, INTEL_DSM_REVISION_ID,
1 << INTEL_DSM_FN_PLATFORM_MUX_INFO)) {
DRM_DEBUG_KMS("no _DSM method for intel device\n");
return false;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: drop the struct_mutex when wedged or trying to reset
== Series Details == Series: drm/i915: drop the struct_mutex when wedged or trying to reset URL : https://patchwork.freedesktop.org/series/16024/ State : success == Summary == Series 16024v1 drm/i915: drop the struct_mutex when wedged or trying to reset https://patchwork.freedesktop.org/api/1.0/series/16024/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-a: dmesg-warn -> PASS (fi-ilk-650) fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 4d904cb07bb992d4b5f3c8b8d00ed5297b774c0c drm-tip: 2016y-11m-28d-08h-24m-29s UTC integration manifest f17af58 drm/i915: drop the struct_mutex when wedged or trying to reset == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3121/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/skl: Increase PCODE CDCLK change notify timeout
On pe, 2016-11-25 at 11:44 +, Chris Wilson wrote: > On Fri, Nov 25, 2016 at 01:30:38PM +0200, Ville Syrjälä wrote: > > On Fri, Nov 25, 2016 at 12:57:01PM +0200, Imre Deak wrote: > > > commit 848496e5902833600f7992f4faa82dc1546051ba > > > Author: Ville Syrjälä > > > Date: Wed Jul 13 16:32:03 2016 +0300 > > > > > > drm/i915: Wait up to 3ms for the pcu to ack the cdclk change > > > request on SKL > > > > > > increased the timeout to match the spec, but we still see a > > > timeout on > > > at least one SKL. A CDCLK change request following the failed one > > > will > > > succeed nevertheless, so let's try to increase the timeout to > > > 10ms. > > > > > > v2: > > > - Use 1ms poll period instead of 10us. (Chris) > > > > I'm not sure that's what we want. IIRC the spec says no delay > > between > > attempts, so I'm not sure this isn't just going to make it more > > likely > > to fail. > > Hmm. We're going to be scheduled away eventually, unless we steal the > cpu for 10ms. To be strict to the spec we would need > > preempt_disable(); > ret = wait_for_atomic(pcu_ready(), 10); > preempt_enable(); > > return ret; Yes, after some testing it looks like when things fail we call pcu_ready() only once after scheduling away for 3ms and so if that one call fails we time out. So I think we need preempt_disable(), I updated the patch adding that. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/3] drm/i915/gen9: Fix PCODE polling during CDCLK change notification
commit 848496e5902833600f7992f4faa82dc1546051ba
Author: Ville Syrjälä
Date: Wed Jul 13 16:32:03 2016 +0300
drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL
increased the timeout to match the spec, but we still see a timeout on
at least one SKL. A CDCLK change request following the failed one will
succeed nevertheless.
I could reproduce this problem easily by running kms_pipe_crc_basic in a
loop. In all failure cases _wait_for() was pre-empted for >3ms and so in
the worst case - when the pre-emption happened right after calculating
timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only
once which failed and so _wait_for() timed out. As opposed to this the
spec says to keep retrying the request for at most a 3ms period.
To fix this disable pre-emption to maximize the number of times we retry
the request. Also increase the timeout to 10ms to account for interrupts
that could reduce the number of these attempts. With this change I
couldn't trigger the problem.
v2:
- Use 1ms poll period instead of 10us. (Chris)
v3:
- Poll with pre-emption disabled to increase the number of request
attempts. (Ville, Chris)
- Factor out a helper to poll, it's also needed by the next patch.
Cc: Ville Syrjälä
Cc: Chris Wilson
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929
Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 2 +-
drivers/gpu/drm/i915/intel_display.c | 29 +++-
drivers/gpu/drm/i915/intel_pm.c | 43
4 files changed, 53 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 01f5067..f618807 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3593,6 +3593,7 @@ extern void intel_display_print_error_state(struct
drm_i915_error_state_buf *e,
int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox, u32
*val);
int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u32 mbox, u32
val);
+int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32
request);
/* intel_sideband.c */
u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6747d68..f542cbc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7424,7 +7424,6 @@ enum {
#define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT 24
#define SKL_PCODE_CDCLK_CONTROL 0x7
#define SKL_CDCLK_PREPARE_FOR_CHANGE 0x3
-#define SKL_CDCLK_READY_FOR_CHANGE 0x1
#define GEN6_PCODE_WRITE_MIN_FREQ_TABLE 0x8
#define GEN6_PCODE_READ_MIN_FREQ_TABLE 0x9
#define GEN6_READ_OC_PARAMS 0xc
@@ -7437,6 +7436,7 @@ enum {
#define GEN9_SAGV_DISABLE 0x0
#define GEN9_SAGV_IS_DISABLED 0x1
#define GEN9_SAGV_ENABLE 0x3
+#define GEN9_PCODE_REQUEST_DONE 0x1
#define GEN6_PCODE_DATA_MMIO(0x138128)
#define GEN6_PCODE_FREQ_IA_RATIO_SHIFT 8
#define GEN6_PCODE_FREQ_RING_RATIO_SHIFT 16
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5d11002..46c0e42 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6245,35 +6245,22 @@ skl_dpll0_disable(struct drm_i915_private *dev_priv)
dev_priv->cdclk_pll.vco = 0;
}
-static bool skl_cdclk_pcu_ready(struct drm_i915_private *dev_priv)
-{
- int ret;
- u32 val;
-
- /* inform PCU we want to change CDCLK */
- val = SKL_CDCLK_PREPARE_FOR_CHANGE;
- mutex_lock(&dev_priv->rps.hw_lock);
- ret = sandybridge_pcode_read(dev_priv, SKL_PCODE_CDCLK_CONTROL, &val);
- mutex_unlock(&dev_priv->rps.hw_lock);
-
- return ret == 0 && (val & SKL_CDCLK_READY_FOR_CHANGE);
-}
-
-static bool skl_cdclk_wait_for_pcu_ready(struct drm_i915_private *dev_priv)
-{
- return _wait_for(skl_cdclk_pcu_ready(dev_priv), 3000, 10) == 0;
-}
-
static void skl_set_cdclk(struct drm_i915_private *dev_priv, int cdclk, int
vco)
{
u32 freq_select, pcu_ack;
+ int ret;
WARN_ON((cdclk == 24000) != (vco == 0));
DRM_DEBUG_DRIVER("Changing CDCLK to %d kHz (VCO %d kHz)\n", cdclk, vco);
- if (!skl_cdclk_wait_for_pcu_ready(dev_priv)) {
- DRM_ERROR("failed to inform PCU about cdclk change\n");
+ mutex_lock(&dev_priv->rps.hw_lock);
+ ret = skl_pcode_request(dev_priv, SKL_PCODE_CDCLK_CONTROL,
+ SKL_CDCLK_PREPARE_FOR_CHANGE);
+ mutex_unlock(&dev_priv->rps.hw_lock);
+ if (ret) {
+ DRM_ERROR("Failed to inform PCU about cdclk change (%d)\n",
+
[Intel-gfx] [PATCH v3 3/3] drm/i915/gen9: Fix PCODE polling during SAGV disabling
According to the previous patch, it's possible atm that we call
intel_do_sagv_disable() only once during the 1ms period and time out if
that call fails. As opposed to this the spec says that we need to keep
retrying this request for a 1ms duration, so let's do this similarly to
the CDCLK change notification request.
Cc: Lyude
Cc: Ville Syrjälä
Cc: Chris Wilson
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_reg.h | 1 -
drivers/gpu/drm/i915/intel_pm.c | 33 +++--
2 files changed, 7 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f542cbc..c7458b7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7434,7 +7434,6 @@ enum {
#define HSW_PCODE_DYNAMIC_DUTY_CYCLE_CONTROL 0x1A
#define GEN9_PCODE_SAGV_CONTROL 0x21
#define GEN9_SAGV_DISABLE 0x0
-#define GEN9_SAGV_IS_DISABLED 0x1
#define GEN9_SAGV_ENABLE 0x3
#define GEN9_PCODE_REQUEST_DONE 0x1
#define GEN6_PCODE_DATA_MMIO(0x138128)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index edd68f3..43b0b40 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2954,24 +2954,10 @@ intel_enable_sagv(struct drm_i915_private *dev_priv)
return 0;
}
-static int
-intel_do_sagv_disable(struct drm_i915_private *dev_priv)
-{
- int ret;
- uint32_t temp = GEN9_SAGV_DISABLE;
-
- ret = sandybridge_pcode_read(dev_priv, GEN9_PCODE_SAGV_CONTROL,
-&temp);
- if (ret)
- return ret;
- else
- return temp & GEN9_SAGV_IS_DISABLED;
-}
-
int
intel_disable_sagv(struct drm_i915_private *dev_priv)
{
- int ret, result;
+ int ret;
if (!intel_has_sagv(dev_priv))
return 0;
@@ -2981,27 +2967,22 @@ intel_disable_sagv(struct drm_i915_private *dev_priv)
DRM_DEBUG_KMS("Disabling the SAGV\n");
mutex_lock(&dev_priv->rps.hw_lock);
-
/* bspec says to keep retrying for at least 1 ms */
- ret = wait_for(result = intel_do_sagv_disable(dev_priv), 1);
+ ret = skl_pcode_request(dev_priv, GEN9_PCODE_SAGV_CONTROL,
+ GEN9_SAGV_DISABLE);
mutex_unlock(&dev_priv->rps.hw_lock);
- if (ret == -ETIMEDOUT) {
- DRM_ERROR("Request to disable SAGV timed out\n");
- return -ETIMEDOUT;
- }
-
/*
* Some skl systems, pre-release machines in particular,
* don't actually have an SAGV.
*/
- if (IS_SKYLAKE(dev_priv) && result == -ENXIO) {
+ if (IS_SKYLAKE(dev_priv) && ret == -ENXIO) {
DRM_DEBUG_DRIVER("No SAGV found on system, ignoring\n");
dev_priv->sagv_status = I915_SAGV_NOT_CONTROLLED;
return 0;
- } else if (result < 0) {
- DRM_ERROR("Failed to disable the SAGV\n");
- return result;
+ } else if (ret < 0) {
+ DRM_ERROR("Failed to disable the SAGV (%d)\n", ret);
+ return ret;
}
dev_priv->sagv_status = I915_SAGV_DISABLED;
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/3] drm/i915/gen6+: Clear upper data byte during PCODE write
The spec calls for the upper data byte to be cleared before most of the PCODE write commands, for others like IPS control it doesn't say anything about this byte. Let's clear it in case it's clobbered somehow, especially that there are places where we only do a PCODE write without a preceeding PCODE read. Cc: Ville Syrjälä Signed-off-by: Imre Deak Reviewed-by: Chris Wilson Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 29b6653..66c62f3 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -7838,6 +7838,7 @@ int sandybridge_pcode_write(struct drm_i915_private *dev_priv, } I915_WRITE_FW(GEN6_PCODE_DATA, val); + I915_WRITE_FW(GEN6_PCODE_DATA1, 0); I915_WRITE_FW(GEN6_PCODE_MAILBOX, GEN6_PCODE_READY | mbox); if (intel_wait_for_register_fw(dev_priv, -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/15] drm/i915: Trim i915_guc_info() stack usage
On 25/11/2016 09:30, Chris Wilson wrote:
i915_guc_info() (part of debugfs output) tries to avoid holding
struct_mutex for a long period by copying onto the stack. This causes a
warning that the stack frame is massive, so stop doing that. We can even
forgo holding the struct_mutex here as that doesn't serialise the values
being read (and the lists used exist for the device lifetime).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 39 +
1 file changed, 14 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8eb8c29b7492..7676e88ae5f2 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2434,47 +2434,36 @@ static void i915_guc_client_info(struct seq_file *m,
static int i915_guc_info(struct seq_file *m, void *data)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
- struct drm_device *dev = &dev_priv->drm;
- struct intel_guc guc;
- struct i915_guc_client client = {};
+ const struct intel_guc *guc = &dev_priv->guc;
struct intel_engine_cs *engine;
enum intel_engine_id id;
- u64 total = 0;
+ u64 total;
if (!HAS_GUC_SCHED(dev_priv))
return 0;
- if (mutex_lock_interruptible(&dev->struct_mutex))
- return 0;
-
- /* Take a local copy of the GuC data, so we can dump it at leisure */
- guc = dev_priv->guc;
- if (guc.execbuf_client)
- client = *guc.execbuf_client;
So this used to print out all zeros when GuC submission is disabled.
Should we instead just skip all the counter dumping if execbuf_client ==
NULL and just print "disabled" or something?
-
- mutex_unlock(&dev->struct_mutex);
-
seq_printf(m, "Doorbell map:\n");
- seq_printf(m, "\t%*pb\n", GUC_MAX_DOORBELLS, guc.doorbell_bitmap);
- seq_printf(m, "Doorbell next cacheline: 0x%x\n\n", guc.db_cacheline);
+ seq_printf(m, "\t%*pb\n", GUC_MAX_DOORBELLS, guc->doorbell_bitmap);
+ seq_printf(m, "Doorbell next cacheline: 0x%x\n\n", guc->db_cacheline);
- seq_printf(m, "GuC total action count: %llu\n", guc.action_count);
- seq_printf(m, "GuC action failure count: %u\n", guc.action_fail);
- seq_printf(m, "GuC last action command: 0x%x\n", guc.action_cmd);
- seq_printf(m, "GuC last action status: 0x%x\n", guc.action_status);
- seq_printf(m, "GuC last action error code: %d\n", guc.action_err);
+ seq_printf(m, "GuC total action count: %llu\n", guc->action_count);
+ seq_printf(m, "GuC action failure count: %u\n", guc->action_fail);
+ seq_printf(m, "GuC last action command: 0x%x\n", guc->action_cmd);
+ seq_printf(m, "GuC last action status: 0x%x\n", guc->action_status);
+ seq_printf(m, "GuC last action error code: %d\n", guc->action_err);
+ total = 0;
seq_printf(m, "\nGuC submissions:\n");
for_each_engine(engine, dev_priv, id) {
- u64 submissions = guc.submissions[id];
+ u64 submissions = guc->submissions[id];
total += submissions;
seq_printf(m, "\t%-24s: %10llu, last seqno 0x%08x\n",
- engine->name, submissions, guc.last_seqno[id]);
+ engine->name, submissions, guc->last_seqno[id]);
}
seq_printf(m, "\t%s: %llu\n", "Total", total);
- seq_printf(m, "\nGuC execbuf client @ %p:\n", guc.execbuf_client);
- i915_guc_client_info(m, dev_priv, &client);
+ seq_printf(m, "\nGuC execbuf client @ %p:\n", guc->execbuf_client);
Dereferencing guc->execbuf_client doesn't oops in execlist mode? I must
be misreading something in that case.
+ i915_guc_client_info(m, dev_priv, guc->execbuf_client);
i915_guc_log_info(m, dev_priv);
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: drop the struct_mutex when wedged or trying to reset
On ma, 2016-11-28 at 10:36 +, Matthew Auld wrote:
> We grab the struct_mutex in intel_crtc_page_flip, but if we are wedged
> or a reset is in progress we bail early but never seem to actually
> release the lock.
>
> Fixes: 7f1847ebf48b ("drm/i915: Simplify checking of GPU reset_counter in
> display pageflips")
> Cc: Chris Wilson
> Signed-off-by: Matthew Auld
Cc: stable # v4.6 ?
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Cleanup i915_gem_restore_gtt_mappings()
On Mon, Nov 21, 2016 at 12:30:01PM +, Chris Wilson wrote: > > I was looking at how we get out of the pm_runtime mess. In part, we hurt > ourselves because we are using wakeref_count to disable asserts, but it > also seems that pushing the optimisation to pm_runtime is the right > thing to do. Any more thoughts on this? Kind regards, David Weinehall ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915/bxt: Corrected the guid for bxt.
On Mon, 28 Nov 2016, Animesh Manna wrote:
> On 11/23/2016 10:02 PM, Chris Wilson wrote:
>> On Wed, Nov 23, 2016 at 09:48:23PM +0530, Animesh Manna wrote:
>>> Guid is changed for bxt platform, so corrected the guid for bxt.
>>>
>>> v1: Initial version as RFC.
>>>
>>> v2: Based on review comment from Jani and David,
>>> have kept guid as binary format.
>>>
>>> Signed-off-by: Ananth Krishna R
>>> Signed-off-by: Bharath K Veera
>>> Signed-off-by: Animesh Manna
>>> ---
>>> drivers/gpu/drm/i915/intel_acpi.c | 20 ++--
>>> 1 file changed, 18 insertions(+), 2 deletions(-)
>>> mode change 100644 => 100755 drivers/gpu/drm/i915/intel_acpi.c
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_acpi.c
>>> b/drivers/gpu/drm/i915/intel_acpi.c
>>> old mode 100644
>>> new mode 100755
>> 3 people handled this patch and none complained about making
>> intel_acpi.c executable? What does happen when you try to execute it?
> oh, will correct it in the next patchset.
>>
>>> index eb638a1..8c878ab
>>> --- a/drivers/gpu/drm/i915/intel_acpi.c
>>> +++ b/drivers/gpu/drm/i915/intel_acpi.c
>>> @@ -15,7 +15,7 @@
>>> acpi_handle dhandle;
>>> } intel_dsm_priv;
>>>
>>> -static const u8 intel_dsm_guid[] = {
>>> +static u8 intel_dsm_guid[] = {
>> Why drop the const?
> intel_dsm_guid is not updated anywhere, it used to assign it to a common
> pointer based on platform check in my current implementation.
> we can explicitly typecast to avoid compilation warning to a normal
> pointer which will be used during dsm probe. Hope it will be fine.
> Please let me know for any concern/suggestion.
Doh, you use 'const u8 *guid', of course. The acpi_check_dsm uuid
parameter is also const u8 *.
BR,
Jani.
>
>>
>>> 0xd3, 0x73, 0xd8, 0x7e,
>>> 0xd0, 0xc2,
>>> 0x4f, 0x4e,
>>> @@ -23,6 +23,14 @@
>>> 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c
>>> };
>>>
>>> +static u8 intel_dsm_guid_bxt[] = {
>> Missing const.
> Explained above.
>>
>>> + 0xc6, 0x41, 0x5b, 0x3e,
>>> + 0x1d, 0xeb,
>>> + 0x60, 0x42,
>>> + 0x9d, 0x15,
>>> + 0xc7, 0x1f, 0xba, 0xda, 0xe4, 0x14
>>> +};
>>> +
>>> static char *intel_dsm_port_name(u8 id)
>>> {
>>> switch (id) {
>>> @@ -113,12 +121,20 @@ static void intel_dsm_platform_mux_info(void)
>>> static bool intel_dsm_pci_probe(struct pci_dev *pdev)
>>> {
>>> acpi_handle dhandle;
>>> + struct drm_device *dev = pci_get_drvdata(pdev);
>>> + struct drm_i915_private *dev_priv = dev->dev_private;
>> dev == dev_priv, just a rose by another name. Use to_i915();
>>
>>> + u8 *guid;
>> Missing const.
> Explained above.
>>
>>>
>>> dhandle = ACPI_HANDLE(&pdev->dev);
>>> if (!dhandle)
>>> return false;
>>>
>>> - if (!acpi_check_dsm(dhandle, intel_dsm_guid, INTEL_DSM_REVISION_ID,
>>> + if (IS_BROXTON(dev_priv))
>>> + guid = intel_dsm_guid_bxt;
>>> + else
>>> + guid = intel_dsm_guid;
>>> +
>>> + if (!acpi_check_dsm(dhandle, guid, INTEL_DSM_REVISION_ID,
>>> 1 << INTEL_DSM_FN_PLATFORM_MUX_INFO)) {
>>> DRM_DEBUG_KMS("no _DSM method for intel device\n");
>>> return false;
>>> --
>>> 1.9.1
>>>
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [dim PATCH] dim: fix update-branches to fetch all available nightly repos
Update all nightly repos that have a corresponding local remote.
Cc: Archit Taneja
Signed-off-by: Jani Nikula
---
dim | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/dim b/dim
index a709342572ab..3dd2d1dec796 100755
--- a/dim
+++ b/dim
@@ -1255,8 +1255,15 @@ function dim_update_branches
local repo remote
cd $DIM_PREFIX/$DIM_DRM_INTEL
- for remote in $DIM_DRM_INTEL_REMOTE `url_to_remote $drm_upstream_git`
origin; do
+ for repo in "${!drm_tip_repos[@]}"; do
+ url=${drm_tip_repos[$repo]}
+ if ! remote=$(url_to_remote $url 2>/dev/null); then
+ continue
+ fi
+ echo -n "Fetching $repo (local remote $remote)... "
+ # git fetch returns 128 if there's nothing to be fetched
git fetch -q $remote || true
+ echo "Done."
done
assert_repo_clean
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/15] drm/i915: Trim i915_guc_info() stack usage
On Mon, Nov 28, 2016 at 11:15:27AM +, Tvrtko Ursulin wrote:
>
> On 25/11/2016 09:30, Chris Wilson wrote:
> >i915_guc_info() (part of debugfs output) tries to avoid holding
> >struct_mutex for a long period by copying onto the stack. This causes a
> >warning that the stack frame is massive, so stop doing that. We can even
> >forgo holding the struct_mutex here as that doesn't serialise the values
> >being read (and the lists used exist for the device lifetime).
> >
> >Signed-off-by: Chris Wilson
> >---
> > drivers/gpu/drm/i915/i915_debugfs.c | 39
> > +
> > 1 file changed, 14 insertions(+), 25 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> >b/drivers/gpu/drm/i915/i915_debugfs.c
> >index 8eb8c29b7492..7676e88ae5f2 100644
> >--- a/drivers/gpu/drm/i915/i915_debugfs.c
> >+++ b/drivers/gpu/drm/i915/i915_debugfs.c
> >@@ -2434,47 +2434,36 @@ static void i915_guc_client_info(struct seq_file *m,
> > static int i915_guc_info(struct seq_file *m, void *data)
> > {
> > struct drm_i915_private *dev_priv = node_to_i915(m->private);
> >-struct drm_device *dev = &dev_priv->drm;
> >-struct intel_guc guc;
> >-struct i915_guc_client client = {};
> >+const struct intel_guc *guc = &dev_priv->guc;
> > struct intel_engine_cs *engine;
> > enum intel_engine_id id;
> >-u64 total = 0;
> >+u64 total;
> >
> > if (!HAS_GUC_SCHED(dev_priv))
> > return 0;
> >
> >-if (mutex_lock_interruptible(&dev->struct_mutex))
> >-return 0;
> >-
> >-/* Take a local copy of the GuC data, so we can dump it at leisure */
> >-guc = dev_priv->guc;
> >-if (guc.execbuf_client)
> >-client = *guc.execbuf_client;
>
> So this used to print out all zeros when GuC submission is disabled.
> Should we instead just skip all the counter dumping if
> execbuf_client == NULL and just print "disabled" or something?
That would be the sensible escape instead of HAS_GUC_SCHED.
if (!dev_priv->guc.execbuf_client) {
seq_puts(m, "GuC scheduling %s\n",
HAS_GUC_SCHED(dev_priv) ? "disabled" : "not supported");
return 0;
}
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/15] drm/i915/guc: Rename client->cookie to match use
On 25/11/2016 09:30, Chris Wilson wrote:
The client->cookie is a shadow of the doorbell->cookie value, so rename
it to indicate its association with the doorbell, like the doorbell id
and offset.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 2 +-
drivers/gpu/drm/i915/i915_guc_submission.c | 6 +++---
drivers/gpu/drm/i915/intel_guc.h | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7676e88ae5f2..fe62a9da4dd1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2414,7 +2414,7 @@ static void i915_guc_client_info(struct seq_file *m,
seq_printf(m, "\tPriority %d, GuC ctx index: %u, PD offset 0x%x\n",
client->priority, client->ctx_index, client->proc_desc_offset);
seq_printf(m, "\tDoorbell id %d, offset: 0x%x, cookie 0x%x\n",
- client->doorbell_id, client->doorbell_offset, client->cookie);
+ client->doorbell_id, client->doorbell_offset,
client->doorbell_cookie);
seq_printf(m, "\tWQ size %d, offset: 0x%x, tail %d\n",
client->wq_size, client->wq_offset, client->wq_tail);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 4462112725ef..81aa5d4265c0 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -567,11 +567,11 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
/* current cookie */
db_cmp.db_status = GUC_DOORBELL_ENABLED;
- db_cmp.cookie = gc->cookie;
+ db_cmp.cookie = gc->doorbell_cookie;
/* cookie to be updated */
db_exc.db_status = GUC_DOORBELL_ENABLED;
- db_exc.cookie = gc->cookie + 1;
+ db_exc.cookie = gc->doorbell_cookie + 1;
if (db_exc.cookie == 0)
db_exc.cookie = 1;
@@ -586,7 +586,7 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
/* if the exchange was successfully executed */
if (db_ret.value_qw == db_cmp.value_qw) {
/* db was successfully rung */
- gc->cookie = db_exc.cookie;
+ gc->doorbell_cookie = db_exc.cookie;
ret = 0;
break;
}
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 02337a81abc2..731e8a2f2644 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -74,7 +74,7 @@ struct i915_guc_client {
uint32_t proc_desc_offset;
uint32_t doorbell_offset;
- uint32_t cookie;
+ uint32_t doorbell_cookie;
uint16_t doorbell_id;
uint16_t padding[3];/* Maintain alignment */
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: drop the struct_mutex when wedged or trying to reset
On Mon, 28 Nov 2016, Joonas Lahtinen wrote:
> On ma, 2016-11-28 at 10:36 +, Matthew Auld wrote:
>> We grab the struct_mutex in intel_crtc_page_flip, but if we are wedged
>> or a reset is in progress we bail early but never seem to actually
>> release the lock.
>>
>> Fixes: 7f1847ebf48b ("drm/i915: Simplify checking of GPU reset_counter in
>> display pageflips")
>> Cc: Chris Wilson
>> Signed-off-by: Matthew Auld
>
> Cc: stable # v4.6 ?
$ dim fixes 7f1847ebf48b
Fixes: 7f1847ebf48b ("drm/i915: Simplify checking of GPU reset_counter in
display pageflips")
Cc: Chris Wilson
Cc: Daniel Vetter
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-gfx@lists.freedesktop.org
Cc: # v4.7+
>
> Reviewed-by: Joonas Lahtinen
>
> Regards, Joonas
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 5/5] drm/i915/guc: Remove spurious include
From: Arkadiusz Hiler Cc: Chris Wilson Cc: Michal Winiarski Signed-off-by: Arkadiusz Hiler Reviewed-by: Chris Wilson Link: http://patchwork.freedesktop.org/patch/msgid/1480096777-12573-6-git-send-email-arkadiusz.hi...@intel.com Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_guc_submission.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c index 125648253902..f724a30a3232 100644 --- a/drivers/gpu/drm/i915/i915_guc_submission.c +++ b/drivers/gpu/drm/i915/i915_guc_submission.c @@ -21,7 +21,6 @@ * IN THE SOFTWARE. * */ -#include #include #include #include -- 2.10.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 4/5] drm/i915/guc: Init send_mutex in intel_uc_init_early()
From: Arkadiusz Hiler
send_mutex is used to serialise communication with GuC via
intel_guc_send().
Since functions that utilize it are no longer limited to submission,
initialization should be handled as a part of general setup.
v2: move initialization to *_early()
Cc: Chris Wilson
Cc: Michal Winiarski
Signed-off-by: Arkadiusz Hiler
Reviewed-by: Chris Wilson
Link:
http://patchwork.freedesktop.org/patch/msgid/1480096777-12573-5-git-send-email-arkadiusz.hi...@intel.com
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c| 2 ++
drivers/gpu/drm/i915/i915_guc_submission.c | 1 -
drivers/gpu/drm/i915/intel_uc.c| 5 +
drivers/gpu/drm/i915/intel_uc.h| 1 +
4 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0fba4bb5655e..8dac298461c0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -817,6 +817,8 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
mutex_init(&dev_priv->wm.wm_mutex);
mutex_init(&dev_priv->pps_mutex);
+ intel_uc_init_early(dev_priv);
+
i915_memcpy_init_early(dev_priv);
ret = i915_workqueues_init(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 72fb525b9a8b..125648253902 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1388,7 +1388,6 @@ int i915_guc_submission_init(struct drm_i915_private
*dev_priv)
guc->ctx_pool_vma = vma;
ida_init(&guc->ctx_ids);
- mutex_init(&guc->send_mutex);
guc_log_create(guc);
guc_addon_create(guc);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index a24cf0822c3b..8ae67954563c 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -25,6 +25,11 @@
#include "i915_drv.h"
#include "intel_uc.h"
+void intel_uc_init_early(struct drm_i915_private *dev_priv)
+{
+ mutex_init(&dev_priv->guc.send_mutex);
+}
+
/*
* Read GuC command/status register (SOFT_SCRATCH_0)
* Return true if it contains a response rather than a command
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index a4dd0e05ba4f..de2b314cb1d7 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -169,6 +169,7 @@ struct intel_guc {
};
/* intel_uc.c */
+void intel_uc_init_early(struct drm_i915_private *dev_priv);
bool intel_guc_recv(struct drm_i915_private *dev_priv, u32 *status);
int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 len);
int intel_guc_sample_forcewake(struct intel_guc *guc);
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/5] drm/i915: Rename intel_guc.h to intel_uc.h
From: Arkadiusz Hiler
GuC is not the only one micro controller we have.
There are also HuC and DMC.
Making the file more general will help with code organization.
Cc: Chris Wilson
Cc: Michal Winiarski
Signed-off-by: Arkadiusz Hiler
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
Link:
http://patchwork.freedesktop.org/patch/msgid/1480096777-12573-2-git-send-email-arkadiusz.hi...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
drivers/gpu/drm/i915/intel_guc_loader.c | 2 +-
drivers/gpu/drm/i915/{intel_guc.h => intel_uc.h} | 4 ++--
4 files changed, 5 insertions(+), 5 deletions(-)
rename drivers/gpu/drm/i915/{intel_guc.h => intel_uc.h} (99%)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c5349aaaf874..297ad03ab0c2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -55,7 +55,7 @@
#include "intel_bios.h"
#include "intel_dpll_mgr.h"
-#include "intel_guc.h"
+#include "intel_uc.h"
#include "intel_lrc.h"
#include "intel_ringbuffer.h"
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 4462112725ef..e14220e961e5 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -26,7 +26,7 @@
#include
#include
#include "i915_drv.h"
-#include "intel_guc.h"
+#include "intel_uc.h"
/**
* DOC: GuC-based command submission
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index e2d0bdaee0c8..27f6fd57eb79 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -28,7 +28,7 @@
*/
#include
#include "i915_drv.h"
-#include "intel_guc.h"
+#include "intel_uc.h"
/**
* DOC: GuC-specific firmware loader
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_uc.h
similarity index 99%
rename from drivers/gpu/drm/i915/intel_guc.h
rename to drivers/gpu/drm/i915/intel_uc.h
index 02337a81abc2..0d8a4939d5ad 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -21,8 +21,8 @@
* IN THE SOFTWARE.
*
*/
-#ifndef _INTEL_GUC_H_
-#define _INTEL_GUC_H_
+#ifndef _INTEL_UC_H_
+#define _INTEL_UC_H_
#include "intel_guc_fwif.h"
#include "i915_guc_reg.h"
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/5] drm/i915/guc: Move guc_{send, recv}() to intel_uc.c
From: Arkadiusz Hiler
guc_send(), guc_recv() and related functions were introduced in the
i915_guc_submission.c and their scope was limited only to that file.
Those are not submission specific though.
This patch moves moves them to intel_uc.c with intel_ prefix added.
v2: rename intel_guc_log_* functions and clean up intel_guc_send usages
Cc: Chris Wilson
Cc: Michal Winiarski
Signed-off-by: Arkadiusz Hiler
Reviewed-by: Chris Wilson
Link:
http://patchwork.freedesktop.org/patch/msgid/1480096777-12573-4-git-send-email-arkadiusz.hi...@intel.com
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/i915_guc_submission.c | 147 -
drivers/gpu/drm/i915/intel_uc.c| 135 ++
drivers/gpu/drm/i915/intel_uc.h| 8 ++
4 files changed, 163 insertions(+), 130 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_uc.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 580602da899a..3c30916727fb 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -55,7 +55,8 @@ i915-y += i915_cmd_parser.o \
intel_uncore.o
# general-purpose microcontroller (GuC) support
-i915-y += intel_guc_loader.o \
+i915-y += intel_uc.o \
+ intel_guc_loader.o \
i915_guc_submission.o
# autogenerated null render state
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 69eba03b9823..72fb525b9a8b 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -49,7 +49,7 @@
* Firmware writes a success/fail code back to the action register after
* processes the request. The kernel driver polls waiting for this update and
* then proceeds.
- * See guc_send()
+ * See intel_guc_send()
*
* Doorbells:
* Doorbells are interrupts to uKernel. A doorbell is a single cache line (QW)
@@ -66,140 +66,29 @@
*/
/*
- * Read GuC command/status register (SOFT_SCRATCH_0)
- * Return true if it contains a response rather than a command
- */
-static inline bool guc_recv(struct drm_i915_private *dev_priv, u32 *status)
-{
- u32 val = I915_READ(SOFT_SCRATCH(0));
- *status = val;
- return INTEL_GUC_RECV_IS_RESPONSE(val);
-}
-
-static int guc_send(struct intel_guc *guc, u32 *data, u32 len)
-{
- struct drm_i915_private *dev_priv = guc_to_i915(guc);
- u32 status;
- int i;
- int ret;
-
- if (WARN_ON(len < 1 || len > 15))
- return -EINVAL;
-
- mutex_lock(&guc->send_mutex);
- intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
-
- dev_priv->guc.action_count += 1;
- dev_priv->guc.action_cmd = data[0];
-
- for (i = 0; i < len; i++)
- I915_WRITE(SOFT_SCRATCH(i), data[i]);
-
- POSTING_READ(SOFT_SCRATCH(i - 1));
-
- I915_WRITE(GUC_SEND_INTERRUPT, GUC_SEND_TRIGGER);
-
- /*
-* Fast commands should complete in less than 10us, so sample quickly
-* up to that length of time, then switch to a slower sleep-wait loop.
-* No INTEL_GUC_ACTION command should ever take longer than 10ms.
-*/
- ret = wait_for_us(guc_recv(dev_priv, &status), 10);
- if (ret)
- ret = wait_for(guc_recv(dev_priv, &status), 10);
- if (status != INTEL_GUC_STATUS_SUCCESS) {
- /*
-* Either the GuC explicitly returned an error (which
-* we convert to -EIO here) or no response at all was
-* received within the timeout limit (-ETIMEDOUT)
-*/
- if (ret != -ETIMEDOUT)
- ret = -EIO;
-
- DRM_WARN("Action 0x%X failed; ret=%d status=0x%08X
response=0x%08X\n",
-data[0], ret, status, I915_READ(SOFT_SCRATCH(15)));
-
- dev_priv->guc.action_fail += 1;
- dev_priv->guc.action_err = ret;
- }
- dev_priv->guc.action_status = status;
-
- intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
- mutex_unlock(&guc->send_mutex);
-
- return ret;
-}
-
-/*
* Tell the GuC to allocate or deallocate a specific doorbell
*/
static int guc_allocate_doorbell(struct intel_guc *guc,
struct i915_guc_client *client)
{
- u32 data[2];
+ u32 action[] = {
+ INTEL_GUC_ACTION_ALLOCATE_DOORBELL,
+ client->ctx_index
+ };
- data[0] = INTEL_GUC_ACTION_ALLOCATE_DOORBELL;
- data[1] = client->ctx_index;
-
- return guc_send(guc, data, 2);
+ return intel_guc_send(guc, action, ARRAY_SIZE(action));
}
static int guc_release_doorbell(struct intel_guc *guc,
struct i915_guc_client *client)
{
- u32 data[2];
-
- data[0] = INTEL_GUC_ACTION_DEALLOCATE_DOORBELL;
- data[1] = client->ctx_index;
[Intel-gfx] [CI 2/5] drm/i915/guc: Drop guc2host/host2guc from names
From: Arkadiusz Hiler
To facilitate code reorganization we are renaming everything that
contains guc2host or host2guc.
host2guc_action() and host2guc_action_response() become guc_send()
and guc_recv() respectively.
Other host2guc_*() functions become simply guc_*().
Other entities are renamed basing on context they appear in:
- HOST2GUC_ACTIONS_& become INTEL_GUC_ACTION_*
- HOST2GUC_{INTERRUPT,TRIGGER} become GUC_SEND_{INTERRUPT,TRIGGER}
- GUC2HOST_STATUS_*become INTEL_GUC_STATUS_*
- GUC2HOST_MSG_* become INTEL_GUC_RECV_MSG_*
- action_lock becomes send_mutex
v2: drop unnecessary backslashes and use BIT() instead of '<<'
v3: shortened enum names and INTEL_GUC_STATUS_*
Cc: Chris Wilson
Cc: Michal Winiarski
Signed-off-by: Arkadiusz Hiler
Link:
http://patchwork.freedesktop.org/patch/msgid/1480096777-12573-3-git-send-email-arkadiusz.hi...@intel.com
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_guc_reg.h| 4 +-
drivers/gpu/drm/i915/i915_guc_submission.c | 91 +++---
drivers/gpu/drm/i915/i915_irq.c| 4 +-
drivers/gpu/drm/i915/intel_guc_fwif.h | 46 +++
drivers/gpu/drm/i915/intel_uc.h| 6 +-
5 files changed, 75 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h
b/drivers/gpu/drm/i915/i915_guc_reg.h
index a47e1e4aec03..5e638fc37208 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -100,8 +100,8 @@
GUC_ENABLE_READ_CACHE_FOR_WOPCM_DATA | \
GUC_ENABLE_MIA_CLOCK_GATING)
-#define HOST2GUC_INTERRUPT _MMIO(0xc4c8)
-#define HOST2GUC_TRIGGER (1<<0)
+#define GUC_SEND_INTERRUPT _MMIO(0xc4c8)
+#define GUC_SEND_TRIGGER (1<<0)
#define GEN8_DRBREGL(x)_MMIO(0x1000 + (x) * 8)
#define GEN8_DRB_VALID (1<<0)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index e14220e961e5..69eba03b9823 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -49,7 +49,7 @@
* Firmware writes a success/fail code back to the action register after
* processes the request. The kernel driver polls waiting for this update and
* then proceeds.
- * See host2guc_action()
+ * See guc_send()
*
* Doorbells:
* Doorbells are interrupts to uKernel. A doorbell is a single cache line (QW)
@@ -69,15 +69,14 @@
* Read GuC command/status register (SOFT_SCRATCH_0)
* Return true if it contains a response rather than a command
*/
-static inline bool host2guc_action_response(struct drm_i915_private *dev_priv,
- u32 *status)
+static inline bool guc_recv(struct drm_i915_private *dev_priv, u32 *status)
{
u32 val = I915_READ(SOFT_SCRATCH(0));
*status = val;
- return GUC2HOST_IS_RESPONSE(val);
+ return INTEL_GUC_RECV_IS_RESPONSE(val);
}
-static int host2guc_action(struct intel_guc *guc, u32 *data, u32 len)
+static int guc_send(struct intel_guc *guc, u32 *data, u32 len)
{
struct drm_i915_private *dev_priv = guc_to_i915(guc);
u32 status;
@@ -87,7 +86,7 @@ static int host2guc_action(struct intel_guc *guc, u32 *data,
u32 len)
if (WARN_ON(len < 1 || len > 15))
return -EINVAL;
- mutex_lock(&guc->action_lock);
+ mutex_lock(&guc->send_mutex);
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
dev_priv->guc.action_count += 1;
@@ -98,17 +97,17 @@ static int host2guc_action(struct intel_guc *guc, u32
*data, u32 len)
POSTING_READ(SOFT_SCRATCH(i - 1));
- I915_WRITE(HOST2GUC_INTERRUPT, HOST2GUC_TRIGGER);
+ I915_WRITE(GUC_SEND_INTERRUPT, GUC_SEND_TRIGGER);
/*
* Fast commands should complete in less than 10us, so sample quickly
* up to that length of time, then switch to a slower sleep-wait loop.
-* No HOST2GUC command should ever take longer than 10ms.
+* No INTEL_GUC_ACTION command should ever take longer than 10ms.
*/
- ret = wait_for_us(host2guc_action_response(dev_priv, &status), 10);
+ ret = wait_for_us(guc_recv(dev_priv, &status), 10);
if (ret)
- ret = wait_for(host2guc_action_response(dev_priv, &status), 10);
- if (status != GUC2HOST_STATUS_SUCCESS) {
+ ret = wait_for(guc_recv(dev_priv, &status), 10);
+ if (status != INTEL_GUC_STATUS_SUCCESS) {
/*
* Either the GuC explicitly returned an error (which
* we convert to -EIO here) or no response at all was
@@ -126,7 +125,7 @@ static int host2guc_action(struct intel_guc *guc, u32
*data, u32 len)
dev_priv->guc.action_status = status;
intel_uncore_for
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/3] drm/i915/gen6+: Clear upper data byte during PCODE write
== Series Details == Series: series starting with [v3,1/3] drm/i915/gen6+: Clear upper data byte during PCODE write URL : https://patchwork.freedesktop.org/series/16028/ State : failure == Summary == Series 16028v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/16028/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-a: dmesg-warn -> PASS (fi-ilk-650) Subgroup suspend-read-crc-pipe-a: pass -> DMESG-WARN (fi-skl-6700hq) Test kms_setmode: Subgroup basic-clone-single-crtc: pass -> INCOMPLETE (fi-skl-6700k) fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6700k total:210 pass:188 dwarn:1 dfail:0 fail:0 skip:20 fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 4d904cb07bb992d4b5f3c8b8d00ed5297b774c0c drm-tip: 2016y-11m-28d-08h-24m-29s UTC integration manifest 5202a43 drm/i915/gen9: Fix PCODE polling during SAGV disabling 7ce4e0f drm/i915/gen9: Fix PCODE polling during CDCLK change notification 73463f9 drm/i915/gen6+: Clear upper data byte during PCODE write == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3122/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i-g-t PATCH] lib: add option for running generic tests cases only
Op 28-11-16 om 10:37 schreef Abdiel Janulgue:
> Pretend to run on a non-intel machine even when running on i915.ko,
> so that we could run and gather passrate data.
> Signed-off-by: Abdiel Janulgue
> ---
> lib/drmtest.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/lib/drmtest.c b/lib/drmtest.c
> index 44abc7e..a8b75e8 100644
> --- a/lib/drmtest.c
> +++ b/lib/drmtest.c
> @@ -254,8 +254,11 @@ int __drm_open_driver(int chipset)
> continue;
>
> if (chipset & DRIVER_INTEL && is_i915_device(fd) &&
> - has_known_intel_chipset(fd))
> + has_known_intel_chipset(fd)) {
> + igt_skip_on_f(getenv("IGT_GENERIC_ONLY"),
> + "Generic tests only\n");
> return fd;
> + }
This will make the passrate worse for any driver that has DRIVER_ANY set.
>
> if (chipset & DRIVER_VC4 &&
> is_vc4_device(fd))
> @@ -415,5 +418,6 @@ int drm_open_driver_render(int chipset)
>
> void igt_require_intel(int fd)
> {
> + igt_skip_on_f(getenv("IGT_GENERIC_ONLY"), "Generic tests only\n");
> igt_require(is_i915_device(fd) && has_known_intel_chipset(fd));
> }
>
Won't it be better to only put the hack in is_i915_device only?
Some code in IGT checks that too.
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/15] drm/i915/guc: Initialise doorbell cookie to matching value
On 25/11/2016 09:30, Chris Wilson wrote: Set the initial value of the doorbell cookie from the client. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_guc_submission.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c index 81aa5d4265c0..800dc5bb732f 100644 --- a/drivers/gpu/drm/i915/i915_guc_submission.c +++ b/drivers/gpu/drm/i915/i915_guc_submission.c @@ -247,8 +247,8 @@ static int guc_update_doorbell_id(struct intel_guc *guc, /* Activate the new doorbell */ __set_bit(new_id, doorbell_bitmap); - doorbell->cookie = 0; doorbell->db_status = GUC_DOORBELL_ENABLED; + doorbell->cookie = client->doorbell_cookie; return host2guc_allocate_doorbell(guc, client); } I assume this is to enable the following patch where the cookie starts being preserved? It appears no change to me when looked just to this point. On that basis it looks fine to let it in. Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: drop the struct_mutex when wedged or trying to reset
On ma, 2016-11-28 at 13:40 +0200, Jani Nikula wrote:
> > On Mon, 28 Nov 2016, Joonas Lahtinen
> > wrote:
> >
> > Cc: stable # v4.6 ?
>
> $ dim fixes 7f1847ebf48b
> Fixes: 7f1847ebf48b ("drm/i915: Simplify checking of GPU reset_counter in
> display pageflips")
> Cc: Chris Wilson
> Cc: Daniel Vetter
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: intel-gfx@lists.freedesktop.org
> Cc: # v4.7+
>
The last tag I have with the DIM setup after updating to drm-tip
compliant structure is v4.6-rc1, maybe the Torvalds remote should be
automated to make sure dim-fixes works (or at least warn if the oldest
tag is too old?).
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/debugfs: add dp mst info
From: Libin Yang
Add the DP MST info dump in debugfs.
Signed-off-by: Libin Yang
Signed-off-by: Dhinakaran Pandiyan
Reviewed-by: Lyude
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_debugfs.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e7f731f..f5f88b2 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2877,6 +2877,20 @@ static void intel_dp_info(struct seq_file *m,
&intel_dp->aux);
}
+static void intel_dp_mst_info(struct seq_file *m,
+ struct intel_connector *intel_connector)
+{
+ struct intel_encoder *intel_encoder = intel_connector->encoder;
+ struct intel_dp_mst_encoder *intel_mst =
+ enc_to_mst(&intel_encoder->base);
+ struct intel_digital_port *intel_dig_port = intel_mst->primary;
+ struct intel_dp *intel_dp = &intel_dig_port->dp;
+ bool has_audio = drm_dp_mst_port_has_audio(&intel_dp->mst_mgr,
+ intel_connector->port);
+
+ seq_printf(m, "\taudio support: %s\n", yesno(has_audio));
+}
+
static void intel_hdmi_info(struct seq_file *m,
struct intel_connector *intel_connector)
{
@@ -2919,7 +2933,10 @@ static void intel_connector_info(struct seq_file *m,
switch (connector->connector_type) {
case DRM_MODE_CONNECTOR_DisplayPort:
case DRM_MODE_CONNECTOR_eDP:
- intel_dp_info(m, intel_connector);
+ if (intel_encoder->type == INTEL_OUTPUT_DP_MST)
+ intel_dp_mst_info(m, intel_connector);
+ else
+ intel_dp_info(m, intel_connector);
break;
case DRM_MODE_CONNECTOR_LVDS:
if (intel_encoder->type == INTEL_OUTPUT_LVDS)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: abstract ddi being audio enabled
From: Libin Yang
Prepare for using the same code for judging ddi being audio enabled.
No functional changes.
Signed-off-by: Libin Yang
Signed-off-by: Dhinakaran Pandiyan
Reviewed-by: Lyude
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_ddi.c | 20 +++-
drivers/gpu/drm/i915/intel_drv.h | 2 ++
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0d680da..e5410be 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1950,6 +1950,19 @@ void intel_ddi_prepare_link_retrain(struct intel_dp
*intel_dp)
udelay(600);
}
+bool intel_ddi_is_audio_enabled(struct drm_i915_private *dev_priv,
+struct intel_crtc *intel_crtc)
+{
+ u32 temp;
+
+ if (intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_AUDIO)) {
+ temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
+ if (temp & AUDIO_OUTPUT_ENABLE(intel_crtc->pipe))
+ return true;
+ }
+ return false;
+}
+
void intel_ddi_get_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config)
{
@@ -2015,11 +2028,8 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
break;
}
- if (intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_AUDIO)) {
- temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
- if (temp & AUDIO_OUTPUT_ENABLE(intel_crtc->pipe))
- pipe_config->has_audio = true;
- }
+ pipe_config->has_audio =
+ intel_ddi_is_audio_enabled(dev_priv, intel_crtc);
if (encoder->type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.bpp &&
pipe_config->pipe_bpp > dev_priv->vbt.edp.bpp) {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9bbe5c5..9346660 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1175,6 +1175,8 @@ bool intel_ddi_pll_select(struct intel_crtc *crtc,
void intel_ddi_set_pipe_settings(struct drm_crtc *crtc);
void intel_ddi_prepare_link_retrain(struct intel_dp *intel_dp);
bool intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector);
+bool intel_ddi_is_audio_enabled(struct drm_i915_private *dev_priv,
+struct intel_crtc *intel_crtc);
void intel_ddi_get_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config);
struct intel_encoder *
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: enable dp mst audio
From: Libin Yang
This patch adds support for DP MST audio in i915.
Enable audio codec when DP MST is enabled if has_audio flag is set.
Disable audio codec when DP MST is disabled if has_audio flag is set.
Another separated patches to support DP MST audio will be implemented
in audio driver.
This patch is ported from
commit 3708d5e082c3 ("drm/i915: start adding dp mst audio")
And because commit 3708d5e082c3 ("drm/i915: start adding dp mst audio")
breaks MST multi-monitor setups on some platforms, the orignal patch is
reverted by
commit be754b101f70 ("Revert "drm/i915: start adding dp mst audio"")
As the multi-monitor setups issue is fixed, let's port the patch and
enable the dp mst audio.
Signed-off-by: Libin Yang
Cc: Lyude
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/intel_dp_mst.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index b029d10..1f98757f 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -37,6 +37,8 @@ static bool intel_dp_mst_compute_config(struct intel_encoder
*encoder,
struct intel_dp_mst_encoder *intel_mst = enc_to_mst(&encoder->base);
struct intel_digital_port *intel_dig_port = intel_mst->primary;
struct intel_dp *intel_dp = &intel_dig_port->dp;
+ struct intel_connector *connector =
+ to_intel_connector(conn_state->connector);
struct drm_atomic_state *state;
int bpp;
int lane_count, slots;
@@ -58,6 +60,8 @@ static bool intel_dp_mst_compute_config(struct intel_encoder
*encoder,
state = pipe_config->base.state;
+ if (drm_dp_mst_port_has_audio(&intel_dp->mst_mgr, connector->port))
+ pipe_config->has_audio = true;
mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
pipe_config->pbn = mst_pbn;
@@ -83,6 +87,7 @@ static void intel_mst_disable_dp(struct intel_encoder
*encoder,
struct intel_dp *intel_dp = &intel_dig_port->dp;
struct intel_connector *connector =
to_intel_connector(old_conn_state->connector);
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
int ret;
DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
@@ -93,6 +98,10 @@ static void intel_mst_disable_dp(struct intel_encoder
*encoder,
if (ret) {
DRM_ERROR("failed to update payload %d\n", ret);
}
+ if (old_crtc_state->has_audio) {
+ intel_audio_codec_disable(encoder);
+ intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO);
+ }
}
static void intel_mst_post_disable_dp(struct intel_encoder *encoder,
@@ -205,6 +214,10 @@ static void intel_mst_enable_dp(struct intel_encoder
*encoder,
ret = drm_dp_check_act_status(&intel_dp->mst_mgr);
ret = drm_dp_update_payload_part2(&intel_dp->mst_mgr);
+ if (pipe_config->has_audio) {
+ intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
+ intel_audio_codec_enable(encoder, pipe_config, conn_state);
+ }
}
static bool intel_dp_mst_enc_get_hw_state(struct intel_encoder *encoder,
@@ -227,6 +240,9 @@ static void intel_dp_mst_enc_get_config(struct
intel_encoder *encoder,
enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
u32 temp, flags = 0;
+ pipe_config->has_audio =
+ intel_ddi_is_audio_enabled(dev_priv, crtc);
+
temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (temp & TRANS_DDI_PHSYNC)
flags |= DRM_MODE_FLAG_PHSYNC;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for GuC code reorganization (rev7)
== Series Details ==
Series: GuC code reorganization (rev7)
URL : https://patchwork.freedesktop.org/series/15896/
State : success
== Summary ==
Series 15896v7 GuC code reorganization
https://patchwork.freedesktop.org/api/1.0/series/15896/revisions/7/mbox/
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a:
dmesg-warn -> PASS (fi-ilk-650)
fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15
fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40
fi-bxt-t5700 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28
fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28
fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32
fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20
fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20
fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53
fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22
fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22
fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22
fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14
fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21
fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21
fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14
fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32
fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33
4d904cb07bb992d4b5f3c8b8d00ed5297b774c0c drm-tip: 2016y-11m-28d-08h-24m-29s UTC
integration manifest
983d62f drm/i915/guc: Remove spurious include
a22e8ac drm/i915/guc: Init send_mutex in intel_uc_init_early()
1ea7b6c drm/i915/guc: Move guc_{send, recv}() to intel_uc.c
c7e9cb42 drm/i915/guc: Drop guc2host/host2guc from names
0f702d6 drm/i915: Rename intel_guc.h to intel_uc.h
== Logs ==
For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3123/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/15] drm/i915: Trim i915_guc_info() stack usage
On 28/11/2016 11:35, Chris Wilson wrote:
On Mon, Nov 28, 2016 at 11:15:27AM +, Tvrtko Ursulin wrote:
On 25/11/2016 09:30, Chris Wilson wrote:
i915_guc_info() (part of debugfs output) tries to avoid holding
struct_mutex for a long period by copying onto the stack. This causes a
warning that the stack frame is massive, so stop doing that. We can even
forgo holding the struct_mutex here as that doesn't serialise the values
being read (and the lists used exist for the device lifetime).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 39 +
1 file changed, 14 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8eb8c29b7492..7676e88ae5f2 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2434,47 +2434,36 @@ static void i915_guc_client_info(struct seq_file *m,
static int i915_guc_info(struct seq_file *m, void *data)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
- struct drm_device *dev = &dev_priv->drm;
- struct intel_guc guc;
- struct i915_guc_client client = {};
+ const struct intel_guc *guc = &dev_priv->guc;
struct intel_engine_cs *engine;
enum intel_engine_id id;
- u64 total = 0;
+ u64 total;
if (!HAS_GUC_SCHED(dev_priv))
return 0;
- if (mutex_lock_interruptible(&dev->struct_mutex))
- return 0;
-
- /* Take a local copy of the GuC data, so we can dump it at leisure */
- guc = dev_priv->guc;
- if (guc.execbuf_client)
- client = *guc.execbuf_client;
So this used to print out all zeros when GuC submission is disabled.
Should we instead just skip all the counter dumping if
execbuf_client == NULL and just print "disabled" or something?
That would be the sensible escape instead of HAS_GUC_SCHED.
if (!dev_priv->guc.execbuf_client) {
seq_puts(m, "GuC scheduling %s\n",
HAS_GUC_SCHED(dev_priv) ? "disabled" : "not supported");
return 0;
}
That looks good to me. (Just printf, not puts.)
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/15] drm/i915/guc: Initialise doorbell cookie to matching value
On Mon, Nov 28, 2016 at 12:09:38PM +, Tvrtko Ursulin wrote: > > On 25/11/2016 09:30, Chris Wilson wrote: > >Set the initial value of the doorbell cookie from the client. > > > >Signed-off-by: Chris Wilson > >--- > > drivers/gpu/drm/i915/i915_guc_submission.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > >diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c > >b/drivers/gpu/drm/i915/i915_guc_submission.c > >index 81aa5d4265c0..800dc5bb732f 100644 > >--- a/drivers/gpu/drm/i915/i915_guc_submission.c > >+++ b/drivers/gpu/drm/i915/i915_guc_submission.c > >@@ -247,8 +247,8 @@ static int guc_update_doorbell_id(struct intel_guc *guc, > > > > /* Activate the new doorbell */ > > __set_bit(new_id, doorbell_bitmap); > >-doorbell->cookie = 0; > > doorbell->db_status = GUC_DOORBELL_ENABLED; > >+doorbell->cookie = client->doorbell_cookie; > > return host2guc_allocate_doorbell(guc, client); > > } > > > > > > I assume this is to enable the following patch where the cookie > starts being preserved? Exactly. At present, the value is zero, but when we start carrying the client over across a reset, the client's cookie persists and so we either want to reset the client of set the cookie to match the client. I choose the later as I think that is more consistent with how we ring the doorbell (by setting the expected value form the client and comparing against the current doorbell in the fw). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i-g-t PATCH] lib: add option for running generic tests cases only
On Mon, Nov 28, 2016 at 01:07:36PM +0100, Maarten Lankhorst wrote:
> Op 28-11-16 om 10:37 schreef Abdiel Janulgue:
> > Pretend to run on a non-intel machine even when running on i915.ko,
> > so that we could run and gather passrate data.
What exactly do you mean?
> > Signed-off-by: Abdiel Janulgue
> > ---
> > lib/drmtest.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/drmtest.c b/lib/drmtest.c
> > index 44abc7e..a8b75e8 100644
> > --- a/lib/drmtest.c
> > +++ b/lib/drmtest.c
> > @@ -254,8 +254,11 @@ int __drm_open_driver(int chipset)
> > continue;
> >
> > if (chipset & DRIVER_INTEL && is_i915_device(fd) &&
> > - has_known_intel_chipset(fd))
> > + has_known_intel_chipset(fd)) {
> > + igt_skip_on_f(getenv("IGT_GENERIC_ONLY"),
> > + "Generic tests only\n");
> > return fd;
> > + }
>
> This will make the passrate worse for any driver that has DRIVER_ANY set.
DRIVER_ANY being the key here. It sounds like you should argue for doing
that generic test first.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [dim PATCH] dim: fix update-branches to fetch all available nightly repos
On 11/28/2016 05:03 PM, Jani Nikula wrote:
Update all nightly repos that have a corresponding local remote.
Cc: Archit Taneja
Signed-off-by: Jani Nikula
Tested-by: Archit Taneja
---
dim | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/dim b/dim
index a709342572ab..3dd2d1dec796 100755
--- a/dim
+++ b/dim
@@ -1255,8 +1255,15 @@ function dim_update_branches
local repo remote
cd $DIM_PREFIX/$DIM_DRM_INTEL
- for remote in $DIM_DRM_INTEL_REMOTE `url_to_remote $drm_upstream_git`
origin; do
+ for repo in "${!drm_tip_repos[@]}"; do
+ url=${drm_tip_repos[$repo]}
+ if ! remote=$(url_to_remote $url 2>/dev/null); then
+ continue
+ fi
+ echo -n "Fetching $repo (local remote $remote)... "
+ # git fetch returns 128 if there's nothing to be fetched
git fetch -q $remote || true
+ echo "Done."
done
assert_repo_clean
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/5] drm/i915: Rename intel_guc.h to intel_uc.h
== Series Details ==
Series: series starting with [CI,1/5] drm/i915: Rename intel_guc.h to intel_uc.h
URL : https://patchwork.freedesktop.org/series/16034/
State : warning
== Summary ==
Series 16034v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/16034/revisions/1/mbox/
Test gem_exec_flush:
Subgroup basic-wb-set-default:
pass -> DMESG-WARN (fi-snb-2520m)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a:
dmesg-warn -> PASS (fi-ilk-650)
fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15
fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40
fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28
fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32
fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20
fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20
fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53
fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22
fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22
fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22
fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14
fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21
fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21
fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14
fi-snb-2520m total:245 pass:212 dwarn:1 dfail:0 fail:0 skip:32
fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33
4d904cb07bb992d4b5f3c8b8d00ed5297b774c0c drm-tip: 2016y-11m-28d-08h-24m-29s UTC
integration manifest
32b7b99 drm/i915/guc: Remove spurious include
0bb5e0c drm/i915/guc: Init send_mutex in intel_uc_init_early()
06a4574 drm/i915/guc: Move guc_{send, recv}() to intel_uc.c
45734cd drm/i915/guc: Drop guc2host/host2guc from names
e2ac67f drm/i915: Rename intel_guc.h to intel_uc.h
== Logs ==
For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3124/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 2/8] drm/i915/bxt: IPC WA for Broxton
Hi,
Will keep WA number in commit message/WA location.
thanks,
Regards,
-Mahesh
On Thursday 24 November 2016 06:21 PM, Lankhorst, Maarten wrote:
Mahesh Kumar schreef op do 24-11-2016 om 09:31 [+0530]:
If IPC is enabled in BXT, display underruns are observed.
WA: The Line Time programmed in the WM_LINETIME register should be
half of the actual calculated Line Time.
Programmed Line Time = 1/2*Calculated Line Time
Signed-off-by: Mahesh Kumar
Reviewed-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 2 ++
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_pm.c | 11 +--
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 445fec9..1b0a589 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1243,6 +1243,8 @@ int i915_driver_load(struct pci_dev *pdev,
const struct pci_device_id *ent)
intel_runtime_pm_enable(dev_priv);
+ dev_priv->ipc_enabled = false;
+
/* Everything is in place, we can now relax! */
DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
driver.name, driver.major, driver.minor,
driver.patchlevel,
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 63c0ea0..6691a4e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2128,6 +2128,8 @@ struct drm_i915_private {
/* perform PHY state sanity checks? */
bool chv_phy_assert[2];
+ bool ipc_enabled;
+
/* Used to save the pipe-to-encoder mapping for audio */
struct intel_encoder *av_enc_map[I915_MAX_PIPES];
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 8908736..7090a7c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3769,7 +3769,10 @@ skl_compute_wm_level(const struct
drm_i915_private *dev_priv,
static uint32_t
skl_compute_linetime_wm(struct intel_crtc_state *cstate)
{
+ struct drm_atomic_state *state = cstate->base.state;
+ struct drm_i915_private *dev_priv = to_i915(state->dev);
uint32_t pixel_rate;
+ uint32_t linetime_wm;
if (!cstate->base.active)
return 0;
@@ -3779,8 +3782,12 @@ skl_compute_linetime_wm(struct
intel_crtc_state *cstate)
if (WARN_ON(pixel_rate == 0))
return 0;
- return DIV_ROUND_UP(8 * cstate-
base.adjusted_mode.crtc_htotal * 1000,
- pixel_rate);
+ linetime_wm = DIV_ROUND_UP(8 * cstate-
base.adjusted_mode.crtc_htotal *
+ 1000, pixel_rate);
+ if (IS_BROXTON(dev_priv) && dev_priv->ipc_enabled)
+ linetime_wm = DIV_ROUND_UP(linetime_wm, 2);
I've asked on irc to be sure, but this needs slightly more info in the
code as well. Same for 3/8 and 8/8.
12:47 < mlankhorst> danvet: if we add hw workarounds that don't have a
name, do we still have to write comments about them in the code?
12:48 < danvet> at least a bspec reference
12:48 < danvet> some hint to make it possible to find where it's from
12:49 < danvet> e.g. mesa has traditionally just pasted the entire
bspec paragraph
12:49 < mlankhorst> ok
12:49 < danvet> we've done that too in the past, but then the wa db
mostly made that redundant
12:49 < danvet> but if there's no wa entry, then full deal
12:49 < danvet> also, maybe a bspec bug notice to pls add one
12:49 < danvet> you should be able to do that over the web, and afaik
there should be one for every w/a
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/5] drm/i915: Rename intel_guc.h to intel_uc.h
On Mon, Nov 28, 2016 at 12:53:27PM +, Patchwork wrote: > == Series Details == > > Series: series starting with [CI,1/5] drm/i915: Rename intel_guc.h to > intel_uc.h > URL : https://patchwork.freedesktop.org/series/16034/ > State : warning > > == Summary == > > Series 16034v1 Series without cover letter > https://patchwork.freedesktop.org/api/1.0/series/16034/revisions/1/mbox/ > > Test gem_exec_flush: > Subgroup basic-wb-set-default: > pass -> DMESG-WARN (fi-snb-2520m) [ 234.675075] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe B (start=13543 end=13544) time 159 us, min 1073, max 1079, scanline start 1061, end 1080 Quite possibly: https://bugs.freedesktop.org/show_bug.cgi?id=91883 > Test kms_pipe_crc_basic: > Subgroup nonblocking-crc-pipe-a: > dmesg-warn -> PASS (fi-ilk-650) Was: [ 331.407848] [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun (Which we see quite ofeten here.) Definately not caused by the change. > == Logs == > > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3124/ > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Cheers, Arek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Enable HPD interrupts with master ctl interrupt
On 11/23/2016 10:31 PM, Imre Deak wrote:
On Wed, 2016-11-23 at 21:48 +0530, Animesh Manna wrote:
While suspending the device hpd related interrupts are enabled
to get the interrupt when device is in suspend state.
Though display is in DC9 but system can be in S0 or S0i3 state.
Hot plug during S0 state will generate de_port_interrupt but if
system is in S0i3 state then display driver will get hotplug
interrupt as pcu_hpd_interrupt which will come via pmc. So
added the interrupt handling for pcu hpd interrupt.
Signed-off-by: Animesh Manna
Signed-off-by: A.Sunil Kamath
---
drivers/gpu/drm/i915/i915_irq.c | 56 ++---
drivers/gpu/drm/i915/i915_reg.h | 12 +
2 files changed, 65 insertions(+), 3 deletions(-)
mode change 100644 => 100755 drivers/gpu/drm/i915/i915_irq.c
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
old mode 100644
new mode 100755
index cb8a75f..2f9b604
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -110,9 +110,9 @@
/* BXT hpd list */
static const u32 hpd_bxt[HPD_NUM_PINS] = {
- [HPD_PORT_A] = BXT_DE_PORT_HP_DDIA,
- [HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
- [HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
+ [HPD_PORT_A] = (BXT_DE_PORT_HP_DDIA | BXT_PCU_DC9_HP_DDIA),
+ [HPD_PORT_B] = (BXT_DE_PORT_HP_DDIB | BXT_PCU_DC9_HP_DDIB),
+ [HPD_PORT_C] = (BXT_DE_PORT_HP_DDIC | BXT_PCU_DC9_HP_DDIC)
These are bits programmed to GEN8_DE_PORT_*, so adding the PCU bits
here is bogus.
Thanks Imre for review. I understood the "hpd_bxt" array is to store all
bits which validate hpd interrupt in irq_handler from the respective port.
Previously only from DE_PORT interrupt used to come and after
implementing HPD as wake feature interrupt source will be both DE_PORT
and PCU.
So added pcu related bits in the same array.
Do you want two different array for DE_PORT and PCU. I can do it by
creating a new array named "hpd_bxt_pcu" and change the existing one as
"hpd_bxt_de".
Please let me know your suggestion.
};
/* IIR can theoretically queue up two events. Be paranoid. */
@@ -2463,6 +2463,24 @@ static void bxt_hpd_irq_handler(struct drm_i915_private
*dev_priv,
DRM_ERROR("The master control interrupt lied (DE
PORT)!\n");
}
+ if (master_ctl & GEN8_PCU_IRQ) {
+ iir = I915_READ(GEN8_PCU_IIR);
+ if (iir) {
+ u32 tmp_mask;
+
+ I915_WRITE(GEN8_PCU_IIR, iir);
+ ret = IRQ_HANDLED;
+ if (IS_BROXTON(dev_priv)) {
+ tmp_mask = iir & BXT_PCU_DC9_HOTPLUG_MASK;
+ if (tmp_mask)
+ bxt_hpd_irq_handler(dev_priv, tmp_mask,
+ hpd_bxt);
+ } else
+ DRM_ERROR("Unexpected PCU interrupt\n");
+ } else
+ DRM_ERROR("The master control interrupt lied (PCU)!\n");
+ }
+
for_each_pipe(dev_priv, pipe) {
u32 flip_done, fault_errors;
@@ -4294,6 +4312,19 @@ void intel_irq_uninstall(struct drm_i915_private *dev_priv)
dev_priv->pm.irqs_enabled = false;
}
+static void bxt_enable_pcu_interrupt(struct drm_i915_private *dev_priv)
+{
+ u32 de_pcu_hpd_enable_mask, de_pcu_imr, de_pcu_ier;
+
+ de_pcu_hpd_enable_mask = GEN9_DE_PCU_PORTA_HOTPLUG |
+ GEN9_DE_PCU_PORTB_HOTPLUG |
+ GEN9_DE_PCU_PORTC_HOTPLUG;
+
+ de_pcu_imr = (I915_READ(GEN8_PCU_IMR) & 0x0);
Typo.
Will remove "de" tag from all pcu related variables, for anything else
let me know.
GEN8 and GEN9 is using same pcu interrupt registers so used the same
macro "GEN8_PCU_IMR".
+ de_pcu_ier = (I915_READ(GEN8_PCU_IER) | de_pcu_hpd_enable_mask);
+ GEN5_IRQ_INIT(GEN8_PCU_, de_pcu_imr, de_pcu_ier);
+}
+
/**
* intel_runtime_pm_disable_interrupts - runtime interrupt disabling
* @dev_priv: i915 device instance
@@ -4303,8 +4334,27 @@ void intel_irq_uninstall(struct drm_i915_private
*dev_priv)
*/
void intel_runtime_pm_disable_interrupts(struct drm_i915_private *dev_priv)
{
+ unsigned long flags = 0;
+
dev_priv->drm.driver->irq_uninstall(&dev_priv->drm);
dev_priv->pm.irqs_enabled = false;
+
+ if (IS_BROXTON(dev_priv) && dev_priv->vbt.hpd_wakeup_enabled) {
+
+ /* Enable HPD related interrupts during DC9 for HPD wakeup */
+
+ I915_WRITE(GEN8_MASTER_IRQ, GEN8_MASTER_IRQ_CONTROL);
+ POSTING_READ(GEN8_MASTER_IRQ);
+
+ spin_lock_irqsave(&dev_priv->irq_lock, flags);
+ if (dev_priv->display.hpd_irq_setup)
+ dev_priv->display.hpd_irq_setup(dev_priv);
+ spin_unlock_irqrestore(&dev_priv->irq_lock, fla
Re: [Intel-gfx] [alsa-devel] [RFC PATCH v3 1/7] drm/i915: setup bridge for HDMI LPE audio driver
On Sun, Nov 27, 2016 at 12:20:30PM -0600, Pierre-Louis Bossart wrote:
> On 11/24/16 7:31 AM, Ville Syrjälä wrote:
> >> +static void lpe_audio_irq_unmask(struct irq_data *d)
> >> +{
> >> + struct drm_device *dev = d->chip_data;
> >> + struct drm_i915_private *dev_priv = to_i915(dev);
> >> + unsigned long irqflags;
> >> + u32 val = (I915_LPE_PIPE_A_INTERRUPT |
> >> + I915_LPE_PIPE_B_INTERRUPT |
> >> + I915_LPE_PIPE_C_INTERRUPT);
> > No pipe C on vlv.
>
> Yes but does it hurt to set this bit? If the hardware is not present
> then there is no side effect, is there?
I'm too lazy to check if the bit is already taken.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/15] drm/i915/guc: Keep the execbuf client allocated across reset
On 25/11/2016 09:30, Chris Wilson wrote:
In order to avoid some complexity in trying to reconstruct the
workqueues across reset, remember them instead. The issue comes when we
have to handle a reset between request allocation and submission, the
request has reserved space in the wq, but is not in any list so we fail
to restore the reserved space. By keeping the execbuf client intact
across the reset, we also keep the reservations.
I lost track a bit on why do we need to reserve the space at request
creation time? Is it not becoming a bit cumbersome?
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_guc_submission.c | 83 +++---
1 file changed, 52 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 800dc5bb732f..00b5fa871644 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -252,13 +252,6 @@ static int guc_update_doorbell_id(struct intel_guc *guc,
return host2guc_allocate_doorbell(guc, client);
}
-static int guc_init_doorbell(struct intel_guc *guc,
- struct i915_guc_client *client,
- uint16_t db_id)
-{
- return guc_update_doorbell_id(guc, client, db_id);
-}
-
static void guc_disable_doorbell(struct intel_guc *guc,
struct i915_guc_client *client)
{
@@ -779,8 +772,7 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
uint16_t db_id;
int i, err;
- /* Save client's original doorbell selection */
- db_id = client->doorbell_id;
+ guc_disable_doorbell(guc, client);
for (i = 0; i < GUC_MAX_DOORBELLS; ++i) {
/* Skip if doorbell is OK */
@@ -793,7 +785,9 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
i, err);
}
- /* Restore to original value */
+ db_id = select_doorbell_register(guc, client->priority);
+ WARN_ON(db_id == GUC_INVALID_DOORBELL_ID);
+
err = guc_update_doorbell_id(guc, client, db_id);
if (err)
DRM_WARN("Failed to restore doorbell to %d, err %d\n",
@@ -883,8 +877,13 @@ guc_client_alloc(struct drm_i915_private *dev_priv,
guc_proc_desc_init(guc, client);
guc_ctx_desc_init(guc, client);
- if (guc_init_doorbell(guc, client, db_id))
- goto err;
+
+ /* For runtime client allocation we need to enable the doorbell. Not
+* required yet for the static execbuf_client as this special kernel
+* client is enabled from i915_guc_submission_enable().
+*
+* guc_update_doorbell_id(guc, client, db_id);
+*/
What future is the "not yet" part referring to? What are the other clients?
DRM_DEBUG_DRIVER("new priority %u client %p for engine(s) 0x%x: ctx_index
%u\n",
priority, client, client->engines, client->ctx_index);
@@ -1484,6 +1483,9 @@ int i915_guc_submission_init(struct drm_i915_private
*dev_priv)
struct intel_guc *guc = &dev_priv->guc;
struct i915_vma *vma;
+ if (!HAS_GUC_SCHED(dev_priv))
+ return 0;
Why did you have to add this hunk? I think this function does not get
called unless there is a GuC.
+
/* Wipe bitmap & delete client in case of reinitialisation */
bitmap_clear(guc->doorbell_bitmap, 0, GUC_MAX_DOORBELLS);
i915_guc_submission_disable(dev_priv);
@@ -1504,42 +1506,57 @@ int i915_guc_submission_init(struct drm_i915_private
*dev_priv)
guc_log_create(guc);
guc_addon_create(guc);
+ guc->execbuf_client = guc_client_alloc(dev_priv,
+ INTEL_INFO(dev_priv)->ring_mask,
+ GUC_CTX_PRIORITY_KMD_NORMAL,
+ dev_priv->kernel_context);
+ if (!guc->execbuf_client) {
+ DRM_ERROR("Failed to create GuC client for execbuf!\n");
+ goto err;
+ }
+
return 0;
+
+err:
+ i915_guc_submission_fini(dev_priv);
+ return -ENOMEM;
+}
+
+static void guc_reset_wq(struct i915_guc_client *gc)
+{
+ struct guc_process_desc *desc = gc->vaddr + gc->proc_desc_offset;
+
+ desc->head = 0;
+ desc->tail = 0;
+
+ gc->wq_tail = 0;
}
int i915_guc_submission_enable(struct drm_i915_private *dev_priv)
{
struct intel_guc *guc = &dev_priv->guc;
- struct drm_i915_gem_request *request;
- struct i915_guc_client *client;
+ struct i915_guc_client *client = guc->execbuf_client;
struct intel_engine_cs *engine;
enum intel_engine_id id;
- /* client for execbuf submission */
- client = guc_client_alloc(dev_priv,
- INTEL_INFO(dev_priv)->ring_mask,
- GUC_CTX_PRIORITY_KMD_NORMAL,
Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/gen9: Fix PCODE polling during CDCLK change notification
On Mon, Nov 28, 2016 at 01:12:57PM +0200, Imre Deak wrote:
> commit 848496e5902833600f7992f4faa82dc1546051ba
> Author: Ville Syrjälä
> Date: Wed Jul 13 16:32:03 2016 +0300
>
> drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on
> SKL
>
> increased the timeout to match the spec, but we still see a timeout on
> at least one SKL. A CDCLK change request following the failed one will
> succeed nevertheless.
>
> I could reproduce this problem easily by running kms_pipe_crc_basic in a
> loop. In all failure cases _wait_for() was pre-empted for >3ms and so in
> the worst case - when the pre-emption happened right after calculating
> timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only
> once which failed and so _wait_for() timed out. As opposed to this the
> spec says to keep retrying the request for at most a 3ms period.
>
> To fix this disable pre-emption to maximize the number of times we retry
> the request. Also increase the timeout to 10ms to account for interrupts
> that could reduce the number of these attempts. With this change I
> couldn't trigger the problem.
>
> v2:
> - Use 1ms poll period instead of 10us. (Chris)
> v3:
> - Poll with pre-emption disabled to increase the number of request
> attempts. (Ville, Chris)
> - Factor out a helper to poll, it's also needed by the next patch.
>
> Cc: Ville Syrjälä
> Cc: Chris Wilson
> Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929
> Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_reg.h | 2 +-
> drivers/gpu/drm/i915/intel_display.c | 29 +++-
> drivers/gpu/drm/i915/intel_pm.c | 43
>
> 4 files changed, 53 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 01f5067..f618807 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3593,6 +3593,7 @@ extern void intel_display_print_error_state(struct
> drm_i915_error_state_buf *e,
>
> int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox, u32
> *val);
> int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u32 mbox, u32
> val);
> +int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32
> request);
>
> /* intel_sideband.c */
> u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 6747d68..f542cbc 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7424,7 +7424,6 @@ enum {
> #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT 24
> #define SKL_PCODE_CDCLK_CONTROL0x7
> #define SKL_CDCLK_PREPARE_FOR_CHANGE 0x3
> -#define SKL_CDCLK_READY_FOR_CHANGE 0x1
> #define GEN6_PCODE_WRITE_MIN_FREQ_TABLE0x8
> #define GEN6_PCODE_READ_MIN_FREQ_TABLE 0x9
> #define GEN6_READ_OC_PARAMS0xc
> @@ -7437,6 +7436,7 @@ enum {
> #define GEN9_SAGV_DISABLE0x0
> #define GEN9_SAGV_IS_DISABLED0x1
> #define GEN9_SAGV_ENABLE 0x3
> +#define GEN9_PCODE_REQUEST_DONE0x1
Is that really a generic thing?
> #define GEN6_PCODE_DATA _MMIO(0x138128)
> #define GEN6_PCODE_FREQ_IA_RATIO_SHIFT 8
> #define GEN6_PCODE_FREQ_RING_RATIO_SHIFT 16
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 5d11002..46c0e42 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6245,35 +6245,22 @@ skl_dpll0_disable(struct drm_i915_private *dev_priv)
> dev_priv->cdclk_pll.vco = 0;
> }
>
> -static bool skl_cdclk_pcu_ready(struct drm_i915_private *dev_priv)
> -{
> - int ret;
> - u32 val;
> -
> - /* inform PCU we want to change CDCLK */
> - val = SKL_CDCLK_PREPARE_FOR_CHANGE;
> - mutex_lock(&dev_priv->rps.hw_lock);
> - ret = sandybridge_pcode_read(dev_priv, SKL_PCODE_CDCLK_CONTROL, &val);
> - mutex_unlock(&dev_priv->rps.hw_lock);
> -
> - return ret == 0 && (val & SKL_CDCLK_READY_FOR_CHANGE);
> -}
> -
> -static bool skl_cdclk_wait_for_pcu_ready(struct drm_i915_private *dev_priv)
> -{
> - return _wait_for(skl_cdclk_pcu_ready(dev_priv), 3000, 10) == 0;
> -}
> -
> static void skl_set_cdclk(struct drm_i915_private *dev_priv, int cdclk, int
> vco)
> {
> u32 freq_select, pcu_ack;
> + int ret;
>
> WARN_ON((cdclk == 24000) != (vco == 0));
>
> DRM_DEBUG_DRIVER("Changing CDCLK to %d kHz (VCO %d kHz)\n", cdclk, vco);
>
> - if (!skl_cdclk_wait_for_pcu_ready(dev_priv)) {
> - DRM_ERROR("failed to inform PCU about cdclk change\n");
> + mutex_lock(&dev_priv->rps.hw
Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/gen9: Fix PCODE polling during CDCLK change notification
On ma, 2016-11-28 at 15:51 +0200, Ville Syrjälä wrote:
> On Mon, Nov 28, 2016 at 01:12:57PM +0200, Imre Deak wrote:
> > commit 848496e5902833600f7992f4faa82dc1546051ba
> > Author: Ville Syrjälä
> > Date: Wed Jul 13 16:32:03 2016 +0300
> >
> > drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on
> > SKL
> >
> > increased the timeout to match the spec, but we still see a timeout on
> > at least one SKL. A CDCLK change request following the failed one will
> > succeed nevertheless.
> >
> > I could reproduce this problem easily by running kms_pipe_crc_basic in a
> > loop. In all failure cases _wait_for() was pre-empted for >3ms and so in
> > the worst case - when the pre-emption happened right after calculating
> > timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only
> > once which failed and so _wait_for() timed out. As opposed to this the
> > spec says to keep retrying the request for at most a 3ms period.
> >
> > To fix this disable pre-emption to maximize the number of times we retry
> > the request. Also increase the timeout to 10ms to account for interrupts
> > that could reduce the number of these attempts. With this change I
> > couldn't trigger the problem.
> >
> > v2:
> > - Use 1ms poll period instead of 10us. (Chris)
> > v3:
> > - Poll with pre-emption disabled to increase the number of request
> > attempts. (Ville, Chris)
> > - Factor out a helper to poll, it's also needed by the next patch.
> >
> > Cc: Ville Syrjälä
> > Cc: Chris Wilson
> > Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929
> > Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/i915_reg.h | 2 +-
> > drivers/gpu/drm/i915/intel_display.c | 29 +++-
> > drivers/gpu/drm/i915/intel_pm.c | 43
> >
> > 4 files changed, 53 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 01f5067..f618807 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -3593,6 +3593,7 @@ extern void intel_display_print_error_state(struct
> > drm_i915_error_state_buf *e,
> >
> > int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox,
> > u32 *val);
> > int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u32 mbox,
> > u32 val);
> > +int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32
> > request);
> >
> > /* intel_sideband.c */
> > u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 6747d68..f542cbc 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7424,7 +7424,6 @@ enum {
> > #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT 24
> > #define SKL_PCODE_CDCLK_CONTROL 0x7
> > #define SKL_CDCLK_PREPARE_FOR_CHANGE 0x3
> > -#define SKL_CDCLK_READY_FOR_CHANGE 0x1
> > #define GEN6_PCODE_WRITE_MIN_FREQ_TABLE 0x8
> > #define GEN6_PCODE_READ_MIN_FREQ_TABLE 0x9
> > #define GEN6_READ_OC_PARAMS 0xc
> > @@ -7437,6 +7436,7 @@ enum {
> > #define GEN9_SAGV_DISABLE 0x0
> > #define GEN9_SAGV_IS_DISABLED 0x1
> > #define GEN9_SAGV_ENABLE 0x3
> > +#define GEN9_PCODE_REQUEST_DONE 0x1
>
> Is that really a generic thing?
At least SAGV uses the same and there is no other request I know of
that would need this polling request. It will be used in the next patch
for SAGV too.
>
> > #define GEN6_PCODE_DATA_MMIO(0x138128)
> > #define GEN6_PCODE_FREQ_IA_RATIO_SHIFT 8
> > #define GEN6_PCODE_FREQ_RING_RATIO_SHIFT 16
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 5d11002..46c0e42 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -6245,35 +6245,22 @@ skl_dpll0_disable(struct drm_i915_private *dev_priv)
> > dev_priv->cdclk_pll.vco = 0;
> > }
> >
> > -static bool skl_cdclk_pcu_ready(struct drm_i915_private *dev_priv)
> > -{
> > - int ret;
> > - u32 val;
> > -
> > - /* inform PCU we want to change CDCLK */
> > - val = SKL_CDCLK_PREPARE_FOR_CHANGE;
> > - mutex_lock(&dev_priv->rps.hw_lock);
> > - ret = sandybridge_pcode_read(dev_priv, SKL_PCODE_CDCLK_CONTROL, &val);
> > - mutex_unlock(&dev_priv->rps.hw_lock);
> > -
> > - return ret == 0 && (val & SKL_CDCLK_READY_FOR_CHANGE);
> > -}
> > -
> > -static bool skl_cdclk_wait_for_pcu_ready(struct drm_i915_private *dev_priv)
> > -{
> > - return _wait_for(skl_cdclk_pcu_ready(dev_priv), 3000, 10) == 0;
> > -}
> > -
> > static void skl_set_cdclk(struct
Re: [Intel-gfx] [RFC PATCH v3 2/7] drm/i915: Add support for audio driver notifications
On Fri, Nov 25, 2016 at 05:51:00AM +, Anand, Jerome wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > Sent: Thursday, November 24, 2016 7:03 PM
> > To: Anand, Jerome
> > Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org;
> > broo...@kernel.org; ti...@suse.de; pierre-louis.boss...@linux.intel.com;
> > Ughreja, Rakesh A
> > Subject: Re: [RFC PATCH v3 2/7] drm/i915: Add support for audio driver
> > notifications
> >
> > On Fri, Nov 25, 2016 at 05:25:43AM +0530, Jerome Anand wrote:
> > > Notifiations like mode change, hot plug and edid to the audio driver
> > > are added. This is inturn used by the audio driver for its
> > > functionality.
> > >
> > > A new interface file capturing the notifications needed by the audio
> > > driver is added
> > >
> > > Signed-off-by: Pierre-Louis Bossart
> > >
> > > Signed-off-by: Jerome Anand
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.h| 3 +++
> > > drivers/gpu/drm/i915/intel_audio.c | 8 ++
> > > drivers/gpu/drm/i915/intel_hdmi.c | 1 +
> > > drivers/gpu/drm/i915/intel_lpe_audio.c | 49
> > ++
> > > include/drm/intel_lpe_audio.h | 1 +
> > > 5 files changed, 62 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h index 2a79048..33bc44c 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -3561,6 +3561,9 @@ int intel_lpe_audio_setup(struct
> > > drm_i915_private *dev_priv); void intel_lpe_audio_teardown(struct
> > > drm_i915_private *dev_priv); void intel_lpe_audio_irq_handler(struct
> > > drm_i915_private *dev_priv); bool intel_lpe_audio_detect(struct
> > > drm_i915_private *dev_priv);
> > > +void intel_lpe_audio_notify(struct drm_i915_private *dev_priv,
> > > + void *eld, int port, int tmds_clk_speed,
> > > + bool connected);
> > >
> > > /* intel_i2c.c */
> > > extern int intel_setup_gmbus(struct drm_device *dev); diff --git
> > > a/drivers/gpu/drm/i915/intel_audio.c
> > > b/drivers/gpu/drm/i915/intel_audio.c
> > > index 1c509f7..55a6831 100644
> > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > @@ -24,6 +24,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include "intel_drv.h"
> > >
> > > #include
> > > @@ -627,6 +628,10 @@ void intel_audio_codec_enable(struct
> > intel_encoder *intel_encoder,
> > > if (acomp && acomp->audio_ops && acomp->audio_ops-
> > >pin_eld_notify)
> > > acomp->audio_ops->pin_eld_notify(acomp->audio_ops-
> > >audio_ptr,
> > >(int) port, (int) pipe);
> > > +
> > > + if (HAS_LPE_AUDIO(dev_priv))
> > > + intel_lpe_audio_notify(dev_priv, connector->eld, port,
> > > + crtc_state->port_clock, true);
> > > }
> > >
> > > /**
> > > @@ -660,6 +665,9 @@ void intel_audio_codec_disable(struct
> > intel_encoder *intel_encoder)
> > > if (acomp && acomp->audio_ops && acomp->audio_ops-
> > >pin_eld_notify)
> > > acomp->audio_ops->pin_eld_notify(acomp->audio_ops-
> > >audio_ptr,
> > >(int) port, (int) pipe);
> > > +
> > > + if (HAS_LPE_AUDIO(dev_priv))
> > > + intel_lpe_audio_notify(dev_priv, NULL, port, 0, true);
> > > }
> > >
> > > /**
> > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > > b/drivers/gpu/drm/i915/intel_hdmi.c
> > > index fb88e32..02d50e3 100644
> > > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > > @@ -36,6 +36,7 @@
> > > #include
> > > #include "intel_drv.h"
> > > #include
> > > +#include
> > > #include "i915_drv.h"
> > >
> > > static struct drm_device *intel_hdmi_to_dev(struct intel_hdmi
> > > *intel_hdmi) diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c
> > > b/drivers/gpu/drm/i915/intel_lpe_audio.c
> > > index 5335fc6..93f83cb 100644
> > > --- a/drivers/gpu/drm/i915/intel_lpe_audio.c
> > > +++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
> > > @@ -367,3 +367,52 @@ void intel_lpe_audio_teardown(struct
> > > drm_i915_private *dev_priv)
> > >
> > > spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags); }
> > > +
> > > +
> > > +/**
> > > + * intel_lpe_audio_notify() - notify lpe audio event
> > > + * audio driver and i915
> > > + * @dev_priv: the i915 drm device private data
> > > + * @eld : ELD data
> > > + * @port: port id
> > > + * @tmds_clk_speed: tmds clock frequency in Hz
> > > + * @connected: hdmi connected/disconnected
> > > + *
> > > + * Notify lpe audio driver of eld change.
> > > + */
> > > +void intel_lpe_audio_notify(struct drm_i915_private *dev_priv,
> > > + void *eld, int port, int tmds_clk_speed,
> > > + bool connected)
> > > +{
> > > + unsigned long irq_flags;
> > > +
> > > + if (HAS_LPE_AUDIO(dev_priv)) {
> > > + st
Re: [Intel-gfx] [PATCH 15/15] drm/i915/guc: Split hw submission for replay after GPU reset
On 25/11/2016 09:30, Chris Wilson wrote:
Something I missed before sending off the partial series was that the
non-scheduler guc reset path was broken (in the full series, this is
pushed to the execlists reset handler). The issue is that after a reset,
we have to refill the GuC workqueues, which we do by resubmitting the
requests. However, if we already have submitted them, the fences within
them have already been used and triggering them again is an error.
Instead, just repopulate the guc workqueue.
[ 115.858560] [IGT] gem_busy: starting subtest hang-render
[ 135.839867] [drm] GPU HANG: ecode 9:0:0xe757fefe, in gem_busy [1716],
reason: Hang on render ring, action: reset
[ 135.839902] drm/i915: Resetting chip after gpu hang
[ 135.839957] [drm] RC6 on
[ 135.858351] [ cut here ]
[ 135.858357] WARNING: CPU: 2 PID: 45 at
drivers/gpu/drm/i915/i915_sw_fence.c:108 i915_sw_fence_complete+0x25/0x30
[ 135.858357] Modules linked in: rfcomm bnep binfmt_misc nls_iso8859_1
input_leds snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic
snd_hda_intel snd_hda_codec snd_hda_core btusb btrtl snd_hwdep snd_pcm 8250_dw
snd_seq_midi hid_lenovo snd_seq_midi_event snd_rawmidi iwlwifi
x86_pkg_temp_thermal coretemp snd_seq crct10dif_pclmul snd_seq_device hci_uart
snd_timer crc32_pclmul ghash_clmulni_intel idma64 aesni_intel virt_dma btbcm
snd btqca aes_x86_64 btintel lrw cfg80211 bluetooth gf128mul glue_helper
ablk_helper cryptd soundcore intel_lpss_pci intel_pch_thermal intel_lpss_acpi
intel_lpss acpi_als mfd_core kfifo_buf acpi_pad industrialio autofs4
hid_plantronics usbhid dm_mirror dm_region_hash dm_log sdhci_pci ahci sdhci
libahci i2c_hid hid
[ 135.858389] CPU: 2 PID: 45 Comm: kworker/2:1 Tainted: GW
4.9.0-rc4+ #238
[ 135.858389] Hardware name: /NUC6i3SYB, BIOS
SYSKLi35.86A.0024.2015.1027.2142 10/27/2015
[ 135.858392] Workqueue: events_long i915_hangcheck_elapsed
[ 135.858394] c91bf9b8 812bb238
[ 135.858396] c91bf9f8 8104f621 006c
8808296137f8
[ 135.858398] 0a00 8808457a 880845764e60
88084576
[ 135.858399] Call Trace:
[ 135.858403] [] dump_stack+0x4d/0x65
[ 135.858405] [] __warn+0xc1/0xe0
[ 135.858406] [] warn_slowpath_null+0x18/0x20
[ 135.858408] [] i915_sw_fence_complete+0x25/0x30
[ 135.858410] [] i915_sw_fence_commit+0xd/0x30
[ 135.858412] [] __i915_gem_request_submit+0xe1/0xf0
[ 135.858413] [] i915_gem_request_submit+0x28/0x40
[ 135.858415] [] i915_guc_submit+0x47/0x210
[ 135.858417] [] i915_guc_submission_enable+0x468/0x540
[ 135.858419] [] intel_guc_setup+0x715/0x810
[ 135.858421] [] i915_gem_init_hw+0x114/0x2a0
[ 135.858423] [] i915_reset+0xe8/0x120
[ 135.858424] [] i915_reset_and_wakeup+0x157/0x180
[ 135.858426] [] i915_handle_error+0x1ab/0x230
[ 135.858428] [] ? scnprintf+0x4d/0x90
[ 135.858430] [] i915_hangcheck_elapsed+0x275/0x3d0
[ 135.858432] [] process_one_work+0x12f/0x410
[ 135.858433] [] worker_thread+0x43/0x4d0
[ 135.858435] [] ? process_one_work+0x410/0x410
[ 135.858436] [] ? process_one_work+0x410/0x410
[ 135.858438] [] kthread+0xd4/0xf0
[ 135.858440] [] ? kthread_park+0x60/0x60
v2: Only resubmit submitted requests
v3: Don't forget the pending requests have reserved space.
Fixes: d55ac5bf97c6 ("drm/i915: Defer transfer onto execution timeline to actual hw
submission")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 37 --
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 00b5fa871644..e12ff881d38d 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -602,12 +602,9 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
}
/**
- * i915_guc_submit() - Submit commands through GuC
+ * __i915_guc_submit() - Submit commands through GuC
* @rq:request associated with the commands
*
- * Return: 0 on success, otherwise an errno.
- * (Note: nonzero really shouldn't happen!)
- *
* The caller must have already called i915_guc_wq_reserve() above with
* a result of 0 (success), guaranteeing that there is space in the work
* queue for the new request, so enqueuing the item cannot fail.
@@ -619,7 +616,7 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
* The only error here arises if the doorbell hardware isn't functioning
* as expected, which really shouln't happen.
*/
-static void i915_guc_submit(struct drm_i915_gem_request *rq)
+static void __i915_guc_submit(struct drm_i915_gem_request *rq)
{
struct drm_i915_private *dev_priv = rq->i915;
struct intel_engine_cs *engine = rq->engine;
@@ -628,17 +625,6 @@ static void i915_guc_submit(struct drm_i9
Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/gen9: Fix PCODE polling during CDCLK change notification
On Mon, Nov 28, 2016 at 03:54:08PM +0200, Imre Deak wrote:
> On ma, 2016-11-28 at 15:51 +0200, Ville Syrjälä wrote:
> > On Mon, Nov 28, 2016 at 01:12:57PM +0200, Imre Deak wrote:
> > > commit 848496e5902833600f7992f4faa82dc1546051ba
> > > Author: Ville Syrjälä
> > > Date: Wed Jul 13 16:32:03 2016 +0300
> > >
> > > drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request
> > > on SKL
> > >
> > > increased the timeout to match the spec, but we still see a timeout on
> > > at least one SKL. A CDCLK change request following the failed one will
> > > succeed nevertheless.
> > >
> > > I could reproduce this problem easily by running kms_pipe_crc_basic in a
> > > loop. In all failure cases _wait_for() was pre-empted for >3ms and so in
> > > the worst case - when the pre-emption happened right after calculating
> > > timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only
> > > once which failed and so _wait_for() timed out. As opposed to this the
> > > spec says to keep retrying the request for at most a 3ms period.
> > >
> > > To fix this disable pre-emption to maximize the number of times we retry
> > > the request. Also increase the timeout to 10ms to account for interrupts
> > > that could reduce the number of these attempts. With this change I
> > > couldn't trigger the problem.
> > >
> > > v2:
> > > - Use 1ms poll period instead of 10us. (Chris)
> > > v3:
> > > - Poll with pre-emption disabled to increase the number of request
> > > attempts. (Ville, Chris)
> > > - Factor out a helper to poll, it's also needed by the next patch.
> > >
> > > Cc: Ville Syrjälä
> > > Cc: Chris Wilson
> > > Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929
> > > Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > drivers/gpu/drm/i915/i915_reg.h | 2 +-
> > > drivers/gpu/drm/i915/intel_display.c | 29 +++-
> > > drivers/gpu/drm/i915/intel_pm.c | 43
> > >
> > > 4 files changed, 53 insertions(+), 22 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 01f5067..f618807 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -3593,6 +3593,7 @@ extern void intel_display_print_error_state(struct
> > > drm_i915_error_state_buf *e,
> > >
> > > int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox,
> > > u32 *val);
> > > int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u32 mbox,
> > > u32 val);
> > > +int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32
> > > request);
> > >
> > > /* intel_sideband.c */
> > > u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 6747d68..f542cbc 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -7424,7 +7424,6 @@ enum {
> > > #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT 24
> > > #define SKL_PCODE_CDCLK_CONTROL0x7
> > > #define SKL_CDCLK_PREPARE_FOR_CHANGE 0x3
> > > -#define SKL_CDCLK_READY_FOR_CHANGE 0x1
> > > #define GEN6_PCODE_WRITE_MIN_FREQ_TABLE0x8
> > > #define GEN6_PCODE_READ_MIN_FREQ_TABLE 0x9
> > > #define GEN6_READ_OC_PARAMS0xc
> > > @@ -7437,6 +7436,7 @@ enum {
> > > #define GEN9_SAGV_DISABLE0x0
> > > #define GEN9_SAGV_IS_DISABLED0x1
> > > #define GEN9_SAGV_ENABLE 0x3
> > > +#define GEN9_PCODE_REQUEST_DONE0x1
> >
> > Is that really a generic thing?
>
> At least SAGV uses the same and there is no other request I know of
> that would need this polling request. It will be used in the next patch
> for SAGV too.
At least it's a bit mispaced since now it looks like it would be
a pcode command, but command 0x1 == CMD_CONFIG according to the spec.
>
> >
> > > #define GEN6_PCODE_DATA _MMIO(0x138128)
> > > #define GEN6_PCODE_FREQ_IA_RATIO_SHIFT 8
> > > #define GEN6_PCODE_FREQ_RING_RATIO_SHIFT 16
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 5d11002..46c0e42 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -6245,35 +6245,22 @@ skl_dpll0_disable(struct drm_i915_private
> > > *dev_priv)
> > > dev_priv->cdclk_pll.vco = 0;
> > > }
> > >
> > > -static bool skl_cdclk_pcu_ready(struct drm_i915_private *dev_priv)
> > > -{
> > > - int ret;
> > > - u32 val;
> > > -
> > > - /* inform PCU we want to change CDCLK */
> > > - val = SKL_CDCLK_PREPARE_FOR_CHANGE;
> > > - mutex_lock(&dev_priv->rps.hw_lock)
Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/gen9: Fix PCODE polling during CDCLK change notification
On Mon, Nov 28, 2016 at 04:06:05PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 28, 2016 at 03:54:08PM +0200, Imre Deak wrote:
> > On ma, 2016-11-28 at 15:51 +0200, Ville Syrjälä wrote:
> > > On Mon, Nov 28, 2016 at 01:12:57PM +0200, Imre Deak wrote:
> > > > commit 848496e5902833600f7992f4faa82dc1546051ba
> > > > Author: Ville Syrjälä
> > > > Date: Wed Jul 13 16:32:03 2016 +0300
> > > >
> > > > drm/i915: Wait up to 3ms for the pcu to ack the cdclk change
> > > > request on SKL
> > > >
> > > > increased the timeout to match the spec, but we still see a timeout on
> > > > at least one SKL. A CDCLK change request following the failed one will
> > > > succeed nevertheless.
> > > >
> > > > I could reproduce this problem easily by running kms_pipe_crc_basic in a
> > > > loop. In all failure cases _wait_for() was pre-empted for >3ms and so in
> > > > the worst case - when the pre-emption happened right after calculating
> > > > timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only
> > > > once which failed and so _wait_for() timed out. As opposed to this the
> > > > spec says to keep retrying the request for at most a 3ms period.
> > > >
> > > > To fix this disable pre-emption to maximize the number of times we retry
> > > > the request. Also increase the timeout to 10ms to account for interrupts
> > > > that could reduce the number of these attempts. With this change I
> > > > couldn't trigger the problem.
> > > >
> > > > v2:
> > > > - Use 1ms poll period instead of 10us. (Chris)
> > > > v3:
> > > > - Poll with pre-emption disabled to increase the number of request
> > > > attempts. (Ville, Chris)
> > > > - Factor out a helper to poll, it's also needed by the next patch.
> > > >
> > > > Cc: Ville Syrjälä
> > > > Cc: Chris Wilson
> > > > Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929
> > > > Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B
> > > > Signed-off-by: Imre Deak
> > > > ---
> > > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > > drivers/gpu/drm/i915/i915_reg.h | 2 +-
> > > > drivers/gpu/drm/i915/intel_display.c | 29 +++-
> > > > drivers/gpu/drm/i915/intel_pm.c | 43
> > > >
> > > > 4 files changed, 53 insertions(+), 22 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 01f5067..f618807 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -3593,6 +3593,7 @@ extern void
> > > > intel_display_print_error_state(struct drm_i915_error_state_buf *e,
> > > >
> > > > int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32
> > > > mbox, u32 *val);
> > > > int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u32
> > > > mbox, u32 val);
> > > > +int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32
> > > > request);
> > > >
> > > > /* intel_sideband.c */
> > > > u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
> > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > index 6747d68..f542cbc 100644
> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > @@ -7424,7 +7424,6 @@ enum {
> > > > #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT 24
> > > > #define SKL_PCODE_CDCLK_CONTROL 0x7
> > > > #define SKL_CDCLK_PREPARE_FOR_CHANGE 0x3
> > > > -#define SKL_CDCLK_READY_FOR_CHANGE 0x1
> > > > #define GEN6_PCODE_WRITE_MIN_FREQ_TABLE 0x8
> > > > #define GEN6_PCODE_READ_MIN_FREQ_TABLE 0x9
> > > > #define GEN6_READ_OC_PARAMS 0xc
> > > > @@ -7437,6 +7436,7 @@ enum {
> > > > #define GEN9_SAGV_DISABLE 0x0
> > > > #define GEN9_SAGV_IS_DISABLED 0x1
> > > > #define GEN9_SAGV_ENABLE 0x3
> > > > +#define GEN9_PCODE_REQUEST_DONE 0x1
> > >
> > > Is that really a generic thing?
> >
> > At least SAGV uses the same and there is no other request I know of
> > that would need this polling request. It will be used in the next patch
> > for SAGV too.
>
> At least it's a bit mispaced since now it looks like it would be
> a pcode command, but command 0x1 == CMD_CONFIG according to the spec.
If we don't want to assume it's all that generic, I guess we could
always have the caller pass in the mask+value to wait for?
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/15] drm/i915/guc: Keep the execbuf client allocated across reset
On Mon, Nov 28, 2016 at 01:49:03PM +, Tvrtko Ursulin wrote:
>
> On 25/11/2016 09:30, Chris Wilson wrote:
> >In order to avoid some complexity in trying to reconstruct the
> >workqueues across reset, remember them instead. The issue comes when we
> >have to handle a reset between request allocation and submission, the
> >request has reserved space in the wq, but is not in any list so we fail
> >to restore the reserved space. By keeping the execbuf client intact
> >across the reset, we also keep the reservations.
>
> I lost track a bit on why do we need to reserve the space at request
> creation time? Is it not becoming a bit cumbersome?
It is very, very hard to handle a failure. We have to be careful not to
alter global state prior to executing the request, or at least
submitting the request, which we are currently not. Since we can't
unwind the global state changes, that imposes a point-of-no-return on
request construction after which, the request must be submitted. (It is
possible though to detect when a request doesn't make any global state
changes and drop the request on add.) As the reservation may fail, we
have to do that early.
> >@@ -883,8 +877,13 @@ guc_client_alloc(struct drm_i915_private *dev_priv,
> >
> > guc_proc_desc_init(guc, client);
> > guc_ctx_desc_init(guc, client);
> >-if (guc_init_doorbell(guc, client, db_id))
> >-goto err;
> >+
> >+/* For runtime client allocation we need to enable the doorbell. Not
> >+ * required yet for the static execbuf_client as this special kernel
> >+ * client is enabled from i915_guc_submission_enable().
> >+ *
> >+ * guc_update_doorbell_id(guc, client, db_id);
> >+ */
>
> What future is the "not yet" part referring to? What are the other clients?
No idea. The code is designed around the premise that users could
allocate guc contexts and do direct submission on their private
channels. That may be more appropriate in a bufferless world, but not
yet.
> > DRM_DEBUG_DRIVER("new priority %u client %p for engine(s) 0x%x:
> > ctx_index %u\n",
> > priority, client, client->engines, client->ctx_index);
> >@@ -1484,6 +1483,9 @@ int i915_guc_submission_init(struct drm_i915_private
> >*dev_priv)
> > struct intel_guc *guc = &dev_priv->guc;
> > struct i915_vma *vma;
> >
> >+if (!HAS_GUC_SCHED(dev_priv))
> >+return 0;
>
> Why did you have to add this hunk? I think this function does not
> get called unless there is a GuC.
I too thought that it would not called without a guc.
> > int i915_guc_submission_enable(struct drm_i915_private *dev_priv)
> > {
> > struct intel_guc *guc = &dev_priv->guc;
> >-struct drm_i915_gem_request *request;
> >-struct i915_guc_client *client;
> >+struct i915_guc_client *client = guc->execbuf_client;
> > struct intel_engine_cs *engine;
> > enum intel_engine_id id;
> >
> >-/* client for execbuf submission */
> >-client = guc_client_alloc(dev_priv,
> >- INTEL_INFO(dev_priv)->ring_mask,
> >- GUC_CTX_PRIORITY_KMD_NORMAL,
> >- dev_priv->kernel_context);
> >-if (!client) {
> >-DRM_ERROR("Failed to create normal GuC client!\n");
> >-return -ENOMEM;
> >-}
> >+if (!client)
> >+return -ENODEV;
> >
> >-guc->execbuf_client = client;
> >+guc_reset_wq(client);
> > host2guc_sample_forcewake(guc, client);
> > guc_init_doorbell_hw(guc);
> >
> > /* Take over from manual control of ELSP (execlists) */
> > for_each_engine(engine, dev_priv, id) {
> >+struct drm_i915_gem_request *rq;
> >+
> > engine->submit_request = i915_guc_submit;
> > engine->schedule = NULL;
> >
> > /* Replay the current set of previously submitted requests */
> >-list_for_each_entry(request,
> >-&engine->timeline->requests, link) {
> >+list_for_each_entry(rq, &engine->timeline->requests, link) {
> > client->wq_rsvd += sizeof(struct guc_wq_item);
> >-if (i915_sw_fence_done(&request->submit))
> >-i915_guc_submit(request);
>
> i915_sw_fence_done check is not needed because only submit-ready
> requests can be on the engine timeline?
More so, only requests that have not only passed the submit fence but
also have the execute fence signaled can be on the engine/execution
timeline. (Distinction is more interesting when the sw scheduler delays
the execute.)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm: Track framebuffer references at the point of assignment
On Mon, Nov 28, 2016 at 08:46:11AM +, Chris Wilson wrote:
> On Mon, Nov 28, 2016 at 08:48:34AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 25, 2016 at 03:32:31PM +, Chris Wilson wrote:
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -1253,7 +1253,7 @@ drm_atomic_set_fb_for_plane(struct drm_plane_state
> > > *plane_state,
> > > DRM_DEBUG_ATOMIC("Set [NOFB] for plane state %p\n",
> > >plane_state);
> > >
> > > - drm_framebuffer_assign(&plane_state->fb, fb);
> > > + drm_framebuffer_assign(__mkwrite_drm_framebuffer(&plane_state->fb), fb);
> >
> > Feels like const gone the wrong way round? Or I'm not entirely clear on
> > what this is supposed to achieve. Just dropping the const would still be a
> > nice improvement.
>
> No one is supposed to be writing to it. Adding the const generates a
> compiler warning for incorrect code that doesn't do the refcounting -
> but doesn't generate a warning for anything simply checking the value.
> It is the moral equivalent to calling it _fb to catch all the users.
But then shouldn't all users use the drm_plane_set_fb helper (and that
maybe gain a comment)? The above escaped the conversion/consolidation,
which is why it looked funny to me ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm: Protect fb_helper list manipulation with a mutex
On Mon, Nov 28, 2016 at 08:38:21AM +, Chris Wilson wrote: > On Mon, Nov 28, 2016 at 08:55:58AM +0100, Daniel Vetter wrote: > > On Wed, Nov 23, 2016 at 02:04:17PM +, Chris Wilson wrote: > > > Though we only walk the kernel_fb_helper_list inside a panic (or single > > > thread debugging), we still need to protect the list manipulation on > > > creating/removing a framebuffer device in order to prevent list > > > corruption. > > > > > > Signed-off-by: Chris Wilson > > > > I guess this explains the moved hunk in patch 1. Still feels misplaced, > > but with or without moving that around: > > No, that had to be moved to pull the register_framebuffer out from > underneath the lock (as it causes a lock recursion into the fbdev trying > to do a modeset). Ah right, I missed that. Can you pls add that the commit message and address Jani's question/comment when resending? Then I can pluck these 3 up. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/15] drm/i915/guc: Split hw submission for replay after GPU reset
On Mon, Nov 28, 2016 at 02:02:33PM +, Tvrtko Ursulin wrote:
>
> On 25/11/2016 09:30, Chris Wilson wrote:
> >Something I missed before sending off the partial series was that the
> >non-scheduler guc reset path was broken (in the full series, this is
> >pushed to the execlists reset handler). The issue is that after a reset,
> >we have to refill the GuC workqueues, which we do by resubmitting the
> >requests. However, if we already have submitted them, the fences within
> >them have already been used and triggering them again is an error.
> >Instead, just repopulate the guc workqueue.
> >
> >[ 115.858560] [IGT] gem_busy: starting subtest hang-render
> >[ 135.839867] [drm] GPU HANG: ecode 9:0:0xe757fefe, in gem_busy [1716],
> >reason: Hang on render ring, action: reset
> >[ 135.839902] drm/i915: Resetting chip after gpu hang
> >[ 135.839957] [drm] RC6 on
> >[ 135.858351] [ cut here ]
> >[ 135.858357] WARNING: CPU: 2 PID: 45 at
> >drivers/gpu/drm/i915/i915_sw_fence.c:108 i915_sw_fence_complete+0x25/0x30
> >[ 135.858357] Modules linked in: rfcomm bnep binfmt_misc nls_iso8859_1
> >input_leds snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic
> >snd_hda_intel snd_hda_codec snd_hda_core btusb btrtl snd_hwdep snd_pcm
> >8250_dw snd_seq_midi hid_lenovo snd_seq_midi_event snd_rawmidi iwlwifi
> >x86_pkg_temp_thermal coretemp snd_seq crct10dif_pclmul snd_seq_device
> >hci_uart snd_timer crc32_pclmul ghash_clmulni_intel idma64 aesni_intel
> >virt_dma btbcm snd btqca aes_x86_64 btintel lrw cfg80211 bluetooth gf128mul
> >glue_helper ablk_helper cryptd soundcore intel_lpss_pci intel_pch_thermal
> >intel_lpss_acpi intel_lpss acpi_als mfd_core kfifo_buf acpi_pad industrialio
> >autofs4 hid_plantronics usbhid dm_mirror dm_region_hash dm_log sdhci_pci
> >ahci sdhci libahci i2c_hid hid
> >[ 135.858389] CPU: 2 PID: 45 Comm: kworker/2:1 Tainted: GW
> >4.9.0-rc4+ #238
> >[ 135.858389] Hardware name: /NUC6i3SYB, BIOS
> >SYSKLi35.86A.0024.2015.1027.2142 10/27/2015
> >[ 135.858392] Workqueue: events_long i915_hangcheck_elapsed
> >[ 135.858394] c91bf9b8 812bb238
> >
> >[ 135.858396] c91bf9f8 8104f621 006c
> >8808296137f8
> >[ 135.858398] 0a00 8808457a 880845764e60
> >88084576
> >[ 135.858399] Call Trace:
> >[ 135.858403] [] dump_stack+0x4d/0x65
> >[ 135.858405] [] __warn+0xc1/0xe0
> >[ 135.858406] [] warn_slowpath_null+0x18/0x20
> >[ 135.858408] [] i915_sw_fence_complete+0x25/0x30
> >[ 135.858410] [] i915_sw_fence_commit+0xd/0x30
> >[ 135.858412] [] __i915_gem_request_submit+0xe1/0xf0
> >[ 135.858413] [] i915_gem_request_submit+0x28/0x40
> >[ 135.858415] [] i915_guc_submit+0x47/0x210
> >[ 135.858417] [] i915_guc_submission_enable+0x468/0x540
> >[ 135.858419] [] intel_guc_setup+0x715/0x810
> >[ 135.858421] [] i915_gem_init_hw+0x114/0x2a0
> >[ 135.858423] [] i915_reset+0xe8/0x120
> >[ 135.858424] [] i915_reset_and_wakeup+0x157/0x180
> >[ 135.858426] [] i915_handle_error+0x1ab/0x230
> >[ 135.858428] [] ? scnprintf+0x4d/0x90
> >[ 135.858430] [] i915_hangcheck_elapsed+0x275/0x3d0
> >[ 135.858432] [] process_one_work+0x12f/0x410
> >[ 135.858433] [] worker_thread+0x43/0x4d0
> >[ 135.858435] [] ? process_one_work+0x410/0x410
> >[ 135.858436] [] ? process_one_work+0x410/0x410
> >[ 135.858438] [] kthread+0xd4/0xf0
> >[ 135.858440] [] ? kthread_park+0x60/0x60
> >
> >v2: Only resubmit submitted requests
> >v3: Don't forget the pending requests have reserved space.
> >
> >Fixes: d55ac5bf97c6 ("drm/i915: Defer transfer onto execution timeline to
> >actual hw submission")
> >Signed-off-by: Chris Wilson
> >Cc: Tvrtko Ursulin
> >---
> > drivers/gpu/drm/i915/i915_guc_submission.c | 37
> > --
> > 1 file changed, 20 insertions(+), 17 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
> >b/drivers/gpu/drm/i915/i915_guc_submission.c
> >index 00b5fa871644..e12ff881d38d 100644
> >--- a/drivers/gpu/drm/i915/i915_guc_submission.c
> >+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> >@@ -602,12 +602,9 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
> > }
> >
> > /**
> >- * i915_guc_submit() - Submit commands through GuC
> >+ * __i915_guc_submit() - Submit commands through GuC
> > * @rq: request associated with the commands
> > *
> >- * Return: 0 on success, otherwise an errno.
> >- * (Note: nonzero really shouldn't happen!)
> >- *
> > * The caller must have already called i915_guc_wq_reserve() above with
> > * a result of 0 (success), guaranteeing that there is space in the work
> > * queue for the new request, so enqueuing the item cannot fail.
> >@@ -619,7 +616,7 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
> > * The only error here arises if the doorbell hardware isn't functioning
> > *
Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/gen9: Fix PCODE polling during CDCLK change notification
On ma, 2016-11-28 at 16:11 +0200, Ville Syrjälä wrote:
> On Mon, Nov 28, 2016 at 04:06:05PM +0200, Ville Syrjälä wrote:
> > On Mon, Nov 28, 2016 at 03:54:08PM +0200, Imre Deak wrote:
> > > On ma, 2016-11-28 at 15:51 +0200, Ville Syrjälä wrote:
> > > > On Mon, Nov 28, 2016 at 01:12:57PM +0200, Imre Deak wrote:
> > > > > commit 848496e5902833600f7992f4faa82dc1546051ba
> > > > > Author: Ville Syrjälä
> > > > > Date: Wed Jul 13 16:32:03 2016 +0300
> > > > >
> > > > > drm/i915: Wait up to 3ms for the pcu to ack the cdclk change
> > > > > request on SKL
> > > > >
> > > > > increased the timeout to match the spec, but we still see a timeout on
> > > > > at least one SKL. A CDCLK change request following the failed one will
> > > > > succeed nevertheless.
> > > > >
> > > > > I could reproduce this problem easily by running kms_pipe_crc_basic
> > > > > in a
> > > > > loop. In all failure cases _wait_for() was pre-empted for >3ms and so
> > > > > in
> > > > > the worst case - when the pre-emption happened right after calculating
> > > > > timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready()
> > > > > only
> > > > > once which failed and so _wait_for() timed out. As opposed to this the
> > > > > spec says to keep retrying the request for at most a 3ms period.
> > > > >
> > > > > To fix this disable pre-emption to maximize the number of times we
> > > > > retry
> > > > > the request. Also increase the timeout to 10ms to account for
> > > > > interrupts
> > > > > that could reduce the number of these attempts. With this change I
> > > > > couldn't trigger the problem.
> > > > >
> > > > > v2:
> > > > > - Use 1ms poll period instead of 10us. (Chris)
> > > > > v3:
> > > > > - Poll with pre-emption disabled to increase the number of request
> > > > > attempts. (Ville, Chris)
> > > > > - Factor out a helper to poll, it's also needed by the next patch.
> > > > >
> > > > > Cc: Ville Syrjälä
> > > > > Cc: Chris Wilson
> > > > > Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929
> > > > > Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B
> > > > > Signed-off-by: Imre Deak
> > > > > ---
> > > > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > > > drivers/gpu/drm/i915/i915_reg.h | 2 +-
> > > > > drivers/gpu/drm/i915/intel_display.c | 29 +++-
> > > > > drivers/gpu/drm/i915/intel_pm.c | 43
> > > > >
> > > > > 4 files changed, 53 insertions(+), 22 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > index 01f5067..f618807 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > @@ -3593,6 +3593,7 @@ extern void
> > > > > intel_display_print_error_state(struct drm_i915_error_state_buf *e,
> > > > >
> > > > > int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32
> > > > > mbox, u32 *val);
> > > > > int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u32
> > > > > mbox, u32 val);
> > > > > +int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox,
> > > > > u32 request);
> > > > >
> > > > > /* intel_sideband.c */
> > > > > u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
> > > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > > index 6747d68..f542cbc 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > > @@ -7424,7 +7424,6 @@ enum {
> > > > > #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT 24
> > > > > #define SKL_PCODE_CDCLK_CONTROL0x7
> > > > > #define SKL_CDCLK_PREPARE_FOR_CHANGE 0x3
> > > > > -#define SKL_CDCLK_READY_FOR_CHANGE 0x1
> > > > > #define GEN6_PCODE_WRITE_MIN_FREQ_TABLE0x8
> > > > > #define GEN6_PCODE_READ_MIN_FREQ_TABLE 0x9
> > > > > #define GEN6_READ_OC_PARAMS0xc
> > > > > @@ -7437,6 +7436,7 @@ enum {
> > > > > #define GEN9_SAGV_DISABLE0x0
> > > > > #define GEN9_SAGV_IS_DISABLED0x1
> > > > > #define GEN9_SAGV_ENABLE 0x3
> > > > > +#define GEN9_PCODE_REQUEST_DONE0x1
> > > >
> > > > Is that really a generic thing?
> > >
> > > At least SAGV uses the same and there is no other request I know of
> > > that would need this polling request. It will be used in the next patch
> > > for SAGV too.
> >
> > At least it's a bit mispaced since now it looks like it would be
> > a pcode command, but command 0x1 == CMD_CONFIG according to the spec.
>
> If we don't want to assume it's all that generic, I guess we could
> always have the caller pass in the mask+value to wait for?
Ok, will change that.
--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/ma
[Intel-gfx] [PATCH 2/2] Revert "drm/i915/execlists: Use a local lock for dfs_link access"
This reverts commit 27745e829a5c ("drm/i915/execlists: Use a local lock
for dfs_link access") as the struct_mutex was required to prevent
concurrent retiring and freeing, now restored in the previous patch.
Signed-off-by: Chris Wilson
Cc: David Weinehall
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0a09024d6ca3..b2c0d509e191 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -695,7 +695,6 @@ pt_lock_engine(struct i915_priotree *pt, struct
intel_engine_cs *locked)
static void execlists_schedule(struct drm_i915_gem_request *request, int prio)
{
- static DEFINE_MUTEX(lock);
struct intel_engine_cs *engine = NULL;
struct i915_dependency *dep, *p;
struct i915_dependency stack;
@@ -704,8 +703,8 @@ static void execlists_schedule(struct drm_i915_gem_request
*request, int prio)
if (prio <= READ_ONCE(request->priotree.priority))
return;
- /* Need global lock to use the temporary link inside i915_dependency */
- mutex_lock(&lock);
+ /* Need BKL in order to use the temporary link inside i915_dependency */
+ lockdep_assert_held(&request->i915->drm.struct_mutex);
stack.signaler = &request->priotree;
list_add(&stack.dfs_link, &dfs);
@@ -772,8 +771,6 @@ static void execlists_schedule(struct drm_i915_gem_request
*request, int prio)
if (engine)
spin_unlock_irq(&engine->timeline->lock);
- mutex_unlock(&lock);
-
/* XXX Do we need to preempt to make room for us and our deps? */
}
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Enable HPD interrupts with master ctl interrupt
On ma, 2016-11-28 at 19:09 +0530, Animesh Manna wrote:
>
> On 11/23/2016 10:31 PM, Imre Deak wrote:
> > On Wed, 2016-11-23 at 21:48 +0530, Animesh Manna wrote:
> > > While suspending the device hpd related interrupts are enabled
> > > to get the interrupt when device is in suspend state.
> > >
> > > Though display is in DC9 but system can be in S0 or S0i3 state.
> > > Hot plug during S0 state will generate de_port_interrupt but if
> > > system is in S0i3 state then display driver will get hotplug
> > > interrupt as pcu_hpd_interrupt which will come via pmc. So
> > > added the interrupt handling for pcu hpd interrupt.
> > >
> > > Signed-off-by: Animesh Manna
> > > Signed-off-by: A.Sunil Kamath
> > > ---
> > > drivers/gpu/drm/i915/i915_irq.c | 56
> > > ++---
> > > drivers/gpu/drm/i915/i915_reg.h | 12 +
> > > 2 files changed, 65 insertions(+), 3 deletions(-)
> > > mode change 100644 => 100755 drivers/gpu/drm/i915/i915_irq.c
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > b/drivers/gpu/drm/i915/i915_irq.c
> > > old mode 100644
> > > new mode 100755
> > > index cb8a75f..2f9b604
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -110,9 +110,9 @@
> > >
> > > /* BXT hpd list */
> > > static const u32 hpd_bxt[HPD_NUM_PINS] = {
> > > - [HPD_PORT_A] = BXT_DE_PORT_HP_DDIA,
> > > - [HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
> > > - [HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
> > > + [HPD_PORT_A] = (BXT_DE_PORT_HP_DDIA | BXT_PCU_DC9_HP_DDIA),
> > > + [HPD_PORT_B] = (BXT_DE_PORT_HP_DDIB | BXT_PCU_DC9_HP_DDIB),
> > > + [HPD_PORT_C] = (BXT_DE_PORT_HP_DDIC | BXT_PCU_DC9_HP_DDIC)
> > These are bits programmed to GEN8_DE_PORT_*, so adding the PCU bits
> > here is bogus.
> Thanks Imre for review. I understood the "hpd_bxt" array is to store all
> bits which validate hpd interrupt in irq_handler from the respective port.
> Previously only from DE_PORT interrupt used to come and after
> implementing HPD as wake feature interrupt source will be both DE_PORT
> and PCU.
> So added pcu related bits in the same array.
> Do you want two different array for DE_PORT and PCU. I can do it by
> creating a new array named "hpd_bxt_pcu" and change the existing one as
> "hpd_bxt_de".
> Please let me know your suggestion.
The problem is that - for example - bxt_hpd_irq_setup() will program
now these PCU bits to GEN8_DE_PORT_IMR which is wrong. There's also a
WARN that will trigger because of this.
Yes, using a separate struct would work I think.
> > > };
> > >
> > > /* IIR can theoretically queue up two events. Be paranoid. */
> > > @@ -2463,6 +2463,24 @@ static void bxt_hpd_irq_handler(struct
> > > drm_i915_private *dev_priv,
> > > DRM_ERROR("The master control interrupt lied
> > > (DE PORT)!\n");
> > > }
> > >
> > > + if (master_ctl & GEN8_PCU_IRQ) {
> > > + iir = I915_READ(GEN8_PCU_IIR);
> > > + if (iir) {
> > > + u32 tmp_mask;
> > > +
> > > + I915_WRITE(GEN8_PCU_IIR, iir);
> > > + ret = IRQ_HANDLED;
> > > + if (IS_BROXTON(dev_priv)) {
> > > + tmp_mask = iir & BXT_PCU_DC9_HOTPLUG_MASK;
> > > + if (tmp_mask)
> > > + bxt_hpd_irq_handler(dev_priv, tmp_mask,
> > > + hpd_bxt);
> > > + } else
> > > + DRM_ERROR("Unexpected PCU interrupt\n");
> > > + } else
> > > + DRM_ERROR("The master control interrupt lied (PCU)!\n");
> > > + }
> > > +
> > > for_each_pipe(dev_priv, pipe) {
> > > u32 flip_done, fault_errors;
> > >
> > > @@ -4294,6 +4312,19 @@ void intel_irq_uninstall(struct drm_i915_private
> > > *dev_priv)
> > > dev_priv->pm.irqs_enabled = false;
> > > }
> > >
> > > +static void bxt_enable_pcu_interrupt(struct drm_i915_private *dev_priv)
> > > +{
> > > + u32 de_pcu_hpd_enable_mask, de_pcu_imr, de_pcu_ier;
> > > +
> > > + de_pcu_hpd_enable_mask = GEN9_DE_PCU_PORTA_HOTPLUG |
> > > + GEN9_DE_PCU_PORTB_HOTPLUG |
> > > + GEN9_DE_PCU_PORTC_HOTPLUG;
> > > +
> > > + de_pcu_imr = (I915_READ(GEN8_PCU_IMR) & 0x0);
> > Typo.
> Will remove "de" tag from all pcu related variables, for anything else
> let me know.
> GEN8 and GEN9 is using same pcu interrupt registers so used the same
> macro "GEN8_PCU_IMR".
I meant the '& 0x0' part, looks like '& ~de_pcu_hpd_enable_mask' is
what you meant.
> >
> > > + de_pcu_ier = (I915_READ(GEN8_PCU_IER) | de_pcu_hpd_enable_mask);
> > > + GEN5_IRQ_INIT(GEN8_PCU_, de_pcu_imr, de_pcu_ier);
> > > +}
> > > +
> > > /**
> > > * intel_runtime_pm_disable_interrupts - runtime interrupt disabling
> > > * @dev_priv: i915 device instance
> > > @@ -4303,8 +4334,27 @@ void intel_irq_uninstall(struct dr
[Intel-gfx] [PATCH 1/2] drm/i915: Move priority bumping for flips earlier
David found another issue with priority bumping from mmioflips, where we are accessing the requests concurrently to them being retired and freed. Whilst we are skipping the dependency if has been submitted, that is not sufficient to stop the dependency from disappearing if another thread retires that request. To prevent we can either employ the struct_mutex (or a request mutex in the future) to serialise retiring before it is freed. Alternatively, we need to keep the dependencies alive using RCU whilst they are being accessed via the DFS. Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.698111] general protection fault: [#1] PREEMPT SMP Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.698305] Modules linked in: snd_hda_intel snd_hda_codec snd_hwdep x86_pkg_temp_thermal snd_hda_core coretemp crct10dif_pclmul crc32_pclmul snd_pcm ghash_clmulni_intel mei_me mei i915 e1000e ptp pps_core i2c_hid Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.698750] CPU: 1 PID: 6716 Comm: kworker/u8:2 Not tainted 4.9.0-rc6-CI-Nightly_816+ #1 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.698871] Hardware name: GIGABYTE GB-BKi7A-7500/MFLP7AP-00, BIOS F1 07/27/2016 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.699125] Workqueue: events_unbound intel_mmio_flip_work_func [i915] Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.699266] task: 880260a5e800 task.stack: c9f6c000 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.699361] RIP: 0010:[] [] execlists_schedule+0x8d/0x300 [i915] Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.699632] RSP: 0018:c9f6fcd8 EFLAGS: 00010206 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.699724] RAX: dead00f8 RBX: 8801f64b2bf0 RCX: 8801f64b2c10 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.699842] RDX: dead0100 RSI: RDI: 8801f64b0458 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.699972] RBP: c9f6fd68 R08: 88026488dc00 R09: 0002 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.700090] R10: R11: R12: 0400 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.700195] R13: c9f6fcf0 R14: 88020955aa40 R15: 88020955aa68 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.700307] FS: () GS:88026dc8() knlGS: Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.700435] CS: 0010 DS: ES: CR0: 80050033 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.700532] CR2: 02a69e90 CR3: 02c07000 CR4: 003406e0 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.700635] Stack: Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.700682] 880260a5e880 c9f6fd50 810af69a c9f6fd28 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.700827] 88020955a628 8801e1eaebf0 0020 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.700947] 0196af1edc96 88025dfa4000 8801f0b030a8 c9f6fcf0 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.701071] Call Trace: Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.701117] [] ? dequeue_entity+0x25a/0xb50 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.701260] [] fence_set_priority+0x7e/0x80 [i915] Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.701406] [] i915_gem_object_wait_priority+0x85/0x160 [i915] Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.701599] [] intel_mmio_flip_work_func+0x47/0x2b0 [i915] Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.701717] [] process_one_work+0x14d/0x470 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.701809] [] worker_thread+0x43/0x4e0 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.701888] [] ? process_one_work+0x470/0x470 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.701969] [] ? process_one_work+0x470/0x470 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.702072] [] kthread+0xc5/0xe0 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.702152] [] ? _raw_spin_unlock_irq+0x9/0x10 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.702234] [] ? kthread_park+0x60/0x60 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.702318] [] ret_from_fork+0x22/0x30 Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.702387] Code: 89 42 08 48 8b 45 88 48 89 55 c0 4c 89 6d c8 4c 8d 70 d8 4d 8d 7e 28 4d 39 ef 74 72 49 8b 1e 48 8b 13 48 39 d3 48 8d 42 f8 74 3e <48> 8b 10 8b 52 38 41 39 d4 7e 26 48 8b 50 30 48 8b 78 28 48 8d Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.702921] RIP [] execlists_schedule+0x8d/0x300 [i915] Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.703027] RSP Nov 25 21:44:11 kbl-gbbki7 kernel: [ 1746.711015] ---[ end trace 4ecf3ae63087e670 ]--- Nov 25 21:44:11 kbl-gbbki7 kernel: [ 1746.711023] BUG: unable to handle kernel NULL pointer dereference at 000b Nov 25 21:44:11 kbl-gbbki7 kernel: [ 1746.711070] IP: [] __wake_up_common+0x26/0x80 Nov 25 21:44:11 kbl-gbbki7 kernel: [ 1746.711104] PGD 25df92067 Nov 25 21:44:11 kbl-gbbki7 kernel: [ 1746.79] PUD 25b1f0067 Nov 25 21:44:11 kbl-gbbki7 kernel: [ 1746.711134] PMD 0 Nov 25 21:44:11 kbl-gbbki7 kernel: [ 1746.711140] Nov 25 21:44:11 kbl-gbbki7 kernel: [ 1746.711151] Oops: 0
Re: [Intel-gfx] [PATCH 3/3] drm: Track framebuffer references at the point of assignment
On Mon, Nov 28, 2016 at 03:15:12PM +0100, Daniel Vetter wrote:
> On Mon, Nov 28, 2016 at 08:46:11AM +, Chris Wilson wrote:
> > On Mon, Nov 28, 2016 at 08:48:34AM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 25, 2016 at 03:32:31PM +, Chris Wilson wrote:
> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > @@ -1253,7 +1253,7 @@ drm_atomic_set_fb_for_plane(struct
> > > > drm_plane_state *plane_state,
> > > > DRM_DEBUG_ATOMIC("Set [NOFB] for plane state %p\n",
> > > > plane_state);
> > > >
> > > > - drm_framebuffer_assign(&plane_state->fb, fb);
> > > > +
> > > > drm_framebuffer_assign(__mkwrite_drm_framebuffer(&plane_state->fb), fb);
> > >
> > > Feels like const gone the wrong way round? Or I'm not entirely clear on
> > > what this is supposed to achieve. Just dropping the const would still be a
> > > nice improvement.
> >
> > No one is supposed to be writing to it. Adding the const generates a
> > compiler warning for incorrect code that doesn't do the refcounting -
> > but doesn't generate a warning for anything simply checking the value.
> > It is the moral equivalent to calling it _fb to catch all the users.
>
> But then shouldn't all users use the drm_plane_set_fb helper (and that
> maybe gain a comment)? The above escaped the conversion/consolidation,
> which is why it looked funny to me ...
Yes, all users (of plane->fb = fb) are. The above is for
plane_state->fb.
I wasn't sure about adding comments to struct drm_plane, I thought the
crtc/fb there was just a crutch for !atomic.
But adding
+
+ /**
+* @fb:
+*
+* Currently active framebuffer. Do not write this directly, use
+* drm_plane_set_fb()
+*/
struct drm_framebuffer * const fb;
is not a hardship.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/debugfs: add dp mst info
== Series Details == Series: series starting with [1/3] drm/i915/debugfs: add dp mst info URL : https://patchwork.freedesktop.org/series/16036/ State : success == Summary == Series 16036v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/16036/revisions/1/mbox/ fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 8f02d2103390e48e9e76c9e75d16dbb4396484c8 drm-tip: 2016y-11m-28d-12h-38m-14s UTC integration manifest 398e091 drm/i915: enable dp mst audio 1ebd50a drm/i915: abstract ddi being audio enabled 059c25e drm/i915/debugfs: add dp mst info == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3125/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm: Hold mode_config.lock to prevent hotplug whilst setting up crtcs
On Mon, Nov 28, 2016 at 08:26:07AM +0100, Daniel Vetter wrote:
> On Wed, Nov 23, 2016 at 02:04:15PM +, Chris Wilson wrote:
> > +#define drm_fb_helper_for_each_connector(fbh, i__) \
> > + for (({lockdep_assert_held(&(fbh)->dev->mode_config.mutex); 1;}), \
> > +i__ = 0; i__ < (fbh)->connector_count; i__++)
> > +
>
> +1 on Jani's question.
I'm missing the question. Found it under pw
" No comments on the substance, but just curious, why is that "1;"
required there? Or is it?"
Hmm, the 1; itself isn't required. I was just uncomfortable when
thinking that ({}) evaluated to the result of the last statement, and
didn't want to contemplate what if that last statement was not valid in
that context. Appears gcc is quite happy since it is discarded and not
used as a rhs.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Move priority bumping for flips earlier
== Series Details == Series: series starting with [1/2] drm/i915: Move priority bumping for flips earlier URL : https://patchwork.freedesktop.org/series/16043/ State : success == Summary == Series 16043v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/16043/revisions/1/mbox/ fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 8f02d2103390e48e9e76c9e75d16dbb4396484c8 drm-tip: 2016y-11m-28d-12h-38m-14s UTC integration manifest f25e8a3 Revert "drm/i915/execlists: Use a local lock for dfs_link access" 12aacba9 drm/i915: Move priority bumping for flips earlier == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3126/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/15] drm/i915/guc: Split hw submission for replay after GPU reset
Chris Wilson writes:
> On Mon, Nov 28, 2016 at 02:02:33PM +, Tvrtko Ursulin wrote:
>>
>> On 25/11/2016 09:30, Chris Wilson wrote:
>> >Something I missed before sending off the partial series was that the
>> >non-scheduler guc reset path was broken (in the full series, this is
>> >pushed to the execlists reset handler). The issue is that after a reset,
>> >we have to refill the GuC workqueues, which we do by resubmitting the
>> >requests. However, if we already have submitted them, the fences within
>> >them have already been used and triggering them again is an error.
>> >Instead, just repopulate the guc workqueue.
>> >
>> >[ 115.858560] [IGT] gem_busy: starting subtest hang-render
>> >[ 135.839867] [drm] GPU HANG: ecode 9:0:0xe757fefe, in gem_busy [1716],
>> >reason: Hang on render ring, action: reset
>> >[ 135.839902] drm/i915: Resetting chip after gpu hang
>> >[ 135.839957] [drm] RC6 on
>> >[ 135.858351] [ cut here ]
>> >[ 135.858357] WARNING: CPU: 2 PID: 45 at
>> >drivers/gpu/drm/i915/i915_sw_fence.c:108 i915_sw_fence_complete+0x25/0x30
>> >[ 135.858357] Modules linked in: rfcomm bnep binfmt_misc nls_iso8859_1
>> >input_leds snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic
>> >snd_hda_intel snd_hda_codec snd_hda_core btusb btrtl snd_hwdep snd_pcm
>> >8250_dw snd_seq_midi hid_lenovo snd_seq_midi_event snd_rawmidi iwlwifi
>> >x86_pkg_temp_thermal coretemp snd_seq crct10dif_pclmul snd_seq_device
>> >hci_uart snd_timer crc32_pclmul ghash_clmulni_intel idma64 aesni_intel
>> >virt_dma btbcm snd btqca aes_x86_64 btintel lrw cfg80211 bluetooth gf128mul
>> >glue_helper ablk_helper cryptd soundcore intel_lpss_pci intel_pch_thermal
>> >intel_lpss_acpi intel_lpss acpi_als mfd_core kfifo_buf acpi_pad
>> >industrialio autofs4 hid_plantronics usbhid dm_mirror dm_region_hash dm_log
>> >sdhci_pci ahci sdhci libahci i2c_hid hid
>> >[ 135.858389] CPU: 2 PID: 45 Comm: kworker/2:1 Tainted: GW
>> >4.9.0-rc4+ #238
>> >[ 135.858389] Hardware name: /NUC6i3SYB, BIOS
>> >SYSKLi35.86A.0024.2015.1027.2142 10/27/2015
>> >[ 135.858392] Workqueue: events_long i915_hangcheck_elapsed
>> >[ 135.858394] c91bf9b8 812bb238
>> >
>> >[ 135.858396] c91bf9f8 8104f621 006c
>> >8808296137f8
>> >[ 135.858398] 0a00 8808457a 880845764e60
>> >88084576
>> >[ 135.858399] Call Trace:
>> >[ 135.858403] [] dump_stack+0x4d/0x65
>> >[ 135.858405] [] __warn+0xc1/0xe0
>> >[ 135.858406] [] warn_slowpath_null+0x18/0x20
>> >[ 135.858408] [] i915_sw_fence_complete+0x25/0x30
>> >[ 135.858410] [] i915_sw_fence_commit+0xd/0x30
>> >[ 135.858412] [] __i915_gem_request_submit+0xe1/0xf0
>> >[ 135.858413] [] i915_gem_request_submit+0x28/0x40
>> >[ 135.858415] [] i915_guc_submit+0x47/0x210
>> >[ 135.858417] [] i915_guc_submission_enable+0x468/0x540
>> >[ 135.858419] [] intel_guc_setup+0x715/0x810
>> >[ 135.858421] [] i915_gem_init_hw+0x114/0x2a0
>> >[ 135.858423] [] i915_reset+0xe8/0x120
>> >[ 135.858424] [] i915_reset_and_wakeup+0x157/0x180
>> >[ 135.858426] [] i915_handle_error+0x1ab/0x230
>> >[ 135.858428] [] ? scnprintf+0x4d/0x90
>> >[ 135.858430] [] i915_hangcheck_elapsed+0x275/0x3d0
>> >[ 135.858432] [] process_one_work+0x12f/0x410
>> >[ 135.858433] [] worker_thread+0x43/0x4d0
>> >[ 135.858435] [] ? process_one_work+0x410/0x410
>> >[ 135.858436] [] ? process_one_work+0x410/0x410
>> >[ 135.858438] [] kthread+0xd4/0xf0
>> >[ 135.858440] [] ? kthread_park+0x60/0x60
>> >
>> >v2: Only resubmit submitted requests
>> >v3: Don't forget the pending requests have reserved space.
>> >
>> >Fixes: d55ac5bf97c6 ("drm/i915: Defer transfer onto execution timeline to
>> >actual hw submission")
>> >Signed-off-by: Chris Wilson
>> >Cc: Tvrtko Ursulin
>> >---
>> > drivers/gpu/drm/i915/i915_guc_submission.c | 37
>> > --
>> > 1 file changed, 20 insertions(+), 17 deletions(-)
>> >
>> >diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
>> >b/drivers/gpu/drm/i915/i915_guc_submission.c
>> >index 00b5fa871644..e12ff881d38d 100644
>> >--- a/drivers/gpu/drm/i915/i915_guc_submission.c
>> >+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
>> >@@ -602,12 +602,9 @@ static int guc_ring_doorbell(struct i915_guc_client
>> >*gc)
>> > }
>> >
>> > /**
>> >- * i915_guc_submit() - Submit commands through GuC
>> >+ * __i915_guc_submit() - Submit commands through GuC
>> > * @rq:request associated with the commands
>> > *
>> >- * Return: 0 on success, otherwise an errno.
>> >- * (Note: nonzero really shouldn't happen!)
>> >- *
>> > * The caller must have already called i915_guc_wq_reserve() above with
>> > * a result of 0 (success), guaranteeing that there is space in the work
>> > * queue for the new request, so enqueuing the item cannot fail.
>> >@@ -619,7 +616,7 @@ static in
[Intel-gfx] [PATCH v4 3/3] drm/i915/gen9: Fix PCODE polling during SAGV disabling
According to the previous patch, it's possible atm that we call
intel_do_sagv_disable() only once during the 1ms period and time out if
that call fails. As opposed to this the spec says that we need to keep
retrying this request for a 1ms duration, so let's do this similarly to
the CDCLK change notification request.
v4:
- Rebased on the reply_mask, reply change.
Cc: Lyude
Cc: Ville Syrjälä
Cc: Chris Wilson
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_pm.c | 34 --
1 file changed, 8 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index aed88e0..61b7108 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2954,24 +2954,10 @@ intel_enable_sagv(struct drm_i915_private *dev_priv)
return 0;
}
-static int
-intel_do_sagv_disable(struct drm_i915_private *dev_priv)
-{
- int ret;
- uint32_t temp = GEN9_SAGV_DISABLE;
-
- ret = sandybridge_pcode_read(dev_priv, GEN9_PCODE_SAGV_CONTROL,
-&temp);
- if (ret)
- return ret;
- else
- return temp & GEN9_SAGV_IS_DISABLED;
-}
-
int
intel_disable_sagv(struct drm_i915_private *dev_priv)
{
- int ret, result;
+ int ret;
if (!intel_has_sagv(dev_priv))
return 0;
@@ -2981,27 +2967,23 @@ intel_disable_sagv(struct drm_i915_private *dev_priv)
DRM_DEBUG_KMS("Disabling the SAGV\n");
mutex_lock(&dev_priv->rps.hw_lock);
-
/* bspec says to keep retrying for at least 1 ms */
- ret = wait_for(result = intel_do_sagv_disable(dev_priv), 1);
+ ret = skl_pcode_request(dev_priv, GEN9_PCODE_SAGV_CONTROL,
+ GEN9_SAGV_DISABLE,
+ GEN9_SAGV_IS_DISABLED, GEN9_SAGV_IS_DISABLED);
mutex_unlock(&dev_priv->rps.hw_lock);
- if (ret == -ETIMEDOUT) {
- DRM_ERROR("Request to disable SAGV timed out\n");
- return -ETIMEDOUT;
- }
-
/*
* Some skl systems, pre-release machines in particular,
* don't actually have an SAGV.
*/
- if (IS_SKYLAKE(dev_priv) && result == -ENXIO) {
+ if (IS_SKYLAKE(dev_priv) && ret == -ENXIO) {
DRM_DEBUG_DRIVER("No SAGV found on system, ignoring\n");
dev_priv->sagv_status = I915_SAGV_NOT_CONTROLLED;
return 0;
- } else if (result < 0) {
- DRM_ERROR("Failed to disable the SAGV\n");
- return result;
+ } else if (ret < 0) {
+ DRM_ERROR("Failed to disable the SAGV (%d)\n", ret);
+ return ret;
}
dev_priv->sagv_status = I915_SAGV_DISABLED;
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/3] drm/i915/gen9: Fix PCODE polling during CDCLK change notification
commit 848496e5902833600f7992f4faa82dc1546051ba
Author: Ville Syrjälä
Date: Wed Jul 13 16:32:03 2016 +0300
drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL
increased the timeout to match the spec, but we still see a timeout on
at least one SKL. A CDCLK change request following the failed one will
succeed nevertheless.
I could reproduce this problem easily by running kms_pipe_crc_basic in a
loop. In all failure cases _wait_for() was pre-empted for >3ms and so in
the worst case - when the pre-emption happened right after calculating
timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only
once which failed and so _wait_for() timed out. As opposed to this the
spec says to keep retrying the request for at most a 3ms period.
To fix this disable pre-emption to maximize the number of times we retry
the request. Also increase the timeout to 10ms to account for interrupts
that could reduce the number of these attempts. With this change I
couldn't trigger the problem.
v2:
- Use 1ms poll period instead of 10us. (Chris)
v3:
- Poll with pre-emption disabled to increase the number of request
attempts. (Ville, Chris)
- Factor out a helper to poll, it's also needed by the next patch.
v4:
- Pass reply_mask, reply to skl_pcode_request(), instead of assuming the
reply is generic. (Ville)
Cc: Ville Syrjälä
Cc: Chris Wilson
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929
Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 31 ---
drivers/gpu/drm/i915/intel_pm.c | 49
3 files changed, 61 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 01f5067..1be5bab 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3593,6 +3593,8 @@ extern void intel_display_print_error_state(struct
drm_i915_error_state_buf *e,
int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox, u32
*val);
int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u32 mbox, u32
val);
+int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32 request,
+ u32 reply_mask, u32 reply);
/* intel_sideband.c */
u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5d11002..3d220da 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6245,35 +6245,24 @@ skl_dpll0_disable(struct drm_i915_private *dev_priv)
dev_priv->cdclk_pll.vco = 0;
}
-static bool skl_cdclk_pcu_ready(struct drm_i915_private *dev_priv)
-{
- int ret;
- u32 val;
-
- /* inform PCU we want to change CDCLK */
- val = SKL_CDCLK_PREPARE_FOR_CHANGE;
- mutex_lock(&dev_priv->rps.hw_lock);
- ret = sandybridge_pcode_read(dev_priv, SKL_PCODE_CDCLK_CONTROL, &val);
- mutex_unlock(&dev_priv->rps.hw_lock);
-
- return ret == 0 && (val & SKL_CDCLK_READY_FOR_CHANGE);
-}
-
-static bool skl_cdclk_wait_for_pcu_ready(struct drm_i915_private *dev_priv)
-{
- return _wait_for(skl_cdclk_pcu_ready(dev_priv), 3000, 10) == 0;
-}
-
static void skl_set_cdclk(struct drm_i915_private *dev_priv, int cdclk, int
vco)
{
u32 freq_select, pcu_ack;
+ int ret;
WARN_ON((cdclk == 24000) != (vco == 0));
DRM_DEBUG_DRIVER("Changing CDCLK to %d kHz (VCO %d kHz)\n", cdclk, vco);
- if (!skl_cdclk_wait_for_pcu_ready(dev_priv)) {
- DRM_ERROR("failed to inform PCU about cdclk change\n");
+ mutex_lock(&dev_priv->rps.hw_lock);
+ ret = skl_pcode_request(dev_priv, SKL_PCODE_CDCLK_CONTROL,
+ SKL_CDCLK_PREPARE_FOR_CHANGE,
+ SKL_CDCLK_READY_FOR_CHANGE,
+ SKL_CDCLK_READY_FOR_CHANGE);
+ mutex_unlock(&dev_priv->rps.hw_lock);
+ if (ret) {
+ DRM_ERROR("Failed to inform PCU about cdclk change (%d)\n",
+ ret);
return;
}
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 66c62f3..aed88e0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7864,6 +7864,55 @@ int sandybridge_pcode_write(struct drm_i915_private
*dev_priv,
return 0;
}
+static bool skl_pcode_try_request(struct drm_i915_private *dev_priv, u32 mbox,
+ u32 request, u32 reply_mask, u32 reply,
+ u32 *status)
+{
+ u32 val = request;
+
+ *status = sandybridge_pcode_read(dev_priv, mbox, &val);
+
+ return *status || ((val & reply_mask) == reply);
+}
+
+/**
+ * skl_pcode_request - send PCODE request until
[Intel-gfx] [PATCH v4 1/3] drm/i915/gen6+: Clear upper data byte during PCODE write
The spec calls for the upper data byte to be cleared before most of the PCODE write commands, for others like IPS control it doesn't say anything about this byte. Let's clear it in case it's clobbered somehow, especially that there are places where we only do a PCODE write without a preceeding PCODE read. Cc: Ville Syrjälä Signed-off-by: Imre Deak Reviewed-by: Chris Wilson Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 29b6653..66c62f3 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -7838,6 +7838,7 @@ int sandybridge_pcode_write(struct drm_i915_private *dev_priv, } I915_WRITE_FW(GEN6_PCODE_DATA, val); + I915_WRITE_FW(GEN6_PCODE_DATA1, 0); I915_WRITE_FW(GEN6_PCODE_MAILBOX, GEN6_PCODE_READY | mbox); if (intel_wait_for_register_fw(dev_priv, -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm: Track framebuffer references at the point of assignment
On Mon, Nov 28, 2016 at 02:44:15PM +, Chris Wilson wrote:
> On Mon, Nov 28, 2016 at 03:15:12PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 28, 2016 at 08:46:11AM +, Chris Wilson wrote:
> > > On Mon, Nov 28, 2016 at 08:48:34AM +0100, Daniel Vetter wrote:
> > > > On Fri, Nov 25, 2016 at 03:32:31PM +, Chris Wilson wrote:
> > > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > > @@ -1253,7 +1253,7 @@ drm_atomic_set_fb_for_plane(struct
> > > > > drm_plane_state *plane_state,
> > > > > DRM_DEBUG_ATOMIC("Set [NOFB] for plane state %p\n",
> > > > >plane_state);
> > > > >
> > > > > - drm_framebuffer_assign(&plane_state->fb, fb);
> > > > > +
> > > > > drm_framebuffer_assign(__mkwrite_drm_framebuffer(&plane_state->fb),
> > > > > fb);
> > > >
> > > > Feels like const gone the wrong way round? Or I'm not entirely clear on
> > > > what this is supposed to achieve. Just dropping the const would still
> > > > be a
> > > > nice improvement.
> > >
> > > No one is supposed to be writing to it. Adding the const generates a
> > > compiler warning for incorrect code that doesn't do the refcounting -
> > > but doesn't generate a warning for anything simply checking the value.
> > > It is the moral equivalent to calling it _fb to catch all the users.
> >
> > But then shouldn't all users use the drm_plane_set_fb helper (and that
> > maybe gain a comment)? The above escaped the conversion/consolidation,
> > which is why it looked funny to me ...
>
> Yes, all users (of plane->fb = fb) are. The above is for
> plane_state->fb.
Ah, missed that ;-)
> I wasn't sure about adding comments to struct drm_plane, I thought the
> crtc/fb there was just a crutch for !atomic.
>
> But adding
> +
> + /**
> +* @fb:
> +*
> +* Currently active framebuffer. Do not write this directly, use
> +* drm_plane_set_fb()
> +*/
> struct drm_framebuffer * const fb;
>
> is not a hardship.
Yeah, that'd be good. We already have a similar comment for
drm_plane_state.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/15] drm/i915/guc: Keep the execbuf client allocated across reset
On 28/11/2016 14:11, Chris Wilson wrote:
On Mon, Nov 28, 2016 at 01:49:03PM +, Tvrtko Ursulin wrote:
On 25/11/2016 09:30, Chris Wilson wrote:
In order to avoid some complexity in trying to reconstruct the
workqueues across reset, remember them instead. The issue comes when we
have to handle a reset between request allocation and submission, the
request has reserved space in the wq, but is not in any list so we fail
to restore the reserved space. By keeping the execbuf client intact
across the reset, we also keep the reservations.
I lost track a bit on why do we need to reserve the space at request
creation time? Is it not becoming a bit cumbersome?
It is very, very hard to handle a failure. We have to be careful not to
alter global state prior to executing the request, or at least
submitting the request, which we are currently not. Since we can't
unwind the global state changes, that imposes a point-of-no-return on
request construction after which, the request must be submitted. (It is
possible though to detect when a request doesn't make any global state
changes and drop the request on add.) As the reservation may fail, we
have to do that early.
We couldn't just not do any of the ring buffer writing at execbuf time,
just add it to the appropriate timeline and do all of that later, when
the scheduler decides it is time to actually submit it?
@@ -883,8 +877,13 @@ guc_client_alloc(struct drm_i915_private *dev_priv,
guc_proc_desc_init(guc, client);
guc_ctx_desc_init(guc, client);
- if (guc_init_doorbell(guc, client, db_id))
- goto err;
+
+ /* For runtime client allocation we need to enable the doorbell. Not
+* required yet for the static execbuf_client as this special kernel
+* client is enabled from i915_guc_submission_enable().
+*
+* guc_update_doorbell_id(guc, client, db_id);
+*/
What future is the "not yet" part referring to? What are the other clients?
No idea. The code is designed around the premise that users could
allocate guc contexts and do direct submission on their private
channels. That may be more appropriate in a bufferless world, but not
yet.
DRM_DEBUG_DRIVER("new priority %u client %p for engine(s) 0x%x: ctx_index
%u\n",
priority, client, client->engines, client->ctx_index);
@@ -1484,6 +1483,9 @@ int i915_guc_submission_init(struct drm_i915_private
*dev_priv)
struct intel_guc *guc = &dev_priv->guc;
struct i915_vma *vma;
+ if (!HAS_GUC_SCHED(dev_priv))
+ return 0;
Why did you have to add this hunk? I think this function does not
get called unless there is a GuC.
I too thought that it would not called without a guc.
But it is or what?
int i915_guc_submission_enable(struct drm_i915_private *dev_priv)
{
struct intel_guc *guc = &dev_priv->guc;
- struct drm_i915_gem_request *request;
- struct i915_guc_client *client;
+ struct i915_guc_client *client = guc->execbuf_client;
struct intel_engine_cs *engine;
enum intel_engine_id id;
- /* client for execbuf submission */
- client = guc_client_alloc(dev_priv,
- INTEL_INFO(dev_priv)->ring_mask,
- GUC_CTX_PRIORITY_KMD_NORMAL,
- dev_priv->kernel_context);
- if (!client) {
- DRM_ERROR("Failed to create normal GuC client!\n");
- return -ENOMEM;
- }
+ if (!client)
+ return -ENODEV;
- guc->execbuf_client = client;
+ guc_reset_wq(client);
host2guc_sample_forcewake(guc, client);
guc_init_doorbell_hw(guc);
/* Take over from manual control of ELSP (execlists) */
for_each_engine(engine, dev_priv, id) {
+ struct drm_i915_gem_request *rq;
+
engine->submit_request = i915_guc_submit;
engine->schedule = NULL;
/* Replay the current set of previously submitted requests */
- list_for_each_entry(request,
- &engine->timeline->requests, link) {
+ list_for_each_entry(rq, &engine->timeline->requests, link) {
client->wq_rsvd += sizeof(struct guc_wq_item);
- if (i915_sw_fence_done(&request->submit))
- i915_guc_submit(request);
i915_sw_fence_done check is not needed because only submit-ready
requests can be on the engine timeline?
More so, only requests that have not only passed the submit fence but
also have the execute fence signaled can be on the engine/execution
timeline. (Distinction is more interesting when the sw scheduler delays
the execute.)
Hm yes, that is correct.
Patch itself looked fine to me. It was just complexity which made me
wonder if we couldn't have taken a different route. But that was long
time ago so not relevant to this pat
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/3] drm/i915/gen6+: Clear upper data byte during PCODE write
== Series Details == Series: series starting with [v4,1/3] drm/i915/gen6+: Clear upper data byte during PCODE write URL : https://patchwork.freedesktop.org/series/16046/ State : success == Summary == Series 16046v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/16046/revisions/1/mbox/ fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 8f02d2103390e48e9e76c9e75d16dbb4396484c8 drm-tip: 2016y-11m-28d-12h-38m-14s UTC integration manifest 3344d31 drm/i915/gen9: Fix PCODE polling during SAGV disabling eb49123 drm/i915/gen9: Fix PCODE polling during CDCLK change notification 9296bd4 drm/i915/gen6+: Clear upper data byte during PCODE write == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3127/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Enable HPD interrupts with master ctl interrupt
On 11/23/2016 10:40 PM, Ville Syrjälä wrote:
On Wed, Nov 23, 2016 at 09:48:27PM +0530, Animesh Manna wrote:
While suspending the device hpd related interrupts are enabled
to get the interrupt when device is in suspend state.
Though display is in DC9 but system can be in S0 or S0i3 state.
Hot plug during S0 state will generate de_port_interrupt but if
system is in S0i3 state then display driver will get hotplug
interrupt as pcu_hpd_interrupt which will come via pmc. So
added the interrupt handling for pcu hpd interrupt.
Signed-off-by: Animesh Manna
Signed-off-by: A.Sunil Kamath
---
drivers/gpu/drm/i915/i915_irq.c | 56 ++---
drivers/gpu/drm/i915/i915_reg.h | 12 +
2 files changed, 65 insertions(+), 3 deletions(-)
mode change 100644 => 100755 drivers/gpu/drm/i915/i915_irq.c
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
old mode 100644
new mode 100755
index cb8a75f..2f9b604
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -110,9 +110,9 @@
/* BXT hpd list */
static const u32 hpd_bxt[HPD_NUM_PINS] = {
- [HPD_PORT_A] = BXT_DE_PORT_HP_DDIA,
- [HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
- [HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
+ [HPD_PORT_A] = (BXT_DE_PORT_HP_DDIA | BXT_PCU_DC9_HP_DDIA),
+ [HPD_PORT_B] = (BXT_DE_PORT_HP_DDIB | BXT_PCU_DC9_HP_DDIB),
+ [HPD_PORT_C] = (BXT_DE_PORT_HP_DDIC | BXT_PCU_DC9_HP_DDIC)
hpd_bxt_pcu[]
Thanks Ville for review.
yes, will add a separate struct for pcu.
};
/* IIR can theoretically queue up two events. Be paranoid. */
@@ -2463,6 +2463,24 @@ static void bxt_hpd_irq_handler(struct drm_i915_private
*dev_priv,
DRM_ERROR("The master control interrupt lied (DE
PORT)!\n");
}
+ if (master_ctl & GEN8_PCU_IRQ) {
+ iir = I915_READ(GEN8_PCU_IIR);
+ if (iir) {
+ u32 tmp_mask;
+
Please add a proper pcu irq ack/handler pair. I actually have such a
thing sitting on a branch:
git://github.com/vsyrjala/linux.git pcode_irq
Downloaded the code, can you please help with the commit you are referring.
I can see some old commit as last commit (will try to sync with you over
irc):
amanna@DispDev:~/PROJECT_CODEBASE/drm-intel-ville/pcode_irq$ git log
commit 20624d17963c737bbd9f242402bf3136cb664d10
Merge: 9a08da1 f4274e2
Author: Linus Torvalds
Date: Wed Apr 8 15:12:25 2015 -0700
Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux
+ I915_WRITE(GEN8_PCU_IIR, iir);
+ ret = IRQ_HANDLED;
+ if (IS_BROXTON(dev_priv)) {
+ tmp_mask = iir & BXT_PCU_DC9_HOTPLUG_MASK;
+ if (tmp_mask)
+ bxt_hpd_irq_handler(dev_priv, tmp_mask,
+ hpd_bxt);
Umm. Does the PCH_HOTPLUG reg actually work in this "hpd redirected to
pcu" state? As in are we going to detect long vs. short pulses correctly
if you just use bxt_hpd_irq_handler()?
After programming the PMC_HPD_CTL register we can get PCU interrupt only
during S0ix for HPD.
AFAIK for both DP and HDMI we will be getting long pulse for hotplug.
And In non-S0ix scenario HPD interrupt will always come from DE_PORT. So
do we need to handle short pulse interrupt?
+ } else
+ DRM_ERROR("Unexpected PCU interrupt\n");
+ } else
+ DRM_ERROR("The master control interrupt lied (PCU)!\n");
+ }
+
for_each_pipe(dev_priv, pipe) {
u32 flip_done, fault_errors;
@@ -4294,6 +4312,19 @@ void intel_irq_uninstall(struct drm_i915_private *dev_priv)
dev_priv->pm.irqs_enabled = false;
}
+static void bxt_enable_pcu_interrupt(struct drm_i915_private *dev_priv)
+{
+ u32 de_pcu_hpd_enable_mask, de_pcu_imr, de_pcu_ier;
+
+ de_pcu_hpd_enable_mask = GEN9_DE_PCU_PORTA_HOTPLUG |
+ GEN9_DE_PCU_PORTB_HOTPLUG |
+ GEN9_DE_PCU_PORTC_HOTPLUG;
+
+ de_pcu_imr = (I915_READ(GEN8_PCU_IMR) & 0x0);
+ de_pcu_ier = (I915_READ(GEN8_PCU_IER) | de_pcu_hpd_enable_mask);
You'll want a bdw_update_pcu_irq() or some such thing.
Yes, better to use bdw tag, will update in next patchset.
+ GEN5_IRQ_INIT(GEN8_PCU_, de_pcu_imr, de_pcu_ier);
+}
+
/**
* intel_runtime_pm_disable_interrupts - runtime interrupt disabling
* @dev_priv: i915 device instance
@@ -4303,8 +4334,27 @@ void intel_irq_uninstall(struct drm_i915_private
*dev_priv)
*/
void intel_runtime_pm_disable_interrupts(struct drm_i915_private *dev_priv)
{
+ unsigned long flags = 0;
+
dev_priv->drm.driver->irq_uninstall(&dev_priv->drm);
dev_priv->pm.irqs_enabled = false;
+
+ if (IS_BROXTON(dev_priv) && dev_priv->vbt.hp
Re: [Intel-gfx] [PATCH 15/15] drm/i915/guc: Split hw submission for replay after GPU reset
On 28/11/2016 14:19, Chris Wilson wrote:
On Mon, Nov 28, 2016 at 02:02:33PM +, Tvrtko Ursulin wrote:
On 25/11/2016 09:30, Chris Wilson wrote:
Something I missed before sending off the partial series was that the
non-scheduler guc reset path was broken (in the full series, this is
pushed to the execlists reset handler). The issue is that after a reset,
we have to refill the GuC workqueues, which we do by resubmitting the
requests. However, if we already have submitted them, the fences within
them have already been used and triggering them again is an error.
Instead, just repopulate the guc workqueue.
[ 115.858560] [IGT] gem_busy: starting subtest hang-render
[ 135.839867] [drm] GPU HANG: ecode 9:0:0xe757fefe, in gem_busy [1716],
reason: Hang on render ring, action: reset
[ 135.839902] drm/i915: Resetting chip after gpu hang
[ 135.839957] [drm] RC6 on
[ 135.858351] [ cut here ]
[ 135.858357] WARNING: CPU: 2 PID: 45 at
drivers/gpu/drm/i915/i915_sw_fence.c:108 i915_sw_fence_complete+0x25/0x30
[ 135.858357] Modules linked in: rfcomm bnep binfmt_misc nls_iso8859_1
input_leds snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic
snd_hda_intel snd_hda_codec snd_hda_core btusb btrtl snd_hwdep snd_pcm 8250_dw
snd_seq_midi hid_lenovo snd_seq_midi_event snd_rawmidi iwlwifi
x86_pkg_temp_thermal coretemp snd_seq crct10dif_pclmul snd_seq_device hci_uart
snd_timer crc32_pclmul ghash_clmulni_intel idma64 aesni_intel virt_dma btbcm
snd btqca aes_x86_64 btintel lrw cfg80211 bluetooth gf128mul glue_helper
ablk_helper cryptd soundcore intel_lpss_pci intel_pch_thermal intel_lpss_acpi
intel_lpss acpi_als mfd_core kfifo_buf acpi_pad industrialio autofs4
hid_plantronics usbhid dm_mirror dm_region_hash dm_log sdhci_pci ahci sdhci
libahci i2c_hid hid
[ 135.858389] CPU: 2 PID: 45 Comm: kworker/2:1 Tainted: GW
4.9.0-rc4+ #238
[ 135.858389] Hardware name: /NUC6i3SYB, BIOS
SYSKLi35.86A.0024.2015.1027.2142 10/27/2015
[ 135.858392] Workqueue: events_long i915_hangcheck_elapsed
[ 135.858394] c91bf9b8 812bb238
[ 135.858396] c91bf9f8 8104f621 006c
8808296137f8
[ 135.858398] 0a00 8808457a 880845764e60
88084576
[ 135.858399] Call Trace:
[ 135.858403] [] dump_stack+0x4d/0x65
[ 135.858405] [] __warn+0xc1/0xe0
[ 135.858406] [] warn_slowpath_null+0x18/0x20
[ 135.858408] [] i915_sw_fence_complete+0x25/0x30
[ 135.858410] [] i915_sw_fence_commit+0xd/0x30
[ 135.858412] [] __i915_gem_request_submit+0xe1/0xf0
[ 135.858413] [] i915_gem_request_submit+0x28/0x40
[ 135.858415] [] i915_guc_submit+0x47/0x210
[ 135.858417] [] i915_guc_submission_enable+0x468/0x540
[ 135.858419] [] intel_guc_setup+0x715/0x810
[ 135.858421] [] i915_gem_init_hw+0x114/0x2a0
[ 135.858423] [] i915_reset+0xe8/0x120
[ 135.858424] [] i915_reset_and_wakeup+0x157/0x180
[ 135.858426] [] i915_handle_error+0x1ab/0x230
[ 135.858428] [] ? scnprintf+0x4d/0x90
[ 135.858430] [] i915_hangcheck_elapsed+0x275/0x3d0
[ 135.858432] [] process_one_work+0x12f/0x410
[ 135.858433] [] worker_thread+0x43/0x4d0
[ 135.858435] [] ? process_one_work+0x410/0x410
[ 135.858436] [] ? process_one_work+0x410/0x410
[ 135.858438] [] kthread+0xd4/0xf0
[ 135.858440] [] ? kthread_park+0x60/0x60
v2: Only resubmit submitted requests
v3: Don't forget the pending requests have reserved space.
Fixes: d55ac5bf97c6 ("drm/i915: Defer transfer onto execution timeline to actual hw
submission")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 37 --
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 00b5fa871644..e12ff881d38d 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -602,12 +602,9 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
}
/**
- * i915_guc_submit() - Submit commands through GuC
+ * __i915_guc_submit() - Submit commands through GuC
* @rq: request associated with the commands
*
- * Return: 0 on success, otherwise an errno.
- * (Note: nonzero really shouldn't happen!)
- *
* The caller must have already called i915_guc_wq_reserve() above with
* a result of 0 (success), guaranteeing that there is space in the work
* queue for the new request, so enqueuing the item cannot fail.
@@ -619,7 +616,7 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
* The only error here arises if the doorbell hardware isn't functioning
* as expected, which really shouln't happen.
*/
-static void i915_guc_submit(struct drm_i915_gem_request *rq)
+static void __i915_guc_submit(struct drm_i915_gem_request *rq)
{
struct drm_i915_private *dev_priv = rq->i915;
struct intel_engine
Re: [Intel-gfx] [PATCH v4 2/3] drm/i915/gen9: Fix PCODE polling during CDCLK change notification
On Mon, Nov 28, 2016 at 05:29:28PM +0200, Imre Deak wrote:
> commit 848496e5902833600f7992f4faa82dc1546051ba
> Author: Ville Syrjälä
> Date: Wed Jul 13 16:32:03 2016 +0300
>
> drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on
> SKL
>
> increased the timeout to match the spec, but we still see a timeout on
> at least one SKL. A CDCLK change request following the failed one will
> succeed nevertheless.
>
> I could reproduce this problem easily by running kms_pipe_crc_basic in a
> loop. In all failure cases _wait_for() was pre-empted for >3ms and so in
> the worst case - when the pre-emption happened right after calculating
> timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only
> once which failed and so _wait_for() timed out. As opposed to this the
> spec says to keep retrying the request for at most a 3ms period.
>
> To fix this disable pre-emption to maximize the number of times we retry
> the request. Also increase the timeout to 10ms to account for interrupts
> that could reduce the number of these attempts. With this change I
> couldn't trigger the problem.
>
> v2:
> - Use 1ms poll period instead of 10us. (Chris)
> v3:
> - Poll with pre-emption disabled to increase the number of request
> attempts. (Ville, Chris)
> - Factor out a helper to poll, it's also needed by the next patch.
> v4:
> - Pass reply_mask, reply to skl_pcode_request(), instead of assuming the
> reply is generic. (Ville)
>
> Cc: Ville Syrjälä
> Cc: Chris Wilson
> Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929
> Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_display.c | 31 ---
> drivers/gpu/drm/i915/intel_pm.c | 49
>
> 3 files changed, 61 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 01f5067..1be5bab 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3593,6 +3593,8 @@ extern void intel_display_print_error_state(struct
> drm_i915_error_state_buf *e,
>
> int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox, u32
> *val);
> int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u32 mbox, u32
> val);
> +int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32
> request,
> + u32 reply_mask, u32 reply);
>
> /* intel_sideband.c */
> u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 5d11002..3d220da 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6245,35 +6245,24 @@ skl_dpll0_disable(struct drm_i915_private *dev_priv)
> dev_priv->cdclk_pll.vco = 0;
> }
>
> -static bool skl_cdclk_pcu_ready(struct drm_i915_private *dev_priv)
> -{
> - int ret;
> - u32 val;
> -
> - /* inform PCU we want to change CDCLK */
> - val = SKL_CDCLK_PREPARE_FOR_CHANGE;
> - mutex_lock(&dev_priv->rps.hw_lock);
> - ret = sandybridge_pcode_read(dev_priv, SKL_PCODE_CDCLK_CONTROL, &val);
> - mutex_unlock(&dev_priv->rps.hw_lock);
> -
> - return ret == 0 && (val & SKL_CDCLK_READY_FOR_CHANGE);
> -}
> -
> -static bool skl_cdclk_wait_for_pcu_ready(struct drm_i915_private *dev_priv)
> -{
> - return _wait_for(skl_cdclk_pcu_ready(dev_priv), 3000, 10) == 0;
> -}
> -
> static void skl_set_cdclk(struct drm_i915_private *dev_priv, int cdclk, int
> vco)
> {
> u32 freq_select, pcu_ack;
> + int ret;
>
> WARN_ON((cdclk == 24000) != (vco == 0));
>
> DRM_DEBUG_DRIVER("Changing CDCLK to %d kHz (VCO %d kHz)\n", cdclk, vco);
>
> - if (!skl_cdclk_wait_for_pcu_ready(dev_priv)) {
> - DRM_ERROR("failed to inform PCU about cdclk change\n");
> + mutex_lock(&dev_priv->rps.hw_lock);
> + ret = skl_pcode_request(dev_priv, SKL_PCODE_CDCLK_CONTROL,
> + SKL_CDCLK_PREPARE_FOR_CHANGE,
> + SKL_CDCLK_READY_FOR_CHANGE,
> + SKL_CDCLK_READY_FOR_CHANGE);
> + mutex_unlock(&dev_priv->rps.hw_lock);
> + if (ret) {
> + DRM_ERROR("Failed to inform PCU about cdclk change (%d)\n",
> + ret);
> return;
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 66c62f3..aed88e0 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7864,6 +7864,55 @@ int sandybridge_pcode_write(struct drm_i915_private
> *dev_priv,
> return 0;
> }
>
> +static bool skl_pcode_try_request(struct drm_i915_private *dev_priv, u32
> mbox,
> + u32 request, u32 reply_mask, u32 reply,
> +
Re: [Intel-gfx] [PATCH 14/15] drm/i915/guc: Keep the execbuf client allocated across reset
On Mon, Nov 28, 2016 at 03:44:41PM +, Tvrtko Ursulin wrote: > > On 28/11/2016 14:11, Chris Wilson wrote: > >On Mon, Nov 28, 2016 at 01:49:03PM +, Tvrtko Ursulin wrote: > >> > >>On 25/11/2016 09:30, Chris Wilson wrote: > >>>In order to avoid some complexity in trying to reconstruct the > >>>workqueues across reset, remember them instead. The issue comes when we > >>>have to handle a reset between request allocation and submission, the > >>>request has reserved space in the wq, but is not in any list so we fail > >>>to restore the reserved space. By keeping the execbuf client intact > >>>across the reset, we also keep the reservations. > >> > >>I lost track a bit on why do we need to reserve the space at request > >>creation time? Is it not becoming a bit cumbersome? > > > >It is very, very hard to handle a failure. We have to be careful not to > >alter global state prior to executing the request, or at least > >submitting the request, which we are currently not. Since we can't > >unwind the global state changes, that imposes a point-of-no-return on > >request construction after which, the request must be submitted. (It is > >possible though to detect when a request doesn't make any global state > >changes and drop the request on add.) As the reservation may fail, we > >have to do that early. > > We couldn't just not do any of the ring buffer writing at execbuf > time, just add it to the appropriate timeline and do all of that > later, when the scheduler decides it is time to actually submit it? It's the fence/request tracking that is the hard part, which ties into the active tracking required to hold the GTT reservation for the request (among many other external factors). > >>>@@ -1484,6 +1483,9 @@ int i915_guc_submission_init(struct drm_i915_private > >>>*dev_priv) > >>> struct intel_guc *guc = &dev_priv->guc; > >>> struct i915_vma *vma; > >>> > >>>+ if (!HAS_GUC_SCHED(dev_priv)) > >>>+ return 0; > >> > >>Why did you have to add this hunk? I think this function does not > >>get called unless there is a GuC. > > > >I too thought that it would not called without a guc. > > But it is or what? Yes. It was clobbering hw state on gen3-gen5 (CI had an ilk fail, I had a pnv fail). [snip] > Patch itself looked fine to me. It was just complexity which made me > wonder if we couldn't have taken a different route. But that was > long time ago so not relevant to this patch anyway. It's still a valid question. I think the current no-fail request handling is the simpler approach atm, but it is almost certain that some point we may need a new scheme (either for greater concurrency, late changes to the requests, something even more wacky). I'd just like to fix the last few remaining bugs in the state handling (legacy switch context) before embarking on a new journey. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Enable HPD interrupts with master ctl interrupt
On Mon, Nov 28, 2016 at 09:19:36PM +0530, Animesh Manna wrote:
>
>
> On 11/23/2016 10:40 PM, Ville Syrjälä wrote:
> > On Wed, Nov 23, 2016 at 09:48:27PM +0530, Animesh Manna wrote:
> >> While suspending the device hpd related interrupts are enabled
> >> to get the interrupt when device is in suspend state.
> >>
> >> Though display is in DC9 but system can be in S0 or S0i3 state.
> >> Hot plug during S0 state will generate de_port_interrupt but if
> >> system is in S0i3 state then display driver will get hotplug
> >> interrupt as pcu_hpd_interrupt which will come via pmc. So
> >> added the interrupt handling for pcu hpd interrupt.
> >>
> >> Signed-off-by: Animesh Manna
> >> Signed-off-by: A.Sunil Kamath
> >> ---
> >> drivers/gpu/drm/i915/i915_irq.c | 56
> >> ++---
> >> drivers/gpu/drm/i915/i915_reg.h | 12 +
> >> 2 files changed, 65 insertions(+), 3 deletions(-)
> >> mode change 100644 => 100755 drivers/gpu/drm/i915/i915_irq.c
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> >> b/drivers/gpu/drm/i915/i915_irq.c
> >> old mode 100644
> >> new mode 100755
> >> index cb8a75f..2f9b604
> >> --- a/drivers/gpu/drm/i915/i915_irq.c
> >> +++ b/drivers/gpu/drm/i915/i915_irq.c
> >> @@ -110,9 +110,9 @@
> >>
> >> /* BXT hpd list */
> >> static const u32 hpd_bxt[HPD_NUM_PINS] = {
> >> - [HPD_PORT_A] = BXT_DE_PORT_HP_DDIA,
> >> - [HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
> >> - [HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
> >> + [HPD_PORT_A] = (BXT_DE_PORT_HP_DDIA | BXT_PCU_DC9_HP_DDIA),
> >> + [HPD_PORT_B] = (BXT_DE_PORT_HP_DDIB | BXT_PCU_DC9_HP_DDIB),
> >> + [HPD_PORT_C] = (BXT_DE_PORT_HP_DDIC | BXT_PCU_DC9_HP_DDIC)
> > hpd_bxt_pcu[]
> Thanks Ville for review.
> yes, will add a separate struct for pcu.
> >
> >> };
> >>
> >> /* IIR can theoretically queue up two events. Be paranoid. */
> >> @@ -2463,6 +2463,24 @@ static void bxt_hpd_irq_handler(struct
> >> drm_i915_private *dev_priv,
> >>DRM_ERROR("The master control interrupt lied (DE
> >> PORT)!\n");
> >>}
> >>
> >> + if (master_ctl & GEN8_PCU_IRQ) {
> >> + iir = I915_READ(GEN8_PCU_IIR);
> >> + if (iir) {
> >> + u32 tmp_mask;
> >> +
> > Please add a proper pcu irq ack/handler pair. I actually have such a
> > thing sitting on a branch:
> >
> > git://github.com/vsyrjala/linux.git pcode_irq
> Downloaded the code, can you please help with the commit you are referring.
> I can see some old commit as last commit (will try to sync with you over
> irc):
> amanna@DispDev:~/PROJECT_CODEBASE/drm-intel-ville/pcode_irq$ git log
> commit 20624d17963c737bbd9f242402bf3136cb664d10
> Merge: 9a08da1 f4274e2
> Author: Linus Torvalds
> Date: Wed Apr 8 15:12:25 2015 -0700
>
> Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux
git checkout pcode_irq
>
>
> >
> >> + I915_WRITE(GEN8_PCU_IIR, iir);
> >> + ret = IRQ_HANDLED;
> >> + if (IS_BROXTON(dev_priv)) {
> >> + tmp_mask = iir & BXT_PCU_DC9_HOTPLUG_MASK;
> >> + if (tmp_mask)
> >> + bxt_hpd_irq_handler(dev_priv, tmp_mask,
> >> + hpd_bxt);
> > Umm. Does the PCH_HOTPLUG reg actually work in this "hpd redirected to
> > pcu" state? As in are we going to detect long vs. short pulses correctly
> > if you just use bxt_hpd_irq_handler()?
> After programming the PMC_HPD_CTL register we can get PCU interrupt only
> during S0ix for HPD.
> AFAIK for both DP and HDMI we will be getting long pulse for hotplug.
> And In non-S0ix scenario HPD interrupt will always come from DE_PORT. So
> do we need to handle short pulse interrupt?
Short pulse probably isn't needed during s0ix since I presume we can't
have any active displays anyway. The only slight concern might be DP
branch devices which would signal downstream port HPDs via a short
pulse. I have a vague recollection that there might be a way to aske
them for a long HPD instead via some DPCD register.
> >
> >> + } else
> >> + DRM_ERROR("Unexpected PCU interrupt\n");
> >> + } else
> >> + DRM_ERROR("The master control interrupt lied (PCU)!\n");
> >> + }
> >> +
> >>for_each_pipe(dev_priv, pipe) {
> >>u32 flip_done, fault_errors;
> >>
> >> @@ -4294,6 +4312,19 @@ void intel_irq_uninstall(struct drm_i915_private
> >> *dev_priv)
> >>dev_priv->pm.irqs_enabled = false;
> >> }
> >>
> >> +static void bxt_enable_pcu_interrupt(struct drm_i915_private *dev_priv)
> >> +{
> >> + u32 de_pcu_hpd_enable_mask, de_pcu_imr, de_pcu_ier;
> >> +
> >> + de_pcu_hpd_enable_mask = GEN9_DE_PCU_PORTA_HOTPLUG |
> >> + GEN9_DE_PCU_PORTB_HOTPLUG |
> >> + GEN9_DE_PCU_PORTC_HOTPLUG;
> >> +
> >> + de_pcu_imr = (I915_READ(GEN8_PCU_IMR) & 0x0);
> >> +
Re: [Intel-gfx] [PATCH 15/15] drm/i915/guc: Split hw submission for replay after GPU reset
On Mon, Nov 28, 2016 at 03:55:42PM +, Tvrtko Ursulin wrote:
>
> On 28/11/2016 14:19, Chris Wilson wrote:
> >On Mon, Nov 28, 2016 at 02:02:33PM +, Tvrtko Ursulin wrote:
> >>
> >>On 25/11/2016 09:30, Chris Wilson wrote:
> >>>Something I missed before sending off the partial series was that the
> >>>non-scheduler guc reset path was broken (in the full series, this is
> >>>pushed to the execlists reset handler). The issue is that after a reset,
> >>>we have to refill the GuC workqueues, which we do by resubmitting the
> >>>requests. However, if we already have submitted them, the fences within
> >>>them have already been used and triggering them again is an error.
> >>>Instead, just repopulate the guc workqueue.
> >>>
> >>>[ 115.858560] [IGT] gem_busy: starting subtest hang-render
> >>>[ 135.839867] [drm] GPU HANG: ecode 9:0:0xe757fefe, in gem_busy [1716],
> >>>reason: Hang on render ring, action: reset
> >>>[ 135.839902] drm/i915: Resetting chip after gpu hang
> >>>[ 135.839957] [drm] RC6 on
> >>>[ 135.858351] [ cut here ]
> >>>[ 135.858357] WARNING: CPU: 2 PID: 45 at
> >>>drivers/gpu/drm/i915/i915_sw_fence.c:108 i915_sw_fence_complete+0x25/0x30
> >>>[ 135.858357] Modules linked in: rfcomm bnep binfmt_misc nls_iso8859_1
> >>>input_leds snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic
> >>>snd_hda_intel snd_hda_codec snd_hda_core btusb btrtl snd_hwdep snd_pcm
> >>>8250_dw snd_seq_midi hid_lenovo snd_seq_midi_event snd_rawmidi iwlwifi
> >>>x86_pkg_temp_thermal coretemp snd_seq crct10dif_pclmul snd_seq_device
> >>>hci_uart snd_timer crc32_pclmul ghash_clmulni_intel idma64 aesni_intel
> >>>virt_dma btbcm snd btqca aes_x86_64 btintel lrw cfg80211 bluetooth
> >>>gf128mul glue_helper ablk_helper cryptd soundcore intel_lpss_pci
> >>>intel_pch_thermal intel_lpss_acpi intel_lpss acpi_als mfd_core kfifo_buf
> >>>acpi_pad industrialio autofs4 hid_plantronics usbhid dm_mirror
> >>>dm_region_hash dm_log sdhci_pci ahci sdhci libahci i2c_hid hid
> >>>[ 135.858389] CPU: 2 PID: 45 Comm: kworker/2:1 Tainted: GW
> >>>4.9.0-rc4+ #238
> >>>[ 135.858389] Hardware name: /NUC6i3SYB, BIOS
> >>>SYSKLi35.86A.0024.2015.1027.2142 10/27/2015
> >>>[ 135.858392] Workqueue: events_long i915_hangcheck_elapsed
> >>>[ 135.858394] c91bf9b8 812bb238
> >>>
> >>>[ 135.858396] c91bf9f8 8104f621 006c
> >>>8808296137f8
> >>>[ 135.858398] 0a00 8808457a 880845764e60
> >>>88084576
> >>>[ 135.858399] Call Trace:
> >>>[ 135.858403] [] dump_stack+0x4d/0x65
> >>>[ 135.858405] [] __warn+0xc1/0xe0
> >>>[ 135.858406] [] warn_slowpath_null+0x18/0x20
> >>>[ 135.858408] [] i915_sw_fence_complete+0x25/0x30
> >>>[ 135.858410] [] i915_sw_fence_commit+0xd/0x30
> >>>[ 135.858412] [] __i915_gem_request_submit+0xe1/0xf0
> >>>[ 135.858413] [] i915_gem_request_submit+0x28/0x40
> >>>[ 135.858415] [] i915_guc_submit+0x47/0x210
> >>>[ 135.858417] [] i915_guc_submission_enable+0x468/0x540
> >>>[ 135.858419] [] intel_guc_setup+0x715/0x810
> >>>[ 135.858421] [] i915_gem_init_hw+0x114/0x2a0
> >>>[ 135.858423] [] i915_reset+0xe8/0x120
> >>>[ 135.858424] [] i915_reset_and_wakeup+0x157/0x180
> >>>[ 135.858426] [] i915_handle_error+0x1ab/0x230
> >>>[ 135.858428] [] ? scnprintf+0x4d/0x90
> >>>[ 135.858430] [] i915_hangcheck_elapsed+0x275/0x3d0
> >>>[ 135.858432] [] process_one_work+0x12f/0x410
> >>>[ 135.858433] [] worker_thread+0x43/0x4d0
> >>>[ 135.858435] [] ? process_one_work+0x410/0x410
> >>>[ 135.858436] [] ? process_one_work+0x410/0x410
> >>>[ 135.858438] [] kthread+0xd4/0xf0
> >>>[ 135.858440] [] ? kthread_park+0x60/0x60
> >>>
> >>>v2: Only resubmit submitted requests
> >>>v3: Don't forget the pending requests have reserved space.
> >>>
> >>>Fixes: d55ac5bf97c6 ("drm/i915: Defer transfer onto execution timeline to
> >>>actual hw submission")
> >>>Signed-off-by: Chris Wilson
> >>>Cc: Tvrtko Ursulin
> >>>---
> >>>drivers/gpu/drm/i915/i915_guc_submission.c | 37
> >>>--
> >>>1 file changed, 20 insertions(+), 17 deletions(-)
> >>>
> >>>diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
> >>>b/drivers/gpu/drm/i915/i915_guc_submission.c
> >>>index 00b5fa871644..e12ff881d38d 100644
> >>>--- a/drivers/gpu/drm/i915/i915_guc_submission.c
> >>>+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> >>>@@ -602,12 +602,9 @@ static int guc_ring_doorbell(struct i915_guc_client
> >>>*gc)
> >>>}
> >>>
> >>>/**
> >>>- * i915_guc_submit() - Submit commands through GuC
> >>>+ * __i915_guc_submit() - Submit commands through GuC
> >>> * @rq:request associated with the commands
> >>> *
> >>>- * Return:0 on success, otherwise an errno.
> >>>- *(Note: nonzero really shouldn't happen!)
> >>>- *
> >>> * The caller must have already called i915_guc_wq_reserve() above with
>
Re: [Intel-gfx] [PATCH 3/5] drm/i915/bxt: Added _DSM call to set HPD_CTL.
On 11/23/2016 11:47 PM, Ville Syrjälä wrote:
On Wed, Nov 23, 2016 at 09:48:25PM +0530, Animesh Manna wrote:
_DSM is added to program HPD_CTL(0x1094) register
of PMC from i915 driver which will be called
based on driver feature flag. PMC hpd control register
programming will enable PMC to get hpd interrupt
during dc9.
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/intel_acpi.c | 44 ---
1 file changed, 37 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_acpi.c
b/drivers/gpu/drm/i915/intel_acpi.c
index 8c878ab..15d3b84 100755
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -10,6 +10,8 @@
#define INTEL_DSM_REVISION_ID 1 /* For Calpella anyway... */
#define INTEL_DSM_FN_PLATFORM_MUX_INFO 1 /* No args */
+#define INTEL_DSM_SET_HPD_WAKEUP 17
+#define HPD_WAKEUP_EN_VAL 0xFCF0
static struct intel_dsm_priv {
acpi_handle dhandle;
@@ -118,6 +120,25 @@ static void intel_dsm_platform_mux_info(void)
ACPI_FREE(pkg);
}
+static void intel_dsm_set_hpd_wakeup(u8 *guid)
+{
+ union acpi_object *obj;
+ union acpi_object argv4 = {
+ .integer.type = ACPI_TYPE_INTEGER,
+ .integer.value = HPD_WAKEUP_EN_VAL,
+ };
+
+ obj = acpi_evaluate_dsm_typed(intel_dsm_priv.dhandle, guid,
+ INTEL_DSM_REVISION_ID, INTEL_DSM_SET_HPD_WAKEUP,
+ &argv4, ACPI_TYPE_INTEGER);
+
+ if (!obj)
+ DRM_DEBUG_DRIVER("failed to evaluate _DSM\n");
+
+ ACPI_FREE(obj);
+}
+
+
static bool intel_dsm_pci_probe(struct pci_dev *pdev)
{
acpi_handle dhandle;
@@ -134,14 +155,23 @@ static bool intel_dsm_pci_probe(struct pci_dev *pdev)
else
guid = intel_dsm_guid;
- if (!acpi_check_dsm(dhandle, guid, INTEL_DSM_REVISION_ID,
- 1 << INTEL_DSM_FN_PLATFORM_MUX_INFO)) {
- DRM_DEBUG_KMS("no _DSM method for intel device\n");
- return false;
- }
-
intel_dsm_priv.dhandle = dhandle;
- intel_dsm_platform_mux_info();
+
+ if (acpi_check_dsm(dhandle, guid, INTEL_DSM_REVISION_ID,
+ 1 << INTEL_DSM_FN_PLATFORM_MUX_INFO))
+ intel_dsm_platform_mux_info();
+ else
+ DRM_DEBUG_KMS("no _DSM method for mux-info\n");
+
+ /* Need to ensure vbt parsing is completed. */
Eh?
There is a feature flag for oem to enable/disable HPD as wake feature in
vbt and on the basis of that PMC_HPD_CTL register will be programmed.
So added a comment just to have that info captured in code-comment, for
any concern let me know, will update accordingly.
+ if (dev_priv->vbt.hpd_wakeup_enabled &&
+ acpi_check_dsm(dhandle, guid, INTEL_DSM_REVISION_ID,
+ 1 << INTEL_DSM_SET_HPD_WAKEUP))
+ intel_dsm_set_hpd_wakeup(guid);
So we're permanently routing hpds to the pcu? Won't that mess up
stuff like short pulse detection?
I was expecting that we'd switch between the PCU and not during
runtime suspend/resume.
Routing hpd to the pcu will only happen during S0ix. As per my
understanding for both HDMI and DP we will be getting long pulse during
hotplug at S0ix. So I think it will not mess up.
Correct me if I am missing something.
- Animesh
+ else {
+ dev_priv->vbt.hpd_wakeup_enabled = false;
+ DRM_DEBUG_KMS("no _DSM method for hpd-enabling\n");
+ }
return true;
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/3] drm/i915/gen9: Fix PCODE polling during CDCLK change notification
On ma, 2016-11-28 at 17:58 +0200, Ville Syrjälä wrote:
> On Mon, Nov 28, 2016 at 05:29:28PM +0200, Imre Deak wrote:
> > commit 848496e5902833600f7992f4faa82dc1546051ba
> > Author: Ville Syrjälä
> > Date: Wed Jul 13 16:32:03 2016 +0300
> >
> > drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on
> > SKL
> >
> > increased the timeout to match the spec, but we still see a timeout on
> > at least one SKL. A CDCLK change request following the failed one will
> > succeed nevertheless.
> >
> > I could reproduce this problem easily by running kms_pipe_crc_basic in a
> > loop. In all failure cases _wait_for() was pre-empted for >3ms and so in
> > the worst case - when the pre-emption happened right after calculating
> > timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only
> > once which failed and so _wait_for() timed out. As opposed to this the
> > spec says to keep retrying the request for at most a 3ms period.
> >
> > To fix this disable pre-emption to maximize the number of times we retry
> > the request. Also increase the timeout to 10ms to account for interrupts
> > that could reduce the number of these attempts. With this change I
> > couldn't trigger the problem.
> >
> > v2:
> > - Use 1ms poll period instead of 10us. (Chris)
> > v3:
> > - Poll with pre-emption disabled to increase the number of request
> > attempts. (Ville, Chris)
> > - Factor out a helper to poll, it's also needed by the next patch.
> > v4:
> > - Pass reply_mask, reply to skl_pcode_request(), instead of assuming the
> > reply is generic. (Ville)
> >
> > Cc: Ville Syrjälä
> > Cc: Chris Wilson
> > Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929
> > Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 2 ++
> > drivers/gpu/drm/i915/intel_display.c | 31 ---
> > drivers/gpu/drm/i915/intel_pm.c | 49
> >
> > 3 files changed, 61 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 01f5067..1be5bab 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -3593,6 +3593,8 @@ extern void intel_display_print_error_state(struct
> > drm_i915_error_state_buf *e,
> >
> > int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox,
> > u32 *val);
> > int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u32 mbox,
> > u32 val);
> > +int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32
> > request,
> > + u32 reply_mask, u32 reply);
> >
> > /* intel_sideband.c */
> > u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 5d11002..3d220da 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -6245,35 +6245,24 @@ skl_dpll0_disable(struct drm_i915_private *dev_priv)
> > dev_priv->cdclk_pll.vco = 0;
> > }
> >
> > -static bool skl_cdclk_pcu_ready(struct drm_i915_private *dev_priv)
> > -{
> > - int ret;
> > - u32 val;
> > -
> > - /* inform PCU we want to change CDCLK */
> > - val = SKL_CDCLK_PREPARE_FOR_CHANGE;
> > - mutex_lock(&dev_priv->rps.hw_lock);
> > - ret = sandybridge_pcode_read(dev_priv, SKL_PCODE_CDCLK_CONTROL, &val);
> > - mutex_unlock(&dev_priv->rps.hw_lock);
> > -
> > - return ret == 0 && (val & SKL_CDCLK_READY_FOR_CHANGE);
> > -}
> > -
> > -static bool skl_cdclk_wait_for_pcu_ready(struct drm_i915_private *dev_priv)
> > -{
> > - return _wait_for(skl_cdclk_pcu_ready(dev_priv), 3000, 10) == 0;
> > -}
> > -
> > static void skl_set_cdclk(struct drm_i915_private *dev_priv, int cdclk,
> > int vco)
> > {
> > u32 freq_select, pcu_ack;
> > + int ret;
> >
> > WARN_ON((cdclk == 24000) != (vco == 0));
> >
> > DRM_DEBUG_DRIVER("Changing CDCLK to %d kHz (VCO %d kHz)\n", cdclk, vco);
> >
> > - if (!skl_cdclk_wait_for_pcu_ready(dev_priv)) {
> > - DRM_ERROR("failed to inform PCU about cdclk change\n");
> > + mutex_lock(&dev_priv->rps.hw_lock);
> > + ret = skl_pcode_request(dev_priv, SKL_PCODE_CDCLK_CONTROL,
> > + SKL_CDCLK_PREPARE_FOR_CHANGE,
> > + SKL_CDCLK_READY_FOR_CHANGE,
> > + SKL_CDCLK_READY_FOR_CHANGE);
> > + mutex_unlock(&dev_priv->rps.hw_lock);
> > + if (ret) {
> > + DRM_ERROR("Failed to inform PCU about cdclk change (%d)\n",
> > + ret);
> > return;
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 66c62f3..aed88e0 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -7864,6 +7864,55 @@ int sandy
Re: [Intel-gfx] [PATCH 1/5] drm/i915/bxt: Corrected the guid for bxt.
On 11/28/2016 4:54 PM, Jani Nikula wrote:
On Mon, 28 Nov 2016, Animesh Manna wrote:
On 11/23/2016 10:02 PM, Chris Wilson wrote:
On Wed, Nov 23, 2016 at 09:48:23PM +0530, Animesh Manna wrote:
Guid is changed for bxt platform, so corrected the guid for bxt.
v1: Initial version as RFC.
v2: Based on review comment from Jani and David,
have kept guid as binary format.
Signed-off-by: Ananth Krishna R
Signed-off-by: Bharath K Veera
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/intel_acpi.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
mode change 100644 => 100755 drivers/gpu/drm/i915/intel_acpi.c
diff --git a/drivers/gpu/drm/i915/intel_acpi.c
b/drivers/gpu/drm/i915/intel_acpi.c
old mode 100644
new mode 100755
3 people handled this patch and none complained about making
intel_acpi.c executable? What does happen when you try to execute it?
oh, will correct it in the next patchset.
index eb638a1..8c878ab
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -15,7 +15,7 @@
acpi_handle dhandle;
} intel_dsm_priv;
-static const u8 intel_dsm_guid[] = {
+static u8 intel_dsm_guid[] = {
Why drop the const?
intel_dsm_guid is not updated anywhere, it used to assign it to a common
pointer based on platform check in my current implementation.
we can explicitly typecast to avoid compilation warning to a normal
pointer which will be used during dsm probe. Hope it will be fine.
Please let me know for any concern/suggestion.
Doh, you use 'const u8 *guid', of course. The acpi_check_dsm uuid
parameter is also const u8 *.
BR,
Jani.
Ok.
0xd3, 0x73, 0xd8, 0x7e,
0xd0, 0xc2,
0x4f, 0x4e,
@@ -23,6 +23,14 @@
0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c
};
+static u8 intel_dsm_guid_bxt[] = {
Missing const.
Explained above.
+ 0xc6, 0x41, 0x5b, 0x3e,
+ 0x1d, 0xeb,
+ 0x60, 0x42,
+ 0x9d, 0x15,
+ 0xc7, 0x1f, 0xba, 0xda, 0xe4, 0x14
+};
+
static char *intel_dsm_port_name(u8 id)
{
switch (id) {
@@ -113,12 +121,20 @@ static void intel_dsm_platform_mux_info(void)
static bool intel_dsm_pci_probe(struct pci_dev *pdev)
{
acpi_handle dhandle;
+ struct drm_device *dev = pci_get_drvdata(pdev);
+ struct drm_i915_private *dev_priv = dev->dev_private;
dev == dev_priv, just a rose by another name. Use to_i915();
+ u8 *guid;
Missing const.
Explained above.
dhandle = ACPI_HANDLE(&pdev->dev);
if (!dhandle)
return false;
- if (!acpi_check_dsm(dhandle, intel_dsm_guid, INTEL_DSM_REVISION_ID,
+ if (IS_BROXTON(dev_priv))
+ guid = intel_dsm_guid_bxt;
+ else
+ guid = intel_dsm_guid;
+
+ if (!acpi_check_dsm(dhandle, guid, INTEL_DSM_REVISION_ID,
1 << INTEL_DSM_FN_PLATFORM_MUX_INFO)) {
DRM_DEBUG_KMS("no _DSM method for intel device\n");
return false;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/3] drm/i915/gen9: Fix PCODE polling during CDCLK change notification
On Mon, Nov 28, 2016 at 06:12:51PM +0200, Imre Deak wrote:
> On ma, 2016-11-28 at 17:58 +0200, Ville Syrjälä wrote:
> > On Mon, Nov 28, 2016 at 05:29:28PM +0200, Imre Deak wrote:
> > > commit 848496e5902833600f7992f4faa82dc1546051ba
> > > Author: Ville Syrjälä
> > > Date: Wed Jul 13 16:32:03 2016 +0300
> > >
> > > drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request
> > > on SKL
> > >
> > > increased the timeout to match the spec, but we still see a timeout on
> > > at least one SKL. A CDCLK change request following the failed one will
> > > succeed nevertheless.
> > >
> > > I could reproduce this problem easily by running kms_pipe_crc_basic in a
> > > loop. In all failure cases _wait_for() was pre-empted for >3ms and so in
> > > the worst case - when the pre-emption happened right after calculating
> > > timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only
> > > once which failed and so _wait_for() timed out. As opposed to this the
> > > spec says to keep retrying the request for at most a 3ms period.
> > >
> > > To fix this disable pre-emption to maximize the number of times we retry
> > > the request. Also increase the timeout to 10ms to account for interrupts
> > > that could reduce the number of these attempts. With this change I
> > > couldn't trigger the problem.
> > >
> > > v2:
> > > - Use 1ms poll period instead of 10us. (Chris)
> > > v3:
> > > - Poll with pre-emption disabled to increase the number of request
> > > attempts. (Ville, Chris)
> > > - Factor out a helper to poll, it's also needed by the next patch.
> > > v4:
> > > - Pass reply_mask, reply to skl_pcode_request(), instead of assuming the
> > > reply is generic. (Ville)
> > >
> > > Cc: Ville Syrjälä
> > > Cc: Chris Wilson
> > > Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929
> > > Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.h | 2 ++
> > > drivers/gpu/drm/i915/intel_display.c | 31 ---
> > > drivers/gpu/drm/i915/intel_pm.c | 49
> > >
> > > 3 files changed, 61 insertions(+), 21 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 01f5067..1be5bab 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -3593,6 +3593,8 @@ extern void intel_display_print_error_state(struct
> > > drm_i915_error_state_buf *e,
> > >
> > > int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox,
> > > u32 *val);
> > > int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u32 mbox,
> > > u32 val);
> > > +int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32
> > > request,
> > > + u32 reply_mask, u32 reply);
> > >
> > > /* intel_sideband.c */
> > > u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 5d11002..3d220da 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -6245,35 +6245,24 @@ skl_dpll0_disable(struct drm_i915_private
> > > *dev_priv)
> > > dev_priv->cdclk_pll.vco = 0;
> > > }
> > >
> > > -static bool skl_cdclk_pcu_ready(struct drm_i915_private *dev_priv)
> > > -{
> > > - int ret;
> > > - u32 val;
> > > -
> > > - /* inform PCU we want to change CDCLK */
> > > - val = SKL_CDCLK_PREPARE_FOR_CHANGE;
> > > - mutex_lock(&dev_priv->rps.hw_lock);
> > > - ret = sandybridge_pcode_read(dev_priv, SKL_PCODE_CDCLK_CONTROL, &val);
> > > - mutex_unlock(&dev_priv->rps.hw_lock);
> > > -
> > > - return ret == 0 && (val & SKL_CDCLK_READY_FOR_CHANGE);
> > > -}
> > > -
> > > -static bool skl_cdclk_wait_for_pcu_ready(struct drm_i915_private
> > > *dev_priv)
> > > -{
> > > - return _wait_for(skl_cdclk_pcu_ready(dev_priv), 3000, 10) == 0;
> > > -}
> > > -
> > > static void skl_set_cdclk(struct drm_i915_private *dev_priv, int cdclk,
> > > int vco)
> > > {
> > > u32 freq_select, pcu_ack;
> > > + int ret;
> > >
> > > WARN_ON((cdclk == 24000) != (vco == 0));
> > >
> > > DRM_DEBUG_DRIVER("Changing CDCLK to %d kHz (VCO %d kHz)\n", cdclk, vco);
> > >
> > > - if (!skl_cdclk_wait_for_pcu_ready(dev_priv)) {
> > > - DRM_ERROR("failed to inform PCU about cdclk change\n");
> > > + mutex_lock(&dev_priv->rps.hw_lock);
> > > + ret = skl_pcode_request(dev_priv, SKL_PCODE_CDCLK_CONTROL,
> > > + SKL_CDCLK_PREPARE_FOR_CHANGE,
> > > + SKL_CDCLK_READY_FOR_CHANGE,
> > > + SKL_CDCLK_READY_FOR_CHANGE);
> > > + mutex_unlock(&dev_priv->rps.hw_lock);
> > > + if (ret) {
> > > + DRM_ERROR("Failed to inform PCU about cdclk change (%d)\n",
> > > + ret);
> > > return;
> > > }
Re: [Intel-gfx] [PATCH 3/5] drm/i915/bxt: Added _DSM call to set HPD_CTL.
On Mon, Nov 28, 2016 at 09:36:51PM +0530, Animesh Manna wrote:
>
>
> On 11/23/2016 11:47 PM, Ville Syrjälä wrote:
> > On Wed, Nov 23, 2016 at 09:48:25PM +0530, Animesh Manna wrote:
> >> _DSM is added to program HPD_CTL(0x1094) register
> >> of PMC from i915 driver which will be called
> >> based on driver feature flag. PMC hpd control register
> >> programming will enable PMC to get hpd interrupt
> >> during dc9.
> >>
> >> Signed-off-by: Animesh Manna
> >> ---
> >> drivers/gpu/drm/i915/intel_acpi.c | 44
> >> ---
> >> 1 file changed, 37 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_acpi.c
> >> b/drivers/gpu/drm/i915/intel_acpi.c
> >> index 8c878ab..15d3b84 100755
> >> --- a/drivers/gpu/drm/i915/intel_acpi.c
> >> +++ b/drivers/gpu/drm/i915/intel_acpi.c
> >> @@ -10,6 +10,8 @@
> >>
> >> #define INTEL_DSM_REVISION_ID 1 /* For Calpella anyway... */
> >> #define INTEL_DSM_FN_PLATFORM_MUX_INFO 1 /* No args */
> >> +#define INTEL_DSM_SET_HPD_WAKEUP 17
> >> +#define HPD_WAKEUP_EN_VAL 0xFCF0
> >>
> >> static struct intel_dsm_priv {
> >>acpi_handle dhandle;
> >> @@ -118,6 +120,25 @@ static void intel_dsm_platform_mux_info(void)
> >>ACPI_FREE(pkg);
> >> }
> >>
> >> +static void intel_dsm_set_hpd_wakeup(u8 *guid)
> >> +{
> >> + union acpi_object *obj;
> >> + union acpi_object argv4 = {
> >> + .integer.type = ACPI_TYPE_INTEGER,
> >> + .integer.value = HPD_WAKEUP_EN_VAL,
> >> + };
> >> +
> >> + obj = acpi_evaluate_dsm_typed(intel_dsm_priv.dhandle, guid,
> >> + INTEL_DSM_REVISION_ID, INTEL_DSM_SET_HPD_WAKEUP,
> >> + &argv4, ACPI_TYPE_INTEGER);
> >> +
> >> + if (!obj)
> >> + DRM_DEBUG_DRIVER("failed to evaluate _DSM\n");
> >> +
> >> + ACPI_FREE(obj);
> >> +}
> >> +
> >> +
> >> static bool intel_dsm_pci_probe(struct pci_dev *pdev)
> >> {
> >>acpi_handle dhandle;
> >> @@ -134,14 +155,23 @@ static bool intel_dsm_pci_probe(struct pci_dev *pdev)
> >>else
> >>guid = intel_dsm_guid;
> >>
> >> - if (!acpi_check_dsm(dhandle, guid, INTEL_DSM_REVISION_ID,
> >> - 1 << INTEL_DSM_FN_PLATFORM_MUX_INFO)) {
> >> - DRM_DEBUG_KMS("no _DSM method for intel device\n");
> >> - return false;
> >> - }
> >> -
> >>intel_dsm_priv.dhandle = dhandle;
> >> - intel_dsm_platform_mux_info();
> >> +
> >> + if (acpi_check_dsm(dhandle, guid, INTEL_DSM_REVISION_ID,
> >> + 1 << INTEL_DSM_FN_PLATFORM_MUX_INFO))
> >> + intel_dsm_platform_mux_info();
> >> + else
> >> + DRM_DEBUG_KMS("no _DSM method for mux-info\n");
> >> +
> >> + /* Need to ensure vbt parsing is completed. */
> > Eh?
> There is a feature flag for oem to enable/disable HPD as wake feature in
> vbt and on the basis of that PMC_HPD_CTL register will be programmed.
> So added a comment just to have that info captured in code-comment, for
> any concern let me know, will update accordingly.
The comment is making me thing the VBT parsing would happen
asynchronously somehow, and this would need then to block until it's
finsiehd. Doesn't make any sense to me.
> >
> >> + if (dev_priv->vbt.hpd_wakeup_enabled &&
> >> + acpi_check_dsm(dhandle, guid, INTEL_DSM_REVISION_ID,
> >> + 1 << INTEL_DSM_SET_HPD_WAKEUP))
> >> + intel_dsm_set_hpd_wakeup(guid);
> > So we're permanently routing hpds to the pcu? Won't that mess up
> > stuff like short pulse detection?
> >
> > I was expecting that we'd switch between the PCU and not during
> > runtime suspend/resume.
> Routing hpd to the pcu will only happen during S0ix. As per my
> understanding for both HDMI and DP we will be getting long pulse during
> hotplug at S0ix. So I think it will not mess up.
> Correct me if I am missing something.
I have no idea. I don't have the hardware to verify any of that. Please
do that yourself, and add a convicing comment/commit message with your
findings documented.
>
> - Animesh
> >
> >> + else {
> >> + dev_priv->vbt.hpd_wakeup_enabled = false;
> >> + DRM_DEBUG_KMS("no _DSM method for hpd-enabling\n");
> >> + }
> >>
> >>return true;
> >> }
> >> --
> >> 1.9.1
> >>
> >> ___
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 2/3] drm/i915/gen9: Fix PCODE polling during CDCLK change notification
commit 848496e5902833600f7992f4faa82dc1546051ba
Author: Ville Syrjälä
Date: Wed Jul 13 16:32:03 2016 +0300
drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL
increased the timeout to match the spec, but we still see a timeout on
at least one SKL. A CDCLK change request following the failed one will
succeed nevertheless.
I could reproduce this problem easily by running kms_pipe_crc_basic in a
loop. In all failure cases _wait_for() was pre-empted for >3ms and so in
the worst case - when the pre-emption happened right after calculating
timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only
once which failed and so _wait_for() timed out. As opposed to this the
spec says to keep retrying the request for at most a 3ms period.
To fix this disable pre-emption to maximize the number of times we retry
the request. Also increase the timeout to 10ms to account for interrupts
that could reduce the number of these attempts. With this change I
couldn't trigger the problem.
v2:
- Use 1ms poll period instead of 10us. (Chris)
v3:
- Poll with pre-emption disabled to increase the number of request
attempts. (Ville, Chris)
- Factor out a helper to poll, it's also needed by the next patch.
v4:
- Pass reply_mask, reply to skl_pcode_request(), instead of assuming the
reply is generic. (Ville)
v5:
- List the request specific timeout values as code comment. (Ville)
Cc: Ville Syrjälä
Cc: Chris Wilson
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929
Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 31 +++--
drivers/gpu/drm/i915/intel_pm.c | 53
3 files changed, 65 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 01f5067..1be5bab 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3593,6 +3593,8 @@ extern void intel_display_print_error_state(struct
drm_i915_error_state_buf *e,
int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox, u32
*val);
int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u32 mbox, u32
val);
+int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32 request,
+ u32 reply_mask, u32 reply);
/* intel_sideband.c */
u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5d11002..3d220da 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6245,35 +6245,24 @@ skl_dpll0_disable(struct drm_i915_private *dev_priv)
dev_priv->cdclk_pll.vco = 0;
}
-static bool skl_cdclk_pcu_ready(struct drm_i915_private *dev_priv)
-{
- int ret;
- u32 val;
-
- /* inform PCU we want to change CDCLK */
- val = SKL_CDCLK_PREPARE_FOR_CHANGE;
- mutex_lock(&dev_priv->rps.hw_lock);
- ret = sandybridge_pcode_read(dev_priv, SKL_PCODE_CDCLK_CONTROL, &val);
- mutex_unlock(&dev_priv->rps.hw_lock);
-
- return ret == 0 && (val & SKL_CDCLK_READY_FOR_CHANGE);
-}
-
-static bool skl_cdclk_wait_for_pcu_ready(struct drm_i915_private *dev_priv)
-{
- return _wait_for(skl_cdclk_pcu_ready(dev_priv), 3000, 10) == 0;
-}
-
static void skl_set_cdclk(struct drm_i915_private *dev_priv, int cdclk, int
vco)
{
u32 freq_select, pcu_ack;
+ int ret;
WARN_ON((cdclk == 24000) != (vco == 0));
DRM_DEBUG_DRIVER("Changing CDCLK to %d kHz (VCO %d kHz)\n", cdclk, vco);
- if (!skl_cdclk_wait_for_pcu_ready(dev_priv)) {
- DRM_ERROR("failed to inform PCU about cdclk change\n");
+ mutex_lock(&dev_priv->rps.hw_lock);
+ ret = skl_pcode_request(dev_priv, SKL_PCODE_CDCLK_CONTROL,
+ SKL_CDCLK_PREPARE_FOR_CHANGE,
+ SKL_CDCLK_READY_FOR_CHANGE,
+ SKL_CDCLK_READY_FOR_CHANGE);
+ mutex_unlock(&dev_priv->rps.hw_lock);
+ if (ret) {
+ DRM_ERROR("Failed to inform PCU about cdclk change (%d)\n",
+ ret);
return;
}
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 66c62f3..4e06e92 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7864,6 +7864,59 @@ int sandybridge_pcode_write(struct drm_i915_private
*dev_priv,
return 0;
}
+static bool skl_pcode_try_request(struct drm_i915_private *dev_priv, u32 mbox,
+ u32 request, u32 reply_mask, u32 reply,
+ u32 *status)
+{
+ u32 val = request;
+
+ *status = sandybridge_pcode_read(dev_priv, mbox, &val);
+
+ return *status || ((val & reply_mask)
Re: [Intel-gfx] [RFC PATCH v3 2/7] drm/i915: Add support for audio driver notifications
> -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Monday, November 28, 2016 7:30 PM > To: Anand, Jerome > Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org; > broo...@kernel.org; ti...@suse.de; pierre-louis.boss...@linux.intel.com; > Ughreja, Rakesh A > Subject: Re: [RFC PATCH v3 2/7] drm/i915: Add support for audio driver > notifications > > On Fri, Nov 25, 2016 at 05:51:00AM +, Anand, Jerome wrote: > > > > > > > -Original Message- > > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > > > Sent: Thursday, November 24, 2016 7:03 PM > > > To: Anand, Jerome > > > Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org; > > > broo...@kernel.org; ti...@suse.de; > > > pierre-louis.boss...@linux.intel.com; > > > Ughreja, Rakesh A > > > Subject: Re: [RFC PATCH v3 2/7] drm/i915: Add support for audio > > > driver notifications > > > > > > On Fri, Nov 25, 2016 at 05:25:43AM +0530, Jerome Anand wrote: > > > > Notifiations like mode change, hot plug and edid to the audio > > > > driver are added. This is inturn used by the audio driver for its > > > > functionality. > > > > > > > > A new interface file capturing the notifications needed by the > > > > audio driver is added > > > > > > > > Signed-off-by: Pierre-Louis Bossart > > > > > > > > Signed-off-by: Jerome Anand > > > > --- > > > > drivers/gpu/drm/i915/i915_drv.h| 3 +++ > > > > drivers/gpu/drm/i915/intel_audio.c | 8 ++ > > > > drivers/gpu/drm/i915/intel_hdmi.c | 1 + > > > > drivers/gpu/drm/i915/intel_lpe_audio.c | 49 > > > ++ > > > > include/drm/intel_lpe_audio.h | 1 + > > > > 5 files changed, 62 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h > > > > b/drivers/gpu/drm/i915/i915_drv.h index 2a79048..33bc44c 100644 > > > > --- a/drivers/gpu/drm/i915/i915_drv.h > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h > > > > @@ -3561,6 +3561,9 @@ int intel_lpe_audio_setup(struct > > > > drm_i915_private *dev_priv); void intel_lpe_audio_teardown(struct > > > > drm_i915_private *dev_priv); void > > > > intel_lpe_audio_irq_handler(struct > > > > drm_i915_private *dev_priv); bool intel_lpe_audio_detect(struct > > > > drm_i915_private *dev_priv); > > > > +void intel_lpe_audio_notify(struct drm_i915_private *dev_priv, > > > > + void *eld, int port, int tmds_clk_speed, > > > > + bool connected); > > > > > > > > /* intel_i2c.c */ > > > > extern int intel_setup_gmbus(struct drm_device *dev); diff --git > > > > a/drivers/gpu/drm/i915/intel_audio.c > > > > b/drivers/gpu/drm/i915/intel_audio.c > > > > index 1c509f7..55a6831 100644 > > > > --- a/drivers/gpu/drm/i915/intel_audio.c > > > > +++ b/drivers/gpu/drm/i915/intel_audio.c > > > > @@ -24,6 +24,7 @@ > > > > #include > > > > #include > > > > #include > > > > +#include > > > > #include "intel_drv.h" > > > > > > > > #include > > > > @@ -627,6 +628,10 @@ void intel_audio_codec_enable(struct > > > intel_encoder *intel_encoder, > > > > if (acomp && acomp->audio_ops && acomp->audio_ops- > > > >pin_eld_notify) > > > > acomp->audio_ops->pin_eld_notify(acomp->audio_ops- > > > >audio_ptr, > > > > (int) port, (int) > > > > pipe); > > > > + > > > > + if (HAS_LPE_AUDIO(dev_priv)) > > > > + intel_lpe_audio_notify(dev_priv, connector->eld, port, > > > > + crtc_state->port_clock, true); > > > > } > > > > > > > > /** > > > > @@ -660,6 +665,9 @@ void intel_audio_codec_disable(struct > > > intel_encoder *intel_encoder) > > > > if (acomp && acomp->audio_ops && acomp->audio_ops- > > > >pin_eld_notify) > > > > acomp->audio_ops->pin_eld_notify(acomp->audio_ops- > > > >audio_ptr, > > > > (int) port, (int) > > > > pipe); > > > > + > > > > + if (HAS_LPE_AUDIO(dev_priv)) > > > > + intel_lpe_audio_notify(dev_priv, NULL, port, 0, true); > > > > } > > > > > > > > /** > > > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > > > > b/drivers/gpu/drm/i915/intel_hdmi.c > > > > index fb88e32..02d50e3 100644 > > > > --- a/drivers/gpu/drm/i915/intel_hdmi.c > > > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > > > > @@ -36,6 +36,7 @@ > > > > #include > > > > #include "intel_drv.h" > > > > #include > > > > +#include > > > > #include "i915_drv.h" > > > > > > > > static struct drm_device *intel_hdmi_to_dev(struct intel_hdmi > > > > *intel_hdmi) diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c > > > > b/drivers/gpu/drm/i915/intel_lpe_audio.c > > > > index 5335fc6..93f83cb 100644 > > > > --- a/drivers/gpu/drm/i915/intel_lpe_audio.c > > > > +++ b/drivers/gpu/drm/i915/intel_lpe_audio.c > > > > @@ -367,3 +367,52 @@ void intel_lpe_audio_teardown(struct > > > > drm_i915_private *dev_priv) > > > > > > > >
Re: [Intel-gfx] [RFC PATCH v3 2/7] drm/i915: Add support for audio driver notifications
On Mon, Nov 28, 2016 at 04:50:15PM +, Anand, Jerome wrote: > > > > -Original Message- > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > > Sent: Monday, November 28, 2016 7:30 PM > > To: Anand, Jerome > > Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org; > > broo...@kernel.org; ti...@suse.de; pierre-louis.boss...@linux.intel.com; > > Ughreja, Rakesh A > > Subject: Re: [RFC PATCH v3 2/7] drm/i915: Add support for audio driver > > notifications > > > > On Fri, Nov 25, 2016 at 05:51:00AM +, Anand, Jerome wrote: > > > > > > > > > > -Original Message- > > > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > > > > Sent: Thursday, November 24, 2016 7:03 PM > > > > To: Anand, Jerome > > > > Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org; > > > > broo...@kernel.org; ti...@suse.de; > > > > pierre-louis.boss...@linux.intel.com; > > > > Ughreja, Rakesh A > > > > Subject: Re: [RFC PATCH v3 2/7] drm/i915: Add support for audio > > > > driver notifications > > > > > > > > On Fri, Nov 25, 2016 at 05:25:43AM +0530, Jerome Anand wrote: > > > > > Notifiations like mode change, hot plug and edid to the audio > > > > > driver are added. This is inturn used by the audio driver for its > > > > > functionality. > > > > > > > > > > A new interface file capturing the notifications needed by the > > > > > audio driver is added > > > > > > > > > > Signed-off-by: Pierre-Louis Bossart > > > > > > > > > > Signed-off-by: Jerome Anand > > > > > --- > > > > > drivers/gpu/drm/i915/i915_drv.h| 3 +++ > > > > > drivers/gpu/drm/i915/intel_audio.c | 8 ++ > > > > > drivers/gpu/drm/i915/intel_hdmi.c | 1 + > > > > > drivers/gpu/drm/i915/intel_lpe_audio.c | 49 > > > > ++ > > > > > include/drm/intel_lpe_audio.h | 1 + > > > > > 5 files changed, 62 insertions(+) > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h > > > > > b/drivers/gpu/drm/i915/i915_drv.h index 2a79048..33bc44c 100644 > > > > > --- a/drivers/gpu/drm/i915/i915_drv.h > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h > > > > > @@ -3561,6 +3561,9 @@ int intel_lpe_audio_setup(struct > > > > > drm_i915_private *dev_priv); void intel_lpe_audio_teardown(struct > > > > > drm_i915_private *dev_priv); void > > > > > intel_lpe_audio_irq_handler(struct > > > > > drm_i915_private *dev_priv); bool intel_lpe_audio_detect(struct > > > > > drm_i915_private *dev_priv); > > > > > +void intel_lpe_audio_notify(struct drm_i915_private *dev_priv, > > > > > + void *eld, int port, int tmds_clk_speed, > > > > > + bool connected); > > > > > > > > > > /* intel_i2c.c */ > > > > > extern int intel_setup_gmbus(struct drm_device *dev); diff --git > > > > > a/drivers/gpu/drm/i915/intel_audio.c > > > > > b/drivers/gpu/drm/i915/intel_audio.c > > > > > index 1c509f7..55a6831 100644 > > > > > --- a/drivers/gpu/drm/i915/intel_audio.c > > > > > +++ b/drivers/gpu/drm/i915/intel_audio.c > > > > > @@ -24,6 +24,7 @@ > > > > > #include > > > > > #include > > > > > #include > > > > > +#include > > > > > #include "intel_drv.h" > > > > > > > > > > #include > > > > > @@ -627,6 +628,10 @@ void intel_audio_codec_enable(struct > > > > intel_encoder *intel_encoder, > > > > > if (acomp && acomp->audio_ops && acomp->audio_ops- > > > > >pin_eld_notify) > > > > > acomp->audio_ops->pin_eld_notify(acomp->audio_ops- > > > > >audio_ptr, > > > > >(int) port, (int) > > > > > pipe); > > > > > + > > > > > + if (HAS_LPE_AUDIO(dev_priv)) > > > > > + intel_lpe_audio_notify(dev_priv, connector->eld, port, > > > > > + crtc_state->port_clock, true); > > > > > } > > > > > > > > > > /** > > > > > @@ -660,6 +665,9 @@ void intel_audio_codec_disable(struct > > > > intel_encoder *intel_encoder) > > > > > if (acomp && acomp->audio_ops && acomp->audio_ops- > > > > >pin_eld_notify) > > > > > acomp->audio_ops->pin_eld_notify(acomp->audio_ops- > > > > >audio_ptr, > > > > >(int) port, (int) > > > > > pipe); > > > > > + > > > > > + if (HAS_LPE_AUDIO(dev_priv)) > > > > > + intel_lpe_audio_notify(dev_priv, NULL, port, 0, true); > > > > > } > > > > > > > > > > /** > > > > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > > > > > b/drivers/gpu/drm/i915/intel_hdmi.c > > > > > index fb88e32..02d50e3 100644 > > > > > --- a/drivers/gpu/drm/i915/intel_hdmi.c > > > > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > > > > > @@ -36,6 +36,7 @@ > > > > > #include > > > > > #include "intel_drv.h" > > > > > #include > > > > > +#include > > > > > #include "i915_drv.h" > > > > > > > > > > static struct drm_device *intel_hdmi_to_dev(struct intel_hdmi > > > > > *intel_hdmi) diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c > > > > > b/drivers/gpu/drm/i915/intel_l
Re: [Intel-gfx] [PATCH v5 2/3] drm/i915/gen9: Fix PCODE polling during CDCLK change notification
On Mon, Nov 28, 2016 at 06:40:33PM +0200, Imre Deak wrote:
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 66c62f3..4e06e92 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7864,6 +7864,59 @@ int sandybridge_pcode_write(struct drm_i915_private
> *dev_priv,
> return 0;
> }
>
> +static bool skl_pcode_try_request(struct drm_i915_private *dev_priv, u32
> mbox,
> + u32 request, u32 reply_mask, u32 reply,
> + u32 *status)
> +{
> + u32 val = request;
> +
> + *status = sandybridge_pcode_read(dev_priv, mbox, &val);
Hmm. This in turn uses a plain wait_for() that we want to stop relying
on drm_can_sleep() in future. Right now, it's ok but we're just making
things harder for ourselves later. I'm not keen on the alternative
though (passing around I am atomic flags, or making more things atomic
by default). :|
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/3] drm/i915/gen6+: Clear upper data byte during PCODE write (rev2)
== Series Details == Series: series starting with [v4,1/3] drm/i915/gen6+: Clear upper data byte during PCODE write (rev2) URL : https://patchwork.freedesktop.org/series/16046/ State : success == Summary == Series 16046v2 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/16046/revisions/2/mbox/ fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 477cc06f6ef4842fd63e28ff30d721462af199a6 drm-tip: 2016y-11m-28d-16h-17m-39s UTC integration manifest b82f611 drm/i915/gen9: Fix PCODE polling during SAGV disabling 97b0290 drm/i915/gen9: Fix PCODE polling during CDCLK change notification 50aec7a4c drm/i915/gen6+: Clear upper data byte during PCODE write == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3128/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/15] drm/i915: VLV/CHV atomic wm prep work
From: Ville Syrjälä A decent pile of prep work split off from my VLV/CHV atomic watermark work. Mostly VLV/CHV specific stuff, but there are a few small things in there that touch other platforms as well. Entire series available here: git://github.com/vsyrjala/linux.git vlv_atomic_wm_prep Ville Syrjälä (15): drm/i915: Drop the nop intel_update_watermarks() call from haswell_crtc_enable() drm/i915: Use the ilk_disable_lp_wm() return value drm/i915: Fix the level 0 max_wm hack on VLV/CHV drm/i915: Clean up VLV/CHV maxfifo watermark setup drm/i915: Remove duplicated wm setup for vlv and chv drm/i915: Organize vlv/chv watermarks by plane_id drm/i915: Introduce vlv_invert_wm_value() drm/i915: Pass around dev_priv in vlv wm functions drm/i915: Protect cxsr state with wm_mutex drm/i915: Skip vblank wait if cxsr was already off drm/i915: Protect DSPARB registers with a spinlock drm/i915: Zero out HOWM registers before writing new WM/HOWM register values drm/i915: Write all DDL registers in one go drm/i915: Clean up vlv_program_watermarks() drm/i915: Pass crtc state to vlv_compute_wm_level() drivers/gpu/drm/i915/i915_drv.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 21 +- drivers/gpu/drm/i915/intel_display.c | 21 +- drivers/gpu/drm/i915/intel_pm.c | 394 ++- 4 files changed, 218 insertions(+), 219 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/15] drm/i915: Fix the level 0 max_wm hack on VLV/CHV
From: Ville Syrjälä
The watermark should never exceed the FIFO size, so we need to
check against the current FIFO size instead of the theoretical
maximum when we clamp the level 0 watermark.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 29b6653661cd..8aa11e1b84ed 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1132,13 +1132,13 @@ static void vlv_compute_wm(struct intel_crtc *crtc)
/* normal watermarks */
for (level = 0; level < wm_state->num_levels; level++) {
int wm = vlv_compute_wm_level(plane, crtc, state,
level);
- int max_wm = plane->base.type == DRM_PLANE_TYPE_CURSOR
? 63 : 511;
+ int max_wm = plane->wm.fifo_size;
/* hack */
if (WARN_ON(level == 0 && wm > max_wm))
wm = max_wm;
- if (wm > plane->wm.fifo_size)
+ if (wm > max_wm)
break;
switch (plane->base.type) {
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/15] drm/i915: Drop the nop intel_update_watermarks() call from haswell_crtc_enable()
From: Ville Syrjälä HSW+ all use the .initial_watermarks() hook, so there's no point in calling intel_update_watermarks() from HSW+ specific code. We'll still hang on to the .initial_watermarks NULL check since theoretically if the memory latencies are not populated we would not populate the function pointer either. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 77c4ff9efbe3..5fef72b8ca61 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -5465,10 +5465,7 @@ static void haswell_crtc_enable(struct intel_crtc_state *pipe_config, intel_ddi_enable_transcoder_func(crtc); if (dev_priv->display.initial_watermarks != NULL) - dev_priv->display.initial_watermarks(old_intel_state, -pipe_config); - else - intel_update_watermarks(intel_crtc); + dev_priv->display.initial_watermarks(old_intel_state, pipe_config); /* XXX: Do the pipe assertions at the right place for BXT DSI. */ if (!transcoder_is_dsi(cpu_transcoder)) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/15] drm/i915: Organize vlv/chv watermarks by plane_id
From: Ville Syrjälä
Store the vlv/chv watermark values in straight up arrays indexed by
enum plane_id. Avoids a lot of useless checks for the plane type when
we don't have to think which structure member we need to access.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 16 ++-
drivers/gpu/drm/i915/intel_pm.c | 209
2 files changed, 92 insertions(+), 133 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c5349aaaf874..be89267474a1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1657,24 +1657,22 @@ struct ilk_wm_values {
};
struct vlv_pipe_wm {
- uint16_t primary;
- uint16_t sprite[2];
- uint8_t cursor;
+ uint16_t plane[I915_MAX_PLANES];
};
struct vlv_sr_wm {
uint16_t plane;
- uint8_t cursor;
+ uint16_t cursor;
+};
+
+struct vlv_wm_ddl_values {
+ uint8_t plane[I915_MAX_PLANES];
};
struct vlv_wm_values {
struct vlv_pipe_wm pipe[3];
struct vlv_sr_wm sr;
- struct {
- uint8_t cursor;
- uint8_t sprite[2];
- uint8_t primary;
- } ddl[3];
+ struct vlv_wm_ddl_values ddl[3];
uint8_t level;
bool cxsr;
};
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ae664eb37d5c..0ca8f0941d00 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -849,56 +849,56 @@ static void vlv_write_wm_values(struct intel_crtc *crtc,
enum pipe pipe = crtc->pipe;
I915_WRITE(VLV_DDL(pipe),
- (wm->ddl[pipe].cursor << DDL_CURSOR_SHIFT) |
- (wm->ddl[pipe].sprite[1] << DDL_SPRITE_SHIFT(1)) |
- (wm->ddl[pipe].sprite[0] << DDL_SPRITE_SHIFT(0)) |
- (wm->ddl[pipe].primary << DDL_PLANE_SHIFT));
+ (wm->ddl[pipe].plane[PLANE_CURSOR] << DDL_CURSOR_SHIFT) |
+ (wm->ddl[pipe].plane[PLANE_SPRITE1] << DDL_SPRITE_SHIFT(1)) |
+ (wm->ddl[pipe].plane[PLANE_SPRITE0] << DDL_SPRITE_SHIFT(0)) |
+ (wm->ddl[pipe].plane[PLANE_PRIMARY] << DDL_PLANE_SHIFT));
I915_WRITE(DSPFW1,
FW_WM(wm->sr.plane, SR) |
- FW_WM(wm->pipe[PIPE_B].cursor, CURSORB) |
- FW_WM_VLV(wm->pipe[PIPE_B].primary, PLANEB) |
- FW_WM_VLV(wm->pipe[PIPE_A].primary, PLANEA));
+ FW_WM(wm->pipe[PIPE_B].plane[PLANE_CURSOR], CURSORB) |
+ FW_WM_VLV(wm->pipe[PIPE_B].plane[PLANE_PRIMARY], PLANEB) |
+ FW_WM_VLV(wm->pipe[PIPE_A].plane[PLANE_PRIMARY], PLANEA));
I915_WRITE(DSPFW2,
- FW_WM_VLV(wm->pipe[PIPE_A].sprite[1], SPRITEB) |
- FW_WM(wm->pipe[PIPE_A].cursor, CURSORA) |
- FW_WM_VLV(wm->pipe[PIPE_A].sprite[0], SPRITEA));
+ FW_WM_VLV(wm->pipe[PIPE_A].plane[PLANE_SPRITE1], SPRITEB) |
+ FW_WM(wm->pipe[PIPE_A].plane[PLANE_CURSOR], CURSORA) |
+ FW_WM_VLV(wm->pipe[PIPE_A].plane[PLANE_SPRITE0], SPRITEA));
I915_WRITE(DSPFW3,
FW_WM(wm->sr.cursor, CURSOR_SR));
if (IS_CHERRYVIEW(dev_priv)) {
I915_WRITE(DSPFW7_CHV,
- FW_WM_VLV(wm->pipe[PIPE_B].sprite[1], SPRITED) |
- FW_WM_VLV(wm->pipe[PIPE_B].sprite[0], SPRITEC));
+ FW_WM_VLV(wm->pipe[PIPE_B].plane[PLANE_SPRITE1],
SPRITED) |
+ FW_WM_VLV(wm->pipe[PIPE_B].plane[PLANE_SPRITE0],
SPRITEC));
I915_WRITE(DSPFW8_CHV,
- FW_WM_VLV(wm->pipe[PIPE_C].sprite[1], SPRITEF) |
- FW_WM_VLV(wm->pipe[PIPE_C].sprite[0], SPRITEE));
+ FW_WM_VLV(wm->pipe[PIPE_C].plane[PLANE_SPRITE1],
SPRITEF) |
+ FW_WM_VLV(wm->pipe[PIPE_C].plane[PLANE_SPRITE0],
SPRITEE));
I915_WRITE(DSPFW9_CHV,
- FW_WM_VLV(wm->pipe[PIPE_C].primary, PLANEC) |
- FW_WM(wm->pipe[PIPE_C].cursor, CURSORC));
+ FW_WM_VLV(wm->pipe[PIPE_C].plane[PLANE_PRIMARY],
PLANEC) |
+ FW_WM(wm->pipe[PIPE_C].plane[PLANE_CURSOR],
CURSORC));
I915_WRITE(DSPHOWM,
FW_WM(wm->sr.plane >> 9, SR_HI) |
- FW_WM(wm->pipe[PIPE_C].sprite[1] >> 8, SPRITEF_HI) |
- FW_WM(wm->pipe[PIPE_C].sprite[0] >> 8, SPRITEE_HI) |
- FW_WM(wm->pipe[PIPE_C].primary >> 8, PLANEC_HI) |
- FW_WM(wm->pipe[PIPE_B].sprite[1] >> 8, SPRITED_HI) |
- FW_WM(wm->pipe[PIPE_B].sprite[0] >> 8, SPRITEC_HI) |
- FW_WM(wm->pipe[PIPE_B].primary >> 8, PLANEB_HI) |
-
[Intel-gfx] [PATCH 12/15] drm/i915: Zero out HOWM registers before writing new WM/HOWM register values
From: Ville Syrjälä On VLV/CHV some of the watermark values are split across two registers: low order bits in one, and high order bits in another. So we may not be able to update a single watermark value atomically, and thus we must be careful that we don't temporarily introduce out of bounds values during the reprogramming. To prevent this we can simply zero out all the high order bits initially, then we update the low order bits, and finally we update the high order bits with the final value. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 9f25f2195a6a..8a3441bbff30 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -877,6 +877,17 @@ static void vlv_write_wm_values(struct intel_crtc *crtc, (wm->ddl[pipe].plane[PLANE_SPRITE0] << DDL_SPRITE_SHIFT(0)) | (wm->ddl[pipe].plane[PLANE_PRIMARY] << DDL_PLANE_SHIFT)); + /* +* Zero the (unused) WM1 watermarks, and also clear all the +* high order bits so that there are no out of bounds values +* present in the registers during the reprogramming. +*/ + I915_WRITE(DSPHOWM, 0); + I915_WRITE(DSPHOWM1, 0); + I915_WRITE(DSPFW4, 0); + I915_WRITE(DSPFW5, 0); + I915_WRITE(DSPFW6, 0); + I915_WRITE(DSPFW1, FW_WM(wm->sr.plane, SR) | FW_WM(wm->pipe[PIPE_B].plane[PLANE_CURSOR], CURSORB) | @@ -924,12 +935,6 @@ static void vlv_write_wm_values(struct intel_crtc *crtc, FW_WM(wm->pipe[PIPE_A].plane[PLANE_PRIMARY] >> 8, PLANEA_HI)); } - /* zero (unused) WM1 watermarks */ - I915_WRITE(DSPFW4, 0); - I915_WRITE(DSPFW5, 0); - I915_WRITE(DSPFW6, 0); - I915_WRITE(DSPHOWM1, 0); - POSTING_READ(DSPFW1); } -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/15] drm/i915: Remove duplicated wm setup for vlv and chv
From: Ville Syrjälä
The code for vlv and chv wm latency/function pointer setup is
identical. Drop one of the copies.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a31f55a7af38..ae664eb37d5c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7683,10 +7683,7 @@ void intel_init_pm(struct drm_i915_private *dev_priv)
DRM_DEBUG_KMS("Failed to read display plane latency. "
"Disable CxSR\n");
}
- } else if (IS_CHERRYVIEW(dev_priv)) {
- vlv_setup_wm_latency(dev_priv);
- dev_priv->display.update_wm = vlv_update_wm;
- } else if (IS_VALLEYVIEW(dev_priv)) {
+ } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
vlv_setup_wm_latency(dev_priv);
dev_priv->display.update_wm = vlv_update_wm;
} else if (IS_PINEVIEW(dev_priv)) {
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/15] drm/i915: Use the ilk_disable_lp_wm() return value
From: Ville Syrjälä
ilk_disable_lp_wm() will tell us whether the LP1+ watermarks were
disabled or not, and hence whether we need to for the vblank wait or
not. Let's use that information to eliminate some useless vblank
waits.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5fef72b8ca61..ce9e7f2f395e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5114,10 +5114,8 @@ static void intel_pre_plane_update(struct
intel_crtc_state *old_crtc_state)
*
* WaCxSRDisabledForSpriteScaling:ivb
*/
- if (pipe_config->disable_lp_wm) {
- ilk_disable_lp_wm(dev);
+ if (pipe_config->disable_lp_wm && ilk_disable_lp_wm(dev))
intel_wait_for_vblank(dev_priv, crtc->pipe);
- }
/*
* If we're doing a modeset, we're done. No need to do any pre-vblank
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/15] drm/i915: Pass around dev_priv in vlv wm functions
From: Ville Syrjälä
Pasing dev_priv instead of dev is the future. Let's make the vlv/chv wm
functions respect that idea.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c955ee6341a1..e3ee07007fa2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1067,9 +1067,9 @@ static void vlv_invert_wms(struct intel_crtc *crtc)
int level;
for (level = 0; level < wm_state->num_levels; level++) {
- struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
const int sr_fifo_size =
- INTEL_INFO(to_i915(dev))->num_pipes * 512 - 1;
+ INTEL_INFO(dev_priv)->num_pipes * 512 - 1;
struct intel_plane *plane;
wm_state->sr[level].plane =
@@ -1079,7 +1079,7 @@ static void vlv_invert_wms(struct intel_crtc *crtc)
vlv_invert_wm_value(wm_state->sr[level].cursor,
63);
- for_each_intel_plane_on_crtc(dev, crtc, plane) {
+ for_each_intel_plane_on_crtc(&dev_priv->drm, crtc, plane) {
wm_state->wm[level].plane[plane->id] =
vlv_invert_wm_value(wm_state->wm[level].plane[plane->id],
plane->wm.fifo_size);
@@ -1089,8 +1089,7 @@ static void vlv_invert_wms(struct intel_crtc *crtc)
static void vlv_compute_wm(struct intel_crtc *crtc)
{
- struct drm_device *dev = crtc->base.dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct vlv_wm_state *wm_state = &crtc->wm_state;
struct intel_plane *plane;
int level;
@@ -1107,7 +1106,7 @@ static void vlv_compute_wm(struct intel_crtc *crtc)
if (wm_state->num_active_planes != 1)
wm_state->cxsr = false;
- for_each_intel_plane_on_crtc(dev, crtc, plane) {
+ for_each_intel_plane_on_crtc(&dev_priv->drm, crtc, plane) {
struct intel_plane_state *state =
to_intel_plane_state(plane->base.state);
int level;
@@ -1253,16 +1252,16 @@ static void vlv_pipe_set_fifo_size(struct intel_crtc
*crtc)
#undef VLV_FIFO
-static void vlv_merge_wm(struct drm_device *dev,
+static void vlv_merge_wm(struct drm_i915_private *dev_priv,
struct vlv_wm_values *wm)
{
struct intel_crtc *crtc;
int num_active_crtcs = 0;
- wm->level = to_i915(dev)->wm.max_level;
+ wm->level = dev_priv->wm.max_level;
wm->cxsr = true;
- for_each_intel_crtc(dev, crtc) {
+ for_each_intel_crtc(&dev_priv->drm, crtc) {
const struct vlv_wm_state *wm_state = &crtc->wm_state;
if (!crtc->active)
@@ -1281,7 +1280,7 @@ static void vlv_merge_wm(struct drm_device *dev,
if (num_active_crtcs > 1)
wm->level = VLV_WM_LEVEL_PM2;
- for_each_intel_crtc(dev, crtc) {
+ for_each_intel_crtc(&dev_priv->drm, crtc) {
struct vlv_wm_state *wm_state = &crtc->wm_state;
enum pipe pipe = crtc->pipe;
@@ -1301,13 +1300,12 @@ static void vlv_merge_wm(struct drm_device *dev,
static void vlv_update_wm(struct intel_crtc *crtc)
{
- struct drm_device *dev = crtc->base.dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
struct vlv_wm_values wm = {};
vlv_compute_wm(crtc);
- vlv_merge_wm(dev, &wm);
+ vlv_merge_wm(dev_priv, &wm);
if (memcmp(&dev_priv->wm.vlv, &wm, sizeof(wm)) == 0) {
/* FIXME should be part of crtc atomic commit */
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/15] drm/i915: Protect DSPARB registers with a spinlock
From: Ville Syrjälä
Each DSPARB register can house bits for two separate pipes, hence
we must protect the registers during reprogramming so that parallel
FIFO reconfigurations happening simultaneosly on multiple pipes won't
corrupt each others values.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 6 ++
3 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0fba4bb5655e..c98032e9112b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -811,6 +811,7 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
spin_lock_init(&dev_priv->uncore.lock);
spin_lock_init(&dev_priv->mm.object_stat_lock);
spin_lock_init(&dev_priv->mmio_flip_lock);
+ spin_lock_init(&dev_priv->wm.dsparb_lock);
mutex_init(&dev_priv->sb_lock);
mutex_init(&dev_priv->modeset_restore_lock);
mutex_init(&dev_priv->av_mutex);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9d808b706824..75439e9a67f7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2169,6 +2169,9 @@ struct drm_i915_private {
} sagv_status;
struct {
+ /* protects DSPARB registers on pre-g4x/vlv/chv */
+ spinlock_t dsparb_lock;
+
/*
* Raw watermark latency values:
* in 0.1us units for WM0,
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 24d85a4e4ed3..9f25f2195a6a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1215,6 +1215,8 @@ static void vlv_pipe_set_fifo_size(struct intel_crtc
*crtc)
pipe_name(crtc->pipe), sprite0_start,
sprite1_start, fifo_size);
+ spin_lock(&dev_priv->wm.dsparb_lock);
+
switch (crtc->pipe) {
uint32_t dsparb, dsparb2, dsparb3;
case PIPE_A:
@@ -1271,6 +1273,10 @@ static void vlv_pipe_set_fifo_size(struct intel_crtc
*crtc)
default:
break;
}
+
+ POSTING_READ(DSPARB);
+
+ spin_unlock(&dev_priv->wm.dsparb_lock);
}
#undef VLV_FIFO
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
