1. 05 Aug, 2015 11 commits
    • Thulasimani,Sivakumar's avatar
      drm/i915: read bpp from vbt only for older panels · 22ce5628
      Thulasimani,Sivakumar authored
      BPP bits defined in VBT should be used only on panels whose
      edid version is 1.3 or older. EDID version 1.4 introduced offsets
      where bpp is defined and read into display_info, hence bpp from
      VBT will be used only when bpc in display_info is zero.
      
      v2: use display_info.bpc for deciding when to use vbt_bpp (Jani)
      Signed-off-by: default avatarSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      22ce5628
    • Paulo Zanoni's avatar
      drm/i915/skl: send opregion_nofify_adapter(PCI_D1) instead of PCI_D3 · d37ae19a
      Paulo Zanoni authored
      I was told that the "repurposed D1 definition" is still valid for SKL.
      It is BDW that is special due to its hotplug bug, so let's
      special-case BDW instead of HSW.
      
      Cc: Kristen Carlson Accardi <kristen@linux.intel.com>
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d37ae19a
    • Damien Lespiau's avatar
      drm/i915: Extract a intel_power_well_disable() function · dcddab3a
      Damien Lespiau authored
      Similar to the ->enable vfunc in patch "drm/i915: Extract a
      intel_power_well_enable() function".
      
      v2 (from Paulo):
        - Same s/i915_/intel_/ bikeshed as the previous patch.
        - Update the commit hash.
      Signed-off-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      dcddab3a
    • Damien Lespiau's avatar
      drm/i915: Extract a intel_power_well_enable() function · e8ca9320
      Damien Lespiau authored
      We need a bit book keeping around power wells' ops->enable(), namely a
      nice debug message and updating hw_enabled. Let's introduce a
      intel_power_well_enable() function to make sure all the callers do the
      same things.
      
      v2 (from Paulo):
        - s/i915_power_well_enable/intel_power_well_enable/ since everything
          else on this file uses intel_ instead of i915_.
        - Fix typo in commit message.
      Signed-off-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e8ca9320
    • Marc Herbert's avatar
      drm/i915/skl: revert duplicated WaBarrierPerformanceFixDisable:skl · 0667405b
      Marc Herbert authored
      With this simple git diff command one can see that skl_init_workarounds()
      got two copies of WaBarrierPerformanceFixDisable:skl:
      
       git diff -U21 ca6e4405^1 ca6e4405 drivers/gpu/drm/i915/intel_ringbuffer.c
      
      This happened when the backmerge of drm-intel-fixes-2015-07-15
      Merged the same fix on both sides. Same fix but not identical enough for
      git: with a different surrounding context; hence the code duplication.
      
      This commit merely reverts the output of the git command above
       = the duplication introduced in the backmerge.
      
      (This duplication was found while running git sanity checks on a
      _linearized_ i915 forklift for ChromeOS.)
      Signed-off-by: default avatarMarc Herbert <marc.herbert@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0667405b
    • Rodrigo Vivi's avatar
      drm/i915: VLV/CHV PSR: Increase wait delay time before active PSR. · 30886c5a
      Rodrigo Vivi authored
      Since active function on VLV immediately activate PSR let's give more
      time for idleness. Different from core platforms where we have idle_frames
      count.
      
      Also kms_psr_sink_crc now is automated and always get this:
      
      [drm:intel_enable_pipe] enabling pipe A
      [drm:intel_edp_backlight_on]
      [drm:intel_panel_enable_backlight] pipe
      [drm:intel_panel_enable_backlight] pipe A
      [drm:intel_panel_actually_set_backlight] set backlight PWM = 7812
      
      PSR gets enabled somewhere here after backlight.
      
      [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x0
      [drm:vlv_pipe_set_fifo_size] Pipe A FIFO split 511 / 511 / 511
      [drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, cursor=63, sp
      
      PSR gets flushed around here by intel_atomic_commit
      
      [drm:vlv_pipe_set_fifo_size] Pipe A FIFO split 511 / 511 / 511
      [drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, cursor=63, sp
      [drm:intel_set_memory_cxsr] memory self-refresh is enabled
      [drm:intel_connector_check_state] [CONNECTOR:39:eDP-1]
      [drm:check_encoder_state] [ENCODER:30:DAC-30]
      [drm:check_encoder_state] [ENCODER:31:TMDS-31]
      [drm:check_encoder_state] [ENCODER:36:TMDS-36]
      [drm:check_encoder_state] [ENCODER:38:TMDS-38]
      [drm:check_crtc_state] [CRTC:21]
      [drm:check_crtc_state] [CRTC:26]
      [drm:intel_psr_activate [i915]] *ERROR* PSR Active
      [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x
      [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe A underrun
      [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO
      Underrun.
      
      It is true that in a product we won't keep disabling and enabling planes so
      frequently, but for safeness let's stay conservative.
      
      It is also true that 500ms is an etternity. But PSR is anyway a power saving
      feature for idle scenario. So if it is idle feature stays on and 500ms to get
      it reanabled is not that insane.
      
      v2: Rebase over intel_psr.c and fix typo.
      v3: Revival: Manual tests indicated that this is needed. With a short delay
          there is a huge risk of getting blank screens when planes are being enabled.
      v4: Revival 2 with reasonable delay. 1/2 sec instead of 5. VBT is 10 sec but
          actually time for link training what we aren't doing, but with only 100 sec
          in some cases kms_psr_sink_crc manual was showing blank screen,
          so let's use this for now. Also changed comment by a FIXME.
      v5: Rebase after a long time, remove FIXME and update comment above.
      v6: msecs_to_jiffies is already on delay. remove duplication.
      v7: use msecs_to_jiffies on schedule_delayed_work call.
      
      Reviewed-by: Durgadoss R <durgadoss.r@intel.com> (v4)
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      30886c5a
    • Rodrigo Vivi's avatar
      drm/i915: Split sink_crc function in start, stop and read. · 082dcc7c
      Rodrigo Vivi authored
      This is just a preparation patch to make clear what operation we
      are performing. There is no functional change on the sink crc
      logic.
      
      hsw_disable_ips has been moved a bit further in the start function
      to avoid disabling ips when sink crc is not going to be started.
      and to avoid goto on this function.
      
      v2: explain why hsw_disable_ips() call place has changed.
      
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarRafael Antognolli <rafael.antognolli@intel.com>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      082dcc7c
    • Paulo Zanoni's avatar
      drm/i915: special-case dirtyfb for frontbuffer tracking · 74b4ea1e
      Paulo Zanoni authored
      First, an introduction. We currently have two types of GTT mmaps: the
      "normal" old mmap, and the WC mmap. For frontbuffer-related features
      that have automatic hardware tracking, only the non-WC mmap writes are
      detected by the hardware. Since inside the Kernel both are treated as
      ORIGIN_GTT, any features ignoring ORIGIN_GTT because of the hardware
      tracking are destined to fail.
      
      One of the special rules defined for the WC mmaps is that the user
      should call the dirtyfb IOCTL after he is done using the pointers, so
      that results in an intel_fb_obj_flush() call. The problem is that the
      dirtyfb is passing ORIGIN_GTT, so it is being ignored by FBC - even
      though the hardware tracking is not detecing the WC mmap operations.
      So in order to fix that without having to give up the automatic
      hardware tracking for GTT mmaps we transform the flush operation from
      dirtyfb into a special operation: ORIGIN_DIRTYFB.
      
      This commit fixes all the kms_frontbuffer_tracking subtests that
      contain "fbc" and "mmap-wc" in their names and are currently failing
      (for a total of 16 subtests).
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      74b4ea1e
    • Paulo Zanoni's avatar
      drm/i915: don't disable FBC for pipe A when flipping pipe B · 4e1e26f1
      Paulo Zanoni authored
      Use the appropriate call.
      
      I know there's a discussion about whether we need this call here at
      all, but removing the call means we'll only update FBC after we get
      the page flip IRQ. So the user may only see the new frame a little
      after it should. Let's wait just a little bit more before removing
      this call since we can rely in the HW tracking for accurate flips.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      4e1e26f1
    • Paulo Zanoni's avatar
      drm/i915: don't call intel_fbc_update() at intel_unpin_work_fn() · 698e84ed
      Paulo Zanoni authored
      Because intel_unpin_work_fn() already calls
      intel_frontbuffer_flip_complete() which will call intel_fbc_flush()
      which will call intel_fbc_update() when needed.
      
      We couldn't fix this previously due to the fact that FBC was not
      properly behaving as intended on frontbuffer flushes, but now that
      this is fixed, we can remove the additional call.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      698e84ed
    • Paulo Zanoni's avatar
      drm/i915: fix FBC frontbuffer tracking flushing code · 6f4551fe
      Paulo Zanoni authored
      Due to the way busy_bits was handled, we were not doing any flushes if
      we didn't previously get an invalidate. Since it's possible to get
      flushes without an invalidate first, remove the busy_bits early
      return.
      
      So now that we don't have the busy_bits guard anymore we'll need the
      origin check for the GTT tracking (we were not doing anything on GTT
      flushes due to the GTT check at invalidate()).
      
      As a last detail, since we can get multiple consecutive flushes,
      disable FBC before updating it, otherwise intel_fbc_update() will just
      keep FBC enabled instead of restarting it.
      
      Notice that this does not fix any of the current IGT tests due to the
      fact that we still have a few intel_fbc() calls at points where we
      also have the frontbuffer tracking calls: we didn't fully convert to
      frontbuffer tracking yet. Once we remove those calls and start relying
      only on the frontbuffer tracking infrastructure we'll need this patch.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      6f4551fe
  2. 31 Jul, 2015 1 commit
  3. 29 Jul, 2015 4 commits
  4. 28 Jul, 2015 2 commits
    • Chris Wilson's avatar
      drm/i915: Keep the mm.bound_list in rough LRU order · 6c246959
      Chris Wilson authored
      When we shrink our working sets, we want to avoid stealing pages from
      objects that likely to be reused in the near future. We first look at
      inactive objects before processing active objects - but what about a
      recently active object that is about to be used again. That object's
      position in the bound_list is ordered by the time of binding, not the
      time of last use, so the most recently used inactive object could well
      be at the head of the shrink list. To compensate, give the object a bump
      to MRU when it becomes inactive (thus transitioning to the end of the
      first pass in shrink lists). Conversely, bumping on inactive makes
      bumping on active useless, since when we do have to reap from the active
      working set, everything is going to become inactive very quickly and the
      order pretty much random - just hope for the best at that point, as once
      we start stalling on active objects, we can hope that the rebinding
      neatly orders vital objects.
      Suggested-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      [danvet: Resolve merge conflict.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      6c246959
    • Daniel Vetter's avatar
      drm/i915: Fake AGP is dead · 3b9a02e8
      Daniel Vetter authored
      Remove the leftovers, yay!
      
      AGP for i915 kms died long ago with
      
      commit 3bb6ce66
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Wed Nov 13 22:14:16 2013 +0100
      
          drm/i915: Kill legeacy AGP for gen3 kms
      
      and with ums now gone to there's really no users any more.
      
      Note that device_is_agp is only called when DRIVER_USE_AGP is set and
      since we've unconditionally cleared that since a while there are
      really no users left for i915_driver_device_is_agp.
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      3b9a02e8
  5. 27 Jul, 2015 6 commits
  6. 22 Jul, 2015 3 commits
  7. 21 Jul, 2015 7 commits
  8. 20 Jul, 2015 1 commit
  9. 17 Jul, 2015 4 commits
  10. 15 Jul, 2015 1 commit
    • Daniel Vetter's avatar
      drm/i915: Invert fastboot check · 26495481
      Daniel Vetter authored
      Fastboot should only downgrade a modeset if we have a match, not be
      used to upgrade to a full modeset. Otherwise we can only use it in a
      very restricted way: Initial modeset when the request mode is the
      preferred one of the panel and there's still a pfit active. And that
      only works because our mode_from_pipe_config fills in the wrong mode
      (it takes the adjusted mode, not the requested one).
      
      But we want fast modesets everywhere even after boot-up (especially
      for testing, but not only there). Hence we need to be able to make any
      modeset a fast one, which means we need to invert the logic and
      optionally downgrade a modeset.
      
      Note that this needs ->connector_changed split out from ->mode_changed
      otherwise it's not going to work (because we might loose a modeset
      because connectors changed but otherwise the config matches). As soon
      as that's merged we can drop the i915.fastboot check from this code.
      
      Also make sure that we don't accidentally clear any_ms and that we add
      the planes for any kind of modeset.
      
      Finally rename fastboot to fastset (yeah it's a silly name) since this
      really isn't about booting all that much.
      
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      26495481