aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-01-19drm/amdgpu: Optimize sdma ras block initialization code for sdma v4_0YiPeng Chai1-16/+5
Optimize sdma ras block initialization code for sdma v4_0. Signed-off-by: YiPeng Chai <[email protected]> Reviewed-by: Tao Zhou <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-19drm/amd/display: fix hdmi_encoded_link_bw definitionArnd Bergmann1-6/+0
Some of the data structures are hidden when CONFIG_DRM_AMD_DC_DCN is disabled, which leads to a link failure: drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dp_capability.c:234:21: error: 'union hdmi_encoded_link_bw' declared inside parameter list will not be visible outside of this definition or declaration [-Werror] 234 | const union hdmi_encoded_link_bw hdmi_encoded_link_bw) | ^~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dp_capability.c:234:42: error: parameter 2 ('hdmi_encoded_link_bw') has incomplete type 234 | const union hdmi_encoded_link_bw hdmi_encoded_link_bw) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dp_capability.c:232:17: error: function declaration isn't a prototype [-Werror=strict-prototypes] 232 | static uint32_t intersect_frl_link_bw_support( | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dp_capability.c: In function 'get_active_converter_info': drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dp_capability.c:1126:76: error: storage size of 'hdmi_encoded_link_bw' isn't known 1126 | union hdmi_encoded_link_bw hdmi_encoded_link_bw; | ^~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dp_capability.c:1130:101: error: 'struct <anonymous>' has no member named 'MAX_ENCODED_LINK_BW_SUPPORT' 1130 | hdmi_color_caps.bits.MAX_ENCODED_LINK_BW_SUPPORT); There is probably no need to hide the data structure, and removing the #ifdef makes it build cleanly. Fixes: d5a43956b73b ("drm/amd/display: move dp capability related logic to link_dp_capability") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-19drm/amd/display: fix dp_retrieve_lttpr_cap() return valueArnd Bergmann1-3/+3
gcc-13 notices a mismatch between the return type of dp_retrieve_lttpr_cap() and the returned value: drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dp_capability.c: In function 'dp_retrieve_lttpr_cap': drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dp_capability.c:1465:24: error: implicit conversion from 'enum <anonymous>' to 'enum dc_status' [-Werror=enum-conversion] 1465 | return false; | ^~~~~ Change the value to an actual dc_status code and remove the bogus initialization that was apparently meant to get returned here. Fixes: b473bd5fc333 ("drm/amd/display: refine wake up aux in retrieve link caps") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-19drm/amdgpu: Add sdma ras function on sdma v6_0_3YiPeng Chai3-0/+60
Add sdma ras function on sdma v6_0_3. Signed-off-by: YiPeng Chai <[email protected]> Reviewed-by: Tao Zhou <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-19drm/amd/display: disable S/G display on DCN 3.1.4Alex Deucher1-1/+0
Causes flickering or white screens in some configurations. Disable it for now until we can fix the issue. Cc: [email protected] Cc: [email protected] Acked-by: Christian König <[email protected]> Reviewed-by: Roman Li <[email protected]> Reviewed-by: Yifan Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-19drm/amd/display: disable S/G display on DCN 3.1.5Alex Deucher1-1/+0
Causes flickering or white screens in some configurations. Disable it for now until we can fix the issue. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2354 Cc: [email protected] Cc: [email protected] Acked-by: Christian König <[email protected]> Reviewed-by: Yifan Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-19drm/amd: decrease message about missing PSP runtime database to debugMario Limonciello1-1/+1
Laptops with APUs from a variety of manufacturers and generations show a warning about a missing PSP runtime database. As it's not required for PSP to dump this database into framebuffer, decrease messages about it missing to debug. Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-19drm/amd/display: Decrease messaging about DP alt mode state to debugMario Limonciello1-1/+1
Currently plugging in a USB-C device that issues an HPD will emit a warning level message `DP Alt mode state on HPD: %d`. This is needlessly noisy for most people, decrease it to debug so that it can be turned on by dynamic debug as needed. Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-19drm/amdgpu/vcn4: fail to schedule IB for AV1 if VCN0 is harvestedAlex Deucher1-0/+4
Only VCN0 supports AV1. Reviewed-by: Leo Liu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-19drm/amdgpu/soc21: don't expose AV1 if VCN0 is harvestedAlex Deucher1-13/+48
Only VCN0 supports AV1. Reviewed-by: Leo Liu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-19drm/amdgpu/vcn3: fail to schedule IB for AV1 if VCN0 is harvestedAlex Deucher1-0/+4
Only VCN0 supports AV1. Reviewed-by: Leo Liu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-19drm/amdgpu/nv: don't expose AV1 if VCN0 is harvestedAlex Deucher1-20/+81
Only VCN0 supports AV1. Reviewed-by: Leo Liu <[email protected]> Acked-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-19Documentation/gpu: Add Raphael to apu-asic-info-tableMario Limonciello1-0/+1
Raphael launched in 2022 but was missed to add to this table. Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-19Documentation/gpu: Add Mendocino to apu-asic-info-tableMario Limonciello1-0/+1
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/543985 Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-19Documentation/gpu: Update lines for GREEN_SARDINE and YELLOW_CARPMario Limonciello1-2/+2
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/543985 Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-19Documentation/gpu: Add MP0 version to apu-asic-info-tableMario Limonciello2-9/+9
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: Alex Deucher <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-19drm/panel: vtdr6130: fix unused ret in visionox_vtdr6130_bl_update_statusNeil Armstrong1-6/+1
Fix the following warning: panel-visionox-vtdr6130.c:249:12: warning: 'ret' is used uninitialized [-Wuninitialized] Fixes: 9402cde9347e ("drm/panel: vtdr6130: Use 16-bit brightness function") Reported-by: Daniel Vetter <[email protected]> Reported-by: kernel test robot <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20230119-topic-sm8550-vtdr6130-fixup-v1-1-82c4fb008138@linaro.org
2023-01-19drm/edid: move EDID BPC quirk application to update_display_info()Jani Nikula1-13/+13
The BPC quirks are closer to home in update_display_info(). Cc: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/8997e0fa3b0fd03c920e72d1dff24c0d96ff4dd0.1672826282.git.jani.nikula@intel.com
2023-01-19drm/edid: merge ELD handling to update_display_info()Jani Nikula1-15/+13
Simplify display info update by merging ELD handling as well as clearing of the data in update_display_info(). The connector->eld really should be moved under display_info altogether, but that's for another time. Cc: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/1f2e7424b998fbcdd9cea488e7d6d7cbb26c460f.1672826282.git.jani.nikula@intel.com
2023-01-19drm/edid: stop passing quirks aroundJani Nikula1-19/+15
Now that quirks are stored in display info, we can just look them up using the connector instead of having to pass them around. Cc: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/d55049dd9b2e48e63103f2dfa49bc9b25dd57f82.1672826282.git.jani.nikula@intel.com
2023-01-19drm/edid: store quirks in display infoJani Nikula2-21/+26
Although the quirks are internal to EDID parsing, it'll be helpful to store them in display info to avoid having to pass them around. This will also help separate adding probed modes (which needs the quirks) from updating display info. Cc: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/819b908f64ad2d158245917f436f24d33a65b95d.1672826282.git.jani.nikula@intel.com
2023-01-19accel/ivpu: Add PM supportJacek Lawrynowicz10-8/+451
- Implement cold and warm firmware boot flows - Add hang recovery support - Add runtime power management support Co-developed-by: Krystian Pradzynski <[email protected]> Signed-off-by: Krystian Pradzynski <[email protected]> Signed-off-by: Jacek Lawrynowicz <[email protected]> Reviewed-by: Jeffrey Hugo <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-19accel/ivpu: Add command buffer submission logicJacek Lawrynowicz8-4/+824
Each of the user contexts has two command queues, one for compute engine and one for the copy engine. Command queues are allocated and registered in the device when the first job (command buffer) is submitted from the user space to the VPU device. The userspace provides a list of GEM buffer object handles to submit to the VPU, the driver resolves buffer handles, pins physical memory if needed, increments ref count for each buffer and stores pointers to buffer objects in the ivpu_job objects that track jobs submitted to the device. The VPU signals job completion with an asynchronous message that contains the job id passed to firmware when the job was submitted. Currently, the driver supports simple scheduling logic where jobs submitted from user space are immediately pushed to the VPU device command queues. In the future, it will be extended to use hardware base scheduling and/or drm_sched. Co-developed-by: Andrzej Kacprowski <[email protected]> Signed-off-by: Andrzej Kacprowski <[email protected]> Signed-off-by: Jacek Lawrynowicz <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Reviewed-by: Jeffrey Hugo <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-19accel/ivpu: Implement firmware parsing and bootingJacek Lawrynowicz8-1/+979
Read, parse and boot VPU firmware image. Co-developed-by: Andrzej Kacprowski <[email protected]> Signed-off-by: Andrzej Kacprowski <[email protected]> Co-developed-by: Krystian Pradzynski <[email protected]> Signed-off-by: Krystian Pradzynski <[email protected]> Signed-off-by: Jacek Lawrynowicz <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Reviewed-by: Jeffrey Hugo <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-19accel/ivpu: Add IPC driver and JSM messagesJacek Lawrynowicz9-0/+1805
The IPC driver is used to send and receive messages to/from firmware running on the VPU. The only supported IPC message format is Job Submission Model (JSM) defined in vpu_jsm_api.h header. Co-developed-by: Andrzej Kacprowski <[email protected]> Signed-off-by: Andrzej Kacprowski <[email protected]> Co-developed-by: Krystian Pradzynski <[email protected]> Signed-off-by: Krystian Pradzynski <[email protected]> Signed-off-by: Jacek Lawrynowicz <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Reviewed-by: Jeffrey Hugo <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-19accel/ivpu: Add GEM buffer object managementJacek Lawrynowicz6-2/+977
Adds four types of GEM-based BOs for the VPU: - shmem - internal - prime All types are implemented as struct ivpu_bo, based on struct drm_gem_object. VPU address is allocated when buffer is created except for imported prime buffers that allocate it in BO_INFO IOCTL due to missing file_priv arg in gem_prime_import callback. Internal buffers are pinned on creation, the rest of buffers types can be pinned on demand (in SUBMIT IOCTL). Buffer VPU address, allocated pages and mappings are released when the buffer is destroyed. Eviction mechanism is planned for future versions. Add two new IOCTLs: BO_CREATE, BO_INFO Signed-off-by: Jacek Lawrynowicz <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Reviewed-by: Jeffrey Hugo <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-19accel/ivpu: Add Intel VPU MMU supportJacek Lawrynowicz9-3/+1479
VPU Memory Management Unit is based on ARM MMU-600. It allows the creation of multiple virtual address spaces for the device and map noncontinuous host memory (there is no dedicated memory on the VPU). Address space is implemented as a struct ivpu_mmu_context, it has an ID, drm_mm allocator for VPU addresses and struct ivpu_mmu_pgtable that holds actual 3-level, 4KB page table. Context with ID 0 (global context) is created upon driver initialization and it's mainly used for mapping memory required to execute the firmware. Contexts with non-zero IDs are user contexts allocated each time the devices is open()-ed and they map command buffers and other workload-related memory. Workloads executing in a given contexts have access only to the memory mapped in this context. This patch is has two main files: - ivpu_mmu_context.c handles MMU page tables and memory mapping - ivpu_mmu.c implements a driver that programs the MMU device Co-developed-by: Karol Wachowski <[email protected]> Signed-off-by: Karol Wachowski <[email protected]> Co-developed-by: Krystian Pradzynski <[email protected]> Signed-off-by: Krystian Pradzynski <[email protected]> Signed-off-by: Jacek Lawrynowicz <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Reviewed-by: Jeffrey Hugo <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-19accel/ivpu: Introduce a new DRM driver for Intel VPUJacek Lawrynowicz14-0/+2272
VPU stands for Versatile Processing Unit and it's a CPU-integrated inference accelerator for Computer Vision and Deep Learning applications. The VPU device consist of following components: - Buttress - provides CPU to VPU integration, interrupt, frequency and power management. - Memory Management Unit (based on ARM MMU-600) - translates VPU to host DMA addresses, isolates user workloads. - RISC based microcontroller - executes firmware that provides job execution API for the kernel-mode driver - Neural Compute Subsystem (NCS) - does the actual work, provides Compute and Copy engines. - Network on Chip (NoC) - network fabric connecting all the components This driver supports VPU IP v2.7 integrated into Intel Meteor Lake client CPUs (14th generation). Module sources are at drivers/accel/ivpu and module name is "intel_vpu.ko". This patch includes only very besic functionality: - module, PCI device and IRQ initialization - register definitions and low level register manipulation functions - SET/GET_PARAM ioctls - power up without firmware Co-developed-by: Krystian Pradzynski <[email protected]> Signed-off-by: Krystian Pradzynski <[email protected]> Signed-off-by: Jacek Lawrynowicz <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Reviewed-by: Jeffrey Hugo <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-19Merge drm/drm-next into drm-misc-nextThomas Zimmermann12491-340403/+639454
Backmerging into drm-misc-next to get DRM accelerator infrastructure, which is required by ipuv driver. Signed-off-by: Thomas Zimmermann <[email protected]>
2023-01-19drm/edid: add helper for HDMI VSDB audio latency field lengthJani Nikula1-7/+11
Add a helper for skipping the HDMI VSDB audio latency fields. There's a functional change for HDMI VSDB blocks that do not respect the spec: "I_Latency_Fields_Present shall be zero if Latency_Fields_Present is zero". We assume this to hold when skipping the latency fields, and ignore non-zero I_Latency_Fields_Present if Latency_Fields_Present is zero. Cc: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/da4293203ef2ddeb0bf66a2bfdbc129ab609c543.1672826282.git.jani.nikula@intel.com
2023-01-19drm/edid: fix and clarify HDMI VSDB audio latency parsingJani Nikula1-8/+19
Add helpers for Latency_Fields_Present and I_Latency_Fields_Present bits, and fix the parsing: - Respect specification regarding "I_Latency_Fields_Present shall be zero if Latency_Fields_Present is zero". - Don't claim latency fields are present if the data block isn't big enough to hold them. Cc: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/80426772a2d2e17bebf6f58d99b7d0cf6260c2d6.1672826282.git.jani.nikula@intel.com
2023-01-19drm/edid: split CTA Y420VDB info and mode parsingJani Nikula1-6/+23
Separate the parsing of display info and modes from the CTA Y420VDB. This is prerequisite work for overall better separation of the two parsing steps. Cc: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/3bc5fe6650a6ce4249803f7192096764ea724e05.1672826282.git.jani.nikula@intel.com
2023-01-19drm/edid: refactor CTA Y420CMDB parsingJani Nikula2-46/+43
Now that we have pre-parsed CTA VDB VICs stored in info->vics, leverage that to simplify CTA Y420CMDB parsing. Move updating the y420_cmdb_modes bitmap to the display info parsing stage, instead of updating it during add modes. This allows us to drop the intermediate y420_cmdb_map from display info, and replace it with a local variable. This is prerequisite work for overall better separation of the two parsing steps (updating display info and adding modes). Cc: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/7a0e5e99a83f203b6a8981d263b89b2bb7d2fe15.1672826282.git.jani.nikula@intel.com
2023-01-19drm/edid: rename struct drm_display_info *display to *infoJani Nikula1-4/+4
Rename the local variable to info for consistency. Cc: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/d35a50c714e21869afcabfafd5c5e590936b791a.1672826282.git.jani.nikula@intel.com
2023-01-19drm/edid: use VIC in AVI infoframe if sink lists it in CTA VDBJani Nikula1-1/+21
Apparently there are HDMI 1.4 compatible displays out there that support VICs from specs later than CTA-861-D, i.e. VIC > 64, although HDMI 1.4 references CTA-861-D only. We try to avoid using VICs from the later specs in the AVI infoframes to avoid upsetting sinks that conform to earlier specs. However, it seems reasonable to do this when the sink claims it supports the VIC. With the pre-parsed list of VICs handy, this is now trivial. References: https://gitlab.freedesktop.org/drm/intel/-/issues/6153 Cc: Ville Syrjälä <[email protected]> Cc: William Tseng <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/775124fd07a5b7892e869becc3dd8dadb328ae5f.1672826282.git.jani.nikula@intel.com
2023-01-19drm/edid: Use the pre-parsed VICsJani Nikula1-60/+32
Now that we have all the VICs in info->vics, use them to simplify access based on VIC index, i.e. on the order of VICs in the EDID, and avoid passing CTA VDB pointers around. This also fixes the highly unlikely scenarios of a) multiple HDMI VSDBs, and b) HDMI VSDB 3D modes using VIC indexes that span across multiple CTA VDBs, and the combination of the two. Cc: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/30f1a97193171e70ec1c26c4b685d8930799b9a6.1672826282.git.jani.nikula@intel.com
2023-01-19drm/edid: parse VICs from CTA VDB earlyJani Nikula3-0/+47
A number of places need access to the VICs. Just parse them early for easy access. Gracefully handle multiple CTA VDBs. It's unlikely to have more than one, but the CTA-861 references "Video Data Block(s)", so err on the safe side. Start parsing them now, convert users in follow-up to have fewer moving parts in one go. Cc: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/7989b2b37837be68953c5d20afd3e93762bfd626.1672826282.git.jani.nikula@intel.com
2023-01-19drm/edid: fix parsing of 3D modes from HDMI VSDBJani Nikula1-12/+10
Commit 537d9ed2f6c1 ("drm/edid: convert add_cea_modes() to use cea db iter") inadvertently moved the do_hdmi_vsdb_modes() call within the db iteration loop, always passing NULL as the CTA VDB to do_hdmi_vsdb_modes(), skipping a lot of stereo modes. Move the call back outside of the loop. This does mean only one CTA VDB and HDMI VSDB combination will be handled, but it's an unlikely scenario to have more than one of either block, and it was not accounted for before the regression either. Fixes: 537d9ed2f6c1 ("drm/edid: convert add_cea_modes() to use cea db iter") Cc: <[email protected]> # v6.0+ Cc: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/cf159b8816191ed595a3cb954acaf189c4528cc7.1672826282.git.jani.nikula@intel.com
2023-01-19drm/edid: fix AVI infoframe aspect ratio handlingJani Nikula1-9/+12
We try to avoid sending VICs defined in the later specs in AVI infoframes to sinks that conform to the earlier specs, to not upset them, and use 0 for the VIC instead. However, we do this detection and conversion to 0 too early, as we'll need the actual VIC to figure out the aspect ratio. In particular, for a mode with 64:27 aspect ratio, 0 for VIC fails the AVI infoframe generation altogether with -EINVAL. Separate the VIC lookup from the "filtering", and postpone the filtering, to use the proper VIC for aspect ratio handling, and the 0 VIC for the infoframe video code as needed. Reported-by: William Tseng <[email protected]> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6153 References: https://lore.kernel.org/r/[email protected] Cc: <[email protected]> Cc: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/c3e78cc6d01ed237f71ad0038826b08d83d75eef.1672826282.git.jani.nikula@intel.com
2023-01-19vc4: fix build failure in vc4_dsi_dev_probe()Arnd Bergmann1-0/+2
The bridge->of_node field is defined inside of an #ifdef, which results in a build failure when compile-testing the vc4_dsi driver without CONFIG_OF: drivers/gpu/drm/vc4/vc4_dsi.c: In function 'vc4_dsi_dev_probe': drivers/gpu/drm/vc4/vc4_dsi.c:1822:20: error: 'struct drm_bridge' has no member named 'of_node' 1822 | dsi->bridge.of_node = dev->of_node; Add another #ifdef in the place it is used in. Alternatively we could consider dropping the #ifdef in the struct definition and all other users. Fixes: 78df640394cd ("drm/vc4: dsi: Convert to using a bridge instead of encoder") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-19drm/connector: fix a kernel-doc bad line warningRandy Dunlap1-1/+1
Building the kernel documentation causes this warning 7 times. Fix it by adding a " *" line instead of a blank line. drivers/gpu/drm/drm_connector.c:1849: warning: bad line: Fixes: 7d63cd8526f1 ("drm/connector: Add TV standard property") Signed-off-by: Randy Dunlap <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Maarten Lankhorst <[email protected]> CC: Thomas Zimmermann <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: [email protected] Reviewed-by: Simon Ser <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-19drm/atomic-helper: fix kernel-doc problemsRandy Dunlap1-3/+3
Fix a kernel-doc warning and other kernel-doc formatting for drm_atomic_helper_connect_tv_check(). drivers/gpu/drm/drm_atomic_state_helper.c:560: warning: Cannot understand * @drm_atomic_helper_connector_tv_check: Validate an analog TV connector state on line 560 - I thought it was a doc line Fixes: 5a28cefda3a9 ("drm/atomic-helper: Add an analog TV atomic_check implementation") Signed-off-by: Randy Dunlap <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Maarten Lankhorst <[email protected]> CC: Thomas Zimmermann <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: [email protected] Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-19drm: bridge: ldb: Warn if LDB clock does not match requested link frequencyAlexander Stein1-4/+19
The LDB clock needs to be exactly 7-times the pixel clock used by the display. Signed-off-by: Alexander Stein <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-19dt-bindings: display: bridge: renesas,rzg2l-mipi-dsi: Document RZ/V2L supportBiju Das1-0/+1
Document RZ/V2L DSI bindings. RZ/V2L MIPI DSI is identical to one found on the RZ/G2L SoC. No driver changes are required as generic compatible string "renesas,rzg2l-mipi-dsi" will be used as a fallback. Signed-off-by: Biju Das <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-19drm/bridge: sii902x: Use dev_err_probeAlexander Stein1-1/+2
This helps figuring out why the device probe is deferred. Signed-off-by: Alexander Stein <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-19drm/bridge: sii902x: Allow reset line to be tied to a sleepy GPIO controllerWadim Egorov1-2/+2
Switch to gpiod_set_value_cansleep() in sii902x_reset(). This is relevant if the reset line is tied to a I2C GPIO controller. Signed-off-by: Wadim Egorov <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-19drm/panel: vtdr6130: Use 16-bit brightness functionRichard Acayan1-4/+1
This panel communicates brightness in big endian. This is not a quirk of the panels themselves, but rather, a part of the MIPI standard. Use the new mipi_dsi_dcs_set_display_brightness_large() function that properly handles 16-bit brightness instead of bypassing the brightness functions entirely. Signed-off-by: Richard Acayan <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Tested-by: Neil Armstrong <[email protected]> # on SM8550-MTP Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-19drm/panel: sofef00: Use 16-bit brightness functionRichard Acayan1-7/+2
These panels communicate brightness in big endian. This is not a quirk of the panels themselves, but rather, a part of the MIPI standard. Use the new mipi_dsi_dcs_set_display_brightness_large() function that properly handles 16-bit brightness instead of doing special processing of the brightness values. Signed-off-by: Richard Acayan <[email protected]> Tested-by: Caleb Connolly <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-19drm/mipi-dsi: Fix byte order of 16-bit DCS set/get brightnessDaniel Mentz2-0/+56
The MIPI DCS specification demands that brightness values are sent in big endian byte order. It also states that one parameter (i.e. one byte) shall be sent/received for 8 bit wide values, and two parameters shall be used for values that are between 9 and 16 bits wide. Add new functions to properly handle 16-bit brightness in big endian, since the two 8- and 16-bit cases are distinct from each other. [richard: use separate functions instead of switch/case] [richard: split into 16-bit component] Fixes: 1a9d759331b8 ("drm/dsi: Implement DCS set/get display brightness") Signed-off-by: Daniel Mentz <[email protected]> Link: https://android.googlesource.com/kernel/msm/+/754affd62d0ee268c686c53169b1dbb7deac8550 [richard: fix 16-bit brightness_get] Signed-off-by: Richard Acayan <[email protected]> Tested-by: Caleb Connolly <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-18drm/amdgpu: allow multipipe policy on ASICs with one MECLang Yu1-0/+3
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 <[email protected]> Reviewed-by: Aaron Liu <[email protected]> Reviewed-by: Yifan Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.