Re: [Intel-gfx] [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts
On Tue, Feb 27, 2018 at 1:56 PM, Ville Syrjala wrote: > From: Ville Syrjälä > > Currently we have a mix of static and dynamic information stored in > the display info structure. That makes it rather difficult to repopulate > the dynamic parts when a new EDID appears. Let's make life easier by > splitting the structure up into static and dynamic parts. > > The static part will consist of subpixel_order, panel_orientation, > and bus_formats. > > Actually I'm not sure where bus_formats & co. fit in all this. For some > drivers those seem to be static, even though they might fill them out > from .get_modes(). For other drivers this stuff even gets frobbed at > runtime, making it more some kind of a bastard encoder/connector state. > I'll just stick it into the static side so that the behaviour doesn't > change when I start clear out the entire dynamic state with memset(). > > Cc: Keith Packard > Cc: Daniel Vetter > Cc: Hans de Goede > Cc: Shashank Sharma > Cc: Stefan Agner > Cc: Thierry Reding > Cc: Boris Brezillon > Cc: Philipp Zabel > Cc: Laurent Pinchart > Cc: Manfred Schlaegl > Cc: Marek Vasut > Cc: Archit Taneja > Cc: Andrzej Hajda > Cc: Alison Wang > Cc: Eric Anholt > Cc: Linus Walleij > Cc: linux-renesas-...@vger.kernel.org > Cc: Maxime Ripard > Signed-off-by: Ville Syrjälä Acked-by: Linus Walleij Yours, Linus Walleij ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v12 1/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset
On 3/2/2018 5:46 AM, Jackie Li wrote:
GuC related exported functions should start with "intel_guc_" prefix and
pass intel_guc as the first parameter since its GuC related. Current
guc_ggtt_offset() failed to follow this code convention and this is a
problem for future patches that needs to access intel_guc data to verify
the GGTT offset against the GuC WOPCM top.
This patch renames the guc_ggtt_offset to intel_guc_ggtt_offset and updates
the related code to pass intel_guc pointer to this function call, so that
we can have a unified coding style for GuC code and also enable the future
patches to get GuC related data from intel_guc to do the offset
verification. Meanwhile, this patch also moves the GUC_GGTT_TOP from
intel_guc_regs.h to intel_guc.h since it is not GuC register related
definition.
v8:
- Fixed coding style issues and moved GUC_GGTT_TOP to intel_guc.h (Sagar)
- Updated commit message to explain to reason and motivation to add
intel_guc as the first parameter of intel_guc_ggtt_offset (Chris)
v9:
- Fixed code alignment issue due to line break (Chris)
v10:
- Removed unnecessary comments, redundant code and avoided reuse variable
to avoid potential issues (Joonas)
Cc: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Joonas Lahtinen
Reviewed-by: Sagar Arun Kamble (v8)
Reviewed-by: Joonas Lahtinen (v9)
Signed-off-by: Jackie Li
I think maintainers will prefer as:
either
Cc:
Cc:
S-o-b:
R-b:
or
S-o-b:
Cc:
Cc:
R-b:
Similar for other patches.
Reviewed-by: Michal Wajdeczko (v11)
---
drivers/gpu/drm/i915/intel_guc.c| 11 ++-
drivers/gpu/drm/i915/intel_guc.h| 14 --
drivers/gpu/drm/i915/intel_guc_ads.c| 8
drivers/gpu/drm/i915/intel_guc_ct.c | 5 +++--
drivers/gpu/drm/i915/intel_guc_fw.c | 2 +-
drivers/gpu/drm/i915/intel_guc_log.c| 2 +-
drivers/gpu/drm/i915/intel_guc_reg.h| 3 ---
drivers/gpu/drm/i915/intel_guc_submission.c | 10 +-
drivers/gpu/drm/i915/intel_huc.c| 6 --
9 files changed, 36 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index e6512cc..a788e15 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -269,8 +269,9 @@ void intel_guc_init_params(struct intel_guc *guc)
/* If GuC submission is enabled, set up additional parameters here */
if (USES_GUC_SUBMISSION(dev_priv)) {
- u32 ads = guc_ggtt_offset(guc->ads_vma) >> PAGE_SHIFT;
- u32 pgs = guc_ggtt_offset(dev_priv->guc.stage_desc_pool);
+ u32 ads = intel_guc_ggtt_offset(guc,
+ guc->ads_vma) >> PAGE_SHIFT;
+ u32 pgs = intel_guc_ggtt_offset(guc, guc->stage_desc_pool);
u32 ctx_in_16 = GUC_MAX_STAGE_DESCRIPTORS / 16;
params[GUC_CTL_DEBUG] |= ads << GUC_ADS_ADDR_SHIFT;
@@ -418,7 +419,7 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
/* any value greater than GUC_POWER_D0 */
data[1] = GUC_POWER_D1;
- data[2] = guc_ggtt_offset(guc->shared_data);
+ data[2] = intel_guc_ggtt_offset(guc, guc->shared_data);
return intel_guc_send(guc, data, ARRAY_SIZE(data));
}
@@ -441,7 +442,7 @@ int intel_guc_reset_engine(struct intel_guc *guc,
data[3] = 0;
data[4] = 0;
data[5] = guc->execbuf_client->stage_id;
- data[6] = guc_ggtt_offset(guc->shared_data);
+ data[6] = intel_guc_ggtt_offset(guc, guc->shared_data);
return intel_guc_send(guc, data, ARRAY_SIZE(data));
}
@@ -463,7 +464,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
data[1] = GUC_POWER_D0;
- data[2] = guc_ggtt_offset(guc->shared_data);
+ data[2] = intel_guc_ggtt_offset(guc, guc->shared_data);
return intel_guc_send(guc, data, ARRAY_SIZE(data));
}
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 52856a9..0c8b10a 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -100,13 +100,23 @@ static inline void intel_guc_notify(struct intel_guc *guc)
guc->notify(guc);
}
-/*
+/* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */
+#define GUC_GGTT_TOP 0xFEE0
+
+/**
+ * intel_guc_ggtt_offset() - Get and validate the GGTT offset of @vma
+ * @guc: intel_guc structure.
+ * @vma: i915 graphics virtual memory area.
+ *
* GuC does not allow any gfx GGTT address that falls into range [0,
WOPCM_TOP),
* which is reserved for Boot ROM, SRAM and WOPCM. Currently this top address
is
* 512K. In order to exclude 0-512K address space from GGTT, all gfx objects
* used by GuC is pinned with PIN_OFFSET_BIAS along with size of WOPCM.
+ *
+ * Return: GGTT offset that meets the G
Re: [Intel-gfx] [PATCH v12 2/6] drm/i915: Implement dynamic GuC WOPCM offset and size calculation
On 3/2/2018 5:46 AM, Jackie Li wrote: Hardware may have specific restrictions on GuC WOPCM offset and size. On Gen9, the value of the GuC WOPCM size register needs to be larger than the value of GuC WOPCM offset register + a Gen9 specific offset (144KB) for reserved GuC WOPCM. Fail to enforce such a restriction on GuC WOPCM size will lead to GuC firmware execution failures. On the other hand, with current static GuC WOPCM offset and size values (512KB for both offset and size), the GuC WOPCM size verification will fail on Gen9 even if it can be fixed by lowering the GuC WOPCM offset by calculating its value based on HuC firmware size (which is likely less than 200KB on Gen9), so that we can have a GuC WOPCM size value which is large enough to pass the GuC WOPCM size check. This patch updates the reserved GuC WOPCM size for RC6 context on Gen9 to 24KB to strictly align with the Gen9 GuC WOPCM layout. It also adds support to verify the GuC WOPCM size aganist the Gen9 hardware restrictions. To meet all above requirements, let's provide dynamic partitioning of the WOPCM that will be based on platform specific HuC/GuC firmware sizes. v2: - Removed intel_wopcm_init (Ville/Sagar/Joonas) - Renamed and Moved the intel_wopcm_partition into intel_guc (Sagar) - Removed unnecessary function calls (Joonas) - Init GuC WOPCM partition as soon as firmware fetching is completed v3: - Fixed indentation issues (Chris) - Removed layering violation code (Chris/Michal) - Created separat files for GuC wopcm code (Michal) - Used inline function to avoid code duplication (Michal) v4: - Preset the GuC WOPCM top during early GuC init (Chris) - Fail intel_uc_init_hw() as soon as GuC WOPCM partitioning failed v5: - Moved GuC DMA WOPCM register updating code into intel_wopcm.c - Took care of the locking status before writing to GuC DMA Write-Once registers. (Joonas) v6: - Made sure the GuC WOPCM size to be multiple of 4K (4K aligned) v8: - Updated comments and fixed naming issues (Sagar/Joonas) - Updated commit message to include more description about the hardware restriction on GuC WOPCM size (Sagar) v9: - Minor changes variable names and code comments (Sagar) - Added detailed GuC WOPCM layout drawing (Sagar/Michal) - Refined macro definitions to be reader friendly (Michal) - Removed redundent check to valid flag (Michal) - Unified first parameter for exported GuC WOPCM functions (Michal) - Refined the name and parameter list of hardware restriction checking functions (Michal) v10: - Used shorter function name for internal functions (Joonas) - Moved init-ealry function into c file (Joonas) - Consolidated and removed redundant size checks (Joonas/Michal) - Removed unnecessary unlikely() from code which is only called once during boot (Joonas) - More fixes to kernel-doc format and content (Michal) - Avoided the use of PAGE_MASK for 4K pages (Michal) - Added error log messages to error paths (Michal) v11: - Replaced intel_guc_wopcm with more generic intel_wopcm and attached intel_wopcm to drm_i915_private instead intel_guc (Michal) - dynamic calculation of GuC non-wopcm memory start (a.k.a WOPCM Top offset from GuC WOPCM base) (Michal) - Moved WOPCM marco definitions into .c source file (Michal) - Exported WOPCM layout diagram as kernel-doc (Michal) v12: - Updated naming, function kernel-doc to align with new changes (Michal) Bspec: 12690 Cc: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Sujaritha Sundaresan Cc: Daniele Ceraolo Spurio Cc: John Spotswood Cc: Oscar Mateo Cc: Chris Wilson Cc: Joonas Lahtinen Reviewed-by: Sagar Arun Kamble (v8) Reviewed-by: Joonas Lahtinen (v9) Reviewed-by: Michal Wajdeczko (v11) Signed-off-by: Jackie Li --- drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/i915_drv.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 8 ++ drivers/gpu/drm/i915/i915_gem.c | 4 + drivers/gpu/drm/i915/i915_gem_context.c | 5 +- drivers/gpu/drm/i915/intel_guc.c| 66 --- drivers/gpu/drm/i915/intel_guc.h| 16 ++- drivers/gpu/drm/i915/intel_guc_reg.h| 8 +- drivers/gpu/drm/i915/intel_huc.c| 2 +- drivers/gpu/drm/i915/intel_uc.c | 6 +- drivers/gpu/drm/i915/intel_uc_fw.c | 13 +-- drivers/gpu/drm/i915/intel_uc_fw.h | 16 +++ drivers/gpu/drm/i915/intel_wopcm.c | 195 drivers/gpu/drm/i915/intel_wopcm.h | 34 ++ 14 files changed, 337 insertions(+), 40 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_wopcm.c create mode 100644 drivers/gpu/drm/i915/intel_wopcm.h diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 881d712..652549e 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -78,7 +78,8 @@ i915-y += i915_cmd_parser.o \ intel_lrc.o \ intel_mocs.o \
[Intel-gfx] [PATCH igt v2] igt/gen7_forcewake_mt: Make the mmio register as volatile
Prevent the compiler from caching reads/writes to the hw register as we
do want to perform mmio.
Whilst fixing up the mmio access, also ensure that we do not leave the
test with any other bits still set in the forcewake register to prevent
affecting other tests, as spotted by Tvrtko.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/gen7_forcewake_mt.c | 59 +--
1 file changed, 47 insertions(+), 12 deletions(-)
diff --git a/tests/gen7_forcewake_mt.c b/tests/gen7_forcewake_mt.c
index 07320ef9..218f674c 100644
--- a/tests/gen7_forcewake_mt.c
+++ b/tests/gen7_forcewake_mt.c
@@ -44,9 +44,10 @@ IGT_TEST_DESCRIPTION("Exercise a suspect workaround required
for"
struct thread {
pthread_t thread;
- void *mmio;
+ volatile uint32_t *mmio;
int fd;
int bit;
+ bool done;
};
static const struct pci_id_match match[] = {
@@ -80,7 +81,7 @@ static struct pci_device *__igfx_get(void)
return dev;
}
-static void *igfx_get_mmio(void)
+static volatile uint32_t *igfx_get_forcewake_mt(void)
{
struct pci_device *pci = __igfx_get();
void *mmio = NULL;
@@ -100,20 +101,28 @@ static void *igfx_get_mmio(void)
igt_assert_eq(error, 0);
igt_assert(mmio != NULL);
- return mmio;
+ return (volatile uint32_t *)((char *)mmio + FORCEWAKE_MT);
}
+
static void *thread(void *arg)
{
+ static const char acquire_error[] = "acquire";
+ static const char release_error[] = "release";
+
struct thread *t = arg;
- uint32_t *forcewake_mt = (uint32_t *)((char *)t->mmio + FORCEWAKE_MT);
- uint32_t bit = 1 << t->bit;
+ const uint32_t bit = 1 << t->bit;
+ volatile uint32_t *forcewake_mt = t->mmio;
- while (1) {
+ while (!t->done) {
*forcewake_mt = bit << 16 | bit;
- igt_assert(*forcewake_mt & bit);
+ if (igt_wait(*forcewake_mt & bit, 50, 1))
+ return (void *)acquire_error;
+
*forcewake_mt = bit << 16;
- igt_assert((*forcewake_mt & bit) == 0);
+ igt_assert(igt_wait((*forcewake_mt & bit) == 0, 50, 1) == 0);
+ if (igt_wait((*forcewake_mt & bit) == 0, 50, 1))
+ return (void *)release_error;
}
return NULL;
@@ -124,10 +133,12 @@ static void *thread(void *arg)
igt_simple_main
{
struct thread t[16];
+ bool success = true;
int i;
t[0].fd = drm_open_driver(DRIVER_INTEL);
- t[0].mmio = igfx_get_mmio();
+ t[0].mmio = igfx_get_forcewake_mt();
+ t[0].done = false;
for (i = 2; i < 16; i++) {
t[i] = t[0];
@@ -137,7 +148,7 @@ igt_simple_main
sleep(2);
- for (i = 0; i < 1000; i++) {
+ igt_until_timeout(2) {
uint32_t *p;
struct drm_i915_gem_execbuffer2 execbuf;
struct drm_i915_gem_exec_object2 exec[2];
@@ -192,13 +203,37 @@ igt_simple_main
p = gem_mmap__gtt(t[0].fd, exec[0].handle, 4096, PROT_READ);
igt_info("[%d]={ %08x %08x }\n", i, p[0], p[1]);
- igt_assert(p[0] & 2);
- igt_assert((p[1] & 2) == 0);
+ if ((p[0] & 2) == 0) {
+ igt_warn("Failed to acquire forcewake BIT(1) from
batch\n");
+ success = false;
+ }
+ if ((p[1] & 2)) {
+ igt_warn("Failed to release forcewake BIT(1) from
batch\n");
+ success = false;
+ }
munmap(p, 4096);
gem_close(t[0].fd, exec[0].handle);
gem_close(t[0].fd, exec[1].handle);
+ if (!success)
+ break;
usleep(1000);
}
+
+ for (i = 2; i < 16; i++) {
+ void *result;
+
+ t[i].done = true;
+ pthread_join(t[i].thread, &result);
+ if (result) {
+ igt_warn("Thread BIT(%d) failed to %s forcewake\n", i,
(char *)result);
+ success = false;
+ }
+ }
+
+ /* And clear all forcewake bits before disappearing */
+ *t[0].mmio = 0xfffe << 16;
+
+ igt_assert(success);
}
--
2.16.2
___
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: Update PSR2 resolution check for Cannonlake
On Thu, Mar 01, 2018 at 10:04:04PM +, Pandiyan, Dhinakaran wrote:
>
>
>
> On Thu, 2018-03-01 at 23:47 +0200, Ville Syrjälä wrote:
> > On Thu, Mar 01, 2018 at 01:27:09PM -0800, Dhinakaran Pandiyan wrote:
> > > In fact, apply the Cannonlake resolution check for all >= Gen-10 platforms
> > > to be safe.
> > >
> > > v2: Use local variables for resolution limits and print them (Ville)
> > >
> > > Cc: Ville Syrjälä
> > > Cc: Rodrigo Vivi
> > > Cc: Elio Martinez Monroy
> > > Signed-off-by: Dhinakaran Pandiyan
> > > ---
> > > drivers/gpu/drm/i915/intel_psr.c | 14 --
> > > 1 file changed, 8 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index 05770790a4e9..66d04a8dd99e 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -451,8 +451,9 @@ static bool intel_psr2_config_valid(struct intel_dp
> > > *intel_dp,
> > > {
> > > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > > struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> > > - const struct drm_display_mode *adjusted_mode =
> > > - &crtc_state->base.adjusted_mode;
> > > + int crtc_h = crtc_state->base.adjusted_mode.crtc_hdisplay;
> > > + int crtc_v = crtc_state->base.adjusted_mode.crtc_vdisplay;
> >
> > I'd probably call these hdisp/vdisp or something like that. "crtc_h" makes
> > me think it's a height of a plane in crtc (pipe source) coordinates.
>
> and h/vdisplay are specifically related to the mode?
They are the active portion of the timings.
>
> >
> > > + int max_h, max_v;
> I guess this is okay then?
max_h does make me immediately think "max height" so they could probably
use a few more characters as well.
>
> > >
> > > /*
> > >* FIXME psr2_support is messed up. It's both computed
> > > @@ -462,10 +463,11 @@ static bool intel_psr2_config_valid(struct intel_dp
> > > *intel_dp,
> > > if (!dev_priv->psr.psr2_support)
> > > return false;
> > >
> > > - /* PSR2 is restricted to work with panel resolutions up to 3640x2304 */
> > > - if (adjusted_mode->crtc_hdisplay > 3640 ||
> > > - adjusted_mode->crtc_vdisplay > 2304) {
> > > - DRM_DEBUG_KMS("PSR2 not enabled, panel resolution too big\n");
> > > + max_h = INTEL_GEN(dev_priv) >= 10 ? 4096 : 3640;
> > > + max_v = 2304;
> >
> > GLK should use the higher limit too no?
>
> Yeah, I just checked and it makes sense to update GLK too.
>
> >
> > Looking at the *future* stuff for this it looks like we'll be getting
> > different limits again soon. So I'd prep for that day by making this
> > a full blown if ladder from the start.
> >
> > > + if (crtc_h > max_h || crtc_v > max_v) {
> > > + DRM_DEBUG_KMS("PSR2 not enabled, resolution %dx%d > max
> > > supported %dx%d\n",
> > > + crtc_h, crtc_v, max_h, max_v);
> > > return false;
> > > }
> > >
> > > --
> > > 2.14.1
> >
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt v3] igt/gen7_forcewake_mt: Make the mmio register as volatile
Prevent the compiler from caching reads/writes to the hw register as we
do want to perform mmio.
Whilst fixing up the mmio access, also ensure that we do not leave the
test with any other bits still set in the forcewake register to prevent
affecting other tests, as spotted by Tvrtko.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
One igt_assert() left inside the thread that was already duplicated into
the soft return.
---
tests/gen7_forcewake_mt.c | 58 +--
1 file changed, 46 insertions(+), 12 deletions(-)
diff --git a/tests/gen7_forcewake_mt.c b/tests/gen7_forcewake_mt.c
index 07320ef9..49e92124 100644
--- a/tests/gen7_forcewake_mt.c
+++ b/tests/gen7_forcewake_mt.c
@@ -44,9 +44,10 @@ IGT_TEST_DESCRIPTION("Exercise a suspect workaround required
for"
struct thread {
pthread_t thread;
- void *mmio;
+ volatile uint32_t *mmio;
int fd;
int bit;
+ bool done;
};
static const struct pci_id_match match[] = {
@@ -80,7 +81,7 @@ static struct pci_device *__igfx_get(void)
return dev;
}
-static void *igfx_get_mmio(void)
+static volatile uint32_t *igfx_get_forcewake_mt(void)
{
struct pci_device *pci = __igfx_get();
void *mmio = NULL;
@@ -100,20 +101,27 @@ static void *igfx_get_mmio(void)
igt_assert_eq(error, 0);
igt_assert(mmio != NULL);
- return mmio;
+ return (volatile uint32_t *)((char *)mmio + FORCEWAKE_MT);
}
+
static void *thread(void *arg)
{
+ static const char acquire_error[] = "acquire";
+ static const char release_error[] = "release";
+
struct thread *t = arg;
- uint32_t *forcewake_mt = (uint32_t *)((char *)t->mmio + FORCEWAKE_MT);
- uint32_t bit = 1 << t->bit;
+ const uint32_t bit = 1 << t->bit;
+ volatile uint32_t *forcewake_mt = t->mmio;
- while (1) {
+ while (!t->done) {
*forcewake_mt = bit << 16 | bit;
- igt_assert(*forcewake_mt & bit);
+ if (igt_wait(*forcewake_mt & bit, 50, 1))
+ return (void *)acquire_error;
+
*forcewake_mt = bit << 16;
- igt_assert((*forcewake_mt & bit) == 0);
+ if (igt_wait((*forcewake_mt & bit) == 0, 50, 1))
+ return (void *)release_error;
}
return NULL;
@@ -124,10 +132,12 @@ static void *thread(void *arg)
igt_simple_main
{
struct thread t[16];
+ bool success = true;
int i;
t[0].fd = drm_open_driver(DRIVER_INTEL);
- t[0].mmio = igfx_get_mmio();
+ t[0].mmio = igfx_get_forcewake_mt();
+ t[0].done = false;
for (i = 2; i < 16; i++) {
t[i] = t[0];
@@ -137,7 +147,7 @@ igt_simple_main
sleep(2);
- for (i = 0; i < 1000; i++) {
+ igt_until_timeout(2) {
uint32_t *p;
struct drm_i915_gem_execbuffer2 execbuf;
struct drm_i915_gem_exec_object2 exec[2];
@@ -192,13 +202,37 @@ igt_simple_main
p = gem_mmap__gtt(t[0].fd, exec[0].handle, 4096, PROT_READ);
igt_info("[%d]={ %08x %08x }\n", i, p[0], p[1]);
- igt_assert(p[0] & 2);
- igt_assert((p[1] & 2) == 0);
+ if ((p[0] & 2) == 0) {
+ igt_warn("Failed to acquire forcewake BIT(1) from
batch\n");
+ success = false;
+ }
+ if ((p[1] & 2)) {
+ igt_warn("Failed to release forcewake BIT(1) from
batch\n");
+ success = false;
+ }
munmap(p, 4096);
gem_close(t[0].fd, exec[0].handle);
gem_close(t[0].fd, exec[1].handle);
+ if (!success)
+ break;
usleep(1000);
}
+
+ for (i = 2; i < 16; i++) {
+ void *result;
+
+ t[i].done = true;
+ pthread_join(t[i].thread, &result);
+ if (result) {
+ igt_warn("Thread BIT(%d) failed to %s forcewake\n", i,
(char *)result);
+ success = false;
+ }
+ }
+
+ /* And clear all forcewake bits before disappearing */
+ *t[0].mmio = 0xfffe << 16;
+
+ igt_assert(success);
}
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt v4] igt/gen7_forcewake_mt: Make the mmio register as volatile
Prevent the compiler from caching reads/writes to the hw register as we
do want to perform mmio.
Whilst fixing up the mmio access, also ensure that we do not leave the
test with any other bits still set in the forcewake register to prevent
affecting other tests, as spotted by Tvrtko.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
Also be sure the compiler doesn't eliminate t->done.
Go get some coffee Chris.
-Chris
tests/gen7_forcewake_mt.c | 59 +--
1 file changed, 47 insertions(+), 12 deletions(-)
diff --git a/tests/gen7_forcewake_mt.c b/tests/gen7_forcewake_mt.c
index 07320ef9..6eb66c00 100644
--- a/tests/gen7_forcewake_mt.c
+++ b/tests/gen7_forcewake_mt.c
@@ -41,12 +41,14 @@ IGT_TEST_DESCRIPTION("Exercise a suspect workaround
required for"
" FORCEWAKE_MT.");
#define FORCEWAKE_MT 0xa188
+#define READ_ONCE(x) (*(volatile typeof(x) *)(&(x)))
struct thread {
pthread_t thread;
- void *mmio;
+ volatile uint32_t *mmio;
int fd;
int bit;
+ bool done;
};
static const struct pci_id_match match[] = {
@@ -80,7 +82,7 @@ static struct pci_device *__igfx_get(void)
return dev;
}
-static void *igfx_get_mmio(void)
+static volatile uint32_t *igfx_get_forcewake_mt(void)
{
struct pci_device *pci = __igfx_get();
void *mmio = NULL;
@@ -100,20 +102,27 @@ static void *igfx_get_mmio(void)
igt_assert_eq(error, 0);
igt_assert(mmio != NULL);
- return mmio;
+ return (volatile uint32_t *)((char *)mmio + FORCEWAKE_MT);
}
+
static void *thread(void *arg)
{
+ static const char acquire_error[] = "acquire";
+ static const char release_error[] = "release";
+
struct thread *t = arg;
- uint32_t *forcewake_mt = (uint32_t *)((char *)t->mmio + FORCEWAKE_MT);
- uint32_t bit = 1 << t->bit;
+ const uint32_t bit = 1 << t->bit;
+ volatile uint32_t *forcewake_mt = t->mmio;
- while (1) {
+ while (!READ_ONCE(t->done)) {
*forcewake_mt = bit << 16 | bit;
- igt_assert(*forcewake_mt & bit);
+ if (igt_wait(*forcewake_mt & bit, 50, 1))
+ return (void *)acquire_error;
+
*forcewake_mt = bit << 16;
- igt_assert((*forcewake_mt & bit) == 0);
+ if (igt_wait((*forcewake_mt & bit) == 0, 50, 1))
+ return (void *)release_error;
}
return NULL;
@@ -124,10 +133,12 @@ static void *thread(void *arg)
igt_simple_main
{
struct thread t[16];
+ bool success = true;
int i;
t[0].fd = drm_open_driver(DRIVER_INTEL);
- t[0].mmio = igfx_get_mmio();
+ t[0].mmio = igfx_get_forcewake_mt();
+ t[0].done = false;
for (i = 2; i < 16; i++) {
t[i] = t[0];
@@ -137,7 +148,7 @@ igt_simple_main
sleep(2);
- for (i = 0; i < 1000; i++) {
+ igt_until_timeout(2) {
uint32_t *p;
struct drm_i915_gem_execbuffer2 execbuf;
struct drm_i915_gem_exec_object2 exec[2];
@@ -192,13 +203,37 @@ igt_simple_main
p = gem_mmap__gtt(t[0].fd, exec[0].handle, 4096, PROT_READ);
igt_info("[%d]={ %08x %08x }\n", i, p[0], p[1]);
- igt_assert(p[0] & 2);
- igt_assert((p[1] & 2) == 0);
+ if ((p[0] & 2) == 0) {
+ igt_warn("Failed to acquire forcewake BIT(1) from
batch\n");
+ success = false;
+ }
+ if ((p[1] & 2)) {
+ igt_warn("Failed to release forcewake BIT(1) from
batch\n");
+ success = false;
+ }
munmap(p, 4096);
gem_close(t[0].fd, exec[0].handle);
gem_close(t[0].fd, exec[1].handle);
+ if (!success)
+ break;
usleep(1000);
}
+
+ for (i = 2; i < 16; i++) {
+ void *result;
+
+ t[i].done = true;
+ pthread_join(t[i].thread, &result);
+ if (result) {
+ igt_warn("Thread BIT(%d) failed to %s forcewake\n", i,
(char *)result);
+ success = false;
+ }
+ }
+
+ /* And clear all forcewake bits before disappearing */
+ *t[0].mmio = 0xfffe << 16;
+
+ igt_assert(success);
}
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt v2] igt/gen7_forcewake_mt: Make the mmio register as volatile
On Fri, Mar 02, 2018 at 08:12:35AM +, Chris Wilson wrote:
> Prevent the compiler from caching reads/writes to the hw register as we
> do want to perform mmio.
>
> Whilst fixing up the mmio access, also ensure that we do not leave the
> test with any other bits still set in the forcewake register to prevent
> affecting other tests, as spotted by Tvrtko.
I wonder why this test isn't using intel_register_access_init() & co.?
Maybe because the library code used to take the forcewake always? But
that could be prevented with a setenv() now.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> ---
> tests/gen7_forcewake_mt.c | 59
> +--
> 1 file changed, 47 insertions(+), 12 deletions(-)
>
> diff --git a/tests/gen7_forcewake_mt.c b/tests/gen7_forcewake_mt.c
> index 07320ef9..218f674c 100644
> --- a/tests/gen7_forcewake_mt.c
> +++ b/tests/gen7_forcewake_mt.c
> @@ -44,9 +44,10 @@ IGT_TEST_DESCRIPTION("Exercise a suspect workaround
> required for"
>
> struct thread {
> pthread_t thread;
> - void *mmio;
> + volatile uint32_t *mmio;
> int fd;
> int bit;
> + bool done;
> };
>
> static const struct pci_id_match match[] = {
> @@ -80,7 +81,7 @@ static struct pci_device *__igfx_get(void)
> return dev;
> }
>
> -static void *igfx_get_mmio(void)
> +static volatile uint32_t *igfx_get_forcewake_mt(void)
> {
> struct pci_device *pci = __igfx_get();
> void *mmio = NULL;
> @@ -100,20 +101,28 @@ static void *igfx_get_mmio(void)
> igt_assert_eq(error, 0);
> igt_assert(mmio != NULL);
>
> - return mmio;
> + return (volatile uint32_t *)((char *)mmio + FORCEWAKE_MT);
> }
>
> +
> static void *thread(void *arg)
> {
> + static const char acquire_error[] = "acquire";
> + static const char release_error[] = "release";
> +
> struct thread *t = arg;
> - uint32_t *forcewake_mt = (uint32_t *)((char *)t->mmio + FORCEWAKE_MT);
> - uint32_t bit = 1 << t->bit;
> + const uint32_t bit = 1 << t->bit;
> + volatile uint32_t *forcewake_mt = t->mmio;
>
> - while (1) {
> + while (!t->done) {
> *forcewake_mt = bit << 16 | bit;
> - igt_assert(*forcewake_mt & bit);
> + if (igt_wait(*forcewake_mt & bit, 50, 1))
> + return (void *)acquire_error;
> +
> *forcewake_mt = bit << 16;
> - igt_assert((*forcewake_mt & bit) == 0);
> + igt_assert(igt_wait((*forcewake_mt & bit) == 0, 50, 1) == 0);
> + if (igt_wait((*forcewake_mt & bit) == 0, 50, 1))
> + return (void *)release_error;
> }
>
> return NULL;
> @@ -124,10 +133,12 @@ static void *thread(void *arg)
> igt_simple_main
> {
> struct thread t[16];
> + bool success = true;
> int i;
>
> t[0].fd = drm_open_driver(DRIVER_INTEL);
> - t[0].mmio = igfx_get_mmio();
> + t[0].mmio = igfx_get_forcewake_mt();
> + t[0].done = false;
>
> for (i = 2; i < 16; i++) {
> t[i] = t[0];
> @@ -137,7 +148,7 @@ igt_simple_main
>
> sleep(2);
>
> - for (i = 0; i < 1000; i++) {
> + igt_until_timeout(2) {
> uint32_t *p;
> struct drm_i915_gem_execbuffer2 execbuf;
> struct drm_i915_gem_exec_object2 exec[2];
> @@ -192,13 +203,37 @@ igt_simple_main
> p = gem_mmap__gtt(t[0].fd, exec[0].handle, 4096, PROT_READ);
>
> igt_info("[%d]={ %08x %08x }\n", i, p[0], p[1]);
> - igt_assert(p[0] & 2);
> - igt_assert((p[1] & 2) == 0);
> + if ((p[0] & 2) == 0) {
> + igt_warn("Failed to acquire forcewake BIT(1) from
> batch\n");
> + success = false;
> + }
> + if ((p[1] & 2)) {
> + igt_warn("Failed to release forcewake BIT(1) from
> batch\n");
> + success = false;
> + }
>
> munmap(p, 4096);
> gem_close(t[0].fd, exec[0].handle);
> gem_close(t[0].fd, exec[1].handle);
> + if (!success)
> + break;
>
> usleep(1000);
> }
> +
> + for (i = 2; i < 16; i++) {
> + void *result;
> +
> + t[i].done = true;
> + pthread_join(t[i].thread, &result);
> + if (result) {
> + igt_warn("Thread BIT(%d) failed to %s forcewake\n", i,
> (char *)result);
> + success = false;
> + }
> + }
> +
> + /* And clear all forcewake bits before disappearing */
> + *t[0].mmio = 0xfffe << 16;
> +
> + igt_assert(success);
> }
> --
> 2.16.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
_
Re: [Intel-gfx] [PATCH v3 1/1] drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric
Quoting Sagar Arun Kamble (2018-03-01 16:45:45)
> +static int huc_fw_xfer(struct intel_uc_fw *huc_fw, struct i915_vma *vma)
> +{
> + struct intel_huc *huc = container_of(huc_fw, struct intel_huc, fw);
> + struct drm_i915_private *dev_priv = huc_to_i915(huc);
> + unsigned long offset = 0;
> + u32 size;
> + int ret;
> +
> + GEM_BUG_ON(huc_fw->type != INTEL_UC_FW_TYPE_HUC);
> +
> + intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
> +
> + /* Set the source address for the uCode */
> + offset = guc_ggtt_offset(vma) + huc_fw->header_offset;
> + I915_WRITE(DMA_ADDR_0_LOW, lower_32_bits(offset));
> + I915_WRITE(DMA_ADDR_0_HIGH, upper_32_bits(offset) & 0x);
So these same registers are used to transfer the guc image. What
serialisation do we have between the two to prevent conflicts?
(lockdep_assert_held the appropriate guard with explanation :)
As it's not a new issue, please follow up with another patch and we'll
apply this in the meantime.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt v2] igt/gen7_forcewake_mt: Make the mmio register as volatile
Quoting Ville Syrjälä (2018-03-02 08:27:45) > On Fri, Mar 02, 2018 at 08:12:35AM +, Chris Wilson wrote: > > Prevent the compiler from caching reads/writes to the hw register as we > > do want to perform mmio. > > > > Whilst fixing up the mmio access, also ensure that we do not leave the > > test with any other bits still set in the forcewake register to prevent > > affecting other tests, as spotted by Tvrtko. > > I wonder why this test isn't using intel_register_access_init() & co.? > Maybe because the library code used to take the forcewake always? But > that could be prevented with a setenv() now. It could just use intel_mmio_use_pci_bar() and then intel_register_access_init() doesn't have to worry about silly tests trying to abuse the hw. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2] tests/gen7_forcewake_mt: Fix test
From: Tvrtko Ursulin
1.
We need to tell the compiler mmio access cannot be optimized away
(volatile).
2.
We need to ensure we don't exit with forcewake left on. Signal threads
to exit in a controlled fashion and install atexit handler just in case.
v2: Do not assert from the threads.
Signed-off-by: Tvrtko Ursulin
---
tests/gen7_forcewake_mt.c | 68 +++
1 file changed, 63 insertions(+), 5 deletions(-)
diff --git a/tests/gen7_forcewake_mt.c b/tests/gen7_forcewake_mt.c
index 07320ef9e8ac..608217fe652a 100644
--- a/tests/gen7_forcewake_mt.c
+++ b/tests/gen7_forcewake_mt.c
@@ -44,6 +44,7 @@ IGT_TEST_DESCRIPTION("Exercise a suspect workaround required
for"
struct thread {
pthread_t thread;
+ bool run;
void *mmio;
int fd;
int bit;
@@ -106,14 +107,26 @@ static void *igfx_get_mmio(void)
static void *thread(void *arg)
{
struct thread *t = arg;
- uint32_t *forcewake_mt = (uint32_t *)((char *)t->mmio + FORCEWAKE_MT);
+ volatile uint32_t *forcewake_mt =
+ (uint32_t *)((char *)t->mmio + FORCEWAKE_MT);
uint32_t bit = 1 << t->bit;
- while (1) {
+ while (t->run) {
+ uint32_t reg;
+
*forcewake_mt = bit << 16 | bit;
- igt_assert(*forcewake_mt & bit);
+ reg = *forcewake_mt;
+ if (!(reg & bit)) {
+ igt_warn("Bit %u did not set! (val=%x)\n", t->bit, reg);
+ return (void *)-1;
+ }
*forcewake_mt = bit << 16;
- igt_assert((*forcewake_mt & bit) == 0);
+ reg = *forcewake_mt;
+ if (reg & bit) {
+ igt_warn("Bit %u did not clear! (val=%x)\n",
+t->bit, reg);
+ return (void *)-1;
+ }
}
return NULL;
@@ -121,13 +134,39 @@ static void *thread(void *arg)
#define MI_STORE_REGISTER_MEM (0x24<<23)
+static void *mmio_base;
+
+static void cleanup(int sig)
+{
+ volatile uint32_t *forcewake_mt =
+ (uint32_t *)((char *)mmio_base + FORCEWAKE_MT);
+ unsigned int bit;
+
+ for (bit = 2; bit < 16; bit++) {
+ uint32_t val = 1 << bit;
+ uint32_t reg;
+
+ *forcewake_mt = val << 16;
+ reg = *forcewake_mt;
+ if (reg & val)
+ igt_warn("Failed to restore bit %u! (val=%x)\n",
+bit, reg);
+ }
+}
+
igt_simple_main
{
struct thread t[16];
+ bool success = true;
int i;
+ mmio_base = igfx_get_mmio();
+
t[0].fd = drm_open_driver(DRIVER_INTEL);
- t[0].mmio = igfx_get_mmio();
+ t[0].run = true;
+ t[0].mmio = mmio_base;
+
+ igt_install_exit_handler(cleanup);
for (i = 2; i < 16; i++) {
t[i] = t[0];
@@ -201,4 +240,23 @@ igt_simple_main
usleep(1000);
}
+
+ for (i = 2; i < 16; i++)
+ t[i].run = false;
+
+ for (i = 2; i < 16; i++) {
+ void *threadret = NULL;
+ int ret;
+
+ ret = pthread_join(t[i].thread, &threadret);
+ if (ret) {
+ igt_warn("failed to join thread%u! (%d)\n", i, ret);
+ success = false;
+ } else if (threadret) {
+ igt_warn("thread%u failed! (%p)\n", i, threadret);
+ success = false;
+ }
+ }
+
+ igt_assert(success);
}
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI i-g-t v3] don't look
From: Tvrtko Ursulin
1.
We need to tell the compiler mmio access cannot be optimized away
(volatile).
2.
We need to ensure we don't exit with forcewake left on. Signal threads
to exit in a controlled fashion and install atexit handler just in case.
v2: Do not assert from the threads.
v3: HACK
Signed-off-by: Tvrtko Ursulin
---
tests/gen7_forcewake_mt.c | 69 +++
1 file changed, 64 insertions(+), 5 deletions(-)
diff --git a/tests/gen7_forcewake_mt.c b/tests/gen7_forcewake_mt.c
index 07320ef9e8ac..d8a369b0e6ff 100644
--- a/tests/gen7_forcewake_mt.c
+++ b/tests/gen7_forcewake_mt.c
@@ -29,6 +29,7 @@
* Testcase: Exercise a suspect workaround required for FORCEWAKE_MT
*
*/
+#pragma GCC optimize ("O0")
#include "igt.h"
#include
@@ -44,6 +45,7 @@ IGT_TEST_DESCRIPTION("Exercise a suspect workaround required
for"
struct thread {
pthread_t thread;
+ bool run;
void *mmio;
int fd;
int bit;
@@ -106,14 +108,26 @@ static void *igfx_get_mmio(void)
static void *thread(void *arg)
{
struct thread *t = arg;
- uint32_t *forcewake_mt = (uint32_t *)((char *)t->mmio + FORCEWAKE_MT);
+ volatile uint32_t *forcewake_mt =
+ (uint32_t *)((char *)t->mmio + FORCEWAKE_MT);
uint32_t bit = 1 << t->bit;
- while (1) {
+ while (t->run) {
+ uint32_t reg;
+
*forcewake_mt = bit << 16 | bit;
- igt_assert(*forcewake_mt & bit);
+ reg = *forcewake_mt;
+ if (!(reg & bit)) {
+ igt_warn("Bit %u did not set! (val=%x)\n", t->bit, reg);
+ return (void *)-1;
+ }
*forcewake_mt = bit << 16;
- igt_assert((*forcewake_mt & bit) == 0);
+ reg = *forcewake_mt;
+ if (reg & bit) {
+ igt_warn("Bit %u did not clear! (val=%x)\n",
+t->bit, reg);
+ return (void *)-1;
+ }
}
return NULL;
@@ -121,13 +135,39 @@ static void *thread(void *arg)
#define MI_STORE_REGISTER_MEM (0x24<<23)
+static void *mmio_base;
+
+static void cleanup(int sig)
+{
+ volatile uint32_t *forcewake_mt =
+ (uint32_t *)((char *)mmio_base + FORCEWAKE_MT);
+ unsigned int bit;
+
+ for (bit = 2; bit < 16; bit++) {
+ uint32_t val = 1 << bit;
+ uint32_t reg;
+
+ *forcewake_mt = val << 16;
+ reg = *forcewake_mt;
+ if (reg & val)
+ igt_warn("Failed to restore bit %u! (val=%x)\n",
+bit, reg);
+ }
+}
+
igt_simple_main
{
struct thread t[16];
+ bool success = true;
int i;
+ mmio_base = igfx_get_mmio();
+
t[0].fd = drm_open_driver(DRIVER_INTEL);
- t[0].mmio = igfx_get_mmio();
+ t[0].run = true;
+ t[0].mmio = mmio_base;
+
+ igt_install_exit_handler(cleanup);
for (i = 2; i < 16; i++) {
t[i] = t[0];
@@ -201,4 +241,23 @@ igt_simple_main
usleep(1000);
}
+
+ for (i = 2; i < 16; i++)
+ t[i].run = false;
+
+ for (i = 2; i < 16; i++) {
+ void *threadret = NULL;
+ int ret;
+
+ ret = pthread_join(t[i].thread, &threadret);
+ if (ret) {
+ igt_warn("failed to join thread%u! (%d)\n", i, ret);
+ success = false;
+ } else if (threadret) {
+ igt_warn("thread%u failed! (%p)\n", i, threadret);
+ success = false;
+ }
+ }
+
+ igt_assert(success);
}
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/1] drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric
Quoting Sagar Arun Kamble (2018-03-01 16:45:45) > GuC load function is named intel_guc_fw_upload() and HuC load function is > named intel_huc_init_hw(). Make them consistent intel_*_fw_upload. Also > move HuC fw loading functions and declarations to separate files > intel_huc_fw.c|h like GuC. > > While at this, do below changes > 1. Update kernel-doc comment for intel_*_fw_upload() functions > 2. s/huc_ucode_xfer/huc_fw_xfer > 3. Introduce intel_huc_fw_init_early() > > v2: Changed patch to update HuC functions instead of changing > guc_fw_upload and update file structure. (Michal Wajdeczko) > > v3: Added SPDX License identifier to huc_fw.c|h. (Michal Wajdeczko) > > Signed-off-by: Sagar Arun Kamble > Cc: Michal Winiarski > Cc: Michal Wajdeczko > Cc: Chris Wilson > Cc: Anusha Srivatsa > Reviewed-by: Michal Wajdeczko Applied, thanks for the patch and review. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] please do *NOT* backport 9965db26ac05 ("drm/i915: Check for fused or unused pipes")
On Thu, 15 Feb 2018, Greg KH wrote:
> On Wed, Feb 14, 2018 at 06:22:56PM +0200, Jani Nikula wrote:
>>
>> Stable team,
>>
>> commit 9965db26ac05 ("drm/i915: Check for fused or unused pipes")
>>
>> with Cc: stable is broken, please do not backport.
>
> Ok, now dropped from my "to-apply" queue, thanks.
The fix has landed upstream, so feel free to backport both:
9965db26ac05 ("drm/i915: Check for fused or unused pipes")
72a6d72c2cd0 ("drm/i915/audio: fix check for av_enc_map overflow")
Thanks,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2] lib/igt_pm: Restore runtime pm state on test exit
On Wed, Feb 28, 2018 at 03:35:06PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Some tests (the ones which call igt_setup_runtime_pm and
> igt_pm_enable_audio_runtime_pm) change default system configuration and
> never restore it.
>
> The configured runtime suspend is aggressive and may influence behaviour
> of subsequent tests, so it is better to restore to previous values on test
> exit.
>
> This way system behaviour, with regards to a random sequence of executed
> tests, will be more consistent from one run to another.
>
> v2: Read failure means no runtime pm support so don't assert on it.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Imre Deak
> Reviewed-by: Chris Wilson # v1
Agreed about having a consistent expected state for each test, not sure
why we didn't restore these settings :/ Btw, I feel somewhat the same
about test results being affected by previous tests, but not sure if
anything should/can be done about that.
Acked-by: Imre Deak
Some nits below.
> ---
> lib/igt_pm.c | 122
> ---
> 1 file changed, 117 insertions(+), 5 deletions(-)
>
> diff --git a/lib/igt_pm.c b/lib/igt_pm.c
> index 5bf5b2e23cdc..04e2b89cca95 100644
> --- a/lib/igt_pm.c
> +++ b/lib/igt_pm.c
> @@ -63,6 +63,46 @@ enum {
> /* Remember to fix this if adding longer strings */
> #define MAX_POLICY_STRLENstrlen(MAX_PERFORMANCE_STR)
>
> +static char __igt_pm_audio_runtime_power_save[64];
> +static char __igt_pm_audio_runtime_control[64];
> +
> +static void __igt_pm_audio_runtime_exit_handler(int sig)
> +{
> + int fd;
> +
> + igt_debug("Restoring audio power management to '%s' and '%s'\n",
> + __igt_pm_audio_runtime_power_save,
> + __igt_pm_audio_runtime_control);
> +
> + fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_WRONLY);
> + if (fd < 0)
> + return;
> + if (write(fd, __igt_pm_audio_runtime_power_save,
> + strlen(__igt_pm_audio_runtime_power_save)) !=
> + strlen(__igt_pm_audio_runtime_power_save))
> + igt_warn("Failed to restore audio power_save to '%s'\n",
> + __igt_pm_audio_runtime_power_save);
> + close(fd);
> +
> + fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_WRONLY);
> + if (fd < 0)
> + return;
> + if (write(fd, __igt_pm_audio_runtime_control,
> + strlen(__igt_pm_audio_runtime_control)) !=
> + strlen(__igt_pm_audio_runtime_control))
> + igt_warn("Failed to restore audio control to '%s'\n",
> + __igt_pm_audio_runtime_control);
> + close(fd);
> +}
> +
> +static void strchomp(char *str)
> +{
> + int len = strlen(str);
> +
> + if (len && str[len - 1] == '\n')
> + str[len - 1] = 0;
> +}
> +
> /**
> * igt_pm_enable_audio_runtime_pm:
> *
> @@ -78,16 +118,32 @@ void igt_pm_enable_audio_runtime_pm(void)
> {
> int fd;
>
> - fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_WRONLY);
> + /* Check if already enabled. */
> + if (__igt_pm_audio_runtime_power_save[0])
> + return;
> +
> + fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_RDWR);
> if (fd >= 0) {
> + igt_assert(read(fd, __igt_pm_audio_runtime_power_save,
> + sizeof(__igt_pm_audio_runtime_power_save)) > 0);
> + strchomp(__igt_pm_audio_runtime_power_save);
> igt_assert_eq(write(fd, "1\n", 2), 2);
> + igt_install_exit_handler(__igt_pm_audio_runtime_exit_handler);
Read/install_handler/write would avoid a potential race with ^C. There's also
link_power_management_policy which is only restored during normal exit.
> close(fd);
> }
> - fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_WRONLY);
> + fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_RDWR);
> if (fd >= 0) {
> + igt_assert(read(fd, __igt_pm_audio_runtime_control,
> + sizeof(__igt_pm_audio_runtime_control)) > 0);
> + strchomp(__igt_pm_audio_runtime_control);
> igt_assert_eq(write(fd, "auto\n", 5), 5);
> close(fd);
> }
> +
> + igt_debug("Saved audio power management as '%s' and '%s'\n",
> + __igt_pm_audio_runtime_power_save,
> + __igt_pm_audio_runtime_control);
> +
> /* Give some time for it to react. */
> sleep(1);
> }
> @@ -238,6 +294,38 @@ void igt_pm_restore_sata_link_power_management(int8_t
> *pm_data)
> /* We just leak this on exit ... */
> int pm_status_fd = -1;
>
> +static char __igt_pm_runtime_autosuspend[64];
> +static char __igt_pm_runtime_control[64];
> +
> +static void __igt_pm_runtime_exit_handler(int sig)
> +{
> + int fd;
> +
> + igt_debug("Restoring runtime management to '%s' and '%s'\n",
> + __igt_pm_runtim
Re: [Intel-gfx] [PATCH] drm/i915: Check for I915_MODE_FLAG_INHERITED before drm_atomic_helper_check_modeset
On Thu, 01 Mar 2018, Lyude Paul wrote:
> Pushed with some small whitespace changes to make sparse happy, thanks!
Please do not push patches before they've passed CI. This patch gives [1]:
[ 281.167033] i915 :00:02.0: DP-2: EDID is invalid:
...
[ 282.806393] [drm:intel_enable_shared_dpll [i915]] *ERROR* DPLL 1 not locked
I don't know if this is caused by the patch, but since we get this in
the BAT round, the full IGT testing wasn't even run here.
BR,
Jani.
[1]
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8102/fi-skl-6700k2/igt@kms_chamel...@common-hpd-after-suspend.html
>
> On Wed, 2018-02-21 at 10:28 +0100, Maarten Lankhorst wrote:
>> Moving the check upwards will mean we we no longer have to add planes
>> and connectors manually, because everything is handled correctly by
>> drm_atomic_helper_check_modeset() as intended.
>>
>> Signed-off-by: Maarten Lankhorst
>> Cc: Lyude Paul
>> Cc: Daniel Vetter
>> Reviewed-by: Daniel Vetter
>> ---
>> drivers/gpu/drm/i915/intel_display.c | 20 +---
>> 1 file changed, 5 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 65be7af7f647..c5cc9022d545 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -11927,6 +11927,11 @@ static int intel_atomic_check(struct drm_device
>> *dev,
>> int ret, i;
>> bool any_ms = false;
>>
>> +/* Catch I915_MODE_FLAG_INHERITED */
>> +for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
>> crtc_state, i)
>> +if (crtc_state->mode.private_flags != old_crtc_state-
>> >mode.private_flags)
>> +crtc_state->mode_changed = true;
>> +
>> ret = drm_atomic_helper_check_modeset(dev, state);
>> if (ret)
>> return ret;
>> @@ -11935,10 +11940,6 @@ static int intel_atomic_check(struct drm_device
>> *dev,
>> struct intel_crtc_state *pipe_config =
>> to_intel_crtc_state(crtc_state);
>>
>> -/* Catch I915_MODE_FLAG_INHERITED */
>> -if (crtc_state->mode.private_flags != old_crtc_state-
>> >mode.private_flags)
>> -crtc_state->mode_changed = true;
>> -
>> if (!needs_modeset(crtc_state))
>> continue;
>>
>> @@ -11947,13 +11948,6 @@ static int intel_atomic_check(struct drm_device
>> *dev,
>> continue;
>> }
>>
>> -/* FIXME: For only active_changed we shouldn't need to do
>> any
>> - * state recomputation at all. */
>> -
>> -ret = drm_atomic_add_affected_connectors(state, crtc);
>> -if (ret)
>> -return ret;
>> -
>> ret = intel_modeset_pipe_config(crtc, pipe_config);
>> if (ret) {
>> intel_dump_pipe_config(to_intel_crtc(crtc),
>> @@ -11972,10 +11966,6 @@ static int intel_atomic_check(struct drm_device
>> *dev,
>> if (needs_modeset(crtc_state))
>> any_ms = true;
>>
>> -ret = drm_atomic_add_affected_planes(state, crtc);
>> -if (ret)
>> -return ret;
>> -
>> intel_dump_pipe_config(to_intel_crtc(crtc), pipe_config,
>> needs_modeset(crtc_state) ?
>> "[modeset]" : "[fastset]");
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 vs checkpatch
Quoting Rodrigo Vivi (2018-03-01 20:00:07) > On Thu, Mar 01, 2018 at 06:13:31PM +0200, Jani Nikula wrote: > > > > I went through the recent checkpatch reports, and here's my take. > > > > On Thu, 01 Mar 2018, Arkadiusz Hiler wrote: > > > 2. Which of the checkpatch checks we want to disabled for i915? > > > > I'd like to have these silenced: > > > > CHECK: No space is necessary after a cast > > WARNING: line over 80 characters > > WARNING: quoted string split across lines > > > > I'd prefer we conform to the last two too, but there's just too much > > noise and too many cases where we explicitly should ignore them. > > > > For the time being, I think we may have to silence these ones too, but > > I'd like us to discuss enforcing them: > > > > CHECK: Prefer kernel type 'u16' over 'uint16_t' > > CHECK: Prefer kernel type 'u32' over 'uint32_t' > > CHECK: Prefer kernel type 'u64' over 'uint64_t' > > CHECK: Prefer kernel type 'u8' over 'uint8_t' > > CHECK: Prefer using the BIT macro > > > > The BIT macros is one that I'd consider accepting a one-time conversion > > of i915_reg.h and after that use it exclusively. But up to debate. > > For this one I just wonder if we would need to do a massive > change before. Because it would get ugly to have mixed cases. Yep, the mixed cases are bit tough to automatically enforce. So the transitional phase will always be troublesome, and trying to make that shorter makes some sense to me. Traditionally we've avoided mass changes just for the changes, but we have to assess the value of doing it against what we get. That is getting automatic enforcement, once we've converted over. We're not that far off the mark with u(32|16|8) vs uint(32|16|8)_t: i915$ git grep -E "uint(32|16|8)_t" | wc -l 852 i915$ git grep -E "u(32|16|8)" | wc -l 3857 I don't consider that undoable. BIT() is in the minority at the moment, so it might benefit even more as people often cargo-cult the programming style from other places in the code. I think it might be worthy doing these two changes to get the automatic enforemend and avoid the codebase staying in limbo. Machine overlords are way better at enforcing any code checks than us humans. Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v3] lib/igt_pm: Restore runtime pm state on test exit
From: Tvrtko Ursulin
Some tests (the ones which call igt_setup_runtime_pm and
igt_pm_enable_audio_runtime_pm) change default system configuration and
never restore it.
The configured runtime suspend is aggressive and may influence behaviour
of subsequent tests, so it is better to restore to previous values on test
exit.
This way system behaviour, with regards to a random sequence of executed
tests, will be more consistent from one run to another.
v2: Read failure means no runtime pm support so don't assert on it.
v3: Install exit handler before the write to close the Ctrl^C race. (Imre)
Signed-off-by: Tvrtko Ursulin
Cc: Imre Deak
Reviewed-by: Chris Wilson # v2
Acked-by: Imre Deak
---
lib/igt_pm.c | 122 ---
1 file changed, 117 insertions(+), 5 deletions(-)
diff --git a/lib/igt_pm.c b/lib/igt_pm.c
index 5bf5b2e23cdc..8ac132269d79 100644
--- a/lib/igt_pm.c
+++ b/lib/igt_pm.c
@@ -63,6 +63,46 @@ enum {
/* Remember to fix this if adding longer strings */
#define MAX_POLICY_STRLEN strlen(MAX_PERFORMANCE_STR)
+static char __igt_pm_audio_runtime_power_save[64];
+static char __igt_pm_audio_runtime_control[64];
+
+static void __igt_pm_audio_runtime_exit_handler(int sig)
+{
+ int fd;
+
+ igt_debug("Restoring audio power management to '%s' and '%s'\n",
+ __igt_pm_audio_runtime_power_save,
+ __igt_pm_audio_runtime_control);
+
+ fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_WRONLY);
+ if (fd < 0)
+ return;
+ if (write(fd, __igt_pm_audio_runtime_power_save,
+ strlen(__igt_pm_audio_runtime_power_save)) !=
+ strlen(__igt_pm_audio_runtime_power_save))
+ igt_warn("Failed to restore audio power_save to '%s'\n",
+__igt_pm_audio_runtime_power_save);
+ close(fd);
+
+ fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_WRONLY);
+ if (fd < 0)
+ return;
+ if (write(fd, __igt_pm_audio_runtime_control,
+ strlen(__igt_pm_audio_runtime_control)) !=
+ strlen(__igt_pm_audio_runtime_control))
+ igt_warn("Failed to restore audio control to '%s'\n",
+__igt_pm_audio_runtime_control);
+ close(fd);
+}
+
+static void strchomp(char *str)
+{
+ int len = strlen(str);
+
+ if (len && str[len - 1] == '\n')
+ str[len - 1] = 0;
+}
+
/**
* igt_pm_enable_audio_runtime_pm:
*
@@ -78,16 +118,32 @@ void igt_pm_enable_audio_runtime_pm(void)
{
int fd;
- fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_WRONLY);
+ /* Check if already enabled. */
+ if (__igt_pm_audio_runtime_power_save[0])
+ return;
+
+ fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_RDWR);
if (fd >= 0) {
+ igt_assert(read(fd, __igt_pm_audio_runtime_power_save,
+ sizeof(__igt_pm_audio_runtime_power_save)) > 0);
+ strchomp(__igt_pm_audio_runtime_power_save);
+ igt_install_exit_handler(__igt_pm_audio_runtime_exit_handler);
igt_assert_eq(write(fd, "1\n", 2), 2);
close(fd);
}
- fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_WRONLY);
+ fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_RDWR);
if (fd >= 0) {
+ igt_assert(read(fd, __igt_pm_audio_runtime_control,
+ sizeof(__igt_pm_audio_runtime_control)) > 0);
+ strchomp(__igt_pm_audio_runtime_control);
igt_assert_eq(write(fd, "auto\n", 5), 5);
close(fd);
}
+
+ igt_debug("Saved audio power management as '%s' and '%s'\n",
+ __igt_pm_audio_runtime_power_save,
+ __igt_pm_audio_runtime_control);
+
/* Give some time for it to react. */
sleep(1);
}
@@ -238,6 +294,38 @@ void igt_pm_restore_sata_link_power_management(int8_t
*pm_data)
/* We just leak this on exit ... */
int pm_status_fd = -1;
+static char __igt_pm_runtime_autosuspend[64];
+static char __igt_pm_runtime_control[64];
+
+static void __igt_pm_runtime_exit_handler(int sig)
+{
+ int fd;
+
+ igt_debug("Restoring runtime management to '%s' and '%s'\n",
+ __igt_pm_runtime_autosuspend,
+ __igt_pm_runtime_control);
+
+ fd = open(POWER_DIR "/autosuspend_delay_ms", O_WRONLY);
+ if (fd < 0)
+ return;
+ if (write(fd, __igt_pm_runtime_autosuspend,
+ strlen(__igt_pm_runtime_autosuspend)) !=
+ strlen(__igt_pm_runtime_autosuspend))
+ igt_warn("Failed to restore runtime pm autosuspend delay to
'%s'\n",
+__igt_pm_runtime_autosuspend);
+ close(fd);
+
+ fd = open(POWER_DIR "/control", O_WRONLY);
+
[Intel-gfx] [PATCH 07/14] drm/i915: Use the same vswing->max_preemph mapping on HSW/BDW as on SKL+
From: Ville Syrjälä
All DDI platforms support the full set of preemph settings for each
supported vswing, so let's use the same code for them. We'll also move
the code into intel_ddi.c so that it sits closer to the actual buf trans
tables.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 20
drivers/gpu/drm/i915/intel_dp.c | 30 --
drivers/gpu/drm/i915/intel_drv.h | 2 ++
3 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 8ca376aca8bd..a56a4db6dc38 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1931,6 +1931,26 @@ u8 intel_ddi_dp_voltage_max(struct intel_encoder
*encoder)
DP_TRAIN_VOLTAGE_SWING_MASK;
}
+/*
+ * We assume that the full set of pre-emphasis values can be
+ * used on all DDI platforms. Should that change we need to
+ * rethink this code.
+ */
+u8 intel_ddi_dp_pre_emphasis_max(struct intel_encoder *encoder, u8
voltage_swing)
+{
+ switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
+ case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
+ return DP_TRAIN_PRE_EMPH_LEVEL_3;
+ case DP_TRAIN_VOLTAGE_SWING_LEVEL_1:
+ return DP_TRAIN_PRE_EMPH_LEVEL_2;
+ case DP_TRAIN_VOLTAGE_SWING_LEVEL_2:
+ return DP_TRAIN_PRE_EMPH_LEVEL_1;
+ case DP_TRAIN_VOLTAGE_SWING_LEVEL_3:
+ default:
+ return DP_TRAIN_PRE_EMPH_LEVEL_0;
+ }
+}
+
static void cnl_ddi_vswing_program(struct intel_encoder *encoder,
int level, enum intel_output_type type)
{
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f1fabd5d..642ae298df07 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3225,33 +3225,11 @@ uint8_t
intel_dp_pre_emphasis_max(struct intel_dp *intel_dp, uint8_t voltage_swing)
{
struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
- enum port port = dp_to_dig_port(intel_dp)->base.port;
+ struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
+ enum port port = encoder->port;
- if (INTEL_GEN(dev_priv) >= 9) {
- switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
- return DP_TRAIN_PRE_EMPH_LEVEL_3;
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_1:
- return DP_TRAIN_PRE_EMPH_LEVEL_2;
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_2:
- return DP_TRAIN_PRE_EMPH_LEVEL_1;
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_3:
- return DP_TRAIN_PRE_EMPH_LEVEL_0;
- default:
- return DP_TRAIN_PRE_EMPH_LEVEL_0;
- }
- } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
- switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
- return DP_TRAIN_PRE_EMPH_LEVEL_3;
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_1:
- return DP_TRAIN_PRE_EMPH_LEVEL_2;
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_2:
- return DP_TRAIN_PRE_EMPH_LEVEL_1;
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_3:
- default:
- return DP_TRAIN_PRE_EMPH_LEVEL_0;
- }
+ if (HAS_DDI(dev_priv)) {
+ return intel_ddi_dp_pre_emphasis_max(encoder, voltage_swing);
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 09a1b968ac9c..d783ecfef46d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1388,6 +1388,8 @@ void intel_ddi_compute_min_voltage_level(struct
drm_i915_private *dev_priv,
u32 bxt_signal_levels(struct intel_dp *intel_dp);
uint32_t ddi_signal_levels(struct intel_dp *intel_dp);
u8 intel_ddi_dp_voltage_max(struct intel_encoder *encoder);
+u8 intel_ddi_dp_pre_emphasis_max(struct intel_encoder *encoder,
+u8 voltage_swing);
int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
bool enable);
--
2.13.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/14] drm/i915: Clean up DVO pipe select bits
From: Ville Syrjälä
Parametrize the DVO pipe select bits.
For consistency with the new way of doing things, let's read out the
pipe select bits even when the port is disable, even though we don't
need that behaviour for asserts in this case.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 4 +++-
drivers/gpu/drm/i915/intel_dvo.c | 13 -
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fadd0a285efa..d7dc03bd0b4f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4423,7 +4423,9 @@ enum {
#define _DVOC 0x61160
#define DVOC _MMIO(_DVOC)
#define DVO_ENABLE (1 << 31)
-#define DVO_PIPE_B_SELECT(1 << 30)
+#define DVO_PIPE_SEL(pipe) ((pipe) << 30)
+#define DVO_PIPE_SEL_MASK(1 << 30)
+#define DVO_PIPE_SEL_SHIFT 30
#define DVO_PIPE_STALL_UNUSED(0 << 28)
#define DVO_PIPE_STALL (1 << 28)
#define DVO_PIPE_STALL_TV(2 << 28)
diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index eb0c559b2715..a86f0398570f 100644
--- a/drivers/gpu/drm/i915/intel_dvo.c
+++ b/drivers/gpu/drm/i915/intel_dvo.c
@@ -137,19 +137,15 @@ static bool intel_dvo_connector_get_hw_state(struct
intel_connector *connector)
static bool intel_dvo_get_hw_state(struct intel_encoder *encoder,
enum pipe *pipe)
{
- struct drm_device *dev = encoder->base.dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_dvo *intel_dvo = enc_to_dvo(encoder);
u32 tmp;
tmp = I915_READ(intel_dvo->dev.dvo_reg);
- if (!(tmp & DVO_ENABLE))
- return false;
-
- *pipe = PORT_TO_PIPE(tmp);
+ *pipe = (tmp & DVO_PIPE_SEL_MASK) >> DVO_PIPE_SEL_SHIFT;
- return true;
+ return tmp & DVO_ENABLE;
}
static void intel_dvo_get_config(struct intel_encoder *encoder,
@@ -276,8 +272,7 @@ static void intel_dvo_pre_enable(struct intel_encoder
*encoder,
dvo_val |= DVO_DATA_ORDER_FP | DVO_BORDER_ENABLE |
DVO_BLANK_ACTIVE_HIGH;
- if (pipe == 1)
- dvo_val |= DVO_PIPE_B_SELECT;
+ dvo_val |= DVO_PIPE_SEL(pipe);
dvo_val |= DVO_PIPE_STALL;
if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
dvo_val |= DVO_HSYNC_ACTIVE_HIGH;
--
2.13.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/14] drm/i915: Clean up TV pipe select bits
From: Ville Syrjälä
Parametrize the TV pipe select bits.
For consistency with the new way of doing things, let's read out the
pipe select bits even when the port is disable, even though we don't
need that behaviour for asserts in this case.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 4 +++-
drivers/gpu/drm/i915/intel_tv.c | 18 +-
2 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0917fcbd618d..fadd0a285efa 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4762,7 +4762,9 @@ enum {
/* Enables the TV encoder */
# define TV_ENC_ENABLE (1 << 31)
/* Sources the TV encoder input from pipe B instead of A. */
-# define TV_ENC_PIPEB_SELECT (1 << 30)
+# define TV_ENC_PIPE_SEL(pipe) ((pipe) << 30)
+# define TV_ENC_PIPE_SEL_MASK (1 << 30)
+# define TV_ENC_PIPE_SEL_SHIFT 30
/* Outputs composite video (DAC A only) */
# define TV_ENC_OUTPUT_COMPOSITE (0 << 28)
/* Outputs SVideo video (DAC B/C) */
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 885fc3809f7f..24caf340a7a5 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -798,16 +798,12 @@ static struct intel_tv *intel_attached_tv(struct
drm_connector *connector)
static bool
intel_tv_get_hw_state(struct intel_encoder *encoder, enum pipe *pipe)
{
- struct drm_device *dev = encoder->base.dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 tmp = I915_READ(TV_CTL);
- if (!(tmp & TV_ENC_ENABLE))
- return false;
+ *pipe = (tmp & TV_ENC_PIPE_SEL_MASK) >> TV_ENC_PIPE_SEL_SHIFT;
- *pipe = PORT_TO_PIPE(tmp);
-
- return true;
+ return tmp & TV_ENC_ENABLE;
}
static void
@@ -1024,8 +1020,7 @@ static void intel_tv_pre_enable(struct intel_encoder
*encoder,
break;
}
- if (intel_crtc->pipe == 1)
- tv_ctl |= TV_ENC_PIPEB_SELECT;
+ tv_ctl |= TV_ENC_PIPE_SEL(intel_crtc->pipe);
tv_ctl |= tv_mode->oversample;
if (tv_mode->progressive)
@@ -1151,10 +1146,7 @@ intel_tv_detect_type(struct intel_tv *intel_tv,
/* Poll for TV detection */
tv_ctl &= ~(TV_ENC_ENABLE | TV_TEST_MODE_MASK);
tv_ctl |= TV_TEST_MODE_MONITOR_DETECT;
- if (intel_crtc->pipe == 1)
- tv_ctl |= TV_ENC_PIPEB_SELECT;
- else
- tv_ctl &= ~TV_ENC_PIPEB_SELECT;
+ tv_ctl |= TV_ENC_PIPE_SEL(intel_crtc->pipe);
tv_dac &= ~(TVDAC_SENSE_MASK | DAC_A_MASK | DAC_B_MASK | DAC_C_MASK);
tv_dac |= (TVDAC_STATE_CHG_EN |
--
2.13.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/14] drm/i915: Use intel_ddi_dp_voltage_max() for HSW/BDW too
From: Ville Syrjälä
Use intel_ddi_dp_voltage_max() for HSW/BDW too instead of letting these
fall through the if ladder in a weird way. This function will look at
the actual buf trans tables we have for HSW/BDW to determine the max
vswing level.
It looks to me like the current code leads HSW port A down the IVB port
A path, HSW port B+ and BDW fall through to the very end. Both cases do
result in the correct max vswing level 2, but it's very hard to see that
from the code.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index aba2f45819d8..f1fabd5d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3206,12 +3206,12 @@ uint8_t
intel_dp_voltage_max(struct intel_dp *intel_dp)
{
struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
- enum port port = dp_to_dig_port(intel_dp)->base.port;
+ struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
+ enum port port = encoder->port;
- if (INTEL_GEN(dev_priv) >= 9) {
- struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
+ if (HAS_DDI(dev_priv))
return intel_ddi_dp_voltage_max(encoder);
- } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
+ else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
return DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
else if (IS_GEN7(dev_priv) && port == PORT_A)
return DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
--
2.13.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/14] drm/i915: Clean up LVDS pipe select bits
From: Ville Syrjälä
Clean up the LVDS pipe select bits. To make the whole situation a bit
less ugly we'll start to share the same code between .get_hw_state()
and the port state asserts.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 9 --
drivers/gpu/drm/i915/intel_display.c | 35 ++-
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_lvds.c| 54 +++-
4 files changed, 44 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f573095d60c2..e993eec97c98 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4458,9 +4458,12 @@ enum {
*/
#define LVDS_PORT_EN (1 << 31)
/* Selects pipe B for LVDS data. Must be set on pre-965. */
-#define LVDS_PIPEB_SELECT(1 << 30)
-#define LVDS_PIPE_MASK (1 << 30)
-#define LVDS_PIPE(pipe) ((pipe) << 30)
+#define LVDS_PIPE_SEL(pipe) ((pipe) << 30)
+#define LVDS_PIPE_SEL_MASK (1 << 30)
+#define LVDS_PIPE_SEL_SHIFT 30
+#define LVDS_PIPE_SEL_CPT(pipe) ((pipe) << 29)
+#define LVDS_PIPE_SEL_MASK_CPT (3 << 30)
+#define LVDS_PIPE_SEL_SHIFT_CPT 29
/* LVDS dithering flag on 965/g4x platform */
#define LVDS_ENABLE_DITHER (1 << 25)
/* LVDS sync polarity flags. Set to invert (i.e. negative) */
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 545d89152e9b..f1f164a20b3f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1171,9 +1171,9 @@ void assert_panel_unlocked(struct drm_i915_private
*dev_priv, enum pipe pipe)
pp_reg = PP_CONTROL(0);
port_sel = I915_READ(PP_ON_DELAYS(0)) & PANEL_PORT_SELECT_MASK;
- if (port_sel == PANEL_PORT_SELECT_LVDS &&
- I915_READ(PCH_LVDS) & LVDS_PIPEB_SELECT)
- panel_pipe = PIPE_B;
+ if (port_sel == PANEL_PORT_SELECT_LVDS) {
+ intel_lvds_port_enabled(dev_priv, PCH_LVDS,
&panel_pipe);
+ }
/* XXX: else fix for eDP */
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
/* presumably write lock depends on pipe, not port select */
@@ -1181,8 +1181,7 @@ void assert_panel_unlocked(struct drm_i915_private
*dev_priv, enum pipe pipe)
panel_pipe = pipe;
} else {
pp_reg = PP_CONTROL(0);
- if (I915_READ(LVDS) & LVDS_PIPEB_SELECT)
- panel_pipe = PIPE_B;
+ intel_lvds_port_enabled(dev_priv, LVDS, &panel_pipe);
}
val = I915_READ(pp_reg);
@@ -1301,22 +1300,6 @@ static bool hdmi_pipe_enabled(struct drm_i915_private
*dev_priv,
return true;
}
-static bool lvds_pipe_enabled(struct drm_i915_private *dev_priv,
- enum pipe pipe, u32 val)
-{
- if ((val & LVDS_PORT_EN) == 0)
- return false;
-
- if (HAS_PCH_CPT(dev_priv)) {
- if ((val & PORT_TRANS_SEL_MASK) != PORT_TRANS_SEL_CPT(pipe))
- return false;
- } else {
- if ((val & LVDS_PIPE_MASK) != LVDS_PIPE(pipe))
- return false;
- }
- return true;
-}
-
static void assert_pch_dp_disabled(struct drm_i915_private *dev_priv,
enum pipe pipe, i915_reg_t reg,
u32 port_sel)
@@ -1348,7 +1331,6 @@ static void assert_pch_ports_disabled(struct
drm_i915_private *dev_priv,
enum pipe pipe)
{
enum pipe port_pipe;
- u32 val;
assert_pch_dp_disabled(dev_priv, pipe, PCH_DP_B, TRANS_DP_PORT_SEL_B);
assert_pch_dp_disabled(dev_priv, pipe, PCH_DP_C, TRANS_DP_PORT_SEL_C);
@@ -1359,10 +1341,10 @@ static void assert_pch_ports_disabled(struct
drm_i915_private *dev_priv,
"PCH VGA enabled on transcoder %c, should be
disabled\n",
pipe_name(pipe));
- val = I915_READ(PCH_LVDS);
- I915_STATE_WARN(lvds_pipe_enabled(dev_priv, pipe, val),
-"PCH LVDS enabled on transcoder %c, should be disabled\n",
-pipe_name(pipe));
+ I915_STATE_WARN(intel_lvds_port_enabled(dev_priv, PCH_LVDS, &port_pipe)
&&
+ port_pipe == pipe,
+ "PCH LVDS enabled on transcoder %c, should be
disabled\n",
+ pipe_name(pipe));
assert_pch_hdmi_disabled(dev_priv, pipe, PCH_HDMIB);
assert_pch_hdmi_disabled(dev_priv, pipe, PCH_HDMIC);
@@ -1405,7 +1387,6 @@ static void vlv_enable_pll(struct intel_crtc *crtc,
POSTING_READ(DPLL_MD(pipe));
}
-
static void _chv_enable_pll(struct intel_crtc *crtc,
[Intel-gfx] [PATCH 01/14] drm/i915: Clean up ADPA pipe select bits
From: Ville Syrjälä
Clean up the ADPA pipe select bits. To make the whole situation a bit
less ugly we'll start to share the same code between .get_hw_state()
and the port state asserts.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 11 +-
drivers/gpu/drm/i915/intel_crt.c | 40 ++--
drivers/gpu/drm/i915/intel_display.c | 24 +-
drivers/gpu/drm/i915/intel_drv.h | 2 ++
4 files changed, 33 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 95a2e51ecbb0..f573095d60c2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4199,11 +4199,12 @@ enum {
#define ADPA_DAC_ENABLE (1<<31)
#define ADPA_DAC_DISABLE 0
-#define ADPA_PIPE_SELECT_MASK(1<<30)
-#define ADPA_PIPE_A_SELECT 0
-#define ADPA_PIPE_B_SELECT (1<<30)
-#define ADPA_PIPE_SELECT(pipe) ((pipe) << 30)
-/* CPT uses bits 29:30 for pch transcoder select */
+#define ADPA_PIPE_SEL_MASK (1<<30)
+#define ADPA_PIPE_SEL_SHIFT 30
+#define ADPA_PIPE_SEL(pipe) ((pipe) << 30)
+#define ADPA_PIPE_SEL_MASK_CPT (3<<29)
+#define ADPA_PIPE_SEL_SHIFT_CPT 29
+#define ADPA_PIPE_SEL_CPT(pipe) ((pipe) << 29)
#define ADPA_CRT_HOTPLUG_MASK 0x03ff /* bit 25-16 */
#define ADPA_CRT_HOTPLUG_MONITOR_NONE (0<<24)
#define ADPA_CRT_HOTPLUG_MONITOR_MASK (3<<24)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 391dd69ae0a4..9af44608 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -63,33 +63,35 @@ static struct intel_crt *intel_attached_crt(struct
drm_connector *connector)
return intel_encoder_to_crt(intel_attached_encoder(connector));
}
+bool intel_crt_port_enabled(struct drm_i915_private *dev_priv,
+ i915_reg_t adpa_reg, enum pipe *pipe)
+{
+ u32 val;
+
+ val = I915_READ(adpa_reg);
+
+ /* asserts want to know the pipe even if the port is disabled */
+ if (HAS_PCH_CPT(dev_priv))
+ *pipe = (val & ADPA_PIPE_SEL_MASK_CPT) >>
ADPA_PIPE_SEL_SHIFT_CPT;
+ else
+ *pipe = (val & ADPA_PIPE_SEL_MASK) >> ADPA_PIPE_SEL_SHIFT;
+
+ return val & ADPA_DAC_ENABLE;
+}
+
static bool intel_crt_get_hw_state(struct intel_encoder *encoder,
enum pipe *pipe)
{
- struct drm_device *dev = encoder->base.dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_crt *crt = intel_encoder_to_crt(encoder);
- u32 tmp;
bool ret;
if (!intel_display_power_get_if_enabled(dev_priv,
encoder->power_domain))
return false;
- ret = false;
-
- tmp = I915_READ(crt->adpa_reg);
-
- if (!(tmp & ADPA_DAC_ENABLE))
- goto out;
+ ret = intel_crt_port_enabled(dev_priv, crt->adpa_reg, pipe);
- if (HAS_PCH_CPT(dev_priv))
- *pipe = PORT_TO_PIPE_CPT(tmp);
- else
- *pipe = PORT_TO_PIPE(tmp);
-
- ret = true;
-out:
intel_display_power_put(dev_priv, encoder->power_domain);
return ret;
@@ -168,11 +170,9 @@ static void intel_crt_set_dpms(struct intel_encoder
*encoder,
if (HAS_PCH_LPT(dev_priv))
; /* Those bits don't exist here */
else if (HAS_PCH_CPT(dev_priv))
- adpa |= PORT_TRANS_SEL_CPT(crtc->pipe);
- else if (crtc->pipe == 0)
- adpa |= ADPA_PIPE_A_SELECT;
+ adpa |= ADPA_PIPE_SEL_CPT(crtc->pipe);
else
- adpa |= ADPA_PIPE_B_SELECT;
+ adpa |= ADPA_PIPE_SEL(crtc->pipe);
if (!HAS_PCH_SPLIT(dev_priv))
I915_WRITE(BCLRPAT(crtc->pipe), 0);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 740a918ee578..545d89152e9b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1317,21 +1317,6 @@ static bool lvds_pipe_enabled(struct drm_i915_private
*dev_priv,
return true;
}
-static bool adpa_pipe_enabled(struct drm_i915_private *dev_priv,
- enum pipe pipe, u32 val)
-{
- if ((val & ADPA_DAC_ENABLE) == 0)
- return false;
- if (HAS_PCH_CPT(dev_priv)) {
- if ((val & PORT_TRANS_SEL_MASK) != PORT_TRANS_SEL_CPT(pipe))
- return false;
- } else {
- if ((val & ADPA_PIPE_SELECT_MASK) != ADPA_PIPE_SELECT(pipe))
- return false;
- }
- return true;
-}
-
static void assert_pch_dp_disabled(struct drm_i915_private *dev_priv,
enum pipe pipe, i915_reg_t reg,
[Intel-gfx] [PATCH 03/14] drm/i915: Clean up SDVO pipe select bits
From: Ville Syrjälä
Clean up the SDVO pipe select bits. To make the whole situation a bit
less ugly we'll start to share the same code between .get_hw_state()
and the port state asserts.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 4 +++-
drivers/gpu/drm/i915/intel_display.c | 46 +---
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_hdmi.c| 25
drivers/gpu/drm/i915/intel_sdvo.c| 38 ++---
5 files changed, 49 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e993eec97c98..0917fcbd618d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4365,7 +4365,7 @@ enum {
#define SDVO_ENABLE (1 << 31)
#define SDVO_PIPE_SEL(pipe) ((pipe) << 30)
#define SDVO_PIPE_SEL_MASK (1 << 30)
-#define SDVO_PIPE_B_SELECT (1 << 30)
+#define SDVO_PIPE_SEL_SHIFT 30
#define SDVO_STALL_SELECT(1 << 29)
#define SDVO_INTERRUPT_ENABLE(1 << 26)
/*
@@ -4407,10 +4407,12 @@ enum {
/* Gen 6 (CPT) SDVO/HDMI bits: */
#define SDVO_PIPE_SEL_CPT(pipe) ((pipe) << 29)
#define SDVO_PIPE_SEL_MASK_CPT (3 << 29)
+#define SDVO_PIPE_SEL_SHIFT_CPT 29
/* CHV SDVO/HDMI bits: */
#define SDVO_PIPE_SEL_CHV(pipe) ((pipe) << 24)
#define SDVO_PIPE_SEL_MASK_CHV (3 << 24)
+#define SDVO_PIPE_SEL_SHIFT_CHV 24
/* DVO port control */
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f1f164a20b3f..26f8f1e741f7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1281,25 +1281,6 @@ static bool dp_pipe_enabled(struct drm_i915_private
*dev_priv,
return true;
}
-static bool hdmi_pipe_enabled(struct drm_i915_private *dev_priv,
- enum pipe pipe, u32 val)
-{
- if ((val & SDVO_ENABLE) == 0)
- return false;
-
- if (HAS_PCH_CPT(dev_priv)) {
- if ((val & SDVO_PIPE_SEL_MASK_CPT) != SDVO_PIPE_SEL_CPT(pipe))
- return false;
- } else if (IS_CHERRYVIEW(dev_priv)) {
- if ((val & SDVO_PIPE_SEL_MASK_CHV) != SDVO_PIPE_SEL_CHV(pipe))
- return false;
- } else {
- if ((val & SDVO_PIPE_SEL_MASK) != SDVO_PIPE_SEL(pipe))
- return false;
- }
- return true;
-}
-
static void assert_pch_dp_disabled(struct drm_i915_private *dev_priv,
enum pipe pipe, i915_reg_t reg,
u32 port_sel)
@@ -1315,16 +1296,21 @@ static void assert_pch_dp_disabled(struct
drm_i915_private *dev_priv,
}
static void assert_pch_hdmi_disabled(struct drm_i915_private *dev_priv,
-enum pipe pipe, i915_reg_t reg)
+enum pipe pipe, enum port port,
+i915_reg_t hdmi_reg)
{
- u32 val = I915_READ(reg);
- I915_STATE_WARN(hdmi_pipe_enabled(dev_priv, pipe, val),
-"PCH HDMI (0x%08x) enabled on transcoder %c, should be disabled\n",
-i915_mmio_reg_offset(reg), pipe_name(pipe));
+ enum pipe port_pipe;
+ bool state;
+
+ state = intel_sdvo_port_enabled(dev_priv, hdmi_reg, &port_pipe);
+
+ I915_STATE_WARN(state && port_pipe == pipe,
+ "PCH HDMI %c enabled on transcoder %c, should be
disabled\n",
+ port_name(port), pipe_name(pipe));
- I915_STATE_WARN(HAS_PCH_IBX(dev_priv) && (val & SDVO_ENABLE) == 0
-&& (val & SDVO_PIPE_B_SELECT),
-"IBX PCH hdmi port still using transcoder B\n");
+ I915_STATE_WARN(HAS_PCH_IBX(dev_priv) && !state && port_pipe == PIPE_B,
+ "IBX PCH HDMI %c still using transcoder B\n",
+ port_name(port));
}
static void assert_pch_ports_disabled(struct drm_i915_private *dev_priv,
@@ -1346,9 +1332,9 @@ static void assert_pch_ports_disabled(struct
drm_i915_private *dev_priv,
"PCH LVDS enabled on transcoder %c, should be
disabled\n",
pipe_name(pipe));
- assert_pch_hdmi_disabled(dev_priv, pipe, PCH_HDMIB);
- assert_pch_hdmi_disabled(dev_priv, pipe, PCH_HDMIC);
- assert_pch_hdmi_disabled(dev_priv, pipe, PCH_HDMID);
+ assert_pch_hdmi_disabled(dev_priv, pipe, PORT_B, PCH_HDMIB);
+ assert_pch_hdmi_disabled(dev_priv, pipe, PORT_C, PCH_HDMIC);
+ assert_pch_hdmi_disabled(dev_priv, pipe, PORT_D, PCH_HDMID);
}
static void _vlv_enable_pll(struct intel_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/
[Intel-gfx] [PATCH 00/14] drm/i915: Clean up the port pipe select bits
From: Ville Syrjälä A bit of an effort to rid outselves of PORT_TO_PIPE() & co. The idea with those macros was to share them between all the port registers, but since not all port registers follow the same bit layout they're kinda just making it harder to see what goes where. So I decided to just define the pipe select bits individually for each register. There's also a bit of cleanup on the DDI vswing/pre-emphasis stuff, and elimination of the pre-atomic intel_trans_dp_port_sel(). I've given this the standard smoke test on ILK, IVB and CHV. Entire pile available here: git://github.com/vsyrjala/linux.git port_sel_cleanup Ville Syrjälä (14): drm/i915: Clean up ADPA pipe select bits drm/i915: Clean up LVDS pipe select bits drm/i915: Clean up SDVO pipe select bits drm/i915: Clean up TV pipe select bits drm/i915: Clean up DVO pipe select bits drm/i915: Use intel_ddi_dp_voltage_max() for HSW/BDW too drm/i915: Use the same vswing->max_preemph mapping on HSW/BDW as on SKL+ drm/i915: Check for IVB instead of gen7 when we think about IVB CPU eDP drm/i915: Move intel_ddi_get_crtc_new_encoder() out from ddi code drm/i915: Parametrize TRANS_DP_PORT_SEL drm/i915: Nuke intel_trans_dp_port_sel() drm/i915: Clean up DP pipe select bits drm/i915: Allow eDP on port C in theory drm/i915: Implement the missing bits of assert_panel_unlocked() drivers/gpu/drm/i915/i915_reg.h | 64 +- drivers/gpu/drm/i915/intel_crt.c | 40 +++--- drivers/gpu/drm/i915/intel_ddi.c | 49 +++- drivers/gpu/drm/i915/intel_display.c | 229 ++- drivers/gpu/drm/i915/intel_dp.c | 170 +- drivers/gpu/drm/i915/intel_drv.h | 13 +- drivers/gpu/drm/i915/intel_dvo.c | 13 +- drivers/gpu/drm/i915/intel_hdmi.c| 25 +--- drivers/gpu/drm/i915/intel_lvds.c| 54 + drivers/gpu/drm/i915/intel_sdvo.c| 38 +++--- drivers/gpu/drm/i915/intel_tv.c | 18 +-- 11 files changed, 327 insertions(+), 386 deletions(-) -- 2.13.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/14] drm/i915: Parametrize TRANS_DP_PORT_SEL
From: Ville Syrjälä
Parametrize the TRANS_DP_PORT_SEL macros.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 8 +++-
drivers/gpu/drm/i915/intel_display.c | 23 +++
2 files changed, 10 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d7dc03bd0b4f..f1460fd27881 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7914,11 +7914,9 @@ enum {
#define _TRANS_DP_CTL_C0xe2300
#define TRANS_DP_CTL(pipe) _MMIO_PIPE(pipe, _TRANS_DP_CTL_A,
_TRANS_DP_CTL_B)
#define TRANS_DP_OUTPUT_ENABLE(1<<31)
-#define TRANS_DP_PORT_SEL_B (0<<29)
-#define TRANS_DP_PORT_SEL_C (1<<29)
-#define TRANS_DP_PORT_SEL_D (2<<29)
-#define TRANS_DP_PORT_SEL_NONE(3<<29)
-#define TRANS_DP_PORT_SEL_MASK(3<<29)
+#define TRANS_DP_PORT_SEL(port) (((port) - PORT_B) << 29)
+#define TRANS_DP_PORT_SEL_NONE(3 << 29)
+#define TRANS_DP_PORT_SEL_MASK(3 << 29)
#define TRANS_DP_PIPE_TO_PORT(val)val) & TRANS_DP_PORT_SEL_MASK) >>
29) + PORT_B)
#define TRANS_DP_AUDIO_ONLY (1<<26)
#define TRANS_DP_ENH_FRAMING (1<<18)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 239059493243..e8bedf09d892 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1318,9 +1318,9 @@ static void assert_pch_ports_disabled(struct
drm_i915_private *dev_priv,
{
enum pipe port_pipe;
- assert_pch_dp_disabled(dev_priv, pipe, PCH_DP_B, TRANS_DP_PORT_SEL_B);
- assert_pch_dp_disabled(dev_priv, pipe, PCH_DP_C, TRANS_DP_PORT_SEL_C);
- assert_pch_dp_disabled(dev_priv, pipe, PCH_DP_D, TRANS_DP_PORT_SEL_D);
+ assert_pch_dp_disabled(dev_priv, pipe, PCH_DP_B,
TRANS_DP_PORT_SEL(PORT_B));
+ assert_pch_dp_disabled(dev_priv, pipe, PCH_DP_C,
TRANS_DP_PORT_SEL(PORT_C));
+ assert_pch_dp_disabled(dev_priv, pipe, PCH_DP_D,
TRANS_DP_PORT_SEL(PORT_D));
I915_STATE_WARN(intel_crt_port_enabled(dev_priv, PCH_ADPA, &port_pipe)
&&
port_pipe == pipe,
@@ -4603,6 +4603,8 @@ static void ironlake_pch_enable(const struct
intel_crtc_state *crtc_state)
&crtc_state->base.adjusted_mode;
u32 bpc = (I915_READ(PIPECONF(pipe)) & PIPECONF_BPC_MASK) >> 5;
i915_reg_t reg = TRANS_DP_CTL(pipe);
+ enum port port;
+
temp = I915_READ(reg);
temp &= ~(TRANS_DP_PORT_SEL_MASK |
TRANS_DP_SYNC_MASK |
@@ -4615,19 +4617,8 @@ static void ironlake_pch_enable(const struct
intel_crtc_state *crtc_state)
if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC)
temp |= TRANS_DP_VSYNC_ACTIVE_HIGH;
- switch (intel_trans_dp_port_sel(crtc)) {
- case PORT_B:
- temp |= TRANS_DP_PORT_SEL_B;
- break;
- case PORT_C:
- temp |= TRANS_DP_PORT_SEL_C;
- break;
- case PORT_D:
- temp |= TRANS_DP_PORT_SEL_D;
- break;
- default:
- BUG();
- }
+ port = intel_trans_dp_port_sel(crtc);
+ temp |= TRANS_DP_PORT_SEL(port);
I915_WRITE(reg, temp);
}
--
2.13.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2] lib/igt_pm: Restore runtime pm state on test exit
On 02/03/2018 09:29, Imre Deak wrote:
On Wed, Feb 28, 2018 at 03:35:06PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Some tests (the ones which call igt_setup_runtime_pm and
igt_pm_enable_audio_runtime_pm) change default system configuration and
never restore it.
The configured runtime suspend is aggressive and may influence behaviour
of subsequent tests, so it is better to restore to previous values on test
exit.
This way system behaviour, with regards to a random sequence of executed
tests, will be more consistent from one run to another.
v2: Read failure means no runtime pm support so don't assert on it.
Signed-off-by: Tvrtko Ursulin
Cc: Imre Deak
Reviewed-by: Chris Wilson # v1
Agreed about having a consistent expected state for each test, not sure
why we didn't restore these settings :/ Btw, I feel somewhat the same
about test results being affected by previous tests, but not sure if
anything should/can be done about that.
Acked-by: Imre Deak
Some nits below.
---
lib/igt_pm.c | 122 ---
1 file changed, 117 insertions(+), 5 deletions(-)
diff --git a/lib/igt_pm.c b/lib/igt_pm.c
index 5bf5b2e23cdc..04e2b89cca95 100644
--- a/lib/igt_pm.c
+++ b/lib/igt_pm.c
@@ -63,6 +63,46 @@ enum {
/* Remember to fix this if adding longer strings */
#define MAX_POLICY_STRLEN strlen(MAX_PERFORMANCE_STR)
+static char __igt_pm_audio_runtime_power_save[64];
+static char __igt_pm_audio_runtime_control[64];
+
+static void __igt_pm_audio_runtime_exit_handler(int sig)
+{
+ int fd;
+
+ igt_debug("Restoring audio power management to '%s' and '%s'\n",
+ __igt_pm_audio_runtime_power_save,
+ __igt_pm_audio_runtime_control);
+
+ fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_WRONLY);
+ if (fd < 0)
+ return;
+ if (write(fd, __igt_pm_audio_runtime_power_save,
+ strlen(__igt_pm_audio_runtime_power_save)) !=
+ strlen(__igt_pm_audio_runtime_power_save))
+ igt_warn("Failed to restore audio power_save to '%s'\n",
+__igt_pm_audio_runtime_power_save);
+ close(fd);
+
+ fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_WRONLY);
+ if (fd < 0)
+ return;
+ if (write(fd, __igt_pm_audio_runtime_control,
+ strlen(__igt_pm_audio_runtime_control)) !=
+ strlen(__igt_pm_audio_runtime_control))
+ igt_warn("Failed to restore audio control to '%s'\n",
+__igt_pm_audio_runtime_control);
+ close(fd);
+}
+
+static void strchomp(char *str)
+{
+ int len = strlen(str);
+
+ if (len && str[len - 1] == '\n')
+ str[len - 1] = 0;
+}
+
/**
* igt_pm_enable_audio_runtime_pm:
*
@@ -78,16 +118,32 @@ void igt_pm_enable_audio_runtime_pm(void)
{
int fd;
- fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_WRONLY);
+ /* Check if already enabled. */
+ if (__igt_pm_audio_runtime_power_save[0])
+ return;
+
+ fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_RDWR);
if (fd >= 0) {
+ igt_assert(read(fd, __igt_pm_audio_runtime_power_save,
+ sizeof(__igt_pm_audio_runtime_power_save)) > 0);
+ strchomp(__igt_pm_audio_runtime_power_save);
igt_assert_eq(write(fd, "1\n", 2), 2);
+ igt_install_exit_handler(__igt_pm_audio_runtime_exit_handler);
Read/install_handler/write would avoid a potential race with ^C. There's also
Well spotted, done in v3.
link_power_management_policy which is only restored during normal exit.
This one already has code to restore
(igt_pm_restore_sata_link_power_management) so maybe best to decide
where to put the responsibility of installing the exit handler in a
follow up patch? Make igt_pm_enable_sata_link_power_management do it, or
have the caller do it? Former would be inline with this patch, and then
probably we can unexport igt_pm_restore_sata_link_power_management. Or
does it already handle this for normal exit since it is calling it from
igt_fixture?
Regards,
Tvrtko
close(fd);
}
- fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_WRONLY);
+ fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_RDWR);
if (fd >= 0) {
+ igt_assert(read(fd, __igt_pm_audio_runtime_control,
+ sizeof(__igt_pm_audio_runtime_control)) > 0);
+ strchomp(__igt_pm_audio_runtime_control);
igt_assert_eq(write(fd, "auto\n", 5), 5);
close(fd);
}
+
+ igt_debug("Saved audio power management as '%s' and '%s'\n",
+ __igt_pm_audio_runtime_power_save,
+ __igt_pm_audio_runtime_control);
+
/* Give some time for i
[Intel-gfx] [PATCH 08/14] drm/i915: Check for IVB instead of gen7 when we think about IVB CPU eDP
From: Ville Syrjälä
Almost all of the GEN7 checks in the DP code are actually looking for
IVB. HSW doesn't even take these codepaths, and VLV is excluded on
account of not having port A. So let's change the checks to IS_IVB to
make the code less confusing.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 642ae298df07..2a82eccffe54 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1970,7 +1970,7 @@ static void intel_dp_prepare(struct intel_encoder
*encoder,
/* Split out the IBX/CPU vs CPT settings */
- if (IS_GEN7(dev_priv) && port == PORT_A) {
+ if (IS_IVYBRIDGE(dev_priv) && port == PORT_A) {
if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
intel_dp->DP |= DP_SYNC_HS_HIGH;
if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC)
@@ -2650,7 +2650,7 @@ static bool intel_dp_get_hw_state(struct intel_encoder
*encoder,
if (!(tmp & DP_PORT_EN))
goto out;
- if (IS_GEN7(dev_priv) && port == PORT_A) {
+ if (IS_IVYBRIDGE(dev_priv) && port == PORT_A) {
*pipe = PORT_TO_PIPE_CPT(tmp);
} else if (HAS_PCH_CPT(dev_priv) && port != PORT_A) {
enum pipe p;
@@ -2887,7 +2887,7 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp,
}
I915_WRITE(DP_TP_CTL(port), temp);
- } else if ((IS_GEN7(dev_priv) && port == PORT_A) ||
+ } else if ((IS_IVYBRIDGE(dev_priv) && port == PORT_A) ||
(HAS_PCH_CPT(dev_priv) && port != PORT_A)) {
*DP &= ~DP_LINK_TRAIN_MASK_CPT;
@@ -3213,7 +3213,7 @@ intel_dp_voltage_max(struct intel_dp *intel_dp)
return intel_ddi_dp_voltage_max(encoder);
else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
return DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
- else if (IS_GEN7(dev_priv) && port == PORT_A)
+ else if (IS_IVYBRIDGE(dev_priv) && port == PORT_A)
return DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
else if (HAS_PCH_CPT(dev_priv) && port != PORT_A)
return DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
@@ -3242,7 +3242,7 @@ intel_dp_pre_emphasis_max(struct intel_dp *intel_dp,
uint8_t voltage_swing)
default:
return DP_TRAIN_PRE_EMPH_LEVEL_0;
}
- } else if (IS_GEN7(dev_priv) && port == PORT_A) {
+ } else if (IS_IVYBRIDGE(dev_priv) && port == PORT_A) {
switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
return DP_TRAIN_PRE_EMPH_LEVEL_2;
@@ -3551,7 +3551,7 @@ intel_dp_set_signal_levels(struct intel_dp *intel_dp)
signal_levels = chv_signal_levels(intel_dp);
} else if (IS_VALLEYVIEW(dev_priv)) {
signal_levels = vlv_signal_levels(intel_dp);
- } else if (IS_GEN7(dev_priv) && port == PORT_A) {
+ } else if (IS_IVYBRIDGE(dev_priv) && port == PORT_A) {
signal_levels = gen7_edp_signal_levels(train_set);
mask = EDP_LINK_TRAIN_VOL_EMP_MASK_IVB;
} else if (IS_GEN6(dev_priv) && port == PORT_A) {
@@ -3641,7 +3641,7 @@ intel_dp_link_down(struct intel_encoder *encoder,
DRM_DEBUG_KMS("\n");
- if ((IS_GEN7(dev_priv) && port == PORT_A) ||
+ if ((IS_IVYBRIDGE(dev_priv) && port == PORT_A) ||
(HAS_PCH_CPT(dev_priv) && port != PORT_A)) {
DP &= ~DP_LINK_TRAIN_MASK_CPT;
DP |= DP_LINK_TRAIN_PAT_IDLE_CPT;
--
2.13.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/14] drm/i915: Nuke intel_trans_dp_port_sel()
From: Ville Syrjälä
for_each_encoder_on_crtc() is legacy and shouldn't be used by atomic
drivers. Let's throw out intel_trans_dp_port_sel() and replace it
with intel_get_crtc_new_encoder() which looks the atomic state instead.
Since we now have to call intel_get_crtc_new_encoder() during the commit
phase we'll need to plumb in the top level atomic state. The
crtc_state->state pointers are no longer valid at that point.
We'll also parametrize TRANS_DP_PORT_SEL() while at it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 39 +---
1 file changed, 14 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e8bedf09d892..52bcb13c1a00 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4496,17 +4496,17 @@ static void ivybridge_update_fdi_bc_bifurcation(struct
intel_crtc *intel_crtc)
* used when we know that the CRTC isn't feeding multiple encoders!
*/
static struct intel_encoder *
-intel_get_crtc_new_encoder(const struct intel_crtc_state *crtc_state)
+intel_get_crtc_new_encoder(const struct intel_atomic_state *state,
+ const struct intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
- const struct drm_atomic_state *state = crtc_state->base.state;
const struct drm_connector_state *connector_state;
const struct drm_connector *connector;
struct intel_encoder *encoder = NULL;
int num_encoders = 0;
int i;
- for_each_new_connector_in_state(state, connector, connector_state, i) {
+ for_each_new_connector_in_state(&state->base, connector,
connector_state, i) {
if (connector_state->crtc != &crtc->base)
continue;
@@ -4520,22 +4520,6 @@ intel_get_crtc_new_encoder(const struct intel_crtc_state
*crtc_state)
return encoder;
}
-/* Return which DP Port should be selected for Transcoder DP control */
-static enum port
-intel_trans_dp_port_sel(struct intel_crtc *crtc)
-{
- struct drm_device *dev = crtc->base.dev;
- struct intel_encoder *encoder;
-
- for_each_encoder_on_crtc(dev, &crtc->base, encoder) {
- if (encoder->type == INTEL_OUTPUT_DP ||
- encoder->type == INTEL_OUTPUT_EDP)
- return encoder->port;
- }
-
- return -1;
-}
-
/*
* Enable PCH resources required for PCH ports:
* - PCH PLLs
@@ -4544,7 +4528,8 @@ intel_trans_dp_port_sel(struct intel_crtc *crtc)
* - DP transcoding bits
* - transcoder
*/
-static void ironlake_pch_enable(const struct intel_crtc_state *crtc_state)
+static void ironlake_pch_enable(const struct intel_atomic_state *state,
+ const struct intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_device *dev = crtc->base.dev;
@@ -4617,7 +4602,7 @@ static void ironlake_pch_enable(const struct
intel_crtc_state *crtc_state)
if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC)
temp |= TRANS_DP_VSYNC_ACTIVE_HIGH;
- port = intel_trans_dp_port_sel(crtc);
+ port = intel_get_crtc_new_encoder(state, crtc_state)->port;
temp |= TRANS_DP_PORT_SEL(port);
I915_WRITE(reg, temp);
@@ -4626,7 +4611,8 @@ static void ironlake_pch_enable(const struct
intel_crtc_state *crtc_state)
ironlake_enable_pch_transcoder(dev_priv, pipe);
}
-static void lpt_pch_enable(const struct intel_crtc_state *crtc_state)
+static void lpt_pch_enable(const struct intel_atomic_state *state,
+ const struct intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -5384,7 +5370,7 @@ static void ironlake_crtc_enable(struct intel_crtc_state
*pipe_config,
intel_enable_pipe(pipe_config);
if (intel_crtc->config->has_pch_encoder)
- ironlake_pch_enable(pipe_config);
+ ironlake_pch_enable(old_intel_state, pipe_config);
assert_vblank_disabled(crtc);
drm_crtc_vblank_on(crtc);
@@ -5520,7 +5506,7 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
intel_enable_pipe(pipe_config);
if (intel_crtc->config->has_pch_encoder)
- lpt_pch_enable(pipe_config);
+ lpt_pch_enable(old_intel_state, pipe_config);
if (intel_crtc_has_type(intel_crtc->config, INTEL_OUTPUT_DP_MST))
intel_ddi_set_vc_payload_alloc(pipe_config, true);
@@ -8971,9 +8957,12 @@ void hsw_disable_pc8(struct drm_i915_private *dev_priv)
static int haswell_crtc_compute_clock(struct intel_crtc *crtc,
[Intel-gfx] [PATCH 13/14] drm/i915: Allow eDP on port C in theory
From: Ville Syrjälä
The power sequencer has bits to allow DP C to be used for eDP.
Currently we assume this will never happen, but I guess it could
theoretically be a thing. MAke the code do the right thing in that
case, and toss in a MISSING_CASE() for any other port.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3732a4e22ef2..c7d0c21da6fe 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5687,10 +5687,20 @@ intel_dp_init_panel_power_sequencer_registers(struct
intel_dp *intel_dp,
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
port_sel = PANEL_PORT_SELECT_VLV(port);
} else if (HAS_PCH_IBX(dev_priv) || HAS_PCH_CPT(dev_priv)) {
- if (port == PORT_A)
+ switch (port) {
+ case PORT_A:
port_sel = PANEL_PORT_SELECT_DPA;
- else
+ break;
+ case PORT_C:
+ port_sel = PANEL_PORT_SELECT_DPC;
+ break;
+ case PORT_D:
port_sel = PANEL_PORT_SELECT_DPD;
+ break;
+ default:
+ MISSING_CASE(port);
+ break;
+ }
}
pp_on |= port_sel;
--
2.13.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/14] drm/i915: Implement the missing bits of assert_panel_unlocked()
From: Ville Syrjälä
Add the missing eDP port handling into assert_panel_unlocked(). We now
have intel_dp_port_enabled() which makes this trivial.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cb056283830c..02fd00634fe7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1171,10 +1171,23 @@ void assert_panel_unlocked(struct drm_i915_private
*dev_priv, enum pipe pipe)
pp_reg = PP_CONTROL(0);
port_sel = I915_READ(PP_ON_DELAYS(0)) & PANEL_PORT_SELECT_MASK;
- if (port_sel == PANEL_PORT_SELECT_LVDS) {
+ switch (port_sel) {
+ case PANEL_PORT_SELECT_LVDS:
intel_lvds_port_enabled(dev_priv, PCH_LVDS,
&panel_pipe);
+ break;
+ case PANEL_PORT_SELECT_DPA:
+ intel_dp_port_enabled(dev_priv, DP_A, PORT_A,
&panel_pipe);
+ break;
+ case PANEL_PORT_SELECT_DPC:
+ intel_dp_port_enabled(dev_priv, PCH_DP_C, PORT_C,
&panel_pipe);
+ break;
+ case PANEL_PORT_SELECT_DPD:
+ intel_dp_port_enabled(dev_priv, PCH_DP_D, PORT_D,
&panel_pipe);
+ break;
+ default:
+ MISSING_CASE(port_sel);
+ break;
}
- /* XXX: else fix for eDP */
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
/* presumably write lock depends on pipe, not port select */
pp_reg = PP_CONTROL(pipe);
--
2.13.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/14] drm/i915: Clean up DP pipe select bits
From: Ville Syrjälä
Clean up the DP pipe select bits. To make the whole situation a bit
less ugly we'll start to share the same code between .get_hw_state(),
the port state asserts, and the VLV power sequencer code.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 24 +++-
drivers/gpu/drm/i915/intel_display.c | 46 +--
drivers/gpu/drm/i915/intel_dp.c | 106 +++
drivers/gpu/drm/i915/intel_drv.h | 3 +
4 files changed, 85 insertions(+), 94 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f1460fd27881..2c1e33b63cf3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5248,10 +5248,15 @@ enum {
#define CHV_DP_D _MMIO(VLV_DISPLAY_BASE + 0x64300)
#define DP_PORT_EN (1 << 31)
-#define DP_PIPEB_SELECT (1 << 30)
-#define DP_PIPE_MASK (1 << 30)
-#define DP_PIPE_SELECT_CHV(pipe) ((pipe) << 16)
-#define DP_PIPE_MASK_CHV (3 << 16)
+#define DP_PIPE_SEL(pipe)((pipe) << 30)
+#define DP_PIPE_SEL_MASK (1 << 30)
+#define DP_PIPE_SEL_SHIFT30
+#define DP_PIPE_SEL_IVB(pipe)((pipe) << 29)
+#define DP_PIPE_SEL_MASK_IVB (3 << 29)
+#define DP_PIPE_SEL_SHIFT_IVB29
+#define DP_PIPE_SEL_CHV(pipe)((pipe) << 16)
+#define DP_PIPE_SEL_MASK_CHV (3 << 16)
+#define DP_PIPE_SEL_SHIFT_CHV16
/* Link training mode - select a suitable mode for each stage */
#define DP_LINK_TRAIN_PAT_1 (0 << 28)
@@ -7899,16 +7904,6 @@ enum {
#define PCH_DP_AUX_CH_DATA(aux_ch, i) _MMIO(_PORT((aux_ch) - AUX_CH_B,
_PCH_DPB_AUX_CH_DATA1, _PCH_DPC_AUX_CH_DATA1) + (i) * 4) /* 5 registers */
/* CPT */
-#define PORT_TRANS_A_SEL_CPT 0
-#define PORT_TRANS_B_SEL_CPT (1<<29)
-#define PORT_TRANS_C_SEL_CPT (2<<29)
-#define PORT_TRANS_SEL_MASK (3<<29)
-#define PORT_TRANS_SEL_CPT(pipe) ((pipe) << 29)
-#define PORT_TO_PIPE(val) (((val) & (1<<30)) >> 30)
-#define PORT_TO_PIPE_CPT(val) (((val) & PORT_TRANS_SEL_MASK) >> 29)
-#define SDVO_PORT_TO_PIPE_CHV(val)(((val) & (3<<24)) >> 24)
-#define DP_PORT_TO_PIPE_CHV(val) (((val) & (3<<16)) >> 16)
-
#define _TRANS_DP_CTL_A0xe0300
#define _TRANS_DP_CTL_B0xe1300
#define _TRANS_DP_CTL_C0xe2300
@@ -7917,7 +7912,6 @@ enum {
#define TRANS_DP_PORT_SEL(port) (((port) - PORT_B) << 29)
#define TRANS_DP_PORT_SEL_NONE(3 << 29)
#define TRANS_DP_PORT_SEL_MASK(3 << 29)
-#define TRANS_DP_PIPE_TO_PORT(val)val) & TRANS_DP_PORT_SEL_MASK) >>
29) + PORT_B)
#define TRANS_DP_AUDIO_ONLY (1<<26)
#define TRANS_DP_ENH_FRAMING (1<<18)
#define TRANS_DP_8BPC (0<<9)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 52bcb13c1a00..cb056283830c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1261,38 +1261,22 @@ void assert_pch_transcoder_disabled(struct
drm_i915_private *dev_priv,
pipe_name(pipe));
}
-static bool dp_pipe_enabled(struct drm_i915_private *dev_priv,
- enum pipe pipe, u32 port_sel, u32 val)
+static void assert_pch_dp_disabled(struct drm_i915_private *dev_priv,
+ enum pipe pipe, enum port port,
+ i915_reg_t dp_reg)
{
- if ((val & DP_PORT_EN) == 0)
- return false;
+ enum pipe port_pipe;
+ bool state;
- if (HAS_PCH_CPT(dev_priv)) {
- u32 trans_dp_ctl = I915_READ(TRANS_DP_CTL(pipe));
- if ((trans_dp_ctl & TRANS_DP_PORT_SEL_MASK) != port_sel)
- return false;
- } else if (IS_CHERRYVIEW(dev_priv)) {
- if ((val & DP_PIPE_MASK_CHV) != DP_PIPE_SELECT_CHV(pipe))
- return false;
- } else {
- if ((val & DP_PIPE_MASK) != (pipe << 30))
- return false;
- }
- return true;
-}
+ state = intel_dp_port_enabled(dev_priv, dp_reg, port, &port_pipe);
-static void assert_pch_dp_disabled(struct drm_i915_private *dev_priv,
- enum pipe pipe, i915_reg_t reg,
- u32 port_sel)
-{
- u32 val = I915_READ(reg);
- I915_STATE_WARN(dp_pipe_enabled(dev_priv, pipe, port_sel, val),
-"PCH DP (0x%08x) enabled on transcoder %c, should be disabled\n",
-i915_mmio_reg_offset(reg), pipe_name(pipe));
+ I915_STATE_WARN(state && port_pipe == pipe,
+ "PCH DP %c enabled on transcoder %c, should be
disabled\n",
+ port_name(port), pipe_name(pipe));
- I915_STATE_WARN(HAS_PCH_IBX(dev_priv) && (val & DP_POR
[Intel-gfx] [PATCH 09/14] drm/i915: Move intel_ddi_get_crtc_new_encoder() out from ddi code
From: Ville Syrjälä
The ddi code no longer uses intel_ddi_get_crtc_new_encoder(). Move it
elsewhere where we have some users left.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 29 -
drivers/gpu/drm/i915/intel_display.c | 31 ++-
drivers/gpu/drm/i915/intel_drv.h | 2 --
3 files changed, 30 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a56a4db6dc38..ab084170ea38 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1065,35 +1065,6 @@ intel_ddi_get_crtc_encoder(struct intel_crtc *crtc)
return ret;
}
-/* Finds the only possible encoder associated with the given CRTC. */
-struct intel_encoder *
-intel_ddi_get_crtc_new_encoder(struct intel_crtc_state *crtc_state)
-{
- struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
- struct intel_encoder *ret = NULL;
- struct drm_atomic_state *state;
- struct drm_connector *connector;
- struct drm_connector_state *connector_state;
- int num_encoders = 0;
- int i;
-
- state = crtc_state->base.state;
-
- for_each_new_connector_in_state(state, connector, connector_state, i) {
- if (connector_state->crtc != crtc_state->base.crtc)
- continue;
-
- ret = to_intel_encoder(connector_state->best_encoder);
- num_encoders++;
- }
-
- WARN(num_encoders != 1, "%d encoders on crtc for pipe %c\n",
num_encoders,
-pipe_name(crtc->pipe));
-
- BUG_ON(ret == NULL);
- return ret;
-}
-
#define LC_FREQ 2700
static int hsw_ddi_calc_wrpll_link(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 26f8f1e741f7..239059493243 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4491,6 +4491,35 @@ static void ivybridge_update_fdi_bc_bifurcation(struct
intel_crtc *intel_crtc)
}
}
+/*
+ * Finds the encoder associated with the given CRTC. This can only be
+ * used when we know that the CRTC isn't feeding multiple encoders!
+ */
+static struct intel_encoder *
+intel_get_crtc_new_encoder(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ const struct drm_atomic_state *state = crtc_state->base.state;
+ const struct drm_connector_state *connector_state;
+ const struct drm_connector *connector;
+ struct intel_encoder *encoder = NULL;
+ int num_encoders = 0;
+ int i;
+
+ for_each_new_connector_in_state(state, connector, connector_state, i) {
+ if (connector_state->crtc != &crtc->base)
+ continue;
+
+ encoder = to_intel_encoder(connector_state->best_encoder);
+ num_encoders++;
+ }
+
+ WARN(num_encoders != 1, "%d encoders for pipe %c\n",
+num_encoders, pipe_name(crtc->pipe));
+
+ return encoder;
+}
+
/* Return which DP Port should be selected for Transcoder DP control */
static enum port
intel_trans_dp_port_sel(struct intel_crtc *crtc)
@@ -8953,7 +8982,7 @@ static int haswell_crtc_compute_clock(struct intel_crtc
*crtc,
{
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI)) {
struct intel_encoder *encoder =
- intel_ddi_get_crtc_new_encoder(crtc_state);
+ intel_get_crtc_new_encoder(crtc_state);
if (!intel_get_shared_dpll(crtc, crtc_state, encoder)) {
DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d783ecfef46d..9f6e68d192b6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1373,8 +1373,6 @@ void intel_ddi_disable_transcoder_func(struct
drm_i915_private *dev_priv,
enum transcoder cpu_transcoder);
void intel_ddi_enable_pipe_clock(const struct intel_crtc_state *crtc_state);
void intel_ddi_disable_pipe_clock(const struct intel_crtc_state *crtc_state);
-struct intel_encoder *
-intel_ddi_get_crtc_new_encoder(struct intel_crtc_state *crtc_state);
void intel_ddi_set_pipe_settings(const struct intel_crtc_state *crtc_state);
void intel_ddi_prepare_link_retrain(struct intel_dp *intel_dp);
bool intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector);
--
2.13.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Kill the remaining CHV HBR2 leftovers
From: Ville Syrjälä
AFAIK CHV was supposed to have HBR2 originally, but in the end the feature
was dropped. We still have some code leftovers from those early days.
Eliminate them.
The extra bit for the training pattern seems to be dead in the hardware.
I can set it (in fact I can set almost any reserved bit in the
registers) but it doesn't seem to interfere with the operation of the
hardware. Either that or I'm very lucky that my displays complete link
training with the incorrect pattern being sent out.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 2 --
drivers/gpu/drm/i915/intel_dp.c | 20
2 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 95a2e51ecbb0..f3efc242df2d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5250,8 +5250,6 @@ enum {
#define DP_LINK_TRAIN_OFF(3 << 28)
#define DP_LINK_TRAIN_MASK (3 << 28)
#define DP_LINK_TRAIN_SHIFT 28
-#define DP_LINK_TRAIN_PAT_3_CHV (1 << 14)
-#define DP_LINK_TRAIN_MASK_CHV ((3 << 28)|(1<<14))
/* CPT Link training mode */
#define DP_LINK_TRAIN_PAT_1_CPT (0 << 8)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index aba2f45819d8..df1772044208 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -92,8 +92,6 @@ static const struct dp_link_dpll chv_dpll[] = {
{ .p1 = 4, .p2 = 2, .n = 1, .m1 = 2, .m2 = 0x81a } },
{ 27, /* m2_int = 27, m2_fraction = 0 */
{ .p1 = 4, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } },
- { 54, /* m2_int = 27, m2_fraction = 0 */
- { .p1 = 2, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } }
};
/**
@@ -2908,10 +2906,7 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp,
}
} else {
- if (IS_CHERRYVIEW(dev_priv))
- *DP &= ~DP_LINK_TRAIN_MASK_CHV;
- else
- *DP &= ~DP_LINK_TRAIN_MASK;
+ *DP &= ~DP_LINK_TRAIN_MASK;
switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) {
case DP_TRAINING_PATTERN_DISABLE:
@@ -2924,12 +2919,8 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp,
*DP |= DP_LINK_TRAIN_PAT_2;
break;
case DP_TRAINING_PATTERN_3:
- if (IS_CHERRYVIEW(dev_priv)) {
- *DP |= DP_LINK_TRAIN_PAT_3_CHV;
- } else {
- DRM_DEBUG_KMS("TPS3 not supported, using TPS2
instead\n");
- *DP |= DP_LINK_TRAIN_PAT_2;
- }
+ DRM_DEBUG_KMS("TPS3 not supported, using TPS2
instead\n");
+ *DP |= DP_LINK_TRAIN_PAT_2;
break;
}
}
@@ -3668,10 +3659,7 @@ intel_dp_link_down(struct intel_encoder *encoder,
DP &= ~DP_LINK_TRAIN_MASK_CPT;
DP |= DP_LINK_TRAIN_PAT_IDLE_CPT;
} else {
- if (IS_CHERRYVIEW(dev_priv))
- DP &= ~DP_LINK_TRAIN_MASK_CHV;
- else
- DP &= ~DP_LINK_TRAIN_MASK;
+ DP &= ~DP_LINK_TRAIN_MASK;
DP |= DP_LINK_TRAIN_PAT_IDLE;
}
I915_WRITE(intel_dp->output_reg, DP);
--
2.13.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 vs checkpatch
On Fri, 02 Mar 2018, Joonas Lahtinen wrote: > Quoting Rodrigo Vivi (2018-03-01 20:00:07) >> On Thu, Mar 01, 2018 at 06:13:31PM +0200, Jani Nikula wrote: >> > >> > I went through the recent checkpatch reports, and here's my take. >> > >> > On Thu, 01 Mar 2018, Arkadiusz Hiler wrote: >> > > 2. Which of the checkpatch checks we want to disabled for i915? >> > >> > I'd like to have these silenced: >> > >> > CHECK: No space is necessary after a cast >> > WARNING: line over 80 characters >> > WARNING: quoted string split across lines >> > >> > I'd prefer we conform to the last two too, but there's just too much >> > noise and too many cases where we explicitly should ignore them. >> > >> > For the time being, I think we may have to silence these ones too, but >> > I'd like us to discuss enforcing them: >> > >> > CHECK: Prefer kernel type 'u16' over 'uint16_t' >> > CHECK: Prefer kernel type 'u32' over 'uint32_t' >> > CHECK: Prefer kernel type 'u64' over 'uint64_t' >> > CHECK: Prefer kernel type 'u8' over 'uint8_t' >> > CHECK: Prefer using the BIT macro >> > >> > The BIT macros is one that I'd consider accepting a one-time conversion >> > of i915_reg.h and after that use it exclusively. But up to debate. >> >> For this one I just wonder if we would need to do a massive >> change before. Because it would get ugly to have mixed cases. > > Yep, the mixed cases are bit tough to automatically enforce. So the > transitional phase will always be troublesome, and trying to make that > shorter makes some sense to me. > > Traditionally we've avoided mass changes just for the changes, but we > have to assess the value of doing it against what we get. That is > getting automatic enforcement, once we've converted over. > > We're not that far off the mark with u(32|16|8) vs uint(32|16|8)_t: > > i915$ git grep -E "uint(32|16|8)_t" | wc -l > 852 > i915$ git grep -E "u(32|16|8)" | wc -l > 3857 Doing a bit of git grep -cE with those seems to indicate that code with uint(32|16|8)_t promotes *more* use of those. It's natural and it goes by the rule of following the style surrounding your changes. > I don't consider that undoable. It's doable. Only a question of whether we want to do that or not. > BIT() is in the minority at the moment, so it might benefit even more as > people often cargo-cult the programming style from other places in the code. FWIW I think BIT(n) is simply better than open-coding (1 << n), while the kernel vs. C types is more of an aestheical thing. > I think it might be worthy doing these two changes to get the automatic > enforemend and avoid the codebase staying in limbo. Machine overlords are > way better at enforcing any code checks than us humans. Agreed on the machine overlords. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/1] drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric
On 3/2/2018 2:01 PM, Chris Wilson wrote:
Quoting Sagar Arun Kamble (2018-03-01 16:45:45)
+static int huc_fw_xfer(struct intel_uc_fw *huc_fw, struct i915_vma *vma)
+{
+ struct intel_huc *huc = container_of(huc_fw, struct intel_huc, fw);
+ struct drm_i915_private *dev_priv = huc_to_i915(huc);
+ unsigned long offset = 0;
+ u32 size;
+ int ret;
+
+ GEM_BUG_ON(huc_fw->type != INTEL_UC_FW_TYPE_HUC);
+
+ intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+
+ /* Set the source address for the uCode */
+ offset = guc_ggtt_offset(vma) + huc_fw->header_offset;
+ I915_WRITE(DMA_ADDR_0_LOW, lower_32_bits(offset));
+ I915_WRITE(DMA_ADDR_0_HIGH, upper_32_bits(offset) & 0x);
So these same registers are used to transfer the guc image. What
serialisation do we have between the two to prevent conflicts?
(lockdep_assert_held the appropriate guard with explanation :)
Yes. Currently they are implicitly serialized by load ordering. Will
need locking if async load is to be done.
But no harm in adding locking/lockdep now. Will do. Thank you.
As it's not a new issue, please follow up with another patch and we'll
apply this in the meantime.
-Chris
--
Thanks,
Sagar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Check for I915_MODE_FLAG_INHERITED before drm_atomic_helper_check_modeset
There is no open cibuglog bug for below issue. However, if a developer believe
that patch didn't cause the issue, they can just mail or ping me on IRC and
I'll create a cibuglog issue and FDO bug to cover it.
In developers we trust.
/Marta
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Friday, March 2, 2018 11:37 AM
> To: Lyude Paul ; Maarten Lankhorst
> ; intel-gfx@lists.freedesktop.org
> Cc: Daniel Vetter ; Lofstedt, Marta
> ; Hiler, Arkadiusz ;
> Sarvela, Tomi P ; Martin Peres
>
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Check for
> I915_MODE_FLAG_INHERITED before drm_atomic_helper_check_modeset
>
> On Thu, 01 Mar 2018, Lyude Paul wrote:
> > Pushed with some small whitespace changes to make sparse happy,
> thanks!
>
> Please do not push patches before they've passed CI. This patch gives [1]:
>
> [ 281.167033] i915 :00:02.0: DP-2: EDID is invalid:
> ...
> [ 282.806393] [drm:intel_enable_shared_dpll [i915]] *ERROR* DPLL 1 not
> locked
>
> I don't know if this is caused by the patch, but since we get this in the BAT
> round, the full IGT testing wasn't even run here.
>
>
> BR,
> Jani.
>
>
> [1] https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8102/fi-skl-
> 6700k2/igt@kms_chamel...@common-hpd-after-suspend.html
> >
> > On Wed, 2018-02-21 at 10:28 +0100, Maarten Lankhorst wrote:
> >> Moving the check upwards will mean we we no longer have to add planes
> >> and connectors manually, because everything is handled correctly by
> >> drm_atomic_helper_check_modeset() as intended.
> >>
> >> Signed-off-by: Maarten Lankhorst
> >> Cc: Lyude Paul
> >> Cc: Daniel Vetter
> >> Reviewed-by: Daniel Vetter
> >> ---
> >> drivers/gpu/drm/i915/intel_display.c | 20 +---
> >> 1 file changed, 5 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index 65be7af7f647..c5cc9022d545 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -11927,6 +11927,11 @@ static int intel_atomic_check(struct
> >> drm_device *dev,
> >>int ret, i;
> >>bool any_ms = false;
> >>
> >> + /* Catch I915_MODE_FLAG_INHERITED */
> >> + for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
> >> crtc_state, i)
> >> + if (crtc_state->mode.private_flags !=
> old_crtc_state-
> >> >mode.private_flags)
> >> + crtc_state->mode_changed =
> true;
> >> +
> >>ret = drm_atomic_helper_check_modeset(dev, state);
> >>if (ret)
> >>return ret;
> >> @@ -11935,10 +11940,6 @@ static int intel_atomic_check(struct
> >> drm_device *dev,
> >>struct intel_crtc_state *pipe_config =
> >>to_intel_crtc_state(crtc_state);
> >>
> >> - /* Catch I915_MODE_FLAG_INHERITED */
> >> - if (crtc_state->mode.private_flags !=
> old_crtc_state-
> >> >mode.private_flags)
> >> - crtc_state->mode_changed =
> true;
> >> -
> >>if (!needs_modeset(crtc_state))
> >>continue;
> >>
> >> @@ -11947,13 +11948,6 @@ static int intel_atomic_check(struct
> >> drm_device *dev,
> >>continue;
> >>}
> >>
> >> - /* FIXME: For only active_changed we shouldn't
> need to do
> >> any
> >> - * state recomputation at all. */
> >> -
> >> - ret =
> drm_atomic_add_affected_connectors(state, crtc);
> >> - if (ret)
> >> - return ret;
> >> -
> >>ret = intel_modeset_pipe_config(crtc,
> pipe_config);
> >>if (ret) {
> >>
> intel_dump_pipe_config(to_intel_crtc(crtc),
> >> @@ -11972,10 +11966,6 @@ static int intel_atomic_check(struct
> >> drm_device *dev,
> >>if (needs_modeset(crtc_state))
> >>any_ms = true;
> >>
> >> - ret = drm_atomic_add_affected_planes(state,
> crtc);
> >> - if (ret)
> >> - return ret;
> >> -
> >>intel_dump_pipe_config(to_intel_crtc(crtc),
> pipe_config,
> >>
> needs_modeset(crtc_state) ?
> >> "[modeset]" :
> "[fastset]");
>
> --
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Stop engines around GPU reset preparations
As we make preparations to reset the GPU state, we assume that the GPU
is hung and will not advance. Make this assumption more explicit by
setting the STOP_RING bit on the engines as part of our early reset
preparations.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michel Thierry
---
See
https://intel-gfx-ci.01.org/tree/drm-tip/kasan_15/fi-bdw-5557u/pstore22-1519879816_Panic_3.log
for a bizarre error that kasan-farm keeps on trying over. Maybe related
to this?
---
drivers/gpu/drm/i915/i915_drv.c | 3 +++
drivers/gpu/drm/i915/i915_drv.h | 10 --
drivers/gpu/drm/i915/intel_uncore.c | 33 +
3 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index aaa861b51024..925f5722d077 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1908,6 +1908,8 @@ void i915_reset(struct drm_i915_private *i915, unsigned
int flags)
error->reset_count++;
disable_irq(i915->drm.irq);
+ intel_gpu_reset_prepare(i915, ALL_ENGINES);
+
ret = i915_gem_reset_prepare(i915);
if (ret) {
dev_err(i915->drm.dev, "GPU recovery failed\n");
@@ -1969,6 +1971,7 @@ void i915_reset(struct drm_i915_private *i915, unsigned
int flags)
finish:
i915_gem_reset_finish(i915);
+ intel_gpu_reset_finish(i915, ALL_ENGINES);
enable_irq(i915->drm.irq);
wakeup:
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 10c9e5e619ab..b95e675e0834 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2957,8 +2957,14 @@ extern const struct dev_pm_ops i915_pm_ops;
extern int i915_driver_load(struct pci_dev *pdev,
const struct pci_device_id *ent);
extern void i915_driver_unload(struct drm_device *dev);
-extern int intel_gpu_reset(struct drm_i915_private *dev_priv, u32 engine_mask);
-extern bool intel_has_gpu_reset(struct drm_i915_private *dev_priv);
+
+bool intel_has_gpu_reset(struct drm_i915_private *dev_priv);
+
+void intel_gpu_reset_prepare(struct drm_i915_private *dev_priv,
+unsigned engine_mask);
+int intel_gpu_reset(struct drm_i915_private *dev_priv, u32 engine_mask);
+void intel_gpu_reset_finish(struct drm_i915_private *dev_priv,
+ unsigned engine_mask);
#define I915_RESET_QUIET BIT(0)
extern void i915_reset(struct drm_i915_private *i915, unsigned int flags);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 5ae9a62712ca..7186fe4d2ba9 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1899,6 +1899,29 @@ static reset_func intel_get_gpu_reset(struct
drm_i915_private *dev_priv)
return NULL;
}
+static void i915_engines_set_mode(struct drm_i915_private *dev_priv,
+ unsigned engine_mask,
+ u32 mode)
+{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ if (INTEL_GEN(dev_priv) < 3)
+ return;
+
+ for_each_engine_masked(engine, dev_priv, engine_mask, id)
+ I915_WRITE_FW(RING_MI_MODE(engine->mmio_base), mode);
+}
+
+void intel_gpu_reset_prepare(struct drm_i915_private *dev_priv,
+unsigned engine_mask)
+{
+ intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+
+ i915_engines_set_mode(dev_priv, engine_mask,
+ _MASKED_BIT_ENABLE(STOP_RING));
+}
+
int intel_gpu_reset(struct drm_i915_private *dev_priv, unsigned engine_mask)
{
reset_func reset = intel_get_gpu_reset(dev_priv);
@@ -1939,6 +1962,16 @@ int intel_gpu_reset(struct drm_i915_private *dev_priv,
unsigned engine_mask)
return ret;
}
+void intel_gpu_reset_finish(struct drm_i915_private *dev_priv,
+ unsigned engine_mask)
+{
+ /* Clear the STOP_RING bit as the reset may not have occurred */
+ i915_engines_set_mode(dev_priv, engine_mask,
+ _MASKED_BIT_DISABLE(STOP_RING));
+
+ intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+}
+
bool intel_has_gpu_reset(struct drm_i915_private *dev_priv)
{
return intel_get_gpu_reset(dev_priv) != NULL;
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt v5] igt/gen7_forcewake_mt: Make the mmio register as volatile
Prevent the compiler from caching reads/writes to the hw register as we
do want to perform mmio.
Whilst fixing up the mmio access, also ensure that we do not leave the
test with any other bits still set in the forcewake register to prevent
affecting other tests, as spotted by Tvrtko.
v2: Use intel_mmio_use_pci_bar() rather open code the ioremap
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/gen7_forcewake_mt.c | 76 +++
1 file changed, 50 insertions(+), 26 deletions(-)
diff --git a/tests/gen7_forcewake_mt.c b/tests/gen7_forcewake_mt.c
index 07320ef9..edf487a7 100644
--- a/tests/gen7_forcewake_mt.c
+++ b/tests/gen7_forcewake_mt.c
@@ -41,12 +41,14 @@ IGT_TEST_DESCRIPTION("Exercise a suspect workaround
required for"
" FORCEWAKE_MT.");
#define FORCEWAKE_MT 0xa188
+#define READ_ONCE(x) (*(volatile typeof(x) *)(&(x)))
struct thread {
pthread_t thread;
- void *mmio;
+ volatile uint32_t *forcewake_mt;
int fd;
int bit;
+ bool done;
};
static const struct pci_id_match match[] = {
@@ -77,43 +79,39 @@ static struct pci_device *__igfx_get(void)
pci_iterator_destroy(iter);
}
+ pci_device_probe(dev);
return dev;
}
-static void *igfx_get_mmio(void)
+static volatile uint32_t *igfx_mmio_forcewake_mt(void)
{
struct pci_device *pci = __igfx_get();
- void *mmio = NULL;
- int error;
- igt_skip_on(pci == NULL);
- igt_skip_on(intel_gen(pci->device_id) != 7);
+ igt_require(pci);
+ igt_assert(intel_gen(pci->device_id) == 7);
- error = pci_device_probe(pci);
- igt_assert_eq(error, 0);
+ intel_mmio_use_pci_bar(pci);
- error = pci_device_map_range(pci,
-pci->regions[0].base_addr,
-2*1024*1024,
-PCI_DEV_MAP_FLAG_WRITABLE,
-&mmio);
- igt_assert_eq(error, 0);
- igt_assert(mmio != NULL);
-
- return mmio;
+ return (volatile uint32_t *)((char *)igt_global_mmio + FORCEWAKE_MT);
}
static void *thread(void *arg)
{
+ static const char acquire_error[] = "acquire";
+ static const char release_error[] = "release";
+
struct thread *t = arg;
- uint32_t *forcewake_mt = (uint32_t *)((char *)t->mmio + FORCEWAKE_MT);
- uint32_t bit = 1 << t->bit;
+ const uint32_t bit = 1 << t->bit;
+ volatile uint32_t *forcewake_mt = t->forcewake_mt;
- while (1) {
+ while (!READ_ONCE(t->done)) {
*forcewake_mt = bit << 16 | bit;
- igt_assert(*forcewake_mt & bit);
+ if (igt_wait(*forcewake_mt & bit, 50, 1))
+ return (void *)acquire_error;
+
*forcewake_mt = bit << 16;
- igt_assert((*forcewake_mt & bit) == 0);
+ if (igt_wait((*forcewake_mt & bit) == 0, 50, 1))
+ return (void *)release_error;
}
return NULL;
@@ -124,10 +122,12 @@ static void *thread(void *arg)
igt_simple_main
{
struct thread t[16];
+ bool success = true;
int i;
t[0].fd = drm_open_driver(DRIVER_INTEL);
- t[0].mmio = igfx_get_mmio();
+ t[0].forcewake_mt = igfx_mmio_forcewake_mt();
+ t[0].done = false;
for (i = 2; i < 16; i++) {
t[i] = t[0];
@@ -137,7 +137,7 @@ igt_simple_main
sleep(2);
- for (i = 0; i < 1000; i++) {
+ igt_until_timeout(2) {
uint32_t *p;
struct drm_i915_gem_execbuffer2 execbuf;
struct drm_i915_gem_exec_object2 exec[2];
@@ -192,13 +192,37 @@ igt_simple_main
p = gem_mmap__gtt(t[0].fd, exec[0].handle, 4096, PROT_READ);
igt_info("[%d]={ %08x %08x }\n", i, p[0], p[1]);
- igt_assert(p[0] & 2);
- igt_assert((p[1] & 2) == 0);
+ if ((p[0] & 2) == 0) {
+ igt_warn("Failed to acquire forcewake BIT(1) from
batch\n");
+ success = false;
+ }
+ if ((p[1] & 2)) {
+ igt_warn("Failed to release forcewake BIT(1) from
batch\n");
+ success = false;
+ }
munmap(p, 4096);
gem_close(t[0].fd, exec[0].handle);
gem_close(t[0].fd, exec[1].handle);
+ if (!success)
+ break;
usleep(1000);
}
+
+ for (i = 2; i < 16; i++) {
+ void *result;
+
+ t[i].done = true;
+ pthread_join(t[i].thread, &result);
+ if (result) {
+ igt_warn("Thread BIT(%d) failed to %s forcewake\n", i,
(char *)result);
+ success = false;
+ }
+ }
+
+
Re: [Intel-gfx] [PATCH v3 05/10] pwm: add PWM mode to pwm_config()
On 28.02.2018 21:44, Thierry Reding wrote: > On Thu, Feb 22, 2018 at 02:01:16PM +0200, Claudiu Beznea wrote: >> Add PWM mode to pwm_config() function. The drivers which uses pwm_config() >> were adapted to this change. >> >> Signed-off-by: Claudiu Beznea >> --- >> arch/arm/mach-s3c24xx/mach-rx1950.c | 11 +-- >> drivers/bus/ts-nbus.c| 2 +- >> drivers/clk/clk-pwm.c| 3 ++- >> drivers/gpu/drm/i915/intel_panel.c | 17 ++--- >> drivers/hwmon/pwm-fan.c | 2 +- >> drivers/input/misc/max77693-haptic.c | 2 +- >> drivers/input/misc/max8997_haptic.c | 6 +- >> drivers/leds/leds-pwm.c | 5 - >> drivers/media/rc/ir-rx51.c | 5 - >> drivers/media/rc/pwm-ir-tx.c | 5 - >> drivers/video/backlight/lm3630a_bl.c | 4 +++- >> drivers/video/backlight/lp855x_bl.c | 4 +++- >> drivers/video/backlight/lp8788_bl.c | 5 - >> drivers/video/backlight/pwm_bl.c | 11 +-- >> drivers/video/fbdev/ssd1307fb.c | 3 ++- >> include/linux/pwm.h | 6 -- >> 16 files changed, 70 insertions(+), 21 deletions(-) > > I don't think it makes sense to leak mode support into the legacy API. > The pwm_config() function is considered legacy I missed this aspect. and should eventually go > away. As such it doesn't make sense to integrate a new feature such as > PWM modes into it. Agree. All users of pwm_config() assume normal mode, and > that's what pwm_config() should provide. Agree. > > Anyone that needs something other than normal mode should use the new > atomic PWM API. Agree. > > Thierry > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Clean up the port pipe select bits
== Series Details == Series: drm/i915: Clean up the port pipe select bits URL : https://patchwork.freedesktop.org/series/39259/ State : failure == Summary == Series 39259v1 drm/i915: Clean up the port pipe select bits https://patchwork.freedesktop.org/api/1.0/series/39259/revisions/1/mbox/ Possible new issues: Test core_auth: Subgroup basic-auth: pass -> INCOMPLETE (fi-ivb-3520m) pass -> INCOMPLETE (fi-snb-2520m) Known issues: Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> DMESG-WARN (fi-skl-6700k2) fdo#103191 Test prime_vgem: Subgroup basic-fence-flip: fail -> PASS (fi-byt-n2820) fdo#104008 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:416s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:423s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:370s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:479s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:277s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:476s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:478s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:465s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:454s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:391s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:567s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:415s fi-gdg-551 total:288 pass:180 dwarn:0 dfail:0 fail:0 skip:108 time:288s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:508s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:391s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:407s fi-ivb-3520m total:1pass:0dwarn:0 dfail:0 fail:0 skip:0 fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:411s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:449s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:492s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:450s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:492s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:583s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:421s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:500s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:518s fi-skl-6700k2total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:485s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:474s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:405s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:430s fi-snb-2520m total:1pass:0dwarn:0 dfail:0 fail:0 skip:0 fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:388s Blacklisted hosts: fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:494s b2e10fd5e8b2cd72b0e1eba46c1221dc3d4b70bc drm-tip: 2018y-03m-02d-09h-36m-59s UTC integration manifest a7f316764d99 drm/i915: Implement the missing bits of assert_panel_unlocked() 4f7d9bb94974 drm/i915: Allow eDP on port C in theory a89c6281509b drm/i915: Clean up DP pipe select bits 9a0df9a20aa0 drm/i915: Nuke intel_trans_dp_port_sel() c220a8c7df1b drm/i915: Parametrize TRANS_DP_PORT_SEL b98263dcfc35 drm/i915: Move intel_ddi_get_crtc_new_encoder() out from ddi code 99de9590 drm/i915: Check for IVB instead of gen7 when we think about IVB CPU eDP f17399fdd4ff drm/i915: Use the same vswing->max_preemph mapping on HSW/BDW as on SKL+ 5bb0a7d136c6 drm/i915: Use intel_ddi_dp_voltage_max() for HSW/BDW too bc1529c6bff2 drm/i915: Clean up DVO pipe select bits 3d9c866f3898 drm/i915: Clean up TV pipe select bits fe22569aa14d drm/i915: Clean up SDVO pipe select bits da99394e9b3f drm/i915: Clean up LVDS pipe select bits 1ff16b8483f3 drm/i915: Clean up ADPA pipe select bits == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8207/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 05/10] pwm: add PWM mode to pwm_config()
On 28.02.2018 22:04, Jani Nikula wrote:
> On Wed, 28 Feb 2018, Thierry Reding wrote:
>> Anyone that needs something other than normal mode should use the new
>> atomic PWM API.
>
> At the risk of revealing my true ignorance, what is the new atomic PWM
> API? Where? Examples of how one would convert old code over to the new
> API?
As far as I know, the old PWM core code uses config(), set_polarity(),
enable(), disable() methods of driver, registered as pwm_ops:
struct pwm_ops {
int (*request)(struct pwm_chip *chip, struct pwm_device *pwm);
void (*free)(struct pwm_chip *chip, struct pwm_device *pwm);
int (*config)(struct pwm_chip *chip, struct pwm_device *pwm,
int duty_ns, int period_ns);
int (*set_polarity)(struct pwm_chip *chip, struct pwm_device *pwm,
enum pwm_polarity polarity);
int (*capture)(struct pwm_chip *chip, struct pwm_device *pwm,
struct pwm_capture *result, unsigned long timeout);
int (*enable)(struct pwm_chip *chip, struct pwm_device *pwm);
void (*disable)(struct pwm_chip *chip, struct pwm_device *pwm);
int (*apply)(struct pwm_chip *chip, struct pwm_device *pwm,
struct pwm_state *state);
void (*get_state)(struct pwm_chip *chip, struct pwm_device *pwm,
struct pwm_state *state);
#ifdef CONFIG_DEBUG_FS
void (*dbg_show)(struct pwm_chip *chip, struct seq_file *s);
#endif
struct module *owner;
};
to do settings on hardware. In order to so settings on a PWM the users
should have been follow the below steps:
->config()
->set_polarity()
->enable()
Moreover, if the PWM was previously enabled it should have been first
disable and then to follow the above steps in order to apply a new settings
on hardware.
The driver should have been provide, at probe, all the above function:
->config(), ->set_polarity(), ->disable(), ->enable(), function that were
used by PWM core.
Now, having atomic PWM, the driver should provide one function to PWM core,
which is ->apply() function. Every PWM has a state associated, which keeps
the period, duty cycle, polarity and enable/disable status. The driver's
->apply() function takes as argument the state that should be applied and
it takes care of applying this new state directly without asking user to
call ->disable(), then ->config()/->set_polarity(), then ->enable() to
apply new hardware settings.
The PWM consumer could set a new state for PWM it uses, using
pwm_apply_state(pwm, new_state);
Regarding the models to switch on atomic PWM, on the controller side you
can check for drivers that registers apply function at probe time.
Regarding the PWM users, you can look for pwm_apply_state()
(drivers/hwmon/pwm-fan.c or drivers/input/misc/pwm-beeper.c are some examples).
Thierry, please correct me if I'm wrong.
Thank you,
Claudiu Beznea
>
> BR,
> Jani.
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/15] drm/i915/guc: Tidy guc_log_control
On 2/27/2018 6:22 PM, Michał Winiarski wrote:
We plan to decouple log runtime (mapping + relay) from verbosity control.
Let's tidy the code now to reduce the churn in the following patches.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_debugfs.c | 11 ++
drivers/gpu/drm/i915/intel_guc_log.c | 75 +++-
drivers/gpu/drm/i915/intel_guc_log.h | 3 +-
3 files changed, 46 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 33fbf3965309..58983cafaece 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2500,13 +2500,10 @@ static int i915_guc_log_control_get(void *data, u64
*val)
Should we name this i915_guc_log_level_get instead? and other related
functions too?
{
struct drm_i915_private *dev_priv = data;
- if (!HAS_GUC(dev_priv))
+ if (!USES_GUC(dev_priv))
return -ENODEV;
- if (!dev_priv->guc.log.vma)
- return -EINVAL;
-
- *val = i915_modparams.guc_log_level;
+ *val = intel_guc_log_control_get(&dev_priv->guc);
return 0;
}
@@ -2515,10 +2512,10 @@ static int i915_guc_log_control_set(void *data, u64 val)
{
struct drm_i915_private *dev_priv = data;
- if (!HAS_GUC(dev_priv))
+ if (!USES_GUC(dev_priv))
return -ENODEV;
- return intel_guc_log_control(&dev_priv->guc, val);
+ return intel_guc_log_control_set(&dev_priv->guc, val);
}
DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_control_fops,
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c
b/drivers/gpu/drm/i915/intel_guc_log.c
index 7b5074e2120c..22a05320817b 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -657,52 +657,55 @@ void intel_guc_log_destroy(struct intel_guc *guc)
i915_vma_unpin_and_release(&guc->log.vma);
}
-int intel_guc_log_control(struct intel_guc *guc, u64 control_val)
+int intel_guc_log_control_get(struct intel_guc *guc)
Should we be passing guc_log as parameter and implement guc_log_to_guc()
function.
+{
+ GEM_BUG_ON(!guc->log.vma);
+ GEM_BUG_ON(i915_modparams.guc_log_level < 0);
+
+ return i915_modparams.guc_log_level;
+}
+
+#define GUC_LOG_IS_ENABLED(x) (x > 0)
+#define GUC_LOG_LEVEL_TO_VERBOSITY(x) (GUC_LOG_IS_ENABLED(x) ? x - 1 : 0)
This is bit misleading, can we make this macro return -1 if logging is
to be disabled. That way guc_log_control can be invoked with
single signed 32bit parameter.
+int intel_guc_log_control_set(struct intel_guc *guc, u64 val)
{
struct drm_i915_private *dev_priv = guc_to_i915(guc);
- bool enable_logging = control_val > 0;
- u32 verbosity;
int ret;
- if (!guc->log.vma)
- return -ENODEV;
+ BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN != 0);
+ GEM_BUG_ON(!guc->log.vma);
+ GEM_BUG_ON(i915_modparams.guc_log_level < 0);
- BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN);
- if (control_val > 1 + GUC_LOG_VERBOSITY_MAX)
+ /*
+* GuC is recognizing log levels starting from 0 to max, we're using 0
+* as indication that logging should be disablded.
+*/
+ if (GUC_LOG_LEVEL_TO_VERBOSITY(val) < GUC_LOG_VERBOSITY_MIN ||
This check seems unnecessary as we currently don't have negative output
for G_L_L_T_V macro.
If we add negative value there, will need to remove this check.
+ GUC_LOG_LEVEL_TO_VERBOSITY(val) > GUC_LOG_VERBOSITY_MAX)
return -EINVAL;
- /* This combination doesn't make sense & won't have any effect */
- if (!enable_logging && !i915_modparams.guc_log_level)
- return 0;
+ mutex_lock(&dev_priv->drm.struct_mutex);
- verbosity = enable_logging ? control_val - 1 : 0;
+ if (i915_modparams.guc_log_level == val) {
+ ret = 0;
+ goto out_unlock;
+ }
- ret = mutex_lock_interruptible(&dev_priv->drm.struct_mutex);
- if (ret)
- return ret;
intel_runtime_pm_get(dev_priv);
- ret = guc_log_control(guc, enable_logging, verbosity);
+ ret = guc_log_control(guc, GUC_LOG_IS_ENABLED(val),
+ GUC_LOG_LEVEL_TO_VERBOSITY(val));
intel_runtime_pm_put(dev_priv);
- mutex_unlock(&dev_priv->drm.struct_mutex);
+ if (ret)
+ goto out_unlock;
- if (ret < 0) {
- DRM_DEBUG_DRIVER("guc_logging_control action failed %d\n", ret);
- return ret;
- }
+ i915_modparams.guc_log_level = val;
- if (enable_logging) {
- i915_modparams.guc_log_level = 1 + verbosity;
+ mutex_unlock(&dev_priv->drm.struct_mutex);
- /*
-* If log was disabled at boot time, then the relay channel file
-* wouldn't have been cre
Re: [Intel-gfx] [PATCH i-g-t v2] tests/perf_pmu: Handle CPU hotplug failures better
On Wed, Feb 28, 2018 at 10:05:55AM +, Tvrtko Ursulin wrote:
> From: Chris Wilson
>
> CPU hotplug, especially CPU0, can be flaky on commodity hardware.
>
> To improve test reliability and reponse times when testing larger runs we
> need to handle those cases better.
>
> Handle failures to off-line a CPU by immediately skipping the test, and
> failures to on-line a CPU by immediately rebooting the machine.
>
> This patch includes igt_sysrq_reboot implementation from Chris Wilson.
>
> v2: Halt by default, reboot if env variable IGT_REBOOT_ON_FATAL_ERROR is
> set. (Petri Latvala)
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
> Cc: Petri Latvala
> Cc: Tomi Sarvela
Reviewed-by: Petri Latvala
with two nitpicks below.
> ---
> lib/Makefile.sources | 2 ++
> lib/igt_core.c | 23 +++
> lib/igt_core.h | 1 +
> lib/igt_sysrq.c | 22 ++
> lib/igt_sysrq.h | 30 ++
> lib/meson.build | 1 +
> tests/perf_pmu.c | 38 +++---
> 7 files changed, 110 insertions(+), 7 deletions(-)
> create mode 100644 lib/igt_sysrq.c
> create mode 100644 lib/igt_sysrq.h
>
> diff --git a/lib/Makefile.sources b/lib/Makefile.sources
> index 5b13ef8896c0..3d37ef1d1984 100644
> --- a/lib/Makefile.sources
> +++ b/lib/Makefile.sources
> @@ -35,6 +35,8 @@ lib_source_list = \
> igt_stats.h \
> igt_sysfs.c \
> igt_sysfs.h \
> + igt_sysrq.c \
> + igt_sysrq.h \
> igt_x86.h \
> igt_x86.c \
> igt_vgem.c \
> diff --git a/lib/igt_core.c b/lib/igt_core.c
> index c292343de09e..3fd9f529f09f 100644
> --- a/lib/igt_core.c
> +++ b/lib/igt_core.c
> @@ -70,6 +70,7 @@
> #include "igt_core.h"
> #include "igt_aux.h"
> #include "igt_sysfs.h"
> +#include "igt_sysrq.h"
> #include "igt_rc.h"
>
> #define UNW_LOCAL_ONLY
> @@ -1136,6 +1137,28 @@ void igt_fail(int exitcode)
> }
> }
>
> +/**
> + * igt_fatal_error:
> + *
> + * Stop test execution or optionally, if the IGT_REBOOT_ON_FATAL_ERROR
> + * environment variable is set, reboot the machine.
> + *
> + * Since out test runner (piglit) does support fatal test exit codes, we
> + * implement the default behaviour by waiting endlessly.
> + */
> +void __attribute__((noreturn)) igt_fatal_error(void)
> +{
> + if (igt_check_boolean_env_var("IGT_REBOOT_ON_FATAL_ERROR", false)) {
> + igt_warn("FATAL ERROR - REBOOTING");
> + igt_sysrq_reboot();
> + } else {
> + igt_warn("FATAL ERROR");
> + for (;;)
> + sleep(60);
> + }
> +}
> +
> +
> /**
> * igt_can_fail:
> *
> diff --git a/lib/igt_core.h b/lib/igt_core.h
> index 7af2b4c109fe..66523a208c31 100644
> --- a/lib/igt_core.h
> +++ b/lib/igt_core.h
> @@ -311,6 +311,7 @@ void __igt_fail_assert(const char *domain, const char
> *file,
> const char *format, ...)
> __attribute__((noreturn));
> void igt_exit(void) __attribute__((noreturn));
> +void igt_fatal_error(void) __attribute__((noreturn));
>
> /**
> * igt_ignore_warn:
> diff --git a/lib/igt_sysrq.c b/lib/igt_sysrq.c
> new file mode 100644
> index ..fe3d2e344ff1
> --- /dev/null
> +++ b/lib/igt_sysrq.c
> @@ -0,0 +1,22 @@
> +#include
> +#include
> +#include
> +#include
> +
> +#include "igt_core.h"
> +
> +#include "igt_sysrq.h"
> +
Docs for igt_sysrq_reboot?
> +void igt_sysrq_reboot(void)
> +{
> + sync();
> +
> + /* Try to be nice at first, and if that fails pull the trigger */
> + if (reboot(RB_AUTOBOOT)) {
> + int fd = open("/proc/sysrq-trigger", O_WRONLY);
> + igt_ignore_warn(write(fd, "b", 2));
> + close(fd);
> + }
> +
> + abort();
> +}
> diff --git a/lib/igt_sysrq.h b/lib/igt_sysrq.h
> new file mode 100644
> index ..422473d2a480
> --- /dev/null
> +++ b/lib/igt_sysrq.h
> @@ -0,0 +1,30 @@
> +/*
> + * Copyright © 2018 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Kill the remaining CHV HBR2 leftovers
== Series Details == Series: drm/i915: Kill the remaining CHV HBR2 leftovers URL : https://patchwork.freedesktop.org/series/39260/ State : success == Summary == Series 39260v1 drm/i915: Kill the remaining CHV HBR2 leftovers https://patchwork.freedesktop.org/api/1.0/series/39260/revisions/1/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: incomplete -> PASS (fi-snb-2520m) fdo#103713 Test prime_vgem: Subgroup basic-fence-flip: fail -> PASS (fi-byt-n2820) fdo#104008 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:414s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:423s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:370s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:481s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:277s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:480s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:462s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:453s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:393s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:567s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:415s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:289s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:506s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:384s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:413s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:443s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:413s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:450s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:489s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:452s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:494s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:581s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:423s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:499s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:516s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:489s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:466s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:406s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:429s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:519s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:386s Blacklisted hosts: fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:490s fi-bxt-dsi failed to collect. IGT log at Patchwork_8208/fi-bxt-dsi/run0.log b2e10fd5e8b2cd72b0e1eba46c1221dc3d4b70bc drm-tip: 2018y-03m-02d-09h-36m-59s UTC integration manifest bd80036a0d46 drm/i915: Kill the remaining CHV HBR2 leftovers == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8208/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v3] tests/perf_pmu: Handle CPU hotplug failures better
From: Chris Wilson
CPU hotplug, especially CPU0, can be flaky on commodity hardware.
To improve test reliability and reponse times when testing larger runs we
need to handle those cases better.
Handle failures to off-line a CPU by immediately skipping the test, and
failures to on-line a CPU by immediately rebooting the machine.
This patch includes igt_sysrq_reboot implementation from Chris Wilson.
v2: Halt by default, reboot if env variable IGT_REBOOT_ON_FATAL_ERROR is
set. (Petri Latvala)
v3: Add missign docs and update stale comment. (Petri Latvala)
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Petri Latvala
Cc: Tomi Sarvela
Reviewed-by: Petri Latvala
---
lib/Makefile.sources | 2 ++
lib/igt_core.c | 23 +++
lib/igt_core.h | 1 +
lib/igt_sysrq.c | 27 +++
lib/igt_sysrq.h | 30 ++
lib/meson.build | 1 +
tests/perf_pmu.c | 38 +++---
7 files changed, 115 insertions(+), 7 deletions(-)
create mode 100644 lib/igt_sysrq.c
create mode 100644 lib/igt_sysrq.h
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 5b13ef8896c0..3d37ef1d1984 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -35,6 +35,8 @@ lib_source_list = \
igt_stats.h \
igt_sysfs.c \
igt_sysfs.h \
+ igt_sysrq.c \
+ igt_sysrq.h \
igt_x86.h \
igt_x86.c \
igt_vgem.c \
diff --git a/lib/igt_core.c b/lib/igt_core.c
index c292343de09e..d64c25e1217b 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -70,6 +70,7 @@
#include "igt_core.h"
#include "igt_aux.h"
#include "igt_sysfs.h"
+#include "igt_sysrq.h"
#include "igt_rc.h"
#define UNW_LOCAL_ONLY
@@ -1136,6 +1137,28 @@ void igt_fail(int exitcode)
}
}
+/**
+ * igt_fatal_error: Stop test execution on fatal errors
+ *
+ * Stop test execution or optionally, if the IGT_REBOOT_ON_FATAL_ERROR
+ * environment variable is set, reboot the machine.
+ *
+ * Since out test runner (piglit) does support fatal test exit codes, we
+ * implement the default behaviour by waiting endlessly.
+ */
+void __attribute__((noreturn)) igt_fatal_error(void)
+{
+ if (igt_check_boolean_env_var("IGT_REBOOT_ON_FATAL_ERROR", false)) {
+ igt_warn("FATAL ERROR - REBOOTING");
+ igt_sysrq_reboot();
+ } else {
+ igt_warn("FATAL ERROR");
+ for (;;)
+ sleep(60);
+ }
+}
+
+
/**
* igt_can_fail:
*
diff --git a/lib/igt_core.h b/lib/igt_core.h
index 7af2b4c109fe..66523a208c31 100644
--- a/lib/igt_core.h
+++ b/lib/igt_core.h
@@ -311,6 +311,7 @@ void __igt_fail_assert(const char *domain, const char *file,
const char *format, ...)
__attribute__((noreturn));
void igt_exit(void) __attribute__((noreturn));
+void igt_fatal_error(void) __attribute__((noreturn));
/**
* igt_ignore_warn:
diff --git a/lib/igt_sysrq.c b/lib/igt_sysrq.c
new file mode 100644
index ..3bda321f7c5b
--- /dev/null
+++ b/lib/igt_sysrq.c
@@ -0,0 +1,27 @@
+#include
+#include
+#include
+#include
+
+#include "igt_core.h"
+
+#include "igt_sysrq.h"
+
+/**
+ * igt_sysrq_reboot: Reboots the machine
+ *
+ * Syncs filesystems and immediately reboots the machine.
+ */
+void igt_sysrq_reboot(void)
+{
+ sync();
+
+ /* Try to be nice at first, and if that fails pull the trigger */
+ if (reboot(RB_AUTOBOOT)) {
+ int fd = open("/proc/sysrq-trigger", O_WRONLY);
+ igt_ignore_warn(write(fd, "b", 2));
+ close(fd);
+ }
+
+ abort();
+}
diff --git a/lib/igt_sysrq.h b/lib/igt_sysrq.h
new file mode 100644
index ..422473d2a480
--- /dev/null
+++ b/lib/igt_sysrq.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
Re: [Intel-gfx] [PATCH i-g-t v2] tests/perf_pmu: Handle CPU hotplug failures better
Quoting Petri Latvala (2018-03-02 11:12:19)
> On Wed, Feb 28, 2018 at 10:05:55AM +, Tvrtko Ursulin wrote:
> > +/**
> > + * igt_fatal_error:
> > + *
> > + * Stop test execution or optionally, if the IGT_REBOOT_ON_FATAL_ERROR
> > + * environment variable is set, reboot the machine.
> > + *
> > + * Since out test runner (piglit) does support fatal test exit codes, we
> > + * implement the default behaviour by waiting endlessly.
> > + */
> > +void __attribute__((noreturn)) igt_fatal_error(void)
> > +{
> > + if (igt_check_boolean_env_var("IGT_REBOOT_ON_FATAL_ERROR", false)) {
> > + igt_warn("FATAL ERROR - REBOOTING");
> > + igt_sysrq_reboot();
> > + } else {
> > + igt_warn("FATAL ERROR");
> > + for (;;)
> > + sleep(60);
s/sleep/pause/
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Stop engines around GPU reset preparations
As we make preparations to reset the GPU state, we assume that the GPU
is hung and will not advance. Make this assumption more explicit by
setting the STOP_RING bit on the engines as part of our early reset
preparations.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michel Thierry
---
See
https://intel-gfx-ci.01.org/tree/drm-tip/kasan_15/fi-bdw-5557u/pstore22-1519879816_Panic_3.log
for a bizarre error that kasan-farm keeps on trying over. Maybe related
to this?
---
drivers/gpu/drm/i915/i915_drv.c | 3 +++
drivers/gpu/drm/i915/i915_drv.h | 10 --
drivers/gpu/drm/i915/intel_uncore.c | 33 +
3 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index aaa861b51024..925f5722d077 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1908,6 +1908,8 @@ void i915_reset(struct drm_i915_private *i915, unsigned
int flags)
error->reset_count++;
disable_irq(i915->drm.irq);
+ intel_gpu_reset_prepare(i915, ALL_ENGINES);
+
ret = i915_gem_reset_prepare(i915);
if (ret) {
dev_err(i915->drm.dev, "GPU recovery failed\n");
@@ -1969,6 +1971,7 @@ void i915_reset(struct drm_i915_private *i915, unsigned
int flags)
finish:
i915_gem_reset_finish(i915);
+ intel_gpu_reset_finish(i915, ALL_ENGINES);
enable_irq(i915->drm.irq);
wakeup:
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 10c9e5e619ab..b95e675e0834 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2957,8 +2957,14 @@ extern const struct dev_pm_ops i915_pm_ops;
extern int i915_driver_load(struct pci_dev *pdev,
const struct pci_device_id *ent);
extern void i915_driver_unload(struct drm_device *dev);
-extern int intel_gpu_reset(struct drm_i915_private *dev_priv, u32 engine_mask);
-extern bool intel_has_gpu_reset(struct drm_i915_private *dev_priv);
+
+bool intel_has_gpu_reset(struct drm_i915_private *dev_priv);
+
+void intel_gpu_reset_prepare(struct drm_i915_private *dev_priv,
+unsigned engine_mask);
+int intel_gpu_reset(struct drm_i915_private *dev_priv, u32 engine_mask);
+void intel_gpu_reset_finish(struct drm_i915_private *dev_priv,
+ unsigned engine_mask);
#define I915_RESET_QUIET BIT(0)
extern void i915_reset(struct drm_i915_private *i915, unsigned int flags);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 5ae9a62712ca..7186fe4d2ba9 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1899,6 +1899,29 @@ static reset_func intel_get_gpu_reset(struct
drm_i915_private *dev_priv)
return NULL;
}
+static void i915_engines_set_mode(struct drm_i915_private *dev_priv,
+ unsigned engine_mask,
+ u32 mode)
+{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ if (INTEL_GEN(dev_priv) < 3)
+ return;
+
+ for_each_engine_masked(engine, dev_priv, engine_mask, id)
+ I915_WRITE_FW(RING_MI_MODE(engine->mmio_base), mode);
+}
+
+void intel_gpu_reset_prepare(struct drm_i915_private *dev_priv,
+unsigned engine_mask)
+{
+ intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+
+ i915_engines_set_mode(dev_priv, engine_mask,
+ _MASKED_BIT_ENABLE(STOP_RING));
+}
+
int intel_gpu_reset(struct drm_i915_private *dev_priv, unsigned engine_mask)
{
reset_func reset = intel_get_gpu_reset(dev_priv);
@@ -1939,6 +1962,16 @@ int intel_gpu_reset(struct drm_i915_private *dev_priv,
unsigned engine_mask)
return ret;
}
+void intel_gpu_reset_finish(struct drm_i915_private *dev_priv,
+ unsigned engine_mask)
+{
+ /* Clear the STOP_RING bit as the reset may not have occurred */
+ i915_engines_set_mode(dev_priv, engine_mask,
+ _MASKED_BIT_DISABLE(STOP_RING));
+
+ intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+}
+
bool intel_has_gpu_reset(struct drm_i915_private *dev_priv)
{
return intel_get_gpu_reset(dev_priv) != NULL;
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Suspend submission tasklets around wedging
After starting hard at sequences like
[ 28.199013] systemd-1 2..s. 26062228us :
execlists_submission_tasklet: rcs0 cs-irq head=0 [0?], tail=1 [1?]
[ 28.199095] systemd-1 2..s. 26062229us :
execlists_submission_tasklet: rcs0 csb[1]: status=0x0018:0x,
active=0x1
[ 28.199177] systemd-1 2..s. 26062230us :
execlists_submission_tasklet: rcs0 out[0]: ctx=0.1, seqno=3, prio=-1024
[ 28.199258] systemd-1 2..s. 26062231us :
execlists_submission_tasklet: rcs0 completed ctx=0
[ 28.199340] gem_eio-829 1..s1 26066853us :
execlists_submission_tasklet: rcs0 in[0]: ctx=1.1, seqno=1, prio=0
[ 28.199421] -0 2..s. 26066863us :
execlists_submission_tasklet: rcs0 cs-irq head=1 [1?], tail=2 [2?]
[ 28.199503] -0 2..s. 26066865us :
execlists_submission_tasklet: rcs0 csb[2]: status=0x0001:0x,
active=0x1
[ 28.199585] gem_eio-829 1..s1 26067077us :
execlists_submission_tasklet: rcs0 in[1]: ctx=3.1, seqno=2, prio=0
[ 28.199667] gem_eio-829 1..s1 26067078us :
execlists_submission_tasklet: rcs0 in[0]: ctx=1.2, seqno=1, prio=0
[ 28.199749] -0 2..s. 26067084us :
execlists_submission_tasklet: rcs0 cs-irq head=2 [2?], tail=3 [3?]
[ 28.199830] -0 2..s. 26067085us :
execlists_submission_tasklet: rcs0 csb[3]: status=0x8002:0x0001,
active=0x1
[ 28.199912] -0 2..s. 26067086us :
execlists_submission_tasklet: rcs0 out[0]: ctx=1.2, seqno=1, prio=0
[ 28.14] gem_eio-829 2..s. 28246084us :
execlists_submission_tasklet: rcs0 cs-irq head=3 [3?], tail=4 [4?]
[ 28.200096] gem_eio-829 2..s. 28246088us :
execlists_submission_tasklet: rcs0 csb[4]: status=0x0014:0x0001,
active=0x5
[ 28.200178] gem_eio-829 2..s. 28246089us :
execlists_submission_tasklet: rcs0 out[0]: ctx=0.0, seqno=0, prio=0
[ 28.200260] gem_eio-829 2..s. 28246127us :
execlists_submission_tasklet: execlists_submission_tasklet:886 GEM_BUG_ON(buf[2
* head + 1] != port->context_id)
the conclusion is that the only place where the ports are reset to zero,
is from engine->cancel_requests called during i915_gem_set_wedged().
The race is horrible as it results from calling set-wedged on active HW
(the GPU reset failed) and as such we need to be careful as the HW state
changes beneath us. Fortunately, it's the same scary conditions as
affect normal reset, so we can reuse the same machinery to disable state
tracking as we clobber it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104945
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem.c | 6 +-
drivers/gpu/drm/i915/intel_lrc.c | 5 +
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c29b1a1cbe96..dcdcc09240b9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3212,8 +3212,10 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
* rolling the global seqno forward (since this would complete requests
* for which we haven't set the fence error to EIO yet).
*/
- for_each_engine(engine, i915, id)
+ for_each_engine(engine, i915, id) {
+ i915_gem_reset_prepare_engine(engine);
engine->submit_request = nop_submit_request;
+ }
/*
* Make sure no one is running the old callback before we proceed with
@@ -3255,6 +3257,8 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
intel_engine_init_global_seqno(engine,
intel_engine_last_submit(engine));
spin_unlock_irqrestore(&engine->timeline->lock, flags);
+
+ i915_gem_reset_finish_engine(engine);
}
wake_up_all(&i915->gpu_error.reset_queue);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 14288743909f..c1a3636e94fc 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -687,6 +687,8 @@ static void execlists_cancel_requests(struct
intel_engine_cs *engine)
struct rb_node *rb;
unsigned long flags;
+ GEM_TRACE("%s\n", engine->name);
+
spin_lock_irqsave(&engine->timeline->lock, flags);
/* Cancel the requests on the HW and clear the ELSP tracker. */
@@ -733,6 +735,9 @@ static void execlists_cancel_requests(struct
intel_engine_cs *engine)
*/
clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
+ /* Mark all CS interrupts as complete */
+ execlists->active = 0;
+
spin_unlock_irqrestore(&engine->timeline->lock, flags);
}
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v4] tests/perf_pmu: Handle CPU hotplug failures better
From: Chris Wilson
CPU hotplug, especially CPU0, can be flaky on commodity hardware.
To improve test reliability and reponse times when testing larger runs we
need to handle those cases better.
Handle failures to off-line a CPU by immediately skipping the test, and
failures to on-line a CPU by immediately rebooting the machine.
This patch includes igt_sysrq_reboot implementation from Chris Wilson.
v2: Halt by default, reboot if env variable IGT_REBOOT_ON_FATAL_ERROR is
set. (Petri Latvala)
v3: Add missign docs and update stale comment. (Petri Latvala)
v4: Use pause instead of sleep. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Petri Latvala
Cc: Tomi Sarvela
Reviewed-by: Petri Latvala
---
lib/Makefile.sources | 2 ++
lib/igt_core.c | 23 +++
lib/igt_core.h | 1 +
lib/igt_sysrq.c | 27 +++
lib/igt_sysrq.h | 30 ++
lib/meson.build | 1 +
tests/perf_pmu.c | 38 +++---
7 files changed, 115 insertions(+), 7 deletions(-)
create mode 100644 lib/igt_sysrq.c
create mode 100644 lib/igt_sysrq.h
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 5b13ef8896c0..3d37ef1d1984 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -35,6 +35,8 @@ lib_source_list = \
igt_stats.h \
igt_sysfs.c \
igt_sysfs.h \
+ igt_sysrq.c \
+ igt_sysrq.h \
igt_x86.h \
igt_x86.c \
igt_vgem.c \
diff --git a/lib/igt_core.c b/lib/igt_core.c
index c292343de09e..46285ac32432 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -70,6 +70,7 @@
#include "igt_core.h"
#include "igt_aux.h"
#include "igt_sysfs.h"
+#include "igt_sysrq.h"
#include "igt_rc.h"
#define UNW_LOCAL_ONLY
@@ -1136,6 +1137,28 @@ void igt_fail(int exitcode)
}
}
+/**
+ * igt_fatal_error: Stop test execution on fatal errors
+ *
+ * Stop test execution or optionally, if the IGT_REBOOT_ON_FATAL_ERROR
+ * environment variable is set, reboot the machine.
+ *
+ * Since out test runner (piglit) does support fatal test exit codes, we
+ * implement the default behaviour by waiting endlessly.
+ */
+void __attribute__((noreturn)) igt_fatal_error(void)
+{
+ if (igt_check_boolean_env_var("IGT_REBOOT_ON_FATAL_ERROR", false)) {
+ igt_warn("FATAL ERROR - REBOOTING");
+ igt_sysrq_reboot();
+ } else {
+ igt_warn("FATAL ERROR");
+ for (;;)
+ pause();
+ }
+}
+
+
/**
* igt_can_fail:
*
diff --git a/lib/igt_core.h b/lib/igt_core.h
index 7af2b4c109fe..66523a208c31 100644
--- a/lib/igt_core.h
+++ b/lib/igt_core.h
@@ -311,6 +311,7 @@ void __igt_fail_assert(const char *domain, const char *file,
const char *format, ...)
__attribute__((noreturn));
void igt_exit(void) __attribute__((noreturn));
+void igt_fatal_error(void) __attribute__((noreturn));
/**
* igt_ignore_warn:
diff --git a/lib/igt_sysrq.c b/lib/igt_sysrq.c
new file mode 100644
index ..3bda321f7c5b
--- /dev/null
+++ b/lib/igt_sysrq.c
@@ -0,0 +1,27 @@
+#include
+#include
+#include
+#include
+
+#include "igt_core.h"
+
+#include "igt_sysrq.h"
+
+/**
+ * igt_sysrq_reboot: Reboots the machine
+ *
+ * Syncs filesystems and immediately reboots the machine.
+ */
+void igt_sysrq_reboot(void)
+{
+ sync();
+
+ /* Try to be nice at first, and if that fails pull the trigger */
+ if (reboot(RB_AUTOBOOT)) {
+ int fd = open("/proc/sysrq-trigger", O_WRONLY);
+ igt_ignore_warn(write(fd, "b", 2));
+ close(fd);
+ }
+
+ abort();
+}
diff --git a/lib/igt_sysrq.h b/lib/igt_sysrq.h
new file mode 100644
index ..422473d2a480
--- /dev/null
+++ b/lib/igt_sysrq.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABIL
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Stop engines around GPU reset preparations
== Series Details == Series: drm/i915: Stop engines around GPU reset preparations URL : https://patchwork.freedesktop.org/series/39261/ State : success == Summary == Series 39261v1 drm/i915: Stop engines around GPU reset preparations https://patchwork.freedesktop.org/api/1.0/series/39261/revisions/1/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: incomplete -> PASS (fi-snb-2520m) fdo#103713 Test prime_vgem: Subgroup basic-fence-flip: fail -> PASS (fi-byt-n2820) fdo#104008 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:415s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:420s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:370s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:480s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:277s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:478s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:482s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:465s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:456s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:390s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:561s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:414s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:289s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:506s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:384s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:407s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:451s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:414s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:453s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:493s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:449s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:494s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:583s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:424s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:502s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:516s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:489s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:479s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:409s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:429s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:524s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:390s Blacklisted hosts: fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:496s b2e10fd5e8b2cd72b0e1eba46c1221dc3d4b70bc drm-tip: 2018y-03m-02d-09h-36m-59s UTC integration manifest 8e51b8d3db3c drm/i915: Stop engines around GPU reset preparations == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8209/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v4] tests/perf_pmu: Handle CPU hotplug failures better
Quoting Tvrtko Ursulin (2018-03-02 11:39:12)
> +/**
> + * igt_fatal_error: Stop test execution on fatal errors
> + *
> + * Stop test execution or optionally, if the IGT_REBOOT_ON_FATAL_ERROR
> + * environment variable is set, reboot the machine.
> + *
> + * Since out test runner (piglit) does support fatal test exit codes, we
> + * implement the default behaviour by waiting endlessly.
> + */
> +void __attribute__((noreturn)) igt_fatal_error(void)
> +{
> + if (igt_check_boolean_env_var("IGT_REBOOT_ON_FATAL_ERROR", false)) {
> + igt_warn("FATAL ERROR - REBOOTING");
+ "\n"
> + igt_sysrq_reboot();
> + } else {
> + igt_warn("FATAL ERROR");
+ "\n"
igt_emergency() ? Would help with mapping kmsg into igt loglevels :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915/uc: Introduce intel_uc_suspend|resume
We want to use higher level 'uc' functions as the main entry points to
the GuC/HuC code to hide some details and keep code layered.
While here, move call to disable_guc_interrupts after sending suspend
action to the GuC to allow it work also with CTB as comm mechanism.
v2: update commit msg (Sagar)
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
Reviewed-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_drv.c | 6 +++---
drivers/gpu/drm/i915/i915_gem.c | 4 ++--
drivers/gpu/drm/i915/intel_guc.c | 42 +
drivers/gpu/drm/i915/intel_guc.h | 4 ++--
drivers/gpu/drm/i915/intel_uc.c | 45
drivers/gpu/drm/i915/intel_uc.h | 2 ++
6 files changed, 68 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index aaa861b..d61b51c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2575,7 +2575,7 @@ static int intel_runtime_suspend(struct device *kdev)
*/
i915_gem_runtime_suspend(dev_priv);
- intel_guc_suspend(dev_priv);
+ intel_uc_suspend(dev_priv);
intel_runtime_pm_disable_interrupts(dev_priv);
@@ -2597,7 +2597,7 @@ static int intel_runtime_suspend(struct device *kdev)
intel_runtime_pm_enable_interrupts(dev_priv);
- intel_guc_resume(dev_priv);
+ intel_uc_resume(dev_priv);
i915_gem_init_swizzling(dev_priv);
i915_gem_restore_fences(dev_priv);
@@ -2683,7 +2683,7 @@ static int intel_runtime_resume(struct device *kdev)
intel_runtime_pm_enable_interrupts(dev_priv);
- intel_guc_resume(dev_priv);
+ intel_uc_resume(dev_priv);
/*
* No point of rolling back things in case of an error, as the best
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c29b1a1..8d107f2 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4916,7 +4916,7 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
i915_gem_contexts_lost(dev_priv);
mutex_unlock(&dev->struct_mutex);
- intel_guc_suspend(dev_priv);
+ intel_uc_suspend(dev_priv);
cancel_delayed_work_sync(&dev_priv->gpu_error.hangcheck_work);
cancel_delayed_work_sync(&dev_priv->gt.retire_work);
@@ -4983,7 +4983,7 @@ void i915_gem_resume(struct drm_i915_private *i915)
if (i915_gem_init_hw(i915))
goto err_wedged;
- intel_guc_resume(i915);
+ intel_uc_resume(i915);
/* Always reload a context for powersaving. */
if (i915_gem_switch_to_kernel_context(i915))
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index e6512cc..ff08ea0 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -403,22 +403,15 @@ int intel_guc_auth_huc(struct intel_guc *guc, u32
rsa_offset)
/**
* intel_guc_suspend() - notify GuC entering suspend state
- * @dev_priv: i915 device private
+ * @guc: the guc
*/
-int intel_guc_suspend(struct drm_i915_private *dev_priv)
+int intel_guc_suspend(struct intel_guc *guc)
{
- struct intel_guc *guc = &dev_priv->guc;
- u32 data[3];
-
- if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
- return 0;
-
- gen9_disable_guc_interrupts(dev_priv);
-
- data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
- /* any value greater than GUC_POWER_D0 */
- data[1] = GUC_POWER_D1;
- data[2] = guc_ggtt_offset(guc->shared_data);
+ u32 data[] = {
+ INTEL_GUC_ACTION_ENTER_S_STATE,
+ GUC_POWER_D1, /* any value greater than GUC_POWER_D0 */
+ guc_ggtt_offset(guc->shared_data)
+ };
return intel_guc_send(guc, data, ARRAY_SIZE(data));
}
@@ -448,22 +441,15 @@ int intel_guc_reset_engine(struct intel_guc *guc,
/**
* intel_guc_resume() - notify GuC resuming from suspend state
- * @dev_priv: i915 device private
+ * @guc: the guc
*/
-int intel_guc_resume(struct drm_i915_private *dev_priv)
+int intel_guc_resume(struct intel_guc *guc)
{
- struct intel_guc *guc = &dev_priv->guc;
- u32 data[3];
-
- if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
- return 0;
-
- if (i915_modparams.guc_log_level)
- gen9_enable_guc_interrupts(dev_priv);
-
- data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
- data[1] = GUC_POWER_D0;
- data[2] = guc_ggtt_offset(guc->shared_data);
+ u32 data[] = {
+ INTEL_GUC_ACTION_EXIT_S_STATE,
+ GUC_POWER_D0,
+ guc_ggtt_offset(guc->shared_data)
+ };
return intel_guc_send(guc, data, ARRAY_SIZE(data));
}
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 52856a9..b9424ac 100644
--- a/drivers/gpu/drm/i915/in
[Intel-gfx] [PATCH v2 2/2] HAX: Enable GuC for CI
v2: except running with HYPERVISOR Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_uc.c| 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 430f5f9..3deae1e 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -47,7 +47,7 @@ param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, 0) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index e5bf0d3..b57c415 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct drm_i915_private *dev_priv) enable_guc |= ENABLE_GUC_LOAD_HUC; /* Any platform specific fine-tuning can be done here */ + if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) + enable_guc = 0; return enable_guc; } -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/15] drm/i915/guc: Tidy guc_log_control
On Fri, Mar 02, 2018 at 04:39:38PM +0530, Sagar Arun Kamble wrote:
>
>
> On 2/27/2018 6:22 PM, Michał Winiarski wrote:
> > We plan to decouple log runtime (mapping + relay) from verbosity control.
> > Let's tidy the code now to reduce the churn in the following patches.
> >
> > Signed-off-by: Michał Winiarski
> > Cc: Chris Wilson
> > Cc: Daniele Ceraolo Spurio
> > Cc: Michal Wajdeczko
> > Cc: Sagar Arun Kamble
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 11 ++
> > drivers/gpu/drm/i915/intel_guc_log.c | 75
> > +++-
> > drivers/gpu/drm/i915/intel_guc_log.h | 3 +-
> > 3 files changed, 46 insertions(+), 43 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 33fbf3965309..58983cafaece 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2500,13 +2500,10 @@ static int i915_guc_log_control_get(void *data, u64
> > *val)
> Should we name this i915_guc_log_level_get instead? and other related
> functions too?
I chose symmetry here, note that the debugfs file is still named
i915_guc_log_control at this point. This changes later in the series though.
> > {
> > struct drm_i915_private *dev_priv = data;
> > - if (!HAS_GUC(dev_priv))
> > + if (!USES_GUC(dev_priv))
> > return -ENODEV;
> > - if (!dev_priv->guc.log.vma)
> > - return -EINVAL;
> > -
> > - *val = i915_modparams.guc_log_level;
> > + *val = intel_guc_log_control_get(&dev_priv->guc);
> > return 0;
> > }
> > @@ -2515,10 +2512,10 @@ static int i915_guc_log_control_set(void *data, u64
> > val)
> > {
> > struct drm_i915_private *dev_priv = data;
> > - if (!HAS_GUC(dev_priv))
> > + if (!USES_GUC(dev_priv))
> > return -ENODEV;
> > - return intel_guc_log_control(&dev_priv->guc, val);
> > + return intel_guc_log_control_set(&dev_priv->guc, val);
> > }
> > DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_control_fops,
> > diff --git a/drivers/gpu/drm/i915/intel_guc_log.c
> > b/drivers/gpu/drm/i915/intel_guc_log.c
> > index 7b5074e2120c..22a05320817b 100644
> > --- a/drivers/gpu/drm/i915/intel_guc_log.c
> > +++ b/drivers/gpu/drm/i915/intel_guc_log.c
> > @@ -657,52 +657,55 @@ void intel_guc_log_destroy(struct intel_guc *guc)
> > i915_vma_unpin_and_release(&guc->log.vma);
> > }
> > -int intel_guc_log_control(struct intel_guc *guc, u64 control_val)
> > +int intel_guc_log_control_get(struct intel_guc *guc)
> Should we be passing guc_log as parameter and implement guc_log_to_guc()
> function.
This is the top-level interface exported for GuC users. In other words - callers
of this function shouldn't have to know about struct guc_log (and the fact that
it's located inside struct intel_guc).
> > +{
> > + GEM_BUG_ON(!guc->log.vma);
> > + GEM_BUG_ON(i915_modparams.guc_log_level < 0);
> > +
> > + return i915_modparams.guc_log_level;
> > +}
> > +
> > +#define GUC_LOG_IS_ENABLED(x) (x > 0)
> > +#define GUC_LOG_LEVEL_TO_VERBOSITY(x) (GUC_LOG_IS_ENABLED(x) ? x - 1
> > : 0)
> This is bit misleading, can we make this macro return -1 if logging is to be
> disabled. That way guc_log_control can be invoked with
> single signed 32bit parameter.
Note that guc_log_control is the function operating directly on GuC interface.
This Host2GuC action really takes 3 arguments (2 parameters here) - enable,
default_logging_enable, verbosity.
As a consequence, I'd like to avoid placing any logic there. The macros are
taking care of translation from guc_log_level modparam to values understood by
GuC (host2guc params).
I agree that the naming is confusing here.
I'll go with LOG_LEVEL_TO_ENABLED(x) and LOG_LEVEL_TO_VERBOSITY(x) in second
spin as suggested by Michał.
> > +int intel_guc_log_control_set(struct intel_guc *guc, u64 val)
> > {
> > struct drm_i915_private *dev_priv = guc_to_i915(guc);
> > - bool enable_logging = control_val > 0;
> > - u32 verbosity;
> > int ret;
> > - if (!guc->log.vma)
> > - return -ENODEV;
> > + BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN != 0);
> > + GEM_BUG_ON(!guc->log.vma);
> > + GEM_BUG_ON(i915_modparams.guc_log_level < 0);
> > - BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN);
> > - if (control_val > 1 + GUC_LOG_VERBOSITY_MAX)
> > + /*
> > +* GuC is recognizing log levels starting from 0 to max, we're using 0
> > +* as indication that logging should be disablded.
> > +*/
> > + if (GUC_LOG_LEVEL_TO_VERBOSITY(val) < GUC_LOG_VERBOSITY_MIN ||
> This check seems unnecessary as we currently don't have negative output for
> G_L_L_T_V macro.
> If we add negative value there, will need to remove this check.
Yeah, agree. That's an error on my part, I wanted to do input validation here.
This should probably be something more like:
if (val < VERBOSITY_TO_LOG_LEVEL(GUC_LOG_VERBOSITY_MIN) ||
val > VERBOSITY_TO_LOG_LEVEL(GUC_LOG_VERBOSITY_MAX))
-Michał
> > + GUC_
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Stop engines around GPU reset preparations
Chris Wilson writes:
> As we make preparations to reset the GPU state, we assume that the GPU
> is hung and will not advance. Make this assumption more explicit by
> setting the STOP_RING bit on the engines as part of our early reset
> preparations.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Michel Thierry
> ---
> See
> https://intel-gfx-ci.01.org/tree/drm-tip/kasan_15/fi-bdw-5557u/pstore22-1519879816_Panic_3.log
> for a bizarre error that kasan-farm keeps on trying over. Maybe related
> to this?
> ---
> drivers/gpu/drm/i915/i915_drv.c | 3 +++
> drivers/gpu/drm/i915/i915_drv.h | 10 --
> drivers/gpu/drm/i915/intel_uncore.c | 33 +
> 3 files changed, 44 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index aaa861b51024..925f5722d077 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1908,6 +1908,8 @@ void i915_reset(struct drm_i915_private *i915, unsigned
> int flags)
> error->reset_count++;
>
> disable_irq(i915->drm.irq);
> + intel_gpu_reset_prepare(i915, ALL_ENGINES);
> +
> ret = i915_gem_reset_prepare(i915);
> if (ret) {
> dev_err(i915->drm.dev, "GPU recovery failed\n");
> @@ -1969,6 +1971,7 @@ void i915_reset(struct drm_i915_private *i915, unsigned
> int flags)
>
> finish:
> i915_gem_reset_finish(i915);
> + intel_gpu_reset_finish(i915, ALL_ENGINES);
> enable_irq(i915->drm.irq);
>
> wakeup:
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 10c9e5e619ab..b95e675e0834 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2957,8 +2957,14 @@ extern const struct dev_pm_ops i915_pm_ops;
> extern int i915_driver_load(struct pci_dev *pdev,
> const struct pci_device_id *ent);
> extern void i915_driver_unload(struct drm_device *dev);
> -extern int intel_gpu_reset(struct drm_i915_private *dev_priv, u32
> engine_mask);
> -extern bool intel_has_gpu_reset(struct drm_i915_private *dev_priv);
> +
> +bool intel_has_gpu_reset(struct drm_i915_private *dev_priv);
> +
> +void intel_gpu_reset_prepare(struct drm_i915_private *dev_priv,
> + unsigned engine_mask);
> +int intel_gpu_reset(struct drm_i915_private *dev_priv, u32 engine_mask);
> +void intel_gpu_reset_finish(struct drm_i915_private *dev_priv,
> + unsigned engine_mask);
>
> #define I915_RESET_QUIET BIT(0)
> extern void i915_reset(struct drm_i915_private *i915, unsigned int flags);
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 5ae9a62712ca..7186fe4d2ba9 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1899,6 +1899,29 @@ static reset_func intel_get_gpu_reset(struct
> drm_i915_private *dev_priv)
> return NULL;
> }
>
> +static void i915_engines_set_mode(struct drm_i915_private *dev_priv,
> + unsigned engine_mask,
> + u32 mode)
> +{
> + struct intel_engine_cs *engine;
> + enum intel_engine_id id;
> +
> + if (INTEL_GEN(dev_priv) < 3)
> + return;
> +
> + for_each_engine_masked(engine, dev_priv, engine_mask, id)
> + I915_WRITE_FW(RING_MI_MODE(engine->mmio_base), mode);
Is there reason to not use gen3_stop_engine in this level?
-Mika
> +}
> +
> +void intel_gpu_reset_prepare(struct drm_i915_private *dev_priv,
> + unsigned engine_mask)
> +{
> + intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
> +
> + i915_engines_set_mode(dev_priv, engine_mask,
> + _MASKED_BIT_ENABLE(STOP_RING));
> +}
> +
> int intel_gpu_reset(struct drm_i915_private *dev_priv, unsigned engine_mask)
> {
> reset_func reset = intel_get_gpu_reset(dev_priv);
> @@ -1939,6 +1962,16 @@ int intel_gpu_reset(struct drm_i915_private *dev_priv,
> unsigned engine_mask)
> return ret;
> }
>
> +void intel_gpu_reset_finish(struct drm_i915_private *dev_priv,
> + unsigned engine_mask)
> +{
> + /* Clear the STOP_RING bit as the reset may not have occurred */
> + i915_engines_set_mode(dev_priv, engine_mask,
> + _MASKED_BIT_DISABLE(STOP_RING));
> +
> + intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
> +}
> +
> bool intel_has_gpu_reset(struct drm_i915_private *dev_priv)
> {
> return intel_get_gpu_reset(dev_priv) != NULL;
> --
> 2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v5] tests/perf_pmu: Handle CPU hotplug failures better
From: Chris Wilson
CPU hotplug, especially CPU0, can be flaky on commodity hardware.
To improve test reliability and reponse times when testing larger runs we
need to handle those cases better.
Handle failures to off-line a CPU by immediately skipping the test, and
failures to on-line a CPU by immediately rebooting the machine.
This patch includes igt_sysrq_reboot implementation from Chris Wilson.
v2: Halt by default, reboot if env variable IGT_REBOOT_ON_FATAL_ERROR is
set. (Petri Latvala)
v3: Add missign docs and update stale comment. (Petri Latvala)
v4: Use pause instead of sleep. (Chris Wilson)
v5: Newlines! (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Petri Latvala
Cc: Tomi Sarvela
Reviewed-by: Petri Latvala
---
lib/Makefile.sources | 2 ++
lib/igt_core.c | 23 +++
lib/igt_core.h | 1 +
lib/igt_sysrq.c | 27 +++
lib/igt_sysrq.h | 30 ++
lib/meson.build | 1 +
tests/perf_pmu.c | 38 +++---
7 files changed, 115 insertions(+), 7 deletions(-)
create mode 100644 lib/igt_sysrq.c
create mode 100644 lib/igt_sysrq.h
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 5b13ef8896c0..3d37ef1d1984 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -35,6 +35,8 @@ lib_source_list = \
igt_stats.h \
igt_sysfs.c \
igt_sysfs.h \
+ igt_sysrq.c \
+ igt_sysrq.h \
igt_x86.h \
igt_x86.c \
igt_vgem.c \
diff --git a/lib/igt_core.c b/lib/igt_core.c
index c292343de09e..e52b806bdb01 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -70,6 +70,7 @@
#include "igt_core.h"
#include "igt_aux.h"
#include "igt_sysfs.h"
+#include "igt_sysrq.h"
#include "igt_rc.h"
#define UNW_LOCAL_ONLY
@@ -1136,6 +1137,28 @@ void igt_fail(int exitcode)
}
}
+/**
+ * igt_fatal_error: Stop test execution on fatal errors
+ *
+ * Stop test execution or optionally, if the IGT_REBOOT_ON_FATAL_ERROR
+ * environment variable is set, reboot the machine.
+ *
+ * Since out test runner (piglit) does support fatal test exit codes, we
+ * implement the default behaviour by waiting endlessly.
+ */
+void __attribute__((noreturn)) igt_fatal_error(void)
+{
+ if (igt_check_boolean_env_var("IGT_REBOOT_ON_FATAL_ERROR", false)) {
+ igt_warn("FATAL ERROR - REBOOTING\n");
+ igt_sysrq_reboot();
+ } else {
+ igt_warn("FATAL ERROR\n");
+ for (;;)
+ pause();
+ }
+}
+
+
/**
* igt_can_fail:
*
diff --git a/lib/igt_core.h b/lib/igt_core.h
index 7af2b4c109fe..66523a208c31 100644
--- a/lib/igt_core.h
+++ b/lib/igt_core.h
@@ -311,6 +311,7 @@ void __igt_fail_assert(const char *domain, const char *file,
const char *format, ...)
__attribute__((noreturn));
void igt_exit(void) __attribute__((noreturn));
+void igt_fatal_error(void) __attribute__((noreturn));
/**
* igt_ignore_warn:
diff --git a/lib/igt_sysrq.c b/lib/igt_sysrq.c
new file mode 100644
index ..3bda321f7c5b
--- /dev/null
+++ b/lib/igt_sysrq.c
@@ -0,0 +1,27 @@
+#include
+#include
+#include
+#include
+
+#include "igt_core.h"
+
+#include "igt_sysrq.h"
+
+/**
+ * igt_sysrq_reboot: Reboots the machine
+ *
+ * Syncs filesystems and immediately reboots the machine.
+ */
+void igt_sysrq_reboot(void)
+{
+ sync();
+
+ /* Try to be nice at first, and if that fails pull the trigger */
+ if (reboot(RB_AUTOBOOT)) {
+ int fd = open("/proc/sysrq-trigger", O_WRONLY);
+ igt_ignore_warn(write(fd, "b", 2));
+ close(fd);
+ }
+
+ abort();
+}
diff --git a/lib/igt_sysrq.h b/lib/igt_sysrq.h
new file mode 100644
index ..422473d2a480
--- /dev/null
+++ b/lib/igt_sysrq.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY C
[Intel-gfx] [PATCH xf86-video-intel v2] sna: Add XV_COLORSPACE attribute support for sprite Xv adaptors
From: Ville Syrjälä
Use the new "COLOR_ENCODING" plane property to implement the
XV_COLORSPACE port attribute for sprite Xv adaptors.
v2: assert(colorspace < ARRAY_SIZE) (Chris)
Cc: Jyri Sarha
Cc: Chris Wilson
Signed-off-by: Ville Syrjälä
---
src/sna/sna.h | 1 +
src/sna/sna_display.c | 149 +++--
src/sna/sna_video.h| 3 +
src/sna/sna_video_sprite.c | 22 ++-
4 files changed, 143 insertions(+), 32 deletions(-)
diff --git a/src/sna/sna.h b/src/sna/sna.h
index 5283ce436a3b..c9097d3db158 100644
--- a/src/sna/sna.h
+++ b/src/sna/sna.h
@@ -634,6 +634,7 @@ static inline void sna_present_cancel_flip(struct sna *sna)
{ }
extern unsigned sna_crtc_count_sprites(xf86CrtcPtr crtc);
extern bool sna_crtc_set_sprite_rotation(xf86CrtcPtr crtc, unsigned idx,
uint32_t rotation);
+extern void sna_crtc_set_sprite_colorspace(xf86CrtcPtr crtc, unsigned idx, int
colorspace);
extern uint32_t sna_crtc_to_sprite(xf86CrtcPtr crtc, unsigned idx);
extern bool sna_crtc_is_transformed(xf86CrtcPtr crtc);
diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index ea2f148d213c..091932f73971 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -222,6 +222,10 @@ struct sna_crtc {
uint32_t supported;
uint32_t current;
} rotation;
+ struct {
+ uint32_t prop;
+ uint64_t values[2];
+ } color_encoding;
struct list link;
} primary;
struct list sprites;
@@ -3293,17 +3297,125 @@ static const xf86CrtcFuncsRec sna_crtc_funcs = {
#endif
};
-inline static bool prop_is_rotation(struct drm_mode_get_property *prop)
+inline static bool prop_has_type_and_name(const struct drm_mode_get_property
*prop,
+ unsigned int type, const char *name)
{
- if ((prop->flags & (1 << 5)) == 0)
+ if ((prop->flags & (1 << type)) == 0)
return false;
- if (strcmp(prop->name, "rotation"))
+ if (strcmp(prop->name, name))
return false;
return true;
}
+inline static bool prop_is_rotation(const struct drm_mode_get_property *prop)
+{
+ return prop_has_type_and_name(prop, 5, "rotation");
+}
+
+static void parse_rotation_prop(struct sna *sna, struct plane *p,
+ struct drm_mode_get_property *prop,
+ uint64_t value)
+{
+ struct drm_mode_property_enum *enums;
+ int j;
+
+ p->rotation.prop = prop->prop_id;
+ p->rotation.current = value;
+
+ DBG(("%s: found rotation property .id=%d, value=%ld, num_enums=%d\n",
+__FUNCTION__, prop->prop_id, value, prop->count_enum_blobs));
+
+ enums = malloc(prop->count_enum_blobs * sizeof(struct
drm_mode_property_enum));
+ if (!enums)
+ return;
+
+ prop->count_values = 0;
+ prop->enum_blob_ptr = (uintptr_t)enums;
+
+ if (drmIoctl(sna->kgem.fd, DRM_IOCTL_MODE_GETPROPERTY, prop)) {
+ free(enums);
+ return;
+ }
+
+ /* XXX we assume that the mapping between kernel enum and
+* RandR remains fixed for our lifetimes.
+*/
+ VG(VALGRIND_MAKE_MEM_DEFINED(enums,
sizeof(*enums)*prop->count_enum_blobs));
+ for (j = 0; j < prop->count_enum_blobs; j++) {
+ DBG(("%s: rotation[%d] = %s [%lx]\n", __FUNCTION__,
+j, enums[j].name, (long)enums[j].value));
+ p->rotation.supported |= 1 << enums[j].value;
+ }
+
+ free(enums);
+}
+
+inline static bool prop_is_color_encoding(const struct drm_mode_get_property
*prop)
+{
+ return prop_has_type_and_name(prop, 3, "COLOR_ENCODING");
+}
+
+static void parse_color_encoding_prop(struct sna *sna, struct plane *p,
+ struct drm_mode_get_property *prop,
+ uint64_t value)
+{
+ struct drm_mode_property_enum *enums;
+ unsigned int supported = 0;
+ int j;
+
+ DBG(("%s: found color encoding property .id=%d, value=%ld,
num_enums=%d\n",
+__FUNCTION__, prop->prop_id, (long)value, prop->count_enum_blobs));
+
+ enums = malloc(prop->count_enum_blobs * sizeof(struct
drm_mode_property_enum));
+ if (!enums)
+ return;
+
+ prop->count_values = 0;
+ prop->enum_blob_ptr = (uintptr_t)enums;
+
+ if (drmIoctl(sna->kgem.fd, DRM_IOCTL_MODE_GETPROPERTY, prop)) {
+ free(enums);
+ return;
+ }
+
+ VG(VALGRIND_MAKE_MEM_DEFINED(enums,
sizeof(*enums)*prop->count_enum_blobs));
+ for (j = 0; j < prop->count_enum_blobs; j++) {
+ if (!strcmp(enums[j].name, "ITU-R BT.601 YCbCr")) {
+ p->color_encoding.values[0] = enums[j].value;
+ supported |= 1 << 0;
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Stop engines around GPU reset preparations
Quoting Mika Kuoppala (2018-03-02 11:50:32)
> Chris Wilson writes:
> > +static void i915_engines_set_mode(struct drm_i915_private *dev_priv,
> > + unsigned engine_mask,
> > + u32 mode)
> > +{
> > + struct intel_engine_cs *engine;
> > + enum intel_engine_id id;
> > +
> > + if (INTEL_GEN(dev_priv) < 3)
> > + return;
> > +
> > + for_each_engine_masked(engine, dev_priv, engine_mask, id)
> > + I915_WRITE_FW(RING_MI_MODE(engine->mmio_base), mode);
>
> Is there reason to not use gen3_stop_engine in this level?
It clears HEAD/TAIL, so undoing it in the case of no reset is a bit more
tricky.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH xf86-video-intel v2] sna: Add XV_COLORSPACE attribute support for sprite Xv adaptors
Quoting Ville Syrjala (2018-03-02 11:59:18) > From: Ville Syrjälä > > Use the new "COLOR_ENCODING" plane property to implement the > XV_COLORSPACE port attribute for sprite Xv adaptors. > > v2: assert(colorspace < ARRAY_SIZE) (Chris) > > Cc: Jyri Sarha > Cc: Chris Wilson > Signed-off-by: Ville Syrjälä Is this (i.e. the kernel implementation is done) ready to land? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Wedged engine mask makes more sense in hex
On 28/02/2018 17:54, Patchwork wrote: == Series Details == Series: drm/i915: Wedged engine mask makes more sense in hex URL : https://patchwork.freedesktop.org/series/39147/ State : success == Summary == Series 39147v1 drm/i915: Wedged engine mask makes more sense in hex https://patchwork.freedesktop.org/api/1.0/series/39147/revisions/1/mbox/ Known issues: Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-skl-guc) fdo#103191 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:415s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:376s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:492s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:285s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:479s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:489s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:469s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:464s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:396s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:559s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:590s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:416s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:286s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:505s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:388s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:410s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:457s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:411s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:457s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:489s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:453s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:492s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:591s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:430s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:501s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:518s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:492s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:475s fi-skl-guc total:245 pass:220 dwarn:0 dfail:0 fail:0 skip:24 fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:431s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:529s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:393s 573e919160e546baa4268a213400f9f42f72ae97 drm-tip: 2018y-02m-28d-16h-17m-37s UTC integration manifest a1a2ccdff789 drm/i915: Wedged engine mask makes more sense in hex Pushed, thanks for the reviews! 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/2] drm/i915: Stop engines around GPU reset preparations
== Series Details == Series: series starting with [1/2] drm/i915: Stop engines around GPU reset preparations URL : https://patchwork.freedesktop.org/series/39270/ State : success == Summary == Series 39270v1 series starting with [1/2] drm/i915: Stop engines around GPU reset preparations https://patchwork.freedesktop.org/api/1.0/series/39270/revisions/1/mbox/ Known issues: Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: incomplete -> PASS (fi-snb-2520m) fdo#103713 Test prime_vgem: Subgroup basic-fence-flip: fail -> PASS (fi-byt-n2820) fdo#104008 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:411s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:423s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:371s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:479s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:278s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:476s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:481s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:463s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:455s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:393s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:564s fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:494s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:413s fi-gdg-551 total:288 pass:180 dwarn:0 dfail:0 fail:0 skip:108 time:288s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:507s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:391s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:407s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:445s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:410s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:449s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:491s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:450s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:491s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:586s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:424s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:500s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:518s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:488s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:467s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:403s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:429s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:512s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:388s fi-cnl-y3 failed to collect. IGT log at Patchwork_8210/fi-cnl-y3/run0.log b2e10fd5e8b2cd72b0e1eba46c1221dc3d4b70bc drm-tip: 2018y-03m-02d-09h-36m-59s UTC integration manifest f2dac0f529e2 drm/i915: Suspend submission tasklets around wedging 1e1a9eccd43f drm/i915: Stop engines around GPU reset preparations == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8210/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH xf86-video-intel v2] sna: Add XV_COLORSPACE attribute support for sprite Xv adaptors
On Fri, Mar 02, 2018 at 12:01:42PM +, Chris Wilson wrote: > Quoting Ville Syrjala (2018-03-02 11:59:18) > > From: Ville Syrjälä > > > > Use the new "COLOR_ENCODING" plane property to implement the > > XV_COLORSPACE port attribute for sprite Xv adaptors. > > > > v2: assert(colorspace < ARRAY_SIZE) (Chris) > > > > Cc: Jyri Sarha > > Cc: Chris Wilson > > Signed-off-by: Ville Syrjälä > > Is this (i.e. the kernel implementation is done) ready to land? No one has complained about the proposed uapi and I have sufficient r-bs, so I'm ready to push the kernel stuff as soon as there's a green light from the user space side. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH xf86-video-intel v2] sna: Add XV_COLORSPACE attribute support for sprite Xv adaptors
Quoting Ville Syrjälä (2018-03-02 12:12:26) > On Fri, Mar 02, 2018 at 12:01:42PM +, Chris Wilson wrote: > > Quoting Ville Syrjala (2018-03-02 11:59:18) > > > From: Ville Syrjälä > > > > > > Use the new "COLOR_ENCODING" plane property to implement the > > > XV_COLORSPACE port attribute for sprite Xv adaptors. > > > > > > v2: assert(colorspace < ARRAY_SIZE) (Chris) > > > > > > Cc: Jyri Sarha > > > Cc: Chris Wilson > > > Signed-off-by: Ville Syrjälä > > > > Is this (i.e. the kernel implementation is done) ready to land? > > No one has complained about the proposed uapi and I have sufficient > r-bs, so I'm ready to push the kernel stuff as soon as there's a green > light from the user space side. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Stop engines around GPU reset preparations
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-03-02 11:50:32)
>> Chris Wilson writes:
>> > +static void i915_engines_set_mode(struct drm_i915_private *dev_priv,
>> > + unsigned engine_mask,
>> > + u32 mode)
>> > +{
>> > + struct intel_engine_cs *engine;
>> > + enum intel_engine_id id;
>> > +
>> > + if (INTEL_GEN(dev_priv) < 3)
>> > + return;
>> > +
>> > + for_each_engine_masked(engine, dev_priv, engine_mask, id)
>> > + I915_WRITE_FW(RING_MI_MODE(engine->mmio_base), mode);
>>
>> Is there reason to not use gen3_stop_engine in this level?
>
> It clears HEAD/TAIL, so undoing it in the case of no reset is a bit more
> tricky.
With this we now have 3 different flavours of stopping an engine.
I would like to see early on prepare reset to call engine->stop(),
which would be unified way of bring engine to halt. And limit
any further restoration of state if we can't really manage to reset it,
leaving it as stopped and dormant as we possibly could get it.
Then only on successful reset and restoration of init state, we would
have an engine->start().
But as this does stop the engine early on it is an improvement,
Reviewed-by: Mika Kuoppala
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2] lib/igt_pm: Restore runtime pm state on test exit
On Fri, Mar 02, 2018 at 09:56:26AM +, Tvrtko Ursulin wrote:
>
> On 02/03/2018 09:29, Imre Deak wrote:
> > On Wed, Feb 28, 2018 at 03:35:06PM +, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > Some tests (the ones which call igt_setup_runtime_pm and
> > > igt_pm_enable_audio_runtime_pm) change default system configuration and
> > > never restore it.
> > >
> > > The configured runtime suspend is aggressive and may influence behaviour
> > > of subsequent tests, so it is better to restore to previous values on test
> > > exit.
> > >
> > > This way system behaviour, with regards to a random sequence of executed
> > > tests, will be more consistent from one run to another.
> > >
> > > v2: Read failure means no runtime pm support so don't assert on it.
> > >
> > > Signed-off-by: Tvrtko Ursulin
> > > Cc: Imre Deak
> > > Reviewed-by: Chris Wilson # v1
> >
> > Agreed about having a consistent expected state for each test, not sure
> > why we didn't restore these settings :/ Btw, I feel somewhat the same
> > about test results being affected by previous tests, but not sure if
> > anything should/can be done about that.
> >
> > Acked-by: Imre Deak
> >
> > Some nits below.
> >
> > > ---
> > > lib/igt_pm.c | 122
> > > ---
> > > 1 file changed, 117 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/lib/igt_pm.c b/lib/igt_pm.c
> > > index 5bf5b2e23cdc..04e2b89cca95 100644
> > > --- a/lib/igt_pm.c
> > > +++ b/lib/igt_pm.c
> > > @@ -63,6 +63,46 @@ enum {
> > > /* Remember to fix this if adding longer strings */
> > > #define MAX_POLICY_STRLEN strlen(MAX_PERFORMANCE_STR)
> > > +static char __igt_pm_audio_runtime_power_save[64];
> > > +static char __igt_pm_audio_runtime_control[64];
> > > +
> > > +static void __igt_pm_audio_runtime_exit_handler(int sig)
> > > +{
> > > + int fd;
> > > +
> > > + igt_debug("Restoring audio power management to '%s' and '%s'\n",
> > > + __igt_pm_audio_runtime_power_save,
> > > + __igt_pm_audio_runtime_control);
> > > +
> > > + fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_WRONLY);
> > > + if (fd < 0)
> > > + return;
> > > + if (write(fd, __igt_pm_audio_runtime_power_save,
> > > + strlen(__igt_pm_audio_runtime_power_save)) !=
> > > + strlen(__igt_pm_audio_runtime_power_save))
> > > + igt_warn("Failed to restore audio power_save to '%s'\n",
> > > + __igt_pm_audio_runtime_power_save);
> > > + close(fd);
> > > +
> > > + fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_WRONLY);
> > > + if (fd < 0)
> > > + return;
> > > + if (write(fd, __igt_pm_audio_runtime_control,
> > > + strlen(__igt_pm_audio_runtime_control)) !=
> > > + strlen(__igt_pm_audio_runtime_control))
> > > + igt_warn("Failed to restore audio control to '%s'\n",
> > > + __igt_pm_audio_runtime_control);
> > > + close(fd);
> > > +}
> > > +
> > > +static void strchomp(char *str)
> > > +{
> > > + int len = strlen(str);
> > > +
> > > + if (len && str[len - 1] == '\n')
> > > + str[len - 1] = 0;
> > > +}
> > > +
> > > /**
> > >* igt_pm_enable_audio_runtime_pm:
> > >*
> > > @@ -78,16 +118,32 @@ void igt_pm_enable_audio_runtime_pm(void)
> > > {
> > > int fd;
> > > - fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_WRONLY);
> > > + /* Check if already enabled. */
> > > + if (__igt_pm_audio_runtime_power_save[0])
> > > + return;
> > > +
> > > + fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_RDWR);
> > > if (fd >= 0) {
> > > + igt_assert(read(fd, __igt_pm_audio_runtime_power_save,
> > > + sizeof(__igt_pm_audio_runtime_power_save)) > 0);
> > > + strchomp(__igt_pm_audio_runtime_power_save);
> > > igt_assert_eq(write(fd, "1\n", 2), 2);
> > > + igt_install_exit_handler(__igt_pm_audio_runtime_exit_handler);
> >
> > Read/install_handler/write would avoid a potential race with ^C. There's
> > also
>
> Well spotted, done in v3.
Ok, for that one:
Reviewed-by: Imre Deak
>
> > link_power_management_policy which is only restored during normal exit.
>
> This one already has code to restore
> (igt_pm_restore_sata_link_power_management) so maybe best to decide where to
> put the responsibility of installing the exit handler in a follow up patch?
> Make igt_pm_enable_sata_link_power_management do it, or have the caller do
> it? Former would be inline with this patch, and then probably we can
> unexport igt_pm_restore_sata_link_power_management. Or does it already
> handle this for normal exit since it is calling it from igt_fixture?
Yes, it's handled for normal exit via igt_fixture, but I think it should
be restored the same way as you did here. But yea, it's fine to do that
as a follow-up.
>
> Regards,
>
> Tvrtko
>
> >
> > > close(fd);
> > >
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Stop engines around GPU reset preparations
Quoting Mika Kuoppala (2018-03-02 12:17:19)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2018-03-02 11:50:32)
> >> Chris Wilson writes:
> >> > +static void i915_engines_set_mode(struct drm_i915_private *dev_priv,
> >> > + unsigned engine_mask,
> >> > + u32 mode)
> >> > +{
> >> > + struct intel_engine_cs *engine;
> >> > + enum intel_engine_id id;
> >> > +
> >> > + if (INTEL_GEN(dev_priv) < 3)
> >> > + return;
> >> > +
> >> > + for_each_engine_masked(engine, dev_priv, engine_mask, id)
> >> > + I915_WRITE_FW(RING_MI_MODE(engine->mmio_base), mode);
> >>
> >> Is there reason to not use gen3_stop_engine in this level?
> >
> > It clears HEAD/TAIL, so undoing it in the case of no reset is a bit more
> > tricky.
>
> With this we now have 3 different flavours of stopping an engine.
>
> I would like to see early on prepare reset to call engine->stop(),
> which would be unified way of bring engine to halt. And limit
> any further restoration of state if we can't really manage to reset it,
> leaving it as stopped and dormant as we possibly could get it.
>
> Then only on successful reset and restoration of init state, we would
> have an engine->start().
Wire it up, and see how it looks. We do
engine->stop # reset(early) or suspend
engine->reset # reset or suspend
engine->cancel # reset or wedge
engine->init # reset or resume
engine->start # reset(late) or resume
I agree adopting that scheme should help, if we can nail the code into
individual steps without repetition. (If we find we repeat ourselves,
the above scheme doesn't fit :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/8] drm: Add BT.2020 constant luminance enum value for the COLOR_ENCODING property
On Wed, Feb 14, 2018 at 09:23:21PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> BT.2020 specifies two YCbCr<->RGB conversion formulas. The more
> traditional non-constant luminance and a more complicate one constant
> luminance one. Add an enum value for the constant luminance variant
> as well in case someone has hardware supporting it.
>
> Cc: Harry Wentland
> Cc: Daniel Vetter
> Cc: Daniel Stone
> Cc: Russell King - ARM Linux
> Cc: Ilia Mirkin
> Cc: Hans Verkuil
> CC: Uma Shankar
> Cc: Shashank Sharma
> Cc: Jyri Sarha
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_color_mgmt.c | 1 +
> include/drm/drm_color_mgmt.h | 3 ++-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> b/drivers/gpu/drm/drm_color_mgmt.c
> index a84fc861e406..061d342f9d96 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -357,6 +357,7 @@ static const char * const color_encoding_name[] = {
> [DRM_COLOR_YCBCR_BT601] = "ITU-R BT.601 YCbCr",
> [DRM_COLOR_YCBCR_BT709] = "ITU-R BT.709 YCbCr",
> [DRM_COLOR_YCBCR_BT2020] = "ITU-R BT.2020 YCbCr",
> + [DRM_COLOR_YCBCR_BT2020_CONST] = "ITU-R BT.2020 YCbCr constant
> luminance",
I just realized that this exceeds the max prop enum name length
of 31 characters. I guess we'll just have to truncate it to something
like "ITU-R BT.2020 YCbCr const". Any better suggestions?
/me goes add some WARN_ON()s for invalid prop/enum names...
> };
>
> static const char * const color_range_name[] = {
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index b3b6d302ca8c..175943c87d5b 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -41,7 +41,8 @@ int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
> enum drm_color_encoding {
> DRM_COLOR_YCBCR_BT601,
> DRM_COLOR_YCBCR_BT709,
> - DRM_COLOR_YCBCR_BT2020,
> + DRM_COLOR_YCBCR_BT2020, /* non-constant luminance */
> + DRM_COLOR_YCBCR_BT2020_CONST, /* constant luminance */
> DRM_COLOR_ENCODING_MAX,
> };
>
> --
> 2.13.6
--
Ville Syrjälä
Intel OTC
___
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 [v2,1/2] drm/i915/uc: Introduce intel_uc_suspend|resume
== Series Details == Series: series starting with [v2,1/2] drm/i915/uc: Introduce intel_uc_suspend|resume URL : https://patchwork.freedesktop.org/series/39272/ State : success == Summary == Series 39272v1 series starting with [v2,1/2] drm/i915/uc: Introduce intel_uc_suspend|resume https://patchwork.freedesktop.org/api/1.0/series/39272/revisions/1/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: pass -> INCOMPLETE (fi-bxt-dsi) fdo#103927 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:413s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:421s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:371s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:478s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:276s fi-bxt-dsi total:246 pass:219 dwarn:0 dfail:0 fail:0 skip:26 fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:479s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:468s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:453s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:397s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:567s fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:494s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:413s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:288s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:508s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:386s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:407s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:451s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:408s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:446s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:488s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:441s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:492s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:583s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:428s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:499s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:520s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:483s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:471s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:406s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:426s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:512s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:396s fi-cnl-y3 failed to collect. IGT log at Patchwork_8211/fi-cnl-y3/run0.log 519e1b37fcc70054cc3064b811bdf68fbd4ff699 drm-tip: 2018y-03m-02d-11h-56m-58s UTC integration manifest b6ef3c59a5e0 HAX: Enable GuC for CI 7b7da3ba6479 drm/i915/uc: Introduce intel_uc_suspend|resume == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8211/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Suspend submission tasklets around wedging
Quoting Chris Wilson (2018-03-02 11:33:24)
> After starting hard at sequences like
>
> [ 28.199013] systemd-1 2..s. 26062228us :
> execlists_submission_tasklet: rcs0 cs-irq head=0 [0?], tail=1 [1?]
> [ 28.199095] systemd-1 2..s. 26062229us :
> execlists_submission_tasklet: rcs0 csb[1]: status=0x0018:0x,
> active=0x1
> [ 28.199177] systemd-1 2..s. 26062230us :
> execlists_submission_tasklet: rcs0 out[0]: ctx=0.1, seqno=3, prio=-1024
> [ 28.199258] systemd-1 2..s. 26062231us :
> execlists_submission_tasklet: rcs0 completed ctx=0
> [ 28.199340] gem_eio-829 1..s1 26066853us :
> execlists_submission_tasklet: rcs0 in[0]: ctx=1.1, seqno=1, prio=0
> [ 28.199421] -0 2..s. 26066863us :
> execlists_submission_tasklet: rcs0 cs-irq head=1 [1?], tail=2 [2?]
> [ 28.199503] -0 2..s. 26066865us :
> execlists_submission_tasklet: rcs0 csb[2]: status=0x0001:0x,
> active=0x1
> [ 28.199585] gem_eio-829 1..s1 26067077us :
> execlists_submission_tasklet: rcs0 in[1]: ctx=3.1, seqno=2, prio=0
> [ 28.199667] gem_eio-829 1..s1 26067078us :
> execlists_submission_tasklet: rcs0 in[0]: ctx=1.2, seqno=1, prio=0
> [ 28.199749] -0 2..s. 26067084us :
> execlists_submission_tasklet: rcs0 cs-irq head=2 [2?], tail=3 [3?]
> [ 28.199830] -0 2..s. 26067085us :
> execlists_submission_tasklet: rcs0 csb[3]: status=0x8002:0x0001,
> active=0x1
> [ 28.199912] -0 2..s. 26067086us :
> execlists_submission_tasklet: rcs0 out[0]: ctx=1.2, seqno=1, prio=0
> [ 28.14] gem_eio-829 2..s. 28246084us :
> execlists_submission_tasklet: rcs0 cs-irq head=3 [3?], tail=4 [4?]
> [ 28.200096] gem_eio-829 2..s. 28246088us :
> execlists_submission_tasklet: rcs0 csb[4]: status=0x0014:0x0001,
> active=0x5
> [ 28.200178] gem_eio-829 2..s. 28246089us :
> execlists_submission_tasklet: rcs0 out[0]: ctx=0.0, seqno=0, prio=0
> [ 28.200260] gem_eio-829 2..s. 28246127us :
> execlists_submission_tasklet: execlists_submission_tasklet:886
> GEM_BUG_ON(buf[2 * head + 1] != port->context_id)
>
> the conclusion is that the only place where the ports are reset to zero,
> is from engine->cancel_requests called during i915_gem_set_wedged().
>
> The race is horrible as it results from calling set-wedged on active HW
> (the GPU reset failed) and as such we need to be careful as the HW state
> changes beneath us. Fortunately, it's the same scary conditions as
> affect normal reset, so we can reuse the same machinery to disable state
> tracking as we clobber it.
>
Fixes: af7a8ffad9c5 ("drm/i915: Use rcu instead of stop_machine in set_wedged")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104945
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Michel Thierry
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/8] drm: Add COLOR_ENCODING and COLOR_RANGE plane properties
On Wed, Feb 14, 2018 at 09:23:19PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Here's a refresh of Jyri's COLOR_ENCODING and COLOR_RANGE properties, > and the i915 implementation I did on top. I tossed in a few core > updates as well: plane state dump, and the BT.2020 constant luminance > variant. > > Apparently nouveau is already exposing a "iturbt_709" bool property > which allows one to choose between BT.601 and BT.709 encodings, but > given that we want at least BT.2020 in addition I don't think that > property is good enough. Trying to implement it, and somehow extend > it beyond BT.601 vs. BT.709 seems like wasted effort. Hence I think > we should just ignore it and move on. > > My userspace implementation in the form of intel ddx > XV_COLORSPACE attribute: > https://patchwork.freedesktop.org/patch/204696/ > > Cc: Harry Wentland > Cc: Daniel Vetter > Cc: Daniel Stone > Cc: Russell King - ARM Linux > Cc: Ilia Mirkin > Cc: Hans Verkuil > Cc: Uma Shankar > Cc: Shashank Sharma > > Jyri Sarha (1): > drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to > drm_plane > > Ville Syrjälä (7): > drm: Add BT.2020 constant luminance enum value for the COLOR_ENCODING > property > drm/atomic: Include color encoding/range in plane state dump > drm/i915: Correctly handle limited range YCbCr data on VLV/CHV > drm/i915: Fix plane YCbCr->RGB conversion for GLK > drm/i915: Add support for the YCbCr COLOR_ENCODING property > drm/i915: Change the COLOR_ENCODING prop default value to BT.709 > drm/i915: Add support for the YCbCr COLOR_RANGE property Userspace for i915 was deemed ready [1] so I've pushed the series (apart from the BT2020_CONST thing) to drm-misc-next. Thanks to everyone who worked on this. [1] https://lists.freedesktop.org/archives/intel-gfx/2018-March/157512.html -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Clean up the port pipe select bits
== Series Details == Series: drm/i915: Clean up the port pipe select bits URL : https://patchwork.freedesktop.org/series/39259/ State : failure == Summary == Series 39259v1 drm/i915: Clean up the port pipe select bits https://patchwork.freedesktop.org/api/1.0/series/39259/revisions/1/mbox/ Possible new issues: Test core_auth: Subgroup basic-auth: pass -> INCOMPLETE (fi-ivb-3520m) pass -> INCOMPLETE (fi-snb-2520m) Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:414s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:422s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:370s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:486s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:278s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:475s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:478s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:463s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:453s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:397s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:569s fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:491s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:408s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:291s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:505s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:388s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:406s fi-ivb-3520m total:1pass:0dwarn:0 dfail:0 fail:0 skip:0 fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:413s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:450s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:489s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:450s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:491s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:583s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:422s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:497s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:517s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:486s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:476s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:407s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:428s fi-snb-2520m total:1pass:0dwarn:0 dfail:0 fail:0 skip:0 fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:387s 519e1b37fcc70054cc3064b811bdf68fbd4ff699 drm-tip: 2018y-03m-02d-11h-56m-58s UTC integration manifest 950164172c86 drm/i915: Implement the missing bits of assert_panel_unlocked() 314966553211 drm/i915: Allow eDP on port C in theory 34744df0f6ca drm/i915: Clean up DP pipe select bits a760b515dcb8 drm/i915: Nuke intel_trans_dp_port_sel() cf688310aae9 drm/i915: Parametrize TRANS_DP_PORT_SEL 4897c0985bc7 drm/i915: Move intel_ddi_get_crtc_new_encoder() out from ddi code 1c0d7dc03383 drm/i915: Check for IVB instead of gen7 when we think about IVB CPU eDP 399bbd665a74 drm/i915: Use the same vswing->max_preemph mapping on HSW/BDW as on SKL+ d3e8f01d950c drm/i915: Use intel_ddi_dp_voltage_max() for HSW/BDW too 7ab6b990997e drm/i915: Clean up DVO pipe select bits e3d61fda6189 drm/i915: Clean up TV pipe select bits c93cce952eca drm/i915: Clean up SDVO pipe select bits 30893edbb0e6 drm/i915: Clean up LVDS pipe select bits 450b0ac22c5c drm/i915: Clean up ADPA pipe select bits == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8212/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/execlists: Move irq state manipulation inside irq disabled region
Although this state (execlists->active and engine->irq_posted) itself is
not protected by the engine->timeline spinlock, it does conveniently
ensure that irqs are disabled. We can use this to protect our
manipulation of the state and so ensure that the next IRQ to arrive sees
consistent state and (hopefully) ignores the reset engine.
Suggested-by: Mika Kuoppala
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michel Thierry
---
drivers/gpu/drm/i915/intel_lrc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c1a3636e94fc..0482e54c94f0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1618,10 +1618,10 @@ static void reset_common_ring(struct intel_engine_cs
*engine,
GEM_TRACE("%s seqno=%x\n",
engine->name, request ? request->global_seqno : 0);
- reset_irq(engine);
-
spin_lock_irqsave(&engine->timeline->lock, flags);
+ reset_irq(engine);
+
/*
* Catch up with any missed context-switch interrupts.
*
@@ -1636,11 +1636,11 @@ static void reset_common_ring(struct intel_engine_cs
*engine,
/* Push back any incomplete requests for replay after the reset. */
__unwind_incomplete_requests(engine);
- spin_unlock_irqrestore(&engine->timeline->lock, flags);
-
/* Mark all CS interrupts as complete */
execlists->active = 0;
+ spin_unlock_irqrestore(&engine->timeline->lock, flags);
+
/* If the request was innocent, we leave the request in the ELSP
* and will try to replay it on restarting. The context image may
* have been corrupted by the reset, in which case we may have
--
2.16.2
___
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: Kill the remaining CHV HBR2 leftovers
== Series Details == Series: drm/i915: Kill the remaining CHV HBR2 leftovers URL : https://patchwork.freedesktop.org/series/39260/ State : success == Summary == Possible new issues: Test kms_cursor_crc: Subgroup cursor-128x128-suspend: skip -> PASS (shard-snb) Known issues: Test kms_chv_cursor_fail: Subgroup pipe-b-128x128-right-edge: pass -> DMESG-WARN (shard-snb) fdo#105185 +4 Test kms_cursor_crc: Subgroup cursor-64x64-suspend: pass -> DMESG-WARN (shard-snb) fdo#102365 Test kms_sysfs_edid_timing: warn -> PASS (shard-apl) fdo#100047 fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185 fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 shard-apltotal:3442 pass:1810 dwarn:1 dfail:0 fail:7 skip:1623 time:12114s shard-hswtotal:3366 pass:1727 dwarn:1 dfail:0 fail:1 skip:1636 time:11477s shard-snbtotal:3463 pass:1358 dwarn:5 dfail:0 fail:1 skip:2099 time:7024s Blacklisted hosts: shard-kbltotal:3445 pass:1927 dwarn:1 dfail:0 fail:7 skip:1509 time:9675s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8208/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm: Don't create properties without names
From: Ville Syrjälä
Creating a property that doesn't have a name makes no sense to me. Don't
allow it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_property.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index bae50e6b819d..fe8627fb7ae6 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -99,10 +99,8 @@ struct drm_property *drm_property_create(struct drm_device
*dev, int flags,
property->num_values = num_values;
INIT_LIST_HEAD(&property->enum_list);
- if (name) {
- strncpy(property->name, name, DRM_PROP_NAME_LEN);
- property->name[DRM_PROP_NAME_LEN-1] = '\0';
- }
+ strncpy(property->name, name, DRM_PROP_NAME_LEN);
+ property->name[DRM_PROP_NAME_LEN-1] = '\0';
list_add_tail(&property->head, &dev->mode_config.property_list);
--
2.13.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm: Check property/enum name length
From: Ville Syrjälä
Reject requests to add properties/enums with an overly long name.
Previously we would have just silently truncated the string and exposed
it userspace.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_property.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index fe8627fb7ae6..f062adf21b9c 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -78,6 +78,9 @@ struct drm_property *drm_property_create(struct drm_device
*dev, int flags,
struct drm_property *property = NULL;
int ret;
+ if (WARN_ON(strlen(name) >= DRM_PROP_NAME_LEN))
+ return -EINVAL;
+
property = kzalloc(sizeof(struct drm_property), GFP_KERNEL);
if (!property)
return NULL;
@@ -372,6 +375,9 @@ int drm_property_add_enum(struct drm_property *property,
int index,
{
struct drm_property_enum *prop_enum;
+ if (WARN_ON(strlen(name) >= DRM_PROP_NAME_LEN))
+ return -EINVAL;
+
if (!(drm_property_type_is(property, DRM_MODE_PROP_ENUM) ||
drm_property_type_is(property, DRM_MODE_PROP_BITMASK)))
return -EINVAL;
--
2.13.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/3] drm: Add BT.2020 constant luminance enum value for the COLOR_ENCODING property
From: Ville Syrjälä
BT.2020 specifies two YCbCr<->RGB conversion formulas. The more
traditional non-constant luminance and a more complicate constant
luminance one. Add an enum value for the constant luminance variant
as well in case someone has hardware supporting it.
v2: Reduce the enum name to fit within the 31 character uapi limit
Cc: Harry Wentland
Cc: Daniel Vetter
Cc: Daniel Stone
Cc: Russell King - ARM Linux
Cc: Ilia Mirkin
Cc: Hans Verkuil
CC: Uma Shankar
Cc: Shashank Sharma
Cc: Jyri Sarha
Signed-off-by: Ville Syrjälä
Acked-by: Harry Wentland #v1
---
drivers/gpu/drm/drm_color_mgmt.c | 1 +
include/drm/drm_color_mgmt.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 4ff064623836..cc28c32399af 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -358,6 +358,7 @@ static const char * const color_encoding_name[] = {
[DRM_COLOR_YCBCR_BT601] = "ITU-R BT.601 YCbCr",
[DRM_COLOR_YCBCR_BT709] = "ITU-R BT.709 YCbCr",
[DRM_COLOR_YCBCR_BT2020] = "ITU-R BT.2020 YCbCr",
+ [DRM_COLOR_YCBCR_BT2020_CONST] = "ITU-R BT.2020 YCbCr const",
};
static const char * const color_range_name[] = {
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index b3b6d302ca8c..175943c87d5b 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -41,7 +41,8 @@ int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
enum drm_color_encoding {
DRM_COLOR_YCBCR_BT601,
DRM_COLOR_YCBCR_BT709,
- DRM_COLOR_YCBCR_BT2020,
+ DRM_COLOR_YCBCR_BT2020, /* non-constant luminance */
+ DRM_COLOR_YCBCR_BT2020_CONST, /* constant luminance */
DRM_COLOR_ENCODING_MAX,
};
--
2.13.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Stop engines around GPU reset preparations
== Series Details == Series: drm/i915: Stop engines around GPU reset preparations URL : https://patchwork.freedesktop.org/series/39261/ State : failure == Summary == Possible new issues: Test drv_selftest: Subgroup live_hangcheck: pass -> INCOMPLETE (shard-apl) Test gem_eio: Subgroup in-flight-internal: pass -> INCOMPLETE (shard-apl) Test gem_exec_capture: Subgroup capture-vebox: pass -> INCOMPLETE (shard-apl) Test kms_cursor_crc: Subgroup cursor-128x128-suspend: skip -> PASS (shard-snb) Known issues: Test gem_eio: Subgroup in-flight-external: pass -> INCOMPLETE (shard-apl) fdo#104945 +1 Test kms_chv_cursor_fail: Subgroup pipe-b-256x256-bottom-edge: dmesg-warn -> PASS (shard-snb) fdo#105185 +2 Test kms_cursor_crc: Subgroup cursor-64x64-suspend: pass -> INCOMPLETE (shard-hsw) fdo#103540 fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945 fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 shard-apltotal:3190 pass:1654 dwarn:1 dfail:0 fail:7 skip:1522 time:10062s shard-hswtotal:3422 pass:1749 dwarn:1 dfail:0 fail:1 skip:1669 time:11471s shard-snbtotal:3463 pass:1361 dwarn:2 dfail:0 fail:1 skip:2099 time:7009s Blacklisted hosts: shard-kbltotal:3190 pass:1765 dwarn:10 dfail:0 fail:6 skip:1403 time:8063s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8209/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Stop engines around GPU reset preparations
== Series Details == Series: series starting with [1/2] drm/i915: Stop engines around GPU reset preparations URL : https://patchwork.freedesktop.org/series/39270/ State : failure == Summary == Possible new issues: Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-spr-indfb-draw-pwrite: pass -> FAIL (shard-apl) Known issues: Test drv_selftest: Subgroup live_gtt: pass -> INCOMPLETE (shard-apl) fdo#103927 Test gem_eio: Subgroup in-flight-contexts: incomplete -> PASS (shard-apl) fdo#104945 Test kms_chv_cursor_fail: Subgroup pipe-b-256x256-bottom-edge: dmesg-warn -> PASS (shard-snb) fdo#105185 +2 Test kms_cursor_crc: Subgroup cursor-64x64-suspend: pass -> INCOMPLETE (shard-hsw) fdo#103540 Test kms_flip: Subgroup modeset-vs-vblank-race-interruptible: pass -> FAIL (shard-hsw) fdo#103060 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945 fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 shard-apltotal:3441 pass:1798 dwarn:1 dfail:0 fail:8 skip:1632 time:12107s shard-hswtotal:3422 pass:1748 dwarn:1 dfail:0 fail:2 skip:1669 time:11536s shard-snbtotal:3463 pass:1360 dwarn:2 dfail:0 fail:1 skip:2100 time:6926s Blacklisted hosts: shard-kbltotal:3445 pass:1926 dwarn:1 dfail:0 fail:8 skip:1509 time:9796s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8210/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] HAX: Enable GuC for CI
v2: except running with HYPERVISOR Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_uc.c| 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 430f5f9..3deae1e 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -47,7 +47,7 @@ param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, 0) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 8e25474..fb80e86 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct drm_i915_private *dev_priv) enable_guc |= ENABLE_GUC_LOAD_HUC; /* Any platform specific fine-tuning can be done here */ + if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) + enable_guc = 0; return enable_guc; } -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915/huc: Mark firmware as failed on auth failure
If we fail to authenticate HuC firmware, we should change
its load status to FAIL. While around, print HUC_STATUS
on firmware verification failure.
v2: keep the variables sorted by length (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Rodrigo Vivi
Cc: Anusha Srivatsa
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_huc.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index e37f58e..65e2afb 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -48,6 +48,7 @@ int intel_huc_auth(struct intel_huc *huc)
struct drm_i915_private *i915 = huc_to_i915(huc);
struct intel_guc *guc = &i915->guc;
struct i915_vma *vma;
+ u32 status;
int ret;
if (huc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
@@ -58,28 +59,35 @@ int intel_huc_auth(struct intel_huc *huc)
if (IS_ERR(vma)) {
ret = PTR_ERR(vma);
DRM_ERROR("HuC: Failed to pin huc fw object %d\n", ret);
- return ret;
+ goto fail;
}
ret = intel_guc_auth_huc(guc,
guc_ggtt_offset(vma) + huc->fw.rsa_offset);
if (ret) {
DRM_ERROR("HuC: GuC did not ack Auth request %d\n", ret);
- goto out;
+ goto fail_unpin;
}
/* Check authentication status, it should be done by now */
- ret = intel_wait_for_register(i915,
- HUC_STATUS2,
- HUC_FW_VERIFIED,
- HUC_FW_VERIFIED,
- 50);
+ ret = __intel_wait_for_register(i915,
+ HUC_STATUS2,
+ HUC_FW_VERIFIED,
+ HUC_FW_VERIFIED,
+ 2, 50, &status);
if (ret) {
- DRM_ERROR("HuC: Authentication failed %d\n", ret);
- goto out;
+ DRM_ERROR("HuC: Firmware not verified %#x\n", status);
+ goto fail_unpin;
}
-out:
i915_vma_unpin(vma);
+ return 0;
+
+fail_unpin:
+ i915_vma_unpin(vma);
+fail:
+ huc->fw.load_status = INTEL_UC_FIRMWARE_FAIL;
+
+ DRM_ERROR("HuC: Authentication failed %d\n", ret);
return ret;
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Suspend submission tasklets around wedging
Chris Wilson writes:
> After starting hard at sequences like
>
> [ 28.199013] systemd-1 2..s. 26062228us :
> execlists_submission_tasklet: rcs0 cs-irq head=0 [0?], tail=1 [1?]
> [ 28.199095] systemd-1 2..s. 26062229us :
> execlists_submission_tasklet: rcs0 csb[1]: status=0x0018:0x,
> active=0x1
> [ 28.199177] systemd-1 2..s. 26062230us :
> execlists_submission_tasklet: rcs0 out[0]: ctx=0.1, seqno=3, prio=-1024
> [ 28.199258] systemd-1 2..s. 26062231us :
> execlists_submission_tasklet: rcs0 completed ctx=0
> [ 28.199340] gem_eio-829 1..s1 26066853us :
> execlists_submission_tasklet: rcs0 in[0]: ctx=1.1, seqno=1, prio=0
> [ 28.199421] -0 2..s. 26066863us :
> execlists_submission_tasklet: rcs0 cs-irq head=1 [1?], tail=2 [2?]
> [ 28.199503] -0 2..s. 26066865us :
> execlists_submission_tasklet: rcs0 csb[2]: status=0x0001:0x,
> active=0x1
> [ 28.199585] gem_eio-829 1..s1 26067077us :
> execlists_submission_tasklet: rcs0 in[1]: ctx=3.1, seqno=2, prio=0
> [ 28.199667] gem_eio-829 1..s1 26067078us :
> execlists_submission_tasklet: rcs0 in[0]: ctx=1.2, seqno=1, prio=0
> [ 28.199749] -0 2..s. 26067084us :
> execlists_submission_tasklet: rcs0 cs-irq head=2 [2?], tail=3 [3?]
> [ 28.199830] -0 2..s. 26067085us :
> execlists_submission_tasklet: rcs0 csb[3]: status=0x8002:0x0001,
> active=0x1
> [ 28.199912] -0 2..s. 26067086us :
> execlists_submission_tasklet: rcs0 out[0]: ctx=1.2, seqno=1, prio=0
> [ 28.14] gem_eio-829 2..s. 28246084us :
> execlists_submission_tasklet: rcs0 cs-irq head=3 [3?], tail=4 [4?]
> [ 28.200096] gem_eio-829 2..s. 28246088us :
> execlists_submission_tasklet: rcs0 csb[4]: status=0x0014:0x0001,
> active=0x5
> [ 28.200178] gem_eio-829 2..s. 28246089us :
> execlists_submission_tasklet: rcs0 out[0]: ctx=0.0, seqno=0, prio=0
> [ 28.200260] gem_eio-829 2..s. 28246127us :
> execlists_submission_tasklet: execlists_submission_tasklet:886
> GEM_BUG_ON(buf[2 * head + 1] != port->context_id)
>
> the conclusion is that the only place where the ports are reset to zero,
> is from engine->cancel_requests called during i915_gem_set_wedged().
>
> The race is horrible as it results from calling set-wedged on active HW
> (the GPU reset failed) and as such we need to be careful as the HW state
> changes beneath us. Fortunately, it's the same scary conditions as
> affect normal reset, so we can reuse the same machinery to disable state
> tracking as we clobber it.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104945
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Michel Thierry
> ---
> drivers/gpu/drm/i915/i915_gem.c | 6 +-
> drivers/gpu/drm/i915/intel_lrc.c | 5 +
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index c29b1a1cbe96..dcdcc09240b9 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3212,8 +3212,10 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
>* rolling the global seqno forward (since this would complete requests
>* for which we haven't set the fence error to EIO yet).
>*/
> - for_each_engine(engine, i915, id)
> + for_each_engine(engine, i915, id) {
> + i915_gem_reset_prepare_engine(engine);
> engine->submit_request = nop_submit_request;
> + }
>
> /*
>* Make sure no one is running the old callback before we proceed with
> @@ -3255,6 +3257,8 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
> intel_engine_init_global_seqno(engine,
>
> intel_engine_last_submit(engine));
> spin_unlock_irqrestore(&engine->timeline->lock, flags);
> +
> + i915_gem_reset_finish_engine(engine);
> }
>
> wake_up_all(&i915->gpu_error.reset_queue);
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 14288743909f..c1a3636e94fc 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -687,6 +687,8 @@ static void execlists_cancel_requests(struct
> intel_engine_cs *engine)
> struct rb_node *rb;
> unsigned long flags;
>
> + GEM_TRACE("%s\n", engine->name);
> +
> spin_lock_irqsave(&engine->timeline->lock, flags);
>
> /* Cancel the requests on the HW and clear the ELSP tracker. */
> @@ -733,6 +735,9 @@ static void execlists_cancel_requests(struct
> intel_engine_cs *engine)
>*/
> clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
>
> + /* Mark all CS interrupts as complete */
> + execlists->active = 0;
With the followup patch to handle the other irq state manipulation inside
timeline lock, albeit it feels a little like borrowing a lock, I am conte
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Move irq state manipulation inside irq disabled region
Chris Wilson writes:
> Although this state (execlists->active and engine->irq_posted) itself is
> not protected by the engine->timeline spinlock, it does conveniently
> ensure that irqs are disabled. We can use this to protect our
> manipulation of the state and so ensure that the next IRQ to arrive sees
> consistent state and (hopefully) ignores the reset engine.
>
> Suggested-by: Mika Kuoppala
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Michel Thierry
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index c1a3636e94fc..0482e54c94f0 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1618,10 +1618,10 @@ static void reset_common_ring(struct intel_engine_cs
> *engine,
> GEM_TRACE("%s seqno=%x\n",
> engine->name, request ? request->global_seqno : 0);
>
> - reset_irq(engine);
> -
> spin_lock_irqsave(&engine->timeline->lock, flags);
>
> + reset_irq(engine);
> +
> /*
>* Catch up with any missed context-switch interrupts.
>*
> @@ -1636,11 +1636,11 @@ static void reset_common_ring(struct intel_engine_cs
> *engine,
> /* Push back any incomplete requests for replay after the reset. */
> __unwind_incomplete_requests(engine);
>
> - spin_unlock_irqrestore(&engine->timeline->lock, flags);
> -
> /* Mark all CS interrupts as complete */
> execlists->active = 0;
>
> + spin_unlock_irqrestore(&engine->timeline->lock, flags);
> +
> /* If the request was innocent, we leave the request in the ELSP
>* and will try to replay it on restarting. The context image may
>* have been corrupted by the reset, in which case we may have
> --
> 2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Move irq state manipulation inside irq disabled region
== Series Details == Series: drm/i915/execlists: Move irq state manipulation inside irq disabled region URL : https://patchwork.freedesktop.org/series/39276/ State : success == Summary == Series 39276v1 drm/i915/execlists: Move irq state manipulation inside irq disabled region https://patchwork.freedesktop.org/api/1.0/series/39276/revisions/1/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:417s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:420s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:371s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:477s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:277s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:475s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:482s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:475s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:460s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:391s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:568s fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:494s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:582s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:413s fi-gdg-551 total:288 pass:180 dwarn:0 dfail:0 fail:0 skip:108 time:289s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:506s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:387s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:407s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:453s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:410s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:448s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:489s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:450s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:495s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:587s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:423s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:498s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:519s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:487s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:480s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:406s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:429s fi-snb-2520m total:245 pass:211 dwarn:0 dfail:0 fail:0 skip:33 fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:393s 7075ab436b3bb8b97dfde3eb16b2545398938f83 drm-tip: 2018y-03m-02d-13h-04m-00s UTC integration manifest fa87757ad944 drm/i915/execlists: Move irq state manipulation inside irq disabled region == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8213/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Move irq state manipulation inside irq disabled region
Quoting Chris Wilson (2018-03-02 13:12:46)
> Although this state (execlists->active and engine->irq_posted) itself is
> not protected by the engine->timeline spinlock, it does conveniently
> ensure that irqs are disabled. We can use this to protect our
> manipulation of the state and so ensure that the next IRQ to arrive sees
> consistent state and (hopefully) ignores the reset engine.
>
> Suggested-by: Mika Kuoppala
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Michel Thierry
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index c1a3636e94fc..0482e54c94f0 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1618,10 +1618,10 @@ static void reset_common_ring(struct intel_engine_cs
> *engine,
> GEM_TRACE("%s seqno=%x\n",
> engine->name, request ? request->global_seqno : 0);
>
> - reset_irq(engine);
> -
> spin_lock_irqsave(&engine->timeline->lock, flags);
>
> + reset_irq(engine);
Alternatively, we split this up with
local_irq_save(flags);
reset_irq(engine);
spin_lock(&engine->timline->lock);
...
Worth the exercise?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm: Don't create properties without names
== Series Details == Series: series starting with [1/3] drm: Don't create properties without names URL : https://patchwork.freedesktop.org/series/39277/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm: Don't create properties without names Okay! Commit: drm: Check property/enum name length - + ^ +drivers/gpu/drm/drm_property.c:82:10: warning: return makes pointer from integer without a cast [-Wint-conversion] +drivers/gpu/drm/drm_property.c:82:24:expected struct drm_property * +drivers/gpu/drm/drm_property.c:82:24:got int +drivers/gpu/drm/drm_property.c:82:24: warning: incorrect type in return expression (different base types) +drivers/gpu/drm/drm_property.c: In function ‘drm_property_create’: + return -EINVAL; Commit: drm: Add BT.2020 constant luminance enum value for the COLOR_ENCODING property Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/3 drm: Check property/enum name length
From: Ville Syrjälä
Reject requests to add properties/enums with an overly long name.
Previously we would have just silently truncated the string and exposed
it userspace.
v2: drm_property_create() returns a pointer
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_property.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index fe8627fb7ae6..c37ac41125b5 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -78,6 +78,9 @@ struct drm_property *drm_property_create(struct drm_device
*dev, int flags,
struct drm_property *property = NULL;
int ret;
+ if (WARN_ON(strlen(name) >= DRM_PROP_NAME_LEN))
+ return NULL;
+
property = kzalloc(sizeof(struct drm_property), GFP_KERNEL);
if (!property)
return NULL;
@@ -372,6 +375,9 @@ int drm_property_add_enum(struct drm_property *property,
int index,
{
struct drm_property_enum *prop_enum;
+ if (WARN_ON(strlen(name) >= DRM_PROP_NAME_LEN))
+ return -EINVAL;
+
if (!(drm_property_type_is(property, DRM_MODE_PROP_ENUM) ||
drm_property_type_is(property, DRM_MODE_PROP_BITMASK)))
return -EINVAL;
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/1] Documentation patch for batchbuffer submission
From: Kevin Rogovin v2: More documentation: intel_ringbuffer, sequence number. Expose to i915.rst existing documentation Call out GEM_EXECBUFFER as deprecated. Place code detailed documentation in source files. Call out INTEL_EXEC_RENDER. Reorder text to make it more readable. Refer to Command Buffer Parser instead of Batchbuffer Parser. (suggested by Joonas Lahtinen) Kevin Rogovin (1): i915: additional documentation Documentation/gpu/i915.rst | 194 +++-- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 +- drivers/gpu/drm/i915/i915_vma.h| 11 +- drivers/gpu/drm/i915/intel_lrc.c | 3 +- drivers/gpu/drm/i915/intel_ringbuffer.h| 64 ++ 5 files changed, 235 insertions(+), 40 deletions(-) -- 2.16.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/1] i915: additional GEM documentation
From: Kevin Rogovin This patch provides additional overview documentation to the i915 kernel driver GEM. In addition, it presents already written documentation to i915.rst as well. Signed-off-by: Kevin Rogovin --- Documentation/gpu/i915.rst | 194 +++-- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 +- drivers/gpu/drm/i915/i915_vma.h| 11 +- drivers/gpu/drm/i915/intel_lrc.c | 3 +- drivers/gpu/drm/i915/intel_ringbuffer.h| 64 ++ 5 files changed, 235 insertions(+), 40 deletions(-) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 41dc881b00dc..cd23da2793ec 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -13,6 +13,18 @@ Core Driver Infrastructure This section covers core driver infrastructure used by both the display and the GEM parts of the driver. +Initialization +-- + +The real action of initialization for the i915 driver is handled by +:c:func:`i915_driver_load`; from this function one can see the key +data (in paritcular :c:struct:'drm_driver' for GEM) of the entry points +to to the driver from user space. + +.. kernel-doc:: drivers/gpu/drm/i915/i915_drv.c + :functions: i915_driver_load + + Runtime Power Management @@ -243,32 +255,148 @@ Display PLLs .. kernel-doc:: drivers/gpu/drm/i915/intel_dpll_mgr.h :internal: -Memory Management and Command Submission - +GEM: Memory Management and Command Submission += This sections covers all things related to the GEM implementation in the i915 driver. -Batchbuffer Parsing +Intel GPU Basics + -.. kernel-doc:: drivers/gpu/drm/i915/i915_cmd_parser.c - :doc: batch buffer command parser +An Intel GPU has multiple engines. There are several engine types. +The user-space value `I915_EXEC_DEFAULT` is an alias to the user +space value `I915_EXEC_RENDER`. + +- RCS engine is for rendering 3D and performing compute, this is named `I915_EXEC_RENDER` in user space. +- BCS is a blitting (copy) engine, this is named `I915_EXEC_BLT` in user space. +- VCS is a video encode and decode engine, this is named `I915_EXEC_BSD` in user space +- VECS is video enhancement engine, this is named `I915_EXEC_VEBOX` in user space. + +The Intel GPU family is a familiy of integrated GPU's using Unified Memory +Access. For having the GPU "do work", user space will feed the GPU batch buffers +via one of the ioctls `DRM_IOCTL_I915_GEM_EXECBUFFER2` or +`DRM_IOCTL_I915_GEM_EXECBUFFER2_WR` (the ioctl `DRM_IOCTL_I915_GEM_EXECBUFFER` +is deprecated). Most such batchbuffers will instruct the GPU to perform work +(for example rendering) and that work needs memory from which to read and memory +to which to write. All memory is encapsulated within GEM buffer objects (usually +created with the ioctl `DRM_IOCTL_I915_GEM_CREATE`). An ioctl providing a batchbuffer +for the GPU to create will also list all GEM buffer objects that the batchbuffer +reads and/or writes. For implementation details of memory management see +`GEM BO Management Implementation Details`_. + +A GPU pipeline (mostly strongly so for the RCS engine) has a great deal of state +which is to be programmed by user space via the contents of a batchbuffer. Starting +in Gen6 (SandyBridge), hardware contexts are supported. A hardware context +encapsulates GPU pipeline state and other portions of GPU state and it is much more +efficient for the GPU to load a hardware context instead of re-submitting commands +in a batchbuffer to the GPU to restore state. In addition, using hardware contexts +provides much better isolation between user space clients. The ioctl +`DRM_IOCTL_I915_GEM_CONTEXT_CREATE` is used by user space to create a hardware context +which is identified by a 32-bit integer. The non-deprecated ioctls to submit batchbuffer +work can pass that ID (in the lower bits of drm_i915_gem_execbuffer2::rsvd1) to +identify what HW context to use with the command. When the kernel submits the +batchbuffer to be executed by the GPU it will also instruct the GPU to load the HW +context prior to executing the contents of a batchbuffer. + +The GPU has its own memory management and address space. The kernel driver +maintains the memory translation table for the GPU. For older GPUs (i.e. those +before Gen8), there is a single global such translation table, a global +Graphics Translation Table (GTT). For newer generation GPUs each hardware +context has its own translation table, called Per-Process Graphics Translation +Table (PPGTT). Of important note, is that although PPGTT is named per-process it +is actually per hardware context. When user space submits a batchbuffer, the kernel +walks the list of GEM buffer objects used by the batchbuffer and guarantees +that not only is the memory of each such GEM buffer object resident
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm: Don't create properties without names
== Series Details == Series: series starting with [1/3] drm: Don't create properties without names URL : https://patchwork.freedesktop.org/series/39277/ State : success == Summary == Series 39277v1 series starting with [1/3] drm: Don't create properties without names https://patchwork.freedesktop.org/api/1.0/series/39277/revisions/1/mbox/ Known issues: Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:412s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:419s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:371s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:494s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:277s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:477s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:485s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:463s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:461s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:390s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:572s fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:492s fi-cnl-y3total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:573s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:407s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:287s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:507s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:392s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:404s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:459s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:410s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:450s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:485s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:448s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:494s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:578s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:426s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:499s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:517s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:483s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:469s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:408s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:428s fi-snb-2520m total:245 pass:211 dwarn:0 dfail:0 fail:0 skip:33 fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:390s 7075ab436b3bb8b97dfde3eb16b2545398938f83 drm-tip: 2018y-03m-02d-13h-04m-00s UTC integration manifest 6b313f784de6 drm: Add BT.2020 constant luminance enum value for the COLOR_ENCODING property c0ec45ad9801 drm: Check property/enum name length 7de598d791f9 drm: Don't create properties without names == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8214/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] *cringe* at adding a parameter to workaround issues.
On Thu, 01 Mar 2018, Marc Herbert wrote: > Hi Jani, > >> *cringe* at adding a parameter to workaround issues. > > I understand that *each* parameter has the potential to *multiply* the total > number of configurations and that the resulting combinatorial explosion is > absolutely not scalable and sustainable from a validation perspective. No > one should expect to get support here when options like this one are set to > a non-default value. > > When something breaks on the other hand, transparent _test_ knobs like this > one have proved invaluable countless times to help troubleshoot and isolate > issues. It's at least 10 times more productive to ask a non-expert in some > opposite timezone "please test again after rebooting with this parameter" > compared to "test again after applying this patch, recompiling, etc." - > assuming the latter has any chance of success at all. I'm speaking from > actual experience as we are routinely experiencing both type of situations. Yes, I do understand, and that's why it's a "cringe", not a "nak". The flip side are bug reports that we still get regardless of warnings in dmesg and kernel taint when people try out parameters that they read about in random forums, and expect support. And lack of bug reports when people silently workaround their issues using module parameters. > I hope the "unsafe" part of "i915_param_named_unsafe" provides a permanent > solution to both problems by making a clear distinction between the only one > single true supported configuration on one hand versus test datapoints > on the other hand. Same for "tainted", sysfs or else. This is what I hoped too when I added support for the "unsafe" parameters. :) Now I wish we could move this stuff to debugfs and flip debugfs options as easily as module parameters. I think this is the primary reason we have so many debugging module parameters: they are more convenient than debugfs. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915/execlists: Move irq state manipulation inside irq disabled region
Although this state (execlists->active and engine->irq_posted) itself is
not protected by the engine->timeline spinlock, it does conveniently
ensure that irqs are disabled. We can use this to protect our
manipulation of the state and so ensure that the next IRQ to arrive sees
consistent state and (hopefully) ignores the reset engine.
Suggested-by: Mika Kuoppala
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michel Thierry
Reviewed-by: Mika Kuoppala
Link:
https://patchwork.freedesktop.org/patch/msgid/20180302131246.22036-1-ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_lrc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c1a3636e94fc..0482e54c94f0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1618,10 +1618,10 @@ static void reset_common_ring(struct intel_engine_cs
*engine,
GEM_TRACE("%s seqno=%x\n",
engine->name, request ? request->global_seqno : 0);
- reset_irq(engine);
-
spin_lock_irqsave(&engine->timeline->lock, flags);
+ reset_irq(engine);
+
/*
* Catch up with any missed context-switch interrupts.
*
@@ -1636,11 +1636,11 @@ static void reset_common_ring(struct intel_engine_cs
*engine,
/* Push back any incomplete requests for replay after the reset. */
__unwind_incomplete_requests(engine);
- spin_unlock_irqrestore(&engine->timeline->lock, flags);
-
/* Mark all CS interrupts as complete */
execlists->active = 0;
+ spin_unlock_irqrestore(&engine->timeline->lock, flags);
+
/* If the request was innocent, we leave the request in the ELSP
* and will try to replay it on restarting. The context image may
* have been corrupted by the reset, in which case we may have
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915: Stop engines around GPU reset preparations
As we make preparations to reset the GPU state, we assume that the GPU
is hung and will not advance. Make this assumption more explicit by
setting the STOP_RING bit on the engines as part of our early reset
preparations.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michel Thierry
Reviewed-by: Mika Kuoppala
Link:
https://patchwork.freedesktop.org/patch/msgid/20180302113324.23189-1-ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.c | 3 +++
drivers/gpu/drm/i915/i915_drv.h | 11 +--
drivers/gpu/drm/i915/intel_uncore.c | 36 +++-
3 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index aaa861b51024..925f5722d077 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1908,6 +1908,8 @@ void i915_reset(struct drm_i915_private *i915, unsigned
int flags)
error->reset_count++;
disable_irq(i915->drm.irq);
+ intel_gpu_reset_prepare(i915, ALL_ENGINES);
+
ret = i915_gem_reset_prepare(i915);
if (ret) {
dev_err(i915->drm.dev, "GPU recovery failed\n");
@@ -1969,6 +1971,7 @@ void i915_reset(struct drm_i915_private *i915, unsigned
int flags)
finish:
i915_gem_reset_finish(i915);
+ intel_gpu_reset_finish(i915, ALL_ENGINES);
enable_irq(i915->drm.irq);
wakeup:
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 10c9e5e619ab..0cb141f768ed 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2957,8 +2957,15 @@ extern const struct dev_pm_ops i915_pm_ops;
extern int i915_driver_load(struct pci_dev *pdev,
const struct pci_device_id *ent);
extern void i915_driver_unload(struct drm_device *dev);
-extern int intel_gpu_reset(struct drm_i915_private *dev_priv, u32 engine_mask);
-extern bool intel_has_gpu_reset(struct drm_i915_private *dev_priv);
+
+bool intel_has_gpu_reset(struct drm_i915_private *dev_priv);
+
+void intel_gpu_reset_prepare(struct drm_i915_private *dev_priv,
+unsigned int engine_mask);
+int intel_gpu_reset(struct drm_i915_private *dev_priv,
+ unsigned int engine_mask);
+void intel_gpu_reset_finish(struct drm_i915_private *dev_priv,
+ unsigned int engine_mask);
#define I915_RESET_QUIET BIT(0)
extern void i915_reset(struct drm_i915_private *i915, unsigned int flags);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 5ae9a62712ca..e193af2feefb 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1899,7 +1899,31 @@ static reset_func intel_get_gpu_reset(struct
drm_i915_private *dev_priv)
return NULL;
}
-int intel_gpu_reset(struct drm_i915_private *dev_priv, unsigned engine_mask)
+static void i915_engines_set_mode(struct drm_i915_private *dev_priv,
+ unsigned int engine_mask,
+ u32 mode)
+{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ if (INTEL_GEN(dev_priv) < 3)
+ return;
+
+ for_each_engine_masked(engine, dev_priv, engine_mask, id)
+ I915_WRITE_FW(RING_MI_MODE(engine->mmio_base), mode);
+}
+
+void intel_gpu_reset_prepare(struct drm_i915_private *dev_priv,
+unsigned int engine_mask)
+{
+ intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+
+ i915_engines_set_mode(dev_priv, engine_mask,
+ _MASKED_BIT_ENABLE(STOP_RING));
+}
+
+int intel_gpu_reset(struct drm_i915_private *dev_priv,
+ unsigned int engine_mask)
{
reset_func reset = intel_get_gpu_reset(dev_priv);
int retry;
@@ -1939,6 +1963,16 @@ int intel_gpu_reset(struct drm_i915_private *dev_priv,
unsigned engine_mask)
return ret;
}
+void intel_gpu_reset_finish(struct drm_i915_private *dev_priv,
+ unsigned int engine_mask)
+{
+ /* Clear the STOP_RING bit as the reset may not have occurred */
+ i915_engines_set_mode(dev_priv, engine_mask,
+ _MASKED_BIT_DISABLE(STOP_RING));
+
+ intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+}
+
bool intel_has_gpu_reset(struct drm_i915_private *dev_priv)
{
return intel_get_gpu_reset(dev_priv) != NULL;
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: Call prepare/finish around intel_gpu_reset() during GEM sanitize
During GEM sanitization, we reset the GPU so that it's always in a default state whenever we take over or return the GPU back to the BIOS. We call the GPU reset directly, so that we don't get caught up in trying to handle GEM or KMS state that is isn't ready at that time, but now we have a couple of helpers to prepare and finish around the HW reset. Use them, so that we can extend them as required for updating HW state tracking around resets. Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Michel Thierry Cc: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_gem.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index dcdcc09240b9..7ae9c877c1c6 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -4874,6 +4874,8 @@ void i915_gem_sanitize(struct drm_i915_private *i915) mutex_unlock(&i915->drm.struct_mutex); } + intel_gpu_reset_prepare(i915, ALL_ENGINES); + /* * If we inherit context state from the BIOS or earlier occupants * of the GPU, the GPU may be in an inconsistent state when we @@ -4884,6 +4886,8 @@ void i915_gem_sanitize(struct drm_i915_private *i915) */ if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915)) WARN_ON(intel_gpu_reset(i915, ALL_ENGINES)); + + intel_gpu_reset_finish(i915, ALL_ENGINES); } int i915_gem_suspend(struct drm_i915_private *dev_priv) -- 2.16.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915/execlists: Split spinlock from its irq disabling side-effect
During reset/wedging, we have to clean up the requests on the timeline
and flush the pending interrupt state. Currently, we are abusing the irq
disabling of the timeline spinlock to protect the irq state in
conjunction to the engine's timeline requests, but this is accidental
and conflates the spinlock with the irq state. A baffling state of
affairs for the reader.
Instead, explicitly disable irqs over the critical section, and separate
modifying the irq state from the timeline's requests.
Suggested-by: Mika Kuoppala
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michel Thierry
---
drivers/gpu/drm/i915/intel_lrc.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0482e54c94f0..7d1109aceabb 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -689,11 +689,13 @@ static void execlists_cancel_requests(struct
intel_engine_cs *engine)
GEM_TRACE("%s\n", engine->name);
- spin_lock_irqsave(&engine->timeline->lock, flags);
+ local_irq_save(flags);
/* Cancel the requests on the HW and clear the ELSP tracker. */
execlists_cancel_port_requests(execlists);
+ spin_lock(&engine->timeline->lock);
+
/* Mark all executing requests as skipped. */
list_for_each_entry(rq, &engine->timeline->requests, link) {
GEM_BUG_ON(!rq->global_seqno);
@@ -727,6 +729,8 @@ static void execlists_cancel_requests(struct
intel_engine_cs *engine)
execlists->first = NULL;
GEM_BUG_ON(port_isset(execlists->port));
+ spin_unlock(&engine->timeline->lock);
+
/*
* The port is checked prior to scheduling a tasklet, but
* just in case we have suspended the tasklet to do the
@@ -738,7 +742,7 @@ static void execlists_cancel_requests(struct
intel_engine_cs *engine)
/* Mark all CS interrupts as complete */
execlists->active = 0;
- spin_unlock_irqrestore(&engine->timeline->lock, flags);
+ local_irq_restore(flags);
}
/*
@@ -1618,10 +1622,11 @@ static void reset_common_ring(struct intel_engine_cs
*engine,
GEM_TRACE("%s seqno=%x\n",
engine->name, request ? request->global_seqno : 0);
- spin_lock_irqsave(&engine->timeline->lock, flags);
+ local_irq_save(flags);
reset_irq(engine);
+
/*
* Catch up with any missed context-switch interrupts.
*
@@ -1634,14 +1639,17 @@ static void reset_common_ring(struct intel_engine_cs
*engine,
execlists_cancel_port_requests(execlists);
/* Push back any incomplete requests for replay after the reset. */
+ spin_lock(&engine->timeline->lock);
__unwind_incomplete_requests(engine);
+ spin_unlock(&engine->timeline->lock);
/* Mark all CS interrupts as complete */
execlists->active = 0;
- spin_unlock_irqrestore(&engine->timeline->lock, flags);
+ local_irq_restore(flags);
- /* If the request was innocent, we leave the request in the ELSP
+ /*
+* If the request was innocent, we leave the request in the ELSP
* and will try to replay it on restarting. The context image may
* have been corrupted by the reset, in which case we may have
* to service a new GPU hang, but more likely we can continue on
@@ -1654,7 +1662,8 @@ static void reset_common_ring(struct intel_engine_cs
*engine,
if (!request || request->fence.error != -EIO)
return;
- /* We want a simple context + ring to execute the breadcrumb update.
+ /*
+* We want a simple context + ring to execute the breadcrumb update.
* We cannot rely on the context being intact across the GPU hang,
* so clear it and rebuild just what we need for the breadcrumb.
* All pending requests for this context will be zapped, and any
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915: Suspend submission tasklets around wedging
After starting hard at sequences like
[ 28.199013] systemd-1 2..s. 26062228us :
execlists_submission_tasklet: rcs0 cs-irq head=0 [0?], tail=1 [1?]
[ 28.199095] systemd-1 2..s. 26062229us :
execlists_submission_tasklet: rcs0 csb[1]: status=0x0018:0x,
active=0x1
[ 28.199177] systemd-1 2..s. 26062230us :
execlists_submission_tasklet: rcs0 out[0]: ctx=0.1, seqno=3, prio=-1024
[ 28.199258] systemd-1 2..s. 26062231us :
execlists_submission_tasklet: rcs0 completed ctx=0
[ 28.199340] gem_eio-829 1..s1 26066853us :
execlists_submission_tasklet: rcs0 in[0]: ctx=1.1, seqno=1, prio=0
[ 28.199421] -0 2..s. 26066863us :
execlists_submission_tasklet: rcs0 cs-irq head=1 [1?], tail=2 [2?]
[ 28.199503] -0 2..s. 26066865us :
execlists_submission_tasklet: rcs0 csb[2]: status=0x0001:0x,
active=0x1
[ 28.199585] gem_eio-829 1..s1 26067077us :
execlists_submission_tasklet: rcs0 in[1]: ctx=3.1, seqno=2, prio=0
[ 28.199667] gem_eio-829 1..s1 26067078us :
execlists_submission_tasklet: rcs0 in[0]: ctx=1.2, seqno=1, prio=0
[ 28.199749] -0 2..s. 26067084us :
execlists_submission_tasklet: rcs0 cs-irq head=2 [2?], tail=3 [3?]
[ 28.199830] -0 2..s. 26067085us :
execlists_submission_tasklet: rcs0 csb[3]: status=0x8002:0x0001,
active=0x1
[ 28.199912] -0 2..s. 26067086us :
execlists_submission_tasklet: rcs0 out[0]: ctx=1.2, seqno=1, prio=0
[ 28.14] gem_eio-829 2..s. 28246084us :
execlists_submission_tasklet: rcs0 cs-irq head=3 [3?], tail=4 [4?]
[ 28.200096] gem_eio-829 2..s. 28246088us :
execlists_submission_tasklet: rcs0 csb[4]: status=0x0014:0x0001,
active=0x5
[ 28.200178] gem_eio-829 2..s. 28246089us :
execlists_submission_tasklet: rcs0 out[0]: ctx=0.0, seqno=0, prio=0
[ 28.200260] gem_eio-829 2..s. 28246127us :
execlists_submission_tasklet: execlists_submission_tasklet:886 GEM_BUG_ON(buf[2
* head + 1] != port->context_id)
the conclusion is that the only place where the ports are reset to zero,
is from engine->cancel_requests called during i915_gem_set_wedged().
The race is horrible as it results from calling set-wedged on active HW
(the GPU reset failed) and as such we need to be careful as the HW state
changes beneath us. Fortunately, it's the same scary conditions as
affect normal reset, so we can reuse the same machinery to disable state
tracking as we clobber it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104945
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michel Thierry
Fixes: af7a8ffad9c5 ("drm/i915: Use rcu instead of stop_machine in set_wedged")
Reviewed-by: Mika Kuoppala
Link:
https://patchwork.freedesktop.org/patch/msgid/20180302113324.23189-2-ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c | 6 +-
drivers/gpu/drm/i915/intel_lrc.c | 5 +
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c29b1a1cbe96..dcdcc09240b9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3212,8 +3212,10 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
* rolling the global seqno forward (since this would complete requests
* for which we haven't set the fence error to EIO yet).
*/
- for_each_engine(engine, i915, id)
+ for_each_engine(engine, i915, id) {
+ i915_gem_reset_prepare_engine(engine);
engine->submit_request = nop_submit_request;
+ }
/*
* Make sure no one is running the old callback before we proceed with
@@ -3255,6 +3257,8 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
intel_engine_init_global_seqno(engine,
intel_engine_last_submit(engine));
spin_unlock_irqrestore(&engine->timeline->lock, flags);
+
+ i915_gem_reset_finish_engine(engine);
}
wake_up_all(&i915->gpu_error.reset_queue);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 14288743909f..c1a3636e94fc 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -687,6 +687,8 @@ static void execlists_cancel_requests(struct
intel_engine_cs *engine)
struct rb_node *rb;
unsigned long flags;
+ GEM_TRACE("%s\n", engine->name);
+
spin_lock_irqsave(&engine->timeline->lock, flags);
/* Cancel the requests on the HW and clear the ELSP tracker. */
@@ -733,6 +735,9 @@ static void execlists_cancel_requests(struct
intel_engine_cs *engine)
*/
clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
+ /* Mark all CS interrupts as complete */
+ execlists->active = 0;
+
spin_unlock_irqrestore(&engine->timeline->lock, flags);
}
--
2.16.2
_
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/2] drm/i915/uc: Introduce intel_uc_suspend|resume
== Series Details == Series: series starting with [v2,1/2] drm/i915/uc: Introduce intel_uc_suspend|resume URL : https://patchwork.freedesktop.org/series/39272/ State : failure == Summary == Possible new issues: Test drv_missed_irq: pass -> SKIP (shard-apl) Test drv_selftest: Subgroup live_guc: pass -> DMESG-WARN (shard-apl) Test perf: Subgroup gen8-unprivileged-single-ctx-counters: pass -> FAIL (shard-apl) Known issues: Test gem_eio: Subgroup in-flight: pass -> INCOMPLETE (shard-apl) fdo#104945 Test kms_chv_cursor_fail: Subgroup pipe-b-128x128-right-edge: dmesg-warn -> PASS (shard-snb) fdo#105185 +2 Test kms_cursor_crc: Subgroup cursor-128x128-suspend: incomplete -> PASS (shard-hsw) fdo#103540 Test kms_flip: Subgroup basic-flip-vs-wf_vblank: fail -> PASS (shard-hsw) fdo#103928 Test kms_plane: Subgroup plane-panning-bottom-right-suspend-pipe-b-planes: fail -> SKIP (shard-snb) fdo#102365 Test kms_sysfs_edid_timing: pass -> WARN (shard-apl) fdo#100047 fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945 fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 shard-apltotal:3422 pass:1787 dwarn:2 dfail:0 fail:13 skip:1618 time:12108s shard-hswtotal:3463 pass:1770 dwarn:1 dfail:0 fail:1 skip:1690 time:12133s shard-snbtotal:3463 pass:1360 dwarn:2 dfail:0 fail:1 skip:2100 time:6939s Blacklisted hosts: shard-kbltotal:3324 pass:1814 dwarn:27 dfail:2 fail:14 skip:1463 time:8844s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8211/shards.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 series starting with [v2,1/2] drm/i915/huc: Mark firmware as failed on auth failure
== Series Details == Series: series starting with [v2,1/2] drm/i915/huc: Mark firmware as failed on auth failure URL : https://patchwork.freedesktop.org/series/39280/ State : success == Summary == Series 39280v1 series starting with [v2,1/2] drm/i915/huc: Mark firmware as failed on auth failure https://patchwork.freedesktop.org/api/1.0/series/39280/revisions/1/mbox/ fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:413s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:424s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:373s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:482s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:278s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:480s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:483s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:467s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:455s fi-cfl-8700k total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:390s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:564s fi-cfl-u total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:492s fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:413s fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:288s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:504s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:386s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:410s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:452s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:416s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:447s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:488s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:445s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:490s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:589s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:424s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:500s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:519s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:486s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:467s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:409s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:430s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:526s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:390s fi-cnl-y3 failed to collect. IGT log at Patchwork_8215/fi-cnl-y3/run0.log 7075ab436b3bb8b97dfde3eb16b2545398938f83 drm-tip: 2018y-03m-02d-13h-04m-00s UTC integration manifest 7d0df29c1a92 HAX: Enable GuC for CI ad2c01a37e79 drm/i915/huc: Mark firmware as failed on auth failure == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8215/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: Suspend submission tasklets around wedging
Chris Wilson writes:
> After starting hard at sequences like
Perhaps you meant staring, but starting is fine too.
-Mika
>
> [ 28.199013] systemd-1 2..s. 26062228us :
> execlists_submission_tasklet: rcs0 cs-irq head=0 [0?], tail=1 [1?]
> [ 28.199095] systemd-1 2..s. 26062229us :
> execlists_submission_tasklet: rcs0 csb[1]: status=0x0018:0x,
> active=0x1
> [ 28.199177] systemd-1 2..s. 26062230us :
> execlists_submission_tasklet: rcs0 out[0]: ctx=0.1, seqno=3, prio=-1024
> [ 28.199258] systemd-1 2..s. 26062231us :
> execlists_submission_tasklet: rcs0 completed ctx=0
> [ 28.199340] gem_eio-829 1..s1 26066853us :
> execlists_submission_tasklet: rcs0 in[0]: ctx=1.1, seqno=1, prio=0
> [ 28.199421] -0 2..s. 26066863us :
> execlists_submission_tasklet: rcs0 cs-irq head=1 [1?], tail=2 [2?]
> [ 28.199503] -0 2..s. 26066865us :
> execlists_submission_tasklet: rcs0 csb[2]: status=0x0001:0x,
> active=0x1
> [ 28.199585] gem_eio-829 1..s1 26067077us :
> execlists_submission_tasklet: rcs0 in[1]: ctx=3.1, seqno=2, prio=0
> [ 28.199667] gem_eio-829 1..s1 26067078us :
> execlists_submission_tasklet: rcs0 in[0]: ctx=1.2, seqno=1, prio=0
> [ 28.199749] -0 2..s. 26067084us :
> execlists_submission_tasklet: rcs0 cs-irq head=2 [2?], tail=3 [3?]
> [ 28.199830] -0 2..s. 26067085us :
> execlists_submission_tasklet: rcs0 csb[3]: status=0x8002:0x0001,
> active=0x1
> [ 28.199912] -0 2..s. 26067086us :
> execlists_submission_tasklet: rcs0 out[0]: ctx=1.2, seqno=1, prio=0
> [ 28.14] gem_eio-829 2..s. 28246084us :
> execlists_submission_tasklet: rcs0 cs-irq head=3 [3?], tail=4 [4?]
> [ 28.200096] gem_eio-829 2..s. 28246088us :
> execlists_submission_tasklet: rcs0 csb[4]: status=0x0014:0x0001,
> active=0x5
> [ 28.200178] gem_eio-829 2..s. 28246089us :
> execlists_submission_tasklet: rcs0 out[0]: ctx=0.0, seqno=0, prio=0
> [ 28.200260] gem_eio-829 2..s. 28246127us :
> execlists_submission_tasklet: execlists_submission_tasklet:886
> GEM_BUG_ON(buf[2 * head + 1] != port->context_id)
>
> the conclusion is that the only place where the ports are reset to zero,
> is from engine->cancel_requests called during i915_gem_set_wedged().
>
> The race is horrible as it results from calling set-wedged on active HW
> (the GPU reset failed) and as such we need to be careful as the HW state
> changes beneath us. Fortunately, it's the same scary conditions as
> affect normal reset, so we can reuse the same machinery to disable state
> tracking as we clobber it.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104945
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Michel Thierry
> Fixes: af7a8ffad9c5 ("drm/i915: Use rcu instead of stop_machine in
> set_wedged")
> Reviewed-by: Mika Kuoppala
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20180302113324.23189-2-ch...@chris-wilson.co.uk
> ---
> drivers/gpu/drm/i915/i915_gem.c | 6 +-
> drivers/gpu/drm/i915/intel_lrc.c | 5 +
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index c29b1a1cbe96..dcdcc09240b9 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3212,8 +3212,10 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
>* rolling the global seqno forward (since this would complete requests
>* for which we haven't set the fence error to EIO yet).
>*/
> - for_each_engine(engine, i915, id)
> + for_each_engine(engine, i915, id) {
> + i915_gem_reset_prepare_engine(engine);
> engine->submit_request = nop_submit_request;
> + }
>
> /*
>* Make sure no one is running the old callback before we proceed with
> @@ -3255,6 +3257,8 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
> intel_engine_init_global_seqno(engine,
>
> intel_engine_last_submit(engine));
> spin_unlock_irqrestore(&engine->timeline->lock, flags);
> +
> + i915_gem_reset_finish_engine(engine);
> }
>
> wake_up_all(&i915->gpu_error.reset_queue);
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 14288743909f..c1a3636e94fc 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -687,6 +687,8 @@ static void execlists_cancel_requests(struct
> intel_engine_cs *engine)
> struct rb_node *rb;
> unsigned long flags;
>
> + GEM_TRACE("%s\n", engine->name);
> +
> spin_lock_irqsave(&engine->timeline->lock, flags);
>
> /* Cancel the requests on the HW and clear the ELSP tracker. */
> @@ -733,6 +735,9 @@ static void execlists_cancel_requests(struct
> intel_engine_cs *engine)
>*/
> clea
