1. 23 6月, 2020 1 次提交
    • J
      drm/i915/params: switch to device specific parameters · 8a25c4be
      Jani Nikula 提交于
      Start using device specific parameters instead of module parameters for
      most things. The module parameters become the immutable initial values
      for i915 parameters. The device specific parameters in i915->params
      start life as a copy of i915_modparams. Any later changes are only
      reflected in the debugfs.
      
      The stragglers are:
      
      * i915.force_probe and i915.modeset. Needed before dev_priv is
        available. This is fine because the parameters are read-only and never
        modified.
      
      * i915.verbose_state_checks. Passing dev_priv to I915_STATE_WARN and
        I915_STATE_WARN_ON would result in massive and ugly churn. This is
        handled by not exposing the parameter via debugfs, and leaving the
        parameter writable in sysfs. This may be fixed up in follow-up work.
      
      * i915.inject_probe_failure. Only makes sense in terms of the module,
        not the device. This is handled by not exposing the parameter via
        debugfs.
      
      v2: Fix uc i915 lookup code (Michał Winiarski)
      
      Cc: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com>
      Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com>
      Cc: Michał Winiarski <michal.winiarski@intel.com>
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Acked-by: NMichał Winiarski <michal.winiarski@intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20200618150402.14022-1-jani.nikula@intel.com
      8a25c4be
  2. 05 6月, 2020 1 次提交
  3. 04 6月, 2020 1 次提交
  4. 03 6月, 2020 1 次提交
  5. 22 5月, 2020 1 次提交
    • S
      drm/i915: Adjust CDCLK accordingly to our DBuf bw needs · cd191546
      Stanislav Lisovskiy 提交于
      According to BSpec max BW per slice is calculated using formula
      Max BW = CDCLK * 64. Currently when calculating min CDCLK we
      account only per plane requirements, however in order to avoid
      FIFO underruns we need to estimate accumulated BW consumed by
      all planes(ddb entries basically) residing on that particular
      DBuf slice. This will allow us to put CDCLK lower and save power
      when we don't need that much bandwidth or gain additional
      performance once plane consumption grows.
      
      v2: - Fix long line warning
          - Limited new DBuf bw checks to only gens >= 11
      
      v3: - Lets track used Dbuf bw per slice and per crtc in bw state
            (or may be in DBuf state in future), that way we don't need
            to have all crtcs in state and those only if we detect if
            are actually going to change cdclk, just same way as we
            do with other stuff, i.e intel_atomic_serialize_global_state
            and co. Just as per Ville's paradigm.
          - Made dbuf bw calculation procedure look nicer by introducing
            for_each_dbuf_slice_in_mask - we often will now need to iterate
            slices using mask.
          - According to experimental results CDCLK * 64 accounts for
            overall bandwidth across all dbufs, not per dbuf.
      
      v4: - Fixed missing const(Ville)
          - Removed spurious whitespaces(Ville)
          - Fixed local variable init(reduced scope where not needed)
          - Added some comments about data rate for planar formats
          - Changed struct intel_crtc_bw to intel_dbuf_bw
          - Moved dbuf bw calculation to intel_compute_min_cdclk(Ville)
      
      v5: - Removed unneeded macro
      
      v6: - Prevent too frequent CDCLK switching back and forth:
            Always switch to higher CDCLK when needed to prevent bandwidth
            issues, however don't switch to lower CDCLK earlier than once
            in 30 minutes in order to prevent constant modeset blinking.
            We could of course not switch back at all, however this is
            bad from power consumption point of view.
      
      v7: - Fixed to track cdclk using bw_state, modeset will be now
            triggered only when CDCLK change is really needed.
      
      v8: - Lock global state if bw_state->min_cdclk is changed.
          - Try getting bw_state only if there are crtcs in the commit
            (need to have read-locked global state)
      
      v9: - Do not do Dbuf bw check for gens < 9 - triggers WARN
            as ddb_size is 0.
      
      v10: - Lock global state for older gens as well.
      
      v11: - Define new bw_calc_min_cdclk hook, instead of using
             a condition(Manasi Navare)
      
      v12: - Fixed rebase conflict
      
      v13: - Added spaces after declarations to make checkpatch happy.
      Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
      Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
      Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200520150058.16123-1-stanislav.lisovskiy@intel.com
      cd191546
  6. 20 5月, 2020 1 次提交
  7. 19 5月, 2020 1 次提交
  8. 16 5月, 2020 1 次提交
  9. 15 5月, 2020 2 次提交
  10. 14 5月, 2020 2 次提交
  11. 13 5月, 2020 1 次提交
  12. 11 5月, 2020 1 次提交
  13. 09 5月, 2020 1 次提交
  14. 30 4月, 2020 1 次提交
  15. 21 4月, 2020 1 次提交
  16. 17 4月, 2020 1 次提交
  17. 16 4月, 2020 1 次提交
  18. 04 4月, 2020 1 次提交
  19. 02 4月, 2020 1 次提交
  20. 26 3月, 2020 2 次提交
    • D
      drm/i915: Use drmm_add_final_kfree · 7fb81e9d
      Daniel Vetter 提交于
      With this we can drop the final kfree from the release function.
      
      The mock device in the selftests needed it's pci_device split
      up from the drm_device. In the future we could simplify this again
      by allocating the pci_device as a managed allocation too.
      
      v2: I overlooked that i915_driver_destroy is also called in the
      unwind code of the error path. There we need a drm_dev_put.
      Similar for the mock object.
      
      Now the problem with that is that the drm_driver->release callbacks
      for both the real driver and the mock one assume everything has been
      set up. Hence going through that path for a partially set up driver
      will result in issues. Quickest fix is to disable the ->release() hook
      until the driver is fully initialized, and keep the onion unwinding.
      Long term would be cleanest to move everything over to drmm_ release
      actions, but that's a lot of work for a big driver like i915. Plus
      more core work needed first anyway.
      
      v3: Fix i915_drm pointer wrangling in mock_gem_device. Also switch
      over to start using drm_dev_put() to clean up even on the error path.
      Aside I think the current error path is leaking the allocation.
      
      v4: more fixes for intel-gfx-ci, some if it damage from v3 :-/
      Reviewed-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Matthew Auld <matthew.auld@intel.com>
      Cc: Andi Shyti <andi.shyti@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
      Cc: intel-gfx@lists.freedesktop.org
      Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-9-daniel.vetter@ffwll.ch
      7fb81e9d
    • C
      drm/i915: Drop final few uses of drm_i915_private.engine · 73c8bfb7
      Chris Wilson 提交于
      We've migrated all the heavy users over to the intel_gt, and can finally
      drop the last few users and with that the mirror in dev_priv->engine[].
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Andi Shyti <andi.shyti@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200325234803.6175-1-chris@chris-wilson.co.uk
      73c8bfb7
  21. 25 3月, 2020 1 次提交
    • J
      drm/i915/display/fbc: Make fences a nice-to-have for GEN9+ · 691f7ba5
      José Roberto de Souza 提交于
      dGFX has local memory so it does not have aperture or support
      CPU fences but even for iGFX it have a small number of fences.
      
      As replacement for fences to track frontbuffer modifications by CPU
      we have a software tracking that is already in used by FBC and PSR.
      PSR don't support fences so it shows that this tracking is reliable.
      
      So lets make fences a nice-to-have to activate FBC for GEN9+, this
      will allow us to enable FBC for dGFXs and iGFXs even when there is no
      available fence.
      
      We do not set fences to rotated planes but FBC only have restrictions
      against 16bpp, so adding it here.
      
      Also adding a new check for the tiling format, fences are only set
      to X and Y tiled planes but again FBC don't have any restrictions
      against tiling so adding linear as supported as well, other formats
      should be added after tested but IGT only supports drawing in thse
      3 formats.
      
      intel_fbc_hw_tracking_covers_screen() maybe can also have the same
      treatment as fences but BSpec is not clear if the size limitation is
      for hardware tracking or general use of FBC and I don't have a 5K
      display to test it, so keeping as is for safety.
      
      v2:
      - Added tiling and pixel format rotation checks
      - Changed the GEN version not requiring fences to 11 from 9, DDX
      needs some changes but it don't have support for GEN11+
      
      v3:
      - Changed back to GEN9+
      - Moved GEN test to inside of tiling_is_valid()
      
      v4:
      - moved rotation check to its own functions
      
      v5:
      - renamed rotations_is_valid to rotation_is_valid
      - moved pre-g4x rotation check to rotation_is_valid()
      
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200319211535.114625-1-jose.souza@intel.com
      691f7ba5
  22. 17 3月, 2020 2 次提交
  23. 14 3月, 2020 1 次提交
  24. 07 3月, 2020 1 次提交
    • V
      drm/i915/hotplug: Use phy to get the hpd_pin instead of the port (v5) · 270810a7
      Vivek Kasireddy 提交于
      On some platforms such as Elkhart Lake, although we may use DDI D
      to drive a connector, we have to use PHY A (Combo Phy PORT A) to
      detect the hotplug interrupts as per the spec because there is no
      one-to-one mapping between DDIs and PHYs. Therefore, use the
      function intel_port_to_phy() which contains the logic for such
      mapping(s) to find the correct hpd_pin.
      
      This change should not affect other platforms as there is always
      a one-to-one mapping between DDIs and PHYs.
      
      v2:
      - Convert the case statements to use PHYs instead of PORTs (Jani)
      
      v3:
      - Refactor the function to reduce the number of return statements by
        lumping all the case statements together except PHY_F which needs
        special handling (Jose)
      
      v4:
      - Add a comment describing how the HPD pin value associated with any
        port can be retrieved using port or phy enum value. (Jani)
      
      v5:
      - Use case ranges instead of individual labels and also normalize the
        return statement by adding -PHY_A to the expression (Ville)
      
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Cc: José Roberto de Souza <jose.souza@intel.com>
      Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
      Signed-off-by: NVivek Kasireddy <vivek.kasireddy@intel.com>
      Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
      Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200304234240.12062-1-vivek.kasireddy@intel.com
      270810a7
  25. 06 3月, 2020 1 次提交
  26. 03 3月, 2020 6 次提交
  27. 02 3月, 2020 5 次提交