- 11 Jun, 2019 39 commits
-
-
Aric Cyr authored
Signed-off-by:
Aric Cyr <aric.cyr@amd.com> Reviewed-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Krunoslav Kovac authored
Using this logic breaks driver unload, this is a temporary fix a followup patch will properly fix this Signed-off-by:
Krunoslav Kovac <Krunoslav.Kovac@amd.com> Reviewed-by:
-
Anthony Koo authored
[Why] HPD not going to be high if Panel VDD is off And all AUX transaction will fail :( [How] 1. Power on VDD before attempting detection if it isn't already on 2. Improve the robustness by having a retry mechanism on the first DPCD read after VDD on. If a particular board always holds HPD high incorrectly, the AUX access may fail, so we can retry in those scenarios. This change would only improve logic since it prevents AUX failure leading to bad resolution on internal panel. 3. We should never need to re-detect internal panel, so logic is re-arranged a bit to skip earlier. Signed-off-by:
Anthony Koo <Anthony.Koo@amd.com> Reviewed-by:
Jun Lei <Jun.Lei@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] To prepare for the upcoming DRM plane color management properties we need to correct a lot of wrong behavior and assumptions made for CRTC color management. The documentation added by this commit in amdgpu_dm_color explains how the HW color pipeline works and its limitations with the DRM interface. The current implementation does the following wrong: - Implicit sRGB DGM when no CRTC DGM is set - Implicit sRGB RGM when no CRTC RGM is set - No way to specify a non-linear DGM matrix that produces correct output - No way to specify a correct RGM when a linear DGM is used We had workarounds for passing kms_color tests but not all of the behavior we had wrong was covered by these tests (especially when it comes to non-linear DGM). Testing both DGM and RGM at the same time isn't something kms_color tests well either. [How] The specifics for how color management works in AMDGPU and the new behavior can be found by reading the documentation added to amdgpu_dm_color.c from this patch. All of the incorrect cases from the old implementation have been addressed for the atomic interface, but there still a few TODOs for the legacy one. Note: this does cause regressions for kms_color@pipe-a-ctm-* over HDMI. The result looks correct from visual inspection but the CRC no longer matches. For reference, the test was previously doing the following: linear degamma -> CTM -> sRGB regamma -> RGB to YUV (709) -> ... Now the test is doing: linear degamma -> CTM -> linear regamma -> RGB to YUV (709) -> ... Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by:
Sun peng Li <Sunpeng.Li@amd.com> Acked-by:
-
Wesley Chalmers authored
[WHY] This is meant to make it clearer that 0xf is not a valid OPP ID, and that code making use of OPP IDs should not accept this value. Signed-off-by:
Wesley Chalmers <Wesley.Chalmers@amd.com> Reviewed-by:
Charlene Liu <Charlene.Liu@amd.com> Acked-by:
-
Charlene Liu authored
Signed-off-by:
Chris Park <Chris.Park@amd.com> Acked-by:
-
Derek Lai authored
1. Add i2c_hw_Status check to make sure when HW i2c is in use. 2. Don't reset HW engine in is_hw_busy() and instead do this in process_transaction() because SW i2c does not check if hw i2c is in use Signed-off-by:
Derek Lai <Derek.Lai@amd.com> Reviewed-by:
-
Eric Bernstein authored
No need to assert just return Signed-off-by:
Eric Bernstein <eric.bernstein@amd.com> Reviewed-by:
-
Aric Cyr authored
Signed-off-by:
-
Charlene Liu authored
Implement floor, ceil, and fabs Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] Almost every function in DC that works with stream state expects that the current state on the stream is the one that it should be writing out. These functions are typically triggered by specifying a particular stream update - but the actual contents of the stream update itself are ignored, leaving it to the DM to actually update the stream state itself. The problem with doing this in DM is a matter of timing. On Linux most of this is incorrectly done in atomic check, when we actually want it to be done during atomic commit tail while access to DC is locked. To give an example, a commit requesting to modify color management state for DM could come in, be rejected, but still have modified the actual system state for the stream since it's shared memory. The next time color management gets programmed it'll use the rejected color management info - which might not even still be around if it's a custom transfer function. So a reasonable place to perform this is within DC itself and this is the model that's currently in use for surface updates. DC can even compare the current system state to the incoming surface update to determine update level, something that can't currnetly be done with the framework for stream updates. [How] Duplicate the framework used for surface updates for stream updates as well. Copy all the updates after checking the update type. Signed-off-by:
Harry Wentland <Harry.Wentland@amd.com> Acked-by:
-
Wesley Chalmers authored
[WHY] Some panels return a link rate of 0 (unknown) in DPCD 0. In this case, an appropriate mode cannot be set, and certain panels will show corruption as they are forced to use a mode they do not support. [HOW] Read DPCD 10 in the case where supported link rate from DPCD 0 is unknown, and pass that value on to the reported link rate. This re-introduces behaviour present in previous versions that appears to have been accidentally removed. Signed-off-by:
-
Tao.Huang authored
Signed-off-by:
Tao.Huang <Tao.Huang@amd.com> Reviewed-by:
-
Nicholas Kazlauskas authored
[Why] The module parameter to specify the default ABM level is now defined, so hook it up in DM. [How] On connector reset specify the default level. DC will program this as part of the modeset since it gets passed onto the stream in dm_update_crtc_state. It's only set for eDP connectors, but it doesn't matter if this is specified for connectors or hardware that doesn't support ABM. It's DC's responsibility to check that ABM can be set or adjusted, and DC does check that the DMCU firmware is running and if there's backlight control available. Signed-off-by:
David Francis <david.francis@amd.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] It's non trivial to configure or specify an ABM reduction level for userspace outside of X. There is also no method to specify the default ABM value at boot time. A parameter should be added to configure this. [How] Expose a module parameter that can specify the default ABM level to use for eDP connectors on DC enabled hardware that loads the DMCU firmware. The default is still disabled (0), but levels can range from 1-4. Levels control how much the backlight can be reduced, with being the least amount of reduction and four being the most reduction. Signed-off-by:
-
Monk Liu authored
It's incorrect to do soft reset for SRIOV, when GFX hang the WREG would stuck there becuase it goes KIQ way. the GPU reset counter is incorrect: always increase twice for each timedout Signed-off-by:
Monk Liu <Monk.Liu@amd.com> Reviewed-by:
-
James Zhu authored
Since Hardware bug, GDS exist ECC error after cold boot up, adding GDS clearing workaround in later init for gfx9. Signed-off-by:
James Zhu <James.Zhu@amd.com> Reviewed-by:
-
Nicholas Kazlauskas authored
[Why] Whenever the a modeset is allowed (but not neccessarily required) we currently recreate all the planes in the state. Most IGT tests and legacy IOCTLs create atomic commits with this flag set, so the pipes are often unnecessarily reprogrammed. Poor performance and stuttering can occur when many of these commits are frequently issued. This flag was needed when the appropriate conditions for checking whether the planes needed a reset were not in place, but should_reset_plane should cover everything needed now. [How] Drop the check for state->allow_modeset in should_reset_plane. All planes on a CRTC should reset in the following conditions: - The CRTC needs a modeset - The CRTC degamma changes - Planes are added or removed to the CRTC These conditions are all covered in should_reset_plane. We still can't drop the format change check in should_reset_plane since fill_dc_plane_info_and_addr isn't called when validating the state, so we can't tell if a FULL update is needed or not. Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] The old logic for checking which output depth to use relied on using the current connector state rather than the new proposed state. This was a problem when performing atomic commits since we weren't verifying it against the incoming max_requested_bpc. But switching this to only use the new state and not the current state breaks filtering modes - it'll always assume that the maximum bpc supported by the display is in use, which will cause certain modes like 1440p@144Hz to be filtered even when using 8bpc. [How] Still use the connector->state if we aren't passed an explicit state. This will respect the max_bpc the user currently has when filtering modes. Also remember to reset the default max_requested_bpc to 8 whenever connector reset is called to retain old behavior when using the new property. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110845Signed-off-by:
-
Tom St Denis authored
This option is no longer needed. The default code paths are now the only option. v2: Add HPAGE support and a default for non contiguous maps v3: Misread 512 pages as MiB ... Signed-off-by:
Tom St Denis <tom.stdenis@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] Unlike our regular connectors, MST connectors don't start off with an initial connector state. This causes a NULL pointer dereference to occur when attaching the bpc property since it tries to modify the connector state. We need an initial connector state on the connector to avoid the crash. [How] Use our reset helper to allocate an initial state and reset the values to their defaults. We were already doing this before, just not for MST connectors. Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] This will be useful for verifying whether we enter the correct output color depth from IGT. [How] Locks the connector and associated CRTC if available and outputs the current and maximum output bpc values. Example: cat /sys/kernel/debug/dri/0/DP-1/output_bpc Current: 8 Maximum: 10 v2: Drop unneeded connector status check Signed-off-by:
-
Prike Liang authored
Use SMU firmware version to indentify the raven1 refresh device and then load homologous RLC FW. Signed-off-by:
Prike Liang <Prike.Liang@amd.com> Suggested-by: Huang Rui<Ray.Huang@amd.com> Reviewed-by:
Huang Rui <ray.huang@amd.com> Reviewed-by:
Evan Quan <evan.quan@amd.com> Signed-off-by:
-
Chengming Gui authored
add gfxoff_state_changed_by_workload to control gfxoff when set power_profile_mode Signed-off-by:
Chengming Gui <Jack.Gui@amd.com> Reviewed-by:
-
Trigger Huang authored
Under Vega10 SR-IOV VF, L1 register access mode should be enabled by default as the non-security VF will no longer be supported. Signed-off-by:
Trigger Huang <Trigger.Huang@amd.com> Reviewed-by:
Emily Deng <Emily.Deng@amd.com> Signed-off-by:
-
Shirish S authored
[What] readptr read always returns zero, since most likely these blocks are either power or clock gated. [How] fetch rptr after amdgpu_ring_alloc() which informs the power management code that the block is about to be used and hence the gating is turned off. Signed-off-by:
Louis Li <Ching-shih.Li@amd.com> Signed-off-by:
Shirish S <shirish.s@amd.com> Reviewed-by:
-
Louis Li authored
[What] vce ring test fails consistently during resume in s3 cycle, due to mismatch read & write pointers. On debug/analysis its found that rptr to be compared is not being correctly updated/read, which leads to this failure. Below is the failure signature: [drm:amdgpu_vce_ring_test_ring] *ERROR* amdgpu: ring 12 test failed [drm:amdgpu_device_ip_resume_phase2] *ERROR* resume of IP block <vce_v3_0> failed -110 [drm:amdgpu_device_resume] *ERROR* amdgpu_device_ip_resume failed (-110). [How] fetch rptr appropriately, meaning move its read location further down in the code flow. With this patch applied the s3 failure is no more seen for >5k s3 cycles, which otherwise is pretty consistent. V2: remove reduntant fetch of rptr Signed-off-by:
-
Jay Cornwall authored
Ported from gfx8, no changes in register setup. Signed-off-by:
Jay Cornwall <Jay.Cornwall@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
Oak Zeng authored
Translate queue priority into pipe priority and write to MQDs. The priority values are used to perform queue and pipe arbitration. Signed-off-by:
Oak Zeng <Oak.Zeng@amd.com> Reviewed-by:
-
Felix Kuehling authored
Always mark evicted queues with q->properties.is_evicted = true, even queues that are inactive for other reason. This simplifies maintaining the eviction state as it doesn't require updating is_evicted when other queue activation conditions change. On the other hand, we now need to check those other queue activation conditions whenever an evicted queues is restored. To minimize code duplication, move the queue activation check into a macro so it can be maintained in one central place. Signed-off-by:
Philip Cox <Philip.Cox@amd.com> Acked-by:
-
James Zhu authored
EDC counts are related to instance and se. They are not the same for different type of EDC. EDC clearing are changed to base on individual EDC's instance and SE number. Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] DCN_VERSION_1_01 is no longer handled in the dal_hw_translate_init switch since it was inadvertently dropped in the patch that removed the unnecessary DCN1_01 guards. This caused numerous regressions on DCN1_01 when loading the driver. [How] Add it back. Fixes: 97df424f ("drm/amd/display: Drop DCN1_01 guards") Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] When switching from vt to desktop with EDID emulation we can receive an atomic commit such that we have a crtc where mode_changed = true. During the dm_update_crtc_state disable pass we remove the stream from the context and free it on the dm_new_crtc_state. During the enable pass we compare the new provisional stream to the dm_old_crtc_state->stream and determine that the stream is unchanged and no scaling has been changed. Following this, new_crtc_state->mode_changed is then set to false. The connectors haven't changed and the CRTC active state hasn't changed so drm_atomic_crtc_needs_modeset returns false, so we jump to skip_modeset and we hit: BUG_ON(dm_new_crtc_state->stream == NULL); ...since the old stream is gone from the context and the new stream is also still NULL. [How] Ensure that we still a stream to reuse before checking if we can reuse the old stream without a full modeset. Signed-off-by:
-
Christian König authored
This avoids OOM situations when we have lots of threads submitting at the same time. v3: apply this to the whole driver, not just CS Signed-off-by:
Chunming Zhou <david1.zhou@amd.com> Tested-by:
Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Signed-off-by:
-
Christian König authored
And only move them in on validation. This allows for better control when multiple processes are fighting over those resources. Signed-off-by:
-
Christian König authored
The messages about amdgpu_cs_list_validate are duplicated because the caller will complain into the logs as well and we can also get interrupted by a signal here. Also fix the the caller to not report -EAGAIN from validation. Signed-off-by:
-
Hawking Zhang authored
ras ta interface header need to be updated to match with latest ta fw updates Signed-off-by:
Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linuxDaniel Vetter authored
omapdrm changes for 5.3 - Add support for DSI command mode displays Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> From: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/a709f57d-6909-8550-3932-d84e0b5bc3ef@ti.com
-
git://linuxtv.org/pinchartl/mediaDaniel Vetter authored
R-Car DU changes for v5.3: - R8A774A1 SoC support - LVDS dual-link mode support - Support for additional formats - Misc fixes Signed-off-by:
-
- 10 Jun, 2019 1 commit
-
-
Sebastian Reichel authored
This adds the required infrastructure for manually updated displays, such as DSI command mode panels. While those panels often support partial updates we currently always do a full refresh. The display will be refreshed when something calls the dirty callback, such as libdrm's drmModeDirtyFB(). This is currently being done at least by the kernel console and Xorg (with modesetting driver) in their default configuration. Weston does not implement this and the fbdev backend does not work (display will not update). Weston's DRM backend uses double buffering and the page flip will also trigger a display refresh. Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com>
-
