Re: [Intel-gfx] [PATCH v7 0/2] Enabling content-type setting for HDMI displays.
Hi Daniel, Could you please check changes in the documentation, I've added a new HDMI connector properties section, based on our discussion. I think now other HDMI specific properties can be transferred there as well. Best Regards, Lisovskiy Stanislav Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo From: dri-devel [dri-devel-boun...@lists.freedesktop.org] on behalf of StanLis [stanislav.lisovs...@intel.com] Sent: Monday, April 23, 2018 10:34 AM To: dri-de...@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Subject: [PATCH v7 0/2] Enabling content-type setting for HDMI displays. From: Stanislav Lisovskiy Added content type setting property to drm_connector(part 1) and enabled transmitting it with HDMI AVI infoframes for i915(part 2). Stanislav Lisovskiy (2): drm: content-type property for HDMI connector i915: content-type property for HDMI connector Documentation/gpu/drm-kms.rst| 6 +++ Documentation/gpu/kms-properties.csv | 1 + drivers/gpu/drm/drm_atomic.c | 17 +++ drivers/gpu/drm/drm_connector.c | 74 drivers/gpu/drm/drm_edid.c | 2 + drivers/gpu/drm/i915/intel_atomic.c | 2 + drivers/gpu/drm/i915/intel_hdmi.c| 4 ++ include/drm/drm_connector.h | 18 +++ include/drm/drm_mode_config.h| 5 ++ include/uapi/drm/drm_mode.h | 7 +++ 10 files changed, 136 insertions(+) -- 2.17.0 ___ dri-devel mailing list dri-de...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: More debug info for fb leaks in mode_config_cleanup
On 04/25/2018 08:49 AM, Daniel Vetter wrote:
On Wed, Apr 25, 2018 at 8:42 AM, Thomas Hellstrom wrote:
Hi,
On 12/07/2017 03:49 PM, Daniel Vetter wrote:
We're spotting this very rarely in CI, but have no idea. Let's add
more debug info about what's going on here.
References:
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D102707&d=DwIFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ&m=HsUZYQaNMPVelJaUQrEYq1PTFDeRDixr0sJ9o5o5NNA&s=Fy9UT786mIt80SvkAKRdBU4Dy-_cr4ita_RmTA4Lqyk&e=
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mode_config.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_mode_config.c
b/drivers/gpu/drm/drm_mode_config.c
index cc78b3d9e5e4..6ffe952142e6 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -469,6 +469,9 @@ void drm_mode_config_cleanup(struct drm_device *dev)
*/
WARN_ON(!list_empty(&dev->mode_config.fb_list));
list_for_each_entry_safe(fb, fbt, &dev->mode_config.fb_list, head)
{
+ struct drm_printer p = drm_debug_printer("[leaked fb]");
+ drm_printf(&p, "framebuffer[%u]:\n", fb->base.id);
+ drm_framebuffer_print_info(&p, 1, fb);
drm_framebuffer_free(&fb->base.refcount);
}
Did we ever get to the bottom of what's causing those framebuffer leaks?
We've seen sporadic framebuffer leaks when transitioning between one and two
screens, but can't seem to repro with the latest drm-fixes branch?
claims the fixes, but that was incomplete. Ville's recent work to
restructure the legacy fb refcounting is meant to plug this leak once
and for all. Given that vmwgfx also has some custom code (for the
fbdev stuff) could very well be that you have such issues too. See:
Yes, hmm, the above doesn't fix our particular issue. I'll keep digging.
Thanks,
Thomas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for YCBCR 4:2:0/4:4:4 output support for LSPCON (rev7)
== Series Details == Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev7) URL : https://patchwork.freedesktop.org/series/36068/ State : failure == Summary == Applying: drm/i915: Introduce CRTC output format Applying: drm/i915: Add CRTC output format YCBCR 4:2:0 error: sha1 information is lacking or useless (drivers/gpu/drm/i915/intel_display.c). error: could not build fake ancestor Patch failed at 0002 drm/i915: Add CRTC output format YCBCR 4:2:0 The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8585/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add documentation to gen9_set_dc_state()
On Tue, Apr 17, 2018 at 02:31:47PM +0300, Imre Deak wrote:
> Add documentation to gen9_set_dc_state() on what enabling a given DC
> state means and at what point HW/DMC actually enters/exits these states.
>
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Signed-off-by: Imre Deak
lgtm.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> [ On IRC I stated that PSR entry would be prevented in a given DC state,
> but looking more at it I haven't found any proof for this. So as I
> understand the only connection between PSR and DC states is that if
> DC5/6 is disabled power saving will be blocked, which would otherwise
> be possible when PSR is active and the display pipe is off. ]
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 53ea564f971e..40a7955886d4 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -542,6 +542,29 @@ void gen9_sanitize_dc_state(struct drm_i915_private
> *dev_priv)
> dev_priv->csr.dc_state = val;
> }
>
> +/**
> + * gen9_set_dc_state - set target display C power state
> + * @dev_priv: i915 device instance
> + * @state: target DC power state
> + * - DC_STATE_DISABLE
> + * - DC_STATE_EN_UPTO_DC5
> + * - DC_STATE_EN_UPTO_DC6
> + * - DC_STATE_EN_DC9
> + *
> + * Signal to DMC firmware/HW the target DC power state passed in @state.
> + * DMC/HW can turn off individual display clocks and power rails when
> entering
> + * a deeper DC power state (higher in number) and turns these back when
> exiting
> + * that state to a shallower power state (lower in number). The HW will
> decide
> + * when to actually enter a given state on an on-demand basis, for instance
> + * depending on the active state of display pipes. The state of display
> + * registers backed by affected power rails are saved/restored as needed.
> + *
> + * Based on the above enabling a deeper DC power state is asynchronous wrt.
> + * enabling it. Disabling a deeper power state is synchronous: for instance
> + * setting %DC_STATE_DISABLE won't complete until all HW resources are turned
> + * back on and register state is restored. This is guaranteed by the MMIO
> write
> + * to DC_STATE_EN blocking until the state is restored.
> + */
> static void gen9_set_dc_state(struct drm_i915_private *dev_priv, uint32_t
> state)
> {
> uint32_t val;
> --
> 2.13.2
>
--
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] input/psmouse: Don't hold the mutex while calling ->disconnect
Ping.
-Daniel
On Tue, Mar 20, 2018 at 9:51 AM, Daniel Vetter wrote:
> At least trackpoint_disconnect wants to remove some sysfs files, and
> we can't remove sysfs files while holding psmouse_mutex:
>
> ==
> WARNING: possible circular locking dependency detected
> 4.16.0-rc5-g613eb885b69e-drmtip_1+ #1 Tainted: G U
> --
> kworker/0:3/102 is trying to acquire lock:
> (kn->count#130){}, at: [<9679748b>]
> kernfs_remove_by_name_ns+0x3b/0x80
>
> but task is already holding lock:
> (psmouse_mutex){+.+.}, at: [<14f44bcc>] psmouse_disconnect+0x62/0x160
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (psmouse_mutex){+.+.}:
>psmouse_attr_set_helper+0x28/0x140
>kernfs_fop_write+0xfe/0x180
>__vfs_write+0x1e/0x130
>vfs_write+0xbd/0x1b0
>SyS_write+0x40/0xa0
>do_syscall_64+0x65/0x1a0
>entry_SYSCALL_64_after_hwframe+0x42/0xb7
>
> -> #0 (kn->count#130){}:
>__kernfs_remove+0x243/0x2b0
>kernfs_remove_by_name_ns+0x3b/0x80
>remove_files.isra.0+0x2b/0x60
>sysfs_remove_group+0x38/0x80
>sysfs_remove_groups+0x24/0x40
>trackpoint_disconnect+0x2c/0x50
>psmouse_disconnect+0x8f/0x160
>serio_disconnect_driver+0x28/0x40
>serio_driver_remove+0xc/0x10
>device_release_driver_internal+0x15b/0x230
>serio_handle_event+0x1c8/0x260
>process_one_work+0x215/0x620
>worker_thread+0x48/0x3a0
>kthread+0xfb/0x130
>ret_from_fork+0x3a/0x50
>
> other info that might help us debug this:
>
> Possible unsafe locking scenario:
>
>CPU0CPU1
>
> lock(psmouse_mutex);
>lock(kn->count#130);
>lock(psmouse_mutex);
> lock(kn->count#130);
>
> *** DEADLOCK ***
>
> 6 locks held by kworker/0:3/102:
> #0: ((wq_completion)"events_long"){+.+.}, at: [<2e408bfa>]
> process_one_work+0x191/0x620
> #1: (serio_event_work){+.+.}, at: [<2e408bfa>]
> process_one_work+0x191/0x620
> #2: (serio_mutex){+.+.}, at: []
> serio_handle_event+0x23/0x260
> #3: (&dev->mutex){}, at: []
> device_release_driver_internal+0x2f/0x230
> #4: (&serio->drv_mutex){+.+.}, at: [<9719f997>]
> serio_disconnect_driver+0x16/0x40
> #5: (psmouse_mutex){+.+.}, at: [<14f44bcc>]
> psmouse_disconnect+0x62/0x160
>
> stack backtrace:
> CPU: 0 PID: 102 Comm: kworker/0:3 Tainted: G U
> 4.16.0-rc5-g613eb885b69e-drmtip_1+ #1
> Hardware name: LENOVO 74591P0/74591P0, BIOS 6DET28WW (1.05 ) 07/30/2008
> Workqueue: events_long serio_handle_event
> Call Trace:
> dump_stack+0x5f/0x86
> print_circular_bug.isra.18+0x1d0/0x2c0
> __lock_acquire+0x14ae/0x1b60
> ? kernfs_remove_by_name_ns+0x20/0x80
> ? lock_acquire+0xaf/0x200
> lock_acquire+0xaf/0x200
> ? kernfs_remove_by_name_ns+0x3b/0x80
> __kernfs_remove+0x243/0x2b0
> ? kernfs_remove_by_name_ns+0x3b/0x80
> ? kernfs_name_hash+0xd/0x70
> ? kernfs_find_ns+0x7e/0x100
> kernfs_remove_by_name_ns+0x3b/0x80
> remove_files.isra.0+0x2b/0x60
> sysfs_remove_group+0x38/0x80
> sysfs_remove_groups+0x24/0x40
> trackpoint_disconnect+0x2c/0x50
> psmouse_disconnect+0x8f/0x160
> serio_disconnect_driver+0x28/0x40
> serio_driver_remove+0xc/0x10
> device_release_driver_internal+0x15b/0x230
> serio_handle_event+0x1c8/0x260
> process_one_work+0x215/0x620
> worker_thread+0x48/0x3a0
> ? _raw_spin_unlock_irqrestore+0x4c/0x60
> kthread+0xfb/0x130
> ? process_one_work+0x620/0x620
> ? _kthread_create_on_node+0x30/0x30
> ret_from_fork+0x3a/0x50
>
> Signed-off-by: Daniel Vetter
> Cc: Dmitry Torokhov
> Cc: Benjamin Tissoires
> Cc: Daniel Vetter
> Cc: Arvind Yadav
> ---
> drivers/input/mouse/psmouse-base.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/input/mouse/psmouse-base.c
> b/drivers/input/mouse/psmouse-base.c
> index 8ac9e03c05b4..6e09a5d6e58a 100644
> --- a/drivers/input/mouse/psmouse-base.c
> +++ b/drivers/input/mouse/psmouse-base.c
> @@ -1467,8 +1467,10 @@ static void psmouse_disconnect(struct serio *serio)
> psmouse_deactivate(parent);
> }
>
> + mutex_unlock(&psmouse_mutex);
> if (psmouse->disconnect)
> psmouse->disconnect(psmouse);
> + mutex_lock(&psmouse_mutex);
>
> if (parent && parent->pt_deactivate)
> parent->pt_deactivate(parent);
> --
> 2.16.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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 2/6] drm/i915: Retire requests along rings
On 24/04/2018 15:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-24 15:46:49)
On 24/04/2018 14:14, Chris Wilson wrote:
In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), leading to much hilarity in miscomputing
the position of ring->head.
As an added bonus, retiring along the ring reduces the penalty of having
one execlists client do cleanup for another (old legacy submission
shares a ring between all clients). The downside is that slow and
irregular (off the critical path) process of cleaning up stale requests
after userspace becomes a modicum less efficient.
In the long run, it will become apparent that the ordered
ring->request_list matches the ring->timeline, a fun challenge for the
future will be unifying the two lists to avoid duplication!
v2: We need both engine-order and ring-order processing to maintain our
knowledge of where individual rings have completed upto as well as
knowing what was last executing on any engine. And finally by decoupling
retiring the contexts on the engine and the timelines along the rings,
we do have to keep a reference to the context on each request
(previously it was guaranteed by the context being pinned).
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
@@ -322,9 +325,9 @@ static void advance_ring(struct i915_request *request)
} else {
tail = request->postfix;
}
- list_del(&request->ring_link);
+ list_del_init(&request->ring_link);
Why the _init flavour? There are two list heads for being on two
separate lists, but are either path reachable after being removed from
the respective lists? (I may find the answer as I read on.)
Yes. rq are held elsewhere and may end up being individually retired
(via the retire_upto paths) multiple times. i915_request_retire() should
only be called once (otherwise asserts).
So init + list_empty() is being used to prevent retiring the same
request multiple times.
- if (engine->last_retired_context)
- engine->context_unpin(engine, engine->last_retired_context);
- engine->last_retired_context = request->ctx;
-
- spin_lock_irq(&request->lock);
- if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &request->fence.flags))
- dma_fence_signal_locked(&request->fence);
- if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &request->fence.flags))
- intel_engine_cancel_signaling(request);
- if (request->waitboost) {
- GEM_BUG_ON(!atomic_read(&request->i915->gt_pm.rps.num_waiters));
- atomic_dec(&request->i915->gt_pm.rps.num_waiters);
- }
- spin_unlock_irq(&request->lock);
+ __retire_engine_upto(request->engine, request);
I did not figure out why do you need to do this. Normally retirement
driven from ring timelines would retire requests on the same engine
belonging to a different ring, as it walks over ring timelines.
Right, so retiring along a ring ends up out of order for a particular
engine.
Only for direct callers of i915_request_retire it may make a difference
but I don't understand is it an functional difference or just optimisation.
I was hoping the GEM_BUG_ON(!list_is_first()); explained the rationale.
Thanks, I remembered after pressing send.
This is then from where list_del_init comes from, since this function
can retire wider than the caller would expect. But then it retires on
the engine (upto) and the callers just walks the list and calls retire
only to find already unlinked elements. Could it just as well then
retire it completely?
We're still trying to only do as little work as we can get away with.
I was thinking about something else, but it was a flawed idea since two
walks are crucial for correct ordering for both engine and ring retirement.
- /* Move the oldest request to the slab-cache (if not in use!) */
- rq = list_first_entry_or_null(&engine->timeline->requests,
- typeof(*rq), link);
+ /* Move our oldest request to the slab-cache (if not in use!) */
+ rq = list_first_entry_or_null(&ring->request_list,
+ typeof(*rq), ring_link);
This is less efficient now - I wonder if you should still be looking at
the engine timeline here?
No, either way you have to walk all engine->requests upto this point, or
all ring->requests. To keep the interface manageable, retirement is in
ring order.
On the other hand, we don't retire as often if we can get away with it.
1 step forwards, 1 step backwards.
AFAIR and AFAICS the point of this was to free up the oldest request
just to help with request recycling as new ones are added. By now
changing it to be oldest on the ring timeline it a) my not be very old,
or b) not even completed, while there might be much older and completed
requests on t
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Retire requests along rings
Quoting Tvrtko Ursulin (2018-04-25 10:30:51) > Related, there could be potential to unify i915_request_retire_upto and > ring_retire_requests. Latter could pass in NULL as the upto request, > just the completed check would need to be different depending on the mode. Also remember that _upto is the public variant, doing the individual request retirement was kept private. As the ordering is paramount, the public version needs to be retire iff first, or retire all/upto. An attempt was made to have one interface that dtrt. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add documentation to gen9_set_dc_state()
Cc: Rodrigo, DK, Ville
On Tue, 17 Apr 2018, Imre Deak wrote:
> Add documentation to gen9_set_dc_state() on what enabling a given DC
> state means and at what point HW/DMC actually enters/exits these states.
>
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> [ On IRC I stated that PSR entry would be prevented in a given DC state,
> but looking more at it I haven't found any proof for this. So as I
> understand the only connection between PSR and DC states is that if
> DC5/6 is disabled power saving will be blocked, which would otherwise
> be possible when PSR is active and the display pipe is off. ]
I think I'm still missing a definitive answer to the question, who
disables PSR before DP AUX transactions?
Does intel_display_power_get(dev_priv, intel_dp->aux_power_domain) in
pps_lock() cause PSR exit, through the DC state change? If yes, this
needs to be properly documented in code. Maybe with a WARN_ON(psr
active) on top.
Quoting bspec 7530, "DDI A AUX channel transactions must not be sent
while SRD is enabled. SRD must be completely disabled before a DDI A AUX
channel transaction can be sent."
I'm also confused how sink CRC would ever work with PSR enabled.
BR,
Jani.
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 53ea564f971e..40a7955886d4 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -542,6 +542,29 @@ void gen9_sanitize_dc_state(struct drm_i915_private
> *dev_priv)
> dev_priv->csr.dc_state = val;
> }
>
> +/**
> + * gen9_set_dc_state - set target display C power state
> + * @dev_priv: i915 device instance
> + * @state: target DC power state
> + * - DC_STATE_DISABLE
> + * - DC_STATE_EN_UPTO_DC5
> + * - DC_STATE_EN_UPTO_DC6
> + * - DC_STATE_EN_DC9
> + *
> + * Signal to DMC firmware/HW the target DC power state passed in @state.
> + * DMC/HW can turn off individual display clocks and power rails when
> entering
> + * a deeper DC power state (higher in number) and turns these back when
> exiting
> + * that state to a shallower power state (lower in number). The HW will
> decide
> + * when to actually enter a given state on an on-demand basis, for instance
> + * depending on the active state of display pipes. The state of display
> + * registers backed by affected power rails are saved/restored as needed.
> + *
> + * Based on the above enabling a deeper DC power state is asynchronous wrt.
> + * enabling it. Disabling a deeper power state is synchronous: for instance
> + * setting %DC_STATE_DISABLE won't complete until all HW resources are turned
> + * back on and register state is restored. This is guaranteed by the MMIO
> write
> + * to DC_STATE_EN blocking until the state is restored.
> + */
> static void gen9_set_dc_state(struct drm_i915_private *dev_priv, uint32_t
> state)
> {
> uint32_t val;
--
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] drm/i915: Add documentation to gen9_set_dc_state()
Argh, now with Ville's correct address.
On Wed, 25 Apr 2018, Jani Nikula wrote:
> Cc: Rodrigo, DK, Ville
>
> On Tue, 17 Apr 2018, Imre Deak wrote:
>> Add documentation to gen9_set_dc_state() on what enabling a given DC
>> state means and at what point HW/DMC actually enters/exits these states.
>>
>> Cc: Jani Nikula
>> Cc: Daniel Vetter
>> Signed-off-by: Imre Deak
>> ---
>> drivers/gpu/drm/i915/intel_runtime_pm.c | 23 +++
>> 1 file changed, 23 insertions(+)
>>
>> [ On IRC I stated that PSR entry would be prevented in a given DC state,
>> but looking more at it I haven't found any proof for this. So as I
>> understand the only connection between PSR and DC states is that if
>> DC5/6 is disabled power saving will be blocked, which would otherwise
>> be possible when PSR is active and the display pipe is off. ]
>
> I think I'm still missing a definitive answer to the question, who
> disables PSR before DP AUX transactions?
>
> Does intel_display_power_get(dev_priv, intel_dp->aux_power_domain) in
> pps_lock() cause PSR exit, through the DC state change? If yes, this
> needs to be properly documented in code. Maybe with a WARN_ON(psr
> active) on top.
>
> Quoting bspec 7530, "DDI A AUX channel transactions must not be sent
> while SRD is enabled. SRD must be completely disabled before a DDI A AUX
> channel transaction can be sent."
>
> I'm also confused how sink CRC would ever work with PSR enabled.
>
> BR,
> Jani.
>
>
>>
>> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> index 53ea564f971e..40a7955886d4 100644
>> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> @@ -542,6 +542,29 @@ void gen9_sanitize_dc_state(struct drm_i915_private
>> *dev_priv)
>> dev_priv->csr.dc_state = val;
>> }
>>
>> +/**
>> + * gen9_set_dc_state - set target display C power state
>> + * @dev_priv: i915 device instance
>> + * @state: target DC power state
>> + * - DC_STATE_DISABLE
>> + * - DC_STATE_EN_UPTO_DC5
>> + * - DC_STATE_EN_UPTO_DC6
>> + * - DC_STATE_EN_DC9
>> + *
>> + * Signal to DMC firmware/HW the target DC power state passed in @state.
>> + * DMC/HW can turn off individual display clocks and power rails when
>> entering
>> + * a deeper DC power state (higher in number) and turns these back when
>> exiting
>> + * that state to a shallower power state (lower in number). The HW will
>> decide
>> + * when to actually enter a given state on an on-demand basis, for instance
>> + * depending on the active state of display pipes. The state of display
>> + * registers backed by affected power rails are saved/restored as needed.
>> + *
>> + * Based on the above enabling a deeper DC power state is asynchronous wrt.
>> + * enabling it. Disabling a deeper power state is synchronous: for instance
>> + * setting %DC_STATE_DISABLE won't complete until all HW resources are
>> turned
>> + * back on and register state is restored. This is guaranteed by the MMIO
>> write
>> + * to DC_STATE_EN blocking until the state is restored.
>> + */
>> static void gen9_set_dc_state(struct drm_i915_private *dev_priv, uint32_t
>> state)
>> {
>> uint32_t val;
--
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] [PATCH 1/7] drm/i915/execlists: Skip lite restore on the currently executing request
When WaIdleLiteRestore isn't enough. --- drivers/gpu/drm/i915/intel_lrc.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 029901a8fa38..5c50263e45d3 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -639,6 +639,19 @@ static void execlists_dequeue(struct intel_engine_cs *engine) if (port_count(&port[1])) goto unlock; + /* +* Skip invoking a lite-restore if we know we have already +* started processing the last request queued to HW. This +* prevents a mystery *unrecoverable* hang on gen8, maybe +* related to updating TAIL within a cacheline of HEAD? (As +* there is still a delay between submitting the ESLP update +* and HW responding, we may still encounter whatever condition +* trips up, just less often.) +*/ + if (i915_seqno_passed(intel_engine_get_seqno(engine), + last->global_seqno - 1)) + goto unlock; + /* * WaIdleLiteRestore:bdw,skl * Apply the wa NOOPs to prevent -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/7] drm/i915: Only track live rings for retiring
We don't need to track every ring for its lifetime as they are managed
by the contexts/engines. What we do want to track are the live rings so
that we can sporadically clean up requests if userspace falls behind. We
can simply restrict the gt->rings list to being only gt->live_rings.
v2: s/live/active/ for consistency with gt.active_requests
Suggested-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/i915_gem.c | 6 --
drivers/gpu/drm/i915/i915_request.c | 10 --
drivers/gpu/drm/i915/intel_ringbuffer.c | 4
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +-
drivers/gpu/drm/i915/selftests/mock_engine.c | 4
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 5 +++--
7 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1837c01d44d0..54351cace362 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2060,7 +2060,8 @@ struct drm_i915_private {
struct i915_gem_timeline global_timeline;
struct list_head timelines;
- struct list_head rings;
+
+ struct list_head active_rings;
u32 active_requests;
u32 request_serial;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 906e2395c245..56c79df5ebce 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -141,6 +141,7 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
{
lockdep_assert_held(&i915->drm.struct_mutex);
GEM_BUG_ON(i915->gt.active_requests);
+ GEM_BUG_ON(!list_empty(&i915->gt.active_rings));
if (!i915->gt.awake)
return I915_EPOCH_INVALID;
@@ -5599,9 +5600,10 @@ int i915_gem_init_early(struct drm_i915_private
*dev_priv)
if (!dev_priv->priorities)
goto err_dependencies;
- mutex_lock(&dev_priv->drm.struct_mutex);
- INIT_LIST_HEAD(&dev_priv->gt.rings);
INIT_LIST_HEAD(&dev_priv->gt.timelines);
+ INIT_LIST_HEAD(&dev_priv->gt.active_rings);
+
+ mutex_lock(&dev_priv->drm.struct_mutex);
err = i915_gem_timeline_init__global(dev_priv);
mutex_unlock(&dev_priv->drm.struct_mutex);
if (err)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index aa84b5447fd5..6301fb0d2319 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -322,6 +322,7 @@ static void advance_ring(struct i915_request *request)
* noops - they are safe to be replayed on a reset.
*/
tail = READ_ONCE(request->tail);
+ list_del(&ring->active_link);
} else {
tail = request->postfix;
}
@@ -1084,6 +1085,8 @@ void __i915_request_add(struct i915_request *request,
bool flush_caches)
i915_gem_active_set(&timeline->last_request, request);
list_add_tail(&request->ring_link, &ring->request_list);
+ if (list_is_first(&request->ring_link, &ring->request_list))
+ list_add(&ring->active_link, &request->i915->gt.active_rings);
request->emitted_jiffies = jiffies;
/*
@@ -1406,14 +1409,17 @@ static void ring_retire_requests(struct intel_ring
*ring)
void i915_retire_requests(struct drm_i915_private *i915)
{
- struct intel_ring *ring, *next;
+ struct intel_ring *ring, *tmp;
lockdep_assert_held(&i915->drm.struct_mutex);
if (!i915->gt.active_requests)
return;
- list_for_each_entry_safe(ring, next, &i915->gt.rings, link)
+ /* An outstanding request must be on a still active ring somewhere */
+ GEM_BUG_ON(list_empty(&i915->gt.active_rings));
+
+ list_for_each_entry_safe(ring, tmp, &i915->gt.active_rings, active_link)
ring_retire_requests(ring);
}
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 75dca28782ee..3d02b2c779e7 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1149,8 +1149,6 @@ intel_engine_create_ring(struct intel_engine_cs *engine,
int size)
}
ring->vma = vma;
- list_add(&ring->link, &engine->i915->gt.rings);
-
return ring;
}
@@ -1162,8 +1160,6 @@ intel_ring_free(struct intel_ring *ring)
i915_vma_close(ring->vma);
__i915_gem_object_release_unless_active(obj);
- list_del(&ring->link);
-
kfree(ring);
}
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index d816f8dea245..e8d17bcd9bee 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -129,7 +12
[Intel-gfx] [PATCH 6/7] drm/i915: Split i915_gem_timeline into individual timelines
We need to move to a more flexible timeline that doesn't assume one
fence context per engine, and so allow for a single timeline to be used
across a combination of engines. This means that preallocating a fence
context per engine is now a hindrance, and so we want to introduce the
singular timeline. From the code perspective, this has the notable
advantage of clearing up a lot of mirky semantics and some clumsy
pointer chasing.
By splitting the timeline up into a single entity rather than an array
of per-engine timelines, we can realise the goal of the previous patch
of tracking the timeline alongside the ring.
v2: Tweak wait_for_idle to stop the compiling thinking that ret may be
uninitialised.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/Makefile | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/i915_gem.c | 129 +---
drivers/gpu/drm/i915/i915_gem_context.c | 49 ++---
drivers/gpu/drm/i915/i915_gem_context.h | 2 -
drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +-
drivers/gpu/drm/i915/i915_gem_timeline.c | 198 --
drivers/gpu/drm/i915/i915_gpu_error.c | 4 +-
drivers/gpu/drm/i915/i915_perf.c | 10 +-
drivers/gpu/drm/i915/i915_request.c | 68 +++---
drivers/gpu/drm/i915/i915_request.h | 3 +-
drivers/gpu/drm/i915/i915_timeline.c | 105 ++
.../{i915_gem_timeline.h => i915_timeline.h} | 67 +++---
drivers/gpu/drm/i915/intel_engine_cs.c| 27 ++-
drivers/gpu/drm/i915/intel_guc_submission.c | 4 +-
drivers/gpu/drm/i915/intel_lrc.c | 48 +++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 25 ++-
drivers/gpu/drm/i915/intel_ringbuffer.h | 11 +-
.../{i915_gem_timeline.c => i915_timeline.c} | 94 +++--
drivers/gpu/drm/i915/selftests/mock_engine.c | 32 ++-
.../gpu/drm/i915/selftests/mock_gem_device.c | 10 +-
.../gpu/drm/i915/selftests/mock_timeline.c| 45 ++--
.../gpu/drm/i915/selftests/mock_timeline.h| 28 +--
23 files changed, 398 insertions(+), 570 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/i915_gem_timeline.c
create mode 100644 drivers/gpu/drm/i915/i915_timeline.c
rename drivers/gpu/drm/i915/{i915_gem_timeline.h => i915_timeline.h} (68%)
rename drivers/gpu/drm/i915/selftests/{i915_gem_timeline.c => i915_timeline.c}
(70%)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9bee52a949a9..120db21fcd50 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -67,11 +67,11 @@ i915-y += i915_cmd_parser.o \
i915_gem_shrinker.o \
i915_gem_stolen.o \
i915_gem_tiling.o \
- i915_gem_timeline.o \
i915_gem_userptr.o \
i915_gemfs.o \
i915_query.o \
i915_request.o \
+ i915_timeline.o \
i915_trace_points.o \
i915_vma.o \
intel_breadcrumbs.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b9bd8328f501..dab15b6abc3c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -72,10 +72,10 @@
#include "i915_gem_fence_reg.h"
#include "i915_gem_object.h"
#include "i915_gem_gtt.h"
-#include "i915_gem_timeline.h"
#include "i915_gpu_error.h"
#include "i915_request.h"
#include "i915_scheduler.h"
+#include "i915_timeline.h"
#include "i915_vma.h"
#include "intel_gvt.h"
@@ -2058,8 +2058,6 @@ struct drm_i915_private {
void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
- struct i915_gem_timeline execution_timeline;
- struct i915_gem_timeline legacy_timeline;
struct list_head timelines;
struct list_head active_rings;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d60f3bd4bc66..44cf67f713c7 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -162,7 +162,7 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
synchronize_irq(i915->drm.irq);
intel_engines_park(i915);
- i915_gem_timelines_park(i915);
+ i915_timelines_park(i915);
i915_pmu_gt_parked(i915);
@@ -2977,8 +2977,8 @@ i915_gem_find_active_request(struct intel_engine_cs
*engine)
* extra delay for a recent interrupt is pointless. Hence, we do
* not need an engine->irq_seqno_barrier() before the seqno reads.
*/
- spin_lock_irqsave(&engine->timeline->lock, flags);
- list_for_each_entry(request, &engine->timeline->requests, link) {
+ spin_lock_irqsave(&engine->timeline.lock, flags);
+ list_for_each_entry(request, &engine->timeline.requests, link) {
if (__i915_request_completed(request, request->global_seqno))
contin
[Intel-gfx] [PATCH 5/7] drm/i915: Move timeline from GTT to ring
In the future, we want to move a request between engines. To achieve
this, we first realise that we have two timelines in effect here. The
first runs through the GTT is required for ordering vma access, which is
tracked currently by engine. The second is implied by sequential
execution of commands inside the ringbuffer. This timeline is one that
maps to userspace's expectations when submitting requests (i.e. given the
same context, batch A is executed before batch B). As the rings's
timelines map to userspace and the GTT timeline an implementation
detail, move the timeline from the GTT into the ring itself (per-context
in logical-ring-contexts/execlists, or a global per-engine timeline for
the shared ringbuffers in legacy submission.
The two timelines are still assumed to be equivalent at the moment (no
migrating requests between engines yet) and so we can simply move from
one to the other without adding extra ordering.
v2: Reinforce that one isn't allowed to mix the engine execution
timeline with the client timeline from userspace (on the ring).
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 13 +
drivers/gpu/drm/i915/i915_gem.c | 9 ++--
drivers/gpu/drm/i915/i915_gem_context.c | 15 +-
drivers/gpu/drm/i915/i915_gem_context.h | 2 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 --
drivers/gpu/drm/i915/i915_gem_gtt.h | 1 -
drivers/gpu/drm/i915/i915_gem_timeline.c | 54 +--
drivers/gpu/drm/i915/i915_gem_timeline.h | 4 ++
drivers/gpu/drm/i915/i915_request.c | 13 +++--
drivers/gpu/drm/i915/intel_engine_cs.c| 3 +-
drivers/gpu/drm/i915/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 10 +++-
drivers/gpu/drm/i915/intel_ringbuffer.h | 5 +-
drivers/gpu/drm/i915/selftests/mock_engine.c | 3 +-
.../gpu/drm/i915/selftests/mock_gem_device.c | 4 +-
drivers/gpu/drm/i915/selftests/mock_gtt.c | 1 -
16 files changed, 101 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 54351cace362..b9bd8328f501 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2058,7 +2058,8 @@ struct drm_i915_private {
void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
- struct i915_gem_timeline global_timeline;
+ struct i915_gem_timeline execution_timeline;
+ struct i915_gem_timeline legacy_timeline;
struct list_head timelines;
struct list_head active_rings;
@@ -3234,16 +3235,6 @@ i915_gem_context_lookup(struct drm_i915_file_private
*file_priv, u32 id)
return ctx;
}
-static inline struct intel_timeline *
-i915_gem_context_lookup_timeline(struct i915_gem_context *ctx,
-struct intel_engine_cs *engine)
-{
- struct i915_address_space *vm;
-
- vm = ctx->ppgtt ? &ctx->ppgtt->base : &ctx->i915->ggtt.base;
- return &vm->timeline.engine[engine->id];
-}
-
int i915_perf_open_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
int i915_perf_add_config_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 56c79df5ebce..d60f3bd4bc66 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3110,10 +3110,10 @@ static void engine_skip_context(struct i915_request
*request)
{
struct intel_engine_cs *engine = request->engine;
struct i915_gem_context *hung_ctx = request->ctx;
- struct intel_timeline *timeline;
+ struct intel_timeline *timeline = request->timeline;
unsigned long flags;
- timeline = i915_gem_context_lookup_timeline(hung_ctx, engine);
+ GEM_BUG_ON(timeline == engine->timeline);
spin_lock_irqsave(&engine->timeline->lock, flags);
spin_lock(&timeline->lock);
@@ -3782,7 +3782,7 @@ int i915_gem_wait_for_idle(struct drm_i915_private *i915,
unsigned int flags)
ret = wait_for_engines(i915);
} else {
- ret = wait_for_timeline(&i915->gt.global_timeline, flags);
+ ret = wait_for_timeline(&i915->gt.execution_timeline, flags);
}
return ret;
@@ -5652,7 +5652,8 @@ void i915_gem_cleanup_early(struct drm_i915_private
*dev_priv)
WARN_ON(dev_priv->mm.object_count);
mutex_lock(&dev_priv->drm.struct_mutex);
- i915_gem_timeline_fini(&dev_priv->gt.global_timeline);
+ i915_gem_timeline_fini(&dev_priv->gt.legacy_timeline);
+ i915_gem_timeline_fini(&dev_priv->gt.execution_timeline);
WARN_ON(!list_empty(&dev_priv->gt.timelines));
mutex_unlock(&dev_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.
[Intel-gfx] [PATCH 2/7] drm/i915: Stop tracking timeline->inflight_seqnos
In commit 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine"), we
moved from a global inflight counter to per-engine counters in the
hope that will be easy to run concurrently in future. However, with the
advent of the desire to move requests between engines, we do need a
global counter to preserve the semantics that no engine wraps in the
middle of a submit. (Although this semantic is now only required for gen7
semaphore support, which only supports greater-then comparisons!)
v2: Keep a global counter of all requests ever submitted and force the
reset when it wraps.
References: 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 5 ++--
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem_timeline.h | 6 -
drivers/gpu/drm/i915/i915_request.c | 33
drivers/gpu/drm/i915/intel_engine_cs.c | 5 ++--
5 files changed, 22 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2f05f5262bba..547e97102b85 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1340,10 +1340,9 @@ static int i915_hangcheck_info(struct seq_file *m, void
*unused)
struct rb_node *rb;
seq_printf(m, "%s:\n", engine->name);
- seq_printf(m, "\tseqno = %x [current %x, last %x], inflight
%d\n",
+ seq_printf(m, "\tseqno = %x [current %x, last %x]\n",
engine->hangcheck.seqno, seqno[id],
- intel_engine_last_submit(engine),
- engine->timeline->inflight_seqnos);
+ intel_engine_last_submit(engine));
seq_printf(m, "\twaiters? %s, fake irq active? %s, stalled?
%s\n",
yesno(intel_engine_has_waiter(engine)),
yesno(test_bit(engine->id,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8444ca8d5aa3..8fd9fb6efba5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2061,6 +2061,7 @@ struct drm_i915_private {
struct list_head timelines;
struct i915_gem_timeline global_timeline;
u32 active_requests;
+ u32 request_serial;
/**
* Is the GPU currently considered idle, or busy executing
diff --git a/drivers/gpu/drm/i915/i915_gem_timeline.h
b/drivers/gpu/drm/i915/i915_gem_timeline.h
index 33e01bf6aa36..6e82119e2cd8 100644
--- a/drivers/gpu/drm/i915/i915_gem_timeline.h
+++ b/drivers/gpu/drm/i915/i915_gem_timeline.h
@@ -37,12 +37,6 @@ struct intel_timeline {
u64 fence_context;
u32 seqno;
- /**
-* Count of outstanding requests, from the time they are constructed
-* to the moment they are retired. Loosely coupled to hardware.
-*/
- u32 inflight_seqnos;
-
spinlock_t lock;
/**
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index b692a9f7c357..b1993d4a1a53 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -241,6 +241,7 @@ static int reset_all_global_seqno(struct drm_i915_private
*i915, u32 seqno)
sizeof(timeline->engine[id].global_sync));
}
+ i915->gt.request_serial = seqno;
return 0;
}
@@ -257,18 +258,22 @@ int i915_gem_set_global_seqno(struct drm_device *dev, u32
seqno)
return reset_all_global_seqno(i915, seqno - 1);
}
-static int reserve_engine(struct intel_engine_cs *engine)
+static int reserve_gt(struct drm_i915_private *i915)
{
- struct drm_i915_private *i915 = engine->i915;
- u32 active = ++engine->timeline->inflight_seqnos;
- u32 seqno = engine->timeline->seqno;
int ret;
- /* Reservation is fine until we need to wrap around */
- if (unlikely(add_overflows(seqno, active))) {
+ /*
+* Reservation is fine until we may need to wrap around
+*
+* By incrementing the serial for every request, we know that no
+* individual engine may exceed that serial (as each is reset to 0
+* on any wrap). This protects even the most pessimistic of migrations
+* of every request from all engines onto just one.
+*/
+ while (unlikely(++i915->gt.request_serial == 0)) {
ret = reset_all_global_seqno(i915, 0);
if (ret) {
- engine->timeline->inflight_seqnos--;
+ i915->gt.request_serial--;
return ret;
}
}
@@ -279,15 +284,10 @@ static int reserve_engine(struct intel_engine_cs *engine)
return 0;
}
-static void unreserve_engine(struct intel_engine_cs *engin
[Intel-gfx] [PATCH 3/7] drm/i915: Retire requests along rings
In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), leading to much hilarity in miscomputing
the position of ring->head.
As an added bonus, retiring along the ring reduces the penalty of having
one execlists client do cleanup for another (old legacy submission
shares a ring between all clients). The downside is that slow and
irregular (off the critical path) process of cleaning up stale requests
after userspace becomes a modicum less efficient.
In the long run, it will become apparent that the ordered
ring->request_list matches the ring->timeline, a fun challenge for the
future will be unifying the two lists to avoid duplication!
v2: We need both engine-order and ring-order processing to maintain our
knowledge of where individual rings have completed upto as well as
knowing what was last executing on any engine. And finally by decoupling
retiring the contexts on the engine and the timelines along the rings,
we do have to keep a reference to the context on each request
(previously it was guaranteed by the context being pinned).
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 3 +-
drivers/gpu/drm/i915/i915_gem.c | 1 +
drivers/gpu/drm/i915/i915_request.c | 140 +++---
drivers/gpu/drm/i915/i915_utils.h | 6 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 6 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
drivers/gpu/drm/i915/selftests/mock_engine.c | 27 +++-
.../gpu/drm/i915/selftests/mock_gem_device.c | 2 +
8 files changed, 120 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8fd9fb6efba5..1837c01d44d0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2058,8 +2058,9 @@ struct drm_i915_private {
void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
- struct list_head timelines;
struct i915_gem_timeline global_timeline;
+ struct list_head timelines;
+ struct list_head rings;
u32 active_requests;
u32 request_serial;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 795ca83aed7a..906e2395c245 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5600,6 +5600,7 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
goto err_dependencies;
mutex_lock(&dev_priv->drm.struct_mutex);
+ INIT_LIST_HEAD(&dev_priv->gt.rings);
INIT_LIST_HEAD(&dev_priv->gt.timelines);
err = i915_gem_timeline_init__global(dev_priv);
mutex_unlock(&dev_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index b1993d4a1a53..aa84b5447fd5 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -286,6 +286,7 @@ static int reserve_gt(struct drm_i915_private *i915)
static void unreserve_gt(struct drm_i915_private *i915)
{
+ GEM_BUG_ON(!i915->gt.active_requests);
if (!--i915->gt.active_requests)
i915_gem_park(i915);
}
@@ -298,6 +299,7 @@ void i915_gem_retire_noop(struct i915_gem_active *active,
static void advance_ring(struct i915_request *request)
{
+ struct intel_ring *ring = request->ring;
unsigned int tail;
/*
@@ -309,7 +311,8 @@ static void advance_ring(struct i915_request *request)
* Note this requires that we are always called in request
* completion order.
*/
- if (list_is_last(&request->ring_link, &request->ring->request_list)) {
+ GEM_BUG_ON(!list_is_first(&request->ring_link, &ring->request_list));
+ if (list_is_last(&request->ring_link, &ring->request_list)) {
/*
* We may race here with execlists resubmitting this request
* as we retire it. The resubmission will move the ring->tail
@@ -322,9 +325,9 @@ static void advance_ring(struct i915_request *request)
} else {
tail = request->postfix;
}
- list_del(&request->ring_link);
+ list_del_init(&request->ring_link);
- request->ring->head = tail;
+ ring->head = tail;
}
static void free_capture_list(struct i915_request *request)
@@ -340,30 +343,79 @@ static void free_capture_list(struct i915_request
*request)
}
}
+static void __retire_engine_request(struct intel_engine_cs *engine,
+ struct i915_request *request)
+{
+ GEM_BUG_ON(!i915_request_completed(request));
+
+ local_irq_disable();
+
+ spin_
[Intel-gfx] [PATCH 7/7] drm/i915: Lazily unbind vma on close
When userspace is passing around swapbuffers using DRI, we frequently
have to open and close the same object in the foreign address space.
This shows itself as the same object being rebound at roughly 30fps
(with a second object also being rebound at 30fps), which involves us
having to rewrite the page tables and maintain the drm_mm range manager
every time.
However, since the object still exists and it is only the local handle
that disappears, if we are lazy and do not unbind the VMA immediately
when the local user closes the object but defer it until the GPU is
idle, then we can reuse the same VMA binding. We still have to be
careful to mark the handle and lookup tables as closed to maintain the
uABI, just allowing the underlying VMA to be resurrected if the user is
able to access the same object from the same context again.
If the object itself is destroyed (neither userspace keeping a handle to
it), the VMA will be reaped immediately as usual.
In the future, this will be even more useful as instantiating a new VMA
for use on the GPU will become heavier. A nuisance indeed, so nip it in
the bud.
v2: s/__i915_vma_final_close/i915_vma_destroy/ etc.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 4 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c| 3 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 14 +++--
drivers/gpu/drm/i915/i915_vma.c | 61 +--
drivers/gpu/drm/i915/i915_vma.h | 6 ++
drivers/gpu/drm/i915/selftests/huge_pages.c | 2 +-
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 +
8 files changed, 67 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dab15b6abc3c..d4da9f941d04 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2061,6 +2061,7 @@ struct drm_i915_private {
struct list_head timelines;
struct list_head active_rings;
+ struct list_head closed_vma;
u32 active_requests;
u32 request_serial;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 44cf67f713c7..7f72dfa87b01 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -165,6 +165,7 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
i915_timelines_park(i915);
i915_pmu_gt_parked(i915);
+ i915_vma_parked(i915);
i915->gt.awake = false;
@@ -4795,7 +4796,7 @@ static void __i915_gem_free_objects(struct
drm_i915_private *i915,
&obj->vma_list, obj_link) {
GEM_BUG_ON(i915_vma_is_active(vma));
vma->flags &= ~I915_VMA_PIN_MASK;
- i915_vma_close(vma);
+ i915_vma_destroy(vma);
}
GEM_BUG_ON(!list_empty(&obj->vma_list));
GEM_BUG_ON(!RB_EMPTY_ROOT(&obj->vma_tree));
@@ -5598,6 +5599,7 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
INIT_LIST_HEAD(&dev_priv->gt.timelines);
INIT_LIST_HEAD(&dev_priv->gt.active_rings);
+ INIT_LIST_HEAD(&dev_priv->gt.closed_vma);
i915_gem_init__mm(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index c74f5df3fb5a..f627a8c47c58 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -762,7 +762,8 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
}
/* transfer ref to ctx */
- vma->open_count++;
+ if (!vma->open_count++)
+ i915_vma_reopen(vma);
list_add(&lut->obj_link, &obj->lut_list);
list_add(&lut->ctx_link, &eb->ctx->handles_list);
lut->ctx = eb->ctx;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e9d828324f67..272d6bb407cc 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2218,6 +2218,12 @@ i915_ppgtt_create(struct drm_i915_private *dev_priv,
}
void i915_ppgtt_close(struct i915_address_space *vm)
+{
+ GEM_BUG_ON(vm->closed);
+ vm->closed = true;
+}
+
+static void ppgtt_destroy_vma(struct i915_address_space *vm)
{
struct list_head *phases[] = {
&vm->active_list,
@@ -2226,15 +2232,12 @@ void i915_ppgtt_close(struct i915_address_space *vm)
NULL,
}, **phase;
- GEM_BUG_ON(vm->closed);
vm->closed = true;
-
for (phase = phases; *phase; phase++) {
struct i915_vma *vma, *vn;
list_for_each_entry_safe(vma, vn, *phase, vm_link)
- if (!i915_vma_is_closed(vma))
-
[Intel-gfx] [PATCH] drm/i915/execlists: Skip lite restore on the currently executing request
When WaIdleLiteRestore isn't enough. Fixes an odd hang on gen8 (both bsw and bdw) during gem_ctx_switch, where by all intents and purposes if we trigger a lite-restore as it is processing the pipecontrol flushes, the RING is restored to the oword following the command and tries to execute the destination address for the pipecontrol rather than a valid command. With the theory being that it doesn't like RING_HEAD being within a cacheline of the restored RING_TAIL, we can evade that issue by not triggering a lite-restore if we know we are inside the last request. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_lrc.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 029901a8fa38..5c50263e45d3 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -639,6 +639,19 @@ static void execlists_dequeue(struct intel_engine_cs *engine) if (port_count(&port[1])) goto unlock; + /* +* Skip invoking a lite-restore if we know we have already +* started processing the last request queued to HW. This +* prevents a mystery *unrecoverable* hang on gen8, maybe +* related to updating TAIL within a cacheline of HEAD? (As +* there is still a delay between submitting the ESLP update +* and HW responding, we may still encounter whatever condition +* trips up, just less often.) +*/ + if (i915_seqno_passed(intel_engine_get_seqno(engine), + last->global_seqno - 1)) + goto unlock; + /* * WaIdleLiteRestore:bdw,skl * Apply the wa NOOPs to prevent -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add documentation to gen9_set_dc_state()
On Wed, Apr 25, 2018 at 12:50:06PM +0300, Jani Nikula wrote:
>
> Argh, now with Ville's correct address.
>
> On Wed, 25 Apr 2018, Jani Nikula wrote:
> > Cc: Rodrigo, DK, Ville
> >
> > On Tue, 17 Apr 2018, Imre Deak wrote:
> >> Add documentation to gen9_set_dc_state() on what enabling a given DC
> >> state means and at what point HW/DMC actually enters/exits these states.
> >>
> >> Cc: Jani Nikula
> >> Cc: Daniel Vetter
> >> Signed-off-by: Imre Deak
> >> ---
> >> drivers/gpu/drm/i915/intel_runtime_pm.c | 23 +++
> >> 1 file changed, 23 insertions(+)
> >>
> >> [ On IRC I stated that PSR entry would be prevented in a given DC state,
> >> but looking more at it I haven't found any proof for this. So as I
> >> understand the only connection between PSR and DC states is that if
> >> DC5/6 is disabled power saving will be blocked, which would otherwise
> >> be possible when PSR is active and the display pipe is off. ]
> >
> > I think I'm still missing a definitive answer to the question, who
> > disables PSR before DP AUX transactions?
> >
> > Does intel_display_power_get(dev_priv, intel_dp->aux_power_domain) in
> > pps_lock() cause PSR exit, through the DC state change? If yes, this
> > needs to be properly documented in code. Maybe with a WARN_ON(psr
> > active) on top.
No, that was only my misunderstanding earlier on IRC. Disabling DC
states doesn't prevent PSR entry. So the PSR active state is independent
of DC states; if PSR is enabled with DC5/6 disabled it just means there
will be less power saving during PSR active periods than it would be
possible with DC5/6 enabled.
Disabling PSR then has to happen by some other means while the driver
performs AUX transfers, either disabling it manually from the driver, or
by using the AUX HW mutex.
> >
> > Quoting bspec 7530, "DDI A AUX channel transactions must not be sent
> > while SRD is enabled. SRD must be completely disabled before a DDI A AUX
> > channel transaction can be sent."
> >
> > I'm also confused how sink CRC would ever work with PSR enabled.
> >
> > BR,
> > Jani.
> >
> >
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> >> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> >> index 53ea564f971e..40a7955886d4 100644
> >> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> >> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> >> @@ -542,6 +542,29 @@ void gen9_sanitize_dc_state(struct drm_i915_private
> >> *dev_priv)
> >>dev_priv->csr.dc_state = val;
> >> }
> >>
> >> +/**
> >> + * gen9_set_dc_state - set target display C power state
> >> + * @dev_priv: i915 device instance
> >> + * @state: target DC power state
> >> + * - DC_STATE_DISABLE
> >> + * - DC_STATE_EN_UPTO_DC5
> >> + * - DC_STATE_EN_UPTO_DC6
> >> + * - DC_STATE_EN_DC9
> >> + *
> >> + * Signal to DMC firmware/HW the target DC power state passed in @state.
> >> + * DMC/HW can turn off individual display clocks and power rails when
> >> entering
> >> + * a deeper DC power state (higher in number) and turns these back when
> >> exiting
> >> + * that state to a shallower power state (lower in number). The HW will
> >> decide
> >> + * when to actually enter a given state on an on-demand basis, for
> >> instance
> >> + * depending on the active state of display pipes. The state of display
> >> + * registers backed by affected power rails are saved/restored as needed.
> >> + *
> >> + * Based on the above enabling a deeper DC power state is asynchronous
> >> wrt.
> >> + * enabling it. Disabling a deeper power state is synchronous: for
> >> instance
> >> + * setting %DC_STATE_DISABLE won't complete until all HW resources are
> >> turned
> >> + * back on and register state is restored. This is guaranteed by the MMIO
> >> write
> >> + * to DC_STATE_EN blocking until the state is restored.
> >> + */
> >> static void gen9_set_dc_state(struct drm_i915_private *dev_priv, uint32_t
> >> state)
> >> {
> >>uint32_t val;
>
> --
> 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] drm/i915/execlists: Skip lite restore on the currently executing request
Chris Wilson writes: > When WaIdleLiteRestore isn't enough. > > Fixes an odd hang on gen8 (both bsw and bdw) during gem_ctx_switch, Do you have a testcase name? (testcase tag would be nice too) > where by all intents and purposes if we trigger a lite-restore as it is > processing the pipecontrol flushes, the RING is restored to the oword s/RING/RING_HEAD ? > following the command and tries to execute the destination address for > the pipecontrol rather than a valid command. With the theory being that > it doesn't like RING_HEAD being within a cacheline of the restored > RING_TAIL, we can evade that issue by not triggering a lite-restore if > we know we are inside the last request. > > Signed-off-by: Chris Wilson > --- > drivers/gpu/drm/i915/intel_lrc.c | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c > b/drivers/gpu/drm/i915/intel_lrc.c > index 029901a8fa38..5c50263e45d3 100644 > --- a/drivers/gpu/drm/i915/intel_lrc.c > +++ b/drivers/gpu/drm/i915/intel_lrc.c > @@ -639,6 +639,19 @@ static void execlists_dequeue(struct intel_engine_cs > *engine) > if (port_count(&port[1])) > goto unlock; > > + /* > + * Skip invoking a lite-restore if we know we have already > + * started processing the last request queued to HW. This > + * prevents a mystery *unrecoverable* hang on gen8, maybe > + * related to updating TAIL within a cacheline of HEAD? (As Did you try with WA_TAIL_DWORDS 16? -Mika > + * there is still a delay between submitting the ESLP update > + * and HW responding, we may still encounter whatever condition > + * trips up, just less often.) > + */ > + if (i915_seqno_passed(intel_engine_get_seqno(engine), > + last->global_seqno - 1)) > + goto unlock; > + > /* >* WaIdleLiteRestore:bdw,skl >* Apply the wa NOOPs to prevent > -- > 2.17.0 > > ___ > 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] drm/i915/execlists: Skip lite restore on the currently executing request
Quoting Mika Kuoppala (2018-04-25 12:19:08) > Chris Wilson writes: > > > When WaIdleLiteRestore isn't enough. > > > > Fixes an odd hang on gen8 (both bsw and bdw) during gem_ctx_switch, > > Do you have a testcase name? (testcase tag would be nice too) Just keep running gem_ctx_switch. Switching between the static set of contexts, no rebind pressure whatsoever. > > where by all intents and purposes if we trigger a lite-restore as it is > > processing the pipecontrol flushes, the RING is restored to the oword > > s/RING/RING_HEAD ? > > > following the command and tries to execute the destination address for > > the pipecontrol rather than a valid command. With the theory being that > > it doesn't like RING_HEAD being within a cacheline of the restored > > RING_TAIL, we can evade that issue by not triggering a lite-restore if > > we know we are inside the last request. > > > > Signed-off-by: Chris Wilson > > --- > > drivers/gpu/drm/i915/intel_lrc.c | 13 + > > 1 file changed, 13 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c > > b/drivers/gpu/drm/i915/intel_lrc.c > > index 029901a8fa38..5c50263e45d3 100644 > > --- a/drivers/gpu/drm/i915/intel_lrc.c > > +++ b/drivers/gpu/drm/i915/intel_lrc.c > > @@ -639,6 +639,19 @@ static void execlists_dequeue(struct intel_engine_cs > > *engine) > > if (port_count(&port[1])) > > goto unlock; > > > > + /* > > + * Skip invoking a lite-restore if we know we have already > > + * started processing the last request queued to HW. This > > + * prevents a mystery *unrecoverable* hang on gen8, maybe > > + * related to updating TAIL within a cacheline of HEAD? (As > > Did you try with WA_TAIL_DWORDS 16? Sure can try, but the error state doesn't indicate TAIL==HEAD as would be the issue with WaIdleLiteRestore (restoring to an idle ring wouldn't generate the arbitration event, so no more context switches). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Skip lite restore on the currently executing request
Quoting Chris Wilson (2018-04-25 12:23:30) > Quoting Mika Kuoppala (2018-04-25 12:19:08) > > Did you try with WA_TAIL_DWORDS 16? > > Sure can try, but the error state doesn't indicate TAIL==HEAD as would > be the issue with WaIdleLiteRestore (restoring to an idle ring wouldn't > generate the arbitration event, so no more context switches). Watch https://patchwork.freedesktop.org/series/42284/ Actually surviving on my bdw -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/8] drm/i915: per context slice/subslice powergating
Hi all, This is an update a series that was sent out a few months ago. The end goal here is to optimize some media workloads. Here is some information provided by Dmitry (cc) on why we want this : Video decoding/encoding tends to work with macroblocks, dividing up a frame into smaller elements. Dependencies exist between those macroblocks, meaning that they cannot be processed in a random order and also there is a maximum number of macroblock that can process at a given time (called wave front). As a result, some workloads (below a certain resolution) will not make use of all the GPU's execution units. On a SKLGT4 (3 slices), for a transcoding workload at a 720x480p, we were able to measure a low number of active EUs (~3%) with 3 slices enabled. As we reduce the number of slices used to 1, the percentage of active EUs obviously increases (~9%). The execution time of the workload also decreases as we decrease the number of slices used (we measure an up to ~20% improvement with 1 slice). It's not clear what speeds up the workload. We currently think that the power budget is redistributed to other parts (including the CPU) and that the GPU thread scheduling is also sped up because it doesn't involve as many slices. We haven't found a way to measure these assumptions. Changing the powergating configuration doesn't come free though. We have some numbers in an IGT benchmark on how much delay is added each time we switch between 2 contexts of different powergating configurations. Measurements are in the order of ~50us on SKLGT4 (3 slices) and ~40us on KBLGT3 (2 slices). Cheers, Chris Wilson (3): drm/i915: Program RPCS for Broadwell drm/i915: Record the sseu configuration per-context & engine drm/i915: Expose RPCS (SSEU) configuration to userspace Lionel Landwerlin (5): drm/i915: expose helper mapping exec flag engine to intel_engine_cs drm/i915: don't specify pinned size for wa_bb pin/allocation drm/i915: extract per-ctx/indirect bb programming drm/i915: pass wa_ctx as argument drm/i915: reprogram NOA muxes on context switch when using perf drivers/gpu/drm/i915/i915_drv.h| 5 + drivers/gpu/drm/i915/i915_gem_context.c| 104 +- drivers/gpu/drm/i915/i915_gem_context.h| 10 + drivers/gpu/drm/i915/i915_gem_execbuffer.c | 18 +- drivers/gpu/drm/i915/i915_perf.c | 92 +++- drivers/gpu/drm/i915/intel_lrc.c | 231 - drivers/gpu/drm/i915/intel_lrc.h | 5 + include/uapi/drm/i915_drm.h| 28 +++ 8 files changed, 419 insertions(+), 74 deletions(-) -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/8] drm/i915: extract per-ctx/indirect bb programming
Let's put this in its own function to reuse it later.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/intel_lrc.c | 59 ++--
1 file changed, 34 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3ca5a1d33fe9..56515091beb4 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2392,6 +2392,38 @@ static u32 intel_lr_indirect_ctx_offset(struct
intel_engine_cs *engine)
return indirect_ctx_offset;
}
+static void execlists_init_reg_state_wa_bb(u32 *regs,
+ struct intel_engine_cs *engine)
+{
+ struct i915_ctx_workarounds *wa_ctx = &engine->wa_ctx;
+ u32 base = engine->mmio_base;
+ u32 ggtt_offset;
+
+ if (!wa_ctx->vma)
+ return;
+
+ ggtt_offset = i915_ggtt_offset(wa_ctx->vma);
+
+ CTX_REG(regs, CTX_RCS_INDIRECT_CTX, RING_INDIRECT_CTX(base), 0);
+ CTX_REG(regs, CTX_RCS_INDIRECT_CTX_OFFSET,
+ RING_INDIRECT_CTX_OFFSET(base), 0);
+ if (wa_ctx->indirect_ctx.size) {
+ regs[CTX_RCS_INDIRECT_CTX + 1] =
+ (ggtt_offset + wa_ctx->indirect_ctx.offset) |
+ (wa_ctx->indirect_ctx.size / CACHELINE_BYTES);
+
+ regs[CTX_RCS_INDIRECT_CTX_OFFSET + 1] =
+ intel_lr_indirect_ctx_offset(engine) << 6;
+ }
+
+ CTX_REG(regs, CTX_BB_PER_CTX_PTR, RING_BB_PER_CTX_PTR(base), 0);
+ if (wa_ctx->per_ctx.size) {
+
+ regs[CTX_BB_PER_CTX_PTR + 1] =
+ (ggtt_offset + wa_ctx->per_ctx.offset) | 0x01;
+ }
+}
+
static void execlists_init_reg_state(u32 *regs,
struct i915_gem_context *ctx,
struct intel_engine_cs *engine,
@@ -2429,31 +2461,8 @@ static void execlists_init_reg_state(u32 *regs,
CTX_REG(regs, CTX_SECOND_BB_HEAD_U, RING_SBBADDR_UDW(base), 0);
CTX_REG(regs, CTX_SECOND_BB_HEAD_L, RING_SBBADDR(base), 0);
CTX_REG(regs, CTX_SECOND_BB_STATE, RING_SBBSTATE(base), 0);
- if (rcs) {
- struct i915_ctx_workarounds *wa_ctx = &engine->wa_ctx;
-
- CTX_REG(regs, CTX_RCS_INDIRECT_CTX, RING_INDIRECT_CTX(base), 0);
- CTX_REG(regs, CTX_RCS_INDIRECT_CTX_OFFSET,
- RING_INDIRECT_CTX_OFFSET(base), 0);
- if (wa_ctx->indirect_ctx.size) {
- u32 ggtt_offset = i915_ggtt_offset(wa_ctx->vma);
-
- regs[CTX_RCS_INDIRECT_CTX + 1] =
- (ggtt_offset + wa_ctx->indirect_ctx.offset) |
- (wa_ctx->indirect_ctx.size / CACHELINE_BYTES);
-
- regs[CTX_RCS_INDIRECT_CTX_OFFSET + 1] =
- intel_lr_indirect_ctx_offset(engine) << 6;
- }
-
- CTX_REG(regs, CTX_BB_PER_CTX_PTR, RING_BB_PER_CTX_PTR(base), 0);
- if (wa_ctx->per_ctx.size) {
- u32 ggtt_offset = i915_ggtt_offset(wa_ctx->vma);
-
- regs[CTX_BB_PER_CTX_PTR + 1] =
- (ggtt_offset + wa_ctx->per_ctx.offset) | 0x01;
- }
- }
+ if (rcs)
+ execlists_init_reg_state_wa_bb(regs, engine);
regs[CTX_LRI_HEADER_1] = MI_LOAD_REGISTER_IMM(9) | MI_LRI_FORCE_POSTED;
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/8] drm/i915: Program RPCS for Broadwell
From: Chris Wilson
Currently we only configure the power gating for Skylake and above, but
the configuration should equally apply to Broadwell and Braswell. Even
though, there is not as much variation as for later generations, we want
to expose control over the configuration to userspace and may want to
opt out of the "always-enabled" setting.
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_lrc.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 029901a8fa38..407a44a341b9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2332,13 +2332,6 @@ make_rpcs(struct drm_i915_private *dev_priv)
{
u32 rpcs = 0;
- /*
-* No explicit RPCS request is needed to ensure full
-* slice/subslice/EU enablement prior to Gen9.
- */
- if (INTEL_GEN(dev_priv) < 9)
- return 0;
-
/*
* Starting in Gen9, render power gating can leave
* slice/subslice/EU in a partially enabled state. We
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm/i915: expose helper mapping exec flag engine to intel_engine_cs
This function will be used later by the per (context,engine) power
programming interface.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h| 3 +++
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 18 +-
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2c72c596057f..fdf71164ee24 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2895,6 +2895,9 @@ void i915_gem_cleanup_early(struct drm_i915_private
*dev_priv);
void i915_gem_load_init_fences(struct drm_i915_private *dev_priv);
int i915_gem_freeze(struct drm_i915_private *dev_priv);
int i915_gem_freeze_late(struct drm_i915_private *dev_priv);
+struct intel_engine_cs *i915_gem_engine_from_flags(struct drm_i915_private
*dev_priv,
+ struct drm_file *file,
+ u64 flags);
void *i915_gem_object_alloc(struct drm_i915_private *dev_priv);
void i915_gem_object_free(struct drm_i915_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index c74f5df3fb5a..9c13ec39d87b 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2032,12 +2032,12 @@ static const enum intel_engine_id
user_ring_map[I915_USER_RINGS + 1] = {
[I915_EXEC_VEBOX] = VECS
};
-static struct intel_engine_cs *
-eb_select_engine(struct drm_i915_private *dev_priv,
-struct drm_file *file,
-struct drm_i915_gem_execbuffer2 *args)
+struct intel_engine_cs *
+i915_gem_engine_from_flags(struct drm_i915_private *dev_priv,
+ struct drm_file *file,
+ u64 flags)
{
- unsigned int user_ring_id = args->flags & I915_EXEC_RING_MASK;
+ unsigned int user_ring_id = flags & I915_EXEC_RING_MASK;
struct intel_engine_cs *engine;
if (user_ring_id > I915_USER_RINGS) {
@@ -2046,14 +2046,14 @@ eb_select_engine(struct drm_i915_private *dev_priv,
}
if ((user_ring_id != I915_EXEC_BSD) &&
- ((args->flags & I915_EXEC_BSD_MASK) != 0)) {
+ ((flags & I915_EXEC_BSD_MASK) != 0)) {
DRM_DEBUG("execbuf with non bsd ring but with invalid "
- "bsd dispatch flags: %d\n", (int)(args->flags));
+ "bsd dispatch flags: %d\n", (int)(flags));
return NULL;
}
if (user_ring_id == I915_EXEC_BSD && HAS_BSD2(dev_priv)) {
- unsigned int bsd_idx = args->flags & I915_EXEC_BSD_MASK;
+ unsigned int bsd_idx = flags & I915_EXEC_BSD_MASK;
if (bsd_idx == I915_EXEC_BSD_DEFAULT) {
bsd_idx = gen8_dispatch_bsd_engine(dev_priv, file);
@@ -2256,7 +2256,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (args->flags & I915_EXEC_IS_PINNED)
eb.batch_flags |= I915_DISPATCH_PINNED;
- eb.engine = eb_select_engine(eb.i915, file, args);
+ eb.engine = i915_gem_engine_from_flags(eb.i915, file, args->flags);
if (!eb.engine)
return -EINVAL;
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/8] drm/i915: Record the sseu configuration per-context & engine
From: Chris Wilson
We want to expose the ability to reconfigure the slices, subslice and
eu per context and per engine. To facilitate that, store the current
configuration on the context for each engine, which is initially set
to the device default upon creation.
v2: record sseu configuration per context & engine (Chris)
v3: introduce the i915_gem_context_sseu to store powergating
programming, sseu_dev_info has grown quite a bit (Lionel)
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_gem_context.c | 22 ++
drivers/gpu/drm/i915/i915_gem_context.h | 10 ++
drivers/gpu/drm/i915/intel_lrc.c| 24
3 files changed, 44 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 74435affe23f..bdf050beeb94 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -261,11 +261,26 @@ static u32 default_desc_template(const struct
drm_i915_private *i915,
return desc;
}
+static struct i915_gem_context_sseu
+i915_gem_context_sseu_from_device_sseu(const struct sseu_dev_info *sseu)
+{
+ struct i915_gem_context_sseu value = {
+ .slice_mask = sseu->slice_mask,
+ .subslice_mask = sseu->subslice_mask[0],
+ .min_eus_per_subslice = sseu->max_eus_per_subslice,
+ .max_eus_per_subslice = sseu->max_eus_per_subslice,
+ };
+
+ return value;
+}
+
static struct i915_gem_context *
__create_hw_context(struct drm_i915_private *dev_priv,
struct drm_i915_file_private *file_priv)
{
struct i915_gem_context *ctx;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
int ret;
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
@@ -314,6 +329,13 @@ __create_hw_context(struct drm_i915_private *dev_priv,
* is no remap info, it will be a NOP. */
ctx->remap_slice = ALL_L3_SLICES(dev_priv);
+ /* On all engines, use the whole device by default */
+ for_each_engine(engine, dev_priv, id) {
+ ctx->engine[id].sseu =
+ i915_gem_context_sseu_from_device_sseu(
+ &INTEL_INFO(dev_priv)->sseu);
+ }
+
i915_gem_context_set_bannable(ctx);
ctx->ring_size = 4 * PAGE_SIZE;
ctx->desc_template =
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index b12a8a8c5af9..2294be644574 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -30,6 +30,7 @@
#include
#include "i915_gem.h"
+#include "intel_device_info.h"
struct pid;
@@ -45,6 +46,13 @@ struct intel_ring;
#define DEFAULT_CONTEXT_HANDLE 0
+struct i915_gem_context_sseu {
+ u8 slice_mask;
+ u8 subslice_mask;
+ u8 min_eus_per_subslice;
+ u8 max_eus_per_subslice;
+};
+
/**
* struct i915_gem_context - client state
*
@@ -149,6 +157,8 @@ struct i915_gem_context {
u32 *lrc_reg_state;
u64 lrc_desc;
int pin_count;
+ /** sseu: Control eu/slice partitioning */
+ struct i915_gem_context_sseu sseu;
} engine[I915_NUM_ENGINES];
/** ring_size: size for allocating the per-engine ring buffer */
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index a0f72fcda0d9..dca17ef24de5 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2387,8 +2387,8 @@ int logical_xcs_ring_init(struct intel_engine_cs *engine)
return logical_ring_init(engine);
}
-static u32
-make_rpcs(struct drm_i915_private *dev_priv)
+static u32 make_rpcs(const struct sseu_dev_info *sseu,
+const struct i915_gem_context_sseu *ctx_sseu)
{
u32 rpcs = 0;
@@ -2398,24 +2398,23 @@ make_rpcs(struct drm_i915_private *dev_priv)
* must make an explicit request through RPCS for full
* enablement.
*/
- if (INTEL_INFO(dev_priv)->sseu.has_slice_pg) {
+ if (sseu->has_slice_pg) {
rpcs |= GEN8_RPCS_S_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask) <<
- GEN8_RPCS_S_CNT_SHIFT;
+ rpcs |= hweight8(ctx_sseu->slice_mask) << GEN8_RPCS_S_CNT_SHIFT;
rpcs |= GEN8_RPCS_ENABLE;
}
- if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
+ if (sseu->has_subslice_pg) {
rpcs |= GEN8_RPCS_SS_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]) <<
- GEN8_RPCS_SS_CNT_SHIFT;
+ rpcs |= hweight8(ctx_sseu->subslice_mask) <<
+ GEN8_RPCS_SS_CNT_SHIFT;
rpcs |= GEN8_RPCS_ENABLE;
}
- if (INTEL_INFO(
[Intel-gfx] [PATCH 5/8] drm/i915: pass wa_ctx as argument
Rather than accessing it from the engine structure. This will be used
for reprogramming later.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/intel_lrc.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 56515091beb4..7a5efab3e4fb 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1586,7 +1586,8 @@ gen10_init_indirectctx_bb(struct intel_engine_cs *engine,
u32 *batch)
#define CTX_WA_BB_OBJ_SIZE (PAGE_SIZE)
-static int lrc_setup_wa_ctx(struct intel_engine_cs *engine)
+static int lrc_setup_wa_ctx(struct intel_engine_cs *engine,
+ struct i915_ctx_workarounds *wa_ctx)
{
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
@@ -1606,7 +1607,7 @@ static int lrc_setup_wa_ctx(struct intel_engine_cs
*engine)
if (err)
goto err;
- engine->wa_ctx.vma = vma;
+ wa_ctx->vma = vma;
return 0;
err:
@@ -1621,9 +1622,9 @@ static void lrc_destroy_wa_ctx(struct intel_engine_cs
*engine)
typedef u32 *(*wa_bb_func_t)(struct intel_engine_cs *engine, u32 *batch);
-static int intel_init_workaround_bb(struct intel_engine_cs *engine)
+static int intel_init_workaround_bb(struct intel_engine_cs *engine,
+ struct i915_ctx_workarounds *wa_ctx)
{
- struct i915_ctx_workarounds *wa_ctx = &engine->wa_ctx;
struct i915_wa_ctx_bb *wa_bb[2] = { &wa_ctx->indirect_ctx,
&wa_ctx->per_ctx };
wa_bb_func_t wa_bb_fn[2];
@@ -1653,7 +1654,7 @@ static int intel_init_workaround_bb(struct
intel_engine_cs *engine)
return 0;
}
- ret = lrc_setup_wa_ctx(engine);
+ ret = lrc_setup_wa_ctx(engine, wa_ctx);
if (ret) {
DRM_DEBUG_DRIVER("Failed to setup context WA page: %d\n", ret);
return ret;
@@ -2306,7 +2307,7 @@ int logical_render_ring_init(struct intel_engine_cs
*engine)
if (ret)
return ret;
- ret = intel_init_workaround_bb(engine);
+ ret = intel_init_workaround_bb(engine, &engine->wa_ctx);
if (ret) {
/*
* We continue even if we fail to initialize WA batch
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/8] drm/i915: reprogram NOA muxes on context switch when using perf
If some of the contexts submitting workloads to the GPU have been
configured to shutdown slices/subslices, we might loose the NOA
configurations written in the NOA muxes. We need to reprogram them at
context switch.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_perf.c | 92 +---
drivers/gpu/drm/i915/intel_lrc.c | 71 +---
drivers/gpu/drm/i915/intel_lrc.h | 1 +
4 files changed, 153 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fdf71164ee24..b15f1fa4453a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3263,6 +3263,8 @@ int i915_perf_remove_config_ioctl(struct drm_device *dev,
void *data,
void i915_oa_init_reg_state(struct intel_engine_cs *engine,
struct i915_gem_context *ctx,
uint32_t *reg_state);
+u32 i915_oa_get_perctx_bb_size(struct intel_engine_cs *engine);
+u32 *i915_oa_emit_perctx_bb(struct intel_engine_cs *engine, u32 *batch);
/* i915_gem_evict.c */
int __must_check i915_gem_evict_something(struct i915_address_space *vm,
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 2fc9c85a0d99..d1598f54e63b 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1752,6 +1752,71 @@ static int gen8_emit_oa_config(struct i915_request *rq,
return 0;
}
+#define MAX_LRI_SIZE (125U)
+
+u32 i915_oa_get_perctx_bb_size(struct intel_engine_cs *engine)
+{
+ struct drm_i915_private *dev_priv = engine->i915;
+ struct i915_perf_stream *stream = dev_priv->perf.oa.exclusive_stream;
+ struct i915_oa_config *oa_config;
+ u32 n_lri;
+
+ /* We only care about RCS. */
+ if (engine->id != RCS)
+ return 0;
+
+ /* Perf not supported. */
+ if (!dev_priv->perf.initialized)
+ return 0;
+
+ /* OA not currently configured. */
+ if (!stream)
+ return 0;
+
+ oa_config = stream->oa_config;
+
+ /* Very unlikely but possible that we have no muxes to configure. */
+ if (!oa_config->mux_regs_len)
+ return 0;
+
+ n_lri = (oa_config->mux_regs_len / MAX_LRI_SIZE) +
+ (oa_config->mux_regs_len % MAX_LRI_SIZE) != 0;
+
+ /* Return the size of MI_LOAD_REGISTER_IMMs + PIPE_CONTROL . */
+ return n_lri * 4 + oa_config->mux_regs_len * 8 + 24;
+}
+
+u32 *i915_oa_emit_perctx_bb(struct intel_engine_cs *engine, u32 *batch)
+{
+ struct drm_i915_private *dev_priv = engine->i915;
+ struct i915_oa_config *oa_config;
+ u32 i, n_loaded_regs;
+
+ if (i915_oa_get_perctx_bb_size(engine) == 0)
+ return batch;
+
+ oa_config = dev_priv->perf.oa.exclusive_stream->oa_config;
+
+ n_loaded_regs = 0;
+ for (i = 0; i < oa_config->mux_regs_len; i++) {
+ if ((n_loaded_regs % MAX_LRI_SIZE) == 0) {
+ u32 n_lri = min(oa_config->mux_regs_len - n_loaded_regs,
+ MAX_LRI_SIZE);
+ *batch++ = MI_LOAD_REGISTER_IMM(n_lri);
+ }
+
+ *batch++ = i915_mmio_reg_offset(oa_config->mux_regs[i].addr);
+ *batch++ = oa_config->mux_regs[i].value;
+ n_loaded_regs++;
+ }
+
+ batch = gen8_emit_pipe_control(batch,
+ PIPE_CONTROL_MMIO_WRITE,
+ 0);
+
+ return batch;
+}
+
static int gen8_switch_to_updated_kernel_context(struct drm_i915_private
*dev_priv,
const struct i915_oa_config
*oa_config)
{
@@ -1829,7 +1894,7 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
/* Switch away from any user context. */
ret = gen8_switch_to_updated_kernel_context(dev_priv, oa_config);
if (ret)
- goto out;
+ return ret;
/*
* The OA register config is setup through the context image. This image
@@ -1846,7 +1911,16 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
*/
ret = i915_gem_wait_for_idle(dev_priv, wait_flags);
if (ret)
- goto out;
+ return ret;
+
+ /*
+* Reload the workaround batchbuffer to include NOA muxes
+* reprogramming on context-switch, so we don't loose configurations
+* after switch-from a context with disabled slices/subslices.
+*/
+ ret = logical_render_ring_reload_wa_bb(dev_priv->engine[RCS]);
+ if (ret)
+ return ret;
/* Update all contexts now that we've stalled the submission. */
list_for_each_entry(ctx, &dev_priv->contexts.list, link) {
@@ -1858,10 +1932,8 @@ static int gen8_configure_all
[Intel-gfx] [PATCH 3/8] drm/i915: don't specify pinned size for wa_bb pin/allocation
We can rely on the i915_vma_pin() to use vma->size instead. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/intel_lrc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 407a44a341b9..3ca5a1d33fe9 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1602,7 +1602,7 @@ static int lrc_setup_wa_ctx(struct intel_engine_cs *engine) goto err; } - err = i915_vma_pin(vma, 0, PAGE_SIZE, PIN_GLOBAL | PIN_HIGH); + err = i915_vma_pin(vma, 0, 0, PIN_GLOBAL | PIN_HIGH); if (err) goto err; -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/8] drm/i915: Expose RPCS (SSEU) configuration to userspace
From: Chris Wilson
We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within the context image (and
currently not accessible via LRI). If the context is adjusted before
first use, the adjustment is for "free"; otherwise if the context is
active we flush the context off the GPU (stalling all users) and forcing
the GPU to save the context to memory where we can modify it and so
ensure that the register is reloaded on next execution.
The overhead of managing additional EU subslices can be significant,
especially in multi-context workloads. Non-GPGPU contexts should
preferably disable the subslices it is not using, and others should
fine-tune the number to match their workload.
We expose complete control over the RPCS register, allowing
configuration of slice/subslice, via masks packed into a u64 for
simplicity. For example,
struct drm_i915_gem_context_param arg;
struct drm_i915_gem_context_param_sseu sseu = { .flags =
I915_EXEC_RENDER };
memset(&arg, 0, sizeof(arg));
arg.ctx_id = ctx;
arg.param = I915_CONTEXT_PARAM_SSEU;
arg.value = (uintptr_t) &sseu;
if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, &arg) == 0) {
sseu.packed.subslice_mask = 0;
drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, &arg);
}
could be used to disable all subslices where supported.
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
c: Dmitry Rogozhkin
CC: Tvrtko Ursulin
CC: Zhipeng Gong
CC: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_context.c | 82 -
drivers/gpu/drm/i915/intel_lrc.c| 55 +
drivers/gpu/drm/i915/intel_lrc.h| 4 ++
include/uapi/drm/i915_drm.h | 28 +
4 files changed, 168 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index bdf050beeb94..b97ddcf47514 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -740,6 +740,26 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev,
void *data,
return 0;
}
+static struct i915_gem_context_sseu
+i915_gem_context_sseu_from_user_sseu(const struct sseu_dev_info *sseu,
+const struct
drm_i915_gem_context_param_sseu *user_sseu)
+{
+ struct i915_gem_context_sseu value = {
+ .slice_mask = user_sseu->packed.slice_mask == 0 ?
+ sseu->slice_mask :
+ (user_sseu->packed.slice_mask & sseu->slice_mask),
+ .subslice_mask = user_sseu->packed.subslice_mask == 0 ?
+sseu->subslice_mask[0] :
+(user_sseu->packed.subslice_mask &
sseu->subslice_mask[0]),
+ .min_eus_per_subslice =
min(user_sseu->packed.min_eus_per_subslice,
+ sseu->max_eus_per_subslice),
+ .max_eus_per_subslice =
min(user_sseu->packed.max_eus_per_subslice,
+ sseu->max_eus_per_subslice),
+ };
+
+ return value;
+}
+
int i915_gem_context_getparam_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
{
@@ -777,6 +797,37 @@ int i915_gem_context_getparam_ioctl(struct drm_device
*dev, void *data,
case I915_CONTEXT_PARAM_PRIORITY:
args->value = ctx->sched.priority;
break;
+ case I915_CONTEXT_PARAM_SSEU: {
+ struct drm_i915_gem_context_param_sseu param_sseu;
+ struct intel_engine_cs *engine;
+
+ if (copy_from_user(¶m_sseu, u64_to_user_ptr(args->value),
+ sizeof(param_sseu))) {
+ ret = -EFAULT;
+ break;
+ }
+
+ engine = i915_gem_engine_from_flags(to_i915(dev), file,
+ param_sseu.flags);
+ if (!engine) {
+ ret = -EINVAL;
+ break;
+ }
+
+ param_sseu.packed.slice_mask =
+ ctx->engine[engine->id].sseu.slice_mask;
+ param_sseu.packed.subslice_mask =
+ ctx->engine[engine->id].sseu.subslice_mask;
+ param_sseu.packed.min_eus_per_subslice =
+ ctx->engine[engine->id].sseu.min_eus_per_subslice;
+ param_sseu.packed.max_eus_per_subslice =
+
Re: [Intel-gfx] [PATCH 1/8] drm/i915: expose helper mapping exec flag engine to intel_engine_cs
Quoting Lionel Landwerlin (2018-04-25 12:45:14) > This function will be used later by the per (context,engine) power > programming interface. No. This is not the appropriate uABI, please see intel_engine_lookup_user(). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/8] drm/i915: don't specify pinned size for wa_bb pin/allocation
Quoting Lionel Landwerlin (2018-04-25 12:45:16) > We can rely on the i915_vma_pin() to use vma->size instead. But that's the alignment parameter. I didn't change it as I have no idea why it was set to PAGE_SIZE. i915_vma_pin() treats it as 0 anyway. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/7] drm/i915/execlists: Skip lite restore on the currently executing request
== Series Details ==
Series: series starting with [1/7] drm/i915/execlists: Skip lite restore on the
currently executing request
URL : https://patchwork.freedesktop.org/series/42280/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4b4a1828d89c drm/i915/execlists: Skip lite restore on the currently executing
request
-:32: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 1 errors, 0 warnings, 0 checks, 19 lines checked
99c54423a77d drm/i915: Stop tracking timeline->inflight_seqnos
-:17: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 9b6586ae9f6b ("drm/i915: Keep a
global seqno per-engine")'
#17:
References: 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine")
total: 1 errors, 0 warnings, 0 checks, 128 lines checked
35eef4c87889 drm/i915: Retire requests along rings
997139c09d44 drm/i915: Only track live rings for retiring
54a83de8b44e drm/i915: Move timeline from GTT to ring
0df2dadcba04 drm/i915: Split i915_gem_timeline into individual timelines
-:464: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#464:
deleted file mode 100644
-:969: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#969: FILE: drivers/gpu/drm/i915/i915_timeline.c:1:
+/*
total: 0 errors, 2 warnings, 0 checks, 1638 lines checked
9cf53c35b5e5 drm/i915: Lazily unbind vma on close
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915: reprogram NOA muxes on context switch when using perf
Quoting Lionel Landwerlin (2018-04-25 12:45:19) > If some of the contexts submitting workloads to the GPU have been > configured to shutdown slices/subslices, we might loose the NOA > configurations written in the NOA muxes. We need to reprogram them at > context switch. On every single batchbuffer, no way. That's around a 33% latency hit, ignoring the cost of what's inside the wa_bb. If they are not context saved, userspace isn't going to be allowed to modify them. So why do we need this? If they not context saved, then the kernel needs to control them and doesn't need to reset around every batch, just the one's that want non-default (fancier if we handle preemption)? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/7] drm/i915/execlists: Skip lite restore on the currently executing request
== Series Details == Series: series starting with [1/7] drm/i915/execlists: Skip lite restore on the currently executing request URL : https://patchwork.freedesktop.org/series/42280/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/execlists: Skip lite restore on the currently executing request Okay! Commit: drm/i915: Stop tracking timeline->inflight_seqnos -O:drivers/gpu/drm/i915/i915_request.c:268:13: error: undefined identifier '__builtin_add_overflow_p' -O:drivers/gpu/drm/i915/i915_request.c:268:13: warning: call with no type! -drivers/gpu/drm/i915/selftests/../i915_drv.h:2211:33: warning: constant 0xea00 is so big it is unsigned long -drivers/gpu/drm/i915/selftests/../i915_drv.h:3659:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:2212:33: warning: constant 0xea00 is so big it is unsigned long +drivers/gpu/drm/i915/selftests/../i915_drv.h:3660:16: warning: expression using sizeof(void) Commit: drm/i915: Retire requests along rings -drivers/gpu/drm/i915/selftests/../i915_drv.h:2212:33: warning: constant 0xea00 is so big it is unsigned long -drivers/gpu/drm/i915/selftests/../i915_drv.h:3660:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:2213:33: warning: constant 0xea00 is so big it is unsigned long +drivers/gpu/drm/i915/selftests/../i915_drv.h:3661:16: warning: expression using sizeof(void) Commit: drm/i915: Only track live rings for retiring -drivers/gpu/drm/i915/selftests/../i915_drv.h:2213:33: warning: constant 0xea00 is so big it is unsigned long -drivers/gpu/drm/i915/selftests/../i915_drv.h:3661:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:2214:33: warning: constant 0xea00 is so big it is unsigned long +drivers/gpu/drm/i915/selftests/../i915_drv.h:3662:16: warning: expression using sizeof(void) Commit: drm/i915: Move timeline from GTT to ring -drivers/gpu/drm/i915/selftests/../i915_drv.h:2214:33: warning: constant 0xea00 is so big it is unsigned long -drivers/gpu/drm/i915/selftests/../i915_drv.h:3662:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:2215:33: warning: constant 0xea00 is so big it is unsigned long +drivers/gpu/drm/i915/selftests/../i915_drv.h:3653:16: warning: expression using sizeof(void) Commit: drm/i915: Split i915_gem_timeline into individual timelines -drivers/gpu/drm/i915/selftests/../i915_drv.h:2215:33: warning: constant 0xea00 is so big it is unsigned long -drivers/gpu/drm/i915/selftests/../i915_drv.h:3653:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:2213:33: warning: constant 0xea00 is so big it is unsigned long +drivers/gpu/drm/i915/selftests/../i915_drv.h:3651:16: warning: expression using sizeof(void) Commit: drm/i915: Lazily unbind vma on close -drivers/gpu/drm/i915/selftests/../i915_drv.h:2213:33: warning: constant 0xea00 is so big it is unsigned long -drivers/gpu/drm/i915/selftests/../i915_drv.h:3651:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:2214:33: warning: constant 0xea00 is so big it is unsigned long +drivers/gpu/drm/i915/selftests/../i915_drv.h:3652:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/7] drm/i915/execlists: Skip lite restore on the currently executing request
== Series Details == Series: series starting with [1/7] drm/i915/execlists: Skip lite restore on the currently executing request URL : https://patchwork.freedesktop.org/series/42280/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4093 -> Patchwork_8795 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_8795 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8795, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/42280/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8795: === IGT changes === Possible regressions igt@gem_exec_suspend@basic-s4-devices: fi-skl-guc: PASS -> FAIL +1 == Known issues == Here are the changes found in Patchwork_8795 that come from known issues: === IGT changes === Issues hit igt@debugfs_test@read_all_entries: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) igt@gem_exec_suspend@basic-s3: fi-ivb-3520m: PASS -> DMESG-WARN (fdo#106084) +1 igt@kms_pipe_crc_basic@hang-read-crc-pipe-a: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106097) +2 Possible fixes igt@kms_chamelium@dp-edid-read: fi-kbl-7500u: FAIL (fdo#103841) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS igt@prime_vgem@basic-fence-flip: fi-glk-j4005: DMESG-WARN (fdo#106235) -> PASS fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106235 https://bugs.freedesktop.org/show_bug.cgi?id=106235 == Participating hosts (38 -> 35) == Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4093 -> Patchwork_8795 CI_DRM_4093: a47694a9464b96e17b12f0bdb1085d10a61c57e9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4446: e5e8dafc991ee922ec159491c680caff0cfe9235 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8795: 9cf53c35b5e5e8f8c8f7bb61262bd49fe26e8061 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4446: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ git://anongit.freedesktop.org/piglit == Linux commits == 9cf53c35b5e5 drm/i915: Lazily unbind vma on close 0df2dadcba04 drm/i915: Split i915_gem_timeline into individual timelines 54a83de8b44e drm/i915: Move timeline from GTT to ring 997139c09d44 drm/i915: Only track live rings for retiring 35eef4c87889 drm/i915: Retire requests along rings 99c54423a77d drm/i915: Stop tracking timeline->inflight_seqnos 4b4a1828d89c drm/i915/execlists: Skip lite restore on the currently executing request == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8795/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH i-g-t] [RFC] CONTRIBUTING: commit rights docs
On 24 April 2018 at 20:14, Daniel Vetter wrote: > On Tue, Apr 24, 2018 at 7:30 PM, Emil Velikov > wrote: >> On 13 April 2018 at 11:00, Daniel Vetter wrote: >>> This tries to align with the X.org communities's long-standing >>> tradition of trying to be an inclusive community and handing out >>> commit rights fairly freely. >>> >>> We also tend to not revoke commit rights for people no longer >>> regularly active in a given project, as long as they're still part of >>> the larger community. >>> >>> Finally make sure that commit rights, like anything happening on fd.o >>> infrastructre, is subject to the fd.o's Code of Conduct. >>> >>> v2: Point at MAINTAINERS for contact info (Daniel S.) >>> >>> v3: >>> - Make it clear that commit rights are voluntary and that committers >>> need to acknowledge positively when they're nominated by someone >>> else (Keith). >>> - Encourage committers to drop their commit rights when they're no >>> longer active, and make it clear they'll get readded (Keith). >>> - Add a line that maintainers and committers should actively nominate >>> new committers (me). >>> >>> v4: Typo (Petri). >>> >>> v5: Typo (Sean). >>> >>> v6: Wording clarifications and spelling (Jani). >>> >>> v7: Require an explicit commitment to the documented merge criteria >>> and rules, instead of just the implied one through the Code of Conduct >>> threat (Jani). >>> >>> Acked-by: Alex Deucher >>> Acked-by: Arkadiusz Hiler >>> Acked-by: Daniel Stone >>> Acked-by: Eric Anholt >>> Acked-by: Gustavo Padovan >>> Acked-by: Petri Latvala >>> Cc: Alex Deucher >>> Cc: Arkadiusz Hiler >>> Cc: Ben Widawsky >>> Cc: Daniel Stone >>> Cc: Dave Airlie >>> Cc: Eric Anholt >>> Cc: Gustavo Padovan >>> Cc: Jani Nikula >>> Cc: Joonas Lahtinen >>> Cc: Keith Packard >>> Cc: Kenneth Graunke >>> Cc: Kristian H. Kristensen >>> Cc: Maarten Lankhorst >>> Cc: Petri Latvala >>> Cc: Rodrigo Vivi >>> Cc: Sean Paul >>> Reviewed-by: Keith Packard >>> Signed-off-by: Daniel Vetter >>> --- >>> If you wonder about the wide distribution list for an igt patch: I'd >>> like to start a discussions about x.org community norms around commit >>> rights at large, at least for all the shared repos. I plan to propose >>> the same text for drm-misc and libdrm too, and hopefully others like >>> mesa/xserver/wayland would follow. >>> >> I think the idea is pretty good, simply highlighting some bits. >> >> What you've outlined in this patch has been in practise for many years: >> a) undocumented, applicable to most xorg projects [1] >> b) documented, mesa > > Hm, I chatted with a few mesa devs about this, and I wasn't aware > there's explicit documentation for mesa. Where is it? I'd very much > want to align as much as we can. > See the "Developer git Access" section in [1]. FWIW I prefer the wording used in this patch and the CoC reference is a big plus. HTH Emil [1] https://www.mesa3d.org/repository.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/execlists: Skip lite restore on the currently executing request
== Series Details == Series: drm/i915/execlists: Skip lite restore on the currently executing request URL : https://patchwork.freedesktop.org/series/42281/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4093 -> Patchwork_8796 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_8796 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8796, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/42281/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8796: === IGT changes === Possible regressions igt@prime_vgem@basic-fence-flip: fi-elk-e7500: PASS -> FAIL == Known issues == Here are the changes found in Patchwork_8796 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s3: fi-ivb-3520m: PASS -> DMESG-WARN (fdo#106084) igt@kms_pipe_crc_basic@hang-read-crc-pipe-c: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106097) +2 Possible fixes igt@kms_chamelium@dp-edid-read: fi-kbl-7500u: FAIL (fdo#103841) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS igt@prime_vgem@basic-fence-flip: fi-glk-j4005: DMESG-WARN (fdo#106235) -> PASS fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106235 https://bugs.freedesktop.org/show_bug.cgi?id=106235 == Participating hosts (38 -> 34) == Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq fi-hsw-4200u == Build changes == * Linux: CI_DRM_4093 -> Patchwork_8796 CI_DRM_4093: a47694a9464b96e17b12f0bdb1085d10a61c57e9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4446: e5e8dafc991ee922ec159491c680caff0cfe9235 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8796: 68be8df41b39d101b29d20347ce109eda0273029 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4446: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ git://anongit.freedesktop.org/piglit == Linux commits == 68be8df41b39 drm/i915/execlists: Skip lite restore on the currently executing request == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8796/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: per context slice/subslice powergating
== Series Details ==
Series: drm/i915: per context slice/subslice powergating
URL : https://patchwork.freedesktop.org/series/42285/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
aad432b4239c drm/i915: expose helper mapping exec flag engine to intel_engine_cs
f01ac5929e4d drm/i915: Program RPCS for Broadwell
1b1c9aba0ce7 drm/i915: don't specify pinned size for wa_bb pin/allocation
418f679dd16e drm/i915: extract per-ctx/indirect bb programming
-:44: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#44: FILE: drivers/gpu/drm/i915/intel_lrc.c:2421:
+ if (wa_ctx->per_ctx.size) {
+
total: 0 errors, 0 warnings, 1 checks, 71 lines checked
46f6a90557d5 drm/i915: pass wa_ctx as argument
02aac22145e0 drm/i915: reprogram NOA muxes on context switch when using perf
-:233: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON &
recovery code rather than BUG() or BUG_ON()
#233: FILE: drivers/gpu/drm/i915/intel_lrc.c:1697:
+ BUG_ON(batch_ptr - batch > wa_ctx->vma->obj->base.size);
total: 0 errors, 1 warnings, 0 checks, 258 lines checked
c67130ef4bd9 drm/i915: Record the sseu configuration per-context & engine
-:57: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#57: FILE: drivers/gpu/drm/i915/i915_gem_context.c:335:
+ i915_gem_context_sseu_from_device_sseu(
-:133: ERROR:CODE_INDENT: code indent should use tabs where possible
#133: FILE: drivers/gpu/drm/i915/intel_lrc.c:2410:
+^I^IGEN8_RPCS_SS_CNT_SHIFT;$
total: 1 errors, 0 warnings, 1 checks, 118 lines checked
59ec862256e6 drm/i915: Expose RPCS (SSEU) configuration to userspace
-:25: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#25:
struct drm_i915_gem_context_param_sseu sseu = { .flags =
I915_EXEC_RENDER };
-:135: CHECK:BRACES: braces {} should be used on all arms of this statement
#135: FILE: drivers/gpu/drm/i915/i915_gem_context.c:905:
+ if (args->size)
[...]
+ else if (!HAS_EXECLISTS(ctx->i915))
[...]
+ else {
[...]
-:139: CHECK:BRACES: Unbalanced braces around else statement
#139: FILE: drivers/gpu/drm/i915/i915_gem_context.c:909:
+ else {
total: 0 errors, 1 warnings, 2 checks, 213 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: per context slice/subslice powergating
== Series Details == Series: drm/i915: per context slice/subslice powergating URL : https://patchwork.freedesktop.org/series/42285/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: expose helper mapping exec flag engine to intel_engine_cs -drivers/gpu/drm/i915/selftests/../i915_drv.h:3659:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3662:16: warning: expression using sizeof(void) Commit: drm/i915: Program RPCS for Broadwell Okay! Commit: drm/i915: don't specify pinned size for wa_bb pin/allocation Okay! Commit: drm/i915: extract per-ctx/indirect bb programming Okay! Commit: drm/i915: pass wa_ctx as argument Okay! Commit: drm/i915: reprogram NOA muxes on context switch when using perf +drivers/gpu/drm/i915/i915_perf.c:1742:37: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/../i915_drv.h:3662:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3664:16: warning: expression using sizeof(void) Commit: drm/i915: Record the sseu configuration per-context & engine Okay! Commit: drm/i915: Expose RPCS (SSEU) configuration to userspace +drivers/gpu/drm/i915/i915_gem_context.c:754:41: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_context.c:754:41: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_context.c:756:41: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_context.c:756:41: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Use memset64() to align the ring with MI_NOOP
When filling the ring to align the emit pointer to the next cacheline,
use memset64() rather than open-coding it. As we know that we always
have an even number of dwords, we can replace the dword loop with the
qword equivalent.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index c68ac605b8a9..07a9a2b4beb7 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1717,22 +1717,24 @@ u32 *intel_ring_begin(struct i915_request *rq, unsigned
int num_dwords)
/* Align the ring tail to a cacheline boundary */
int intel_ring_cacheline_align(struct i915_request *rq)
{
- int num_dwords = (rq->ring->emit & (CACHELINE_BYTES - 1)) / sizeof(u32);
- u32 *cs;
+ int num_dwords;
+ void *cs;
+ num_dwords = (rq->ring->emit & (CACHELINE_BYTES - 1)) / sizeof(u32);
if (num_dwords == 0)
return 0;
- num_dwords = CACHELINE_BYTES / sizeof(u32) - num_dwords;
+ num_dwords = CACHELINE_DWORDS - num_dwords;
+ GEM_BUG_ON(num_dwords & 1);
+
cs = intel_ring_begin(rq, num_dwords);
if (IS_ERR(cs))
return PTR_ERR(cs);
- while (num_dwords--)
- *cs++ = MI_NOOP;
-
+ memset64(cs, 0, num_dwords/2);
intel_ring_advance(rq, cs);
+ GEM_BUG_ON(rq->ring->emit & CACHELINE_BYTES);
return 0;
}
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Skip lite restore on the currently executing request
Quoting Chris Wilson (2018-04-25 12:31:29) > Quoting Chris Wilson (2018-04-25 12:23:30) > > Quoting Mika Kuoppala (2018-04-25 12:19:08) > > > Did you try with WA_TAIL_DWORDS 16? > > > > Sure can try, but the error state doesn't indicate TAIL==HEAD as would > > be the issue with WaIdleLiteRestore (restoring to an idle ring wouldn't > > generate the arbitration event, so no more context switches). > > Watch https://patchwork.freedesktop.org/series/42284/ > > Actually surviving on my bdw And what appears to work just as well is @@ -1387,7 +1387,7 @@ static int execlists_request_alloc(struct i915_request *request) */ request->reserved_space += EXECLISTS_REQUEST_SIZE; - ret = intel_ring_wait_for_space(request->ring, request->reserved_space); + ret = intel_ring_cacheline_align(request); if (ret) return ret; If that doesn't hint towards some weirdness in HW, I don't know what would ;) -Chris ___ 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: per context slice/subslice powergating
== Series Details == Series: drm/i915: per context slice/subslice powergating URL : https://patchwork.freedesktop.org/series/42285/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4093 -> Patchwork_8797 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/42285/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_8797 that come from known issues: === IGT changes === Possible fixes igt@kms_chamelium@dp-edid-read: fi-kbl-7500u: FAIL (fdo#103841) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 == Participating hosts (38 -> 33) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-glk-j4005 fi-skl-6700hq fi-hsw-4200u == Build changes == * Linux: CI_DRM_4093 -> Patchwork_8797 CI_DRM_4093: a47694a9464b96e17b12f0bdb1085d10a61c57e9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4446: e5e8dafc991ee922ec159491c680caff0cfe9235 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8797: 59ec862256e6d9a083390dd214a93d119d07e6f0 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4446: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ git://anongit.freedesktop.org/piglit == Linux commits == 59ec862256e6 drm/i915: Expose RPCS (SSEU) configuration to userspace c67130ef4bd9 drm/i915: Record the sseu configuration per-context & engine 02aac22145e0 drm/i915: reprogram NOA muxes on context switch when using perf 46f6a90557d5 drm/i915: pass wa_ctx as argument 418f679dd16e drm/i915: extract per-ctx/indirect bb programming 1b1c9aba0ce7 drm/i915: don't specify pinned size for wa_bb pin/allocation f01ac5929e4d drm/i915: Program RPCS for Broadwell aad432b4239c drm/i915: expose helper mapping exec flag engine to intel_engine_cs == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8797/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Use memset64() to align the ring with MI_NOOP
== Series Details == Series: drm/i915: Use memset64() to align the ring with MI_NOOP URL : https://patchwork.freedesktop.org/series/42290/ State : warning == Summary == $ dim checkpatch origin/drm-tip a2d0462fc7d0 drm/i915: Use memset64() to align the ring with MI_NOOP -:41: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV) #41: FILE: drivers/gpu/drm/i915/intel_ringbuffer.c:1734: + memset64(cs, 0, num_dwords/2); ^ total: 0 errors, 0 warnings, 1 checks, 30 lines checked ___ 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: Use memset64() to align the ring with MI_NOOP
== Series Details == Series: drm/i915: Use memset64() to align the ring with MI_NOOP URL : https://patchwork.freedesktop.org/series/42290/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4093 -> Patchwork_8798 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/42290/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_8798 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s3: fi-ivb-3520m: PASS -> DMESG-WARN (fdo#106084) +1 igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: fi-hsw-4770r: PASS -> FAIL (fdo#103481) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-cnl-psr: PASS -> DMESG-WARN (fdo#104951) Possible fixes igt@kms_chamelium@dp-edid-read: fi-kbl-7500u: FAIL (fdo#103841) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-ivb-3520m: DMESG-WARN (fdo#106084) -> PASS fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS igt@prime_vgem@basic-fence-flip: fi-glk-j4005: DMESG-WARN (fdo#106235) -> PASS fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481 fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084 fdo#106235 https://bugs.freedesktop.org/show_bug.cgi?id=106235 == Participating hosts (38 -> 34) == Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq fi-hsw-4200u == Build changes == * Linux: CI_DRM_4093 -> Patchwork_8798 CI_DRM_4093: a47694a9464b96e17b12f0bdb1085d10a61c57e9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4446: e5e8dafc991ee922ec159491c680caff0cfe9235 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8798: a2d0462fc7d03f71bc819c2e777d60c0fef38c58 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4446: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ git://anongit.freedesktop.org/piglit == Linux commits == a2d0462fc7d0 drm/i915: Use memset64() to align the ring with MI_NOOP == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8798/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Skip lite restore on the currently executing request
Quoting Chris Wilson (2018-04-25 13:45:45) > Quoting Chris Wilson (2018-04-25 12:31:29) > > Quoting Chris Wilson (2018-04-25 12:23:30) > > > Quoting Mika Kuoppala (2018-04-25 12:19:08) > > > > Did you try with WA_TAIL_DWORDS 16? > > > > > > Sure can try, but the error state doesn't indicate TAIL==HEAD as would > > > be the issue with WaIdleLiteRestore (restoring to an idle ring wouldn't > > > generate the arbitration event, so no more context switches). > > > > Watch https://patchwork.freedesktop.org/series/42284/ > > > > Actually surviving on my bdw > > And what appears to work just as well is > > @@ -1387,7 +1387,7 @@ static int execlists_request_alloc(struct i915_request > *request) > */ > request->reserved_space += EXECLISTS_REQUEST_SIZE; > > - ret = intel_ring_wait_for_space(request->ring, > request->reserved_space); > + ret = intel_ring_cacheline_align(request); > if (ret) > return ret; > > If that doesn't hint towards some weirdness in HW, I don't know what > would ;) Fwiw, I've now hit GPU hangs with WA_TAIL_DWORDS set to 16 and with the cacheline_align; scratch that theory. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915: reprogram NOA muxes on context switch when using perf
Quoting Chris Wilson (2018-04-25 12:57:24) > If they are not context saved, userspace isn't going to be allowed to > modify them. So why do we need this? If they not context saved, then the > kernel needs to control them and doesn't need to reset around every > batch, just the one's that want non-default (fancier if we handle > preemption)? Preemption is the killer here. Jumping from one preempted batch back to inside another and you skip over all ring preambles. We could use the preemption ring itself to set state though. Still I would rather see an alternative to wa_bb than incur the cost where it is never needed :| -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH i-g-t] [RFC] CONTRIBUTING: commit rights docs
On Wed, Apr 25, 2018 at 01:27:20PM +0100, Emil Velikov wrote: > On 24 April 2018 at 20:14, Daniel Vetter wrote: > > On Tue, Apr 24, 2018 at 7:30 PM, Emil Velikov > > wrote: > >> On 13 April 2018 at 11:00, Daniel Vetter wrote: > >>> This tries to align with the X.org communities's long-standing > >>> tradition of trying to be an inclusive community and handing out > >>> commit rights fairly freely. > >>> > >>> We also tend to not revoke commit rights for people no longer > >>> regularly active in a given project, as long as they're still part of > >>> the larger community. > >>> > >>> Finally make sure that commit rights, like anything happening on fd.o > >>> infrastructre, is subject to the fd.o's Code of Conduct. > >>> > >>> v2: Point at MAINTAINERS for contact info (Daniel S.) > >>> > >>> v3: > >>> - Make it clear that commit rights are voluntary and that committers > >>> need to acknowledge positively when they're nominated by someone > >>> else (Keith). > >>> - Encourage committers to drop their commit rights when they're no > >>> longer active, and make it clear they'll get readded (Keith). > >>> - Add a line that maintainers and committers should actively nominate > >>> new committers (me). > >>> > >>> v4: Typo (Petri). > >>> > >>> v5: Typo (Sean). > >>> > >>> v6: Wording clarifications and spelling (Jani). > >>> > >>> v7: Require an explicit commitment to the documented merge criteria > >>> and rules, instead of just the implied one through the Code of Conduct > >>> threat (Jani). > >>> > >>> Acked-by: Alex Deucher > >>> Acked-by: Arkadiusz Hiler > >>> Acked-by: Daniel Stone > >>> Acked-by: Eric Anholt > >>> Acked-by: Gustavo Padovan > >>> Acked-by: Petri Latvala > >>> Cc: Alex Deucher > >>> Cc: Arkadiusz Hiler > >>> Cc: Ben Widawsky > >>> Cc: Daniel Stone > >>> Cc: Dave Airlie > >>> Cc: Eric Anholt > >>> Cc: Gustavo Padovan > >>> Cc: Jani Nikula > >>> Cc: Joonas Lahtinen > >>> Cc: Keith Packard > >>> Cc: Kenneth Graunke > >>> Cc: Kristian H. Kristensen > >>> Cc: Maarten Lankhorst > >>> Cc: Petri Latvala > >>> Cc: Rodrigo Vivi > >>> Cc: Sean Paul > >>> Reviewed-by: Keith Packard > >>> Signed-off-by: Daniel Vetter > >>> --- > >>> If you wonder about the wide distribution list for an igt patch: I'd > >>> like to start a discussions about x.org community norms around commit > >>> rights at large, at least for all the shared repos. I plan to propose > >>> the same text for drm-misc and libdrm too, and hopefully others like > >>> mesa/xserver/wayland would follow. > >>> > >> I think the idea is pretty good, simply highlighting some bits. > >> > >> What you've outlined in this patch has been in practise for many years: > >> a) undocumented, applicable to most xorg projects [1] > >> b) documented, mesa > > > > Hm, I chatted with a few mesa devs about this, and I wasn't aware > > there's explicit documentation for mesa. Where is it? I'd very much > > want to align as much as we can. > > > See the "Developer git Access" section in [1]. FWIW I prefer the > wording used in this patch and the CoC reference is a big plus. > > HTH > Emil > > [1] https://www.mesa3d.org/repository.html Ah missed this indeed. One thing to note wrt mesa is that this text here relies heavily on _documented_ merge criteria. When I discussed it with mesa we realized that the documented merge criteria do not really match the actual criteria: https://www.mesa3d.org/submittingpatches.html E.g. for many drivers review is mandatory I think, same for core code. And Intel folks require that you go through their CI too. So the bigger part in adopting this for mesa would be in updating the merge criteria doc to reflect reality. Anyway, I'm happy that even the few terse lines match what I'm proposing here (minus lots of details), I think we're good to go. -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] drm/i915: Use memset64() to align the ring with MI_NOOP
On 25/04/2018 13:37, Chris Wilson wrote:
When filling the ring to align the emit pointer to the next cacheline,
use memset64() rather than open-coding it. As we know that we always
have an even number of dwords, we can replace the dword loop with the
qword equivalent.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index c68ac605b8a9..07a9a2b4beb7 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1717,22 +1717,24 @@ u32 *intel_ring_begin(struct i915_request *rq, unsigned
int num_dwords)
/* Align the ring tail to a cacheline boundary */
int intel_ring_cacheline_align(struct i915_request *rq)
{
- int num_dwords = (rq->ring->emit & (CACHELINE_BYTES - 1)) / sizeof(u32);
- u32 *cs;
+ int num_dwords;
+ void *cs;
+ num_dwords = (rq->ring->emit & (CACHELINE_BYTES - 1)) / sizeof(u32);
if (num_dwords == 0)
return 0;
- num_dwords = CACHELINE_BYTES / sizeof(u32) - num_dwords;
+ num_dwords = CACHELINE_DWORDS - num_dwords;
+ GEM_BUG_ON(num_dwords & 1);
+
cs = intel_ring_begin(rq, num_dwords);
if (IS_ERR(cs))
return PTR_ERR(cs);
- while (num_dwords--)
- *cs++ = MI_NOOP;
-
BUILD_BUG_ON(MI_NOOP != 0) for paranoid future proofing, since MI_NOOP
is now not mentioned in this function, but is meant.
+ memset64(cs, 0, num_dwords/2);
Spaces around '/' to appease checkpatch and our style.
intel_ring_advance(rq, cs);
+ GEM_BUG_ON(rq->ring->emit & CACHELINE_BYTES);
return 0;
}
With whitespace fixed, and preferably BUILD_BUG_ON:
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/edid: Reset more of the display info
On Tue, Apr 24, 2018 at 09:36:29PM +0200, Daniel Vetter wrote:
> On Tue, Apr 24, 2018 at 05:26:30PM +0300, Ville Syrjälä wrote:
> > On Tue, Apr 24, 2018 at 04:18:37PM +0200, Daniel Vetter wrote:
> > > On Tue, Apr 24, 2018 at 04:02:50PM +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > We're currently failing to reset everything in display_info.hdmi
> > > > which will potentially cause us to use stale information when
> > > > swapping monitors. Eg. if the user replaces a HDMI 2.0 monitor
> > > > with a HDMI 1.x monitor we will continue to think that the monitor
> > > > supports scrambling. That will lead to a black screen since the
> > > > HDMI 1.x monitor won't understand the scrambled signal.
> > > >
> > > > Fix the problem by clearing display_info.hdmi fully. And while at
> > > > eliminate some duplicated code by calling drm_reset_display_info()
> > > > in drm_add_display_info().
> > > >
> > > > Cc: Antony Chen
> > > > Cc: Shashank Sharma
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105655
> > > > Signed-off-by: Ville Syrjälä
> > > > ---
> > > > drivers/gpu/drm/drm_edid.c | 11 +++
> > > > 1 file changed, 3 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > > index 134069f36482..39f1db4acda4 100644
> > > > --- a/drivers/gpu/drm/drm_edid.c
> > > > +++ b/drivers/gpu/drm/drm_edid.c
> > > > @@ -4451,6 +4451,7 @@ drm_reset_display_info(struct drm_connector
> > > > *connector)
> > > > info->max_tmds_clock = 0;
> > > > info->dvi_dual = false;
> > > > info->has_hdmi_infoframe = false;
> > > > + memset(&info->hdmi, 0, sizeof(info->hdmi));
> > > >
> > > > info->non_desktop = 0;
> > > > }
> > > > @@ -4462,17 +4463,11 @@ u32 drm_add_display_info(struct drm_connector
> > > > *connector, const struct edid *edi
> > > >
> > > > u32 quirks = edid_get_quirks(edid);
> > > >
> > > > + drm_reset_display_info(connector);
> > > > +
> > >
> > > Strictly speaking this is a separate bugfix, for the case where you
> > > immediately go from one output to a different one. Keith already fixed the
> > > case where at least somewhere in between you go to the disconnected state
> > > in:
> > >
> > > commit 170178fe99dd212bf25e70c89bc4b6e195564ffc
> > > Author: Keith Packard
> > > Date: Wed Dec 13 00:44:26 2017 -0800
> > >
> > > drm: Update edid-derived drm_display_info fields at edid property set
> > > [v2]
> > >
> > > With the above explained in the commit message:
> >
> > The drm_reset_display_info() call is just the "deduplicate the code"
> > part. The memset() is the bugfix, and applies in all cases.
>
> Hm ... I guess my brain wasn't fully working.
>
> Reviewed-by: Daniel Vetter
>
> as-is.
Cool. Thanks.
Pushed to drm-misc-fixes with
Cc: sta...@vger.kernel.org
Tested-by: Antony Chen
> -Daniel
>
> >
> > >
> > > Reviewed-by: Daniel Vetter
> > >
> > > > info->width_mm = edid->width_cm * 10;
> > > > info->height_mm = edid->height_cm * 10;
> > > >
> > > > - /* driver figures it out in this case */
> > > > - info->bpc = 0;
> > > > - info->color_formats = 0;
> > > > - info->cea_rev = 0;
> > > > - info->max_tmds_clock = 0;
> > > > - info->dvi_dual = false;
> > > > - info->has_hdmi_infoframe = false;
> > > > -
> > > > info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
> > > >
> > > > DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
> > > > --
> > > > 2.16.1
> > > >
> > > > ___
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> >
> > --
> > Ville Syrjälä
> > Intel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use memset64() to align the ring with MI_NOOP
Quoting Tvrtko Ursulin (2018-04-25 15:00:43)
>
> On 25/04/2018 13:37, Chris Wilson wrote:
> > When filling the ring to align the emit pointer to the next cacheline,
> > use memset64() rather than open-coding it. As we know that we always
> > have an even number of dwords, we can replace the dword loop with the
> > qword equivalent.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/intel_ringbuffer.c | 14 --
> > 1 file changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index c68ac605b8a9..07a9a2b4beb7 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -1717,22 +1717,24 @@ u32 *intel_ring_begin(struct i915_request *rq,
> > unsigned int num_dwords)
> > /* Align the ring tail to a cacheline boundary */
> > int intel_ring_cacheline_align(struct i915_request *rq)
> > {
> > - int num_dwords = (rq->ring->emit & (CACHELINE_BYTES - 1)) /
> > sizeof(u32);
> > - u32 *cs;
> > + int num_dwords;
> > + void *cs;
> >
> > + num_dwords = (rq->ring->emit & (CACHELINE_BYTES - 1)) / sizeof(u32);
> > if (num_dwords == 0)
> > return 0;
> >
> > - num_dwords = CACHELINE_BYTES / sizeof(u32) - num_dwords;
> > + num_dwords = CACHELINE_DWORDS - num_dwords;
> > + GEM_BUG_ON(num_dwords & 1);
> > +
> > cs = intel_ring_begin(rq, num_dwords);
> > if (IS_ERR(cs))
> > return PTR_ERR(cs);
> >
> > - while (num_dwords--)
> > - *cs++ = MI_NOOP;
> > -
>
> BUILD_BUG_ON(MI_NOOP != 0) for paranoid future proofing, since MI_NOOP
> is now not mentioned in this function, but is meant.
((u64)MI_NOOP << 32 | MI_NOOP) ?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/edid: Reset more of the display info
On Wed, Apr 25, 2018 at 07:03:14PM +0800, Antony Chen wrote:
> Hi all,
>
> The patch works: drivers/gpu/drm/drm_edid.c
> I switch 4K@60 and 4K@30 monitors some times, monitors show correct output.
> Thanks for your help.
>
> What are the steps to close the issue in freedesktop? Append the patch by
> Ville
> Syrjälä, then I close it?
The bug is now resolved. Thanks for reporting the problem and testing
the fix.
>
> Antony
>
> 2018-04-25 3:36 GMT+08:00 Daniel Vetter :
>
> > On Tue, Apr 24, 2018 at 05:26:30PM +0300, Ville Syrjälä wrote:
> > > On Tue, Apr 24, 2018 at 04:18:37PM +0200, Daniel Vetter wrote:
> > > > On Tue, Apr 24, 2018 at 04:02:50PM +0300, Ville Syrjala wrote:
> > > > > From: Ville Syrjälä
> > > > >
> > > > > We're currently failing to reset everything in display_info.hdmi
> > > > > which will potentially cause us to use stale information when
> > > > > swapping monitors. Eg. if the user replaces a HDMI 2.0 monitor
> > > > > with a HDMI 1.x monitor we will continue to think that the monitor
> > > > > supports scrambling. That will lead to a black screen since the
> > > > > HDMI 1.x monitor won't understand the scrambled signal.
> > > > >
> > > > > Fix the problem by clearing display_info.hdmi fully. And while at
> > > > > eliminate some duplicated code by calling drm_reset_display_info()
> > > > > in drm_add_display_info().
> > > > >
> > > > > Cc: Antony Chen
> > > > > Cc: Shashank Sharma
> > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105655
> > > > > Signed-off-by: Ville Syrjälä
> > > > > ---
> > > > > drivers/gpu/drm/drm_edid.c | 11 +++
> > > > > 1 file changed, 3 insertions(+), 8 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > > > index 134069f36482..39f1db4acda4 100644
> > > > > --- a/drivers/gpu/drm/drm_edid.c
> > > > > +++ b/drivers/gpu/drm/drm_edid.c
> > > > > @@ -4451,6 +4451,7 @@ drm_reset_display_info(struct drm_connector
> > *connector)
> > > > > info->max_tmds_clock = 0;
> > > > > info->dvi_dual = false;
> > > > > info->has_hdmi_infoframe = false;
> > > > > + memset(&info->hdmi, 0, sizeof(info->hdmi));
> > > > >
> > > > > info->non_desktop = 0;
> > > > > }
> > > > > @@ -4462,17 +4463,11 @@ u32 drm_add_display_info(struct
> > drm_connector *connector, const struct edid *edi
> > > > >
> > > > > u32 quirks = edid_get_quirks(edid);
> > > > >
> > > > > + drm_reset_display_info(connector);
> > > > > +
> > > >
> > > > Strictly speaking this is a separate bugfix, for the case where you
> > > > immediately go from one output to a different one. Keith already fixed
> > the
> > > > case where at least somewhere in between you go to the disconnected
> > state
> > > > in:
> > > >
> > > > commit 170178fe99dd212bf25e70c89bc4b6e195564ffc
> > > > Author: Keith Packard
> > > > Date: Wed Dec 13 00:44:26 2017 -0800
> > > >
> > > > drm: Update edid-derived drm_display_info fields at edid property
> > set [v2]
> > > >
> > > > With the above explained in the commit message:
> > >
> > > The drm_reset_display_info() call is just the "deduplicate the code"
> > > part. The memset() is the bugfix, and applies in all cases.
> >
> > Hm ... I guess my brain wasn't fully working.
> >
> > Reviewed-by: Daniel Vetter
> >
> > as-is.
> > -Daniel
> >
> > >
> > > >
> > > > Reviewed-by: Daniel Vetter
> > > >
> > > > > info->width_mm = edid->width_cm * 10;
> > > > > info->height_mm = edid->height_cm * 10;
> > > > >
> > > > > - /* driver figures it out in this case */
> > > > > - info->bpc = 0;
> > > > > - info->color_formats = 0;
> > > > > - info->cea_rev = 0;
> > > > > - info->max_tmds_clock = 0;
> > > > > - info->dvi_dual = false;
> > > > > - info->has_hdmi_infoframe = false;
> > > > > -
> > > > > info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
> > > > >
> > > > > DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
> > > > > --
> > > > > 2.16.1
> > > > >
> > > > > ___
> > > > > Intel-gfx mailing list
> > > > > Intel-gfx@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > >
> > > > --
> > > > Daniel Vetter
> > > > Software Engineer, Intel Corporation
> > > > http://blog.ffwll.ch
> > >
> > > --
> > > Ville Syrjälä
> > > Intel
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> >
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use memset64() to align the ring with MI_NOOP
On 25/04/2018 15:09, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-25 15:00:43)
On 25/04/2018 13:37, Chris Wilson wrote:
When filling the ring to align the emit pointer to the next cacheline,
use memset64() rather than open-coding it. As we know that we always
have an even number of dwords, we can replace the dword loop with the
qword equivalent.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index c68ac605b8a9..07a9a2b4beb7 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1717,22 +1717,24 @@ u32 *intel_ring_begin(struct i915_request *rq, unsigned
int num_dwords)
/* Align the ring tail to a cacheline boundary */
int intel_ring_cacheline_align(struct i915_request *rq)
{
- int num_dwords = (rq->ring->emit & (CACHELINE_BYTES - 1)) / sizeof(u32);
- u32 *cs;
+ int num_dwords;
+ void *cs;
+ num_dwords = (rq->ring->emit & (CACHELINE_BYTES - 1)) / sizeof(u32);
if (num_dwords == 0)
return 0;
- num_dwords = CACHELINE_BYTES / sizeof(u32) - num_dwords;
+ num_dwords = CACHELINE_DWORDS - num_dwords;
+ GEM_BUG_ON(num_dwords & 1);
+
cs = intel_ring_begin(rq, num_dwords);
if (IS_ERR(cs))
return PTR_ERR(cs);
- while (num_dwords--)
- *cs++ = MI_NOOP;
-
BUILD_BUG_ON(MI_NOOP != 0) for paranoid future proofing, since MI_NOOP
is now not mentioned in this function, but is meant.
((u64)MI_NOOP << 32 | MI_NOOP) ?
That also works, can keep the r-b.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915: Remove obsolete min/max freq setters from debugfs
A more complete, and more importantly stable, interface for controlling
the RPS frequency range is available in sysfs, obsoleting the unstable
debugfs.
It's presence seems to trick people into using it, forgetting it is not
ABI.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106237
Signed-off-by: Chris Wilson
Reviewed-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_debugfs.c | 115
1 file changed, 115 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2f05f5262bba..1c88805d3354 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4204,119 +4204,6 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_drop_caches_fops,
i915_drop_caches_get, i915_drop_caches_set,
"0x%08llx\n");
-static int
-i915_max_freq_get(void *data, u64 *val)
-{
- struct drm_i915_private *dev_priv = data;
-
- if (INTEL_GEN(dev_priv) < 6)
- return -ENODEV;
-
- *val = intel_gpu_freq(dev_priv, dev_priv->gt_pm.rps.max_freq_softlimit);
- return 0;
-}
-
-static int
-i915_max_freq_set(void *data, u64 val)
-{
- struct drm_i915_private *dev_priv = data;
- struct intel_rps *rps = &dev_priv->gt_pm.rps;
- u32 hw_max, hw_min;
- int ret;
-
- if (INTEL_GEN(dev_priv) < 6)
- return -ENODEV;
-
- DRM_DEBUG_DRIVER("Manually setting max freq to %llu\n", val);
-
- ret = mutex_lock_interruptible(&dev_priv->pcu_lock);
- if (ret)
- return ret;
-
- /*
-* Turbo will still be enabled, but won't go above the set value.
-*/
- val = intel_freq_opcode(dev_priv, val);
-
- hw_max = rps->max_freq;
- hw_min = rps->min_freq;
-
- if (val < hw_min || val > hw_max || val < rps->min_freq_softlimit) {
- mutex_unlock(&dev_priv->pcu_lock);
- return -EINVAL;
- }
-
- rps->max_freq_softlimit = val;
-
- if (intel_set_rps(dev_priv, val))
- DRM_DEBUG_DRIVER("failed to update RPS to new softlimit\n");
-
- mutex_unlock(&dev_priv->pcu_lock);
-
- return 0;
-}
-
-DEFINE_SIMPLE_ATTRIBUTE(i915_max_freq_fops,
- i915_max_freq_get, i915_max_freq_set,
- "%llu\n");
-
-static int
-i915_min_freq_get(void *data, u64 *val)
-{
- struct drm_i915_private *dev_priv = data;
-
- if (INTEL_GEN(dev_priv) < 6)
- return -ENODEV;
-
- *val = intel_gpu_freq(dev_priv, dev_priv->gt_pm.rps.min_freq_softlimit);
- return 0;
-}
-
-static int
-i915_min_freq_set(void *data, u64 val)
-{
- struct drm_i915_private *dev_priv = data;
- struct intel_rps *rps = &dev_priv->gt_pm.rps;
- u32 hw_max, hw_min;
- int ret;
-
- if (INTEL_GEN(dev_priv) < 6)
- return -ENODEV;
-
- DRM_DEBUG_DRIVER("Manually setting min freq to %llu\n", val);
-
- ret = mutex_lock_interruptible(&dev_priv->pcu_lock);
- if (ret)
- return ret;
-
- /*
-* Turbo will still be enabled, but won't go below the set value.
-*/
- val = intel_freq_opcode(dev_priv, val);
-
- hw_max = rps->max_freq;
- hw_min = rps->min_freq;
-
- if (val < hw_min ||
- val > hw_max || val > rps->max_freq_softlimit) {
- mutex_unlock(&dev_priv->pcu_lock);
- return -EINVAL;
- }
-
- rps->min_freq_softlimit = val;
-
- if (intel_set_rps(dev_priv, val))
- DRM_DEBUG_DRIVER("failed to update RPS to new softlimit\n");
-
- mutex_unlock(&dev_priv->pcu_lock);
-
- return 0;
-}
-
-DEFINE_SIMPLE_ATTRIBUTE(i915_min_freq_fops,
- i915_min_freq_get, i915_min_freq_set,
- "%llu\n");
-
static int
i915_cache_sharing_get(void *data, u64 *val)
{
@@ -4878,8 +4765,6 @@ static const struct i915_debugfs_files {
const struct file_operations *fops;
} i915_debugfs_files[] = {
{"i915_wedged", &i915_wedged_fops},
- {"i915_max_freq", &i915_max_freq_fops},
- {"i915_min_freq", &i915_min_freq_fops},
{"i915_cache_sharing", &i915_cache_sharing_fops},
{"i915_ring_missed_irq", &i915_ring_missed_irq_fops},
{"i915_ring_test_irq", &i915_ring_test_irq_fops},
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915: reprogram NOA muxes on context switch when using perf
On 25/04/18 12:57, Chris Wilson wrote: Quoting Lionel Landwerlin (2018-04-25 12:45:19) If some of the contexts submitting workloads to the GPU have been configured to shutdown slices/subslices, we might loose the NOA configurations written in the NOA muxes. We need to reprogram them at context switch. On every single batchbuffer, no way. That's around a 33% latency hit, ignoring the cost of what's inside the wa_bb. If they are not context saved, userspace isn't going to be allowed to modify them. So why do we need this? If they not context saved, then the kernel needs to control them and doesn't need to reset around every batch, just the one's that want non-default (fancier if we handle preemption)? -Chris These are neither context saved, nor power saved :( I can't tell whether the GuC might schedule things behind our back. But eventually that will happen anyway. So that's why I put the reprogramming in per ctx wa. Agreed, it sucks. I'll look into the fancier things. Thanks, - Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Remove obsolete min/max freq setters from debugfs
== Series Details ==
Series: drm/i915: Remove obsolete min/max freq setters from debugfs
URL : https://patchwork.freedesktop.org/series/42293/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4094 -> Patchwork_8799 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_8799 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_8799, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/42293/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_8799:
=== IGT changes ===
Possible regressions
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-glk-j4005: PASS -> DMESG-WARN
== Known issues ==
Here are the changes found in Patchwork_8799 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_frontbuffer_tracking@basic:
{fi-hsw-4200u}: PASS -> DMESG-FAIL (fdo#106103)
igt@kms_pipe_crc_basic@hang-read-crc-pipe-b:
fi-skl-guc: PASS -> FAIL (fdo#103191)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713)
Possible fixes
igt@gem_exec_suspend@basic-s3:
fi-ivb-3520m: DMESG-WARN (fdo#106084) -> PASS
igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
fi-glk-j4005: DMESG-WARN -> PASS
igt@pm_rpm@basic-pci-d3-state:
fi-glk-j4005: DMESG-WARN (fdo#106097) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084
fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097
fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103
== Participating hosts (39 -> 35) ==
Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq fi-pnv-d510
== Build changes ==
* Linux: CI_DRM_4094 -> Patchwork_8799
CI_DRM_4094: e4641c176c96e8b4a7951f6a38dd681c20754173 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4448: 0350f0e7f6a0e07281445fc3082aa70419f4aac7 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_8799: bf35568b684a85b41ad1e046a35dfecfeb46190b @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4448: 1a4372adb07ede41e35ff4786b9b034fc603b105 @
git://anongit.freedesktop.org/piglit
== Linux commits ==
bf35568b684a drm/i915: Remove obsolete min/max freq setters from debugfs
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8799/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Correctly clear lost ctx-switch interrupts across reset for Gen11
Quoting Michel Thierry (2018-04-24 23:27:41)
> On 4/24/2018 2:39 PM, Oscar Mateo wrote:
> > Interrupt handling in Gen11 is quite different from previous platforms.
> >
> > v2: Rebased (Michel)
> > v3: Rebased with wiggle
> > v4: Rebased, remove TODO warning correctly (Daniele)
> > v5: Rebased, made gen11_gtiir const while at it (Michel)
> > v6: Rebased
> > v7: Adapt to the style currently in upstream
> >
> > Suggested-by: Michel Thierry
> > Signed-off-by: Rodrigo Vivi
> > Signed-off-by: Michel Thierry
> > Signed-off-by: Oscar Mateo
> > Cc: Tvrtko Ursulin
> > Cc: Daniele Ceraolo Spurio
> > Cc: Mika Kuoppala
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 6 ++--
> > drivers/gpu/drm/i915/intel_drv.h | 3 ++
> > drivers/gpu/drm/i915/intel_lrc.c | 60
> >
> > 3 files changed, 48 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 96547e0..f9bc3aa 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -247,9 +247,9 @@ void i915_hotplug_interrupt_update(struct
> > drm_i915_private *dev_priv,
> > gen11_gt_engine_identity(struct drm_i915_private * const i915,
> >const unsigned int bank, const unsigned int bit);
> >
> > -static bool gen11_reset_one_iir(struct drm_i915_private * const i915,
> > - const unsigned int bank,
> > - const unsigned int bit)
> > +bool gen11_reset_one_iir(struct drm_i915_private * const i915,
> > + const unsigned int bank,
> > + const unsigned int bit)
> > {
> > void __iomem * const regs = i915->regs;
> > u32 dw;
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 58868b9..9bba035 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1333,6 +1333,9 @@ void intel_pch_fifo_underrun_irq_handler(struct
> > drm_i915_private *dev_priv,
> > void intel_check_pch_fifo_underruns(struct drm_i915_private *dev_priv);
> >
> > /* i915_irq.c */
> > +bool gen11_reset_one_iir(struct drm_i915_private * const i915,
> > + const unsigned int bank,
> > + const unsigned int bit);
> > void gen5_enable_gt_irq(struct drm_i915_private *dev_priv, uint32_t mask);
> > void gen5_disable_gt_irq(struct drm_i915_private *dev_priv, uint32_t
> > mask);
> > void gen6_mask_pm_irq(struct drm_i915_private *dev_priv, u32 mask);
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 2d6572a..7ea5f36 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -789,22 +789,9 @@ static void execlists_dequeue(struct intel_engine_cs
> > *engine)
> >
> > static void clear_gtiir(struct intel_engine_cs *engine)
> > {
> > - static const u8 gtiir[] = {
> > - [RCS] = 0,
> > - [BCS] = 0,
> > - [VCS] = 1,
> > - [VCS2] = 1,
> > - [VECS] = 3,
> > - };
> > struct drm_i915_private *dev_priv = engine->i915;
> > int i;
> >
> > - /* TODO: correctly reset irqs for gen11 */
> > - if (WARN_ON_ONCE(INTEL_GEN(engine->i915) >= 11))
> > - return;
> > -
> > - GEM_BUG_ON(engine->id >= ARRAY_SIZE(gtiir));
> > -
> > /*
> >* Clear any pending interrupt state.
> >*
> > @@ -812,13 +799,50 @@ static void clear_gtiir(struct intel_engine_cs
> > *engine)
> >* double buffered, and so if we only reset it once there may
> >* still be an interrupt pending.
> >*/
> > - for (i = 0; i < 2; i++) {
> > - I915_WRITE(GEN8_GT_IIR(gtiir[engine->id]),
> > + if (INTEL_GEN(dev_priv) >= 11) {
> > + static const struct {
> > + u8 bank;
> > + u8 bit;
> > + } gen11_gtiir[] = {
> > + [RCS] = {0, GEN11_RCS0},
> > + [BCS] = {0, GEN11_BCS},
> > + [_VCS(0)] = {1, GEN11_VCS(0)},
> > + [_VCS(1)] = {1, GEN11_VCS(1)},
> > + [_VCS(2)] = {1, GEN11_VCS(2)},
> > + [_VCS(3)] = {1, GEN11_VCS(3)},
> > + [_VECS(0)] = {1, GEN11_VECS(0)},
> > + [_VECS(1)] = {1, GEN11_VECS(1)},
> > + };
> bit,bank values are correct so
>
> Reviewed-by: Michel Thierry
>
> > + unsigned long irqflags;
> > +
> > + GEM_BUG_ON(engine->id >= ARRAY_SIZE(gen11_gtiir));
> > +
> > + spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
> > + for (i = 0; i < 2; i++) {
> > + gen11_reset_one_iir(dev_priv,
> > + gen11_gtiir[engine->id].bank,
> > +
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: per context slice/subslice powergating
== Series Details == Series: drm/i915: per context slice/subslice powergating URL : https://patchwork.freedesktop.org/series/42285/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4093_full -> Patchwork_8797_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_8797_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8797_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/42285/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8797_full: === IGT changes === Possible regressions igt@gem_ctx_param@invalid-param-get: shard-apl: PASS -> FAIL shard-glk: PASS -> FAIL shard-kbl: PASS -> FAIL igt@gem_ctx_param@invalid-param-set: shard-kbl: PASS -> DMESG-FAIL shard-hsw: PASS -> FAIL +1 shard-snb: PASS -> FAIL +1 shard-glk: PASS -> DMESG-FAIL shard-apl: PASS -> DMESG-FAIL Warnings igt@gem_mocs_settings@mocs-rc6-render: shard-kbl: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_8797_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@2x-flip-vs-expired-vblank: shard-hsw: PASS -> FAIL (fdo#102887) igt@kms_flip@2x-plain-flip-ts-check-interruptible: shard-hsw: PASS -> FAIL (fdo#100368) igt@kms_flip@absolute-wf_vblank-interruptible: shard-apl: PASS -> FAIL (fdo#106087) igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-glk: PASS -> FAIL (fdo#102887) igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-gtt: shard-apl: PASS -> FAIL (fdo#103167) Possible fixes igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic: shard-hsw: FAIL (fdo#104873) -> PASS igt@kms_flip@flip-vs-modeset-vs-hang-interruptible: shard-kbl: DMESG-WARN (fdo#103558, fdo#105602) -> PASS +1 shard-snb: DMESG-WARN (fdo#103821) -> PASS igt@kms_flip@plain-flip-ts-check-interruptible: shard-glk: FAIL (fdo#100368) -> PASS shard-hsw: FAIL (fdo#100368) -> PASS igt@kms_frontbuffer_tracking@fbc-suspend: shard-kbl: DMESG-WARN (fdo#103558, fdo#105602, fdo#103841) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821 fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841 fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#106087 https://bugs.freedesktop.org/show_bug.cgi?id=106087 == Participating hosts (6 -> 5) == Missing(1): shard-glkb == Build changes == * Linux: CI_DRM_4093 -> Patchwork_8797 CI_DRM_4093: a47694a9464b96e17b12f0bdb1085d10a61c57e9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4446: e5e8dafc991ee922ec159491c680caff0cfe9235 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8797: 59ec862256e6d9a083390dd214a93d119d07e6f0 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4446: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8797/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use memset64() to align the ring with MI_NOOP
== Series Details == Series: drm/i915: Use memset64() to align the ring with MI_NOOP URL : https://patchwork.freedesktop.org/series/42290/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4093_full -> Patchwork_8798_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8798_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8798_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/42290/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8798_full: === IGT changes === Warnings igt@gem_mocs_settings@mocs-rc6-blt: shard-kbl: PASS -> SKIP +2 == Known issues == Here are the changes found in Patchwork_8798_full that come from known issues: === IGT changes === Issues hit igt@gem_eio@in-flight-contexts-immediate: shard-glk: PASS -> FAIL (fdo#105957) igt@kms_flip@2x-wf_vblank-ts-check: shard-hsw: PASS -> FAIL (fdo#103928) igt@kms_mmio_vs_cs_flip@setcrtc_vs_cs_flip: shard-kbl: PASS -> DMESG-WARN (fdo#103558, fdo#105602) +10 Possible fixes igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic: shard-hsw: FAIL (fdo#104873) -> PASS igt@kms_flip@flip-vs-modeset-vs-hang-interruptible: shard-kbl: DMESG-WARN (fdo#103558, fdo#105602) -> PASS +1 shard-snb: DMESG-WARN (fdo#103821) -> PASS igt@kms_flip@plain-flip-ts-check-interruptible: shard-glk: FAIL (fdo#100368) -> PASS +1 shard-hsw: FAIL (fdo#100368) -> PASS igt@kms_frontbuffer_tracking@fbc-suspend: shard-kbl: DMESG-WARN (fdo#103841, fdo#103558, fdo#105602) -> PASS igt@kms_sysfs_edid_timing: shard-apl: WARN (fdo#100047) -> PASS fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821 fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#105957 https://bugs.freedesktop.org/show_bug.cgi?id=105957 == Participating hosts (6 -> 5) == Missing(1): shard-glkb == Build changes == * Linux: CI_DRM_4093 -> Patchwork_8798 CI_DRM_4093: a47694a9464b96e17b12f0bdb1085d10a61c57e9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4446: e5e8dafc991ee922ec159491c680caff0cfe9235 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8798: a2d0462fc7d03f71bc819c2e777d60c0fef38c58 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4446: a2f486679f467cd6e82578384f56d4aabaa8cf2e @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8798/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Remove obsolete min/max freq setters from debugfs
== Series Details == Series: drm/i915: Remove obsolete min/max freq setters from debugfs URL : https://patchwork.freedesktop.org/series/42293/ State : failure == Summary == Applying: drm/i915: Remove obsolete min/max freq setters from debugfs Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_debugfs.c Falling back to patching base and 3-way merge... No changes -- Patch already applied. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8799/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/edid: Reset more of the display info
Hi all,
The patch works: drivers/gpu/drm/drm_edid.c
I switch 4K@60 and 4K@30 monitors some times, monitors show correct output.
Thanks for your help.
What are the steps to close the issue in freedesktop? Append the patch by Ville
Syrjälä, then I close it?
Antony
2018-04-25 3:36 GMT+08:00 Daniel Vetter :
> On Tue, Apr 24, 2018 at 05:26:30PM +0300, Ville Syrjälä wrote:
> > On Tue, Apr 24, 2018 at 04:18:37PM +0200, Daniel Vetter wrote:
> > > On Tue, Apr 24, 2018 at 04:02:50PM +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > We're currently failing to reset everything in display_info.hdmi
> > > > which will potentially cause us to use stale information when
> > > > swapping monitors. Eg. if the user replaces a HDMI 2.0 monitor
> > > > with a HDMI 1.x monitor we will continue to think that the monitor
> > > > supports scrambling. That will lead to a black screen since the
> > > > HDMI 1.x monitor won't understand the scrambled signal.
> > > >
> > > > Fix the problem by clearing display_info.hdmi fully. And while at
> > > > eliminate some duplicated code by calling drm_reset_display_info()
> > > > in drm_add_display_info().
> > > >
> > > > Cc: Antony Chen
> > > > Cc: Shashank Sharma
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105655
> > > > Signed-off-by: Ville Syrjälä
> > > > ---
> > > > drivers/gpu/drm/drm_edid.c | 11 +++
> > > > 1 file changed, 3 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > > index 134069f36482..39f1db4acda4 100644
> > > > --- a/drivers/gpu/drm/drm_edid.c
> > > > +++ b/drivers/gpu/drm/drm_edid.c
> > > > @@ -4451,6 +4451,7 @@ drm_reset_display_info(struct drm_connector
> *connector)
> > > > info->max_tmds_clock = 0;
> > > > info->dvi_dual = false;
> > > > info->has_hdmi_infoframe = false;
> > > > + memset(&info->hdmi, 0, sizeof(info->hdmi));
> > > >
> > > > info->non_desktop = 0;
> > > > }
> > > > @@ -4462,17 +4463,11 @@ u32 drm_add_display_info(struct
> drm_connector *connector, const struct edid *edi
> > > >
> > > > u32 quirks = edid_get_quirks(edid);
> > > >
> > > > + drm_reset_display_info(connector);
> > > > +
> > >
> > > Strictly speaking this is a separate bugfix, for the case where you
> > > immediately go from one output to a different one. Keith already fixed
> the
> > > case where at least somewhere in between you go to the disconnected
> state
> > > in:
> > >
> > > commit 170178fe99dd212bf25e70c89bc4b6e195564ffc
> > > Author: Keith Packard
> > > Date: Wed Dec 13 00:44:26 2017 -0800
> > >
> > > drm: Update edid-derived drm_display_info fields at edid property
> set [v2]
> > >
> > > With the above explained in the commit message:
> >
> > The drm_reset_display_info() call is just the "deduplicate the code"
> > part. The memset() is the bugfix, and applies in all cases.
>
> Hm ... I guess my brain wasn't fully working.
>
> Reviewed-by: Daniel Vetter
>
> as-is.
> -Daniel
>
> >
> > >
> > > Reviewed-by: Daniel Vetter
> > >
> > > > info->width_mm = edid->width_cm * 10;
> > > > info->height_mm = edid->height_cm * 10;
> > > >
> > > > - /* driver figures it out in this case */
> > > > - info->bpc = 0;
> > > > - info->color_formats = 0;
> > > > - info->cea_rev = 0;
> > > > - info->max_tmds_clock = 0;
> > > > - info->dvi_dual = false;
> > > > - info->has_hdmi_infoframe = false;
> > > > -
> > > > info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
> > > >
> > > > DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
> > > > --
> > > > 2.16.1
> > > >
> > > > ___
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> >
> > --
> > Ville Syrjälä
> > Intel
>
> --
> 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] drm/i915: Add documentation to gen9_set_dc_state()
On Wed, Apr 25, 2018 at 02:09:14PM +0300, Imre Deak wrote:
> On Wed, Apr 25, 2018 at 12:50:06PM +0300, Jani Nikula wrote:
> >
> > Argh, now with Ville's correct address.
> >
> > On Wed, 25 Apr 2018, Jani Nikula wrote:
> > > Cc: Rodrigo, DK, Ville
> > >
> > > On Tue, 17 Apr 2018, Imre Deak wrote:
> > >> Add documentation to gen9_set_dc_state() on what enabling a given DC
> > >> state means and at what point HW/DMC actually enters/exits these states.
> > >>
> > >> Cc: Jani Nikula
> > >> Cc: Daniel Vetter
> > >> Signed-off-by: Imre Deak
> > >> ---
> > >> drivers/gpu/drm/i915/intel_runtime_pm.c | 23 +++
> > >> 1 file changed, 23 insertions(+)
> > >>
> > >> [ On IRC I stated that PSR entry would be prevented in a given DC state,
> > >> but looking more at it I haven't found any proof for this. So as I
> > >> understand the only connection between PSR and DC states is that if
> > >> DC5/6 is disabled power saving will be blocked, which would otherwise
> > >> be possible when PSR is active and the display pipe is off. ]
> > >
> > > I think I'm still missing a definitive answer to the question, who
> > > disables PSR before DP AUX transactions?
no one. :(
This is a gap that we are aware. I believe Jose is working to address that.
cc: Jose.
> > >
> > > Does intel_display_power_get(dev_priv, intel_dp->aux_power_domain) in
> > > pps_lock() cause PSR exit, through the DC state change? If yes, this
> > > needs to be properly documented in code. Maybe with a WARN_ON(psr
> > > active) on top.
>
> No, that was only my misunderstanding earlier on IRC. Disabling DC
> states doesn't prevent PSR entry. So the PSR active state is independent
> of DC states; if PSR is enabled with DC5/6 disabled it just means there
> will be less power saving during PSR active periods than it would be
> possible with DC5/6 enabled.
Yeap, they are independent.
>
> Disabling PSR then has to happen by some other means while the driver
> performs AUX transfers, either disabling it manually from the driver, or
> by using the AUX HW mutex.
AUX HW mutex is not an option. It got discarded again. Guidance from HW eng
is to avoid it and disable PSR manually before aux transactions.
>
> > >
> > > Quoting bspec 7530, "DDI A AUX channel transactions must not be sent
> > > while SRD is enabled. SRD must be completely disabled before a DDI A AUX
> > > channel transaction can be sent."
> > >
> > > I'm also confused how sink CRC would ever work with PSR enabled.
Our driver does aux transactions on modesets and hw does them on psr sync.
Sink CRC is used on the tests after modeset and hopefully when psr is
stable. But this actually could explain most of sink CRC issues we had
so far, indeed. Too much assumption and so less checks and protections :(
my bad...
> > >
> > > BR,
> > > Jani.
> > >
> > >
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > >> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > >> index 53ea564f971e..40a7955886d4 100644
> > >> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > >> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > >> @@ -542,6 +542,29 @@ void gen9_sanitize_dc_state(struct drm_i915_private
> > >> *dev_priv)
> > >> dev_priv->csr.dc_state = val;
> > >> }
> > >>
> > >> +/**
> > >> + * gen9_set_dc_state - set target display C power state
> > >> + * @dev_priv: i915 device instance
> > >> + * @state: target DC power state
> > >> + * - DC_STATE_DISABLE
> > >> + * - DC_STATE_EN_UPTO_DC5
> > >> + * - DC_STATE_EN_UPTO_DC6
> > >> + * - DC_STATE_EN_DC9
> > >> + *
> > >> + * Signal to DMC firmware/HW the target DC power state passed in @state.
> > >> + * DMC/HW can turn off individual display clocks and power rails when
> > >> entering
> > >> + * a deeper DC power state (higher in number) and turns these back when
> > >> exiting
> > >> + * that state to a shallower power state (lower in number). The HW will
> > >> decide
> > >> + * when to actually enter a given state on an on-demand basis, for
> > >> instance
> > >> + * depending on the active state of display pipes. The state of display
> > >> + * registers backed by affected power rails are saved/restored as
> > >> needed.
> > >> + *
> > >> + * Based on the above enabling a deeper DC power state is asynchronous
> > >> wrt.
> > >> + * enabling it. Disabling a deeper power state is synchronous: for
> > >> instance
> > >> + * setting %DC_STATE_DISABLE won't complete until all HW resources are
> > >> turned
> > >> + * back on and register state is restored. This is guaranteed by the
> > >> MMIO write
> > >> + * to DC_STATE_EN blocking until the state is restored.
> > >> + */
> > >> static void gen9_set_dc_state(struct drm_i915_private *dev_priv,
> > >> uint32_t state)
> > >> {
> > >> uint32_t val;
> >
> > --
> > Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.or
Re: [Intel-gfx] [CI] drm/i915: Remove obsolete min/max freq setters from debugfs
On Wed, Apr 25, 2018 at 03:23:34PM +0100, Chris Wilson wrote:
> A more complete, and more importantly stable, interface for controlling
> the RPS frequency range is available in sysfs, obsoleting the unstable
> debugfs.
>
> It's presence seems to trick people into using it, forgetting it is not
> ABI.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=106237
> Signed-off-by: Chris Wilson
> Reviewed-by: Sagar Arun Kamble
after CI gets happy:
Acked-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 115
> 1 file changed, 115 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 2f05f5262bba..1c88805d3354 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4204,119 +4204,6 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_drop_caches_fops,
> i915_drop_caches_get, i915_drop_caches_set,
> "0x%08llx\n");
>
> -static int
> -i915_max_freq_get(void *data, u64 *val)
> -{
> - struct drm_i915_private *dev_priv = data;
> -
> - if (INTEL_GEN(dev_priv) < 6)
> - return -ENODEV;
> -
> - *val = intel_gpu_freq(dev_priv, dev_priv->gt_pm.rps.max_freq_softlimit);
> - return 0;
> -}
> -
> -static int
> -i915_max_freq_set(void *data, u64 val)
> -{
> - struct drm_i915_private *dev_priv = data;
> - struct intel_rps *rps = &dev_priv->gt_pm.rps;
> - u32 hw_max, hw_min;
> - int ret;
> -
> - if (INTEL_GEN(dev_priv) < 6)
> - return -ENODEV;
> -
> - DRM_DEBUG_DRIVER("Manually setting max freq to %llu\n", val);
> -
> - ret = mutex_lock_interruptible(&dev_priv->pcu_lock);
> - if (ret)
> - return ret;
> -
> - /*
> - * Turbo will still be enabled, but won't go above the set value.
> - */
> - val = intel_freq_opcode(dev_priv, val);
> -
> - hw_max = rps->max_freq;
> - hw_min = rps->min_freq;
> -
> - if (val < hw_min || val > hw_max || val < rps->min_freq_softlimit) {
> - mutex_unlock(&dev_priv->pcu_lock);
> - return -EINVAL;
> - }
> -
> - rps->max_freq_softlimit = val;
> -
> - if (intel_set_rps(dev_priv, val))
> - DRM_DEBUG_DRIVER("failed to update RPS to new softlimit\n");
> -
> - mutex_unlock(&dev_priv->pcu_lock);
> -
> - return 0;
> -}
> -
> -DEFINE_SIMPLE_ATTRIBUTE(i915_max_freq_fops,
> - i915_max_freq_get, i915_max_freq_set,
> - "%llu\n");
> -
> -static int
> -i915_min_freq_get(void *data, u64 *val)
> -{
> - struct drm_i915_private *dev_priv = data;
> -
> - if (INTEL_GEN(dev_priv) < 6)
> - return -ENODEV;
> -
> - *val = intel_gpu_freq(dev_priv, dev_priv->gt_pm.rps.min_freq_softlimit);
> - return 0;
> -}
> -
> -static int
> -i915_min_freq_set(void *data, u64 val)
> -{
> - struct drm_i915_private *dev_priv = data;
> - struct intel_rps *rps = &dev_priv->gt_pm.rps;
> - u32 hw_max, hw_min;
> - int ret;
> -
> - if (INTEL_GEN(dev_priv) < 6)
> - return -ENODEV;
> -
> - DRM_DEBUG_DRIVER("Manually setting min freq to %llu\n", val);
> -
> - ret = mutex_lock_interruptible(&dev_priv->pcu_lock);
> - if (ret)
> - return ret;
> -
> - /*
> - * Turbo will still be enabled, but won't go below the set value.
> - */
> - val = intel_freq_opcode(dev_priv, val);
> -
> - hw_max = rps->max_freq;
> - hw_min = rps->min_freq;
> -
> - if (val < hw_min ||
> - val > hw_max || val > rps->max_freq_softlimit) {
> - mutex_unlock(&dev_priv->pcu_lock);
> - return -EINVAL;
> - }
> -
> - rps->min_freq_softlimit = val;
> -
> - if (intel_set_rps(dev_priv, val))
> - DRM_DEBUG_DRIVER("failed to update RPS to new softlimit\n");
> -
> - mutex_unlock(&dev_priv->pcu_lock);
> -
> - return 0;
> -}
> -
> -DEFINE_SIMPLE_ATTRIBUTE(i915_min_freq_fops,
> - i915_min_freq_get, i915_min_freq_set,
> - "%llu\n");
> -
> static int
> i915_cache_sharing_get(void *data, u64 *val)
> {
> @@ -4878,8 +4765,6 @@ static const struct i915_debugfs_files {
> const struct file_operations *fops;
> } i915_debugfs_files[] = {
> {"i915_wedged", &i915_wedged_fops},
> - {"i915_max_freq", &i915_max_freq_fops},
> - {"i915_min_freq", &i915_min_freq_fops},
> {"i915_cache_sharing", &i915_cache_sharing_fops},
> {"i915_ring_missed_irq", &i915_ring_missed_irq_fops},
> {"i915_ring_test_irq", &i915_ring_test_irq_fops},
> --
> 2.17.0
>
> ___
> 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 08/17] drm/i915/icl: Implement voltage swing programming sequence for Combo PHY DDI
On Tue, Apr 24, 2018 at 05:34:14PM -0700, Paulo Zanoni wrote:
> Em Qui, 2018-04-05 às 17:20 -0700, Rodrigo Vivi escreveu:
> > On Thu, Feb 22, 2018 at 12:55:10AM -0300, Paulo Zanoni wrote:
> > > From: Manasi Navare
> > >
> > > This is an important part of the DDI initalization as well as
> > > for changing the voltage during DisplayPort link training.
> > >
> > > The Voltage swing seqeuence is similar to Cannonlake.
> > > However it has different register definitions and hence
> > > it makes sense to create a separate vswing sequence and
> > > program functions for ICL to leave room for more changes
> > > in case the Bspec changes later and deviates from CNL sequence.
> > >
> > > v2:
> > > Use ~TAP3_DISABLE for enbaling that bit (Jani Nikula)
> > >
> > > v3:
> > > * Use dw4_scaling column for PORT_TX_DW4 values (Rodrigo)
> > >
> > > v4:
> > > * Call it combo_vswing, use switch statement (Paulo)
> > >
> > > v5 (from Paulo):
> > > * Fix a typo.
> > > * s/rate < 60/rate <= 60/.
> > > * Don't remove blank lines that should be there.
> > >
> > > v6:
> > > * Rebased by Rodrigo on top of Cannonlake changes
> > > where non vswing sequences are not aligned with iboost
> > > anymore.
> > >
> > > v7: Another rebase after an upstream rework.
> > >
> > > v8 (from Paulo):
> > > * Adjust the code to the upstream output type changes.
> > > * Squash the patch that moved some functions up.
> > > * Merge both get_combo_buf_trans functions in order to simplify the
> > > code.
> > > * Change the changelog format.
> > >
> > > Cc: Jani Nikula
> > > Reviewed-by: Paulo Zanoni (v5)
> > > Signed-off-by: Manasi Navare
> > > Signed-off-by: Rodrigo Vivi
> > > Signed-off-by: Paulo Zanoni
> > > ---
> > > drivers/gpu/drm/i915/intel_ddi.c | 189
> > > ++-
> > > 1 file changed, 186 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index 0a4683991ec2..c38873cb98ca 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -849,6 +849,45 @@ cnl_get_buf_trans_edp(struct drm_i915_private
> > > *dev_priv, int *n_entries)
> > > }
> > > }
> > >
> > > +static const struct icl_combo_phy_ddi_buf_trans *
> > > +icl_get_combo_buf_trans(struct drm_i915_private *dev_priv, enum
> > > port port,
> > > + int type, int *n_entries)
> > > +{
> > > + u32 voltage = I915_READ(ICL_PORT_COMP_DW3(port)) &
> > > VOLTAGE_INFO_MASK;
> > > +
> > > + if (type == INTEL_OUTPUT_EDP && dev_priv-
> > > >vbt.edp.low_vswing) {
> > > + switch (voltage) {
> > > + case VOLTAGE_INFO_0_85V:
> > > + *n_entries =
> > > ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_0_85V);
> > > + return
> > > icl_combo_phy_ddi_translations_edp_0_85V;
> > > + case VOLTAGE_INFO_0_95V:
> > > + *n_entries =
> > > ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_0_95V);
> > > + return
> > > icl_combo_phy_ddi_translations_edp_0_95V;
> > > + case VOLTAGE_INFO_1_05V:
> > > + *n_entries =
> > > ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_1_05V);
> > > + return
> > > icl_combo_phy_ddi_translations_edp_1_05V;
> > > + default:
> > > + MISSING_CASE(voltage);
> > > + return NULL;
> > > + }
> > > + } else {
> >
> > DP ends up here on HDMI?
> > This is strange...
>
> DP ends on the "dp_hdmi" part, while edp ends on the "edp" part. What
> is strange about that?
Oh... actually spec is strange...
They have 2 tables, 1 for DP and 1 for HDMI.
I just read them again and they are the same indeed.
So, nothing wrong here.
>
> >
> > Also, for clarity, why not to split this into separated functions
> > like all other platforms?
>
> So we don't end up reading PORT_COMP_DW3 multiple times (like we do for
> CNL), and as a bonus the code looks better IMHO.
Agree.
Reviewed-by: Rodrigo Vivi
>
>
>
> >
> > > + switch (voltage) {
> > > + case VOLTAGE_INFO_0_85V:
> > > + *n_entries =
> > > ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hdmi_0_85V);
> > > + return
> > > icl_combo_phy_ddi_translations_dp_hdmi_0_85V;
> > > + case VOLTAGE_INFO_0_95V:
> > > + *n_entries =
> > > ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hdmi_0_95V);
> > > + return
> > > icl_combo_phy_ddi_translations_dp_hdmi_0_95V;
> > > + case VOLTAGE_INFO_1_05V:
> > > + *n_entries =
> > > ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hdmi_1_05V);
> > > + return
> > > icl_combo_phy_ddi_translations_dp_hdmi_1_05V;
> > > + default:
> > > + MISSING_CASE(voltage);
> > > + return NULL;
> > > + }
> > > + }
> > > +}
> > > +
> > > static int intel_ddi_hdmi_level(struct drm_i915_private *dev_priv,
> > > enum
Re: [Intel-gfx] [PATCH] drm/i915: Add documentation to gen9_set_dc_state()
On Wed, 2018-04-25 at 10:45 -0700, Rodrigo Vivi wrote: > On Wed, Apr 25, 2018 at 02:09:14PM +0300, Imre Deak wrote: > > On Wed, Apr 25, 2018 at 12:50:06PM +0300, Jani Nikula wrote: > > > > > > Argh, now with Ville's correct address. > > > > > > On Wed, 25 Apr 2018, Jani Nikula wrote: > > > > Cc: Rodrigo, DK, Ville > > > > > > > > On Tue, 17 Apr 2018, Imre Deak wrote: > > > >> Add documentation to gen9_set_dc_state() on what enabling a given DC > > > >> state means and at what point HW/DMC actually enters/exits these > > > >> states. > > > >> > > > >> Cc: Jani Nikula > > > >> Cc: Daniel Vetter > > > >> Signed-off-by: Imre Deak > > > >> --- > > > >> drivers/gpu/drm/i915/intel_runtime_pm.c | 23 +++ > > > >> 1 file changed, 23 insertions(+) > > > >> > > > >> [ On IRC I stated that PSR entry would be prevented in a given DC > > > >> state, > > > >> but looking more at it I haven't found any proof for this. So as I > > > >> understand the only connection between PSR and DC states is that if > > > >> DC5/6 is disabled power saving will be blocked, which would otherwise > > > >> be possible when PSR is active and the display pipe is off. ] > > > > > > > > I think I'm still missing a definitive answer to the question, who > > > > disables PSR before DP AUX transactions? > > no one. :( > > This is a gap that we are aware. I believe Jose is working to address that. > > cc: Jose. > > > > > > > > > Does intel_display_power_get(dev_priv, intel_dp->aux_power_domain) in > > > > pps_lock() cause PSR exit, through the DC state change? If yes, this > > > > needs to be properly documented in code. Maybe with a WARN_ON(psr > > > > active) on top. > > > > No, that was only my misunderstanding earlier on IRC. Disabling DC > > states doesn't prevent PSR entry. So the PSR active state is independent > > of DC states; if PSR is enabled with DC5/6 disabled it just means there > > will be less power saving during PSR active periods than it would be > > possible with DC5/6 enabled. > > Yeap, they are independent. > > > > > Disabling PSR then has to happen by some other means while the driver > > performs AUX transfers, either disabling it manually from the driver, or > > by using the AUX HW mutex. > > AUX HW mutex is not an option. It got discarded again. Guidance from HW eng > is to avoid it and disable PSR manually before aux transactions. > > > > > > > > > > > Quoting bspec 7530, "DDI A AUX channel transactions must not be sent > > > > while SRD is enabled. SRD must be completely disabled before a DDI A AUX > > > > channel transaction can be sent." > > > > > > > > I'm also confused how sink CRC would ever work with PSR enabled. The bspec quote is specifically for BDW and HSW. The reason, presumably, is HW sends aux transactions for PSR exit (this, we know for sure) and the transactions can interfere with driver initiated aux transactions. afaict, there is nothing in the DP spec against aux reads (for sink-crc) when PSR is enabled. So, we have to be careful about reading sink-crc and not start the reads when PSR exit events happen. The current sink-crc code does the exact opposite by reading sink-crc after triggering PSR exit events, namely vbi enable. -DK > > Our driver does aux transactions on modesets and hw does them on psr sync. > > Sink CRC is used on the tests after modeset and hopefully when psr is > stable. But this actually could explain most of sink CRC issues we had > so far, indeed. Too much assumption and so less checks and protections :( > > my bad... > > > > > > > > > BR, > > > > Jani. > > > > > > > > > > > >> > > > >> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c > > > >> b/drivers/gpu/drm/i915/intel_runtime_pm.c > > > >> index 53ea564f971e..40a7955886d4 100644 > > > >> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c > > > >> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c > > > >> @@ -542,6 +542,29 @@ void gen9_sanitize_dc_state(struct > > > >> drm_i915_private *dev_priv) > > > >>dev_priv->csr.dc_state = val; > > > >> } > > > >> > > > >> +/** > > > >> + * gen9_set_dc_state - set target display C power state > > > >> + * @dev_priv: i915 device instance > > > >> + * @state: target DC power state > > > >> + * - DC_STATE_DISABLE > > > >> + * - DC_STATE_EN_UPTO_DC5 > > > >> + * - DC_STATE_EN_UPTO_DC6 > > > >> + * - DC_STATE_EN_DC9 > > > >> + * > > > >> + * Signal to DMC firmware/HW the target DC power state passed in > > > >> @state. > > > >> + * DMC/HW can turn off individual display clocks and power rails when > > > >> entering > > > >> + * a deeper DC power state (higher in number) and turns these back > > > >> when exiting > > > >> + * that state to a shallower power state (lower in number). The HW > > > >> will decide > > > >> + * when to actually enter a given state on an on-demand basis, for > > > >> instance > > > >> + * depending on the active state of display pipes. The state of > > > >> display > > > >> + * registers backed by a
Re: [Intel-gfx] [PATCH] drm/i915: Add documentation to gen9_set_dc_state()
On Tue, 2018-04-17 at 14:31 +0300, Imre Deak wrote:
> Add documentation to gen9_set_dc_state() on what enabling a given DC
> state means and at what point HW/DMC actually enters/exits these states.
>
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> [ On IRC I stated that PSR entry would be prevented in a given DC state,
> but looking more at it I haven't found any proof for this. So as I
> understand the only connection between PSR and DC states is that if
> DC5/6 is disabled power saving will be blocked, which would otherwise
> be possible when PSR is active and the display pipe is off. ]
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 53ea564f971e..40a7955886d4 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -542,6 +542,29 @@ void gen9_sanitize_dc_state(struct drm_i915_private
> *dev_priv)
> dev_priv->csr.dc_state = val;
> }
>
> +/**
> + * gen9_set_dc_state - set target display C power state
> + * @dev_priv: i915 device instance
> + * @state: target DC power state
> + * - DC_STATE_DISABLE
> + * - DC_STATE_EN_UPTO_DC5
> + * - DC_STATE_EN_UPTO_DC6
> + * - DC_STATE_EN_DC9
> + *
> + * Signal to DMC firmware/HW the target DC power state passed in @state.
> + * DMC/HW can turn off individual display clocks and power rails when
> entering
Any chance you could eliminate the firmware/HW ambiguity? Not knowing
whether it is the firmware or the HW leads to potentially incorrect
assumptions.
> + * a deeper DC power state (higher in number) and turns these back when
> exiting
> + * that state to a shallower power state (lower in number). The HW will
> decide
> + * when to actually enter a given state on an on-demand basis, for instance
> + * depending on the active state of display pipes. The state of display
> + * registers backed by affected power rails are saved/restored as needed.
> + *
One of things that is completely misleading is the enable_dc6 debug
message we print. It is all over dmesg, but like you already wrote, HW
needs PSR to be enabled and only in a single-pipe active case, the
display controller can go to DC6. So, with PSR disabled upstream, there
is really no chance that the HW can go to DC6 without all displays
disabled.
> + * Based on the above enabling a deeper DC power state is asynchronous wrt.
> + * enabling it. Disabling a deeper power state is synchronous: for instance
> + * setting %DC_STATE_DISABLE won't complete until all HW resources are turned
> + * back on and register state is restored. This is guaranteed by the MMIO
> write
> + * to DC_STATE_EN blocking until the state is restored.
> + */
> static void gen9_set_dc_state(struct drm_i915_private *dev_priv, uint32_t
> state)
> {
> uint32_t val;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/7] drm/i915/dp: abstract dp link config computation from the rest
On Thu, Apr 05, 2018 at 05:39:01PM +0300, Jani Nikula wrote:
> Abstract a new intel_dp_compute_link_config() from
> intel_dp_compute_config(), with the parts related to link configuration,
> i.e. bpp, link rate, and lane count selection. No functional changes.
>
This abstraction makes it cleaner and easy to add dsc compute config.
Reviewed-by: Manasi Navare
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dp.c | 160
> ++--
> 1 file changed, 87 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 81cf363e71af..19fe5eb8d32a 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1685,19 +1685,14 @@ static bool intel_edp_compare_alt_mode(struct
> drm_display_mode *m1,
> return bres;
> }
>
> -bool
> -intel_dp_compute_config(struct intel_encoder *encoder,
> - struct intel_crtc_state *pipe_config,
> - struct drm_connector_state *conn_state)
> +static bool
> +intel_dp_compute_link_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> struct drm_display_mode *adjusted_mode =
> &pipe_config->base.adjusted_mode;
> struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
> - enum port port = encoder->port;
> - struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
> struct intel_connector *intel_connector = intel_dp->attached_connector;
> - struct intel_digital_connector_state *intel_conn_state =
> - to_intel_digital_connector_state(conn_state);
> int lane_count, clock;
> int min_lane_count = 1;
> int max_lane_count = intel_dp_max_lane_count(intel_dp);
> @@ -1706,9 +1701,6 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> int bpp, mode_rate;
> int link_avail, link_clock;
> int common_len;
> - bool reduce_m_n = drm_dp_has_quirk(&intel_dp->desc,
> -DP_DPCD_QUIRK_LIMITED_M_N);
> -
> common_len = intel_dp_common_len_rate_limit(intel_dp,
> intel_dp->max_link_rate);
>
> @@ -1717,51 +1709,6 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>
> max_clock = common_len - 1;
>
> - if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && port != PORT_A)
> - pipe_config->has_pch_encoder = true;
> -
> - pipe_config->has_drrs = false;
> - if (IS_G4X(dev_priv) || port == PORT_A)
> - pipe_config->has_audio = false;
> - else if (intel_conn_state->force_audio == HDMI_AUDIO_AUTO)
> - pipe_config->has_audio = intel_dp->has_audio;
> - else
> - pipe_config->has_audio = intel_conn_state->force_audio ==
> HDMI_AUDIO_ON;
> -
> - if (intel_dp_is_edp(intel_dp) && intel_connector->panel.fixed_mode) {
> - struct drm_display_mode *panel_mode =
> - intel_connector->panel.alt_fixed_mode;
> - struct drm_display_mode *req_mode = &pipe_config->base.mode;
> -
> - if (!intel_edp_compare_alt_mode(req_mode, panel_mode))
> - panel_mode = intel_connector->panel.fixed_mode;
> -
> - drm_mode_debug_printmodeline(panel_mode);
> -
> - intel_fixed_panel_mode(panel_mode, adjusted_mode);
> -
> - if (INTEL_GEN(dev_priv) >= 9) {
> - int ret;
> - ret = skl_update_scaler_crtc(pipe_config);
> - if (ret)
> - return ret;
> - }
> -
> - if (HAS_GMCH_DISPLAY(dev_priv))
> - intel_gmch_panel_fitting(intel_crtc, pipe_config,
> - conn_state->scaling_mode);
> - else
> - intel_pch_panel_fitting(intel_crtc, pipe_config,
> - conn_state->scaling_mode);
> - }
> -
> - if ((IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) &&
> - adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
> - return false;
> -
> - if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
> - return false;
> -
> /* Use values requested by Compliance Test Request */
> if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) {
> int index;
> @@ -1831,6 +1778,82 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> return false;
>
> found:
> + pipe_config->lane_count = lane_count;
> + pipe_config->pipe_bpp = bpp;
> + pipe_config->port_clock = intel_dp->common_rates[clock];
> +
> + DRM_DEBUG_KMS("DP lane count %d clock %d bpp %d\n",
> + pipe_config->lane_count, pipe_config->port_clock, bpp);
> + DRM_DEBUG_KMS("DP
Re: [Intel-gfx] [PATCH 5/7] drm/i915/dp: group link config limits in a struct
On Thu, Apr 05, 2018 at 05:39:03PM +0300, Jani Nikula wrote:
> Also use same min/max model for bpp, and adjust debug logging while at
> it.
>
Reviewed-by: Manasi Navare
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dp.c | 57
> -
> 1 file changed, 33 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index dd42e0422af6..3c5fbdf42b9b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1647,6 +1647,12 @@ void intel_dp_compute_rate(struct intel_dp *intel_dp,
> int port_clock,
> }
> }
>
> +struct link_config_limits {
> + int min_clock, max_clock;
> + int min_lane_count, max_lane_count;
> + int min_bpp, max_bpp;
> +};
> +
> static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
> struct intel_crtc_state *pipe_config)
> {
> @@ -1704,21 +1710,25 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder,
> {
> struct drm_display_mode *adjusted_mode =
> &pipe_config->base.adjusted_mode;
> struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
> - int lane_count, clock;
> - int min_lane_count = 1;
> - int max_lane_count = intel_dp_max_lane_count(intel_dp);
> - int min_clock = 0;
> - int max_clock;
> - int bpp, mode_rate;
> - int link_avail, link_clock;
> + struct link_config_limits limits;
> + int bpp, clock, lane_count;
> + int mode_rate, link_avail, link_clock;
> int common_len;
> +
> common_len = intel_dp_common_len_rate_limit(intel_dp,
> intel_dp->max_link_rate);
>
> /* No common link rates between source and sink */
> WARN_ON(common_len <= 0);
>
> - max_clock = common_len - 1;
> + limits.min_clock = 0;
> + limits.max_clock = common_len - 1;
> +
> + limits.min_lane_count = 1;
> + limits.max_lane_count = intel_dp_max_lane_count(intel_dp);
> +
> + limits.min_bpp = 6 * 3;
> + limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
>
> /* Use values requested by Compliance Test Request */
> if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) {
> @@ -1733,18 +1743,11 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder,
> intel_dp->num_common_rates,
>
> intel_dp->compliance.test_link_rate);
> if (index >= 0)
> - min_clock = max_clock = index;
> - min_lane_count = max_lane_count =
> intel_dp->compliance.test_lane_count;
> + limits.min_clock = limits.max_clock = index;
> + limits.min_lane_count = limits.max_lane_count =
> intel_dp->compliance.test_lane_count;
> }
> }
> - DRM_DEBUG_KMS("DP link computation with max lane count %i "
> - "max bw %d pixel clock %iKHz\n",
> - max_lane_count, intel_dp->common_rates[max_clock],
> - adjusted_mode->crtc_clock);
>
> - /* Walk through all bpp values. Luckily they're all nicely spaced with 2
> - * bpc in between. */
> - bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
> if (intel_dp_is_edp(intel_dp)) {
> /*
>* Use the maximum clock and number of lanes the eDP panel
> @@ -1753,18 +1756,24 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder,
>* configuration, and typically these values correspond to the
>* native resolution of the panel.
>*/
> - min_lane_count = max_lane_count;
> - min_clock = max_clock;
> + limits.min_lane_count = limits.max_lane_count;
> + limits.min_clock = limits.max_clock;
> }
>
> - for (; bpp >= 6*3; bpp -= 2*3) {
> + DRM_DEBUG_KMS("DP link computation with max lane count %i "
> + "max rate %d max bpp %d pixel clock %iKHz\n",
> + limits.max_lane_count,
> + intel_dp->common_rates[limits.max_clock],
> + limits.max_bpp, adjusted_mode->crtc_clock);
> +
> + for (bpp = limits.max_bpp; bpp >= limits.min_bpp; bpp -= 2 * 3) {
> mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
> bpp);
>
> - for (clock = min_clock; clock <= max_clock; clock++) {
> - for (lane_count = min_lane_count;
> - lane_count <= max_lane_count;
> - lane_count <<= 1) {
> + for (clock = limits.min_clock; clock <= limits.max_clock;
> clock++) {
> + for (lane_count = limits.min_lane_count;
> + lane_count <=
[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave,
Here's the latest from -misc-fixes. Of note, no nasty backmerges as per the
thread on dim-tools. We have one regression fix, and two stable fixes, and a
couple of regular fixes for your consideration.
drm-misc-fixes-2018-04-25:
sun41: Fix regression for TBSA711 tablet (Ondrej)
qxl: 2 bug fixes (Gerd)
core: Don't use stale display info between HDMI hotplugs (Ville)
virtio: Fix guest spinning when request queue is full (Gerd)
Cc: Ondrej Jirman
Cc: Gerd Hoffmann
Cc: Ville Syrjälä
Cheers, Sean
The following changes since commit 6d08b06e67cd117f6992c46611dfb4ce267cd71e:
Linux 4.17-rc2 (2018-04-22 19:20:09 -0700)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-04-25
for you to fetch changes up to 1f6b8eef11c3d097bc8a6b2bbb868eb47ec6f7d8:
drm/edid: Reset more of the display info (2018-04-25 15:03:13 -0400)
sun41: Fix regression for TBSA711 tablet (Ondrej)
qxl: 2 bug fixes (Gerd)
core: Don't use stale display info between HDMI hotplugs (Ville)
virtio: Fix guest spinning when request queue is full (Gerd)
Cc: Ondrej Jirman
Cc: Gerd Hoffmann
Cc: Ville Syrjälä
Gerd Hoffmann (3):
qxl: fix qxl_release_{map,unmap}
qxl: keep separate release_bo pointer
drm/virtio: fix vq wait_event condition
Ondrej Jirman (1):
Revert "drm/sun4i: add lvds mode_valid function"
Ville Syrjälä (1):
drm/edid: Reset more of the display info
drivers/gpu/drm/drm_edid.c | 11 ++--
drivers/gpu/drm/qxl/qxl_cmd.c | 6 ++--
drivers/gpu/drm/qxl/qxl_drv.h | 1 +
drivers/gpu/drm/qxl/qxl_ioctl.c | 4 +--
drivers/gpu/drm/qxl/qxl_release.c | 18 ++--
drivers/gpu/drm/sun4i/sun4i_lvds.c | 55 -
drivers/gpu/drm/virtio/virtgpu_vq.c | 4 +--
7 files changed, 19 insertions(+), 80 deletions(-)
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/4] drm/i915/psr/skl+: Print information about what caused a PSR exit
On Tue, 2018-04-24 at 16:47 -0700, Dhinakaran Pandiyan wrote:
>
>
> On Fri, 2018-04-20 at 15:27 -0700, José Roberto de Souza wrote:
> > This will be helpful to debug what hardware is actually tracking
> > and causing PSR to exit.
> >
> > BSpec: 7721
> >
> > Signed-off-by: José Roberto de Souza
> > Cc: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
> > ---
> >
> > New patch in this series.
> >
> > drivers/gpu/drm/i915/i915_reg.h | 23
> > drivers/gpu/drm/i915/intel_psr.c | 45
> >
> > 2 files changed, 68 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 2dad655a710c..073b4502b30a 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4095,6 +4095,29 @@ enum {
> > #define EDP_PSR2_IDLE_FRAME_MASK 0xf
> > #define EDP_PSR2_IDLE_FRAME_SHIFT0
> >
> > +#define _PSR_EVENT_TRANS_A 0x60848
> > +#define _PSR_EVENT_TRANS_B 0x61848
> > +#define _PSR_EVENT_TRANS_C 0x62848
> > +#define _PSR_EVENT_TRANS_D 0x63848
> > +#define _PSR_EVENT_TRANS_EDP 0x6F848
> > +#define PSR_EVENT(trans) (trans ==
> > TRANSCODER_EDP ? _MMIO(_PSR_EVENT_TRANS_EDP) : _MMIO_PORT(trans,
> > _PSR_EVENT_TRANS_A, _PSR_EVENT_TRANS_B))
>
> You get this for free using _MMIO_TRANS2(), see TRANS_DDI_FUNC_CTL
Oh nice, thanks
>
> > +#define PSR_EVENT_PSR2_WD_TIMER_EXPIRE(1 << 17)
> > +#define PSR_EVENT_PSR2_DISABLED (1 << 16)
> > +#define PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN (1 << 15)
> > +#define PSR_EVENT_SU_CRC_FIFO_UNDERRUN(1 << 14)
> > +#define PSR_EVENT_GRAPHICS_RESET (1 << 12)
> > +#define PSR_EVENT_PCH_INTERRUPT (1 << 11)
> > +#define PSR_EVENT_MEMORY_UP (1 << 10)
> > +#define PSR_EVENT_FRONT_BUFFER_MODIFY (1 << 9)
> > +#define PSR_EVENT_WD_TIMER_EXPIRE (1 << 8)
> > +#define PSR_EVENT_PIPE_REGISTERS_UPDATE (1 << 6)
> > +#define PSR_EVENT_REGISTER_UPDATE (1 << 5)
> > +#define PSR_EVENT_HDCP_ENABLE (1 << 4)
> > +#define PSR_EVENT_KVMR_SESSION_ENABLE (1 << 3)
> > +#define PSR_EVENT_VBI_ENABLE (1 << 2)
> > +#define PSR_EVENT_LPSP_MODE_EXIT (1 << 1)
> > +#define PSR_EVENT_PSR_DISABLE (1 << 0)
> > +
> > #define EDP_PSR2_STATUS_MMIO(0x6f940)
> > #define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
> > #define EDP_PSR2_STATUS_STATE_SHIFT28
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 0d548292dd09..0938df48107a 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -125,6 +125,43 @@ void intel_psr_irq_control(struct
> > drm_i915_private *dev_priv, bool debug)
> > I915_WRITE(EDP_PSR_IMR, ~mask);
> > }
> >
> > +static void psr_event_print(u32 val, bool psr2_enabled)
>
> Is psr2_enabled needed? Do the bits get set incorrectly?
Yes, when PSR is enabled the PSR_EVENT_PSR2_DISABLED bit always set the
same happens with PSR_EVENT_PSR_DISABLE when PSR2 is enabled.
>
> > +{
> > + DRM_DEBUG_KMS("PSR exit causes: 0x%x\n", val);
>
> How about s/causes/events ?
Okay
> > + if (val & PSR_EVENT_PSR2_WD_TIMER_EXPIRE)
> > + DRM_DEBUG_KMS("\tPSR2 watchdog timer expired\n");
> > + if ((val & PSR_EVENT_PSR2_DISABLED) && psr2_enabled)
> > + DRM_DEBUG_KMS("\tPSR2 disabled\n");
> > + if (val & PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN)
> > + DRM_DEBUG_KMS("\tSU dirty FIFO underrun\n");
> > + if (val & PSR_EVENT_SU_CRC_FIFO_UNDERRUN)
> > + DRM_DEBUG_KMS("\tSU CRC FIFO underrun\n");
> > + if (val & PSR_EVENT_GRAPHICS_RESET)
> > + DRM_DEBUG_KMS("\tGraphics reset\n");
> > + if (val & PSR_EVENT_PCH_INTERRUPT)
> > + DRM_DEBUG_KMS("\tPCH interrupt\n");
> > + if (val & PSR_EVENT_MEMORY_UP)
> > + DRM_DEBUG_KMS("\tMemory up\n");
> > + if (val & PSR_EVENT_FRONT_BUFFER_MODIFY)
> > + DRM_DEBUG_KMS("\tFront buffer modification\n");
> > + if (val & PSR_EVENT_WD_TIMER_EXPIRE)
> > + DRM_DEBUG_KMS("\tPSR watchdog timer expired\n");
> > + if (val & PSR_EVENT_PIPE_REGISTERS_UPDATE)
> > + DRM_DEBUG_KMS("\tPIPE registers updated\n");
> > + if (val & PSR_EVENT_REGISTER_UPDATE)
> > + DRM_DEBUG_KMS("\tRegister updated\n");
> > + if (val & PSR_EVENT_HDCP_ENABLE)
> > + DRM_DEBUG_KMS("\tHDCP enabled\n");
> > + if (val & PSR_EVENT_KVMR_SESSION_ENABLE)
> > + DRM_DEBUG_KMS("\tKVMR session enabled\n");
> > + if (val & PSR_EVENT_VBI_ENABLE)
> > + DRM_DEBUG_KMS("\tVBI enabled\n");
> > + if (val & PSR_EVENT_LPSP_MODE_EXIT)
> > + DRM_DEBUG_KMS("\tLPSP mode exited\n");
> > + if ((val & PSR_EVENT_PSR_DISABLE) && !psr2_enabled)
> > +
Re: [Intel-gfx] [PATCH v3 3/4] drm/i915/debugfs: Print sink PSR status
On Tue, 2018-04-24 at 17:18 -0700, Dhinakaran Pandiyan wrote:
>
>
> On Fri, 2018-04-20 at 15:27 -0700, José Roberto de Souza wrote:
> > IGT tests could be improved with sink status, knowing for sure that
> > hardware have activate or exit PSR.
> >
> > Reviewed-by: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
> > Signed-off-by: José Roberto de Souza
> > ---
> >
> > No changes since v2, Dhinakaran asked to not merge this patch in v2
> > because reading i915_edp_psr_status was causing PSR to exit but now
> > with 'drm/i915/psr: Prevent PSR exit when a non-pipe related
> > register
> > is written' it is fixed.
> >
>
> Do you mind adding "reading i915_edp_psr_status was causing PSR to
> exit
> but now with 'drm/i915/psr: Prevent PSR exit when a non-pipe related
> register is written' it is fixed." to the commit message?
Done
>
>
>
> > drivers/gpu/drm/i915/i915_debugfs.c | 29
> > +
> > 1 file changed, 29 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 2f05f5262bba..536d93322451 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2603,6 +2603,26 @@ static const char *psr2_live_status(u32 val)
> > return "unknown";
> > }
> >
> > +static const char *psr_sink_status(u8 val)
> > +{
> > + static const char * const sink_status[] = {
> > + "inactive",
> > + "transition to active, capture and display",
> > + "active, display from RFB",
> > + "active, capture and display on sink device
> > timings",
> > + "transition to inactive, capture and display,
> > timing re-sync",
> > + "reserved",
> > + "reserved",
> > + "sink internal error"
> > + };
> > +
> > + val &= DP_PSR_SINK_STATE_MASK;
> > + if (val < ARRAY_SIZE(sink_status))
> > + return sink_status[val];
> > +
> > + return "unknown";
> > +}
> > +
> > static int i915_edp_psr_status(struct seq_file *m, void *data)
> > {
> > struct drm_i915_private *dev_priv = node_to_i915(m-
> > >private);
> > @@ -2684,6 +2704,15 @@ static int i915_edp_psr_status(struct
> > seq_file *m, void *data)
> > seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
> >psr2, psr2_live_status(psr2));
> > }
> > +
> > + if (dev_priv->psr.enabled) {
> > + struct drm_dp_aux *aux = &dev_priv->psr.enabled-
> > >aux;
> > + u8 val;
> > +
> > + if (drm_dp_dpcd_readb(aux, DP_PSR_STATUS, &val) ==
> > 1)
> > + seq_printf(m, "Sink PSR status: 0x%x
> > [%s]\n", val,
> > + psr_sink_status(val));
> > + }
> > mutex_unlock(&dev_priv->psr.lock);
> >
> > if (READ_ONCE(dev_priv->psr.debug)) {
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/4] drm/i915/psr: Prevent PSR exit when a non-pipe related register is written
On Tue, 2018-04-24 at 17:16 -0700, Dhinakaran Pandiyan wrote: > > > On Tue, 2018-04-24 at 14:20 -0700, Rodrigo Vivi wrote: > > On Mon, Apr 23, 2018 at 05:42:40PM -0700, Souza, Jose wrote: > > > On Fri, 2018-04-20 at 15:57 -0700, Rodrigo Vivi wrote: > > > > On Fri, Apr 20, 2018 at 03:27:56PM -0700, José Roberto de Souza > > > > wrote: > > > > > Any write in any display register was causing HW to exit PSR, > > > > > masking it to allow more power savings. Writes to pipe > > > > > related > > > > > registers will still cause HW to exit PSR. > > > > > This is already masked for PSR2. > > > > > > > > This seems a good idea indeed with the test case on > > > > perspective. > > > > > > what test cases are thinking? the current ones already do pages > > > flips > > > that will only touch the pipe related registers. > > > > > > > > > > > But it needs more tests to make sure it doesn't break > > > > "Display WA #0884: all" > > > > > > I just tested the WA #0884 and it still causes PSR to exit. I > > > have > > > added a new debugfs that when read it writes to > > > 'I915_WRITE(CURSURFLIVE(pipe), 0);' causing a PSR exit. > > > > Interesting. Thanks a lot for checking this. > > I guess we are safe then. DK?! > > > > Not sure why it works though, let's give it a try. > > It might be worth adding more information about test platform and how > was this was tested in the commit message. Since this is not clearly > documented in bspec, someone is going read this in a few months and > think the code does not make any sense. > > Reviewed-by: Dhinakaran Pandiyan Done > > > > > > > > > > > > > Or we might need to revert that patch before moving with this > > > > idea. > > > > > > > > > > > > > > Bspec: 7721 and 8042 > > > > > > > > > > Cc: Rodrigo Vivi > > > > > Cc: Dhinakaran Pandiyan > > > > > Signed-off-by: José Roberto de Souza > > > > > --- > > > > > > > > > > New patch in this series. > > > > > > > > > > drivers/gpu/drm/i915/intel_psr.c | 3 ++- > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c > > > > > b/drivers/gpu/drm/i915/intel_psr.c > > > > > index 0938df48107a..c907282dc82d 100644 > > > > > --- a/drivers/gpu/drm/i915/intel_psr.c > > > > > +++ b/drivers/gpu/drm/i915/intel_psr.c > > > > > @@ -712,7 +712,8 @@ static void hsw_psr_enable_source(struct > > > > > intel_dp *intel_dp, > > > > > I915_WRITE(EDP_PSR_DEBUG, > > > > > EDP_PSR_DEBUG_MASK_MEMUP | > > > > > EDP_PSR_DEBUG_MASK_HPD | > > > > > -EDP_PSR_DEBUG_MASK_LPSP); > > > > > +EDP_PSR_DEBUG_MASK_LPSP | > > > > > +EDP_PSR_DEBUG_MASK_DISP_REG_WRITE > > > > > ); > > > > > } > > > > > } > > > > > > > > > > -- > > > > > 2.17.0 > > > > > > > > > ___ > > 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 2/3] drm/i915/icl: Enable 2nd DBuf slice only when needed
On Thu, Apr 05, 2018 at 11:30:18AM +0530, Mahesh Kumar wrote:
> ICL has two slices of DBuf, each slice of size 1024 blocks.
> We should not always enable slice-2. It should be enabled only if
> display total required BW is > 12GBps OR more than 1 pipes are enabled.
>
> Changes since V1:
> - typecast total_data_rate to u64 before multiplication to solve any
>possible overflow (Rodrigo)
> - fix where skl_wm_get_hw_state was memsetting ddb, resulting
>enabled_slices to become zero
> - Fix the logic of calculating ddb_size
> Changes since V2:
> - If no-crtc is part of commit required_slices will have value "0",
>don't try to disable DBuf slice.
> Changes since V3:
> - Create a generic helper to enable/disable slice
> - don't return early if total_data_rate is 0, it may be cursor only
>commit, or atomic modeset without any plane.
>
> Signed-off-by: Mahesh Kumar
> ---
> drivers/gpu/drm/i915/intel_display.c| 10 +
> drivers/gpu/drm/i915/intel_drv.h| 6 +++
> drivers/gpu/drm/i915/intel_pm.c | 57 +++--
> drivers/gpu/drm/i915/intel_runtime_pm.c | 65
> ++---
> 4 files changed, 113 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 96a1e6a7f69e..bc795307657a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12196,6 +12196,8 @@ static void skl_update_crtcs(struct drm_atomic_state
> *state)
> bool progress;
> enum pipe pipe;
> int i;
> + uint8_t hw_enabled_slices = dev_priv->wm.skl_hw.ddb.enabled_slices;
> + uint8_t required_slices = intel_state->wm_results.ddb.enabled_slices;
in many parts this enabled_slices meaning required or calculated confused me a
bit,
but I don't have better suggestion and the code seems right:
Reviewed-by: Rodrigo Vivi
>
> const struct skl_ddb_entry *entries[I915_MAX_PIPES] = {};
>
> @@ -12204,6 +12206,10 @@ static void skl_update_crtcs(struct drm_atomic_state
> *state)
> if (new_crtc_state->active)
> entries[i] =
> &to_intel_crtc_state(old_crtc_state)->wm.skl.ddb;
>
> + /* If 2nd DBuf slice required, enable it here */
> + if (INTEL_GEN(dev_priv) >= 11 && required_slices > hw_enabled_slices)
> + icl_dbuf_slices_update(dev_priv, required_slices);
> +
> /*
>* Whenever the number of active pipes changes, we need to make sure we
>* update the pipes in the right order so that their ddb allocations
> @@ -12254,6 +12260,10 @@ static void skl_update_crtcs(struct drm_atomic_state
> *state)
> progress = true;
> }
> } while (progress);
> +
> + /* If 2nd DBuf slice is no more required disable it */
> + if (INTEL_GEN(dev_priv) >= 11 && required_slices < hw_enabled_slices)
> + icl_dbuf_slices_update(dev_priv, required_slices);
> }
>
> static void intel_atomic_helper_free_state(struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index d1452fd2a58d..473a1ad7f32b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -140,6 +140,10 @@
> #define KHz(x) (1000 * (x))
> #define MHz(x) KHz(1000 * (x))
>
> +#define KBps(x) (1000 * (x))
> +#define MBps(x) KBps(1000 * (x))
> +#define GBps(x) ((uint64_t) 1000 * MBps((x)))
> +
> /*
> * Display related stuff
> */
> @@ -1914,6 +1918,8 @@ bool intel_display_power_get_if_enabled(struct
> drm_i915_private *dev_priv,
> enum intel_display_power_domain domain);
> void intel_display_power_put(struct drm_i915_private *dev_priv,
>enum intel_display_power_domain domain);
> +void icl_dbuf_slices_update(struct drm_i915_private *dev_priv,
> + uint8_t req_slices);
>
> static inline void
> assert_rpm_device_not_suspended(struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 3ff37d5ba353..caa29f949335 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3771,9 +3771,42 @@ bool intel_can_enable_sagv(struct drm_atomic_state
> *state)
> return true;
> }
>
> +static unsigned int intel_get_ddb_size(struct drm_i915_private *dev_priv,
> +const struct intel_crtc_state *cstate,
> +const unsigned int total_data_rate,
> +const int num_active,
> +struct skl_ddb_allocation *ddb)
> +{
> + const struct drm_display_mode *adjusted_mode;
> + u64 total_data_bw;
> + u16 ddb_size = INTEL_INFO(dev_priv)->ddb_size;
> +
> + WARN_ON(ddb_size == 0);
> +
> + if (INTEL_GEN(dev_priv) < 11)
> +
Re: [Intel-gfx] [PATCH v2 6/9] drm/i915/psr/bdw+: Enable CRC check in the static frame on the sink side
On Fri, 2018-04-20 at 14:16 -0700, Rodrigo Vivi wrote:
> On Wed, Apr 18, 2018 at 03:43:08PM -0700, José Roberto de Souza
> wrote:
> > Sink can be configured to calculate the CRC over the static frame
> > and
> > compare with the CRC calculated and transmited in the VSC SDP by
> > source, if there is a mismatch sink will do a short pulse in HPD
> > and set DP_PSR_LINK_CRC_ERROR on DP_PSR_ERROR_STATUS.
>
> good idea, but first we need to stop using sink crc for the tests :(
We do the sink crc tests to check if PSR really exited and the screen
was updated with the new frame right? I don't see how this would cause
any problems.
>
> and make sure the interrupts are being handled correct...
>
> (I was going to mention an extra requirement that was to make sure
> that you implement the needed Wa, but I noticed you already took care
> of this)
>
> >
> > Also spec recommends to disable MAX_SLEEP as a trigger to exit PSR
> > when
> > CRC check is enabled to improve power savings.
>
> my first impression was that this should be a separated patch
> in case we needed to revert it doesn't revert both functionalities...
>
> however I saw this was Display WA #0388 with a mention:
> "This becomes standard required programming for all subsequent
> projects."
>
> so yeah, it belongs here. Maybe good to at least referrence this wa
> number.
I will add this.
>
> >
> > Spec: 7723
> >
> > Signed-off-by: José Roberto de Souza
> > Cc: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
> > ---
> >
> > Changes from v1:
> > - printing a debug message when sink assert a error
> >
> > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > drivers/gpu/drm/i915/intel_psr.c | 24 +---
> > 2 files changed, 18 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index fb106026a1f4..d3efbd654889 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4016,6 +4016,7 @@ enum {
> > #define EDP_PSR_SKIP_AUX_EXIT(1<<12)
> > #define EDP_PSR_TP1_TP2_SEL (0<<11)
> > #define EDP_PSR_TP1_TP3_SEL (1<<11)
> > +#define EDP_PSR_CRC_ENABLE (1<<10) /*
> > BDW+ */
> > #define EDP_PSR_TP2_TP3_TIME_500us (0<<8)
> > #define EDP_PSR_TP2_TP3_TIME_100us (1<<8)
> > #define EDP_PSR_TP2_TP3_TIME_2500us (2<<8)
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 558b08a43f9e..1920e7d03e06 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -290,6 +290,8 @@ static void hsw_psr_enable_sink(struct intel_dp
> > *intel_dp)
> > dpcd_val |= DP_PSR_ENABLE_PSR2;
> > if (dev_priv->psr.link_standby)
> > dpcd_val |= DP_PSR_MAIN_LINK_ACTIVE;
> > + if (!dev_priv->psr.psr2_enabled && INTEL_GEN(dev_priv) >=
> > 8)
> > + dpcd_val |= DP_PSR_CRC_VERIFICATION;
> > drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG,
> > dpcd_val);
> >
> > drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER,
> > DP_SET_POWER_D0);
> > @@ -377,6 +379,9 @@ static void hsw_activate_psr1(struct intel_dp
> > *intel_dp)
> > else
> > val |= EDP_PSR_TP1_TP2_SEL;
> >
> > + if (INTEL_GEN(dev_priv) >= 8)
> > + val |= EDP_PSR_CRC_ENABLE;
> > +
> > val |= I915_READ(EDP_PSR_CTL) &
> > EDP_PSR_RESTORE_PSR_ACTIVE_CTX_MASK;
> > I915_WRITE(EDP_PSR_CTL, val);
> > }
> > @@ -602,10 +607,12 @@ static void hsw_psr_enable_source(struct
> > intel_dp *intel_dp,
> > * preventing other hw tracking issues now we can
> > rely
> > * on frontbuffer tracking.
> > */
> > - I915_WRITE(EDP_PSR_DEBUG,
> > - EDP_PSR_DEBUG_MASK_MEMUP |
> > - EDP_PSR_DEBUG_MASK_HPD |
> > - EDP_PSR_DEBUG_MASK_LPSP);
> > + u32 val = EDP_PSR_DEBUG_MASK_MEMUP |
> > EDP_PSR_DEBUG_MASK_HPD
> > + | EDP_PSR_DEBUG_MASK_LPSP;
> > +
> > + if (INTEL_GEN(dev_priv) >= 8)
> > + val |= EDP_PSR_DEBUG_MASK_MAX_SLEEP;
> > + I915_WRITE(EDP_PSR_DEBUG, val);
> > }
> > }
> >
> > @@ -1161,14 +1168,17 @@ void
> > intel_psr_hpd_short_pulse_handle(struct intel_dp *intel_dp)
> > goto dpcd_error;
> > }
> >
> > - if (val & DP_PSR_RFB_STORAGE_ERROR) {
> > - DRM_DEBUG_KMS("PSR RFB storage error, exiting
> > PSR\n");
> > + if (val & (DP_PSR_RFB_STORAGE_ERROR |
> > DP_PSR_LINK_CRC_ERROR)) {
> > + if (val & DP_PSR_RFB_STORAGE_ERROR)
> > + DRM_DEBUG_KMS("PSR RFB storage error,
> > exiting PSR\n");
> > + if (val & DP_PSR_LINK_CRC_ERROR)
> > + DRM_DEBUG_KMS("PSR Link CRC error, exiting
> > PSR\n");
> > intel_psr_exit(dev_priv);
> > }
> > /* clear status regist
Re: [Intel-gfx] [PATCH 3/3] drm/i915/icl: update ddb entry start/end mask during hw ddb readout
On Thu, Apr 05, 2018 at 11:30:19AM +0530, Mahesh Kumar wrote:
> Gen11/ICL onward ddb entry start/end mask is increased from 10 bits to
> 11 bits. This patch make changes to use proper mask for ICL+ during
> hardware ddb value readout.
>
> Changes since V1:
> - Use _MASK & _SHIFT macro (James)
>
> Signed-off-by: Mahesh Kumar
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> drivers/gpu/drm/i915/intel_pm.c | 18 ++
> 2 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 176dca6554f4..e3a6c535617d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6459,6 +6459,9 @@ enum {
>
> #define _PLANE_BUF_CFG_1_B 0x7127c
> #define _PLANE_BUF_CFG_2_B 0x7137c
> +#define SKL_DDB_ENTRY_MASK 0x3FF
> +#define ICL_DDB_ENTRY_MASK 0x7FF
> +#define DDB_ENTRY_END_SHIFT 16
> #define _PLANE_BUF_CFG_1(pipe) \
> _PIPE(pipe, _PLANE_BUF_CFG_1_A, _PLANE_BUF_CFG_1_B)
> #define _PLANE_BUF_CFG_2(pipe) \
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index caa29f949335..98e91f4a5ab4 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3864,10 +3864,18 @@ static unsigned int skl_cursor_allocation(int
> num_active)
> return 8;
> }
>
> -static void skl_ddb_entry_init_from_hw(struct skl_ddb_entry *entry, u32 reg)
> +static void skl_ddb_entry_init_from_hw(struct drm_i915_private *dev_priv,
> +struct skl_ddb_entry *entry, u32 reg)
> {
> - entry->start = reg & 0x3ff;
> - entry->end = (reg >> 16) & 0x3ff;
> + uint16_t mask;
> +
> + if (INTEL_GEN(dev_priv) >= 11)
> + mask = ICL_DDB_ENTRY_MASK;
> + else
> + mask = SKL_DDB_ENTRY_MASK;
> + entry->start = reg & mask;
> + entry->end = (reg >> DDB_ENTRY_END_SHIFT) & mask;
> +
> if (entry->end)
> entry->end += 1;
> }
> @@ -3898,7 +3906,9 @@ void skl_ddb_get_hw_state(struct drm_i915_private
> *dev_priv,
> else
> val = I915_READ(CUR_BUF_CFG(pipe));
>
> - skl_ddb_entry_init_from_hw(&ddb->plane[pipe][plane_id],
> val);
> + skl_ddb_entry_init_from_hw(dev_priv,
> +&ddb->plane[pipe][plane_id],
> +val);
> }
>
> intel_display_power_put(dev_priv, power_domain);
> --
> 2.16.2
>
> ___
> 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] [PATCH 4/4] drm/i915/psr/cnl: Set y-coordinate as valid in SDP
This was my bad, spec says that the name of this bit is
'Y-coordinate valid' but the values for it is:
0: Include Y-coordinate valid eDP1.4a
1: Do not include Y-coordinate valid eDP 1.4
So not setting it.
BSpec: 7713
Cc: Rodrigo Vivi
Reviewed-by: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_psr.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index c8d5cdce544f..6233a322aac5 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -508,9 +508,8 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
* mesh at all with our frontbuffer tracking. And the hw alone isn't
* good enough. */
val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
- if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
- val |= EDP_Y_COORDINATE_VALID | EDP_Y_COORDINATE_ENABLE;
- }
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
+ val |= EDP_Y_COORDINATE_ENABLE;
val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv->psr.sink_sync_latency + 1);
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915/psr: Prevent PSR exit when a non-pipe related register is written
Any write in any display register was causing HW to exit PSR, masking it to allow more power savings. Writes to pipe related registers will still cause HW to exit PSR. This is already masked for PSR2. It also do not break the Display WA #0884, writes to CURSURFLIVE are still causing hardware to exit PSR. This was tested in CNL machine by triggering a write to CURSURFLIVE when a debugfs was read by user. Bspec: 7721 and 8042 v4: Checked that it do not breaks WA #0884 and added this information to the commit message. Cc: Rodrigo Vivi Reviewed-by: Dhinakaran Pandiyan Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/intel_psr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 0d548292dd09..e35a3b94fa69 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -667,7 +667,8 @@ static void hsw_psr_enable_source(struct intel_dp *intel_dp, I915_WRITE(EDP_PSR_DEBUG, EDP_PSR_DEBUG_MASK_MEMUP | EDP_PSR_DEBUG_MASK_HPD | - EDP_PSR_DEBUG_MASK_LPSP); + EDP_PSR_DEBUG_MASK_LPSP | + EDP_PSR_DEBUG_MASK_DISP_REG_WRITE); } } -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/psr/skl+: Print information about what caused a PSR exit
This will be helpful to debug what hardware is actually tracking
and causing PSR to exit.
BSpec: 7721
v4:
- Using _MMIO_TRANS2() in PSR_EVENT
- Cleaning events before printing
Signed-off-by: José Roberto de Souza
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_reg.h | 23
drivers/gpu/drm/i915/intel_psr.c | 45
2 files changed, 68 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2dad655a710c..391825ae2361 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4095,6 +4095,29 @@ enum {
#define EDP_PSR2_IDLE_FRAME_MASK 0xf
#define EDP_PSR2_IDLE_FRAME_SHIFT0
+#define _PSR_EVENT_TRANS_A 0x60848
+#define _PSR_EVENT_TRANS_B 0x61848
+#define _PSR_EVENT_TRANS_C 0x62848
+#define _PSR_EVENT_TRANS_D 0x63848
+#define _PSR_EVENT_TRANS_EDP 0x6F848
+#define PSR_EVENT(trans) _MMIO_TRANS2(trans,
_PSR_EVENT_TRANS_A)
+#define PSR_EVENT_PSR2_WD_TIMER_EXPIRE(1 << 17)
+#define PSR_EVENT_PSR2_DISABLED (1 << 16)
+#define PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN (1 << 15)
+#define PSR_EVENT_SU_CRC_FIFO_UNDERRUN(1 << 14)
+#define PSR_EVENT_GRAPHICS_RESET (1 << 12)
+#define PSR_EVENT_PCH_INTERRUPT (1 << 11)
+#define PSR_EVENT_MEMORY_UP (1 << 10)
+#define PSR_EVENT_FRONT_BUFFER_MODIFY (1 << 9)
+#define PSR_EVENT_WD_TIMER_EXPIRE (1 << 8)
+#define PSR_EVENT_PIPE_REGISTERS_UPDATE (1 << 6)
+#define PSR_EVENT_REGISTER_UPDATE (1 << 5)
+#define PSR_EVENT_HDCP_ENABLE (1 << 4)
+#define PSR_EVENT_KVMR_SESSION_ENABLE (1 << 3)
+#define PSR_EVENT_VBI_ENABLE (1 << 2)
+#define PSR_EVENT_LPSP_MODE_EXIT (1 << 1)
+#define PSR_EVENT_PSR_DISABLE (1 << 0)
+
#define EDP_PSR2_STATUS_MMIO(0x6f940)
#define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
#define EDP_PSR2_STATUS_STATE_SHIFT28
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index e35a3b94fa69..c8d5cdce544f 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -125,6 +125,43 @@ void intel_psr_irq_control(struct drm_i915_private
*dev_priv, bool debug)
I915_WRITE(EDP_PSR_IMR, ~mask);
}
+static void psr_event_print(u32 val, bool psr2_enabled)
+{
+ DRM_DEBUG_KMS("PSR exit events: 0x%x\n", val);
+ if (val & PSR_EVENT_PSR2_WD_TIMER_EXPIRE)
+ DRM_DEBUG_KMS("\tPSR2 watchdog timer expired\n");
+ if ((val & PSR_EVENT_PSR2_DISABLED) && psr2_enabled)
+ DRM_DEBUG_KMS("\tPSR2 disabled\n");
+ if (val & PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN)
+ DRM_DEBUG_KMS("\tSU dirty FIFO underrun\n");
+ if (val & PSR_EVENT_SU_CRC_FIFO_UNDERRUN)
+ DRM_DEBUG_KMS("\tSU CRC FIFO underrun\n");
+ if (val & PSR_EVENT_GRAPHICS_RESET)
+ DRM_DEBUG_KMS("\tGraphics reset\n");
+ if (val & PSR_EVENT_PCH_INTERRUPT)
+ DRM_DEBUG_KMS("\tPCH interrupt\n");
+ if (val & PSR_EVENT_MEMORY_UP)
+ DRM_DEBUG_KMS("\tMemory up\n");
+ if (val & PSR_EVENT_FRONT_BUFFER_MODIFY)
+ DRM_DEBUG_KMS("\tFront buffer modification\n");
+ if (val & PSR_EVENT_WD_TIMER_EXPIRE)
+ DRM_DEBUG_KMS("\tPSR watchdog timer expired\n");
+ if (val & PSR_EVENT_PIPE_REGISTERS_UPDATE)
+ DRM_DEBUG_KMS("\tPIPE registers updated\n");
+ if (val & PSR_EVENT_REGISTER_UPDATE)
+ DRM_DEBUG_KMS("\tRegister updated\n");
+ if (val & PSR_EVENT_HDCP_ENABLE)
+ DRM_DEBUG_KMS("\tHDCP enabled\n");
+ if (val & PSR_EVENT_KVMR_SESSION_ENABLE)
+ DRM_DEBUG_KMS("\tKVMR session enabled\n");
+ if (val & PSR_EVENT_VBI_ENABLE)
+ DRM_DEBUG_KMS("\tVBI enabled\n");
+ if (val & PSR_EVENT_LPSP_MODE_EXIT)
+ DRM_DEBUG_KMS("\tLPSP mode exited\n");
+ if ((val & PSR_EVENT_PSR_DISABLE) && !psr2_enabled)
+ DRM_DEBUG_KMS("\tPSR disabled\n");
+}
+
void intel_psr_irq_handler(struct drm_i915_private *dev_priv, u32 psr_iir)
{
u32 transcoders = BIT(TRANSCODER_EDP);
@@ -152,6 +189,14 @@ void intel_psr_irq_handler(struct drm_i915_private
*dev_priv, u32 psr_iir)
dev_priv->psr.last_exit = time_ns;
DRM_DEBUG_KMS("[transcoder %s] PSR exit completed\n",
transcoder_name(cpu_transcoder));
+
+ if (INTEL_GEN(dev_priv) >= 9) {
+ u32 val = I915_READ(PSR_EVENT(cpu_transcoder));
+ bool psr2_enabled = dev_priv->psr.psr2_enabled;
+
+
[Intel-gfx] [PATCH 3/4] drm/i915/debugfs: Print sink PSR status
IGT tests could be improved with sink status, knowing for sure that
hardware have activate or exit PSR.
v3:
Reading i915_edp_psr_status was causing PSR to exit but now with
'drm/i915/psr: Prevent PSR exit when a non-pipe related register is
written' it is fixed.
Reviewed-by: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_debugfs.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1c88805d3354..cb1a804bf72e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2603,6 +2603,26 @@ static const char *psr2_live_status(u32 val)
return "unknown";
}
+static const char *psr_sink_status(u8 val)
+{
+ static const char * const sink_status[] = {
+ "inactive",
+ "transition to active, capture and display",
+ "active, display from RFB",
+ "active, capture and display on sink device timings",
+ "transition to inactive, capture and display, timing re-sync",
+ "reserved",
+ "reserved",
+ "sink internal error"
+ };
+
+ val &= DP_PSR_SINK_STATE_MASK;
+ if (val < ARRAY_SIZE(sink_status))
+ return sink_status[val];
+
+ return "unknown";
+}
+
static int i915_edp_psr_status(struct seq_file *m, void *data)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -2684,6 +2704,15 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
psr2, psr2_live_status(psr2));
}
+
+ if (dev_priv->psr.enabled) {
+ struct drm_dp_aux *aux = &dev_priv->psr.enabled->aux;
+ u8 val;
+
+ if (drm_dp_dpcd_readb(aux, DP_PSR_STATUS, &val) == 1)
+ seq_printf(m, "Sink PSR status: 0x%x [%s]\n", val,
+ psr_sink_status(val));
+ }
mutex_unlock(&dev_priv->psr.lock);
if (READ_ONCE(dev_priv->psr.debug)) {
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/psr/skl+: Print information about what caused a PSR exit
On Wed, Apr 25, 2018 at 02:23:32PM -0700, José Roberto de Souza wrote:
> This will be helpful to debug what hardware is actually tracking
> and causing PSR to exit.
>
> BSpec: 7721
>
> v4:
> - Using _MMIO_TRANS2() in PSR_EVENT
> - Cleaning events before printing
>
> Signed-off-by: José Roberto de Souza
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_reg.h | 23
> drivers/gpu/drm/i915/intel_psr.c | 45
> 2 files changed, 68 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2dad655a710c..391825ae2361 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4095,6 +4095,29 @@ enum {
> #define EDP_PSR2_IDLE_FRAME_MASK 0xf
> #define EDP_PSR2_IDLE_FRAME_SHIFT 0
>
> +#define _PSR_EVENT_TRANS_A 0x60848
> +#define _PSR_EVENT_TRANS_B 0x61848
> +#define _PSR_EVENT_TRANS_C 0x62848
> +#define _PSR_EVENT_TRANS_D 0x63848
> +#define _PSR_EVENT_TRANS_EDP 0x6F848
> +#define PSR_EVENT(trans) _MMIO_TRANS2(trans,
> _PSR_EVENT_TRANS_A)
> +#define PSR_EVENT_PSR2_WD_TIMER_EXPIRE (1 << 17)
> +#define PSR_EVENT_PSR2_DISABLED (1 << 16)
> +#define PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN(1 << 15)
> +#define PSR_EVENT_SU_CRC_FIFO_UNDERRUN (1 << 14)
> +#define PSR_EVENT_GRAPHICS_RESET(1 << 12)
> +#define PSR_EVENT_PCH_INTERRUPT (1 << 11)
> +#define PSR_EVENT_MEMORY_UP (1 << 10)
> +#define PSR_EVENT_FRONT_BUFFER_MODIFY (1 << 9)
> +#define PSR_EVENT_WD_TIMER_EXPIRE (1 << 8)
> +#define PSR_EVENT_PIPE_REGISTERS_UPDATE (1 << 6)
> +#define PSR_EVENT_REGISTER_UPDATE (1 << 5)
> +#define PSR_EVENT_HDCP_ENABLE (1 << 4)
> +#define PSR_EVENT_KVMR_SESSION_ENABLE (1 << 3)
> +#define PSR_EVENT_VBI_ENABLE(1 << 2)
> +#define PSR_EVENT_LPSP_MODE_EXIT(1 << 1)
> +#define PSR_EVENT_PSR_DISABLE (1 << 0)
> +
> #define EDP_PSR2_STATUS _MMIO(0x6f940)
> #define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
> #define EDP_PSR2_STATUS_STATE_SHIFT28
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index e35a3b94fa69..c8d5cdce544f 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -125,6 +125,43 @@ void intel_psr_irq_control(struct drm_i915_private
> *dev_priv, bool debug)
> I915_WRITE(EDP_PSR_IMR, ~mask);
> }
>
> +static void psr_event_print(u32 val, bool psr2_enabled)
> +{
> + DRM_DEBUG_KMS("PSR exit events: 0x%x\n", val);
> + if (val & PSR_EVENT_PSR2_WD_TIMER_EXPIRE)
> + DRM_DEBUG_KMS("\tPSR2 watchdog timer expired\n");
> + if ((val & PSR_EVENT_PSR2_DISABLED) && psr2_enabled)
I'm not sure if we should add this extra psr2_enable check here.
Probably better to just print the bit reference and move one.
otherwise we might have the risk of having a message
"PSR exit events:"
followed by nothing below it
> + DRM_DEBUG_KMS("\tPSR2 disabled\n");
> + if (val & PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN)
> + DRM_DEBUG_KMS("\tSU dirty FIFO underrun\n");
> + if (val & PSR_EVENT_SU_CRC_FIFO_UNDERRUN)
> + DRM_DEBUG_KMS("\tSU CRC FIFO underrun\n");
> + if (val & PSR_EVENT_GRAPHICS_RESET)
> + DRM_DEBUG_KMS("\tGraphics reset\n");
> + if (val & PSR_EVENT_PCH_INTERRUPT)
> + DRM_DEBUG_KMS("\tPCH interrupt\n");
> + if (val & PSR_EVENT_MEMORY_UP)
> + DRM_DEBUG_KMS("\tMemory up\n");
> + if (val & PSR_EVENT_FRONT_BUFFER_MODIFY)
> + DRM_DEBUG_KMS("\tFront buffer modification\n");
> + if (val & PSR_EVENT_WD_TIMER_EXPIRE)
> + DRM_DEBUG_KMS("\tPSR watchdog timer expired\n");
> + if (val & PSR_EVENT_PIPE_REGISTERS_UPDATE)
> + DRM_DEBUG_KMS("\tPIPE registers updated\n");
> + if (val & PSR_EVENT_REGISTER_UPDATE)
> + DRM_DEBUG_KMS("\tRegister updated\n");
> + if (val & PSR_EVENT_HDCP_ENABLE)
> + DRM_DEBUG_KMS("\tHDCP enabled\n");
> + if (val & PSR_EVENT_KVMR_SESSION_ENABLE)
> + DRM_DEBUG_KMS("\tKVMR session enabled\n");
> + if (val & PSR_EVENT_VBI_ENABLE)
> + DRM_DEBUG_KMS("\tVBI enabled\n");
> + if (val & PSR_EVENT_LPSP_MODE_EXIT)
> + DRM_DEBUG_KMS("\tLPSP mode exited\n");
> + if ((val & PSR_EVENT_PSR_DISABLE) && !psr2_enabled)
> + DRM_DEBUG_KMS("\tPSR disabled\n");
> +}
> +
> void intel_psr_irq_handler(struct drm_i915_private *dev_priv, u32 psr_iir)
> {
> u32 transcoders = BIT(TRANSCODER_EDP);
> @@ -152,6 +189,14 @@ void intel_psr_irq_handler(struct drm_i915_private
> *dev_priv, u32 psr_iir)
>
[Intel-gfx] ✗ Fi.CI.BAT: failure for Optimize use of DBuf slices (rev2)
== Series Details == Series: Optimize use of DBuf slices (rev2) URL : https://patchwork.freedesktop.org/series/41180/ State : failure == Summary == Applying: drm/i915/icl: track dbuf slice-2 status error: Failed to merge in the changes. Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_drv.h M drivers/gpu/drm/i915/intel_display.c M drivers/gpu/drm/i915/intel_pm.c M drivers/gpu/drm/i915/intel_runtime_pm.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_runtime_pm.c Auto-merging drivers/gpu/drm/i915/intel_pm.c Auto-merging drivers/gpu/drm/i915/intel_display.c Auto-merging drivers/gpu/drm/i915/i915_drv.h CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_drv.h Patch failed at 0001 drm/i915/icl: track dbuf slice-2 status The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8588/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/psr/skl+: Print information about what caused a PSR exit
On Wed, 2018-04-25 at 14:40 -0700, Rodrigo Vivi wrote:
> On Wed, Apr 25, 2018 at 02:23:32PM -0700, José Roberto de Souza
> wrote:
> > This will be helpful to debug what hardware is actually tracking
> > and causing PSR to exit.
> >
> > BSpec: 7721
> >
> > v4:
> > - Using _MMIO_TRANS2() in PSR_EVENT
> > - Cleaning events before printing
> >
> > Signed-off-by: José Roberto de Souza
> > Cc: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 23
> > drivers/gpu/drm/i915/intel_psr.c | 45
> >
> > 2 files changed, 68 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 2dad655a710c..391825ae2361 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4095,6 +4095,29 @@ enum {
> > #define EDP_PSR2_IDLE_FRAME_MASK 0xf
> > #define EDP_PSR2_IDLE_FRAME_SHIFT0
> >
> > +#define _PSR_EVENT_TRANS_A 0x60848
> > +#define _PSR_EVENT_TRANS_B 0x61848
> > +#define _PSR_EVENT_TRANS_C 0x62848
> > +#define _PSR_EVENT_TRANS_D 0x63848
> > +#define _PSR_EVENT_TRANS_EDP 0x6F848
> > +#define PSR_EVENT(trans) _MMIO_TRANS2(trans
> > , _PSR_EVENT_TRANS_A)
> > +#define PSR_EVENT_PSR2_WD_TIMER_EXPIRE(1 << 17)
> > +#define PSR_EVENT_PSR2_DISABLED (1 << 16)
> > +#define PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN (1 << 15)
> > +#define PSR_EVENT_SU_CRC_FIFO_UNDERRUN(1 << 14)
> > +#define PSR_EVENT_GRAPHICS_RESET (1 << 12)
> > +#define PSR_EVENT_PCH_INTERRUPT (1 << 11)
> > +#define PSR_EVENT_MEMORY_UP (1 << 10)
> > +#define PSR_EVENT_FRONT_BUFFER_MODIFY (1 << 9)
> > +#define PSR_EVENT_WD_TIMER_EXPIRE (1 << 8)
> > +#define PSR_EVENT_PIPE_REGISTERS_UPDATE (1 << 6)
> > +#define PSR_EVENT_REGISTER_UPDATE (1 << 5)
> > +#define PSR_EVENT_HDCP_ENABLE (1 << 4)
> > +#define PSR_EVENT_KVMR_SESSION_ENABLE (1 << 3)
> > +#define PSR_EVENT_VBI_ENABLE (1 << 2)
> > +#define PSR_EVENT_LPSP_MODE_EXIT (1 << 1)
> > +#define PSR_EVENT_PSR_DISABLE (1 << 0)
> > +
> > #define EDP_PSR2_STATUS_MMIO(0x6f940)
> > #define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
> > #define EDP_PSR2_STATUS_STATE_SHIFT28
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index e35a3b94fa69..c8d5cdce544f 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -125,6 +125,43 @@ void intel_psr_irq_control(struct
> > drm_i915_private *dev_priv, bool debug)
> > I915_WRITE(EDP_PSR_IMR, ~mask);
> > }
> >
> > +static void psr_event_print(u32 val, bool psr2_enabled)
> > +{
> > + DRM_DEBUG_KMS("PSR exit events: 0x%x\n", val);
> > + if (val & PSR_EVENT_PSR2_WD_TIMER_EXPIRE)
> > + DRM_DEBUG_KMS("\tPSR2 watchdog timer expired\n");
> > + if ((val & PSR_EVENT_PSR2_DISABLED) && psr2_enabled)
>
> I'm not sure if we should add this extra psr2_enable check here.
> Probably better to just print the bit reference and move one.
>
> otherwise we might have the risk of having a message
> "PSR exit events:"
> followed by nothing below it
I'm okay with this too but I think is not necessary have 'PSR2
disabled' printed everytime when PSR is enabled.
>
> > + DRM_DEBUG_KMS("\tPSR2 disabled\n");
> > + if (val & PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN)
> > + DRM_DEBUG_KMS("\tSU dirty FIFO underrun\n");
> > + if (val & PSR_EVENT_SU_CRC_FIFO_UNDERRUN)
> > + DRM_DEBUG_KMS("\tSU CRC FIFO underrun\n");
> > + if (val & PSR_EVENT_GRAPHICS_RESET)
> > + DRM_DEBUG_KMS("\tGraphics reset\n");
> > + if (val & PSR_EVENT_PCH_INTERRUPT)
> > + DRM_DEBUG_KMS("\tPCH interrupt\n");
> > + if (val & PSR_EVENT_MEMORY_UP)
> > + DRM_DEBUG_KMS("\tMemory up\n");
> > + if (val & PSR_EVENT_FRONT_BUFFER_MODIFY)
> > + DRM_DEBUG_KMS("\tFront buffer modification\n");
> > + if (val & PSR_EVENT_WD_TIMER_EXPIRE)
> > + DRM_DEBUG_KMS("\tPSR watchdog timer expired\n");
> > + if (val & PSR_EVENT_PIPE_REGISTERS_UPDATE)
> > + DRM_DEBUG_KMS("\tPIPE registers updated\n");
> > + if (val & PSR_EVENT_REGISTER_UPDATE)
> > + DRM_DEBUG_KMS("\tRegister updated\n");
> > + if (val & PSR_EVENT_HDCP_ENABLE)
> > + DRM_DEBUG_KMS("\tHDCP enabled\n");
> > + if (val & PSR_EVENT_KVMR_SESSION_ENABLE)
> > + DRM_DEBUG_KMS("\tKVMR session enabled\n");
> > + if (val & PSR_EVENT_VBI_ENABLE)
> > + DRM_DEBUG_KMS("\tVBI enabled\n");
> > + if (val & PSR_EVENT_LPSP_MODE_EXIT)
> > + DRM_DEBUG_KMS("\tLPSP mode exited\n");
> > + if ((val & PSR_EVENT_PSR_DISABLE) && !psr2_enabled)
> > +
Re: [Intel-gfx] [PATCH 2/4] drm/i915/psr/skl+: Print information about what caused a PSR exit
On Wed, Apr 25, 2018 at 02:47:35PM -0700, Souza, Jose wrote:
> On Wed, 2018-04-25 at 14:40 -0700, Rodrigo Vivi wrote:
> > On Wed, Apr 25, 2018 at 02:23:32PM -0700, José Roberto de Souza
> > wrote:
> > > This will be helpful to debug what hardware is actually tracking
> > > and causing PSR to exit.
> > >
> > > BSpec: 7721
> > >
> > > v4:
> > > - Using _MMIO_TRANS2() in PSR_EVENT
> > > - Cleaning events before printing
> > >
> > > Signed-off-by: José Roberto de Souza
> > > Cc: Dhinakaran Pandiyan
> > > Cc: Rodrigo Vivi
> > > ---
> > > drivers/gpu/drm/i915/i915_reg.h | 23
> > > drivers/gpu/drm/i915/intel_psr.c | 45
> > >
> > > 2 files changed, 68 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 2dad655a710c..391825ae2361 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -4095,6 +4095,29 @@ enum {
> > > #define EDP_PSR2_IDLE_FRAME_MASK 0xf
> > > #define EDP_PSR2_IDLE_FRAME_SHIFT 0
> > >
> > > +#define _PSR_EVENT_TRANS_A 0x60848
> > > +#define _PSR_EVENT_TRANS_B 0x61848
> > > +#define _PSR_EVENT_TRANS_C 0x62848
> > > +#define _PSR_EVENT_TRANS_D 0x63848
> > > +#define _PSR_EVENT_TRANS_EDP 0x6F848
> > > +#define PSR_EVENT(trans) _MMIO_TRANS2(trans
> > > , _PSR_EVENT_TRANS_A)
> > > +#define PSR_EVENT_PSR2_WD_TIMER_EXPIRE (1 << 17)
> > > +#define PSR_EVENT_PSR2_DISABLED (1 << 16)
> > > +#define PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN(1 << 15)
> > > +#define PSR_EVENT_SU_CRC_FIFO_UNDERRUN (1 << 14)
> > > +#define PSR_EVENT_GRAPHICS_RESET(1 << 12)
> > > +#define PSR_EVENT_PCH_INTERRUPT (1 << 11)
> > > +#define PSR_EVENT_MEMORY_UP (1 << 10)
> > > +#define PSR_EVENT_FRONT_BUFFER_MODIFY (1 << 9)
> > > +#define PSR_EVENT_WD_TIMER_EXPIRE (1 << 8)
> > > +#define PSR_EVENT_PIPE_REGISTERS_UPDATE (1 << 6)
> > > +#define PSR_EVENT_REGISTER_UPDATE (1 << 5)
> > > +#define PSR_EVENT_HDCP_ENABLE (1 << 4)
> > > +#define PSR_EVENT_KVMR_SESSION_ENABLE (1 << 3)
> > > +#define PSR_EVENT_VBI_ENABLE(1 << 2)
> > > +#define PSR_EVENT_LPSP_MODE_EXIT(1 << 1)
> > > +#define PSR_EVENT_PSR_DISABLE (1 << 0)
> > > +
> > > #define EDP_PSR2_STATUS _MMIO(0x6f940)
> > > #define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
> > > #define EDP_PSR2_STATUS_STATE_SHIFT28
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index e35a3b94fa69..c8d5cdce544f 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -125,6 +125,43 @@ void intel_psr_irq_control(struct
> > > drm_i915_private *dev_priv, bool debug)
> > > I915_WRITE(EDP_PSR_IMR, ~mask);
> > > }
> > >
> > > +static void psr_event_print(u32 val, bool psr2_enabled)
> > > +{
> > > + DRM_DEBUG_KMS("PSR exit events: 0x%x\n", val);
> > > + if (val & PSR_EVENT_PSR2_WD_TIMER_EXPIRE)
> > > + DRM_DEBUG_KMS("\tPSR2 watchdog timer expired\n");
> > > + if ((val & PSR_EVENT_PSR2_DISABLED) && psr2_enabled)
> >
> > I'm not sure if we should add this extra psr2_enable check here.
> > Probably better to just print the bit reference and move one.
> >
> > otherwise we might have the risk of having a message
> > "PSR exit events:"
> > followed by nothing below it
>
> I'm okay with this too but I think is not necessary have 'PSR2
> disabled' printed everytime when PSR is enabled.
oh! I see your point now...
Makes sense to minimize this noise, and let's hope we
don't face the empty case.
>
> >
> > > + DRM_DEBUG_KMS("\tPSR2 disabled\n");
> > > + if (val & PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN)
> > > + DRM_DEBUG_KMS("\tSU dirty FIFO underrun\n");
> > > + if (val & PSR_EVENT_SU_CRC_FIFO_UNDERRUN)
> > > + DRM_DEBUG_KMS("\tSU CRC FIFO underrun\n");
> > > + if (val & PSR_EVENT_GRAPHICS_RESET)
> > > + DRM_DEBUG_KMS("\tGraphics reset\n");
> > > + if (val & PSR_EVENT_PCH_INTERRUPT)
> > > + DRM_DEBUG_KMS("\tPCH interrupt\n");
> > > + if (val & PSR_EVENT_MEMORY_UP)
> > > + DRM_DEBUG_KMS("\tMemory up\n");
> > > + if (val & PSR_EVENT_FRONT_BUFFER_MODIFY)
> > > + DRM_DEBUG_KMS("\tFront buffer modification\n");
> > > + if (val & PSR_EVENT_WD_TIMER_EXPIRE)
> > > + DRM_DEBUG_KMS("\tPSR watchdog timer expired\n");
> > > + if (val & PSR_EVENT_PIPE_REGISTERS_UPDATE)
> > > + DRM_DEBUG_KMS("\tPIPE registers updated\n");
> > > + if (val & PSR_EVENT_REGISTER_UPDATE)
> > > + DRM_DEBUG_KMS("\tRegister updated\n");
> > > + if (val & PSR_EVENT_HDCP_ENABLE)
> > > + DRM_DEBUG_KMS("\tHDCP enabled\n");
> > > +
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Optimize use of DBuf slices (rev2)
On Wed, Apr 25, 2018 at 09:46:23PM -, Patchwork wrote: > == Series Details == > > Series: Optimize use of DBuf slices (rev2) > URL : https://patchwork.freedesktop.org/series/41180/ > State : failure > > == Summary == > > Applying: drm/i915/icl: track dbuf slice-2 status > error: Failed to merge in the changes. > Using index info to reconstruct a base tree... > M drivers/gpu/drm/i915/i915_drv.h > M drivers/gpu/drm/i915/intel_display.c > M drivers/gpu/drm/i915/intel_pm.c > M drivers/gpu/drm/i915/intel_runtime_pm.c > Falling back to patching base and 3-way merge... > Auto-merging drivers/gpu/drm/i915/intel_runtime_pm.c > Auto-merging drivers/gpu/drm/i915/intel_pm.c > Auto-merging drivers/gpu/drm/i915/intel_display.c > Auto-merging drivers/gpu/drm/i915/i915_drv.h > CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_drv.h > Patch failed at 0001 drm/i915/icl: track dbuf slice-2 status > The copy of the patch that failed is found in: .git/rebase-apply/patch > When you have resolved this problem, run "git am --continue". > If you prefer to skip this patch, run "git am --skip" instead. > To restore the original branch and stop patching, run "git am --abort". Mahesh, I'm really sorry for taking so long to review these patches Could you please send a rebased version so after CI giving the okay we push it. Thanks in advance, Rodrigo. > > == Logs == > > For more details see: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8588/issues.html > ___ > 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] [PATCH] drm/i915: remove check for aux irq
This became dead code with commit 309bd8ed464f ("drm/i915: Reinstate
GMBUS and AUX interrupts on gen4/g4x").
Cc: Ville Syrjälä
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_drv.h | 3 +--
drivers/gpu/drm/i915/intel_dp.c | 22 +++---
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_psr.c | 2 +-
4 files changed, 9 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8444ca8d5aa3..09e1c2289ea1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2545,7 +2545,7 @@ intel_info(const struct drm_i915_private *dev_priv)
IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
/*
- * dp aux and gmbus irq on gen4 seems to be able to generate legacy interrupts
+ * gmbus irq on gen4 seems to be able to generate legacy interrupts
* even when in MSI mode. This results in spurious interrupt warnings if the
* legacy irq no. is shared with another device. The kernel then disables that
* interrupt source and so prevents the other device from working properly.
@@ -2553,7 +2553,6 @@ intel_info(const struct drm_i915_private *dev_priv)
* Since we don't enable MSI anymore on gen4, we can always use GMBUS/AUX
* interrupts.
*/
-#define HAS_AUX_IRQ(dev_priv) true
#define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
/* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 62f82c4298ac..fd417473b6a9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -936,7 +936,7 @@ intel_dp_check_edp(struct intel_dp *intel_dp)
}
static uint32_t
-intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
+intel_dp_aux_wait_done(struct intel_dp *intel_dp)
{
struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
@@ -944,14 +944,10 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool
has_aux_irq)
bool done;
#define C (((status = I915_READ_NOTRACE(ch_ctl)) & DP_AUX_CH_CTL_SEND_BUSY) ==
0)
- if (has_aux_irq)
- done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
- msecs_to_jiffies_timeout(10));
- else
- done = wait_for(C, 10) == 0;
+ done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
+ msecs_to_jiffies_timeout(10));
if (!done)
- DRM_ERROR("dp aux hw did not signal timeout (has irq: %i)!\n",
- has_aux_irq);
+ DRM_ERROR("dp aux hw did not signal timeout!\n");
#undef C
return status;
@@ -1016,7 +1012,6 @@ static uint32_t skl_get_aux_clock_divider(struct intel_dp
*intel_dp, int index)
}
static uint32_t g4x_get_aux_send_ctl(struct intel_dp *intel_dp,
-bool has_aux_irq,
int send_bytes,
uint32_t aux_clock_divider)
{
@@ -1037,7 +1032,7 @@ static uint32_t g4x_get_aux_send_ctl(struct intel_dp
*intel_dp,
return DP_AUX_CH_CTL_SEND_BUSY |
DP_AUX_CH_CTL_DONE |
- (has_aux_irq ? DP_AUX_CH_CTL_INTERRUPT : 0) |
+ DP_AUX_CH_CTL_INTERRUPT |
DP_AUX_CH_CTL_TIME_OUT_ERROR |
timeout |
DP_AUX_CH_CTL_RECEIVE_ERROR |
@@ -1047,13 +1042,12 @@ static uint32_t g4x_get_aux_send_ctl(struct intel_dp
*intel_dp,
}
static uint32_t skl_get_aux_send_ctl(struct intel_dp *intel_dp,
- bool has_aux_irq,
int send_bytes,
uint32_t unused)
{
return DP_AUX_CH_CTL_SEND_BUSY |
DP_AUX_CH_CTL_DONE |
- (has_aux_irq ? DP_AUX_CH_CTL_INTERRUPT : 0) |
+ DP_AUX_CH_CTL_INTERRUPT |
DP_AUX_CH_CTL_TIME_OUT_ERROR |
DP_AUX_CH_CTL_TIME_OUT_MAX |
DP_AUX_CH_CTL_RECEIVE_ERROR |
@@ -1076,7 +1070,6 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
int i, ret, recv_bytes;
uint32_t status;
int try, clock = 0;
- bool has_aux_irq = HAS_AUX_IRQ(dev_priv);
bool vdd;
ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
@@ -1131,7 +1124,6 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
while ((aux_clock_divider = intel_dp->get_aux_clock_divider(intel_dp,
clock++))) {
u32 send_ctl = intel_dp->get_aux_send_ctl(intel_dp,
- has_aux_irq,
send_bytes,
aux_clock_divider);
@@ -1148,7 +1140,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
[Intel-gfx] [PATCH v2 2/3] drm/i915/dp: Fix sink-crc reads.
Sink crc is calculated by the sink for static frames irrespective of
what the driver sets in TEST_SINK_START dpcd. Since PSR is the only use
case for sink crc, we don't really need the sink_crc_{start, stop} code.
The second problem with the current implementation is vblank waits.
Enabling vblank interrupts triggers PSR exit, which means we aren't
really reading the correct CRC values for PSR tests. vblank waits are
replaced by delays.
With the changes made in this patch, sink CRC is available only for
static frames. I have tested this on a SKL laptop with PSR panel.
v2: Use refresh rate to calculate frame time.
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 +-
drivers/gpu/drm/i915/intel_dp.c | 115 +---
drivers/gpu/drm/i915/intel_drv.h| 3 +-
3 files changed, 18 insertions(+), 104 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2f05f5262bba..e4ba6527c16e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2749,6 +2749,7 @@ static int i915_sink_crc(struct seq_file *m, void *data)
struct drm_crtc *crtc;
struct drm_connector_state *state;
struct intel_crtc_state *crtc_state;
+ int vrefresh;
if (connector->base.connector_type != DRM_MODE_CONNECTOR_eDP)
continue;
@@ -2783,8 +2784,9 @@ static int i915_sink_crc(struct seq_file *m, void *data)
}
intel_dp = enc_to_intel_dp(state->best_encoder);
+ vrefresh = crtc_state->base.adjusted_mode.vrefresh;
- ret = intel_dp_sink_crc(intel_dp, crtc_state, crc);
+ ret = intel_dp_sink_crc(intel_dp, vrefresh, crc);
if (ret)
goto err;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7dcc874b7d8f..3ab3f82e33f6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3876,32 +3876,19 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
intel_dp->is_mst);
}
-static int intel_dp_sink_crc_stop(struct intel_dp *intel_dp,
- struct intel_crtc_state *crtc_state, bool
disable_wa)
+int intel_dp_sink_crc(struct intel_dp *intel_dp, int vrefresh, u8 *crc)
{
- struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
- struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
- u8 buf;
- int ret = 0;
- int count = 0;
- int attempts = 10;
+ int count = 0, ret = 0, attempts;
+ int half_frame_us = DIV_ROUND_UP(100/2, vrefresh);
- if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0) {
- DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
- ret = -EIO;
- goto out;
- }
+ for (attempts = 0; attempts < 3 && count == 0; attempts++) {
+ u8 buf;
- if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_SINK,
- buf & ~DP_TEST_SINK_START) < 0) {
- DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
- ret = -EIO;
- goto out;
- }
-
- do {
- intel_wait_for_vblank(dev_priv, intel_crtc->pipe);
+ /* Wait for approximately half a frame, we cannot wait for a
+* vblank interrupt as it triggers PSR exit.
+*/
+ if (attempts)
+ usleep_range(half_frame_us, half_frame_us + 100);
if (drm_dp_dpcd_readb(&intel_dp->aux,
DP_TEST_SINK_MISC, &buf) < 0) {
@@ -3909,93 +3896,19 @@ static int intel_dp_sink_crc_stop(struct intel_dp
*intel_dp,
goto out;
}
count = buf & DP_TEST_COUNT_MASK;
- } while (--attempts && count);
-
- if (attempts == 0) {
- DRM_DEBUG_KMS("TIMEOUT: Sink CRC counter is not zeroed after
calculation is stopped\n");
- ret = -ETIMEDOUT;
}
- out:
- if (disable_wa)
- hsw_enable_ips(crtc_state);
- return ret;
-}
-
-static int intel_dp_sink_crc_start(struct intel_dp *intel_dp,
- struct intel_crtc_state *crtc_state)
-{
- struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
- struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
- u8 buf;
- int ret;
-
- if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK_MISC, &buf) < 0)
- return -EIO;
-
- if (!(buf & DP_TEST_CRC_SUPPORTED))
- re
[Intel-gfx] [PATCH v2 3/3] drm/i915/psr: Move sink-crc to intel_psr.c
With sink-crc now being relevant only for PSR static frames, move the
code to intel_psr.c and rename the function.
v2: Rebased.
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/intel_dp.c | 36
drivers/gpu/drm/i915/intel_drv.h| 2 +-
drivers/gpu/drm/i915/intel_psr.c| 36
4 files changed, 39 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e4ba6527c16e..a84f410ad722 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2786,7 +2786,7 @@ static int i915_sink_crc(struct seq_file *m, void *data)
intel_dp = enc_to_intel_dp(state->best_encoder);
vrefresh = crtc_state->base.adjusted_mode.vrefresh;
- ret = intel_dp_sink_crc(intel_dp, vrefresh, crc);
+ ret = intel_psr_sink_crc(intel_dp, vrefresh, crc);
if (ret)
goto err;
@@ -4856,7 +4856,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_ppgtt_info", i915_ppgtt_info, 0},
{"i915_llc", i915_llc, 0},
{"i915_edp_psr_status", i915_edp_psr_status, 0},
- {"i915_sink_crc_eDP1", i915_sink_crc, 0},
+ {"i915_edp_psr_sink_crc", i915_sink_crc, 0},
{"i915_energy_uJ", i915_energy_uJ, 0},
{"i915_runtime_pm_status", i915_runtime_pm_status, 0},
{"i915_power_domain_info", i915_power_domain_info, 0},
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3ab3f82e33f6..ff7522d3632e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3876,42 +3876,6 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
intel_dp->is_mst);
}
-int intel_dp_sink_crc(struct intel_dp *intel_dp, int vrefresh, u8 *crc)
-{
- int count = 0, ret = 0, attempts;
- int half_frame_us = DIV_ROUND_UP(100/2, vrefresh);
-
- for (attempts = 0; attempts < 3 && count == 0; attempts++) {
- u8 buf;
-
- /* Wait for approximately half a frame, we cannot wait for a
-* vblank interrupt as it triggers PSR exit.
-*/
- if (attempts)
- usleep_range(half_frame_us, half_frame_us + 100);
-
- if (drm_dp_dpcd_readb(&intel_dp->aux,
- DP_TEST_SINK_MISC, &buf) < 0) {
- ret = -EIO;
- goto out;
- }
- count = buf & DP_TEST_COUNT_MASK;
- }
-
- if (attempts == 3) {
- ret = -ETIMEDOUT;
- goto out;
- }
-
- if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR, crc, 6) != 6) {
- ret = -EIO;
- goto out;
- }
-
-out:
- return ret;
-}
-
static bool
intel_dp_get_sink_irq(struct intel_dp *intel_dp, u8 *sink_irq_vector)
{
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 48073be8a023..d4e5a40f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1644,7 +1644,6 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int
mode);
void intel_dp_encoder_reset(struct drm_encoder *encoder);
void intel_dp_encoder_suspend(struct intel_encoder *intel_encoder);
void intel_dp_encoder_destroy(struct drm_encoder *encoder);
-int intel_dp_sink_crc(struct intel_dp *intel_dp, int vrefresh, u8 *crc);
bool intel_dp_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state);
@@ -1900,6 +1899,7 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
struct intel_crtc_state *crtc_state);
void intel_psr_irq_control(struct drm_i915_private *dev_priv, bool debug);
void intel_psr_irq_handler(struct drm_i915_private *dev_priv, u32 psr_iir);
+int intel_psr_sink_crc(struct intel_dp *intel_dp, int vrefresh, u8 *crc);
/* intel_runtime_pm.c */
int intel_power_domains_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 0d548292dd09..8b3a3459eae5 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -197,6 +197,42 @@ static u8 intel_dp_get_sink_sync_latency(struct intel_dp
*intel_dp)
return val;
}
+int intel_psr_sink_crc(struct intel_dp *intel_dp, int vrefresh, u8 *crc)
+{
+ int count = 0, ret = 0, attempts;
+ int half_frame_us = DIV_ROUND_UP(100/2, vrefresh);
+
+ for (attempts = 0; attempts < 3 && count == 0; attempts++) {
+ u8 buf;
+
+ /* Wait for approximately half a frame, we cannot wait for a
+* vbl
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915/psr: Prevent PSR exit when a non-pipe related register is written
== Series Details == Series: series starting with [1/4] drm/i915/psr: Prevent PSR exit when a non-pipe related register is written URL : https://patchwork.freedesktop.org/series/42304/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4099 -> Patchwork_8802 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/42304/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_8802 that come from known issues: === IGT changes === Possible fixes igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 == Participating hosts (38 -> 35) == Missing(3): fi-ilk-m540 fi-skl-6700hq fi-pnv-d510 == Build changes == * Linux: CI_DRM_4099 -> Patchwork_8802 CI_DRM_4099: 92a39635c2eca4dfe1c8c1673e0c606a720746e5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4449: 0350f0e7f6a0e07281445fc3082aa70419f4aac7 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8802: cd94e9f8e4937f47d54a2eb6e821020f388b5cdf @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4449: ad8992d3fb27fd604b9ab15e7963c42421ced85c @ git://anongit.freedesktop.org/piglit == Linux commits == cd94e9f8e493 drm/i915/psr/cnl: Set y-coordinate as valid in SDP 48dc63739f2f drm/i915/debugfs: Print sink PSR status 02bba1aa3a2b drm/i915/psr/skl+: Print information about what caused a PSR exit 632045d33482 drm/i915/psr: Prevent PSR exit when a non-pipe related register is written == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8802/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: remove check for aux irq
== Series Details == Series: drm/i915: remove check for aux irq URL : https://patchwork.freedesktop.org/series/42305/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: remove check for aux irq -drivers/gpu/drm/i915/selftests/../i915_drv.h:3659:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3658:16: warning: expression using sizeof(void) ___ 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: remove check for aux irq
== Series Details == Series: drm/i915: remove check for aux irq URL : https://patchwork.freedesktop.org/series/42305/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4099 -> Patchwork_8803 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/42305/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_8803 that come from known issues: === IGT changes === Issues hit igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: PASS -> FAIL (fdo#102575) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-ivb-3520m: PASS -> DMESG-WARN (fdo#106084) igt@prime_vgem@basic-fence-flip: fi-ilk-650: PASS -> FAIL (fdo#104008) fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084 == Participating hosts (38 -> 35) == Missing(3): fi-ilk-m540 fi-skl-6700hq fi-pnv-d510 == Build changes == * Linux: CI_DRM_4099 -> Patchwork_8803 CI_DRM_4099: 92a39635c2eca4dfe1c8c1673e0c606a720746e5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4449: 0350f0e7f6a0e07281445fc3082aa70419f4aac7 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8803: e1dc08fa1c44a40c406ef757a2b85f4c41b6fb64 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4449: ad8992d3fb27fd604b9ab15e7963c42421ced85c @ git://anongit.freedesktop.org/piglit == Linux commits == e1dc08fa1c44 drm/i915: remove check for aux irq == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8803/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/dp: Check if the sink crc we read is 6 bytes. (rev3)
== Series Details == Series: series starting with [1/3] drm/i915/dp: Check if the sink crc we read is 6 bytes. (rev3) URL : https://patchwork.freedesktop.org/series/42154/ State : warning == Summary == $ dim checkpatch origin/drm-tip 89124b64449f drm/i915/dp: Check if the sink crc we read is 6 bytes. d8db909cc13f drm/i915/dp: Fix sink-crc reads. -:65: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV) #65: FILE: drivers/gpu/drm/i915/intel_dp.c:3882: + int half_frame_us = DIV_ROUND_UP(100/2, vrefresh); ^ total: 0 errors, 0 warnings, 1 checks, 165 lines checked 3288f3762198 drm/i915/psr: Move sink-crc to intel_psr.c -:112: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV) #112: FILE: drivers/gpu/drm/i915/intel_psr.c:203: + int half_frame_us = DIV_ROUND_UP(100/2, vrefresh); ^ total: 0 errors, 0 warnings, 1 checks, 114 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/dp: Check if the sink crc we read is 6 bytes. (rev3)
== Series Details ==
Series: series starting with [1/3] drm/i915/dp: Check if the sink crc we read
is 6 bytes. (rev3)
URL : https://patchwork.freedesktop.org/series/42154/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4099 -> Patchwork_8804 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_8804 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_8804, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/42154/revisions/3/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_8804:
=== IGT changes ===
Possible regressions
igt@kms_frontbuffer_tracking@basic:
fi-cnl-y3: PASS -> FAIL
fi-cnl-psr: PASS -> FAIL
fi-cfl-s3: PASS -> FAIL
fi-kbl-7560u: PASS -> FAIL
fi-skl-6600u: PASS -> FAIL
{fi-hsw-4200u}: PASS -> FAIL
fi-kbl-r: PASS -> FAIL
fi-cfl-u: PASS -> FAIL
Warnings
igt@kms_sink_crc_basic:
fi-cfl-u: PASS -> SKIP
{fi-hsw-4200u}: PASS -> SKIP
fi-cnl-psr: PASS -> SKIP
== Known issues ==
Here are the changes found in Patchwork_8804 that come from known issues:
=== IGT changes ===
Possible fixes
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
== Participating hosts (38 -> 35) ==
Missing(3): fi-ilk-m540 fi-skl-6700hq fi-pnv-d510
== Build changes ==
* Linux: CI_DRM_4099 -> Patchwork_8804
CI_DRM_4099: 92a39635c2eca4dfe1c8c1673e0c606a720746e5 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4449: 0350f0e7f6a0e07281445fc3082aa70419f4aac7 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_8804: 3288f3762198964ac51b630273a5b3cbbee2db4d @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4449: ad8992d3fb27fd604b9ab15e7963c42421ced85c @
git://anongit.freedesktop.org/piglit
== Linux commits ==
3288f3762198 drm/i915/psr: Move sink-crc to intel_psr.c
d8db909cc13f drm/i915/dp: Fix sink-crc reads.
89124b64449f drm/i915/dp: Check if the sink crc we read is 6 bytes.
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8804/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake
Hi Anusha, Can I ask if this is on anyone's radar as I'm concerned this patch will stall otherwise? I see that the significance of testing with the 4.14 kernel enabled the firmware to be included in the latest Chrome OS kernel ( https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-reviews/jtpHvZOfZ-Q). It is important to similarly include in the mainline and stable kernels to facilitate various distros that are now raising bug reports (for example: https://bugs.launchpad.net/intel/+bug/1760545). Many thanks, Ian On Sun, 22 Apr 2018 at 08:46, Ian W MORRISON wrote: > On 21 April 2018 at 11:22, Botello Ortega, Luis > wrote: > > Hi all: > > > > We tested GLK DMC 1.04 FW in last week of September 2017, using the latest drm-tip version for that time (4.14.0-rc2) and according to our results we could declare this FW as acceptable and healthy to be used with kernel version 4.14 . > > However, we cannot guarantee quality and healthy of this FW if it is used in top of current drm-tip kernel (4.17-rc0). > > > > Best Regards > > Luis Botello > > > > > Your measured response is appreciated and raises at least four > possible alternatives for this patch to proceed: > 1. It is normal that firmware is *only* tested at a certain point in > time with the drm-tip version of the mainline kernel so that the > statement 'firmware X is acceptable and healthy to be used with kernel > version Y but is not guaranteed with Y+1 or Y+n' always holds true for > any microarchitecture codename's DMC firmware. Therefore it is > appropriate for this patch to have a restricted 'Cc: > sta...@vger.kernel.org # 4.14' tag together with an explicit > 'Tested-by: (in 4.14)' tag. > 2. As firmware testing was not performed on 4.15 and subsequent > versions, testing is still required on versions 4.15 through to the > current RC of version 4.17 for the patch to receive a 'Tested-by:' tag > together with a 'Cc: sta...@vger.kernel.org # 4.14' tag. > 3. Further firmware testing will only be undertaken for the current RC > of version 4.17 and on successful completion the patch will only > receive a 'Tested-by:' tag. A 'Cc: sta...@vger.kernel.org' tag is not > applicable. > 4. The firmware was not tested on 4.15 and subsequent versions as it's > functionality was provided by alternative means and therefore the > patch is only required in version 4.14 and should have a 'Cc: > sta...@vger.kernel.org # 4.14 only' tag together with a restricted > 'Tested-by: (only in 4.14)' tag. > Could you indicate which alternative is appropriate? If further > firmware testing is required (as in points 2 or 3) then can an > expected completion date be provided? > Best regards, > Ian ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/dp: Fix sink-crc reads.
On Wed, Apr 25, 2018 at 02:57:57PM -0700, Dhinakaran Pandiyan wrote:
> Sink crc is calculated by the sink for static frames irrespective of
> what the driver sets in TEST_SINK_START dpcd. Since PSR is the only use
> case for sink crc, we don't really need the sink_crc_{start, stop} code.
>
> The second problem with the current implementation is vblank waits.
> Enabling vblank interrupts triggers PSR exit, which means we aren't
> really reading the correct CRC values for PSR tests. vblank waits are
> replaced by delays.
>
> With the changes made in this patch, sink CRC is available only for
> static frames. I have tested this on a SKL laptop with PSR panel.
>
> v2: Use refresh rate to calculate frame time.
Cool! :)
>
> Signed-off-by: Dhinakaran Pandiyan
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 4 +-
> drivers/gpu/drm/i915/intel_dp.c | 115
> +---
> drivers/gpu/drm/i915/intel_drv.h| 3 +-
> 3 files changed, 18 insertions(+), 104 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 2f05f5262bba..e4ba6527c16e 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2749,6 +2749,7 @@ static int i915_sink_crc(struct seq_file *m, void *data)
> struct drm_crtc *crtc;
> struct drm_connector_state *state;
> struct intel_crtc_state *crtc_state;
> + int vrefresh;
>
> if (connector->base.connector_type != DRM_MODE_CONNECTOR_eDP)
> continue;
> @@ -2783,8 +2784,9 @@ static int i915_sink_crc(struct seq_file *m, void *data)
> }
>
> intel_dp = enc_to_intel_dp(state->best_encoder);
> + vrefresh = crtc_state->base.adjusted_mode.vrefresh;
>
> - ret = intel_dp_sink_crc(intel_dp, crtc_state, crc);
> + ret = intel_dp_sink_crc(intel_dp, vrefresh, crc);
> if (ret)
> goto err;
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 7dcc874b7d8f..3ab3f82e33f6 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3876,32 +3876,19 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
> intel_dp->is_mst);
> }
>
> -static int intel_dp_sink_crc_stop(struct intel_dp *intel_dp,
> - struct intel_crtc_state *crtc_state, bool
> disable_wa)
> +int intel_dp_sink_crc(struct intel_dp *intel_dp, int vrefresh, u8 *crc)
> {
> - struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> - struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> - struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
> - u8 buf;
> - int ret = 0;
> - int count = 0;
> - int attempts = 10;
> + int count = 0, ret = 0, attempts;
> + int half_frame_us = DIV_ROUND_UP(100/2, vrefresh);
>
> - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0) {
> - DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
> - ret = -EIO;
> - goto out;
> - }
> + for (attempts = 0; attempts < 3 && count == 0; attempts++) {
> + u8 buf;
>
> - if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_SINK,
> -buf & ~DP_TEST_SINK_START) < 0) {
> - DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
> - ret = -EIO;
> - goto out;
> - }
> -
> - do {
> - intel_wait_for_vblank(dev_priv, intel_crtc->pipe);
> + /* Wait for approximately half a frame, we cannot wait for a
> + * vblank interrupt as it triggers PSR exit.
> + */
> + if (attempts)
> + usleep_range(half_frame_us, half_frame_us + 100);
>
> if (drm_dp_dpcd_readb(&intel_dp->aux,
> DP_TEST_SINK_MISC, &buf) < 0) {
> @@ -3909,93 +3896,19 @@ static int intel_dp_sink_crc_stop(struct intel_dp
> *intel_dp,
> goto out;
> }
> count = buf & DP_TEST_COUNT_MASK;
> - } while (--attempts && count);
> -
> - if (attempts == 0) {
> - DRM_DEBUG_KMS("TIMEOUT: Sink CRC counter is not zeroed after
> calculation is stopped\n");
> - ret = -ETIMEDOUT;
> }
>
> - out:
> - if (disable_wa)
> - hsw_enable_ips(crtc_state);
> - return ret;
> -}
> -
> -static int intel_dp_sink_crc_start(struct intel_dp *intel_dp,
> -struct intel_crtc_state *crtc_state)
> -{
> - struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> - struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> - struct intel_crtc *intel_crtc = to_intel_crtc(cr
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/psr: Move sink-crc to intel_psr.c
On Wed, Apr 25, 2018 at 02:58:34PM -0700, Dhinakaran Pandiyan wrote:
> With sink-crc now being relevant only for PSR static frames, move the
> code to intel_psr.c and rename the function.
>
> v2: Rebased.
> Signed-off-by: Dhinakaran Pandiyan
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
> drivers/gpu/drm/i915/intel_dp.c | 36
> drivers/gpu/drm/i915/intel_drv.h| 2 +-
> drivers/gpu/drm/i915/intel_psr.c| 36
> 4 files changed, 39 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index e4ba6527c16e..a84f410ad722 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2786,7 +2786,7 @@ static int i915_sink_crc(struct seq_file *m, void *data)
> intel_dp = enc_to_intel_dp(state->best_encoder);
> vrefresh = crtc_state->base.adjusted_mode.vrefresh;
>
> - ret = intel_dp_sink_crc(intel_dp, vrefresh, crc);
> + ret = intel_psr_sink_crc(intel_dp, vrefresh, crc);
> if (ret)
> goto err;
>
> @@ -4856,7 +4856,7 @@ static const struct drm_info_list i915_debugfs_list[] =
> {
> {"i915_ppgtt_info", i915_ppgtt_info, 0},
> {"i915_llc", i915_llc, 0},
> {"i915_edp_psr_status", i915_edp_psr_status, 0},
> - {"i915_sink_crc_eDP1", i915_sink_crc, 0},
> + {"i915_edp_psr_sink_crc", i915_sink_crc, 0},
> {"i915_energy_uJ", i915_energy_uJ, 0},
> {"i915_runtime_pm_status", i915_runtime_pm_status, 0},
> {"i915_power_domain_info", i915_power_domain_info, 0},
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 3ab3f82e33f6..ff7522d3632e 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3876,42 +3876,6 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
> intel_dp->is_mst);
> }
>
> -int intel_dp_sink_crc(struct intel_dp *intel_dp, int vrefresh, u8 *crc)
> -{
> - int count = 0, ret = 0, attempts;
> - int half_frame_us = DIV_ROUND_UP(100/2, vrefresh);
> -
> - for (attempts = 0; attempts < 3 && count == 0; attempts++) {
> - u8 buf;
> -
> - /* Wait for approximately half a frame, we cannot wait for a
> - * vblank interrupt as it triggers PSR exit.
> - */
> - if (attempts)
> - usleep_range(half_frame_us, half_frame_us + 100);
> -
> - if (drm_dp_dpcd_readb(&intel_dp->aux,
> - DP_TEST_SINK_MISC, &buf) < 0) {
> - ret = -EIO;
> - goto out;
> - }
> - count = buf & DP_TEST_COUNT_MASK;
> - }
> -
> - if (attempts == 3) {
> - ret = -ETIMEDOUT;
> - goto out;
> - }
> -
> - if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR, crc, 6) != 6) {
> - ret = -EIO;
> - goto out;
> - }
> -
> -out:
> - return ret;
> -}
> -
> static bool
> intel_dp_get_sink_irq(struct intel_dp *intel_dp, u8 *sink_irq_vector)
> {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 48073be8a023..d4e5a40f 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1644,7 +1644,6 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int
> mode);
> void intel_dp_encoder_reset(struct drm_encoder *encoder);
> void intel_dp_encoder_suspend(struct intel_encoder *intel_encoder);
> void intel_dp_encoder_destroy(struct drm_encoder *encoder);
> -int intel_dp_sink_crc(struct intel_dp *intel_dp, int vrefresh, u8 *crc);
> bool intel_dp_compute_config(struct intel_encoder *encoder,
>struct intel_crtc_state *pipe_config,
>struct drm_connector_state *conn_state);
> @@ -1900,6 +1899,7 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
> struct intel_crtc_state *crtc_state);
> void intel_psr_irq_control(struct drm_i915_private *dev_priv, bool debug);
> void intel_psr_irq_handler(struct drm_i915_private *dev_priv, u32 psr_iir);
> +int intel_psr_sink_crc(struct intel_dp *intel_dp, int vrefresh, u8 *crc);
>
> /* intel_runtime_pm.c */
> int intel_power_domains_init(struct drm_i915_private *);
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 0d548292dd09..8b3a3459eae5 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -197,6 +197,42 @@ static u8 intel_dp_get_sink_sync_latency(struct intel_dp
> *intel_dp)
> return val;
> }
>
> +int intel_psr_sink_crc(struct intel_dp *intel_dp, int vrefresh, u8 *crc)
> +{
> + int count = 0, ret = 0, attempts;
> + int
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/dp: Check if the sink crc we read is 6 bytes. (rev3)
On Wed, Apr 25, 2018 at 10:48:10PM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/3] drm/i915/dp: Check if the sink crc we read
> is 6 bytes. (rev3)
> URL : https://patchwork.freedesktop.org/series/42154/
> State : failure
>
> == Summary ==
>
> = CI Bug Log - changes from CI_DRM_4099 -> Patchwork_8804 =
>
> == Summary - FAILURE ==
>
> Serious unknown changes coming with Patchwork_8804 absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_8804, please notify your bug team to allow them
> to document this new failure mode, which will reduce false positives in CI.
>
> External URL:
> https://patchwork.freedesktop.org/api/1.0/series/42154/revisions/3/mbox/
>
> == Possible new issues ==
>
> Here are the unknown changes that may have been introduced in
> Patchwork_8804:
>
> === IGT changes ===
>
> Possible regressions
>
> igt@kms_frontbuffer_tracking@basic:
> fi-cnl-y3: PASS -> FAIL
> fi-cnl-psr: PASS -> FAIL
> fi-cfl-s3: PASS -> FAIL
> fi-kbl-7560u: PASS -> FAIL
> fi-skl-6600u: PASS -> FAIL
> {fi-hsw-4200u}: PASS -> FAIL
> fi-kbl-r: PASS -> FAIL
> fi-cfl-u: PASS -> FAIL
it seems that we need to kill sink_crc test case first...
>
>
> Warnings
>
> igt@kms_sink_crc_basic:
> fi-cfl-u: PASS -> SKIP
> {fi-hsw-4200u}: PASS -> SKIP
> fi-cnl-psr: PASS -> SKIP
>
>
> == Known issues ==
>
> Here are the changes found in Patchwork_8804 that come from known issues:
>
> === IGT changes ===
>
> Possible fixes
>
> igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
> fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS
>
>
> {name}: This element is suppressed. This means it is ignored when computing
> the status of the difference (SUCCESS, WARNING, or FAILURE).
>
> fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
>
>
> == Participating hosts (38 -> 35) ==
>
> Missing(3): fi-ilk-m540 fi-skl-6700hq fi-pnv-d510
>
>
> == Build changes ==
>
> * Linux: CI_DRM_4099 -> Patchwork_8804
>
> CI_DRM_4099: 92a39635c2eca4dfe1c8c1673e0c606a720746e5 @
> git://anongit.freedesktop.org/gfx-ci/linux
> IGT_4449: 0350f0e7f6a0e07281445fc3082aa70419f4aac7 @
> git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
> Patchwork_8804: 3288f3762198964ac51b630273a5b3cbbee2db4d @
> git://anongit.freedesktop.org/gfx-ci/linux
> piglit_4449: ad8992d3fb27fd604b9ab15e7963c42421ced85c @
> git://anongit.freedesktop.org/piglit
>
>
> == Linux commits ==
>
> 3288f3762198 drm/i915/psr: Move sink-crc to intel_psr.c
> d8db909cc13f drm/i915/dp: Fix sink-crc reads.
> 89124b64449f drm/i915/dp: Check if the sink crc we read is 6 bytes.
>
> == Logs ==
>
> For more details see:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8804/issues.html
> ___
> 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] drm/i915: remove check for aux irq
On Wed, Apr 25, 2018 at 02:55:24PM -0700, Lucas De Marchi wrote:
> This became dead code with commit 309bd8ed464f ("drm/i915: Reinstate
> GMBUS and AUX interrupts on gen4/g4x").
>
> Cc: Ville Syrjälä
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 +--
> drivers/gpu/drm/i915/intel_dp.c | 22 +++---
> drivers/gpu/drm/i915/intel_drv.h | 1 -
> drivers/gpu/drm/i915/intel_psr.c | 2 +-
> 4 files changed, 9 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8444ca8d5aa3..09e1c2289ea1 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2545,7 +2545,7 @@ intel_info(const struct drm_i915_private *dev_priv)
>IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
>
> /*
> - * dp aux and gmbus irq on gen4 seems to be able to generate legacy
> interrupts
> + * gmbus irq on gen4 seems to be able to generate legacy interrupts
> * even when in MSI mode. This results in spurious interrupt warnings if the
> * legacy irq no. is shared with another device. The kernel then disables
> that
> * interrupt source and so prevents the other device from working properly.
> @@ -2553,7 +2553,6 @@ intel_info(const struct drm_i915_private *dev_priv)
> * Since we don't enable MSI anymore on gen4, we can always use GMBUS/AUX
> * interrupts.
> */
> -#define HAS_AUX_IRQ(dev_priv) true
> #define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
>
> /* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 62f82c4298ac..fd417473b6a9 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -936,7 +936,7 @@ intel_dp_check_edp(struct intel_dp *intel_dp)
> }
>
> static uint32_t
> -intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
> +intel_dp_aux_wait_done(struct intel_dp *intel_dp)
> {
> struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
> i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
> @@ -944,14 +944,10 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool
> has_aux_irq)
> bool done;
>
> #define C (((status = I915_READ_NOTRACE(ch_ctl)) & DP_AUX_CH_CTL_SEND_BUSY)
> == 0)
> - if (has_aux_irq)
> - done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
> - msecs_to_jiffies_timeout(10));
> - else
> - done = wait_for(C, 10) == 0;
> + done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
> + msecs_to_jiffies_timeout(10));
> if (!done)
> - DRM_ERROR("dp aux hw did not signal timeout (has irq: %i)!\n",
> - has_aux_irq);
> + DRM_ERROR("dp aux hw did not signal timeout!\n");
> #undef C
>
> return status;
> @@ -1016,7 +1012,6 @@ static uint32_t skl_get_aux_clock_divider(struct
> intel_dp *intel_dp, int index)
> }
>
> static uint32_t g4x_get_aux_send_ctl(struct intel_dp *intel_dp,
> - bool has_aux_irq,
>int send_bytes,
>uint32_t aux_clock_divider)
> {
> @@ -1037,7 +1032,7 @@ static uint32_t g4x_get_aux_send_ctl(struct intel_dp
> *intel_dp,
>
> return DP_AUX_CH_CTL_SEND_BUSY |
> DP_AUX_CH_CTL_DONE |
> -(has_aux_irq ? DP_AUX_CH_CTL_INTERRUPT : 0) |
> +DP_AUX_CH_CTL_INTERRUPT |
> DP_AUX_CH_CTL_TIME_OUT_ERROR |
> timeout |
> DP_AUX_CH_CTL_RECEIVE_ERROR |
> @@ -1047,13 +1042,12 @@ static uint32_t g4x_get_aux_send_ctl(struct intel_dp
> *intel_dp,
> }
>
> static uint32_t skl_get_aux_send_ctl(struct intel_dp *intel_dp,
> - bool has_aux_irq,
> int send_bytes,
> uint32_t unused)
> {
> return DP_AUX_CH_CTL_SEND_BUSY |
> DP_AUX_CH_CTL_DONE |
> -(has_aux_irq ? DP_AUX_CH_CTL_INTERRUPT : 0) |
> +DP_AUX_CH_CTL_INTERRUPT |
> DP_AUX_CH_CTL_TIME_OUT_ERROR |
> DP_AUX_CH_CTL_TIME_OUT_MAX |
> DP_AUX_CH_CTL_RECEIVE_ERROR |
> @@ -1076,7 +1070,6 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
> int i, ret, recv_bytes;
> uint32_t status;
> int try, clock = 0;
> - bool has_aux_irq = HAS_AUX_IRQ(dev_priv);
> bool vdd;
>
> ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
> @@ -1131,7 +1124,6 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
>
> while ((aux_clock_divider = intel_dp->get_aux_clock_divider(intel_dp,
> clock++))) {
> u32 send_ctl = intel_dp->get_aux_send_ctl(intel_dp,
> - has_aux_irq,
Re: [Intel-gfx] [PATCH 08/17] drm/i915/icl: Implement voltage swing programming sequence for Combo PHY DDI
Em Qua, 2018-04-25 às 11:01 -0700, Rodrigo Vivi escreveu:
> On Tue, Apr 24, 2018 at 05:34:14PM -0700, Paulo Zanoni wrote:
> > Em Qui, 2018-04-05 às 17:20 -0700, Rodrigo Vivi escreveu:
> > > On Thu, Feb 22, 2018 at 12:55:10AM -0300, Paulo Zanoni wrote:
> > > > From: Manasi Navare
> > > >
> > > > This is an important part of the DDI initalization as well as
> > > > for changing the voltage during DisplayPort link training.
> > > >
> > > > The Voltage swing seqeuence is similar to Cannonlake.
> > > > However it has different register definitions and hence
> > > > it makes sense to create a separate vswing sequence and
> > > > program functions for ICL to leave room for more changes
> > > > in case the Bspec changes later and deviates from CNL sequence.
> > > >
> > > > v2:
> > > > Use ~TAP3_DISABLE for enbaling that bit (Jani Nikula)
> > > >
> > > > v3:
> > > > * Use dw4_scaling column for PORT_TX_DW4 values (Rodrigo)
> > > >
> > > > v4:
> > > > * Call it combo_vswing, use switch statement (Paulo)
> > > >
> > > > v5 (from Paulo):
> > > > * Fix a typo.
> > > > * s/rate < 60/rate <= 60/.
> > > > * Don't remove blank lines that should be there.
> > > >
> > > > v6:
> > > > * Rebased by Rodrigo on top of Cannonlake changes
> > > > where non vswing sequences are not aligned with iboost
> > > > anymore.
> > > >
> > > > v7: Another rebase after an upstream rework.
> > > >
> > > > v8 (from Paulo):
> > > > * Adjust the code to the upstream output type changes.
> > > > * Squash the patch that moved some functions up.
> > > > * Merge both get_combo_buf_trans functions in order to simplify
> > > > the
> > > > code.
> > > > * Change the changelog format.
> > > >
> > > > Cc: Jani Nikula
> > > > Reviewed-by: Paulo Zanoni (v5)
> > > > Signed-off-by: Manasi Navare
> > > > Signed-off-by: Rodrigo Vivi
> > > > Signed-off-by: Paulo Zanoni
> > > > ---
> > > > drivers/gpu/drm/i915/intel_ddi.c | 189
> > > > ++-
> > > > 1 file changed, 186 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > index 0a4683991ec2..c38873cb98ca 100644
> > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > @@ -849,6 +849,45 @@ cnl_get_buf_trans_edp(struct
> > > > drm_i915_private
> > > > *dev_priv, int *n_entries)
> > > > }
> > > > }
> > > >
> > > > +static const struct icl_combo_phy_ddi_buf_trans *
> > > > +icl_get_combo_buf_trans(struct drm_i915_private *dev_priv,
> > > > enum
> > > > port port,
> > > > + int type, int *n_entries)
> > > > +{
> > > > + u32 voltage = I915_READ(ICL_PORT_COMP_DW3(port)) &
> > > > VOLTAGE_INFO_MASK;
> > > > +
> > > > + if (type == INTEL_OUTPUT_EDP && dev_priv-
> > > > > vbt.edp.low_vswing) {
> > > >
> > > > + switch (voltage) {
> > > > + case VOLTAGE_INFO_0_85V:
> > > > + *n_entries =
> > > > ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_0_85V);
> > > > + return
> > > > icl_combo_phy_ddi_translations_edp_0_85V;
> > > > + case VOLTAGE_INFO_0_95V:
> > > > + *n_entries =
> > > > ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_0_95V);
> > > > + return
> > > > icl_combo_phy_ddi_translations_edp_0_95V;
> > > > + case VOLTAGE_INFO_1_05V:
> > > > + *n_entries =
> > > > ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_1_05V);
> > > > + return
> > > > icl_combo_phy_ddi_translations_edp_1_05V;
> > > > + default:
> > > > + MISSING_CASE(voltage);
> > > > + return NULL;
> > > > + }
> > > > + } else {
> > >
> > > DP ends up here on HDMI?
> > > This is strange...
> >
> > DP ends on the "dp_hdmi" part, while edp ends on the "edp" part.
> > What
> > is strange about that?
>
> Oh... actually spec is strange...
> They have 2 tables, 1 for DP and 1 for HDMI.
> I just read them again and they are the same indeed.
> So, nothing wrong here.
>
> >
> > >
> > > Also, for clarity, why not to split this into separated functions
> > > like all other platforms?
> >
> > So we don't end up reading PORT_COMP_DW3 multiple times (like we do
> > for
> > CNL), and as a bonus the code looks better IMHO.
>
> Agree.
>
> Reviewed-by: Rodrigo Vivi
You're reviewing v8 of the patch. This thread already has v9 (as a
reply to v8). Does the r-b also apply to it?
v9 was also resent as https://patchwork.freedesktop.org/patch/213515/
>
> >
> >
> >
> > >
> > > > + switch (voltage) {
> > > > + case VOLTAGE_INFO_0_85V:
> > > > + *n_entries =
> > > > ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hdmi_0_85V);
> > > > + return
> > > > icl_combo_phy_ddi_translations_dp_hdmi_0_85V;
> > > > +
Re: [Intel-gfx] [PATCH 3/3] drm/i915/icl: update ddb entry start/end mask during hw ddb readout
On Thu, Apr 05, 2018 at 02:47:56PM +0530, Mahesh Kumar wrote:
> Gen11/ICL onward ddb entry start/end mask is increased from 10 bits to
> 11 bits. This patch make changes to use proper mask for ICL+ during
> hardware ddb value readout.
>
> Changes since V1:
> - Use _MASK & _SHIFT macro (James)
> Changes since V2:
> - use kernel type u8 instead of uint8_t
Paulo warned me that I reviewed the wrong one.
rv-b stays with this change.
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: Mahesh Kumar
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> drivers/gpu/drm/i915/intel_pm.c | 18 ++
> 2 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 176dca6554f4..e3a6c535617d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6459,6 +6459,9 @@ enum {
>
> #define _PLANE_BUF_CFG_1_B 0x7127c
> #define _PLANE_BUF_CFG_2_B 0x7137c
> +#define SKL_DDB_ENTRY_MASK 0x3FF
> +#define ICL_DDB_ENTRY_MASK 0x7FF
> +#define DDB_ENTRY_END_SHIFT 16
> #define _PLANE_BUF_CFG_1(pipe) \
> _PIPE(pipe, _PLANE_BUF_CFG_1_A, _PLANE_BUF_CFG_1_B)
> #define _PLANE_BUF_CFG_2(pipe) \
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 615a084736f3..f7522b268494 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3864,10 +3864,18 @@ static unsigned int skl_cursor_allocation(int
> num_active)
> return 8;
> }
>
> -static void skl_ddb_entry_init_from_hw(struct skl_ddb_entry *entry, u32 reg)
> +static void skl_ddb_entry_init_from_hw(struct drm_i915_private *dev_priv,
> +struct skl_ddb_entry *entry, u32 reg)
> {
> - entry->start = reg & 0x3ff;
> - entry->end = (reg >> 16) & 0x3ff;
> + u16 mask;
> +
> + if (INTEL_GEN(dev_priv) >= 11)
> + mask = ICL_DDB_ENTRY_MASK;
> + else
> + mask = SKL_DDB_ENTRY_MASK;
> + entry->start = reg & mask;
> + entry->end = (reg >> DDB_ENTRY_END_SHIFT) & mask;
> +
> if (entry->end)
> entry->end += 1;
> }
> @@ -3898,7 +3906,9 @@ void skl_ddb_get_hw_state(struct drm_i915_private
> *dev_priv,
> else
> val = I915_READ(CUR_BUF_CFG(pipe));
>
> - skl_ddb_entry_init_from_hw(&ddb->plane[pipe][plane_id],
> val);
> + skl_ddb_entry_init_from_hw(dev_priv,
> +&ddb->plane[pipe][plane_id],
> +val);
> }
>
> intel_display_power_put(dev_priv, power_domain);
> --
> 2.16.2
>
> ___
> 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 2/3] drm/i915/icl: Enable 2nd DBuf slice only when needed
On Thu, Apr 05, 2018 at 02:47:55PM +0530, Mahesh Kumar wrote:
> ICL has two slices of DBuf, each slice of size 1024 blocks.
> We should not always enable slice-2. It should be enabled only if
> display total required BW is > 12GBps OR more than 1 pipes are enabled.
>
> Changes since V1:
> - typecast total_data_rate to u64 before multiplication to solve any
>possible overflow (Rodrigo)
> - fix where skl_wm_get_hw_state was memsetting ddb, resulting
>enabled_slices to become zero
> - Fix the logic of calculating ddb_size
> Changes since V2:
> - If no-crtc is part of commit required_slices will have value "0",
>don't try to disable DBuf slice.
> Changes since V3:
> - Create a generic helper to enable/disable slice
> - don't return early if total_data_rate is 0, it may be cursor only
>commit, or atomic modeset without any plane.
> Changes since V3:
> - Solve checkpatch warnings
> - use kernel types u8/u64 instead of uint8_t/uint64_t
Paulo warned me that I reviewed the wrong one.
rv-b stays with this change.
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: Mahesh Kumar
> ---
> drivers/gpu/drm/i915/intel_display.c| 10 +
> drivers/gpu/drm/i915/intel_drv.h| 6 +++
> drivers/gpu/drm/i915/intel_pm.c | 57 +++--
> drivers/gpu/drm/i915/intel_runtime_pm.c | 65
> ++---
> 4 files changed, 113 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 96a1e6a7f69e..dfd7288b9484 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12196,6 +12196,8 @@ static void skl_update_crtcs(struct drm_atomic_state
> *state)
> bool progress;
> enum pipe pipe;
> int i;
> + u8 hw_enabled_slices = dev_priv->wm.skl_hw.ddb.enabled_slices;
> + u8 required_slices = intel_state->wm_results.ddb.enabled_slices;
>
> const struct skl_ddb_entry *entries[I915_MAX_PIPES] = {};
>
> @@ -12204,6 +12206,10 @@ static void skl_update_crtcs(struct drm_atomic_state
> *state)
> if (new_crtc_state->active)
> entries[i] =
> &to_intel_crtc_state(old_crtc_state)->wm.skl.ddb;
>
> + /* If 2nd DBuf slice required, enable it here */
> + if (INTEL_GEN(dev_priv) >= 11 && required_slices > hw_enabled_slices)
> + icl_dbuf_slices_update(dev_priv, required_slices);
> +
> /*
>* Whenever the number of active pipes changes, we need to make sure we
>* update the pipes in the right order so that their ddb allocations
> @@ -12254,6 +12260,10 @@ static void skl_update_crtcs(struct drm_atomic_state
> *state)
> progress = true;
> }
> } while (progress);
> +
> + /* If 2nd DBuf slice is no more required disable it */
> + if (INTEL_GEN(dev_priv) >= 11 && required_slices < hw_enabled_slices)
> + icl_dbuf_slices_update(dev_priv, required_slices);
> }
>
> static void intel_atomic_helper_free_state(struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index d1452fd2a58d..13b9d9ce2c51 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -140,6 +140,10 @@
> #define KHz(x) (1000 * (x))
> #define MHz(x) KHz(1000 * (x))
>
> +#define KBps(x) (1000 * (x))
> +#define MBps(x) KBps(1000 * (x))
> +#define GBps(x) ((u64)1000 * MBps((x)))
> +
> /*
> * Display related stuff
> */
> @@ -1914,6 +1918,8 @@ bool intel_display_power_get_if_enabled(struct
> drm_i915_private *dev_priv,
> enum intel_display_power_domain domain);
> void intel_display_power_put(struct drm_i915_private *dev_priv,
>enum intel_display_power_domain domain);
> +void icl_dbuf_slices_update(struct drm_i915_private *dev_priv,
> + u8 req_slices);
>
> static inline void
> assert_rpm_device_not_suspended(struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 7341f4af3151..615a084736f3 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3771,9 +3771,42 @@ bool intel_can_enable_sagv(struct drm_atomic_state
> *state)
> return true;
> }
>
> +static unsigned int intel_get_ddb_size(struct drm_i915_private *dev_priv,
> +const struct intel_crtc_state *cstate,
> +const unsigned int total_data_rate,
> +const int num_active,
> +struct skl_ddb_allocation *ddb)
> +{
> + const struct drm_display_mode *adjusted_mode;
> + u64 total_data_bw;
> + u16 ddb_size = INTEL_INFO(dev_priv)->ddb_size;
> +
> + WARN_ON(ddb_size == 0);
> +
> + if (INTEL_GEN(dev_priv) < 11)
> +
