- 01 Nov, 2018 6 commits
-
-
Christian König authored
This is still completely breaking my Raven system. This reverts commit cdf2f910fa969adca1b0e3ad2b487821233dc038. Revert until we sort out the sbios and firmware combinations that work correctly. bug: https://bugs.freedesktop.org/show_bug.cgi?id=108606 Cc: stable@vger.kernel.org # v4.19 Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Rex Zhu authored
print warning in dmesg to notify user the setting for sclk_od/mclk_od out of range that vbios can support Reviewed-by:
Rex Zhu <Rex.Zhu@amd.com> Signed-off-by:
-
Rex Zhu authored
not update dpm table with user's setting. Reviewed-by:
-
Rex Zhu authored
not update the dpm table with user's setting Acked-by:
-
Evan Quan authored
As MGPU fan boost feature will be definitely not needed when DPM is disabled. So, there is no need to error out. Signed-off-by:
Evan Quan <evan.quan@amd.com> Reviewed-by:
-
Andrey Grodzovsky authored
Problem: During GPU recover DAL would hang in amdgpu_pm_compute_clocks->amdgpu_fence_wait_empty Fix: Turns out there was a typo introduced by 3320b8d2 drm/amdgpu: remove job->ring which caused skipping amdgpu_fence_driver_force_completion and so the hangged job was never force signaled and this would cause the hang later in DAL. Signed-off-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by:
-
- 30 Oct, 2018 2 commits
-
-
Evan Quan authored
Tell the version numbers when the pptable versions do not match. Signed-off-by:
-
Guttula, Suresh authored
This patch will work as workaround for silicon limitation related to PWM dutycycle when the backlight level goes to 0. Actually PWM value is 16 bit value and valid range from 1-65535. when ever user requested to set this PWM value to 0 which is not fall in the range, in VBIOS taken care this by limiting to 1. This patch here will do the same. Either driver or VBIOS can not pass 0 value as it is not a valid range for PWM and it will give a high PWM pulse which is not the intended behaviour as per HW constraints. Signed-off-by:
suresh guttula <suresh.guttula@amd.com> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
- 26 Oct, 2018 3 commits
-
-
Shirish S authored
Currently send_msg_to_smc_async() only report which message failed, but the actual failing message is the previous one, which SMU is unable to service. This patch reads the contents of register where the SMU is stuck and report appropriately. v2: fix the build (Alex) Signed-off-by:
Shirish S <shirish.s@amd.com> Reviewed-by:
-
Andrey Grodzovsky authored
Problem: After GPU reset on dGPUs with gfx8 compute ring 1.0.0 fails to pass the ring test. Ring registers inspection shows that it's active and no hang is observed (rptr == wptr) No significant diffs were observed between CP_HQD* registers for the ring in good and bad shape. Fix: No clear reason why but reversing the order of ring tests fixes the problem. Signed-off-by:
-
Christian König authored
Make sure we don't try to go down further after the leave walk already ended. This fixes a crash with a new VM test. Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Acked-by:
-
- 25 Oct, 2018 7 commits
-
-
Christian König authored
We should not remove mappings in rbtree_postorder_for_each_entry_safe because that rebalances the tree. Signed-off-by:
Chunming Zhou <david1.zhou@amd.com> Signed-off-by:
-
Evan Quan authored
So that it can be shared between all clocks. Signed-off-by:
-
Evan Quan authored
Currently the clocks reported are in 10Khz unit. Correct them as Khz unit as DAL wanted. Signed-off-by:
-
David Francis authored
[Why] Carrizo and Stoney have severe corruption when trying to power 4k 60 monitors over HDMI connectors that support 4k 60. Carrizo and Stoney require retimers and redrivers to support 4k 60 over HDMI. This driver does not currently support these. Thus, 4k 60 HDMI (and all other modes requiring over 300MHz) should be disabled. [How] Reduce the dce11 HDMI pixel clock cap to 300000kHz. Signed-off-by:
David Francis <David.Francis@amd.com> Reviewed-by:
Roman Li <Roman.Li@amd.com> Acked-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by:
-
Rex Zhu authored
need to check adev->powerplay.pp_funcs first, becasue from AI, the smu ip can be disabled by user, and the pp_handle is null in this case. Reviewed-by:
-
Rex Zhu authored
from AI, SMU Ip is not indispensable to driver and can be disabled by user via module parameter ip_block_mask. so the pp_handle may be NULL. Reviewed-by:
-
Evan Quan authored
This can suppress the error reported on driver loading. Also these are empty APIs as Vega12/Vega20 has no performance levels. Signed-off-by:
Feifei Xu <Feifei.Xu@amd.com> Signed-off-by:
-
- 22 Oct, 2018 6 commits
-
-
Evan Quan authored
As the matching VBIOS is already ready. Also drop the temporary workarounds applied before. Signed-off-by:
-
Evan Quan authored
The UCLK is forced to highest at the start of display configuration change. Downgrade the UCLK from highest after display configuration change. Otherwise, we may see the UCLK stuck in the highest in some cases. Signed-off-by:
-
Joseph Greathouse authored
OverDrive mode allows users to increase the maximum SCLK and MCLK frequencies beyond the default on the GPU. However, this may not results in large performance gains if the GPU then runs into its TDP power limit. This patch adds the capability to increase the power limit of a GPU above its default maximum. This is only allowed when overdrive is enabled in the ppfeaturemask, since this is an overdrive feature. The TDPODLimit value from the VBIOS describes how how much higher the TDP should be allowed to go over its default, in percentage. v2: Moved dereference of hwmgr to after its validity check Signed-off-by:
Joseph Greathouse <Joseph.Greathouse@amd.com> Reviewed-by:
-
David Francis authored
In a refactor, the watermark clock inputs to powerplay from DC were changed from units of 10kHz to kHz clocks. One division by 100 was not converted into a division by 1000. Signed-off-by:
-
Emily Deng authored
Need to check adev->powerplay.pp_funcs. Signed-off-by:
Emily Deng <Emily.Deng@amd.com> Reviewed-by:
Huang Rui <ray.huang@amd.com> Signed-off-by:
-
Evan Quan authored
Forcing clock level is supported under manual dpm mode only. Error out when trying to set under manual mode. Instead of doing nothing and reporting success. V2: update for mclk/pcie clock level settings also Signed-off-by:
-
- 19 Oct, 2018 1 commit
-
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2018-10-18' of git://anongit.freedesktop.org/drm/drm-intel into drm-next - Fix GPU hang on MacBook2,1 when booting in EFI mode (Bugzilla #105637) - Fix garbled console on Y tiled BIOS framebuffer configs (Bugzilla #108264) - Fix black screen on certain eDP panels eg. Dell XPS 9350 (Bugzilla #107489 and #105338) - MST fixes that Rodrigo dropped from drm-intel-fixes and bunch of Icelake fixes - Then assorted proactive code fixes caught by CI or developers Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181018165725.GA2281@jlahtine-desk.ger.corp.intel.com
-
- 18 Oct, 2018 15 commits
-
-
Anusha Srivatsa authored
Add missing MODULE_FIRMWARE while loading DMC ICL. v2: Add Fixes tag. (Rodrigo) v3: Rebase by Rodrigo after commit 7fe78985 ("drm/i915/csr: restructure CSR firmware definition macros") v4: Rodrigo fixing his own mess on commit mentioning on v3 comment above. Fixes: 4445930f ("firmware/dmc/icl: load v1.07 on icelake.") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (v2) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181004223613.19938-1-rodrigo.vivi@intel.com (cherry picked from commit 00e5d8b1) Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Rodrigo Vivi authored
Since when it was introduced we forgot to add this case so ICL was using a wrong signal_levels as reference. Fixes: fb5c8e9d ("drm/i915/icl: Implement voltage swing programming sequence for Combo PHY DDI") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181017215652.26841-1-rodrigo.vivi@intel.com (cherry picked from commit 61cdfb9e) Signed-off-by:
-
Mahesh Kumar authored
DDI/TC clock-off bits are not equally distanced. TC1-3 bits are from offset 12 & TC4 is at offset 21. Create a function to choose correct clk-off bit. v2: Add fixes tag (Lucas) Fixes: c27e917e ("drm/i915/icl: add basic support for the ICL clocks") Signed-off-by:
Mahesh Kumar <mahesh1.kumar@intel.com> Signed-off-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Mahesh Kumar authored
This patch creates a function/wrapper to check if port is combophy port instead of explicitly comparing ports. Changes since V1: - keep all intel_port_is_* helper together (Lucas) Signed-off-by:
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
Fixes for 4.20. Highlights: - VCN DPG fixes for Picasso - Add support for the latest vega20 vbios - Scheduler timeout fix - License fixes for radeon and amdgpu - Misc other fixes Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2018-10-17' of git://anongit.freedesktop.org/drm/drm-misc into drm-next - Add quirk to fix orientation of Acer One 10 (S1003) panel (Hans) Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Imre Deak authored
If BIOS configured a Y tiled FB we failed to set up the backing object tiling accordingly, leading to a lack of GT fence installed and a garbled console. The problem was bisected to commit 011f22eb ("drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2") but it just revealed a pre-existing issue. Kudos to Ville who suspected a missing fence looking at the corruption on the screen. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: <ronald@innovation.ch> Cc: <stable@vger.kernel.org> Reported-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Reported-by: <ronald@innovation.ch> Tested-by: <ronald@innovation.ch> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108264 Fixes: bc8d7dff ("drm/i915/skl: Provide a Skylake version of get_plane_config()") Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181016160011.28347-1-imre.deak@intel.com (cherry picked from commit 914a4fd8) Signed-off-by:
-
Chris Wilson authored
Handle integer overflow when computing the sub-page length for shmem backed pread/pwrite. Reported-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: stable@vger.kernel.org Reviewed-by:
-
Chris Wilson authored
For mmap-exhaustion, we deliberately put the system under a large amount of pressure to ensure that we are able to reap mmap-offsets from dead objects. If background activity does that reaping for us, that defeats the purpose of the test and in some cases will fail our sanity checks (because of the fake activity we use to prevent the idle worker). Fixes: 932cac10 ("drm/i915/selftests: Prevent background reaping of acti ve objects") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181011103748.18387-1-chris@chris-wilson.co.uk (cherry picked from commit 0b4bf7ca) Signed-off-by:
-
Manasi Navare authored
This patch fixes the original commit c0cfb10d ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") that causes a blank screen in case of certain eDP panels (Eg: seen on Dell XPS13 9350) where first link training fails and a retraining is required by falling back to lower link rate/lane count. In case of some panels they advertise higher link rate/lane count than whats required for supporting the panel's native mode. But we always link train at highest link rate/lane count for eDP and if that fails we can still fallback to lower link rate/lane count as long as the fallback link BW still fits the native mode to avoid pruning the panel's native mode yet retraining at fallback values to recover from a blank screen. v3: * Add const for fixed_mode (Ville) v2: * Send uevent if link failure on eDP unconditionally Fixes: c0cfb10d ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") Cc: Clinton Taylor <clinton.a.taylor@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: <stable@vger.kernel.org> # v4.17+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107489 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105338Signed-off-by:
Alexander Wilson <alexander.wilson@ncf.edu> Reviewed-by:
-
Lyude Paul authored
Currently, i915 appears to rely on blocking modesets on no-longer-present MSTB ports by simply returning NULL for ->best_encoder(), which in turn causes any new atomic commits that don't disable the CRTC to fail. This is wrong however, since we still want to allow userspace to disable CRTCs on no-longer-present MSTB ports by changing the DPMS state to off and this still requires that we retrieve an encoder. So, fix this by always returning a valid encoder regardless of the state of the MST port. Changes since v1: - Remove mst atomic helper, since this got replaced with a much simpler solution Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20181008232437.5571-6-lyude@redhat.com (cherry picked from commit a9f9ca33) Signed-off-by:
-
Lyude Paul authored
Since we need to be able to allow DPMS on->off prop changes after an MST port has disappeared from the system, we need to be able to make sure we can compute a config for the resulting atomic commit. Currently this is impossible when the port has disappeared, since the VCPI slot searching we try to do in intel_dp_mst_compute_config() will fail with -EINVAL. Since the only commits we want to allow on no-longer-present MST ports are ones that shut off display hardware, we already know that no VCPI allocations are needed. So, hardcode the VCPI slot count to 0 when intel_dp_mst_compute_config() is called on an MST port that's gone. Changes since V4: - Don't use mst_port_gone at all, just check whether or not the drm connector is registered - Daniel Vetter Signed-off-by:
-
Lyude Paul authored
Currently we set intel_connector->mst_port to NULL to signify that the MST port has been removed from the system so that we can prevent further action on the port such as connector probes, mode probing, etc. However, we're going to need access to intel_connector->mst_port in order to fixup ->best_encoder() so that it can always return the correct encoder for an MST port to prevent legacy DPMS prop changes from failing. This should be safe, so instead keep intel_connector->mst_port always set and instead just check the status of drm_connector->regustered to signify whether or not the connector has disappeared from the system. Changes since v2: - Add a comment to mst_port_gone (Jani Nikula) - Change mst_port_gone to a u8 instead of a bool, per the kernel bot. Apparently bool is discouraged in structs these days Changes since v4: - Don't use mst_port_gone at all! Just check if the connector is registered or not - Daniel Vetter Signed-off-by:
-
Chris Wilson authored
Before we can reset the seqno, we have to be sure the engines are idle. In debugfs/i915_drop_caches_set, we do wait_for_idle but allow ourselves to be interrupted. We should only proceed to reset the seqno then if we were not interrupted, and so also avoid overwriting the error status. References: https://bugs.freedesktop.org/show_bug.cgi?id=108133 Fixes: 6b048706 ("drm/i915: Forcibly flush unwanted requests in drop-caches") Signed-off-by:
-
Ville Syrjälä authored
When we decide that a plane is attached to the wrong pipe we try to turn off said plane. However we are passing around the crtc we think that the plane is supposed to be using rather than the crtc it is currently using. That doesn't work all that well because we may have to do vblank waits etc. and the other pipe might not even be enabled here. So let's pass the plane's current crtc to intel_plane_disable_noatomic() so that it can its job correctly. To do that semi-cleanly we also have to change the plane readout to record the plane's visibility into the bitmasks of the crtc where the plane is currently enabled rather than to the crtc we want to use for the plane. One caveat here is that our active_planes bitmask will get confused if both planes are enabled on the same pipe. Fortunately we can use plane_mask to reconstruct active_planes sufficiently since plane_mask still has the same meaning (is the plane visible?) during readout. We also have to do the same during the initial plane readout as the second plane could clear the active_planes bit the first plane had already set. v2: Rely on fixup_active_planes() to populate active_planes fully (Daniel) Add Daniel's proposed comment to better document why we do this Drop the redundant intel_set_plane_visible() call Cc: stable@vger.kernel.org # fcba862e8428 drm/i915: Have plane->get_hw_state() return the current pipe Cc: stable@vger.kernel.org Cc: Dennis <dennis.nezic@utoronto.ca> Cc: Daniel Vetter <daniel@ffwll.ch> Tested-by:Dennis <dennis.nezic@utoronto.ca> Tested-by:
Peter Nowee <peter.nowee@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105637 Fixes: b1e01595 ("drm/i915: Redo plane sanitation during readout") Signed-off-by:
-
