- 19 Jan, 2023 8 commits
-
-
Mario Limonciello authored
Mendocino launched in 2023 and uses the new naming scheme for APU processors. Link: https://community.amd.com/t5/corporate/announcing-new-model-numbers-for-2023-mobile-processors/ba-p/543985Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Mario Limonciello <mario.limonciello@amd.com> Signed-off-by:
-
Mario Limonciello authored
These products have launched, so add matching codenames. Also AMD has announced that both of these products have new refresh variants that launch in 2023 using the new naming scheme, so add that information. Link: https://community.amd.com/t5/corporate/announcing-new-model-numbers-for-2023-mobile-processors/ba-p/543985Reviewed-by:
-
Mario Limonciello authored
MP0 version is useful to know to figure out which firmware is intended for a platform. Add a column for all supported APUs. v2: squash in column fix (Mario) Reviewed-by:
-
Lang Yu authored
Always enable multipipe policy on ASICs with GC VERSION > 9.0.0 instead of MEC number > 1. This will allow multipipe policy on ASICs with one MEC, e.g., gfx11 APUs. Signed-off-by:
Lang Yu <Lang.Yu@amd.com> Reviewed-by:
Aaron Liu <aaron.liu@amd.com> Reviewed-by:
Yifan Zhang <yifan1.zhang@amd.com> Signed-off-by:
-
Lang Yu authored
There is only one MEC on these APUs. Signed-off-by:
-
Hamza Mahfooz authored
Currently, we run into a number of WARN()s when attempting to unload the amdgpu driver (e.g. using "modprobe -r amdgpu"). These all stem from calling drm_encoder_cleanup() too early. So, to fix this we can stop calling drm_encoder_cleanup() from amdgpu_dm_fini() and instead have it be called from amdgpu_dm_encoder_destroy(). Also, we don't need to free in amdgpu_dm_encoder_destroy() since mst_encoders[] isn't explicitly allocated by the slab allocator. Fixes: f74367e4 ("drm/amdgpu/display: create fake mst encoders ahead of time (v4)") Reviewed-by:
Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by:
-
Guilherme G. Piccoli authored
The HW model validation that guards the indirect SRAM checking in the VCN code path is redundant - there's no model that's not included in the switch, making it useless in practice [0]. So, let's remove this switch statement for good. [0] lore.kernel.org/amd-gfx/MN0PR12MB61013D20B8A2263B22AE1BCFE2C19@MN0PR12MB6101.namprd12.prod.outlook.com Suggested-by:
Guilherme G. Piccoli <gpiccoli@igalia.com> Signed-off-by:
-
Guilherme G. Piccoli authored
This is an incredibly trivial fix, just for the sake of "aesthetical" organization of the defines. Some were space based, most were tab based and there was a lack of "alignment", now it's all the same and aligned. Cc: James Zhu <James.Zhu@amd.com> Cc: Lazar Lijo <Lijo.Lazar@amd.com> Cc: Leo Liu <leo.liu@amd.com> Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Sonny Jiang <sonny.jiang@amd.com> Reviewed-by:
-
- 17 Jan, 2023 32 commits
-
-
Leo Liu authored
The problem is that base sched hasn't been assigned yet at this moment, causing something like "ring=0" all the time from trace. mpv:cs0-3473 [002] ..... 129.047431: amdgpu_cs: ring=0, dw=48, fences=0 mpv:cs0-3473 [002] ..... 129.089125: amdgpu_cs: ring=0, dw=48, fences=0 mpv:cs0-3473 [002] ..... 129.130987: amdgpu_cs: ring=0, dw=48, fences=0 mpv:cs0-3473 [002] ..... 129.172478: amdgpu_cs: ring=0, dw=48, fences=0 Fixes: 4624459c ("drm/amdgpu: add gang submit frontend v6") Signed-off-by:
Leo Liu <leo.liu@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Stanley.Yang authored
There is xgmi3x16 pcs error status for aldebaran, driver should check xgmi3x16 pcs error status field instead of gopx16 pcs error status field. Signed-off-by:
Stanley.Yang <Stanley.Yang@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
Stanley.Yang authored
The pcs error count should be determined by PCS ERROR status and PCS ERROR MASK registers, only PCS ERROR status register can not refect error counts accurately. Changed from V1: remove clean noncorrectable mask registers optimize query pcs error status Changed from V2: remove check mask_value bits correct set value corresponding bit Signed-off-by:
Lijo Lazar <lijo.lazar@amd.com> Signed-off-by:
-
Christian König authored
It can be that neither fence were initialized when we run out of UVD streams for example. v2: fix typo breaking compile Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2324Signed-off-by:
-
YiPeng Chai authored
Use gfx ras common initialization interface to initialize gfx ras block. V2: Update function call due to amdgpu_gfx_ras_sw_init interface changes. Signed-off-by:
YiPeng Chai <YiPeng.Chai@amd.com> Reviewed-by:
Tao Zhou <tao.zhou1@amd.com> Signed-off-by:
-
Thomas Zimmermann authored
Align a closing brace and remove trailing whitespaces. No functional changes. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
-
Joshua Ashton authored
The YCC conversion matrix for RGB -> COLOR_SPACE_YCBCR2020_TYPE is missing the values for the fourth column of the matrix. The fourth column of the matrix is essentially just a value that is added given that the color is 3 components in size. These values are needed to bias the chroma from the [-1, 1] -> [0, 1] range. This fixes color being very green when using Gamescope HDR on HDMI output which prefers YCC 4:4:4. Fixes: 40df2f80 ("drm/amd/display: color space ycbcr709 support") Reviewed-by:
Melissa Wen <mwen@igalia.com> Signed-off-by:
Joshua Ashton <joshua@froggi.es> Signed-off-by:
-
Joshua Ashton authored
Code in get_output_color_space depends on knowing the pixel encoding to determine whether to pick between eg. COLOR_SPACE_SRGB or COLOR_SPACE_YCBCR709 for transparent RGB -> YCbCr 4:4:4 in the driver. v2: Fixed patch being accidentally based on a personal feature branch, oops! Fixes: ea117312 ("drm/amd/display: Reduce HDMI pixel encoding if max clock is exceeded") Reviewed-by:
-
Deepak R Varma authored
Use swap() helper macro instead of open coded swap instructions. The change also facilitates code cleanup and realignment for improved readability. Issue identified using swap.cocci Coccinelle semantic patch script. Signed-off-by:
Deepak R Varma <drv@mailo.com> Signed-off-by:
-
Deepak R Varma authored
For bit mask addition, it is recommended to use or operator "|" instead of numerical addition as the former is quicker and cleaner. Change suggested by orplus.cocci Coccinelle semantic patch. Reviewed-by:
Evan Quan <evan.quan@amd.com> Signed-off-by:
-
Deepak R Varma authored
For bit mask addition, it is recommended to use or operator "|" instead of numerical addition as the former is quicker and cleaner. Change suggested by orplus.cocci Coccinelle semantic patch. Reviewed-by:
-
Deepak R Varma authored
For bit mask addition, it is recommended to use or operator "|" instead of numerical addition as the former is quicker and cleaner. Change suggested by orplus.cocci Coccinelle semantic patch. Reviewed-by:
-
Alex Deucher authored
Power reporting is socket power. On APUs this includes the CPU. Update the documentation to clarify this. Reviewed-by:
-
Philip Yang authored
Update queue qpd is done for the first queue creation of the process, if the device support XNACK mode per process, update qpd setup sh_mem_config based on the process XNACK mode, to support the process destroy all queues, change XNACK mode, and then create queues. Add helper macro KFD_SUPPORT_XNACK_PER_PROCESS to remove duplicate code and add new ASICs support in future. Signed-off-by:
Philip Yang <Philip.Yang@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
Mario Limonciello authored
If early init fails for a single IP block, then no further IP blocks are evaluated. This means that if a user was missing more than one firmware binary they would have to keep adding binaries and re-probing until they discovered the ones missing. To make this easier, run early init for each IP block and report a single failure if not all passed. Reviewed-by:
-
Mario Limonciello authored
There is already a "default" case in the switch block, so there is no need to have a break after the switch block. Reviewed-by:
-
Christian König authored
We need to reset this or otherwise run into list corruption later on. Fixes: e44a0fe6 ("drm/amdgpu: rework reserved VMID handling") Signed-off-by:
Candice Li <candice.li@amd.com> Signed-off-by:
-
YiPeng Chai authored
[Why]: Amdgpu ras uses amdgpu_ras_is_supported to check whether the ras block supports the ras function. amdgpu_ras_is_supported uses .ras_enabled to determine whether the ras function of the block is enabled. But for special asic with mem ecc enabled but sram ecc not enabled, some ras blocks support poison mode but their ras function is not enabled on .ras_enabled, these ras blocks will run abnormally. [How]: If the ras block is not supported on .ras_enabled but the asic supports poison mode and the ras block has ras configuration, it can be considered that the ras block supports ras function. Signed-off-by: -
YiPeng Chai authored
[Why]: For special asic with mem ecc enabled but sram ecc not enabled, some ras blocks can register their ras configuration to ras list, but these ras blocks are not enabled on .ras_enabled, so it can not get ras block object using amdgpu_ras_get_ras_block. [How]: Remove ras block support check. Even if the ras block checked is not in the ras list, it will return a null pointer and will have no effect. Signed-off-by:
-
YiPeng Chai authored
Perform gpu reset after gfx finishes processing ras poison consumption on gfx_v11_0_3. V2: Move gfx poison consumption handler from hw_ops to ip function level. V3: Adjust the calling position of amdgpu_gfx_poison_consumation_handler. V4: Since gfx v11_0_3 does not have .hw_ops instance, the .hw_ops null pointer check in amdgpu_ras_interrupt_poison_consumption_handler needs to be adjusted. Signed-off-by:
-
YiPeng Chai authored
V2: Optimize gfx_v11_0_set_cp_ecc_error_state function. V3: Define macro constant for me pipe instance address interval. V5: Register and handle gfx cp ecc error irq on gfx v11_0_3. V6: Remove invalid intermediate function call. Signed-off-by:
-
YiPeng Chai authored
Add gfx ras poison consumption irq handling on gfx v11_0_3. V2: Move ras poison consumption irq handling code of gfx v11_0_3 to gfx_v11_0_3.c. V5: Create dedicated irq handler for RLC_GC_FED_INTERRUPT. V6: Remove invalid function call. Signed-off-by: -
YiPeng Chai authored
V2: Add RLC_RLCS_FED_STATUS_0 and RLC_RLCS_FED_STATUS_1 register offset and shift masks. Signed-off-by:
-
YiPeng Chai authored
Add gfx ras function on gfx v11_0_3. V2: 1. Add separate source files for gfx v11_0_3. 2. Create a common function to initialize gfx ras block. V3: 1. Rename amdgpu_gfx_ras_block_init to amdgpu_gfx_ras_sw_init. 2. Adjust the calling position of amdgpu_gfx_ras_sw_init. 3. Remove gfx_v11_0_3_ras_ops. V4: Revert changes in amdgpu_ras_interrupt_poison_consumption_handler. V5: 1. Remove invalid include file in gfx_v11_0_3.c. 2. Reduce the number of parameters of amdgpu_gfx_ras_sw_init. Signed-off-by:
-
Mario Limonciello authored
The existing codebase never had a case for detecting MP0 version on Renoir and instead relied upon hardcoded chip name. This was missed as part of the changes to migrate all IP blocks to build filenames from `amdgpu_ucode.c`. Consequently, Renoir tries to fetch a binary with 11_0_3 in the filename and since it's supposed to have "renoir" in the filename fails to probe. The fbdev still works though so the series worked. Add a case for Renoir into the legacy table to ensure the right ASD and TA firmware load again. Reported-by:
Ekene Akuneme <Ekene.Akuneme@amd.com> Reported-by:
Nicholas Choi <Nicholas.Choi@amd.com> Cc: Alex Hung <Alex.Hung@amd.com> Fixes: 994a9744 ("drm/amd: Parse both v1 and v2 TA microcode headers using same function") Fixes: 54a3e032 ("drm/amd: Add a legacy mapping to "amdgpu_ucode_ip_version_decode"") Signed-off-by:
-
Aric Cyr authored
This version brings along following fixes: - Revert patches that caused regressions associated with audio and an old change that checks the DCN version. - Refactor DDC and HDP. - Move DPIA and DPCD logic to new files. - Updates to DMUB. - Optimization and bug fixes for SUBVP/DRR. - Drop legacy code. Tested-by:
Daniel Wheeler <Daniel.Wheeler@amd.com> Reviewed-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by:
Aric Cyr <aric.cyr@amd.com> Signed-off-by:
-
hersen wu authored
[Why] incorrect skip when drm_connector.index = 0 within event_property_validate and update [How] handle hdcp validate and update for connector 0 Tested-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Acked-by:
hersen wu <hersenxs.wu@amd.com> Signed-off-by:
-
hersen wu authored
[why] For MST topology with 1 physical link and multiple connectors (>=2), e.g. daisy cahined MST + SST, or 1-to-multi MST hub, if userspace set to enable the HDCP simultaneously on all connected outputs, the commit tail iteratively call the hdcp_update_display() for each display (connector). However, the hdcp workqueue data structure for each link has only one DM connector and encryption status members, which means the work queue of property_validate/update() would only be triggered for the last connector within this physical link, and therefore the HDCP property value of other connectors would stay on DESIRED instead of switching to ENABLED, which is NOT as expected. [how] Use array of AMDGPU_DM_MAX_DISPLAY_INDEX for both aconnector and encryption status in hdcp workqueue data structure for each physical link. For property validate/update work queue, we iterates over the array and do similar operation/check for each connected display. Tested-by:
-
Dillon Varone authored
[WHY?] Cannot only consider the MALL required from top pipes because of the MPO case. [HOW?] Only count a pipe if it fits the following criteria: 1) does not have a top pipe (is the topmost pipe for that plane) 2) it does have a top pipe, but that pipe is associated with a different plane Tested-by:
Nevenko Stupar <Nevenko.Stupar@amd.com> Acked-by:
Dillon Varone <Dillon.Varone@amd.com> Signed-off-by:
-
Alvin Lee authored
Enable subvp on specifically 1440p@60hz displays even though it can switch in vactive. Tested-by:
Jun Lei <Jun.Lei@amd.com> Acked-by:
Alvin Lee <Alvin.Lee2@amd.com> Signed-off-by:
-
Alvin Lee authored
[Description] - Request min clocks after disabling pipes on init - This optimizes for power savings during init sequence - Also handles the case where we boot up with no display connected Tested-by:
-
Brandon Syu authored
[Why] There is an issue mapping non-allocated location of memory. It would allocate gpio registers from an array out of bounds. [How] Patch correct numbers of bounds for using. Tested-by:
Martin Leung <Martin.Leung@amd.com> Acked-by:
Brandon Syu <Brandon.Syu@amd.com> Signed-off-by:
-
