- 19 Apr, 2019 1 commit
-
-
Evan Quan authored
PSP SOS firmware needs to be 0x80067 or later. Signed-off-by:
Evan Quan <evan.quan@amd.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
- 15 Apr, 2019 20 commits
-
-
Joshua Aberback authored
[Why] We used this change to investigate the performance of bandwidth validation, it will be useful to have if we need to investigate further. [How] We use performance counter tick numbers to profile performance, they live at dc->debug.bw_val_profile (set .enable in debugger to turn on measuring). Signed-off-by:
Joshua Aberback <joshua.aberback@amd.com> Reviewed-by:
Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by:
-
Joshua Aberback authored
Add a fast_validate parameter in dc_validate_global_state for future use Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] As long as we have at least one non-cursor plane enabled on a CRTC then the CRTC itself can remain enabled. This will allow for commits where there's an overlay plane enabled but no primary plane enabled. [How] Remove existing primary plane fb != NULL checks and replace them with the new does_crtc_have_active_plane helper. This will be called from atomic check when validating the CRTC. Since the primary plane state can now potentially be NULL we'll need to guard for that when accessing it in some of the cursor logic. Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by:
David Francis <David.Francis@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] Surface scaling info updates can affect bandwidth and blocks. We need to be checking these with global validation to avoid underflow or corruption. [How] Drop the state->allow_modeset early exit in dm_determine_update_type_for_commit. Most of those should be considered fast now anyway. Fill in scaling info and it to the surface update in atomic check. Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] DM thinks that the update type should be full whenever a stream or plane is added or removed (including recreations). This won't match in the case where DC thinks what looks like a fast update to DM is actually a medium or full - like scaling changes that affect bandwidth and clocks. [How] Drop this warning. DC knows better than the DM does for determining cases like this. The other warning can be kept for now since it would warn on a pretty serious DC or DM bug. Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] DC expects the surface memory address to identify the surface. This doesn't work with what we're doing with the temporary surfaces, it will always assume this is a full update because the surface isn't in the current context. [How] Use the surface directly. This doesn't give us much improvement yet, since we always create a new dc_plane_state when state->allow_modeset is true. The call into dc_check_update_surfaces_for_stream also needs to be locked, for two reasons: 1. It checks the current DC state 2. It modifies the surface update flags Both of which could be currently in the middle of commit work from commit tail. A TODO here is to pass the context explicitly into this function and find a way to get the surface update flags out of it without modifying the surface in place. Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] Planes have downscaling limits and upscaling limits per format and DM is expected to validate these using DC caps. We should fail atomic check validation if we aren't capable of doing the scaling. [How] We don't currently create store which DC plane maps to which DRM plane so we can't easily check the caps directly. For now add basic constraints that cover the absolute min and max downscale / upscale limits for most RGB and YUV formats across ASICs. Leave a TODO indicating that these should really be done with DC caps. We'll probably need to subclass DRM planes again in order to correctly identify which DC plane maps to it. Signed-off-by:
Harry Wentland <Harry.Wentland@amd.com> Reviewed-by:
-
Samson Tam authored
[Why] DM doesn't need to know which link cap is being retrieved ( verified or preferred ). Let DC figure it out. [How] Change name. Signed-off-by:
Samson Tam <Samson.Tam@amd.com> Reviewed-by:
-
Nicholas Kazlauskas authored
[Why] We currently don't do DC validation for medium or full updates where the plane state isn't created. There are some medium and full updates that can cause bandwidth or clock changes to occur resulting in underflow or corruption. We need to be able to fill surface and plane info updates during atomic commit for dm_determine_update_type for commit. Since we already do this during atomic commit tail it would be good if we had the same logic in both places for creating these structures. [How] Introduce fill_dc_scaling_info and fill_dc_plane_info_and_addr. These two functions cover the following three update structures: - struct dc_scaling_info - struct dc_plane_info - struct dc_plane_address Cleanup and adapter the existing fill_plane_* helpers to work with these functions. Update call sites that used most of these sub helpers directly to work with the new functions. The exception being prepare_fb - we just want the new buffer attributes specifically in the case where we're creating the plane. This is needed for dc_commit_state in the case where the FB hasn't been previously been used. This isn't quite a refactor, but functionally driver behavior should be mostly the smae as before. The one exception is that we now check the return code for fill_plane_buffer_attributes which means that commits will be rejected that try to enable DCC with erroneous parameters. Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] Pitch was only calculated based on format whenever the plane state was recreated. This could result in surface corruption due to the incorrect pitch being programmed when the surface pitch changed during commits where state->allow_modeset = false. [How] Recalculate pitch at the same time we update the buffer address and other buffer attributes. This function was previously called fill_plane_tiling_attributes but I've also renamed it to fill_plane_buffer_attributes to clarify the actual intent of the function now that it's handling most buffer related attributes. Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] The overlay will be incorrectly placed *below* the primary plane for commits with state->allow_modeset = true because the primary plane won't be removed and recreated in the same commit. [How] Add the should_reset_plane helper to determine if the plane should be reset or not. If we need to add or force reset any plane in the context then we'll need to do the same for every plane on the stream. Unfortunately we need to do the remove / recreate routine for removing planes as well since DC currently isn't well equipped to handle the plane with the top pipe being removed with other planes still active. Signed-off-by:
Sun peng Li <Sunpeng.Li@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] Plane scaling parameters are not correctly filled or updated when performing fast updates. They're filled when creating the dc plane state and during atomic check. While the atomic check code path happens for the plane even during fast updates, the issue is that they're done in place on the dc_plane_state directly. This dc_plane_state may be the current state plane state being used by the hardware, so these parameters won't be correctly programmed. The new scaling parameters should instead be passed as an update to the plane. [How] Update fill_rects_from_plane_state to not modify dc_plane_state directly. Update the call sites that use this to fill in the appropriate values. Signed-off-by:
-
Aric Cyr authored
Signed-off-by:
Aric Cyr <aric.cyr@amd.com> Reviewed-by:
-
Anthony Koo authored
[Why] Unlike external DP panels, internal eDP does not perform verify link caps because the panel connection is fixed. So if GOP enabled the eDP at boot, we can retain its trained link settings to optimize. [How] Read the lane count and link rate by reading this information from DPCD 100h, 101h, 115h Signed-off-by:
Anthony Koo <Anthony.Koo@amd.com> Reviewed-by:
-
Yongqiang Sun authored
Signed-off-by:
Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by:
-
David Francis authored
[Why] dc_stream_get_crtc_position can return false. This was unhandled in delay_cursor_until_vupdate [How] If dc_stream_get_crtc_position returns false, something is weird. Don't delay. Signed-off-by:
-
Jun Lei authored
[why] there are some scaling capabilities such as fp16 which are known to be unsupported on a given ASIC. exposing these static capabilities allows much simpler implementation for OS interfaces which require to report such static capabilities to reduce the number of dynamic validation calls [how] refactor the existing plane caps to be more extensible, and add fp16 and scaling capabilities Signed-off-by:
Jun Lei <Jun.Lei@amd.com> Reviewed-by:
-
Nicholas Kazlauskas authored
[Why] We need DC's color space to match the color encoding and color space specified by userspace to correctly render YUV surfaces. [How] Add the DRM color properties when the DC plane supports NV12. Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] Hardware can support video surfaces and DC tells us which planes are suitable via DC plane caps. [How] The supported formats array will now vary based on what DC tells us, so create an array and fill it dynamically based on plane types and caps. Ideally we'd query support for every format via DC plane caps, but for the framework is in place to do so later with this. Signed-off-by:
-
Anthony Koo authored
[Why] Some LED Driver might not like Fractional PWM especially at extreme ranges near 0% or 100%. For example, backlight flashing could be observed. We want a way to switch fractional PWM on/off either for debug, or possibly production. [How] Add DC code that can send new FW command to enable/disable fractional PWM. Signed-off-by:
-
- 12 Apr, 2019 7 commits
-
-
shaoyunl authored
Driver need to call SMU to set xgmi pstate Signed-off-by:
shaoyunl <shaoyun.liu@amd.com> Reviewed-by:
-
shaoyunl authored
XGMI pstate is controlled by SMU, driver need this interface to communicate with SMU Signed-off-by:
-
Christian König authored
We don't hold a reference to the old fence, so it can go away any time we are waiting for it to signal. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Chunming Zhou <david1.zhou@amd.com> Signed-off-by:
-
Chunming Zhou authored
v2: update version for amd-staging-drm-next merge Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
-
Chunming Zhou authored
syncobj wait/signal operation is appending in command submission. v2: separate to two kinds in/out_deps functions v3: fix checking for timeline syncobj Signed-off-by:
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
- Fixes for powerplay custom profiles - DC bandwidth clean ups and fixes - RAS fixes for vega20 - DC atomic resume fix - Better plane handling in DC - Freesync improvements - Misc bug fixes and cleanups Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190411031242.3337-1-alexander.deucher@amd.com
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for 5.2: UAPI Changes: - None Cross-subsystem Changes: -MAINTAINERS: Add moderation flag for lima mailing list (Randy) -dt-bindings: Add Mali Bifrost bindings (Neil) -dt-bindings: Add G12A compatibility strings to meson bindings (Neil) Core Changes: -Add a handful of format helpers (Gerd) Driver Changes: -cirrus: Driver rewrite megapatch (Gerd) -meson: Add G12A support to meson driver (Neil) -lima: Couple fixes (Qiang) Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Qiang Yu <yuq825@gmail.com> Signed-off-by:
-
- 10 Apr, 2019 12 commits
-
-
Dmytro Laktyushkin authored
Simply return true/false, don't iterate up the tree. Signed-off-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by:
Nikola Cornij <Nikola.Cornij@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] When deciding to add properties or expose formats on DRM planes we should be querying the caps for the DC plane it's supposed to represent. [How] Pass plane caps down into plane initialization, refactoring overlay plane initialization to have the overlay plane be represented by the first overlay capable DC plane. Signed-off-by:
-
Leo Li authored
[Why] dcn*_disable_plane() doesn't unlock the pipe anymore, making the extra lock unnecessary. In addition - during full plane updates - all necessary pipes should be locked/unlocked together when modifying hubp to avoid tearing in pipesplit setups. [How] Remove redundant locks, and add function to lock all pipes. If an interdependent pipe update is required, lock down all pipes. Otherwise, lock only the top pipe for the updated pipe tree. Signed-off-by:
-
Leo Li authored
[Why] When entering S3, amdgpu first calls DRM to cache the current atomic state, then commit the 'all-disabled' state. This sets dc->current_state to point at the private atomic object's dm_atomic_state->context, as any regular atomic commit would. Afterwards, amdgpu_dm calls dc_set_power_state() with S3 power state. This invalidates dc->current_state by wiping it to 0, consequently wiping dm_atomic_state->context. During resume, the cached atomic state is restored. When getting the private object however, the dm_atomic_state - containing the wiped context - is duplicated into the atomic state. This causes DC validation to fail during atomic check, as necessary function pointers in dc_state are now NULL. [How] Recreate the private object's dm_atomic_state->context during resume, restoring any static values such as function pointers. A TODO item is added to move static read-only values out of dc_state - they shouldn't be there anyways. Signed-off-by:
-
Murton Liu authored
[Why] Checking against a TF that is unused causes us to default to black [How] Check against PQ instead Signed-off-by:
Murton Liu <murton.liu@amd.com> Reviewed-by:
-
Eric Yang authored
[Why] New seamless boot sequence introduced a bug where front end is disabled without blanking otg. [How] Adjust the condition of blanking otg to match seamless boot. Signed-off-by:
Eric Yang <Eric.Yang2@amd.com> Reviewed-by:
-
Anthony Koo authored
[Why] If link is already enabled at a different rate (for example 5.4 Gbps) then calling VBIOS command table to switch to a new rate (for example 2.7 Gbps) will not take effect. This can lead to link training failure to occur. [How] If the requested link rate is different than the current link rate, the link must be disabled in order to re-enable at the new link rate. In today's logic it is currently only impacting eDP since DP connection types will always disable the link during display detection, when initial link verification occurs. Signed-off-by:
-
Anthony Koo authored
[Why] In some cases we want DC init to take in some config options [How] Init dc_config before rest of DC init Signed-off-by:
-
SivapiriyanKumarasamy authored
[Why] In HDR configurations, the cursor - in SDR - needs to have it's white level boosted. [How] Program the cursor boost in update_dchubp_dpp like the other cursor attributes. Signed-off-by:
SivapiriyanKumarasamy <sivapiriyan.kumarasamy@amd.com> Reviewed-by:
Reza Amini <Reza.Amini@amd.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] We need DC's color space to match the color encoding and color space specified by userspace to correctly render YUV surfaces. [How] Convert the DRM color encoding and color range properties to the appropriate DC colorspace option and update the color space when performing surface updates. Signed-off-by:
-
Wenjing Liu authored
[why] when preferred link cap is set, we should always use preferred in all validation. we should not use preferred for some validation but use verified for others. [how] create getter function that gets verified link cap. if preferred is set, return preferred link settings instead. Signed-off-by:
Wenjing Liu <Wenjing.Liu@amd.com> Reviewed-by:
-
Josip Pavic authored
[Why] Image brightness compensation for solid color full screen images is expected to be optimal for ABM 2.2 at level 3. The min reduction that is currently being enforced prevents this from being achieved. [How] Remove the min reduction for ABM 2.2 at level 3 Signed-off-by:
Josip Pavic <Josip.Pavic@amd.com> Reviewed-by:
-
