[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/cnl: Get RC6 working. (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Get RC6 working. (rev2)
URL   : https://patchwork.freedesktop.org/series/32491/
State : success

== Summary ==

Test drv_module_reload:
Subgroup basic-reload-inject:
dmesg-warn -> PASS   (shard-hsw) fdo#102707 +1
Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_busy:
Subgroup extended-modeset-hang-oldfb-with-reset-render-A:
dmesg-warn -> PASS   (shard-hsw) fdo#102249

fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249

shard-hswtotal:2540 pass:1433 dwarn:2   dfail:0   fail:8   skip:1097 
time:9225s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6151/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: Get RC6 working. (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Get RC6 working. (rev2)
URL   : https://patchwork.freedesktop.org/series/32491/
State : success

== Summary ==

Series 32491v2 drm/i915/cnl: Get RC6 working.
https://patchwork.freedesktop.org/api/1.0/series/32491/revisions/2/mbox/

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:441s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:450s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:371s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:522s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:266s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:502s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:506s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:493s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:480s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:559s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:412s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:248s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:575s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:451s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:433s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:431s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:493s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:455s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:494s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:571s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:579s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:552s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:461s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:637s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:517s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:503s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:455s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:565s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:416s

5c82a37eff83ab4e60e760fbaf03db5ba0563497 drm-tip: 2017y-10m-23d-18h-06m-28s UTC 
integration manifest
f4e4165a1218 drm/i915/cnl: Get RC6 working.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6151/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Mesa-dev] [PATCH] i965: Revert absolute mode for constant buffer pointers.

[Kenneth Graunke]

On Monday, October 23, 2017 3:53:15 PM PDT Rodrigo Vivi wrote:
> On Mon, Oct 23, 2017 at 10:32:43PM +, Jordan Justen wrote:
> > On 2017-10-19 16:30:44, Kristian Høgsberg wrote:
> > > On Thu, Oct 19, 2017 at 4:18 PM, Kenneth Graunke  
> > > wrote:
> > > > The kernel doesn't initialize the value of the INSTPM or CS_DEBUG_MODE2
> > > > registers at context initialization time.  Instead, they're inherited
> > > > from whatever happened to be running on the GPU prior to first run of a
> > > > new context.  So, when we started setting these, other contexts in the
> > > > system started inheriting our values.  Since this controls whether
> > > > 3DSTATE_CONSTANT_* takes a pointer or an offset, getting the wrong
> > > > setting is fatal for almost any process which isn't expecting this.
> > > >
> > > > Unfortunately, VA-API and Beignet don't initialize this (nor does older
> > > > Mesa), so they will die horribly if we start doing this.  UXA and SNA
> > > > don't use any push constants, so they are unaffected.
> > > >
> > > > The kernel developers are apparently uninterested in making the proto-
> > > > context initialize these registers to guarantee deterministic behavior.
> > > 
> > > Could somebody from the kernel team elaborate here? This is obviously
> > > broken and undermines the security and containerization that hw
> > > contexts are supposed to provide. I'm really curious what the thinking
> > > is here...
> > > 
> > > Kristian
> > 
> > Cc intel-gfx, maintainers
> 
> Is this the null-state/golden-context related discussions?
> 
> I assume we are ok for older platforms, but the problem would be only for
> CNL+ where we are not adding the null context initialization yet.
> Am I getting it right?

No, this problem exists on earlier platforms as well.  We saw the issue
on Broadwell and Kabylake.


signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/4] drm/i915: Bump wait-times for the final CS interrupt before parking

[Patchwork]

== Series Details ==

Series: series starting with [1/4] drm/i915: Bump wait-times for the final CS 
interrupt before parking
URL   : https://patchwork.freedesktop.org/series/32493/
State : success

== Summary ==

Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252
Test drv_module_reload:
Subgroup basic-reload-inject:
dmesg-warn -> PASS   (shard-hsw) fdo#102707
Test kms_busy:
Subgroup extended-modeset-hang-oldfb-with-reset-render-A:
dmesg-warn -> PASS   (shard-hsw) fdo#102249 +1

fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249

shard-hswtotal:2540 pass:1433 dwarn:2   dfail:0   fail:8   skip:1097 
time:9202s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6149/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 12/14] drm/i915/guc: Preemption! With GuC

[Daniele Ceraolo Spurio]

+
+#define GUC_PREEMPT_FINISHED 0x1
+#define GUC_PREEMPT_BREADCRUMB_DWORDS 0x8
+static void inject_preempt_context(struct work_struct *work)
+{
+   struct guc_preempt_work *preempt_work =
+   container_of(work, typeof(*preempt_work), work);
+   struct intel_engine_cs *engine = preempt_work->engine;
+   struct intel_guc *guc = >i915->guc;
+   struct i915_guc_client *client = guc->client[PREEMPT];
+   struct intel_ring *ring = client->owner->engine[engine->id].ring;
+   u32 ctx_desc = lower_32_bits(intel_lr_context_descriptor(client->owner,
+engine));
+   u32 *cs = ring->vaddr + ring->tail;
+   u32 data[7];
+
+   if (engine->id == RCS) {
+   cs = gen8_emit_ggtt_write_rcs(cs, GUC_PREEMPT_FINISHED,
+   intel_hws_preempt_done_address(engine));
+   } else {
+   cs = gen8_emit_ggtt_write(cs, GUC_PREEMPT_FINISHED,
+   intel_hws_preempt_done_address(engine));
+   *cs++ = MI_NOOP;
+   *cs++ = MI_NOOP;
+   }
+   *cs++ = MI_USER_INTERRUPT;
+   *cs++ = MI_NOOP;
+
+   GEM_BUG_ON(!IS_ALIGNED(ring->size,
+  GUC_PREEMPT_BREADCRUMB_DWORDS * sizeof(u32)));
+   GEM_BUG_ON((void*)cs - (ring->vaddr + ring->tail) !=
+  GUC_PREEMPT_BREADCRUMB_DWORDS * sizeof(u32));
+
+   ring->tail += GUC_PREEMPT_BREADCRUMB_DWORDS * sizeof(u32);
+   ring->tail &= (ring->size - 1);
+
+   flush_ggtt_writes(ring->vma);
+
+   spin_lock_irq(>wq_lock);
+   guc_wq_item_append(client, engine->guc_id, ctx_desc,
+  ring->tail / sizeof(u64), 0);
+   spin_unlock_irq(>wq_lock);
+
+   data[0] = INTEL_GUC_ACTION_REQUEST_PREEMPTION;
+   data[1] = client->stage_id;
+   data[2] = INTEL_GUC_PREEMPT_OPTION_IMMEDIATE |


I was looking at how the GuC handles these flags and from what I've seen 
INTEL_GUC_PREEMPT_OPTION_IMMEDIATE doesn't seem to be used anywhere in 
GuC FW anymore (even if it still exist in the interface), so I believe 
it should be safe to drop it.


Daniele


+ INTEL_GUC_PREEMPT_OPTION_DROP_WORK_Q |
+ INTEL_GUC_PREEMPT_OPTION_DROP_SUBMIT_Q;
+   data[3] = engine->guc_id;
+   data[4] = guc->client[SUBMIT]->priority;
+   data[5] = guc->client[SUBMIT]->stage_id;
+   data[6] = guc_ggtt_offset(guc->shared_data);
+
+   if (WARN_ON(intel_guc_send(guc, data, ARRAY_SIZE(data {
+   WRITE_ONCE(engine->execlists.preempt, false);
+   tasklet_schedule(>execlists.irq_tasklet);
+   }
+}

___
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/cnl: Get RC6 working. (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Get RC6 working. (rev2)
URL   : https://patchwork.freedesktop.org/series/32491/
State : failure

== Summary ==

Series 32491v2 drm/i915/cnl: Get RC6 working.
https://patchwork.freedesktop.org/api/1.0/series/32491/revisions/2/mbox/

Test gem_exec_reloc:
Subgroup basic-gtt-cpu-active:
pass   -> FAIL   (fi-gdg-551) fdo#102582 +2
Subgroup basic-write-cpu-active:
pass   -> FAIL   (fi-gdg-551)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> SKIP   (fi-hsw-4770r)
Subgroup suspend-read-crc-pipe-c:
pass   -> INCOMPLETE (fi-skl-6700hq)

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:442s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:451s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:371s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:517s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:263s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:497s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:500s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:495s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:476s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:561s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:418s
fi-gdg-551   total:289  pass:174  dwarn:1   dfail:0   fail:5   skip:109 
time:249s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:580s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:446s
fi-hsw-4770r total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:409s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:429s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:490s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:492s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:569s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:584s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:537s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-skl-6700hqtotal:247  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:517s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:500s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:456s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:561s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:417s

5c82a37eff83ab4e60e760fbaf03db5ba0563497 drm-tip: 2017y-10m-23d-18h-06m-28s UTC 
integration manifest
eca827093a8a drm/i915/cnl: Get RC6 working.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6150/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Mesa-dev] [PATCH] i965: Revert absolute mode for constant buffer pointers.

[Rodrigo Vivi]

On Mon, Oct 23, 2017 at 10:32:43PM +, Jordan Justen wrote:
> On 2017-10-19 16:30:44, Kristian Høgsberg wrote:
> > On Thu, Oct 19, 2017 at 4:18 PM, Kenneth Graunke  
> > wrote:
> > > The kernel doesn't initialize the value of the INSTPM or CS_DEBUG_MODE2
> > > registers at context initialization time.  Instead, they're inherited
> > > from whatever happened to be running on the GPU prior to first run of a
> > > new context.  So, when we started setting these, other contexts in the
> > > system started inheriting our values.  Since this controls whether
> > > 3DSTATE_CONSTANT_* takes a pointer or an offset, getting the wrong
> > > setting is fatal for almost any process which isn't expecting this.
> > >
> > > Unfortunately, VA-API and Beignet don't initialize this (nor does older
> > > Mesa), so they will die horribly if we start doing this.  UXA and SNA
> > > don't use any push constants, so they are unaffected.
> > >
> > > The kernel developers are apparently uninterested in making the proto-
> > > context initialize these registers to guarantee deterministic behavior.
> > 
> > Could somebody from the kernel team elaborate here? This is obviously
> > broken and undermines the security and containerization that hw
> > contexts are supposed to provide. I'm really curious what the thinking
> > is here...
> > 
> > Kristian
> 
> Cc intel-gfx, maintainers

Is this the null-state/golden-context related discussions?

I assume we are ok for older platforms, but the problem would be only for
CNL+ where we are not adding the null context initialization yet.
Am I getting it right?

> 
> > 
> > > Apparently, the "Default Value" of registers in the documentation is a
> > > total lie, and cannot be relied upon by userspace.  So, we need to find
> > > a new solution.  One would be to patch VA-API and Beignet to initialize
> > > these, then get every distributor to ship those in tandem with the newer
> > > Mesa version.  I'm unclear when va-intel-driver releases might happen.
> > > Another option would be to hack Mesa to restore the register back to the
> > > historical default (relative mode) at the end of each batch.  This is
> > > also gross, as it has non-zero cost, and is also relying on userspace to
> > > be "polite" to other broken userspace.  A large part of the motivation
> > > for contexts was to provide proper process isolation, so we should not
> > > have to do this.  But, we're already doing it in some cases, because
> > > our kernel fixes to enforce isolation were reverted.
> > >
> > > In the meantime, I guess we'll just revert this patch and abandon using
> > > the feature.  It will lead to fewer pushed UBOs on Broadwell+, which may
> > > lead to lower performance, but I don't have any data on the impact.
> > >
> > > Cc: "17.2" 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102774
> > > ---
> > >  src/mesa/drivers/dri/i965/brw_state_upload.c | 24 
> > > 
> > >  src/mesa/drivers/dri/i965/intel_screen.c |  2 +-
> > >  2 files changed, 1 insertion(+), 25 deletions(-)
> > >
> > > diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c 
> > > b/src/mesa/drivers/dri/i965/brw_state_upload.c
> > > index 16f44d03bbe..23e4ebda259 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_state_upload.c
> > > +++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
> > > @@ -101,30 +101,6 @@ brw_upload_initial_gpu_state(struct brw_context *brw)
> > >OUT_BATCH(0);
> > >ADVANCE_BATCH();
> > > }
> > > -
> > > -   /* Set the "CONSTANT_BUFFER Address Offset Disable" bit, so
> > > -* 3DSTATE_CONSTANT_XS buffer 0 is an absolute address.
> > > -*
> > > -* On Gen6-7.5, we use an execbuf parameter to do this for us.
> > > -* However, the kernel ignores that when execlists are in use.
> > > -* Fortunately, we can just write the registers from userspace
> > > -* on Gen8+, and they're context saved/restored.
> > > -*/
> > > -   if (devinfo->gen >= 9) {
> > > -  BEGIN_BATCH(3);
> > > -  OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2));
> > > -  OUT_BATCH(CS_DEBUG_MODE2);
> > > -  OUT_BATCH(REG_MASK(CSDBG2_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE) |
> > > -CSDBG2_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE);
> > > -  ADVANCE_BATCH();
> > > -   } else if (devinfo->gen == 8) {
> > > -  BEGIN_BATCH(3);
> > > -  OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2));
> > > -  OUT_BATCH(INSTPM);
> > > -  OUT_BATCH(REG_MASK(INSTPM_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE) |
> > > -INSTPM_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE);
> > > -  ADVANCE_BATCH();
> > > -   }
> > >  }
> > >
> > >  static inline const struct brw_tracked_state *
> > > diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
> > > b/src/mesa/drivers/dri/i965/intel_screen.c
> > > index ea04a72e860..776c2898d5b 100644
> > > --- a/src/mesa/drivers/dri/i965/intel_screen.c
> > > +++ 

[Intel-gfx] [PATCH] drm/i915/cnl: Get RC6 working.

[Rodrigo Vivi]

On CNL, individual wake rate limit was added to each engine.

GT can only go to RC6 if both Render and Media engines are
individually qualified. So we need to set their individual
wake rate limit.

+-+---+--+--+
| |GT RC6 |  Render C6   |   Media C6   |
+-+---+--+--+
| Wake rate limit | 0xA09C[31:16] | 0xA09C[15:0] | 0xA0A0[15:0] |
+-+---+--+--+

v2: - Tune Render and Media wake rate values according to some extra
  info I got from HW engineers. Value can be tuned, but for now
  these are the recommended values.
- Fix typos pointed by James.

Cc: Nathan Ciobanu 
Cc: Wayne Boyer 
Cc: Joe Konno 
Cc: David Weinehall 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: James Ausmus 
---
 drivers/gpu/drm/i915/i915_reg.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c | 15 +++
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 68a58cce6ab1..f138eae82bf0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7905,6 +7905,7 @@ enum {
 #define GEN6_RC1_WAKE_RATE_LIMIT   _MMIO(0xA098)
 #define GEN6_RC6_WAKE_RATE_LIMIT   _MMIO(0xA09C)
 #define GEN6_RC6pp_WAKE_RATE_LIMIT _MMIO(0xA0A0)
+#define GEN10_MEDIA_WAKE_RATE_LIMIT_MMIO(0xA0A0)
 #define GEN6_RC_EVALUATION_INTERVAL_MMIO(0xA0A8)
 #define GEN6_RC_IDLE_HYSTERSIS _MMIO(0xA0AC)
 #define GEN6_RC_SLEEP  _MMIO(0xA0B0)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5fdae39b1969..742d5455b201 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6605,12 +6605,19 @@ static void gen9_enable_rc6(struct drm_i915_private 
*dev_priv)
I915_WRITE(GEN6_RC_CONTROL, 0);
 
/* 2b: Program RC6 thresholds.*/
-
-   /* WaRsDoubleRc6WrlWithCoarsePowerGating: Doubling WRL only when CPG is 
enabled */
-   if (IS_SKYLAKE(dev_priv))
+   if (INTEL_GEN(dev_priv) >= 10) {
+   I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 54 << 16 | 85);
+   I915_WRITE(GEN10_MEDIA_WAKE_RATE_LIMIT, 150);
+   } else if (IS_SKYLAKE(dev_priv)) {
+   /*
+* WaRsDoubleRc6WrlWithCoarsePowerGating:skl Doubling WRL only
+* when CPG is enabled
+*/
I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 108 << 16);
-   else
+   } else {
I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 54 << 16);
+   }
+
I915_WRITE(GEN6_RC_EVALUATION_INTERVAL, 125000); /* 12500 * 1280ns */
I915_WRITE(GEN6_RC_IDLE_HYSTERSIS, 25); /* 25 * 1280ns */
for_each_engine(engine, dev_priv, id)
-- 
2.13.5

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/cnl: Get RC6 working.

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Get RC6 working.
URL   : https://patchwork.freedesktop.org/series/32491/
State : success

== Summary ==

Test drv_module_reload:
Subgroup basic-no-display:
pass   -> DMESG-WARN (shard-hsw) fdo#102707 +1
Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_busy:
Subgroup extended-modeset-hang-oldfb-with-reset-render-A:
dmesg-warn -> PASS   (shard-hsw) fdo#102249

fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249

shard-hswtotal:2540 pass:1433 dwarn:2   dfail:0   fail:8   skip:1097 
time:9206s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6148/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Mesa-dev] [PATCH] i965: Revert absolute mode for constant buffer pointers.

[Jordan Justen]

On 2017-10-19 16:30:44, Kristian Høgsberg wrote:
> On Thu, Oct 19, 2017 at 4:18 PM, Kenneth Graunke  
> wrote:
> > The kernel doesn't initialize the value of the INSTPM or CS_DEBUG_MODE2
> > registers at context initialization time.  Instead, they're inherited
> > from whatever happened to be running on the GPU prior to first run of a
> > new context.  So, when we started setting these, other contexts in the
> > system started inheriting our values.  Since this controls whether
> > 3DSTATE_CONSTANT_* takes a pointer or an offset, getting the wrong
> > setting is fatal for almost any process which isn't expecting this.
> >
> > Unfortunately, VA-API and Beignet don't initialize this (nor does older
> > Mesa), so they will die horribly if we start doing this.  UXA and SNA
> > don't use any push constants, so they are unaffected.
> >
> > The kernel developers are apparently uninterested in making the proto-
> > context initialize these registers to guarantee deterministic behavior.
> 
> Could somebody from the kernel team elaborate here? This is obviously
> broken and undermines the security and containerization that hw
> contexts are supposed to provide. I'm really curious what the thinking
> is here...
> 
> Kristian

Cc intel-gfx, maintainers

> 
> > Apparently, the "Default Value" of registers in the documentation is a
> > total lie, and cannot be relied upon by userspace.  So, we need to find
> > a new solution.  One would be to patch VA-API and Beignet to initialize
> > these, then get every distributor to ship those in tandem with the newer
> > Mesa version.  I'm unclear when va-intel-driver releases might happen.
> > Another option would be to hack Mesa to restore the register back to the
> > historical default (relative mode) at the end of each batch.  This is
> > also gross, as it has non-zero cost, and is also relying on userspace to
> > be "polite" to other broken userspace.  A large part of the motivation
> > for contexts was to provide proper process isolation, so we should not
> > have to do this.  But, we're already doing it in some cases, because
> > our kernel fixes to enforce isolation were reverted.
> >
> > In the meantime, I guess we'll just revert this patch and abandon using
> > the feature.  It will lead to fewer pushed UBOs on Broadwell+, which may
> > lead to lower performance, but I don't have any data on the impact.
> >
> > Cc: "17.2" 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102774
> > ---
> >  src/mesa/drivers/dri/i965/brw_state_upload.c | 24 
> >  src/mesa/drivers/dri/i965/intel_screen.c |  2 +-
> >  2 files changed, 1 insertion(+), 25 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c 
> > b/src/mesa/drivers/dri/i965/brw_state_upload.c
> > index 16f44d03bbe..23e4ebda259 100644
> > --- a/src/mesa/drivers/dri/i965/brw_state_upload.c
> > +++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
> > @@ -101,30 +101,6 @@ brw_upload_initial_gpu_state(struct brw_context *brw)
> >OUT_BATCH(0);
> >ADVANCE_BATCH();
> > }
> > -
> > -   /* Set the "CONSTANT_BUFFER Address Offset Disable" bit, so
> > -* 3DSTATE_CONSTANT_XS buffer 0 is an absolute address.
> > -*
> > -* On Gen6-7.5, we use an execbuf parameter to do this for us.
> > -* However, the kernel ignores that when execlists are in use.
> > -* Fortunately, we can just write the registers from userspace
> > -* on Gen8+, and they're context saved/restored.
> > -*/
> > -   if (devinfo->gen >= 9) {
> > -  BEGIN_BATCH(3);
> > -  OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2));
> > -  OUT_BATCH(CS_DEBUG_MODE2);
> > -  OUT_BATCH(REG_MASK(CSDBG2_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE) |
> > -CSDBG2_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE);
> > -  ADVANCE_BATCH();
> > -   } else if (devinfo->gen == 8) {
> > -  BEGIN_BATCH(3);
> > -  OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2));
> > -  OUT_BATCH(INSTPM);
> > -  OUT_BATCH(REG_MASK(INSTPM_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE) |
> > -INSTPM_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE);
> > -  ADVANCE_BATCH();
> > -   }
> >  }
> >
> >  static inline const struct brw_tracked_state *
> > diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
> > b/src/mesa/drivers/dri/i965/intel_screen.c
> > index ea04a72e860..776c2898d5b 100644
> > --- a/src/mesa/drivers/dri/i965/intel_screen.c
> > +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> > @@ -2510,7 +2510,7 @@ __DRIconfig **intelInitScreen2(__DRIscreen 
> > *dri_screen)
> > screen->compiler = brw_compiler_create(screen, devinfo);
> > screen->compiler->shader_debug_log = shader_debug_log_mesa;
> > screen->compiler->shader_perf_log = shader_perf_log_mesa;
> > -   screen->compiler->constant_buffer_0_is_relative = devinfo->gen < 8;
> > +   screen->compiler->constant_buffer_0_is_relative = true;
> > 

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Get RC6 working.

[James Ausmus]

On Mon, Oct 23, 2017 at 02:20:01PM -0700, Rodrigo Vivi wrote:
> On CNL, individual ware rate limit was added to each engine.
s/ware/wake/

> 
> GT can only go to RC6 if both Render and Media engines are
> idividually qualified. So we need to set their individual
s/idividually/individually/

> wake rate limit.
> 
> +-+---+--+--+
> | |GT RC6 |  Render C6   |   Media C6   |
> +-+---+--+--+
> | Wake rate limit | 0xA09C[31:16] | 0xA09C[15:0] | 0xA0A0[15:0] |
> +-+---+--+--+
> 
> Cc: Nathan Ciobanu 
> Cc: Wayne Boyer 
> Cc: Joe Konno 
> Cc: David Weinehall 
> Signed-off-by: Rodrigo Vivi 

Matches my read of the spec. With the commit message nitpicking fixed :)

Reviewed-by: James Ausmus 

> ---
>  drivers/gpu/drm/i915/i915_reg.h |  1 +
>  drivers/gpu/drm/i915/intel_pm.c | 15 +++
>  2 files changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 68a58cce6ab1..f138eae82bf0 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7905,6 +7905,7 @@ enum {
>  #define GEN6_RC1_WAKE_RATE_LIMIT _MMIO(0xA098)
>  #define GEN6_RC6_WAKE_RATE_LIMIT _MMIO(0xA09C)
>  #define GEN6_RC6pp_WAKE_RATE_LIMIT   _MMIO(0xA0A0)
> +#define GEN10_MEDIA_WAKE_RATE_LIMIT  _MMIO(0xA0A0)
>  #define GEN6_RC_EVALUATION_INTERVAL  _MMIO(0xA0A8)
>  #define GEN6_RC_IDLE_HYSTERSIS   _MMIO(0xA0AC)
>  #define GEN6_RC_SLEEP_MMIO(0xA0B0)
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 5fdae39b1969..b193eda65e81 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6605,12 +6605,19 @@ static void gen9_enable_rc6(struct drm_i915_private 
> *dev_priv)
>   I915_WRITE(GEN6_RC_CONTROL, 0);
>  
>   /* 2b: Program RC6 thresholds.*/
> -
> - /* WaRsDoubleRc6WrlWithCoarsePowerGating: Doubling WRL only when CPG is 
> enabled */
> - if (IS_SKYLAKE(dev_priv))
> + if (INTEL_GEN(dev_priv) >= 10) {
> + I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 54 << 16 | 54);
> + I915_WRITE(GEN10_MEDIA_WAKE_RATE_LIMIT, 54);
> + } else if (IS_SKYLAKE(dev_priv)) {
> + /*
> +  * WaRsDoubleRc6WrlWithCoarsePowerGating:skl Doubling WRL only
> +  * when CPG is enabled
> +  */
>   I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 108 << 16);
> - else
> + } else {
>   I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 54 << 16);
> + }
> +
>   I915_WRITE(GEN6_RC_EVALUATION_INTERVAL, 125000); /* 12500 * 1280ns */
>   I915_WRITE(GEN6_RC_IDLE_HYSTERSIS, 25); /* 25 * 1280ns */
>   for_each_engine(engine, dev_priv, id)
> -- 
> 2.13.5
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Bump wait-times for the final CS interrupt before parking

[Patchwork]

== Series Details ==

Series: series starting with [1/4] drm/i915: Bump wait-times for the final CS 
interrupt before parking
URL   : https://patchwork.freedesktop.org/series/32493/
State : success

== Summary ==

Series 32493v1 series starting with [1/4] drm/i915: Bump wait-times for the 
final CS interrupt before parking
https://patchwork.freedesktop.org/api/1.0/series/32493/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-n2820) fdo#101705
Test drv_module_reload:
Subgroup basic-no-display:
dmesg-warn -> INCOMPLETE (fi-cfl-s) fdo#103206

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:438s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:450s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:373s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:532s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:262s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:503s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:494s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:495s
fi-byt-n2820 total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:487s
fi-cfl-s total:287  pass:253  dwarn:2   dfail:0   fail:0   skip:31 
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:414s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:245s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:579s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:448s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:427s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:432s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:493s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:485s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:572s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:583s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:541s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:448s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:644s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:521s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:499s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:457s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:558s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:414s

5c82a37eff83ab4e60e760fbaf03db5ba0563497 drm-tip: 2017y-10m-23d-18h-06m-28s UTC 
integration manifest
c8aac7abc28d warn
a00f168756fa drm/i915: Filter out spurious execlists context-switch interrupts
0590b88c7a50 drm/i915: Synchronize irq before parking each engine
ae84ddb5f695 drm/i915: Bump wait-times for the final CS interrupt before parking

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6149/
___
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/cnl: Get RC6 working.

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Get RC6 working.
URL   : https://patchwork.freedesktop.org/series/32491/
State : success

== Summary ==

Series 32491v1 drm/i915/cnl: Get RC6 working.
https://patchwork.freedesktop.org/api/1.0/series/32491/revisions/1/mbox/

Test chamelium:
Subgroup dp-hpd-fast:
pass   -> INCOMPLETE (fi-kbl-7500u) fdo#102332
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900) fdo#101705

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:439s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:447s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:371s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:528s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:262s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:494s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:499s
fi-byt-j1900 total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  
time:491s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:472s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:549s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:421s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:248s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:574s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:447s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:429s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:437s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:494s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:462s
fi-kbl-7500u total:70   pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:570s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:478s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:584s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:547s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:467s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:644s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:526s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:505s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:460s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:563s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:419s

5c82a37eff83ab4e60e760fbaf03db5ba0563497 drm-tip: 2017y-10m-23d-18h-06m-28s UTC 
integration manifest
bff589143fc6 drm/i915/cnl: Get RC6 working.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6148/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/4] drm/i915: Bump wait-times for the final CS interrupt before parking

[Chris Wilson]

In the idle worker we drop the prolonged GT wakeref used to cover such
essentials as interrupt delivery. (When a CS interrupt arrives, we also
assert that the GT is awake.) However, it turns out that 10ms is not
long enough to be assured that the last CS interrupt has been delivered,
so bump that to 200ms, and move the entirety of that wait to before we
take the struct_mutex to avoid blocking. As this is now a potentially
long wait, restore the earlier behaviour of bailing out early when a new
request arrives.

v2: Break out the repeated check for new requests into its own little
helper to try and improve the self-commentary.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Mika Kuoppala 
Cc: Imre Deak 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 37 ++---
 1 file changed, 26 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 026cb52ece0b..bb0e85043e01 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3276,13 +3276,20 @@ i915_gem_retire_work_handler(struct work_struct *work)
}
 }
 
+static inline bool
+new_requests_since_last_retire(const struct drm_i915_private *i915)
+{
+   return (READ_ONCE(i915->gt.active_requests) ||
+   work_pending(>gt.idle_work.work));
+}
+
 static void
 i915_gem_idle_work_handler(struct work_struct *work)
 {
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv), gt.idle_work.work);
-   struct drm_device *dev = _priv->drm;
bool rearm_hangcheck;
+   ktime_t end;
 
if (!READ_ONCE(dev_priv->gt.awake))
return;
@@ -3291,14 +3298,21 @@ i915_gem_idle_work_handler(struct work_struct *work)
 * Wait for last execlists context complete, but bail out in case a
 * new request is submitted.
 */
-   wait_for(intel_engines_are_idle(dev_priv), 10);
-   if (READ_ONCE(dev_priv->gt.active_requests))
-   return;
+   end = ktime_add_ms(ktime_get(), 200);
+   do {
+   if (new_requests_since_last_retire(dev_priv))
+   return;
+
+   if (intel_engines_are_idle(dev_priv))
+   break;
+
+   usleep_range(100, 500);
+   } while (ktime_before(ktime_get(), end));
 
rearm_hangcheck =
cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
 
-   if (!mutex_trylock(>struct_mutex)) {
+   if (!mutex_trylock(_priv->drm.struct_mutex)) {
/* Currently busy, come back later */
mod_delayed_work(dev_priv->wq,
 _priv->gt.idle_work,
@@ -3310,13 +3324,14 @@ i915_gem_idle_work_handler(struct work_struct *work)
 * New request retired after this work handler started, extend active
 * period until next instance of the work.
 */
-   if (work_pending(work))
-   goto out_unlock;
-
-   if (dev_priv->gt.active_requests)
+   if (new_requests_since_last_retire(dev_priv))
goto out_unlock;
 
-   if (wait_for(intel_engines_are_idle(dev_priv), 10))
+   /*
+* We are committed now to parking the engines, make sure there
+* will be no more interrupts arriving later.
+*/
+   if (!intel_engines_are_idle(dev_priv))
DRM_ERROR("Timeout waiting for engines to idle\n");
 
intel_engines_mark_idle(dev_priv);
@@ -3330,7 +3345,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
gen6_rps_idle(dev_priv);
intel_runtime_pm_put(dev_priv);
 out_unlock:
-   mutex_unlock(>struct_mutex);
+   mutex_unlock(_priv->drm.struct_mutex);
 
 out_rearm:
if (rearm_hangcheck) {
-- 
2.15.0.rc1

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

[Intel-gfx] [PATCH 3/4] drm/i915: Filter out spurious execlists context-switch interrupts

[Chris Wilson]

Back in commit a4b2b01523a8 ("drm/i915: Don't mark an execlists
context-switch when idle") we noticed the presence of late
context-switch interrupts. We were able to filter those out by looking
at whether the ELSP remained active, but in commit beecec901790
("drm/i915/execlists: Preemption!") that became problematic as we now
anticipate receiving a context-switch event for preemption while ELSP
may be empty. To restore the spurious interrupt suppression, add a
counter for the expected number of pending context-switches and skip if
we do not need to handle this interrupt to make forward progress.

v2: Don't forget to switch on for preempt.
v3: Reduce the counter to a on/off boolean tracker. Declare the HW as
active when we first submit, and idle after the final completion event
(with which we confirm the HW says it is idle), and track each source
of activity separately. With a finite number of sources, it should us
debug which gets stuck.

Fixes: beecec901790 ("drm/i915/execlists: Preemption!")
Signed-off-by: Chris Wilson 
Cc: Michal Winiarski 
Cc: Tvrtko Ursulin 
Cc: Arkadiusz Hiler 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_guc_submission.c |  3 +++
 drivers/gpu/drm/i915/i915_irq.c|  6 --
 drivers/gpu/drm/i915/intel_engine_cs.c |  5 +++--
 drivers/gpu/drm/i915/intel_lrc.c   | 27 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.h| 34 --
 5 files changed, 62 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index a2e8114b739d..f84c267728fd 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -610,6 +610,7 @@ static void i915_guc_dequeue(struct intel_engine_cs *engine)
execlists->first = rb;
if (submit) {
port_assign(port, last);
+   execlists_set_active(execlists, EXECLISTS_ACTIVE_USER);
i915_guc_submit(engine);
}
spin_unlock_irq(>timeline->lock);
@@ -633,6 +634,8 @@ static void i915_guc_irq_handler(unsigned long data)
 
rq = port_request([0]);
}
+   if (!rq)
+   execlists_clear_active(execlists, EXECLISTS_ACTIVE_USER);
 
if (!port_isset(last_port))
i915_guc_dequeue(engine);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b1296a55c1e4..f8205841868b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1388,8 +1388,10 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 
iir, int test_shift)
bool tasklet = false;
 
if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift)) {
-   __set_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
-   tasklet = true;
+   if (READ_ONCE(engine->execlists.active)) {
+   __set_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
+   tasklet = true;
+   }
}
 
if (iir & (GT_RENDER_USER_INTERRUPT << test_shift)) {
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a47a9c6bea52..ab5bf4e2e28e 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1548,8 +1548,8 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
if (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
return false;
 
-   /* Both ports drained, no more ELSP submission? */
-   if (port_request(>execlists.port[0]))
+   /* Waiting to drain ELSP? */
+   if (READ_ONCE(engine->execlists.active))
return false;
 
/* ELSP is empty, but there are ready requests? */
@@ -1749,6 +1749,7 @@ void intel_engine_dump(struct intel_engine_cs *engine, 
struct drm_printer *m)
   idx);
}
}
+   drm_printf(m, "\t\tHW active? 0x%x\n", execlists->active);
rcu_read_unlock();
} else if (INTEL_GEN(dev_priv) > 6) {
drm_printf(m, "\tPP_DIR_BASE: 0x%08x\n",
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 7f45dd7dc3e5..233c992a886b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -575,7 +575,8 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
 * the state of the GPU is known (idle).
 */
inject_preempt_context(engine);
-   execlists->preempt = true;
+   execlists_set_active(execlists,
+EXECLISTS_ACTIVE_PREEMPT);
 

[Intel-gfx] [PATCH 2/4] drm/i915: Synchronize irq before parking each engine

[Chris Wilson]

When we park the engine (upon idling), we kill the irq tasklet. However,
to be sure that it is not restarted by a final interrupt after doing so,
flush the interrupt handler before parking. As we only park the engines
when we believe the system is idle, there should not be any spurious
interrupts later to distrub us; so flushing the final in-flight
interrupt should be sufficient.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Mika Kuoppala 
Cc: Imre Deak 
---
 drivers/gpu/drm/i915/i915_gem.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index bb0e85043e01..b547a6327d34 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3327,6 +3327,12 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (new_requests_since_last_retire(dev_priv))
goto out_unlock;
 
+   /*
+* Be paranoid and flush a concurrent interrupt to make sure
+* we don't reactivate any irq tasklets after parking.
+*/
+   synchronize_irq(dev_priv->drm.irq);
+
/*
 * We are committed now to parking the engines, make sure there
 * will be no more interrupts arriving later.
-- 
2.15.0.rc1

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

[Intel-gfx] [PATCH 4/4] warn

[Chris Wilson]

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

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f8205841868b..e4bd20ce031d 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1391,6 +1391,9 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 
iir, int test_shift)
if (READ_ONCE(engine->execlists.active)) {
__set_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
tasklet = true;
+   } else if (WARN_ON(!engine->i915->gt.awake)) {
+   struct drm_printer p = 
drm_info_printer(engine->i915->drm.dev);
+   intel_engine_dump(engine, );
}
}
 
-- 
2.15.0.rc1

___
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: Synchronize irq before parking each engine

[Patchwork]

== Series Details ==

Series: drm/i915: Synchronize irq before parking each engine
URL   : https://patchwork.freedesktop.org/series/32490/
State : failure

== Summary ==

Series 32490 revision 1 was fully merged or fully failed: no git log

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

[Intel-gfx] [PATCH] drm/i915/cnl: Get RC6 working.

[Rodrigo Vivi]

On CNL, individual ware rate limit was added to each engine.

GT can only go to RC6 if both Render and Media engines are
idividually qualified. So we need to set their individual
wake rate limit.

+-+---+--+--+
| |GT RC6 |  Render C6   |   Media C6   |
+-+---+--+--+
| Wake rate limit | 0xA09C[31:16] | 0xA09C[15:0] | 0xA0A0[15:0] |
+-+---+--+--+

Cc: Nathan Ciobanu 
Cc: Wayne Boyer 
Cc: Joe Konno 
Cc: David Weinehall 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_reg.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c | 15 +++
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 68a58cce6ab1..f138eae82bf0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7905,6 +7905,7 @@ enum {
 #define GEN6_RC1_WAKE_RATE_LIMIT   _MMIO(0xA098)
 #define GEN6_RC6_WAKE_RATE_LIMIT   _MMIO(0xA09C)
 #define GEN6_RC6pp_WAKE_RATE_LIMIT _MMIO(0xA0A0)
+#define GEN10_MEDIA_WAKE_RATE_LIMIT_MMIO(0xA0A0)
 #define GEN6_RC_EVALUATION_INTERVAL_MMIO(0xA0A8)
 #define GEN6_RC_IDLE_HYSTERSIS _MMIO(0xA0AC)
 #define GEN6_RC_SLEEP  _MMIO(0xA0B0)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5fdae39b1969..b193eda65e81 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6605,12 +6605,19 @@ static void gen9_enable_rc6(struct drm_i915_private 
*dev_priv)
I915_WRITE(GEN6_RC_CONTROL, 0);
 
/* 2b: Program RC6 thresholds.*/
-
-   /* WaRsDoubleRc6WrlWithCoarsePowerGating: Doubling WRL only when CPG is 
enabled */
-   if (IS_SKYLAKE(dev_priv))
+   if (INTEL_GEN(dev_priv) >= 10) {
+   I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 54 << 16 | 54);
+   I915_WRITE(GEN10_MEDIA_WAKE_RATE_LIMIT, 54);
+   } else if (IS_SKYLAKE(dev_priv)) {
+   /*
+* WaRsDoubleRc6WrlWithCoarsePowerGating:skl Doubling WRL only
+* when CPG is enabled
+*/
I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 108 << 16);
-   else
+   } else {
I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 54 << 16);
+   }
+
I915_WRITE(GEN6_RC_EVALUATION_INTERVAL, 125000); /* 12500 * 1280ns */
I915_WRITE(GEN6_RC_IDLE_HYSTERSIS, 25); /* 25 * 1280ns */
for_each_engine(engine, dev_priv, id)
-- 
2.13.5

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

[Intel-gfx] [PATCH] drm/i915: Synchronize irq before parking each engine

[Chris Wilson]

When we park the engine (upon idling), we kill the irq tasklet. However,
to be sure that it is not restarted by a final interrupt after doing so,
flush the interrupt handler before parking. As we only park the engines
when we believe the system is idle, there should not be any spurious
interrupts later to distrub us; so flushing the final in-flight
interrupt should be sufficient.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Mika Kuoppala 
Cc: Imre Deak 
---
 drivers/gpu/drm/i915/i915_gem.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index bb0e85043e01..b547a6327d34 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3327,6 +3327,12 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (new_requests_since_last_retire(dev_priv))
goto out_unlock;
 
+   /*
+* Be paranoid and flush a concurrent interrupt to make sure
+* we don't reactivate any irq tasklets after parking.
+*/
+   synchronize_irq(dev_priv->drm.irq);
+
/*
 * We are committed now to parking the engines, make sure there
 * will be no more interrupts arriving later.
-- 
2.15.0.rc1

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Filter out spurious execlists context-switch interrupts

[Chris Wilson]

Quoting Chris Wilson (2017-10-23 21:06:16)
> Back in commit a4b2b01523a8 ("drm/i915: Don't mark an execlists
> context-switch when idle") we noticed the presence of late
> context-switch interrupts. We were able to filter those out by looking
> at whether the ELSP remained active, but in commit beecec901790
> ("drm/i915/execlists: Preemption!") that became problematic as we now
> anticipate receiving a context-switch event for preemption while ELSP
> may be empty. To restore the spurious interrupt suppression, add a
> counter for the expected number of pending context-switches and skip if
> we do not need to handle this interrupt to make forward progress.

Looking at an example from
https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_1299/
the common case is where we still get the interrupt after already
parsing the whole CSB:

<6>[   22.723238] i915 :00:02.0: [drm] vecs0
<6>[   22.723246] i915 :00:02.0: [drm]  current seqno 8, last 8, 
hangcheck 0 [-277277 ms], inflight 0
<6>[   22.723260] i915 :00:02.0: [drm]  Reset count: 0
<6>[   22.723269] i915 :00:02.0: [drm]  Requests:
<6>[   22.723278] i915 :00:02.0: [drm]  RING_START: 0x007fb000 
[0x]
<6>[   22.723289] i915 :00:02.0: [drm]  RING_HEAD:  0x0278 
[0x]
<6>[   22.723300] i915 :00:02.0: [drm]  RING_TAIL:  0x0278 
[0x]
<6>[   22.723311] i915 :00:02.0: [drm]  RING_CTL:   0x3001 []
<6>[   22.723322] i915 :00:02.0: [drm]  ACTHD:  0x_0278
<6>[   22.72] i915 :00:02.0: [drm]  BBADDR: 0x_0004
<6>[   22.723343] i915 :00:02.0: [drm]  Execlist status: 0x0301 

<6>[   22.723355] i915 :00:02.0: [drm]  Execlist CSB read 1 [1 cached], 
write 1 [1 from hws], interrupt posted? no
<6>[   22.723370] i915 :00:02.0: [drm]  ELSP[0] idle
<6>[   22.723378] i915 :00:02.0: [drm]  ELSP[1] idle
<6>[   22.723387] i915 :00:02.0: [drm]  HW active? 0x0
<6>[   22.723402] i915 :00:02.0: [drm] 


Those should not lead to hitting BUG_ON(gt.awake) though as the tasklet
is flushed before we clear gt.awake. Except if maybe the interrupt
arrives after the tasklet_kill...

Given that we wait for the engines to be idle before parking, we should
be safe enough with

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index bb0e85043e01..fa46137d431a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3327,6 +3327,8 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (new_requests_since_last_retire(dev_priv))
goto out_unlock;
 
+   synchronize_irq(dev_priv->drm.irq);
+
/*
 * We are committed now to parking the engines, make sure there
 * will be no more interrupts arriving later.

to flush a pending irq and not worry about a multi-phase park.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v7 3/4] drm/i915/guc : Updating GuC and HuC FW select function

[Sujaritha]

On 10/18/2017 02:17 PM, Michal Wajdeczko wrote:
On Wed, 18 Oct 2017 12:29:13 +0200, Sagar Arun Kamble 
 wrote:





On 10/18/2017 4:20 AM, Sujaritha Sundaresan wrote:

Updating GuC and HuC firmware select function to support removing
i915_modparams.enable_guc_loading module parameter.

v2: Clarifying the commit message (Anusha)

v3: Unify seq_puts messages, Re-factoring code as per review (Michal)

v4: Rebase

v5: Separating message unification into a separate patch

v6: Re-factoring code (Sagar, Michal)
 Rebase

v7: Separating from previuos patch (Sagar)
 Rebase

Signed-off-by: Sujaritha Sundaresan 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Anusha Srivatsa 
Cc: Oscar Mateo 
---
  drivers/gpu/drm/i915/intel_guc_fw.c | 9 -
  drivers/gpu/drm/i915/intel_guc_fw.h | 2 +-
  drivers/gpu/drm/i915/intel_huc.c    | 4 +++-
  3 files changed, 8 insertions(+), 7 deletions(-)

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

index ef67a36..5bffeef 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -63,7 +63,7 @@
   *
   * Return: zero when we know firmware, non-zero in other case

Update this documentation about return.
You have dropped call to fw_select in this series. Can you please check.

   */
-int intel_guc_fw_select(struct intel_guc *guc)
+void intel_guc_fw_select(struct intel_guc *guc)
  {
  struct drm_i915_private *dev_priv = guc_to_i915(guc);
  @@ -90,11 +90,10 @@ int intel_guc_fw_select(struct intel_guc *guc)
  guc->fw.major_ver_wanted = GLK_FW_MAJOR;
  guc->fw.minor_ver_wanted = GLK_FW_MINOR;
  } else {
-    DRM_ERROR("No GuC firmware known for platform with GuC!\n");
-    return -ENOENT;
+    if (!HAS_GUC(dev_priv))

This should be HAS_GUC


Hmm, I'm not sure that we really need such check here at all.
We can do proper check *before* calling this function and cover both
Huc and Guc at once.


I will drop the check in the next revision.



+    DRM_ERROR("No GuC FW known for platform with GuC!\n");
+    return;
  }
-
-    return 0;
  }
    /*
diff --git a/drivers/gpu/drm/i915/intel_guc_fw.h 
b/drivers/gpu/drm/i915/intel_guc_fw.h

index 023f5ba..7f6ccaf 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.h
+++ b/drivers/gpu/drm/i915/intel_guc_fw.h
@@ -27,7 +27,7 @@
    struct intel_guc;
  -int intel_guc_fw_select(struct intel_guc *guc);
+void intel_guc_fw_select(struct intel_guc *guc);
  int intel_guc_fw_upload(struct intel_guc *guc);
    #endif
diff --git a/drivers/gpu/drm/i915/intel_huc.c 
b/drivers/gpu/drm/i915/intel_huc.c

index c8a48cb..fc61779 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -108,7 +108,9 @@ void intel_huc_select_fw(struct intel_huc *huc)
  huc->fw.major_ver_wanted = GLK_HUC_FW_MAJOR;
  huc->fw.minor_ver_wanted = GLK_HUC_FW_MINOR;
  } else {
-    DRM_ERROR("No HuC firmware known for platform with HuC!\n");
+    /* For now, everything with a GuC also has a HuC */
+    if (HAS_GUC(dev_priv))
+    DRM_ERROR("No HuC FW known for platform with HuC!\n");
  return;
  }
  }


Thanks for the review.

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

Re: [Intel-gfx] [PATCH v7 3/4] drm/i915/guc : Updating GuC and HuC FW select function

[Sujaritha]

On 10/18/2017 03:29 AM, Sagar Arun Kamble wrote:



On 10/18/2017 4:20 AM, Sujaritha Sundaresan wrote:

Updating GuC and HuC firmware select function to support removing
i915_modparams.enable_guc_loading module parameter.

v2: Clarifying the commit message (Anusha)

v3: Unify seq_puts messages, Re-factoring code as per review (Michal)

v4: Rebase

v5: Separating message unification into a separate patch

v6: Re-factoring code (Sagar, Michal)
 Rebase

v7: Separating from previuos patch (Sagar)
 Rebase

Signed-off-by: Sujaritha Sundaresan 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Anusha Srivatsa 
Cc: Oscar Mateo 
---
  drivers/gpu/drm/i915/intel_guc_fw.c | 9 -
  drivers/gpu/drm/i915/intel_guc_fw.h | 2 +-
  drivers/gpu/drm/i915/intel_huc.c    | 4 +++-
  3 files changed, 8 insertions(+), 7 deletions(-)

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

index ef67a36..5bffeef 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -63,7 +63,7 @@
   *
   * Return: zero when we know firmware, non-zero in other case

Update this documentation about return.
You have dropped call to fw_select in this series. Can you please check.


I will check and update this.

   */
-int intel_guc_fw_select(struct intel_guc *guc)
+void intel_guc_fw_select(struct intel_guc *guc)
  {
  struct drm_i915_private *dev_priv = guc_to_i915(guc);
  @@ -90,11 +90,10 @@ int intel_guc_fw_select(struct intel_guc *guc)
  guc->fw.major_ver_wanted = GLK_FW_MAJOR;
  guc->fw.minor_ver_wanted = GLK_FW_MINOR;
  } else {
-    DRM_ERROR("No GuC firmware known for platform with GuC!\n");
-    return -ENOENT;
+    if (!HAS_GUC(dev_priv))

This should be HAS_GUC


I have decided to drop this check based on Michal's review.

+    DRM_ERROR("No GuC FW known for platform with GuC!\n");
+    return;
  }
-
-    return 0;
  }
    /*
diff --git a/drivers/gpu/drm/i915/intel_guc_fw.h 
b/drivers/gpu/drm/i915/intel_guc_fw.h

index 023f5ba..7f6ccaf 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.h
+++ b/drivers/gpu/drm/i915/intel_guc_fw.h
@@ -27,7 +27,7 @@
    struct intel_guc;
  -int intel_guc_fw_select(struct intel_guc *guc);
+void intel_guc_fw_select(struct intel_guc *guc);
  int intel_guc_fw_upload(struct intel_guc *guc);
    #endif
diff --git a/drivers/gpu/drm/i915/intel_huc.c 
b/drivers/gpu/drm/i915/intel_huc.c

index c8a48cb..fc61779 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -108,7 +108,9 @@ void intel_huc_select_fw(struct intel_huc *huc)
  huc->fw.major_ver_wanted = GLK_HUC_FW_MAJOR;
  huc->fw.minor_ver_wanted = GLK_HUC_FW_MINOR;
  } else {
-    DRM_ERROR("No HuC firmware known for platform with HuC!\n");
+    /* For now, everything with a GuC also has a HuC */
+    if (HAS_GUC(dev_priv))
+    DRM_ERROR("No HuC FW known for platform with HuC!\n");
  return;
  }
  }




Thanks for the review,

Regards,

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Bump wait-times for the final CS interrupt before parking

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Bump wait-times for the final CS 
interrupt before parking
URL   : https://patchwork.freedesktop.org/series/32486/
State : warning

== Summary ==

Series 32486v1 series starting with [1/2] drm/i915: Bump wait-times for the 
final CS interrupt before parking
https://patchwork.freedesktop.org/api/1.0/series/32486/revisions/1/mbox/

Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (fi-hsw-4770r)

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:443s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:456s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:371s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:531s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:265s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:506s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:501s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:495s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:478s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:557s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:417s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:249s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:578s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:432s
fi-hsw-4770r total:289  pass:261  dwarn:1   dfail:0   fail:0   skip:27  
time:426s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:434s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:497s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:460s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:494s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:570s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:473s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:592s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:548s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:645s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:527s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:506s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:459s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:567s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:424s

5c82a37eff83ab4e60e760fbaf03db5ba0563497 drm-tip: 2017y-10m-23d-18h-06m-28s UTC 
integration manifest
077bf0f23d24 drm/i915: Filter out spurious execlists context-switch interrupts
6129d04f29c2 drm/i915: Bump wait-times for the final CS interrupt before parking

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6146/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] drm/i915: Filter out spurious execlists context-switch interrupts

[Chris Wilson]

Back in commit a4b2b01523a8 ("drm/i915: Don't mark an execlists
context-switch when idle") we noticed the presence of late
context-switch interrupts. We were able to filter those out by looking
at whether the ELSP remained active, but in commit beecec901790
("drm/i915/execlists: Preemption!") that became problematic as we now
anticipate receiving a context-switch event for preemption while ELSP
may be empty. To restore the spurious interrupt suppression, add a
counter for the expected number of pending context-switches and skip if
we do not need to handle this interrupt to make forward progress.

v2: Don't forget to switch on for preempt.
v3: Reduce the counter to a on/off boolean tracker. Declare the HW as
active when we first submit, and idle after the final completion event
(with which we confirm the HW says it is idle), and track each source
of activity separately. With a finite number of sources, it should us
debug which gets stuck.

Fixes: beecec901790 ("drm/i915/execlists: Preemption!")
Signed-off-by: Chris Wilson 
Cc: Michal Winiarski 
Cc: Tvrtko Ursulin 
Cc: Arkadiusz Hiler 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_guc_submission.c |  3 +++
 drivers/gpu/drm/i915/i915_irq.c|  6 --
 drivers/gpu/drm/i915/intel_engine_cs.c |  5 +++--
 drivers/gpu/drm/i915/intel_lrc.c   | 27 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.h| 34 --
 5 files changed, 62 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index a2e8114b739d..f84c267728fd 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -610,6 +610,7 @@ static void i915_guc_dequeue(struct intel_engine_cs *engine)
execlists->first = rb;
if (submit) {
port_assign(port, last);
+   execlists_set_active(execlists, EXECLISTS_ACTIVE_USER);
i915_guc_submit(engine);
}
spin_unlock_irq(>timeline->lock);
@@ -633,6 +634,8 @@ static void i915_guc_irq_handler(unsigned long data)
 
rq = port_request([0]);
}
+   if (!rq)
+   execlists_clear_active(execlists, EXECLISTS_ACTIVE_USER);
 
if (!port_isset(last_port))
i915_guc_dequeue(engine);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b1296a55c1e4..f8205841868b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1388,8 +1388,10 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 
iir, int test_shift)
bool tasklet = false;
 
if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift)) {
-   __set_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
-   tasklet = true;
+   if (READ_ONCE(engine->execlists.active)) {
+   __set_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
+   tasklet = true;
+   }
}
 
if (iir & (GT_RENDER_USER_INTERRUPT << test_shift)) {
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a47a9c6bea52..ab5bf4e2e28e 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1548,8 +1548,8 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
if (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted))
return false;
 
-   /* Both ports drained, no more ELSP submission? */
-   if (port_request(>execlists.port[0]))
+   /* Waiting to drain ELSP? */
+   if (READ_ONCE(engine->execlists.active))
return false;
 
/* ELSP is empty, but there are ready requests? */
@@ -1749,6 +1749,7 @@ void intel_engine_dump(struct intel_engine_cs *engine, 
struct drm_printer *m)
   idx);
}
}
+   drm_printf(m, "\t\tHW active? 0x%x\n", execlists->active);
rcu_read_unlock();
} else if (INTEL_GEN(dev_priv) > 6) {
drm_printf(m, "\tPP_DIR_BASE: 0x%08x\n",
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 7f45dd7dc3e5..233c992a886b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -575,7 +575,8 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
 * the state of the GPU is known (idle).
 */
inject_preempt_context(engine);
-   execlists->preempt = true;
+   execlists_set_active(execlists,
+EXECLISTS_ACTIVE_PREEMPT);
 

[Intel-gfx] [PATCH 1/2] drm/i915: Bump wait-times for the final CS interrupt before parking

[Chris Wilson]

In the idle worker we drop the prolonged GT wakeref used to cover such
essentials as interrupt delivery. (When a CS interrupt arrives, we also
assert that the GT is awake.) However, it turns out that 10ms is not
long enough to be assured that the last CS interrupt has been delivered,
so bump that to 200ms, and move the entirety of that wait to before we
take the struct_mutex to avoid blocking. As this is now a potentially
long wait, restore the earlier behaviour of bailing out early when a new
request arrives.

v2: Break out the repeated check for new requests into its own little
helper to try and improve the self-commentary.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Mika Kuoppala 
Cc: Imre Deak 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 37 ++---
 1 file changed, 26 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 026cb52ece0b..bb0e85043e01 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3276,13 +3276,20 @@ i915_gem_retire_work_handler(struct work_struct *work)
}
 }
 
+static inline bool
+new_requests_since_last_retire(const struct drm_i915_private *i915)
+{
+   return (READ_ONCE(i915->gt.active_requests) ||
+   work_pending(>gt.idle_work.work));
+}
+
 static void
 i915_gem_idle_work_handler(struct work_struct *work)
 {
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv), gt.idle_work.work);
-   struct drm_device *dev = _priv->drm;
bool rearm_hangcheck;
+   ktime_t end;
 
if (!READ_ONCE(dev_priv->gt.awake))
return;
@@ -3291,14 +3298,21 @@ i915_gem_idle_work_handler(struct work_struct *work)
 * Wait for last execlists context complete, but bail out in case a
 * new request is submitted.
 */
-   wait_for(intel_engines_are_idle(dev_priv), 10);
-   if (READ_ONCE(dev_priv->gt.active_requests))
-   return;
+   end = ktime_add_ms(ktime_get(), 200);
+   do {
+   if (new_requests_since_last_retire(dev_priv))
+   return;
+
+   if (intel_engines_are_idle(dev_priv))
+   break;
+
+   usleep_range(100, 500);
+   } while (ktime_before(ktime_get(), end));
 
rearm_hangcheck =
cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
 
-   if (!mutex_trylock(>struct_mutex)) {
+   if (!mutex_trylock(_priv->drm.struct_mutex)) {
/* Currently busy, come back later */
mod_delayed_work(dev_priv->wq,
 _priv->gt.idle_work,
@@ -3310,13 +3324,14 @@ i915_gem_idle_work_handler(struct work_struct *work)
 * New request retired after this work handler started, extend active
 * period until next instance of the work.
 */
-   if (work_pending(work))
-   goto out_unlock;
-
-   if (dev_priv->gt.active_requests)
+   if (new_requests_since_last_retire(dev_priv))
goto out_unlock;
 
-   if (wait_for(intel_engines_are_idle(dev_priv), 10))
+   /*
+* We are committed now to parking the engines, make sure there
+* will be no more interrupts arriving later.
+*/
+   if (!intel_engines_are_idle(dev_priv))
DRM_ERROR("Timeout waiting for engines to idle\n");
 
intel_engines_mark_idle(dev_priv);
@@ -3330,7 +3345,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
gen6_rps_idle(dev_priv);
intel_runtime_pm_put(dev_priv);
 out_unlock:
-   mutex_unlock(>struct_mutex);
+   mutex_unlock(_priv->drm.struct_mutex);
 
 out_rearm:
if (rearm_hangcheck) {
-- 
2.15.0.rc1

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/cnl: Force DDI_A_4_LANES when needed. (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Force DDI_A_4_LANES when needed. (rev3)
URL   : https://patchwork.freedesktop.org/series/32398/
State : success

== Summary ==

Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-B-planes:
skip   -> PASS   (shard-hsw)
Test kms_plane_multiple:
Subgroup atomic-pipe-B-tiling-x:
skip   -> PASS   (shard-hsw)
Test kms_busy:
Subgroup extended-modeset-hang-oldfb-with-reset-render-C:
dmesg-warn -> PASS   (shard-hsw) fdo#102249
Test drv_module_reload:
Subgroup basic-reload-inject:
dmesg-warn -> PASS   (shard-hsw) fdo#102707

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

shard-hswtotal:2540 pass:1433 dwarn:1   dfail:0   fail:9   skip:1097 
time:9205s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6145/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 8/8] drm/i915: Adjust system agent voltage on CNL if required by DDI ports

[Rodrigo Vivi]

On Fri, Oct 20, 2017 at 05:05:40PM +, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> On CNL we may need to bump up the system agent voltage not only due
> to CDCLK but also when driving DDI port with a sufficiently high clock.
> To that end start tracking the minimum acceptable voltage for each crtc.
> We do the tracking via crtcs because we don't have any kind of encoder
> state. Also there's no downside to doing it this way, and it matches how
> we track cdclk requirements on account of pixel rate.
> 
> v2: Allow disabled crtcs to use the min voltage
> Add IS_CNL check to intel_ddi_compute_min_voltage() since
> we're using CNL specific values there
> s/intel_compute_min_voltage/cnl_compute_min_voltage/ since
> the function makes hw specific assumptions about the voltage
> values
> v3: Drop the test hack leftovers from skl_modeset_calc_cdclk()
> 
> Cc: Mika Kahola 
> Cc: Manasi Navare 
> Cc: Rodrigo Vivi 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  2 ++
>  drivers/gpu/drm/i915/intel_cdclk.c   | 46 
> +++-
>  drivers/gpu/drm/i915/intel_ddi.c | 11 +
>  drivers/gpu/drm/i915/intel_display.c |  9 +++
>  drivers/gpu/drm/i915/intel_dp_mst.c  |  5 
>  drivers/gpu/drm/i915/intel_drv.h |  6 +
>  6 files changed, 78 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d3ac58dc275f..185711a852b0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2415,6 +2415,8 @@ struct drm_i915_private {
>   unsigned int active_crtcs;
>   /* minimum acceptable cdclk for each pipe */
>   int min_cdclk[I915_MAX_PIPES];
> + /* minimum acceptable voltage for each pipe */
> + u8 min_voltage[I915_MAX_PIPES];
>  
>   int dpio_phy_iosf_port[I915_NUM_PHYS_VLV];
>  
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index 2a0cc9aafa5a..0f5f2ce4bd3e 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1661,6 +1661,12 @@ static void cnl_set_cdclk(struct drm_i915_private 
> *dev_priv,
>   mutex_unlock(_priv->pcu_lock);
>  
>   intel_update_cdclk(dev_priv);
> +
> + /*
> +  * Can't read out the voltage :( So let's
> +  * just assume everything is as expected.
> +  */
> + dev_priv->cdclk.hw.voltage = cdclk_state->voltage;
>  }
>  
>  static int cnl_cdclk_pll_vco(struct drm_i915_private *dev_priv, int cdclk)
> @@ -1930,6 +1936,42 @@ static int intel_compute_min_cdclk(struct 
> drm_atomic_state *state)
>   return min_cdclk;
>  }
>  
> +/*
> + * Note that this functions assumes that 0 is
> + * the lowest voltage value, and higher values
> + * correspond to increasingly higher voltages.
> + *
> + * Should that relationship no longer hold on
> + * future platforms this code will need to be
> + * adjusted.
> + */
> +static u8 cnl_compute_min_voltage(struct intel_atomic_state *state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + struct intel_crtc *crtc;
> + struct intel_crtc_state *crtc_state;
> + u8 min_voltage;
> + int i;
> + enum pipe pipe;
> +
> + memcpy(state->min_voltage, dev_priv->min_voltage,
> +sizeof(state->min_voltage));
> +
> + for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
> + if (crtc_state->base.enable)
> + state->min_voltage[i] = crtc_state->min_voltage;
> + else
> + state->min_voltage[i] = 0;
> + }
> +
> + min_voltage = 0;
> + for_each_pipe(dev_priv, pipe)
> + min_voltage = max(state->min_voltage[pipe],
> +   min_voltage);
> +
> + return min_voltage;
> +}
> +
>  static int vlv_modeset_calc_cdclk(struct drm_atomic_state *state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(state->dev);
> @@ -2086,7 +2128,9 @@ static int cnl_modeset_calc_cdclk(struct 
> drm_atomic_state *state)
>  
>   intel_state->cdclk.logical.vco = vco;
>   intel_state->cdclk.logical.cdclk = cdclk;
> - intel_state->cdclk.logical.voltage = cnl_calc_voltage(cdclk);
> + intel_state->cdclk.logical.voltage =
> + max(cnl_calc_voltage(cdclk),
> + cnl_compute_min_voltage(intel_state));
>  
>   if (!intel_state->active_crtcs) {
>   cdclk = cnl_calc_cdclk(0);
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index adf51b328844..f707134b4f65 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2525,6 +2525,13 @@ bool intel_ddi_is_audio_enabled(struct 
> drm_i915_private *dev_priv,
>   return false;
>  }
>  
> +void 

Re: [Intel-gfx] [PATCH 7/8] drm/i915: Use cdclk_state->voltage on CNL

[Rodrigo Vivi]

On Wed, Oct 18, 2017 at 08:48:24PM +, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Track the system agent voltage we request from pcode in the cdclk state
> on CNL. Annoyingly we can't actually read out the current value since
> there's no pcode command to do that, so we'll have to just assume that
> it worked.
> 
> Cc: Mika Kahola 
> Cc: Manasi Navare 
> Cc: Rodrigo Vivi 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Rodrigo Vivi 
(even with new v with voltage_level name)

Thanks for all explanations and discussions, this seems the
right approach.

> ---
>  drivers/gpu/drm/i915/intel_cdclk.c | 44 
> --
>  1 file changed, 28 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index 1b4dcd9689da..795a18f64c4c 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1505,6 +1505,19 @@ static int cnl_calc_cdclk(int min_cdclk)
>   return 168000;
>  }
>  
> +static u8 cnl_calc_voltage(int cdclk)
> +{
> + switch (cdclk) {
> + default:
> + case 168000:
> + return 0;
> + case 336000:
> + return 1;
> + case 528000:
> + return 2;
> + }
> +}
> +
>  static void cnl_cdclk_pll_update(struct drm_i915_private *dev_priv,
>struct intel_cdclk_state *cdclk_state)
>  {
> @@ -1538,7 +1551,7 @@ static void cnl_get_cdclk(struct drm_i915_private 
> *dev_priv,
>   cdclk_state->cdclk = cdclk_state->ref;
>  
>   if (cdclk_state->vco == 0)
> - return;
> + goto out;
>  
>   divider = I915_READ(CDCLK_CTL) & BXT_CDCLK_CD2X_DIV_SEL_MASK;
>  
> @@ -1555,6 +1568,13 @@ static void cnl_get_cdclk(struct drm_i915_private 
> *dev_priv,
>   }
>  
>   cdclk_state->cdclk = DIV_ROUND_CLOSEST(cdclk_state->vco, div);
> +
> + out:
> + /*
> +  * Can't read this out :( Let's assume it's
> +  * at least what the CDCLK frequency requires.
> +  */
> + cdclk_state->voltage = cnl_calc_voltage(cdclk_state->cdclk);
>  }
>  
>  static void cnl_cdclk_pll_disable(struct drm_i915_private *dev_priv)
> @@ -1595,7 +1615,7 @@ static void cnl_set_cdclk(struct drm_i915_private 
> *dev_priv,
>  {
>   int cdclk = cdclk_state->cdclk;
>   int vco = cdclk_state->vco;
> - u32 val, divider, pcu_ack;
> + u32 val, divider;
>   int ret;
>  
>   mutex_lock(_priv->pcu_lock);
> @@ -1624,19 +1644,6 @@ static void cnl_set_cdclk(struct drm_i915_private 
> *dev_priv,
>   break;
>   }
>  
> - switch (cdclk) {
> - case 528000:
> - pcu_ack = 2;
> - break;
> - case 336000:
> - pcu_ack = 1;
> - break;
> - case 168000:
> - default:
> - pcu_ack = 0;
> - break;
> - }
> -
>   if (dev_priv->cdclk.hw.vco != 0 &&
>   dev_priv->cdclk.hw.vco != vco)
>   cnl_cdclk_pll_disable(dev_priv);
> @@ -1654,7 +1661,8 @@ static void cnl_set_cdclk(struct drm_i915_private 
> *dev_priv,
>  
>   /* inform PCU of the change */
>   mutex_lock(_priv->pcu_lock);
> - sandybridge_pcode_write(dev_priv, SKL_PCODE_CDCLK_CONTROL, pcu_ack);
> + sandybridge_pcode_write(dev_priv, SKL_PCODE_CDCLK_CONTROL,
> + cdclk_state->voltage);
>   mutex_unlock(_priv->pcu_lock);
>  
>   intel_update_cdclk(dev_priv);
> @@ -1747,6 +1755,7 @@ void cnl_init_cdclk(struct drm_i915_private *dev_priv)
>  
>   cdclk_state.cdclk = cnl_calc_cdclk(0);
>   cdclk_state.vco = cnl_cdclk_pll_vco(dev_priv, cdclk_state.cdclk);
> + cdclk_state.voltage = cnl_calc_voltage(cdclk_state.cdclk);
>  
>   cnl_set_cdclk(dev_priv, _state);
>  }
> @@ -1764,6 +1773,7 @@ void cnl_uninit_cdclk(struct drm_i915_private *dev_priv)
>  
>   cdclk_state.cdclk = cdclk_state.ref;
>   cdclk_state.vco = 0;
> + cdclk_state.voltage = cnl_calc_voltage(cdclk_state.cdclk);
>  
>   cnl_set_cdclk(dev_priv, _state);
>  }
> @@ -2081,6 +2091,7 @@ static int cnl_modeset_calc_cdclk(struct 
> drm_atomic_state *state)
>  
>   intel_state->cdclk.logical.vco = vco;
>   intel_state->cdclk.logical.cdclk = cdclk;
> + intel_state->cdclk.logical.voltage = cnl_calc_voltage(cdclk);
>  
>   if (!intel_state->active_crtcs) {
>   cdclk = cnl_calc_cdclk(0);
> @@ -2088,6 +2099,7 @@ static int cnl_modeset_calc_cdclk(struct 
> drm_atomic_state *state)
>  
>   intel_state->cdclk.actual.vco = vco;
>   intel_state->cdclk.actual.cdclk = cdclk;
> + intel_state->cdclk.actual.voltage = cnl_calc_voltage(cdclk);
>   } else {
>   intel_state->cdclk.actual =
>   intel_state->cdclk.logical;
> -- 
> 2.13.6
> 

Re: [Intel-gfx] linux-firmware pull request (glk: DMC;cnl: DMC)

[Anusha Srivatsa]

On Mon, Oct 23, 2017 at 10:11:28AM -0700, Anusha Srivatsa wrote:

+Kyle McMartin

> Hi,
> 
> Please consider pulling i915 updates to linux-firmware.git.
> he following changes since commit bf04291309d3169c0ad3b8db52564235bbd08e30:
> 
>   WHENCE: Add new qed firmware (2017-10-09 18:03:26 +0100)
> 
> are available in the git repository at:
> 
>   https://github.com/anushasr/linux-firmware.git master
> 
> for you to fetch changes up to de5b4c22f05a03df76b45aed02a4dc26407857a4:
> 
>   linux-firmware/i915: Add Cannonlake DMC version 1.06 (2017-10-20 15:48:00 
> -0700)
> 
> 
> Anusha Srivatsa (2):
>   linux-firmware/i915: Add Geminilake DMC version 1.04
>   linux-firmware/i915: Add Cannonlake DMC version 1.06
> 
>  WHENCE   |   6 ++
>  i915/cnl_dmc_ver1_06.bin | Bin 0 -> 11224 bytes
>  i915/glk_dmc_ver1_04.bin | Bin 0 -> 8800 bytes
>  3 files changed, 6 insertions(+)
>  create mode 100644 i915/cnl_dmc_ver1_06.bin
>  create mode 100644 i915/glk_dmc_ver1_04.bin
> 
> P.S: Ignore the previous pull-request.
> 
> Thanks,
> Anusha Srivatsa
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/cnl: Force DDI_A_4_LANES when needed. (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Force DDI_A_4_LANES when needed. (rev2)
URL   : https://patchwork.freedesktop.org/series/32398/
State : success

== Summary ==

Test kms_flip:
Subgroup flip-vs-wf_vblank-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368 +1
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-B-planes:
skip   -> PASS   (shard-hsw)
Test kms_plane_multiple:
Subgroup atomic-pipe-B-tiling-x:
skip   -> PASS   (shard-hsw)

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

shard-hswtotal:2540 pass:1429 dwarn:3   dfail:0   fail:11  skip:1097 
time:9158s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6144/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] How To install?

[Rodrigo Vivi]

On Sat, Oct 21, 2017 at 02:27:11PM +, Rhyanz wrote:
> How to install graphic card on kali linux with "00:02.0 VGA compatible 
> controller: Intel
> Corporation 2nd Generation Core Processor Family Integrated Graphics 
> Controller (rev 09)
> ".

Could you please re-do it with nn to grab the exact pci id.

lspci -nn -s 00:02.0

> 
> i dont know what the steps to install.

you shouldn't need to install anything.
What is exactly the issue you are facing?

> please help me.
> Thanks :)

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

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: Force DDI_A_4_LANES when needed. (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Force DDI_A_4_LANES when needed. (rev3)
URL   : https://patchwork.freedesktop.org/series/32398/
State : success

== Summary ==

Series 32398v3 drm/i915/cnl: Force DDI_A_4_LANES when needed.
https://patchwork.freedesktop.org/api/1.0/series/32398/revisions/3/mbox/

Test chamelium:
Subgroup dp-crc-fast:
fail   -> PASS   (fi-kbl-7500u) fdo#102514
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
fail   -> PASS   (fi-gdg-551) fdo#102618
incomplete -> PASS   (fi-skl-6700hq) fdo#103410 +1
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-kbl-7560u) fdo#102846

fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514
fdo#102618 https://bugs.freedesktop.org/show_bug.cgi?id=102618
fdo#103410 https://bugs.freedesktop.org/show_bug.cgi?id=103410
fdo#102846 https://bugs.freedesktop.org/show_bug.cgi?id=102846

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:444s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:456s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:371s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:515s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:263s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:502s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:492s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:496s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:556s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:417s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:251s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:577s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:447s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:432s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:434s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:481s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:489s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:572s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:580s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:543s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:649s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:514s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:500s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:451s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:576s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:421s

d2ec28c53833297976d0754e0e82c3d7490b149c drm-tip: 2017y-10m-23d-08h-55m-00s UTC 
integration manifest
0073b1d1 drm/i915/cnl: Force DDI_A_4_LANES when needed.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6145/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v7 2/4] drm/i915/guc : Removing i915_modparams.enable_guc_loading module parameter

[Sujaritha]

On 10/18/2017 04:53 AM, Michal Wajdeczko wrote:
On Wed, 18 Oct 2017 00:50:47 +0200, Sujaritha Sundaresan 
 wrote:



We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need i915_modparams.enable_guc_submission=1, we also need
enable_guc_loading=1. We also need enable_guc_loading=1 when
we want to verify the HuC, which is every time we have a HuC
(but all platforms with HuC have a GuC and viceversa).

v2: Clarifying the commit message (Anusha)

v3: Unify seq_puts messages, Re-factoring code as per review (Michal)

v4: Rebase

v5: Separating message unification into a separate patch

v6: Re-factoring code (Sagar, Michal)
    Rebase

v7: Applying review comments (Sagar)
    Rebase

Suggested by: Oscar Mateo 
Signed-off-by: Sujaritha Sundaresan 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Anusha Srivatsa 
Cc: Oscar Mateo 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  6 +--
 drivers/gpu/drm/i915/i915_drv.h |  9 +++--
 drivers/gpu/drm/i915/i915_gem_context.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c |  2 +-
 drivers/gpu/drm/i915/i915_irq.c |  2 +-
 drivers/gpu/drm/i915/i915_params.c  |  4 --
 drivers/gpu/drm/i915/i915_params.h  |  1 -
 drivers/gpu/drm/i915/intel_uc.c | 69 
++---

 drivers/gpu/drm/i915/intel_uncore.c |  3 +-
 9 files changed, 50 insertions(+), 48 deletions(-)

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

index ac25d63..bc31769 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2361,7 +2361,7 @@ static int i915_huc_load_status_info(struct 
seq_file *m, void *data)

 struct drm_i915_private *dev_priv = node_to_i915(m->private);
 struct intel_uc_fw *huc_fw = _priv->huc.fw;
-    if (!HAS_HUC_UCODE(dev_priv)) {
+    if (!HAS_GUC(dev_priv)) {
 seq_puts(m, "not supported\n");
 return 0;
 }
@@ -2397,7 +2397,7 @@ static int i915_guc_load_status_info(struct 
seq_file *m, void *data)

 struct intel_uc_fw *guc_fw = _priv->guc.fw;
 u32 tmp, i;
-    if (!HAS_GUC_UCODE(dev_priv)) {
+    if (!HAS_GUC(dev_priv)) {
 seq_puts(m, "not supported\n");
 return 0;
 }
@@ -2496,7 +2496,7 @@ static bool check_guc_submission(struct 
seq_file *m)

if (!guc->execbuf_client) {
 seq_printf(m, "GuC submission %s\n",
-   HAS_GUC_SCHED(dev_priv) ?
+   HAS_GUC(dev_priv) ?
    "disabled" :
    "not supported");


Btw, there is also 3rd case: "failed" when we have Guc, but something 
went

wrong with fw loading or enabling...


 return false;
diff --git a/drivers/gpu/drm/i915/i915_drv.h 
b/drivers/gpu/drm/i915/i915_drv.h

index dd141b2..5b9bdd0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3201,9 +3201,12 @@ static inline unsigned int 
i915_sg_segment_size(void)

  */
 #define HAS_GUC(dev_priv)    ((dev_priv)->info.has_guc)
 #define HAS_GUC_CT(dev_priv) ((dev_priv)->info.has_guc_ct)
-#define HAS_GUC_UCODE(dev_priv)    (HAS_GUC(dev_priv))
-#define HAS_GUC_SCHED(dev_priv)    (HAS_GUC(dev_priv))
-#define HAS_HUC_UCODE(dev_priv)    (HAS_GUC(dev_priv))
+#define HAS_GUC_UCODE(dev_priv) ((dev_priv)->guc.fw.path != NULL)
+#define HAS_HUC_UCODE(dev_priv) ((dev_priv)->huc.fw.path != NULL)
+
+#define NEEDS_GUC_LOADING(dev_priv) \
+    (HAS_GUC(dev_priv) && \
+    (i915_modparams.enable_guc_submission || HAS_HUC_UCODE(dev_priv)))


Hmm, so by the moment we add huc fw definition to the driver we will
enable guc loading, and as huc is always present with guc, this will
silently enable guc loading for all platforms with guc(huc) and there
will be no option to turn this off ...

What if we don't care about Huc functionality ?

If there will be Huc fw, both guc and huc will be loaded.
If there will be no Huc fw on the system (but it will be defined in 
driver)
then we will generate errors from Huc firware loading, and likely try 
to load

Guc firmware for no purpose ...


Hmm, ok. So will the change will be to make the macro

NEEDS_GUC_LOADING(dev_priv) \
    (HAS_GUC(dev_priv) && i915_mopdarams.enable_guc_submission) ?


#define HAS_RESOURCE_STREAMER(dev_priv) 
((dev_priv)->info.has_resource_streamer)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c

index 5bf96a2..692d609 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -314,7 +314,7 @@ static u32 default_desc_template(const struct 
drm_i915_private *i915,
  * present or not in use we still need a small bias as ring 
wraparound

  * at offset 0 sometimes hangs. No idea why.
  */
-    if (HAS_GUC(dev_priv) 

[Intel-gfx] [PATCH] drm/i915/cnl: Force DDI_A_4_LANES when needed.

[Rodrigo Vivi]

As we faced in BXT, on CNL DDI_A_4_LANES is not
set as expected when system is boot with multiple
monitors connected. This result in wrong lane
setup impacting the max data rate available and
consequently blocking modeset on eDP, resulting
in a blank screen.

Most of CNL SKUs don't support DDI-E.
The only SKU that supports DDI-E is the same
that supports the full A/E split called DDI-F.

Also when DDI-F is used DDI-E cannot be used because
they share Interrupts. So DDI-E is almost useless.
Anyways let's consider this is possible and rely on
VBT for that.

This patch was initialy start by Clint, but required
many changes including full commit message. So
Credits entirely to Clint for finding this.

v2: Extract all messy conditions into a helper function
as suggested by Ville.
Along with simplification I removed the debug
message on the working case since now all conditions
are grouped.
v3: Split the conditions even more as suggested by Ville.
Get's cleaner and easier to add new cases in the
future.

Suggested-by: Clint Taylor 
Cc: Clint Taylor 
Cc: Mika Kahola 
Cc: Jani Nikula 
Cc: Ville Syrjälä 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_ddi.c | 46 ++--
 1 file changed, 35 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index adf51b328844..38a7088bd39c 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2694,6 +2694,34 @@ intel_ddi_init_hdmi_connector(struct intel_digital_port 
*intel_dig_port)
return connector;
 }
 
+static bool intel_ddi_a_force_4_lanes(struct intel_digital_port *dport)
+{
+   struct drm_i915_private *dev_priv = to_i915(dport->base.base.dev);
+
+   if (dport->port != PORT_A)
+   return false;
+
+   if (dport->saved_port_bits & DDI_A_4_LANES)
+   return false;
+
+   /* Broxton/Geminilake: Bspec says that DDI_A_4_LANES is the only
+* supported configuration
+*/
+   if (IS_GEN9_LP(dev_priv))
+   return true;
+
+   /* Cannonlake: Most of SKUs don't support DDI_E, and the only
+* one who does also have a full A/E split called
+* DDI_F what makes DDI_E useless. However for this
+* case let's trust VBT info.
+*/
+   if (IS_CANNONLAKE(dev_priv) &&
+   !intel_bios_is_port_present(dev_priv, PORT_E))
+   return true;
+
+   return false;
+}
+
 void intel_ddi_init(struct drm_i915_private *dev_priv, enum port port)
 {
struct intel_digital_port *intel_dig_port;
@@ -2803,18 +2831,14 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
}
 
/*
-* Bspec says that DDI_A_4_LANES is the only supported configuration
-* for Broxton.  Yet some BIOS fail to set this bit on port A if eDP
-* wasn't lit up at boot.  Force this bit on in our internal
-* configuration so that we use the proper lane count for our
-* calculations.
+* Some BIOS might fail to set this bit on port A if eDP
+* wasn't lit up at boot.  Force this bit set when needed
+* so we use the proper lane count for our calculations.
 */
-   if (IS_GEN9_LP(dev_priv) && port == PORT_A) {
-   if (!(intel_dig_port->saved_port_bits & DDI_A_4_LANES)) {
-   DRM_DEBUG_KMS("BXT BIOS forgot to set DDI_A_4_LANES for 
port A; fixing\n");
-   intel_dig_port->saved_port_bits |= DDI_A_4_LANES;
-   max_lanes = 4;
-   }
+   if (intel_ddi_a_force_4_lanes(intel_dig_port)) {
+   DRM_DEBUG_KMS("Forcing DDI_A_4_LANES for port A\n");
+   intel_dig_port->saved_port_bits |= DDI_A_4_LANES;
+   max_lanes = 4;
}
 
intel_dig_port->max_lanes = max_lanes;
-- 
2.13.5

___
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/cnl: Force DDI_A_4_LANES when needed. (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Force DDI_A_4_LANES when needed. (rev2)
URL   : https://patchwork.freedesktop.org/series/32398/
State : success

== Summary ==

Series 32398v2 drm/i915/cnl: Force DDI_A_4_LANES when needed.
https://patchwork.freedesktop.org/api/1.0/series/32398/revisions/2/mbox/

Test chamelium:
Subgroup dp-crc-fast:
fail   -> PASS   (fi-kbl-7500u) fdo#102514
Test gem_exec_reloc:
Subgroup basic-cpu-active:
pass   -> FAIL   (fi-gdg-551) fdo#102582 +2
Subgroup basic-write-gtt-active:
pass   -> FAIL   (fi-gdg-551) fdo#102582
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
fail   -> PASS   (fi-gdg-551) fdo#102618
incomplete -> PASS   (fi-skl-6700hq) fdo#103410 +1
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-kbl-7560u) fdo#102846

fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514
fdo#102582 https://bugs.freedesktop.org/show_bug.cgi?id=102582
fdo#102582 https://bugs.freedesktop.org/show_bug.cgi?id=102582
fdo#102618 https://bugs.freedesktop.org/show_bug.cgi?id=102618
fdo#103410 https://bugs.freedesktop.org/show_bug.cgi?id=103410
fdo#102846 https://bugs.freedesktop.org/show_bug.cgi?id=102846

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:440s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:452s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:368s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:522s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:265s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:505s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:492s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:493s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:476s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:553s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:416s
fi-gdg-551   total:289  pass:174  dwarn:1   dfail:0   fail:5   skip:109 
time:249s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:583s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:427s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:426s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:431s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:493s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:457s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:491s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:574s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:583s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:553s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:455s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:647s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:523s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:498s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:456s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:559s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:420s

d2ec28c53833297976d0754e0e82c3d7490b149c drm-tip: 2017y-10m-23d-08h-55m-00s UTC 
integration manifest
d2ab26975b01 drm/i915/cnl: Force DDI_A_4_LANES when needed.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6144/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Force DDI_A_4_LANES when needed.

[Ville Syrjälä]

On Mon, Oct 23, 2017 at 10:12:00AM -0700, Rodrigo Vivi wrote:
> As we faced in BXT, on CNL DDI_A_4_LANES is not
> set as expected when system is boot with multiple
> monitors connected. This result in wrong lane
> setup impacting the max data rate available and
> consequently blocking modeset on eDP, resulting
> in a blank screen.
> 
> Most of CNL SKUs don't support DDI-E.
> The only SKU that supports DDI-E is the same
> that supports the full A/E split called DDI-F.
> 
> Also when DDI-F is used DDI-E cannot be used because
> they share Interrupts. So DDI-E is almost useless.
> Anyways let's consider this is possible and rely on
> VBT for that.
> 
> This patch was initialy start by Clint, but required
> many changes including full commit message. So
> Credits entirely to Clint for finding this.
> 
> v2: Extract all messy conditions into a helper function
> as suggested by Ville.
> Along with simplification I removed the debug
> message on the working case since now all conditions
> are grouped.
> 
> Suggested-by: Clint Taylor 
> Cc: Clint Taylor 
> Cc: Mika Kahola 
> Cc: Jani Nikula 
> Cc: Ville Syrjälä 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 36 +---
>  1 file changed, 25 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index adf51b328844..5b03c24bae97 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2694,6 +2694,24 @@ intel_ddi_init_hdmi_connector(struct 
> intel_digital_port *intel_dig_port)
>   return connector;
>  }
>  
> +static bool intel_ddi_a_force_4_lanes(struct intel_digital_port *dport)
> +{
> + struct drm_i915_private *dev_priv = to_i915(dport->base.base.dev);
> +
> + /* Broxton: Bspec says that DDI_A_4_LANES is the only supported
> +  *  configuration
> +  * Cannonlake: Most of SKUs don't support DDI_E, and the only
> +  * one who does also have a full A/E split called
> +  * DDI_F what makes DDI_E useless. However for this
> +  * case let's trust VBT info.
> +  */
> + return dport->port == PORT_A &&
> + !(dport->saved_port_bits & DDI_A_4_LANES) &&
> + (IS_GEN9_LP(dev_priv) ||
> +  ((IS_CANNONLAKE(dev_priv)) &&
  ^   ^

Those don't look necessary.

It still took me a while to parse that thing. Maybe it should be split
even further? Eg. something like:

{
if (port != PORT_A)
return false;
if (saved_port_bits & 4_LANES)
return false;

/* blah */
if (BXT)
return true;

/* meh */
if (CNL && !port_e_present)
return true;

return false;
}

But your code looks correct as well, and I can live with it
if you want to keep it as is. So, with the extra parens removed
Reviewed-by: Ville Syrjälä 

> +   !intel_bios_is_port_present(dev_priv, PORT_E)));
> +}
> +
>  void intel_ddi_init(struct drm_i915_private *dev_priv, enum port port)
>  {
>   struct intel_digital_port *intel_dig_port;
> @@ -2803,18 +2821,14 @@ void intel_ddi_init(struct drm_i915_private 
> *dev_priv, enum port port)
>   }
>  
>   /*
> -  * Bspec says that DDI_A_4_LANES is the only supported configuration
> -  * for Broxton.  Yet some BIOS fail to set this bit on port A if eDP
> -  * wasn't lit up at boot.  Force this bit on in our internal
> -  * configuration so that we use the proper lane count for our
> -  * calculations.
> +  * Some BIOS might fail to set this bit on port A if eDP
> +  * wasn't lit up at boot.  Force this bit set when needed
> +  * so we use the proper lane count for our calculations.
>*/
> - if (IS_GEN9_LP(dev_priv) && port == PORT_A) {
> - if (!(intel_dig_port->saved_port_bits & DDI_A_4_LANES)) {
> - DRM_DEBUG_KMS("BXT BIOS forgot to set DDI_A_4_LANES for 
> port A; fixing\n");
> - intel_dig_port->saved_port_bits |= DDI_A_4_LANES;
> - max_lanes = 4;
> - }
> + if (intel_ddi_a_force_4_lanes(intel_dig_port)) {
> + DRM_DEBUG_KMS("Forcing DDI_A_4_LANES for port A\n");
> + intel_dig_port->saved_port_bits |= DDI_A_4_LANES;
> + max_lanes = 4;
>   }
>  
>   intel_dig_port->max_lanes = max_lanes;
> -- 
> 2.13.5

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

Re: [Intel-gfx] linux-firmware pull request (glk: DMC;cnl: DMC)

[Rodrigo Vivi]

On Mon, Oct 23, 2017 at 05:11:28PM +, Anusha Srivatsa wrote:
> Hi,
> 
> Please consider pulling i915 updates to linux-firmware.git.
> he following changes since commit bf04291309d3169c0ad3b8db52564235bbd08e30:
> 
>   WHENCE: Add new qed firmware (2017-10-09 18:03:26 +0100)
> 
> are available in the git repository at:
> 
>   https://github.com/anushasr/linux-firmware.git master
> 
> for you to fetch changes up to de5b4c22f05a03df76b45aed02a4dc26407857a4:
> 
>   linux-firmware/i915: Add Cannonlake DMC version 1.06 (2017-10-20 15:48:00 
> -0700)

Acked-by: Rodrigo Vivi 

we need these 2 firmwares...

> 
> 
> Anusha Srivatsa (2):
>   linux-firmware/i915: Add Geminilake DMC version 1.04
>   linux-firmware/i915: Add Cannonlake DMC version 1.06
> 
>  WHENCE   |   6 ++
>  i915/cnl_dmc_ver1_06.bin | Bin 0 -> 11224 bytes
>  i915/glk_dmc_ver1_04.bin | Bin 0 -> 8800 bytes
>  3 files changed, 6 insertions(+)
>  create mode 100644 i915/cnl_dmc_ver1_06.bin
>  create mode 100644 i915/glk_dmc_ver1_04.bin
> 
> P.S: Ignore the previous pull-request.
> 
> Thanks,
> Anusha Srivatsa
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/8] drm/i915: Start tracking voltage level in the cdclk state

[Rodrigo Vivi]

On Mon, Oct 23, 2017 at 12:13:46PM +, Ville Syrjälä wrote:
> On Fri, Oct 20, 2017 at 01:43:51PM -0700, Rodrigo Vivi wrote:
> > On Fri, Oct 20, 2017 at 02:01:37PM +, Ville Syrjälä wrote:
> > > On Wed, Oct 18, 2017 at 11:48:19PM +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä 
> > > > 
> > > > For CNL we'll need to start considering the port clocks when we select
> > > > the voltage level for the system agent. To that end start tracking the
> > > > voltage in the cdclk state (since that already has to adjust it).
> > > > 
> > > > Cc: Mika Kahola 
> > > > Cc: Manasi Navare 
> > > > Cc: Rodrigo Vivi 
> > > > Signed-off-by: Ville Syrjälä 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h |  1 +
> > > >  drivers/gpu/drm/i915/intel_cdclk.c  | 31 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_display.c|  8 
> > > >  drivers/gpu/drm/i915/intel_drv.h|  4 +++-
> > > >  drivers/gpu/drm/i915/intel_runtime_pm.c |  3 ++-
> > > >  5 files changed, 34 insertions(+), 13 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index f01c80076c59..d3ac58dc275f 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -2227,6 +2227,7 @@ struct i915_oa_ops {
> > > >  
> > > >  struct intel_cdclk_state {
> > > > unsigned int cdclk, vco, ref;
> > > > +   u8 voltage;
> > > 
> > > BTW now that I decided to abuse this for all platforms the name
> > > "voltage" might not be entirely accurate anymore. Especially on VLV/CHV
> > > the DSPFREQUAR value isn't directly a voltage value, but instead a
> > > request to punit to change the cdclk frequency to a specific value.
> > > Although naturally punit will also make sure the voltage will be
> > > set sufficiently high as well.
> > > 
> > > So I'm not entirely sure we want to call it "voltage" anymore. Something
> > > abstract like "level" is also what came to mind when I was thingking
> > > about this. If anyone is irked by "voltage" and would like to see
> > > something different there, let me know. Otherwise I think I might just
> > > leave it as is for now.
> > 
> > I honestly prefer "dvfs_level", voltage_level or anything_level.
> 
> I think voltage_level makes a ton of sense, and looks like that's
> actually what the CNL spec calls it as well (at least in some places).
> While still not 100% accurate for VLV/CHV I suppose, I think it's more
> clear than just "level" for more recent platforms.
> 
> Any objections to "voltage_level"?

none from my side.
feel free to carry the rv-b on patches changing to new name.

> 
> > 
> > Even if on VLV/CHV if it was also voltage related and not
> > frequency related. It is strange for my brain to read
> > voltage 1,2,3... my poor braing automatically reads 1V, 2V, 3V!
> > So level would be better imho.
> > 
> > But it is up to you.
> > 
> > > 
> > > >  };
> > > >  
> > > >  struct drm_i915_private {
> > > > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> > > > b/drivers/gpu/drm/i915/intel_cdclk.c
> > > > index 4bffd31a8924..52f8bb50 100644
> > > > --- a/drivers/gpu/drm/i915/intel_cdclk.c
> > > > +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> > > > @@ -1690,17 +1690,34 @@ void cnl_uninit_cdclk(struct drm_i915_private 
> > > > *dev_priv)
> > > >  }
> > > >  
> > > >  /**
> > > > - * intel_cdclk_state_compare - Determine if two CDCLK states differ
> > > > + * intel_cdclk_needs_modeset - Determine if two CDCLK states require a 
> > > > modeset on all pipes
> > > >   * @a: first CDCLK state
> > > >   * @b: second CDCLK state
> > > >   *
> > > >   * Returns:
> > > > - * True if the CDCLK states are identical, false if they differ.
> > > > + * True if the CDCLK states require pipes to be off during 
> > > > reprogramming, false if not.
> > > >   */
> > > > -bool intel_cdclk_state_compare(const struct intel_cdclk_state *a,
> > > > +bool intel_cdclk_needs_modeset(const struct intel_cdclk_state *a,
> > > >const struct intel_cdclk_state *b)
> > > >  {
> > > > -   return memcmp(a, b, sizeof(*a)) == 0;
> > > > +   return a->cdclk != b->cdclk ||
> > > > +   a->vco != b->vco ||
> > > > +   a->ref != b->ref;
> > > > +}
> > > > +
> > > > +/**
> > > > + * intel_cdclk_changed - Determine if two CDCLK states are different
> > > > + * @a: first CDCLK state
> > > > + * @b: second CDCLK state
> > > > + *
> > > > + * Returns:
> > > > + * True if the CDCLK states don't match, false if they do.
> > > > + */
> > > > +bool intel_cdclk_changed(const struct intel_cdclk_state *a,
> > > > +const struct intel_cdclk_state *b)
> > > > +{
> > > > +   return intel_cdclk_needs_modeset(a, b) ||
> > > > +   a->voltage != b->voltage;
> > 

[Intel-gfx] linux-firmware pull request (glk: DMC;cnl: DMC)

[Anusha Srivatsa]

Hi,

Please consider pulling i915 updates to linux-firmware.git.
he following changes since commit bf04291309d3169c0ad3b8db52564235bbd08e30:

  WHENCE: Add new qed firmware (2017-10-09 18:03:26 +0100)

are available in the git repository at:

  https://github.com/anushasr/linux-firmware.git master

for you to fetch changes up to de5b4c22f05a03df76b45aed02a4dc26407857a4:

  linux-firmware/i915: Add Cannonlake DMC version 1.06 (2017-10-20 15:48:00 
-0700)


Anusha Srivatsa (2):
  linux-firmware/i915: Add Geminilake DMC version 1.04
  linux-firmware/i915: Add Cannonlake DMC version 1.06

 WHENCE   |   6 ++
 i915/cnl_dmc_ver1_06.bin | Bin 0 -> 11224 bytes
 i915/glk_dmc_ver1_04.bin | Bin 0 -> 8800 bytes
 3 files changed, 6 insertions(+)
 create mode 100644 i915/cnl_dmc_ver1_06.bin
 create mode 100644 i915/glk_dmc_ver1_04.bin

P.S: Ignore the previous pull-request.

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

[Intel-gfx] [PATCH] drm/i915/cnl: Force DDI_A_4_LANES when needed.

[Rodrigo Vivi]

As we faced in BXT, on CNL DDI_A_4_LANES is not
set as expected when system is boot with multiple
monitors connected. This result in wrong lane
setup impacting the max data rate available and
consequently blocking modeset on eDP, resulting
in a blank screen.

Most of CNL SKUs don't support DDI-E.
The only SKU that supports DDI-E is the same
that supports the full A/E split called DDI-F.

Also when DDI-F is used DDI-E cannot be used because
they share Interrupts. So DDI-E is almost useless.
Anyways let's consider this is possible and rely on
VBT for that.

This patch was initialy start by Clint, but required
many changes including full commit message. So
Credits entirely to Clint for finding this.

v2: Extract all messy conditions into a helper function
as suggested by Ville.
Along with simplification I removed the debug
message on the working case since now all conditions
are grouped.

Suggested-by: Clint Taylor 
Cc: Clint Taylor 
Cc: Mika Kahola 
Cc: Jani Nikula 
Cc: Ville Syrjälä 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_ddi.c | 36 +---
 1 file changed, 25 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index adf51b328844..5b03c24bae97 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2694,6 +2694,24 @@ intel_ddi_init_hdmi_connector(struct intel_digital_port 
*intel_dig_port)
return connector;
 }
 
+static bool intel_ddi_a_force_4_lanes(struct intel_digital_port *dport)
+{
+   struct drm_i915_private *dev_priv = to_i915(dport->base.base.dev);
+
+   /* Broxton: Bspec says that DDI_A_4_LANES is the only supported
+*  configuration
+* Cannonlake: Most of SKUs don't support DDI_E, and the only
+* one who does also have a full A/E split called
+* DDI_F what makes DDI_E useless. However for this
+* case let's trust VBT info.
+*/
+   return dport->port == PORT_A &&
+   !(dport->saved_port_bits & DDI_A_4_LANES) &&
+   (IS_GEN9_LP(dev_priv) ||
+((IS_CANNONLAKE(dev_priv)) &&
+ !intel_bios_is_port_present(dev_priv, PORT_E)));
+}
+
 void intel_ddi_init(struct drm_i915_private *dev_priv, enum port port)
 {
struct intel_digital_port *intel_dig_port;
@@ -2803,18 +2821,14 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
}
 
/*
-* Bspec says that DDI_A_4_LANES is the only supported configuration
-* for Broxton.  Yet some BIOS fail to set this bit on port A if eDP
-* wasn't lit up at boot.  Force this bit on in our internal
-* configuration so that we use the proper lane count for our
-* calculations.
+* Some BIOS might fail to set this bit on port A if eDP
+* wasn't lit up at boot.  Force this bit set when needed
+* so we use the proper lane count for our calculations.
 */
-   if (IS_GEN9_LP(dev_priv) && port == PORT_A) {
-   if (!(intel_dig_port->saved_port_bits & DDI_A_4_LANES)) {
-   DRM_DEBUG_KMS("BXT BIOS forgot to set DDI_A_4_LANES for 
port A; fixing\n");
-   intel_dig_port->saved_port_bits |= DDI_A_4_LANES;
-   max_lanes = 4;
-   }
+   if (intel_ddi_a_force_4_lanes(intel_dig_port)) {
+   DRM_DEBUG_KMS("Forcing DDI_A_4_LANES for port A\n");
+   intel_dig_port->saved_port_bits |= DDI_A_4_LANES;
+   max_lanes = 4;
}
 
intel_dig_port->max_lanes = max_lanes;
-- 
2.13.5

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

Re: [Intel-gfx] [PATCH v7 2/4] drm/i915/guc : Removing i915_modparams.enable_guc_loading module parameter

[Sujaritha]

On 10/17/2017 03:57 PM, Chris Wilson wrote:

Quoting Sujaritha Sundaresan (2017-10-17 23:50:47)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dd141b2..5b9bdd0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3201,9 +3201,12 @@ static inline unsigned int i915_sg_segment_size(void)
   */
  #define HAS_GUC(dev_priv)  ((dev_priv)->info.has_guc)
  #define HAS_GUC_CT(dev_priv)   ((dev_priv)->info.has_guc_ct)
-#define HAS_GUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
-#define HAS_GUC_SCHED(dev_priv)(HAS_GUC(dev_priv))
-#define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
+#define HAS_GUC_UCODE(dev_priv) ((dev_priv)->guc.fw.path != NULL)
+#define HAS_HUC_UCODE(dev_priv) ((dev_priv)->huc.fw.path != NULL)
+
+#define NEEDS_GUC_LOADING(dev_priv) \
+   (HAS_GUC(dev_priv) && \
+   (i915_modparams.enable_guc_submission || HAS_HUC_UCODE(dev_priv)))

NEEDS_GUC_FW ?
-Chris

Sure. Will do.

Thanks for the review.

Sujaritha

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Disable lazy PPGTT page table optimization for vGPU (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Disable lazy PPGTT page table optimization for vGPU (rev2)
URL   : https://patchwork.freedesktop.org/series/32201/
State : success

== Summary ==

Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-B-planes:
skip   -> PASS   (shard-hsw)
Test kms_plane_multiple:
Subgroup atomic-pipe-B-tiling-x:
skip   -> PASS   (shard-hsw)
Test kms_busy:
Subgroup extended-modeset-hang-oldfb-with-reset-render-A:
pass   -> DMESG-WARN (shard-hsw) fdo#102249 +1

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

shard-hswtotal:2540 pass:1431 dwarn:3   dfail:0   fail:9   skip:1097 
time:9157s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6143/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gvt: use ARRAY_SIZE

[Zhi Wang]

Thanks, applied!

On 10/16/17 10:32, Jérémy Lefaure wrote:

Using the ARRAY_SIZE macro improves the readability of the code. Also,
it's useless to use a variable to store this constant calculated at
compile time.

Found with Coccinelle with the following semantic patch:
@r depends on (org || report)@
type T;
T[] E;
position p;
@@
(
  (sizeof(E)@p /sizeof(*E))
|
  (sizeof(E)@p /sizeof(E[...]))
|
  (sizeof(E)@p /sizeof(T))
)

Signed-off-by: Jérémy Lefaure 
---
This patch was part of a bigger patch [1].

[1]: https://patchwork.kernel.org/patch/9979843/

  drivers/gpu/drm/i915/gvt/vgpu.c | 9 -
  1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index 02c61a1ad56a..b32c1c889ea8 100644
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@ -31,6 +31,7 @@
   *
   */
  
+#include 

  #include "i915_drv.h"
  #include "gvt.h"
  #include "i915_pvinfo.h"
@@ -98,7 +99,6 @@ static struct {
   */
  int intel_gvt_init_vgpu_types(struct intel_gvt *gvt)
  {
-   unsigned int num_types;
unsigned int i, low_avail, high_avail;
unsigned int min_low;
  
@@ -116,15 +116,14 @@ int intel_gvt_init_vgpu_types(struct intel_gvt *gvt)

 */
low_avail = gvt_aperture_sz(gvt) - HOST_LOW_GM_SIZE;
high_avail = gvt_hidden_sz(gvt) - HOST_HIGH_GM_SIZE;
-   num_types = sizeof(vgpu_types) / sizeof(vgpu_types[0]);
  
-	gvt->types = kzalloc(num_types * sizeof(struct intel_vgpu_type),

-GFP_KERNEL);
+   gvt->types = kzalloc(ARRAY_SIZE(vgpu_types) *
+sizeof(struct intel_vgpu_type), GFP_KERNEL);
if (!gvt->types)
return -ENOMEM;
  
  	min_low = MB_TO_BYTES(32);

-   for (i = 0; i < num_types; ++i) {
+   for (i = 0; i < ARRAY_SIZE(vgpu_types); ++i) {
if (low_avail / vgpu_types[i].low_mm == 0)
break;
  


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

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Clean up dead code in cmd_parser

[Zhi Wang]

Thanks, applied! :)

On 10/16/17 06:32, Christos Gkekas wrote:

Delete variables 'gma_bottom' that are set but never used.

Signed-off-by: Christos Gkekas 
---
  drivers/gpu/drm/i915/gvt/cmd_parser.c | 6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index 2c0ccbb..d75ce70 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -2511,7 +2511,7 @@ static int command_scan(struct parser_exec_state *s,
  
  static int scan_workload(struct intel_vgpu_workload *workload)

  {
-   unsigned long gma_head, gma_tail, gma_bottom;
+   unsigned long gma_head, gma_tail;
struct parser_exec_state s;
int ret = 0;
  
@@ -2521,7 +2521,6 @@ static int scan_workload(struct intel_vgpu_workload *workload)
  
  	gma_head = workload->rb_start + workload->rb_head;

gma_tail = workload->rb_start + workload->rb_tail;
-   gma_bottom = workload->rb_start +  _RING_CTL_BUF_SIZE(workload->rb_ctl);
  
  	s.buf_type = RING_BUFFER_INSTRUCTION;

s.buf_addr_type = GTT_BUFFER;
@@ -2557,7 +2556,7 @@ static int scan_workload(struct intel_vgpu_workload 
*workload)
  static int scan_wa_ctx(struct intel_shadow_wa_ctx *wa_ctx)
  {
  
-	unsigned long gma_head, gma_tail, gma_bottom, ring_size, ring_tail;

+   unsigned long gma_head, gma_tail, ring_size, ring_tail;
struct parser_exec_state s;
int ret = 0;
struct intel_vgpu_workload *workload = container_of(wa_ctx,
@@ -2573,7 +2572,6 @@ static int scan_wa_ctx(struct intel_shadow_wa_ctx *wa_ctx)
PAGE_SIZE);
gma_head = wa_ctx->indirect_ctx.guest_gma;
gma_tail = wa_ctx->indirect_ctx.guest_gma + ring_tail;
-   gma_bottom = wa_ctx->indirect_ctx.guest_gma + ring_size;
  
  	s.buf_type = RING_BUFFER_INSTRUCTION;

s.buf_addr_type = GTT_BUFFER;


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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Plane assert/readout cleanups etc. (rev7)

[Patchwork]

== Series Details ==

Series: drm/i915: Plane assert/readout cleanups etc. (rev7)
URL   : https://patchwork.freedesktop.org/series/31758/
State : success

== Summary ==

Test kms_flip:
Subgroup flip-vs-absolute-wf_vblank:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-A:
dmesg-warn -> PASS   (shard-hsw) fdo#102249
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-B-planes:
skip   -> PASS   (shard-hsw)
Test kms_plane_multiple:
Subgroup atomic-pipe-B-tiling-x:
skip   -> PASS   (shard-hsw)
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912

fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912

shard-hswtotal:2540 pass:1432 dwarn:2   dfail:0   fail:9   skip:1097 
time:9144s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6142/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Disable lazy PPGTT page table optimization for vGPU (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Disable lazy PPGTT page table optimization for vGPU (rev2)
URL   : https://patchwork.freedesktop.org/series/32201/
State : success

== Summary ==

Series 32201v2 drm/i915: Disable lazy PPGTT page table optimization for vGPU
https://patchwork.freedesktop.org/api/1.0/series/32201/revisions/2/mbox/

Test chamelium:
Subgroup dp-crc-fast:
fail   -> PASS   (fi-kbl-7500u) fdo#102514
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
fail   -> PASS   (fi-gdg-551) fdo#102618
incomplete -> PASS   (fi-skl-6700hq) fdo#103410 +1
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-b-frame-sequence:
notrun -> INCOMPLETE (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-kbl-7560u) fdo#102846

fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514
fdo#102618 https://bugs.freedesktop.org/show_bug.cgi?id=102618
fdo#103410 https://bugs.freedesktop.org/show_bug.cgi?id=103410
fdo#102846 https://bugs.freedesktop.org/show_bug.cgi?id=102846

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:439s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:452s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:371s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:520s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:263s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:482s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:496s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:495s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:477s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:554s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:417s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:250s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:573s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:447s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:427s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:429s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:481s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:456s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:489s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:574s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:579s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:537s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-skl-6700hqtotal:236  pass:211  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:512s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:500s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:456s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:556s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:418s

d2ec28c53833297976d0754e0e82c3d7490b149c drm-tip: 2017y-10m-23d-08h-55m-00s UTC 
integration manifest
cd309c6e1658 drm/i915: Disable lazy PPGTT page table optimization for vGPU

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6143/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 1/7] fbcon: Add fbcon_rotate_hint to struct fb_info

[Sebastian Reichel]

Hi Hans,

On Mon, Oct 23, 2017 at 09:14:19AM +0200, Hans de Goede wrote:
> On some hardware the LCD panel is not mounted upright in the casing,
> but upside-down or rotated 90 degrees. In this case we want the console
> to automatically be rotated to compensate.
> 
> The fbdev-driver may know about the need to rotate. Add a new
> fbcon_rotate_hint field to struct fb_info, which gets initialized to -1.
> If the fbdev-driver knows that some sort of rotation is necessary then
> it can set this field to a FB_ROTATE_* value to tell the fbcon console
> driver to rotate the console.
> 
> Signed-off-by: Hans de Goede 
> ---

Thanks for your work. I will give it a try with Droid 4 and N950
once I find some time :)

[...]

> + p->con_rotate = initial_rotation;
> + if (p->con_rotate == -1)
> + p->con_rotate = info->fbcon_rotate_hint;
> + if (p->con_rotate == -1)
>   p->con_rotate = fbcon_platform_get_rotate(info);

[...]

> + p->con_rotate = initial_rotation;
> + if (p->con_rotate == -1)
> + p->con_rotate = info->fbcon_rotate_hint;
> + if (p->con_rotate == -1)
>   p->con_rotate = fbcon_platform_get_rotate(info);
> +

maybe add a little helper function to reduce code duplication?

-- Sebastian


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

[Intel-gfx] [CI] drm/i915: Disable lazy PPGTT page table optimization for vGPU

[Joonas Lahtinen]

When running under virtualization (vGPU active), we must disable
the lazy PPGTT page table initialization optimization introduced by:

14826673247e ("drm/i915: Only initialize partially filled pagetables")

We must do this because GVT-g makes unduly assumptions about guest
behaviour, which this optimization breaks. This results in following
looking errors in the host:

ERROR gvt: guest page write error -22, gfn 0x7ada8, pa 0x7ada89a8, var 0x6, len 
1

The real fix is to not to depend on i915 driver behaviour, but instead
either rely on only the contracts that i915 has with the hardware, or
add some paravirtualization. While the real fix is en route, it won't
be finished in time for 4.15, so the best option is to disable the
optimization for now when vGPU is active to avoid breaking 4.15 guests
in existing VM environments.

Fixes: 14826673247e ("drm/i915: Only initialize partially filled pagetables")
Suggested-by: Xiaolin Zhang 
Signed-off-by: Xiaolin Zhang 
[Joonas: Rewrote the commit message and added tags.]
Signed-off-by: Joonas Lahtinen 
Cc: Zhenyu Wang 
Cc: Zhi Wang 
Cc: Chris Wilson 
Cc: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Acked-by: Chris Wilson 
Acked-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 527a2d2d6281..5eaa6893daaa 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1341,7 +1341,7 @@ static int gen8_ppgtt_alloc_pd(struct i915_address_space 
*vm,
if (IS_ERR(pt))
goto unwind;
 
-   if (count < GEN8_PTES)
+   if (count < GEN8_PTES || intel_vgpu_active(vm->i915))
gen8_initialize_pt(vm, pt);
 
gen8_ppgtt_set_pde(vm, pd, pt, pde);
-- 
2.13.6

___
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: Plane assert/readout cleanups etc. (rev7)

[Patchwork]

== Series Details ==

Series: drm/i915: Plane assert/readout cleanups etc. (rev7)
URL   : https://patchwork.freedesktop.org/series/31758/
State : success

== Summary ==

Series 31758v7 drm/i915: Plane assert/readout cleanups etc.
https://patchwork.freedesktop.org/api/1.0/series/31758/revisions/7/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
fail   -> PASS   (fi-gdg-551) fdo#102618
incomplete -> PASS   (fi-skl-6700hq) fdo#103410 +1
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-kbl-7560u) fdo#102846

fdo#102618 https://bugs.freedesktop.org/show_bug.cgi?id=102618
fdo#103410 https://bugs.freedesktop.org/show_bug.cgi?id=103410
fdo#102846 https://bugs.freedesktop.org/show_bug.cgi?id=102846

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:441s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:452s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:378s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:530s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:263s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:499s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:497s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:493s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:471s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:554s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:405s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:250s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:575s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:455s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:427s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:432s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:495s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:457s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:477s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:572s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:478s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:583s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:541s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:456s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:644s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:516s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:500s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:456s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:568s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:413s

d2ec28c53833297976d0754e0e82c3d7490b149c drm-tip: 2017y-10m-23d-08h-55m-00s UTC 
integration manifest
32b9109d5b22 drm/i915: Use enum i9xx_plane_id for the .get_fifo_size() hooks
7571f3f46a81 drm/i915: s/enum plane/enum i9xx_plane_id/
7b45bbf79907 drm/i915: Redo plane sanitation during readout
bf23f7597723 drm/i915: Add .get_hw_state() method for planes

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6142/
___
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/fbdev: Panel orientation connector property support (rev2)

[Hans de Goede]

Hi,

On 23-10-17 13:09, Saarinen, Jani wrote:

Hi,

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of Hans de Goede
Sent: maanantai 23. lokakuuta 2017 13.32
To: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/fbdev: Panel orientation
connector property support (rev2)

Hi,

On 23-10-17 11:44, Patchwork wrote:

== Series Details ==

Series: drm/fbdev: Panel orientation connector property support (rev2)
URL   : https://patchwork.freedesktop.org/series/32447/
State : failure

== Summary ==

Series 32447v2 drm/fbdev: Panel orientation connector property support
https://patchwork.freedesktop.org/api/1.0/series/32447/revisions/2/mbo
x/

Test gem_exec_reloc:
  Subgroup basic-softpin:
  incomplete -> PASS   (fi-byt-j1900) fdo#103411
Test drv_module_reload:
  Subgroup basic-no-display:
  pass   -> FAIL   (fi-snb-2520m)


This seems to be an unrelated failure.

Potentially, let's verify, rerun established: 
https://intel-gfx-ci.01.org/queue/intel-gfx.html


That seemed to do the trick, thanks.

Perhaps we need to file a bug against the test which filed in the first
run that it fails intermittently ?

Regards,

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

[Intel-gfx] [PATCH v3 08/10] drm/i915: Nuke crtc->plane

[Ville Syrjala]

From: Ville Syrjälä 

Eliminate crtc->plane since it's pretty much a layering violation.
We can always get the plane via crtc->primary if we actually need it.

The only ugly thing left is plane_to_crtc_mapping[], but that's
still needed by the pre-g4x watermark code.

v2: Removed a misplaced comment change (Daniel)
v3: Rebase due to fbc crtc->y usage removal

Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 5 ++---
 drivers/gpu/drm/i915/intel_drv.h | 1 -
 drivers/gpu/drm/i915/intel_fbc.c | 4 ++--
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8854d8ccadb0..4cdd180bcc55 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13366,14 +13366,13 @@ static int intel_crtc_init(struct drm_i915_private 
*dev_priv, enum pipe pipe)
goto fail;
 
intel_crtc->pipe = pipe;
-   intel_crtc->plane = primary->plane;
 
/* initialize shared scalers */
intel_crtc_init_scalers(intel_crtc, crtc_state);
 
BUG_ON(pipe >= ARRAY_SIZE(dev_priv->plane_to_crtc_mapping) ||
-  dev_priv->plane_to_crtc_mapping[intel_crtc->plane] != NULL);
-   dev_priv->plane_to_crtc_mapping[intel_crtc->plane] = intel_crtc;
+  dev_priv->plane_to_crtc_mapping[primary->plane] != NULL);
+   dev_priv->plane_to_crtc_mapping[primary->plane] = intel_crtc;
dev_priv->pipe_to_crtc_mapping[intel_crtc->pipe] = intel_crtc;
 
drm_crtc_helper_add(_crtc->base, _helper_funcs);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index caa91f248f03..52b9321c9788 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -796,7 +796,6 @@ struct intel_crtc_state {
 struct intel_crtc {
struct drm_crtc base;
enum pipe pipe;
-   enum i9xx_plane_id plane;
/*
 * Whether the crtc and the connected output pipeline is active. Implies
 * that crtc->enabled is set, i.e. the current mode configuration has
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 89518846aa8b..e3cfdc2a8fef 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -890,7 +890,7 @@ static void intel_fbc_get_reg_params(struct intel_crtc 
*crtc,
params->vma = cache->vma;
 
params->crtc.pipe = crtc->pipe;
-   params->crtc.plane = crtc->plane;
+   params->crtc.plane = to_intel_plane(crtc->base.primary)->plane;
params->crtc.fence_y_offset = get_crtc_fence_y_offset(fbc);
 
params->fb.format = cache->fb.format;
@@ -1086,7 +1086,7 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
*dev_priv,
if (fbc_on_pipe_a_only(dev_priv) && crtc->pipe != PIPE_A)
continue;
 
-   if (fbc_on_plane_a_only(dev_priv) && crtc->plane != PLANE_A)
+   if (fbc_on_plane_a_only(dev_priv) && plane->plane != PLANE_A)
continue;
 
crtc_state = intel_atomic_get_new_crtc_state(state, crtc);
-- 
2.13.6

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

[Intel-gfx] [PATCH v4 01/10] drm/i915: Add .get_hw_state() method for planes

[Ville Syrjala]

From: Ville Syrjälä 

Add a .get_hw_state() method for planes, returning true or false
depending on whether the plane is enabled. Use it to rewrite the
plane enabled/disabled asserts in platform agnostic fashion.

We do lose the pre-gen4 plane<->pipe mapping checks, but since we're
supposed sanitize that anyway it doesn't really matter.

v2: Reoder patches to not depend on enum old_plane_id
Just call assert_plane_disabled() from assert_planes_disabled()
v3: Deal with disabled power wells in .get_hw_state()
v4: Rebase due skl primary plane code removal

Cc: Thierry Reding 
Cc: Alex Villacís Lasso 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter  #v2
Tested-by: Thierry Reding  #v2
---
 drivers/gpu/drm/i915/intel_display.c | 188 +--
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_sprite.c  |  83 
 3 files changed, 175 insertions(+), 98 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e2ac976844d8..8638d8fd7721 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1192,23 +1192,6 @@ void assert_panel_unlocked(struct drm_i915_private 
*dev_priv, enum pipe pipe)
 pipe_name(pipe));
 }
 
-static void assert_cursor(struct drm_i915_private *dev_priv,
- enum pipe pipe, bool state)
-{
-   bool cur_state;
-
-   if (IS_I845G(dev_priv) || IS_I865G(dev_priv))
-   cur_state = I915_READ(CURCNTR(PIPE_A)) & CURSOR_ENABLE;
-   else
-   cur_state = I915_READ(CURCNTR(pipe)) & CURSOR_MODE;
-
-   I915_STATE_WARN(cur_state != state,
-"cursor on pipe %c assertion failure (expected %s, current %s)\n",
-   pipe_name(pipe), onoff(state), onoff(cur_state));
-}
-#define assert_cursor_enabled(d, p) assert_cursor(d, p, true)
-#define assert_cursor_disabled(d, p) assert_cursor(d, p, false)
-
 void assert_pipe(struct drm_i915_private *dev_priv,
 enum pipe pipe, bool state)
 {
@@ -1236,77 +1219,25 @@ void assert_pipe(struct drm_i915_private *dev_priv,
pipe_name(pipe), onoff(state), onoff(cur_state));
 }
 
-static void assert_plane(struct drm_i915_private *dev_priv,
-enum plane plane, bool state)
+static void assert_plane(struct intel_plane *plane, bool state)
 {
-   u32 val;
-   bool cur_state;
+   bool cur_state = plane->get_hw_state(plane);
 
-   val = I915_READ(DSPCNTR(plane));
-   cur_state = !!(val & DISPLAY_PLANE_ENABLE);
I915_STATE_WARN(cur_state != state,
-"plane %c assertion failure (expected %s, current %s)\n",
-   plane_name(plane), onoff(state), onoff(cur_state));
+   "%s assertion failure (expected %s, current %s)\n",
+   plane->base.name, onoff(state), onoff(cur_state));
 }
 
-#define assert_plane_enabled(d, p) assert_plane(d, p, true)
-#define assert_plane_disabled(d, p) assert_plane(d, p, false)
+#define assert_plane_enabled(p) assert_plane(p, true)
+#define assert_plane_disabled(p) assert_plane(p, false)
 
-static void assert_planes_disabled(struct drm_i915_private *dev_priv,
-  enum pipe pipe)
+static void assert_planes_disabled(struct intel_crtc *crtc)
 {
-   int i;
-
-   /* Primary planes are fixed to pipes on gen4+ */
-   if (INTEL_GEN(dev_priv) >= 4) {
-   u32 val = I915_READ(DSPCNTR(pipe));
-   I915_STATE_WARN(val & DISPLAY_PLANE_ENABLE,
-"plane %c assertion failure, should be disabled but not\n",
-plane_name(pipe));
-   return;
-   }
-
-   /* Need to check both planes against the pipe */
-   for_each_pipe(dev_priv, i) {
-   u32 val = I915_READ(DSPCNTR(i));
-   enum pipe cur_pipe = (val & DISPPLANE_SEL_PIPE_MASK) >>
-   DISPPLANE_SEL_PIPE_SHIFT;
-   I915_STATE_WARN((val & DISPLAY_PLANE_ENABLE) && pipe == 
cur_pipe,
-"plane %c assertion failure, should be off on pipe %c but 
is still active\n",
-plane_name(i), pipe_name(pipe));
-   }
-}
-
-static void assert_sprites_disabled(struct drm_i915_private *dev_priv,
-   enum pipe pipe)
-{
-   int sprite;
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   struct intel_plane *plane;
 
-   if (INTEL_GEN(dev_priv) >= 9) {
-   for_each_sprite(dev_priv, pipe, sprite) {
-   u32 val = I915_READ(PLANE_CTL(pipe, sprite));
-   I915_STATE_WARN(val & PLANE_CTL_ENABLE,
-"plane %d assertion failure, 

[Intel-gfx] [PATCH v5 03/10] drm/i915: s/enum plane/enum i9xx_plane_id/

[Ville Syrjala]

From: Ville Syrjälä 

Rename enum plane to enum i9xx_plane_id to make it clear that it only
applies to pre-SKL platforms.

enum i9xx_plane_id is a global identifier, whereas enum plane_id is
per-pipe. We need the old global identifier to index the primary plane
(and the pre-g4x sprite C if we ever expose it) registers on pre-SKL
platforms.

v2: Reorder patches
v3: s/old_plane_id/i9xx_plane_id/ (Daniel)
Pimp the commit message a bit
Note that i9xx_plane_id doesn't apply to SKL+
v4: Rebase due to power domain handling in plane readout
v5: Rebase due to crtc->dspaddr_offset removal

Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h  |  6 +--
 drivers/gpu/drm/i915/intel_display.c | 87 ++--
 drivers/gpu/drm/i915/intel_drv.h |  6 +--
 3 files changed, 49 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 54b5d4c582b6..a6b912c646f9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -305,9 +305,9 @@ static inline bool transcoder_is_dsi(enum transcoder 
transcoder)
 
 /*
  * Global legacy plane identifier. Valid only for primary/sprite
- * planes on pre-g4x, and only for primary planes on g4x+.
+ * planes on pre-g4x, and only for primary planes on g4x-bdw.
  */
-enum plane {
+enum i9xx_plane_id {
PLANE_A,
PLANE_B,
PLANE_C,
@@ -1137,7 +1137,7 @@ struct intel_fbc {
 
struct {
enum pipe pipe;
-   enum plane plane;
+   enum i9xx_plane_id plane;
unsigned int fence_y_offset;
} crtc;
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 4ea0f1ef249e..e726b65588aa 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3223,16 +3223,16 @@ int i9xx_check_plane_surface(struct intel_plane_state 
*plane_state)
return 0;
 }
 
-static void i9xx_update_primary_plane(struct intel_plane *primary,
- const struct intel_crtc_state *crtc_state,
- const struct intel_plane_state 
*plane_state)
+static void i9xx_update_plane(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
 {
-   struct drm_i915_private *dev_priv = to_i915(primary->base.dev);
+   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
const struct drm_framebuffer *fb = plane_state->base.fb;
-   enum plane plane = primary->plane;
+   enum i9xx_plane_id plane_id = plane->plane;
u32 linear_offset;
u32 dspcntr = plane_state->ctl;
-   i915_reg_t reg = DSPCNTR(plane);
+   i915_reg_t reg = DSPCNTR(plane_id);
int x = plane_state->main.x;
int y = plane_state->main.y;
unsigned long irqflags;
@@ -3251,34 +3251,34 @@ static void i9xx_update_primary_plane(struct 
intel_plane *primary,
/* pipesrc and dspsize control the size that is scaled from,
 * which should always be the user's requested size.
 */
-   I915_WRITE_FW(DSPSIZE(plane),
+   I915_WRITE_FW(DSPSIZE(plane_id),
  ((crtc_state->pipe_src_h - 1) << 16) |
  (crtc_state->pipe_src_w - 1));
-   I915_WRITE_FW(DSPPOS(plane), 0);
-   } else if (IS_CHERRYVIEW(dev_priv) && plane == PLANE_B) {
-   I915_WRITE_FW(PRIMSIZE(plane),
+   I915_WRITE_FW(DSPPOS(plane_id), 0);
+   } else if (IS_CHERRYVIEW(dev_priv) && plane_id == PLANE_B) {
+   I915_WRITE_FW(PRIMSIZE(plane_id),
  ((crtc_state->pipe_src_h - 1) << 16) |
  (crtc_state->pipe_src_w - 1));
-   I915_WRITE_FW(PRIMPOS(plane), 0);
-   I915_WRITE_FW(PRIMCNSTALPHA(plane), 0);
+   I915_WRITE_FW(PRIMPOS(plane_id), 0);
+   I915_WRITE_FW(PRIMCNSTALPHA(plane_id), 0);
}
 
I915_WRITE_FW(reg, dspcntr);
 
-   I915_WRITE_FW(DSPSTRIDE(plane), fb->pitches[0]);
+   I915_WRITE_FW(DSPSTRIDE(plane_id), fb->pitches[0]);
if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
-   I915_WRITE_FW(DSPSURF(plane),
+   I915_WRITE_FW(DSPSURF(plane_id),
  intel_plane_ggtt_offset(plane_state) +
  dspaddr_offset);
-   I915_WRITE_FW(DSPOFFSET(plane), (y << 16) | x);
+   I915_WRITE_FW(DSPOFFSET(plane_id), (y << 16) | x);
} else if (INTEL_GEN(dev_priv) >= 4) {
-   I915_WRITE_FW(DSPSURF(plane),
+   

Re: [Intel-gfx] [PATCH v3 1/7] fbcon: Add fbcon_rotate_hint to struct fb_info

[Hans de Goede]

Hi,

On 23-10-17 14:43, Sebastian Reichel wrote:

Hi Hans,

On Mon, Oct 23, 2017 at 09:14:19AM +0200, Hans de Goede wrote:

On some hardware the LCD panel is not mounted upright in the casing,
but upside-down or rotated 90 degrees. In this case we want the console
to automatically be rotated to compensate.

The fbdev-driver may know about the need to rotate. Add a new
fbcon_rotate_hint field to struct fb_info, which gets initialized to -1.
If the fbdev-driver knows that some sort of rotation is necessary then
it can set this field to a FB_ROTATE_* value to tell the fbcon console
driver to rotate the console.

Signed-off-by: Hans de Goede 
---


Thanks for your work. I will give it a try with Droid 4 and N950
once I find some time :)


Ah, I did not even realize that this work would be useful for those
too, but yes that makes sense.



[...]


+   p->con_rotate = initial_rotation;
+   if (p->con_rotate == -1)
+   p->con_rotate = info->fbcon_rotate_hint;
+   if (p->con_rotate == -1)
p->con_rotate = fbcon_platform_get_rotate(info);


[...]


+   p->con_rotate = initial_rotation;
+   if (p->con_rotate == -1)
+   p->con_rotate = info->fbcon_rotate_hint;
+   if (p->con_rotate == -1)
p->con_rotate = fbcon_platform_get_rotate(info);
+


maybe add a little helper function to reduce code duplication?


Maybe, I took a look and there already is a fbcon_set_rotation()
helper which does something completely different, so it might
be best to just keep this as is to avoid confusion between
2 similar named functions.

Regards,

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

Re: [Intel-gfx] [PATCH] drm/i915: Apply Wa Display #1183 on skl, kbl, and cfl.

[Ville Syrjälä]

On Fri, Oct 20, 2017 at 03:15:49PM -0700, Rodrigo Vivi wrote:
> Wa Display #1183 was recently added to workaround
> "Failures when enabling DPLL0 with eDP link rate 2.16
> or 4.32 GHz and CD clock frequency 308.57 or 617.14 MHz
> (CDCLK_CTL CD Frequency Select 10b or 11b) used in this
>  enabling or in previous enabling."
> 
> This Workaround was designed to minimize the impact only
> to save the bad case with that link rates. But HW engineers
> indicated that it should be safe to apply broadly. Although
> they were expecting the DPLL0 link rate to be unchanged on
> runtime.
> 
> So, we could only apply if vco is 864. However this
> would require a synchronization with intel_csr.c. Probably
> a dev_priv->wa1183 bool.
> 
> Another equaly ugly possibility would be to save the edp_link_rate
> on dev_priv. With this we could fix one corner case that
> although rare I believe our code could hit that is if
> desired port clock is 4.32GHz our dpll0_enable initially
> sets the link rate to DPLL_CTRL1_LINK_RATE_1080 while
> it should set to DPLL_CTRL1_LINK_RATE_2160.
> 
> v2: - Avoid RMW for every step since we know exactly what
>   we should set. This also fix a bug on v1.
> - Remove set of minimal CDCLK since this is not needed
>   in the WA. At least one less write to CDCLK_CTL
>   since the other ones cannot be grouped.
> - Fix commit message.
> 
> Cc: Arthur J Runyan 
> Cc: Ville Syrjälä 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_reg.h |  2 ++
>  drivers/gpu/drm/i915/intel_cdclk.c  | 37 
> ++---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 10 +
>  3 files changed, 37 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 68a58cce6ab1..816b9665e092 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6980,6 +6980,7 @@ enum {
>  #define  RESET_PCH_HANDSHAKE_ENABLE  (1<<4)
>  
>  #define GEN8_CHICKEN_DCPR_1  _MMIO(0x46430)
> +#define   SKL_SELECT_ALTERNATE_DC_EXIT   (1<<30)
>  #define   MASK_WAKEMEM   (1<<13)
>  
>  #define SKL_DFSM _MMIO(0x51000)
> @@ -8526,6 +8527,7 @@ enum skl_power_gate {
>  #define  BXT_CDCLK_CD2X_DIV_SEL_4(3<<22)
>  #define  BXT_CDCLK_CD2X_PIPE(pipe)   ((pipe)<<20)
>  #define  BXT_CDCLK_CD2X_PIPE_NONEBXT_CDCLK_CD2X_PIPE(3)
> +#define  DIVMUX_CD_OVERRIDE  (1<<19)
>  #define  BXT_CDCLK_SSA_PRECHARGE_ENABLE  (1<<16)
>  #define  CDCLK_FREQ_DECIMAL_MASK (0x7ff)
>  
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index b2a6d62b71c0..5ecd5cb44e43 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -858,18 +858,13 @@ static void skl_set_preferred_cdclk_vco(struct 
> drm_i915_private *dev_priv,
>   intel_update_max_cdclk(dev_priv);
>  }
>  
> -static void skl_dpll0_enable(struct drm_i915_private *dev_priv, int vco)
> +static void skl_dpll0_enable(struct drm_i915_private *dev_priv, int vco,
> +  u32 freq_select)
>  {
> - int min_cdclk = skl_calc_cdclk(0, vco);
>   u32 val;
>  
>   WARN_ON(vco != 810 && vco != 864);
>  
> - /* select the minimum CDCLK before enabling DPLL 0 */
> - val = CDCLK_FREQ_337_308 | skl_cdclk_decimal(min_cdclk);
> - I915_WRITE(CDCLK_CTL, val);
> - POSTING_READ(CDCLK_CTL);
> -
>   /*
>* We always enable DPLL0 with the lowest link rate possible, but still
>* taking into account the VCO required to operate the eDP panel at the
> @@ -894,6 +889,10 @@ static void skl_dpll0_enable(struct drm_i915_private 
> *dev_priv, int vco)
>   I915_WRITE(DPLL_CTRL1, val);
>   POSTING_READ(DPLL_CTRL1);
>  
> + /* Wa Display #1183: skl,kbl,cfl */
> + val = DIVMUX_CD_OVERRIDE;
> + I915_WRITE(CDCLK_CTL, val);
> +
>   I915_WRITE(LCPLL1_CTL, I915_READ(LCPLL1_CTL) | LCPLL_PLL_ENABLE);
>  
>   if (intel_wait_for_register(dev_priv,
> @@ -901,6 +900,17 @@ static void skl_dpll0_enable(struct drm_i915_private 
> *dev_priv, int vco)
>   5))
>   DRM_ERROR("DPLL0 not locked\n");
>  
> + /* Wa Display #1183: skl,kbl,cfl */
> + val &= ~CDCLK_FREQ_SEL_MASK;;
> + I915_WRITE(CDCLK_CTL, val);
> +
> + val |= freq_select;
> + I915_WRITE(CDCLK_CTL, val);
> +
> + /* Wa Display #1183: skl,kbl,cfl */
> + val &= ~DIVMUX_CD_OVERRIDE;
> + I915_WRITE(CDCLK_CTL, val);

If I understood the w/a correctly we should pull all of this outa into
skl_set_cdclk(). Otherwise we'd only do these gymnastics when changing
the VCO between 8640 and 8100, whereas IIRC the w/a said that we should
do it every time VCO=8640 is going to be used, or maybe even was
used previously.

> +
>   

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Bump wait-times for the final CS interrupt before parking

[Patchwork]

== Series Details ==

Series: drm/i915: Bump wait-times for the final CS interrupt before parking
URL   : https://patchwork.freedesktop.org/series/32468/
State : failure

== Summary ==

Series 32468v1 drm/i915: Bump wait-times for the final CS interrupt before 
parking
https://patchwork.freedesktop.org/api/1.0/series/32468/revisions/1/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
fail   -> PASS   (fi-gdg-551) fdo#102618
incomplete -> PASS   (fi-skl-6700hq) fdo#103410 +1
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> INCOMPLETE (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-kbl-7560u) fdo#102846

fdo#102618 https://bugs.freedesktop.org/show_bug.cgi?id=102618
fdo#103410 https://bugs.freedesktop.org/show_bug.cgi?id=103410
fdo#102846 https://bugs.freedesktop.org/show_bug.cgi?id=102846

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:444s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:453s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:373s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:534s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:262s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:495s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:499s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:494s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:490s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:557s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:247s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:579s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:447s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:430s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:438s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:461s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:482s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:579s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:589s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:542s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:457s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:648s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:528s
fi-skl-6770hqtotal:225  pass:208  dwarn:0   dfail:0   fail:0   skip:16 
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:458s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:569s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:428s

d2ec28c53833297976d0754e0e82c3d7490b149c drm-tip: 2017y-10m-23d-08h-55m-00s UTC 
integration manifest
0ac4920cb227 drm/i915: Bump wait-times for the final CS interrupt before parking

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6141/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Force DDI_A_4_LANES when needed.

[Ville Syrjälä]

On Fri, Oct 20, 2017 at 04:11:27PM -0700, Rodrigo Vivi wrote:
> As we faced in BXT, on CNL DDI_A_4_LANES is not
> set as expected when system is boot with multiple
> monitors connected. This result in wrong lane
> setup impacting the max data rate available and
> consequently blocking modeset on eDP, resulting
> in a blank screen.
> 
> Most of CNL SKUs don't support DDI-E.
> The only SKU that supports DDI-E is the same
> that supports the full A/E split called DDI-F.
> 
> Also when DDI-F is used DDI-E cannot be used because
> they share Interrupts. So DDI-E is almost useless.
> Anyways let's consider this is possible and rely on
> VBT for that.
> 
> Since this become a trend this commit also adds
> an extra commit message so in the future we have
> an extra insight when we are dealing with this
> same case.
> 
> This patch was initialy start by Clint, but required
> many changes including full commit message. So
> Credits entirely to Clint for finding this.
> 
> Suggested-by: Clint Taylor 
> Cc: Clint Taylor 
> Cc: Mika Kahola 
> Cc: Jani Nikula 
> Cc: Ville Syrjälä 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 24 ++--
>  1 file changed, 18 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index adf51b328844..8acacf800a24 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2803,17 +2803,29 @@ void intel_ddi_init(struct drm_i915_private 
> *dev_priv, enum port port)
>   }
>  
>   /*
> -  * Bspec says that DDI_A_4_LANES is the only supported configuration
> -  * for Broxton.  Yet some BIOS fail to set this bit on port A if eDP
> -  * wasn't lit up at boot.  Force this bit on in our internal
> +  * Some BIOS might fail to set this bit on port A if eDP
> +  * wasn't lit up at boot.  Force this bit when needed on in our internal
>* configuration so that we use the proper lane count for our
>* calculations.
>*/
> - if (IS_GEN9_LP(dev_priv) && port == PORT_A) {
> - if (!(intel_dig_port->saved_port_bits & DDI_A_4_LANES)) {
> - DRM_DEBUG_KMS("BXT BIOS forgot to set DDI_A_4_LANES for 
> port A; fixing\n");
> + if (port == PORT_A &&
> + !(intel_dig_port->saved_port_bits & DDI_A_4_LANES)) {
> +
> + /* Broxton: Bspec says that DDI_A_4_LANES is the only supported
> +  *  configuration
> +  * Cannonlake: Most of SKUs don't support DDI_E, and the only
> +  * one who does also have a full A/E split called
> +  * DDI_F what makes DDI_E useless. However for this
> +  * case let's trust VBT info.
> +  */
> + if (IS_GEN9_LP(dev_priv) ||
> + ((IS_CANNONLAKE(dev_priv)) &&
> +  !intel_bios_is_port_present(dev_priv, PORT_E))) {

Can you extract all these messy conditions into some kind of (ideally
less convoluted) helper function? In the end I think it would be cool if
this part of the code ends up looking something like:

if (intel_ddi_a_force_4_lanes(dig_port)) {
DRM_DEBUG_KMS(...);
dig_port->saved_port_bits |= DDI_A_4_LANES;
max_lanes = 4;
}


> + DRM_DEBUG_KMS("Forcing DDI_A_4_LANES for port A\n");
>   intel_dig_port->saved_port_bits |= DDI_A_4_LANES;
>   max_lanes = 4;
> + } else {
> + DRM_DEBUG_KMS("DDI A configured for 2 lanes\n");
>   }
>   }
>  
> -- 
> 2.13.5

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

Re: [Intel-gfx] [PATCH] drm/i915: Show firmware URL once

[Michal Wajdeczko]

On Mon, 23 Oct 2017 14:15:06 +0200, Chris Wilson  
 wrote:



Quoting Michal Wajdeczko (2017-10-23 13:04:49)

On Sun, 22 Oct 2017 12:15:50 +0200, Chris Wilson
 wrote:

> Just show the firmware URL on the first failure, not every failure.
>
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Michal Wajdeczko 
> ---
>  drivers/gpu/drm/i915/intel_csr.c   |  3 +--
>  drivers/gpu/drm/i915/intel_uc_fw.c | 13 +++--
>  drivers/gpu/drm/i915/intel_uc_fw.h |  5 ++---
>  3 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_csr.c
> b/drivers/gpu/drm/i915/intel_csr.c
> index da9de47562b8..12a857acdb9b 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -427,8 +427,7 @@ static void csr_load_work_fn(struct work_struct
> *work)
>  "Failed to load DMC firmware %s."
>  " Disabling runtime power management.\n",
>  csr->fw_path);
> - dev_notice(dev_priv->drm.dev, "DMC firmware homepage:  
%s",

> -INTEL_UC_FIRMWARE_URL);
> + intel_uc_fw_show_url(dev_priv);
>   }
>   release_firmware(fw);
> diff --git a/drivers/gpu/drm/i915/intel_uc_fw.c
> b/drivers/gpu/drm/i915/intel_uc_fw.c
> index 973888e94cba..4ee90fda326b 100644
> --- a/drivers/gpu/drm/i915/intel_uc_fw.c
> +++ b/drivers/gpu/drm/i915/intel_uc_fw.c
> @@ -28,6 +28,16 @@
>  #include "intel_uc_fw.h"
>  #include "i915_drv.h"
> +/* Home of GuC, HuC and DMC firmwares */
> +#define INTEL_UC_FIRMWARE_URL
> "https://01.org/linuxgraphics/downloads/firmware;
> +
> +void intel_uc_fw_show_url(struct drm_i915_private *i915)
> +{
> + dev_info_once(i915->drm.dev,
> +   "Firmware can be downloaded from %s\n",
> +   INTEL_UC_FIRMWARE_URL);
> +}
> +
>  /**
>   * intel_uc_fw_fetch - fetch uC firmware
>   *
> @@ -189,8 +199,7 @@ void intel_uc_fw_fetch(struct drm_i915_private
> *dev_priv,
>   DRM_WARN("%s: Failed to fetch firmware %s (error %d)\n",
>intel_uc_fw_type_repr(uc_fw->type), uc_fw->path, err);
> - DRM_INFO("%s: Firmware can be downloaded from %s\n",
> -  intel_uc_fw_type_repr(uc_fw->type),  
INTEL_UC_FIRMWARE_URL);

> + intel_uc_fw_show_url(dev_priv);

Hmm, intel_uc_fw_fetch() should be called only once per specific uC
and only as part of i915_driver_load() - so there shall be no repeated
fetch failures for the same uC.

Also your changed message is little too generic (in old one we had uC
type, which may be helpful for the user).


I had the same url multiple times; at different log levels, that was
ugly. The url we give is the base for all firmwares, which one failed is
given in the previous line (including expected version) so unless you
plan on generating the url for the specific firmware, it is repeating
itself.


Hmm, we can use query url (and this will work even without immediate  
support
from 01.org site, user will just see homepage). Then your log will look  
like:


[4.961005] i915 :00:02.0: Direct firmware load for  
i915/bxt_dmc_ver1_07.bin failed with error -2
[4.961035] i915 :00:02.0: DMC firmware can be downloaded from:  
https://01.org/linuxgraphics/downloads/firmware?name=i915/bxt_dmc_ver1_07.bin
[4.983194] i915 :00:02.0: Direct firmware load for  
i915/bxt_huc_ver01_07_1398.bin failed with error -2
[4.983224] i915 :00:02.0: HuC firmware can be downloaded from:  
https://01.org/linuxgraphics/downloads/firmware?name=i915/bxt_huc_ver01_07_1398.bin





And in case of independent
fetch failures (lets say there is no DMC and HuC fw), we may wrongly
suggest that given url is for fw that failed first (DMC?), as messages
 from second failures (HuC) will not have such hint - user will have to
grep whole dmesg to guess that earlier url is applicable there too.


Correct, but such warnings are clustered.


And they are clustered accidentally as DMC fw is loaded from separate
csr.work.



[4.961005] i915 :00:02.0: Direct firmware load for  
i915/bxt_dmc_ver1_07.bin failed with error -2
[4.961028] i915 :00:02.0: Failed to load DMC firmware  
i915/bxt_dmc_ver1_07.bin. Disabling runtime power management.
[4.961035] i915 :00:02.0: DMC firmware homepage:  
https://01.org/linuxgraphics/downloads/firmware
[4.983194] i915 :00:02.0: Direct firmware load for  
i915/bxt_huc_ver01_07_1398.bin failed with error -2
[4.983218] [drm] HuC: Failed to fetch firmware  
i915/bxt_huc_ver01_07_1398.bin (error -2)
[4.983224] [drm] HuC: Firmware can be downloaded from  
https://01.org/linuxgraphics/downloads/firmware



So can we limit this patch only to s/DRM_INFO/dev_notice ?


This is info, not notice.


Correct.


It's not a significant condition as that's the
"ok, load failed, but we can 

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Add a hook for making the engines idle (parking) and unparking

[Joonas Lahtinen]

On Fri, 2017-10-20 at 22:06 +0100, Chris Wilson wrote:
> In the next patch, we will want to install a callback when the engines
> (GT as a whole) become idle and similarly when they first become busy.
> To enable that callback, first rename intel_engines_mark_idle() to the
> intel_engines_park() and provide the companion intel_engines_unpark().
> 
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Tvrtko Ursulin 
> Cc: Michał Winiarski 

Reviewed-by: Joonas Lahtinen 

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

[Intel-gfx] [CI] drm/i915: Bump wait-times for the final CS interrupt before parking

[Chris Wilson]

In the idle worker we drop the prolonged GT wakeref used to cover such
essentials as interrupt delivery. (When a CS interrupt arrives, we also
assert that the GT is awake.) However, it turns out that 10ms is not
long enough to be assured that the last CS interrupt has been delivered,
so bump that to 200ms, and move the entirety of that wait to before we
take the struct_mutex to avoid blocking. As this is now a potentially
long wait, restore the earlier behaviour of bailing out early when a new
request arrives.

v2: Break out the repeated check for new requests into its own little
helper to try and improve the self-commentary.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Mika Kuoppala 
Cc: Imre Deak 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 37 ++---
 1 file changed, 26 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 026cb52ece0b..bb0e85043e01 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3276,13 +3276,20 @@ i915_gem_retire_work_handler(struct work_struct *work)
}
 }
 
+static inline bool
+new_requests_since_last_retire(const struct drm_i915_private *i915)
+{
+   return (READ_ONCE(i915->gt.active_requests) ||
+   work_pending(>gt.idle_work.work));
+}
+
 static void
 i915_gem_idle_work_handler(struct work_struct *work)
 {
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv), gt.idle_work.work);
-   struct drm_device *dev = _priv->drm;
bool rearm_hangcheck;
+   ktime_t end;
 
if (!READ_ONCE(dev_priv->gt.awake))
return;
@@ -3291,14 +3298,21 @@ i915_gem_idle_work_handler(struct work_struct *work)
 * Wait for last execlists context complete, but bail out in case a
 * new request is submitted.
 */
-   wait_for(intel_engines_are_idle(dev_priv), 10);
-   if (READ_ONCE(dev_priv->gt.active_requests))
-   return;
+   end = ktime_add_ms(ktime_get(), 200);
+   do {
+   if (new_requests_since_last_retire(dev_priv))
+   return;
+
+   if (intel_engines_are_idle(dev_priv))
+   break;
+
+   usleep_range(100, 500);
+   } while (ktime_before(ktime_get(), end));
 
rearm_hangcheck =
cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
 
-   if (!mutex_trylock(>struct_mutex)) {
+   if (!mutex_trylock(_priv->drm.struct_mutex)) {
/* Currently busy, come back later */
mod_delayed_work(dev_priv->wq,
 _priv->gt.idle_work,
@@ -3310,13 +3324,14 @@ i915_gem_idle_work_handler(struct work_struct *work)
 * New request retired after this work handler started, extend active
 * period until next instance of the work.
 */
-   if (work_pending(work))
-   goto out_unlock;
-
-   if (dev_priv->gt.active_requests)
+   if (new_requests_since_last_retire(dev_priv))
goto out_unlock;
 
-   if (wait_for(intel_engines_are_idle(dev_priv), 10))
+   /*
+* We are committed now to parking the engines, make sure there
+* will be no more interrupts arriving later.
+*/
+   if (!intel_engines_are_idle(dev_priv))
DRM_ERROR("Timeout waiting for engines to idle\n");
 
intel_engines_mark_idle(dev_priv);
@@ -3330,7 +3345,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
gen6_rps_idle(dev_priv);
intel_runtime_pm_put(dev_priv);
 out_unlock:
-   mutex_unlock(>struct_mutex);
+   mutex_unlock(_priv->drm.struct_mutex);
 
 out_rearm:
if (rearm_hangcheck) {
-- 
2.15.0.rc1

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

Re: [Intel-gfx] [PATCH] drm/i915: Show firmware URL once

[Chris Wilson]

Quoting Michal Wajdeczko (2017-10-23 13:04:49)
> On Sun, 22 Oct 2017 12:15:50 +0200, Chris Wilson  
>  wrote:
> 
> > Just show the firmware URL on the first failure, not every failure.
> >
> > Signed-off-by: Chris Wilson 
> > Cc: Joonas Lahtinen 
> > Cc: Michal Wajdeczko 
> > ---
> >  drivers/gpu/drm/i915/intel_csr.c   |  3 +--
> >  drivers/gpu/drm/i915/intel_uc_fw.c | 13 +++--
> >  drivers/gpu/drm/i915/intel_uc_fw.h |  5 ++---
> >  3 files changed, 14 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_csr.c  
> > b/drivers/gpu/drm/i915/intel_csr.c
> > index da9de47562b8..12a857acdb9b 100644
> > --- a/drivers/gpu/drm/i915/intel_csr.c
> > +++ b/drivers/gpu/drm/i915/intel_csr.c
> > @@ -427,8 +427,7 @@ static void csr_load_work_fn(struct work_struct  
> > *work)
> >  "Failed to load DMC firmware %s."
> >  " Disabling runtime power management.\n",
> >  csr->fw_path);
> > - dev_notice(dev_priv->drm.dev, "DMC firmware homepage: %s",
> > -INTEL_UC_FIRMWARE_URL);
> > + intel_uc_fw_show_url(dev_priv);
> >   }
> >   release_firmware(fw);
> > diff --git a/drivers/gpu/drm/i915/intel_uc_fw.c  
> > b/drivers/gpu/drm/i915/intel_uc_fw.c
> > index 973888e94cba..4ee90fda326b 100644
> > --- a/drivers/gpu/drm/i915/intel_uc_fw.c
> > +++ b/drivers/gpu/drm/i915/intel_uc_fw.c
> > @@ -28,6 +28,16 @@
> >  #include "intel_uc_fw.h"
> >  #include "i915_drv.h"
> > +/* Home of GuC, HuC and DMC firmwares */
> > +#define INTEL_UC_FIRMWARE_URL  
> > "https://01.org/linuxgraphics/downloads/firmware;
> > +
> > +void intel_uc_fw_show_url(struct drm_i915_private *i915)
> > +{
> > + dev_info_once(i915->drm.dev,
> > +   "Firmware can be downloaded from %s\n",
> > +   INTEL_UC_FIRMWARE_URL);
> > +}
> > +
> >  /**
> >   * intel_uc_fw_fetch - fetch uC firmware
> >   *
> > @@ -189,8 +199,7 @@ void intel_uc_fw_fetch(struct drm_i915_private  
> > *dev_priv,
> >   DRM_WARN("%s: Failed to fetch firmware %s (error %d)\n",
> >intel_uc_fw_type_repr(uc_fw->type), uc_fw->path, err);
> > - DRM_INFO("%s: Firmware can be downloaded from %s\n",
> > -  intel_uc_fw_type_repr(uc_fw->type), INTEL_UC_FIRMWARE_URL);
> > + intel_uc_fw_show_url(dev_priv);
> 
> Hmm, intel_uc_fw_fetch() should be called only once per specific uC
> and only as part of i915_driver_load() - so there shall be no repeated
> fetch failures for the same uC.
> 
> Also your changed message is little too generic (in old one we had uC
> type, which may be helpful for the user).

I had the same url multiple times; at different log levels, that was
ugly. The url we give is the base for all firmwares, which one failed is
given in the previous line (including expected version) so unless you
plan on generating the url for the specific firmware, it is repeating
itself.

> And in case of independent
> fetch failures (lets say there is no DMC and HuC fw), we may wrongly
> suggest that given url is for fw that failed first (DMC?), as messages
>  from second failures (HuC) will not have such hint - user will have to
> grep whole dmesg to guess that earlier url is applicable there too.

Correct, but such warnings are clustered.

[4.961005] i915 :00:02.0: Direct firmware load for 
i915/bxt_dmc_ver1_07.bin failed with error -2
[4.961028] i915 :00:02.0: Failed to load DMC firmware 
i915/bxt_dmc_ver1_07.bin. Disabling runtime power management.
[4.961035] i915 :00:02.0: DMC firmware homepage: 
https://01.org/linuxgraphics/downloads/firmware
[4.983194] i915 :00:02.0: Direct firmware load for 
i915/bxt_huc_ver01_07_1398.bin failed with error -2
[4.983218] [drm] HuC: Failed to fetch firmware 
i915/bxt_huc_ver01_07_1398.bin (error -2)
[4.983224] [drm] HuC: Firmware can be downloaded from 
https://01.org/linuxgraphics/downloads/firmware
 
> So can we limit this patch only to s/DRM_INFO/dev_notice ?

This is info, not notice. It's not a significant condition as that's the
"ok, load failed, but we can survive with little change" before and this
is just the information where to find the firmware (outside of their
distro packing linux-firmwares which presumably was out of date).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/8] drm/i915: Start tracking voltage level in the cdclk state

[Ville Syrjälä]

On Fri, Oct 20, 2017 at 01:43:51PM -0700, Rodrigo Vivi wrote:
> On Fri, Oct 20, 2017 at 02:01:37PM +, Ville Syrjälä wrote:
> > On Wed, Oct 18, 2017 at 11:48:19PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > > 
> > > For CNL we'll need to start considering the port clocks when we select
> > > the voltage level for the system agent. To that end start tracking the
> > > voltage in the cdclk state (since that already has to adjust it).
> > > 
> > > Cc: Mika Kahola 
> > > Cc: Manasi Navare 
> > > Cc: Rodrigo Vivi 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h |  1 +
> > >  drivers/gpu/drm/i915/intel_cdclk.c  | 31 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c|  8 
> > >  drivers/gpu/drm/i915/intel_drv.h|  4 +++-
> > >  drivers/gpu/drm/i915/intel_runtime_pm.c |  3 ++-
> > >  5 files changed, 34 insertions(+), 13 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index f01c80076c59..d3ac58dc275f 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -2227,6 +2227,7 @@ struct i915_oa_ops {
> > >  
> > >  struct intel_cdclk_state {
> > >   unsigned int cdclk, vco, ref;
> > > + u8 voltage;
> > 
> > BTW now that I decided to abuse this for all platforms the name
> > "voltage" might not be entirely accurate anymore. Especially on VLV/CHV
> > the DSPFREQUAR value isn't directly a voltage value, but instead a
> > request to punit to change the cdclk frequency to a specific value.
> > Although naturally punit will also make sure the voltage will be
> > set sufficiently high as well.
> > 
> > So I'm not entirely sure we want to call it "voltage" anymore. Something
> > abstract like "level" is also what came to mind when I was thingking
> > about this. If anyone is irked by "voltage" and would like to see
> > something different there, let me know. Otherwise I think I might just
> > leave it as is for now.
> 
> I honestly prefer "dvfs_level", voltage_level or anything_level.

I think voltage_level makes a ton of sense, and looks like that's
actually what the CNL spec calls it as well (at least in some places).
While still not 100% accurate for VLV/CHV I suppose, I think it's more
clear than just "level" for more recent platforms.

Any objections to "voltage_level"?

> 
> Even if on VLV/CHV if it was also voltage related and not
> frequency related. It is strange for my brain to read
> voltage 1,2,3... my poor braing automatically reads 1V, 2V, 3V!
> So level would be better imho.
> 
> But it is up to you.
> 
> > 
> > >  };
> > >  
> > >  struct drm_i915_private {
> > > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> > > b/drivers/gpu/drm/i915/intel_cdclk.c
> > > index 4bffd31a8924..52f8bb50 100644
> > > --- a/drivers/gpu/drm/i915/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> > > @@ -1690,17 +1690,34 @@ void cnl_uninit_cdclk(struct drm_i915_private 
> > > *dev_priv)
> > >  }
> > >  
> > >  /**
> > > - * intel_cdclk_state_compare - Determine if two CDCLK states differ
> > > + * intel_cdclk_needs_modeset - Determine if two CDCLK states require a 
> > > modeset on all pipes
> > >   * @a: first CDCLK state
> > >   * @b: second CDCLK state
> > >   *
> > >   * Returns:
> > > - * True if the CDCLK states are identical, false if they differ.
> > > + * True if the CDCLK states require pipes to be off during 
> > > reprogramming, false if not.
> > >   */
> > > -bool intel_cdclk_state_compare(const struct intel_cdclk_state *a,
> > > +bool intel_cdclk_needs_modeset(const struct intel_cdclk_state *a,
> > >  const struct intel_cdclk_state *b)
> > >  {
> > > - return memcmp(a, b, sizeof(*a)) == 0;
> > > + return a->cdclk != b->cdclk ||
> > > + a->vco != b->vco ||
> > > + a->ref != b->ref;
> > > +}
> > > +
> > > +/**
> > > + * intel_cdclk_changed - Determine if two CDCLK states are different
> > > + * @a: first CDCLK state
> > > + * @b: second CDCLK state
> > > + *
> > > + * Returns:
> > > + * True if the CDCLK states don't match, false if they do.
> > > + */
> > > +bool intel_cdclk_changed(const struct intel_cdclk_state *a,
> > > +  const struct intel_cdclk_state *b)
> > > +{
> > > + return intel_cdclk_needs_modeset(a, b) ||
> > > + a->voltage != b->voltage;
> > >  }
> > >  
> > >  /**
> > > @@ -1714,15 +1731,15 @@ bool intel_cdclk_state_compare(const struct 
> > > intel_cdclk_state *a,
> > >  void intel_set_cdclk(struct drm_i915_private *dev_priv,
> > >const struct intel_cdclk_state *cdclk_state)
> > >  {
> > > - if (intel_cdclk_state_compare(_priv->cdclk.hw, cdclk_state))
> > > + if (!intel_cdclk_changed(_priv->cdclk.hw, cdclk_state))
> > >   return;
> > > 

Re: [Intel-gfx] [PATCH] drm/i915: Show firmware URL once

[Michal Wajdeczko]

On Sun, 22 Oct 2017 12:15:50 +0200, Chris Wilson  
 wrote:



Just show the firmware URL on the first failure, not every failure.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/intel_csr.c   |  3 +--
 drivers/gpu/drm/i915/intel_uc_fw.c | 13 +++--
 drivers/gpu/drm/i915/intel_uc_fw.h |  5 ++---
 3 files changed, 14 insertions(+), 7 deletions(-)

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

index da9de47562b8..12a857acdb9b 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -427,8 +427,7 @@ static void csr_load_work_fn(struct work_struct  
*work)

   "Failed to load DMC firmware %s."
   " Disabling runtime power management.\n",
   csr->fw_path);
-   dev_notice(dev_priv->drm.dev, "DMC firmware homepage: %s",
-  INTEL_UC_FIRMWARE_URL);
+   intel_uc_fw_show_url(dev_priv);
}
release_firmware(fw);
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.c  
b/drivers/gpu/drm/i915/intel_uc_fw.c

index 973888e94cba..4ee90fda326b 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/intel_uc_fw.c
@@ -28,6 +28,16 @@
 #include "intel_uc_fw.h"
 #include "i915_drv.h"
+/* Home of GuC, HuC and DMC firmwares */
+#define INTEL_UC_FIRMWARE_URL  
"https://01.org/linuxgraphics/downloads/firmware;

+
+void intel_uc_fw_show_url(struct drm_i915_private *i915)
+{
+   dev_info_once(i915->drm.dev,
+ "Firmware can be downloaded from %s\n",
+ INTEL_UC_FIRMWARE_URL);
+}
+
 /**
  * intel_uc_fw_fetch - fetch uC firmware
  *
@@ -189,8 +199,7 @@ void intel_uc_fw_fetch(struct drm_i915_private  
*dev_priv,

DRM_WARN("%s: Failed to fetch firmware %s (error %d)\n",
 intel_uc_fw_type_repr(uc_fw->type), uc_fw->path, err);
-   DRM_INFO("%s: Firmware can be downloaded from %s\n",
-intel_uc_fw_type_repr(uc_fw->type), INTEL_UC_FIRMWARE_URL);
+   intel_uc_fw_show_url(dev_priv);


Hmm, intel_uc_fw_fetch() should be called only once per specific uC
and only as part of i915_driver_load() - so there shall be no repeated
fetch failures for the same uC.

Also your changed message is little too generic (in old one we had uC
type, which may be helpful for the user). And in case of independent
fetch failures (lets say there is no DMC and HuC fw), we may wrongly
suggest that given url is for fw that failed first (DMC?), as messages
from second failures (HuC) will not have such hint - user will have to
grep whole dmesg to guess that earlier url is applicable there too.

So can we limit this patch only to s/DRM_INFO/dev_notice ?

Michal


release_firmware(fw);   /* OK even if fw is NULL */
 }
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h  
b/drivers/gpu/drm/i915/intel_uc_fw.h

index 132903669391..e18b9bedab02 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/intel_uc_fw.h
@@ -29,9 +29,6 @@ struct drm_printer;
 struct drm_i915_private;
 struct i915_vma;
-/* Home of GuC, HuC and DMC firmwares */
-#define INTEL_UC_FIRMWARE_URL  
"https://01.org/linuxgraphics/downloads/firmware;

-
 enum intel_uc_fw_status {
INTEL_UC_FIRMWARE_FAIL = -1,
INTEL_UC_FIRMWARE_NONE = 0,
@@ -118,4 +115,6 @@ int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,
 void intel_uc_fw_fini(struct intel_uc_fw *uc_fw);
 void intel_uc_fw_dump(struct intel_uc_fw *uc_fw, struct drm_printer *p);
+void intel_uc_fw_show_url(struct drm_i915_private *i915);
+
 #endif

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

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Adjust system agent voltage on CNL if required by DDI ports

[Ville Syrjälä]

On Fri, Oct 20, 2017 at 09:44:53PM +, Runyan, Arthur J wrote:
> If you know which direction voltage is moving, then you can optimize.  Nobody 
> snooping PLL.  Really only the DVFS post sequence is needed, placed either 
> before or after the clock programming, depending on whether voltage is 
> increasing or decreasing.  But you shouldn't optimize that far since nobody 
> is validating it that way.
> You do want to lower voltage to save power.

OK, so it looks like what I had in mind will work pefectly fine then.

And it's good that you mentioned the validation angle. We'll definitely
want to stick to using both the pre and post sequences just to be on the
safe side.

Thanks Art.

> 
> -Original Message-
> From: Vivi, Rodrigo 
> Sent: Friday, 20 October, 2017 1:37 PM
> To: Ville Syrjälä 
> Cc: Runyan, Arthur J ; 
> intel-gfx@lists.freedesktop.org; Kahola, Mika ; 
> Navare, Manasi D 
> Subject: Re: [PATCH 8/8] drm/i915: Adjust system agent voltage on CNL if 
> required by DDI ports
> 
> On Fri, Oct 20, 2017 at 08:07:07PM +, Ville Syrjälä wrote:
> > On Fri, Oct 20, 2017 at 05:48:54PM +, Runyan, Arthur J wrote:
> > > Sorry about top reply from corporate email...
> > > If you know in advance that you will just be temporarily disabling the 
> > > PLL, then your sequence works. 
> > 
> > Actually we would end up using this sequence even if disable the PLL for
> > good.
> > 
> > Eg. if we're just disabling the entire pipe+DPLL, we'd do this (assuming
> > cdclk doesn't need changing, but voltage can be lowered due to the port
> > no longer requiring it):
> > 1. disable DPLL
> > 2. disable DPLL power
> > ...
> > 3. DVFS pre sequence
> > 4. DVFS post sequence
> > 
> > And when starting up a pipe from the cold with a new DPLL we'd conversly
> > do this (again assuming no cdclk change, but voltage would have to be
> > ramped up for the port):
> > 1. DVFS pre sequence
> > 2. DVFS post sequence
> > ...
> > 3. enable DPLL power
> > 4. enable DPLL
> > 
> > It does look a bit strange doing the DVFS sequences on their own like
> > that, but I don't see why that should be problem. From where I'm sitting
> > it doesn't really look any different than the following seqeunces:
> > 
> > Disable with cdclk changing but port clock not having any effect
> > on the voltage:
> > 1. disable DPLL
> > 2. disable DPLL power
> > ...
> > 3. DVFS pre sequence
> > 4. change cdclk
> > 5. DVFS post sequence
> > 
> > Enable with cdclk changing but port clock not having any effect
> > on the voltage:
> > 1. DVFS pre sequence
> > 2. change cdclk
> > 3. DVFS post sequence
> > ...
> > 4. enable DPLL power
> > 5. enable DPLL
> > 
> > So unless something is snooping the actual state of the DPLLs, and based
> > on that second guessing our choice of voltage, I don't really see how
> > these two cases differ at all.
> 
> Well, I admit that I'm kind of lost on the discussion now.
> 
> but spec tells that we need use pre and post DVFS sequence
> always on CDCLK part and on DPLL only "If the frequency will result in a
> change to the voltage requirement,"
> So in the temporary disable-re-enable case we would be safe, because
> there woulnd't be no need to keep tweaking the voltage...
> 
> However on the other case you mentioned for the full pipe disable
> it seems that we have a situation of non optimal power getting
> wasted, right?!
> 
> Any idea how to solve that in the atomic way?
> Maybe caching the global min voltage required outside cdclk struct
> in a place where we can have access from both cdclk and pll state?
> 
> > 
> > > 
> > > -Original Message-
> > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] 
> > > Sent: Friday, 20 October, 2017 4:12 AM
> > > To: Vivi, Rodrigo 
> > > Cc: intel-gfx@lists.freedesktop.org; Kahola, Mika 
> > > ; Navare, Manasi D ; 
> > > Runyan, Arthur J 
> > > Subject: Re: [PATCH 8/8] drm/i915: Adjust system agent voltage on CNL if 
> > > required by DDI ports
> > > 
> > > On Thu, Oct 19, 2017 at 04:54:56PM -0700, Rodrigo Vivi wrote:
> > > > 
> > > > On Wed, Oct 18, 2017 at 08:48:25PM +, Ville Syrjala wrote:
> > > > > From: Ville Syrjälä 
> > > > > 
> > > > > On CNL we may need to bump up the system agent voltage not only due
> > > > > to CDCLK but also when driving DDI port with a sufficiently high 
> > > > > clock.
> > > > > To that end start tracking the minimum acceptable voltage for each 
> > > > > crtc.
> > > > > We do the tracking via crtcs because we don't have any kind of encoder
> > > > > state. Also there's no downside to doing it this way, and it matches 
> > > > > how
> > > > > we track cdclk requirements on account of pixel rate.
> > > > > 
> > > > > Cc: Mika Kahola 
> > > > > Cc: Manasi Navare 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Bump wait-times for the final CS interrupt before parking

[Chris Wilson]

Quoting Mika Kuoppala (2017-10-23 12:52:11)
> Chris Wilson  writes:
> 
> > In the idle worker we drop the prolonged GT wakeref used to cover such
> > essentials as interrupt delivery. (When a CS interrupt arrives, we also
> > assert that the GT is awake.) However, it turns out that 10ms is not
> > long enough to be assured that the last CS interrupt has been delivered,
> > so bump that to 200ms, and move the entirety of that wait to before we
> > take the struct_mutex to avoid blocking. As this is now a potentially
> > long wait, restore the earlier behaviour of bailing out early when a new
> > request arrives.
> >
> > Signed-off-by: Chris Wilson 
> > Cc: Joonas Lahtinen 
> > Cc: Mika Kuoppala 
> > Cc: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c | 31 ---
> >  1 file changed, 20 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 026cb52ece0b..d3a638613857 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3281,8 +3281,8 @@ i915_gem_idle_work_handler(struct work_struct *work)
> >  {
> >   struct drm_i915_private *dev_priv =
> >   container_of(work, typeof(*dev_priv), gt.idle_work.work);
> > - struct drm_device *dev = _priv->drm;
> >   bool rearm_hangcheck;
> > + ktime_t end;
> >  
> >   if (!READ_ONCE(dev_priv->gt.awake))
> >   return;
> > @@ -3291,14 +3291,22 @@ i915_gem_idle_work_handler(struct work_struct *work)
> >* Wait for last execlists context complete, but bail out in case a
> >* new request is submitted.
> >*/
> > - wait_for(intel_engines_are_idle(dev_priv), 10);
> > - if (READ_ONCE(dev_priv->gt.active_requests))
> > - return;
> > + end = ktime_add_ms(ktime_get(), 200);
> > + do {
> > + if (READ_ONCE(dev_priv->gt.active_requests) ||
> > + work_pending(work))
> > + return;
> > +
> > + if (intel_engines_are_idle(dev_priv))
> > + break;
> > +
> > + usleep_range(100, 500);
> > + } while (ktime_before(ktime_get(), end));
> >  
> >   rearm_hangcheck =
> >   cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
> >  
> > - if (!mutex_trylock(>struct_mutex)) {
> > + if (!mutex_trylock(_priv->drm.struct_mutex)) {
> >   /* Currently busy, come back later */
> >   mod_delayed_work(dev_priv->wq,
> >_priv->gt.idle_work,
> > @@ -3310,13 +3318,14 @@ i915_gem_idle_work_handler(struct work_struct *work)
> >* New request retired after this work handler started, extend active
> >* period until next instance of the work.
> >*/
> > - if (work_pending(work))
> > + if (dev_priv->gt.active_requests || work_pending(work))
> >   goto out_unlock;
> >
> 
> In here there might be some value of introducing helper
> for gt_work_pending as you could use it in early bailout and
> in here. You would get one superfluous READ_ONCE by having that inside
> the helper but in idle work it doesnt matter.
> 
> I think it would read better too. But as it is in bikesched
> department.

Read better depends on finding the right name.

new_requests_since_last_retire()?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Bump wait-times for the final CS interrupt before parking

[Mika Kuoppala]

Chris Wilson  writes:

> In the idle worker we drop the prolonged GT wakeref used to cover such
> essentials as interrupt delivery. (When a CS interrupt arrives, we also
> assert that the GT is awake.) However, it turns out that 10ms is not
> long enough to be assured that the last CS interrupt has been delivered,
> so bump that to 200ms, and move the entirety of that wait to before we
> take the struct_mutex to avoid blocking. As this is now a potentially
> long wait, restore the earlier behaviour of bailing out early when a new
> request arrives.
>
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Mika Kuoppala 
> Cc: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 31 ---
>  1 file changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 026cb52ece0b..d3a638613857 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3281,8 +3281,8 @@ i915_gem_idle_work_handler(struct work_struct *work)
>  {
>   struct drm_i915_private *dev_priv =
>   container_of(work, typeof(*dev_priv), gt.idle_work.work);
> - struct drm_device *dev = _priv->drm;
>   bool rearm_hangcheck;
> + ktime_t end;
>  
>   if (!READ_ONCE(dev_priv->gt.awake))
>   return;
> @@ -3291,14 +3291,22 @@ i915_gem_idle_work_handler(struct work_struct *work)
>* Wait for last execlists context complete, but bail out in case a
>* new request is submitted.
>*/
> - wait_for(intel_engines_are_idle(dev_priv), 10);
> - if (READ_ONCE(dev_priv->gt.active_requests))
> - return;
> + end = ktime_add_ms(ktime_get(), 200);
> + do {
> + if (READ_ONCE(dev_priv->gt.active_requests) ||
> + work_pending(work))
> + return;
> +
> + if (intel_engines_are_idle(dev_priv))
> + break;
> +
> + usleep_range(100, 500);
> + } while (ktime_before(ktime_get(), end));
>  
>   rearm_hangcheck =
>   cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
>  
> - if (!mutex_trylock(>struct_mutex)) {
> + if (!mutex_trylock(_priv->drm.struct_mutex)) {
>   /* Currently busy, come back later */
>   mod_delayed_work(dev_priv->wq,
>_priv->gt.idle_work,
> @@ -3310,13 +3318,14 @@ i915_gem_idle_work_handler(struct work_struct *work)
>* New request retired after this work handler started, extend active
>* period until next instance of the work.
>*/
> - if (work_pending(work))
> + if (dev_priv->gt.active_requests || work_pending(work))
>   goto out_unlock;
>

In here there might be some value of introducing helper
for gt_work_pending as you could use it in early bailout and
in here. You would get one superfluous READ_ONCE by having that inside
the helper but in idle work it doesnt matter.

I think it would read better too. But as it is in bikesched
department.

Reviewed-by: Mika Kuoppala 


> - if (dev_priv->gt.active_requests)
> - goto out_unlock;
> -
> - if (wait_for(intel_engines_are_idle(dev_priv), 10))
> + /*
> +  * We are committed now to parking the engines, make sure there
> +  * will be no more interrupts arriving later.
> +  */
> + if (!intel_engines_are_idle(dev_priv))
>   DRM_ERROR("Timeout waiting for engines to idle\n");
>  
>   intel_engines_mark_idle(dev_priv);
> @@ -3330,7 +3339,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
>   gen6_rps_idle(dev_priv);
>   intel_runtime_pm_put(dev_priv);
>  out_unlock:
> - mutex_unlock(>struct_mutex);
> + mutex_unlock(_priv->drm.struct_mutex);
>  
>  out_rearm:
>   if (rearm_hangcheck) {
> -- 
> 2.15.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Adjust system agent voltage on CNL if required by DDI ports

[Ville Syrjälä]

On Fri, Oct 20, 2017 at 01:36:42PM -0700, Rodrigo Vivi wrote:
> On Fri, Oct 20, 2017 at 08:07:07PM +, Ville Syrjälä wrote:
> > On Fri, Oct 20, 2017 at 05:48:54PM +, Runyan, Arthur J wrote:
> > > Sorry about top reply from corporate email...
> > > If you know in advance that you will just be temporarily disabling the 
> > > PLL, then your sequence works. 
> > 
> > Actually we would end up using this sequence even if disable the PLL for
> > good.
> > 
> > Eg. if we're just disabling the entire pipe+DPLL, we'd do this (assuming
> > cdclk doesn't need changing, but voltage can be lowered due to the port
> > no longer requiring it):
> > 1. disable DPLL
> > 2. disable DPLL power
> > ...
> > 3. DVFS pre sequence
> > 4. DVFS post sequence
> > 
> > And when starting up a pipe from the cold with a new DPLL we'd conversly
> > do this (again assuming no cdclk change, but voltage would have to be
> > ramped up for the port):
> > 1. DVFS pre sequence
> > 2. DVFS post sequence
> > ...
> > 3. enable DPLL power
> > 4. enable DPLL
> > 
> > It does look a bit strange doing the DVFS sequences on their own like
> > that, but I don't see why that should be problem. From where I'm sitting
> > it doesn't really look any different than the following seqeunces:
> > 
> > Disable with cdclk changing but port clock not having any effect
> > on the voltage:
> > 1. disable DPLL
> > 2. disable DPLL power
> > ...
> > 3. DVFS pre sequence
> > 4. change cdclk
> > 5. DVFS post sequence
> > 
> > Enable with cdclk changing but port clock not having any effect
> > on the voltage:
> > 1. DVFS pre sequence
> > 2. change cdclk
> > 3. DVFS post sequence
> > ...
> > 4. enable DPLL power
> > 5. enable DPLL
> > 
> > So unless something is snooping the actual state of the DPLLs, and based
> > on that second guessing our choice of voltage, I don't really see how
> > these two cases differ at all.
> 
> Well, I admit that I'm kind of lost on the discussion now.
> 
> but spec tells that we need use pre and post DVFS sequence
> always on CDCLK part and on DPLL only "If the frequency will result in a
> change to the voltage requirement,"
> So in the temporary disable-re-enable case we would be safe, because
> there woulnd't be no need to keep tweaking the voltage...
> 
> However on the other case you mentioned for the full pipe disable
> it seems that we have a situation of non optimal power getting
> wasted, right?!

No. The voltage will be reduced, but only after all relevant DPLLs have
been disabled. And conversly the voltage will be increased before any
relevant DPLLs will be enabled. So instead of talking to pcode around
the actual DPLL enable/disable register writes we do it well before/after
we touch the DPLL(s).

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/fbdev: Panel orientation connector property support (rev2)

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Hans de Goede
> Sent: maanantai 23. lokakuuta 2017 13.32
> To: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/fbdev: Panel orientation
> connector property support (rev2)
> 
> Hi,
> 
> On 23-10-17 11:44, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/fbdev: Panel orientation connector property support (rev2)
> > URL   : https://patchwork.freedesktop.org/series/32447/
> > State : failure
> >
> > == Summary ==
> >
> > Series 32447v2 drm/fbdev: Panel orientation connector property support
> > https://patchwork.freedesktop.org/api/1.0/series/32447/revisions/2/mbo
> > x/
> >
> > Test gem_exec_reloc:
> >  Subgroup basic-softpin:
> >  incomplete -> PASS   (fi-byt-j1900) fdo#103411
> > Test drv_module_reload:
> >  Subgroup basic-no-display:
> >  pass   -> FAIL   (fi-snb-2520m)
> 
> This seems to be an unrelated failure.
Potentially, let's verify, rerun established: 
https://intel-gfx-ci.01.org/queue/intel-gfx.html

> 
> Regards,
> 
> Hans

Br,
Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo


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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/fbdev: Panel orientation connector property support (rev2)

[Patchwork]

== Series Details ==

Series: drm/fbdev: Panel orientation connector property support (rev2)
URL   : https://patchwork.freedesktop.org/series/32447/
State : success

== Summary ==

Test perf:
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252

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

shard-hswtotal:2540 pass:1428 dwarn:2   dfail:0   fail:9   skip:1101 
time:9253s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6139/shards.html
___
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/fbdev: Panel orientation connector property support (rev2)

[Hans de Goede]

Hi,

On 23-10-17 11:44, Patchwork wrote:

== Series Details ==

Series: drm/fbdev: Panel orientation connector property support (rev2)
URL   : https://patchwork.freedesktop.org/series/32447/
State : failure

== Summary ==

Series 32447v2 drm/fbdev: Panel orientation connector property support
https://patchwork.freedesktop.org/api/1.0/series/32447/revisions/2/mbox/

Test gem_exec_reloc:
 Subgroup basic-softpin:
 incomplete -> PASS   (fi-byt-j1900) fdo#103411
Test drv_module_reload:
 Subgroup basic-no-display:
 pass   -> FAIL   (fi-snb-2520m)


This seems to be an unrelated failure.

Regards,

Hans





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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:446s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:448s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:371s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:523s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:263s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:496s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:499s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:505s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:477s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:551s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:418s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:250s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:578s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:445s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:430s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:440s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:498s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:457s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:498s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:576s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:479s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:586s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:543s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:458s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:650s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:525s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:497s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:460s
fi-snb-2520m total:289  pass:249  dwarn:0   dfail:0   fail:1   skip:39  
time:596s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:421s

93e5fc11a47aaf43e7cb10fab23d459163bb735b drm-tip: 2017y-10m-23d-06h-23m-22s UTC 
integration manifest
bbcc23fa3d3e fbcon: Remove dmi quirk table
7b229c3756f8 efifb: Set info->fbcon_rotate_hint based on 
drm_get_panel_orientation_quirk
6fbceafb86c3 drm/i915: Add "panel orientation" property to the panel connector
ba26abae2d99 drm/fb-helper: Apply panel orientation connector prop to the 
primary plane
6cce10152489 drm: Add support for a panel-orientation connector property
86af0d99c58f drm: Add panel orientation quirks
c98ef8cf9994 fbcon: Add fbcon_rotate_hint to struct fb_info

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6139/


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

Re: [Intel-gfx] [PATCH 05/15] drm/armada: Use drm_fb_helper_lastclose() and _poll_changed()

[Russell King - ARM Linux]

On Fri, Oct 20, 2017 at 01:02:03AM +0200, Noralf Trønnes wrote:
> This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
> It can also use drm_fb_helper_output_poll_changed() as its
> .output_poll_changed callback.
> 
> Cc: Russell King 

Acked-by: Russell King 

Thanks.

> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/armada/armada_drm.h   |  1 -
>  drivers/gpu/drm/armada/armada_drv.c   |  8 ++--
>  drivers/gpu/drm/armada/armada_fb.c| 11 +--
>  drivers/gpu/drm/armada/armada_fbdev.c |  8 
>  4 files changed, 3 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_drm.h 
> b/drivers/gpu/drm/armada/armada_drm.h
> index b064879ecdbd..cc4c557c9f66 100644
> --- a/drivers/gpu/drm/armada/armada_drm.h
> +++ b/drivers/gpu/drm/armada/armada_drm.h
> @@ -84,7 +84,6 @@ void armada_drm_queue_unref_work(struct drm_device *,
>  extern const struct drm_mode_config_funcs armada_drm_mode_config_funcs;
>  
>  int armada_fbdev_init(struct drm_device *);
> -void armada_fbdev_lastclose(struct drm_device *);
>  void armada_fbdev_fini(struct drm_device *);
>  
>  int armada_overlay_plane_create(struct drm_device *, unsigned long);
> diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> b/drivers/gpu/drm/armada/armada_drv.c
> index e857b88a9799..4b11b6b52f1d 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include "armada_crtc.h"
>  #include "armada_drm.h"
> @@ -54,15 +55,10 @@ static struct drm_ioctl_desc armada_ioctls[] = {
>   DRM_IOCTL_DEF_DRV(ARMADA_GEM_PWRITE, armada_gem_pwrite_ioctl, 0),
>  };
>  
> -static void armada_drm_lastclose(struct drm_device *dev)
> -{
> - armada_fbdev_lastclose(dev);
> -}
> -
>  DEFINE_DRM_GEM_FOPS(armada_drm_fops);
>  
>  static struct drm_driver armada_drm_driver = {
> - .lastclose  = armada_drm_lastclose,
> + .lastclose  = drm_fb_helper_lastclose,
>   .gem_free_object_unlocked = armada_gem_free_object,
>   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> diff --git a/drivers/gpu/drm/armada/armada_fb.c 
> b/drivers/gpu/drm/armada/armada_fb.c
> index a38d5a0892a9..ac92bce07ecd 100644
> --- a/drivers/gpu/drm/armada/armada_fb.c
> +++ b/drivers/gpu/drm/armada/armada_fb.c
> @@ -154,16 +154,7 @@ static struct drm_framebuffer *armada_fb_create(struct 
> drm_device *dev,
>   return ERR_PTR(ret);
>  }
>  
> -static void armada_output_poll_changed(struct drm_device *dev)
> -{
> - struct armada_private *priv = dev->dev_private;
> - struct drm_fb_helper *fbh = priv->fbdev;
> -
> - if (fbh)
> - drm_fb_helper_hotplug_event(fbh);
> -}
> -
>  const struct drm_mode_config_funcs armada_drm_mode_config_funcs = {
>   .fb_create  = armada_fb_create,
> - .output_poll_changed= armada_output_poll_changed,
> + .output_poll_changed= drm_fb_helper_output_poll_changed,
>  };
> diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
> b/drivers/gpu/drm/armada/armada_fbdev.c
> index a2ce83f84800..2a59db0994b2 100644
> --- a/drivers/gpu/drm/armada/armada_fbdev.c
> +++ b/drivers/gpu/drm/armada/armada_fbdev.c
> @@ -159,14 +159,6 @@ int armada_fbdev_init(struct drm_device *dev)
>   return ret;
>  }
>  
> -void armada_fbdev_lastclose(struct drm_device *dev)
> -{
> - struct armada_private *priv = dev->dev_private;
> -
> - if (priv->fbdev)
> - drm_fb_helper_restore_fbdev_mode_unlocked(priv->fbdev);
> -}
> -
>  void armada_fbdev_fini(struct drm_device *dev)
>  {
>   struct armada_private *priv = dev->dev_private;
> -- 
> 2.14.2
> 

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_atomic_transition: Make tests pass

[Maarten Lankhorst]

Op 23-10-17 om 11:35 schreef Petri Latvala:
>
>
> On Fri, Oct 20, 2017 at 03:24:15PM +0200, Maarten Lankhorst wrote:
>
> Subject: [Intel-gfx] [PATCH i-g-t] tests/kms_atomic_transition: Make tests 
> pass
>
>
> You have an excellent explanation of what this patch does in the long
> description, and yet this short description says nothing of value.
>
>
>
Is this patch good with subject: 'tests/kms_atomic_transition: Do not update 
unbound planes'?

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

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_plane_lowres: Rework tests to work without fbcon.

[Maarten Lankhorst]

Op 23-10-17 om 12:05 schreef Mika Kahola:
> Reviewed-by: Mika Kahola 
>
> On Fri, 2017-10-13 at 16:58 +0200, Maarten Lankhorst wrote:
>> kmstest_get_crtc was skipping because at that point the crtc was not
>> active yet, instead we should only use igt_assert_plane_visible
>> directly. Unexport kmstest_get_crtc, since nothing here should need
>> it.
>> While at it fix a small leak in igt_assert_plane_visible, the only
>> remaining user.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>> Resend, messed up my git-send-email
Thanks, pushed v3 which had some more fixes to make the test pass. :)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_plane_lowres: Rework tests to work without fbcon.

[Mika Kahola]

Reviewed-by: Mika Kahola 

On Fri, 2017-10-13 at 16:58 +0200, Maarten Lankhorst wrote:
> kmstest_get_crtc was skipping because at that point the crtc was not
> active yet, instead we should only use igt_assert_plane_visible
> directly. Unexport kmstest_get_crtc, since nothing here should need
> it.
> While at it fix a small leak in igt_assert_plane_visible, the only
> remaining user.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
> Resend, messed up my git-send-email
> 
>  lib/igt_kms.c|  5 ++--
>  lib/igt_kms.h|  1 -
>  tests/kms_plane_lowres.c | 64 
> 
>  3 files changed, 30 insertions(+), 40 deletions(-)
> 
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index cb2bc2b8df98..1c50484a613c 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -1416,7 +1416,7 @@ static void parse_crtc(char *info, struct
> kmstest_crtc *crtc)
>   igt_assert_eq(ret, 2);
>  }
>  
> -void kmstest_get_crtc(int device, enum pipe pipe, struct
> kmstest_crtc *crtc)
> +static void kmstest_get_crtc(int device, enum pipe pipe, struct
> kmstest_crtc *crtc)
>  {
>   char tmp[256];
>   FILE *file;
> @@ -1460,7 +1460,7 @@ void kmstest_get_crtc(int device, enum pipe
> pipe, struct kmstest_crtc *crtc)
>   fclose(file);
>   close(fd);
>  
> - igt_skip_on(ncrtc == 0);
> + igt_assert(ncrtc == 1);
>  }
>  
>  void igt_assert_plane_visible(int fd, enum pipe pipe, bool
> visibility)
> @@ -1485,6 +1485,7 @@ void igt_assert_plane_visible(int fd, enum pipe
> pipe, bool visibility)
>   }
>   }
>  
> + free(crtc.planes);
>   igt_assert_eq(visible, visibility);
>  }
>  
> diff --git a/lib/igt_kms.h b/lib/igt_kms.h
> index 200f35e63308..acc82913e0b7 100644
> --- a/lib/igt_kms.h
> +++ b/lib/igt_kms.h
> @@ -221,7 +221,6 @@ uint32_t kmstest_dumb_create(int fd, int width,
> int height, int bpp,
>  void *kmstest_dumb_map_buffer(int fd, uint32_t handle, uint64_t
> size,
>     unsigned prot);
>  unsigned int kmstest_get_vblank(int fd, int pipe, unsigned int
> flags);
> -void kmstest_get_crtc(int fd, enum pipe pipe, struct kmstest_crtc
> *crtc);
>  void igt_assert_plane_visible(int fd, enum pipe pipe, bool
> visibility);
>  
>  /*
> diff --git a/tests/kms_plane_lowres.c b/tests/kms_plane_lowres.c
> index b16c8cd433b2..44e0ada92ead 100644
> --- a/tests/kms_plane_lowres.c
> +++ b/tests/kms_plane_lowres.c
> @@ -40,7 +40,6 @@ typedef struct {
>   int drm_fd;
>   igt_display_t display;
>   igt_pipe_crc_t *pipe_crc;
> - igt_plane_t **plane;
>   struct igt_fb *fb;
>  } data_t;
>  
> @@ -113,30 +112,27 @@ static void
>  test_init(data_t *data, enum pipe pipe)
>  {
>   data->pipe_crc = igt_pipe_crc_new(data->drm_fd, pipe,
> INTEL_PIPE_CRC_SOURCE_AUTO);
> - data->plane = calloc(data->display.pipes[pipe].n_planes,
> sizeof(data->plane));\
> - igt_assert_f(data->plane, "Failed to allocate memory for %d
> planes\n",
> -  data->display.pipes[pipe].n_planes);
>   data->fb = calloc(data->display.pipes[pipe].n_planes,
> sizeof(struct igt_fb));
>   igt_assert_f(data->fb, "Failed to allocate memory for %d
> FBs\n",
>    data->display.pipes[pipe].n_planes);
>  }
>  
>  static void
> -test_fini(data_t *data, igt_output_t *output)
> +test_fini(data_t *data, igt_output_t *output, enum pipe pipe)
>  {
> + igt_plane_t *plane;
> +
>   /* restore original mode */
>   igt_output_override_mode(output, NULL);
>  
> - for (int i = 0; i < 2; i++)
> - igt_plane_set_fb(data->plane[i], NULL);
> + for_each_plane_on_pipe(>display, pipe, plane)
> + igt_plane_set_fb(plane, NULL);
>  
>   /* reset the constraint on the pipe */
>   igt_output_set_pipe(output, PIPE_ANY);
>  
>   igt_pipe_crc_free(data->pipe_crc);
>  
> - free(data->plane);
> - data->plane = NULL;
>   free(data->fb);
>   data->fb = NULL;
>  }
> @@ -184,19 +180,13 @@ static drmModeModeInfo *
>  test_setup(data_t *data, enum pipe pipe, uint64_t modifier, int
> flags,
>      igt_output_t *output)
>  {
> - struct kmstest_crtc crtc;
>   drmModeModeInfo *mode;
>   int size;
>   int i, x, y;
> + igt_plane_t *plane;
>  
>   igt_output_set_pipe(output, pipe);
>  
> - kmstest_get_crtc(data->drm_fd, pipe, );
> - igt_skip_on(crtc.n_planes > data-
> >display.pipes[pipe].n_planes);
> - igt_skip_on(crtc.n_planes == 0);
> -
> - for (i = 0; i < crtc.n_planes; i++)
> - data->plane[i] = igt_output_get_plane(output,
> crtc.planes[i].index);
>  
>   mode = igt_output_get_mode(output);
>  
> @@ -206,13 +196,14 @@ test_setup(data_t *data, enum pipe pipe,
> uint64_t modifier, int flags,
>   0.0, 0.0, 1.0,
>   >fb[0]);
>  
> - igt_plane_set_fb(data->plane[0], >fb[0]);
> -
>   /* yellow sprite plane in 

[Intel-gfx] Updated drm-intel-testing

[Jani Nikula]

Hi all,

The following changes tagged drm-intel-testing-2017-10-23:

drm-intel-next-2017-10-23:
This time really the last i915 batch for v4.15:

- PSR state tracking in crtc state (Ville)
- Fix eviction when the GGTT is idle but full (Chris)
- BDW DP aux channel timeout fix (James)
- LSPCON detection fixes (Shashank)
- Use for_each_pipe to iterate over pipes (Mika Kahola)
- Replace *_reference/unreference() or *_ref/unref with _get/put() (Harsha)
- Refactoring and preparation for DDI encoder type cleanup (Ville)
- Broadwell DDI FDI buf translation fix (Chris)
- Read CSB and CSB write pointer from HWSP in GVT-g VM if available (Weinan)
- GuC/HuC firmware loader refactoring (Michal)
- Make shrinking more effective and not stall so much (Chris)
- Cannonlake PLL fixes (Rodrigo)
- DP MST connector error propagation fixes (James)
- Convert timers to use timer_setup (Kees Cook)
- Skylake plane enable/disable unification (Juha-Pekka)
- Fix to actually free driver internal objects when requested (Chris)
- DDI buf trans refactoring (Ville)
- Skip waking the device to service pwrite (Chris)
- Improve DSI VBT backlight parsing abstraction (Madhav)
- Cannonlake VBT DDC pin mapping fix (Rodrigo)

BR,
Jani.


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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/fbdev: Panel orientation connector property support (rev2)

[Patchwork]

== Series Details ==

Series: drm/fbdev: Panel orientation connector property support (rev2)
URL   : https://patchwork.freedesktop.org/series/32447/
State : failure

== Summary ==

Series 32447v2 drm/fbdev: Panel orientation connector property support
https://patchwork.freedesktop.org/api/1.0/series/32447/revisions/2/mbox/

Test gem_exec_reloc:
Subgroup basic-softpin:
incomplete -> PASS   (fi-byt-j1900) fdo#103411
Test drv_module_reload:
Subgroup basic-no-display:
pass   -> FAIL   (fi-snb-2520m)

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:446s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:448s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:371s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:523s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:263s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:496s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:499s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:505s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:477s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:551s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:418s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:250s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:578s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:445s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:430s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:440s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:498s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:457s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:498s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:576s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:479s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:586s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:543s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:458s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:650s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:525s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:497s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:460s
fi-snb-2520m total:289  pass:249  dwarn:0   dfail:0   fail:1   skip:39  
time:596s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:421s

93e5fc11a47aaf43e7cb10fab23d459163bb735b drm-tip: 2017y-10m-23d-06h-23m-22s UTC 
integration manifest
bbcc23fa3d3e fbcon: Remove dmi quirk table
7b229c3756f8 efifb: Set info->fbcon_rotate_hint based on 
drm_get_panel_orientation_quirk
6fbceafb86c3 drm/i915: Add "panel orientation" property to the panel connector
ba26abae2d99 drm/fb-helper: Apply panel orientation connector prop to the 
primary plane
6cce10152489 drm: Add support for a panel-orientation connector property
86af0d99c58f drm: Add panel orientation quirks
c98ef8cf9994 fbcon: Add fbcon_rotate_hint to struct fb_info

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6139/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_atomic_transition: Make tests pass

[Petri Latvala]

On Fri, Oct 20, 2017 at 03:24:15PM +0200, Maarten Lankhorst wrote:

Subject: [Intel-gfx] [PATCH i-g-t] tests/kms_atomic_transition: Make tests pass


You have an excellent explanation of what this patch does in the long
description, and yet this short description says nothing of value.



-- 
Petri Latvala


> kms_atomic_transition was updating already disabled planes and committing
> them nonblockingly. This results in sporadic -EBUSY failures because
> planes that are unbound have their own timeline.
> 
> The solution is not unbinding already unbound planes, making the test
> pass. There is also a related kernel bug causing failures in the same
> way, but that will get fixed soon.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102671
> Signed-off-by: Maarten Lankhorst 
> ---
>  tests/kms_atomic_transition.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
> index 7ddb65cea183..4c295125a8a7 100644
> --- a/tests/kms_atomic_transition.c
> +++ b/tests/kms_atomic_transition.c
> @@ -134,7 +134,8 @@ wm_setup_plane(igt_display_t *display, enum pipe pipe,
>   int i = plane->index;
>  
>   if (!((1 << plane->index) & mask)) {
> - igt_plane_set_fb(plane, NULL);
> + if (plane->values[IGT_PLANE_FB_ID])
> + igt_plane_set_fb(plane, NULL);
>   continue;
>   }
>  
> @@ -388,11 +389,13 @@ static void wait_for_transition(igt_display_t *display, 
> enum pipe pipe, bool non
>   if (fencing) {
>   int fence_fd = display->pipes[pipe].out_fence_fd;
>  
> - igt_assert_neq(fd_completed(fence_fd), nonblocking);
> + if (!nonblocking)
> + igt_assert(fd_completed(fence_fd));
>  
>   igt_assert(sync_fence_wait(fence_fd, 3) == 0);
>   } else {
> - igt_assert_neq(fd_completed(display->drm_fd), nonblocking);
> + if (!nonblocking)
> + igt_assert(fd_completed(display->drm_fd));
>  
>   drmHandleEvent(display->drm_fd, _events);
>   }
> -- 
> 2.14.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_eio: Skip in-flight-suspend on snb

[Martin Peres]

On 20/10/17 12:26, Joonas Lahtinen wrote:
> + Petri
> 
> On Thu, 2017-10-19 at 16:29 +0300, Martin Peres wrote:
>> On 19/10/17 12:51, Daniel Vetter wrote:
>>> CI gets upset about it resulting in an incomplete, let's skip it until
>>> that's fixed to avoid havoc in the CI farm. Of course this should/will
>>> be reverted as soon as we have a fix (similar to how we dealt with the
>>> snb-dies-in-blt-hangs issue).
>>>
>>> Cc: Joonas Lahtinen 
>>> Cc: Chris Wilson 
>>> Cc: "Lofstedt, Marta" 
>>> Cc: Martin Peres 
>>> References: 
>>> https://intel-gfx-ci.01.org/tree/drm-tip/igt@gem_...@in-flight-suspend.html
>>> References: https://bugs.freedesktop.org/show_bug.cgi?id=103289
>>> Signed-off-by: Daniel Vetter 
> 
> 
> 
>> So, let's recap the problem here:
>>   - Any incomplete in sharded runs mean that the platform is unfit for 
>> pre-merge (because any other test after will go from pass to notrun)
>>   - We can't fix issues immediately, especially for old platforms
>>
>> This patch is sweeping the test under the rug by using the skip output, 
>> which is not only hard to track, it is also misleading.
>>
>> After discussing with Marta, Arek and Petri, we found some consensus on 
>> the following proposal (terminology is up for debate):
>>
>> - Introduce igt_dodge_on(cond, label): Report a pre-emptive 'fail' when 
>> the condition is true. Make sure this is over-ridable with IGT_DODGE=0 
>> so as we can easily run these tests without recompiling them.
> 
> Make this igt_skip_on_ci(cond) and require IGT_CI=1 to activate them.
> Much like with simulation.

replace skip with fail, and we agree. Skips are too easy to ignore!

> 
> Still, a BIOS update to one of the CI machines might mean (if it's not
> now the case, not very far fetched for the future) that we go churn in
> the IGT codebase to drop bunch of these. That's not the optimal
> workflow I can think of when we're discussing a separate mailing list
> for IGT discussion and patches to make it more self-contained. Then we
> bind that new mailing list to our CI farm contents, and bind making
> fixes to the CI farm operation directly to the IGT reviewing bandwidth?

Isn't what we are proposing doing exactly this? By changing the source
code of IGT, we allow people to send patches to remove some workarounds
and see if they pass or fail in the same way they would propose any
change to IGT. Moreover, we make the running of IGT in our farm as
transparent as possible.

> 
> I'm still thinking best way would be that CI would mask the known
> problematic ones from the failure/pass criteria, and then somebody
> actually looks at the masked on after their testing coverage is
> prioritized. I think IGT should try to provide a wide range of tests
> that are supposed to work on any certain hardware. If they don't, it's
> not a reason to change the tests itself.

This is true that some skips will be highly-machine specific, but isn't
our role as developers to know what and what doesn't work? By pushing
this to an external whitelist only for CI, we miss an opportunity to
improve this CI blacklist.

Now, let me remind you that this blacklist is *only* for tests that hang
the machine or leave it in an inconsistant state which will lead to a
crash later.

> 
> With the filter, we can grow the testing coverage for the new
> platforms, even if CI happens to have odd machines that may not pass
> those tests (and we may not have the resources to immediately fix
> those). All this without churning on the IGT codebase.

You are describing what cibuglog is already doing. Failing tests cases
are suppressed in pre-merge, and associated bugs[1].

See above for what this proposal is about.

[1] https://intel-gfx-ci.01.org/cibuglog/

> 
> But if this is the only technically viable solution in short-term, then
> so be it. I just see better options too.

Maybe we need a write up our workflow. This time, a public one!

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

[Intel-gfx] [PATCH v4 5/7] drm/i915: Add "panel orientation" property to the panel connector

[Hans de Goede]

Ideally we could use the VBT for this, that would be simple, in
intel_dsi_init() check dev_priv->vbt.dsi.config->rotation, set
connector->display_info.panel_orientation accordingly and call
drm_connector_init_panel_orientation_property(), done.

Unfortunately vbt.dsi.config->rotation is always 0 even on tablets
with an upside down LCD and where the GOP is properly rotating the
EFI fb in hardware.

So instead we end up reading the rotation from the primary plane.
To read the info from the primary plane, we need to know which crtc
the panel is hooked up to, so we do this the first time the panel
encoder's get_config function get called, as by then the encoder
crtc routing has been set up.

This commit only implements the panel orientation property for DSI
panels on BYT / CHT / BXT hardware, as all known non normal oriented
panels are only found on this hardware.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Read back the rotation applied by the GOP from the primary plane
 instead of relying on dev_priv->vbt.dsi.config->rotation, because it
 seems that the VBT rotation filed is always 0 even on devices where the
 GOP does apply a rotation

Changes in v3:
-Rewrite the code to read back the orientation from the primary
 plane to contain all of this in intel_dsi.c instead of poking a bunch
 of holes between all the different layers
---
 drivers/gpu/drm/i915/intel_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_dsi.c   | 48 ++
 drivers/gpu/drm/i915/intel_dsi.h   |  2 ++
 drivers/gpu/drm/i915/intel_panel.c | 16 +
 4 files changed, 67 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 47d022d48718..11efc6cb74c8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1727,6 +1727,7 @@ void intel_panel_enable_backlight(const struct 
intel_crtc_state *crtc_state,
  const struct drm_connector_state *conn_state);
 void intel_panel_disable_backlight(const struct drm_connector_state 
*old_conn_state);
 void intel_panel_destroy_backlight(struct drm_connector *connector);
+void intel_panel_set_orientation(struct intel_panel *panel, int orientation);
 enum drm_connector_status intel_panel_detect(struct drm_i915_private 
*dev_priv);
 extern struct drm_display_mode *intel_find_panel_downclock(
struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 83f15848098a..3e2f12db8d15 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1084,13 +1084,16 @@ static void bxt_dsi_get_pipe_config(struct 
intel_encoder *encoder,
struct drm_display_mode *adjusted_mode_sw;
struct intel_crtc *intel_crtc;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
+   struct intel_panel *panel = _dsi->attached_connector->panel;
unsigned int lane_count = intel_dsi->lane_count;
unsigned int bpp, fmt;
+   int orientation;
enum port port;
u16 hactive, hfp, hsync, hbp, vfp, vsync, vbp;
u16 hfp_sw, hsync_sw, hbp_sw;
u16 crtc_htotal_sw, crtc_hsync_start_sw, crtc_hsync_end_sw,
crtc_hblank_start_sw, crtc_hblank_end_sw;
+   u32 val;
 
/* FIXME: hw readout should not depend on SW state */
intel_crtc = to_intel_crtc(encoder->base.crtc);
@@ -1234,6 +1237,49 @@ static void bxt_dsi_get_pipe_config(struct intel_encoder 
*encoder,
if (adjusted_mode->crtc_hblank_end == crtc_hblank_end_sw)
adjusted_mode->crtc_hblank_end =
adjusted_mode_sw->crtc_hblank_end;
+
+   if (!intel_dsi->got_panel_orientation) {
+   val = I915_READ(PLANE_CTL(intel_crtc->pipe, 0));
+   /* The rotation is used to correct for the panel orientation */
+   switch (val & PLANE_CTL_ROTATE_MASK) {
+   case PLANE_CTL_ROTATE_0:
+   orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
+   break;
+   case PLANE_CTL_ROTATE_90:
+   orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP;
+   break;
+   case PLANE_CTL_ROTATE_180:
+   orientation = DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
+   break;
+   case PLANE_CTL_ROTATE_270:
+   orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP;
+   break;
+   }
+   intel_panel_set_orientation(panel, orientation);
+   intel_dsi->got_panel_orientation = true;
+   }
+}
+
+static void vlv_dsi_get_pipe_config(struct intel_encoder *encoder)
+{
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
+   struct 

[Intel-gfx] [PATCH v4 4/7] drm/fb-helper: Apply panel orientation connector prop to the primary plane

[Hans de Goede]

Apply the "panel orientation" drm connector prop to the primary plane so
that fbcon and fbdev using userspace programs display the right way up.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=94894
Signed-off-by: Hans de Goede 
---
Changes in v2:
-New patch in v2 of this patch-set

Changes in v3:
-Use a rotation member in struct drm_fb_helper_crtc and set that from
 drm_setup_crtcs instead of looping over all crtc's to find the right one
 later
-Since we now no longer look at rotation quirks directly in the fbcon
 code, set fb_info.fbcon_rotate_hint when the panel is not mounted upright
 and we cannot use hardware rotation

Changes in v4:
-Make drm_fb_helper_init() init drm_fb_helper_crtc.rotation to
 DRM_MODE_ROTATE_0 for all crtcs, so that we do not end up setting the
 plane_state's rotation to an invalid value for disabled crtcs
 (caught by Fi.CI)
---
 drivers/gpu/drm/drm_fb_helper.c | 77 +++--
 include/drm/drm_fb_helper.h |  8 +
 2 files changed, 83 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 116d1f1337c7..b5d075fbd3a5 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 
+#include "drm_crtc_internal.h"
 #include "drm_crtc_helper_internal.h"
 
 static bool drm_fbdev_emulation = true;
@@ -350,6 +351,7 @@ EXPORT_SYMBOL(drm_fb_helper_debug_leave);
 static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper, bool 
active)
 {
struct drm_device *dev = fb_helper->dev;
+   struct drm_plane_state *plane_state;
struct drm_plane *plane;
struct drm_atomic_state *state;
int i, ret;
@@ -368,8 +370,6 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper 
*fb_helper, bool activ
 retry:
plane_mask = 0;
drm_for_each_plane(plane, dev) {
-   struct drm_plane_state *plane_state;
-
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state)) {
ret = PTR_ERR(plane_state);
@@ -392,6 +392,11 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper 
*fb_helper, bool activ
 
for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_mode_set *mode_set = 
_helper->crtc_info[i].mode_set;
+   struct drm_plane *primary = mode_set->crtc->primary;
+
+   /* Cannot fail as we've already gotten the plane state above */
+   plane_state = drm_atomic_get_new_plane_state(state, primary);
+   plane_state->rotation = fb_helper->crtc_info[i].rotation;
 
ret = __drm_atomic_helper_set_config(mode_set, state);
if (ret != 0)
@@ -821,6 +826,7 @@ int drm_fb_helper_init(struct drm_device *dev,
if (!fb_helper->crtc_info[i].mode_set.connectors)
goto out_free;
fb_helper->crtc_info[i].mode_set.num_connectors = 0;
+   fb_helper->crtc_info[i].rotation = DRM_MODE_ROTATE_0;
}
 
i = 0;
@@ -2334,6 +2340,57 @@ static int drm_pick_crtcs(struct drm_fb_helper 
*fb_helper,
return best_score;
 }
 
+/*
+ * This function checks if rotation is necessary because of panel orientation
+ * and if it is, if it is supported.
+ * If rotation is necessary and supported, its gets set in fb_crtc.rotation.
+ * If rotation is necessary but not supported, a DRM_MODE_ROTATE_* flag gets
+ * or-ed into fb_helper->rotations. In drm_setup_crtcs_fb() we check if only
+ * one bit is set and then we set fb_info.fbcon_rotate_hint to make fbcon do
+ * the unsupported rotation.
+ */
+static void drm_setup_crtc_rotation(struct drm_fb_helper *fb_helper,
+   struct drm_fb_helper_crtc *fb_crtc,
+   struct drm_connector *connector)
+{
+   struct drm_plane *plane = fb_crtc->mode_set.crtc->primary;
+   uint64_t valid_mask = 0;
+   int i, rotation;
+
+   fb_crtc->rotation = DRM_MODE_ROTATE_0;
+
+   switch (connector->display_info.panel_orientation) {
+   case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
+   rotation = DRM_MODE_ROTATE_180;
+   break;
+   case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
+   rotation = DRM_MODE_ROTATE_90;
+   break;
+   case DRM_MODE_PANEL_ORIENTATION_RIGHT_UP:
+   rotation = DRM_MODE_ROTATE_270;
+   break;
+   default:
+   rotation = DRM_MODE_ROTATE_0;
+   }
+
+   if (rotation == DRM_MODE_ROTATE_0 || !plane->rotation_property) {
+   fb_helper->rotations |= rotation;
+   return;
+   }
+
+   for (i = 0; i < plane->rotation_property->num_values; i++)
+   valid_mask |= (1ULL << plane->rotation_property->values[i]);
+
+   if (!(rotation & valid_mask)) {
+   fb_helper->rotations |= 

[Intel-gfx] [PATCH v4 7/7] fbcon: Remove dmi quirk table

[Hans de Goede]

This is now all handled in the drivers and communicated through
fb_info.fbcon_rotate_hint.

Signed-off-by: Hans de Goede 
---
 drivers/video/fbdev/core/Makefile   |   3 -
 drivers/video/fbdev/core/fbcon.c|   4 +-
 drivers/video/fbdev/core/fbcon.h|   6 --
 drivers/video/fbdev/core/fbcon_dmi_quirks.c | 145 
 4 files changed, 2 insertions(+), 156 deletions(-)
 delete mode 100644 drivers/video/fbdev/core/fbcon_dmi_quirks.c

diff --git a/drivers/video/fbdev/core/Makefile 
b/drivers/video/fbdev/core/Makefile
index 73493bbd7a15..0214b863ac3f 100644
--- a/drivers/video/fbdev/core/Makefile
+++ b/drivers/video/fbdev/core/Makefile
@@ -14,9 +14,6 @@ ifeq ($(CONFIG_FRAMEBUFFER_CONSOLE_ROTATION),y)
 fb-y += fbcon_rotate.o fbcon_cw.o fbcon_ud.o \
 fbcon_ccw.o
 endif
-ifeq ($(CONFIG_DMI),y)
-fb-y += fbcon_dmi_quirks.o
-endif
 endif
 fb-objs   := $(fb-y)
 
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index fb317ed76b45..157a40670a47 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -968,7 +968,7 @@ static const char *fbcon_startup(void)
if (p->con_rotate == -1)
p->con_rotate = info->fbcon_rotate_hint;
if (p->con_rotate == -1)
-   p->con_rotate = fbcon_platform_get_rotate(info);
+   p->con_rotate = FB_ROTATE_UR;
 
set_blitting_type(vc, info);
 
@@ -,7 +,7 @@ static void fbcon_init(struct vc_data *vc, int init)
if (p->con_rotate == -1)
p->con_rotate = info->fbcon_rotate_hint;
if (p->con_rotate == -1)
-   p->con_rotate = fbcon_platform_get_rotate(info);
+   p->con_rotate = FB_ROTATE_UR;
 
set_blitting_type(vc, info);
 
diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
index 18f3ac144237..3746828356ed 100644
--- a/drivers/video/fbdev/core/fbcon.h
+++ b/drivers/video/fbdev/core/fbcon.h
@@ -261,10 +261,4 @@ extern void fbcon_set_rotate(struct fbcon_ops *ops);
 #define fbcon_set_rotate(x) do {} while(0)
 #endif /* CONFIG_FRAMEBUFFER_CONSOLE_ROTATION */
 
-#ifdef CONFIG_DMI
-int fbcon_platform_get_rotate(struct fb_info *info);
-#else
-#define fbcon_platform_get_rotate(i) FB_ROTATE_UR
-#endif /* CONFIG_DMI */
-
 #endif /* _VIDEO_FBCON_H */
diff --git a/drivers/video/fbdev/core/fbcon_dmi_quirks.c 
b/drivers/video/fbdev/core/fbcon_dmi_quirks.c
deleted file mode 100644
index 6904e47d1e51..
--- a/drivers/video/fbdev/core/fbcon_dmi_quirks.c
+++ /dev/null
@@ -1,145 +0,0 @@
-/*
- *  fbcon_dmi_quirks.c -- DMI based quirk detection for fbcon
- *
- * Copyright (C) 2017 Hans de Goede 
- *
- *  This file is subject to the terms and conditions of the GNU General Public
- *  License.  See the file COPYING in the main directory of this archive for
- *  more details.
- */
-
-#include 
-#include 
-#include 
-#include "fbcon.h"
-
-/*
- * Some x86 clamshell design devices use portrait tablet screens and a display
- * engine which cannot rotate in hardware, so we need to rotate the fbcon to
- * compensate. Unfortunately these (cheap) devices also typically have quite
- * generic DMI data, so we match on a combination of DMI data, screen 
resolution
- * and a list of known BIOS dates to avoid false positives.
- */
-
-struct fbcon_dmi_rotate_data {
-   int width;
-   int height;
-   const char * const *bios_dates;
-   int rotate;
-};
-
-static const struct fbcon_dmi_rotate_data rotate_data_asus_t100ha = {
-   .width = 800,
-   .height = 1280,
-   .rotate = FB_ROTATE_CCW,
-};
-
-static const struct fbcon_dmi_rotate_data rotate_data_gpd_pocket = {
-   .width = 1200,
-   .height = 1920,
-   .bios_dates = (const char * const []){ "05/26/2017", "06/28/2017",
-   "07/05/2017", "08/07/2017", NULL },
-   .rotate = FB_ROTATE_CW,
-};
-
-static const struct fbcon_dmi_rotate_data rotate_data_gpd_win = {
-   .width = 720,
-   .height = 1280,
-   .bios_dates = (const char * const []){
-   "10/25/2016", "11/18/2016", "12/23/2016", "12/26/2016",
-   "02/21/2017", "03/20/2017", "05/25/2017", NULL },
-   .rotate = FB_ROTATE_CW,
-};
-
-static const struct fbcon_dmi_rotate_data rotate_data_itworks_tw891 = {
-   .width = 800,
-   .height = 1280,
-   .bios_dates = (const char * const []){ "10/16/2015", NULL },
-   .rotate = FB_ROTATE_CW,
-};
-
-static const struct fbcon_dmi_rotate_data rotate_data_vios_lth17 = {
-   .width = 800,
-   .height = 1280,
-   .rotate = FB_ROTATE_CW,
-};
-
-static const struct dmi_system_id rotate_data[] = {
-   {   /* Asus T100HA */
-   .matches = {
- DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
-   

[Intel-gfx] [PATCH v4 2/7] drm: Add panel orientation quirks

[Hans de Goede]

Some x86 clamshell design devices use portrait tablet screens and a display
engine which cannot rotate in hardware, so the firmware just leaves things
as is and we cannot figure out that the display is oriented non upright
from the hardware.

So at least on x86, we need a quirk table for this. This commit adds a DMI
based quirk table which is initially populated with 5 such devices: Asus
T100HA, GPD Pocket, GPD win, I.T.Works TW891 and the VIOS LTH17.

This quirk table will be used by the drm code to let userspace know that
the display is not mounted upright inside the devices case through a new
panel orientation drm-connector property, as well as to tell fbcon to
rotate the console so that it shows the right way up.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/Kconfig|   3 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/drm_panel_orientation_quirks.c | 157 +
 include/drm/drm_utils.h|  18 +++
 4 files changed, 179 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_panel_orientation_quirks.c
 create mode 100644 include/drm/drm_utils.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 4d9f21831741..9d005ac98c2b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -26,6 +26,9 @@ config DRM_MIPI_DSI
bool
depends on DRM
 
+config DRM_PANEL_ORIENTATION_QUIRKS
+   tristate
+
 config DRM_DP_AUX_CHARDEV
bool "DRM DP AUX Interface"
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index a3fdc5a68dff..ffb621819bbf 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/
 
 obj-$(CONFIG_DRM)  += drm.o
 obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
+obj-$(CONFIG_DRM_PANEL_ORIENTATION_QUIRKS) += drm_panel_orientation_quirks.o
 obj-$(CONFIG_DRM_ARM)  += arm/
 obj-$(CONFIG_DRM_TTM)  += ttm/
 obj-$(CONFIG_DRM_TDFX) += tdfx/
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
new file mode 100644
index ..cea4d71f4978
--- /dev/null
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -0,0 +1,157 @@
+/*
+ *  drm_panel_orientation_quirks.c -- Quirks for non-normal panel orientation
+ *
+ * Copyright (C) 2017 Hans de Goede 
+ *
+ *  This file is subject to the terms and conditions of the GNU General Public
+ *  License.  See the file COPYING in the main directory of this archive for
+ *  more details.
+ */
+
+#include 
+#include 
+
+#ifdef CONFIG_DMI
+
+/*
+ * Some x86 clamshell design devices use portrait tablet screens and a display
+ * engine which cannot rotate in hardware, so we need to rotate the fbcon to
+ * compensate. Unfortunately these (cheap) devices also typically have quite
+ * generic DMI data, so we match on a combination of DMI data, screen 
resolution
+ * and a list of known BIOS dates to avoid false positives.
+ */
+
+struct drm_dmi_panel_orientation_data {
+   int width;
+   int height;
+   const char * const *bios_dates;
+   int orientation;
+};
+
+static const struct drm_dmi_panel_orientation_data asus_t100ha = {
+   .width = 800,
+   .height = 1280,
+   .orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP,
+};
+
+static const struct drm_dmi_panel_orientation_data gpd_pocket = {
+   .width = 1200,
+   .height = 1920,
+   .bios_dates = (const char * const []){ "05/26/2017", "06/28/2017",
+   "07/05/2017", "08/07/2017", NULL },
+   .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
+static const struct drm_dmi_panel_orientation_data gpd_win = {
+   .width = 720,
+   .height = 1280,
+   .bios_dates = (const char * const []){
+   "10/25/2016", "11/18/2016", "12/23/2016", "12/26/2016",
+   "02/21/2017", "03/20/2017", "05/25/2017", NULL },
+   .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
+static const struct drm_dmi_panel_orientation_data itworks_tw891 = {
+   .width = 800,
+   .height = 1280,
+   .bios_dates = (const char * const []){ "10/16/2015", NULL },
+   .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
+static const struct drm_dmi_panel_orientation_data vios_lth17 = {
+   .width = 800,
+   .height = 1280,
+   .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
+static const struct dmi_system_id orientation_data[] = {
+   {   /* Asus T100HA */
+   .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100HAN"),
+   },
+   .driver_data = (void *)_t100ha,
+   }, {/*
+* GPD Pocket, note that the the DMI data is less generic then
+* it seems, devices with a board-vendor of "AMI 

[Intel-gfx] [PATCH v4 3/7] drm: Add support for a panel-orientation connector property

[Hans de Goede]

On some devices the LCD panel is mounted in the casing in such a way that
the up/top side of the panel does not match with the top side of the
device (e.g. it is mounted upside-down).

This commit adds the necessary infra for lcd-panel drm_connector-s to
have a "panel orientation" property to communicate how the panel is
orientated vs the casing.

Userspace can use this property to check for non-normal orientation and
then adjust the displayed image accordingly by rotating it to compensate.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Rebased on 4.14-rc1
-Store panel_orientation in drm_display_info, so that drm_fb_helper.c can
 access it easily
-Have a single drm_connector_init_panel_orientation_property rather then
 create and attach functions. The caller is expected to set
 drm_display_info.panel_orientation before calling this, then this will
 check for platform specific quirks overriding the panel_orientation and if
 the panel_orientation is set after this then it will attach the property.
---
 drivers/gpu/drm/Kconfig |  1 +
 drivers/gpu/drm/drm_connector.c | 73 +
 include/drm/drm_connector.h | 11 +++
 include/drm/drm_mode_config.h   |  7 
 include/uapi/drm/drm_mode.h |  7 
 5 files changed, 99 insertions(+)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 9d005ac98c2b..0b166e626eb6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -7,6 +7,7 @@
 menuconfig DRM
tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI 
support)"
depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
+   select DRM_PANEL_ORIENTATION_QUIRKS
select HDMI
select FB_CMDLINE
select I2C
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 704fc8934616..129c83a84320 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drm_crtc_internal.h"
 #include "drm_internal.h"
@@ -212,6 +213,8 @@ int drm_connector_init(struct drm_device *dev,
mutex_init(>mutex);
connector->edid_blob_ptr = NULL;
connector->status = connector_status_unknown;
+   connector->display_info.panel_orientation =
+   DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
 
drm_connector_get_cmdline_mode(connector);
 
@@ -664,6 +667,13 @@ static const struct drm_prop_enum_list 
drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
 };
 
+static const struct drm_prop_enum_list drm_panel_orientation_enum_list[] = {
+   { DRM_MODE_PANEL_ORIENTATION_NORMAL,"Normal"},
+   { DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP, "Upside Down"   },
+   { DRM_MODE_PANEL_ORIENTATION_LEFT_UP,   "Left Side Up"  },
+   { DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,  "Right Side Up" },
+};
+
 static const struct drm_prop_enum_list drm_dvi_i_select_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
{ DRM_MODE_SUBCONNECTOR_DVID,  "DVI-D" }, /* DVI-I  */
@@ -768,6 +778,18 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
  *
  * CRTC_ID:
  * Mode object ID of the _crtc this connector should be connected to.
+ *
+ * Connectors for LCD panels may also have one standardized property:
+ *
+ * panel orientation:
+ * On some devices the LCD panel is mounted in the casing in such a way
+ * that the up/top side of the panel does not match with the top side of
+ * the device. Userspace can use this property to check for this.
+ * Note that input coordinates from touchscreens (input devices with
+ * INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
+ * coordinates, so if userspace rotates the picture to adjust for
+ * the orientation it must also apply the same transformation to the
+ * touchscreen input coordinates.
  */
 
 int drm_connector_create_standard_properties(struct drm_device *dev)
@@ -1234,6 +1256,57 @@ void drm_mode_connector_set_link_status_property(struct 
drm_connector *connector
 }
 EXPORT_SYMBOL(drm_mode_connector_set_link_status_property);
 
+/**
+ * drm_connector_init_panel_orientation_property -
+ * initialize the connecters panel_orientation property
+ * @connector: connector for which to init the panel-orientation property.
+ * @width: width in pixels of the panel, used for panel quirk detection
+ * @height: height in pixels of the panel, used for panel quirk detection
+ *
+ * This function should only be called for built-in panels, after setting
+ * connector->display_info.panel_orientation first (if known).
+ *
+ * This function will check for platform specific (e.g. DMI based) quirks
+ * overriding display_info.panel_orientation first, then if panel_orientation
+ * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
+ * "panel orientation" property to the connector.

[Intel-gfx] [PATCH v4 0/7] drm/fbdev: Panel orientation connector property support

[Hans de Goede]

Hi All,

Here is v4 of my series to add a "panel orientation" property to
the drm-connector for the LCD panel to let userspace know about LCD
panels which are not mounted upright, as well as detecting upside-down
panels without needing quirks (like we do for 90 degree rotated screens).

New in v3:
-As requested by Daniel v3 moves the quirks over from the fbdev
 subsys to the drm subsys. I've done this by simpy starting with a copy of
 the quirk table and eventually removing the fbdev version.

New in v4:
-Fix drm_fb_helper code setting an invalid rotation value on the primary
 plane of disabled/unused crtcs (caught by Fi.CI)

The 1st patch in this series is a small fbdev/fbcon patch, patches 2-5
are all drm patches since patches 2-5 depend on patch 1 I believe it
would be best to merge patches 1-5 through the drm tree.

For merging patches 6-7 I see 3 options:

1) Wait a kernel cycle, things will work fine without them, they are really
just there to remove the fbdev copy of the quirks

2) Merge all 7 patches through the drm tree

3) Use a stable tag in the drm tree which the fbdev tree can merge and then
merge patches 6-7 through the drm tree.

Regards,

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

[Intel-gfx] [PATCH v4 6/7] efifb: Set info->fbcon_rotate_hint based on drm_get_panel_orientation_quirk

[Hans de Goede]

On some hardware the LCD panel is not mounted upright in the casing,
but rotated by 90 degrees. In this case we want the console to
automatically be rotated to compensate.

The drm subsys has a quirk table for this, use the
drm_get_panel_orientation_quirk function to get the panel orientation
and set info->fbcon_rotate_hint based on this, so that the fbcon console
on top of efifb gets automatically rotated to compensate for the panel
orientation.

Signed-off-by: Hans de Goede 
---
 drivers/video/fbdev/Kconfig |  1 +
 drivers/video/fbdev/efifb.c | 21 -
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 5e58f5ec0a28..c4a90c497839 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -772,6 +772,7 @@ config FB_VESA
 config FB_EFI
bool "EFI-based Framebuffer Support"
depends on (FB = y) && !IA64 && EFI
+   select DRM_PANEL_ORIENTATION_QUIRKS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 3a010641f630..8c7f6aeee205 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -15,6 +15,8 @@
 #include 
 #include 
 #include 
+#include  /* For drm_get_panel_orientation_quirk */
+#include   /* For DRM_MODE_PANEL_ORIENTATION_* */
 
 static bool request_mem_succeeded = false;
 static bool nowc = false;
@@ -156,7 +158,7 @@ static u64 bar_offset;
 static int efifb_probe(struct platform_device *dev)
 {
struct fb_info *info;
-   int err;
+   int err, orientation;
unsigned int size_vmode;
unsigned int size_remap;
unsigned int size_total;
@@ -328,6 +330,23 @@ static int efifb_probe(struct platform_device *dev)
info->fix = efifb_fix;
info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE;
 
+   orientation = drm_get_panel_orientation_quirk(efifb_defined.xres,
+ efifb_defined.yres);
+   switch (orientation) {
+   default:
+   info->fbcon_rotate_hint = FB_ROTATE_UR;
+   break;
+   case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
+   info->fbcon_rotate_hint = FB_ROTATE_UD;
+   break;
+   case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
+   info->fbcon_rotate_hint = FB_ROTATE_CCW;
+   break;
+   case DRM_MODE_PANEL_ORIENTATION_RIGHT_UP:
+   info->fbcon_rotate_hint = FB_ROTATE_CW;
+   break;
+   }
+
err = sysfs_create_groups(>dev.kobj, efifb_groups);
if (err) {
pr_err("efifb: cannot add sysfs attrs\n");
-- 
2.14.2

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

[Intel-gfx] [PATCH v4 1/7] fbcon: Add fbcon_rotate_hint to struct fb_info

[Hans de Goede]

On some hardware the LCD panel is not mounted upright in the casing,
but upside-down or rotated 90 degrees. In this case we want the console
to automatically be rotated to compensate.

The fbdev-driver may know about the need to rotate. Add a new
fbcon_rotate_hint field to struct fb_info, which gets initialized to -1.
If the fbdev-driver knows that some sort of rotation is necessary then
it can set this field to a FB_ROTATE_* value to tell the fbcon console
driver to rotate the console.

Signed-off-by: Hans de Goede 
---
 drivers/video/fbdev/core/fbcon.c   | 18 --
 drivers/video/fbdev/core/fbsysfs.c |  1 +
 include/linux/fb.h |  5 +
 3 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 04612f938bab..fb317ed76b45 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -963,10 +963,13 @@ static const char *fbcon_startup(void)
ops->cur_rotate = -1;
ops->cur_blink_jiffies = HZ / 5;
info->fbcon_par = ops;
-   if (initial_rotation != -1)
-   p->con_rotate = initial_rotation;
-   else
+
+   p->con_rotate = initial_rotation;
+   if (p->con_rotate == -1)
+   p->con_rotate = info->fbcon_rotate_hint;
+   if (p->con_rotate == -1)
p->con_rotate = fbcon_platform_get_rotate(info);
+
set_blitting_type(vc, info);
 
if (info->fix.type != FB_TYPE_TEXT) {
@@ -1103,10 +1106,13 @@ static void fbcon_init(struct vc_data *vc, int init)
 
ops = info->fbcon_par;
ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);
-   if (initial_rotation != -1)
-   p->con_rotate = initial_rotation;
-   else
+
+   p->con_rotate = initial_rotation;
+   if (p->con_rotate == -1)
+   p->con_rotate = info->fbcon_rotate_hint;
+   if (p->con_rotate == -1)
p->con_rotate = fbcon_platform_get_rotate(info);
+
set_blitting_type(vc, info);
 
cols = vc->vc_cols;
diff --git a/drivers/video/fbdev/core/fbsysfs.c 
b/drivers/video/fbdev/core/fbsysfs.c
index 15755ce1d26c..e31a182b42bf 100644
--- a/drivers/video/fbdev/core/fbsysfs.c
+++ b/drivers/video/fbdev/core/fbsysfs.c
@@ -58,6 +58,7 @@ struct fb_info *framebuffer_alloc(size_t size, struct device 
*dev)
info->par = p + fb_info_size;
 
info->device = dev;
+   info->fbcon_rotate_hint = -1;
 
 #ifdef CONFIG_FB_BACKLIGHT
mutex_init(>bl_curve_mutex);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index f4386b0ccf40..10cf71cc5d13 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -464,6 +464,11 @@ struct fb_info {
atomic_t count;
int node;
int flags;
+   /*
+* -1 by default, set to a FB_ROTATE_* value by the driver, if it knows
+* a lcd is not mounted upright and fbcon should rotate to compensate.
+*/
+   int fbcon_rotate_hint;
struct mutex lock;  /* Lock for open/release/ioctl funcs */
struct mutex mm_lock;   /* Lock for fb_mmap and smem_* fields */
struct fb_var_screeninfo var;   /* Current var */
-- 
2.14.2

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

Re: [Intel-gfx] [PATCH] drm/i915: Increase the busyspin durations for i915_wait_request

[Sagar Arun Kamble]

On 9/15/2017 3:48 PM, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2017-09-15 11:01:02)

On 14/09/2017 10:58, Chris Wilson wrote:

An interesting discussion regarding "hybrid interrupt polling" for NVMe
came to the conclusion that the ideal busyspin before sleeping was half
of the expected request latency (and better if it was already halfway
through that request). This suggested that we too should look again at
our tradeoff between spinning and waiting. Currently, our spin simply
tries to hide the cost of enabling the interrupt, which is good to avoid
penalising nop requests (i.e. test throughput) and not much else.
Studying real world workloads suggests that a spin of upto 500us can

What workloads and and power/perf testing?

Classic glxgears ;) People on the cc I trust to give a solid yay/nay.
Perf runs on SKL show improvements on some of the CL and media 
benchmarks without impacting power.
On APL, perf is not impacted but core power increase is observed. This 
observation is present w/ and w/o GuC.
More benefit of this approach with GuC can be observed by disabling 
RC6/CPG. I had tested xcompbench offscreen benchmark
with GuC on APL with this change and RC6 disabled and had observed 
substantial improvements.

dramatically boost performance, but the suggestion is that this is not
from avoiding interrupt latency per-se, but from secondary effects of
sleeping such as allowing the CPU reduce cstate and context switch away.

Maybe the second part of the sentence would be clearer if not in a way
in inverted form. Like longer spin = more performance = less sleeping =
less cstate switching? Or just add "but from _avoiding_ secondary
effects of sleeping"?


To offset those costs from penalising the active client, bump the initial
spin somewhat to 250us and the secondary spin to 20us to balance the cost
of another context switch following the interrupt.

Suggested-by: Sagar Kamble 
Signed-off-by: Chris Wilson 
Cc: Sagar Kamble 
Cc: Eero Tamminen 
Cc: Tvrtko Ursulin 
Cc: Ben Widawsky 
Cc: Joonas Lahtinen 

The change looks good to me (w.r.t old drm-tip)
Reviewed-by: Sagar Arun Kamble 

---
   drivers/gpu/drm/i915/i915_gem_request.c | 25 +
   1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 813a3b546d6e..ccbdaf6a0e4d 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -1155,8 +1155,20 @@ long i915_wait_request(struct drm_i915_gem_request *req,
   GEM_BUG_ON(!intel_wait_has_seqno());
   GEM_BUG_ON(!i915_sw_fence_signaled(>submit));
   
- /* Optimistic short spin before touching IRQs */

- if (i915_spin_request(req, state, 5))
+ /* Optimistic short spin before touching IRQs.

So it's not short any more. "Optimistic busy spin" ?


+  *
+  * We use a rather large value here to offset the penalty of switching
+  * away from the active task. Frequently, the client will wait upon
+  * an old swapbuffer to throttle itself to remain within a frame of
+  * the gpu. If the client is running in lockstep with the gpu, then
+  * it should not be waiting long at all, and a sleep now will incur
+  * extra scheduler latency in producing the next frame. So we sleep
+  * for longer to try and keep the client running.
+  *

250us sounds quite long and worrying to me.

Yes. It's the sort of level where we are applying an artificial load to
the CPU to encourage turbo...

20us, I'm happier with; that does tally well with the latencies we can
measure from interrupt to process. 250us and we're well into secondary
effects that we should not be messing with (at least not like this).

Otoh, at 250us it might be interesting to play with monitor/mwait.
  

In the waiting on swapbuffer case, what are the clients waiting for? GPU
rendering to finish or previous vblank or something?

It's throttling the swap queue, so previous frame.
  

I am thinking if it would be possible to add a special API just for this
sort of waits and internally know how long it is likely to take. So then
decide based on that whether to spin or sleep. Like next vblank is
coming in 5ms, no point in busy spinning or something like that.

We have one; THROTTLE. For the user, it is too imprecise (we could
argument it with a timeout parameter, but...) as it doesn't wait for an
explicit event. GL ideally tries to ensure the render pipeline is full
but never more than a completed frame in advance. (That pipeline depth
could be specified by the client.) You've seen the same effect in wsim,
where if you just let a client fill up 20ms of batches, that can block
the GPU for seconds, but again a limit upon client batches enforces rr.
We've 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/fbdev: Panel orientation connector property support

[Patchwork]

== Series Details ==

Series: drm/fbdev: Panel orientation connector property support
URL   : https://patchwork.freedesktop.org/series/32447/
State : failure

== Summary ==

Test kms_properties:
Subgroup plane-properties-atomic:
pass   -> FAIL   (shard-hsw)
Subgroup plane-properties-legacy:
pass   -> FAIL   (shard-hsw)
Test kms_busy:
Subgroup extended-modeset-hang-oldfb-with-reset-render-C:
dmesg-warn -> PASS   (shard-hsw) fdo#102249

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

shard-hswtotal:2540 pass:1428 dwarn:1   dfail:0   fail:10  skip:1101 
time:9210s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6138/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/fbdev: Panel orientation connector property support

[Hans de Goede]

Hi,

On 23-10-17 09:33, Patchwork wrote:

== Series Details ==

Series: drm/fbdev: Panel orientation connector property support
URL   : https://patchwork.freedesktop.org/series/32447/
State : warning


Ok, I think I know where the warnings are coming from, v4 coming up.

Regards,

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/fbdev: Panel orientation connector property support

[Patchwork]

== Series Details ==

Series: drm/fbdev: Panel orientation connector property support
URL   : https://patchwork.freedesktop.org/series/32447/
State : warning

== Summary ==

Series 32447v1 drm/fbdev: Panel orientation connector property support
https://patchwork.freedesktop.org/api/1.0/series/32447/revisions/1/mbox/

Test gem_exec_reloc:
Subgroup basic-softpin:
incomplete -> PASS   (fi-byt-j1900)
Test kms_busy:
Subgroup basic-flip-b:
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-bxt-dsi)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-kbl-7567u)
pass   -> DMESG-WARN (fi-kbl-r)
pass   -> DMESG-WARN (fi-glk-1)
Subgroup basic-flip-c:
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-bxt-dsi)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-kbl-7567u)
pass   -> DMESG-WARN (fi-kbl-r)
pass   -> DMESG-WARN (fi-glk-1)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6700hq) fdo#103124
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-bxt-dsi)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#102392 +2
pass   -> DMESG-WARN (fi-kbl-7567u)
pass   -> DMESG-WARN (fi-kbl-r)
pass   -> DMESG-WARN (fi-glk-1)
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-bxt-dsi)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-kbl-7567u)
pass   -> DMESG-WARN (fi-kbl-r)
pass   -> DMESG-WARN (fi-glk-1)
Subgroup basic-flip-vs-wf_vblank:
pass   -> DMESG-WARN (fi-skl-6260u) fdo#102035 +7
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-bxt-dsi)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-kbl-7567u)
pass   -> DMESG-WARN (fi-kbl-r)
Subgroup basic-plain-flip:
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-bxt-dsi)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-kbl-7567u)
pass   -> DMESG-WARN (fi-kbl-r)
pass   -> DMESG-WARN (fi-glk-1)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-bxt-dsi)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-kbl-7567u)
pass   -> DMESG-WARN (fi-kbl-r)
pass   -> DMESG-WARN (fi-glk-1)
Subgroup hang-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-bxt-dsi)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> 

[Intel-gfx] [PATCH v3 3/7] drm: Add support for a panel-orientation connector property

[Hans de Goede]

On some devices the LCD panel is mounted in the casing in such a way that
the up/top side of the panel does not match with the top side of the
device (e.g. it is mounted upside-down).

This commit adds the necessary infra for lcd-panel drm_connector-s to
have a "panel orientation" property to communicate how the panel is
orientated vs the casing.

Userspace can use this property to check for non-normal orientation and
then adjust the displayed image accordingly by rotating it to compensate.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Rebased on 4.14-rc1
-Store panel_orientation in drm_display_info, so that drm_fb_helper.c can
 access it easily
-Have a single drm_connector_init_panel_orientation_property rather then
 create and attach functions. The caller is expected to set
 drm_display_info.panel_orientation before calling this, then this will
 check for platform specific quirks overriding the panel_orientation and if
 the panel_orientation is set after this then it will attach the property.
---
 drivers/gpu/drm/Kconfig |  1 +
 drivers/gpu/drm/drm_connector.c | 73 +
 include/drm/drm_connector.h | 11 +++
 include/drm/drm_mode_config.h   |  7 
 include/uapi/drm/drm_mode.h |  7 
 5 files changed, 99 insertions(+)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 9d005ac98c2b..0b166e626eb6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -7,6 +7,7 @@
 menuconfig DRM
tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI 
support)"
depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
+   select DRM_PANEL_ORIENTATION_QUIRKS
select HDMI
select FB_CMDLINE
select I2C
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 704fc8934616..129c83a84320 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drm_crtc_internal.h"
 #include "drm_internal.h"
@@ -212,6 +213,8 @@ int drm_connector_init(struct drm_device *dev,
mutex_init(>mutex);
connector->edid_blob_ptr = NULL;
connector->status = connector_status_unknown;
+   connector->display_info.panel_orientation =
+   DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
 
drm_connector_get_cmdline_mode(connector);
 
@@ -664,6 +667,13 @@ static const struct drm_prop_enum_list 
drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
 };
 
+static const struct drm_prop_enum_list drm_panel_orientation_enum_list[] = {
+   { DRM_MODE_PANEL_ORIENTATION_NORMAL,"Normal"},
+   { DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP, "Upside Down"   },
+   { DRM_MODE_PANEL_ORIENTATION_LEFT_UP,   "Left Side Up"  },
+   { DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,  "Right Side Up" },
+};
+
 static const struct drm_prop_enum_list drm_dvi_i_select_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
{ DRM_MODE_SUBCONNECTOR_DVID,  "DVI-D" }, /* DVI-I  */
@@ -768,6 +778,18 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
  *
  * CRTC_ID:
  * Mode object ID of the _crtc this connector should be connected to.
+ *
+ * Connectors for LCD panels may also have one standardized property:
+ *
+ * panel orientation:
+ * On some devices the LCD panel is mounted in the casing in such a way
+ * that the up/top side of the panel does not match with the top side of
+ * the device. Userspace can use this property to check for this.
+ * Note that input coordinates from touchscreens (input devices with
+ * INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
+ * coordinates, so if userspace rotates the picture to adjust for
+ * the orientation it must also apply the same transformation to the
+ * touchscreen input coordinates.
  */
 
 int drm_connector_create_standard_properties(struct drm_device *dev)
@@ -1234,6 +1256,57 @@ void drm_mode_connector_set_link_status_property(struct 
drm_connector *connector
 }
 EXPORT_SYMBOL(drm_mode_connector_set_link_status_property);
 
+/**
+ * drm_connector_init_panel_orientation_property -
+ * initialize the connecters panel_orientation property
+ * @connector: connector for which to init the panel-orientation property.
+ * @width: width in pixels of the panel, used for panel quirk detection
+ * @height: height in pixels of the panel, used for panel quirk detection
+ *
+ * This function should only be called for built-in panels, after setting
+ * connector->display_info.panel_orientation first (if known).
+ *
+ * This function will check for platform specific (e.g. DMI based) quirks
+ * overriding display_info.panel_orientation first, then if panel_orientation
+ * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
+ * "panel orientation" property to the connector.

[Intel-gfx] [PATCH v3 4/7] drm/fb-helper: Apply panel orientation connector prop to the primary plane

[Hans de Goede]

Apply the "panel orientation" drm connector prop to the primary plane so
that fbcon and fbdev using userspace programs display the right way up.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=94894
Signed-off-by: Hans de Goede 
---
Changes in v2:
-New patch in v2 of this patch-set

Changes in v3:
-Use a rotation member in struct drm_fb_helper_crtc and set that from
 drm_setup_crtcs instead of looping over all crtc's to find the right one
 later
-Since we now no longer look at rotation quirks directly in the fbcon code,
 set fb_info.fbcon_rotate_hint when the panel is not mounted upright and
 we cannot use hardware rotation
---
 drivers/gpu/drm/drm_fb_helper.c | 76 +++--
 include/drm/drm_fb_helper.h |  8 +
 2 files changed, 82 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 116d1f1337c7..e0f95f2cc52f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 
+#include "drm_crtc_internal.h"
 #include "drm_crtc_helper_internal.h"
 
 static bool drm_fbdev_emulation = true;
@@ -350,6 +351,7 @@ EXPORT_SYMBOL(drm_fb_helper_debug_leave);
 static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper, bool 
active)
 {
struct drm_device *dev = fb_helper->dev;
+   struct drm_plane_state *plane_state;
struct drm_plane *plane;
struct drm_atomic_state *state;
int i, ret;
@@ -368,8 +370,6 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper 
*fb_helper, bool activ
 retry:
plane_mask = 0;
drm_for_each_plane(plane, dev) {
-   struct drm_plane_state *plane_state;
-
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state)) {
ret = PTR_ERR(plane_state);
@@ -392,6 +392,11 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper 
*fb_helper, bool activ
 
for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_mode_set *mode_set = 
_helper->crtc_info[i].mode_set;
+   struct drm_plane *primary = mode_set->crtc->primary;
+
+   /* Cannot fail as we've already gotten the plane state above */
+   plane_state = drm_atomic_get_new_plane_state(state, primary);
+   plane_state->rotation = fb_helper->crtc_info[i].rotation;
 
ret = __drm_atomic_helper_set_config(mode_set, state);
if (ret != 0)
@@ -2334,6 +2339,57 @@ static int drm_pick_crtcs(struct drm_fb_helper 
*fb_helper,
return best_score;
 }
 
+/*
+ * This function checks if rotation is necessary because of panel orientation
+ * and if it is, if it is supported.
+ * If rotation is necessary and supported, its gets set in fb_crtc.rotation.
+ * If rotation is necessary but not supported, a DRM_MODE_ROTATE_* flag gets
+ * or-ed into fb_helper->rotations. In drm_setup_crtcs_fb() we check if only
+ * one bit is set and then we set fb_info.fbcon_rotate_hint to make fbcon do
+ * the unsupported rotation.
+ */
+static void drm_setup_crtc_rotation(struct drm_fb_helper *fb_helper,
+   struct drm_fb_helper_crtc *fb_crtc,
+   struct drm_connector *connector)
+{
+   struct drm_plane *plane = fb_crtc->mode_set.crtc->primary;
+   uint64_t valid_mask = 0;
+   int i, rotation;
+
+   fb_crtc->rotation = DRM_MODE_ROTATE_0;
+
+   switch (connector->display_info.panel_orientation) {
+   case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
+   rotation = DRM_MODE_ROTATE_180;
+   break;
+   case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
+   rotation = DRM_MODE_ROTATE_90;
+   break;
+   case DRM_MODE_PANEL_ORIENTATION_RIGHT_UP:
+   rotation = DRM_MODE_ROTATE_270;
+   break;
+   default:
+   rotation = DRM_MODE_ROTATE_0;
+   }
+
+   if (rotation == DRM_MODE_ROTATE_0 || !plane->rotation_property) {
+   fb_helper->rotations |= rotation;
+   return;
+   }
+
+   for (i = 0; i < plane->rotation_property->num_values; i++)
+   valid_mask |= (1ULL << plane->rotation_property->values[i]);
+
+   if (!(rotation & valid_mask)) {
+   fb_helper->rotations |= rotation;
+   return;
+   }
+
+   fb_crtc->rotation = rotation;
+   /* Rotating in hardware, fbcon should not rotate */
+   fb_helper->rotations |= DRM_MODE_ROTATE_0;
+}
+
 static void drm_setup_crtcs(struct drm_fb_helper *fb_helper,
u32 width, u32 height)
 {
@@ -2393,6 +2449,7 @@ static void drm_setup_crtcs(struct drm_fb_helper 
*fb_helper,
drm_fb_helper_modeset_release(fb_helper,
  
_helper->crtc_info[i].mode_set);
 
+   fb_helper->rotations = 0;

[Intel-gfx] [PATCH v3 6/7] efifb: Set info->fbcon_rotate_hint based on drm_get_panel_orientation_quirk

[Hans de Goede]

On some hardware the LCD panel is not mounted upright in the casing,
but rotated by 90 degrees. In this case we want the console to
automatically be rotated to compensate.

The drm subsys has a quirk table for this, use the
drm_get_panel_orientation_quirk function to get the panel orientation
and set info->fbcon_rotate_hint based on this, so that the fbcon console
on top of efifb gets automatically rotated to compensate for the panel
orientation.

Signed-off-by: Hans de Goede 
---
 drivers/video/fbdev/Kconfig |  1 +
 drivers/video/fbdev/efifb.c | 21 -
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 5e58f5ec0a28..c4a90c497839 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -772,6 +772,7 @@ config FB_VESA
 config FB_EFI
bool "EFI-based Framebuffer Support"
depends on (FB = y) && !IA64 && EFI
+   select DRM_PANEL_ORIENTATION_QUIRKS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 3a010641f630..8c7f6aeee205 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -15,6 +15,8 @@
 #include 
 #include 
 #include 
+#include  /* For drm_get_panel_orientation_quirk */
+#include   /* For DRM_MODE_PANEL_ORIENTATION_* */
 
 static bool request_mem_succeeded = false;
 static bool nowc = false;
@@ -156,7 +158,7 @@ static u64 bar_offset;
 static int efifb_probe(struct platform_device *dev)
 {
struct fb_info *info;
-   int err;
+   int err, orientation;
unsigned int size_vmode;
unsigned int size_remap;
unsigned int size_total;
@@ -328,6 +330,23 @@ static int efifb_probe(struct platform_device *dev)
info->fix = efifb_fix;
info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE;
 
+   orientation = drm_get_panel_orientation_quirk(efifb_defined.xres,
+ efifb_defined.yres);
+   switch (orientation) {
+   default:
+   info->fbcon_rotate_hint = FB_ROTATE_UR;
+   break;
+   case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
+   info->fbcon_rotate_hint = FB_ROTATE_UD;
+   break;
+   case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
+   info->fbcon_rotate_hint = FB_ROTATE_CCW;
+   break;
+   case DRM_MODE_PANEL_ORIENTATION_RIGHT_UP:
+   info->fbcon_rotate_hint = FB_ROTATE_CW;
+   break;
+   }
+
err = sysfs_create_groups(>dev.kobj, efifb_groups);
if (err) {
pr_err("efifb: cannot add sysfs attrs\n");
-- 
2.14.2

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

[Intel-gfx] [PATCH v3 1/7] fbcon: Add fbcon_rotate_hint to struct fb_info

[Hans de Goede]

On some hardware the LCD panel is not mounted upright in the casing,
but upside-down or rotated 90 degrees. In this case we want the console
to automatically be rotated to compensate.

The fbdev-driver may know about the need to rotate. Add a new
fbcon_rotate_hint field to struct fb_info, which gets initialized to -1.
If the fbdev-driver knows that some sort of rotation is necessary then
it can set this field to a FB_ROTATE_* value to tell the fbcon console
driver to rotate the console.

Signed-off-by: Hans de Goede 
---
 drivers/video/fbdev/core/fbcon.c   | 18 --
 drivers/video/fbdev/core/fbsysfs.c |  1 +
 include/linux/fb.h |  5 +
 3 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 04612f938bab..fb317ed76b45 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -963,10 +963,13 @@ static const char *fbcon_startup(void)
ops->cur_rotate = -1;
ops->cur_blink_jiffies = HZ / 5;
info->fbcon_par = ops;
-   if (initial_rotation != -1)
-   p->con_rotate = initial_rotation;
-   else
+
+   p->con_rotate = initial_rotation;
+   if (p->con_rotate == -1)
+   p->con_rotate = info->fbcon_rotate_hint;
+   if (p->con_rotate == -1)
p->con_rotate = fbcon_platform_get_rotate(info);
+
set_blitting_type(vc, info);
 
if (info->fix.type != FB_TYPE_TEXT) {
@@ -1103,10 +1106,13 @@ static void fbcon_init(struct vc_data *vc, int init)
 
ops = info->fbcon_par;
ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);
-   if (initial_rotation != -1)
-   p->con_rotate = initial_rotation;
-   else
+
+   p->con_rotate = initial_rotation;
+   if (p->con_rotate == -1)
+   p->con_rotate = info->fbcon_rotate_hint;
+   if (p->con_rotate == -1)
p->con_rotate = fbcon_platform_get_rotate(info);
+
set_blitting_type(vc, info);
 
cols = vc->vc_cols;
diff --git a/drivers/video/fbdev/core/fbsysfs.c 
b/drivers/video/fbdev/core/fbsysfs.c
index 15755ce1d26c..e31a182b42bf 100644
--- a/drivers/video/fbdev/core/fbsysfs.c
+++ b/drivers/video/fbdev/core/fbsysfs.c
@@ -58,6 +58,7 @@ struct fb_info *framebuffer_alloc(size_t size, struct device 
*dev)
info->par = p + fb_info_size;
 
info->device = dev;
+   info->fbcon_rotate_hint = -1;
 
 #ifdef CONFIG_FB_BACKLIGHT
mutex_init(>bl_curve_mutex);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index f4386b0ccf40..10cf71cc5d13 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -464,6 +464,11 @@ struct fb_info {
atomic_t count;
int node;
int flags;
+   /*
+* -1 by default, set to a FB_ROTATE_* value by the driver, if it knows
+* a lcd is not mounted upright and fbcon should rotate to compensate.
+*/
+   int fbcon_rotate_hint;
struct mutex lock;  /* Lock for open/release/ioctl funcs */
struct mutex mm_lock;   /* Lock for fb_mmap and smem_* fields */
struct fb_var_screeninfo var;   /* Current var */
-- 
2.14.2

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

[Intel-gfx] [PATCH v3 5/7] drm/i915: Add "panel orientation" property to the panel connector

[Hans de Goede]

Ideally we could use the VBT for this, that would be simple, in
intel_dsi_init() check dev_priv->vbt.dsi.config->rotation, set
connector->display_info.panel_orientation accordingly and call
drm_connector_init_panel_orientation_property(), done.

Unfortunately vbt.dsi.config->rotation is always 0 even on tablets
with an upside down LCD and where the GOP is properly rotating the
EFI fb in hardware.

So instead we end up reading the rotation from the primary plane.
To read the info from the primary plane, we need to know which crtc
the panel is hooked up to, so we do this the first time the panel
encoder's get_config function get called, as by then the encoder
crtc routing has been set up.

This commit only implements the panel orientation property for DSI
panels on BYT / CHT / BXT hardware, as all known non normal oriented
panels are only found on this hardware.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Read back the rotation applied by the GOP from the primary plane
 instead of relying on dev_priv->vbt.dsi.config->rotation, because it
 seems that the VBT rotation filed is always 0 even on devices where the
 GOP does apply a rotation

Changes in v3:
-Rewrite the code to read back the orientation from the primary
 plane to contain all of this in intel_dsi.c instead of poking a bunch
 of holes between all the different layers
---
 drivers/gpu/drm/i915/intel_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_dsi.c   | 48 ++
 drivers/gpu/drm/i915/intel_dsi.h   |  2 ++
 drivers/gpu/drm/i915/intel_panel.c | 16 +
 4 files changed, 67 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a05ab3a1ab27..29fb7a414bbe 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1728,6 +1728,7 @@ void intel_panel_enable_backlight(const struct 
intel_crtc_state *crtc_state,
  const struct drm_connector_state *conn_state);
 void intel_panel_disable_backlight(const struct drm_connector_state 
*old_conn_state);
 void intel_panel_destroy_backlight(struct drm_connector *connector);
+void intel_panel_set_orientation(struct intel_panel *panel, int orientation);
 enum drm_connector_status intel_panel_detect(struct drm_i915_private 
*dev_priv);
 extern struct drm_display_mode *intel_find_panel_downclock(
struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 66bbedc5fa01..86914d2f9f6a 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1084,13 +1084,16 @@ static void bxt_dsi_get_pipe_config(struct 
intel_encoder *encoder,
struct drm_display_mode *adjusted_mode_sw;
struct intel_crtc *intel_crtc;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
+   struct intel_panel *panel = _dsi->attached_connector->panel;
unsigned int lane_count = intel_dsi->lane_count;
unsigned int bpp, fmt;
+   int orientation;
enum port port;
u16 hactive, hfp, hsync, hbp, vfp, vsync, vbp;
u16 hfp_sw, hsync_sw, hbp_sw;
u16 crtc_htotal_sw, crtc_hsync_start_sw, crtc_hsync_end_sw,
crtc_hblank_start_sw, crtc_hblank_end_sw;
+   u32 val;
 
/* FIXME: hw readout should not depend on SW state */
intel_crtc = to_intel_crtc(encoder->base.crtc);
@@ -1234,6 +1237,49 @@ static void bxt_dsi_get_pipe_config(struct intel_encoder 
*encoder,
if (adjusted_mode->crtc_hblank_end == crtc_hblank_end_sw)
adjusted_mode->crtc_hblank_end =
adjusted_mode_sw->crtc_hblank_end;
+
+   if (!intel_dsi->got_panel_orientation) {
+   val = I915_READ(PLANE_CTL(intel_crtc->pipe, 0));
+   /* The rotation is used to correct for the panel orientation */
+   switch (val & PLANE_CTL_ROTATE_MASK) {
+   case PLANE_CTL_ROTATE_0:
+   orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
+   break;
+   case PLANE_CTL_ROTATE_90:
+   orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP;
+   break;
+   case PLANE_CTL_ROTATE_180:
+   orientation = DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
+   break;
+   case PLANE_CTL_ROTATE_270:
+   orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP;
+   break;
+   }
+   intel_panel_set_orientation(panel, orientation);
+   intel_dsi->got_panel_orientation = true;
+   }
+}
+
+static void vlv_dsi_get_pipe_config(struct intel_encoder *encoder)
+{
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
+   struct 

[Intel-gfx] [PATCH v3 0/7] drm/fbdev: Panel orientation connector property support

[Hans de Goede]

Hi All,

Here is v3 of my series to add a "panel orientation" property to
the drm-connector for the LCD panel to let userspace know about LCD
panels which are not mounted upright, as well as detecting upside-down
panels without needing quirks (like we do for 90 degree rotated screens).

As requested by Daniel this version moves the quirks over from the fbdev
subsys to the drm subsys. I've done this by simpy starting with a copy of
the quirk table and eventually removing the fbdev version.

The 1st patch in this series is a small fbdev/fbcon patch, patches 2-5
are all drm patches since patches 2-5 depend on patch 1 I believe it
would be best to merge patches 1-5 through the drm tree.

For merging patches 6-7 I see 3 options:

1) Wait a kernel cycle, things will work fine without them, they are really
just there to remove the fbdev copy of the quirks

2) Merge all 7 patches through the drm tree

3) Use a stable tag in the drm tree which the fbdev tree can merge and then
merge patches 6-7 through the drm tree.

Regards,

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

[Intel-gfx] [PATCH v3 2/7] drm: Add panel orientation quirks

[Hans de Goede]

Some x86 clamshell design devices use portrait tablet screens and a display
engine which cannot rotate in hardware, so the firmware just leaves things
as is and we cannot figure out that the display is oriented non upright
from the hardware.

So at least on x86, we need a quirk table for this. This commit adds a DMI
based quirk table which is initially populated with 5 such devices: Asus
T100HA, GPD Pocket, GPD win, I.T.Works TW891 and the VIOS LTH17.

This quirk table will be used by the drm code to let userspace know that
the display is not mounted upright inside the device's case through a new
panel orientation drm-connector property, as well as to tell fbcon to
rotate the console so that it shows the right way up.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/Kconfig|   3 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/drm_panel_orientation_quirks.c | 157 +
 include/drm/drm_utils.h|  18 +++
 4 files changed, 179 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_panel_orientation_quirks.c
 create mode 100644 include/drm/drm_utils.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 4d9f21831741..9d005ac98c2b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -26,6 +26,9 @@ config DRM_MIPI_DSI
bool
depends on DRM
 
+config DRM_PANEL_ORIENTATION_QUIRKS
+   tristate
+
 config DRM_DP_AUX_CHARDEV
bool "DRM DP AUX Interface"
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index a3fdc5a68dff..ffb621819bbf 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/
 
 obj-$(CONFIG_DRM)  += drm.o
 obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
+obj-$(CONFIG_DRM_PANEL_ORIENTATION_QUIRKS) += drm_panel_orientation_quirks.o
 obj-$(CONFIG_DRM_ARM)  += arm/
 obj-$(CONFIG_DRM_TTM)  += ttm/
 obj-$(CONFIG_DRM_TDFX) += tdfx/
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
new file mode 100644
index ..cea4d71f4978
--- /dev/null
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -0,0 +1,157 @@
+/*
+ *  drm_panel_orientation_quirks.c -- Quirks for non-normal panel orientation
+ *
+ * Copyright (C) 2017 Hans de Goede 
+ *
+ *  This file is subject to the terms and conditions of the GNU General Public
+ *  License.  See the file COPYING in the main directory of this archive for
+ *  more details.
+ */
+
+#include 
+#include 
+
+#ifdef CONFIG_DMI
+
+/*
+ * Some x86 clamshell design devices use portrait tablet screens and a display
+ * engine which cannot rotate in hardware, so we need to rotate the fbcon to
+ * compensate. Unfortunately these (cheap) devices also typically have quite
+ * generic DMI data, so we match on a combination of DMI data, screen 
resolution
+ * and a list of known BIOS dates to avoid false positives.
+ */
+
+struct drm_dmi_panel_orientation_data {
+   int width;
+   int height;
+   const char * const *bios_dates;
+   int orientation;
+};
+
+static const struct drm_dmi_panel_orientation_data asus_t100ha = {
+   .width = 800,
+   .height = 1280,
+   .orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP,
+};
+
+static const struct drm_dmi_panel_orientation_data gpd_pocket = {
+   .width = 1200,
+   .height = 1920,
+   .bios_dates = (const char * const []){ "05/26/2017", "06/28/2017",
+   "07/05/2017", "08/07/2017", NULL },
+   .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
+static const struct drm_dmi_panel_orientation_data gpd_win = {
+   .width = 720,
+   .height = 1280,
+   .bios_dates = (const char * const []){
+   "10/25/2016", "11/18/2016", "12/23/2016", "12/26/2016",
+   "02/21/2017", "03/20/2017", "05/25/2017", NULL },
+   .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
+static const struct drm_dmi_panel_orientation_data itworks_tw891 = {
+   .width = 800,
+   .height = 1280,
+   .bios_dates = (const char * const []){ "10/16/2015", NULL },
+   .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
+static const struct drm_dmi_panel_orientation_data vios_lth17 = {
+   .width = 800,
+   .height = 1280,
+   .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
+static const struct dmi_system_id orientation_data[] = {
+   {   /* Asus T100HA */
+   .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100HAN"),
+   },
+   .driver_data = (void *)_t100ha,
+   }, {/*
+* GPD Pocket, note that the the DMI data is less generic then
+* it seems, devices with a board-vendor of "AMI 

[Intel-gfx] [PATCH v3 7/7] fbcon: Remove dmi quirk table

[Hans de Goede]

This is now all handled in the drivers and communicated through
fb_info.fbcon_rotate_hint.

Signed-off-by: Hans de Goede 
---
 drivers/video/fbdev/core/Makefile   |   3 -
 drivers/video/fbdev/core/fbcon.c|   4 +-
 drivers/video/fbdev/core/fbcon.h|   6 --
 drivers/video/fbdev/core/fbcon_dmi_quirks.c | 145 
 4 files changed, 2 insertions(+), 156 deletions(-)
 delete mode 100644 drivers/video/fbdev/core/fbcon_dmi_quirks.c

diff --git a/drivers/video/fbdev/core/Makefile 
b/drivers/video/fbdev/core/Makefile
index 73493bbd7a15..0214b863ac3f 100644
--- a/drivers/video/fbdev/core/Makefile
+++ b/drivers/video/fbdev/core/Makefile
@@ -14,9 +14,6 @@ ifeq ($(CONFIG_FRAMEBUFFER_CONSOLE_ROTATION),y)
 fb-y += fbcon_rotate.o fbcon_cw.o fbcon_ud.o \
 fbcon_ccw.o
 endif
-ifeq ($(CONFIG_DMI),y)
-fb-y += fbcon_dmi_quirks.o
-endif
 endif
 fb-objs   := $(fb-y)
 
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index fb317ed76b45..157a40670a47 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -968,7 +968,7 @@ static const char *fbcon_startup(void)
if (p->con_rotate == -1)
p->con_rotate = info->fbcon_rotate_hint;
if (p->con_rotate == -1)
-   p->con_rotate = fbcon_platform_get_rotate(info);
+   p->con_rotate = FB_ROTATE_UR;
 
set_blitting_type(vc, info);
 
@@ -,7 +,7 @@ static void fbcon_init(struct vc_data *vc, int init)
if (p->con_rotate == -1)
p->con_rotate = info->fbcon_rotate_hint;
if (p->con_rotate == -1)
-   p->con_rotate = fbcon_platform_get_rotate(info);
+   p->con_rotate = FB_ROTATE_UR;
 
set_blitting_type(vc, info);
 
diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
index 18f3ac144237..3746828356ed 100644
--- a/drivers/video/fbdev/core/fbcon.h
+++ b/drivers/video/fbdev/core/fbcon.h
@@ -261,10 +261,4 @@ extern void fbcon_set_rotate(struct fbcon_ops *ops);
 #define fbcon_set_rotate(x) do {} while(0)
 #endif /* CONFIG_FRAMEBUFFER_CONSOLE_ROTATION */
 
-#ifdef CONFIG_DMI
-int fbcon_platform_get_rotate(struct fb_info *info);
-#else
-#define fbcon_platform_get_rotate(i) FB_ROTATE_UR
-#endif /* CONFIG_DMI */
-
 #endif /* _VIDEO_FBCON_H */
diff --git a/drivers/video/fbdev/core/fbcon_dmi_quirks.c 
b/drivers/video/fbdev/core/fbcon_dmi_quirks.c
deleted file mode 100644
index 6904e47d1e51..
--- a/drivers/video/fbdev/core/fbcon_dmi_quirks.c
+++ /dev/null
@@ -1,145 +0,0 @@
-/*
- *  fbcon_dmi_quirks.c -- DMI based quirk detection for fbcon
- *
- * Copyright (C) 2017 Hans de Goede 
- *
- *  This file is subject to the terms and conditions of the GNU General Public
- *  License.  See the file COPYING in the main directory of this archive for
- *  more details.
- */
-
-#include 
-#include 
-#include 
-#include "fbcon.h"
-
-/*
- * Some x86 clamshell design devices use portrait tablet screens and a display
- * engine which cannot rotate in hardware, so we need to rotate the fbcon to
- * compensate. Unfortunately these (cheap) devices also typically have quite
- * generic DMI data, so we match on a combination of DMI data, screen 
resolution
- * and a list of known BIOS dates to avoid false positives.
- */
-
-struct fbcon_dmi_rotate_data {
-   int width;
-   int height;
-   const char * const *bios_dates;
-   int rotate;
-};
-
-static const struct fbcon_dmi_rotate_data rotate_data_asus_t100ha = {
-   .width = 800,
-   .height = 1280,
-   .rotate = FB_ROTATE_CCW,
-};
-
-static const struct fbcon_dmi_rotate_data rotate_data_gpd_pocket = {
-   .width = 1200,
-   .height = 1920,
-   .bios_dates = (const char * const []){ "05/26/2017", "06/28/2017",
-   "07/05/2017", "08/07/2017", NULL },
-   .rotate = FB_ROTATE_CW,
-};
-
-static const struct fbcon_dmi_rotate_data rotate_data_gpd_win = {
-   .width = 720,
-   .height = 1280,
-   .bios_dates = (const char * const []){
-   "10/25/2016", "11/18/2016", "12/23/2016", "12/26/2016",
-   "02/21/2017", "03/20/2017", "05/25/2017", NULL },
-   .rotate = FB_ROTATE_CW,
-};
-
-static const struct fbcon_dmi_rotate_data rotate_data_itworks_tw891 = {
-   .width = 800,
-   .height = 1280,
-   .bios_dates = (const char * const []){ "10/16/2015", NULL },
-   .rotate = FB_ROTATE_CW,
-};
-
-static const struct fbcon_dmi_rotate_data rotate_data_vios_lth17 = {
-   .width = 800,
-   .height = 1280,
-   .rotate = FB_ROTATE_CW,
-};
-
-static const struct dmi_system_id rotate_data[] = {
-   {   /* Asus T100HA */
-   .matches = {
- DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
-   

Re: [Intel-gfx] [PATCH 15/15] staging: vboxvideo: Use drm_fb_helper_lastclose()

[Hans de Goede]

HI,

On 20-10-17 01:02, Noralf Trønnes wrote:

This driver can use drm_fb_helper_lastclose() as its .lastclose callback.

Cc: Hans de Goede 
Signed-off-by: Noralf Trønnes 


Thank you for doing this, looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans



---
  drivers/staging/vboxvideo/vbox_drv.c  |  2 +-
  drivers/staging/vboxvideo/vbox_drv.h  |  1 -
  drivers/staging/vboxvideo/vbox_main.c | 12 
  3 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/drivers/staging/vboxvideo/vbox_drv.c 
b/drivers/staging/vboxvideo/vbox_drv.c
index e18642e5027e..a4d8d7898e3d 100644
--- a/drivers/staging/vboxvideo/vbox_drv.c
+++ b/drivers/staging/vboxvideo/vbox_drv.c
@@ -229,7 +229,7 @@ static struct drm_driver driver = {
  
  	.load = vbox_driver_load,

.unload = vbox_driver_unload,
-   .lastclose = vbox_driver_lastclose,
+   .lastclose = drm_fb_helper_lastclose,
.master_set = vbox_master_set,
.master_drop = vbox_master_drop,
  
diff --git a/drivers/staging/vboxvideo/vbox_drv.h b/drivers/staging/vboxvideo/vbox_drv.h

index 4b9302703b36..7273d7e9bc9b 100644
--- a/drivers/staging/vboxvideo/vbox_drv.h
+++ b/drivers/staging/vboxvideo/vbox_drv.h
@@ -128,7 +128,6 @@ struct vbox_private {
  
  int vbox_driver_load(struct drm_device *dev, unsigned long flags);

  void vbox_driver_unload(struct drm_device *dev);
-void vbox_driver_lastclose(struct drm_device *dev);
  
  struct vbox_gem_object;
  
diff --git a/drivers/staging/vboxvideo/vbox_main.c b/drivers/staging/vboxvideo/vbox_main.c

index 80bd039fa08e..c3d756620fd5 100644
--- a/drivers/staging/vboxvideo/vbox_main.c
+++ b/drivers/staging/vboxvideo/vbox_main.c
@@ -421,18 +421,6 @@ void vbox_driver_unload(struct drm_device *dev)
vbox_hw_fini(vbox);
  }
  
-/**

- * @note this is described in the DRM framework documentation.  AST does not
- * have it, but we get an oops on driver unload if it is not present.
- */
-void vbox_driver_lastclose(struct drm_device *dev)
-{
-   struct vbox_private *vbox = dev->dev_private;
-
-   if (vbox->fbdev)
-   drm_fb_helper_restore_fbdev_mode_unlocked(>fbdev->helper);
-}
-
  int vbox_gem_create(struct drm_device *dev,
u32 size, bool iskernel, struct drm_gem_object **obj)
  {


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