- 27 Jul, 2023 12 commits
-
-
Maxim Schwalm authored
Some Tegra device-trees may specify a video output graph, which involves MHL bridge/simple bridge and/or connector framework. This patch adds support for the bridge/connector attached to the HDMI output, allowing us to model the hardware properly. Inspired by: 29efdc29 ("drm/tegra: output: rgb: Support LVDS encoder bridge") Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # ASUS TF T30 Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> # ASUS P1801-T T30 Tested-by: Robert Eckelmann <longnoserob@gmail.com> # ASUS TF101 T20 Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # ASUS TF201 T30 Signed-off-by:
Maxim Schwalm <maxim.schwalm@gmail.com> Signed-off-by:
Svyatoslav Ryhel <clamor95@gmail.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230618085046.10081-2-clamor95@gmail.com
-
Mikko Perttunen authored
Currently, engine drivers only enable runtime PM during the host1x init callback. This can happen slightly later than the probe, which can cause the power domain to intermittently not be turned off after probe. My hypothesis is that there is a race condition between the post-probe power domain poweroff that is done from a queued work, and the pm_runtime_enable call happening in the host1x init callback. If the pm_runtime_enable call happens first, everything is OK and the power off work can disable the power domain as PM runtime is enabled and the device is runtime suspended. If power off work runs first, PM runtime is still disabled for the device and the domain must be kept powered. Resolve the issue by moving the runtime PM enablement to the probe function. Signed-off-by:
Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by:
-
Yang Li authored
Convert platform_get_resource(),devm_ioremap_resource() to a single call to devm_platform_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Signed-off-by:
-
Mikko Perttunen authored
If a context device was not attached to IOMMU, we kept the old success err value causing context devices to be unregistered but success to be returned. This would mean that things would go on but with context isolation disabled. To decide on an explicit behavior, let's return an error code here instead. If someone wants to go without IOMMU on a platform modern enough to support context isolation, they can remove the context devices from device tree. Reported-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
Mikko Perttunen authored
The return value for tegra_drm_alloc was missing an error check. Add one. Reported-by:
-
Nathan Chancellor authored
A proposed update to clang's -Wconstant-logical-operand to warn when the left hand side is a constant shows the following instance in nsecs_to_jiffies_timeout() when NSEC_PER_SEC is not a multiple of HZ, such as CONFIG_HZ=300: drivers/gpu/drm/i915/gem/i915_gem_wait.c:189:24: warning: use of logical '&&' with constant operand [-Wconstant-logical-operand] 189 | if (NSEC_PER_SEC % HZ && | ~~~~~~~~~~~~~~~~~ ^ drivers/gpu/drm/i915/gem/i915_gem_wait.c:189:24: note: use '&' for a bitwise operation 189 | if (NSEC_PER_SEC % HZ && | ^~ | & drivers/gpu/drm/i915/gem/i915_gem_wait.c:189:24: note: remove constant to silence this warning 1 warning generated. Turn this into an explicit comparison against zero to make the expression a boolean to make it clear this should be a logical check, not a bitwise one. Link: https://reviews.llvm.org/D142609Signed-off-by:Nathan Chancellor <nathan@kernel.org> Acked-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230718-nsecs_to_jiffies_timeout-constant-logical-operand-v1-2-36ed8fc8faea@kernel.org
-
Nathan Chancellor authored
A proposed update to clang's -Wconstant-logical-operand to warn when the left hand side is a constant shows the following instance in nsecs_to_jiffies_timeout() when NSEC_PER_SEC is not a multiple of HZ, such as CONFIG_HZ=300: In file included from drivers/gpu/drm/v3d/v3d_debugfs.c:12: drivers/gpu/drm/v3d/v3d_drv.h:343:24: warning: use of logical '&&' with constant operand [-Wconstant-logical-operand] 343 | if (NSEC_PER_SEC % HZ && | ~~~~~~~~~~~~~~~~~ ^ drivers/gpu/drm/v3d/v3d_drv.h:343:24: note: use '&' for a bitwise operation 343 | if (NSEC_PER_SEC % HZ && | ^~ | & drivers/gpu/drm/v3d/v3d_drv.h:343:24: note: remove constant to silence this warning 1 warning generated. Turn this into an explicit comparison against zero to make the expression a boolean to make it clear this should be a logical check, not a bitwise one. Link: https://reviews.llvm.org/D142609Signed-off-by:Maíra Canal <mcanal@igalia.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
Thierry Reding authored
The Hydis HV070WX2-1E0 is a 7" WXGA (800x1280) TFT LCD LVDS panel that is one of the variants used on Google Nexus 7. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Thierry Reding authored
The Chunghwa CLAA070WP03XG is an LVDS panel, so move it to the correct bindings file. Signed-off-by:
-
Thierry Reding authored
The HannStar HSD101PWW2 is an LVDS panel, so move it to the correct bindings file. Signed-off-by:
-
Javier Martinez Canillas authored
The commit 45b58669 ("drm/ssd130x: Allocate buffer in the plane's .atomic_check() callback") moved the buffers allocation to be done in the primary plane's .atomic_check() callback. But it missed that since the driver uses a shadow-buffered plane, the __drm_gem_{reset,duplicate,destroy}_shadow_plane() helper functions must be used in the struct drm_plane_funcs handlers. This was missed because the mentioned commit did not remove the macro DRM_GEM_SHADOW_PLANE_FUNCS, which leads to the custom plane's atomic state management handlers to not be used. Fixes: 45b58669 ("drm/ssd130x: Allocate buffer in the plane's .atomic_check() callback") Reported-by:
Arnd Bergmann <arnd@arndb.de> Closes: https://lore.kernel.org/dri-devel/20230727122412.2464210-1-arnd@kernel.orgSuggested-by:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
-
Luc Ma authored
The kernel-doc for DMA-BUF statistics mentions /sys/kernel/dma-buf/buffers but the correct path is /sys/kernel/dmabuf/buffers instead. Signed-off-by:
Luc Ma <luc@sietium.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
- 26 Jul, 2023 2 commits
-
-
Javier Martinez Canillas authored
Drivers are not allowed to fail after drm_atomic_helper_swap_state() has been called and the new atomic state is stored into the current sw state. Since the struct ssd130x_device .data_array is allocated in the encoder's .atomic_enable callback, the operation can fail and this is after the new state has been stored. So it can break an atomic mode settings assumption. Fix this by having custom helpers to allocate, duplicate and destroy the plane state, that will take care of allocating and freeing these buffers. Suggested-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230726105433.389740-2-javierm@redhat.com
-
Javier Martinez Canillas authored
There is only a single caller for both helper functions and these don't do much other than allocate and free two buffers, so let's just inline them. Suggested-by:
-
- 25 Jul, 2023 1 commit
-
-
Thomas Zimmermann authored
Remove ast_init_pci_config() as the ast driver already enables the PCI resources by calling pcim_enable_device(). Suggested-by:
Sui Jingfeng <suijingfeng@loongson.cn> Signed-off-by:
Jocelyn Falempe <jfalempe@redhat.com> Tested-by:
-
- 24 Jul, 2023 25 commits
-
-
Arnd Bergmann authored
The driver now uses the backlight interface, which breaks when that is disabled: ld.lld: error: undefined symbol: devm_backlight_device_register Enforce the necessary Kconfig dependency to avoid this. Fixes: c2268daa ("drm/panel: ld9040: Register a backlight device") Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230724121736.1293270-1-arnd@kernel.org
-
Thomas Zimmermann authored
Make the comments for I/O, system and DMA memory say the same. Makes the header file's structure more obvious. Suggested-by:
-
Thomas Zimmermann authored
Remove the initializer macro FB_DEFAULT_SYS_OPS and its helper macro __FB_DEFAULT_SYS_OPS_MMAP. There are no users. Signed-off-by:
-
Thomas Zimmermann authored
Mark the framebuffer with FBINFO_VIRTFB. The framebuffer range is in DMA-able memory and should be accessed with the CPU's regular memory ops. v2: * drop FBINFO_DEFAULT Signed-off-by:
-
Thomas Zimmermann authored
The fbdev emulation currently uses fbdev's default mmap code, which has been written for I/O memory. Provide an mmap that uses GEM's mmap infrastructure. Utilize fine-grained fbdev macros to initialize struct fb_ops. The macros set the read/write and the draw callbacks for DMA memory. Set the fb_mmap callback to omapdrm's new mmap helper. Also select the correct Kconfig token for fbdev's DMA helpers. Note that the DMA helpers are the same as for system memory. Signed-off-by:
-
Thomas Zimmermann authored
Use the mmap callback in struct drm_gem_object_funcs to set the VM flags. Replace a number of mmap helpers in omapdrm with their GEM helper counterparts. Generate DRM's file-operations instance with GEM's DEFINE_DRM_GEM_FOPS. The omapdrm driver uses DRM's drm_gem_mmap() helper to prepare the VMA structure. It then modifies the resulting VMA state in its own helper omap_gem_mmap_obj(). The patch improves this by setting up the VMA in the mmap callback in drm_gem_object_funcs, which is called from within drm_gem_mmap(). Omapdrm's omap_gem_mmap() and omap_gem_mmap() can then be removed from the driver. A call to drm_gem_mmap() is sufficient for the mmap operation. Finally, with the omap functions gone, the drivers file_ops in omapdriver_fops can be generated with DEFINE_DRM_GEM_FOPS, which sets DRM's default helpers. v2: * detailed commit message (Javier) * do not set VM_PFNMAP Signed-off-by:
-
Thomas Zimmermann authored
Mark the framebuffer with FBINFO_VIRTFB. The framebuffer range is in DMA-able memory and should be accessed with the CPU's regular memory ops. v2: * drop FBINFO_FLAG_DEFAULT Signed-off-by:
-
Thomas Zimmermann authored
Use fbdev's DMA helpers for fbdev emulation. The driver previously used the I/O-memory helpers, while allocating DMA-able system memory. This could (in theory) result in bus errors from accessing the memory range. This bug has been present since the exynos driver was first added. v2: * drop the pointless Fixes tag (Javier) * fix typo in commit message Signed-off-by:
Inki Dae <inki.dae@samsung.com> Acked-by:
-
Thomas Zimmermann authored
Tegra uses DMA-able memory, which has to be acessed with CPU ops for system-memory. Store the framebuffer's vmap address in struct fb_info.screen_buffer. The currently used field 'screen_base' is for I/O memory. Suggested-by:
Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
-
Thomas Zimmermann authored
Mark the framebuffer with FBINFO_VIRTFB. The framebuffer range is in DMA-able memory and should be accessed with the CPU's regular memory ops. v2: * drop FBINFO_DEFAULT Signed-off-by:
-
Thomas Zimmermann authored
Use fbdev's DMA helpers for fbdev emulation. They are equivalent to the previously used system-memory helpers, so no functional changes here. Signed-off-by:
-
Thomas Zimmermann authored
Use fbdev's DMA helpers for fbdev-dma. They are equivalent to the previously used system-memory helpers, so no functional changes here. Signed-off-by:
-
Thomas Zimmermann authored
Add initializer macros for struct fb_ops for framebuffers in DMA-able memory areas. Also add a corresponding Kconfig token. As of now, this is equivalent to system framebuffers and mostly useful for labeling drivers correctly. A later patch may add a generic DMA-specific mmap operation. Linux offers a number of dma_mmap_*() helpers for different use cases. Signed-off-by:
-
Luca Ceresoli authored
These variables are never referenced in the code. Signed-off-by:
Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230719105829.148011-1-luca.ceresoli@bootlin.com
-
Thomas Zimmermann authored
Most fbdev drivers depend on framebuffer_alloc() to initialize the allocated memory to 0. Document this guarantee. v3: * slightly reword the sentence (Miguel) Suggested-by:
Miguel Ojeda <ojeda@kernel.org> Signed-off-by:
-
Thomas Zimmermann authored
Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by devm_kzalloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by:
-
Thomas Zimmermann authored
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by a static declaration. So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by:
-
Thomas Zimmermann authored
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v4: * clarify commit message (Geert, Dan) v2: * fix commit message (Miguel) Signed-off-by:
-
Thomas Zimmermann authored
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by kzalloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v4: * clarify commit message (Geert, Dan) v2: * fix commit message (Miguel) Signed-off-by:
-
Thomas Zimmermann authored
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230715185343.7193-13-tzimmermann@suse.de
-
Thomas Zimmermann authored
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by kzalloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by:
-
Thomas Zimmermann authored
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by:
Bruno Prémont <bonbons@linux-vserver.org> Cc: "Bruno Prémont" <bonbons@linux-vserver.org> Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230715185343.7193-11-tzimmermann@suse.de
-
Thomas Zimmermann authored
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by:
-
Thomas Zimmermann authored
Assign FB_MODE_IS_UNKNOWN to sh7763fb_videomode.flag instead of FBINFO_FLAG_DEFAULT. Both are 0, so the stored value does not change. FBINFO_FLAG_DEFAULT is a flag for a framebuffer in struct fb_info. Flags for videomodes are prefixed with FB_MODE_. v3: * include board name in commit message (Adrian) v2: * assign FB_MODE_IS_UNKNOWN (Adrian) Signed-off-by:
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Rich Felker <dalias@libc.org> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230715185343.7193-9-tzimmermann@suse.de
-
