- 17 Aug, 2020 16 commits
-
-
Chris Wilson authored
Gracefully skip over the failures in the frequency scaling for the moment, the results are under review. References: https://gitlab.freedesktop.org/drm/intel/-/issues/1754Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: "Sundaresan, Sujaritha" <sujaritha.sundaresan@intel.com> Cc: "Ewins, Jon" <jon.ewins@intel.com> Reviewed-by:
Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200723153805.8076-1-chris@chris-wilson.co.ukSigned-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matt Roper authored
After doing normal PHY-B initialization on Rocket Lake, we need to manually copy some additional PHY-A register values into PHY-B registers. Note that the bspec's combo phy page doesn't specify that this workaround is restricted to specific platform steppings (and doesn't even do a very good job of specifying that RKL is the only platform this is needed on), but the RKL workaround page lists this as relevant only for A and B steppings, so I'm trusting that information for now. v2: Make rkl_combo_phy_b_init_wa() static v3: - Minimize variables in WA function. (Jose) - Fix timeout duration (usec vs msec). (Jose) - Add verification of workaround. (Jose) - Fix stepping bounds in comment. Bspec: 49291 Bspec: 53273 Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200716220551.2730644-6-matthew.d.roper@intel.comReviewed-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Matt Roper authored
If HTI (also sometimes called HDPORT) is enabled at startup, it may be using some of the PHYs and DPLLs making them unavailable for general usage. Let's read out the HDPORT_STATE register and avoid making use of resources that HTI is already using. v2: - Fix minor checkpatch warnings v3: - Just readout HDPORT_STATE register once during init and then parse it later as needed. - Add a 'has_hti' device info flag to track whether we should readout HDPORT_STATE or not. We can skip the platform/flag tests later since the hti_state in dev_priv will remain 0 for platforms it does not apply to. - Move PLL masking into icl_get_combo_phy_dpll() since at the moment RKL is the only platform that has HTI. (Jose) Bspec: 49189 Bspec: 53707 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Matt Roper authored
Rocket Lake has a third DPLL (called 'DPLL4') that must be used to enable a third display. Unlike EHL's variant of DPLL4, the RKL variant behaves the same as DPLL0/1. And despite its name, the DPLL4 registers are offset as if it were DPLL2. v2: - Add new .update_ref_clks() hook. v3: - Renumber TBT PLL to '3' and switch _MMIO_PLL3 to _MMIO_PLL (Lucas) v4: - Don't drop _MMIO_PLL3; although it's now unused, we're going to need it very soon again for upcoming DG1 patches. (Lucas) v5: - Don't re-number TBT PLL and beyond, just use new RKL_DPLL_CFGCR macros to lookup the proper registers instead. Although renumbering the PLLs might be something we want to consider down the road, it opens a big can of worms right now since a bunch of places in the code have an assumption that the PLL table has idx==id and no holes. Renumbering creates a hole for TGL, so we'd either need to allow holes in the table or break the idx==id invariant, both of which are somewhat invasive changes to the design. Bspec: 49202 Bspec: 49443 Bspec: 50288 Bspec: 50289 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Matt Roper authored
RKL and TGL share some general gen12 workarounds, but each platform also has its own platform-specific workarounds. v2: - Add Wa_1604555607 for RKL. This makes RKL's ctx WA list identical to TGL's, so we'll have both functions call the tgl_ function for now; this workaround isn't listed for DG1 so we don't want to add it to the general gen12_ function. Cc: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
-
Matt Roper authored
RKL uses a slightly different bit layout for the DPCLKA_CFGCR0 register. v2: - Fix inverted mask application when updating ICL_DPCLKA_CFGCR0 - Checkpatch style fixes Bspec: 50287 Cc: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by:
-
Ville Syrjälä authored
It's silly to have if(SKL) checks in gen9_init_clock_gating() when we can just move those bits into skl_init_clock_gating(). I'm not entirely convinced we even need this w/a, or if we do then maybe we want it for kbl/cfl as well. IIRC it was only listed in the wadb, but that is now dead so can't double check anymore. Bspec doesn't seem to have any purely skl specific DOP clock gating workarounds listed. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200716190426.17047-1-ville.syrjala@linux.intel.comReviewed-by:
-
José Roberto de Souza authored
Hours Of Battery Life is a new GEN12+ power-saving feature that allows supported motherboards to use a special voltage swing table for eDP panels that uses less power. So here if supported by HW, OEM will set it in VBT and i915 will try to train link with HOBL vswing table if link training fails it fall back to the original table. intel_ddi_dp_preemph_max() was optimized to only check the HOBL flag instead of do something like is done in intel_ddi_dp_voltage_max() because it is only called after the first entry of the voltage swing table was loaded so the HOBL flag is valid at that point. v3: - removed a few parameters of icl_ddi_combo_vswing_program() that can be taken from encoder v4: - using the HOBL vswing table until training fails completely (Ville) v5: - not reducing lane or link rate when link training fails with HOBL active - duplicated the HOBL voltage swing entry to match DP spec requirement v6: - removed the optional VS 3 & pre-emp 0 from HOBL table - changed from u8:1 to bool to store hobl_failed/active BSpec: 49291 BSpec: 49399 Reviewed-by:
-
Alexei Podtelezhnikov authored
0x0155 is rather Ivy Bridge PCI-E Root Port. 0x0157 from the same commit ff049b6c ("drm/i915: bind driver to ValleyView chipsets") is likely wrong too. Nowhere is it independetly confirmed or mentioned. Signed-off-by:
Alexei Podtelezhnikov <apodtele@gmail.com> Signed-off-by:
-
Chris Wilson authored
Rather than manually implement our own module reference counting for perf pmu events, finally realise that there is a module parameter to struct pmu for this very purpose. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200716094643.31410-1-chris@chris-wilson.co.ukSigned-off-by:
-
Imre Deak authored
The value we program to DDI_BUF_CTL changes at the following places: - At enabling/disabling the output to configure the port width etc, and to enable/disable the DDI BUF function. - At the beginning/end of link re-training to disable/re-enable the DDI BUF function. - On HSW/BDW/SKL to change the voltage swing/pre-emph levels. Except of the above the value we program to the DDI_BUF_CTL register (intel_dp->DP) doesn't change, so no need to reprogram the register when changing the link training patterns (which is programmed via the DP_TP_CTL register on DDI platforms). v2: - Fix the commit message wrt. voltage/pre-emph level values in intel_dp->DP. (Ville) Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Imre Deak authored
According to BSpec this flag should not be changed while the DDI function is enabled. On BDW+ the DP_TP_CTL register spec also states it explicitly that the HW takes care of enabling/disabling the scrambling for training patterns (and it must stay enabled for normal pixel output). Assume that this HW automatic handling of scrambling is also true for HSW. BSpec: 8013, 7557, 50484 Signed-off-by:
-
Ville Syrjälä authored
Explicitly check for i830 when assigning the .get_cdclk() vfunc, and then deal with the case of not having assigned the vfunc separately. Less confusing, and gets rid of the checkpatch complaint about using {} on one branch but not the others. Signed-off-by: -
Ville Syrjälä authored
Some spaces have snuck in where we want tabs. Fix it. Signed-off-by:
-
Ville Syrjälä authored
There's a pointless hole in struct intel_cdclk_vals, get rid of it. Fortunately we already use named initializers so the order does not matter. Signed-off-by:
-
Ville Syrjälä authored
Since g4x the CFB base only takes a 28bit offset into stolen. Not sure if the CFB is allowed to start below that limit but then extend beyond it. Let's assume not and just restrict the allocation to the first 256MiB (in the unlikely case we have more stolen than that). v2: s/BIT/BIT_ULL/ (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 12 Aug, 2020 2 commits
-
-
Christian König authored
This reverts commit 2ddef176. As it turned out VMWGFX needs a much wider audit to fix this. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
git://people.freedesktop.org/~sroland/linuxDave Airlie authored
The drm_mode_config_reset patches are very important fixing a recently introduced kernel crash, the others fix various older issues which are a bit less serious in practice. Signed-off-by:
-
- 11 Aug, 2020 12 commits
-
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
amd-drm-fixes-5.9-2020-08-07: amdgpu: - Re-add spelling typo fix - Sienna Cichlid fixes - Navy Flounder fixes - DC fixes - SMU i2c fix - Power fixes Signed-off-by:
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
* backmerge from drm-fixes at v5.8-rc7 * add orientation quirk for ASUS T103HAF * drm/omap: force runtime PM suspend on system suspend * drm/tidss: fix modeset init for DPI panels * re-added docs for drm_gem_flink_ioctl() * ttm: fix page-offset calculation within TTM Signed-off-by:
-
Dave Airlie authored
I need to backmerge 5.8 as I've got a bunch of fixes sitting on an rc7 base that I want to land. Signed-off-by: -
Colin Ian King authored
There is a spelling mistake in a DRM_ERROR message. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Roland Scheidegger <sroland@vmware.com>
-
Colin Ian King authored
There is a spelling mistake in a DRM_ERROR message. Fix it. Signed-off-by:
-
Roland Scheidegger authored
Same problem as in stdu, same fix. Fixes: 51f644b4 ("drm/atomic-helper: reset vblank on crtc reset") Acked-by:
Charmaine Lee <charmainel@vmware.com> Reviewed-by:
Zack Rusin <zackr@vmware.com> Signed-off-by:
-
Roland Scheidegger authored
Same problem as in stdu, same fix. Fixes: 51f644b4 ("drm/atomic-helper: reset vblank on crtc reset") Acked-by:
-
Daniel Vetter authored
When converting to atomic the state reset was done by directly calling the functions, and before the modeset object was fully initialized. This means the various ->dev pointers weren't set up. After commit 51f644b4 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jun 12 18:00:49 2020 +0200 drm/atomic-helper: reset vblank on crtc reset this started to oops because now we're trying to derefence drm_crtc->dev. Fix this up by entirely switching over to drm_mode_config_reset, called once everything is set up. Fixes: 51f644b4 ("drm/atomic-helper: reset vblank on crtc reset") Reported-by:
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Tested-by:
-
Dan Carpenter authored
These if statements are supposed to be true if we ended the list_for_each_entry() loops without hitting a break statement but they don't work. In the first loop, we increment "i" after the "if (i == unit)" condition so we don't necessarily know that "i" is not equal to unit at the end of the loop. In the second loop we exit when mode is not pointing to a valid drm_display_mode struct so it doesn't make sense to check "mode->type". Fixes: a278724a ("drm/vmwgfx: Implement fbdev on kms v2") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Dan Carpenter authored
The "entry" pointer is an offset from the list head and it doesn't point to a valid vmw_legacy_display_unit struct. Presumably the intent was to point to the last entry. Also the "i++" wasn't used so I have removed that as well. Fixes: d7e1958d ("drm/vmwgfx: Support older hardware.") Signed-off-by:
-
Gustavo A. R. Silva authored
Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. This code was detected with the help of Coccinelle and, audited and fixed manually. Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2020-08-05' of git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next-fixes for v5.9-rc1: - Fix drm_dp_mst_port refcount leaks in drm_dp_mst_allocate_vcpi - Fix a fbcon OOB read in fbdev, found by syzbot. - Mark vga_tryget static as it's not used elsewhere. - Small fixes to xlnx. - Remove null check for kfree in drm_dev_release. - Fix DRM_FORMAT_MOD_AMLOGIC_FBC definition. - Fix mode initialization in omap_connector_mode_valid(). Signed-off-by:
-
- 07 Aug, 2020 4 commits
-
-
Sandeep Raghuraman authored
Reproducing bug report here: After hibernating and resuming, DPM is not enabled. This remains the case even if you test hibernate using the steps here: https://www.kernel.org/doc/html/latest/power/basic-pm-debugging.html I debugged the problem, and figured out that in the file hardwaremanager.c, in the function, phm_enable_dynamic_state_management(), the check 'if (!hwmgr->pp_one_vf && smum_is_dpm_running(hwmgr) && !amdgpu_passthrough(adev) && adev->in_suspend)' returns true for the hibernate case, and false for the suspend case. This means that for the hibernate case, the AMDGPU driver doesn't enable DPM (even though it should) and simply returns from that function. In the suspend case, it goes ahead and enables DPM, even though it doesn't need to. I debugged further, and found out that in the case of suspend, for the CIK/Hawaii GPUs, smum_is_dpm_running(hwmgr) returns false, while in the case of hibernate, smum_is_dpm_running(hwmgr) returns true. For CIK, the ci_is_dpm_running() function calls the ci_is_smc_ram_running() function, which is ultimately used to determine if DPM is currently enabled or not, and this seems to provide the wrong answer. I've changed the ci_is_dpm_running() function to instead use the same method that some other AMD GPU chips do (e.g Fiji), which seems to read the voltage controller. I've tested on my R9 390 and it seems to work correctly for both suspend and hibernate use cases, and has been stable so far. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=208839Signed-off-by:
Sandeep Raghuraman <sandy.8925@gmail.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
Evan Quan authored
As VCN related dpm table setup needs VCN be in PG ungate state. Same logics applies to JPEG. V2: fix paste typo V3: code cosmetic Signed-off-by:
Evan Quan <evan.quan@amd.com> Tested-by:
Matt Coffin <mcoffin13@gmail.com> Reviewed-by:
-
Evan Quan authored
Add lock protections and avoid unnecessary actions if the PG state is already the same as required. Signed-off-by:
-
Likun Gao authored
Swith default gpu reset method for sienna_cichlid to MODE1 reset. Signed-off-by:
Likun Gao <Likun.Gao@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
- 06 Aug, 2020 6 commits
-
-
Alex Deucher authored
The i2c init/fini functions just register the i2c adapter. There is no need to call them during hw init/fini. They only need to be called once per driver init/fini. The previous behavior broke runtime pm because we unregistered the i2c adapter during suspend. Tested-by:
Tom St Denis <tom.stdenis@amd.com> Reviewed-by:
Kevin Wang <kevin1.wang@amd.com> Signed-off-by:
-
Igor Kravchenko authored
[why] Display goes blank after driver installation. Aux tuning parameters must be used for 2.x only. Wrong dc_golden_table offset was used. [How] Implement a new enc3_hw_init function without VBIOS constants usage to be called for 3.x Calculate dc_golden_table offset using sum of base dce_info offset and golden table offset Signed-off-by:
Igor Kravchenko <Igor.Kravchenko@amd.com> Reviewed-by:
Aric Cyr <Aric.Cyr@amd.com> Acked-by:
Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by:
-
George Shen authored
[Why] During SetPathMode and UpdatePlanes, the plane state can be null. We default to linear swizzle mode when plane state is null. This resulted in bandwidth validation failing when trying to set 8K60 mode (which previously passed validation during rebuild timing list). [How] Change the default swizzle mode from linear to 4kb_s and update pitch accordingly. Signed-off-by:
George Shen <george.shen@amd.com> Reviewed-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by:
-
JinZe.Xu authored
[How] Use dc_is_hdmi_signal to determine signal type. Signed-off-by:
JinZe.Xu <JinZe.Xu@amd.com> Reviewed-by:
Charlene Liu <Charlene.Liu@amd.com> Acked-by:
-
Aric Cyr authored
[Why] Sink OUI supported cap is not set so driver skips programming it. [How] Revert the change the skips OUI programming if the cap is not set Signed-off-by:
Anthony Koo <Anthony.Koo@amd.com> Acked-by:
-
Harry Wentland authored
[Why&How] use correct logger context Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Reviewed-by:
Roman Li <Roman.Li@amd.com> Acked-by:
-
