1. 03 1月, 2018 9 次提交
  2. 02 1月, 2018 2 次提交
  3. 29 12月, 2017 2 次提交
  4. 24 12月, 2017 1 次提交
    • H
      drm/i915/vlv: Add cdclk workaround for DSI · c8dae55a
      Hans de Goede 提交于
      At least on the Chuwi Vi8 (non pro/plus) the LCD panel will show an image
      shifted aprox. 20% to the left (with wraparound) and sometimes also wrong
      colors, showing that the panel controller is starting with sampling the
      datastream somewhere mid-line. This happens after the first blanking and
      re-init of the panel.
      
      After looking at drm.debug output I noticed that initially we inherit the
      cdclk of 333333 KHz set by the GOP, but after the re-init we picked 266667
      KHz, which turns out to be the cause of this problem, a quick hack to hard
      code the cdclk to 333333 KHz makes the problem go away.
      
      I've tested this on various Bay Trail devices, to make sure this not does
      cause regressions on other devices and the higher cdclk does not cause
      any problems on the following devices:
      -GP-electronic T701      1024x600   333333 KHz cdclk after this patch
      -PEAQ C1010              1920x1200  333333 KHz cdclk after this patch
      -PoV mobii-wintab-800w    800x1280  333333 KHz cdclk after this patch
      -Asus Transformer-T100TA 1368x768   320000 KHz cdclk after this patch
      
      Also interesting wrt this is the comment in vlv_calc_cdclk about the
      existing workaround to avoid 200 Mhz as clock because that causes issues
      in some cases.
      
      This commit extends the "do not use 200 Mhz" workaround with an extra
      check to require atleast 320000 KHz (avoiding 266667 KHz) when a DSI
      panel is active.
      
      Changes in v2:
      -Change the commit message and the code comment to not treat the GOP as
       a reference, the GOP should not be treated as a reference
      Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171220105017.11259-1-hdegoede@redhat.com
      c8dae55a
  5. 23 12月, 2017 6 次提交
    • L
      drm/i915: Apply Display WA #1183 on skl, kbl, and cfl · 53421c2f
      Lucas De Marchi 提交于
      Display WA #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.
      
      We need to cover 2 cases: when we are in fact enabling DPLL0
      and when we are just changing the frequency with small
      differences.
      
      This is based on previous patch by Rodrigo Vivi with suggestions
      from Ville Syrjälä.
      
      Cc: Arthur J Runyan <arthur.j.runyan@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171204232210.4958-1-lucas.demarchi@intel.com
      53421c2f
    • R
      drm/i915: Update DRIVER_DATE to 20171222 · cfe4982c
      Rodrigo Vivi 提交于
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      cfe4982c
    • C
      drm/i915: Show HWSP in intel_engine_dump() · c1bf2728
      Chris Wilson 提交于
      Looking at a CI failure with an ominous line of
      [  362.550715] hangcheck current seqno ffffff6b, last ffffff8c, hangcheck ffffff6b [6016 ms], inflight 118
      with no apparent cause for the seqno to be negative, left me wondering
      if someone had scribbled over the HWSP. So include the HWSP in the
      engine dump to see if there are more signs of random scribbling.
      
      v2: Fix row pointer, i is now incremented by 8 so doesn't need scaling
      by 8, and we don't need to keep volatile here as the status_page isn't
      marked up as volatile itself.
      v3: Use hexdump, with suppression of identical lines. (Tvrtko)
          Which results in
      
      HWSP:
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      *
      00000040 00000001 00000000 00000018 00000002 00000001 00000000 00000018 00000000
      00000060 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000003
      00000080 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      *
      000000c0 00000002 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      000000e0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      *
      
          instead of 128 lines of mostly 0s.
      v4: Tidy up the locals
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171222182521.18106-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      c1bf2728
    • C
      drm/i915: Assert that the request is on the execution queue before being removed · 2d453c78
      Chris Wilson 提交于
      We should only attempt to remove requests from the execution queue that
      are on the execution queue. These are the requests that have been
      assigned a global_seqno, so we can assert that we only attempt to remove
      requests with a nonzero global_seqno. Afterwards we assert that we
      remove them in order, i.e. the global_seqno matches the engine's seqno,
      but that leaves a small loophole for an unattached request on an unused
      engine.
      
      We can then make the same assertion on queuing the request to the
      execution engine, it must have a zero global_seqno or else we are queuing
      the same request twice.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Michał Winiarski <michal.winiarski@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171222141959.3006-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      2d453c78
    • C
      drm/i915/execlists: Show preemption progress in GEM_TRACE · 193a98dc
      Chris Wilson 提交于
      We already emit a GEM_TRACE for when we start preemption, but we lack
      one to show when the preemption is completed and we return to the regular
      queue. This is to continue the investigation into the mysterious
      
      <0>[  197.854177]   <idle>-0       1..s1 197837017us : execlists_submission_tasklet: rcs0 cs-irq head=0 [0], tail=0 [0]
      <0>[  197.854209] drv_self-6008    2.... 197837390us : reset_common_ring: rcs0 seqno=15515
      <0>[  197.854240] drv_self-6008    2.... 197837415us : reset_common_ring: bcs0 seqno=0
      <0>[  197.854270] drv_self-6008    2.... 197837443us : reset_common_ring: vcs0 seqno=0
      <0>[  197.854300] drv_self-6008    2.... 197837463us : reset_common_ring: vcs1 seqno=0
      <0>[  197.854330] drv_self-6008    2.... 197837482us : reset_common_ring: vecs0 seqno=0
      <0>[  197.854360] ksoftirq-23      2..s. 197838341us : execlists_submission_tasklet: bcs0 in[0]:  ctx=0.1, seqno=1dce7
      <0>[  197.854392]   <idle>-0       1..s1 197838347us : execlists_submission_tasklet: bcs0 cs-irq head=0 [0], tail=0 [0]
      <0>[  197.854423] ksoftirq-23      2..s. 197838354us : execlists_submission_tasklet: vcs0 in[0]:  ctx=0.1, seqno=1d027
      <0>[  197.854456] ksoftirq-23      2.Ns. 197838361us : execlists_submission_tasklet: vcs1 in[0]:  ctx=0.1, seqno=1e738
      <0>[  197.854488] ksoftirq-23      2.Ns. 197838366us : execlists_submission_tasklet: vecs0 in[0]:  ctx=0.1, seqno=235aa
      <0>[  197.854520] ksoftirq-23      2.Ns. 197838376us : execlists_submission_tasklet: rcs0 in[0]:  ctx=0.1, seqno=15518
      <0>[  197.854552]   <idle>-0       1..s1 197853285us : execlists_submission_tasklet: rcs0 cs-irq head=0 [0], tail=7 [7]
      <0>[  197.854584]   <idle>-0       1..s1 197853285us : execlists_submission_tasklet: rcs0 csb[1]: status=0x00000018:0x00000000
      <0>[  197.854616]   <idle>-0       1..s1 197853286us : execlists_submission_tasklet: rcs0 out[0]: ctx=0.0, seqno=0
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171222132742.4272-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      193a98dc
    • R
      Merge tag 'gvt-next-2017-12-22' of https://github.com/intel/gvt-linux into drm-intel-next-queued · e329ef67
      Rodrigo Vivi 提交于
      gvt-next-2017-12-22:
      
      - more mmio switch optimization (Weinan)
      - cleanup i915_reg_t vs. offset usage (Zhenyu)
      - move write protect handler out of mmio handler (Zhenyu)
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171222085141.vgewlvvni37dljdt@zhen-hp.sh.intel.com
      e329ef67
  6. 22 12月, 2017 18 次提交
  7. 21 12月, 2017 2 次提交