[Intel-gfx] [PATCH v2] drm/i915/perf: Wrap 64bit divides in do_div()
Just a couple of naked 64bit divides causing link errors on 32bit
builds, with:
ERROR: "__udivdi3" [drivers/gpu/drm/i915/i915.ko] undefined!
v2: do_div() is only u64/u32, we need a u32/u64!
Reported-by: kbuild test robot
Fixes: d79651522e89 ("drm/i915: Enable i915 perf stream for Haswell OA unit")
Signed-off-by: Chris Wilson
Cc: Robert Bragg
---
drivers/gpu/drm/i915/i915_perf.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 95512824922b..62685c14b726 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -974,8 +974,8 @@ static void i915_oa_stream_disable(struct i915_perf_stream
*stream)
static u64 oa_exponent_to_ns(struct drm_i915_private *dev_priv, int exponent)
{
- return 10ULL * (2ULL << exponent) /
- dev_priv->perf.oa.timestamp_frequency;
+ return div64_u64(10ULL * (2ULL << exponent),
+dev_priv->perf.oa.timestamp_frequency);
}
static const struct i915_perf_stream_ops i915_oa_stream_ops = {
@@ -1051,16 +1051,17 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
dev_priv->perf.oa.periodic = props->oa_periodic;
if (dev_priv->perf.oa.periodic) {
- u64 period_ns = oa_exponent_to_ns(dev_priv,
- props->oa_period_exponent);
+ u32 margin;
dev_priv->perf.oa.period_exponent = props->oa_period_exponent;
/* See comment for OA_TAIL_MARGIN_NSEC for details
* about this tail_margin...
*/
- dev_priv->perf.oa.tail_margin =
- ((OA_TAIL_MARGIN_NSEC / period_ns) + 1) * format_size;
+ margin = div_u64(OA_TAIL_MARGIN_NSEC,
+oa_exponent_to_ns(dev_priv,
+ props->oa_period_exponent));
+ dev_priv->perf.oa.tail_margin = (margin + 1) * format_size;
}
if (stream->ctx) {
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed
On Tue, Nov 22, 2016 at 05:15:59PM -0800, Manasi Navare wrote:
> On Mon, Nov 21, 2016 at 04:48:07PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 21, 2016 at 11:10:45AM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 21, 2016 at 09:42:57AM +, Chris Wilson wrote:
> > > > On Mon, Nov 21, 2016 at 10:38:20AM +0100, Daniel Vetter wrote:
> > > > > On Fri, Nov 18, 2016 at 09:44:49AM -0800, Manasi Navare wrote:
> > > > > > On Fri, Nov 18, 2016 at 06:21:21PM +0200, Ville Syrjälä wrote:
> > > > > > > On Fri, Nov 18, 2016 at 04:35:25PM +0100, Daniel Vetter wrote:
> > > > > > > > On Fri, Nov 18, 2016 at 05:28:54PM +0200, Ville Syrjälä wrote:
> > > > > > > > > On Fri, Nov 18, 2016 at 03:18:06PM +0100, Maarten Lankhorst
> > > > > > > > > wrote:
> > > > > > > > > > Op 18-11-16 om 15:11 schreef Ville Syrjälä:
> > > > > > > > > > > On Fri, Nov 18, 2016 at 02:50:52PM +0100, Maarten
> > > > > > > > > > > Lankhorst wrote:
> > > > > > > > > > >> Op 18-11-16 om 08:13 schreef Manasi Navare:
> > > > > > > > > > >>> CRTC state connector_changed needs to be set to true
> > > > > > > > > > >>> if connector link status property has changed. This
> > > > > > > > > > >>> will tell the
> > > > > > > > > > >>> driver to do a complete modeset due to change in
> > > > > > > > > > >>> connector property.
> > > > > > > > > > >>>
> > > > > > > > > > >>> Acked-by: Harry Wentland
> > > > > > > > > > >>> Acked-by: Tony Cheng
> > > > > > > > > > >>> Cc: dri-de...@lists.freedesktop.org
> > > > > > > > > > >>> Cc: Jani Nikula
> > > > > > > > > > >>> Cc: Daniel Vetter
> > > > > > > > > > >>> Cc: Ville Syrjala
> > > > > > > > > > >>> Signed-off-by: Manasi Navare
> > > > > > > > > > >>> ---
> > > > > > > > > > >>> drivers/gpu/drm/drm_atomic_helper.c | 7 +++
> > > > > > > > > > >>> 1 file changed, 7 insertions(+)
> > > > > > > > > > >>>
> > > > > > > > > > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > > > >>> b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > > > >>> index 0b16587..2125fd1 100644
> > > > > > > > > > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > > > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > > > >>> @@ -519,6 +519,13 @@ static int
> > > > > > > > > > >>> handle_conflicting_encoders(struct drm_atomic_state
> > > > > > > > > > >>> *state,
> > > > > > > > > > >>>
> > > > > > > > > > >>> connector_state);
> > > > > > > > > > >>> if (ret)
> > > > > > > > > > >>> return ret;
> > > > > > > > > > >>> +
> > > > > > > > > > >>> + if (connector->state->crtc) {
> > > > > > > > > > >>> + crtc_state =
> > > > > > > > > > >>> drm_atomic_get_existing_crtc_state(state,
> > > > > > > > > > >>> +
> > > > > > > > > > >>> connector->state->crtc);
> > > > > > > > > > >>> + if (connector->link_status ==
> > > > > > > > > > >>> DRM_MODE_LINK_STATUS_BAD)
> > > > > > > > > > >>> +
> > > > > > > > > > >>> crtc_state->connectors_changed = true;
> > > > > > > > > > >>> + }
> > > > > > > > > > >>> }
> > > > > > > > > > >>>
> > > > > > > > > > >>> /*
> > > > > > > > > > >> This will cause ordinary atomic commits that happen to
> > > > > > > > > > >> change connector flags to potentially fail with -EINVAL
> > > > > > > > > > >> if ALLOW_MODESET is not set.
> > > > > > > > > > >> For this reason I'm not sure this flag should be set
> > > > > > > > > > >> automatically by the kernel. Could we add add a retrain
> > > > > > > > > > >> link property instead, that
> > > > > > > > > > >> always return 0 when queried, but writing a 1 causing
> > > > > > > > > > >> connectors_changed to be set on bad link status?
> > > > > > > > > > > Or just check for allow_modeset before setting
> > > > > > > > > > > connectors_changed=true here?
> > > > > > > > > >
> > > > > > > > > > I don't think modesets should be done automatically like
> > > > > > > > > > that, even if ALLOW_MODESET is set a modeset may not be
> > > > > > > > > > expected by userspace.
> > > > > > > > >
> > > > > > > > > Presumably userspace would want a picture on the screen using
> > > > > > > > > any means
> > > > > > > > > if it said ALLOW_MODESET. So if it can't tolerate the modeset
> > > > > > > > > it should
> > > > > > > > > probably say as much?
> > > > > > > >
> > > > > > > > Yeah, agreed. Also, if the link is bad then we pretty much have
> > > > > > > > to do a
> > > > > > > > modeset to recover it, otherwise you'll be forever stuck with a
> > > > > > > > bad
> > > > > > > > screen.
> > > > > > > >
> > > > > > > > What we could try is to gate this of whether userspace touches
> > > > > > > > the mode
> > > > > > > > property on the corresponding CRTC. I.e. if that's touched
> > > > > > > > (even if it's
> > > > > > > > the same mode),
Re: [Intel-gfx] [PATCH] drm/i915: Move the release of PT page to the upper caller
It's also the style how CPU page table is managed... > From: Wang, Zhi A > Sent: Wednesday, November 23, 2016 3:37 PM > > Hi Chris, thanks for the reply! Without this patch, we have to do pattern > scan to identify > if the page is still being used as a PT page. :( It's complicated. > > Originally, all the guest shadow PPGTT pages will be set to write-protected > by HV. When > guest makes a change in its page table, it will be trapped by HV. > > For example: > Guest updates a PTE entry in a PTE PT page, then HV will be notified and > populate the > shadow PPGTT page table accordingly. Now let's say a PTE PT is empty (all > mappings are > pointing to scratch page) and will be freed in the newer kernel. If guest > freed the PT page > first, this page could be used by anyone while HV is still treating this page > as PT page, then > things goes wrong here. HV has to identify the page is not being used as PT > page anymore > at this time. > > While if the guest updated the upper level PT entry first, HV will know the > PTE PT page will > not be used as a page table page, and stop track that page at this time. Then > following > accesses to that page will not be trapped by HV and surely HV will not see > unrecognized > PT entry writing (this page may be used by other guy at this time.) > > Thanks, > Zhi. > > > -Original Message- > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > > Sent: Tuesday, November 22, 2016 10:38 PM > > To: Wang, Zhi A > > Cc: intel-gfx@lists.freedesktop.org; Winiarski, Michal; Thierry, Michel; > > Joonas > > Lahtinen; Zhenyu Wang; Lv, Zhiyuan > > Subject: Re: [PATCH] drm/i915: Move the release of PT page to the upper > > caller > > > > On Tue, Nov 22, 2016 at 09:29:40PM +0800, Zhi Wang wrote: > > > Hi guys: > > > Would you mind to have a quick review on this patch? :P The linux > > > guest under GVT-g couldn't boot up without this patch in the newer > > > kernel. > > > > > > Thanks, > > > Zhi. > > > > > > On 11/21/16 19:44, Zhi Wang wrote: > > > >a PT page will be released if it doesn't contain any meaningful > > > >mappings during PPGTT page table shrinking. The PT entry in the upper > > > >level will be set to a scratch entry. > > > > > > > >Normally this works nicely, but in virtualization world, the PPGTT > > > >page table is tracked by hypervisor. Releasing the PT page before > > > >modifying the upper level PT entry would cause extra efforts. > > > > > > > >As the tracked page has been returned to OS before losing track from > > > >hypervisor, it could be written in any pattern. Hypervisor has to > > > >recognize if a page is still being used as a PT page by validating > > > >these writing patterns. It's complicated. Better let the guest modify > > > >the PT entry in upper level PT first, then release the PT page. > > > > > > > >Cc: Michał Winiarski > > > >Cc: Michel Thierry > > > >Cc: Joonas Lahtinen > > > >Cc: Chris Wilson > > > >Cc: Zhenyu Wang > > > >Cc: Zhiyuan Lv > > > >Signed-off-by: Zhi Wang > > > > The original didn't make it to me, so I just assumed a list issue. > > > > For the record, I'd like to have some more detail on just when the hv is > > doing > > the page scanning. It makes it sound like you are actively scanning an idle > > range. > > > > Reviewed-by: Chris Wilson -Chris > > > > -- > > Chris Wilson, Intel Open Source Technology Centre > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] lib/debugobjects: Export for use in modules
On Tue, Nov 22, 2016 at 04:53:09PM -0800, Andrew Morton wrote: > On Tue, 22 Nov 2016 14:30:39 + Chris Wilson > wrote: > > > Drivers, or other modules, that use a mixture of objects (especially > > objects embedded within other objects) would like to take advantage of > > the debugobjects facilities to help catch misuse. Currently, the > > debugobjects interface is only available to builtin drivers and requires > > a set of EXPORT_SYMBOL_GPL for use by modules. > > You didn't tell me this (and you should have!) but I'm going to assume > that this patch is needed for current development so I have queued it for > inclusion in 4.9-rcX. As a general make-life-easier-for-everyone thing. A bit too obtuse, sorry. Indeed I am using the debugobjects in i915.ko to try and catch some invalid operations on embedded objects. The problem currently only presents itself across module unload so forcing i915 to be builtin is not an option. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Move the release of PT page to the upper caller
Hi Chris, thanks for the reply! Without this patch, we have to do pattern scan to identify if the page is still being used as a PT page. :( It's complicated. Originally, all the guest shadow PPGTT pages will be set to write-protected by HV. When guest makes a change in its page table, it will be trapped by HV. For example: Guest updates a PTE entry in a PTE PT page, then HV will be notified and populate the shadow PPGTT page table accordingly. Now let's say a PTE PT is empty (all mappings are pointing to scratch page) and will be freed in the newer kernel. If guest freed the PT page first, this page could be used by anyone while HV is still treating this page as PT page, then things goes wrong here. HV has to identify the page is not being used as PT page anymore at this time. While if the guest updated the upper level PT entry first, HV will know the PTE PT page will not be used as a page table page, and stop track that page at this time. Then following accesses to that page will not be trapped by HV and surely HV will not see unrecognized PT entry writing (this page may be used by other guy at this time.) Thanks, Zhi. > -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Tuesday, November 22, 2016 10:38 PM > To: Wang, Zhi A > Cc: intel-gfx@lists.freedesktop.org; Winiarski, Michal; Thierry, Michel; > Joonas > Lahtinen; Zhenyu Wang; Lv, Zhiyuan > Subject: Re: [PATCH] drm/i915: Move the release of PT page to the upper caller > > On Tue, Nov 22, 2016 at 09:29:40PM +0800, Zhi Wang wrote: > > Hi guys: > > Would you mind to have a quick review on this patch? :P The linux > > guest under GVT-g couldn't boot up without this patch in the newer > > kernel. > > > > Thanks, > > Zhi. > > > > On 11/21/16 19:44, Zhi Wang wrote: > > >a PT page will be released if it doesn't contain any meaningful > > >mappings during PPGTT page table shrinking. The PT entry in the upper > > >level will be set to a scratch entry. > > > > > >Normally this works nicely, but in virtualization world, the PPGTT > > >page table is tracked by hypervisor. Releasing the PT page before > > >modifying the upper level PT entry would cause extra efforts. > > > > > >As the tracked page has been returned to OS before losing track from > > >hypervisor, it could be written in any pattern. Hypervisor has to > > >recognize if a page is still being used as a PT page by validating > > >these writing patterns. It's complicated. Better let the guest modify > > >the PT entry in upper level PT first, then release the PT page. > > > > > >Cc: Michał Winiarski > > >Cc: Michel Thierry > > >Cc: Joonas Lahtinen > > >Cc: Chris Wilson > > >Cc: Zhenyu Wang > > >Cc: Zhiyuan Lv > > >Signed-off-by: Zhi Wang > > The original didn't make it to me, so I just assumed a list issue. > > For the record, I'd like to have some more detail on just when the hv is doing > the page scanning. It makes it sound like you are actively scanning an idle > range. > > Reviewed-by: Chris Wilson -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Move the release of PT page to the upper caller
Thanks Michał! Have a good day. :P On 11/22/16 22:39, Michał Winiarski wrote: On Mon, Nov 21, 2016 at 07:44:26PM +0800, Zhi Wang wrote: a PT page will be released if it doesn't contain any meaningful mappings during PPGTT page table shrinking. The PT entry in the upper level will be set to a scratch entry. Normally this works nicely, but in virtualization world, the PPGTT page table is tracked by hypervisor. Releasing the PT page before modifying the upper level PT entry would cause extra efforts. As the tracked page has been returned to OS before losing track from hypervisor, it could be written in any pattern. Hypervisor has to recognize if a page is still being used as a PT page by validating these writing patterns. It's complicated. Better let the guest modify the PT entry in upper level PT first, then release the PT page. Reviewed-by: Michał Winiarski -Michał Cc: Michał Winiarski Cc: Michel Thierry Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Zhenyu Wang Cc: Zhiyuan Lv Signed-off-by: Zhi Wang --- drivers/gpu/drm/i915/i915_gem_gtt.c | 18 +++--- 1 file changed, 7 insertions(+), 11 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/perf: Wrap 64bit divides in do_div()
> == Series Details == > > Series: drm/i915/perf: Wrap 64bit divides in do_div() > URL : https://patchwork.freedesktop.org/series/15769/ > State : warning > > == Summary == > > Series 15769v1 drm/i915/perf: Wrap 64bit divides in do_div() > https://patchwork.freedesktop.org/api/1.0/series/15769/revisions/1/mbo > x/ > > Test drv_module_reload_basic: > dmesg-warn -> PASS (fi-skl-6770hq) > pass -> DMESG-WARN (fi-ilk-650) https://bugs.freedesktop.org/show_bug.cgi?id=74102 ? > Test kms_pipe_crc_basic: > Subgroup nonblocking-crc-pipe-a: > dmesg-warn -> PASS (fi-ilk-650) > > fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 > fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 > fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 > fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 > fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 > fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 > fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 > fi-ilk-650 total:244 pass:190 dwarn:1 dfail:0 fail:0 skip:53 > fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 > fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 > fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 > fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 > fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 > fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 > fi-skl-6770hqtotal:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 > fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 > fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 > > b34f27e00c9a21d2078062da760e24fd4a620391 drm-intel-nightly: 2016y- > 11m-22d-17h-42m-39s UTC integration manifest > 97cba78 drm/i915/perf: Wrap 64bit divides in do_div() > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3085/ > ___ > 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/2] drm/i915: Make GPU pages movable
On Tue, 22 Nov 2016, Matthew Auld wrote: > On 9 November 2016 at 18:36, Hugh Dickins wrote: > > On Wed, 9 Nov 2016, Daniel Vetter wrote: > >> > >> Hi all -mm folks! > >> > >> Any feedback on these two? It's kinda an intermediate step towards a > >> full-blown gemfs, and I think useful for that. Or do we need to go > >> directly to our own backing storage thing? Aside from ack/nack from -mm I > >> think this is ready for merging. > > > > I'm currently considering them at last: will report back later. > > > > Full-blown gemfs does not come in here, of course; but let me > > fire a warning shot since you mention it: if it's going to use swap, > > then we shall probably have to nak it in favour of continuing to use > > infrastructure from mm/shmem.c. I very much understand why you would > > love to avoid that dependence, but I doubt it can be safely bypassed. > > Could you please elaborate on what specifically you don't like about > gemfs implementing swap, just to make sure I'm following? If we're talking about swap as implemented in mm/swapfile.c, and managed for tmpfs mainly through shmem_getpage_gfp(): that's slippery stuff, private to mm, and I would not want such trickiness duplicated somewhere down in drivers/gpu/drm, where mm developers and drm developers will keep on forgetting to keep it working correctly. But you write of gemfs "implementing" swap (and I see Daniel wrote of "our own backing storage"): perhaps you intend a disk or slow-mem file of your own, dedicated to paging gemfs objects according to your own rules, poked from memory reclaim via a shrinker. I certainly don't have the same quick objection to that: it may be a good way forward, though I'm not at all sure (and would prefer a name distinct from swap, so we wouldn't get confused - maybe gemswap). Hugh ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/lspcon: Wait for expected LSPCON mode to settle
R-B: Shashank Sharma
Regards
Shashank
-Original Message-
From: Deak, Imre
Sent: Tuesday, November 22, 2016 9:47 PM
To: Sharma, Shashank ;
intel-gfx@lists.freedesktop.org
Cc: Ville Syrjälä ; Nikula, Jani
Subject: Re: [PATCH 3/4] drm/i915/lspcon: Wait for expected LSPCON mode to
settle
On Tue, 2016-11-22 at 21:06 +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 11/22/2016 12:45 AM, Imre Deak wrote:
> > Some LSPCON adaptors may return an incorrect LSPCON mode right after
> > waking from DP Sleep state. This is the case at least for the
> > ParadTech
> > PS175 adaptor, both when waking because of exiting the DP Sleep to
> > active state, or due to any other AUX CH transfer. We can determine
> > the current expected mode based on whether the DPCD area is
> > accessible, since according to the LSPCON spec this area is only
> > accesible in PCON mode.
> >
> > This wait will avoid us trying to change the mode, while the current
> > expected mode hasn't settled yet and start link training before the
> > adaptor thinks it's in PCON mode after waking from DP Sleep state.
> >
> > Cc: Shashank Sharma
> > Cc: Ville Syrjälä
> > Cc: Jani Nikula
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 5 +++
> > drivers/gpu/drm/i915/intel_drv.h| 1 +
> > drivers/gpu/drm/i915/intel_lspcon.c | 70
> > -
> > 3 files changed, 68 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c index 16c19d78..8026a83 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -2401,6 +2401,8 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp,
> > int mode)
> > ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER,
> > DP_SET_POWER_D3);
> > } else {
> > + struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> > +
> > /*
> > * When turning on, we need to retry for 1ms to give the sink
> > * time to wake up.
> > @@ -2412,6 +2414,9 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp,
> > int mode)
> > break;
> > msleep(1);
> > }
> > +
> > + if (ret == 1 && lspcon->active)
> > + lspcon_wait_pcon_mode(lspcon);
> > }
> >
> > if (ret != 1)
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index cf47e8a..d165904 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1830,4 +1830,5 @@ void intel_color_load_luts(struct
> > drm_crtc_state *crtc_state);
> > /* intel_lspcon.c */
> > bool lspcon_init(struct intel_digital_port *intel_dig_port);
> > void lspcon_resume(struct intel_lspcon *lspcon);
> > +void lspcon_wait_pcon_mode(struct intel_lspcon *lspcon);
> > #endif /* __INTEL_DRV_H__ */
> > diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
> > b/drivers/gpu/drm/i915/intel_lspcon.c
> > index 5013124..281127d 100644
> > --- a/drivers/gpu/drm/i915/intel_lspcon.c
> > +++ b/drivers/gpu/drm/i915/intel_lspcon.c
> > @@ -35,16 +35,54 @@ static struct intel_dp *lspcon_to_intel_dp(struct
> > intel_lspcon *lspcon)
> > return &dig_port->dp;
> > }
> >
> > +static const char *lspcon_mode_name(enum drm_lspcon_mode mode) {
> > + switch (mode) {
> > + case DRM_LSPCON_MODE_PCON:
> > + return "PCON";
> > + case DRM_LSPCON_MODE_LS:
> > + return "LS";
> > + case DRM_LSPCON_MODE_INVALID:
> > + return "INVALID";
> > + default:
> > + MISSING_CASE(mode);
> > + return "INVALID";
> > + }
> > +}
> > +
> > static enum drm_lspcon_mode lspcon_get_current_mode(struct
> > intel_lspcon *lspcon)
> > {
> > - enum drm_lspcon_mode current_mode = DRM_LSPCON_MODE_INVALID;
> > + enum drm_lspcon_mode current_mode;
> > struct i2c_adapter *adapter =
> > &lspcon_to_intel_dp(lspcon)->aux.ddc;
> >
> > - if (drm_lspcon_get_mode(adapter, ¤t_mode))
> > + if (drm_lspcon_get_mode(adapter, ¤t_mode)) {
> > DRM_ERROR("Error reading LSPCON mode\n");
> > - else
> > - DRM_DEBUG_KMS("Current LSPCON mode %s\n",
> > - current_mode == DRM_LSPCON_MODE_PCON ? "PCON" : "LS");
> > + return DRM_LSPCON_MODE_INVALID;
> > + }
> > + return current_mode;
> > +}
> > +
> > +static enum drm_lspcon_mode lspcon_wait_mode(struct intel_lspcon *lspcon,
> > + enum drm_lspcon_mode mode) {
> > + enum drm_lspcon_mode current_mode;
> > +
> > + current_mode = lspcon_get_current_mode(lspcon);
> > + if (current_mode == mode || current_mode == DRM_LSPCON_MODE_INVALID)
> > + goto out;
> > +
> > + DRM_DEBUG_KMS("Waiting for LSPCON mode %s to settle\n",
> > + lspcon_mode_name(mode));
> > +
> Can we remove
Re: [Intel-gfx] [PATCH] drm/i915: Move the release of PT page to the upper caller
On 2016.11.22 14:38:19 +, Chris Wilson wrote: > On Tue, Nov 22, 2016 at 09:29:40PM +0800, Zhi Wang wrote: > > Hi guys: > > Would you mind to have a quick review on this patch? :P The > > linux guest under GVT-g couldn't boot up without this patch in the > > newer kernel. > > > > Thanks, > > Zhi. > > > > On 11/21/16 19:44, Zhi Wang wrote: > > >a PT page will be released if it doesn't contain any meaningful mappings > > >during PPGTT page table shrinking. The PT entry in the upper level will > > >be set to a scratch entry. > > > > > >Normally this works nicely, but in virtualization world, the PPGTT page > > >table is tracked by hypervisor. Releasing the PT page before modifying > > >the upper level PT entry would cause extra efforts. > > > > > >As the tracked page has been returned to OS before losing track from > > >hypervisor, it could be written in any pattern. Hypervisor has to recognize > > >if a page is still being used as a PT page by validating these writing > > >patterns. It's complicated. Better let the guest modify the PT entry in > > >upper level PT first, then release the PT page. > > > > > >Cc: Michał Winiarski > > >Cc: Michel Thierry > > >Cc: Joonas Lahtinen > > >Cc: Chris Wilson > > >Cc: Zhenyu Wang > > >Cc: Zhiyuan Lv > > >Signed-off-by: Zhi Wang > > The original didn't make it to me, so I just assumed a list issue. > > For the record, I'd like to have some more detail on just when the hv is > doing the page scanning. It makes it sound like you are actively > scanning an idle range. > > Reviewed-by: Chris Wilson Note that this should be queued for 4.9 fix otherwise 4.9 will be broken as guest kernel version for GVT-g. Thanks -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RFC] drm: Add a new connector atomic property for link status
On Tue, Nov 22, 2016 at 8:30 PM, Manasi Navare
wrote:
> This is RFC patch for adding a connector link-status property
> and making it atomic by adding it to the drm_connector_state.
> This is to make sure its wired properly in drm_atomic_connector_set_property
> and drm_atomic_connector_get_property functions.
>
Thanks for sending this. We ran into some re-training awkwardness
recently, and I
was hoping for such a patch.
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Ville Syrjala
> Cc: Chris Wilson
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/drm_atomic.c| 5
> drivers/gpu/drm/drm_connector.c | 65
> +++--
> include/drm/drm_connector.h | 12 +++-
> include/drm/drm_mode_config.h | 5
> include/uapi/drm/drm_mode.h | 4 +++
> 5 files changed, 88 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 89737e4..644d19f 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1087,6 +1087,9 @@ int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> * now?) atomic writes to DPMS property:
> */
> return -EINVAL;
> + } else if (property == config->link_status_property) {
> + state->link_status = val;
> + return 0;
> } else if (connector->funcs->atomic_set_property) {
> return connector->funcs->atomic_set_property(connector,
> state, property, val);
> @@ -1135,6 +1138,8 @@ static void drm_atomic_connector_print_state(struct
> drm_printer *p,
> *val = (state->crtc) ? state->crtc->base.id : 0;
> } else if (property == config->dpms_property) {
> *val = connector->dpms;
> + } else if (property == config->link_status_property) {
> + *val = state->link_status;
> } else if (connector->funcs->atomic_get_property) {
> return connector->funcs->atomic_get_property(connector,
> state, property, val);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 5a45262..4576c9f 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
> drm_object_attach_property(&connector->base,
> config->dpms_property, 0);
>
> + drm_object_attach_property(&connector->base,
> + config->link_status_property,
> + 0);
> +
> if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
> drm_object_attach_property(&connector->base,
> config->prop_crtc_id, 0);
> }
> @@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum
> subpixel_order order)
> };
> DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
>
> +static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
> + { DRM_MODE_LINK_STATUS_GOOD, "Good" },
> + { DRM_MODE_LINK_STATUS_BAD, "Bad" },
> +};
> +DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
> +
> /**
> * drm_display_info_set_bus_formats - set the supported bus formats
> * @info: display info to store bus formats in
> @@ -616,7 +626,7 @@ int drm_display_info_set_bus_formats(struct
> drm_display_info *info,
> * path property the MST manager created. Userspace cannot change this
> * property.
> * TILE:
> - * Connector tile group property to indicate how a set of DRM connector
> + * Connector tile group property to indicate how a set of DRM connector
keyboard slip here
> * compose together into one logical screen. This is used by both
> high-res
> * external screens (often only using a single cable, but exposing
> multiple
> * DP MST sinks), or high-res integrated panels (like dual-link DSI)
> which
> @@ -625,7 +635,14 @@ int drm_display_info_set_bus_formats(struct
> drm_display_info *info,
> * tiling and virtualize both &drm_crtc and &drm_plane if needed. Drivers
> * should update this value using drm_mode_connector_set_tile_property().
> * Userspace cannot change this property.
> - *
> + * link-status:
> + * Connector link-status property to indicate the status of link during
> + * the modeset. The default value of link-status is "GOOD". If something
> + * fails during modeset, the kernel driver can set this to "BAD", prune
> + * the mode list based on new link parameters and send a hotplug uevent
> + * to notify userspace to re-check the valid modes through GET_CONNECTOR
> + * IOCTL and redo a modeset. Drivers should update this value using
> + * drm_mode_connector_set_link_status_property().
> * Connectors also have one standardized atomic property:
> *
> * CRT
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: Add a new connector atomic property for link status
== Series Details == Series: drm: Add a new connector atomic property for link status URL : https://patchwork.freedesktop.org/series/15781/ State : warning == Summary == Series 15781v1 drm: Add a new connector atomic property for link status https://patchwork.freedesktop.org/api/1.0/series/15781/revisions/1/mbox/ Test drv_module_reload_basic: dmesg-warn -> PASS (fi-skl-6770hq) Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-b: pass -> DMESG-WARN (fi-ilk-650) Subgroup nonblocking-crc-pipe-a: dmesg-warn -> PASS (fi-ilk-650) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:190 dwarn:1 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 b34f27e00c9a21d2078062da760e24fd4a620391 drm-intel-nightly: 2016y-11m-22d-17h-42m-39s UTC integration manifest 09b9c0a drm: Add a new connector atomic property for link status == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3087/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RFC] drm: Add a new connector atomic property for link status
This is RFC patch for adding a connector link-status property
and making it atomic by adding it to the drm_connector_state.
This is to make sure its wired properly in drm_atomic_connector_set_property
and drm_atomic_connector_get_property functions.
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
Cc: Chris Wilson
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/drm_atomic.c| 5
drivers/gpu/drm/drm_connector.c | 65 +++--
include/drm/drm_connector.h | 12 +++-
include/drm/drm_mode_config.h | 5
include/uapi/drm/drm_mode.h | 4 +++
5 files changed, 88 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 89737e4..644d19f 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1087,6 +1087,9 @@ int drm_atomic_connector_set_property(struct
drm_connector *connector,
* now?) atomic writes to DPMS property:
*/
return -EINVAL;
+ } else if (property == config->link_status_property) {
+ state->link_status = val;
+ return 0;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -1135,6 +1138,8 @@ static void drm_atomic_connector_print_state(struct
drm_printer *p,
*val = (state->crtc) ? state->crtc->base.id : 0;
} else if (property == config->dpms_property) {
*val = connector->dpms;
+ } else if (property == config->link_status_property) {
+ *val = state->link_status;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 5a45262..4576c9f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
drm_object_attach_property(&connector->base,
config->dpms_property, 0);
+ drm_object_attach_property(&connector->base,
+ config->link_status_property,
+ 0);
+
if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
drm_object_attach_property(&connector->base,
config->prop_crtc_id, 0);
}
@@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum
subpixel_order order)
};
DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
+static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
+ { DRM_MODE_LINK_STATUS_GOOD, "Good" },
+ { DRM_MODE_LINK_STATUS_BAD, "Bad" },
+};
+DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
+
/**
* drm_display_info_set_bus_formats - set the supported bus formats
* @info: display info to store bus formats in
@@ -616,7 +626,7 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
* path property the MST manager created. Userspace cannot change this
* property.
* TILE:
- * Connector tile group property to indicate how a set of DRM connector
+ * Connector tile group property to indicate how a set of DRM connector
* compose together into one logical screen. This is used by both high-res
* external screens (often only using a single cable, but exposing multiple
* DP MST sinks), or high-res integrated panels (like dual-link DSI) which
@@ -625,7 +635,14 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
* tiling and virtualize both &drm_crtc and &drm_plane if needed. Drivers
* should update this value using drm_mode_connector_set_tile_property().
* Userspace cannot change this property.
- *
+ * link-status:
+ * Connector link-status property to indicate the status of link during
+ * the modeset. The default value of link-status is "GOOD". If something
+ * fails during modeset, the kernel driver can set this to "BAD", prune
+ * the mode list based on new link parameters and send a hotplug uevent
+ * to notify userspace to re-check the valid modes through GET_CONNECTOR
+ * IOCTL and redo a modeset. Drivers should update this value using
+ * drm_mode_connector_set_link_status_property().
* Connectors also have one standardized atomic property:
*
* CRTC_ID:
@@ -666,6 +683,13 @@ int drm_connector_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.tile_property = prop;
+ prop = drm_property_create_enum(dev, DRM_MODE_PROP_ATOMIC,
"link-status",
+ drm_link_status_enum_list,
+ ARRAY_SIZE(drm_link_status_
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed
On Mon, Nov 21, 2016 at 04:48:07PM +0100, Daniel Vetter wrote:
> On Mon, Nov 21, 2016 at 11:10:45AM +0100, Daniel Vetter wrote:
> > On Mon, Nov 21, 2016 at 09:42:57AM +, Chris Wilson wrote:
> > > On Mon, Nov 21, 2016 at 10:38:20AM +0100, Daniel Vetter wrote:
> > > > On Fri, Nov 18, 2016 at 09:44:49AM -0800, Manasi Navare wrote:
> > > > > On Fri, Nov 18, 2016 at 06:21:21PM +0200, Ville Syrjälä wrote:
> > > > > > On Fri, Nov 18, 2016 at 04:35:25PM +0100, Daniel Vetter wrote:
> > > > > > > On Fri, Nov 18, 2016 at 05:28:54PM +0200, Ville Syrjälä wrote:
> > > > > > > > On Fri, Nov 18, 2016 at 03:18:06PM +0100, Maarten Lankhorst
> > > > > > > > wrote:
> > > > > > > > > Op 18-11-16 om 15:11 schreef Ville Syrjälä:
> > > > > > > > > > On Fri, Nov 18, 2016 at 02:50:52PM +0100, Maarten Lankhorst
> > > > > > > > > > wrote:
> > > > > > > > > >> Op 18-11-16 om 08:13 schreef Manasi Navare:
> > > > > > > > > >>> CRTC state connector_changed needs to be set to true
> > > > > > > > > >>> if connector link status property has changed. This will
> > > > > > > > > >>> tell the
> > > > > > > > > >>> driver to do a complete modeset due to change in
> > > > > > > > > >>> connector property.
> > > > > > > > > >>>
> > > > > > > > > >>> Acked-by: Harry Wentland
> > > > > > > > > >>> Acked-by: Tony Cheng
> > > > > > > > > >>> Cc: dri-de...@lists.freedesktop.org
> > > > > > > > > >>> Cc: Jani Nikula
> > > > > > > > > >>> Cc: Daniel Vetter
> > > > > > > > > >>> Cc: Ville Syrjala
> > > > > > > > > >>> Signed-off-by: Manasi Navare
> > > > > > > > > >>> ---
> > > > > > > > > >>> drivers/gpu/drm/drm_atomic_helper.c | 7 +++
> > > > > > > > > >>> 1 file changed, 7 insertions(+)
> > > > > > > > > >>>
> > > > > > > > > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > > >>> b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > > >>> index 0b16587..2125fd1 100644
> > > > > > > > > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > > >>> @@ -519,6 +519,13 @@ static int
> > > > > > > > > >>> handle_conflicting_encoders(struct drm_atomic_state
> > > > > > > > > >>> *state,
> > > > > > > > > >>> connector_state);
> > > > > > > > > >>> if (ret)
> > > > > > > > > >>> return ret;
> > > > > > > > > >>> +
> > > > > > > > > >>> + if (connector->state->crtc) {
> > > > > > > > > >>> + crtc_state =
> > > > > > > > > >>> drm_atomic_get_existing_crtc_state(state,
> > > > > > > > > >>> +
> > > > > > > > > >>> connector->state->crtc);
> > > > > > > > > >>> + if (connector->link_status ==
> > > > > > > > > >>> DRM_MODE_LINK_STATUS_BAD)
> > > > > > > > > >>> + crtc_state->connectors_changed
> > > > > > > > > >>> = true;
> > > > > > > > > >>> + }
> > > > > > > > > >>> }
> > > > > > > > > >>>
> > > > > > > > > >>> /*
> > > > > > > > > >> This will cause ordinary atomic commits that happen to
> > > > > > > > > >> change connector flags to potentially fail with -EINVAL if
> > > > > > > > > >> ALLOW_MODESET is not set.
> > > > > > > > > >> For this reason I'm not sure this flag should be set
> > > > > > > > > >> automatically by the kernel. Could we add add a retrain
> > > > > > > > > >> link property instead, that
> > > > > > > > > >> always return 0 when queried, but writing a 1 causing
> > > > > > > > > >> connectors_changed to be set on bad link status?
> > > > > > > > > > Or just check for allow_modeset before setting
> > > > > > > > > > connectors_changed=true here?
> > > > > > > > >
> > > > > > > > > I don't think modesets should be done automatically like
> > > > > > > > > that, even if ALLOW_MODESET is set a modeset may not be
> > > > > > > > > expected by userspace.
> > > > > > > >
> > > > > > > > Presumably userspace would want a picture on the screen using
> > > > > > > > any means
> > > > > > > > if it said ALLOW_MODESET. So if it can't tolerate the modeset
> > > > > > > > it should
> > > > > > > > probably say as much?
> > > > > > >
> > > > > > > Yeah, agreed. Also, if the link is bad then we pretty much have
> > > > > > > to do a
> > > > > > > modeset to recover it, otherwise you'll be forever stuck with a
> > > > > > > bad
> > > > > > > screen.
> > > > > > >
> > > > > > > What we could try is to gate this of whether userspace touches
> > > > > > > the mode
> > > > > > > property on the corresponding CRTC. I.e. if that's touched (even
> > > > > > > if it's
> > > > > > > the same mode), and a link is bad in one of the connectors in the
> > > > > > > state
> > > > > > > then we do a full modeset to recover.
> > > > > > >
> > > > > > > Another option would be to make the link status writeable. Trying
> > > > > > > to
> > > > > > > change it from bad->good would force the modeset. That would be
> > > > > > > 1
Re: [Intel-gfx] [PATCH] lib/debugobjects: Export for use in modules
On Tue, 22 Nov 2016 14:30:39 + Chris Wilson wrote: > Drivers, or other modules, that use a mixture of objects (especially > objects embedded within other objects) would like to take advantage of > the debugobjects facilities to help catch misuse. Currently, the > debugobjects interface is only available to builtin drivers and requires > a set of EXPORT_SYMBOL_GPL for use by modules. You didn't tell me this (and you should have!) but I'm going to assume that this patch is needed for current development so I have queued it for inclusion in 4.9-rcX. As a general make-life-easier-for-everyone thing. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: Wrap 64bit divides in do_div()
On Tue, Nov 22, 2016 at 11:32:38PM +, Robert Bragg wrote: >Thanks for sending out. It looked good to me, but testing shows a 'divide >error'. > >I haven't double checked, but I think it's because the max OA exponent >(31) converted to nanoseconds is > UINT32_MAX with the lower 32bits zero >and the do_div denominator argument is only 32bit. Hmm, I thought do_div() was u64 / u64, but no it is u64 / u32. Looks like the appropriate function would be div64_u64(). >It corresponds to a 5 minute period which is a bit silly, so we could >reduce the max exponent. A period of UINT32_MAX is about 4 seconds where I >can't currently think of a good use case for such a low frequency. > >Instead of changing the max OA exponent (where the relationship to the >period changes for gen9 and may become fuzzy if we start training our view >of the gpu timestamp frequency instead of using constants) maybe we should >set an early limit on an exponent resulting in a period > UINT32_MAX? Seems like picking the right function would help! -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: Wrap 64bit divides in do_div()
Thanks for sending out. It looked good to me, but testing shows a 'divide
error'.
I haven't double checked, but I think it's because the max OA exponent (31)
converted to nanoseconds is > UINT32_MAX with the lower 32bits zero and the
do_div denominator argument is only 32bit.
It corresponds to a 5 minute period which is a bit silly, so we could
reduce the max exponent. A period of UINT32_MAX is about 4 seconds where I
can't currently think of a good use case for such a low frequency.
Instead of changing the max OA exponent (where the relationship to the
period changes for gen9 and may become fuzzy if we start training our view
of the gpu timestamp frequency instead of using constants) maybe we should
set an early limit on an exponent resulting in a period > UINT32_MAX?
- Robert
On Tue, Nov 22, 2016 at 9:14 PM, Chris Wilson
wrote:
> Just a couple of naked 64bit divides causing link errors on 32bit
> builds, with:
>
> ERROR: "__udivdi3" [drivers/gpu/drm/i915/i915.ko] undefined!
>
> Reported-by: kbuild test robot
> Fixes: d79651522e89 ("drm/i915: Enable i915 perf stream for Haswell OA
> unit")
> Signed-off-by: Chris Wilson
> Cc: Robert Bragg
> ---
> drivers/gpu/drm/i915/i915_perf.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> index 95512824922b..7d00532ae010 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -974,8 +974,12 @@ static void i915_oa_stream_disable(struct
> i915_perf_stream *stream)
>
> static u64 oa_exponent_to_ns(struct drm_i915_private *dev_priv, int
> exponent)
> {
> - return 10ULL * (2ULL << exponent) /
> - dev_priv->perf.oa.timestamp_frequency;
> + u64 interval;
> +
> + interval = 10ULL * (2ULL << exponent);
> + do_div(interval, dev_priv->perf.oa.timestamp_frequency);
> +
> + return interval;
> }
>
> static const struct i915_perf_stream_ops i915_oa_stream_ops = {
> @@ -1051,16 +1055,17 @@ static int i915_oa_stream_init(struct
> i915_perf_stream *stream,
>
> dev_priv->perf.oa.periodic = props->oa_periodic;
> if (dev_priv->perf.oa.periodic) {
> - u64 period_ns = oa_exponent_to_ns(dev_priv,
> -
> props->oa_period_exponent);
> + u64 margin;
>
> dev_priv->perf.oa.period_exponent =
> props->oa_period_exponent;
>
> /* See comment for OA_TAIL_MARGIN_NSEC for details
> * about this tail_margin...
> */
> - dev_priv->perf.oa.tail_margin =
> - ((OA_TAIL_MARGIN_NSEC / period_ns) + 1) *
> format_size;
> + margin = OA_TAIL_MARGIN_NSEC;
> + do_div(margin,
> + oa_exponent_to_ns(dev_priv,
> props->oa_period_exponent));
> + dev_priv->perf.oa.tail_margin = (margin + 1) * format_size;
> }
>
> if (stream->ctx) {
> --
> 2.10.2
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Add Automation support for DP compliance testing
== Series Details == Series: Add Automation support for DP compliance testing URL : https://patchwork.freedesktop.org/series/15771/ State : success == Summary == Series 15771v1 Add Automation support for DP compliance testing https://patchwork.freedesktop.org/api/1.0/series/15771/revisions/1/mbox/ Test drv_module_reload_basic: dmesg-warn -> PASS (fi-skl-6770hq) Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-a: dmesg-warn -> PASS (fi-ilk-650) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 b34f27e00c9a21d2078062da760e24fd4a620391 drm-intel-nightly: 2016y-11m-22d-17h-42m-39s UTC integration manifest 22114a2 drm/i915: Add support for DP Video pattern compliance tests a2621e2 drm: Add definitions for DP compliance Video pattern tests 9309922 Add support for forcing 6 bpc on DP pipes. 69f7478 drm/i915: Fixes to support DP Compliance EDID tests b8ca49e drm/i915: Add support for DP link training compliance == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3086/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/perf: Wrap 64bit divides in do_div()
== Series Details == Series: drm/i915/perf: Wrap 64bit divides in do_div() URL : https://patchwork.freedesktop.org/series/15769/ State : warning == Summary == Series 15769v1 drm/i915/perf: Wrap 64bit divides in do_div() https://patchwork.freedesktop.org/api/1.0/series/15769/revisions/1/mbox/ Test drv_module_reload_basic: dmesg-warn -> PASS (fi-skl-6770hq) pass -> DMESG-WARN (fi-ilk-650) Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-a: dmesg-warn -> PASS (fi-ilk-650) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:190 dwarn:1 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 b34f27e00c9a21d2078062da760e24fd4a620391 drm-intel-nightly: 2016y-11m-22d-17h-42m-39s UTC integration manifest 97cba78 drm/i915/perf: Wrap 64bit divides in do_div() == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3085/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] Add support for forcing 6 bpc on DP pipes.
From: Jim Bride
For DP compliance we need to be able to control the output color
type for the pipe associated with the DP port. When a specific DP
compliance test is requested with specific BPC value, we read the BPC
value from the DPCD register and store it in the intel_dp structure.
If this BPC value in intel_dp structure has a non-zero value
and we're on a display port connector, then we use the value to
calculate the bpp for the pipe. For cases where we are
not on DP or there has not been an overridden value then we behave
as normal.
Signed-off-by: Jim Bride
Signed-off-by: Manasi Navare
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
---
drivers/gpu/drm/i915/intel_display.c | 4 +++-
drivers/gpu/drm/i915/intel_dp.c | 10 ++
drivers/gpu/drm/i915/intel_dp_mst.c | 11 +--
drivers/gpu/drm/i915/intel_drv.h | 1 +
4 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b7a7ed8..bb1cca2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12694,11 +12694,13 @@ static void
intel_modeset_update_connector_atomic_state(struct drm_device *dev)
/* Clamp display bpp to EDID value */
for_each_connector_in_state(state, connector, connector_state, i) {
+
if (connector_state->crtc != &crtc->base)
continue;
connected_sink_compute_bpp(to_intel_connector(connector),
- pipe_config);
+ pipe_config);
+
}
return bpp;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6693918..f93e130 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1549,6 +1549,13 @@ static int intel_dp_compute_bpp(struct intel_dp
*intel_dp,
if (bpc > 0)
bpp = min(bpp, 3*bpc);
+ /* For DP Compliance we override the computed bpp for the pipe */
+ if (intel_dp->compliance_force_bpc != 0) {
+ pipe_config->pipe_bpp = intel_dp->compliance_force_bpc*3;
+ DRM_DEBUG_KMS("Setting pipe_bpp to %d\n",
+ pipe_config->pipe_bpp);
+ }
+
return bpp;
}
@@ -1629,6 +1636,7 @@ static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
/* 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 (is_edp(intel_dp)) {
/* Get bpp from vbt only for panels that dont have bpp in edid
*/
@@ -4109,6 +4117,7 @@ static void intel_dp_handle_test_request(struct intel_dp
*intel_dp)
intel_dp->compliance_test_data = 0;
intel_dp->compliance_test_lane_count = 0;
intel_dp->compliance_test_link_rate = 0;
+ intel_dp->compliance_force_bpc = 0;
/*
* Now read the DPCD to see if it's actually running
@@ -4434,6 +4443,7 @@ static bool intel_digital_port_connected(struct
drm_i915_private *dev_priv,
intel_dp->compliance_test_active = 0;
intel_dp->compliance_test_type = 0;
intel_dp->compliance_test_data = 0;
+ intel_dp->compliance_force_bpc = 0;
intel_dp->compliance_test_lane_count = 0;
intel_dp->compliance_test_link_rate = 0;
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index b029d10..940f173 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -45,6 +45,14 @@ static bool intel_dp_mst_compute_config(struct intel_encoder
*encoder,
pipe_config->has_pch_encoder = false;
bpp = 24;
+ /* For DP Compliance we need to ensurethat we can override
+* the computed bpp for the pipe
+*/
+ if (intel_dp->compliance_force_bpc) {
+ bpp = intel_dp->compliance_force_bpc * 3;
+ DRM_DEBUG_KMS("Setting pipe bpp to %d\n",
+ bpp);
+ }
/*
* for MST we always configure max link bw - the spec doesn't
* seem to suggest we should do otherwise.
@@ -52,8 +60,7 @@ static bool intel_dp_mst_compute_config(struct intel_encoder
*encoder,
lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
pipe_config->lane_count = lane_count;
-
- pipe_config->pipe_bpp = 24;
+ pipe_config->pipe_bpp = bpp;
pipe_config->port_clock = intel_dp_max_link_rate(intel_dp);
state = pipe_config->base.state;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1e88288..3eb428e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -960,6 +960,7 @@ struct intel_dp {
bool compliance_test_active;
u8 compliance_tes
[Intel-gfx] [PATCH 4/5] drm: Add definitions for DP compliance Video pattern tests
Cc: dri-de...@lists.freedesktop.org Cc: Jani Nikula Cc: Daniel Vetter Cc: Ville Syrjala Signed-off-by: Manasi Navare --- include/drm/drm_dp_helper.h | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 55bbeb0..f2c04ec 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -415,7 +415,21 @@ #define DP_TEST_LANE_COUNT 0x220 -#define DP_TEST_PATTERN0x221 +#define DP_TEST_PATTERN0x221 +#define DP_COLOR_RAMP (1 << 0) +#define DP_TEST_H_WIDTH0x22E +#define DP_TEST_V_HEIGHT 0x230 +#define DP_TEST_MISC 0x232 +#define DP_VIDEO_PATTERN_RGB_FORMAT0 +#define DP_TEST_COLOR_FORMAT_MASK 0x6 +#define DP_TEST_DYNAMIC_RANGE_MASK (1 << 3) +#define DP_VIDEO_PATTERN_VESA 0 +#define DP_TEST_BIT_DEPTH_MASK 0x00E0 +#define DP_TEST_BIT_DEPTH_60 +#define DP_TEST_BIT_DEPTH_81 +#define DP_TEST_MISC_BIT_1 1 +#define DP_TEST_MISC_BIT_3 3 +#define DP_TEST_MISC_BIT_5 5 #define DP_TEST_CRC_R_CR 0x240 #define DP_TEST_CRC_G_Y0x242 -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/5] Add Automation support for DP compliance testing
DP 1.2 compliance testing can be acheived using DPR-120's CTS suite. This compliance unit sends a short pulse to initiate link training and video pattern generation compliance tests and sends a long pulse to initate EDID compliance tests. It also sets the AUTOMATED TEST REQUEST bit in Device IRQ to 1. These patches add support in the kernel to respond to these test requests sent by DPR-120. The test handler has been added for Link training/EDID and Video pattern compliance tests that gets invoked on short/long pulse sent by DPR-120. The test handler for each of the tests reads the corresponding DPCD registers to read the test parameters. These tests need to be run with the IGT DP compliance automation tool. Link Training Tests (4.3.1.1 - 4.3.2.3): It reads the DPCD registers to get the link rate and lane count requested by test and sends a hotplug uevent for the userspace to redo a modeset in order to train the link at the requested test parameters. EDID Tests (4.2.2.3 - 4.2.2.6): It reads the EDID set by the DPR-120, if EDID read succeeds, it sets the video mode to PREFERRED and sets the test_active flag. This flag wakes up the IGT compliance tool that then fills the framebuffers and triggers a modeset. Video Pattern Tests (4.3.3.1): It reads the DPCD registers to set the requested video pattern parameters. It then sets the test active flag that wakes up the IGT tool, userspace reads the video pattern values from corresponding debugfs files and fills the framebuffers and triggers a modeset. Jim Bride (1): Add support for forcing 6 bpc on DP pipes. Manasi Navare (4): drm/i915: Add support for DP link training compliance drm/i915: Fixes to support DP Compliance EDID tests drm: Add definitions for DP compliance Video pattern tests drm/i915: Add support for DP Video pattern compliance tests drivers/gpu/drm/i915/i915_debugfs.c | 14 +++- drivers/gpu/drm/i915/intel_display.c | 4 +- drivers/gpu/drm/i915/intel_dp.c | 155 +-- drivers/gpu/drm/i915/intel_dp_mst.c | 11 ++- drivers/gpu/drm/i915/intel_drv.h | 12 +++ include/drm/drm_dp_helper.h | 16 +++- 6 files changed, 199 insertions(+), 13 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: Add support for DP Video pattern compliance tests
The intel_dp_autotest_video_pattern() function gets invoked through the
compliance test handler on a HPD short pulse if the test type is
set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers
reads to read the requested test pattern, video pattern resolution,
frame rate and bits per color value. The results of this analysis
are handed off to userspace so that the userspace app can set the
video pattern mode appropriately for the test result/response.
The compliance_test_active flag is set at the end of the individual
test handling functions. This is so that the kernel-side operations
can be completed without the risk of interruption from the userspace
app that is polling on that flag.
Signed-off-by: Manasi Navare
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
---
drivers/gpu/drm/i915/i915_debugfs.c | 14 +++-
drivers/gpu/drm/i915/intel_dp.c | 68 +
drivers/gpu/drm/i915/intel_drv.h| 9 +
3 files changed, 90 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3799a12..b048a0e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4545,7 +4545,19 @@ static int i915_displayport_test_data_show(struct
seq_file *m, void *data)
if (connector->status == connector_status_connected &&
connector->encoder != NULL) {
intel_dp = enc_to_intel_dp(connector->encoder);
- seq_printf(m, "%lx", intel_dp->compliance_test_data);
+ if (intel_dp->compliance_test_type ==
+ DP_TEST_LINK_EDID_READ)
+ seq_printf(m, "%lx",
+ intel_dp->compliance_test_data);
+ else if (intel_dp->compliance_test_type ==
+DP_TEST_LINK_VIDEO_PATTERN) {
+ seq_printf(m, "hdisplay: %d\n",
+ intel_dp->test_data.hdisplay);
+ seq_printf(m, "vdisplay: %d\n",
+ intel_dp->test_data.vdisplay);
+ seq_printf(m, "bpc: %u\n",
+ intel_dp->test_data.bpc);
+ }
} else
seq_puts(m, "0");
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f93e130..784f86e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -28,8 +28,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -3868,7 +3870,73 @@ static uint8_t intel_dp_autotest_link_training(struct
intel_dp *intel_dp)
static uint8_t intel_dp_autotest_video_pattern(struct intel_dp *intel_dp)
{
uint8_t test_result = DP_TEST_NAK;
+ uint8_t test_pattern;
+ uint16_t test_misc;
+ __be16 h_width, v_height;
+ int status = 0;
+
+ /* Read the TEST_PATTERN (DP CTS 3.1.5) */
+ status = drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_PATTERN,
+ &test_pattern, 1);
+ if (status <= 0) {
+ DRM_DEBUG_KMS("Could not read test pattern from "
+ "reference sink\n");
+ return 0;
+ }
+ if (test_pattern != DP_COLOR_RAMP)
+ return test_result;
+ intel_dp->test_data.video_pattern = test_pattern;
+
+ status = drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_H_WIDTH,
+ &h_width, 2);
+ if (status <= 0) {
+ DRM_DEBUG_KMS("Could not read H Width from "
+ "reference sink\n");
+ return 0;
+ }
+ intel_dp->test_data.hdisplay = be16_to_cpu(h_width);
+
+ status = drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_V_HEIGHT,
+ &v_height, 2);
+ if (status <= 0) {
+ DRM_DEBUG_KMS("Could not read V Height from "
+ "reference sink\n");
+ return 0;
+ }
+ intel_dp->test_data.vdisplay = be16_to_cpu(v_height);
+
+ status = drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_MISC,
+ &test_misc, 1);
+ if (status <= 0) {
+ DRM_DEBUG_KMS("Could not read TEST MISC from "
+ "reference sink\n");
+ return 0;
+ }
+ if (((test_misc & DP_TEST_COLOR_FORMAT_MASK) >> DP_TEST_MISC_BIT_1) !=
+ DP_VIDEO_PATTERN_RGB_FORMAT)
+ return test_result;
+ if (((test_misc & DP_TEST_DYNAMIC_RANGE_MASK) >> DP_TEST_MISC_BIT_3) !=
+ DP_VIDEO_PATTERN_VESA)
+ return test_result;
+ switch ((test_misc & DP_TEST_BIT_DEPTH_MASK) >> DP_TEST_MISC_BIT_5) {
[Intel-gfx] [PATCH 1/5] drm/i915: Add support for DP link training compliance
This patch adds support to handle automated DP compliance
link training test requests. This patch has been tested with
Unigraf DPR-120 DP Compliance device for testing Link
Training Compliance.
After we get a short pulse Compliance test request, test
request values are read and hotplug uevent is sent in order
to trigger another modeset during which the pipe is configured
and link is retrained and enabled for link parameters requested
by the test.
Signed-off-by: Manasi Navare
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
---
drivers/gpu/drm/i915/intel_dp.c | 73
drivers/gpu/drm/i915/intel_drv.h | 2 ++
2 files changed, 69 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 90283ed..69944d1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -288,6 +288,21 @@ static int intel_dp_common_rates(struct intel_dp *intel_dp,
common_rates);
}
+static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
+ int *common_rates, int link_rate)
+{
+ int common_len;
+ int index;
+
+ common_len = intel_dp_common_rates(intel_dp, common_rates);
+ for (index = 0; index < common_len; index++) {
+ if (link_rate == common_rates[common_len - index - 1])
+ return common_len - index - 1;
+ }
+
+ return -1;
+}
+
static enum drm_mode_status
intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
@@ -1554,6 +1569,7 @@ static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
/* Conveniently, the link BW constants become indices with a shift...*/
int min_clock = 0;
int max_clock;
+ int link_rate_index;
int bpp, mode_rate;
int link_avail, link_clock;
int common_rates[DP_MAX_SUPPORTED_RATES] = {};
@@ -1595,6 +1611,16 @@ static int intel_dp_compute_bpp(struct intel_dp
*intel_dp,
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) {
+ link_rate_index = intel_dp_link_rate_index(intel_dp,
+ common_rates,
+
drm_dp_bw_code_to_link_rate(intel_dp->compliance_test_link_rate));
+ if (link_rate_index >= 0)
+ min_clock = max_clock = link_rate_index;
+ min_lane_count = 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, common_rates[max_clock],
@@ -1642,6 +1668,7 @@ static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
}
}
}
+
}
return false;
@@ -3804,6 +3831,29 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
static uint8_t intel_dp_autotest_link_training(struct intel_dp *intel_dp)
{
uint8_t test_result = DP_TEST_ACK;
+ int status = 0;
+ /* (DP CTS 1.2)
+* 4.3.1.11
+*/
+ /* Read the TEST_LANE_COUNT and TEST_LINK_RTAE fields (DP CTS 3.1.4) */
+ status = drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_LANE_COUNT,
+ &intel_dp->compliance_test_lane_count);
+
+ if (status <= 0) {
+ DRM_DEBUG_KMS("Could not read test lane count from "
+ "reference sink\n");
+ return 0;
+ }
+ intel_dp->compliance_test_lane_count &= DP_MAX_LANE_COUNT_MASK;
+
+ status = drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_LINK_RATE,
+ &intel_dp->compliance_test_link_rate);
+ if (status <= 0) {
+ DRM_DEBUG_KMS("Could not read test link rate from "
+ "refernce sink\n");
+ return 0;
+ }
+
return test_result;
}
@@ -3908,7 +3958,8 @@ static void intel_dp_handle_test_request(struct intel_dp
*intel_dp)
DP_TEST_RESPONSE,
&response, 1);
if (status <= 0)
- DRM_DEBUG_KMS("Could not write test response to sink\n");
+ DRM_DEBUG_KMS("Could not write test response "
+ "to sink\n");
}
static int
@@ -4018,9 +4069,8 @@ static void intel_dp_handle_test_request(struct intel_dp
*intel_dp)
if (WARN_ON_ONCE(!intel_dp->lane_count))
return;
- /* if link training is requested we should perform it always */
- if ((in
[Intel-gfx] [PATCH 2/5] drm/i915: Fixes to support DP Compliance EDID tests
This patch addresses a few issues from the original patch for
DP Compliance EDID test support submitted by
Todd Previte
Video Mode requested in the EDID test handler for the EDID Read
test (CTS 4.2.2.3) should be set to PREFERRED as per the CTS spec.
Signed-off-by: Manasi Navare
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
---
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 69944d1..6693918 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3865,7 +3865,7 @@ static uint8_t intel_dp_autotest_video_pattern(struct
intel_dp *intel_dp)
static uint8_t intel_dp_autotest_edid(struct intel_dp *intel_dp)
{
- uint8_t test_result = DP_TEST_NAK;
+ uint8_t test_result = DP_TEST_ACK;
struct intel_connector *intel_connector = intel_dp->attached_connector;
struct drm_connector *connector = &intel_connector->base;
@@ -3900,7 +3900,7 @@ static uint8_t intel_dp_autotest_edid(struct intel_dp
*intel_dp)
DRM_DEBUG_KMS("Failed to write EDID checksum\n");
test_result = DP_TEST_ACK | DP_TEST_EDID_CHECKSUM_WRITE;
- intel_dp->compliance_test_data = INTEL_DP_RESOLUTION_STANDARD;
+ intel_dp->compliance_test_data = INTEL_DP_RESOLUTION_PREFERRED;
}
/* Set test active flag here so userspace doesn't interrupt things */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Always initialize action_lock
>-Original Message- >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >Chris Wilson >Sent: Tuesday, November 22, 2016 9:06 AM >To: Hiler, Arkadiusz >Cc: intel-gfx@lists.freedesktop.org >Subject: Re: [Intel-gfx] [PATCH] drm/i915/guc: Always initialize action_lock > >On Tue, Nov 22, 2016 at 05:22:47PM +0100, Arkadiusz Hiler wrote: >> Action lock is not being initialized if the GuC submission is disabled >> (i.e. i915.guc_submission=0). >> >> host2guc_action(), which uses the action_lock can be used for >> non-submission purposes, e.g. triggering HuC authentication. >> >> Moving action_lock initialization before enablement check will allow >> us to use the host2guc_action no matter whether submission is enabled >> or not. >> >> Cc: Anusha Srivatsa >> Cc: Jeff McGee >> Signed-off-by: Arkadiusz Hiler > >Seems like you want to split uc_send(), uc_recv() out of i915_guc_submission.c >- >Chris Hiler, this fixes the guc_loading enabled and guc_submission disabled scenario that I was facing. Anusha >-- >Chris Wilson, Intel Open Source Technology Centre >___ >Intel-gfx mailing list >Intel-gfx@lists.freedesktop.org >https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/perf: Wrap 64bit divides in do_div()
Just a couple of naked 64bit divides causing link errors on 32bit
builds, with:
ERROR: "__udivdi3" [drivers/gpu/drm/i915/i915.ko] undefined!
Reported-by: kbuild test robot
Fixes: d79651522e89 ("drm/i915: Enable i915 perf stream for Haswell OA unit")
Signed-off-by: Chris Wilson
Cc: Robert Bragg
---
drivers/gpu/drm/i915/i915_perf.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 95512824922b..7d00532ae010 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -974,8 +974,12 @@ static void i915_oa_stream_disable(struct i915_perf_stream
*stream)
static u64 oa_exponent_to_ns(struct drm_i915_private *dev_priv, int exponent)
{
- return 10ULL * (2ULL << exponent) /
- dev_priv->perf.oa.timestamp_frequency;
+ u64 interval;
+
+ interval = 10ULL * (2ULL << exponent);
+ do_div(interval, dev_priv->perf.oa.timestamp_frequency);
+
+ return interval;
}
static const struct i915_perf_stream_ops i915_oa_stream_ops = {
@@ -1051,16 +1055,17 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
dev_priv->perf.oa.periodic = props->oa_periodic;
if (dev_priv->perf.oa.periodic) {
- u64 period_ns = oa_exponent_to_ns(dev_priv,
- props->oa_period_exponent);
+ u64 margin;
dev_priv->perf.oa.period_exponent = props->oa_period_exponent;
/* See comment for OA_TAIL_MARGIN_NSEC for details
* about this tail_margin...
*/
- dev_priv->perf.oa.tail_margin =
- ((OA_TAIL_MARGIN_NSEC / period_ns) + 1) * format_size;
+ margin = OA_TAIL_MARGIN_NSEC;
+ do_div(margin,
+ oa_exponent_to_ns(dev_priv, props->oa_period_exponent));
+ dev_priv->perf.oa.tail_margin = (margin + 1) * format_size;
}
if (stream->ctx) {
--
2.10.2
___
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: Make skl_write_{plane, cursor}_wm() static
== Series Details ==
Series: drm/i915: Make skl_write_{plane, cursor}_wm() static
URL : https://patchwork.freedesktop.org/series/15767/
State : success
== Summary ==
Series 15767v1 drm/i915: Make skl_write_{plane, cursor}_wm() static
https://patchwork.freedesktop.org/api/1.0/series/15767/revisions/1/mbox/
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a:
dmesg-warn -> PASS (fi-ilk-650)
fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15
fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40
fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28
fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28
fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32
fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20
fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20
fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53
fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14
fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21
fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21
fi-skl-6770hqtotal:244 pass:229 dwarn:1 dfail:0 fail:0 skip:14
fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32
fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33
b34f27e00c9a21d2078062da760e24fd4a620391 drm-intel-nightly:
2016y-11m-22d-17h-42m-39s UTC integration manifest
410252c drm/i915: Make skl_write_{plane, cursor}_wm() static
== Logs ==
For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3084/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Make skl_write_{plane, cursor}_wm() static
Reviewed-by: Lyude
On Tue, 2016-11-22 at 22:21 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Someone forgot to make skl_write_{plane,cursor}_wm() static when
> removing the prototypes from the header. Sparse isn't pleased.
>
> Cc: Maarten Lankhorst
> Cc: Lyude
> Cc: Matt Roper
> Fixes: e62929b3f628 ("drm/i915/gen9+: Program watermarks as a
> separate step during evasion, v3.")
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index bbb1eaf1e6db..d67974eb127a 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3851,10 +3851,10 @@ static void skl_write_wm_level(struct
> drm_i915_private *dev_priv,
> I915_WRITE(reg, val);
> }
>
> -void skl_write_plane_wm(struct intel_crtc *intel_crtc,
> - const struct skl_plane_wm *wm,
> - const struct skl_ddb_allocation *ddb,
> - int plane)
> +static void skl_write_plane_wm(struct intel_crtc *intel_crtc,
> + const struct skl_plane_wm *wm,
> + const struct skl_ddb_allocation *ddb,
> + int plane)
> {
> struct drm_crtc *crtc = &intel_crtc->base;
> struct drm_device *dev = crtc->dev;
> @@ -3875,9 +3875,9 @@ void skl_write_plane_wm(struct intel_crtc
> *intel_crtc,
> &ddb->y_plane[pipe][plane]);
> }
>
> -void skl_write_cursor_wm(struct intel_crtc *intel_crtc,
> - const struct skl_plane_wm *wm,
> - const struct skl_ddb_allocation *ddb)
> +static void skl_write_cursor_wm(struct intel_crtc *intel_crtc,
> + const struct skl_plane_wm *wm,
> + const struct skl_ddb_allocation
> *ddb)
> {
> struct drm_crtc *crtc = &intel_crtc->base;
> struct drm_device *dev = crtc->dev;
--
Cheers,
Lyude
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/9] drm/i915: Use enum plane_id in SKL wm code
Looks good to me
Reviewed-by: Lyude
On Tue, 2016-11-22 at 18:01 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Nuke skl_wm_plane_id() and just use the new intel_plane->id.
>
> v2: Convert skl_write_plane_wm() as well
> v3: Convert skl_pipe_wm_get_hw_state() correctly
> v4: Rebase due to changes in the wm code
> Drop the cursor FIXME from the total data rate calc (Paulo)
> Use the "[PLANE:%d:%s]" format in debug print (Paulo)
>
> Cc: Matt Roper
> Cc: Paulo Zanoni
> Cc: Maarten Lankhorst
> Cc: Lyude
> Signed-off-by: Ville Syrjälä
> Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_pm.c | 180 +-
> --
> 1 file changed, 77 insertions(+), 103 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index bbb1eaf1e6db..e6351445016d 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2867,28 +2867,6 @@ bool ilk_disable_lp_wm(struct drm_device *dev)
> #define SKL_SAGV_BLOCK_TIME 30 /* µs */
>
> /*
> - * Return the index of a plane in the SKL DDB and wm result
> arrays. Primary
> - * plane is always in slot 0, cursor is always in slot
> I915_MAX_PLANES-1, and
> - * other universal planes are in indices 1..n. Note that this may
> leave unused
> - * indices between the top "sprite" plane and the cursor.
> - */
> -static int
> -skl_wm_plane_id(const struct intel_plane *plane)
> -{
> - switch (plane->base.type) {
> - case DRM_PLANE_TYPE_PRIMARY:
> - return 0;
> - case DRM_PLANE_TYPE_CURSOR:
> - return PLANE_CURSOR;
> - case DRM_PLANE_TYPE_OVERLAY:
> - return plane->plane + 1;
> - default:
> - MISSING_CASE(plane->base.type);
> - return plane->plane;
> - }
> -}
> -
> -/*
> * FIXME: We still don't have the proper code detect if we need to
> apply the WA,
> * so assume we'll always need it in order to avoid underruns.
> */
> @@ -3026,7 +3004,6 @@ bool intel_can_enable_sagv(struct
> drm_atomic_state *state)
> struct intel_crtc *crtc;
> struct intel_plane *plane;
> struct intel_crtc_state *cstate;
> - struct skl_plane_wm *wm;
> enum pipe pipe;
> int level, latency;
>
> @@ -3053,7 +3030,8 @@ bool intel_can_enable_sagv(struct
> drm_atomic_state *state)
> return false;
>
> for_each_intel_plane_on_crtc(dev, crtc, plane) {
> - wm = &cstate-
> >wm.skl.optimal.planes[skl_wm_plane_id(plane)];
> + struct skl_plane_wm *wm =
> + &cstate->wm.skl.optimal.planes[plane->id];
>
> /* Skip this plane if it's not enabled */
> if (!wm->wm[0].plane_en)
> @@ -3156,28 +3134,29 @@ static void skl_ddb_entry_init_from_hw(struct
> skl_ddb_entry *entry, u32 reg)
> void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
> struct skl_ddb_allocation *ddb /* out */)
> {
> - enum pipe pipe;
> - int plane;
> - u32 val;
> + struct intel_crtc *crtc;
>
> memset(ddb, 0, sizeof(*ddb));
>
> - for_each_pipe(dev_priv, pipe) {
> + for_each_intel_crtc(&dev_priv->drm, crtc) {
> enum intel_display_power_domain power_domain;
> + enum plane_id plane_id;
> + enum pipe pipe = crtc->pipe;
>
> power_domain = POWER_DOMAIN_PIPE(pipe);
> if (!intel_display_power_get_if_enabled(dev_priv,
> power_domain))
> continue;
>
> - for_each_universal_plane(dev_priv, pipe, plane) {
> - val = I915_READ(PLANE_BUF_CFG(pipe, plane));
> - skl_ddb_entry_init_from_hw(&ddb-
> >plane[pipe][plane],
> - val);
> - }
> + for_each_plane_id_on_crtc(crtc, plane_id) {
> + u32 val;
> +
> + if (plane_id != PLANE_CURSOR)
> + val = I915_READ(PLANE_BUF_CFG(pipe,
> plane_id));
> + else
> + val = I915_READ(CUR_BUF_CFG(pipe));
>
> - val = I915_READ(CUR_BUF_CFG(pipe));
> - skl_ddb_entry_init_from_hw(&ddb-
> >plane[pipe][PLANE_CURSOR],
> - val);
> + skl_ddb_entry_init_from_hw(&ddb-
> >plane[pipe][plane_id], val);
> + }
>
> intel_display_power_put(dev_priv, power_domain);
> }
> @@ -3278,30 +3257,28 @@ skl_get_total_relative_data_rate(struct
> intel_crtc_state *intel_cstate,
> struct drm_crtc_state *cstate = &intel_cstate->base;
> struct drm_atomic_state *state = cstate->state;
> struct drm_plane *plane;
> - const struct intel_plane *intel_plane;
> const struct drm_plane_state *pstate;
> - unsigned int rate, total_data_rate = 0;
> - int id;
> + unsigned int total_data_rate = 0
[Intel-gfx] [PATCH] drm/i915: Make skl_write_{plane, cursor}_wm() static
From: Ville Syrjälä
Someone forgot to make skl_write_{plane,cursor}_wm() static when
removing the prototypes from the header. Sparse isn't pleased.
Cc: Maarten Lankhorst
Cc: Lyude
Cc: Matt Roper
Fixes: e62929b3f628 ("drm/i915/gen9+: Program watermarks as a separate step
during evasion, v3.")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index bbb1eaf1e6db..d67974eb127a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3851,10 +3851,10 @@ static void skl_write_wm_level(struct drm_i915_private
*dev_priv,
I915_WRITE(reg, val);
}
-void skl_write_plane_wm(struct intel_crtc *intel_crtc,
- const struct skl_plane_wm *wm,
- const struct skl_ddb_allocation *ddb,
- int plane)
+static void skl_write_plane_wm(struct intel_crtc *intel_crtc,
+ const struct skl_plane_wm *wm,
+ const struct skl_ddb_allocation *ddb,
+ int plane)
{
struct drm_crtc *crtc = &intel_crtc->base;
struct drm_device *dev = crtc->dev;
@@ -3875,9 +3875,9 @@ void skl_write_plane_wm(struct intel_crtc *intel_crtc,
&ddb->y_plane[pipe][plane]);
}
-void skl_write_cursor_wm(struct intel_crtc *intel_crtc,
-const struct skl_plane_wm *wm,
-const struct skl_ddb_allocation *ddb)
+static void skl_write_cursor_wm(struct intel_crtc *intel_crtc,
+ const struct skl_plane_wm *wm,
+ const struct skl_ddb_allocation *ddb)
{
struct drm_crtc *crtc = &intel_crtc->base;
struct drm_device *dev = crtc->dev;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:drm-intel-next-queued 6/11] ERROR: "__udivdi3" [drivers/gpu/drm/i915/i915.ko] undefined!
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: 7abbd8d670bb928366aa94332a173aa3d394ebfe commit: d79651522e89c4ffa8992b48dfe449f0c583f809 [6/11] drm/i915: Enable i915 perf stream for Haswell OA unit config: i386-randconfig-c0-11222334 (attached as .config) compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4 reproduce: git checkout d79651522e89c4ffa8992b48dfe449f0c583f809 # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): >> ERROR: "__udivdi3" [drivers/gpu/drm/i915/i915.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dim: Enable --scissors by default
On Tue, Nov 22, 2016 at 05:51:20PM +0200, Jani Nikula wrote: > On Tue, 22 Nov 2016, Daniel Vetter wrote: > > I never knew this even was a thing, and plain git am cuts everything > > below the scissors line (since it matches the --- of a diffstat > > start). > > > > Cc: Robert Bragg > > Signed-off-by: Daniel Vetter > > --- > > dim | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/dim b/dim > > index 8697eaee92cc..0b437c9c0a18 100755 > > --- a/dim > > +++ b/dim > > @@ -556,7 +556,7 @@ function dim_apply_branch > > sob=-s > > fi > > > > - cat $file | git am -3 $sob "$@" > > + cat $file | git am --scissors -3 $sob "$@" > > Side note, -3 rarely helps for us because nightly moves on, and the tree > info in the patch is lost. It was still useful for me 1y ago when I pushed most of the patches, and hence likelihood that people based their patches on a -nightly I pushed and hence still had available locally was pretty good. Also, anyone who git worktree shares the dim tree with his own branch repo will benefit from this (at least me for my own patches). So -3 still helps a lot, at least here. -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
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Always initialize action_lock
== Series Details == Series: drm/i915/guc: Always initialize action_lock URL : https://patchwork.freedesktop.org/series/15755/ State : failure == Summary == Series 15755v1 drm/i915/guc: Always initialize action_lock https://patchwork.freedesktop.org/api/1.0/series/15755/revisions/1/mbox/ Test drv_module_reload_basic: dmesg-warn -> PASS (fi-skl-6770hq) Test kms_setmode: Subgroup basic-clone-single-crtc: pass -> INCOMPLETE (fi-skl-6700k) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:209 pass:187 dwarn:1 dfail:0 fail:0 skip:20 fi-skl-6770hqtotal:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 eeec5e7742b23082dd20523c8baa08fe495175e4 drm-intel-nightly: 2016y-11m-21d-18h-22m-22s UTC integration manifest 6500d86 drm/i915/guc: Always initialize action_lock == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3083/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Always initialize action_lock
On Tue, Nov 22, 2016 at 05:22:47PM +0100, Arkadiusz Hiler wrote: > Action lock is not being initialized if the GuC submission is disabled > (i.e. i915.guc_submission=0). > > host2guc_action(), which uses the action_lock can be used for > non-submission purposes, e.g. triggering HuC authentication. > > Moving action_lock initialization before enablement check will allow us > to use the host2guc_action no matter whether submission is enabled or > not. > > Cc: Anusha Srivatsa > Cc: Jeff McGee > Signed-off-by: Arkadiusz Hiler Seems like you want to split uc_send(), uc_recv() out of i915_guc_submission.c -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] igt/gem_exec_parse: test_lri check init + add debug msg
On Tue, Nov 22, 2016 at 04:50:35PM +, Robert Bragg wrote:
> Just to note I haven't tested yet as I don't have hsw to hand, but seems
> simple enough to send out anyway...
>
> --- >8 ---
>
> To make it clear on failure what register was being tested the test_lri
> helper now uses igt_debug to log the register address and value being
> tested. The test_lri helper now also double checks that the initial
> intel_register_write() takes before issuing the LRI.
>
> Signed-off-by: Robert Bragg
> ---
> tests/gem_exec_parse.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
> index cc2103a..534a933 100644
> --- a/tests/gem_exec_parse.c
> +++ b/tests/gem_exec_parse.c
> @@ -272,8 +272,15 @@ test_lri(int fd, uint32_t handle,
> MI_BATCH_BUFFER_END,
> };
>
> + igt_debug("testing lri, reg=%x, val=%x, expected errno=%d\n",
> + test->reg, test->test_val, expected_errno);
> +
> intel_register_write(test->reg, test->init_val);
>
> + igt_assert_eq_u32((intel_register_read(test->reg) &
> +test->read_mask),
> + test->init_val);
igt_assert_f((intel_register_read(test->reg) & test->read_mask) ==
test->init_val,
"LRI reg=%x overwrote initial value of %x with %x [LRI
value=%x]\n",
test->reg, test->init_val, intel_register_read(test->reg) &
test->read_mask, test->val);
Something like that. I was also hoping to pass in test->name [name of
the register for convenience], which equally lends itself to
igt_subtest_f("test-lri-%s", test->name)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] igt/gem_exec_parse: test_lri check init + add debug msg
Just to note I haven't tested yet as I don't have hsw to hand, but seems
simple enough to send out anyway...
--- >8 ---
To make it clear on failure what register was being tested the test_lri
helper now uses igt_debug to log the register address and value being
tested. The test_lri helper now also double checks that the initial
intel_register_write() takes before issuing the LRI.
Signed-off-by: Robert Bragg
---
tests/gem_exec_parse.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index cc2103a..534a933 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -272,8 +272,15 @@ test_lri(int fd, uint32_t handle,
MI_BATCH_BUFFER_END,
};
+ igt_debug("testing lri, reg=%x, val=%x, expected errno=%d\n",
+ test->reg, test->test_val, expected_errno);
+
intel_register_write(test->reg, test->init_val);
+ igt_assert_eq_u32((intel_register_read(test->reg) &
+ test->read_mask),
+ test->init_val);
+
exec_batch(fd, handle,
lri, sizeof(lri),
I915_EXEC_RENDER,
--
2.10.2
___
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: Add a per-pipe plane identifier enum (rev5)
== Series Details == Series: drm/i915: Add a per-pipe plane identifier enum (rev5) URL : https://patchwork.freedesktop.org/series/14978/ State : success == Summary == Series 14978v5 drm/i915: Add a per-pipe plane identifier enum https://patchwork.freedesktop.org/api/1.0/series/14978/revisions/5/mbox/ Test drv_module_reload_basic: dmesg-warn -> PASS (fi-skl-6770hq) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 eeec5e7742b23082dd20523c8baa08fe495175e4 drm-intel-nightly: 2016y-11m-21d-18h-22m-22s UTC integration manifest dc45b91 drm/i915: Rename the local 'plane' variable to 'plane_id' in primary plane code 3e642c7 drm/i915: Don't populate plane->plane for cursors and sprites fa55355 drm/i915: s/plane/plane_id/ in skl+ plane register defines 87d3a43 drm/i915: Use enum plane_id in VLV/CHV wm code 1e0e553 drm/i915: Use enum plane_id in VLV/CHV sprite code b861dac drm/i915: Use enum plane_id in SKL plane code 2b8c0dd drm/i915: Use enum plane_id in SKL wm code baf65ea drm/i915: Add crtc->plane_ids_mask 0d733576 drm/i915: Add per-pipe plane identifier == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3082/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] aubdump: Handle 48-bit relocations properly
Reviewed-by: Lionel Landwerlin
On 18/11/16 19:51, Jason Ekstrand wrote:
aubdump was only writing 32-bits regardless of platform. This is fine if
the client being dumped leaves the top 32 bits zero since the aubdump GTT
is fairly small. However, if the client does store something in the upper
32 bits, this results in an invalid relocation.
Cc: Kristian Høgsberg
---
tools/aubdump.c | 31 ---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/tools/aubdump.c b/tools/aubdump.c
index 4e0d0a8..0cf993d 100644
--- a/tools/aubdump.c
+++ b/tools/aubdump.c
@@ -284,6 +284,32 @@ aub_dump_ringbuffer(uint64_t batch_offset, uint64_t
offset, int ring_flag)
data_out(ringbuffer, ring_count * 4);
}
+static void
+write_reloc(void *p, uint64_t v)
+{
+ if (gen >= 8) {
+ /* From the Broadwell PRM Vol. 2a,
+* MI_LOAD_REGISTER_MEM::MemoryAddress:
+*
+* "This field specifies the address of the memory
+* location where the register value specified in the
+* DWord above will read from. The address specifies
+* the DWord location of the data. Range =
+* GraphicsVirtualAddress[63:2] for a DWord register
+* GraphicsAddress [63:48] are ignored by the HW and
+* assumed to be in correct canonical form [63:48] ==
+* [47]."
+*
+* In practice, this will always mean the top bits are zero
+* because of the GTT size limitation of the aubdump tool.
+*/
+ const int shift = 63 - 47;
+ *(uint64_t *)p = (((int64_t)v) << shift) >> shift;
+ } else {
+ *(uint32_t *)p = v;
+ }
+}
+
static void *
relocate_bo(struct bo *bo, const struct drm_i915_gem_execbuffer2 *execbuffer2,
const struct drm_i915_gem_exec_object2 *obj)
@@ -293,7 +319,6 @@ relocate_bo(struct bo *bo, const struct
drm_i915_gem_execbuffer2 *execbuffer2,
const struct drm_i915_gem_relocation_entry *relocs =
(const struct drm_i915_gem_relocation_entry *) (uintptr_t)
obj->relocs_ptr;
void *relocated;
- uint32_t *dw;
int handle;
relocated = malloc(bo->size);
@@ -307,8 +332,8 @@ relocate_bo(struct bo *bo, const struct
drm_i915_gem_execbuffer2 *execbuffer2,
else
handle = relocs[i].target_handle;
- dw = (uint32_t*)(((char *) relocated) + relocs[i].offset);
- *dw = get_bo(handle)->offset + relocs[i].delta;
+ write_reloc(((char *)relocated) + relocs[i].offset,
+ get_bo(handle)->offset + relocs[i].delta);
}
return relocated;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/lspcon: Remove unused force change mode parameter
On Tue, 2016-11-22 at 21:09 +0530, Sharma, Shashank wrote:
> The reason why I kept the force function was, that during debug phase, I
> saw a need to change LSPCON mode.
>
> Also, in future, if we need to provide an IOCTL/control to userspace, to
> change lspcon mode, force may be required to differentiate the path from
> user/kernel space.
Not sure how that would work, but it's easy to add the parameter when
it's actually implemented. Until then it only makes reading the code
more difficult.
>
> But in any case: Reviewed-by: Shashank Sharma
>
>
> Regards
>
> Shashank
>
> On 11/22/2016 12:45 AM, Imre Deak wrote:
> > All callers asked for a forced change but the function ignored this
> > parameter. It doesn't seem to be necessary to force the change in any
> > case so let's just remove the parameter.
> >
> > Cc: Shashank Sharma
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_lspcon.c | 7 +++
> > 1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
> > b/drivers/gpu/drm/i915/intel_lspcon.c
> > index 281127d..f6d4e69 100644
> > --- a/drivers/gpu/drm/i915/intel_lspcon.c
> > +++ b/drivers/gpu/drm/i915/intel_lspcon.c
> > @@ -87,7 +87,7 @@ static enum drm_lspcon_mode lspcon_wait_mode(struct
> > intel_lspcon *lspcon,
> > }
> >
> > static int lspcon_change_mode(struct intel_lspcon *lspcon,
> > - enum drm_lspcon_mode mode, bool force)
> > + enum drm_lspcon_mode mode)
> > {
> > int err;
> > enum drm_lspcon_mode current_mode;
> > @@ -202,7 +202,7 @@ void lspcon_resume(struct intel_lspcon *lspcon)
> > if (lspcon_wait_mode(lspcon, expected_mode) == DRM_LSPCON_MODE_PCON)
> > return;
> >
> > - if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON, true))
> > + if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON))
> > DRM_ERROR("LSPCON resume failed\n");
> > else
> > DRM_DEBUG_KMS("LSPCON resume success\n");
> > @@ -239,8 +239,7 @@ bool lspcon_init(struct intel_digital_port
> > *intel_dig_port)
> > * 2.0 sinks.
> > */
> > if (lspcon->active && lspcon->mode != DRM_LSPCON_MODE_PCON) {
> > - if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON,
> > - true) < 0) {
> > + if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON) < 0) {
> > DRM_ERROR("LSPCON mode change to PCON failed\n");
> > return false;
> > }
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/guc: Always initialize action_lock
Action lock is not being initialized if the GuC submission is disabled (i.e. i915.guc_submission=0). host2guc_action(), which uses the action_lock can be used for non-submission purposes, e.g. triggering HuC authentication. Moving action_lock initialization before enablement check will allow us to use the host2guc_action no matter whether submission is enabled or not. Cc: Anusha Srivatsa Cc: Jeff McGee Signed-off-by: Arkadiusz Hiler --- drivers/gpu/drm/i915/i915_guc_submission.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c index 4462112..17c06d5 100644 --- a/drivers/gpu/drm/i915/i915_guc_submission.c +++ b/drivers/gpu/drm/i915/i915_guc_submission.c @@ -1484,6 +1484,8 @@ int i915_guc_submission_init(struct drm_i915_private *dev_priv) struct intel_guc *guc = &dev_priv->guc; struct i915_vma *vma; + mutex_init(&guc->action_lock); + /* Wipe bitmap & delete client in case of reinitialisation */ bitmap_clear(guc->doorbell_bitmap, 0, GUC_MAX_DOORBELLS); i915_guc_submission_disable(dev_priv); @@ -1500,7 +1502,6 @@ int i915_guc_submission_init(struct drm_i915_private *dev_priv) guc->ctx_pool_vma = vma; ida_init(&guc->ctx_ids); - mutex_init(&guc->action_lock); guc_log_create(guc); guc_addon_create(guc); -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/lspcon: Wait for expected LSPCON mode to settle
On Tue, 2016-11-22 at 21:06 +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 11/22/2016 12:45 AM, Imre Deak wrote:
> > Some LSPCON adaptors may return an incorrect LSPCON mode right after
> > waking from DP Sleep state. This is the case at least for the ParadTech
> > PS175 adaptor, both when waking because of exiting the DP Sleep to
> > active state, or due to any other AUX CH transfer. We can determine the
> > current expected mode based on whether the DPCD area is accessible,
> > since according to the LSPCON spec this area is only accesible
> > in PCON mode.
> >
> > This wait will avoid us trying to change the mode, while the current
> > expected mode hasn't settled yet and start link training before the
> > adaptor thinks it's in PCON mode after waking from DP Sleep state.
> >
> > Cc: Shashank Sharma
> > Cc: Ville Syrjälä
> > Cc: Jani Nikula
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 5 +++
> > drivers/gpu/drm/i915/intel_drv.h| 1 +
> > drivers/gpu/drm/i915/intel_lspcon.c | 70
> > -
> > 3 files changed, 68 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 16c19d78..8026a83 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -2401,6 +2401,8 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp,
> > int mode)
> > ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER,
> > DP_SET_POWER_D3);
> > } else {
> > + struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> > +
> > /*
> > * When turning on, we need to retry for 1ms to give the sink
> > * time to wake up.
> > @@ -2412,6 +2414,9 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp,
> > int mode)
> > break;
> > msleep(1);
> > }
> > +
> > + if (ret == 1 && lspcon->active)
> > + lspcon_wait_pcon_mode(lspcon);
> > }
> >
> > if (ret != 1)
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index cf47e8a..d165904 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1830,4 +1830,5 @@ void intel_color_load_luts(struct drm_crtc_state
> > *crtc_state);
> > /* intel_lspcon.c */
> > bool lspcon_init(struct intel_digital_port *intel_dig_port);
> > void lspcon_resume(struct intel_lspcon *lspcon);
> > +void lspcon_wait_pcon_mode(struct intel_lspcon *lspcon);
> > #endif /* __INTEL_DRV_H__ */
> > diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
> > b/drivers/gpu/drm/i915/intel_lspcon.c
> > index 5013124..281127d 100644
> > --- a/drivers/gpu/drm/i915/intel_lspcon.c
> > +++ b/drivers/gpu/drm/i915/intel_lspcon.c
> > @@ -35,16 +35,54 @@ static struct intel_dp *lspcon_to_intel_dp(struct
> > intel_lspcon *lspcon)
> > return &dig_port->dp;
> > }
> >
> > +static const char *lspcon_mode_name(enum drm_lspcon_mode mode)
> > +{
> > + switch (mode) {
> > + case DRM_LSPCON_MODE_PCON:
> > + return "PCON";
> > + case DRM_LSPCON_MODE_LS:
> > + return "LS";
> > + case DRM_LSPCON_MODE_INVALID:
> > + return "INVALID";
> > + default:
> > + MISSING_CASE(mode);
> > + return "INVALID";
> > + }
> > +}
> > +
> > static enum drm_lspcon_mode lspcon_get_current_mode(struct intel_lspcon
> > *lspcon)
> > {
> > - enum drm_lspcon_mode current_mode = DRM_LSPCON_MODE_INVALID;
> > + enum drm_lspcon_mode current_mode;
> > struct i2c_adapter *adapter = &lspcon_to_intel_dp(lspcon)->aux.ddc;
> >
> > - if (drm_lspcon_get_mode(adapter, ¤t_mode))
> > + if (drm_lspcon_get_mode(adapter, ¤t_mode)) {
> > DRM_ERROR("Error reading LSPCON mode\n");
> > - else
> > - DRM_DEBUG_KMS("Current LSPCON mode %s\n",
> > - current_mode == DRM_LSPCON_MODE_PCON ? "PCON" : "LS");
> > + return DRM_LSPCON_MODE_INVALID;
> > + }
> > + return current_mode;
> > +}
> > +
> > +static enum drm_lspcon_mode lspcon_wait_mode(struct intel_lspcon *lspcon,
> > + enum drm_lspcon_mode mode)
> > +{
> > + enum drm_lspcon_mode current_mode;
> > +
> > + current_mode = lspcon_get_current_mode(lspcon);
> > + if (current_mode == mode || current_mode == DRM_LSPCON_MODE_INVALID)
> > + goto out;
> > +
> > + DRM_DEBUG_KMS("Waiting for LSPCON mode %s to settle\n",
> > + lspcon_mode_name(mode));
> > +
> Can we remove above lines, and start from below lines ? I guess wait_for
> checks the condition first and then executes wait ?
Yes wait_for() works like that, but I wanted to have a debug message
about the fact that we had to wait.
> Also, a comment stating 100ms wait ?
Why? It's clear what's the timeout from the
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915: Don't deref context->file_priv ERR_PTR upon reset
== Series Details == Series: series starting with [CI,1/4] drm/i915: Don't deref context->file_priv ERR_PTR upon reset URL : https://patchwork.freedesktop.org/series/15748/ State : success == Summary == Series 15748v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/15748/revisions/1/mbox/ Test drv_module_reload_basic: dmesg-warn -> PASS (fi-skl-6770hq) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 eeec5e7742b23082dd20523c8baa08fe495175e4 drm-intel-nightly: 2016y-11m-21d-18h-22m-22s UTC integration manifest a8ec120 drm/i915: Stop the machine as we install the wedged submit_request handler 5161134 drm/i915: Complete requests in nop_submit_request b4c2f62 drm/i915: Disable hangcheck when wedged fc61f35 drm/i915: Don't deref context->file_priv ERR_PTR upon reset == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3081/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt v4 12/13] igt/gem_exec_parse: update registers test for v >= 8
On Tue, Nov 22, 2016 at 03:45:59PM +, Chris Wilson wrote: > On Mon, Nov 14, 2016 at 08:51:21PM +, Robert Bragg wrote: > > This combines some parts of the recently added store_lri test with the > > registers test to be able to first load a distinguishable value before > > the LRI and explicitly read back the register to determine if the > > command succeeded or was a NOOP. > > > > For now though we won't look at OACONTROL without checking for version 9 > > of the command parser. > > > > This updates the 'bad' test to check the OASTATUS2 register so that we > > can explicitly read back from the register to check it becomes a NOOP. > > > > This adds a struct test_lri for associating a mask with the init/test > > values so we ignore things like hw status bits that might interfere > > with the result. > > > > Signed-off-by: Robert Bragg > > Reviewed-by: Matthew Auld > > --- > > tests/gem_exec_parse.c | 94 > > ++ > > 1 file changed, 49 insertions(+), 45 deletions(-) > > > > diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c > > index 2bc6340..43f25ce 100644 > > --- a/tests/gem_exec_parse.c > > +++ b/tests/gem_exec_parse.c > > @@ -35,6 +35,7 @@ > > #endif > > > > #define DERRMR 0x44050 > > +#define OASTATUS2 0x2368 > > #define OACONTROL 0x2360 > > #define SO_WRITE_OFFSET_0 0x5280 > > > > @@ -253,27 +254,35 @@ static void exec_batch_chained(int fd, uint32_t > > cmd_bo, uint32_t *cmds, > > gem_close(fd, target_bo); > > } > > > > -static void stray_lri(int fd, uint32_t handle) > > Ahem. Why did you remove that agnostic test without replacing it? In a later patch, that was annoying. But it is not being tested for the rejection. test_lri() doesn't check the register write took (always useful to test the setup first), nor does it provide a good hint as to which lri failed. Either that needs expanding upon, or the multiple tests extracted into separate subtests. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Make GPU pages movable
On 9 November 2016 at 18:36, Hugh Dickins wrote: > On Wed, 9 Nov 2016, Daniel Vetter wrote: >> >> Hi all -mm folks! >> >> Any feedback on these two? It's kinda an intermediate step towards a >> full-blown gemfs, and I think useful for that. Or do we need to go >> directly to our own backing storage thing? Aside from ack/nack from -mm I >> think this is ready for merging. > > I'm currently considering them at last: will report back later. > > Full-blown gemfs does not come in here, of course; but let me > fire a warning shot since you mention it: if it's going to use swap, > then we shall probably have to nak it in favour of continuing to use > infrastructure from mm/shmem.c. I very much understand why you would > love to avoid that dependence, but I doubt it can be safely bypassed. Could you please elaborate on what specifically you don't like about gemfs implementing swap, just to make sure I'm following? Thanks, Matt ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/9] drm/i915: s/plane/plane_id/ in skl+ plane register defines
From: Ville Syrjälä
Rename the SKL plane register define 'plane' parameter to 'plane_id' to
reflect the fact that you're supposed to pass in the enum plane_id
rather than enum plane.
Do the same for the scaler plane selector bits.
Cc: Paulo Zanoni
Suggested-by: Paulo Zanoni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 46 -
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d03491089f9c..8ceea23ba63b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5502,8 +5502,8 @@ enum {
#define _PLANE_CTL_1(pipe) _PIPE(pipe, _PLANE_CTL_1_A, _PLANE_CTL_1_B)
#define _PLANE_CTL_2(pipe) _PIPE(pipe, _PLANE_CTL_2_A, _PLANE_CTL_2_B)
#define _PLANE_CTL_3(pipe) _PIPE(pipe, _PLANE_CTL_3_A, _PLANE_CTL_3_B)
-#define PLANE_CTL(pipe, plane) \
- _MMIO_PLANE(plane, _PLANE_CTL_1(pipe), _PLANE_CTL_2(pipe))
+#define PLANE_CTL(pipe, plane_id) \
+ _MMIO_PLANE(plane_id, _PLANE_CTL_1(pipe), _PLANE_CTL_2(pipe))
#define _PLANE_STRIDE_1_B 0x71188
#define _PLANE_STRIDE_2_B 0x71288
@@ -5514,8 +5514,8 @@ enum {
_PIPE(pipe, _PLANE_STRIDE_2_A, _PLANE_STRIDE_2_B)
#define _PLANE_STRIDE_3(pipe) \
_PIPE(pipe, _PLANE_STRIDE_3_A, _PLANE_STRIDE_3_B)
-#define PLANE_STRIDE(pipe, plane) \
- _MMIO_PLANE(plane, _PLANE_STRIDE_1(pipe), _PLANE_STRIDE_2(pipe))
+#define PLANE_STRIDE(pipe, plane_id) \
+ _MMIO_PLANE(plane_id, _PLANE_STRIDE_1(pipe), _PLANE_STRIDE_2(pipe))
#define _PLANE_POS_1_B 0x7118c
#define _PLANE_POS_2_B 0x7128c
@@ -5523,8 +5523,8 @@ enum {
#define _PLANE_POS_1(pipe) _PIPE(pipe, _PLANE_POS_1_A, _PLANE_POS_1_B)
#define _PLANE_POS_2(pipe) _PIPE(pipe, _PLANE_POS_2_A, _PLANE_POS_2_B)
#define _PLANE_POS_3(pipe) _PIPE(pipe, _PLANE_POS_3_A, _PLANE_POS_3_B)
-#define PLANE_POS(pipe, plane) \
- _MMIO_PLANE(plane, _PLANE_POS_1(pipe), _PLANE_POS_2(pipe))
+#define PLANE_POS(pipe, plane_id) \
+ _MMIO_PLANE(plane_id, _PLANE_POS_1(pipe), _PLANE_POS_2(pipe))
#define _PLANE_SIZE_1_B0x71190
#define _PLANE_SIZE_2_B0x71290
@@ -5532,8 +5532,8 @@ enum {
#define _PLANE_SIZE_1(pipe)_PIPE(pipe, _PLANE_SIZE_1_A, _PLANE_SIZE_1_B)
#define _PLANE_SIZE_2(pipe)_PIPE(pipe, _PLANE_SIZE_2_A, _PLANE_SIZE_2_B)
#define _PLANE_SIZE_3(pipe)_PIPE(pipe, _PLANE_SIZE_3_A, _PLANE_SIZE_3_B)
-#define PLANE_SIZE(pipe, plane)\
- _MMIO_PLANE(plane, _PLANE_SIZE_1(pipe), _PLANE_SIZE_2(pipe))
+#define PLANE_SIZE(pipe, plane_id) \
+ _MMIO_PLANE(plane_id, _PLANE_SIZE_1(pipe), _PLANE_SIZE_2(pipe))
#define _PLANE_SURF_1_B0x7119c
#define _PLANE_SURF_2_B0x7129c
@@ -5541,36 +5541,36 @@ enum {
#define _PLANE_SURF_1(pipe)_PIPE(pipe, _PLANE_SURF_1_A, _PLANE_SURF_1_B)
#define _PLANE_SURF_2(pipe)_PIPE(pipe, _PLANE_SURF_2_A, _PLANE_SURF_2_B)
#define _PLANE_SURF_3(pipe)_PIPE(pipe, _PLANE_SURF_3_A, _PLANE_SURF_3_B)
-#define PLANE_SURF(pipe, plane)\
- _MMIO_PLANE(plane, _PLANE_SURF_1(pipe), _PLANE_SURF_2(pipe))
+#define PLANE_SURF(pipe, plane_id) \
+ _MMIO_PLANE(plane_id, _PLANE_SURF_1(pipe), _PLANE_SURF_2(pipe))
#define _PLANE_OFFSET_1_B 0x711a4
#define _PLANE_OFFSET_2_B 0x712a4
#define _PLANE_OFFSET_1(pipe) _PIPE(pipe, _PLANE_OFFSET_1_A, _PLANE_OFFSET_1_B)
#define _PLANE_OFFSET_2(pipe) _PIPE(pipe, _PLANE_OFFSET_2_A, _PLANE_OFFSET_2_B)
-#define PLANE_OFFSET(pipe, plane) \
- _MMIO_PLANE(plane, _PLANE_OFFSET_1(pipe), _PLANE_OFFSET_2(pipe))
+#define PLANE_OFFSET(pipe, plane_id) \
+ _MMIO_PLANE(plane_id, _PLANE_OFFSET_1(pipe), _PLANE_OFFSET_2(pipe))
#define _PLANE_KEYVAL_1_B 0x71194
#define _PLANE_KEYVAL_2_B 0x71294
#define _PLANE_KEYVAL_1(pipe) _PIPE(pipe, _PLANE_KEYVAL_1_A, _PLANE_KEYVAL_1_B)
#define _PLANE_KEYVAL_2(pipe) _PIPE(pipe, _PLANE_KEYVAL_2_A, _PLANE_KEYVAL_2_B)
-#define PLANE_KEYVAL(pipe, plane) \
- _MMIO_PLANE(plane, _PLANE_KEYVAL_1(pipe), _PLANE_KEYVAL_2(pipe))
+#define PLANE_KEYVAL(pipe, plane_id) \
+ _MMIO_PLANE(plane_id, _PLANE_KEYVAL_1(pipe), _PLANE_KEYVAL_2(pipe))
#define _PLANE_KEYMSK_1_B 0x71198
#define _PLANE_KEYMSK_2_B 0x71298
#define _PLANE_KEYMSK_1(pipe) _PIPE(pipe, _PLANE_KEYMSK_1_A, _PLANE_KEYMSK_1_B)
#define _PLANE_KEYMSK_2(pipe) _PIPE(pipe, _PLANE_KEYMSK_2_A, _PLANE_KEYMSK_2_B)
-#define PLANE_KEYMSK(pipe, plane) \
- _MMIO_PLANE(plane, _PLANE_KEYMSK_1(pipe), _PLANE_KEYMSK_2(pipe))
+#define PLANE_KEYMSK(pipe, plane_id) \
+ _MMIO_PLANE(plane_id, _PLANE_KEYMSK_1(pipe), _PLANE_KEYMSK_2(pipe))
#define _
[Intel-gfx] [PATCH 4/9] drm/i915: Use enum plane_id in SKL plane code
From: Ville Syrjälä
Replace the intel_plane->plane and hardcoded 0 usage in the SKL plane
code with intel_plane->id.
This should make the SKL "primary" and "sprite" code virtually
identical, so the next logical step would likely be dropping one
of the copies.
Signed-off-by: Ville Syrjälä
Reviewed-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 31 +-
drivers/gpu/drm/i915/intel_sprite.c | 42 ++--
2 files changed, 37 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6c3032f04d54..0a98989b8663 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3378,7 +3378,8 @@ static void skylake_update_primary_plane(struct drm_plane
*plane,
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_framebuffer *fb = plane_state->base.fb;
- int pipe = intel_crtc->pipe;
+ enum plane_id plane_id = to_intel_plane(plane)->id;
+ enum pipe pipe = to_intel_plane(plane)->pipe;
u32 plane_ctl;
unsigned int rotation = plane_state->base.rotation;
u32 stride = skl_plane_stride(fb, 0, rotation);
@@ -3413,30 +3414,30 @@ static void skylake_update_primary_plane(struct
drm_plane *plane,
intel_crtc->adjusted_x = src_x;
intel_crtc->adjusted_y = src_y;
- I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
- I915_WRITE(PLANE_OFFSET(pipe, 0), (src_y << 16) | src_x);
- I915_WRITE(PLANE_STRIDE(pipe, 0), stride);
- I915_WRITE(PLANE_SIZE(pipe, 0), (src_h << 16) | src_w);
+ I915_WRITE(PLANE_CTL(pipe, plane_id), plane_ctl);
+ I915_WRITE(PLANE_OFFSET(pipe, plane_id), (src_y << 16) | src_x);
+ I915_WRITE(PLANE_STRIDE(pipe, plane_id), stride);
+ I915_WRITE(PLANE_SIZE(pipe, plane_id), (src_h << 16) | src_w);
if (scaler_id >= 0) {
uint32_t ps_ctrl = 0;
WARN_ON(!dst_w || !dst_h);
- ps_ctrl = PS_SCALER_EN | PS_PLANE_SEL(0) |
+ ps_ctrl = PS_SCALER_EN | PS_PLANE_SEL(plane_id) |
crtc_state->scaler_state.scalers[scaler_id].mode;
I915_WRITE(SKL_PS_CTRL(pipe, scaler_id), ps_ctrl);
I915_WRITE(SKL_PS_PWR_GATE(pipe, scaler_id), 0);
I915_WRITE(SKL_PS_WIN_POS(pipe, scaler_id), (dst_x << 16) |
dst_y);
I915_WRITE(SKL_PS_WIN_SZ(pipe, scaler_id), (dst_w << 16) |
dst_h);
- I915_WRITE(PLANE_POS(pipe, 0), 0);
+ I915_WRITE(PLANE_POS(pipe, plane_id), 0);
} else {
- I915_WRITE(PLANE_POS(pipe, 0), (dst_y << 16) | dst_x);
+ I915_WRITE(PLANE_POS(pipe, plane_id), (dst_y << 16) | dst_x);
}
- I915_WRITE(PLANE_SURF(pipe, 0),
+ I915_WRITE(PLANE_SURF(pipe, plane_id),
intel_fb_gtt_offset(fb, rotation) + surf_addr);
- POSTING_READ(PLANE_SURF(pipe, 0));
+ POSTING_READ(PLANE_SURF(pipe, plane_id));
}
static void skylake_disable_primary_plane(struct drm_plane *primary,
@@ -3444,12 +3445,12 @@ static void skylake_disable_primary_plane(struct
drm_plane *primary,
{
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- int pipe = intel_crtc->pipe;
+ enum plane_id plane_id = to_intel_plane(primary)->id;
+ enum pipe pipe = to_intel_plane(primary)->pipe;
- I915_WRITE(PLANE_CTL(pipe, 0), 0);
- I915_WRITE(PLANE_SURF(pipe, 0), 0);
- POSTING_READ(PLANE_SURF(pipe, 0));
+ I915_WRITE(PLANE_CTL(pipe, plane_id), 0);
+ I915_WRITE(PLANE_SURF(pipe, plane_id), 0);
+ POSTING_READ(PLANE_SURF(pipe, plane_id));
}
/* Assume fb object is pinned & idle & fenced and just update base pointers */
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index b5f750364e99..93158061f790 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -203,8 +203,8 @@ skl_update_plane(struct drm_plane *drm_plane,
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_plane *intel_plane = to_intel_plane(drm_plane);
struct drm_framebuffer *fb = plane_state->base.fb;
- const int pipe = intel_plane->pipe;
- const int plane = intel_plane->plane + 1;
+ enum plane_id plane_id = intel_plane->id;
+ enum pipe pipe = intel_plane->pipe;
u32 plane_ctl;
const struct drm_intel_sprite_colorkey *key = &plane_state->ckey;
u32 surf_addr = plane_state->main.offset;
@@ -229,9 +229,9 @@ skl_update_plane(struct drm_plane *drm_plane,
plane_ctl |= skl_plane_ctl_rotation(rotation);
if (key->flags) {
- I915_WRITE(PLANE_KEYVAL(pipe, plane), key->
[Intel-gfx] [PATCH 2/9] drm/i915: Add crtc->plane_ids_mask
From: Ville Syrjälä
Add a mask of which planes are available for each pipe. This doesn't
quite work for old platforms with dynamic plane<->pipe assignment, but
as we don't support that sort of stuff (yet) we can get away with it.
The main use I have for this is the for_each_plane_id_on_crtc() macro
for iterating over all possible planes on the crtc. I suppose we could
not add the mask, and instead iterate by comparing intel_plane->pipe
but then we'd need a local intel_plane variable which is just
unnecessary clutter in some cases. But I'm not hung up on this, so if
people prefer the other option I could be convinced to use it.
v2: Use BIT() in the iterator macro too (Paulo)
Signed-off-by: Ville Syrjälä
Reviewed-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h | 4
drivers/gpu/drm/i915/intel_display.c | 3 +++
drivers/gpu/drm/i915/intel_drv.h | 3 ++-
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6c9864287b29..90bd31d71a81 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -210,6 +210,10 @@ enum plane_id {
I915_MAX_PLANES,
};
+#define for_each_plane_id_on_crtc(__crtc, __p) \
+ for ((__p) = PLANE_PRIMARY; (__p) < I915_MAX_PLANES; (__p)++) \
+ for_each_if ((__crtc)->plane_ids_mask & BIT(__p))
+
enum port {
PORT_NONE = -1,
PORT_A = 0,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index dfd3dbe6a92a..6c3032f04d54 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15277,6 +15277,7 @@ static int intel_crtc_init(struct drm_i915_private
*dev_priv, enum pipe pipe)
ret = PTR_ERR(primary);
goto fail;
}
+ intel_crtc->plane_ids_mask |= BIT(primary->id);
for_each_sprite(dev_priv, pipe, sprite) {
struct intel_plane *plane;
@@ -15286,6 +15287,7 @@ static int intel_crtc_init(struct drm_i915_private
*dev_priv, enum pipe pipe)
ret = PTR_ERR(plane);
goto fail;
}
+ intel_crtc->plane_ids_mask |= BIT(plane->id);
}
cursor = intel_cursor_plane_create(dev_priv, pipe);
@@ -15293,6 +15295,7 @@ static int intel_crtc_init(struct drm_i915_private
*dev_priv, enum pipe pipe)
ret = PTR_ERR(cursor);
goto fail;
}
+ intel_crtc->plane_ids_mask |= BIT(cursor->id);
ret = drm_crtc_init_with_planes(&dev_priv->drm, &intel_crtc->base,
&primary->base, &cursor->base,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index b2a0409330a9..c1b245853ba9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -691,8 +691,9 @@ struct intel_crtc {
* some outputs connected to this crtc.
*/
bool active;
- unsigned long enabled_power_domains;
bool lowfreq_avail;
+ u8 plane_ids_mask;
+ unsigned long enabled_power_domains;
struct intel_overlay *overlay;
struct intel_flip_work *flip_work;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/9] drm/i915: Use enum plane_id in SKL wm code
From: Ville Syrjälä
Nuke skl_wm_plane_id() and just use the new intel_plane->id.
v2: Convert skl_write_plane_wm() as well
v3: Convert skl_pipe_wm_get_hw_state() correctly
v4: Rebase due to changes in the wm code
Drop the cursor FIXME from the total data rate calc (Paulo)
Use the "[PLANE:%d:%s]" format in debug print (Paulo)
Cc: Matt Roper
Cc: Paulo Zanoni
Cc: Maarten Lankhorst
Cc: Lyude
Signed-off-by: Ville Syrjälä
Reviewed-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_pm.c | 180 +---
1 file changed, 77 insertions(+), 103 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index bbb1eaf1e6db..e6351445016d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2867,28 +2867,6 @@ bool ilk_disable_lp_wm(struct drm_device *dev)
#define SKL_SAGV_BLOCK_TIME30 /* µs */
/*
- * Return the index of a plane in the SKL DDB and wm result arrays. Primary
- * plane is always in slot 0, cursor is always in slot I915_MAX_PLANES-1, and
- * other universal planes are in indices 1..n. Note that this may leave unused
- * indices between the top "sprite" plane and the cursor.
- */
-static int
-skl_wm_plane_id(const struct intel_plane *plane)
-{
- switch (plane->base.type) {
- case DRM_PLANE_TYPE_PRIMARY:
- return 0;
- case DRM_PLANE_TYPE_CURSOR:
- return PLANE_CURSOR;
- case DRM_PLANE_TYPE_OVERLAY:
- return plane->plane + 1;
- default:
- MISSING_CASE(plane->base.type);
- return plane->plane;
- }
-}
-
-/*
* FIXME: We still don't have the proper code detect if we need to apply the
WA,
* so assume we'll always need it in order to avoid underruns.
*/
@@ -3026,7 +3004,6 @@ bool intel_can_enable_sagv(struct drm_atomic_state *state)
struct intel_crtc *crtc;
struct intel_plane *plane;
struct intel_crtc_state *cstate;
- struct skl_plane_wm *wm;
enum pipe pipe;
int level, latency;
@@ -3053,7 +3030,8 @@ bool intel_can_enable_sagv(struct drm_atomic_state *state)
return false;
for_each_intel_plane_on_crtc(dev, crtc, plane) {
- wm = &cstate->wm.skl.optimal.planes[skl_wm_plane_id(plane)];
+ struct skl_plane_wm *wm =
+ &cstate->wm.skl.optimal.planes[plane->id];
/* Skip this plane if it's not enabled */
if (!wm->wm[0].plane_en)
@@ -3156,28 +3134,29 @@ static void skl_ddb_entry_init_from_hw(struct
skl_ddb_entry *entry, u32 reg)
void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
struct skl_ddb_allocation *ddb /* out */)
{
- enum pipe pipe;
- int plane;
- u32 val;
+ struct intel_crtc *crtc;
memset(ddb, 0, sizeof(*ddb));
- for_each_pipe(dev_priv, pipe) {
+ for_each_intel_crtc(&dev_priv->drm, crtc) {
enum intel_display_power_domain power_domain;
+ enum plane_id plane_id;
+ enum pipe pipe = crtc->pipe;
power_domain = POWER_DOMAIN_PIPE(pipe);
if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
continue;
- for_each_universal_plane(dev_priv, pipe, plane) {
- val = I915_READ(PLANE_BUF_CFG(pipe, plane));
- skl_ddb_entry_init_from_hw(&ddb->plane[pipe][plane],
- val);
- }
+ for_each_plane_id_on_crtc(crtc, plane_id) {
+ u32 val;
+
+ if (plane_id != PLANE_CURSOR)
+ val = I915_READ(PLANE_BUF_CFG(pipe, plane_id));
+ else
+ val = I915_READ(CUR_BUF_CFG(pipe));
- val = I915_READ(CUR_BUF_CFG(pipe));
- skl_ddb_entry_init_from_hw(&ddb->plane[pipe][PLANE_CURSOR],
- val);
+ skl_ddb_entry_init_from_hw(&ddb->plane[pipe][plane_id],
val);
+ }
intel_display_power_put(dev_priv, power_domain);
}
@@ -3278,30 +3257,28 @@ skl_get_total_relative_data_rate(struct
intel_crtc_state *intel_cstate,
struct drm_crtc_state *cstate = &intel_cstate->base;
struct drm_atomic_state *state = cstate->state;
struct drm_plane *plane;
- const struct intel_plane *intel_plane;
const struct drm_plane_state *pstate;
- unsigned int rate, total_data_rate = 0;
- int id;
+ unsigned int total_data_rate = 0;
if (WARN_ON(!state))
return 0;
/* Calculate and cache data rate for each plane */
drm_atomic_crtc_state_for_each_plane_state(plane, pstate, cstate) {
- id = skl_wm_plane_id(to_intel_plane(plane));
-
[Intel-gfx] [PATCH 1/9] drm/i915: Add per-pipe plane identifier
From: Ville Syrjälä
As I told people in [1] we really should not be confusing enum plane
as a per-pipe plane identifier. Looks like that happened nonetheless, so
let's fix it up by splitting the two into two enums.
We'll also want something we just directly pass to various register
offset macros and whatnot on SKL+. So let's make this new thing work for that.
Currently we pass intel_plane->plane for the "sprites" and just a
hardcoded zero for the "primary" planes. We want to get rid of that
hardocoding so that we can share the same code for all planes (apart
from the legacy cursor of course).
[1] https://lists.freedesktop.org/archives/intel-gfx/2015-September/076082.html
Cc: Matt Roper
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
Reviewed-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h | 28 +---
drivers/gpu/drm/i915/intel_display.c | 2 ++
drivers/gpu/drm/i915/intel_drv.h | 3 ++-
drivers/gpu/drm/i915/intel_sprite.c | 1 +
4 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c7d5f7a30fe8..6c9864287b29 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -180,22 +180,36 @@ static inline bool transcoder_is_dsi(enum transcoder
transcoder)
}
/*
- * I915_MAX_PLANES in the enum below is the maximum (across all platforms)
- * number of planes per CRTC. Not all platforms really have this many planes,
- * which means some arrays of size I915_MAX_PLANES may have unused entries
- * between the topmost sprite plane and the cursor plane.
+ * Global legacy plane identifier. Valid only for primary/sprite
+ * planes on pre-g4x, and only for primary planes on g4x+.
*/
enum plane {
- PLANE_A = 0,
+ PLANE_A,
PLANE_B,
PLANE_C,
- PLANE_CURSOR,
- I915_MAX_PLANES,
};
#define plane_name(p) ((p) + 'A')
#define sprite_name(p, s) ((p) * INTEL_INFO(dev_priv)->num_sprites[(p)] + (s)
+ 'A')
+/*
+ * Per-pipe plane identifier.
+ * I915_MAX_PLANES in the enum below is the maximum (across all platforms)
+ * number of planes per CRTC. Not all platforms really have this many planes,
+ * which means some arrays of size I915_MAX_PLANES may have unused entries
+ * between the topmost sprite plane and the cursor plane.
+ *
+ * This is expected to be passed to various register macros
+ * (eg. PLANE_CTL(), PS_PLANE_SEL(), etc.) so adjust with care.
+ */
+enum plane_id {
+ PLANE_PRIMARY,
+ PLANE_SPRITE0,
+ PLANE_SPRITE1,
+ PLANE_CURSOR,
+ I915_MAX_PLANES,
+};
+
enum port {
PORT_NONE = -1,
PORT_A = 0,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b7a7ed82c325..dfd3dbe6a92a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14988,6 +14988,7 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
primary->plane = (enum plane) !pipe;
else
primary->plane = (enum plane) pipe;
+ primary->id = PLANE_PRIMARY;
primary->frontbuffer_bit = INTEL_FRONTBUFFER_PRIMARY(pipe);
primary->check_plane = intel_check_primary_plane;
@@ -15187,6 +15188,7 @@ intel_cursor_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
cursor->max_downscale = 1;
cursor->pipe = pipe;
cursor->plane = pipe;
+ cursor->id = PLANE_CURSOR;
cursor->frontbuffer_bit = INTEL_FRONTBUFFER_CURSOR(pipe);
cursor->check_plane = intel_check_cursor_plane;
cursor->update_plane = intel_update_cursor_plane;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cd132c216a67..b2a0409330a9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -766,7 +766,8 @@ struct intel_plane_wm_parameters {
struct intel_plane {
struct drm_plane base;
- int plane;
+ u8 plane;
+ enum plane_id id;
enum pipe pipe;
bool can_scale;
int max_downscale;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 8f131a08d440..b5f750364e99 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1112,6 +1112,7 @@ intel_sprite_plane_create(struct drm_i915_private
*dev_priv,
intel_plane->pipe = pipe;
intel_plane->plane = plane;
+ intel_plane->id = PLANE_SPRITE0 + plane;
intel_plane->frontbuffer_bit = INTEL_FRONTBUFFER_SPRITE(pipe, plane);
intel_plane->check_plane = intel_check_sprite_plane;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 9/9] drm/i915: Rename the local 'plane' variable to 'plane_id' in primary plane code
From: Ville Syrjälä
Now we've rename the local plane id variable as 'plane_id' everywhere
except the pre-SKL primary plane code. Let's do the rename there as well
so that we'll free up the name 'plane' for use with struct intel_plane*.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 57 +---
1 file changed, 27 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f180f14fcf3a..a9b88749e897 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3001,10 +3001,9 @@ static void i9xx_update_primary_plane(struct drm_plane
*primary,
struct drm_i915_private *dev_priv = to_i915(primary->dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_framebuffer *fb = plane_state->base.fb;
- int plane = intel_crtc->plane;
+ enum plane plane_id = to_intel_plane(primary)->plane;
u32 linear_offset;
u32 dspcntr;
- i915_reg_t reg = DSPCNTR(plane);
unsigned int rotation = plane_state->base.rotation;
int x = plane_state->base.src.x1 >> 16;
int y = plane_state->base.src.y1 >> 16;
@@ -3020,16 +3019,16 @@ static void i9xx_update_primary_plane(struct drm_plane
*primary,
/* pipesrc and dspsize control the size that is scaled from,
* which should always be the user's requested size.
*/
- I915_WRITE(DSPSIZE(plane),
+ I915_WRITE(DSPSIZE(plane_id),
((crtc_state->pipe_src_h - 1) << 16) |
(crtc_state->pipe_src_w - 1));
- I915_WRITE(DSPPOS(plane), 0);
- } else if (IS_CHERRYVIEW(dev_priv) && plane == PLANE_B) {
- I915_WRITE(PRIMSIZE(plane),
+ I915_WRITE(DSPPOS(plane_id), 0);
+ } else if (IS_CHERRYVIEW(dev_priv) && plane_id == PLANE_B) {
+ I915_WRITE(PRIMSIZE(plane_id),
((crtc_state->pipe_src_h - 1) << 16) |
(crtc_state->pipe_src_w - 1));
- I915_WRITE(PRIMPOS(plane), 0);
- I915_WRITE(PRIMCNSTALPHA(plane), 0);
+ I915_WRITE(PRIMPOS(plane_id), 0);
+ I915_WRITE(PRIMCNSTALPHA(plane_id), 0);
}
switch (fb->pixel_format) {
@@ -3092,21 +3091,21 @@ static void i9xx_update_primary_plane(struct drm_plane
*primary,
intel_crtc->adjusted_x = x;
intel_crtc->adjusted_y = y;
- I915_WRITE(reg, dspcntr);
+ I915_WRITE(DSPCNTR(plane_id), dspcntr);
- I915_WRITE(DSPSTRIDE(plane), fb->pitches[0]);
+ I915_WRITE(DSPSTRIDE(plane_id), fb->pitches[0]);
if (INTEL_GEN(dev_priv) >= 4) {
- I915_WRITE(DSPSURF(plane),
+ I915_WRITE(DSPSURF(plane_id),
intel_fb_gtt_offset(fb, rotation) +
intel_crtc->dspaddr_offset);
- I915_WRITE(DSPTILEOFF(plane), (y << 16) | x);
- I915_WRITE(DSPLINOFF(plane), linear_offset);
+ I915_WRITE(DSPTILEOFF(plane_id), (y << 16) | x);
+ I915_WRITE(DSPLINOFF(plane_id), linear_offset);
} else {
- I915_WRITE(DSPADDR(plane),
+ I915_WRITE(DSPADDR(plane_id),
intel_fb_gtt_offset(fb, rotation) +
intel_crtc->dspaddr_offset);
}
- POSTING_READ(reg);
+ POSTING_READ(DSPCNTR(plane_id));
}
static void i9xx_disable_primary_plane(struct drm_plane *primary,
@@ -3114,15 +3113,14 @@ static void i9xx_disable_primary_plane(struct drm_plane
*primary,
{
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- int plane = intel_crtc->plane;
+ enum plane plane_id = to_intel_plane(primary)->plane;
- I915_WRITE(DSPCNTR(plane), 0);
+ I915_WRITE(DSPCNTR(plane_id), 0);
if (INTEL_INFO(dev_priv)->gen >= 4)
- I915_WRITE(DSPSURF(plane), 0);
+ I915_WRITE(DSPSURF(plane_id), 0);
else
- I915_WRITE(DSPADDR(plane), 0);
- POSTING_READ(DSPCNTR(plane));
+ I915_WRITE(DSPADDR(plane_id), 0);
+ POSTING_READ(DSPCNTR(plane_id));
}
static void ironlake_update_primary_plane(struct drm_plane *primary,
@@ -3133,10 +3131,9 @@ static void ironlake_update_primary_plane(struct
drm_plane *primary,
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_framebuffer *fb = plane_state->base.fb;
- int plane = intel_crtc->plane;
+ enum plane plane_id = to_intel_plane(primary)->plane;
u32 linear_offset;
u32 dspcntr;
- i915_reg_t reg = DSPCNTR(plane);
unsig
[Intel-gfx] [PATCH 8/9] drm/i915: Don't populate plane->plane for cursors and sprites
From: Ville Syrjälä
With plane->plane now purely reserved for the primary planes, let's
not even populate it for cursors and sprites. Let's switch the type
to enum plane as well since it's no longer being abused for anything
else.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 1 -
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_sprite.c | 1 -
3 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b6d5d5e5cc99..f180f14fcf3a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15188,7 +15188,6 @@ intel_cursor_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
cursor->can_scale = false;
cursor->max_downscale = 1;
cursor->pipe = pipe;
- cursor->plane = pipe;
cursor->id = PLANE_CURSOR;
cursor->frontbuffer_bit = INTEL_FRONTBUFFER_CURSOR(pipe);
cursor->check_plane = intel_check_cursor_plane;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c1b245853ba9..d14718e09911 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -767,7 +767,7 @@ struct intel_plane_wm_parameters {
struct intel_plane {
struct drm_plane base;
- u8 plane;
+ enum plane plane;
enum plane_id id;
enum pipe pipe;
bool can_scale;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 63154a5a9305..1044095d0084 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -,7 +,6 @@ intel_sprite_plane_create(struct drm_i915_private
*dev_priv,
}
intel_plane->pipe = pipe;
- intel_plane->plane = plane;
intel_plane->id = PLANE_SPRITE0 + plane;
intel_plane->frontbuffer_bit = INTEL_FRONTBUFFER_SPRITE(pipe, plane);
intel_plane->check_plane = intel_check_sprite_plane;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/9] drm/i915: Add a per-pipe plane identifier enum (v2)
From: Ville Syrjälä I ended up tweaking quite a few of the patches (and even adding a new one) based on Paulo's review, so figured I'd repost the entire thing. I didn't do the _ID_ rename thing, at least not yet. I'll have to think about it more if I could come up with some nice way to deal with the per-pipe id vs. the A/B/C plane id. Anyways, enough of these got r-bs so that I can at least move forward with VLV/CHV watermark rewrite #4 now. Ville Syrjälä (9): drm/i915: Add per-pipe plane identifier drm/i915: Add crtc->plane_ids_mask drm/i915: Use enum plane_id in SKL wm code drm/i915: Use enum plane_id in SKL plane code drm/i915: Use enum plane_id in VLV/CHV sprite code drm/i915: Use enum plane_id in VLV/CHV wm code drm/i915: s/plane/plane_id/ in skl+ plane register defines drm/i915: Don't populate plane->plane for cursors and sprites drm/i915: Rename the local 'plane' variable to 'plane_id' in primary plane code drivers/gpu/drm/i915/i915_drv.h | 30 - drivers/gpu/drm/i915/i915_reg.h | 104 +++--- drivers/gpu/drm/i915/intel_display.c | 96 ++--- drivers/gpu/drm/i915/intel_drv.h | 6 +- drivers/gpu/drm/i915/intel_pm.c | 253 --- drivers/gpu/drm/i915/intel_sprite.c | 118 6 files changed, 304 insertions(+), 303 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/9] drm/i915: Use enum plane_id in VLV/CHV wm code
From: Ville Syrjälä
Let's try not to abuse plane->plane for sprites on VLV/CHV and instead
use plane->id. Since out watermark structures aren't entirely plane type
agnostic (for now) and start indexing sprites from 0 we'll add a small
helper to convert between the two bases.
Signed-off-by: Ville Syrjälä
Reviewed-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_pm.c | 73 -
1 file changed, 36 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e6351445016d..2b4bdb3abb10 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -370,12 +370,15 @@ static const int pessimal_latency_ns = 5000;
#define VLV_FIFO_START(dsparb, dsparb2, lo_shift, hi_shift) \
dsparb) >> (lo_shift)) & 0xff) | dsparb2) >> (hi_shift)) & 0x1)
<< 8))
-static int vlv_get_fifo_size(struct drm_i915_private *dev_priv,
- enum pipe pipe, int plane)
+static int vlv_get_fifo_size(struct intel_plane *plane)
{
+ struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
int sprite0_start, sprite1_start, size;
- switch (pipe) {
+ if (plane->id == PLANE_CURSOR)
+ return 63;
+
+ switch (plane->pipe) {
uint32_t dsparb, dsparb2, dsparb3;
case PIPE_A:
dsparb = I915_READ(DSPARB);
@@ -399,24 +402,21 @@ static int vlv_get_fifo_size(struct drm_i915_private
*dev_priv,
return 0;
}
- switch (plane) {
- case 0:
+ switch (plane->id) {
+ case PLANE_PRIMARY:
size = sprite0_start;
break;
- case 1:
+ case PLANE_SPRITE0:
size = sprite1_start - sprite0_start;
break;
- case 2:
+ case PLANE_SPRITE1:
size = 512 - 1 - sprite1_start;
break;
default:
return 0;
}
- DRM_DEBUG_KMS("Pipe %c %s %c FIFO size: %d\n",
- pipe_name(pipe), plane == 0 ? "primary" : "sprite",
- plane == 0 ? plane_name(pipe) : sprite_name(pipe, plane -
1),
- size);
+ DRM_DEBUG_KMS("%s FIFO size: %d\n", plane->base.name, size);
return size;
}
@@ -1053,6 +1053,12 @@ static void vlv_compute_fifo(struct intel_crtc *crtc)
WARN_ON(fifo_left != 0);
}
+/* FIXME kill me */
+static inline int vlv_sprite_id(enum plane_id plane_id)
+{
+ return plane_id - PLANE_SPRITE0;
+}
+
static void vlv_invert_wms(struct intel_crtc *crtc)
{
struct vlv_wm_state *wm_state = &crtc->wm_state;
@@ -1079,7 +1085,7 @@ static void vlv_invert_wms(struct intel_crtc *crtc)
wm_state->wm[level].primary;
break;
case DRM_PLANE_TYPE_OVERLAY:
- sprite = plane->plane;
+ sprite = vlv_sprite_id(plane->id);
wm_state->wm[level].sprite[sprite] =
plane->wm.fifo_size -
wm_state->wm[level].sprite[sprite];
break;
@@ -1144,7 +1150,7 @@ static void vlv_compute_wm(struct intel_crtc *crtc)
wm_state->wm[level].primary = wm;
break;
case DRM_PLANE_TYPE_OVERLAY:
- sprite = plane->plane;
+ sprite = vlv_sprite_id(plane->id);
wm_state->wm[level].sprite[sprite] = wm;
break;
}
@@ -1170,7 +1176,7 @@ static void vlv_compute_wm(struct intel_crtc *crtc)
wm_state->wm[level].primary);
break;
case DRM_PLANE_TYPE_OVERLAY:
- sprite = plane->plane;
+ sprite = vlv_sprite_id(plane->id);
for (level = 0; level < wm_state->num_levels; level++)
wm_state->sr[level].plane =
min(wm_state->sr[level].plane,
@@ -1199,17 +1205,23 @@ static void vlv_pipe_set_fifo_size(struct intel_crtc
*crtc)
int sprite0_start = 0, sprite1_start = 0, fifo_size = 0;
for_each_intel_plane_on_crtc(dev, crtc, plane) {
- if (plane->base.type == DRM_PLANE_TYPE_CURSOR) {
- WARN_ON(plane->wm.fifo_size != 63);
- continue;
- }
-
- if (plane->base.type == DRM_PLANE_TYPE_PRIMARY)
+ switch (plane->id) {
+ case PLANE_PRIMARY:
sprite0_start = plane->wm.fifo_size;
- else if (plane->plane == 0)
+ break;
+ case PLANE_SPRITE0:
[Intel-gfx] [PATCH 5/9] drm/i915: Use enum plane_id in VLV/CHV sprite code
From: Ville Syrjälä
Use intel_plane->id to derive the VLV/CHV sprite register offsets
instead of abusing plane->plane which is really meant to for
primary planes only.
v2: Convert assert_sprites_disabled() over as well
v3: Rename the reg macro parameter to 'plane_id' as well (Paulo)
Signed-off-by: Ville Syrjälä
Reviewed-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_reg.h | 58 +++-
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_sprite.c | 74 ++--
3 files changed, 70 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c70c07a7b586..d03491089f9c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5374,18 +5374,21 @@ enum {
#define _SPBCONSTALPHA (VLV_DISPLAY_BASE + 0x722a8)
#define _SPBGAMC (VLV_DISPLAY_BASE + 0x722f4)
-#define SPCNTR(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPACNTR,
_SPBCNTR)
-#define SPLINOFF(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPALINOFF,
_SPBLINOFF)
-#define SPSTRIDE(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPASTRIDE,
_SPBSTRIDE)
-#define SPPOS(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPAPOS, _SPBPOS)
-#define SPSIZE(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPASIZE,
_SPBSIZE)
-#define SPKEYMINVAL(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
_SPAKEYMINVAL, _SPBKEYMINVAL)
-#define SPKEYMSK(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPAKEYMSK,
_SPBKEYMSK)
-#define SPSURF(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPASURF,
_SPBSURF)
-#define SPKEYMAXVAL(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
_SPAKEYMAXVAL, _SPBKEYMAXVAL)
-#define SPTILEOFF(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPATILEOFF,
_SPBTILEOFF)
-#define SPCONSTALPHA(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
_SPACONSTALPHA, _SPBCONSTALPHA)
-#define SPGAMC(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPAGAMC,
_SPBGAMC)
+#define _MMIO_VLV_SPR(pipe, plane_id, reg_a, reg_b) \
+ _MMIO_PIPE((pipe) * 2 + (plane_id) - PLANE_SPRITE0, (reg_a), (reg_b))
+
+#define SPCNTR(pipe, plane_id) _MMIO_VLV_SPR((pipe), (plane_id),
_SPACNTR, _SPBCNTR)
+#define SPLINOFF(pipe, plane_id) _MMIO_VLV_SPR((pipe), (plane_id),
_SPALINOFF, _SPBLINOFF)
+#define SPSTRIDE(pipe, plane_id) _MMIO_VLV_SPR((pipe), (plane_id),
_SPASTRIDE, _SPBSTRIDE)
+#define SPPOS(pipe, plane_id) _MMIO_VLV_SPR((pipe), (plane_id),
_SPAPOS, _SPBPOS)
+#define SPSIZE(pipe, plane_id) _MMIO_VLV_SPR((pipe), (plane_id),
_SPASIZE, _SPBSIZE)
+#define SPKEYMINVAL(pipe, plane_id)_MMIO_VLV_SPR((pipe), (plane_id),
_SPAKEYMINVAL, _SPBKEYMINVAL)
+#define SPKEYMSK(pipe, plane_id) _MMIO_VLV_SPR((pipe), (plane_id),
_SPAKEYMSK, _SPBKEYMSK)
+#define SPSURF(pipe, plane_id) _MMIO_VLV_SPR((pipe), (plane_id),
_SPASURF, _SPBSURF)
+#define SPKEYMAXVAL(pipe, plane_id)_MMIO_VLV_SPR((pipe), (plane_id),
_SPAKEYMAXVAL, _SPBKEYMAXVAL)
+#define SPTILEOFF(pipe, plane_id) _MMIO_VLV_SPR((pipe), (plane_id),
_SPATILEOFF, _SPBTILEOFF)
+#define SPCONSTALPHA(pipe, plane_id) _MMIO_VLV_SPR((pipe), (plane_id),
_SPACONSTALPHA, _SPBCONSTALPHA)
+#define SPGAMC(pipe, plane_id) _MMIO_VLV_SPR((pipe), (plane_id),
_SPAGAMC, _SPBGAMC)
/*
* CHV pipe B sprite CSC
@@ -5394,29 +5397,32 @@ enum {
* |yg| = |c3 c4 c5| x |yg + yg_ioff| + |yg_ooff|
* |cb| |c6 c7 c8| |cb + cr_ioff| |cb_ooff|
*/
-#define SPCSCYGOFF(sprite) _MMIO(VLV_DISPLAY_BASE + 0x6d900 + (sprite) *
0x1000)
-#define SPCSCCBOFF(sprite) _MMIO(VLV_DISPLAY_BASE + 0x6d904 + (sprite) *
0x1000)
-#define SPCSCCROFF(sprite) _MMIO(VLV_DISPLAY_BASE + 0x6d908 + (sprite) *
0x1000)
+#define _MMIO_CHV_SPCSC(plane_id, reg) \
+ _MMIO(VLV_DISPLAY_BASE + ((plane_id) - PLANE_SPRITE0) * 0x1000 + (reg))
+
+#define SPCSCYGOFF(plane_id) _MMIO_CHV_SPCSC(plane_id, 0x6d900)
+#define SPCSCCBOFF(plane_id) _MMIO_CHV_SPCSC(plane_id, 0x6d904)
+#define SPCSCCROFF(plane_id) _MMIO_CHV_SPCSC(plane_id, 0x6d908)
#define SPCSC_OOFF(x) (((x) & 0x7ff) << 16) /* s11 */
#define SPCSC_IOFF(x) (((x) & 0x7ff) << 0) /* s11 */
-#define SPCSCC01(sprite) _MMIO(VLV_DISPLAY_BASE + 0x6d90c + (sprite) *
0x1000)
-#define SPCSCC23(sprite) _MMIO(VLV_DISPLAY_BASE + 0x6d910 + (sprite) *
0x1000)
-#define SPCSCC45(sprite) _MMIO(VLV_DISPLAY_BASE + 0x6d914 + (sprite) *
0x1000)
-#define SPCSCC67(sprite) _MMIO(VLV_DISPLAY_BASE + 0x6d918 + (sprite) *
0x1000)
-#define SPCSCC8(sprite)_MMIO(VLV_DISPLAY_BASE + 0x6d91c +
(sprite) * 0x1000)
+#define SPCSCC01(plane_id) _MMIO_CHV_SPCSC(plane_id, 0x6d90c)
+#define SPCSCC23(plane_id) _MMIO_CHV_SPCSC(plane_id, 0x6d910)
+#define SPCSCC45(plane_id) _MMIO_CHV_SPCSC(plane_id, 0x6d914)
+#define SPCSCC67(plane_id) _MMIO_CHV_SPCSC(plane_id, 0x6d918)
+#define SPCSCC8(plane_id) _MMIO_CHV_SPCSC(plane_id, 0x6d9
Re: [Intel-gfx] [PATCH] dim: Enable --scissors by default
On Tue, 22 Nov 2016, Daniel Vetter wrote: > I never knew this even was a thing, and plain git am cuts everything > below the scissors line (since it matches the --- of a diffstat > start). > > Cc: Robert Bragg > Signed-off-by: Daniel Vetter > --- > dim | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dim b/dim > index 8697eaee92cc..0b437c9c0a18 100755 > --- a/dim > +++ b/dim > @@ -556,7 +556,7 @@ function dim_apply_branch > sob=-s > fi > > - cat $file | git am -3 $sob "$@" > + cat $file | git am --scissors -3 $sob "$@" Side note, -3 rarely helps for us because nightly moves on, and the tree info in the patch is lost. BR, Jani. > > if [ -n "$message_id" ]; then > dim_commit_add_tag "Link: > http://patchwork.freedesktop.org/patch/msgid/$message_id"; -- 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] ✗ Fi.CI.BAT: failure for drm/i915: Integrate i915_sw_fence with debugobjects
== Series Details == Series: drm/i915: Integrate i915_sw_fence with debugobjects URL : https://patchwork.freedesktop.org/series/15747/ State : failure == Summary == Series 15747v1 drm/i915: Integrate i915_sw_fence with debugobjects https://patchwork.freedesktop.org/api/1.0/series/15747/revisions/1/mbox/ Test drv_module_reload_basic: dmesg-warn -> PASS (fi-skl-6770hq) Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (fi-byt-j1900) Test kms_force_connector_basic: Subgroup force-edid: pass -> DMESG-WARN (fi-snb-2520m) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:215 dwarn:0 dfail:0 fail:1 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:244 pass:211 dwarn:1 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 eeec5e7742b23082dd20523c8baa08fe495175e4 drm-intel-nightly: 2016y-11m-21d-18h-22m-22s UTC integration manifest 5284697 drm/i915: Integrate i915_sw_fence with debugobjects == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3080/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt v4 12/13] igt/gem_exec_parse: update registers test for v >= 8
On Mon, Nov 14, 2016 at 08:51:21PM +, Robert Bragg wrote: > This combines some parts of the recently added store_lri test with the > registers test to be able to first load a distinguishable value before > the LRI and explicitly read back the register to determine if the > command succeeded or was a NOOP. > > For now though we won't look at OACONTROL without checking for version 9 > of the command parser. > > This updates the 'bad' test to check the OASTATUS2 register so that we > can explicitly read back from the register to check it becomes a NOOP. > > This adds a struct test_lri for associating a mask with the init/test > values so we ignore things like hw status bits that might interfere > with the result. > > Signed-off-by: Robert Bragg > Reviewed-by: Matthew Auld > --- > tests/gem_exec_parse.c | 94 > ++ > 1 file changed, 49 insertions(+), 45 deletions(-) > > diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c > index 2bc6340..43f25ce 100644 > --- a/tests/gem_exec_parse.c > +++ b/tests/gem_exec_parse.c > @@ -35,6 +35,7 @@ > #endif > > #define DERRMR 0x44050 > +#define OASTATUS2 0x2368 > #define OACONTROL 0x2360 > #define SO_WRITE_OFFSET_0 0x5280 > > @@ -253,27 +254,35 @@ static void exec_batch_chained(int fd, uint32_t cmd_bo, > uint32_t *cmds, > gem_close(fd, target_bo); > } > > -static void stray_lri(int fd, uint32_t handle) Ahem. Why did you remove that agnostic test without replacing it? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: don't whitelist oacontrol in cmd parser
On Tue, Nov 22, 2016 at 02:09:08PM +, Robert Bragg wrote:
> On Tue, Nov 22, 2016 at 1:34 PM, Daniel Vetter wrote:
>
> > On Tue, Nov 08, 2016 at 12:51:48PM +, Robert Bragg wrote:
> > > This v2 patch bumps the command parser version so it can be referenced in
> > > corresponding i-g-t gem_exec_parse changes.
> > >
> > > --- >8 ---
> >
> > Scissors cut everything below, not everything above, hence next time
> > around pls switch around your comment and the commit message, as-is not
> > much left ;-)
> >
>
> Hmm, they cut away what's above and keep what's below in my experience -
> what command are you seeing the opposite with?
>
> I just double checked this with git am --scissors
Plain git am works the other way round, that's why I never noticed there's
a special option. TIL ;-)
-Daniel
>
> - Robert
>
>
>
> >
> > Fixed up while applying.
> > -Daniel
> >
> > >
> > > Being able to program OACONTROL from a non-privileged batch buffer is
> > > not sufficient to be able to configure the OA unit. This was originally
> > > allowed to help enable Mesa to expose OA counters via the
> > > INTEL_performance_query extension, but the current implementation based
> > > on programming OACONTROL via a batch buffer isn't able to report useable
> > > data without a more complete OA unit configuration. Mesa handles the
> > > possibility that writes to OACONTROL may not be allowed and so only
> > > advertises the extension after explicitly testing that a write to
> > > OACONTROL succeeds. Based on this; removing OACONTROL from the whitelist
> > > should be ok for userspace.
> > >
> > > Removing this simplifies adding a new kernel api for configuring the OA
> > > unit without needing to consider the possibility that userspace might
> > > trample on OACONTROL state which we'd like to start managing within
> > > the kernel instead. In particular running any Mesa based GL application
> > > currently results in clearing OACONTROL when initializing which would
> > > disable the capturing of metrics.
> > >
> > > v2:
> > > This bumps the command parser version from 8 to 9, as the change is
> > > visible to userspace.
> > >
> > > Signed-off-by: Robert Bragg
> > > Reviewed-by: Matthew Auld
> > > Reviewed-by: Sourab Gupta
> > > ---
> > > drivers/gpu/drm/i915/i915_cmd_parser.c | 42
> > --
> > > 1 file changed, 5 insertions(+), 37 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
> > b/drivers/gpu/drm/i915/i915_cmd_parser.c
> > > index c9d2ecd..f5762cd 100644
> > > --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
> > > +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
> > > @@ -450,7 +450,6 @@ static const struct drm_i915_reg_descriptor
> > gen7_render_regs[] = {
> > > REG64(PS_INVOCATION_COUNT),
> > > REG64(PS_DEPTH_COUNT),
> > > REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE),
> > > - REG32(GEN7_OACONTROL), /* Only allowed for LRI and SRM. See below.
> > */
> > > REG64(MI_PREDICATE_SRC0),
> > > REG64(MI_PREDICATE_SRC1),
> > > REG32(GEN7_3DPRIM_END_OFFSET),
> > > @@ -1060,8 +1059,7 @@ bool intel_engine_needs_cmd_parser(struct
> > intel_engine_cs *engine)
> > > static bool check_cmd(const struct intel_engine_cs *engine,
> > > const struct drm_i915_cmd_descriptor *desc,
> > > const u32 *cmd, u32 length,
> > > - const bool is_master,
> > > - bool *oacontrol_set)
> > > + const bool is_master)
> > > {
> > > if (desc->flags & CMD_DESC_SKIP)
> > > return true;
> > > @@ -1099,31 +1097,6 @@ static bool check_cmd(const struct
> > intel_engine_cs *engine,
> > > }
> > >
> > > /*
> > > - * OACONTROL requires some special handling for
> > > - * writes. We want to make sure that any batch
> > which
> > > - * enables OA also disables it before the end of
> > the
> > > - * batch. The goal is to prevent one process from
> > > - * snooping on the perf data from another process.
> > To do
> > > - * that, we need to check the value that will be
> > written
> > > - * to the register. Hence, limit OACONTROL writes
> > to
> > > - * only MI_LOAD_REGISTER_IMM commands.
> > > - */
> > > - if (reg_addr ==
> > > i915_mmio_reg_offset(GEN7_OACONTROL))
> > {
> > > - if (desc->cmd.value ==
> > MI_LOAD_REGISTER_MEM) {
> > > - DRM_DEBUG_DRIVER("CMD: Rejected
> > LRM to OACONTROL\n");
> > > - return false;
> > > - }
> > > -
> > > - if (desc->cmd.value ==
> > MI_LOAD_REGISTER_REG) {
> > > - DRM_DEBUG_DRIVER("CM
Re: [Intel-gfx] [PATCH] drm/i915: Moving no of scalers initialization to runtime init
On Tue, Nov 22, 2016 at 05:31:05PM +0530, Nabendu Maiti wrote:
Try to avoid confusing contractions (i.e. no no) and give us a verb in
that sentence in that Subject line.
> Number of scalers initialization is moved to runtime init from
> intel_crtc_init for platform specific initialization.
so that... Tell us why!
> Signed-off-by: Nabendu Maiti
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_device_info.c | 3 +++
> drivers/gpu/drm/i915/intel_display.c | 10 ++
> drivers/gpu/drm/i915/intel_drv.h | 4 ++--
> 5 files changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index b7f42c4..8349abe 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3080,7 +3080,7 @@ static void intel_scaler_info(struct seq_file *m,
> struct intel_crtc *intel_crtc)
> pipe_config->scaler_state.scaler_users,
> pipe_config->scaler_state.scaler_id);
>
> - for (i = 0; i < SKL_NUM_SCALERS; i++) {
> + for (i = 0; i < num_scalers; i++) {
> struct intel_scaler *sc =
> &pipe_config->scaler_state.scalers[i];
Already applied.
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index be67aee..6eed9c2 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -731,6 +731,7 @@ struct intel_device_info {
> u16 device_id;
> u8 num_pipes;
> u8 num_sprites[I915_MAX_PIPES];
> + u8 num_scalers[I915_MAX_PIPES];
> u8 gen;
> u16 gen_mask;
> u8 ring_mask; /* Rings supported by the HW */
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> b/drivers/gpu/drm/i915/intel_device_info.c
> index 185e3bb..ef26fa8 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -282,6 +282,9 @@ void intel_device_info_runtime_init(struct
> drm_i915_private *dev_priv)
> info->num_sprites[PIPE_A] = 2;
> info->num_sprites[PIPE_B] = 2;
> info->num_sprites[PIPE_C] = 1;
> + info->num_scalers[PIPE_A] = 2;
> + info->num_scalers[PIPE_B] = 2;
> + info->num_scalers[PIPE_C] = 1;
> } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> for_each_pipe(dev_priv, pipe)
> info->num_sprites[pipe] = 2;
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index bd2c99e..d2023c4 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15269,14 +15269,8 @@ static int intel_crtc_init(struct drm_i915_private
> *dev_priv, enum pipe pipe)
> crtc_state->base.crtc = &intel_crtc->base;
>
> /* initialize shared scalers */
> - if (INTEL_GEN(dev_priv) >= 9) {
> - if (pipe == PIPE_C)
> - intel_crtc->num_scalers = 1;
> - else
> - intel_crtc->num_scalers = SKL_NUM_SCALERS;
> -
> - skl_init_scalers(dev_priv, intel_crtc, crtc_state);
> - }
> + intel_crtc->num_scalers = dev_priv->info.num_scalers[pipe];
Double space after =.
> + skl_init_scalers(dev_priv, intel_crtc, crtc_state);
Now called for everybody, not just gen9+. Why? Is it safe? If it was
safe it would not be called skl_*(). intel_crtc->num_scalers is now a
candidate for including in init_scalers().
> primary = intel_primary_plane_create(dev_priv, pipe);
> if (IS_ERR(primary)) {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index cd132c2..3f89607 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -430,8 +430,8 @@ struct intel_scaler {
> };
>
> struct intel_crtc_scaler_state {
> -#define SKL_NUM_SCALERS 2
> - struct intel_scaler scalers[SKL_NUM_SCALERS];
> +#define MAX_NUM_SCALERS 2
> + struct intel_scaler scalers[MAX_NUM_SCALERS];
Replaced the gen marker rather than the abreviation. So now we have
what reads as NUM_NUM_SCALERS.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/lspcon: Remove unused force change mode parameter
The reason why I kept the force function was, that during debug phase, I
saw a need to change LSPCON mode.
Also, in future, if we need to provide an IOCTL/control to userspace, to
change lspcon mode, force may be required
to differentiate the path from user/kernel space.
But in any case: Reviewed-by: Shashank Sharma
Regards
Shashank
On 11/22/2016 12:45 AM, Imre Deak wrote:
All callers asked for a forced change but the function ignored this
parameter. It doesn't seem to be necessary to force the change in any
case so let's just remove the parameter.
Cc: Shashank Sharma
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_lspcon.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
b/drivers/gpu/drm/i915/intel_lspcon.c
index 281127d..f6d4e69 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -87,7 +87,7 @@ static enum drm_lspcon_mode lspcon_wait_mode(struct
intel_lspcon *lspcon,
}
static int lspcon_change_mode(struct intel_lspcon *lspcon,
- enum drm_lspcon_mode mode, bool force)
+ enum drm_lspcon_mode mode)
{
int err;
enum drm_lspcon_mode current_mode;
@@ -202,7 +202,7 @@ void lspcon_resume(struct intel_lspcon *lspcon)
if (lspcon_wait_mode(lspcon, expected_mode) == DRM_LSPCON_MODE_PCON)
return;
- if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON, true))
+ if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON))
DRM_ERROR("LSPCON resume failed\n");
else
DRM_DEBUG_KMS("LSPCON resume success\n");
@@ -239,8 +239,7 @@ bool lspcon_init(struct intel_digital_port *intel_dig_port)
* 2.0 sinks.
*/
if (lspcon->active && lspcon->mode != DRM_LSPCON_MODE_PCON) {
- if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON,
- true) < 0) {
+ if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON) < 0) {
DRM_ERROR("LSPCON mode change to PCON failed\n");
return false;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] dim: Enable --scissors by default
I never knew this even was a thing, and plain git am cuts everything below the scissors line (since it matches the --- of a diffstat start). Cc: Robert Bragg Signed-off-by: Daniel Vetter --- dim | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dim b/dim index 8697eaee92cc..0b437c9c0a18 100755 --- a/dim +++ b/dim @@ -556,7 +556,7 @@ function dim_apply_branch sob=-s fi - cat $file | git am -3 $sob "$@" + cat $file | git am --scissors -3 $sob "$@" if [ -n "$message_id" ]; then dim_commit_add_tag "Link: http://patchwork.freedesktop.org/patch/msgid/$message_id"; -- 2.10.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 01/11] drm/i915: Add i915 perf infrastructure
On Tue, Nov 22, 2016 at 02:02:38PM +, Robert Bragg wrote:
> On Tue, Nov 22, 2016 at 1:31 PM, Daniel Vetter wrote:
>
> > On Tue, Nov 22, 2016 at 02:29:18PM +0100, Daniel Vetter wrote:
> > > On Wed, Nov 09, 2016 at 08:00:06PM +, Matthew Auld wrote:
> > > > On 7 November 2016 at 19:49, Robert Bragg
> > wrote:
> > > > > Adds base i915 perf infrastructure for Gen performance metrics.
> > > > >
> > > > > This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of
> > uint64
> > > > > properties to configure a stream of metrics and returns a new fd
> > usable
> > > > > with standard VFS system calls including read() to read typed and
> > sized
> > > > > records; ioctl() to enable or disable capture and poll() to wait for
> > > > > data.
> > > > >
> > > > > A stream is opened something like:
> > > > >
> > > > > uint64_t properties[] = {
> > > > > /* Single context sampling */
> > > > > DRM_I915_PERF_PROP_CTX_HANDLE,ctx_handle,
> > > > >
> > > > > /* Include OA reports in samples */
> > > > > DRM_I915_PERF_PROP_SAMPLE_OA, true,
> > > > >
> > > > > /* OA unit configuration */
> > > > > DRM_I915_PERF_PROP_OA_METRICS_SET,metrics_set_id,
> > > > > DRM_I915_PERF_PROP_OA_FORMAT, report_format,
> > > > > DRM_I915_PERF_PROP_OA_EXPONENT, period_exponent,
> > > > >};
> > > > >struct drm_i915_perf_open_param parm = {
> > > > > .flags = I915_PERF_FLAG_FD_CLOEXEC |
> > > > >I915_PERF_FLAG_FD_NONBLOCK |
> > > > >I915_PERF_FLAG_DISABLED,
> > > > > .properties_ptr = (uint64_t)properties,
> > > > > .num_properties = sizeof(properties) / 16,
> > > > >};
> > > > >int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, ¶m);
> > > > >
> > > > > Records read all start with a common { type, size } header with
> > > > > DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
> > > > > contain an extensible number of fields and it's the
> > > > > DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
> > > > > determine what's included in every sample.
> > > > >
> > > > > No specific streams are supported yet so any attempt to open a stream
> > > > > will return an error.
> > > > >
> > > > > v2:
> > > > > use i915_gem_context_get() - Chris Wilson
> > > > > v3:
> > > > > update read() interface to avoid passing state struct - Chris
> > Wilson
> > > > > fix some rebase fallout, with i915-perf init/deinit
> > > > > v4:
> > > > > s/DRM_IORW/DRM_IOW/ - Emil Velikov
> > > > >
> > > > > Signed-off-by: Robert Bragg
> > > > > Reviewed-by: Matthew Auld
> > > > > Reviewed-by: Sourab Gupta
> > > > Minor nit, there are a fair few DRM_ERROR's missing a new line.
> > >
> > > Also, DRM_ERROR for userspace-triggerable failures is no good. igt
> > > testcase are supposed to exercise all the invalid stuff, and would then
> > > fail if you spam dmesg. Why was this not caught?
> > >
> > > Fixup patch totally fine, but if this wasn't caught due to missing igt
> > > that needs to be fixed, too.
> >
> > Another nitpick for the future: Enabling new features first and then
> > fixing up the fallout is the wrong way round, if someone bisects over this
> > range mesa might blow up in really bad ways.
> >
> > Oh well, this has been out there for way too long, so meh.
> >
>
> Fwiw I'm aware of this, and think I've ordered the patches correctly to
> avoid bisect problems in Mesa / userspace. This infrastructure patch should
> have no fallout to fix for userspace. The command parser changes that
> affect userspace were done before adding oacontrol usage to i915-perf and
> the cmd parser's EINVAL reporting for access failures was changed *before*
> removing oacontrol from the whitelist.
>
> Did I overlook something in particular?
Ah, if you key the userspace side off the cmd parser change then I think
it should be all fine. I only looked at this ioctl here, and that alone
looked like it was unsafe. Ordering of the patches later on seemed correct
indeed.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/lspcon: Wait for expected LSPCON mode to settle
Regards
Shashank
On 11/22/2016 12:45 AM, Imre Deak wrote:
Some LSPCON adaptors may return an incorrect LSPCON mode right after
waking from DP Sleep state. This is the case at least for the ParadTech
PS175 adaptor, both when waking because of exiting the DP Sleep to
active state, or due to any other AUX CH transfer. We can determine the
current expected mode based on whether the DPCD area is accessible,
since according to the LSPCON spec this area is only accesible
in PCON mode.
This wait will avoid us trying to change the mode, while the current
expected mode hasn't settled yet and start link training before the
adaptor thinks it's in PCON mode after waking from DP Sleep state.
Cc: Shashank Sharma
Cc: Ville Syrjälä
Cc: Jani Nikula
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_dp.c | 5 +++
drivers/gpu/drm/i915/intel_drv.h| 1 +
drivers/gpu/drm/i915/intel_lspcon.c | 70 -
3 files changed, 68 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 16c19d78..8026a83 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2401,6 +2401,8 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int
mode)
ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER,
DP_SET_POWER_D3);
} else {
+ struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
+
/*
* When turning on, we need to retry for 1ms to give the sink
* time to wake up.
@@ -2412,6 +2414,9 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int
mode)
break;
msleep(1);
}
+
+ if (ret == 1 && lspcon->active)
+ lspcon_wait_pcon_mode(lspcon);
}
if (ret != 1)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cf47e8a..d165904 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1830,4 +1830,5 @@ void intel_color_load_luts(struct drm_crtc_state
*crtc_state);
/* intel_lspcon.c */
bool lspcon_init(struct intel_digital_port *intel_dig_port);
void lspcon_resume(struct intel_lspcon *lspcon);
+void lspcon_wait_pcon_mode(struct intel_lspcon *lspcon);
#endif /* __INTEL_DRV_H__ */
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
b/drivers/gpu/drm/i915/intel_lspcon.c
index 5013124..281127d 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -35,16 +35,54 @@ static struct intel_dp *lspcon_to_intel_dp(struct
intel_lspcon *lspcon)
return &dig_port->dp;
}
+static const char *lspcon_mode_name(enum drm_lspcon_mode mode)
+{
+ switch (mode) {
+ case DRM_LSPCON_MODE_PCON:
+ return "PCON";
+ case DRM_LSPCON_MODE_LS:
+ return "LS";
+ case DRM_LSPCON_MODE_INVALID:
+ return "INVALID";
+ default:
+ MISSING_CASE(mode);
+ return "INVALID";
+ }
+}
+
static enum drm_lspcon_mode lspcon_get_current_mode(struct intel_lspcon
*lspcon)
{
- enum drm_lspcon_mode current_mode = DRM_LSPCON_MODE_INVALID;
+ enum drm_lspcon_mode current_mode;
struct i2c_adapter *adapter = &lspcon_to_intel_dp(lspcon)->aux.ddc;
- if (drm_lspcon_get_mode(adapter, ¤t_mode))
+ if (drm_lspcon_get_mode(adapter, ¤t_mode)) {
DRM_ERROR("Error reading LSPCON mode\n");
- else
- DRM_DEBUG_KMS("Current LSPCON mode %s\n",
- current_mode == DRM_LSPCON_MODE_PCON ? "PCON" : "LS");
+ return DRM_LSPCON_MODE_INVALID;
+ }
+ return current_mode;
+}
+
+static enum drm_lspcon_mode lspcon_wait_mode(struct intel_lspcon *lspcon,
+enum drm_lspcon_mode mode)
+{
+ enum drm_lspcon_mode current_mode;
+
+ current_mode = lspcon_get_current_mode(lspcon);
+ if (current_mode == mode || current_mode == DRM_LSPCON_MODE_INVALID)
+ goto out;
+
+ DRM_DEBUG_KMS("Waiting for LSPCON mode %s to settle\n",
+ lspcon_mode_name(mode));
+
Can we remove above lines, and start from below lines ? I guess wait_for
checks the condition first and
then executes wait ? Also, a comment stating 100ms wait ?
- Shashank
+ wait_for((current_mode = lspcon_get_current_mode(lspcon)) == mode ||
+current_mode == DRM_LSPCON_MODE_INVALID, 100);
+ if (current_mode != mode)
+ DRM_DEBUG_KMS("LSPCON mode hasn't settled\n");
+
+out:
+ DRM_DEBUG_KMS("Current LSPCON mode %s\n",
+ lspcon_mode_name(current_mode));
+
return current_mode;
}
@@ -97,8 +135,10 @@ static bool lspcon_probe(struct intel_lspcon *lspcon)
{
enum drm_dp_dual_mode_type adap
[Intel-gfx] [drm-intel:drm-intel-next-queued 6/11] undefined reference to `__udivdi3'
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: 7abbd8d670bb928366aa94332a173aa3d394ebfe commit: d79651522e89c4ffa8992b48dfe449f0c583f809 [6/11] drm/i915: Enable i915 perf stream for Haswell OA unit config: i386-defconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: git checkout d79651522e89c4ffa8992b48dfe449f0c583f809 # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): drivers/built-in.o: In function `i915_perf_open_ioctl': >> (.text+0x19a6f8): undefined reference to `__udivdi3' drivers/built-in.o: In function `i915_perf_open_ioctl': (.text+0x19a714): undefined reference to `__udivdi3' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for lib/debugobjects: Export for use in modules (rev2)
== Series Details == Series: lib/debugobjects: Export for use in modules (rev2) URL : https://patchwork.freedesktop.org/series/15743/ State : success == Summary == Series 15743v2 lib/debugobjects: Export for use in modules https://patchwork.freedesktop.org/api/1.0/series/15743/revisions/2/mbox/ Test drv_module_reload_basic: dmesg-warn -> PASS (fi-skl-6770hq) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 eeec5e7742b23082dd20523c8baa08fe495175e4 drm-intel-nightly: 2016y-11m-21d-18h-22m-22s UTC integration manifest 4365fec lib/debugobjects: Export for use in modules == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3079/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/4] drm/i915: Disable hangcheck when wedged
If the gpu reset fails and the machine is terminally wedged, further hangchecks achieve nothing but noise. Disable them, with a corollary that we re-enable hangchecking after a successful GPU reset in case the user is artificially bringing the machine back to life through the debug interface. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_drv.c| 2 ++ drivers/gpu/drm/i915/intel_hangcheck.c | 3 +++ 2 files changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 445fec9c2841..d3ee72449025 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1814,6 +1814,8 @@ void i915_reset(struct drm_i915_private *dev_priv) goto error; } + i915_queue_hangcheck(dev_priv); + wakeup: wake_up_bit(&error->flags, I915_RESET_IN_PROGRESS); return; diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c b/drivers/gpu/drm/i915/intel_hangcheck.c index c03db022a6d8..f05971f5586f 100644 --- a/drivers/gpu/drm/i915/intel_hangcheck.c +++ b/drivers/gpu/drm/i915/intel_hangcheck.c @@ -434,6 +434,9 @@ static void i915_hangcheck_elapsed(struct work_struct *work) if (!READ_ONCE(dev_priv->gt.awake)) return; + if (i915_terminally_wedged(&dev_priv->gpu_error)) + return; + /* As enabling the GPU requires fairly extensive mmio access, * periodically arm the mmio checker to see if we are triggering * any invalid access. -- 2.10.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/4] drm/i915: Complete requests in nop_submit_request
Since the submit/execute split in commit d55ac5bf97c6 ("drm/i915: Defer
transfer onto execution timeline to actual hw submission") the
global seqno advance was deferred until the submit_request callback.
After wedging the GPU, we were installing a nop_submit_request handler
(to avoid waking up the dead hw) but I had missed converting this over
to the new scheme. Under the new scheme, we have to explicitly call
i915_gem_submit_request() from the submit_request handler to mark the
request as on the hardware. If we don't the request is always pending,
and any waiter will continue to wait indefinitely and hangcheck will not
be able to resolve the lockup.
References: https://bugs.freedesktop.org/show_bug.cgi?id=98748
Testcase: igt/gem_eio/in-flight
Fixes: d55ac5bf97c6 ("drm/i915: Defer transfer onto execution timeline to
actual hw submission")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b0dd0f0ea65a..91f1ac30c5fa 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2781,6 +2781,8 @@ void i915_gem_reset(struct drm_i915_private *dev_priv)
static void nop_submit_request(struct drm_i915_gem_request *request)
{
+ i915_gem_request_submit(request);
+ intel_engine_init_global_seqno(request->engine, request->global_seqno);
}
static void i915_gem_cleanup_engine(struct intel_engine_cs *engine)
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/4] drm/i915: Don't deref context->file_priv ERR_PTR upon reset
When a user context is closed, it's file_priv backpointer is replaced by
ERR_PTR(-EBADF); be careful not to chase this invalid pointer after a
hang and a GPU reset.
Signed-off-by: Chris Wilson
Fixes: b083a0870c79 ("drm/i915: Add per client max context ban limit")
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b38d4f8d1875..b0dd0f0ea65a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2647,16 +2647,12 @@ static void i915_gem_context_mark_guilty(struct
i915_gem_context *ctx)
ctx->name, ctx->ban_score,
yesno(ctx->banned));
- if (!ctx->file_priv)
+ if (!ctx->banned || IS_ERR_OR_NULL(ctx->file_priv))
return;
- if (ctx->banned) {
- ctx->file_priv->context_bans++;
-
- DRM_DEBUG_DRIVER("client %s has has %d context banned\n",
-ctx->name,
-ctx->file_priv->context_bans);
- }
+ ctx->file_priv->context_bans++;
+ DRM_DEBUG_DRIVER("client %s has had %d context banned\n",
+ctx->name, ctx->file_priv->context_bans);
}
static void i915_gem_context_mark_innocent(struct i915_gem_context *ctx)
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 4/4] drm/i915: Stop the machine as we install the wedged submit_request handler
In order to prevent a race between the old callback submitting an
incomplete request and i915_gem_set_wedged() installing its nop handler,
we must ensure that the swap occurs when the machine is idle
(stop_machine).
v2: move context lost from out of BKL.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 91f1ac30c5fa..3d4e07e9734f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2787,6 +2788,12 @@ static void nop_submit_request(struct
drm_i915_gem_request *request)
static void i915_gem_cleanup_engine(struct intel_engine_cs *engine)
{
+ /* We need to be sure that no thread is running the old callback as
+* we install the nop handler (otherwise we would submit a request
+* to hardware that will never complete). In order to prevent this
+* race, we wait until the machine is idle before making the swap
+* (using stop_machine()).
+*/
engine->submit_request = nop_submit_request;
/* Mark all pending requests as complete so that any concurrent
@@ -2817,20 +2824,29 @@ static void i915_gem_cleanup_engine(struct
intel_engine_cs *engine)
}
}
-void i915_gem_set_wedged(struct drm_i915_private *dev_priv)
+static int __i915_gem_set_wedged_BKL(void *data)
{
+ struct drm_i915_private *i915 = data;
struct intel_engine_cs *engine;
enum intel_engine_id id;
+ for_each_engine(engine, i915, id)
+ i915_gem_cleanup_engine(engine);
+
+ return 0;
+}
+
+void i915_gem_set_wedged(struct drm_i915_private *dev_priv)
+{
lockdep_assert_held(&dev_priv->drm.struct_mutex);
set_bit(I915_WEDGED, &dev_priv->gpu_error.flags);
- i915_gem_context_lost(dev_priv);
- for_each_engine(engine, dev_priv, id)
- i915_gem_cleanup_engine(engine);
- mod_delayed_work(dev_priv->wq, &dev_priv->gt.idle_work, 0);
+ stop_machine(__i915_gem_set_wedged_BKL, dev_priv, NULL);
+ i915_gem_context_lost(dev_priv);
i915_gem_retire_requests(dev_priv);
+
+ mod_delayed_work(dev_priv->wq, &dev_priv->gt.idle_work, 0);
}
static void
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 4/8] drm/i915/bxt: Enable IPC support
Em Ter, 2016-11-22 às 19:05 +0530, Mahesh Kumar escreveu:
> Hi,
>
>
> On Tuesday 22 November 2016 12:16 AM, Paulo Zanoni wrote:
> >
> > Em Sex, 2016-11-18 às 20:39 +0530, Mahesh Kumar escreveu:
> > >
> > > This patch adds IPC support for platforms. This patch enables IPC
> > > only for BXT/KBL platform as for SKL recommendation is to keep is
> > > disabled.
> > > IPC (Isochronous Priority Control) is the hardware feature, which
> > > dynamically controles the memory read priority of Display.
> > >
> > > When IPC is enabled, plane read requests are sent at high
> > > priority
> > > until
> > > filling above the transition watermark, then the requests are
> > > sent at
> > > lower priority until dropping below the level 0 watermark.
> > > The lower priority requests allow other memory clients to have
> > > better
> > > memory access. When IPC is disabled, all plane read requests are
> > > sent
> > > at
> > > high priority.
> > >
> > > Changes since V1:
> > > - Remove commandline parameter to disable ipc
> > > - Address Paulo's comments
> > > Changes since V2:
> > > - Address review comments
> > > - Set ipc_enabled flag
> > >
> > > Signed-off-by: Mahesh Kumar
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.c | 1 +
> > > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > > drivers/gpu/drm/i915/intel_pm.c | 15 +++
> > > 4 files changed, 18 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > b/drivers/gpu/drm/i915/i915_drv.c
> > > index 1b0a589..4074601 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -1244,6 +1244,7 @@ int i915_driver_load(struct pci_dev *pdev,
> > > const struct pci_device_id *ent)
> > > intel_runtime_pm_enable(dev_priv);
> > >
> > > dev_priv->ipc_enabled = false;
> > > + intel_enable_ipc(dev_priv);
> > So now we have to places that touch dev_priv->ipc_enabled. This one
> > and
> > intel_enable_ipc(). Please move that "dev_priv->ipc_enabled =
> > false"
> > line to inside intel_enable_ipc(). It's much easier to read the
> > code
> > when there's a single function responsible for setting the
> > appropriate
> > value to a variable.
> >
> >
> > Besides, my understanding of your discussion with Maarten in the
> > last
> > revision of this patch was that we needed to change where
> > intel_enable_ipc() is called in order to make sure the bit stays
> > enabled after suspend/resume. If that's not needed, why is it not
> > needed?
> We don't overwrite DISP_ARB_CTL2 register during suspend/resume
> So there will not be any impact of it & handling during
> suspend/resume
> is not needed.
Just to make sure I understood: any value that our driver sets to this
register will persist after a suspend/resume cycle? That's not what I
was expecting. Usually after a suspend/resume cycle a lot of registers
are reset to their default value, so our driver needs to write them all
again.
Can you also confirm whether this is true during runtime PM?
Thanks,
Paulo
> thanks for review
>
> Regards,
> -Mahesh
> >
> > >
> > >
> > > /* Everything is in place, we can now relax! */
> > > DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor
> > > %d\n",
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index c70c07a..300418a 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -6076,6 +6076,7 @@ enum {
> > > #define DISP_FBC_WM_DIS(1<<15)
> > > #define DISP_ARB_CTL2 _MMIO(0x45004)
> > > #define DISP_DATA_PARTITION_5_6(1<<6)
> > > +#define DISP_IPC_ENABLE (1<<3)
> > > #define DBUF_CTL_MMIO(0x45008)
> > > #define DBUF_POWER_REQUEST (1<<31)
> > > #define DBUF_POWER_STATE (1<<30)
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index cd132c2..ad542a2 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -1745,6 +1745,7 @@ bool skl_ddb_allocation_overlaps(const
> > > struct
> > > skl_ddb_entry **entries,
> > > uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state
> > > *pipe_config);
> > > bool ilk_disable_lp_wm(struct drm_device *dev);
> > > int sanitize_rc6_option(struct drm_i915_private *dev_priv, int
> > > enable_rc6);
> > > +void intel_enable_ipc(struct drm_i915_private *dev_priv);
> > > static inline int intel_enable_rc6(void)
> > > {
> > > return i915.enable_rc6;
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > b/drivers/gpu/drm/i915/intel_pm.c
> > > index df39b50..d8090aa 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -4682,6 +4682,21 @@ void intel_update_watermarks(struct
> > > intel_crtc
> > > *crtc)
> > > dev_priv->display.up
[Intel-gfx] ✓ Fi.CI.BAT: success for lib/debugobjects: Export for use in modules
== Series Details == Series: lib/debugobjects: Export for use in modules URL : https://patchwork.freedesktop.org/series/15743/ State : success == Summary == Series 15743v1 lib/debugobjects: Export for use in modules https://patchwork.freedesktop.org/api/1.0/series/15743/revisions/1/mbox/ Test drv_module_reload_basic: dmesg-warn -> PASS (fi-skl-6770hq) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 eeec5e7742b23082dd20523c8baa08fe495175e4 drm-intel-nightly: 2016y-11m-21d-18h-22m-22s UTC integration manifest 7a4efa3 lib/debugobjects: Export for use in modules == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3078/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Integrate i915_sw_fence with debugobjects
Add the tracking required to enable debugobjects to improve error
detection in BAT. The debugobject interface lets us to track the
lifetime of the fences even while being embedded into larger structs,
i.e. to check they are not used after they have been released.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig.debug | 13 +
drivers/gpu/drm/i915/i915_sw_fence.c | 100 +++
2 files changed, 113 insertions(+)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 51ba630a134b..a6c69b8cb1d2 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -22,6 +22,7 @@ config DRM_I915_DEBUG
select X86_MSR # used by igt/pm_rpm
select DRM_VGEM # used by igt/prime_vgem (dmabuf interop checks)
select DRM_DEBUG_MM if DRM=y
+select DRM_I915_SW_FENCE_DEBUG_OBJECTS if DRM_I915=y
default n
help
Choose this option to turn on extra driver debugging that may affect
@@ -43,3 +44,15 @@ config DRM_I915_DEBUG_GEM
If in doubt, say "N".
+config DRM_I915_SW_FENCE_DEBUG_OBJECTS
+bool "Enable additional driver debugging for fence objects"
+depends on DRM_I915=y
+select DEBUG_OBJECTS
+default n
+help
+ Choose this option to turn on extra driver debugging that may affect
+ performance but will catch some internal issues.
+
+ Recommended for driver developers only.
+
+ If in doubt, say "N".
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b/drivers/gpu/drm/i915/i915_sw_fence.c
index 147420ccf49c..5223e17a245e 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -17,6 +17,82 @@
static DEFINE_SPINLOCK(i915_sw_fence_lock);
+#ifdef CONFIG_DRM_I915_SW_FENCE_DEBUG_OBJECTS
+
+static void *i915_sw_fence_debug_hint(void *addr)
+{
+ return (void *)(((struct i915_sw_fence *)addr)->flags &
I915_SW_FENCE_MASK);
+}
+
+static bool i915_sw_fence_is_static_object(void *addr)
+{
+ return false;
+}
+
+static bool i915_sw_fence_fixup_fail(void *addr, enum debug_obj_state state)
+{
+ return false;
+}
+
+static struct debug_obj_descr i915_sw_fence_debug_descr = {
+ .name = "i915_sw_fence",
+ .debug_hint = i915_sw_fence_debug_hint,
+ .is_static_object = i915_sw_fence_is_static_object,
+ .fixup_init = i915_sw_fence_fixup_fail,
+ .fixup_activate = i915_sw_fence_fixup_fail,
+ .fixup_free = i915_sw_fence_fixup_fail,
+ .fixup_assert_init = i915_sw_fence_fixup_fail,
+};
+
+static inline void debug_fence_init(struct i915_sw_fence *fence)
+{
+ debug_object_init(fence, &i915_sw_fence_debug_descr);
+}
+
+static inline void debug_fence_activate(struct i915_sw_fence *fence)
+{
+ debug_object_activate(fence, &i915_sw_fence_debug_descr);
+}
+
+static inline void debug_fence_deactivate(struct i915_sw_fence *fence)
+{
+ debug_object_deactivate(fence, &i915_sw_fence_debug_descr);
+}
+
+static inline void debug_fence_free(struct i915_sw_fence *fence)
+{
+ debug_object_free(fence, &i915_sw_fence_debug_descr);
+}
+
+static inline void debug_fence_assert(struct i915_sw_fence *fence)
+{
+ debug_object_assert_init(fence, &i915_sw_fence_debug_descr);
+}
+
+#else
+
+static inline void debug_fence_init(struct i915_sw_fence *fence)
+{
+}
+
+static inline void debug_fence_activate(struct i915_sw_fence *fence)
+{
+}
+
+static inline void debug_fence_deactivate(struct i915_sw_fence *fence)
+{
+}
+
+static inline void debug_fence_free(struct i915_sw_fence *fence)
+{
+}
+
+static inline void debug_fence_assert(struct i915_sw_fence *fence)
+{
+}
+
+#endif
+
static int __i915_sw_fence_notify(struct i915_sw_fence *fence,
enum i915_sw_fence_notify state)
{
@@ -31,6 +107,7 @@ static void i915_sw_fence_free(struct kref *kref)
struct i915_sw_fence *fence = container_of(kref, typeof(*fence), kref);
WARN_ON(atomic_read(&fence->pending) > 0);
+ debug_fence_free(fence);
if (fence->flags & I915_SW_FENCE_MASK)
__i915_sw_fence_notify(fence, FENCE_FREE);
@@ -40,11 +117,13 @@ static void i915_sw_fence_free(struct kref *kref)
static void i915_sw_fence_put(struct i915_sw_fence *fence)
{
+ debug_fence_assert(fence);
kref_put(&fence->kref, i915_sw_fence_free);
}
static struct i915_sw_fence *i915_sw_fence_get(struct i915_sw_fence *fence)
{
+ debug_fence_assert(fence);
kref_get(&fence->kref);
return fence;
}
@@ -56,6 +135,8 @@ static void __i915_sw_fence_wake_up_all(struct i915_sw_fence
*fence,
wait_queue_t *pos, *next;
unsigned long flags;
+ debug_fence_assert(fence);
+
atomic_set_release(&fence->pending, -1); /* 0 -> -1 [done] */
/*
@@ -88,11 +169,15 @@ static void __i915_sw_fence_wake_up_all(struct
i915_sw_fence *fence,
Re: [Intel-gfx] [PATCH] drm/i915: Move the release of PT page to the upper caller
On Mon, Nov 21, 2016 at 07:44:26PM +0800, Zhi Wang wrote: > a PT page will be released if it doesn't contain any meaningful mappings > during PPGTT page table shrinking. The PT entry in the upper level will > be set to a scratch entry. > > Normally this works nicely, but in virtualization world, the PPGTT page > table is tracked by hypervisor. Releasing the PT page before modifying > the upper level PT entry would cause extra efforts. > > As the tracked page has been returned to OS before losing track from > hypervisor, it could be written in any pattern. Hypervisor has to recognize > if a page is still being used as a PT page by validating these writing > patterns. It's complicated. Better let the guest modify the PT entry in > upper level PT first, then release the PT page. Reviewed-by: Michał Winiarski -Michał > Cc: Michał Winiarski > Cc: Michel Thierry > Cc: Joonas Lahtinen > Cc: Chris Wilson > Cc: Zhenyu Wang > Cc: Zhiyuan Lv > Signed-off-by: Zhi Wang > --- > drivers/gpu/drm/i915/i915_gem_gtt.c | 18 +++--- > 1 file changed, 7 insertions(+), 11 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Move the release of PT page to the upper caller
On Tue, Nov 22, 2016 at 09:29:40PM +0800, Zhi Wang wrote: > Hi guys: > Would you mind to have a quick review on this patch? :P The > linux guest under GVT-g couldn't boot up without this patch in the > newer kernel. > > Thanks, > Zhi. > > On 11/21/16 19:44, Zhi Wang wrote: > >a PT page will be released if it doesn't contain any meaningful mappings > >during PPGTT page table shrinking. The PT entry in the upper level will > >be set to a scratch entry. > > > >Normally this works nicely, but in virtualization world, the PPGTT page > >table is tracked by hypervisor. Releasing the PT page before modifying > >the upper level PT entry would cause extra efforts. > > > >As the tracked page has been returned to OS before losing track from > >hypervisor, it could be written in any pattern. Hypervisor has to recognize > >if a page is still being used as a PT page by validating these writing > >patterns. It's complicated. Better let the guest modify the PT entry in > >upper level PT first, then release the PT page. > > > >Cc: Michał Winiarski > >Cc: Michel Thierry > >Cc: Joonas Lahtinen > >Cc: Chris Wilson > >Cc: Zhenyu Wang > >Cc: Zhiyuan Lv > >Signed-off-by: Zhi Wang The original didn't make it to me, so I just assumed a list issue. For the record, I'd like to have some more detail on just when the hv is doing the page scanning. It makes it sound like you are actively scanning an idle range. Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] lib/scatterlist: Fix offset type in sg_alloc_table_from_pages
Em Mon, 14 Nov 2016 09:55:48 + Chris Wilson escreveu: > On Fri, Nov 11, 2016 at 08:50:17AM +, Tvrtko Ursulin wrote: > > From: Tvrtko Ursulin > > > > Scatterlist entries have an unsigned int for the offset so > > correct the sg_alloc_table_from_pages function accordingly. > > > > Since these are offsets withing a page, unsigned int is > > wide enough. > > > > Also converts callers which were using unsigned long locally > > with the lower_32_bits annotation to make it explicitly > > clear what is happening. > > > > v2: Use offset_in_page. (Chris Wilson) > > > > Signed-off-by: Tvrtko Ursulin > > Cc: Masahiro Yamada > > Cc: Pawel Osciak > > Cc: Marek Szyprowski > > Cc: Kyungmin Park > > Cc: Tomasz Stanislawski > > Cc: Matt Porter > > Cc: Alexandre Bounine > > Cc: linux-me...@vger.kernel.org > > Cc: linux-ker...@vger.kernel.org > > Acked-by: Marek Szyprowski (v1) > > If there were kerneldoc, it would nicely explain that having an offset > larger then a page is silly when passing in array of pages. > > Changes elsewhere look ok (personally I'd be happy with just > offset_in_page(), 4GiB superpages are somebody else's problem :) For the media changes, that looked OK. We don't have any needs to stream 4GB images nowadays :-) Reviewed-by: Mauro Carvalho Chehab > Reviewed-by: Chris Wilson > -Chris > Thanks, Mauro ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] lib/debugobjects: Export for use in modules
Drivers, or other modules, that use a mixture of objects (especially objects embedded within other objects) would like to take advantage of the debugobjects facilities to help catch misuse. Currently, the debugobjects interface is only available to builtin drivers and requires a set of EXPORT_SYMBOL_GPL for use by modules. Signed-off-by: Chris Wilson Cc: "Du, Changbin" Cc: Andrew Morton Cc: Thomas Gleixner Cc: Christian Borntraeger Cc: intel-gfx@lists.freedesktop.org --- lib/debugobjects.c | 8 1 file changed, 8 insertions(+) diff --git a/lib/debugobjects.c b/lib/debugobjects.c index a8e12601eb37..056052dc8e91 100644 --- a/lib/debugobjects.c +++ b/lib/debugobjects.c @@ -362,6 +362,7 @@ void debug_object_init(void *addr, struct debug_obj_descr *descr) __debug_object_init(addr, descr, 0); } +EXPORT_SYMBOL_GPL(debug_object_init); /** * debug_object_init_on_stack - debug checks when an object on stack is @@ -376,6 +377,7 @@ void debug_object_init_on_stack(void *addr, struct debug_obj_descr *descr) __debug_object_init(addr, descr, 1); } +EXPORT_SYMBOL_GPL(debug_object_init_on_stack); /** * debug_object_activate - debug checks when an object is activated @@ -449,6 +451,7 @@ int debug_object_activate(void *addr, struct debug_obj_descr *descr) } return 0; } +EXPORT_SYMBOL_GPL(debug_object_activate); /** * debug_object_deactivate - debug checks when an object is deactivated @@ -496,6 +499,7 @@ void debug_object_deactivate(void *addr, struct debug_obj_descr *descr) raw_spin_unlock_irqrestore(&db->lock, flags); } +EXPORT_SYMBOL_GPL(debug_object_deactivate); /** * debug_object_destroy - debug checks when an object is destroyed @@ -542,6 +546,7 @@ void debug_object_destroy(void *addr, struct debug_obj_descr *descr) out_unlock: raw_spin_unlock_irqrestore(&db->lock, flags); } +EXPORT_SYMBOL_GPL(debug_object_destroy); /** * debug_object_free - debug checks when an object is freed @@ -582,6 +587,7 @@ void debug_object_free(void *addr, struct debug_obj_descr *descr) out_unlock: raw_spin_unlock_irqrestore(&db->lock, flags); } +EXPORT_SYMBOL_GPL(debug_object_free); /** * debug_object_assert_init - debug checks when object should be init-ed @@ -626,6 +632,7 @@ void debug_object_assert_init(void *addr, struct debug_obj_descr *descr) raw_spin_unlock_irqrestore(&db->lock, flags); } +EXPORT_SYMBOL_GPL(debug_object_assert_init); /** * debug_object_active_state - debug checks object usage state machine @@ -673,6 +680,7 @@ debug_object_active_state(void *addr, struct debug_obj_descr *descr, raw_spin_unlock_irqrestore(&db->lock, flags); } +EXPORT_SYMBOL_GPL(debug_object_active_state); #ifdef CONFIG_DEBUG_OBJECTS_FREE static void __debug_check_no_obj_freed(const void *address, unsigned long size) -- 2.10.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't deref context->file_priv ERR_PTR upon reset
Chris Wilson writes:
> When a user context is closed, it's file_priv backpointer is replaced by
> ERR_PTR(-EBADF); be careful not to chase this invalid pointer after a
> hang and a GPU reset.
>
> Signed-off-by: Chris Wilson
> Fixes: b083a0870c79 ("drm/i915: Add per client max context ban limit")
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index b850e66c2f83..d75196b86693 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2647,16 +2647,12 @@ static void i915_gem_context_mark_guilty(struct
> i915_gem_context *ctx)
>ctx->name, ctx->ban_score,
>yesno(ctx->banned));
>
> - if (!ctx->file_priv)
> + if (!ctx->banned || IS_ERR_OR_NULL(ctx->file_priv))
> return;
>
> - if (ctx->banned) {
> - ctx->file_priv->context_bans++;
> -
> - DRM_DEBUG_DRIVER("client %s has has %d context banned\n",
> - ctx->name,
> - ctx->file_priv->context_bans);
> - }
> + ctx->file_priv->context_bans++;
> + DRM_DEBUG_DRIVER("client %s has had %d context banned\n",
> + ctx->name, ctx->file_priv->context_bans);
> }
>
> static void i915_gem_context_mark_innocent(struct i915_gem_context *ctx)
> --
> 2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] lib/debugobjects: Export for use in modules
Drivers, or other modules, that use a mixture of objects (especially objects embedded within other objects) would like to take advantage of the debugobjects facilities to help catch misuse. Currently, the debugobjects interface is only available to builtin drivers and requires a set of EXPORT_SYMBOL_GPL for use by modules. Signed-off-by: Chris Wilson Cc: "Du, Changbin" Cc: Andrew Morton Cc: Thomas Gleixner Cc: Christian Borntraeger Cc: intel-gfx@lists.freedesktop.org --- lib/debugobjects.c | 8 1 file changed, 8 insertions(+) diff --git a/lib/debugobjects.c b/lib/debugobjects.c index a8e12601eb37..056052dc8e91 100644 --- a/lib/debugobjects.c +++ b/lib/debugobjects.c @@ -362,6 +362,7 @@ void debug_object_init(void *addr, struct debug_obj_descr *descr) __debug_object_init(addr, descr, 0); } +EXPORT_SYMBOL_GPL(debug_object_init); /** * debug_object_init_on_stack - debug checks when an object on stack is @@ -376,6 +377,7 @@ void debug_object_init_on_stack(void *addr, struct debug_obj_descr *descr) __debug_object_init(addr, descr, 1); } +EXPORT_SYMBOL_GPL(debug_object_init_on_stack); /** * debug_object_activate - debug checks when an object is activated @@ -449,6 +451,7 @@ int debug_object_activate(void *addr, struct debug_obj_descr *descr) } return 0; } +EXPORT_SYMBOL_GPL(debug_object_activate); /** * debug_object_deactivate - debug checks when an object is deactivated @@ -496,6 +499,7 @@ void debug_object_deactivate(void *addr, struct debug_obj_descr *descr) raw_spin_unlock_irqrestore(&db->lock, flags); } +EXPORT_SYMBOL_GPL(debug_object_deactivate); /** * debug_object_destroy - debug checks when an object is destroyed @@ -542,6 +546,7 @@ void debug_object_destroy(void *addr, struct debug_obj_descr *descr) out_unlock: raw_spin_unlock_irqrestore(&db->lock, flags); } +EXPORT_SYMBOL_GPL(debug_object_destroy); /** * debug_object_free - debug checks when an object is freed @@ -582,6 +587,7 @@ void debug_object_free(void *addr, struct debug_obj_descr *descr) out_unlock: raw_spin_unlock_irqrestore(&db->lock, flags); } +EXPORT_SYMBOL_GPL(debug_object_free); /** * debug_object_assert_init - debug checks when object should be init-ed @@ -626,6 +632,7 @@ void debug_object_assert_init(void *addr, struct debug_obj_descr *descr) raw_spin_unlock_irqrestore(&db->lock, flags); } +EXPORT_SYMBOL_GPL(debug_object_assert_init); /** * debug_object_active_state - debug checks object usage state machine @@ -673,6 +680,7 @@ debug_object_active_state(void *addr, struct debug_obj_descr *descr, raw_spin_unlock_irqrestore(&db->lock, flags); } +EXPORT_SYMBOL_GPL(debug_object_active_state); #ifdef CONFIG_DEBUG_OBJECTS_FREE static void __debug_check_no_obj_freed(const void *address, unsigned long size) -- 2.10.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 5/8] drm/i915/skl+: change WM calc to fixed point 16.16
On Tuesday 22 November 2016 06:12 PM, Paulo Zanoni wrote:
Em Sex, 2016-11-18 às 20:39 +0530, Mahesh Kumar escreveu:
This patch changes Watermak calculation to fixed point calculation.
Problem with current calculation is during plane_blocks_per_line
calculation we divide intermediate blocks with min_scanlines and
takes floor of the result because of integer operation.
hence we end-up assigning less blocks than required. Which leads to
flickers.
Changes since V1:
- Add fixed point data type as per Paulo's review
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/i915_drv.h | 84
+
drivers/gpu/drm/i915/intel_pm.c | 70 ---
---
2 files changed, 125 insertions(+), 29 deletions(-)
First of all, there's non-standard indentation all over the code. When
a statement is broken into multiple lines, sometimes there's way too
many tabs, sometimes tabs/spaces are missing.
looks like some editor setting went wrong, will fix it.
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 394d7ea..20691e9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -119,6 +119,90 @@ bool __i915_inject_load_failure(const char
*func, int line);
#define i915_inject_load_failure() \
__i915_inject_load_failure(__func__, __LINE__)
+typedef struct {
+ uint32_t val;
+} uint_fixed_16_16_t;
+
+#define FP_16_16_MAX ({ \
+ uint_fixed_16_16_t fp; \
+ fp.val = UINT_MAX; \
+ fp; \
+})
+
+static inline uint_fixed_16_16_t u32_to_fp_16_16(uint32_t val)
In the type name the patch uses "fixed", but in some functions it uses
"fp". I know that fp is supposed to help function names shorter, but
IMHO we should stick with the same word all the time. My suggestion is
to keep "fixed" everywhere, because the definition of "fp" is not
obvious to everybody (fixed point? floating point? frame pointer?
functional programming?).
+{
+ uint_fixed_16_16_t fp;
+
+ WARN_ON(val >> 16);
+
+ fp.val = val << 16;
+ return fp;
+}
+
+static inline uint32_t fp_16_16_to_u32_round_up(uint_fixed_16_16_t
fp)
+{
+ return DIV_ROUND_UP(fp.val, 1 << 16);
+}
+
+static inline uint32_t fp_16_16_to_u32(uint_fixed_16_16_t fp)
+{
+ return (fp.val / 1 << 16);
This is dividing by 1 and then shifting. Doesn't look correct.
It should have been (fp.val / (1 << 16))
+}
+
+static inline uint_fixed_16_16_t min_fp_16_16(uint_fixed_16_16_t
min1,
+ uint_fixed_16_16_t
min2)
+{
+ uint_fixed_16_16_t min;
+
+ min.val = min(min1.val, min2.val);
+ return min;
+}
+
+static inline uint_fixed_16_16_t max_fp_16_16(uint_fixed_16_16_t
max1,
+ uint_fixed_16_16_t
max2)
+{
+ uint_fixed_16_16_t max;
+
+ max.val = max(max1.val, max2.val);
+ return max;
+}
+
+static inline uint_fixed_16_16_t fp_16_16_div_round_up(uint32_t val,
uint32_t d)
+{
+ uint_fixed_16_16_t fp, res;
+
+ fp = u32_to_fp_16_16(val);
+ res.val = DIV_ROUND_UP(fp.val, d);
+ return res;
+}
+
+static inline uint_fixed_16_16_t fp_16_16_div_round_up_ull(uint64_t
val,
+ uint
32_t d)
I'd end the name with "u64" instead of "ull" since it's an uint64_t
type, not unsigned long long.
+{
+ uint_fixed_16_16_t res;
+ uint64_t interm_val;
+
+ WARN_ON(val >> 48);
+ val <<= 16;
+ interm_val = DIV_ROUND_UP_ULL(val, d);
+ WARN_ON(interm_val >> 32);
+ res.val = (uint32_t) interm_val;
+
+ return res;
+}
+
+static inline uint_fixed_16_16_t mul_fp_16_16_u32(uint32_t val,
+ uint_fixed_16_16_t
mul)
+{
+ uint64_t intermediate_val;
+ uint_fixed_16_16_t fp;
+
+ intermediate_val = (uint64_t) val * mul.val;
+ WARN_ON(intermediate_val >> 32);
+ fp.val = (uint32_t) intermediate_val;
+ return fp;
+}
+
static inline const char *yesno(bool v)
{
return v ? "yes" : "no";
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index d8090aa..7c788ac 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3515,33 +3515,37 @@ skl_allocate_pipe_ddb(struct intel_crtc_state
*cstate,
* for the read latency) and cpp should always be <= 8, so that
* should allow pixel_rate up to ~2 GHz which seems sufficient since
max
* 2xcdclk is 1350 MHz and the pixel rate should never exceed that.
+ * Both Method1 & Method2 returns fixedpoint 16.16 output
This line is not needed anymore: function signatures are saying it now.
*/
-static uint32_t skl_wm_method1(uint32_t pixel_rate, uint8_t cpp,
uint32_t latency)
+static uint_fixed_16_16_t skl_wm_method1(uint32_t pixel_rate,
uint8_t cpp,
+uint3
Re: [Intel-gfx] [PATCH v2] drm/i915: don't whitelist oacontrol in cmd parser
On Tue, Nov 22, 2016 at 1:34 PM, Daniel Vetter wrote:
> On Tue, Nov 08, 2016 at 12:51:48PM +, Robert Bragg wrote:
> > This v2 patch bumps the command parser version so it can be referenced in
> > corresponding i-g-t gem_exec_parse changes.
> >
> > --- >8 ---
>
> Scissors cut everything below, not everything above, hence next time
> around pls switch around your comment and the commit message, as-is not
> much left ;-)
>
Hmm, they cut away what's above and keep what's below in my experience -
what command are you seeing the opposite with?
I just double checked this with git am --scissors
- Robert
>
> Fixed up while applying.
> -Daniel
>
> >
> > Being able to program OACONTROL from a non-privileged batch buffer is
> > not sufficient to be able to configure the OA unit. This was originally
> > allowed to help enable Mesa to expose OA counters via the
> > INTEL_performance_query extension, but the current implementation based
> > on programming OACONTROL via a batch buffer isn't able to report useable
> > data without a more complete OA unit configuration. Mesa handles the
> > possibility that writes to OACONTROL may not be allowed and so only
> > advertises the extension after explicitly testing that a write to
> > OACONTROL succeeds. Based on this; removing OACONTROL from the whitelist
> > should be ok for userspace.
> >
> > Removing this simplifies adding a new kernel api for configuring the OA
> > unit without needing to consider the possibility that userspace might
> > trample on OACONTROL state which we'd like to start managing within
> > the kernel instead. In particular running any Mesa based GL application
> > currently results in clearing OACONTROL when initializing which would
> > disable the capturing of metrics.
> >
> > v2:
> > This bumps the command parser version from 8 to 9, as the change is
> > visible to userspace.
> >
> > Signed-off-by: Robert Bragg
> > Reviewed-by: Matthew Auld
> > Reviewed-by: Sourab Gupta
> > ---
> > drivers/gpu/drm/i915/i915_cmd_parser.c | 42
> --
> > 1 file changed, 5 insertions(+), 37 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
> b/drivers/gpu/drm/i915/i915_cmd_parser.c
> > index c9d2ecd..f5762cd 100644
> > --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
> > +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
> > @@ -450,7 +450,6 @@ static const struct drm_i915_reg_descriptor
> gen7_render_regs[] = {
> > REG64(PS_INVOCATION_COUNT),
> > REG64(PS_DEPTH_COUNT),
> > REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE),
> > - REG32(GEN7_OACONTROL), /* Only allowed for LRI and SRM. See below.
> */
> > REG64(MI_PREDICATE_SRC0),
> > REG64(MI_PREDICATE_SRC1),
> > REG32(GEN7_3DPRIM_END_OFFSET),
> > @@ -1060,8 +1059,7 @@ bool intel_engine_needs_cmd_parser(struct
> intel_engine_cs *engine)
> > static bool check_cmd(const struct intel_engine_cs *engine,
> > const struct drm_i915_cmd_descriptor *desc,
> > const u32 *cmd, u32 length,
> > - const bool is_master,
> > - bool *oacontrol_set)
> > + const bool is_master)
> > {
> > if (desc->flags & CMD_DESC_SKIP)
> > return true;
> > @@ -1099,31 +1097,6 @@ static bool check_cmd(const struct
> intel_engine_cs *engine,
> > }
> >
> > /*
> > - * OACONTROL requires some special handling for
> > - * writes. We want to make sure that any batch
> which
> > - * enables OA also disables it before the end of
> the
> > - * batch. The goal is to prevent one process from
> > - * snooping on the perf data from another process.
> To do
> > - * that, we need to check the value that will be
> written
> > - * to the register. Hence, limit OACONTROL writes
> to
> > - * only MI_LOAD_REGISTER_IMM commands.
> > - */
> > - if (reg_addr == i915_mmio_reg_offset(GEN7_OACONTROL))
> {
> > - if (desc->cmd.value ==
> MI_LOAD_REGISTER_MEM) {
> > - DRM_DEBUG_DRIVER("CMD: Rejected
> LRM to OACONTROL\n");
> > - return false;
> > - }
> > -
> > - if (desc->cmd.value ==
> MI_LOAD_REGISTER_REG) {
> > - DRM_DEBUG_DRIVER("CMD: Rejected
> LRR to OACONTROL\n");
> > - return false;
> > - }
> > -
> > - if (desc->cmd.value ==
> MI_LOAD_REGISTER_IMM(1))
> > - *oacontrol_set = (cmd[offset + 1]
> != 0);
> > - }
> > -
> > - /*
> >* Check the val
Re: [Intel-gfx] [PATCH v2] drm/i915: Stop the machine as we install the wedged submit_request handler
Chris Wilson writes:
> In order to prevent a race between the old callback submitting an
> incomplete request and i915_gem_set_wedged() installing its nop handler,
> we must ensure that the swap occurs when the machine is idle
> (stop_machine).
>
> v2: move context lost from out of BKL.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem.c | 26 +-
> 1 file changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index d0dcaf35b429..e80ad6906fb4 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -38,6 +38,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -2770,6 +2771,12 @@ static void nop_submit_request(struct
> drm_i915_gem_request *request)
>
> static void i915_gem_cleanup_engine(struct intel_engine_cs *engine)
> {
> + /* We need to be sure that no thread is running the old callback as
> + * we install the nop handler (otherwise we would submit a request
> + * to hardware that will never complete). In order to prevent this
> + * race, we wait until the machine is idle before making the swap
> + * (using stop_machine()).
> + */
> engine->submit_request = nop_submit_request;
>
> /* Mark all pending requests as complete so that any concurrent
> @@ -2800,20 +2807,29 @@ static void i915_gem_cleanup_engine(struct
> intel_engine_cs *engine)
> }
> }
>
> -void i915_gem_set_wedged(struct drm_i915_private *dev_priv)
> +static int __i915_gem_set_wedged_BKL(void *data)
> {
> + struct drm_i915_private *i915 = data;
> struct intel_engine_cs *engine;
> enum intel_engine_id id;
>
> + for_each_engine(engine, i915, id)
> + i915_gem_cleanup_engine(engine);
> +
> + return 0;
> +}
> +
> +void i915_gem_set_wedged(struct drm_i915_private *dev_priv)
> +{
> lockdep_assert_held(&dev_priv->drm.struct_mutex);
> set_bit(I915_WEDGED, &dev_priv->gpu_error.flags);
>
> - i915_gem_context_lost(dev_priv);
> - for_each_engine(engine, dev_priv, id)
> - i915_gem_cleanup_engine(engine);
> - mod_delayed_work(dev_priv->wq, &dev_priv->gt.idle_work, 0);
> + stop_machine(__i915_gem_set_wedged_BKL, dev_priv, NULL);
>
> + i915_gem_context_lost(dev_priv);
> i915_gem_retire_requests(dev_priv);
> +
> + mod_delayed_work(dev_priv->wq, &dev_priv->gt.idle_work, 0);
> }
>
> static void
> --
> 2.10.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 07/12] lib/igt_kms: Add support for the OUT_FENCE_PTR property
On Tue, Nov 22, 2016 at 02:56:49PM +0100, Daniel Vetter wrote:
On Tue, Nov 22, 2016 at 01:50:53PM +, Brian Starkey wrote:
On Tue, Nov 22, 2016 at 02:12:59PM +0100, Daniel Vetter wrote:
> On Tue, Nov 22, 2016 at 12:37:47PM +, Brian Starkey wrote:
> > On Tue, Nov 22, 2016 at 12:10:52PM +, Chris Wilson wrote:
> > > On Tue, Nov 22, 2016 at 11:54:57AM +, Brian Starkey wrote:
> > > > On Tue, Nov 22, 2016 at 11:06:00AM +, Chris Wilson wrote:
> > > > >On Tue, Nov 22, 2016 at 10:53:51AM +, Brian Starkey wrote:
> > > > >>Hi Gustavo,
> > > > >>
> > > > >>A little late to the party here, but I was blocked by our internal
> > > > >>contributions process...
> > > > >>
> > > > >>I didn't see these end up in my checkout yet though, so I guess they
> > > > >>aren't picked up yet.
> > > > >>
> > > > >>On Mon, Nov 14, 2016 at 06:59:21PM +0900, Gustavo Padovan wrote:
> > > > >>>From: Gustavo Padovan
> > > > >>>
> > > > >>>Add support for the OUT_FENCE_PTR property to enable setting out
fences for
> > > > >>>atomic commits.
> > > > >>>
> > > > >>>Signed-off-by: Gustavo Padovan
> > > > >>>---
> > > > >>>lib/igt_kms.c | 20 +++-
> > > > >>>lib/igt_kms.h | 3 +++
> > > > >>>2 files changed, 22 insertions(+), 1 deletion(-)
> > > > >>>
> > > > >>>diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> > > > >>>index 4748c0a..f25e1eb 100644
> > > > >>>--- a/lib/igt_kms.c
> > > > >>>+++ b/lib/igt_kms.c
> > > > >>>@@ -175,7 +175,8 @@ const char
*igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
> > > > >>>"DEGAMMA_LUT",
> > > > >>>"GAMMA_LUT",
> > > > >>>"MODE_ID",
> > > > >>>- "ACTIVE"
> > > > >>>+ "ACTIVE",
> > > > >>>+ "OUT_FENCE_PTR"
> > > > >>>};
> > > > >>>
> > > > >>>const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
> > > > >>>@@ -2103,6 +2104,9 @@ static void
igt_atomic_prepare_crtc_commit(igt_pipe_t *pipe_obj, drmModeAtomicRe
> > > > >>>igt_atomic_populate_crtc_req(req, pipe_obj,
IGT_CRTC_ACTIVE, !!output);
> > > > >>>}
> > > > >>>
> > > > >>>+ if (pipe_obj->out_fence_ptr)
> > > > >>>+ igt_atomic_populate_crtc_req(req, pipe_obj,
IGT_CRTC_OUT_FENCE_PTR, pipe_obj->out_fence_ptr);
> > > > >>>+
> > > > >>>/*
> > > > >>> * TODO: Add all crtc level properties here
> > > > >>> */
> > > > >>>@@ -2683,6 +2687,20 @@ igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void
*ptr, size_t length)
> > > > >>>}
> > > > >>>
> > > > >>>/**
> > > > >>>+ * igt_pipe_set_out_fence_ptr:
> > > > >>>+ * @pipe: pipe pointer to which background color to be set
> > > > >>>+ * @fence_ptr: out fence pointer
> > > > >>
> > > > >>I don't think fence_ptr can be int *. It needs to be a pointer to a
> > > > >>64-bit type.
> > > > >>
> > > > >>>+ *
> > > > >>>+ * Sets the out fence pointer that will be passed to the kernel in
> > > > >>>+ * the atomic ioctl. When the kernel returns the out fence pointer
> > > > >>>+ * will contain the fd number of the out fence created by KMS.
> > > > >>>+ */
> > > > >>>+void igt_pipe_set_out_fence_ptr(igt_pipe_t *pipe, int *fence_ptr)
> > > > >>>+{
> > > > >>>+ pipe->out_fence_ptr = (uint64_t) fence_ptr;
> > > > >>>+}
> > > > >>>+
> > > > >>>+/**
> > > > >>> * igt_crtc_set_background:
> > > > >>> * @pipe: pipe pointer to which background color to be set
> > > > >>> * @background: background color value in BGR 16bpc
> > > > >>>diff --git a/lib/igt_kms.h b/lib/igt_kms.h
> > > > >>>index 344f931..02d7bd1 100644
> > > > >>>--- a/lib/igt_kms.h
> > > > >>>+++ b/lib/igt_kms.h
> > > > >>>@@ -110,6 +110,7 @@ enum igt_atomic_crtc_properties {
> > > > >>> IGT_CRTC_GAMMA_LUT,
> > > > >>> IGT_CRTC_MODE_ID,
> > > > >>> IGT_CRTC_ACTIVE,
> > > > >>>+ IGT_CRTC_OUT_FENCE_PTR,
> > > > >>> IGT_NUM_CRTC_PROPS
> > > > >>>};
> > > > >>>
> > > > >>>@@ -298,6 +299,7 @@ struct igt_pipe {
> > > > >>>
> > > > >>>uint64_t mode_blob;
> > > > >>>bool mode_changed;
> > > > >>>+ uint64_t out_fence_ptr;
> > > > >>
> > > > >>IMO this should be:
> > > > >>
> > > > >>int64_t *out_fence_ptr;
> > > > >
> > > > >In userspace, fences are *fd*, a plain int. It is only the uabi that we
> > > > >pass pointers as u64 to the kernel, and indeed that should be limited
to
> > > > >the uabi wrapper.
> > > > >-Chris
> > > >
> > > > Where's the uabi wrapper in this case?
> > > >
> > > > Wherever it is, afaik someone needs to have 64-bit type for the kernel
> > > > to stash its fd in - on the kernel side out_fence_ptr is
> > > > (s64 __user *), so if there's not a 64-bit variable on the other end
> > > > of it then someone's going to have a bad day.
> > >
> > > We do not have pointers in the uabi because they are different sizes on
> > > different platforms. The uabi must be a u64 representation of a user
> > > address to store the result - that is what we pass to the crtc set
> > > property ioctl.
> >
> > Sure, but igt_pipe is not a uabi structure. By storing a uint
Re: [Intel-gfx] [PATCH v9 01/11] drm/i915: Add i915 perf infrastructure
On Tue, Nov 22, 2016 at 1:31 PM, Daniel Vetter wrote:
> On Tue, Nov 22, 2016 at 02:29:18PM +0100, Daniel Vetter wrote:
> > On Wed, Nov 09, 2016 at 08:00:06PM +, Matthew Auld wrote:
> > > On 7 November 2016 at 19:49, Robert Bragg
> wrote:
> > > > Adds base i915 perf infrastructure for Gen performance metrics.
> > > >
> > > > This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of
> uint64
> > > > properties to configure a stream of metrics and returns a new fd
> usable
> > > > with standard VFS system calls including read() to read typed and
> sized
> > > > records; ioctl() to enable or disable capture and poll() to wait for
> > > > data.
> > > >
> > > > A stream is opened something like:
> > > >
> > > > uint64_t properties[] = {
> > > > /* Single context sampling */
> > > > DRM_I915_PERF_PROP_CTX_HANDLE,ctx_handle,
> > > >
> > > > /* Include OA reports in samples */
> > > > DRM_I915_PERF_PROP_SAMPLE_OA, true,
> > > >
> > > > /* OA unit configuration */
> > > > DRM_I915_PERF_PROP_OA_METRICS_SET,metrics_set_id,
> > > > DRM_I915_PERF_PROP_OA_FORMAT, report_format,
> > > > DRM_I915_PERF_PROP_OA_EXPONENT, period_exponent,
> > > >};
> > > >struct drm_i915_perf_open_param parm = {
> > > > .flags = I915_PERF_FLAG_FD_CLOEXEC |
> > > >I915_PERF_FLAG_FD_NONBLOCK |
> > > >I915_PERF_FLAG_DISABLED,
> > > > .properties_ptr = (uint64_t)properties,
> > > > .num_properties = sizeof(properties) / 16,
> > > >};
> > > >int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, ¶m);
> > > >
> > > > Records read all start with a common { type, size } header with
> > > > DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
> > > > contain an extensible number of fields and it's the
> > > > DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
> > > > determine what's included in every sample.
> > > >
> > > > No specific streams are supported yet so any attempt to open a stream
> > > > will return an error.
> > > >
> > > > v2:
> > > > use i915_gem_context_get() - Chris Wilson
> > > > v3:
> > > > update read() interface to avoid passing state struct - Chris
> Wilson
> > > > fix some rebase fallout, with i915-perf init/deinit
> > > > v4:
> > > > s/DRM_IORW/DRM_IOW/ - Emil Velikov
> > > >
> > > > Signed-off-by: Robert Bragg
> > > > Reviewed-by: Matthew Auld
> > > > Reviewed-by: Sourab Gupta
> > > Minor nit, there are a fair few DRM_ERROR's missing a new line.
> >
> > Also, DRM_ERROR for userspace-triggerable failures is no good. igt
> > testcase are supposed to exercise all the invalid stuff, and would then
> > fail if you spam dmesg. Why was this not caught?
> >
> > Fixup patch totally fine, but if this wasn't caught due to missing igt
> > that needs to be fixed, too.
>
> Another nitpick for the future: Enabling new features first and then
> fixing up the fallout is the wrong way round, if someone bisects over this
> range mesa might blow up in really bad ways.
>
> Oh well, this has been out there for way too long, so meh.
>
Fwiw I'm aware of this, and think I've ordered the patches correctly to
avoid bisect problems in Mesa / userspace. This infrastructure patch should
have no fallout to fix for userspace. The command parser changes that
affect userspace were done before adding oacontrol usage to i915-perf and
the cmd parser's EINVAL reporting for access failures was changed *before*
removing oacontrol from the whitelist.
Did I overlook something in particular?
- Robert
> -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 07/12] lib/igt_kms: Add support for the OUT_FENCE_PTR property
On Tue, Nov 22, 2016 at 01:50:53PM +, Brian Starkey wrote:
> On Tue, Nov 22, 2016 at 02:12:59PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 22, 2016 at 12:37:47PM +, Brian Starkey wrote:
> > > On Tue, Nov 22, 2016 at 12:10:52PM +, Chris Wilson wrote:
> > > > On Tue, Nov 22, 2016 at 11:54:57AM +, Brian Starkey wrote:
> > > > > On Tue, Nov 22, 2016 at 11:06:00AM +, Chris Wilson wrote:
> > > > > >On Tue, Nov 22, 2016 at 10:53:51AM +, Brian Starkey wrote:
> > > > > >>Hi Gustavo,
> > > > > >>
> > > > > >>A little late to the party here, but I was blocked by our internal
> > > > > >>contributions process...
> > > > > >>
> > > > > >>I didn't see these end up in my checkout yet though, so I guess they
> > > > > >>aren't picked up yet.
> > > > > >>
> > > > > >>On Mon, Nov 14, 2016 at 06:59:21PM +0900, Gustavo Padovan wrote:
> > > > > >>>From: Gustavo Padovan
> > > > > >>>
> > > > > >>>Add support for the OUT_FENCE_PTR property to enable setting out
> > > > > >>>fences for
> > > > > >>>atomic commits.
> > > > > >>>
> > > > > >>>Signed-off-by: Gustavo Padovan
> > > > > >>>---
> > > > > >>>lib/igt_kms.c | 20 +++-
> > > > > >>>lib/igt_kms.h | 3 +++
> > > > > >>>2 files changed, 22 insertions(+), 1 deletion(-)
> > > > > >>>
> > > > > >>>diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> > > > > >>>index 4748c0a..f25e1eb 100644
> > > > > >>>--- a/lib/igt_kms.c
> > > > > >>>+++ b/lib/igt_kms.c
> > > > > >>>@@ -175,7 +175,8 @@ const char
> > > > > >>>*igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
> > > > > >>> "DEGAMMA_LUT",
> > > > > >>> "GAMMA_LUT",
> > > > > >>> "MODE_ID",
> > > > > >>>- "ACTIVE"
> > > > > >>>+ "ACTIVE",
> > > > > >>>+ "OUT_FENCE_PTR"
> > > > > >>>};
> > > > > >>>
> > > > > >>>const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
> > > > > >>>@@ -2103,6 +2104,9 @@ static void
> > > > > >>>igt_atomic_prepare_crtc_commit(igt_pipe_t *pipe_obj,
> > > > > >>>drmModeAtomicRe
> > > > > >>> igt_atomic_populate_crtc_req(req, pipe_obj,
> > > > > >>> IGT_CRTC_ACTIVE, !!output);
> > > > > >>> }
> > > > > >>>
> > > > > >>>+ if (pipe_obj->out_fence_ptr)
> > > > > >>>+ igt_atomic_populate_crtc_req(req, pipe_obj,
> > > > > >>>IGT_CRTC_OUT_FENCE_PTR, pipe_obj->out_fence_ptr);
> > > > > >>>+
> > > > > >>> /*
> > > > > >>>* TODO: Add all crtc level properties here
> > > > > >>>*/
> > > > > >>>@@ -2683,6 +2687,20 @@ igt_pipe_set_gamma_lut(igt_pipe_t *pipe,
> > > > > >>>void *ptr, size_t length)
> > > > > >>>}
> > > > > >>>
> > > > > >>>/**
> > > > > >>>+ * igt_pipe_set_out_fence_ptr:
> > > > > >>>+ * @pipe: pipe pointer to which background color to be set
> > > > > >>>+ * @fence_ptr: out fence pointer
> > > > > >>
> > > > > >>I don't think fence_ptr can be int *. It needs to be a pointer to a
> > > > > >>64-bit type.
> > > > > >>
> > > > > >>>+ *
> > > > > >>>+ * Sets the out fence pointer that will be passed to the kernel in
> > > > > >>>+ * the atomic ioctl. When the kernel returns the out fence pointer
> > > > > >>>+ * will contain the fd number of the out fence created by KMS.
> > > > > >>>+ */
> > > > > >>>+void igt_pipe_set_out_fence_ptr(igt_pipe_t *pipe, int *fence_ptr)
> > > > > >>>+{
> > > > > >>>+ pipe->out_fence_ptr = (uint64_t) fence_ptr;
> > > > > >>>+}
> > > > > >>>+
> > > > > >>>+/**
> > > > > >>> * igt_crtc_set_background:
> > > > > >>> * @pipe: pipe pointer to which background color to be set
> > > > > >>> * @background: background color value in BGR 16bpc
> > > > > >>>diff --git a/lib/igt_kms.h b/lib/igt_kms.h
> > > > > >>>index 344f931..02d7bd1 100644
> > > > > >>>--- a/lib/igt_kms.h
> > > > > >>>+++ b/lib/igt_kms.h
> > > > > >>>@@ -110,6 +110,7 @@ enum igt_atomic_crtc_properties {
> > > > > >>> IGT_CRTC_GAMMA_LUT,
> > > > > >>> IGT_CRTC_MODE_ID,
> > > > > >>> IGT_CRTC_ACTIVE,
> > > > > >>>+ IGT_CRTC_OUT_FENCE_PTR,
> > > > > >>> IGT_NUM_CRTC_PROPS
> > > > > >>>};
> > > > > >>>
> > > > > >>>@@ -298,6 +299,7 @@ struct igt_pipe {
> > > > > >>>
> > > > > >>> uint64_t mode_blob;
> > > > > >>> bool mode_changed;
> > > > > >>>+ uint64_t out_fence_ptr;
> > > > > >>
> > > > > >>IMO this should be:
> > > > > >>
> > > > > >>int64_t *out_fence_ptr;
> > > > > >
> > > > > >In userspace, fences are *fd*, a plain int. It is only the uabi that
> > > > > >we
> > > > > >pass pointers as u64 to the kernel, and indeed that should be
> > > > > >limited to
> > > > > >the uabi wrapper.
> > > > > >-Chris
> > > > >
> > > > > Where's the uabi wrapper in this case?
> > > > >
> > > > > Wherever it is, afaik someone needs to have 64-bit type for the kernel
> > > > > to stash its fd in - on the kernel side out_fence_ptr is
> > > > > (s64 __user *), so if there's not a 64-bit variable on the other end
> > > > > of it then someone's going to have a bad day.
> > > >
> > > > We do not have pointers in the uabi because they are different sizes on
> > > > different platforms. The uabi must be a u64 re
Re: [Intel-gfx] [PATCH 07/12] lib/igt_kms: Add support for the OUT_FENCE_PTR property
On Tue, Nov 22, 2016 at 02:12:59PM +0100, Daniel Vetter wrote:
On Tue, Nov 22, 2016 at 12:37:47PM +, Brian Starkey wrote:
On Tue, Nov 22, 2016 at 12:10:52PM +, Chris Wilson wrote:
> On Tue, Nov 22, 2016 at 11:54:57AM +, Brian Starkey wrote:
> > On Tue, Nov 22, 2016 at 11:06:00AM +, Chris Wilson wrote:
> > >On Tue, Nov 22, 2016 at 10:53:51AM +, Brian Starkey wrote:
> > >>Hi Gustavo,
> > >>
> > >>A little late to the party here, but I was blocked by our internal
> > >>contributions process...
> > >>
> > >>I didn't see these end up in my checkout yet though, so I guess they
> > >>aren't picked up yet.
> > >>
> > >>On Mon, Nov 14, 2016 at 06:59:21PM +0900, Gustavo Padovan wrote:
> > >>>From: Gustavo Padovan
> > >>>
> > >>>Add support for the OUT_FENCE_PTR property to enable setting out fences
for
> > >>>atomic commits.
> > >>>
> > >>>Signed-off-by: Gustavo Padovan
> > >>>---
> > >>>lib/igt_kms.c | 20 +++-
> > >>>lib/igt_kms.h | 3 +++
> > >>>2 files changed, 22 insertions(+), 1 deletion(-)
> > >>>
> > >>>diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> > >>>index 4748c0a..f25e1eb 100644
> > >>>--- a/lib/igt_kms.c
> > >>>+++ b/lib/igt_kms.c
> > >>>@@ -175,7 +175,8 @@ const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS]
= {
> > >>> "DEGAMMA_LUT",
> > >>> "GAMMA_LUT",
> > >>> "MODE_ID",
> > >>>- "ACTIVE"
> > >>>+ "ACTIVE",
> > >>>+ "OUT_FENCE_PTR"
> > >>>};
> > >>>
> > >>>const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
> > >>>@@ -2103,6 +2104,9 @@ static void
igt_atomic_prepare_crtc_commit(igt_pipe_t *pipe_obj, drmModeAtomicRe
> > >>> igt_atomic_populate_crtc_req(req, pipe_obj, IGT_CRTC_ACTIVE,
!!output);
> > >>> }
> > >>>
> > >>>+ if (pipe_obj->out_fence_ptr)
> > >>>+ igt_atomic_populate_crtc_req(req, pipe_obj,
IGT_CRTC_OUT_FENCE_PTR, pipe_obj->out_fence_ptr);
> > >>>+
> > >>> /*
> > >>> * TODO: Add all crtc level properties here
> > >>> */
> > >>>@@ -2683,6 +2687,20 @@ igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void
*ptr, size_t length)
> > >>>}
> > >>>
> > >>>/**
> > >>>+ * igt_pipe_set_out_fence_ptr:
> > >>>+ * @pipe: pipe pointer to which background color to be set
> > >>>+ * @fence_ptr: out fence pointer
> > >>
> > >>I don't think fence_ptr can be int *. It needs to be a pointer to a
> > >>64-bit type.
> > >>
> > >>>+ *
> > >>>+ * Sets the out fence pointer that will be passed to the kernel in
> > >>>+ * the atomic ioctl. When the kernel returns the out fence pointer
> > >>>+ * will contain the fd number of the out fence created by KMS.
> > >>>+ */
> > >>>+void igt_pipe_set_out_fence_ptr(igt_pipe_t *pipe, int *fence_ptr)
> > >>>+{
> > >>>+ pipe->out_fence_ptr = (uint64_t) fence_ptr;
> > >>>+}
> > >>>+
> > >>>+/**
> > >>> * igt_crtc_set_background:
> > >>> * @pipe: pipe pointer to which background color to be set
> > >>> * @background: background color value in BGR 16bpc
> > >>>diff --git a/lib/igt_kms.h b/lib/igt_kms.h
> > >>>index 344f931..02d7bd1 100644
> > >>>--- a/lib/igt_kms.h
> > >>>+++ b/lib/igt_kms.h
> > >>>@@ -110,6 +110,7 @@ enum igt_atomic_crtc_properties {
> > >>> IGT_CRTC_GAMMA_LUT,
> > >>> IGT_CRTC_MODE_ID,
> > >>> IGT_CRTC_ACTIVE,
> > >>>+ IGT_CRTC_OUT_FENCE_PTR,
> > >>> IGT_NUM_CRTC_PROPS
> > >>>};
> > >>>
> > >>>@@ -298,6 +299,7 @@ struct igt_pipe {
> > >>>
> > >>> uint64_t mode_blob;
> > >>> bool mode_changed;
> > >>>+ uint64_t out_fence_ptr;
> > >>
> > >>IMO this should be:
> > >>
> > >> int64_t *out_fence_ptr;
> > >
> > >In userspace, fences are *fd*, a plain int. It is only the uabi that we
> > >pass pointers as u64 to the kernel, and indeed that should be limited to
> > >the uabi wrapper.
> > >-Chris
> >
> > Where's the uabi wrapper in this case?
> >
> > Wherever it is, afaik someone needs to have 64-bit type for the kernel
> > to stash its fd in - on the kernel side out_fence_ptr is
> > (s64 __user *), so if there's not a 64-bit variable on the other end
> > of it then someone's going to have a bad day.
>
> We do not have pointers in the uabi because they are different sizes on
> different platforms. The uabi must be a u64 representation of a user
> address to store the result - that is what we pass to the crtc set
> property ioctl.
Sure, but igt_pipe is not a uabi structure. By storing a uint64_t here
we're making it needlessly opaque what the value is actually meant to
be - which is the address of a 64-bit signed integer.
Regardless, tests cannot set out_fence_ptr to the address of an int, I
hope we can agree on that. Where that detail gets taken care of I
don't much mind - but this code as-is is incorrect.
By making igt_pipe.out_fence_ptr an (int64_t *) I thought we'd be
letting the compiler warn anyone else away from incorrect code.
> That it has been futher managled not to pass around fd
> is an interesting twist, but ideally that sillyness should not make
> itself into our API.
Allowing the kernel and userspace to have different ideas about how
big a
Re: [Intel-gfx] [PATCH v9 11/11] drm/i915: Add a kerneldoc summary for i915_perf.c
On Mon, Nov 07, 2016 at 07:49:57PM +, Robert Bragg wrote: > In particular this tries to capture for posterity some of the early > challenges we had with using the core perf infrastructure in case we > ever want to revisit adapting perf for device metrics. > > Cc: Chris Wilson > Signed-off-by: Robert Bragg > Reviewed-by: Matthew Auld > --- > drivers/gpu/drm/i915/i915_perf.c | 163 > +++ Missing the include stanza in Documentation/gpu/i915.rst, which means this won't show up in the docs build. Also function/struct docs are not included either it seems. Please check out Documentation/kernel-documentation.rst and build it all with $ make DOCBOOKS="" htmldocs Again fixup patch is fine. -Daniel > 1 file changed, 163 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_perf.c > b/drivers/gpu/drm/i915/i915_perf.c > index 1a87fe9..9551282 100644 > --- a/drivers/gpu/drm/i915/i915_perf.c > +++ b/drivers/gpu/drm/i915/i915_perf.c > @@ -24,6 +24,169 @@ > * Robert Bragg > */ > > + > +/** > + * DOC: i915 Perf, streaming API for GPU metrics > + * > + * Gen graphics supports a large number of performance counters that can help > + * driver and application developers understand and optimize their use of the > + * GPU. > + * > + * This i915 perf interface enables userspace to configure and open a file > + * descriptor representing a stream of GPU metrics which can then be read() > as > + * a stream of sample records. > + * > + * The interface is particularly suited to exposing buffered metrics that are > + * captured by DMA from the GPU, unsynchronized with and unrelated to the > CPU. > + * > + * Streams representing a single context are accessible to applications with > a > + * corresponding drm file descriptor, such that OpenGL can use the interface > + * without special privileges. Access to system-wide metrics requires root > + * privileges by default, unless changed via the dev.i915.perf_event_paranoid > + * sysctl option. > + * > + * > + * The interface was initially inspired by the core Perf infrastructure but > + * some notable differences are: > + * > + * i915 perf file descriptors represent a "stream" instead of an "event"; > where > + * a perf event primarily corresponds to a single 64bit value, while a stream > + * might sample sets of tightly-coupled counters, depending on the > + * configuration. For example the Gen OA unit isn't designed to support > + * orthogonal configurations of individual counters; it's configured for a > set > + * of related counters. Samples for an i915 perf stream capturing OA metrics > + * will include a set of counter values packed in a compact HW specific > format. > + * The OA unit supports a number of different packing formats which can be > + * selected by the user opening the stream. Perf has support for grouping > + * events, but each event in the group is configured, validated and > + * authenticated individually with separate system calls. > + * > + * i915 perf stream configurations are provided as an array of u64 > (key,value) > + * pairs, instead of a fixed struct with multiple miscellaneous config > members, > + * interleaved with event-type specific members. > + * > + * i915 perf doesn't support exposing metrics via an mmap'd circular buffer. > + * The supported metrics are being written to memory by the GPU > unsynchronized > + * with the CPU, using HW specific packing formats for counter sets. > Sometimes > + * the constraints on HW configuration require reports to be filtered before > it > + * would be acceptable to expose them to unprivileged applications - to hide > + * the metrics of other processes/contexts. For these use cases a read() > based > + * interface is a good fit, and provides an opportunity to filter data as it > + * gets copied from the GPU mapped buffers to userspace buffers. > + * > + * > + * Some notes regarding Linux Perf: > + * > + * > + * The first prototype of this driver was based on the core perf > + * infrastructure, and while we did make that mostly work, with some changes > to > + * perf, we found we were breaking or working around too many assumptions > baked > + * into perf's currently cpu centric design. > + * > + * In the end we didn't see a clear benefit to making perf's implementation > and > + * interface more complex by changing design assumptions while we knew we > still > + * wouldn't be able to use any existing perf based userspace tools. > + * > + * Also considering the Gen specific nature of the Observability hardware and > + * how userspace will sometimes need to combine i915 perf OA metrics with > + * side-band OA data captured via MI_REPORT_PERF_COUNT commands; we're > + * expecting the interface to be used by a platform specific userspace such > as > + * OpenGL or tools. This is to say; we aren't inherently missing out on > having > + * a standard vendor/architecture agnostic interface by not using perf. > +
[Intel-gfx] [PATCH v2 36/37] drm: Add mode_config .get_format_info() hook
From: Ville Syrjälä
Allow drivers to return a custom drm_format_info structure for special
fb layouts. We'll use this for the compression control surface in i915.
v2: Fix drm_get_format_info() kernel doc (Laurent)
Don't pass 'dev' to the new hook (Laurent)
Cc: Laurent Pinchart
Cc: Ben Widawsky
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
drivers/gpu/drm/drm_fourcc.c | 25 +
drivers/gpu/drm/drm_framebuffer.c| 9 +++--
drivers/gpu/drm/drm_modeset_helper.c | 2 +-
include/drm/drm_fourcc.h | 6 ++
include/drm/drm_mode_config.h| 14 ++
6 files changed, 54 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index aab4465307ed..d7f8876cf5e9 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -186,7 +186,7 @@ struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct
drm_device *dev,
int ret;
int i;
- info = drm_format_info(mode_cmd->pixel_format);
+ info = drm_get_format_info(dev, mode_cmd);
if (!info)
return ERR_PTR(-EINVAL);
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8da8eb..f9b6445e846a 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -199,6 +199,31 @@ const struct drm_format_info *drm_format_info(u32 format)
EXPORT_SYMBOL(drm_format_info);
/**
+ * drm_get_format_info - query information for a given framebuffer
configuration
+ * @dev: DRM device
+ * @mode_cmd: metadata from the userspace fb creation request
+ *
+ * Returns:
+ * The instance of struct drm_format_info that describes the pixel format, or
+ * NULL if the format is unsupported.
+ */
+const struct drm_format_info *
+drm_get_format_info(struct drm_device *dev,
+ const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ const struct drm_format_info *info = NULL;
+
+ if (dev->mode_config.funcs->get_format_info)
+ info = dev->mode_config.funcs->get_format_info(mode_cmd);
+
+ if (!info)
+ info = drm_format_info(mode_cmd->pixel_format);
+
+ return info;
+}
+EXPORT_SYMBOL(drm_get_format_info);
+
+/**
* drm_format_num_planes - get the number of planes for format
* @format: pixel format (DRM_FORMAT_*)
*
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 94ddab41f24f..292930a5dcc2 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -126,11 +126,13 @@ int drm_mode_addfb(struct drm_device *dev,
return 0;
}
-static int framebuffer_check(const struct drm_mode_fb_cmd2 *r)
+static int framebuffer_check(struct drm_device *dev,
+const struct drm_mode_fb_cmd2 *r)
{
const struct drm_format_info *info;
int i;
+ /* check if the format is supported at all */
info = __drm_format_info(r->pixel_format & ~DRM_FORMAT_BIG_ENDIAN);
if (!info) {
struct drm_format_name_buf format_name;
@@ -140,6 +142,9 @@ static int framebuffer_check(const struct drm_mode_fb_cmd2
*r)
return -EINVAL;
}
+ /* now let the driver pick its own format info */
+ info = drm_get_format_info(dev, r);
+
if (r->width == 0 || r->width % info->hsub) {
DRM_DEBUG_KMS("bad framebuffer width %u\n", r->width);
return -EINVAL;
@@ -263,7 +268,7 @@ drm_internal_framebuffer_create(struct drm_device *dev,
return ERR_PTR(-EINVAL);
}
- ret = framebuffer_check(r);
+ ret = framebuffer_check(dev, r);
if (ret)
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/drm_modeset_helper.c
b/drivers/gpu/drm/drm_modeset_helper.c
index 5b051859b8d3..f78df06a940d 100644
--- a/drivers/gpu/drm/drm_modeset_helper.c
+++ b/drivers/gpu/drm/drm_modeset_helper.c
@@ -75,7 +75,7 @@ void drm_helper_mode_fill_fb_struct(struct drm_device *dev,
int i;
fb->dev = dev;
- fb->format = drm_format_info(mode_cmd->pixel_format);
+ fb->format = drm_get_format_info(dev, mode_cmd);
fb->width = mode_cmd->width;
fb->height = mode_cmd->height;
for (i = 0; i < 4; i++) {
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index fcc08da850c8..6942e84b6edd 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -25,6 +25,9 @@
#include
#include
+struct drm_device;
+struct drm_mode_fb_cmd2;
+
/**
* struct drm_format_info - information about a DRM format
* @format: 4CC format identifier (DRM_FORMAT_*)
@@ -55,6 +58,9 @@ struct drm_format_name_buf {
const struct drm_format_info *__drm_format_info(u32 format);
const struct drm_format_info *drm_format_info(u32 format);
+const struct drm_format_info *
+drm_get_f
Re: [Intel-gfx] [PATCH] drm/i915/dp: Add a helper function to return DP link rate index
On Tue, 22 Nov 2016, Manasi Navare wrote:
> Common rates array is used to keep track of common rates
> supported between DP sink and source. This helper function
> returns the index of a specific link rate in this common rates
> array.
>
> This is in prep with patches for DP Link training compliance
> tests that need an index for the link rate specified by the
> test as well as for link training failure handling patches that
> require index of fallback link rate.
I'm not a fan of adding functions that are not used in prep patches.
BR,
Jani.
>
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Ville Syrjala
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/intel_dp.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 90283ed..bf72335 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -288,6 +288,21 @@ static int intel_dp_common_rates(struct intel_dp
> *intel_dp,
> common_rates);
> }
>
> +static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
> + int *common_rates, int link_rate)
> +{
> + int common_len;
> + int index;
> +
> + common_len = intel_dp_common_rates(intel_dp, common_rates);
> + for (index = 0; index < common_len; index++) {
> + if (link_rate == common_rates[common_len - index - 1])
> + return common_len - index - 1;
> + }
> +
> + return -1;
> +}
> +
> static enum drm_mode_status
> intel_dp_mode_valid(struct drm_connector *connector,
> struct drm_display_mode *mode)
--
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: Move the release of PT page to the upper caller
Hi guys:
Would you mind to have a quick review on this patch? :P The linux
guest under GVT-g couldn't boot up without this patch in the newer kernel.
Thanks,
Zhi.
On 11/21/16 19:44, Zhi Wang wrote:
a PT page will be released if it doesn't contain any meaningful mappings
during PPGTT page table shrinking. The PT entry in the upper level will
be set to a scratch entry.
Normally this works nicely, but in virtualization world, the PPGTT page
table is tracked by hypervisor. Releasing the PT page before modifying
the upper level PT entry would cause extra efforts.
As the tracked page has been returned to OS before losing track from
hypervisor, it could be written in any pattern. Hypervisor has to recognize
if a page is still being used as a PT page by validating these writing
patterns. It's complicated. Better let the guest modify the PT entry in
upper level PT first, then release the PT page.
Cc: Michał Winiarski
Cc: Michel Thierry
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Zhenyu Wang
Cc: Zhiyuan Lv
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index b4bde14..6cee707 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -736,10 +736,8 @@ static bool gen8_ppgtt_clear_pt(struct i915_address_space
*vm,
bitmap_clear(pt->used_ptes, pte, num_entries);
- if (bitmap_empty(pt->used_ptes, GEN8_PTES)) {
- free_pt(to_i915(vm->dev), pt);
+ if (bitmap_empty(pt->used_ptes, GEN8_PTES))
return true;
- }
pt_vaddr = kmap_px(pt);
@@ -775,13 +773,12 @@ static bool gen8_ppgtt_clear_pd(struct i915_address_space
*vm,
pde_vaddr = kmap_px(pd);
pde_vaddr[pde] = scratch_pde;
kunmap_px(ppgtt, pde_vaddr);
+ free_pt(to_i915(vm->dev), pt);
}
}
- if (bitmap_empty(pd->used_pdes, I915_PDES)) {
- free_pd(to_i915(vm->dev), pd);
+ if (bitmap_empty(pd->used_pdes, I915_PDES))
return true;
- }
return false;
}
@@ -795,7 +792,6 @@ static bool gen8_ppgtt_clear_pdp(struct i915_address_space
*vm,
uint64_t length)
{
struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
- struct drm_i915_private *dev_priv = to_i915(vm->dev);
struct i915_page_directory *pd;
uint64_t pdpe;
gen8_ppgtt_pdpe_t *pdpe_vaddr;
@@ -813,16 +809,14 @@ static bool gen8_ppgtt_clear_pdp(struct
i915_address_space *vm,
pdpe_vaddr[pdpe] = scratch_pdpe;
kunmap_px(ppgtt, pdpe_vaddr);
}
+ free_pd(to_i915(vm->dev), pd);
}
}
mark_tlbs_dirty(ppgtt);
- if (USES_FULL_48BIT_PPGTT(dev_priv) &&
- bitmap_empty(pdp->used_pdpes, I915_PDPES_PER_PDP(dev_priv))) {
- free_pdp(dev_priv, pdp);
+ if (bitmap_empty(pdp->used_pdpes, I915_PDPES_PER_PDP(dev_priv)))
return true;
- }
return false;
}
@@ -836,6 +830,7 @@ static void gen8_ppgtt_clear_pml4(struct i915_address_space
*vm,
uint64_t start,
uint64_t length)
{
+ struct drm_i915_private *dev_priv = to_i915(vm->dev);
struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
struct i915_page_directory_pointer *pdp;
uint64_t pml4e;
@@ -854,6 +849,7 @@ static void gen8_ppgtt_clear_pml4(struct i915_address_space
*vm,
pml4e_vaddr = kmap_px(pml4);
pml4e_vaddr[pml4e] = scratch_pml4e;
kunmap_px(ppgtt, pml4e_vaddr);
+ free_pdp(dev_priv, pdp);
}
}
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: don't whitelist oacontrol in cmd parser
On Tue, Nov 08, 2016 at 12:51:48PM +, Robert Bragg wrote:
> This v2 patch bumps the command parser version so it can be referenced in
> corresponding i-g-t gem_exec_parse changes.
>
> --- >8 ---
Scissors cut everything below, not everything above, hence next time
around pls switch around your comment and the commit message, as-is not
much left ;-)
Fixed up while applying.
-Daniel
>
> Being able to program OACONTROL from a non-privileged batch buffer is
> not sufficient to be able to configure the OA unit. This was originally
> allowed to help enable Mesa to expose OA counters via the
> INTEL_performance_query extension, but the current implementation based
> on programming OACONTROL via a batch buffer isn't able to report useable
> data without a more complete OA unit configuration. Mesa handles the
> possibility that writes to OACONTROL may not be allowed and so only
> advertises the extension after explicitly testing that a write to
> OACONTROL succeeds. Based on this; removing OACONTROL from the whitelist
> should be ok for userspace.
>
> Removing this simplifies adding a new kernel api for configuring the OA
> unit without needing to consider the possibility that userspace might
> trample on OACONTROL state which we'd like to start managing within
> the kernel instead. In particular running any Mesa based GL application
> currently results in clearing OACONTROL when initializing which would
> disable the capturing of metrics.
>
> v2:
> This bumps the command parser version from 8 to 9, as the change is
> visible to userspace.
>
> Signed-off-by: Robert Bragg
> Reviewed-by: Matthew Auld
> Reviewed-by: Sourab Gupta
> ---
> drivers/gpu/drm/i915/i915_cmd_parser.c | 42
> --
> 1 file changed, 5 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
> b/drivers/gpu/drm/i915/i915_cmd_parser.c
> index c9d2ecd..f5762cd 100644
> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
> @@ -450,7 +450,6 @@ static const struct drm_i915_reg_descriptor
> gen7_render_regs[] = {
> REG64(PS_INVOCATION_COUNT),
> REG64(PS_DEPTH_COUNT),
> REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE),
> - REG32(GEN7_OACONTROL), /* Only allowed for LRI and SRM. See below. */
> REG64(MI_PREDICATE_SRC0),
> REG64(MI_PREDICATE_SRC1),
> REG32(GEN7_3DPRIM_END_OFFSET),
> @@ -1060,8 +1059,7 @@ bool intel_engine_needs_cmd_parser(struct
> intel_engine_cs *engine)
> static bool check_cmd(const struct intel_engine_cs *engine,
> const struct drm_i915_cmd_descriptor *desc,
> const u32 *cmd, u32 length,
> - const bool is_master,
> - bool *oacontrol_set)
> + const bool is_master)
> {
> if (desc->flags & CMD_DESC_SKIP)
> return true;
> @@ -1099,31 +1097,6 @@ static bool check_cmd(const struct intel_engine_cs
> *engine,
> }
>
> /*
> - * OACONTROL requires some special handling for
> - * writes. We want to make sure that any batch which
> - * enables OA also disables it before the end of the
> - * batch. The goal is to prevent one process from
> - * snooping on the perf data from another process. To do
> - * that, we need to check the value that will be written
> - * to the register. Hence, limit OACONTROL writes to
> - * only MI_LOAD_REGISTER_IMM commands.
> - */
> - if (reg_addr == i915_mmio_reg_offset(GEN7_OACONTROL)) {
> - if (desc->cmd.value == MI_LOAD_REGISTER_MEM) {
> - DRM_DEBUG_DRIVER("CMD: Rejected LRM to
> OACONTROL\n");
> - return false;
> - }
> -
> - if (desc->cmd.value == MI_LOAD_REGISTER_REG) {
> - DRM_DEBUG_DRIVER("CMD: Rejected LRR to
> OACONTROL\n");
> - return false;
> - }
> -
> - if (desc->cmd.value == MI_LOAD_REGISTER_IMM(1))
> - *oacontrol_set = (cmd[offset + 1] != 0);
> - }
> -
> - /*
>* Check the value written to the register against the
>* allowed mask/value pair given in the whitelist entry.
>*/
> @@ -1214,7 +1187,6 @@ int intel_engine_cmd_parser(struct intel_engine_cs
> *engine,
> u32 *cmd, *batch_end;
> struct drm_i915_cmd_descriptor default_desc = noop_desc;
> const struct drm_i915_cmd_descriptor *desc = &default_desc;
> - bool oacontrol_set = false; /*
Re: [Intel-gfx] [PATCH v5 4/8] drm/i915/bxt: Enable IPC support
Hi,
On Tuesday 22 November 2016 12:16 AM, Paulo Zanoni wrote:
Em Sex, 2016-11-18 às 20:39 +0530, Mahesh Kumar escreveu:
This patch adds IPC support for platforms. This patch enables IPC
only for BXT/KBL platform as for SKL recommendation is to keep is
disabled.
IPC (Isochronous Priority Control) is the hardware feature, which
dynamically controles the memory read priority of Display.
When IPC is enabled, plane read requests are sent at high priority
until
filling above the transition watermark, then the requests are sent at
lower priority until dropping below the level 0 watermark.
The lower priority requests allow other memory clients to have better
memory access. When IPC is disabled, all plane read requests are sent
at
high priority.
Changes since V1:
- Remove commandline parameter to disable ipc
- Address Paulo's comments
Changes since V2:
- Address review comments
- Set ipc_enabled flag
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 15 +++
4 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 1b0a589..4074601 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1244,6 +1244,7 @@ int i915_driver_load(struct pci_dev *pdev,
const struct pci_device_id *ent)
intel_runtime_pm_enable(dev_priv);
dev_priv->ipc_enabled = false;
+ intel_enable_ipc(dev_priv);
So now we have to places that touch dev_priv->ipc_enabled. This one and
intel_enable_ipc(). Please move that "dev_priv->ipc_enabled = false"
line to inside intel_enable_ipc(). It's much easier to read the code
when there's a single function responsible for setting the appropriate
value to a variable.
Besides, my understanding of your discussion with Maarten in the last
revision of this patch was that we needed to change where
intel_enable_ipc() is called in order to make sure the bit stays
enabled after suspend/resume. If that's not needed, why is it not
needed?
We don't overwrite DISP_ARB_CTL2 register during suspend/resume
So there will not be any impact of it & handling during suspend/resume
is not needed.
thanks for review
Regards,
-Mahesh
/* Everything is in place, we can now relax! */
DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index c70c07a..300418a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6076,6 +6076,7 @@ enum {
#define DISP_FBC_WM_DIS (1<<15)
#define DISP_ARB_CTL2 _MMIO(0x45004)
#define DISP_DATA_PARTITION_5_6 (1<<6)
+#define DISP_IPC_ENABLE (1<<3)
#define DBUF_CTL _MMIO(0x45008)
#define DBUF_POWER_REQUEST (1<<31)
#define DBUF_POWER_STATE (1<<30)
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index cd132c2..ad542a2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1745,6 +1745,7 @@ bool skl_ddb_allocation_overlaps(const struct
skl_ddb_entry **entries,
uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state
*pipe_config);
bool ilk_disable_lp_wm(struct drm_device *dev);
int sanitize_rc6_option(struct drm_i915_private *dev_priv, int
enable_rc6);
+void intel_enable_ipc(struct drm_i915_private *dev_priv);
static inline int intel_enable_rc6(void)
{
return i915.enable_rc6;
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index df39b50..d8090aa 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4682,6 +4682,21 @@ void intel_update_watermarks(struct intel_crtc
*crtc)
dev_priv->display.update_wm(crtc);
}
+void intel_enable_ipc(struct drm_i915_private *dev_priv)
+{
+ u32 val;
+
+ if (!(IS_BROXTON(dev_priv) || IS_KABYLAKE(dev_priv)))
+ return;
+
+ val = I915_READ(DISP_ARB_CTL2);
+
+ val |= DISP_IPC_ENABLE;
+
+ I915_WRITE(DISP_ARB_CTL2, val);
+ dev_priv->ipc_enabled = true;
+}
+
/*
* Lock protecting IPS related data structures
*/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 01/11] drm/i915: Add i915 perf infrastructure
On Tue, Nov 22, 2016 at 02:29:18PM +0100, Daniel Vetter wrote:
> On Wed, Nov 09, 2016 at 08:00:06PM +, Matthew Auld wrote:
> > On 7 November 2016 at 19:49, Robert Bragg wrote:
> > > Adds base i915 perf infrastructure for Gen performance metrics.
> > >
> > > This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
> > > properties to configure a stream of metrics and returns a new fd usable
> > > with standard VFS system calls including read() to read typed and sized
> > > records; ioctl() to enable or disable capture and poll() to wait for
> > > data.
> > >
> > > A stream is opened something like:
> > >
> > > uint64_t properties[] = {
> > > /* Single context sampling */
> > > DRM_I915_PERF_PROP_CTX_HANDLE,ctx_handle,
> > >
> > > /* Include OA reports in samples */
> > > DRM_I915_PERF_PROP_SAMPLE_OA, true,
> > >
> > > /* OA unit configuration */
> > > DRM_I915_PERF_PROP_OA_METRICS_SET,metrics_set_id,
> > > DRM_I915_PERF_PROP_OA_FORMAT, report_format,
> > > DRM_I915_PERF_PROP_OA_EXPONENT, period_exponent,
> > >};
> > >struct drm_i915_perf_open_param parm = {
> > > .flags = I915_PERF_FLAG_FD_CLOEXEC |
> > >I915_PERF_FLAG_FD_NONBLOCK |
> > >I915_PERF_FLAG_DISABLED,
> > > .properties_ptr = (uint64_t)properties,
> > > .num_properties = sizeof(properties) / 16,
> > >};
> > >int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, ¶m);
> > >
> > > Records read all start with a common { type, size } header with
> > > DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
> > > contain an extensible number of fields and it's the
> > > DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
> > > determine what's included in every sample.
> > >
> > > No specific streams are supported yet so any attempt to open a stream
> > > will return an error.
> > >
> > > v2:
> > > use i915_gem_context_get() - Chris Wilson
> > > v3:
> > > update read() interface to avoid passing state struct - Chris Wilson
> > > fix some rebase fallout, with i915-perf init/deinit
> > > v4:
> > > s/DRM_IORW/DRM_IOW/ - Emil Velikov
> > >
> > > Signed-off-by: Robert Bragg
> > > Reviewed-by: Matthew Auld
> > > Reviewed-by: Sourab Gupta
> > Minor nit, there are a fair few DRM_ERROR's missing a new line.
>
> Also, DRM_ERROR for userspace-triggerable failures is no good. igt
> testcase are supposed to exercise all the invalid stuff, and would then
> fail if you spam dmesg. Why was this not caught?
>
> Fixup patch totally fine, but if this wasn't caught due to missing igt
> that needs to be fixed, too.
Another nitpick for the future: Enabling new features first and then
fixing up the fallout is the wrong way round, if someone bisects over this
range mesa might blow up in really bad ways.
Oh well, this has been out there for way too long, so meh.
-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
[Intel-gfx] [PATCH i-g-t v9 20/21] tests/sw_sync: Add subtest test_sync_busy_fork
From: Robert Foss
Add subtest test_sync_busy_fork which increments the timeline in a forked child
process.
Signed-off-by: Robert Foss
---
tests/sw_sync.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 3a67877..e0bf6c3 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -171,6 +171,42 @@ static void test_sync_busy(void)
close(timeline);
}
+static void test_sync_busy_fork(void)
+{
+ int fence, ret;
+ int timeline;
+ int skip = 0;
+
+ timeline = sw_sync_timeline_create();
+ fence = sw_sync_fence_create(timeline, 1);
+
+ switch (fork()) {
+ case 0:
+ /* Child process */
+ usleep(1*1000*1000);
+ /* Advance timeline from 0 -> 1 */
+ sw_sync_timeline_inc(timeline, 1);
+ _Exit(0);
+ break;
+ case -1:
+ /* Failed fork */
+ skip = 1;
+ break;
+ default:
+ /* Parent process */
+ ret = sync_wait(fence, 0);
+ igt_assert_f(ret == -1 && errno == ETIME, "Fence signaled (it
should not have been signalled yet)\n");
+
+ ret = sync_wait(fence, 2*1000);
+ igt_assert_f(ret == 0, "Fence not signaled (timeline value 1
fence seqno 1)\n");
+ break;
+ }
+
+ close(fence);
+ close(timeline);
+ igt_require(!skip);
+}
+
static void test_sync_merge_invalid(void)
{
int in_fence;
@@ -789,6 +825,9 @@ igt_main
igt_subtest("sync_busy")
test_sync_busy();
+ igt_subtest("sync_busy_fork")
+ test_sync_busy_fork();
+
igt_subtest("sync_merge_invalid")
test_sync_merge_invalid();
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 01/11] drm/i915: Add i915 perf infrastructure
On Wed, Nov 09, 2016 at 08:00:06PM +, Matthew Auld wrote:
> On 7 November 2016 at 19:49, Robert Bragg wrote:
> > Adds base i915 perf infrastructure for Gen performance metrics.
> >
> > This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
> > properties to configure a stream of metrics and returns a new fd usable
> > with standard VFS system calls including read() to read typed and sized
> > records; ioctl() to enable or disable capture and poll() to wait for
> > data.
> >
> > A stream is opened something like:
> >
> > uint64_t properties[] = {
> > /* Single context sampling */
> > DRM_I915_PERF_PROP_CTX_HANDLE,ctx_handle,
> >
> > /* Include OA reports in samples */
> > DRM_I915_PERF_PROP_SAMPLE_OA, true,
> >
> > /* OA unit configuration */
> > DRM_I915_PERF_PROP_OA_METRICS_SET,metrics_set_id,
> > DRM_I915_PERF_PROP_OA_FORMAT, report_format,
> > DRM_I915_PERF_PROP_OA_EXPONENT, period_exponent,
> >};
> >struct drm_i915_perf_open_param parm = {
> > .flags = I915_PERF_FLAG_FD_CLOEXEC |
> >I915_PERF_FLAG_FD_NONBLOCK |
> >I915_PERF_FLAG_DISABLED,
> > .properties_ptr = (uint64_t)properties,
> > .num_properties = sizeof(properties) / 16,
> >};
> >int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, ¶m);
> >
> > Records read all start with a common { type, size } header with
> > DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
> > contain an extensible number of fields and it's the
> > DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
> > determine what's included in every sample.
> >
> > No specific streams are supported yet so any attempt to open a stream
> > will return an error.
> >
> > v2:
> > use i915_gem_context_get() - Chris Wilson
> > v3:
> > update read() interface to avoid passing state struct - Chris Wilson
> > fix some rebase fallout, with i915-perf init/deinit
> > v4:
> > s/DRM_IORW/DRM_IOW/ - Emil Velikov
> >
> > Signed-off-by: Robert Bragg
> > Reviewed-by: Matthew Auld
> > Reviewed-by: Sourab Gupta
> Minor nit, there are a fair few DRM_ERROR's missing a new line.
Also, DRM_ERROR for userspace-triggerable failures is no good. igt
testcase are supposed to exercise all the invalid stuff, and would then
fail if you spam dmesg. Why was this not caught?
Fixup patch totally fine, but if this wasn't caught due to missing igt
that needs to be fixed, too.
-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
[Intel-gfx] [PATCH i-g-t v9 07/21] tests/sw_sync: Add subtest test_sync_merge
From: Robert Foss
Add subtest test_sync_merge that tests merging fences and the validity of the
resulting merged fence.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 67 +
1 file changed, 67 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index b962e82..96dcbff 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -131,6 +131,70 @@ static void test_sync_busy(void)
close(timeline);
}
+static void test_sync_merge(void)
+{
+ int in_fence[3];
+ int fence_merge;
+ int timeline;
+ int active, signaled;
+
+ timeline = sw_sync_timeline_create();
+ in_fence[0] = sw_sync_fence_create(timeline, 1);
+ in_fence[1] = sw_sync_fence_create(timeline, 2);
+ in_fence[2] = sw_sync_fence_create(timeline, 3);
+
+ fence_merge = sync_merge(in_fence[0], in_fence[1]);
+ fence_merge = sync_merge(in_fence[2], fence_merge);
+
+ /* confirm all fences have one active point (even d) */
+ active = sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(active == 1, "in_fence[0] has too many active fences\n");
+ active = sync_fence_count_status(in_fence[1],
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(active == 1, "in_fence[1] has too many active fences\n");
+ active = sync_fence_count_status(in_fence[2],
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(active == 1, "in_fence[2] has too many active fences\n");
+ active = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(active == 1, "fence_merge has too many active fences\n");
+
+ /* confirm that fence_merge is not signaled until the max of fence
0,1,2 */
+ sw_sync_timeline_inc(timeline, 1);
+ signaled = sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+ active = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(signaled == 1, "in_fence[0] did not signal\n");
+ igt_assert_f(active == 1, "fence_merge signaled too early\n");
+
+ sw_sync_timeline_inc(timeline, 1);
+ signaled = sync_fence_count_status(in_fence[1],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+ active = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(signaled == 1, "in_fence[1] did not signal\n");
+ igt_assert_f(active == 1, "fence_merge signaled too early\n");
+
+ sw_sync_timeline_inc(timeline, 1);
+ signaled = sync_fence_count_status(in_fence[2],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+ igt_assert_f(signaled == 1, "in_fence[2] did not signal\n");
+ signaled = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+ active = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(active == 0 && signaled == 1,
+"fence_merge did not signal\n");
+
+ close(in_fence[0]);
+ close(in_fence[1]);
+ close(in_fence[2]);
+ close(fence_merge);
+ close(timeline);
+}
+
igt_main
{
igt_subtest("alloc_timeline")
@@ -147,5 +211,8 @@ igt_main
igt_subtest("sync_busy")
test_sync_busy();
+
+ igt_subtest("sync_merge")
+ test_sync_merge();
}
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v9 21/21] tests/sw_sync: Add subtest test_sync_busy_unixsocket
From: Robert Foss
Add subtest test_sync_busy_fork which increments the timeline in a forked child
process, where the timeline fd has been sent through a UNIX socket.
Signed-off-by: Robert Foss
---
tests/sw_sync.c | 103
1 file changed, 103 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index e0bf6c3..bcf5731 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -30,6 +30,8 @@
#include
#include
#include
+#include
+#include
#include
#include "igt.h"
@@ -171,6 +173,104 @@ static void test_sync_busy(void)
close(timeline);
}
+static void test_sync_busy_fork_unixsocket(void)
+{
+ int fence, ret;
+ int timeline;
+ int skip = 0;
+ int sv[2];
+
+
+ timeline = sw_sync_timeline_create();
+ fence = sw_sync_fence_create(timeline, 1);
+
+ if (socketpair(AF_UNIX, SOCK_DGRAM, 0, sv) != 0) {
+ skip = 1;
+ goto out;
+ }
+
+ switch (fork()) {
+ case 0:
+ {
+ /* Child process */
+ int socket = sv[1];
+ int socket_timeline;
+ struct msghdr msg = {0};
+ struct cmsghdr *cmsg;
+ unsigned char *data;
+ char m_buffer[256];
+ char c_buffer[256];
+ struct iovec io = { .iov_base = m_buffer, .iov_len =
sizeof(m_buffer) };
+ close(sv[0]);
+
+ msg.msg_iov = &io;
+ msg.msg_iovlen = 1;
+ msg.msg_control = c_buffer;
+ msg.msg_controllen = sizeof(c_buffer);
+
+ if (recvmsg(socket, &msg, 0) < 0)
+ _Exit(1);
+
+ cmsg = CMSG_FIRSTHDR(&msg);
+ data = CMSG_DATA(cmsg);
+ socket_timeline = *((int *) data);
+
+ /* Advance timeline from 0 -> 1 */
+ sw_sync_timeline_inc(socket_timeline, 1);
+
+ _Exit(0);
+ break;
+ }
+ case -1:
+ {
+ /* Failed fork */
+ skip = 1;
+ break;
+ }
+ default:
+ {
+ /* Parent process */
+ int socket = sv[0];
+ struct cmsghdr *cmsg;
+ struct iovec io = { .iov_base = (char *)"ABC", .iov_len = 3 };
+ struct msghdr msg = { 0 };
+ char buf[CMSG_SPACE(sizeof(timeline))];
+ memset(buf, '\0', sizeof(buf));
+ close(sv[1]);
+
+ msg.msg_iov = &io;
+ msg.msg_iovlen = 1;
+ msg.msg_control = buf;
+ msg.msg_controllen = sizeof(buf);
+
+ cmsg = CMSG_FIRSTHDR(&msg);
+ cmsg->cmsg_level = SOL_SOCKET;
+ cmsg->cmsg_type = SCM_RIGHTS;
+ cmsg->cmsg_len = CMSG_LEN(sizeof(timeline));
+
+ *((int *) CMSG_DATA(cmsg)) = timeline;
+ msg.msg_controllen = cmsg->cmsg_len;
+
+ ret = sync_wait(fence, 0);
+ igt_assert_f(ret == -1 && errno == ETIME, "Fence signaled (it
should not have been signalled yet)\n");
+
+ if (sendmsg(socket, &msg, 0) < 0) {
+ skip = 1;
+ goto out;
+ }
+
+ ret = sync_wait(fence, 2*1000);
+ igt_assert_f(ret == 0, "Fence not signaled (timeline value 1
fence seqno 1)\n");
+ break;
+ }
+ }
+
+out:
+ close(fence);
+ close(timeline);
+ igt_require(!skip);
+}
+
static void test_sync_busy_fork(void)
{
int fence, ret;
@@ -828,6 +928,9 @@ igt_main
igt_subtest("sync_busy_fork")
test_sync_busy_fork();
+ igt_subtest("sync_busy_fork_unixsocket")
+ test_sync_busy_fork_unixsocket();
+
igt_subtest("sync_merge_invalid")
test_sync_merge_invalid();
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v9 09/21] tests/sw_sync: Add subtest test_sync_multi_consumer
From: Robert Foss
This subtest verifies the access ordering of multiple consumer threads.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 103
1 file changed, 103 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index ada1243..cd0c588 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -27,6 +27,8 @@
*Robert Foss
*/
+#include
+#include
#include
#include
@@ -39,6 +41,15 @@
IGT_TEST_DESCRIPTION("Test SW Sync Framework");
+typedef struct {
+ int timeline;
+ uint32_t thread_id;
+ uint32_t nbr_threads;
+ uint32_t nbr_iterations;
+ volatile uint32_t * volatile counter;
+ sem_t *sem;
+} data_t;
+
static void test_alloc_timeline(void)
{
int timeline;
@@ -219,6 +230,95 @@ static void test_sync_merge_same(void)
close(timeline);
}
+static void * test_sync_multi_consumer_thread(void *arg)
+{
+ data_t *data = arg;
+ int thread_id = data->thread_id;
+ int nbr_threads = data->nbr_threads;
+ int timeline = data->timeline;
+ int iterations = data->nbr_iterations;
+ int ret, i;
+
+ for (i = 0; i < iterations; i++) {
+ int next_point = i * nbr_threads + thread_id;
+ int fence = sw_sync_fence_create(timeline, next_point);
+
+ ret = sync_wait(fence, 1000);
+ if (ret == -1)
+ {
+ return (void *) 1;
+ }
+
+ if (*(data->counter) != next_point)
+ {
+ return (void *) 1;
+ }
+
+ sem_post(data->sem);
+ close(fence);
+ }
+ return NULL;
+}
+
+static void test_sync_multi_consumer(void)
+{
+ const uint32_t nbr_threads = 8;
+ const uint32_t nbr_iterations = 1 << 14;
+ data_t data_arr[nbr_threads];
+ pthread_t thread_arr[nbr_threads];
+ sem_t sem;
+ int timeline;
+ volatile uint32_t counter = 0;
+ uintptr_t thread_ret = 0;
+ data_t data;
+ int i, ret;
+
+ sem_init(&sem, 0, 0);
+ timeline = sw_sync_timeline_create();
+
+ data.nbr_iterations = nbr_iterations;
+ data.nbr_threads = nbr_threads;
+ data.counter = &counter;
+ data.timeline = timeline;
+ data.sem = &sem;
+
+ /* Start sync threads. */
+ for (i = 0; i < nbr_threads; i++)
+ {
+ data_arr[i] = data;
+ data_arr[i].thread_id = i;
+ ret = pthread_create(&thread_arr[i], NULL,
+test_sync_multi_consumer_thread,
+(void *) &(data_arr[i]));
+ igt_assert_eq(ret, 0);
+ }
+
+ /* Produce 'content'. */
+ for (i = 0; i < nbr_threads * nbr_iterations; i++)
+ {
+ sem_wait(&sem);
+
+ counter++;
+ sw_sync_timeline_inc(timeline, 1);
+ }
+
+ /* Wait for threads to complete. */
+ for (i = 0; i < nbr_threads; i++)
+ {
+ uintptr_t local_thread_ret;
+ pthread_join(thread_arr[i], (void **)&local_thread_ret);
+ thread_ret |= local_thread_ret;
+ }
+
+ close(timeline);
+ sem_destroy(&sem);
+
+ igt_assert_f(counter == nbr_threads * nbr_iterations,
+"Counter has unexpected value.\n");
+
+ igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
+}
+
igt_main
{
igt_subtest("alloc_timeline")
@@ -241,5 +341,8 @@ igt_main
igt_subtest("sync_merge_same")
test_sync_merge_same();
+
+ igt_subtest("sync_multi_consumer")
+ test_sync_multi_consumer();
}
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v9 16/21] tests/sw_sync: Add subtest test_timeline_closed_signaled
From: Robert Foss
Add subtest test_timeline_closed_signaled that verifies that a signaled fence
stays signaled after its timeline has been closed.
Signed-off-by: Robert Foss
---
tests/sw_sync.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 1d2c921..ef21af6 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -89,6 +89,21 @@ static void test_timeline_closed(void)
"Failure waiting on unsignaled fence on closed
timeline\n");
}
+static void test_timeline_closed_signaled(void)
+{
+ int fence, ret;
+ int timeline;
+
+ timeline = sw_sync_timeline_create();
+ fence = sw_sync_fence_create(timeline, 1);
+
+ sw_sync_timeline_inc(timeline, 1);
+ close(timeline);
+ ret = sync_wait(fence, 0);
+ igt_assert_f(ret == 0,
+"Failure waiting on signaled fence for closed timeline\n");
+}
+
static void test_alloc_merge_fence(void)
{
int in_fence[2];
@@ -724,6 +739,9 @@ igt_main
igt_subtest("timeline_closed")
test_timeline_closed();
+ igt_subtest("timeline_closed_signaled")
+ test_timeline_closed_signaled();
+
igt_subtest("alloc_merge_fence")
test_alloc_merge_fence();
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v9 06/21] tests/sw_sync: Add subtest test_sync_busy
From: Robert Foss
This subtest verifies that waiting on fences works properly.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 51 +++
1 file changed, 51 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 03bc0b3..b962e82 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -32,6 +32,7 @@
#include "igt.h"
#include "igt_aux.h"
+#include "igt_primes.h"
#include "sw_sync.h"
@@ -83,6 +84,53 @@ static void test_alloc_merge_fence(void)
close(timeline[1]);
}
+static void test_sync_busy(void)
+{
+ int fence, ret;
+ int timeline;
+ int seqno;
+
+ timeline = sw_sync_timeline_create();
+ fence = sw_sync_fence_create(timeline, 5);
+
+ /* Make sure that fence has not been signaled yet */
+ ret = sync_wait(fence, 0);
+ igt_assert_f(ret == -1 && errno == ETIME, "Fence signaled early
(timeline value 0, fence seqno 5)\n");
+
+ /* Advance timeline from 0 -> 1 */
+ sw_sync_timeline_inc(timeline, 1);
+
+ /* Make sure that fence has not been signaled yet */
+ ret = sync_wait(fence, 0);
+ igt_assert_f(ret == -1 && errno == ETIME, "Fence signaled early
(timeline value 1, fence seqno 5)\n");
+
+ /* Advance timeline from 1 -> 5: signaling the fence (seqno 5)*/
+ sw_sync_timeline_inc(timeline, 4);
+ ret = sync_wait(fence, 0);
+ igt_assert_f(ret == 0, "Fence not signaled (timeline value 5, fence
seqno 5)\n");
+
+ /* Go even further, and confirm wait still succeeds */
+ sw_sync_timeline_inc(timeline, 5);
+ ret = sync_wait(fence, 0);
+ igt_assert_f(ret == 0, "Fence not signaled (timeline value 10, fence
seqno 5)\n");
+
+ seqno = 10;
+ for_each_prime_number(prime, 100) {
+ int fence_prime;
+ seqno += prime;
+
+ fence_prime = sw_sync_fence_create(timeline, seqno);
+ sw_sync_timeline_inc(timeline, prime);
+
+ ret = sync_wait(fence_prime, 0);
+ igt_assert_f(ret == 0, "Fence not signaled during test of prime
timeline increments\n");
+ close(fence_prime);
+ }
+
+ close(fence);
+ close(timeline);
+}
+
igt_main
{
igt_subtest("alloc_timeline")
@@ -96,5 +144,8 @@ igt_main
igt_subtest("alloc_merge_fence")
test_alloc_merge_fence();
+
+ igt_subtest("sync_busy")
+ test_sync_busy();
}
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
