1. 17 11月, 2020 1 次提交
  2. 15 9月, 2020 1 次提交
  3. 11 9月, 2020 1 次提交
  4. 27 8月, 2020 1 次提交
  5. 18 8月, 2020 10 次提交
  6. 14 7月, 2020 1 次提交
  7. 08 7月, 2020 1 次提交
  8. 07 7月, 2020 1 次提交
  9. 03 7月, 2020 1 次提交
  10. 01 7月, 2020 2 次提交
  11. 27 6月, 2020 1 次提交
  12. 16 6月, 2020 1 次提交
  13. 11 6月, 2020 1 次提交
  14. 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
  15. 08 6月, 2020 1 次提交
  16. 05 6月, 2020 1 次提交
  17. 04 6月, 2020 1 次提交
  18. 01 6月, 2020 1 次提交
  19. 20 5月, 2020 1 次提交
  20. 19 5月, 2020 2 次提交
    • V
      drm/i915: Read out hrawclk on all gen3+ platforms · 488e0179
      Ville Syrjälä 提交于
      I've checked a bunch of gen3/4 machines and all seem to have
      consistent FSB frequency information in the CLKCFG register.
      So let's read out hrawclk on all gen3+ machines. Although
      apart from g4x/pnv aux/pps dividers we only really need this
      for for i965g/gm cs timestamp increment.
      
      The CLKCFG memory clock values seem less consistent but we
      don't care about those here.
      
      For posterity here's a list of CLKCFG vs. FSB dumps from
      a bunch of machines (only missing lpt for a full set):
      machine CLKCFG     FSB
      alv1    0x00001411 533
      alv2    0x00000420 400 (Chris)
      gdg1    0x20000022 800
      gdg2    0x20000022 800
      cst     0x00010043 666
      blb     0x00002034 1333
      pnv1    0x00000423 666
      pnv2    0x00000433 666
      965gm   0x00004342 800
      946gz   0x00000022 800
      965g    0x00000422 800
      g35     0x00000430 1066
              0x00000434 1333
      ctg1    0x00644056 1066
      ctg2    0x00644066 1066
      elk1    0x00012420 1066
              0x00012424 1333
              0x00012436 1600
              0x00012422 800
      elk2    0x00012040 1066
      
      For the mobile parts the chipset docs generally have these
      documented to some degree (alv being the exception).
      
      The two settings w/o any evidence are 0x5=400MHz on desktop
      and 0x7=1333MHz on mobile. Though the mobile 1333MHz case
      probably doesn't even exist since ctg is only documented
      to go up to 1066MHz.
      
      v2: Fix 400mhz readout for Chris's alv/celeron machine
          Do a clean mobile vs. dekstop split since that's really
          what seems to be going on
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200514123838.3017-3-ville.syrjala@linux.intel.comAcked-by: NChris Wilson <chris@chris-wilson.co.uk>
      488e0179
    • V
      drm/i915: Fix 400 MHz FSB readout on elk · 6f62bda1
      Ville Syrjälä 提交于
      Looks like elk redefines some of the CLKCFG FSB values to
      make room for 400 MHz FSB. The setting overlaps with one of
      the 266MHz settings (which is even documented in the ctg docs,
      and cofirmed to be correct on my ctg). So we limit the special
      case to elk only.
      
      Though it might also be that we have some kind of desktop vs.
      mobile difference going on here as eg. both g35 and elk
      use 0x0 for the 266 MHz setting, vs. 0x6 used by ctg). The
      g35 doesn't let me select 400MHz for the FSB strap so can't
      confirm which way it would go here. But anyways as it seems
      only elk has the 400MHz option we shouldn't lose anything
      by limiting the special case to it alone.
      
      My earlier experiments on this appear to have been nonsense as
      the comment I added claims that FSB strap of 400MHz results in
      a value of 0x4, but I've now retested it and I definitely get a
      value of 0x6 instead. So let's remove that bogus comment.
      
      v2: s/_ELK/_ALT/ in the define in anticipation of a full
          mobile vs. desktop CLKCFG split
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200514123838.3017-1-ville.syrjala@linux.intel.comAcked-by: NChris Wilson <chris@chris-wilson.co.uk>
      6f62bda1
  21. 08 5月, 2020 1 次提交
  22. 07 5月, 2020 2 次提交
  23. 06 5月, 2020 1 次提交
  24. 05 5月, 2020 1 次提交
  25. 02 5月, 2020 1 次提交
  26. 30 4月, 2020 1 次提交
  27. 26 4月, 2020 1 次提交
  28. 25 4月, 2020 1 次提交