- 29 Nov, 2022 1 commit
-
-
Jani Nikula authored
The file uses bool and struct completion, include the relevant headers. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221123130932.3863985-1-jani.nikula@intel.com
-
- 28 Nov, 2022 11 commits
-
-
Maxime Ripard authored
drm_kunit_device_init() is a public function meant to be used by other tests, but isn't exported. This leads to modpost errors when the other tests are compiled as module. Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
Maíra Canal <mairacanal@riseup.net> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221128081938.742410-3-maxime@cerno.tech
-
Shang XiaoJing authored
Commit f0601ef8 ("drm/vc4: vec: Protect device resources after removal") add fail path for vc4_vec_encoder_enable(), and will put usage_counter only when pm_runtime_get_sync() succeeds. However, pm_runtime_get_sync() will increment usage_counter even it failed. Fix it by replacing it with pm_runtime_resume_and_get() to keep usage counter balanced. Fixes: e4b81f8c ("drm/vc4: Add support for the VEC (Video Encoder) IP") Signed-off-by:
Shang XiaoJing <shangxiaojing@huawei.com> Link: https://lore.kernel.org/r/20221124015113.18540-1-shangxiaojing@huawei.comSigned-off-by:
-
Maxime Ripard authored
It's fairly hard to figure out the instance of the CRTC affected by an atomic change using the default name. Since we can provide our own to the CRTC initialization functions, let's do so to make the debugging sessions easier. Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
-
Maxime Ripard authored
Both users of vc4_crtc_init need the same extra initialization to set the pointer to the platform_device and the CRTC data. Since it's mandatory, let's make them both arguments of vc4_crtc_init(). Reviewed-by:
-
Maxime Ripard authored
It makes more sense to register the CRTC before the encoder and connectors, so let's move our call around. Reviewed-by:
-
Maxime Ripard authored
The TXP is integrated as a separate CRTC/Encoder/Connector combo, but for some reason doesn't rely on the vc4_encoder type and it's associated type. Let's create a type to make it consistent with the other encoders. Reviewed-by:
-
Maxime Ripard authored
The current order of variable assignments is unneccessarily complex, let's make it simpler. Reviewed-by:
-
Maxime Ripard authored
On the vc4 devices (and later), the blending is done by a single device called the HVS. The HVS has three FIFO that can operate in parallel, and route their output to 6 CRTCs and 7 encoders on the BCM2711. Each of these CRTCs and encoders have some constraints on which FIFO they can feed from, so we need some code to take all those constraints into account and assign FIFOs to CRTCs. The problem can be simplified by assigning those FIFOs to CRTCs by ascending output index number. We had a comment mentioning it already, but we were never actually enforcing it. It was working still in most situations because the probe order is roughly equivalent, except for the (optional, and fairly rarely used on the Pi4) VEC which was last in the probe order sequence, but one of the earliest device to assign. This resulted in configurations that were rejected by our code but were still valid with a different assignment. We can fix this by making sure we assign CRTCs to FIFOs by ordering them by ascending HVS output index. Fixes: 87ebcd42 ("drm/vc4: crtc: Assign output to channel automatically") Reviewed-by:
-
Maxime Ripard authored
The vc4_hvs_get_(old|new)_global_state functions don't modify the drm_atomic_state passed as an argument, so let's make it const. Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v1-13-051a0bb60a16@cerno.techReviewed-by:
-
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:
-
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 26 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:
-
