An error occurred fetching the project authors.
  1. 11 Oct, 2013 1 commit
    • Daniel Vetter's avatar
      drm/i915: Kconfig option to disable the legacy fbdev support · 4520f53a
      Daniel Vetter authored
      Boots Just Fine (tm)!
      
      The only glitch seems to be that at least on Fedora the boot splash
      gets confused and doesn't display much at all.
      
      And since there's no ugly console flickering anymore in between, the
      flicker while switching between X servers (VT support is still enabled)
      is even more jarring.
      
      Also, I'm unsure whether we don't need to somehow kick out vgacon, now
      that nothing else gets in the way. But stuff seems to work, so I
      don't care. Also everything still works as well with VGA_CONSOLE=n
      
      Also the #ifdef mess needs a bit of a cleanup, follow-up patches will
      do just that.
      
      To keep the Kconfig tidy, extract all the i915 options into its own
      file.
      
      v2:
      - Rebase on top of the preliminary hw support option and the
        intel_drv.h cleanup.
      - Shut up warnings in i915_debugfs.c
      
      v3: Use the right CONFIG variable, spotted by Chon Ming.
      
      Cc: Lee, Chon Ming <chon.ming.lee@intel.com>
      Cc: David Herrmann <dh.herrmann@gmail.com>
      Reviewed-by: default avatarChon Ming Lee <chon.ming.lee@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      4520f53a
  2. 10 Oct, 2013 4 commits
  3. 09 Oct, 2013 1 commit
  4. 03 Oct, 2013 1 commit
    • Chris Wilson's avatar
      drm/i915: Boost RPS frequency for CPU stalls · b29c19b6
      Chris Wilson authored
      If we encounter a situation where the CPU blocks waiting for results
      from the GPU, give the GPU a kick to boost its the frequency.
      
      This should work to reduce user interface stalls and to quickly promote
      mesa to high frequencies - but the cost is that our requested frequency
      stalls high (as we do not idle for long enough before rc6 to start
      reducing frequencies, nor are we aggressive at down clocking an
      underused GPU). However, this should be mitigated by rc6 itself powering
      off the GPU when idle, and that energy use is dependent upon the workload
      of the GPU in addition to its frequency (e.g. the math or sampler
      functions only consume power when used). Still, this is likely to
      adversely affect light workloads.
      
      In particular, this nearly eliminates the highly noticeable wake-up lag
      in animations from idle. For example, expose or workspace transitions.
      (However, given the situation where we fail to downclock, our requested
      frequency is almost always the maximum, except for Baytrail where we
      manually downclock upon idling. This often masks the latency of
      upclocking after being idle, so animations are typically smooth - at the
      cost of increased power consumption.)
      
      Stéphane raised the concern that this will punish good applications and
      reward bad applications - but due to the nature of how mesa performs its
      client throttling, I believe all mesa applications will be roughly
      equally affected. To address this concern, and to prevent applications
      like compositors from permanently boosting the RPS state, we ratelimit the
      frequency of the wait-boosts each client recieves.
      
      Unfortunately, this techinique is ineffective with Ironlake - which also
      has dynamic render power states and suffers just as dramatically. For
      Ironlake, the thermal/power headroom is shared with the CPU through
      Intelligent Power Sharing and the intel-ips module. This leaves us with
      no GPU boost frequencies available when coming out of idle, and due to
      hardware limitations we cannot change the arbitration between the CPU and
      GPU quickly enough to be effective.
      
      v2: Limit each client to receiving a single boost for each active period.
          Tested by QA to only marginally increase power, and to demonstrably
          increase throughput in games. No latency measurements yet.
      
      v3: Cater for front-buffer rendering with manual throttling.
      
      v4: Tidy up.
      
      v5: Sadly the compositor needs frequent boosts as it may never idle, but
      due to its picking mechanism (using ReadPixels) may require frequent
      waits. Those waits, along with the waits for the vrefresh swap, conspire
      to keep the GPU at low frequencies despite the interactive latency. To
      overcome this we ditch the one-boost-per-active-period and just ratelimit
      the number of wait-boosts each client can receive.
      Reported-and-tested-by: default avatarPaul Neumann <paul104x@yahoo.de>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Kenneth Graunke <kenneth@whitecape.org>
      Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
      Cc: Owen Taylor <otaylor@redhat.com>
      Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
      Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      [danvet: No extern for function prototypes in headers.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b29c19b6
  5. 01 Oct, 2013 10 commits
  6. 20 Sep, 2013 2 commits
  7. 17 Sep, 2013 2 commits
  8. 16 Sep, 2013 4 commits
  9. 13 Sep, 2013 2 commits
  10. 10 Sep, 2013 1 commit
  11. 08 Sep, 2013 1 commit
  12. 06 Sep, 2013 1 commit
    • Ville Syrjälä's avatar
      drm/i915: Delay disabling of VGA memory until vgacon->fbcon handoff is done · 6e1b4fda
      Ville Syrjälä authored
      When transitioning away from vgacon the system tries to save the
      current contents of the VGA memory, so that it can be cleanly handed
      off to fbcon (or whatever comes afterwards).
      
      The recent change
      
       commit 81b5c7bc
       Author: Alex Williamson <alex.williamson@redhat.com>
       Date:   Wed Aug 28 09:39:08 2013 -0600
      
          i915: Update VGA arbiter support for newer devices
      
      caused i915 to disable VGA memory decode for the IGD when i915 is
      initializing. Unfortunately that happens before the vgacon->fbcon
      handoff so vgacon_save_screen() will read out all ones from the
      VGA memory.
      
      After the handoff fbcon will inherit the bogus state from vgacon,
      and pre-fills the fb with matching contents. The end result is
      a white rectangle in the top left corner of the screen, the size
      of which matches the now inactive VGA console.
      
      To remedy the situation delay the disabling of VGA memory until
      the vgacon->fbcon handoff has happened.
      
      Also rename i915_enable_vga to i915_enable_vga_mem to make
      the relationship between these functions clearer.
      
      Cc: Alex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      6e1b4fda
  13. 04 Sep, 2013 3 commits
  14. 03 Sep, 2013 1 commit
    • Ville Syrjälä's avatar
      drm/i915: Fix pipe config warnings when dealing with LVDS fixed mode · 4c6df4b4
      Ville Syrjälä authored
      intel_fixed_panel_mode() overwrote the adjusted_mode with the fixed mode
      only partially. Notably it forgot to copy over the sync flags. The LVDS code however programmed the hardware with the sync flags from fixed mode, and then later the pipe config comparison obviously failed as we
      filled out the adjusted_mode in get_config from the real registers.
      
      Just call drm_mode_copy() in intel_fixed_panel_mode() to copy over the
      whole thing, and then just use adjusted_mode in the LVDS code to figure
      out which sync settings the hardware needs.
      
      Also constify the fixed_mode argument to intel_fixed_panel_mode().
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      4c6df4b4
  15. 23 Aug, 2013 3 commits
    • Paulo Zanoni's avatar
      drm/i915: allow package C8+ states on Haswell (disabled) · c67a470b
      Paulo Zanoni authored
      This patch allows PC8+ states on Haswell. These states can only be
      reached when all the display outputs are disabled, and they allow some
      more power savings.
      
      The fact that the graphics device is allowing PC8+ doesn't mean that
      the machine will actually enter PC8+: all the other devices also need
      to allow PC8+.
      
      For now this option is disabled by default. You need i915.allow_pc8=1
      if you want it.
      
      This patch adds a big comment inside i915_drv.h explaining how it
      works and how it tracks things. Read it.
      
      v2: (this is not really v2, many previous versions were already sent,
           but they had different names)
          - Use the new functions to enable/disable GTIMR and GEN6_PMIMR
          - Rename almost all variables and functions to names suggested by
            Chris
          - More WARNs on the IRQ handling code
          - Also disable PC8 when there's GPU work to do (thanks to Ben for
            the help on this), so apps can run caster
          - Enable PC8 on a delayed work function that is delayed for 5
            seconds. This makes sure we only enable PC8+ if we're really
            idle
          - Make sure we're not in PC8+ when suspending
      v3: - WARN if IRQs are disabled on __wait_seqno
          - Replace some DRM_ERRORs with WARNs
          - Fix calls to restore GT and PM interrupts
          - Use intel_mark_busy instead of intel_ring_advance to disable PC8
      v4: - Use the force_wake, Luke!
      v5: - Remove the "IIR is not zero" WARNs
          - Move the force_wake chunk to its own patch
          - Only restore what's missing from RC6, not everything
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c67a470b
    • Paulo Zanoni's avatar
      drm/i915: wrap GEN6_PMIMR changes · edbfdb45
      Paulo Zanoni authored
      Just like we're doing with the other IMR changes.
      
      One of the functional changes is that not every caller was doing the
      POSTING_READ.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      edbfdb45
    • Paulo Zanoni's avatar
      drm/i915: wrap GTIMR changes · 43eaea13
      Paulo Zanoni authored
      Just like the functions that touch DEIMR and SDEIMR, but for GTIMR.
      The new functions contain a POSTING_READ(GTIMR) which was not present
      at the 2 callers inside i915_irq.c.
      
      The implementation is based on ibx_display_interrupt_update.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      43eaea13
  16. 09 Aug, 2013 3 commits