- 13 Jul, 2021 4 commits
-
-
Eric Huang authored
This reverts commit 51627f03. Reason for revert: it causes regression on Aldebaran. Signed-off-by:
Eric Huang <jinhuieric.huang@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Chengming Gui authored
Correct BACO state setting for Beige_Goby Signed-off-by:
Chengming Gui <Jack.Gui@amd.com> Reviewed-by:
Jiansong Chen <Jiansong.Chen@amd.com> Reviewed-by:
Guchun Chen <guchun.chen@amd.com> Signed-off-by:
-
Emily.Deng authored
After FLR, the msix will be cleared, so need to re-enable it. Signed-off-by:
Peng Ju Zhou <PengJu.Zhou@amd.com> Signed-off-by:
Emily.Deng <Emily.Deng@amd.com> Reviewed-by:
Lijo Lazar <lijo.lazar@amd.com> Signed-off-by:
-
Felix Kuehling authored
The thunk needs to mmap all BOs for CPU access to allow the debugger to access them. Invisible ones are mapped with PROT_NONE. Fixes: 71df0368 ("drm/amdgpu: Implement mmap as GEM object function") Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
- 08 Jul, 2021 33 commits
-
-
Zhan Liu authored
[Why] The original logic is to update eDP's backlight level on every amdgpu dm atomic commit, which causes excessive DMUB write. As a result, when playing game or moving window around, DMUB timeout and system lagging are observed. [How] We only need to update eDP's backlight level when current level doesn't match requested level. Signed-off-by:
Zhan Liu <zhan.liu@amd.com> Reviewed-by:
-
John Clements authored
support umc ras function initialization for aldebaran v2: squash in compile fix Signed-off-by:
John Clements <john.clements@amd.com> Signed-off-by:
Stanley.Yang <Stanley.Yang@amd.com> Reviewed-by:
-
Philip Yang authored
prange is NULL if vm fault retry on invalid address, for this case, can not use prange to get pdd, use adev to get gpuidx and then get pdd instead, then increase pdd vm fault counter. Signed-off-by:
Philip Yang <Philip.Yang@amd.com> Reviewed-by:
-
Emily Deng authored
The irq number should be decided by num_crtc, and the num_crtc could change by parameter. Signed-off-by:
-
Xiaomeng Hou authored
Update the register header file name. Signed-off-by:
Xiaomeng Hou <Xiaomeng.Hou@amd.com> Reviewed-by:
Aaron Liu <aaron.liu@amd.com> Signed-off-by:
-
Xiaomeng Hou authored
Since there's nothing special in smu implementation for yellow carp, it's better to reuse the common smu_v13_0 interfaces and drop the specific smu_v13_0_1.c|h files. v2: remove the duplicate register offset and shift mask header files as well. Signed-off-by:
Kevin Wang <kevin1.wang@amd.com> Signed-off-by:
-
Evan Quan authored
To suppress the annoying warning about version mismatch. Signed-off-by:
Evan Quan <evan.quan@amd.com> Reviewed-by:
-
Evan Quan authored
Due to the structure layout change: "uint32_t ThrottlerStatus" -> " uint8_t ThrottlingPercentage[THROTTLER_COUNT]". Signed-off-by:
-
Evan Quan authored
Due to the structure layout change: "uint32_t ThrottlerStatus" -> " uint8_t ThrottlingPercentage[THROTTLER_COUNT]". Signed-off-by:
-
Dan Carpenter authored
If copy_to_user() fails then this should return -EFAULT instead of -EINVAL. Fixes: c65b0805 ("drm/amdgpu: RAS EEPROM table is now in debugfs") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Luben Tuikov <luben.tuikov@amd.com> Signed-off-by:
-
Dan Carpenter authored
This error path needs to unlock before returning. While we're at it, the correct error code from copy_to_user() failure is -EFAULT, not -EINVAL. Fixes: c65b0805 ("drm/amdgpu: RAS EEPROM table is now in debugfs") Signed-off-by:
-
Dan Carpenter authored
The i2c_transfer() function returns negatives or else the number of messages transferred. This code does not work because ARRAY_SIZE() is type size_t and so that means negative values of "r" are type promoted to high positive values which are greater than the ARRAY_SIZE(). Fix this by changing the < to != which works regardless of type promotion. Fixes: 746b5847 ("drm/amdgpu: Fixes to the AMDGPU EEPROM driver") Signed-off-by:
-
Dan Carpenter authored
If amdgpu_eeprom_read() returns a negative error code then the error handling checks: if (res < buf_size) { The problem is that "buf_size" is a u32 so negative values are type promoted to a high positive values and the condition is false. Fix this by changing the type of "buf_size" to int. Fixes: 63d4c081 ("drm/amdgpu: Optimize EEPROM RAS table I/O") Signed-off-by: -
Aric Cyr authored
[Why] EDID CTS requires at least 2k (16 blocks) to be readable. [How] Increase EDID buffer size to 2k Signed-off-by:
Aric Cyr <aric.cyr@amd.com> Reviewed-by:
Anthony Koo <Anthony.Koo@amd.com> Acked-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by:
-
Aric Cyr authored
[Why] When requesting clocks from SMU which takes MHz inputs, DC will round down KHz when converting to MHz, thus potentially requesting too low a clock value. [How] Round up (ceil) when converting KHz to MHz for clock requests to SMU. Signed-off-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by:
-
Aric Cyr authored
DC version 3.2.142 brings improvements in multiple areas. In summary, we highlight: - Freesync improvements - Remove unnecessary assert - Firmware release 0.0.72 - Improve the EDID manipulation and DML calculations Signed-off-by:
-
Anthony Koo authored
- Updated SCR definition for FW boot options for Separate DCN init for DMUB FW loaded in VBL Signed-off-by:
-
Alvin Lee authored
Type adjustments and formatting fixes. Signed-off-by:
Alvin Lee <Alvin.Lee2@amd.com> Reviewed-by:
-
Dmytro Laktyushkin authored
Signed-off-by:
Wenjing Liu <Wenjing.Liu@amd.com> Acked-by:
-
Wesley Chalmers authored
This reverts commit 2b7605d7 Some displays are not lighting up when put in LTTPR Transparent Mode Signed-off-by:
Wesley Chalmers <Wesley.Chalmers@amd.com> Reviewed-by:
Jun Lei <Jun.Lei@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] We're only treating TMDS as a valid target for infoframe updates which results in PSR being unable to transition from state 4 to state 5. [How] Also allow infoframe updates for DCN3.1 - following how we handle this path for earlier ASIC as well. Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by:
Eric Yang <eric.yang2@amd.com> Acked-by:
-
Stylon Wang authored
[Why] Changes in DM needed to support Freesync HDMI on DMUB. [How] Change implementation to parse CEA blocks in case of DMUB-enabled ASICs. Signed-off-by:
Stylon Wang <stylon.wang@amd.com> Reviewed-by:
-
Wang authored
Added NULL checks before two problematic statements Signed-off-by:
Wang <anguwang@amd.com> Reviewed-by:
Martin Leung <Martin.Leung@amd.com> Acked-by:
-
Chun-Liang Chang authored
[Why] dmub would notify x86 response time violation by GPINT_DATAOUT [How] 1. Use GPINT_DATAOUT to trigger x86 interrupt 2. Register GPINT_DATAOUT interrupt handler. 3. Trigger ACR while GPINT_DATAOUT occurred. Signed-off-by:
Chun-Liang Chang <Chun-Liang.Chang@amd.com> Reviewed-by:
-
Wenjing Liu authored
There is a difference between our default behavior and override behavior. For default behavior we need to decide link training settings within specs' limitation and mandates. For override behavior we do not need to follow all these requirements. We are isolating override decision to its own function to maintain the integrity of our specs compliant default behavior. Signed-off-by:
George Shen <George.Shen@amd.com> Acked-by:
-
Luben Tuikov authored
In amdgpu_ras_query_error_count() return an error if the device doesn't support RAS. This prevents that function from having to always set the values of the integer pointers (if set), and thus prevents function side effects--always to have to set values of integers if integer pointers set, regardless of whether RAS is supported or not--with this change this side effect is mitigated. Also, if no pointers are set, don't count, since we've no way of reporting the counts. Also, give this function a kernel-doc. Cc: Alexander Deucher <Alexander.Deucher@amd.com> Cc: John Clements <john.clements@amd.com> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Reported-by:
Tom Rix <trix@redhat.com> Fixes: a46751fb ("drm/amdgpu: Fix RAS function interface") Signed-off-by:
-
Jingwen Chen authored
[Why] If flr_work takes read_lock, then other threads who takes read_lock can access hardware when host is doing vf flr. [How] flr_work should take write_lock to avoid this case. Signed-off-by:
Jingwen Chen <Jingwen.Chen2@amd.com> Reviewed-by:
Monk Liu <monk.liu@amd.com> Signed-off-by:
-
Luben Tuikov authored
The I2C IP doesn't support writes or reads of 0 bytes. In order for a START/STOP transaction to take place on the bus, the data written/read has to be at least one byte. That is, you cannot generate a write with 0 bytes, just to get the ACK from a device, just so you can probe that device if it is on the bus and so to discover all devices on the bus--you'll have to read at least one byte. Writes of 0 bytes generate no START/STOP on this I2C IP--the bus is not engaged at all. Set the I2C_AQ_NO_ZERO_LEN to the existing I2C quirk tables for Aldebaran, Arcturus, Navi10 and Sienna Cichlid, and add a quirk table to the I2C driver which drives the bus when the SMU doesn't--for instance on Vega20. Cc: Alexander Deucher <Alexander.Deucher@amd.com> Cc: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> Cc: Lijo Lazar <Lijo.Lazar@amd.com> Cc: John Clements <john.clements@amd.com> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
Luben Tuikov authored
Add I2C quirk table to Aldebaran. Cc: Alexander Deucher <Alexander.Deucher@amd.com> Cc: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> Cc: Lijo Lazar <Lijo.Lazar@amd.com> Cc: John Clements <john.clements@amd.com> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
YuBiao Wang authored
[Why] GPU timing counters are read via KIQ under sriov, which will introduce a delay. [How] It could be directly read by MMIO. v2: Add additional check to prevent carryover issue. v3: Only check for carryover for once to prevent performance issue. v4: Add comments of the rough frequency where carryover happens. v5: Remove mutex and gfxoff ctrl unused with current timing registers. Signed-off-by:
YuBiao Wang <YuBiao.Wang@amd.com> Acked-by:
Horace Chen <horace.chen@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.co> Reviewed-by:
-
Eric Huang authored
It is based on reverting two patches back. drm/amdkfd: Make TLB flush conditional on mapping drm/amdgpu: Add table_freed parameter to amdgpu_vm_bo_update Signed-off-by:
-
Nirmoy Das authored
Use new helper function amdgpu_vm_set_pasid() to assign vm pasid value. This also ensures that we don't free a pasid from vm code as pasids are allocated somewhere else. Signed-off-by:
Nirmoy Das <nirmoy.das@amd.com> Acked-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Nirmoy Das authored
Replace idr with xarray as we actually need hash functionality. Cleanup code related to vm pasid by adding helper function. Signed-off-by:
-
- 01 Jul, 2021 3 commits
-
-
Jiri Kosina authored
In case when psp_init_asd_microcode() fails to load ASD microcode file, psp_v12_0_init_microcode() tries to print the firmware filename that failed to load before bailing out. This is wrong because: - the firmware filename it would want it print is an incorrect one as psp_init_asd_microcode() and psp_v12_0_init_microcode() are loading different filenames - it tries to print fw_name, but that's not yet been initialized by that time, so it prints random stack contents, e.g. amdgpu 0000:04:00.0: Direct firmware load for amdgpu/renoir_asd.bin failed with error -2 amdgpu 0000:04:00.0: amdgpu: fail to initialize asd microcode amdgpu 0000:04:00.0: amdgpu: psp v12.0: Failed to load firmware "\xfeTO\x8e\xff\xff" Fix that by bailing out immediately, instead of priting the bogus error message. Reported-by:Vojtech Pavlik <vojtech@ucw.cz> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Jiri Kosina authored
This reverts commit 4192f7b5. It is not true (as stated in the reverted commit changelog) that we never unmap the BAR on failure; it actually does happen properly on amdgpu_driver_load_kms() -> amdgpu_driver_unload_kms() -> amdgpu_device_fini() error path. What's worse, this commit actually completely breaks resource freeing on probe failure (like e.g. failure to load microcode), as amdgpu_driver_unload_kms() notices adev->rmmio being NULL and bails too early, leaving all the resources that'd normally be freed in amdgpu_acpi_fini() and amdgpu_device_fini() still hanging around, leading to all sorts of oopses when someone tries to, for example, access the sysfs and procfs resources which are still around while the driver is gone. Fixes: 4192f7b5 ("drm/amdgpu: unmap register bar on device init failure") Reported-by:
-
Lang Yu authored
Use amdgpu_ucode_name to show ucode name and psp_gfx_cmd_name to show psp_gfx_cmd name in psp_cmd_submit_buf. v2: adjust function name Signed-off-by:
Lang Yu <Lang.Yu@amd.com> Reviewed-by:
Huang Rui <ray.huang@amd.com> Signed-off-by:
-
