[Intel-gfx] [PATCH] drm/i915: Address broxton phy registers based on phy and channel number

[Ander Conselvan de Oliveira]

The port registers related to the phys in broxton map to different
channels and specific phys. Make that mapping explicit.

v2: Pass enum dpio_phy to macros instead of mmio base. (Imre)

v3: Fix typo in macros. (Imre)

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/i915_drv.h   |   2 +
 drivers/gpu/drm/i915/i915_reg.h   | 141 ++
 drivers/gpu/drm/i915/intel_dpio_phy.c |  80 +++
 drivers/gpu/drm/i915/intel_dpll_mgr.c |  84 +++-
 4 files changed, 185 insertions(+), 122 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 77f1374..c3fa29a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3735,6 +3735,8 @@ u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, 
u32 reg);
 void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
 
 /* intel_dpio_phy.c */
+void bxt_port_to_phy_channel(enum port port,
+u32 *phy, enum dpio_channel *ch);
 void bxt_ddi_phy_set_signal_level(struct drm_i915_private *dev_priv,
  enum port port, u32 margin, u32 scale,
  u32 enable, u32 deemphasis);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d3802c6..8f4612c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1187,7 +1187,19 @@ enum skl_disp_power_wells {
 #define   DPIO_UPAR_SHIFT  30
 
 /* BXT PHY registers */
-#define _BXT_PHY(phy, a, b)_MMIO_PIPE((phy), (a), (b))
+#define _BXT_PHY0_BASE 0x6C000
+#define _BXT_PHY1_BASE 0x162000
+#define BXT_PHY_BASE(phy)  _PIPE((phy), _BXT_PHY0_BASE, \
+_BXT_PHY1_BASE)
+
+#define _BXT_PHY(phy, reg) \
+   _MMIO(BXT_PHY_BASE(phy) - _BXT_PHY0_BASE + (reg))
+
+#define _BXT_PHY_CH(phy, ch, reg_ch0, reg_ch1) \
+   (BXT_PHY_BASE(phy) + _PIPE((ch), (reg_ch0) - _BXT_PHY0_BASE,\
+(reg_ch1) - _BXT_PHY0_BASE))
+#define _MMIO_BXT_PHY_CH(phy, ch, reg_ch0, reg_ch1)\
+   _MMIO(_BXT_PHY_CH(phy, ch, reg_ch0, reg_ch1))
 
 #define BXT_P_CR_GT_DISP_PWRON _MMIO(0x138090)
 #define   GT_DISPLAY_POWER_ON(phy) (1 << (phy))
@@ -1204,8 +1216,8 @@ enum skl_disp_power_wells {
 #define _PHY_CTL_FAMILY_EDP0x64C80
 #define _PHY_CTL_FAMILY_DDI0x64C90
 #define   COMMON_RESET_DIS (1 << 31)
-#define BXT_PHY_CTL_FAMILY(phy)_BXT_PHY((phy), 
_PHY_CTL_FAMILY_DDI, \
-   _PHY_CTL_FAMILY_EDP)
+#define BXT_PHY_CTL_FAMILY(phy)_MMIO_PIPE((phy), 
_PHY_CTL_FAMILY_DDI, \
+ _PHY_CTL_FAMILY_EDP)
 
 /* BXT PHY PLL registers */
 #define _PORT_PLL_A0x46074
@@ -1225,18 +1237,18 @@ enum skl_disp_power_wells {
 #define   PORT_PLL_P2_SHIFT8
 #define   PORT_PLL_P2_MASK (0x1f << PORT_PLL_P2_SHIFT)
 #define   PORT_PLL_P2(x)   ((x)  << PORT_PLL_P2_SHIFT)
-#define BXT_PORT_PLL_EBB_0(port)   _MMIO_PORT3(port, _PORT_PLL_EBB_0_A, \
-   _PORT_PLL_EBB_0_B,  \
-   _PORT_PLL_EBB_0_C)
+#define BXT_PORT_PLL_EBB_0(phy, ch)_MMIO_BXT_PHY_CH(phy, ch, \
+_PORT_PLL_EBB_0_B, \
+_PORT_PLL_EBB_0_C)
 
 #define _PORT_PLL_EBB_4_A  0x162038
 #define _PORT_PLL_EBB_4_B  0x6C038
 #define _PORT_PLL_EBB_4_C  0x6C344
 #define   PORT_PLL_10BIT_CLK_ENABLE(1 << 13)
 #define   PORT_PLL_RECALIBRATE (1 << 14)
-#define BXT_PORT_PLL_EBB_4(port)   _MMIO_PORT3(port, _PORT_PLL_EBB_4_A, \
-   _PORT_PLL_EBB_4_B,  \
-   _PORT_PLL_EBB_4_C)
+#define BXT_PORT_PLL_EBB_4(phy, ch)_MMIO_BXT_PHY_CH(phy, ch, \
+_PORT_PLL_EBB_4_B, \
+_PORT_PLL_EBB_4_C)
 
 #define _PORT_PLL_0_A  0x162100
 #define _PORT_PLL_0_B  0x6C100
@@ -1267,62 +1279,56 @@ enum skl_disp_power_wells {
 #define  PORT_PLL_DCO_AMP_DEFAULT  15
 #define  PORT_PLL_DCO_AMP_MASK 0x3c00
 #define  PORT_PLL_DCO_AMP(x)   ((x)<<10)
-#define _PORT_PLL_BASE(port)   _PORT3(port, _PORT_PLL_0_A, \
-   _PORT_PLL_0_B,  \
-   _PORT_PLL_0_C)
-#define BXT_PORT_PLL(port, idx)  

Re: [Intel-gfx] [PATCH v4 i-g-t 3/3] aubdump: add --command option to stream aubdump to another program

[Gandikota, Sirisha]

>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Lionel Landwerlin
>Sent: Thursday, October 06, 2016 8:17 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Gandikota, Sirisha 
>Subject: [Intel-gfx] [PATCH v4 i-g-t 3/3] aubdump: add --command option to
>stream aubdump to another program
>
>This comes handy if you want to look at your application output without having
>to save it into a file. For example, use this with aubinator from Mesa :
>
>$ intel_aubdump -c '/path/to/aubinator --gen=hsw' my_gl_app
>
>v2: Fix handling empty command line option
>
>v3: Fix command line concatenation (again...)
>
>v4: Use execvp (Petri)
>Indentation (Petri)
>Allow recording to a file and stream to an external application (Lionel)
>
>Signed-off-by: Lionel Landwerlin 
>Cc: Sirisha Gandikota 
>---
> tools/aubdump.c| 81
>--
> tools/intel_aubdump.in | 26 +++-
> 2 files changed, 97 insertions(+), 10 deletions(-)
>
>diff --git a/tools/aubdump.c b/tools/aubdump.c index e82b514..61aa83c 100644
>--- a/tools/aubdump.c
>+++ b/tools/aubdump.c
>@@ -43,6 +43,10 @@
> #include "intel_aub.h"
> #include "intel_chipset.h"
>
>+#ifndef ARRAY_SIZE
>+#define ARRAY_SIZE(x) (sizeof(x)/sizeof((x)[0])) #endif
>+
> static int close_init_helper(int fd);
> static int ioctl_init_helper(int fd, unsigned long request, ...);
>
>@@ -50,8 +54,8 @@ static int (*libc_close)(int fd) = close_init_helper;  
>static int
>(*libc_ioctl)(int fd, unsigned long request, ...) = ioctl_init_helper;
>
> static int drm_fd = -1;
>-static char *filename;
>-static FILE *file;
>+static char *filename = NULL;
>+static FILE *files[2] = { NULL, NULL };
> static int gen = 0;
> static int verbose = 0;
> static const uint32_t gtt_size = 0x1; @@ -140,13 +144,28 @@
>align_u64(uint64_t v, uint64_t a)  static void  dword_out(uint32_t data)  {
>-  fwrite(, 1, 4, file);
>+  for (int i = 0; i < ARRAY_SIZE (files); i++) {
>+  if (files[i] == NULL)
>+  continue;
>+
>+  fail_if(fwrite(, 1, 4, files[i]) == 0,
>+  "Writing to output failed\n");
>+  }
> }
>
> static void
> data_out(const void *data, size_t size)  {
>-  fwrite(data, 1, size, file);
>+  if (size == 0)
>+  return;
>+
>+  for (int i = 0; i < ARRAY_SIZE (files); i++) {
>+  if (files[i] == NULL)
>+  continue;
>+
>+  fail_if(fwrite(data, 1, size, files[i]) == 0,
>+  "Writing to output failed\n");
>+  }
> }
>
> static void
>@@ -393,7 +412,10 @@ dump_execbuffer2(int fd, struct
>drm_i915_gem_execbuffer2 *execbuffer2)
>   aub_dump_ringbuffer(batch_bo->offset + execbuffer2-
>>batch_start_offset,
>   offset, ring_flag);
>
>-  fflush(file);
>+  for (int i = 0; i < ARRAY_SIZE(files); i++) {
>+  if (files[i] != NULL)
>+  fflush(files[i]);
>+  }
> }
>
> static void
>@@ -426,6 +448,40 @@ close(int fd)
>   return libc_close(fd);
> }
>
>+static FILE *
>+launch_command(char *command)
>+{
>+  int i = 0, fds[2];
>+  char **args = calloc(strlen(command), sizeof(char *));
>+  char *iter = command;
>+
>+  args[i++] = iter = command;
>+
>+  while ((iter = strstr(iter, ",")) != NULL) {
>+  *iter = '\0';
>+  iter += 1;
>+  args[i++] = iter;
>+  }
>+
>+  if (pipe(fds) == -1)
>+  return NULL;
>+
>+  switch (fork()) {
>+  case 0:
>+  dup2(fds[0], 0);
>+  fail_if(execvp(args[0], args) == -1,
>+  "intel_aubdump: failed to launch child command\n");
>+  return NULL;
>+
>+  default:
>+  free(args);
>+  return fdopen(fds[1], "w");
>+
>+  case -1:
>+  return NULL;
>+  }
>+}
>+
> static void
> maybe_init(void)
> {
>@@ -447,10 +503,15 @@ maybe_init(void)
>   device_override = true;
>   } else if (!strcmp(key, "file")) {
>   filename = value;
>-  file = fopen(filename, "w+");
>-  fail_if(file == NULL,
>+  files[0] = fopen(filename, "w+");
>+  fail_if(files[0] == NULL,
>   "intel_aubdump: failed to open file '%s'\n",
>   filename);
>+  } else if (!strcmp(key,  "command")) {
>+  files[1] = launch_command(value);
>+  fail_if(files[1] == NULL,
>+  "intel_aubdump: failed to launch command
>'%s'\n",
>+  value);
>   } else {
>   fprintf(stderr, "intel_aubdump: unknown option '%s'\n",
>key);
>   }
>@@ 

Re: [Intel-gfx] [PATCH i-g-t 1/3] tools: intel_aubdump: avoid initializing multiple times

[Gandikota, Sirisha]

>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Lionel Landwerlin
>Sent: Thursday, October 06, 2016 8:17 AM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH i-g-t 1/3] tools: intel_aubdump: avoid initializing
>multiple times
>
>For some reason init() seems to be called multiple times. Let's move the
>initialization to the first ioctl().
>
>Signed-off-by: Lionel Landwerlin 
>---
> tools/aubdump.c | 44 
> 1 file changed, 28 insertions(+), 16 deletions(-)
>
>diff --git a/tools/aubdump.c b/tools/aubdump.c index 30dc742..a2ac7f1 100644
>--- a/tools/aubdump.c
>+++ b/tools/aubdump.c
>@@ -426,6 +426,32 @@ close(int fd)
>   return libc_close(fd);
> }
>
>+static void
>+maybe_init(void)
>+{
>+  static bool initialized = false;
>+  const char *args = getenv("INTEL_AUBDUMP_ARGS");
>+
>+  if (initialized)
>+  return;
>+
>+  initialized = true;
>+
>+  if (sscanf(args, "verbose=%d;file=%m[^;];device=%i",
>+ , , ) != 3)
>+  filename = strdup("intel.aub");
>+  fail_if(filename == NULL, "intel_aubdump: out of memory\n");
>+
>+  if (device)
>+  device_override = true;
>+
>+  bos = malloc(MAX_BO_COUNT * sizeof(bos[0]));
>+  fail_if(bos == NULL, "intel_aubdump: out of memory\n");
>+
>+  file = fopen(filename, "w+");
>+  fail_if(file == NULL, "intel_aubdump: failed to open file '%s'\n",
>+filename); }
>+

[SG]  Since you are adding a new method anyway, I would combine patches 1 and 2 
and send only 1 patch instead. Patch 2 is also working on the same new method 
with few additional changes. Additionally, please verify if intel_aubdump works 
with --device= option. It failed for me for 0x1602 (bdw) but works 
without device option on system (hsw in my case).

> int
> ioctl(int fd, unsigned long request, ...)  { @@ -447,6 +473,8 @@ ioctl(int fd,
>unsigned long request, ...)
>   }
>
>   if (fd == drm_fd) {
>+  maybe_init();
>+
>   switch (request) {
>   case DRM_IOCTL_I915_GETPARAM: {
>   struct drm_i915_getparam *getparam = argp; @@ -
>550,26 +578,10 @@ ioctl(int fd, unsigned long request, ...)  static void
> init(void)
> {
>-  const char *args = getenv("INTEL_AUBDUMP_ARGS");
>-
>   libc_close = dlsym(RTLD_NEXT, "close");
>   libc_ioctl = dlsym(RTLD_NEXT, "ioctl");
>   fail_if(libc_close == NULL || libc_ioctl == NULL,
>   "intel_aubdump: failed to get libc ioctl or close\n");
>-
>-  if (sscanf(args, "verbose=%d;file=%m[^;];device=%i",
>- , , ) != 3)
>-  filename = strdup("intel.aub");
>-  fail_if(filename == NULL, "intel_aubdump: out of memory\n");
>-
>-  if (device)
>-  device_override = true;
>-
>-  bos = malloc(MAX_BO_COUNT * sizeof(bos[0]));
>-  fail_if(bos == NULL, "intel_aubdump: out of memory\n");
>-
>-  file = fopen(filename, "w+");
>-  fail_if(file == NULL, "intel_aubdump: failed to open file '%s'\n",
>filename);
> }
>
> static int
>--
>2.9.3
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to handle GuC when GuC is not supported.

[Vivi, Rodrigo]

On Thu, 2016-10-06 at 09:36 -0300, Paulo Zanoni wrote:
> Em Qua, 2016-10-05 às 23:37 +, Vivi, Rodrigo escreveu:
> > Hi Daniel,
> > 
> > So, can we close https://bugs.freedesktop.org/show_bug.cgi?id=97573
> > with
> > wontfix or notabug?
> > 
> > I don't have a strong side on that actually, but Jani was against it
> > it
> > seems.
> 
> Just my opinion:
> 
> Considering that we already identified the problem and the fix is
> simple, I really think it's better to just fix it. In fact I thought
> you were going to submit V2 and I was planning to do the review.
> 
> Fixing this may help reducing future bug triaging time, because if we
> keep the problem unfixed we may get the same bug report again and again
> and again. It's easy to say "users get to keep all the pieces of the
> broken kernel", but we usually have to triage the problems regardless,
> discuss what to do, etc.

Here it is:
https://patchwork.freedesktop.org/patch/113922/

> 
> > 
> > Thanks,
> > Rodrigo.
> > 
> > On Wed, 2016-10-05 at 15:50 +0200, Daniel Vetter wrote:
> > > 
> > > On Thu, Sep 22, 2016 at 04:55:07PM +, Vivi, Rodrigo wrote:
> > > > 
> > > > On Wed, 2016-09-21 at 18:00 -0300, Paulo Zanoni wrote:
> > > > > 
> > > > > Em Qua, 2016-09-21 às 11:22 -0700, Rodrigo Vivi escreveu:
> > > > > > 
> > > > > > Avoid any kind of GuC handling if GuC is not supported
> > > > > > on a giving platform.
> > > > > > 
> > > > > > Besides being useless handling, our driver needs
> > > > > > to be smarter than the user trying to use an invalid
> > > > > > paramenter.
> > > > > 
> > > > > So the problem is when a platform doesn't support guc and the
> > > > > user
> > > > > passes i915.enable_guc_something=1, right?
> > > > 
> > > > 1 is not a problem actually since it means "use if available".
> > > > There is
> > > > not firmware and execution continues.
> > > > 
> > > > 2 is the problem because it means "use guc or fail if not
> > > > available".
> > > > But platforms that don't have guc can't fail. driver needs to be
> > > > smarter
> > > > than that.
> > > 
> > > Not sure it needs to be smarter than that really, since all these
> > > debug
> > > options auto-taint the kernel if you touch them. As in: You get to
> > > keep
> > > all the pieces.
> > > 
> > > We can still do some auto-cleanup of modoptions ofc if there's a
> > > good need
> > > for them.
> > > -Daniel
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > Cc: Jani Nikula 
> > > > > > Cc: Anusha Srivatsa 
> > > > > > Cc: Christophe Prigent 
> > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97573
> > > > > > Signed-off-by: Rodrigo Vivi 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/intel_guc_loader.c | 7 +++
> > > > > >  1 file changed, 7 insertions(+)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
> > > > > > b/drivers/gpu/drm/i915/intel_guc_loader.c
> > > > > > index 6fd39ef..da0f5ed 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> > > > > > @@ -720,6 +720,13 @@ void intel_guc_init(struct drm_device
> > > > > > *dev)
> > > > > > struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
> > > > > > const char *fw_path;
> > > > > >  
> > > > > > +   if (!HAS_GUC(dev)) {
> > > > > > +   i915.enable_guc_loading = 0;
> > > > > > +   i915.enable_guc_submission = 0;
> > > > > > +   fw_path = NULL;
> > > > > > +   return;
> > > > > > +   }
> > > > > 
> > > > > Instead of this, how about we just patch the code below with:
> > > > > 
> > > > > if (!HAS_GUC(dev_priv)) {
> > > > >   i915.enable_guc_loading = 0;
> > > > >   i915.enable_guc_submission = 0;
> > > > > } else {
> > > > >   /* A negative value means "use platform default" */
> > > > >   if (i915.enable_guc_loading < 0)
> > > > >   i915.enable_guc_loading =
> > > > > HAS_GUC_UCODE(dev_priv);
> > > > >   if (i915.enable_guc_submission < 0)
> > > > >   i915.enable_guc_submission =
> > > > > HAS_GUC_SCHED(dev_priv);
> > > > > }
> > > > 
> > > > yeap, this works as well. I just went for the simplest option
> > > > that
> > > > minimized at most any interactions for platforms where GuC simply
> > > > doesn't exist.
> > > > 
> > > > > 
> > > > > 
> > > > > Or we could even go with our current "design pattern" and
> > > > > create
> > > > > intel_sanitize_guc_options().
> > > > 
> > > > This is indeed a very good idea.
> > > > 
> > > > > 
> > > > > 
> > > > > This way we'll be able to avoid adding a second failure code
> > > > > path,
> > > > > since we already have one for platforms with guc but options
> > > > > disabled.
> > > > > 
> > > > > 
> > > > > > 
> > > > > > +
> > > > > > /* A negative value means "use platform default" */
> > > > > > if (i915.enable_guc_loading < 0)
> > > > > >  

Re: [Intel-gfx] [PATCH 1/3] Revert "Skip intel_crt_init for Dell XPS 8700"

[Ville Syrjälä]

On Wed, Oct 05, 2016 at 03:56:39PM +0200, Daniel Vetter wrote:
> On Mon, Sep 26, 2016 at 12:20:44PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > This reverts commit 10b6ee4a87811a110cb01eaca01eb04da6801baf.
> > 
> > According to [1] Dell XPS8700 VBT says 'int_crt_support 0', so thanks
> > to commit e4abb733bb72 ("drm/i915: Check VBT for CRT port presence on
> > HSW/BDW") we no longer need to blacklist it based on DMI.
> > 
> > Looking through the bug report, SFUSE_STRAP based detection was
> > apparently also tried and failed, but the VBT based one should still
> > work just fine.
> > 
> > The commit says that the symptom was a frozen machine, but based on the
> > bug report it doesn't look like the CRT detection was at least directly
> > responsible for such a drastic outcome.
> > 
> > Cc: Giacomo Comes 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=73559
> > References: 
> > http://lists.freedesktop.org/archives/intel-gfx/2014-January/038178.html [1]
> > Signed-off-by: Ville Syrjälä 
> 
> Seems all rather reasonable. On all 3 patches:
> 
> Reviewed-by: Daniel Vetter 

Thanks. Series pushed to dinq.

> 
> > ---
> >  drivers/gpu/drm/i915/intel_crt.c | 8 
> >  1 file changed, 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_crt.c 
> > b/drivers/gpu/drm/i915/intel_crt.c
> > index 88ebbdde185a..ba372c239d48 100644
> > --- a/drivers/gpu/drm/i915/intel_crt.c
> > +++ b/drivers/gpu/drm/i915/intel_crt.c
> > @@ -823,14 +823,6 @@ static const struct dmi_system_id intel_no_crt[] = {
> > DMI_MATCH(DMI_PRODUCT_NAME, "ZGB"),
> > },
> > },
> > -   {
> > -   .callback = intel_no_crt_dmi_callback,
> > -   .ident = "DELL XPS 8700",
> > -   .matches = {
> > -   DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> > -   DMI_MATCH(DMI_PRODUCT_NAME, "XPS 8700"),
> > -   },
> > -   },
> > { }
> >  };
> >  
> > -- 
> > 2.7.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Move down skl/kbl ddi iboost and n_edp_entires fixup (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Move down skl/kbl ddi iboost and 
n_edp_entires fixup (rev2)
URL   : https://patchwork.freedesktop.org/series/13171/
State : warning

== Summary ==

Series 13171v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/13171/revisions/2/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-byt-j1900)
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (fi-skl-6700hq)

fi-bdw-5557u total:248  pass:231  dwarn:0   dfail:0   fail:0   skip:17 
fi-bsw-n3050 total:248  pass:204  dwarn:0   dfail:0   fail:0   skip:44 
fi-bxt-t5700 total:248  pass:217  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-j1900 total:248  pass:214  dwarn:1   dfail:0   fail:1   skip:32 
fi-byt-n2820 total:248  pass:210  dwarn:0   dfail:0   fail:1   skip:37 
fi-hsw-4770  total:248  pass:225  dwarn:0   dfail:0   fail:0   skip:23 
fi-hsw-4770r total:248  pass:224  dwarn:0   dfail:0   fail:0   skip:24 
fi-ilk-650   total:248  pass:184  dwarn:0   dfail:0   fail:2   skip:62 
fi-ivb-3520m total:248  pass:221  dwarn:0   dfail:0   fail:0   skip:27 
fi-ivb-3770  total:248  pass:207  dwarn:0   dfail:0   fail:0   skip:41 
fi-kbl-7200u total:248  pass:222  dwarn:0   dfail:0   fail:0   skip:26 
fi-skl-6260u total:248  pass:232  dwarn:0   dfail:0   fail:0   skip:16 
fi-skl-6700hqtotal:248  pass:224  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6700k total:248  pass:222  dwarn:1   dfail:0   fail:0   skip:25 
fi-skl-6770hqtotal:248  pass:231  dwarn:1   dfail:0   fail:1   skip:15 
fi-snb-2520m total:248  pass:211  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:248  pass:209  dwarn:0   dfail:0   fail:0   skip:39 

Results at /archive/results/CI_IGT_test/Patchwork_2642/

2dff18acaa95a26b882a5f9910d7ded514f18415 drm-intel-nightly: 
2016y-10m-05d-13h-58m-08s UTC integration manifest
e5be0d6 drm/i915: KBL - Recommended buffer translation programming for 
DisplayPort
0d4fd49 drm/i915: Move down skl/kbl ddi iboost and n_edp_entires fixup

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] i915/GuC: Make GuC loads default

[Rodrigo Vivi]

I also asked that same question many times. Maybe they can be unified
later when we enable submission by default, but right now I believe
this is the way to go, so

Reviewed-by: Rodrigo Vivi 


On Thu, Oct 6, 2016 at 11:03 AM, Srivatsa, Anusha
 wrote:
>
>
>>-Original Message-
>>From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
>>Sent: Wednesday, October 5, 2016 11:57 PM
>>To: Srivatsa, Anusha 
>>Cc: intel-gfx@lists.freedesktop.org
>>Subject: Re: [Intel-gfx] [PATCH] i915/GuC: Make GuC loads default
>>
>>On Wed, Oct 05, 2016 at 04:20:04PM -0700, Anusha Srivatsa wrote:
>>> Proper functioning of HuC requires GuC to be loaded. Make GuC loads
>>> default so that HuC works seemlessly.
>>> Also, note that GuC submission is not made default and still needs to
>>> be given as a kernel parameter.
>>> Once the issues around GuC submission is resolved it is intended to
>>> make it default as well.
>>
>>Why is this even a separate parameter? -Chris
>
> It is a separate parameter because HuC requires GuC to be loaded. It is ok if 
> command submission is not happening through GuC but GuC "has to" be loaded 
> for HuC to function. Guc_submission parameter enables the command submission 
> through GUC. But, guc_loading parameter ensures not only that the GuC is 
> loaded but also that HuC can now function.
>
> Anusha
>>--
>>Chris Wilson, Intel Open Source Technology Centre
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] i915/GuC: Make GuC loads default

[Srivatsa, Anusha]

>-Original Message-
>From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
>Sent: Wednesday, October 5, 2016 11:57 PM
>To: Srivatsa, Anusha 
>Cc: intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH] i915/GuC: Make GuC loads default
>
>On Wed, Oct 05, 2016 at 04:20:04PM -0700, Anusha Srivatsa wrote:
>> Proper functioning of HuC requires GuC to be loaded. Make GuC loads
>> default so that HuC works seemlessly.
>> Also, note that GuC submission is not made default and still needs to
>> be given as a kernel parameter.
>> Once the issues around GuC submission is resolved it is intended to
>> make it default as well.
>
>Why is this even a separate parameter? -Chris

It is a separate parameter because HuC requires GuC to be loaded. It is ok if 
command submission is not happening through GuC but GuC "has to" be loaded for 
HuC to function. Guc_submission parameter enables the command submission 
through GUC. But, guc_loading parameter ensures not only that the GuC is loaded 
but also that HuC can now function.

Anusha
>--
>Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: KBL - Recommended buffer translation programming for DisplayPort

[Rodrigo Vivi]

According to spec: "KBL re-uses SKL values, except where
specific KBL values are listed."

And recently spec has changed adding different table for Display Port only.
But for all SKUs (H,S,U,Y) we have slightly different values.

v2: Fix wrong condition spotted by Jani.

Cc: Jani Nikula 
Cc: Manasi Navare 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_ddi.c | 88 +++-
 1 file changed, 78 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 35f0b7c..195aa70 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -167,8 +167,47 @@ static const struct ddi_buf_trans 
skl_y_ddi_translations_dp[] = {
{ 0x80005012, 0x00C0, 0x3 },
 };
 
+/* Kabylake H and S */
+static const struct ddi_buf_trans kbl_ddi_translations_dp[] = {
+   { 0x2016, 0x00A0, 0x0 },
+   { 0x5012, 0x009B, 0x0 },
+   { 0x7011, 0x0088, 0x0 },
+   { 0x80009010, 0x00C0, 0x1 },
+   { 0x2016, 0x009B, 0x0 },
+   { 0x5012, 0x0088, 0x0 },
+   { 0x80007011, 0x00C0, 0x1 },
+   { 0x2016, 0x009F, 0x0 },
+   { 0x80005012, 0x00C0, 0x1 },
+};
+
+/* Kabylake U */
+static const struct ddi_buf_trans kbl_u_ddi_translations_dp[] = {
+   { 0x201B, 0x00A1, 0x0 },
+   { 0x5012, 0x0088, 0x0 },
+   { 0x80007011, 0x00CD, 0x3 },
+   { 0x80009010, 0x00C0, 0x3 },
+   { 0x201B, 0x009D, 0x0 },
+   { 0x80005012, 0x00C0, 0x3 },
+   { 0x80007011, 0x00C0, 0x3 },
+   { 0x2016, 0x004F, 0x0 },
+   { 0x80005012, 0x00C0, 0x3 },
+};
+
+/* Kabylake Y */
+static const struct ddi_buf_trans kbl_y_ddi_translations_dp[] = {
+   { 0x1017, 0x00A1, 0x0 },
+   { 0x5012, 0x0088, 0x0 },
+   { 0x80007011, 0x00CD, 0x3 },
+   { 0x8000800F, 0x00C0, 0x3 },
+   { 0x1017, 0x009D, 0x0 },
+   { 0x80005012, 0x00C0, 0x3 },
+   { 0x80007011, 0x00C0, 0x3 },
+   { 0x1017, 0x004C, 0x0 },
+   { 0x80005012, 0x00C0, 0x3 },
+};
+
 /*
- * Skylake H and S
+ * Skylake/Kabylake H and S
  * eDP 1.4 low vswing translation parameters
  */
 static const struct ddi_buf_trans skl_ddi_translations_edp[] = {
@@ -185,7 +224,7 @@ static const struct ddi_buf_trans 
skl_ddi_translations_edp[] = {
 };
 
 /*
- * Skylake U
+ * Skylake/Kabylake U
  * eDP 1.4 low vswing translation parameters
  */
 static const struct ddi_buf_trans skl_u_ddi_translations_edp[] = {
@@ -202,7 +241,7 @@ static const struct ddi_buf_trans 
skl_u_ddi_translations_edp[] = {
 };
 
 /*
- * Skylake Y
+ * Skylake/Kabylake Y
  * eDP 1.4 low vswing translation parameters
  */
 static const struct ddi_buf_trans skl_y_ddi_translations_edp[] = {
@@ -218,7 +257,7 @@ static const struct ddi_buf_trans 
skl_y_ddi_translations_edp[] = {
{ 0x0018, 0x008A, 0x0 },
 };
 
-/* Skylake U, H and S */
+/* Skylake/Kabylake U, H and S */
 static const struct ddi_buf_trans skl_ddi_translations_hdmi[] = {
{ 0x0018, 0x00AC, 0x0 },
{ 0x5012, 0x009D, 0x0 },
@@ -233,7 +272,7 @@ static const struct ddi_buf_trans 
skl_ddi_translations_hdmi[] = {
{ 0x8018, 0x00C0, 0x1 },
 };
 
-/* Skylake Y */
+/* Skylake/Kabylake Y */
 static const struct ddi_buf_trans skl_y_ddi_translations_hdmi[] = {
{ 0x0018, 0x00A1, 0x0 },
{ 0x5012, 0x00DF, 0x0 },
@@ -334,10 +373,10 @@ bdw_get_buf_trans_edp(struct drm_i915_private *dev_priv, 
int *n_entries)
 static const struct ddi_buf_trans *
 skl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int *n_entries)
 {
-   if (IS_SKL_ULX(dev_priv) || IS_KBL_ULX(dev_priv)) {
+   if (IS_SKL_ULX(dev_priv)) {
*n_entries = ARRAY_SIZE(skl_y_ddi_translations_dp);
return skl_y_ddi_translations_dp;
-   } else if (IS_SKL_ULT(dev_priv) || IS_KBL_ULT(dev_priv)) {
+   } else if (IS_SKL_ULT(dev_priv)) {
*n_entries = ARRAY_SIZE(skl_u_ddi_translations_dp);
return skl_u_ddi_translations_dp;
} else {
@@ -347,6 +386,21 @@ skl_get_buf_trans_dp(struct drm_i915_private *dev_priv, 
int *n_entries)
 }
 
 static const struct ddi_buf_trans *
+kbl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int *n_entries)
+{
+   if (IS_KBL_ULX(dev_priv)) {
+   *n_entries = ARRAY_SIZE(kbl_y_ddi_translations_dp);
+   return kbl_y_ddi_translations_dp;
+   } else if (IS_KBL_ULT(dev_priv)) {
+   *n_entries = ARRAY_SIZE(kbl_u_ddi_translations_dp);
+   return kbl_u_ddi_translations_dp;
+   } else {
+   *n_entries = ARRAY_SIZE(kbl_ddi_translations_dp);
+   return kbl_ddi_translations_dp;
+   }
+}
+
+static const struct ddi_buf_trans *
 

[Intel-gfx] ✗ Fi.CI.BAT: warning for Broxton ddi phy refactoring (rev2)

[Patchwork]

== Series Details ==

Series: Broxton ddi phy refactoring (rev2)
URL   : https://patchwork.freedesktop.org/series/13320/
State : warning

== Summary ==

Series 13320v2 Broxton ddi phy refactoring
https://patchwork.freedesktop.org/api/1.0/series/13320/revisions/2/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-byt-j1900)
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (fi-skl-6700hq)

fi-bdw-5557u total:248  pass:231  dwarn:0   dfail:0   fail:0   skip:17 
fi-bsw-n3050 total:248  pass:204  dwarn:0   dfail:0   fail:0   skip:44 
fi-bxt-t5700 total:248  pass:217  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-j1900 total:248  pass:214  dwarn:1   dfail:0   fail:1   skip:32 
fi-byt-n2820 total:248  pass:211  dwarn:0   dfail:0   fail:1   skip:36 
fi-hsw-4770  total:248  pass:224  dwarn:0   dfail:0   fail:0   skip:24 
fi-hsw-4770r total:248  pass:224  dwarn:0   dfail:0   fail:0   skip:24 
fi-ilk-650   total:248  pass:184  dwarn:0   dfail:0   fail:2   skip:62 
fi-ivb-3520m total:248  pass:221  dwarn:0   dfail:0   fail:0   skip:27 
fi-ivb-3770  total:248  pass:207  dwarn:0   dfail:0   fail:0   skip:41 
fi-kbl-7200u total:248  pass:222  dwarn:0   dfail:0   fail:0   skip:26 
fi-skl-6260u total:248  pass:232  dwarn:0   dfail:0   fail:0   skip:16 
fi-skl-6700hqtotal:248  pass:223  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6700k total:248  pass:222  dwarn:1   dfail:0   fail:0   skip:25 
fi-skl-6770hqtotal:248  pass:230  dwarn:1   dfail:0   fail:1   skip:16 
fi-snb-2520m total:248  pass:211  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:248  pass:209  dwarn:0   dfail:0   fail:0   skip:39 

Results at /archive/results/CI_IGT_test/Patchwork_2641/

2dff18acaa95a26b882a5f9910d7ded514f18415 drm-intel-nightly: 
2016y-10m-05d-13h-58m-08s UTC integration manifest
52a2236 drm/i915: Address broxton phy registers based on phy and channel number
6631150 drm/i915: Add location of the Rcomp resistor to bxt_ddi_phy_info
655bd41 drm/i915: Create a struct to hold information about the broxton phys
3196d4a drm/i915: Move broxton vswing sequence to intel_dpio_phy.c
1d1fb65 drm/i915: Move DPIO phy documentation section to intel_dpio_phy.c
70949cd drm/i915: Move broxton phy code to intel_dpio_phy.c
ca0aaeb drm/i915: Pass lane count to bxt_ddi_phy_calc_lane_optmin_mask()
45aa2bc drm/i915: Explicitly map broxton DPIO power wells to phys
3b2c9f5 drm/i915: Rename struct i915_power_well field data to id

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/22] drm/i915: Shrink per-platform watermark configuration

[Ville Syrjälä]

On Thu, Oct 06, 2016 at 05:38:12PM +0100, Tvrtko Ursulin wrote:
> 
> On 05/10/2016 18:11, Ville Syrjälä wrote:
> > On Wed, Oct 05, 2016 at 01:33:30PM +0100, Tvrtko Ursulin wrote:
> >> From: Tvrtko Ursulin 
> >>
> >> Use types of more appropriate size in struct
> >> intel_watermark_params to save 512 bytes of .rodata.
> >>
> >> Signed-off-by: Tvrtko Ursulin 
> >> ---
> >>   drivers/gpu/drm/i915/intel_drv.h | 10 +-
> >>   drivers/gpu/drm/i915/intel_pm.c  |  4 ++--
> >>   2 files changed, 7 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> >> b/drivers/gpu/drm/i915/intel_drv.h
> >> index c52b1d3a7ba0..59a73f8ca7af 100644
> >> --- a/drivers/gpu/drm/i915/intel_drv.h
> >> +++ b/drivers/gpu/drm/i915/intel_drv.h
> >> @@ -799,11 +799,11 @@ struct intel_plane {
> >>   };
> >>   
> >>   struct intel_watermark_params {
> >> -  unsigned long fifo_size;
> >> -  unsigned long max_wm;
> >> -  unsigned long default_wm;
> >> -  unsigned long guard_size;
> >> -  unsigned long cacheline_size;
> >> +  u16 fifo_size;
> >> +  u16 max_wm;
> >> +  u8 default_wm;
> >> +  u8 guard_size;
> >> +  u8 cacheline_size;
> >>   };
> > This thing has been bugging me since forever. And yet I never sent out a
> > fix. We could probably shrink things furher by tossing out a bunch of
> > the data since it's not all that diverse. But this looks like a decent
> > first step.
> >
> > The other thing that bugs me about these is the defines for the actual
> > values. Makes it just that much harder to figure out what the actual
> > values are. I'm pretty sure I have a branch or two where I kill the
> > defines but naturally I can't find it right now. I'm too lazy to
> > double check the values now with this indirection in place, but your
> > choice of types does look reasonable, so
> >
> > Acked-by: Ville Syrjälä 
> 
> Thanks.
> 
> Btw we can shave one more kilobyte by similarly shrinking "struct 
> video_levels" and "struct tv_mode". u8/u16 are enough to replace most of 
> the ints there.  If you want to ack that in principle I can include a 
> patch for that in the next round.

Sure, go for it.

-- 
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: warning for drm/i915: Reset the breadcrumbs IRQ more carefully (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Reset the breadcrumbs IRQ more carefully (rev2)
URL   : https://patchwork.freedesktop.org/series/13375/
State : warning

== Summary ==

Series 13375v2 drm/i915: Reset the breadcrumbs IRQ more carefully
https://patchwork.freedesktop.org/api/1.0/series/13375/revisions/2/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-byt-j1900)
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (fi-skl-6700hq)

fi-bdw-5557u total:248  pass:231  dwarn:0   dfail:0   fail:0   skip:17 
fi-bsw-n3050 total:248  pass:204  dwarn:0   dfail:0   fail:0   skip:44 
fi-bxt-t5700 total:248  pass:217  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-j1900 total:248  pass:214  dwarn:1   dfail:0   fail:1   skip:32 
fi-byt-n2820 total:248  pass:211  dwarn:0   dfail:0   fail:1   skip:36 
fi-hsw-4770  total:248  pass:224  dwarn:0   dfail:0   fail:0   skip:24 
fi-hsw-4770r total:248  pass:224  dwarn:0   dfail:0   fail:0   skip:24 
fi-ilk-650   total:248  pass:184  dwarn:0   dfail:0   fail:2   skip:62 
fi-ivb-3520m total:248  pass:221  dwarn:0   dfail:0   fail:0   skip:27 
fi-ivb-3770  total:248  pass:208  dwarn:0   dfail:0   fail:0   skip:40 
fi-kbl-7200u total:248  pass:222  dwarn:0   dfail:0   fail:0   skip:26 
fi-skl-6260u total:248  pass:232  dwarn:0   dfail:0   fail:0   skip:16 
fi-skl-6700hqtotal:248  pass:223  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6700k total:248  pass:221  dwarn:1   dfail:0   fail:0   skip:26 
fi-skl-6770hqtotal:248  pass:231  dwarn:1   dfail:0   fail:1   skip:15 
fi-snb-2520m total:248  pass:211  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:248  pass:209  dwarn:0   dfail:0   fail:0   skip:39 

Results at /archive/results/CI_IGT_test/Patchwork_2640/

2dff18acaa95a26b882a5f9910d7ded514f18415 drm-intel-nightly: 
2016y-10m-05d-13h-58m-08s UTC integration manifest
9ac590f drm/i915: Reset the breadcrumbs IRQ more carefully

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/22] drm/i915: Shrink per-platform watermark configuration

[Tvrtko Ursulin]

On 05/10/2016 18:11, Ville Syrjälä wrote:

On Wed, Oct 05, 2016 at 01:33:30PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Use types of more appropriate size in struct
intel_watermark_params to save 512 bytes of .rodata.

Signed-off-by: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/intel_drv.h | 10 +-
  drivers/gpu/drm/i915/intel_pm.c  |  4 ++--
  2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c52b1d3a7ba0..59a73f8ca7af 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -799,11 +799,11 @@ struct intel_plane {
  };
  
  struct intel_watermark_params {

-   unsigned long fifo_size;
-   unsigned long max_wm;
-   unsigned long default_wm;
-   unsigned long guard_size;
-   unsigned long cacheline_size;
+   u16 fifo_size;
+   u16 max_wm;
+   u8 default_wm;
+   u8 guard_size;
+   u8 cacheline_size;
  };

This thing has been bugging me since forever. And yet I never sent out a
fix. We could probably shrink things furher by tossing out a bunch of
the data since it's not all that diverse. But this looks like a decent
first step.

The other thing that bugs me about these is the defines for the actual
values. Makes it just that much harder to figure out what the actual
values are. I'm pretty sure I have a branch or two where I kill the
defines but naturally I can't find it right now. I'm too lazy to
double check the values now with this indirection in place, but your
choice of types does look reasonable, so

Acked-by: Ville Syrjälä 


Thanks.

Btw we can shave one more kilobyte by similarly shrinking "struct 
video_levels" and "struct tv_mode". u8/u16 are enough to replace most of 
the ints there.  If you want to ack that in principle I can include a 
patch for that in the next round.


Regards,

Tvrtko

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 5/9] drm/i915: Move DPIO phy documentation section to intel_dpio_phy.c

[Ander Conselvan de Oliveira]

Move the DPIO phy documentation section to intel_dpio_phy.c, since that
is a more suitable place now that there is a source file dedicated for
those phys.

Signed-off-by: Ander Conselvan de Oliveira 

Reviewed-by: Imre Deak 
---
 Documentation/gpu/i915.rst|  2 +-
 drivers/gpu/drm/i915/i915_reg.h   | 91 +
 drivers/gpu/drm/i915/intel_dpio_phy.c | 91 -
 3 files changed, 93 insertions(+), 91 deletions(-)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 87aaffc..8cecae1 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -180,7 +180,7 @@ Display Refresh Rate Switching (DRRS)
 DPIO
 
 
-.. kernel-doc:: drivers/gpu/drm/i915/i915_reg.h
+.. kernel-doc:: drivers/gpu/drm/i915/intel_dpio_phy.c
:doc: DPIO
 
 CSR firmware support for DMC
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index acc767a..f6d29fb 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -831,96 +831,7 @@ enum skl_disp_power_wells {
 #define  CCK_FREQUENCY_STATUS_SHIFT8
 #define  CCK_FREQUENCY_VALUES  (0x1f << 0)
 
-/**
- * DOC: DPIO
- *
- * VLV, CHV and BXT have slightly peculiar display PHYs for driving DP/HDMI
- * ports. DPIO is the name given to such a display PHY. These PHYs
- * don't follow the standard programming model using direct MMIO
- * registers, and instead their registers must be accessed trough IOSF
- * sideband. VLV has one such PHY for driving ports B and C, and CHV
- * adds another PHY for driving port D. Each PHY responds to specific
- * IOSF-SB port.
- *
- * Each display PHY is made up of one or two channels. Each channel
- * houses a common lane part which contains the PLL and other common
- * logic. CH0 common lane also contains the IOSF-SB logic for the
- * Common Register Interface (CRI) ie. the DPIO registers. CRI clock
- * must be running when any DPIO registers are accessed.
- *
- * In addition to having their own registers, the PHYs are also
- * controlled through some dedicated signals from the display
- * controller. These include PLL reference clock enable, PLL enable,
- * and CRI clock selection, for example.
- *
- * Eeach channel also has two splines (also called data lanes), and
- * each spline is made up of one Physical Access Coding Sub-Layer
- * (PCS) block and two TX lanes. So each channel has two PCS blocks
- * and four TX lanes. The TX lanes are used as DP lanes or TMDS
- * data/clock pairs depending on the output type.
- *
- * Additionally the PHY also contains an AUX lane with AUX blocks
- * for each channel. This is used for DP AUX communication, but
- * this fact isn't really relevant for the driver since AUX is
- * controlled from the display controller side. No DPIO registers
- * need to be accessed during AUX communication,
- *
- * Generally on VLV/CHV the common lane corresponds to the pipe and
- * the spline (PCS/TX) corresponds to the port.
- *
- * For dual channel PHY (VLV/CHV):
- *
- *  pipe A == CMN/PLL/REF CH0
- *
- *  pipe B == CMN/PLL/REF CH1
- *
- *  port B == PCS/TX CH0
- *
- *  port C == PCS/TX CH1
- *
- * This is especially important when we cross the streams
- * ie. drive port B with pipe B, or port C with pipe A.
- *
- * For single channel PHY (CHV):
- *
- *  pipe C == CMN/PLL/REF CH0
- *
- *  port D == PCS/TX CH0
- *
- * On BXT the entire PHY channel corresponds to the port. That means
- * the PLL is also now associated with the port rather than the pipe,
- * and so the clock needs to be routed to the appropriate transcoder.
- * Port A PLL is directly connected to transcoder EDP and port B/C
- * PLLs can be routed to any transcoder A/B/C.
- *
- * Note: DDI0 is digital port B, DD1 is digital port C, and DDI2 is
- * digital port D (CHV) or port A (BXT). ::
- *
- *
- * Dual channel PHY (VLV/CHV/BXT)
- * -
- * |  CH0  |  CH1  |
- * |  CMN/PLL/REF  |  CMN/PLL/REF  |
- * |---|---| Display PHY
- * | PCS01 | PCS23 | PCS01 | PCS23 |
- * |---|---|---|---|
- * |TX0|TX1|TX2|TX3|TX0|TX1|TX2|TX3|
- * -
- * | DDI0  | DDI1  | DP/HDMI ports
- * -
- *
- * Single channel PHY (CHV/BXT)
- * -
- * |  CH0  |
- * |  CMN/PLL/REF  |
- * |---| Display PHY
- * | PCS01 | PCS23 |
- * |---|---|
- * |TX0|TX1|TX2|TX3|
- * -
- * | DDI2  | DP/HDMI port
- * -
- */
+/* DPIO registers */
 #define DPIO_DEVFN 0
 
 #define DPIO_CTL   _MMIO(VLV_DISPLAY_BASE + 0x2110)
diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
b/drivers/gpu/drm/i915/intel_dpio_phy.c
index 

[Intel-gfx] [PATCH v2 3/9] drm/i915: Pass lane count to bxt_ddi_phy_calc_lane_optmin_mask()

[Ander Conselvan de Oliveira]

Pass lane count to bxt_ddi_phy_calc_lane_optmin_mask() instead of having
it extract that number from a pipe_config to decouple the phy code from
intel_crtc_state.

Signed-off-by: Ander Conselvan de Oliveira 

Reviewed-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_ddi.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 35f0b7c..1dc7543 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2120,9 +2120,9 @@ bool bxt_ddi_phy_verify_state(struct drm_i915_private 
*dev_priv,
 
 static uint8_t
 bxt_ddi_phy_calc_lane_lat_optim_mask(struct intel_encoder *encoder,
-struct intel_crtc_state *pipe_config)
+uint8_t lane_count)
 {
-   switch (pipe_config->lane_count) {
+   switch (lane_count) {
case 1:
return 0;
case 2:
@@ -2130,7 +2130,7 @@ bxt_ddi_phy_calc_lane_lat_optim_mask(struct intel_encoder 
*encoder,
case 4:
return BIT(3) | BIT(2) | BIT(0);
default:
-   MISSING_CASE(pipe_config->lane_count);
+   MISSING_CASE(lane_count);
 
return 0;
}
@@ -2347,7 +2347,7 @@ static bool intel_ddi_compute_config(struct intel_encoder 
*encoder,
if (IS_BROXTON(dev_priv) && ret)
pipe_config->lane_lat_optim_mask =
bxt_ddi_phy_calc_lane_lat_optim_mask(encoder,
-pipe_config);
+
pipe_config->lane_count);
 
return ret;
 
-- 
git-series 0.8.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 8/9] drm/i915: Add location of the Rcomp resistor to bxt_ddi_phy_info

[Ander Conselvan de Oliveira]

Use struct bxt_ddi_phy_info to hold information of where the Rcomp
resistor is located, instead of hard coding it in the init sequence.

Note that this moves the enabling of the phy with the Rcomp resistor out
of the power well enable code. That should be safe since
bxt_ddi_phy_init() is called while the power domains lock is held, and
that is the only way that function gets called, so there is no
possibility of a concurrent phy enable caused by a power domain get
call.

v2: Replace comment about lock with lockdep_assert_held()  (Imre)

Signed-off-by: Ander Conselvan de Oliveira 

Reviewed-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_dpio_phy.c   | 72 +++---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 15 +-
 2 files changed, 55 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
b/drivers/gpu/drm/i915/intel_dpio_phy.c
index 1b1fba1..6711e3a 100644
--- a/drivers/gpu/drm/i915/intel_dpio_phy.c
+++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
@@ -124,6 +124,13 @@ struct bxt_ddi_phy_info {
bool dual_channel;
 
/**
+* @rcomp_phy: If -1, indicates this phy has its own rcomp resistor.
+* Otherwise the GRC value will be copied from the phy indicated by
+* this field.
+*/
+   enum dpio_phy rcomp_phy;
+
+   /**
 * @channel: struct containing per channel information.
 */
struct {
@@ -137,6 +144,7 @@ struct bxt_ddi_phy_info {
 static const struct bxt_ddi_phy_info bxt_ddi_phy_info[] = {
[DPIO_PHY0] = {
.dual_channel = true,
+   .rcomp_phy = DPIO_PHY1,
 
.channel = {
[DPIO_CH0] = { .port = PORT_B },
@@ -145,6 +153,7 @@ static const struct bxt_ddi_phy_info bxt_ddi_phy_info[] = {
},
[DPIO_PHY1] = {
.dual_channel = false,
+   .rcomp_phy = -1,
 
.channel = {
[DPIO_CH0] = { .port = PORT_A },
@@ -214,9 +223,10 @@ bool bxt_ddi_phy_is_enabled(struct drm_i915_private 
*dev_priv,
return false;
}
 
-   if (phy == DPIO_PHY1 &&
-   !(I915_READ(BXT_PORT_REF_DW3(DPIO_PHY1)) & GRC_DONE)) {
-   DRM_DEBUG_DRIVER("DDI PHY 1 powered, but GRC isn't done\n");
+   if (phy_info->rcomp_phy == -1 &&
+   !(I915_READ(BXT_PORT_REF_DW3(phy)) & GRC_DONE)) {
+   DRM_DEBUG_DRIVER("DDI PHY %d powered, but GRC isn't done\n",
+phy);
 
return false;
}
@@ -261,14 +271,15 @@ static void bxt_phy_wait_grc_done(struct drm_i915_private 
*dev_priv,
DRM_ERROR("timeout waiting for PHY%d GRC\n", phy);
 }
 
-void bxt_ddi_phy_init(struct drm_i915_private *dev_priv, enum dpio_phy phy)
+static void _bxt_ddi_phy_init(struct drm_i915_private *dev_priv,
+ enum dpio_phy phy)
 {
const struct bxt_ddi_phy_info *phy_info = _ddi_phy_info[phy];
u32 val;
 
if (bxt_ddi_phy_is_enabled(dev_priv, phy)) {
/* Still read out the GRC value for state verification */
-   if (phy == DPIO_PHY0)
+   if (phy_info->rcomp_phy != -1)
dev_priv->bxt_phy_grc = bxt_get_grc(dev_priv, phy);
 
if (bxt_ddi_phy_verify_state(dev_priv, phy)) {
@@ -338,30 +349,32 @@ void bxt_ddi_phy_init(struct drm_i915_private *dev_priv, 
enum dpio_phy phy)
val |= OCL2_LDOFUSE_PWR_DIS;
I915_WRITE(BXT_PORT_CL1CM_DW30(phy), val);
 
-   if (phy == DPIO_PHY0) {
+   if (phy_info->rcomp_phy != -1) {
uint32_t grc_code;
/*
 * PHY0 isn't connected to an RCOMP resistor so copy over
 * the corresponding calibrated value from PHY1, and disable
 * the automatic calibration on PHY0.
 */
-   val = dev_priv->bxt_phy_grc = bxt_get_grc(dev_priv, DPIO_PHY1);
+   val = dev_priv->bxt_phy_grc = bxt_get_grc(dev_priv,
+ phy_info->rcomp_phy);
grc_code = val << GRC_CODE_FAST_SHIFT |
   val << GRC_CODE_SLOW_SHIFT |
   val;
-   I915_WRITE(BXT_PORT_REF_DW6(DPIO_PHY0), grc_code);
+   I915_WRITE(BXT_PORT_REF_DW6(phy), grc_code);
 
-   val = I915_READ(BXT_PORT_REF_DW8(DPIO_PHY0));
+   val = I915_READ(BXT_PORT_REF_DW8(phy));
val |= GRC_DIS | GRC_RDY_OVRD;
-   I915_WRITE(BXT_PORT_REF_DW8(DPIO_PHY0), val);
+   I915_WRITE(BXT_PORT_REF_DW8(phy), val);
}
 
val = I915_READ(BXT_PHY_CTL_FAMILY(phy));
val |= COMMON_RESET_DIS;
I915_WRITE(BXT_PHY_CTL_FAMILY(phy), val);
 
-   if (phy == DPIO_PHY1)
-   bxt_phy_wait_grc_done(dev_priv, DPIO_PHY1);
+   

[Intel-gfx] [PATCH v2 2/9] drm/i915: Explicitly map broxton DPIO power wells to phys

[Ander Conselvan de Oliveira]

The mapping from the BXT_DPIO_CMN_* power wells to their respective phys
required a detour implemented in the bxt_power_well_to_phy() function.
Instead, embed that information directly into the power_well struct, by
resurrecting the data field.

Signed-off-by: Ander Conselvan de Oliveira 

Reviewed-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_drv.h |  5 +
 drivers/gpu/drm/i915/intel_runtime_pm.c | 22 +++---
 2 files changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5bd3f59..93c90b9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1318,6 +1318,11 @@ struct i915_power_well {
unsigned long domains;
/* unique identifier for this power well */
unsigned long id;
+   /*
+* Arbitraty data associated with this power well. Platform and power
+* well specific.
+*/
+   unsigned long data;
const struct i915_power_well_ops *ops;
 };
 
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 4ecaf6a..d41fd46 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -846,13 +846,6 @@ static void skl_power_well_disable(struct drm_i915_private 
*dev_priv,
skl_set_power_well(dev_priv, power_well, false);
 }
 
-static enum dpio_phy bxt_power_well_to_phy(struct i915_power_well *power_well)
-{
-   enum skl_disp_power_wells power_well_id = power_well->id;
-
-   return power_well_id == BXT_DPIO_CMN_A ? DPIO_PHY1 : DPIO_PHY0;
-}
-
 static void bxt_dpio_cmn_power_well_enable(struct drm_i915_private *dev_priv,
   struct i915_power_well *power_well)
 {
@@ -868,7 +861,7 @@ static void bxt_dpio_cmn_power_well_enable(struct 
drm_i915_private *dev_priv,
intel_power_well_get(dev_priv, cmn_a_well);
}
 
-   bxt_ddi_phy_init(dev_priv, bxt_power_well_to_phy(power_well));
+   bxt_ddi_phy_init(dev_priv, power_well->data);
 
if (cmn_a_well)
intel_power_well_put(dev_priv, cmn_a_well);
@@ -877,14 +870,13 @@ static void bxt_dpio_cmn_power_well_enable(struct 
drm_i915_private *dev_priv,
 static void bxt_dpio_cmn_power_well_disable(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
 {
-   bxt_ddi_phy_uninit(dev_priv, bxt_power_well_to_phy(power_well));
+   bxt_ddi_phy_uninit(dev_priv, power_well->data);
 }
 
 static bool bxt_dpio_cmn_power_well_enabled(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
 {
-   return bxt_ddi_phy_is_enabled(dev_priv,
- bxt_power_well_to_phy(power_well));
+   return bxt_ddi_phy_is_enabled(dev_priv, power_well->data);
 }
 
 static void bxt_dpio_cmn_power_well_sync_hw(struct drm_i915_private *dev_priv,
@@ -903,13 +895,11 @@ static void bxt_verify_ddi_phy_power_wells(struct 
drm_i915_private *dev_priv)
 
power_well = lookup_power_well(dev_priv, BXT_DPIO_CMN_A);
if (power_well->count > 0)
-   bxt_ddi_phy_verify_state(dev_priv,
-bxt_power_well_to_phy(power_well));
+   bxt_ddi_phy_verify_state(dev_priv, power_well->data);
 
power_well = lookup_power_well(dev_priv, BXT_DPIO_CMN_BC);
if (power_well->count > 0)
-   bxt_ddi_phy_verify_state(dev_priv,
-bxt_power_well_to_phy(power_well));
+   bxt_ddi_phy_verify_state(dev_priv, power_well->data);
 }
 
 static bool gen9_dc_off_power_well_enabled(struct drm_i915_private *dev_priv,
@@ -2163,12 +2153,14 @@ static struct i915_power_well bxt_power_wells[] = {
.domains = BXT_DPIO_CMN_A_POWER_DOMAINS,
.ops = _dpio_cmn_power_well_ops,
.id = BXT_DPIO_CMN_A,
+   .data = DPIO_PHY1,
},
{
.name = "dpio-common-bc",
.domains = BXT_DPIO_CMN_BC_POWER_DOMAINS,
.ops = _dpio_cmn_power_well_ops,
.id = BXT_DPIO_CMN_BC,
+   .data = DPIO_PHY0,
},
 };
 
-- 
git-series 0.8.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 6/9] drm/i915: Move broxton vswing sequence to intel_dpio_phy.c

[Ander Conselvan de Oliveira]

The vswing sequence is related to the DPIO phy, so move it closer to the
rest of DPIO phy related code.

Signed-off-by: Ander Conselvan de Oliveira 

Reviewed-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_drv.h   |  3 ++-
 drivers/gpu/drm/i915/intel_ddi.c  | 38 +++
 drivers/gpu/drm/i915/intel_dpio_phy.c | 39 -
 3 files changed, 47 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8bdbbb5..77f1374 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3735,6 +3735,9 @@ u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, 
u32 reg);
 void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
 
 /* intel_dpio_phy.c */
+void bxt_ddi_phy_set_signal_level(struct drm_i915_private *dev_priv,
+ enum port port, u32 margin, u32 scale,
+ u32 enable, u32 deemphasis);
 void bxt_ddi_phy_init(struct drm_i915_private *dev_priv, enum dpio_phy phy);
 void bxt_ddi_phy_uninit(struct drm_i915_private *dev_priv, enum dpio_phy phy);
 bool bxt_ddi_phy_is_enabled(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index d69d231..f27cd67 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1477,7 +1477,6 @@ static void bxt_ddi_vswing_sequence(struct 
drm_i915_private *dev_priv,
 {
const struct bxt_ddi_buf_trans *ddi_translations;
u32 n_entries, i;
-   uint32_t val;
 
if (type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.low_vswing) {
n_entries = ARRAY_SIZE(bxt_ddi_translations_edp);
@@ -1506,38 +1505,11 @@ static void bxt_ddi_vswing_sequence(struct 
drm_i915_private *dev_priv,
}
}
 
-   /*
-* While we write to the group register to program all lanes at once we
-* can read only lane registers and we pick lanes 0/1 for that.
-*/
-   val = I915_READ(BXT_PORT_PCS_DW10_LN01(port));
-   val &= ~(TX2_SWING_CALC_INIT | TX1_SWING_CALC_INIT);
-   I915_WRITE(BXT_PORT_PCS_DW10_GRP(port), val);
-
-   val = I915_READ(BXT_PORT_TX_DW2_LN0(port));
-   val &= ~(MARGIN_000 | UNIQ_TRANS_SCALE);
-   val |= ddi_translations[level].margin << MARGIN_000_SHIFT |
-  ddi_translations[level].scale << UNIQ_TRANS_SCALE_SHIFT;
-   I915_WRITE(BXT_PORT_TX_DW2_GRP(port), val);
-
-   val = I915_READ(BXT_PORT_TX_DW3_LN0(port));
-   val &= ~SCALE_DCOMP_METHOD;
-   if (ddi_translations[level].enable)
-   val |= SCALE_DCOMP_METHOD;
-
-   if ((val & UNIQUE_TRANGE_EN_METHOD) && !(val & SCALE_DCOMP_METHOD))
-   DRM_ERROR("Disabled scaling while ouniqetrangenmethod was set");
-
-   I915_WRITE(BXT_PORT_TX_DW3_GRP(port), val);
-
-   val = I915_READ(BXT_PORT_TX_DW4_LN0(port));
-   val &= ~DE_EMPHASIS;
-   val |= ddi_translations[level].deemphasis << DEEMPH_SHIFT;
-   I915_WRITE(BXT_PORT_TX_DW4_GRP(port), val);
-
-   val = I915_READ(BXT_PORT_PCS_DW10_LN01(port));
-   val |= TX2_SWING_CALC_INIT | TX1_SWING_CALC_INIT;
-   I915_WRITE(BXT_PORT_PCS_DW10_GRP(port), val);
+   bxt_ddi_phy_set_signal_level(dev_priv, port,
+ddi_translations[level].margin,
+ddi_translations[level].scale,
+ddi_translations[level].enable,
+ddi_translations[level].deemphasis);
 }
 
 static uint32_t translate_signal_level(int signal_levels)
diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
b/drivers/gpu/drm/i915/intel_dpio_phy.c
index 6806296..2a18724 100644
--- a/drivers/gpu/drm/i915/intel_dpio_phy.c
+++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
@@ -114,6 +114,45 @@
  * -
  */
 
+void bxt_ddi_phy_set_signal_level(struct drm_i915_private *dev_priv,
+ enum port port, u32 margin, u32 scale,
+ u32 enable, u32 deemphasis)
+{
+   u32 val;
+
+   /*
+* While we write to the group register to program all lanes at once we
+* can read only lane registers and we pick lanes 0/1 for that.
+*/
+   val = I915_READ(BXT_PORT_PCS_DW10_LN01(port));
+   val &= ~(TX2_SWING_CALC_INIT | TX1_SWING_CALC_INIT);
+   I915_WRITE(BXT_PORT_PCS_DW10_GRP(port), val);
+
+   val = I915_READ(BXT_PORT_TX_DW2_LN0(port));
+   val &= ~(MARGIN_000 | UNIQ_TRANS_SCALE);
+   val |= margin << MARGIN_000_SHIFT | scale << UNIQ_TRANS_SCALE_SHIFT;
+   I915_WRITE(BXT_PORT_TX_DW2_GRP(port), val);
+
+   val = I915_READ(BXT_PORT_TX_DW3_LN0(port));
+   val &= ~SCALE_DCOMP_METHOD;
+   if (enable)
+   val |= SCALE_DCOMP_METHOD;
+
+   if ((val & 

[Intel-gfx] [PATCH v2 7/9] drm/i915: Create a struct to hold information about the broxton phys

[Ander Conselvan de Oliveira]

Information about which phy is dual channel is hardcoded in the phy init
sequence. Split that to a separate struct so the init sequence is more
generic.

v2: Restore mangled part that ended up in following patch. (Imre)

Signed-off-by: Ander Conselvan de Oliveira 

Reviewed-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_reg.h   |  9 +++-
 drivers/gpu/drm/i915/intel_dpio_phy.c | 65 +++-
 2 files changed, 62 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f6d29fb..d3802c6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1308,8 +1308,13 @@ enum skl_disp_power_wells {
 #define BXT_PORT_CL1CM_DW30(phy)   _BXT_PHY((phy), _PORT_CL1CM_DW30_BC, \
_PORT_CL1CM_DW30_A)
 
-/* Defined for PHY0 only */
-#define BXT_PORT_CL2CM_DW6_BC  _MMIO(0x6C358)
+/* The spec defines this only for BXT PHY0, but lets assume that this
+ * would exist for PHY1 too if it had a second channel.
+ */
+#define _PORT_CL2CM_DW6_A  0x162358
+#define _PORT_CL2CM_DW6_BC 0x6C358
+#define BXT_PORT_CL2CM_DW6(phy)_BXT_PHY((phy), 
_PORT_CL2CM_DW6_BC, \
+   _PORT_CL2CM_DW6_A)
 #define   DW6_OLDO_DYN_PWR_DOWN_EN (1 << 28)
 
 /* BXT PHY Ref registers */
diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
b/drivers/gpu/drm/i915/intel_dpio_phy.c
index 2a18724..1b1fba1 100644
--- a/drivers/gpu/drm/i915/intel_dpio_phy.c
+++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
@@ -114,6 +114,50 @@
  * -
  */
 
+/**
+ * struct bxt_ddi_phy_info - Hold info for a broxton DDI phy
+ */
+struct bxt_ddi_phy_info {
+   /**
+* @dual_channel: true if this phy has a second channel.
+*/
+   bool dual_channel;
+
+   /**
+* @channel: struct containing per channel information.
+*/
+   struct {
+   /**
+* @port: which port maps to this channel.
+*/
+   enum port port;
+   } channel[2];
+};
+
+static const struct bxt_ddi_phy_info bxt_ddi_phy_info[] = {
+   [DPIO_PHY0] = {
+   .dual_channel = true,
+
+   .channel = {
+   [DPIO_CH0] = { .port = PORT_B },
+   [DPIO_CH1] = { .port = PORT_C },
+   }
+   },
+   [DPIO_PHY1] = {
+   .dual_channel = false,
+
+   .channel = {
+   [DPIO_CH0] = { .port = PORT_A },
+   }
+   },
+};
+
+static u32 bxt_phy_port_mask(const struct bxt_ddi_phy_info *phy_info)
+{
+   return (phy_info->dual_channel * BIT(phy_info->channel[DPIO_CH1].port)) 
|
+   BIT(phy_info->channel[DPIO_CH0].port);
+}
+
 void bxt_ddi_phy_set_signal_level(struct drm_i915_private *dev_priv,
  enum port port, u32 margin, u32 scale,
  u32 enable, u32 deemphasis)
@@ -156,6 +200,7 @@ void bxt_ddi_phy_set_signal_level(struct drm_i915_private 
*dev_priv,
 bool bxt_ddi_phy_is_enabled(struct drm_i915_private *dev_priv,
enum dpio_phy phy)
 {
+   const struct bxt_ddi_phy_info *phy_info = _ddi_phy_info[phy];
enum port port;
 
if (!(I915_READ(BXT_P_CR_GT_DISP_PWRON) & GT_DISPLAY_POWER_ON(phy)))
@@ -183,9 +228,7 @@ bool bxt_ddi_phy_is_enabled(struct drm_i915_private 
*dev_priv,
return false;
}
 
-   for_each_port_masked(port,
-phy == DPIO_PHY0 ? BIT(PORT_B) | BIT(PORT_C) :
-   BIT(PORT_A)) {
+   for_each_port_masked(port, bxt_phy_port_mask(phy_info)) {
u32 tmp = I915_READ(BXT_PHY_CTL(port));
 
if (tmp & BXT_PHY_CMNLANE_POWERDOWN_ACK) {
@@ -220,6 +263,7 @@ static void bxt_phy_wait_grc_done(struct drm_i915_private 
*dev_priv,
 
 void bxt_ddi_phy_init(struct drm_i915_private *dev_priv, enum dpio_phy phy)
 {
+   const struct bxt_ddi_phy_info *phy_info = _ddi_phy_info[phy];
u32 val;
 
if (bxt_ddi_phy_is_enabled(dev_priv, phy)) {
@@ -272,10 +316,10 @@ void bxt_ddi_phy_init(struct drm_i915_private *dev_priv, 
enum dpio_phy phy)
SUS_CLK_CONFIG;
I915_WRITE(BXT_PORT_CL1CM_DW28(phy), val);
 
-   if (phy == DPIO_PHY0) {
-   val = I915_READ(BXT_PORT_CL2CM_DW6_BC);
+   if (phy_info->dual_channel) {
+   val = I915_READ(BXT_PORT_CL2CM_DW6(phy));
val |= DW6_OLDO_DYN_PWR_DOWN_EN;
-   I915_WRITE(BXT_PORT_CL2CM_DW6_BC, val);
+   I915_WRITE(BXT_PORT_CL2CM_DW6(phy), val);
}
 
val = I915_READ(BXT_PORT_CL1CM_DW30(phy));
@@ -290,7 +334,7 @@ void bxt_ddi_phy_init(struct drm_i915_private *dev_priv, 
enum dpio_phy phy)
 

[Intel-gfx] [PATCH v2 1/9] drm/i915: Rename struct i915_power_well field data to id

[Ander Conselvan de Oliveira]

Calling it data seems to imply arbitrary data can be associated with the
power well. However, that field is used for look ups and expected to be
unique, so rename it.

Signed-off-by: Ander Conselvan de Oliveira 

Reviewed-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_drv.h |   3 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 112 -
 2 files changed, 58 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4613f03..5bd3f59 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1316,7 +1316,8 @@ struct i915_power_well {
/* cached hw enabled state */
bool hw_enabled;
unsigned long domains;
-   unsigned long data;
+   /* unique identifier for this power well */
+   unsigned long id;
const struct i915_power_well_ops *ops;
 };
 
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 6c11168..4ecaf6a 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -331,7 +331,7 @@ static void skl_power_well_post_enable(struct 
drm_i915_private *dev_priv,
 * sure vgacon can keep working normally without triggering interrupts
 * and error messages.
 */
-   if (power_well->data == SKL_DISP_PW_2) {
+   if (power_well->id == SKL_DISP_PW_2) {
vga_get_uninterruptible(pdev, VGA_RSRC_LEGACY_IO);
outb(inb(VGA_MSR_READ), VGA_MSR_WRITE);
vga_put(pdev, VGA_RSRC_LEGACY_IO);
@@ -344,7 +344,7 @@ static void skl_power_well_post_enable(struct 
drm_i915_private *dev_priv,
 static void skl_power_well_pre_disable(struct drm_i915_private *dev_priv,
   struct i915_power_well *power_well)
 {
-   if (power_well->data == SKL_DISP_PW_2)
+   if (power_well->id == SKL_DISP_PW_2)
gen8_irq_power_well_pre_disable(dev_priv,
1 << PIPE_C | 1 << PIPE_B);
 }
@@ -659,7 +659,7 @@ static void
 gen9_sanitize_power_well_requests(struct drm_i915_private *dev_priv,
  struct i915_power_well *power_well)
 {
-   enum skl_disp_power_wells power_well_id = power_well->data;
+   enum skl_disp_power_wells power_well_id = power_well->id;
u32 val;
u32 mask;
 
@@ -704,7 +704,7 @@ static void skl_set_power_well(struct drm_i915_private 
*dev_priv,
tmp = I915_READ(HSW_PWR_WELL_DRIVER);
fuse_status = I915_READ(SKL_FUSE_STATUS);
 
-   switch (power_well->data) {
+   switch (power_well->id) {
case SKL_DISP_PW_1:
if (intel_wait_for_register(dev_priv,
SKL_FUSE_STATUS,
@@ -728,13 +728,13 @@ static void skl_set_power_well(struct drm_i915_private 
*dev_priv,
case SKL_DISP_PW_MISC_IO:
break;
default:
-   WARN(1, "Unknown power well %lu\n", power_well->data);
+   WARN(1, "Unknown power well %lu\n", power_well->id);
return;
}
 
-   req_mask = SKL_POWER_WELL_REQ(power_well->data);
+   req_mask = SKL_POWER_WELL_REQ(power_well->id);
enable_requested = tmp & req_mask;
-   state_mask = SKL_POWER_WELL_STATE(power_well->data);
+   state_mask = SKL_POWER_WELL_STATE(power_well->id);
is_enabled = tmp & state_mask;
 
if (!enable && enable_requested)
@@ -770,14 +770,14 @@ static void skl_set_power_well(struct drm_i915_private 
*dev_priv,
  power_well->name, enable ? "enable" : "disable");
 
if (check_fuse_status) {
-   if (power_well->data == SKL_DISP_PW_1) {
+   if (power_well->id == SKL_DISP_PW_1) {
if (intel_wait_for_register(dev_priv,
SKL_FUSE_STATUS,
SKL_FUSE_PG1_DIST_STATUS,
SKL_FUSE_PG1_DIST_STATUS,
1))
DRM_ERROR("PG1 distributing status timeout\n");
-   } else if (power_well->data == SKL_DISP_PW_2) {
+   } else if (power_well->id == SKL_DISP_PW_2) {
if (intel_wait_for_register(dev_priv,
SKL_FUSE_STATUS,
SKL_FUSE_PG2_DIST_STATUS,
@@ -819,8 +819,8 @@ static void hsw_power_well_disable(struct drm_i915_private 
*dev_priv,
 static bool skl_power_well_enabled(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
 {
-   uint32_t mask = SKL_POWER_WELL_REQ(power_well->data) |
-   

[Intel-gfx] [PATCH v2 0/9] Broxton ddi phy refactoring

[Ander Conselvan de Oliveira]

Update series with review addressed. Changes since v1:

  - Use lockdep_assert_help() in bxt_ddi_phy_init().
  - Fix mangled patch.
  - Pass enum dpio_phy instead of mmio base to macroc.

Thanks,
Ander

Ander Conselvan de Oliveira (9):
  drm/i915: Rename struct i915_power_well field data to id
  drm/i915: Explicitly map broxton DPIO power wells to phys
  drm/i915: Pass lane count to bxt_ddi_phy_calc_lane_optmin_mask()
  drm/i915: Move broxton phy code to intel_dpio_phy.c
  drm/i915: Move DPIO phy documentation section to intel_dpio_phy.c
  drm/i915: Move broxton vswing sequence to intel_dpio_phy.c
  drm/i915: Create a struct to hold information about the broxton phys
  drm/i915: Add location of the Rcomp resistor to bxt_ddi_phy_info
  drm/i915: Address broxton phy registers based on phy and channel number

 Documentation/gpu/i915.rst  |   2 +-
 drivers/gpu/drm/i915/i915_drv.h |  23 +-
 drivers/gpu/drm/i915/i915_reg.h | 237 +++---
 drivers/gpu/drm/i915/intel_ddi.c| 362 +---
 drivers/gpu/drm/i915/intel_dpio_phy.c   | 588 +-
 drivers/gpu/drm/i915/intel_dpll_mgr.c   |  84 ++--
 drivers/gpu/drm/i915/intel_drv.h|   6 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 145 ++
 8 files changed, 806 insertions(+), 641 deletions(-)

-- 
git-series 0.8.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 4/9] drm/i915: Move broxton phy code to intel_dpio_phy.c

[Ander Conselvan de Oliveira]

The phy in broxton is also a dpio phy, similar to cherryview but with
programming through MMIO. So move the code together with the other
similar phys.

Signed-off-by: Ander Conselvan de Oliveira 

Reviewed-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_drv.h   |  12 +-
 drivers/gpu/drm/i915/intel_ddi.c  | 322 +---
 drivers/gpu/drm/i915/intel_dpio_phy.c | 327 +++-
 drivers/gpu/drm/i915/intel_drv.h  |   6 +-
 4 files changed, 341 insertions(+), 326 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 93c90b9..8bdbbb5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3735,6 +3735,18 @@ u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, 
u32 reg);
 void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
 
 /* intel_dpio_phy.c */
+void bxt_ddi_phy_init(struct drm_i915_private *dev_priv, enum dpio_phy phy);
+void bxt_ddi_phy_uninit(struct drm_i915_private *dev_priv, enum dpio_phy phy);
+bool bxt_ddi_phy_is_enabled(struct drm_i915_private *dev_priv,
+   enum dpio_phy phy);
+bool bxt_ddi_phy_verify_state(struct drm_i915_private *dev_priv,
+ enum dpio_phy phy);
+uint8_t bxt_ddi_phy_calc_lane_lat_optim_mask(struct intel_encoder *encoder,
+uint8_t lane_count);
+void bxt_ddi_phy_set_lane_optim_mask(struct intel_encoder *encoder,
+uint8_t lane_lat_optim_mask);
+uint8_t bxt_ddi_phy_get_lane_lat_optim_mask(struct intel_encoder *encoder);
+
 void chv_set_phy_signal_level(struct intel_encoder *encoder,
  u32 deemph_reg_value, u32 margin_reg_value,
  bool uniq_trans_scale);
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 1dc7543..d69d231 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1853,332 +1853,14 @@ static void intel_disable_ddi(struct intel_encoder 
*intel_encoder,
}
 }
 
-bool bxt_ddi_phy_is_enabled(struct drm_i915_private *dev_priv,
-   enum dpio_phy phy)
-{
-   enum port port;
-
-   if (!(I915_READ(BXT_P_CR_GT_DISP_PWRON) & GT_DISPLAY_POWER_ON(phy)))
-   return false;
-
-   if ((I915_READ(BXT_PORT_CL1CM_DW0(phy)) &
-(PHY_POWER_GOOD | PHY_RESERVED)) != PHY_POWER_GOOD) {
-   DRM_DEBUG_DRIVER("DDI PHY %d powered, but power hasn't 
settled\n",
-phy);
-
-   return false;
-   }
-
-   if (phy == DPIO_PHY1 &&
-   !(I915_READ(BXT_PORT_REF_DW3(DPIO_PHY1)) & GRC_DONE)) {
-   DRM_DEBUG_DRIVER("DDI PHY 1 powered, but GRC isn't done\n");
-
-   return false;
-   }
-
-   if (!(I915_READ(BXT_PHY_CTL_FAMILY(phy)) & COMMON_RESET_DIS)) {
-   DRM_DEBUG_DRIVER("DDI PHY %d powered, but still in reset\n",
-phy);
-
-   return false;
-   }
-
-   for_each_port_masked(port,
-phy == DPIO_PHY0 ? BIT(PORT_B) | BIT(PORT_C) :
-   BIT(PORT_A)) {
-   u32 tmp = I915_READ(BXT_PHY_CTL(port));
-
-   if (tmp & BXT_PHY_CMNLANE_POWERDOWN_ACK) {
-   DRM_DEBUG_DRIVER("DDI PHY %d powered, but common lane "
-"for port %c powered down "
-"(PHY_CTL %08x)\n",
-phy, port_name(port), tmp);
-
-   return false;
-   }
-   }
-
-   return true;
-}
-
-static u32 bxt_get_grc(struct drm_i915_private *dev_priv, enum dpio_phy phy)
-{
-   u32 val = I915_READ(BXT_PORT_REF_DW6(phy));
-
-   return (val & GRC_CODE_MASK) >> GRC_CODE_SHIFT;
-}
-
-static void bxt_phy_wait_grc_done(struct drm_i915_private *dev_priv,
- enum dpio_phy phy)
-{
-   if (intel_wait_for_register(dev_priv,
-   BXT_PORT_REF_DW3(phy),
-   GRC_DONE, GRC_DONE,
-   10))
-   DRM_ERROR("timeout waiting for PHY%d GRC\n", phy);
-}
-
-void bxt_ddi_phy_init(struct drm_i915_private *dev_priv, enum dpio_phy phy)
-{
-   u32 val;
-
-   if (bxt_ddi_phy_is_enabled(dev_priv, phy)) {
-   /* Still read out the GRC value for state verification */
-   if (phy == DPIO_PHY0)
-   dev_priv->bxt_phy_grc = bxt_get_grc(dev_priv, phy);
-
-   if (bxt_ddi_phy_verify_state(dev_priv, phy)) {
-   DRM_DEBUG_DRIVER("DDI PHY %d already enabled, "
-"won't reprogram it\n", phy);
-
-  

[Intel-gfx] [PATCH v2 9/9] drm/i915: Address broxton phy registers based on phy and channel number

[Ander Conselvan de Oliveira]

The port registers related to the phys in broxton map to different
channels and specific phys. Make that mapping explicit.

v2: Pass enum dpio_phy to macros instead of mmio base. (Imre)

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/i915_drv.h   |   2 +-
 drivers/gpu/drm/i915/i915_reg.h   | 141 +--
 drivers/gpu/drm/i915/intel_dpio_phy.c |  80 ---
 drivers/gpu/drm/i915/intel_dpll_mgr.c |  84 
 4 files changed, 185 insertions(+), 122 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 77f1374..c3fa29a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3735,6 +3735,8 @@ u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, 
u32 reg);
 void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
 
 /* intel_dpio_phy.c */
+void bxt_port_to_phy_channel(enum port port,
+u32 *phy, enum dpio_channel *ch);
 void bxt_ddi_phy_set_signal_level(struct drm_i915_private *dev_priv,
  enum port port, u32 margin, u32 scale,
  u32 enable, u32 deemphasis);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d3802c6..d40cba8 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1187,7 +1187,19 @@ enum skl_disp_power_wells {
 #define   DPIO_UPAR_SHIFT  30
 
 /* BXT PHY registers */
-#define _BXT_PHY(phy, a, b)_MMIO_PIPE((phy), (a), (b))
+#define _BXT_PHY0_BASE 0x6C000
+#define _BXT_PHY1_BASE 0x162000
+#define BXT_PHY_BASE(phy)  _PIPE((phy), _BXT_PHY0_BASE, \
+_BXT_PHY1_BASE)
+
+#define _BXT_PHY(phy, reg) \
+   _MMIO(BXT_PHY_BASE(phy) - _BXT_PHY0_BASE + (reg))
+
+#define _BXT_PHY_CH(phy, ch, reg_ch0, reg_ch1) \
+   (BXT_PHY_BASE(phy) + _PIPE((ch), (reg_ch0) - _BXT_PHY0_BASE,\
+(reg_ch1) - _BXT_PHY0_BASE))
+#define _MMIO_BXT_PHY_CH(phy, ch, reg_ch0, reg_ch1)\
+   _MMIO(_BXT_PHY_CH(phy, ch, reg_ch0, reg_ch1))
 
 #define BXT_P_CR_GT_DISP_PWRON _MMIO(0x138090)
 #define   GT_DISPLAY_POWER_ON(phy) (1 << (phy))
@@ -1204,8 +1216,8 @@ enum skl_disp_power_wells {
 #define _PHY_CTL_FAMILY_EDP0x64C80
 #define _PHY_CTL_FAMILY_DDI0x64C90
 #define   COMMON_RESET_DIS (1 << 31)
-#define BXT_PHY_CTL_FAMILY(phy)_BXT_PHY((phy), 
_PHY_CTL_FAMILY_DDI, \
-   _PHY_CTL_FAMILY_EDP)
+#define BXT_PHY_CTL_FAMILY(phy)_MMIO_PIPE((phy), 
_PHY_CTL_FAMILY_DDI, \
+ _PHY_CTL_FAMILY_EDP)
 
 /* BXT PHY PLL registers */
 #define _PORT_PLL_A0x46074
@@ -1225,18 +1237,18 @@ enum skl_disp_power_wells {
 #define   PORT_PLL_P2_SHIFT8
 #define   PORT_PLL_P2_MASK (0x1f << PORT_PLL_P2_SHIFT)
 #define   PORT_PLL_P2(x)   ((x)  << PORT_PLL_P2_SHIFT)
-#define BXT_PORT_PLL_EBB_0(port)   _MMIO_PORT3(port, _PORT_PLL_EBB_0_A, \
-   _PORT_PLL_EBB_0_B,  \
-   _PORT_PLL_EBB_0_C)
+#define BXT_PORT_PLL_EBB_0(phy, ch)_MMIO_BXT_PHY_CH(phy, ch, \
+_PORT_PLL_EBB_0_B, \
+_PORT_PLL_EBB_0_C)
 
 #define _PORT_PLL_EBB_4_A  0x162038
 #define _PORT_PLL_EBB_4_B  0x6C038
 #define _PORT_PLL_EBB_4_C  0x6C344
 #define   PORT_PLL_10BIT_CLK_ENABLE(1 << 13)
 #define   PORT_PLL_RECALIBRATE (1 << 14)
-#define BXT_PORT_PLL_EBB_4(port)   _MMIO_PORT3(port, _PORT_PLL_EBB_4_A, \
-   _PORT_PLL_EBB_4_B,  \
-   _PORT_PLL_EBB_4_C)
+#define BXT_PORT_PLL_EBB_4(phy, ch)_MMIO_BXT_PHY_CH(phy, ch, \
+_PORT_PLL_EBB_4_B, \
+_PORT_PLL_EBB_4_C)
 
 #define _PORT_PLL_0_A  0x162100
 #define _PORT_PLL_0_B  0x6C100
@@ -1267,62 +1279,56 @@ enum skl_disp_power_wells {
 #define  PORT_PLL_DCO_AMP_DEFAULT  15
 #define  PORT_PLL_DCO_AMP_MASK 0x3c00
 #define  PORT_PLL_DCO_AMP(x)   ((x)<<10)
-#define _PORT_PLL_BASE(port)   _PORT3(port, _PORT_PLL_0_A, \
-   _PORT_PLL_0_B,  \
-   _PORT_PLL_0_C)
-#define BXT_PORT_PLL(port, idx)_MMIO(_PORT_PLL_BASE(port) + 

[Intel-gfx] [PATCH v2] drm/i915: Reset the breadcrumbs IRQ more carefully

[Chris Wilson]

Along with the interrupt, we want to restore the fake-irq and
wait-timeout detection. If we use the breadcrumbs interface to setup the
interrupt as it wants, the auxiliary timers will also be restored.

v2: Cancel both timers as well, sanitize the IMR.

Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 31 +--
 drivers/gpu/drm/i915/intel_engine_cs.c   | 15 ---
 drivers/gpu/drm/i915/intel_lrc.c |  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c  |  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |  2 +-
 5 files changed, 32 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 9bad14d22c95..3dd23c16bea1 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -578,6 +578,34 @@ int intel_engine_init_breadcrumbs(struct intel_engine_cs 
*engine)
return 0;
 }
 
+static void cancel_fake_irq(struct intel_engine_cs *engine)
+{
+   struct intel_breadcrumbs *b = >breadcrumbs;
+
+   del_timer_sync(>hangcheck);
+   del_timer_sync(>fake_irq);
+   clear_bit(engine->id, >i915->gpu_error.missed_irq_rings);
+}
+
+void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine)
+{
+   struct intel_breadcrumbs *b = >breadcrumbs;
+
+   cancel_fake_irq(engine);
+   spin_lock(>lock);
+
+   __intel_breadcrumbs_disable_irq(b);
+   if (intel_engine_has_waiter(engine)) {
+   b->timeout = wait_timeout();
+   __intel_breadcrumbs_enable_irq(b);
+   } else {
+   /* sanitize the IMR and unmask any auxiliary interrupts */
+   irq_disable(engine);
+   }
+
+   spin_unlock(>lock);
+}
+
 void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine)
 {
struct intel_breadcrumbs *b = >breadcrumbs;
@@ -585,8 +613,7 @@ void intel_engine_fini_breadcrumbs(struct intel_engine_cs 
*engine)
if (!IS_ERR_OR_NULL(b->signaler))
kthread_stop(b->signaler);
 
-   del_timer_sync(>hangcheck);
-   del_timer_sync(>fake_irq);
+   cancel_fake_irq(engine);
 }
 
 unsigned int intel_kick_waiters(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index d00ec805f93d..480584c09306 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -210,9 +210,6 @@ void intel_engine_init_seqno(struct intel_engine_cs 
*engine, u32 seqno)
 void intel_engine_init_hangcheck(struct intel_engine_cs *engine)
 {
memset(>hangcheck, 0, sizeof(engine->hangcheck));
-   clear_bit(engine->id, >i915->gpu_error.missed_irq_rings);
-   if (intel_engine_has_waiter(engine))
-   i915_queue_hangcheck(engine->i915);
 }
 
 static void intel_engine_init_requests(struct intel_engine_cs *engine)
@@ -307,18 +304,6 @@ int intel_engine_init_common(struct intel_engine_cs 
*engine)
return 0;
 }
 
-void intel_engine_reset_irq(struct intel_engine_cs *engine)
-{
-   struct drm_i915_private *dev_priv = engine->i915;
-
-   spin_lock_irq(_priv->irq_lock);
-   if (intel_engine_has_waiter(engine))
-   engine->irq_enable(engine);
-   else
-   engine->irq_disable(engine);
-   spin_unlock_irq(_priv->irq_lock);
-}
-
 /**
  * intel_engines_cleanup_common - cleans up the engine state created by
  *the common initiailizers.
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 936f6f63f626..44904e298bfc 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1230,7 +1230,7 @@ static int gen8_init_common_ring(struct intel_engine_cs 
*engine)
 
lrc_init_hws(engine);
 
-   intel_engine_reset_irq(engine);
+   intel_engine_reset_breadcrumbs(engine);
 
I915_WRITE(RING_HWSTAM(engine->mmio_base), 0x);
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 35f359e38f4d..729f373782e2 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -548,7 +548,7 @@ static int init_ring_common(struct intel_engine_cs *engine)
else
intel_ring_setup_status_page(engine);
 
-   intel_engine_reset_irq(engine);
+   intel_engine_reset_breadcrumbs(engine);
 
/* Enforce ordering by reading HEAD register back */
I915_READ_HEAD(engine);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 34954ca03a4a..124f4646958d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -520,7 +520,6 @@ int 

[Intel-gfx] [PATCH v11 4/4] drm/i915: Put "cooked" vlank counters in frame CRC lines

[Tomeu Vizoso]

Use drm_accurate_vblank_count so we have the full 32 bit to represent
the frame counter and userspace has a simpler way of knowing when the
counter wraps around.

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Emil Velikov 
---

 drivers/gpu/drm/i915/i915_irq.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1549cc4f88ec..238a353454e9 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1495,7 +1495,6 @@ static void display_pipe_crc_irq_handler(struct 
drm_i915_private *dev_priv,
struct drm_driver *driver = dev_priv->drm.driver;
uint32_t crcs[5];
int head, tail, ret;
-   u32 frame;
 
spin_lock(_crc->lock);
if (pipe_crc->source) {
@@ -1551,8 +1550,9 @@ static void display_pipe_crc_irq_handler(struct 
drm_i915_private *dev_priv,
crcs[2] = crc2;
crcs[3] = crc3;
crcs[4] = crc4;
-   frame = driver->get_vblank_counter(_priv->drm, pipe);
-   ret = drm_crtc_add_crc_entry(crtc, true, frame, crcs);
+   ret = drm_crtc_add_crc_entry(crtc, true,
+drm_accurate_vblank_count(crtc),
+crcs);
spin_unlock(>crc.lock);
if (!ret)
wake_up_interruptible(>crc.wq);
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v11 3/4] drm/i915: Use new CRC debugfs API

[Tomeu Vizoso]

The core provides now an ABI to userspace for generation of frame CRCs,
so implement the ->set_crc_source() callback and reuse as much code as
possible with the previous ABI implementation.

When handling the pageflip interrupt, we skip 1 or 2 frames depending on
the HW because they contain wrong values. For the legacy ABI for
generating frame CRCs, this was done in userspace but now that we have a
generic ABI it's better if it's not exposed by the kernel.

v2:
- Leave the legacy implementation in place as the ABI implementation
  in the core is incompatible with it.
v3:
- Use the "cooked" vblank counter so we have a whole 32 bits.
- Make sure we don't mess with the state of the legacy CRC capture
  ABI implementation.
v4:
- Keep use of get_vblank_counter as in the legacy code, will be
  changed in a followup commit.

v5:
- Skip first frame or two as it's known that they contain wrong
  data.
- A few fixes suggested by Emil Velikov.

v6:
- Rework programming of the HW registers to preserve previous
  behavior.

v7:
- Address whitespace issue.
- Added a comment on why in the implementation of the new ABI we
  skip the 1st or 2nd frames.

v9:
- Add stub for intel_crtc_set_crc_source.

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Emil Velikov 
---

 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/i915_irq.c   | 83 +--
 drivers/gpu/drm/i915/intel_display.c  |  1 +
 drivers/gpu/drm/i915/intel_drv.h  |  8 +++
 drivers/gpu/drm/i915/intel_pipe_crc.c | 94 ++-
 5 files changed, 149 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f8c66eea06bc..20522f0a4c57 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1713,6 +1713,7 @@ struct intel_pipe_crc {
enum intel_pipe_crc_source source;
int head, tail;
wait_queue_head_t wq;
+   int skipped;
 };
 
 struct i915_frontbuffer_tracking {
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bd6c8b0eeaef..1549cc4f88ec 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1491,41 +1491,72 @@ static void display_pipe_crc_irq_handler(struct 
drm_i915_private *dev_priv,
 {
struct intel_pipe_crc *pipe_crc = _priv->pipe_crc[pipe];
struct intel_pipe_crc_entry *entry;
-   int head, tail;
+   struct drm_crtc *crtc = intel_get_crtc_for_pipe(_priv->drm, pipe);
+   struct drm_driver *driver = dev_priv->drm.driver;
+   uint32_t crcs[5];
+   int head, tail, ret;
+   u32 frame;
 
spin_lock(_crc->lock);
+   if (pipe_crc->source) {
+   if (!pipe_crc->entries) {
+   spin_unlock(_crc->lock);
+   DRM_DEBUG_KMS("spurious interrupt\n");
+   return;
+   }
 
-   if (!pipe_crc->entries) {
-   spin_unlock(_crc->lock);
-   DRM_DEBUG_KMS("spurious interrupt\n");
-   return;
-   }
-
-   head = pipe_crc->head;
-   tail = pipe_crc->tail;
+   head = pipe_crc->head;
+   tail = pipe_crc->tail;
 
-   if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
-   spin_unlock(_crc->lock);
-   DRM_ERROR("CRC buffer overflowing\n");
-   return;
-   }
+   if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
+   spin_unlock(_crc->lock);
+   DRM_ERROR("CRC buffer overflowing\n");
+   return;
+   }
 
-   entry = _crc->entries[head];
+   entry = _crc->entries[head];
 
-   entry->frame = dev_priv->drm.driver->get_vblank_counter(_priv->drm,
-pipe);
-   entry->crc[0] = crc0;
-   entry->crc[1] = crc1;
-   entry->crc[2] = crc2;
-   entry->crc[3] = crc3;
-   entry->crc[4] = crc4;
+   entry->frame = driver->get_vblank_counter(_priv->drm, pipe);
+   entry->crc[0] = crc0;
+   entry->crc[1] = crc1;
+   entry->crc[2] = crc2;
+   entry->crc[3] = crc3;
+   entry->crc[4] = crc4;
 
-   head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
-   pipe_crc->head = head;
+   head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
+   pipe_crc->head = head;
 
-   spin_unlock(_crc->lock);
+   spin_unlock(_crc->lock);
 
-   wake_up_interruptible(_crc->wq);
+   wake_up_interruptible(_crc->wq);
+   } else {
+   /*
+* For some not yet identified reason, the first CRC is
+* bonkers. So let's just wait for the next vblank and read
+   

[Intel-gfx] [PATCH v11 1/4] drm/i915/debugfs: Move out pipe CRC code

[Tomeu Vizoso]

In preparation to using a generic API in the DRM core for continuous CRC
generation, move the related code out of i915_debugfs.c into a new file.

Eventually, only the Intel-specific code will remain in this new file.

v2: Rebased.

v6: Rebased.

v7: Fix whitespace issue.

v9: Have intel_display_crc_init accept a drm_i915_private instead.

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Emil Velikov 
---

 drivers/gpu/drm/i915/Makefile |   2 +-
 drivers/gpu/drm/i915/i915_debugfs.c   | 886 +---
 drivers/gpu/drm/i915/intel_drv.h  |   5 +
 drivers/gpu/drm/i915/intel_pipe_crc.c | 943 ++
 4 files changed, 953 insertions(+), 883 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_pipe_crc.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a998c2bce70a..e6fe0040fe64 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -24,7 +24,7 @@ i915-y := i915_drv.o \
  intel_runtime_pm.o
 
 i915-$(CONFIG_COMPAT)   += i915_ioc32.o
-i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o
+i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o intel_pipe_crc.o
 
 # GEM code
 i915-y += i915_cmd_parser.o \
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index da7141382b00..4fb9d829884e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -26,19 +26,9 @@
  *
  */
 
-#include 
-#include 
-#include 
 #include 
-#include 
-#include 
 #include 
-#include 
-#include 
 #include "intel_drv.h"
-#include "intel_ringbuffer.h"
-#include 
-#include "i915_drv.h"
 
 static inline struct drm_i915_private *node_to_i915(struct drm_info_node *node)
 {
@@ -3414,12 +3404,6 @@ static int i915_drrs_status(struct seq_file *m, void 
*unused)
return 0;
 }
 
-struct pipe_crc_info {
-   const char *name;
-   struct drm_i915_private *dev_priv;
-   enum pipe pipe;
-};
-
 static int i915_dp_mst_info(struct seq_file *m, void *unused)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -3449,848 +3433,6 @@ static int i915_dp_mst_info(struct seq_file *m, void 
*unused)
return 0;
 }
 
-static int i915_pipe_crc_open(struct inode *inode, struct file *filep)
-{
-   struct pipe_crc_info *info = inode->i_private;
-   struct drm_i915_private *dev_priv = info->dev_priv;
-   struct intel_pipe_crc *pipe_crc = _priv->pipe_crc[info->pipe];
-
-   if (info->pipe >= INTEL_INFO(dev_priv)->num_pipes)
-   return -ENODEV;
-
-   spin_lock_irq(_crc->lock);
-
-   if (pipe_crc->opened) {
-   spin_unlock_irq(_crc->lock);
-   return -EBUSY; /* already open */
-   }
-
-   pipe_crc->opened = true;
-   filep->private_data = inode->i_private;
-
-   spin_unlock_irq(_crc->lock);
-
-   return 0;
-}
-
-static int i915_pipe_crc_release(struct inode *inode, struct file *filep)
-{
-   struct pipe_crc_info *info = inode->i_private;
-   struct drm_i915_private *dev_priv = info->dev_priv;
-   struct intel_pipe_crc *pipe_crc = _priv->pipe_crc[info->pipe];
-
-   spin_lock_irq(_crc->lock);
-   pipe_crc->opened = false;
-   spin_unlock_irq(_crc->lock);
-
-   return 0;
-}
-
-/* (6 fields, 8 chars each, space separated (5) + '\n') */
-#define PIPE_CRC_LINE_LEN  (6 * 8 + 5 + 1)
-/* account for \'0' */
-#define PIPE_CRC_BUFFER_LEN(PIPE_CRC_LINE_LEN + 1)
-
-static int pipe_crc_data_count(struct intel_pipe_crc *pipe_crc)
-{
-   assert_spin_locked(_crc->lock);
-   return CIRC_CNT(pipe_crc->head, pipe_crc->tail,
-   INTEL_PIPE_CRC_ENTRIES_NR);
-}
-
-static ssize_t
-i915_pipe_crc_read(struct file *filep, char __user *user_buf, size_t count,
-  loff_t *pos)
-{
-   struct pipe_crc_info *info = filep->private_data;
-   struct drm_i915_private *dev_priv = info->dev_priv;
-   struct intel_pipe_crc *pipe_crc = _priv->pipe_crc[info->pipe];
-   char buf[PIPE_CRC_BUFFER_LEN];
-   int n_entries;
-   ssize_t bytes_read;
-
-   /*
-* Don't allow user space to provide buffers not big enough to hold
-* a line of data.
-*/
-   if (count < PIPE_CRC_LINE_LEN)
-   return -EINVAL;
-
-   if (pipe_crc->source == INTEL_PIPE_CRC_SOURCE_NONE)
-   return 0;
-
-   /* nothing to read */
-   spin_lock_irq(_crc->lock);
-   while (pipe_crc_data_count(pipe_crc) == 0) {
-   int ret;
-
-   if (filep->f_flags & O_NONBLOCK) {
-   spin_unlock_irq(_crc->lock);
-   return -EAGAIN;
-   }
-
-   ret = wait_event_interruptible_lock_irq(pipe_crc->wq,
-   pipe_crc_data_count(pipe_crc), pipe_crc->lock);
-   if (ret) {
-   spin_unlock_irq(_crc->lock);
-   

[Intel-gfx] [PATCH v11 0/4] New debugfs API for capturing CRC of frames

[Tomeu Vizoso]

Hi,

this series basically takes the facility for continuously capturing CRCs
of frames from the i915 driver and into the DRM core.

The idea is that test suites such as IGT use this information to check
that frames that are exected to be identical, also have identical CRC
values.

Other drivers for hardware that can provide frame CRCs (including eDP
panels that support self-refresh) can easily implement the new callback
and provide userspace with the CRC values.

Sorry about that, but there was a dangling brace in v10 breaking the build so
here is this v11.

Thanks,

Tomeu


Tomeu Vizoso (4):
  drm/i915/debugfs: Move out pipe CRC code
  drm: Add API for capturing frame CRCs
  drm/i915: Use new CRC debugfs API
  drm/i915: Put "cooked" vlank counters in frame CRC lines

 Documentation/gpu/drm-uapi.rst|6 +
 drivers/gpu/drm/Makefile  |3 +-
 drivers/gpu/drm/drm_crtc.c|   34 +-
 drivers/gpu/drm/drm_debugfs.c |   34 +-
 drivers/gpu/drm/drm_debugfs_crc.c |  351 
 drivers/gpu/drm/drm_internal.h|   16 +
 drivers/gpu/drm/i915/Makefile |2 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |  886 +---
 drivers/gpu/drm/i915/i915_drv.h   |1 +
 drivers/gpu/drm/i915/i915_irq.c   |   83 ++-
 drivers/gpu/drm/i915/intel_display.c  |1 +
 drivers/gpu/drm/i915/intel_drv.h  |   13 +
 drivers/gpu/drm/i915/intel_pipe_crc.c | 1013 +
 include/drm/drm_crtc.h|   41 ++
 include/drm/drm_debugfs_crc.h |   73 +++
 15 files changed, 1645 insertions(+), 912 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
 create mode 100644 drivers/gpu/drm/i915/intel_pipe_crc.c
 create mode 100644 include/drm/drm_debugfs_crc.h

-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 2/3] tools: intel_aubdump: pass configuration through file descriptor

[Lionel Landwerlin]

This makes parsing options less complicated and easier to extend.

Signed-off-by: Lionel Landwerlin 
---
 tools/aubdump.c| 32 ++--
 tools/intel_aubdump.in | 22 +++---
 2 files changed, 37 insertions(+), 17 deletions(-)

diff --git a/tools/aubdump.c b/tools/aubdump.c
index a2ac7f1..e82b514 100644
--- a/tools/aubdump.c
+++ b/tools/aubdump.c
@@ -430,26 +430,38 @@ static void
 maybe_init(void)
 {
static bool initialized = false;
-   const char *args = getenv("INTEL_AUBDUMP_ARGS");
+   FILE *config;
+   char *key, *value;
 
if (initialized)
return;
 
initialized = true;
 
-   if (sscanf(args, "verbose=%d;file=%m[^;];device=%i",
-  , , ) != 3)
-   filename = strdup("intel.aub");
-   fail_if(filename == NULL, "intel_aubdump: out of memory\n");
+   config = fdopen(3, "r");
+   while (fscanf(config, "%m[^=]=%m[^\n]\n", , ) != EOF) {
+   if (!strcmp(key, "verbose")) {
+   verbose = 1;
+   } else if (!strcmp(key, "device")) {
+   device = atoi(value);
+   device_override = true;
+   } else if (!strcmp(key, "file")) {
+   filename = value;
+   file = fopen(filename, "w+");
+   fail_if(file == NULL,
+   "intel_aubdump: failed to open file '%s'\n",
+   filename);
+   } else {
+   fprintf(stderr, "intel_aubdump: unknown option '%s'\n", 
key);
+   }
 
-   if (device)
-   device_override = true;
+   free(key);
+   free(value);
+   }
+   fclose(config);
 
bos = malloc(MAX_BO_COUNT * sizeof(bos[0]));
fail_if(bos == NULL, "intel_aubdump: out of memory\n");
-
-   file = fopen(filename, "w+");
-   fail_if(file == NULL, "intel_aubdump: failed to open file '%s'\n", 
filename);
 }
 
 int
diff --git a/tools/intel_aubdump.in b/tools/intel_aubdump.in
index feee23a..445b60f 100644
--- a/tools/intel_aubdump.in
+++ b/tools/intel_aubdump.in
@@ -21,29 +21,38 @@ EOF
 exit 0
 }
 
-verbose=0
-device=0
+args=""
+command=""
+file=""
+
+function add_arg() {
+arg=$1
+args="$args$arg\n"
+}
 
 while true; do
   case "$1" in
  -o)
  file=$2
+ add_arg "file=${f:-$(basename ${f}).aub}"
  shift 2
  ;;
  -v)
- verbose=1
+ add_arg "verbose=1"
  shift 1
  ;;
  -o*)
  file=${1##-o}
+ add_arg "file=${file:-$(basename ${file}).aub}"
  shift
  ;;
  --output=*)
  file=${1##--output=}
+ add_arg "file=${file:-$(basename ${file}).aub}"
  shift
  ;;
  --device=*)
- device=${1##--device=}
+ add_arg "device=${1##--device=}"
  shift
  ;;
  --help)
@@ -66,12 +75,11 @@ done
 
 [ -z $1 ] && show_help
 
-file=${file:-$(basename $1).aub}
+[ -z $file ] && add_arg "file=intel.aub"
 
 prefix=@prefix@
 exec_prefix=@exec_prefix@
 libdir=@libdir@
 
 LD_PRELOAD=${libdir}/intel_aubdump.so${LD_PPRELOAD:+:${LD_PRELOAD}} \
- INTEL_AUBDUMP_ARGS="verbose=$verbose;file=$file;device=$device" \
- exec -- "$@"
+ exec -- "$@" 3<<< `printf '%b' "$args"`
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 1/3] tools: intel_aubdump: avoid initializing multiple times

[Lionel Landwerlin]

For some reason init() seems to be called multiple times. Let's move the
initialization to the first ioctl().

Signed-off-by: Lionel Landwerlin 
---
 tools/aubdump.c | 44 
 1 file changed, 28 insertions(+), 16 deletions(-)

diff --git a/tools/aubdump.c b/tools/aubdump.c
index 30dc742..a2ac7f1 100644
--- a/tools/aubdump.c
+++ b/tools/aubdump.c
@@ -426,6 +426,32 @@ close(int fd)
return libc_close(fd);
 }
 
+static void
+maybe_init(void)
+{
+   static bool initialized = false;
+   const char *args = getenv("INTEL_AUBDUMP_ARGS");
+
+   if (initialized)
+   return;
+
+   initialized = true;
+
+   if (sscanf(args, "verbose=%d;file=%m[^;];device=%i",
+  , , ) != 3)
+   filename = strdup("intel.aub");
+   fail_if(filename == NULL, "intel_aubdump: out of memory\n");
+
+   if (device)
+   device_override = true;
+
+   bos = malloc(MAX_BO_COUNT * sizeof(bos[0]));
+   fail_if(bos == NULL, "intel_aubdump: out of memory\n");
+
+   file = fopen(filename, "w+");
+   fail_if(file == NULL, "intel_aubdump: failed to open file '%s'\n", 
filename);
+}
+
 int
 ioctl(int fd, unsigned long request, ...)
 {
@@ -447,6 +473,8 @@ ioctl(int fd, unsigned long request, ...)
}
 
if (fd == drm_fd) {
+   maybe_init();
+
switch (request) {
case DRM_IOCTL_I915_GETPARAM: {
struct drm_i915_getparam *getparam = argp;
@@ -550,26 +578,10 @@ ioctl(int fd, unsigned long request, ...)
 static void
 init(void)
 {
-   const char *args = getenv("INTEL_AUBDUMP_ARGS");
-
libc_close = dlsym(RTLD_NEXT, "close");
libc_ioctl = dlsym(RTLD_NEXT, "ioctl");
fail_if(libc_close == NULL || libc_ioctl == NULL,
"intel_aubdump: failed to get libc ioctl or close\n");
-
-   if (sscanf(args, "verbose=%d;file=%m[^;];device=%i",
-  , , ) != 3)
-   filename = strdup("intel.aub");
-   fail_if(filename == NULL, "intel_aubdump: out of memory\n");
-
-   if (device)
-   device_override = true;
-
-   bos = malloc(MAX_BO_COUNT * sizeof(bos[0]));
-   fail_if(bos == NULL, "intel_aubdump: out of memory\n");
-
-   file = fopen(filename, "w+");
-   fail_if(file == NULL, "intel_aubdump: failed to open file '%s'\n", 
filename);
 }
 
 static int
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4 i-g-t 3/3] aubdump: add --command option to stream aubdump to another program

[Lionel Landwerlin]

This comes handy if you want to look at your application output without
having to save it into a file. For example, use this with aubinator from
Mesa :

$ intel_aubdump -c '/path/to/aubinator --gen=hsw' my_gl_app

v2: Fix handling empty command line option

v3: Fix command line concatenation (again...)

v4: Use execvp (Petri)
Indentation (Petri)
Allow recording to a file and stream to an external application (Lionel)

Signed-off-by: Lionel Landwerlin 
Cc: Sirisha Gandikota 
---
 tools/aubdump.c| 81 --
 tools/intel_aubdump.in | 26 +++-
 2 files changed, 97 insertions(+), 10 deletions(-)

diff --git a/tools/aubdump.c b/tools/aubdump.c
index e82b514..61aa83c 100644
--- a/tools/aubdump.c
+++ b/tools/aubdump.c
@@ -43,6 +43,10 @@
 #include "intel_aub.h"
 #include "intel_chipset.h"

+#ifndef ARRAY_SIZE
+#define ARRAY_SIZE(x) (sizeof(x)/sizeof((x)[0]))
+#endif
+
 static int close_init_helper(int fd);
 static int ioctl_init_helper(int fd, unsigned long request, ...);

@@ -50,8 +54,8 @@ static int (*libc_close)(int fd) = close_init_helper;
 static int (*libc_ioctl)(int fd, unsigned long request, ...) = 
ioctl_init_helper;

 static int drm_fd = -1;
-static char *filename;
-static FILE *file;
+static char *filename = NULL;
+static FILE *files[2] = { NULL, NULL };
 static int gen = 0;
 static int verbose = 0;
 static const uint32_t gtt_size = 0x1;
@@ -140,13 +144,28 @@ align_u64(uint64_t v, uint64_t a)
 static void
 dword_out(uint32_t data)
 {
-   fwrite(, 1, 4, file);
+   for (int i = 0; i < ARRAY_SIZE (files); i++) {
+   if (files[i] == NULL)
+   continue;
+
+   fail_if(fwrite(, 1, 4, files[i]) == 0,
+   "Writing to output failed\n");
+   }
 }

 static void
 data_out(const void *data, size_t size)
 {
-   fwrite(data, 1, size, file);
+   if (size == 0)
+   return;
+
+   for (int i = 0; i < ARRAY_SIZE (files); i++) {
+   if (files[i] == NULL)
+   continue;
+
+   fail_if(fwrite(data, 1, size, files[i]) == 0,
+   "Writing to output failed\n");
+   }
 }

 static void
@@ -393,7 +412,10 @@ dump_execbuffer2(int fd, struct drm_i915_gem_execbuffer2 
*execbuffer2)
aub_dump_ringbuffer(batch_bo->offset + execbuffer2->batch_start_offset,
offset, ring_flag);

-   fflush(file);
+   for (int i = 0; i < ARRAY_SIZE(files); i++) {
+   if (files[i] != NULL)
+   fflush(files[i]);
+   }
 }

 static void
@@ -426,6 +448,40 @@ close(int fd)
return libc_close(fd);
 }

+static FILE *
+launch_command(char *command)
+{
+   int i = 0, fds[2];
+   char **args = calloc(strlen(command), sizeof(char *));
+   char *iter = command;
+
+   args[i++] = iter = command;
+
+   while ((iter = strstr(iter, ",")) != NULL) {
+   *iter = '\0';
+   iter += 1;
+   args[i++] = iter;
+   }
+
+   if (pipe(fds) == -1)
+   return NULL;
+
+   switch (fork()) {
+   case 0:
+   dup2(fds[0], 0);
+   fail_if(execvp(args[0], args) == -1,
+   "intel_aubdump: failed to launch child command\n");
+   return NULL;
+
+   default:
+   free(args);
+   return fdopen(fds[1], "w");
+
+   case -1:
+   return NULL;
+   }
+}
+
 static void
 maybe_init(void)
 {
@@ -447,10 +503,15 @@ maybe_init(void)
device_override = true;
} else if (!strcmp(key, "file")) {
filename = value;
-   file = fopen(filename, "w+");
-   fail_if(file == NULL,
+   files[0] = fopen(filename, "w+");
+   fail_if(files[0] == NULL,
"intel_aubdump: failed to open file '%s'\n",
filename);
+   } else if (!strcmp(key,  "command")) {
+   files[1] = launch_command(value);
+   fail_if(files[1] == NULL,
+   "intel_aubdump: failed to launch command 
'%s'\n",
+   value);
} else {
fprintf(stderr, "intel_aubdump: unknown option '%s'\n", 
key);
}
@@ -621,7 +682,9 @@ static void __attribute__ ((destructor))
 fini(void)
 {
free(filename);
-   if (file)
-   fclose(file);
+   for (int i = 0; i < ARRAY_SIZE(files); i++) {
+   if (files[i] != NULL)
+   fclose(files[i]);
+   }
free(bos);
 }
diff --git a/tools/intel_aubdump.in b/tools/intel_aubdump.in
index 445b60f..a8e96d6 100644
--- a/tools/intel_aubdump.in
+++ 

[Intel-gfx] [PATCH v10 4/4] drm/i915: Put "cooked" vlank counters in frame CRC lines

[Tomeu Vizoso]

Use drm_accurate_vblank_count so we have the full 32 bit to represent
the frame counter and userspace has a simpler way of knowing when the
counter wraps around.

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Emil Velikov 
---

 drivers/gpu/drm/i915/i915_irq.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1549cc4f88ec..238a353454e9 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1495,7 +1495,6 @@ static void display_pipe_crc_irq_handler(struct 
drm_i915_private *dev_priv,
struct drm_driver *driver = dev_priv->drm.driver;
uint32_t crcs[5];
int head, tail, ret;
-   u32 frame;
 
spin_lock(_crc->lock);
if (pipe_crc->source) {
@@ -1551,8 +1550,9 @@ static void display_pipe_crc_irq_handler(struct 
drm_i915_private *dev_priv,
crcs[2] = crc2;
crcs[3] = crc3;
crcs[4] = crc4;
-   frame = driver->get_vblank_counter(_priv->drm, pipe);
-   ret = drm_crtc_add_crc_entry(crtc, true, frame, crcs);
+   ret = drm_crtc_add_crc_entry(crtc, true,
+drm_accurate_vblank_count(crtc),
+crcs);
spin_unlock(>crc.lock);
if (!ret)
wake_up_interruptible(>crc.wq);
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v10 1/4] drm/i915/debugfs: Move out pipe CRC code

[Tomeu Vizoso]

In preparation to using a generic API in the DRM core for continuous CRC
generation, move the related code out of i915_debugfs.c into a new file.

Eventually, only the Intel-specific code will remain in this new file.

v2: Rebased.

v6: Rebased.

v7: Fix whitespace issue.

v9: Have intel_display_crc_init accept a drm_i915_private instead.

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Emil Velikov 
---

 drivers/gpu/drm/i915/Makefile |   2 +-
 drivers/gpu/drm/i915/i915_debugfs.c   | 886 +---
 drivers/gpu/drm/i915/intel_drv.h  |   5 +
 drivers/gpu/drm/i915/intel_pipe_crc.c | 943 ++
 4 files changed, 953 insertions(+), 883 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_pipe_crc.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a998c2bce70a..e6fe0040fe64 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -24,7 +24,7 @@ i915-y := i915_drv.o \
  intel_runtime_pm.o
 
 i915-$(CONFIG_COMPAT)   += i915_ioc32.o
-i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o
+i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o intel_pipe_crc.o
 
 # GEM code
 i915-y += i915_cmd_parser.o \
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index da7141382b00..4fb9d829884e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -26,19 +26,9 @@
  *
  */
 
-#include 
-#include 
-#include 
 #include 
-#include 
-#include 
 #include 
-#include 
-#include 
 #include "intel_drv.h"
-#include "intel_ringbuffer.h"
-#include 
-#include "i915_drv.h"
 
 static inline struct drm_i915_private *node_to_i915(struct drm_info_node *node)
 {
@@ -3414,12 +3404,6 @@ static int i915_drrs_status(struct seq_file *m, void 
*unused)
return 0;
 }
 
-struct pipe_crc_info {
-   const char *name;
-   struct drm_i915_private *dev_priv;
-   enum pipe pipe;
-};
-
 static int i915_dp_mst_info(struct seq_file *m, void *unused)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -3449,848 +3433,6 @@ static int i915_dp_mst_info(struct seq_file *m, void 
*unused)
return 0;
 }
 
-static int i915_pipe_crc_open(struct inode *inode, struct file *filep)
-{
-   struct pipe_crc_info *info = inode->i_private;
-   struct drm_i915_private *dev_priv = info->dev_priv;
-   struct intel_pipe_crc *pipe_crc = _priv->pipe_crc[info->pipe];
-
-   if (info->pipe >= INTEL_INFO(dev_priv)->num_pipes)
-   return -ENODEV;
-
-   spin_lock_irq(_crc->lock);
-
-   if (pipe_crc->opened) {
-   spin_unlock_irq(_crc->lock);
-   return -EBUSY; /* already open */
-   }
-
-   pipe_crc->opened = true;
-   filep->private_data = inode->i_private;
-
-   spin_unlock_irq(_crc->lock);
-
-   return 0;
-}
-
-static int i915_pipe_crc_release(struct inode *inode, struct file *filep)
-{
-   struct pipe_crc_info *info = inode->i_private;
-   struct drm_i915_private *dev_priv = info->dev_priv;
-   struct intel_pipe_crc *pipe_crc = _priv->pipe_crc[info->pipe];
-
-   spin_lock_irq(_crc->lock);
-   pipe_crc->opened = false;
-   spin_unlock_irq(_crc->lock);
-
-   return 0;
-}
-
-/* (6 fields, 8 chars each, space separated (5) + '\n') */
-#define PIPE_CRC_LINE_LEN  (6 * 8 + 5 + 1)
-/* account for \'0' */
-#define PIPE_CRC_BUFFER_LEN(PIPE_CRC_LINE_LEN + 1)
-
-static int pipe_crc_data_count(struct intel_pipe_crc *pipe_crc)
-{
-   assert_spin_locked(_crc->lock);
-   return CIRC_CNT(pipe_crc->head, pipe_crc->tail,
-   INTEL_PIPE_CRC_ENTRIES_NR);
-}
-
-static ssize_t
-i915_pipe_crc_read(struct file *filep, char __user *user_buf, size_t count,
-  loff_t *pos)
-{
-   struct pipe_crc_info *info = filep->private_data;
-   struct drm_i915_private *dev_priv = info->dev_priv;
-   struct intel_pipe_crc *pipe_crc = _priv->pipe_crc[info->pipe];
-   char buf[PIPE_CRC_BUFFER_LEN];
-   int n_entries;
-   ssize_t bytes_read;
-
-   /*
-* Don't allow user space to provide buffers not big enough to hold
-* a line of data.
-*/
-   if (count < PIPE_CRC_LINE_LEN)
-   return -EINVAL;
-
-   if (pipe_crc->source == INTEL_PIPE_CRC_SOURCE_NONE)
-   return 0;
-
-   /* nothing to read */
-   spin_lock_irq(_crc->lock);
-   while (pipe_crc_data_count(pipe_crc) == 0) {
-   int ret;
-
-   if (filep->f_flags & O_NONBLOCK) {
-   spin_unlock_irq(_crc->lock);
-   return -EAGAIN;
-   }
-
-   ret = wait_event_interruptible_lock_irq(pipe_crc->wq,
-   pipe_crc_data_count(pipe_crc), pipe_crc->lock);
-   if (ret) {
-   spin_unlock_irq(_crc->lock);
-   

[Intel-gfx] [PATCH v10 3/4] drm/i915: Use new CRC debugfs API

[Tomeu Vizoso]

The core provides now an ABI to userspace for generation of frame CRCs,
so implement the ->set_crc_source() callback and reuse as much code as
possible with the previous ABI implementation.

When handling the pageflip interrupt, we skip 1 or 2 frames depending on
the HW because they contain wrong values. For the legacy ABI for
generating frame CRCs, this was done in userspace but now that we have a
generic ABI it's better if it's not exposed by the kernel.

v2:
- Leave the legacy implementation in place as the ABI implementation
  in the core is incompatible with it.
v3:
- Use the "cooked" vblank counter so we have a whole 32 bits.
- Make sure we don't mess with the state of the legacy CRC capture
  ABI implementation.
v4:
- Keep use of get_vblank_counter as in the legacy code, will be
  changed in a followup commit.

v5:
- Skip first frame or two as it's known that they contain wrong
  data.
- A few fixes suggested by Emil Velikov.

v6:
- Rework programming of the HW registers to preserve previous
  behavior.

v7:
- Address whitespace issue.
- Added a comment on why in the implementation of the new ABI we
  skip the 1st or 2nd frames.

v9:
- Add stub for intel_crtc_set_crc_source.

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Emil Velikov 
---

 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/i915_irq.c   | 83 +--
 drivers/gpu/drm/i915/intel_display.c  |  1 +
 drivers/gpu/drm/i915/intel_drv.h  |  8 +++
 drivers/gpu/drm/i915/intel_pipe_crc.c | 94 ++-
 5 files changed, 149 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f8c66eea06bc..20522f0a4c57 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1713,6 +1713,7 @@ struct intel_pipe_crc {
enum intel_pipe_crc_source source;
int head, tail;
wait_queue_head_t wq;
+   int skipped;
 };
 
 struct i915_frontbuffer_tracking {
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bd6c8b0eeaef..1549cc4f88ec 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1491,41 +1491,72 @@ static void display_pipe_crc_irq_handler(struct 
drm_i915_private *dev_priv,
 {
struct intel_pipe_crc *pipe_crc = _priv->pipe_crc[pipe];
struct intel_pipe_crc_entry *entry;
-   int head, tail;
+   struct drm_crtc *crtc = intel_get_crtc_for_pipe(_priv->drm, pipe);
+   struct drm_driver *driver = dev_priv->drm.driver;
+   uint32_t crcs[5];
+   int head, tail, ret;
+   u32 frame;
 
spin_lock(_crc->lock);
+   if (pipe_crc->source) {
+   if (!pipe_crc->entries) {
+   spin_unlock(_crc->lock);
+   DRM_DEBUG_KMS("spurious interrupt\n");
+   return;
+   }
 
-   if (!pipe_crc->entries) {
-   spin_unlock(_crc->lock);
-   DRM_DEBUG_KMS("spurious interrupt\n");
-   return;
-   }
-
-   head = pipe_crc->head;
-   tail = pipe_crc->tail;
+   head = pipe_crc->head;
+   tail = pipe_crc->tail;
 
-   if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
-   spin_unlock(_crc->lock);
-   DRM_ERROR("CRC buffer overflowing\n");
-   return;
-   }
+   if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
+   spin_unlock(_crc->lock);
+   DRM_ERROR("CRC buffer overflowing\n");
+   return;
+   }
 
-   entry = _crc->entries[head];
+   entry = _crc->entries[head];
 
-   entry->frame = dev_priv->drm.driver->get_vblank_counter(_priv->drm,
-pipe);
-   entry->crc[0] = crc0;
-   entry->crc[1] = crc1;
-   entry->crc[2] = crc2;
-   entry->crc[3] = crc3;
-   entry->crc[4] = crc4;
+   entry->frame = driver->get_vblank_counter(_priv->drm, pipe);
+   entry->crc[0] = crc0;
+   entry->crc[1] = crc1;
+   entry->crc[2] = crc2;
+   entry->crc[3] = crc3;
+   entry->crc[4] = crc4;
 
-   head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
-   pipe_crc->head = head;
+   head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
+   pipe_crc->head = head;
 
-   spin_unlock(_crc->lock);
+   spin_unlock(_crc->lock);
 
-   wake_up_interruptible(_crc->wq);
+   wake_up_interruptible(_crc->wq);
+   } else {
+   /*
+* For some not yet identified reason, the first CRC is
+* bonkers. So let's just wait for the next vblank and read
+   

[Intel-gfx] [PATCH v10 0/4] New debugfs API for capturing CRC of frames

[Tomeu Vizoso]

Hi,

this series basically takes the facility for continuously capturing CRCs
of frames from the i915 driver and into the DRM core.

The idea is that test suites such as IGT use this information to check
that frames that are exected to be identical, also have identical CRC
values.

Other drivers for hardware that can provide frame CRCs (including eDP
panels that support self-refresh) can easily implement the new callback
and provide userspace with the CRC values.

In this v10 debugfs creation failures don't abort CRTC registration, as
suggested by Emil Velikov.

Thanks,

Tomeu


Tomeu Vizoso (4):
  drm/i915/debugfs: Move out pipe CRC code
  drm: Add API for capturing frame CRCs
  drm/i915: Use new CRC debugfs API
  drm/i915: Put "cooked" vlank counters in frame CRC lines

 Documentation/gpu/drm-uapi.rst|6 +
 drivers/gpu/drm/Makefile  |3 +-
 drivers/gpu/drm/drm_crtc.c|   34 +-
 drivers/gpu/drm/drm_debugfs.c |   34 +-
 drivers/gpu/drm/drm_debugfs_crc.c |  351 
 drivers/gpu/drm/drm_internal.h|   16 +
 drivers/gpu/drm/i915/Makefile |2 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |  886 +---
 drivers/gpu/drm/i915/i915_drv.h   |1 +
 drivers/gpu/drm/i915/i915_irq.c   |   83 ++-
 drivers/gpu/drm/i915/intel_display.c  |1 +
 drivers/gpu/drm/i915/intel_drv.h  |   13 +
 drivers/gpu/drm/i915/intel_pipe_crc.c | 1013 +
 include/drm/drm_crtc.h|   41 ++
 include/drm/drm_debugfs_crc.h |   73 +++
 15 files changed, 1645 insertions(+), 912 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
 create mode 100644 drivers/gpu/drm/i915/intel_pipe_crc.c
 create mode 100644 include/drm/drm_debugfs_crc.h

-- 
2.7.4

___
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/guc: Unwind GuC workqueue reservation if request construction fails

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Unwind GuC workqueue reservation if request construction 
fails
URL   : https://patchwork.freedesktop.org/series/13390/
State : success

== Summary ==

Series 13390v1 drm/i915/guc: Unwind GuC workqueue reservation if request 
construction fails
https://patchwork.freedesktop.org/api/1.0/series/13390/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-byt-j1900)

fi-bdw-5557u total:248  pass:231  dwarn:0   dfail:0   fail:0   skip:17 
fi-bsw-n3050 total:248  pass:204  dwarn:0   dfail:0   fail:0   skip:44 
fi-bxt-t5700 total:248  pass:217  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-j1900 total:248  pass:214  dwarn:1   dfail:0   fail:1   skip:32 
fi-byt-n2820 total:248  pass:210  dwarn:0   dfail:0   fail:1   skip:37 
fi-hsw-4770  total:248  pass:224  dwarn:0   dfail:0   fail:0   skip:24 
fi-hsw-4770r total:248  pass:224  dwarn:0   dfail:0   fail:0   skip:24 
fi-ilk-650   total:248  pass:185  dwarn:0   dfail:0   fail:2   skip:61 
fi-ivb-3520m total:248  pass:221  dwarn:0   dfail:0   fail:0   skip:27 
fi-ivb-3770  total:248  pass:207  dwarn:0   dfail:0   fail:0   skip:41 
fi-kbl-7200u total:248  pass:222  dwarn:0   dfail:0   fail:0   skip:26 
fi-skl-6260u total:248  pass:232  dwarn:0   dfail:0   fail:0   skip:16 
fi-skl-6700hqtotal:248  pass:224  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6700k total:248  pass:221  dwarn:1   dfail:0   fail:0   skip:26 
fi-skl-6770hqtotal:248  pass:231  dwarn:1   dfail:0   fail:1   skip:15 
fi-snb-2520m total:248  pass:211  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:248  pass:209  dwarn:0   dfail:0   fail:0   skip:39 

Results at /archive/results/CI_IGT_test/Patchwork_2639/

2dff18acaa95a26b882a5f9910d7ded514f18415 drm-intel-nightly: 
2016y-10m-05d-13h-58m-08s UTC integration manifest
bc63ebe drm/i915/guc: Unwind GuC workqueue reservation if request construction 
fails

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Reset the breadcrumbs IRQ more carefully

[Chris Wilson]

On Thu, Oct 06, 2016 at 05:02:44PM +0300, Mika Kuoppala wrote:
> Chris Wilson  writes:
> 
> > On Thu, Oct 06, 2016 at 04:32:37PM +0300, Mika Kuoppala wrote:
> >> Chris Wilson  writes:
> >> 
> >> > Along with the interrupt, we want to restore the fake-irq and
> >> > wait-timeout detection. If we use the breadcrumbs interface to setup the
> >> > interrupt as it wants, the auxiliary timers will also be restored.
> >> >
> >> > Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete 
> >> > requests")
> >> > Signed-off-by: Chris Wilson 
> >> > Cc: Mika Kuoppala 
> >> > ---
> >> >  drivers/gpu/drm/i915/intel_breadcrumbs.c | 17 +
> >> >  drivers/gpu/drm/i915/intel_engine_cs.c   | 15 ---
> >> >  drivers/gpu/drm/i915/intel_lrc.c |  2 +-
> >> >  drivers/gpu/drm/i915/intel_ringbuffer.c  |  2 +-
> >> >  drivers/gpu/drm/i915/intel_ringbuffer.h  |  2 +-
> >> >  5 files changed, 20 insertions(+), 18 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
> >> > b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >> > index 9dba4971fb1e..d27da6d69735 100644
> >> > --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >> > +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >> > @@ -584,6 +584,23 @@ int intel_engine_init_breadcrumbs(struct 
> >> > intel_engine_cs *engine)
> >> >  return 0;
> >> >  }
> >> >  
> >> > +void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine)
> >> > +{
> >> > +struct intel_breadcrumbs *b = >breadcrumbs;
> >> > +
> >> 
> >> Should we kill the timer before proceeding in here?
> >
> > Which timer? In breadcrumbs.c, we are concerned with the fake_irq and
> > the wait-timeout. The wait-timeout is reset below, we should add the
> > code to cancel the fake_irq along with clearing the bit.
> 
> I was considering that irqs are enabled and we have a
> active breadcrumbs timer, triggering at the same time as
> reset happens. So we would enable the fake irq as a post reset
> race between reset/breadcrumbs hangcheck.
> 
> As in why not cancel and postpone the timer and only after
> clear the missed_irq?

So just picking up that we don't cancel the fake irq along with the
clear_bit() (currently justing for the wait to complete before
cancelling).

> >> Not relevant to this patch but I also noticed that the period
> >> is identical to hangcheck period. Multiple of hangcheck period
> >> would be better, as our kicking might help and we don't
> >> want to fallback to fake irqs just so easily.
> >
> > ?
> >
> > The main GPU hangcheck is kicked off by the wait timeout. Keeping the
> > two pieces independent (fake-irq, hangcheck) is quite nice, and the
> > jiffie wake up serves as a backup, and either it is required or it will
> > be disabled by the reset.
> 
> But we queue hangcheck also from retire work. So it could be that
> we fallback to fake irqs, even if next hangcheck might have
> managed to kick the wait and make forward progress?

Below the level of care. The limited kicking that hangcheck does is
immaterial to deciding whether or not we might need fake user interrupts.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/guc: Unwind GuC workqueue reservation if request construction fails

[Michał Winiarski]

On Thu, Oct 06, 2016 at 02:34:46PM +0100, Chris Wilson wrote:
> We reserve space in the GuC workqueue for submitting the request in the
> future. However, if we fail to construct the request, we need to give
> that reserved space back to the system.
> 
> Fixes: dadd481bfe55 ("drm/i915/guc: Prepare for nonblocking execbuf 
> submission")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97978
> Signed-off-by: Chris Wilson 
> Cc: Michał Winiarski 

Reviewed-by: Michał Winiarski 

-Michał
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Reset the breadcrumbs IRQ more carefully

[Mika Kuoppala]

Chris Wilson  writes:

> On Thu, Oct 06, 2016 at 04:32:37PM +0300, Mika Kuoppala wrote:
>> Chris Wilson  writes:
>> 
>> > Along with the interrupt, we want to restore the fake-irq and
>> > wait-timeout detection. If we use the breadcrumbs interface to setup the
>> > interrupt as it wants, the auxiliary timers will also be restored.
>> >
>> > Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete 
>> > requests")
>> > Signed-off-by: Chris Wilson 
>> > Cc: Mika Kuoppala 
>> > ---
>> >  drivers/gpu/drm/i915/intel_breadcrumbs.c | 17 +
>> >  drivers/gpu/drm/i915/intel_engine_cs.c   | 15 ---
>> >  drivers/gpu/drm/i915/intel_lrc.c |  2 +-
>> >  drivers/gpu/drm/i915/intel_ringbuffer.c  |  2 +-
>> >  drivers/gpu/drm/i915/intel_ringbuffer.h  |  2 +-
>> >  5 files changed, 20 insertions(+), 18 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
>> > b/drivers/gpu/drm/i915/intel_breadcrumbs.c
>> > index 9dba4971fb1e..d27da6d69735 100644
>> > --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
>> > +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
>> > @@ -584,6 +584,23 @@ int intel_engine_init_breadcrumbs(struct 
>> > intel_engine_cs *engine)
>> >return 0;
>> >  }
>> >  
>> > +void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine)
>> > +{
>> > +  struct intel_breadcrumbs *b = >breadcrumbs;
>> > +
>> 
>> Should we kill the timer before proceeding in here?
>
> Which timer? In breadcrumbs.c, we are concerned with the fake_irq and
> the wait-timeout. The wait-timeout is reset below, we should add the
> code to cancel the fake_irq along with clearing the bit.

I was considering that irqs are enabled and we have a
active breadcrumbs timer, triggering at the same time as
reset happens. So we would enable the fake irq as a post reset
race between reset/breadcrumbs hangcheck.

As in why not cancel and postpone the timer and only after
clear the missed_irq?

>  
>> Not relevant to this patch but I also noticed that the period
>> is identical to hangcheck period. Multiple of hangcheck period
>> would be better, as our kicking might help and we don't
>> want to fallback to fake irqs just so easily.
>
> ?
>
> The main GPU hangcheck is kicked off by the wait timeout. Keeping the
> two pieces independent (fake-irq, hangcheck) is quite nice, and the
> jiffie wake up serves as a backup, and either it is required or it will
> be disabled by the reset.

But we queue hangcheck also from retire work. So it could be that
we fallback to fake irqs, even if next hangcheck might have
managed to kick the wait and make forward progress?

And perhaps we should rename the breadcrumb hangcheck
as wait_watchdog to avoid confusion between different independant
'hangchecks'

-Mika

> -Chris
>
> -- 
> Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/guc: Delay GuC workqueue reservation

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Delay GuC workqueue reservation
URL   : https://patchwork.freedesktop.org/series/13388/
State : warning

== Summary ==

Series 13388v1 drm/i915/guc: Delay GuC workqueue reservation
https://patchwork.freedesktop.org/api/1.0/series/13388/revisions/1/mbox/

Test drv_module_reload_basic:
pass   -> SKIP   (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (fi-skl-6700k)
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-byt-j1900)

fi-bdw-5557u total:248  pass:231  dwarn:0   dfail:0   fail:0   skip:17 
fi-bsw-n3050 total:248  pass:205  dwarn:0   dfail:0   fail:0   skip:43 
fi-bxt-t5700 total:248  pass:217  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-j1900 total:248  pass:214  dwarn:1   dfail:0   fail:1   skip:32 
fi-byt-n2820 total:248  pass:211  dwarn:0   dfail:0   fail:1   skip:36 
fi-hsw-4770  total:248  pass:224  dwarn:0   dfail:0   fail:0   skip:24 
fi-hsw-4770r total:248  pass:224  dwarn:0   dfail:0   fail:0   skip:24 
fi-ilk-650   total:248  pass:184  dwarn:0   dfail:0   fail:2   skip:62 
fi-ivb-3520m total:248  pass:221  dwarn:0   dfail:0   fail:0   skip:27 
fi-ivb-3770  total:248  pass:207  dwarn:0   dfail:0   fail:0   skip:41 
fi-skl-6260u total:248  pass:232  dwarn:0   dfail:0   fail:0   skip:16 
fi-skl-6700hqtotal:248  pass:224  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6700k total:248  pass:221  dwarn:2   dfail:0   fail:0   skip:25 
fi-skl-6770hqtotal:248  pass:230  dwarn:1   dfail:0   fail:1   skip:16 
fi-snb-2520m total:248  pass:211  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:248  pass:209  dwarn:0   dfail:0   fail:0   skip:39 

Results at /archive/results/CI_IGT_test/Patchwork_2638/

2dff18acaa95a26b882a5f9910d7ded514f18415 drm-intel-nightly: 
2016y-10m-05d-13h-58m-08s UTC integration manifest
20986b2 drm/i915/guc: Delay GuC workqueue reservation

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Reset the breadcrumbs IRQ more carefully

[Chris Wilson]

On Thu, Oct 06, 2016 at 04:32:37PM +0300, Mika Kuoppala wrote:
> Chris Wilson  writes:
> 
> > Along with the interrupt, we want to restore the fake-irq and
> > wait-timeout detection. If we use the breadcrumbs interface to setup the
> > interrupt as it wants, the auxiliary timers will also be restored.
> >
> > Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete 
> > requests")
> > Signed-off-by: Chris Wilson 
> > Cc: Mika Kuoppala 
> > ---
> >  drivers/gpu/drm/i915/intel_breadcrumbs.c | 17 +
> >  drivers/gpu/drm/i915/intel_engine_cs.c   | 15 ---
> >  drivers/gpu/drm/i915/intel_lrc.c |  2 +-
> >  drivers/gpu/drm/i915/intel_ringbuffer.c  |  2 +-
> >  drivers/gpu/drm/i915/intel_ringbuffer.h  |  2 +-
> >  5 files changed, 20 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
> > b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> > index 9dba4971fb1e..d27da6d69735 100644
> > --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
> > +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> > @@ -584,6 +584,23 @@ int intel_engine_init_breadcrumbs(struct 
> > intel_engine_cs *engine)
> > return 0;
> >  }
> >  
> > +void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine)
> > +{
> > +   struct intel_breadcrumbs *b = >breadcrumbs;
> > +
> 
> Should we kill the timer before proceeding in here?

Which timer? In breadcrumbs.c, we are concerned with the fake_irq and
the wait-timeout. The wait-timeout is reset below, we should add the
code to cancel the fake_irq along with clearing the bit.
 
> Not relevant to this patch but I also noticed that the period
> is identical to hangcheck period. Multiple of hangcheck period
> would be better, as our kicking might help and we don't
> want to fallback to fake irqs just so easily.

?

The main GPU hangcheck is kicked off by the wait timeout. Keeping the
two pieces independent (fake-irq, hangcheck) is quite nice, and the
jiffie wake up serves as a backup, and either it is required or it will
be disabled by the reset.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests/drv_module_reload_basic: Leave basic breadcrumbs in dmesg

[Ville Syrjälä]

On Thu, Oct 06, 2016 at 03:37:50PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 06, 2016 at 03:17:45PM +0300, Jani Nikula wrote:
> > On Thu, 06 Oct 2016, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä 
> > >
> > > Leave the normal "executing" and "exiting" breadcrumbs into dmesg when
> > > running the test.
> > >
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  tests/drv_module_reload_basic | 27 +++
> > >  1 file changed, 27 insertions(+)
> > >
> > > diff --git a/tests/drv_module_reload_basic b/tests/drv_module_reload_basic
> > > index 93cf7c005638..4c75f0e9614a 100755
> > > --- a/tests/drv_module_reload_basic
> > > +++ b/tests/drv_module_reload_basic
> > > @@ -6,6 +6,33 @@
> > >  #
> > >  
> > >  SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
> > > +
> > > +NAME=$(basename "$0")
> > > +
> > > +KERN_EMER="<0>"
> > > +KERN_ALERT="<1>"
> > > +KERN_CRIT="<2>"
> > > +KERN_ERR="<3>"
> > > +KERN_WARNING="<4>"
> > > +KERN_NOTICE="<5>"
> > > +KERN_INFO="<6>"
> > > +KERN_DEBUG="<7>"
> > > +
> > > +function kmsg()
> > > +{
> > > + echo "$1" > /dev/kmsg
> > > +}
> > > +
> > 
> > Seems like these would belong in drm_lib.sh. Or do you really need to do
> > the kmsg *before* sourcing drm_lib.sh?
> 
> drm_lib.sh can itself exit, so the trap needs to be done before sourcing
> it. And drm_lib.sh isn't a bash script, so I didn't dare to put it
> there.

Actuall it's a bash script, and I guess trap isn't even a bashism. Not
sure why I have that idea. Anyway, new series posted with all the magic
happening in drm_lib.sh \o/

> 
> > 
> > BR,
> > Jani.
> > 
> > > +function finish()
> > > +{
> > > + exitcode=$?
> > > + kmsg "$KERN_INFO$NAME: exiting, ret=$exitcode"
> > > + exit $exitcode
> > > +}
> > > +trap finish EXIT
> > > +
> > > +kmsg "$KERN_INFO$NAME: executing"
> > > +
> > >  . $SOURCE_DIR/drm_lib.sh
> > >  
> > >  # no other drm service should be running, so we can just unbind
> > 
> > -- 
> > Jani Nikula, Intel Open Source Technology Center
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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 i-g-t 3/5] tests/vgem_reload_basic: Leave breadcrumbs in dmesg

[ville . syrjala]

From: Ville Syrjälä 

Source drm_lib.sh instead of drm_getopt.sh so that we get the
"executing", and "exiting" breadcrumbs in dmesg.

Signed-off-by: Ville Syrjälä 
---
 tests/vgem_reload_basic | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/vgem_reload_basic b/tests/vgem_reload_basic
index e47af2f54951..46088fc34ee6 100755
--- a/tests/vgem_reload_basic
+++ b/tests/vgem_reload_basic
@@ -6,7 +6,7 @@
 #
 
 SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
-. $SOURCE_DIR/drm_getopt.sh
+. $SOURCE_DIR/drm_lib.sh
 
 function unload() {
/sbin/rmmod vgem
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 4/5] tests/tools_test: Fix it up for intel_reg

[ville . syrjala]

From: Ville Syrjälä 

intel_reg_read and intel_reg_dumper are no more. Switch over to intel_reg.

Signed-off-by: Ville Syrjälä 
---
 tests/tools_test | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/tools_test b/tests/tools_test
index 04878274e135..a27fb873b029 100755
--- a/tests/tools_test
+++ b/tests/tools_test
@@ -7,8 +7,8 @@ SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
 
 # ARB_MODE has existed for many gens
 PATH=$SOURCE_DIR/../tools:$PATH
-do_or_die "intel_reg_read 0x4030"
-do_or_die "intel_reg_dumper"
+do_or_die "intel_reg read 0x4030"
+do_or_die "intel_reg dump"
 
 # TODO: Add more tests
 
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 5/5] tools/intel_reg: Return SUCCESS after a succesful dump

[ville . syrjala]

From: Ville Syrjälä 

No reason why 'intel_reg dump' can't declare success after a succesful
dumping. Spotted after fixing tools_test to use the right tool :)

Signed-off-by: Ville Syrjälä 
---
 tools/intel_reg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/intel_reg.c b/tools/intel_reg.c
index 98dea0faa0e0..01a3671e97dd 100644
--- a/tools/intel_reg.c
+++ b/tools/intel_reg.c
@@ -491,7 +491,7 @@ static int intel_reg_dump(struct config *config, int argc, 
char *argv[])
 
intel_register_access_fini();
 
-   return EXIT_FAILURE;
+   return EXIT_SUCCESS;
 }
 
 static int intel_reg_snapshot(struct config *config, int argc, char *argv[])
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 2/5] tests: Leave basic breadcrumbs in dmesg for shell script based tests

[ville . syrjala]

From: Ville Syrjälä 

Leave the normal "executing" and "exiting" breadcrumbs into dmesg when
running the test.

Signed-off-by: Ville Syrjälä 
---
 tests/drm_lib.sh | 24 
 1 file changed, 24 insertions(+)

diff --git a/tests/drm_lib.sh b/tests/drm_lib.sh
index 0eeab1c183c9..456040e1971f 100755
--- a/tests/drm_lib.sh
+++ b/tests/drm_lib.sh
@@ -3,6 +3,30 @@
 SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
 . $SOURCE_DIR/drm_getopt.sh
 
+NAME=$(basename "$0")
+
+KERN_EMER="<0>"
+KERN_ALERT="<1>"
+KERN_CRIT="<2>"
+KERN_ERR="<3>"
+KERN_WARNING="<4>"
+KERN_NOTICE="<5>"
+KERN_INFO="<6>"
+KERN_DEBUG="<7>"
+
+kmsg() {
+   echo "$1" > /dev/kmsg
+}
+
+finish() {
+   exitcode=$?
+   kmsg "$KERN_INFO$NAME: exiting, ret=$exitcode"
+   exit $exitcode
+}
+trap finish EXIT
+
+kmsg "$KERN_INFO$NAME: executing"
+
 skip() {
echo "$@"
exit $IGT_EXIT_SKIP
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 1/5] tests: Use bash for debugfs_wedged and drm_lib.sh

[ville . syrjala]

From: Ville Syrjälä 

debugfs_wedged and drm_lib.sh are already using bashism so switch over
to using #!/bin/bash instead of #!/bin/sh.

Signed-off-by: Ville Syrjälä 
---
 tests/debugfs_wedged | 2 +-
 tests/drm_lib.sh | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/debugfs_wedged b/tests/debugfs_wedged
index 903a0a20060a..f15ac4614845 100755
--- a/tests/debugfs_wedged
+++ b/tests/debugfs_wedged
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
 
 SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
 . $SOURCE_DIR/drm_lib.sh
diff --git a/tests/drm_lib.sh b/tests/drm_lib.sh
index c32bc68dc6a8..0eeab1c183c9 100755
--- a/tests/drm_lib.sh
+++ b/tests/drm_lib.sh
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
 
 SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
 . $SOURCE_DIR/drm_getopt.sh
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/guc: Unwind GuC workqueue reservation if request construction fails

[Chris Wilson]

We reserve space in the GuC workqueue for submitting the request in the
future. However, if we fail to construct the request, we need to give
that reserved space back to the system.

Fixes: dadd481bfe55 ("drm/i915/guc: Prepare for nonblocking execbuf submission")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97978
Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_guc_submission.c |  9 +
 drivers/gpu/drm/i915/intel_guc.h   |  1 +
 drivers/gpu/drm/i915/intel_lrc.c   | 17 ++---
 3 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index ec785f4dfd34..750f85cdb863 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -451,6 +451,15 @@ int i915_guc_wq_reserve(struct drm_i915_gem_request 
*request)
return ret;
 }
 
+void i915_guc_wq_unreserve(struct drm_i915_gem_request *request)
+{
+   struct i915_guc_client *gc = request->i915->guc.execbuf_client;
+
+   spin_lock(>wq_lock);
+   gc->wq_rsvd -= sizeof(struct guc_wq_item);
+   spin_unlock(>wq_lock);
+}
+
 /* Construct a Work Item and append it to the GuC's Work Queue */
 static void guc_wq_item_append(struct i915_guc_client *gc,
   struct drm_i915_gem_request *rq)
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index b1ba86958811..5cdf7aa75be5 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -160,6 +160,7 @@ extern int intel_guc_resume(struct drm_device *dev);
 int i915_guc_submission_init(struct drm_i915_private *dev_priv);
 int i915_guc_submission_enable(struct drm_i915_private *dev_priv);
 int i915_guc_wq_reserve(struct drm_i915_gem_request *rq);
+void i915_guc_wq_unreserve(struct drm_i915_gem_request *request);
 void i915_guc_submission_disable(struct drm_i915_private *dev_priv);
 void i915_guc_submission_fini(struct drm_i915_private *dev_priv);
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index eb162553cff2..ce2ae0ecf88d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -635,6 +635,10 @@ int intel_logical_ring_alloc_request_extras(struct 
drm_i915_gem_request *request
 
request->ring = ce->ring;
 
+   ret = intel_lr_context_pin(request->ctx, engine);
+   if (ret)
+   return ret;
+
if (i915.enable_guc_submission) {
/*
 * Check that the GuC has space for the request before
@@ -643,21 +647,17 @@ int intel_logical_ring_alloc_request_extras(struct 
drm_i915_gem_request *request
 */
ret = i915_guc_wq_reserve(request);
if (ret)
-   return ret;
+   goto err_unpin;
}
 
-   ret = intel_lr_context_pin(request->ctx, engine);
-   if (ret)
-   return ret;
-
ret = intel_ring_begin(request, 0);
if (ret)
-   goto err_unpin;
+   goto err_unreserve;
 
if (!ce->initialised) {
ret = engine->init_context(request);
if (ret)
-   goto err_unpin;
+   goto err_unreserve;
 
ce->initialised = true;
}
@@ -672,6 +672,9 @@ int intel_logical_ring_alloc_request_extras(struct 
drm_i915_gem_request *request
request->reserved_space -= EXECLISTS_REQUEST_SIZE;
return 0;
 
+err_unreserve:
+   if (i915.enable_guc_submission)
+   i915_guc_wq_unreserve(request);
 err_unpin:
intel_lr_context_unpin(request->ctx, engine);
return ret;
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Reset the breadcrumbs IRQ more carefully

[Mika Kuoppala]

Chris Wilson  writes:

> Along with the interrupt, we want to restore the fake-irq and
> wait-timeout detection. If we use the breadcrumbs interface to setup the
> interrupt as it wants, the auxiliary timers will also be restored.
>
> Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests")
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/intel_breadcrumbs.c | 17 +
>  drivers/gpu/drm/i915/intel_engine_cs.c   | 15 ---
>  drivers/gpu/drm/i915/intel_lrc.c |  2 +-
>  drivers/gpu/drm/i915/intel_ringbuffer.c  |  2 +-
>  drivers/gpu/drm/i915/intel_ringbuffer.h  |  2 +-
>  5 files changed, 20 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
> b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> index 9dba4971fb1e..d27da6d69735 100644
> --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
> +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> @@ -584,6 +584,23 @@ int intel_engine_init_breadcrumbs(struct intel_engine_cs 
> *engine)
>   return 0;
>  }
>  
> +void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine)
> +{
> + struct intel_breadcrumbs *b = >breadcrumbs;
> +

Should we kill the timer before proceeding in here?

Not relevant to this patch but I also noticed that the period
is identical to hangcheck period. Multiple of hangcheck period
would be better, as our kicking might help and we don't
want to fallback to fake irqs just so easily.

-Mika

> + clear_bit(engine->id, >i915->gpu_error.missed_irq_rings);
> +
> + spin_lock(>lock);
> +
> + __intel_breadcrumbs_disable_irq(b);
> + if (intel_engine_has_waiter(engine)) {
> + b->timeout = wait_timeout();
> + __intel_breadcrumbs_enable_irq(b);
> + }
> +
> + spin_unlock(>lock);
> +}
> +
>  void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine)
>  {
>   struct intel_breadcrumbs *b = >breadcrumbs;
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index c8ac72ba4000..755f1a8b76d8 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -210,9 +210,6 @@ void intel_engine_init_global_seqno(struct 
> intel_engine_cs *engine, u32 seqno)
>  void intel_engine_init_hangcheck(struct intel_engine_cs *engine)
>  {
>   memset(>hangcheck, 0, sizeof(engine->hangcheck));
> - clear_bit(engine->id, >i915->gpu_error.missed_irq_rings);
> - if (intel_engine_has_waiter(engine))
> - i915_queue_hangcheck(engine->i915);
>  }
>  
>  static void intel_engine_init_timeline(struct intel_engine_cs *engine)
> @@ -308,18 +305,6 @@ int intel_engine_init_common(struct intel_engine_cs 
> *engine)
>   return 0;
>  }
>  
> -void intel_engine_reset_irq(struct intel_engine_cs *engine)
> -{
> - struct drm_i915_private *dev_priv = engine->i915;
> -
> - spin_lock_irq(_priv->irq_lock);
> - if (intel_engine_has_waiter(engine))
> - engine->irq_enable(engine);
> - else
> - engine->irq_disable(engine);
> - spin_unlock_irq(_priv->irq_lock);
> -}
> -
>  /**
>   * intel_engines_cleanup_common - cleans up the engine state created by
>   *the common initiailizers.
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index bf22c94c3d53..eb162553cff2 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1199,7 +1199,7 @@ static int gen8_init_common_ring(struct intel_engine_cs 
> *engine)
>  
>   lrc_init_hws(engine);
>  
> - intel_engine_reset_irq(engine);
> + intel_engine_reset_breadcrumbs(engine);
>  
>   I915_WRITE(RING_HWSTAM(engine->mmio_base), 0x);
>  
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 4bc47af68454..3abfbe3cfed9 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -548,7 +548,7 @@ static int init_ring_common(struct intel_engine_cs 
> *engine)
>   else
>   intel_ring_setup_status_page(engine);
>  
> - intel_engine_reset_irq(engine);
> + intel_engine_reset_breadcrumbs(engine);
>  
>   /* Enforce ordering by reading HEAD register back */
>   I915_READ_HEAD(engine);
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index 29d37b7c6021..a888f68d63d9 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -482,7 +482,6 @@ int __intel_ring_space(int head, int tail, int size);
>  void intel_ring_update_space(struct intel_ring *ring);
>  
>  void intel_engine_init_global_seqno(struct intel_engine_cs *engine, u32 
> seqno);
> -void intel_engine_reset_irq(struct intel_engine_cs *engine);
>  
>  void 

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to handle GuC when GuC is not supported.

[Jani Nikula]

On Thu, 06 Oct 2016, Paulo Zanoni  wrote:
> Em Qua, 2016-10-05 às 23:37 +, Vivi, Rodrigo escreveu:
>> Hi Daniel,
>> 
>> So, can we close https://bugs.freedesktop.org/show_bug.cgi?id=97573
>> with
>> wontfix or notabug?
>> 
>> I don't have a strong side on that actually, but Jani was against it
>> it
>> seems.
>
> Just my opinion:
>
> Considering that we already identified the problem and the fix is
> simple, I really think it's better to just fix it. In fact I thought
> you were going to submit V2 and I was planning to do the review.
>
> Fixing this may help reducing future bug triaging time, because if we
> keep the problem unfixed we may get the same bug report again and again
> and again. It's easy to say "users get to keep all the pieces of the
> broken kernel", but we usually have to triage the problems regardless,
> discuss what to do, etc.

All, please stop the discussion and just do one or the other. I'll ack
either approach.

http://dilbert.com/strip/1998-11-10


BR,
Jani.



>
>> 
>> Thanks,
>> Rodrigo.
>> 
>> On Wed, 2016-10-05 at 15:50 +0200, Daniel Vetter wrote:
>> > 
>> > On Thu, Sep 22, 2016 at 04:55:07PM +, Vivi, Rodrigo wrote:
>> > > 
>> > > On Wed, 2016-09-21 at 18:00 -0300, Paulo Zanoni wrote:
>> > > > 
>> > > > Em Qua, 2016-09-21 às 11:22 -0700, Rodrigo Vivi escreveu:
>> > > > > 
>> > > > > Avoid any kind of GuC handling if GuC is not supported
>> > > > > on a giving platform.
>> > > > > 
>> > > > > Besides being useless handling, our driver needs
>> > > > > to be smarter than the user trying to use an invalid
>> > > > > paramenter.
>> > > > 
>> > > > So the problem is when a platform doesn't support guc and the
>> > > > user
>> > > > passes i915.enable_guc_something=1, right?
>> > > 
>> > > 1 is not a problem actually since it means "use if available".
>> > > There is
>> > > not firmware and execution continues.
>> > > 
>> > > 2 is the problem because it means "use guc or fail if not
>> > > available".
>> > > But platforms that don't have guc can't fail. driver needs to be
>> > > smarter
>> > > than that.
>> > 
>> > Not sure it needs to be smarter than that really, since all these
>> > debug
>> > options auto-taint the kernel if you touch them. As in: You get to
>> > keep
>> > all the pieces.
>> > 
>> > We can still do some auto-cleanup of modoptions ofc if there's a
>> > good need
>> > for them.
>> > -Daniel
>> > 
>> > > 
>> > > 
>> > > > 
>> > > > 
>> > > > > 
>> > > > > 
>> > > > > Cc: Jani Nikula 
>> > > > > Cc: Anusha Srivatsa 
>> > > > > Cc: Christophe Prigent 
>> > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97573
>> > > > > Signed-off-by: Rodrigo Vivi 
>> > > > > ---
>> > > > >  drivers/gpu/drm/i915/intel_guc_loader.c | 7 +++
>> > > > >  1 file changed, 7 insertions(+)
>> > > > > 
>> > > > > diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
>> > > > > b/drivers/gpu/drm/i915/intel_guc_loader.c
>> > > > > index 6fd39ef..da0f5ed 100644
>> > > > > --- a/drivers/gpu/drm/i915/intel_guc_loader.c
>> > > > > +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
>> > > > > @@ -720,6 +720,13 @@ void intel_guc_init(struct drm_device
>> > > > > *dev)
>> > > > >  struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
>> > > > >  const char *fw_path;
>> > > > >  
>> > > > > +if (!HAS_GUC(dev)) {
>> > > > > +i915.enable_guc_loading = 0;
>> > > > > +i915.enable_guc_submission = 0;
>> > > > > +fw_path = NULL;
>> > > > > +return;
>> > > > > +}
>> > > > 
>> > > > Instead of this, how about we just patch the code below with:
>> > > > 
>> > > > if (!HAS_GUC(dev_priv)) {
>> > > >i915.enable_guc_loading = 0;
>> > > >i915.enable_guc_submission = 0;
>> > > > } else {
>> > > >/* A negative value means "use platform default" */
>> > > >if (i915.enable_guc_loading < 0)
>> > > >i915.enable_guc_loading =
>> > > > HAS_GUC_UCODE(dev_priv);
>> > > >if (i915.enable_guc_submission < 0)
>> > > >i915.enable_guc_submission =
>> > > > HAS_GUC_SCHED(dev_priv);
>> > > > }
>> > > 
>> > > yeap, this works as well. I just went for the simplest option
>> > > that
>> > > minimized at most any interactions for platforms where GuC simply
>> > > doesn't exist.
>> > > 
>> > > > 
>> > > > 
>> > > > Or we could even go with our current "design pattern" and
>> > > > create
>> > > > intel_sanitize_guc_options().
>> > > 
>> > > This is indeed a very good idea.
>> > > 
>> > > > 
>> > > > 
>> > > > This way we'll be able to avoid adding a second failure code
>> > > > path,
>> > > > since we already have one for platforms with guc but options
>> > > > disabled.
>> > > > 
>> > > > 
>> > > > > 
>> > > > > +
>> > > > >  /* A negative value means "use platform default" */
>> > > > >  if (i915.enable_guc_loading < 0)
>> > > > >  

Re: [Intel-gfx] [PATCH] drm/i915/guc: Delay GuC workqueue reservation

[Chris Wilson]

On Thu, Oct 06, 2016 at 03:14:19PM +0200, Michał Winiarski wrote:
> We're reserving space in the workqueue early during request allocation.
> This can be problematic if we get interrupted later in the process,
> because we can end up in a state where GuC workqueue is seemingly full,
> while the HW is idle and no work has been submitted.
> Let's delay the reservation to avoid such scenario.
> 
> Testcase: igt/gem_ringfill/*-interruptible
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97978
> Cc: Michel Thierry 
> Cc: Jeff Mcgee 
> Signed-off-by: Michał Winiarski 
> ---
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 11 +++
>  drivers/gpu/drm/i915/intel_lrc.c   | 11 ---
>  2 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index e88786e..37204db 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1529,6 +1529,17 @@ execbuf_submit(struct i915_execbuffer_params *params,
>   if (ret)
>   return ret;
>  
> + if (i915.enable_guc_submission) {

No. This logic does not deserve to be at this level. Please try fixing
the underlying problem, which would be that we don't cancel the reserved
space.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/guc: Delay GuC workqueue reservation

[Michał Winiarski]

We're reserving space in the workqueue early during request allocation.
This can be problematic if we get interrupted later in the process,
because we can end up in a state where GuC workqueue is seemingly full,
while the HW is idle and no work has been submitted.
Let's delay the reservation to avoid such scenario.

Testcase: igt/gem_ringfill/*-interruptible
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97978
Cc: Michel Thierry 
Cc: Jeff Mcgee 
Signed-off-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 11 +++
 drivers/gpu/drm/i915/intel_lrc.c   | 11 ---
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index e88786e..37204db 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1529,6 +1529,17 @@ execbuf_submit(struct i915_execbuffer_params *params,
if (ret)
return ret;
 
+   if (i915.enable_guc_submission) {
+   /*
+* Check that the GuC has space for the request before
+* going any further, as the i915_add_request() call
+* later on mustn't fail ...
+*/
+   ret = i915_guc_wq_reserve(params->request);
+   if (ret)
+   return ret;
+   }
+
trace_i915_gem_ring_dispatch(params->request, params->dispatch_flags);
 
i915_gem_execbuffer_move_to_active(vmas, params->request);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 936f6f6..cc8fd03 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -626,17 +626,6 @@ int intel_logical_ring_alloc_request_extras(struct 
drm_i915_gem_request *request
 
request->ring = ce->ring;
 
-   if (i915.enable_guc_submission) {
-   /*
-* Check that the GuC has space for the request before
-* going any further, as the i915_add_request() call
-* later on mustn't fail ...
-*/
-   ret = i915_guc_wq_reserve(request);
-   if (ret)
-   return ret;
-   }
-
ret = intel_lr_context_pin(request->ctx, engine);
if (ret)
return ret;
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 i-g-t] aubdump: add --command option to stream aubdump to another program

[Lionel Landwerlin]

On 06/10/16 13:46, Ville Syrjälä wrote:

On Thu, Oct 06, 2016 at 11:13:22AM +0100, Lionel Landwerlin wrote:

This comes handy if you want to look at your application output without
having to save it into a file. For example, use this with aubinator from
Mesa :

$ intel_aubdump -c '/path/to/aubinator --gen=hsw' my_gl_app

Why not just write to stdout so you could just pipe it to something else?


Most of the applications I've dealt with end writing on stdout as well :(




v2: Fix handling empty command line option

v3: Fix command line concatenation (again...)

Signed-off-by: Lionel Landwerlin 
Cc: Sirisha Gandikota 
---
  tools/aubdump.c| 107 -
  tools/intel_aubdump.in |  31 +-
  2 files changed, 117 insertions(+), 21 deletions(-)

diff --git a/tools/aubdump.c b/tools/aubdump.c
index 30dc742..3b85bc7 100644
--- a/tools/aubdump.c
+++ b/tools/aubdump.c
@@ -50,6 +50,7 @@ static int (*libc_close)(int fd) = close_init_helper;
  static int (*libc_ioctl)(int fd, unsigned long request, ...) = 
ioctl_init_helper;

  static int drm_fd = -1;
+static char *command;
  static char *filename;
  static FILE *file;
  static int gen = 0;
@@ -113,6 +114,82 @@ fail_if(int cond, const char *format, ...)
raise(SIGTRAP);
  }

+static FILE *
+launch_command(void)
+{
+   int i = 0, fds[2];
+   char **args = calloc(strlen(command), sizeof(char *));
+   char *iter = command;
+
+   args[i++] = iter = command;
+
+   while ((iter = strstr(iter, ",")) != NULL) {
+   *iter = '\0';
+   iter += 1;
+   args[i++] = iter;
+   }
+
+   if (pipe(fds) == -1)
+   return NULL;
+
+   switch (fork()) {
+   case 0:
+   dup2(fds[0], 0);
+   fail_if(execv(args[0], args) == -1,
+   "intel_aubdump: fail to launch child command\n");
+   return NULL;
+
+   default:
+   free(args);
+   return fdopen(fds[1], "w");
+
+   case -1:
+   return NULL;
+   }
+}
+
+static void
+maybe_init_output(void)
+{
+   const char *args;
+   static bool initialized = false;
+   int nb_args;
+
+   if (initialized)
+   return;
+
+   args = getenv("INTEL_AUBDUMP_ARGS");
+
+   nb_args = sscanf(args, 
"verbose=%d;file=%m[^;];device=%i;command=%m[^;];",
+, , , );
+   if (nb_args != 4) {
+   if (filename)
+   free(filename);
+   nb_args = sscanf(args, "verbose=%d;file=%m[^;];device=%i;",
+, , );
+   command = strdup("");
+   }
+fail_if(filename == NULL || command == NULL,
+"intel_aubdump: out of memory\n");
+   if (device)
+   device_override = true;
+
+   bos = malloc(MAX_BO_COUNT * sizeof(bos[0]));
+   fail_if(bos == NULL, "intel_aubdump: out of memory\n");
+
+if (strlen(command) != 0) {
+  file = launch_command();
+  fail_if(file == NULL,
+  "intel_aubdump: failed to launch command '%s'\n", command);
+} else {
+  file = fopen(filename, "w+");
+  fail_if(file == NULL,
+  "intel_aubdump: failed to open file '%s'\n", filename);
+}
+
+   initialized = true;
+}
+
  static struct bo *
  get_bo(uint32_t handle)
  {
@@ -140,13 +217,18 @@ align_u64(uint64_t v, uint64_t a)
  static void
  dword_out(uint32_t data)
  {
-   fwrite(, 1, 4, file);
+   fail_if(fwrite(, 1, 4, file) == 0,
+   "Writing to output failed\n");
  }

  static void
  data_out(const void *data, size_t size)
  {
-   fwrite(data, 1, size, file);
+   if (size == 0)
+   return;
+
+   fail_if(fwrite(data, 1, size, file) == 0,
+   "Writing to output failed\n");
  }

  static void
@@ -447,6 +529,8 @@ ioctl(int fd, unsigned long request, ...)
}

if (fd == drm_fd) {
+   maybe_init_output();
+
switch (request) {
case DRM_IOCTL_I915_GETPARAM: {
struct drm_i915_getparam *getparam = argp;
@@ -550,26 +634,8 @@ ioctl(int fd, unsigned long request, ...)
  static void
  init(void)
  {
-   const char *args = getenv("INTEL_AUBDUMP_ARGS");
-
libc_close = dlsym(RTLD_NEXT, "close");
libc_ioctl = dlsym(RTLD_NEXT, "ioctl");
-   fail_if(libc_close == NULL || libc_ioctl == NULL,
-   "intel_aubdump: failed to get libc ioctl or close\n");
-
-   if (sscanf(args, "verbose=%d;file=%m[^;];device=%i",
-  , , ) != 3)
-   filename = strdup("intel.aub");
-   fail_if(filename == NULL, "intel_aubdump: out of memory\n");
-
-   if (device)
-   device_override = true;
-
-   bos = malloc(MAX_BO_COUNT * sizeof(bos[0]));
-   

Re: [Intel-gfx] [PATCH v3 i-g-t] aubdump: add --command option to stream aubdump to another program

[Ville Syrjälä]

On Thu, Oct 06, 2016 at 11:13:22AM +0100, Lionel Landwerlin wrote:
> This comes handy if you want to look at your application output without
> having to save it into a file. For example, use this with aubinator from
> Mesa :
> 
> $ intel_aubdump -c '/path/to/aubinator --gen=hsw' my_gl_app

Why not just write to stdout so you could just pipe it to something else?

> 
> v2: Fix handling empty command line option
> 
> v3: Fix command line concatenation (again...)
> 
> Signed-off-by: Lionel Landwerlin 
> Cc: Sirisha Gandikota 
> ---
>  tools/aubdump.c| 107 
> -
>  tools/intel_aubdump.in |  31 +-
>  2 files changed, 117 insertions(+), 21 deletions(-)
> 
> diff --git a/tools/aubdump.c b/tools/aubdump.c
> index 30dc742..3b85bc7 100644
> --- a/tools/aubdump.c
> +++ b/tools/aubdump.c
> @@ -50,6 +50,7 @@ static int (*libc_close)(int fd) = close_init_helper;
>  static int (*libc_ioctl)(int fd, unsigned long request, ...) = 
> ioctl_init_helper;
> 
>  static int drm_fd = -1;
> +static char *command;
>  static char *filename;
>  static FILE *file;
>  static int gen = 0;
> @@ -113,6 +114,82 @@ fail_if(int cond, const char *format, ...)
>   raise(SIGTRAP);
>  }
> 
> +static FILE *
> +launch_command(void)
> +{
> + int i = 0, fds[2];
> + char **args = calloc(strlen(command), sizeof(char *));
> + char *iter = command;
> +
> + args[i++] = iter = command;
> +
> + while ((iter = strstr(iter, ",")) != NULL) {
> + *iter = '\0';
> + iter += 1;
> + args[i++] = iter;
> + }
> +
> + if (pipe(fds) == -1)
> + return NULL;
> +
> + switch (fork()) {
> + case 0:
> + dup2(fds[0], 0);
> + fail_if(execv(args[0], args) == -1,
> + "intel_aubdump: fail to launch child command\n");
> + return NULL;
> +
> + default:
> + free(args);
> + return fdopen(fds[1], "w");
> +
> + case -1:
> + return NULL;
> + }
> +}
> +
> +static void
> +maybe_init_output(void)
> +{
> + const char *args;
> + static bool initialized = false;
> + int nb_args;
> +
> + if (initialized)
> + return;
> +
> + args = getenv("INTEL_AUBDUMP_ARGS");
> +
> + nb_args = sscanf(args, 
> "verbose=%d;file=%m[^;];device=%i;command=%m[^;];",
> +  , , , );
> + if (nb_args != 4) {
> + if (filename)
> + free(filename);
> + nb_args = sscanf(args, "verbose=%d;file=%m[^;];device=%i;",
> +  , , );
> + command = strdup("");
> + }
> +fail_if(filename == NULL || command == NULL,
> +"intel_aubdump: out of memory\n");
> + if (device)
> + device_override = true;
> +
> + bos = malloc(MAX_BO_COUNT * sizeof(bos[0]));
> + fail_if(bos == NULL, "intel_aubdump: out of memory\n");
> +
> +if (strlen(command) != 0) {
> +  file = launch_command();
> +  fail_if(file == NULL,
> +  "intel_aubdump: failed to launch command '%s'\n", command);
> +} else {
> +  file = fopen(filename, "w+");
> +  fail_if(file == NULL,
> +  "intel_aubdump: failed to open file '%s'\n", filename);
> +}
> +
> + initialized = true;
> +}
> +
>  static struct bo *
>  get_bo(uint32_t handle)
>  {
> @@ -140,13 +217,18 @@ align_u64(uint64_t v, uint64_t a)
>  static void
>  dword_out(uint32_t data)
>  {
> - fwrite(, 1, 4, file);
> + fail_if(fwrite(, 1, 4, file) == 0,
> + "Writing to output failed\n");
>  }
> 
>  static void
>  data_out(const void *data, size_t size)
>  {
> - fwrite(data, 1, size, file);
> + if (size == 0)
> + return;
> +
> + fail_if(fwrite(data, 1, size, file) == 0,
> + "Writing to output failed\n");
>  }
> 
>  static void
> @@ -447,6 +529,8 @@ ioctl(int fd, unsigned long request, ...)
>   }
> 
>   if (fd == drm_fd) {
> + maybe_init_output();
> +
>   switch (request) {
>   case DRM_IOCTL_I915_GETPARAM: {
>   struct drm_i915_getparam *getparam = argp;
> @@ -550,26 +634,8 @@ ioctl(int fd, unsigned long request, ...)
>  static void
>  init(void)
>  {
> - const char *args = getenv("INTEL_AUBDUMP_ARGS");
> -
>   libc_close = dlsym(RTLD_NEXT, "close");
>   libc_ioctl = dlsym(RTLD_NEXT, "ioctl");
> - fail_if(libc_close == NULL || libc_ioctl == NULL,
> - "intel_aubdump: failed to get libc ioctl or close\n");
> -
> - if (sscanf(args, "verbose=%d;file=%m[^;];device=%i",
> -, , ) != 3)
> - filename = strdup("intel.aub");
> - fail_if(filename == NULL, "intel_aubdump: out of memory\n");
> -
> - if (device)
> - device_override = true;
> -
> - bos = 

Re: [Intel-gfx] [PATCH i-g-t] tests/drv_module_reload_basic: Leave basic breadcrumbs in dmesg

[Ville Syrjälä]

On Thu, Oct 06, 2016 at 03:17:45PM +0300, Jani Nikula wrote:
> On Thu, 06 Oct 2016, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > Leave the normal "executing" and "exiting" breadcrumbs into dmesg when
> > running the test.
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  tests/drv_module_reload_basic | 27 +++
> >  1 file changed, 27 insertions(+)
> >
> > diff --git a/tests/drv_module_reload_basic b/tests/drv_module_reload_basic
> > index 93cf7c005638..4c75f0e9614a 100755
> > --- a/tests/drv_module_reload_basic
> > +++ b/tests/drv_module_reload_basic
> > @@ -6,6 +6,33 @@
> >  #
> >  
> >  SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
> > +
> > +NAME=$(basename "$0")
> > +
> > +KERN_EMER="<0>"
> > +KERN_ALERT="<1>"
> > +KERN_CRIT="<2>"
> > +KERN_ERR="<3>"
> > +KERN_WARNING="<4>"
> > +KERN_NOTICE="<5>"
> > +KERN_INFO="<6>"
> > +KERN_DEBUG="<7>"
> > +
> > +function kmsg()
> > +{
> > +   echo "$1" > /dev/kmsg
> > +}
> > +
> 
> Seems like these would belong in drm_lib.sh. Or do you really need to do
> the kmsg *before* sourcing drm_lib.sh?

drm_lib.sh can itself exit, so the trap needs to be done before sourcing
it. And drm_lib.sh isn't a bash script, so I didn't dare to put it
there.

> 
> BR,
> Jani.
> 
> > +function finish()
> > +{
> > +   exitcode=$?
> > +   kmsg "$KERN_INFO$NAME: exiting, ret=$exitcode"
> > +   exit $exitcode
> > +}
> > +trap finish EXIT
> > +
> > +kmsg "$KERN_INFO$NAME: executing"
> > +
> >  . $SOURCE_DIR/drm_lib.sh
> >  
> >  # no other drm service should be running, so we can just unbind
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
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] drm/i915: Don't try to handle GuC when GuC is not supported.

[Paulo Zanoni]

Em Qua, 2016-10-05 às 23:37 +, Vivi, Rodrigo escreveu:
> Hi Daniel,
> 
> So, can we close https://bugs.freedesktop.org/show_bug.cgi?id=97573
> with
> wontfix or notabug?
> 
> I don't have a strong side on that actually, but Jani was against it
> it
> seems.

Just my opinion:

Considering that we already identified the problem and the fix is
simple, I really think it's better to just fix it. In fact I thought
you were going to submit V2 and I was planning to do the review.

Fixing this may help reducing future bug triaging time, because if we
keep the problem unfixed we may get the same bug report again and again
and again. It's easy to say "users get to keep all the pieces of the
broken kernel", but we usually have to triage the problems regardless,
discuss what to do, etc.

> 
> Thanks,
> Rodrigo.
> 
> On Wed, 2016-10-05 at 15:50 +0200, Daniel Vetter wrote:
> > 
> > On Thu, Sep 22, 2016 at 04:55:07PM +, Vivi, Rodrigo wrote:
> > > 
> > > On Wed, 2016-09-21 at 18:00 -0300, Paulo Zanoni wrote:
> > > > 
> > > > Em Qua, 2016-09-21 às 11:22 -0700, Rodrigo Vivi escreveu:
> > > > > 
> > > > > Avoid any kind of GuC handling if GuC is not supported
> > > > > on a giving platform.
> > > > > 
> > > > > Besides being useless handling, our driver needs
> > > > > to be smarter than the user trying to use an invalid
> > > > > paramenter.
> > > > 
> > > > So the problem is when a platform doesn't support guc and the
> > > > user
> > > > passes i915.enable_guc_something=1, right?
> > > 
> > > 1 is not a problem actually since it means "use if available".
> > > There is
> > > not firmware and execution continues.
> > > 
> > > 2 is the problem because it means "use guc or fail if not
> > > available".
> > > But platforms that don't have guc can't fail. driver needs to be
> > > smarter
> > > than that.
> > 
> > Not sure it needs to be smarter than that really, since all these
> > debug
> > options auto-taint the kernel if you touch them. As in: You get to
> > keep
> > all the pieces.
> > 
> > We can still do some auto-cleanup of modoptions ofc if there's a
> > good need
> > for them.
> > -Daniel
> > 
> > > 
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > Cc: Jani Nikula 
> > > > > Cc: Anusha Srivatsa 
> > > > > Cc: Christophe Prigent 
> > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97573
> > > > > Signed-off-by: Rodrigo Vivi 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_guc_loader.c | 7 +++
> > > > >  1 file changed, 7 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
> > > > > b/drivers/gpu/drm/i915/intel_guc_loader.c
> > > > > index 6fd39ef..da0f5ed 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> > > > > @@ -720,6 +720,13 @@ void intel_guc_init(struct drm_device
> > > > > *dev)
> > > > >   struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
> > > > >   const char *fw_path;
> > > > >  
> > > > > + if (!HAS_GUC(dev)) {
> > > > > + i915.enable_guc_loading = 0;
> > > > > + i915.enable_guc_submission = 0;
> > > > > + fw_path = NULL;
> > > > > + return;
> > > > > + }
> > > > 
> > > > Instead of this, how about we just patch the code below with:
> > > > 
> > > > if (!HAS_GUC(dev_priv)) {
> > > > i915.enable_guc_loading = 0;
> > > > i915.enable_guc_submission = 0;
> > > > } else {
> > > > /* A negative value means "use platform default" */
> > > > if (i915.enable_guc_loading < 0)
> > > > i915.enable_guc_loading =
> > > > HAS_GUC_UCODE(dev_priv);
> > > > if (i915.enable_guc_submission < 0)
> > > > i915.enable_guc_submission =
> > > > HAS_GUC_SCHED(dev_priv);
> > > > }
> > > 
> > > yeap, this works as well. I just went for the simplest option
> > > that
> > > minimized at most any interactions for platforms where GuC simply
> > > doesn't exist.
> > > 
> > > > 
> > > > 
> > > > Or we could even go with our current "design pattern" and
> > > > create
> > > > intel_sanitize_guc_options().
> > > 
> > > This is indeed a very good idea.
> > > 
> > > > 
> > > > 
> > > > This way we'll be able to avoid adding a second failure code
> > > > path,
> > > > since we already have one for platforms with guc but options
> > > > disabled.
> > > > 
> > > > 
> > > > > 
> > > > > +
> > > > >   /* A negative value means "use platform default" */
> > > > >   if (i915.enable_guc_loading < 0)
> > > > >   i915.enable_guc_loading =
> > > > > HAS_GUC_UCODE(dev);
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> 
___
Intel-gfx mailing list

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/3] Revert "Skip intel_crt_init for Dell XPS 8700"

[Jani Nikula]

On Thu, 06 Oct 2016, Jani Nikula  wrote:
> On Thu, 06 Oct 2016, Ville Syrjälä  wrote:
>> On Mon, Sep 26, 2016 at 10:23:48AM -, Patchwork wrote:
>>> == Series Details ==
>>> 
>>> Series: series starting with [1/3] Revert "Skip intel_crt_init for Dell XPS 
>>> 8700"
>>> URL   : https://patchwork.freedesktop.org/series/12920/
>>> State : warning
>>> 
>>> == Summary ==
>>> 
>>> Series 12920v1 Series without cover letter
>>> https://patchwork.freedesktop.org/api/1.0/series/12920/revisions/1/mbox/
>>> 
>>> Test drv_module_reload_basic:
>>> pass   -> SKIP   (fi-skl-6770hq)
>>
>> rmmod: ERROR: Module i915 is in use
>> rmmod: ERROR: Module i915 is in use
>> rmmod: ERROR: Module i915 is in use
>> rmmod: ERROR: Module i915 is in use
>> rmmod: ERROR: Module i915 is in use
>>
>> This test has been a bit flaky historically, and the droppings aren't
>> clear enough to pinpoint the fault.
>
> I added more breadcrumbs to the test, but this was not run with those
> changes. :(

Specifically, I mean

832dfbc6e904 igt/drv_module_reload_basic: let intel_ips removal errors through
2085e1476e6e igt/drv_module_reload_basic: let snd_hda_intel removal errors 
through
8f3cf597e498 igt/drv_module_reload_basic: add helper for checking module 
reloaded

but IGT used here was

32b20211adf2 benchmarks: Add some missing .gitignore binaries

BR,
Jani.


>
> BR,
> Jani.
>
>
>
>>
>>> Test kms_flip:
>>> Subgroup basic-flip-vs-dpms:
>>> pass   -> DMESG-WARN (fi-skl-6770hq)
>>
>> [  521.531723] [drm:skl_set_cdclk] *ERROR* failed to inform PCU about cdclk 
>> change
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=97929
>>
>> [  521.541043] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe C 
>> FIFO underrun
>>
>>> Test kms_pipe_crc_basic:
>>> Subgroup nonblocking-crc-pipe-a:
>>> pass   -> DMESG-WARN (fi-skl-6700k)
>>
>> [  543.224512] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe B 
>> FIFO underrun
>>
>> I'm going to chalk these up to SKL watermark problems.
>>
>>> Test kms_psr_sink_crc:
>>> Subgroup psr_basic:
>>> pass   -> DMESG-WARN (fi-skl-6700hq)
>>
>> [  669.493504] [drm:intel_pipe_update_start] *ERROR* Potential atomic update 
>> failure on pipe A
>>
>> Has been happening all along. PSR+DMC messing about with vblank
>> irqs/counters perhaps...
>>
>> Nothing CRT output related in here, so I'm going to declare the patches as 
>> safe.
>>
>>> 
>>> fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
>>> fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
>>> fi-byt-n2820 total:244  pass:208  dwarn:0   dfail:0   fail:1   skip:35 
>>> fi-hsw-4770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
>>> fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
>>> fi-ilk-650   total:244  pass:182  dwarn:0   dfail:0   fail:2   skip:60 
>>> fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
>>> fi-ivb-3770  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
>>> fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
>>> fi-skl-6700hqtotal:244  pass:221  dwarn:1   dfail:0   fail:0   skip:22 
>>> fi-skl-6700k total:244  pass:218  dwarn:2   dfail:0   fail:0   skip:24 
>>> fi-skl-6770hqtotal:244  pass:226  dwarn:2   dfail:0   fail:1   skip:15 
>>> fi-snb-2520m total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
>>> fi-snb-2600  total:244  pass:206  dwarn:0   dfail:0   fail:0   skip:38 
>>> 
>>> Results at /archive/results/CI_IGT_test/Patchwork_2575/
>>> 
>>> 34f3af78be52f23896926b7d41ca51d898c5224d drm-intel-nightly: 
>>> 2016y-09m-26d-09h-17m-56s UTC integration manifest
>>> 17b45ac drm/i915: Add spurious CRT DMI match for Intel DZ77BH-55K
>>> 4995164 drm/i915: Register shadow VGA even when it produces spurious 
>>> detection results
>>> 113f2c3 Revert "Skip intel_crt_init for Dell XPS 8700"

-- 
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] ✗ Fi.CI.BAT: warning for series starting with [1/3] Revert "Skip intel_crt_init for Dell XPS 8700"

[Jani Nikula]

On Thu, 06 Oct 2016, Ville Syrjälä  wrote:
> On Mon, Sep 26, 2016 at 10:23:48AM -, Patchwork wrote:
>> == Series Details ==
>> 
>> Series: series starting with [1/3] Revert "Skip intel_crt_init for Dell XPS 
>> 8700"
>> URL   : https://patchwork.freedesktop.org/series/12920/
>> State : warning
>> 
>> == Summary ==
>> 
>> Series 12920v1 Series without cover letter
>> https://patchwork.freedesktop.org/api/1.0/series/12920/revisions/1/mbox/
>> 
>> Test drv_module_reload_basic:
>> pass   -> SKIP   (fi-skl-6770hq)
>
> rmmod: ERROR: Module i915 is in use
> rmmod: ERROR: Module i915 is in use
> rmmod: ERROR: Module i915 is in use
> rmmod: ERROR: Module i915 is in use
> rmmod: ERROR: Module i915 is in use
>
> This test has been a bit flaky historically, and the droppings aren't
> clear enough to pinpoint the fault.

I added more breadcrumbs to the test, but this was not run with those
changes. :(

BR,
Jani.



>
>> Test kms_flip:
>> Subgroup basic-flip-vs-dpms:
>> pass   -> DMESG-WARN (fi-skl-6770hq)
>
> [  521.531723] [drm:skl_set_cdclk] *ERROR* failed to inform PCU about cdclk 
> change
>
> https://bugs.freedesktop.org/show_bug.cgi?id=97929
>
> [  521.541043] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe C 
> FIFO underrun
>
>> Test kms_pipe_crc_basic:
>> Subgroup nonblocking-crc-pipe-a:
>> pass   -> DMESG-WARN (fi-skl-6700k)
>
> [  543.224512] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe B 
> FIFO underrun
>
> I'm going to chalk these up to SKL watermark problems.
>
>> Test kms_psr_sink_crc:
>> Subgroup psr_basic:
>> pass   -> DMESG-WARN (fi-skl-6700hq)
>
> [  669.493504] [drm:intel_pipe_update_start] *ERROR* Potential atomic update 
> failure on pipe A
>
> Has been happening all along. PSR+DMC messing about with vblank
> irqs/counters perhaps...
>
> Nothing CRT output related in here, so I'm going to declare the patches as 
> safe.
>
>> 
>> fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
>> fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
>> fi-byt-n2820 total:244  pass:208  dwarn:0   dfail:0   fail:1   skip:35 
>> fi-hsw-4770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
>> fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
>> fi-ilk-650   total:244  pass:182  dwarn:0   dfail:0   fail:2   skip:60 
>> fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
>> fi-ivb-3770  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
>> fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
>> fi-skl-6700hqtotal:244  pass:221  dwarn:1   dfail:0   fail:0   skip:22 
>> fi-skl-6700k total:244  pass:218  dwarn:2   dfail:0   fail:0   skip:24 
>> fi-skl-6770hqtotal:244  pass:226  dwarn:2   dfail:0   fail:1   skip:15 
>> fi-snb-2520m total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
>> fi-snb-2600  total:244  pass:206  dwarn:0   dfail:0   fail:0   skip:38 
>> 
>> Results at /archive/results/CI_IGT_test/Patchwork_2575/
>> 
>> 34f3af78be52f23896926b7d41ca51d898c5224d drm-intel-nightly: 
>> 2016y-09m-26d-09h-17m-56s UTC integration manifest
>> 17b45ac drm/i915: Add spurious CRT DMI match for Intel DZ77BH-55K
>> 4995164 drm/i915: Register shadow VGA even when it produces spurious 
>> detection results
>> 113f2c3 Revert "Skip intel_crt_init for Dell XPS 8700"

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Force relocations via cpu if we run out of idle aperture

[Joonas Lahtinen]

On to, 2016-10-06 at 08:41 +0100, Chris Wilson wrote:
> If we run out of enough aperture space to fit the entire object, we
> fallback to trying to insert a single page. However, if that also fails,
> we currently fail to userspace with an unexpected ENOSPC. (ENOSPC means
> to userspace that their batch could not be fitted within the GTT.) Prior
> to commit e8cb909ac3ab ("drm/i915: Fallback to single page GTT
> mmappings for relocations") the approach is to fallback to using the
> slow CPU relocation path in case of iomapping failure, and that is the
> behaviour we need to restore.
> 
> Fixes: e8cb909ac3ab ("drm/i915: Fallback to single page GTT mmappings...")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98101
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/3] Revert "Skip intel_crt_init for Dell XPS 8700"

[Ville Syrjälä]

On Mon, Sep 26, 2016 at 10:23:48AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [1/3] Revert "Skip intel_crt_init for Dell XPS 
> 8700"
> URL   : https://patchwork.freedesktop.org/series/12920/
> State : warning
> 
> == Summary ==
> 
> Series 12920v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/12920/revisions/1/mbox/
> 
> Test drv_module_reload_basic:
> pass   -> SKIP   (fi-skl-6770hq)

rmmod: ERROR: Module i915 is in use
rmmod: ERROR: Module i915 is in use
rmmod: ERROR: Module i915 is in use
rmmod: ERROR: Module i915 is in use
rmmod: ERROR: Module i915 is in use

This test has been a bit flaky historically, and the droppings aren't
clear enough to pinpoint the fault.

> Test kms_flip:
> Subgroup basic-flip-vs-dpms:
> pass   -> DMESG-WARN (fi-skl-6770hq)

[  521.531723] [drm:skl_set_cdclk] *ERROR* failed to inform PCU about cdclk 
change

https://bugs.freedesktop.org/show_bug.cgi?id=97929

[  521.541043] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe C 
FIFO underrun

> Test kms_pipe_crc_basic:
> Subgroup nonblocking-crc-pipe-a:
> pass   -> DMESG-WARN (fi-skl-6700k)

[  543.224512] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe B 
FIFO underrun

I'm going to chalk these up to SKL watermark problems.

> Test kms_psr_sink_crc:
> Subgroup psr_basic:
> pass   -> DMESG-WARN (fi-skl-6700hq)

[  669.493504] [drm:intel_pipe_update_start] *ERROR* Potential atomic update 
failure on pipe A

Has been happening all along. PSR+DMC messing about with vblank
irqs/counters perhaps...

Nothing CRT output related in here, so I'm going to declare the patches as safe.

> 
> fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
> fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
> fi-byt-n2820 total:244  pass:208  dwarn:0   dfail:0   fail:1   skip:35 
> fi-hsw-4770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
> fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
> fi-ilk-650   total:244  pass:182  dwarn:0   dfail:0   fail:2   skip:60 
> fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
> fi-ivb-3770  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
> fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
> fi-skl-6700hqtotal:244  pass:221  dwarn:1   dfail:0   fail:0   skip:22 
> fi-skl-6700k total:244  pass:218  dwarn:2   dfail:0   fail:0   skip:24 
> fi-skl-6770hqtotal:244  pass:226  dwarn:2   dfail:0   fail:1   skip:15 
> fi-snb-2520m total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
> fi-snb-2600  total:244  pass:206  dwarn:0   dfail:0   fail:0   skip:38 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_2575/
> 
> 34f3af78be52f23896926b7d41ca51d898c5224d drm-intel-nightly: 
> 2016y-09m-26d-09h-17m-56s UTC integration manifest
> 17b45ac drm/i915: Add spurious CRT DMI match for Intel DZ77BH-55K
> 4995164 drm/i915: Register shadow VGA even when it produces spurious 
> detection results
> 113f2c3 Revert "Skip intel_crt_init for Dell XPS 8700"

-- 
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 i-g-t] tests/drv_module_reload_basic: Leave basic breadcrumbs in dmesg

[Jani Nikula]

On Thu, 06 Oct 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
>
> Leave the normal "executing" and "exiting" breadcrumbs into dmesg when
> running the test.
>
> Signed-off-by: Ville Syrjälä 
> ---
>  tests/drv_module_reload_basic | 27 +++
>  1 file changed, 27 insertions(+)
>
> diff --git a/tests/drv_module_reload_basic b/tests/drv_module_reload_basic
> index 93cf7c005638..4c75f0e9614a 100755
> --- a/tests/drv_module_reload_basic
> +++ b/tests/drv_module_reload_basic
> @@ -6,6 +6,33 @@
>  #
>  
>  SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
> +
> +NAME=$(basename "$0")
> +
> +KERN_EMER="<0>"
> +KERN_ALERT="<1>"
> +KERN_CRIT="<2>"
> +KERN_ERR="<3>"
> +KERN_WARNING="<4>"
> +KERN_NOTICE="<5>"
> +KERN_INFO="<6>"
> +KERN_DEBUG="<7>"
> +
> +function kmsg()
> +{
> + echo "$1" > /dev/kmsg
> +}
> +

Seems like these would belong in drm_lib.sh. Or do you really need to do
the kmsg *before* sourcing drm_lib.sh?

BR,
Jani.

> +function finish()
> +{
> + exitcode=$?
> + kmsg "$KERN_INFO$NAME: exiting, ret=$exitcode"
> + exit $exitcode
> +}
> +trap finish EXIT
> +
> +kmsg "$KERN_INFO$NAME: executing"
> +
>  . $SOURCE_DIR/drm_lib.sh
>  
>  # no other drm service should be running, so we can just unbind

-- 
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 8/9] drm/i915: Add location of the Rcomp resistor to bxt_ddi_phy_info

[Imre Deak]

On to, 2016-10-06 at 14:50 +0300, Ander Conselvan De Oliveira wrote:
> On Wed, 2016-10-05 at 17:51 +0300, Imre Deak wrote:
> > On ke, 2016-10-05 at 15:09 +0300, Ander Conselvan de Oliveira
> > wrote:
> > > 
> > > Use struct bxt_ddi_phy_info to hold information of where the
> > > Rcomp
> > > resistor is located, instead of hard coding it in the init
> > > sequence.
> > > 
> > > Note that this moves the enabling of the phy with the Rcomp
> > > resistor out
> > > of the power well enable code. That should be safe since
> > > bxt_ddi_phy_init() is called while the power domains lock is
> > > held, and
> > > that is the only way that function gets called, so there is no
> > > possibility of a concurrent phy enable caused by a power domain
> > > get
> > > call.
> > > 
> > > Signed-off-by: Ander Conselvan de Oliveira 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dpio_phy.c   | 76
> > > +-
> > > ---
> > >  drivers/gpu/drm/i915/intel_runtime_pm.c | 15 ---
> > >  2 files changed, 59 insertions(+), 32 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c
> > > b/drivers/gpu/drm/i915/intel_dpio_phy.c
> > > index 66d750a..e8a75fd 100644
> > > --- a/drivers/gpu/drm/i915/intel_dpio_phy.c
> > > +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
> > > @@ -124,6 +124,13 @@ struct bxt_ddi_phy_info {
> > >   bool dual_channel;
> > >  
> > >   /**
> > > +  * @rcomp_phy: If -1, indicates this phy has its own
> > > rcomp
> > > resistor.
> > > +  * Otherwise the GRC value will be copied from the phy
> > > indicated by
> > > +  * this field.
> > > +  */
> > > + enum dpio_phy rcomp_phy;
> > > +
> > > + /**
> > >    * @channel: struct containing per channel information.
> > >    */
> > >   struct {
> > > @@ -137,6 +144,7 @@ struct bxt_ddi_phy_info {
> > >  static const struct bxt_ddi_phy_info bxt_ddi_phy_info[] = {
> > >   [DPIO_PHY0] = {
> > >   .dual_channel = true,
> > > + .rcomp_phy = DPIO_PHY1,
> > >  
> > >   .channel = {
> > >   [DPIO_CH0] = { .port = PORT_B },
> > > @@ -145,6 +153,7 @@ static const struct bxt_ddi_phy_info
> > > bxt_ddi_phy_info[]
> > > = {
> > >   },
> > >   [DPIO_PHY1] = {
> > >   .dual_channel = false,
> > > + .rcomp_phy = -1,
> > >  
> > >   .channel = {
> > >   [DPIO_CH0] = { .port = PORT_A },
> > > @@ -152,6 +161,7 @@ static const struct bxt_ddi_phy_info
> > > bxt_ddi_phy_info[]
> > > = {
> > >   },
> > >  };
> > >  
> > > +static u32 bxt_phy_port_mask(const struct bxt_ddi_phy_info
> > > *phy_info)
> > >  {
> > >   return (phy_info->dual_channel * BIT(phy_info-
> > > > channel[DPIO_CH1].port)) |
> > >   BIT(phy_info->channel[DPIO_CH0].port);
> > > @@ -199,6 +209,7 @@ void bxt_ddi_phy_set_signal_level(struct
> > > drm_i915_private *dev_priv,
> > >  bool bxt_ddi_phy_is_enabled(struct drm_i915_private *dev_priv,
> > >   enum dpio_phy phy)
> > >  {
> > > + const struct bxt_ddi_phy_info *phy_info =
> > > _ddi_phy_info[phy];
> > >   enum port port;
> > >  
> > >   if (!(I915_READ(BXT_P_CR_GT_DISP_PWRON) &
> > > GT_DISPLAY_POWER_ON(phy)))
> > > @@ -212,9 +223,10 @@ bool bxt_ddi_phy_is_enabled(struct
> > > drm_i915_private
> > > *dev_priv,
> > >   return false;
> > >   }
> > >  
> > > - if (phy == DPIO_PHY1 &&
> > > - !(I915_READ(BXT_PORT_REF_DW3(DPIO_PHY1)) &
> > > GRC_DONE)) {
> > > - DRM_DEBUG_DRIVER("DDI PHY 1 powered, but GRC
> > > isn't
> > > done\n");
> > > + if (phy_info->rcomp_phy == -1 &&
> > > + !(I915_READ(BXT_PORT_REF_DW3(phy)) & GRC_DONE)) {
> > > + DRM_DEBUG_DRIVER("DDI PHY %d powered, but GRC
> > > isn't
> > > done\n",
> > > +  phy);
> > >  
> > >   return false;
> > >   }
> > > @@ -259,14 +271,15 @@ static void bxt_phy_wait_grc_done(struct
> > > drm_i915_private *dev_priv,
> > >   DRM_ERROR("timeout waiting for PHY%d GRC\n",
> > > phy);
> > >  }
> > >  
> > > -void bxt_ddi_phy_init(struct drm_i915_private *dev_priv, enum
> > > dpio_phy phy)
> > > +static void _bxt_ddi_phy_init(struct drm_i915_private *dev_priv,
> > > +   enum dpio_phy phy)
> > >  {
> > >   const struct bxt_ddi_phy_info *phy_info =
> > > _ddi_phy_info[phy];
> > >   u32 val;
> > >  
> > >   if (bxt_ddi_phy_is_enabled(dev_priv, phy)) {
> > >   /* Still read out the GRC value for state
> > > verification */
> > > - if (phy == DPIO_PHY0)
> > > + if (phy_info->rcomp_phy != -1)
> > >   dev_priv->bxt_phy_grc =
> > > bxt_get_grc(dev_priv, phy);
> > >  
> > >   if (bxt_ddi_phy_verify_state(dev_priv, phy)) {
> > > @@ -336,30 +349,32 @@ void bxt_ddi_phy_init(struct
> > > drm_i915_private
> > > *dev_priv, enum dpio_phy phy)
> > >   val |= OCL2_LDOFUSE_PWR_DIS;
> > >   I915_WRITE(BXT_PORT_CL1CM_DW30(phy), val);
> > >  
> > > - if (phy == DPIO_PHY0) {
> > > + if (phy_info->rcomp_phy != -1) {
> > >   uint32_t grc_code;
> > >   /*

[Intel-gfx] [PATCH i-g-t] tests/drv_module_reload_basic: Leave basic breadcrumbs in dmesg

[ville . syrjala]

From: Ville Syrjälä 

Leave the normal "executing" and "exiting" breadcrumbs into dmesg when
running the test.

Signed-off-by: Ville Syrjälä 
---
 tests/drv_module_reload_basic | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/tests/drv_module_reload_basic b/tests/drv_module_reload_basic
index 93cf7c005638..4c75f0e9614a 100755
--- a/tests/drv_module_reload_basic
+++ b/tests/drv_module_reload_basic
@@ -6,6 +6,33 @@
 #
 
 SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
+
+NAME=$(basename "$0")
+
+KERN_EMER="<0>"
+KERN_ALERT="<1>"
+KERN_CRIT="<2>"
+KERN_ERR="<3>"
+KERN_WARNING="<4>"
+KERN_NOTICE="<5>"
+KERN_INFO="<6>"
+KERN_DEBUG="<7>"
+
+function kmsg()
+{
+   echo "$1" > /dev/kmsg
+}
+
+function finish()
+{
+   exitcode=$?
+   kmsg "$KERN_INFO$NAME: exiting, ret=$exitcode"
+   exit $exitcode
+}
+trap finish EXIT
+
+kmsg "$KERN_INFO$NAME: executing"
+
 . $SOURCE_DIR/drm_lib.sh
 
 # no other drm service should be running, so we can just unbind
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Add location of the Rcomp resistor to bxt_ddi_phy_info

[Ander Conselvan De Oliveira]

On Wed, 2016-10-05 at 17:51 +0300, Imre Deak wrote:
> On ke, 2016-10-05 at 15:09 +0300, Ander Conselvan de Oliveira wrote:
> > 
> > Use struct bxt_ddi_phy_info to hold information of where the Rcomp
> > resistor is located, instead of hard coding it in the init sequence.
> > 
> > Note that this moves the enabling of the phy with the Rcomp resistor out
> > of the power well enable code. That should be safe since
> > bxt_ddi_phy_init() is called while the power domains lock is held, and
> > that is the only way that function gets called, so there is no
> > possibility of a concurrent phy enable caused by a power domain get
> > call.
> > 
> > Signed-off-by: Ander Conselvan de Oliveira 
> > ---
> >  drivers/gpu/drm/i915/intel_dpio_phy.c   | 76 +-
> > ---
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 15 ---
> >  2 files changed, 59 insertions(+), 32 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c
> > b/drivers/gpu/drm/i915/intel_dpio_phy.c
> > index 66d750a..e8a75fd 100644
> > --- a/drivers/gpu/drm/i915/intel_dpio_phy.c
> > +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
> > @@ -124,6 +124,13 @@ struct bxt_ddi_phy_info {
> >     bool dual_channel;
> >  
> >     /**
> > +    * @rcomp_phy: If -1, indicates this phy has its own rcomp
> > resistor.
> > +    * Otherwise the GRC value will be copied from the phy indicated by
> > +    * this field.
> > +    */
> > +   enum dpio_phy rcomp_phy;
> > +
> > +   /**
> >      * @channel: struct containing per channel information.
> >      */
> >     struct {
> > @@ -137,6 +144,7 @@ struct bxt_ddi_phy_info {
> >  static const struct bxt_ddi_phy_info bxt_ddi_phy_info[] = {
> >     [DPIO_PHY0] = {
> >     .dual_channel = true,
> > +   .rcomp_phy = DPIO_PHY1,
> >  
> >     .channel = {
> >     [DPIO_CH0] = { .port = PORT_B },
> > @@ -145,6 +153,7 @@ static const struct bxt_ddi_phy_info bxt_ddi_phy_info[]
> > = {
> >     },
> >     [DPIO_PHY1] = {
> >     .dual_channel = false,
> > +   .rcomp_phy = -1,
> >  
> >     .channel = {
> >     [DPIO_CH0] = { .port = PORT_A },
> > @@ -152,6 +161,7 @@ static const struct bxt_ddi_phy_info bxt_ddi_phy_info[]
> > = {
> >     },
> >  };
> >  
> > +static u32 bxt_phy_port_mask(const struct bxt_ddi_phy_info *phy_info)
> >  {
> >     return (phy_info->dual_channel * BIT(phy_info-
> > >channel[DPIO_CH1].port)) |
> >     BIT(phy_info->channel[DPIO_CH0].port);
> > @@ -199,6 +209,7 @@ void bxt_ddi_phy_set_signal_level(struct
> > drm_i915_private *dev_priv,
> >  bool bxt_ddi_phy_is_enabled(struct drm_i915_private *dev_priv,
> >     enum dpio_phy phy)
> >  {
> > +   const struct bxt_ddi_phy_info *phy_info = _ddi_phy_info[phy];
> >     enum port port;
> >  
> >     if (!(I915_READ(BXT_P_CR_GT_DISP_PWRON) &
> > GT_DISPLAY_POWER_ON(phy)))
> > @@ -212,9 +223,10 @@ bool bxt_ddi_phy_is_enabled(struct drm_i915_private
> > *dev_priv,
> >     return false;
> >     }
> >  
> > -   if (phy == DPIO_PHY1 &&
> > -   !(I915_READ(BXT_PORT_REF_DW3(DPIO_PHY1)) & GRC_DONE)) {
> > -   DRM_DEBUG_DRIVER("DDI PHY 1 powered, but GRC isn't
> > done\n");
> > +   if (phy_info->rcomp_phy == -1 &&
> > +   !(I915_READ(BXT_PORT_REF_DW3(phy)) & GRC_DONE)) {
> > +   DRM_DEBUG_DRIVER("DDI PHY %d powered, but GRC isn't
> > done\n",
> > +    phy);
> >  
> >     return false;
> >     }
> > @@ -259,14 +271,15 @@ static void bxt_phy_wait_grc_done(struct
> > drm_i915_private *dev_priv,
> >     DRM_ERROR("timeout waiting for PHY%d GRC\n", phy);
> >  }
> >  
> > -void bxt_ddi_phy_init(struct drm_i915_private *dev_priv, enum dpio_phy phy)
> > +static void _bxt_ddi_phy_init(struct drm_i915_private *dev_priv,
> > +     enum dpio_phy phy)
> >  {
> >     const struct bxt_ddi_phy_info *phy_info = _ddi_phy_info[phy];
> >     u32 val;
> >  
> >     if (bxt_ddi_phy_is_enabled(dev_priv, phy)) {
> >     /* Still read out the GRC value for state verification */
> > -   if (phy == DPIO_PHY0)
> > +   if (phy_info->rcomp_phy != -1)
> >     dev_priv->bxt_phy_grc = bxt_get_grc(dev_priv, phy);
> >  
> >     if (bxt_ddi_phy_verify_state(dev_priv, phy)) {
> > @@ -336,30 +349,32 @@ void bxt_ddi_phy_init(struct drm_i915_private
> > *dev_priv, enum dpio_phy phy)
> >     val |= OCL2_LDOFUSE_PWR_DIS;
> >     I915_WRITE(BXT_PORT_CL1CM_DW30(phy), val);
> >  
> > -   if (phy == DPIO_PHY0) {
> > +   if (phy_info->rcomp_phy != -1) {
> >     uint32_t grc_code;
> >     /*
> >      * PHY0 isn't connected to an RCOMP resistor so copy over
> >      * the corresponding calibrated value from PHY1, and
> > disable
> >      * the automatic calibration on PHY0.
> >      */
> > -   val = dev_priv->bxt_phy_grc = bxt_get_grc(dev_priv,
> > DPIO_PHY1);
> > +   val = 

Re: [Intel-gfx] [PATCH] drm/i915/gen9: fix DDB partitioning for multi-screen cases

[Maarten Lankhorst]

Op 04-10-16 om 19:44 schreef Paulo Zanoni:
> Em Ter, 2016-10-04 às 14:37 -0300, Paulo Zanoni escreveu:
>> With the previous code we were only recomputing the DDB partitioning
>> for the CRTCs included in the atomic commit, so any other active
>> CRTCs
>> would end up having their DDB registers zeroed. In this patch we make
>> sure that the computed state starts as a copy of the current
>> partitioning, and then we only zero the DDBs that we're actually
>> going to recompute.
>>
>> How to reproduce the bug:
>>   1 - Enable the primary plane on pipe A
>>   2 - Enable the primary plane on pipe B
>>   3 - Enable the sprite plane on pipe A
> Forgot to mention: sprite or cursor.
Testcase: kms_cursor_legacy.cursorA-vs-flipB-atomic-transitions

Fails with:
(kms_cursor_legacy:1962) igt-kms-CRITICAL: Last errno: 22, Invalid argument
(kms_cursor_legacy:1962) igt-kms-CRITICAL: error: -22 != 0

The test succeeds with this patch applied, but it still has FIFO underruns. Oh 
well it's progress..

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Regression report] Weekly regression report WW40

[Argotti, Yann]

> 
> On 06/10/16 13:26, Conselvan De Oliveira, Ander wrote:
> > On Thu, 2016-10-06 at 13:11 +0300, Jani Nikula wrote:
> >> On Wed, 05 Oct 2016, "Argotti, Yann"  wrote:
> >>>
> 
> >
> > On Mon, 03 Oct 2016, Jairo Miramontes
> >  wrote:
> >>
> >> This week regressions
> > In the past we used "regression", "bisect_pending", and "bisected"
> > in the bugzilla "Keywords" field. Can we start using those again,
> please?
>  I think this is a very good idea Jani. So we can start to scrub
>  current regression (and then igt linked one) and update
> accordingly.
>  Yann
> >>> Two additional thoughts are:
> >>> - add "regression_pending" (vs "regression") as well as keyword to
> >>> indicate where bug reporter has doubt on the fact it is or not a
> >>> regression.
> >> I think it should be enough, at least for a start (or should I say
> >> re-start), to freely use "regression" when things worked in the past
> >> but do not work anymore. We can then drop the keyword if it's not
> >> proven to be a regression.
> >>
> >> No strong feelings on "regression_pending", though. But I don't think
> >> you can add keywords at will, I think the field only accepts a
> >> predefined set of keywords. So you'd need to talk to Ander or Martin
> >> (Cc'd) to get the new one to bugzilla.
> >
> > I don't have admin access in bugzilla, so I would just forward such
> > requests to Martin.
> 
> Just tell me what you need when you all agree on the name :)
Thanks Martin.

Ok, so let use what it is already set, "re-starting" with "regression" key word 
but ensuring that use of this keyword is done simultaneously with good & bad 
commit id to brace that statement.
Yann 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/6] Start of skl watermark cleanup

[Maarten Lankhorst]

Op 05-10-16 om 17:33 schreef Lyude:
> While it (mostly) works, the code for handling watermarks on Skylake has been
> kind of ugly for a while. As well a lot of it isn't that friendly to atomic
> transactions, Lots of copy paste, redundant wm values, etc. While this isn't a
> full cleanup, it's a good start. As well, we add a couple of features for
> making debugging watermarks a little easier.
It's a good start, with the review comments addressed and rebased I think it's 
good to go. :)

Feel free to add my r-b.

~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Regression report] Weekly regression report WW40

[Martin Peres]

On 06/10/16 13:26, Conselvan De Oliveira, Ander wrote:

On Thu, 2016-10-06 at 13:11 +0300, Jani Nikula wrote:

On Wed, 05 Oct 2016, "Argotti, Yann"  wrote:






On Mon, 03 Oct 2016, Jairo Miramontes
 wrote:


This week regressions

In the past we used "regression", "bisect_pending", and "bisected" in
the bugzilla "Keywords" field. Can we start using those again, please?

I think this is a very good idea Jani. So we can start to scrub current
regression (and then igt linked one) and update accordingly.
Yann

Two additional thoughts are:
- add "regression_pending" (vs "regression") as well as keyword to
indicate where bug reporter has doubt on the fact it is or not a
regression.

I think it should be enough, at least for a start (or should I say
re-start), to freely use "regression" when things worked in the past but
do not work anymore. We can then drop the keyword if it's not proven to
be a regression.

No strong feelings on "regression_pending", though. But I don't think
you can add keywords at will, I think the field only accepts a
predefined set of keywords. So you'd need to talk to Ander or Martin
(Cc'd) to get the new one to bugzilla.


I don't have admin access in bugzilla, so I would just forward such requests to
Martin.


Just tell me what you need when you all agree on the name :)

-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 


This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/6] drm/i915/gen9: Make skl_wm_level per-plane

[Maarten Lankhorst]

Op 05-10-16 om 22:33 schreef Paulo Zanoni:
> Em Qua, 2016-10-05 às 11:33 -0400, Lyude escreveu:
>> Having skl_wm_level contain all of the watermarks for each plane is
>> annoying since it prevents us from having any sort of object to
>> represent a single watermark level, something we take advantage of in
>> the next commit to cut down on all of the copy paste code in here.
> I'd like to start my review pointing that I really like this patch. I
> agree the current form is annoying.
>
> See below for some details.
>
>
>> Signed-off-by: Lyude 
>> Cc: Maarten Lankhorst 
>> Cc: Ville Syrjälä 
>> Cc: Matt Roper 
>> ---
>>  drivers/gpu/drm/i915/i915_drv.h  |   6 +-
>>  drivers/gpu/drm/i915/intel_drv.h |   6 +-
>>  drivers/gpu/drm/i915/intel_pm.c  | 208 +--
>> 
>>  3 files changed, 100 insertions(+), 120 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index d26e5999..0f97d43 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -1648,9 +1648,9 @@ struct skl_wm_values {
>>  };
>>  
>>  struct skl_wm_level {
>> -bool plane_en[I915_MAX_PLANES];
>> -uint16_t plane_res_b[I915_MAX_PLANES];
>> -uint8_t plane_res_l[I915_MAX_PLANES];
>> +bool plane_en;
>> +uint16_t plane_res_b;
>> +uint8_t plane_res_l;
>>  };
>>  
>>  /*
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index 35ba282..d684f4f 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -468,9 +468,13 @@ struct intel_pipe_wm {
>>  bool sprites_scaled;
>>  };
>>  
>> -struct skl_pipe_wm {
>> +struct skl_plane_wm {
>>  struct skl_wm_level wm[8];
>>  struct skl_wm_level trans_wm;
>> +};
>> +
>> +struct skl_pipe_wm {
>> +struct skl_plane_wm planes[I915_MAX_PLANES];
>>  uint32_t linetime;
>>  };
>>  
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c
>> b/drivers/gpu/drm/i915/intel_pm.c
>> index af96888..250f12d 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -3668,67 +3668,52 @@ static int
>>  skl_compute_wm_level(const struct drm_i915_private *dev_priv,
>>   struct skl_ddb_allocation *ddb,
>>   struct intel_crtc_state *cstate,
>> + struct intel_plane *intel_plane,
>>   int level,
>>   struct skl_wm_level *result)
>>  {
>>  struct drm_atomic_state *state = cstate->base.state;
>>  struct intel_crtc *intel_crtc = to_intel_crtc(cstate-
>>> base.crtc);
>> -struct drm_plane *plane;
>> -struct intel_plane *intel_plane;
>> -struct intel_plane_state *intel_pstate;
>> +struct drm_plane *plane = _plane->base;
>> +struct intel_plane_state *intel_pstate = NULL;
>>  uint16_t ddb_blocks;
>>  enum pipe pipe = intel_crtc->pipe;
>>  int ret;
>> +int i = skl_wm_plane_id(intel_plane);
>> +
>> +if (state)
>> +intel_pstate =
>> +intel_atomic_get_existing_plane_state(state,
>> +  intel_
>> plane);
>>  
>>  /*
>> - * We'll only calculate watermarks for planes that are
>> actually
>> - * enabled, so make sure all other planes are set as
>> disabled.
>> + * Note: If we start supporting multiple pending atomic
>> commits against
>> + * the same planes/CRTC's in the future, plane->state will
>> no longer be
>> + * the correct pre-state to use for the calculations here
>> and we'll
>> + * need to change where we get the 'unchanged' plane data
>> from.
>> + *
>> + * For now this is fine because we only allow one queued
>> commit against
>> + * a CRTC.  Even if the plane isn't modified by this
>> transaction and we
>> + * don't have a plane lock, we still have the CRTC's lock,
>> so we know
>> + * that no other transactions are racing with us to update
>> it.
>>   */
>> -memset(result, 0, sizeof(*result));
>> -
>> -for_each_intel_plane_mask(_priv->drm,
>> -  intel_plane,
>> -  cstate->base.plane_mask) {
>> -int i = skl_wm_plane_id(intel_plane);
>> -
>> -plane = _plane->base;
>> -intel_pstate = NULL;
>> -if (state)
>> -intel_pstate =
>> -intel_atomic_get_existing_plane_stat
>> e(state,
>> -
>>   intel_plane);
>> +if (!intel_pstate)
>> +intel_pstate = to_intel_plane_state(plane->state);
>>  
>> -/*
>> - * Note: If we start supporting multiple pending
>> atomic commits
>> - * against the same planes/CRTC's in the future,
>> plane->state
>> - * 

Re: [Intel-gfx] [PATCH v2 07/15] drm/omap: Use per-plane rotation property

[Tomi Valkeinen]

On 06/10/16 13:30, Ville Syrjälä wrote:
> On Thu, Oct 06, 2016 at 12:59:17PM +0300, Tomi Valkeinen wrote:
>>
>> On 26/09/16 19:30, ville.syrj...@linux.intel.com wrote:
>>> From: Ville Syrjälä 
>>>
>>> The global mode_config.rotation_property is going away, switch over to
>>> per-plane rotation_property.
>>>
>>> Not sure I got the annoying crtc rotation_property handling right.
>>> Might work, or migth not.
>>>
>>> v2: Drop the BIT()
>>> Don't create rotation property twice for each primary plane
>>>
>>> Cc: Tomi Valkeinen 
>>> Cc: Rob Clark 
>>> Signed-off-by: Ville Syrjälä 
>>> ---
>>
>>
>>> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
>>> b/drivers/gpu/drm/omapdrm/omap_plane.c
>>> index 6ddaa5ea4b6b..b272f810989e 100644
>>> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
>>> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
>>> @@ -211,9 +211,16 @@ void omap_plane_install_properties(struct drm_plane 
>>> *plane,
>>> struct omap_drm_private *priv = dev->dev_private;
>>>  
>>> if (priv->has_dmm) {
>>> -   struct drm_property *prop = dev->mode_config.rotation_property;
>>> -
>>> -   drm_object_attach_property(obj, prop, DRM_ROTATE_0);
>>> +   if (!plane->rotation_property)
>>> +   drm_plane_create_rotation_property(plane,
>>> +  DRM_ROTATE_0,
>>> +  DRM_ROTATE_0 | 
>>> DRM_ROTATE_90 |
>>> +  DRM_ROTATE_180 | 
>>> DRM_ROTATE_270 |
>>> +  DRM_REFLECT_X | 
>>> DRM_REFLECT_Y);
>>> +
>>> +   if (plane->rotation_property && obj != >base)
>>> +   drm_object_attach_property(obj, 
>>> plane->rotation_property,
>>> +  DRM_ROTATE_0);
>>
>> I think this could use a short comment, as it's not obvious wth is going
>> on here =).
> 
> /* Attach the rotation property also to the crtc object */ ?

Yes, sounds fine to me.

 Tomi



signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 07/15] drm/omap: Use per-plane rotation property

[Ville Syrjälä]

On Thu, Oct 06, 2016 at 12:59:17PM +0300, Tomi Valkeinen wrote:
> 
> On 26/09/16 19:30, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > The global mode_config.rotation_property is going away, switch over to
> > per-plane rotation_property.
> > 
> > Not sure I got the annoying crtc rotation_property handling right.
> > Might work, or migth not.
> > 
> > v2: Drop the BIT()
> > Don't create rotation property twice for each primary plane
> > 
> > Cc: Tomi Valkeinen 
> > Cc: Rob Clark 
> > Signed-off-by: Ville Syrjälä 
> > ---
> 
> 
> > diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
> > b/drivers/gpu/drm/omapdrm/omap_plane.c
> > index 6ddaa5ea4b6b..b272f810989e 100644
> > --- a/drivers/gpu/drm/omapdrm/omap_plane.c
> > +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
> > @@ -211,9 +211,16 @@ void omap_plane_install_properties(struct drm_plane 
> > *plane,
> > struct omap_drm_private *priv = dev->dev_private;
> >  
> > if (priv->has_dmm) {
> > -   struct drm_property *prop = dev->mode_config.rotation_property;
> > -
> > -   drm_object_attach_property(obj, prop, DRM_ROTATE_0);
> > +   if (!plane->rotation_property)
> > +   drm_plane_create_rotation_property(plane,
> > +  DRM_ROTATE_0,
> > +  DRM_ROTATE_0 | 
> > DRM_ROTATE_90 |
> > +  DRM_ROTATE_180 | 
> > DRM_ROTATE_270 |
> > +  DRM_REFLECT_X | 
> > DRM_REFLECT_Y);
> > +
> > +   if (plane->rotation_property && obj != >base)
> > +   drm_object_attach_property(obj, 
> > plane->rotation_property,
> > +  DRM_ROTATE_0);
> 
> I think this could use a short comment, as it's not obvious wth is going
> on here =).

/* Attach the rotation property also to the crtc object */ ?

> 
> Otherwise both omap patches look fine, and test fine.
> 
> Reviewed-by: Tomi Valkeinen 
> 
>  Tomi
> 




-- 
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] [Regression report] Weekly regression report WW40

[Conselvan De Oliveira, Ander]

On Thu, 2016-10-06 at 13:11 +0300, Jani Nikula wrote:
> On Wed, 05 Oct 2016, "Argotti, Yann"  wrote:
> > 
> > > 
> > > > 
> > > > On Mon, 03 Oct 2016, Jairo Miramontes
> > > >  wrote:
> > > > > 
> > > > > This week regressions
> > > > In the past we used "regression", "bisect_pending", and "bisected" in
> > > > the bugzilla "Keywords" field. Can we start using those again, please?
> > > I think this is a very good idea Jani. So we can start to scrub current
> > > regression (and then igt linked one) and update accordingly.
> > > Yann
> > Two additional thoughts are:
> > - add "regression_pending" (vs "regression") as well as keyword to
> > indicate where bug reporter has doubt on the fact it is or not a
> > regression.
> I think it should be enough, at least for a start (or should I say
> re-start), to freely use "regression" when things worked in the past but
> do not work anymore. We can then drop the keyword if it's not proven to
> be a regression.
> 
> No strong feelings on "regression_pending", though. But I don't think
> you can add keywords at will, I think the field only accepts a
> predefined set of keywords. So you'd need to talk to Ander or Martin
> (Cc'd) to get the new one to bugzilla.

I don't have admin access in bugzilla, so I would just forward such requests to
Martin.

Ander
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 i-g-t 2/2] aubdump: add --command option to stream aubdump to another program

[Petri Latvala]

On Wed, Oct 05, 2016 at 11:48:27PM +0100, Lionel Landwerlin wrote:
> This comes handy if you want to look at your application output without
> having to save it into a file. For example, use this with aubinator from
> Mesa :
> 
> $ intel_aubdump -c '/path/to/aubinator --gen=hsw' my_gl_app
> 
> v2: Fix handling empty command line option
> 
> Signed-off-by: Lionel Landwerlin 
> Cc: Sirisha Gandikota 
> ---
>  tools/aubdump.c| 107 
> -
>  tools/intel_aubdump.in |  31 +-
>  2 files changed, 117 insertions(+), 21 deletions(-)
> 
> diff --git a/tools/aubdump.c b/tools/aubdump.c
> index 30dc742..3b85bc7 100644
> --- a/tools/aubdump.c
> +++ b/tools/aubdump.c
> @@ -50,6 +50,7 @@ static int (*libc_close)(int fd) = close_init_helper;
>  static int (*libc_ioctl)(int fd, unsigned long request, ...) = 
> ioctl_init_helper;
> 
>  static int drm_fd = -1;
> +static char *command;
>  static char *filename;
>  static FILE *file;
>  static int gen = 0;
> @@ -113,6 +114,82 @@ fail_if(int cond, const char *format, ...)
>   raise(SIGTRAP);
>  }
> 
> +static FILE *
> +launch_command(void)
> +{
> + int i = 0, fds[2];
> + char **args = calloc(strlen(command), sizeof(char *));
> + char *iter = command;
> +
> + args[i++] = iter = command;
> +
> + while ((iter = strstr(iter, ",")) != NULL) {
> + *iter = '\0';
> + iter += 1;
> + args[i++] = iter;
> + }
> +
> + if (pipe(fds) == -1)
> + return NULL;
> +
> + switch (fork()) {
> + case 0:
> + dup2(fds[0], 0);
> + fail_if(execv(args[0], args) == -1,
> + "intel_aubdump: fail to launch child command\n");
> + return NULL;
> +

Why not use execvp to avoid having to use an absolute path?

"failed" instead of "fail"


> + default:
> + free(args);
> + return fdopen(fds[1], "w");
> +
> + case -1:
> + return NULL;
> + }
> +}
> +
> +static void
> +maybe_init_output(void)
> +{
> + const char *args;
> + static bool initialized = false;
> + int nb_args;
> +
> + if (initialized)
> + return;
> +
> + args = getenv("INTEL_AUBDUMP_ARGS");
> +
> + nb_args = sscanf(args, 
> "verbose=%d;file=%m[^;];device=%i;command=%m[^;];",
> +  , , , );
> + if (nb_args != 4) {
> + if (filename)
> + free(filename);
> + nb_args = sscanf(args, "verbose=%d;file=%m[^;];device=%i;",
> +  , , );
> + command = strdup("");
> + }
> +fail_if(filename == NULL || command == NULL,
> +"intel_aubdump: out of memory\n");
> + if (device)
> + device_override = true;
> +

Indentation on that fail_if.


> + bos = malloc(MAX_BO_COUNT * sizeof(bos[0]));
> + fail_if(bos == NULL, "intel_aubdump: out of memory\n");
> +
> +if (strlen(command) != 0) {
> +  file = launch_command();
> +  fail_if(file == NULL,
> +  "intel_aubdump: failed to launch command '%s'\n", command);
> +} else {
> +  file = fopen(filename, "w+");
> +  fail_if(file == NULL,
> +  "intel_aubdump: failed to open file '%s'\n", filename);
> +}
> +
> + initialized = true;
> +}
> +

Indentation again.


>  static struct bo *
>  get_bo(uint32_t handle)
>  {
> @@ -140,13 +217,18 @@ align_u64(uint64_t v, uint64_t a)
>  static void
>  dword_out(uint32_t data)
>  {
> - fwrite(, 1, 4, file);
> + fail_if(fwrite(, 1, 4, file) == 0,
> + "Writing to output failed\n");
>  }
> 
>  static void
>  data_out(const void *data, size_t size)
>  {
> - fwrite(data, 1, size, file);
> + if (size == 0)
> + return;
> +
> + fail_if(fwrite(data, 1, size, file) == 0,
> + "Writing to output failed\n");
>  }
> 
>  static void
> @@ -447,6 +529,8 @@ ioctl(int fd, unsigned long request, ...)
>   }
> 
>   if (fd == drm_fd) {
> + maybe_init_output();
> +
>   switch (request) {
>   case DRM_IOCTL_I915_GETPARAM: {
>   struct drm_i915_getparam *getparam = argp;
> @@ -550,26 +634,8 @@ ioctl(int fd, unsigned long request, ...)
>  static void
>  init(void)
>  {
> - const char *args = getenv("INTEL_AUBDUMP_ARGS");
> -
>   libc_close = dlsym(RTLD_NEXT, "close");
>   libc_ioctl = dlsym(RTLD_NEXT, "ioctl");
> - fail_if(libc_close == NULL || libc_ioctl == NULL,
> - "intel_aubdump: failed to get libc ioctl or close\n");
> -
> - if (sscanf(args, "verbose=%d;file=%m[^;];device=%i",
> -, , ) != 3)
> - filename = strdup("intel.aub");
> - fail_if(filename == NULL, "intel_aubdump: out of memory\n");
> -
> - if (device)
> - device_override = true;
> 

[Intel-gfx] [PATCH v3 i-g-t] aubdump: add --command option to stream aubdump to another program

[Lionel Landwerlin]

This comes handy if you want to look at your application output without
having to save it into a file. For example, use this with aubinator from
Mesa :

$ intel_aubdump -c '/path/to/aubinator --gen=hsw' my_gl_app

v2: Fix handling empty command line option

v3: Fix command line concatenation (again...)

Signed-off-by: Lionel Landwerlin 
Cc: Sirisha Gandikota 
---
 tools/aubdump.c| 107 -
 tools/intel_aubdump.in |  31 +-
 2 files changed, 117 insertions(+), 21 deletions(-)

diff --git a/tools/aubdump.c b/tools/aubdump.c
index 30dc742..3b85bc7 100644
--- a/tools/aubdump.c
+++ b/tools/aubdump.c
@@ -50,6 +50,7 @@ static int (*libc_close)(int fd) = close_init_helper;
 static int (*libc_ioctl)(int fd, unsigned long request, ...) = 
ioctl_init_helper;

 static int drm_fd = -1;
+static char *command;
 static char *filename;
 static FILE *file;
 static int gen = 0;
@@ -113,6 +114,82 @@ fail_if(int cond, const char *format, ...)
raise(SIGTRAP);
 }

+static FILE *
+launch_command(void)
+{
+   int i = 0, fds[2];
+   char **args = calloc(strlen(command), sizeof(char *));
+   char *iter = command;
+
+   args[i++] = iter = command;
+
+   while ((iter = strstr(iter, ",")) != NULL) {
+   *iter = '\0';
+   iter += 1;
+   args[i++] = iter;
+   }
+
+   if (pipe(fds) == -1)
+   return NULL;
+
+   switch (fork()) {
+   case 0:
+   dup2(fds[0], 0);
+   fail_if(execv(args[0], args) == -1,
+   "intel_aubdump: fail to launch child command\n");
+   return NULL;
+
+   default:
+   free(args);
+   return fdopen(fds[1], "w");
+
+   case -1:
+   return NULL;
+   }
+}
+
+static void
+maybe_init_output(void)
+{
+   const char *args;
+   static bool initialized = false;
+   int nb_args;
+
+   if (initialized)
+   return;
+
+   args = getenv("INTEL_AUBDUMP_ARGS");
+
+   nb_args = sscanf(args, 
"verbose=%d;file=%m[^;];device=%i;command=%m[^;];",
+, , , );
+   if (nb_args != 4) {
+   if (filename)
+   free(filename);
+   nb_args = sscanf(args, "verbose=%d;file=%m[^;];device=%i;",
+, , );
+   command = strdup("");
+   }
+fail_if(filename == NULL || command == NULL,
+"intel_aubdump: out of memory\n");
+   if (device)
+   device_override = true;
+
+   bos = malloc(MAX_BO_COUNT * sizeof(bos[0]));
+   fail_if(bos == NULL, "intel_aubdump: out of memory\n");
+
+if (strlen(command) != 0) {
+  file = launch_command();
+  fail_if(file == NULL,
+  "intel_aubdump: failed to launch command '%s'\n", command);
+} else {
+  file = fopen(filename, "w+");
+  fail_if(file == NULL,
+  "intel_aubdump: failed to open file '%s'\n", filename);
+}
+
+   initialized = true;
+}
+
 static struct bo *
 get_bo(uint32_t handle)
 {
@@ -140,13 +217,18 @@ align_u64(uint64_t v, uint64_t a)
 static void
 dword_out(uint32_t data)
 {
-   fwrite(, 1, 4, file);
+   fail_if(fwrite(, 1, 4, file) == 0,
+   "Writing to output failed\n");
 }

 static void
 data_out(const void *data, size_t size)
 {
-   fwrite(data, 1, size, file);
+   if (size == 0)
+   return;
+
+   fail_if(fwrite(data, 1, size, file) == 0,
+   "Writing to output failed\n");
 }

 static void
@@ -447,6 +529,8 @@ ioctl(int fd, unsigned long request, ...)
}

if (fd == drm_fd) {
+   maybe_init_output();
+
switch (request) {
case DRM_IOCTL_I915_GETPARAM: {
struct drm_i915_getparam *getparam = argp;
@@ -550,26 +634,8 @@ ioctl(int fd, unsigned long request, ...)
 static void
 init(void)
 {
-   const char *args = getenv("INTEL_AUBDUMP_ARGS");
-
libc_close = dlsym(RTLD_NEXT, "close");
libc_ioctl = dlsym(RTLD_NEXT, "ioctl");
-   fail_if(libc_close == NULL || libc_ioctl == NULL,
-   "intel_aubdump: failed to get libc ioctl or close\n");
-
-   if (sscanf(args, "verbose=%d;file=%m[^;];device=%i",
-  , , ) != 3)
-   filename = strdup("intel.aub");
-   fail_if(filename == NULL, "intel_aubdump: out of memory\n");
-
-   if (device)
-   device_override = true;
-
-   bos = malloc(MAX_BO_COUNT * sizeof(bos[0]));
-   fail_if(bos == NULL, "intel_aubdump: out of memory\n");
-
-   file = fopen(filename, "w+");
-   fail_if(file == NULL, "intel_aubdump: failed to open file '%s'\n", 
filename);
 }

 static int
@@ -596,6 +662,7 @@ ioctl_init_helper(int fd, unsigned long request, ...)
 static void 

Re: [Intel-gfx] [Regression report] Weekly regression report WW40

[Jani Nikula]

On Wed, 05 Oct 2016, "Argotti, Yann"  wrote:
>> > On Mon, 03 Oct 2016, Jairo Miramontes
>> >  wrote:
>> > > This week regressions
>> >
>> > In the past we used "regression", "bisect_pending", and "bisected" in
>> > the bugzilla "Keywords" field. Can we start using those again, please?
>> 
>> I think this is a very good idea Jani. So we can start to scrub current
>> regression (and then igt linked one) and update accordingly.
>> Yann
>
> Two additional thoughts are:
> - add "regression_pending" (vs "regression") as well as keyword to
> indicate where bug reporter has doubt on the fact it is or not a
> regression.

I think it should be enough, at least for a start (or should I say
re-start), to freely use "regression" when things worked in the past but
do not work anymore. We can then drop the keyword if it's not proven to
be a regression.

No strong feelings on "regression_pending", though. But I don't think
you can add keywords at will, I think the field only accepts a
predefined set of keywords. So you'd need to talk to Ander or Martin
(Cc'd) to get the new one to bugzilla.

> - either use of "regression" or "regression_pending" must be coming
> with good & bad commit when reporting the bug

Agreed.

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 2/2] drm/i915: Sort DEV_INFO_FOR_EACH_FLAG

[Tvrtko Ursulin]

On 04/10/2016 14:32, Chris Wilson wrote:

On Tue, Oct 04, 2016 at 03:42:58PM +0300, Joonas Lahtinen wrote:

Sort DEV_INFO_FOR_EACH_FLAG to alphabetical order (except is_*).

Signed-off-by: Joonas Lahtinen 

Ok. Looks like it should be easier to read.
Reviewed-by: Chris Wilson 

Could you add something like:

/* Keep is_* in chronological order */

/* Keep has_* in alphabetical order */
...


You could also push is_mobile and is_preliminary to the end of the is_ 
block which would be a micro-opt for the "IS_SKYLAKE || IS_KABYLAKE" 
code and similar for the checks for the earlier hardware. If flags for 
things of similar age end up in the same byte then checking for compound 
conditions is shorter. :) As it stands they are just split across byte 
boundaries. :))


Regards,

Tvrtko

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/9] drm/i915: Create a struct to hold information about the broxton phys

[Imre Deak]

On to, 2016-10-06 at 12:56 +0300, Imre Deak wrote:
> On ke, 2016-10-05 at 15:09 +0300, Ander Conselvan de Oliveira wrote:
> > Information about which phy is dual channel is hardcoded in the phy
> > init
> > sequence. Split that to a separate struct so the init sequence is
> > more
> > generic.
> > 
> > Signed-off-by: Ander Conselvan de Oliveira 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h   |  9 +++--
> >  drivers/gpu/drm/i915/intel_dpio_phy.c | 63
> > +--
> >  2 files changed, 60 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index f6d29fb..d3802c6 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1308,8 +1308,13 @@ enum skl_disp_power_wells {
> >  #define BXT_PORT_CL1CM_DW30(phy)   _BXT_PHY((phy),
> > _PORT_CL1CM_DW30_BC, \
> >     _PORT_CL1C
> > M_DW30_A)
> >  
> > -/* Defined for PHY0 only */
> > -#define BXT_PORT_CL2CM_DW6_BC  _MMIO(0x6C358)
> > +/* The spec defines this only for BXT PHY0, but lets assume that
> > this
> > + * would exist for PHY1 too if it had a second channel.
> > + */
> > +#define _PORT_CL2CM_DW6_A  0x162358
> > +#define _PORT_CL2CM_DW6_BC 0x6C358
> > +#define BXT_PORT_CL2CM_DW6(phy)_BXT_PHY((phy),
> > _PORT_CL2CM_DW6_BC, \
> > +   _PORT_CL2C
> > M_DW6_A)
> >  #define   DW6_OLDO_DYN_PWR_DOWN_EN (1 << 28)
> >  
> >  /* BXT PHY Ref registers */
> > diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c
> > b/drivers/gpu/drm/i915/intel_dpio_phy.c
> > index 2a18724..66d750a 100644
> > --- a/drivers/gpu/drm/i915/intel_dpio_phy.c
> > +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
> > @@ -114,6 +114,49 @@
> >   * -
> >   */
> >  
> > +/**
> > + * struct bxt_ddi_phy_info - Hold info for a broxton DDI phy
> > + */
> > +struct bxt_ddi_phy_info {
> > +   /**
> > +    * @dual_channel: true if this phy has a second channel.
> > +    */
> > +   bool dual_channel;
> > +
> > +   /**
> > +    * @channel: struct containing per channel information.
> > +    */
> > +   struct {
> > +   /**
> > +    * @port: which port maps to this channel.
> > +    */
> > +   enum port port;
> > +   } channel[2];
> 
> Nitpick: could this be just a port mask?

Ah, just noticed in patch 9 that it cannot, so ignore the above.

> 
> Patches 1-8 look good to me, with or without the nit changes on
> those:
> Reviewed-by: Imre Deak 
> 
> > +};
> > +
> > +static const struct bxt_ddi_phy_info bxt_ddi_phy_info[] = {
> > +   [DPIO_PHY0] = {
> > +   .dual_channel = true,
> > +
> > +   .channel = {
> > +   [DPIO_CH0] = { .port = PORT_B },
> > +   [DPIO_CH1] = { .port = PORT_C },
> > +   }
> > +   },
> > +   [DPIO_PHY1] = {
> > +   .dual_channel = false,
> > +
> > +   .channel = {
> > +   [DPIO_CH0] = { .port = PORT_A },
> > +   }
> > +   },
> > +};
> > +
> > +{
> > +   return (phy_info->dual_channel * BIT(phy_info-
> > >channel[DPIO_CH1].port)) |
> > +   BIT(phy_info->channel[DPIO_CH0].port);
> > +}
> > +
> >  void bxt_ddi_phy_set_signal_level(struct drm_i915_private
> > *dev_priv,
> >       enum port port, u32 margin, u32
> > scale,
> >       u32 enable, u32 deemphasis)
> > @@ -183,9 +226,7 @@ bool bxt_ddi_phy_is_enabled(struct
> > drm_i915_private *dev_priv,
> >     return false;
> >     }
> >  
> > -   for_each_port_masked(port,
> > -    phy == DPIO_PHY0 ? BIT(PORT_B) |
> > BIT(PORT_C) :
> > -   BIT(PORT_A)) {
> > +   for_each_port_masked(port, bxt_phy_port_mask(phy_info)) {
> >     u32 tmp = I915_READ(BXT_PHY_CTL(port));
> >  
> >     if (tmp & BXT_PHY_CMNLANE_POWERDOWN_ACK) {
> > @@ -220,6 +261,7 @@ static void bxt_phy_wait_grc_done(struct
> > drm_i915_private *dev_priv,
> >  
> >  void bxt_ddi_phy_init(struct drm_i915_private *dev_priv, enum
> > dpio_phy phy)
> >  {
> > +   const struct bxt_ddi_phy_info *phy_info =
> > _ddi_phy_info[phy];
> >     u32 val;
> >  
> >     if (bxt_ddi_phy_is_enabled(dev_priv, phy)) {
> > @@ -272,10 +314,10 @@ void bxt_ddi_phy_init(struct drm_i915_private
> > *dev_priv, enum dpio_phy phy)
> >     SUS_CLK_CONFIG;
> >     I915_WRITE(BXT_PORT_CL1CM_DW28(phy), val);
> >  
> > -   if (phy == DPIO_PHY0) {
> > -   val = I915_READ(BXT_PORT_CL2CM_DW6_BC);
> > +   if (phy_info->dual_channel) {
> > +   val = I915_READ(BXT_PORT_CL2CM_DW6(phy));
> >     val |= DW6_OLDO_DYN_PWR_DOWN_EN;
> > -   I915_WRITE(BXT_PORT_CL2CM_DW6_BC, val);
> > +   I915_WRITE(BXT_PORT_CL2CM_DW6(phy), val);
> >     }
> >  
> >     val = I915_READ(BXT_PORT_CL1CM_DW30(phy));
> > @@ -290,7 +332,7 

Re: [Intel-gfx] [PATCH v2 07/15] drm/omap: Use per-plane rotation property

[Tomi Valkeinen]

On 26/09/16 19:30, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> The global mode_config.rotation_property is going away, switch over to
> per-plane rotation_property.
> 
> Not sure I got the annoying crtc rotation_property handling right.
> Might work, or migth not.
> 
> v2: Drop the BIT()
> Don't create rotation property twice for each primary plane
> 
> Cc: Tomi Valkeinen 
> Cc: Rob Clark 
> Signed-off-by: Ville Syrjälä 
> ---


> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
> b/drivers/gpu/drm/omapdrm/omap_plane.c
> index 6ddaa5ea4b6b..b272f810989e 100644
> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
> @@ -211,9 +211,16 @@ void omap_plane_install_properties(struct drm_plane 
> *plane,
>   struct omap_drm_private *priv = dev->dev_private;
>  
>   if (priv->has_dmm) {
> - struct drm_property *prop = dev->mode_config.rotation_property;
> -
> - drm_object_attach_property(obj, prop, DRM_ROTATE_0);
> + if (!plane->rotation_property)
> + drm_plane_create_rotation_property(plane,
> +DRM_ROTATE_0,
> +DRM_ROTATE_0 | 
> DRM_ROTATE_90 |
> +DRM_ROTATE_180 | 
> DRM_ROTATE_270 |
> +DRM_REFLECT_X | 
> DRM_REFLECT_Y);
> +
> + if (plane->rotation_property && obj != >base)
> + drm_object_attach_property(obj, 
> plane->rotation_property,
> +DRM_ROTATE_0);

I think this could use a short comment, as it's not obvious wth is going
on here =).

Otherwise both omap patches look fine, and test fine.

Reviewed-by: Tomi Valkeinen 

 Tomi



signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/9] drm/i915: Create a struct to hold information about the broxton phys

[Imre Deak]

On ke, 2016-10-05 at 15:09 +0300, Ander Conselvan de Oliveira wrote:
> Information about which phy is dual channel is hardcoded in the phy init
> sequence. Split that to a separate struct so the init sequence is more
> generic.
> 
> Signed-off-by: Ander Conselvan de Oliveira 
> ---
>  drivers/gpu/drm/i915/i915_reg.h   |  9 +++--
>  drivers/gpu/drm/i915/intel_dpio_phy.c | 63 
> +--
>  2 files changed, 60 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index f6d29fb..d3802c6 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1308,8 +1308,13 @@ enum skl_disp_power_wells {
>  #define BXT_PORT_CL1CM_DW30(phy) _BXT_PHY((phy), _PORT_CL1CM_DW30_BC, \
>   _PORT_CL1CM_DW30_A)
>  
> -/* Defined for PHY0 only */
> -#define BXT_PORT_CL2CM_DW6_BC_MMIO(0x6C358)
> +/* The spec defines this only for BXT PHY0, but lets assume that this
> + * would exist for PHY1 too if it had a second channel.
> + */
> +#define _PORT_CL2CM_DW6_A0x162358
> +#define _PORT_CL2CM_DW6_BC   0x6C358
> +#define BXT_PORT_CL2CM_DW6(phy)  _BXT_PHY((phy), 
> _PORT_CL2CM_DW6_BC, \
> + _PORT_CL2CM_DW6_A)
>  #define   DW6_OLDO_DYN_PWR_DOWN_EN   (1 << 28)
>  
>  /* BXT PHY Ref registers */
> diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
> b/drivers/gpu/drm/i915/intel_dpio_phy.c
> index 2a18724..66d750a 100644
> --- a/drivers/gpu/drm/i915/intel_dpio_phy.c
> +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
> @@ -114,6 +114,49 @@
>   * -
>   */
>  
> +/**
> + * struct bxt_ddi_phy_info - Hold info for a broxton DDI phy
> + */
> +struct bxt_ddi_phy_info {
> + /**
> +  * @dual_channel: true if this phy has a second channel.
> +  */
> + bool dual_channel;
> +
> + /**
> +  * @channel: struct containing per channel information.
> +  */
> + struct {
> + /**
> +  * @port: which port maps to this channel.
> +  */
> + enum port port;
> + } channel[2];

Nitpick: could this be just a port mask?

Patches 1-8 look good to me, with or without the nit changes on those:
Reviewed-by: Imre Deak 

> +};
> +
> +static const struct bxt_ddi_phy_info bxt_ddi_phy_info[] = {
> + [DPIO_PHY0] = {
> + .dual_channel = true,
> +
> + .channel = {
> + [DPIO_CH0] = { .port = PORT_B },
> + [DPIO_CH1] = { .port = PORT_C },
> + }
> + },
> + [DPIO_PHY1] = {
> + .dual_channel = false,
> +
> + .channel = {
> + [DPIO_CH0] = { .port = PORT_A },
> + }
> + },
> +};
> +
> +{
> + return (phy_info->dual_channel * BIT(phy_info->channel[DPIO_CH1].port)) 
> |
> + BIT(phy_info->channel[DPIO_CH0].port);
> +}
> +
>  void bxt_ddi_phy_set_signal_level(struct drm_i915_private *dev_priv,
>     enum port port, u32 margin, u32 scale,
>     u32 enable, u32 deemphasis)
> @@ -183,9 +226,7 @@ bool bxt_ddi_phy_is_enabled(struct drm_i915_private 
> *dev_priv,
>   return false;
>   }
>  
> - for_each_port_masked(port,
> -  phy == DPIO_PHY0 ? BIT(PORT_B) | BIT(PORT_C) :
> - BIT(PORT_A)) {
> + for_each_port_masked(port, bxt_phy_port_mask(phy_info)) {
>   u32 tmp = I915_READ(BXT_PHY_CTL(port));
>  
>   if (tmp & BXT_PHY_CMNLANE_POWERDOWN_ACK) {
> @@ -220,6 +261,7 @@ static void bxt_phy_wait_grc_done(struct drm_i915_private 
> *dev_priv,
>  
>  void bxt_ddi_phy_init(struct drm_i915_private *dev_priv, enum dpio_phy phy)
>  {
> + const struct bxt_ddi_phy_info *phy_info = _ddi_phy_info[phy];
>   u32 val;
>  
>   if (bxt_ddi_phy_is_enabled(dev_priv, phy)) {
> @@ -272,10 +314,10 @@ void bxt_ddi_phy_init(struct drm_i915_private 
> *dev_priv, enum dpio_phy phy)
>   SUS_CLK_CONFIG;
>   I915_WRITE(BXT_PORT_CL1CM_DW28(phy), val);
>  
> - if (phy == DPIO_PHY0) {
> - val = I915_READ(BXT_PORT_CL2CM_DW6_BC);
> + if (phy_info->dual_channel) {
> + val = I915_READ(BXT_PORT_CL2CM_DW6(phy));
>   val |= DW6_OLDO_DYN_PWR_DOWN_EN;
> - I915_WRITE(BXT_PORT_CL2CM_DW6_BC, val);
> + I915_WRITE(BXT_PORT_CL2CM_DW6(phy), val);
>   }
>  
>   val = I915_READ(BXT_PORT_CL1CM_DW30(phy));
> @@ -290,7 +332,7 @@ void bxt_ddi_phy_init(struct drm_i915_private *dev_priv, 
> enum dpio_phy phy)
>    * FIXME: Clarify programming of the following, the register is
>    * read-only with bit 6 fixed at 0 at least in stepping A.
>    */
> - if (phy == DPIO_PHY1)
> + if (!phy_info->dual_channel)
>    

Re: [Intel-gfx] [PATCH] tests/igt: dmesg noise is a kernel failure

[Ville Syrjälä]

On Thu, Oct 06, 2016 at 11:07:17AM +0200, Daniel Vetter wrote:
> At least when testing the kernel. In normal programs pretty much all
> the dmesg noise would simply be replaced by debug asserts, but in the
> kernel we try rely hard to not fall over minor inconsistencies.
> 
> Still for CI purposes there's not really a difference, hence don't
> treat it as such.
> 
> Motivated since once again I've seen a statistics where this was split
> up, and then a reduction of "failures" (but in reality just trading
> them in for more "warnings") praised as success.
> 
> Cc: jari.tahvanai...@intel.com
> Cc: Petri Latvala 
> Signed-off-by: Daniel Vetter 
> ---
>  tests/igt.py | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/tests/igt.py b/tests/igt.py
> index 7ebb03646b50..473027b76936 100644
> --- a/tests/igt.py
> +++ b/tests/igt.py
> @@ -53,6 +53,7 @@ def check_environment():
>  
>  """
>  debugfs_path = "/sys/kernel/debug/dri"
> +
>  if os.getuid() != 0:
>  raise exceptions.PiglitInternalError(
>  "Test Environment check: not root!")
> @@ -123,6 +124,10 @@ class IGTTest(Test):
>  else:
>  self.result.result = 'fail'
>  
> +# all dmesg noise is considered a test failure when testing the 
> kernel
> +if self.result.dmesg
> +self.result.result = 'fail'

Hmm. So now all errors will look the same? I think I'm usually more
interested in the dmesg warns, so this would perhaps make it harder for
me to spot them. Not sure I like that.

> +
>  
>  def list_tests(listname):
>  """Parse igt test list and return them as a list."""
> -- 
> 2.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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 9/9] drm/i915: Address broxton phy registers based on phy and channel number

[Imre Deak]

On ke, 2016-10-05 at 15:09 +0300, Ander Conselvan de Oliveira wrote:
> The port registers related to the phys in broxton map to different
> channels and specific phys. Make that mapping explicit.
> 
> Signed-off-by: Ander Conselvan de Oliveira 
> ---
>  drivers/gpu/drm/i915/i915_drv.h   |   2 +
>  drivers/gpu/drm/i915/i915_reg.h   | 211 
> +-
>  drivers/gpu/drm/i915/intel_dpio_phy.c | 131 +++--
>  drivers/gpu/drm/i915/intel_dpll_mgr.c |  84 --
>  4 files changed, 222 insertions(+), 206 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 77f1374..c3fa29a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3735,6 +3735,8 @@ u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, 
> u32 reg);
>  void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
>  
>  /* intel_dpio_phy.c */
> +void bxt_port_to_phy_channel(enum port port,
> +  u32 *phy, enum dpio_channel *ch);
>  void bxt_ddi_phy_set_signal_level(struct drm_i915_private *dev_priv,
>     enum port port, u32 margin, u32 scale,
>     u32 enable, u32 deemphasis);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index d3802c6..416cbb1 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1187,6 +1187,9 @@ enum skl_disp_power_wells {
>  #define   DPIO_UPAR_SHIFT30
>  
>  /* BXT PHY registers */
> +#define BXT_PHY1_BASE0x162000
> +#define BXT_PHY0_BASE0x6C000
> +
>  #define _BXT_PHY(phy, a, b)  _MMIO_PIPE((phy), (a), (b))
>  
>  #define BXT_P_CR_GT_DISP_PWRON   _MMIO(0x138090)
> @@ -1216,31 +1219,26 @@ enum skl_disp_power_wells {
>  #define   PORT_PLL_REF_SEL   (1 << 27)
>  #define BXT_PORT_PLL_ENABLE(port)_MMIO_PORT(port, _PORT_PLL_A, 
> _PORT_PLL_B)
>  
> -#define _PORT_PLL_EBB_0_A0x162034
> -#define _PORT_PLL_EBB_0_B0x6C034
> -#define _PORT_PLL_EBB_0_C0x6C340
> +#define _PORT_PLL_EBB_0_CH0  0x34
> +#define _PORT_PLL_EBB_0_CH1  0x340
>  #define   PORT_PLL_P1_SHIFT  13
>  #define   PORT_PLL_P1_MASK   (0x07 << PORT_PLL_P1_SHIFT)
>  #define   PORT_PLL_P1(x) ((x)  << PORT_PLL_P1_SHIFT)
>  #define   PORT_PLL_P2_SHIFT  8
>  #define   PORT_PLL_P2_MASK   (0x1f << PORT_PLL_P2_SHIFT)
>  #define   PORT_PLL_P2(x) ((x)  << PORT_PLL_P2_SHIFT)
> -#define BXT_PORT_PLL_EBB_0(port) _MMIO_PORT3(port, _PORT_PLL_EBB_0_A, \
> - _PORT_PLL_EBB_0_B,  \
> - _PORT_PLL_EBB_0_C)
> +#define BXT_PORT_PLL_EBB_0(base, ch) \
> + _MMIO((base) + _PIPE((ch), _PORT_PLL_EBB_0_CH0, _PORT_PLL_EBB_0_CH1))

Passing the phy and calculating the base here would be more natural.
Also we should try to preserve bspec reg names and addresses to make
lookup easier. You could do that by using _PORT_PLL_EBB_0_B
and _PORT_PLL_EBB_0_C here and adjusting the base by -BXT_PHY0_BASE.
I'd also leave _PORT_PLL_EBB_0_A around for reference.

>  
> -#define _PORT_PLL_EBB_4_A0x162038
> -#define _PORT_PLL_EBB_4_B0x6C038
> -#define _PORT_PLL_EBB_4_C0x6C344
> +#define _PORT_PLL_EBB_4_CH0  0x38
> +#define _PORT_PLL_EBB_4_CH1  0x344
>  #define   PORT_PLL_10BIT_CLK_ENABLE  (1 << 13)
>  #define   PORT_PLL_RECALIBRATE   (1 << 14)
> -#define BXT_PORT_PLL_EBB_4(port) _MMIO_PORT3(port, _PORT_PLL_EBB_4_A, \
> - _PORT_PLL_EBB_4_B,  \
> - _PORT_PLL_EBB_4_C)
> +#define BXT_PORT_PLL_EBB_4(base, ch) \
> + _MMIO((base) + _PIPE((ch), _PORT_PLL_EBB_4_CH0, _PORT_PLL_EBB_4_CH1))
>  
> -#define _PORT_PLL_0_A0x162100
> -#define _PORT_PLL_0_B0x6C100
> -#define _PORT_PLL_0_C0x6C380
> +#define _PORT_PLL_0_CH0  0x100
> +#define _PORT_PLL_0_CH1  0x380
>  /* PORT_PLL_0_A */
>  #define   PORT_PLL_M2_MASK   0xFF
>  /* PORT_PLL_1_A */
> @@ -1267,65 +1265,43 @@ enum skl_disp_power_wells {
>  #define  PORT_PLL_DCO_AMP_DEFAULT15
>  #define  PORT_PLL_DCO_AMP_MASK   0x3c00
>  #define  PORT_PLL_DCO_AMP(x) ((x)<<10)
> -#define _PORT_PLL_BASE(port) _PORT3(port, _PORT_PLL_0_A, \
> - _PORT_PLL_0_B,  \
> - _PORT_PLL_0_C)
> -#define BXT_PORT_PLL(port, idx)  _MMIO(_PORT_PLL_BASE(port) + 
> (idx) * 4)
> +#define _PORT_PLL_BASE(base, ch) \
> + ((base) + _PIPE((ch), _PORT_PLL_0_CH0, _PORT_PLL_0_CH1))
> +#define 

Re: [Intel-gfx] [PATCH i-g-t v2] tests: Add explicit test lists for CI use.

[Lionel Landwerlin]

Regardless of the list of tests we expect to pass, I think it's better 
to have an actual list rather than relying on the name of the tests (as 
we have been doing or are still doing, correct me if I'm wrong).


Thanks for doing this!

Acked-by: Lionel Landwerlin 

On 06/10/16 09:54, Petri Latvala wrote:

See tests/intel-ci/README for rationale and explanation.

v2: Use the current BAT set for fast-feedback.testlist first

Signed-off-by: Petri Latvala 
---

Thanks for the feedback. This commit only contains the current test
set, extended test suites are left for future discussion.


  tests/intel-ci/README |  34 +
  tests/intel-ci/fast-feedback.testlist | 248 ++
  2 files changed, 282 insertions(+)
  create mode 100644 tests/intel-ci/README
  create mode 100644 tests/intel-ci/fast-feedback.testlist

diff --git a/tests/intel-ci/README b/tests/intel-ci/README
new file mode 100644
index 000..dc7e5c8
--- /dev/null
+++ b/tests/intel-ci/README
@@ -0,0 +1,34 @@
+This directory contains test lists that are used by Intel's CI. The
+files are passed to piglit with the --test-list parameter directly.
+
+The test lists are contained in the IGT repository for several
+reasons:
+
+- The lists stay synchronized with the IGT codebase.
+- Public availability. Kernel developers can see what tests are run,
+  and can see what changes are done to the set, when, and why.
+- Explicit test lists in general make it possible to implement a new
+  test without having it run in CI (accidentally or on purpose) before
+  CI is ready for it, and for CI to stop running a test without
+  removing the test or changing its name. The previous method of test
+  selection was based on name patterns.
+
+Changing the test lists should only happen with approval from the CI
+people. If you make a new test that should be tested by CI regularly,
+ask a maintainer (see MAINTAINERS).
+
+==
+fast-feedback.testlist
+==
+
+Fast-feedback is the testlist that is run for Patchwork and Trybot
+testing. It is also run on various drm-intel-* branches.
+
+Time limit: Full run must complete in 15 minutes on all tested
+platforms.
+
+Feature coverage: Should test all working features, with at least 1
+test per feature.
+
+The string "basic" in a test name means the test probably belongs in
+this list.
diff --git a/tests/intel-ci/fast-feedback.testlist 
b/tests/intel-ci/fast-feedback.testlist
new file mode 100644
index 000..ae94381
--- /dev/null
+++ b/tests/intel-ci/fast-feedback.testlist
@@ -0,0 +1,248 @@
+igt@core_auth@basic-auth
+igt@core_prop_blob@basic
+igt@drv_getparams_basic@basic-eu-total
+igt@drv_getparams_basic@basic-subslice-total
+igt@drv_hangman@error-state-basic
+igt@drv_module_reload_basic
+igt@gem_basic@bad-close
+igt@gem_basic@create-close
+igt@gem_basic@create-fd-close
+igt@gem_busy@basic-busy-default
+igt@gem_busy@basic-hang-default
+igt@gem_close_race@basic-process
+igt@gem_close_race@basic-threads
+igt@gem_cpu_reloc@basic
+igt@gem_cs_tlb@basic-default
+igt@gem_ctx_basic
+igt@gem_ctx_create@basic
+igt@gem_ctx_create@basic-files
+igt@gem_ctx_exec@basic
+igt@gem_ctx_param@basic
+igt@gem_ctx_param@basic-default
+igt@gem_ctx_switch@basic-default
+igt@gem_ctx_switch@basic-default-heavy
+igt@gem_exec_basic@basic-blt
+igt@gem_exec_basic@basic-bsd
+igt@gem_exec_basic@basic-bsd1
+igt@gem_exec_basic@basic-bsd2
+igt@gem_exec_basic@basic-default
+igt@gem_exec_basic@basic-render
+igt@gem_exec_basic@basic-vebox
+igt@gem_exec_basic@gtt-blt
+igt@gem_exec_basic@gtt-bsd
+igt@gem_exec_basic@gtt-bsd1
+igt@gem_exec_basic@gtt-bsd2
+igt@gem_exec_basic@gtt-default
+igt@gem_exec_basic@gtt-render
+igt@gem_exec_basic@gtt-vebox
+igt@gem_exec_basic@readonly-blt
+igt@gem_exec_basic@readonly-bsd
+igt@gem_exec_basic@readonly-bsd1
+igt@gem_exec_basic@readonly-bsd2
+igt@gem_exec_basic@readonly-default
+igt@gem_exec_basic@readonly-render
+igt@gem_exec_basic@readonly-vebox
+igt@gem_exec_create@basic
+igt@gem_exec_flush@basic-batch-kernel-default-cmd
+igt@gem_exec_flush@basic-batch-kernel-default-uc
+igt@gem_exec_flush@basic-batch-kernel-default-wb
+igt@gem_exec_flush@basic-uc-pro-default
+igt@gem_exec_flush@basic-uc-prw-default
+igt@gem_exec_flush@basic-uc-ro-default
+igt@gem_exec_flush@basic-uc-rw-default
+igt@gem_exec_flush@basic-uc-set-default
+igt@gem_exec_flush@basic-wb-pro-default
+igt@gem_exec_flush@basic-wb-prw-default
+igt@gem_exec_flush@basic-wb-ro-before-default
+igt@gem_exec_flush@basic-wb-ro-default
+igt@gem_exec_flush@basic-wb-rw-before-default
+igt@gem_exec_flush@basic-wb-rw-default
+igt@gem_exec_flush@basic-wb-set-default
+igt@gem_exec_gttfill@basic
+igt@gem_exec_nop@basic-parallel
+igt@gem_exec_nop@basic-series
+igt@gem_exec_parallel@basic
+igt@gem_exec_parse@basic-allowed
+igt@gem_exec_parse@basic-rejected
+igt@gem_exec_store@basic-all
+igt@gem_exec_store@basic-blt
+igt@gem_exec_store@basic-bsd

Re: [Intel-gfx] [PATCH] tests/igt: dmesg noise is a kernel failure

[Chris Wilson]

On Thu, Oct 06, 2016 at 11:07:17AM +0200, Daniel Vetter wrote:
> At least when testing the kernel. In normal programs pretty much all
> the dmesg noise would simply be replaced by debug asserts, but in the
> kernel we try rely hard to not fall over minor inconsistencies.
> 
> Still for CI purposes there's not really a difference, hence don't
> treat it as such.
> 
> Motivated since once again I've seen a statistics where this was split
> up, and then a reduction of "failures" (but in reality just trading
> them in for more "warnings") praised as success.

Hear, hear! dfail == fail, and dwarn == warn.

Calling a failure, a dfail just softens that it failed.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 1/2] aubdump: remove already handled -o

[Lionel Landwerlin]

On 06/10/16 10:09, Petri Latvala wrote:

On Wed, Oct 05, 2016 at 11:48:26PM +0100, Lionel Landwerlin wrote:

- -o*)
- file=${1##-o}
- shift
- ;;


This breaks using -ofilename without spaces.




Oh right, I didn't realize that was an acceptable input.
Let's drop this patch then.

Thanks!

-
Lionel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Reset the breadcrumbs IRQ more carefully

[Chris Wilson]

Along with the interrupt, we want to restore the fake-irq and
wait-timeout detection. If we use the breadcrumbs interface to setup the
interrupt as it wants, the auxiliary timers will also be restored.

Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 17 +
 drivers/gpu/drm/i915/intel_engine_cs.c   | 15 ---
 drivers/gpu/drm/i915/intel_lrc.c |  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c  |  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |  2 +-
 5 files changed, 20 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 9dba4971fb1e..d27da6d69735 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -584,6 +584,23 @@ int intel_engine_init_breadcrumbs(struct intel_engine_cs 
*engine)
return 0;
 }
 
+void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine)
+{
+   struct intel_breadcrumbs *b = >breadcrumbs;
+
+   clear_bit(engine->id, >i915->gpu_error.missed_irq_rings);
+
+   spin_lock(>lock);
+
+   __intel_breadcrumbs_disable_irq(b);
+   if (intel_engine_has_waiter(engine)) {
+   b->timeout = wait_timeout();
+   __intel_breadcrumbs_enable_irq(b);
+   }
+
+   spin_unlock(>lock);
+}
+
 void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine)
 {
struct intel_breadcrumbs *b = >breadcrumbs;
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index c8ac72ba4000..755f1a8b76d8 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -210,9 +210,6 @@ void intel_engine_init_global_seqno(struct intel_engine_cs 
*engine, u32 seqno)
 void intel_engine_init_hangcheck(struct intel_engine_cs *engine)
 {
memset(>hangcheck, 0, sizeof(engine->hangcheck));
-   clear_bit(engine->id, >i915->gpu_error.missed_irq_rings);
-   if (intel_engine_has_waiter(engine))
-   i915_queue_hangcheck(engine->i915);
 }
 
 static void intel_engine_init_timeline(struct intel_engine_cs *engine)
@@ -308,18 +305,6 @@ int intel_engine_init_common(struct intel_engine_cs 
*engine)
return 0;
 }
 
-void intel_engine_reset_irq(struct intel_engine_cs *engine)
-{
-   struct drm_i915_private *dev_priv = engine->i915;
-
-   spin_lock_irq(_priv->irq_lock);
-   if (intel_engine_has_waiter(engine))
-   engine->irq_enable(engine);
-   else
-   engine->irq_disable(engine);
-   spin_unlock_irq(_priv->irq_lock);
-}
-
 /**
  * intel_engines_cleanup_common - cleans up the engine state created by
  *the common initiailizers.
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index bf22c94c3d53..eb162553cff2 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1199,7 +1199,7 @@ static int gen8_init_common_ring(struct intel_engine_cs 
*engine)
 
lrc_init_hws(engine);
 
-   intel_engine_reset_irq(engine);
+   intel_engine_reset_breadcrumbs(engine);
 
I915_WRITE(RING_HWSTAM(engine->mmio_base), 0x);
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 4bc47af68454..3abfbe3cfed9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -548,7 +548,7 @@ static int init_ring_common(struct intel_engine_cs *engine)
else
intel_ring_setup_status_page(engine);
 
-   intel_engine_reset_irq(engine);
+   intel_engine_reset_breadcrumbs(engine);
 
/* Enforce ordering by reading HEAD register back */
I915_READ_HEAD(engine);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 29d37b7c6021..a888f68d63d9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -482,7 +482,6 @@ int __intel_ring_space(int head, int tail, int size);
 void intel_ring_update_space(struct intel_ring *ring);
 
 void intel_engine_init_global_seqno(struct intel_engine_cs *engine, u32 seqno);
-void intel_engine_reset_irq(struct intel_engine_cs *engine);
 
 void intel_engine_setup_common(struct intel_engine_cs *engine);
 int intel_engine_init_common(struct intel_engine_cs *engine);
@@ -568,6 +567,7 @@ static inline bool intel_engine_wakeup(const struct 
intel_engine_cs *engine)
return wakeup;
 }
 
+void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine);
 void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine);
 unsigned int intel_kick_waiters(struct drm_i915_private *i915);
 unsigned int intel_kick_signalers(struct drm_i915_private *i915);

Re: [Intel-gfx] [PATCH i-g-t 1/2] aubdump: remove already handled -o

[Petri Latvala]

On Wed, Oct 05, 2016 at 11:48:26PM +0100, Lionel Landwerlin wrote:
> -   -o*)
> -   file=${1##-o}
> -   shift
> -   ;;


This breaks using -ofilename without spaces.


--
Petri Latvala
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] tests/igt: dmesg noise is a kernel failure

[Daniel Vetter]

At least when testing the kernel. In normal programs pretty much all
the dmesg noise would simply be replaced by debug asserts, but in the
kernel we try rely hard to not fall over minor inconsistencies.

Still for CI purposes there's not really a difference, hence don't
treat it as such.

Motivated since once again I've seen a statistics where this was split
up, and then a reduction of "failures" (but in reality just trading
them in for more "warnings") praised as success.

Cc: jari.tahvanai...@intel.com
Cc: Petri Latvala 
Signed-off-by: Daniel Vetter 
---
 tests/igt.py | 5 +
 1 file changed, 5 insertions(+)

diff --git a/tests/igt.py b/tests/igt.py
index 7ebb03646b50..473027b76936 100644
--- a/tests/igt.py
+++ b/tests/igt.py
@@ -53,6 +53,7 @@ def check_environment():
 
 """
 debugfs_path = "/sys/kernel/debug/dri"
+
 if os.getuid() != 0:
 raise exceptions.PiglitInternalError(
 "Test Environment check: not root!")
@@ -123,6 +124,10 @@ class IGTTest(Test):
 else:
 self.result.result = 'fail'
 
+# all dmesg noise is considered a test failure when testing the kernel
+if self.result.dmesg
+self.result.result = 'fail'
+
 
 def list_tests(listname):
 """Parse igt test list and return them as a list."""
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v9 1/4] drm/i915/debugfs: Move out pipe CRC code

[Tomeu Vizoso]

In preparation to using a generic API in the DRM core for continuous CRC
generation, move the related code out of i915_debugfs.c into a new file.

Eventually, only the Intel-specific code will remain in this new file.

v2: Rebased.

v6: Rebased.

v7: Fix whitespace issue.

v9: Have intel_display_crc_init accept a drm_i915_private instead.

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Emil Velikov 
---

 drivers/gpu/drm/i915/Makefile |   2 +-
 drivers/gpu/drm/i915/i915_debugfs.c   | 886 +---
 drivers/gpu/drm/i915/intel_drv.h  |   5 +
 drivers/gpu/drm/i915/intel_pipe_crc.c | 943 ++
 4 files changed, 953 insertions(+), 883 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_pipe_crc.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a998c2bce70a..e6fe0040fe64 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -24,7 +24,7 @@ i915-y := i915_drv.o \
  intel_runtime_pm.o
 
 i915-$(CONFIG_COMPAT)   += i915_ioc32.o
-i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o
+i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o intel_pipe_crc.o
 
 # GEM code
 i915-y += i915_cmd_parser.o \
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index da7141382b00..4fb9d829884e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -26,19 +26,9 @@
  *
  */
 
-#include 
-#include 
-#include 
 #include 
-#include 
-#include 
 #include 
-#include 
-#include 
 #include "intel_drv.h"
-#include "intel_ringbuffer.h"
-#include 
-#include "i915_drv.h"
 
 static inline struct drm_i915_private *node_to_i915(struct drm_info_node *node)
 {
@@ -3414,12 +3404,6 @@ static int i915_drrs_status(struct seq_file *m, void 
*unused)
return 0;
 }
 
-struct pipe_crc_info {
-   const char *name;
-   struct drm_i915_private *dev_priv;
-   enum pipe pipe;
-};
-
 static int i915_dp_mst_info(struct seq_file *m, void *unused)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -3449,848 +3433,6 @@ static int i915_dp_mst_info(struct seq_file *m, void 
*unused)
return 0;
 }
 
-static int i915_pipe_crc_open(struct inode *inode, struct file *filep)
-{
-   struct pipe_crc_info *info = inode->i_private;
-   struct drm_i915_private *dev_priv = info->dev_priv;
-   struct intel_pipe_crc *pipe_crc = _priv->pipe_crc[info->pipe];
-
-   if (info->pipe >= INTEL_INFO(dev_priv)->num_pipes)
-   return -ENODEV;
-
-   spin_lock_irq(_crc->lock);
-
-   if (pipe_crc->opened) {
-   spin_unlock_irq(_crc->lock);
-   return -EBUSY; /* already open */
-   }
-
-   pipe_crc->opened = true;
-   filep->private_data = inode->i_private;
-
-   spin_unlock_irq(_crc->lock);
-
-   return 0;
-}
-
-static int i915_pipe_crc_release(struct inode *inode, struct file *filep)
-{
-   struct pipe_crc_info *info = inode->i_private;
-   struct drm_i915_private *dev_priv = info->dev_priv;
-   struct intel_pipe_crc *pipe_crc = _priv->pipe_crc[info->pipe];
-
-   spin_lock_irq(_crc->lock);
-   pipe_crc->opened = false;
-   spin_unlock_irq(_crc->lock);
-
-   return 0;
-}
-
-/* (6 fields, 8 chars each, space separated (5) + '\n') */
-#define PIPE_CRC_LINE_LEN  (6 * 8 + 5 + 1)
-/* account for \'0' */
-#define PIPE_CRC_BUFFER_LEN(PIPE_CRC_LINE_LEN + 1)
-
-static int pipe_crc_data_count(struct intel_pipe_crc *pipe_crc)
-{
-   assert_spin_locked(_crc->lock);
-   return CIRC_CNT(pipe_crc->head, pipe_crc->tail,
-   INTEL_PIPE_CRC_ENTRIES_NR);
-}
-
-static ssize_t
-i915_pipe_crc_read(struct file *filep, char __user *user_buf, size_t count,
-  loff_t *pos)
-{
-   struct pipe_crc_info *info = filep->private_data;
-   struct drm_i915_private *dev_priv = info->dev_priv;
-   struct intel_pipe_crc *pipe_crc = _priv->pipe_crc[info->pipe];
-   char buf[PIPE_CRC_BUFFER_LEN];
-   int n_entries;
-   ssize_t bytes_read;
-
-   /*
-* Don't allow user space to provide buffers not big enough to hold
-* a line of data.
-*/
-   if (count < PIPE_CRC_LINE_LEN)
-   return -EINVAL;
-
-   if (pipe_crc->source == INTEL_PIPE_CRC_SOURCE_NONE)
-   return 0;
-
-   /* nothing to read */
-   spin_lock_irq(_crc->lock);
-   while (pipe_crc_data_count(pipe_crc) == 0) {
-   int ret;
-
-   if (filep->f_flags & O_NONBLOCK) {
-   spin_unlock_irq(_crc->lock);
-   return -EAGAIN;
-   }
-
-   ret = wait_event_interruptible_lock_irq(pipe_crc->wq,
-   pipe_crc_data_count(pipe_crc), pipe_crc->lock);
-   if (ret) {
-   spin_unlock_irq(_crc->lock);
-   

[Intel-gfx] [PATCH v9 3/4] drm/i915: Use new CRC debugfs API

[Tomeu Vizoso]

The core provides now an ABI to userspace for generation of frame CRCs,
so implement the ->set_crc_source() callback and reuse as much code as
possible with the previous ABI implementation.

When handling the pageflip interrupt, we skip 1 or 2 frames depending on
the HW because they contain wrong values. For the legacy ABI for
generating frame CRCs, this was done in userspace but now that we have a
generic ABI it's better if it's not exposed by the kernel.

v2:
- Leave the legacy implementation in place as the ABI implementation
  in the core is incompatible with it.
v3:
- Use the "cooked" vblank counter so we have a whole 32 bits.
- Make sure we don't mess with the state of the legacy CRC capture
  ABI implementation.
v4:
- Keep use of get_vblank_counter as in the legacy code, will be
  changed in a followup commit.

v5:
- Skip first frame or two as it's known that they contain wrong
  data.
- A few fixes suggested by Emil Velikov.

v6:
- Rework programming of the HW registers to preserve previous
  behavior.

v7:
- Address whitespace issue.
- Added a comment on why in the implementation of the new ABI we
  skip the 1st or 2nd frames.

v9:
- Add stub for intel_crtc_set_crc_source.

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Emil Velikov 
---

 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/i915_irq.c   | 83 +--
 drivers/gpu/drm/i915/intel_display.c  |  1 +
 drivers/gpu/drm/i915/intel_drv.h  |  8 +++
 drivers/gpu/drm/i915/intel_pipe_crc.c | 94 ++-
 5 files changed, 149 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f8c66eea06bc..20522f0a4c57 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1713,6 +1713,7 @@ struct intel_pipe_crc {
enum intel_pipe_crc_source source;
int head, tail;
wait_queue_head_t wq;
+   int skipped;
 };
 
 struct i915_frontbuffer_tracking {
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bd6c8b0eeaef..1549cc4f88ec 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1491,41 +1491,72 @@ static void display_pipe_crc_irq_handler(struct 
drm_i915_private *dev_priv,
 {
struct intel_pipe_crc *pipe_crc = _priv->pipe_crc[pipe];
struct intel_pipe_crc_entry *entry;
-   int head, tail;
+   struct drm_crtc *crtc = intel_get_crtc_for_pipe(_priv->drm, pipe);
+   struct drm_driver *driver = dev_priv->drm.driver;
+   uint32_t crcs[5];
+   int head, tail, ret;
+   u32 frame;
 
spin_lock(_crc->lock);
+   if (pipe_crc->source) {
+   if (!pipe_crc->entries) {
+   spin_unlock(_crc->lock);
+   DRM_DEBUG_KMS("spurious interrupt\n");
+   return;
+   }
 
-   if (!pipe_crc->entries) {
-   spin_unlock(_crc->lock);
-   DRM_DEBUG_KMS("spurious interrupt\n");
-   return;
-   }
-
-   head = pipe_crc->head;
-   tail = pipe_crc->tail;
+   head = pipe_crc->head;
+   tail = pipe_crc->tail;
 
-   if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
-   spin_unlock(_crc->lock);
-   DRM_ERROR("CRC buffer overflowing\n");
-   return;
-   }
+   if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
+   spin_unlock(_crc->lock);
+   DRM_ERROR("CRC buffer overflowing\n");
+   return;
+   }
 
-   entry = _crc->entries[head];
+   entry = _crc->entries[head];
 
-   entry->frame = dev_priv->drm.driver->get_vblank_counter(_priv->drm,
-pipe);
-   entry->crc[0] = crc0;
-   entry->crc[1] = crc1;
-   entry->crc[2] = crc2;
-   entry->crc[3] = crc3;
-   entry->crc[4] = crc4;
+   entry->frame = driver->get_vblank_counter(_priv->drm, pipe);
+   entry->crc[0] = crc0;
+   entry->crc[1] = crc1;
+   entry->crc[2] = crc2;
+   entry->crc[3] = crc3;
+   entry->crc[4] = crc4;
 
-   head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
-   pipe_crc->head = head;
+   head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
+   pipe_crc->head = head;
 
-   spin_unlock(_crc->lock);
+   spin_unlock(_crc->lock);
 
-   wake_up_interruptible(_crc->wq);
+   wake_up_interruptible(_crc->wq);
+   } else {
+   /*
+* For some not yet identified reason, the first CRC is
+* bonkers. So let's just wait for the next vblank and read
+   

[Intel-gfx] [PATCH v9 4/4] drm/i915: Put "cooked" vlank counters in frame CRC lines

[Tomeu Vizoso]

Use drm_accurate_vblank_count so we have the full 32 bit to represent
the frame counter and userspace has a simpler way of knowing when the
counter wraps around.

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Emil Velikov 
---

 drivers/gpu/drm/i915/i915_irq.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1549cc4f88ec..238a353454e9 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1495,7 +1495,6 @@ static void display_pipe_crc_irq_handler(struct 
drm_i915_private *dev_priv,
struct drm_driver *driver = dev_priv->drm.driver;
uint32_t crcs[5];
int head, tail, ret;
-   u32 frame;
 
spin_lock(_crc->lock);
if (pipe_crc->source) {
@@ -1551,8 +1550,9 @@ static void display_pipe_crc_irq_handler(struct 
drm_i915_private *dev_priv,
crcs[2] = crc2;
crcs[3] = crc3;
crcs[4] = crc4;
-   frame = driver->get_vblank_counter(_priv->drm, pipe);
-   ret = drm_crtc_add_crc_entry(crtc, true, frame, crcs);
+   ret = drm_crtc_add_crc_entry(crtc, true,
+drm_accurate_vblank_count(crtc),
+crcs);
spin_unlock(>crc.lock);
if (!ret)
wake_up_interruptible(>crc.wq);
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v9 0/4] New debugfs API for capturing CRC of frames

[Tomeu Vizoso]

Hi,

this series basically takes the facility for continuously capturing CRCs
of frames from the i915 driver and into the DRM core.

The idea is that test suites such as IGT use this information to check
that frames that are exected to be identical, also have identical CRC
values.

Other drivers for hardware that can provide frame CRCs (including eDP
panels that support self-refresh) can easily implement the new callback
and provide userspace with the CRC values.

In this v9, there are build fixes for !CONFIG_DEBUG_FS and a fix so we don't
break probing of drivers that still use the .load callback (tested on
Tegra124).

Thanks,

Tomeu


Tomeu Vizoso (4):
  drm/i915/debugfs: Move out pipe CRC code
  drm: Add API for capturing frame CRCs
  drm/i915: Use new CRC debugfs API
  drm/i915: Put "cooked" vlank counters in frame CRC lines

 Documentation/gpu/drm-uapi.rst|6 +
 drivers/gpu/drm/Makefile  |3 +-
 drivers/gpu/drm/drm_crtc.c|   34 +-
 drivers/gpu/drm/drm_debugfs.c |   34 +-
 drivers/gpu/drm/drm_debugfs_crc.c |  351 
 drivers/gpu/drm/drm_internal.h|   16 +
 drivers/gpu/drm/i915/Makefile |2 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |  886 +---
 drivers/gpu/drm/i915/i915_drv.h   |1 +
 drivers/gpu/drm/i915/i915_irq.c   |   83 ++-
 drivers/gpu/drm/i915/intel_display.c  |1 +
 drivers/gpu/drm/i915/intel_drv.h  |   13 +
 drivers/gpu/drm/i915/intel_pipe_crc.c | 1013 +
 include/drm/drm_crtc.h|   41 ++
 include/drm/drm_debugfs_crc.h |   73 +++
 15 files changed, 1645 insertions(+), 912 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
 create mode 100644 drivers/gpu/drm/i915/intel_pipe_crc.c
 create mode 100644 include/drm/drm_debugfs_crc.h

-- 
2.7.4

___
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: Add explicit test lists for CI use.

[Petri Latvala]

See tests/intel-ci/README for rationale and explanation.

v2: Use the current BAT set for fast-feedback.testlist first

Signed-off-by: Petri Latvala 
---

Thanks for the feedback. This commit only contains the current test
set, extended test suites are left for future discussion.


 tests/intel-ci/README |  34 +
 tests/intel-ci/fast-feedback.testlist | 248 ++
 2 files changed, 282 insertions(+)
 create mode 100644 tests/intel-ci/README
 create mode 100644 tests/intel-ci/fast-feedback.testlist

diff --git a/tests/intel-ci/README b/tests/intel-ci/README
new file mode 100644
index 000..dc7e5c8
--- /dev/null
+++ b/tests/intel-ci/README
@@ -0,0 +1,34 @@
+This directory contains test lists that are used by Intel's CI. The
+files are passed to piglit with the --test-list parameter directly.
+
+The test lists are contained in the IGT repository for several
+reasons:
+
+- The lists stay synchronized with the IGT codebase.
+- Public availability. Kernel developers can see what tests are run,
+  and can see what changes are done to the set, when, and why.
+- Explicit test lists in general make it possible to implement a new
+  test without having it run in CI (accidentally or on purpose) before
+  CI is ready for it, and for CI to stop running a test without
+  removing the test or changing its name. The previous method of test
+  selection was based on name patterns.
+
+Changing the test lists should only happen with approval from the CI
+people. If you make a new test that should be tested by CI regularly,
+ask a maintainer (see MAINTAINERS).
+
+==
+fast-feedback.testlist
+==
+
+Fast-feedback is the testlist that is run for Patchwork and Trybot
+testing. It is also run on various drm-intel-* branches.
+
+Time limit: Full run must complete in 15 minutes on all tested
+platforms.
+
+Feature coverage: Should test all working features, with at least 1
+test per feature.
+
+The string "basic" in a test name means the test probably belongs in
+this list.
diff --git a/tests/intel-ci/fast-feedback.testlist 
b/tests/intel-ci/fast-feedback.testlist
new file mode 100644
index 000..ae94381
--- /dev/null
+++ b/tests/intel-ci/fast-feedback.testlist
@@ -0,0 +1,248 @@
+igt@core_auth@basic-auth
+igt@core_prop_blob@basic
+igt@drv_getparams_basic@basic-eu-total
+igt@drv_getparams_basic@basic-subslice-total
+igt@drv_hangman@error-state-basic
+igt@drv_module_reload_basic
+igt@gem_basic@bad-close
+igt@gem_basic@create-close
+igt@gem_basic@create-fd-close
+igt@gem_busy@basic-busy-default
+igt@gem_busy@basic-hang-default
+igt@gem_close_race@basic-process
+igt@gem_close_race@basic-threads
+igt@gem_cpu_reloc@basic
+igt@gem_cs_tlb@basic-default
+igt@gem_ctx_basic
+igt@gem_ctx_create@basic
+igt@gem_ctx_create@basic-files
+igt@gem_ctx_exec@basic
+igt@gem_ctx_param@basic
+igt@gem_ctx_param@basic-default
+igt@gem_ctx_switch@basic-default
+igt@gem_ctx_switch@basic-default-heavy
+igt@gem_exec_basic@basic-blt
+igt@gem_exec_basic@basic-bsd
+igt@gem_exec_basic@basic-bsd1
+igt@gem_exec_basic@basic-bsd2
+igt@gem_exec_basic@basic-default
+igt@gem_exec_basic@basic-render
+igt@gem_exec_basic@basic-vebox
+igt@gem_exec_basic@gtt-blt
+igt@gem_exec_basic@gtt-bsd
+igt@gem_exec_basic@gtt-bsd1
+igt@gem_exec_basic@gtt-bsd2
+igt@gem_exec_basic@gtt-default
+igt@gem_exec_basic@gtt-render
+igt@gem_exec_basic@gtt-vebox
+igt@gem_exec_basic@readonly-blt
+igt@gem_exec_basic@readonly-bsd
+igt@gem_exec_basic@readonly-bsd1
+igt@gem_exec_basic@readonly-bsd2
+igt@gem_exec_basic@readonly-default
+igt@gem_exec_basic@readonly-render
+igt@gem_exec_basic@readonly-vebox
+igt@gem_exec_create@basic
+igt@gem_exec_flush@basic-batch-kernel-default-cmd
+igt@gem_exec_flush@basic-batch-kernel-default-uc
+igt@gem_exec_flush@basic-batch-kernel-default-wb
+igt@gem_exec_flush@basic-uc-pro-default
+igt@gem_exec_flush@basic-uc-prw-default
+igt@gem_exec_flush@basic-uc-ro-default
+igt@gem_exec_flush@basic-uc-rw-default
+igt@gem_exec_flush@basic-uc-set-default
+igt@gem_exec_flush@basic-wb-pro-default
+igt@gem_exec_flush@basic-wb-prw-default
+igt@gem_exec_flush@basic-wb-ro-before-default
+igt@gem_exec_flush@basic-wb-ro-default
+igt@gem_exec_flush@basic-wb-rw-before-default
+igt@gem_exec_flush@basic-wb-rw-default
+igt@gem_exec_flush@basic-wb-set-default
+igt@gem_exec_gttfill@basic
+igt@gem_exec_nop@basic-parallel
+igt@gem_exec_nop@basic-series
+igt@gem_exec_parallel@basic
+igt@gem_exec_parse@basic-allowed
+igt@gem_exec_parse@basic-rejected
+igt@gem_exec_store@basic-all
+igt@gem_exec_store@basic-blt
+igt@gem_exec_store@basic-bsd
+igt@gem_exec_store@basic-bsd1
+igt@gem_exec_store@basic-bsd2
+igt@gem_exec_store@basic-default
+igt@gem_exec_store@basic-render
+igt@gem_exec_store@basic-vebox
+igt@gem_exec_suspend@basic
+igt@gem_exec_suspend@basic-s3
+igt@gem_exec_suspend@basic-s4
+igt@gem_flink_basic@bad-flink
+igt@gem_flink_basic@bad-open
+igt@gem_flink_basic@basic

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Force relocations via cpu if we run out of idle aperture

[Patchwork]

== Series Details ==

Series: drm/i915: Force relocations via cpu if we run out of idle aperture
URL   : https://patchwork.freedesktop.org/series/13368/
State : warning

== Summary ==

Series 13368v1 drm/i915: Force relocations via cpu if we run out of idle 
aperture
https://patchwork.freedesktop.org/api/1.0/series/13368/revisions/1/mbox/

Test kms_busy:
Subgroup basic-flip-default-a:
pass   -> DMESG-WARN (fi-byt-n2820)
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (fi-skl-6700hq)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:244  pass:214  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:244  pass:210  dwarn:2   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:244  pass:207  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:244  pass:182  dwarn:0   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:244  pass:219  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 
fi-kbl-7200u total:244  pass:220  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:221  dwarn:1   dfail:0   fail:0   skip:22 
fi-skl-6700k total:244  pass:219  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:244  pass:228  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:244  pass:208  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:244  pass:207  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2636/

2dff18acaa95a26b882a5f9910d7ded514f18415 drm-intel-nightly: 
2016y-10m-05d-13h-58m-08s UTC integration manifest
a6bf9e7 drm/i915: Force relocations via cpu if we run out of idle aperture

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Distinguish last emitted request from last submitted request

[Mika Kuoppala]

Chris Wilson  writes:

> In order not to trigger hangcheck on a idle-but-waiting engine, we need
> to distinguish between the pending request queue and the actual
> execution queue. This is done later in "drm/i915: Enable multiple
> timelines" but for now we need a temporary fix to prevent blaming the
> wrong engine for a GPU hang.
>

You described this as a hack, but on top of current nightly,
this doesn't seem so hackish at all.

Reviewed-by: Mika Kuoppala 

> Fixes: 0a046a0e93d2 ("drm/i915: Nonblocking request submission")
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_gem_request.c | 5 +++--
>  drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> b/drivers/gpu/drm/i915/i915_gem_request.c
> index 40978bc12ceb..8832f8ec1583 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -328,6 +328,7 @@ submit_notify(struct i915_sw_fence *fence, enum 
> i915_sw_fence_notify state)
>  
>   switch (state) {
>   case FENCE_COMPLETE:
> + request->engine->last_submitted_seqno = request->fence.seqno;
>   request->engine->submit_request(request);
>   break;
>  
> @@ -641,8 +642,8 @@ void __i915_add_request(struct drm_i915_gem_request 
> *request, bool flush_caches)
>>submitq);
>  
>   request->emitted_jiffies = jiffies;
> - request->previous_seqno = engine->last_submitted_seqno;
> - engine->last_submitted_seqno = request->fence.seqno;
> + request->previous_seqno = engine->last_pending_seqno;
> + engine->last_pending_seqno = request->fence.seqno;
>   i915_gem_active_set(>last_request, request);
>   list_add_tail(>link, >request_list);
>   list_add_tail(>ring_link, >request_list);
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index 498931f0b1f1..34954ca03a4a 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -355,6 +355,7 @@ struct intel_engine_cs {
>* inspecting request list.
>*/
>   u32 last_submitted_seqno;
> + u32 last_pending_seqno;
>  
>   /* An RCU guarded pointer to the last request. No reference is
>* held to the request, users must carefully acquire a reference to
> -- 
> 2.9.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Save hangcheck score across resets

[Patchwork]

== Series Details ==

Series: drm/i915: Save hangcheck score across resets
URL   : https://patchwork.freedesktop.org/series/13367/
State : failure

== Summary ==

Series 13367v1 drm/i915: Save hangcheck score across resets
https://patchwork.freedesktop.org/api/1.0/series/13367/revisions/1/mbox/

Test gem_close_race:
Subgroup basic-threads:
pass   -> FAIL   (fi-snb-2600)
pass   -> FAIL   (fi-bsw-n3050)
pass   -> FAIL   (fi-byt-j1900)
pass   -> FAIL   (fi-ivb-3770)
pass   -> FAIL   (fi-hsw-4770)
pass   -> FAIL   (fi-hsw-4770r)
pass   -> FAIL   (fi-byt-n2820)
pass   -> FAIL   (fi-bxt-t5700)
pass   -> FAIL   (fi-skl-6260u)
pass   -> FAIL   (fi-ivb-3520m)
pass   -> FAIL   (fi-bdw-5557u)
pass   -> FAIL   (fi-snb-2520m)
pass   -> FAIL   (fi-skl-6700hq)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-byt-j1900)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900)

fi-bdw-5557u total:244  pass:228  dwarn:0   dfail:0   fail:1   skip:15 
fi-bsw-n3050 total:244  pass:201  dwarn:0   dfail:0   fail:1   skip:42 
fi-bxt-t5700 total:244  pass:213  dwarn:0   dfail:0   fail:1   skip:30 
fi-byt-j1900 total:244  pass:211  dwarn:0   dfail:0   fail:2   skip:31 
fi-byt-n2820 total:244  pass:207  dwarn:0   dfail:0   fail:2   skip:35 
fi-hsw-4770  total:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-hsw-4770r total:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-ilk-650   total:244  pass:182  dwarn:0   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:244  pass:218  dwarn:0   dfail:0   fail:1   skip:25 
fi-ivb-3770  total:244  pass:206  dwarn:0   dfail:0   fail:1   skip:37 
fi-kbl-7200u total:244  pass:220  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:244  pass:229  dwarn:0   dfail:0   fail:1   skip:14 
fi-skl-6700hqtotal:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-skl-6700k total:244  pass:219  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:244  pass:228  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:244  pass:207  dwarn:0   dfail:0   fail:1   skip:36 
fi-snb-2600  total:244  pass:206  dwarn:0   dfail:0   fail:1   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2635/

2dff18acaa95a26b882a5f9910d7ded514f18415 drm-intel-nightly: 
2016y-10m-05d-13h-58m-08s UTC integration manifest
b60a823 drm/i915: Save hangcheck score across resets

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Force relocations via cpu if we run out of idle aperture

[Chris Wilson]

If we run out of enough aperture space to fit the entire object, we
fallback to trying to insert a single page. However, if that also fails,
we currently fail to userspace with an unexpected ENOSPC. (ENOSPC means
to userspace that their batch could not be fitted within the GTT.) Prior
to commit e8cb909ac3ab ("drm/i915: Fallback to single page GTT
mmappings for relocations") the approach is to fallback to using the
slow CPU relocation path in case of iomapping failure, and that is the
behaviour we need to restore.

Fixes: e8cb909ac3ab ("drm/i915: Fallback to single page GTT mmappings...")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98101
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 8c0cf1417e79..cdcdab2b0370 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -461,8 +461,8 @@ static void *reloc_iomap(struct drm_i915_gem_object *obj,
 0, ggtt->mappable_end,
 DRM_MM_SEARCH_DEFAULT,
 DRM_MM_CREATE_DEFAULT);
-   if (ret)
-   return ERR_PTR(ret);
+   if (ret) /* no inactive aperture space, use cpu reloc */
+   return NULL;
} else {
ret = i915_vma_put_fence(vma);
if (ret) {
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 04/22] drm/i915: Make HAS_DDI and HAS_PCH_LPT_LP only take dev_priv

[Tvrtko Ursulin]

On 05/10/2016 18:16, Ville Syrjälä wrote:

On Wed, Oct 05, 2016 at 01:33:31PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

This saves 3248 bytes of .rodata strings.

Signed-off-by: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_drv.h   |  8 +++---
  drivers/gpu/drm/i915/intel_crt.c  | 10 +++
  drivers/gpu/drm/i915/intel_display.c  | 49 ++-
  drivers/gpu/drm/i915/intel_dp.c   | 16 ++--
  drivers/gpu/drm/i915/intel_dpll_mgr.c |  4 +--
  drivers/gpu/drm/i915/intel_hdmi.c | 10 +++
  drivers/gpu/drm/i915/intel_pm.c   |  4 +--
  drivers/gpu/drm/i915/intel_psr.c  |  8 +++---
  8 files changed, 56 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4613f031d127..61e0cf7374ed 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2817,7 +2817,7 @@ struct drm_i915_cmd_table {
  
  #define HAS_DP_MST(dev)	(INTEL_INFO(dev)->has_dp_mst)
  
-#define HAS_DDI(dev)		(INTEL_INFO(dev)->has_ddi)

+#define HAS_DDI(dev_priv)  (dev_priv->info.has_ddi)

((dev_priv)->...)


Yes I've also spotted that myself. Will fix them all locally but won't 
be sending them out until/if there is some consensus.


Regards,

Tvrtko

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/22] drm/i915: Shrink per-platform watermark configuration

[Tvrtko Ursulin]

On 06/10/2016 07:58, Joonas Lahtinen wrote:

On ke, 2016-10-05 at 17:53 +0100, Tvrtko Ursulin wrote:

On 05/10/2016 17:50, Tvrtko Ursulin wrote:


On 05/10/2016 16:07, Joonas Lahtinen wrote:

On ke, 2016-10-05 at 13:33 +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Use types of more appropriate size in struct
intel_watermark_params to save 512 bytes of .rodata.

Signed-off-by: Tvrtko Ursulin 

The code does seem to use datatypes very sloppily. Where did you
pick
up these?

I was just nosing around in .rodata and wondered why a huge table
of
zeros. :)


Oops no, that was the cxsr table which stood out so much. After I
found
that one I nosed around some more to see which ones look wasteful.


I rather meant how did you deduce the right datatype sizes?



Oh right, I've looked at the values stored in them and got extra 
confidence when the compiler did not complain.


Regards,

Tvrtko

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/22] drm/i915: Shrink cxsr_latency_table

[Tvrtko Ursulin]

On 05/10/2016 18:01, Ville Syrjälä wrote:

On Wed, Oct 05, 2016 at 01:33:28PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

unsigned long is too wide - use smaller types in
struct cxsr_latency to save 800-something bytes of .rodata.

Signed-off-by: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/intel_drv.h | 16 
  drivers/gpu/drm/i915/intel_pm.c  |  4 ++--
  2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f48e79ae2ac6..c52b1d3a7ba0 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -807,14 +807,14 @@ struct intel_watermark_params {
  };
  
  struct cxsr_latency {

-   int is_desktop;
-   int is_ddr3;
-   unsigned long fsb_freq;
-   unsigned long mem_freq;
-   unsigned long display_sr;
-   unsigned long display_hpll_disable;
-   unsigned long cursor_sr;
-   unsigned long cursor_hpll_disable;
+   bool is_desktop : 1;
+   bool is_ddr3 : 1;
+   unsigned int fsb_freq;
+   unsigned int mem_freq;
+   unsigned int display_sr;
+   unsigned int display_hpll_disable;
+   unsigned int cursor_sr;
+   unsigned int cursor_hpll_disable;

Am I blind or would all of the values fit even in u16?


No you are right, I'll improve it accordingly. :)

Regards,

Tvrtko

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t RFC] tests: Add explicit test lists for CI use.

[Daniel Vetter]

On Thu, Oct 06, 2016 at 09:31:32AM +0300, Petri Latvala wrote:
> See tests/intel-ci/README for rationale and explanation.
> 
> Signed-off-by: Petri Latvala 
> ---
> 
> 
> The plans for CI are to use explicit test lists in the future, as laid
> out in this commit. Comments, acks, nacks, flames, etc would be very
> welcome.
> 
> The only list so far is a fattened version of the currently run set,
> also known as the BAT set. The tests added are such that they all pass
> in preliminary test runs, and do it sufficiently quickly to still meet
> the time requirement of 15 minute runs.
> 
> Having said that, the limit is getting a bit tight and some of these
> should be dropped before deploying to production. Comments on test
> overlap and such also appreciated.

I think we should split this into 2 patches: First switch the BAT test
list over to this file, then in a 2nd patch extend it.
-Daniel


> 
> 
> 
> 
> 
>  tests/intel-ci/README |  34 ++
>  tests/intel-ci/fast-feedback.testlist | 611 
> ++
>  2 files changed, 645 insertions(+)
>  create mode 100644 tests/intel-ci/README
>  create mode 100644 tests/intel-ci/fast-feedback.testlist
> 
> diff --git a/tests/intel-ci/README b/tests/intel-ci/README
> new file mode 100644
> index 000..dc7e5c8
> --- /dev/null
> +++ b/tests/intel-ci/README
> @@ -0,0 +1,34 @@
> +This directory contains test lists that are used by Intel's CI. The
> +files are passed to piglit with the --test-list parameter directly.
> +
> +The test lists are contained in the IGT repository for several
> +reasons:
> +
> +- The lists stay synchronized with the IGT codebase.
> +- Public availability. Kernel developers can see what tests are run,
> +  and can see what changes are done to the set, when, and why.
> +- Explicit test lists in general make it possible to implement a new
> +  test without having it run in CI (accidentally or on purpose) before
> +  CI is ready for it, and for CI to stop running a test without
> +  removing the test or changing its name. The previous method of test
> +  selection was based on name patterns.
> +
> +Changing the test lists should only happen with approval from the CI
> +people. If you make a new test that should be tested by CI regularly,
> +ask a maintainer (see MAINTAINERS).
> +
> +==
> +fast-feedback.testlist
> +==
> +
> +Fast-feedback is the testlist that is run for Patchwork and Trybot
> +testing. It is also run on various drm-intel-* branches.
> +
> +Time limit: Full run must complete in 15 minutes on all tested
> +platforms.
> +
> +Feature coverage: Should test all working features, with at least 1
> +test per feature.
> +
> +The string "basic" in a test name means the test probably belongs in
> +this list.
> diff --git a/tests/intel-ci/fast-feedback.testlist 
> b/tests/intel-ci/fast-feedback.testlist
> new file mode 100644
> index 000..6f9349c
> --- /dev/null
> +++ b/tests/intel-ci/fast-feedback.testlist
> @@ -0,0 +1,611 @@
> +igt@core_auth@basic-auth
> +igt@core_auth@many-magics
> +igt@core_getclient
> +igt@core_get_client_auth@master-drop
> +igt@core_get_client_auth@simple
> +igt@core_getstats
> +igt@core_getversion
> +igt@core_prop_blob@basic
> +igt@core_prop_blob@blob-multiple
> +igt@core_prop_blob@blob-prop-core
> +igt@core_prop_blob@blob-prop-lifetime
> +igt@core_prop_blob@blob-prop-validate
> +igt@core_prop_blob@invalid-get-prop
> +igt@core_prop_blob@invalid-get-prop-any
> +igt@core_prop_blob@invalid-set-prop
> +igt@core_prop_blob@invalid-set-prop-any
> +igt@core_setmaster_vs_auth
> +igt@debugfs_emon_crash
> +igt@drm_import_export@import-close-race-flink
> +igt@drm_import_export@import-close-race-prime
> +igt@drm_read@empty-nonblock
> +igt@drm_read@fault-buffer
> +igt@drm_read@invalid-buffer
> +igt@drm_read@short-buffer-block
> +igt@drm_read@short-buffer-nonblock
> +igt@drm_vma_limiter
> +igt@drm_vma_limiter_cpu
> +igt@drv_debugfs_reader
> +igt@drv_getparams_basic@basic-eu-total
> +igt@drv_getparams_basic@basic-subslice-total
> +igt@drv_hangman@error-state-basic
> +igt@drv_hangman@error-state-debugfs-entry
> +igt@drv_hangman@error-state-sysfs-entry
> +igt@drv_module_reload_basic
> +igt@gem_bad_length
> +igt@gem_bad_reloc@negative-reloc-blt
> +igt@gem_bad_reloc@negative-reloc-bltcopy
> +igt@gem_bad_reloc@negative-reloc-bsd
> +igt@gem_bad_reloc@negative-reloc-bsd1
> +igt@gem_bad_reloc@negative-reloc-bsd2
> +igt@gem_bad_reloc@negative-reloc-default
> +igt@gem_bad_reloc@negative-reloc-lut-blt
> +igt@gem_bad_reloc@negative-reloc-lut-bsd
> +igt@gem_bad_reloc@negative-reloc-lut-bsd1
> +igt@gem_bad_reloc@negative-reloc-lut-bsd2
> +igt@gem_bad_reloc@negative-reloc-lut-default
> +igt@gem_bad_reloc@negative-reloc-lut-render
> +igt@gem_bad_reloc@negative-reloc-lut-vebox
> +igt@gem_bad_reloc@negative-reloc-render
> +igt@gem_bad_reloc@negative-reloc-vebox
> +igt@gem_basic@bad-close
> +igt@gem_basic@create-close
> +igt@gem_basic@create-fd-close