1. 14 11月, 2017 1 次提交
  2. 12 11月, 2017 1 次提交
  3. 10 11月, 2017 1 次提交
    • V
      drm/i915: Nuke intel_digital_port->port · 8f4f2797
      Ville Syrjälä 提交于
      Remove intel_digital_port->port and replace its users with
      intel_encoder->port. intel_encoder->port is a superset of
      intel_digital_port->port, and it works correctly even for
      MST encoders.
      
      v2: Eliminate a few dp_to_dig_port()->base.port cases too (DK)
      
      Performed with cocci:
      @@
      @@
      struct intel_digital_port {
             ...
      -       enum port port;
             ...
      }
      
      @@
      struct intel_digital_port *D;
      expression E;
      @@
      - D->port = E;
      
      @@
      struct intel_digital_port *D;
      @@
      - D->port
      + D->base.port
      
      @
      expression E;
      @@
      (
      - dp_to_dig_port(E)->port
      + dp_to_dig_port(E)->base.port
      |
      - enc_to_dig_port(E)->port
      + to_intel_encoder(E)->port
      )
      
      @@
      expression E;
      @@
      - to_intel_encoder(&E->base)
      + E
      
      @@
      struct intel_digital_port *D;
      identifier I, M;
      @@
        I = &D->base
      <...
      (
      - D->base.M
      + I->M
      |
      - &D->base
      + I
      )
      ...>
      
      @@
      identifier D;
      expression E;
      identifier M;
      @@
       D = enc_to_dig_port(&E->base)
      <...
      (
      - D->base.M
      + E->M
      |
      - &D->base
      + E
      )
      ...>
      
      @@
      identifier D, DP;
      expression E;
      identifier M;
      @@
       DP = enc_to_intel_dp(&E->base)
      <...
      (
      - dp_to_dig_port(DP)->base.M
      + E->M
      |
      - &dp_to_dig_port(DP)->base
      + E
      )
      ...>
      
      @@
      expression E;
      identifier M;
      @@
      (
      - enc_to_dig_port(&E->base)->base.M
      + E->M
      |
      - enc_to_dig_port(&E->base)->base
      + E
      |
      - enc_to_mst(&E->base)->primary->base.port
      + E->port
      )
      
      @@
      expression E;
      identifier D;
      @@
      - struct intel_digital_port *D = E;
      ... when != D
      
      Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Acked-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171109152434.32074-1-ville.syrjala@linux.intel.com
      8f4f2797
  4. 01 11月, 2017 1 次提交
  5. 31 10月, 2017 3 次提交
  6. 27 10月, 2017 1 次提交
  7. 25 10月, 2017 3 次提交
  8. 19 10月, 2017 1 次提交
  9. 18 10月, 2017 4 次提交
  10. 17 10月, 2017 2 次提交
  11. 13 10月, 2017 1 次提交
  12. 12 10月, 2017 1 次提交
  13. 11 10月, 2017 3 次提交
  14. 10 10月, 2017 1 次提交
  15. 26 9月, 2017 1 次提交
    • U
      drm/i915: Enable scanline read based on frame timestamps · aec0246f
      Uma Shankar 提交于
      For certain platforms on certain encoders, timings are driven
      from port instead of pipe. Thus, we can't rely on pipe scanline
      registers to get the timing information. Some cases scanline
      register read will not be functional.
      This is causing vblank evasion logic to fail since it relies on
      scanline, causing atomic update failure warnings.
      
      This patch uses pipe framestamp and current timestamp registers
      to calculate scanline. This is an indirect way to get the scanline.
      It helps resolve atomic update failure for gen9 dsi platforms.
      
      v2: Addressed Ville and Daniel's review comments. Updated the
      register MACROs, handled race condition for register reads,
      extracted timings from the hwmode. Removed the dependency on
      crtc->config to get the encoder type.
      
      v3: Made get scanline function generic
      
      v4: Addressed Ville's review comments. Added a flag to decide timestamp
      based scanline reporting. Changed 64bit variables to u32
      
      v5: Adressed Ville's review comments. Put the scanline compute function
      at the place of caller. Removed hwmode flags from uapi and used a local
      i915 data structure instead.
      
      v6: Used vblank hwmode to get the timings.
      
      v7: Fixed sparse warnings, indentation and minor review comments.
      
      v8: Limited this only for Gen9 DSI.
      
      Credits-to: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NUma Shankar <uma.shankar@intel.com>
      Signed-off-by: NChandra Konduru <chandra.konduru@intel.com>
      Signed-off-by: NVidya Srinivas <vidya.srinivas@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1506347761-4201-1-git-send-email-vidya.srinivas@intel.com
      aec0246f
  16. 22 9月, 2017 1 次提交
  17. 07 9月, 2017 1 次提交
    • K
      drm/i915/bxt+: Enable IPC support · 2503a0fe
      Kumar, Mahesh 提交于
      This patch adds IPC support. This patch also enables IPC in all supported
      platforms based on has_ipc flag.
      IPC (Isochronous Priority Control) is the hardware feature, which
      dynamically controls the memory read priority of Display.
      
      When IPC is enabled, plane read requests are sent at high priority until
      filling above the transition watermark, then the requests are sent at
      lower priority until dropping below the level 0 watermark.
      The lower priority requests allow other memory clients to have better
      memory access. When IPC is disabled, all plane read requests are sent at
      high priority.
      
      Changes since V1:
       - Remove commandline parameter to disable ipc
       - Address Paulo's comments
      Changes since V2:
       - Address review comments
       - Set ipc_enabled flag
      Changes since V3:
       - move ipc_enabled flag assignment inside intel_ipc_enable function
      Changes since V4:
       - Re-enable IPC after suspend/resume
      Changes since V5:
       - Enable IPC for all gen >=9 except SKL
      Changes since V6:
       - fix commit msg
       - after resume program IPC based on SW state.
      Changes since V7:
       - Modify IPC support check based on HAS_IPC macro (suggested by Chris)
      Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170817134529.2839-8-mahesh1.kumar@intel.com
      2503a0fe
  18. 06 9月, 2017 1 次提交
  19. 01 9月, 2017 5 次提交
  20. 25 8月, 2017 2 次提交
  21. 23 8月, 2017 1 次提交
    • C
      drm/i915: Boost GPU clocks if we miss the pageflip's vblank · 74d290f8
      Chris Wilson 提交于
      If we miss the current vblank because the gpu was busy, that may cause a
      jitter as the frame rate temporarily drops. We try to limit the impact
      of this by then boosting the GPU clock to deliver the frame as quickly
      as possible. Originally done in commit 6ad790c0 ("drm/i915: Boost GPU
      frequency if we detect outstanding pageflips") but was never forward
      ported to atomic and finally dropped in commit fd3a4024 ("drm/i915:
      Rip out legacy page_flip completion/irq handling").
      
      One of the most typical use-cases for this is a mostly idle desktop.
      Rendering one frame of the desktop's frontbuffer can easily be
      accomplished by the GPU running at low frequency, but often exceeds
      the time budget of the desktop compositor. The result is that animations
      such as opening the menu, doing a fullscreen switch, or even just trying
      to move a window around are slow and jerky. We need to respond within a
      frame to give the best impression of a smooth UX, as a compromise we
      instead respond if that first frame misses its goal. The result should
      be a near-imperceivable initial delay and a smooth animation even
      starting from idle. The cost, as ever, is that we spend more power than
      is strictly necessary as we overestimate the required GPU frequency and
      then try to ramp down.
      
      This of course is reactionary, too little, too late; nevertheless it is
      surprisingly effective.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102199Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170817123706.6777-1-chris@chris-wilson.co.ukTested-by: NLyude Paul <lyude@redhat.com>
      Reviewed-by: NRadoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
      74d290f8
  22. 22 8月, 2017 4 次提交