- 19 Mar, 2024 3 commits
-
-
Nathan Morrisson authored
Add support for the POWERTIP PH128800T006-ZHC01 10.1" (1280x800) LCD-TFT panel. Signed-off-by:
Nathan Morrisson <nmorrisson@phytec.com> Acked-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Link: https://lore.kernel.org/r/20240318161708.1415484-3-nmorrisson@phytec.comSigned-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240318161708.1415484-3-nmorrisson@phytec.com
-
Nathan Morrisson authored
Add POWERTIP PH128800T-006-ZHC01 10.1" LCD-TFT LVDS panel compatible string. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240318161708.1415484-2-nmorrisson@phytec.comSigned-off-by:
-
Laurent Pinchart authored
Commit 00084f0c ("drm: bridge: thc63lvd1024: Switch to use of_graph_get_remote_node()") simplified the thc63lvd1024 driver by replacing hand-rolled code with a helper function. While doing so, it created an error code path at probe time without any error message, potentially causing probe issues that get annoying to debug. Fix it by adding an error message. Fixes: 00084f0c ("drm: bridge: thc63lvd1024: Switch to use of_graph_get_remote_node()") Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
-
- 18 Mar, 2024 9 commits
-
-
Sui Jingfeng authored
To reduce boilerplate, use of_graph_get_remote_node() helper instead of the hand-rolling code. Signed-off-by:
Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240316172800.1168390-1-sui.jingfeng@linux.devSigned-off-by:
-
Sui Jingfeng authored
The calling of of_device_is_available() in it66121_probe() is duplicated, as the of_graph_get_remote_node() has already do the check for us. There is no need to call it again, thus delete the later one. Signed-off-by:
-
Sui Jingfeng authored
To reduce boilerplate, use of_graph_get_remote_node() helper instead of the hand-rolling code. Signed-off-by:
-
Sui Jingfeng authored
If a specific design doesn't wire IT66121's interrupt signal output pin up to the display controller side, then we should not register the interrupt handler. Such a decision is valid usage, as we can fall back to polling mode. So, don't make the assumption that a specific board always supports HPD. Carry out a sanity check on 'client->irq' before using it, fall back to polling mode if client->irq < 0 is true. Such a design increases the overall flexibility. Signed-off-by:
-
Laurent Pinchart authored
The ilitek-ili9881c controls the reset GPIO using the non-sleeping gpiod_set_value() function. This complains loudly when the GPIO controller needs to sleep. As the caller can sleep, use gpiod_set_value_cansleep() to fix the issue. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Laurent Pinchart authored
Add support for the Startek KD050HDFIA020-C020A panel. The init table comes from the Compulab BSP ([1]). [1] https://github.com/compulab-yokneam/meta-bsp-imx8mp/blob/ucm-imx8m-plus-r1.1/recipes-kernel/linux/compulab/imx8mp/0000-compulab-imx8m-plus-Add-boards-support.patchSigned-off-by:
-
Laurent Pinchart authored
Document the compatible value for Startek KD050HDFIA020-C020A panels. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20240317155746.23034-2-laurent.pinchart@ideasonboard.comSigned-off-by:
-
Tony Lindgren authored
Commit 95da53d6 ("drm/omapdrm: Use regular fbdev I/O helpers") stopped console from updating for command mode displays because there is no damage handling in fb_sys_write() unlike we had earlier in drm_fb_helper_sys_write(). Let's fix the issue by adding FB_GEN_DEFAULT_DEFERRED_DMAMEM_OPS and FB_DMAMEM_HELPERS_DEFERRED as suggested by Thomas. We cannot use the FB_DEFAULT_DEFERRED_OPS as fb_deferred_io_mmap() won't work properly for write-combine. Fixes: 95da53d6 ("drm/omapdrm: Use regular fbdev I/O helpers") Suggested-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240228063540.4444-3-tony@atomide.com
-
Tony Lindgren authored
The framebuffer console stopped updating with commit f231af49 ("drm/fb-helper: Disconnect damage worker from update logic"). Let's fix the issue by implementing fb_dirty similar to what was done with commit 039a72ce ("drm/i915/fbdev: Implement fb_dirty for intel custom fb helper"). Fixes: f231af49 ("drm/fb-helper: Disconnect damage worker from update logic") Reviewed-by:
-
- 15 Mar, 2024 1 commit
-
-
Lyude Paul authored
I've recently been seeing some unexplained GSP errors on my RTX 6000 from failed aux transactions: [ 132.915867] nouveau 0000:1f:00.0: gsp: cli:0xc1d00002 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff While the cause of these is not yet clear, these messages made me notice that the aux transactions causing these transactions were succeeding - not failing. As it turns out, this is because we're currently not returning the correct variable when r535_dp_aux_xfer() hits an error - causing us to never propagate GSP errors for failed aux transactions to userspace. So, let's fix that. Fixes: 4ae3a201 ("nouveau/gsp: don't free ctrl messages on errors") Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240315212104.776936-1-lyude@redhat.com
-
- 14 Mar, 2024 5 commits
-
-
Hsin-Yi Wang authored
There are 2 different AUO panels using the same panel id. One of the variants requires using overridden modes to resolve glitching issue as described in commit 70e0d555 ("drm/panel-edp: Add auo_b116xa3_mode"). Other variants should use the modes parsed from EDID. Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Hsin-Yi Wang authored
It's found that some panels have variants that they share the same panel id although their EDID and names are different. When matching generic edp panels, we should first match with both panel identity, which contains both panel id and panel name. If not found, match with panel id only. Signed-off-by:
-
Hsin-Yi Wang authored
Currently edid quirks are matched by panel id only. Modify it to match with identity so it's easier to be extended for more complex matching if required. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Hsin-Yi Wang authored
Create a type drm_edid_ident as the identity of an EDID. Currently it contains panel id and monitor name. Create a function that can match a given EDID and an identity: 1. Reject if the panel id doesn't match. 2. If name is not null in identity, try to match it in the detailed timing blocks. Note that some panel vendors put the monitor name after EDID_DETAIL_MONITOR_STRING. Signed-off-by:
-
Hsin-Yi Wang authored
It's found that some panels have variants that they share the same panel id although their EDID and names are different. Besides panel id, now we need more information from the EDID base block to distinguish these panel variants. Add drm_edid_read_base_block() to return the EDID base block, which is wrapped in struct drm_edid. Caller can further use it to get panel id or check if the block contains certain strings, such as panel name. Merge drm_edid_get_panel_id() and edid_extract_panel_id() into one function. Signed-off-by:
-
- 13 Mar, 2024 3 commits
-
-
Jérémie Dautheribes authored
Add support for Crystal Clear Technology CMT430B19N00 4.3" 480x272 TFT-LCD panel. Suggested-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
Jérémie Dautheribes <jeremie.dautheribes@bootlin.com> Reviewed-by:
-
Jérémie Dautheribes authored
Add Crystal Clear Technology CMT430B19N00 4.3" 480x272 TFT-LCD panel compatible string. Acked-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
-
Jérémie Dautheribes authored
Update Documentation/devicetree/bindings/vendor-prefixes.yaml to include "cct" as a vendor prefix for "Crystal Clear Technology". CCT is the vendor of the CMT430B19N00 TFT-LCD panel. Link: http://www.cct.com.my/Acked-by:
-
- 12 Mar, 2024 3 commits
-
-
Jiapeng Chong authored
./drivers/gpu/drm/drm_gem_shmem_helper.c: linux/module.h is included more than once. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4567Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
-
Maxime Ripard authored
This URL gets redirected to the Intel landing page now. Let's switch the webpage to freedesktop. Link: https://lore.kernel.org/r/20240306153841.698693-2-mripard@kernel.orgAcked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Maxime Ripard authored
Now that the drm-misc tree has moved to Gitlab, adjust the MAINTAINERS git trees to reflect the location change. Link: https://lore.kernel.org/r/20240306153841.698693-1-mripard@kernel.orgAcked-by:
-
- 11 Mar, 2024 16 commits
-
-
Thomas Zimmermann authored
Pin and vmap are distinct operations. Do not perform a pin as part of the vmap call. This used to be necessary to keep the fbdev buffer in place while it is being updated. Fbdev emulation has meanwhile been fixed to lock the buffer correctly. Same for vunmap. Signed-off-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> # virtio-gpu Acked-by:
Christian König <christian.koenig@amd.com> Acked-by:
Zack Rusin <zack.rusin@broadcom.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240227113853.8464-14-tzimmermann@suse.de
-
Thomas Zimmermann authored
Pin and vmap are distinct operations. Do not perform a pin as part of the vmap call. This used to be necessary to keep the fbdev buffer in place while it is being updated. Fbdev emulation has meanwhile been fixed to lock the buffer correctly. Same for vunmap. For refactoring the code, remove the pin calls from the helper's vmap implementation in drm_gem_vram_vmap() and inline the call to drm_gem_vram_kmap_locked(). This gives a vmap helper that only maps the buffer object's memory pages without pinning or locking. Do a similar refactoring for vunmap. Signed-off-by:
-
Thomas Zimmermann authored
The function drm_client_buffer_vmap() establishes a long-term mapping of the client's buffer object into the kernel address space. Make sure that buffer does not move by pinning it to its current location. Same for vunmap with unpin. The only caller of drm_client_buffer_vmap() is fbdev-dma, which uses gem-dma. As DMA-backed GEM buffers do not move, this change is for correctness with little impact in practice. Signed-off-by:
-
Thomas Zimmermann authored
Temporarily lock the fbdev buffer object during updates to prevent memory managers from evicting/moving the buffer. Moving a buffer object while update its content results in undefined behaviour. Fbdev-generic updates its buffer object from a shadow buffer. Gem-shmem and gem-dma helpers do not move buffer objects, so they are safe to be used with fbdev-generic. Gem-vram and qxl are based on TTM, but pin buffer objects are part of the vmap operation. So both are also safe to be used with fbdev-generic. Amdgpu and nouveau do not pin or lock the buffer object during an update. Their TTM-based memory management could move the buffer object while the update is ongoing. The new vmap_local and vunmap_local helpers hold the buffer object's reservation lock during the buffer update. This prevents moving the buffer object on all memory managers. Signed-off-by:
-
Thomas Zimmermann authored
Acquire the buffer object's reservation lock in drm_gem_pin() and remove locking the drivers' GEM callbacks where necessary. Same for unpin(). DRM drivers and memory managers modified by this patch will now have correct dma-buf locking semantics: the caller is responsible for holding the reservation lock when calling the pin or unpin callback. DRM drivers and memory managers that are not modified will now be protected against concurent invocation of their pin and unpin callbacks. PRIME does not implement struct dma_buf_ops.pin, which requires the caller to hold the reservation lock. It does implement struct dma_buf_ops.attach, which requires to callee to acquire the reservation lock. The PRIME code uses drm_gem_pin(), so locks are now taken as specified. Same for unpin and detach. The patch harmonizes GEM pin and unpin to have non-interruptible reservation locking across all drivers, as is already the case for vmap and vunmap. This affects gem-shmem, gem-vram, loongson, qxl and radeon. Signed-off-by:
-
Thomas Zimmermann authored
Acquire the reservation lock directly in GEM pin callback. Same for unpin. Prepares for further changes. Dma-buf locking semantics require callers to hold the buffer's reservation lock when invoking the pin and unpin callbacks. Prepare qxl accordingly by pushing locking out of the implementation. A follow-up patch will fix locking for all GEM code at once. Signed-off-by:
-
Thomas Zimmermann authored
Rename __qxl_bo_pin() to qxl_bo_pin_locked() and update all callers. The function will be helpful for implementing the GEM pin callback with correct semantics. Same for __qxl_bo_unpin(). Signed-off-by:
-
Thomas Zimmermann authored
Acquire the reservation lock directly in GEM pin callback. Same for unpin. Prepares for further changes. Dma-buf locking semantics require callers to hold the buffer's reservation lock when invoking the pin and unpin callbacks. Prepare nouveau accordingly by pushing locking out of the implementation. A follow-up patch will fix locking for all GEM code at once. Signed-off-by:
-
Thomas Zimmermann authored
Implement pinning without locking in nouveau_bo_pin_locked(). Keep nouveau_bo_pin() for acquiring the buffer object's reservation lock. The new helper will be useful for implementing the GEM pin callback with correct semantics. Same for unpin. Signed-off-by:
-
Thomas Zimmermann authored
Export msm_gem_pin_pages_locked() and acquire the reservation lock directly in GEM pin callback. Same for unpin. Prepares for further changes. Dma-buf locking semantics require callers to hold the buffer's reservation lock when invoking the pin and unpin callbacks. Prepare msm accordingly by pushing locking out of the implementation. A follow-up patch will fix locking for all GEM code at once. Signed-off-by:
-
Thomas Zimmermann authored
Rename msm_gem_pin_pages_locked() to msm_gem_get_pages_locked(). The function doesn't pin any pages, but only acquires them. Renaming the function makes the old name available. Signed-off-by:
-
Thomas Zimmermann authored
Acquire the reservation lock directly in GEM pin callback. Same for unpin. Prepares for further changes. Dma-buf locking semantics require callers to hold the buffer's reservation lock when invoking the pin and unpin callbacks. Prepare gem-vram accordingly by pushing locking out of the implementation. A follow-up patch will fix locking for all GEM code at once. Signed-off-by:
-
Thomas Zimmermann authored
Export drm_gem_shmem_pin_locked() and acquire the reservation lock directly in GEM pin callback. Same for unpin. Prepares for further changes. Dma-buf locking semantics require callers to hold the buffer's reservation lock when invoking the pin and unpin callbacks. Prepare gem-shmem accordingly by pushing locking out of the implementation. A follow-up patch will fix locking for all GEM code at once. Signed-off-by:
-
Jani Nikula authored
Mark some members private to silence kernel-doc warnings, and add FIXME comments. Acked-by:
-
Adrián Larumbe authored
Debugfs isn't always available in production builds that try to squeeze every single byte out of the kernel image, but we still need a way to toggle the timestamp and cycle counter registers so that jobs can be profiled for fdinfo's drm engine and cycle calculations. Drop the debugfs knob and replace it with a sysfs file that accomplishes the same functionality, and document its ABI in a separate file. Signed-off-by:
Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Steven Price <steven.price@arm.com> Signed-off-by:
-
Jani Nikula authored
This reverts commit 674dc7f6. The commit causes a recursive dependency in kconfig: drivers/iommu/Kconfig:14:error: recursive dependency detected! drivers/iommu/Kconfig:14: symbol IOMMU_SUPPORT is selected by DRM_PANTHOR drivers/gpu/drm/panthor/Kconfig:3: symbol DRM_PANTHOR depends on PM kernel/power/Kconfig:183: symbol PM is selected by PM_SLEEP kernel/power/Kconfig:117: symbol PM_SLEEP depends on HIBERNATE_CALLBACKS kernel/power/Kconfig:35: symbol HIBERNATE_CALLBACKS is selected by XEN_SAVE_RESTORE arch/x86/xen/Kconfig:67: symbol XEN_SAVE_RESTORE depends on XEN arch/x86/xen/Kconfig:6: symbol XEN depends on PARAVIRT arch/x86/Kconfig:781: symbol PARAVIRT is selected by HYPERV drivers/hv/Kconfig:5: symbol HYPERV depends on X86_LOCAL_APIC arch/x86/Kconfig:1106: symbol X86_LOCAL_APIC depends on X86_UP_APIC arch/x86/Kconfig:1081: symbol X86_UP_APIC prompt is visible depending on PCI_MSI drivers/pci/Kconfig:39: symbol PCI_MSI is selected by AMD_IOMMU drivers/iommu/amd/Kconfig:3: symbol AMD_IOMMU depends on IOMMU_SUPPORT For a resolution refer to Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive dependency limitations" Fixes: 674dc7f6 ("drm/panthor: Fix undefined panthor_device_suspend/resume symbol issue") Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Steven Price <steven.price@arm.com> Acked-by:
-
