- 30 Mar, 2017 40 commits
-
-
Geert Uytterhoeven authored
Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: dri-devel@lists.freedesktop.orgamd-gfx@lists.freedesktop.org Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Lyude authored
Aux transfers always fail with non-zero status flags when there's nothing connected on the port, so we don't usually need to see all of the debugging information from it. Also, we try reprobing a -lot-, so without ratelimiting most of the kernel log is filled up with messages from radeon_dp_aux_transfer_native. Signed-off-by:
Lyude <lyude@redhat.com> Signed-off-by:
-
Alex Deucher authored
This enables the LEDs that light up based on DPM states on some Fiji boards. bug: https://bugs.freedesktop.org/show_bug.cgi?id=97590Reviewed-by:
Huang Rui <ray.huang@amd.com> Signed-off-by:
-
Junwei Zhang authored
Signed-off-by:
Junwei Zhang <Jerry.Zhang@amd.com> Reviewed-by:
-
Trigger Huang authored
In some cases, manually insmod/rmmod amdgpu is necessary. When unloading amdgpu, the KIQ IRQ enable/disable function will case system hang. The root cause is, in the sequence of function amdgpu_fini, the sw_fini of IP block AMD_IP_BLOCK_TYPE_GFX will be invoked earlier than that of AMD_IP_BLOCK_TYPE_IH. So continue to use the variable freed by AMD_IP_BLOCK_TYPE_GFX will cause system hang. Signed-off-by:
Trigger Huang <trigger.huang@amd.com> Reviewed-by: Xiangliang Yu < Xiangliang.Yu@amd.com> Reviewed-by:
Monk Liu <monk.liu@amd.com> Acked-by:
-
Alex Deucher authored
v2: agd: bump version Reviewed-by:
-
Junwei Zhang authored
v2: move the config struct to drm_amdgpu_info_device v3: move the config feature to amdgpu_gca_config Signed-off-by:
-
Xiangliang Yu authored
Need to free mqd backup when destroying ring. Signed-off-by:
Xiangliang Yu <Xiangliang.Yu@amd.com> Reviewed-by:
-
Xiangliang Yu authored
When send messages to hypervior, the messages format should be is idh_request, not idh_event. Signed-off-by:
-
Xiangliang Yu authored
vi_mqd is only used by VI family but mqd_ptr and mqd_backup is common for all ASIC, so change the pointer to void. Signed-off-by:
-
Monk Liu authored
v2: use in_rest to fix compute ring test failure issue which occured after FLR/gpu_reset. we need backup a clean status of MQD which was created in drv load stage, and use it in resume stage, otherwise KCQ and KIQ all may faild in ring/ib test. Signed-off-by:
-
Monk Liu authored
In resume routine, we need clr RB prior to the ring test of engine, otherwise some engine hang duplicated during GPU reset. Signed-off-by:
-
Monk Liu authored
we can use it clear ring buffer instead of fullfill 0, which is not correct for engine Signed-off-by:
-
Monk Liu authored
this is required for restoring the mqds after GPU reset. Signed-off-by:
-
Monk Liu authored
use it to seperate driver load and gpu reset/resume because gfx IP need different approach for different hw_init trigger source Signed-off-by:
-
Monk Liu authored
this flag will get cleared by request gpu access Signed-off-by:
-
Monk Liu authored
no need to use a delay work since we don't know how much time hypervisor takes on FLR, so just polling and waiting in a work. Signed-off-by:
-
Monk Liu authored
Use no kiq version reg access due to: 1) better performance 2) INTR context consideration (some routine in mailbox is in INTR context e.g.xgpu_vi_mailbox_rcv_irq) Signed-off-by:
-
Ken Xue authored
Signed-off-by:
Ken Xue <Ken.Xue@amd.com> Acked-by:
-
Monk Liu authored
some registers are PF & VF copy, and we can safely use mmio method to access them. and sometime we are forbid to use kiq to access registers for example in INTR context. we need a MACRO that always disable KIQ for regs accessing Signed-off-by:
-
Monk Liu authored
Change-Id: Ica8f86577a50d817119de4b4fb95068dc72652a9 Signed-off-by:
-
Nicolai Hähnle authored
By using ttm_bo_init_reserved instead of the manual initialization of the reservation object, the reservation lock will be properly unlocked and destroyed when the TTM BO initialization fails. Actual deadlocks caused by the missing unlock should have been fixed by "drm/ttm: never add BO that failed to validate to the LRU list", superseding the flawed fix in commit 38fc4856 ("drm/amdgpu: fix a potential deadlock in amdgpu_bo_create_restricted()"). This change fixes remaining recursive locking errors that can be seen with lock debugging enabled, and avoids the error of freeing a locked mutex. As an additional minor bonus, buffers created with resv == NULL and the AMDGPU_GEM_CREATE_VRAM_CLEARED flag are now only added to the global LRU list after the fill commands have been issued. v2: use amdgpu_bo_unreserve instead of ttm_bo_unreserve Fixes: 12a852219583 ("drm/amdgpu: improve AMDGPU_GEM_CREATE_VRAM_CLEARED handling (v2)") Signed-off-by:
Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by:
-
Nicolai Hähnle authored
This variant of ttm_bo_init returns the validated buffer object with the reservation lock held when resv == NULL. This is convenient for callers that want to use the BO immediately, e.g. for initializing its contents. Signed-off-by:
-
Nicolai Hähnle authored
As the comment says: callers of ttm_bo_init cannot rely on having the only reference to the BO when the function returns successfully. Signed-off-by:
-
Nicolai Hähnle authored
This reverts commit 38fc4856, which introduces a use-after-free. The underlying bug should be properly fixed with "drm/ttm: never add BO that failed to validate to the LRU list". Cc: zhoucm1 <david1.zhou@amd.com> Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by:
-
Nicolai Hähnle authored
Fixes a potential race condition in amdgpu that looks as follows: Task 1: attempt ttm_bo_init, but ttm_bo_validate fails Task 1: add BO to global list anyway Task 2: grabs hold of the BO, waits on its reservation lock Task 1: releases its reference of the BO; never gives up the reservation lock The patch "drm/amdgpu: fix a potential deadlock in amdgpu_bo_create_restricted()" attempts to fix that by releasing the reservation lock in amdgpu code; unfortunately, it introduces a use-after-free when this race _doesn't_ happen. This patch should fix the race properly by never adding the BO to the global list in the first place. Cc: zhoucm1 <david1.zhou@amd.com> Signed-off-by: -
Alex Deucher authored
This includes shader/memory clocks, temperature, GPU load, etc. v2: - add sub-queries for AMDPGU_INFO_GPU_SENSOR_* - do not break the ABI v3: - return -ENOENT when amdgpu_dpm == 0 - expose more sensor queries v4: - s/GPU_POWER/GPU_AVG_POWER/ - improve VDDNB/VDDGFX query description - fix amdgpu_dpm check v5: - agd: fix warning v6: - agd: bump version Signed-off-by: -
Samuel Pitoiset authored
read_sensor() has been recently implemented for dpm based boards which means amdgpu_sensors can now be exposed. v2: - make sure read_sensor is not NULL on dpm chips - keep sanity check for powerplay chips v3: - make sure amdgpu_dpm != 0 Cc: Tom St Denis <tom.stdenis@amd.com> Reviewed-by:Tom St Denis <tom.stdenis@amd.com> Signed-off-by:
-
Samuel Pitoiset authored
Add the GPU temperature, the shader clock and eventually the memory clock (as well as the GPU load on CI). The main goal is to expose this info to the userspace like Radeon. v2: - add AMDGPU_PP_SENSOR_GPU_LOAD on CI - update the commit description Signed-off-by: -
Marek Olšák authored
Set alignment mode to unaligned on CIK to align with amdgpu. This is needed for unaligned loads to work properly in mesa. The current setting requires dword alignment. Signed-off-by:
Marek Olšák <marek.olsak@amd.com> Reviewed-by:
-
Christian König authored
v2: new approach fixing this by registering a fence callback for all users of the VM on teardown v3: agd: rebase Signed-off-by: -
Christian König authored
Don't assume kmalloc will always succeed. v2: agd: rebase Signed-off-by:
-
Christian König authored
When two VMs stop using PRT support at the same time we might not disable it in the right order otherwise. v2: agd: rebase Signed-off-by:
-
Alex Xie authored
Reviewed-by:
Alex Xie <AlexBin.Xie@amd.com> Signed-off-by:
-
Christian König authored
Those should be 64bit, even on a 32bit system. Signed-off-by:
-
Tom St Denis authored
This update allows sensors to return more than 1 value and indicates to the caller how many bytes are written. The debugfs interface has been updated to handle reading all of the values. Simply seek to the enum value (multiplied by 4) and then read as many bytes as the sensor provides. (v2): Don't set size to 4 before reading GPU_POWER (v3): agd: rebase Signed-off-by:
-
Christian König authored
Enable/disable the handling globally for now and print a warning when we enable it for the first time. v2: set correct register Signed-off-by:
-
Christian König authored
Enable/disable the handling globally for now and print a warning when we enable it for the first time. v2: set correct register Signed-off-by:
-
Christian König authored
Enable/disable the handling globally for now and print a warning when we enable it for the first time. v2: write to the correct register, adjust bits to that hw generation v3: fix compilation, add the missing register bit definitions Signed-off-by:
-
Junwei Zhang authored
Till GFX8 we can only enable PRT support globally, but with the next hardware generation we can do this on a per page basis. Keep the interface consistent by adding PRT mappings and enable support globally on current hardware when the first mapping is made. v2: disable PRT support delayed and on all error paths v3: PRT and other permissions are mutal exclusive, PRT mappings don't need a BO. v4: update PRT mappings durign CS as well, make va_flags 64bit Signed-off-by:
-
