- 06 Jun, 2017 25 commits
-
-
Hawking Zhang authored
vddc_dep_on_dal_pwrl is allocated and initialized in cz_hwmgr_backend_init Thus free the memory in cz_hwmgr_backend_fini Signed-off-by:
Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Hawking Zhang authored
vddc_dep_on_dal_pwrl and vq_budgeting_table are allocated and initialized in rv_hwmgr_backend_init. Thus free the memory in rv_hwmgr_backend_fini Signed-off-by:
-
Eric Huang authored
For overclocking sclk and mclk. Signed-off-by:
Eric Huang <JinHuiEric.Huang@amd.com> Reviewed-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 8 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:
-
