- 12 12月, 2018 2 次提交
-
-
由 Nicholas Kazlauskas 提交于
[Why] If the "max bpc" isn't explicitly set in the atomic state then it have a value of 0. This has the correct behavior of limiting a panel to 8bpc in the case where the panel supports 8bpc. In the case of eDP panels this isn't a true assumption - there are panels that can only do 6bpc. Banding occurs for these displays. [How] Initialize the max_bpc when the connector resets to 8bpc. Also carry over the value when the state is duplicated. Bugzilla: https://bugs.freedesktop.org/108825 Fixes: 307638884f72 ("drm/amd/display: Support amdgpu "max bpc" connector property") Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Nicholas Kazlauskas 提交于
This reverts commit 91b66c47. Forcing RMX_ASPECT as default uses the preferred/native mode's timings for any mode the user selects and scales the image. This provides a a consistently nicer result in the case where the selected mode's refresh rate matches the native mode's refresh but this isn't always the case. For example, if the monitor is 1080p@144Hz and the preferred mode is 60Hz then even if the user selects 1080p@144Hz as their selected mode they'll get 1080p@60Hz. Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 06 12月, 2018 1 次提交
-
-
由 David Francis 提交于
[Why] Tracing is a useful and cheap debug functionality [How] This creates a new trace system amdgpu_dm, currently with three trace events amdgpu_dc_rreg and amdgpu_dc_wreg report the address and value of any dc register reads and writes amdgpu_dc_performance requires at least one of those two to be enabled. It counts the register reads and writes since the last entry v2: Don't check for NULL before kfree Signed-off-by: NDavid Francis <David.Francis@amd.com> Reviewed-by: NHarry Wentland <Harry.Wentland@amd.com> Acked-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 01 12月, 2018 16 次提交
-
-
由 Fatemeh Darbehani 提交于
[Why] To prepare for clock debug logging. With the exception of removing max_supported_dppclk_khz from logs, there are no functional changes. [How] Add clk_bypass struct and clean up buffer logic Signed-off-by: NFatemeh Darbehani <fatemeh.darbehani@amd.com> Reviewed-by: NYongqiang Sun <yongqiang.sun@amd.com> Acked-by: NSu Chung <Su.Chung@amd.com> Acked-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Steven Chiu 提交于
Signed-off-by: NSteven Chiu <steven.chiu@amd.com> Reviewed-by: NFatemeh Darbehani <Fatemeh.Darbehani@amd.com> Acked-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 David Francis 提交于
dce100 was set to always pass safe_to_lower = false to the clock manager Thus, on suspend the clocks were not being set to 0 which is incorrect behaviour This was causing s3 resume to blackscreen on intel CPUs with dce100 GPUs attached (Note that the hash in this Fixes: tag is the hash on Alex's tree) Fixes: ae7d8aeb38d7 ("drm/amd/display: remove safe_to_lower flag from dc, use 2 functions instead") Signed-off-by: NDavid Francis <David.Francis@amd.com> Reviewed-by: NHarry Wentland <Harry.Wentland@amd.com> Acked-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 SivapiriyanKumarasamy 提交于
Dithering needs to be enabled or disabled as requested. If dc_stream_update->dither_option is non-null, program the FMT blocks. Signed-off-by: NSivapiriyanKumarasamy <sivapiriyan.kumarasamy@amd.com> Reviewed-by: NAnthony Koo <Anthony.Koo@amd.com> Reviewed-by: NKrunoslav Kovac <Krunoslav.Kovac@amd.com> Acked-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Nicholas Kazlauskas 提交于
[Why] When running igt@kms_plane@pixel-format-pipe-* tests the CRC read will time out and the test will fail. This is because the CRTC is duplicated but the crc_enabled parameter isn't copied over to the new dm_crtc_state. CRC reads will time out because amdgpu_dm_crtc_handle_crc_irq will no longer call drm_crtc_add_crc_entry. [How] Copy crc_enabled when duplicating the state. Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: NDavid Francis <David.Francis@amd.com> Reviewed-by: NSun peng Li <Sunpeng.Li@amd.com> Acked-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Chiawen Huang 提交于
[why] add customizable log with a message input, which is for adding test log in debugging as printf function in ETW. [Usage] EVENT_LOG_CUST_MSG1("TestLog","Hello World %d=0x%x", 123, pDC); Signed-off-by: NChiawen Huang <chiawen.huang@amd.com> Reviewed-by: NTony Cheng <Tony.Cheng@amd.com> Acked-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Nevenko Stupar 提交于
For more clear usage in future Signed-off-by: NNevenko Stupar <Nevenko.Stupar@amd.com> Reviewed-by: NTony Cheng <Tony.Cheng@amd.com> Acked-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 hersen wu 提交于
[WHY] fbc is within the data path from memory to dce. while re-configure mc dmif, fbc should be enabled. otherwise, fbc may not be enabled properly. [HOW] before re-configure mc dmif, disable fbc, only after dmif re-configuration fully done, enable fbc again. Signed-off-by: Nhersen wu <hersenxs.wu@amd.com> Reviewed-by: NRoman Li <Roman.Li@amd.com> Acked-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Harmanprit Tatla 提交于
* Use provided infopacket in stream (if valid) instead of reconstructing in set_vendor_info_packet() * Use proper format for enums * Use dc info packet struct instead Signed-off-by: NHarmanprit Tatla <Harmanprit.Tatla@amd.com> Reviewed-by: NAnthony Koo <Anthony.Koo@amd.com> Acked-by: NKrunoslav Kovac <Krunoslav.Kovac@amd.com> Acked-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 abdoulaye berthe 提交于
[Why] Failure to read Detailed Capabilities Info. [How] Read Detailed Capbilities Info 80h-08Fh. Signed-off-by: Nabdoulaye berthe <abdoulaye.berthe@amd.com> Reviewed-by: NWenjing Liu <Wenjing.Liu@amd.com> Acked-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Krunoslav Kovac 提交于
Use axis instead of axix Signed-off-by: NKrunoslav Kovac <Krunoslav.Kovac@amd.com> Reviewed-by: NAric Cyr <Aric.Cyr@amd.com> Acked-by: NAnthony Koo <Anthony.Koo@amd.com> Acked-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Joshua Aberback 提交于
[Why] This patch is for use by dm, no need for it in dc. Signed-off-by: NJoshua Aberback <joshua.aberback@amd.com> Reviewed-by: NJun Lei <Jun.Lei@amd.com> Acked-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 David Francis 提交于
[Why] There are a lot of unintuitive parts of the dm-dc interface. It would help us if these were documented to provide a common understanding of what they are supposed to do [How] Most of this documentation is stubs, to be filled out more thoroughly by the experts Not every dm-accessible function and struct is mentioned. Simple functions like getters, setters, retain, release, create, destroy can be left unadorned. Signed-off-by: NDavid Francis <David.Francis@amd.com> Reviewed-by: NHarry Wentland <Harry.Wentland@amd.com> Acked-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Steven Chiu 提交于
Signed-off-by: NSteven Chiu <steven.chiu@amd.com> Reviewed-by: NShahin Khayyer <Shahin.Khayyer@amd.com> Acked-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Yogesh Mohan Marimuthu 提交于
[why] When there are multiple aux transaction in parallel, it is sometime sporadically the aux transaction starts to continuously fail. The aux transaction was failing because the busy bit for the given gpio pin was always set. The busy bit was alway set because the programming sequence to read, modify and write busy bit was not atomic. Due to which when multiple threads are trying to modify the busy bits for their gpio pins in the same integer variable sometimes the busy bits integer variable is written with old data causing failure. [how] Instead of using individual bits to track gpio pins and grouping them to integers, one byte will be allcoated for each gpio pin. Now whenever a gpio pin needs to be set to mark being used, only writing a value of one to that byte is sufficient, other bytes are not impacted. Also no need to have atomicity with bytes unlike with bits. Signed-off-by: NYogesh Mohan Marimuthu <yogesh.mohanmarimuthu@amd.com> Reviewed-by: NHarry Wentland <Harry.Wentland@amd.com> Acked-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Nicholas Kazlauskas 提交于
[Why] With scaling, underscan and abm changes we can end up calling commit_planes_to_stream in commit_tail. This call uses dm_state->context which can be NULL if the commit was a fast update. [How] Use dc_state instead since that can't be NULL unless the system ran out of memory. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108912 Fixes: e64abff2f133 ("drm/amd/display: Use private obj helpers for dm_atomic_state") Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 30 11月, 2018 2 次提交
-
-
由 Jerry (Fangzhi) Zuo 提交于
Calculate preferred refresh rate only when preferred mode exists. Signed-off-by: NJerry (Fangzhi) Zuo <Jerry.Zuo@amd.com> Reviewed-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Roman Li 提交于
[Why] More than 4x4K didn't lightup on Vega20 due to low dcfclk value. Powerplay expects valid min requirement for dcfclk from DC. [How] Update min_dcfclock_khz based on min_engine_clock value. Reviewed-by: NHersen Wu <hersenxs.wu@amd.com> Reviewed-by: NFeifei Xu <Feifei.Xu@amd.com> Reviewed-by: NEvan Quan <evan.quan@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NRoman Li <Roman.Li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 29 11月, 2018 3 次提交
-
-
由 Nicholas Kazlauskas 提交于
Support for AMDGPU specific FreeSync properties and ioctls are dropped from amdgpu_dm in favor of supporting drm variable refresh rate properties. The notify_freesync and set_freesync_property functions are dropped from amdgpu_display_funcs. The drm vrr_capable property is now attached to any DP/HDMI connector. Its value is updated accordingly to the connector's FreeSync capabiltiy. The freesync_enable logic and ioctl control has has been dropped in favor of utilizing the vrr_enabled on the drm CRTC. This allows for more fine grained atomic control over which CRTCs should support variable refresh rate. To handle state changes for vrr_enabled it was easiest to drop the forced modeset on freesync_enabled change. This patch now performs the required stream updates when planes are flipped. This is done for a few reasons: (1) VRR stream updates can be done in the fast update path (2) amdgpu_dm_atomic_check would need to be hacked apart to check desired variable refresh state and capability before the CRTC disable pass. (3) Performing VRR stream updates on-flip is needed for enabling BTR support. VRR packets and timing adjustments are now tracked and compared to previous values sent to the hardware. Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 David Francis 提交于
The fallback code for getting default backlight caps was using the wrong variable name. Fix it. Fixes: https://lists.freedesktop.org/archives/dri-devel/2018-November/197752.htmlSigned-off-by: NDavid Francis <David.Francis@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Nicholas Kazlauskas 提交于
[Why] Two non-blocking commits in succession can result in a sequence where the same dc->current_state is queried for both commits. 1. 1st commit -> check -> commit -> swaps atomic state -> queues work 2. 2nd commit -> check -> commit -> swaps atomic state -> queues work 3. 1st commit work finishes The issue with this sequence is that the same dc->current_state is read in both atomic checks. If the first commit modifies streams or planes those will be missing from the dc->current_state for the second atomic check. This result in many stream and plane errors in atomic commit tail. [How] The driver still needs to track old to new state to determine if the commit in its current implementation. Updating the dc_state in atomic tail is wrong since the dc_state swap should be happening as part of drm_atomic_helper_swap_state *before* the worker queue kicks its work off. The simplest replacement for the subclassing (which doesn't properly manage the old to new atomic state swap) is to use the drm private object helpers. While some of the dc_state members could be merged into dm_crtc_state or dm_plane_state and copied over that way it is easier for now to just treat the whole dc_state structure as a single private object. This allows amdgpu_dm to drop the dc->current_state copy from within atomic check. It's replaced by a copy from the current atomic state which is propagated correctly for the sequence described above. Since access to the dm_state private object is now locked this should also fix issues that could arise if submitting non-blocking commits from different threads. Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 27 11月, 2018 6 次提交
-
-
由 Brajeswar Ghosh 提交于
Remove dce/dce_mem_input.h which is included more than once Signed-off-by: NBrajeswar Ghosh <brajeswar.linux@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 David Francis 提交于
ACPI ATIF has a function called query backlight transfer characteristics. Among the information returned by this function is the minimum and maximum input signals for the backlight Call that function on ACPI init. When DM backlight device is updated, copy over the backlight caps into DM, but only once. Use the backlight caps in the backlight-to-dc calculation Signed-off-by: NDavid Francis <David.Francis@amd.com> Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 David Francis 提交于
Adaptive Backlight Management (ABM) is a feature that reduces backlight level to save power, while increasing pixel contrast and pixel luminance to maintain readability and image quality. ABM will adjust in response to the pixel luminance of the displayed content. ABM is made available as a drm property on eDP monitors called "abm level", which ranges from 0 to 4. When this property is set to 0, ABM is off. Levels 1 to 4 represent different ranges of backlight reduction. At higher levels both the backlight reduction and pixel adjustment will be greater. ABM requires DMCU firmware, which is currently available for Raven ASICs only. If the feature does not work, please ensure your firmware is up to date. v2: Fix commit message, only attach property if DMCU loaded v3: Store ABM level in crtc state to accommodate dc v4: Fix ABM saving on dpms cycle Signed-off-by: NDavid Francis <David.Francis@amd.com> Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 David Francis 提交于
DMCU IRAM must be loaded by the driver before DMCU can function. Move the IRAM code out of the shadows and into a new file modules/power/power_helpers.c The IRAM table contains the backlight curve and ABM parameters Add this new file to the Makefiles Call dmcu_load_iram in late init of DM Move struct dmcu_version from dc.h to dmcu.h to allow dmcu to be included on its own Signed-off-by: NDavid Francis <David.Francis@amd.com> Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Bhawanpreet Lakha 提交于
Before: We use drm_match_cea_mode() to get the vic for any mode we want to set, most of the time vic will be different for the new mode. DC uses memcmp to check if timing changed, in this case DC will say timing changed and we endup doing a full modeset. Current: Now we check if !RMX_OFF and old_refresh == new_refresh if so we copy the vic from old timing. In a case where we are currently on a lower timing and want to change to higher mode, stream->dst will be different and cause us to do a full modeset, which is what we want. Signed-off-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Bhawanpreet Lakha 提交于
Setting this allows for display scaling by default Signed-off-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 22 11月, 2018 2 次提交
-
-
由 Colin Ian King 提交于
Currently there are several instances of pointer fs_params being dereferenced before fs_params is being null checked. Fix this by only dereferencing fs_params after the null check. Detected by CoverityScan, CID#1475565 ("Dereference before null check") Fixes: e1e8a020 ("drm/amd/display: Add support for Freesync 2 HDR and Content to Display Mapping") Signed-off-by: NColin Ian King <colin.king@canonical.com> Reviewed-by: NLeo Li <sunpeng.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Brajeswar Ghosh 提交于
Remove dm_services_types.h which is included more than once Signed-off-by: NBrajeswar Ghosh <brajeswar.linux@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 20 11月, 2018 8 次提交
-
-
由 David Francis 提交于
[Why] There was a full clock request struct of which only one value was being used. [How] Replace the struct with a uint32_t Signed-off-by: NDavid Francis <David.Francis@amd.com> Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Reviewed-by: NSun peng Li <Sunpeng.Li@amd.com> Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Nicholas Kazlauskas 提交于
[Why] Many panels support more than 8bpc but some modes are unavailable while running at greater than 8bpc due to DP/HDMI bandwidth constraints. Support for more than 8bpc was added recently in the driver but it defaults to the maximum supported bpc - locking out these modes. This should be a user configurable option such that the user can select what bpc configuration they would like. [How] This patch adds support for getting and setting the amdgpu driver specific "max bpc" property on the connector. It also adds support for limiting the output bpc based on the property value. The default limitation is the lowest value in the range, 8bpc. This was the old value before the range was uncapped. This patch should be updated/replaced later once common drm support for max bpc lands. Bugzilla: https://bugs.freedesktop.org/108542 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201585 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200645 Fixes: e03fd3f3 ("drm/amd/display: Do not limit color depth to 8bpc") v2: rebase on upstream (Alex) Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 David Francis 提交于
[Why] dc_link_set_backlight_level can be called from a context where the stream is unknown. In this case, we can still find which controller is driving this particular backlight [How] Compare links for equality instead of streams Signed-off-by: NDavid Francis <David.Francis@amd.com> Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Charlene Liu 提交于
expose dcn10_get_surface_visual_confirm_color() to be used in the future Signed-off-by: NCharlene Liu <charlene.liu@amd.com> Reviewed-by: NDmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Dmytro Laktyushkin 提交于
A number of registers need to be updated for all active pipes wherever any pipe causes a change in watermarks. This change separates programming of these registers into a separate function call that is called for all active pipes during a bw update. Signed-off-by: NDmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by: NTony Cheng <Tony.Cheng@amd.com> Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Joshua Aberback 提交于
[Why] We observed an issue where a display would not accept programming of the ignore_MSA_timing_param bit if the stream was blanked. [How] move enable_stream_features from enable_link_dp to core_link_enable_stream, after unblank_stream Signed-off-by: NJoshua Aberback <joshua.aberback@amd.com> Reviewed-by: NJun Lei <Jun.Lei@amd.com> Acked-by: NAnthony Koo <Anthony.Koo@amd.com> Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Eric Bernstein 提交于
[Why] For some complicated blending transition cases, the head pipe of the second stream may end up being a higher pipe index than the free pipe. In those cases dc_add_plane_to_context will incorrectly set the tail_pipe to the free pipe, which will cause the top_pipe and bottom_pipe to be the same [How] Move the call to resource_get_tail_pipe_for_stream() to be before call to acquire_free_pipe_for_stream(). Signed-off-by: NEric Bernstein <eric.bernstein@amd.com> Reviewed-by: NDmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Xiaodong Yan 提交于
DPCD Extended Receiver Capability Field [Why] 1.dpcd extended receiver capability sometimes read fail, and corrupted data leads to sink caps is not correct. 2.sometimes sink reply ack with fewer data [How] check the return value of core_link_read_dpcd, try to read again when failure happens Signed-off-by: NXiaodong Yan <Xiaodong.Yan@amd.com> Reviewed-by: NWenjing Liu <Wenjing.Liu@amd.com> Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Acked-by: NTony Cheng <Tony.Cheng@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-