- Feb 03, 2025
-
-
Thomas Zimmermann authoredVBIOS mode tables are terminated by an entry with a refresh rate of 0xff. The code is hard to read and fragile to use. Therefore create an empty entry with AST_VBIOS_MODE_INVALID to terminate each mode list. Stop at the invalid entry when searching for modes in the tables. Instead of testing for refresh == 0xff, test with a helper function if the mode's size and refresh have meaningful values. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-10-tzimmermann@suse.de
-
Thomas Zimmermann authored
The ast driver looks up supplied display modes from an internal list of display modes supported by the VBIOS. Do not use the crtc_-prefixed display values from struct drm_display_mode for looking up the VBIOS mode. The fields contain raw values that the driver programs to hardware. They are affected by display settings like double-scan or interlace. Instead use the regular vdisplay and hdisplay fields for lookup. As the programmed values can now differ from the values used for lookup, set struct drm_display_mode.crtc_vdisplay and .crtc_hdisplay from the VBIOS mode. Signed-off-by:
-
Thomas Zimmermann authored
The ast driver matches DRM display modes against an internal list of modes supported by the VBIOS. Matching H/V sync flags between modes is preferred, but optional. If sync flags are not matching, the driver would program the VBIOS settings to hardware and let the display handle the difference. DRM modes are generated from attached displays or standard mode lines. Therefore differences to the VBIOS modes are not just cosmetical, but signal possible incompatibility with the display hardware. Hence make matching H/V sync flags mandatory. If the VBIOS does not support a certain mode, we should report it as unsupported. Note that the VBIOS mode tables all appear to refer to standard modes. (If sync flags really make no difference to the VBIOS, the ast driver shouldn't match them in the first place.) Signed-off-by:
-
Thomas Zimmermann authored
Detect support for 1920x1200 (WUXGA) in ast_detect_widescreen(). The flag is cleared by default. The test logic has been taken from existing code in ast_crtc_helper_mode_valid(). The code in that function is being replaced by the new flag. v2: - move shared detection code into helper (Jocelyn) Signed-off-by:
-
Thomas Zimmermann authored
Detect support for 1920x1080 (FullHD) in ast_detect_widescreen(). The flag is cleared by default. The test logic has been taken from existing code in ast_crtc_helper_mode_valid(). The code in that function is being replaced by the new flag. For Gen3, a new branch duplicates the Gen2 logic and adds a test for AST2200. Gen2 adds a test for AST2100. v2: - use fullhd flag for setting max width/height Signed-off-by:
-
Thomas Zimmermann authored
Testing for support of widescreen modes mixes up various hardware Gens. First branch by hardware Gen, then do specific tests for each Gen. By default, widesscreen support is disabled. Later patches will add more specific tests for each Gen. v2: - move shared detection code into helper (Jocelyn) Signed-off-by:
-
Thomas Zimmermann authored
The flag support_wide_screen in struct ast_device selects devices that support resolutions of at least 1680x1050 (WSXGA+). Name it accordingly. Signed-off-by:
-
Thomas Zimmermann authored
Rename variables and register constants to align with the programming manual. Add new constants where necessary. Signed-off-by:
-
Thomas Zimmermann authored
The resolution 1152x864 has a ratio of 4:3 and is already handled as such. Remove it from the list of widescreen resolutions. Signed-off-by:
-
Recovery work doesn't need to be bound to any specific CPU, so move it to unbound workqueue to improve execution time and system latency. Reviewed-by:
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Signed-off-by:
Karol Wachowski <karol.wachowski@intel.com> Reviewed-by:
Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by:
-
Recovery now works on fpga. JSM state dump timeout needs to be really long for the new fpga model releases. Enable punit on fpga. Reviewed-by:
Tomasz Rusinowicz <tomasz.rusinowicz@intel.com> Reviewed-by:
-
Hardware scheduling (HWS) is supposed to be supported on all existing platform with recent FW including pre-silicon ones. Turn on HWS by default. Reviewed-by:
-
Move the ivpu_mmu_discard_events() function to the common portion of the abort work function. This ensures it is called only once, even if there are no faulty contexts in context_xa, to guarantee that MMU events are discarded and new events are not missed. Reviewed-by:
-
Jacek Ławrynowicz authoredCall pm_runtime_mark_last_busy() in top half of IRQ handler to prevent device from being runtime suspended before bottom half is executed on a workqueue. Reviewed-by:
-
Jacek Ławrynowicz authored
Introduces the capability to simulate hardware faults for testing purposes. The new `fail_hw` fault can be injected in `ivpu_hw_reg_poll_fld()`, which is used in various parts of the driver to wait for the hardware to reach a specific state. This allows to test failures during NPU boot and shutdown, IPC message handling and more. Fault injection can be enabled using debugfs or a module parameter. Reviewed-by:
Maciej Falkowski <maciej.falkowski@linux.intel.com> Reviewed-by:
-
- Jan 31, 2025
-
-
Jeffrey Hugo authored
Add basic support for the new AIC200 product. The PCIe Device ID is 0xa110. With this, we can turn on the lights for AIC200 by leveraging much of the existing driver. Co-developed-by:
Youssef Samir <quic_yabdulra@quicinc.com> Signed-off-by:
Lizhi Hou <lizhi.hou@amd.com> Acked-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250117170943.2643280-8-quic_jhugo@quicinc.com
-
Jeffrey Hugo authored
As the number of cards supported by the driver grows, their configurations will differ. The driver needs to become more dynamic to support these configurations. Currently, each card may differ in the exposed BARs, the regions they map to, and the family. Create config structs for each card, and let the driver configure the qaic_device struct based on the configurations passed to the driver. Co-developed-by:
-
During the initialization of the qaic device, pci_select_bars() is used to fetch a bitmask of the BARs exposed by the device. On devices that have Virtual Functions capabilities, the bitmask includes SR-IOV BARs. Use a mask to filter out SR-IOV BARs if they exist. Signed-off-by:
-
AIC200 device will support MSI-X while AIC100 devices will keep using MSI. pci_alloc_irq_vectors() will try to allocate MSI-X vectors if it is supported by the target device, otherwise, it will fallback to MSI. Add support for MSI-X vectors allocation for AIC200 devices. Signed-off-by:
-
Devices use 1 MSI vector for the MHI controller and as many vectors as the DMA bridge channels on the device. During the probing of the device, the driver allocates 32 MSI vectors, which is usually more than what is needed for AIC100 devices, which is wasting resources. Allocate only the needed number of MSI vectors per device. Signed-off-by:
Troy Hanson <quic_thanson@quicinc.com> Reviewed-by:
-
Currently, MHI host only performs firmware transfer via BHI in PBL and BHIe from SBL. To support BHIe transfer directly from PBL, a policy needs to be added. With this policy, BHIe will be used to transfer firmware in PBL if the MHI controller has BHIe regs, sets seg_len, and does not set fbc_download. The intention is to transfer firmware using BHIe in PBL without further BHIe transfers in SBL. Signed-off-by:
Matthew Leung <quic_mattleun@quicinc.com> Reviewed-by:
-
Refactor the firmware loading code to have distinct helper functions for BHI and BHIe operations. This lays the foundation for separating the firmware loading protocol from the firmware being loaded and the EE it is loaded in. Signed-off-by:
-
- Jan 29, 2025
-
-
Jocelyn Falempe authored
ast_dp_is_connected() used to also check for link training success to report the DP connector as connected. Without this check, the physical_status is always connected. So if no monitor is present, it will fail to read the EDID and set the default resolution to 640x480 instead of 1024x768. Signed-off-by:
Jerry Hoemann <jerry.hoemann@hpe.com> Tested-by:
Jose Lopez <jose.lopez@hpe.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Dave Airlie <airlied@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.12+ Reviewed-by:
-
- Jan 28, 2025
-
-
Properties with variable number of items per each device are expected to have widest constraints in top-level "properties:" block and further customized (narrowed) in "if:then:". Add missing top-level constraints for clocks, clock-names, interrupts, resets, reset-names, renesas,cmms and renesas,vsps. Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Signed-off-by:
-
Each variable-length property like interrupts or resets must have fixed constraints on number of items for given variant in binding. The clauses in "if:then:" block should define both limits: upper and lower. Acked-by:
-
Tomi Valkeinen authoredUpdate drm/rcar-du maintainer entries: * Add myself as drm/rcar-du maintainer. * Update Laurent's email to include +renesas. * Switch Kieran from a maintainer to reviewer. * Change rcar-du to be under drm-misc umbrella. Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250128-rcar-du-maintainers-v2-1-4a3860a3e1ef@ideasonboard.com
-
- Jan 27, 2025
-
-
Noralf Trønnes authored
Remove myself as maintainer for gud, mi0283qt, panel-mipi-dbi and repaper. My fatigue illness has finally closed the door on doing development of even moderate complexity so it's sad to let this go. Acked-by:
Simona Vetter <simona.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20250123-remove-myself-as-maintainer-v1-1-cc3ab7cd98ae@tronnes.org Signed-off-by:
Noralf Trønnes <noralf@tronnes.org>
-
- Jan 26, 2025
-
-
The ADV7511 chip allows 24 bits samples max in I2S mode, excepted for direct AES3 mode (SNDRV_PCM_FORMAT_IEC958_SUBFRAME_LE format). However the HDMI codec exposes S32_LE format as supported. Adapt ADV7511 HDMI I2S format list to expose formats actually supported. Signed-off-by:
Olivier Moysan <olivier.moysan@foss.st.com> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250108170356.413063-4-olivier.moysan@foss.st.com Signed-off-by:
-
Currently the hdmi-codec driver registers all the formats that are allowed on the I2S bus. Add i2s_formats field to codec data, to allow the hdmi codec client to refine the list of the audio I2S formats actually supported. Signed-off-by:
Mark Brown <broonie@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250108170356.413063-3-olivier.moysan@foss.st.com Signed-off-by:
-
Set no_i2s_capture and no_spdif_capture flags in hdmi_codec_pdata structure to report that the ADV7511 HDMI bridge does not support i2s or spdif audio capture. Signed-off-by:
-
- Jan 24, 2025
-
-
Zhi Wang authored
As the GSP message recv path is able to handle the return of large GSP message, consume the return of large GSP message in the sending path. Signed-off-by:
Zhi Wang <zhiw@nvidia.com> Signed-off-by:
Danilo Krummrich <dakr@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250124182958.2040494-16-zhiw@nvidia.com
-
Zhi Wang authored
The max GSP message element size is 16 pages (including the headers). To send a message larger than 16 pages, nvkm should split it into multiple and send them accordingly. The first element has the expected function number, while the rest are sent with function number as NV_VGPU_MSG_FUNCTION_CONTINUATION_RECORD. GSP consumes the elements from the cmdq and always writes the result back to the msgq. The result is also formed as split elements. However, nvkm is able to split the large GSP message and send them, but totally not aware of handling the return of the large GSP message, which are the split elements in the msgq. Thus, it keeps dumping the unknown RPC messages from msgq, which is actually CONTINUATION_RECORD message, discard them unexpectedly. Thus, the caller will not be able to consume the result from GSP. Introduce the handling of the return of large GSP message on the msgq path. Slightly re-factor the low-level part of msg receiving routines. Merge the split elements back into a large element before handling it to the upper level. Thus, the upper-level of GSP RPC APIs don't need to be heavily changed. Signed-off-by:
-
Zhi Wang authored
Prepare for supporting receive the large GSP RPC message. Factor out r535_gsp_msgq_recv_one_elem(). Fold its params into a data structure of params. Move the allocation of the GSP RPC message to its caller. Refine the variable names in the re-factor. No functional change is intended. Signed-off-by:
-
Zhi Wang authored
To receive a GSP message queue element from the GSP status queue, the driver needs to make sure there are available elements in the queue. The previous r535_gsp_msgq_wait() consists of three functions, which is a little too complicated for a single function: - wait for an available element. - peek the message element header in the queue. - recevice the element from the queue. Factor out r535_gsp_msgq_peek() and divide the functions in r535_gsp_msgq_wait() into three functions. No functional change is intended. Cc: Danilo Krummrich <dakr@kernel.org> Signed-off-by:
-
Zhi Wang authored
Refine the name to align with the terms in the kernel doc. No functional change is intended. Signed-off-by:
-
Zhi Wang authored
The variable "msg" in r535_gsp_msg_recv() actually means the GSP RPC. Refine the names to align with the terms in the kernel doc. No functional change is intended. Signed-off-by:
-
Zhi Wang authored
The variable names in r535_gsp_rpc_push() are quite confusing and some of them are not representing what they really are. Update the names and explanations in the decoder section of the kernel doc. Refine the names to align with the terms in the kernel doc. No functional change is intended. Signed-off-by:
-
Zhi Wang authored
There has been a GSP_MSG_MAX_SIZE which represents the max size of a GSP message element header. Use it instead of a magic number. No functional change is intended. Signed-off-by:
-
Zhi Wang authored
The macro GSP_MSG_MAX_SIZE refers to another macro that doesn't exist. It represents the max GSP message element size. Fix the broken marco so it can be used to replace some magic numbers in the code. Signed-off-by:
-
Zhi Wang authored
The name "argc" has different meanings in different functions. To improve the readability, it's better to refine it to a name that reflects what it represents. Rename "argc" to what it represents. Add terms in the decoder section to explain their meaning. No functional change is intended. Signed-off-by:
-
