- 28 Apr, 2022 2 commits
-
-
Dave Airlie authored
Merge tag 'amd-drm-next-5.19-2022-04-22' of https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-5.19-2022-04-22: amdgpu: - SMU message documentation update - Misc code cleanups - Documenation updates - PSP TA updates - Runtime PM regression fix - SR-IOV header cleanup - Misc fixes amdkfd: - TLB flush fixes - GWS fixes - CRIU GWS support radeon: - Misc code cleanups Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220422150049.5859-1-alexander.deucher@amd.com
-
Dave Airlie authored
Merge tag 'amd-drm-next-5.19-2022-04-15' of https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-5.19-2022-04-15: amdgpu: - USB-C updates - GPUVM updates - TMZ fixes for RV - DCN 3.1 pstate fixes - Display z state fixes - RAS fixes - Misc code cleanups and spelling fixes - More DC FP rework - GPUVM TLB handling rework - Power management sysfs code cleanup - Add RAS support for VCN - Backlight fix - Add unique id support for more asics - Misc display updates - SR-IOV fixes - Extend CG and PG flags to 64 bits - Enable VCN clk sysfs nodes for navi12 amdkfd: - Fix IO link cleanup during device removal - RAS fixes - Retry fault fixes - Asynchronously free events - SVM fixes radeon: - Drop some dead code - Misc code cleanups From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220415135144.5700-1-alexander.deucher@amd.comSigned-off-by:
-
- 22 Apr, 2022 1 commit
-
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for 5.19-rc1 UAPI Changes: Cross-subsystem Changes: - of: Create a platform_device for offb Core Changes: - edid: block read refactoring - ttm: Add common debugfs code for resource managers Driver Changes: - bridges: - adv7611: Enable DRM_BRIDGE_OP_HPD if there's an interrupt - anx7625: Fill ELD if no monitor is connected - dw_hdmi: Add General Parallel Audio support - icn6211: Add data-lanes DT property - new driver: Lontium LT9211 - nouveau: make some structures static - tidss: Reset DISPC on startup - solomon: SPI Support and DT bindings improvements Signed-off-by:
-
- 21 Apr, 2022 17 commits
-
-
Bokun Zhang authored
- In the latest version of the header, there is a variable name change. This should not cause any backward compatibility since the variable is at the same offset in the struct. Signed-off-by:
Bokun Zhang <Bokun.Zhang@amd.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Bokun Zhang authored
- Clean up the identation in the header file Signed-off-by:
-
Bokun Zhang authored
- Update MIT license header Signed-off-by:
-
Alex Deucher authored
It's not used outside of dcn31_hubp.c. Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
Miaoqian Lin authored
When dcn20_clk_src_construct() fails, we need to release clk_src. Fixes: 6f4e6361 ("drm/amd/display: Add Renoir resource (v2)") Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Signed-off-by:
-
Haowen Bai authored
aux_rep only memset but no use at all, so we drop it. Signed-off-by:
Haowen Bai <baihaowen@meizu.com> Signed-off-by:
-
Alex Deucher authored
We normally runtime suspend when there are displays attached if they are in the DPMS off state, however, if something wakes the GPU we send a hotplug event on resume (in case any displays were connected while the GPU was in suspend) which can cause userspace to light up the displays again soon after they were turned off. Prior to commit 087451f3 ("drm/amdgpu: use generic fb helpers instead of setting up AMD own's."), the driver took a runtime pm reference when the fbdev emulation was enabled because we didn't implement proper shadowing support for vram access when the device was off so the device never runtime suspended when there was a console bound. Once that commit landed, we now utilize the core fb helper implementation which properly handles the emulation, so runtime pm now suspends in cases where it did not before. Ultimately, we need to sort out why runtime suspend in not working in this case for some users, but this should restore similar behavior to before. v2: move check into runtime_suspend v3: wake ups -> wakeups in comment, retain pm_runtime behavior in runtime_idle callback Fixes: 087451f3 ("drm/amdgpu: use generic fb helpers instead of setting up AMD own's.") Link: https://lore.kernel.org/r/20220403132322.51c90903@darkstar.example.org/Tested-by:
Michele Ballabio <ballabio.m@gmail.com> Reviewed-by:
Evan Quan <evan.quan@amd.com> Signed-off-by:
-
Lang Yu authored
This reverts commit 36bf9321. It causes SVM regressions on Vega10 with XNACK-ON. Just revert it at the moment. ./kfdtest --gtest_filter=KFDSVMRangeTest.MigratePolicyTest Signed-off-by:
Lang Yu <Lang.Yu@amd.com> Reviewed-by: Philip Yang<Philip.Yang@amd.com> Signed-off-by:
-
Candice Li authored
v1: Add debugfs support to load/unload/invoke TA in runtime. v2: 1. Update some variables to static. 2. Use PAGE_ALIGN to calculate shared buf size directly. 3. Remove fp check. 4. Update debugfs from read to write. Signed-off-by:
John Clements <john.clements@amd.com> Signed-off-by:
Candice Li <candice.li@amd.com> Reviewed-by:
Tao Zhou <tao.zhou1@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
Candice Li authored
The upcoming TA debugfs interface needs to use indirect buffer when performing TA invoke and check psp response status for TA load and invoke. Signed-off-by:
-
David Yat Sin authored
Add support to checkpoint/restore GWS (Global Wave Sync) queues. Signed-off-by:
David Yat Sin <david.yatsin@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
David Yat Sin authored
dqm->gws_queue_count and pdd->qpd.mapped_gws_queue need to be updated each time the queue gets evicted. Fixes: b8020b03 ("drm/amdkfd: Enable over-subscription with >1 GWS queue") Signed-off-by:
-
Zack Rusin authored
Switch to using the TTM resource manager debugfs helpers. The functionality is largely the same. The TTM resource managers need to stay valid for as long as the drm debugfs_root is valid. Signed-off-by:
Zack Rusin <zackr@vmware.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: amd-gfx@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20220412033526.369115-6-zack@kde.orgReviewed-by:
Christian König <christian.koenig@amd.com>
-
Zack Rusin authored
Switch to using the TTM resource manager debugfs helpers. The functionality is largely the same. The TTM resource managers need to stay valid for as long as the drm debugfs_root is valid. Signed-off-by:
-
Zack Rusin authored
Switch to using the TTM resource manager debugfs helpers. It's exactly the same functionality but the debugfs code is shared with other drivers. The TTM resource managers need to stay valid for as long as the drm debugfs_root is valid. Signed-off-by:
-
Zack Rusin authored
Use the newly added TTM's ability to automatically create debugfs entries for specified placements. This creates debugfs files that can be read to get information about various TTM resource managers which are used by vmwgfx. Signed-off-by:
-
Zack Rusin authored
Drivers duplicate the code required to add debugfs entries for various ttm resource managers. To fix it add common TTM resource manager debugfs code that each driver can reuse. Specific resource managers can overwrite ttm_resource_manager_func::debug to get more information from those debugfs entries. Signed-off-by:
-
- 20 Apr, 2022 8 commits
-
-
Javier Martinez Canillas authored
The ssd130x driver only provides the core support for these devices but it does not have any bus transport logic. Add a driver to interface over SPI. There is a difference in the communication protocol when using 4-wire SPI instead of I2C. For the latter, a control byte that contains a D/C# field has to be sent. This field tells the controller whether the data has to be written to the command register or to the graphics display data memory. But for 4-wire SPI that control byte is not used, instead a real D/C# line must be pulled HIGH for commands data and LOW for graphics display data. For this reason the standard SPI regmap can't be used and a custom .write bus handler is needed. Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
Mark Brown <broonie@kernel.org> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patchwork.freedesktop.org/patch/msgid/20220419214824.335075-6-javierm@redhat.com
-
Javier Martinez Canillas authored
These are declared in the ssd130x-i2c transport driver but the information is not I2C specific, and could be used by other SSD130x transport drivers. Move them to the ssd130x core driver and just set the OF device entries to an ID that could be used to lookup the correct device info from an array. While being there, also move the SSD130X_DATA and SSD130X_COMMAND control bytes. Since even though they are used by the I2C interface, they could also be useful for other transport protocols such as SPI. Suggested-by:
Chen-Yu Tsai <wens@kernel.org> Signed-off-by:
-
Javier Martinez Canillas authored
The current compatible strings for SSD130x I2C controllers contain an "fb" and "-i2c" suffixes. These have been deprecated and more correct ones were added, that don't encode a subsystem or bus used to interface the devices. Signed-off-by:
-
Javier Martinez Canillas authored
The Solomon SSD130x OLED displays can either have an I2C or SPI interface, add to the schema the properties and examples for OLED devices under SPI. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220419214824.335075-3-javierm@redhat.com
-
Javier Martinez Canillas authored
The current compatible strings for SSD130x I2C controllers contain both an "fb" and "-i2c" suffixes. It seems to indicate that are for a fbdev driver and also that are for devices that can be accessed over an I2C bus. But a DT is supposed to describe the hardware and not Linux implementation details. So let's deprecate those compatible strings and add new ones that only contain the vendor and device name, without any of these suffixes. These will just describe the device and can be matched by both I2C and SPI DRM drivers. The required properties should still be enforced for old ones. While being there, just drop the "sinowealth,sh1106-i2c" compatible string since that was never present in a released Linux version. Signed-off-by:
-
Thomas Zimmermann authored
A workaround makes fbdev hot-unplugging work for framebuffers without device. The only user for this feature was offb. As each OF framebuffer now has an associated platform device, the workaround hould no longer be triggered. Update it with a warning and rewrite the comment. Fbdev drivers that trigger the hot-unplug workaround really need to be fixed. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
-
Thomas Zimmermann authored
Create a platform device for each OF-declared framebuffer and have offb bind to these devices. Allows for real hot-unplugging and other drivers besides offb. Originally, offb created framebuffer devices while initializing its module by parsing the OF device tree. No actual Linux device was set up. This tied OF framebuffers to offb and makes writing other drivers for the OF framebuffers complicated. The absence of a Linux device further prevented real hot-unplugging. Adding a distinct platform device for each OF framebuffer solves both problems. Specifically, a DRM driver can now provide graphics output for modern userspace. Some of the offb init code is now located in the OF initialization. There's now also an implementation of of_platform_default_populate_init(), which was missing before. The OF side creates different devices for either OF display nodes or BootX displays as they require different handling by the driver. The offb drivers picks up each type of device and runs the appropriate fbdev initialization. Tested with OF display nodes on qemu's ppc64le target. v3: * declare variable 'node' with function scope (Rob) v2: * run PPC code as part of existing initialization (Rob) * add a few more error warnings (Javier) Signed-off-by:
-
Xiaomeng Tong authored
Instead of exiting the loop as expected when an entry is found, the list_for_each_entry() continues until the traversal is complete. To avoid potential executing 'ret = gma_backlight_init(dev);' repeatly, goto outside the loop when found entry by replacing switch/case with if statement. Signed-off-by:
Xiaomeng Tong <xiam0nd.tong@gmail.com> Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> [Fixed indentation] Link: https://patchwork.freedesktop.org/patch/msgid/20220413051105.5612-1-xiam0nd.tong@gmail.com
-
- 19 Apr, 2022 12 commits
-
-
Tales Lelo da Aparecida authored
To make sure maintainers of amdgpu drivers are aware of any changes in their documentation, add its entry to MAINTAINERS. Acked-by:
Tales Lelo da Aparecida <tales.aparecida@gmail.com> Signed-off-by:
-
Tales Lelo da Aparecida authored
Add missing acronyms to the amdgppu glossary. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/1939Acked-by:
-
Tom Rix authored
evergreen_default_state and evergreen_default_size are only used in evergreen.c. Single file symbols should be static. So move their definitions to evergreen_blit_shaders.h and change their storage-class-specifier to static. Remove unneeded evergreen_blit_shader.c evergreen_ps/vs definitions were removed with commit 4f862967 ("drm/radeon/kms: remove r6xx+ blit copy routines") So their declarations in evergreen_blit_shader.h are not needed, so remove them. Signed-off-by:
Tom Rix <trix@redhat.com> Signed-off-by:
-
Tom Rix authored
Smatch reports this issue virtual_link_hwss.c:32:6: warning: symbol 'virtual_setup_stream_attribute' was not declared. Should it be static? virtual_setup_stream_attribute is only used in virtual_link_hwss.c, but the other functions in the file are declared in the header file and used elsewhere. For consistency, add the virtual_setup_stream_attribute decl to virtual_link_hwss.h. Signed-off-by:
-
Keita Suzuki authored
In function si_parse_power_table(), array adev->pm.dpm.ps and its member is allocated. If the allocation of each member fails, the array itself is freed and returned with an error code. However, the array is later freed again in si_dpm_fini() function which is called when the function returns an error. This leads to potential double free of the array adev->pm.dpm.ps, as well as leak of its array members, since the members are not freed in the allocation function and the array is not nulled when freed. In addition adev->pm.dpm.num_ps, which keeps track of the allocated array member, is not updated until the member allocation is successfully finished, this could also lead to either use after free, or uninitialized variable access in si_dpm_fini(). Fix this by postponing the free of the array until si_dpm_fini() and increment adev->pm.dpm.num_ps everytime the array member is allocated. Signed-off-by:
Keita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp> Signed-off-by:
-
Tales Lelo da Aparecida authored
It's a local function, let's make it static. AGD: remove prototype in dcn10_hubp.h Signed-off-by:
-
Darren Powell authored
Clarify the smu_cmn_send_smc_msg_with_param documentation to mention two cases exist where messages are silently dropped with no error returned. These cases occur in unusual situations where either: 1. the message type is not allowed to a virtual GPU, or 2. a PCI recovery is underway and the HW is not yet in sync with the SW For more details see commit 4ea5081c ("drm/amd/powerplay: enable SMC message filter") commit bf36b52e ("drm/amdgpu: Avoid accessing HW when suspending SW state") (v2) Reworked with suggestions from Luben & Paul (v3) Updated wording as per Luben's feedback Corrected error stating all messages denied on virtual GPU (each GPU has mask of which messages are allowed) Signed-off-by:
Darren Powell <darren.powell@amd.com> Reviewed-by:
Luben Tuikov <luben.tuikov@amd.com> Signed-off-by:
-
Huang Rui authored
It needs to check if the pp_funcs is initialized while release the context, otherwise it will trigger null pointer panic while the software smu is not enabled. [ 1109.404555] BUG: kernel NULL pointer dereference, address: 0000000000000078 [ 1109.404609] #PF: supervisor read access in kernel mode [ 1109.404638] #PF: error_code(0x0000) - not-present page [ 1109.404657] PGD 0 P4D 0 [ 1109.404672] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 1109.404701] CPU: 7 PID: 9150 Comm: amdgpu_test Tainted: G OEL 5.16.0-custom #1 [ 1109.404732] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 1109.404765] RIP: 0010:amdgpu_dpm_force_performance_level+0x1d/0x170 [amdgpu] [ 1109.405109] Code: 5d c3 44 8b a3 f0 80 00 00 eb e5 66 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 08 4c 8b b7 f0 7d 00 00 <49> 83 7e 78 00 0f 84 f2 00 00 00 80 bf 87 80 00 00 00 48 89 fb 0f [ 1109.405176] RSP: 0018:ffffaf3083ad7c20 EFLAGS: 00010282 [ 1109.405203] RAX: 0000000000000000 RBX: ffff9796b1c14600 RCX: 0000000002862007 [ 1109.405229] RDX: ffff97968591c8c0 RSI: 0000000000000001 RDI: ffff9796a3700000 [ 1109.405260] RBP: ffffaf3083ad7c50 R08: ffffffff9897de00 R09: ffff979688d9db60 [ 1109.405286] R10: 0000000000000000 R11: ffff979688d9db90 R12: 0000000000000001 [ 1109.405316] R13: ffff9796a3700000 R14: 0000000000000000 R15: ffff9796a3708fc0 [ 1109.405345] FS: 00007ff055cff180(0000) GS:ffff9796bfdc0000(0000) knlGS:0000000000000000 [ 1109.405378] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1109.405400] CR2: 0000000000000078 CR3: 000000000a394000 CR4: 00000000000506e0 [ 1109.405434] Call Trace: [ 1109.405445] <TASK> [ 1109.405456] ? delete_object_full+0x1d/0x20 [ 1109.405480] amdgpu_ctx_set_stable_pstate+0x7c/0xa0 [amdgpu] [ 1109.405698] amdgpu_ctx_fini.part.0+0xcb/0x100 [amdgpu] [ 1109.405911] amdgpu_ctx_do_release+0x71/0x80 [amdgpu] [ 1109.406121] amdgpu_ctx_ioctl+0x52d/0x550 [amdgpu] [ 1109.406327] ? _raw_spin_unlock+0x1a/0x30 [ 1109.406354] ? drm_gem_handle_delete+0x81/0xb0 [drm] [ 1109.406400] ? amdgpu_ctx_get_entity+0x2c0/0x2c0 [amdgpu] [ 1109.406609] drm_ioctl_kernel+0xb6/0x140 [drm] Signed-off-by:
Huang Rui <ray.huang@amd.com> Reviewed-by:
Aaron Liu <aaron.liu@amd.com> Signed-off-by:
-
Lang Yu authored
The idea is from commit a50fe707 ("drm/amdkfd: Only apply heavy-weight TLB flush on Aldebaran") and commit f61c40c0 ("drm/amdkfd: enable heavy-weight TLB flush on Arcturus"). At the moment, heavy-weight TLB could cause problems on ASICs except Aldebaran and Arcturus. A simple hipMallocManaged/hipFree program could trigger this issue. [ 97.787657] amdgpu 0000:01:00.0: amdgpu: wait for kiq fence error: 0. [ 106.868758] amdgpu: qcm fence wait loop timeout expired [ 106.868966] amdgpu: The cp might be in an unrecoverable state due to an unsuccessful queues preemption [ 106.869203] amdgpu: Failed to evict process queues [ 106.869261] amdgpu: Failed to quiesce KFD Signed-off-by:
-
Lang Yu authored
To make kfd_flush_tlb_after_unmap visible in kfd_svm.c, move it into kfd_priv.h. And change it to an inline function. Signed-off-by:
-
Marek Vasut authored
The driver currently hard-codes DSI lane count to two, however the chip is capable of operating in 1..4 DSI lanes mode. Parse 'data-lanes' DT property and program the result into DSI_CTRL register. Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> To: dri-devel@lists.freedesktop.org Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220407185617.179573-2-marex@denx.de
-
Marek Vasut authored
It is necessary to specify the number of connected/used DSI data lanes when using the DSI input port of this bridge. Document the 'data-lanes' property of the DSI input port. Signed-off-by:
-
