Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 14 5月, 2020 2 次提交
  3. 13 5月, 2020 1 次提交
  5. 11 5月, 2020 1 次提交
  7. 09 5月, 2020 1 次提交
  9. 30 4月, 2020 1 次提交
  11. 17 4月, 2020 1 次提交
  13. 16 4月, 2020 1 次提交
  15. 04 4月, 2020 1 次提交
  17. 02 4月, 2020 1 次提交
  19. 26 3月, 2020 1 次提交
  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
  23. 17 3月, 2020 2 次提交
  25. 14 3月, 2020 1 次提交
  27. 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
  29. 06 3月, 2020 1 次提交
  31. 03 3月, 2020 6 次提交
  33. 02 3月, 2020 5 次提交
  35. 28 2月, 2020 1 次提交
  37. 26 2月, 2020 1 次提交
  39. 25 2月, 2020 3 次提交
  41. 21 2月, 2020 3 次提交
  43. 19 2月, 2020 1 次提交
  45. 17 2月, 2020 1 次提交
  47. 11 2月, 2020 1 次提交
  49. 06 2月, 2020 1 次提交
    • S
      drm/i915: Manipulate DBuf slices properly · 0f0f9aee
      由 Stanislav Lisovskiy 提交于 
      Start manipulating DBuf slices as a mask,
but not as a total number, as current approach
doesn't give us full control on all combinations
of slices, which we might need(like enabling S2
only can't enabled by setting enabled_slices=1).

Removed wrong code from intel_get_ddb_size as
it doesn't match to BSpec. For now still just
use DBuf slice until proper algorithm is implemented.

Other minor code refactoring to get prepared
for major DBuf assignment changes landed:
- As now enabled slices contain a mask
  we still need some value which should
  reflect how much DBuf slices are supported
  by the platform, now device info contains
  num_supported_dbuf_slices.
- Removed unneeded assertion as we are now
  manipulating slices in a more proper way.

v2: Start using enabled_slices in dev_priv

v3: "enabled_slices" is now "enabled_dbuf_slices_mask",
    as this now sits in dev_priv independently.

v4: - Fixed debug print formatting to hex(Matt Roper)
    - Optimized dbuf slice updates to be used only
      if slice union is different from current conf(Matt Roper)
    - Fixed some functions to be static(Matt Roper)
    - Created a parameterized version for DBUF_CTL to
      simplify DBuf programming cycle(Matt Roper)
    - Removed unrequred field from GEN10_FEATURES(Matt Roper)

v5: - Removed redundant programming dbuf slices helper(Ville Syrjälä)
    - Started to use parameterized loop for hw readout to get slices
      (Ville Syrjälä)
    - Added back assertion checking amount of DBUF slices enabled
      after DC states 5/6 transition, also added new assertion
      as starting from ICL DMC seems to restore the last DBuf
      power state set, rather than power up all dbuf slices
      as assertion was previously expecting(Ville Syrjälä)

v6: - Now using enum for DBuf slices in this patch (Ville Syrjälä)
    - Removed gen11_assert_dbuf_enabled and put gen9_assert_dbuf_enabled
      back, as we really need to have a single unified assert here
      however currently enabling always slice 1 is enforced by BSpec,
      so we will have to OR enabled slices mask with 1 in order
      to be consistent with BSpec, that way we can unify that
      assertion and against the actual state from the driver, but
      not some hardcoded value.(concluded with Ville)
    - Remove parameterized DBUF_CTL version, to extract it to another
      patch.(Ville Syrjälä)
v7:
    - Removed unneeded hardcoded return value for older gens from
      intel_enabled_dbuf_slices_mask - this now is handled in a
      unified manner since device info anyway returns max dbuf slices
      as 1 for older platforms(Matthew Roper)
    - Now using INTEL_INFO(dev_priv)->num_supported_dbuf_slices instead
      of intel_dbuf_max_slices function as it is trivial(Matthew Roper)

v8: - Fixed icl_dbuf_disable to disable all dbufs still(Ville Syrjälä)

v9: - Renamed _DBUF_CTL_S to DBUF_CTL_S(Ville Syrjälä)
    - Now using power_domain mutex to protect from race condition, which
      can occur because intel_dbuf_slices_update might be running in
      parallel to gen9_dc_off_power_well_enable being called from
      intel_dp_detect for instance, which causes assertion triggered by
      race condition, as gen9_assert_dbuf_enabled might preempt this
      when registers were already updated, while dev_priv was not.
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200202230630.8975-6-stanislav.lisovskiy@intel.com
      0f0f9aee