summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/amd/display
Commit message (Collapse)AuthorAgeFilesLines
...
* | Merge tag 'drm-next-2019-05-09' of git://anongit.freedesktop.org/drm/drmLinus Torvalds2019-05-0893-1658/+3952
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull drm updates from Dave Airlie: "This has two exciting community drivers for ARM Mali accelerators. Since ARM has never been open source friendly on the GPU side of the house, the community has had to create open source drivers for the Mali GPUs. Lima covers the older t4xx and panfrost the newer 6xx/7xx series. Well done to all involved and hopefully this will help ARM head in the right direction. There is also now the ability if you don't have any of the legacy drivers enabled (pre-KMS) to remove all the pre-KMS support code from the core drm, this saves 10% or so in codesize on my machine. i915 also enable Icelake/Elkhart Lake Gen11 GPUs by default, vboxvideo moves out of staging. There are also some rcar-du patches which crossover with media tree but all should be acked by Mauro. Summary: uapi changes: - Colorspace connector property - fourcc - new YUV formts - timeline sync objects initially merged - expose FB_DAMAGE_CLIPS to atomic userspace new drivers: - vboxvideo: moved out of staging - aspeed: ASPEED SoC BMC chip display support - lima: ARM Mali4xx GPU acceleration driver support - panfrost: ARM Mali6xx/7xx Midgard/Bitfrost acceleration driver support core: - component helper docs - unplugging fixes - devm device init - MIPI/DSI rate control - shmem backed gem objects - connector, display_info, edid_quirks cleanups - dma_buf fence chain support - 64-bit dma-fence seqno comparison fixes - move initial fb config code to core - gem fence array helpers for Lima - ability to remove legacy support code if no drivers requires it (removes 10% of drm.ko size) - lease fixes ttm: - unified DRM_FILE_PAGE_OFFSET handling - Account for kernel allocations in kernel zone only panel: - OSD070T1718-19TS panel support - panel-tpo-td028ttec1 backlight support - Ronbo RB070D30 MIPI/DSI - Feiyang FY07024DI26A30-D MIPI-DSI panel - Rocktech jh057n00900 MIPI-DSI panel i915: - Comet Lake (Gen9) PCI IDs - Updated Icelake PCI IDs - Elkhartlake (Gen11) support - DP MST property addtions - plane and watermark fixes - Icelake port sync and VEBOX disable fixes - struct_mutex usage reduction - Icelake gamma fix - GuC reset fixes - make mmap more asynchronous - sound display power well race fixes - DDI/MIPI-DSI clocks for Icelake - Icelake RPS frequency changing support - Icelake workarounds amdgpu: - Use HMM for userptr - vega20 experimental smu11 support - RAS support for vega20 - BACO support for vega12 + fixes for vega20 - reworked IH interrupt handling - amdkfd RAS support - Freesync improvements - initial timeline sync object support - DC Z ordering fixes - NV12 planes support - colorspace properties for planes= - eDP opts if eDP already initialized nouveau: - misc fixes etnaviv: - misc fixes msm: - GPU zap shader support expansion - robustness ABI addition exynos: - Logging cleanups tegra: - Shared reset fix - CPU cache maintenance fix cirrus: - driver rewritten using simple helpers meson: - G12A support vmwgfx: - Resource dirtying management improvements - Userspace logging improvements virtio: - PRIME fixes rockchip: - rk3066 hdmi support sun4i: - DSI burst mode support vc4: - load tracker to detect underflow v3d: - v3d v4.2 support malidp: - initial Mali D71 support in komeda driver tfp410: - omap related improvement omapdrm: - drm bridge/panel support - drop some omap specific panels rcar-du: - Display writeback support" * tag 'drm-next-2019-05-09' of git://anongit.freedesktop.org/drm/drm: (1507 commits) drm/msm/a6xx: No zap shader is not an error drm/cma-helper: Fix drm_gem_cma_free_object() drm: Fix timestamp docs for variable refresh properties. drm/komeda: Mark the local functions as static drm/komeda: Fixed warning: Function parameter or member not described drm/komeda: Expose bus_width to Komeda-CORE drm/komeda: Add sysfs attribute: core_id and config_id drm: add non-desktop quirk for Valve HMDs drm/panfrost: Show stored feature registers drm/panfrost: Don't scream about deferred probe drm/panfrost: Disable PM on probe failure drm/panfrost: Set DMA masks earlier drm/panfrost: Add sanity checks to submit IOCTL drm/etnaviv: initialize idle mask before querying the HW db drm: introduce a capability flag for syncobj timeline support drm: report consistent errors when checking syncobj capibility drm/nouveau/nouveau: forward error generated while resuming objects tree drm/nouveau/fb/ramgk104: fix spelling mistake "sucessfully" -> "successfully" drm/nouveau/i2c: Disable i2c bus access after ->fini() drm/nouveau: Remove duplicate ACPI_VIDEO_NOTIFY_PROBE definition ...
| * Merge branch 'drm-next-5.2' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2019-05-0323-233/+524
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-next - SR-IOV fixes - Raven flickering fix - Misc spelling fixes - Vega20 power fixes - Freesync improvements - DC fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190502193020.3562-1-alexander.deucher@amd.com
| | * drm/amd/display: Compensate for pre-DCE12 BTR-VRR hw limitations. (v3)Mario Kleiner2019-04-291-4/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pre-DCE12 needs special treatment for BTR / low framerate compensation for more stable behaviour: According to comments in the code and some testing on DCE-8 and DCE-11, DCE-11 and earlier only apply VTOTAL_MIN/MAX programming with a lag of one frame, so the special BTR hw programming for intermediate fixed duration frames must be done inside the current frame at flip submission in atomic commit tail, ie. one vblank earlier, and the fixed refresh intermediate frame mode must be also terminated one vblank earlier on pre-DCE12 display engines. To achieve proper termination on < DCE-12 shift the point when the switch-back from fixed vblank duration to variable vblank duration happens from the start of VBLANK (vblank irq, as done on DCE-12+) to back-porch or end of VBLANK (handled by vupdate irq handler). We must leave the switch-back code inside VBLANK irq for DCE12+, as before. Doing this, we get much better behaviour of BTR for up-sweeps, ie. going from short to long frame durations (~high to low fps) and for constant framerate flips, as tested on DCE-8 and DCE-11. Behaviour is still not quite as good as on DCN-1 though. On down-sweeps, going from long to short frame durations (low fps to high fps) < DCE-12 is a little bit improved, although by far not as much as for up-sweeps and constant fps. v2: Fix some wrong locking, as pointed out by Nicholas. v3: Simplify if-condition in vupdate-irq - nit by Nicholas. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Fix and simplify apply_below_the_range()Mario Kleiner2019-04-291-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The comparison of inserted_frame_duration_in_us against a duration calculated from max_refresh_in_uhz is both wrong in its math and not needed, as the min_duration_in_us value is already cached in in_out_vrr for reuse. No need to recalculate it wrongly at each invocation. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Expose DRM_FORMAT_RGB565 on overlay planesNicholas Kazlauskas2019-04-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RGB565 support isn't restricted to just the primary plane in DC, so also expose support for it on overlays. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: David Francis <david.francis@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Do VRR transition before enable_crc_interruptsNicholas Kazlauskas2019-04-291-11/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Why] Originally we did the amdgpu_dm_handle_vrr_transition call before interrupts were enabled. After the interrupt toggling logic was moved around for support enabling CRTCs with no primary planes active this was no longer being called in the case where there wasn't a modeset. This fixes failures in igt@kms_vrr@* with error "Timed out: Waiting for vblank event". [How] Shift them back into the loop that always ran before interrupts were enabled. Pull out the logic that updated VRR state into the same loop since there's no reason these need to be split. In the case where we're going from VRR off, no planes to VRR on, some active planes we'll still be covered for having the VRR vupdate handler enabled - vblank will be re-enabled at this point, it will see that VRR is active and set the vupdate interrupt on there. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Refactor dp vendor parsing logic to a functionJohn Barberiz2019-04-292-21/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Refactor dp vendor parsing int to a new function, and call it before get_active_converter_info(). Also, add a flag to skip parsing of Display ID 2.0. Some devices fail on readind DID2, but we shouldn't fail EDID read because of it. Add this flag to facilitate the logic. Signed-off-by: John Barberiz <John.Barberiz@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Add hubp_init entry to hubp vtableCharlene Liu2019-04-294-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Different HW will need to init HUBP differently. For now, add a vtable entry, and hook a NO-OP for DCN1. In addition, future HW will need to access the HUBPREQ_DEBUG register for hubp_init. Add it to the reg list. Signed-off-by: Charlene Liu <charlene.liu@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: remove deprecated pplib interfaceEric Yang2019-04-293-45/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Why] The new interface now replaces the old interface for all known configurations. Signed-off-by: Eric Yang <Eric.Yang2@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Add power down display on boot flagThomas Lim2019-04-293-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Why] Due to the generic introduction of seamless boot, the display is no longer blanked upon boot. However, this causes corruption on some systems that does not lock the memory in the non-secure boot case, resulting in brief corruption on boot due to garbage being written into the frame buffer. [How] Add a flag, read during DC init, to determine whether display should be blanked on boot. Default to true. Signed-off-by: Thomas Lim <Thomas.Lim@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Refactor watermark programmingYongqiang Sun2019-04-294-29/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Replace certain register writes with register sets that overwrites the the entire register, instead of only a field within the register. * Add program_watermarks() entry to hubbub vtable. Hook it up to existing functions that program watermarks. * Add additional watermark registers. Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Allow commits with no planes activeNicholas Kazlauskas2019-04-291-2/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Why] Many userspace applications (and IGT) seem to expect that most drivers can keep a CRTC active and enabled if there are no primary or overlay planes. DC is setup to handle this but only in the case where there are absolutely no planes on the CRTC - no primary, cursor, or overlay. [How] Add a check to reject commits that have cursor planes enabled and nothing else on CRTCs since we can't handle that. The new helper does_crtc_have_active_cursor is used for this. In atomic commit tail, we need to let DC know that there are zero planes enabled when doing stream updates to let it disable and blank pipes as appropriate. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Split enabling CRTC interrupts into two passesNicholas Kazlauskas2019-04-291-32/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Why] When disabling all the pipes for a CRTC the page-flip interrupt also gets disabled on Raven. We can't re-enable the page-flip interrupt unless we give DC at least one active DC plane. We currently enable interrupts after the call to dc_commit_state since there's currently no valid sequence that should disable all the planes or re-enable planes for a CRTC without first going through dc_commit_state. If we were to allow for a CRTC to be enabled with no primary plane this would not be the case - the call to dc_commit_updates_for_stream would enable the planes when going from zero to at least one active plane, but manage_dm_interrupts would have been called too early. This results in a page-flip timeout on any subsequent commits since we think the page-flip are now enabled when they're actually disabled. We need to enable interrupts after the call to dc_commit_updates_for_stream. [How] Split enabling interrupts into two passes. One pass before dc_commit_updates_for_stream and one after it. Shifting all the interrupts to be strictly below the call doesn't currently work even though it should in theory. We end up queuing off the vblank event to be handle by the flip handler before it's actually enabled in some cases, particularly: old_crtc_state->active = false -> new_crtc_state->active = true The framebuffer states haven't changed and we can technically still do a "pageflip" in this case and send back the event. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Fix CRC vblank refs when changing interruptsNicholas Kazlauskas2019-04-291-8/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Why] We only currently drop the vblank reference when the stream is being removed from the context. We should be dropping it whenever we disable interrupts and reaquiring it after we re-enable them. We also never get the extra reference correctly when re-enabling interrupts, since grabbing the reference has the following condition: if (!crtc_state->crc_enabled && enable) drm_crtc_vblank_get(crtc); This means that crc_enabled must be *false* in order to grab the extra reference. [How] Always drop the ref whenever we're disabling interrupts. Only disable CRC capture when the stream is being removed. Always grab the ref by setting dm_new_crtc_state->crc_enabled = false before the call to re-enable CRC capture. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Disable cursors before disabling planesNicholas Kazlauskas2019-04-291-3/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Why] We can't do cursor programming after the planes have been disabled since there won't be any pipes - leading to lock warnings and the wrong cursor state being left in the registers. When we re-enable the planes after the previous cursor state will also remain if we don't have a cursor plane. [How] If we're disabling the planes then do the cursor programming first. If we're not disabling the planes then do the cursor programming after. Introduce the amdgpu_dm_commit_cursors helper to avoid code duplication for both of these cases. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Refactor CRTC interrupt toggling logicNicholas Kazlauskas2019-04-292-21/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Why] The vblank and pageflip interrupts should only be enabled for a CRTC that's enabled and has active planes. The current logic takes care of this, but isn't setup to handle the case where the active plane count goes to zero but the stream remains enabled. We currently block this case since we don't allow commits that enable a CRTC with no active planes, but shouldn't be any reason we can't support this from a hardware perspective and many userspace applications expect to be able to do it (like IGT). [How] The count_crtc_active_planes function fills in the number of "active_planes" on the dm_crtc_state. This should be the same as DC's plane_count on the stream_status but easier to access since we don't need to lock the private atomic state with the DC context. Add the "interrupts_enabled" flag to the dm_crtc_state and set it based on whether the stream exists and if there are active planes on the stream. Update the disable and enable logic to make use of this new flag. There shouldn't be any functional change (yet) with this patch. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: fix incorrect null check on pointerColin Ian King2019-04-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently an allocation is being made but the allocation failure check is being performed on another pointer. Fix this by checking the correct pointer. Also use the normal kernel idiom for null pointer checks. Addresses-Coverity: ("Resource leak") Fixes: 43e3ac8389ef ("drm/amd/display: Add function to copy DC streams") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: add explicit handshake between x86 and DMCUJun Lei2019-04-233-2/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [why] When DMCU interrupts x86, it leads to undefined phy programming [how] expand dmcu interface to support new PHY lock and unlock commands if DMCU FW doesn't support these commands, they fail silently so its okay Signed-off-by: Jun Lei <Jun.Lei@amd.com> Reviewed-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Allow cursor position when plane_res.ipp is NULLEric Bernstein2019-04-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Why] Starting with DCN1, the input_pixel_processor (ipp) struct has been replaced by dpp struct (part of DAL3.1 SW architecture change). Need to update logic to handle cases where ipp is never allocated. [How] Only skip cursor position programming if both ipp and dpp resources are NULL. Signed-off-by: Eric Bernstein <eric.bernstein@amd.com> Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: 3.2.27Aric Cyr2019-04-231-1/+1
| | | | | | | | | | | | | | | | | | | | | Signed-off-by: Aric Cyr <aric.cyr@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Fix eDP Black screen after S4 resumeAnthony Koo2019-04-232-46/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Why] Power down of PHY on eDP requires us to call eDP power control to power on again [How] 1. In the case link rates don't match, disable PHY requires calling of eDP power control ON after 2. Link disable case limit to eDP path since this is not really applicable to DP since we do power down PHY as part of verify link cap 3. Move detection of eDP link settings to be done even for S4 resume cases where other dpcd cap read and edid read can be skipped Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Send DMCU messages only if FW loadedAnthony Koo2019-04-232-19/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Why] Some DMCU messages were being sent in cases where there was no DMCU FW at all, which resulted in some wait timeouts [How] Delay sending some of the DMCU messages after FW init is called and DMCU is running. Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Add function to copy DC streamsWenjing Liu2019-04-232-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We'll need the ability to copy a dc_stream_state for some features. Implement it here. Signed-off-by: Wenjing Liu <Wenjing.Liu@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Allow system to enter stutter on initAnthony Koo2019-04-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Why] Workaround was missing in one HW disable path, meaning when all pipes are power gated, stutter was not working [How] Add workaround for init_hw path for stutter workaround Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Use a reasonable timeout for framebuffer fence waitsAndrey Grodzovsky2019-04-231-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | Patch '5edb0c9b Fix deadlock with display during hanged ring recovery' was accidentaly removed during one of DALs code merges. Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: wait for fence without holding reservation lockChristian König2019-04-231-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't block others while waiting for the fences to finish, concurrent submission is perfectly valid in this case and holding the lock can prevent killed applications from terminating. Signed-off-by: Christian König <ckoenig.leichtzumerken@gmail.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Expose support for DRM_FORMAT_RGB565Nicholas Kazlauskas2019-04-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DC and DM already support DRM_FORMAT_RGB565, it's just missing from the list of valid formats. Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * | Merge branch 'drm-next-5.2' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2019-04-2419-325/+757
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-next - Add the amdgpu specific bits for timeline support - Add internal interfaces for xgmi pstate support - DC Z ordering fixes for planes - Add support for NV12 planes in DC - Add colorspace properties for planes in DC - eDP optimizations if the GOP driver already initialized eDP - DC bandwidth validation tracing support Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190419150034.3473-1-alexander.deucher@amd.com
| | * drm/amd/display: Add profiling tools for bandwidth validationJoshua Aberback2019-04-152-0/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Add fast_validate parameterJoshua Aberback2019-04-1511-13/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add a fast_validate parameter in dc_validate_global_state for future use 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: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Relax requirements for CRTCs to be enabledNicholas Kazlauskas2019-04-151-12/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Check scaling info when determing update typeNicholas Kazlauskas2019-04-151-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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 <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Don't warn when DC update type > DM guessNicholas Kazlauskas2019-04-151-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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 <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Use surface directly when checking update typeNicholas Kazlauskas2019-04-151-16/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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 <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Add basic downscale and upscale valdiationNicholas Kazlauskas2019-04-151-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: change name from dc_link_get_verified_link_cap to ↵Samson Tam2019-04-153-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dc_link_get_link_cap [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: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Rework DC plane filling and surface updatesNicholas Kazlauskas2019-04-151-202/+204
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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 <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Recalculate pitch when buffers changeNicholas Kazlauskas2019-04-151-39/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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 <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Maintain z-ordering when creating planesNicholas Kazlauskas2019-04-151-5/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Update plane scaling parameters for fast updatesNicholas Kazlauskas2019-04-151-24/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: 3.2.26Aric Cyr2019-04-151-1/+1
| | | | | | | | | | | | | | | | | | | | | Signed-off-by: Aric Cyr <aric.cyr@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Read eDP link settings on detectionAnthony Koo2019-04-151-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: define HUBP_MASK_SH_LIST_DCN for RavenYongqiang Sun2019-04-151-3/+6
| | | | | | | | | | | | | | | | | | | | | Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Handle get crtc position errorDavid Francis2019-04-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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: David Francis <David.Francis@amd.com> Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: expand plane caps to include fp16 and scaling capabilityJun Lei2019-04-158-13/+150
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Acked-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Add DRM color properties for primary planesNicholas Kazlauskas2019-04-151-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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 <nicholas.kazlauskas@amd.com> Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Expose support for NV12 on suitable planesNicholas Kazlauskas2019-04-151-31/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * drm/amd/display: Add switch for Fractional PWM on or offAnthony Koo2019-04-152-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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: Anthony Koo <Anthony.Koo@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * | BackMerge v5.1-rc5 into drm-nextDave Airlie2019-04-153-22/+12
| |\ \ | | |/ | |/| | | | | | | | | | Need rc5 for udl fix to add udl cleanups on top. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/amd/display: fix is odm head pipe logicDmytro Laktyushkin2019-04-101-8/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
OpenPOWER on IntegriCloud