- 08 Jul, 2021 27 commits
-
-
Evan Quan authored
To suppress the annoying warning about version mismatch. Signed-off-by:
Evan Quan <evan.quan@amd.com> Reviewed-by:
Lijo Lazar <lijo.lazar@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
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:
Eric Huang <jinhuieric.huang@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> 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 13 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:
-
Lang Yu authored
Implement function psp_gfx_cmd_name to show cmd name via cmd id. v2: rename it to psp_gfx_cmd_name Signed-off-by:
-
Lang Yu authored
Implement function amdgpu_ucode_name to show ucode name via ucode id. v2: rename it to amdgpu_ucode_name Signed-off-by:
-
Alex Deucher authored
Was missing. Add it. Fixes: 6b36fa61 ("drm/amdgpu: add umc v8_7_0 IP headers") Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
Lukas Bulwahn authored
Commit 6b36fa61 ("drm/amdgpu: add umc v8_7_0 IP headers") adds the new file ./drivers/gpu/drm/amd/include/asic_reg/umc/umc_8_7_0_sh_mask.h with DOS line endings, which is very uncommon for the kernel repository. Rectify the line endings in this file with dos2unix. Identified by a checkpatch evaluation on the whole kernel repository and spot-checking for really unexpected checkpatch rule violations. Reported-by:
Dwaipayan Ray <dwaipayanray1@gmail.com> Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by:
-
Luben Tuikov authored
Simplify Aldebaran managed I2C transfer function to correctly play with the upper I2C layers. This gets it in line with Navi10, Acturus, and Sienna Cichlid. 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
On long transfers to the EEPROM device, i.e. write, it is observed that the driver aborts the transfer. The reason for this is that the driver isn't patient enough--the IC_STATUS register's contents is 0x27, which is MST_ACTIVITY | TFE | TFNF | ACTIVITY. That is, while the transmission FIFO is empty, we, the I2C master device, are still driving the bus. Implement the correct procedure to disable the block, as described in the DesignWare I2C Databook, section 3.8.3 Disabling DW_apb_i2c on page 56. Now there are no premature aborts on long data transfers. Cc: Alexander Deucher <Alexander.Deucher@amd.com> Cc: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> Signed-off-by:
-
Luben Tuikov authored
In smu_v11_0_i2c_transmit() use a single loop to transmit bytes, instead of two nested loops. Cc: Alexander Deucher <Alexander.Deucher@amd.com> Cc: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> Signed-off-by:
-
Luben Tuikov authored
Debugfs RAS EEPROM files are available when the ASIC supports RAS, and when the debugfs is enabled, an also when "ras_enable" module parameter is set to 0. However in this case, we get a kernel oops when accessing some of the "ras_..." controls in debugfs. The reason for this is that struct amdgpu_ras::adev is unset. This commit sets it, thus enabling access to those facilities. Note that this facilitates EEPROM access and not necessarily RAS features or functionality. Cc: Alexander Deucher <Alexander.Deucher@amd.com> Cc: John Clements <john.clements@amd.com> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
Alex Deucher authored
pos is 64 bits. Fixes: c65b0805 ("drm/amdgpu: RAS EEPROM table is now in debugfs") Cc: luben.tuikov@amd.com Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
-
Luben Tuikov authored
Add "ras_eeprom_size" file in debugfs, which reports the maximum size allocated to the RAS table in EEROM, as the number of bytes and the number of records it could store. For instance, $cat /sys/kernel/debug/dri/0/ras/ras_eeprom_size 262144 bytes or 10921 records $_ Add "ras_eeprom_table" file in debugfs, which dumps the RAS table stored EEPROM, in a formatted way. For instance, $cat ras_eeprom_table Signature Version FirstOffs Size Checksum 0x414D4452 0x00010000 0x00000014 0x000000EC 0x000000DA Index Offset ErrType Bank/CU TimeStamp Offs/Addr MemChl MCUMCID RetiredPage 0 0x00014 ue 0x00 0x00000000607608DC 0x000000000000 0x00 0x00 0x000000000000 1 0x0002C ue 0x00 0x00000000607608DC 0x000000001000 0x00 0x00 0x000000000001 2 0x00044 ue 0x00 0x00000000607608DC 0x000000002000 0x00 0x00 0x000000000002 3 0x0005C ue 0x00 0x00000000607608DC 0x000000003000 0x00 0x00 0x000000000003 4 0x00074 ue 0x00 0x00000000607608DC 0x000000004000 0x00 0x00 0x000000000004 5 0x0008C ue 0x00 0x00000000607608DC 0x000000005000 0x00 0x00 0x000000000005 6 0x000A4 ue 0x00 0x00000000607608DC 0x000000006000 0x00 0x00 0x000000000006 7 0x000BC ue 0x00 0x00000000607608DC 0x000000007000 0x00 0x00 0x000000000007 8 0x000D4 ue 0x00 0x00000000607608DD 0x000000008000 0x00 0x00 0x000000000008 $_ Cc: Alexander Deucher <Alexander.Deucher@amd.com> Cc: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> Cc: John Clements <john.clements@amd.com> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Cc: Xinhui Pan <xinhui.pan@amd.com> Signed-off-by:
-
