1. 29 10月, 2020 1 次提交
  2. 24 10月, 2020 2 次提交
  3. 21 10月, 2020 2 次提交
  4. 20 10月, 2020 1 次提交
  5. 16 10月, 2020 4 次提交
  6. 10 10月, 2020 1 次提交
  7. 06 10月, 2020 2 次提交
    • I
      drm/i915/skl: Work around incorrect BIOS WRPLL PDIV programming · 7a8a95f5
      Imre Deak 提交于
      The BIOS of at least one ASUS-Z170M system with an SKL I have programs
      the 101b WRPLL PDIV divider value, which is the encoding for PDIV=7 with
      bit#0 incorrectly set.
      
      This happens with the
      
      "3840x2160": 30 262750 3840 3888 3920 4000 2160 2163 2168 2191 0x48 0x9
      
      HDMI mode (scaled from a 1024x768 src fb) set by BIOS and the
      
      ref_clock=24000, dco_integer=383, dco_fraction=5802, pdiv=7, qdiv=1, kdiv=1
      
      WRPLL parameters (assuming PDIV=7 was the intended setting). This
      corresponds to 262749 PLL frequency/port clock.
      
      Later the driver sets the same mode for which it calculates the same
      dco_int/dco_frac/div WRPLL parameters (with the correct PDIV=7 encoding).
      
      Based on the above, let's assume that PDIV=7 was intended and the HW
      just ignores bit#0 in the PDIV register field for this setting, treating
      100b and 101b encodings the same way.
      
      While at it add the MISSING_CASE() for the p0,p2 divider decodings.
      
      v2: (Ville)
      - Add a define for the incorrect divider value.
      - Emit only a debug message when detecting the incorrect divider value.
      - Use fallthrough from the incorrect divider value case.
      - Add the MISSING_CASE()s.
      
      v3: Return 0 freq for incorrect divider values. (Ville)
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20201006013555.1488262-1-imre.deak@intel.com
      7a8a95f5
    • M
      drm/i915/dg1: Wait for pcode/uncore handshake at startup · f9c730ed
      Matt Roper 提交于
      DG1 does some additional pcode/uncore handshaking at
      boot time; this handshaking must complete before various other pcode
      commands are effective and before general work is submitted to the GPU.
      We need to poll a new pcode mailbox during startup until it reports that
      this handshaking is complete.
      
      The bspec doesn't give guidance on how long we may need to wait for this
      handshaking to complete.  For now, let's just set a really long timeout;
      if we still don't get a completion status by the end of that timeout,
      we'll just continue on and hope for the best.
      
      v2 (Lucas): Rename macros to make clear the relation between command and
         result (requested by José)
      
      Bspec: 52065
      Cc: Clinton Taylor <Clinton.A.Taylor@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
      Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20201001063917.3133475-2-lucas.demarchi@intel.com
      f9c730ed
  8. 01 10月, 2020 1 次提交
  9. 28 9月, 2020 2 次提交
  10. 15 9月, 2020 1 次提交
  11. 11 9月, 2020 1 次提交
  12. 27 8月, 2020 1 次提交
  13. 18 8月, 2020 10 次提交
  14. 14 7月, 2020 1 次提交
  15. 08 7月, 2020 1 次提交
  16. 07 7月, 2020 1 次提交
  17. 03 7月, 2020 1 次提交
  18. 01 7月, 2020 2 次提交
  19. 27 6月, 2020 1 次提交
  20. 16 6月, 2020 1 次提交
  21. 11 6月, 2020 1 次提交
  22. 10 6月, 2020 1 次提交
    • M
      drm/i915/rkl: RKL uses ABOX0 for pixel transfers · 62afef28
      Matt Roper 提交于
      Rocket Lake uses the same 'abox0' mechanism to handle pixel data
      transfers from memory that gen11 platforms used, rather than the
      abox1/abox2 interfaces used by TGL/DG1.  For the most part this is a
      hardware implementation detail that's transparent to driver software,
      but we do have to program a couple of tuning registers (MBUS_ABOX_CTL
      and BW_BUDDY registers) according to which ABOX instances are used by a
      platform.  Let's track the platform's ABOX usage in the device info
      structure and use that to determine which instances of these registers
      to program.
      
      As an exception to this rule is that even though TGL/DG1 use ABOX1+ABOX2
      for data transfers, we're still directed to program the ABOX_CTL
      register for ABOX0; so we'll handle that as a special case.
      
      v2:
       - Store the mask of platform-specific abox registers in the device
         info structure.
       - Add a TLB_REQ_TIMER() helper macro.  (Aditya)
      
      v3:
       - Squash ABOX and BW_BUDDY patches together and use a single mask for
         both of them, plus a special-case for programming the ABOX0 instance
         on all gen12.  (Ville)
      
      Bspec: 50096
      Bspec: 49218
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Aditya Swarup <aditya.swarup@intel.com>
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200606025740.3308880-2-matthew.d.roper@intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      62afef28
  23. 08 6月, 2020 1 次提交