- 21 Feb, 2019 1 commit
-
-
Alex Deucher authored
Trivial. Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
- 19 Feb, 2019 18 commits
-
-
Christian König authored
We still need to set bulk_movable to false when new BOs are added or removed. v2: also set it to false on removal Signed-off-by:
Christian König <christian.koenig@amd.com> Tested-by:
StDenis, Tom <Tom.StDenis@amd.com> Tested-by:
Przemek Socha <soprwa@gmail.com> Reviewed-by:
Zhou, David(ChunMing) <David1.Zhou@amd.com> Signed-off-by:
-
Christian König authored
We only need to set this to false now when BOs are removed from the LRU. Signed-off-by:
-
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; size = sizeof(struct foo) + count * sizeof(struct boo); instance = kzalloc(size, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL); Notice that, in this case, variable table_size is not necessary, hence it is removed. This code was detected with the help of Coccinelle. Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; size = sizeof(struct foo) + count * sizeof(struct boo); instance = kzalloc(size, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL); Notice that, in this case, variable table_size is not necessary, hence it is removed. This code was detected with the help of Coccinelle. Signed-off-by: -
Yongqiang Sun authored
[Why] Current periodic interrupt start point calc in optc is not clear. [How] 1. DM convert delta time to lines number and dc will calculate the start position as per lines number and interrupt type. 2. hwss calculates the start point as per line offset. 3. optc programs vertical interrupts register as per start point and interrupt source. 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:
-
Nicholas Kazlauskas authored
[Why] The stream->mode_changed flag can persist in the following sequence of atomic commits: Commit 1: Enable CRTC0 (mode_changed = true), Enable CRTC1 (mode_changed = true) Commit 2: Disable CRTC1 (mode_changed = false) In this sequence we want to keep the exiting CRTC0 but it's not in the atomic state for the commit since it hasn't been modified. In this case the stream->mode_changed flag persists as true and we don't re-program the planes for the existing stream. [How] The flag needs to be cleared and it makes the most sense to do it within DC after the state has been committed. Nothing following dc_commit_state should think that the stream's mode has changed. Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by:
-
Nicholas Kazlauskas authored
[Why] Cursor updates used to happen after vblank/flip/stream updates before the stream update refactor. They now happen before stream updates which means that they're not going to be synced with fb changes and that they're going to programmed for pipes that we're disabling within the same commit. [How] Move them after stream updates. Signed-off-by:
David Francis <David.Francis@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] Whenever a stream or plane is added or removed from the context the pointer will change from old to new. We set lock and validation needed in these cases. But not all of these cases match update_type from dm_determine_update_type_for_commit - an example being overlay plane updates. There are warnings for a few of these cases that should be fixed. [How] We can closer align to DC (and lock_and_validation_needed) by comparing stream and plane pointers. Since the old stream/old plane state is never freed until sometime after the commit tail work finishes we are guaranteed to never get back the same block of memory when we remove and create a stream or plane state in the same commit. Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] This format isn't supported in DC and some IGT tests fail since we expose support for it. [How] Remove it. Signed-off-by:
Harry Wentland <Harry.Wentland@amd.com> Reviewed-by:
-
Nicholas Kazlauskas authored
[Why] If a commit updates an overlay plane via the legacy plane IOCTL then the only plane in the state will be the overlay plane. Overlay planes need to be added first to the DC context, but in the scenario above the plane will be added last. This will result in wrong z-order during rendering. [How] If any non-cursor plane has been updated then the rest of the non-cursor planes should be added to the CRTC state. The cursor plane doesn't need to be included for stream updates and locking it will cause performance issues. It should be ignored. DC requires that the surface count passed during stream updates be the number of surfaces currently on the stream to enable fast updates. This previously wasn't the case without this patch, so this also allows this optimization to occur. Signed-off-by:
-
Josip Pavic authored
[Why] Previously, a change removed code that would send a pipe set command to dmcu each time the backlight was set, as it was thought to be superfluous. However, it is possible for the backlight to be set before a valid pipe has been set, which causes DMCU to hang after a DPMS restore on some systems. [How] Send a pipe set command to DMCU prior to setting the backlight. Signed-off-by:
Josip Pavic <Josip.Pavic@amd.com> Reviewed-by:
Anthony Koo <Anthony.Koo@amd.com> Acked-by:
-
Gary Kattan authored
[Why] Certain tests fail after a fresh reboot. This is caused by writing to registers prior to ungating the stream we're trying to program. [How] Make sure the stream is ungated before writing to its registers. This also enables power-gating plane resources before init_hw initializes them. Additionally, this does some refactoring to move gating/ungating from enable/disable_plane functions to where stream resources are enabled/disabled. Signed-off-by:
Gary Kattan <gary.kattan@amd.com> Reviewed-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by:
-
Anthony Koo authored
[Why] We are currently losing precision when we convert from 16 bit --> 8 bit --> 16 bit. [How] We shouldn't down convert unnecessarily and lose precision. Keep values at 16 bit and use directly. Signed-off-by:
Aric Cyr <Aric.Cyr@amd.com> Acked-by:
-
Anthony Koo authored
[Why] We want boot to desktop to be seamless [How] During init pipes, avoid touching the pipes where GOP has already enabled the HW to the state we want. Signed-off-by:
-
Josip Pavic authored
[Why] When stream is blanked, pipe set command is sent to dmcu to notify it that the abm pipe is disabled. When stream is unblanked, no notification is made to dmcu that the abm pipe has been enabled, resulting in abm not being enabled in the firmware. [How] When stream is unblanked, send a pipe set command to dmcu. Signed-off-by:
-
Yong Zhao authored
The original change caused a regression, so revert it until the new fix is ready. BUG: https://bugs.freedesktop.org/show_bug.cgi?id=109650 This reverts commit 764c85fef41722db0f21558c6c2fb38bee172d19. Signed-off-by:
Yong Zhao <Yong.Zhao@amd.com> Acked-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
Yong Zhao authored
This reverts commit 9006c6bd9059cb9807fa863bafc1d776222cb61b. Signed-off-by:
-
Gustavo A. R. Silva authored
Add missing break statement in order to prevent the code from falling through to case CB_TARGET_MASK. This bug was found thanks to the ongoing efforts to enable -Wimplicit-fallthrough. Fixes: dd220a00 ("drm/radeon/kms: add support for streamout v7") Cc: stable@vger.kernel.org Signed-off-by:
-
- 18 Feb, 2019 10 commits
-
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Warning level 3 was used: -Wimplicit-fallthrough=3 Notice that, in this particular case, the code comment is modified in accordance with what GCC is expecting to find. This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Signed-off-by:
-
Yong Zhao authored
We can directly calculate sdma doorbell indexes in the process doorbell pages through the doorbell_index structure in amdgpu_device, so no need to cache them in kgd2kfd_shared_resources any more. This alleviates the adaptation needs when new SDMA configurations are introduced. Signed-off-by:
-
Yong Zhao authored
Reserved doorbells for SDMA IH and VCN were not properly masked out when allocating doorbells for CP user queues. This patch fixed that. Signed-off-by:
-
Yong Zhao authored
They will be used to inform KFD the doorbell range not usable for CP. Signed-off-by:
-
Yong Zhao authored
The similar definitions should be consecutive. Signed-off-by:
-
- 15 Feb, 2019 5 commits
-
-
Alex Deucher authored
Carried over from radeon, but no longer used. Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Acked-by:
-
Bas Nieuwenhuizen authored
Given a master fd we can then override the priority of the context in another fd. Using these overrides was recommended by Christian instead of trying to submit from a master fd, and I am adding a way to override a single context instead of the entire process so we can only upgrade a single Vulkan queue and not effectively the entire process. Reused the flags field as it was checked to be 0 anyways, so nothing used it. This is source-incompatible (due to the name change), but ABI compatible. Signed-off-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by:
-
Bas Nieuwenhuizen authored
Otherwise we interpret the file private data as drm & amdgpu data while it might not be, possibly allowing one to get memory corruption. Signed-off-by:
-
Bas Nieuwenhuizen authored
I don't see another way to figure out if a ring is initialized if the hardware block might not be initialized. Entities have been fixed up to handle num_rqs = 0. Signed-off-by:
-
Bas Nieuwenhuizen authored
Some blocks in amdgpu can have 0 rqs. Job creation already fails with -ENOENT when entity->rq is NULL, so jobs cannot be pushed. Without a rq there is no scheduler to pop jobs, and rq selection already does the right thing with a list of length 0. So the operations we need to fix are: - Creation, do not set rq to rq_list[0] if the list can have length 0. - Do not flush any jobs when there is no rq. - On entity destruction handle the rq = NULL case. - on set_priority, do not try to change the rq if it is NULL. Signed-off-by:
-
- 13 Feb, 2019 6 commits
-
-
Alex Deucher authored
This prevents us from accessing extended registers in tools like umr. The register access functions already check if the offset is beyond the BAR size and use the indirect accessors with locking so this is safe. Reviewed-by:
-
Colin Ian King authored
There are several statements that are incorrectly indented. Fix these. Reviewed-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Alex Deucher authored
Missing firmware declaration caused firmware requirement to not be noted by the module and may cause firmware to not be available in initrd. Fixes: bc4b539e "drm/amdgpu: remove old CI DPM implementation" Reviewed-by:
James Zhu <James.Zhu@amd.com> Tested-by:
-
Andrey Grodzovsky authored
When ring hang happens amdgpu_dm_commit_planes during flip is holding the BO reserved and then stack waiting for fences to signal in reservation_object_wait_timeout_rcu (which won't signal because there was a hnag). Then when we try to shutdown display block during reset recovery from drm_atomic_helper_suspend we also try to reserve the BO from dm_plane_helper_cleanup_fb ending in deadlock. Also remove useless WARN_ON Signed-off-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by:
-
Yong Zhao authored
They are no longer used, so delete them to avoid confusion. Signed-off-by:
-
Yong Zhao authored
CP_RB_DOORBELL_RANGE_LOWER/UPPER and CP_MEC_DOORBELL_RANGE_LOWER/UPPER are used for waking up an idle scheduler and for power gating support. Usually the first few doorbells in pci doorbell bar are used for RB and all leftover for MEC. This patch fixes the incorrect settings. Theoretically, gfx ring doorbells should come before all MEC doorbells to be consistent with the design. However, since the doorbell allocations are agreed by all and we are not free to change them, also considering the kernel MEC ring doorbells which are before gfx ring doorbells are not used often, we compromise by leaving the doorbell allocations unchanged. Signed-off-by:
-
