- 10 Jun, 2024 14 commits
-
-
Marek Vasut authored
Fix comment copy-paste error in tc_edp_mode_valid(), this function is validating DP/eDP clock, not DPI clock frequency. Update the comment to match. No functional change. Signed-off-by:
Marek Vasut <marex@denx.de> Reviewed-by:
Robert Foss <rfoss@kernel.org> Signed-off-by:
-
Sam Ravnborg authored
There are no users left of drm_bridge_chain_mode_fixup() and we do not want to have this function available, so drop it. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
Maxime Ripard <mripard@kernel.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Sam Ravnborg authored
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:
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:
-
Jocelyn Falempe authored
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 authored
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 authored
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:
-
Ondrej Jirman authored
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.czSigned-off-by:
-
Ondrej Jirman authored
These will be needed later on when we move layer configuration to crtc update. Signed-off-by:
-
Ondrej Jirman authored
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:
-
Jeff Johnson authored
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:
-
Jeff Johnson authored
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:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Jeff Johnson authored
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:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Jeff Johnson authored
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 authored
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:
-
- 07 Jun, 2024 5 commits
-
-
Noralf Trønnes authored
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.orgSigned-off-by:
Noralf Trønnes <noralf@tronnes.org>
-
Noralf Trønnes authored
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.orgSigned-off-by:
-
Noralf Trønnes authored
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:
-
Noralf Trønnes authored
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:
-
Noralf Trønnes authored
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.orgSigned-off-by:
-
- 06 Jun, 2024 16 commits
-
-
Michal Wajdeczko authored
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.comSigned-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Michal Wajdeczko authored
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:
-
Michal Wajdeczko authored
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 authored
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 authored
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:
-
Primoz Fiser authored
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.pdfSigned-off-by:
Primoz Fiser <primoz.fiser@norik.com> Reviewed-by:
-
Primoz Fiser authored
Add PrimeView PM070WL4 7.0" 800x480 TFT LCD panel compatible string. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20240606080104.3663355-2-primoz.fiser@norik.comSigned-off-by:
-
Primoz Fiser authored
The Prime View International (PVI) is a LCD panel manufacturer. Signed-off-by:
-
Vignesh Raman authored
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:
-
Vignesh Raman authored
Skip driver specific tests and skip kms tests for panfrost driver since it is not a kms driver. Reviewed-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Acked-by:
-
Vignesh Raman authored
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:
-
Vignesh Raman authored
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 authored
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 authored
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:
-
Rodrigo Vivi authored
Last caller was removed with commit 078a5b49 ("drm/tests: Remove slow tests"). Cc: Maxime Ripard <mripard@kernel.org> Acked-by:
-
Haoran Liu authored
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:
-
- 05 Jun, 2024 2 commits
-
-
Barry Song authored
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 authored
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: 3cbcbe01 ("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:
-
- 04 Jun, 2024 3 commits
-
-
Lucas Stach authored
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:
-
Wyon Bi authored
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 authored
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:
-
