Sam Ravnborg [Fri, 31 May 2024 20:37:45 +0000 (22:37 +0200)]
drm/mediatek: Drop chain_mode_fixup call in mode_valid()
The mode_valid implementation had a call to
drm_bridge_chain_mode_fixup() which would be wrong as the mode_valid is
not allowed to change anything - only to validate the mode.
As the next bridge is often/always a connector the call had no effect
anyway. So drop it.
From the git history I could see this call was included in the original
version of the driver so there was no help there to find out why it was
added in the first place. But a lot has changed since the initial driver
were added and is seems safe to remove the call now.
v4:
- Link to v3: https://lore.kernel.org/dri-devel/
20220717174454.46616-4-sam@ravnborg.org/
- Rebase, and added acks/rb
v3:
- Link to v2: https://lore.kernel.org/dri-devel/
20211020181901.
2114645-6-sam@ravnborg.org/
v2:
- Link to v1: https://lore.kernel.org/dri-devel/
20210722062246.
2512666-6-sam@ravnborg.org/
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Cc: linux-mediatek@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240531-bridge_chain_mode-v1-1-8b49e36c5dd3@ravnborg.org
Jocelyn Falempe [Mon, 3 Jun 2024 09:47:27 +0000 (11:47 +0200)]
drm/panic: Add a kmsg panic screen
Add a kmsg option, which will display the last lines of kmsg,
and should be similar to fbcon.
Add a drm.panic_screen module parameter, so you can choose between
the different panic screens available.
two options currently, but more will be added later:
* "user": a short message telling the user to reboot the machine.
* "kmsg": fill the screen with the last lines of kmsg.
You can even change it at runtime by writing to
/sys/module/drm/parameters/panic_screen
v2:
* Use module parameter instead of Kconfig choice
(Javier Martinez Canillas)
v3:
* Add help for module parameter usage in Kconfig
(Javier Martivez Canillas)
* Fix use of font->height before checking it isn't null.
(kernel test robot, Dan Carpenter)
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240603095343.39588-4-jfalempe@redhat.com
Jocelyn Falempe [Mon, 3 Jun 2024 09:47:26 +0000 (11:47 +0200)]
drm/panic: Add a set_pixel() callback to drm_scanout_buffer
This allows drivers to draw the pixel, and handle tiling, or specific
color formats.
v2:
* Use fg_color for blit() functions (Javier Martinez Canillas)
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240603095343.39588-3-jfalempe@redhat.com
Jocelyn Falempe [Mon, 3 Jun 2024 09:47:25 +0000 (11:47 +0200)]
drm/panic: only draw the foreground color in drm_panic_blit()
The whole framebuffer is cleared, so it's useless to rewrite the
background colored pixels. It allows to simplify the drawing
functions, and prepare the work for the set_pixel() callback.
v2:
* keep fg16/fg24/fg32 as variable name for the blit function.
* add drm_panic_is_pixel_fg() to avoid code duplication.
both suggested by Javier Martinez Canillas
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240603095343.39588-2-jfalempe@redhat.com
Ondrej Jirman [Sat, 24 Feb 2024 15:06:00 +0000 (16:06 +0100)]
drm/sun4i: Fix layer zpos change/atomic modesetting
Identical configurations of planes can lead to different (and wrong)
layer -> pipe routing at HW level, depending on the order of atomic
plane changes.
For example:
- Layer 1 is configured to zpos 0 and thus uses pipe 0. No other layer
is enabled. This is a typical situation at boot.
- When a compositor takes over and layer 3 is enabled,
sun8i_ui_layer_enable() will get called with old_zpos=0 zpos=1, which
will lead to incorrect disabling of pipe 0 and enabling of pipe 1.
What happens is that sun8i_ui_layer_enable() function may disable
blender pipes even if it is no longer assigned to its layer.
To correct this, move the routing setup out of individual plane's
atomic_update into crtc's atomic_update, where it can be calculated
and updated all at once.
Remove the atomic_disable callback because it is no longer needed.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20240224150604.3855534-4-megi@xff.cz
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Ondrej Jirman [Sat, 24 Feb 2024 15:05:59 +0000 (16:05 +0100)]
drm/sun4i: Add more parameters to sunxi_engine commit callback
These will be needed later on when we move layer configuration to
crtc update.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20240224150604.3855534-3-megi@xff.cz
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Ondrej Jirman [Sat, 24 Feb 2024 15:05:58 +0000 (16:05 +0100)]
drm/sun4i: Unify sun8i_*_layer structs
These structs are identical, use a single struct to represent private
data for the DRM plane. This is a preparation for configuring layer
routing from the CRTC (mixer) instead of current approach of setting
up routing from individual layer's atomic_update callback.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20240224150604.3855534-2-megi@xff.cz
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Jeff Johnson [Sun, 9 Jun 2024 18:42:53 +0000 (11:42 -0700)]
drm: add missing MODULE_DESCRIPTION() macros
On x86, make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/gud/gud.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/drm_panel_orientation_quirks.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/drm_mipi_dbi.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/i915/kvmgt.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/udl/udl.o
Add the missing invocation of the MODULE_DESCRIPTION() macro to all
files which have a MODULE_LICENSE().
For consistency this includes drivers/gpu/drm/drm_simple_kms_helper.c
since it contains a MODULE_LICENSE() even though it isn't built as a
separate module -- it is always built as part of drm_kms_helper and
drm_kms_helper_common.c already provides a MODULE_DESCRIPTION for that
module.
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240609-md-drivers-gpu-drm-v1-1-89e9a316d513@quicinc.com
Jeff Johnson [Sun, 9 Jun 2024 17:06:17 +0000 (10:06 -0700)]
drm/bridge: add missing MODULE_DESCRIPTION() macros
make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/bridge/lontium-lt9611.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/bridge/lontium-lt9611uxc.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/bridge/sil-sii8620.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/bridge/sii9234.o
Add the missing invocations of the MODULE_DESCRIPTION() macro.
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240609-md-drivers-gpu-drm-bridge-v1-1-b582c5c815d7@quicinc.com
Jeff Johnson [Sun, 9 Jun 2024 17:20:27 +0000 (10:20 -0700)]
drm/tiny: add missing MODULE_DESCRIPTION() macros
make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tiny/bochs.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tiny/cirrus.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tiny/gm12u320.o
Add the missing invocations of the MODULE_DESCRIPTION() macro.
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240609-md-drivers-gpu-drm-tiny-v1-1-6905fe4ada50@quicinc.com
Jeff Johnson [Sun, 9 Jun 2024 16:53:21 +0000 (09:53 -0700)]
drm/panel: add missing MODULE_DESCRIPTION() macros
make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/panel/panel-abt-y030xx067a.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/panel/panel-auo-a030jtn01.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/panel/panel-innolux-ej030na.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/panel/panel-newvision-nv3052c.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/panel/panel-novatek-nt39016.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/panel/panel-orisetech-ota5601a.o
Add the missing invocations of the MODULE_DESCRIPTION() macro.
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240609-md-drivers-gpu-drm-panel-v1-1-04b2a1ae7412@quicinc.com
Jeff Johnson [Fri, 7 Jun 2024 04:42:46 +0000 (21:42 -0700)]
drm/tests: add missing MODULE_DESCRIPTION() macros
make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tests/drm_kunit_helpers.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tests/drm_buddy_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tests/drm_cmdline_parser_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tests/drm_connector_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tests/drm_damage_helper_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tests/drm_dp_mst_helper_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tests/drm_exec_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tests/drm_format_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tests/drm_framebuffer_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tests/drm_gem_shmem_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tests/drm_managed_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tests/drm_mm_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tests/drm_modes_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tests/drm_plane_helper_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tests/drm_probe_helper_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tests/drm_rect_test.o
Add the missing invocations of the MODULE_DESCRIPTION() macro.
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240606-md-drivers-gpu-drm-tests-v1-1-228ca6213969@quicinc.com
Noralf Trønnes [Tue, 4 Jun 2024 13:20:32 +0000 (15:20 +0200)]
drm/tiny: panel-mipi-dbi: Support the pixel format property
Add support for these pixel format property values:
- r5g6b5, RGB565
- b6x2g6x2r6x2, BGR666
BGR666 is presented to userspace as RGB888. The 2 LSB in each color
are discarded by the controller. The pixel is sent on the wire using
8 bits per word (little endian) so the controller sees it as BGR.
RGB565 is the default if the property is not present.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240604-panel-mipi-dbi-rgb666-v4-5-d7c2bcb9b78d@tronnes.org
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Noralf Trønnes [Tue, 4 Jun 2024 13:20:31 +0000 (15:20 +0200)]
drm/mipi-dbi: Add support for DRM_FORMAT_RGB888
DRM_FORMAT_RGB888 is 24 bits per pixel and it would be natural to send it
on the SPI bus using a 24 bits per word transfer. The problem with this
is that not all SPI controllers support 24 bpw.
Since DRM_FORMAT_RGB888 is stored in memory as little endian and the SPI
bus is big endian we use 8 bpw to always get the same pixel format on the
bus: b8g8r8.
The MIPI DCS specification lists the standard commands that can be sent
over the MIPI DBI interface. The set_address_mode (36h) command has one
bit in the parameter that controls RGB/BGR order. This means that the
controller can be configured to receive the pixel as BGR.
RGB888 is rarely supported on these controllers but RGB666 is very common.
All datasheets I have seen do at least support the pixel format option
where each color is sent as one byte and the 6 MSB's are used.
All this put together means that we can send each pixel as b8g8r8 and an
RGB666 capable controller sees this as b6x2g6x2r6x2.
v4:
- s/emulation_format/pixel_format/ (Dmitry)
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240604-panel-mipi-dbi-rgb666-v4-4-d7c2bcb9b78d@tronnes.org
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Noralf Trønnes [Tue, 4 Jun 2024 13:20:30 +0000 (15:20 +0200)]
drm/mipi-dbi: Make bits per word configurable for pixel transfers
MIPI DCS write/set commands have 8 bit parameters except for the
write_memory commands where it depends on the pixel format.
drm_mipi_dbi does currently only support RGB565 which is 16-bit and it
has to make sure that the pixels enters the SPI bus in big endian format
since the MIPI DBI spec doesn't have support for little endian.
drm_mipi_dbi is optimized for DBI interface option 3 which means that the
16-bit bytes are swapped by the upper layer if the SPI bus does not
support 16 bits per word, signified by the swap_bytes member.
In order to support both 16-bit and 24-bit pixel transfers we need a way
to tell the DBI command layer the format of the buffer. Add a
write_memory_bpw member that the upper layer can use to tell how many
bits per word to use for the SPI transfer.
v4:
- Expand the commit message (Dmitry)
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240604-panel-mipi-dbi-rgb666-v4-3-d7c2bcb9b78d@tronnes.org
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Noralf Trønnes [Tue, 4 Jun 2024 13:20:29 +0000 (15:20 +0200)]
drm/mipi-dbi: Remove mipi_dbi_machine_little_endian()
mipi_dbi_machine_little_endian() should really have been called
mipi_dbi_framebuffer_little_endian() because that's the function it
performs. When I added support for these SPI displays I thought that the
framebuffers on big endian machines were also big endian, but I have
later learned that this is not the case. There's a bit in the fourcc code
that controls this: DRM_FORMAT_BIG_ENDIAN.
Just remove the function to avoid confusion. We can add big endian support
later should the need arise and we have hardware to test on.
Instead of just amending the docs, expand it to explain the endianness
handling.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240604-panel-mipi-dbi-rgb666-v4-2-d7c2bcb9b78d@tronnes.org
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Noralf Trønnes [Tue, 4 Jun 2024 13:20:28 +0000 (15:20 +0200)]
dt-bindings: display: panel: mipi-dbi-spi: Add a pixel format property
The MIPI DBI 2.0 specification (2005) lists only two pixel formats for
the Type C Interface (SPI) and that is 3-bits/pixel RGB111 with
2 options for bit layout.
For Type A and B (parallel) the following formats are listed: RGB332,
RGB444, RGB565, RGB666 and RGB888 (some have 2 options for the bit layout).
Many MIPI DBI compatible controllers support all interface types on the
same chip and often the manufacturers have chosen to provide support for
the Type A/B interface pixel formats also on the Type C interface.
Some chips provide many pixel formats with optional bit layouts over SPI,
but the most common by far are RGB565 and RGB666. So even if the
specification doesn't list these formats for the Type C interface, the
industry has chosen to include them.
The MIPI DCS specification lists the standard commands that can be sent
over the MIPI DBI interface. The set_address_mode (36h) command has one
bit in the parameter that controls RGB/BGR order:
This bit controls the RGB data latching order transferred from the
peripheral’s frame memory to the display device.
This means that each supported RGB format also has a BGR variant.
Based on this rationale document the following pixel formats describing
the bit layout going over the wire:
- RGB111 (option 1): x2r1g1b1r1g1b1 (2 pixels per byte)
- BGR111 (option 1): x2b1g1r1b1g1r1 (2 pixels per byte)
- RGB111 (option 2): x1r1g1b1x1r1g1b1 (2 pixels per byte)
- BGR111 (option 2): x1b1g1r1x1b1g1r1 (2 pixels per byte)
- RGB565: r5g6b5 (2 bytes)
- BGR565: b5g6r5 (2 bytes)
- RGB666: r6x2g6x2b6x2 (3 bytes)
- BGR666: b6x2g6x2r6x2 (3 bytes)
(x: don't care)
v2:
- Use 'default: r5g6b5' (Rob)
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240604-panel-mipi-dbi-rgb666-v4-1-d7c2bcb9b78d@tronnes.org
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Michal Wajdeczko [Fri, 17 May 2024 16:34:06 +0000 (18:34 +0200)]
drm/i915: Don't use __func__ as prefix for drm_dbg_printer
Updated code of drm_dbg_printer() is already printing symbolic
name of the caller like drm_dbg() does.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240517163406.2348-4-michal.wajdeczko@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Michal Wajdeczko [Fri, 17 May 2024 16:34:05 +0000 (18:34 +0200)]
drm/print: Improve drm_dbg_printer
With recent introduction of a generic drm dev printk function, we
can now store and use location where drm_dbg_printer was invoked
and output it's symbolic name like we do for all drm debug prints.
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240517163406.2348-3-michal.wajdeczko@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Michal Wajdeczko [Fri, 17 May 2024 16:34:04 +0000 (18:34 +0200)]
drm/print: Add generic drm dev printk function
We already have some drm printk functions that need to duplicate
a code to get a similar format of the final result, for example:
[ ] 0000:00:00.0: [drm:foo] bar
[ ] 0000:00:00.0: [drm] foo bar
[ ] 0000:00:00.0: [drm] *ERROR* foo
Add a generic __drm_dev_vprintk() function that can format the
final message like all other existing function do and allows us
to keep the formatting code in one place.
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240517163406.2348-2-michal.wajdeczko@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Michal Wajdeczko [Thu, 16 May 2024 16:00:15 +0000 (18:00 +0200)]
drm/print: Kill ___drm_dbg()
There is no point in maintaining a separate print function, while
there is __drm_dev_dbg() function that can work with a NULL device.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240516160015.2260-1-michal.wajdeczko@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Michal Wajdeczko [Thu, 23 May 2024 17:44:29 +0000 (19:44 +0200)]
drm/print: Add missing [drm] prefix to drm based WARN
All drm_device based logging macros, except those related to WARN,
include the [drm] prefix. Fix that.
[ ] 0000:00:00.0: this is a warning
[ ] 0000:00:00.0: drm_WARN_ON(true)
vs
[ ] 0000:00:00.0: [drm] this is a warning
[ ] 0000:00:00.0: [drm] drm_WARN_ON(true)
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240523174429.800-1-michal.wajdeczko@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Primoz Fiser [Thu, 6 Jun 2024 08:01:04 +0000 (10:01 +0200)]
drm/panel: simple: Add PrimeView PM070WL4 support
Add support for PrimeView PM070WL4 7.0" (800x480) TFT-LCD panel.
Datasheet can be found at [1].
[1] https://www.beyondinfinite.com/lcd/Library/Pvi/PM070WL4-V1.0.pdf
Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20240606080104.3663355-3-primoz.fiser@norik.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240606080104.3663355-3-primoz.fiser@norik.com
Primoz Fiser [Thu, 6 Jun 2024 08:01:03 +0000 (10:01 +0200)]
dt-bindings: display: simple: Add PrimeView PM070WL4 panel
Add PrimeView PM070WL4 7.0" 800x480 TFT LCD panel compatible string.
Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240606080104.3663355-2-primoz.fiser@norik.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240606080104.3663355-2-primoz.fiser@norik.com
Primoz Fiser [Thu, 6 Jun 2024 08:01:02 +0000 (10:01 +0200)]
dt-bindings: vendor-prefixes: Add PrimeView
The Prime View International (PVI) is a LCD panel manufacturer.
Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240606080104.3663355-1-primoz.fiser@norik.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240606080104.3663355-1-primoz.fiser@norik.com
Vignesh Raman [Wed, 29 May 2024 02:40:49 +0000 (08:10 +0530)]
drm/ci: update xfails for the new testlist
Now the testlist is used from IGT build, so update
xfails with the new testlist.
Set the timeout of all i915 jobs to 1h30m since some jobs
takes more than 1 hour to complete.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # msm testlists
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> # msm test list
Acked-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240529024049.356327-7-vignesh.raman@collabora.com
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Vignesh Raman [Wed, 29 May 2024 02:40:48 +0000 (08:10 +0530)]
drm/ci: skip driver specific tests
Skip driver specific tests and skip kms tests for
panfrost driver since it is not a kms driver.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240529024049.356327-6-vignesh.raman@collabora.com
Vignesh Raman [Wed, 29 May 2024 02:40:47 +0000 (08:10 +0530)]
drm/ci: uprev IGT
test-list.txt and test-list-full.txt are not generated for
cross-builds and they are required by drm-ci for testing
arm32 targets. This is fixed in igt-gpu-tools. So uprev
IGT to include the commit which fixes this issue. Also
disable building xe driver tests for non-intel platforms.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240529024049.356327-5-vignesh.raman@collabora.com
Vignesh Raman [Wed, 29 May 2024 02:40:46 +0000 (08:10 +0530)]
drm/ci: generate testlist from build
Stop vendoring the testlist into the kernel. Instead, use the
testlist from the IGT build to ensure we do not miss renamed
or newly added tests.
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240529024049.356327-4-vignesh.raman@collabora.com
Vignesh Raman [Wed, 29 May 2024 02:40:45 +0000 (08:10 +0530)]
drm/ci: add farm variable
Mesa uses structured logs for logging and debug purpose,
https://mesa.pages.freedesktop.org/-/mesa/-/jobs/
59165650/artifacts/results/job_detail.json
Since drm-ci uses the mesa scripts, add the farm variable
and update the device type for missing jobs.
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240529024049.356327-3-vignesh.raman@collabora.com
Vignesh Raman [Wed, 29 May 2024 02:40:44 +0000 (08:10 +0530)]
drm/ci: uprev mesa version
zlib.net is not allowing tarball download anymore and results
in below error in kernel+rootfs_arm32 container build,
urllib.error.HTTPError: HTTP Error 403: Forbidden
urllib.error.HTTPError: HTTP Error 415: Unsupported Media Type
Uprev mesa to latest version which includes a fix for this issue.
https://gitlab.freedesktop.org/mesa/mesa/-/commit/
908f444e
Use id_tokens for JWT authentication. Since s3 bucket is migrated to
mesa-rootfs, update the variables accordingly. Also copy helper scripts
to install, so that the ci jobs can use these scripts for logging.
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240529024049.356327-2-vignesh.raman@collabora.com
Rodrigo Vivi [Tue, 4 Jun 2024 17:54:38 +0000 (13:54 -0400)]
drm/mm: Remove unused drm_mm_replace_node
Last caller was removed with commit
078a5b498d6a ("drm/tests:
Remove slow tests").
Cc: Maxime Ripard <mripard@kernel.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240604175438.48125-1-rodrigo.vivi@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Haoran Liu [Wed, 29 Nov 2023 11:34:05 +0000 (03:34 -0800)]
drm/meson: plane: Add error handling
This patch adds robust error handling to the meson_plane_create
function in drivers/gpu/drm/meson/meson_plane.c. The function
previously lacked proper handling for potential failure scenarios
of the drm_universal_plane_init call.
Signed-off-by: Haoran Liu <liuhaoran14@163.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20231129113405.33057-1-liuhaoran14@163.com
[narmstrong: fixe the commit subject]
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20231129113405.33057-1-liuhaoran14@163.com
Barry Song [Wed, 5 Jun 2024 01:26:05 +0000 (13:26 +1200)]
dma-buf: align fd_flags and heap_flags with dma_heap_allocation_data
dma_heap_allocation_data defines the UAPI as follows:
struct dma_heap_allocation_data {
__u64 len;
__u32 fd;
__u32 fd_flags;
__u64 heap_flags;
};
However, dma_heap_buffer_alloc() casts both fd_flags and heap_flags
into unsigned int. We're inconsistent with types in the non UAPI
arguments. This patch fixes it.
Signed-off-by: Barry Song <v-songbaohua@oppo.com>
Acked-by: John Stultz <jstultz@google.com>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240605012605.5341-1-21cnbao@gmail.com
Tvrtko Ursulin [Tue, 4 Jun 2024 16:02:10 +0000 (17:02 +0100)]
drm/v3d: Fix perfmon build error/warning
Move static const array into the source file to fix the "defined but not
used" errors.
The fix is perhaps not the prettiest due hand crafting the array sizes
in v3d_performance_counters.h, but I did add some build time asserts to
validate the counts look sensible, so hopefully it is good enough for a
quick fix.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Fixes:
3cbcbe016c31 ("drm/v3d: Add Performance Counters descriptions for V3D 4.2 and 7.1")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/
202405211137.hueFkLKG-lkp@intel.com/Cc: Maíra Canal <mcanal@igalia.com>
Cc: Iago Toral Quiroga <itoral@igalia.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240604160210.24073-1-tursulin@igalia.com
Lucas Stach [Mon, 18 Mar 2024 20:39:25 +0000 (21:39 +0100)]
drm/bridge: analogix_dp: don't adjust further when clock recovery succeeded
Take a early return from the clock recovery training when the sink reports
CR_DONE for all lanes. There is no point in trying to adjust the link
parameters further.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240318203925.2837689-3-l.stach@pengutronix.de
Wyon Bi [Mon, 18 Mar 2024 20:39:24 +0000 (21:39 +0100)]
drm/bridge: analogix_dp: simplify analogix_dp_{set/get}_lane_link_training helpers
There is no need for separate functions for each lane, as we can deduct the
register offset to read/write from the lane index.
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240318203925.2837689-2-l.stach@pengutronix.de
Lucas Stach [Mon, 18 Mar 2024 20:39:23 +0000 (21:39 +0100)]
drm/bridge: analogix_dp: properly handle zero sized AUX transactions
Address only transactions without any data are valid and should not
be flagged as short transactions. Simply return the message size when
no transaction errors occured.
CC: stable@vger.kernel.org
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240318203925.2837689-1-l.stach@pengutronix.de
Ryan Walklin [Thu, 30 May 2024 21:12:15 +0000 (09:12 +1200)]
drm: panel: nv3052c: Add WL-355608-A8 panel
The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display from an unknown
OEM used in a number of handheld gaming devices made by Anbernic.
Limited information is available online however the panel timing values
(below) have been obtained from the vendor BSP. The panel appears to
integrate a NV3052C LCD driver (or clone). Available devices address it
in SPI/RGB mode, with the timing signals generated from the device
SoC (Allwinner H700) and passed through.
Add a panel definition and display mode to the existing NV3502C driver.
It was assumed during bringup that the initialisation sequence was the
same as the existing Fascontek FS035VG158 panel, proved working during
experimentation, however subsequent dumping of the init sequence with a
logic analyser confirms one small change to VCOM_ADJ3 from 0x4a to 0x44,
therefore a separate set of registers is also added.
Timings:
| Active | FP | Sync | BP | Total
-----------|--------|------|------|------|-------
Horizontal | 640 | 64 | 20 | 46 | 770
Vertical | 480 | 21 | 4 | 15 | 520
Signed-off-by: Ryan Walklin <ryan@testtoast.com>
Co-developed-by: Hironori KIKUCHI <kikuchan98@gmail.com>
Signed-off-by: Hironori KIKUCHI <kikuchan98@gmail.com>
Reviewed-by: John Watts <contact@jookia.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Acked-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Link: https://lore.kernel.org/r/20240530211415.44201-4-ryan@testtoast.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240530211415.44201-4-ryan@testtoast.com
Ryan Walklin [Thu, 30 May 2024 21:12:14 +0000 (09:12 +1200)]
dt-bindings: display: panel: Add WL-355608-A8 panel
The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display used in a
number of handheld gaming devices made by Anbernic. By consensus a
vendor prefix is not provided as the panel OEM is unknown.
Add a device tree binding for the panel.
Signed-off-by: Ryan Walklin <ryan@testtoast.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240530211415.44201-3-ryan@testtoast.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240530211415.44201-3-ryan@testtoast.com
Sam Ravnborg [Thu, 30 May 2024 21:14:02 +0000 (23:14 +0200)]
MAINTAINERS: drm: Drop sam as panel reviewer
Drop myself as reviewer of panel patches, to reflect the reality.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20240530211402.GA1660596@ravnborg.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240530211402.GA1660596@ravnborg.org
Christian König [Wed, 29 May 2024 08:43:22 +0000 (10:43 +0200)]
dma-buf: add a warning when drv try to reserve 0 fence slots
When dma_resv_reserve_fences() is called with num_fences=0 it usually
means that a driver or other component messed up its calculation how
many fences are needed. Warn in that situation.
When no fence are needed the function shouldn't be called in the first
place.
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240529084322.2284-1-christian.koenig@amd.com
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Dmitry Baryshkov [Fri, 3 May 2024 18:15:04 +0000 (21:15 +0300)]
drm/ci: validate drm/msm XML register files against schema
In order to validate drm/msm register definition files against schema,
reuse the nodebugfs build step. The validation entry is guarded by
the EXPERT Kconfig option and we don't want to enable that option for
all the builds.
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503-fd-fix-lxml-v2-2-f80a60ce21a1@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Manikandan Muralidharan [Wed, 24 Apr 2024 05:33:51 +0000 (11:03 +0530)]
drm: atmel-hlcdc: add LCD controller layer definition for sam9x75
Add the LCD controller layer definition and descriptor structure for
sam9x75 for the following layers:
- Base Layer
- Overlay1 Layer
- Overlay2 Layer
- High End Overlay
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240424053351.589830-9-manikandan.m@microchip.com
Manikandan Muralidharan [Wed, 24 Apr 2024 05:33:50 +0000 (11:03 +0530)]
drm: atmel-hlcdc: add support for DSI output formats
Add support for the following DPI mode if the encoder type
is DSI as per the XLCDC IP datasheet:
- 16BPPCFG1
- 16BPPCFG2
- 16BPPCFG3
- 18BPPCFG1
- 18BPPCFG2
- 24BPP
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
[durai.manickamkr@microchip.com: update output format using is_xlcdc flag]
Signed-off-by: Durai Manickam KR <durai.manickamkr@microchip.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240424053351.589830-8-manikandan.m@microchip.com
Manikandan Muralidharan [Wed, 24 Apr 2024 05:33:49 +0000 (11:03 +0530)]
drm: atmel-hlcdc: add vertical and horizontal scaling support for XLCDC
Update the vertical and horizontal scaler registers of XLCDC IP
with Bilinear and Bicubic co-efficients taps for Chroma and
Luma componenets of the Pixel.
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240424053351.589830-7-manikandan.m@microchip.com
Manikandan Muralidharan [Wed, 24 Apr 2024 05:33:48 +0000 (11:03 +0530)]
drm: atmel-hlcdc: add DPI mode support for XLCDC
Add support for Display Pixel Interface (DPI) Compatible Mode
support in atmel-hlcdc driver for XLCDC IP along with legacy
pixel mapping. DPI mode BIT is configured in LCDC_CFG5 register.
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
[durai.manickamkr@microchip.com: update DPI mode bit using is_xlcdc flag]
Signed-off-by: Durai Manickam KR <durai.manickamkr@microchip.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240424053351.589830-6-manikandan.m@microchip.com
Manikandan Muralidharan [Wed, 24 Apr 2024 05:33:47 +0000 (11:03 +0530)]
drm: atmel_hlcdc: Add support for XLCDC using IP specific driver ops
Add XLCDC specific driver ops and is_xlcdc flag to separate the
functionality and to access the controller registers.
HEO scaling, window resampling, Alpha blending, YUV-to-RGB
conversion in XLCDC is derived and handled using additional
configuration bits and registers. Writing one to the Enable fields
of each layer in LCD_ATTRE is required to reflect the values set
in Configuration, FBA, Enable registers of each layer.
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Co-developed-by: Hari Prasath Gujulan Elango <Hari.PrasathGE@microchip.com>
Signed-off-by: Hari Prasath Gujulan Elango <Hari.PrasathGE@microchip.com>
Co-developed-by: Durai Manickam KR <durai.manickamkr@microchip.com>
Signed-off-by: Durai Manickam KR <durai.manickamkr@microchip.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240424053351.589830-5-manikandan.m@microchip.com
Manikandan Muralidharan [Wed, 24 Apr 2024 05:33:46 +0000 (11:03 +0530)]
drm: atmel_hlcdc: replace regmap_read with regmap_read_poll_timeout
Replace regmap_read with regmap_read_poll_timeout to neatly handle
retries
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Acked-by: Dharma Balasubiramani <dharma.b@microchip.com>
Reviewed-by: Hari Prasath Gujulan Elango <hari.prasathge@microchip.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240424053351.589830-4-manikandan.m@microchip.com
Durai Manickam KR [Wed, 24 Apr 2024 05:33:45 +0000 (11:03 +0530)]
drm: atmel-hlcdc: Define XLCDC specific registers
The register address of the XLCDC IP used in SAM9X7 SoC family
are different from the previous HLCDC. Defining those address
space with valid macros.
Signed-off-by: Durai Manickam KR <durai.manickamkr@microchip.com>
[manikandan.m@microchip.com: Remove unused macro definitions]
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Acked-by: Lee Jones <lee@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240424053351.589830-3-manikandan.m@microchip.com
Manikandan Muralidharan [Wed, 24 Apr 2024 05:33:44 +0000 (11:03 +0530)]
drm: atmel-hlcdc: add driver ops to differentiate HLCDC and XLCDC IP
Add LCD IP specific ops in driver data to differentiate
HLCDC and XLCDC code within the atmel-hlcdc driver files.
XLCDC in SAM9X7 has different sets of registers and additional
configuration bits when compared to previous HLCDC IP. Read/write
operation on the controller register and functionality is now
separated using the LCD IP specific ops.
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240424053351.589830-2-manikandan.m@microchip.com
Maxime Ripard [Wed, 29 May 2024 08:00:13 +0000 (10:00 +0200)]
drm/display: Fix HDMI state helper dependency
During the life of the series that introduced the
DRM_DISPLAY_HDMI_STATE_HELPER option, we reworked the Kconfig option
dependency setup to rely on depends on with commit
f6d2dc03fa85 ("drm:
Switch DRM_DISPLAY_HDMI_HELPER to depends on") which got reverted later
on because it was creating too many issues by commit
d7c128cb775e
("Revert "drm: Switch DRM_DISPLAY_HDMI_HELPER to depends on"").
However, since the series was out of tree at that time,
DRM_DISPLAY_HDMI_STATE_HELPER wasn't properly updated to take the revert
into account and is now creating build issues.
Let's switch the depends on to a select to fix this.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/
202405290332.Sqtt0ix0-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/
202405290438.TOYhXMIn-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/
202405290803.c3178DYT-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/
202405291109.PQdqc46g-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/
202405291221.a0NStxHE-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/
202405291636.8GgBtK8u-lkp@intel.com/
Fixes:
54cb39e2293b ("drm/connector: hdmi: Create an HDMI sub-state")
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240529080013.2325748-1-mripard@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Maxime Ripard [Tue, 28 May 2024 15:10:56 +0000 (17:10 +0200)]
drm/sun4i: Fix compilation error
Commit
ea64761a54a2 ("drm/sun4i: hdmi: Switch to HDMI connector")
introduced a dependency that got renamed in a previous version, but
wasn't properly updated in that driver. Fix the name of the function.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/
202405282205.EU7NUoeQ-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/
202405282248.U2lhPvCK-lkp@intel.com/
Fixes:
ea64761a54a2 ("drm/sun4i: hdmi: Switch to HDMI connector")
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240528151056.2104153-1-mripard@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Pin-yen Lin [Mon, 27 May 2024 09:54:50 +0000 (17:54 +0800)]
drm/panel-edp: Add more panels with conservative timings
Same as commit
7c8690d8fc80 ("drm/panel-edp: Add some panels with
conservative timings"), the 3 panels added in this patch are used by
Mediatek MT8173 Chromebooks and they used to work with the downstream
v4.19 kernel without any specified delay.
These panel IDs were found from in-field reports, but their datahseets
are not available. For BOE 0x0623 and SHP 0x153a, their product names
are retrieved from the EDIDs. The EDID of AUO 0x1999 does not contain
such information, so list as "Unknown" in this patch.
Update these entries with less-conservative timings from other panels of
the same vendor.
Signed-off-by: Pin-yen Lin <treapking@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240527095511.719825-3-treapking@chromium.org
Pin-yen Lin [Mon, 27 May 2024 09:54:49 +0000 (17:54 +0800)]
drm/panel-edp: Add support for several panels
Add support for the following models:
AUO B140HTN02.0
BOE NT116WHM-N21 V4.1
BOE NT116WHM-N21
Signed-off-by: Pin-yen Lin <treapking@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240527095511.719825-2-treapking@chromium.org
Douglas Anderson [Fri, 3 May 2024 21:33:28 +0000 (14:33 -0700)]
drm/panel: sony-acx565akm: Don't call disable at remove
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
A grep through mainline for compatible strings used by this driver
indicates that it is used by TI OMAP boards. The TI OMAP driver
appears to be correctly calling drm_atomic_helper_shutdown() so we can
remove the calls.
[1] https://lore.kernel.org/r/
20230901234015.566018-1-dianders@chromium.org
[2] https://lore.kernel.org/r/
20230901234202.566951-1-dianders@chromium.org
[3] https://lore.kernel.org/r/
20230921192749.
1542462-1-dianders@chromium.org
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.47.I2513fd6824929a17c1ccd18a797b98a1a1063559@changeid
Douglas Anderson [Fri, 3 May 2024 21:33:27 +0000 (14:33 -0700)]
drm/panel: sony-acx565akm: Don't double-check enabled state in disable
As talked about in commit
d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
The acx565akm seems to do some unique stuff with the "enabled"
state. Specifically:
1. It seems to detect the enabled state based on how the bootloader
left the panel.
2. It uses the enabled state to prevent certain sysfs files from
accessing a disabled panel.
We'll leave the "enabled" state tracking for this. However, we can at
least get rid of the double-check when trying to disable.
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.46.I6a51b36831a5c7b2b82bccf8c550cf0d076aa541@changeid
Douglas Anderson [Fri, 3 May 2024 21:33:24 +0000 (14:33 -0700)]
drm/panel: sitronix-st7703: Don't call disable at shutdown/remove
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
The compatible strings used by this driver seem to show up across
boards using a variety of DRM drivers. It appears that the relevant
drivers have been converted, but at least one compatible string
doesn't seem to be found in any mainline dts files so we can't be 100%
sure. If it is found that the DRM modeset driver hasn't been fixed
then this patch could be temporarily reverted until it is.
[1] https://lore.kernel.org/r/
20230901234015.566018-1-dianders@chromium.org
[2] https://lore.kernel.org/r/
20230901234202.566951-1-dianders@chromium.org
[3] https://lore.kernel.org/r/
20230921192749.
1542462-1-dianders@chromium.org
Cc: Guido Günther <agx@sigxcpu.org>
Cc: Ondřej Jirman <megi@xff.cz>
Cc: Chris Morgan <macromorgan@hotmail.com>
Cc: Frank Oltmanns <frank@oltmanns.dev>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.43.I08ba0d4e2d534c06ab0ede9c148bb14cc7c1a9d7@changeid
Douglas Anderson [Fri, 3 May 2024 21:33:23 +0000 (14:33 -0700)]
drm/panel: sitronix-st7703: Stop tracking prepared
As talked about in commit
d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
One thing to note for st7703 is that it has a special "allpixelson"
debugfs file. When this file is written the driver hacks a
disable/unprepare and then a prepare/enable to try to reset the
panel. Potentially that might have been relying on the old booleans we
removed. It'll still "work" because of the checks in the core but it
deserves a comment. This debugfs file didn't appear to be particularly
safe to use even before this patch since it would cause a
disabled/unprepared panel to become prepared/enabled.
Cc: Guido Günther <agx@sigxcpu.org>
Cc: Ondřej Jirman <megi@xff.cz>
Cc: Chris Morgan <macromorgan@hotmail.com>
Cc: Frank Oltmanns <frank@oltmanns.dev>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.42.Ifc436b262d72f1a33ddef10adfd7578d4acb60d8@changeid
Douglas Anderson [Fri, 3 May 2024 21:33:12 +0000 (14:33 -0700)]
drm/panel: xinpeng-xpp055c272: Don't call unprepare+disable at shutdown/remove
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
A grep through mainline for compatible strings used by this driver
indicates that it is used by Rockchip boards. The Rockchip driver
appears to be correctly calling drm_atomic_helper_shutdown() so we can
remove the calls.
[1] https://lore.kernel.org/r/
20230901234015.566018-1-dianders@chromium.org
[2] https://lore.kernel.org/r/
20230901234202.566951-1-dianders@chromium.org
[3] https://lore.kernel.org/r/
20230921192749.
1542462-1-dianders@chromium.org
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.31.Ib97e67a9877070698afbec4f8ede091b2bf89a1f@changeid
Douglas Anderson [Fri, 3 May 2024 21:33:11 +0000 (14:33 -0700)]
drm/panel: xinpeng-xpp055c272: Stop tracking prepared
As talked about in commit
d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.30.I2145be78ce28327f4588c2c21370f22fd79d28b8@changeid
Douglas Anderson [Fri, 3 May 2024 21:33:08 +0000 (14:33 -0700)]
drm/panel: simple: Add a comment about unprepare+disable at shutdown/remove
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
Unfortunately, it's very difficult to know exactly which DRM modeset
drivers are using panel-simple due to the sheer number of panels it
handles. For now, we'll leave the calls and just add a comment to keep
people from copying this code.
[1] https://lore.kernel.org/r/
20230901234015.566018-1-dianders@chromium.org
[2] https://lore.kernel.org/r/
20230901234202.566951-1-dianders@chromium.org
[3] https://lore.kernel.org/r/
20230921192749.
1542462-1-dianders@chromium.org
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.27.I639183ac987e139092491a94e22d46a5d857580c@changeid
Douglas Anderson [Fri, 3 May 2024 21:33:07 +0000 (14:33 -0700)]
drm/panel: simple: Stop tracking prepared/enabled
As talked about in commit
d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Acked-by: Sui Jingfeng <sui.jingfeng@linux.dev>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.26.I865be97dd393d6ae3c3a3cd1358c95fdbca0fe83@changeid
Douglas Anderson [Fri, 3 May 2024 21:33:06 +0000 (14:33 -0700)]
drm/panel: samsung-atna33xc20: Don't call unprepare+disable at shutdown/remove
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
A grep through mainline for compatible strings used by this driver
indicates that it is used by Qualcomm boards. The Qualcomm driver
appears to be correctly calling drm_atomic_helper_shutdown() so we can
remove the calls.
[1] https://lore.kernel.org/r/
20230901234015.566018-1-dianders@chromium.org
[2] https://lore.kernel.org/r/
20230901234202.566951-1-dianders@chromium.org
[3] https://lore.kernel.org/r/
20230921192749.
1542462-1-dianders@chromium.org
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.25.Iaeacccf98e6cb729b8fc3a782725769cd66812ad@changeid
Douglas Anderson [Fri, 3 May 2024 21:33:05 +0000 (14:33 -0700)]
drm/panel: samsung-atna33xc20: Stop tracking prepared/enabled
As talked about in commit
d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.24.Ibb4f923363a27167c480a432e52884b117221974@changeid
Douglas Anderson [Fri, 3 May 2024 21:33:00 +0000 (14:33 -0700)]
drm/panel: novatek-nt36672a: Don't call unprepare+disable at shutdown/remove
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
A grep through mainline for compatible strings used by this driver
indicates that it is used by Qualcomm boards. The Qualcomm driver
appears to be correctly calling drm_atomic_helper_shutdown() so we can
remove the calls.
[1] https://lore.kernel.org/r/
20230901234015.566018-1-dianders@chromium.org
[2] https://lore.kernel.org/r/
20230901234202.566951-1-dianders@chromium.org
[3] https://lore.kernel.org/r/
20230921192749.
1542462-1-dianders@chromium.org
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Benni Steini <bennisteinir@gmail.com>
Cc: Marijn Suijten <marijn.suijten@somainline.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Joel Selvaraj <jo@jsfamily.in>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.19.I67819ba5513d4ef85f254a68b22a3402b4cdf30f@changeid
Douglas Anderson [Fri, 3 May 2024 21:32:59 +0000 (14:32 -0700)]
drm/panel: novatek-nt36672a: Stop tracking prepared
As talked about in commit
d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Benni Steini <bennisteinir@gmail.com>
Cc: Marijn Suijten <marijn.suijten@somainline.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Joel Selvaraj <jo@jsfamily.in>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.18.I13a06b9e6f5920659b1e5d12543b3cd9066383b8@changeid
Douglas Anderson [Fri, 3 May 2024 21:32:58 +0000 (14:32 -0700)]
drm/panel: ltk500hd1829: Don't call unprepare+disable at shutdown/remove
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
Unfortunately, grepping mainline for this panel's compatible string
shows no hits, so we can't be 100% sure if the DRM modeset driver used
with this panel has been fixed. If it is found that the DRM modeset
driver hasn't been fixed then this patch could be temporarily reverted
until it is.
[1] https://lore.kernel.org/r/
20230901234015.566018-1-dianders@chromium.org
[2] https://lore.kernel.org/r/
20230901234202.566951-1-dianders@chromium.org
[3] https://lore.kernel.org/r/
20230921192749.
1542462-1-dianders@chromium.org
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.17.If3edcf846f754b425959980039372a9fd1599ecc@changeid
Douglas Anderson [Fri, 3 May 2024 21:32:57 +0000 (14:32 -0700)]
drm/panel: ltk500hd1829: Stop tracking prepared
As talked about in commit
d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.16.I4f574b87fe24765ddd4424437159b37a6481aa1a@changeid
Douglas Anderson [Fri, 3 May 2024 21:32:56 +0000 (14:32 -0700)]
drm/panel: ltk050h3146w: Don't call unprepare+disable at shutdown/remove
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
Unfortunately, grepping mainline for this panel's compatible string
shows no hits, so we can't be 100% sure if the DRM modeset driver used
with this panel has been fixed. If it is found that the DRM modeset
driver hasn't been fixed then this patch could be temporarily reverted
until it is.
[1] https://lore.kernel.org/r/
20230901234015.566018-1-dianders@chromium.org
[2] https://lore.kernel.org/r/
20230901234202.566951-1-dianders@chromium.org
[3] https://lore.kernel.org/r/
20230921192749.
1542462-1-dianders@chromium.org
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Tested-by: Quentin Schulz <quentin.schulz@cherry.de> # RK3399 Puma with Haikou Video Demo
Tested-by: Quentin Schulz <quentin.schulz@cherry.de> # PX30 Ringneck with Haikou Video Demo
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.15.Ibeb2e5692e34b136afe4cf55532f0696ab3f5eed@changeid
Douglas Anderson [Fri, 3 May 2024 21:32:55 +0000 (14:32 -0700)]
drm/panel: ltk050h3146w: Stop tracking prepared
As talked about in commit
d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.14.I264417152e65b4a2e374666010666fa1c2d973fc@changeid
Douglas Anderson [Fri, 3 May 2024 21:32:54 +0000 (14:32 -0700)]
drm/panel: kingdisplay-kd097d04: Don't call unprepare+disable at shutdown/remove
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
A grep through mainline for compatible strings used by this driver
indicates that it is used by Rockchip boards. The Rockchip driver
appear to be correctly calling drm_atomic_helper_shutdown() so we can
remove the calls.
[1] https://lore.kernel.org/r/
20230901234015.566018-1-dianders@chromium.org
[2] https://lore.kernel.org/r/
20230901234202.566951-1-dianders@chromium.org
[3] https://lore.kernel.org/r/
20230921192749.
1542462-1-dianders@chromium.org
Cc: Brian Norris <briannorris@chromium.org>
Cc: Chris Zhong <zyw@rock-chips.com>
Cc: Nickey Yang <nickey.yang@rock-chips.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.13.I6c7c84b1560dd374f6e7e8dc50f419a870d31d31@changeid
Douglas Anderson [Fri, 3 May 2024 21:32:53 +0000 (14:32 -0700)]
drm/panel: kingdisplay-kd097d04: Stop tracking prepared/enabled
As talked about in commit
d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
Cc: Brian Norris <briannorris@chromium.org>
Cc: Chris Zhong <zyw@rock-chips.com>
Cc: Nickey Yang <nickey.yang@rock-chips.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.12.I711d07c4f4738df199697fd534c452cdfa46a21f@changeid
Douglas Anderson [Fri, 3 May 2024 21:32:50 +0000 (14:32 -0700)]
drm/panel: innolux-p079zca: Don't call unprepare+disable at shutdown/remove
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
A grep through mainline for compatible strings used by this driver
indicates that it is used by Rockchip boards. The Rockchip driver
appears to be correctly calling drm_atomic_helper_shutdown() so we can
remove the calls.
[1] https://lore.kernel.org/r/
20230901234015.566018-1-dianders@chromium.org
[2] https://lore.kernel.org/r/
20230901234202.566951-1-dianders@chromium.org
[3] https://lore.kernel.org/r/
20230921192749.
1542462-1-dianders@chromium.org
Cc: Chris Zhong <zyw@rock-chips.com>
Cc: Lin Huang <hl@rock-chips.com>
Cc: Brian Norris <briannorris@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.9.Iaddb8e0cab570e2f8066a4baf1d49239a820b799@changeid
Douglas Anderson [Fri, 3 May 2024 21:32:49 +0000 (14:32 -0700)]
drm/panel: innolux-p079zca: Stop tracking prepared/enabled
As talked about in commit
d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
Cc: Chris Zhong <zyw@rock-chips.com>
Cc: Lin Huang <hl@rock-chips.com>
Cc: Brian Norris <briannorris@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.8.I99c73621fe3fba067a5e7ee6a1f6293c23371e1e@changeid
Douglas Anderson [Fri, 3 May 2024 21:32:48 +0000 (14:32 -0700)]
drm/panel: edp: Add a comment about unprepare+disable at shutdown/remove
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
Unfortunately, it's very difficult to know exactly which DRM modeset
drivers are using panel-edp due to the sheer number of panels it
handles. For now, we'll leave the calls and just add a comment to keep
people from copying this code.
[1] https://lore.kernel.org/r/
20230901234015.566018-1-dianders@chromium.org
[2] https://lore.kernel.org/r/
20230901234202.566951-1-dianders@chromium.org
[3] https://lore.kernel.org/r/
20230921192749.
1542462-1-dianders@chromium.org
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.7.Icff7f7005d997773d585e36aba9ed41a9865201f@changeid
Douglas Anderson [Fri, 3 May 2024 21:32:47 +0000 (14:32 -0700)]
drm/panel: edp: Stop tracking prepared/enabled
As talked about in commit
d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.6.I4d1bf08781593c08127e506422687ab19fd3c824@changeid
Douglas Anderson [Fri, 3 May 2024 21:32:46 +0000 (14:32 -0700)]
drm/panel: boe-tv101wum-nl6: Don't call unprepare+disable at shutdown/remove
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset drivers as
possible [1] [2] [3] and most drivers are fixed now.
A grep through mainline for compatible strings used by this driver
indicates that it is used by Mediatek and Qualcomm boards. Both of
those drivers appear to be correctly calling
drm_atomic_helper_shutdown() so we can remove the calls.
[1] https://lore.kernel.org/r/
20230901234015.566018-1-dianders@chromium.org
[2] https://lore.kernel.org/r/
20230901234202.566951-1-dianders@chromium.org
[3] https://lore.kernel.org/r/
20230921192749.
1542462-1-dianders@chromium.org
Cc: Jitao Shi <jitao.shi@mediatek.com>
Cc: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.5.I5bd120aa0b7d17a1149ea43cc4852492834058c0@changeid
Douglas Anderson [Fri, 3 May 2024 21:32:45 +0000 (14:32 -0700)]
drm/panel: boe-tv101wum-nl6: Stop tracking prepared
As talked about in commit
d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
Cc: Jitao Shi <jitao.shi@mediatek.com>
Cc: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.4.Ib501f2eceb62016e09cfb17bca29bde0f605a567@changeid
Douglas Anderson [Fri, 3 May 2024 21:32:42 +0000 (14:32 -0700)]
drm/panel: raydium-rm692e5: Stop tracking prepared
As talked about in commit
d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
Cc: Konrad Dybcio <konrad.dybcio@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Luca Weiss <luca.weiss@fairphone.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.1.I784238de4810658212a5786b219f128460562a37@changeid
Ville Syrjälä [Mon, 8 Apr 2024 17:04:12 +0000 (20:04 +0300)]
drm/sti: Allow build with COMPILE_TEST=y
Allow sti to be built with COMPILE_TEST=y for greater
coverage. Builds fine on x86/x86_64 at least.
Cc: Alain Volmat <alain.volmat@foss.st.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240408170426.9285-8-ville.syrjala@linux.intel.com
Acked-by: Alain Volmat <alain.volmat@foss.st.com>
Ville Syrjälä [Mon, 8 Apr 2024 17:04:11 +0000 (20:04 +0300)]
drm/sti: Include linux/io.h for devm_ioremap()
Include linux/io.h for devm_ioremap().
When built on x86_64 w/ COMPILE_TEST=y:
../drivers/gpu/drm/sti/sti_dvo.c:531:21: error: implicit declaration of function ‘devm_ioremap’ [-Werror=implicit-function-declaration]
531 | dvo->regs = devm_ioremap(dev, res->start,
| ^~~~~~~~~~~~
../drivers/gpu/drm/sti/sti_dvo.c:531:19: error: assignment to ‘void *’ from ‘int’ makes pointer from integer without a cast [-Werror=int-conversion]
531 | dvo->regs = devm_ioremap(dev, res->start,
| ^
Cc: Alain Volmat <alain.volmat@foss.st.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240408170426.9285-7-ville.syrjala@linux.intel.com
Acked-by: Alain Volmat <alain.volmat@foss.st.com>
MarileneGarcia [Sun, 19 May 2024 03:10:27 +0000 (00:10 -0300)]
drm/dp: Fix documentation warning
It fixes the following warnings when
the kernel documentation is generated:
./include/drm/display/drm_dp_helper.h:126:
warning: Function parameter or struct member
'mode' not described in 'drm_dp_as_sdp'
./include/drm/display/drm_dp_helper.h:126:
warning: Excess struct member 'operation_mode'
description in 'drm_dp_as_sdp'
Signed-off-by: MarileneGarcia <marilene.agarcia@gmail.com>
Fixes:
0bbb8f594e33 ("drm/dp: Add Adaptive Sync SDP logging")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Closes: https://lore.kernel.org/r/
20240405141640.
09b0bdbf@canb.auug.org.au
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240519031027.433751-1-marilene.agarcia@gmail.com
Alex Bee [Thu, 9 May 2024 14:06:51 +0000 (16:06 +0200)]
drm/rockchip: dsi: Add support for RK3128
The DesignWare MIPI DSI controller found RK3128 SoCs supports up to 4 DSI
data lanes. Similar to PX30/RK356x/RV1126 it uses an external D-PHY.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20240509140653.168591-6-knaerzche@gmail.com
Alex Bee [Thu, 9 May 2024 14:06:47 +0000 (16:06 +0200)]
dt-bindings: display: rockchip,dw-mipi-dsi: Document RK3128 DSI
Document the MIPI DSI controller for Rockchip RK3128. The integration is
similar to PX30 so it's bindings-constraints can be re-used.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20240509140653.168591-2-knaerzche@gmail.com
Maxime Ripard [Mon, 27 May 2024 13:58:18 +0000 (15:58 +0200)]
drm/sun4i: hdmi: Switch to HDMI connector
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Acked-by: Sui Jingfeng <sui.jingfeng@linux.dev>
Reviewed-by: Andy Yan <andyshrk@163.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-29-c5af16c3aae2@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Maxime Ripard [Mon, 27 May 2024 13:58:17 +0000 (15:58 +0200)]
drm/rockchip: inno_hdmi: Switch to HDMI connector
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Andy Yan <andyshrk@163.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-28-c5af16c3aae2@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Maxime Ripard [Mon, 27 May 2024 13:58:16 +0000 (15:58 +0200)]
drm/vc4: tests: Convert to plane creation helper
Now that we have a plane create helper for kunit mocked drivers, let's
convert to it in vc4.
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-27-c5af16c3aae2@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Maxime Ripard [Mon, 27 May 2024 13:58:15 +0000 (15:58 +0200)]
drm/vc4: tests: Remove vc4_dummy_plane structure
The vc4_dummy_plane structure was introduced as a mean to add
mock-specific fields.
However, we never really used it and it's still strictly equivalent to
vc4_plane (which is in the same situation vs drm_plane), so we can
simply remove the vc4_dummy_plane structure and make the mock code
cleaner.
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-26-c5af16c3aae2@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Maxime Ripard [Mon, 27 May 2024 13:58:14 +0000 (15:58 +0200)]
drm/vc4: hdmi: Switch to HDMI connector
The new HDMI connector infrastructure allows us to remove a lot of
boilerplate, so let's switch to it.
Acked-by: Sui Jingfeng <sui.jingfeng@linux.dev>
Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-25-c5af16c3aae2@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Maxime Ripard [Mon, 27 May 2024 13:58:13 +0000 (15:58 +0200)]
drm/connector: hdmi: Create Infoframe DebugFS entries
There has been some discussions recently about the infoframes sent by
drivers and if they were properly generated.
In parallel, there's been some interest in creating an infoframe-decode
tool similar to edid-decode.
Both would be much easier if we were to expose the infoframes programmed
in the hardware. It won't be perfect since we have no guarantee that
it's actually what goes through the wire, but it's the best we can do.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-24-c5af16c3aae2@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Maxime Ripard [Mon, 27 May 2024 13:58:12 +0000 (15:58 +0200)]
drm/tests: Add infoframes test
The previous patch added the generation of the infoframes matching an
HDMI connector state. Let's add a few tests to make sure it works as
expected.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-23-c5af16c3aae2@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Maxime Ripard [Mon, 27 May 2024 13:58:11 +0000 (15:58 +0200)]
drm/connector: hdmi: Add Infoframes generation
Infoframes in KMS is usually handled by a bunch of low-level helpers
that require quite some boilerplate for drivers. This leads to
discrepancies with how drivers generate them, and which are actually
sent.
Now that we have everything needed to generate them in the HDMI
connector state, we can generate them in our common logic so that
drivers can simply reuse what we precomputed.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-22-c5af16c3aae2@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Maxime Ripard [Mon, 27 May 2024 13:58:10 +0000 (15:58 +0200)]
drm/tests: Add RGB Quantization tests
The previous commit added the infrastructure to the connector state to
track what RGB Quantization should be used in a given state for an HDMI
connector.
Let's add some kunit tests to make sure it works as expected.
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-21-c5af16c3aae2@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Maxime Ripard [Mon, 27 May 2024 13:58:09 +0000 (15:58 +0200)]
drm/connector: hdmi: Add RGB Quantization Range to the connector state
HDMI controller drivers will need to figure out the RGB range they need
to configure based on a mode and property values. Let's expose that in
the HDMI connector state so drivers can just use that value.
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-20-c5af16c3aae2@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Maxime Ripard [Mon, 27 May 2024 13:58:08 +0000 (15:58 +0200)]
drm/tests: Add tests for Broadcast RGB property
This had a bunch of kunit tests to make sure our code to handle the
Broadcast RGB property behaves properly.
This requires bringing a bit of infrastructure to create mock HDMI
connectors, with custom EDIDs.
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-19-c5af16c3aae2@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Maxime Ripard [Mon, 27 May 2024 13:58:07 +0000 (15:58 +0200)]
drm/connector: hdmi: Add Broadcast RGB property
The i915 driver has a property to force the RGB range of an HDMI output.
The vc4 driver then implemented the same property with the same
semantics. KWin has support for it, and a PR for mutter is also there to
support it.
Both drivers implementing the same property with the same semantics,
plus the userspace having support for it, is proof enough that it's
pretty much a de-facto standard now and we can provide helpers for it.
Let's plumb it into the newly created HDMI connector.
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-18-c5af16c3aae2@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Maxime Ripard [Mon, 27 May 2024 13:58:06 +0000 (15:58 +0200)]
drm/doc: Remove unused Broadcast RGB Property
The Broadcast RGB property has been documented as three separate entries
so far, each with a different set of values.
The first one is pretty much the generic one: it's used by i915 and vc4,
and is the one used by all the compositors.
The second one is used by the gma500 driver, and is a subset of the
first one: it can have the values "Full" or "Limited 16:235", but lack
the "Automatic" value.
The third one however isn't used by any driver and documents the values
"off", "auto" and "on".
It's unclear where the last one comes from. It was first documented in
commit
6c6a3996f2c5 ("Documentation: drm: describing drm properties
exposed by various drivers") which adds a number of properties used by
drivers, but without mentioning which driver was using what property.
Grepping at the
6c6a3996f2c5 commit however, it looks like no driver is
actually using it, and a quick look at the entire kernel history doesn't
show any match either.
At the time though, gma500 had an "audio" property used right next to
Broadcast RGB that did have the "off", "auto" and "on" values in the
same order.
As such, it was probably a copy/paste or scripting error back then, and
there's never been such property used in the kernel.
Either way, it certainly hasn't been used in a decade or two so we can
just get rid of it.
Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-17-c5af16c3aae2@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Maxime Ripard [Mon, 27 May 2024 13:58:05 +0000 (15:58 +0200)]
drm/tests: Add HDMI connector bpc and format tests
The previous patch added the bpc and format an HDMI connector needs to
be set up with for a given connector state.
Let's add a few tests to make sure it works as expected.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-16-c5af16c3aae2@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Maxime Ripard [Mon, 27 May 2024 13:58:04 +0000 (15:58 +0200)]
drm/connector: hdmi: Compute bpc and format automatically
Now that we have all the infrastructure needed, we can add some code
that will, for a given connector state and mode, compute the best output
format and bpc.
The algorithm is equivalent to the one already found in i915 and vc4.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-15-c5af16c3aae2@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
projects / linux-2.6-block.git / log