- 31 Jul, 2023 1 commit
-
-
Jiapeng Chong authored
No functional modification involved. drivers/gpu/drm/solomon/ssd130x.c:715 ssd130x_primary_plane_duplicate_state() warn: inconsistent indenting. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=6034Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
-
- 29 Jul, 2023 10 commits
-
-
Geert Uytterhoeven authored
As of commit a01cb8ba ("drm: Move drm_plane_helper_check_state() into drm_atomic_helper.c"), drm_plane_helper_check_state() no longer exists, but is part of drm_atomic_helper_check_plane_state(). Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Geert Uytterhoeven authored
The transitional helpers were removed a long time ago, but some references stuck. Remove them. Fixes: 21ebe615 ("drm: Remove transitional helpers") Signed-off-by:
-
Geert Uytterhoeven authored
Convert the references to fbconv links to footnotes, so they can be navigated. Signed-off-by:
-
Geert Uytterhoeven authored
The section about converting existing KMS drivers to atomic modesetting mentions the existence of a conversion guide, but does not reference it. While the guide is old and rusty, it still contains useful information, so add a link to it. Also link to the LWN.net articles that give an overview about the atomic mode setting design. While at it, remove the reference to unconverted virtual HW drivers, as they've been converted. Signed-off-by:
-
Geert Uytterhoeven authored
As the temporary buffer is no longer used to store 8-bit grayscale data, its size can be reduced to the size needed to store the monochrome bitmap data. Fixes: 24c6bede ("drm/repaper: Use format helper for xrgb8888 to monochrome conversion") Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by:
-
Geert Uytterhoeven authored
As ffs() returns one more than the index of the first bit set (zero means no bits set), the color key mode value is shifted one position too much. Fix this by using FIELD_GET() instead. Fixes: c96103b6 ("drm/armada: move colorkey properties into overlay plane state") Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Geert Uytterhoeven authored
Fix a misspelling of "rendez-vous". Signed-off-by:
Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by:
-
Geert Uytterhoeven authored
Fix misspellings of "semaphore". Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Geert Uytterhoeven authored
Use the drm_crtc_helper_atomic_check() helper instead of open-coding the same operation. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Sui Jingfeng <suijingfeng@loongson.cn> Signed-off-by:
-
Geert Uytterhoeven authored
drm_connector_init_with_ddc() can fail, but the call in drm_bridge_connector_init() does not check that. Fix this by adding the missing error handling. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
-
- 28 Jul, 2023 12 commits
-
-
Lyude Paul authored
Currently we use the drm_dp_dpcd_read_caps() helper in the DRM side of nouveau in order to read the DPCD of a DP connector, which makes sure we do the right thing and also check for extended DPCD caps. However, it turns out we're not currently doing this on the nvkm side since we don't have access to the drm_dp_aux structure there - which means that the DRM side of the driver and the NVKM side can end up with different DPCD capabilities for the same connector. Ideally in order to fix this, we just want to use the drm_dp_read_dpcd_caps() helper in nouveau. That's not currently possible though, and is going to depend on having a bunch of the DP code moved out of nvkm and into the DRM side of things as part of the GSP enablement work. Until then however, let's workaround this problem by porting a copy of drm_dp_read_dpcd_caps() into NVKM - which should fix this issue. Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Karol Herbst <kherbst@redhat.com> Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/211 Link: https://patchwork.freedesktop.org/patch/msgid/20230728225858.350581-1-lyude@redhat.com
-
Yangtao Li authored
Use devm_platform_ioremap_resource() to simplify code. Signed-off-by:
Yangtao Li <frank.li@vivo.com> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Link: https://lore.kernel.org/r/20230710032355.72914-8-frank.li@vivo.comSigned-off-by:
-
Yangtao Li authored
Use devm_platform_ioremap_resource() to simplify code. Signed-off-by:
-
Philipp Zabel authored
Use the already existing local variable height = drm_rect_height() >> 16 to replace other occurrences of the same value. Suggested-by:
Lucas Stach <l.stach@pengutronix.de> Reviewed-by:
-
Jocelyn Falempe authored
Aspeed always report the display port as "connected", because it doesn't set a .detect_ctx callback. Fix this by providing the proper detect callback for astdp and dp501. This also fixes the following regression: Since commit fae7d186 ("drm/probe-helper: Default to 640x480 if no EDID on DP") The default resolution is now 640x480 when no monitor is connected. But Aspeed graphics is mostly used in servers, where no monitor is attached. This also affects the remote BMC resolution to 640x480, which is inconvenient, and breaks the anaconda installer. v2: Add .detect callback to the dp/dp501 connector (Jani Nikula) v3: Use .detect_ctx callback, and refactors (Thomas Zimmermann) Add a BMC virtual connector v4: Better indent detect_ctx() functions (Thomas Zimmermann) v5: Enable polling of the dp and dp501 connector status (Thomas Zimmermann) v6: Change check order in ast_astdp_is_connected (Jammy Huang) Fixes: fae7d186 ("drm/probe-helper: Default to 640x480 if no EDID on DP") Signed-off-by:
Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by:
-
Jocelyn Falempe authored
Most aspeed devices have a BMC, which allows to remotely see the screen. Also in the common use case, those servers don't have a display connected. So add a Virtual connector, to reflect that even if no display is connected, the framebuffer can still be seen remotely. This prepares the work to implement a detect_ctx() for the Display port connector. v4: call drm_add_modes_noedid() with 4096x4096 (Thomas Zimmermann) remove useless struct field init to 0 (Thomas Zimmermann) don't use drm_simple_encoder_init() (Thomas Zimmermann) inline ast_bmc_connector_init() (Thomas Zimmermann) Fixes: fae7d186 ("drm/probe-helper: Default to 640x480 if no EDID on DP") Signed-off-by: -
Alexander Stein authored
This helps identifying problems with downstream pipeline devices, like HDMI/DP output. Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by:
Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Signed-off-by:
-
Geert Uytterhoeven authored
Both the patform_driver and mipi_dsi_driver structures contain pointers to the match table used, so the custom code to obtain match and match data can be replaced by calls to of_device_get_match_data(). Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Geert Uytterhoeven authored
If CONFIG_FB_CORE=y and CONFIG_FB=n, the frame buffer bootup logos can no longer be enabled. Fix this by making CONFIG_LOGO depend on CONFIG_FB_CORE instead of CONFIG_FB, as there is no good reason for the logo code to depend on the presence of real frame buffer device drivers. Fixes: 55bffc81 ("fbdev: Split frame buffer support in FB and FB_CORE symbols") Signed-off-by:
-
Geert Uytterhoeven authored
This reverts commit a6a00d7e. This commit is redundant, as the root cause that resulted in a false positive was fixed by commit 27f644dc ("x86: kmsan: use C versions of memset16/memset32/memset64"). Closes: https://lore.kernel.org/r/CAMuHMdUH4CU9EfoirSxjivg08FDimtstn7hizemzyQzYeq6b6g@mail.gmail.com/Signed-off-by:
-
Geert Uytterhoeven authored
All debug messages in drm_gem_framebuffer_helper.c use drm_dbg_kms(), except for one, which uses drm_dbg(). Replace the outlier by drm_dbg_kms() to restore consistency. Fixes: c91acda3 ("drm/gem: Check for valid formats") Signed-off-by:
Maíra Canal <mcanal@igalia.com> Signed-off-by:
-
Geert Uytterhoeven authored
drm_crtc_force_disable_all() was renamed to drm_helper_force_disable_all(), but one reference was not updated. Fixes: c2d88e06 ("drm: Move the legacy kms disable_all helper to crtc helpers") Signed-off-by:
-
- 27 Jul, 2023 17 commits
-
-
Maíra Canal authored
Currently, it is possible for the composer to be set as enabled and then as disabled without a proper call for the vkms_vblank_simulate(). This is problematic, because the driver would skip one CRC output, causing CRC tests to fail. Therefore, we need to make sure that, for each time the composer is set as enabled, a composer job is added to the queue. In order to provide this guarantee, add a mutex that will lock before the composer is set as enabled and will unlock only after the composer job is added to the queue. This way, we can have a guarantee that the driver won't skip a CRC entry. This race-condition is affecting the IGT test "writeback-check-output", making the test fail and also, leaking writeback framebuffers, as the writeback job is queued, but it is not signaled. This patch avoids both problems. [v2]: * Create a new mutex and keep the spinlock across the atomic commit in order to avoid interrupts that could result in deadlocks. Signed-off-by:Arthur Grillo <arthurgrillo@riseup.net> Signed-off-by:
Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230523123207.173976-1-mcanal@igalia.com
-
Arthur Grillo authored
Support a 1D gamma LUT with interpolation for each color channel on the VKMS driver. Add a check for the LUT length by creating vkms_atomic_check(). Enable VKMS to run the test igt@kms_plane@pixel-format. Tested with: igt@kms_color@gamma igt@kms_color@legacy-gamma igt@kms_color@invalid-gamma-lut-sizes v2: - Add interpolation between the values of the LUT (Simon Ser) v3: - s/ratio/delta (Pekka) - s/color_channel/channel_value (Pekka) - s/lut_area/lut_channel - Store the `drm_color_lut`, `lut_length`, and `channel_value2index_ratio` inside a struct called `vkms_lut` (Pekka) - Pre-compute some constants values used through the LUT procedure (Pekka) - Change the switch statement to a cast to __u16* (Pekka) - Make the apply_lut_to_channel_value return the computation result (Pekka) v4: - Add a comment explaining that `enum lut_area` depends on the layout of `struct drm_color_lut` (Pekka) - Remove unused variable (kernel test robot) v5: - Mention that this will make it possible to run the test igt@kms_plane@pixel-format (Maíra) - s/had/has (Maíra) Signed-off-by:Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Reviewed-by:
-
Yangtao Li authored
Use devm_platform_ioremap_resource() to simplify code. Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230710032355.72914-16-frank.li@vivo.com
-
Yangtao Li authored
Use devm_platform_ioremap_resource() to simplify code. Signed-off-by:
-
Yangtao Li authored
When platform_get_irq fails, we should return dpaux->irq instead of -ENXIO. Fixes: 6b6b6042 ("drm/tegra: Add eDP support") Signed-off-by:
-
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:
-
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:
-
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: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:
-
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:
-
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:
-
