1. 21 Jun, 2016 7 commits
  2. 20 Jun, 2016 7 commits
  3. 19 Jun, 2016 1 commit
  4. 17 Jun, 2016 10 commits
  5. 16 Jun, 2016 7 commits
  6. 15 Jun, 2016 4 commits
  7. 14 Jun, 2016 4 commits
    • Lyude's avatar
      drm/i915/ilk: Don't disable SSC source if it's in use · 1c1a24d2
      Lyude authored
      Thanks to Ville Syrjälä for pointing me towards the cause of this issue.
      
      Unfortunately one of the sideaffects of having the refclk for a DPLL set
      to SSC is that as long as it's set to SSC, the GPU will prevent us from
      powering down any of the pipes or transcoders using it. A couple of
      BIOSes enable SSC in both PCH_DREF_CONTROL and in the DPLL
      configurations. This causes issues on the first modeset, since we don't
      expect SSC to be left on and as a result, can't successfully power down
      the pipes or the transcoders using it. Here's an example from this Dell
      OptiPlex 990:
      
      [drm:intel_modeset_init] SSC enabled by BIOS, overriding VBT which says disabled
      [drm:intel_modeset_init] 2 display pipes available.
      [drm:intel_update_cdclk] Current CD clock rate: 400000 kHz
      [drm:intel_update_max_cdclk] Max CD clock rate: 400000 kHz
      [drm:intel_update_max_cdclk] Max dotclock rate: 360000 kHz
      vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
      [drm:intel_crt_reset] crt adpa set to 0xf40000
      [drm:intel_dp_init_connector] Adding DP connector on port C
      [drm:intel_dp_aux_init] registering DPDDC-C bus for card0-DP-1
      [drm:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_ck505 0
      [drm:ironlake_init_pch_refclk] Disabling SSC entirely
      … later we try committing the first modeset …
      [drm:intel_dump_pipe_config] [CRTC:26][modeset] config ffff88041b02e800 for pipe A
      [drm:intel_dump_pipe_config] cpu_transcoder: A
      …
      [drm:intel_dump_pipe_config] dpll_hw_state: dpll: 0xc4016001, dpll_md: 0x0, fp0: 0x20e08, fp1: 0x30d07
      [drm:intel_dump_pipe_config] planes on this crtc
      [drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 0.0 idx: 0 enabled
      [drm:intel_dump_pipe_config]     FB:42, fb = 800x600 format = 0x34325258
      [drm:intel_dump_pipe_config]     scaler:0 src (0, 0) 800x600 dst (0, 0) 800x600
      [drm:intel_dump_pipe_config] CURSOR PLANE:25 plane: 0.1 idx: 1 disabled, scaler_id = 0
      [drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 0.1 idx: 2 disabled, scaler_id = 0
      [drm:intel_get_shared_dpll] CRTC:26 allocated PCH DPLL A
      [drm:intel_get_shared_dpll] using PCH DPLL A for pipe A
      [drm:ilk_audio_codec_disable] Disable audio codec on port C, pipe A
      [drm:intel_disable_pipe] disabling pipe A
      ------------[ cut here ]------------
      WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_display.c:1146 intel_disable_pipe+0x297/0x2d0 [i915]
      pipe_off wait timed out
      …
      ---[ end trace 94fc8aa03ae139e8 ]---
      [drm:intel_dp_link_down]
      [drm:ironlake_crtc_disable [i915]] *ERROR* failed to disable transcoder A
      
      Later modesets succeed since they reset the DPLL's configuration anyway,
      but this is enough to get stuck with a big fat warning in dmesg.
      
      A better solution would be to add refcounts for the SSC source, but for
      now leaving the source clock on should suffice.
      
      Changes since v4:
       - Fix calculation of final for systems with LVDS panels (fixes BUG() on
         CI test suite)
      Changes since v3:
       - Move temp variable into loop
       - Move checks for using_ssc_source to after we've figured out has_ck505
       - Add using_ssc_source to debug output
      Changes since v2:
       - Fix debug output for when we disable the CPU source
      Changes since v1:
       - Leave the SSC source clock on instead of just shutting it off on all
         of the DPLL configurations.
      
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarLyude <cpaul@redhat.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1465916649-10228-1-git-send-email-cpaul@redhat.com
      1c1a24d2
    • Daniel Vetter's avatar
      Merge tag 'sphinx-4.8' of git://git.lwn.net/linux into topic/drm-misc · db5dfef7
      Daniel Vetter authored
      Stable tag for sphinx work
      
      Pull current state of the sphinx rework from Jonathan into drm-misc so
      that we can start converting gpu.tmpl.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      db5dfef7
    • Daniel Vetter's avatar
      drm/virtio: Don't reinvent a flipping wheel · 0d841ac0
      Daniel Vetter authored
      Now that the core helpers support nonblocking atomic commits there's
      no need to invent that wheel separately (instead of fixing the bug in
      the atomic implementation of virtio, as it should have been done!).
      
      v2: Rebased on top of
      
      commit e7cf0963
      Author: Gerd Hoffmann <kraxel@redhat.com>
      Date:   Tue May 31 08:50:47 2016 +0200
      
      virtio-gpu: add atomic_commit function
      
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Tested-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      Reviewed-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1465510073-20951-1-git-send-email-daniel.vetter@ffwll.ch
      0d841ac0
    • Dave Gordon's avatar
      drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission · 4d75787b
      Dave Gordon authored
      During a hibernate/resume cycle, the whole system is reset, including
      the GuC and the doorbell hardware. Then the system is booted up, drivers
      are loaded, etc -- the GuC firmware may be loaded and set running at
      this point. But then, the booted kernel is replaced by the hibernated
      image, and this resumed kernel will also try to reload the GuC firmware
      (which will fail). To recover, we reset the GuC and try again (which
      should work). But this GuC reset doesn't also reset the doorbell
      hardware, so it can be left in a state inconsistent with that assumed
      by the driver and/or the newly-loaded GuC firmware.
      
      It would be better if the GuC reset also cleared all doorbell state,
      but that's not how the hardware currently works; also, the driver cannot
      directly reprogram the doorbell hardware (only the GuC can do that).
      
      So this patch cycles through all doorbells, assigning and releasing each
      in turn, so that all the doorbell hardware is left in a consistent
      state, no matter how it was programmed by the previously-running kernel
      and/or GuC firmware.
      
      v2: don't use kmap_atomic() now that client page 0 is kept mapped.
      Signed-off-by: default avatarDave Gordon <david.s.gordon@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1465837054-16245-2-git-send-email-david.s.gordon@intel.com
      4d75787b