1. 19 Apr, 2022 2 commits
  2. 13 Apr, 2022 7 commits
  3. 12 Apr, 2022 11 commits
  4. 11 Apr, 2022 4 commits
    • Lucas De Marchi's avatar
      drm/i915/dg2: Do not explode on phy calibration error · 82c362f2
      Lucas De Marchi authored
      When the PHY fails on calibration we were previously skipping the ddi
      initialization. However the driver is not really prepared for that,
      ultimately leading to a NULL pointer dereference:
      
      [   75.748348] i915 0000:03:00.0: [drm:intel_modeset_init_nogem [i915]] SNPS PHY A failed to calibrate; output will not be used.
      ...
      [   75.750336] i915 0000:03:00.0: [drm:intel_modeset_setup_hw_state [i915]] [CRTC:80:pipe A] hw state readout: enabled
      ...
      
      ( no DDI A/PHY A )
      [   75.753080] i915 0000:03:00.0: [drm:intel_modeset_setup_hw_state [i915]] [ENCODER:235:DDI B/PHY B] hw state readout: disabled, pipe A
      [   75.753164] i915 0000:03:00.0: [drm:intel_modeset_setup_hw_state [i915]] [ENCODER:245:DDI C/PHY C] hw state readout: disabled, pipe A
      ...
      [   75.754425] i915 0000:03:00.0: [drm] *ERROR* crtc 80: Can't calculate constants, dotclock = 0!
      [   75.765558] i915 0000:03:00.0: drm_WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev))
      [   75.765569] WARNING: CPU: 5 PID: 1759 at drivers/gpu/drm/drm_vblank.c:728 drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x347/0x360
      ...
      [   75.781230] BUG: kernel NULL pointer dereference, address: 000000000000007c
      [   75.788198] #PF: supervisor read access in kernel mode
      [   75.793347] #PF: error_code(0x0000) - not-present page
      [   75.798480] PGD 0 P4D 0
      [   75.801019] Oops: 0000 [#1] PREEMPT SMP NOPTI
      [   75.805377] CPU: 5 PID: 1759 Comm: modprobe Tainted: G        W         5.18.0-rc1-demarchi+ #199
      [   75.827613] RIP: 0010:icl_aux_power_well_disable+0x3b/0x200 [i915]
      [   75.833890] Code: 83 ec 30 65 48 8b 04 25 28 00 00 00 48 89 44 24 28 48 8b 06 0f b6 70 1c f6 40 20 04 8d 56 fa 0f 45 f2 e8 88 bd ff ff 48 89 ef <8b> 70 7c e8 ed 67 ff ff 48 89 ef 89 c6 e8 73 67 ff ff 84 c0 75 0a
      [   75.852629] RSP: 0018:ffffc90003a7fb30 EFLAGS: 00010246
      [   75.857852] RAX: 0000000000000000 RBX: ffff8881145e8f10 RCX: 0000000000000000
      [   75.864978] RDX: ffff888115220840 RSI: 0000000000000000 RDI: ffff888115220000
      [   75.872106] RBP: ffff888115220000 R08: ffff88888effffe8 R09: 00000000fffdffff
      [   75.879234] R10: ffff88888e200000 R11: ffff88888ed00000 R12: ffff8881145e8f10
      [   75.886363] R13: 0000000000000001 R14: ffff888115223240 R15: 0000000000000000
      [   75.893490] FS:  00007ff6e753a740(0000) GS:ffff88888f680000(0000) knlGS:0000000000000000
      [   75.901573] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   75.907313] CR2: 000000000000007c CR3: 00000001216a6001 CR4: 0000000000770ee0
      [   75.914446] PKRU: 55555554
      [   75.917153] Call Trace:
      [   75.919603]  <TASK>
      [   75.921709]  intel_power_domains_sanitize_state+0x88/0xb0 [i915]
      [   75.927814]  intel_modeset_init_nogem+0x317/0xef0 [i915]
      [   75.933205]  i915_driver_probe+0x5f6/0xdf0 [i915]
      [   75.937976]  i915_pci_probe+0x51/0x1d0 [i915]
      
      We skip the initialization of PHY A, but later we try to find out what
      is the phy for that power well and dereference dig_port, which is NULL.
      
      Failing the PHY calibration could be left as a warning or error, like it
      was before commit b4eb76d8 ("drm/i915/dg2: Skip output init on PHY
      calibration failure"). However that often fails for outputs not being
      used, which would make the warning/error appear on systems that have no
      visible issues. Anyway, there is still a need to fix those failures,
      but that is left for later.
      Signed-off-by: default avatarLucas De Marchi <lucas.demarchi@intel.com>
      Reviewed-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220410061537.4187383-1-lucas.demarchi@intel.com
      82c362f2
    • Stanislav Lisovskiy's avatar
      drm/i915: Swap ret and status returned from skl_pcode_request · 40a56956
      Stanislav Lisovskiy authored
      If ret isn't zero, it is almost for sure ETIMEDOUT, because
      we use it in wait_for macro which does continuous retries
      until timeout is reached. If we still ran out of time and
      retries, we most likely would be interested in getting status,
      to understand what was the actual error propagated from PCode,
      rather than to find out that we had a time out, which is anyway
      quite obvious, if the function fails.
      
      v2: Make it status ? status : ret(thanks Vinod for the hint)
      Signed-off-by: default avatarStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
      Reviewed-by: default avatarVinod Govindapillai <vinod.govindapillai@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220411081343.18099-1-stanislav.lisovskiy@intel.com
      40a56956
    • Stanislav Lisovskiy's avatar
      drm/i915: Fix skl_pcode_try_request function · 9e0a1c3c
      Stanislav Lisovskiy authored
      Currently skl_pcode_try_request function doesn't
      properly handle return value it gets from
      snb_pcode_rw, but treats status != 0 as success,
      returning true, which basically doesn't allow
      to use retry/timeout mechanisms if PCode happens
      to be busy and returns EGAIN or some other status
      code not equal to 0.
      
      We saw this on real hw and also tried simulating this
      by always returning -EAGAIN from snb_pcode_rw for 6 times, which
      currently will just result in false success, while it should
      have tried until timeout is reached:
      
      [   22.357729] i915 0000:00:02.0: [drm:intel_cdclk_dump_config [i915]] Changing CDCLK to
      307200 kHz, VCO 614400 kHz, ref 38400 kHz, bypass 19200 kHz, voltage level 0
      [   22.357831] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 1
      [   22.357892] i915 0000:00:02.0: [drm:skl_pcode_request [i915]] Success, exiting
      [   22.357936] i915 0000:00:02.0: [drm] ERROR Failed to inform PCU about cdclk change (err -11, freq 307200)
      
      We see en error because higher level api, still notices that status was wrong,
      however we still did try only once.
      
      We fix it by requiring _both_ the status to be 0 and
      request/reply match for success(true) and function
      should return failure(false) if either status turns
      out to be EAGAIN, EBUSY or whatever or reply/request
      masks do not match.
      
      So now we see this in the logs:
      
      [   22.318667] i915 0000:00:02.0: [drm:intel_cdclk_dump_config [i915]] Changing CDCLK to
      307200 kHz, VCO 614400 kHz, ref 38400 kHz, bypass 19200 kHz, voltage level 0
      [   22.318782] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 1
      [   22.318849] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 2
      [   22.319006] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 3
      [   22.319091] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 4
      [   22.319158] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 5
      [   22.319224] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 6
      Reviewed-by: default avatarVinod Govindapillai <vinod.govindapillai@intel.com>
      Signed-off-by: default avatarStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220408125200.9069-2-stanislav.lisovskiy@intel.com
      9e0a1c3c
    • Jani Nikula's avatar
      Merge drm/drm-next into drm-intel-next · 83970cd6
      Jani Nikula authored
      Sync up with v5.18-rc1, in particular to get 5e3094cf
      ("drm/i915/xehpsdv: Add has_flat_ccs to device info").
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      83970cd6
  5. 09 Apr, 2022 1 commit
  6. 08 Apr, 2022 1 commit
  7. 06 Apr, 2022 7 commits
  8. 05 Apr, 2022 7 commits