dri-devel July 2021

dri-devel@lists.freedesktop.org

321 participants
829 discussions

[PATCH] drm/bridge: dw-mipi-dsi: Find the possible DSI devices
by Jagan Teki 19 Oct '21

19 Oct '21

Finding panel_or_bridge might vary based on associated DSI devices like DSI panel, bridge, and I2C based DSI bridge. 1. DSI panels and bridges will invoke the host attach from probe in order to find the panel_or_bridge. chipone_probe() dw_mipi_dsi_host_attach().start dw_mipi_dsi_panel_or_bridge() ...found the panel_or_bridge... ltdc_encoder_init().start dw_mipi_dsi_bridge_attach().start dw_mipi_dsi_host_attach().start chipone_attach(). start chipone_attach(). done dw_mipi_dsi_host_attach().done dw_mipi_dsi_bridge_attach(). done ltdc_encoder_init().done 2. I2C based DSI bridge will invoke the drm_bridge_attach from bridge attach in order to find the panel_or_bridge. ltdc_encoder_init().start dw_mipi_dsi_bridge_attach().start dw_mipi_dsi_panel_or_bridge() ...found the panel_or_bridge... dw_mipi_dsi_host_attach().start sn65dsi83_attach(). start sn65dsi83_attach(). done dw_mipi_dsi_host_attach().done dw_mipi_dsi_bridge_attach(). done ltdc_encoder_init().done So, invoke the panel_or_bridge from host attach and bridge attach in order to find all possible DSI devices. Signed-off-by: Jagan Teki <jagan(a)amarulasolutions.com> --- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 58 ++++++++++++++----- 1 file changed, 43 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index 6b268f9445b3..45f4515dda00 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c @@ -246,6 +246,7 @@ struct dw_mipi_dsi { struct clk *pclk; + bool device_found; unsigned int lane_mbps; /* per lane */ u32 channel; u32 lanes; @@ -309,13 +310,37 @@ static inline u32 dsi_read(struct dw_mipi_dsi *dsi, u32 reg) return readl(dsi->base + reg); } +static int dw_mipi_dsi_panel_or_bridge(struct dw_mipi_dsi *dsi, + struct device_node *node) +{ + struct drm_bridge *bridge; + struct drm_panel *panel; + int ret; + + ret = drm_of_find_panel_or_bridge(node, 1, 0, &panel, &bridge); + if (ret) + return ret; + + if (panel) { + bridge = drm_panel_bridge_add_typed(panel, + DRM_MODE_CONNECTOR_DSI); + if (IS_ERR(bridge)) + return PTR_ERR(bridge); + } + + dsi->panel_bridge = bridge; + + if (!dsi->panel_bridge) + return -EPROBE_DEFER; + + return 0; +} + static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host, struct mipi_dsi_device *device) { struct dw_mipi_dsi *dsi = host_to_dsi(host); const struct dw_mipi_dsi_plat_data *pdata = dsi->plat_data; - struct drm_bridge *bridge; - struct drm_panel *panel; int ret; if (device->lanes > dsi->plat_data->max_data_lanes) { @@ -329,22 +354,14 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host, dsi->format = device->format; dsi->mode_flags = device->mode_flags; - ret = drm_of_find_panel_or_bridge(host->dev->of_node, 1, 0, - &panel, &bridge); - if (ret) - return ret; + if (!dsi->device_found) { + ret = dw_mipi_dsi_panel_or_bridge(dsi, host->dev->of_node); + if (ret) + return ret; - if (panel) { - bridge = drm_panel_bridge_add_typed(panel, - DRM_MODE_CONNECTOR_DSI); - if (IS_ERR(bridge)) - return PTR_ERR(bridge); + dsi->device_found = true; } - dsi->panel_bridge = bridge; - - drm_bridge_add(&dsi->bridge); - if (pdata->host_ops && pdata->host_ops->attach) { ret = pdata->host_ops->attach(pdata->priv_data, device); if (ret < 0) @@ -999,6 +1016,16 @@ static int dw_mipi_dsi_bridge_attach(struct drm_bridge *bridge, /* Set the encoder type as caller does not know it */ bridge->encoder->encoder_type = DRM_MODE_ENCODER_DSI; + if (!dsi->device_found) { + int ret; + + ret = dw_mipi_dsi_panel_or_bridge(dsi, dsi->dev->of_node); + if (ret) + return ret; + + dsi->device_found = true; + } + /* Attach the panel-bridge to the dsi bridge */ return drm_bridge_attach(bridge->encoder, dsi->panel_bridge, bridge, flags); @@ -1181,6 +1208,7 @@ __dw_mipi_dsi_probe(struct platform_device *pdev, #ifdef CONFIG_OF dsi->bridge.of_node = pdev->dev.of_node; #endif + drm_bridge_add(&dsi->bridge); return dsi; } -- 2.25.1

6 7

[Bug 205649] New: Daisy Chain (MST) Session Crash after Screen Lock Resume
by bugzilla-daemon＠bugzilla.kernel.org 18 Oct '21

18 Oct '21

https://bugzilla.kernel.org/show_bug.cgi?id=205649 Bug ID: 205649 Summary: Daisy Chain (MST) Session Crash after Screen Lock Resume Product: Drivers Version: 2.5 Kernel Version: 5.4 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: michael(a)rauch.be Regression: No Error message: Nov 25 17:18:59 hoi kernel: [ 664.616065] [drm] DM_MST: stopping TM on aconnector: 00000000d2ec50d2 [id: 64] Nov 25 17:19:03 hoi kernel: [ 668.779501] [drm] DM_MST: Disabling connector: 0000000020957698 [id: 72] [master: 00000000d2ec50d2] Nov 25 17:19:03 hoi kernel: [ 668.780518] [drm] DM_MST: Disabling connector: 00000000a3e45904 [id: 67] [master: 00000000d2ec50d2] Nov 25 17:19:03 hoi kernel: [ 668.795264] [drm] DM_MST: starting TM on aconnector: 00000000d2ec50d2 [id: 64] Nov 25 17:19:03 hoi kernel: [ 668.868743] [drm] DM_MST: added connector: 00000000a5e1fa4b [id: 84] [master: 00000000d2ec50d2] Nov 25 17:19:03 hoi kernel: [ 669.018055] [drm] DM_MST: added connector: 00000000a62ddae1 [id: 102] [master: 00000000d2ec50d2] Nov 25 17:19:49 hoi kernel: [ 715.510276] [drm] DM_MST: stopping TM on aconnector: 00000000d2ec50d2 [id: 64] Nov 25 17:19:54 hoi kernel: [ 719.723556] [drm] DM_MST: Disabling connector: 00000000a62ddae1 [id: 102] [master: 00000000d2ec50d2] Nov 25 17:19:54 hoi kernel: [ 719.724562] [drm] DM_MST: Disabling connector: 00000000a5e1fa4b [id: 84] [master: 00000000d2ec50d2] Nov 25 17:19:54 hoi kernel: [ 719.738593] [drm] DM_MST: starting TM on aconnector: 00000000d2ec50d2 [id: 64] Nov 25 17:19:54 hoi kernel: [ 719.799040] [drm] DM_MST: added connector: 0000000084594915 [id: 82] [master: 00000000d2ec50d2] Nov 25 17:19:54 hoi kernel: [ 719.944380] [drm] DM_MST: added connector: 000000007a6df593 [id: 111] [master: 00000000d2ec50d2] Nov 25 17:27:56 hoi kernel: [ 1202.137752] [drm] DM_MST: stopping TM on aconnector: 00000000d2ec50d2 [id: 64] Nov 25 17:28:00 hoi kernel: [ 1206.380336] [drm] DM_MST: Disabling connector: 000000007a6df593 [id: 111] [master: 00000000d2ec50d2] Nov 25 17:28:00 hoi kernel: [ 1206.381399] [drm] DM_MST: Disabling connector: 0000000084594915 [id: 82] [master: 00000000d2ec50d2] Nov 25 17:28:00 hoi kernel: [ 1206.395858] [drm] DM_MST: starting TM on aconnector: 00000000d2ec50d2 [id: 64] Nov 25 17:28:00 hoi kernel: [ 1206.478238] [drm] DM_MST: added connector: 00000000e1e4c871 [id: 84] [master: 00000000d2ec50d2] Nov 25 17:28:01 hoi kernel: [ 1206.628767] [drm] DM_MST: added connector: 00000000a3c8d4bc [id: 109] [master: 00000000d2ec50d2] Setup: 2 monitors in Daisy Chain (MST) setup as separate displays How to reproduce the issue: 1. Enable Screen Lock for a Gnome Session 2. Wake up the session after the monitors go to sleep During the issue, the following occured: 1. Session crash for a running user session after wake up 2. User has to login to a new session System specification: Radeon PRO WX 2100 Ubuntu 18.04 I have tried the following combination: Kernel 5.3, 5.4 Mesa 19.0.8 Let me know if more logfiles are needed -- You are receiving this mail because: You are watching the assignee of the bug.

1 9

[PATCH 0/4] drm: Make modeset locking easier
by Ville Syrjala 14 Oct '21

14 Oct '21

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> While staring at some DRM_MODESET_LOCK_ALL_{BEGIN,END}() conversions I decided I don't really like what those macros do. The main problems that I see: - the magic goto inside limits their usefulness to baically a single statement, unless you're willing to look inside and find out the name of the magic label - can't help at all in the "we don't want to lock everything" cases, which are quite numerous - not at all obvious that there's a loop in there So I figured I'd try to come up with something more universally useful. Cc: Sean Paul <seanpaul(a)chromium.org> Cc: Daniel Vetter <daniel(a)ffwll.ch> Ville Syrjälä (4): drm: Introduce drm_modeset_lock_ctx_retry() drm: Introduce drm_modeset_lock_all_ctx_retry() drm/i915: Extract intel_crtc_initial_commit() drm/i915: Use drm_modeset_lock_ctx_retry() & co. drivers/gpu/drm/drm_modeset_lock.c | 44 ++++ drivers/gpu/drm/i915/display/g4x_dp.c | 17 +- drivers/gpu/drm/i915/display/intel_audio.c | 17 +- drivers/gpu/drm/i915/display/intel_ddi.c | 16 +- drivers/gpu/drm/i915/display/intel_display.c | 192 ++++++++---------- .../drm/i915/display/intel_display_debugfs.c | 45 ++-- drivers/gpu/drm/i915/display/intel_pipe_crc.c | 38 ++-- include/drm/drm_modeset_lock.h | 26 +++ 8 files changed, 188 insertions(+), 207 deletions(-) -- 2.31.1

4 10

[PATCH v8 0/4] drm: LogiCVC display controller support
by Paul Kocialkowski 13 Oct '21

13 Oct '21

This series introduces support for the LogiCVC display controller. The controller is a bit unusual since it is usually loaded as programmable logic on Xilinx FPGAs or Zynq-7000 SoCs. More details are presented on the main commit for the driver. More information about the controller is available on the dedicated web page: https://www.logicbricks.com/Products/logiCVC-ML.aspx Note that this driver has rather simple connector management, which was not converted to drm_panel_bridge to keep the ability to enable the panel at first vblank but also to support DVI. Change since v7: - Replaced DRM_INFO/DRM_ERROR/DRM_DEBUG_DRIVER with fashions using drm_device; - Fixed yaml binding alignment issue; - Renamed logicvc-display name to the generic "display" name; - Added patternProperties match for display in the parent mfd binding; - Used drm_atomic_get_new_crtc_state when needed; - Checked mode in mode_valid instead of atomic_check; - Switched to drmm_mode_config_init; - Removed useless logicvc_connector_destroy wrapper; - Removed useless drm_dev_put calls; - Removed atomic_commit_tail that enables the panel and streamlined the logic; - Reworked Makefile cosmetics; - Fixed checkpatch issues. Changes since v6: - Updated to the latest DRM internal API changes; - Used an enum to index dt properties instead of the name string. Changes since v5: - Subclass DRM device and use devm_drm_dev_alloc for allocation; - Removed call to drm_mode_config_cleanup (done automatically with devm); - Some related code cleanups; - Bring back not-for-merge patch adding colorkey support. Changes since v4: - Updated to internal DRM API changes (rebased on drm-misc-next); - Added Kconfig dependency on OF; - Added MAINTAINERS entry; - Used drm_err and dev_err instead of DRM_ERROR where possible; - Various cosmetic changes. Changes since v3: - Rebased on latest drm-misc; - Improved event lock wrapping; - Added collect tag; - Added color-key support patch (not for merge, for reference only). Changes since v2: - Fixed and slightly improved dt schema. Changes since v1: - Switched dt bindings documentation to dt schema; - Described more possible dt parameters; - Added support for the lvds-3bit interface; - Added support for grabbing syscon regmap from parent node; - Removed layers count property and count layers child nodes instead. Paul Kocialkowski (4): dt-bindings: display: Document the Xylon LogiCVC display controller dt-bindings: mfd: logicvc: Add patternProperties for the display drm: Add support for the LogiCVC display controller NOTFORMERGE: drm/logicvc: Add plane colorkey support .../display/xylon,logicvc-display.yaml | 313 +++++++ .../bindings/mfd/xylon,logicvc.yaml | 3 + MAINTAINERS | 6 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/logicvc/Kconfig | 9 + drivers/gpu/drm/logicvc/Makefile | 9 + drivers/gpu/drm/logicvc/logicvc_crtc.c | 280 +++++++ drivers/gpu/drm/logicvc/logicvc_crtc.h | 21 + drivers/gpu/drm/logicvc/logicvc_drm.c | 474 +++++++++++ drivers/gpu/drm/logicvc/logicvc_drm.h | 67 ++ drivers/gpu/drm/logicvc/logicvc_interface.c | 214 +++++ drivers/gpu/drm/logicvc/logicvc_interface.h | 28 + drivers/gpu/drm/logicvc/logicvc_layer.c | 762 ++++++++++++++++++ drivers/gpu/drm/logicvc/logicvc_layer.h | 71 ++ drivers/gpu/drm/logicvc/logicvc_mode.c | 80 ++ drivers/gpu/drm/logicvc/logicvc_mode.h | 15 + drivers/gpu/drm/logicvc/logicvc_of.c | 185 +++++ drivers/gpu/drm/logicvc/logicvc_of.h | 46 ++ drivers/gpu/drm/logicvc/logicvc_regs.h | 88 ++ 20 files changed, 2674 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml create mode 100644 drivers/gpu/drm/logicvc/Kconfig create mode 100644 drivers/gpu/drm/logicvc/Makefile create mode 100644 drivers/gpu/drm/logicvc/logicvc_crtc.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_crtc.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_drm.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_drm.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_interface.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_interface.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_layer.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_layer.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_mode.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_mode.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_of.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_of.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_regs.h -- 2.29.2

5 12

Questions over DSI within DRM.
by Dave Stevenson 12 Oct '21

12 Oct '21

Hi All I'm trying to get DSI devices working reliably on the Raspberry Pi, but I'm hitting a number of places where it isn't clear as to the expected behaviour within DRM. Power on state. Many devices want the DSI clock and/or data lanes in LP-11 state when they are powered up. With the normal calling sequence of: - panel/bridge pre_enable calls from connector towards the encoder. - encoder enable which also enables video. - panel/bridge enable calls from encoder to connector. there is no point at which the DSI tx is initialised but not transmitting video. What DSI states are expected to be adopted at each point? On a similar theme, some devices want the clock lane in HS mode early so they can use it in place of an external oscillator, but the data lanes still in LP-11. There appears to be no way for the display/bridge to signal this requirement or it be achieved. host_transfer calls can supposedly be made at any time, however unless MIPI_DSI_MSG_USE_LPM is set in the message then we're meant to send it in high speed mode. If this is before a mode has been set, what defines the link frequency parameters at this point? Adopting a random default sounds like a good way to get undefined behaviour. DSI burst mode needs to set the DSI link frequency independently of the display mode. How is that meant to be configured? I would have expected it to come from DT due to link frequency often being chosen based on EMC restrictions, but I don't see such a thing in any binding. As a follow on, bridge devices can support burst mode (eg TI's SN65DSI83 that's just been merged), so it needs to know the desired panel timings for the output side of the bridge, but the DSI link timings to set up the bridge's PLL. What's the correct way for signalling that? drm_crtc_state->adjusted_mode vs drm_crtc_state->mode? Except mode is userspace's request, not what has been validated/updated by the panel/bridge. vc4 has constraints that the DSI host interface is fed off an integer divider from a typically 3GHz clock, so the host interface needs to signal that burst mode is in use even if the panel/bridge doesn't need to run in burst mode. (This does mean that displays that require a very precise link frequency can not be supported). It currently updates the adjusted_mode via drm_encoder_helper_funcs mode_fixup, but is that the correct thing to do, or is there a better solution? I'd have expected the DSI tx to be responsible for configuring burst mode parameters anyway, so the mechanism required would seem to be just the normal approach for adopting burst mode if that is defined. Some DSI host interfaces are implemented as bridges, others are encoders. Pro's and con's of each? I suspect I'm just missing the history here. When it comes to the MIPI_DSI_MODE_* flags, which ones are mutually exclusive, or are assumed based on others? Does a burst mode DSI sink set both MIPI_DSI_MODE_VIDEO and MIPI_DSI_MODE_VIDEO_BURST, or just the latter? Presumably !MIPI_DSI_MODE_VIDEO signals the of use command mode for conveying video. So looking at panel-ilitek-ili9881c where it sets just MIPI_DSI_MODE_VIDEO_SYNC_PULSE means command mode video with sync pulses? That sounds unlikely. I have looked for any information that covers this, but failed to find such, hence calling on all your expertise. Many thanks for your time, Dave

6 18

[PATCH 0/3] drm/nouveau: fix a use-after-free in postclose()
by Jeremy Cline 11 Oct '21

11 Oct '21

This series fixes a number of use-after-frees in nouveau's postclose() handler. It was discovered by pointing IGT's core_hotunplug tests at a nouveau device, but the steps to reproduce it are simple: 1. Open the device file 2. Unbind the driver or remove the device 3. Close the file opened in step 1. During the device removal, the nouveau_drm structure is de-allocated, but is dereferenced in the postclose() handler. One obvious solution is to ensure all the operations in the postclose() handler are valid by extending the lifetime of the nouveau_drm structure. This is possible with the new devm_drm_dev_alloc() interface, but the change is somewhat invasive so I thought it best to submit that work separately. Instead, we make use of the drm_dev_unplug() API, clean up all clients in the device removal call, and check to make sure the device has not been unplugged in the postclose() handler. While this does not enable hot-unplug support for nouveau, it's enough to avoid crashing the kernel and leads to all the core_hotunplug tests to pass. Jeremy Cline (3): drm/nouveau: use drm_dev_unplug() during device removal drm/nouveau: Add a dedicated mutex for the clients list drm/nouveau: clean up all clients on device removal drivers/gpu/drm/nouveau/nouveau_drm.c | 39 +++++++++++++++++++++++---- drivers/gpu/drm/nouveau/nouveau_drv.h | 5 ++++ 2 files changed, 39 insertions(+), 5 deletions(-) -- 2.28.0

4 15

[PATCH 00/11] drm/msm: Add Display Stream Compression Support
by Vinod Koul 06 Oct '21

06 Oct '21

Display Stream Compression (DSC) compresses the display stream in host which is later decoded by panel. This series enables this for Qualcomm msm driver. This was tested on Google Pixel3 phone which use LGE SW43408 panel. The changes include adding DT properties for DSC then hardware blocks support required in DPU1 driver and support in encoder. We also add support in DSI and introduce required topology changes. In order for panel to set the DSC parameters we add dsc in drm_panel and set it from the msm driver. Complete changes which enable this for Pixel3 along with panel driver (not part of this series) and DT changes can be found at: git.linaro.org/people/vinod.koul/kernel.git pixel/dsc_v1 Comments welcome! Changes since RFC: - Drop the DT binding patch as we derive the configuration from panel - Drop the drm api patch as we no longer need it (use pps drm api) - Fix comments raised by Dimitry - Add dsc parameters calculation from downstream Vinod Koul (11): drm/msm/dsi: add support for dsc data drm/msm/disp/dpu1: Add support for DSC drm/msm/disp/dpu1: Add support for DSC in pingpong block drm/msm/disp/dpu1: Add DSC support in RM drm/msm/disp/dpu1: Add DSC for SDM845 to hw_catalog drm/msm/disp/dpu1: Add DSC support in hw_ctl drm/msm/disp/dpu1: Don't use DSC with mode_3d drm/msm/disp/dpu1: Add support for DSC in encoder drm/msm/disp/dpu1: Add support for DSC in topology drm/msm/dsi: Add support for DSC configuration drm/msm/dsi: Pass DSC params to drm_panel drivers/gpu/drm/msm/Makefile | 1 + drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 158 +++++++++- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 11 + .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 2 + .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 22 ++ .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 13 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 12 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 2 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 221 ++++++++++++++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h | 77 +++++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 13 + .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 32 ++ .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 14 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 + drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 32 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 1 + drivers/gpu/drm/msm/dsi/dsi.xml.h | 10 + drivers/gpu/drm/msm/dsi/dsi_host.c | 289 +++++++++++++++++- drivers/gpu/drm/msm/msm_drv.h | 21 ++ include/drm/drm_panel.h | 7 + 20 files changed, 925 insertions(+), 14 deletions(-) create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h -- 2.31.1

4 40

[PATCH] drm/bridge/lontium-lt9611uxc: fix provided connector suport
by Dmitry Baryshkov 06 Oct '21

06 Oct '21

- set DRM_CONNECTOR_POLL_HPD as the connector will generate hotplug events on its own - do not call drm_kms_helper_hotplug_event() unless mode_config.funcs pointer is not NULL to remove possible kernel oops. Fixes: bc6fa8676ebb ("drm/bridge/lontium-lt9611uxc: move HPD notification out of IRQ handler") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> --- drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c index 3cac16db970f..010657ea7af7 100644 --- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c +++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c @@ -167,9 +167,10 @@ static void lt9611uxc_hpd_work(struct work_struct *work) struct lt9611uxc *lt9611uxc = container_of(work, struct lt9611uxc, work); bool connected; - if (lt9611uxc->connector.dev) - drm_kms_helper_hotplug_event(lt9611uxc->connector.dev); - else { + if (lt9611uxc->connector.dev) { + if (lt9611uxc->connector.dev->mode_config.funcs) + drm_kms_helper_hotplug_event(lt9611uxc->connector.dev); + } else { mutex_lock(&lt9611uxc->ocm_lock); connected = lt9611uxc->hdmi_connected; @@ -339,6 +340,8 @@ static int lt9611uxc_connector_init(struct drm_bridge *bridge, struct lt9611uxc return -ENODEV; } + lt9611uxc->connector.polled = DRM_CONNECTOR_POLL_HPD; + drm_connector_helper_add(&lt9611uxc->connector, &lt9611uxc_bridge_connector_helper_funcs); ret = drm_connector_init(bridge->dev, &lt9611uxc->connector, -- 2.30.2

2 2

[PATCH 0/9] Add 4 Jenson simple panels
by Giulio Benetti 05 Oct '21

05 Oct '21

This patchset introduce Jenson vendor and add 4 of its panels to panel-simple driver. Giulio Benetti (9): dt-bindings: Add Jenson Display vendor prefix dt-bindings: display/panel: add Jenson JT60248-01 dt-bindings: display/panel: add Jenson JT60249-01 dt-bindings: display/panel: add Jenson JT60245-01 dt-bindings: display/panel: add Jenson JT60250-02 drm/panel: simple: add Jenson JT60245-01 drm/panel: simple: add Jenson JT60248-01 drm/panel: simple: add Jenson JT60249-01 drm/panel: simple: add Jenson JT60250-02 .../bindings/display/panel/panel-simple.yaml | 8 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + drivers/gpu/drm/panel/panel-simple.c | 108 ++++++++++++++++++ 3 files changed, 118 insertions(+) -- 2.25.1

3 37

[PATCH] drm: fsl-dcu: enable PIXCLK on LS1021A
by Matthias Schiffer 05 Oct '21

05 Oct '21

The PIXCLK needs to be enabled in SCFG before accessing the DCU on LS1021A, or the access will hang. Signed-off-by: Matthias Schiffer <matthias.schiffer(a)ew.tq-group.com> --- drivers/gpu/drm/fsl-dcu/Kconfig | 1 + drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 25 +++++++++++++++++++++++ drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 3 +++ 3 files changed, 29 insertions(+) diff --git a/drivers/gpu/drm/fsl-dcu/Kconfig b/drivers/gpu/drm/fsl-dcu/Kconfig index d7dd8ba90e3a..9e5a35e7c00c 100644 --- a/drivers/gpu/drm/fsl-dcu/Kconfig +++ b/drivers/gpu/drm/fsl-dcu/Kconfig @@ -8,6 +8,7 @@ config DRM_FSL_DCU select DRM_PANEL select REGMAP_MMIO select VIDEOMODE_HELPERS + select MFD_SYSCON if SOC_LS1021A help Choose this option if you have an Freescale DCU chipset. If M is selected the module will be called fsl-dcu-drm. diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c index abbc1ddbf27f..8a7556655581 100644 --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c @@ -51,6 +51,23 @@ static const struct regmap_config fsl_dcu_regmap_config = { .volatile_reg = fsl_dcu_drm_is_volatile_reg, }; +static int fsl_dcu_scfg_config_ls1021a(struct device_node *np) +{ + struct regmap *scfg; + + scfg = syscon_regmap_lookup_by_compatible("fsl,ls1021a-scfg"); + if (IS_ERR(scfg)) + return PTR_ERR(scfg); + + /* + * For simplicity, enable the PIXCLK unconditionally. It might + * be possible to disable the clock in PM or on unload as a future + * improvement. + */ + return regmap_update_bits(scfg, SCFG_PIXCLKCR, SCFG_PIXCLKCR_PXCEN, + SCFG_PIXCLKCR_PXCEN); +} + static void fsl_dcu_irq_uninstall(struct drm_device *dev) { struct fsl_dcu_drm_device *fsl_dev = dev->dev_private; @@ -70,6 +87,14 @@ static int fsl_dcu_load(struct drm_device *dev, unsigned long flags) return ret; } + if (of_device_is_compatible(fsl_dev->np, "fsl,ls1021a-dcu")) { + ret = fsl_dcu_scfg_config_ls1021a(fsl_dev->np); + if (ret < 0) { + dev_err(dev->dev, "failed to enable pixclk\n"); + goto done; + } + } + ret = drm_vblank_init(dev, dev->mode_config.num_crtc); if (ret < 0) { dev_err(dev->dev, "failed to initialize vblank\n"); diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h index e2049a0e8a92..566396013c04 100644 --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h @@ -160,6 +160,9 @@ #define FSL_DCU_ARGB4444 12 #define FSL_DCU_YUV422 14 +#define SCFG_PIXCLKCR 0x28 +#define SCFG_PIXCLKCR_PXCEN BIT(31) + #define VF610_LAYER_REG_NUM 9 #define LS1021A_LAYER_REG_NUM 10 -- 2.17.1

2 5

← Newer
1
...
5
6
7
8
9
10
11
...
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2021