dri-devel April 2022

dri-devel@lists.freedesktop.org

351 participants
951 discussions

DRM Master ignoring hotplug event during display switching (QT)
by Jagan Teki 08 Jun '22

08 Jun '22

Hi all, I have implemented runtime display switching in the MIPI switch design where LVDS and HDMI bridges are selected with the help of runtime GPIO. Initial discussion on the same can be found here, https://www.spinics.net/lists/dri-devel/msg318524.html The implementation has been done by creating each connector at runtime. The default boot will create the LVDS connector and based on the HDMI plug-in the ISR. 1. forcing the LVDS to disconnect 2. call drm_kms_helper_hotplug_event 3. detach … [View More]

4 11

[RFC PATCH 00/16] drm/rockchip: Rockchip EBC ("E-Book Controller") display driver
by Samuel Holland 08 Jun '22

08 Jun '22

This series adds a DRM driver for the electrophoretic display controller found in a few different Rockchip SoCs, specifically the RK3566/RK3568 variant[0] used by the PineNote tablet[1]. This is my first real involvement with the DRM subsystem, so please let me know where I am misunderstanding things. This is now the second SoC-integrated EPD controller with a DRM driver submission -- the first one being the i.MX6 EPDC[2]. I want to thank Andreas for sending that series, and for his advice … [View More]while writing this driver. One goal I have with sending this series is to discuss how to support EPDs more generally within the DRM subsystem, so the interfaces with panels and PMICs and waveform LUTs can be controller-independent. My understanding is that the i.MX6 EPDC series is at least partly based on the downstream vendor driver. This driver is a clean-sheet design for hardware with different (read: fewer) capabilities, so we took some different design paths, but we ran into many of the same sharp edges. Here are some of the areas I would like input on: Panel Lifecycle =============== Panels use prepare/unprepare callbacks for their power supply. EPDs should only be powered up when the display contents are changed. Should the controller call both drm_panel_(un)prepare during each atomic update when the framebuffer is dirty? Similarly, panel enable/disable callbacks are tied to backlight state. For an EPD, it makes sense to have the backlight enabled while the panel is powered down (because the contents are static). Is it acceptable to call drm_panel_{en,dis}able while the panel is not prepared? With panel_bridge, the "normal" callback ordering is enforced, and tied to the atomic state, so neither of these is possible. As a result, neither the backlight nor the voltage regulators are tied to the panel. The panel's regulators are consumed by the EBC itself. Panel Timing Parameters ======================= EPDs have more timing parameters than LCDs, and there are several different ways of labeling these parameters. See for example the timing diagrams on pp. 2237-2239 of the RK3568 TRM[0], the descriptions in the ED103TC2 panel datasheet[3], and the submitted EPDC bindings[2]. Both the EPDC and EBC vendor drivers put all of the timing parameters in the controller's OF node. There is no panel device/node. I was able to squeeze everything needed for my specific case into a struct drm_display_mode (see patches 5 and 14), but I don't know if this is an acceptable use of those fields, or if will work with other controllers. Is adding more fields to drm_display_mode an option? See also the discussion of "dumb" LCD TCONs below. Panel Connector Type / Media Bus Format ======================================= The EBC supports either an 8-bit or 16-bit wide data bus, where each pair of data lines represents the source driver polarity (positive, negative, or neutral) for a pixel. The only effect of the data bus width is the number of pixels that are transferred per clock cycle. It has no impact on the number of possible grayscale levels. How does that translate to DRM_MODE_CONNECTOR_* or MEDIA_BUS_FMT_*? Panel Reflection ================ The ED103TC2 panel scans from right to left. Currently, there is no API or OF property to represent this. I can add something similar to drm_panel_orientation. Should this be exposed to userspace? It is acceptable for the kernel driver to flip the image when blitting from the framebuffer? CRTC "active" and "enabled" states ================================== What do these states mean in the context of an EPD? Currently, the driver ignores "active" and clears the screen to solid white when the CRTC is disabled. The vendor drivers can switch to a user-provided image when the CRTC is disabled. Is this something that can/should be supported upstream? If so, how? Would userspace provide the image to the kernel, or just tell the kernel not to clear the screen? VBLANK Events and Asynchronous Commits ====================================== When should the VBLANK event complete? When the pixels have been blitted to the kernel's shadow buffer? When the first frame of the waveform is sent to the panel? When the last frame is sent to the panel? Currently, the driver is taking the first option, letting drm_atomic_helper_fake_vblank() send the VBLANK event without waiting on the refresh thread. This is the only way I was able to get good performance with existing userspace. Waveform Loading ================ Waveform files are calibrated for each batch of panels. So while a single waveform file may be "good enough" for all panels of a certain model, the correctly-calibrated file will have better image quality. I don't know of a good way to choose the calibrated file. Even the board's compatible string may not be specific enough, if the board is manufactured with multiple batches of panels. Maybe the filename should just be the panel compatible, and the user is responsible for putting the right file there? In that case, how should I get the compatible string from the panel_bridge? Traverse the OF graph myself? There is also the issue that different controllers need the waveform data in different formats. ".wbf" appears to be the format provided by PVI/eInk, the panel manufacturer. The Rockchip EBC hardware expects a single waveform in a flat array, so the driver has to extract/decompress that from the .wbf file (this is done in patch 1). On the other hand, the i.MX EPDC expects a ".wrf" file containing multiple waveforms[8]. I propose that the waveform file on disk should always be what was shipped with the panel -- the .wbf file -- and any extracting or reformatting is done in the kernel. Waveform Selection From Userspace ================================= EPDs use different waveforms for different purposes: high-quality grayscale vs. monochrome text vs. dithered monochrome video. How can userspace select which waveform to use? Should this be a plane property? It is also likely that userspace will want to use different waveforms at the same time for different parts of the screen, for example a fast monochrome waveform for the drawing area of a note-taking app, but a grayscale waveform for surrounding UI and window manager. I believe the i.MX6 EPDC supports multiple planes, each with their own waveform choice. That seems like a good abstraction, but the EBC only supports one plane in hardware. So using this abstraction with the EBC would require blending pixels and doing waveform lookups in software. Blitting/Blending in Software ============================= There are multiple layers to this topic (pun slightly intended): 1) Today's userspace does not expect a grayscale framebuffer. Currently, the driver advertises XRGB8888 and converts to Y4 in software. This seems to match other drivers (e.g. repaper). 2) Ignoring what userspace "wants", the closest existing format is DRM_FORMAT_R8. Geert sent a series[4] adding DRM_FORMAT_R1 through DRM_FORMAT_R4 (patch 9), which I believe are the "correct" formats to use. 3) The RK356x SoCs have an "RGA" hardware block that can do the RGB-to-grayscale conversion, and also RGB-to-dithered-monochrome which is needed for animation/video. Currently this is exposed with a V4L2 platform driver. Can this be inserted into the pipeline in a way that is transparent to userspace? Or must some userspace library be responsible for setting up the RGA => EBC pipeline? 4) Supporting multiple planes (for multiple concurrent waveforms) implies blending in software. Is that acceptable? 5) Thoughts on SIMD-optimized blitting and waveform lookup functions? 5) Currently the driver uses kmalloc() and dma_sync_single_for_device() for its buffers, because it needs both fast reads and fast writes to several of them. Maybe cma_alloc() or dma_alloc_from_contiguous() would be more appropriate, but I don't see any drivers using those directly. EPDs connected to "dumb" LCD TCONs ================================== This topic is mostly related to my first patch. Some boards exist that hook up an EPD to a normal LCD TCON, not a dedicated EPD controller. For example, there's the reMarkable 2[5] and some PocketBook models[6][7]. I have some concerns about this: 1) If we put EPD panel timings in panel drivers (e.g. panel-simple), can the same timings work with LCD TCONs and EPD controllers? For example: one cycle of the 16-bit data bus is "one pixel" to an LCD controller, but is "8 pixels" to an EPD controller. So there is a factor-of-8 difference in horizontal resolution depending on your perspective. Should we have the "number of pixel clock cycles" or "number of pixels" in .hdisplay/.htotal in the panel timings? Patch 14 adds a panel with "number of pixels" horizontal resolution, so the correct resolution is reported to userspace, but the existing eink_vb3300_kca_timing in panel-simple.c appears to use "number of pixel clocks" for its horizontal resolution. This makes the panel timing definitions incompatible across controllers. 2) Using fbdev/fbcon with an EPD hooked up to an LCD TCON will have unintended consequences, and possibly damage the panel. Currently, there is no way to mark the framebuffer as expecting "source driver polarity waveforms" and not pixel data. Is there a specific DRM_FORMAT_* we should use for these cases to prevent accidental use by userspace? Or should we disallow this entirely, and have some wrapper layer to do the waveform lookups in kernelspace? I like the wrapper layer idea because it allows normal userspace and fbcon to work. It would not be much new code, especially since this driver already supports doing the whole pipeline in software. So that's why I wrote a separate helper library; I hope this code can be reused. Thanks for any input! Samuel [0]: https://dl.radxa.com/rock3/docs/hw/datasheet/Rockchip%20RK3568%20TRM%20Part… [1]: https://wiki.pine64.org/wiki/PineNote [2]: https://lore.kernel.org/lkml/20220206080016.796556-1-andreas@kemnade.info/T/ [3]: https://files.pine64.org/doc/quartz64/Eink%20P-511-828-V1_ED103TC2%20Formal… [4]: https://lore.kernel.org/lkml/cover.1646683502.git.geert@linux-m68k.org/T/ [5]: https://lore.kernel.org/lkml/20220330094126.30252-1-alistair@alistair23.me/… [6]: https://github.com/megous/linux/commits/pb-5.17 [7]: https://github.com/megous/linux/commit/3cdf84388959 [8]: https://github.com/fread-ink/inkwave Samuel Holland (16): drm: Add a helper library for EPD drivers dt-bindings: display: rockchip: Add EBC binding drm/rockchip: Add EBC platform driver skeleton drm/rockchip: ebc: Add DRM driver skeleton drm/rockchip: ebc: Add CRTC mode setting drm/rockchip: ebc: Add CRTC refresh thread drm/rockchip: ebc: Add CRTC buffer management drm/rockchip: ebc: Add LUT loading drm/rockchip: ebc: Implement global refreshes drm/rockchip: ebc: Implement partial refreshes drm/rockchip: ebc: Enable diff mode for partial refreshes drm/rockchip: ebc: Add support for direct mode drm/rockchip: ebc: Add a panel reflection option drm/panel-simple: Add eInk ED103TC2 arm64: dts: rockchip: rk356x: Add EBC node [DO NOT MERGE] arm64: dts: rockchip: pinenote: Enable EBC display pipeline .../display/rockchip/rockchip,rk3568-ebc.yaml | 106 ++ .../boot/dts/rockchip/rk3566-pinenote.dtsi | 80 + arch/arm64/boot/dts/rockchip/rk356x.dtsi | 14 + drivers/gpu/drm/Kconfig | 6 + drivers/gpu/drm/Makefile | 4 +- drivers/gpu/drm/drm_epd_helper.c | 663 +++++++ drivers/gpu/drm/panel/panel-simple.c | 31 + drivers/gpu/drm/rockchip/Kconfig | 12 + drivers/gpu/drm/rockchip/Makefile | 2 + drivers/gpu/drm/rockchip/rockchip_ebc.c | 1586 +++++++++++++++++ include/drm/drm_epd_helper.h | 104 ++ 11 files changed, 2607 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip,rk3568-ebc.yaml create mode 100644 drivers/gpu/drm/drm_epd_helper.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_ebc.c create mode 100644 include/drm/drm_epd_helper.h -- 2.35.1 [View Less]

5 27

[PATCH 00/33] Remaining patches for basic GuC submission
by Matthew Brost 07 Jun '22

07 Jun '22

The remaining patches for basic GuC submission [1]. Need 1 more RB and CI results to get this merged. v2: (Checkpatch) - Fix checkpatch warning (1 remaining overrulled) (Daniele) - Use an outer lock in guc_context_block / unblock Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> [1] https://patchwork.freedesktop.org/series/91840/ Daniele Ceraolo Spurio (1): drm/i915/guc: Unblock GuC submission on Gen11+ Daniele Ceraolo Spurio (1): drm/i915/guc: Unblock GuC … [View More]submission on Gen11+ John Harrison (12): drm/i915/guc: Make hangcheck work with GuC virtual engines drm/i915/guc: Provide mmio list to be saved/restored on engine reset drm/i915/guc: Don't complain about reset races drm/i915/guc: Enable GuC engine reset drm/i915/guc: Fix for error capture after full GPU reset with GuC drm/i915/guc: Hook GuC scheduling policies up drm/i915/guc: Connect reset modparam updates to GuC policy flags drm/i915/guc: Include scheduling policies in the debugfs state dump drm/i915/guc: Add golden context to GuC ADS drm/i915/selftest: Better error reporting from hangcheck selftest drm/i915/selftest: Fix hangcheck self test for GuC submission drm/i915/selftest: Bump selftest timeouts for hangcheck Matthew Brost (18): drm/i915/guc: GuC virtual engines drm/i915: Hold reference to intel_context over life of i915_request drm/i915/guc: Disable bonding extension with GuC submission drm/i915/guc: Direct all breadcrumbs for a class to single breadcrumbs drm/i915: Add i915_sched_engine destroy vfunc drm/i915: Move active request tracking to a vfunc drm/i915/guc: Reset implementation for new GuC interface drm/i915: Reset GPU immediately if submission is disabled drm/i915/guc: Add disable interrupts to guc sanitize drm/i915/guc: Suspend/resume implementation for new interface drm/i915/guc: Handle context reset notification drm/i915/guc: Handle engine reset failure notification drm/i915/guc: Enable the timer expired interrupt for GuC drm/i915/guc: Capture error state on context reset drm/i915/guc: Implement banned contexts for GuC submission drm/i915/guc: Support request cancellation drm/i915/selftest: Increase some timeouts in live_requests drm/i915/guc: Implement GuC priority management Rahul Kumar Singh (2): drm/i915/selftest: Fix workarounds selftest for GuC submission drm/i915/selftest: Fix MOCS selftest for GuC submission drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gem/i915_gem_context.c | 15 +- drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 44 +- drivers/gpu/drm/i915/gt/intel_breadcrumbs.h | 16 +- .../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 7 + drivers/gpu/drm/i915/gt/intel_context.c | 36 + drivers/gpu/drm/i915/gt/intel_context.h | 23 + drivers/gpu/drm/i915/gt/intel_context_types.h | 33 +- drivers/gpu/drm/i915/gt/intel_engine.h | 57 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 183 +- .../gpu/drm/i915/gt/intel_engine_heartbeat.c | 70 +- .../gpu/drm/i915/gt/intel_engine_heartbeat.h | 4 + drivers/gpu/drm/i915/gt/intel_engine_types.h | 13 +- drivers/gpu/drm/i915/gt/intel_engine_user.c | 4 + .../drm/i915/gt/intel_execlists_submission.c | 89 +- .../drm/i915/gt/intel_execlists_submission.h | 4 - drivers/gpu/drm/i915/gt/intel_gt.c | 2 + drivers/gpu/drm/i915/gt/intel_gt_pm.c | 6 +- drivers/gpu/drm/i915/gt/intel_reset.c | 50 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 58 + drivers/gpu/drm/i915/gt/intel_rps.c | 4 + drivers/gpu/drm/i915/gt/intel_workarounds.c | 46 +- .../gpu/drm/i915/gt/intel_workarounds_types.h | 1 + drivers/gpu/drm/i915/gt/mock_engine.c | 34 +- .../drm/i915/gt/selftest_engine_heartbeat.c | 22 + .../drm/i915/gt/selftest_engine_heartbeat.h | 2 + drivers/gpu/drm/i915/gt/selftest_execlists.c | 12 +- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 322 +++- drivers/gpu/drm/i915/gt/selftest_mocs.c | 50 +- .../gpu/drm/i915/gt/selftest_workarounds.c | 132 +- .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 + drivers/gpu/drm/i915/gt/uc/intel_guc.c | 82 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h | 38 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 464 ++++- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.h | 4 + drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 11 +- .../gpu/drm/i915/gt/uc/intel_guc_debugfs.c | 2 + .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 1611 +++++++++++++++-- .../gpu/drm/i915/gt/uc/intel_guc_submission.h | 13 +- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 101 +- drivers/gpu/drm/i915/gt/uc/intel_uc.h | 6 + drivers/gpu/drm/i915/i915_debugfs_params.c | 32 + drivers/gpu/drm/i915/i915_gpu_error.c | 25 +- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/i915_request.c | 162 +- drivers/gpu/drm/i915/i915_request.h | 21 + drivers/gpu/drm/i915/i915_scheduler.c | 16 +- drivers/gpu/drm/i915/i915_scheduler.h | 10 +- drivers/gpu/drm/i915/i915_scheduler_types.h | 22 + drivers/gpu/drm/i915/i915_trace.h | 37 +- drivers/gpu/drm/i915/selftests/i915_request.c | 4 +- .../gpu/drm/i915/selftests/igt_flush_test.c | 2 +- .../i915/selftests/intel_scheduler_helpers.c | 88 + .../i915/selftests/intel_scheduler_helpers.h | 33 + include/uapi/drm/i915_drm.h | 9 + 55 files changed, 3501 insertions(+), 634 deletions(-) create mode 100644 drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c create mode 100644 drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.h -- 2.28.0 [View Less]

7 47

[PATCH v4 00/13] drm/msm: drm scheduler conversion and cleanups
by Rob Clark 07 Jun '22

07 Jun '22

From: Rob Clark <robdclark(a)chromium.org> Conversion to gpu_scheduler, and bonus removal of drm_gem_object_put_locked() v2: Fix priority mixup (msm UAPI has lower numeric priority value as higher priority, inverse of drm/scheduler) and add some comments in the UAPI header to clarify. Now that we move active refcnt get into msm_gem_submit, add a patch to mark all bos busy before pinning, to avoid evicting bos used in same batch. Fix bo locking for cmdstream … [View More]dumping ($debugfs/n/{rd,hangrd}) v3: Add a patch to drop submit bo_list and instead use -EALREADY to detect errors with same obj appearing multiple times in the submit ioctl bos table. Otherwise, with struct_mutex locking dropped, we'd need to move insertion into and removal from bo_list under the obj lock. v4: One last small tweak, drop unused wait_queue_head_t in msm_fence_context Rob Clark (13): drm/msm: Docs and misc cleanup drm/msm: Small submitqueue creation cleanup drm/msm: drop drm_gem_object_put_locked() drm: Drop drm_gem_object_put_locked() drm/msm/submit: Simplify out-fence-fd handling drm/msm: Consolidate submit bo state drm/msm: Track "seqno" fences by idr drm/msm: Return ERR_PTR() from submit_create() drm/msm: Conversion to drm scheduler drm/msm: Drop submit bo_list drm/msm: Drop struct_mutex in submit path drm/msm: Utilize gpu scheduler priorities drm/msm/gem: Mark active before pinning drivers/gpu/drm/drm_gem.c | 22 -- drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 4 +- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 6 +- drivers/gpu/drm/msm/adreno/a5xx_power.c | 2 +- drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 7 +- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 12 +- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +- drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 4 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 6 +- drivers/gpu/drm/msm/msm_drv.c | 30 +- drivers/gpu/drm/msm/msm_fence.c | 42 --- drivers/gpu/drm/msm/msm_fence.h | 3 - drivers/gpu/drm/msm/msm_gem.c | 94 +----- drivers/gpu/drm/msm/msm_gem.h | 47 +-- drivers/gpu/drm/msm/msm_gem_submit.c | 344 ++++++++++++-------- drivers/gpu/drm/msm/msm_gpu.c | 46 +-- drivers/gpu/drm/msm/msm_gpu.h | 78 ++++- drivers/gpu/drm/msm/msm_rd.c | 6 +- drivers/gpu/drm/msm/msm_ringbuffer.c | 70 +++- drivers/gpu/drm/msm/msm_ringbuffer.h | 12 + drivers/gpu/drm/msm/msm_submitqueue.c | 53 ++- include/drm/drm_gem.h | 2 - include/uapi/drm/msm_drm.h | 14 +- 24 files changed, 516 insertions(+), 391 deletions(-) -- 2.31.1 [View Less]

4 34

[PATCH v3 0/4] Add RZ/G2L Display support
by Biju Das 07 Jun '22

07 Jun '22

RZ/G2L LCD controller composed of Frame compression Processor(FCPVD), Video signal processor (VSPD) and Display unit(DU). The output of LCDC is connected to Display parallel interface and MIPI link video interface. This patch series aims to add basic display support on RZ/G2L SMARC EVK platform. The output from DSI is connected to ADV7535. The DU controller is similar to R-Car as it is connected to VSPD, so most of code is based on R-Car with new CRTC/DRM driver specific to RZ/G2L V2->v3: … [View More] * Added new bindings for RZ/G2L DU * Removed indirection and created new DRM driver based on R-Car DU v1->v2: * Based on [1], all references to 'rzg2l_lcdc' replaced with 'rzg2l_du' * Updated commit description for bindings * Removed LCDC references from bindings * Changed clock name from du.0->aclk from bindings * Changed reset name from du.0->du from bindings * Replaced crtc_helper_funcs->rcar_crtc_helper_funcs * Updated macro DRM_RZG2L_LCDC->DRM_RZG2L_DU * Replaced rzg2l-lcdc-drm->rzg2l-du-drm * Added forward declaration for struct reset_control [1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220312084205… RFC->v1: * Changed minItems->maxItems for renesas,vsps. * Added RZ/G2L LCDC driver with special handling for CRTC reusing most of RCar DU code * Fixed the comments for num_rpf from rpf's->RPFs/ and vsp->VSP. RFC: https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612… https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612… https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612… https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612… Biju Das (4): dt-bindings: display: Document Renesas RZ/G2L DU bindings drm: rcar-du: Fix typo drm: rcar-du: Add num_rpf to struct rcar_du_device_info drm: rcar-du: Add RZ/G2L DU Support .../bindings/display/renesas,rzg2l-du.yaml | 159 ++++ drivers/gpu/drm/rcar-du/Kconfig | 16 +- drivers/gpu/drm/rcar-du/Makefile | 9 + drivers/gpu/drm/rcar-du/rcar_du_drv.c | 17 + drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 + drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 8 +- drivers/gpu/drm/rcar-du/rzg2l_du_crtc.c | 745 +++++++++++++++++ drivers/gpu/drm/rcar-du/rzg2l_du_crtc.h | 104 +++ drivers/gpu/drm/rcar-du/rzg2l_du_drv.c | 192 +++++ drivers/gpu/drm/rcar-du/rzg2l_du_drv.h | 102 +++ drivers/gpu/drm/rcar-du/rzg2l_du_encoder.c | 113 +++ drivers/gpu/drm/rcar-du/rzg2l_du_encoder.h | 29 + drivers/gpu/drm/rcar-du/rzg2l_du_group.h | 32 + drivers/gpu/drm/rcar-du/rzg2l_du_kms.c | 782 ++++++++++++++++++ drivers/gpu/drm/rcar-du/rzg2l_du_kms.h | 43 + drivers/gpu/drm/rcar-du/rzg2l_du_regs.h | 64 ++ drivers/gpu/drm/rcar-du/rzg2l_du_vsp.c | 420 ++++++++++ drivers/gpu/drm/rcar-du/rzg2l_du_vsp.h | 93 +++ drivers/gpu/drm/rcar-du/rzg2l_du_writeback.c | 247 ++++++ drivers/gpu/drm/rcar-du/rzg2l_du_writeback.h | 42 + 20 files changed, 3212 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_crtc.c create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_crtc.h create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_drv.c create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_drv.h create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_encoder.c create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_encoder.h create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_group.h create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_kms.c create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_kms.h create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_regs.h create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_vsp.c create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_vsp.h create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_writeback.c create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_writeback.h -- 2.25.1 [View Less]

4 16

[PATCH v1 0/2] Add 1024x768 timing for AST2600
by Tommy Haung 07 Jun '22

07 Jun '22

v1: Add 1024x768@70Hz for AST2600 soc display timing selection. Add gfx flag for future usage. Testing steps: 1. Add below config to turn VT and LOGO on. CONFIG_TTY=y CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_VT_CONSOLE_SLEEP=y CONFIG_HW_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y CONFIG_UNIX98_PTYS=y CONFIG_LDISC_AUTOLOAD=y CONFIG_DEVMEM=y CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y … [View More]

3 7

[PATCH v2 0/2] drm/bridge: analogix_dp: Self-refresh state machine fixes
by Brian Norris 07 Jun '22

07 Jun '22

Hi, I've been investigating several eDP issues on a Rockchip RK3399 system and have two proposed bugfixes. RK3399 has two CRTCs, either of which can be used for eDP output. For both fixes, we have bugs due to the relationship between the generalized "self refresh helpers" and the analogix-dp bridge driver which controls much of the PSR mechanics. These bugs are most visible when switching between CRTCs. I'm not a DRM expert, but I've been poking at a lot of Rockchip display drivers recently. … [View More]

4 9

How should "max bpc" KMS property work?
by Pekka Paalanen 03 Jun '22

03 Jun '22

Hi all, I'm working on setting HDR & WCG video modes in Weston, and I thought setting "max bpc" KMS property on the connector would be a good idea. I'm confused about how it works though. I did some digging in https://gitlab.freedesktop.org/wayland/weston/-/issues/612 Summary: - Apparently the property was originally added as a manual workaround for sink hardware behaving badly with high depth. A simple end user setting for "max bpc" would suffice for this use. - Drivers will … [View More]

9 36

[Bug 205089] New: amdgpu : drm:amdgpu_cs_ioctl : Failed to initialize parser -125
by bugzilla-daemon＠bugzilla.kernel.org 02 Jun '22

02 Jun '22

https://bugzilla.kernel.org/show_bug.cgi?id=205089 Bug ID: 205089 Summary: amdgpu : drm:amdgpu_cs_ioctl : Failed to initialize parser -125 Product: Drivers Version: 2.5 Kernel Version: 5.3.2 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)… [View More]

2 47

Re: [PATCH v6 3/6] drm: Add driver for Solomon SSD130x OLED displays
by Dominik Kierner 01 Jun '22

01 Jun '22

Hello Javier, I was working on a SSD130x driver as well, although with a different (drm_panel) approach and hit a bit of a roadblock. Now that Your driver is quite a bit maturer than mine, I will happily provide You with the source of my draft, so that any useful bits can be incorporated in Your driver. I know that links are a bit frowned upon, but I'd rather avoid cluttering the thread with my draft code, which is unfinished and incompatible with the code in this thread. https://github.com/… [View More]dh-electronics/panel-solomon-ssd130x-draft https://github.com/dh-electronics/panel-solomon-ssd130x-draft/tree/drm-ssd1… The code was designed as a rewrite from scratch, as I assumed that a new DRM driver that accommodates for I2C, 3- and 4-wire-SPI, will probably need a new DTS interface for differentiating the protocol-specific drivers, which would obviously break compatibility. I do have few suggestions though: # Atomic Configuration of Display Driving Regulator and the Charge Pump The regulator VBAT is the SSD1306-specific low-voltage (3.3 V to 5 V) regulator for the charge pump and takes the place of the voltage regulator VCC, that would otherwise supply the OLED driver block with 7 V to 15 V. The charge pump is never enabled when a VCC with 7 V to 15 V is present. Configuring the charge pump based on the available regulators, would provide an atomic configuration for either low-voltage + charge pump or the regular voltage. This way, the device tree boolean for enabling the charge pump could be removed by probing for an optional VBAT first, which replaces VCC, and falling back to a mandatory VCC otherwise: ``` [...] struct ssd130x_panel { ... struct regulator *vdd; /* Core logic supply */ union { struct regulator *vcc; /* Panel driving supply */ struct regulator *vbat; /* Charge pump regulator supply */ }; struct backlight_device *backlight; struct { unsigned int com_scan_dir_inv : 1; unsigned int com_seq_pin_cfg : 1; unsigned int com_lr_remap : 1; unsigned int seg_remap : 1; unsigned int inverse_display : 1; unsigned int use_charge_pump : 1; uint8_t height; uint8_t width; uint8_t height_mm; uint8_t width_mm; uint8_t display_start_line; uint8_t com_offset ; uint8_t contrast; uint8_t pre_charge_period_dclocks_phase1; uint8_t pre_charge_period_dclocks_phase2; uint8_t vcomh_deselect_level; uint8_t clock_divide_ratio; uint8_t oscillator_frequency; } display_settings; bool prepared; bool enabled; [...] ssd130x->vbat = devm_regulator_get_optional(dev, "vbat"); if (IS_ERR(ssd130x->vbat)) { ret = PTR_ERR(ssd130x->vbat); if (ret != -ENODEV) { if (ret != -EPROBE_DEFER) dev_err(dev, "failed to request regulator: %d\n", ret); return ret; } ssd130x->vbat = NULL; } else { ssd130x->display_settings.use_charge_pump = true; } /* Get panel driving supply */ If (!ssd130x->vbat) { ssd130x->vcc = devm_regulator_get(dev, "vcc"); if (IS_ERR(ssd130x->vcc)){ ret = PTR_ERR(ssd130x->vcc); return ret; } else { ssd130x->display_settings.use_charge_pump = false; } } ``` Splitting in VCC/VBAT and VDD and enforcing their presence is of course compatibility breaking. https://github.com/dh-electronics/panel-solomon-ssd130x-draft/blob/drm-ssd1… https://github.com/dh-electronics/panel-solomon-ssd130x-draft/blob/drm-ssd1… # Static or Dynamic Configuration for SPI-Modes 3-Wire and 4-Wire For the SPI-protocol drivers I see two possible approaches: * Dynamic configuration by determining the presence/absence of the D/C-GPIO and assigning the functions accordingly. This way a single driver file for both SPI modes could be sufficient. * Static configuration by using the device-tree names (ssd130x-spi-3wire/-4wire) to differentiate between the SPI protocol drivers. This would obviously necessitate two drivers files. Which one do you think would be the best approach for this? # DRM Mode Configuration via Device Tree In the old fbdev driver, the display modes are hard-coded, which means for every new display configuration, a new patch needs to be mainlined, which slows down official Kernel support and puts burden on the maintainers. Additionally, with the DRM-subsystem supporting height and length information, for scaling, this opens up a lot of new combinations. The SSD1306 for example, is available in multiple resolutions like 128x64 and 96x16 and comes in different sizes per resolution as well. Just to name a few: * 128x64 0.96" (22x11mm) * 128x64 1.3" (30x15mm) * 96x16 0.69" (18x3mm) Instead of hard-coding, I would suggest something along the lines of of_get_drm_display_mode(). The displays won't need to support multiple modes at the same time, let alone support for switching between them, so the one-time invocation of this expensive function might be worth it. maybe a new and simpler function that could be named: of_get_drm_display_mode_simple() Providing a mode could later prove useful for a conversion to drm_panel, if that is feasible. But for a function like this, I have to chicken out. # DRM Panel The reason why I decided for the drm_panel approach in my code, was power management and a clean handling of the software backlight dependency, which requires powered display regulators to be powered. Prepare/unprepare would power on/off the display logic regulator VDD. Enable/disable would power on/off VCC/VBAT, optionally turn on/off the charge pump and send the DISPLAY_ON/OFF commands. The SSD1305's PWM part would likely be placed in enable/disable as well. What is Your opinion on using drm_panel for Your driver? Mit freundlichen Grüßen / Best regards Dominik Kierner Student Employee Research & Development DH electronics [View Less]

3 2

← Newer
1
2
3
4
5
6
7
...
96
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2022