- 13 Dec, 2023 40 commits
-
-
Melissa Wen authored
Add 3D LUT property for plane color transformations using a 3D lookup table. 3D LUT allows for highly accurate and complex color transformations and is suitable to adjust the balance between color channels. It's also more complex to manage and require more computational resources. Since a 3D LUT has a limited number of entries in each dimension we want to use them in an optimal fashion. This means using the 3D LUT in a colorspace that is optimized for human vision, such as sRGB, PQ, or another non-linear space. Therefore, userpace may need one 1D LUT (shaper) before it to delinearize content and another 1D LUT after 3D LUT (blend) to linearize content again for blending. The next patches add these 1D LUTs to the plane color mgmt pipeline. v3: - improve commit message about 3D LUT - describe the 3D LUT entries and size (Harry) v4: - advertise 3D LUT max size as the size of a single-dimension v5: - get lut3d blob correctly (Joshua) - fix doc about 3d-lut dimension size (Sebastian) Signed-off-by:
Melissa Wen <mwen@igalia.com> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Jani Nikula authored
Including drm_edid.h from radeon_mode.h causes the rebuild of more than a hundred files when drm_edid.h is modified, while there are only a handful of files that actually need to include drm_edid.h. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Friedrich Vock authored
This improves latency if the GPU is already busy with other work. This is useful for VR compositors that submit highly latency-sensitive compositing work on high-priority compute queues while the GPU is busy rendering the next frame. Userspace merge request: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26462 v2: bump driver version (Alex) Reviewed-by:
Marek Olšák <marek.olsak@amd.com> Signed-off-by:
Friedrich Vock <friedrich.vock@gmx.de> Signed-off-by:
-
Alex Deucher authored
Add begin/end_use ring callbacks to disallow GFXOFF when SDMA work is submitted and allow it again afterward. This should avoid corner cases where GFXOFF is erroneously entered when SDMA is still active. For now just allow/disallow GFXOFF in the begin and end helpers until we root cause the issue. This should not impact power as SDMA usage is pretty minimal and GFXOSS should not be active when SDMA is active anyway, this just makes it explicit. v2: move everything into sdma5.2 code. No reason for this to be generic at this point. v3: Add comments in new code Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2220 Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> (v1) Tested-by: Mario Limonciello <mario.limonciello@amd.com> (v1) Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Evan Quan authored
Fulfill the SMU13.0.7 support for Wifi RFI mitigation feature. -- v10->v11: - downgrade the prompt level on message failure(Lijo) v13: - Fix the format issue (IIpo Jarvinen) - Remove duplicate code (IIpo Jarvinen) Signed-off-by:
Evan Quan <quanliangl@hotmail.com> Reviewed-by:
Mario Limonciello <mario.limonciello@amd.com> Signed-off-by:
Ma Jun <Jun.Ma2@amd.com> Signed-off-by:
-
Ma Jun authored
Fulfill the SMU13.0.0 support for Wifi RFI mitigation feature. -- v10->v11: - downgrade the prompt level on message failure(Lijo) v13: - Fix the format issue (IIpo Jarvinen) - Move function smu_v13_0_0_set_wbrf_exclusion_ranges to smu_v13_0.c as a generic code for later use (IIpo Jarvinen) Co-developed-by:
-
Evan Quan authored
To protect PMFW from being overloaded. Signed-off-by:
-
Evan Quan authored
With WBRF feature supported, as a driver responding to the frequencies, amdgpu driver is able to do shadow pstate switching to mitigate possible interference(between its (G-)DDR memory clocks and local radio module frequency bands used by Wifi 6/6e/7). -- v1->v2: - update the prompt for feature support(Lijo) v8->v9: - update parameter document for smu_wbrf_event_handler(Simon) v9->v10: v10->v11: - correct the logics for wbrf range sorting(Lijo) v13: - Fix the format issue (IIpo Jarvinen) Signed-off-by:
-
Evan Quan authored
Add those data structures to support Wifi RFI mitigation feature. Signed-off-by:
-
Alex Deucher authored
Immutable branch between pdx86 amd wbrf branch and wifi / amdgpu due for the v6.8 merge window platform-drivers-x86-amd-wbrf-v6.8-1: v6.7-rc1 + AMD WBRF support for merging into the wifi subsys and amdgpu driver for 6.8. Signed-off-by: -
Felix Kuehling authored
Use drm_gem_prime_fd_to_handle to import DMABufs for interop. This ensures that a GEM handle is created on import and that obj->dma_buf will be set and remain set as long as the object is imported into KFD. Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
Ramesh Errabolu <Ramesh.Errabolu@amd.com> Reviewed-by:
Xiaogang.Chen <Xiaogang.Chen@amd.com> Acked-by:
-
Felix Kuehling authored
Create GEM handles for exporting DMABufs using GEM-Prime APIs. The GEM handles are created in a drm_client_dev context to avoid exposing them in user mode contexts through a DMABuf import. Signed-off-by:
-
Vignesh Chander authored
1. Use the mirrored topology info to fill links for VF. The new solution is required to simplify and optimize host driver logic. Only use the new solution for VFs that support full duplex and extended_peer_link_info otherwise the info would be incomplete. 2. avoid calling extended_link_info on VF as its not supported Signed-off-by:
Vignesh Chander <Vignesh.Chander@amd.com> Reviewed-by:
Zhigang Luo <zhigang.luo@amd.com> Reviewed-by:
Jonathan Kim <jonathan.kim@amd.com> Signed-off-by:
-
Harshit Mogalapalli authored
'wb_info' needs to be freed on error paths or it would leak the memory. Smatch pointed this out. Fixes: c81e13b9 ("drm/amd/display: Hande writeback request from userspace") Signed-off-by:
Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Reviewed-by:
Alex Hung <alex.hung@amd.com> Signed-off-by:
-
Joshua Ashton authored
Multiplier to 'gain' the plane. When PQ is decoded using the fixed func transfer function to the internal FP16 fb, 1.0 -> 80 nits (on AMD at least) When sRGB is decoded, 1.0 -> 1.0. Therefore, 1.0 multiplier = 80 nits for SDR content. So if you want, 203 nits for SDR content, pass in (203.0 / 80.0). v4: - comment about the PQ TF need for L-to-NL (from Harry's review) Reviewed-by:
Joshua Ashton <joshua@froggi.es> Co-developed-by:
-
Melissa Wen authored
Brief documentation about pre-defined transfer function usage on AMD display driver and standardized EOTFs and inverse EOTFs. v3: - Document BT709 OETF (Pekka) - Fix description of sRGB and pure power funcs (Pekka) v4: - Add description of linear and non-linear forms (Harry) Reviewed-by:
-
Melissa Wen authored
Instead of relying on color block names to get the transfer function intention regarding encoding pixel's luminance, define supported Electro-Optical Transfer Functions (EOTFs) and inverse EOTFs, that includes pure gamma or standardized transfer functions. v3: - squash linear and unity TFs to identity (Pekka) - define the right TFs for BT.709 (Pekka and Harry) - add comment about AMD TF coefficients Suggested-by:
-
Joshua Ashton authored
Allow userspace to tell the kernel driver the input space and, therefore, uses correct predefined transfer function (TF) to go from encoded values to linear values. v2: - rename TF enum prefix from DRM_ to AMDGPU_ (Harry) - remove HLG TF Reviewed-by:
-
Mario Limonciello authored
When screen brightness is rapidly changed and PSR-SU is enabled the display hangs on panels with this TCON even on the latest DCN 3.1.4 microcode (0x8002a81 at this time). This was disabled previously as commit 072030b1 ("drm/amd: Disable PSR-SU on Parade 0803 TCON") but reverted as commit 1e66a17c ("Revert "drm/amd: Disable PSR-SU on Parade 0803 TCON"") in favor of testing for a new enough microcode (commit cd2e31a9 ("drm/amd/display: Set minimum requirement for using PSR-SU on Phoenix")). As hangs are still happening specifically with this TCON, disable PSR-SU again for it until it can be root caused. Cc: stable@vger.kernel.org Cc: aaron.ma@canonical.com Cc: binli@gnome.org Cc: Marc Rossi <Marc.Rossi@amd.com> Cc: Hamza Mahfooz <Hamza.Mahfooz@amd.com> Signed-off-by:
-
Aric Cyr authored
Summary: Bug fixes for: * DCN35 power gating * P-state change, & prefetch logic * ABM * DP 2.1 Acked-by:
Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by:
Aric Cyr <aric.cyr@amd.com> Signed-off-by:
-
Charlene Liu authored
[why] Power up and power down has reverted programming order. also make sure disable root clock last. Reviewed-by:
Muhammad Ahmed <ahmed.ahmed@amd.com> Acked-by:
Charlene Liu <charlene.liu@amd.com> Signed-off-by:
-
Alvin Lee authored
[Description] - When we're in a no plane config, DCN is always asserting P-State allow - This creates a scenario where the P-State blackout can start just as VUPDATE takes place and transitions the DCN config to a one where one or more HUBP's are active which can result in underflow - To fix this issue, force p-state disallow and unforce after the transition from no planes case -> one or more planes active Reviewed-by:
Samson Tam <samson.tam@amd.com> Acked-by:
Alvin Lee <alvin.lee2@amd.com> Signed-off-by:
-
Alvin Lee authored
[Description] For mode programming we want to extend the prefetch as much as possible (up to oto, or as long as we can for equ) if we're not already applying the 60us prefetch requirement. This is to avoid intermittent underflow issues during prefetch. The prefetch extension is applied under the following scenarios: 1. We're in prefetch mode 1 (i.e. we don't support MCLK switch in blank) 2. We're using subvp or drr methods of p-state switch, in which case we we don't care if prefetch takes up more of the blanking time Mode programming typically chooses the smallest prefetch time possible (i.e. highest bandwidth during prefetch) presumably to create margin between p-states / c-states that happen in vblank and prefetch. Therefore we only apply this prefetch extension when p-state in vblank is not required (UCLK p-states take up the most vblank time). Reviewed-by:
Jun Lei <jun.lei@amd.com> Acked-by:
-
Sung Joon Kim authored
[why & how] User interface cannot guarantee system is in idle state, so need to ensure we exit idle state before accessing any HW data. Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by:
Sung Joon Kim <sungkim@amd.com> Signed-off-by:
-
Allen authored
[Why] To match the hardware sequence Reviewed-by:
Allen <allen.pan@amd.com> Signed-off-by:
-
Fangzhi Zuo authored
dtbclk is unavaliable from pmfw. Try to grab the value from bounding box Reviewed-by:
Fangzhi Zuo <jerry.zuo@amd.com> Signed-off-by:
-
Michael Strauss authored
[WHY] Introduces regression with DP2 native displays [HOW] Revert the change Reviewed-by:
Michael Strauss <michael.strauss@amd.com> Signed-off-by:
-
Aurabindo Pillai authored
FP guard is valid for all recent asics, not just RV, so fix the comment. Reviewed-by:
Chaitanya Dhere <chaitanya.dhere@amd.com> Acked-by:
-
Taimur Hassan authored
[Why & How] HostVMMinPageSize is expected to be in KB according to spec, the checks later down the line reflect this as well. Reviewed-by:
Taimur Hassan <syed.hassan@amd.com> Signed-off-by:
-
Ran Shi authored
why: With DP2.1a expansion we are allowing DP40 cables to do UHBR13.5 how: Assume UHBR10 means UHBR13.5 also for unknown cable type and passive cable type. Reviewed-by:
George Shen <george.shen@amd.com> Acked-by:
Ran Shi <ran.shi@amd.com> Signed-off-by:
-
Aurabindo Pillai authored
Reviewed-by:
-
Joshua Aberback authored
Reviewed-by:
Dillon Varone <dillon.varone@amd.com> Acked-by:
Joshua Aberback <joshua.aberback@amd.com> Signed-off-by:
-
Ma Jun authored
Remove redundant functions members of pptable_funcs and change the function type as static because they are not called by other files. Signed-off-by:
Yang Wang <kevinyang.wang@amd.com> Signed-off-by:
-
Saleemkhan Jamadar authored
Doorbell is configured during start of each playback. v1 - add comment for the doorbell programming change Signed-off-by:
Saleemkhan Jamadar <saleemkhan.jamadar@amd.com> Acked-by:
Leo Liu <leo.liu@amd.com> Reviewed-by:
Veerabadhran Gopalakrishnan <Veerabadhran.Gopalakrishnan@amd.com> Signed-off-by:
-
Lijo Lazar authored
Replace direct usage of adev->ip_versions with amdgpu_ip_version. Signed-off-by:
Lijo Lazar <lijo.lazar@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by:
-
Melissa Wen authored
Hook up driver-specific atomic operations for managing AMD color properties. Create AMD driver-specific color management properties and attach them according to HW capabilities defined by `struct dc_color_caps`. First add plane degamma LUT properties that means user-blob and its size. We will add more plane color properties in the next patches. In addition, we define AMD_PRIVATE_COLOR to guard these driver-specific plane properties. Plane degamma can be used to linearize input space for arithmetical operations that are more accurate when applied in linear color. v2: - update degamma LUT prop description - move private color operations from amdgpu_display to amdgpu_dm_color v5: - get degamma blob correctly (Joshua) Reviewed-by:
-
Melissa Wen authored
We will add color mgmt properties to DRM planes in the next patches and we want to track when one of this properties change to define atomic commit behaviors. Using a similar approach from CRTC color props, we set a color_mgmt_changed boolean whenever a plane color prop changes. Reviewed-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
-
Melissa Wen authored
Place it in drm_property where drm_property_replace_blob and drm_property_lookup_blob live. Then we can use the DRM helper for driver-specific KMS properties too. Reviewed-by:
Liviu Dudau <liviu.dudau@arm.com> Signed-off-by:
-
Melissa Wen authored
DRM_OBJECT_MAX_PROPERTY limits the number of properties to be attached and we are increasing that value all time we add a new property (generic or driver-specific). In this series, we are adding 13 new KMS driver-specific properties for AMD color manage: - CRTC Gamma enumerated Transfer Function - Plane: Degamma LUT+size+TF, HDR multiplier, shaper LUT+size+TF, 3D LUT+size, blend LUT+size+TF (12) Therefore, just increase DRM_OBJECT_MAX_PROPERTY to a number (64) that accomodates these new properties and gives some room for others, avoiding change this number everytime we add a new KMS property. Reviewed-by:
Simon Ser <contact@emersion.fr> Signed-off-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Acked-by:
-
Colin Ian King authored
There is a spelling mistake in a smu_print message. Fix it. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
