Re: [Intel-gfx] [PATCH v4 0/5] HPD support during suspend for BXT/APL.

[Animesh Manna]

Hi,


On 6/27/2017 5:31 PM, David Weinehall wrote:

On Mon, Jun 12, 2017 at 08:54:02PM +0530, Animesh Manna wrote:

Along with below patches sharing some background details/design.
- On BXT, Display cannot generate an interrupt when in D3.
- Without display in D3, S0ix can be achieved, Power impact will be zero if d3 
is blocked. PMCSR for Graphics/Display is irrelevant, as the power management 
for them is taken care by the PUNIT using RC6/DC9 hints and *not* through PMCSR 
write trigger.

Does this apply to GLK as well?

Yes, as per bspec this apply for GLK as well.

Regards,
Animesh



So solution is based on below principles:
- Display should not be put into D3 for HPD to work.
- With D0+DC9 we can achieve S0ix and at the same time helps to get the 
interrupt.
- Using pci_save_state() during suspend to take control from OSPM and blocking 
D3, while resuming, giving back to OSPM by pci_restore_state().
- _DSM method is used to program pmc hpd control register to enable hpd during 
suspend.

Please have a look and send your comments/suggestions.

v1: Initial version sent as RFC.

v2: Updated version after addressing review comments from Imre,David.

v3: Updated version after addressing review commnets from Imre, Ville,
 Chris.

v4: New version updated after bios changes on APL platform.

Animesh Manna (5):
   drm/i915/bxt: Corrected the guid for bxt.
   drm/i915/bxt: VBT changes for hpd as wakeup feature
   drm/i915/bxt: Added _DSM call to set HPD_CTL.
   drm/i915/bxt: Block D3 during suspend.
   drm/i915: Enable HPD interrupts with master ctl interrupt

  drivers/gpu/drm/i915/i915_drv.c |  5 +++
  drivers/gpu/drm/i915/i915_drv.h |  3 ++
  drivers/gpu/drm/i915/i915_irq.c | 69 +++--
  drivers/gpu/drm/i915/i915_reg.h |  8 
  drivers/gpu/drm/i915/intel_acpi.c   | 59 
  drivers/gpu/drm/i915/intel_bios.c   |  4 ++
  drivers/gpu/drm/i915/intel_runtime_pm.c |  3 +-
  drivers/gpu/drm/i915/intel_vbt_defs.h   |  3 +-
  8 files changed, 141 insertions(+), 13 deletions(-)

--
1.9.1

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


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

Re: [Intel-gfx] [PATCH i-g-t v2 7/7] Make igtrc configuration common, with configurable suspend/resume delay

[Paul Kocialkowski]

On Tue, 2017-06-27 at 17:11 -0400, Lyude Paul wrote:
> 
> 
> On Tue, 2017-06-27 at 13:53 +0300, Paul Kocialkowski wrote:
> > This adds support for configurable suspend/resume delay and takes the
> > occasion to move igtrc configuation from igt_chamelium to igt_core.
> > This way, suspend/resume delay configuration can be used for all
> > tests.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  lib/Makefile.am |  2 ++
> >  lib/igt_aux.c   | 27 ++
> >  lib/igt_aux.h   |  1 +
> >  lib/igt_chamelium.c | 49 +---
> >  lib/igt_core.c  | 64
> > +
> >  lib/igt_core.h  |  2 ++
> >  tests/Makefile.am   |  4 ++--
> >  tests/chamelium.c   | 11 +
> >  tools/Makefile.am   |  4 ++--
> >  9 files changed, 112 insertions(+), 52 deletions(-)
> > 
> > diff --git a/lib/Makefile.am b/lib/Makefile.am
> > index 91e72c44..d4f41128 100644
> > --- a/lib/Makefile.am
> > +++ b/lib/Makefile.am
> > @@ -41,6 +41,7 @@ AM_CFLAGS = \
> > $(XMLRPC_CFLAGS) \
> > $(LIBUDEV_CFLAGS) \
> > $(PIXMAN_CFLAGS) \
> > +   $(GLIB_CFLAGS) \
> > $(VALGRIND_CFLAGS) \
> > -DIGT_SRCDIR=\""$(abs_top_srcdir)/tests"\" \
> > -DIGT_DATADIR=\""$(pkgdatadir)"\" \
> > @@ -61,5 +62,6 @@ libintel_tools_la_LIBADD = \
> > $(XMLRPC_LIBS) \
> > $(LIBUDEV_LIBS) \
> > $(PIXMAN_LIBS) \
> > +   $(GLIB_LIBS) \
> > -lm
> >  
> > diff --git a/lib/igt_aux.c b/lib/igt_aux.c
> > index 882dba06..86a213c2 100644
> > --- a/lib/igt_aux.c
> > +++ b/lib/igt_aux.c
> > @@ -748,10 +748,7 @@ static void suspend_via_rtcwake(enum
> > igt_suspend_state state)
> >  
> > igt_assert(state < SUSPEND_STATE_NUM);
> >  
> > -   if (autoresume_delay)
> > -   delay = autoresume_delay;
> > -   else
> > -   delay = state == SUSPEND_STATE_DISK ? 30 : 15;
> > +   delay = igt_get_autoresume_delay(state);
> >  
> > /*
> >  * Skip if rtcwake would fail for a reason not related to
> > the kernel's
> > @@ -899,6 +896,28 @@ void igt_set_autoresume_delay(int delay_secs)
> >  }
> >  
> >  /**
> > + * igt_get_autoresume_delay:
> > + * @state: an #igt_suspend_state, the target suspend state
> > + *
> > + * Retrieves how long we wait to resume the system after suspending
> > it.
> > + * This can either be set through igt_set_autoresume_delay or be a
> > default
> > + * value that depends on the suspend state.
> > + *
> > + * Returns: The autoresume delay, in seconds.
> > + */
> > +int igt_get_autoresume_delay(enum igt_suspend_state state)
> > +{
> > +   int delay;
> > +
> > +   if (autoresume_delay)
> > +   delay = autoresume_delay;
> > +   else
> > +   delay = state == SUSPEND_STATE_DISK ? 30 : 15;
> > +
> > +   return delay;
> > +}
> > +
> > +/**
> >   * igt_drop_root:
> >   *
> >   * Drop root privileges and make sure it actually worked. Useful for
> > tests
> > diff --git a/lib/igt_aux.h b/lib/igt_aux.h
> > index 54b97164..499a1679 100644
> > --- a/lib/igt_aux.h
> > +++ b/lib/igt_aux.h
> > @@ -192,6 +192,7 @@ enum igt_suspend_test {
> >  void igt_system_suspend_autoresume(enum igt_suspend_state state,
> >enum igt_suspend_test test);
> >  void igt_set_autoresume_delay(int delay_secs);
> > +int igt_get_autoresume_delay(enum igt_suspend_state state);
> >  
> >  /* dropping priviledges */
> >  void igt_drop_root(void);
> > diff --git a/lib/igt_chamelium.c b/lib/igt_chamelium.c
> > index 225f98c3..345c44d6 100644
> > --- a/lib/igt_chamelium.c
> > +++ b/lib/igt_chamelium.c
> > @@ -51,8 +51,8 @@
> >   * [on the ChromeOS project page](https://www.chromium.org/chromium-
> > os/testing/chamelium).
> >   *
> >   * In order to run tests using the Chamelium, a valid configuration
> > file must be
> > - * present.  The configuration file is a normal Glib keyfile
> > (similar to Windows
> > - * INI) structured like so:
> > + * present. It must contain Chamelium-specific keys as shown with
> > the following
> > + * example:
> >   *
> >   * |[
> >   * [Chamelium]
> > @@ -72,8 +72,6 @@
> >   * ChameliumPortID=3
> >   * ]|
> >   *
> > - * By default, this file is expected to exist in ~/.igtrc . The
> > directory for
> > - * this can be overriden by setting the environment variable
> > %IGT_CONFIG_PATH.
> >   */
> >  
> >  struct chamelium_edid {
> > @@ -1034,7 +1032,7 @@ static unsigned int
> > chamelium_get_port_type(struct chamelium *chamelium,
> >  }
> >  
> >  static bool chamelium_read_port_mappings(struct chamelium
> > *chamelium,
> > -int drm_fd, GKeyFile
> > *key_file)
> > +int drm_fd)
> >  {
> > drmModeRes *res;
> > drmModeConnector *connector;
> > @@ -1045,7 +1043,7 @@ static bool chamelium_read_port_mappings(struct
> > chamelium *chamelium,
> > int port_i, i, j;
> > bool ret = true;
> >  
> > -   group_list = g_key_file_get_groups(key_file, NULL);
> > +  

Re: [Intel-gfx] [PATCH 00/13] fbdev locking rework and deferred setup, take 2

[Daniel Vetter]

On Tue, Jun 27, 2017 at 04:02:02PM -0700, John Stultz wrote:
> On Tue, Jun 27, 2017 at 7:59 AM, Daniel Vetter  wrote:
> >
> > Thanks to Liviu's help I realized that I fumbled the locking rework 
> > completely.
> > This one here should be better, but somehow I'm having a real bad day today 
> > and
> > I spent all day typing shit code, and then making it worse.
> >
> > This here seems to work at first glance, but please test and review 
> > carefully.
> 
> After some self-caused testing pain (somehow missed picking one of the
> patches in mutt), I managed to get these tested w/ HiKey against
> 4.12-rc7.
> 
> Things seemed to work fairly well.
> 
> Though the one quirk I saw was that previously if I booted the device
> w/o HDMI plugged in, it would boot up defaulting to 1024x768
> resolution, and when I plugged in the HDMI cable, the monitor would
> start up and use that resolution.
> 
> With your patchset, if I boot without the monitor attached,  it seems
> no fb is created, so surfaceflinger crashes repeatedly trying to start
> up.  Then when I do plug the montior in, I get the following crash:
> 
> [  106.503724] Unable to handle kernel NULL pointer dereference at
> virtual address 0038
> [  106.512050] pgd = ff8008e89000
> [  106.515596] [0038] *pgd=77ffe003,
> *pud=77ffe003, *pmd=
> [  106.524050] Internal error: Oops: 9605 [#1] PREEMPT SMP
> [  106.529678] CPU: 2 PID: 1184 Comm: kworker/2:2 Tainted: GW
>  4.12.0-rc7-00093-g42439fe-dirty #3054
> [  106.539711] Hardware name: HiKey Development Board (DT)
> [  106.544996] Workqueue: events adv7511_hpd_work
> [  106.549484] task: ffc0753c3e80 task.stack: ffc074b0c000
> [  106.555449] PC is at drm_sysfs_hotplug_event+0x34/0x58
> [  106.560624] LR is at drm_sysfs_hotplug_event+0x34/0x58
> [  106.565796] pc : [] lr : []
> pstate: 4145
> [  106.573221] sp : ffc074b0fd40
> [  106.576562] x29: ffc074b0fd40 x28: 
> [  106.581925] x27: ffc005f93d20 x26: ffc074d387b8
> [  106.587288] x25: ffc0753c3e80 x24: ffc0747e3258
> [  106.592650] x23:  x22: ffc077f44a80
> [  106.598012] x21: ffc077f46900 x20: ffc07441cd00
> [  106.603373] x19:  x18: 
> [  106.608733] x17:  x16: 
> [  106.614093] x15: 0018cc1b97ed x14: 
> [  106.619453] x13:  x12: 
> [  106.624813] x11: 02e5 x10: 0880
> [  106.630173] x9 : ffc074b0fa10 x8 : ffc0753c4760
> [  106.635534] x7 : ffc077f3ec80 x6 : ffc077f3c090
> [  106.640895] x5 : ff8008da0568 x4 : 
> [  106.646254] x3 :  x2 : ff8008c39d90
> [  106.651613] x1 : 0001 x0 : ff8008c02fe8
> [  106.656981] Process kworker/2:2 (pid: 1184, stack limit = 
> 0xffc074b0c000)
> [  106.664152] Stack: (0xffc074b0fd40 to 0xffc074b1)
> [  106.669940] fd40: ffc074b0fd70 ff800851d1ec
>  ff80085c7b04
> [  106.677813] fd60: ff8008c39d80 
> ffc074b0fd90 ff8008550bd4
> [  106.685687] fd80: ffc0747e3018 ff80080df688
> ffc074b0fdc0 ff80080d0814
> [  106.693561] fda0:  ff8008a45eb8
> ffc074b0fdc0 00d0080d0808
> [  106.701436] fdc0: ffc074b0fe00 ff80080d0a68
> ffc07441cd00 ffc074a83a00
> [  106.709310] fde0: ffc077f44a80 ffc07441cd30
> ff8008d46000 ffc077f44aa0
> [  106.717184] fe00: ffc074b0fe60 ff80080d6974
> ffc074d38780 ffc074a83a00
> [  106.725059] fe20: ff8008df9160 ffc0753c3e80
> ff8008bf9528 ffc07441cd00
> [  106.732929] fe40: ff80080d0a20 ffc074d387b8
> ffc005f93d20 
> [  106.740801] fe60:  ff8008082ec0
> ff80080d6878 ffc074a83a00
> [  106.748671] fe80:  
>  
> [  106.756541] fea0:  
>  
> [  106.764411] fec0:  
>  
> [  106.772281] fee0:  
>  
> [  106.780151] ff00:  
>  
> [  106.788021] ff20:  
>  
> [  106.795889] ff40:  
>  
> [  106.803759] ff60:  
>  
> [  106.811629] ff80:  
>  
> [  106.819475] ffa0:  
>  
> [  106.827308] ffc0:  0005
>  
> [  106.835143] ffe0:  0

Re: [Intel-gfx] [PATCH i-g-t v2 5/7] tests/chamelium: Update connector state without reprobe when possible

[Paul Kocialkowski]

On Tue, 2017-06-27 at 17:26 -0400, Lyude Paul wrote:
> I -think- this one might be okay but I just got reminded of a rather
> not-obvious part of the DRM spec for hotplugging, and I need to check
> that this doesn't actually break that. will get back to you in a bit
> with an actual review :)

Martin was really expecting this to come around, so I hope it is in accordance
with the DRM spec. At least, it works properly with i915 on SKL.

Thanks for double-checking!

> On Tue, 2017-06-27 at 13:53 +0300, Paul Kocialkowski wrote:
> > This renames the reprobe_connector function to update_connector and
> > ensures that full reprobe of the connector is only done when really
> > necessary (e.g. when changing the EDID).
> > 
> > A full reprobe takes time and is not required for updating the
> > connector
> > state. Thus, this allows executing tests faster.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  tests/chamelium.c | 34 ++
> >  1 file changed, 18 insertions(+), 16 deletions(-)
> > 
> > diff --git a/tests/chamelium.c b/tests/chamelium.c
> > index b412c6a7..346018a5 100644
> > --- a/tests/chamelium.c
> > +++ b/tests/chamelium.c
> > @@ -103,13 +103,14 @@ require_connector_present(data_t *data,
> > unsigned int type)
> >  }
> >  
> >  static drmModeConnection
> > -reprobe_connector(data_t *data, struct chamelium_port *port)
> > +update_connector(data_t *data, struct chamelium_port *port, bool
> > reprobe)
> >  {
> > drmModeConnector *connector;
> > drmModeConnection status;
> >  
> > -   igt_debug("Reprobing %s...\n",
> > chamelium_port_get_name(port));
> > -   connector = chamelium_port_get_connector(data->chamelium,
> > port, true);
> > +   igt_debug("Updating %s...\n",
> > chamelium_port_get_name(port));
> > +   connector = chamelium_port_get_connector(data->chamelium,
> > port,
> > +reprobe);
> > igt_assert(connector);
> > status = connector->connection;
> >  
> > @@ -119,7 +120,7 @@ reprobe_connector(data_t *data, struct
> > chamelium_port *port)
> >  
> >  static void
> >  wait_for_connector(data_t *data, struct chamelium_port *port,
> > -  drmModeConnection status)
> > +  drmModeConnection status, bool reprobe)
> >  {
> > bool finished = false;
> >  
> > @@ -132,7 +133,7 @@ wait_for_connector(data_t *data, struct
> > chamelium_port *port,
> >  * that hpd events work in the event that hpd doesn't work
> > on the system
> >  */
> > igt_until_timeout(HOTPLUG_TIMEOUT) {
> > -   if (reprobe_connector(data, port) == status) {
> > +   if (update_connector(data, port, reprobe) == status)
> > {
> > finished = true;
> > return;
> > }
> > @@ -151,11 +152,12 @@ reset_state(data_t *data, struct chamelium_port
> > *port)
> > chamelium_reset(data->chamelium);
> >  
> > if (port) {
> > -   wait_for_connector(data, port,
> > DRM_MODE_DISCONNECTED);
> > +   wait_for_connector(data, port,
> > DRM_MODE_DISCONNECTED, false);
> > } else {
> > for (p = 0; p < data->port_count; p++) {
> > port = data->ports[p];
> > -   wait_for_connector(data, port,
> > DRM_MODE_DISCONNECTED);
> > +   wait_for_connector(data, port,
> > DRM_MODE_DISCONNECTED,
> > +  false);
> > }
> > }
> >  }
> > @@ -175,7 +177,7 @@ test_basic_hotplug(data_t *data, struct
> > chamelium_port *port, int toggle_count)
> > /* Check if we get a sysfs hotplug event */
> > chamelium_plug(data->chamelium, port);
> > igt_assert(igt_hotplug_detected(mon,
> > HOTPLUG_TIMEOUT));
> > -   igt_assert_eq(reprobe_connector(data, port),
> > +   igt_assert_eq(update_connector(data, port, false),
> >   DRM_MODE_CONNECTED);
> >  
> > igt_flush_hotplugs(mon);
> > @@ -183,7 +185,7 @@ test_basic_hotplug(data_t *data, struct
> > chamelium_port *port, int toggle_count)
> > /* Now check if we get a hotplug from disconnection
> > */
> > chamelium_unplug(data->chamelium, port);
> > igt_assert(igt_hotplug_detected(mon,
> > HOTPLUG_TIMEOUT));
> > -   igt_assert_eq(reprobe_connector(data, port),
> > +   igt_assert_eq(update_connector(data, port, false),
> >   DRM_MODE_DISCONNECTED);
> > }
> >  
> > @@ -204,7 +206,7 @@ test_edid_read(data_t *data, struct
> > chamelium_port *port,
> >  
> > chamelium_port_set_edid(data->chamelium, port, edid_id);
> > chamelium_plug(data->chamelium, port);
> > -   wait_for_connector(data, port, DRM_MODE_CONNECTED);
> > +   wait_for_connector(data, port, DRM_MODE_CONNECTED, true);
> >  
> > igt_assert(kmstest_get_property(data->drm_fd, connector-
> > > connector_id,
> > 
> > DRM_MODE_OBJECT_CONNECTOR,
> > "EDI

Re: [Intel-gfx] [PATCH i-g-t v2 6/7] tests/chamelium: Disconnect connectors without extra reset

[Paul Kocialkowski]

On Tue, 2017-06-27 at 17:21 -0400, Lyude Paul wrote:
> NAK, I'd rather just go with the idea you had with removing the
> connector reset in chamelium_init()

Okay then, I'll craft v3 in that directon. This is not a big overhead anyways,
and it does not change anything when running subtests separately (which is what
most test infrastructures using igt seem to be doing).

> On Tue, 2017-06-27 at 13:53 +0300, Paul Kocialkowski wrote:
> > This removes the reset call from the reset_state function and renames
> > it
> > to disconnect_connector. Since a call to reset is already done in
> > chamelium_init, there is no need to do an extra reset in each test.
> > 
> > This allows reducing the execution time a bit.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  tests/chamelium.c | 22 +++---
> >  1 file changed, 11 insertions(+), 11 deletions(-)
> > 
> > diff --git a/tests/chamelium.c b/tests/chamelium.c
> > index 346018a5..41e0e89b 100644
> > --- a/tests/chamelium.c
> > +++ b/tests/chamelium.c
> > @@ -145,17 +145,17 @@ wait_for_connector(data_t *data, struct
> > chamelium_port *port,
> >  }
> >  
> >  static void
> > -reset_state(data_t *data, struct chamelium_port *port)
> > +disconnect_connector(data_t *data, struct chamelium_port *port)
> >  {
> > int p;
> >  
> > -   chamelium_reset(data->chamelium);
> > -
> > if (port) {
> > +   chamelium_unplug(data->chamelium, port);
> > wait_for_connector(data, port,
> > DRM_MODE_DISCONNECTED, false);
> > } else {
> > for (p = 0; p < data->port_count; p++) {
> > port = data->ports[p];
> > +   chamelium_unplug(data->chamelium, port);
> > wait_for_connector(data, port,
> > DRM_MODE_DISCONNECTED,
> >false);
> > }
> > @@ -168,7 +168,7 @@ test_basic_hotplug(data_t *data, struct
> > chamelium_port *port, int toggle_count)
> > struct udev_monitor *mon = igt_watch_hotplug();
> > int i;
> >  
> > -   reset_state(data, NULL);
> > +   disconnect_connector(data, NULL);
> > igt_hpd_storm_set_threshold(data->drm_fd, 0);
> >  
> > for (i = 0; i < toggle_count; i++) {
> > @@ -202,7 +202,7 @@ test_edid_read(data_t *data, struct
> > chamelium_port *port,
> > data->chamelium, port, false);
> > uint64_t edid_blob_id;
> >  
> > -   reset_state(data, port);
> > +   disconnect_connector(data, port);
> >  
> > chamelium_port_set_edid(data->chamelium, port, edid_id);
> > chamelium_plug(data->chamelium, port);
> > @@ -270,7 +270,7 @@ test_suspend_resume_hpd(data_t *data, struct
> > chamelium_port *port,
> >  {
> > struct udev_monitor *mon = igt_watch_hotplug();
> >  
> > -   reset_state(data, port);
> > +   disconnect_connector(data, port);
> >  
> > /* Make sure we notice new connectors after resuming */
> > try_suspend_resume_hpd(data, port, state, test, mon, false);
> > @@ -294,7 +294,7 @@ test_suspend_resume_hpd_common(data_t *data, enum
> > igt_suspend_state state,
> > igt_debug("Testing port %s\n",
> > chamelium_port_get_name(port));
> > }
> >  
> > -   reset_state(data, NULL);
> > +   disconnect_connector(data, NULL);
> >  
> > /* Make sure we notice new connectors after resuming */
> > try_suspend_resume_hpd(data, NULL, state, test, mon, false);
> > @@ -314,7 +314,7 @@ test_suspend_resume_edid_change(data_t *data,
> > struct chamelium_port *port,
> >  {
> > struct udev_monitor *mon = igt_watch_hotplug();
> >  
> > -   reset_state(data, port);
> > +   disconnect_connector(data, port);
> >  
> > /* First plug in the port */
> > chamelium_port_set_edid(data->chamelium, port, edid_id);
> > @@ -582,7 +582,7 @@ test_hpd_without_ddc(data_t *data, struct
> > chamelium_port *port)
> >  {
> > struct udev_monitor *mon = igt_watch_hotplug();
> >  
> > -   reset_state(data, port);
> > +   disconnect_connector(data, port);
> > igt_flush_hotplugs(mon);
> >  
> > /* Disable the DDC on the connector and make sure we still
> > get a
> > @@ -604,7 +604,7 @@ test_hpd_storm_detect(data_t *data, struct
> > chamelium_port *port, int width)
> > int count = 0;
> >  
> > igt_require_hpd_storm_ctl(data->drm_fd);
> > -   reset_state(data, port);
> > +   disconnect_connector(data, port);
> >  
> > igt_hpd_storm_set_threshold(data->drm_fd, 1);
> > chamelium_fire_hpd_pulses(data->chamelium, port, width, 10);
> > @@ -629,7 +629,7 @@ static void
> >  test_hpd_storm_disable(data_t *data, struct chamelium_port *port,
> > int width)
> >  {
> > igt_require_hpd_storm_ctl(data->drm_fd);
> > -   reset_state(data, port);
> > +   disconnect_connector(data, port);
> >  
> > igt_hpd_storm_set_threshold(data->drm_fd, 0);
> > chamelium_fire_hpd_pulses(data->chamelium, port,
-- 
Paul Kocialkowski 
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
___
Intel-gfx mailing list
Intel-gfx@list

Re: [Intel-gfx] [PATCH v12 3/3] drm/i915: Add option to support dynamic backlight via DPCD

[David Weinehall]

On Tue, Jun 27, 2017 at 10:29:33PM +, Pandiyan, Dhinakaran wrote:
> 
> 
> 
> On Tue, 2017-06-27 at 16:23 +0300, David Weinehall wrote:
> > On Mon, Jun 26, 2017 at 05:18:19PM +0300, David Weinehall wrote:
> > > On Thu, Jun 22, 2017 at 12:03:39PM -0700, Puthikorn Voravootivat wrote:
> > > > This patch adds option to enable dynamic backlight for eDP
> > > > panel that supports this feature via DPCD register and
> > > > set minimum / maximum brightness to 0% and 100% of the
> > > > normal brightness.
> > > 
> > > This patch causes a regression on my ThinkPad X1 Carbon Gen 4;
> > > with enable_dbc = true the backlight stays off; setting i915.enable_dbc=0
> > > on boot makes things work properly again.
> > 
> > Some more testing indicates that while i915.enable_dbc=0 solves the
> > initial issue of backlight not coming on, it's not enough--after
> > suspend/resume the backlight stays off.
> > 
> > Passing i915.enable_dpcd_backlight=0 seems to work both for the initial
> > case of backlight not coming on at boot, and the issue with backlight
> > not coming on after suspend/resume.
> > 
> > So:
> > 
> > DBC:1, DPCD: -1: blank screen on boot
> > DBC:0, DPCD: -1: screen OK on boot, blank after suspend/resume
> > DBC:1, DPCD:  0: screen OK on boot, screen OK after suspend/resume
> > DBC:0, DPCD:  0: screen OK on boot, screen OK after suspend/resume
> > 
> > So it seems that at least for the ThinkPad X1 Carbon Gen 4 (possibly
> > limited to the 2560x1440 model) DPCD backlight isn't supported.
> > 
> 
> Hi David, 
> 
> Thanks for the bug report. It's come a bit sooner than I expected
> though.
> 
> We shouldn't be enabling DPCD backlight control if the panel does not
> support it. I'd like to look at the dmesg with drm.debug=0xE. We debug
> log the panel capabilities early during boot and that will be useful.
> Can you also provide the output of i915_dpcd in debugfs for the eDP
> connector?
> 
> I guess it makes sense to file an FDO and attach the logs there. 

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


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

Re: [Intel-gfx] [igt PATCH] igt/pm_rps: Remove remaining assert on CUR <= MAX

[Arkadiusz Hiler]

On Wed, Jun 21, 2017 at 08:57:21AM -0700, Jeff McGee wrote:
> On Wed, Jun 21, 2017 at 12:55:42PM +0300, Arkadiusz Hiler wrote:
> > On Tue, Jun 20, 2017 at 06:15:52PM +0300, Arkadiusz Hiler wrote:
> > > On Tue, Jun 20, 2017 at 01:54:54PM +, Szwichtenberg, Radoslaw wrote:
> > > > On Wed, 2017-06-14 at 12:44 -0700, jeff.mc...@intel.com wrote:
> > > > > From: Jeff McGee 
> > > > > 
> > > > > This completes the change started by:
> > > > > 
> > > > > commit 39cccab83b7c515a2b57abe679a8cb304c8933ef
> > > > > Author: Chris Wilson 
> > > > > Date:   Fri May 19 09:41:40 2017 +0100
> > > > > 
> > > > > igt/pm_rps: Allow CUR to be greater than MAX (overclocking)
> > > > > 
> > > > > Cc: Chris Wilson 
> > > > > Signed-off-by: Jeff McGee 
> > > > Reviewed-by: Radoslaw Szwichtenberg 
> > > 
> > > Pushed. Thanks for the patch and the review.
> > > 
> > > Excerpt from CONTRIBUTING:
> > > -
> > > Please use --subject-prefix="PATCH i-g-t" so that i-g-t patches are easily
> > > identified in the massive amount mails on intel-gfx. To ensure this is 
> > > always
> > > done, autogen.sh will run:
> > > 
> > >   git config format.subjectprefix "PATCH i-g-t"
> > > 
> > > on its first invocation.
> > > -
> > > 
> > > Lack of proper prefix breaks filtering / patchwork and makes changes
> > > harder to track, and effectilvely it takes longer to get the patch in.
> > > 
> > > The autogen.sh thing is a recent addition.
> > 
> > Hey Jeff,
> > 
> > The change has been reverted.
> > 
> > At first the it looked like a sensible folloup to previous changes and
> > it even got r-bed, but as pointed out by Michal, this constraint still
> > should hold, as it's checked in a non-boost scenario.
> > 
> > It hides bug introduced into the kernel by the commit:
> > "drm/i915: Define a separate variable and control for RPS waitboost 
> > frequency"
> > 
> > for GuC submission path, as the check below always holds true as we have
> > waiters all the time:
> >  if (client_boost || any_waiters) max = hw_max;
> > 
> > What was the point of this change?
> > Were you aware of the fail in the guc_submission scenario?
> > 
> > -- 
> > Cheers,
> > Arek
> 
> Hi Arek. Yes, this was prompted by a regression of this subtest in Yocto
> which uses GuC submission. I root caused it to this same i915 commit
> from Chris but incorrectly thought that the new "policy" was that sysfs
> max freq could be ignored in pretty much any situation. I understand now
> that it should be ignored in only boost and real user wait situations
> (not those triggered by GuC). So I do agree with this revert.

Hey,

Thank you for the explanation. I see where to confusion issued from -
the change seemed to make sense on it's own and to be just a simple
follow up to the previous patch.

> Is there an i915 fix coming soon? Chris?

I think it's under the review on the ML already:
https://patchwork.freedesktop.org/patch/163146/

-- 
Cheers,
Arek

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

Re: [Intel-gfx] [PATCH] drm/i915: select CRC32

[Jani Nikula]

On Wed, 21 Jun 2017, Nicholas Piggin  wrote:
> On Wed, 21 Jun 2017 10:15:56 +0100
> Chris Wilson  wrote:
>
>> Quoting Daniel Vetter (2017-06-21 10:13:41)
>> > On Wed, Jun 21, 2017 at 04:34:20PM +1000, Nicholas Piggin wrote:  
>> > > kbuild test robot found a build failure when building with thin
>> > > archives:
>> > > 
>> > > http://marc.info/?l=linux-kbuild&m=149802285009737&w=2
>> > > 
>> > > Signed-off-by: Nicholas Piggin   
>> > 
>> > Pushed to drm-intel for 4.14, thanks.  
>> 
>> Probably deserves to be in fixes if we identify what introduced the CRC
>> dep. mst-dp? pipe crc?
>
> Looks like
>
> 579cea5f3 ("drm/i915/gvt: golden virtual HW state management")

Thus the select should've been under DRM_I915_GVT.

BR,
Jani.


>
> Thanks,
> Nick
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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] [RFC] drm/i915: Add GuC timeout config options to Kconfig.debug

[Tvrtko Ursulin]

On 14/06/2017 00:19, Kelvin Gardiner wrote:

It is sometimes useful for debug purposes to be able to set GuC timeout
lengths.

This patch adds GuC load and request timeouts values to Kconfig.debug,
which can then be optionally set as required for debug cases. A default
value equal to the current hard-coded values are provided.

In the case when a Kconfig option has not been set, a default value is
provide using a define.

Signed-off-by: Kelvin Gardiner 
---
  drivers/gpu/drm/i915/Kconfig.debug  | 40 +
  drivers/gpu/drm/i915/i915_drv.h | 13 +++
  drivers/gpu/drm/i915/intel_guc_loader.c |  3 ++-
  drivers/gpu/drm/i915/intel_uc.c |  5 -
  4 files changed, 59 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
b/drivers/gpu/drm/i915/Kconfig.debug
index 78c5c04..6a0767d 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -112,3 +112,43 @@ config DRM_I915_DEBUG_VBLANK_EVADE
  the vblank.
  
  	  If in doubt, say "N".

+
+config DRM_I915_OVERRIDE_TIMEOUTS
+   bool "Enable timeout overrides"
+depends on DRM_I915
+default n
+help
+  Enable this option to allow overriding of selected timeouts in the
+ driver i915.
+
+ Timeouts should only be overridden for debug and not in normal use.
+
+ If in doubt, say "N".


If you drop this config...


+
+config DRM_I915_TIMEOUT_GUC_LOAD
+   int "Set the value of the GuC load timeout"
+depends on DRM_I915_OVERRIDE_TIMEOUTS


... and this depends line...


+default 100
+range 0 1
+help
+ Set this option to select the value of the timeout in ms for how long
+ the GuC FW load should take.
+
+ The valid range is 0 to 1
+
+ The default timeout will work in normal use. This option is provided
+ for debug.
+
+config DRM_I915_TIMEOUT_GUC_REQUEST
+   int "Set the value of the GuC request timeout"
+depends on DRM_I915_OVERRIDE_TIMEOUTS


... and this one...


+   default 10
+   range 0 1000
+   help
+  Set this option to select the value of the timeout in ms for how long
+ a request to the GuC should take.
+
+ The valid range is 0 to 1000
+
+ The default timeout will work in normal use. This option is provided
+ for debug.
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 38ef734..efc56d2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1488,6 +1488,19 @@ struct drm_i915_error_state_buf {
  #define I915_ENGINE_DEAD_TIMEOUT  (4 * HZ)  /* Seqno, head and subunits dead 
*/
  #define I915_SEQNO_DEAD_TIMEOUT   (12 * HZ) /* Seqno dead with active head */
  
+#ifndef CONFIG_DRM_I915_TIMEOUT_GUC_LOAD

+#define DRM_I915_TIMEOUT_GUC_LOAD 100
+#else
+#define DRM_I915_TIMEOUT_GUC_LOAD CONFIG_DRM_I915_TIMEOUT_GUC_LOAD
+#endif
+
+#ifndef CONFIG_DRM_I915_TIMEOUT_GUC_REQUEST
+#define DRM_I915_TIMEOUT_GUC_REQUEST 10
+#else
+#define DRM_I915_TIMEOUT_GUC_REQUEST CONFIG_DRM_I915_TIMEOUT_GUC_REQUEST
+#endif
+
+


... and this whole block ...


  struct i915_gpu_error {
/* For hangcheck timer */
  #define DRM_I915_HANGCHECK_PERIOD 1500 /* in ms */
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 8b0ae7f..0d7abad 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -235,7 +235,8 @@ static int guc_ucode_xfer_dma(struct drm_i915_private 
*dev_priv,
 * (Higher levels of the driver will attempt to fall back to
 * execlist mode if this happens.)
 */
-   ret = wait_for(guc_ucode_response(dev_priv, &status), 100);
+   ret = wait_for(guc_ucode_response(dev_priv, &status),
+   DRM_I915_TIMEOUT_GUC_LOAD);


... and use CONFIG_DRM_I915_TIMEOUT_GUC_LOAD directly here ...

  
  	DRM_DEBUG_DRIVER("DMA status 0x%x, GuC status 0x%x\n",

I915_READ(DMA_CTRL), status);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 27e072c..de34119 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -501,7 +501,10 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)
   guc_send_reg(guc, 0),
   INTEL_GUC_RECV_MASK,
   INTEL_GUC_RECV_MASK,
-  10, 10, &status);
+  10,
+  DRM_I915_TIMEOUT_GUC_REQUEST,


... and the same here respectively, then the patch becomes somewhat shorter.

Question is whether that would be worth it, or having an explicit master 
toggle is more desirable?


Since both timeout options provide defaul

Re: [Intel-gfx] [PATCH] drm/i915: Cancel pending execlists irq handler upon idling

[Tvrtko Ursulin]

On 27/06/2017 16:25, Chris Wilson wrote:

Due to the slight asynchronicity in handling the execlists interrupts
(i.e. we defer the work to a handler that may consume more than one
interrupt event), when the engine is idle we may still have an irq
tasklet queued (especially when it has been deferred to a ksoftirqd).
At the beginning of the tasklet, we assert that we do hold a device
wakeref for the access we are about to perform. This assumes that when
we idle and release the GT wakeref, all execlists work has been
completed (since the elsp tracking says the hw is idle). However, there
may still be a tasklet queued, so as we mark the engine idle, also
cancel any pending tasklet.


We check the irq_posted bit which should correspond with a pending 
tasklet (intel_engines_are_idle/intel_engine_is_idle), before 
transitioning to idle so I don't understand this.


Regards,

Tvrtko


Signed-off-by: Chris Wilson 
  Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/intel_engine_cs.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 3b46c1f7b88b..49e875c46c96 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1328,6 +1328,7 @@ void intel_engines_mark_idle(struct drm_i915_private 
*i915)
for_each_engine(engine, i915, id) {
intel_engine_disarm_breadcrumbs(engine);
i915_gem_batch_pool_fini(&engine->batch_pool);
+   tasklet_kill(&engine->irq_tasklet);
engine->no_priolist = false;
}
  }


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

[Intel-gfx] [PATCH] drm/hisilicon: Remove custom FB helper deferred setup

[Daniel Vetter]

From: Thierry Reding 

The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.

v2: Dont' resurrect drm_vblank_cleanup.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Reviewed-by: Daniel Vetter 
Signed-off-by: Thierry Reding  (v1)
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 8065d6cb1d7f..1178341c3858 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -54,14 +54,7 @@ static void kirin_fbdev_output_poll_changed(struct 
drm_device *dev)
 {
struct kirin_drm_private *priv = dev->dev_private;
 
-   if (priv->fbdev) {
-   drm_fbdev_cma_hotplug_event(priv->fbdev);
-   } else {
-   priv->fbdev = drm_fbdev_cma_init(dev, 32,
-
dev->mode_config.num_connector);
-   if (IS_ERR(priv->fbdev))
-   priv->fbdev = NULL;
-   }
+   drm_fbdev_cma_hotplug_event(priv->fbdev);
 }
 #endif
 
@@ -128,11 +121,18 @@ static int kirin_drm_kms_init(struct drm_device *dev)
/* init kms poll for handling hpd */
drm_kms_helper_poll_init(dev);
 
-   /* force detection after connectors init */
-   (void)drm_helper_hpd_irq_event(dev);
+   priv->fbdev = drm_fbdev_cma_init(dev, 32,
+dev->mode_config.num_connector);
+   if (IS_ERR(priv->fbdev)) {
+   DRM_ERROR("failed to initialize fbdev.\n");
+   ret = PTR_ERR(priv->fbdev);
+   goto err_cleanup_poll;
+   }
 
return 0;
 
+err_cleanup_poll:
+   drm_kms_helper_poll_fini(dev);
 err_unbind_all:
component_unbind_all(dev->dev, dev);
 err_dc_cleanup:
-- 
2.11.0

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

[Intel-gfx] [PATCH] dim: Fixes/polish for cherry-pick

[Daniel Vetter]

- Subcommands without subshell is nice, except it can break worktree
  setups: Branch specific commands want to run in the worktree,
  general commands like dim_cite switch back to the main directory.
  Tears ensue (or well, some cryptic complaint from git that
  cherry-pick --abort failed because there's no cherry-pick in
  progress). Run it in a subshell.

  Not sure we need a general fix to make this more robust.

- Document commands a bit better.

Cc: Jani Nikula 
Acked-by: Jani Nikula 
Signed-off-by: Daniel Vetter 
---
 dim | 2 +-
 dim.rst | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/dim b/dim
index 267dbc0313b1..6a87f99e9c2d 100755
--- a/dim
+++ b/dim
@@ -997,7 +997,7 @@ function dim_cherry_pick_branch
commit_list_references $commit
if ! git cherry-pick -x -s $commit; then
echo "FAILED: $(dim_cite $commit)"
-   dim_cite $commit >> $fail_log
+   (dim_cite $commit) >> $fail_log
git cherry-pick --abort
fi
done
diff --git a/dim.rst b/dim.rst
index 10572f139130..4d3eaa846e17 100644
--- a/dim.rst
+++ b/dim.rst
@@ -323,7 +323,9 @@ cherry-pick-next-fixes
 --
 Look for non-upstreamed fixes (commits tagged Cc: sta...@vger.kernel.org or Cc:
 drm-intel-fi...@lists.freedesktop.org) in drm-intel-next-queued, and try to
-cherry-pick them to drm-intel-fixes or drm-intel-next-fixes.
+cherry-pick them to drm-intel-fixes or drm-intel-next-fixes. These commands use
+dim cherry-pick internally to make sure bugfixes for fixes are cherry-picked
+too.
 
 pull-request *branch* *upstream*
 
-- 
2.11.0

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

[Intel-gfx] ✓ Fi.CI.BAT: success for fbdev locking rework and deferred setup, take 2 (rev2)

[Patchwork]

== Series Details ==

Series: fbdev locking rework and deferred setup, take 2 (rev2)
URL   : https://patchwork.freedesktop.org/series/26437/
State : success

== Summary ==

Series 26437v2 fbdev locking rework and deferred setup, take 2
https://patchwork.freedesktop.org/api/1.0/series/26437/revisions/2/mbox/

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:438s
fi-bdw-gvtdvmtotal:279  pass:257  dwarn:8   dfail:0   fail:0   skip:14  
time:426s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:356s
fi-bsw-n3050 total:279  pass:242  dwarn:1   dfail:0   fail:0   skip:36  
time:530s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:505s
fi-byt-j1900 total:279  pass:253  dwarn:2   dfail:0   fail:0   skip:24  
time:487s
fi-byt-n2820 total:279  pass:249  dwarn:2   dfail:0   fail:0   skip:28  
time:485s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:596s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:434s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:417s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:421s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:495s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:469s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:466s
fi-kbl-7560u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:568s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:580s
fi-pnv-d510  total:279  pass:221  dwarn:3   dfail:0   fail:0   skip:55  
time:555s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:450s
fi-skl-6700hqtotal:279  pass:223  dwarn:1   dfail:0   fail:30  skip:24  
time:341s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:466s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:474s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:430s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:547s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:415s

51ebcf3056873a715adda8d12449fbaad9b1b9f4 drm-tip: 2017y-06m-27d-20h-39m-13s UTC 
integration manifest
dc0a528 drm/atomic-helper: Realign function parameters
bd8562e drm/hisilicon: Remove custom FB helper deferred setup
a5fa9bd drm/exynos: Remove custom FB helper deferred setup
d13237b drm/fb-helper: Support deferred setup
b6fd921 drm/fb-helper: Split dpms handling into legacy and atomic paths
85eca32 drm/fb-helper: Stop using mode_config.mutex for internals
9c5a78e drm/fb-helper: Push locking into restore_fbdev_mode_atomic|legacy
4e6d765 drm/fb-helper: Push locking into pan_display_atomic|legacy
3f0dacf drm/fb-helper: Drop locking from the vsync wait ioctl code
a207f8d drm/fb-helper: Push locking in fb_is_bound
9f59a3c drm/fb-helper: Add top-level lock
d53b06d drm/i915: Drop FBDEV #ifdev in mst code
455bdc2 drm/fb-helper: Push down modeset lock into FB helpers

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5055/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Cancel pending execlists irq handler upon idling

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-06-28 09:59:04)
> 
> On 27/06/2017 16:25, Chris Wilson wrote:
> > Due to the slight asynchronicity in handling the execlists interrupts
> > (i.e. we defer the work to a handler that may consume more than one
> > interrupt event), when the engine is idle we may still have an irq
> > tasklet queued (especially when it has been deferred to a ksoftirqd).
> > At the beginning of the tasklet, we assert that we do hold a device
> > wakeref for the access we are about to perform. This assumes that when
> > we idle and release the GT wakeref, all execlists work has been
> > completed (since the elsp tracking says the hw is idle). However, there
> > may still be a tasklet queued, so as we mark the engine idle, also
> > cancel any pending tasklet.
> 
> We check the irq_posted bit which should correspond with a pending 
> tasklet (intel_engines_are_idle/intel_engine_is_idle), before 
> transitioning to idle so I don't understand this.

Exactly, we've processed the interrupt in the current irq handler, but
due to the ordering (which is essential to ensure that we don't miss an
interrupt, i.e. the strong ordering is via the tasklet atomic ops so
that each interrupt is always followed by a tasklet, at least if we do
have elsp[]!) we can queue a second tasklet execution despite it already
being handled concurrently.

Run long enough and this rare event will then coincide with idling.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Cancel pending execlists irq handler upon idling

[Tvrtko Ursulin]

On 28/06/2017 11:01, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2017-06-28 09:59:04)


On 27/06/2017 16:25, Chris Wilson wrote:

Due to the slight asynchronicity in handling the execlists interrupts
(i.e. we defer the work to a handler that may consume more than one
interrupt event), when the engine is idle we may still have an irq
tasklet queued (especially when it has been deferred to a ksoftirqd).
At the beginning of the tasklet, we assert that we do hold a device
wakeref for the access we are about to perform. This assumes that when
we idle and release the GT wakeref, all execlists work has been
completed (since the elsp tracking says the hw is idle). However, there
may still be a tasklet queued, so as we mark the engine idle, also
cancel any pending tasklet.


We check the irq_posted bit which should correspond with a pending
tasklet (intel_engines_are_idle/intel_engine_is_idle), before
transitioning to idle so I don't understand this.


Exactly, we've processed the interrupt in the current irq handler, but
due to the ordering (which is essential to ensure that we don't miss an
interrupt, i.e. the strong ordering is via the tasklet atomic ops so
that each interrupt is always followed by a tasklet, at least if we do
have elsp[]!) we can queue a second tasklet execution despite it already
being handled concurrently.

Run long enough and this rare event will then coincide with idling.


Ah rings a bell now. That would mean the irq_posted bit being consumed 
by the current tasklet, and then the next one coming along as designed.


Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support

[Takashi Iwai]

On Mon, 26 Jun 2017 19:54:49 +0200,
Daniel Vetter wrote:
> 
> On Mon, Jun 26, 2017 at 7:47 PM, Takashi Iwai  wrote:
> > On Mon, 26 Jun 2017 18:16:30 +0200,
> > Daniel Vetter wrote:
> >>
> >> On Wed, Jun 21, 2017 at 05:30:10PM +0200, Takashi Iwai wrote:
> >> > On Wed, 21 Jun 2017 17:23:57 +0200,
> >> > Chris Wilson wrote:
> >> > >
> >> > > Quoting Daniel Vetter (2017-06-21 16:08:54)
> >> > > > So back when the i915 power well support landed in
> >> > > >
> >> > > > commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6
> >> > > > Author: Wang Xingchao 
> >> > > > Date:   Thu May 30 22:07:10 2013 +0800
> >> > > >
> >> > > > ALSA: hda - Add power-welll support for haswell HDA
> >> > > >
> >> > > > the logic to handle the cross-module depencies was hand-rolled using 
> >> > > > a
> >> > > > async work item, and that just doesn't work.
> >> > > >
> >> > > > The correct way to handle cross-module deps is either:
> >> > > > - request_module + failing when the other module isn't there
> >> > > >
> >> > > > OR
> >> > > >
> >> > > > - failing the module load with EPROBE_DEFER.
> >> > > >
> >> > > > You can't mix them, if you do then the entire load path just
> >> > > > busy-spins blowing through cpu cycles forever with no way to stop
> >> > > > this.
> >> > > >
> >> > > > snd-hda-intel does mix it, because the hda codec drivers are loaded
> >> > > > using request_module, but the i915 depency is handled using
> >> > > > PROBE_DEFER (or well, should be, but I haven't found any code at 
> >> > > > all).
> >> > > > This is a major pain when trying to debug i915 load failures.
> >> > > >
> >> > > > This patch here is a horrible hackish attempt at somewhat correctly
> >> > > > wriing EPROBE_DEFER through. Stuff that's missing:
> >> > > > - Check all the other places where load errors are conveniently
> >> > > >   dropped on the floor.
> >> > > > - Also fix up the firmware_cb path.
> >> > > > - Drop the debug noise I've left in to make it clear this isn't
> >> > > >   anything for merging.
> >> > >
> >> > > This tames "hdaudio hdaudioC0D0: Unable to bind the codec" which was
> >> > > continuously spewing previously, and now the system is usable again.
> >> >
> >> > Could you give a failing scenario?  I'm not opposing to the suggested
> >> > solution, we need to fix the mess in anyway, but I just would like to
> >> > know how to trigger the problem easily.
> >>
> >> Disable i915 loading e.g. with i915.modeset=0. Watch how snd-hda*
> >> collective blow through 100% of the cpu time spewing into dmesg (and make
> >> the system completely unuseable for kernel work because you can't find
> >> your own debug printk anymore).
> >
> > Ah, that's the case we discussed in the past.  We know that it's
> > problematic for component binding, but we're ignoring this scenario
> > because it's supposed to be no real use-case but only for some
> > temporary workarounds.
> >
> > We had some bigger-hammer patchset, but it didn't justify for the
> > further development of the reasoning above.
> >
> >> This is on a snb, where we don't even need the cross-module stuff ... But
> >> I think it goes sideways in other cases too, if you simply build but don't
> >> load i915. So every time an i915 breaks module load things become real
> >> painful.
> >
> > Even on SNB, we still need i915 for the HDMI/DP ELD notification.  The
> > hardware inquiry over HD-audio verb was so unstable, so we rather take
> > a path directly inquiring to the gfx driver.
> 
> Ah right, forgot about that.
> 
> >> Unfortunately the patch is a bit too big for our fixup branch in drm-tip,
> >> so plan B would be to stop building snd-hda (which will make the intel
> >> audio team unhappy, but mea culpa if they don't fix this mess).
> >
> > OK, let me think and take a look for older patchset, too.
> 
> Yeah would be great if we can somehow address this, preferrably using
> EPROBE_DEFER or something else that's standard. At least the component
> stuff really doesn't work without wiring EPROBE_DEFER through.

Now I took a closer look, and this appears rather like a brown paper
bag bug, not about the deferred probe or module dependency.
The fix patch is below.  Could you check whether it works?


thanks,

Takashi

-- 8< --
From: Takashi Iwai 
Subject: [PATCH] ALSA: hda - Fix endless loop of codec configure

azx_codec_configure() loops over the codecs found on the given
controller via a linked list.  The code used to work in the past, but
in the current version, this may lead to an endless loop when a codec
binding returns an error.

The culprit is that the snd_hda_codec_configure() unregisters the
device upon error, and this eventually deletes the given codec object
from the bus.  Since the list is initialized via list_del_init(), the
next object points to the same device itself.  This behavior change
was introduced at splitting the HD-audio code code, and forgotten to
adapt it here.

For fixing this bug, just use a *_safe() version of list iteration.

Fixes: d068ebc25e6e ("ALSA: hda - 

Re: [Intel-gfx] [PATCH] drm/i915: Set all undefined MOCS entries to follow PTE

[Chris Wilson]

Quoting Francisco Jerez (2017-05-04 21:59:44)
> Chris Wilson  writes:
> 
> > On Thu, May 04, 2017 at 10:56:54AM -0700, Francisco Jerez wrote:
> >> David Weinehall  writes:
> >> 
> >> > On Thu, May 04, 2017 at 10:51:29AM +0100, Chris Wilson wrote:
> >> >> A good default for garbage entries from the user is to follow the
> >> >> default setting of the object (i.e. the PTE). Currently they use the
> >> >> uncached entry, and now the only way to accidentally hit uncached
> >> >> performance is via explicit use of the uncached MOCS or setting the
> >> >> object to uncached. Note that these entries are currently undefined in
> >> >> the ABI and we reserve the right to change them. We originally chose
> >> >> uncached to eliminate any problem with reducing the caching level in
> >> >> future, but the object is a much better definition of the minimum
> >> >> caching level.
> >> >> 
> >> 
> >> NAK.  The reason for the default being UC is that it's the only setting
> >> that guarantees full forwards compatibility with any other entry that
> >> might be added in the future.  If you default to PTE on (e)LLC and WB on
> >> L3, userspace will no longer be able to use any newly introduced entry
> >> with stricter coherency guarantees than that (e.g. any L3-uncached
> >> entry) in a backwards-compatible way.  Attempting to do so may break
> >> memory coherency assumptions of the application and lead to misrendering
> >> when run on older kernel versions (which to my judgment is a scarier
> >> failure mode than reduced performance).
> >
> > You can't use a weaker coherency model in mocs than that specified for
> > the object as you can't control other uses of the object (even just
> > memory pressure will break your assumptions).
> 
> Exactly, but you can use a stronger coherency model than the application
> requested, which is why falling back to UC should generally work for
> unknown entries but falling back to PTE+WB isn't guaranteed to.

Still wrong. GEM will write into the CPU cache believing the object is
coherent. The GPU will read from memory bypassing the CPU cache
following the UC mocs. The only safe option is for it to follow PTE.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

[Maarten Lankhorst]

Op 27-06-17 om 17:01 schreef Daniel Vetter:
> On Tue, Jun 27, 2017 at 04:29:44PM +0200, Maarten Lankhorst wrote:
>> Op 27-06-17 om 09:37 schreef Daniel Vetter:
>>> On Mon, Jun 26, 2017 at 03:44:07PM -0400, Harry Wentland wrote:
 On 2017-06-20 01:57 PM, Andrey Grodzovsky wrote:
> Problem : While running IGT kms_atomic_transition test suite i encountered
> a hang in drmHandleEvent immediately following  an atomic_commit.
> After dumping the atomic state I relized that in this case there was
> not even one CRTC attached to the state and only disabled
> planes. This probably due to a commit which hadn't changed any property
> which would require attaching crtc state. This means drmHandleEvent
> will never wake up from read since without CRTC in atomic state
> the event fd will not be signaled.
>
> Fix: Protect against this issue by failing atomic_commit early in
> drm_mode_atomic_commit where such probelm can be identified.
>
> v2:
> Fix typos and extra newlines.
>
> Change-Id: I3ee28ffae35fd1e8bfe553146c44da53da02e6f8
> Signed-off-by: Andrey Grodzovsky 
 Reviewed-by: Harry Wentland 
>>> Stalling on this hoping for the igt patch. Does it exist already?
>>> -Daniel
>>>
 Harry

> ---
>  drivers/gpu/drm/drm_atomic.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index a567310..48145bf 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1933,7 +1933,7 @@ static int prepare_crtc_signaling(struct drm_device 
> *dev,
>  {
>   struct drm_crtc *crtc;
>   struct drm_crtc_state *crtc_state;
> - int i, ret;
> + int i, c = 0, ret;
>  
>   if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)
>   return 0;
> @@ -1994,8 +1994,17 @@ static int prepare_crtc_signaling(struct 
> drm_device *dev,
>  
>   crtc_state->event->base.fence = fence;
>   }
> +
> + c++;
>   }
>  
> + /*
> +  * Having this flag means user mode pends on event which will never
> +  * reach due to lack of at least one CRTC for signaling
> +  */
> + if (c == 0 && (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
> + return -EINVAL;
> +
>   return 0;
>  }
>  
>
>> Just do it, and I'll commit this to igt?
> Ack on both the kernel patch and the igt patch, feel free to push them
> both with:
>
> Acked-by: Daniel Vetter 
>
> If you do, please add the Testcase: line to the kernel patch.
Oops, missed adding the testcase to commit message, but pushed.

I've pushed the IGT testcase as well, after fixing it up to make sure it works 
as intended.

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

Re: [Intel-gfx] [PATCH] drm/i915: Cancel pending execlists irq handler upon idling

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-06-28 11:15:36)
> 
> On 28/06/2017 11:01, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2017-06-28 09:59:04)
> >>
> >> On 27/06/2017 16:25, Chris Wilson wrote:
> >>> Due to the slight asynchronicity in handling the execlists interrupts
> >>> (i.e. we defer the work to a handler that may consume more than one
> >>> interrupt event), when the engine is idle we may still have an irq
> >>> tasklet queued (especially when it has been deferred to a ksoftirqd).
> >>> At the beginning of the tasklet, we assert that we do hold a device
> >>> wakeref for the access we are about to perform. This assumes that when
> >>> we idle and release the GT wakeref, all execlists work has been
> >>> completed (since the elsp tracking says the hw is idle). However, there
> >>> may still be a tasklet queued, so as we mark the engine idle, also
> >>> cancel any pending tasklet.
> >>
> >> We check the irq_posted bit which should correspond with a pending
> >> tasklet (intel_engines_are_idle/intel_engine_is_idle), before
> >> transitioning to idle so I don't understand this.
> > 
> > Exactly, we've processed the interrupt in the current irq handler, but
> > due to the ordering (which is essential to ensure that we don't miss an
> > interrupt, i.e. the strong ordering is via the tasklet atomic ops so
> > that each interrupt is always followed by a tasklet, at least if we do
> > have elsp[]!) we can queue a second tasklet execution despite it already
> > being handled concurrently.
> > 
> > Run long enough and this rare event will then coincide with idling.
> 
> Ah rings a bell now. That would mean the irq_posted bit being consumed 
> by the current tasklet, and then the next one coming along as designed.

Phew, I didn't have to draw the ascii flow chart. Now, for the final
execution that triggers the bug, we shouldn't actually touch hw (the irq
posted bit should be clear, and the execlists queue should also be
empty), so we could argue that the bug on is in err -- but I think it is
a useful bug on to document the intent of the wakeref being held on our
behalf and cancelling the extra work seems sensible.
 
> Reviewed-by: Tvrtko Ursulin 

Ta, consider it pushed. Not sure if CI has seen it yet, so no bugzilla
to close.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] igt/debugfs_test: Skip dummy reads for sysfs pipe crc data

[Abdiel Janulgue]

Doing this tends to takes forever.

Signed-off-by: Abdiel Janulgue 
---
 tests/debugfs_test.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/debugfs_test.c b/tests/debugfs_test.c
index 3f0eaae..3d973d9 100644
--- a/tests/debugfs_test.c
+++ b/tests/debugfs_test.c
@@ -40,7 +40,8 @@ static void read_and_discard_sysfs_entries(int path_fd)
 
while ((dirent = readdir(dir))) {
if (!strcmp(dirent->d_name, ".") ||
-   !strcmp(dirent->d_name, ".."))
+   !strcmp(dirent->d_name, "..") ||
+   !strcmp(dirent->d_name, "crc"))
continue;
if (dirent->d_type == DT_DIR) {
int sub_fd = -1;
-- 
2.7.4

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

[Intel-gfx] [PATCH] fbcon: Make fbcon a built-time depency for fbdev

[Daniel Vetter]

There's a bunch of folks who're trying to make printk less
contended and faster, but there's a problem: printk uses the
console_lock, and the console lock has become the BKL for all things
fbdev/fbcon, which in turn pulled in half the drm subsystem under that
lock. That's awkward.

There reasons for that is probably just a historical accident:

- fbcon is a runtime option of fbdev, i.e. at runtime you can pick
  whether your fbdev driver instances are used as kernel consoles.
  Unfortunately this wasn't implemented with some module option, but
  through some module loading magic: As long as you don't load
  fbcon.ko, there's no fbdev console support, but loading it (in any
  order wrt fbdev drivers) will create console instances for all fbdev
  drivers.

- This was implemented through a notifier chain. fbcon.ko enumerates
  all fbdev instances at load time and also registers itself as
  listener in the fbdev notifier. The fbdev core tries to register new
  fbdev instances with fbcon using the notifier.

- On top of that the modifier chain is also used at runtime by the
  fbdev subsystem to e.g. control backlights for panels.

- The problem is that the notifier puts a mutex locking context
  between fbdev and fbcon, which mixes up the locking contexts for
  both the runtime usage and the register time usage to notify fbcon.
  And at runtime fbcon (through the fbdev core) might call into the
  notifier from a printk critical section while console_lock is held.

- This means console_lock must be an outer lock for the entire fbdev
  subsystem, which also means it must be acquired when registering a
  new framebuffer driver as the outermost lock since we might call
  into fbcon (through the notifier) which would result in a locking
  inversion if fbcon would acquire the console_lock from its notifier
  callback (which it needs to register the console).

- console_lock can be held anywhere, since printk can be called
  anywhere, and through the above story, plus drm/kms being an fbdev
  driver, we pull in a shocking amount of locking hiercharchy
  underneath the console_lock. Which makes cleaning up printk really
  hard (not even splitting console_lock into an rwsem is all that
  useful due to this).

There's various ways to address this, but the cleanest would be to
make fbcon a compile-time option, where fbdev directly calls the fbcon
register functions from register_framebuffer, or dummy static inline
versions if fbcon is disabled. Maybe augmented with a runtime knob to
disable fbcon, if that's needed (for debugging perhaps).

But this could break some users who rely on the magic "loading
fbcon.ko enables/disables fbdev framebuffers at runtime" thing, even
if that's unlikely. Hence we must be careful:

1. Create a compile-time dependency between fbcon and fbdev in the
least minimal way. This is what this patch does.

2. Wait at least 1 year to give possible users time to scream about
how we broke their setup. Unlikely, since all distros make fbcon
compile-in, and embedded platforms only compile stuff they know they
need anyway. But still.

3. Convert the notifier to direct functions calls, with dummy static
inlines if fbcon is disabled. We'll still need the fb notifier for the
other uses (like backlights), but we can probably move it into the fb
core (atm it must be built-into vmlinux).

4. Push console_lock down the call-chain, until it is down in
console_register again.

5. Finally start to clean up and rework the printk/console locking.

For context of this saga see

commit 50e244cc793d511b86adea24972f3a7264cae114
Author: Alan Cox 
Date:   Fri Jan 25 10:28:15 2013 +1000

fb: rework locking to fix lock ordering on takeover

plus the pile of commits on top that tried to make this all work
without terminally upsetting lockdep. We've uncovered all this when
console_lock lockdep annotations where added in

commit daee779718a319ff9f83e1ba3339334ac650bb22
Author: Daniel Vetter 
Date:   Sat Sep 22 19:52:11 2012 +0200

console: implement lockdep support for console_lock

On the patch itself:
- Add fbcon.h for the dummy symbol to force the module load ordering
  between fbcon.ko and fb.ko. In step 3 that's hopefully going to be
  the place for the fbcon register/unregister functions.

- Switch CONFIG_FRAMEBUFFER_CONSOLE to be a boolean, using the overall
  CONFIG_FB tristate to decided whether it should be a module or
  built-in.

Cc: Alan Cox 
Cc: Sergey Senozhatsky 
Cc: Linux Fbdev development list 
Cc: Steven Rostedt 
Cc: Bartlomiej Zolnierkiewicz 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Daniel Vetter 
---
 drivers/video/console/Kconfig| 2 +-
 drivers/video/console/Makefile   | 8 +---
 drivers/video/console/fbcon.c| 8 
 drivers/video/fbdev/core/fbmem.c | 4 
 include/linux/fbcon.h| 6 ++
 5 files changed, 24 insertions(+), 4 deletions(-)
 create mode 100644 include/linux/fbcon.h

diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
ind

[Intel-gfx] [PATCH i-g-t] lib/ioctl_wrappers: Fix some comments

[Arkadiusz Hiler]

"This is a wraps" -> "This wraps"
"hw/hardware context" -> "context"

gem_context_create does not use igt_require() but igt_skip_on() so make
the similarity note more vague and in result true.

Cc: Daniel Vetter 
Cc: Radoslaw Szwichtenberg 
Signed-off-by: Arkadiusz Hiler 
---
 lib/ioctl_wrappers.c | 32 +++-
 1 file changed, 15 insertions(+), 17 deletions(-)

diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 8e5ec88..2bbaed5 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -881,7 +881,7 @@ void *gem_mmap__cpu(int fd, uint32_t handle, uint64_t 
offset, uint64_t size, uns
  * @handle: gem buffer object handle
  * @state: desired madvise state
  *
- * This is a wraps the MADVISE ioctl, which is used in libdrm to implement
+ * This wraps the MADVISE ioctl, which is used in libdrm to implement
  * opportunistic buffer object caching. Objects in the cache are set to 
DONTNEED
  * (internally in the kernel tracked as purgeable objects). When such a cached
  * object is in need again it must be set back to WILLNEED before first use.
@@ -906,12 +906,11 @@ int gem_madvise(int fd, uint32_t handle, int state)
  * gem_context_create:
  * @fd: open i915 drm file descriptor
  *
- * This is a wraps the CONTEXT_CREATE ioctl, which is used to allocate a new
- * hardware context. Not that similarly to gem_set_caching() this wrapper calls
- * igt_require() internally to correctly skip on kernels and platforms where hw
- * context support is not available.
+ * This wraps the CONTEXT_CREATE ioctl, which is used to allocate a new
+ * context. Note that similarly to gem_set_caching() this wrapper skips on
+ * kernels and platforms where context support is not available.
  *
- * Returns: The id of the allocated hw context.
+ * Returns: The id of the allocated context.
  */
 uint32_t gem_context_create(int fd)
 {
@@ -946,10 +945,9 @@ int __gem_context_destroy(int fd, uint32_t ctx_id)
 /**
  * gem_context_destroy:
  * @fd: open i915 drm file descriptor
- * @ctx_id: i915 hw context id
+ * @ctx_id: i915 context id
  *
- * This is a wraps the CONTEXT_DESTROY ioctl, which is used to free a hardware
- * context.
+ * This wraps the CONTEXT_DESTROY ioctl, which is used to free a context.
  */
 void gem_context_destroy(int fd, uint32_t ctx_id)
 {
@@ -975,9 +973,9 @@ int __gem_context_get_param(int fd, struct 
local_i915_gem_context_param *p)
 /**
  * gem_context_get_param:
  * @fd: open i915 drm file descriptor
- * @p: i915 hw context parameter
+ * @p: i915 context parameter
  *
- * This is a wraps the CONTEXT_GET_PARAM ioctl, which is used to get a context
+ * This wraps the CONTEXT_GET_PARAM ioctl, which is used to get a context
  * parameter.
  */
 void gem_context_get_param(int fd, struct local_i915_gem_context_param *p)
@@ -999,9 +997,9 @@ int __gem_context_set_param(int fd, struct 
local_i915_gem_context_param *p)
 /**
  * gem_context_set_param:
  * @fd: open i915 drm file descriptor
- * @p: i915 hw context parameter
+ * @p: i915 context parameter
  *
- * This is a wraps the CONTEXT_SET_PARAM ioctl, which is used to set a context
+ * This wraps the CONTEXT_SET_PARAM ioctl, which is used to set a context
  * parameter.
  */
 void gem_context_set_param(int fd, struct local_i915_gem_context_param *p)
@@ -1012,9 +1010,9 @@ void gem_context_set_param(int fd, struct 
local_i915_gem_context_param *p)
 /**
  * gem_context_require_param:
  * @fd: open i915 drm file descriptor
- * @param: i915 hw context parameter
+ * @param: i915 context parameter
  *
- * Feature test macro to query whether hw context parameter support for @param
+ * Feature test macro to query whether context parameter support for @param
  * is available. Automatically skips through igt_require() if not.
  */
 void gem_context_require_param(int fd, uint64_t param)
@@ -1098,7 +1096,7 @@ void gem_userptr(int fd, void *ptr, int size, int 
read_only, uint32_t flags, uin
  * @fd: open i915 drm file descriptor
  * @handle: gem buffer object handle
  *
- * This is a wraps the SW_FINISH ioctl, which is used to flush out frontbuffer
+ * This wraps the SW_FINISH ioctl, which is used to flush out frontbuffer
  * rendering done through the direct cpu memory mappings. Shipping userspace
  * does _not_ call this after frontbuffer rendering through gtt memory 
mappings.
  */
@@ -1117,7 +1115,7 @@ void gem_sw_finish(int fd, uint32_t handle)
  * @fd: open i915 drm file descriptor
  * @handle: gem buffer object handle
  *
- * This is a wraps the BUSY ioctl, which tells whether a buffer object is still
+ * This wraps the BUSY ioctl, which tells whether a buffer object is still
  * actively used by the gpu in a execbuffer.
  *
  * Returns: The busy state of the buffer object.
-- 
2.9.4

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

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Hold RPM wakelock while initializing OA buffer

[Lionel Landwerlin]

Hi Sagar,

Thanks for this patch, it all looks good to me :

Reviewed-by: Lionel Landwerlin 

On 27/06/17 20:39, Sagar Arun Kamble wrote:

OA buffer initialization involves access to HW registers to set
the OA base, head and tail. Ensure device is awake while setting
these. With this, all oa.ops are covered under RPM and forcewake
wakelock.

Cc: Lionel Landwerlin 
Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/i915_perf.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 38c4440..9cd22f8 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2067,10 +2067,6 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
return ret;
}
  
-	ret = alloc_oa_buffer(dev_priv);

-   if (ret)
-   goto err_oa_buf_alloc;
-
/* PRM - observability performance counters:
 *
 *   OACONTROL, performance counter enable, note:
@@ -2086,6 +2082,10 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
intel_runtime_pm_get(dev_priv);
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
  
+	ret = alloc_oa_buffer(dev_priv);

+   if (ret)
+   goto err_oa_buf_alloc;
+
ret = dev_priv->perf.oa.ops.enable_metric_set(dev_priv);
if (ret)
goto err_enable;
@@ -2097,11 +2097,11 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
return 0;
  
  err_enable:

-   intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
-   intel_runtime_pm_put(dev_priv);
free_oa_buffer(dev_priv);
  
  err_oa_buf_alloc:

+   intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+   intel_runtime_pm_put(dev_priv);
if (stream->ctx)
oa_put_render_ctx_id(stream);
  



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

Re: [Intel-gfx] [PATCH i-g-t v2] lib/ioctl_wrappers: Fix function descriptions

[Arkadiusz Hiler]

On Fri, Jun 23, 2017 at 04:01:05PM +0200, Radoslaw Szwichtenberg wrote:
> Function description incorrectly stated that gem_context_get_param
> and gem_context_set_param were freeing hw context.
> 
> v2: removed additional incorrect information
> 
> Signed-off-by: Radoslaw Szwichtenberg 
Reviewed-by: Arkadiusz Hiler 

I'll push it in a moment, thanks!

I followed up with a couple of similar fixes around the area, on top of
your patch.

Feel free to review them :-)

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

Re: [Intel-gfx] [PATCH i-g-t] igt/debugfs_test: Skip dummy reads for sysfs pipe crc data

[Arkadiusz Hiler]

On Wed, Jun 28, 2017 at 01:33:16PM +0300, Abdiel Janulgue wrote:
> Doing this tends to takes forever.
> 
> Signed-off-by: Abdiel Janulgue 
> ---
>  tests/debugfs_test.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/debugfs_test.c b/tests/debugfs_test.c
> index 3f0eaae..3d973d9 100644
> --- a/tests/debugfs_test.c
> +++ b/tests/debugfs_test.c
> @@ -40,7 +40,8 @@ static void read_and_discard_sysfs_entries(int path_fd)
>  
>   while ((dirent = readdir(dir))) {
>   if (!strcmp(dirent->d_name, ".") ||
> - !strcmp(dirent->d_name, ".."))
> + !strcmp(dirent->d_name, "..") ||
> + !strcmp(dirent->d_name, "crc"))

Do we have one that actually is named just "crc"?

IIRC 'i915_something_crc_something' was the format, and the check won't
catch them.

-- 
Cheers,
Arek

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

[Intel-gfx] [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s

[Marta Lofstedt]

The subtests: igt@kms_frontbuffer_tracking@fbc-*draw*
has non-consistent results, pending between fail and pass.
The fails are always due to "FBC disabled".
With this increase in timeout the flip-flop behavior is no
longer reproducible.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623
Signed-off-by: Marta Lofstedt 
---
 tests/kms_frontbuffer_tracking.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index c24e4a81..8bec5d5a 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -923,7 +923,7 @@ static bool fbc_stride_not_supported(void)
 
 static bool fbc_wait_until_enabled(void)
 {
-   return igt_wait(fbc_is_enabled(), 2000, 1);
+   return igt_wait(fbc_is_enabled(), 5000, 1);
 }
 
 static bool psr_wait_until_enabled(void)
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH] drm/i915: Drop flushing of the object free list/worker from i915_gem_suspend

[Chris Wilson]

Quoting David Weinehall (2017-06-27 18:57:34)
> On Tue, Jun 27, 2017 at 06:37:31PM +0100, Chris Wilson wrote:
> > i915_gem_suspend() is called from all of our finalization paths
> > (suspend, hibernate, unload). i915_gem_drain_freed_objects() adds an
> > arbitrary delay as it uses an rcu_barrier() to ensure that there are no
> > more freed objects in flight, and this delay causes a large amount of
> > variability in suspend timings. For S3 suspend, we do not need to free
> > pages as doing so does not impact at all upon the system in its
> > suspended state, unlike S4 hibernation where we do want the hibernation
> > image to be as small as possible. Therefore we can forgo waiting inside
> > i915_gem_suspend(), so long as we ensure that we do cleanup before
> > unload (see i915_gem_load_cleanup()) and prefer to reap our objects
> > prior to hibernation (see i915_gem_freeze()).
> > 
> > Removing the rcu_barrier() from i915_gem_suspend() improves S3 latency
> > by about 30ms on Skylake (ymmv).
> > 
> > Reported-by: David Weinehall 
> > Signed-off-by: Chris Wilson 
> > Cc: David Weinehall 
> 
> Tested-by: David Weinehall 
> Reviewed-by: David Weinehall 

Thanks for the heads up and testing the patch, pushed.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/fbdev: Check for existence of ifbdev->vma before operations

[Chris Wilson]

Quoting Chris Wilson (2017-06-22 17:02:11)
> Commit fabef825626d ("drm/i915: Drop struct_mutex around frontbuffer
> flushes") adds a dependency to ifbdev->vma when flushing the framebufer,
> but the checks are only against the existence of the ifbdev->fb and not
> against ifbdev->vma. This leaves a window of opportunity where we may
> try to operate on the fbdev prior to it being probed (thanks to
> asynchronous booting).
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101534
> Fixes: fabef825626d ("drm/i915: Drop struct_mutex around frontbuffer flushes")
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Daniel Vetter 

Ping?

> ---
>  drivers/gpu/drm/i915/intel_fbdev.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 03347c6ae599..0c4cde6b2e6f 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -535,13 +535,14 @@ static void intel_fbdev_destroy(struct intel_fbdev 
> *ifbdev)
>  
> drm_fb_helper_fini(&ifbdev->helper);
>  
> -   if (ifbdev->fb) {
> +   if (ifbdev->vma) {
> mutex_lock(&ifbdev->helper.dev->struct_mutex);
> intel_unpin_fb_vma(ifbdev->vma);
> mutex_unlock(&ifbdev->helper.dev->struct_mutex);
> +   }
>  
> +   if (ifbdev->fb)
> drm_framebuffer_remove(&ifbdev->fb->base);
> -   }
>  
> kfree(ifbdev);
>  }
> @@ -765,7 +766,7 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int 
> state, bool synchronous
> struct intel_fbdev *ifbdev = dev_priv->fbdev;
> struct fb_info *info;
>  
> -   if (!ifbdev || !ifbdev->fb)
> +   if (!ifbdev || !ifbdev->vma)
> return;
>  
> info = ifbdev->helper.fbdev;
> @@ -812,7 +813,7 @@ void intel_fbdev_output_poll_changed(struct drm_device 
> *dev)
>  {
> struct intel_fbdev *ifbdev = to_i915(dev)->fbdev;
>  
> -   if (ifbdev && ifbdev->fb)
> +   if (ifbdev && ifbdev->vma)
> drm_fb_helper_hotplug_event(&ifbdev->helper);
>  }
>  
> @@ -824,7 +825,7 @@ void intel_fbdev_restore_mode(struct drm_device *dev)
> return;
>  
> intel_fbdev_sync(ifbdev);
> -   if (!ifbdev->fb)
> +   if (!ifbdev->vma)
> return;
>  
> if (drm_fb_helper_restore_fbdev_mode_unlocked(&ifbdev->helper) == 0)
> -- 
> 2.13.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for fbcon: Make fbcon a built-time depency for fbdev

[Patchwork]

== Series Details ==

Series: fbcon: Make fbcon a built-time depency for fbdev
URL   : https://patchwork.freedesktop.org/series/26477/
State : success

== Summary ==

Series 26477v1 fbcon: Make fbcon a built-time depency for fbdev
https://patchwork.freedesktop.org/api/1.0/series/26477/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-pnv-d510) fdo#101597
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-byt-j1900) fdo#101517

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597
fdo#101517 https://bugs.freedesktop.org/show_bug.cgi?id=101517

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:438s
fi-bdw-gvtdvmtotal:279  pass:257  dwarn:8   dfail:0   fail:0   skip:14  
time:431s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:364s
fi-bsw-n3050 total:279  pass:242  dwarn:1   dfail:0   fail:0   skip:36  
time:534s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:506s
fi-byt-j1900 total:279  pass:253  dwarn:2   dfail:0   fail:0   skip:24  
time:481s
fi-byt-n2820 total:279  pass:249  dwarn:2   dfail:0   fail:0   skip:28  
time:484s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:600s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:435s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:411s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:415s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:501s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:477s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:466s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:578s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:587s
fi-pnv-d510  total:279  pass:221  dwarn:3   dfail:0   fail:0   skip:55  
time:557s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:459s
fi-skl-6700hqtotal:279  pass:223  dwarn:1   dfail:0   fail:30  skip:24  
time:343s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:472s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:471s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:434s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:539s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:399s

66ce0778a886b8907b12f83fe47858d2e87ac1e1 drm-tip: 2017y-06m-28d-10h-31m-55s UTC 
integration manifest
a22da25 fbcon: Make fbcon a built-time depency for fbdev

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5056/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] lib/ioctl_wrappers: Fix some comments

[Szwichtenberg, Radoslaw]

On Wed, 2017-06-28 at 13:40 +0300, Arkadiusz Hiler wrote:
> "This is a wraps" -> "This wraps"
> "hw/hardware context" -> "context"
> 
> gem_context_create does not use igt_require() but igt_skip_on() so make
> the similarity note more vague and in result true.
> 
> Cc: Daniel Vetter 
> Cc: Radoslaw Szwichtenberg 
> Signed-off-by: Arkadiusz Hiler 
Reviewed-by: Radoslaw Szwichtenberg 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC v4 1/2] drm/i915: Engine discovery uAPI

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-06-26 16:47:41)
> From: Tvrtko Ursulin 
> 
> Engine discovery uAPI allows userspace to probe for engine
> configuration and features without needing to maintain the
> internal PCI id based database.
> 
> This enables removal of code duplications across userspace
> components.
> 
> Probing is done via the new DRM_IOCTL_I915_GEM_ENGINE_INFO ioctl
> which returns the number and information on the specified engine
> class.
> 
> Currently only general engine configuration and HEVC feature of
> the VCS engine can be probed but the uAPI is designed to be
> generic and extensible.
> 
> Code is based almost exactly on the earlier proposal on the
> topic by Jon Bloomfield. Engine class and instance refactoring
> made recently by Daniele Ceraolo Spurio enabled this to be
> implemented in an elegant fashion.
> 
> To probe configuration userspace sets the engine class it wants
> to query (struct drm_i915_gem_engine_info) and provides an array
> of drm_i915_engine_info structs which will be filled in by the
> driver. Userspace also has to tell i915 how many elements are in
> the array, and the driver will report back the total number of
> engine instances in any case.
> 
> v2:
>  * Add a version field and consolidate to one engine count.
>(Chris Wilson)
>  * Rename uAPI flags for VCS engines to DRM_I915_ENGINE_CLASS_VIDEO.
>(Gong Zhipeng)
> 
> v3:
>  * Drop the DRM_ prefix from uAPI enums. (Chris Wilson)
>  * Only reserve 8-bits for the engine info for time being.
> 
> v4:
>  * Made user_class_map static.
> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Ben Widawsky 
> Cc: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Joonas Lahtinen 
> Cc: Jon Bloomfield 
> Cc: "Rogozhkin, Dmitry V" 
> Cc: Oscar Mateo 
> Cc: "Gong, Zhipeng" 
> ---
>  drivers/gpu/drm/i915/i915_drv.c|  1 +
>  drivers/gpu/drm/i915/i915_drv.h|  3 ++
>  drivers/gpu/drm/i915/intel_engine_cs.c | 64 
> ++
>  include/uapi/drm/i915_drm.h| 41 ++
>  4 files changed, 109 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index e9d8e9ee51b2..44dd2f37937f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2724,6 +2724,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
> DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, 
> i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, 
> i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
> DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(I915_GEM_ENGINE_INFO, i915_gem_engine_info_ioctl, 
> DRM_RENDER_ALLOW),
>  };
>  
>  static struct drm_driver driver = {
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 427d10c7eca5..496565e1753f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3598,6 +3598,9 @@ void i915_oa_init_reg_state(struct intel_engine_cs 
> *engine,
> struct i915_gem_context *ctx,
> uint32_t *reg_state);
>  
> +int i915_gem_engine_info_ioctl(struct drm_device *dev, void *data,
> +  struct drm_file *file);
> +
>  /* i915_gem_evict.c */
>  int __must_check i915_gem_evict_something(struct i915_address_space *vm,
>   u64 min_size, u64 alignment,
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 3b46c1f7b88b..a98669f6ad85 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -25,6 +25,7 @@
>  #include "i915_drv.h"
>  #include "intel_ringbuffer.h"
>  #include "intel_lrc.h"
> +#include 
>  
>  /* Haswell does have the CXT_SIZE register however it does not appear to be
>   * valid. Now, docs explain in dwords what is in the context object. The full
> @@ -1332,6 +1333,69 @@ void intel_engines_mark_idle(struct drm_i915_private 
> *i915)
> }
>  }
>  
> +static u8 user_class_map[I915_ENGINE_CLASS_MAX] = {
> +   [I915_ENGINE_CLASS_OTHER] = OTHER_CLASS,
> +   [I915_ENGINE_CLASS_RENDER] = RENDER_CLASS,
> +   [I915_ENGINE_CLASS_COPY] = COPY_ENGINE_CLASS,
> +   [I915_ENGINE_CLASS_VIDEO] = VIDEO_DECODE_CLASS,
> +   [I915_ENGINE_CLASS_VIDEO_ENHANCE] = VIDEO_ENHANCEMENT_CLASS,
> +};
> +
> +int i915_gem_engine_info_ioctl(struct drm_device *dev, void *data,
> +  struct drm_file *file)
> +{
> +   struct drm_i915_private *i915 = to_i915(dev);
> +   struct drm_i915_gem_engine_info *args = data;
> +   struct drm_i915_engine_info __user *user_info =
> +   u64_to_user_ptr(args->info_ptr);
> +   unsigned int info_size = args->num_engines;
> +   struct drm_i915_engine_info info;
> +   struct intel_engine_

[Intel-gfx] [PATCH] drm/fb-helper: Support deferred setup

[Daniel Vetter]

FB helper code falls back to a 1024x768 mode if no outputs are connected
or don't report back any modes upon initialization. This can be annoying
because outputs that are added to FB helper later on can't be used with
FB helper if they don't support a matching mode.

The fallback is in place because VGA connectors can happen to report an
unknown connection status even when they are in fact connected.

Some drivers have custom solutions in place to defer FB helper setup
until at least one output is connected. But the logic behind these
solutions is always the same and there is nothing driver-specific about
it, so a better alterative is to fix the FB helper core and add support
for all drivers automatically.

This patch adds support for deferred FB helper setup. It checks all the
connectors for their connection status, and if all of them report to be
disconnected marks the FB helper as needing deferred setup. Whet setup
is deferred, the FB helper core will automatically retry setup after a
hotplug event, and it will keep trying until it succeeds.

v2: Rebase onto my entirely reworked fbdev helper locking. One big
difference is that this version again drops&reacquires the fbdev lock
(which is now fb_helper->lock, but before this patch series it was
mode_config->mutex), because register_framebuffer must be able to
recurse back into fbdev helper code for the initial screen setup.

v3: __drm_fb_helper_initial_config must hold fb_helper->lock upon
return, I've fumbled that in the deferred setup case (Liviu).

v4: I was blind, redo this all. __drm_fb_helper_initial_config
shouldn't need to reacquire fb_helper->lock, that just confuses
callers. I myself got confused by kernel_fb_helper_lock and somehow
thought it's the same as fb_helper->lock. Tsk.

Also simplify the logic a bit (we don't need two functions to probe
connectors), we can stick much closer to the existing code. And update
some comments I've spotted that are outdated.

v5: Don't pass -EAGAIN to drivers, it's just an internal error code
(Liviu).

Cc: Liviu Dudau 
Cc: John Stultz 
Cc: Thierry Reding  (v1)
Tested-by: John Stultz 
Signed-off-by: Thierry Reding  (v1)
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c | 101 ++--
 include/drm/drm_fb_helper.h |  23 +
 2 files changed, 89 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index bbd4c6d0378d..e49bae10f0ee 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -521,6 +521,9 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct 
drm_fb_helper *fb_helper)
if (!drm_fbdev_emulation)
return -ENODEV;
 
+   if (READ_ONCE(fb_helper->deferred_setup))
+   return 0;
+
mutex_lock(&fb_helper->lock);
ret = restore_fbdev_mode(fb_helper);
 
@@ -1695,8 +1698,7 @@ EXPORT_SYMBOL(drm_fb_helper_pan_display);
 
 /*
  * Allocates the backing storage and sets up the fbdev info structure through
- * the ->fb_probe callback and then registers the fbdev and sets up the panic
- * notifier.
+ * the ->fb_probe callback.
  */
 static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper,
 int preferred_bpp)
@@ -1794,13 +1796,8 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
}
 
if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
-   /*
-* hmm everyone went away - assume VGA cable just fell out
-* and will come back later.
-*/
-   DRM_INFO("Cannot find any crtc or sizes - going 1024x768\n");
-   sizes.fb_width = sizes.surface_width = 1024;
-   sizes.fb_height = sizes.surface_height = 768;
+   DRM_INFO("Cannot find any crtc or sizes\n");
+   return -EAGAIN;
}
 
/* Handle our overallocation */
@@ -2429,6 +2426,58 @@ static void drm_setup_crtcs(struct drm_fb_helper 
*fb_helper,
kfree(enabled);
 }
 
+/* Note: Drops fb_helper->lock before returning. */
+static int __drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper,
+ int bpp_sel)
+{
+   struct drm_device *dev = fb_helper->dev;
+   struct fb_info *info;
+   unsigned int width, height;
+   int ret;
+
+   width = dev->mode_config.max_width;
+   height = dev->mode_config.max_height;
+
+   drm_setup_crtcs(fb_helper, width, height);
+   ret = drm_fb_helper_single_fb_probe(fb_helper, bpp_sel);
+   if (ret < 0) {
+   if (ret == -EAGAIN) {
+   fb_helper->preferred_bpp = bpp_sel;
+   fb_helper->deferred_setup = true;
+   ret = 0;
+   }
+   mutex_unlock(&fb_helper->lock);
+
+   return ret;
+   }
+
+   fb_helper->deferred_setup 

Re: [Intel-gfx] [RFC v4 1/2] drm/i915: Engine discovery uAPI

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-06-26 16:47:41)
> From: Tvrtko Ursulin 
> 
> Engine discovery uAPI allows userspace to probe for engine
> configuration and features without needing to maintain the
> internal PCI id based database.
> 
> This enables removal of code duplications across userspace
> components.
> 
> Probing is done via the new DRM_IOCTL_I915_GEM_ENGINE_INFO ioctl
> which returns the number and information on the specified engine
> class.
> 
> Currently only general engine configuration and HEVC feature of
> the VCS engine can be probed but the uAPI is designed to be
> generic and extensible.
> 
> Code is based almost exactly on the earlier proposal on the
> topic by Jon Bloomfield. Engine class and instance refactoring
> made recently by Daniele Ceraolo Spurio enabled this to be
> implemented in an elegant fashion.
> 
> To probe configuration userspace sets the engine class it wants
> to query (struct drm_i915_gem_engine_info) and provides an array
> of drm_i915_engine_info structs which will be filled in by the
> driver. Userspace also has to tell i915 how many elements are in
> the array, and the driver will report back the total number of
> engine instances in any case.

Include psuedo code to first show how to do the multipass query followed
by an example hooking it to execbuf.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] fbcon: Make fbcon a built-time depency for fbdev

[Daniel Vetter]

On Wed, Jun 28, 2017 at 1:00 PM, Alan Cox  wrote:
> On Wed, 28 Jun 2017 12:36:35 +0200
> Daniel Vetter  wrote:
>
>> There's a bunch of folks who're trying to make printk less
>> contended and faster, but there's a problem: printk uses the
>> console_lock, and the console lock has become the BKL for all things
>> fbdev/fbcon, which in turn pulled in half the drm subsystem under that
>> lock. That's awkward.
>
> Yes - very. Although if you implement your console printing method with
> sufficient cunning it shouldn't cause much latency in most cases but for
> unaccelerated fb it's really bad.
>
> It also makes it unnecessarily hard for a drm driver to accelerate
> console output.

It's worse, we've had to sprinkle early returns for oops_in_progress
and pushing anything more complex than writing to an mmap region when
in_atomic() into workers stuff all over the fbdev helpers because the
calling context of the fbdev driver callbacks is so ill defined.

There's an rfc patch series for a very minimal oops handler (since
there's no way you can make a modern kms driver oops-safe), but it
hasn't landed yet.

>> 4. Push console_lock down the call-chain, until it is down in
>> console_register again.
>
> I don't think that's actually going to work out. To fix it is going to
> need more invasive changes so that you can 'create' a console and set it
> up separately to actually 'enabling' it when you make it visible and
> start scribbling. I don't see any other way to make the changeover
> locking saner at this point without still having huge potential stalls in
> printk().

Yeah, I expect that as soon as console_lock is down in the fbcon.c
code the real hard work of designing a reasonable console locking
scheme will have to start. console.c is very old skool, with big locks
instead of refcounting to keep things alive, static arrays and other
fun things. It'll need work.

We'll probably also want to untangle the normal console usage from the
emergency printing when the kernel is keeling over, since it's a
totally different environment. That would at least help drm/kms a lot.

> Reviewed-by: Alan Cox 

Thanks for reviewing.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] fbcon: Make fbcon a built-time depency for fbdev

[Alan Cox]

On Wed, 28 Jun 2017 12:36:35 +0200
Daniel Vetter  wrote:

> There's a bunch of folks who're trying to make printk less
> contended and faster, but there's a problem: printk uses the
> console_lock, and the console lock has become the BKL for all things
> fbdev/fbcon, which in turn pulled in half the drm subsystem under that
> lock. That's awkward.

Yes - very. Although if you implement your console printing method with
sufficient cunning it shouldn't cause much latency in most cases but for
unaccelerated fb it's really bad.

It also makes it unnecessarily hard for a drm driver to accelerate
console output.

> 4. Push console_lock down the call-chain, until it is down in
> console_register again.

I don't think that's actually going to work out. To fix it is going to
need more invasive changes so that you can 'create' a console and set it
up separately to actually 'enabling' it when you make it visible and
start scribbling. I don't see any other way to make the changeover
locking saner at this point without still having huge potential stalls in
printk().

Reviewed-by: Alan Cox 


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

Re: [Intel-gfx] [RESEND i-g-t 1/3] lib/cfl: Add Coffeelake PCI IDs for S SKU.

[Arkadiusz Hiler]

On Thu, Jun 22, 2017 at 09:28:35AM -0700, Anusha Srivatsa wrote:
> From: anushasr 
> 
> Just following the spec and adding these extra IDs.
> 
> v2: update IDs following the kernel commit:
> b056f8f3d6b900e8afd19f312719160346d263b4 (Chris)
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: Anusha Srivatsa 
> Reviewed-by: Clint Taylor 
> ---
>  lib/i915_pciids.h   | 10 ++
>  lib/intel_device_info.c |  2 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/lib/i915_pciids.h b/lib/i915_pciids.h
> index 27e0dba..02f43d9 100644
> --- a/lib/i915_pciids.h
> +++ b/lib/i915_pciids.h
> @@ -334,4 +334,14 @@
>   INTEL_KBL_GT3_IDS(info), \
>   INTEL_KBL_GT4_IDS(info)
>  
> +#define INTEL_CFL_S_IDS(info) \
> + INTEL_VGA_DEVICE(0x3E90, info), /* SRV GT1 */ \
> + INTEL_VGA_DEVICE(0x3E93, info), /* SRV GT1 */ \
> + INTEL_VGA_DEVICE(0x3E91, info), /* SRV GT2 */ \
> + INTEL_VGA_DEVICE(0x3E92, info), /* SRV GT2 */ \
> + INTEL_VGA_DEVICE(0x3E96, info) /* SRV GT2 */
> +
> +#define INTEL_CFL_IDS(info) \
> + INTEL_CFL_S_IDS(info)
> +
>  #endif /* _I915_PCIIDS_H */
> diff --git a/lib/intel_device_info.c b/lib/intel_device_info.c
> index 199fa2d..2c46aba 100644
> --- a/lib/intel_device_info.c
> +++ b/lib/intel_device_info.c
> @@ -241,6 +241,8 @@ static const struct pci_id_match intel_device_match[] = {
>  
>   INTEL_GLK_IDS(&intel_geminilake_info),
>  
> + INTEL_CFL_IDS(&intel_coffeelake_info),

BTW, having
"From: anushasr "
on your patches resulting in quite unusual authorship lines.

Please consider using `git config --global user.name "Your Full Name"`
on the machines you are creating the patches with if this is not
intentional.

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

Re: [Intel-gfx] [RESEND i-g-t 1/3] lib/cfl: Add Coffeelake PCI IDs for S SKU.

[Arkadiusz Hiler]

On Wed, Jun 28, 2017 at 03:17:00PM +0300, Arkadiusz Hiler wrote:
> On Thu, Jun 22, 2017 at 09:28:35AM -0700, Anusha Srivatsa wrote:
> > From: anushasr 
> > 
> > Just following the spec and adding these extra IDs.
> > 
> > v2: update IDs following the kernel commit:
> > b056f8f3d6b900e8afd19f312719160346d263b4 (Chris)
> > 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: Anusha Srivatsa 
> > Reviewed-by: Clint Taylor 
> > ---
> >  lib/i915_pciids.h   | 10 ++
> >  lib/intel_device_info.c |  2 ++
> >  2 files changed, 12 insertions(+)
> > 
> > diff --git a/lib/i915_pciids.h b/lib/i915_pciids.h
> > index 27e0dba..02f43d9 100644
> > --- a/lib/i915_pciids.h
> > +++ b/lib/i915_pciids.h
> > @@ -334,4 +334,14 @@
> > INTEL_KBL_GT3_IDS(info), \
> > INTEL_KBL_GT4_IDS(info)
> >  
> > +#define INTEL_CFL_S_IDS(info) \
> > +   INTEL_VGA_DEVICE(0x3E90, info), /* SRV GT1 */ \
> > +   INTEL_VGA_DEVICE(0x3E93, info), /* SRV GT1 */ \
> > +   INTEL_VGA_DEVICE(0x3E91, info), /* SRV GT2 */ \
> > +   INTEL_VGA_DEVICE(0x3E92, info), /* SRV GT2 */ \
> > +   INTEL_VGA_DEVICE(0x3E96, info) /* SRV GT2 */
> > +
> > +#define INTEL_CFL_IDS(info) \
> > +   INTEL_CFL_S_IDS(info)
> > +
> >  #endif /* _I915_PCIIDS_H */
> > diff --git a/lib/intel_device_info.c b/lib/intel_device_info.c
> > index 199fa2d..2c46aba 100644
> > --- a/lib/intel_device_info.c
> > +++ b/lib/intel_device_info.c
> > @@ -241,6 +241,8 @@ static const struct pci_id_match intel_device_match[] = 
> > {
> >  
> > INTEL_GLK_IDS(&intel_geminilake_info),
> >  
> > +   INTEL_CFL_IDS(&intel_coffeelake_info),

Cut the important part accidentally before sending. Here it is:

Hey,

The series does not compile and intel_coffeelake_info is nowhere to be
found.

Maybe you are missing a patch from the series?

> BTW, having
> "From: anushasr "
> on your patches resulting in quite unusual authorship lines.
> 
> Please consider using `git config --global user.name "Your Full Name"`
> on the machines you are creating the patches with if this is not
> intentional.
> 
> -- 
> Cheers,
> Arek
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for fbdev locking rework and deferred setup, take 2 (rev3)

[Patchwork]

== Series Details ==

Series: fbdev locking rework and deferred setup, take 2 (rev3)
URL   : https://patchwork.freedesktop.org/series/26437/
State : success

== Summary ==

Series 26437v3 fbdev locking rework and deferred setup, take 2
https://patchwork.freedesktop.org/api/1.0/series/26437/revisions/3/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125 +1
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-pnv-d510) fdo#101597 +1

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:444s
fi-bdw-gvtdvmtotal:279  pass:257  dwarn:8   dfail:0   fail:0   skip:14  
time:423s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:354s
fi-bsw-n3050 total:279  pass:242  dwarn:1   dfail:0   fail:0   skip:36  
time:522s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:504s
fi-byt-j1900 total:279  pass:253  dwarn:2   dfail:0   fail:0   skip:24  
time:488s
fi-byt-n2820 total:279  pass:249  dwarn:2   dfail:0   fail:0   skip:28  
time:487s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:594s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:432s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:414s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:425s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:502s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:476s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:465s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:570s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:579s
fi-pnv-d510  total:279  pass:222  dwarn:2   dfail:0   fail:0   skip:55  
time:558s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:459s
fi-skl-6700hqtotal:279  pass:223  dwarn:1   dfail:0   fail:30  skip:24  
time:345s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:466s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:476s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:444s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:548s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:403s

90513552ce32ddf2a4efffa21a5df5f21a425a18 drm-tip: 2017y-06m-28d-11h-26m-16s UTC 
integration manifest
a712ea9 drm/atomic-helper: Realign function parameters
1ed8ce9 drm/hisilicon: Remove custom FB helper deferred setup
9166d3e drm/exynos: Remove custom FB helper deferred setup
61d4a4b drm/fb-helper: Support deferred setup
4392314 drm/fb-helper: Split dpms handling into legacy and atomic paths
c4cbe02 drm/fb-helper: Stop using mode_config.mutex for internals
61c2425 drm/fb-helper: Push locking into restore_fbdev_mode_atomic|legacy
584a0e9 drm/fb-helper: Push locking into pan_display_atomic|legacy
2a53d27 drm/fb-helper: Drop locking from the vsync wait ioctl code
58f43d8 drm/fb-helper: Push locking in fb_is_bound
11b9905 drm/fb-helper: Add top-level lock
95a9f45 drm/i915: Drop FBDEV #ifdev in mst code
34a5437 drm/fb-helper: Push down modeset lock into FB helpers

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5057/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915: Avoid keeping waitboost active for signaling threads

[Chris Wilson]

Once a client has requested a waitboost, we keep that waitboost active
until all clients are no longer waiting. This is because we don't
distinguish which waiter deserves the boost. However, with the advent of
fence signaling, the signaler threads appear as waiters to the RPS
interrupt handler. So instead of using a single boolean to track when to
keep the waitboost active, use a counter of all outstanding waitboosted
requests.

At this point, I have removed all vestiges of the rate limiting on
clients. Whilst this means that compositors should remain more fluid,
it also means that boosts are more prevalent. See commit b29c19b64528
("drm/i915: Boost RPS frequency for CPU stalls") for a longer discussion
on the pros and cons of both approaches.

A drawback of this implementation is that it requires constant request
submission to keep the waitboost trimmed (as it is now cancelled when the
request is completed). This will be fine for a busy system, but near
idle the boosts may be kept for longer than desired (effectively tens of
vblanks worstcase) and there is a reliance on rc6 instead.

v2: Remove defunct rps.client_lock

Reported-by: Michał Winiarski 
Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
Reviewed-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 12 +++
 drivers/gpu/drm/i915/i915_drv.h | 10 ++
 drivers/gpu/drm/i915/i915_gem.c | 25 +--
 drivers/gpu/drm/i915/i915_gem_request.c |  7 +++-
 drivers/gpu/drm/i915/i915_gem_request.h |  2 ++
 drivers/gpu/drm/i915/i915_irq.c | 18 ++-
 drivers/gpu/drm/i915/intel_drv.h|  5 ++-
 drivers/gpu/drm/i915/intel_pm.c | 57 +
 8 files changed, 45 insertions(+), 91 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index f7aa6cbe3a2e..580bd4f4a49e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2327,6 +2327,8 @@ static int i915_rps_boost_info(struct seq_file *m, void 
*data)
seq_printf(m, "GPU busy? %s [%d requests]\n",
   yesno(dev_priv->gt.awake), dev_priv->gt.active_requests);
seq_printf(m, "CPU waiting? %d\n", count_irq_waiters(dev_priv));
+   seq_printf(m, "Boosts outstanding? %d\n",
+  atomic_read(&dev_priv->rps.num_waiters));
seq_printf(m, "Frequency requested %d\n",
   intel_gpu_freq(dev_priv, dev_priv->rps.cur_freq));
seq_printf(m, "  min hard:%d, soft:%d; max soft:%d, hard:%d\n",
@@ -2340,22 +2342,20 @@ static int i915_rps_boost_info(struct seq_file *m, void 
*data)
   intel_gpu_freq(dev_priv, dev_priv->rps.boost_freq));
 
mutex_lock(&dev->filelist_mutex);
-   spin_lock(&dev_priv->rps.client_lock);
list_for_each_entry_reverse(file, &dev->filelist, lhead) {
struct drm_i915_file_private *file_priv = file->driver_priv;
struct task_struct *task;
 
rcu_read_lock();
task = pid_task(file->pid, PIDTYPE_PID);
-   seq_printf(m, "%s [%d]: %d boosts%s\n",
+   seq_printf(m, "%s [%d]: %d boosts\n",
   task ? task->comm : "",
   task ? task->pid : -1,
-  file_priv->rps.boosts,
-  list_empty(&file_priv->rps.link) ? "" : ", active");
+  atomic_read(&file_priv->rps.boosts));
rcu_read_unlock();
}
-   seq_printf(m, "Kernel (anonymous) boosts: %d\n", dev_priv->rps.boosts);
-   spin_unlock(&dev_priv->rps.client_lock);
+   seq_printf(m, "Kernel (anonymous) boosts: %d\n",
+  atomic_read(&dev_priv->rps.boosts));
mutex_unlock(&dev->filelist_mutex);
 
if (INTEL_GEN(dev_priv) >= 6 &&
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 427d10c7eca5..effbe4f72a64 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -584,8 +584,7 @@ struct drm_i915_file_private {
struct idr context_idr;
 
struct intel_rps_client {
-   struct list_head link;
-   unsigned boosts;
+   atomic_t boosts;
} rps;
 
unsigned int bsd_engine;
@@ -1303,13 +1302,10 @@ struct intel_gen6_power_mgmt {
int last_adj;
enum { LOW_POWER, BETWEEN, HIGH_POWER } power;
 
-   spinlock_t client_lock;
-   struct list_head clients;
-   bool client_boost;
-
bool enabled;
struct delayed_work autoenable_work;
-   unsigned boosts;
+   atomic_t num_waiters;
+   atomic_t boosts;
 
/* manual wa residency calculations */
struct intel_rps_ei ei;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f38c84e485ab..1b2dfa8bdeef 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

[Zhang, Tina]

> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Gerd Hoffmann
> Sent: Tuesday, June 27, 2017 2:13 PM
> To: Alex Williamson 
> Cc: Wang, Zhenyu Z ; intel-
> g...@lists.freedesktop.org; linux-ker...@vger.kernel.org; Chen, Xiaoguang
> ; Zhang, Tina ; Kirti
> Wankhede ; Lv, Zhiyuan ;
> intel-gvt-...@lists.freedesktop.org; Wang, Zhi A 
> Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf
> operations
> 
>   Hi,
> 
> > Hmm, I don't like that interface.  Can you cite examples of other
> > ioctls that behave this way?  It doesn't feel like an elegant user
> > interface; the user can get the dmabuf, but only after they query the
> > dmabuf, even though the get-dmabuf ioctl returns the same data as the
> > query-plane ioctl, but they can't get the dmabuf if the plane has
> > changed in the interim, which is not something the user can know.  Are
> > we causing our own problems with this model of cycling through dmabuf
> > fds?  We talked previously about an enum of plane types, primary and
> > cursor.  What if the user was simply able to get a dmabuf fd for each
> > of those and they queried the current plane information via those fds?
> > IOW, the fd is persistent and specific to a given plane type, but the
> > format within it is dynamic.
> 
> Will not work due to how dma-bufs are designed.
> 
> But, yes, the QUERY then GET split is ugly for a number of reasons.
> 
> Does gvt track the live cycle of all dma-bufs it has handed out?
The V9 implementation does track the dma-bufs' live cycle. The original idea 
was that leaving the dma-bufs' live cycle management to user mode.

> If so, then maybe we can let the kernel check whenever a dma-buf for the
> current plane exists?  And if that isn't the case hand out a dma- buf right 
> away,
> without expecting userspace explicitly asking for it?
I think this is a good advice. We are going to try this idea and add some 
tracking logic to kernel mode.

> 
> That will simplify the interface and remove the race condition at the expense 
> of
> some additional bookkeeping in the kernel.
In this case, maybe one ioctl like QUERY_PLAN is enough. We can block it this 
ioctl and return it when the fd and info are ready.

Thanks.
Tina


> 
> cheers,
>   Gerd
> 
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
___
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: Avoid keeping waitboost active for signaling threads (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Avoid keeping waitboost active for signaling threads (rev2)
URL   : https://patchwork.freedesktop.org/series/26211/
State : failure

== Summary ==

Series 26211v2 drm/i915: Avoid keeping waitboost active for signaling threads
https://patchwork.freedesktop.org/api/1.0/series/26211/revisions/2/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125 +1
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (fi-skl-6770hq)

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:442s
fi-bdw-gvtdvmtotal:279  pass:257  dwarn:8   dfail:0   fail:0   skip:14  
time:431s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:354s
fi-bsw-n3050 total:279  pass:242  dwarn:1   dfail:0   fail:0   skip:36  
time:528s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:510s
fi-byt-j1900 total:279  pass:253  dwarn:2   dfail:0   fail:0   skip:24  
time:492s
fi-byt-n2820 total:279  pass:249  dwarn:2   dfail:0   fail:0   skip:28  
time:478s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:593s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:437s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:412s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:417s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:499s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:479s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:464s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:573s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:582s
fi-pnv-d510  total:279  pass:222  dwarn:2   dfail:0   fail:0   skip:55  
time:560s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:470s
fi-skl-6700hqtotal:279  pass:223  dwarn:1   dfail:0   fail:30  skip:24  
time:340s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:471s
fi-skl-6770hqtotal:279  pass:268  dwarn:0   dfail:0   fail:1   skip:10  
time:474s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:436s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:540s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:413s

90513552ce32ddf2a4efffa21a5df5f21a425a18 drm-tip: 2017y-06m-28d-11h-26m-16s UTC 
integration manifest
332079a drm/i915: Avoid keeping waitboost active for signaling threads

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5058/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] External display pixelated after upgrade to kernel >= 4.11.0-rc1

[Jani Nikula]

On Wed, 21 Jun 2017, neil k  wrote:
> Hey everyone,
>
> I have a new Thinkpad with a Kaby Lake CPU and Intel HD Graphics 620.  I
> had been using a 26" Vizio TV (1360x768) over HDMI as an external monitor
> with no issues.  I upgraded to a 4.11 series kernel and now the TV is very
> pixelated (see attached picture.)  I posted some logs/info on the kernel
> bugzilla here .  I had
> to nuke that Fedora install, but I have attached dmesg logs from Xubuntu
> booted with the drm.debug=0xe option.  Xubuntu logs are with the laptop
> screen at 1600x900.
>
> Here's what I've found so far in addition to the bugzilla post:

Please file drm/i915 bugs at [1] and keep all information there.

BR,
Jani

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel


-- 
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] [RFC v4 1/2] drm/i915: Engine discovery uAPI

[Tvrtko Ursulin]

On 28/06/2017 12:27, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2017-06-26 16:47:41)

From: Tvrtko Ursulin 

Engine discovery uAPI allows userspace to probe for engine
configuration and features without needing to maintain the
internal PCI id based database.

This enables removal of code duplications across userspace
components.

Probing is done via the new DRM_IOCTL_I915_GEM_ENGINE_INFO ioctl
which returns the number and information on the specified engine
class.

Currently only general engine configuration and HEVC feature of
the VCS engine can be probed but the uAPI is designed to be
generic and extensible.

Code is based almost exactly on the earlier proposal on the
topic by Jon Bloomfield. Engine class and instance refactoring
made recently by Daniele Ceraolo Spurio enabled this to be
implemented in an elegant fashion.

To probe configuration userspace sets the engine class it wants
to query (struct drm_i915_gem_engine_info) and provides an array
of drm_i915_engine_info structs which will be filled in by the
driver. Userspace also has to tell i915 how many elements are in
the array, and the driver will report back the total number of
engine instances in any case.

v2:
  * Add a version field and consolidate to one engine count.
(Chris Wilson)
  * Rename uAPI flags for VCS engines to DRM_I915_ENGINE_CLASS_VIDEO.
(Gong Zhipeng)

v3:
  * Drop the DRM_ prefix from uAPI enums. (Chris Wilson)
  * Only reserve 8-bits for the engine info for time being.

v4:
  * Made user_class_map static.

Signed-off-by: Tvrtko Ursulin 
Cc: Ben Widawsky 
Cc: Chris Wilson 
Cc: Daniel Vetter 
Cc: Joonas Lahtinen 
Cc: Jon Bloomfield 
Cc: "Rogozhkin, Dmitry V" 
Cc: Oscar Mateo 
Cc: "Gong, Zhipeng" 
---
  drivers/gpu/drm/i915/i915_drv.c|  1 +
  drivers/gpu/drm/i915/i915_drv.h|  3 ++
  drivers/gpu/drm/i915/intel_engine_cs.c | 64 ++
  include/uapi/drm/i915_drm.h| 41 ++
  4 files changed, 109 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e9d8e9ee51b2..44dd2f37937f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2724,6 +2724,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
 DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, 
i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
 DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, 
i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
 DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_ENGINE_INFO, i915_gem_engine_info_ioctl, 
DRM_RENDER_ALLOW),
  };
  
  static struct drm_driver driver = {

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 427d10c7eca5..496565e1753f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3598,6 +3598,9 @@ void i915_oa_init_reg_state(struct intel_engine_cs 
*engine,
 struct i915_gem_context *ctx,
 uint32_t *reg_state);
  
+int i915_gem_engine_info_ioctl(struct drm_device *dev, void *data,

+  struct drm_file *file);
+
  /* i915_gem_evict.c */
  int __must_check i915_gem_evict_something(struct i915_address_space *vm,
   u64 min_size, u64 alignment,
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 3b46c1f7b88b..a98669f6ad85 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -25,6 +25,7 @@
  #include "i915_drv.h"
  #include "intel_ringbuffer.h"
  #include "intel_lrc.h"
+#include 
  
  /* Haswell does have the CXT_SIZE register however it does not appear to be

   * valid. Now, docs explain in dwords what is in the context object. The full
@@ -1332,6 +1333,69 @@ void intel_engines_mark_idle(struct drm_i915_private 
*i915)
 }
  }
  
+static u8 user_class_map[I915_ENGINE_CLASS_MAX] = {

+   [I915_ENGINE_CLASS_OTHER] = OTHER_CLASS,
+   [I915_ENGINE_CLASS_RENDER] = RENDER_CLASS,
+   [I915_ENGINE_CLASS_COPY] = COPY_ENGINE_CLASS,
+   [I915_ENGINE_CLASS_VIDEO] = VIDEO_DECODE_CLASS,
+   [I915_ENGINE_CLASS_VIDEO_ENHANCE] = VIDEO_ENHANCEMENT_CLASS,
+};
+
+int i915_gem_engine_info_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file)
+{
+   struct drm_i915_private *i915 = to_i915(dev);
+   struct drm_i915_gem_engine_info *args = data;
+   struct drm_i915_engine_info __user *user_info =
+   u64_to_user_ptr(args->info_ptr);
+   unsigned int info_size = args->num_engines;
+   struct drm_i915_engine_info info;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+   u8 class;
+
+   if (args->rsvd)
+   return -EINVAL;
+
+   switch (args->engine_class) {
+   ca

Re: [Intel-gfx] [RFC v4 1/2] drm/i915: Engine discovery uAPI

[Tvrtko Ursulin]

On 28/06/2017 14:15, Tvrtko Ursulin wrote:

On 28/06/2017 12:27, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2017-06-26 16:47:41)

From: Tvrtko Ursulin 

Engine discovery uAPI allows userspace to probe for engine
configuration and features without needing to maintain the
internal PCI id based database.

This enables removal of code duplications across userspace
components.

Probing is done via the new DRM_IOCTL_I915_GEM_ENGINE_INFO ioctl
which returns the number and information on the specified engine
class.

Currently only general engine configuration and HEVC feature of
the VCS engine can be probed but the uAPI is designed to be
generic and extensible.

Code is based almost exactly on the earlier proposal on the
topic by Jon Bloomfield. Engine class and instance refactoring
made recently by Daniele Ceraolo Spurio enabled this to be
implemented in an elegant fashion.

To probe configuration userspace sets the engine class it wants
to query (struct drm_i915_gem_engine_info) and provides an array
of drm_i915_engine_info structs which will be filled in by the
driver. Userspace also has to tell i915 how many elements are in
the array, and the driver will report back the total number of
engine instances in any case.

v2:
  * Add a version field and consolidate to one engine count.
(Chris Wilson)
  * Rename uAPI flags for VCS engines to DRM_I915_ENGINE_CLASS_VIDEO.
(Gong Zhipeng)

v3:
  * Drop the DRM_ prefix from uAPI enums. (Chris Wilson)
  * Only reserve 8-bits for the engine info for time being.

v4:
  * Made user_class_map static.

Signed-off-by: Tvrtko Ursulin 
Cc: Ben Widawsky 
Cc: Chris Wilson 
Cc: Daniel Vetter 
Cc: Joonas Lahtinen 
Cc: Jon Bloomfield 
Cc: "Rogozhkin, Dmitry V" 
Cc: Oscar Mateo 
Cc: "Gong, Zhipeng" 
---
  drivers/gpu/drm/i915/i915_drv.c|  1 +
  drivers/gpu/drm/i915/i915_drv.h|  3 ++
  drivers/gpu/drm/i915/intel_engine_cs.c | 64 
++

  include/uapi/drm/i915_drm.h| 41 ++
  4 files changed, 109 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c 
b/drivers/gpu/drm/i915/i915_drv.c

index e9d8e9ee51b2..44dd2f37937f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2724,6 +2724,7 @@ static const struct drm_ioctl_desc 
i915_ioctls[] = {
 DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, 
i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
 DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, 
i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
 DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_ENGINE_INFO, 
i915_gem_engine_info_ioctl, DRM_RENDER_ALLOW),

  };
  static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h 
b/drivers/gpu/drm/i915/i915_drv.h

index 427d10c7eca5..496565e1753f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3598,6 +3598,9 @@ void i915_oa_init_reg_state(struct 
intel_engine_cs *engine,

 struct i915_gem_context *ctx,
 uint32_t *reg_state);
+int i915_gem_engine_info_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file);
+
  /* i915_gem_evict.c */
  int __must_check i915_gem_evict_something(struct i915_address_space 
*vm,

   u64 min_size, u64 alignment,
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c

index 3b46c1f7b88b..a98669f6ad85 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -25,6 +25,7 @@
  #include "i915_drv.h"
  #include "intel_ringbuffer.h"
  #include "intel_lrc.h"
+#include 
  /* Haswell does have the CXT_SIZE register however it does not 
appear to be
   * valid. Now, docs explain in dwords what is in the context 
object. The full
@@ -1332,6 +1333,69 @@ void intel_engines_mark_idle(struct 
drm_i915_private *i915)

 }
  }
+static u8 user_class_map[I915_ENGINE_CLASS_MAX] = {
+   [I915_ENGINE_CLASS_OTHER] = OTHER_CLASS,
+   [I915_ENGINE_CLASS_RENDER] = RENDER_CLASS,
+   [I915_ENGINE_CLASS_COPY] = COPY_ENGINE_CLASS,
+   [I915_ENGINE_CLASS_VIDEO] = VIDEO_DECODE_CLASS,
+   [I915_ENGINE_CLASS_VIDEO_ENHANCE] = VIDEO_ENHANCEMENT_CLASS,
+};
+
+int i915_gem_engine_info_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file)
+{
+   struct drm_i915_private *i915 = to_i915(dev);
+   struct drm_i915_gem_engine_info *args = data;
+   struct drm_i915_engine_info __user *user_info =
+   u64_to_user_ptr(args->info_ptr);
+   unsigned int info_size = args->num_engines;
+   struct drm_i915_engine_info info;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+   u8 class;
+
+   if (args->rsvd)
+   return -EINVAL;
+
+

Re: [Intel-gfx] [RFC v4 1/2] drm/i915: Engine discovery uAPI

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-06-28 14:15:05)
> 
> On 28/06/2017 12:27, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2017-06-26 16:47:41)
> >> From: Tvrtko Ursulin 
> >>
> >> Engine discovery uAPI allows userspace to probe for engine
> >> configuration and features without needing to maintain the
> >> internal PCI id based database.
> >>
> >> This enables removal of code duplications across userspace
> >> components.
> >>
> >> Probing is done via the new DRM_IOCTL_I915_GEM_ENGINE_INFO ioctl
> >> which returns the number and information on the specified engine
> >> class.
> >>
> >> Currently only general engine configuration and HEVC feature of
> >> the VCS engine can be probed but the uAPI is designed to be
> >> generic and extensible.
> >>
> >> Code is based almost exactly on the earlier proposal on the
> >> topic by Jon Bloomfield. Engine class and instance refactoring
> >> made recently by Daniele Ceraolo Spurio enabled this to be
> >> implemented in an elegant fashion.
> >>
> >> To probe configuration userspace sets the engine class it wants
> >> to query (struct drm_i915_gem_engine_info) and provides an array
> >> of drm_i915_engine_info structs which will be filled in by the
> >> driver. Userspace also has to tell i915 how many elements are in
> >> the array, and the driver will report back the total number of
> >> engine instances in any case.
> >>
> >> v2:
> >>   * Add a version field and consolidate to one engine count.
> >> (Chris Wilson)
> >>   * Rename uAPI flags for VCS engines to DRM_I915_ENGINE_CLASS_VIDEO.
> >> (Gong Zhipeng)
> >>
> >> v3:
> >>   * Drop the DRM_ prefix from uAPI enums. (Chris Wilson)
> >>   * Only reserve 8-bits for the engine info for time being.
> >>
> >> v4:
> >>   * Made user_class_map static.
> >>
> >> Signed-off-by: Tvrtko Ursulin 
> >> Cc: Ben Widawsky 
> >> Cc: Chris Wilson 
> >> Cc: Daniel Vetter 
> >> Cc: Joonas Lahtinen 
> >> Cc: Jon Bloomfield 
> >> Cc: "Rogozhkin, Dmitry V" 
> >> Cc: Oscar Mateo 
> >> Cc: "Gong, Zhipeng" 
> >> ---
> >>   drivers/gpu/drm/i915/i915_drv.c|  1 +
> >>   drivers/gpu/drm/i915/i915_drv.h|  3 ++
> >>   drivers/gpu/drm/i915/intel_engine_cs.c | 64 
> >> ++
> >>   include/uapi/drm/i915_drm.h| 41 ++
> >>   4 files changed, 109 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> >> b/drivers/gpu/drm/i915/i915_drv.c
> >> index e9d8e9ee51b2..44dd2f37937f 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.c
> >> +++ b/drivers/gpu/drm/i915/i915_drv.c
> >> @@ -2724,6 +2724,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
> >>  DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, 
> >> i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
> >>  DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, 
> >> i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
> >>  DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
> >> DRM_RENDER_ALLOW),
> >> +   DRM_IOCTL_DEF_DRV(I915_GEM_ENGINE_INFO, 
> >> i915_gem_engine_info_ioctl, DRM_RENDER_ALLOW),
> >>   };
> >>   
> >>   static struct drm_driver driver = {
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >> b/drivers/gpu/drm/i915/i915_drv.h
> >> index 427d10c7eca5..496565e1753f 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -3598,6 +3598,9 @@ void i915_oa_init_reg_state(struct intel_engine_cs 
> >> *engine,
> >>  struct i915_gem_context *ctx,
> >>  uint32_t *reg_state);
> >>   
> >> +int i915_gem_engine_info_ioctl(struct drm_device *dev, void *data,
> >> +  struct drm_file *file);
> >> +
> >>   /* i915_gem_evict.c */
> >>   int __must_check i915_gem_evict_something(struct i915_address_space *vm,
> >>u64 min_size, u64 alignment,
> >> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> >> b/drivers/gpu/drm/i915/intel_engine_cs.c
> >> index 3b46c1f7b88b..a98669f6ad85 100644
> >> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> >> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> >> @@ -25,6 +25,7 @@
> >>   #include "i915_drv.h"
> >>   #include "intel_ringbuffer.h"
> >>   #include "intel_lrc.h"
> >> +#include 
> >>   
> >>   /* Haswell does have the CXT_SIZE register however it does not appear to 
> >> be
> >>* valid. Now, docs explain in dwords what is in the context object. The 
> >> full
> >> @@ -1332,6 +1333,69 @@ void intel_engines_mark_idle(struct 
> >> drm_i915_private *i915)
> >>  }
> >>   }
> >>   
> >> +static u8 user_class_map[I915_ENGINE_CLASS_MAX] = {
> >> +   [I915_ENGINE_CLASS_OTHER] = OTHER_CLASS,
> >> +   [I915_ENGINE_CLASS_RENDER] = RENDER_CLASS,
> >> +   [I915_ENGINE_CLASS_COPY] = COPY_ENGINE_CLASS,
> >> +   [I915_ENGINE_CLASS_VIDEO] = VIDEO_DECODE_CLASS,
> >> +   [I915_ENGINE_CLASS_VIDEO_ENHANCE] = VIDEO_ENHANCEMENT_CLASS,
> >> +};
> >> +
> >> +int i915_

[Intel-gfx] [PATCH 2/2] drm/atomic: Wait indefinitely and interruptibly for hw_done.

[Maarten Lankhorst]

Without waiting for hw_done, previous atomic updates may dereference
the wrong state and cause a lot of confusion. The real fix is fixing
all obj->state to use the accessor macros, but for now wait
indefinitely and interruptibly.

Cc: Boris Brezillon 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Cc: CK Hu 
Cc: Philipp Zabel 
Cc: Matthias Brugger 
Cc: Rob Clark 
Cc: Ben Skeggs 
Cc: Thierry Reding 
Cc: Jonathan Hunter 
Cc: Jyri Sarha 
Cc: Tomi Valkeinen 
Cc: Eric Anholt 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: intel-gfx@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: linux-te...@vger.kernel.org
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic_helper.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index f66b6c45cdd0..56e7729d993d 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2144,8 +2144,7 @@ EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
 int drm_atomic_helper_swap_state(struct drm_atomic_state *state,
  bool stall)
 {
-   int i;
-   long ret;
+   int i, ret;
struct drm_connector *connector;
struct drm_connector_state *old_conn_state, *new_conn_state;
struct drm_crtc *crtc;
@@ -2168,12 +2167,11 @@ int drm_atomic_helper_swap_state(struct 
drm_atomic_state *state,
if (!commit)
continue;
 
-   ret = wait_for_completion_timeout(&commit->hw_done,
- 10*HZ);
-   if (ret == 0)
-   DRM_ERROR("[CRTC:%d:%s] hw_done timed out\n",
- crtc->base.id, crtc->name);
+   ret = 
wait_for_completion_interruptible(&commit->hw_done);
drm_crtc_commit_put(commit);
+
+   if (ret)
+   return ret;
}
}
 
-- 
2.11.0

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

[Intel-gfx] [PATCH 1/2] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

[Maarten Lankhorst]

We want to change swap_state to wait indefinitely, but to do this
swap_state should wait interruptibly. This requires propagating
the error to each driver. All drivers have changes to deal with the
clean up. In order to allow easy reverting, the commit that changes
behavior is separate so someone only has to revert that for testing.

Nouveau has a small bugfix, if drm_atomic_helper_wait_for_fences
failed cleanup_planes was not called.

Cc: Boris Brezillon 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Cc: CK Hu 
Cc: Philipp Zabel 
Cc: Matthias Brugger 
Cc: Rob Clark 
Cc: Ben Skeggs 
Cc: Thierry Reding 
Cc: Jonathan Hunter 
Cc: Jyri Sarha 
Cc: Tomi Valkeinen 
Cc: Eric Anholt 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: intel-gfx@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: linux-te...@vger.kernel.org
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 14 --
 drivers/gpu/drm/drm_atomic_helper.c  | 18 --
 drivers/gpu/drm/i915/intel_display.c | 10 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c   |  7 ++-
 drivers/gpu/drm/msm/msm_atomic.c | 14 +-
 drivers/gpu/drm/nouveau/nv50_display.c   | 10 --
 drivers/gpu/drm/tegra/drm.c  |  7 ++-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  6 +-
 drivers/gpu/drm/vc4/vc4_kms.c| 21 +
 include/drm/drm_atomic_helper.h  |  4 ++--
 10 files changed, 82 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 516d9547d331..d4f787bf1d4a 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -544,9 +544,11 @@ static int atmel_hlcdc_dc_atomic_commit(struct drm_device 
*dev,
goto error;
}
 
-   /* Swap the state, this is the point of no return. */
-   drm_atomic_helper_swap_state(state, true);
+   ret = drm_atomic_helper_swap_state(state, true);
+   if (ret)
+   goto err_pending;
 
+   /* Swap state succeeded, this is the point of no return. */
drm_atomic_state_get(state);
if (async)
queue_work(dc->wq, &commit->work);
@@ -555,6 +557,14 @@ static int atmel_hlcdc_dc_atomic_commit(struct drm_device 
*dev,
 
return 0;
 
+err_pending:
+   /* Fail the commit, wake up any waiter. */
+   spin_lock(&dc->commit.wait.lock);
+   dc->commit.pending = false;
+   wake_up_all_locked(&dc->commit.wait);
+   spin_unlock(&dc->commit.wait.lock);
+err_free:
+   kfree(commit);
 error:
drm_atomic_helper_cleanup_planes(dev, state);
return ret;
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index f1847d29ba3e..f66b6c45cdd0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1387,10 +1387,8 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 
if (!nonblock) {
ret = drm_atomic_helper_wait_for_fences(dev, state, true);
-   if (ret) {
-   drm_atomic_helper_cleanup_planes(dev, state);
-   return ret;
-   }
+   if (ret)
+   goto err;
}
 
/*
@@ -1399,7 +1397,9 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 * the software side now.
 */
 
-   drm_atomic_helper_swap_state(state, true);
+   ret = drm_atomic_helper_swap_state(state, true);
+   if (ret)
+   goto err;
 
/*
 * Everything below can be run asynchronously without the need to grab
@@ -1428,6 +1428,10 @@ int drm_atomic_helper_commit(struct drm_device *dev,
commit_tail(state);
 
return 0;
+
+err:
+   drm_atomic_helper_cleanup_planes(dev, state);
+   return ret;
 }
 EXPORT_SYMBOL(drm_atomic_helper_commit);
 
@@ -2137,7 +2141,7 @@ EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
  * the current atomic helpers this is almost always the case, since the helpers
  * don't pass the right state structures to the callbacks.
  */
-void drm_atomic_helper_swap_state(struct drm_atomic_state *state,
+int drm_atomic_helper_swap_state(struct drm_atomic_state *state,
  bool stall)
 {
int i;
@@ -2214,6 +2218,8 @@ void drm_atomic_helper_swap_state(struct drm_atomic_state 
*state,
 
__for_each_private_obj(state, obj, obj_state, i, funcs)
funcs->swap_state(obj, &state->private_objs[i].obj_state);
+
+   return 0;
 }
 EXPORT_SYMBOL(drm_atomic_helper_swap_state);
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/d

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/atomic: Change 
drm_atomic_helper_swap_state to return an error.
URL   : https://patchwork.freedesktop.org/series/26488/
State : failure

== Summary ==

Series 26488v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/26488/revisions/1/mbox/

Test gem_exec_parallel:
Subgroup basic:
pass   -> INCOMPLETE (fi-pnv-d510)
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-r) fdo#100125
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-byt-j1900) fdo#101517

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
fdo#101517 https://bugs.freedesktop.org/show_bug.cgi?id=101517

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:445s
fi-bdw-gvtdvmtotal:279  pass:257  dwarn:8   dfail:0   fail:0   skip:14  
time:433s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:357s
fi-bsw-n3050 total:279  pass:242  dwarn:1   dfail:0   fail:0   skip:36  
time:532s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:508s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:483s
fi-byt-n2820 total:279  pass:249  dwarn:2   dfail:0   fail:0   skip:28  
time:481s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:594s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:435s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:420s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:413s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:491s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:478s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:470s
fi-kbl-7560u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:570s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:584s
fi-pnv-d510  total:68   pass:42   dwarn:0   dfail:0   fail:0   skip:25 
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:454s
fi-skl-6700hqtotal:279  pass:223  dwarn:1   dfail:0   fail:30  skip:24  
time:341s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:464s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:476s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:437s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:539s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:408s

90513552ce32ddf2a4efffa21a5df5f21a425a18 drm-tip: 2017y-06m-28d-11h-26m-16s UTC 
integration manifest
3ec2e30 drm/atomic: Wait indefinitely and interruptibly for hw_done.
d685f31 drm/atomic: Change drm_atomic_helper_swap_state to return an error.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5059/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] vc4: Test setting labels of BOs.

[Arkadiusz Hiler]

On Thu, Jun 22, 2017 at 01:51:29PM -0700, Eric Anholt wrote:
> So far this test is basically making sure that we throw appropriate
> errors, and don't oops the kernel with silly inputs.
> 
> Signed-off-by: Eric Anholt 
Acked-by: Arkadiusz Hiler 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 2/3] lib: Add reset-type helper in ioctl_wrappers

[Arkadiusz Hiler]

On Tue, Jun 20, 2017 at 11:25:01AM -0700, Michel Thierry wrote:
> Soon we will have tests that are only for platforms with reset-engine
> (GEN8+), so add a helper to query the has_gpu_reset via the getparam ioctl.
> 
> Signed-off-by: Michel Thierry 
> ---
>  lib/ioctl_wrappers.c | 22 ++
>  lib/ioctl_wrappers.h |  1 +
>  2 files changed, 23 insertions(+)
> 
> diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
> index 0816a7b6..958b7d03 100644
> --- a/lib/ioctl_wrappers.c
> +++ b/lib/ioctl_wrappers.c
> @@ -1199,6 +1199,28 @@ bool gem_uses_full_ppgtt(int fd)
>  }
>  
>  /**
> + * gem_gpu_reset_type:
> + * @fd: open i915 drm file descriptor
> + *
> + * Query whether reset-engine (2), global-reset (1) or reset-disable (0)

What about using an enum to save us commenting on the magic numbers
later on?

-- 
Cheers,
Arek

> + * is available.
> + *
> + * Returns: GPU reset type available
> + */
> +int gem_gpu_reset_type(int fd)
> +{
> + struct drm_i915_getparam gp;
> + int gpu_reset_type = -1;
> +
> + memset(&gp, 0, sizeof(gp));
> + gp.param = I915_PARAM_HAS_GPU_RESET;
> + gp.value = &gpu_reset_type;
> + drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, &gp);
> +
> + return gpu_reset_type;
> +}
> +
> +/**
>   * gem_available_fences:
>   * @fd: open i915 drm file descriptor
>   *
> diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
> index e1279d94..0fd4e8e4 100644
> --- a/lib/ioctl_wrappers.h
> +++ b/lib/ioctl_wrappers.h
> @@ -164,6 +164,7 @@ bool gem_has_blt(int fd);
>  bool gem_has_vebox(int fd);
>  bool gem_has_bsd2(int fd);
>  int gem_gtt_type(int fd);
> +int gem_gpu_reset_type(int fd);
>  bool gem_uses_ppgtt(int fd);
>  bool gem_uses_full_ppgtt(int fd);
>  int gem_available_fences(int fd);
> -- 
> 2.11.0
> 
> ___
> 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] i915/gvt: Add MIPI DSI support

[Jani Nikula]

On Wed, 21 Jun 2017, Alan Tan  wrote:
> From: Vivek Kasireddy 
>
> In addition to adding the registers asscociated with MIPI DSI
> encoder/connector, we also ensure intel_bios_init() function
> gets called before intel_gvt_init() so that we can detect the presence
> of MIPI DSI from the VBT and decide whether to read the releveant
> registers or not. This is needed because if we read MIPI registers
> when it is not present, this leads to a hang.
>
> Also, since PIPECONF register reads 0x0 when MIPI DSI is enabled,
> we try to augment functions like pipe_is_enabled() to ensure that
> Vblank and Flip done events are forwarded to DomU by calling
> intel_bios_is_dsi_present(). We do similar thing with plane
> surface and MMIO write handler as well.
>
> Signed-off-by: Vivek Kasireddy 
> Reviewed-by: He, Min 
> ---
>  drivers/gpu/drm/i915/gvt/display.c  |  277 ++--
>  drivers/gpu/drm/i915/gvt/handlers.c | 1317 
> ++-
>  drivers/gpu/drm/i915/i915_drv.c |8 +-
>  drivers/gpu/drm/i915/i915_irq.c |   17 +-
>  4 files changed, 1242 insertions(+), 377 deletions(-)

Please split up the patch. This is way too big to be reviewed or merged
in one go.

Especially the parts touching i915 proper must be split up to patches of
their own.

You also have tons of whitespace and other unrelated changes here.

There are many helpful tips about patch size, here are a couple I like:

* If you get a regression report with a bisect pointing to the commit,
  will you be able to spot the mistake reasonably quickly?

* What is the impact of revert in the above case? Can you split up and
  rearrange the patch/series in a way that reverting the main functional
  change still leaves in all the prep work?

BR,
Jani.


>
> diff --git a/drivers/gpu/drm/i915/gvt/display.c 
> b/drivers/gpu/drm/i915/gvt/display.c
> index 6d8fde8..8d9f329 100644
> --- a/drivers/gpu/drm/i915/gvt/display.c
> +++ b/drivers/gpu/drm/i915/gvt/display.c
> @@ -55,6 +55,20 @@ static int get_edp_pipe(struct intel_vgpu *vgpu)
>   return pipe;
>  }
>  
> +int get_dsi_pipe(struct intel_vgpu *vgpu)
> +{
> + struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
> + u32 data = vgpu_vreg(vgpu, _MIPIA_CTRL);
> +
> + data &= BXT_PIPE_SELECT_MASK;
> + data >>= BXT_PIPE_SELECT_SHIFT;
> +
> + if (data > PIPE_C)
> + return -1;
> + else
> + return data;
> +}
> +
>  static int edp_pipe_is_enabled(struct intel_vgpu *vgpu)
>  {
>   struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
> @@ -80,58 +94,117 @@ static int pipe_is_enabled(struct intel_vgpu *vgpu, int 
> pipe)
>   if (edp_pipe_is_enabled(vgpu) &&
>   get_edp_pipe(vgpu) == pipe)
>   return 1;
> +
> + if (intel_bios_is_dsi_present(dev_priv, NULL) &&
> + get_dsi_pipe(vgpu) == pipe)
> + return 1;
> +
>   return 0;
>  }
>  
> +static unsigned char virtual_dp_monitor_edid[GVT_EDID_NUM][EDID_SIZE] = {
> + {
> +/* EDID with 1024x768 as its resolution */
> + /*Header*/
> + 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00,
> + /* Vendor & Product Identification */
> + 0x22, 0xf0, 0x54, 0x29, 0x00, 0x00, 0x00, 0x00, 0x04, 0x17,
> + /* Version & Revision */
> + 0x01, 0x04,
> + /* Basic Display Parameters & Features */
> + 0xa5, 0x34, 0x20, 0x78, 0x23,
> + /* Color Characteristics */
> + 0xfc, 0x81, 0xa4, 0x55, 0x4d, 0x9d, 0x25, 0x12, 0x50, 0x54,
> + /* Established Timings: maximum resolution is 1024x768 */
> + 0x21, 0x08, 0x00,
> + /* Standard Timings. All invalid */
> + 0x00, 0xc0, 0x00, 0xc0, 0x00, 0x40, 0x00, 0x80, 0x00, 0x00,
> + 0x00, 0x40, 0x00, 0x00, 0x00, 0x01,
> + /* 18 Byte Data Blocks 1: invalid */
> + 0x00, 0x00, 0x80, 0xa0, 0x70, 0xb0,
> + 0x23, 0x40, 0x30, 0x20, 0x36, 0x00, 0x06, 0x44, 0x21, 0x00, 
> 0x00, 0x1a,
> + /* 18 Byte Data Blocks 2: invalid */
> + 0x00, 0x00, 0x00, 0xfd, 0x00, 0x18, 0x3c, 0x18, 0x50, 0x11, 
> 0x00, 0x0a,
> + 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
> + /* 18 Byte Data Blocks 3: invalid */
> + 0x00, 0x00, 0x00, 0xfc, 0x00, 0x48,
> + 0x50, 0x20, 0x5a, 0x52, 0x32, 0x34, 0x34, 0x30, 0x77, 0x0a, 
> 0x20, 0x20,
> + /* 18 Byte Data Blocks 4: invalid */
> + 0x00, 0x00, 0x00, 0xff, 0x00, 0x43, 0x4e, 0x34, 0x33, 0x30, 
> 0x34, 0x30,
> + 0x44, 0x58, 0x51, 0x0a, 0x20, 0x20,
> + /* Extension Block Count */
> + 0x00,
> + /* Checksum */
> + 0xef,
> + },
> + {
>  /* EDID with 1920x1200 as its resolution */
> -static unsigned char virtual_dp_monitor_edid[] = {
> - /*Header*/
> - 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00,
> - /* Vendor & Product Identi

[Intel-gfx] [RFC v5 1/2] drm/i915: Engine discovery uAPI

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Engine discovery uAPI allows userspace to probe for engine
configuration and features without needing to maintain the
internal PCI id based database.

This enables removal of code duplications across userspace
components.

Probing is done via the new DRM_IOCTL_I915_GEM_ENGINE_INFO ioctl
which returns the number and information on the specified engine
class.

Currently only general engine configuration and HEVC feature of
the VCS engine can be probed but the uAPI is designed to be
generic and extensible.

Code is based almost exactly on the earlier proposal on the
topic by Jon Bloomfield. Engine class and instance refactoring
made recently by Daniele Ceraolo Spurio enabled this to be
implemented in an elegant fashion.

To probe configuration userspace sets the engine class it wants
to query (struct drm_i915_gem_engine_info) and provides an array
of drm_i915_engine_info structs which will be filled in by the
driver. Userspace also has to tell i915 how many elements are in
the array, and the driver will report back the total number of
engine instances in any case.

Pseudo-code example of userspace using the uAPI:

  struct drm_i915_gem_engine_info info = {};
  struct drm_i915_engine_info engines[8];
  int i, ret;

  info.version = 1;
  info.engine_class = I915_ENGINE_CLASS_VIDEO;
  info.num_engines = ARRAY_SIZE(engines);
  info.info_ptr = to_user_pointer(&engines[0]);

  ret = ioctl(..., &info);
  assert(ret == 0);

  if (info.version != 1)
  goto kernel_does_not_support_a_version_this_new;

  for (i = 0; i < info.num_engines; i++)
  printf("VCS%u: flags=%x\n",
 engines[i].instance,
 engines[i].info);

If the userspace wants to allocate the exact number of
drm_i915_engine_info structures instead of pesimistically
over-allocating, it can submit the ioctl two times.

First time with info.num_engines set to zero, so the kernel
reports back the total number of available engines, and the
second time with the field set to the number of allocated
array elements.

v2:
 * Add a version field and consolidate to one engine count.
   (Chris Wilson)
 * Rename uAPI flags for VCS engines to DRM_I915_ENGINE_CLASS_VIDEO.
   (Gong Zhipeng)

v3:
 * Drop the DRM_ prefix from uAPI enums. (Chris Wilson)
 * Only reserve 8-bits for the engine info for time being.

v4:
 * Made user_class_map static.

v5:
 * Example usage added to commit msg. (Chris Wilson)
 * Report engine count in case of version mismatch. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Cc: Ben Widawsky 
Cc: Chris Wilson 
Cc: Daniel Vetter 
Cc: Joonas Lahtinen 
Cc: Jon Bloomfield 
Cc: "Rogozhkin, Dmitry V" 
Cc: Oscar Mateo 
Cc: "Gong, Zhipeng" 
---
 drivers/gpu/drm/i915/i915_drv.c|  1 +
 drivers/gpu/drm/i915/i915_drv.h|  3 ++
 drivers/gpu/drm/i915/intel_engine_cs.c | 64 ++
 include/uapi/drm/i915_drm.h| 41 ++
 4 files changed, 109 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e9d8e9ee51b2..44dd2f37937f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2724,6 +2724,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, 
i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, 
i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_ENGINE_INFO, i915_gem_engine_info_ioctl, 
DRM_RENDER_ALLOW),
 };
 
 static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 427d10c7eca5..496565e1753f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3598,6 +3598,9 @@ void i915_oa_init_reg_state(struct intel_engine_cs 
*engine,
struct i915_gem_context *ctx,
uint32_t *reg_state);
 
+int i915_gem_engine_info_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file);
+
 /* i915_gem_evict.c */
 int __must_check i915_gem_evict_something(struct i915_address_space *vm,
  u64 min_size, u64 alignment,
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 3b46c1f7b88b..d88198933262 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -25,6 +25,7 @@
 #include "i915_drv.h"
 #include "intel_ringbuffer.h"
 #include "intel_lrc.h"
+#include 
 
 /* Haswell does have the CXT_SIZE register however it does not appear to be
  * valid. Now, docs explain in dwords what is in the context object. The full
@@ -1332,6 +1333,69 @@ void intel_engines_mark_idle(struct drm_i915_private 
*i915)
}
 }
 
+static u8 user_class_map[I915_ENGINE_CLASS_MAX] = {
+

[Intel-gfx] [PATCH] drm/i915: Drain the device workqueue on unload

[Chris Wilson]

Workers on the i915->wq may rearm themselves so for completeness we need
to replace our flush_workqueue() with a call to drain_workqueue() before
unloading the device.

References: https://bugs.freedesktop.org/show_bug.cgi?id=101627
Signed-off-by: Chris Wilson 
Cc: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_drv.c  | 2 +-
 drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9167a73f3c69..3f998d7102f7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -592,7 +592,7 @@ static const struct vga_switcheroo_client_ops 
i915_switcheroo_ops = {
 
 static void i915_gem_fini(struct drm_i915_private *dev_priv)
 {
-   flush_workqueue(dev_priv->wq);
+   drain_workqueue(dev_priv->wq);
 
mutex_lock(&dev_priv->drm.struct_mutex);
intel_uc_fini_hw(dev_priv);
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 47613d20bba8..4beed89b51e6 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -57,7 +57,7 @@ static void mock_device_release(struct drm_device *dev)
 
cancel_delayed_work_sync(&i915->gt.retire_work);
cancel_delayed_work_sync(&i915->gt.idle_work);
-   flush_workqueue(i915->wq);
+   drain_workqueue(i915->wq);
 
mutex_lock(&i915->drm.struct_mutex);
for_each_engine(engine, i915, id)
-- 
2.13.1

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

[Intel-gfx] [PATCH i-g-t] tests/gem_mocs_settings: Fix LNCFCMOCS testing and extract the subtests

[Michał Winiarski]

Testing LNCFCMOCS values on non-render engines is tricky. The values in
those registers are lost on RC6, which means that if users of non-render
engines want to see the proper values, they need to obtain a forcewake
and execute something on render (relying on it to restore the values)
before using non-render engine.
Previous version of the test did exactly that - we were relying on the
fact that we're taking forcewake (hidden by intel_register_access_init,
even though the test is not doing any mmio accesses) before iterating
through engines (and render is before other engines, so job done).
I really hope that this is not an ABI and those registers are not used
on non-render in any way. Let's limit testing LNCFCMOCS to render
engine only.
The other non-render issue is that when we're using I915_EXEC_BSD, we
can't be sure which BSD ring we'll end up executing on. Let's
explicitly select BSD1 and BSD2 in our tests.
While we're here, let's also remove the duplicated code and add some
structure by extracting moving more content into subtests.
We're only doing tests that involve "dirtying" the registers for the
render engine - since it's the only one that has those registers in its
context.

Cc: Arkadiusz Hiler 
Cc: Chris Wilson 
Cc: David Weinehall 
Cc: Łukasz Kałamarz 
Signed-off-by: Michał Winiarski 
---
 tests/gem_mocs_settings.c | 353 ++
 1 file changed, 108 insertions(+), 245 deletions(-)

diff --git a/tests/gem_mocs_settings.c b/tests/gem_mocs_settings.c
index a96aa66..9760c0e 100644
--- a/tests/gem_mocs_settings.c
+++ b/tests/gem_mocs_settings.c
@@ -32,14 +32,28 @@
 #include "igt_sysfs.h"
 
 #define MAX_NUMBER_MOCS_REGISTERS  (64)
-
 enum {
NONE,
RESET,
+   RC6,
SUSPEND,
-   HIBERNATE
+   HIBERNATE,
+   MAX_MOCS_TEST_MODES
+};
+
+static const char * const test_modes[] = {
+   [NONE] = "settings",
+   [RESET] = "reset",
+   [RC6] = "rc6",
+   [SUSPEND] = "suspend",
+   [HIBERNATE] = "hibernate"
 };
 
+#define MOCS_NON_DEFAULT_CTX   (1<<0)
+#define MOCS_DIRTY_VALUES  (1<<1)
+#define ALL_MOCS_FLAGS (MOCS_NON_DEFAULT_CTX | \
+MOCS_DIRTY_VALUES)
+
 #define GEN9_LNCFCMOCS0(0xB020)/* L3 Cache Control 
base */
 #define GEN9_GFX_MOCS_0(0xc800)/* Graphics MOCS base 
register*/
 #define GEN9_MFX0_MOCS_0   (0xc900)/* Media 0 MOCS base register*/
@@ -117,19 +131,18 @@ static bool get_mocs_settings(int fd, struct mocs_table 
*table, bool dirty)
return result;
 }
 
+#define LOCAL_I915_EXEC_BSD1 (I915_EXEC_BSD | (1<<13))
+#define LOCAL_I915_EXEC_BSD2 (I915_EXEC_BSD | (2<<13))
+
 static uint32_t get_engine_base(uint32_t engine)
 {
-   /* Note we cannot test BSD1 or BSD2 due to limitations of current ANI */
switch (engine) {
-   case I915_EXEC_BSD: return GEN9_MFX0_MOCS_0;
-/*
-   case I915_EXEC_BSD1:return GEN9_MFX0_MOCS_0;
-   case I915_EXEC_BSD2:return GEN9_MFX1_MOCS_0;
-*/
-   case I915_EXEC_RENDER:  return GEN9_GFX_MOCS_0;
-   case I915_EXEC_BLT: return GEN9_BLT_MOCS_0;
-   case I915_EXEC_VEBOX:   return GEN9_VEBOX_MOCS_0;
-   default:return 0;
+   case LOCAL_I915_EXEC_BSD1:  return GEN9_MFX0_MOCS_0;
+   case LOCAL_I915_EXEC_BSD2:  return GEN9_MFX1_MOCS_0;
+   case I915_EXEC_RENDER:  return GEN9_GFX_MOCS_0;
+   case I915_EXEC_BLT: return GEN9_BLT_MOCS_0;
+   case I915_EXEC_VEBOX:   return GEN9_VEBOX_MOCS_0;
+   default:return 0;
}
 }
 
@@ -252,7 +265,7 @@ static void check_control_registers(int fd,
uint32_t ctx_id,
bool dirty)
 {
-   const uint32_t reg_base  = get_engine_base(engine);
+   const uint32_t reg_base = get_engine_base(engine);
uint32_t dst_handle = gem_create(fd, 4096);
uint32_t *read_regs;
struct mocs_table table;
@@ -299,6 +312,7 @@ static void check_l3cc_registers(int fd,
read_regs = gem_mmap__cpu(fd, dst_handle, 0, 4096, PROT_READ);
 
gem_set_domain(fd, dst_handle, I915_GEM_DOMAIN_CPU, 0);
+
for (index = 0; index < table.size / 2; index++) {
igt_assert_eq_u32(read_regs[index] & 0x,
  table.table[index * 2].l3cc_value);
@@ -314,183 +328,65 @@ static void check_l3cc_registers(int fd,
gem_close(fd, dst_handle);
 }
 
-static void test_context_mocs_values(int fd, unsigned engine)
-{
-   int local_fd;
-   uint32_t ctx_id = 0;
-
-   local_fd = fd;
-   if (local_fd == -1)
-   local_fd = drm_open_driver_master(DRIVER_INTEL);
-
-   check_control_registers(local_fd, engine, ctx_id, false);
-   check_l3cc_registers(local_fd, engine, ctx_id, false);
-
-   if (engine == I915_EXEC_RENDER) {
-   ctx_id = 

[Intel-gfx] ✗ Fi.CI.BAT: failure for New engine discovery and execbuffer2 engine selection uAPI (rev9)

[Patchwork]

== Series Details ==

Series: New engine discovery and execbuffer2 engine selection uAPI (rev9)
URL   : https://patchwork.freedesktop.org/series/23189/
State : failure

== Summary ==

Series 23189v9 New engine discovery and execbuffer2 engine selection uAPI
https://patchwork.freedesktop.org/api/1.0/series/23189/revisions/9/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17
Test gem_exec_parse:
Subgroup basic-allowed:
pass   -> FAIL   (fi-byt-j1900)
Subgroup basic-rejected:
pass   -> FAIL   (fi-byt-j1900)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> FAIL   (fi-snb-2600) fdo#100215

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:438s
fi-bdw-gvtdvmtotal:279  pass:257  dwarn:8   dfail:0   fail:0   skip:14  
time:430s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:357s
fi-bsw-n3050 total:279  pass:242  dwarn:1   dfail:0   fail:0   skip:36  
time:529s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:504s
fi-byt-j1900 total:279  pass:251  dwarn:2   dfail:0   fail:2   skip:24  
time:439s
fi-byt-n2820 total:279  pass:249  dwarn:2   dfail:0   fail:0   skip:28  
time:486s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:602s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:433s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:410s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:417s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:501s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:471s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:464s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:574s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:587s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:562s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:454s
fi-skl-6700hqtotal:279  pass:223  dwarn:1   dfail:0   fail:30  skip:24  
time:343s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:462s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:479s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:435s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:548s
fi-snb-2600  total:279  pass:249  dwarn:0   dfail:0   fail:1   skip:29  
time:403s

85a692e2c6a7cf93082044d776e838cb9e9b2146 drm-tip: 2017y-06m-28d-14h-24m-59s UTC 
integration manifest
b3ca660 drm/i915: Select engines via class and instance in execbuffer2
6e37821 drm/i915: Engine discovery uAPI

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5060/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] fbcon: Make fbcon a built-time depency for fbdev

[Daniel Vetter]

On Wed, Jun 28, 2017 at 5:08 PM, Steven Rostedt  wrote:
> On Wed, 28 Jun 2017 12:36:35 +0200
> Daniel Vetter  wrote:
>
>> There's a bunch of folks who're trying to make printk less
>> contended and faster, but there's a problem: printk uses the
>> console_lock, and the console lock has become the BKL for all things
>> fbdev/fbcon, which in turn pulled in half the drm subsystem under that
>> lock. That's awkward.
>>
>
> I applied your patch and compiled it, and got this error while
> installing modules:
>
>   DEPMOD  4.12.0-rc5-test+
> depmod: ERROR: Found 11 modules in dependency cycles!
> depmod: ERROR: Cycle detected: fbcon -> bitblit -> softcursor -> fb -> fbcon
> depmod: ERROR: Cycle detected: softcursor -> fb -> fbcon_rotate -> fbcon_ccw 
> -> softcursor
> depmod: ERROR: Cycle detected: fb -> fbcon_rotate -> fbcon_ccw -> fb
> depmod: ERROR: Cycle detected: softcursor -> fb -> fbcon_rotate -> fbcon_ccw 
> -> fbcon_ud -> softcursor
> depmod: ERROR: Cycle detected: fb -> fbcon_rotate -> fbcon_ccw -> fbcon_ud -> 
> fb
> depmod: ERROR: Cycle detected: softcursor -> fb -> fbcon_rotate -> fbcon_ccw 
> -> fbcon_ud -> fbcon_cw -> softcursor
> depmod: ERROR: Cycle detected: fb -> fbcon_rotate -> fbcon_ccw -> fbcon_ud -> 
> fbcon_cw -> fb
> depmod: ERROR: Cycle detected: fb -> fbcon_rotate -> fbcon_ccw -> fbcon_ud -> 
> fbcon_cw -> fb
> depmod: ERROR: Cycle detected: fb -> fbcon_rotate -> fbcon_ccw -> fbcon_ud -> 
> fbcon_cw -> tileblit -> fb
> depmod: ERROR: Cycle detected: fbcon -> bitblit -> softcursor -> fb -> 
> fbcon_rotate -> fbcon_ccw -> fbcon_ud -> fbcon_cw -> tileblit -> fbdev
> depmod: ERROR: Cycle detected: fb -> fbcon_rotate -> fbcon_ccw -> fbcon_ud -> 
> fbcon_cw -> tileblit -> fb
> /work/git/linux-trace.git/Makefile:1251: recipe for target '_modinst_post' 
> failed
>
>
> Config attached.
>
> Oh, and I changed CONFIG_FB to be a module, which is probably where the
> error happened.

Yeah I only compile tested all the combos and didn't realize that
depmod is only run at install time. I indeed created a depency loop
here. I think the simplest solution would be to stuff all the fbcon
code into the fb.ko module, I'm trying to figure out whether that can
be done without massive code movement.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Drain the device workqueue on unload

[Patchwork]

== Series Details ==

Series: drm/i915: Drain the device workqueue on unload
URL   : https://patchwork.freedesktop.org/series/26494/
State : success

== Summary ==

Series 26494v1 drm/i915: Drain the device workqueue on unload
https://patchwork.freedesktop.org/api/1.0/series/26494/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-byt-j1900) fdo#101517

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#101517 https://bugs.freedesktop.org/show_bug.cgi?id=101517

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:443s
fi-bdw-gvtdvmtotal:279  pass:257  dwarn:8   dfail:0   fail:0   skip:14  
time:424s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:354s
fi-bsw-n3050 total:279  pass:242  dwarn:1   dfail:0   fail:0   skip:36  
time:539s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:518s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:489s
fi-byt-n2820 total:279  pass:249  dwarn:2   dfail:0   fail:0   skip:28  
time:483s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:602s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:435s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:410s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:414s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:499s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:471s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:464s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:570s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:581s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:557s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:461s
fi-skl-6700hqtotal:279  pass:223  dwarn:1   dfail:0   fail:30  skip:24  
time:340s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:462s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:479s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:436s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:536s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:414s

85a692e2c6a7cf93082044d776e838cb9e9b2146 drm-tip: 2017y-06m-28d-14h-24m-59s UTC 
integration manifest
99d97d4 drm/i915: Drain the device workqueue on unload

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5061/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/fb-helper: Support deferred setup

[Liviu Dudau]

On Wed, Jun 28, 2017 at 01:32:01PM +0200, Daniel Vetter wrote:
> FB helper code falls back to a 1024x768 mode if no outputs are connected
> or don't report back any modes upon initialization. This can be annoying
> because outputs that are added to FB helper later on can't be used with
> FB helper if they don't support a matching mode.
> 
> The fallback is in place because VGA connectors can happen to report an
> unknown connection status even when they are in fact connected.
> 
> Some drivers have custom solutions in place to defer FB helper setup
> until at least one output is connected. But the logic behind these
> solutions is always the same and there is nothing driver-specific about
> it, so a better alterative is to fix the FB helper core and add support
> for all drivers automatically.
> 
> This patch adds support for deferred FB helper setup. It checks all the
> connectors for their connection status, and if all of them report to be
> disconnected marks the FB helper as needing deferred setup. Whet setup
> is deferred, the FB helper core will automatically retry setup after a
> hotplug event, and it will keep trying until it succeeds.
> 
> v2: Rebase onto my entirely reworked fbdev helper locking. One big
> difference is that this version again drops&reacquires the fbdev lock
> (which is now fb_helper->lock, but before this patch series it was
> mode_config->mutex), because register_framebuffer must be able to
> recurse back into fbdev helper code for the initial screen setup.
> 
> v3: __drm_fb_helper_initial_config must hold fb_helper->lock upon
> return, I've fumbled that in the deferred setup case (Liviu).
> 
> v4: I was blind, redo this all. __drm_fb_helper_initial_config
> shouldn't need to reacquire fb_helper->lock, that just confuses
> callers. I myself got confused by kernel_fb_helper_lock and somehow
> thought it's the same as fb_helper->lock. Tsk.
> 
> Also simplify the logic a bit (we don't need two functions to probe
> connectors), we can stick much closer to the existing code. And update
> some comments I've spotted that are outdated.
> 
> v5: Don't pass -EAGAIN to drivers, it's just an internal error code
> (Liviu).
> 
> Cc: Liviu Dudau 
> Cc: John Stultz 
> Cc: Thierry Reding  (v1)
> Tested-by: John Stultz 
> Signed-off-by: Thierry Reding  (v1)
> Signed-off-by: Daniel Vetter 

Tested-by: Liviu Dudau 

I'm going through the debugging on the deferred setup on first monitor connect,
as that seems to not do a full modeset, but that might turn out a bug in my
driver.

> ---
>  drivers/gpu/drm/drm_fb_helper.c | 101 
> ++--
>  include/drm/drm_fb_helper.h |  23 +
>  2 files changed, 89 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index bbd4c6d0378d..e49bae10f0ee 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -521,6 +521,9 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct 
> drm_fb_helper *fb_helper)
>   if (!drm_fbdev_emulation)
>   return -ENODEV;
>  
> + if (READ_ONCE(fb_helper->deferred_setup))
> + return 0;
> +
>   mutex_lock(&fb_helper->lock);
>   ret = restore_fbdev_mode(fb_helper);
>  
> @@ -1695,8 +1698,7 @@ EXPORT_SYMBOL(drm_fb_helper_pan_display);
>  
>  /*
>   * Allocates the backing storage and sets up the fbdev info structure through
> - * the ->fb_probe callback and then registers the fbdev and sets up the panic
> - * notifier.
> + * the ->fb_probe callback.
>   */
>  static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper,
>int preferred_bpp)
> @@ -1794,13 +1796,8 @@ static int drm_fb_helper_single_fb_probe(struct 
> drm_fb_helper *fb_helper,
>   }
>  
>   if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
> - /*
> -  * hmm everyone went away - assume VGA cable just fell out
> -  * and will come back later.
> -  */
> - DRM_INFO("Cannot find any crtc or sizes - going 1024x768\n");
> - sizes.fb_width = sizes.surface_width = 1024;
> - sizes.fb_height = sizes.surface_height = 768;
> + DRM_INFO("Cannot find any crtc or sizes\n");
> + return -EAGAIN;
>   }
>  
>   /* Handle our overallocation */
> @@ -2429,6 +2426,58 @@ static void drm_setup_crtcs(struct drm_fb_helper 
> *fb_helper,
>   kfree(enabled);
>  }
>  
> +/* Note: Drops fb_helper->lock before returning. */
> +static int __drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper,
> +   int bpp_sel)
> +{
> + struct drm_device *dev = fb_helper->dev;
> + struct fb_info *info;
> + unsigned int width, height;
> + int ret;
> +
> + width = dev->mode_config.max_width;
> + height = dev->mode_config.max_height;
> +
> + drm_setup_crtcs(fb_helper, width, heigh

Re: [Intel-gfx] [PATCH i-g-t 2/3] lib: Add reset-type helper in ioctl_wrappers

[Michel Thierry]

On 6/28/2017 7:10 AM, Arkadiusz Hiler wrote:

On Tue, Jun 20, 2017 at 11:25:01AM -0700, Michel Thierry wrote:

Soon we will have tests that are only for platforms with reset-engine
(GEN8+), so add a helper to query the has_gpu_reset via the getparam ioctl.

Signed-off-by: Michel Thierry 
---
  lib/ioctl_wrappers.c | 22 ++
  lib/ioctl_wrappers.h |  1 +
  2 files changed, 23 insertions(+)

diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 0816a7b6..958b7d03 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -1199,6 +1199,28 @@ bool gem_uses_full_ppgtt(int fd)
  }
  
  /**

+ * gem_gpu_reset_type:
+ * @fd: open i915 drm file descriptor
+ *
+ * Query whether reset-engine (2), global-reset (1) or reset-disable (0)


What about using an enum to save us commenting on the magic numbers
later on?



The problem with enum is that we will forget to keep them updated.
But I can do something like we have for gem_gtt_type(); instead of tests 
calling gem_gpu_reset_type directly, I add these helpers:


- gem_reset_enabled {return gem_gpu_reset_type > 0}
- gem_reset_engine_enabled {return gem_gpu_reset_type > 1}

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

Re: [Intel-gfx] [RESEND i-g-t 1/3] lib/cfl: Add Coffeelake PCI IDs for S SKU.

[Srivatsa, Anusha]

>-Original Message-
>From: Hiler, Arkadiusz
>Sent: Wednesday, June 28, 2017 5:20 AM
>To: Srivatsa, Anusha 
>Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo 
>Subject: Re: [Intel-gfx] [RESEND i-g-t 1/3] lib/cfl: Add Coffeelake PCI IDs 
>for S
>SKU.
>
>On Wed, Jun 28, 2017 at 03:17:00PM +0300, Arkadiusz Hiler wrote:
>> On Thu, Jun 22, 2017 at 09:28:35AM -0700, Anusha Srivatsa wrote:
>> > From: anushasr 
>> >
>> > Just following the spec and adding these extra IDs.
>> >
>> > v2: update IDs following the kernel commit:
>> > b056f8f3d6b900e8afd19f312719160346d263b4 (Chris)
>> >
>> > Cc: Rodrigo Vivi 
>> > Signed-off-by: Anusha Srivatsa 
>> > Reviewed-by: Clint Taylor 
>> > ---
>> >  lib/i915_pciids.h   | 10 ++
>> >  lib/intel_device_info.c |  2 ++
>> >  2 files changed, 12 insertions(+)
>> >
>> > diff --git a/lib/i915_pciids.h b/lib/i915_pciids.h index
>> > 27e0dba..02f43d9 100644
>> > --- a/lib/i915_pciids.h
>> > +++ b/lib/i915_pciids.h
>> > @@ -334,4 +334,14 @@
>> >INTEL_KBL_GT3_IDS(info), \
>> >INTEL_KBL_GT4_IDS(info)
>> >
>> > +#define INTEL_CFL_S_IDS(info) \
>> > +  INTEL_VGA_DEVICE(0x3E90, info), /* SRV GT1 */ \
>> > +  INTEL_VGA_DEVICE(0x3E93, info), /* SRV GT1 */ \
>> > +  INTEL_VGA_DEVICE(0x3E91, info), /* SRV GT2 */ \
>> > +  INTEL_VGA_DEVICE(0x3E92, info), /* SRV GT2 */ \
>> > +  INTEL_VGA_DEVICE(0x3E96, info) /* SRV GT2 */
>> > +
>> > +#define INTEL_CFL_IDS(info) \
>> > +  INTEL_CFL_S_IDS(info)
>> > +
>> >  #endif /* _I915_PCIIDS_H */
>> > diff --git a/lib/intel_device_info.c b/lib/intel_device_info.c index
>> > 199fa2d..2c46aba 100644
>> > --- a/lib/intel_device_info.c
>> > +++ b/lib/intel_device_info.c
>> > @@ -241,6 +241,8 @@ static const struct pci_id_match
>> > intel_device_match[] = {
>> >
>> >INTEL_GLK_IDS(&intel_geminilake_info),
>> >
>> > +  INTEL_CFL_IDS(&intel_coffeelake_info),
>
>Cut the important part accidentally before sending. Here it is:
>
>Hey,
>
>The series does not compile and intel_coffeelake_info is nowhere to be found.
>
>Maybe you are missing a patch from the series?

Intel_coffeelake_info is part of "Introduce Coffeelake platform definition" - 
8c47cc5eca authored by Rodrigo Vivi.

Once that patch is merged, this one compiles. I thought its already merged. 

I need to send the patches with correct authorship anyway, will check again 
Arek. 

Thanks ,
Anusha

>> BTW, having
>> "From: anushasr "
>> on your patches resulting in quite unusual authorship lines.
>>
>> Please consider using `git config --global user.name "Your Full Name"`
>> on the machines you are creating the patches with if this is not
>> intentional.
>>
>> --
>> Cheers,
>> Arek
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t v2 1/2] lib: Add reset-type helper in ioctl_wrappers

[Michel Thierry]

Soon we will have tests that are only for platforms with reset-engine
(GEN8+), so add a helper to query the has_gpu_reset via the getparam ioctl.

v2: Add more helper functions to avoid using magic numbers in tests (Arek).

Cc: Arkadiusz Hiler 
Signed-off-by: Michel Thierry 
---
 lib/ioctl_wrappers.c | 51 +++
 lib/ioctl_wrappers.h |  3 +++
 2 files changed, 54 insertions(+)

diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 2bbaed54..51000bac 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -1193,6 +1193,57 @@ bool gem_uses_full_ppgtt(int fd)
 }
 
 /**
+ * gem_gpu_reset_type:
+ * @fd: open i915 drm file descriptor
+ *
+ * Query whether reset-engine (2), global-reset (1) or reset-disable (0)
+ * is available.
+ *
+ * Returns: GPU reset type available
+ */
+int gem_gpu_reset_type(int fd)
+{
+   struct drm_i915_getparam gp;
+   int gpu_reset_type = -1;
+
+   memset(&gp, 0, sizeof(gp));
+   gp.param = I915_PARAM_HAS_GPU_RESET;
+   gp.value = &gpu_reset_type;
+   drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, &gp);
+
+   return gpu_reset_type;
+}
+
+/**
+ * gem_gpu_reset_enabled:
+ * @fd: open i915 drm file descriptor
+ *
+ * Feature test macro to check whether the kernel internally uses hangchecks
+ * and can reset the GPU upon hang detection. Note that this is also true when
+ * reset-engine (the lightweight, single engine reset) is available.
+ *
+ * Returns: Whether the driver will detect hangs and perform a reset.
+ */
+bool gem_gpu_reset_enabled(int fd)
+{
+   return gem_gpu_reset_type(fd) > 0;
+}
+
+/**
+ * gem_engine_reset_enabled:
+ * @fd: open i915 drm file descriptor
+ *
+ * Feature test macro to check whether the kernel internally uses hangchecks
+ * and can reset individual engines upon hang detection.
+ *
+ * Returns: Whether the driver will detect hangs and perform an engine reset.
+ */
+bool gem_engine_reset_enabled(int fd)
+{
+   return gem_gpu_reset_type(fd) > 1;
+}
+
+/**
  * gem_available_fences:
  * @fd: open i915 drm file descriptor
  *
diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
index e1279d94..8915edca 100644
--- a/lib/ioctl_wrappers.h
+++ b/lib/ioctl_wrappers.h
@@ -166,6 +166,9 @@ bool gem_has_bsd2(int fd);
 int gem_gtt_type(int fd);
 bool gem_uses_ppgtt(int fd);
 bool gem_uses_full_ppgtt(int fd);
+int gem_gpu_reset_type(int fd);
+bool gem_gpu_reset_enabled(int fd);
+bool gem_engine_reset_enabled(int fd);
 int gem_available_fences(int fd);
 uint64_t gem_total_mappable_size(int fd);
 uint64_t gem_total_stolen_size(int fd);
-- 
2.11.0

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

[Intel-gfx] [PATCH i-g-t v2 2/2] tests/gem_reset_stats: Enforce full chip reset mode before run

[Michel Thierry]

Platforms with per-engine reset enabled (i915.reset=2) are unlikely to
perform a full chip reset, keeping the reset_count unmodified. In order
to keep the expectations of this test, enforce that full GPU reset is
enabled (i915.reset=1).

Later on, we can expand the reset_stats ioctl to also return the number
of per-engine resets and use reset_count + reset_engine_count when
checking for the updated reset count.

v2: Rebase, don't use gem_gpu_reset_type directly, since we now have
additional helpers.

Cc: Arkadiusz Hiler 
Signed-off-by: Michel Thierry 
---
 tests/gem_reset_stats.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/tests/gem_reset_stats.c b/tests/gem_reset_stats.c
index 73afeeb2..9ac08aab 100644
--- a/tests/gem_reset_stats.c
+++ b/tests/gem_reset_stats.c
@@ -27,6 +27,8 @@
 
 #define _GNU_SOURCE
 #include "igt.h"
+#include "igt_sysfs.h"
+#include 
 #include 
 #include 
 #include 
@@ -777,15 +779,24 @@ igt_main
int fd;
 
bool has_reset_stats;
+   bool using_full_reset;
fd = drm_open_driver(DRIVER_INTEL);
devid = intel_get_drm_devid(fd);
 
has_reset_stats = gem_has_reset_stats(fd);
 
+   igt_assert(igt_sysfs_set_parameter
+  (fd, "reset", "%d", 1 /* only global reset */));
+
+   using_full_reset = !gem_engine_reset_enabled(fd) &&
+  gem_gpu_reset_enabled(fd);
+
close(fd);
 
igt_require_f(has_reset_stats,
  "No reset stats ioctl support. Too old 
kernel?\n");
+   igt_require_f(using_full_reset,
+ "Full GPU reset is not enabled. Is 
enable_hangcheck set?\n");
}
 
igt_subtest("params")
@@ -831,4 +842,13 @@ igt_main
igt_subtest_f("defer-hangcheck-%s", e->name)
RUN_TEST(defer_hangcheck(e));
}
+
+   igt_fixture {
+   int fd;
+
+   fd = drm_open_driver(DRIVER_INTEL);
+   igt_assert(igt_sysfs_set_parameter
+  (fd, "reset", "%d", INT_MAX /* any reset method */));
+   close(fd);
+   }
 }
-- 
2.11.0

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

[Intel-gfx] [PATCH v3 0/6] drm: add asynchrounous plane update

[Gustavo Padovan]

From: Gustavo Padovan 

Hi,

This is just a rebase on top of latest drm-misc-next. Last iteration
can be found here:

https://www.spinics.net/lists/intel-gfx/msg130582.html

Please review! Thanks,

   Gustavo

---
Gustavo Padovan (6):
  drm/atomic: initial support for asynchronous plane update
  drm/i915: update cursors asynchronously through atomic
  drm/i915: remove intel_cursor_plane_funcs
  drm/msm: update cursors asynchronously through atomic
  drm/msm: remove mdp5_cursor_plane_funcs
  drm/vc4: update cursors asynchronously through atomic

 drivers/gpu/drm/drm_atomic.c  |  70 
 drivers/gpu/drm/drm_atomic_helper.c   |  35 ++
 drivers/gpu/drm/i915/intel_atomic_plane.c |  73 +
 drivers/gpu/drm/i915/intel_display.c  | 160 ---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 175 +++---
 drivers/gpu/drm/msm/msm_atomic.c  |   6 +
 drivers/gpu/drm/vc4/vc4_kms.c |  20 
 drivers/gpu/drm/vc4/vc4_plane.c   | 128 +-
 include/drm/drm_atomic.h  |   2 +
 include/drm/drm_atomic_helper.h   |   2 +
 include/drm/drm_modeset_helper_vtables.h  |  50 +
 11 files changed, 398 insertions(+), 323 deletions(-)

-- 
2.9.4

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

[Intel-gfx] [PATCH v3 1/6] drm/atomic: initial support for asynchronous plane update

[Gustavo Padovan]

From: Gustavo Padovan 

In some cases, like cursor updates, it is interesting to update the
plane in an asynchronous fashion to avoid big delays. The current queued
update could be still waiting for a fence to signal and thus block any
subsequent update until its scan out. In cases like this if we update the
cursor synchronously through the atomic API it will cause significant
delays that would even be noticed by the final user.

This patch creates a fast path to jump ahead the current queued state and
do single planes updates without going through all atomic steps in
drm_atomic_helper_commit(). We take this path for legacy cursor updates.

For now only single plane updates are supported, but we plan to support
multiple planes updates and async PageFlips through this interface as well
in the near future.

v5:
- improve comments (Eric Anholt)

v4:
- fix state->crtc NULL check (Archit Taneja)

v3:
- fix iteration on the wrong crtc state
- put back code to forbid updates if there is a queued update for
the same plane (Ville Syrjälä)
- move size checks back to drivers (Ville Syrjälä)
- move ASYNC_UPDATE flag addition to its own patch (Ville Syrjälä)

v2:
- allow updates even if there is a queued update for the same
plane.
- fixes on the documentation (Emil Velikov)
- unconditionally call ->atomic_async_update (Emil Velikov)
- check for ->atomic_async_update earlier (Daniel Vetter)
- make ->atomic_async_check() the last step (Daniel Vetter)
- add ASYNC_UPDATE flag (Eric Anholt)
- update state in core after ->atomic_async_update (Eric Anholt)
- update docs (Eric Anholt)

Cc: Daniel Vetter 
Cc: Rob Clark 
Cc: Eric Anholt 
Signed-off-by: Gustavo Padovan 
Reviewed-by: Archit Taneja 
Acked-by: Eric Anholt 
---
 drivers/gpu/drm/drm_atomic.c | 70 
 drivers/gpu/drm/drm_atomic_helper.c  | 35 
 include/drm/drm_atomic.h |  2 +
 include/drm/drm_atomic_helper.h  |  2 +
 include/drm/drm_modeset_helper_vtables.h | 50 +++
 5 files changed, 159 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c0f336d..e406688 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -644,6 +644,73 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
return 0;
 }
 
+static bool drm_atomic_async_check(struct drm_atomic_state *state)
+{
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   struct drm_crtc_commit *commit;
+   struct drm_plane *__plane, *plane = NULL;
+   struct drm_plane_state *__plane_state, *plane_state = NULL;
+   const struct drm_plane_helper_funcs *funcs;
+   int i, j, n_planes = 0;
+
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+   if (drm_atomic_crtc_needs_modeset(crtc_state))
+   return false;
+   }
+
+   for_each_new_plane_in_state(state, __plane, __plane_state, i) {
+   n_planes++;
+   plane = __plane;
+   plane_state = __plane_state;
+   }
+
+   /* FIXME: we support only single plane updates for now */
+   if (!plane || n_planes != 1)
+   return false;
+
+   if (!plane_state->crtc)
+   return false;
+
+   funcs = plane->helper_private;
+   if (!funcs->atomic_async_update)
+   return false;
+
+   if (plane_state->fence)
+   return false;
+
+   /*
+* Don't do an async update if there is an outstanding commit modifying
+* the plane.  This prevents our async update's changes from getting
+* overridden by a previous synchronous update's state.
+*/
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+   if (plane->crtc != crtc)
+   continue;
+
+   spin_lock(&crtc->commit_lock);
+   commit = list_first_entry_or_null(&crtc->commit_list,
+ struct drm_crtc_commit,
+ commit_entry);
+   if (!commit) {
+   spin_unlock(&crtc->commit_lock);
+   continue;
+   }
+   spin_unlock(&crtc->commit_lock);
+
+   if (!crtc->state->state)
+   continue;
+
+   for_each_plane_in_state(crtc->state->state, __plane,
+   __plane_state, j) {
+   if (__plane == plane)
+   return false;
+   }
+   }
+
+   return !funcs->atomic_async_check(plane, plane_state);
+}
+
 static void drm_atomic_crtc_print_state(struct drm_printer *p,
const struct drm_crtc_state *state)
 {
@@ -1665,6 +1732,9 @@ int drm_atomic_c

[Intel-gfx] [PATCH v3 3/6] drm/i915: remove intel_cursor_plane_funcs

[Gustavo Padovan]

From: Gustavo Padovan 

After converting legacy cursor updates to atomic async commits
intel_cursor_plane_funcs just duplicates intel_plane_funcs now.

Cc: Daniel Vetter 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/i915/intel_display.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 736301d..36f96271a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13412,17 +13412,6 @@ const struct drm_plane_funcs intel_plane_funcs = {
.atomic_destroy_state = intel_plane_destroy_state,
 };
 
-static const struct drm_plane_funcs intel_cursor_plane_funcs = {
-   .update_plane = drm_atomic_helper_update_plane,
-   .disable_plane = drm_atomic_helper_disable_plane,
-   .destroy = intel_plane_destroy,
-   .set_property = drm_atomic_helper_plane_set_property,
-   .atomic_get_property = intel_plane_atomic_get_property,
-   .atomic_set_property = intel_plane_atomic_set_property,
-   .atomic_duplicate_state = intel_plane_duplicate_state,
-   .atomic_destroy_state = intel_plane_destroy_state,
-};
-
 static struct intel_plane *
 intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
 {
@@ -13669,7 +13658,7 @@ intel_cursor_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
cursor->disable_plane = intel_disable_cursor_plane;
 
ret = drm_universal_plane_init(&dev_priv->drm, &cursor->base,
-  0, &intel_cursor_plane_funcs,
+  0, &intel_plane_funcs,
   intel_cursor_formats,
   ARRAY_SIZE(intel_cursor_formats),
   DRM_PLANE_TYPE_CURSOR,
-- 
2.9.4

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

[Intel-gfx] [PATCH v3 2/6] drm/i915: update cursors asynchronously through atomic

[Gustavo Padovan]

From: Gustavo Padovan 

Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
intel_legacy_cursor_update() did but through atomic.

v3:
- set correct vma to new state for cleanup
- move size checks back to drivers (Ville Syrjälä)

v2:
- move fb setting to core and use new state (Eric Anholt)

Cc: Daniel Vetter 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c |  73 +++
 drivers/gpu/drm/i915/intel_display.c  | 149 +-
 2 files changed, 97 insertions(+), 125 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index a40c82c..1737b8a 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -246,11 +246,84 @@ static void intel_plane_atomic_update(struct drm_plane 
*plane,
}
 }
 
+static int intel_plane_atomic_async_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+   struct drm_crtc *crtc = plane->state->crtc;
+   struct drm_crtc_state *crtc_state = crtc->state;
+
+   if (plane->type != DRM_PLANE_TYPE_CURSOR)
+   return -EINVAL;
+
+   /*
+* When crtc is inactive or there is a modeset pending,
+* wait for it to complete in the slowpath
+*/
+   if (!crtc_state->active || to_intel_crtc_state(crtc_state)->update_pipe)
+   return -EINVAL;
+
+   /*
+* If any parameters change that may affect watermarks,
+* take the slowpath. Only changing fb or position should be
+* in the fastpath.
+*/
+   if (plane->state->crtc != state->crtc ||
+   plane->state->src_w != state->src_w ||
+   plane->state->src_h != state->src_h ||
+   plane->state->crtc_w != state->crtc_w ||
+   plane->state->crtc_h != state->crtc_h ||
+   !plane->state->fb != !state->fb)
+   return -EINVAL;
+
+   return 0;
+}
+
+static void intel_plane_atomic_async_update(struct drm_plane *plane,
+   struct drm_plane_state *new_state)
+{
+   struct intel_plane *intel_plane = to_intel_plane(plane);
+   struct drm_crtc *crtc = plane->state->crtc;
+   struct drm_framebuffer *old_fb;
+   struct i915_vma *old_vma;
+
+   old_vma = to_intel_plane_state(plane->state)->vma;
+   old_fb = plane->state->fb;
+
+   i915_gem_track_fb(intel_fb_obj(old_fb), intel_fb_obj(new_state->fb),
+ intel_plane->frontbuffer_bit);
+
+   plane->state->src_x = new_state->src_x;
+   plane->state->src_y = new_state->src_y;
+   plane->state->crtc_x = new_state->crtc_x;
+   plane->state->crtc_y = new_state->crtc_y;
+   plane->state->fb = new_state->fb;
+   *to_intel_plane_state(plane->state) = *to_intel_plane_state(new_state);
+
+   to_intel_plane_state(new_state)->vma = old_vma;
+   new_state->fb = old_fb;
+
+   if (plane->state->visible) {
+   trace_intel_update_plane(plane, to_intel_crtc(crtc));
+   intel_plane->update_plane(plane,
+ to_intel_crtc_state(crtc->state),
+ to_intel_plane_state(plane->state));
+   } else {
+   trace_intel_disable_plane(plane, to_intel_crtc(crtc));
+   intel_plane->disable_plane(plane, crtc);
+   }
+
+   mutex_lock(&plane->dev->struct_mutex);
+   intel_cleanup_plane_fb(plane, new_state);
+   mutex_unlock(&plane->dev->struct_mutex);
+}
+
 const struct drm_plane_helper_funcs intel_plane_helper_funcs = {
.prepare_fb = intel_prepare_plane_fb,
.cleanup_fb = intel_cleanup_plane_fb,
.atomic_check = intel_plane_atomic_check,
.atomic_update = intel_plane_atomic_update,
+   .atomic_async_check = intel_plane_atomic_async_check,
+   .atomic_async_update = intel_plane_atomic_async_update,
 };
 
 /**
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 636c64e..736301d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13004,6 +13004,26 @@ static int intel_atomic_commit(struct drm_device *dev,
struct drm_i915_private *dev_priv = to_i915(dev);
int ret = 0;
 
+   /*
+* The atomic async update fast path takes care
+* of avoiding the vblank waits for simple cursor
+* movement and flips. For cursor on/off and size changes,
+* we want to perform the vblank waits so that watermark
+* updates happen during the correct frames. Gen9+ have
+* double buffered watermarks and so shouldn't need this.
+*/
+   if (state->async_update) {
+   ret = mutex_lock_interruptible(&dev->struct_mutex);
+   if (

[Intel-gfx] [PATCH v3 4/6] drm/msm: update cursors asynchronously through atomic

[Gustavo Padovan]

From: Gustavo Padovan 

Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
mdp5_update_cursor_plane_legacy() did but through atomic.

v4: add missing atomic async commit call to msm_atomic_commit(Archit Taneja)

v3: move size checks back to drivers (Ville Syrjälä)

v2: move fb setting to core and use new state (Eric Anholt)

Cc: Rob Clark 
Cc: Archit Taneja 
Signed-off-by: Gustavo Padovan 
Tested-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 151 +-
 drivers/gpu/drm/msm/msm_atomic.c  |   6 ++
 2 files changed, 69 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 5e7d9af..bb5ee03 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -33,15 +33,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
struct drm_crtc *crtc, struct drm_framebuffer *fb,
struct drm_rect *src, struct drm_rect *dest);
 
-static int mdp5_update_cursor_plane_legacy(struct drm_plane *plane,
-   struct drm_crtc *crtc,
-   struct drm_framebuffer *fb,
-   int crtc_x, int crtc_y,
-   unsigned int crtc_w, unsigned int crtc_h,
-   uint32_t src_x, uint32_t src_y,
-   uint32_t src_w, uint32_t src_h,
-   struct drm_modeset_acquire_ctx *ctx);
-
 static struct mdp5_kms *get_kms(struct drm_plane *plane)
 {
struct msm_drm_private *priv = plane->dev->dev_private;
@@ -257,7 +248,7 @@ static const struct drm_plane_funcs mdp5_plane_funcs = {
 };
 
 static const struct drm_plane_funcs mdp5_cursor_plane_funcs = {
-   .update_plane = mdp5_update_cursor_plane_legacy,
+   .update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = mdp5_plane_destroy,
.set_property = drm_atomic_helper_plane_set_property,
@@ -484,11 +475,73 @@ static void mdp5_plane_atomic_update(struct drm_plane 
*plane,
}
 }
 
+static int mdp5_plane_atomic_async_check(struct drm_plane *plane,
+struct drm_plane_state *state)
+{
+   struct mdp5_plane_state *mdp5_state = to_mdp5_plane_state(state);
+   struct drm_crtc_state *crtc_state;
+
+   crtc_state = drm_atomic_get_existing_crtc_state(state->state,
+   state->crtc);
+   if (WARN_ON(!crtc_state))
+   return -EINVAL;
+
+   if (!crtc_state->active)
+   return -EINVAL;
+
+   mdp5_state = to_mdp5_plane_state(state);
+
+   /* don't use fast path if we don't have a hwpipe allocated yet */
+   if (!mdp5_state->hwpipe)
+   return -EINVAL;
+
+   /* only allow changing of position(crtc x/y or src x/y) in fast path */
+   if (plane->state->crtc != state->crtc ||
+   plane->state->src_w != state->src_w ||
+   plane->state->src_h != state->src_h ||
+   plane->state->crtc_w != state->crtc_w ||
+   plane->state->crtc_h != state->crtc_h ||
+   !plane->state->fb ||
+   plane->state->fb != state->fb)
+   return -EINVAL;
+
+   return 0;
+}
+
+static void mdp5_plane_atomic_async_update(struct drm_plane *plane,
+  struct drm_plane_state *new_state)
+{
+   plane->state->src_x = new_state->src_x;
+   plane->state->src_y = new_state->src_y;
+   plane->state->crtc_x = new_state->crtc_x;
+   plane->state->crtc_y = new_state->crtc_y;
+
+   if (plane_enabled(new_state)) {
+   struct mdp5_ctl *ctl;
+   struct mdp5_pipeline *pipeline =
+   mdp5_crtc_get_pipeline(plane->crtc);
+   int ret;
+
+   ret = mdp5_plane_mode_set(plane, new_state->crtc, new_state->fb,
+   &new_state->src, &new_state->dst);
+   WARN_ON(ret < 0);
+
+   ctl = mdp5_crtc_get_ctl(new_state->crtc);
+
+   mdp5_ctl_commit(ctl, pipeline, mdp5_plane_get_flush(plane));
+   }
+
+   *to_mdp5_plane_state(plane->state) =
+   *to_mdp5_plane_state(new_state);
+}
+
 static const struct drm_plane_helper_funcs mdp5_plane_helper_funcs = {
.prepare_fb = mdp5_plane_prepare_fb,
.cleanup_fb = mdp5_plane_cleanup_fb,
.atomic_check = mdp5_plane_atomic_check,
.atomic_update = mdp5_plane_atomic_update,
+   .atomic_async_check = mdp5_plane_atomic_async_check,
+   .atomic_async_update = mdp5_plane_atomic_async_update,
 };
 
 static void set_scanout_locked(struct mdp5_kms *mdp5_kms,
@@ -997,84 +1050,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
re

[Intel-gfx] [PATCH v3 5/6] drm/msm: remove mdp5_cursor_plane_funcs

[Gustavo Padovan]

From: Gustavo Padovan 

After converting legacy cursor updates to atomic async commits
mdp5_cursor_plane_funcs just duplicates mdp5_plane_funcs now.

Cc: Rob Clark 
Cc: Archit Taneja 
Signed-off-by: Gustavo Padovan 
Tested-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 26 +++---
 1 file changed, 3 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index bb5ee03..e6bf21d 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -247,19 +247,6 @@ static const struct drm_plane_funcs mdp5_plane_funcs = {
.atomic_print_state = mdp5_plane_atomic_print_state,
 };
 
-static const struct drm_plane_funcs mdp5_cursor_plane_funcs = {
-   .update_plane = drm_atomic_helper_update_plane,
-   .disable_plane = drm_atomic_helper_disable_plane,
-   .destroy = mdp5_plane_destroy,
-   .set_property = drm_atomic_helper_plane_set_property,
-   .atomic_set_property = mdp5_plane_atomic_set_property,
-   .atomic_get_property = mdp5_plane_atomic_get_property,
-   .reset = mdp5_plane_reset,
-   .atomic_duplicate_state = mdp5_plane_duplicate_state,
-   .atomic_destroy_state = mdp5_plane_destroy_state,
-   .atomic_print_state = mdp5_plane_atomic_print_state,
-};
-
 static int mdp5_plane_prepare_fb(struct drm_plane *plane,
 struct drm_plane_state *new_state)
 {
@@ -,16 +1098,9 @@ struct drm_plane *mdp5_plane_init(struct drm_device *dev,
 
spin_lock_init(&mdp5_plane->pipe_lock);
 
-   if (type == DRM_PLANE_TYPE_CURSOR)
-   ret = drm_universal_plane_init(dev, plane, 0xff,
-   &mdp5_cursor_plane_funcs,
-   mdp5_plane->formats, mdp5_plane->nformats,
-   type, NULL);
-   else
-   ret = drm_universal_plane_init(dev, plane, 0xff,
-   &mdp5_plane_funcs,
-   mdp5_plane->formats, mdp5_plane->nformats,
-   type, NULL);
+   ret = drm_universal_plane_init(dev, plane, 0xff, &mdp5_plane_funcs,
+  mdp5_plane->formats,
+  mdp5_plane->nformats, type, NULL);
if (ret)
goto fail;
 
-- 
2.9.4

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

[Intel-gfx] [PATCH v3 6/6] drm/vc4: update cursors asynchronously through atomic

[Gustavo Padovan]

From: Gustavo Padovan 

Add support for async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
vc4_update_plane() did but through atomic.

v5: add missing call to vc4_plane_atomic_check() (Eric Anholt)

v4: add drm_atomic_helper_async() commit (Eric Anholt)

v3: move size checks back to drivers (Ville Syrjälä)

v2: move fb setting to core and use new state (Eric Anholt)

Cc: Eric Anholt 
Signed-off-by: Gustavo Padovan 
Reviewed-by: Eric Anholt 
Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_kms.c   |  20 +++
 drivers/gpu/drm/vc4/vc4_plane.c | 128 
 2 files changed, 71 insertions(+), 77 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 27edae4..efd2656 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -95,6 +95,26 @@ static int vc4_atomic_commit(struct drm_device *dev,
struct vc4_dev *vc4 = to_vc4_dev(dev);
int ret;
 
+   if (state->async_update) {
+   ret = down_interruptible(&vc4->async_modeset);
+   if (ret)
+   return ret;
+
+   ret = drm_atomic_helper_prepare_planes(dev, state);
+   if (ret) {
+   up(&vc4->async_modeset);
+   return ret;
+   }
+
+   drm_atomic_helper_async_commit(dev, state);
+
+   drm_atomic_helper_cleanup_planes(dev, state);
+
+   up(&vc4->async_modeset);
+
+   return 0;
+   }
+
ret = drm_atomic_helper_setup_commit(state, nonblock);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 8853e9a..52bf74c 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -759,87 +759,41 @@ void vc4_plane_async_set_fb(struct drm_plane *plane, 
struct drm_framebuffer *fb)
vc4_state->dlist[vc4_state->ptr0_offset] = addr;
 }
 
-static int vc4_prepare_fb(struct drm_plane *plane,
- struct drm_plane_state *state)
+static int vc4_plane_atomic_async_check(struct drm_plane *plane,
+   struct drm_plane_state *state)
 {
-   struct vc4_bo *bo;
-   struct dma_fence *fence;
+   if (plane != state->crtc->cursor)
+   return -EINVAL;
 
-   if ((plane->state->fb == state->fb) || !state->fb)
-   return 0;
+   if (!plane->state)
+   return -EINVAL;
 
-   bo = to_vc4_bo(&drm_fb_cma_get_gem_obj(state->fb, 0)->base);
-   fence = reservation_object_get_excl_rcu(bo->resv);
-   drm_atomic_set_fence_for_plane(state, fence);
+   /* No configuring new scaling in the fast path. */
+   if (state->crtc_w != plane->state->crtc_w ||
+   state->crtc_h != plane->state->crtc_h ||
+   state->src_w != plane->state->src_w ||
+   state->src_h != plane->state->src_h) {
+   return -EINVAL;
+   }
 
return 0;
 }
 
-static const struct drm_plane_helper_funcs vc4_plane_helper_funcs = {
-   .atomic_check = vc4_plane_atomic_check,
-   .atomic_update = vc4_plane_atomic_update,
-   .prepare_fb = vc4_prepare_fb,
-};
-
-static void vc4_plane_destroy(struct drm_plane *plane)
-{
-   drm_plane_helper_disable(plane);
-   drm_plane_cleanup(plane);
-}
-
-/* Implements immediate (non-vblank-synced) updates of the cursor
- * position, or falls back to the atomic helper otherwise.
- */
-static int
-vc4_update_plane(struct drm_plane *plane,
-struct drm_crtc *crtc,
-struct drm_framebuffer *fb,
-int crtc_x, int crtc_y,
-unsigned int crtc_w, unsigned int crtc_h,
-uint32_t src_x, uint32_t src_y,
-uint32_t src_w, uint32_t src_h,
-struct drm_modeset_acquire_ctx *ctx)
+static void vc4_plane_atomic_async_update(struct drm_plane *plane,
+ struct drm_plane_state *new_state)
 {
-   struct drm_plane_state *plane_state;
-   struct vc4_plane_state *vc4_state;
-
-   if (plane != crtc->cursor)
-   goto out;
-
-   plane_state = plane->state;
-   vc4_state = to_vc4_plane_state(plane_state);
-
-   if (!plane_state)
-   goto out;
-
-   /* No configuring new scaling in the fast path. */
-   if (crtc_w != plane_state->crtc_w ||
-   crtc_h != plane_state->crtc_h ||
-   src_w != plane_state->src_w ||
-   src_h != plane_state->src_h) {
-   goto out;
-   }
-
-   if (fb != plane_state->fb) {
-   drm_atomic_set_fb_for_plane(plane->state, fb);
-   vc4_plane_async_set_fb(plane, fb);
-   }
+   struct vc4_plane_state *vc4_state = to_vc4_plane_state(plane->state);
 
-   /* Set the cursor's position on the screen.  Thi

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: add asynchrounous plane update (rev4)

[Patchwork]

== Series Details ==

Series: drm: add asynchrounous plane update (rev4)
URL   : https://patchwork.freedesktop.org/series/25814/
State : failure

== Summary ==

  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CHK include/generated/bounds.h
  CHK include/generated/timeconst.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  CHK scripts/mod/devicetable-offsets.h
  CHK include/generated/compile.h
  CHK kernel/config_data.h
  CC [M]  drivers/gpu/drm/i915/intel_atomic_plane.o
drivers/gpu/drm/i915/intel_atomic_plane.c: In function 
‘intel_plane_atomic_async_update’:
drivers/gpu/drm/i915/intel_atomic_plane.c:291:29: error: passing argument 1 of 
‘intel_plane->update_plane’ from incompatible pointer type 
[-Werror=incompatible-pointer-types]
   intel_plane->update_plane(plane,
 ^
drivers/gpu/drm/i915/intel_atomic_plane.c:291:29: note: expected ‘struct 
intel_plane *’ but argument is of type ‘struct drm_plane *’
drivers/gpu/drm/i915/intel_atomic_plane.c:296:30: error: passing argument 1 of 
‘intel_plane->disable_plane’ from incompatible pointer type 
[-Werror=incompatible-pointer-types]
   intel_plane->disable_plane(plane, crtc);
  ^
drivers/gpu/drm/i915/intel_atomic_plane.c:296:30: note: expected ‘struct 
intel_plane *’ but argument is of type ‘struct drm_plane *’
drivers/gpu/drm/i915/intel_atomic_plane.c:296:37: error: passing argument 2 of 
‘intel_plane->disable_plane’ from incompatible pointer type 
[-Werror=incompatible-pointer-types]
   intel_plane->disable_plane(plane, crtc);
 ^
drivers/gpu/drm/i915/intel_atomic_plane.c:296:37: note: expected ‘struct 
intel_crtc *’ but argument is of type ‘struct drm_crtc *’
cc1: all warnings being treated as errors
scripts/Makefile.build:302: recipe for target 
'drivers/gpu/drm/i915/intel_atomic_plane.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_atomic_plane.o] Error 1
scripts/Makefile.build:561: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:561: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:561: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1016: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

Re: [Intel-gfx] [RESEND i-g-t 3/3] lib/cfl: Add PCI Ids for U SKU in CFl

[Clint Taylor]

On 06/22/2017 09:28 AM, Anusha Srivatsa wrote:

From: anushasr 

Follow the spec and add ID for U SKU

v2: Update IDs in accordance to the kernel commit:
d29fe702c9cb682df99146d24d06e5455f043101 (Chris)

Cc: Rodrigo Vivi 
Signed-off-by: Anusha Srivatsa 
---
  lib/i915_pciids.h | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/lib/i915_pciids.h b/lib/i915_pciids.h
index c319e37..71cce60 100644
--- a/lib/i915_pciids.h
+++ b/lib/i915_pciids.h
@@ -346,8 +346,15 @@
INTEL_VGA_DEVICE(0x3E9B, info), /* Halo GT2 */ \
INTEL_VGA_DEVICE(0x3E94, info) /* Halo GT2 */
  
+#define INTEL_CFL_U_IDS(info) \

+   INTEL_VGA_DEVICE(0x3EA5, info), /* ULT GT3 */ \
+   INTEL_VGA_DEVICE(0x3EA6, info), /* ULT GT3 */ \
+   INTEL_VGA_DEVICE(0x3EA7, info), /* ULT GT3 */ \
+   INTEL_VGA_DEVICE(0x3EA8, info) /* ULT GT3 */
+

Added devices match i915 driver IDs.
Reviewed-by: Clinton Taylor 


  #define INTEL_CFL_IDS(info) \
INTEL_CFL_S_IDS(info), \
-   INTEL_CFL_H_IDS(info)
+   INTEL_CFL_H_IDS(info), \
+   INTEL_CFL_U_IDS(info)
  
  #endif /* _I915_PCIIDS_H */


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

[Intel-gfx] [PATCH] drm/i915: reintroduce VLV/CHV PFI programming power domain workaround

[Gabriel Krisman Bertazi]

There are still cases on these platforms where an attempt is made to
configure the CDCLK while the power domain is off, like when coming back
from a suspend.  So the workaround below is still needed.

This effectively reverts commit 63ff30442519 ("drm/i915: Nuke the
VLV/CHV PFI programming power domain workaround").

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

Suggested-by: Ville Syrjälä 
Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/i915/intel_cdclk.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index b8914db7d2e1..1241e5891b29 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -491,6 +491,14 @@ static void vlv_set_cdclk(struct drm_i915_private 
*dev_priv,
int cdclk = cdclk_state->cdclk;
u32 val, cmd;
 
+   /* There are cases where we can end up here with power domains
+* off and a CDCLK frequency other than the minimum, like when
+* issuing a modeset without actually changing any display after
+* a system suspend.  So grab the PIPE-A domain, which covers
+* the HW blocks needed for the following programming.
+*/
+   intel_display_power_get(dev_priv, POWER_DOMAIN_PIPE_A);
+
if (cdclk >= 32) /* jump to highest voltage for 400MHz too */
cmd = 2;
else if (cdclk == 27)
@@ -549,6 +557,8 @@ static void vlv_set_cdclk(struct drm_i915_private *dev_priv,
intel_update_cdclk(dev_priv);
 
vlv_program_pfi_credits(dev_priv);
+
+   intel_display_power_put(dev_priv, POWER_DOMAIN_PIPE_A);
 }
 
 static void chv_set_cdclk(struct drm_i915_private *dev_priv,
@@ -568,6 +578,14 @@ static void chv_set_cdclk(struct drm_i915_private 
*dev_priv,
return;
}
 
+   /* There are cases where we can end up here with power domains
+* off and a CDCLK frequency other than the minimum, like when
+* issuing a modeset without actually changing any display after
+* a system suspend.  So grab the PIPE-A domain, which covers
+* the HW blocks needed for the following programming.
+*/
+   intel_display_power_get(dev_priv, POWER_DOMAIN_PIPE_A);
+
/*
 * Specs are full of misinformation, but testing on actual
 * hardware has shown that we just need to write the desired
@@ -590,6 +608,8 @@ static void chv_set_cdclk(struct drm_i915_private *dev_priv,
intel_update_cdclk(dev_priv);
 
vlv_program_pfi_credits(dev_priv);
+
+   intel_display_power_put(dev_priv, POWER_DOMAIN_PIPE_A);
 }
 
 static int bdw_calc_cdclk(int max_pixclk)
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH libdrm 1/3] intel: PCI Ids for S SKU in CFL

[Clint Taylor]

On 06/21/2017 09:39 AM, Anusha Srivatsa wrote:

Add the PCI IDs for S SKU IN CFL by following the spec.

v2: Update IDs.

Cc: Rodrigo Vivi 
Signed-off-by: Anusha Srivatsa 
---
  intel/intel_chipset.h | 17 -
  1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 41fc0da..36bbec9 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -221,6 +221,12 @@
  #define PCI_CHIP_GLK  0x3184
  #define PCI_CHIP_GLK_2X6  0x3185
  
+#define PCI_CHIP_COFFEELAKE_S_GT1_1 0x3E90

+#define PCI_CHIP_COFFEELAKE_S_GT1_2 0x3E93
+#define PCI_CHIP_COFFEELAKE_S_GT2_1 0x3E91
+#define PCI_CHIP_COFFEELAKE_S_GT2_2 0x3E92
+#define PCI_CHIP_COFFEELAKE_S_GT2_3 0x3E96

Matches BSPEC DID2 values.
Reviewed-by: Clinton Taylor 


+
  #define IS_MOBILE(devid)  ((devid) == PCI_CHIP_I855_GM || \
 (devid) == PCI_CHIP_I915_GM || \
 (devid) == PCI_CHIP_I945_GM || \
@@ -452,10 +458,19 @@
  #define IS_GEMINILAKE(devid)  ((devid) == PCI_CHIP_GLK || \
 (devid) == PCI_CHIP_GLK_2X6)
  
+#define IS_CFL_S(devid) ((devid) == PCI_CHIP_COFFEELAKE_S_GT1_1 || \

+(devid) == PCI_CHIP_COFFEELAKE_S_GT1_2 || \
+(devid) == PCI_CHIP_COFFEELAKE_S_GT2_1 || \
+(devid) == PCI_CHIP_COFFEELAKE_S_GT2_2 || \
+(devid) == PCI_CHIP_COFFEELAKE_S_GT2_3 )
+
+#define IS_COFFEELAKE(devid)   (IS_CFL_S(devid))
+
  #define IS_GEN9(devid)(IS_SKYLAKE(devid)  || \
 IS_BROXTON(devid)  || \
 IS_KABYLAKE(devid) || \
-IS_GEMINILAKE(devid))
+IS_GEMINILAKE(devid) || \
+IS_COFFEELAKE(devid))
  
  #define IS_9XX(dev)		(IS_GEN3(dev) || \

 IS_GEN4(dev) || \


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

Re: [Intel-gfx] [PATCH libdrm 2/3] intel: PCI Ids for H SKU in CFL

[Clint Taylor]

On 06/21/2017 09:39 AM, Anusha Srivatsa wrote:

Add the PCI IDs for H SKU IN CFL by following the spec.

v2: Update IDs

Cc: Rodrigo Vivi 
Signed-off-by: Anusha Srivatsa 
---
  intel/intel_chipset.h | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 36bbec9..4da145c 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -226,6 +226,8 @@
  #define PCI_CHIP_COFFEELAKE_S_GT2_1 0x3E91
  #define PCI_CHIP_COFFEELAKE_S_GT2_2 0x3E92
  #define PCI_CHIP_COFFEELAKE_S_GT2_3 0x3E96
+#define PCI_CHIP_COFFEELAKE_H_GT2_1 0x3E9B
+#define PCI_CHIP_COFFEELAKE_H_GT2_2 0x3E94

Matches BSPEC DID2 values
Reviewed-by: Clinton Taylor 

  
  #define IS_MOBILE(devid)	((devid) == PCI_CHIP_I855_GM || \

 (devid) == PCI_CHIP_I915_GM || \
@@ -464,7 +466,11 @@
  (devid) == PCI_CHIP_COFFEELAKE_S_GT2_2 || \
  (devid) == PCI_CHIP_COFFEELAKE_S_GT2_3 )
  
-#define IS_COFFEELAKE(devid)   (IS_CFL_S(devid))

+#define IS_CFL_H(devid) ((devid) == PCI_CHIP_COFFEELAKE_H_GT2_1 || \
+ (devid) == PCI_CHIP_COFFEELAKE_H_GT2_2)
+
+#define IS_COFFEELAKE(devid)   (IS_CFL_S(devid) || \
+   IS_CFL_H(devid))
  
  #define IS_GEN9(devid)		(IS_SKYLAKE(devid)  || \

 IS_BROXTON(devid)  || \


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

Re: [Intel-gfx] [PATCH libdrm 3/3] intel: PCI Ids for U SKU in CFL

[Clint Taylor]

On 06/21/2017 09:39 AM, Anusha Srivatsa wrote:

Add the PCI IDs for U SKU IN CFL by following the spec.

v2: Update IDs

Cc: Rodrigo Vivi 
Signed-off-by: Anusha Srivatsa 
---
  intel/intel_chipset.h | 12 +++-
  1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 4da145c..8a0d4ff 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -228,6 +228,10 @@
  #define PCI_CHIP_COFFEELAKE_S_GT2_3 0x3E96
  #define PCI_CHIP_COFFEELAKE_H_GT2_1 0x3E9B
  #define PCI_CHIP_COFFEELAKE_H_GT2_2 0x3E94
+#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA5
+#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA6
+#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA7
+#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA8

Matches values in i915 driver.
Reviewed-by: Clinton Taylor 

  
  #define IS_MOBILE(devid)	((devid) == PCI_CHIP_I855_GM || \

 (devid) == PCI_CHIP_I915_GM || \
@@ -469,8 +473,14 @@
  #define IS_CFL_H(devid) ((devid) == PCI_CHIP_COFFEELAKE_H_GT2_1 || \
   (devid) == PCI_CHIP_COFFEELAKE_H_GT2_2)
  
+#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT3_1 || \

+ (devid) == PCI_CHIP_COFFEELAKE_U_GT3_2 || \
+ (devid) == PCI_CHIP_COFFEELAKE_U_GT3_3 || \
+ (devid) == PCI_CHIP_COFFEELAKE_U_GT3_4)
+
  #define IS_COFFEELAKE(devid)   (IS_CFL_S(devid) || \
-   IS_CFL_H(devid))
+   IS_CFL_H(devid) || \
+   IS_CFL_U(devid))
  
  #define IS_GEN9(devid)		(IS_SKYLAKE(devid)  || \

 IS_BROXTON(devid)  || \


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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm: add asynchrounous plane update (rev4)

[Gustavo Padovan]

This patch is meant for drm-misc, where the changes to
intel_plane->update_plane() and intel_plane->disable_plane() are not
present, so this patchset just builds fine there.

2017-06-28 Patchwork :

> == Series Details ==
> 
> Series: drm: add asynchrounous plane update (rev4)
> URL   : https://patchwork.freedesktop.org/series/25814/
> State : failure
> 
> == Summary ==
> 
>   CHK include/config/kernel.release
>   CHK include/generated/uapi/linux/version.h
>   CHK include/generated/utsrelease.h
>   CHK include/generated/bounds.h
>   CHK include/generated/timeconst.h
>   CHK include/generated/asm-offsets.h
>   CALLscripts/checksyscalls.sh
>   CHK scripts/mod/devicetable-offsets.h
>   CHK include/generated/compile.h
>   CHK kernel/config_data.h
>   CC [M]  drivers/gpu/drm/i915/intel_atomic_plane.o
> drivers/gpu/drm/i915/intel_atomic_plane.c: In function 
> ‘intel_plane_atomic_async_update’:
> drivers/gpu/drm/i915/intel_atomic_plane.c:291:29: error: passing argument 1 
> of ‘intel_plane->update_plane’ from incompatible pointer type 
> [-Werror=incompatible-pointer-types]
>intel_plane->update_plane(plane,
>  ^
> drivers/gpu/drm/i915/intel_atomic_plane.c:291:29: note: expected ‘struct 
> intel_plane *’ but argument is of type ‘struct drm_plane *’
> drivers/gpu/drm/i915/intel_atomic_plane.c:296:30: error: passing argument 1 
> of ‘intel_plane->disable_plane’ from incompatible pointer type 
> [-Werror=incompatible-pointer-types]
>intel_plane->disable_plane(plane, crtc);
>   ^
> drivers/gpu/drm/i915/intel_atomic_plane.c:296:30: note: expected ‘struct 
> intel_plane *’ but argument is of type ‘struct drm_plane *’
> drivers/gpu/drm/i915/intel_atomic_plane.c:296:37: error: passing argument 2 
> of ‘intel_plane->disable_plane’ from incompatible pointer type 
> [-Werror=incompatible-pointer-types]
>intel_plane->disable_plane(plane, crtc);
>  ^
> drivers/gpu/drm/i915/intel_atomic_plane.c:296:37: note: expected ‘struct 
> intel_crtc *’ but argument is of type ‘struct drm_crtc *’
> cc1: all warnings being treated as errors
> scripts/Makefile.build:302: recipe for target 
> 'drivers/gpu/drm/i915/intel_atomic_plane.o' failed
> make[4]: *** [drivers/gpu/drm/i915/intel_atomic_plane.o] Error 1
> scripts/Makefile.build:561: recipe for target 'drivers/gpu/drm/i915' failed
> make[3]: *** [drivers/gpu/drm/i915] Error 2
> scripts/Makefile.build:561: recipe for target 'drivers/gpu/drm' failed
> make[2]: *** [drivers/gpu/drm] Error 2
> scripts/Makefile.build:561: recipe for target 'drivers/gpu' failed
> make[1]: *** [drivers/gpu] Error 2
> Makefile:1016: recipe for target 'drivers' failed
> make: *** [drivers] Error 2
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Set all undefined MOCS entries to follow PTE

[Francisco Jerez]

Chris Wilson  writes:

> Quoting Francisco Jerez (2017-05-04 21:59:44)
>> Chris Wilson  writes:
>> 
>> > On Thu, May 04, 2017 at 10:56:54AM -0700, Francisco Jerez wrote:
>> >> David Weinehall  writes:
>> >> 
>> >> > On Thu, May 04, 2017 at 10:51:29AM +0100, Chris Wilson wrote:
>> >> >> A good default for garbage entries from the user is to follow the
>> >> >> default setting of the object (i.e. the PTE). Currently they use the
>> >> >> uncached entry, and now the only way to accidentally hit uncached
>> >> >> performance is via explicit use of the uncached MOCS or setting the
>> >> >> object to uncached. Note that these entries are currently undefined in
>> >> >> the ABI and we reserve the right to change them. We originally chose
>> >> >> uncached to eliminate any problem with reducing the caching level in
>> >> >> future, but the object is a much better definition of the minimum
>> >> >> caching level.
>> >> >> 
>> >> 
>> >> NAK.  The reason for the default being UC is that it's the only setting
>> >> that guarantees full forwards compatibility with any other entry that
>> >> might be added in the future.  If you default to PTE on (e)LLC and WB on
>> >> L3, userspace will no longer be able to use any newly introduced entry
>> >> with stricter coherency guarantees than that (e.g. any L3-uncached
>> >> entry) in a backwards-compatible way.  Attempting to do so may break
>> >> memory coherency assumptions of the application and lead to misrendering
>> >> when run on older kernel versions (which to my judgment is a scarier
>> >> failure mode than reduced performance).
>> >
>> > You can't use a weaker coherency model in mocs than that specified for
>> > the object as you can't control other uses of the object (even just
>> > memory pressure will break your assumptions).
>> 
>> Exactly, but you can use a stronger coherency model than the application
>> requested, which is why falling back to UC should generally work for
>> unknown entries but falling back to PTE+WB isn't guaranteed to.
>
> Still wrong. GEM will write into the CPU cache believing the object is
> coherent. The GPU will read from memory bypassing the CPU cache
> following the UC mocs.

I agree that this is a plausible scenario.

> The only safe option is for it to follow PTE.

Except you don't know whether the client reading or writing at the other
end is the CPU, or whether the client at the other end is (set up to be)
LLC-coherent.  There's likely no 100% safe option on the LLC side of
things.

I could probably be convinced that in a number of scenarios PTE on LLC
has somewhat better chances of success, but on the L3 side of things
this patch enables WB which is AFAIA strictly more weakly coherent than
UC, so it still gets my NAK.

> -Chris



signature.asc
Description: PGP signature
___
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: reintroduce VLV/CHV PFI programming power domain workaround

[Patchwork]

== Series Details ==

Series: drm/i915: reintroduce VLV/CHV PFI programming power domain workaround
URL   : https://patchwork.freedesktop.org/series/26509/
State : success

== Summary ==

Series 26509v1 drm/i915: reintroduce VLV/CHV PFI programming power domain 
workaround
https://patchwork.freedesktop.org/api/1.0/series/26509/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-byt-j1900) fdo#101517 +3

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
fdo#101517 https://bugs.freedesktop.org/show_bug.cgi?id=101517

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:446s
fi-bdw-gvtdvmtotal:279  pass:257  dwarn:8   dfail:0   fail:0   skip:14  
time:433s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:388s
fi-bsw-n3050 total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  
time:541s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:514s
fi-byt-j1900 total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  
time:492s
fi-byt-n2820 total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:484s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:600s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:437s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:411s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:425s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:496s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:477s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:467s
fi-kbl-7560u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:569s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:583s
fi-pnv-d510  total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  
time:564s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:465s
fi-skl-6700hqtotal:279  pass:223  dwarn:1   dfail:0   fail:30  skip:24  
time:337s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:473s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:475s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:437s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:554s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:402s

85a692e2c6a7cf93082044d776e838cb9e9b2146 drm-tip: 2017y-06m-28d-14h-24m-59s UTC 
integration manifest
6eb533a drm/i915: reintroduce VLV/CHV PFI programming power domain workaround

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5063/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Skip i915_swizzle_info in platforms without GPU side swizzle

[Michel Thierry]

There's no need to keep reading random registers in i915_swizzle_info if
the platform is not doing GPU side swizzling.

After HSW, swizzling is not used, and the CPU's memory controller
performs all the address swizzling modifications, commit be292e1563ac5b
("drm/i915/bdw: Let the memory controller do all the swizzling").

Cc: Daniele Ceraolo Spurio 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 87e13131f6ea..e82f503389fb 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2152,6 +2152,11 @@ static int i915_swizzle_info(struct seq_file *m, void 
*data)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
 
+   if (INTEL_GEN(dev_priv) >= 8 || IS_VALLEYVIEW(dev_priv)) {
+   seq_puts(m, "not supported - CPU does all the swizzling\n");
+   return 0;
+   }
+
intel_runtime_pm_get(dev_priv);
 
seq_printf(m, "bit6 swizzle for X-tiling = %s\n",
-- 
2.11.0

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Skip i915_swizzle_info in platforms without GPU side swizzle

[Patchwork]

== Series Details ==

Series: drm/i915: Skip i915_swizzle_info in platforms without GPU side swizzle
URL   : https://patchwork.freedesktop.org/series/26517/
State : success

== Summary ==

Series 26517v1 drm/i915: Skip i915_swizzle_info in platforms without GPU side 
swizzle
https://patchwork.freedesktop.org/api/1.0/series/26517/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-pnv-d510) fdo#101597

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597

fi-bdw-5557u total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  
time:453s
fi-bdw-gvtdvmtotal:279  pass:257  dwarn:8   dfail:0   fail:0   skip:14  
time:424s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:350s
fi-bsw-n3050 total:279  pass:242  dwarn:1   dfail:0   fail:0   skip:36  
time:531s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:505s
fi-byt-j1900 total:279  pass:253  dwarn:2   dfail:0   fail:0   skip:24  
time:484s
fi-byt-n2820 total:279  pass:249  dwarn:2   dfail:0   fail:0   skip:28  
time:483s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:593s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:436s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:414s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:423s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:492s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:475s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:465s
fi-kbl-7560u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:570s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:585s
fi-pnv-d510  total:279  pass:222  dwarn:2   dfail:0   fail:0   skip:55  
time:556s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:453s
fi-skl-6700hqtotal:279  pass:223  dwarn:1   dfail:0   fail:30  skip:24  
time:339s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:464s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:478s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:435s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:542s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:403s

85a692e2c6a7cf93082044d776e838cb9e9b2146 drm-tip: 2017y-06m-28d-14h-24m-59s UTC 
integration manifest
77e2a75 drm/i915: Skip i915_swizzle_info in platforms without GPU side swizzle

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5064/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts

[Manasi Navare]

This patch fixes the DP AUX CH timeouts observed during CI IGT
tests thus fixing the CI failures. This is done by adding a
quirk for a particular PCI device that requires the panel power
cycle delay (T12) to be 300msecs more than the minimum value
specified in the eDP spec. So a quirk is implemented for that
specific PCI device.

v2:
* Change the function and variable names to from PPS_T12_
to _T12 since it is a T12 delay (Clint)

Fixes: FDO #101144 #101515 #101154 #101167
Cc: Ville Syrjala 
Cc: Cinton Taylor 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_display.c | 12 
 drivers/gpu/drm/i915/intel_dp.c  | 12 
 3 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 427d10c..4327c8a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1168,6 +1168,7 @@ enum intel_sbi_destination {
 #define QUIRK_INVERT_BRIGHTNESS (1<<2)
 #define QUIRK_BACKLIGHT_PRESENT (1<<3)
 #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
+#define QUIRK_INCREASE_T12_DELAY (1<<6)
 
 struct intel_fbdev;
 struct intel_fbc_work;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 4e03ca6..37beb62 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14765,6 +14765,15 @@ static void quirk_backlight_present(struct drm_device 
*dev)
DRM_INFO("applying backlight present quirk\n");
 }
 
+/* Some systems require 300ms extra PPS T12 delay to be added to VBT value */
+static void quirk_increase_t12_delay(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   dev_priv->quirks |= QUIRK_INCREASE_T12_DELAY;
+   DRM_INFO("Applying T12 delay quirk\n");
+}
+
 struct intel_quirk {
int device;
int subsystem_vendor;
@@ -14848,6 +14857,9 @@ static struct intel_quirk intel_quirks[] = {
 
/* Dell Chromebook 11 (2015 version) */
{ 0x0a16, 0x1028, 0x0a35, quirk_backlight_present },
+
+   /* Toshiba Satellite P50-C-18C */
+   { 0x191B, 0x1179, 0xF840, quirk_increase_t12_delay },
 };
 
 static void intel_init_quirks(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 67bc8a7a..db6953e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -49,6 +49,9 @@
 #define INTEL_DP_RESOLUTION_STANDARD   (2 << INTEL_DP_RESOLUTION_SHIFT_MASK)
 #define INTEL_DP_RESOLUTION_FAILSAFE   (3 << INTEL_DP_RESOLUTION_SHIFT_MASK)
 
+/* PPS T12 Delay Quirk value for eDP */
+#define T11_T12_800MS  8000
+
 struct dp_link_dpll {
int clock;
struct dpll dpll;
@@ -5230,6 +5233,15 @@ intel_dp_init_panel_power_sequencer(struct drm_device 
*dev,
intel_pps_dump_state("cur", &cur);
 
vbt = dev_priv->vbt.edp.pps;
+   /* Apply the QUIRK_INCREASE_T12_DELAY quirk for a specific
+* type of PCI device to avoid  DP AUX CH Timeouts.
+*/
+   if (dev_priv->quirks & QUIRK_INCREASE_T12_DELAY) {
+
+   vbt.t11_t12 = max_t(u16, vbt.t11_t12, T11_T12_800MS);
+   DRM_DEBUG_KMS("Increasing T12 panel delay as per the quirk to 
%d\n",
+ vbt.t11_t12);
+   }
/* T11_T12 delay is special and actually in units of 100ms, but zero
 * based in the hw (so we need to add 100 ms). But the sw vbt
 * table multiplies it with 1000 to make it in units of 100usec,
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH v2] drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts

[Clint Taylor]

Looks Good.
Reviewed-by: Clinton Taylor 

-Clint


On 06/28/2017 05:14 PM, Manasi Navare wrote:

This patch fixes the DP AUX CH timeouts observed during CI IGT
tests thus fixing the CI failures. This is done by adding a
quirk for a particular PCI device that requires the panel power
cycle delay (T12) to be 300msecs more than the minimum value
specified in the eDP spec. So a quirk is implemented for that
specific PCI device.

v2:
* Change the function and variable names to from PPS_T12_
to _T12 since it is a T12 delay (Clint)

Fixes: FDO #101144 #101515 #101154 #101167
Cc: Ville Syrjala 
Cc: Cinton Taylor 
Signed-off-by: Manasi Navare 
---
  drivers/gpu/drm/i915/i915_drv.h  |  1 +
  drivers/gpu/drm/i915/intel_display.c | 12 
  drivers/gpu/drm/i915/intel_dp.c  | 12 
  3 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 427d10c..4327c8a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1168,6 +1168,7 @@ enum intel_sbi_destination {
  #define QUIRK_INVERT_BRIGHTNESS (1<<2)
  #define QUIRK_BACKLIGHT_PRESENT (1<<3)
  #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
+#define QUIRK_INCREASE_T12_DELAY (1<<6)
  
  struct intel_fbdev;

  struct intel_fbc_work;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 4e03ca6..37beb62 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14765,6 +14765,15 @@ static void quirk_backlight_present(struct drm_device 
*dev)
DRM_INFO("applying backlight present quirk\n");
  }
  
+/* Some systems require 300ms extra PPS T12 delay to be added to VBT value */

+static void quirk_increase_t12_delay(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   dev_priv->quirks |= QUIRK_INCREASE_T12_DELAY;
+   DRM_INFO("Applying T12 delay quirk\n");
+}
+
  struct intel_quirk {
int device;
int subsystem_vendor;
@@ -14848,6 +14857,9 @@ static struct intel_quirk intel_quirks[] = {
  
  	/* Dell Chromebook 11 (2015 version) */

{ 0x0a16, 0x1028, 0x0a35, quirk_backlight_present },
+
+   /* Toshiba Satellite P50-C-18C */
+   { 0x191B, 0x1179, 0xF840, quirk_increase_t12_delay },
  };
  
  static void intel_init_quirks(struct drm_device *dev)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 67bc8a7a..db6953e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -49,6 +49,9 @@
  #define INTEL_DP_RESOLUTION_STANDARD  (2 << INTEL_DP_RESOLUTION_SHIFT_MASK)
  #define INTEL_DP_RESOLUTION_FAILSAFE  (3 << INTEL_DP_RESOLUTION_SHIFT_MASK)
  
+/* PPS T12 Delay Quirk value for eDP */

+#define T11_T12_800MS  8000
+
  struct dp_link_dpll {
int clock;
struct dpll dpll;
@@ -5230,6 +5233,15 @@ intel_dp_init_panel_power_sequencer(struct drm_device 
*dev,
intel_pps_dump_state("cur", &cur);
  
  	vbt = dev_priv->vbt.edp.pps;

+   /* Apply the QUIRK_INCREASE_T12_DELAY quirk for a specific
+* type of PCI device to avoid  DP AUX CH Timeouts.
+*/
+   if (dev_priv->quirks & QUIRK_INCREASE_T12_DELAY) {
+
+   vbt.t11_t12 = max_t(u16, vbt.t11_t12, T11_T12_800MS);
+   DRM_DEBUG_KMS("Increasing T12 panel delay as per the quirk to 
%d\n",
+ vbt.t11_t12);
+   }
/* T11_T12 delay is special and actually in units of 100ms, but zero
 * based in the hw (so we need to add 100 ms). But the sw vbt
 * table multiplies it with 1000 to make it in units of 100usec,


___
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/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts

[Patchwork]

== Series Details ==

Series: drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts
URL   : https://patchwork.freedesktop.org/series/26518/
State : success

== Summary ==

Series 26518v1 drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH 
timeouts
https://patchwork.freedesktop.org/api/1.0/series/26518/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
Test kms_busy:
Subgroup basic-flip-default-a:
dmesg-warn -> PASS   (fi-skl-6700hq) fdo#101144 +3
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
fail   -> PASS   (fi-skl-6700hq) fdo#101154 +24
Test kms_flip:
Subgroup basic-flip-vs-modeset:
skip   -> PASS   (fi-skl-6700hq)
Subgroup basic-flip-vs-wf_vblank:
skip   -> PASS   (fi-skl-6700hq)
Subgroup basic-plain-flip:
skip   -> PASS   (fi-skl-6700hq)
Test kms_frontbuffer_tracking:
Subgroup basic:
skip   -> PASS   (fi-skl-6700hq)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-pnv-d510) fdo#101597
Subgroup suspend-read-crc-pipe-b:
fail   -> PASS   (fi-skl-6700hq) fdo#100461 +1
Test kms_setmode:
Subgroup basic-clone-single-crtc:
warn   -> PASS   (fi-skl-6700hq) fdo#101518
Test kms_sink_crc_basic:
fail   -> PASS   (fi-skl-6700hq) fdo#101519
Test pm_rpm:
Subgroup basic-pci-d3-state:
skip   -> PASS   (fi-skl-6700hq)
Subgroup basic-rte:
skip   -> PASS   (fi-skl-6700hq)

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144
fdo#101154 https://bugs.freedesktop.org/show_bug.cgi?id=101154
fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597
fdo#100461 https://bugs.freedesktop.org/show_bug.cgi?id=100461
fdo#101518 https://bugs.freedesktop.org/show_bug.cgi?id=101518
fdo#101519 https://bugs.freedesktop.org/show_bug.cgi?id=101519

fi-bdw-gvtdvmtotal:279  pass:257  dwarn:8   dfail:0   fail:0   skip:14  
time:427s
fi-blb-e6850 total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  
time:353s
fi-bsw-n3050 total:279  pass:242  dwarn:1   dfail:0   fail:0   skip:36  
time:529s
fi-bxt-j4205 total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:515s
fi-byt-j1900 total:279  pass:253  dwarn:2   dfail:0   fail:0   skip:24  
time:488s
fi-byt-n2820 total:279  pass:249  dwarn:2   dfail:0   fail:0   skip:28  
time:487s
fi-glk-2atotal:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  
time:598s
fi-hsw-4770  total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:432s
fi-hsw-4770r total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  
time:410s
fi-ilk-650   total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  
time:421s
fi-ivb-3520m total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:499s
fi-ivb-3770  total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:472s
fi-kbl-7500u total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  
time:465s
fi-kbl-7560u total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  
time:573s
fi-kbl-r total:279  pass:260  dwarn:1   dfail:0   fail:0   skip:18  
time:576s
fi-pnv-d510  total:279  pass:222  dwarn:2   dfail:0   fail:0   skip:55  
time:549s
fi-skl-6260u total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:456s
fi-skl-6700hqtotal:279  pass:262  dwarn:0   dfail:0   fail:0   skip:17  
time:609s
fi-skl-6700k total:279  pass:257  dwarn:4   dfail:0   fail:0   skip:18  
time:468s
fi-skl-6770hqtotal:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  
time:481s
fi-skl-gvtdvmtotal:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  
time:431s
fi-snb-2520m total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  
time:545s
fi-snb-2600  total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  
time:409s
fi-bdw-5557u failed to collect. IGT log at Patchwork_5065/fi-bdw-5557u/igt.log

85a692e2c6a7cf93082044d776e838cb9e9b2146 drm-tip: 2017y-06m-28d-14h-24m-59s UTC 
integration manifest
b9c2fef drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5065/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RESEND i-g-t 1/3] lib/cfl: Add Coffeelake PCI IDs for S SKU.

[Anusha Srivatsa]

Just following the spec and adding these extra IDs.

v2: update IDs following the kernel commit:
b056f8f3d6b900e8afd19f312719160346d263b4 (Chris)

Cc: Rodrigo Vivi 
Signed-off-by: Anusha Srivatsa 
Reviewed-by: Clint Taylor 
---
 lib/i915_pciids.h   | 10 ++
 lib/intel_device_info.c |  2 ++
 2 files changed, 12 insertions(+)

diff --git a/lib/i915_pciids.h b/lib/i915_pciids.h
index 27e0dba..02f43d9 100644
--- a/lib/i915_pciids.h
+++ b/lib/i915_pciids.h
@@ -334,4 +334,14 @@
INTEL_KBL_GT3_IDS(info), \
INTEL_KBL_GT4_IDS(info)
 
+#define INTEL_CFL_S_IDS(info) \
+   INTEL_VGA_DEVICE(0x3E90, info), /* SRV GT1 */ \
+   INTEL_VGA_DEVICE(0x3E93, info), /* SRV GT1 */ \
+   INTEL_VGA_DEVICE(0x3E91, info), /* SRV GT2 */ \
+   INTEL_VGA_DEVICE(0x3E92, info), /* SRV GT2 */ \
+   INTEL_VGA_DEVICE(0x3E96, info) /* SRV GT2 */
+
+#define INTEL_CFL_IDS(info) \
+   INTEL_CFL_S_IDS(info)
+
 #endif /* _I915_PCIIDS_H */
diff --git a/lib/intel_device_info.c b/lib/intel_device_info.c
index 199fa2d..2c46aba 100644
--- a/lib/intel_device_info.c
+++ b/lib/intel_device_info.c
@@ -241,6 +241,8 @@ static const struct pci_id_match intel_device_match[] = {
 
INTEL_GLK_IDS(&intel_geminilake_info),
 
+   INTEL_CFL_IDS(&intel_coffeelake_info),
+
INTEL_VGA_DEVICE(PCI_MATCH_ANY, &intel_generic_info),
 };
 
-- 
2.7.4

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

[Intel-gfx] [RESEND i-g-t 2/3] lib/cfl: Add PCI IDs to H SKU in CFl

[Anusha Srivatsa]

Follow the spec and add the ID for H SKU in
CFL.

v2: Update IDs following kernel commit:
ccfd13215fd25a0e8c28221f3acc0dcaec11cd15 (Chris)

Cc: Rodrigo Vivi 
Signed-off-by: Anusha Srivatsa 
Reviewed-by: Clint Taylor 
---
 lib/i915_pciids.h | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/lib/i915_pciids.h b/lib/i915_pciids.h
index 02f43d9..c319e37 100644
--- a/lib/i915_pciids.h
+++ b/lib/i915_pciids.h
@@ -341,7 +341,13 @@
INTEL_VGA_DEVICE(0x3E92, info), /* SRV GT2 */ \
INTEL_VGA_DEVICE(0x3E96, info) /* SRV GT2 */
 
+
+#define INTEL_CFL_H_IDS(info) \
+   INTEL_VGA_DEVICE(0x3E9B, info), /* Halo GT2 */ \
+   INTEL_VGA_DEVICE(0x3E94, info) /* Halo GT2 */
+
 #define INTEL_CFL_IDS(info) \
-   INTEL_CFL_S_IDS(info)
+   INTEL_CFL_S_IDS(info), \
+   INTEL_CFL_H_IDS(info)
 
 #endif /* _I915_PCIIDS_H */
-- 
2.7.4

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

[Intel-gfx] [RESEND i-g-t 3/3] lib/cfl: Add PCI Ids for U SKU in CFl

[Anusha Srivatsa]

Follow the spec and add ID for U SKU

v2: Update IDs in accordance to the kernel commit:
d29fe702c9cb682df99146d24d06e5455f043101 (Chris)

Cc: Rodrigo Vivi 
Signed-off-by: Anusha Srivatsa 
Reviewed-by: Clint Taylor 
---
 lib/i915_pciids.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/lib/i915_pciids.h b/lib/i915_pciids.h
index c319e37..71cce60 100644
--- a/lib/i915_pciids.h
+++ b/lib/i915_pciids.h
@@ -346,8 +346,15 @@
INTEL_VGA_DEVICE(0x3E9B, info), /* Halo GT2 */ \
INTEL_VGA_DEVICE(0x3E94, info) /* Halo GT2 */
 
+#define INTEL_CFL_U_IDS(info) \
+   INTEL_VGA_DEVICE(0x3EA5, info), /* ULT GT3 */ \
+   INTEL_VGA_DEVICE(0x3EA6, info), /* ULT GT3 */ \
+   INTEL_VGA_DEVICE(0x3EA7, info), /* ULT GT3 */ \
+   INTEL_VGA_DEVICE(0x3EA8, info) /* ULT GT3 */
+
 #define INTEL_CFL_IDS(info) \
INTEL_CFL_S_IDS(info), \
-   INTEL_CFL_H_IDS(info)
+   INTEL_CFL_H_IDS(info), \
+   INTEL_CFL_U_IDS(info)
 
 #endif /* _I915_PCIIDS_H */
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 05/20] drm/i915: introduce page_size members

[Zhenyu Wang]

On 2017.06.27 15:54:29 +0100, Matthew Auld wrote:
> In preparation for supporting huge gtt pages for the ppgtt, we introduce
> page size members for gem objects.  We fill in the page sizes by
> scanning the sg table.
> 
> v2: pass the sg_mask to set_pages
> 
> v3: calculate the sg_mask inline with populating the sg_table where
> possible, and pass to set_pages along with the pages.
> 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  5 ++-
>  drivers/gpu/drm/i915/i915_gem.c  | 43 
> 
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c   | 17 --
>  drivers/gpu/drm/i915/i915_gem_internal.c |  5 ++-
>  drivers/gpu/drm/i915/i915_gem_object.h   | 20 ++-
>  drivers/gpu/drm/i915/i915_gem_stolen.c   | 13 ---
>  drivers/gpu/drm/i915/i915_gem_userptr.c  | 26 ++
>  drivers/gpu/drm/i915/selftests/huge_gem_object.c |  4 ++-
>  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c|  3 +-
>  9 files changed, 110 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index fe225cb9b622..0539f210622f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2951,6 +2951,8 @@ intel_info(const struct drm_i915_private *dev_priv)
>  #define USES_PPGTT(dev_priv) (i915.enable_ppgtt)
>  #define USES_FULL_PPGTT(dev_priv)(i915.enable_ppgtt >= 2)
>  #define USES_FULL_48BIT_PPGTT(dev_priv)  (i915.enable_ppgtt == 3)
> +#define HAS_PAGE_SIZE(dev_priv, page_size) \
> + ((dev_priv)->info.page_size_mask & (page_size))
>  
>  #define HAS_OVERLAY(dev_priv) ((dev_priv)->info.has_overlay)
>  #define OVERLAY_NEEDS_PHYSICAL(dev_priv) \
> @@ -3335,7 +3337,8 @@ i915_gem_object_get_dma_address(struct 
> drm_i915_gem_object *obj,
>   unsigned long n);
>  
>  void __i915_gem_object_set_pages(struct drm_i915_gem_object *obj,
> -  struct sg_table *pages);
> +  struct sg_table *pages,
> +  unsigned int sg_mask);
>  int __i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
>  
>  static inline int __must_check
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 80539a821004..4d29a5cfa0c4 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -163,7 +163,8 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev, void 
> *data,
>  }
>  
>  static struct sg_table *
> -i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj)
> +i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj,
> +unsigned int *sg_mask)
>  {
>   struct address_space *mapping = obj->base.filp->f_mapping;
>   drm_dma_handle_t *phys;
> @@ -223,6 +224,8 @@ i915_gem_object_get_pages_phys(struct drm_i915_gem_object 
> *obj)
>   sg->offset = 0;
>   sg->length = obj->base.size;
>  
> + *sg_mask = sg->length;
> +
>   sg_dma_address(sg) = phys->busaddr;
>   sg_dma_len(sg) = obj->base.size;
>  
> @@ -2314,6 +2317,8 @@ void __i915_gem_object_put_pages(struct 
> drm_i915_gem_object *obj,
>   if (!IS_ERR(pages))
>   obj->ops->put_pages(obj, pages);
>  
> + obj->mm.page_sizes.phys = obj->mm.page_sizes.sg = 0;
> +
>  unlock:
>   mutex_unlock(&obj->mm.lock);
>  }
> @@ -2345,7 +2350,8 @@ static bool i915_sg_trim(struct sg_table *orig_st)
>  }
>  
>  static struct sg_table *
> -i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj)
> +i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj,
> +   unsigned int *sg_mask)
>  {
>   struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
>   const unsigned long page_count = obj->base.size / PAGE_SIZE;
> @@ -2392,6 +2398,7 @@ i915_gem_object_get_pages_gtt(struct 
> drm_i915_gem_object *obj)
>  
>   sg = st->sgl;
>   st->nents = 0;
> + *sg_mask = 0;
>   for (i = 0; i < page_count; i++) {
>   const unsigned int shrink[] = {
>   I915_SHRINK_BOUND | I915_SHRINK_UNBOUND | 
> I915_SHRINK_PURGEABLE,
> @@ -2443,8 +2450,10 @@ i915_gem_object_get_pages_gtt(struct 
> drm_i915_gem_object *obj)
>   if (!i ||
>   sg->length >= max_segment ||
>   page_to_pfn(page) != last_pfn + 1) {
> - if (i)
> + if (i) {
> + *sg_mask |= sg->length;
>   sg = sg_next(sg);
> + }
>   st->nents++;
>   sg_set_page(sg, page, PAGE_SIZE, 0);
>   } else {
> @@ -2455,8 +2464,10 @@ i915_gem_object_get_pages_gtt(struct 
> drm_i915_gem_object *obj)
>   /* Check that the i965g

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

[Gerd Hoffmann]

  Hi,

> > Does gvt track the live cycle of all dma-bufs it has handed out?
> 
> The V9 implementation does track the dma-bufs' live cycle. The
> original idea was that leaving the dma-bufs' live cycle management to
> user mode.

That is still the case, user space decides which dma-bufs it'll go keep
cached.  But kernel space can see what user space is doing, so there is
no need to explicitly tell the kernel whenever a cached dma-buf exists
or not.

cheers,
  Gerd

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

[Intel-gfx] [GIT PULL] GVT-g fixes for drm-intel-next-fixes

[Zhenyu Wang]

Hi, this is current gvt fixes after 4.13 stuff got pulled in
drm-intel-next. Mostly two race fixes and several virtual display
fixes on BDW.

Thanks.
--
The following changes since commit e274086e473c0cbea18051ae0a78a05f8d658f47:

  drm/i915/gvt: clean up unsubmited workloads before destroying kmem cache 
(2017-05-24 10:33:37 +0800)

are available in the git repository at:

  https://github.com/01org/gvt-linux.git tags/gvt-fixes-2017-06-29

for you to fetch changes up to 5cd82b757795228516bf60a0552d1a40fa8adeb2:

  drm/i915/gvt: Make function dpy_reg_mmio_readx safe (2017-06-29 11:15:11 
+0800)


gvt-fixes-2017-06-29

- two race fixes for VFIO locks from Chuanxiao
- virtual display fix for BDW from Xiong


Changbin Du (1):
  drm/i915/gvt: Make function dpy_reg_mmio_readx safe

Chuanxiao Dong (2):
  drm/i915/gvt: Fix possible recursive locking issue
  drm/i915/gvt: Fix inconsistent locks holding sequence

Xiong Zhang (2):
  drm/i915/gvt: Set initial PORT_CLK_SEL vreg for BDW
  drm/i915/gvt: Don't read ADPA_CRT_HOTPLUG_MONITOR from host

 drivers/gpu/drm/i915/gvt/display.c  | 22 
 drivers/gpu/drm/i915/gvt/gvt.h  |  3 ++
 drivers/gpu/drm/i915/gvt/handlers.c | 37 +++-
 drivers/gpu/drm/i915/gvt/kvmgt.c| 69 +
 4 files changed, 99 insertions(+), 32 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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