1. 17 10月, 2017 2 次提交
  2. 13 10月, 2017 1 次提交
  3. 12 10月, 2017 1 次提交
  4. 11 10月, 2017 3 次提交
  5. 10 10月, 2017 1 次提交
  6. 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
  7. 22 9月, 2017 1 次提交
  8. 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
  9. 06 9月, 2017 1 次提交
  10. 01 9月, 2017 5 次提交
  11. 25 8月, 2017 2 次提交
  12. 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
  13. 22 8月, 2017 4 次提交
  14. 21 8月, 2017 2 次提交
  15. 16 8月, 2017 1 次提交
  16. 11 8月, 2017 1 次提交
    • B
      drm/i915: Add format modifiers for Intel · 714244e2
      Ben Widawsky 提交于
      This was based on a patch originally by Kristian. It has been modified
      pretty heavily to use the new callbacks from the previous patch.
      
      v2:
        - Add LINEAR and Yf modifiers to list (Ville)
        - Combine i8xx and i965 into one list of formats (Ville)
        - Allow 1010102 formats for Y/Yf tiled (Ville)
      
      v3:
        - Handle cursor formats (Ville)
        - Put handling for LINEAR in the mod_support functions (Ville)
      
      v4:
        - List each modifier explicitly in supported modifiers (Ville)
        - Handle the CURSOR plane (Ville)
      
      v5:
        - Split out cursor and sprite handling (Ville)
      
      v6:
        - Actually use the sprite funcs (Emil)
        - Use unreachable (Emil)
      
      v7:
        - Only allow Intel modifiers and LINEAR (Ben)
      
      v8
        - Fix spite assert introduced in v6 (Daniel)
      
      v9
        - Change vendor check logic to avoid magic 56 (Emil)
        - Reorder skl_mod_support (Ville)
        - make intel_plane_funcs static, could be done as of v5 (Ville)
        - rename local variable intel_format_modifiers to modifiers (Ville)
          - actually use sprite modifiers
        - split out modifier/formats by platform (Ville)
      
      v10:
        - Undo vendor check from v9
      
      v11:
        - Squash CCS advertisement into this patch (daniels)
        - Don't advertise CCS on higher sprite planes (daniels)
      
      v12:
        - Don't advertise Y-tiled or CCS on any sprite planes, since we don't
          allocate enough DDB space for it to work. (daniels)
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (v8)
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Stone <daniels@collabora.com>
      714244e2
  17. 04 8月, 2017 1 次提交
  18. 27 7月, 2017 2 次提交
  19. 21 7月, 2017 3 次提交
  20. 19 7月, 2017 1 次提交
    • D
      drm/i915: Fix fbdev unload sequence · 4f256d82
      Daniel Vetter 提交于
      First thing we need to do is unregister the fbdev instance, but we
      can't just go ahead and kfree it. That must wait until the hotplug and
      polling work are stopped, since they can race with the with the
      teardown. That means we need to split up the fbdev teardown into the
      unregister part and the cleanup part.
      
      I originally suspected that this was broken in one of the unload
      shuffles, but on closer inspection the oldest sequence I've dug out
      also gets this wrong. Just not quite so badly.
      
      I've run drv_module_reload a few hundred times and it's rock solid
      compared to insta-death beforehand. This bug seems to have been
      uncovered by
      
      commit 88be58be
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Thu Jul 6 15:00:19 2017 +0200
      
          drm/i915/fbdev: Always forward hotplug events
      
      But the effect of that seems to only be to increase the race window
      enough to make it blow up easier. I'm not exactly clear on what's
      going on there ...
      
      v2: Fix whitespace and use fetch_and_zero (Chris).
      
      Testcase: igt/drv_module_reload
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101791
      Cc: martin.peres@free.fr
      Cc: chris@chris-wilson.co.uk
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170714224656.6431-2-daniel.vetter@ffwll.ch
      4f256d82
  21. 18 7月, 2017 1 次提交
  22. 28 6月, 2017 1 次提交
    • C
      drm/i915: Avoid keeping waitboost active for signaling threads · 7b92c1bd
      Chris Wilson 提交于
      Once a client has requested a waitboost, we keep that waitboost active
      until all clients are no longer waiting. This is because we don't
      distinguish which waiter deserves the boost. However, with the advent of
      fence signaling, the signaler threads appear as waiters to the RPS
      interrupt handler. So instead of using a single boolean to track when to
      keep the waitboost active, use a counter of all outstanding waitboosted
      requests.
      
      At this point, I have removed all vestiges of the rate limiting on
      clients. Whilst this means that compositors should remain more fluid,
      it also means that boosts are more prevalent. See commit b29c19b6
      ("drm/i915: Boost RPS frequency for CPU stalls") for a longer discussion
      on the pros and cons of both approaches.
      
      A drawback of this implementation is that it requires constant request
      submission to keep the waitboost trimmed (as it is now cancelled when the
      request is completed). This will be fine for a busy system, but near
      idle the boosts may be kept for longer than desired (effectively tens of
      vblanks worstcase) and there is a reliance on rc6 instead.
      
      v2: Remove defunct rps.client_lock
      Reported-by: NMichał Winiarski <michal.winiarski@intel.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michał Winiarski <michal.winiarski@intel.com>
      Reviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170628123548.9236-1-chris@chris-wilson.co.uk
      7b92c1bd
  23. 15 6月, 2017 1 次提交
  24. 13 6月, 2017 1 次提交
    • V
      drm/i915/cnl: Implement CNL display init/unit sequence · d8d4a512
      Ville Syrjälä 提交于
      Implement the CNL display init/uninit sequence as outlined in Bspec.
      
      Quite similar to SKL/BXT. The main complicaiton is probably the extra
      procmon setup we must do based on the process/voltage information we
      can read out from some register.
      
      v2: s/skl_dbuf/gen9_dbuf/ to follow upstream
          bxt needed a cdclk sanitize step, so let's add it for cnl too
      v3: s/CHICKEN_MISC_1/CHICKEN_MISC_2/ (Ander)
      v4: Rebased by Rodrigo after Ville's cdclk rework
      v5: Removed unecessary Aux IO forced enable/disable, Fix DW10 setup
          Fix procpon Mask. (Credits-to Paulo and Clint)
          Remove A0 workaround.
      v6: Rebased on top of recent code (Rodrigo).
      v7: Respect the order of sanitize_ after set_
          (Done by Rodrigo, Requested by Ville)
      v8: Commit message updated to matvh v5 changes besides
          Remove unused DW8 and an extra blank line. (all noticed
          by Imre).
      v9: Remove __attribute__((unused)) added on latest version
          of drm/i915/cnl: Implement .set_cdclk() for CNL.
      
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Clint Taylor <clinton.a.taylor@intel.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-3-git-send-email-rodrigo.vivi@intel.com
      d8d4a512
  25. 12 6月, 2017 1 次提交
    • M
      drm/i915: Pass atomic state to backlight enable/disable/set callbacks. · 7d025e08
      Maarten Lankhorst 提交于
      Pass crtc_state to the enable callback, and connector_state to all callbacks.
      This will eliminate the need to guess for the correct pipe in these
      callbacks.
      
      The crtc state is required for pch_enable_backlight to obtain the correct
      cpu_transcoder.
      
      intel_dp_aux_backlight's setup function is called before hw readout, so
      crtc_state and connector_state->best_encoder are NULL in the enable()
      and set() callbacks.
      
      This fixes the following series of warns from intel_get_pipe_from_connector:
      [  219.968428] ------------[ cut here ]------------
      [  219.968481] WARNING: CPU: 3 PID: 2457 at
      drivers/gpu/drm/i915/intel_display.c:13881
      intel_get_pipe_from_connector+0x62/0x90 [i915]
      [  219.968483]
      WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex))
      [  219.968485] Modules linked in: nls_iso8859_1 snd_hda_codec_hdmi
      snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec
      snd_hda_core snd_hwdep snd_pcm intel_rapl x86_pkg_temp_thermal coretemp
      kvm_intel snd_seq_midi snd_seq_midi_event kvm snd_rawmidi irqbypass
      crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc snd_seq
      snd_seq_device serio_raw snd_timer aesni_intel aes_x86_64 crypto_simd
      glue_helper cryptd lpc_ich snd mei_me shpchp soundcore mei rfkill_gpio
      mac_hid intel_pmc_ipc parport_pc ppdev lp parport ip_tables x_tables
      autofs4 hid_generic usbhid igb ahci i915 xhci_pci dca xhci_hcd ptp
      sdhci_pci sdhci libahci pps_core i2c_hid hid video
      [  219.968573] CPU: 3 PID: 2457 Comm: kworker/u8:3 Tainted: G        W
      4.10.0-tip-201703010159+ #2
      [  219.968575] Hardware name: Intel Corp. Broxton P/NOTEBOOK, BIOS
      APLKRVPA.X64.0144.B10.1606270006 06/27/2016
      [  219.968627] Workqueue: events_unbound intel_atomic_commit_work [i915]
      [  219.968629] Call Trace:
      [  219.968640]  dump_stack+0x63/0x87
      [  219.968646]  __warn+0xd1/0xf0
      [  219.968651]  warn_slowpath_fmt+0x4f/0x60
      [  219.968657]  ? drm_printk+0x97/0xa0
      [  219.968708]  intel_get_pipe_from_connector+0x62/0x90 [i915]
      [  219.968756]  intel_panel_enable_backlight+0x19/0xf0 [i915]
      [  219.968804]  intel_edp_backlight_on.part.22+0x33/0x40 [i915]
      [  219.968852]  intel_edp_backlight_on+0x18/0x20 [i915]
      [  219.968900]  intel_enable_ddi+0x94/0xc0 [i915]
      [  219.968950]  intel_encoders_enable.isra.93+0x77/0x90 [i915]
      [  219.969000]  haswell_crtc_enable+0x310/0x7f0 [i915]
      [  219.969051]  intel_update_crtc+0x58/0x100 [i915]
      [  219.969101]  skl_update_crtcs+0x218/0x240 [i915]
      [  219.969153]  intel_atomic_commit_tail+0x350/0x1000 [i915]
      [  219.969159]  ? vtime_account_idle+0xe/0x50
      [  219.969164]  ? finish_task_switch+0x107/0x250
      [  219.969214]  intel_atomic_commit_work+0x12/0x20 [i915]
      [  219.969219]  process_one_work+0x153/0x3f0
      [  219.969223]  worker_thread+0x12b/0x4b0
      [  219.969227]  kthread+0x101/0x140
      [  219.969230]  ? rescuer_thread+0x340/0x340
      [  219.969233]  ? kthread_park+0x90/0x90
      [  219.969237]  ? do_syscall_64+0x6e/0x180
      [  219.969243]  ret_from_fork+0x2c/0x40
      [  219.969246] ---[ end trace 0a8fa19387b9ad6d ]---
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100022Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170612102115.23665-4-maarten.lankhorst@linux.intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      7d025e08