1. 26 5月, 2021 1 次提交
  2. 20 5月, 2021 3 次提交
  3. 15 5月, 2021 1 次提交
  4. 07 5月, 2021 1 次提交
  5. 01 5月, 2021 1 次提交
  6. 14 4月, 2021 5 次提交
  7. 29 3月, 2021 6 次提交
  8. 25 3月, 2021 3 次提交
  9. 24 3月, 2021 3 次提交
    • M
      drm/i915: Move cmd parser pinning to execbuffer · 0edbb9ba
      Maarten Lankhorst 提交于
      We need to get rid of allocations in the cmd parser, because it needs
      to be called from a signaling context, first move all pinning to
      execbuf, where we already hold all locks.
      
      Allocate jump_whitelist in the execbuffer, and add annotations around
      intel_engine_cmd_parser(), to ensure we only call the command parser
      without allocating any memory, or taking any locks we're not supposed to.
      
      Because i915_gem_object_get_page() may also allocate memory, add a
      path to i915_gem_object_get_sg() that prevents memory allocations,
      and walk the sg list manually. It should be similarly fast.
      
      This has the added benefit of being able to catch all memory allocation
      errors before the point of no return, and return -ENOMEM safely to the
      execbuf submitter.
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Acked-by: NThomas Hellström <thomas.hellstrom@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-4-maarten.lankhorst@linux.intel.com
      0edbb9ba
    • M
      drm/i915: Add DISPLAY_VER() and related macros · 01eb15c9
      Matt Roper 提交于
      Although we've long referred to platforms by a single "GEN" number, the
      hardware teams have recommended that we stop doing this since the
      various component IP blocks are going to start using independent number
      schemes with varying cadence.  To support this, hardware platforms a bit
      down the road are going to start providing MMIO registers that the
      driver can read to obtain the "graphics version," "media version," and
      "display version" without needing to do a PCI ID -> platform -> version
      translation.
      
      Although our current platforms don't yet expose these registers (and the
      next couple we release probably won't have them yet either), the
      hardware teams would still like to see us move to this independent
      numbering scheme now in preparation.  For i915 that means we should try
      to eliminate all usage of INTEL_GEN() throughout our code and instead
      replace it with separate GRAPHICS_VER(), MEDIA_VER(), and DISPLAY_VER()
      constructs in the code.  For old platforms, these will all usually give
      the same value for each IP block (aside from a few special cases like
      GLK which we can no more accurately represent as graphics=9 +
      display=10), but future platforms will have more flexibility to bump IP
      version numbers independently.
      
      The upcoming ADL-P platform will have a display version of 13 and a
      graphics version of 12, so let's just the first step of breaking out
      DISPLAY_VER(), but leaving the rest of INTEL_GEN() untouched for now.
      For now we'll automatically derive the display version from the
      platform's INTEL_GEN() value except in cases where an alternative
      display version is explicitly provided in the device info structure.
      
      We also add some helper macros IS_DISPLAY_VER(i915, ver) and
      IS_DISPLAY_RANGE(i915, from, until) that match the behavior of the
      existing gen-based macros.  However unlike IS_GEN(), we will implement
      those macros with direct comparisons rather than trying to maintain a
      mask to help compiler optimization.  In practice the optimization winds
      up not being used in very many places (since the vast majority of our
      platform checks are of the form "gen >= x") so there is pretty minimal
      size reduction in the final driver binary[1].  We're also likely going
      to need to extend these version numbers to non-integer major.minor
      values at some point in the future, so the mask approach won't work at
      all once we get to platforms like that.
      
       [1] The results before/after the next patch in this series, which
           switches our code over to the new display macros:
      
              $ size i915.ko.{orig,new}
                 text    data     bss     dec     hex filename
              2940291  102944    5384 3048619  2e84ab i915.ko.orig
              2940723  102956    5384 3049063  2e8667 i915.ko.new
      
      v2:
       - Move version into device info's display sub-struct. (Jani)
       - Add extra parentheses to macros.  (Jani)
       - Note the lack of genmask optimization in the display-based macros and
         give size data.  (Lucas)
      
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Lucas De Marchi <lucas.demarchi@intel.com>
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210320044245.3920043-3-matthew.d.roper@intel.com
      01eb15c9
    • M
      drm/i915/display: Convert gen5/gen6 tests to IS_IRONLAKE/IS_SANDYBRIDGE · d47d29a6
      Matt Roper 提交于
      ILK is the only platform that we consider "gen5" and SNB is the only
      platform we consider "gen6."  Add an IS_SANDYBRIDGE() macro and then
      replace numeric platform tests for these two generations with direct
      platform tests with the following Coccinelle semantic patch:
      
              @@ expression dev_priv; @@
              - IS_GEN(dev_priv, 5)
              + IS_IRONLAKE(dev_priv)
      
              @@ expression dev_priv; @@
              - IS_GEN(dev_priv, 6)
              + IS_SANDYBRIDGE(dev_priv)
      
              @@ expression dev_priv; @@
              - IS_GEN_RANGE(dev_priv, 5, 6)
              + IS_IRONLAKE(dev_priv) || IS_SANDYBRIDGE(dev_priv)
      
      This will simplify our upcoming patches which eliminate INTEL_GEN()
      usage in the display code.
      
      v2:
       - Reverse ilk/snb order for IS_GEN_RANGE conversion.  (Ville)
       - Rebase + regenerate from semantic patch
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210320044245.3920043-2-matthew.d.roper@intel.com
      d47d29a6
  10. 18 3月, 2021 6 次提交
  11. 12 3月, 2021 1 次提交
  12. 04 3月, 2021 1 次提交
  13. 13 2月, 2021 1 次提交
    • M
      drm/i915: FPGA_DBG is display-specific · a321c3c6
      Matt Roper 提交于
      Although the bspec's description doesn't make it very clear, the
      hardware architects have confirmed that the FPGA_DBG register that we
      use to check for unclaimed MMIO accesses is display-specific and will
      only properly flag unclaimed MMIO transactions for registers in the
      display range.  If a platform doesn't have display, FPGA_DBG itself will
      not be available and should not be checked.  Let's move the feature flag
      into intel_device_info.display to more accurately reflect this.
      
      Given that we now know FPGA_DBG is display-specific, it could be argued
      that we should only check it on out intel_de_*() functions.  However
      let's not make that change right now; keeping the checks in all of the
      existing locations still helps us catch cases where regular
      intel_uncore_*() functions use bad MMIO offset math / base addresses and
      accidentally wind up landing within an unused area within the display
      MMIO range.  It will also help catch cases where userspace-initiated
      MMIO (e.g., IGT's intel_reg tool) attempt to read bad offsets within the
      display range.
      
      v2:  Add missing hunk with the update to the HAS_FPGA_DBG_UNCLAIMED
           macro.  (CI)
      
      Cc: Lucas De Marchi <lucas.demarchi@intel.com>
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210212222049.3516344-1-matthew.d.roper@intel.com
      a321c3c6
  14. 09 2月, 2021 1 次提交
  15. 08 2月, 2021 1 次提交
  16. 05 2月, 2021 2 次提交
    • G
      drm/i915/display: Support PSR Multiple Instances · b64d6c51
      Gwan-gyeong Mun 提交于
      It is a preliminary work for supporting multiple EDP PSR and
      DP PanelReplay. And it refactors singleton PSR to Multi Transcoder
      supportable PSR.
      And this moves and renames the i915_psr structure of drm_i915_private's to
      intel_dp's intel_psr structure.
      It also causes changes in PSR interrupt handling routine for supporting
      multiple transcoders. But it does not change the scenario and timing of
      enabling and disabling PSR. And it not support multiple pipes with
      a single transcoder PSR case yet.
      
      v2: Fix indentation and add comments
      v3: Remove Blank line
      v4: Rebased
      v5: Rebased and Addressed Anshuman's review comment.
          - Move calling of intel_psr_init() to intel_dp_init_connector()
      v6: Address Anshuman's review comments
         - Remove wrong comments and add comments for a limit of supporting of
           a single pipe PSR
      v7: Update intel_psr_compute_config() for supporting multiple transcoder
          PSR on BDW+
      v8: Address Anshuman's review comments
         - Replace DRM_DEBUG_KMS with drm_dbg_kms() / DRM_WARN with drm_warn()
      v9: Fix commit message
      v10: Rebased
      v11: Address Jose's review comment.
        - Reorder calling order of intel_psr2_program_trans_man_trk_ctl().
        - In order to reduce changes keep the old name for drm_i915_private.
        - Change restrictions of multiple instances of PSR.
      v12: Address Jose's review comment.
        - Change the calling of intel_psr2_program_trans_man_trk_ctl() into
          commit_pipe_config().
        - Change a checking order of CAN_PSR() and connector_status to original
          on i915_psr_sink_status_show().
        - Drop unneeded intel_dp_update_pipe() function.
        - In order to wait a specific encoder which belong to crtc_state on
          intel_psr_wait_for_idle(), add checking of encoder.
        - Add an whitespace to comments.
      v13: Rebased and Address Jose's review comment.
        - Add and use for_each_intel_psr_enabled_encoder() macro.
        - In order to use correct frontbuffer_bit for each pipe,
          fix intel_psr_invalidate() and intel_psr_flush().
        - Remove redundant or unneeded codes.
        - Update comments.
      v14: Address Jose's review comment
        - Add and use for_each_intel_encoder_can_psr() macro and
          for_each_intel_encoder_mask_can_psr() macro.
        - Add source_support member variable into intel_psr structure.
        - Update CAN_PSR() macro that checks source_support.
        - Move encoder's PSR availity check to psr_init() from
          psr_compute_config().
        - Remove redundant or unneeded codes.
      v15: Remove wrong mutex lock/unlock of PSR from
           intel_psr2_program_trans_man_trk_ctl()
      Signed-off-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>
      Cc: José Roberto de Souza <jose.souza@intel.com>
      Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
      Cc: Anshuman Gupta <anshuman.gupta@intel.com>
      Reviewed-by: NAnshuman Gupta <anshuman.gupta@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/20210204134015.419036-1-gwan-gyeong.mun@intel.com
      b64d6c51
    • C
      drm/i915/display: support ddr5 mem types · 1f1257a6
      Clint Taylor 提交于
      Add DDR5 and LPDDR5 return values from punit fw.
      
      BSPEC: 54023
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Cc: José Roberto de Souza <jose.souza@intel.com>
      Signed-off-by: NClint Taylor <clinton.a.taylor@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/20210204200458.21875-1-clinton.a.taylor@intel.com
      1f1257a6
  17. 02 2月, 2021 1 次提交
  18. 01 2月, 2021 1 次提交
  19. 29 1月, 2021 1 次提交