- 11 Jul, 2022 15 commits
-
-
Arthur Grillo authored
Considering the current adoption of the KUnit framework, convert the DRM mm selftest to the KUnit API. Signed-off-by:
Arthur Grillo <arthur.grillo@usp.br> Tested-by:
David Gow <davidgow@google.com> Acked-by:
Daniel Latypov <dlatypov@google.com> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
Maíra Canal <maira.canal@usp.br> Signed-off-by:
-
Maíra Canal authored
Considering the current adoption of the KUnit framework, convert the DRM buddy selftest to the KUnit API. Tested-by:
-
Maíra Canal authored
Considering the current adoption of the KUnit framework, convert the DRM framebuffer selftest to the KUnit API. Tested-by:
-
Maíra Canal authored
Considering the current adoption of the KUnit framework, convert the DRM DP MST helper selftest to the KUnit API. Co-developed-by:
Rubens Gomes Neto <rubens.gomes.neto@usp.br> Signed-off-by:
-
Maíra Canal authored
Considering the current adoption of the KUnit framework, convert the DRM plane helper selftest to the KUnit API. Co-developed-by:
Djakson C. G. Filho <djakson.filho@gmail.com> Signed-off-by:
Anderson Fraga <aaafraga@gmail.com> Signed-off-by:
-
Maíra Canal authored
Considering the current adoption of the KUnit framework, convert the DRM format selftest to the KUnit API. Tested-by:
-
Maíra Canal authored
Considering the current adoption of the KUnit framework, convert the DRM rect selftest to the KUnit API. Co-developed-by:
Carlos Veras <carlos.craveiro@usp.br> Signed-off-by:
Matheus Vieira <matheus.vieira.g@usp.br> Signed-off-by:
-
Maíra Canal authored
Considering the current adoption of the KUnit framework, convert the DRM cmdline parser selftest to the KUnit API. Co-developed-by:
-
Maíra Canal authored
Considering the current adoption of the KUnit framework, convert the DRM damage helper selftest to the KUnit API. Co-developed-by:
-
Christian König authored
Allow BOs to exist without backing store. v2: handle ttm_bo_move_memcpy as well. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Michael J. Ruhl <michael.j.ruhl@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220707102453.3633-5-christian.koenig@amd.com
-
Christian König authored
Make sure we can at least move and release BOs without backing store. Signed-off-by:
-
Christian König authored
Make sure we can at least move and release BOs without backing store. Signed-off-by:
-
Christian König authored
Rename ttm_bo_init to ttm_bo_init_validate since that better matches what the function is actually doing. Remove the unused size parameter, move the function's kerneldoc to the implementation and cleanup the whole error handling. Signed-off-by:
-
Arunpravin Paneer Selvam authored
This reverts commit 5e3f1e77. This is part of a revert of the following commits: commit 708d19d9 ("drm/amdgpu: move internal vram_mgr function into the C file") commit 5e3f1e77 ("drm/amdgpu: fix start calculation in amdgpu_vram_mgr_new") commit c9cad937 ("drm/amdgpu: add drm buddy support to amdgpu") [WHY] Few users reported garbaged graphics as soon as x starts, reverting until this can be resolved. Signed-off-by:
Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Reviewed-by:
-
Arunpravin Paneer Selvam authored
This reverts commit 708d19d9. This is part of a revert of the following commits: commit 708d19d9 ("drm/amdgpu: move internal vram_mgr function into the C file") commit 5e3f1e77 ("drm/amdgpu: fix start calculation in amdgpu_vram_mgr_new") commit c9cad937 ("drm/amdgpu: add drm buddy support to amdgpu") [WHY] Few users reported garbaged graphics as soon as x starts, reverting until this can be resolved. Signed-off-by:
-
- 09 Jul, 2022 22 commits
-
-
Paul Cercueil authored
- Use DEFINE_SIMPLE_DEV_PM_OPS() instead of the SIMPLE_DEV_PM_OPS() macro. This makes it possible to remove the __maybe_unused flags on the callback functions. - Since we only have callbacks for suspend/resume, we can conditionally compile the dev_pm_ops structure for when CONFIG_PM_SLEEP is enabled; so use the pm_sleep_ptr() macro instead of pm_ptr(). Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220708205406.96473-7-paul@crapouillou.net
-
Paul Cercueil authored
Avoid requesting a full modeset if the sharpness property is not modified, because then we don't actually need it. Signed-off-by:
-
Paul Cercueil authored
Add support for the JZ4760 and JZ4760B SoCs to the ingenic-drm display driver. Signed-off-by:
-
Paul Cercueil authored
The previous "GPL v2" string is deprecated. For more info, see commit bf7fbeea ("module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity") Signed-off-by:
-
Paul Cercueil authored
Add compatible strings for the LCD controllers found in the JZ4760 and JZ4760B SoCs from Ingenic. Signed-off-by:
-
Geert Uytterhoeven authored
Fix various spelling and grammar mistakes in the kerneldoc comments documenting the offsets member in the drm_framebuffer structure: - s/laytou/layout/, - Add missing "is", - s/it/its/. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Acked-by:
Simon Ser <contact@emersion.fr> Signed-off-by:
-
Martin Jücker authored
Add timings and panel description for the Samsung LTL101AL01 panel. Signed-off-by:
Martin Jücker <martin.juecker@gmail.com> Signed-off-by:
-
Martin Jücker authored
Add the Samsung LTL101AL01 WXGA LCD panel to the list. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Geert Uytterhoeven authored
Fix various grammar mistakes in the kerneldoc comments documenting the drm_mode_fb_cmd2 structure: - s/is/are/, - s/8 bit/8-bit/. Signed-off-by:
-
Geert Uytterhoeven authored
As Rn covers single-channel formats with a direct relationship between channel value and brightness, and Cn can be any colors, there are currently no fourcc codes to describe single-channel formats with an inverse relationship between channel value and brightness. Introduce fourcc codes for a single-channel frame buffer format with two, four, sixteen, or 256 brightness ("darkness") levels, where there is an inverse relationship between channel value and brightness. As the number of bits per pixel may be less than eight, some of these formats rely on proper block handling for the calculation of bits per pixel and pitch. The fill order (the order in which multiple pixels are packed in a byte) is the same order as used for grayscale (2, 4, and 16 levels) images in the PNG specification, Version 1.2. This order is also the recommended and default order (FillOrder = 1) for bilevel and grayscale (16 levels) images in the TIFF 6.0 Specification, and is also used for monochrome images in the PBM file format, monochrome Linux frame buffer logos, and BDF and PSF (Linux kernel) font files. Signed-off-by: -
Geert Uytterhoeven authored
Introduce fourcc codes for single-channel frame buffer formats with two, four, and sixteen brightness levels, where there is a direct relationship between channel value and brightness. As the number of bits per pixel is less than eight, these rely on proper block handling for the calculation of bits per pixel and pitch. The fill order (the order in which multiple pixels are packed in a byte) is the same order as used for grayscale (2, 4, and 16 levels) images in the PNG specification, Version 1.2. This order is also the recommended and default order (FillOrder = 1) for bilevel and grayscale (16 levels) images in the TIFF 6.0 Specification, and is also used for monochrome images in the PBM file format, monochrome Linux frame buffer logos, and BDF and PSF (Linux kernel) font files. Signed-off-by:
-
Geert Uytterhoeven authored
Traditionally, the first channel has been called the "red" channel, but the fourcc values for single-channel "red" formats can also be used for other single-channel formats with a direct relationship between channel value and brightness, like grayscale. Signed-off-by:
-
Geert Uytterhoeven authored
The AFBC helpers derive the number of bits per pixel from the deprecated drm_format_info.cpp[] field, which does not take into account block sizes. Fix this by using the actual number of bits per pixel instead. Signed-off-by:
-
Geert Uytterhoeven authored
Add support for color-indexed frame buffer formats with two, four, and sixteen colors to the DRM framebuffer helper functions: 1. Add support for 1, 2, and 4 bits per pixel to the damage helper, 2. For color-indexed modes, the length of the color bitfields must be set to the color depth, else the logo code may pick a logo with too many colors. Drop the incorrect DAC width comment, which originates from the i915 driver. 3. Accept C[124] modes when validating or filling in struct fb_var_screeninfo, and use the correct number of bits per pixel. 4. Set the visual to FB_VISUAL_PSEUDOCOLOR for all color-indexed modes. Signed-off-by: -
Geert Uytterhoeven authored
Introduce fourcc codes for color-indexed frame buffer formats with two, four, and sixteen colors, and provide a mapping from bits per pixel and depth to fourcc codes. As the number of bits per pixel is less than eight, these rely on proper block handling for the calculation of bits per pixel and pitch. The fill order (the order in which multiple pixels are packed in a byte) is the same order as used for indexed-color (2, 4, and 16 colors) images in the PNG specification, Version 1.2. This order is also the recommended and default order (FillOrder = 1) for palette-color (16 colors) images in the TIFF 6.0 Specification, and is also used for 16-color Linux frame buffer logos. Signed-off-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by:
-
Geert Uytterhoeven authored
When userspace queries the properties of a frame buffer, the number of bits per pixel is derived from the deprecated drm_format_info.cpp[] field, which does not take into account block sizes. Fix this by using the actual number of bits per pixel instead. Signed-off-by:
-
Geert Uytterhoeven authored
When allocating a frame buffer, the number of bits per pixel needed is derived from the deprecated drm_format_info.cpp[] field. While this may work for formats using less than 8 bits per pixel, it does lead to a large overallocation. Reduce memory consumption by using the actual number of bits per pixel instead. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
-
Geert Uytterhoeven authored
Add a flag to struct drm_format_info to indicate if a format is color-indexed, similar to the existing .is_yuv flag. This way generic code and drivers can just check this flag, instead of checking against a list of fourcc formats. Signed-off-by:
-
Geert Uytterhoeven authored
Add a helper to retrieve the actual number of bits per pixel for a plane, taking into account the number of characters and pixels per block for tiled formats. Signed-off-by:
-
Uwe Kleine-König authored
All implementations return 0 and the return value of mipi_dsi_drv_remove() is ignored anyhow. So change the prototype of the remove function to return no value. This way driver authors are not tempted to assume that passing an error to the upper layer is a good idea. All drivers are adapted accordingly. There is no intended change of behaviour. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
-
Uwe Kleine-König authored
Returning an error code from a mipi_dsi remove callback fails, this is silently ignored. (mipi_dsi_drv_remove() propagates the return value to device_remove() which ignores it.) So emit an error code in the driver remove function and return 0. Signed-off-by:
-
Uwe Kleine-König authored
panel_simple_remove() returns zero unconditionally. Make it return no value instead making more obvious what happens in the callers. This is a preparation for making platform and mipi-dsi remove callbacks return void. Signed-off-by:
-
- 08 Jul, 2022 3 commits
-
-
Dan Carpenter authored
This code works, but technically it uses "num_in_bus_fmts" before it has been initialized so it leads to static checker warnings and probably KMEMsan warnings at run time. Initialize the variable to zero to silence the warning. Fixes: f32df58a ("drm/bridge: Add the necessary bits to support bus format negotiation") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/YrrIs3hoGcPVmXc5@kili
-
Samuel Holland authored
Allwinner display drivers are split roughly into two generations. The first generation was found on early 32-bit ARM SoCs and contains DE1.0 and a custom HDMI controller. Clarify that these options only apply to a specific list of SoCs, and limit selecting them to 32-bit ARM, to avoid confusion. The second generation, found in A83T and newer SoCs (both 32-bit and 64-bit), contains a DE2.0 and a DesignWare HDMI controller. Since this is the most widely-used generation, enable it by default. The previous default condition (MACH_SUN8I) was limited to 32-bit SoCs. Also enable the DSI controller by default, which is found on 64-bit SoCs as well. Signed-off-by:
Samuel Holland <samuel@sholland.org> Signed-off-by:
-
Maxime Ripard authored
The current code tries to handle the case where CONFIG_PM isn't selected by first calling our runtime_resume implementation and then properly report the power state to the runtime_pm core. This allows to have a functionning device even if pm_runtime_get_* functions are nops. However, the device power state if CONFIG_PM is enabled is RPM_SUSPENDED, and thus our vc4_hdmi_write() and vc4_hdmi_read() calls in the runtime_pm hooks will now report a warning since the device might not be properly powered. Even more so, we need CONFIG_PM enabled since the previous RaspberryPi have a power domain that needs to be powered up for the HDMI controller to be usable. The previous patch has created a dependency on CONFIG_PM, now we can just assume it's there and only call pm_runtime_resume_and_get() to make sure our device is powered in bind. Link: https://lore.kernel.org/r/20220629123510.1915022-39-maxime@cerno.techAcked-by:
Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by:
-
