Re: [Intel-gfx] [PATCH 39/40] drm/i915/execlists: Refactor out can_merge_rq()
On 28/09/2018 21:11, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-09-27 12:32:54)
On 19/09/2018 20:55, Chris Wilson wrote:
In the next patch, we add another user that wants to check whether
requests can be merge into a single HW execution, and in the future we
want to add more conditions under which requests from the same context
cannot be merge. In preparation, extract out can_merge_rq().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index be7dbdd7fc2c..679ce521be16 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -478,6 +478,15 @@ static bool can_merge_ctx(const struct intel_context *prev,
return true;
}
+static bool can_merge_rq(const struct i915_request *prev,
+ const struct i915_request *next)
+{
+ if (!can_merge_ctx(prev->hw_context, next->hw_context))
+ return false;
+
+ return true;
Not just return can_merge_ctx(..) ?
Makes you think I have plans to add more tests here... If you look in
the archives you can even have a seek peek ;)
I don't see anything in Virtual Engine / Frame Split work, where to look?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 19/25] drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI
On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote: > > > [...] > > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c > > > b/drivers/gpu/drm/i915/intel_runtime_pm.c > > > index 480dadb1047b..146e2d6cf954 100644 > > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c > > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c > > > @@ -146,6 +146,8 @@ intel_display_power_domain_str(enum > > > intel_display_power_domain domain) > > > return "MODESET"; > > > case POWER_DOMAIN_GT_IRQ: > > > return "GT_IRQ"; > > > + case POWER_DOMAIN_VDSC_EDP_MIPI: > > > + return "VDSC_EDP_MIPI"; > > > default: > > > MISSING_CASE(domain); > > > return "?"; > > > @@ -1966,18 +1968,16 @@ void intel_display_power_put(struct > > > drm_i915_private *dev_priv, > > > BIT_ULL(POWER_DOMAIN_AUDIO) | \ > > > BIT_ULL(POWER_DOMAIN_INIT)) > > > /* > > > - * - transcoder WD > > > - * - KVMR (HW control) > > > + * - eDP/MIPI DSI VDSC > > > > > We're not changing anything in the PW3 domains list, so why changing > > the above? > > These comments are below the PW3 domains define and before the PW2 > domains define. So I thought they were for PW2 domains define. Is > that not the case? > > If its for PW3 then I can keep them as is and if its for PW2 then we > should have eDP/DSI VDSC , KVMR since KVMR will enable PW2 and PW3. Yes, the above comments are for PW3. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/18] drm/i915: Return the mask of enabled infoframes from ->inforame_enabled()
On Mon, Sep 24, 2018 at 07:36:08PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 24, 2018 at 05:51:16PM +0200, Daniel Vetter wrote:
> > On Thu, Sep 20, 2018 at 09:51:38PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > We want to start tracking which infoframes are enabled, so let's replace
> > > the boolean flag with a bitmask.
> > >
> > > We'll abstract the bitmask so that it's not platform dependent. That
> > > will allow us to examine the bitmask later in platform independent code.
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/intel_ddi.c | 2 +-
> > > drivers/gpu/drm/i915/intel_drv.h | 4 +-
> > > drivers/gpu/drm/i915/intel_hdmi.c | 87
> > > ---
> > > 3 files changed, 68 insertions(+), 25 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index 086e3f940586..098a0e4edf2a 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -3390,7 +3390,7 @@ void intel_ddi_get_config(struct intel_encoder
> > > *encoder,
> > > pipe_config->has_hdmi_sink = true;
> > > intel_dig_port = enc_to_dig_port(>base);
> > >
> > > - if (intel_dig_port->infoframe_enabled(encoder, pipe_config))
> > > + if (intel_hdmi_infoframes_enabled(encoder, pipe_config))
> > > pipe_config->has_infoframe = true;
> > >
> > > if ((temp & TRANS_DDI_HDMI_SCRAMBLING_MASK) ==
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index e0f3a79fc75e..6815c69aac2f 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -1181,7 +1181,7 @@ struct intel_digital_port {
> > > bool enable,
> > > const struct intel_crtc_state *crtc_state,
> > > const struct drm_connector_state *conn_state);
> > > - bool (*infoframe_enabled)(struct intel_encoder *encoder,
> > > + u32 (*infoframes_enabled)(struct intel_encoder *encoder,
> > > const struct intel_crtc_state *pipe_config);
> > > };
> > >
> > > @@ -1856,6 +1856,8 @@ bool intel_hdmi_handle_sink_scrambling(struct
> > > intel_encoder *encoder,
> > > bool scrambling);
> > > void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool
> > > enable);
> > > void intel_infoframe_init(struct intel_digital_port *intel_dig_port);
> > > +u32 intel_hdmi_infoframes_enabled(struct intel_encoder *encoder,
> > > + const struct intel_crtc_state *crtc_state);
> > >
> > >
> > > /* intel_lvds.c */
> > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > > b/drivers/gpu/drm/i915/intel_hdmi.c
> > > index c3c2a638d062..a8fcddb199ae 100644
> > > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > > @@ -100,10 +100,14 @@ static u32 g4x_infoframe_index(unsigned int type)
> > > static u32 g4x_infoframe_enable(unsigned int type)
> > > {
> > > switch (type) {
> > > + case HDMI_PACKET_TYPE_NULL:
> > > + return VIDEO_DIP_ENABLE; /* slight lie */
> >
> > Not exactly sure why we're tracking this one here, but not for hsw.
>
> HSW+ doesn't have a DIP enable bit like this. It only has the
> bits to enable specific infoframes.
>
> > Shouldn't we include that one if the DDI port is in hdmi mode? Would be
> > more consistent I think.
>
> Yes that would seem like the more correct thing. I think the reason
> I did this here was so that I could map the DIP_ENABLE bit to
> something unique. Would allow us to differentiate between the
> "DIP enabled with no infoframes enabled" vs. "DIP enabled with
> some infoframes enabled" cases. But seeing as we always enable some
> infoframes I guess this doesn't really provide us with anything
> particularly useful.
>
> That said, I'm actually not sure whether the hw will send the null
> packets if we don't enable the DIP. Would require a HDMI analyzer
> to confirm.
>
> Hmm. Actually gen4 bspec tells me:
> "If DIP is enabled but DIP types are all disabled, no DIP is sent.
> However, a single Null DIP will be sent at the same point in the
> stream that DIP packets would have been sent. This is done to
> keep the port in HDMI mode, otherwise it would revert to DVI mode.
> The "Null packets enabled during vsync" mode (bit #9 of port
> control register) overrides this behavior."
>
> So I guess mapping the null packet to the DIP enable bit is more or
> less correct. Although the spec doesn't quite say whether the null
> packet is also sent when some DIP types are also enabled, or if it
> is only send when no DIP types are enabled.
>
> So to match the hw I guess the readout should really do something
> like:
>
> if (hdmi & HDMI_MODE || dip_ctl & DIP_ENABLE)
> infoframes |= TYPE_NULL;
>
> but that would
Re: [Intel-gfx] [PATCH 39/40] drm/i915/execlists: Refactor out can_merge_rq()
Quoting Tvrtko Ursulin (2018-10-01 09:14:52)
>
> On 28/09/2018 21:11, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-09-27 12:32:54)
> >>
> >> On 19/09/2018 20:55, Chris Wilson wrote:
> >>> In the next patch, we add another user that wants to check whether
> >>> requests can be merge into a single HW execution, and in the future we
> >>> want to add more conditions under which requests from the same context
> >>> cannot be merge. In preparation, extract out can_merge_rq().
> >>>
> >>> Signed-off-by: Chris Wilson
> >>> ---
> >>>drivers/gpu/drm/i915/intel_lrc.c | 12 ++--
> >>>1 file changed, 10 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> >>> b/drivers/gpu/drm/i915/intel_lrc.c
> >>> index be7dbdd7fc2c..679ce521be16 100644
> >>> --- a/drivers/gpu/drm/i915/intel_lrc.c
> >>> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> >>> @@ -478,6 +478,15 @@ static bool can_merge_ctx(const struct intel_context
> >>> *prev,
> >>>return true;
> >>>}
> >>>
> >>> +static bool can_merge_rq(const struct i915_request *prev,
> >>> + const struct i915_request *next)
> >>> +{
> >>> + if (!can_merge_ctx(prev->hw_context, next->hw_context))
> >>> + return false;
> >>> +
> >>> + return true;
> >>
> >> Not just return can_merge_ctx(..) ?
> >
> > Makes you think I have plans to add more tests here... If you look in
> > the archives you can even have a seek peek ;)
>
> I don't see anything in Virtual Engine / Frame Split work, where to look?
Per-context frequency control to allow the rps range to change between
requests.
-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 7/7] tests/plane_damage: Integrate kernel selftest test-drm_damage_helper
On Thu, Sep 27, 2018 at 05:43:50PM -0700, Deepak Rawat wrote:
> Call kernel selftest module test-drm_damage_helper from igt.
>
> Signed-off-by: Deepak Rawat
> ---
> tests/Makefile.sources | 1 +
> tests/drm_plane_damage.c | 10 ++
> 2 files changed, 11 insertions(+)
> create mode 100644 tests/drm_plane_damage.c
>
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 269336ad..31ea8819 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -229,6 +229,7 @@ TESTS_progs = \
> tools_test \
> vgem_basic \
> vgem_slow \
> + drm_plane_damage \
> $(NULL)
Alphabetical, as Chris said. And the corresponding change to meson.build too.
>
> TESTS_progs_X = \
> diff --git a/tests/drm_plane_damage.c b/tests/drm_plane_damage.c
> new file mode 100644
> index ..c2b793cc
> --- /dev/null
> +++ b/tests/drm_plane_damage.c
> @@ -0,0 +1,10 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#include "igt.h"
> +#include "igt_kmod.h"
> +
> +IGT_TEST_DESCRIPTION("Basic sanity check of DRM's plane damage helper
> iterator.");
> +
> +igt_main
> +{
> + igt_kselftests("test-drm_damage_helper", NULL, NULL, NULL);
> +}
This test also needs whitelisting in tests/igt_command_line.sh similar
to drv_selftest and drm_mm.
> --
> 2.17.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/18] drm/i915/sdvo: Read out HDMI infoframes
On Mon, Sep 24, 2018 at 08:13:08PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 24, 2018 at 06:10:14PM +0200, Daniel Vetter wrote:
> > On Thu, Sep 20, 2018 at 09:51:43PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Read the HDMI infoframes from the hbuf and unpack them into
> > > the crtc state.
> > >
> > > Well, actually just AVI infoframe for now but let's write the
> > > infoframe readout code in a more generic fashion in case we
> > > expand this later.
> > >
> > > Signed-off-by: Ville Syrjälä
> >
> > Hm, caring about sdvo seems a bit overkill. And afaik we don't have any
> > sdvo (much less hdmi) in CI. I'm leaning towards just adding a
> > PIPE_CONFIG_QUIRK_INFOFRAMES for sdvo, and short-circuiting the checks if
> > that's set. Except if you can somehow convince CI folks to add an sdvo
> > hdmi card to CI :-)
>
> Unfortunately I only have one SDVO HDMI device and it has the chip
> straight on the motherboard. I can't give mine up for ci :) I guess
> we could try to find another one of those as that model doesn't
> even seem super rare. Just the annoying usual problem of getting
> one from somewhere approved.
>
> I think having to maintain a quirk is ~500% more annoying than
> adding the readout code.
My experience disagrees, a bunch of the (early?) sdvo chips don't bother
to implement all the get stuff. I had a pile of these (but some of them
died, and plugging them all into machines is a pain), and just because it
works on 1 chip doesn't mean it's actually all that useful. That's why I
suggested we do the same thing as with the other stuff we read out from
the sdvo chip (as opposed to things we can read out from
crtc/sdvo-host-side registers).
-Daniel
>
> >
> > > ---
> > > drivers/gpu/drm/i915/intel_sdvo.c | 92
> > > +--
> > > 1 file changed, 89 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> > > b/drivers/gpu/drm/i915/intel_sdvo.c
> > > index d8c78aebaf01..4d787c86df6d 100644
> > > --- a/drivers/gpu/drm/i915/intel_sdvo.c
> > > +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> > > @@ -981,6 +981,58 @@ static bool intel_sdvo_write_infoframe(struct
> > > intel_sdvo *intel_sdvo,
> > > _rate, 1);
> > > }
> > >
> > > +static ssize_t intel_sdvo_read_infoframe(struct intel_sdvo *intel_sdvo,
> > > + unsigned int if_index,
> > > + u8 *data, unsigned int length)
> > > +{
> > > + u8 set_buf_index[2] = { if_index, 0 };
> > > + u8 hbuf_size, tx_rate, av_split;
> > > + int i;
> > > +
> > > + if (!intel_sdvo_get_value(intel_sdvo,
> > > + SDVO_CMD_GET_HBUF_AV_SPLIT,
> > > + _split, 1))
> > > + return -ENXIO;
> > > +
> > > + if (av_split < if_index)
> > > + return 0;
> > > +
> > > + if (!intel_sdvo_get_value(intel_sdvo,
> > > + SDVO_CMD_GET_HBUF_TXRATE,
> > > + _rate, 1))
> > > + return -ENXIO;
> > > +
> > > + if (tx_rate == SDVO_HBUF_TX_DISABLED)
> > > + return 0;
> > > +
> > > + if (!intel_sdvo_set_value(intel_sdvo,
> > > + SDVO_CMD_SET_HBUF_INDEX,
> > > + set_buf_index, 2))
> > > + return -ENXIO;
> > > +
> > > + if (!intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_HBUF_INFO,
> > > + _size, 1))
> > > + return -ENXIO;
> > > +
> > > + /* Buffer size is 0 based, hooray! */
> > > + hbuf_size++;
> > > +
> > > + DRM_DEBUG_KMS("reading sdvo hbuf: %i, hbuf_size %i, hbuf_size: %i\n",
> > > + if_index, length, hbuf_size);
> > > +
> > > + hbuf_size = min_t(unsigned int, length, hbuf_size);
> > > +
> > > + for (i = 0; i < hbuf_size; i += 8) {
> > > + if (!intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_HBUF_DATA,
> > > NULL, 0))
> > > + return -ENXIO;
> > > + if (!intel_sdvo_read_response(intel_sdvo, [i],
> > > + min_t(unsigned int, 8, hbuf_size
> > > - i)))
> > > + return -ENXIO;
> > > + }
> > > +
> > > + return hbuf_size;
> > > +}
> > > +
> > > static bool intel_sdvo_compute_avi_infoframe(struct intel_sdvo
> > > *intel_sdvo,
> > >struct intel_crtc_state
> > > *crtc_state,
> > >struct drm_connector_state
> > > *conn_state)
> > > @@ -1039,6 +1091,37 @@ static bool intel_sdvo_set_avi_infoframe(struct
> > > intel_sdvo *intel_sdvo,
> > > sdvo_data, sizeof(sdvo_data));
> > > }
> > >
> > > +static bool intel_sdvo_get_avi_infoframe(struct intel_sdvo *intel_sdvo,
> > > + struct intel_crtc_state *crtc_state)
> > > +{
> > > + u8 sdvo_data[HDMI_INFOFRAME_SIZE(AVI)];
> > > + union hdmi_infoframe *frame = _state->infoframes.avi;
> > > + ssize_t len;
> > > +
Re: [Intel-gfx] [PATCH 6/6] drm/i915/icl: Support co-existence between per-context SSEU and OA
Hi,
One final unreviewed patch on this series. Hopefully uncontroversial
enough for a quick review?
Thanks,
Tvrtko
On 17/09/2018 12:30, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
When OA is active we want to lock the powergating configuration, but on
Icelake, users like the media stack will have issues if we lock to the
full device configuration.
Instead lock to a subset of (sub)slices which are currently a known
working configuration for all users.
v2:
* Fix commit message spelling.
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
---
drivers/gpu/drm/i915/intel_lrc.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b5603e977a3f..cded1f1d9ec2 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2521,13 +2521,28 @@ u32 gen8_make_rpcs(struct drm_i915_private *i915,
struct intel_sseu *req_sseu)
/*
* If i915/perf is active, we want a stable powergating configuration
-* on the system. The most natural configuration to take in that case
-* is the default (i.e maximum the hardware can do).
+* on the system.
+*
+* We could choose full enablement, but on ICL we know there are use
+* cases which disable slices for functional, apart for performance
+* reasons. So in this case we select a known stable subset.
*/
- if (unlikely(i915->perf.oa.exclusive_stream))
- ctx_sseu = intel_device_default_sseu(i915);
- else
+ if (!i915->perf.oa.exclusive_stream) {
ctx_sseu = *req_sseu;
+ } else {
+ ctx_sseu = intel_device_default_sseu(i915);
+
+ if (IS_GEN11(i915)) {
+ /*
+* We only need subslice count so it doesn't matter
+* which ones we select - just turn of low bits in the
+* amount of half of all available subslices per slice.
+*/
+ ctx_sseu.subslice_mask =
+ ~(~0 << (hweight8(ctx_sseu.subslice_mask) / 2));
+ ctx_sseu.slice_mask = 0x1;
+ }
+ }
slices = hweight8(ctx_sseu.slice_mask);
subslices = hweight8(ctx_sseu.subslice_mask);
___
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 2/5] igt/prime_vgem: Skip flip if no display
On Fri, Sep 14, 2018 at 09:13:07PM +0100, Chris Wilson wrote: > We try flipping a vgem surface onto a i915 scanout. However, if there > is no display we want to disable the kms interface, including the addfb > ioctl. On such systems the call to kms_addfb will naturally fail and the > test cannot be run. > > Signed-off-by: Chris Wilson > --- > tests/prime_vgem.c | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/tests/prime_vgem.c b/tests/prime_vgem.c > index b821fbb8c..a76d3797b 100644 > --- a/tests/prime_vgem.c > +++ b/tests/prime_vgem.c > @@ -762,10 +762,13 @@ static void test_flip(int i915, int vgem, unsigned hang) > igt_assert(handle[i]); > close(fd); > > - do_or_die(__kms_addfb(i915, handle[i], > - bo[i].width, bo[i].height, bo[i].pitch, > - DRM_FORMAT_XRGB, I915_TILING_NONE, > NULL, > - LOCAL_DRM_MODE_FB_MODIFIERS, _id[i])); > + /* May skip if i915 has no displays */ > + igt_require(__kms_addfb(i915, handle[i], > + bo[i].width, bo[i].height, bo[i].pitch, > + DRM_FORMAT_XRGB, > + I915_TILING_NONE, NULL, > + LOCAL_DRM_MODE_FB_MODIFIERS, > + _id[i]) == 0); Hm, both here and in patch 1 I feel like this is super late to check for requirements. I think for these low-level tests a kms_require_display which checks for n_pipes > 0 && n_outputs > 0 would be good. Then we can sprinkle these early (and keep the do_or_die here), plus it won't need a comment about why we have the check since it's obvious from the name. -Daniel > igt_assert(fb_id[i]); > } > > -- > 2.19.0 > > ___ > igt-dev mailing list > igt-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/igt-dev -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 19/25] drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI
On Fri, Sep 21, 2018 at 04:46:47PM +0300, Ville Syrjälä wrote:
> On Fri, Sep 21, 2018 at 01:34:00AM -0700, Manasi Navare wrote:
> > On Wed, Sep 19, 2018 at 01:57:00PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 18, 2018 at 02:10:17PM -0700, Manasi Navare wrote:
> > > > On Tue, Sep 18, 2018 at 10:46:46PM +0300, Ville Syrjälä wrote:
> > > > > On Tue, Sep 18, 2018 at 12:31:54PM -0700, Manasi Navare wrote:
> > > > > > On Tue, Sep 18, 2018 at 10:12:24PM +0300, Ville Syrjälä wrote:
> > > > > > > On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote:
> > > > > > > > Thanks Imre for your review comments. Please find the comments
> > > > > > > > below:
> > > > > > > >
> > > > > > > > On Fri, Sep 14, 2018 at 01:55:00PM +0300, Imre Deak wrote:
> > > > > > > > > On Tue, Sep 11, 2018 at 05:56:01PM -0700, Manasi Navare wrote:
> > > > > > > > > > On Icelake, a separate power well PG2 is created for
> > > > > > > > > > VDSC engine used for eDP/MIPI DSI. This patch adds a new
> > > > > > > > > > display power domain for Power well 2.
> > > > > > > > > >
> > > > > > > > > > Cc: Rodrigo Vivi
> > > > > > > > > > Cc: Imre Deak
> > > > > > > > > > Signed-off-by: Manasi Navare
> > > > > > > > > > ---
> > > > > > > > > > drivers/gpu/drm/i915/intel_display.h| 1 +
> > > > > > > > > > drivers/gpu/drm/i915/intel_runtime_pm.c | 12 ++--
> > > > > > > > > > 2 files changed, 7 insertions(+), 6 deletions(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > > > > > > > > > b/drivers/gpu/drm/i915/intel_display.h
> > > > > > > > > > index 3fe52788b4cf..bef71d27cdfe 100644
> > > > > > > > > > --- a/drivers/gpu/drm/i915/intel_display.h
> > > > > > > > > > +++ b/drivers/gpu/drm/i915/intel_display.h
> > > > > > > > > > @@ -256,6 +256,7 @@ enum intel_display_power_domain {
> > > > > > > > > > POWER_DOMAIN_MODESET,
> > > > > > > > > > POWER_DOMAIN_GT_IRQ,
> > > > > > > > > > POWER_DOMAIN_INIT,
> > > > > > > > > > + POWER_DOMAIN_VDSC_EDP_MIPI,
> > > > > > > > >
> > > > > > > > > This is better named VDSC_PIPE_A. The other pipes have also
> > > > > > > > > VDSC
> > > > > > > > > functionality which could be on separate power wells in the
> > > > > > > > > future.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Yea naming it as VDSC_PIPE_A makes sense since eDP/MIPI DSI on
> > > > > > > > Pipe A
> > > > > > > > will use this VDSC power well.
> > > > > > > > I will change this in the next revision.
> > > > > > >
> > > > > > > Isn't the VDSC in the transcoder for now though? And I guess it's
> > > > > > > moving to the pipe later?
> > > > > >
> > > > > > VDSC engine is attached to the eDP/DSI transcoders and this gets
> > > > > > used
> > > > > > for eDP/DSI VDSC on Pipe A.
> > > > >
> > > > > And what happens when I want to use pipe B instead?
> > > >
> > > > DP VDSC on Pipe B uses the VDSC engine on Pipe B. Same for Pipe C
> > >
> > > There are no VDSCs in pipe B or C. There are VDSCs in transcoder B
> > > and C. But that's not the same thing at all. The mux is between the
> > > pipe and transcoder.
> > >
> >
> > As per the display overview for Gen 11, the VDSC engine is present on Pipe
> > B And C.
>
> On transcoder B and C, not pipe B and C.
Yep, I was wrong, the original name POWER_DOMAIN_VDSC_EDP_MIPI is ok.
Up to GEN11 pipe B,C use their associated pipe compression
engines/joiner if routed to transcoder B,C but they use the separate
compression engine (w/o a joiner) if routed to the eDP/MIPI transcoder.
One unclear thing is that the BSpec DSS_CTL1/2 register descriptions
(used for the eDP/MIPI DSC) show that they are backed by PG1, not PG2 as
implied elsewhere in the spec and in this patch.
Art, is that incorrect, or the registers are backed by a different power
well (PG1) than the functionality itself (PG2)?
--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915/icl: Support co-existence between per-context SSEU and OA
On 17/09/2018 13:30, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
When OA is active we want to lock the powergating configuration, but on
Icelake, users like the media stack will have issues if we lock to the
full device configuration.
Instead lock to a subset of (sub)slices which are currently a known
working configuration for all users.
v2:
* Fix commit message spelling.
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
---
drivers/gpu/drm/i915/intel_lrc.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b5603e977a3f..cded1f1d9ec2 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2521,13 +2521,28 @@ u32 gen8_make_rpcs(struct drm_i915_private *i915,
struct intel_sseu *req_sseu)
/*
* If i915/perf is active, we want a stable powergating configuration
-* on the system. The most natural configuration to take in that case
-* is the default (i.e maximum the hardware can do).
+* on the system.
+*
+* We could choose full enablement, but on ICL we know there are use
+* cases which disable slices for functional, apart for performance
+* reasons. So in this case we select a known stable subset.
*/
- if (unlikely(i915->perf.oa.exclusive_stream))
- ctx_sseu = intel_device_default_sseu(i915);
- else
+ if (!i915->perf.oa.exclusive_stream) {
ctx_sseu = *req_sseu;
+ } else {
+ ctx_sseu = intel_device_default_sseu(i915);
+
+ if (IS_GEN11(i915)) {
+ /*
+* We only need subslice count so it doesn't matter
+* which ones we select - just turn of low bits in the
s/turn of/turn off/
+* amount of half of all available subslices per slice.
+*/
+ ctx_sseu.subslice_mask =
+ ~(~0 << (hweight8(ctx_sseu.subslice_mask) / 2));
I would go with :
ctx_sseu.subslice_mask = ctx_sseu.subslice_mask & 0xf;
Documentation says that the first 4 subslices are the "big" ones
(gathered from the fusing register fields which go from
slice0-subslice[0-3] then slice1-subslice[0-3], etc...), so this should
be equally media/3d capable.
+ ctx_sseu.slice_mask = 0x1;
+ }
+ }
slices = hweight8(ctx_sseu.slice_mask);
subslices = hweight8(ctx_sseu.subslice_mask);
___
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 2/5] igt/prime_vgem: Skip flip if no display
Quoting Daniel Vetter (2018-10-01 09:49:07) > On Fri, Sep 14, 2018 at 09:13:07PM +0100, Chris Wilson wrote: > > We try flipping a vgem surface onto a i915 scanout. However, if there > > is no display we want to disable the kms interface, including the addfb > > ioctl. On such systems the call to kms_addfb will naturally fail and the > > test cannot be run. > > > > Signed-off-by: Chris Wilson > > --- > > tests/prime_vgem.c | 11 +++ > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > diff --git a/tests/prime_vgem.c b/tests/prime_vgem.c > > index b821fbb8c..a76d3797b 100644 > > --- a/tests/prime_vgem.c > > +++ b/tests/prime_vgem.c > > @@ -762,10 +762,13 @@ static void test_flip(int i915, int vgem, unsigned > > hang) > > igt_assert(handle[i]); > > close(fd); > > > > - do_or_die(__kms_addfb(i915, handle[i], > > - bo[i].width, bo[i].height, bo[i].pitch, > > - DRM_FORMAT_XRGB, I915_TILING_NONE, > > NULL, > > - LOCAL_DRM_MODE_FB_MODIFIERS, > > _id[i])); > > + /* May skip if i915 has no displays */ > > + igt_require(__kms_addfb(i915, handle[i], > > + bo[i].width, bo[i].height, > > bo[i].pitch, > > + DRM_FORMAT_XRGB, > > + I915_TILING_NONE, NULL, > > + LOCAL_DRM_MODE_FB_MODIFIERS, > > + _id[i]) == 0); > > Hm, both here and in patch 1 I feel like this is super late to check for > requirements. This is earlier than the current check, interesting that check will segfault under this scenario. > I think for these low-level tests a kms_require_display > which checks for n_pipes > 0 && n_outputs > 0 would be good. Then we can > sprinkle these early (and keep the do_or_die here), plus it won't need a > comment about why we have the check since it's obvious from the name. The comment was to try and reinforce that this restriction wasn't to do with vgem itself. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 1/2] drm: Add connector property to limit max bpc
On Mon, Sep 24, 2018 at 02:08:14PM -0700, Radhakrishna Sripada wrote:
> At times 12bpc HDMI cannot be driven due to faulty cables, dongles
> level shifters etc. To workaround them we may need to drive the output
> at a lower bpc. Currently the user space does not have a way to limit
> the bpc. The default bpc to be programmed is decided by the driver and
> is run against connector limitations.
>
> Creating a new connector property "max bpc" in order to limit the bpc.
> xrandr can make use of this connector property to make sure that bpc does
> not exceed the configured value. This property can be used by userspace to
> set the bpc.
>
> V2: Initialize max_bpc to satisfy kms_properties
> V3: Move the property to drm_connector
> V4: Split drm and i915 components(Ville)
> V5: Make the property per connector(Ville)
> V6: Compare the requested bpc to connector bpc(Daniel)
> Move the attach_property function to core(Ville)
> V7: Fix checkpatch warnings
> V8: Simplify the connector check code(Ville)
> V9: Const display_info(Ville)
> V10: Fix CI issues.
>
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Kishore Kadiyala
> Cc: Rodrigo Vivi
> Cc: Manasi Navare
> Cc: Stanislav Lisovskiy
> Cc: Sunpeng Li
> Signed-off-by: Radhakrishna Sripada
Skimming this, I think it looks good now at a high-level.
What's missing is now kernel-doc for these new prorties, needs to be added
here:
https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties
With that I'm happy with the high-level design:
Acked-by: Daniel Vetter
No full review since I didn't look at the igt side for this. Userspace I
think is ok, since it's just another connector prop.
-Daniel
> ---
> drivers/gpu/drm/drm_atomic.c| 5 +
> drivers/gpu/drm/drm_atomic_helper.c | 4
> drivers/gpu/drm/drm_atomic_uapi.c | 4
> drivers/gpu/drm/drm_connector.c | 33 +
> include/drm/drm_connector.h | 20
> 5 files changed, 66 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 2870ae205237..f328bcca84a8 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -390,6 +390,7 @@ static int drm_atomic_connector_check(struct
> drm_connector *connector,
> {
> struct drm_crtc_state *crtc_state;
> struct drm_writeback_job *writeback_job = state->writeback_job;
> + const struct drm_display_info *info = >display_info;
>
> if ((connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK) ||
> !writeback_job)
> return 0;
> @@ -417,6 +418,10 @@ static int drm_atomic_connector_check(struct
> drm_connector *connector,
> return -EINVAL;
> }
>
> + state->max_bpc = info->bpc ? info->bpc : 8;
> + if (connector->max_bpc_property)
> + state->max_bpc = min(state->max_bpc, state->max_requested_bpc);
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index e49b22381048..75aeca35f6d9 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -639,6 +639,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> if (old_connector_state->link_status !=
> new_connector_state->link_status)
> new_crtc_state->connectors_changed = true;
> +
> + if (old_connector_state->max_requested_bpc !=
> + new_connector_state->max_requested_bpc)
> + new_crtc_state->connectors_changed = true;
> }
>
> if (funcs->atomic_check)
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index d5b7f315098c..86ac33922b09 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -740,6 +740,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
>
> return set_out_fence_for_connector(state->state, connector,
> fence_ptr);
> + } else if (property == connector->max_bpc_property) {
> + state->max_requested_bpc = val;
> } else if (connector->funcs->atomic_set_property) {
> return connector->funcs->atomic_set_property(connector,
> state, property, val);
> @@ -804,6 +806,8 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> *val = 0;
> } else if (property == config->writeback_out_fence_ptr_property) {
> *val = 0;
> + } else if (property == connector->max_bpc_property) {
> + *val = state->max_requested_bpc;
> } else if (connector->funcs->atomic_get_property) {
> return connector->funcs->atomic_get_property(connector,
>
Re: [Intel-gfx] [PATCH] input/psmouse: Don't hold the mutex while calling ->disconnect
On Wed, May 2, 2018 at 11:06 AM Daniel Vetter wrote:
>
> On Mon, Apr 30, 2018 at 11:17 PM, Dmitry Torokhov
> wrote:
> > Hi Daniel,
> >
> > On Mon, Apr 30, 2018 at 09:56:49PM +0200, Daniel Vetter wrote:
> >> At least trackpoint_disconnect wants to remove some sysfs files, and
> >> we can't remove sysfs files while holding psmouse_mutex:
> >>
> >> ==
> >> WARNING: possible circular locking dependency detected
> >> 4.16.0-rc5-g613eb885b69e-drmtip_1+ #1 Tainted: G U
> >> --
> >> kworker/0:3/102 is trying to acquire lock:
> >> (kn->count#130){}, at: [<9679748b>]
> >> kernfs_remove_by_name_ns+0x3b/0x80
> >>
> >> but task is already holding lock:
> >> (psmouse_mutex){+.+.}, at: [<14f44bcc>]
> >> psmouse_disconnect+0x62/0x160
> >>
> >> which lock already depends on the new lock.
> >>
> >> the existing dependency chain (in reverse order) is:
> >>
> >> -> #1 (psmouse_mutex){+.+.}:
> >>psmouse_attr_set_helper+0x28/0x140
> >>kernfs_fop_write+0xfe/0x180
> >>__vfs_write+0x1e/0x130
> >>vfs_write+0xbd/0x1b0
> >>SyS_write+0x40/0xa0
> >>do_syscall_64+0x65/0x1a0
> >>entry_SYSCALL_64_after_hwframe+0x42/0xb7
> >>
> >> -> #0 (kn->count#130){}:
> >>__kernfs_remove+0x243/0x2b0
> >>kernfs_remove_by_name_ns+0x3b/0x80
> >>remove_files.isra.0+0x2b/0x60
> >>sysfs_remove_group+0x38/0x80
> >>sysfs_remove_groups+0x24/0x40
> >>trackpoint_disconnect+0x2c/0x50
> >>psmouse_disconnect+0x8f/0x160
> >>serio_disconnect_driver+0x28/0x40
> >>serio_driver_remove+0xc/0x10
> >>device_release_driver_internal+0x15b/0x230
> >>serio_handle_event+0x1c8/0x260
> >>process_one_work+0x215/0x620
> >>worker_thread+0x48/0x3a0
> >>kthread+0xfb/0x130
> >>ret_from_fork+0x3a/0x50
> >>
> >> other info that might help us debug this:
> >>
> >> Possible unsafe locking scenario:
> >>
> >>CPU0CPU1
> >>
> >> lock(psmouse_mutex);
> >>lock(kn->count#130);
> >>lock(psmouse_mutex);
> >> lock(kn->count#130);
> >>
> >> *** DEADLOCK ***
> >>
> >> 6 locks held by kworker/0:3/102:
> >> #0: ((wq_completion)"events_long"){+.+.}, at: [<2e408bfa>]
> >> process_one_work+0x191/0x620
> >> #1: (serio_event_work){+.+.}, at: [<2e408bfa>]
> >> process_one_work+0x191/0x620
> >> #2: (serio_mutex){+.+.}, at: []
> >> serio_handle_event+0x23/0x260
> >> #3: (>mutex){}, at: []
> >> device_release_driver_internal+0x2f/0x230
> >> #4: (>drv_mutex){+.+.}, at: [<9719f997>]
> >> serio_disconnect_driver+0x16/0x40
> >> #5: (psmouse_mutex){+.+.}, at: [<14f44bcc>]
> >> psmouse_disconnect+0x62/0x160
> >>
> >> stack backtrace:
> >> CPU: 0 PID: 102 Comm: kworker/0:3 Tainted: G U
> >> 4.16.0-rc5-g613eb885b69e-drmtip_1+ #1
> >> Hardware name: LENOVO 74591P0/74591P0, BIOS 6DET28WW (1.05 ) 07/30/2008
> >> Workqueue: events_long serio_handle_event
> >> Call Trace:
> >> dump_stack+0x5f/0x86
> >> print_circular_bug.isra.18+0x1d0/0x2c0
> >> __lock_acquire+0x14ae/0x1b60
> >> ? kernfs_remove_by_name_ns+0x20/0x80
> >> ? lock_acquire+0xaf/0x200
> >> lock_acquire+0xaf/0x200
> >> ? kernfs_remove_by_name_ns+0x3b/0x80
> >> __kernfs_remove+0x243/0x2b0
> >> ? kernfs_remove_by_name_ns+0x3b/0x80
> >> ? kernfs_name_hash+0xd/0x70
> >> ? kernfs_find_ns+0x7e/0x100
> >> kernfs_remove_by_name_ns+0x3b/0x80
> >> remove_files.isra.0+0x2b/0x60
> >> sysfs_remove_group+0x38/0x80
> >> sysfs_remove_groups+0x24/0x40
> >> trackpoint_disconnect+0x2c/0x50
> >> psmouse_disconnect+0x8f/0x160
> >> serio_disconnect_driver+0x28/0x40
> >> serio_driver_remove+0xc/0x10
> >> device_release_driver_internal+0x15b/0x230
> >> serio_handle_event+0x1c8/0x260
> >> process_one_work+0x215/0x620
> >> worker_thread+0x48/0x3a0
> >> ? _raw_spin_unlock_irqrestore+0x4c/0x60
> >> kthread+0xfb/0x130
> >> ? process_one_work+0x620/0x620
> >> ? _kthread_create_on_node+0x30/0x30
> >> ret_from_fork+0x3a/0x50
> >>
> >> Signed-off-by: Daniel Vetter
> >> Cc: Dmitry Torokhov
> >> Cc: Benjamin Tissoires
> >> Cc: Daniel Vetter
> >> Cc: Arvind Yadav
> >> Cc: Stephen Lyons
> >> Cc: linux-in...@vger.kernel.org
> >> ---
> >> drivers/input/mouse/psmouse-base.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/input/mouse/psmouse-base.c
> >> b/drivers/input/mouse/psmouse-base.c
> >> index 8900c3166ebf..06ccd8e22f3c 100644
> >> --- a/drivers/input/mouse/psmouse-base.c
> >> +++ b/drivers/input/mouse/psmouse-base.c
> >> @@ -1484,8 +1484,10 @@ static void psmouse_disconnect(struct serio *serio)
> >> psmouse_deactivate(parent);
> >> }
> >>
> >> + mutex_unlock(_mutex);
Re: [Intel-gfx] [PATCH 37/40] drm/i915: Allow a context to define its set of engines
On 28/09/2018 21:22, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-09-27 12:28:47)
On 19/09/2018 20:55, Chris Wilson wrote:
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
The I915_EXEC_DEFAULT slot is left empty, and invalid for use by
execbuf. It's use will be revealed in the next patch.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c| 88 ++
drivers/gpu/drm/i915/i915_gem_context.h| 4 +
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 22 --
include/uapi/drm/i915_drm.h| 27 +++
4 files changed, 135 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index a8570a07b3b7..313471253f51 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -90,6 +90,7 @@
#include
#include "i915_drv.h"
#include "i915_trace.h"
+#include "i915_user_extensions.h"
#include "intel_workarounds.h"
#define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
@@ -223,6 +224,8 @@ static void i915_gem_context_free(struct i915_gem_context
*ctx)
ce->ops->destroy(ce);
}
+ kfree(ctx->engines);
+
if (ctx->timeline)
i915_timeline_put(ctx->timeline);
@@ -948,6 +951,87 @@ int i915_gem_context_getparam_ioctl(struct drm_device *dev, void *data,
return ret;
}
+struct set_engines {
+ struct i915_gem_context *ctx;
+ struct intel_engine_cs **engines;
+ unsigned int nengine;
+};
+
+static const i915_user_extension_fn set_engines__extensions[] = {
+};
This is OK unless someone one day gets the desire to make the extension
namespace sparse. I was thinking on how to put some warnings in the code
to warn about it, but I think that's for later. Namespace is also per
parent ioctl, another thing which would perhaps need enforcing.
Unless you intend to go extremely sparse, I'd just leave it with the
usual [NAME1] = func1, and skipping over NULLs. We can always add
alternatives if need be (I'd actually been meaning to convert execbuf3
over to this scheme to flesh it out a bit more).
It is fine for now, I was just thinking out loud how to protect us
against the table accidentally growing huge one day.
+static int set_engines(struct i915_gem_context *ctx,
+struct drm_i915_gem_context_param *args)
+{
+ struct i915_context_param_engines __user *user;
+ struct set_engines set = {
+ .ctx = ctx,
+ .engines = NULL,
+ .nengine = -1,
+ };
+ unsigned int n;
+ u64 size, extensions;
Size is u32 in the uAPI, so either that or unsigned int would do here.
+ int err;
+
+ user = u64_to_user_ptr(args->value);
+ size = args->size;
+ if (!size)
args->sizes = sizeof(*user);
... if you want to allow size probing via set param, or we add a
get_param (too much work for nothing?) and only allow probing from there?
It's a variable array, so a little trickier.
Indeed!
+ goto out;
+
+ if (size < sizeof(struct i915_context_param_engines))
+ return -EINVAL;
+
+ size -= sizeof(struct i915_context_param_engines);
+ if (size % sizeof(*user->class_instance))
+ return -EINVAL;
+
+ set.nengine = size / sizeof(*user->class_instance);
+ if (set.nengine == 0 || set.nengine >= I915_EXEC_RING_MASK)
+ return -EINVAL;
+
+ set.engines = kmalloc_array(set.nengine + 1,
+ sizeof(*set.engines),
+ GFP_KERNEL);
+ if (!set.engines)
+ return -ENOMEM;
+
+ set.engines[0] = NULL;
/* Reserve the I915_EXEC_DEFAULT slot. */
+ for (n = 0; n < set.nengine; n++) {
+ u32 class, instance;
I will later recommend we use u16 for class/instance. I think we settled
for that in the meantime.
+
+ if (get_user(class, >class_instance[n].class) ||
+ get_user(instance,
Re: [Intel-gfx] [PATCH i-g-t 3/5] lib: Report if kms is enabled on the display
On Fri, Sep 14, 2018 at 09:13:08PM +0100, Chris Wilson wrote:
> Some drivers may have disabled KMS or there may simply nothing attached
> to the device. In either case KMS is unusable and we may prefer to skip.
>
> Signed-off-by: Chris Wilson
> ---
> lib/igt_kms.c | 14 --
> lib/igt_kms.h | 3 ++-
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index 4563bfd9d..9710bcae1 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -1843,8 +1843,9 @@ static void igt_fill_display_format_mod(igt_display_t
> *display);
> * Initialize @display and allocate the various resources required. Use
> * #igt_display_fini to release the resources when they are no longer
> required.
> *
> + * Returns: true if the display has outputs and pipes available, false
> otherwise
> */
> -void igt_display_init(igt_display_t *display, int drm_fd)
> +bool igt_display_init(igt_display_t *display, int drm_fd)
> {
> drmModeRes *resources;
> drmModePlaneRes *plane_resources;
> @@ -1857,7 +1858,8 @@ void igt_display_init(igt_display_t *display, int
> drm_fd)
> display->drm_fd = drm_fd;
>
> resources = drmModeGetResources(display->drm_fd);
> - igt_assert(resources);
> + if (!resources)
> + goto out;
>
> /*
>* We cache the number of pipes, that number is a physical limit of the
> @@ -2004,7 +2006,15 @@ void igt_display_init(igt_display_t *display, int
> drm_fd)
> /* Set reasonable default values for every object in the display. */
> igt_display_reset(display);
>
> +out:
> LOG_UNINDENT(display);
> +
> + return display->n_pipes && display->n_outputs;
> +}
> +
Do we have any genuine cases where we want to init the display helpers and
not require pipes/outputs? I'm kinda leaning towards keeping the helper
api as-is, and putting the igt_require into igt_display_init(). We can
always have an __igt_display_init or stuff a bunch of subtests into an
igt_subtest_group.
-Daniel
> +void igt_display_require(igt_display_t *display, int drm_fd)
> +{
> + igt_require(igt_display_init(display, drm_fd));
> }
>
> /**
> diff --git a/lib/igt_kms.h b/lib/igt_kms.h
> index 3862efa28..73624399b 100644
> --- a/lib/igt_kms.h
> +++ b/lib/igt_kms.h
> @@ -378,7 +378,8 @@ struct igt_display {
> int format_mod_count;
> };
>
> -void igt_display_init(igt_display_t *display, int drm_fd);
> +bool igt_display_init(igt_display_t *display, int drm_fd);
> +void igt_display_require(igt_display_t *display, int drm_fd);
> void igt_display_fini(igt_display_t *display);
> void igt_display_reset(igt_display_t *display);
> int igt_display_commit2(igt_display_t *display, enum igt_commit_style s);
> --
> 2.19.0
>
> ___
> 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
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 4/5] lib/kms: Skip no-op display updates
On Fri, Sep 14, 2018 at 09:13:09PM +0100, Chris Wilson wrote:
> If the display is disabled (e.g. the driver has disabled the KMS
> interface) there is nothing to do so avoid failing.
>
> Signed-off-by: Chris Wilson
Silently doing nothing feels funny, I think putting the igt_require into
igt_display_init makes more sense with this one in mind. Also avoids the
churn in patch 5.
-Daniel
> ---
> lib/igt_kms.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index 9710bcae1..dedc81344 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -3271,6 +3271,9 @@ static int do_display_commit(igt_display_t *display,
> enum pipe pipe;
> LOG_INDENT(display, "commit");
>
> + if (!display->n_pipes || !display->n_outputs)
> + return 0; /* nothing to do */
> +
> igt_display_refresh(display);
>
> if (s == COMMIT_ATOMIC) {
> @@ -3321,6 +3324,9 @@ int igt_display_try_commit_atomic(igt_display_t
> *display, uint32_t flags, void *
> {
> int ret;
>
> + if (!display->n_pipes || !display->n_outputs)
> + return 0; /* nothing to do */
> +
> LOG_INDENT(display, "commit");
>
> igt_display_refresh(display);
> --
> 2.19.0
>
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/3] drm/i915/icl: Restructure ICL DPLL enable functionality
> -Original Message-
> From: Ville Syrjälä
> Sent: Wednesday, September 26, 2018 7:57 PM
> To: Kulkarni, Vandita
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ;
> Zanoni, Paulo R
> Subject: Re: [Intel-gfx] [RFC 1/3] drm/i915/icl: Restructure ICL DPLL enable
> functionality
>
> On Wed, Sep 19, 2018 at 05:31:37PM +, Kulkarni, Vandita wrote:
> >
> >
> > > -Original Message-
> > > From: Ville Syrjälä
> > > Sent: Friday, September 14, 2018 9:37 PM
> > > To: Kulkarni, Vandita
> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > > ; Zanoni, Paulo R
> > > Subject: Re: [Intel-gfx] [RFC 1/3] drm/i915/icl: Restructure ICL
> > > DPLL enable functionality
> > >
> > > On Fri, Sep 14, 2018 at 12:24:12PM +0530, Vandita Kulkarni wrote:
> > > > From: Madhav Chauhan
> > > >
> > > > In Gen11, DPLL 0 and 1 are shared between DDI and DSI.
> > > > Most of the steps for enabling DPLL are common across DDI and DSI.
> > > > This patch makes icl_dpll_enable() generic which will be used by
> > > > all the encoders.
> > > >
> > > > Signed-off-by: Madhav Chauhan
> > > > Signed-off-by: Vandita Kulkarni
> > > > ---
> > > > drivers/gpu/drm/i915/intel_ddi.c | 12
> > > > drivers/gpu/drm/i915/intel_dpll_mgr.c | 19 ++-
> > > > drivers/gpu/drm/i915/intel_dpll_mgr.h | 2 +-
> > > > 3 files changed, 15 insertions(+), 18 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > index cd01a09..2942a24 100644
> > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > @@ -2810,6 +2810,18 @@ static void intel_ddi_clk_select(struct
> > > intel_encoder *encoder,
> > > > mutex_lock(_priv->dpll_lock);
> > > >
> > > > if (IS_ICELAKE(dev_priv)) {
> > > > + enum intel_dpll_id id = pll->info->id;
> > > > + i915_reg_t enable_reg = icl_pll_id_to_enable_reg(id);
> > > > +
> > > > + val = I915_READ(enable_reg);
> > > > + val |= PLL_ENABLE;
> > > > + I915_WRITE(enable_reg, val);
> > > > +
> > > > + /* TODO: wait times missing from the spec. */
> > > > + if (intel_wait_for_register(dev_priv, enable_reg,
> > > > PLL_LOCK,
> > > > + PLL_LOCK, 5))
> > > > + DRM_ERROR("PLL %d not locked\n", id);
> > > > +
> > >
> > > I don't really see why this can't stay in the dpll mgr.
> > This was part of icl_pll_enable, which gets called for all hdmi, dp and
> > mipi dsi.
> > But for mipi dsi we have couple of more things to do before we enable pll.
> >
> > In order to keep it unchanged for other encoders , pll enable was moved
> > here.
> > Another way could be have an encoder check in icl_pll_enable function and do
> those extra steps for mipi dsi and then enable the pll.
> > Please let me know what you think would be a better way to do.
>
> Hard to judge what is best without knowing what the differences are.
As per the bspec,
The below two steps are the extra ones that we do before enabling the PLL
1. Configure both DSI_ESC_CLK_DIV and DPHY_ESC_CLK_DIV registers. Both
registers must be programmed with the same value.
2. Read back both DPHY_ESC_CLK_DIV, ignoring the data value, this is to ensure
write completed before the next step.
And these steps below
Configure DPCLKA_CFGCR0 to map the DPLL to the DDI/DSI.
Make sure that the DDI clocks are not gated at this point. The DSI enabling
sequence will gate the DDI clocks at a later point within the sequence.
are done before pll enable in case of pll enable sequence for mipi dsi.
Thanks
Vandita
>
> >
> > Thanks,
> > Vandita
> > >
> > > > if (port >= PORT_C)
> > > > I915_WRITE(DDI_CLK_SEL(port),
> > > >icl_pll_to_ddi_pll_sel(encoder,
> > > > pll)); diff --git
> > > > a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > index e6cac92..36ed155 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > @@ -2930,7 +2930,7 @@ static bool icl_calc_mg_pll_state(struct
> > > intel_crtc_state *crtc_state,
> > > > return pll;
> > > > }
> > > >
> > > > -static i915_reg_t icl_pll_id_to_enable_reg(enum intel_dpll_id id)
> > > > +i915_reg_t icl_pll_id_to_enable_reg(enum intel_dpll_id id)
> > > > {
> > > > switch (id) {
> > > > default:
> > > > @@ -3119,22 +3119,7 @@ static void icl_pll_enable(struct
> > > > drm_i915_private
> > > *dev_priv,
> > > > default:
> > > > MISSING_CASE(id);
> > > > }
> > > > -
> > > > - /*
> > > > -* DVFS pre sequence would be here, but in our driver the cdclk
> > > > code
> > > > -* paths should already be setting the appropriate voltage,
> > > > hence we do
> > > > -* nothign
Re: [Intel-gfx] [PATCH 6/6] drm/i915/icl: Support co-existence between per-context SSEU and OA
On 01/10/2018 15:18, Lionel Landwerlin wrote:
On 01/10/2018 13:42, Tvrtko Ursulin wrote:
On 01/10/2018 12:06, Lionel Landwerlin wrote:
On 01/10/2018 12:20, Tvrtko Ursulin wrote:
On 01/10/2018 10:50, Lionel Landwerlin wrote:
On 17/09/2018 13:30, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
When OA is active we want to lock the powergating configuration,
but on
Icelake, users like the media stack will have issues if we lock to
the
full device configuration.
Instead lock to a subset of (sub)slices which are currently a known
working configuration for all users.
v2:
* Fix commit message spelling.
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
---
drivers/gpu/drm/i915/intel_lrc.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index b5603e977a3f..cded1f1d9ec2 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2521,13 +2521,28 @@ u32 gen8_make_rpcs(struct drm_i915_private
*i915, struct intel_sseu *req_sseu)
/*
* If i915/perf is active, we want a stable powergating
configuration
- * on the system. The most natural configuration to take in
that case
- * is the default (i.e maximum the hardware can do).
+ * on the system.
+ *
+ * We could choose full enablement, but on ICL we know there
are use
+ * cases which disable slices for functional, apart for
performance
+ * reasons. So in this case we select a known stable subset.
*/
- if (unlikely(i915->perf.oa.exclusive_stream))
- ctx_sseu = intel_device_default_sseu(i915);
- else
+ if (!i915->perf.oa.exclusive_stream) {
ctx_sseu = *req_sseu;
+ } else {
+ ctx_sseu = intel_device_default_sseu(i915);
+
+ if (IS_GEN11(i915)) {
+ /*
+ * We only need subslice count so it doesn't matter
+ * which ones we select - just turn of low bits in the
s/turn of/turn off/
Yep, thanks.
+ * amount of half of all available subslices per slice.
+ */
+ ctx_sseu.subslice_mask =
+ ~(~0 << (hweight8(ctx_sseu.subslice_mask) / 2));
I would go with :
ctx_sseu.subslice_mask = ctx_sseu.subslice_mask & 0xf;
Documentation says that the first 4 subslices are the "big" ones
(gathered from the fusing register fields which go from
slice0-subslice[0-3] then slice1-subslice[0-3], etc...), so this
should be equally media/3d capable.
Doesn't work I think - one 1x6x8 part I've seen has a subslice mask
of 0b1100 and there we want to have three subslices enabled.
Regards,
Tvrtko
Thanks, then the fusing fields don't match for a big/small sets of
subslices.
I guess the fusing might be in this pattern (Small/Big) : SBSBSBSB
I was hoping we could know so that we program the powergating at the
most capable configuration.
It will be the most capable configuration. Did you forget the RPCS
register in ICL works with counts and not masks? According the that
Bspec table we cannot select anything but the most capable configuration.
Regards,
Tvrtko
Sorry, I must have forgotten. I was trying to read the docs again
looking for something that said the fusing always happened in pairs.
I'm confident we need to limit the subslices when OA is on and if you
know where the details are written down (maybe add the bspec number?),
this is :
Hm I was certain I have put the link in some time ago, but you are
right, I have not so will do!
Reviewed-by: Lionel Landwerlin
Thanks!
Regards,
Tvrtko
___
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: Restore vblank interrupts earlier
== Series Details == Series: series starting with [1/3] drm/i915: Restore vblank interrupts earlier URL : https://patchwork.freedesktop.org/series/50393/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4907 -> Patchwork_10307 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/50393/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10307 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s3: fi-bdw-samus: PASS -> INCOMPLETE (fdo#107773) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-icl-u: PASS -> INCOMPLETE (fdo#107713) Possible fixes igt@drv_module_reload@basic-reload: fi-glk-j4005: DMESG-WARN (fdo#106725, fdo#106248) -> PASS igt@gem_exec_suspend@basic-s3: fi-blb-e6850: INCOMPLETE (fdo#107718) -> PASS igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: DMESG-WARN (fdo#106000) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-skl-caroline:INCOMPLETE (fdo#104108, fdo#107556, fdo#107773) -> PASS igt@pm_rpm@module-reload: fi-glk-j4005: FAIL (fdo#104767) -> PASS fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108 fdo#104767 https://bugs.freedesktop.org/show_bug.cgi?id=104767 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248 fdo#106725 https://bugs.freedesktop.org/show_bug.cgi?id=106725 fdo#107556 https://bugs.freedesktop.org/show_bug.cgi?id=107556 fdo#107713 https://bugs.freedesktop.org/show_bug.cgi?id=107713 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773 == Participating hosts (52 -> 47) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4907 -> Patchwork_10307 CI_DRM_4907: d628a99df39be84d6fd0a608bf2ab2185dcd6a26 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4658: cab89ce2c5da684d01deff402d4e8e11441beadb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10307: 56da01b165ac0fbb4f3ae68d0ef9aa15075b2cd5 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 56da01b165ac drm/i915: Clean up early plane debugs ab4d85399a55 drm/i915: Use the correct crtc when sanitizing plane mapping 3d421aa28f28 drm/i915: Restore vblank interrupts earlier == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10307/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/8] drm/i915: Add a new "remapped" gtt_view
On 01/10/2018 16:37, Chris Wilson wrote: Quoting Ville Syrjälä (2018-10-01 16:27:43) On Mon, Oct 01, 2018 at 04:12:09PM +0100, Chris Wilson wrote: Quoting Ville Syrjälä (2018-10-01 16:03:30) On Wed, Sep 26, 2018 at 08:50:25AM +0100, Tvrtko Ursulin wrote: On 25/09/2018 20:37, Ville Syrjala wrote: One more thing, do you really need random access for this transformation? Or you could walk the sg list as it is? Just if you hit a too long chunk you need to copy a trimmed version over and know where to continue for the next row. If doable it would be better than having to kvmalloc_array. I think Chris suggested just using i915_gem_object_get_dma_address() here. But I'm not sure why we're not using it for rotate_pages() as well. Tvrtko is opposed to populating the obj->mm.pages cache with no defined release point. I say the mempressure and shrinker should to the right thing, but it's a big if. OK. Well, looks to me like i915_gem_object_get_dma_address() is the only convenient looking thing for iterating the pages without arowning the code in irrelevant details about sgs and whatnot. I suppose it should be possible to write some helpers that avoid all that and don't need the temp array, but I'm not really motivated enough to do that myself. Keep it simple and use get_dma_address(). We can find ways to throw away the cache later if need be. I'd do it straight away. I think cache for a large framebuffer, the kind which needs remapping could be quite big! Even the more fragmented memory the bigger the cache, and so if it sticks around pointlessly for the lifetime of the framebuffer it is a double whammy. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Engine discovery query
Hi,
Media experts please scroll down...
On 01/10/2018 17:15, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Engine discovery query allows userspace to enumerate engines, probe their
configuration features, all without needing to maintain the internal PCI
ID based database.
A new query for the generic i915 query ioctl is added named
DRM_I915_QUERY_ENGINE_INFO, together with accompanying structure
drm_i915_query_engine_info. The address of latter should be passed to the
kernel in the query.data_ptr field, and should be large enough for the
kernel to fill out all known engines as struct drm_i915_engine_info
elements trailing the query.
As with other queries, setting the item query length to zero allows
userspace to query minimum required buffer size.
Enumerated engines have common type mask which can be used to query all
hardware engines, versus engines userspace can submit to using the execbuf
uAPI.
Engines also have capabilities which are per engine class namespace of
bits describing features not present on all engine instances.
v2:
* Fixed HEVC assignment.
* Reorder some fields, rename type to flags, increase width. (Lionel)
* No need to allocate temporary storage if we do it engine by engine.
(Lionel)
v3:
* Describe engine flags and mark mbz fields. (Lionel)
* HEVC only applies to VCS.
v4:
* Squash SFC flag into main patch.
* Tidy some comments.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Jon Bloomfield
Cc: Dmitry Rogozhkin
Cc: Lionel Landwerlin
Cc: Joonas Lahtinen
Cc: Tony Ye
---
drivers/gpu/drm/i915/i915_query.c | 63 +
drivers/gpu/drm/i915/intel_engine_cs.c | 9
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 ++
include/uapi/drm/i915_drm.h | 54 +
4 files changed, 129 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 5821002cad42..294f8195efa7 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -84,9 +84,72 @@ static int query_topology_info(struct drm_i915_private
*dev_priv,
return total_length;
}
+static int
+query_engine_info(struct drm_i915_private *i915,
+ struct drm_i915_query_item *query_item)
+{
+ struct drm_i915_query_engine_info __user *query_ptr =
+ u64_to_user_ptr(query_item->data_ptr);
+ struct drm_i915_engine_info __user *info_ptr = _ptr->engines[0];
+ struct drm_i915_query_engine_info query;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ int len;
+
+ if (query_item->flags)
+ return -EINVAL;
+
+ len = sizeof(struct drm_i915_query_engine_info) +
+ I915_NUM_ENGINES * sizeof(struct drm_i915_engine_info);
+
+ if (!query_item->length)
+ return len;
+ else if (query_item->length < len)
+ return -EINVAL;
+
+ if (copy_from_user(, query_ptr, sizeof(query)))
+ return -EFAULT;
+
+ if (query.num_engines || query.rsvd[0] || query.rsvd[1] ||
+ query.rsvd[2])
+ return -EINVAL;
+
+ if (!access_ok(VERIFY_WRITE, query_ptr, query_item->length))
+ return -EFAULT;
+
+ for_each_engine(engine, i915, id) {
+ struct drm_i915_engine_info info;
+
+ if (__copy_from_user(, info_ptr, sizeof(info)))
+ return -EFAULT;
+
+ if (info.flags || info.class || info.instance ||
+ info.capabilities || info.rsvd0 || info.rsvd1[0] ||
+ info.rsvd1[1])
+ return -EINVAL;
+
+ info.class = engine->uabi_class;
+ info.instance = engine->instance;
+ info.flags = I915_ENGINE_FLAG_PHYSICAL | I915_ENGINE_FLAG_ABI;
+ info.capabilities = engine->capabilities;
+
+ if (__copy_to_user(info_ptr, , sizeof(info)))
+ return -EFAULT;
+
+ query.num_engines++;
+ info_ptr++;
+ }
+
+ if (__copy_to_user(query_ptr, , sizeof(query)))
+ return -EFAULT;
+
+ return len;
+}
+
static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
struct drm_i915_query_item *query_item)
= {
query_topology_info,
+ query_engine_info,
};
int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 1c6143bdf5a4..97b4acf8af5c 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -294,6 +294,15 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
engine->mmio_base = __engine_mmio_base(dev_priv, info->mmio_bases);
engine->class = info->class;
engine->instance = info->instance;
+
Re: [Intel-gfx] [PATCH] drm/i915: Engine discovery query
Quoting Tvrtko Ursulin (2018-10-01 17:15:24)
> From: Tvrtko Ursulin
>
> Engine discovery query allows userspace to enumerate engines, probe their
> configuration features, all without needing to maintain the internal PCI
> ID based database.
>
> A new query for the generic i915 query ioctl is added named
> DRM_I915_QUERY_ENGINE_INFO, together with accompanying structure
> drm_i915_query_engine_info. The address of latter should be passed to the
> kernel in the query.data_ptr field, and should be large enough for the
> kernel to fill out all known engines as struct drm_i915_engine_info
> elements trailing the query.
>
> As with other queries, setting the item query length to zero allows
> userspace to query minimum required buffer size.
>
> Enumerated engines have common type mask which can be used to query all
> hardware engines, versus engines userspace can submit to using the execbuf
> uAPI.
>
> Engines also have capabilities which are per engine class namespace of
> bits describing features not present on all engine instances.
>
> v2:
> * Fixed HEVC assignment.
> * Reorder some fields, rename type to flags, increase width. (Lionel)
> * No need to allocate temporary storage if we do it engine by engine.
>(Lionel)
>
> v3:
> * Describe engine flags and mark mbz fields. (Lionel)
> * HEVC only applies to VCS.
>
> v4:
> * Squash SFC flag into main patch.
> * Tidy some comments.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
> Cc: Jon Bloomfield
> Cc: Dmitry Rogozhkin
> Cc: Lionel Landwerlin
> Cc: Joonas Lahtinen
> Cc: Tony Ye
> ---
> drivers/gpu/drm/i915/i915_query.c | 63 +
> drivers/gpu/drm/i915/intel_engine_cs.c | 9
> drivers/gpu/drm/i915/intel_ringbuffer.h | 3 ++
> include/uapi/drm/i915_drm.h | 54 +
> 4 files changed, 129 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_query.c
> b/drivers/gpu/drm/i915/i915_query.c
> index 5821002cad42..294f8195efa7 100644
> --- a/drivers/gpu/drm/i915/i915_query.c
> +++ b/drivers/gpu/drm/i915/i915_query.c
> @@ -84,9 +84,72 @@ static int query_topology_info(struct drm_i915_private
> *dev_priv,
> return total_length;
> }
>
> +static int
> +query_engine_info(struct drm_i915_private *i915,
> + struct drm_i915_query_item *query_item)
> +{
> + struct drm_i915_query_engine_info __user *query_ptr =
> + u64_to_user_ptr(query_item->data_ptr);
> + struct drm_i915_engine_info __user *info_ptr = _ptr->engines[0];
> + struct drm_i915_query_engine_info query;
> + struct intel_engine_cs *engine;
> + enum intel_engine_id id;
> + int len;
> +
> + if (query_item->flags)
> + return -EINVAL;
> +
> + len = sizeof(struct drm_i915_query_engine_info) +
> + I915_NUM_ENGINES * sizeof(struct drm_i915_engine_info);
Since I915_NUM_ENGINES is not ABI, and this will be using a 2-step
query (1st to find length, 2nd to grab details), it should work with
info->num_rings. If not, we have problems later ;)
> +
> + if (!query_item->length)
> + return len;
> + else if (query_item->length < len)
> + return -EINVAL;
> +
> + if (copy_from_user(, query_ptr, sizeof(query)))
> + return -EFAULT;
> +
> + if (query.num_engines || query.rsvd[0] || query.rsvd[1] ||
> + query.rsvd[2])
> + return -EINVAL;
> +
> + if (!access_ok(VERIFY_WRITE, query_ptr, query_item->length))
> + return -EFAULT;
> +
> + for_each_engine(engine, i915, id) {
> + struct drm_i915_engine_info info;
> +
> + if (__copy_from_user(, info_ptr, sizeof(info)))
> + return -EFAULT;
> +
> + if (info.flags || info.class || info.instance ||
> + info.capabilities || info.rsvd0 || info.rsvd1[0] ||
> + info.rsvd1[1])
> + return -EINVAL;
> +
> + info.class = engine->uabi_class;
> + info.instance = engine->instance;
> + info.flags = I915_ENGINE_FLAG_PHYSICAL | I915_ENGINE_FLAG_ABI;
> + info.capabilities = engine->capabilities;
> +
> + if (__copy_to_user(info_ptr, , sizeof(info)))
> + return -EFAULT;
> +
> + query.num_engines++;
> + info_ptr++;
> + }
> +
> + if (__copy_to_user(query_ptr, , sizeof(query)))
> + return -EFAULT;
> +
> + return len;
> +}
> +
> static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
> struct drm_i915_query_item
> *query_item) = {
> query_topology_info,
> + query_engine_info,
> };
>
> int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file
> *file)
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
>
Re: [Intel-gfx] [PATCH v3 3/8] drm/i915: Add a new "remapped" gtt_view
Quoting Ville Syrjälä (2018-10-01 16:03:30) > On Wed, Sep 26, 2018 at 08:50:25AM +0100, Tvrtko Ursulin wrote: > > > > On 25/09/2018 20:37, Ville Syrjala wrote: > > One more thing, do you really need random access for this > > transformation? Or you could walk the sg list as it is? Just if you hit > > a too long chunk you need to copy a trimmed version over and know where > > to continue for the next row. If doable it would be better than having > > to kvmalloc_array. > > I think Chris suggested just using i915_gem_object_get_dma_address() > here. But I'm not sure why we're not using it for rotate_pages() > as well. Tvrtko is opposed to populating the obj->mm.pages cache with no defined release point. I say the mempressure and shrinker should to the right thing, but it's a big if. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/8] drm/i915: Add a new "remapped" gtt_view
On Mon, Oct 01, 2018 at 04:12:09PM +0100, Chris Wilson wrote: > Quoting Ville Syrjälä (2018-10-01 16:03:30) > > On Wed, Sep 26, 2018 at 08:50:25AM +0100, Tvrtko Ursulin wrote: > > > > > > On 25/09/2018 20:37, Ville Syrjala wrote: > > > One more thing, do you really need random access for this > > > transformation? Or you could walk the sg list as it is? Just if you hit > > > a too long chunk you need to copy a trimmed version over and know where > > > to continue for the next row. If doable it would be better than having > > > to kvmalloc_array. > > > > I think Chris suggested just using i915_gem_object_get_dma_address() > > here. But I'm not sure why we're not using it for rotate_pages() > > as well. > > Tvrtko is opposed to populating the obj->mm.pages cache with no defined > release point. I say the mempressure and shrinker should to the right > thing, but it's a big if. OK. Well, looks to me like i915_gem_object_get_dma_address() is the only convenient looking thing for iterating the pages without arowning the code in irrelevant details about sgs and whatnot. I suppose it should be possible to write some helpers that avoid all that and don't need the temp array, but I'm not really motivated enough to do that myself. -- 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 3/8] drm/i915: Add a new "remapped" gtt_view
On 01/10/2018 16:12, Chris Wilson wrote: Quoting Ville Syrjälä (2018-10-01 16:03:30) On Wed, Sep 26, 2018 at 08:50:25AM +0100, Tvrtko Ursulin wrote: On 25/09/2018 20:37, Ville Syrjala wrote: One more thing, do you really need random access for this transformation? Or you could walk the sg list as it is? Just if you hit a too long chunk you need to copy a trimmed version over and know where to continue for the next row. If doable it would be better than having to kvmalloc_array. I think Chris suggested just using i915_gem_object_get_dma_address() here. But I'm not sure why we're not using it for rotate_pages() as well. Tvrtko is opposed to populating the obj->mm.pages cache with no defined release point. I say the mempressure and shrinker should to the right thing, but it's a big if. Wasn't there some compromise we agreed last time? Like that you would just add an API to drop the cache? So users like this one and rotation, where it is known to be very unlikely the cache would be used again, would be able to drop it immediately after remapping? But maybe you had an argument that the cache could be used after all? So pread/pwrite on framebuffers likely? Relocations wouldn't be. Is there something else? Maybe we should resolve this since it's been going for a very long time. :) Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/8] drm/i915: Add a new "remapped" gtt_view
Quoting Ville Syrjälä (2018-10-01 16:27:43) > On Mon, Oct 01, 2018 at 04:12:09PM +0100, Chris Wilson wrote: > > Quoting Ville Syrjälä (2018-10-01 16:03:30) > > > On Wed, Sep 26, 2018 at 08:50:25AM +0100, Tvrtko Ursulin wrote: > > > > > > > > On 25/09/2018 20:37, Ville Syrjala wrote: > > > > One more thing, do you really need random access for this > > > > transformation? Or you could walk the sg list as it is? Just if you hit > > > > a too long chunk you need to copy a trimmed version over and know where > > > > to continue for the next row. If doable it would be better than having > > > > to kvmalloc_array. > > > > > > I think Chris suggested just using i915_gem_object_get_dma_address() > > > here. But I'm not sure why we're not using it for rotate_pages() > > > as well. > > > > Tvrtko is opposed to populating the obj->mm.pages cache with no defined > > release point. I say the mempressure and shrinker should to the right > > thing, but it's a big if. > > OK. > > Well, looks to me like i915_gem_object_get_dma_address() is the > only convenient looking thing for iterating the pages without > arowning the code in irrelevant details about sgs and whatnot. > I suppose it should be possible to write some helpers that avoid > all that and don't need the temp array, but I'm not really > motivated enough to do that myself. Keep it simple and use get_dma_address(). We can find ways to throw away the cache later if need be. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/8] drm/i915: Add a new "remapped" gtt_view
On 01/10/2018 16:27, Ville Syrjälä wrote: On Mon, Oct 01, 2018 at 04:12:09PM +0100, Chris Wilson wrote: Quoting Ville Syrjälä (2018-10-01 16:03:30) On Wed, Sep 26, 2018 at 08:50:25AM +0100, Tvrtko Ursulin wrote: On 25/09/2018 20:37, Ville Syrjala wrote: One more thing, do you really need random access for this transformation? Or you could walk the sg list as it is? Just if you hit a too long chunk you need to copy a trimmed version over and know where to continue for the next row. If doable it would be better than having to kvmalloc_array. I think Chris suggested just using i915_gem_object_get_dma_address() here. But I'm not sure why we're not using it for rotate_pages() as well. Tvrtko is opposed to populating the obj->mm.pages cache with no defined release point. I say the mempressure and shrinker should to the right thing, but it's a big if. OK. Well, looks to me like i915_gem_object_get_dma_address() is the only convenient looking thing for iterating the pages without arowning the code in irrelevant details about sgs and whatnot. I suppose it should be possible to write some helpers that avoid all that and don't need the temp array, but I'm not really motivated enough to do that myself. That's fine by me, I primarily suggested you could coalesce and trim when done. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Engine discovery query
Hi,
Media experts please scroll down...
On 01/10/2018 17:15, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Engine discovery query allows userspace to enumerate engines, probe their
configuration features, all without needing to maintain the internal PCI
ID based database.
A new query for the generic i915 query ioctl is added named
DRM_I915_QUERY_ENGINE_INFO, together with accompanying structure
drm_i915_query_engine_info. The address of latter should be passed to the
kernel in the query.data_ptr field, and should be large enough for the
kernel to fill out all known engines as struct drm_i915_engine_info
elements trailing the query.
As with other queries, setting the item query length to zero allows
userspace to query minimum required buffer size.
Enumerated engines have common type mask which can be used to query all
hardware engines, versus engines userspace can submit to using the execbuf
uAPI.
Engines also have capabilities which are per engine class namespace of
bits describing features not present on all engine instances.
v2:
* Fixed HEVC assignment.
* Reorder some fields, rename type to flags, increase width. (Lionel)
* No need to allocate temporary storage if we do it engine by engine.
(Lionel)
v3:
* Describe engine flags and mark mbz fields. (Lionel)
* HEVC only applies to VCS.
v4:
* Squash SFC flag into main patch.
* Tidy some comments.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Jon Bloomfield
Cc: Dmitry Rogozhkin
Cc: Lionel Landwerlin
Cc: Joonas Lahtinen
Cc: Tony Ye
---
drivers/gpu/drm/i915/i915_query.c | 63 +
drivers/gpu/drm/i915/intel_engine_cs.c | 9
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 ++
include/uapi/drm/i915_drm.h | 54 +
4 files changed, 129 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 5821002cad42..294f8195efa7 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -84,9 +84,72 @@ static int query_topology_info(struct drm_i915_private
*dev_priv,
return total_length;
}
+static int
+query_engine_info(struct drm_i915_private *i915,
+ struct drm_i915_query_item *query_item)
+{
+ struct drm_i915_query_engine_info __user *query_ptr =
+ u64_to_user_ptr(query_item->data_ptr);
+ struct drm_i915_engine_info __user *info_ptr = _ptr->engines[0];
+ struct drm_i915_query_engine_info query;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ int len;
+
+ if (query_item->flags)
+ return -EINVAL;
+
+ len = sizeof(struct drm_i915_query_engine_info) +
+ I915_NUM_ENGINES * sizeof(struct drm_i915_engine_info);
+
+ if (!query_item->length)
+ return len;
+ else if (query_item->length < len)
+ return -EINVAL;
+
+ if (copy_from_user(, query_ptr, sizeof(query)))
+ return -EFAULT;
+
+ if (query.num_engines || query.rsvd[0] || query.rsvd[1] ||
+ query.rsvd[2])
+ return -EINVAL;
+
+ if (!access_ok(VERIFY_WRITE, query_ptr, query_item->length))
+ return -EFAULT;
+
+ for_each_engine(engine, i915, id) {
+ struct drm_i915_engine_info info;
+
+ if (__copy_from_user(, info_ptr, sizeof(info)))
+ return -EFAULT;
+
+ if (info.flags || info.class || info.instance ||
+ info.capabilities || info.rsvd0 || info.rsvd1[0] ||
+ info.rsvd1[1])
+ return -EINVAL;
+
+ info.class = engine->uabi_class;
+ info.instance = engine->instance;
+ info.flags = I915_ENGINE_FLAG_PHYSICAL | I915_ENGINE_FLAG_ABI;
+ info.capabilities = engine->capabilities;
+
+ if (__copy_to_user(info_ptr, , sizeof(info)))
+ return -EFAULT;
+
+ query.num_engines++;
+ info_ptr++;
+ }
+
+ if (__copy_to_user(query_ptr, , sizeof(query)))
+ return -EFAULT;
+
+ return len;
+}
+
static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
struct drm_i915_query_item *query_item)
= {
query_topology_info,
+ query_engine_info,
};
int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 1c6143bdf5a4..97b4acf8af5c 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -294,6 +294,15 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
engine->mmio_base = __engine_mmio_base(dev_priv, info->mmio_bases);
engine->class = info->class;
engine->instance = info->instance;
+
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/dp: Validate the downclock mode for eDP if it exists
On Wed, Sep 12, 2018 at 03:57:18PM -0700, Manasi Navare wrote:
> With downclock mode and DRRS now operating independently user can
> request a modeset on downclock mode. In that case intel_dp_mode_valid()
> should validate the downclock mode as well if that is requested.
>
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/intel_dp.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 30526c02b343..0e400629e85c 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -615,6 +615,8 @@ intel_dp_mode_valid(struct drm_connector *connector,
> struct intel_dp *intel_dp = intel_attached_dp(connector);
> struct intel_connector *intel_connector = to_intel_connector(connector);
> struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
> + struct drm_display_mode *downclock_mode =
> + intel_connector->panel.downclock_mode;
> int target_clock = mode->clock;
> int max_rate, mode_rate, max_lanes, max_link_clock;
> int max_dotclk;
> @@ -631,7 +633,10 @@ intel_dp_mode_valid(struct drm_connector *connector,
> if (mode->vdisplay > fixed_mode->vdisplay)
> return MODE_PANEL;
>
> - target_clock = fixed_mode->clock;
> + if (target_clock < fixed_mode->clock && downclock_mode)
> + target_clock = downclock_mode->clock;
> + else
> + target_clock = fixed_mode->clock;
The whole mode_valid() thing is a bit of mess for internal displays.
I tried to start fixing it here https://patchwork.freedesktop.org/series/45610/
but it got stuck in a bit of a bikeshed.
So without going all in and fixing the vrefresh stuff, and probably
also digging through the whole rat's nest of drm_mode_equal() clock
comparison accuracy (if we want to deal with the whole 59.97 v. 60
hz stuff fully) I think this can be simplified into:
intel_edp_min_dotclock()
{
return downclock_mode ? downclock_mode->clock : fixed_mode->clock;
}
Anyways, none of that is helpful unless you actually start to use the
downlock mode instead of the fixed mode. Which I didn't spot anywhere
in this series.
> }
>
> max_link_clock = intel_dp_max_link_rate(intel_dp);
> --
> 2.18.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 v2 1/4] drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode
On Wed, Sep 12, 2018 at 03:57:16PM -0700, Manasi Navare wrote:
> This patch fixes the original commit c0cfb10d9e1de49 ("drm/i915/edp:
> Do not do link training fallback or prune modes on EDP") that causes
> a blank screen in case of certain eDP panels (Eg: seen on Dell XPS13 9350)
> where first link training fails and a retraining is required by falling
> back to lower link rate/lane count.
> In case of some panels they advertise higher link rate/lane count
> than whats required for supporting the panel's native mode.
> But we always link train at highest link rate/lane count for eDP
> and if that fails we can still fallback to lower link rate/lane count
> as long as the fallback link BW still fits the native mode to avoid
> pruning the panel's native mode yet retraining at fallback values
> to recover from a blank screen.
>
> v2:
> * Send uevent if link failure on eDP unconditionally
>
> Cc: Clinton Taylor
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Daniel Vetter
> Cc: Lucas De Marchi
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107489
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105338
> Signed-off-by: Manasi Navare
> Tested-by: Alexander Wilson
> ---
> drivers/gpu/drm/i915/intel_dp.c | 29 +++
> drivers/gpu/drm/i915/intel_dp_link_training.c | 26 ++---
> 2 files changed, 38 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 436c22de33b6..e4de5257cd87 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -557,6 +557,21 @@ static bool intel_dp_link_params_valid(struct intel_dp
> *intel_dp, int link_rate,
> return true;
> }
>
> +static bool intel_dp_can_link_train_fallback_for_edp(struct intel_dp
> *intel_dp,
> + int link_rate,
> + uint8_t lane_count)
> +{
> + struct drm_display_mode *fixed_mode =
> intel_dp->attached_connector->panel.fixed_mode;
const
> + int mode_rate, max_rate;
> +
> + mode_rate = intel_dp_link_required(fixed_mode->clock, 18);
> + max_rate = intel_dp_max_data_rate(link_rate, lane_count);
> + if (mode_rate > max_rate)
> + return false;
I wonder if we should extract this into a helper and share with
mode_valid(). Then again, it's just a few lines so maybe not worth it.
> +
> + return true;
> +}
> +
> int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> int link_rate, uint8_t lane_count)
> {
> @@ -566,9 +581,23 @@ int intel_dp_get_link_train_fallback_values(struct
> intel_dp *intel_dp,
> intel_dp->num_common_rates,
> link_rate);
> if (index > 0) {
> + if (intel_dp_is_edp(intel_dp) &&
> + !intel_dp_can_link_train_fallback_for_edp(intel_dp,
> +
> intel_dp->common_rates[index - 1],
> + lane_count)) {
> + DRM_DEBUG_KMS("Retrying Link training for eDP with same
> parameters\n");
> + return 0;
> + }
> intel_dp->max_link_rate = intel_dp->common_rates[index - 1];
> intel_dp->max_link_lane_count = lane_count;
> } else if (lane_count > 1) {
> + if (intel_dp_is_edp(intel_dp) &&
> + !intel_dp_can_link_train_fallback_for_edp(intel_dp,
> +
> intel_dp_max_common_rate(intel_dp),
> + lane_count >> 1))
> {
> + DRM_DEBUG_KMS("Retrying Link training for eDP with same
> parameters\n");
> + return 0;
> + }
> intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> intel_dp->max_link_lane_count = lane_count >> 1;
This whole thing is getting a bit messy. I think it would worthwile to
rewrite this as something like:
intel_dp_update_link_train_fallback_values(intel_dp)
{
int link_rate = intel_dp->link_rate;
int lane_count = intel_dp->lane_count;
if (intel_dp_get_link_train_fallback_values(intel_dp, _rate,
_count))
return -1;
if (is_edp() && !edp_can_link_train_thing(link_rate, lane_count)) {
DRM_DEBUG_KMS("...");
return 0;
}
intel_dp->max_link_rate = link_rate;
intel_dp->max_link_lane_count = lane_count;
return 0;
}
But that can be done later. With the missing const added this patch is
Reviewed-by: Ville Syrjälä
> } else {
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/3] drm/i915: Priority boost for new clients
== Series Details == Series: series starting with [CI,1/3] drm/i915: Priority boost for new clients URL : https://patchwork.freedesktop.org/series/50395/ State : warning == Summary == $ dim checkpatch origin/drm-tip 2b9a64542c15 drm/i915: Priority boost for new clients 3ef9b826a9a3 drm/i915: Pull scheduling under standalone lock -:146: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #146: new file mode 100644 -:151: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #151: FILE: drivers/gpu/drm/i915/i915_scheduler.c:1: +/* -:394: WARNING:FUNCTION_ARGUMENTS: function definition argument 'pl' should also have an identifier name #394: FILE: drivers/gpu/drm/i915/i915_scheduler.c:244: + struct list_head *uninitialized_var(pl); total: 0 errors, 3 warnings, 0 checks, 870 lines checked be9bf43bff75 drm/i915: Priority boost for waiting clients ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/3] drm/i915: Priority boost for new clients
== Series Details == Series: series starting with [CI,1/3] drm/i915: Priority boost for new clients URL : https://patchwork.freedesktop.org/series/50395/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Priority boost for new clients Okay! Commit: drm/i915: Pull scheduling under standalone lock +./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from constant value (8000 becomes 0) Commit: drm/i915: Priority boost for waiting clients Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Engine discovery query
From: Tvrtko Ursulin
Engine discovery query allows userspace to enumerate engines, probe their
configuration features, all without needing to maintain the internal PCI
ID based database.
A new query for the generic i915 query ioctl is added named
DRM_I915_QUERY_ENGINE_INFO, together with accompanying structure
drm_i915_query_engine_info. The address of latter should be passed to the
kernel in the query.data_ptr field, and should be large enough for the
kernel to fill out all known engines as struct drm_i915_engine_info
elements trailing the query.
As with other queries, setting the item query length to zero allows
userspace to query minimum required buffer size.
Enumerated engines have common type mask which can be used to query all
hardware engines, versus engines userspace can submit to using the execbuf
uAPI.
Engines also have capabilities which are per engine class namespace of
bits describing features not present on all engine instances.
v2:
* Fixed HEVC assignment.
* Reorder some fields, rename type to flags, increase width. (Lionel)
* No need to allocate temporary storage if we do it engine by engine.
(Lionel)
v3:
* Describe engine flags and mark mbz fields. (Lionel)
* HEVC only applies to VCS.
v4:
* Squash SFC flag into main patch.
* Tidy some comments.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Jon Bloomfield
Cc: Dmitry Rogozhkin
Cc: Lionel Landwerlin
Cc: Joonas Lahtinen
Cc: Tony Ye
---
drivers/gpu/drm/i915/i915_query.c | 63 +
drivers/gpu/drm/i915/intel_engine_cs.c | 9
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 ++
include/uapi/drm/i915_drm.h | 54 +
4 files changed, 129 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 5821002cad42..294f8195efa7 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -84,9 +84,72 @@ static int query_topology_info(struct drm_i915_private
*dev_priv,
return total_length;
}
+static int
+query_engine_info(struct drm_i915_private *i915,
+ struct drm_i915_query_item *query_item)
+{
+ struct drm_i915_query_engine_info __user *query_ptr =
+ u64_to_user_ptr(query_item->data_ptr);
+ struct drm_i915_engine_info __user *info_ptr = _ptr->engines[0];
+ struct drm_i915_query_engine_info query;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ int len;
+
+ if (query_item->flags)
+ return -EINVAL;
+
+ len = sizeof(struct drm_i915_query_engine_info) +
+ I915_NUM_ENGINES * sizeof(struct drm_i915_engine_info);
+
+ if (!query_item->length)
+ return len;
+ else if (query_item->length < len)
+ return -EINVAL;
+
+ if (copy_from_user(, query_ptr, sizeof(query)))
+ return -EFAULT;
+
+ if (query.num_engines || query.rsvd[0] || query.rsvd[1] ||
+ query.rsvd[2])
+ return -EINVAL;
+
+ if (!access_ok(VERIFY_WRITE, query_ptr, query_item->length))
+ return -EFAULT;
+
+ for_each_engine(engine, i915, id) {
+ struct drm_i915_engine_info info;
+
+ if (__copy_from_user(, info_ptr, sizeof(info)))
+ return -EFAULT;
+
+ if (info.flags || info.class || info.instance ||
+ info.capabilities || info.rsvd0 || info.rsvd1[0] ||
+ info.rsvd1[1])
+ return -EINVAL;
+
+ info.class = engine->uabi_class;
+ info.instance = engine->instance;
+ info.flags = I915_ENGINE_FLAG_PHYSICAL | I915_ENGINE_FLAG_ABI;
+ info.capabilities = engine->capabilities;
+
+ if (__copy_to_user(info_ptr, , sizeof(info)))
+ return -EFAULT;
+
+ query.num_engines++;
+ info_ptr++;
+ }
+
+ if (__copy_to_user(query_ptr, , sizeof(query)))
+ return -EFAULT;
+
+ return len;
+}
+
static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
struct drm_i915_query_item *query_item)
= {
query_topology_info,
+ query_engine_info,
};
int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 1c6143bdf5a4..97b4acf8af5c 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -294,6 +294,15 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
engine->mmio_base = __engine_mmio_base(dev_priv, info->mmio_bases);
engine->class = info->class;
engine->instance = info->instance;
+ if (engine->class == VIDEO_DECODE_CLASS) {
+ /* HEVC support is present only on vcs0. */
[Intel-gfx] ✗ Fi.CI.BAT: failure for Per context dynamic (sub)slice power-gating (rev6)
== Series Details == Series: Per context dynamic (sub)slice power-gating (rev6) URL : https://patchwork.freedesktop.org/series/48194/ State : failure == Summary == Applying: drm/i915/execlists: Move RPCS setup to context pin Applying: drm/i915: Record the sseu configuration per-context & engine Applying: drm/i915/perf: lock powergating configuration to default when active Applying: drm/i915: Add timeline barrier support Applying: drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only) Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_gem_context.c M drivers/gpu/drm/i915/intel_lrc.c M include/uapi/drm/i915_drm.h Falling back to patching base and 3-way merge... Auto-merging include/uapi/drm/i915_drm.h Auto-merging drivers/gpu/drm/i915/intel_lrc.c Auto-merging drivers/gpu/drm/i915/i915_gem_context.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_gem_context.c error: Failed to merge in the changes. Patch failed at 0005 drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only) Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/8] drm/i915: Add a new "remapped" gtt_view
On Wed, Sep 26, 2018 at 08:50:25AM +0100, Tvrtko Ursulin wrote:
>
> On 25/09/2018 20:37, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > To overcome display engine stride limits we'll want to remap the
> > pages in the GTT. To that end we need a new gtt_view type which
> > is just like the "rotated" type except not rotated.
> >
> > v2: Use intel_remapped_plane_info base type
> > s/unused/unused_mbz/ (Chris)
> > Separate BUILD_BUG_ON()s (Chris)
> > Use I915_GTT_PAGE_SIZE (Chris)
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 12
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 91
> > +++
> > drivers/gpu/drm/i915/i915_gem_gtt.h | 25 +++--
> > drivers/gpu/drm/i915/i915_vma.c | 6 +-
> > drivers/gpu/drm/i915/i915_vma.h | 3 +
> > drivers/gpu/drm/i915/intel_display.c | 11
> > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > drivers/gpu/drm/i915/selftests/i915_vma.c | 6 +-
> > 8 files changed, 147 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index b4744a68cd88..edb9f6f3c0cf 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -196,6 +196,18 @@ describe_obj(struct seq_file *m, struct
> > drm_i915_gem_object *obj)
> >
> > vma->ggtt_view.rotated.plane[1].offset);
> > break;
> >
> > + case I915_GGTT_VIEW_REMAPPED:
> > + seq_printf(m, ", remapped [(%ux%u, stride=%u,
> > offset=%u), (%ux%u, stride=%u, offset=%u)]",
> > +
> > vma->ggtt_view.remapped.plane[0].width,
> > +
> > vma->ggtt_view.remapped.plane[0].height,
> > +
> > vma->ggtt_view.remapped.plane[0].stride,
> > +
> > vma->ggtt_view.remapped.plane[0].offset,
> > +
> > vma->ggtt_view.remapped.plane[1].width,
> > +
> > vma->ggtt_view.remapped.plane[1].height,
> > +
> > vma->ggtt_view.remapped.plane[1].stride,
> > +
> > vma->ggtt_view.remapped.plane[1].offset);
> > + break;
> > +
> > default:
> > MISSING_CASE(vma->ggtt_view.type);
> > break;
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index f6c7ab413081..e4d49c345c81 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -3798,6 +3798,92 @@ intel_rotate_pages(struct intel_rotation_info
> > *rot_info,
> > return ERR_PTR(ret);
> > }
> >
> > +static struct scatterlist *
> > +remap_pages(const dma_addr_t *in, unsigned int offset,
> > + unsigned int width, unsigned int height,
> > + unsigned int stride,
> > + struct sg_table *st, struct scatterlist *sg)
> > +{
> > + unsigned int column, row;
> > +
> > + for (row = 0; row < height; row++) {
> > + for (column = 0; column < width; column++) {
> > + st->nents++;
> > + /* We don't need the pages, but need to initialize
> > +* the entries so the sg list can be happily traversed.
> > +* The only thing we need are DMA addresses.
> > +*/
> > + sg_set_page(sg, NULL, I915_GTT_PAGE_SIZE, 0);
> > + sg_dma_address(sg) = in[offset + column];
> > + sg_dma_len(sg) = I915_GTT_PAGE_SIZE;
> > + sg = sg_next(sg);
>
> For this type of remapping you could I think potentially get some
> decreased memory use benefits by coalescing the consecutive addresses
> into single sg entries. If I understood correctly what it's doing at
> least.. Since framebuffers could have a good chance to have been
> initially allocated in larger than page size chunks.
>
> If you decide to do that, then...
>
> > + }
> > + offset += stride;
> > + }
> > +
> > + return sg;
> > +}
> > +
> > +static noinline struct sg_table *
> > +intel_remap_pages(struct intel_remapped_info *rem_info,
> > + struct drm_i915_gem_object *obj)
> > +{
> > + const unsigned long n_pages = obj->base.size / I915_GTT_PAGE_SIZE;
> > + unsigned int size = intel_remapped_info_size(rem_info);
> > + struct sgt_iter sgt_iter;
> > + dma_addr_t dma_addr;
> > + unsigned long i;
> > + dma_addr_t *page_addr_list;
> > + struct sg_table *st;
> > + struct scatterlist *sg;
> > + int ret = -ENOMEM;
> > +
> > + /* Allocate a temporary list of source pages for random access.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915: Restore vblank interrupts earlier
== Series Details == Series: series starting with [1/3] drm/i915: Restore vblank interrupts earlier URL : https://patchwork.freedesktop.org/series/50393/ State : warning == Summary == $ dim checkpatch origin/drm-tip 3d421aa28f28 drm/i915: Restore vblank interrupts earlier ab4d85399a55 drm/i915: Use the correct crtc when sanitizing plane mapping -:30: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #30: Cc: sta...@vger.kernel.org # fcba862e8428 drm/i915: Have plane->get_hw_state() return the current pipe total: 0 errors, 1 warnings, 0 checks, 111 lines checked 56da01b165ac drm/i915: Clean up early plane debugs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915/icl: Support co-existence between per-context SSEU and OA
From: Tvrtko Ursulin
When OA is active we want to lock the powergating configuration, but on
Icelake, users like the media stack will have issues if we lock to the
full device configuration.
Instead lock to a subset of (sub)slices which are currently a known
working configuration for all users.
v2:
* Fix commit message spelling.
v3:
Lionel:
* Add bspec reference.
* Fix spelling in comment.
Signed-off-by: Tvrtko Ursulin
Bspec: 21140
Cc: Lionel Landwerlin
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/intel_lrc.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c6c5938684cf..2e8151192fc4 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2577,13 +2577,28 @@ u32 gen8_make_rpcs(struct drm_i915_private *i915,
struct intel_sseu *req_sseu)
/*
* If i915/perf is active, we want a stable powergating configuration
-* on the system. The most natural configuration to take in that case
-* is the default (i.e maximum the hardware can do).
+* on the system.
+*
+* We could choose full enablement, but on ICL we know there are use
+* cases which disable slices for functional, apart for performance
+* reasons. So in this case we select a known stable subset.
*/
- if (unlikely(i915->perf.oa.exclusive_stream))
- ctx_sseu = intel_device_default_sseu(i915);
- else
+ if (!i915->perf.oa.exclusive_stream) {
ctx_sseu = *req_sseu;
+ } else {
+ ctx_sseu = intel_device_default_sseu(i915);
+
+ if (IS_GEN11(i915)) {
+ /*
+* We only need subslice count so it doesn't matter
+* which ones we select - just turn off low bits in the
+* amount of half of all available subslices per slice.
+*/
+ ctx_sseu.subslice_mask =
+ ~(~0 << (hweight8(ctx_sseu.subslice_mask) / 2));
+ ctx_sseu.slice_mask = 0x1;
+ }
+ }
slices = hweight8(ctx_sseu.slice_mask);
subslices = hweight8(ctx_sseu.subslice_mask);
--
2.17.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 series starting with [CI,1/3] drm/i915: Priority boost for new clients
== Series Details == Series: series starting with [CI,1/3] drm/i915: Priority boost for new clients URL : https://patchwork.freedesktop.org/series/50395/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4908 -> Patchwork_10308 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/50395/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10308 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-bdw-samus: NOTRUN -> INCOMPLETE (fdo#107773) igt@prime_vgem@basic-fence-flip: fi-cfl-8700k: PASS -> FAIL (fdo#104008) Possible fixes igt@gem_exec_suspend@basic-s3: fi-cfl-8109u: DMESG-WARN (fdo#107345) -> PASS +3 igt@gem_exec_suspend@basic-s4-devices: fi-bdw-samus: INCOMPLETE (fdo#107773) -> PASS fi-blb-e6850: INCOMPLETE (fdo#107718) -> PASS igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a: fi-byt-clapper: FAIL (fdo#107362) -> PASS fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#107345 https://bugs.freedesktop.org/show_bug.cgi?id=107345 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773 == Participating hosts (53 -> 47) == Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-u2 fi-ctg-p8600 == Build changes == * Linux: CI_DRM_4908 -> Patchwork_10308 CI_DRM_4908: d287e1ba5382518eb1ce7cac144f428c1522b8a1 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4658: cab89ce2c5da684d01deff402d4e8e11441beadb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10308: be9bf43bff75fbb35b2a0517f32011e3c52f8242 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == be9bf43bff75 drm/i915: Priority boost for waiting clients 3ef9b826a9a3 drm/i915: Pull scheduling under standalone lock 2b9a64542c15 drm/i915: Priority boost for new clients == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10308/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 6/6] drm/i915/psr: Remove alpm from i915_psr
ALPM is a requirement and we don't need to keep it's cached, what
were done in commit 97c9de66ca80
("drm/i915/psr: Fix ALPM cap check for PSR2") but the alpm was not
removed from i915_psr.
Reviewed-by: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b672ed0cac24..149d1f88f5e4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -632,7 +632,6 @@ struct i915_psr {
bool sink_psr2_support;
bool link_standby;
bool colorimetry_support;
- bool alpm;
bool psr2_enabled;
u8 sink_sync_latency;
ktime_t last_entry_attempt;
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 4/6] drm/i915/psr: Use WA to force HW tracking to exit PSR2
This WA also works fine for PSR2, triggering a selective update when
possible.
Acked-by: Dhinakaran Pandiyan
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_psr.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index fbceb814d6be..341af802b251 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -1023,20 +1023,16 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
/* By definition flush = invalidate + flush */
if (frontbuffer_bits) {
- if (dev_priv->psr.psr2_enabled) {
- intel_psr_exit(dev_priv);
- } else {
- /*
-* Display WA #0884: all
-* This documented WA for bxt can be safely applied
-* broadly so we can force HW tracking to exit PSR
-* instead of disabling and re-enabling.
-* Workaround tells us to write 0 to CUR_SURFLIVE_A,
-* but it makes more sense write to the current active
-* pipe.
-*/
- I915_WRITE(CURSURFLIVE(pipe), 0);
- }
+ /*
+* Display WA #0884: all
+* This documented WA for bxt can be safely applied
+* broadly so we can force HW tracking to exit PSR
+* instead of disabling and re-enabling.
+* Workaround tells us to write 0 to CUR_SURFLIVE_A,
+* but it makes more sense write to the current active
+* pipe.
+*/
+ I915_WRITE(CURSURFLIVE(pipe), 0);
}
if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 3/6] drm/i915/psr: Remove PSR2 TODO error handling
We are already handling all PSR2 errors, so we can drop this TODO. Reviewed-by: Dhinakaran Pandiyan Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/intel_psr.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 570ae1a2938a..fbceb814d6be 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -1127,8 +1127,6 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp) intel_psr_disable_locked(intel_dp); /* clear status register */ drm_dp_dpcd_writeb(_dp->aux, DP_PSR_ERROR_STATUS, val); - - /* TODO: handle PSR2 errors */ exit: mutex_unlock(>lock); } -- 2.19.0 ___ 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 [v3,1/6] drm/i915/psr: Share PSR and PSR2 exit mask
== Series Details == Series: series starting with [v3,1/6] drm/i915/psr: Share PSR and PSR2 exit mask URL : https://patchwork.freedesktop.org/series/50417/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4911 -> Patchwork_10316 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/50417/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10316 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: fi-byt-clapper: PASS -> FAIL (fdo#103191, fdo#107362) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-bdw-samus: NOTRUN -> INCOMPLETE (fdo#107773) Possible fixes igt@gem_exec_suspend@basic-s3: fi-bdw-samus: INCOMPLETE (fdo#107773) -> PASS igt@kms_pipe_crc_basic@hang-read-crc-pipe-b: fi-byt-clapper: FAIL (fdo#103191, fdo#107362) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-blb-e6850: INCOMPLETE (fdo#107718) -> PASS fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773 == Participating hosts (49 -> 46) == Additional (3): fi-gdg-551 fi-snb-2520m fi-pnv-d510 Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-u2 fi-ctg-p8600 == Build changes == * Linux: CI_DRM_4911 -> Patchwork_10316 CI_DRM_4911: e46b4809753a2e3d3d73c5a9e028cd030bea60e5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4659: 7f41adfbfd17027b71c332d6ae997f1364f73731 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10316: eb96d2d16902fa0585527586405210e7591aa796 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == eb96d2d16902 drm/i915/psr: Remove alpm from i915_psr 00e220b8b69f drm/i915/psr: Don't tell sink that main link will be active while is active PSR2 3f238e1d2c3b drm/i915/psr: Use WA to force HW tracking to exit PSR2 9034607b220e drm/i915/psr: Remove PSR2 TODO error handling 86c86b719ae1 drm/i915/psr: Make MASK_DISP_REG_WRITE reserved in PSR_MASK for ICL f82ea23a1cf4 drm/i915/psr: Share PSR and PSR2 exit mask == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10316/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/dp: Restrict link retrain workaround to external monitors
On Mon, 2018-10-01 at 12:49 -0700, Rodrigo Vivi wrote:
> On Mon, Sep 24, 2018 at 03:45:24PM -0700, Dhinakaran Pandiyan wrote:
> > Commit '3cf71bc9904d ("drm/i915: Re-apply "Perform link quality
> > check,
> > unconditionally during long pulse"")' applies a work around for
> > sinks
>
> Fixes: ?
>
> Should this patch be on drm-intel-fixes for 4.19?
>
> If so, the cherry-pick failed anyway and a backported version is
> needed.
>
> Please let me know how to proceed here.
Looks like the patch can be cherry-picked cleanly if 1/6 was also
picked. So, the relevant commits in dinq are -
f24f6eb95807 drm/i915/dp: Restrict link retrain workaround to external
monitors
9ebd8202393d drm/i915/dp: Fix link retraining comment in
intel_dp_long_pulse()
-DK
>
> Thanks in advance,
> Rodrigo.
>
> > that don't signal link loss. The work around does not need to have
> > to be
> > that broad as the issue was seen with only one particular monitor;
> > limit
> > this only for external displays as eDP features like PSR turn off
> > the link
> > and the driver ends up retraining the link seeeing that link is not
> > synchronized.
> >
> > Cc: Lyude Paul
> > Cc: Jan-Marek Glogowski
> > Cc: Ville Syrjälä
> > Cc: Rodrigo Vivi
> > References: 3cf71bc9904d ("drm/i915: Re-apply "Perform link quality
> > check, unconditionally during long pulse"")
> > Signed-off-by: Dhinakaran Pandiyan
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 13 +++--
> > 1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 34c561011e7a..6130d05d8b88 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -5072,12 +5072,13 @@ intel_dp_long_pulse(struct intel_connector
> > *connector,
> > */
> > status = connector_status_disconnected;
> > goto out;
> > - } else {
> > - /*
> > -* Some external monitors do not signal loss of link
> > -* synchronization with an IRQ_HPD, so force a link
> > status
> > -* check.
> > -*/
> > + }
> > +
> > + /*
> > +* Some external monitors do not signal loss of link
> > synchronization
> > +* with an IRQ_HPD, so force a link status check.
> > +*/
> > + if (!intel_dp_is_edp(intel_dp)) {
> > struct intel_encoder *encoder =
> > _to_dig_port(intel_dp)->base;
> >
> > intel_dp_retrain_link(encoder, ctx);
> > --
> > 2.17.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 v2] drm/i915/psr: Enable PSR1 on gen-9+ HW
On Thu, Sep 27, 2018 at 11:11:17PM -0700, Dhinakaran Pandiyan wrote:
> We have new tests and fixes in place since the feature was last
> disabled. Try again for gen-9+ hardware and enable only PSR1 by default as
> a first step.
> v2: Remove typo fix and comment improvements (Rodrigo)
>
> Cc: Jani Nikula
> Cc: Jose Roberto de Souza
> Cc: Paulo Zanoni
> Cc: Rodrigo Vivi
> Cc: Ville Syrjälä
> References: commit 2ee7dc497e34 ("drm/i915: disable PSR by default on
> HSW/BDW")
> References: commit dcb2e993f3c0 ("Revert "drm/i915: Enable PSR by default on
> Valleyview and Cherryview."")
> Signed-off-by: Dhinakaran Pandiyan
It seems that we still need to wait and check why shard-skl wasn't up on this
CI,
but patch itself is right, so
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_psr.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index b6838b525502..5a2660ad8203 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -71,6 +71,10 @@ static bool psr_global_enabled(u32 debug)
> static bool intel_psr2_enabled(struct drm_i915_private *dev_priv,
> const struct intel_crtc_state *crtc_state)
> {
> + /* Disable PSR2 by default for all platforms */
> + if (i915_modparams.enable_psr == -1)
> + return false;
> +
> switch (dev_priv->psr.debug & I915_PSR_DEBUG_MODE_MASK) {
> case I915_PSR_DEBUG_FORCE_PSR1:
> return false;
> @@ -1065,12 +1069,9 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
> if (!dev_priv->psr.sink_support)
> return;
>
> - if (i915_modparams.enable_psr == -1) {
> - i915_modparams.enable_psr = dev_priv->vbt.psr.enable;
> -
> - /* Per platform default: all disabled. */
> - i915_modparams.enable_psr = 0;
> - }
> + if (i915_modparams.enable_psr == -1)
> + if (INTEL_GEN(dev_priv) < 9 || !dev_priv->vbt.psr.enable)
> + i915_modparams.enable_psr = 0;
>
> /* Set link_standby x link_off defaults */
> if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> --
> 2.17.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/guc: init GuC descriptors after GuC load
== Series Details == Series: series starting with [1/2] drm/i915/guc: init GuC descriptors after GuC load URL : https://patchwork.freedesktop.org/series/50410/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4911 -> Patchwork_10314 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/50410/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10314 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s3: fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718) igt@kms_frontbuffer_tracking@basic: fi-byt-clapper: PASS -> FAIL (fdo#103167) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-byt-clapper: PASS -> FAIL (fdo#107362, fdo#103191) +1 Possible fixes igt@kms_pipe_crc_basic@hang-read-crc-pipe-b: fi-byt-clapper: FAIL (fdo#107362, fdo#103191) -> PASS 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#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 == Participating hosts (49 -> 43) == Additional (3): fi-gdg-551 fi-snb-2520m fi-pnv-d510 Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-icl-u2 fi-bsw-cyan fi-ctg-p8600 fi-icl-u fi-bdw-samus == Build changes == * Linux: CI_DRM_4911 -> Patchwork_10314 CI_DRM_4911: e46b4809753a2e3d3d73c5a9e028cd030bea60e5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4659: 7f41adfbfd17027b71c332d6ae997f1364f73731 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10314: da1d0bdfa91d91916a69647e59cd721db70249bd @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == da1d0bdfa91d drm/i915/guc: Don't clear the cookie on dorbell destroy 96c98341d09e drm/i915/guc: init GuC descriptors after GuC load == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10314/issues.html ___ 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: extract common ce->pin_count check
== Series Details == Series: drm/i915: extract common ce->pin_count check URL : https://patchwork.freedesktop.org/series/50414/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4911 -> Patchwork_10315 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/50414/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10315 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s4-devices: fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718) igt@kms_frontbuffer_tracking@basic: fi-byt-clapper: PASS -> FAIL (fdo#103167) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-byt-clapper: PASS -> FAIL (fdo#107362, fdo#103191) Possible fixes igt@kms_pipe_crc_basic@hang-read-crc-pipe-b: fi-byt-clapper: FAIL (fdo#107362, fdo#103191) -> PASS 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#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 == Participating hosts (49 -> 46) == Additional (3): fi-gdg-551 fi-snb-2520m fi-pnv-d510 Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-u2 fi-ctg-p8600 == Build changes == * Linux: CI_DRM_4911 -> Patchwork_10315 CI_DRM_4911: e46b4809753a2e3d3d73c5a9e028cd030bea60e5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4659: 7f41adfbfd17027b71c332d6ae997f1364f73731 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10315: 1eeadaad02c581c752a3247f773897552f77f34c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 1eeadaad02c5 drm/i915: extract common ce->pin_count check == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10315/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/6] drm/i915/psr: Share PSR and PSR2 exit mask
Now both PSR and PSR2 have the same exit mask, so let's share then
instead of have the same code 2 times.
Reviewed-by: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_psr.c | 34
1 file changed, 13 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 11fdefaf7728..3b5b8798c3ba 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -576,28 +576,20 @@ static void intel_psr_enable_source(struct intel_dp
*intel_dp,
else
chicken &= ~VSC_DATA_SEL_SOFTWARE_CONTROL;
I915_WRITE(CHICKEN_TRANS(cpu_transcoder), chicken);
-
- I915_WRITE(EDP_PSR_DEBUG,
- EDP_PSR_DEBUG_MASK_MEMUP |
- EDP_PSR_DEBUG_MASK_HPD |
- EDP_PSR_DEBUG_MASK_LPSP |
- EDP_PSR_DEBUG_MASK_MAX_SLEEP |
- EDP_PSR_DEBUG_MASK_DISP_REG_WRITE);
- } else {
- /*
-* Per Spec: Avoid continuous PSR exit by masking MEMUP
-* and HPD. also mask LPSP to avoid dependency on other
-* drivers that might block runtime_pm besides
-* preventing other hw tracking issues now we can rely
-* on frontbuffer tracking.
-*/
- I915_WRITE(EDP_PSR_DEBUG,
- EDP_PSR_DEBUG_MASK_MEMUP |
- EDP_PSR_DEBUG_MASK_HPD |
- EDP_PSR_DEBUG_MASK_LPSP |
- EDP_PSR_DEBUG_MASK_DISP_REG_WRITE |
- EDP_PSR_DEBUG_MASK_MAX_SLEEP);
}
+
+ /*
+* Per Spec: Avoid continuous PSR exit by masking MEMUP and HPD also
+* mask LPSP to avoid dependency on other drivers that might block
+* runtime_pm besides preventing other hw tracking issues now we
+* can rely on frontbuffer tracking.
+*/
+ I915_WRITE(EDP_PSR_DEBUG,
+ EDP_PSR_DEBUG_MASK_MEMUP |
+ EDP_PSR_DEBUG_MASK_HPD |
+ EDP_PSR_DEBUG_MASK_LPSP |
+ EDP_PSR_DEBUG_MASK_DISP_REG_WRITE |
+ EDP_PSR_DEBUG_MASK_MAX_SLEEP);
}
static void intel_psr_enable_locked(struct drm_i915_private *dev_priv,
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/6] drm/i915/psr: Make MASK_DISP_REG_WRITE reserved in PSR_MASK for ICL
ICL spec states that this bit is now reserved.
Bspec: 7722
v2(Dhinakaran and Jani):
- instead of remove bit in gen11 now only setting if if gen < 11
- changed commit title
Cc: Jani Nikula
Reviewed-by: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_reg.h | 4 ++--
drivers/gpu/drm/i915/intel_psr.c | 16 ++--
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 27e650fe591b..8f436c73f184 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4195,7 +4195,7 @@ enum {
#define EDP_PSR_DEBUG_MASK_LPSP (1 << 27)
#define EDP_PSR_DEBUG_MASK_MEMUP (1 << 26)
#define EDP_PSR_DEBUG_MASK_HPD (1 << 25)
-#define EDP_PSR_DEBUG_MASK_DISP_REG_WRITE(1 << 16)
+#define EDP_PSR_DEBUG_MASK_DISP_REG_WRITE(1 << 16) /* Reserved in ICL+ */
#define EDP_PSR_DEBUG_EXIT_ON_PIXEL_UNDERRUN (1 << 15) /* SKL+ */
#define EDP_PSR2_CTL _MMIO(0x6f900)
@@ -4232,7 +4232,7 @@ enum {
#define PSR_EVENT_FRONT_BUFFER_MODIFY (1 << 9)
#define PSR_EVENT_WD_TIMER_EXPIRE (1 << 8)
#define PSR_EVENT_PIPE_REGISTERS_UPDATE (1 << 6)
-#define PSR_EVENT_REGISTER_UPDATE (1 << 5)
+#define PSR_EVENT_REGISTER_UPDATE (1 << 5) /* Reserved in ICL+ */
#define PSR_EVENT_HDCP_ENABLE (1 << 4)
#define PSR_EVENT_KVMR_SESSION_ENABLE (1 << 3)
#define PSR_EVENT_VBI_ENABLE (1 << 2)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 3b5b8798c3ba..570ae1a2938a 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -559,6 +559,7 @@ static void intel_psr_enable_source(struct intel_dp
*intel_dp,
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
+ u32 mask;
/* Only HSW and BDW have PSR AUX registers that need to be setup. SKL+
* use hardcoded values PSR AUX transactions
@@ -584,12 +585,15 @@ static void intel_psr_enable_source(struct intel_dp
*intel_dp,
* runtime_pm besides preventing other hw tracking issues now we
* can rely on frontbuffer tracking.
*/
- I915_WRITE(EDP_PSR_DEBUG,
- EDP_PSR_DEBUG_MASK_MEMUP |
- EDP_PSR_DEBUG_MASK_HPD |
- EDP_PSR_DEBUG_MASK_LPSP |
- EDP_PSR_DEBUG_MASK_DISP_REG_WRITE |
- EDP_PSR_DEBUG_MASK_MAX_SLEEP);
+ mask = EDP_PSR_DEBUG_MASK_MEMUP |
+ EDP_PSR_DEBUG_MASK_HPD |
+ EDP_PSR_DEBUG_MASK_LPSP |
+ EDP_PSR_DEBUG_MASK_MAX_SLEEP;
+
+ if (INTEL_GEN(dev_priv) < 11)
+ mask |= EDP_PSR_DEBUG_MASK_DISP_REG_WRITE;
+
+ I915_WRITE(EDP_PSR_DEBUG, mask);
}
static void intel_psr_enable_locked(struct drm_i915_private *dev_priv,
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 5/6] drm/i915/psr: Don't tell sink that main link will be active while is active PSR2
For PSR2 there is no register to tell HW to keep main link enabled
while PSR2 is active, so don't configure sink DPCD with a
wrong value.
v3: Also update the value printed in debugfs
Cc: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
drivers/gpu/drm/i915/intel_psr.c| 10 ++
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index b4744a68cd88..14d58d121f2a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2723,7 +2723,8 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
seq_printf(m, "Main link in standby mode: %s\n",
- yesno(dev_priv->psr.link_standby));
+ yesno(dev_priv->psr.link_standby &&
+ !dev_priv->psr.psr2_enabled));
seq_printf(m, "HW Enabled & Active bit: %s\n", yesno(enabled));
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 341af802b251..02dcc33750a8 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -342,12 +342,14 @@ static void intel_psr_enable_sink(struct intel_dp
*intel_dp)
drm_dp_dpcd_writeb(_dp->aux, DP_RECEIVER_ALPM_CONFIG,
DP_ALPM_ENABLE);
dpcd_val |= DP_PSR_ENABLE_PSR2;
+ } else {
+ if (dev_priv->psr.link_standby)
+ dpcd_val |= DP_PSR_MAIN_LINK_ACTIVE;
+
+ if (INTEL_GEN(dev_priv) >= 8)
+ dpcd_val |= DP_PSR_CRC_VERIFICATION;
}
- if (dev_priv->psr.link_standby)
- dpcd_val |= DP_PSR_MAIN_LINK_ACTIVE;
- if (!dev_priv->psr.psr2_enabled && INTEL_GEN(dev_priv) >= 8)
- dpcd_val |= DP_PSR_CRC_VERIFICATION;
drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, dpcd_val);
drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
--
2.19.0
___
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/dp: Do not grab crtc modeset lock in intel_dp_detect()
On Mon, Oct 01, 2018 at 03:01:18PM -0700, Dhinakaran Pandiyan wrote:
> On Mon, 2018-10-01 at 23:10 +0300, Ville Syrjälä wrote:
> > On Mon, Oct 01, 2018 at 12:48:28PM -0700, Rodrigo Vivi wrote:
> > > On Tue, Sep 25, 2018 at 07:54:22PM -0700, Dhinakaran Pandiyan
> > > wrote:
> > > > A crtc modeset lock was added for link retraining but
> > > > intel_dp_retrain_link() knows to take the necessary locks since
> > > > commit c85d200e8321 ("drm/i915: Move SST DP link retraining into
> > > > the
> > > > ->post_hotplug() hook")
> > > > v2: Drop AUX power domain reference in the early return path
> > > >
> > > > Fixes: c85d200e8321 ("drm/i915: Move SST DP link retraining into
> > > > the ->post_hotplug() hook")
> > >
> > > This patch failed on cherry-pick for drm-intel-fixes targeting
> > > 4.19.
> > >
> > > If it still makes sense to have it there please provide a
> > > backported version
> > > to drm-intel-fixes or let me know if it has dependency on other
> > > patches?
> >
> > This is more of an optimization to not disturb page flips and whatnot
> > so much with detect. The double lock is otherwise harmless due to
> > ww_mutex.
> >
> Yeah, let's not backport this.
cool, thanks.
>
> -DK
>
> > >
> > > Thanks,
> > > Rodrigo.
> > >
> > > > Cc: Ville Syrjälä
> > > > Signed-off-by: Dhinakaran Pandiyan > > > >
> > > > ---
> > > > drivers/gpu/drm/i915/intel_dp.c | 24 ++--
> > > > 1 file changed, 10 insertions(+), 14 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 09229fc66dec..ef28cc0f122c 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -5079,8 +5079,15 @@ intel_dp_long_pulse(struct intel_connector
> > > > *connector,
> > > > * Some external monitors do not signal loss of link
> > > > synchronization
> > > > * with an IRQ_HPD, so force a link status check.
> > > > */
> > > > - if (!intel_dp_is_edp(intel_dp))
> > > > - intel_dp_retrain_link(encoder, ctx);
> > > > + if (!intel_dp_is_edp(intel_dp)) {
> > > > + int ret;
> > > > +
> > > > + ret = intel_dp_retrain_link(encoder, ctx);
> > > > + if (ret) {
> > > > + intel_display_power_put(dev_priv, intel_dp-
> > > > >aux_power_domain);
> > > > + return ret;
> > > > + }
> > > > + }
> > > >
> > > > /*
> > > > * Clearing NACK and defer counts to get their exact values
> > > > @@ -5130,19 +5137,8 @@ intel_dp_detect(struct drm_connector
> > > > *connector,
> > > > connector->base.id, connector->name);
> > > >
> > > > /* If full detect is not performed yet, do a full detect */
> > > > - if (!intel_dp->detect_done) {
> > > > - struct drm_crtc *crtc;
> > > > - int ret;
> > > > -
> > > > - crtc = connector->state->crtc;
> > > > - if (crtc) {
> > > > - ret = drm_modeset_lock(>mutex, ctx);
> > > > - if (ret)
> > > > - return ret;
> > > > - }
> > > > -
> > > > + if (!intel_dp->detect_done)
> > > > status = intel_dp_long_pulse(intel_dp-
> > > > >attached_connector, ctx);
> > > > - }
> > > >
> > > > intel_dp->detect_done = false;
> > > >
> > > > --
> > > > 2.14.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
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v3,1/6] drm/i915/psr: Share PSR and PSR2 exit mask
== Series Details == Series: series starting with [v3,1/6] drm/i915/psr: Share PSR and PSR2 exit mask URL : https://patchwork.freedesktop.org/series/50417/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/psr: Share PSR and PSR2 exit mask Okay! Commit: drm/i915/psr: Make MASK_DISP_REG_WRITE reserved in PSR_MASK for ICL Okay! Commit: drm/i915/psr: Remove PSR2 TODO error handling Okay! Commit: drm/i915/psr: Use WA to force HW tracking to exit PSR2 Okay! Commit: drm/i915/psr: Don't tell sink that main link will be active while is active PSR2 Okay! Commit: drm/i915/psr: Remove alpm from i915_psr -drivers/gpu/drm/i915/selftests/../i915_drv.h:3724:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3723:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v3,1/6] drm/i915/psr: Share PSR and PSR2 exit mask
== Series Details == Series: series starting with [v3,1/6] drm/i915/psr: Share PSR and PSR2 exit mask URL : https://patchwork.freedesktop.org/series/50417/ State : warning == Summary == $ dim checkpatch origin/drm-tip f82ea23a1cf4 drm/i915/psr: Share PSR and PSR2 exit mask 86c86b719ae1 drm/i915/psr: Make MASK_DISP_REG_WRITE reserved in PSR_MASK for ICL 9034607b220e drm/i915/psr: Remove PSR2 TODO error handling 3f238e1d2c3b drm/i915/psr: Use WA to force HW tracking to exit PSR2 00e220b8b69f drm/i915/psr: Don't tell sink that main link will be active while is active PSR2 -:29: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #29: FILE: drivers/gpu/drm/i915/i915_debugfs.c:2727: + yesno(dev_priv->psr.link_standby && + !dev_priv->psr.psr2_enabled)); total: 0 errors, 0 warnings, 1 checks, 27 lines checked eb96d2d16902 drm/i915/psr: Remove alpm from i915_psr ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] drm/i915: Replace some open-coded i915_map_coherent_type()
== Series Details == Series: series starting with [1/4] drm/i915: Replace some open-coded i915_map_coherent_type() URL : https://patchwork.freedesktop.org/series/50408/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4911 -> Patchwork_10313 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_10313 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10313, 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/50408/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_10313: === IGT changes === Possible regressions igt@vgem_basic@debugfs: fi-ilk-650: PASS -> INCOMPLETE == Known issues == Here are the changes found in Patchwork_10313 that come from known issues: === IGT changes === Issues hit igt@drv_getparams_basic@basic-subslice-total: fi-snb-2520m: NOTRUN -> DMESG-WARN (fdo#103713) +10 igt@gem_exec_suspend@basic-s3: fi-skl-caroline:PASS -> INCOMPLETE (fdo#107773, fdo#107556, fdo#104108) igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: PASS -> DMESG-WARN (fdo#107139, fdo#105128) fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718) igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a: fi-byt-clapper: PASS -> FAIL (fdo#107362) Possible fixes igt@kms_pipe_crc_basic@hang-read-crc-pipe-b: fi-byt-clapper: FAIL (fdo#103191, fdo#107362) -> PASS fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107556 https://bugs.freedesktop.org/show_bug.cgi?id=107556 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773 == Participating hosts (49 -> 44) == Additional (3): fi-gdg-551 fi-snb-2520m fi-pnv-d510 Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-icl-u2 fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus fi-snb-2600 == Build changes == * Linux: CI_DRM_4911 -> Patchwork_10313 CI_DRM_4911: e46b4809753a2e3d3d73c5a9e028cd030bea60e5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4659: 7f41adfbfd17027b71c332d6ae997f1364f73731 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10313: 8e58a32e738615317e38a9e9440b52499a101598 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 8e58a32e7386 drm/i915: Cache the error string ff536a417a34 drm/i915: Clear the error PTE just once on finish b90981da8f54 drm/i915: Handle incomplete Z_FINISH for compressed error states 094552a0cfc5 drm/i915: Replace some open-coded i915_map_coherent_type() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10313/issues.html ___ 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/dp: Do not grab crtc modeset lock in intel_dp_detect()
On Mon, 2018-10-01 at 23:10 +0300, Ville Syrjälä wrote:
> On Mon, Oct 01, 2018 at 12:48:28PM -0700, Rodrigo Vivi wrote:
> > On Tue, Sep 25, 2018 at 07:54:22PM -0700, Dhinakaran Pandiyan
> > wrote:
> > > A crtc modeset lock was added for link retraining but
> > > intel_dp_retrain_link() knows to take the necessary locks since
> > > commit c85d200e8321 ("drm/i915: Move SST DP link retraining into
> > > the
> > > ->post_hotplug() hook")
> > > v2: Drop AUX power domain reference in the early return path
> > >
> > > Fixes: c85d200e8321 ("drm/i915: Move SST DP link retraining into
> > > the ->post_hotplug() hook")
> >
> > This patch failed on cherry-pick for drm-intel-fixes targeting
> > 4.19.
> >
> > If it still makes sense to have it there please provide a
> > backported version
> > to drm-intel-fixes or let me know if it has dependency on other
> > patches?
>
> This is more of an optimization to not disturb page flips and whatnot
> so much with detect. The double lock is otherwise harmless due to
> ww_mutex.
>
Yeah, let's not backport this.
-DK
> >
> > Thanks,
> > Rodrigo.
> >
> > > Cc: Ville Syrjälä
> > > Signed-off-by: Dhinakaran Pandiyan > > >
> > > ---
> > > drivers/gpu/drm/i915/intel_dp.c | 24 ++--
> > > 1 file changed, 10 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 09229fc66dec..ef28cc0f122c 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -5079,8 +5079,15 @@ intel_dp_long_pulse(struct intel_connector
> > > *connector,
> > >* Some external monitors do not signal loss of link
> > > synchronization
> > >* with an IRQ_HPD, so force a link status check.
> > >*/
> > > - if (!intel_dp_is_edp(intel_dp))
> > > - intel_dp_retrain_link(encoder, ctx);
> > > + if (!intel_dp_is_edp(intel_dp)) {
> > > + int ret;
> > > +
> > > + ret = intel_dp_retrain_link(encoder, ctx);
> > > + if (ret) {
> > > + intel_display_power_put(dev_priv, intel_dp-
> > > >aux_power_domain);
> > > + return ret;
> > > + }
> > > + }
> > >
> > > /*
> > >* Clearing NACK and defer counts to get their exact values
> > > @@ -5130,19 +5137,8 @@ intel_dp_detect(struct drm_connector
> > > *connector,
> > > connector->base.id, connector->name);
> > >
> > > /* If full detect is not performed yet, do a full detect */
> > > - if (!intel_dp->detect_done) {
> > > - struct drm_crtc *crtc;
> > > - int ret;
> > > -
> > > - crtc = connector->state->crtc;
> > > - if (crtc) {
> > > - ret = drm_modeset_lock(>mutex, ctx);
> > > - if (ret)
> > > - return ret;
> > > - }
> > > -
> > > + if (!intel_dp->detect_done)
> > > status = intel_dp_long_pulse(intel_dp-
> > > >attached_connector, ctx);
> > > - }
> > >
> > > intel_dp->detect_done = false;
> > >
> > > --
> > > 2.14.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
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: Enable PSR1 on gen-9+ HW (rev2)
== Series Details == Series: drm/i915/psr: Enable PSR1 on gen-9+ HW (rev2) URL : https://patchwork.freedesktop.org/series/49312/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4909_full -> Patchwork_10312_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10312_full that come from known issues: === IGT changes === Issues hit igt@gem_cpu_reloc@full: shard-apl: PASS -> INCOMPLETE (fdo#103927) igt@gem_exec_big: shard-hsw: PASS -> TIMEOUT (fdo#107937) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) igt@perf@buffer-fill: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@perf@polling: shard-hsw: PASS -> FAIL (fdo#102252) Possible fixes igt@kms_busy@extended-modeset-hang-newfb-render-b: shard-hsw: DMESG-WARN (fdo#107956) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105363) -> PASS fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#107937 https://bugs.freedesktop.org/show_bug.cgi?id=107937 fdo#107956 https://bugs.freedesktop.org/show_bug.cgi?id=107956 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (6 -> 5) == Missing(1): shard-skl == Build changes == * Linux: CI_DRM_4909 -> Patchwork_10312 CI_DRM_4909: f045c20e31b216e68d869c9215239224b048a240 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4658: cab89ce2c5da684d01deff402d4e8e11441beadb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10312: b593302a41ec9a0f0e5826888907d3f8e2edf56f @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10312/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/6] drm/i915/dp: Fix link retraining comment in intel_dp_long_pulse()
Reviewed-by: Lyude Paul
On Mon, 2018-09-24 at 15:45 -0700, Dhinakaran Pandiyan wrote:
> Comment claims link needs to be retrained because the connected sink raised
> a long pulse to indicate link loss. If the sink did so,
> intel_dp_hotplug() would have handled link retraining. Looking at the
> logs in Bugzilla referenced in commit '3cf71bc9904d ("drm/i915: Re-apply
> Perform link quality check, unconditionally during long pulse"")', the
> issue is that the sink does not trigger an interrupt. What we want is
> ->detect() from user space to check link status and retrain. Ville's
> review for the original patch also indicates the same root cause. So,
> rewrite the comment.
>
> v2: Patch split and rewrote comment.
>
> Cc: Lyude Paul
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> Cc: Rodrigo Vivi
> Cc: Jan-Marek Glogowski
> References: 3cf71bc9904d ("drm/i915: Re-apply "Perform link quality check,
> unconditionally during long pulse"")
> Signed-off-by: Dhinakaran Pandiyan
> ---
> drivers/gpu/drm/i915/intel_dp.c | 13 +++--
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index 6b4c19123f2a..34c561011e7a 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5074,16 +5074,9 @@ intel_dp_long_pulse(struct intel_connector
> *connector,
> goto out;
> } else {
> /*
> - * If display is now connected check links status,
> - * there has been known issues of link loss triggering
> - * long pulse.
> - *
> - * Some sinks (eg. ASUS PB287Q) seem to perform some
> - * weird HPD ping pong during modesets. So we can apparently
> - * end up with HPD going low during a modeset, and then
> - * going back up soon after. And once that happens we must
> - * retrain the link to get a picture. That's in case no
> - * userspace component reacted to intermittent HPD dip.
> + * Some external monitors do not signal loss of link
> + * synchronization with an IRQ_HPD, so force a link status
> + * check.
>*/
> struct intel_encoder *encoder = _to_dig_port(intel_dp)-
> >base;
>
--
Cheers,
Lyude Paul
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/dp: Restrict link retrain workaround to external monitors
Reviewed-by: Lyude Paul
On Mon, 2018-09-24 at 15:45 -0700, Dhinakaran Pandiyan wrote:
> Commit '3cf71bc9904d ("drm/i915: Re-apply "Perform link quality check,
> unconditionally during long pulse"")' applies a work around for sinks
> that don't signal link loss. The work around does not need to have to be
> that broad as the issue was seen with only one particular monitor; limit
> this only for external displays as eDP features like PSR turn off the link
> and the driver ends up retraining the link seeeing that link is not
> synchronized.
>
> Cc: Lyude Paul
> Cc: Jan-Marek Glogowski
> Cc: Ville Syrjälä
> Cc: Rodrigo Vivi
> References: 3cf71bc9904d ("drm/i915: Re-apply "Perform link quality check,
> unconditionally during long pulse"")
> Signed-off-by: Dhinakaran Pandiyan
> ---
> drivers/gpu/drm/i915/intel_dp.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index 34c561011e7a..6130d05d8b88 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5072,12 +5072,13 @@ intel_dp_long_pulse(struct intel_connector
> *connector,
>*/
> status = connector_status_disconnected;
> goto out;
> - } else {
> - /*
> - * Some external monitors do not signal loss of link
> - * synchronization with an IRQ_HPD, so force a link status
> - * check.
> - */
> + }
> +
> + /*
> + * Some external monitors do not signal loss of link synchronization
> + * with an IRQ_HPD, so force a link status check.
> + */
> + if (!intel_dp_is_edp(intel_dp)) {
> struct intel_encoder *encoder = _to_dig_port(intel_dp)-
> >base;
>
> intel_dp_retrain_link(encoder, ctx);
--
Cheers,
Lyude Paul
___
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/2] drm/i915/guc: init GuC descriptors after GuC load
== Series Details == Series: series starting with [1/2] drm/i915/guc: init GuC descriptors after GuC load URL : https://patchwork.freedesktop.org/series/50410/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4911_full -> Patchwork_10314_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_10314_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10314_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_10314_full: === IGT changes === Warnings igt@pm_rc6_residency@rc6-accuracy: shard-kbl: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_10314_full that come from known issues: === IGT changes === Issues hit igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: shard-hsw: PASS -> DMESG-WARN (fdo#107956) igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: shard-kbl: PASS -> DMESG-WARN (fdo#107956) +1 igt@kms_flip@plain-flip-ts-check-interruptible: shard-hsw: PASS -> INCOMPLETE (fdo#103540) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_busy@extended-pageflip-hang-newfb-render-c: shard-glk: DMESG-WARN (fdo#107956) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105363) -> PASS +1 igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend: shard-apl: DMESG-WARN (fdo#103558, fdo#105602) -> PASS +4 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#107956 https://bugs.freedesktop.org/show_bug.cgi?id=107956 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (6 -> 5) == Missing(1): shard-skl == Build changes == * Linux: CI_DRM_4911 -> Patchwork_10314 CI_DRM_4911: e46b4809753a2e3d3d73c5a9e028cd030bea60e5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4659: 7f41adfbfd17027b71c332d6ae997f1364f73731 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10314: da1d0bdfa91d91916a69647e59cd721db70249bd @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10314/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 38/40] drm/i915/execlists: Flush the CS events before unpinning
On 19/09/2018 20:55, Chris Wilson wrote:
Inside the execlists submission tasklet, we often make the mistake of
assuming that everything beneath the request is available for use.
However, the submission and the request live on two separate timelines,
and the request contents may be freed from an early retirement before we
have had a chance to run the submission tasklet (think ksoftirqd). To
safeguard ourselves against any mistakes, flush the tasklet before we
unpin the context if execlists still has a reference to this context.
References: 60367132a214 ("drm/i915: Avoid use-after-free of ctx in request
tracepoints")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_context.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c| 32 -
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index 9f89119a6566..1fd71dfdfa62 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -170,6 +170,7 @@ struct i915_gem_context {
/** engine: per-engine logical HW state */
struct intel_context {
struct i915_gem_context *gem_context;
+ struct intel_engine_cs *active;
struct i915_vma *state;
struct intel_ring *ring;
u32 *lrc_reg_state;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 48a2bca7fec3..be7dbdd7fc2c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -282,6 +282,8 @@ static void __unwind_incomplete_requests(struct
intel_engine_cs *engine)
__i915_request_unsubmit(rq);
unwind_wa_tail(rq);
+ GEM_BUG_ON(rq->hw_context->active);
+
GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID);
if (rq_prio(rq) != prio) {
prio = rq_prio(rq);
@@ -427,8 +429,11 @@ static void execlists_submit_ports(struct intel_engine_cs
*engine)
rq = port_unpack([n], );
if (rq) {
GEM_BUG_ON(count > !n);
- if (!count++)
+ if (!count++) {
+ GEM_BUG_ON(rq->hw_context->active);
execlists_context_schedule_in(rq);
+ rq->hw_context->active = engine;
Put it in execlists_context_schedule_in/out?
Why does it have to be the engine pointer and not just a boolean?
Because we don't have an engine backpointer in hw_context? Should we add
it? I think I had occasionally wished we had it.. maybe too much work to
evaluate what function prototypes we could clean up with it and whether
it would be an overall gain.
+ }
port_set([n], port_pack(rq, count));
desc = execlists_update_context(rq);
GEM_DEBUG_EXEC(port[n].context_id =
upper_32_bits(desc));
@@ -734,6 +739,8 @@ execlists_cancel_port_requests(struct
intel_engine_execlists * const execlists)
intel_engine_get_seqno(rq->engine));
GEM_BUG_ON(!execlists->active);
+
+ rq->hw_context->active = NULL;
execlists_context_schedule_out(rq,
i915_request_completed(rq) ?
INTEL_CONTEXT_SCHEDULE_OUT :
@@ -971,6 +978,7 @@ static void process_csb(struct intel_engine_cs *engine)
*/
GEM_BUG_ON(!i915_request_completed(rq));
+ rq->hw_context->active = NULL;
execlists_context_schedule_out(rq,
INTEL_CONTEXT_SCHEDULE_OUT);
i915_request_put(rq);
@@ -1080,6 +1088,28 @@ static void execlists_context_destroy(struct
intel_context *ce)
static void execlists_context_unpin(struct intel_context *ce)
{
+ struct intel_engine_cs *engine;
+
+ /*
+* The tasklet may still be using a pointer to our state, via an
+* old request. However, since we know we only unpin the context
+* on retirement of the following request, we know that the last
+* request referencing us will have had a completion CS interrupt.
Hm hm hm... my initial thought was that interrupts could be more delayed
than breadcrumb writes (more than one context ahead), in which case the
process_csb below could be premature and the assert would trigger. But I
must be forgetting something since that would also mean we would
prematurely unpin the context. So I must be forgetting something..
Regards,
Tvrtko
+* If we see that it is still active, it means that the tasklet hasn't
+* had the chance to run yet; let it run before we teardown the
+* reference it
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915/selftests: Split preemption smoke test into threads (rev2)
== Series Details == Series: series starting with [1/4] drm/i915/selftests: Split preemption smoke test into threads (rev2) URL : https://patchwork.freedesktop.org/series/50329/ State : warning == Summary == $ dim checkpatch origin/drm-tip 949446d4ae2f drm/i915/selftests: Split preemption smoke test into threads -:33: WARNING:LINE_SPACING: Missing a blank line after declarations #33: FILE: drivers/gpu/drm/i915/selftests/intel_lrc.c:605: + struct preempt_smoke *smoke = arg; + IGT_TIMEOUT(end_time); total: 0 errors, 1 warnings, 0 checks, 100 lines checked 27ea74d97340 drm/i915/selftests: Include arbitration points in preemption smoketest 8a4361322e2b drm/i915: Reserve some priority bits for internal use 05453e086003 drm/i915: Combine multiple internal plists into the same i915_priolist bucket -:167: WARNING:FUNCTION_ARGUMENTS: function definition argument 'pl' should also have an identifier name #167: FILE: drivers/gpu/drm/i915/intel_lrc.c:367: + struct list_head *uninitialized_var(pl); -:285: WARNING:FUNCTION_ARGUMENTS: function definition argument 'pl' should also have an identifier name #285: FILE: drivers/gpu/drm/i915/intel_lrc.c:1179: + struct list_head *uninitialized_var(pl); -:314: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'plist' - possible side-effects? #314: FILE: drivers/gpu/drm/i915/intel_ringbuffer.h:199: +#define priolist_for_each_request(it, plist, idx) \ + for (idx = 0; idx < ARRAY_SIZE((plist)->requests); idx++) \ + list_for_each_entry(it, &(plist)->requests[idx], sched.link) -:314: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'idx' - possible side-effects? #314: FILE: drivers/gpu/drm/i915/intel_ringbuffer.h:199: +#define priolist_for_each_request(it, plist, idx) \ + for (idx = 0; idx < ARRAY_SIZE((plist)->requests); idx++) \ + list_for_each_entry(it, &(plist)->requests[idx], sched.link) -:318: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'plist' - possible side-effects? #318: FILE: drivers/gpu/drm/i915/intel_ringbuffer.h:203: +#define priolist_for_each_request_consume(it, n, plist, idx) \ + for (; (idx = ffs((plist)->used)); (plist)->used &= ~BIT(idx - 1)) \ + list_for_each_entry_safe(it, n, \ +&(plist)->requests[idx - 1], \ +sched.link) -:318: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'idx' - possible side-effects? #318: FILE: drivers/gpu/drm/i915/intel_ringbuffer.h:203: +#define priolist_for_each_request_consume(it, n, plist, idx) \ + for (; (idx = ffs((plist)->used)); (plist)->used &= ~BIT(idx - 1)) \ + list_for_each_entry_safe(it, n, \ +&(plist)->requests[idx - 1], \ +sched.link) total: 0 errors, 2 warnings, 4 checks, 272 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 3/3] drm/i915/icl: Calculate DPLL params for DSI
> -Original Message-
> From: Ville Syrjälä
> Sent: Wednesday, September 26, 2018 7:52 PM
> To: Kulkarni, Vandita
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ;
> Zanoni, Paulo R
> Subject: Re: [Intel-gfx] [RFC 3/3] drm/i915/icl: Calculate DPLL params for DSI
>
> On Thu, Sep 20, 2018 at 08:49:52AM +, Kulkarni, Vandita wrote:
> >
> >
> > > -Original Message-
> > > From: Ville Syrjälä
> > > Sent: Friday, September 14, 2018 9:39 PM
> > > To: Kulkarni, Vandita
> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > > ; Zanoni, Paulo R
> > > Subject: Re: [Intel-gfx] [RFC 3/3] drm/i915/icl: Calculate DPLL
> > > params for DSI
> > >
> > > On Fri, Sep 14, 2018 at 12:24:14PM +0530, Vandita Kulkarni wrote:
> > > > From: Madhav Chauhan
> > > >
> > > > This patch calculate various DPLL dividers and parameters for DSI
> > > > encoder and adjust AFE clock for DSI. For DSI, 8x clock is AFE clock.
> > > >
> > > > v2: Extend haswell_crtc_compute_clock() for Gen11 DSI
> > > > v3: Rebase
> > > >
> > > > Signed-off-by: Madhav Chauhan
> > > > Signed-off-by: Vandita Kulkarni
> > > > ---
> > > > drivers/gpu/drm/i915/intel_display.c | 4 +++-
> > > > drivers/gpu/drm/i915/intel_dpll_mgr.c | 7 ++-
> > > > 2 files changed, 9 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index 6928dcc..1a44c5e 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -9238,10 +9238,12 @@ void hsw_disable_pc8(struct
> > > > drm_i915_private
> > > > *dev_priv) static int haswell_crtc_compute_clock(struct intel_crtc
> > > > *crtc,
> > > > struct intel_crtc_state
> > > > *crtc_state) {
> > > > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > > struct intel_atomic_state *state =
> > > > to_intel_atomic_state(crtc_state->base.state);
> > > >
> > > > - if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI)) {
> > > > + if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI) ||
> > > > +IS_ICELAKE(dev_priv)) {
> > > > struct intel_encoder *encoder =
> > > > intel_get_crtc_new_encoder(state, crtc_state);
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > index 36ed155..5175e44 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > @@ -22,6 +22,7 @@
> > > > */
> > > >
> > > > #include "intel_drv.h"
> > > > +#include "intel_dsi.h"
> > > >
> > > > /**
> > > > * DOC: Display PLLs
> > > > @@ -2532,7 +2533,11 @@ static bool icl_calc_dpll_state(struct
> > > intel_crtc_state *crtc_state,
> > > > ret = icl_calc_tbt_pll(dev_priv, clock, _params);
> > > > else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> > > > ret = cnl_ddi_calculate_wrpll(clock, dev_priv,
> > > > _params);
> > > > - else
> > > > + else if (encoder->type == INTEL_OUTPUT_DSI) {
> > > > + struct intel_dsi *intel_dsi =
> > > > enc_to_intel_dsi(>base);
> > > > + ret = cnl_ddi_calculate_wrpll(intel_dsi->bitrate_khz/5,
> > >
> > > Missing port_clock=whatever in compute config?
> > As per the spec I see that for mipi dsi on icl, 8x clock = AFE clock.
> > And 8x clock is calculated and stored already as pixel_clk * bpp /
> > lane_count Hence we are using already calculate 8x clock variable here
> > and divide by/5 because later in the function it gets multiplied by 5 for
> > afe
> clock.
> >
> > port_clock is assigned to pixel clock as I see.
>
> port_clock can basically be anything you want. It's really up to the encoder
> to
> define it. For DP it's the freq (1.62ghz, 2.7ghz, etc.), for HDMI it's the
> TMDS
> character rate, for SDVO it's the multiplied pixel clock, etc.
>
> I suppose that means that currently port_clock is the output from the dpll in
> pretty much all cases. Sticking to that same rule will make DSI look less
> special
> and thus easier to understand for everyone.
Thank you, I will assign this bitrate_khz (dsi_clk) to port_clock.
Regards,
Vandita
>
> > Please let me know if we have to use math around the port clock and pass
> > that
> value, than passing 8x clock.
> >
> > Thanks,
> > Vandita
> > >
> > > > + dev_priv, _params);
> > > > + } else
> > > > ret = icl_calc_dp_combo_pll(dev_priv, clock,
> > > > _params);
> > > >
> > > > if (!ret)
> > > > --
> > > > 1.9.1
> > > >
> > > > ___
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >
> > > --
> > > Ville
Re: [Intel-gfx] [PATCH 6/6] drm/i915/icl: Support co-existence between per-context SSEU and OA
On 01/10/2018 12:06, Lionel Landwerlin wrote:
On 01/10/2018 12:20, Tvrtko Ursulin wrote:
On 01/10/2018 10:50, Lionel Landwerlin wrote:
On 17/09/2018 13:30, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
When OA is active we want to lock the powergating configuration, but on
Icelake, users like the media stack will have issues if we lock to the
full device configuration.
Instead lock to a subset of (sub)slices which are currently a known
working configuration for all users.
v2:
* Fix commit message spelling.
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
---
drivers/gpu/drm/i915/intel_lrc.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index b5603e977a3f..cded1f1d9ec2 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2521,13 +2521,28 @@ u32 gen8_make_rpcs(struct drm_i915_private
*i915, struct intel_sseu *req_sseu)
/*
* If i915/perf is active, we want a stable powergating
configuration
- * on the system. The most natural configuration to take in
that case
- * is the default (i.e maximum the hardware can do).
+ * on the system.
+ *
+ * We could choose full enablement, but on ICL we know there
are use
+ * cases which disable slices for functional, apart for
performance
+ * reasons. So in this case we select a known stable subset.
*/
- if (unlikely(i915->perf.oa.exclusive_stream))
- ctx_sseu = intel_device_default_sseu(i915);
- else
+ if (!i915->perf.oa.exclusive_stream) {
ctx_sseu = *req_sseu;
+ } else {
+ ctx_sseu = intel_device_default_sseu(i915);
+
+ if (IS_GEN11(i915)) {
+ /*
+ * We only need subslice count so it doesn't matter
+ * which ones we select - just turn of low bits in the
s/turn of/turn off/
Yep, thanks.
+ * amount of half of all available subslices per slice.
+ */
+ ctx_sseu.subslice_mask =
+ ~(~0 << (hweight8(ctx_sseu.subslice_mask) / 2));
I would go with :
ctx_sseu.subslice_mask = ctx_sseu.subslice_mask & 0xf;
Documentation says that the first 4 subslices are the "big" ones
(gathered from the fusing register fields which go from
slice0-subslice[0-3] then slice1-subslice[0-3], etc...), so this
should be equally media/3d capable.
Doesn't work I think - one 1x6x8 part I've seen has a subslice mask of
0b1100 and there we want to have three subslices enabled.
Regards,
Tvrtko
Thanks, then the fusing fields don't match for a big/small sets of
subslices.
I guess the fusing might be in this pattern (Small/Big) : SBSBSBSB
I was hoping we could know so that we program the powergating at the
most capable configuration.
It will be the most capable configuration. Did you forget the RPCS
register in ICL works with counts and not masks? According the that
Bspec table we cannot select anything but the most capable configuration.
Regards,
Tvrtko
___
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/7] drm/i915/icl: Add WaEnable32PlaneMode
== Series Details == Series: series starting with [1/7] drm/i915/icl: Add WaEnable32PlaneMode URL : https://patchwork.freedesktop.org/series/50340/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4906 -> Patchwork_10303 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/50340/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10303 that come from known issues: === IGT changes === Issues hit igt@drv_module_reload@basic-reload: fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718) igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: PASS -> DMESG-WARN (fdo#102614) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-bdw-samus: NOTRUN -> INCOMPLETE (fdo#107773) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-icl-u: PASS -> INCOMPLETE (fdo#107713) igt@pm_rpm@basic-pci-d3-state: fi-skl-6600u: PASS -> FAIL (fdo#107707) Possible fixes igt@gem_exec_suspend@basic-s3: fi-bdw-samus: INCOMPLETE (fdo#107773) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: 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#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107707 https://bugs.freedesktop.org/show_bug.cgi?id=107707 fdo#107713 https://bugs.freedesktop.org/show_bug.cgi?id=107713 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773 == Participating hosts (50 -> 45) == Additional (2): fi-skl-caroline fi-snb-2520m Missing(7): fi-hsw-4770r fi-ilk-m540 fi-byt-squawks fi-icl-u2 fi-bsw-cyan fi-ctg-p8600 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4906 -> Patchwork_10303 CI_DRM_4906: 187637a6495f71dd240d02badbf2fecc1e3c1bb2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4658: cab89ce2c5da684d01deff402d4e8e11441beadb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10303: 701c41d934c219edba293256032e0262e7e7fb0c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 701c41d934c2 drm/i915/icl: Add Wa_1406609255 6782832c3e2f drm/i915/icl: WaAllowUMDToModifyHalfSliceChicken7 592a1d4a7b2a drm/i915/icl: WaAllowUMDToModifyHalfSliceChicken2 06b0334e7372 drm/i915/icl: WaSendPushConstantsFromMMIO 91f7b4d05da2 drm/i915/icl: Implement Display WA_1405510057 73f64ac7335e drm/i915/icl: apply Display WA #1178 to fix type C dongles 0d6df61c673c drm/i915/icl: Add WaEnable32PlaneMode == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10303/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 3/3] drm/i915/icl: Calculate DPLL params for DSI
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Kulkarni, Vandita
> Sent: Monday, October 1, 2018 5:00 PM
> To: Ville Syrjälä
> Cc: Nikula, Jani ; intel-gfx@lists.freedesktop.org;
> Zanoni, Paulo R
> Subject: Re: [Intel-gfx] [RFC 3/3] drm/i915/icl: Calculate DPLL params for DSI
>
>
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Wednesday, September 26, 2018 7:52 PM
> > To: Kulkarni, Vandita
> > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > ; Zanoni, Paulo R
> > Subject: Re: [Intel-gfx] [RFC 3/3] drm/i915/icl: Calculate DPLL params
> > for DSI
> >
> > On Thu, Sep 20, 2018 at 08:49:52AM +, Kulkarni, Vandita wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Ville Syrjälä
> > > > Sent: Friday, September 14, 2018 9:39 PM
> > > > To: Kulkarni, Vandita
> > > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > > > ; Zanoni, Paulo R
> > > >
> > > > Subject: Re: [Intel-gfx] [RFC 3/3] drm/i915/icl: Calculate DPLL
> > > > params for DSI
> > > >
> > > > On Fri, Sep 14, 2018 at 12:24:14PM +0530, Vandita Kulkarni wrote:
> > > > > From: Madhav Chauhan
> > > > >
> > > > > This patch calculate various DPLL dividers and parameters for
> > > > > DSI encoder and adjust AFE clock for DSI. For DSI, 8x clock is AFE
> > > > > clock.
> > > > >
> > > > > v2: Extend haswell_crtc_compute_clock() for Gen11 DSI
> > > > > v3: Rebase
> > > > >
> > > > > Signed-off-by: Madhav Chauhan
> > > > > Signed-off-by: Vandita Kulkarni
> > > > > ---
> > > > > drivers/gpu/drm/i915/intel_display.c | 4 +++-
> > > > > drivers/gpu/drm/i915/intel_dpll_mgr.c | 7 ++-
> > > > > 2 files changed, 9 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > > index 6928dcc..1a44c5e 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > > @@ -9238,10 +9238,12 @@ void hsw_disable_pc8(struct
> > > > > drm_i915_private
> > > > > *dev_priv) static int haswell_crtc_compute_clock(struct intel_crtc
> *crtc,
> > > > > struct intel_crtc_state
> > > > > *crtc_state) {
> > > > > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > > > struct intel_atomic_state *state =
> > > > > to_intel_atomic_state(crtc_state->base.state);
> > > > >
> > > > > - if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI)) {
> > > > > + if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI) ||
> > > > > + IS_ICELAKE(dev_priv)) {
> > > > > struct intel_encoder *encoder =
> > > > > intel_get_crtc_new_encoder(state, crtc_state);
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > > index 36ed155..5175e44 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > > @@ -22,6 +22,7 @@
> > > > > */
> > > > >
> > > > > #include "intel_drv.h"
> > > > > +#include "intel_dsi.h"
> > > > >
> > > > > /**
> > > > > * DOC: Display PLLs
> > > > > @@ -2532,7 +2533,11 @@ static bool icl_calc_dpll_state(struct
> > > > intel_crtc_state *crtc_state,
> > > > > ret = icl_calc_tbt_pll(dev_priv, clock, _params);
> > > > > else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> > > > > ret = cnl_ddi_calculate_wrpll(clock, dev_priv,
> > > > > _params);
> > > > > - else
> > > > > + else if (encoder->type == INTEL_OUTPUT_DSI) {
> > > > > + struct intel_dsi *intel_dsi =
> enc_to_intel_dsi(>base);
> > > > > + ret = cnl_ddi_calculate_wrpll(intel_dsi-
> >bitrate_khz/5,
> > > >
> > > > Missing port_clock=whatever in compute config?
> > > As per the spec I see that for mipi dsi on icl, 8x clock = AFE clock.
> > > And 8x clock is calculated and stored already as pixel_clk * bpp /
> > > lane_count Hence we are using already calculate 8x clock variable
> > > here and divide by/5 because later in the function it gets
> > > multiplied by 5 for afe
> > clock.
> > >
> > > port_clock is assigned to pixel clock as I see.
> >
> > port_clock can basically be anything you want. It's really up to the
> > encoder to define it. For DP it's the freq (1.62ghz, 2.7ghz, etc.),
> > for HDMI it's the TMDS character rate, for SDVO it's the multiplied pixel
> clock, etc.
> >
> > I suppose that means that currently port_clock is the output from the
> > dpll in pretty much all cases. Sticking to that same rule will make
> > DSI look less special and thus easier to understand for everyone.
>
> Thank you, I will assign this bitrate_khz (dsi_clk) to port_clock.
Please make sure we are not breaking anything else by doing this as there will
be assumption
In DSI code that this is the pixelclk.
Re: [Intel-gfx] [PATCH 6/6] drm/i915/icl: Support co-existence between per-context SSEU and OA
On 01/10/2018 10:50, Lionel Landwerlin wrote:
On 17/09/2018 13:30, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
When OA is active we want to lock the powergating configuration, but on
Icelake, users like the media stack will have issues if we lock to the
full device configuration.
Instead lock to a subset of (sub)slices which are currently a known
working configuration for all users.
v2:
* Fix commit message spelling.
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
---
drivers/gpu/drm/i915/intel_lrc.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index b5603e977a3f..cded1f1d9ec2 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2521,13 +2521,28 @@ u32 gen8_make_rpcs(struct drm_i915_private
*i915, struct intel_sseu *req_sseu)
/*
* If i915/perf is active, we want a stable powergating
configuration
- * on the system. The most natural configuration to take in that
case
- * is the default (i.e maximum the hardware can do).
+ * on the system.
+ *
+ * We could choose full enablement, but on ICL we know there are use
+ * cases which disable slices for functional, apart for performance
+ * reasons. So in this case we select a known stable subset.
*/
- if (unlikely(i915->perf.oa.exclusive_stream))
- ctx_sseu = intel_device_default_sseu(i915);
- else
+ if (!i915->perf.oa.exclusive_stream) {
ctx_sseu = *req_sseu;
+ } else {
+ ctx_sseu = intel_device_default_sseu(i915);
+
+ if (IS_GEN11(i915)) {
+ /*
+ * We only need subslice count so it doesn't matter
+ * which ones we select - just turn of low bits in the
s/turn of/turn off/
Yep, thanks.
+ * amount of half of all available subslices per slice.
+ */
+ ctx_sseu.subslice_mask =
+ ~(~0 << (hweight8(ctx_sseu.subslice_mask) / 2));
I would go with :
ctx_sseu.subslice_mask = ctx_sseu.subslice_mask & 0xf;
Documentation says that the first 4 subslices are the "big" ones
(gathered from the fusing register fields which go from
slice0-subslice[0-3] then slice1-subslice[0-3], etc...), so this should
be equally media/3d capable.
Doesn't work I think - one 1x6x8 part I've seen has a subslice mask of
0b1100 and there we want to have three subslices enabled.
Regards,
Tvrtko
+ ctx_sseu.slice_mask = 0x1;
+ }
+ }
slices = hweight8(ctx_sseu.slice_mask);
subslices = hweight8(ctx_sseu.subslice_mask);
___
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 4/7] drm/i915/icl: WaSendPushConstantsFromMMIO
Why is this mixed with display workarounds?
These were already once on the list and were decided not to be included
as there are no known users.
Regards, Joonas
Quoting Radhakrishna Sripada (2018-09-28 19:47:35)
> From: Oscar Mateo
>
> Allows UMDs to set 'Disable Gather at Set Shader Common Slice'.
>
> Cc: Mika Kuoppala
> Signed-off-by: Oscar Mateo
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/i915/intel_workarounds.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> b/drivers/gpu/drm/i915/intel_workarounds.c
> index ba4009b4ad2c..d0a982868964 100644
> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> @@ -1013,6 +1013,8 @@ static void cnl_whitelist_build(struct whitelist *w)
>
> static void icl_whitelist_build(struct whitelist *w)
> {
> + /* WaSendPushConstantsFromMMIO:icl */
> + whitelist_reg(w, COMMON_SLICE_CHICKEN2);
> }
>
> static struct whitelist *whitelist_build(struct intel_engine_cs *engine,
> --
> 2.9.3
>
> ___
> 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.CHECKPATCH: warning for series starting with [1/5] drm/dp/mst: Configure no_stop_bit correctly for remote i2c xfers
== Series Details ==
Series: series starting with [1/5] drm/dp/mst: Configure no_stop_bit correctly
for remote i2c xfers
URL : https://patchwork.freedesktop.org/series/50341/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3c513d17e3fc drm/dp/mst: Configure no_stop_bit correctly for remote i2c xfers
12c216b98bf5 drm/dp/mst: Validate REMOTE_I2C_READ harder
732333e972e3 drm/dp: Implement I2C_M_STOP for i2c-over-aux
4fcf4b69c01d drm/dp/mst: Provide defines for ACK vs. NAK reply type
-:99: WARNING:BRACES: braces {} are not necessary for single statement blocks
#99: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:2351:
+ if (txmsg->reply.reply_type == DP_REPLY_NAK) {
DRM_DEBUG_KMS("Got NAK reply: req 0x%02x, reason
0x%02x, nak data 0x%02x\n", txmsg->reply.req_type, txmsg->reply.u.nak.reason,
txmsg->reply.u.nak.nak_data);
}
total: 0 errors, 1 warnings, 0 checks, 94 lines checked
3ce151fed736 drm/dp/mst: Provide better debugs for NAK replies
-:22: ERROR:BRACKET_SPACE: space prohibited before open square bracket '['
#22: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:70:
+#define STR(x) [DP_ ## x] = #x
-:53: ERROR:BRACKET_SPACE: space prohibited before open square bracket '['
#53: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:101:
+#define STR(x) [DP_NAK_ ## x] = #x
total: 2 errors, 0 warnings, 0 checks, 84 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Add Wa_1606682166 (rev2)
== Series Details == Series: Add Wa_1606682166 (rev2) URL : https://patchwork.freedesktop.org/series/50349/ State : failure == Summary == Applying: drm/i915/icl:Add Wa_1606682166 error: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_reg.h). error: could not build fake ancestor Patch failed at 0001 drm/i915/icl:Add Wa_1606682166 Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ 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/5] drm/dp/mst: Configure no_stop_bit correctly for remote i2c xfers
== Series Details == Series: series starting with [1/5] drm/dp/mst: Configure no_stop_bit correctly for remote i2c xfers URL : https://patchwork.freedesktop.org/series/50341/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4906 -> Patchwork_10304 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/50341/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10304 that come from known issues: === IGT changes === Possible fixes igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-byt-clapper: FAIL (fdo#103191, fdo#107362) -> PASS fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 == Participating hosts (50 -> 47) == Additional (2): fi-skl-caroline fi-snb-2520m Missing(5): fi-ctg-p8600 fi-bsw-cyan fi-ilk-m540 fi-byt-squawks fi-icl-u2 == Build changes == * Linux: CI_DRM_4906 -> Patchwork_10304 CI_DRM_4906: 187637a6495f71dd240d02badbf2fecc1e3c1bb2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4658: cab89ce2c5da684d01deff402d4e8e11441beadb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10304: 3ce151fed736e40a6011327e4c320782c6c00c9d @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 3ce151fed736 drm/dp/mst: Provide better debugs for NAK replies 4fcf4b69c01d drm/dp/mst: Provide defines for ACK vs. NAK reply type 732333e972e3 drm/dp: Implement I2C_M_STOP for i2c-over-aux 12c216b98bf5 drm/dp/mst: Validate REMOTE_I2C_READ harder 3c513d17e3fc drm/dp/mst: Configure no_stop_bit correctly for remote i2c xfers == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10304/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915/selftests: Split preemption smoke test into threads
When submitting chains to each engine, we can do so (mostly) in
parallel, so delegate submission to threads on a per-engine basis.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/intel_lrc.c | 73 ++
1 file changed, 61 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/intel_lrc.c
b/drivers/gpu/drm/i915/selftests/intel_lrc.c
index 3a474bb64c05..d68a924c530e 100644
--- a/drivers/gpu/drm/i915/selftests/intel_lrc.c
+++ b/drivers/gpu/drm/i915/selftests/intel_lrc.c
@@ -587,8 +587,10 @@ static int random_priority(struct rnd_state *rnd)
struct preempt_smoke {
struct drm_i915_private *i915;
struct i915_gem_context **contexts;
+ struct intel_engine_cs *engine;
unsigned int ncontext;
struct rnd_state prng;
+ unsigned long count;
};
static struct i915_gem_context *smoke_context(struct preempt_smoke *smoke)
@@ -597,31 +599,78 @@ static struct i915_gem_context *smoke_context(struct
preempt_smoke *smoke)
>prng)];
}
+static int smoke_crescendo_thread(void *arg)
+{
+ struct preempt_smoke *smoke = arg;
+ IGT_TIMEOUT(end_time);
+ unsigned long count;
+
+ count = 0;
+ do {
+ struct i915_gem_context *ctx = smoke_context(smoke);
+ struct i915_request *rq;
+
+ mutex_lock(>i915->drm.struct_mutex);
+
+ ctx->sched.priority = count % I915_PRIORITY_MAX;
+
+ rq = i915_request_alloc(smoke->engine, ctx);
+ if (IS_ERR(rq)) {
+ mutex_unlock(>i915->drm.struct_mutex);
+ return PTR_ERR(rq);
+ }
+
+ i915_request_add(rq);
+
+ mutex_unlock(>i915->drm.struct_mutex);
+
+ count++;
+ } while (!__igt_timeout(end_time, NULL));
+
+ smoke->count = count;
+ return 0;
+}
+
static int smoke_crescendo(struct preempt_smoke *smoke)
{
+ struct task_struct *tsk[I915_NUM_ENGINES] = {};
+ struct preempt_smoke arg[I915_NUM_ENGINES];
struct intel_engine_cs *engine;
enum intel_engine_id id;
unsigned long count;
+ int err = 0;
+
+ mutex_unlock(>i915->drm.struct_mutex);
- count = 0;
for_each_engine(engine, smoke->i915, id) {
- IGT_TIMEOUT(end_time);
+ arg[id] = *smoke;
+ arg[id].engine = engine;
+ arg[id].count = 0;
+
+ tsk[id] = kthread_run(smoke_crescendo_thread, ,
+ "igt/smoke:%d", id);
+ if (IS_ERR(tsk[id])) {
+ err = PTR_ERR(tsk[id]);
+ break;
+ }
+ }
- do {
- struct i915_gem_context *ctx = smoke_context(smoke);
- struct i915_request *rq;
+ count = 0;
+ for_each_engine(engine, smoke->i915, id) {
+ int status;
- ctx->sched.priority = count % I915_PRIORITY_MAX;
+ if (IS_ERR_OR_NULL(tsk[id]))
+ continue;
- rq = i915_request_alloc(engine, ctx);
- if (IS_ERR(rq))
- return PTR_ERR(rq);
+ status = kthread_stop(tsk[id]);
+ if (status && !err)
+ err = status;
- i915_request_add(rq);
- count++;
- } while (!__igt_timeout(end_time, NULL));
+ count += arg[id].count;
}
+ mutex_lock(>i915->drm.struct_mutex);
+
pr_info("Submitted %lu crescendo requests across %d engines and %d
contexts\n",
count, INTEL_INFO(smoke->i915)->num_rings, smoke->ncontext);
return 0;
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: Reserve some priority bits for internal use
In the next few patches, we will want to give a small priority boost to
some requests/queues but not so much that we perturb the user controlled
order. As such we will shift the user priority bits higher leaving
ourselves a few low priority bits for our internal bumping.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h| 2 +-
drivers/gpu/drm/i915/i915_gem_context.c| 9 +
drivers/gpu/drm/i915/i915_scheduler.h | 6 ++
drivers/gpu/drm/i915/selftests/intel_lrc.c | 8 +---
4 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 30191523c309..b672ed0cac24 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3236,7 +3236,7 @@ int i915_gem_object_wait(struct drm_i915_gem_object *obj,
int i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
unsigned int flags,
const struct i915_sched_attr *attr);
-#define I915_PRIORITY_DISPLAY I915_PRIORITY_MAX
+#define I915_PRIORITY_DISPLAY I915_USER_PRIORITY(I915_PRIORITY_MAX)
int __must_check
i915_gem_object_set_to_wc_domain(struct drm_i915_gem_object *obj, bool write);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 15c92f75b1b8..8cbe58070561 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -337,7 +337,7 @@ __create_hw_context(struct drm_i915_private *dev_priv,
kref_init(>ref);
list_add_tail(>link, _priv->contexts.list);
ctx->i915 = dev_priv;
- ctx->sched.priority = I915_PRIORITY_NORMAL;
+ ctx->sched.priority = I915_USER_PRIORITY(I915_PRIORITY_NORMAL);
for (n = 0; n < ARRAY_SIZE(ctx->__engine); n++) {
struct intel_context *ce = >__engine[n];
@@ -504,7 +504,7 @@ i915_gem_context_create_kernel(struct drm_i915_private
*i915, int prio)
}
i915_gem_context_clear_bannable(ctx);
- ctx->sched.priority = prio;
+ ctx->sched.priority = I915_USER_PRIORITY(prio);
ctx->ring_size = PAGE_SIZE;
GEM_BUG_ON(!i915_gem_context_is_kernel(ctx));
@@ -879,7 +879,7 @@ int i915_gem_context_getparam_ioctl(struct drm_device *dev,
void *data,
args->value = i915_gem_context_is_bannable(ctx);
break;
case I915_CONTEXT_PARAM_PRIORITY:
- args->value = ctx->sched.priority;
+ args->value = ctx->sched.priority >> I915_USER_PRIORITY_SHIFT;
break;
default:
ret = -EINVAL;
@@ -948,7 +948,8 @@ int i915_gem_context_setparam_ioctl(struct drm_device *dev,
void *data,
!capable(CAP_SYS_NICE))
ret = -EPERM;
else
- ctx->sched.priority = priority;
+ ctx->sched.priority =
+ I915_USER_PRIORITY(priority);
}
break;
diff --git a/drivers/gpu/drm/i915/i915_scheduler.h
b/drivers/gpu/drm/i915/i915_scheduler.h
index 70a42220358d..89d456312557 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.h
+++ b/drivers/gpu/drm/i915/i915_scheduler.h
@@ -19,6 +19,12 @@ enum {
I915_PRIORITY_INVALID = INT_MIN
};
+#define I915_USER_PRIORITY_SHIFT 0
+#define I915_USER_PRIORITY(x) ((x) << I915_USER_PRIORITY_SHIFT)
+
+#define I915_PRIORITY_COUNT BIT(I915_USER_PRIORITY_SHIFT)
+#define I915_PRIORITY_MASK (I915_PRIORITY_COUNT - 1)
+
struct i915_sched_attr {
/**
* @priority: execution and service priority
diff --git a/drivers/gpu/drm/i915/selftests/intel_lrc.c
b/drivers/gpu/drm/i915/selftests/intel_lrc.c
index d67fe8335ceb..c8b7f03c35bd 100644
--- a/drivers/gpu/drm/i915/selftests/intel_lrc.c
+++ b/drivers/gpu/drm/i915/selftests/intel_lrc.c
@@ -292,12 +292,14 @@ static int live_preempt(void *arg)
ctx_hi = kernel_context(i915);
if (!ctx_hi)
goto err_spin_lo;
- ctx_hi->sched.priority = I915_CONTEXT_MAX_USER_PRIORITY;
+ ctx_hi->sched.priority =
+ I915_USER_PRIORITY(I915_CONTEXT_MAX_USER_PRIORITY);
ctx_lo = kernel_context(i915);
if (!ctx_lo)
goto err_ctx_hi;
- ctx_lo->sched.priority = I915_CONTEXT_MIN_USER_PRIORITY;
+ ctx_lo->sched.priority =
+ I915_USER_PRIORITY(I915_CONTEXT_MIN_USER_PRIORITY);
for_each_engine(engine, i915, id) {
struct i915_request *rq;
@@ -418,7 +420,7 @@ static int live_late_preempt(void *arg)
goto err_wedged;
}
- attr.priority = I915_PRIORITY_MAX;
+ attr.priority = I915_USER_PRIORITY(I915_PRIORITY_MAX);
engine->schedule(rq, );
if (!wait_for_spinner(_hi, rq))
[Intel-gfx] [PATCH 4/4] drm/i915: Combine multiple internal plists into the same i915_priolist bucket
As we are about to allow ourselves to slightly bump the user priority
into a few different sublevels, packthose internal priority lists
into the same i915_priolist to keep the rbtree compact and avoid having
to allocate the default user priority even after the internal bumping.
The downside to having an requests[] rather than a node per active list,
is that we then have to walk over the empty higher priority lists. To
compensate, we track the active buckets and use a small bitmap to skip
over any inactive ones.
v2: Use MASK of internal levels to simplify our usage.
v3: Prevent overflow when SHIFT is zero.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 6 +-
drivers/gpu/drm/i915/intel_guc_submission.c | 12 ++-
drivers/gpu/drm/i915/intel_lrc.c| 87 ++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 13 ++-
4 files changed, 80 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 6726d57f018f..1c6143bdf5a4 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1534,10 +1534,10 @@ void intel_engine_dump(struct intel_engine_cs *engine,
count = 0;
drm_printf(m, "\t\tQueue priority: %d\n", execlists->queue_priority);
for (rb = rb_first_cached(>queue); rb; rb = rb_next(rb)) {
- struct i915_priolist *p =
- rb_entry(rb, typeof(*p), node);
+ struct i915_priolist *p = rb_entry(rb, typeof(*p), node);
+ int i;
- list_for_each_entry(rq, >requests, sched.link) {
+ priolist_for_each_request(rq, p, i) {
if (count++ < MAX_REQUESTS_TO_SHOW - 1)
print_request(m, rq, "\t\tQ ");
else
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 4874a212754c..ac862b42f6a1 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -746,30 +746,28 @@ static bool __guc_dequeue(struct intel_engine_cs *engine)
while ((rb = rb_first_cached(>queue))) {
struct i915_priolist *p = to_priolist(rb);
struct i915_request *rq, *rn;
+ int i;
- list_for_each_entry_safe(rq, rn, >requests, sched.link) {
+ priolist_for_each_request_consume(rq, rn, p, i) {
if (last && rq->hw_context != last->hw_context) {
- if (port == last_port) {
- __list_del_many(>requests,
- >sched.link);
+ if (port == last_port)
goto done;
- }
if (submit)
port_assign(port, last);
port++;
}
- INIT_LIST_HEAD(>sched.link);
+ list_del_init(>sched.link);
__i915_request_submit(rq);
trace_i915_request_in(rq, port_index(port, execlists));
+
last = rq;
submit = true;
}
rb_erase_cached(>node, >queue);
- INIT_LIST_HEAD(>requests);
if (p->priority != I915_PRIORITY_NORMAL)
kmem_cache_free(engine->i915->priorities, p);
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 15345e74d8ce..4ee00f531153 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -259,14 +259,49 @@ intel_lr_context_descriptor_update(struct
i915_gem_context *ctx,
ce->lrc_desc = desc;
}
-static struct i915_priolist *
+static void assert_priolists(struct intel_engine_execlists * const execlists,
+long queue_priority)
+{
+ struct rb_node *rb;
+ long last_prio, i;
+
+ if (!IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
+ return;
+
+ GEM_BUG_ON(rb_first_cached(>queue) !=
+ rb_first(>queue.rb_root));
+
+ last_prio = (queue_priority >> I915_USER_PRIORITY_SHIFT) + 1;
+ for (rb = rb_first_cached(>queue); rb; rb = rb_next(rb)) {
+ struct i915_priolist *p = to_priolist(rb);
+
+ GEM_BUG_ON(p->priority >= last_prio);
+ last_prio = p->priority;
+
+ GEM_BUG_ON(!p->used);
+ for (i = 0; i < ARRAY_SIZE(p->requests); i++) {
+ if (list_empty(>requests[i]))
+ continue;
+
+ GEM_BUG_ON(!(p->used & BIT(i)));
+ }
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix ILK-IVB sprite enable delays
== Series Details == Series: drm/i915: Fix ILK-IVB sprite enable delays URL : https://patchwork.freedesktop.org/series/50328/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4906_full -> Patchwork_10301_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_10301_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10301_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_10301_full: === IGT changes === Possible regressions igt@kms_plane@plane-position-hole-dpms-pipe-a-planes: shard-snb: PASS -> DMESG-WARN +2 Warnings igt@kms_cursor_crc@cursor-128x128-onscreen: shard-snb: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_10301_full that come from known issues: === IGT changes === Issues hit igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_color@pipe-c-ctm-blue-to-red: shard-kbl: DMESG-WARN (fdo#105602, fdo#103558) -> PASS +24 igt@kms_cursor_legacy@cursora-vs-flipa-toggle: shard-glk: DMESG-WARN (fdo#105763, fdo#106538) -> PASS igt@kms_draw_crc@draw-method-xrgb-render-ytiled: shard-glk: FAIL (fdo#103232) -> PASS igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105363) -> PASS igt@kms_plane_multiple@atomic-pipe-a-tiling-x: shard-snb: FAIL (fdo#103166) -> PASS Warnings igt@kms_available_modes_crc@available_mode_test_crc: shard-kbl: DMESG-WARN (fdo#105602, fdo#103558) -> FAIL (fdo#106641) fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166 fdo#103232 https://bugs.freedesktop.org/show_bug.cgi?id=103232 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763 fdo#106538 https://bugs.freedesktop.org/show_bug.cgi?id=106538 fdo#106641 https://bugs.freedesktop.org/show_bug.cgi?id=106641 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (6 -> 5) == Missing(1): shard-skl == Build changes == * Linux: CI_DRM_4906 -> Patchwork_10301 CI_DRM_4906: 187637a6495f71dd240d02badbf2fecc1e3c1bb2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4658: cab89ce2c5da684d01deff402d4e8e11441beadb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10301: 65b3960449ec975dcac4bf2b28efa71bfa5d2802 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10301/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/icl: Add Wa_1406609255
Radhakrishna Sripada writes:
> Shader feature to prefetch binding tables does not support 16:6 18:8 BTP
> formats. Enabling fault handling could result in hangs with faults.
> Disabling demand prefetch would disable binding table prefetch.
>
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> drivers/gpu/drm/i915/intel_workarounds.c | 6 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4b472bc2d26d..117ae5bf647c 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7411,6 +7411,9 @@ enum {
> #define GEN9_SLICE_COMMON_ECO_CHICKEN1 _MMIO(0x731c)
> #define GEN11_STATE_CACHE_REDIRECT_TO_CS (1 << 11)
>
> +#define GEN7_SARCHKMD_MMIO(0xB000)
> +#define GEN7_DISABLE_DEMAND_PREFETCH (1 << 31)
> +
> #define GEN7_L3SQCREG1 _MMIO(0xB010)
> #define VLV_B0_WA_L3SQCREG1_VALUE 0x00D3
>
> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> b/drivers/gpu/drm/i915/intel_workarounds.c
> index 54a63c9b694f..9d5f48b98803 100644
> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> @@ -909,6 +909,12 @@ static void icl_gt_workarounds_apply(struct
> drm_i915_private *dev_priv)
> /* WaEnable32PlaneMode:icl */
> I915_WRITE(GEN9_CSFE_CHICKEN1_RCS,
> _MASKED_BIT_ENABLE(GEN11_ENABLE_32_PLANE_MODE));
> +
> + /* Wa_1406609255:icl (pre-prod) */
> + if (IS_ICL_REVID(dev_priv, ICL_REVID_A0, ICL_REVID_C0))
This is fixed on C0.
-Mika
> + I915_WRITE(GEN7_SARCHKMD,
> +I915_READ(GEN7_SARCHKMD) |
> +GEN7_DISABLE_DEMAND_PREFETCH);
> }
>
> void intel_gt_workarounds_apply(struct drm_i915_private *dev_priv)
> --
> 2.9.3
>
> ___
> 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 1/4] drm/i915/selftests: Split preemption smoke test into threads
On 28/09/2018 14:58, Chris Wilson wrote:
When submitting chains to each engine, we can do so (mostly) in
parallel, so delegate submission to threads on a per-engine basis.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/intel_lrc.c | 73 ++
1 file changed, 61 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/intel_lrc.c
b/drivers/gpu/drm/i915/selftests/intel_lrc.c
index 3a474bb64c05..d68a924c530e 100644
--- a/drivers/gpu/drm/i915/selftests/intel_lrc.c
+++ b/drivers/gpu/drm/i915/selftests/intel_lrc.c
@@ -587,8 +587,10 @@ static int random_priority(struct rnd_state *rnd)
struct preempt_smoke {
struct drm_i915_private *i915;
struct i915_gem_context **contexts;
+ struct intel_engine_cs *engine;
unsigned int ncontext;
struct rnd_state prng;
+ unsigned long count;
};
static struct i915_gem_context *smoke_context(struct preempt_smoke *smoke)
@@ -597,31 +599,78 @@ static struct i915_gem_context *smoke_context(struct
preempt_smoke *smoke)
>prng)];
}
+static int smoke_crescendo_thread(void *arg)
+{
+ struct preempt_smoke *smoke = arg;
+ IGT_TIMEOUT(end_time);
+ unsigned long count;
+
+ count = 0;
+ do {
+ struct i915_gem_context *ctx = smoke_context(smoke);
+ struct i915_request *rq;
+
+ mutex_lock(>i915->drm.struct_mutex);
+
+ ctx->sched.priority = count % I915_PRIORITY_MAX;
+
+ rq = i915_request_alloc(smoke->engine, ctx);
+ if (IS_ERR(rq)) {
+ mutex_unlock(>i915->drm.struct_mutex);
+ return PTR_ERR(rq);
+ }
+
+ i915_request_add(rq);
+
+ mutex_unlock(>i915->drm.struct_mutex);
+
+ count++;
Very little outside the mutex so I am not sure if parallelization will
work that well. Every thread could probably fill the ring in it's
timeslice? And then it blocks the others until there is space. It will
heavily rely on scheduler behaviour and mutex fairness I think.
Regards,
Tvrtko
+ } while (!__igt_timeout(end_time, NULL));
+
+ smoke->count = count;
+ return 0;
+}
+
static int smoke_crescendo(struct preempt_smoke *smoke)
{
+ struct task_struct *tsk[I915_NUM_ENGINES] = {};
+ struct preempt_smoke arg[I915_NUM_ENGINES];
struct intel_engine_cs *engine;
enum intel_engine_id id;
unsigned long count;
+ int err = 0;
+
+ mutex_unlock(>i915->drm.struct_mutex);
- count = 0;
for_each_engine(engine, smoke->i915, id) {
- IGT_TIMEOUT(end_time);
+ arg[id] = *smoke;
+ arg[id].engine = engine;
+ arg[id].count = 0;
+
+ tsk[id] = kthread_run(smoke_crescendo_thread, ,
+ "igt/smoke:%d", id);
+ if (IS_ERR(tsk[id])) {
+ err = PTR_ERR(tsk[id]);
+ break;
+ }
+ }
- do {
- struct i915_gem_context *ctx = smoke_context(smoke);
- struct i915_request *rq;
+ count = 0;
+ for_each_engine(engine, smoke->i915, id) {
+ int status;
- ctx->sched.priority = count % I915_PRIORITY_MAX;
+ if (IS_ERR_OR_NULL(tsk[id]))
+ continue;
- rq = i915_request_alloc(engine, ctx);
- if (IS_ERR(rq))
- return PTR_ERR(rq);
+ status = kthread_stop(tsk[id]);
+ if (status && !err)
+ err = status;
- i915_request_add(rq);
- count++;
- } while (!__igt_timeout(end_time, NULL));
+ count += arg[id].count;
}
+ mutex_lock(>i915->drm.struct_mutex);
+
pr_info("Submitted %lu crescendo requests across %d engines and %d
contexts\n",
count, INTEL_INFO(smoke->i915)->num_rings, smoke->ncontext);
return 0;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 40/40] drm/i915: Load balancing across a virtual engine
On 19/09/2018 20:55, Chris Wilson wrote:
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the set in a manner as best to
distribute load. The virtual engine has a single timeline across all
engines (it operates as a single queue), so it is not able to concurrently
run batches across multiple engines by itself; that is left up to the user
to submit multiple concurrent batches to multiple queues. Multiple users
will be load balanced across the system.
The mechanism used for load balancing in this patch is a late greedy
balancer. When a request is ready for execution, it is added to each
engine's queue, and when an engine is ready for its next request it
claims it from the virtual engine. The first engine to do so, wins, i.e.
the request is executed at the earliest opportunity (idle moment) in the
system.
As not all HW is created equal, the user is still able to skip the
virtual engine and execute the batch on a specific engine, all within the
same queue. It will then be executed in order on the correct engine,
with execution on other virtual engines being moved away due to the load
detection.
I think a few paragraphs describing the implementation are warranted. To
help current and future readers. :)
A couple of areas for potential improvement left!
- The virtual engine always take priority over equal-priority tasks.
Mostly broken up by applying FQ_CODEL rules for prioritising new clients,
and hopefully the virtual and real engines are not then congested (i.e.
all work is via virtual engines, or all work is to the real engine).
- We require the breadcrumb irq around every virtual engine request. For
normal engines, we eliminate the need for the slow round trip via
interrupt by using the submit fence and queueing in order. For virtual
engines, we have to allow any job to transfer to a new ring, and cannot
coalesce the submissions, so require the completion fence instead,
forcing the persistent use of interrupts.
Other areas of improvement are more general, such as reducing lock
contention, reducing dispatch overhead, looking at direct submission
rather than bouncing around tasklets etc.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.h| 5 +
drivers/gpu/drm/i915/i915_gem_context.c| 85 +++-
drivers/gpu/drm/i915/i915_gem_context.h| 1 +
drivers/gpu/drm/i915/i915_request.c| 2 +-
drivers/gpu/drm/i915/i915_scheduler.c | 1 +
drivers/gpu/drm/i915/i915_timeline.h | 1 +
drivers/gpu/drm/i915/intel_engine_cs.c | 48 +-
drivers/gpu/drm/i915/intel_lrc.c | 500 -
drivers/gpu/drm/i915/intel_lrc.h | 16 +-
drivers/gpu/drm/i915/intel_ringbuffer.h| 8 +
drivers/gpu/drm/i915/selftests/intel_lrc.c | 216 +
include/uapi/drm/i915_drm.h| 27 ++
12 files changed, 851 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 599c4f6eb1ea..69d137786700 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -87,4 +87,9 @@ static inline bool __tasklet_is_enabled(const struct
tasklet_struct *t)
return !atomic_read(>count);
}
+static inline bool __tasklet_is_scheduled(struct tasklet_struct *t)
+{
+ return test_bit(TASKLET_STATE_SCHED, >state);
+}
+
#endif /* __I915_GEM_H__ */
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 313471253f51..0ee39772df03 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -91,6 +91,7 @@
#include "i915_drv.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
+#include "intel_lrc.h"
#include "intel_workarounds.h"
#define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
@@ -224,7 +225,10 @@ static void i915_gem_context_free(struct i915_gem_context
*ctx)
ce->ops->destroy(ce);
}
- kfree(ctx->engines);
+ if (ctx->engines) {
+ intel_virtual_engine_put(ctx->engines[0]);
+ kfree(ctx->engines);
+ }
if (ctx->timeline)
i915_timeline_put(ctx->timeline);
@@ -351,6 +355,7 @@ __create_hw_context(struct drm_i915_private *dev_priv,
struct intel_context *ce = >__engine[n];
ce->gem_context = ctx;
+ ce->owner = dev_priv->engine[n];
So owner is actually the engine backpointer AFAICT, it doesn't change as
the context moves around? Call it engine in that case?
}
INIT_RADIX_TREE(>handles_vma, GFP_KERNEL);
@@ -679,7 +684,8 @@ last_request_on_engine(struct i915_timeline *timeline,
rq = i915_gem_active_raw(>last_request,
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] drm/i915/selftests: Split preemption smoke test into threads (rev2)
Quoting Patchwork (2018-10-01 12:25:25) > == Series Details == > > Series: series starting with [1/4] drm/i915/selftests: Split preemption smoke > test into threads (rev2) > URL : https://patchwork.freedesktop.org/series/50329/ > State : failure > > == Summary == > > = CI Bug Log - changes from CI_DRM_4906 -> Patchwork_10302 = > > == Summary - FAILURE == > > Serious unknown changes coming with Patchwork_10302 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_10302, 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/50329/revisions/2/mbox/ > > == Possible new issues == > > Here are the unknown changes that may have been introduced in > Patchwork_10302: > > === IGT changes === > > Possible regressions > > igt@gem_close_race@basic-process: > fi-skl-6700k2: PASS -> INCOMPLETE Ah, my assert is broken with I915_USER_PRIORITY_SHIFT == 0. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/selftests: Include arbitration points in preemption smoketest
Include a batch full of a page of arbitration points in order to provide
a window for inject_preempt_context() in the preemption smoketests.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/intel_lrc.c | 134 -
1 file changed, 101 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/intel_lrc.c
b/drivers/gpu/drm/i915/selftests/intel_lrc.c
index d68a924c530e..d67fe8335ceb 100644
--- a/drivers/gpu/drm/i915/selftests/intel_lrc.c
+++ b/drivers/gpu/drm/i915/selftests/intel_lrc.c
@@ -588,6 +588,7 @@ struct preempt_smoke {
struct drm_i915_private *i915;
struct i915_gem_context **contexts;
struct intel_engine_cs *engine;
+ struct drm_i915_gem_object *batch;
unsigned int ncontext;
struct rnd_state prng;
unsigned long count;
@@ -599,6 +600,49 @@ static struct i915_gem_context *smoke_context(struct
preempt_smoke *smoke)
>prng)];
}
+static int smoke_submit(struct preempt_smoke *smoke,
+ struct i915_gem_context *ctx, int prio,
+ struct drm_i915_gem_object *batch)
+{
+ struct i915_request *rq;
+ struct i915_vma *vma = NULL;
+ int err = 0;
+
+ if (batch) {
+ vma = i915_vma_instance(batch, >ppgtt->vm, NULL);
+ if (IS_ERR(vma))
+ return PTR_ERR(vma);
+
+ err = i915_vma_pin(vma, 0, 0, PIN_USER);
+ if (err)
+ return err;
+ }
+
+ ctx->sched.priority = prio;
+
+ rq = i915_request_alloc(smoke->engine, ctx);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto unpin;
+ }
+
+ if (vma) {
+ err = rq->engine->emit_bb_start(rq,
+ vma->node.start,
+ PAGE_SIZE, 0);
+ if (!err)
+ err = i915_vma_move_to_active(vma, rq, 0);
+ }
+
+ i915_request_add(rq);
+
+unpin:
+ if (vma)
+ i915_vma_unpin(vma);
+
+ return err;
+}
+
static int smoke_crescendo_thread(void *arg)
{
struct preempt_smoke *smoke = arg;
@@ -608,21 +652,15 @@ static int smoke_crescendo_thread(void *arg)
count = 0;
do {
struct i915_gem_context *ctx = smoke_context(smoke);
- struct i915_request *rq;
+ int err;
mutex_lock(>i915->drm.struct_mutex);
-
- ctx->sched.priority = count % I915_PRIORITY_MAX;
-
- rq = i915_request_alloc(smoke->engine, ctx);
- if (IS_ERR(rq)) {
- mutex_unlock(>i915->drm.struct_mutex);
- return PTR_ERR(rq);
- }
-
- i915_request_add(rq);
-
+ err = smoke_submit(smoke,
+ ctx, count % I915_PRIORITY_MAX,
+ smoke->batch);
mutex_unlock(>i915->drm.struct_mutex);
+ if (err)
+ return err;
count++;
} while (!__igt_timeout(end_time, NULL));
@@ -631,7 +669,8 @@ static int smoke_crescendo_thread(void *arg)
return 0;
}
-static int smoke_crescendo(struct preempt_smoke *smoke)
+static int smoke_crescendo(struct preempt_smoke *smoke, unsigned int flags)
+#define BATCH BIT(0)
{
struct task_struct *tsk[I915_NUM_ENGINES] = {};
struct preempt_smoke arg[I915_NUM_ENGINES];
@@ -645,6 +684,8 @@ static int smoke_crescendo(struct preempt_smoke *smoke)
for_each_engine(engine, smoke->i915, id) {
arg[id] = *smoke;
arg[id].engine = engine;
+ if (!(flags & BATCH))
+ arg[id].batch = NULL;
arg[id].count = 0;
tsk[id] = kthread_run(smoke_crescendo_thread, ,
@@ -671,37 +712,37 @@ static int smoke_crescendo(struct preempt_smoke *smoke)
mutex_lock(>i915->drm.struct_mutex);
- pr_info("Submitted %lu crescendo requests across %d engines and %d
contexts\n",
- count, INTEL_INFO(smoke->i915)->num_rings, smoke->ncontext);
+ pr_info("Submitted %lu crescendo:%x requests across %d engines and %d
contexts\n",
+ count, flags,
+ INTEL_INFO(smoke->i915)->num_rings, smoke->ncontext);
return 0;
}
-static int smoke_random(struct preempt_smoke *smoke)
+static int smoke_random(struct preempt_smoke *smoke, unsigned int flags)
{
- struct intel_engine_cs *engine;
enum intel_engine_id id;
IGT_TIMEOUT(end_time);
unsigned long count;
count = 0;
do {
- for_each_engine(engine, smoke->i915, id) {
+ for_each_engine(smoke->engine, smoke->i915, id) {
struct i915_gem_context *ctx =
Re: [Intel-gfx] [PATCH 39/40] drm/i915/execlists: Refactor out can_merge_rq()
On 01/10/2018 09:18, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-10-01 09:14:52)
On 28/09/2018 21:11, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-09-27 12:32:54)
On 19/09/2018 20:55, Chris Wilson wrote:
In the next patch, we add another user that wants to check whether
requests can be merge into a single HW execution, and in the future we
want to add more conditions under which requests from the same context
cannot be merge. In preparation, extract out can_merge_rq().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index be7dbdd7fc2c..679ce521be16 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -478,6 +478,15 @@ static bool can_merge_ctx(const struct intel_context *prev,
return true;
}
+static bool can_merge_rq(const struct i915_request *prev,
+ const struct i915_request *next)
+{
+ if (!can_merge_ctx(prev->hw_context, next->hw_context))
+ return false;
+
+ return true;
Not just return can_merge_ctx(..) ?
Makes you think I have plans to add more tests here... If you look in
the archives you can even have a seek peek ;)
I don't see anything in Virtual Engine / Frame Split work, where to look?
Per-context frequency control to allow the rps range to change between
requests.
Who knows when will that be at the head of the queue but OK, it's a
style issue only so:
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915/icl: WaSendPushConstantsFromMMIO
Chris Wilson writes: > Quoting Radhakrishna Sripada (2018-09-28 17:47:35) >> From: Oscar Mateo >> >> Allows UMDs to set 'Disable Gather at Set Shader Common Slice'. > > Question for reviewers is what other bits are exposed here? And we would also need to have a mesa/umd side commit/ack to demonstrate that this is desired and really needed. -Mika > -Chris > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix ILK-IVB sprite enable delays
== Series Details == Series: drm/i915: Fix ILK-IVB sprite enable delays URL : https://patchwork.freedesktop.org/series/50328/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4906 -> Patchwork_10301 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/50328/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10301 that come from known issues: === IGT changes === Issues hit igt@drv_getparams_basic@basic-subslice-total: fi-snb-2520m: NOTRUN -> DMESG-WARN (fdo#103713) +10 igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: PASS -> DMESG-WARN (fdo#105128, fdo#107139) igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-byt-clapper: PASS -> FAIL (fdo#103191, fdo#107362) igt@prime_vgem@basic-fence-flip: fi-ilk-650: PASS -> FAIL (fdo#104008) Possible fixes igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-byt-clapper: FAIL (fdo#103191, fdo#107362) -> PASS fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 == Participating hosts (50 -> 45) == Additional (1): fi-snb-2520m Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-icl-u2 fi-ctg-p8600 == Build changes == * Linux: CI_DRM_4906 -> Patchwork_10301 CI_DRM_4906: 187637a6495f71dd240d02badbf2fecc1e3c1bb2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4658: cab89ce2c5da684d01deff402d4e8e11441beadb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10301: 65b3960449ec975dcac4bf2b28efa71bfa5d2802 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 65b3960449ec drm/i915: Fix ILK-IVB sprite enable delays == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10301/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915/selftests: Split preemption smoke test into threads
Quoting Tvrtko Ursulin (2018-10-01 11:38:37)
>
> On 28/09/2018 14:58, Chris Wilson wrote:
> > When submitting chains to each engine, we can do so (mostly) in
> > parallel, so delegate submission to threads on a per-engine basis.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/selftests/intel_lrc.c | 73 ++
> > 1 file changed, 61 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/selftests/intel_lrc.c
> > b/drivers/gpu/drm/i915/selftests/intel_lrc.c
> > index 3a474bb64c05..d68a924c530e 100644
> > --- a/drivers/gpu/drm/i915/selftests/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/selftests/intel_lrc.c
> > @@ -587,8 +587,10 @@ static int random_priority(struct rnd_state *rnd)
> > struct preempt_smoke {
> > struct drm_i915_private *i915;
> > struct i915_gem_context **contexts;
> > + struct intel_engine_cs *engine;
> > unsigned int ncontext;
> > struct rnd_state prng;
> > + unsigned long count;
> > };
> >
> > static struct i915_gem_context *smoke_context(struct preempt_smoke *smoke)
> > @@ -597,31 +599,78 @@ static struct i915_gem_context *smoke_context(struct
> > preempt_smoke *smoke)
> > >prng)];
> > }
> >
> > +static int smoke_crescendo_thread(void *arg)
> > +{
> > + struct preempt_smoke *smoke = arg;
> > + IGT_TIMEOUT(end_time);
> > + unsigned long count;
> > +
> > + count = 0;
> > + do {
> > + struct i915_gem_context *ctx = smoke_context(smoke);
> > + struct i915_request *rq;
> > +
> > + mutex_lock(>i915->drm.struct_mutex);
> > +
> > + ctx->sched.priority = count % I915_PRIORITY_MAX;
> > +
> > + rq = i915_request_alloc(smoke->engine, ctx);
> > + if (IS_ERR(rq)) {
> > + mutex_unlock(>i915->drm.struct_mutex);
> > + return PTR_ERR(rq);
> > + }
> > +
> > + i915_request_add(rq);
> > +
> > + mutex_unlock(>i915->drm.struct_mutex);
> > +
> > + count++;
>
> Very little outside the mutex so I am not sure if parallelization will
> work that well. Every thread could probably fill the ring in it's
> timeslice?
Very unlikely due to the randomised ring. And we are working on that,
right? :)
> And then it blocks the others until there is space. It will
> heavily rely on scheduler behaviour and mutex fairness I think.
But it does bring the overall subtest time from num_engines to 1s, for
the same pattern.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/icl: Add Wa_1406609255
Radhakrishna Sripada writes:
> Shader feature to prefetch binding tables does not support 16:6 18:8 BTP
> formats.
s/formats./,causing lower performance if used. And with fault
handling enabled can cause gpu hangs.
> Disabling demand prefetch would disable binding table prefetch.
>
Also please add:
References: HSDES#1406609255, HSDES#1406573985
And as mentioned earlied, this is fixed on C0 so limit
range to ICL_REVID_B0.
Thanks,
-Mika
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> drivers/gpu/drm/i915/intel_workarounds.c | 6 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4b472bc2d26d..117ae5bf647c 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7411,6 +7411,9 @@ enum {
> #define GEN9_SLICE_COMMON_ECO_CHICKEN1 _MMIO(0x731c)
> #define GEN11_STATE_CACHE_REDIRECT_TO_CS (1 << 11)
>
> +#define GEN7_SARCHKMD_MMIO(0xB000)
> +#define GEN7_DISABLE_DEMAND_PREFETCH (1 << 31)
> +
> #define GEN7_L3SQCREG1 _MMIO(0xB010)
> #define VLV_B0_WA_L3SQCREG1_VALUE 0x00D3
>
> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> b/drivers/gpu/drm/i915/intel_workarounds.c
> index 54a63c9b694f..9d5f48b98803 100644
> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> @@ -909,6 +909,12 @@ static void icl_gt_workarounds_apply(struct
> drm_i915_private *dev_priv)
> /* WaEnable32PlaneMode:icl */
> I915_WRITE(GEN9_CSFE_CHICKEN1_RCS,
> _MASKED_BIT_ENABLE(GEN11_ENABLE_32_PLANE_MODE));
> +
> + /* Wa_1406609255:icl (pre-prod) */
> + if (IS_ICL_REVID(dev_priv, ICL_REVID_A0, ICL_REVID_C0))
> + I915_WRITE(GEN7_SARCHKMD,
> +I915_READ(GEN7_SARCHKMD) |
> +GEN7_DISABLE_DEMAND_PREFETCH);
> }
>
> void intel_gt_workarounds_apply(struct drm_i915_private *dev_priv)
> --
> 2.9.3
>
> ___
> 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 6/6] drm/i915/icl: Support co-existence between per-context SSEU and OA
On 01/10/2018 12:20, Tvrtko Ursulin wrote:
On 01/10/2018 10:50, Lionel Landwerlin wrote:
On 17/09/2018 13:30, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
When OA is active we want to lock the powergating configuration, but on
Icelake, users like the media stack will have issues if we lock to the
full device configuration.
Instead lock to a subset of (sub)slices which are currently a known
working configuration for all users.
v2:
* Fix commit message spelling.
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
---
drivers/gpu/drm/i915/intel_lrc.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index b5603e977a3f..cded1f1d9ec2 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2521,13 +2521,28 @@ u32 gen8_make_rpcs(struct drm_i915_private
*i915, struct intel_sseu *req_sseu)
/*
* If i915/perf is active, we want a stable powergating
configuration
- * on the system. The most natural configuration to take in
that case
- * is the default (i.e maximum the hardware can do).
+ * on the system.
+ *
+ * We could choose full enablement, but on ICL we know there
are use
+ * cases which disable slices for functional, apart for
performance
+ * reasons. So in this case we select a known stable subset.
*/
- if (unlikely(i915->perf.oa.exclusive_stream))
- ctx_sseu = intel_device_default_sseu(i915);
- else
+ if (!i915->perf.oa.exclusive_stream) {
ctx_sseu = *req_sseu;
+ } else {
+ ctx_sseu = intel_device_default_sseu(i915);
+
+ if (IS_GEN11(i915)) {
+ /*
+ * We only need subslice count so it doesn't matter
+ * which ones we select - just turn of low bits in the
s/turn of/turn off/
Yep, thanks.
+ * amount of half of all available subslices per slice.
+ */
+ ctx_sseu.subslice_mask =
+ ~(~0 << (hweight8(ctx_sseu.subslice_mask) / 2));
I would go with :
ctx_sseu.subslice_mask = ctx_sseu.subslice_mask & 0xf;
Documentation says that the first 4 subslices are the "big" ones
(gathered from the fusing register fields which go from
slice0-subslice[0-3] then slice1-subslice[0-3], etc...), so this
should be equally media/3d capable.
Doesn't work I think - one 1x6x8 part I've seen has a subslice mask of
0b1100 and there we want to have three subslices enabled.
Regards,
Tvrtko
Thanks, then the fusing fields don't match for a big/small sets of
subslices.
I guess the fusing might be in this pattern (Small/Big) : SBSBSBSB
I was hoping we could know so that we program the powergating at the
most capable configuration.
-
Lionel
+ ctx_sseu.slice_mask = 0x1;
+ }
+ }
slices = hweight8(ctx_sseu.slice_mask);
subslices = hweight8(ctx_sseu.subslice_mask);
___
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 38/40] drm/i915/execlists: Flush the CS events before unpinning
Quoting Tvrtko Ursulin (2018-10-01 11:51:23)
>
> On 19/09/2018 20:55, Chris Wilson wrote:
> > Inside the execlists submission tasklet, we often make the mistake of
> > assuming that everything beneath the request is available for use.
> > However, the submission and the request live on two separate timelines,
> > and the request contents may be freed from an early retirement before we
> > have had a chance to run the submission tasklet (think ksoftirqd). To
> > safeguard ourselves against any mistakes, flush the tasklet before we
> > unpin the context if execlists still has a reference to this context.
> >
> > References: 60367132a214 ("drm/i915: Avoid use-after-free of ctx in request
> > tracepoints")
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/i915_gem_context.h | 1 +
> > drivers/gpu/drm/i915/intel_lrc.c| 32 -
> > 2 files changed, 32 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
> > b/drivers/gpu/drm/i915/i915_gem_context.h
> > index 9f89119a6566..1fd71dfdfa62 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.h
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.h
> > @@ -170,6 +170,7 @@ struct i915_gem_context {
> > /** engine: per-engine logical HW state */
> > struct intel_context {
> > struct i915_gem_context *gem_context;
> > + struct intel_engine_cs *active;
> > struct i915_vma *state;
> > struct intel_ring *ring;
> > u32 *lrc_reg_state;
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 48a2bca7fec3..be7dbdd7fc2c 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -282,6 +282,8 @@ static void __unwind_incomplete_requests(struct
> > intel_engine_cs *engine)
> > __i915_request_unsubmit(rq);
> > unwind_wa_tail(rq);
> >
> > + GEM_BUG_ON(rq->hw_context->active);
> > +
> > GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID);
> > if (rq_prio(rq) != prio) {
> > prio = rq_prio(rq);
> > @@ -427,8 +429,11 @@ static void execlists_submit_ports(struct
> > intel_engine_cs *engine)
> > rq = port_unpack([n], );
> > if (rq) {
> > GEM_BUG_ON(count > !n);
> > - if (!count++)
> > + if (!count++) {
> > + GEM_BUG_ON(rq->hw_context->active);
> > execlists_context_schedule_in(rq);
> > + rq->hw_context->active = engine;
>
> Put it in execlists_context_schedule_in/out?
>
> Why does it have to be the engine pointer and not just a boolean?
> Because we don't have an engine backpointer in hw_context? Should we add
> it? I think I had occasionally wished we had it.. maybe too much work to
> evaluate what function prototypes we could clean up with it and whether
> it would be an overall gain.
It's a backpointer in hw_context for the purposes of being a backpointer
in hw_context. Its purpose is for:
active = READ_ONCE(ve->context.active);
if (active && active != engine) {
rb = rb_next(rb);
continue;
}
> > + }
> > port_set([n], port_pack(rq, count));
> > desc = execlists_update_context(rq);
> > GEM_DEBUG_EXEC(port[n].context_id =
> > upper_32_bits(desc));
> > @@ -734,6 +739,8 @@ execlists_cancel_port_requests(struct
> > intel_engine_execlists * const execlists)
> > intel_engine_get_seqno(rq->engine));
> >
> > GEM_BUG_ON(!execlists->active);
> > +
> > + rq->hw_context->active = NULL;
> > execlists_context_schedule_out(rq,
> > i915_request_completed(rq) ?
> > INTEL_CONTEXT_SCHEDULE_OUT :
> > @@ -971,6 +978,7 @@ static void process_csb(struct intel_engine_cs *engine)
> >*/
> > GEM_BUG_ON(!i915_request_completed(rq));
> >
> > + rq->hw_context->active = NULL;
> > execlists_context_schedule_out(rq,
> >
> > INTEL_CONTEXT_SCHEDULE_OUT);
> > i915_request_put(rq);
> > @@ -1080,6 +1088,28 @@ static void execlists_context_destroy(struct
> > intel_context *ce)
> >
> > static void execlists_context_unpin(struct intel_context *ce)
> > {
> > + struct intel_engine_cs *engine;
> > +
> > + /*
> > + * The tasklet may still be using a pointer to our state, via an
> > + * old request. However, since we know we only unpin the context
> > + * on retirement of the following request, we
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] drm/i915/selftests: Split preemption smoke test into threads (rev2)
== Series Details == Series: series starting with [1/4] drm/i915/selftests: Split preemption smoke test into threads (rev2) URL : https://patchwork.freedesktop.org/series/50329/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4906 -> Patchwork_10302 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_10302 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10302, 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/50329/revisions/2/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_10302: === IGT changes === Possible regressions igt@gem_close_race@basic-process: fi-skl-6700k2: PASS -> INCOMPLETE fi-skl-6700hq: PASS -> INCOMPLETE fi-kbl-7560u: PASS -> INCOMPLETE fi-kbl-8809g: PASS -> INCOMPLETE fi-bsw-kefka: PASS -> INCOMPLETE fi-kbl-7567u: PASS -> INCOMPLETE fi-icl-u: PASS -> INCOMPLETE igt@gem_close_race@basic-threads: fi-skl-6600u: PASS -> INCOMPLETE fi-whl-u: PASS -> INCOMPLETE fi-cnl-u: PASS -> INCOMPLETE fi-kbl-7500u: PASS -> INCOMPLETE fi-cfl-8109u: PASS -> INCOMPLETE fi-kbl-r: PASS -> INCOMPLETE fi-skl-6260u: PASS -> INCOMPLETE fi-skl-6770hq: PASS -> INCOMPLETE fi-kbl-x1275: PASS -> INCOMPLETE fi-cfl-s3: PASS -> INCOMPLETE fi-skl-iommu: PASS -> INCOMPLETE fi-cfl-8700k: PASS -> INCOMPLETE igt@gem_ctx_switch@basic-default: fi-bdw-samus: PASS -> INCOMPLETE fi-bsw-n3050: PASS -> INCOMPLETE fi-bdw-5557u: PASS -> INCOMPLETE igt@gem_ctx_switch@basic-default-heavy: fi-kbl-soraka: PASS -> INCOMPLETE fi-skl-caroline:NOTRUN -> INCOMPLETE == Known issues == Here are the changes found in Patchwork_10302 that come from known issues: === IGT changes === Issues hit igt@gem_close_race@basic-process: fi-glk-j4005: PASS -> INCOMPLETE (fdo#103359, k.org#198133) fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) fi-bxt-j4205: PASS -> INCOMPLETE (fdo#103927) fi-kbl-guc: PASS -> INCOMPLETE (fdo#106693) fi-glk-dsi: PASS -> INCOMPLETE (fdo#103359, k.org#198133) fi-cfl-guc: PASS -> INCOMPLETE (fdo#106693) igt@gem_close_race@basic-threads: fi-skl-guc: PASS -> INCOMPLETE (fdo#106693) fi-skl-gvtdvm: PASS -> INCOMPLETE (fdo#105600) igt@gem_ctx_switch@basic-default-heavy: fi-bdw-gvtdvm: PASS -> INCOMPLETE (fdo#105600) igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: PASS -> DMESG-WARN (fdo#102614) igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a: fi-byt-clapper: PASS -> FAIL (fdo#107362) Possible fixes igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: 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#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105600 https://bugs.freedesktop.org/show_bug.cgi?id=105600 fdo#106693 https://bugs.freedesktop.org/show_bug.cgi?id=106693 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (50 -> 46) == Additional (1): fi-skl-caroline Missing(5): fi-ctg-p8600 fi-bsw-cyan fi-ilk-m540 fi-byt-squawks fi-icl-u2 == Build changes == * Linux: CI_DRM_4906 -> Patchwork_10302 CI_DRM_4906: 187637a6495f71dd240d02badbf2fecc1e3c1bb2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4658: cab89ce2c5da684d01deff402d4e8e11441beadb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10302: 05453e08600332f053e0a1cf63250f70cc70f1a9 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 05453e086003 drm/i915: Combine multiple internal plists into the same i915_priolist bucket 8a4361322e2b drm/i915: Reserve some priority bits for internal use 27ea74d97340 drm/i915/selftests: Include arbitration points in preemption smoketest 949446d4ae2f drm/i915/selftests: Split preemption smoke test into threads == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10302/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915/selftests: Split preemption smoke test into threads
== Series Details == Series: series starting with [1/4] drm/i915/selftests: Split preemption smoke test into threads URL : https://patchwork.freedesktop.org/series/50389/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7cbb475e40b4 drm/i915/selftests: Split preemption smoke test into threads -:33: WARNING:LINE_SPACING: Missing a blank line after declarations #33: FILE: drivers/gpu/drm/i915/selftests/intel_lrc.c:605: + struct preempt_smoke *smoke = arg; + IGT_TIMEOUT(end_time); total: 0 errors, 1 warnings, 0 checks, 100 lines checked e3babdb4224b drm/i915/selftests: Include arbitration points in preemption smoketest a4e4f339f7f9 drm/i915: Reserve some priority bits for internal use f6db93f476e4 drm/i915: Combine multiple internal plists into the same i915_priolist bucket -:168: WARNING:FUNCTION_ARGUMENTS: function definition argument 'pl' should also have an identifier name #168: FILE: drivers/gpu/drm/i915/intel_lrc.c:367: + struct list_head *uninitialized_var(pl); -:286: WARNING:FUNCTION_ARGUMENTS: function definition argument 'pl' should also have an identifier name #286: FILE: drivers/gpu/drm/i915/intel_lrc.c:1179: + struct list_head *uninitialized_var(pl); -:315: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'plist' - possible side-effects? #315: FILE: drivers/gpu/drm/i915/intel_ringbuffer.h:199: +#define priolist_for_each_request(it, plist, idx) \ + for (idx = 0; idx < ARRAY_SIZE((plist)->requests); idx++) \ + list_for_each_entry(it, &(plist)->requests[idx], sched.link) -:315: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'idx' - possible side-effects? #315: FILE: drivers/gpu/drm/i915/intel_ringbuffer.h:199: +#define priolist_for_each_request(it, plist, idx) \ + for (idx = 0; idx < ARRAY_SIZE((plist)->requests); idx++) \ + list_for_each_entry(it, &(plist)->requests[idx], sched.link) -:319: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'plist' - possible side-effects? #319: FILE: drivers/gpu/drm/i915/intel_ringbuffer.h:203: +#define priolist_for_each_request_consume(it, n, plist, idx) \ + for (; (idx = ffs((plist)->used)); (plist)->used &= ~BIT(idx - 1)) \ + list_for_each_entry_safe(it, n, \ +&(plist)->requests[idx - 1], \ +sched.link) -:319: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'idx' - possible side-effects? #319: FILE: drivers/gpu/drm/i915/intel_ringbuffer.h:203: +#define priolist_for_each_request_consume(it, n, plist, idx) \ + for (; (idx = ffs((plist)->used)); (plist)->used &= ~BIT(idx - 1)) \ + list_for_each_entry_safe(it, n, \ +&(plist)->requests[idx - 1], \ +sched.link) total: 0 errors, 2 warnings, 4 checks, 272 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: fix wrong error number report
During driver load it's considered that the i915_driver_create()
function fails only in case of insufficient memory. Indeed, in
case of failure of i915_driver_create(), the load function
returns indiscriminately -ENOMEM ignoring the real cause of
failure.
In i915_driver_create() get the consistent error value from
drm_dev_init() and embed it in the pointer return value.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_drv.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1b028f429e92..d1f65d57f4df 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1627,14 +1627,16 @@ i915_driver_create(struct pci_dev *pdev, const struct
pci_device_id *ent)
(struct intel_device_info *)ent->driver_data;
struct intel_device_info *device_info;
struct drm_i915_private *i915;
+ int err;
i915 = kzalloc(sizeof(*i915), GFP_KERNEL);
if (!i915)
return NULL;
- if (drm_dev_init(>drm, , >dev)) {
+ err = drm_dev_init(>drm, , >dev);
+ if (err) {
kfree(i915);
- return NULL;
+ return ERR_PTR(err);
}
i915->drm.pdev = pdev;
@@ -1683,8 +1685,8 @@ int i915_driver_load(struct pci_dev *pdev, const struct
pci_device_id *ent)
int ret;
dev_priv = i915_driver_create(pdev, ent);
- if (!dev_priv)
- return -ENOMEM;
+ if (IS_ERR(dev_priv))
+ return PTR_ERR(dev_priv);
/* Disable nuclear pageflip by default on pre-ILK */
if (!i915_modparams.nuclear_pageflip && match_info->gen < 5)
--
2.19.0
___
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: Engine discovery query (rev3)
== Series Details == Series: drm/i915: Engine discovery query (rev3) URL : https://patchwork.freedesktop.org/series/39958/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4908 -> Patchwork_10310 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/39958/revisions/3/mbox/ == Known issues == Here are the changes found in Patchwork_10310 that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_hangcheck: fi-skl-guc: PASS -> DMESG-FAIL (fdo#106685) igt@gem_exec_suspend@basic-s3: fi-bdw-samus: PASS -> INCOMPLETE (fdo#107773) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-blb-e6850: NOTRUN -> INCOMPLETE (fdo#107718) Possible fixes igt@gem_exec_suspend@basic-s3: fi-cfl-8109u: DMESG-WARN (fdo#107345) -> PASS +3 igt@gem_exec_suspend@basic-s4-devices: fi-blb-e6850: INCOMPLETE (fdo#107718) -> PASS igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a: fi-byt-clapper: FAIL (fdo#107362) -> PASS fdo#106685 https://bugs.freedesktop.org/show_bug.cgi?id=106685 fdo#107345 https://bugs.freedesktop.org/show_bug.cgi?id=107345 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773 == Participating hosts (53 -> 47) == Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-u2 fi-ctg-p8600 == Build changes == * Linux: CI_DRM_4908 -> Patchwork_10310 CI_DRM_4908: d287e1ba5382518eb1ce7cac144f428c1522b8a1 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4658: cab89ce2c5da684d01deff402d4e8e11441beadb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10310: 9c2c6952bb563c07750379f55c1ea11646506674 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 9c2c6952bb56 drm/i915: Engine discovery query == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10310/issues.html ___ 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: fix wrong error number report
== Series Details == Series: drm/i915: fix wrong error number report URL : https://patchwork.freedesktop.org/series/50406/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4908 -> Patchwork_10311 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/50406/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10311 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s3: fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718) igt@kms_frontbuffer_tracking@basic: fi-byt-clapper: PASS -> FAIL (fdo#103167) igt@kms_pipe_crc_basic@hang-read-crc-pipe-b: fi-byt-clapper: PASS -> FAIL (fdo#107362, fdo#103191) Possible fixes igt@gem_exec_suspend@basic-s3: fi-cfl-8109u: DMESG-WARN (fdo#107345) -> PASS +3 igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a: fi-byt-clapper: FAIL (fdo#107362) -> PASS fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#107345 https://bugs.freedesktop.org/show_bug.cgi?id=107345 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 == Participating hosts (53 -> 45) == Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-icl-u2 fi-bsw-cyan fi-snb-2520m fi-ctg-p8600 fi-pnv-d510 == Build changes == * Linux: CI_DRM_4908 -> Patchwork_10311 CI_DRM_4908: d287e1ba5382518eb1ce7cac144f428c1522b8a1 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4658: cab89ce2c5da684d01deff402d4e8e11441beadb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10311: 67933e3071d5718711b8188ca94a0120652955bb @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 67933e3071d5 drm/i915: fix wrong error number report == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10311/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Engine discovery query
On 01/10/2018 17:24, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-10-01 17:15:24)
From: Tvrtko Ursulin
Engine discovery query allows userspace to enumerate engines, probe their
configuration features, all without needing to maintain the internal PCI
ID based database.
A new query for the generic i915 query ioctl is added named
DRM_I915_QUERY_ENGINE_INFO, together with accompanying structure
drm_i915_query_engine_info. The address of latter should be passed to the
kernel in the query.data_ptr field, and should be large enough for the
kernel to fill out all known engines as struct drm_i915_engine_info
elements trailing the query.
As with other queries, setting the item query length to zero allows
userspace to query minimum required buffer size.
Enumerated engines have common type mask which can be used to query all
hardware engines, versus engines userspace can submit to using the execbuf
uAPI.
Engines also have capabilities which are per engine class namespace of
bits describing features not present on all engine instances.
v2:
* Fixed HEVC assignment.
* Reorder some fields, rename type to flags, increase width. (Lionel)
* No need to allocate temporary storage if we do it engine by engine.
(Lionel)
v3:
* Describe engine flags and mark mbz fields. (Lionel)
* HEVC only applies to VCS.
v4:
* Squash SFC flag into main patch.
* Tidy some comments.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Jon Bloomfield
Cc: Dmitry Rogozhkin
Cc: Lionel Landwerlin
Cc: Joonas Lahtinen
Cc: Tony Ye
---
drivers/gpu/drm/i915/i915_query.c | 63 +
drivers/gpu/drm/i915/intel_engine_cs.c | 9
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 ++
include/uapi/drm/i915_drm.h | 54 +
4 files changed, 129 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 5821002cad42..294f8195efa7 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -84,9 +84,72 @@ static int query_topology_info(struct drm_i915_private
*dev_priv,
return total_length;
}
+static int
+query_engine_info(struct drm_i915_private *i915,
+ struct drm_i915_query_item *query_item)
+{
+ struct drm_i915_query_engine_info __user *query_ptr =
+ u64_to_user_ptr(query_item->data_ptr);
+ struct drm_i915_engine_info __user *info_ptr = _ptr->engines[0];
+ struct drm_i915_query_engine_info query;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ int len;
+
+ if (query_item->flags)
+ return -EINVAL;
+
+ len = sizeof(struct drm_i915_query_engine_info) +
+ I915_NUM_ENGINES * sizeof(struct drm_i915_engine_info);
Since I915_NUM_ENGINES is not ABI, and this will be using a 2-step
query (1st to find length, 2nd to grab details), it should work with
info->num_rings. If not, we have problems later ;)
I don't follow, what do you plan to enumerate that would cause a problem?
+
+ if (!query_item->length)
+ return len;
+ else if (query_item->length < len)
+ return -EINVAL;
+
+ if (copy_from_user(, query_ptr, sizeof(query)))
+ return -EFAULT;
+
+ if (query.num_engines || query.rsvd[0] || query.rsvd[1] ||
+ query.rsvd[2])
+ return -EINVAL;
+
+ if (!access_ok(VERIFY_WRITE, query_ptr, query_item->length))
+ return -EFAULT;
+
+ for_each_engine(engine, i915, id) {
+ struct drm_i915_engine_info info;
+
+ if (__copy_from_user(, info_ptr, sizeof(info)))
+ return -EFAULT;
+
+ if (info.flags || info.class || info.instance ||
+ info.capabilities || info.rsvd0 || info.rsvd1[0] ||
+ info.rsvd1[1])
+ return -EINVAL;
+
+ info.class = engine->uabi_class;
+ info.instance = engine->instance;
+ info.flags = I915_ENGINE_FLAG_PHYSICAL | I915_ENGINE_FLAG_ABI;
+ info.capabilities = engine->capabilities;
+
+ if (__copy_to_user(info_ptr, , sizeof(info)))
+ return -EFAULT;
+
+ query.num_engines++;
+ info_ptr++;
+ }
+
+ if (__copy_to_user(query_ptr, , sizeof(query)))
+ return -EFAULT;
+
+ return len;
+}
+
static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
struct drm_i915_query_item
*query_item) = {
query_topology_info,
+ query_engine_info,
};
int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 1c6143bdf5a4..97b4acf8af5c 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++
Re: [Intel-gfx] linux-firmware pull request(ICL:DMC)
>-Original Message- >From: Josh Boyer [mailto:jwbo...@kernel.org] >Sent: Monday, October 1, 2018 6:55 AM >To: Srivatsa, Anusha >Cc: Intel Graphics Development ; Kyle McMartin >; Ben Hutchings >Subject: Re: linux-firmware pull request(ICL:DMC) > >On Wed, Sep 26, 2018 at 3:11 PM Srivatsa, Anusha >wrote: >> >> Josh , >> Apologies about the previous one. >> Sending a new PR: >> >> The following changes since commit >44d4fca9922a252a0bd81f6307bcc072a78da54a: >> >> Merge https://github.com/pmachata/linux-firmware (2018-09-13 >> 11:45:40 -0400) >> >> are available in the git repository at: >> >> >> git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware. >> git ICL_DMC > >Guessing you meant >git://anongit.freedesktop.org/git/drm/drm-firmware.git/ ICL_DMC. > >I've pulled and pushed that out. Thanks for the cleanup. Thanks a lot Josh :) Anusha >josh ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/18] drm/i915/sdvo: Read out HDMI infoframes
On Mon, Oct 01, 2018 at 04:35:50PM +0300, Ville Syrjälä wrote: > On Mon, Oct 01, 2018 at 08:59:41AM +0200, Daniel Vetter wrote: > > On Mon, Sep 24, 2018 at 08:13:08PM +0300, Ville Syrjälä wrote: > > > On Mon, Sep 24, 2018 at 06:10:14PM +0200, Daniel Vetter wrote: > > > > On Thu, Sep 20, 2018 at 09:51:43PM +0300, Ville Syrjala wrote: > > > > > From: Ville Syrjälä > > > > > > > > > > Read the HDMI infoframes from the hbuf and unpack them into > > > > > the crtc state. > > > > > > > > > > Well, actually just AVI infoframe for now but let's write the > > > > > infoframe readout code in a more generic fashion in case we > > > > > expand this later. > > > > > > > > > > Signed-off-by: Ville Syrjälä > > > > > > > > Hm, caring about sdvo seems a bit overkill. And afaik we don't have any > > > > sdvo (much less hdmi) in CI. I'm leaning towards just adding a > > > > PIPE_CONFIG_QUIRK_INFOFRAMES for sdvo, and short-circuiting the checks > > > > if > > > > that's set. Except if you can somehow convince CI folks to add an sdvo > > > > hdmi card to CI :-) > > > > > > Unfortunately I only have one SDVO HDMI device and it has the chip > > > straight on the motherboard. I can't give mine up for ci :) I guess > > > we could try to find another one of those as that model doesn't > > > even seem super rare. Just the annoying usual problem of getting > > > one from somewhere approved. > > > > > > I think having to maintain a quirk is ~500% more annoying than > > > adding the readout code. > > > > My experience disagrees, a bunch of the (early?) sdvo chips don't bother > > to implement all the get stuff. I had a pile of these (but some of them > > died, and plugging them all into machines is a pain), and just because it > > works on 1 chip doesn't mean it's actually all that useful. That's why I > > suggested we do the same thing as with the other stuff we read out from > > the sdvo chip (as opposed to things we can read out from > > crtc/sdvo-host-side registers). > > We do read out the hdmi encoding and pixel multipler from > the sdvo chip already. If the chips don't implement the hdmi > stuff we treat them as dvi. I have some (supposedly) hdmi > add2 cards like that. So I don't think those pose any kind > of real problem. Hm ok, but you get to keep the pieces if there's an sdvo regression report :-) I.e. in that case I'd vote for a revert + quirk flag, and call it a day. But I guess for now we could assume that hdmi sdvo cards are less garbage, and implement the spec better. On both this and the previous patch: Acked-by: Daniel Vetter (Since I'm too lazy to dig out the hdmi sdvo spec and check all the details, imo not quite worth it). It would be good to capture the gist of this discussion here in the commit message, for future reference. Maybe stuff it into the readout patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Engine discovery query (rev3)
== Series Details == Series: drm/i915: Engine discovery query (rev3) URL : https://patchwork.freedesktop.org/series/39958/ State : warning == Summary == $ dim checkpatch origin/drm-tip 9c2c6952bb56 drm/i915: Engine discovery query -:179: WARNING:TYPO_SPELLING: 'an user' may be misspelled - perhaps 'a user'? #179: FILE: include/uapi/drm/i915_drm.h:1754: + * Describes one engine known to the driver, whether or not it is an user- total: 0 errors, 1 warnings, 0 checks, 162 lines checked ___ 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/3] drm/i915: Restore vblank interrupts earlier
== Series Details == Series: series starting with [1/3] drm/i915: Restore vblank interrupts earlier URL : https://patchwork.freedesktop.org/series/50393/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4907_full -> Patchwork_10307_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10307_full that come from known issues: === IGT changes === Issues hit igt@gem_exec_await@wide-contexts: shard-apl: PASS -> FAIL (fdo#106680) igt@kms_cursor_legacy@cursorb-vs-flipb-toggle: shard-glk: PASS -> DMESG-WARN (fdo#106538, fdo#105763) igt@kms_flip@flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#102887, fdo#105363) igt@kms_vblank@pipe-b-ts-continuation-suspend: shard-kbl: PASS -> DMESG-WARN (fdo#105602, fdo#103558) +1 Possible fixes igt@gem_exec_big: shard-hsw: TIMEOUT (fdo#107937) -> PASS igt@gem_ppgtt@blt-vs-render-ctxn: shard-kbl: INCOMPLETE (fdo#103665, fdo#106023) -> PASS fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#106538 https://bugs.freedesktop.org/show_bug.cgi?id=106538 fdo#106680 https://bugs.freedesktop.org/show_bug.cgi?id=106680 fdo#107937 https://bugs.freedesktop.org/show_bug.cgi?id=107937 == Participating hosts (6 -> 5) == Missing(1): shard-skl == Build changes == * Linux: CI_DRM_4907 -> Patchwork_10307 CI_DRM_4907: d628a99df39be84d6fd0a608bf2ab2185dcd6a26 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4658: cab89ce2c5da684d01deff402d4e8e11441beadb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10307: 56da01b165ac0fbb4f3ae68d0ef9aa15075b2cd5 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10307/shards.html ___ 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] igt/kms_getfb: Check the iface exists before use
On 01/10/18 12:43, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-10-01 19:36:24)
On 28/09/18 03:19, Chris Wilson wrote:
If the driver doesn't support the getfb iface (e.g. because KMS has been
disabled), the ioctls will fail with ENOTSUP. This is expected, so skip
the test as nothing useful can be learnt.
Signed-off-by: Chris Wilson
---
tests/kms_getfb.c | 40 ++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/tests/kms_getfb.c b/tests/kms_getfb.c
index 81d796a42..71d65488f 100644
--- a/tests/kms_getfb.c
+++ b/tests/kms_getfb.c
@@ -40,6 +40,40 @@
#include "drm.h"
#include "drm_fourcc.h"
+static bool has_getfb_iface(int fd)
+{
+ struct drm_mode_fb_cmd arg = { };
+ int err;
+
+ err = 0;
+ if (drmIoctl(fd, DRM_IOCTL_MODE_GETFB, ))
+ err = -errno;
+ switch (err) {
+ case -ENOTTY: /* ioctl unrecognised (kernel too old) */
+ case -ENOTSUP: /* driver doesn't support KMS */
+ return false;
+ default:
+ return true;
+ }
+}
+
+static bool has_addfb2_iface(int fd)
+{
+ struct drm_mode_fb_cmd2 arg = { };
+ int err;
+
+ err = 0;
+ if (drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, ) == 0)
+ err = -errno;
Shouldn't this^ be != 0?
Yup.
+ switch (err) {
+ case -ENOTTY: /* ioctl unrecognised (kernel too old) */
+ case -ENOTSUP: /* driver doesn't support KMS */
+ return false;
+ default:
+ return true;
Shouldn't we fail on every errno?
No. We want to be very careful in only fail at this point for errno we
know imply the interface is not supported so that we do not confuse an
illegal addfb2 request and fail later in the actual test.
Fair enough.
Acked-by: Antonio Argenziano
for the series.
-Chris
___
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/dp: Do not grab crtc modeset lock in intel_dp_detect()
On Mon, Oct 01, 2018 at 12:48:28PM -0700, Rodrigo Vivi wrote:
> On Tue, Sep 25, 2018 at 07:54:22PM -0700, Dhinakaran Pandiyan wrote:
> > A crtc modeset lock was added for link retraining but
> > intel_dp_retrain_link() knows to take the necessary locks since
> > commit c85d200e8321 ("drm/i915: Move SST DP link retraining into the
> > ->post_hotplug() hook")
> > v2: Drop AUX power domain reference in the early return path
> >
> > Fixes: c85d200e8321 ("drm/i915: Move SST DP link retraining into the
> > ->post_hotplug() hook")
>
> This patch failed on cherry-pick for drm-intel-fixes targeting 4.19.
>
> If it still makes sense to have it there please provide a backported version
> to drm-intel-fixes or let me know if it has dependency on other patches?
This is more of an optimization to not disturb page flips and whatnot
so much with detect. The double lock is otherwise harmless due to ww_mutex.
>
> Thanks,
> Rodrigo.
>
> > Cc: Ville Syrjälä
> > Signed-off-by: Dhinakaran Pandiyan
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 24 ++--
> > 1 file changed, 10 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 09229fc66dec..ef28cc0f122c 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -5079,8 +5079,15 @@ intel_dp_long_pulse(struct intel_connector
> > *connector,
> > * Some external monitors do not signal loss of link synchronization
> > * with an IRQ_HPD, so force a link status check.
> > */
> > - if (!intel_dp_is_edp(intel_dp))
> > - intel_dp_retrain_link(encoder, ctx);
> > + if (!intel_dp_is_edp(intel_dp)) {
> > + int ret;
> > +
> > + ret = intel_dp_retrain_link(encoder, ctx);
> > + if (ret) {
> > + intel_display_power_put(dev_priv,
> > intel_dp->aux_power_domain);
> > + return ret;
> > + }
> > + }
> >
> > /*
> > * Clearing NACK and defer counts to get their exact values
> > @@ -5130,19 +5137,8 @@ intel_dp_detect(struct drm_connector *connector,
> > connector->base.id, connector->name);
> >
> > /* If full detect is not performed yet, do a full detect */
> > - if (!intel_dp->detect_done) {
> > - struct drm_crtc *crtc;
> > - int ret;
> > -
> > - crtc = connector->state->crtc;
> > - if (crtc) {
> > - ret = drm_modeset_lock(>mutex, ctx);
> > - if (ret)
> > - return ret;
> > - }
> > -
> > + if (!intel_dp->detect_done)
> > status = intel_dp_long_pulse(intel_dp->attached_connector, ctx);
> > - }
> >
> > intel_dp->detect_done = false;
> >
> > --
> > 2.14.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
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] [intel-gfx] drm/i915/csr Added DC5 and DC6 counter register for ICL in debugfs entry.
DC5 and DC6 counter register tells about residency of DC5 and DC6.
These registers are same for SKL and ICL.
v2 : Remove csr_version check.
Added generic check regarding DC counters for Gen9 onwards. (Rodrigo)
Signed-off-by: Jyoti Yadav
---
drivers/gpu/drm/i915/i915_debugfs.c | 7 ---
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a5265c2..bcc1e86 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2880,11 +2880,13 @@ static int i915_dmc_info(struct seq_file *m, void
*unused)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
struct intel_csr *csr;
+ int gen;
if (!HAS_CSR(dev_priv))
return -ENODEV;
csr = _priv->csr;
+ gen = INTEL_GEN(dev_priv);
intel_runtime_pm_get(dev_priv);
@@ -2897,13 +2899,12 @@ static int i915_dmc_info(struct seq_file *m, void
*unused)
seq_printf(m, "version: %d.%d\n", CSR_VERSION_MAJOR(csr->version),
CSR_VERSION_MINOR(csr->version));
- if (IS_KABYLAKE(dev_priv) ||
- (IS_SKYLAKE(dev_priv) && csr->version >= CSR_VERSION(1, 6))) {
+ if ((!IS_BROXTON(dev_priv)) && gen >= 9 && gen <= 11) {
seq_printf(m, "DC3 -> DC5 count: %d\n",
I915_READ(SKL_CSR_DC3_DC5_COUNT));
seq_printf(m, "DC5 -> DC6 count: %d\n",
I915_READ(SKL_CSR_DC5_DC6_COUNT));
- } else if (IS_BROXTON(dev_priv) && csr->version >= CSR_VERSION(1, 4)) {
+ } else if (IS_BROXTON(dev_priv)) {
seq_printf(m, "DC3 -> DC5 count: %d\n",
I915_READ(BXT_CSR_DC3_DC5_COUNT));
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8534f88..573d5f3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6985,6 +6985,7 @@ enum {
/* MMIO address range for CSR program (0x8 - 0x82FFF) */
#define CSR_MMIO_START_RANGE 0x8
#define CSR_MMIO_END_RANGE 0x8
+/* DC3_DC5 count and DC5_DC6 count registers are same for SKL and ICL */
#define SKL_CSR_DC3_DC5_COUNT _MMIO(0x80030)
#define SKL_CSR_DC5_DC6_COUNT _MMIO(0x8002C)
#define BXT_CSR_DC3_DC5_COUNT _MMIO(0x80038)
--
1.9.1
___
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: extract common ce->pin_count check
== Series Details == Series: drm/i915: extract common ce->pin_count check URL : https://patchwork.freedesktop.org/series/50414/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4911_full -> Patchwork_10315_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_10315_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10315_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_10315_full: === IGT changes === Warnings igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-render: shard-snb: PASS -> SKIP +6 igt@perf_pmu@rc6: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_10315_full that come from known issues: === IGT changes === Issues hit igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: shard-hsw: PASS -> DMESG-WARN (fdo#107956) igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: shard-kbl: PASS -> DMESG-WARN (fdo#107956) +1 igt@kms_flip@flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#105363) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105363) -> PASS igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend: shard-apl: DMESG-WARN (fdo#103558, fdo#105602) -> PASS +4 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#107956 https://bugs.freedesktop.org/show_bug.cgi?id=107956 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (6 -> 5) == Missing(1): shard-skl == Build changes == * Linux: CI_DRM_4911 -> Patchwork_10315 CI_DRM_4911: e46b4809753a2e3d3d73c5a9e028cd030bea60e5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4659: 7f41adfbfd17027b71c332d6ae997f1364f73731 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10315: 1eeadaad02c581c752a3247f773897552f77f34c @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10315/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v3,1/6] drm/i915/psr: Share PSR and PSR2 exit mask
== Series Details == Series: series starting with [v3,1/6] drm/i915/psr: Share PSR and PSR2 exit mask URL : https://patchwork.freedesktop.org/series/50417/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4911_full -> Patchwork_10316_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_10316_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10316_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_10316_full: === IGT changes === Warnings igt@pm_rc6_residency@rc6-accuracy: shard-kbl: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_10316_full that come from known issues: === IGT changes === Issues hit igt@drv_suspend@shrink: shard-kbl: PASS -> INCOMPLETE (fdo#106886, fdo#103665) igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: shard-hsw: PASS -> DMESG-WARN (fdo#107956) igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: shard-kbl: PASS -> DMESG-WARN (fdo#107956) +1 Possible fixes igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: shard-hsw: DMESG-WARN (fdo#107956) -> PASS +1 igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105363) -> PASS +1 igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend: shard-apl: DMESG-WARN (fdo#105602, fdo#103558) -> PASS +4 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#107956 https://bugs.freedesktop.org/show_bug.cgi?id=107956 == Participating hosts (6 -> 5) == Missing(1): shard-skl == Build changes == * Linux: CI_DRM_4911 -> Patchwork_10316 CI_DRM_4911: e46b4809753a2e3d3d73c5a9e028cd030bea60e5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4659: 7f41adfbfd17027b71c332d6ae997f1364f73731 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10316: eb96d2d16902fa0585527586405210e7591aa796 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10316/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
