Maíra Canal [Wed, 11 Jan 2023 13:13:05 +0000 (10:13 -0300)]
drm/vkms: reintroduce prepare_fb and cleanup_fb functions
With commit 359c6649cd9a ("drm/gem: Implement shadow-plane {begin,
end}_fb_access with vmap"), the behavior of the shadow-plane helpers
changed and the vunmap is now performed at the end of
the current pageflip, instead of the end of the following pageflip.
By performing the vunmap at the end of the current pageflip, invalid
memory is accessed by the vkms during the plane composition, as the data
is being unmapped before being used, as reported by the following
warning:
Therefore, introduce again prepare_fb and cleanup_fb functions to the
vkms, which were previously removed on commit b43e2ec03b0d ("drm/vkms:
Let shadow-plane helpers prepare the plane's FB").
Fixes: 359c6649cd9a ("drm/gem: Implement shadow-plane {begin, end}_fb_access with vmap") Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maíra Canal <mcanal@igalia.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230111131304.106039-1-mcanal@igalia.com
Daniel Vetter [Mon, 9 Jan 2023 16:46:04 +0000 (17:46 +0100)]
drm: document better that drivers shouldn't use drm_minor directly
The documentation for struct drm_minor already states this, but that's
not always that easy to find.
Also due to historical reasons we still have the minor-centric
interfaces (like drm_debugfs_create_files), but since this is now
getting fixed we can put a few more pointers in place as to how this
should be done ideally. Note that debugfs isn't there yet for all
cases (debugfs files on kms objects like crtc/connector aren't
supported, neither debugfs files with full fops), so the debugfs side
of this is still rather aspirational and more for new users than
converting everything existing. todo.rst covers the additional work
needed already.
Motivated by some discussion with Rodrigo on irc about how drm/xe
should lay out its sysfs interfaces.
v2: Make the debugfs situation clearer in the commit message, but
don't elaborate more in the actual kerneldoc to avoid distracting from
the main message around sysfs (Jani)
Abel Vesa [Sat, 31 Dec 2022 14:27:20 +0000 (16:27 +0200)]
drm/panel-edp: fix name for IVO product id 854b
The actual name is R133NW4K-R0.
Fixes: 0f9fa5f58c78 ("drm/panel-edp: add IVO M133NW4J-R3 panel entry") Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Steev Klimaszewski <steev@kali.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221231142721.338643-1-abel.vesa@linaro.org
Uwe Kleine-König [Fri, 30 Dec 2022 13:00:24 +0000 (14:00 +0100)]
drm/imx/dcss: Drop if blocks with always false condition
dcss_drv_platform_remove() is only called for a device after
dcss_drv_platform_probe() returned 0. In that case dev_set_drvdata() was
called with a non-NULL value and so dev_get_drvdata() won't return NULL.
Maíra Canal [Thu, 5 Jan 2023 19:30:39 +0000 (16:30 -0300)]
drm/debugfs: add descriptions to struct parameters
The structs drm_debugfs_info and drm_debugfs_entry don't have
descriptions for their parameters, which is causing the following warnings:
include/drm/drm_debugfs.h:93: warning: Function parameter or member
'name' not described in 'drm_debugfs_info'
include/drm/drm_debugfs.h:93: warning: Function parameter or member
'show' not described in 'drm_debugfs_info'
include/drm/drm_debugfs.h:93: warning: Function parameter or member
'driver_features' not described in 'drm_debugfs_info'
include/drm/drm_debugfs.h:93: warning: Function parameter or member
'data' not described in 'drm_debugfs_info'
include/drm/drm_debugfs.h:105: warning: Function parameter or member
'dev' not described in 'drm_debugfs_entry'
include/drm/drm_debugfs.h:105: warning: Function parameter or member
'file' not described in 'drm_debugfs_entry'
include/drm/drm_debugfs.h:105: warning: Function parameter or member
'list' not described in 'drm_debugfs_entry'
Therefore, fix the warnings by adding descriptions to all struct
parameters.
Maíra Canal [Thu, 5 Jan 2023 19:30:38 +0000 (16:30 -0300)]
drm/debugfs: use octal permissions instead of symbolic permissions
Currently, debugfs functions are using symbolic macros as permission
bits, but checkpatch reinforces permission bits in the octal form, as
they are more readable and easier to understand [1]. Moreover, using
the symbolic macro S_IFREG is redundant.
Therefore, use octal permission bits in all debugfs functions.
Add device tree bindings for panels based on the Himax HX8394 controller,
such as the HannStar HSD060BHW4 720x1440 TFT LCD panel that is connected
through a MIPI-DSI video interface.
Simon Ser [Mon, 28 Nov 2022 13:39:05 +0000 (13:39 +0000)]
doc: add dma-buf IOCTL code to table
The code 'b' is used for dma-buf IOCTLs.
Signed-off-by: Simon Ser <contact@emersion.fr> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Christian König <christian.koenig@amd.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221128133853.355645-1-contact@emersion.fr
Uwe Kleine-König [Mon, 19 Dec 2022 08:53:07 +0000 (09:53 +0100)]
MAINTAINERS: drm/hisilicon: Drop Chen Feng
The listed address doesn't work any more:
puck.chen@hisilicon.com
host mx5.hisilicon.com [124.71.93.234]
SMTP error from remote mail server after RCPT TO:<puck.chen@hisilicon.com>:
551 5.1.1 <puck.chen@hisilicon.com>: Recipient address rejected:
Failed recipient validation check.: host 127.0.0.1[127.0.0.1] said:
554 5.7.1 recipient verify from ldap failed (in reply to RCPT TO command)
Uwe Kleine-König [Mon, 19 Dec 2022 08:36:27 +0000 (09:36 +0100)]
drm: Only select I2C_ALGOBIT for drivers that actually need it
While working on a drm driver that doesn't need the i2c algobit stuff I
noticed that DRM selects this code even though only 8 drivers actually use
it. While also only some drivers use i2c, keep the select for I2C for the
next cleanup patch. Still prepare this already by also selecting I2C for
the individual drivers.
Uwe Kleine-König [Tue, 10 Jan 2023 09:38:20 +0000 (10:38 +0100)]
drm/mxsfb: improve clk handling for axi clk
Ignoring errors from devm_clk_get() is wrong. To handle not all platforms
having an axi clk use devm_clk_get_optional() instead and do proper error
handling.
Also the clk API handles NULL as a dummy clk (which is also returned by
devm_clk_get_optional() if there is no clk) so there is no need to check
for NULL before calling clk_prepare_enable() or its counter part.
devm_regulator_get_enable_optional() function returns 0 on success, so
use it for the check if function succeeded instead of the -ENODEV value.
Fixes: 429e87063661 ("drm/meson: dw-hdmi: Use devm_regulator_*get_enable*()") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
[narmstrong: s/succeeded/succeeded/ in commit message] Link: https://patchwork.freedesktop.org/patch/msgid/20230109220033.31202-1-m.szyprowski@samsung.com
Neil Armstrong [Mon, 9 Jan 2023 08:49:30 +0000 (09:49 +0100)]
drm/panel: add visionox vtdr6130 DSI panel driver
Add support for the 1080x2400 Visionox VTDR6130 AMOLED DSI panel
found on the Qualcomm SM8550 MTP board.
By default the the panel is configured to work with DSI compressed
streams, but can work in uncompressed video mode since 1080x2400 in
RGB888 fits in the 4 DSI lanes bandwidth.
While display compression is preferred for performance and power
reasons, let's start with the uncompressed video mode support and
add the DSC support later on.
Dave Stevenson [Wed, 7 Dec 2022 11:53:25 +0000 (12:53 +0100)]
drm/vc4: hdmi: Correct interlaced timings again
The back porch timings were correct, only the sync offset was wrong.
Correct timing is now reported for 1080i and 576i, but the h offset is
incorrect for 480i for non-obvious reasons.
Mateusz Kwiatkowski [Wed, 7 Dec 2022 11:53:24 +0000 (12:53 +0100)]
drm/vc4: crtc: Fix timings for VEC modes
This commit fixes vertical timings of the VEC (composite output) modes
to accurately represent the 525-line ("NTSC") and 625-line ("PAL") ITU-R
standards.
Previous timings were actually defined as 502 and 601 lines, resulting
in non-standard 62.69 Hz and 52 Hz signals being generated,
respectively.
Changes to vc4_crtc.c have also been made, to make the PixelValve
vertical timings accurately correspond to the DRM modeline in interlaced
modes. The resulting VERTA/VERTB register values have been verified
against the reference values set by the Raspberry Pi firmware.
Dave Stevenson [Wed, 7 Dec 2022 11:53:21 +0000 (12:53 +0100)]
drm/vc4: plane: Omit pixel_order from the hvs_format for hvs5 only formats
pixel_order is used for the earlier versions of the HVS, so is
redundant on the 10:10:10:2 and 10bit YUV formats that are only
supported on HVS5.
Remove the assignment from the table to avoid confusion.
Dave Stevenson [Wed, 7 Dec 2022 11:53:17 +0000 (12:53 +0100)]
drm/vc4: hvs: Fix colour order for xRGB1555 on HVS5
Same as the xRGB8888 formats, HVS5 has managed to swap the colour
channels for the xRGB1555 formats as well. Add the relevant
config for pixel_order_hvs5.
Dave Stevenson [Wed, 7 Dec 2022 11:53:14 +0000 (12:53 +0100)]
drm/vc4: hvs: SCALER_DISPBKGND_AUTOHS is only valid on HVS4
The bit used for SCALER_DISPBKGND_AUTOHS in SCALER_DISPBKGNDX
has been repurposed on HVS5 to configure whether a display can
win back-to-back arbitration wins for the COB.
This is not desirable, therefore only select this bit on HVS4,
and explicitly clear it on HVS5.
Dave Stevenson [Wed, 7 Dec 2022 11:53:13 +0000 (12:53 +0100)]
drm/vc4: hvs: Set AXI panic modes
The HVS can change AXI request mode based on how full the COB
FIFOs are.
Until now the vc4 driver has been relying on the firmware to
have set these to sensible values.
With HVS channel 2 now being used for live video, change the
panic mode for all channels to be explicitly set by the driver,
and the same for all channels.
Dave Stevenson [Wed, 7 Dec 2022 11:53:12 +0000 (12:53 +0100)]
drm/vc4: hvs: Configure the HVS COB allocations
The HVS Composite Output Buffer (COB) is the memory used to
generate the output pixel data.
Until now the vc4 driver has been relying on the firmware to
have set these to sensible values.
In testing triple screen support it has been noted that only
1 line was being assigned to HVS channel 2. Whilst that is fine
for the transposer (TXP), and indeed needed as only some pixels
have an alpha channel, it is insufficient to run a live display.
Split the COB more evenly between the 3 HVS channels.
Javier Martinez Canillas [Mon, 2 Jan 2023 20:25:42 +0000 (21:25 +0100)]
drm/mipi-dsi: Add a mipi_dsi_dcs_write_seq() macro
Many panel drivers define dsi_dcs_write_seq() and dsi_generic_write_seq()
macros to send DCS commands and generic write packets respectively, with
the payload specified as a list of parameters instead of using arrays.
There's already a macro for the former, introduced by commit 2a9e9daf75231
("drm/mipi-dsi: Introduce mipi_dsi_dcs_write_seq macro") so drivers can be
changed to use that. But there isn't one yet for the latter, let's add it.
Maíra Canal [Mon, 26 Dec 2022 15:50:23 +0000 (12:50 -0300)]
drm/arm/hdlcd: use new debugfs device-centered functions
Replace the use of drm_debugfs_create_files() with the new
drm_debugfs_add_files() function, which center the debugfs files
management on the drm_device instead of drm_minor. Moreover, remove the
debugfs_init hook and add the debugfs files directly on hdlcd_drm_bind(),
before drm_dev_register().
Maíra Canal [Mon, 26 Dec 2022 15:50:22 +0000 (12:50 -0300)]
drm/gud: use new debugfs device-centered functions
Replace the use of drm_debugfs_create_files() with the new
drm_debugfs_add_file() function, which center the debugfs files
management on the drm_device instead of drm_minor. Moreover, remove the
debugfs_init hook and add the debugfs files directly on gud_probe(),
before drm_dev_register().
Thomas Zimmermann [Fri, 6 Jan 2023 11:23:24 +0000 (12:23 +0100)]
drm/fb-helper: Replace bpp/depth parameter by color mode
Replace the combination of bpp and depth with a single color-mode
argument. Handle special cases in simpledrm and ofdrm. Hard-code
XRGB8888 as fallback format for cases where no given format works.
The color-mode argument accepts the same values as the kernel's video
parameter. These are mostly bpp values between 1 and 32. The exceptions
are 15, which has a color depth of 15 and a bpp value of 16; and 32,
which has a color depth of 24 and a bpp value of 32.
v4:
* add back lost test for bpp_specified (Maira)
* add Fixes tag (Daniel)
v3:
* fix ofdrm build (Maxime)
v2:
* minimize changes (Daniel)
* use drm_driver_legacy_fb_format() (Daniel)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Maíra Canal <mcanal@igalia.com> # vc4 and vkms Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: 37c90d589dc0 ("drm/fb-helper: Fix single-probe color-format selection") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230106112324.22055-1-tzimmermann@suse.de
Dmitry Baryshkov [Wed, 2 Nov 2022 18:07:05 +0000 (21:07 +0300)]
drm/bridge_connector: drop drm_bridge_connector_en/disable_hpd()
Now as all drivers stopped calling drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() it is safe to remove them complelely.
Rename our internal helpers to remove the underscore prefix.
Dmitry Baryshkov [Wed, 2 Nov 2022 18:07:04 +0000 (21:07 +0300)]
drm/omap: stop using drm_bridge_connector_en/disable_hpd()
The functionality of drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() is provided automatically by the
drm_kms_poll helpers. Stop calling these functions manually.
Dmitry Baryshkov [Wed, 2 Nov 2022 18:07:03 +0000 (21:07 +0300)]
drm/msm/hdmi: stop using drm_bridge_connector_en/disable_hpd()
The functionality of drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() is provided automatically by the
drm_kms_poll helpers. Stop calling these functions manually.
Dmitry Baryshkov [Wed, 2 Nov 2022 18:07:02 +0000 (21:07 +0300)]
drm/imx/dcss: stop using drm_bridge_connector_en/disable_hpd()
The functionality of drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() is provided automatically by the
drm_kms_poll helpers. Stop calling these functions manually.
Dmitry Baryshkov [Wed, 2 Nov 2022 18:07:01 +0000 (21:07 +0300)]
drm/bridge_connector: rely on drm_kms_helper_poll_* for HPD enablement
Use drm_connector's helpers enable_hpd and disable_hpd to enable and
disable HPD automatically by the means of drm_kms_helper_poll_*
functions. As the drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() functions are now unused, replace
them with stubs to ease driver migration.
Enabling the HPD from drm_bridge_connector_init() can happen too early,
before the driver is prepared to handle HPD events. As the
drm_bridge_connector_enable_hpd() is empty anyway, drop this call
anyway.
Dmitry Baryshkov [Wed, 2 Nov 2022 18:07:00 +0000 (21:07 +0300)]
drm/probe-helper: enable and disable HPD on connectors
Introduce two drm_connector_helper_funcs: enable_hpd() and disable_hpd().
They are called by drm_kms_helper_poll_enable() and
drm_kms_helper_poll_disable() (and thus drm_kms_helper_poll_init() and
drm_kms_helper_poll_fini()) respectively.
This allows DRM drivers to rely on drm_kms_helper_poll for enabling and
disabling HPD detection rather than doing that manually.
Daniel Vetter [Wed, 23 Nov 2022 19:24:37 +0000 (20:24 +0100)]
drm/fourcc: Document open source user waiver
It's a bit a FAQ, and we really can't claim to be the authoritative
source for allocating these numbers used in many standard extensions
if we tell closed source or vendor stacks in general to go away.
Iirc this was already clarified in some vulkan discussions, but I
can't find that anywhere anymore. At least not in a public link.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Neil Trevett <ntrevett@nvidia.com> Acked-by: Daniel Stone <daniels@collabora.com> Acked-by: Maxime Ripard <maxime@cerno.tech> Acked-by: David Airlie <airlied@gmail.com> Acked-by: Marek Olšák <maraeo@gmail.com> Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Acked-by: Jason Ekstrand <jason.ekstrand@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221123192437.1065826-1-daniel.vetter@ffwll.ch
Maxime Ripard [Mon, 2 Jan 2023 12:01:23 +0000 (13:01 +0100)]
drm/bridge: panel: Prevent ERR_PTR Dereference
Commit 5ea6b1702781 ("drm/panel: Add prepare_prev_first flag to
drm_panel") introduced an access to the bridge pointer in the
devm_drm_panel_bridge_add_typed() function.
However, due to the unusual ERR_PTR check when getting that pointer, the
pointer access is done even though the pointer might be an error
pointer.
Rework the function for a more traditional design that will return
immediately if it gets an ERR_PTR so that we never access the pointer in
that case.
Add a paragraph explaining that the default behavior for areas which
are not covered by planes or where planes are blending with the CRTC
background, is black.
This is alluded to in the "pixel blend mode" property docs, but not
called out explicitly.
Maíra Canal [Tue, 27 Dec 2022 20:00:11 +0000 (17:00 -0300)]
drm/v3d: replace open-coded implementation of drm_gem_object_lookup
As v3d_submit_tfu_ioctl() performs the same steps as
drm_gem_object_lookup(), replace the open-code implementation in v3d
with its DRM core equivalent.
Drivers only emulate XRGB8888 framebuffers. Remove all conversion
helpers that do not use XRGB8888 as their source format. Also remove
some special cases for alpha formats in the blit helper.
The DRM helper drm_fb_build_fourcc_list() creates a list of color
formats for primary planes of the generic drivers. Simplify the helper:
- It used to mix and filter native and emulated formats as provided
by the driver. Now the only emulated format is XRGB8888, which is
required as fallback by legacy software. Drop support for emulating
any other formats.
- Also convert alpha formats to their non-alpha counterparts. Generic
drivers don't support primary planes with alpha formats and some
DTs incorrectly advertise alpha channels for non-alpha hardware. So
only export non-alpha formats for primary planes.
With the simplified helper, scrap format lists of the affected generic
drivers. All they need is the firmware buffer's native format, from which
the helper creates the list of color formats.
Fix the color-format selection of the single-probe helper. Go
through all user-specified values and test each for compatibility
with the driver. If none is supported, use the driver-provided
default. This guarantees that the console is always available in
any color format at least.
Until now, the format selection of the single-probe helper tried
to either use a user-specified format or a 32-bit default format.
If the user-specified format was not supported by the driver, the
selection failed and the display remained blank.
Thomas Zimmermann [Mon, 2 Jan 2023 11:29:24 +0000 (12:29 +0100)]
drm/fh-helper: Split fbdev single-probe helper
Split the single-probe helper's implementation into multiple
functions and get locking and overallocation out of the way of
the surface setup. Simplifies later changes to the setup code.
Thomas Zimmermann [Mon, 2 Jan 2023 11:29:23 +0000 (12:29 +0100)]
drm/format-helper: Add conversion from XRGB8888 to 15-bit RGB555 formats
Add conversion from XRGB8888 to XRGB1555, ARGB1555 and RGBA5551, which
are the formats currently supported by the simplefb infrastructure. The
new helpers allow the output of XRGB8888 framebuffers to firmware
scanout buffers in one of the 15-bit formats.
v3:
* use __le* for destination buffers (Jose, kernel test robot)
v2:
* test 15-bit results with local endianness (Jose)
Thomas Zimmermann [Mon, 2 Jan 2023 11:29:20 +0000 (12:29 +0100)]
drm/format-helper: Flip src/dst-format branches in blit helper
Upcoming changes to the format conversion will mostly blit from
XRGB8888 to some other format. So put the source format in blit's
outer branches to make the code more readable. For cases where
a format only changes its endianness, such as XRGB565, introduce
dedicated branches that handle this for all formats.
Thomas Zimmermann [Mon, 2 Jan 2023 11:29:19 +0000 (12:29 +0100)]
drm/format-helper: Type fixes in format-helper tests
Change the source-buffer type of le32buf_to_cpu() to __le32* to
reflect endianness. Result buffers are converted to local endianness,
so instantiate them from regular u8 or u32 types.
Thomas Zimmermann [Mon, 2 Jan 2023 11:29:17 +0000 (12:29 +0100)]
drm/format-helper: Fix test-input format conversion
Convert test input for format helpers from host byte order to
little-endian order. The current code does it the other way around,
but there's no effective difference to the result.
Thomas Zimmermann [Mon, 2 Jan 2023 11:29:16 +0000 (12:29 +0100)]
drm/format-helper: Comment on RGB888 byte order
RGB888 is different than the other formats as most of its pixels are
unaligned and therefore helper functions do not use endianness conversion
helpers. Comment on this in the source code.
Thomas Zimmermann [Mon, 2 Jan 2023 11:29:15 +0000 (12:29 +0100)]
firmware/sysfb: Fix EFI/VESA format selection
Select color format for EFI/VESA firmware scanout buffer from the
number of bits per pixel and the position of the individual color
components. Fixes the selected format for the buffer in several odd
cases. For example, XRGB1555 has been reported as ARGB1555 because
of the different use of depth and transparency in VESA and Linux.
Bits-per-pixel is always the pixel's raw number of bits; including
alpha and filler bits. It is preferred over color depth, which has a
different meaning among various components and standards.
Also do not compare reserved bits and transparency bits to each other.
These values have different meanings, as reserved bits include filler
bits while transparency does not.
Dave Stevenson [Thu, 22 Dec 2022 18:52:13 +0000 (18:52 +0000)]
drm/bridge: panel: Set pre_enable_prev_first from drmm_panel_bridge_add
Commit 5ea6b1702781 ("drm/panel: Add prepare_prev_first flag to drm_panel")
added code to copy prepare_prev_first from drm_panel to pre_enable_prev_first
in drm_bridge when called through devm_panel_bridge_add, but
missed drmm_panel_bridge_add.
Maíra Canal [Thu, 29 Dec 2022 19:46:38 +0000 (16:46 -0300)]
drm/vc4: drop all currently held locks if deadlock happens
If vc4_hdmi_reset_link() returns -EDEADLK, it means that a deadlock
happened in the locking context. This situation should be addressed by
dropping all currently held locks and block until the contended lock
becomes available. Currently, vc4 is not dealing with the deadlock
properly, producing the following output when PROVE_LOCKING is enabled:
Carlo Caione [Mon, 19 Dec 2022 09:02:38 +0000 (10:02 +0100)]
drm/tiny: ili9486: Do not assume 8-bit only SPI controllers
The pixel data for the ILI9486 is always 16-bits wide and it must be
sent over the SPI bus. When the controller is only able to deal with
8-bit transfers, this 16-bits data needs to be swapped before the
sending to account for the big endian bus, this is on the contrary not
needed when the SPI controller already supports 16-bits transfers.
The decision about swapping the pixel data or not is taken in the MIPI
DBI code by probing the controller capabilities: if the controller only
suppors 8-bit transfers the data is swapped, otherwise it is not.
This swapping/non-swapping is relying on the assumption that when the
controller does support 16-bit transactions then the data is sent
unswapped in 16-bits-per-word over SPI.
The problem with the ILI9486 driver is that it is forcing 8-bit
transactions also for controllers supporting 16-bits, violating the
assumption and corrupting the pixel data.
Align the driver to what is done in the MIPI DBI code by adjusting the
transfer size to the maximum allowed by the SPI controller.
Maíra Canal [Mon, 19 Dec 2022 12:06:21 +0000 (09:06 -0300)]
drm/todo: update the debugfs clean up task
The structs drm_debugfs_info and drm_debugfs_entry introduced a new
debugfs structure to DRM, centered on drm_device instead of drm_minor.
Therefore, remove the tasks related to create a new device-centered
debugfs structure and add a new task to replace the use of
drm_debugfs_create_files() for the use of drm_debugfs_add_file() and
drm_debugfs_add_files().
Maíra Canal [Mon, 19 Dec 2022 12:06:20 +0000 (09:06 -0300)]
drm/vkms: use new debugfs device-centered functions
Replace the use of drm_debugfs_create_files() with the new
drm_debugfs_add_files() function, which centers the debugfs files
management on the drm_device instead of drm_minor. Moreover, remove the
debugfs_init hook and add the debugfs files directly on vkms_create(),
before drm_dev_register().
Maíra Canal [Mon, 19 Dec 2022 12:06:19 +0000 (09:06 -0300)]
drm/v3d: use new debugfs device-centered functions
Replace the use of drm_debugfs_create_files() with the new
drm_debugfs_add_files() function, which centers the debugfs files
management on the drm_device instead of drm_minor.
Maíra Canal [Mon, 19 Dec 2022 12:06:18 +0000 (09:06 -0300)]
drm/vc4: use new debugfs device-centered functions
Currently, vc4 has its own debugfs infrastructure that adds the debugfs
files on drm_dev_register(). With the introduction of the new debugfs,
functions, replace the vc4 debugfs structure with the DRM debugfs
device-centered function, drm_debugfs_add_file().
Moreover, remove the explicit error handling of debugfs related functions,
considering that the only failure mode is -ENOMEM and also that error
handling is not recommended for debugfs functions, as pointed out in [1].
Maíra Canal [Mon, 19 Dec 2022 12:06:17 +0000 (09:06 -0300)]
drm/debugfs: create debugfs late register functions
Although the device-centered debugfs functions can track requests for
the addition of DRM debugfs files at any time and have them added all
at once during drm_dev_register(), they are not able to create debugfs
files for modeset components, as they are registered after the primary
and the render drm_minor are registered.
So, create a drm_debugfs_late_register() function, which is responsible
for dealing with the creation of all the debugfs files for modeset
components at once. Therefore, the functions drm_debugfs_add_file()
and drm_debugfs_add_files() can be used in late_register hooks.
Maíra Canal [Mon, 19 Dec 2022 12:06:16 +0000 (09:06 -0300)]
drm: use new debugfs device-centered functions on DRM core files
Replace the use of drm_debugfs_create_files() with the new
drm_debugfs_add_files() function in all DRM core files, centering the
debugfs files management on the drm_device instead of drm_minor.
Introduce the ability to track requests for the addition of DRM debugfs
files at any time and have them added all at once during
drm_dev_register().
Drivers can add DRM debugfs files to a device-managed list and, during
drm_dev_register(), all added files will be created at once.
Now, the drivers can use the functions drm_debugfs_add_file() and
drm_debugfs_add_files() to create DRM debugfs files instead of using the
drm_debugfs_create_files() function.
projects / users / jedix / linux-maple.git / log