aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/amd
AgeCommit message (Collapse)AuthorFilesLines
2019-10-25drm/amd/display: Free gamma after calculating legacy transfer functionNicholas Kazlauskas1-0/+2
[Why] We're leaking memory by not freeing the gamma used to calculate the transfer function for legacy gamma. [How] Release the gamma after we're done with it. Signed-off-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: Leo Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-25drm/amdgpu/psp11: fix typo in commentXiaojie Yuan1-1/+1
Signed-off-by: Xiaojie Yuan <[email protected]> Reviewed-by: Feifei Xu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-25drm/amdgpu/psp11: wait for sOS ready for ring creationXiaojie Yuan1-0/+8
Signed-off-by: Xiaojie Yuan <[email protected]> Reviewed-by: Feifei Xu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-25drm/amd/display: setting the DIG_MODE to the correct value.Zhan liu1-0/+9
[Why] This patch is for fixing Navi14 HDMI display pink screen issue. [How] Call stream->link->link_enc->funcs->setup twice. This is setting the DIG_MODE to the correct value after having been overridden by the call to transmitter control. Signed-off-by: Zhan Liu <[email protected]> Reviewed-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-25drm/amdgpu/powerplay: use local renoir array sizes for clock fetchingAlex Deucher1-4/+4
To avoid walking past the end of the arrays since the PP_SMU defines don't match the renoir defines. Reviewed-by: Prike Liang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-25drm/amdgpu: call amdgpu_vm_prt_fini before deleting the root PDPelloux-prayer, Pierre-eric1-9/+10
amdgpu_vm_prt_fini uses "vm->root.base.bo" so it must still be valid when we call it. Fixes: b65709a92156 ("drm/amdgpu: reserve the root PD while freeing PASIDs") Signed-off-by: Pierre-Eric Pelloux-Prayer <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-25drm/amdgpu/vi: silence an uninitialized variable warningDan Carpenter1-0/+1
Smatch complains that we need to initialized "*cap" otherwise it can lead to an uninitialized variable bug in the caller. This seems like a reasonable warning and it doesn't hurt to silence it at least. drivers/gpu/drm/amd/amdgpu/vi.c:767 vi_asic_reset_method() error: uninitialized symbol 'baco_reset'. Fixes: 425db2553e43 ("drm/amdgpu: expose BACO interfaces to upper level from PP") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-25drm/amdgpu/vce: make some functions staticAlex Deucher2-10/+10
They are not used outside of the file they are defined in. Reviewed-by: James Zhu <[email protected]> Acked-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-25drm/amdgpu/vce: fix allocation size in enc ring testAlex Deucher2-5/+16
We need to allocate a large enough buffer for the feedback buffer, otherwise the IB test can overwrite other memory. Reviewed-by: James Zhu <[email protected]> Acked-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-25drm/amdgpu/psp: declare PSP TA firmwarechen gong1-0/+3
Add PSP TA firmware declaration for raven raven2 picasso Signed-off-by: chen gong <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-26Merge tag 'drm-next-5.5-2019-10-09' of ↵Dave Airlie245-4131/+11372
git://people.freedesktop.org/~agd5f/linux into drm-next drm-next-5.5-2019-10-09: amdgpu: - Additional RAS enablement for vega20 - RAS page retirement and bad page storage in EEPROM - No GPU reset with unrecoverable RAS errors - Reserve vram for page tables rather than trying to evict - Fix issues with GPU reset and xgmi hives - DC i2c over aux fixes - Direct submission for clears, PTE/PDE updates - Improvements to help support recoverable GPU page faults - Silence harmless SAD block messages - Clean up code for creating a bo at a fixed location - Initial DC HDCP support - Lots of documentation fixes - GPU reset for renoir - Add IH clockgating support for soc15 asics - Powerplay improvements - DC MST cleanups - Add support for MSI-X - Misc cleanups and bug fixes amdkfd: - Query KFD device info by asic type rather than pci ids - Add navi14 support - Add renoir support - Add navi12 support - gfx10 trap handler improvements - pasid cleanups - Check against device cgroup ttm: - Return -EBUSY with pipelining with no_gpu_wait radeon: - Silence harmless SAD block messages device_cgroup: - Export devcgroup_check_permission Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-25drm/ttm: remove pointers to globalsChristian König2-6/+5
As the name says global memory and bo accounting is global. So it doesn't make to much sense having pointers to global structures all around the code. Signed-off-by: Christian König <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Link: https://patchwork.freedesktop.org/patch/332879/
2019-10-25drm/ttm: always keep BOs on the LRUChristian König5-10/+9
This allows blocking for BOs to become available in the memory management. Amdgpu is doing this for quite a while now during CS. Now apply the new behavior to all drivers using TTM. Signed-off-by: Christian König <[email protected]> Acked-by: Thomas Hellstrom <[email protected]> Link: https://patchwork.freedesktop.org/patch/332878/
2019-10-24drm/dp_mst: Add basic topology reprobing when resumingLyude Paul1-1/+1
Finally! For a very long time, our MST helpers have had one very annoying issue: They don't know how to reprobe the topology state when coming out of suspend. This means that if a user has a machine connected to an MST topology and decides to suspend their machine, we lose all topology changes that happened during that period. That can be a big problem if the machine was connected to a different topology on the same port before resuming, as we won't bother reprobing any of the ports and likely cause the user's monitors not to come back up as expected. So, we start fixing this by teaching our MST helpers how to reprobe the link addresses of each connected topology when resuming. As it turns out, the behavior that we want here is identical to the behavior we want when initially probing a newly connected MST topology, with a couple of important differences: - We need to be more careful about handling the potential races between events from the MST hub that could change the topology state as we're performing the link address reprobe - We need to be more careful about handling unlikely state changes on ports - such as an input port turning into an output port, something that would be far more likely to happen in situations like the MST hub we're connected to being changed while we're suspend Both of which have been solved by previous commits. That leaves one requirement: - We need to prune any MST ports in our in-memory topology state that were present when suspending, but have not appeared in the post-resume link address response from their parent branch device Which we can now handle in this commit by modifying drm_dp_send_link_address(). We then introduce suspend/resume reprobing by introducing drm_dp_mst_topology_mgr_invalidate_mstb(), which we call in drm_dp_mst_topology_mgr_suspend() to traverse the in-memory topology state to indicate that each mstb needs it's link address resent and PBN resources reprobed. On resume, we start back up &mgr->work and have it reprobe the topology in the same way we would on a hotplug, removing any leftover ports that no longer appear in the topology state. Changes since v4: * Split indenting changes in drm_dp_mst_topology_mgr_resume() into a separate patch * Only fire hotplugs when something has actually changed after a link address probe * Don't try to change port->connector at all on ports, just throw out ports that need their connectors removed to make things easier. Cc: Juston Li <[email protected]> Cc: Imre Deak <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Harry Wentland <[email protected]> Cc: Daniel Vetter <[email protected]> Reviewed-by: Sean Paul <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-24drm/amdgpu/dm: Resume short HPD IRQs before resuming MST topologyLyude Paul1-3/+3
Since we're going to be reprobing the entire topology state on resume now using sideband transactions, we need to ensure that we actually have short HPD irqs enabled before calling drm_dp_mst_topology_mgr_resume(). So, do that. Changes since v3: * Fix typo in comments Cc: Juston Li <[email protected]> Cc: Imre Deak <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Harry Wentland <[email protected]> Cc: Daniel Vetter <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-24drm/amdgpu: Iterate through DRM connectors correctlyLyude Paul11-73/+195
Currently, every single piece of code in amdgpu that loops through connectors does it incorrectly and doesn't use the proper list iteration helpers, drm_connector_list_iter_begin() and drm_connector_list_iter_end(). Yeesh. So, do that. Cc: Juston Li <[email protected]> Cc: Imre Deak <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Harry Wentland <[email protected]> Cc: Daniel Vetter <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-24drm/dp_mst: Protect drm_dp_mst_port members with lockingLyude Paul1-16/+12
This is a complicated one. Essentially, there's currently a problem in the MST core that hasn't really caused any issues that we're aware of (emphasis on "that we're aware of"): locking. When we go through and probe the link addresses and path resources in a topology, we hold no locks when updating ports with said information. The members I'm referring to in particular are: - ldps - ddps - mcs - pdt - dpcd_rev - num_sdp_streams - num_sdp_stream_sinks - available_pbn - input - connector Now that we're handling UP requests asynchronously and will be using some of the struct members mentioned above in atomic modesetting in the future for features such as PBN validation, this is going to become a lot more important. As well, the next few commits that prepare us for and introduce suspend/resume reprobing will also need clear locking in order to prevent from additional racing hilarities that we never could have hit in the past. So, let's solve this issue by using &mgr->base.lock, the modesetting lock which currently only protects &mgr->base.state. This works perfectly because it allows us to avoid blocking connection_mutex unnecessarily, and we can grab this in connector detection paths since it's a ww mutex. We start by having drm_dp_mst_handle_up_req() hold this when updating ports. For drm_dp_mst_handle_link_address_port() things are a bit more complicated. As I've learned the hard way, we can grab &mgr->lock.base for everything except for port->connector. See, our normal driver probing paths end up generating this rather obvious lockdep chain: &drm->mode_config.mutex -> crtc_ww_class_mutex/crtc_ww_class_acquire -> &connector->mutex However, sysfs grabs &drm->mode_config.mutex in order to protect itself from connector state changing under it. Because this entails grabbing kn->count, e.g. the lock that the kernel provides for protecting sysfs contexts, we end up grabbing kn->count followed by &drm->mode_config.mutex. This ends up creating an extremely rude chain: &kn->count -> &drm->mode_config.mutex -> crtc_ww_class_mutex/crtc_ww_class_acquire -> &connector->mutex I mean, look at that thing! It's just evil!!! This gross thing ends up making any calls to drm_connector_register()/drm_connector_unregister() impossible when holding any kind of modesetting lock. This is annoying because ideally, we always want to ensure that drm_dp_mst_port->connector never changes when doing an atomic commit or check that would affect the atomic topology state so that it can reliably and easily be used from future DRM DP MST helpers to assist with tasks such as scanning through the current VCPI allocations and adding connectors which need to have their allocations updated in response to a bandwidth change or the like. Being able to hold &mgr->base.lock throughout the entire link probe process would have been _great_, since we could prevent userspace from ever seeing any states in-between individual port changes and as a result likely end up with a much faster probe and more consistent results from said probes. But without some rework of how we handle connector probing in sysfs it's not at all currently possible. In the future, maybe we can try using the sysfs locks to protect updates to connector probing state and fix this mess. So for now, to protect everything other than port->connector under &mgr->base.lock and ensure that we still have the guarantee that atomic check/commit contexts will never see port->connector change we use a silly trick. See: port->connector only needs to change in order to ensure that input ports (see the MST spec) never have a ghost connector associated with them. But, there's nothing stopping us from simply throwing the entire port out and creating a new one in order to maintain that requirement while still keeping port->connector consistent across the lifetime of the port in atomic check/commit contexts. For all intended purposes this works fine, as we validate ports in any contexts we care about before using them and as such will end up reporting the connector as disconnected until it's port's destruction finalizes. So, we just do that in cases where we detect port->input has transitioned from true->false. We don't need to worry about the other direction, since a port without a connector isn't visible to userspace and as such doesn't need to be protected by &mgr->base.lock until we finish registering a connector for it. For updating members of drm_dp_mst_port other than port->connector, we simply grab &mgr->base.lock in drm_dp_mst_link_probe_work() for already registered ports, update said members and drop the lock before potentially registering a connector and probing the link address of it's children. Finally, we modify drm_dp_mst_detect_port() to take a modesetting lock acquisition context in order to acquire &mgr->base.lock under &connection_mutex and convert all it's users over to using the .detect_ctx probe hooks. With that, we finally have well defined locking. Changes since v4: * Get rid of port->mutex, stop using connection_mutex and just use our own modesetting lock - mgr->base.lock. Also, add a probe_lock that comes before this patch. * Just throw out ports that get changed from an output to an input, and replace them with new ports. This lets us ensure that modesetting contexts never see port->connector go from having a connector to being NULL. * Write an extremely detailed explanation of what problems this is trying to fix, since there's a _lot_ of context here and I honestly forgot some of it myself a couple times. * Don't grab mgr->lock when reading port->mstb in drm_dp_mst_handle_link_address_port(). It's not needed. Cc: Juston Li <[email protected]> Cc: Imre Deak <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Harry Wentland <[email protected]> Cc: Daniel Vetter <[email protected]> Reviewed-by: Sean Paul <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-23Merge drm/drm-next into drm-misc-nextSean Paul28-79/+128
Parroting Daniel's backmerge justification from 2e79e22e092acd55da0b2db066e4826d7d152c41: Thierry needs fd70c7755bf0 ("drm/bridge: tc358767: fix max_tu_symbol value") to be able to merge his dp_link patch series. Signed-off-by: Sean Paul <[email protected]>
2019-10-23Merge v5.4-rc4 into drm-nextDaniel Vetter6-45/+45
Thierry needs fd70c7755bf0 ("drm/bridge: tc358767: fix max_tu_symbol value") to be able to merge his dp_link patch series. Some adjacent changes conflicts, plus some clashes in i915 due to cherry-picking and git trying to be helpful and leaving both versions in. Signed-off-by: Daniel Vetter <[email protected]>
2019-10-17drm/amdgpu: fix amdgpu trace event print string format errorKevin Wang1-9/+9
the trace event print string format error. (use integer type to handle string) before: amdgpu_test_kev-1556 [002] 138.508781: amdgpu_cs_ioctl: sched_job=8, timeline=gfx_0.0.0, context=177, seqno=1, ring_name=ffff94d01c207bf0, num_ibs=2 after: amdgpu_test_kev-1506 [004] 370.703783: amdgpu_cs_ioctl: sched_job=12, timeline=gfx_0.0.0, context=234, seqno=2, ring_name=gfx_0.0.0, num_ibs=1 change trace event list: 1.amdgpu_cs_ioctl 2.amdgpu_sched_run_job 3.amdgpu_ib_pipe_sync Signed-off-by: Kevin Wang <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amdgpu/psp: add psp memory training implementation(v3)Tianci.Yin3-0/+171
add memory training implementation code to save resume time. Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Luben Tuikov <[email protected]> Signed-off-by: Tianci.Yin <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amdgpu: reserve vram for memory training(v4)Tianci.Yin1-0/+91
memory training using specific fixed vram segment, reserve these segments before anyone may allocate it. Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Luben Tuikov <[email protected]> Signed-off-by: Tianci.Yin <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amdgpu: add psp memory training callbacks and macroTianci.Yin2-0/+73
add interface for memory training. Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Luben Tuikov <[email protected]> Signed-off-by: Tianci.Yin <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amdgpu/atomfirmware: add memory training related helper functions(v3)Tianci.Yin4-0/+150
parse firmware to get memory training capability and fb location. Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Luben Tuikov <[email protected]> Signed-off-by: Tianci.Yin <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amdgpu: update atomfirmware header with memory training related members(v3)Tianci.Yin1-6/+21
add new vram_reserve_block structure and atomfirmware_internal_constants enumeration Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Luben Tuikov <[email protected]> Signed-off-by: Tianci.Yin <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amdgpu: introduce psp_v11_0_is_sos_alive interface(v2)Tianci.Yin1-9/+13
introduce psp_v11_0_is_sos_alive func for common use. Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Luben Tuikov <[email protected]> Signed-off-by: Tianci.Yin <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amdgpu: add a generic fb accessing helper function(v3)Tianci.Yin3-11/+33
add a generic helper function for accessing framebuffer via MMIO Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Luben Tuikov <[email protected]> Signed-off-by: Tianci.Yin <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amdgpu: update amdgpu_discovery to handle revisionTianci.Yin2-2/+4
update amdgpu_discovery to get IP revision. Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Luben Tuikov <[email protected]> Signed-off-by: Tianci.Yin <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amdgpu/powerplay: implement interface pp_power_profile_modePrike Liang1-0/+34
implement get_power_profile_mode for getting power profile mode status. Signed-off-by: Prike Liang <[email protected]> Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amdgpu/vcn: fix allocation size in enc ring testAlex Deucher1-12/+23
We need to allocate a large enough buffer for the session info, otherwise the IB test can overwrite other memory. - Session info is 128K according to mesa - Use the same session info for create and destroy Bug: https://bugzilla.kernel.org/show_bug.cgi?id=204241 Acked-by: Christian König <[email protected]> Reviewed-by: James Zhu <[email protected]> Tested-by: James Zhu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amdgpu/uvd7: fix allocation size in enc ring test (v2)Alex Deucher1-11/+22
We need to allocate a large enough buffer for the session info, otherwise the IB test can overwrite other memory. v2: - session info is 128K according to mesa - use the same session info for create and destroy Bug: https://bugzilla.kernel.org/show_bug.cgi?id=204241 Acked-by: Christian König <[email protected]> Reviewed-by: James Zhu <[email protected]> Tested-by: James Zhu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amdgpu/uvd6: fix allocation size in enc ring test (v2)Alex Deucher1-10/+21
We need to allocate a large enough buffer for the session info, otherwise the IB test can overwrite other memory. v2: - session info is 128K according to mesa - use the same session info for create and destroy Bug: https://bugzilla.kernel.org/show_bug.cgi?id=204241 Acked-by: Christian König <[email protected]> Reviewed-by: James Zhu <[email protected]> Tested-by: James Zhu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amdgpu/display: fix build when CONFIG_DRM_AMD_DC_DSC_SUPPORT=nAlex Deucher1-0/+2
Add proper config check. Reviewed-by: Mikita Lipski <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amd/display: Make dc_link_detect_helper staticYueHaibing1-1/+2
Fix sparse warning: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:746:6: warning: symbol 'dc_link_detect_helper' was not declared. Should it be static? Reported-by: Hulk Robot <[email protected]> Signed-off-by: YueHaibing <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amd/display: null check pp_smu clock table before using itBhawanpreet Lakha1-1/+1
Signed-off-by: Bhawanpreet Lakha <[email protected]> Reviewed-by: Roman Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amd/display: handle dp is usb-cBhawanpreet Lakha3-1/+116
This patch adds handling of dp is usb-c, it is not tested but is needed to support dp over usb-c Signed-off-by: Bhawanpreet Lakha <[email protected]> Reviewed-by: Roman Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amd/display: use requested_dispclk_khz instead of clkBhawanpreet Lakha1-11/+2
Use requested_dispclk_khz / 1000 directly Signed-off-by: Bhawanpreet Lakha <[email protected]> Reviewed-by: Roman Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amd/display: enable smu set dcfclkLewis Huang1-2/+2
[Why] SMU fixed this issue after version 0x370c00 [How] enable smu send message to set dcfclk after smu version 0x370c00 Signed-off-by: Lewis Huang <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Reviewed-by: Roman Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amd/display: fix header for RN clk mgrjoseph gravenor1-1/+1
[why] Should always MP0_BASE for any register definition from MP per-IP header files. I belive the reason the linux version of MP1_BASE works is The 0th element of the 0th table of that is identical to the corrisponding value of MP0_BASE in the renoir offset header file. The reason we should only use MP0_BASE is There is only one set of per-IP headers MP that includes all register definitions related to SMU IP block. This IP includes MP0, MP1, MP2 and an ecryption engine that can be used only by MP0. As a result all register definitions from MP file should be based only on MP0_BASE data. [How] Change MP1_BASE to MP0_BASE Signed-off-by: joseph gravenor <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Reviewed-by: Roman Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amd/display: add sanity check for clk table from smuEric Yang1-0/+8
[Why] Handle the case where we don't get a valid table. Also fixes compiler warning for variable potentially used before assignment. [How] If the entire table has no valid fclk, reject the table and use our own hard code. Signed-off-by: Eric Yang <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Reviewed-by: Roman Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amd/display: Fix rn audio playback and video playback speedMichael Strauss1-8/+7
[WHY] dprefclk is improperly read due to incorrect units used. Causes an audio clock to be improperly set, making audio non-functional and videos play back too fast [HOW] Scale dprefclk value from MHz to KHz (multiply by 1000) to ensure that dprefclk_khz is in correct units Signed-off-by: Michael Strauss <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Reviewed-by: Roman Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amd/display: handle "18" case in TruncToValidBPPBhawanpreet Lakha1-0/+2
Handle 18 DecimalBPP like other cases Signed-off-by: Bhawanpreet Lakha <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Reviewed-by: Roman Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amd/display: update odm mode validation to be in line with policyDmytro Laktyushkin1-1/+8
Previously 8k30 worked with dsc and odm combine due to a workaround that ran the formula a second time with dsc support enable should dsc validation fail. This worked when clocks were low enough for formula to enable odm to lower voltage, however now broke due to increased clocks. This change updates the ODM combine policy within the formula to properly reflect our current policy within DC, only enabling ODM when we have to, as well as adding a check for viewport width when dsc is enabled. As a side effect the redundant call to dml when odm is required is now unnecessary. Signed-off-by: Dmytro Laktyushkin <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Reviewed-by: Roman Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amd/display: add dummy functions to smu for Renoir Silicon DiagsSung Lee1-1/+1
[Why] Previously only dummy functions were added in Diags for FPGA. On silicon, this would lead to a segmentation fault on silicon diags. [How] Check if diags silicon and if so, add dummy functions. Signed-off-by: Sung Lee <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Reviewed-by: Roman Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amd/display: change PP_SM defs to 8Bhawanpreet Lakha1-2/+2
DPM level is 8 these were incorrect before. Fix them Signed-off-by: Bhawanpreet Lakha <[email protected]> Reviewed-by: Roman Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amd/display: update renoir bounding box and res_capsBhawanpreet Lakha1-11/+13
The values for bounding box and res_caps were incorrect. So Fix them Signed-off-by: Bhawanpreet Lakha <[email protected]> Reviewed-by: Roman Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amd/display: update dcn21 hubbub registersBhawanpreet Lakha1-10/+7
use dcn20 common regs define to share some regs with dcn20 Signed-off-by: Bhawanpreet Lakha <[email protected]> Reviewed-by: Roman Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amd/display: add detile buffer size for renoirBhawanpreet Lakha1-0/+1
Detile buffer size affects dcc caps, it was already added for dcn2. Now add it for dcn21 Signed-off-by: Bhawanpreet Lakha <[email protected]> Reviewed-by: Roman Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amd/display: correct dcn21 NUM_VMID to 16Dmytro Laktyushkin1-1/+1
1 vmid limitation only exists for HOSTVM which is a custom use case anyway. Signed-off-by: Dmytro Laktyushkin <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Reviewed-by: Roman Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-17drm/amd/display: use dcn10 version of program tiling on RenoirEric Yang1-1/+3
[Why] Renoir is gfx9, same as dcn10, not dcn20. Signed-off-by: Eric Yang <[email protected]> Acked-by: Bhawanpreet Lakha <[email protected]> Reviewed-by: Roman Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.