aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-06-06drm/print: Add missing [drm] prefix to drm based WARNMichal Wajdeczko1-2/+2
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 <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-06-06drm/panel: simple: Add PrimeView PM070WL4 supportPrimoz Fiser1-0/+29
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 <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-06dt-bindings: display: simple: Add PrimeView PM070WL4 panelPrimoz Fiser1-0/+2
Add PrimeView PM070WL4 7.0" 800x480 TFT LCD panel compatible string. Signed-off-by: Primoz Fiser <[email protected]> Acked-by: Conor Dooley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-06dt-bindings: vendor-prefixes: Add PrimeViewPrimoz Fiser1-0/+2
The Prime View International (PVI) is a LCD panel manufacturer. Signed-off-by: Primoz Fiser <[email protected]> Acked-by: Conor Dooley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-06drm/ci: update xfails for the new testlistVignesh Raman53-388/+1023
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 <[email protected]> # msm testlists Signed-off-by: Vignesh Raman <[email protected]> Reviewed-by: Jessica Zhang <[email protected]> # msm test list Acked-by: Helen Koike <[email protected]> Signed-off-by: Helen Koike <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Helen Koike <[email protected]>
2024-06-06drm/ci: skip driver specific testsVignesh Raman19-10/+229
Skip driver specific tests and skip kms tests for panfrost driver since it is not a kms driver. Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Vignesh Raman <[email protected]> Reviewed-by: Jessica Zhang <[email protected]> Acked-by: Helen Koike <[email protected]> Signed-off-by: Helen Koike <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-06drm/ci: uprev IGTVignesh Raman2-1/+5
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 <[email protected]> Signed-off-by: Vignesh Raman <[email protected]> Acked-by: Helen Koike <[email protected]> Signed-off-by: Helen Koike <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-06drm/ci: generate testlist from buildVignesh Raman3-2765/+40
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 <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Jessica Zhang <[email protected]> Acked-by: Helen Koike <[email protected]> Signed-off-by: Helen Koike <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-06drm/ci: add farm variableVignesh Raman1-2/+9
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 <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Jessica Zhang <[email protected]> Acked-by: Helen Koike <[email protected]> Signed-off-by: Helen Koike <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-06drm/ci: uprev mesa versionVignesh Raman6-28/+42
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 <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Jessica Zhang <[email protected]> Acked-by: Helen Koike <[email protected]> Signed-off-by: Helen Koike <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-06drm/mm: Remove unused drm_mm_replace_nodeRodrigo Vivi2-36/+0
Last caller was removed with commit 078a5b498d6a ("drm/tests: Remove slow tests"). Cc: Maxime Ripard <[email protected]> Acked-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-06-06drm/meson: plane: Add error handlingHaoran Liu1-6/+11
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 <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] [narmstrong: fixe the commit subject] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-05dma-buf: align fd_flags and heap_flags with dma_heap_allocation_dataBarry Song2-3/+3
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 <[email protected]> Acked-by: John Stultz <[email protected]> Signed-off-by: Sumit Semwal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-05drm/v3d: Fix perfmon build error/warningTvrtko Ursulin4-195/+205
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 <[email protected]> Fixes: 3cbcbe016c31 ("drm/v3d: Add Performance Counters descriptions for V3D 4.2 and 7.1") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/Cc: Maíra Canal <[email protected]> Cc: Iago Toral Quiroga <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Ashutosh Dixit <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-04drm/bridge: analogix_dp: don't adjust further when clock recovery succeededLucas Stach1-29/+26
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 <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-04drm/bridge: analogix_dp: simplify analogix_dp_{set/get}_lane_link_training ↵Wyon Bi3-207/+26
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 <[email protected]> Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-04drm/bridge: analogix_dp: properly handle zero sized AUX transactionsLucas Stach1-4/+1
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: [email protected] Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-03drm: panel: nv3052c: Add WL-355608-A8 panelRyan Walklin1-0/+225
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 <[email protected]> Co-developed-by: Hironori KIKUCHI <[email protected]> Signed-off-by: Hironori KIKUCHI <[email protected]> Reviewed-by: John Watts <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Acked-by: Jessica Zhang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-03dt-bindings: display: panel: Add WL-355608-A8 panelRyan Walklin1-0/+60
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 <[email protected]> Reviewed-by: Conor Dooley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-03MAINTAINERS: drm: Drop sam as panel reviewerSam Ravnborg1-1/+0
Drop myself as reviewer of panel patches, to reflect the reality. Signed-off-by: Sam Ravnborg <[email protected]> Cc: Neil Armstrong <[email protected]> Acked-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-31dma-buf: add a warning when drv try to reserve 0 fence slotsChristian König1-0/+7
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 <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Matthew Auld <[email protected]>
2024-05-31drm/ci: validate drm/msm XML register files against schemaDmitry Baryshkov2-0/+4
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 <[email protected]> Acked-by: Helen Koike <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-05-30drm: atmel-hlcdc: add LCD controller layer definition for sam9x75Manikandan Muralidharan1-0/+100
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 <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-30drm: atmel-hlcdc: add support for DSI output formatsManikandan Muralidharan1-6/+64
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 <[email protected]> [[email protected]: update output format using is_xlcdc flag] Signed-off-by: Durai Manickam KR <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-30drm: atmel-hlcdc: add vertical and horizontal scaling support for XLCDCManikandan Muralidharan2-0/+24
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 <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-30drm: atmel-hlcdc: add DPI mode support for XLCDCManikandan Muralidharan1-2/+19
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 <[email protected]> [[email protected]: update DPI mode bit using is_xlcdc flag] Signed-off-by: Durai Manickam KR <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-30drm: atmel_hlcdc: Add support for XLCDC using IP specific driver opsManikandan Muralidharan3-5/+217
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 <[email protected]> Co-developed-by: Hari Prasath Gujulan Elango <[email protected]> Signed-off-by: Hari Prasath Gujulan Elango <[email protected]> Co-developed-by: Durai Manickam KR <[email protected]> Signed-off-by: Durai Manickam KR <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-30drm: atmel_hlcdc: replace regmap_read with regmap_read_poll_timeoutManikandan Muralidharan1-19/+25
Replace regmap_read with regmap_read_poll_timeout to neatly handle retries Signed-off-by: Manikandan Muralidharan <[email protected]> Acked-by: Dharma Balasubiramani <[email protected]> Reviewed-by: Hari Prasath Gujulan Elango <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-30drm: atmel-hlcdc: Define XLCDC specific registersDurai Manickam KR2-0/+52
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 <[email protected]> [[email protected]: Remove unused macro definitions] Signed-off-by: Manikandan Muralidharan <[email protected]> Acked-by: Lee Jones <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-30drm: atmel-hlcdc: add driver ops to differentiate HLCDC and XLCDC IPManikandan Muralidharan3-83/+172
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 <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-29drm/display: Fix HDMI state helper dependencyMaxime Ripard1-1/+1
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 <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: 54cb39e2293b ("drm/connector: hdmi: Create an HDMI sub-state") Reviewed-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2024-05-29drm/sun4i: Fix compilation errorMaxime Ripard1-3/+2
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 <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: ea64761a54a2 ("drm/sun4i: hdmi: Switch to HDMI connector") Reviewed-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2024-05-28drm/panel-edp: Add more panels with conservative timingsPin-yen Lin1-0/+3
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 <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-28drm/panel-edp: Add support for several panelsPin-yen Lin1-0/+3
Add support for the following models: AUO B140HTN02.0 BOE NT116WHM-N21 V4.1 BOE NT116WHM-N21 Signed-off-by: Pin-yen Lin <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-28drm/panel: sony-acx565akm: Don't call disable at removeDouglas Anderson1-3/+0
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/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Laurent Pinchart <[email protected]> Cc: Sebastian Reichel <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.47.I2513fd6824929a17c1ccd18a797b98a1a1063559@changeid
2024-05-28drm/panel: sony-acx565akm: Don't double-check enabled state in disableDouglas Anderson1-3/+0
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 <[email protected]> Cc: Sebastian Reichel <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.46.I6a51b36831a5c7b2b82bccf8c550cf0d076aa541@changeid
2024-05-28drm/panel: sitronix-st7703: Don't call disable at shutdown/removeDouglas Anderson1-17/+0
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/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Guido Günther <[email protected]> Cc: Ondřej Jirman <[email protected]> Cc: Chris Morgan <[email protected]> Cc: Frank Oltmanns <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.43.I08ba0d4e2d534c06ab0ede9c148bb14cc7c1a9d7@changeid
2024-05-28drm/panel: sitronix-st7703: Stop tracking preparedDouglas Anderson1-11/+7
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 <[email protected]> Cc: Ondřej Jirman <[email protected]> Cc: Chris Morgan <[email protected]> Cc: Frank Oltmanns <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.42.Ifc436b262d72f1a33ddef10adfd7578d4acb60d8@changeid
2024-05-28drm/panel: xinpeng-xpp055c272: Don't call unprepare+disable at shutdown/removeDouglas Anderson1-17/+0
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/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.31.Ib97e67a9877070698afbec4f8ede091b2bf89a1f@changeid
2024-05-28drm/panel: xinpeng-xpp055c272: Stop tracking preparedDouglas Anderson1-11/+0
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 <[email protected]> Acked-by: Maxime Ripard <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.30.I2145be78ce28327f4588c2c21370f22fd79d28b8@changeid
2024-05-28drm/panel: simple: Add a comment about unprepare+disable at shutdown/removeDouglas Anderson1-10/+23
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/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.27.I639183ac987e139092491a94e22d46a5d857580c@changeid
2024-05-28drm/panel: simple: Stop tracking prepared/enabledDouglas Anderson1-27/+0
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 <[email protected]> Acked-by: Maxime Ripard <[email protected]> Acked-by: Sui Jingfeng <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.26.I865be97dd393d6ae3c3a3cd1358c95fdbca0fe83@changeid
2024-05-28drm/panel: samsung-atna33xc20: Don't call unprepare+disable at shutdown/removeDouglas Anderson1-12/+0
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/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.25.Iaeacccf98e6cb729b8fc3a782725769cd66812ad@changeid
2024-05-28drm/panel: samsung-atna33xc20: Stop tracking prepared/enabledDouglas Anderson1-24/+0
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 <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.24.Ibb4f923363a27167c480a432e52884b117221974@changeid
2024-05-28drm/panel: novatek-nt36672a: Don't call unprepare+disable at shutdown/removeDouglas Anderson1-17/+0
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/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Sumit Semwal <[email protected]> Cc: Benni Steini <[email protected]> Cc: Marijn Suijten <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Tested-by: Joel Selvaraj <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.19.I67819ba5513d4ef85f254a68b22a3402b4cdf30f@changeid
2024-05-28drm/panel: novatek-nt36672a: Stop tracking preparedDouglas Anderson1-12/+0
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 <[email protected]> Cc: Benni Steini <[email protected]> Cc: Marijn Suijten <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Tested-by: Joel Selvaraj <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.18.I13a06b9e6f5920659b1e5d12543b3cd9066383b8@changeid
2024-05-28drm/panel: ltk500hd1829: Don't call unprepare+disable at shutdown/removeDouglas Anderson1-17/+0
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/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.17.If3edcf846f754b425959980039372a9fd1599ecc@changeid
2024-05-28drm/panel: ltk500hd1829: Stop tracking preparedDouglas Anderson1-11/+0
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 <[email protected]> Acked-by: Maxime Ripard <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.16.I4f574b87fe24765ddd4424437159b37a6481aa1a@changeid
2024-05-28drm/panel: ltk050h3146w: Don't call unprepare+disable at shutdown/removeDouglas Anderson1-17/+0
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/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Reviewed-by: Quentin Schulz <[email protected]> Tested-by: Quentin Schulz <[email protected]> # RK3399 Puma with Haikou Video Demo Tested-by: Quentin Schulz <[email protected]> # PX30 Ringneck with Haikou Video Demo Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.15.Ibeb2e5692e34b136afe4cf55532f0696ab3f5eed@changeid
2024-05-28drm/panel: ltk050h3146w: Stop tracking preparedDouglas Anderson1-11/+0
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 <[email protected]> Acked-by: Maxime Ripard <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Reviewed-by: Quentin Schulz <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.14.I264417152e65b4a2e374666010666fa1c2d973fc@changeid