- 28 Nov, 2022 2 commits
-
-
Maxime Ripard authored
None of our wrappers around container_of to access our objects from the DRM object pointer actually modify the latter. Let's make them const. Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221123-rpi-kunit-tests-v1-11-051a0bb60a16@cerno.tech
-
Maxime Ripard authored
The drm_atomic_get_(old|new)_*_state don't modify the passed drm_atomic_state, so we can make it const. Reviewed-by:
-
- 25 Nov, 2022 2 commits
-
-
Geert Uytterhoeven authored
Freescale/NXP i.MX LCDIF and eLCDIF LCD controllers are only present on Freescale/NXP i.MX SoCs. Hence add a dependency on ARCH_MXS || ARCH_MXC, to prevent asking the user about this driver when configuring a kernel without Freescale/NXP i.MX support. Fixes: 45d59d70 ("drm: Add new driver for MXSFB controller") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
Geert Uytterhoeven authored
The Freescale/NXP i.MX LCDIFv3 LCD controller is only present on Freescale/NXP i.MX SoCs. Hence add a dependency on ARCH_MXC, to prevent asking the user about this driver when configuring a kernel without Freescale/NXP i.MX support. Fixes: 9db35bb3 ("drm: lcdif: Add support for i.MX8MP LCDIF variant") Signed-off-by:
-
- 24 Nov, 2022 30 commits
-
-
Thomas Zimmermann authored
If no preferred value for bits-per-pixel has been given, fall back to 32. Never use the preferred depth. The color depth is the number of color/alpha bits per pixel, while bpp is the overall number of bits in most cases. Most noteworthy, XRGB8888 has a depth of 24 and a bpp value of 32. Using depth for bpp would make the value 24 as well and format selection in fbdev helpers fails. Unfortunately XRGB8888 is the most common format and the old heuristic therefore fails for most of the drivers (unless they implement the 24-bit RGB888 format). Picking a bpp of 32 will later on result in a default depth of 24 and the format XRGB8888. As XRGB8888 is the default format for most of the current and legacy graphics stack, all drivers must support it. So it is the safe choice. v2: * fix commit-message typo (Javier) Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221123115348.2521-8-tzimmermann@suse.de
-
Thomas Zimmermann authored
Set the preferred color depth to 24 bits and the fbdev bpp to 32 bits. This will signal XRGB8888 as default format to clients. Signed-off-by:
-
Thomas Zimmermann authored
Set the preferred depth from the format of the scanout buffer. The value cannot be hardcoded, as the scanout buffer is only known at runtime. Also derive the fbdev emulation's bpp value from the scanout format. v2: * fix commit-message typo Signed-off-by:
-
Thomas Zimmermann authored
Set the preferred depth from the format of the scanout buffer. The value cannot be hardcoded, as the scanout buffer is only known at runtime. Keeping the existing switch statement just duplicates the driver's existing logic for format detection. Also remove the FIXME comment from the call to drm_fbdev_generic_setup() as the driver now handles color depth and bpp values correctly. v2: * fix commit-message typo Signed-off-by:
-
Thomas Zimmermann authored
Cirrus has a preferred color depth of 16 bit; also use it as fbdev bpp value. Don't use the color depth directly. It has a different meaning than bpp and both cannot be used interchangeably. Signed-off-by:
-
Thomas Zimmermann authored
Logicvc can have different values for the preferred color depth. Set the fbdev bpp value depending on the runtime value. v2: * remove unused color depth of 15 from switch (Javier) Signed-off-by:
-
Thomas Zimmermann authored
Set the preferred color depth to 24 bits and the fbdev bpp to 32 bits. This will signal XRGB8888 as default format to clients. Signed-off-by:
-
Frieder Schrempf authored
The datasheet specifies a delay of 10 milliseconds, but the current driver only waits for 1 ms. Fix this to make sure the initialization sequence meets the spec. Fixes: ceb515ba ("drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver") Signed-off-by:
Frieder Schrempf <frieder.schrempf@kontron.de> Reviewed-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221122081219.20143-1-frieder@fris.de
-
Maxime Ripard authored
Now that the core can deal fine with analog TV modes, let's convert the sun4i TV driver to leverage those new features. Acked-by:
Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Acked-in-principle-or-something-like-that-by:
-
Mateusz Kwiatkowski authored
Add support for the following composite output modes (all of them are somewhat more obscure than the previously defined ones): - NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to 4.43361875 MHz (the PAL subcarrier frequency). Never used for broadcasting, but sometimes used as a hack to play NTSC content in PAL regions (e.g. on VCRs). - PAL_N - PAL with alternative chroma subcarrier frequency, 3.58205625 MHz. Used as a broadcast standard in Argentina, Paraguay and Uruguay to fit 576i50 with colour in 6 MHz channel raster. - PAL60 - 480i60 signal with PAL-style color at normal European PAL frequency. Another non-standard, non-broadcast mode, used in similar contexts as NTSC_443. Some displays support one but not the other. - SECAM - French frequency-modulated analog color standard; also have been broadcast in Eastern Europe and various parts of Africa and Asia. Uses the same 576i50 timings as PAL. Also added some comments explaining color subcarrier frequency registers. Acked-by:
Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Tested-by:
-
Maxime Ripard authored
Now that the core can deal fine with analog TV modes, let's convert the vc4 VEC driver to leverage those new features. We've added some backward compatibility to support the old TV mode property and translate it into the new TV norm property. We're also making use of the new analog TV atomic_check helper to make sure we trigger a modeset whenever the TV mode is updated. Acked-by:
-
Mateusz Kwiatkowski authored
The VEC can accept pretty much any relatively reasonable mode, but still has a bunch of constraints to meet. Let's create an atomic_check() implementation that will make sure we don't end up accepting a non-functional mode. Acked-by:
-
Maxime Ripard authored
The analog TV properties created by the drm_mode_create_tv_properties() are not properly initialised at reset. Let's switch our implementation to call drm_atomic_helper_connector_tv_reset(). Reviewed-by:
-
Maxime Ripard authored
The analog TV connector drivers share some atomic_check logic, and the new TV standard property have created some boilerplate that can be shared across drivers too. Let's create an atomic_check helper for those use cases. Reviewed-by:
-
Maxime Ripard authored
The drm_tv_create_properties() function will create a bunch of properties, but it's up to each and every driver using that function to properly reset the state of these properties leading to inconsistent behaviours. Let's create a helper that will take care of it. Reviewed-by:
-
Noralf Trønnes authored
Most of the TV connectors will need a similar get_modes implementation that will, depending on the drivers' capabilities, register the 480i and 576i modes. That implementation will also need to set the preferred flag and order the modes based on the driver and users preferrence. This is especially important to guarantee that a userspace stack such as Xorg can start and pick up the preferred mode while maintaining a working output. Signed-off-by:
-
Maxime Ripard authored
Now that we can easily extend the named modes list, let's add a few more analog TV modes that were used in the wild, and some unit tests to make sure it works as intended. Reviewed-by:
-
Maxime Ripard authored
Commit 3aeeb13d ("drm/modes: Support modes names on the command line") initially introduced the named modes support by essentially matching the name passed on the command-line to the mode names defined by the drivers. This proved to be difficult to work with, since all drivers had to provide properly named modes. This was also needed because we weren't passing a full blown-mode to the drivers, but were only filling its name. Thanks to the previous patches, we now generate a proper mode, and we thus can use the usual matching algo on timings, and can simply drop the name match. Reviewed-by:
-
Maxime Ripard authored
The framework will get the drm_display_mode from the drm_cmdline_mode it got by parsing the video command line argument by calling drm_connector_pick_cmdline_mode(). The heavy lifting will then be done by the drm_mode_create_from_cmdline_mode() function. In the case of the named modes though, there's no real code to make that translation and we rely on the drivers to guess which actual display mode we meant. Let's modify drm_mode_create_from_cmdline_mode() to properly generate the drm_display_mode we mean when passing a named mode. Reviewed-by:
-
Maxime Ripard authored
Our new tv mode option allows to specify the TV mode from a property. However, it can still be useful, for example to avoid any boot time artifact, to set that property directly from the kernel command line. Let's add some code to allow it, and some unit tests to exercise that code. Reviewed-by:
-
Maxime Ripard authored
As part of the command line parsing rework coming in the next patches, we'll need to lookup drm_connector_tv_mode values by their name, already defined in drm_tv_mode_enum_list. In order to avoid any code duplication, let's do a function that will perform a lookup of a TV mode name and return its value. Reviewed-by:
-
Maxime Ripard authored
Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and 625-lines modes in their drivers. Since those modes are fairly standard, and that we'll need to use them in more places in the future, it makes sense to move their definition into the core framework. However, analog display usually have fairly loose timings requirements, the only discrete parameters being the total number of lines and pixel clock frequency. Thus, we created a function that will create a display mode from the standard, the pixel frequency and the active area. Tested-by:
-
Maxime Ripard authored
The TV mode property has been around for a while now to select and get the current TV mode output on an analog TV connector. Despite that property name being generic, its content isn't and has been driver-specific which makes it hard to build any generic behaviour on top of it, both in kernel and user-space. Let's create a new enum tv norm property, that can contain any of the analog TV standards currently supported by kernel drivers. Each driver can then pass in a bitmask of the modes it supports, and the property creation function will filter out the modes not supported. We'll then be able to phase out the older tv mode property. Tested-by:
-
Maxime Ripard authored
drm_mode_create_tv_properties(), among other things, will create the "mode" property that stores the analog TV mode that connector is supposed to output. However, that property is getting deprecated, so let's rename that function to mention it's deprecated. We'll introduce a new variant of that function creating the property superseeding it in a later patch. Reviewed-by: Lyude Paul <lyude@redhat.com> # nouveau Reviewed-by:
-
Maxime Ripard authored
The drm_create_tv_properties() will create the TV mode property unconditionally. However, since we'll gradually phase it out, let's register it only if we have a list passed as an argument. This will make the transition easier. Acked-by:
-
Maxime Ripard authored
The current tv_mode has driver-specific values that don't allow to easily share code using it, either at the userspace or kernel level. Since we're going to introduce a new, generic, property that fit the same purpose, let's rename this one to legacy_tv_mode to make it obvious we should move away from it. Acked-by:
-
Maxime Ripard authored
That file is included directly, so we can't use any MODULE macro. Let's leave a comment to avoid any future mistake. Reviewed-by:
-
T.J. Mercier authored
I've been collecting these typo fixes for a while and it feels like time to send them in. Signed-off-by:
T.J. Mercier <tjmercier@google.com> Reviewed-by:
Randy Dunlap <rdunlap@infradead.org> Acked-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Tommaso Merciai <tommaso.merciai@amarulasolutions.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221123193519.3948105-1-tjmercier@google.comSigned-off-by:
-
Thomas Zimmermann authored
Backmerging to get v6.1-rc6 into drm-misc-next. Signed-off-by: -
Dave Airlie authored
Linux 6.1-rc6 This is needed for drm-misc-next and tegra. Signed-off-by:Dave Airlie <airlied@redhat.com>
-
- 23 Nov, 2022 3 commits
-
-
Geert Uytterhoeven authored
As of commit eae06120 ("drm: refuse ADDFB2 ioctl for broken bigendian drivers"), drivers must set the quirk_addfb_prefer_host_byte_order quirk to make the drm_mode_addfb() compat code work correctly on big-endian machines. While that works fine for big-endian XRGB8888 and ARGB8888, which are mapped to the existing little-endian BGRX8888 and BGRA8888 formats, it does not work for big-endian XRGB1555 and RGB565, as the latter are not listed in the format database. Fix this by adding the missing formats. Limit this to big-endian platforms, as there is currently no need to support these formats on little-endian platforms. Fixes: 6960e6da ("drm: fix drm_mode_addfb() on big endian machines.") Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Randy Dunlap authored
Correct grammar and make the use of the igt-tests more readable. Signed-off-by:
-
Dmitry Osipenko authored
The drm_sched_entity_kill() is invoked twice by drm_sched_entity_destroy() while userspace process is exiting or being killed. First time it's invoked when sched entity is flushed and second time when entity is released. This causes a lockup within wait_for_completion(entity_idle) due to how completion API works. Calling wait_for_completion() more times than complete() was invoked is a error condition that causes lockup because completion internally uses counter for complete/wait calls. The complete_all() must be used instead in such cases. This patch fixes lockup of Panfrost driver that is reproducible by killing any application in a middle of 3d drawing operation. Fixes: 2fdb8a8f ("drm/scheduler: rework entity flush, kill and fini") Signed-off-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Reviewed-by:
-
- 22 Nov, 2022 3 commits
-
-
git://anongit.freedesktop.org/drm/drm-intelDave Airlie authored
GVT Changes: - gvt-next stuff mostly with refactor for the new MDEV interface. i915 Changes: - PSR fixes and improvements (Jouni) - DP DSC fixes (Vinod, Jouni) - More general display cleanups (Jani) - More display collor management cleanup targetting degamma (Ville) - remove circ_buf.h includes (Jiri) - wait power off delay at driver remove to optimize probe (Jani) - More audio cleanup targeting the ELD precompute readout (Ville) - Enable DC power states on all eDP ports (Imre) - RPL-P stepping info (Matt Atwood) - MTL enabling patches (RK) - Removal of DG2 force_probe (Matt) Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-intel-gt-next-2022-11-18' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Core Changes: - Backmerge of drm-next Driver Changes: - Restore probe_range behaviour for userptr (Matt A) - Fix use-after-free on lmem_userfault_list (Matt A) - Never purge busy TTM objects (Matt A) - Meteorlake enabling (Daniele, Badal, Daniele, Stuart, Aravind, Alan) - Demote GuC kernel contexts to normal priority (John) - Use RC6 residency types as arguments to residency functions (Ashutosh, Rodrigo, Jani) - Convert some legacy DRM debugging macros to new ones (Tvrtko) - Don't deadlock GuC busyness stats vs reset (John) - Remove excessive line feeds in GuC state dumps (John) - Use i915_sg_dma_sizes() for all backends (Matt A) - Prefer REG_FIELD_GET in intel_rps_get_cagf (Ashutosh, Rodrigo) - Use GEN12_RPSTAT register for GT freq (Don, Badal, Ashutosh) - Remove unwanted TTM ghost obj check (Matt A) - Update workaround documentation (Lucas) - Coding style and static checker fixes and cleanups (Jani, Umesh, Tvrtko, Lucas, Andrzej) - Selftest improvements (Chris, Daniele, Riana, Andrzej) Signed-off-by:
-
https://gitlab.freedesktop.org/agd5f/linuxDave Airlie authored
amd-drm-next-6.2-2022-11-18: amdgpu: - SR-IOV fixes - Clean up DC checks - DCN 3.2.x fixes - DCN 3.1.x fixes - Don't enable degamma on asics which don't support it - IP discovery fixes - BACO fixes - Fix vbios allocation handling when vkms is enabled - Drop buggy tdr advanced mode GPU reset handling - Fix the build when DCN is not set in kconfig - MST DSC fixes - Userptr fixes - FRU and RAS EEPROM fixes - VCN 4.x RAS support - Aldrebaran CU occupancy reporting fix - PSP ring cleanup amdkfd: - Memory limit fix - Enable cooperative launch on gfx 10.3 amd-drm-next-6.2-2022-11-11: amdgpu: - SMU 13.x updates - GPUVM TLB race fix - DCN 3.1.4 updates - DCN 3.2.x updates - PSR fixes - Kerneldoc fix - Vega10 fan fix - GPUVM locking fixes in error pathes - BACO fix for Beige Goby - EEPROM I2C address cleanup - GFXOFF fix - Fix DC memory leak in error pathes - Flexible array updates - Mtype fix for GPUVM PTEs - Move Kconfig into amdgpu directory - SR-IOV updates - Fix possible memory leak in CS IOCTL error path amdkfd: - Fix possible memory overrun - CRIU fixes radeon: - ACPI ref count fix - HDA audio notifier support - Move Kconfig into radeon directory UAPI: - Add new GEM_CREATE flags to help to transition more KFD functionality to the DRM UAPI. These are used internally in the driver to align location based memory coherency requirements from memory allocated in the KFD with how we manage GPUVM PTEs. They are currently blocked in the GEM_CREATE IOCTL as we don't have a user right now. They are just used internally in the kernel driver for now for existing KFD memory allocations. So a change to the UAPI header, but no functional change in the UAPI. From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221118170807.6505-1-alexander.deucher@amd.comSigned-off-by:
-
