1. 25 Sep, 2019 1 commit
    • Maarten Lankhorst's avatar
      drm/i915/dp: Fix dsc bpp calculations, v5. · ed06efb8
      Maarten Lankhorst authored
      
      
      There was a integer wraparound when mode_clock became too high,
      and we didn't correct for the FEC overhead factor when dividing,
      with the calculations breaking at HBR3.
      
      As a result our calculated bpp was way too high, and the link width
      limitation never came into effect.
      
      Print out the resulting bpp calcululations as a sanity check, just
      in case we ever have to debug it later on again.
      
      We also used the wrong factor for FEC. While bspec mentions 2.4%,
      all the calculations use 1/0.972261, and the same ratio should be
      applied to data M/N as well, so use it there when FEC is enabled.
      
      This fixes the FIFO underrun we are seeing with FEC enabled.
      
      Changes since v2:
      - Handle fec_enable in intel_link_compute_m_n, so only data M/N is adjusted. (Ville)
      - Fix initial hardware readout for FEC. (Ville)
      Changes since v3:
      - Remove bogus fec_to_mode_clock. (Ville)
      Changes since v4:
      - Use the correct register for icl. (Ville)
      - Split hw readout to a separate patch.
      Signed-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Fixes: d9218c8f ("drm/i915/dp: Add helpers for Compressed BPP and Slice Count for DSC")
      Cc: <stable@vger.kernel.org> # v5.0+
      Cc: Manasi Navare <manasi.d.navare@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190925082110.17439-1-maarten.lankhorst@linux.intel.com
      
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      ed06efb8
  2. 23 Sep, 2019 4 commits
  3. 20 Sep, 2019 4 commits
  4. 19 Sep, 2019 2 commits
  5. 16 Sep, 2019 6 commits
  6. 13 Sep, 2019 2 commits
  7. 11 Sep, 2019 2 commits
  8. 06 Sep, 2019 1 commit
  9. 04 Sep, 2019 2 commits
  10. 03 Sep, 2019 1 commit
    • Chris Wilson's avatar
      drm/i915: Replace obj->pin_global with obj->frontbuffer · 5a90606d
      Chris Wilson authored
      
      
      obj->pin_global was originally used as a means to keep the shrinker off
      the active scanout, but we use the vma->pin_count itself for that and
      the obj->frontbuffer to delay shrinking active framebuffers. The other
      role that obj->pin_global gained was for spotting display objects inside
      GEM and working harder to keep those coherent; for which we can again
      simply inspect obj->frontbuffer directly.
      
      Coming up next, we will want to manipulate the pin_global counter
      outside of the principle locks, so would need to make pin_global atomic.
      However, since obj->frontbuffer is already managed atomically, it makes
      sense to use that the primary key for display objects instead of having
      pin_global.
      
      Ville pointed out the principle difference is that obj->frontbuffer is
      set for as long as an intel_framebuffer is attached to an object, but
      obj->pin_global was only raised for as long as the object was active. In
      practice, this means that we consider the object as being on the scanout
      for longer than is strictly required, causing us to be more proactive in
      flushing -- though it should be true that we would have flushed
      eventually when the back became the front, except that on the flip path
      that flush is async but when hit from another ioctl it will be
      synchronous.
      
      v2: i915_gem_object_is_framebuffer()
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190902040303.14195-5-chris@chris-wilson.co.uk
      5a90606d
  11. 02 Sep, 2019 1 commit
  12. 30 Aug, 2019 1 commit
  13. 29 Aug, 2019 2 commits
  14. 28 Aug, 2019 1 commit
    • Imre Deak's avatar
      drm/i915: Align power domain names with port names · 8a84bacb
      Imre Deak authored
      
      
      There is a difference in BSpec's and the driver's designation of DDI
      ports. BSpec uses the following names:
      - before GEN11:
        BSpec/driver:
        	port A/B/C/D etc
      - GEN11:
        BSpec/driver:
      	port A-F
      - GEN12:
        BSpec:
        	port A/B/C for combo PHY ports
      	port TC1-6 for Type C PHY ports
        driver:
      	port A-I.
        The driver's port D name matches BSpec's TC1 port name.
      
      So far power domains were named according to the BSpec designation, to
      make it easier to match the code against the specification. That however
      can be confusing when a power domain needs to be matched to a port on
      GEN12+. To resolve that use the driver's port A-I designation for power
      domain names too and rename the corresponding power wells so that they
      reflect the mapping from the driver's to BSpec's port name.
      
      Cc: Lucas De Marchi <lucas.demarchi@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190823100711.27833-1-imre.deak@intel.com
      8a84bacb
  15. 27 Aug, 2019 1 commit
  16. 23 Aug, 2019 2 commits
  17. 20 Aug, 2019 1 commit
    • Lucas De Marchi's avatar
      drm/i915/tgl: disable DDIC · ea6591b4
      Lucas De Marchi authored
      
      
      The current SKUs added for Tiger Lake don't have DDIC hooked up, even
      though it is supported by the SoC. The current state for these SKUs is
      problematic since while enabling the combo phy, PORT_COMP_DW* return
      0xFFFFFFFF, which is invalid per register definition.
      
      During initialization we check what phys are not yet enabled by reading
      PHY_MISC_C and try to enable it by toggling the "DE to IO Comp Pwr Down"
      bit.  But after that any read to the PORT_COMP_DW* returns invalid
      results. This removes the following warning
      
      [56997.634353] Missing case (val == 4294967295)
      [56997.639241] WARNING: CPU: 5 PID: 768 at drivers/gpu/drm/i915/display/intel_combo_phy.c:54 cnl_get_procmon_ref_values+0xc9/0xf0 [i915]
      [56997.639808] Modules linked in: i915(+) prime_numbers x86_pkg_temp_thermal coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel e1000e [last unloaded: prime_numbers]
      [56997.639808] CPU: 5 PID: 768 Comm: insmod Tainted: G     U  W         5.2.0-demarchi+ #65
      [56997.639808] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.R00.2252.A03.1906270154 06/27/2019
      [56997.639808] RIP: 0010:cnl_get_procmon_ref_values+0xc9/0xf0 [i915]
      [56997.639808] Code: 2c a0 85 c9 74 e0 81 f9 00 00 00 01 75 09 48 c7 c0 0c a4 2c a0 eb cf 48 c7 c6 3c 3a 31 a0 48 c7 c7 40 3a 31 a0 e8 6b 4d ea e0 <0f> 0b 48 c7 c0 00 a4 2c a0 eb b1 48 c7 c0 24 a4 2
      c a0 eb a8 e8 be
      [56997.639808] RSP: 0018:ffffc9000068f8a8 EFLAGS: 00010286
      [56997.639808] RAX: 0000000000000000 RBX: ffff88848fa90000 RCX: 0000000000000000
      [56997.639808] RDX: ffff8884a08b5ef8 RSI: ffff8884a08a6658 RDI: 00000000ffffffff
      [56997.639808] RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000
      [56997.639808] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88848fa90000
      [56997.639808] R13: 0000000000000000 R14: 0000000000000002 R15: 0006c00000162000
      [56997.639808] FS:  00007f61ca3d12c0(0000) GS:ffff8884a0880000(0000) knlGS:0000000000000000
      [56997.639808] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [56997.639808] CR2: 00007f71be6a92c0 CR3: 0000000494750006 CR4: 0000000000760ee0
      [56997.639808] PKRU: 55555554
      [56997.639808] Call Trace:
      [56997.639808]  cnl_verify_procmon_ref_values+0x36/0xf0 [i915]
      [56997.639808]  ? rcu_read_lock_sched_held+0x6f/0x80
      [56997.639808]  ? gen11_fwtable_read32+0x257/0x290 [i915]
      [56997.639808]  icl_combo_phy_verify_state.part.0+0x22/0xa0 [i915]
      [56997.639808]  intel_combo_phy_init+0x17e/0x3e0 [i915]
      [56997.639808]  ? icl_display_core_init+0x2c/0x1a0 [i915]
      [56997.639808]  ? _raw_spin_unlock_irqrestore+0x4c/0x60
      [56997.639808]  icl_display_core_init+0x34/0x1a0 [i915]
      [56997.639808]  intel_power_domains_init_hw+0x200/0x570 [i915]
      [56997.639808]  i915_driver_probe+0x103b/0x17e0 [i915]
      [56997.639808]  ? printk+0x53/0x6a
      [56997.639808]  i915_pci_probe+0x3b/0x190 [i915]
      
      We may or may not need to change the implementation to account for DDIC
      being available on other SKUs. For now I think the best thing to do is
      to just disable the port.
      
      Cc: José Roberto de Souza <jose.souza@intel.com>
      Signed-off-by: default avatarLucas De Marchi <lucas.demarchi@intel.com>
      Reviewed-by: default avatarUma Shankar <uma.shankar@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190814235517.10032-1-lucas.demarchi@intel.com
      ea6591b4
  18. 16 Aug, 2019 2 commits
  19. 14 Aug, 2019 1 commit
  20. 13 Aug, 2019 1 commit
  21. 08 Aug, 2019 2 commits