- 06 Jun, 2017 23 commits
-
-
Eric Huang authored
For overclocking sclk and mclk. Signed-off-by:
Eric Huang <JinHuiEric.Huang@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Rex Zhu authored
As the min clk may be large than boot level can support. in this case, just ignore the min clk. Signed-off-by:
Rex Zhu <Rex.Zhu@amd.com> Reviewed-by:
-
Huang Rui authored
Signed-off-by:
Huang Rui <ray.huang@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Something writes over the first 8 MB so reserve this on vega10 until we root cause it. Signed-off-by:
-
Huang Rui authored
User is able to follow the ip block number to write the ip_block_mask for selecting the one which user would like to enable. Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
This patch moves invalidation into gart enable function from hw_init. Because we would like align the sequence calling between init and resume. Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
- 01 Jun, 2017 7 commits
-
-
Leo Liu authored
We are using PSP to resume firmware after suspend, and it is resumed at where it got suspended, so we'd better save the the context. Signed-off-by:
Leo Liu <leo.liu@amd.com> Reviewed-by:
-
Leo Liu authored
To simplify vce bo create Signed-off-by:
-
Leo Liu authored
Signed-off-by:
-
Alex Xie authored
In review, Christian would like to keep the logic inside amdgpu_vm.c with a cost of slightly slower. The loop is still optimized out with this patch. v2: remove the if statement. Now it is not slower. Signed-off-by:
Alex Xie <AlexBin.Xie@amd.com> Reviewed-by:
Christian König <christian.koeng@amd.com> Signed-off-by:
-
Rex Zhu authored
Signed-off-by:
-
Rex Zhu authored
Signed-off-by:
-
Rex Zhu authored
Use the vbios to look up the default frequencies for socclk and dcefclk. Signed-off-by:
-
- 31 May, 2017 10 commits
-
-
Andres Rodriguez authored
Spreading the load across multiple SDMA engines can increase memory transfer performance. Signed-off-by:
Andres Rodriguez <andresx7@gmail.com> Reviewed-by:
Nicolai Hähnle <nicolai.haehnle@amd.com> Signed-off-by:
-
Andres Rodriguez authored
Depending on usage patterns, the current LRU policy may create a non-injective mapping between userspace ring ids and kernel rings. This behaviour is undesired as apps that attempt to fill all HW blocks would be unable to reach some of them. This change forces the LRU policy to create bijective mappings only. v2: compress ring_blacklist v3: simplify amdgpu_ring_is_blacklisted() logic Signed-off-by:
-
Andres Rodriguez authored
Use an LRU policy to map usermode rings to HW compute queues. Most compute clients use one queue, and usually the first queue available. This results in poor pipe/queue work distribution when multiple compute apps are running. In most cases pipe 0 queue 0 is the only queue that gets used. In order to better distribute work across multiple HW queues, we adopt a policy to map the usermode ring ids to the LRU HW queue. This fixes a large majority of multi-app compute workloads sharing the same HW queue, even though 7 other queues are available. v2: use ring->funcs->type instead of ring->hw_ip v3: remove amdgpu_queue_mapper_funcs v4: change ring_lru_list_lock to spinlock, grab only once in lru_get() Signed-off-by:
-
Andres Rodriguez authored
Add amdgpu_queue_mgr, a mechanism that allows disjointing usermode's ring ids from the kernel's ring ids. The queue manager maintains a per-file descriptor map of user ring ids to amdgpu_ring pointers. Once a map is created it is permanent (this is required to maintain FIFO execution guarantees for a context's ring). Different queue map policies can be configured for each HW IP. Currently all HW IPs use the identity mapper, i.e. kernel ring id is equal to the user ring id. The purpose of this mechanism is to distribute the load across multiple queues more effectively for HW IPs that support multiple rings. Userspace clients are unable to check whether a specific resource is in use by a different client. Therefore, it is up to the kernel driver to make the optimal choice. v2: remove amdgpu_queue_mapper_funcs v3: made amdgpu_queue_mgr per context instead of per-fd v4: add context_put on error paths v5: rebase and include new IPs UVD_ENC & VCN_* v6: drop unused amdgpu_ring_is_valid_index (Alex) Reviewed-by:
-
Andres Rodriguez authored
Tonga based asics may experience hangs when an HQD's EOP parameters are modified. Workaround this HW issue by avoiding writes to these registers for tonga asics. Based on the following ROCm commit: 2a0fb8 - drm/amdgpu: Synchronize KFD HQD load protocol with CP scheduler From the ROCm git repository: https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver.git CC: Jay Cornwall <Jay.Cornwall@amd.com> Suggested-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
-
Andres Rodriguez authored
The MQD structure matches the reg layout. Take advantage of this to simplify HQD programming. Note that the ACTIVE field still needs to be programmed last. Suggested-by:
-
Andres Rodriguez authored
Instead of taking the first pipe and giving the rest to kfd, take the first 2 queues of each pipe. Effectively, amdgpu and amdkfd own the same number of queues. But because the queues are spread over multiple pipes the hardware will be able to better handle concurrent compute workloads. amdgpu goes from 1 pipe to 4 pipes, i.e. from 1 compute threads to 4 amdkfd goes from 3 pipe to 4 pipes, i.e. from 3 compute threads to 4 v2: fix policy comment Reviewed-by:
Edward O'Callaghan <funfunctor@folklore1984.net> Reviewed-by:
-
Andres Rodriguez authored
Instead of picking an arbitrary queue for KIQ, search for one according to policy. The queue must be unused. Also report the KIQ as an unavailable resource to KFD. In testing I ran into KCQ initialization issues when using pipes 2/3 of MEC2 for the KIQ. Therefore the policy disallows grabbing one of these. v2: fix (ring.me + 1) to (ring.me -1) in amdgpu_amdkfd_device_init Reviewed-by:
-
Andres Rodriguez authored
The assumption that we are only using the first pipe no longer holds. Instead, calculate the queue_mask from the queue_bitmap. Acked-by:
-
Andres Rodriguez authored
Pipes provide better concurrency than queues, therefore we want to make sure that apps use queues from different pipes whenever possible. Optimize for the trivial case where an app will consume rings in order, therefore we don't want adjacent rings to belong to the same pipe. Reviewed-by:
-
