Re: [Intel-gfx] [PATCH v6 0/3] drm & vgaarb: handle vgacon removal in vgaarb.
Hi, > -Original Message- > From: Gerd Hoffmann [mailto:kra...@redhat.com] > Sent: perjantai 1. maaliskuuta 2019 8.12 > To: Saarinen, Jani > Cc: Hiler, Arkadiusz ; Sarvela, Tomi P > ; intel-gfx > Subject: Re: [Intel-gfx] [PATCH v6 0/3] drm & vgaarb: handle vgacon removal in > vgaarb. > > Hi, > > > > Hmm, I see the test results in patchwork, but I can't remember having > > > seen a > mail. > > > So the next question: where the results are sent to? > > From page above sent by Arek: > > " Since we accept patches through mailing lists, this is where you can > > find the results - they are sent out as a replies to the original > > mail. Here are the mailing lists we currently support:" > > Hmm, I'm not subscribed to intel-gfx, so that explains why I havn't seen the > result > mails. Any chance to sent the results also to the patch submitter? It patches are sent to mailing list(s) (intel-gfx, trybot or igt-dev) and patches apply or not cleanly to latest drm-tip then results are sent both to developer and list as cc. Arek, Tomi, any other comments? > > thanks, > Gerd ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib: Incrementally mlock()
On Wed, Feb 27, 2019 at 04:29:50PM +, Chris Wilson wrote:
As we already have the previous portion of the mmap mlocked, we only
need to mlock() the fresh portion for testing available memory.
v2: Fixup the uint64_t pointer arithmetric and only use a single mmap to
avoid subsequent mlock fail (for reasons unknown, but bet on mm/).
Signed-off-by: Chris Wilson
Cc: Caz Yokoyama
Wondering how this patch was reviewed, tested and merged. The parent
process still dies with 100% certainty rendering the test useless:
# build/tests/i915_suspend --run-subtest shrink
IGT-Version: 1.23-g6be2dc8d (x86_64) (Linux: 5.0.0-rc5+ x86_64)
Starting subtest: shrink
child 0 died with signal 9, Killed
child 0 died with signal 9, Killed
child 0 died with signal 9, Killed
child 0 died with signal 9, Killed
child 0 died with signal 9, Killed
child 0 died with signal 9, Killed
Killed
+ if (*can_mlock > locked + inc) { /* Weird bit of mm/ lore */
What is the meaning of this if check? The parent should mlock the
incremental amount the child has mlocked unconditionally as was done in the
previous version. If the objective was to kludge our way out of the parent
dying that objective doesn't seem to have been met either :(
-Ashutosh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 0/3] drm & vgaarb: handle vgacon removal in vgaarb.
Hi, > > Hmm, I see the test results in patchwork, but I can't remember having seen > > a mail. > > So the next question: where the results are sent to? > From page above sent by Arek: > " Since we accept patches through mailing lists, this is where you can > find the results - they are sent out as a replies to the original > mail. Here are the mailing lists we currently support:" Hmm, I'm not subscribed to intel-gfx, so that explains why I havn't seen the result mails. Any chance to sent the results also to the patch submitter? thanks, Gerd ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 5/6] drm/i915: Disable PSR2 while getting pipe CRC
On Thu, 2019-02-28 at 17:57 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2019-02-28 at 15:07 -0800, Souza, Jose wrote:
> > On Thu, 2019-02-28 at 18:58 +0200, Ville Syrjälä wrote:
> > > On Wed, Feb 27, 2019 at 05:32:58PM -0800, José Roberto de Souza
> > > wrote:
> > > > When PSR2 is active aka after the number of frames programmed
> > > > in
> > > > PSR2_CTL 'Frames Before SU Entry' hardware stops to generate
> > > > CRC
> > > > interruptions causing IGT tests to fail due timeout.
> > > >
> > > > Oddly that don't happen when PSR1 active, so here it switches
> > > > from
> > > > PSR2 to PSR1 while user is requesting pipe CRC.
> > > >
> > > > Force setting mode_changed as true is necessary to atomic
> > > > checks
> > > > functions compute new PSR state, that is why it was added to
> > > > intel_crtc_crc_prepare().
> > > >
> > > > v3: Reusing intel_crtc_crc_prepare() and crc_enabled
> > > >
> > > > v2: Changed commit description to describe that PSR2 inhibit
> > > > CRC
> > > > calculations.
> > > >
> > > > Cc: Dhinakaran Pandiyan
> > > > Cc: Ville Syrjälä
> > > > Signed-off-by: José Roberto de Souza
> > > > ---
> > > > drivers/gpu/drm/i915/intel_pipe_crc.c | 1 +
> > > > drivers/gpu/drm/i915/intel_psr.c | 3 +++
> > > > 2 files changed, 4 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > index f6d0b2aaffe2..e7ac24c33650 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > @@ -308,6 +308,7 @@ intel_crtc_crc_prepare(struct
> > > > drm_i915_private
> > > > *dev_priv, struct drm_crtc *crtc,
> > > > goto put_state;
> > > > }
> > > >
> > > > + pipe_config->base.mode_changed = pipe_config-
> > > > >crc_enabled !=
> > > > enable;
> > >
> > > Do we really want to set that unconditionally?
> >
> > Without it atomic helpers will return ealier as there is no state
> > changes, I was wondering if the IPS was being applied in the bellow
> > connectors_changed is not set.
> > Anyways to triggers the code paths to disable PSR2 it is needed,
> > and
> > with fastboot enable by default in gen9+ it will do a fastset so
> > not
> > much drawbacks.
> What about pre gen9 platforms that do not have PSR? Running through
> state checks and acquiring several locks on platforms that will never
> need it is wasteful.
>
> Why not make it conditional upon?
> if (HAS_PSR()) or even CAN_PSR() for that matter.
Okay, done.
>
>
>
> > > > pipe_config->crc_enabled = enable;
> > > >
> > > > if (IS_HASWELL(dev_priv) && intel_crtc->pipe == PIPE_A)
> > > > {
> > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > index 6175b1d2e0c8..f7730b8b2ec0 100644
> > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > @@ -572,6 +572,9 @@ static bool intel_psr2_config_valid(struct
> > > > intel_dp *intel_dp,
> > > > return false;
> > > > }
> > > >
> > > > + if (crtc_state->crc_enabled)
> > > > + return false;
> > > > +
> > > > return true;
> > > > }
> > > >
> > > > --
> > > > 2.21.0
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 5/6] drm/i915: Disable PSR2 while getting pipe CRC
On Thu, 2019-02-28 at 15:07 -0800, Souza, Jose wrote:
> On Thu, 2019-02-28 at 18:58 +0200, Ville Syrjälä wrote:
> > On Wed, Feb 27, 2019 at 05:32:58PM -0800, José Roberto de Souza
> > wrote:
> > > When PSR2 is active aka after the number of frames programmed in
> > > PSR2_CTL 'Frames Before SU Entry' hardware stops to generate CRC
> > > interruptions causing IGT tests to fail due timeout.
> > >
> > > Oddly that don't happen when PSR1 active, so here it switches
> > > from
> > > PSR2 to PSR1 while user is requesting pipe CRC.
> > >
> > > Force setting mode_changed as true is necessary to atomic checks
> > > functions compute new PSR state, that is why it was added to
> > > intel_crtc_crc_prepare().
> > >
> > > v3: Reusing intel_crtc_crc_prepare() and crc_enabled
> > >
> > > v2: Changed commit description to describe that PSR2 inhibit CRC
> > > calculations.
> > >
> > > Cc: Dhinakaran Pandiyan
> > > Cc: Ville Syrjälä
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/i915/intel_pipe_crc.c | 1 +
> > > drivers/gpu/drm/i915/intel_psr.c | 3 +++
> > > 2 files changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > index f6d0b2aaffe2..e7ac24c33650 100644
> > > --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > @@ -308,6 +308,7 @@ intel_crtc_crc_prepare(struct
> > > drm_i915_private
> > > *dev_priv, struct drm_crtc *crtc,
> > > goto put_state;
> > > }
> > >
> > > + pipe_config->base.mode_changed = pipe_config->crc_enabled !=
> > > enable;
> >
> > Do we really want to set that unconditionally?
>
> Without it atomic helpers will return ealier as there is no state
> changes, I was wondering if the IPS was being applied in the bellow
> connectors_changed is not set.
> Anyways to triggers the code paths to disable PSR2 it is needed, and
> with fastboot enable by default in gen9+ it will do a fastset so not
> much drawbacks.
What about pre gen9 platforms that do not have PSR? Running through
state checks and acquiring several locks on platforms that will never
need it is wasteful.
Why not make it conditional upon?
if (HAS_PSR()) or even CAN_PSR() for that matter.
>
> >
> > > pipe_config->crc_enabled = enable;
> > >
> > > if (IS_HASWELL(dev_priv) && intel_crtc->pipe == PIPE_A) {
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index 6175b1d2e0c8..f7730b8b2ec0 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -572,6 +572,9 @@ static bool intel_psr2_config_valid(struct
> > > intel_dp *intel_dp,
> > > return false;
> > > }
> > >
> > > + if (crtc_state->crc_enabled)
> > > + return false;
> > > +
> > > return true;
> > > }
> > >
> > > --
> > > 2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/5] drm/i915: Watchdog timeout: IRQ handler for gen8+
On Thu, 2019-02-28 at 17:38 +, Tvrtko Ursulin wrote: > On 21/02/2019 02:58, Carlos Santa wrote: > > From: Michel Thierry > > > > *** General *** > > > > Watchdog timeout (or "media engine reset") is a feature that allows > > userland applications to enable hang detection on individual batch > > buffers. > > The detection mechanism itself is mostly bound to the hardware and > > the only > > thing that the driver needs to do to support this form of hang > > detection > > is to implement the interrupt handling support as well as watchdog > > command > > emission before and after the emitted batch buffer start > > instruction in the > > ring buffer. > > > > The principle of the hang detection mechanism is as follows: > > > > 1. Once the decision has been made to enable watchdog timeout for a > > particular batch buffer and the driver is in the process of > > emitting the > > batch buffer start instruction into the ring buffer it also emits a > > watchdog timer start instruction before and a watchdog timer > > cancellation > > instruction after the batch buffer start instruction in the ring > > buffer. > > > > 2. Once the GPU execution reaches the watchdog timer start > > instruction > > the hardware watchdog counter is started by the hardware. The > > counter > > keeps counting until either reaching a previously configured > > threshold > > value or the timer cancellation instruction is executed. > > > > 2a. If the counter reaches the threshold value the hardware fires a > > watchdog interrupt that is picked up by the watchdog interrupt > > handler. > > This means that a hang has been detected and the driver needs to > > deal with > > it the same way it would deal with a engine hang detected by the > > periodic > > hang checker. The only difference between the two is that we > > already blamed > > the active request (to ensure an engine reset). > > > > 2b. If the batch buffer completes and the execution reaches the > > watchdog > > cancellation instruction before the watchdog counter reaches its > > threshold value the watchdog is cancelled and nothing more comes of > > it. > > No hang is detected. > > > > Note about future interaction with preemption: Preemption could > > happen > > in a command sequence prior to watchdog counter getting disabled, > > resulting in watchdog being triggered following preemption (e.g. > > when > > watchdog had been enabled in the low priority batch). The driver > > will > > need to explicitly disable the watchdog counter as part of the > > preemption sequence. > > > > *** This patch introduces: *** > > > > 1. IRQ handler code for watchdog timeout allowing direct hang > > recovery > > based on hardware-driven hang detection, which then integrates > > directly > > with the hang recovery path. This is independent of having per- > > engine reset > > or just full gpu reset. > > > > 2. Watchdog specific register information. > > > > Currently the render engine and all available media engines support > > watchdog timeout (VECS is only supported in GEN9). The > > specifications elude > > to the BCS engine being supported but that is currently not > > supported by > > this commit. > > > > Note that the value to stop the counter is different between render > > and > > non-render engines in GEN8; GEN9 onwards it's the same. > > > > v2: Move irq handler to tasklet, arm watchdog for a 2nd time to > > check > > against false-positives. > > > > v3: Don't use high priority tasklet, use engine_last_submit while > > checking for false-positives. From GEN9 onwards, the stop counter > > bit is > > the same for all engines. > > > > v4: Remove unnecessary brackets, use current_seqno to mark the > > request > > as guilty in the hangcheck/capture code. > > > > v5: Rebased after RESET_ENGINEs flag. > > > > v6: Don't capture error state in case of watchdog timeout. The > > capture > > process is time consuming and this will align to what happens when > > we > > use GuC to handle the watchdog timeout. (Chris) > > > > v7: Rebase. > > > > v8: Rebase, use HZ to reschedule. > > > > v9: Rebase, get forcewake domains in function (no longer in > > execlists > > struct). > > > > v10: Rebase. > > > > v11: Rebase, > > remove extra braces (Tvrtko), > > implement watchdog_to_clock_counts helper (Tvrtko), > > Move tasklet_kill(watchdog_tasklet) inside intel_engines > > (Tvrtko), > > Use a global heartbeat seqno instead of engine seqno (Chris) > > Make all engines checks all class based checks (Tvrtko) > > > > Cc: Antonio Argenziano > > Cc: Tvrtko Ursulin > > Signed-off-by: Michel Thierry > > Signed-off-by: Carlos Santa > > --- > > drivers/gpu/drm/i915/i915_drv.h | 8 +++ > > drivers/gpu/drm/i915/i915_gpu_error.h | 4 ++ > > drivers/gpu/drm/i915/i915_irq.c | 12 - > > drivers/gpu/drm/i915/i915_reg.h | 6 +++ > > drivers/gpu/drm/i915/intel_engine_cs.c | 1 + > > drivers/gpu/drm/i915/intel_hangcheck.c | 17 +-- >
Re: [Intel-gfx] [PATCH v3 4/6] drm/i915/crc: Make IPS workaround generic
On Thu, 2019-02-28 at 17:06 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2019-02-28 at 15:26 -0800, Souza, Jose wrote:
> > On Thu, 2019-02-28 at 18:56 +0200, Ville Syrjälä wrote:
> > > On Wed, Feb 27, 2019 at 05:32:57PM -0800, José Roberto de Souza
> > > wrote:
> > > > Other features like PSR2 also needs to be disabled while
> > > > getting
> > > > CRC
> > > > so lets rename ips_force_disable to crc_enabled, drop all this
> > > > checks
> > > > for pipe A and HSW and BDW and make it generic and
> > > > hsw_compute_ips_config() will take care of all the checks
> > > > removed
> > > > from here.
> > > >
> > > > Cc: Dhinakaran Pandiyan
> > > > Cc: Ville Syrjälä
> > > > Signed-off-by: José Roberto de Souza
> > > > ---
> > > > drivers/gpu/drm/i915/intel_display.c | 10 +--
> > > > drivers/gpu/drm/i915/intel_drv.h | 3 +-
> > > > drivers/gpu/drm/i915/intel_pipe_crc.c | 42 +
> > > >
> > > > --
> > > > 3 files changed, 24 insertions(+), 31 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index 816e8f124b3b..328967c642b3 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -6751,7 +6751,13 @@ static bool
> > > > hsw_compute_ips_config(struct
> > > > intel_crtc_state *crtc_state)
> > > > if (!hsw_crtc_state_ips_capable(crtc_state))
> > > > return false;
> > > >
> > > > - if (crtc_state->ips_force_disable)
> > > > + /*
> > > > +* When IPS gets enabled, the pipe CRC changes. Since
> > > > IPS gets
> > > > +* enabled and disabled dynamically based on package C
> > > > states,
> > > > +* user space can't make reliable use of the CRCs, so
> > > > let's
> > > > just
> > > > +* completely disable it.
> > > > +*/
> > > > + if (crtc_state->crc_enabled)
> > > > return false;
> > >
> > > Hmm. I was wondering how we even manage to pass the state checker
> > > with
> > > the current code. But apparently we don't have state checking for
> > > IPS.
> > > I would suggest moving this into hsw_compute_ips_config() and
> > > then
> > > adding the state checker (for HSW only though since BDW can't do
> > > the
> > > readout).
> > >
> > > >
> > > > /* IPS should be fine as long as at least one plane is
> > > > enabled.
> > > > */
> > > > @@ -11684,7 +11690,7 @@ clear_intel_crtc_state(struct
> > > > intel_crtc_state *crtc_state)
> > > > saved_state->shared_dpll = crtc_state->shared_dpll;
> > > > saved_state->dpll_hw_state = crtc_state->dpll_hw_state;
> > > > saved_state->pch_pfit.force_thru = crtc_state-
> > > > > pch_pfit.force_thru;
> > > >
> > > > - saved_state->ips_force_disable = crtc_state-
> > > > >ips_force_disable;
> > > > + saved_state->crc_enabled = crtc_state->crc_enabled;
> > > > if (IS_G4X(dev_priv) ||
> > > > IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > > > saved_state->wm = crtc_state->wm;
> > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > index 5412373e2f98..2be64529e4a2 100644
> > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > @@ -999,7 +999,8 @@ struct intel_crtc_state {
> > > > struct intel_link_m_n fdi_m_n;
> > > >
> > > > bool ips_enabled;
> > > > - bool ips_force_disable;
> > > > +
> > > > + bool crc_enabled;
> > > >
> > > > bool enable_fbc;
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > index 53d4ec68d3c4..f6d0b2aaffe2 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > @@ -280,11 +280,12 @@ static int ilk_pipe_crc_ctl_reg(enum
> > > > intel_pipe_crc_source *source,
> > > > return 0;
> > > > }
> > > >
> > > > -static void hsw_pipe_A_crc_wa(struct drm_i915_private
> > > > *dev_priv,
> > > > - bool enable)
> > > > +static void
> > > > +intel_crtc_crc_prepare(struct drm_i915_private *dev_priv,
> > > > struct
> > > > drm_crtc *crtc,
> > >
> > > Just pass in the intel_crtc
> >
> > Okay
> >
> > > > + bool enable)
> > > > {
> > > > struct drm_device *dev = _priv->drm;
> > > > - struct intel_crtc *crtc =
> > > > intel_get_crtc_for_pipe(dev_priv,
> > > > PIPE_A);
> > > > + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > >
> > > and then we don't have to have an ugly name for this.
> > >
> > > Also pasing in dev_priv is redundant when you're already passing
> > > in
> > > the
> > > crtc.
> > >
> >
> > okay
> >
> > > The function name isn't super descriptive. It makes me think
> > > we're
> > > preparing for CRC capture, when in fact it just adds/removes the
>
Re: [Intel-gfx] [PATCH v3 4/6] drm/i915/crc: Make IPS workaround generic
On Thu, 2019-02-28 at 15:26 -0800, Souza, Jose wrote:
> On Thu, 2019-02-28 at 18:56 +0200, Ville Syrjälä wrote:
> > On Wed, Feb 27, 2019 at 05:32:57PM -0800, José Roberto de Souza
> > wrote:
> > > Other features like PSR2 also needs to be disabled while getting
> > > CRC
> > > so lets rename ips_force_disable to crc_enabled, drop all this
> > > checks
> > > for pipe A and HSW and BDW and make it generic and
> > > hsw_compute_ips_config() will take care of all the checks removed
> > > from here.
> > >
> > > Cc: Dhinakaran Pandiyan
> > > Cc: Ville Syrjälä
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/i915/intel_display.c | 10 +--
> > > drivers/gpu/drm/i915/intel_drv.h | 3 +-
> > > drivers/gpu/drm/i915/intel_pipe_crc.c | 42 +
> > > --
> > > 3 files changed, 24 insertions(+), 31 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 816e8f124b3b..328967c642b3 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -6751,7 +6751,13 @@ static bool hsw_compute_ips_config(struct
> > > intel_crtc_state *crtc_state)
> > > if (!hsw_crtc_state_ips_capable(crtc_state))
> > > return false;
> > >
> > > - if (crtc_state->ips_force_disable)
> > > + /*
> > > + * When IPS gets enabled, the pipe CRC changes. Since IPS gets
> > > + * enabled and disabled dynamically based on package C states,
> > > + * user space can't make reliable use of the CRCs, so let's
> > > just
> > > + * completely disable it.
> > > + */
> > > + if (crtc_state->crc_enabled)
> > > return false;
> >
> > Hmm. I was wondering how we even manage to pass the state checker
> > with
> > the current code. But apparently we don't have state checking for
> > IPS.
> > I would suggest moving this into hsw_compute_ips_config() and then
> > adding the state checker (for HSW only though since BDW can't do
> > the
> > readout).
> >
> > >
> > > /* IPS should be fine as long as at least one plane is enabled.
> > > */
> > > @@ -11684,7 +11690,7 @@ clear_intel_crtc_state(struct
> > > intel_crtc_state *crtc_state)
> > > saved_state->shared_dpll = crtc_state->shared_dpll;
> > > saved_state->dpll_hw_state = crtc_state->dpll_hw_state;
> > > saved_state->pch_pfit.force_thru = crtc_state-
> > > > pch_pfit.force_thru;
> > >
> > > - saved_state->ips_force_disable = crtc_state->ips_force_disable;
> > > + saved_state->crc_enabled = crtc_state->crc_enabled;
> > > if (IS_G4X(dev_priv) ||
> > > IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > > saved_state->wm = crtc_state->wm;
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index 5412373e2f98..2be64529e4a2 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -999,7 +999,8 @@ struct intel_crtc_state {
> > > struct intel_link_m_n fdi_m_n;
> > >
> > > bool ips_enabled;
> > > - bool ips_force_disable;
> > > +
> > > + bool crc_enabled;
> > >
> > > bool enable_fbc;
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > index 53d4ec68d3c4..f6d0b2aaffe2 100644
> > > --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > @@ -280,11 +280,12 @@ static int ilk_pipe_crc_ctl_reg(enum
> > > intel_pipe_crc_source *source,
> > > return 0;
> > > }
> > >
> > > -static void hsw_pipe_A_crc_wa(struct drm_i915_private *dev_priv,
> > > - bool enable)
> > > +static void
> > > +intel_crtc_crc_prepare(struct drm_i915_private *dev_priv, struct
> > > drm_crtc *crtc,
> >
> > Just pass in the intel_crtc
>
> Okay
>
> >
> > > +bool enable)
> > > {
> > > struct drm_device *dev = _priv->drm;
> > > - struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv,
> > > PIPE_A);
> > > + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> >
> > and then we don't have to have an ugly name for this.
> >
> > Also pasing in dev_priv is redundant when you're already passing in
> > the
> > crtc.
> >
>
> okay
>
> > The function name isn't super descriptive. It makes me think we're
> > preparing for CRC capture, when in fact it just adds/removes the
> > w/as.
>
> What about: intel_crtc_crc_workarounds_setup()?
>
> >
> > > struct intel_crtc_state *pipe_config;
> > > struct drm_atomic_state *state;
> > > struct drm_modeset_acquire_ctx ctx;
> > > @@ -301,23 +302,15 @@ static void hsw_pipe_A_crc_wa(struct
> > > drm_i915_private *dev_priv,
> > > state->acquire_ctx =
> > >
> > > retry:
> > > - pipe_config = intel_atomic_get_crtc_state(state, crtc);
> > > + pipe_config = intel_atomic_get_crtc_state(state, intel_crtc);
> > > if (IS_ERR(pipe_config)) {
> > > ret = PTR_ERR(pipe_config);
> > > goto put_state;
> >
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Suppress mere WAIT preemption
== Series Details == Series: drm/i915/execlists: Suppress mere WAIT preemption URL : https://patchwork.freedesktop.org/series/57368/ State : success == Summary == CI Bug Log - changes from CI_DRM_5674_full -> Patchwork_12335_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12335_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@modeset-lpsp-stress-no-wait: - shard-skl: PASS -> INCOMPLETE [fdo#107807] +1 * igt@kms_atomic_interruptible@legacy-dpms: - shard-kbl: PASS -> DMESG-WARN [fdo#103313] / [fdo#103558] * igt@kms_busy@basic-flip-d: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +7 * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a: - shard-kbl: PASS -> DMESG-WARN [fdo#107956] * igt@kms_chv_cursor_fail@pipe-a-64x64-bottom-edge: - shard-skl: PASS -> FAIL [fdo#104671] * igt@kms_color@pipe-a-legacy-gamma: - shard-apl: PASS -> FAIL [fdo#104782] / [fdo#108145] * igt@kms_color@pipe-c-ctm-max: - shard-apl: PASS -> FAIL [fdo#108147] * igt@kms_cursor_crc@cursor-64x21-sliding: - shard-apl: PASS -> FAIL [fdo#103232] * igt@kms_draw_crc@draw-method-rgb565-pwrite-xtiled: - shard-skl: PASS -> FAIL [fdo#103184] * igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-untiled: - shard-skl: PASS -> FAIL [fdo#103184] / [fdo#108472] * igt@kms_flip@2x-blocking-absolute-wf_vblank-interruptible: - shard-apl: NOTRUN -> SKIP [fdo#109271] +12 * igt@kms_flip@flip-vs-suspend: - shard-apl: PASS -> DMESG-WARN [fdo#108566] * igt@kms_flip@modeset-vs-vblank-race-interruptible: - shard-kbl: PASS -> FAIL [fdo#103060] * igt@kms_flip_tiling@flip-changes-tiling: - shard-skl: PASS -> FAIL [fdo#108303] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-pwrite: - shard-skl: PASS -> FAIL [fdo#105682] +1 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt: - shard-apl: NOTRUN -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff: - shard-apl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-rte: - shard-skl: PASS -> FAIL [fdo#103167] / [fdo#105682] * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-pwrite: - shard-snb: NOTRUN -> SKIP [fdo#109271] +49 * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc: - shard-glk: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-mmap-cpu: - shard-skl: NOTRUN -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-move: - shard-skl: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-indfb-msflip-blt: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +13 * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-move: - shard-skl: NOTRUN -> SKIP [fdo#109271] +89 * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] * igt@kms_plane_alpha_blend@pipe-a-alpha-basic: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] * igt@kms_plane_multiple@atomic-pipe-a-tiling-x: - shard-glk: PASS -> FAIL [fdo#103166] * igt@kms_plane_multiple@atomic-pipe-c-tiling-y: - shard-apl: PASS -> FAIL [fdo#103166] +1 * igt@kms_rotation_crc@primary-rotation-90: - shard-skl: PASS -> FAIL [fdo#103925] / [fdo#107815] * igt@kms_universal_plane@disable-primary-vs-flip-pipe-f: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +10 Possible fixes * igt@gem_eio@in-flight-suspend: - shard-snb: FAIL [fdo#103375] -> PASS * igt@i915_pm_rpm@universal-planes-dpms: - shard-skl: INCOMPLETE [fdo#107807] -> PASS * igt@kms_chv_cursor_fail@pipe-c-128x128-top-edge: - shard-hsw: DMESG-WARN [fdo#102614] -> PASS +1 * igt@kms_cursor_crc@cursor-128x128-offscreen: - shard-skl: FAIL [fdo#103232] -> PASS - shard-apl: INCOMPLETE [fdo#103927] -> PASS * igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-xtiled: - shard-skl: FAIL [fdo#103184] -> PASS +1 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu: - shard-apl: FAIL [fdo#103167] -> PASS *
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_ctx_isolation: Sanitycheck nonpriv access
On Sat, Feb 23, 2019 at 09:45:10AM +, Chris Wilson wrote:
> Verify that our list of nonpriv registers exist and are writable.
>
> Signed-off-by: Chris Wilson
> Cc: Dale B Stimson
> Cc: Tvrtko Ursulin
> Cc: Joonas Lahtinen
> ---
> tests/i915/gem_ctx_isolation.c | 164 +++--
> 1 file changed, 135 insertions(+), 29 deletions(-)
>
> diff --git a/tests/i915/gem_ctx_isolation.c b/tests/i915/gem_ctx_isolation.c
> index 839d49ad..991a997f 100644
> --- a/tests/i915/gem_ctx_isolation.c
> +++ b/tests/i915/gem_ctx_isolation.c
> @@ -59,16 +59,23 @@ enum {
>
> static const struct named_register {
> const char *name;
> - unsigned int gen_mask;
> - unsigned int engine_mask;
> - uint32_t offset;
> + unsigned int gen_mask; /* on which gen the register exists */
> + unsigned int engine_mask; /* preferred engine / powerwell */
> + uint32_t offset; /* address of register, from bottom of mmio bar */
> uint32_t count;
> uint32_t ignore_bits;
> + uint32_t write_mask; /* some registers bits do not exist */
> bool masked;
> } nonpriv_registers[] = {
> { "NOPID", NOCTX, RCS0, 0x2094 },
> { "MI_PREDICATE_RESULT_2", NOCTX, RCS0, 0x23bc },
> - { "INSTPM", GEN6, RCS0, 0x20c0, 1, BIT(8) /* ro counter */, true },
> + {
> + "INSTPM",
> + GEN6, RCS0, 0x20c0,
> + .ignore_bits = BIT(8) /* ro counter */,
> + .write_mask = BIT(8) /* rsvd varies between gen */,
> + .masked = true,
> + },
> { "IA_VERTICES_COUNT", GEN4, RCS0, 0x2310, 2 },
> { "IA_PRIMITIVES_COUNT", GEN4, RCS0, 0x2318, 2 },
> { "VS_INVOCATION_COUNT", GEN4, RCS0, 0x2320, 2 },
> @@ -78,7 +85,7 @@ static const struct named_register {
> { "GS_PRIMITIVES_COUNT", GEN4, RCS0, 0x2330, 2 },
> { "CL_INVOCATION_COUNT", GEN4, RCS0, 0x2338, 2 },
> { "CL_PRIMITIVES_COUNT", GEN4, RCS0, 0x2340, 2 },
> - { "PS_INVOCATION_COUNT_0", GEN4, RCS0, 0x22c8, 2 },
> + { "PS_INVOCATION_COUNT_0", GEN4, RCS0, 0x22c8, 2, .write_mask = ~0x3 },
I can't find a reason for adding ".write_mask = ~0x3".
Among other places, I've looked in:
https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-kbl-vol02c-commandreference-registers-part2_0.pdf
> { "PS_DEPTH_COUNT_0", GEN4, RCS0, 0x22d8, 2 },
> { "GPUGPU_DISPATCHDIMX", GEN8, RCS0, 0x2500 },
> { "GPUGPU_DISPATCHDIMY", GEN8, RCS0, 0x2504 },
> @@ -86,7 +93,7 @@ static const struct named_register {
> { "MI_PREDICATE_SRC0", GEN8, RCS0, 0x2400, 2 },
> { "MI_PREDICATE_SRC1", GEN8, RCS0, 0x2408, 2 },
> { "MI_PREDICATE_DATA", GEN8, RCS0, 0x2410, 2 },
> - { "MI_PRED_RESULT", GEN8, RCS0, 0x2418 },
> + { "MI_PRED_RESULT", GEN8, RCS0, 0x2418, .write_mask = 0x1 },
> { "3DPRIM_END_OFFSET", GEN6, RCS0, 0x2420 },
> { "3DPRIM_START_VERTEX", GEN6, RCS0, 0x2430 },
> { "3DPRIM_VERTEX_COUNT", GEN6, RCS0, 0x2434 },
> @@ -94,45 +101,45 @@ static const struct named_register {
> { "3DPRIM_START_INSTANCE", GEN6, RCS0, 0x243c },
> { "3DPRIM_BASE_VERTEX", GEN6, RCS0, 0x2440 },
> { "GPGPU_THREADS_DISPATCHED", GEN8, RCS0, 0x2290, 2 },
> - { "PS_INVOCATION_COUNT_1", GEN8, RCS0, 0x22f0, 2 },
> + { "PS_INVOCATION_COUNT_1", GEN8, RCS0, 0x22f0, 2, .write_mask = ~0x3 },
Same comment as for "PS_INVOCATION_COUNT_0" above.
> { "PS_DEPTH_COUNT_1", GEN8, RCS0, 0x22f8, 2 },
> { "BB_OFFSET", GEN8, RCS0, 0x2158, .ignore_bits = 0x4 },
> { "MI_PREDICATE_RESULT_1", GEN8, RCS0, 0x241c },
> { "CS_GPR", GEN8, RCS0, 0x2600, 32 },
> { "OA_CTX_CONTROL", GEN8, RCS0, 0x2360 },
> { "OACTXID", GEN8, RCS0, 0x2364 },
> - { "PS_INVOCATION_COUNT_2", GEN8, RCS0, 0x2448, 2 },
> + { "PS_INVOCATION_COUNT_2", GEN8, RCS0, 0x2448, 2, .write_mask = ~0x3 },
Same comment as for "PS_INVOCATION_COUNT_0" above.
> { "PS_DEPTH_COUNT_2", GEN8, RCS0, 0x2450, 2 },
> - { "Cache_Mode_0", GEN7, RCS0, 0x7000 },
> - { "Cache_Mode_1", GEN7, RCS0, 0x7004 },
> - { "GT_MODE", GEN8, RCS0, 0x7008 },
> - { "L3_Config", GEN7, RCS0, 0x7034 },
> - { "TD_CTL", GEN8, RCS0, 0xe400 },
> + { "Cache_Mode_0", GEN7, RCS0, 0x7000, .masked = true },
> + { "Cache_Mode_1", GEN7, RCS0, 0x7004, .masked = true },
> + { "GT_MODE", GEN8, RCS0, 0x7008, .masked = true },
> + { "L3_Config", GEN8, RCS0, 0x7034 },
> + { "TD_CTL", GEN8, RCS0, 0xe400, .masked = true },
It looks to me like TD_CTL should not be ".masked = true", as docs state
"reserved" and "31:16 MBZ".
> { "TD_CTL2", GEN8, RCS0, 0xe404 },
> - { "SO_NUM_PRIMS_WRITEN0", GEN6, RCS0, 0x5200, 2 },
> - { "SO_NUM_PRIMS_WRITEN1", GEN6, RCS0, 0x5208, 2 },
> - { "SO_NUM_PRIMS_WRITEN2", GEN6, RCS0, 0x5210, 2 },
> - { "SO_NUM_PRIMS_WRITEN3", GEN6, RCS0, 0x5218, 2 },
> + { "SO_NUM_PRIMS_WRITTEN0", GEN6, RCS0, 0x5200, 2 },
> + { "SO_NUM_PRIMS_WRITTEN1", GEN6, RCS0, 0x5208, 2 },
> + {
Re: [Intel-gfx] [CI, v3, 1/2] drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set
On Thu, Feb 28, 2019 at 10:34:20PM +, Chris Wilson wrote: > Quoting Guenter Roeck (2019-02-28 22:27:35) > > On Thu, Feb 28, 2019 at 10:18:32PM +, Chris Wilson wrote: > > > > > > If you have userspace that is broken, we need to fix it. We can get away > > > with quietly changing ABI only so long as nobody notices. It sounds like > > > you have some userspace that will break if you updated the kernel; ergo > > > we have a problem. > > > > > > We just need that as a clear statement so that we have the user impact > > > recorded. > > > > Yes, it does break our userspace code. I fixed the problem in our kernels > > with the following patch: > > > And what userspace is that? Details for the log, please. Internal agreement is that we'll fix our userspace code. Guenter ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 4/6] drm/i915/crc: Make IPS workaround generic
On Thu, 2019-02-28 at 18:56 +0200, Ville Syrjälä wrote:
> On Wed, Feb 27, 2019 at 05:32:57PM -0800, José Roberto de Souza
> wrote:
> > Other features like PSR2 also needs to be disabled while getting
> > CRC
> > so lets rename ips_force_disable to crc_enabled, drop all this
> > checks
> > for pipe A and HSW and BDW and make it generic and
> > hsw_compute_ips_config() will take care of all the checks removed
> > from here.
> >
> > Cc: Dhinakaran Pandiyan
> > Cc: Ville Syrjälä
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 10 +--
> > drivers/gpu/drm/i915/intel_drv.h | 3 +-
> > drivers/gpu/drm/i915/intel_pipe_crc.c | 42 +
> > --
> > 3 files changed, 24 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 816e8f124b3b..328967c642b3 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -6751,7 +6751,13 @@ static bool hsw_compute_ips_config(struct
> > intel_crtc_state *crtc_state)
> > if (!hsw_crtc_state_ips_capable(crtc_state))
> > return false;
> >
> > - if (crtc_state->ips_force_disable)
> > + /*
> > +* When IPS gets enabled, the pipe CRC changes. Since IPS gets
> > +* enabled and disabled dynamically based on package C states,
> > +* user space can't make reliable use of the CRCs, so let's
> > just
> > +* completely disable it.
> > +*/
> > + if (crtc_state->crc_enabled)
> > return false;
>
> Hmm. I was wondering how we even manage to pass the state checker
> with
> the current code. But apparently we don't have state checking for
> IPS.
> I would suggest moving this into hsw_compute_ips_config() and then
> adding the state checker (for HSW only though since BDW can't do the
> readout).
>
> >
> > /* IPS should be fine as long as at least one plane is enabled.
> > */
> > @@ -11684,7 +11690,7 @@ clear_intel_crtc_state(struct
> > intel_crtc_state *crtc_state)
> > saved_state->shared_dpll = crtc_state->shared_dpll;
> > saved_state->dpll_hw_state = crtc_state->dpll_hw_state;
> > saved_state->pch_pfit.force_thru = crtc_state-
> > >pch_pfit.force_thru;
> > - saved_state->ips_force_disable = crtc_state->ips_force_disable;
> > + saved_state->crc_enabled = crtc_state->crc_enabled;
> > if (IS_G4X(dev_priv) ||
> > IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > saved_state->wm = crtc_state->wm;
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 5412373e2f98..2be64529e4a2 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -999,7 +999,8 @@ struct intel_crtc_state {
> > struct intel_link_m_n fdi_m_n;
> >
> > bool ips_enabled;
> > - bool ips_force_disable;
> > +
> > + bool crc_enabled;
> >
> > bool enable_fbc;
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > index 53d4ec68d3c4..f6d0b2aaffe2 100644
> > --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > @@ -280,11 +280,12 @@ static int ilk_pipe_crc_ctl_reg(enum
> > intel_pipe_crc_source *source,
> > return 0;
> > }
> >
> > -static void hsw_pipe_A_crc_wa(struct drm_i915_private *dev_priv,
> > - bool enable)
> > +static void
> > +intel_crtc_crc_prepare(struct drm_i915_private *dev_priv, struct
> > drm_crtc *crtc,
>
> Just pass in the intel_crtc
Okay
>
> > + bool enable)
> > {
> > struct drm_device *dev = _priv->drm;
> > - struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv,
> > PIPE_A);
> > + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>
> and then we don't have to have an ugly name for this.
>
> Also pasing in dev_priv is redundant when you're already passing in
> the
> crtc.
>
okay
> The function name isn't super descriptive. It makes me think we're
> preparing for CRC capture, when in fact it just adds/removes the
> w/as.
What about: intel_crtc_crc_workarounds_setup()?
>
> > struct intel_crtc_state *pipe_config;
> > struct drm_atomic_state *state;
> > struct drm_modeset_acquire_ctx ctx;
> > @@ -301,23 +302,15 @@ static void hsw_pipe_A_crc_wa(struct
> > drm_i915_private *dev_priv,
> > state->acquire_ctx =
> >
> > retry:
> > - pipe_config = intel_atomic_get_crtc_state(state, crtc);
> > + pipe_config = intel_atomic_get_crtc_state(state, intel_crtc);
> > if (IS_ERR(pipe_config)) {
> > ret = PTR_ERR(pipe_config);
> > goto put_state;
> > }
> >
> > - if (HAS_IPS(dev_priv)) {
> > - /*
> > -* When IPS gets enabled, the pipe CRC changes. Since
> > IPS gets
> > -* enabled and disabled dynamically based on package C
> > states,
> > -* user
Re: [Intel-gfx] [PATCH] drm/i915: Yet another if/else sort of newer to older platforms.
On Mon, Feb 25, 2019 at 11:11:30AM -0800, Rodrigo Vivi wrote:
No functional change. Just a reorg to match the preferred
behavior.
When rebasing internal branch on top of latest sort I noticed
few more cases that needs to get reordered.
Let's do in a bundle this time and hoping there's no other
missing places.
v2: Check for HSW/BDW ULT before generic IS_HASWELL or
IS_BROADWELL or it doesn't work as pointed by Ville.
But also ULT came afterwards anyway.
Cc: Ville Syrjälä
Cc: Chris Wilson
Cc: Lucas De Marchi
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.c | 20
drivers/gpu/drm/i915/i915_perf.c | 50 +-
drivers/gpu/drm/i915/intel_cdclk.c | 38 +++---
drivers/gpu/drm/i915/intel_workarounds.c | 64
4 files changed, 86 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c6354f6cdbdb..ed48aac1487d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -219,20 +219,20 @@ intel_virt_detect_pch(const struct drm_i915_private
*dev_priv)
* make an educated guess as to which PCH is really there.
*/
- if (IS_GEN(dev_priv, 5))
- id = INTEL_PCH_IBX_DEVICE_ID_TYPE;
- else if (IS_GEN(dev_priv, 6) || IS_IVYBRIDGE(dev_priv))
- id = INTEL_PCH_CPT_DEVICE_ID_TYPE;
+ if (IS_ICELAKE(dev_priv))
+ id = INTEL_PCH_ICP_DEVICE_ID_TYPE;
+ else if (IS_COFFEELAKE(dev_priv) || IS_CANNONLAKE(dev_priv))
if you want to be strict about the order, then this should be:
else if (IS_CANNONLAKE(dev_priv) || IS_COFFELAKE(dev_priv))
+ id = INTEL_PCH_CNP_DEVICE_ID_TYPE;
+ else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
ditto
+ id = INTEL_PCH_SPT_DEVICE_ID_TYPE;
else if (IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv))
id = INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
id = INTEL_PCH_LPT_DEVICE_ID_TYPE;
- else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
- id = INTEL_PCH_SPT_DEVICE_ID_TYPE;
- else if (IS_COFFEELAKE(dev_priv) || IS_CANNONLAKE(dev_priv))
- id = INTEL_PCH_CNP_DEVICE_ID_TYPE;
- else if (IS_ICELAKE(dev_priv))
- id = INTEL_PCH_ICP_DEVICE_ID_TYPE;
+ else if (IS_GEN(dev_priv, 6) || IS_IVYBRIDGE(dev_priv))
+ id = INTEL_PCH_CPT_DEVICE_ID_TYPE;
+ else if (IS_GEN(dev_priv, 5))
+ id = INTEL_PCH_IBX_DEVICE_ID_TYPE;
if (id)
DRM_DEBUG_KMS("Assuming PCH ID %04x\n", id);
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 9ebf99f3d8d3..72a9a35b40e2 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2881,12 +2881,24 @@ void i915_perf_register(struct drm_i915_private
*dev_priv)
sysfs_attr_init(_priv->perf.oa.test_config.sysfs_metric_id.attr);
- if (IS_HASWELL(dev_priv)) {
- i915_perf_load_test_config_hsw(dev_priv);
- } else if (IS_BROADWELL(dev_priv)) {
- i915_perf_load_test_config_bdw(dev_priv);
- } else if (IS_CHERRYVIEW(dev_priv)) {
- i915_perf_load_test_config_chv(dev_priv);
+ if (IS_ICELAKE(dev_priv)) {
+ i915_perf_load_test_config_icl(dev_priv);
+ } else if (IS_CANNONLAKE(dev_priv)) {
+ i915_perf_load_test_config_cnl(dev_priv);
+ } else if (IS_COFFEELAKE(dev_priv)) {
+ if (IS_CFL_GT2(dev_priv))
+ i915_perf_load_test_config_cflgt2(dev_priv);
+ if (IS_CFL_GT3(dev_priv))
+ i915_perf_load_test_config_cflgt3(dev_priv);
+ } else if (IS_GEMINILAKE(dev_priv)) {
+ i915_perf_load_test_config_glk(dev_priv);
+ } else if (IS_KABYLAKE(dev_priv)) {
+ if (IS_KBL_GT2(dev_priv))
+ i915_perf_load_test_config_kblgt2(dev_priv);
+ else if (IS_KBL_GT3(dev_priv))
+ i915_perf_load_test_config_kblgt3(dev_priv);
+ } else if (IS_BROXTON(dev_priv)) {
+ i915_perf_load_test_config_bxt(dev_priv);
} else if (IS_SKYLAKE(dev_priv)) {
if (IS_SKL_GT2(dev_priv))
i915_perf_load_test_config_sklgt2(dev_priv);
@@ -2894,25 +2906,13 @@ void i915_perf_register(struct drm_i915_private
*dev_priv)
i915_perf_load_test_config_sklgt3(dev_priv);
else if (IS_SKL_GT4(dev_priv))
i915_perf_load_test_config_sklgt4(dev_priv);
- } else if (IS_BROXTON(dev_priv)) {
- i915_perf_load_test_config_bxt(dev_priv);
- } else if (IS_KABYLAKE(dev_priv)) {
- if (IS_KBL_GT2(dev_priv))
-
Re: [Intel-gfx] [PATCH v3 5/6] drm/i915: Disable PSR2 while getting pipe CRC
On Thu, 2019-02-28 at 18:58 +0200, Ville Syrjälä wrote:
> On Wed, Feb 27, 2019 at 05:32:58PM -0800, José Roberto de Souza
> wrote:
> > When PSR2 is active aka after the number of frames programmed in
> > PSR2_CTL 'Frames Before SU Entry' hardware stops to generate CRC
> > interruptions causing IGT tests to fail due timeout.
> >
> > Oddly that don't happen when PSR1 active, so here it switches from
> > PSR2 to PSR1 while user is requesting pipe CRC.
> >
> > Force setting mode_changed as true is necessary to atomic checks
> > functions compute new PSR state, that is why it was added to
> > intel_crtc_crc_prepare().
> >
> > v3: Reusing intel_crtc_crc_prepare() and crc_enabled
> >
> > v2: Changed commit description to describe that PSR2 inhibit CRC
> > calculations.
> >
> > Cc: Dhinakaran Pandiyan
> > Cc: Ville Syrjälä
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/intel_pipe_crc.c | 1 +
> > drivers/gpu/drm/i915/intel_psr.c | 3 +++
> > 2 files changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > index f6d0b2aaffe2..e7ac24c33650 100644
> > --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > @@ -308,6 +308,7 @@ intel_crtc_crc_prepare(struct drm_i915_private
> > *dev_priv, struct drm_crtc *crtc,
> > goto put_state;
> > }
> >
> > + pipe_config->base.mode_changed = pipe_config->crc_enabled !=
> > enable;
>
> Do we really want to set that unconditionally?
Without it atomic helpers will return ealier as there is no state
changes, I was wondering if the IPS was being applied in the bellow
connectors_changed is not set.
Anyways to triggers the code paths to disable PSR2 it is needed, and
with fastboot enable by default in gen9+ it will do a fastset so not
much drawbacks.
>
> > pipe_config->crc_enabled = enable;
> >
> > if (IS_HASWELL(dev_priv) && intel_crtc->pipe == PIPE_A) {
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 6175b1d2e0c8..f7730b8b2ec0 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -572,6 +572,9 @@ static bool intel_psr2_config_valid(struct
> > intel_dp *intel_dp,
> > return false;
> > }
> >
> > + if (crtc_state->crc_enabled)
> > + return false;
> > +
> > return true;
> > }
> >
> > --
> > 2.21.0
signature.asc
Description: This is a digitally signed message part
___
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/execlists: Suppress mere WAIT preemption
== Series Details ==
Series: drm/i915/execlists: Suppress mere WAIT preemption
URL : https://patchwork.freedesktop.org/series/57368/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5674 -> Patchwork_12335
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/57368/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12335:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_pread@basic:
- {fi-icl-y}: NOTRUN -> INCOMPLETE
Known issues
Here are the changes found in Patchwork_12335 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@kms_chamelium@hdmi-edid-read:
- fi-hsw-peppy: NOTRUN -> SKIP [fdo#109271] +46
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: NOTRUN -> DMESG-FAIL [fdo#102614] / [fdo#107814]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: DMESG-WARN [fdo#108965] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107814]: https://bugs.freedesktop.org/show_bug.cgi?id=107814
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109673]: https://bugs.freedesktop.org/show_bug.cgi?id=109673
[fdo#109779]: https://bugs.freedesktop.org/show_bug.cgi?id=109779
Participating hosts (44 -> 41)
--
Additional (2): fi-icl-y fi-hsw-peppy
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600
Build changes
-
* Linux: CI_DRM_5674 -> Patchwork_12335
CI_DRM_5674: 71bb3bfb61fb58f93f8b09e6ad576a403cd7752c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4863: 0f0db14e7f4ec41251ca156d7cb5b8d531a38006 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12335: f2d30c16483fb7926c113787d6163d8fcf9a47a6 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
f2d30c16483f drm/i915/execlists: Suppress mere WAIT preemption
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12335/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/icl: Default to Thread Group preemption for compute workloads
Quoting Rodrigo Vivi (2019-02-28 22:32:35) > On Thu, Feb 28, 2019 at 11:02:54AM -0800, Rodrigo Vivi wrote: > (What I' wondering now is that how this behaviour can change with GuC... > I heard some media folks were using i915 directly and facing some > strange gpu hangs but no gpu hang when using guc submission...) Which probably means no preemption is occurring... -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/6] drm/i915/psr: Only lookup for enabled CRTCs when forcing a fastset
On Thu, 2019-02-28 at 18:39 +0200, Ville Syrjälä wrote:
> On Wed, Feb 27, 2019 at 05:32:55PM -0800, José Roberto de Souza
> wrote:
> > Forcing a specific CRTC to the eDP connector was causing the
> > intel_psr_fastset_force() to mark mode_chaged in the wrong and
> > disabled CRTC causing no update in the PSR state.
> >
> > Looks like our internal state track do not clear output_types and
> > has_psr in the disabled CRTCs, not sure if this is the expected
> > behavior or not but in the mean time this fix the issue.
> >
> > Cc: Maarten Lankhorst
> > Cc: Dhinakaran Pandiyan
> > Reviewed-by: Dhinakaran Pandiyan
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/intel_psr.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 8bed73914876..6175b1d2e0c8 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -981,7 +981,8 @@ static int intel_psr_fastset_force(struct
> > drm_i915_private *dev_priv)
> >
> > intel_crtc_state = to_intel_crtc_state(crtc_state);
> >
> > - if (intel_crtc_has_type(intel_crtc_state,
> > INTEL_OUTPUT_EDP) &&
> > + if (crtc_state->active &&
> > + intel_crtc_has_type(intel_crtc_state,
> > INTEL_OUTPUT_EDP) &&
>
> What's the point of that eDP check anyway?
I gonna drop it in another patch.
>
> > intel_crtc_state->has_psr) {
> > /* Mark mode as changed to trigger a pipe-
> > >update() */
> > crtc_state->mode_changed = true;
> > --
> > 2.21.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI, v3, 1/2] drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set
Quoting Guenter Roeck (2019-02-28 22:27:35) > On Thu, Feb 28, 2019 at 10:18:32PM +, Chris Wilson wrote: > > > > If you have userspace that is broken, we need to fix it. We can get away > > with quietly changing ABI only so long as nobody notices. It sounds like > > you have some userspace that will break if you updated the kernel; ergo > > we have a problem. > > > > We just need that as a clear statement so that we have the user impact > > recorded. > > Yes, it does break our userspace code. I fixed the problem in our kernels > with the following patch: > And what userspace is that? Details for the log, please. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/icl: Default to Thread Group preemption for compute workloads
On Thu, Feb 28, 2019 at 11:02:54AM -0800, Rodrigo Vivi wrote:
> On Wed, Feb 27, 2019 at 04:51:08PM +0100, Michał Winiarski wrote:
> > We assumed that the default preemption granularity is fine for ICL.
> > Unfortunately, it turns out that some drivers don't support mid-thread
> > preemption for compute workloads.
> > If a workload that doesn't support mid-thread preemption gets mid-thread
> > preempted, we're going to observe a GPU hang.
> > While I'm here, let's also update the "workaround" naming.
> >
> > Signed-off-by: Michał Winiarski
> > Cc: Anuj Phogat
> > Cc: Joonas Lahtinen
> > Cc: Matt Roper
> > Cc: Rafael Antognolli
> > ---
> > drivers/gpu/drm/i915/intel_workarounds.c | 9 +++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> > b/drivers/gpu/drm/i915/intel_workarounds.c
> > index 743cf5b00155..a19e1c0052a7 100644
> > --- a/drivers/gpu/drm/i915/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> > @@ -555,6 +555,11 @@ static void icl_ctx_workarounds_init(struct
> > intel_engine_cs *engine)
> >GEN10_CACHE_MODE_SS,
> >0, /* write-only, so skip validation */
> >_MASKED_BIT_ENABLE(FLOAT_BLEND_OPTIMIZATION_ENABLE));
> > +
> > + /* WaDisableGPGPUMidThreadPreemption:icl */
>
> Could you please give me some internal pointers to this WA?
> I couldn't find it on bspec nor on wadb.
>
> > + WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1,
> > + GEN9_PREEMPT_GPGPU_LEVEL_MASK,
> > + GEN9_PREEMPT_GPGPU_THREAD_GROUP_LEVEL);
> > }
> >
> > void intel_engine_init_ctx_wa(struct intel_engine_cs *engine)
> > @@ -1170,8 +1175,8 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> > struct i915_wa_list *wal)
> > GEN7_DISABLE_SAMPLER_PREFETCH);
> > }
> >
> > - if (IS_GEN(i915, 9) || IS_CANNONLAKE(i915)) {
> > - /*
> > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,cnl */
>
> Please don't remove the old name that is still part of old
> references. If we have a new name for ICL+ please keep both
> here on the comments.
I'm sorry for my delayed response on irc, I hope you that answer
came in time to avoid your rework.
I just noticed that this name for gen9/10 platforsm is already inside
gen9_whitelist_build() and that on next patch you re-introduce the icl
one...
Also thanks for all the explanations. I checked bits with spec
and everything makes sense now, so:
Reviewed-by: Rodrigo Vivi
(What I' wondering now is that how this behaviour can change with GuC...
I heard some media folks were using i915 directly and facing some
strange gpu hangs but no gpu hang when using guc submission...)
>
>
> > + if (IS_GEN_RANGE(i915, 9, 11)) {
> > + /*
> > FtrPerCtxtPreemptionGranularityControl:skl,bxt,kbl,cfl,cnl,icl */
>
> also please give me a pointer to this...
>
> Thanks,
> Rodrigo.
>
> > wa_masked_en(wal,
> > GEN7_FF_SLICE_CS_CHICKEN1,
> > GEN9_FFSC_PERCTX_PREEMPT_CTRL);
> > --
> > 2.20.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI, v3, 1/2] drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set
On Thu, Feb 28, 2019 at 10:18:32PM +, Chris Wilson wrote: > > If you have userspace that is broken, we need to fix it. We can get away > with quietly changing ABI only so long as nobody notices. It sounds like > you have some userspace that will break if you updated the kernel; ergo > we have a problem. > > We just need that as a clear statement so that we have the user impact > recorded. Yes, it does break our userspace code. I fixed the problem in our kernels with the following patch: - return vma->vm_start == addr && (vma->vm_end - vma->vm_start) == size; + return vma->vm_start == addr && (vma->vm_end - vma->vm_start) == roundup(size, PAGE_SIZE); Guenter ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI, v3, 1/2] drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set
Quoting Guenter Roeck (2019-02-28 22:11:51)
> On Thu, Feb 28, 2019 at 10:01:45PM +, Chris Wilson wrote:
> > Quoting Guenter Roeck (2019-02-28 21:57:03)
> > > On Thu, Feb 28, 2019 at 01:32:41PM -0800, Guenter Roeck wrote:
> > > > On Thu, Feb 28, 2019 at 11:12:49AM -0800, Guenter Roeck wrote:
> > > > > Hi,
> > > > >
> > > > > On Thu, Feb 07, 2019 at 10:54:53AM +0200, Joonas Lahtinen wrote:
> > > > > > Make sure the underlying VMA in the process address space is the
> > > > > > same as it was during vm_mmap to avoid applying WC to wrong VMA.
> > > > > >
> > > > > > A more long-term solution would be to have vm_mmap_locked variant
> > > > > > in linux/mmap.h for when caller wants to hold mmap_sem for an
> > > > > > extended duration.
> > > > > >
> > > > >
> > > > > It seems like we may have a regression due to this patch. I am still
> > > > > debugging, but I have a question; please see below.
> > > > >
> > > > > Thanks,
> > > > > Guenter
> > > > >
> > > > > > v2:
> > > > > > - Refactor the compare function
> > > > > >
> > > > > > Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user
> > > > > > mappings for objects")
> > > > > > Reported-by: Adam Zabrocki
> > > > > > Suggested-by: Linus Torvalds
> > > > > > Signed-off-by: Joonas Lahtinen
> > > > > > Cc: # v4.0+
> > > > > > Cc: Akash Goel
> > > > > > Cc: Chris Wilson
> > > > > > Cc: Tvrtko Ursulin
> > > > > > Cc: Adam Zabrocki
> > > > > > Reviewed-by: Chris Wilson
> > > > > > Reviewed-by: Tvrtko Ursulin #v1
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/i915_gem.c | 12 +++-
> > > > > > 1 file changed, 11 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > > > > > b/drivers/gpu/drm/i915/i915_gem.c
> > > > > > index 05ce9176ac4e..52639f749908 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > > > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > > > > @@ -1681,6 +1681,16 @@ i915_gem_sw_finish_ioctl(struct drm_device
> > > > > > *dev, void *data,
> > > > > > return 0;
> > > > > > }
> > > > > >
> > > > > > +static inline bool
> > > > > > +__vma_matches(struct vm_area_struct *vma, struct file *filp,
> > > > > > + unsigned long addr, unsigned long size)
> > > > > > +{
> > > > > > + if (vma->vm_file != filp)
> > > > > > + return false;
> > > > > > +
> > > > > > + return vma->vm_start == addr && (vma->vm_end - vma->vm_start) ==
> > > > > > size;
> > > > >
> > > > > Shouldn't this be:
> > > > > return vma->vm_start == addr && (vma->vm_end - vma->vm_start + 1)
> > > > > == size;
> > > > > instead ?
> > > > >
> > > >
> > > > Answer is no .. because vm_end points to the first byte after the
> > > > end address.
> > > >
> > > > The actual values are:
> > > >
> > > > start=7d288f7f9000 end=7d288f84d000 end-start=54000 size=53400
> > > >
> > > > meaning the size field passed in the ioctl is smaller than the total
> > > > length
> > > > of the area.
> > > >
> > > > Question is now: Is the request/ioctl indeed invalid, ie does the
> > > > requested
> > > > size have to match the vma size ? This used to work until this patch was
> > > > applied, and the change causes our test code to fail (and possibly
> > > > minigbm,
> > > > which is used by the test code). That doesn't mean that our code is
> > > > correct
> > > > (I see some related local changes in our version of minigbm), but it is
> > > > annoying, and I am being asked to revert this patch as regression
> > > > from our kernel releases.
> > > >
> > >
> > > In i915_gem_create():
> > >
> > > size = roundup(size, PAGE_SIZE);
> > > if (size == 0)
> > > return -EINVAL;
> > >
> > > This suggests to me that the requested size can be smaller than the
> >
> > Not really, the ABI has never handled less than page-sized requests.
> > It's a mistake from the very beginning that it was not rejected as being
> > the invalid size it was.
> >
> > > allocated size, which in turn suggests that the check
> > > (vma->vm_end - vma->vm_start) == size;
> > > is wrong. Either it should be
> > > (vma->vm_end - vma->vm_start) >= size;
> > > or possibly
> > > (vma->vm_end - vma->vm_start) == roundup(size, PAGE_SIZE);
> > >
> > > Any comments/feedback/thoughts ?
> >
> > It's a violation of mmap(2).
> >
> > Is probably what we will have to do if you ring the regression bell loud
> > enough, and do not see the folly of your ways. :-p
>
> I won't ring any bells; I don't play such games. I'll make a local change
> in our kernel to fix the problem, quoting your statement that less than
> page-sized requests were never supposed to be supported, and add a note
> that we'll have to handle this with a local patch going forward.
If you have userspace that is broken, we need to fix it. We can get away
with quietly changing ABI only so long as nobody notices. It sounds like
you have some userspace that will break if you updated the kernel; ergo
we have
Re: [Intel-gfx] [CI, v3, 1/2] drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set
On Thu, Feb 28, 2019 at 10:01:45PM +, Chris Wilson wrote:
> Quoting Guenter Roeck (2019-02-28 21:57:03)
> > On Thu, Feb 28, 2019 at 01:32:41PM -0800, Guenter Roeck wrote:
> > > On Thu, Feb 28, 2019 at 11:12:49AM -0800, Guenter Roeck wrote:
> > > > Hi,
> > > >
> > > > On Thu, Feb 07, 2019 at 10:54:53AM +0200, Joonas Lahtinen wrote:
> > > > > Make sure the underlying VMA in the process address space is the
> > > > > same as it was during vm_mmap to avoid applying WC to wrong VMA.
> > > > >
> > > > > A more long-term solution would be to have vm_mmap_locked variant
> > > > > in linux/mmap.h for when caller wants to hold mmap_sem for an
> > > > > extended duration.
> > > > >
> > > >
> > > > It seems like we may have a regression due to this patch. I am still
> > > > debugging, but I have a question; please see below.
> > > >
> > > > Thanks,
> > > > Guenter
> > > >
> > > > > v2:
> > > > > - Refactor the compare function
> > > > >
> > > > > Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user
> > > > > mappings for objects")
> > > > > Reported-by: Adam Zabrocki
> > > > > Suggested-by: Linus Torvalds
> > > > > Signed-off-by: Joonas Lahtinen
> > > > > Cc: # v4.0+
> > > > > Cc: Akash Goel
> > > > > Cc: Chris Wilson
> > > > > Cc: Tvrtko Ursulin
> > > > > Cc: Adam Zabrocki
> > > > > Reviewed-by: Chris Wilson
> > > > > Reviewed-by: Tvrtko Ursulin #v1
> > > > > ---
> > > > > drivers/gpu/drm/i915/i915_gem.c | 12 +++-
> > > > > 1 file changed, 11 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > > > > b/drivers/gpu/drm/i915/i915_gem.c
> > > > > index 05ce9176ac4e..52639f749908 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > > > @@ -1681,6 +1681,16 @@ i915_gem_sw_finish_ioctl(struct drm_device
> > > > > *dev, void *data,
> > > > > return 0;
> > > > > }
> > > > >
> > > > > +static inline bool
> > > > > +__vma_matches(struct vm_area_struct *vma, struct file *filp,
> > > > > + unsigned long addr, unsigned long size)
> > > > > +{
> > > > > + if (vma->vm_file != filp)
> > > > > + return false;
> > > > > +
> > > > > + return vma->vm_start == addr && (vma->vm_end - vma->vm_start) ==
> > > > > size;
> > > >
> > > > Shouldn't this be:
> > > > return vma->vm_start == addr && (vma->vm_end - vma->vm_start + 1)
> > > > == size;
> > > > instead ?
> > > >
> > >
> > > Answer is no .. because vm_end points to the first byte after the
> > > end address.
> > >
> > > The actual values are:
> > >
> > > start=7d288f7f9000 end=7d288f84d000 end-start=54000 size=53400
> > >
> > > meaning the size field passed in the ioctl is smaller than the total
> > > length
> > > of the area.
> > >
> > > Question is now: Is the request/ioctl indeed invalid, ie does the
> > > requested
> > > size have to match the vma size ? This used to work until this patch was
> > > applied, and the change causes our test code to fail (and possibly
> > > minigbm,
> > > which is used by the test code). That doesn't mean that our code is
> > > correct
> > > (I see some related local changes in our version of minigbm), but it is
> > > annoying, and I am being asked to revert this patch as regression
> > > from our kernel releases.
> > >
> >
> > In i915_gem_create():
> >
> > size = roundup(size, PAGE_SIZE);
> > if (size == 0)
> > return -EINVAL;
> >
> > This suggests to me that the requested size can be smaller than the
>
> Not really, the ABI has never handled less than page-sized requests.
> It's a mistake from the very beginning that it was not rejected as being
> the invalid size it was.
>
> > allocated size, which in turn suggests that the check
> > (vma->vm_end - vma->vm_start) == size;
> > is wrong. Either it should be
> > (vma->vm_end - vma->vm_start) >= size;
> > or possibly
> > (vma->vm_end - vma->vm_start) == roundup(size, PAGE_SIZE);
> >
> > Any comments/feedback/thoughts ?
>
> It's a violation of mmap(2).
>
> Is probably what we will have to do if you ring the regression bell loud
> enough, and do not see the folly of your ways. :-p
I won't ring any bells; I don't play such games. I'll make a local change
in our kernel to fix the problem, quoting your statement that less than
page-sized requests were never supposed to be supported, and add a note
that we'll have to handle this with a local patch going forward.
Guenter
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915/execlists: Suppress mere WAIT preemption
WAIT is occasionally suppressed by virtue of preempted requests being
promoted to NEWCLIENT if they have not all ready received that boost.
Make this consistent for all WAIT boosts that they are not allowed to
preempt executing contexts and are merely granted the right to be at the
front of the queue for the next execution slot. This is in keeping with
the desire that the WAIT boost be a minor tweak that does not give
excessive promotion to its user and open ourselves to trivial abuse.
The problem with the inconsistent WAIT preemption becomes more apparent
as the preemption is propagated across the engines, where one engine may
preempt and the other not, and we be relying on the exact execution
order being consistent across engines (e.g. using HW semaphores to
coordinate parallel execution).
v2: Also protect GuC submission from false preemption loops.
v3: Build bug safeguards and better debug messages for st.
v4: Do the priority bumping in unsubmit (i.e. on preemption/reset
unwind), applying it earlier during submit causes out-of-order execution
combined with execute fences.
v5: Call sw_fence_fini for our dummy request (Matthew)
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_request.c | 15 ++
drivers/gpu/drm/i915/i915_scheduler.c | 1 -
drivers/gpu/drm/i915/i915_scheduler.h | 2 +
drivers/gpu/drm/i915/intel_guc_submission.c | 2 +-
drivers/gpu/drm/i915/intel_lrc.c| 9 +-
drivers/gpu/drm/i915/selftests/intel_lrc.c | 163
6 files changed, 189 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index a011bf4be48e..c65f6c990fdd 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -358,11 +358,14 @@ void __i915_request_submit(struct i915_request *request)
/* We may be recursing from the signal callback of another i915 fence */
spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
+
GEM_BUG_ON(test_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags));
set_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags);
+
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags) &&
!i915_request_enable_breadcrumb(request))
intel_engine_queue_breadcrumbs(engine);
+
spin_unlock(>lock);
engine->emit_fini_breadcrumb(request,
@@ -406,10 +409,22 @@ void __i915_request_unsubmit(struct i915_request *request)
/* We may be recursing from the signal callback of another i915 fence */
spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
+
+ /*
+* As we do not allow WAIT to preempt inflight requests,
+* once we have executed a request, along with triggering
+* any execution callbacks, we must preserve its ordering
+* within the non-preemptible FIFO.
+*/
+ BUILD_BUG_ON(__NO_PREEMPTION & ~I915_PRIORITY_MASK); /* only internal */
+ request->sched.attr.priority |= __NO_PREEMPTION;
+
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
i915_request_cancel_breadcrumb(request);
+
GEM_BUG_ON(!test_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags));
clear_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags);
+
spin_unlock(>lock);
/* Transfer back from the global per-engine timeline to per-context */
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 0dd720593f9c..50018ad30233 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -324,7 +324,6 @@ static void __i915_schedule(struct i915_request *rq,
if (node_signaled(p->signaler))
continue;
- GEM_BUG_ON(p->signaler->attr.priority <
node->attr.priority);
if (prio > READ_ONCE(p->signaler->attr.priority))
list_move_tail(>dfs_link, );
}
diff --git a/drivers/gpu/drm/i915/i915_scheduler.h
b/drivers/gpu/drm/i915/i915_scheduler.h
index bb3d496d4c49..7d4a49750d92 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.h
+++ b/drivers/gpu/drm/i915/i915_scheduler.h
@@ -33,6 +33,8 @@ enum {
#define I915_PRIORITY_WAIT ((u8)BIT(0))
#define I915_PRIORITY_NEWCLIENT((u8)BIT(1))
+#define __NO_PREEMPTION (I915_PRIORITY_WAIT)
+
struct i915_sched_attr {
/**
* @priority: execution and service priority
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 4366db7978a8..56ba2fcbabe6 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -720,7 +720,7 @@ static inline int rq_prio(const struct i915_request *rq)
static inline int port_prio(const struct execlist_port *port)
{
- return
Re: [Intel-gfx] [CI, v3, 1/2] drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set
Quoting Guenter Roeck (2019-02-28 21:57:03)
> On Thu, Feb 28, 2019 at 01:32:41PM -0800, Guenter Roeck wrote:
> > On Thu, Feb 28, 2019 at 11:12:49AM -0800, Guenter Roeck wrote:
> > > Hi,
> > >
> > > On Thu, Feb 07, 2019 at 10:54:53AM +0200, Joonas Lahtinen wrote:
> > > > Make sure the underlying VMA in the process address space is the
> > > > same as it was during vm_mmap to avoid applying WC to wrong VMA.
> > > >
> > > > A more long-term solution would be to have vm_mmap_locked variant
> > > > in linux/mmap.h for when caller wants to hold mmap_sem for an
> > > > extended duration.
> > > >
> > >
> > > It seems like we may have a regression due to this patch. I am still
> > > debugging, but I have a question; please see below.
> > >
> > > Thanks,
> > > Guenter
> > >
> > > > v2:
> > > > - Refactor the compare function
> > > >
> > > > Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user
> > > > mappings for objects")
> > > > Reported-by: Adam Zabrocki
> > > > Suggested-by: Linus Torvalds
> > > > Signed-off-by: Joonas Lahtinen
> > > > Cc: # v4.0+
> > > > Cc: Akash Goel
> > > > Cc: Chris Wilson
> > > > Cc: Tvrtko Ursulin
> > > > Cc: Adam Zabrocki
> > > > Reviewed-by: Chris Wilson
> > > > Reviewed-by: Tvrtko Ursulin #v1
> > > > ---
> > > > drivers/gpu/drm/i915/i915_gem.c | 12 +++-
> > > > 1 file changed, 11 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > > > b/drivers/gpu/drm/i915/i915_gem.c
> > > > index 05ce9176ac4e..52639f749908 100644
> > > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > > @@ -1681,6 +1681,16 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev,
> > > > void *data,
> > > > return 0;
> > > > }
> > > >
> > > > +static inline bool
> > > > +__vma_matches(struct vm_area_struct *vma, struct file *filp,
> > > > + unsigned long addr, unsigned long size)
> > > > +{
> > > > + if (vma->vm_file != filp)
> > > > + return false;
> > > > +
> > > > + return vma->vm_start == addr && (vma->vm_end - vma->vm_start) == size;
> > >
> > > Shouldn't this be:
> > > return vma->vm_start == addr && (vma->vm_end - vma->vm_start + 1) ==
> > > size;
> > > instead ?
> > >
> >
> > Answer is no .. because vm_end points to the first byte after the
> > end address.
> >
> > The actual values are:
> >
> > start=7d288f7f9000 end=7d288f84d000 end-start=54000 size=53400
> >
> > meaning the size field passed in the ioctl is smaller than the total length
> > of the area.
> >
> > Question is now: Is the request/ioctl indeed invalid, ie does the requested
> > size have to match the vma size ? This used to work until this patch was
> > applied, and the change causes our test code to fail (and possibly minigbm,
> > which is used by the test code). That doesn't mean that our code is correct
> > (I see some related local changes in our version of minigbm), but it is
> > annoying, and I am being asked to revert this patch as regression
> > from our kernel releases.
> >
>
> In i915_gem_create():
>
> size = roundup(size, PAGE_SIZE);
> if (size == 0)
> return -EINVAL;
>
> This suggests to me that the requested size can be smaller than the
Not really, the ABI has never handled less than page-sized requests.
It's a mistake from the very beginning that it was not rejected as being
the invalid size it was.
> allocated size, which in turn suggests that the check
> (vma->vm_end - vma->vm_start) == size;
> is wrong. Either it should be
> (vma->vm_end - vma->vm_start) >= size;
> or possibly
> (vma->vm_end - vma->vm_start) == roundup(size, PAGE_SIZE);
>
> Any comments/feedback/thoughts ?
It's a violation of mmap(2).
Is probably what we will have to do if you ring the regression bell loud
enough, and do not see the folly of your ways. :-p
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI, v3, 1/2] drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set
On Thu, Feb 28, 2019 at 01:32:41PM -0800, Guenter Roeck wrote:
> On Thu, Feb 28, 2019 at 11:12:49AM -0800, Guenter Roeck wrote:
> > Hi,
> >
> > On Thu, Feb 07, 2019 at 10:54:53AM +0200, Joonas Lahtinen wrote:
> > > Make sure the underlying VMA in the process address space is the
> > > same as it was during vm_mmap to avoid applying WC to wrong VMA.
> > >
> > > A more long-term solution would be to have vm_mmap_locked variant
> > > in linux/mmap.h for when caller wants to hold mmap_sem for an
> > > extended duration.
> > >
> >
> > It seems like we may have a regression due to this patch. I am still
> > debugging, but I have a question; please see below.
> >
> > Thanks,
> > Guenter
> >
> > > v2:
> > > - Refactor the compare function
> > >
> > > Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user
> > > mappings for objects")
> > > Reported-by: Adam Zabrocki
> > > Suggested-by: Linus Torvalds
> > > Signed-off-by: Joonas Lahtinen
> > > Cc: # v4.0+
> > > Cc: Akash Goel
> > > Cc: Chris Wilson
> > > Cc: Tvrtko Ursulin
> > > Cc: Adam Zabrocki
> > > Reviewed-by: Chris Wilson
> > > Reviewed-by: Tvrtko Ursulin #v1
> > > ---
> > > drivers/gpu/drm/i915/i915_gem.c | 12 +++-
> > > 1 file changed, 11 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > > b/drivers/gpu/drm/i915/i915_gem.c
> > > index 05ce9176ac4e..52639f749908 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -1681,6 +1681,16 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev,
> > > void *data,
> > > return 0;
> > > }
> > >
> > > +static inline bool
> > > +__vma_matches(struct vm_area_struct *vma, struct file *filp,
> > > + unsigned long addr, unsigned long size)
> > > +{
> > > + if (vma->vm_file != filp)
> > > + return false;
> > > +
> > > + return vma->vm_start == addr && (vma->vm_end - vma->vm_start) == size;
> >
> > Shouldn't this be:
> > return vma->vm_start == addr && (vma->vm_end - vma->vm_start + 1) ==
> > size;
> > instead ?
> >
>
> Answer is no .. because vm_end points to the first byte after the
> end address.
>
> The actual values are:
>
> start=7d288f7f9000 end=7d288f84d000 end-start=54000 size=53400
>
> meaning the size field passed in the ioctl is smaller than the total length
> of the area.
>
> Question is now: Is the request/ioctl indeed invalid, ie does the requested
> size have to match the vma size ? This used to work until this patch was
> applied, and the change causes our test code to fail (and possibly minigbm,
> which is used by the test code). That doesn't mean that our code is correct
> (I see some related local changes in our version of minigbm), but it is
> annoying, and I am being asked to revert this patch as regression
> from our kernel releases.
>
In i915_gem_create():
size = roundup(size, PAGE_SIZE);
if (size == 0)
return -EINVAL;
This suggests to me that the requested size can be smaller than the
allocated size, which in turn suggests that the check
(vma->vm_end - vma->vm_start) == size;
is wrong. Either it should be
(vma->vm_end - vma->vm_start) >= size;
or possibly
(vma->vm_end - vma->vm_start) == roundup(size, PAGE_SIZE);
Any comments/feedback/thoughts ?
Thanks,
Guenter
> Thanks,
> Guenter
>
> > > +}
> > > +
> > > /**
> > > * i915_gem_mmap_ioctl - Maps the contents of an object, returning the
> > > address
> > > *it is mapped to.
> > > @@ -1739,7 +1749,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void
> > > *data,
> > > return -EINTR;
> > > }
> > > vma = find_vma(mm, addr);
> > > - if (vma)
> > > + if (vma && __vma_matches(vma, obj->base.filp, addr, args->size))
> > > vma->vm_page_prot =
> > >
> > > pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
> > > else
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Finalize Wa_1408961008:icl
Tested-by: Clint Taylor
-Clint
On 2/28/19 9:36 AM, Ville Syrjala wrote:
From: Ville Syrjälä
The icl wm1+ underrun w/a has been added to the spec. It changed
slightly from the previous incarnation by requiring that we mirror
the lines watermark and the ignore lines bit from WM0 into WM1.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4c0e43caa5cd..9c97a95c1816 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4467,11 +4467,15 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
wm = >wm.skl.optimal.planes[plane_id];
memset(>wm[level], 0, sizeof(wm->wm[level]));
- /* W/A for underruns with WM1+ disabled */
+ /*
+* Wa_1408961008:icl
+* Underruns with WM1+ disabled
+*/
if (IS_ICELAKE(dev_priv) &&
level == 1 && wm->wm[0].plane_en) {
wm->wm[level].plane_res_b =
wm->wm[0].plane_res_b;
- wm->wm[level].ignore_lines = true;
+ wm->wm[level].plane_res_l =
wm->wm[0].plane_res_l;
+ wm->wm[level].ignore_lines =
wm->wm[0].ignore_lines;
}
}
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI, v3, 1/2] drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set
Quoting Guenter Roeck (2019-02-28 21:32:41)
> On Thu, Feb 28, 2019 at 11:12:49AM -0800, Guenter Roeck wrote:
> > Hi,
> >
> > On Thu, Feb 07, 2019 at 10:54:53AM +0200, Joonas Lahtinen wrote:
> > > Make sure the underlying VMA in the process address space is the
> > > same as it was during vm_mmap to avoid applying WC to wrong VMA.
> > >
> > > A more long-term solution would be to have vm_mmap_locked variant
> > > in linux/mmap.h for when caller wants to hold mmap_sem for an
> > > extended duration.
> > >
> >
> > It seems like we may have a regression due to this patch. I am still
> > debugging, but I have a question; please see below.
> >
> > Thanks,
> > Guenter
> >
> > > v2:
> > > - Refactor the compare function
> > >
> > > Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user
> > > mappings for objects")
> > > Reported-by: Adam Zabrocki
> > > Suggested-by: Linus Torvalds
> > > Signed-off-by: Joonas Lahtinen
> > > Cc: # v4.0+
> > > Cc: Akash Goel
> > > Cc: Chris Wilson
> > > Cc: Tvrtko Ursulin
> > > Cc: Adam Zabrocki
> > > Reviewed-by: Chris Wilson
> > > Reviewed-by: Tvrtko Ursulin #v1
> > > ---
> > > drivers/gpu/drm/i915/i915_gem.c | 12 +++-
> > > 1 file changed, 11 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > > b/drivers/gpu/drm/i915/i915_gem.c
> > > index 05ce9176ac4e..52639f749908 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -1681,6 +1681,16 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev,
> > > void *data,
> > > return 0;
> > > }
> > >
> > > +static inline bool
> > > +__vma_matches(struct vm_area_struct *vma, struct file *filp,
> > > + unsigned long addr, unsigned long size)
> > > +{
> > > + if (vma->vm_file != filp)
> > > + return false;
> > > +
> > > + return vma->vm_start == addr && (vma->vm_end - vma->vm_start) == size;
> >
> > Shouldn't this be:
> > return vma->vm_start == addr && (vma->vm_end - vma->vm_start + 1) ==
> > size;
> > instead ?
> >
>
> Answer is no .. because vm_end points to the first byte after the
> end address.
>
> The actual values are:
>
> start=7d288f7f9000 end=7d288f84d000 end-start=54000 size=53400
>
> meaning the size field passed in the ioctl is smaller than the total length
> of the area.
>
> Question is now: Is the request/ioctl indeed invalid, ie does the requested
> size have to match the vma size ?
Yes. The vma is page-aligned, your request isn't. What happens next is
undefined behaviour, and almost certainly not what you expect -- you
can't access the last bits of your framebuffer.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Finalize Wa_1408961008:icl
== Series Details == Series: drm/i915: Finalize Wa_1408961008:icl URL : https://patchwork.freedesktop.org/series/57359/ State : success == Summary == CI Bug Log - changes from CI_DRM_5674_full -> Patchwork_12334_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12334_full that come from known issues: ### IGT changes ### Issues hit * igt@kms_busy@basic-flip-d: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +6 * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a: - shard-kbl: PASS -> DMESG-WARN [fdo#107956] * igt@kms_color@pipe-a-legacy-gamma: - shard-apl: PASS -> FAIL [fdo#104782] / [fdo#108145] +1 * igt@kms_cursor_crc@cursor-64x21-sliding: - shard-apl: PASS -> FAIL [fdo#103232] +2 * igt@kms_cursor_crc@cursor-alpha-opaque: - shard-glk: PASS -> FAIL [fdo#109350] * igt@kms_flip@flip-vs-expired-vblank: - shard-glk: PASS -> FAIL [fdo#102887] / [fdo#105363] * igt@kms_flip@plain-flip-fb-recreate-interruptible: - shard-skl: PASS -> FAIL [fdo#100368] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt: - shard-apl: NOTRUN -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff: - shard-apl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc: - shard-glk: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-fullscreen: - shard-apl: NOTRUN -> SKIP [fdo#109271] +17 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-mmap-cpu: - shard-skl: NOTRUN -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@psr-1p-primscrn-indfb-msflip-blt: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +12 * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-move: - shard-skl: NOTRUN -> SKIP [fdo#109271] +67 * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] * igt@kms_plane_alpha_blend@pipe-a-alpha-basic: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_lowres@pipe-a-tiling-none: - shard-snb: PASS -> SKIP [fdo#109271] +2 * igt@kms_plane_multiple@atomic-pipe-a-tiling-x: - shard-apl: PASS -> FAIL [fdo#103166] +1 * igt@kms_plane_multiple@atomic-pipe-c-tiling-none: - shard-glk: PASS -> FAIL [fdo#103166] * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom: - shard-kbl: PASS -> DMESG-FAIL [fdo#105763] * igt@kms_universal_plane@cursor-fb-leak-pipe-d: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +7 * igt@perf_pmu@busy-check-all-vecs0: - shard-snb: NOTRUN -> SKIP [fdo#109271] +78 Possible fixes * igt@gem_eio@in-flight-suspend: - shard-snb: FAIL [fdo#103375] -> PASS * igt@i915_pm_rpm@universal-planes-dpms: - shard-skl: INCOMPLETE [fdo#107807] -> PASS * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: - shard-apl: DMESG-WARN [fdo#107956] -> PASS - shard-kbl: DMESG-WARN [fdo#107956] -> PASS * igt@kms_busy@extended-pageflip-hang-newfb-render-a: - shard-glk: DMESG-WARN [fdo#107956] -> PASS * igt@kms_chv_cursor_fail@pipe-c-128x128-top-edge: - shard-hsw: DMESG-WARN [fdo#102614] -> PASS +1 * igt@kms_cursor_crc@cursor-128x128-offscreen: - shard-apl: INCOMPLETE [fdo#103927] -> PASS * igt@kms_cursor_crc@cursor-128x42-random: - shard-apl: FAIL [fdo#103232] -> PASS * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-ytiled: - shard-skl: FAIL [fdo#103184] -> PASS * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: FAIL [fdo#105363] -> PASS * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu: - shard-apl: FAIL [fdo#103167] -> PASS +1 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move: - shard-glk: FAIL [fdo#103167] -> PASS +1 * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-apl: FAIL [fdo#108948] -> PASS * igt@kms_plane@plane-position-covered-pipe-a-planes: - shard-apl: FAIL [fdo#103166] -> PASS * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: FAIL [fdo#107815] -> PASS * igt@kms_plane_multiple@atomic-pipe-a-tiling-y: - shard-glk: FAIL [fdo#103166] -> PASS +2 * igt@kms_rotation_crc@multiplane-rotation: - shard-kbl: INCOMPLETE [fdo#103665] -> PASS * igt@kms_setmode@basic: - shard-apl: FAIL [fdo#99912] -> PASS - shard-kbl: FAIL [fdo#99912] ->
Re: [Intel-gfx] [CI, v3, 1/2] drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set
On Thu, Feb 28, 2019 at 11:12:49AM -0800, Guenter Roeck wrote:
> Hi,
>
> On Thu, Feb 07, 2019 at 10:54:53AM +0200, Joonas Lahtinen wrote:
> > Make sure the underlying VMA in the process address space is the
> > same as it was during vm_mmap to avoid applying WC to wrong VMA.
> >
> > A more long-term solution would be to have vm_mmap_locked variant
> > in linux/mmap.h for when caller wants to hold mmap_sem for an
> > extended duration.
> >
>
> It seems like we may have a regression due to this patch. I am still
> debugging, but I have a question; please see below.
>
> Thanks,
> Guenter
>
> > v2:
> > - Refactor the compare function
> >
> > Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user
> > mappings for objects")
> > Reported-by: Adam Zabrocki
> > Suggested-by: Linus Torvalds
> > Signed-off-by: Joonas Lahtinen
> > Cc: # v4.0+
> > Cc: Akash Goel
> > Cc: Chris Wilson
> > Cc: Tvrtko Ursulin
> > Cc: Adam Zabrocki
> > Reviewed-by: Chris Wilson
> > Reviewed-by: Tvrtko Ursulin #v1
> > ---
> > drivers/gpu/drm/i915/i915_gem.c | 12 +++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 05ce9176ac4e..52639f749908 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -1681,6 +1681,16 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev,
> > void *data,
> > return 0;
> > }
> >
> > +static inline bool
> > +__vma_matches(struct vm_area_struct *vma, struct file *filp,
> > + unsigned long addr, unsigned long size)
> > +{
> > + if (vma->vm_file != filp)
> > + return false;
> > +
> > + return vma->vm_start == addr && (vma->vm_end - vma->vm_start) == size;
>
> Shouldn't this be:
> return vma->vm_start == addr && (vma->vm_end - vma->vm_start + 1) ==
> size;
> instead ?
>
Answer is no .. because vm_end points to the first byte after the
end address.
The actual values are:
start=7d288f7f9000 end=7d288f84d000 end-start=54000 size=53400
meaning the size field passed in the ioctl is smaller than the total length
of the area.
Question is now: Is the request/ioctl indeed invalid, ie does the requested
size have to match the vma size ? This used to work until this patch was
applied, and the change causes our test code to fail (and possibly minigbm,
which is used by the test code). That doesn't mean that our code is correct
(I see some related local changes in our version of minigbm), but it is
annoying, and I am being asked to revert this patch as regression
from our kernel releases.
Thanks,
Guenter
> > +}
> > +
> > /**
> > * i915_gem_mmap_ioctl - Maps the contents of an object, returning the
> > address
> > * it is mapped to.
> > @@ -1739,7 +1749,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void
> > *data,
> > return -EINTR;
> > }
> > vma = find_vma(mm, addr);
> > - if (vma)
> > + if (vma && __vma_matches(vma, obj->base.filp, addr, args->size))
> > vma->vm_page_prot =
> >
> > pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
> > else
___
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: Don't manually add connectors and planes state
On Thu, 2019-02-28 at 13:37 +0200, Ville Syrjälä wrote: > On Wed, Feb 27, 2019 at 03:04:08PM -0800, José Roberto de Souza > wrote: > > drm_atomic_commit() call chain already takes care of adding > > connectors and planes, so lets no add then manually if not changing > > their states. > > The specific callgraph would make review easier. Appending this to the commit message is enough? drm_atomic_commit() drm_atomic_check_only() config->funcs->atomic_check()/intel_atomic_check() drm_atomic_helper_check() drm_atomic_helper_check_modeset() for_each_oldnew_crtc_in_state() drm_atomic_add_affected _connectors() drm_atomic_add_affected _planes() > > > Cc: Ville Syrjälä > > Cc: Lyude Paul > > Signed-off-by: José Roberto de Souza > > --- > > drivers/gpu/drm/i915/intel_ddi.c | 8 > > 1 file changed, 8 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c > > b/drivers/gpu/drm/i915/intel_ddi.c > > index 34dd5823398a..c22ddde2dfc1 100644 > > --- a/drivers/gpu/drm/i915/intel_ddi.c > > +++ b/drivers/gpu/drm/i915/intel_ddi.c > > @@ -3975,14 +3975,6 @@ static int modeset_pipe(struct drm_crtc > > *crtc, > > > > crtc_state->mode_changed = true; > > > > - ret = drm_atomic_add_affected_connectors(state, crtc); > > - if (ret) > > - goto out; > > - > > - ret = drm_atomic_add_affected_planes(state, crtc); > > - if (ret) > > - goto out; > > - > > ret = drm_atomic_commit(state); > > out: > > drm_atomic_state_put(state); > > -- > > 2.21.0 signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for some cleanups and uapi clarification for leases
== Series Details == Series: some cleanups and uapi clarification for leases URL : https://patchwork.freedesktop.org/series/57354/ State : success == Summary == CI Bug Log - changes from CI_DRM_5674_full -> Patchwork_12333_full Summary --- **SUCCESS** No regressions found. New tests - New tests have been introduced between CI_DRM_5674_full and Patchwork_12333_full: ### New IGT tests (14) ### * igt@kms_addfb_basic@master-rmfb: - Statuses : 6 pass(s) - Exec time: [0.0, 0.00] s * igt@kms_lease@atomic_implicit_crtc: - Statuses : 6 pass(s) - Exec time: [0.00, 0.02] s * igt@kms_lease@cursor_implicit_plane: - Statuses : 6 pass(s) - Exec time: [0.23, 2.81] s * igt@kms_lease@page_flip_implicit_plane: - Statuses : 6 pass(s) - Exec time: [0.29, 2.92] s * igt@kms_lease@setcrtc_implicit_plane: - Statuses : 6 pass(s) - Exec time: [0.26, 3.05] s * igt@kms_prop_blob@basic: - Statuses : 5 pass(s) - Exec time: [0.0] s * igt@kms_prop_blob@blob-multiple: - Statuses : 6 pass(s) - Exec time: [0.0, 0.00] s * igt@kms_prop_blob@blob-prop-core: - Statuses : 6 pass(s) - Exec time: [0.0] s * igt@kms_prop_blob@blob-prop-lifetime: - Statuses : 6 pass(s) - Exec time: [0.0, 0.00] s * igt@kms_prop_blob@blob-prop-validate: - Statuses : 6 pass(s) - Exec time: [0.0] s * igt@kms_prop_blob@invalid-get-prop: - Statuses : 6 pass(s) - Exec time: [0.0] s * igt@kms_prop_blob@invalid-get-prop-any: - Statuses : 6 pass(s) - Exec time: [0.0] s * igt@kms_prop_blob@invalid-set-prop: - Statuses : 6 pass(s) - Exec time: [0.0] s * igt@kms_prop_blob@invalid-set-prop-any: - Statuses : 6 pass(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_12333_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_userptr_blits@unsync-unmap-cycles: - shard-snb: PASS -> INCOMPLETE [fdo#105411] * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-kbl: PASS -> SKIP [fdo#109271] * igt@kms_atomic_transition@1x-modeset-transitions-fencing: - shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108470] * igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: - shard-kbl: PASS -> FAIL [fdo#109660] * igt@kms_busy@basic-flip-d: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +12 * igt@kms_busy@extended-modeset-hang-newfb-render-b: - shard-skl: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a: - shard-kbl: PASS -> DMESG-WARN [fdo#107956] * igt@kms_chv_cursor_fail@pipe-c-128x128-left-edge: - shard-skl: PASS -> FAIL [fdo#104671] * igt@kms_color@pipe-b-degamma: - shard-skl: PASS -> FAIL [fdo#104782] * igt@kms_color@pipe-c-ctm-green-to-red: - shard-skl: PASS -> FAIL [fdo#107201] * igt@kms_cursor_crc@cursor-128x128-random: - shard-skl: PASS -> FAIL [fdo#103232] +2 * igt@kms_cursor_crc@cursor-256x256-onscreen: - shard-kbl: PASS -> FAIL [fdo#103232] +2 - shard-glk: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-256x85-random: - shard-apl: PASS -> FAIL [fdo#103232] +3 * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-glk: NOTRUN -> SKIP [fdo#109271] +6 * igt@kms_flip@modeset-vs-vblank-race: - shard-glk: PASS -> FAIL [fdo#103060] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt: - shard-glk: PASS -> FAIL [fdo#103167] +7 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render: - shard-apl: PASS -> FAIL [fdo#103167] +2 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff: - shard-kbl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-rte: - shard-apl: PASS -> FAIL [fdo#103167] / [fdo#105682] * igt@kms_frontbuffer_tracking@psr-1p-primscrn-indfb-msflip-blt: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +12 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-blt: - shard-skl: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-indfb-msflip-blt: - shard-apl: NOTRUN -> SKIP [fdo#109271] +15 * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-move: - shard-skl: NOTRUN -> SKIP [fdo#109271] +106 * igt@kms_plane@pixel-format-pipe-b-planes: - shard-skl: NOTRUN -> DMESG-FAIL [fdo#103166] / [fdo#106885] - shard-kbl: PASS -> FAIL [fdo#103166] +2 * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-apl: PASS -> FAIL [fdo#108948] * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-skl:
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: Use intel_engine_stop_cs when stopping ringbuffer (rev2)
== Series Details == Series: series starting with [1/3] drm/i915: Use intel_engine_stop_cs when stopping ringbuffer (rev2) URL : https://patchwork.freedesktop.org/series/57352/ State : success == Summary == CI Bug Log - changes from CI_DRM_5674_full -> Patchwork_12332_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12332_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_pwrite@stolen-normal: - shard-skl: NOTRUN -> SKIP [fdo#109271] +60 * igt@gem_softpin@noreloc-s3: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@i915_suspend@sysfs-reader: - shard-skl: PASS -> INCOMPLETE [fdo#104108] * igt@kms_busy@basic-flip-d: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +6 * igt@kms_busy@extended-pageflip-hang-oldfb-render-f: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +6 * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a: - shard-kbl: PASS -> DMESG-WARN [fdo#107956] * igt@kms_chv_cursor_fail@pipe-a-64x64-bottom-edge: - shard-skl: PASS -> FAIL [fdo#104671] * igt@kms_color@pipe-a-legacy-gamma: - shard-apl: PASS -> FAIL [fdo#104782] / [fdo#108145] * igt@kms_color@pipe-b-degamma: - shard-apl: PASS -> FAIL [fdo#104782] * igt@kms_cursor_crc@cursor-64x21-sliding: - shard-apl: PASS -> FAIL [fdo#103232] +1 * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232] +1 * igt@kms_cursor_crc@cursor-alpha-opaque: - shard-glk: PASS -> FAIL [fdo#109350] * igt@kms_draw_crc@draw-method-rgb565-pwrite-xtiled: - shard-skl: PASS -> FAIL [fdo#103184] * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: PASS -> FAIL [fdo#105363] * igt@kms_flip@plain-flip-fb-recreate-interruptible: - shard-skl: PASS -> FAIL [fdo#100368] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt: - shard-apl: NOTRUN -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-rte: - shard-skl: PASS -> FAIL [fdo#103167] / [fdo#105682] * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc: - shard-glk: PASS -> FAIL [fdo#103167] +2 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-blt: - shard-skl: PASS -> FAIL [fdo#105682] * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-fullscreen: - shard-apl: NOTRUN -> SKIP [fdo#109271] +17 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-mmap-cpu: - shard-skl: NOTRUN -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-move: - shard-skl: PASS -> FAIL [fdo#103167] +2 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-indfb-msflip-blt: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +13 * igt@kms_plane@pixel-format-pipe-b-planes: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] * igt@kms_plane_alpha_blend@pipe-a-alpha-basic: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max: - shard-skl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] * igt@kms_plane_multiple@atomic-pipe-c-tiling-y: - shard-apl: PASS -> FAIL [fdo#103166] * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom: - shard-kbl: PASS -> DMESG-FAIL [fdo#105763] * igt@kms_rotation_crc@primary-rotation-90: - shard-skl: PASS -> FAIL [fdo#103925] / [fdo#107815] * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-apl: PASS -> FAIL [fdo#104894] * igt@perf_pmu@busy-check-all-vecs0: - shard-snb: NOTRUN -> SKIP [fdo#109271] +78 * igt@tools_test@tools_test: - shard-kbl: PASS -> SKIP [fdo#109271] Possible fixes * igt@gem_eio@in-flight-suspend: - shard-snb: FAIL [fdo#103375] -> PASS * igt@i915_pm_rpm@universal-planes-dpms: - shard-skl: INCOMPLETE [fdo#107807] -> PASS * igt@kms_chv_cursor_fail@pipe-c-128x128-top-edge: - shard-hsw: DMESG-WARN [fdo#102614] -> PASS +1 * igt@kms_color@pipe-b-legacy-gamma: - shard-apl: FAIL [fdo#104782] -> PASS * igt@kms_cursor_crc@cursor-128x128-offscreen: - shard-apl: INCOMPLETE [fdo#103927] -> PASS * igt@kms_cursor_crc@cursor-128x42-sliding: - shard-apl: FAIL [fdo#103232] -> PASS *
Re: [Intel-gfx] [CI, v3, 1/2] drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set
Hi,
On Thu, Feb 07, 2019 at 10:54:53AM +0200, Joonas Lahtinen wrote:
> Make sure the underlying VMA in the process address space is the
> same as it was during vm_mmap to avoid applying WC to wrong VMA.
>
> A more long-term solution would be to have vm_mmap_locked variant
> in linux/mmap.h for when caller wants to hold mmap_sem for an
> extended duration.
>
It seems like we may have a regression due to this patch. I am still
debugging, but I have a question; please see below.
Thanks,
Guenter
> v2:
> - Refactor the compare function
>
> Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user mappings
> for objects")
> Reported-by: Adam Zabrocki
> Suggested-by: Linus Torvalds
> Signed-off-by: Joonas Lahtinen
> Cc: # v4.0+
> Cc: Akash Goel
> Cc: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Adam Zabrocki
> Reviewed-by: Chris Wilson
> Reviewed-by: Tvrtko Ursulin #v1
> ---
> drivers/gpu/drm/i915/i915_gem.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 05ce9176ac4e..52639f749908 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1681,6 +1681,16 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev, void
> *data,
> return 0;
> }
>
> +static inline bool
> +__vma_matches(struct vm_area_struct *vma, struct file *filp,
> + unsigned long addr, unsigned long size)
> +{
> + if (vma->vm_file != filp)
> + return false;
> +
> + return vma->vm_start == addr && (vma->vm_end - vma->vm_start) == size;
Shouldn't this be:
return vma->vm_start == addr && (vma->vm_end - vma->vm_start + 1) ==
size;
instead ?
> +}
> +
> /**
> * i915_gem_mmap_ioctl - Maps the contents of an object, returning the
> address
> *it is mapped to.
> @@ -1739,7 +1749,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
> return -EINTR;
> }
> vma = find_vma(mm, addr);
> - if (vma)
> + if (vma && __vma_matches(vma, obj->base.filp, addr, args->size))
> vma->vm_page_prot =
>
> pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
> else
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/icl: Default to Thread Group preemption for compute workloads
On Wed, Feb 27, 2019 at 04:51:08PM +0100, Michał Winiarski wrote:
> We assumed that the default preemption granularity is fine for ICL.
> Unfortunately, it turns out that some drivers don't support mid-thread
> preemption for compute workloads.
> If a workload that doesn't support mid-thread preemption gets mid-thread
> preempted, we're going to observe a GPU hang.
> While I'm here, let's also update the "workaround" naming.
>
> Signed-off-by: Michał Winiarski
> Cc: Anuj Phogat
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: Rafael Antognolli
> ---
> drivers/gpu/drm/i915/intel_workarounds.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> b/drivers/gpu/drm/i915/intel_workarounds.c
> index 743cf5b00155..a19e1c0052a7 100644
> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> @@ -555,6 +555,11 @@ static void icl_ctx_workarounds_init(struct
> intel_engine_cs *engine)
> GEN10_CACHE_MODE_SS,
> 0, /* write-only, so skip validation */
> _MASKED_BIT_ENABLE(FLOAT_BLEND_OPTIMIZATION_ENABLE));
> +
> + /* WaDisableGPGPUMidThreadPreemption:icl */
Could you please give me some internal pointers to this WA?
I couldn't find it on bspec nor on wadb.
> + WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1,
> + GEN9_PREEMPT_GPGPU_LEVEL_MASK,
> + GEN9_PREEMPT_GPGPU_THREAD_GROUP_LEVEL);
> }
>
> void intel_engine_init_ctx_wa(struct intel_engine_cs *engine)
> @@ -1170,8 +1175,8 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
> GEN7_DISABLE_SAMPLER_PREFETCH);
> }
>
> - if (IS_GEN(i915, 9) || IS_CANNONLAKE(i915)) {
> - /*
> WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,cnl */
Please don't remove the old name that is still part of old
references. If we have a new name for ICL+ please keep both
here on the comments.
> + if (IS_GEN_RANGE(i915, 9, 11)) {
> + /*
> FtrPerCtxtPreemptionGranularityControl:skl,bxt,kbl,cfl,cnl,icl */
also please give me a pointer to this...
Thanks,
Rodrigo.
> wa_masked_en(wal,
>GEN7_FF_SLICE_CS_CHICKEN1,
>GEN9_FFSC_PERCTX_PREEMPT_CTRL);
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib: Incrementally mlock()
Reviewed-by: Caz Yokoyama
Correction of my test report: The patched test runs less than 7 sec on
my nuc. 10 times faster.
-caz
On Wed, 2019-02-27 at 16:29 +, Chris Wilson wrote:
> As we already have the previous portion of the mmap mlocked, we only
> need to mlock() the fresh portion for testing available memory.
>
> v2: Fixup the uint64_t pointer arithmetric and only use a single mmap
> to
> avoid subsequent mlock fail (for reasons unknown, but bet on mm/).
>
> Signed-off-by: Chris Wilson
> Cc: Caz Yokoyama
> ---
> lib/igt_aux.h | 2 +-
> lib/intel_os.c| 40 +--
>
> tests/eviction_common.c | 17 +
> tests/i915/i915_suspend.c | 17 +++--
> 4 files changed, 35 insertions(+), 41 deletions(-)
>
> diff --git a/lib/igt_aux.h b/lib/igt_aux.h
> index fb02c026a..09b6246bf 100644
> --- a/lib/igt_aux.h
> +++ b/lib/igt_aux.h
> @@ -194,7 +194,7 @@ void intel_purge_vm_caches(int fd);
> uint64_t intel_get_avail_ram_mb(void);
> uint64_t intel_get_total_ram_mb(void);
> uint64_t intel_get_total_swap_mb(void);
> -size_t intel_get_total_pinnable_mem(void);
> +void *intel_get_total_pinnable_mem(size_t *pinned);
>
> int __intel_check_memory(uint64_t count, uint64_t size, unsigned
> mode,
>uint64_t *out_required, uint64_t *out_total);
> diff --git a/lib/intel_os.c b/lib/intel_os.c
> index e1e31e230..dd93bea1a 100644
> --- a/lib/intel_os.c
> +++ b/lib/intel_os.c
> @@ -227,11 +227,9 @@ intel_get_total_swap_mb(void)
> *
> * Returns: Amount of memory that can be safely pinned, in bytes.
> */
> -size_t
> -intel_get_total_pinnable_mem(void)
> +void *intel_get_total_pinnable_mem(size_t *total)
> {
> uint64_t *can_mlock, pin, avail;
> - size_t ret;
>
> pin = (intel_get_total_ram_mb() + 1) << 20;
> avail = (intel_get_avail_ram_mb() + 1) << 20;
> @@ -245,34 +243,40 @@ intel_get_total_pinnable_mem(void)
>*/
> *can_mlock = (avail >> 1) + (avail >> 2);
> if (mlock(can_mlock, *can_mlock)) {
> - *can_mlock = 0;
> - goto out;
> + munmap(can_mlock, pin);
> + return MAP_FAILED;
> }
>
> for (uint64_t inc = 1024 << 20; inc >= 4 << 10; inc >>= 2) {
> - igt_debug("Testing mlock %'"PRIu64" B (%'"PRIu64"
> MiB)\n",
> - *can_mlock, *can_mlock >> 20);
> + uint64_t locked = *can_mlock;
> +
> + igt_debug("Testing mlock %'"PRIu64"B (%'"PRIu64"MiB) +
> %'"PRIu64"B\n",
> + locked, locked >> 20, inc);
>
> igt_fork(child, 1) {
> - for (uint64_t bytes = *can_mlock;
> - bytes <= pin;
> - bytes += inc) {
> - if (mlock(can_mlock, bytes))
> + uint64_t bytes = *can_mlock;
> +
> + while (bytes <= pin) {
> + if (mlock((void *)can_mlock + bytes,
> inc))
> break;
>
> - *can_mlock = bytes;
> + *can_mlock = bytes += inc;
> __sync_synchronize();
> }
> }
> __igt_waitchildren();
> - igt_assert(!mlock(can_mlock, *can_mlock));
> - }
>
> -out:
> - ret = *can_mlock;
> - munmap(can_mlock, pin);
> + if (*can_mlock > locked + inc) { /* Weird bit of mm/
> lore */
> + *can_mlock -= inc;
> + igt_debug("Claiming mlock %'"PRIu64"B
> (%'"PRIu64"MiB)\n",
> + *can_mlock, *can_mlock >> 20);
> + igt_assert(!mlock((void *)can_mlock + locked,
> + *can_mlock - locked));
> + }
> + }
>
> - return ret;
> + *total = pin;
> + return can_mlock;
> }
>
> static uint64_t vfs_file_max(void)
> diff --git a/tests/eviction_common.c b/tests/eviction_common.c
> index 321772ba7..a3b9e4167 100644
> --- a/tests/eviction_common.c
> +++ b/tests/eviction_common.c
> @@ -133,23 +133,24 @@ static void mlocked_evictions(int fd, struct
> igt_eviction_test_ops *ops,
> uint64_t surface_size,
> uint64_t surface_count)
> {
> + uint64_t sz, pin, total;
> void *mem;
> - uint64_t sz, pin_total;
>
> intel_require_memory(surface_count, surface_size, CHECK_RAM);
>
> - sz = surface_size*surface_count;
> - pin_total = intel_get_total_pinnable_mem();
> - igt_require(pin_total > sz);
> -
> - mem = mmap(NULL, pin_total, PROT_READ, MAP_SHARED | MAP_ANON,
> -1, 0);
> + mem = intel_get_total_pinnable_mem();
> igt_assert(mem != MAP_FAILED);
> + pin = *(uint64_t *)mem;
> + igt_assert(!munlock(mem, pin));
> +
> + sz = surface_size * surface_count;
> +
Re: [Intel-gfx] [PATCH] drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake.
Quoting Kenneth Graunke (2018-01-05 06:06:34) > On Thursday, January 4, 2018 4:41:35 PM PST Rodrigo Vivi wrote: > > On Thu, Jan 04, 2018 at 11:39:23PM +, Kenneth Graunke wrote: > > > On Thursday, January 4, 2018 1:23:06 PM PST Chris Wilson wrote: > > > > Quoting Kenneth Graunke (2018-01-04 19:38:05) > > > > > Geminilake requires the 3D driver to select whether barriers are > > > > > intended for compute shaders, or tessellation control shaders, by > > > > > whacking a "Barrier Mode" bit in SLICE_COMMON_ECO_CHICKEN1 when > > > > > switching pipelines. Failure to do this properly can result in GPU > > > > > hangs. > > > > > > > > > > Unfortunately, this means it needs to switch mid-batch, so only > > > > > userspace can properly set it. To facilitate this, the kernel needs > > > > > to whitelist the register. > > > > > > > > > > Signed-off-by: Kenneth Graunke > > > > > Cc: sta...@vger.kernel.org > > > > > --- > > > > > drivers/gpu/drm/i915/i915_reg.h| 2 ++ > > > > > drivers/gpu/drm/i915/intel_engine_cs.c | 5 + > > > > > 2 files changed, 7 insertions(+) > > > > > > > > > > Hello, > > > > > > > > > > We unfortunately need to whitelist an extra register for GPU hang fix > > > > > on Geminilake. Here's the corresponding Mesa patch: > > > > > > > > Thankfully it appears to be context saved. Has a w/a name been assigned > > > > for this? > > > > -Chris > > > > > > There doesn't appear to be one. The workaround page lists it, but there > > > is no name. The register description has a note saying that you need to > > > set this, but doesn't call it out as a workaround. > > > > It mentions only BXT:ALL, but not mention to GLK. > > > > Should we add to both then? > > Well, that's irritating. On the workarounds page, it does indeed say > "BXT" with no mention of GLK. But the workaround text says to set > "SLICE_COMMON_CHICKEN_ECO1 Barrier Mode [...] (bit 7 of MMIO 0x731C)." > > Looking at the register definition for SLICE_COMMON_ECO_CHICKEN1, bit 7 > is "Barrier Mode" on [GLK] only, with no mention of BXT. It's marked > reserved PBC on [SKL+, not GLK, not KBL]. On KBL it's something else. > > I believe Mark saw hangs in tessellation control shader hangs on > Geminilake only, and never saw this issue on Broxton. So, my guess is > that the workaround really is new on Geminilake, and the BXT tag on the > workarounds page is incorrect. (Mark, does that sound right to you?) Hi, I'm back! This fails a selftest on glk as we can't even write to the register 0x731c, or at least can't read from the register. Did bspec ever get updated to include this register & wa? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Finalize Wa_1408961008:icl
== Series Details ==
Series: drm/i915: Finalize Wa_1408961008:icl
URL : https://patchwork.freedesktop.org/series/57359/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5674 -> Patchwork_12334
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/57359/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12334 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-n3050: PASS -> SKIP [fdo#109271]
* igt@i915_pm_rpm@basic-rte:
- fi-bsw-n3050: PASS -> FAIL [fdo#108800]
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: PASS -> FAIL [fdo#103167]
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: DMESG-WARN [fdo#108965] -> PASS
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
Participating hosts (44 -> 37)
--
Additional (1): fi-icl-y
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-byt-squawks
fi-bsw-cyan fi-bwr-2160 fi-ctg-p8600 fi-bxt-j4205
Build changes
-
* Linux: CI_DRM_5674 -> Patchwork_12334
CI_DRM_5674: 71bb3bfb61fb58f93f8b09e6ad576a403cd7752c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4863: 0f0db14e7f4ec41251ca156d7cb5b8d531a38006 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12334: aeb805975ea67aea0e0ee48763698f18d3301f96 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
aeb805975ea6 drm/i915: Finalize Wa_1408961008:icl
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12334/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Finalize Wa_1408961008:icl
On Thu, Feb 28, 2019 at 07:36:39PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The icl wm1+ underrun w/a has been added to the spec. It changed
> slightly from the previous incarnation by requiring that we mirror
> the lines watermark and the ignore lines bit from WM0 into WM1.
>
> Signed-off-by: Ville Syrjälä
Matches the new workaround details that were added to the bspec
yesterday.
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_pm.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 4c0e43caa5cd..9c97a95c1816 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4467,11 +4467,15 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
> wm = >wm.skl.optimal.planes[plane_id];
> memset(>wm[level], 0, sizeof(wm->wm[level]));
>
> - /* W/A for underruns with WM1+ disabled */
> + /*
> + * Wa_1408961008:icl
> + * Underruns with WM1+ disabled
> + */
> if (IS_ICELAKE(dev_priv) &&
> level == 1 && wm->wm[0].plane_en) {
> wm->wm[level].plane_res_b =
> wm->wm[0].plane_res_b;
> - wm->wm[level].ignore_lines = true;
> + wm->wm[level].plane_res_l =
> wm->wm[0].plane_res_l;
> + wm->wm[level].ignore_lines =
> wm->wm[0].ignore_lines;
> }
> }
> }
> --
> 2.19.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Check that whitelisted registers are accessible (rev3)
== Series Details == Series: drm/i915/selftests: Check that whitelisted registers are accessible (rev3) URL : https://patchwork.freedesktop.org/series/57342/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5673_full -> Patchwork_12329_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12329_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12329_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_12329_full: ### IGT changes ### Possible regressions * igt@i915_selftest@live_workarounds: - shard-glk: PASS -> DMESG-FAIL Known issues Here are the changes found in Patchwork_12329_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@extended-semaphore-bsd: - shard-hsw: NOTRUN -> SKIP [fdo#109271] +4 * igt@gem_pread@stolen-normal: - shard-skl: NOTRUN -> SKIP [fdo#109271] +97 * igt@i915_pm_rpm@cursor-dpms: - shard-skl: PASS -> INCOMPLETE [fdo#107807] * igt@i915_pm_rpm@debugfs-read: - shard-skl: NOTRUN -> INCOMPLETE [fdo#107807] * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-oldfb-render-f: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +8 * igt@kms_busy@extended-pageflip-hang-newfb-render-f: - shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@kms_chamelium@hdmi-crc-fast: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +17 * igt@kms_chv_cursor_fail@pipe-a-64x64-bottom-edge: - shard-skl: PASS -> FAIL [fdo#104671] * igt@kms_chv_cursor_fail@pipe-c-256x256-right-edge: - shard-skl: NOTRUN -> FAIL [fdo#104671] * igt@kms_color@pipe-a-degamma: - shard-apl: PASS -> FAIL [fdo#104782] / [fdo#108145] * igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions: - shard-hsw: PASS -> FAIL [fdo#103355] * igt@kms_flip_tiling@flip-changes-tiling: - shard-skl: PASS -> FAIL [fdo#108303] * igt@kms_frontbuffer_tracking@fbc-1p-rte: - shard-skl: PASS -> FAIL [fdo#103167] / [fdo#105682] * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-blt: - shard-skl: PASS -> FAIL [fdo#105682] * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-render: - shard-snb: NOTRUN -> SKIP [fdo#109271] +40 * igt@kms_frontbuffer_tracking@fbcpsr-stridechange: - shard-skl: NOTRUN -> FAIL [fdo#105683] * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-move: - shard-skl: PASS -> FAIL [fdo#103167] +2 * igt@kms_plane@pixel-format-pipe-c-planes: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb: - shard-kbl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: NOTRUN -> FAIL [fdo#108145] +1 * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: PASS -> FAIL [fdo#107815] * igt@kms_plane_multiple@atomic-pipe-a-tiling-x: - shard-apl: PASS -> FAIL [fdo#103166] * igt@kms_plane_multiple@atomic-pipe-c-tiling-y: - shard-glk: PASS -> FAIL [fdo#103166] * igt@kms_rotation_crc@primary-rotation-90: - shard-skl: PASS -> FAIL [fdo#103925] / [fdo#107815] * igt@kms_setmode@basic: - shard-apl: PASS -> FAIL [fdo#99912] - shard-kbl: PASS -> FAIL [fdo#99912] * igt@kms_universal_plane@cursor-fb-leak-pipe-d: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@kms_vblank@pipe-b-ts-continuation-suspend: - shard-snb: PASS -> INCOMPLETE [fdo#105411] * igt@perf_pmu@rc6: - shard-kbl: PASS -> SKIP [fdo#109271] * igt@tools_test@tools_test: - shard-hsw: PASS -> SKIP [fdo#109271] +1 Possible fixes * igt@i915_pm_rpm@sysfs-read: - shard-skl: INCOMPLETE [fdo#107807] -> PASS * igt@kms_busy@extended-pageflip-hang-newfb-render-a: - shard-glk: DMESG-WARN [fdo#107956] -> PASS * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS * igt@kms_cursor_crc@cursor-64x21-sliding: - shard-apl: FAIL [fdo#103232] -> PASS * igt@kms_flip@flip-vs-suspend-interruptible: -
Re: [Intel-gfx] [PATCH v4 2/5] drm/i915: Watchdog timeout: IRQ handler for gen8+
On 21/02/2019 02:58, Carlos Santa wrote:
From: Michel Thierry
*** General ***
Watchdog timeout (or "media engine reset") is a feature that allows
userland applications to enable hang detection on individual batch buffers.
The detection mechanism itself is mostly bound to the hardware and the only
thing that the driver needs to do to support this form of hang detection
is to implement the interrupt handling support as well as watchdog command
emission before and after the emitted batch buffer start instruction in the
ring buffer.
The principle of the hang detection mechanism is as follows:
1. Once the decision has been made to enable watchdog timeout for a
particular batch buffer and the driver is in the process of emitting the
batch buffer start instruction into the ring buffer it also emits a
watchdog timer start instruction before and a watchdog timer cancellation
instruction after the batch buffer start instruction in the ring buffer.
2. Once the GPU execution reaches the watchdog timer start instruction
the hardware watchdog counter is started by the hardware. The counter
keeps counting until either reaching a previously configured threshold
value or the timer cancellation instruction is executed.
2a. If the counter reaches the threshold value the hardware fires a
watchdog interrupt that is picked up by the watchdog interrupt handler.
This means that a hang has been detected and the driver needs to deal with
it the same way it would deal with a engine hang detected by the periodic
hang checker. The only difference between the two is that we already blamed
the active request (to ensure an engine reset).
2b. If the batch buffer completes and the execution reaches the watchdog
cancellation instruction before the watchdog counter reaches its
threshold value the watchdog is cancelled and nothing more comes of it.
No hang is detected.
Note about future interaction with preemption: Preemption could happen
in a command sequence prior to watchdog counter getting disabled,
resulting in watchdog being triggered following preemption (e.g. when
watchdog had been enabled in the low priority batch). The driver will
need to explicitly disable the watchdog counter as part of the
preemption sequence.
*** This patch introduces: ***
1. IRQ handler code for watchdog timeout allowing direct hang recovery
based on hardware-driven hang detection, which then integrates directly
with the hang recovery path. This is independent of having per-engine reset
or just full gpu reset.
2. Watchdog specific register information.
Currently the render engine and all available media engines support
watchdog timeout (VECS is only supported in GEN9). The specifications elude
to the BCS engine being supported but that is currently not supported by
this commit.
Note that the value to stop the counter is different between render and
non-render engines in GEN8; GEN9 onwards it's the same.
v2: Move irq handler to tasklet, arm watchdog for a 2nd time to check
against false-positives.
v3: Don't use high priority tasklet, use engine_last_submit while
checking for false-positives. From GEN9 onwards, the stop counter bit is
the same for all engines.
v4: Remove unnecessary brackets, use current_seqno to mark the request
as guilty in the hangcheck/capture code.
v5: Rebased after RESET_ENGINEs flag.
v6: Don't capture error state in case of watchdog timeout. The capture
process is time consuming and this will align to what happens when we
use GuC to handle the watchdog timeout. (Chris)
v7: Rebase.
v8: Rebase, use HZ to reschedule.
v9: Rebase, get forcewake domains in function (no longer in execlists
struct).
v10: Rebase.
v11: Rebase,
remove extra braces (Tvrtko),
implement watchdog_to_clock_counts helper (Tvrtko),
Move tasklet_kill(watchdog_tasklet) inside intel_engines (Tvrtko),
Use a global heartbeat seqno instead of engine seqno (Chris)
Make all engines checks all class based checks (Tvrtko)
Cc: Antonio Argenziano
Cc: Tvrtko Ursulin
Signed-off-by: Michel Thierry
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_drv.h | 8 +++
drivers/gpu/drm/i915/i915_gpu_error.h | 4 ++
drivers/gpu/drm/i915/i915_irq.c | 12 -
drivers/gpu/drm/i915/i915_reg.h | 6 +++
drivers/gpu/drm/i915/intel_engine_cs.c | 1 +
drivers/gpu/drm/i915/intel_hangcheck.c | 17 +--
drivers/gpu/drm/i915/intel_lrc.c| 65 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 7 +++
8 files changed, 114 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 63a008aebfcd..0fcb2df869a2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3120,6 +3120,14 @@ i915_gem_context_lookup(struct drm_i915_file_private
*file_priv, u32 id)
return ctx;
}
+static inline u32
+watchdog_to_clock_counts(struct drm_i915_private *dev_priv, u64 value_in_us)
+{
+
[Intel-gfx] [PATCH] drm/i915: Finalize Wa_1408961008:icl
From: Ville Syrjälä
The icl wm1+ underrun w/a has been added to the spec. It changed
slightly from the previous incarnation by requiring that we mirror
the lines watermark and the ignore lines bit from WM0 into WM1.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4c0e43caa5cd..9c97a95c1816 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4467,11 +4467,15 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
wm = >wm.skl.optimal.planes[plane_id];
memset(>wm[level], 0, sizeof(wm->wm[level]));
- /* W/A for underruns with WM1+ disabled */
+ /*
+* Wa_1408961008:icl
+* Underruns with WM1+ disabled
+*/
if (IS_ICELAKE(dev_priv) &&
level == 1 && wm->wm[0].plane_en) {
wm->wm[level].plane_res_b =
wm->wm[0].plane_res_b;
- wm->wm[level].ignore_lines = true;
+ wm->wm[level].plane_res_l =
wm->wm[0].plane_res_l;
+ wm->wm[level].ignore_lines =
wm->wm[0].ignore_lines;
}
}
}
--
2.19.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 some cleanups and uapi clarification for leases
== Series Details == Series: some cleanups and uapi clarification for leases URL : https://patchwork.freedesktop.org/series/57354/ State : success == Summary == CI Bug Log - changes from CI_DRM_5674 -> Patchwork_12333 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/57354/revisions/1/mbox/ New tests - New tests have been introduced between CI_DRM_5674 and Patchwork_12333: ### New IGT tests (1) ### * igt@kms_prop_blob@basic: - Statuses : 35 pass(s) - Exec time: [0.0, 0.00] s Known issues Here are the changes found in Patchwork_12333 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_execlists: - fi-apl-guc: PASS -> INCOMPLETE [fdo#103927] / [fdo#109720] * igt@kms_chamelium@hdmi-edid-read: - fi-hsw-peppy: NOTRUN -> SKIP [fdo#109271] +46 * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: NOTRUN -> DMESG-FAIL [fdo#102614] / [fdo#107814] * igt@kms_pipe_crc_basic@read-crc-pipe-b: - fi-byt-clapper: PASS -> FAIL [fdo#107362] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718] * igt@prime_vgem@basic-fence-flip: - fi-byt-n2820: PASS -> FAIL [fdo#104008] * igt@runner@aborted: - fi-apl-guc: NOTRUN -> FAIL [fdo#108622] / [fdo#109720] / [fdo#109799] Possible fixes * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: - fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107814]: https://bugs.freedesktop.org/show_bug.cgi?id=107814 [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 [fdo#109799]: https://bugs.freedesktop.org/show_bug.cgi?id=109799 Participating hosts (44 -> 37) -- Additional (1): fi-hsw-peppy Missing(8): fi-ilk-m540 fi-bdw-5557u fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-bwr-2160 fi-ctg-p8600 fi-kbl-7560u Build changes - * IGT: IGT_4863 -> IGTPW_2536 * Linux: CI_DRM_5674 -> Patchwork_12333 CI_DRM_5674: 71bb3bfb61fb58f93f8b09e6ad576a403cd7752c @ git://anongit.freedesktop.org/gfx-ci/linux IGTPW_2536: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2536/ IGT_4863: 0f0db14e7f4ec41251ca156d7cb5b8d531a38006 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12333: 98d4aa8a20097a91231f84d253d460a6f4449924 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 98d4aa8a2009 drm/atomic: -EACCESS for lease-denied crtc lookup 46403901d6fd drm/atomic: Wire file_priv through for property changes 073f93fd49d9 drm/lease: Make sure implicit planes are leased 132428fce909 drm/lease: Check for lessor outside of locks 362dec242f50 drm/leases: Don't init to 0 in drm_master_create 4681bff40cf6 drm/lease: Drop recursive leads checks cd9ef7832c15 drm/leases: Drop object_id validation for negative ids == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12333/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 4/5] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout
On 21/02/2019 02:58, Carlos Santa wrote:
From: Michel Thierry
Final enablement patch for GPU hang detection using watchdog timeout.
Using the gem_context_setparam ioctl, users can specify the desired
timeout value in microseconds, and the driver will do the conversion to
'timestamps'.
The recommended default watchdog threshold for video engines is 6 us,
since this has been _empirically determined_ to be a good compromise for
low-latency requirements and low rate of false positives. The default
register value is ~106000us and the theoretical max value (all 1s) is
353 seconds.
[1]
http://patchwork.freedesktop.org/patch/msgid/20170329135831.30254-2-ch...@chris-wilson.co.uk
v2: Fixed get api to return values in microseconds. Threshold updated to
be per context engine. Check for u32 overflow. Capture ctx threshold
value in error state.
v3: Add a way to get array size, short-cut to disable all thresholds,
return EFAULT / EINVAL as needed. Move the capture of the threshold
value in the error state into a new patch. BXT has a different
timestamp base (because why not?).
v4: Checking if watchdog is available should be the first thing to
do, instead of giving false hopes to abi users; remove unnecessary & in
set_watchdog; ignore args->size in getparam.
v5: GEN9-LP platforms have a different crystal clock frequency, use the
right timestamp base for them (magic 8-ball predicts this will change
again later on, so future-proof it). (Daniele)
v6: Rebase, no more mutex BLK in getparam_ioctl.
v7: use to_intel_context instead of ctx->engine.
v8: Rebase, remove extra mutex from i915_gem_context_set_watchdog (Tvrtko),
Update UAPI to use engine class while keeping thresholds per
engine class (Michel).
v9: Rebase,
Remove outdated comment from the commit message (Tvrtko)
Use the engine->flag to verify for gpu watchdog support (Tvrtko)
Use the standard copy_to_user() instead (Tvrtko)
Use the correct type when declaring engine class iterator (Tvrtko)
Remove yet another unncessary mutex_lock (Tvrtko)
Cc: Antonio Argenziano
Cc: Tvrtko Ursulin
Cc: Daniele Ceraolo Spurio
Signed-off-by: Michel Thierry
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_drv.h | 50 +-
drivers/gpu/drm/i915/i915_gem_context.c | 91 +
include/uapi/drm/i915_drm.h | 1 +
3 files changed, 141 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0fcb2df869a2..aaa5810ba76c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1582,6 +1582,9 @@ struct drm_i915_private {
struct drm_i915_fence_reg fence_regs[I915_MAX_NUM_FENCES]; /* assume
965 */
int num_fence_regs; /* 8 on pre-965, 16 otherwise */
+ /* Command stream timestamp base - helps define watchdog threshold */
+ u32 cs_timestamp_base;
+
unsigned int fsb_freq, mem_freq, is_ddr3;
unsigned int skl_preferred_vco_freq;
unsigned int max_cdclk_freq;
@@ -3120,10 +3123,55 @@ i915_gem_context_lookup(struct drm_i915_file_private
*file_priv, u32 id)
return ctx;
}
+/*
+ * BDW, CHV & SKL+ Timestamp timer resolution = 0.080 uSec,
+ * or 1250 counts per second, or ~12 counts per microsecond.
+ *
+ * But BXT/GLK Timestamp timer resolution is different, 0.052 uSec,
+ * or 1920 counts per second, or ~19 counts per microsecond.
+ *
+ * Future-proofing, some day it won't be as simple as just GEN & IS_LP.
+ */
+#define GEN8_TIMESTAMP_CNTS_PER_USEC 12
+#define GEN9_LP_TIMESTAMP_CNTS_PER_USEC 19
+static inline u32 cs_timestamp_in_us(struct drm_i915_private *dev_priv)
Probably let the compiler decide on the inline.
And s/dev_priv/i915/ is preferred in the GEM areas unless there are
pesky I915_READ/WRITE around.
+{
+ u32 cs_timestamp_base = dev_priv->cs_timestamp_base;
+
+ if (cs_timestamp_base)
+ return cs_timestamp_base;
+
+ switch (INTEL_GEN(dev_priv)) {
+ default:
+ MISSING_CASE(INTEL_GEN(dev_priv));
+ /* fall through */
+ case 9:
+ cs_timestamp_base = IS_GEN9_LP(dev_priv) ?
+ GEN9_LP_TIMESTAMP_CNTS_PER_USEC :
+ GEN8_TIMESTAMP_CNTS_PER_USEC;
+ break;
+ case 8:
+ cs_timestamp_base = GEN8_TIMESTAMP_CNTS_PER_USEC;
+ break;
+ }
+
+ dev_priv->cs_timestamp_base = cs_timestamp_base;
+ return cs_timestamp_base;
+}
+
+static inline u32
+watchdog_to_us(struct drm_i915_private *dev_priv, u32 value_in_clock_counts)
Drop the inline as well.
+{
+ return value_in_clock_counts / cs_timestamp_in_us(dev_priv);
+}
+
static inline u32
watchdog_to_clock_counts(struct drm_i915_private *dev_priv, u64 value_in_us)
Here as well.
u32 for value_in_us should be enough according to the caller.
{
- u64 threshold =
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm: Slightly quieten bad EDID messages
== Series Details ==
Series: drm: Slightly quieten bad EDID messages
URL : https://patchwork.freedesktop.org/series/57343/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5674_full -> Patchwork_12330_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12330_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12330_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_12330_full:
### IGT changes ###
Possible regressions
* igt@kms_flip@flip-vs-suspend:
- shard-kbl: PASS -> DMESG-WARN
Known issues
Here are the changes found in Patchwork_12330_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_pwrite@stolen-normal:
- shard-skl: NOTRUN -> SKIP [fdo#109271] +82
* igt@kms_busy@basic-flip-d:
- shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +9
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-kbl: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_cursor_crc@cursor-128x42-onscreen:
- shard-apl: PASS -> FAIL [fdo#103232] +4
* igt@kms_flip@2x-blocking-absolute-wf_vblank-interruptible:
- shard-apl: NOTRUN -> SKIP [fdo#109271] +12
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-apl: NOTRUN -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
- shard-apl: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc:
- shard-glk: PASS -> FAIL [fdo#103167] +2
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-mmap-cpu:
- shard-skl: NOTRUN -> FAIL [fdo#103167]
* igt@kms_plane@pixel-format-pipe-b-planes:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#106885]
* igt@kms_plane_alpha_blend@pipe-a-alpha-basic:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-skl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-apl: PASS -> FAIL [fdo#103166] +2
* igt@kms_universal_plane@disable-primary-vs-flip-pipe-f:
- shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +9
* igt@perf_pmu@busy-check-all-vecs0:
- shard-snb: NOTRUN -> SKIP [fdo#109271] +87
Possible fixes
* igt@gem_eio@in-flight-suspend:
- shard-snb: FAIL [fdo#103375] -> PASS
* igt@i915_pm_rpm@universal-planes-dpms:
- shard-skl: INCOMPLETE [fdo#107807] -> PASS
* igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
- shard-apl: FAIL [fdo#109660] -> PASS
* igt@kms_chv_cursor_fail@pipe-c-128x128-top-edge:
- shard-hsw: DMESG-WARN [fdo#102614] -> PASS +1
* igt@kms_cursor_crc@cursor-128x128-offscreen:
- shard-skl: FAIL [fdo#103232] -> PASS
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_cursor_crc@cursor-128x128-random:
- shard-apl: FAIL [fdo#103232] -> PASS +1
* igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-ytiled:
- shard-skl: FAIL [fdo#103184] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-apl: FAIL [fdo#103167] -> PASS +1
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-mmap-cpu:
- shard-skl: FAIL [fdo#103167] -> PASS +4
* igt@kms_plane@pixel-format-pipe-c-planes-source-clamping:
- shard-apl: FAIL [fdo#108948] -> PASS
* igt@kms_plane@plane-position-covered-pipe-a-planes:
- shard-apl: FAIL [fdo#103166] -> PASS
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: FAIL [fdo#107815] -> PASS
* igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-glk: FAIL [fdo#103166] -> PASS
* igt@kms_setmode@basic:
- shard-hsw: FAIL [fdo#99912] -> PASS
* igt@kms_vblank@pipe-b-ts-continuation-suspend:
- shard-snb: INCOMPLETE [fdo#105411] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103184]: https://bugs.freedesktop.org/show_bug.cgi?id=103184
[fdo#103232]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for some cleanups and uapi clarification for leases
== Series Details == Series: some cleanups and uapi clarification for leases URL : https://patchwork.freedesktop.org/series/57354/ State : warning == Summary == $ dim checkpatch origin/drm-tip cd9ef7832c15 drm/leases: Drop object_id validation for negative ids -:32: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 11 lines checked 4681bff40cf6 drm/lease: Drop recursive leads checks -:27: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 8 lines checked 362dec242f50 drm/leases: Don't init to 0 in drm_master_create 132428fce909 drm/lease: Check for lessor outside of locks 073f93fd49d9 drm/lease: Make sure implicit planes are leased -:60: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 30 lines checked 46403901d6fd drm/atomic: Wire file_priv through for property changes -:36: WARNING:LINE_SPACING: Missing a blank line after declarations #36: FILE: drivers/gpu/drm/drm_atomic_uapi.c:525: + struct drm_framebuffer *fb; + fb = drm_framebuffer_lookup(dev, file_priv, val); -:75: WARNING:LINE_SPACING: Missing a blank line after declarations #75: FILE: drivers/gpu/drm/drm_atomic_uapi.c:755: + int ret; + fb = drm_framebuffer_lookup(dev, file_priv, val); -:160: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 3 warnings, 0 checks, 121 lines checked 98d4aa8a2009 drm/atomic: -EACCESS for lease-denied crtc lookup -:37: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 16 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Use intel_engine_stop_cs when stopping ringbuffer (rev2)
== Series Details == Series: series starting with [1/3] drm/i915: Use intel_engine_stop_cs when stopping ringbuffer (rev2) URL : https://patchwork.freedesktop.org/series/57352/ State : success == Summary == CI Bug Log - changes from CI_DRM_5674 -> Patchwork_12332 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/57352/revisions/2/mbox/ Known issues Here are the changes found in Patchwork_12332 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-compute: - fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094] * igt@gem_exec_suspend@basic-s3: - fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718] * igt@i915_pm_rpm@module-reload: - fi-skl-6770hq: PASS -> FAIL [fdo#108511] * igt@i915_selftest@live_execlists: - fi-apl-guc: PASS -> INCOMPLETE [fdo#103927] / [fdo#109720] * igt@runner@aborted: - fi-apl-guc: NOTRUN -> FAIL [fdo#108622] / [fdo#109720] / [fdo#109799] Possible fixes * igt@amdgpu/amd_basic@userptr: - fi-kbl-8809g: DMESG-WARN [fdo#108965] -> PASS * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: - fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094 [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511 [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622 [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965 [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 [fdo#109799]: https://bugs.freedesktop.org/show_bug.cgi?id=109799 Participating hosts (44 -> 39) -- Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 Build changes - * Linux: CI_DRM_5674 -> Patchwork_12332 CI_DRM_5674: 71bb3bfb61fb58f93f8b09e6ad576a403cd7752c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4863: 0f0db14e7f4ec41251ca156d7cb5b8d531a38006 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12332: 6304b6caa2e3282ea6bd67138911d4a7c2c24815 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 6304b6caa2e3 drm/i915: Disable PSMI idle messaging when stopping ring d35a973d87dd drm/i915: Introduce intel_engine_stop_ringbuffer 869ff2bfc80a drm/i915: Use intel_engine_stop_cs when stopping ringbuffer == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12332/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 4/6] drm/i915/crc: Make IPS workaround generic
On Thu, Feb 28, 2019 at 06:56:48PM +0200, Ville Syrjälä wrote: > On Wed, Feb 27, 2019 at 05:32:57PM -0800, José Roberto de Souza wrote: > > Other features like PSR2 also needs to be disabled while getting CRC > > so lets rename ips_force_disable to crc_enabled, drop all this checks > > for pipe A and HSW and BDW and make it generic and > > hsw_compute_ips_config() will take care of all the checks removed > > from here. > > > > Cc: Dhinakaran Pandiyan > > Cc: Ville Syrjälä > > Signed-off-by: José Roberto de Souza > > --- > > drivers/gpu/drm/i915/intel_display.c | 10 +-- > > drivers/gpu/drm/i915/intel_drv.h | 3 +- > > drivers/gpu/drm/i915/intel_pipe_crc.c | 42 +-- > > 3 files changed, 24 insertions(+), 31 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > b/drivers/gpu/drm/i915/intel_display.c > > index 816e8f124b3b..328967c642b3 100644 > > --- a/drivers/gpu/drm/i915/intel_display.c > > +++ b/drivers/gpu/drm/i915/intel_display.c > > @@ -6751,7 +6751,13 @@ static bool hsw_compute_ips_config(struct > > intel_crtc_state *crtc_state) > > if (!hsw_crtc_state_ips_capable(crtc_state)) > > return false; > > > > - if (crtc_state->ips_force_disable) > > + /* > > +* When IPS gets enabled, the pipe CRC changes. Since IPS gets > > +* enabled and disabled dynamically based on package C states, > > +* user space can't make reliable use of the CRCs, so let's just > > +* completely disable it. > > +*/ > > + if (crtc_state->crc_enabled) > > return false; > > Hmm. I was wondering how we even manage to pass the state checker with > the current code. But apparently we don't have state checking for IPS. > I would suggest moving this into hsw_compute_ips_config() and then > adding the state checker (for HSW only though since BDW can't do the > readout). And of course this _is_ hsw_compute_ips_config(). Not sure what code I was reading. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Use intel_engine_stop_cs when stopping ringbuffer
== Series Details ==
Series: series starting with [1/3] drm/i915: Use intel_engine_stop_cs when
stopping ringbuffer
URL : https://patchwork.freedesktop.org/series/57352/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5674 -> Patchwork_12331
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/57352/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12331 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@i915_selftest@live_execlists:
- fi-apl-guc: PASS -> INCOMPLETE [fdo#103927] / [fdo#109720]
* igt@kms_chamelium@hdmi-edid-read:
- fi-hsw-peppy: NOTRUN -> SKIP [fdo#109271] +46
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: NOTRUN -> DMESG-FAIL [fdo#102614] / [fdo#107814]
* igt@runner@aborted:
- fi-apl-guc: NOTRUN -> FAIL [fdo#108622] / [fdo#109720] /
[fdo#109799]
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: DMESG-WARN [fdo#108965] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107814]: https://bugs.freedesktop.org/show_bug.cgi?id=107814
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720
[fdo#109779]: https://bugs.freedesktop.org/show_bug.cgi?id=109779
[fdo#109799]: https://bugs.freedesktop.org/show_bug.cgi?id=109799
Participating hosts (44 -> 41)
--
Additional (2): fi-icl-y fi-hsw-peppy
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600
Build changes
-
* Linux: CI_DRM_5674 -> Patchwork_12331
CI_DRM_5674: 71bb3bfb61fb58f93f8b09e6ad576a403cd7752c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4863: 0f0db14e7f4ec41251ca156d7cb5b8d531a38006 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12331: 246c9a8ebbc1cfbb6374c1ebf310f30706593b5e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
246c9a8ebbc1 drm/i915: Disable PSMI idle messaging when stopping ring
994f53ea5eff drm/i915: Introduce intel_engine_stop_ringbuffer
c408614e8a4c drm/i915: Use intel_engine_stop_cs when stopping ringbuffer
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12331/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/7] drm/atomic: Wire file_priv through for property changes
We need this to make sure lessees can only connect their
plane/connectors to crtc objects they own. And note that this is
irrespective of whether the lessor is atomic or not, lessor cannot
prevent lessees from enabling atomic.
Cc: sta...@vger.kernel.org
Cc: Keith Packard
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_uapi.c | 32 +++-
drivers/gpu/drm/drm_crtc_internal.h | 1 +
drivers/gpu/drm/drm_mode_object.c | 5 +++--
3 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 4eb81f10bc54..f0dbfeb00926 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -512,8 +512,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
}
static int drm_atomic_plane_set_property(struct drm_plane *plane,
- struct drm_plane_state *state, struct drm_property *property,
- uint64_t val)
+ struct drm_plane_state *state, struct drm_file *file_priv,
+ struct drm_property *property, uint64_t val)
{
struct drm_device *dev = plane->dev;
struct drm_mode_config *config = >mode_config;
@@ -521,7 +521,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
int ret;
if (property == config->prop_fb_id) {
- struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL,
val);
+ struct drm_framebuffer *fb;
+ fb = drm_framebuffer_lookup(dev, file_priv, val);
drm_atomic_set_fb_for_plane(state, fb);
if (fb)
drm_framebuffer_put(fb);
@@ -537,7 +538,7 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
return -EINVAL;
} else if (property == config->prop_crtc_id) {
- struct drm_crtc *crtc = drm_crtc_find(dev, NULL, val);
+ struct drm_crtc *crtc = drm_crtc_find(dev, file_priv, val);
return drm_atomic_set_crtc_for_plane(state, crtc);
} else if (property == config->prop_crtc_x) {
state->crtc_x = U642I64(val);
@@ -681,14 +682,14 @@ static int drm_atomic_set_writeback_fb_for_connector(
}
static int drm_atomic_connector_set_property(struct drm_connector *connector,
- struct drm_connector_state *state, struct drm_property
*property,
- uint64_t val)
+ struct drm_connector_state *state, struct drm_file *file_priv,
+ struct drm_property *property, uint64_t val)
{
struct drm_device *dev = connector->dev;
struct drm_mode_config *config = >mode_config;
if (property == config->prop_crtc_id) {
- struct drm_crtc *crtc = drm_crtc_find(dev, NULL, val);
+ struct drm_crtc *crtc = drm_crtc_find(dev, file_priv, val);
return drm_atomic_set_crtc_for_connector(state, crtc);
} else if (property == config->dpms_property) {
/* setting DPMS property requires special handling, which
@@ -749,8 +750,10 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
} else if (property == connector->colorspace_property) {
state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
- struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL,
val);
- int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
+ struct drm_framebuffer *fb;
+ int ret;
+ fb = drm_framebuffer_lookup(dev, file_priv, val);
+ ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
if (fb)
drm_framebuffer_put(fb);
return ret;
@@ -947,6 +950,7 @@ int drm_atomic_connector_commit_dpms(struct
drm_atomic_state *state,
}
int drm_atomic_set_property(struct drm_atomic_state *state,
+ struct drm_file *file_priv,
struct drm_mode_object *obj,
struct drm_property *prop,
uint64_t prop_value)
@@ -969,7 +973,8 @@ int drm_atomic_set_property(struct drm_atomic_state *state,
}
ret = drm_atomic_connector_set_property(connector,
- connector_state, prop, prop_value);
+ connector_state, file_priv,
+ prop, prop_value);
break;
}
case DRM_MODE_OBJECT_CRTC: {
@@ -997,7 +1002,8 @@ int drm_atomic_set_property(struct drm_atomic_state *state,
}
ret = drm_atomic_plane_set_property(plane,
- plane_state, prop, prop_value);
+ plane_state, file_priv,
+ prop, prop_value);
[Intel-gfx] [PATCH 7/7] drm/atomic: -EACCESS for lease-denied crtc lookup
With the previous patch drm_crtc_find will return NULL when the crtc
isn't in our lease, which will then disable the plane/connector. No
longer an issue since the lessor can't escape their lease terms
anymore, but not quite great semantics yet either.
Catch this and return -EACCES, so that at least evil test cases have a
better chance of making sure the kernel works correctly.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index f0dbfeb00926..6687215cc188 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -539,6 +539,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
} else if (property == config->prop_crtc_id) {
struct drm_crtc *crtc = drm_crtc_find(dev, file_priv, val);
+ if (val && !crtc)
+ return -EACCES;
return drm_atomic_set_crtc_for_plane(state, crtc);
} else if (property == config->prop_crtc_x) {
state->crtc_x = U642I64(val);
@@ -690,6 +692,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
if (property == config->prop_crtc_id) {
struct drm_crtc *crtc = drm_crtc_find(dev, file_priv, val);
+ if (val && !crtc)
+ return -EACCES;
return drm_atomic_set_crtc_for_connector(state, crtc);
} else if (property == config->dpms_property) {
/* setting DPMS property requires special handling, which
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use intel_engine_stop_cs when stopping ringbuffer
Quoting Mika Kuoppala (2019-02-28 16:53:46)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2019-02-28 16:14:11)
> >> We have an exported function for stopping the engine before
> >> disabling a ringbuffer. Take it into use.
> >>
> >> v2: use fw on empty check
> >> v3: tail is tail
> >>
> >> Cc: Chris Wilson
> >> Signed-off-by: Mika Kuoppala
> >> Reviewed-by: Chris Wilson
> >> ---
> >> drivers/gpu/drm/i915/intel_engine_cs.c | 3 ++
> >> drivers/gpu/drm/i915/intel_ringbuffer.c | 41 ++---
> >> 2 files changed, 26 insertions(+), 18 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> >> b/drivers/gpu/drm/i915/intel_engine_cs.c
> >> index df8f88142f1d..e35dc0386bf6 100644
> >> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> >> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> >> @@ -856,6 +856,9 @@ void intel_engine_cancel_stop_cs(struct
> >> intel_engine_cs *engine)
> >> {
> >> struct drm_i915_private *dev_priv = engine->i915;
> >>
> >> + if (INTEL_GEN(dev_priv) < 3)
> >> + return;
> >> +
> >> GEM_TRACE("%s\n", engine->name);
> >>
> >> I915_WRITE_FW(RING_MI_MODE(engine->mmio_base),
> >> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> >> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> >> index 1b96b0960adc..5fe28d9087b7 100644
> >> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> >> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> >> @@ -604,26 +604,32 @@ static void ring_setup_status_page(struct
> >> intel_engine_cs *engine)
> >> flush_cs_tlb(engine);
> >> }
> >>
> >> +static bool ring_is_empty(struct intel_engine_cs *engine)
> >> +{
> >> + struct drm_i915_private *dev_priv = engine->i915;
> >> + const u32 base = engine->mmio_base;
> >> +
> >> + return (I915_READ_FW(RING_HEAD(base)) & HEAD_ADDR) ==
> >> + (I915_READ_FW(RING_TAIL(base)) & TAIL_ADDR);
> >> +}
> >> +
> >> static bool stop_ring(struct intel_engine_cs *engine)
> >> {
> >> struct drm_i915_private *dev_priv = engine->i915;
> >> + int ret;
> >>
> >> - if (INTEL_GEN(dev_priv) > 2) {
> >> - I915_WRITE_MODE(engine, _MASKED_BIT_ENABLE(STOP_RING));
> >> - if (intel_wait_for_register(dev_priv,
> >> -
> >> RING_MI_MODE(engine->mmio_base),
> >> - MODE_IDLE,
> >> - MODE_IDLE,
> >> - 1000)) {
> >> - DRM_ERROR("%s : timed out trying to stop ring\n",
> >> - engine->name);
> >> - /* Sometimes we observe that the idle flag is not
> >> -* set even though the ring is empty. So double
> >> -* check before giving up.
> >> -*/
> >> - if (I915_READ_HEAD(engine) !=
> >> I915_READ_TAIL(engine))
> >> - return false;
> >> - }
> >> + ret = intel_engine_stop_cs(engine);
> >> + if (ret == -ENODEV)
> >> + ret = 0;
> >> +
> >> + if (ret) {
> >> + /*
> >> +* Sometimes we observe that the idle flag is not
> >> +* set even though the ring is empty. So double
> >> +* check before giving up.
> >> +*/
> >> + if (!ring_is_empty(engine))
> >> + return false;
> >
> > Hmm, thinking more about this, shouldn't we push this down to stop_cs()?
> >
> > If that's reporting an error in a situation where we can determine that
> > the ring is idle anyway, we can report the stop_cs succeeded.
>
> Makes sense, I will take a look.
>
> I felt small urge to deflate the 'stop'.
>
> Would it be confusing if we just did
> intel_engine_start|stop instead of stop_cs and
> cancel_stop_cs?
>
> So hmm:
>
> intel_engine_start()
> intel_engine_stop()
>
> these would only toggle the STOP_RING
>
> and for replacing stop_ring with:
> intel_engine_empty_ring()
intel_engine_clear_ring() / reset_ring(). Hmm, clear_ring of those two.
>
> for zeroing the heads.
>
> one 'stop' to rule the (ring)world!?
The counter argument is that _start() is a little too broad. The appeal
of stop_cs() is that it describing what it is doing, poking at the bit
to stop the CS advancing and nothing more. It frequently doesn't
succeed...
So I think it's not a worthy change, but I never did feel totally
satisfied with stop_cs -- cs is too short, but we do have usage with
xCS.
intel_engine_stop_command_streamer,
intel_engine_halt_command_streamer,
intel_engine_pause_command_streamer,
?
But intel_engine_clear_ring() I could be sold on.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/7] drm/lease: Make sure implicit planes are leased
If userspace doesn't enable universal planes, then we automatically
add the primary and cursor planes. But for universal userspace there's
no such check (and maybe we only want to give the lessee one plane,
maybe not even the primary one), hence we need to check for the
implied plane.
v2: don't forget setcrtc ioctl.
v3: Still allow disabling of the crtc in SETCRTC.
Cc: sta...@vger.kernel.org
Cc: Keith Packard
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 4
drivers/gpu/drm/drm_plane.c | 8
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 7dabbaf033a1..790ba5941954 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -559,6 +559,10 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
plane = crtc->primary;
+ /* allow disabling with the primary plane leased */
+ if (crtc_req->mode_valid && !drm_lease_held(file_priv, plane->base.id))
+ return -EACCES;
+
mutex_lock(>dev->mode_config.mutex);
DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx,
DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 4cfb56893b7f..d6ad60ab0d38 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -960,6 +960,11 @@ static int drm_mode_cursor_common(struct drm_device *dev,
if (ret)
goto out;
+ if (!drm_lease_held(file_priv, crtc->cursor->base.id)) {
+ ret = -EACCES;
+ goto out;
+ }
+
ret = drm_mode_cursor_universal(crtc, req, file_priv, );
goto out;
}
@@ -1062,6 +1067,9 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
plane = crtc->primary;
+ if (!drm_lease_held(file_priv, plane->base.id))
+ return -EACCES;
+
if (crtc->funcs->page_flip_target) {
u32 current_vblank;
int r;
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] drm/leases: Don't init to 0 in drm_master_create
We kzalloc. Cc: Keith Packard Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_auth.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c index 1669c42c40ed..bcf0a5a1018f 100644 --- a/drivers/gpu/drm/drm_auth.c +++ b/drivers/gpu/drm/drm_auth.c @@ -109,8 +109,6 @@ struct drm_master *drm_master_create(struct drm_device *dev) master->dev = dev; /* initialize the tree of output resource lessees */ - master->lessor = NULL; - master->lessee_id = 0; INIT_LIST_HEAD(>lessees); INIT_LIST_HEAD(>lessee_list); idr_init(>leases); -- 2.14.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] drm/lease: Drop recursive leads checks
We disallow subleasing, so no point checking whether the master holds all the leases - it will. Spotted while typing exhaustive igt coverage for all these corner cases. Cc: Keith Packard Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_lease.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c index 1176d814cf7f..cce5d9dd52ff 100644 --- a/drivers/gpu/drm/drm_lease.c +++ b/drivers/gpu/drm/drm_lease.c @@ -220,8 +220,6 @@ static struct drm_master *drm_lease_create(struct drm_master *lessor, struct idr error = 0; if (!idr_find(>mode_config.object_idr, object)) error = -ENOENT; - else if (!_drm_lease_held_master(lessor, object)) - error = -EACCES; else if (_drm_has_leased(lessor, object)) error = -EBUSY; -- 2.14.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/7] drm/lease: Check for lessor outside of locks
The lessor is invariant over a lifetime of a lease, we don't have to
grab any locks for that. Speeds up the common case of not being a lease.
Cc: Keith Packard
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_lease.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index cce5d9dd52ff..694ff363a90b 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -111,7 +111,7 @@ static bool _drm_has_leased(struct drm_master *master, int
id)
*/
bool _drm_lease_held(struct drm_file *file_priv, int id)
{
- if (file_priv == NULL || file_priv->master == NULL)
+ if (!file_priv || !file_priv->master)
return true;
return _drm_lease_held_master(file_priv->master, id);
@@ -133,7 +133,7 @@ bool drm_lease_held(struct drm_file *file_priv, int id)
struct drm_master *master;
bool ret;
- if (file_priv == NULL || file_priv->master == NULL)
+ if (!file_priv || !file_priv->master || !file_priv->master->lessor)
return true;
master = file_priv->master;
@@ -159,7 +159,7 @@ uint32_t drm_lease_filter_crtcs(struct drm_file *file_priv,
uint32_t crtcs_in)
int count_in, count_out;
uint32_t crtcs_out = 0;
- if (file_priv == NULL || file_priv->master == NULL)
+ if (!file_priv || !file_priv->master || !file_priv->master->lessor)
return crtcs_in;
master = file_priv->master;
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/7] some cleanups and uapi clarification for leases
[resend with the right mailing lists] Hi all, Nothing too major, only things I did find in all my igt test extending for drm lease is some corner cases around implicit planes and atomic target crtcs. Review and comments very much appreciated. Cheers, Daniel Test-with: 20190228141918.26043-1-daniel.vet...@ffwll.ch Daniel Vetter (7): drm/leases: Drop object_id validation for negative ids drm/lease: Drop recursive leads checks drm/leases: Don't init to 0 in drm_master_create drm/lease: Check for lessor outside of locks drm/lease: Make sure implicit planes are leased drm/atomic: Wire file_priv through for property changes drm/atomic: -EACCESS for lease-denied crtc lookup drivers/gpu/drm/drm_atomic_uapi.c | 36 +++- drivers/gpu/drm/drm_auth.c | 2 -- drivers/gpu/drm/drm_crtc.c | 4 drivers/gpu/drm/drm_crtc_internal.h | 1 + drivers/gpu/drm/drm_lease.c | 13 +++-- drivers/gpu/drm/drm_mode_object.c | 5 +++-- drivers/gpu/drm/drm_plane.c | 8 7 files changed, 42 insertions(+), 27 deletions(-) -- 2.14.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/7] drm/leases: Drop object_id validation for negative ids
Not exactly sure what's the aim here, but the canonical nil object has
id == 0, we don't use negative object ids for anything. Plus all
object_id are valided by the object_idr, there's nothing we need to do
on top of that ENOENT check a bit further down.
Spotted while typing exhaustive igt coverage for all these
corner-cases.
Cc: Keith Packard
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_lease.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 603b0bd9c5ce..1176d814cf7f 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -403,11 +403,6 @@ static int fill_object_idr(struct drm_device *dev,
/* step one - get references to all the mode objects
and check for validity. */
for (o = 0; o < object_count; o++) {
- if ((int) object_ids[o] < 0) {
- ret = -EINVAL;
- goto out_free_objects;
- }
-
objects[o] = drm_mode_object_find(dev, lessor_priv,
object_ids[o],
DRM_MODE_OBJECT_ANY);
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 5/6] drm/i915: Disable PSR2 while getting pipe CRC
On Wed, Feb 27, 2019 at 05:32:58PM -0800, José Roberto de Souza wrote:
> When PSR2 is active aka after the number of frames programmed in
> PSR2_CTL 'Frames Before SU Entry' hardware stops to generate CRC
> interruptions causing IGT tests to fail due timeout.
>
> Oddly that don't happen when PSR1 active, so here it switches from
> PSR2 to PSR1 while user is requesting pipe CRC.
>
> Force setting mode_changed as true is necessary to atomic checks
> functions compute new PSR state, that is why it was added to
> intel_crtc_crc_prepare().
>
> v3: Reusing intel_crtc_crc_prepare() and crc_enabled
>
> v2: Changed commit description to describe that PSR2 inhibit CRC
> calculations.
>
> Cc: Dhinakaran Pandiyan
> Cc: Ville Syrjälä
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_pipe_crc.c | 1 +
> drivers/gpu/drm/i915/intel_psr.c | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> b/drivers/gpu/drm/i915/intel_pipe_crc.c
> index f6d0b2aaffe2..e7ac24c33650 100644
> --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> @@ -308,6 +308,7 @@ intel_crtc_crc_prepare(struct drm_i915_private *dev_priv,
> struct drm_crtc *crtc,
> goto put_state;
> }
>
> + pipe_config->base.mode_changed = pipe_config->crc_enabled != enable;
Do we really want to set that unconditionally?
> pipe_config->crc_enabled = enable;
>
> if (IS_HASWELL(dev_priv) && intel_crtc->pipe == PIPE_A) {
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 6175b1d2e0c8..f7730b8b2ec0 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -572,6 +572,9 @@ static bool intel_psr2_config_valid(struct intel_dp
> *intel_dp,
> return false;
> }
>
> + if (crtc_state->crc_enabled)
> + return false;
> +
> return true;
> }
>
> --
> 2.21.0
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 4/6] drm/i915/crc: Make IPS workaround generic
On Wed, Feb 27, 2019 at 05:32:57PM -0800, José Roberto de Souza wrote:
> Other features like PSR2 also needs to be disabled while getting CRC
> so lets rename ips_force_disable to crc_enabled, drop all this checks
> for pipe A and HSW and BDW and make it generic and
> hsw_compute_ips_config() will take care of all the checks removed
> from here.
>
> Cc: Dhinakaran Pandiyan
> Cc: Ville Syrjälä
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_display.c | 10 +--
> drivers/gpu/drm/i915/intel_drv.h | 3 +-
> drivers/gpu/drm/i915/intel_pipe_crc.c | 42 +--
> 3 files changed, 24 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 816e8f124b3b..328967c642b3 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6751,7 +6751,13 @@ static bool hsw_compute_ips_config(struct
> intel_crtc_state *crtc_state)
> if (!hsw_crtc_state_ips_capable(crtc_state))
> return false;
>
> - if (crtc_state->ips_force_disable)
> + /*
> + * When IPS gets enabled, the pipe CRC changes. Since IPS gets
> + * enabled and disabled dynamically based on package C states,
> + * user space can't make reliable use of the CRCs, so let's just
> + * completely disable it.
> + */
> + if (crtc_state->crc_enabled)
> return false;
Hmm. I was wondering how we even manage to pass the state checker with
the current code. But apparently we don't have state checking for IPS.
I would suggest moving this into hsw_compute_ips_config() and then
adding the state checker (for HSW only though since BDW can't do the
readout).
>
> /* IPS should be fine as long as at least one plane is enabled. */
> @@ -11684,7 +11690,7 @@ clear_intel_crtc_state(struct intel_crtc_state
> *crtc_state)
> saved_state->shared_dpll = crtc_state->shared_dpll;
> saved_state->dpll_hw_state = crtc_state->dpll_hw_state;
> saved_state->pch_pfit.force_thru = crtc_state->pch_pfit.force_thru;
> - saved_state->ips_force_disable = crtc_state->ips_force_disable;
> + saved_state->crc_enabled = crtc_state->crc_enabled;
> if (IS_G4X(dev_priv) ||
> IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> saved_state->wm = crtc_state->wm;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 5412373e2f98..2be64529e4a2 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -999,7 +999,8 @@ struct intel_crtc_state {
> struct intel_link_m_n fdi_m_n;
>
> bool ips_enabled;
> - bool ips_force_disable;
> +
> + bool crc_enabled;
>
> bool enable_fbc;
>
> diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> b/drivers/gpu/drm/i915/intel_pipe_crc.c
> index 53d4ec68d3c4..f6d0b2aaffe2 100644
> --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> @@ -280,11 +280,12 @@ static int ilk_pipe_crc_ctl_reg(enum
> intel_pipe_crc_source *source,
> return 0;
> }
>
> -static void hsw_pipe_A_crc_wa(struct drm_i915_private *dev_priv,
> - bool enable)
> +static void
> +intel_crtc_crc_prepare(struct drm_i915_private *dev_priv, struct drm_crtc
> *crtc,
Just pass in the intel_crtc
> +bool enable)
> {
> struct drm_device *dev = _priv->drm;
> - struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, PIPE_A);
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
and then we don't have to have an ugly name for this.
Also pasing in dev_priv is redundant when you're already passing in the
crtc.
The function name isn't super descriptive. It makes me think we're
preparing for CRC capture, when in fact it just adds/removes the w/as.
> struct intel_crtc_state *pipe_config;
> struct drm_atomic_state *state;
> struct drm_modeset_acquire_ctx ctx;
> @@ -301,23 +302,15 @@ static void hsw_pipe_A_crc_wa(struct drm_i915_private
> *dev_priv,
> state->acquire_ctx =
>
> retry:
> - pipe_config = intel_atomic_get_crtc_state(state, crtc);
> + pipe_config = intel_atomic_get_crtc_state(state, intel_crtc);
> if (IS_ERR(pipe_config)) {
> ret = PTR_ERR(pipe_config);
> goto put_state;
> }
>
> - if (HAS_IPS(dev_priv)) {
> - /*
> - * When IPS gets enabled, the pipe CRC changes. Since IPS gets
> - * enabled and disabled dynamically based on package C states,
> - * user space can't make reliable use of the CRCs, so let's just
> - * completely disable it.
> - */
> - pipe_config->ips_force_disable = enable;
> - }
> + pipe_config->crc_enabled = enable;
>
> - if (IS_HASWELL(dev_priv)) {
> + if (IS_HASWELL(dev_priv) &&
Re: [Intel-gfx] [PATCH 0/3] Propagate DP-over-Type-C hotplug events from Type-C subsys to drm-drivers
Hi Heikki, On 28-02-19 15:47, Heikki Krogerus wrote: Hi Hans, On Thu, Feb 28, 2019 at 12:24:25PM +0100, Hans de Goede wrote: Hi, On 28-02-19 10:15, Heikki Krogerus wrote: I've been thinking about this... Do we actually need to link the correct drm_connector to the Type-C connector? Perhaps we can make this work by just linking the GFX device to the Type-C connector. What use is it to the kms driver if it gets an event there is a DP hotplug with x lanes and orientation foo, if we are not telling it on which DP port it is ? kms devices already have multiple DP ports and more then one could be hooked-up to type-c connectors. I was looking at this series. You walk trough every DP port in the system when the DP alt mode driver broadcasts the event, but maybe that's different. Never mind. Right, my "simple / naive" solution simply tells the kms driver to check all DP ports for connection state changes, similar to how running "xrandr" under Xorg causes the kms driver to re-check the connection status of all ports. Actually running xrandr under Xorg after plugging in the cable, is how I did my initial DP over Type-C testing on the GPD win. But once we start passing extra-info, I believe the kms driver needs to know to which connector that info belongs. Well, I don't think we can deny the GPU driver (in this case) the information that we have and that is relevant to it, just because it seems difficult to deliver that information to the right location. Right, but this does not require a tight-coupling. My original proposal can do this if we pass a data struct with an identifier for the DP port for which the event is to the notifier. I suggest using a string for identifier, something like: ":00:02.0/DP-1" this event struct could then also contain all the info we want to pass. I do agree that we should not tie the objects (device entries) representing these components in kernel together, but I assume that we agree now that the connection between the two - the USB Type-C connector and the DisplayPort - must be described somewhere, either in firmware or build-in? So I guess we are talking implementation details here, right? Right. If that is the case... That string identifier you proposed would basically provide the details about the connection, so if we know those details, we might as well use "normal" ways to describe the connection and just extract them in runtime in the function that our DP alt mode driver calls. I think the connection has to be defined in i915 on CHT in any case. Interesting, I think the connection should be described in the fwnode for the fusb302 device for the CHT/GPD win case. Specifically I think this fits well as a property of the dp altmode. The DP alt mode driver should definitely not need to pass anything else to the notifier other than handle to itself (actually, handle straight to the port device would be better) as an identifier. The notifier function needs to be the one that determines the actual connection using that handle. Even if the target DP is described using a string like you propose, then that string has to come from somewhere, most likely from a device property. The notifier function can just as well extract it, we don't need to pass it separately. Here's my suggestion for function prototype: int drm_typec_dp_notification(struct device *typec_port_dev, struct typec_displayport_data *data); How about instead of the port_dev we pass in the altmode object and we have a method to get the fwnode for the altmode? Then the drm_typec_dp_notification() function can get info from that fwnode to implement the connection finding you describe below: So that function finds the connection between typec_port_dev and the correct DP in runtime, possibly by letting i915 (or what ever GPU driver) to do that. Once the function is done, it decrements any ref counts that it incremented before returning. That struct typec_displayport_data has all the information we have - the current pin assignment from the Configure VDO, HPD IRQ from the last Status Update, etc. - so it needs to be passed as payload to the notifier. Ack. So I believe that this discussion ties into the discussion from the: "[PATCH 0/2] platform/x86: intel_cht_int33fe: Start using software nodes" Mail thread. As discussed there I agree that adding a usb_connector child fwnode to the fwnode for the fusb302 to describe things like sink- and source-pdos is a good idea. Our last few mails were discussing describing supported alt-modes on the connector by adding altmode child-nodes to the usb_connector node. I think it is best to continue that discussion here, as the 2 discussions tie into one another. So my last proposal in that thread was adding the following to: Documentation/devicetree/bindings/connector/usb-connector.txt: """ Optionally an "usb-c-connector" can have child nodes, describing supported alt-modes. Required properties for
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use intel_engine_stop_cs when stopping ringbuffer
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-02-28 16:14:11)
>> We have an exported function for stopping the engine before
>> disabling a ringbuffer. Take it into use.
>>
>> v2: use fw on empty check
>> v3: tail is tail
>>
>> Cc: Chris Wilson
>> Signed-off-by: Mika Kuoppala
>> Reviewed-by: Chris Wilson
>> ---
>> drivers/gpu/drm/i915/intel_engine_cs.c | 3 ++
>> drivers/gpu/drm/i915/intel_ringbuffer.c | 41 ++---
>> 2 files changed, 26 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
>> b/drivers/gpu/drm/i915/intel_engine_cs.c
>> index df8f88142f1d..e35dc0386bf6 100644
>> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
>> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
>> @@ -856,6 +856,9 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs
>> *engine)
>> {
>> struct drm_i915_private *dev_priv = engine->i915;
>>
>> + if (INTEL_GEN(dev_priv) < 3)
>> + return;
>> +
>> GEM_TRACE("%s\n", engine->name);
>>
>> I915_WRITE_FW(RING_MI_MODE(engine->mmio_base),
>> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
>> b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> index 1b96b0960adc..5fe28d9087b7 100644
>> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
>> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> @@ -604,26 +604,32 @@ static void ring_setup_status_page(struct
>> intel_engine_cs *engine)
>> flush_cs_tlb(engine);
>> }
>>
>> +static bool ring_is_empty(struct intel_engine_cs *engine)
>> +{
>> + struct drm_i915_private *dev_priv = engine->i915;
>> + const u32 base = engine->mmio_base;
>> +
>> + return (I915_READ_FW(RING_HEAD(base)) & HEAD_ADDR) ==
>> + (I915_READ_FW(RING_TAIL(base)) & TAIL_ADDR);
>> +}
>> +
>> static bool stop_ring(struct intel_engine_cs *engine)
>> {
>> struct drm_i915_private *dev_priv = engine->i915;
>> + int ret;
>>
>> - if (INTEL_GEN(dev_priv) > 2) {
>> - I915_WRITE_MODE(engine, _MASKED_BIT_ENABLE(STOP_RING));
>> - if (intel_wait_for_register(dev_priv,
>> - RING_MI_MODE(engine->mmio_base),
>> - MODE_IDLE,
>> - MODE_IDLE,
>> - 1000)) {
>> - DRM_ERROR("%s : timed out trying to stop ring\n",
>> - engine->name);
>> - /* Sometimes we observe that the idle flag is not
>> -* set even though the ring is empty. So double
>> -* check before giving up.
>> -*/
>> - if (I915_READ_HEAD(engine) != I915_READ_TAIL(engine))
>> - return false;
>> - }
>> + ret = intel_engine_stop_cs(engine);
>> + if (ret == -ENODEV)
>> + ret = 0;
>> +
>> + if (ret) {
>> + /*
>> +* Sometimes we observe that the idle flag is not
>> +* set even though the ring is empty. So double
>> +* check before giving up.
>> +*/
>> + if (!ring_is_empty(engine))
>> + return false;
>
> Hmm, thinking more about this, shouldn't we push this down to stop_cs()?
>
> If that's reporting an error in a situation where we can determine that
> the ring is idle anyway, we can report the stop_cs succeeded.
Makes sense, I will take a look.
I felt small urge to deflate the 'stop'.
Would it be confusing if we just did
intel_engine_start|stop instead of stop_cs and
cancel_stop_cs?
So hmm:
intel_engine_start()
intel_engine_stop()
these would only toggle the STOP_RING
and for replacing stop_ring with:
intel_engine_empty_ring()
for zeroing the heads.
one 'stop' to rule the (ring)world!?
-Mika
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Introduce intel_engine_stop_ringbuffer
Quoting Mika Kuoppala (2019-02-28 16:01:32) > We use identical sequence of stopping ringbuffer on reset > handing and on ring initialization. Make a function > to handle both cases. > > v2: intel_engine_stop_ring, cleaner stop_ring (Chris) > > Cc: Chris Wilson > Signed-off-by: Mika Kuoppala Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/6] drm/i915: Compute and commit color features in fastsets
On Wed, Feb 27, 2019 at 05:32:56PM -0800, José Roberto de Souza wrote:
> In any commit, intel_modeset_pipe_config() will initialilly clear
> and then recalculate most of the pipe states but it leave intel
> specific color features states in reset state.
>
> If after intel_pipe_config_compare() is detected that a fastset is
> possible it will mark update_pipe as true and unsed mode_changed,
> causing the color features state to be kept in reset state and then
> latter being committed to hardware disabling the color features.
>
> This issue can be reproduced by any code patch that duplicates the
> actual(with color features already enabled) state and only mark
> mode_changed as true.
>
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Signed-off-by: José Roberto de Souza
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 7c5e84ef5171..816e8f124b3b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11232,7 +11232,8 @@ static int intel_crtc_atomic_check(struct drm_crtc
> *crtc,
> return ret;
> }
>
> - if (mode_changed || crtc_state->color_mgmt_changed) {
> + if (mode_changed || pipe_config->update_pipe ||
> + crtc_state->color_mgmt_changed) {
> ret = intel_color_check(pipe_config);
> if (ret)
> return ret;
> --
> 2.21.0
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/6] drm/i915/psr: Only lookup for enabled CRTCs when forcing a fastset
On Wed, Feb 27, 2019 at 05:32:55PM -0800, José Roberto de Souza wrote:
> Forcing a specific CRTC to the eDP connector was causing the
> intel_psr_fastset_force() to mark mode_chaged in the wrong and
> disabled CRTC causing no update in the PSR state.
>
> Looks like our internal state track do not clear output_types and
> has_psr in the disabled CRTCs, not sure if this is the expected
> behavior or not but in the mean time this fix the issue.
>
> Cc: Maarten Lankhorst
> Cc: Dhinakaran Pandiyan
> Reviewed-by: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_psr.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 8bed73914876..6175b1d2e0c8 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -981,7 +981,8 @@ static int intel_psr_fastset_force(struct
> drm_i915_private *dev_priv)
>
> intel_crtc_state = to_intel_crtc_state(crtc_state);
>
> - if (intel_crtc_has_type(intel_crtc_state, INTEL_OUTPUT_EDP) &&
> + if (crtc_state->active &&
> + intel_crtc_has_type(intel_crtc_state, INTEL_OUTPUT_EDP) &&
What's the point of that eDP check anyway?
> intel_crtc_state->has_psr) {
> /* Mark mode as changed to trigger a pipe->update() */
> crtc_state->mode_changed = true;
> --
> 2.21.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use intel_engine_stop_cs when stopping ringbuffer
Quoting Mika Kuoppala (2019-02-28 16:14:11)
> We have an exported function for stopping the engine before
> disabling a ringbuffer. Take it into use.
>
> v2: use fw on empty check
> v3: tail is tail
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> Reviewed-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 3 ++
> drivers/gpu/drm/i915/intel_ringbuffer.c | 41 ++---
> 2 files changed, 26 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index df8f88142f1d..e35dc0386bf6 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -856,6 +856,9 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs
> *engine)
> {
> struct drm_i915_private *dev_priv = engine->i915;
>
> + if (INTEL_GEN(dev_priv) < 3)
> + return;
> +
> GEM_TRACE("%s\n", engine->name);
>
> I915_WRITE_FW(RING_MI_MODE(engine->mmio_base),
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 1b96b0960adc..5fe28d9087b7 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -604,26 +604,32 @@ static void ring_setup_status_page(struct
> intel_engine_cs *engine)
> flush_cs_tlb(engine);
> }
>
> +static bool ring_is_empty(struct intel_engine_cs *engine)
> +{
> + struct drm_i915_private *dev_priv = engine->i915;
> + const u32 base = engine->mmio_base;
> +
> + return (I915_READ_FW(RING_HEAD(base)) & HEAD_ADDR) ==
> + (I915_READ_FW(RING_TAIL(base)) & TAIL_ADDR);
> +}
> +
> static bool stop_ring(struct intel_engine_cs *engine)
> {
> struct drm_i915_private *dev_priv = engine->i915;
> + int ret;
>
> - if (INTEL_GEN(dev_priv) > 2) {
> - I915_WRITE_MODE(engine, _MASKED_BIT_ENABLE(STOP_RING));
> - if (intel_wait_for_register(dev_priv,
> - RING_MI_MODE(engine->mmio_base),
> - MODE_IDLE,
> - MODE_IDLE,
> - 1000)) {
> - DRM_ERROR("%s : timed out trying to stop ring\n",
> - engine->name);
> - /* Sometimes we observe that the idle flag is not
> -* set even though the ring is empty. So double
> -* check before giving up.
> -*/
> - if (I915_READ_HEAD(engine) != I915_READ_TAIL(engine))
> - return false;
> - }
> + ret = intel_engine_stop_cs(engine);
> + if (ret == -ENODEV)
> + ret = 0;
> +
> + if (ret) {
> + /*
> +* Sometimes we observe that the idle flag is not
> +* set even though the ring is empty. So double
> +* check before giving up.
> +*/
> + if (!ring_is_empty(engine))
> + return false;
Hmm, thinking more about this, shouldn't we push this down to stop_cs()?
If that's reporting an error in a situation where we can determine that
the ring is idle anyway, we can report the stop_cs succeeded.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Disable PSMI idle messaging when stopping ring
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-02-28 16:01:33)
>> Hardware cannot be in a middle of idle flow messaging
>> when we pull the plug from ringbuffer. Disable idle
>> messaging before we do so to avoid potential deadlock
>> on engine initialization and reset.
>>
>> v2: INVALID_MMIO_REG, unconditional enable (Chris)
>> v3: comment (Chris), bspec reference
>>
>> References: bspec/11751
>> Cc: Chris Wilson
>> Acked-by: Chris Wilson
>> Signed-off-by: Mika Kuoppala
>> ---
>> drivers/gpu/drm/i915/intel_engine_cs.c | 64 +-
>> 1 file changed, 63 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
>> b/drivers/gpu/drm/i915/intel_engine_cs.c
>> index 2a94b92cfcd3..10cb6b22fe92 100644
>> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
>> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
>> @@ -764,7 +764,7 @@ int intel_engine_init_common(struct intel_engine_cs
>> *engine)
>>
>> /**
>> * intel_engines_cleanup_common - cleans up the engine state created by
>> - *the common initiailizers.
>> + *the common initializers.
>> * @engine: Engine to cleanup.
>> *
>> * This cleans up everything created by the common helpers.
>> @@ -865,6 +865,63 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs
>> *engine)
>> _MASKED_BIT_DISABLE(STOP_RING));
>> }
>>
>> +static i915_reg_t get_idle_poll_reg(const struct intel_engine_cs *engine)
>> +{
>> + if (engine->id != RCS)
>> + return INVALID_MMIO_REG;
>> +
>> + if (IS_GEN(engine->i915, 9))
>> + return GEN9_RCS_FE_FSM2;
>> +
>> + if (IS_GEN(engine->i915, 8))
>> + return GEN6_RCS_PWR_FSM;
>> +
>> + return INVALID_MMIO_REG;
>> +}
>> +
>> +static void disable_idle_messaging(struct intel_engine_cs *engine)
>> +{
>> + struct drm_i915_private *dev_priv = engine->i915;
>> + i915_reg_t poll_reg;
>> +
>> + poll_reg = get_idle_poll_reg(engine);
>> + if (!i915_mmio_reg_valid(poll_reg))
>> + return;
>> +
>> + GEM_DEBUG_WARN_ON(I915_READ_FW(GEN6_RC_SLEEP_PSMI_CONTROL) &
>> + GEN6_PSMI_SLEEP_MSG_DISABLE);
>> + /*
>> +* Hardware must not be in middle of idle flow signalling
>> +* when the RING_CTL is zeroed. In order to prevent this
>> +* we disable the messaging temporarily.
>> +*/
>> + I915_WRITE_FW(GEN6_RC_SLEEP_PSMI_CONTROL,
>> + _MASKED_BIT_ENABLE(GEN6_PSMI_SLEEP_MSG_DISABLE));
>> +
>> + /*
>> +* Poll the magic bits to ensure that engine state machine
>> +* is in valid state for stopping the ring.
>> +*/
>> + if (__intel_wait_for_register_fw(dev_priv, poll_reg,
>> +0x7f, 0x30,
>> +5000, 0,
>> +NULL))
>> + DRM_DEBUG_DRIVER("psmi idle msg poll timeout\n");
>> +}
>> +
>> +static void enable_idle_messaging(struct intel_engine_cs *engine)
>> +{
>> + struct drm_i915_private *dev_priv = engine->i915;
>> + i915_reg_t poll_reg;
>> +
>> + poll_reg = get_idle_poll_reg(engine);
>> + if (!i915_mmio_reg_valid(poll_reg))
>> + return;
>> +
>> + I915_WRITE_FW(GEN6_RC_SLEEP_PSMI_CONTROL,
>> + _MASKED_BIT_DISABLE(GEN6_PSMI_SLEEP_MSG_DISABLE));
>> +}
>> +
>> int intel_engine_stop_ring(struct intel_engine_cs *engine)
>> {
>> struct drm_i915_private *dev_priv = engine->i915;
>> @@ -880,9 +937,14 @@ int intel_engine_stop_ring(struct intel_engine_cs
>> *engine)
>> I915_WRITE_FW(RING_TAIL(base), 0);
>> POSTING_READ_FW(RING_TAIL(base));
>>
>> + /* Idle messaging needs to be off during ring disable */
>
> Ok, that's ott :)
Rest assured, Captain Obvious will scrap this before merging.
>
> The previous pair are a nice why, peeling back some of the layers of the
> HW to see what's going on. This one is just repeating
> disable_idle_messing().
There is this dream I had where hardware engineers
did review patches.
But it should be close enough of 'what's going on'
Thanks,
-Mika
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/7] drm/i915: Force GPU idle on suspend
== Series Details == Series: series starting with [1/7] drm/i915: Force GPU idle on suspend URL : https://patchwork.freedesktop.org/series/57340/ State : success == Summary == CI Bug Log - changes from CI_DRM_5673_full -> Patchwork_12327_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12327_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-iclb: NOTRUN -> SKIP [fdo#109313] * igt@gem_exec_params@no-bsd: - shard-iclb: NOTRUN -> SKIP [fdo#109283] * igt@gem_pread@stolen-normal: - shard-skl: NOTRUN -> SKIP [fdo#109271] +105 * igt@i915_pm_backlight@fade_with_suspend: - shard-iclb: NOTRUN -> FAIL [fdo#107847] * igt@i915_pm_rpm@debugfs-forcewake-user: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] * igt@i915_pm_rps@min-max-config-loaded: - shard-iclb: NOTRUN -> FAIL [fdo#102250] * igt@kms_atomic_transition@5x-modeset-transitions-nonblocking: - shard-iclb: NOTRUN -> SKIP [fdo#109278] * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1 * igt@kms_busy@extended-modeset-hang-oldfb-render-f: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +9 * igt@kms_busy@extended-pageflip-hang-newfb-render-f: - shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@kms_chamelium@hdmi-cmp-nv21: - shard-iclb: NOTRUN -> SKIP [fdo#109284] +1 * igt@kms_chamelium@hdmi-crc-fast: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +17 * igt@kms_chamelium@hdmi-crc-xbgr: - shard-apl: NOTRUN -> SKIP [fdo#109271] +2 * igt@kms_chv_cursor_fail@pipe-a-64x64-bottom-edge: - shard-skl: PASS -> FAIL [fdo#104671] * igt@kms_chv_cursor_fail@pipe-c-256x256-right-edge: - shard-skl: NOTRUN -> FAIL [fdo#104671] * igt@kms_cursor_crc@cursor-128x128-offscreen: - shard-skl: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-iclb: NOTRUN -> SKIP [fdo#109274] * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-ytiled: - shard-skl: NOTRUN -> FAIL [fdo#103184] * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-glk: PASS -> FAIL [fdo#105363] * igt@kms_flip@nonexisting-fb-interruptible: - shard-apl: PASS -> INCOMPLETE [fdo#103927] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt: - shard-apl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-rte: - shard-skl: PASS -> FAIL [fdo#105682] * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-gtt: - shard-skl: NOTRUN -> FAIL [fdo#105682] * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-mmap-cpu: - shard-skl: NOTRUN -> FAIL [fdo#103167] +3 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-render: - shard-snb: NOTRUN -> SKIP [fdo#109271] +40 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-pwrite: - shard-iclb: PASS -> FAIL [fdo#103167] +3 * igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-spr-indfb-onoff: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +4 * igt@kms_frontbuffer_tracking@fbcpsr-stridechange: - shard-skl: NOTRUN -> FAIL [fdo#105683] * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-move: - shard-skl: PASS -> FAIL [fdo#103167] +3 * igt@kms_plane@pixel-format-pipe-c-planes: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] * igt@kms_plane@plane-position-covered-pipe-a-planes: - shard-iclb: PASS -> FAIL [fdo#103166] * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb: - shard-apl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb: - shard-kbl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: NOTRUN -> FAIL [fdo#108145] +1 * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: PASS -> FAIL [fdo#107815] +1 * igt@kms_plane_multiple@atomic-pipe-a-tiling-y: - shard-apl: PASS -> FAIL [fdo#103166] +1 * igt@kms_psr@psr2_cursor_plane_onoff: - shard-iclb: NOTRUN -> SKIP [fdo#109441] +1 * igt@kms_rotation_crc@multiplane-rotation: - shard-kbl: PASS -> INCOMPLETE [fdo#103665] * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom: - shard-kbl: PASS -> DMESG-FAIL [fdo#105763] *
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Disable PSMI idle messaging when stopping ring
Quoting Mika Kuoppala (2019-02-28 16:01:33)
> Hardware cannot be in a middle of idle flow messaging
> when we pull the plug from ringbuffer. Disable idle
> messaging before we do so to avoid potential deadlock
> on engine initialization and reset.
>
> v2: INVALID_MMIO_REG, unconditional enable (Chris)
> v3: comment (Chris), bspec reference
>
> References: bspec/11751
> Cc: Chris Wilson
> Acked-by: Chris Wilson
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 64 +-
> 1 file changed, 63 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 2a94b92cfcd3..10cb6b22fe92 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -764,7 +764,7 @@ int intel_engine_init_common(struct intel_engine_cs
> *engine)
>
> /**
> * intel_engines_cleanup_common - cleans up the engine state created by
> - *the common initiailizers.
> + *the common initializers.
> * @engine: Engine to cleanup.
> *
> * This cleans up everything created by the common helpers.
> @@ -865,6 +865,63 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs
> *engine)
> _MASKED_BIT_DISABLE(STOP_RING));
> }
>
> +static i915_reg_t get_idle_poll_reg(const struct intel_engine_cs *engine)
> +{
> + if (engine->id != RCS)
> + return INVALID_MMIO_REG;
> +
> + if (IS_GEN(engine->i915, 9))
> + return GEN9_RCS_FE_FSM2;
> +
> + if (IS_GEN(engine->i915, 8))
> + return GEN6_RCS_PWR_FSM;
> +
> + return INVALID_MMIO_REG;
> +}
> +
> +static void disable_idle_messaging(struct intel_engine_cs *engine)
> +{
> + struct drm_i915_private *dev_priv = engine->i915;
> + i915_reg_t poll_reg;
> +
> + poll_reg = get_idle_poll_reg(engine);
> + if (!i915_mmio_reg_valid(poll_reg))
> + return;
> +
> + GEM_DEBUG_WARN_ON(I915_READ_FW(GEN6_RC_SLEEP_PSMI_CONTROL) &
> + GEN6_PSMI_SLEEP_MSG_DISABLE);
> + /*
> +* Hardware must not be in middle of idle flow signalling
> +* when the RING_CTL is zeroed. In order to prevent this
> +* we disable the messaging temporarily.
> +*/
> + I915_WRITE_FW(GEN6_RC_SLEEP_PSMI_CONTROL,
> + _MASKED_BIT_ENABLE(GEN6_PSMI_SLEEP_MSG_DISABLE));
> +
> + /*
> +* Poll the magic bits to ensure that engine state machine
> +* is in valid state for stopping the ring.
> +*/
> + if (__intel_wait_for_register_fw(dev_priv, poll_reg,
> +0x7f, 0x30,
> +5000, 0,
> +NULL))
> + DRM_DEBUG_DRIVER("psmi idle msg poll timeout\n");
> +}
> +
> +static void enable_idle_messaging(struct intel_engine_cs *engine)
> +{
> + struct drm_i915_private *dev_priv = engine->i915;
> + i915_reg_t poll_reg;
> +
> + poll_reg = get_idle_poll_reg(engine);
> + if (!i915_mmio_reg_valid(poll_reg))
> + return;
> +
> + I915_WRITE_FW(GEN6_RC_SLEEP_PSMI_CONTROL,
> + _MASKED_BIT_DISABLE(GEN6_PSMI_SLEEP_MSG_DISABLE));
> +}
> +
> int intel_engine_stop_ring(struct intel_engine_cs *engine)
> {
> struct drm_i915_private *dev_priv = engine->i915;
> @@ -880,9 +937,14 @@ int intel_engine_stop_ring(struct intel_engine_cs
> *engine)
> I915_WRITE_FW(RING_TAIL(base), 0);
> POSTING_READ_FW(RING_TAIL(base));
>
> + /* Idle messaging needs to be off during ring disable */
Ok, that's ott :)
The previous pair are a nice why, peeling back some of the layers of the
HW to see what's going on. This one is just repeating
disable_idle_messing().
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Use intel_engine_stop_cs when stopping ringbuffer
We have an exported function for stopping the engine before
disabling a ringbuffer. Take it into use.
v2: use fw on empty check
v3: tail is tail
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 3 ++
drivers/gpu/drm/i915/intel_ringbuffer.c | 41 ++---
2 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index df8f88142f1d..e35dc0386bf6 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -856,6 +856,9 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs
*engine)
{
struct drm_i915_private *dev_priv = engine->i915;
+ if (INTEL_GEN(dev_priv) < 3)
+ return;
+
GEM_TRACE("%s\n", engine->name);
I915_WRITE_FW(RING_MI_MODE(engine->mmio_base),
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 1b96b0960adc..5fe28d9087b7 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -604,26 +604,32 @@ static void ring_setup_status_page(struct intel_engine_cs
*engine)
flush_cs_tlb(engine);
}
+static bool ring_is_empty(struct intel_engine_cs *engine)
+{
+ struct drm_i915_private *dev_priv = engine->i915;
+ const u32 base = engine->mmio_base;
+
+ return (I915_READ_FW(RING_HEAD(base)) & HEAD_ADDR) ==
+ (I915_READ_FW(RING_TAIL(base)) & TAIL_ADDR);
+}
+
static bool stop_ring(struct intel_engine_cs *engine)
{
struct drm_i915_private *dev_priv = engine->i915;
+ int ret;
- if (INTEL_GEN(dev_priv) > 2) {
- I915_WRITE_MODE(engine, _MASKED_BIT_ENABLE(STOP_RING));
- if (intel_wait_for_register(dev_priv,
- RING_MI_MODE(engine->mmio_base),
- MODE_IDLE,
- MODE_IDLE,
- 1000)) {
- DRM_ERROR("%s : timed out trying to stop ring\n",
- engine->name);
- /* Sometimes we observe that the idle flag is not
-* set even though the ring is empty. So double
-* check before giving up.
-*/
- if (I915_READ_HEAD(engine) != I915_READ_TAIL(engine))
- return false;
- }
+ ret = intel_engine_stop_cs(engine);
+ if (ret == -ENODEV)
+ ret = 0;
+
+ if (ret) {
+ /*
+* Sometimes we observe that the idle flag is not
+* set even though the ring is empty. So double
+* check before giving up.
+*/
+ if (!ring_is_empty(engine))
+ return false;
}
I915_WRITE_HEAD(engine, I915_READ_TAIL(engine));
@@ -718,8 +724,7 @@ static int init_ring_common(struct intel_engine_cs *engine)
goto out;
}
- if (INTEL_GEN(dev_priv) > 2)
- I915_WRITE_MODE(engine, _MASKED_BIT_DISABLE(STOP_RING));
+ intel_engine_cancel_stop_cs(engine);
/* Now awake, let it get started */
if (ring->tail != ring->head) {
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use intel_engine_stop_cs when stopping ringbuffer
Mika Kuoppala writes:
> We have an exported function for stopping the engine before
> disabling a ringbuffer. Take it into use.
>
> v2: use fw on empty check
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> Reviewed-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 3 ++
> drivers/gpu/drm/i915/intel_ringbuffer.c | 41 ++---
> 2 files changed, 26 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index df8f88142f1d..e35dc0386bf6 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -856,6 +856,9 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs
> *engine)
> {
> struct drm_i915_private *dev_priv = engine->i915;
>
> + if (INTEL_GEN(dev_priv) < 3)
> + return;
> +
> GEM_TRACE("%s\n", engine->name);
>
> I915_WRITE_FW(RING_MI_MODE(engine->mmio_base),
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 1b96b0960adc..d7486f9a29a9 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -604,26 +604,32 @@ static void ring_setup_status_page(struct
> intel_engine_cs *engine)
> flush_cs_tlb(engine);
> }
>
> +static bool ring_is_empty(struct intel_engine_cs *engine)
> +{
> + struct drm_i915_private *dev_priv = engine->i915;
> + const u32 base = engine->mmio_base;
> +
> + return (I915_READ_FW(RING_HEAD(base)) & HEAD_ADDR) ==
> + (I915_READ_FW(RING_HEAD(base)) & TAIL_ADDR);
ARgh!
-Mika
> +}
> +
> static bool stop_ring(struct intel_engine_cs *engine)
> {
> struct drm_i915_private *dev_priv = engine->i915;
> + int ret;
>
> - if (INTEL_GEN(dev_priv) > 2) {
> - I915_WRITE_MODE(engine, _MASKED_BIT_ENABLE(STOP_RING));
> - if (intel_wait_for_register(dev_priv,
> - RING_MI_MODE(engine->mmio_base),
> - MODE_IDLE,
> - MODE_IDLE,
> - 1000)) {
> - DRM_ERROR("%s : timed out trying to stop ring\n",
> - engine->name);
> - /* Sometimes we observe that the idle flag is not
> - * set even though the ring is empty. So double
> - * check before giving up.
> - */
> - if (I915_READ_HEAD(engine) != I915_READ_TAIL(engine))
> - return false;
> - }
> + ret = intel_engine_stop_cs(engine);
> + if (ret == -ENODEV)
> + ret = 0;
> +
> + if (ret) {
> + /*
> + * Sometimes we observe that the idle flag is not
> + * set even though the ring is empty. So double
> + * check before giving up.
> + */
> + if (!ring_is_empty(engine))
> + return false;
> }
>
> I915_WRITE_HEAD(engine, I915_READ_TAIL(engine));
> @@ -718,8 +724,7 @@ static int init_ring_common(struct intel_engine_cs
> *engine)
> goto out;
> }
>
> - if (INTEL_GEN(dev_priv) > 2)
> - I915_WRITE_MODE(engine, _MASKED_BIT_DISABLE(STOP_RING));
> + intel_engine_cancel_stop_cs(engine);
>
> /* Now awake, let it get started */
> if (ring->tail != ring->head) {
> --
> 2.17.1
___
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/icl: Probe again type-c connectors that failed
On Thu, Feb 28, 2019 at 02:32:38AM +0200, Souza, Jose wrote: > [...] > > > + * and then retrying the probe. > > > + */ > > > + if (state == INTEL_HOTPLUG_NOCHANGE && > > > + connector->base.status != connector_status_connected && > > > + irq_received && intel_port_is_tc(dev_priv, encoder->port) > > > && > > > + !dig_port->tc_legacy_port && !dig_port->dp.is_mst) > > > > Based on the investigation by Jani et al, we have the similar problem > > with > > HDMI, only during disconnect. So I think we could generalize by > > retrying > > any time there is no change (except for MST where the driver always > > keeps > > the connector in a disconnected state), regardless of the type of the > > sink, since a no-change is suspect in any case: why would the sink > > signal > > (with a long pulse) if there is no change? > > The only case that I can think of is the cases were sink do a short > pulse but we don't handle it in the short pulse handler and schedule a > long pulse handler but it should not cause any drawback retry everytime > there is no change in the state and irq_received is set. > > What comment could we add about the HDMI here? Something like this > would be fine? > > "HDMI sinks are reported as connected by hardware right after unpluging > it, so here also giving some time for hardware to process the unplug so > driver can read it and do the unplug sequence and notify userspace > about the absence of the HDMI sink" It could be more specific, something like: On many platforms the HDMI live state signal is known to be unreliable, so we can't use it to detect if a sink is connected or not. Instead we detect if it's connected based on whether we can read the EDID or not. That in turn has a problem during disconnect, since the HPD interrupt may be raised before the DDC lines get disconnected (due to how the required length of DDC vs. HPD connector pins are specified) and so we'll still be able to get a valid EDID. To solve this schedule another detection cycle if this time around we didn't detect any change in the sink's connection status. > > > > > For HDMI we'd also need to handle this in intel_hdmi.c. > > It happens in older gens that don't have DDI? Otherwise just the update > above should take care of DP and HDMI DDI ports. I've been told it happens both on old and new HW. > > Then Ville suggested to add a Chamelium test for this to IGT, could > > you > > Jose look into that as well? Both the connect and disconnect races > > could > > be tested, both on HDMI and DP, by generating the HPD early/late wrt. > > to > > AUX/DDC starting/stopping to return valid data. I don't know if > > Chamelium can do this, you'd have to find that out first. > > I will try put my hands in a Chamelium board otherwise I will play with > trybot to add this tests. Okay, thanks. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Introduce intel_engine_stop_ringbuffer
We use identical sequence of stopping ringbuffer on reset
handing and on ring initialization. Make a function
to handle both cases.
v2: intel_engine_stop_ring, cleaner stop_ring (Chris)
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reset.c | 18 +---
drivers/gpu/drm/i915/intel_engine_cs.c | 28 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 12 +++
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 ++
4 files changed, 34 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index 55d6123dbba4..e7be0bf881c3 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -113,28 +113,12 @@ void i915_reset_request(struct i915_request *rq, bool
guilty)
static void gen3_stop_engine(struct intel_engine_cs *engine)
{
- struct drm_i915_private *dev_priv = engine->i915;
- const u32 base = engine->mmio_base;
-
GEM_TRACE("%s\n", engine->name);
if (intel_engine_stop_cs(engine))
GEM_TRACE("%s: timed out on STOP_RING\n", engine->name);
- I915_WRITE_FW(RING_HEAD(base), I915_READ_FW(RING_TAIL(base)));
- POSTING_READ_FW(RING_HEAD(base)); /* paranoia */
-
- I915_WRITE_FW(RING_HEAD(base), 0);
- I915_WRITE_FW(RING_TAIL(base), 0);
- POSTING_READ_FW(RING_TAIL(base));
-
- /* The ring must be empty before it is disabled */
- I915_WRITE_FW(RING_CTL(base), 0);
-
- /* Check acts as a post */
- if (I915_READ_FW(RING_HEAD(base)))
- GEM_TRACE("%s: ring head [%x] not parked\n",
- engine->name, I915_READ_FW(RING_HEAD(base)));
+ intel_engine_stop_ring(engine);
}
static void i915_stop_engines(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index e35dc0386bf6..2a94b92cfcd3 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -865,6 +865,34 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs
*engine)
_MASKED_BIT_DISABLE(STOP_RING));
}
+int intel_engine_stop_ring(struct intel_engine_cs *engine)
+{
+ struct drm_i915_private *dev_priv = engine->i915;
+ const u32 base = engine->mmio_base;
+
+ assert_forcewakes_active(dev_priv, FORCEWAKE_ALL);
+ GEM_TRACE("%s\n", engine->name);
+
+ I915_WRITE_FW(RING_HEAD(base), I915_READ_FW(RING_TAIL(base)));
+ POSTING_READ_FW(RING_HEAD(base)); /* paranoia */
+
+ I915_WRITE_FW(RING_HEAD(base), 0);
+ I915_WRITE_FW(RING_TAIL(base), 0);
+ POSTING_READ_FW(RING_TAIL(base));
+
+ /* The ring must be empty before it is disabled */
+ I915_WRITE_FW(RING_CTL(base), 0);
+
+ /* Check acts as a post */
+ if (I915_READ_FW(RING_HEAD(base))) {
+ GEM_TRACE("%s: ring head [%x] not parked\n",
+ engine->name, I915_READ_FW(RING_HEAD(base)));
+ return -EIO;
+ }
+
+ return 0;
+}
+
const char *i915_cache_level_str(struct drm_i915_private *i915, int type)
{
switch (type) {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index d7486f9a29a9..e099ef088d1a 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -615,7 +615,6 @@ static bool ring_is_empty(struct intel_engine_cs *engine)
static bool stop_ring(struct intel_engine_cs *engine)
{
- struct drm_i915_private *dev_priv = engine->i915;
int ret;
ret = intel_engine_stop_cs(engine);
@@ -632,15 +631,10 @@ static bool stop_ring(struct intel_engine_cs *engine)
return false;
}
- I915_WRITE_HEAD(engine, I915_READ_TAIL(engine));
-
- I915_WRITE_HEAD(engine, 0);
- I915_WRITE_TAIL(engine, 0);
-
- /* The ring must be empty before it is disabled */
- I915_WRITE_CTL(engine, 0);
+ if (intel_engine_stop_ring(engine))
+ return false;
- return (I915_READ_HEAD(engine) & HEAD_ADDR) == 0;
+ return true;
}
static int init_ring_common(struct intel_engine_cs *engine)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index b8ec7e40a59b..5ed895c56a35 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -843,6 +843,8 @@ int intel_init_vebox_ring_buffer(struct intel_engine_cs
*engine);
int intel_engine_stop_cs(struct intel_engine_cs *engine);
void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine);
+int intel_engine_stop_ring(struct intel_engine_cs *engine);
+
void intel_engine_set_hwsp_writemask(struct intel_engine_cs *engine, u32 mask);
u64 intel_engine_get_active_head(const struct intel_engine_cs *engine);
--
2.17.1
[Intel-gfx] [PATCH 3/3] drm/i915: Disable PSMI idle messaging when stopping ring
Hardware cannot be in a middle of idle flow messaging
when we pull the plug from ringbuffer. Disable idle
messaging before we do so to avoid potential deadlock
on engine initialization and reset.
v2: INVALID_MMIO_REG, unconditional enable (Chris)
v3: comment (Chris), bspec reference
References: bspec/11751
Cc: Chris Wilson
Acked-by: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_engine_cs.c | 64 +-
1 file changed, 63 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 2a94b92cfcd3..10cb6b22fe92 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -764,7 +764,7 @@ int intel_engine_init_common(struct intel_engine_cs *engine)
/**
* intel_engines_cleanup_common - cleans up the engine state created by
- *the common initiailizers.
+ *the common initializers.
* @engine: Engine to cleanup.
*
* This cleans up everything created by the common helpers.
@@ -865,6 +865,63 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs
*engine)
_MASKED_BIT_DISABLE(STOP_RING));
}
+static i915_reg_t get_idle_poll_reg(const struct intel_engine_cs *engine)
+{
+ if (engine->id != RCS)
+ return INVALID_MMIO_REG;
+
+ if (IS_GEN(engine->i915, 9))
+ return GEN9_RCS_FE_FSM2;
+
+ if (IS_GEN(engine->i915, 8))
+ return GEN6_RCS_PWR_FSM;
+
+ return INVALID_MMIO_REG;
+}
+
+static void disable_idle_messaging(struct intel_engine_cs *engine)
+{
+ struct drm_i915_private *dev_priv = engine->i915;
+ i915_reg_t poll_reg;
+
+ poll_reg = get_idle_poll_reg(engine);
+ if (!i915_mmio_reg_valid(poll_reg))
+ return;
+
+ GEM_DEBUG_WARN_ON(I915_READ_FW(GEN6_RC_SLEEP_PSMI_CONTROL) &
+ GEN6_PSMI_SLEEP_MSG_DISABLE);
+ /*
+* Hardware must not be in middle of idle flow signalling
+* when the RING_CTL is zeroed. In order to prevent this
+* we disable the messaging temporarily.
+*/
+ I915_WRITE_FW(GEN6_RC_SLEEP_PSMI_CONTROL,
+ _MASKED_BIT_ENABLE(GEN6_PSMI_SLEEP_MSG_DISABLE));
+
+ /*
+* Poll the magic bits to ensure that engine state machine
+* is in valid state for stopping the ring.
+*/
+ if (__intel_wait_for_register_fw(dev_priv, poll_reg,
+0x7f, 0x30,
+5000, 0,
+NULL))
+ DRM_DEBUG_DRIVER("psmi idle msg poll timeout\n");
+}
+
+static void enable_idle_messaging(struct intel_engine_cs *engine)
+{
+ struct drm_i915_private *dev_priv = engine->i915;
+ i915_reg_t poll_reg;
+
+ poll_reg = get_idle_poll_reg(engine);
+ if (!i915_mmio_reg_valid(poll_reg))
+ return;
+
+ I915_WRITE_FW(GEN6_RC_SLEEP_PSMI_CONTROL,
+ _MASKED_BIT_DISABLE(GEN6_PSMI_SLEEP_MSG_DISABLE));
+}
+
int intel_engine_stop_ring(struct intel_engine_cs *engine)
{
struct drm_i915_private *dev_priv = engine->i915;
@@ -880,9 +937,14 @@ int intel_engine_stop_ring(struct intel_engine_cs *engine)
I915_WRITE_FW(RING_TAIL(base), 0);
POSTING_READ_FW(RING_TAIL(base));
+ /* Idle messaging needs to be off during ring disable */
+ disable_idle_messaging(engine);
+
/* The ring must be empty before it is disabled */
I915_WRITE_FW(RING_CTL(base), 0);
+ enable_idle_messaging(engine);
+
/* Check acts as a post */
if (I915_READ_FW(RING_HEAD(base))) {
GEM_TRACE("%s: ring head [%x] not parked\n",
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Use intel_engine_stop_cs when stopping ringbuffer
We have an exported function for stopping the engine before
disabling a ringbuffer. Take it into use.
v2: use fw on empty check
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 3 ++
drivers/gpu/drm/i915/intel_ringbuffer.c | 41 ++---
2 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index df8f88142f1d..e35dc0386bf6 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -856,6 +856,9 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs
*engine)
{
struct drm_i915_private *dev_priv = engine->i915;
+ if (INTEL_GEN(dev_priv) < 3)
+ return;
+
GEM_TRACE("%s\n", engine->name);
I915_WRITE_FW(RING_MI_MODE(engine->mmio_base),
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 1b96b0960adc..d7486f9a29a9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -604,26 +604,32 @@ static void ring_setup_status_page(struct intel_engine_cs
*engine)
flush_cs_tlb(engine);
}
+static bool ring_is_empty(struct intel_engine_cs *engine)
+{
+ struct drm_i915_private *dev_priv = engine->i915;
+ const u32 base = engine->mmio_base;
+
+ return (I915_READ_FW(RING_HEAD(base)) & HEAD_ADDR) ==
+ (I915_READ_FW(RING_HEAD(base)) & TAIL_ADDR);
+}
+
static bool stop_ring(struct intel_engine_cs *engine)
{
struct drm_i915_private *dev_priv = engine->i915;
+ int ret;
- if (INTEL_GEN(dev_priv) > 2) {
- I915_WRITE_MODE(engine, _MASKED_BIT_ENABLE(STOP_RING));
- if (intel_wait_for_register(dev_priv,
- RING_MI_MODE(engine->mmio_base),
- MODE_IDLE,
- MODE_IDLE,
- 1000)) {
- DRM_ERROR("%s : timed out trying to stop ring\n",
- engine->name);
- /* Sometimes we observe that the idle flag is not
-* set even though the ring is empty. So double
-* check before giving up.
-*/
- if (I915_READ_HEAD(engine) != I915_READ_TAIL(engine))
- return false;
- }
+ ret = intel_engine_stop_cs(engine);
+ if (ret == -ENODEV)
+ ret = 0;
+
+ if (ret) {
+ /*
+* Sometimes we observe that the idle flag is not
+* set even though the ring is empty. So double
+* check before giving up.
+*/
+ if (!ring_is_empty(engine))
+ return false;
}
I915_WRITE_HEAD(engine, I915_READ_TAIL(engine));
@@ -718,8 +724,7 @@ static int init_ring_common(struct intel_engine_cs *engine)
goto out;
}
- if (INTEL_GEN(dev_priv) > 2)
- I915_WRITE_MODE(engine, _MASKED_BIT_DISABLE(STOP_RING));
+ intel_engine_cancel_stop_cs(engine);
/* Now awake, let it get started */
if (ring->tail != ring->head) {
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/edid: If no preferred mode is found assume the first mode is preferred
On Wed, 2019-02-27 at 23:03 +0200, Ville Syrjälä wrote: > So instead of putting this logic into the EDID parser I guess we > could just put it into the i915 fixed mode code. But then I suppose > we should also fix EDID_QUIRK_FIRST_DETAILED_PREFERRED (assuming it > exists for a good reason). I don't think it has any good reason to exist, tbh. The commit adding it to xserver was for the Philips 107P5, which - being a CRT - would be entirely expected to not have the preferred bit set. We should probably have handled that instead by letting the "target a DPI near 96" logic handle things. - ajax ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_ppgtt: Estimate resource usage and bail if it means swapping!
fi-kbl-guc's swap ran dry while running blt-vs-render-ctxN, which is
midly concerning but conceivable as we never checked there was enough
memory to run the test to begin with.
Each child needs to keep its own surface and possible a pair of logical
contexts (one for rcs and one for bcs) so check that there is enough
memory to allow all children to co-exist. During execution, we require
another surface and batch, but these are temporary and so should fit
fine with a small amount of thrashing on the boundary.
References: https://bugs.freedesktop.org/show_bug.cgi?id=109801
Signed-off-by: Chris Wilson
---
tests/i915/gem_ppgtt.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tests/i915/gem_ppgtt.c b/tests/i915/gem_ppgtt.c
index 11ca31e74..9409bef14 100644
--- a/tests/i915/gem_ppgtt.c
+++ b/tests/i915/gem_ppgtt.c
@@ -91,8 +91,14 @@ static void fork_rcs_copy(int timeout, uint32_t final,
#define CREATE_CONTEXT 0x1
{
igt_render_copyfunc_t render_copy;
+ uint64_t mem_per_child;
int devid;
+ mem_per_child = SIZE;
+ if (flags & CREATE_CONTEXT)
+ mem_per_child += 2 * 128 * 1024; /* rough context sizes */
+ intel_require_memory(mem_per_child, count, CHECK_RAM);
+
for (int child = 0; child < count; child++) {
int fd = drm_open_driver(DRIVER_INTEL);
drm_intel_bufmgr *bufmgr;
--
2.20.1
___
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/selftests: Check that whitelisted registers are accessible (rev3)
== Series Details == Series: drm/i915/selftests: Check that whitelisted registers are accessible (rev3) URL : https://patchwork.freedesktop.org/series/57342/ State : success == Summary == CI Bug Log - changes from CI_DRM_5673 -> Patchwork_12329 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/57342/revisions/3/mbox/ Known issues Here are the changes found in Patchwork_12329 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@memory-alloc: - fi-ivb-3520m: NOTRUN -> SKIP [fdo#109271] +48 * igt@debugfs_test@read_all_entries: - fi-kbl-7567u: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] * igt@gem_exec_suspend@basic-s3: - fi-kbl-7567u: PASS -> DMESG-WARN [fdo#103558] / [fdo#105079] / [fdo#105602] +3 * igt@kms_busy@basic-flip-a: - fi-kbl-7567u: PASS -> SKIP [fdo#109271] / [fdo#109278] +2 * igt@kms_chamelium@hdmi-edid-read: - fi-kbl-7567u: PASS -> FAIL [fdo#109569] +1 * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7567u: PASS -> FAIL [fdo#109800] * igt@kms_pipe_crc_basic@read-crc-pipe-a: - fi-byt-clapper: PASS -> FAIL [fdo#107362] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718] Possible fixes * igt@i915_pm_rpm@basic-pci-d3-state: - fi-byt-j1900: SKIP [fdo#109271] -> PASS * igt@i915_pm_rpm@basic-rte: - fi-byt-j1900: FAIL [fdo#108800] -> PASS * igt@i915_selftest@live_execlists: - fi-apl-guc: INCOMPLETE [fdo#103927] / [fdo#109720] -> PASS * igt@i915_selftest@live_hangcheck: - fi-icl-u2: INCOMPLETE [fdo#108569] -> PASS * igt@kms_busy@basic-flip-a: - fi-gdg-551: FAIL [fdo#103182] -> PASS * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#105079]: https://bugs.freedesktop.org/show_bug.cgi?id=105079 [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109569]: https://bugs.freedesktop.org/show_bug.cgi?id=109569 [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 [fdo#109800]: https://bugs.freedesktop.org/show_bug.cgi?id=109800 Participating hosts (44 -> 38) -- Additional (1): fi-ivb-3520m Missing(7): fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-skl-6770hq fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 Build changes - * Linux: CI_DRM_5673 -> Patchwork_12329 CI_DRM_5673: 900dc561f06564ee9602c1adc855cb558f22791b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4863: 0f0db14e7f4ec41251ca156d7cb5b8d531a38006 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12329: 182f007bce85a5d5ac536398f5dab67fbee444ea @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 182f007bce85 drm/i915/selftests: Check that whitelisted registers are accessible == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12329/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 0/3] drm & vgaarb: handle vgacon removal in vgaarb.
HI, > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Gerd > Hoffmann > Sent: torstai 28. helmikuuta 2019 15.28 > To: Hiler, Arkadiusz > Cc: Sarvela, Tomi P ; intel-gfx g...@lists.freedesktop.org> > Subject: Re: [Intel-gfx] [PATCH v6 0/3] drm & vgaarb: handle vgacon removal in > vgaarb. > > On Thu, Feb 28, 2019 at 01:03:14PM +0200, Arkadiusz Hiler wrote: > > On Thu, Feb 28, 2019 at 11:52:39AM +0100, Daniel Vetter wrote: > > > Adding intel-gfx and CI folks. > > > > > > On Thu, Feb 28, 2019 at 9:22 AM Gerd Hoffmann wrote: > > > > Quick question on the Intel CI: How does it work? I've seen it > > > > sending mails. Does it report failures only, i.e. no news is good > > > > news? How long does it usually take to run the tests? Is waiting a > > > > day enough? > > > > Is there a website where I can see the test results? > > > > > > It always reports, and result links also get dumped onto patchwork > > > (in the series view). There's 2 main runs: BAT and IGT (first with > > > more machines, 2nd with more tests). BAT should be there within a > > > few hours at most, IGT sometimes takes 1 day when there's a big backlog. > > > > > > -Daniel > > > > Hey, > > > > We try to explain our CI here: https://intel-gfx-ci.01.org/ > > > > By the questions you have asked I already see that we should add > > information on the results being sent out for successes too and give > > some time estimations. > > Hmm, I see the test results in patchwork, but I can't remember having seen a > mail. > So the next question: where the results are sent to? From page above sent by Arek: " Since we accept patches through mailing lists, this is where you can find the results - they are sent out as a replies to the original mail. Here are the mailing lists we currently support:" > > cheers, > Gerd Br, Jani Saarinen Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Slightly quieten bad EDID messages
== Series Details == Series: drm: Slightly quieten bad EDID messages URL : https://patchwork.freedesktop.org/series/57343/ State : success == Summary == CI Bug Log - changes from CI_DRM_5674 -> Patchwork_12330 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/57343/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_12330 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-compute: - fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094] * igt@gem_exec_suspend@basic-s3: - fi-byt-clapper: PASS -> INCOMPLETE [fdo#102657] * igt@i915_selftest@live_execlists: - fi-apl-guc: PASS -> INCOMPLETE [fdo#103927] / [fdo#109720] * igt@kms_chamelium@hdmi-edid-read: - fi-hsw-peppy: NOTRUN -> SKIP [fdo#109271] +46 * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: NOTRUN -> DMESG-FAIL [fdo#102614] / [fdo#107814] * igt@runner@aborted: - fi-apl-guc: NOTRUN -> FAIL [fdo#108622] / [fdo#109720] / [fdo#109799] Possible fixes * igt@amdgpu/amd_basic@userptr: - fi-kbl-8809g: DMESG-WARN [fdo#108965] -> PASS [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#102657]: https://bugs.freedesktop.org/show_bug.cgi?id=102657 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#107814]: https://bugs.freedesktop.org/show_bug.cgi?id=107814 [fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094 [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622 [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 [fdo#109799]: https://bugs.freedesktop.org/show_bug.cgi?id=109799 Participating hosts (44 -> 40) -- Additional (1): fi-hsw-peppy Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 Build changes - * Linux: CI_DRM_5674 -> Patchwork_12330 CI_DRM_5674: 71bb3bfb61fb58f93f8b09e6ad576a403cd7752c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4863: 0f0db14e7f4ec41251ca156d7cb5b8d531a38006 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12330: 4a5a07a7b90dc609c185908ae353802e38589fcd @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4a5a07a7b90d drm: Slightly quieten bad EDID messages == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12330/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 5/5] tests/i915/pm_rc6_residency: Fix linking
On 28/02/2019 14:33, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-02-28 14:18:28) From: Tvrtko Ursulin Probably a leftover from test renames: tests/Makefile.am:134: warning: variable 'pm_rc6_residency_LDADD' is defined but no program or tests/Makefile.am:134: library has 'pm_rc6_residency' as canonical name (possible typo) Signed-off-by: Tvrtko Ursulin --- tests/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index c5dd210c7163..80bc5f92a13b 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -131,7 +131,7 @@ perf_pmu_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la gem_eio_LDADD = $(LDADD) -lrt gem_wait_LDADD = $(LDADD) -lrt kms_flip_LDADD = $(LDADD) -lrt -lpthread -pm_rc6_residency_LDADD = $(LDADD) -lrt +i915_pm_rc6_residency_LDADD = $(LDADD) -lrt Have we not snuck -lrt into the core library yet, pretty sure libigt.la now includes clock_gettime() and so must be pulling it in already? i.e. can we just drop the above line? Looks like it. And many more in this case. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] Propagate DP-over-Type-C hotplug events from Type-C subsys to drm-drivers
Hi Hans, On Thu, Feb 28, 2019 at 12:24:25PM +0100, Hans de Goede wrote: > Hi, > > On 28-02-19 10:15, Heikki Krogerus wrote: > > On Wed, Feb 27, 2019 at 04:45:32PM +0100, Hans de Goede wrote: > > > Hi, > > > > > > On 27-02-19 12:16, Jani Nikula wrote: > > > > On Wed, 27 Feb 2019, Heikki Krogerus > > > > wrote: > > > > > One thing that this series does not consider is the DP lane count > > > > > problem. The GPU drivers (i915 in this case) does not know is four, > > > > > two or one DP lanes in use. > > > > > > > > Also, orientation. > > > > > > The orientation should simply be correct with Type-C over DP. The mux / > > > orientation-switch used will take care of (physically) swapping the > > > lanes if the connector is inserted upside-down. > > > > > > > > I guess that is not a critical issue since there is a workaround (I > > > > > think) where the driver basically does trial and error, but ideally we > > > > > should be able to tell i915 also the pin assignment that was > > > > > negotiated with the partner device so it knows the DP lane count. > > > > > > > > Yeah, if the information is there, we'd like to know. > > > > > > So far machines actually using a setup where the kernel does the > > > USB-PD / Type-C negotiation rather then this being handled in firmware > > > in say the Alpine Ridge controller, are very rare. > > > > > > AFAIK in the Alpine Ridge controller case, there is no communication > > > with the i915 driver, the only thing the Alpine Ridge controller does > > > which the everything done in the kernel approach does not, is that > > > it actually has a pin connected to the HDP pin of the displayport in > > > question. But that just lets the i915 driver know about hotplug-events, > > > not how many lanes are used. > > > > > > Currently I'm aware of only 2 x86 models which actually need the > > > hotplug event propagation from the Type-C subsystem to the i915 driver. > > > Do we really want to come up with a much more complex solution to > > > optimize for this corner case, while the much more common case > > > (Alpine Ridge controller) does not provide this info to the i915 driver? > > > > The HPD signal is often handled with a GPIO on Intel Platforms. Either > > the PD controller or EC controller, after receiving the Attention > > message, triggers the GPIO. On some systems though that GPIO method > > could not be used, so instead a side channel communication is used: > > the GFX device (so i915 driver) receives a specific custom interrupt. > > > > Unfortunately it now appears that there may be products coming where > > using the GPIO is not going to be possible, and also side channel > > communication is going to be out of the question. I've started an > > internal discussion inside Intel about the possibility to extend the > > UCSI specification to be able to support that kind of products. > > > > Alpine Ridge uses TI's Power Delivery controllers. The platforms that > > have Alpine Ridge TBT controller(s) often expose the USB Type-C > > connectors on them to the OS via UCSI, however, it appears the Alpine > > Ridge actually allows direct access to the PD controllers from the OS. > > That would mean we can supply the same information to the GPU drivers > > that we will deliver on CHT also on every platform that uses Alpine > > Ridge. > > Ok. > > > > To give some idea of the complexity, first of all we need some > > > mechanism to let the kernel know which drm_connector is connected > > > to which Type-C port. For the 2 models I know if which need this, this > > > info is not available and we would need to hardcode it in the kernel > > > based on e.g. DMI matching. > > > > I've been thinking about this... Do we actually need to link the > > correct drm_connector to the Type-C connector? Perhaps we can make > > this work by just linking the GFX device to the Type-C connector. > > What use is it to the kms driver if it gets an event there is a DP > hotplug with x lanes and orientation foo, if we are not telling it > on which DP port it is ? kms devices already have multiple DP ports > and more then one could be hooked-up to type-c connectors. I was looking at this series. You walk trough every DP port in the system when the DP alt mode driver broadcasts the event, but maybe that's different. Never mind. > > > Then once we have this link, we need to start thinking about probe > > > ordering. Likely we need the typec framework to find the drm_connector, > > > since the typec-partner device is only created when there actually is > > > a DP capable "dongle" connected, making doing it the other way around > > > tricky. Then the typec-partner device needs to get a reference or some > > > such to make sure the drm_connector does not fgo away during the lifetime > > > of the typec-partner device. > > > > No! We must not link the partner device with anything other than the > > Type-C connector. We link the USB Type-C connector to the DisplayPort, > > and we link the USB
Re: [Intel-gfx] [PATCH i-g-t 2/5] gem_wsim: Round mmap to page size
Quoting Tvrtko Ursulin (2019-02-28 14:41:23)
>
> On 28/02/2019 14:25, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-02-28 14:18:25)
> >> From: Tvrtko Ursulin
> >>
> >> mmap(2) mandates size is page aligned.
> >>
> >> Signed-off-by: Tvrtko Ursulin
> >> ---
> >> benchmarks/gem_wsim.c | 7 ---
> >> 1 file changed, 4 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
> >> index 0a5abc08d8c2..57ceb983cf82 100644
> >> --- a/benchmarks/gem_wsim.c
> >> +++ b/benchmarks/gem_wsim.c
> >> @@ -737,6 +737,7 @@ init_bb(struct w_step *w, unsigned int flags)
> >> {
> >> const unsigned int arb_period =
> >> get_bb_sz(w->preempt_us) / sizeof(uint32_t);
> >> + const unsigned int mmap_len = ALIGN(w->bb_sz, 4096);
> >> unsigned int i;
> >> uint32_t *ptr;
> >
> > You only need to do it for
> >
> > ww->bb_sz = ALIGN(get_bb_sz(), 4096);
> >
> > All batch lengths are start = ww->bb_sz - get_bb_sz() and so remain
> > correct. Right?
>
> I think so. I have one more assignment site of w->bb_sz in the upcoming
> code so it was 2 : 2 and I flipped a coin. Actually I wanted to make it
> explicit what I am fixing - the mmap size. But now you'll say batch size
> is also implicitly rounded.. oh well.. I prefer the explicit round up at
> mmap time.
Ok,
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 4/5] autoconf: Silence void pointer arithmetic warnings
On 28/02/2019 14:31, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-02-28 14:18:27) From: Tvrtko Ursulin Meson build does it so make the two symmetrical in this respect. Signed-off-by: Tvrtko Ursulin --- configure.ac | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configure.ac b/configure.ac index 4f55ea5d0f89..210e2c57df55 100644 --- a/configure.ac +++ b/configure.ac @@ -256,6 +256,8 @@ AC_ARG_ENABLE(werror, [Fail on warnings]), [], [enable_werror=no]) +CWARNFLAGS="$CWARNFLAGS -Wno-pointer-arith" \o/ Maybe I am only testing to see who still uses automake. :)) + if test "x$enable_debug" = xyes; then AS_COMPILER_FLAG([-g3], [DEBUG_CFLAGS="-g3"], [DEBUG_CFLAGS="-g"]) AS_COMPILER_FLAG([-Og], [DEBUG_CFLAGS+=" -Og -Wno-maybe-uninitialized"], # disable maybe-uninitialized due to false positives -- But shouldn't we be using something like the above to verify the flag exists? Definitely true. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/5] gem_wsim: Round mmap to page size
On 28/02/2019 14:25, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-02-28 14:18:25)
From: Tvrtko Ursulin
mmap(2) mandates size is page aligned.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 0a5abc08d8c2..57ceb983cf82 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -737,6 +737,7 @@ init_bb(struct w_step *w, unsigned int flags)
{
const unsigned int arb_period =
get_bb_sz(w->preempt_us) / sizeof(uint32_t);
+ const unsigned int mmap_len = ALIGN(w->bb_sz, 4096);
unsigned int i;
uint32_t *ptr;
You only need to do it for
ww->bb_sz = ALIGN(get_bb_sz(), 4096);
All batch lengths are start = ww->bb_sz - get_bb_sz() and so remain
correct. Right?
I think so. I have one more assignment site of w->bb_sz in the upcoming
code so it was 2 : 2 and I flipped a coin. Actually I wanted to make it
explicit what I am fixing - the mmap size. But now you'll say batch size
is also implicitly rounded.. oh well.. I prefer the explicit round up at
mmap time.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/5] lib/i915: Assert mmap size alignment
On 28/02/2019 14:24, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-02-28 14:18:24) From: Tvrtko Ursulin mmap(2) mandates size is page aligned so check this in our wrappers. Signed-off-by: Tvrtko Ursulin --- lib/i915/gem_mman.c | 4 1 file changed, 4 insertions(+) diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c index 3cf9a6bbdb31..084dbb3b3678 100644 --- a/lib/i915/gem_mman.c +++ b/lib/i915/gem_mman.c @@ -57,6 +57,8 @@ void *__gem_mmap__gtt(int fd, uint32_t handle, uint64_t size, unsigned prot) struct drm_i915_gem_mmap_gtt mmap_arg; void *ptr; + igt_assert(!(size & 4095)); No, we don't filter what the kernel gets, not in the ioctl wrapper itself. I know, but I could flip a coin on these kind of decisions. (Sometimes we open code for such ABI tests.) Move it to non-double underscore flavours? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 5/5] tests/i915/pm_rc6_residency: Fix linking
Quoting Tvrtko Ursulin (2019-02-28 14:18:28) > From: Tvrtko Ursulin > > Probably a leftover from test renames: > > tests/Makefile.am:134: warning: variable 'pm_rc6_residency_LDADD' is > defined but no program or > tests/Makefile.am:134: library has 'pm_rc6_residency' as canonical name > (possible typo) > > Signed-off-by: Tvrtko Ursulin > --- > tests/Makefile.am | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/Makefile.am b/tests/Makefile.am > index c5dd210c7163..80bc5f92a13b 100644 > --- a/tests/Makefile.am > +++ b/tests/Makefile.am > @@ -131,7 +131,7 @@ perf_pmu_LDADD = $(LDADD) > $(top_builddir)/lib/libigt_perf.la > gem_eio_LDADD = $(LDADD) -lrt > gem_wait_LDADD = $(LDADD) -lrt > kms_flip_LDADD = $(LDADD) -lrt -lpthread > -pm_rc6_residency_LDADD = $(LDADD) -lrt > +i915_pm_rc6_residency_LDADD = $(LDADD) -lrt Have we not snuck -lrt into the core library yet, pretty sure libigt.la now includes clock_gettime() and so must be pulling it in already? i.e. can we just drop the above line? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 4/5] autoconf: Silence void pointer arithmetic warnings
Quoting Tvrtko Ursulin (2019-02-28 14:18:27) > From: Tvrtko Ursulin > > Meson build does it so make the two symmetrical in this respect. > > Signed-off-by: Tvrtko Ursulin > --- > configure.ac | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/configure.ac b/configure.ac > index 4f55ea5d0f89..210e2c57df55 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -256,6 +256,8 @@ AC_ARG_ENABLE(werror, > [Fail on warnings]), > [], [enable_werror=no]) > > +CWARNFLAGS="$CWARNFLAGS -Wno-pointer-arith" \o/ > + > if test "x$enable_debug" = xyes; then > AS_COMPILER_FLAG([-g3], [DEBUG_CFLAGS="-g3"], [DEBUG_CFLAGS="-g"]) > AS_COMPILER_FLAG([-Og], [DEBUG_CFLAGS+=" -Og > -Wno-maybe-uninitialized"], # disable maybe-uninitialized due to false > positives > -- But shouldn't we be using something like the above to verify the flag exists? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/5] gem_wsim: Remove some unused struct members
Quoting Tvrtko Ursulin (2019-02-28 14:18:26) > From: Tvrtko Ursulin > > We do not bother explicitly unmapping memory on exit so no need to store > address and size in the workload step struct. If compiler happy, and I'm happy about leaving the mmap dangling for the kernel to clean up, Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/5] gem_wsim: Round mmap to page size
Quoting Tvrtko Ursulin (2019-02-28 14:18:25)
> From: Tvrtko Ursulin
>
> mmap(2) mandates size is page aligned.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> benchmarks/gem_wsim.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
> index 0a5abc08d8c2..57ceb983cf82 100644
> --- a/benchmarks/gem_wsim.c
> +++ b/benchmarks/gem_wsim.c
> @@ -737,6 +737,7 @@ init_bb(struct w_step *w, unsigned int flags)
> {
> const unsigned int arb_period =
> get_bb_sz(w->preempt_us) / sizeof(uint32_t);
> + const unsigned int mmap_len = ALIGN(w->bb_sz, 4096);
> unsigned int i;
> uint32_t *ptr;
You only need to do it for
ww->bb_sz = ALIGN(get_bb_sz(), 4096);
All batch lengths are start = ww->bb_sz - get_bb_sz() and so remain
correct. Right?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/5] lib/i915: Assert mmap size alignment
Quoting Tvrtko Ursulin (2019-02-28 14:18:24) > From: Tvrtko Ursulin > > mmap(2) mandates size is page aligned so check this in our wrappers. > > Signed-off-by: Tvrtko Ursulin > --- > lib/i915/gem_mman.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c > index 3cf9a6bbdb31..084dbb3b3678 100644 > --- a/lib/i915/gem_mman.c > +++ b/lib/i915/gem_mman.c > @@ -57,6 +57,8 @@ void *__gem_mmap__gtt(int fd, uint32_t handle, uint64_t > size, unsigned prot) > struct drm_i915_gem_mmap_gtt mmap_arg; > void *ptr; > > + igt_assert(!(size & 4095)); No, we don't filter what the kernel gets, not in the ioctl wrapper itself. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/5] lib/i915: Assert mmap size alignment
From: Tvrtko Ursulin
mmap(2) mandates size is page aligned so check this in our wrappers.
Signed-off-by: Tvrtko Ursulin
---
lib/i915/gem_mman.c | 4
1 file changed, 4 insertions(+)
diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c
index 3cf9a6bbdb31..084dbb3b3678 100644
--- a/lib/i915/gem_mman.c
+++ b/lib/i915/gem_mman.c
@@ -57,6 +57,8 @@ void *__gem_mmap__gtt(int fd, uint32_t handle, uint64_t size,
unsigned prot)
struct drm_i915_gem_mmap_gtt mmap_arg;
void *ptr;
+ igt_assert(!(size & 4095));
+
memset(_arg, 0, sizeof(mmap_arg));
mmap_arg.handle = handle;
if (igt_ioctl(fd, DRM_IOCTL_I915_GEM_MMAP_GTT, _arg))
@@ -162,6 +164,8 @@ static void
{
struct drm_i915_gem_mmap arg;
+ igt_assert(!(size & 4095));
+
memset(, 0, sizeof(arg));
arg.handle = handle;
arg.offset = offset;
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/5] gem_wsim: Round mmap to page size
From: Tvrtko Ursulin
mmap(2) mandates size is page aligned.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 0a5abc08d8c2..57ceb983cf82 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -737,6 +737,7 @@ init_bb(struct w_step *w, unsigned int flags)
{
const unsigned int arb_period =
get_bb_sz(w->preempt_us) / sizeof(uint32_t);
+ const unsigned int mmap_len = ALIGN(w->bb_sz, 4096);
unsigned int i;
uint32_t *ptr;
@@ -746,12 +747,12 @@ init_bb(struct w_step *w, unsigned int flags)
gem_set_domain(fd, w->bb_handle,
I915_GEM_DOMAIN_WC, I915_GEM_DOMAIN_WC);
- ptr = gem_mmap__wc(fd, w->bb_handle, 0, w->bb_sz, PROT_WRITE);
+ ptr = gem_mmap__wc(fd, w->bb_handle, 0, mmap_len, PROT_WRITE);
for (i = arb_period; i < w->bb_sz / sizeof(uint32_t); i += arb_period)
ptr[i] = 0x5 << 23; /* MI_ARB_CHK */
- munmap(ptr, w->bb_sz);
+ munmap(ptr, mmap_len);
}
static void
@@ -771,7 +772,7 @@ terminate_bb(struct w_step *w, unsigned int flags)
batch_start -= 12 * sizeof(uint32_t);
mmap_start = rounddown(batch_start, PAGE_SIZE);
- mmap_len = w->bb_sz - mmap_start;
+ mmap_len = ALIGN(w->bb_sz - mmap_start, PAGE_SIZE);
gem_set_domain(fd, w->bb_handle,
I915_GEM_DOMAIN_WC, I915_GEM_DOMAIN_WC);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 5/5] tests/i915/pm_rc6_residency: Fix linking
From: Tvrtko Ursulin Probably a leftover from test renames: tests/Makefile.am:134: warning: variable 'pm_rc6_residency_LDADD' is defined but no program or tests/Makefile.am:134: library has 'pm_rc6_residency' as canonical name (possible typo) Signed-off-by: Tvrtko Ursulin --- tests/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index c5dd210c7163..80bc5f92a13b 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -131,7 +131,7 @@ perf_pmu_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la gem_eio_LDADD = $(LDADD) -lrt gem_wait_LDADD = $(LDADD) -lrt kms_flip_LDADD = $(LDADD) -lrt -lpthread -pm_rc6_residency_LDADD = $(LDADD) -lrt +i915_pm_rc6_residency_LDADD = $(LDADD) -lrt prime_nv_test_CFLAGS = $(AM_CFLAGS) $(DRM_NOUVEAU_CFLAGS) prime_nv_test_LDADD = $(LDADD) $(DRM_NOUVEAU_LIBS) -- 2.19.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 3/5] gem_wsim: Remove some unused struct members
From: Tvrtko Ursulin
We do not bother explicitly unmapping memory on exit so no need to store
address and size in the workload step struct.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 57ceb983cf82..afb9644dd7f0 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -131,7 +131,6 @@ struct w_step
struct drm_i915_gem_relocation_entry reloc[4];
unsigned long bb_sz;
uint32_t bb_handle;
- uint32_t *mapped_batch;
uint32_t *seqno_value;
uint32_t *seqno_address;
uint32_t *rt0_value;
@@ -139,7 +138,6 @@ struct w_step
uint32_t *rt1_address;
uint32_t *latch_value;
uint32_t *latch_address;
- unsigned int mapped_len;
};
DECLARE_EWMA(uint64_t, rt, 4, 2)
@@ -824,9 +822,6 @@ terminate_bb(struct w_step *w, unsigned int flags)
}
*cs = bbe;
-
- w->mapped_batch = ptr;
- w->mapped_len = mmap_len;
}
static const unsigned int eb_engine_map[NUM_ENGINES] = {
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 4/5] autoconf: Silence void pointer arithmetic warnings
From: Tvrtko Ursulin Meson build does it so make the two symmetrical in this respect. Signed-off-by: Tvrtko Ursulin --- configure.ac | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configure.ac b/configure.ac index 4f55ea5d0f89..210e2c57df55 100644 --- a/configure.ac +++ b/configure.ac @@ -256,6 +256,8 @@ AC_ARG_ENABLE(werror, [Fail on warnings]), [], [enable_werror=no]) +CWARNFLAGS="$CWARNFLAGS -Wno-pointer-arith" + if test "x$enable_debug" = xyes; then AS_COMPILER_FLAG([-g3], [DEBUG_CFLAGS="-g3"], [DEBUG_CFLAGS="-g"]) AS_COMPILER_FLAG([-Og], [DEBUG_CFLAGS+=" -Og -Wno-maybe-uninitialized"], # disable maybe-uninitialized due to false positives -- 2.19.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Slightly quieten bad EDID messages
On Thu, Feb 28, 2019 at 01:42:33PM +, Chris Wilson wrote:
> Bad EDID are a fact of life when dealing with random monitors. We only
> spam the logs when debugging is enabled, but we only need to raise
> notice and not set off the warning bells.
>
> Signed-off-by: Chris Wilson
> Cc: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_edid.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 990b1909f9d7..98903cb7064d 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1535,9 +1535,8 @@ static void connector_bad_edid(struct drm_connector
> *connector,
> if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
> return;
>
> - dev_warn(connector->dev->dev,
> - "%s: EDID is invalid:\n",
> - connector->name);
> + dev_notice(connector->dev->dev,
> +"%s: EDID is invalid:\n", connector->name);
> for (i = 0; i < num_blocks; i++) {
> u8 *block = edid + i * EDID_LENGTH;
> char prefix[20];
> @@ -1549,7 +1548,7 @@ static void connector_bad_edid(struct drm_connector
> *connector,
> else
> sprintf(prefix, "\t[%02x] GOOD ", i);
>
> - print_hex_dump(KERN_WARNING,
> + print_hex_dump(KERN_NOTICE,
> prefix, DUMP_PREFIX_NONE, 16, 1,
> block, EDID_LENGTH, false);
> }
These two definitely make sense.
> @@ -4695,8 +4694,8 @@ int drm_add_edid_modes(struct drm_connector *connector,
> struct edid *edid)
> }
> if (!drm_edid_is_valid(edid)) {
> clear_eld(connector);
> - dev_warn(connector->dev->dev, "%s: EDID invalid.\n",
> - connector->name);
> + dev_notice(connector->dev->dev,
> +"%s: EDID invalid.\n", connector->name);
Not entirely sure about this one, if we totally break the i2c reading, but
load detect still works (likely, since different paths at least for i915),
then we won't catch that. We'll just silently fall back to the default
modes (and maybe some wtf test failures).
I'd keep this one here.
-Daniel
> return 0;
> }
>
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
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/selftests: Check that whitelisted registers are accessible (rev3)
== Series Details == Series: drm/i915/selftests: Check that whitelisted registers are accessible (rev3) URL : https://patchwork.freedesktop.org/series/57342/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5673 -> Patchwork_12329 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12329 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12329, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/57342/revisions/3/mbox/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_12329: ### IGT changes ### Possible regressions * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7567u: PASS -> FAIL Known issues Here are the changes found in Patchwork_12329 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@memory-alloc: - fi-ivb-3520m: NOTRUN -> SKIP [fdo#109271] +48 * igt@debugfs_test@read_all_entries: - fi-kbl-7567u: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] * igt@gem_exec_suspend@basic-s3: - fi-kbl-7567u: PASS -> DMESG-WARN [fdo#103558] / [fdo#105079] / [fdo#105602] +3 * igt@kms_busy@basic-flip-a: - fi-kbl-7567u: PASS -> SKIP [fdo#109271] / [fdo#109278] +2 * igt@kms_chamelium@hdmi-edid-read: - fi-kbl-7567u: PASS -> FAIL [fdo#109569] +1 * igt@kms_pipe_crc_basic@read-crc-pipe-a: - fi-byt-clapper: PASS -> FAIL [fdo#107362] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718] Possible fixes * igt@i915_pm_rpm@basic-pci-d3-state: - fi-byt-j1900: SKIP [fdo#109271] -> PASS * igt@i915_pm_rpm@basic-rte: - fi-byt-j1900: FAIL [fdo#108800] -> PASS * igt@i915_selftest@live_execlists: - fi-apl-guc: INCOMPLETE [fdo#103927] / [fdo#109720] -> PASS * igt@i915_selftest@live_hangcheck: - fi-icl-u2: INCOMPLETE [fdo#108569] -> PASS * igt@kms_busy@basic-flip-a: - fi-gdg-551: FAIL [fdo#103182] -> PASS * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#105079]: https://bugs.freedesktop.org/show_bug.cgi?id=105079 [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109569]: https://bugs.freedesktop.org/show_bug.cgi?id=109569 [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 Participating hosts (44 -> 38) -- Additional (1): fi-ivb-3520m Missing(7): fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-skl-6770hq fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 Build changes - * Linux: CI_DRM_5673 -> Patchwork_12329 CI_DRM_5673: 900dc561f06564ee9602c1adc855cb558f22791b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4863: 0f0db14e7f4ec41251ca156d7cb5b8d531a38006 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12329: 182f007bce85a5d5ac536398f5dab67fbee444ea @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 182f007bce85 drm/i915/selftests: Check that whitelisted registers are accessible == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12329/ ___ 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/selftests: Check that whitelisted registers are accessible (rev2)
== Series Details ==
Series: drm/i915/selftests: Check that whitelisted registers are accessible
(rev2)
URL : https://patchwork.freedesktop.org/series/57342/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5673 -> Patchwork_12328
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/57342/revisions/2/mbox/
Known issues
Here are the changes found in Patchwork_12328 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@memory-alloc:
- fi-ivb-3520m: NOTRUN -> SKIP [fdo#109271] +48
* igt@amdgpu/amd_cs_nop@fork-compute0:
- fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +18
* igt@i915_module_load@reload-no-display:
- fi-kbl-7567u: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +1
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: PASS -> SKIP [fdo#109271] / [fdo#109278] +2
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@runner@aborted:
- fi-kbl-7567u: NOTRUN -> FAIL [fdo#105602]
Possible fixes
* igt@i915_module_load@reload:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: SKIP [fdo#109271] -> PASS
* igt@i915_pm_rpm@basic-rte:
- fi-byt-j1900: FAIL [fdo#108800] -> PASS
* igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] / [fdo#109720] -> PASS
* igt@i915_selftest@live_hangcheck:
- fi-icl-u2: INCOMPLETE [fdo#108569] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS +1
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720
Participating hosts (44 -> 41)
--
Additional (2): fi-icl-y fi-ivb-3520m
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600
Build changes
-
* Linux: CI_DRM_5673 -> Patchwork_12328
CI_DRM_5673: 900dc561f06564ee9602c1adc855cb558f22791b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4863: 0f0db14e7f4ec41251ca156d7cb5b8d531a38006 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12328: 354ff68826949b728e4a26f7801538808c4ac871 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
354ff6882694 drm/i915/selftests: Check that whitelisted registers are accessible
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12328/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] topic/mei-hdcp for char-misc-next
On Thu, Feb 28, 2019 at 1:00 PM Greg KH wrote: > > On Tue, Feb 26, 2019 at 10:17:10PM +0100, Daniel Vetter wrote: > > Hi Greg > > > > topic/mei-hdcp-2019-02-26: > > mei-hdcp driver > > > > mei driver for the me hdcp client, for use by drm/i915. > > > > Including the following prep work: > > - whitelist hdcp client in mei bus > > - merge to include char-misc-next because of another mei bus prep patch to > > export a helper macro to drivers > > - drm/i915 side of the mei_hdcp/i915 component interface (already pulled > > into drm-intel for 5.2 as a topic branch) > > - component prep work (including one patch touching i915), already > > pulled by you into drivers-base-next for 5.1 > > > > mei-hdcp patches all reviewed and acked by Tomas Winkler. All other bits > > and pieces acked by relevant subsystem people. Took a bit longer than > > planned, but so does the 5.0 release. Up to you whether you still want to > > pull for 5.1 merge window or delay for 5.2, either totally fine for us. > > The drm/i915 of this will only land in 5.2 completely. > > > > Cheers, Daniel > > > > Note: diffstat below generated against Linus' tree. Which is wrong, but > > since this both contains drivers-base-next, char-misc-next and stuff > > queued for drm-i915 (but which isn't in linux-next yet because that's > > aimed for 5.2) it's a bit a mess. Given that shrugged and just went with > > this. I can regenerate some other diffstat if you want something else, > > just didn't know what's really the right thing here. > > That diffstat and shortlog was crazy :( > > Here's the right diffstat: Yup, that one looks reasonable. I guess for the next contrived topic branch I need to figure out how to generate diffstat against the other subsytem tree and put that in our scripting. Usually for topic branches just generating the diffstat against Linus' tree dtrt. But not in this case. > Documentation/driver-api/component.rst | 17 ++ > Documentation/driver-api/device_link.rst | 3 + > Documentation/driver-api/index.rst | 1 + > drivers/base/component.c | 206 - > drivers/gpu/drm/i915/intel_audio.c | 4 +- > drivers/gpu/drm/i915/intel_display.h | 16 +- > drivers/misc/mei/Kconfig | 10 + > drivers/misc/mei/Makefile| 2 + > drivers/misc/mei/bus-fixup.c | 16 ++ > drivers/misc/mei/hdcp/Makefile | 7 + > drivers/misc/mei/hdcp/mei_hdcp.c | 849 > +++ > drivers/misc/mei/hdcp/mei_hdcp.h | 377 > > include/drm/drm_audio_component.h| 1 + > include/drm/drm_hdcp.h | 18 ++ > include/drm/i915_component.h | 5 + > include/drm/i915_drm.h | 15 ++ > include/drm/i915_mei_hdcp_interface.h| 149 + > include/linux/component.h| 76 +++ > include/sound/hda_component.h| 5 +- > sound/hda/hdac_component.c | 4 +- > sound/hda/hdac_i915.c| 6 +- > 21 files changed, 1754 insertions(+), 33 deletions(-) > create mode 100644 Documentation/driver-api/component.rst > create mode 100644 drivers/misc/mei/hdcp/Makefile > create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.c > create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.h > create mode 100644 include/drm/i915_mei_hdcp_interface.h > > Anyway, I've pulled this into my char-misc-testing tree to let 0-day run with > it, and if all is good, will move it to my -next branch for inclusion in > 5.1-rc1. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: use REG_FIELD_PREP() to define register bitfield values
On Thu, 28 Feb 2019, Michal Wajdeczko wrote:
> On Thu, 28 Feb 2019 11:24:53 +0100, Jani Nikula
> wrote:
>
>> On Thu, 28 Feb 2019, Michal Wajdeczko wrote:
>>> On Wed, 27 Feb 2019 18:02:38 +0100, Jani Nikula
>>> wrote:
>>>
@@ -108,9 +108,9 @@
* #define FOO(pipe) _MMIO_PIPE(pipe, _FOO_A,
_FOO_B)
* #define FOO_ENABLEREG_BIT(31)
* #define FOO_MODE_MASK REG_GENMASK(19, 16)
- * #define FOO_MODE_BAR (0 << 16)
- * #define FOO_MODE_BAZ (1 << 16)
- * #define FOO_MODE_QUX_SNB (2 << 16)
+ * #define FOO_MODE_BAR REG_FIELD_PREP(FOO_MODE_MASK,
0)
+ * #define FOO_MODE_BAZ REG_FIELD_PREP(FOO_MODE_MASK,
1)
+ * #define FOO_MODE_QUX_SNB REG_FIELD_PREP(FOO_MODE_MASK,
2)
>>>
>>> hmm, shouldn't we define these values as:
>>>
>>> #define FOO_MODE_BAR (0)
>>> #define FOO_MODE_BAZ (1)
>>> #define FOO_MODE_QUX_SNB (2)
>>>
>>> to allow using them natively with REG_FIELD_GET/PREPARE() ?
>>> maybe we should also consider dropping _MASK suffix?
>>>
>>> MMIO_WRITE(...,
>>> REG_FIELD_PREPARE(FOO_ENABLE, true) |
>>> REG_FIELD_PREPARE(FOO_MODE, FOO_MODE_BAR))
>>>
>>> mode = REG_FIELD_GET(FOO_MODE, MMIO_READ(...));
>>> enabled = REG_FIELD_GET(FOO_ENABLE, MMIO_READ(...));
>>
>> I would have to agree with you *if* we were writing all this from
>> scratch. But almost all of the existing bitfield values are defined
>> shifted in place, so you can OR them in place directly. I want to keep
>> it that way instead of creating a mix. And we have about 1k macros with
>> _MASK suffix too.
>
> But since this is 'documentation' part, maybe we should push into preferred
> usage model, leaving behind existing code (and let it upgrade case by case)
I'm actually not even sure I agree with the usage model. Contrast:
I915_WRITE(..., FOO_MODE_BAR | FOO_SOMETHING_ELSE);
with
I915_WRITE(..., REG_FIELD_PREP(FOO_MODE_MASK, FOO_MODE_BAR) |
FOO_SOMETHING_ELSE);
When possible, I think I still prefer having the verbose part in
i915_reg.h in favor of keeping the code readable *and* uniform
regardless of whether the fields were defined using REG_FIELD_PREP() or
manual shifts.
I can also imagine doing:
#define FOO_SIZE_MASK REG_GENMASK(7, 0)
#define FOO_SIZE(size) REG_FIELD_PREP(FOO_SIZE_MASK, size)
and using:
I915_WRITE(..., FOO_SIZE(42))
instead of:
I915_WRITE(..., REG_FIELD_PREP(FOO_SIZE_MASK, size))
>
>>
>> So, yeah, it's going to be slightly problematic to REG_FIELD_GET() a
>> field and compare it against a defined value for that field. I expect us
>> to keep using things like:
>>
>> if ((val & FOO_MODE_MASK) == FOO_MODE_BAR)
>
> Hmm, if you still want to use it this way, what's the purpose of having
> pair of REG_FIELD_GET macro?
I don't think we read register fields to compare them against the macros
all that much. I think it's more common to read the fields to extract
some value (say, pixels, timing), or to compare against a value stored
in state.
>
>>
>> Indeed, one of the reasons for the local integer constant expression
>> version of REG_FIELD_PREP() is to allow it in case labels:
>>
>> switch (val & FOO_MODE_MASK) {
>> case FOO_MODE_BAR: /* defined using REG_FIELD_PREP() */
>> /* ... */
>> }
>>
>> I don't want to have to start changing these common existing conventions
>> throughout the driver. With the proposed approach, we can define the
>> registers in the new style and not change anything. We can drop _SHIFT
>> case by case if we move to REG_FIELD_PREP/GET usage.
>>
>
> But actually maybe better option would be to let old definitions and code
> intact, and then later change both places at once, to follow new rules:
>
> mode = REG_FIELD_GET(FOO_MODE_MASK, val);
> switch (mode) {
> case FOO_MODE_BAR: /* defined like 0 based enums */
> /* ... */
> }
>
> otherwise, regardless of having new style _PREP/_GET macros, we still
> be using our old convention based on _SHIFT'ed values.
>
> As Chris replied earlier, we must take into account "that other people
> reading our code already know the language" and with keeping register
> values shifted, we may break style expected by _PREP/_GET.
So imagine the mixed use, one set of registers converted, some others
not, and you have code with:
I915_WRITE(..., REG_FIELD_PREP(FOO_MODE_MASK, FOO_MODE_BAR) |
FOO_SOMETHING_ELSE);
I915_WRITE(..., BAR_MODE_BAZ | BAR_SOMETHING_ELSE);
And you're wondering why the inconsistency.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
