- 08 Jul, 2021 18 commits
-
-
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:
Aric Cyr <aric.cyr@amd.com> Acked-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Anthony Koo authored
- Updated SCR definition for FW boot options for Separate DCN init for DMUB FW loaded in VBL Signed-off-by:
Anthony Koo <Anthony.Koo@amd.com> Acked-by:
-
Alvin Lee authored
Type adjustments and formatting fixes. Signed-off-by:
Alvin Lee <Alvin.Lee2@amd.com> Reviewed-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-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:
Luben Tuikov <luben.tuikov@amd.com> Reviewed-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:
Lijo Lazar <Lijo.Lazar@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 22 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: -
Luben Tuikov authored
Split functionality between read and write, which simplifies the code and exposes areas of optimization and more or less complexity, and take advantage of that. Read and write the table in one go; use a separate stage to decode or encode the data, as opposed to on the fly, which keeps the I2C bus busy. Use a single read/write to read/write the table or at most two if the number of records we're reading/writing wraps around. Check the check-sum of a table in EEPROM on init. Update the checksum at the same time as when updating the table header signature, when the threshold was increased on boot. Take advantage of arithmetic modulo 256, that is, use a byte!, to greatly simplify checksum arithmetic. Cc: Alexander Deucher <Alexander.Deucher@amd.com> Cc: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> Signed-off-by:
-
Luben Tuikov authored
The code is now tested from userspace. Remove already macroed out test function. Cc: Alexander Deucher <Alexander.Deucher@amd.com> Cc: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> Signed-off-by:
-
Luben Tuikov authored
Qualify with "ras_". Use kernel's own--don't redefine your own. Cc: Alexander Deucher <Alexander.Deucher@amd.com> Cc: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> Signed-off-by:
-
Luben Tuikov authored
buff --> buf. Essentially buffer abbreviates to buf, remove 1/2 of it, or just the iron part, as opposed to just the Er, Cc: Alexander Deucher <Alexander.Deucher@amd.com> Cc: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> Signed-off-by:
-
Luben Tuikov authored
RAS_MAX_RECORD_NUM may mean the maximum record number, as in the maximum house number on your street, or it may mean the maximum number of records, as in the count of records, which is also a number. To make this distinction whether the number is ordinal (index) or cardinal (count), rename this macro to RAS_MAX_RECORD_COUNT. This makes it easy to understand what it refers to, especially when we compute quantities such as, how many records do we have left in the table, especially when there are so many other numbers, quantities and numerical macros around. Also rename the long, amdgpu_ras_eeprom_get_record_max_length() to the more succinct and clear, amdgpu_ras_eeprom_max_record_count(). When computing the threshold, which also deals with counts, i.e. "how many", use cardinal "max_eeprom_records_count", than the quantitative "max_eeprom_records_len". Simplify the logic here and there, as well. Cc: Guchun Chen <guchun.chen@amd.com> Cc: John Clements <john.clements@amd.com> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Cc: Alexander Deucher <Alexander.Deucher@amd.com> Signed-off-by:
-
Luben Tuikov authored
Rename update_table_header() to write_table_header() as this function is actually writing it to EEPROM. Use kernel types; use u8 to carry around the checksum, in order to take advantage of arithmetic modulo 8-bits (256). Tidy up to 80 columns. When updating the checksum, just recalculate the whole thing. Cc: Alexander Deucher <Alexander.Deucher@amd.com> Cc: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> Signed-off-by:
-
Luben Tuikov authored
No need to account for the 2 bytes of EEPROM address--this is now well abstracted away by the fixes the the lower layers. Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Cc: Alexander Deucher <Alexander.Deucher@amd.com> Signed-off-by:
-
Luben Tuikov authored
The low level EEPROM write method, doesn't return 1, but the number of bytes written. Thus do not compare to 1, instead, compare to greater than 0 for success. Other cleanup: if the lower layers returned -errno, then return that, as opposed to overwriting the error code with one-fits-all -EINVAL. For instance, some return -EAGAIN. Cc: Jean Delvare <jdelvare@suse.de> Cc: Alexander Deucher <Alexander.Deucher@amd.com> Cc: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> Cc: Lijo Lazar <Lijo.Lazar@amd.com> Cc: Stanley Yang <Stanley.Yang@amd.com> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
Luben Tuikov authored
The I2C address is kept as a 16-bit quantity in the kernel. The I2C_TAR::I2C_TAR field is 10-bit wide. Fix the width of the I2C address for Vega20 from 8 bits to 16 bits to accommodate the full spectrum of I2C address space. Cc: Jean Delvare <jdelvare@suse.de> Cc: Alexander Deucher <Alexander.Deucher@amd.com> Cc: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> Cc: Lijo Lazar <Lijo.Lazar@amd.com> Cc: Stanley Yang <Stanley.Yang@amd.com> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
