summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-04-17dt-bindings: display: simple: Add Tianma P0700WXF1MBAA panelLuca Ceresoli
Add the Tianma Micro-electronics P0700WXF1MBAA 7.0" LVDS LCD TFT panel. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://lore.kernel.org/r/20250411-tianma-p0700wxf1mbaa-v3-1-acbefe9ea669@bootlin.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250411-tianma-p0700wxf1mbaa-v3-1-acbefe9ea669@bootlin.com
2025-04-17drm/panthor: Fix the panthor_gpu_coherency_init() error pathBoris Brezillon
The panthor_gpu_coherency_init() call has been moved around, but the error path hasn't been adjusted accordingly. Make sure we undo what has been done before this call in case of failure. Fixes: 7d5a3b22f5b5 ("drm/panthor: Call panthor_gpu_coherency_init() after PM resume()") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/dri-devel/4da470aa-4f84-460e-aff8-dabc8cc4da15@stanley.mountain/T/#t Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://lore.kernel.org/r/20250414130120.581274-1-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-04-17drm/udl: Set error code in udl_init()Dan Carpenter
Return -ENOMEM if udl_alloc_urb_list() fails. Don't return success. Fixes: fb10144ba426 ("drm/udl: Support adapters without firmware descriptor") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/Z_-P4N4_U-xTC9-O@stanley.mountain
2025-04-17drm/bridge: dw-hdmi: Avoid including uapi headersAndy Yan
It is not recommended for drivers to include UAPI header directly. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250411115941.318558-1-andyshrk@163.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-04-17drm/bridge: select DRM_KMS_HELPER for AUX_BRIDGEDmitry Baryshkov
The aux bridge uses devm_drm_of_get_bridge() from the panel bridge (and correctly selects DRM_PANEL_BRIDGE). However panel bridge is not a separate module, it is compiled into the drm_kms_helper.o. Select DRM_KMS_HELPER too to express this dependency. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250411-aux-select-kms-v1-1-c4276f905a56@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-04-16drm/edid: Refactor DisplayID timing block structsEgor Vorontsov
Using le16 instead of u8[2]. Suggested-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Egor Vorontsov <sdoregor@sdore.me> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/a7967d7884d48b15ca08ae78d687e73124f0ba04.1744708239.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-16drm/edid: Implement DisplayID Type IX & X timing blocks parsingEgor Vorontsov
Some newer high refresh rate consumer monitors (including those by Samsung) make use of DisplayID 2.1 timing blocks in their EDID data, notably for their highest refresh rate modes. Such modes won't be available as of now. Implement partial support for such blocks in order to enable native support of HRR modes of most such monitors for users without having to rely on EDID patching/override (or need thereof). Closes: https://gitlab.freedesktop.org/drm/misc/kernel/-/issues/55 Suggested-by: Maximilian Boße <max@bosse.io> Signed-off-by: Egor Vorontsov <sdoregor@sdore.me> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/d795d27c6f60596df402ff151ce29938e2ad4f53.1744708239.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-16drm/panel: boe-bf060y8m-aj0: transition to mipi_dsi wrapped functionsTejas Vipin
Changes the boe-bf060y8m-aj0 panel to use multi style functions for improved error handling. Additionally the MIPI_DSI_MODE_LPM flag is set after the off commands are run in boe_bf060y8m_aj0_off regardless of any failures, and regulators are disabled if the boe_bf060y8m_aj0_on call in boe_bf060y8m_aj0_prepare fails. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Tejas Vipin <tejasvipin76@gmail.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250413035959.255842-1-tejasvipin76@gmail.com
2025-04-16gpu: drm: xlnx: zynqmp_dp: Use dev_err_probe()Zhang Enpei
Replace the open-code with dev_err_probe() to simplify the code. Signed-off-by: Zhang Enpei <zhang.enpei@zte.com.cn> Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20250402193852834atJ7eho66TlnKOIMSvpfr@zte.com.cn Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2025-04-16drm: xlnx: zynqmp_dpsub: use snd_soc_dummy_dlcKuninori Morimoto
struct zynqmp_dp_audio :: components has codec component, but it is used as dummy DAI. OTOH, We can use common snd_soc_dummy_dlc. Let's use common dummy_dlc instead of own component. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://lore.kernel.org/r/87ecxvr25o.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2025-04-16drm/virtio: Support drm_panic with non-vmapped shmem BORyosuke Yasuoka
Pass array of pages of the scanout buffer to shmem BO, allowing drm_panic to work even if the BO is not vmapped. Link: https://lore.kernel.org/all/20250407140138.162383-3-jfalempe@redhat.com/ Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> [dmitry.osipenko@collabora.com: rebased on misc-next, fixed minor checkpatch warn] [dmitry.osipenko@collabora.com: changed commit message to use link tag] Link: https://lore.kernel.org/all/20250412132012.291837-1-ryasuoka@redhat.com/
2025-04-16drm/virtio: Use dma_buf from GEM object instanceThomas Zimmermann
Avoid dereferencing struct drm_gem_object.import_attach for the imported dma-buf. The dma_buf field in the GEM object instance refers to the same buffer. Prepares to make import_attach optional. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://lore.kernel.org/r/20250414131507.566072-3-tzimmermann@suse.de
2025-04-16drm/virtio: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. The helper tests the dma_buf itself while import_attach is just an artifact of the import. Prepares to make import_attach optional. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://lore.kernel.org/r/20250414131507.566072-2-tzimmermann@suse.de
2025-04-15drm/imagination: Add support for TI AM68 GPUMatt Coster
Since we already added a generic compatible string for all IMG Rogue GPUs ("img,img-rogue"), all that's needed here is to link the appropriate firmware for the BXS-4-64 GPU in the AM68. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-16-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Use cached memory with dma_coherentMatt Coster
The TI k3-j721s2 platform does not allow us to use uncached memory (which is what the driver currently does) without disabling cache snooping on the AXI ACE-Lite interface, which would be too much of a performance hit. Given the platform is dma-coherent, we can simply force all device-accessible memory allocations through the CPU cache. In fact, this can be done whenever the dma_coherent attribute is present. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-15-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Add RISC-V firmware processor supportSarah Walker
Newer PowerVR GPUs (such as the BXS-4-64 MC1) use a RISC-V firmware processor instead of the previous MIPS or META. The current version of this patch depends on a patch[1] which exists in drm-misc-fixes, but has not yet made it back to drm-misc-next (the target of this patch). That patch adds the function pvr_vm_unmap_obj() which is used here. [1]: https://lore.kernel.org/r/20250226-hold-drm_gem_gpuva-lock-for-unmap-v2-1-3fdacded227f@imgtec.com Signed-off-by: Sarah Walker <sarah.walker@imgtec.com> Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-14-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Move ELF fw utils to common fileMatt Coster
Currently only MIPS firmware processors use ELF-formatted firmware. When adding support for RISC-V firmware processors, it will be useful to have ELF handling functions ready to go. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-13-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Use callbacks for fw irq handlingMatt Coster
This allows for more versatility in checking and clearing firmware registers used for interrupt handling. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-12-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Use a lookup table for fw defsMatt Coster
With more than two firmware processor types, the if/else chain in pvr_fw_init() gets a bit ridiculous. Use a static array indexed on pvr_fw_processor_type (which is now a proper enum instead of #defines) instead. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-11-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Make has_fixed_data_addr a valueMatt Coster
This is currently a callback function which takes no parameters; there's no reason for this so let's make it a straightforward value in pvr_fw_defs. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-10-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Rename event_mask -> status_maskMatt Coster
Now that enable_reg isn't used, rename the previously shared event_mask to status_mask since it's only used with status_reg. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-9-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Remove firmware enable_regMatt Coster
After a previous commit ("drm/imagination: Mask GPU IRQs in threaded handler"), this register is now only used to enable firmware interrupts at start-of-day. This is, however, unnecessary since they are enabled by default. In addition, the soon-to-be-added RISC-V firmware processors do not have an equivalent register. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-8-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Handle Rogue safety event IRQsAlessio Belle
Extend interrupt handling logic to check for safety event IRQs, then clear and handle them in the IRQ handler thread. Safety events need to be checked and cleared with a different set of GPU registers than those the IRQ handler has been using so far. Only two safety events need to be handled on the host: FW fault (ECC error correction or detection) and device watchdog timeout. Handling right now simply consists of clearing any error and logging the event. If either of these events results in an unrecoverable GPU or FW, the driver will eventually attempt to recover from it e.g. via pvr_power_reset(). Note that Rogue GPUs may send interrupts to the host for all types of safety events, not just the two above. For events not handled by the host, clearing the associated interrupt is sufficient. Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-7-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Mask GPU IRQs in threaded handlerAlessio Belle
Pass IRQF_ONESHOT flag to request_threaded_irq(), so that interrupts will be masked by the kernel until the end of the threaded IRQ handler. Since the calls to pvr_fw_irq_enable() and pvr_fw_irq_disable() are now redundant, remove them. Interrupts to the host from the soon-to-be-added RISC-V firmware processors cannot be masked in hardware. This change allows us to continue using the threaded handler in GPUs with a RISC-V firmware. For simplicity, the same approach is taken for all firmware processors. Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-6-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Add power domain controlMatt Coster
The first supported GPU only used a single power domain so this was automatically handled by the device runtime. In order to support multiple power domains, they must be enumerated from devicetree and linked to both the GPU device and each other to ensure correct power sequencing at start time. For all Imagination Rogue GPUs, power domains are named "a", "b", etc. and the sequence A->B->... is always valid for startup with the reverse true for shutdown. Note this is not always the *only* valid sequence, but it's simple and does not require special-casing for different GPU power topologies. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-5-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Use new generic compatible stringMatt Coster
Follow-on from the companion dt-bindings change ("dt-bindings: gpu: img: More explicit compatible strings"), deprecating "img,img-axe" in favour of the more explicit combination of "img,img-rogue" and "img,img-axe-1-16m". Since all relevant details are interrogated from the device at runtime, we can match on the generic "img,img-rogue" and avoid adding more entries with NULL data members (barring hardware quirks). Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-4-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Update register defs for newer GPUsAlessio Belle
Update the register define header to a newer version that covers more recent GPUs, including BXS-4-64. Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-3-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15dt-bindings: gpu: img: Add BXS-4-64 devicetree bindingsMatt Coster
Unlike AXE-1-16M, BXS-4-64 uses two power domains. Like the existing AXE-1-16M integration, BXS-4-64 uses the single clock integration in the TI k3-j721s2. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-2-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15dt-bindings: gpu: img: Future-proofing enhancementsMatt Coster
The first compatible strings added for the AXE-1-16M are not sufficient to accurately describe all the IMG Rogue GPUs. The current "img,img-axe" string refers to the entire family of Series AXE GPUs, but this is primarily a marketing term and does not denote a level of hardware similarity any greater than just "Rogue". The more specific "img,img-axe-1-16m" string refers to individual AXE-1-16M GPU. For example, unlike the rest of the Series AXE GPUs, the AXE-1-16M only uses a single power domain. The situation is actually slightly worse than described in the first paragraph, since many "series" (such as Series BXS found in the TI AM68 among others and added later in this series) contain cores with both Rogue and Volcanic architectures. Besides attempting to move away from vague groupings defined only by marketing terms, we want to draw a line between properties inherent to the IP core and choices made by the silicon vendor at integration time. For instance, the number of power domains is a property of the IP core, whereas the decision to use one or multiple clocks is a vendor one. In the original compatible strings, we must use "ti,am62-gpu" to constrain both of these properties since the number of power domains cannot be fixed for "img,img-axe". Work is currently underway to add support for volcanic-based Imagination GPUs, for which bindings will be added in "img,powervr-volcanic.yaml". As alluded to previously, the split between rogue and volcanic cores is non-obvious at times, so add a generic top-level "img,img-rogue" compatible string here to allow for simpler differentiation in devicetrees without referring back to the bindings. The currently supported GPU (AXE-1-16M) only requires a single power domain. Subsequent patches will add support for BXS-4-64 MC1, which has two power domains. Add infrastructure now to allow for this. Also allow the dma-coherent property to be added to IMG Rogue GPUs, which are DMA devices. The decision for coherency is made at integration time and this property should be applied wherever it accurately describes the vendor integration. Note that the new required properties for power domains are conditional on the new base compatible string to avoid an ABI break. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-1-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15Merge drm/drm-next into drm-misc-nextThomas Zimmermann
Backmerging to get fixes from v6.15-rc2 into drm-misc-next. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2025-04-15drm/display: hdmi: provide central data authority for ACR paramsDmitry Baryshkov
HDMI standard defines recommended N and CTS values for Audio Clock Regeneration. Currently each driver implements those, frequently in somewhat unique way. Provide a generic helper for getting those values to be used by the HDMI drivers. The helper is added to drm_hdmi_helper.c rather than drm_hdmi_audio.c since HDMI drivers can be using this helper function even without switching to DRM HDMI Audio helpers. Note: currently this only handles the values per HDMI 1.4b Section 7.2 and HDMI 2.0 Section 9.2.1. Later the table can be expanded to accommodate for Deep Color TMDS char rates per HDMI 1.4 Appendix D and/or HDMI 2.0 / 2.1 Appendix C). Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250408-drm-hdmi-acr-v2-1-dee7298ab1af@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-04-15drm/bridge: anx7625: Use devm_pm_runtime_enable()Chen-Yu Tsai
The anx7625 driver is open coding what devm_pm_runtime_enable() does. Switch to the common helper instead. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20250409093814.3977025-1-wenst@chromium.org Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
2025-04-15Merge tag 'drm-intel-next-2025-04-11' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next Cross-subsystem Changes: - Update GVT MAINTAINERS (Jani) Driver Changes: - Updates for xe3lpd display (Gustavo) - Fix link training interrupted by HPD pulse (Imre) - Watermark bound checks for DSC (Ankit) - VRR Refactor and other fixes and improvements (Ankit) - More conversions towards intel_display struct (Gustavo, Jani) - Other clean-up patches towards a display separation (Jani) - Maintain asciibetical order for HAS_* macros (Ankit) - Fixes around probe/initialization (Janusz) - Fix build and doc build issue (Yue, Rodrigo) - DSI related fixes (Suraj, William, Jani) - Improve DC6 entry counter (Mohammed) - Fix xe2hpd memory type identification (Vivek) - PSR related fixes and improvements (Animesh, Jouni) - DP MST related fixes and improvements (Imre) - Fix scanline_offset for LNL+/BMG+ (Ville) - Some gvt related fixes and changes (Ville, Jani) - Some PLL code adjustment (Ville) - Display wa addition (Vinod) - DRAM type logging (Lucas) - Pimp the initial FB readout (Ville) - Some sagv/bw cleanup (Ville) - Remove i915_display_capabilities debugfs entry (Jani) - Move PCH type to display caps debugfs entry (Jani) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/Z_kTqPX5Mjruq1pL@intel.com
2025-04-14drm/vmwgfx: Use dma_buf from GEM object instanceThomas Zimmermann
Avoid dereferencing struct drm_gem_object.import_attach for the imported dma-buf. The dma_buf field in the GEM object instance refers to the same buffer. Prepares to make import_attach optional. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Zack Rusin <zack.rusin@broadcom.com> Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com> Reviewed-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://lore.kernel.org/r/20250317131923.238374-15-tzimmermann@suse.de
2025-04-14drm/vmwgfx: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. The helper tests the dma_buf itself while import_attach is just an artifact of the import. Prepares to make import_attach optional. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Zack Rusin <zack.rusin@broadcom.com> Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com> Reviewed-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://lore.kernel.org/r/20250317131923.238374-14-tzimmermann@suse.de
2025-04-14drm/panthor: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. The helper tests the dma_buf itself while import_attach is just an artifact of the import. Prepares to make import_attach optional. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Steven Price <steven.price@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250317131923.238374-10-tzimmermann@suse.de
2025-04-14drm/panfrost: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. The helper tests the dma_buf itself while import_attach is just an artifact of the import. Prepares to make import_attach optional. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Rob Herring <robh@kernel.org> Cc: Steven Price <steven.price@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250317131923.238374-9-tzimmermann@suse.de
2025-04-14drm/msm: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. The helper tests the dma_buf itself while import_attach is just an artifact of the import. Prepares to make import_attach optional. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Rob Clark <robdclark@gmail.com> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> Cc: Dmitry Baryshkov <lumag@kernel.org> Cc: Sean Paul <sean@poorly.run> Cc: Marijn Suijten <marijn.suijten@somainline.org> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250317131923.238374-7-tzimmermann@suse.de
2025-04-14drm/etnaviv: Use dma_buf from GEM object instanceThomas Zimmermann
Avoid dereferencing struct drm_gem_object.import_attach for the imported dma-buf. The dma_buf field in the GEM object instance refers to the same buffer. Prepares to make import_attach optional. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: etnaviv@lists.freedesktop.org Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Link: https://lore.kernel.org/r/20250317131923.238374-4-tzimmermann@suse.de
2025-04-14drm/etnaviv: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. The helper tests the dma_buf itself while import_attach is just an artifact of the import. Prepares to make import_attach optional. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: etnaviv@lists.freedesktop.org Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Link: https://lore.kernel.org/r/20250317131923.238374-3-tzimmermann@suse.de
2025-04-14drm/udl: Support adapters without firmware descriptorThomas Zimmermann
Set default limit on the number of pixels for adapters without vendor firmware descriptor. The devices work as expected, they just don't provide any description. If parsing the vendor firmware descriptor fails, the device falls back to the given default limits. Failing to allocate memory is still an error. v2: - fix typo in constant (Patrik) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://lore.kernel.org/r/20250410105948.25463-10-tzimmermann@suse.de
2025-04-14drm/udl: Validate length in vendor-descriptor parserThomas Zimmermann
Rewrite the parser for the vendor firmware descriptor with the following improvements. - Validate the key-value length given in a vendor descriptor against the length of the descriptor. The current code fails to do this and might read more bytes than available. This can lead to out-of-bounds reads of the allocated buffer. - Read raw data with helpers for unaligned data. This allows the code to run on platforms that do now support unaligned memory access by default. - Validate the pixel limit against a default value. The default comes from real-world devices. If the reported number of pixels is significantly above the limit, it is likely invalid. - Drop the obsolete print macros. There is still a warning about invalid firmware descriptors. The rest of the output is bogus. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://lore.kernel.org/r/20250410105948.25463-9-tzimmermann@suse.de
2025-04-14drm/udl: Treat vendor descriptor as u8Thomas Zimmermann
The vendor descriptor is an array of unsigned bytes. It is raw data that is not to be modified. Declare it as 'const u8'. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://lore.kernel.org/r/20250410105948.25463-8-tzimmermann@suse.de
2025-04-14drm/udl: Return error if vendor descriptor is too shortThomas Zimmermann
There need to be least 5 bytes in the vendor descriptor. Return an error otherwise. Also change the branching to early-out on the error. Adjust indention of the rest of the parser function. The original length test expected more than 5 bytes in the vendor descriptor. As a descriptor with no key-value pairs has exactly 5 bytes and is still valid, change the test to accept this case as well. v2 - clarify changes to length test in commit description (Patrik) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://lore.kernel.org/r/20250410105948.25463-7-tzimmermann@suse.de
2025-04-14drm/udl: Handle errors from usb_get_descriptor()Thomas Zimmermann
Reading the vendor descriptor from the udl device can fail with an error, which the current code fails to capture. Store the return value in an integer and test for the error. Abort parsing on errors or treat the value as length on success. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://lore.kernel.org/r/20250410105948.25463-6-tzimmermann@suse.de
2025-04-14drm/udl: The number of pixels is always positiveThomas Zimmermann
Store sku_pixel_limit as type unsigned long instead of int. The number of pixels available is always positive. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://lore.kernel.org/r/20250410105948.25463-5-tzimmermann@suse.de
2025-04-14drm/udl: Improve type safety when using struct udl_deviceThomas Zimmermann
Push upcasts from struct drm_device to struct udl_device outwards in the call chain; cast earlier and call functions with the upcasted value. Improves type safety. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://lore.kernel.org/r/20250410105948.25463-4-tzimmermann@suse.de
2025-04-14drm/udl: Remove unused field gem_lock from struct udl_deviceThomas Zimmermann
Reduce the size of struct udl_device by removing the unused field gem_lock. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://lore.kernel.org/r/20250410105948.25463-3-tzimmermann@suse.de
2025-04-14drm/udl: Remove unused field dev from struct udl_deviceThomas Zimmermann
Reduce the size of struct udl_device by removing the unused field dev. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://lore.kernel.org/r/20250410105948.25463-2-tzimmermann@suse.de
2025-04-14drm/sysfb: Share helpers for screen_info validationThomas Zimmermann
Share efidrm's and vesadrm's validation of struct screen_info in shared helpers. Update the drivers. Most validation helpers test individual values against limits and can be shared as they are. For color formats, a common helper looks up the correct DRM format info from a driver-provided list of color formats. These screen_info helpers are only available if CONFIG_SCREEN_INFO has been selected, as done by efidrm and vesadrm. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250410083834.10810-4-tzimmermann@suse.de
generated by cgit (git 2.34.1) at 2025-07-16 03:23:36 +0000