Message ID | 20230713090152.140060-1-angelogioacchino.delregno@collabora.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:a6b2:0:b0:3e4:2afc:c1 with SMTP id c18csp1701731vqm; Thu, 13 Jul 2023 02:35:35 -0700 (PDT) X-Google-Smtp-Source: APBJJlH/ZWEwpZHNFsVw4dlh13eY+PUgxS0n5eLtYEF+zjWZf9GxAKw09V4KiPzyoToL5dBfE94B X-Received: by 2002:a05:6a00:228d:b0:677:c5bf:dcc7 with SMTP id f13-20020a056a00228d00b00677c5bfdcc7mr1279439pfe.17.1689240935608; Thu, 13 Jul 2023 02:35:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689240935; cv=none; d=google.com; s=arc-20160816; b=O17ao9ID3Px9nReZT7yk7VaotqrN7PAVwKzTD6eC7OSkcQ5rkIXi8xB0SCc051WIRT uyiSjo3TCT2a7wPsa5cakVheccMq+m4LGEbGZu/+HQNBDSyGuRUV28lrIm99lK157fWz 2X+D0vbawui4SwBTd/NoxAMcfUsmrmqiWGdzRW1nP+IOtRnOnIJxHJB7zcggILWkBjk5 Yzu7PKHo020KWJMeLZRCUa2ws19lRbqhv6UomvMGl1uJmpoCFAvhRrQhJjvK12n1Iu+p Mjhc0pNM7LHA/KHM8LXWlr2jvisej5WJ4dgYrQBRNP+amsRLELOw4G1JszPqj8w17443 MzTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=Jm+4bA7L5qQARGCuBviR0yCve9XmJx/kjr6/J1RXj6c=; fh=JpmmvsKbFEtjFcPhKwAU/TS0J6xmkcPCzvp06hVht3s=; b=o4KeabZSDGKR5RDnMEEDwaM98dgSPua9kehWUX63/EdaQ4C/8wDqlRXm1vS7ahbj5r jBcCS5TjXt9kbUrkxdFoCfwK34Rat5w4JvU2Smlu6QNIfvD1j79AKHdayTA2gTxOY6KK A4pBta9btt18UWE0/6/ceLmCfGGeL+Hy6coN6cl2YwKyhHXeK9Yp1bAAUOZA5lPtqVms +qHMPkm0l2Q9p8yg98FRXk76skcGD3Sbtr/gMPCz9QiRRL9vUY+k82vFas1sZzu+2zKT HC8WP9uShRONLpVKNG6UTO/Ilv5LmcBKJq82LqFip/PgE5lUzi5nCfDfq4EN1pa7d6Js +8Gw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=W1CQgZsa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bd20-20020a056a00279400b0064d3e1db254si4733604pfb.347.2023.07.13.02.35.23; Thu, 13 Jul 2023 02:35:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=W1CQgZsa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233364AbjGMJDD (ORCPT <rfc822;ybw1215001957@gmail.com> + 99 others); Thu, 13 Jul 2023 05:03:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58430 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234153AbjGMJCc (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 13 Jul 2023 05:02:32 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B67372D67 for <linux-kernel@vger.kernel.org>; Thu, 13 Jul 2023 02:01:59 -0700 (PDT) Received: from IcarusMOD.eternityproject.eu (2-237-20-237.ip236.fastwebnet.it [2.237.20.237]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kholk11) by madras.collabora.co.uk (Postfix) with ESMTPSA id AE9EF6607044; Thu, 13 Jul 2023 10:01:57 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1689238918; bh=WhbAVEXdX9GjpwripqW58AET2QNGyCRlQO6iZTf/vYg=; h=From:To:Cc:Subject:Date:From; b=W1CQgZsa8/plt03OKILwzeBjXUJyqQZiC0tVJFNz30jh9WM6erb9MArAxdFS9uSPC tSqi2VBODVNMqrIGPxEJ7JmXEaliUw2ILJgepHaGJ+fRQR5RViv6dUHUJnP2YYy9yo Vy3wHEWZas9hLYpDsc23e++0h0jQW37ZTKT0xuUU/NO/w3ysc+GwYLoS0330dNJwHw k4S3jA5KLZSZkCeNSRoPl3FVCAV/fe5/7+YSHx2t9btwg9ePvWEsfhDisqUhdHXwUv 9zNVFljiMnG/kqmNHDr5PSO0lm8SOHcLEpHbDP/bGcpTYT8XA7TPuAcy56swlFVeLa BtA2g66LTbX2A== From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> To: chunkuang.hu@kernel.org Cc: p.zabel@pengutronix.de, airlied@gmail.com, daniel@ffwll.ch, matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com, dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kernel@collabora.com, wenst@chromium.org, nfraprado@collabora.com Subject: [PATCH v5 00/10] MediaTek DisplayPort: support eDP and aux-bus Date: Thu, 13 Jul 2023 11:01:42 +0200 Message-Id: <20230713090152.140060-1-angelogioacchino.delregno@collabora.com> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1771297503431005852 X-GMAIL-MSGID: 1771297503431005852 |
Series |
MediaTek DisplayPort: support eDP and aux-bus
|
|
Message
AngeloGioacchino Del Regno
July 13, 2023, 9:01 a.m. UTC
Changes in v5: - Added .wait_hpd_asserted() callback for aux-bus - Avoid enabling and registering HPD interrupt + handlers for eDP case only (keeps HPD interrupts enabled for full DP case) - Support not always-on eDP panels (boot with regulator off, suspend with regulator off) for power saving in PM suspend. Changes in v4: - Set data lanes to idle to prevent stalls if bootloader didn't properly close the eDP port - Now using the .done_probing() callback for AUX bus to prevent probe deferral loops in case the panel-edp driver is a module as previously seen with another bridge driver (ANX7625) on some other SoCs (MT8192 and others) - Rebased over next-20230706 - Dropped Chen-Yu's T-b tag on last patch as some logic changed (before, I wasn't using the .done_probing() callback). Changes in v3: - Added DPTX AUX block initialization before trying to communicate to stop relying on the bootloader keeping it initialized before booting Linux. - Fixed commit description for patch [09/09] and removed commented out code (that slipped from dev phase.. sorry!). This series adds "real" support for eDP in the mtk-dp DisplayPort driver. Explaining the "real": Before this change, the DisplayPort driver did support eDP to some extent, but it was treating it entirely like a regular DP interface which is partially fine, after all, embedded DisplayPort *is* actually DisplayPort, but there might be some differences to account for... and this is for both small performance improvements and, more importantly, for correct functionality in some systems. Functionality first: One of the common differences found in various boards implementing eDP and machines using an eDP panel is that many times the HPD line is not connected. This *must* be accounted for: at startup, this specific IP will raise a HPD interrupt (which should maybe be ignored... as it does not appear to be a "real" event...) that will make the eDP panel to be detected and to actually work but, after a suspend-resume cycle, there will be no HPD interrupt (as there's no HPD line in my case!) producing a functionality issue - specifically, the DP Link Training fails because the panel doesn't get powered up, then it stays black and won't work until rebooting the machine (or removing and reinserting the module I think, but I haven't tried that). Now for.. both: eDP panels are *e*DP because they are *not* removable (in the sense that you can't unplug the cable without disassembling the machine, in which case, the machine shall be powered down..!): this (correct) assumption makes us able to solve some issues and to also gain a little performance during PM operations. What was done here is: - Caching the EDID if the panel is eDP: we're always going to read the same data everytime, so we can just cache that (as it's small enough) shortening PM resume times for the eDP driver instance; - Always return connector_status_connected if it's eDP: non-removable means connector_status_disconnected can't happen during runtime... this also saves us some time and even power, as we won't have to perform yet another power cycle of the HW; - Added aux-bus support! This makes us able to rely on panel autodetection from the EDID, avoiding to add more and more panel timings to panel-edp and, even better, allowing to use one panel node in devicetrees for multiple variants of the same machine since, at that point, it's not important to "preventively know" what panel we have (eh, it's autodetected...!). This was tested on a MT8195 Cherry Tomato Chromebook (panel-edp on aux-bus) P.S.: For your own testing commodity, here's a reference devicetree: pp3300_disp_x: regulator-pp3300-disp-x { compatible = "regulator-fixed"; regulator-name = "pp3300_disp_x"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; enable-active-high; gpio = <&pio 55 GPIO_ACTIVE_HIGH>; pinctrl-names = "default"; pinctrl-0 = <&panel_fixed_pins>; }; &edp_tx { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&edptx_pins_default>; ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; edp_in: endpoint { remote-endpoint = <&dp_intf0_out>; }; }; port@1 { reg = <1>; edp_out: endpoint { data-lanes = <0 1 2 3>; remote-endpoint = <&panel_in>; }; }; }; aux-bus { panel: panel { compatible = "edp-panel"; power-supply = <&pp3300_disp_x>; backlight = <&backlight_lcd0>; port { panel_in: endpoint { remote-endpoint = <&edp_out>; }; }; }; }; }; AngeloGioacchino Del Regno (10): drm/mediatek: dp: Move AUX and panel poweron/off sequence to function drm/mediatek: dp: Change logging to dev for mtk_dp_aux_transfer() drm/mediatek: dp: Use devm variant of drm_bridge_add() drm/mediatek: dp: Move AUX_P0 setting to mtk_dp_initialize_aux_settings() drm/mediatek: dp: Enable event interrupt only when bridge attached drm/mediatek: dp: Avoid mutex locks if audio is not supported/enabled drm/mediatek: dp: Move PHY registration to new function drm/mediatek: dp: Add support for embedded DisplayPort aux-bus drm/mediatek: dp: Add .wait_hpd_asserted() for AUX bus drm/mediatek: dp: Don't register HPD interrupt handler for eDP case drivers/gpu/drm/mediatek/Kconfig | 1 + drivers/gpu/drm/mediatek/mtk_dp.c | 335 ++++++++++++++++++++---------- 2 files changed, 224 insertions(+), 112 deletions(-)
Comments
On Thu, Jul 13, 2023 at 5:01 PM AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> wrote: > > Changes in v5: > - Added .wait_hpd_asserted() callback for aux-bus > - Avoid enabling and registering HPD interrupt + handlers for > eDP case only (keeps HPD interrupts enabled for full DP case) > - Support not always-on eDP panels (boot with regulator off, > suspend with regulator off) for power saving in PM suspend. This still doesn't work when the DRM driver is builtin, and the panel driver is a module. This is still with regulator-always-on. From what I can tell from the kernel logs, the DRM driver is not waiting for eDP panel to probe (which sort of makes sense?), and simply uses the default EDID. When the panel does probe, nothing triggers the DRM driver to update its connector. [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:32:eDP-1] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:32:eDP-1] status updated from unknown to connected [drm:drm_mode_debug_printmodeline] Modeline "640x480": 60 25175 640 656 752 800 480 490 492 525 0x40 0xa [drm:drm_mode_prune_invalid] Not using 640x480 mode: CLOCK_HIGH [drm:drm_mode_debug_printmodeline] Modeline "800x600": 56 36000 800 824 896 1024 600 601 603 625 0x40 0x5 [drm:drm_mode_prune_invalid] Not using 800x600 mode: CLOCK_HIGH [drm:drm_mode_debug_printmodeline] Modeline "800x600": 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5 [drm:drm_mode_prune_invalid] Not using 800x600 mode: CLOCK_HIGH [drm:drm_mode_debug_printmodeline] Modeline "848x480": 60 33750 848 864 976 1088 480 486 494 517 0x40 0x5 [drm:drm_mode_prune_invalid] Not using 848x480 mode: CLOCK_HIGH [drm:drm_mode_debug_printmodeline] Modeline "1024x768": 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa [drm:drm_mode_prune_invalid] Not using 1024x768 mode: CLOCK_HIGH [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:34:DP-1] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:34:DP-1] status updated from unknown to disconnected [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:34:DP-1] disconnected [drm:drm_client_modeset_probe] No connectors reported connected with modes [drm:drm_client_modeset_probe] connector 32 enabled? yes [drm:drm_client_modeset_probe] connector 34 enabled? no [drm:drm_client_firmware_config.constprop.0.isra.0] Not using firmware configuration [drm:drm_client_modeset_probe] looking for cmdline mode on connector 32 [drm:drm_client_modeset_probe] looking for preferred mode on connector 32 0 [drm:drm_client_modeset_probe] found mode none [drm:drm_client_modeset_probe] picking CRTCs for 4096x4096 config mediatek-drm mediatek-drm.12.auto: [drm:__drm_fb_helper_initial_config_and_unlock] test CRTC 0 primary plane mediatek-drm mediatek-drm.12.auto: [drm] Cannot find any crtc or sizes mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_dpcd_probe] aux_mtk_dp: 0x00000 AUX -> (ret= 1) 14 mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_dpcd_read] aux_mtk_dp: 0x00000 AUX -> (ret= 15) 14 0a 84 41 00 00 01 80 02 00 00 00 0f 09 80 mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_dpcd_probe] aux_mtk_dp: 0x00000 AUX -> (ret= 1) 14 mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_dpcd_read] aux_mtk_dp: 0x02200 AUX -> (ret= 15) 14 0a 84 41 00 00 01 80 02 00 00 00 0f 01 80 mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_read_dpcd_caps] aux_mtk_dp: Base DPCD: 14 0a 84 41 00 00 01 80 02 00 00 00 0f 09 80 mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_read_dpcd_caps] aux_mtk_dp: DPCD: 14 0a 84 41 00 00 01 80 02 00 00 00 0f 01 80 mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_dpcd_probe] aux_mtk_dp: 0x00000 AUX -> (ret= 1) 14 mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_dpcd_read] aux_mtk_dp: 0x00021 AUX -> (ret= 1) 00 panel-simple-dp-aux aux-1c500000.edp-tx: Detected BOE NE135FBM-N41 v8.1 (0x095f) If the panel is also built-in, then the eDP panel probe happens between the drm driver adding components and binding to them, and everything seems to work OK. ChenYu > Changes in v4: > - Set data lanes to idle to prevent stalls if bootloader didn't > properly close the eDP port > - Now using the .done_probing() callback for AUX bus to prevent > probe deferral loops in case the panel-edp driver is a module > as previously seen with another bridge driver (ANX7625) on > some other SoCs (MT8192 and others) > - Rebased over next-20230706 > - Dropped Chen-Yu's T-b tag on last patch as some logic changed > (before, I wasn't using the .done_probing() callback). > > Changes in v3: > - Added DPTX AUX block initialization before trying to communicate > to stop relying on the bootloader keeping it initialized before > booting Linux. > - Fixed commit description for patch [09/09] and removed commented > out code (that slipped from dev phase.. sorry!). > > This series adds "real" support for eDP in the mtk-dp DisplayPort driver. > > Explaining the "real": > Before this change, the DisplayPort driver did support eDP to some > extent, but it was treating it entirely like a regular DP interface > which is partially fine, after all, embedded DisplayPort *is* actually > DisplayPort, but there might be some differences to account for... and > this is for both small performance improvements and, more importantly, > for correct functionality in some systems. > > Functionality first: > > One of the common differences found in various boards implementing eDP > and machines using an eDP panel is that many times the HPD line is not > connected. This *must* be accounted for: at startup, this specific IP > will raise a HPD interrupt (which should maybe be ignored... as it does > not appear to be a "real" event...) that will make the eDP panel to be > detected and to actually work but, after a suspend-resume cycle, there > will be no HPD interrupt (as there's no HPD line in my case!) producing > a functionality issue - specifically, the DP Link Training fails because > the panel doesn't get powered up, then it stays black and won't work > until rebooting the machine (or removing and reinserting the module I > think, but I haven't tried that). > > Now for.. both: > eDP panels are *e*DP because they are *not* removable (in the sense that > you can't unplug the cable without disassembling the machine, in which > case, the machine shall be powered down..!): this (correct) assumption > makes us able to solve some issues and to also gain a little performance > during PM operations. > > What was done here is: > - Caching the EDID if the panel is eDP: we're always going to read the > same data everytime, so we can just cache that (as it's small enough) > shortening PM resume times for the eDP driver instance; > - Always return connector_status_connected if it's eDP: non-removable > means connector_status_disconnected can't happen during runtime... > this also saves us some time and even power, as we won't have to > perform yet another power cycle of the HW; > - Added aux-bus support! > This makes us able to rely on panel autodetection from the EDID, > avoiding to add more and more panel timings to panel-edp and, even > better, allowing to use one panel node in devicetrees for multiple > variants of the same machine since, at that point, it's not important > to "preventively know" what panel we have (eh, it's autodetected...!). > > This was tested on a MT8195 Cherry Tomato Chromebook (panel-edp on aux-bus) > > > P.S.: For your own testing commodity, here's a reference devicetree: > > pp3300_disp_x: regulator-pp3300-disp-x { > compatible = "regulator-fixed"; > regulator-name = "pp3300_disp_x"; > regulator-min-microvolt = <3300000>; > regulator-max-microvolt = <3300000>; > enable-active-high; > gpio = <&pio 55 GPIO_ACTIVE_HIGH>; > pinctrl-names = "default"; > pinctrl-0 = <&panel_fixed_pins>; > }; > > &edp_tx { > status = "okay"; > > pinctrl-names = "default"; > pinctrl-0 = <&edptx_pins_default>; > > ports { > #address-cells = <1>; > #size-cells = <0>; > > port@0 { > reg = <0>; > edp_in: endpoint { > remote-endpoint = <&dp_intf0_out>; > }; > }; > > port@1 { > reg = <1>; > edp_out: endpoint { > data-lanes = <0 1 2 3>; > remote-endpoint = <&panel_in>; > }; > }; > }; > > aux-bus { > panel: panel { > compatible = "edp-panel"; > power-supply = <&pp3300_disp_x>; > backlight = <&backlight_lcd0>; > port { > panel_in: endpoint { > remote-endpoint = <&edp_out>; > }; > }; > }; > }; > }; > > AngeloGioacchino Del Regno (10): > drm/mediatek: dp: Move AUX and panel poweron/off sequence to function > drm/mediatek: dp: Change logging to dev for mtk_dp_aux_transfer() > drm/mediatek: dp: Use devm variant of drm_bridge_add() > drm/mediatek: dp: Move AUX_P0 setting to > mtk_dp_initialize_aux_settings() > drm/mediatek: dp: Enable event interrupt only when bridge attached > drm/mediatek: dp: Avoid mutex locks if audio is not supported/enabled > drm/mediatek: dp: Move PHY registration to new function > drm/mediatek: dp: Add support for embedded DisplayPort aux-bus > drm/mediatek: dp: Add .wait_hpd_asserted() for AUX bus > drm/mediatek: dp: Don't register HPD interrupt handler for eDP case > > drivers/gpu/drm/mediatek/Kconfig | 1 + > drivers/gpu/drm/mediatek/mtk_dp.c | 335 ++++++++++++++++++++---------- > 2 files changed, 224 insertions(+), 112 deletions(-) > > -- > 2.40.1 >
Il 13/07/23 11:54, Chen-Yu Tsai ha scritto: > On Thu, Jul 13, 2023 at 5:01 PM AngeloGioacchino Del Regno > <angelogioacchino.delregno@collabora.com> wrote: >> >> Changes in v5: >> - Added .wait_hpd_asserted() callback for aux-bus >> - Avoid enabling and registering HPD interrupt + handlers for >> eDP case only (keeps HPD interrupts enabled for full DP case) >> - Support not always-on eDP panels (boot with regulator off, >> suspend with regulator off) for power saving in PM suspend. > > This still doesn't work when the DRM driver is builtin, and the panel > driver is a module. This is still with regulator-always-on. > > From what I can tell from the kernel logs, the DRM driver is not waiting > for eDP panel to probe (which sort of makes sense?), and simply uses > the default EDID. When the panel does probe, nothing triggers the DRM > driver to update its connector. > > [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:32:eDP-1] > [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:32:eDP-1] > status updated from unknown to connected > [drm:drm_mode_debug_printmodeline] Modeline "640x480": 60 25175 640 > 656 752 800 480 490 492 525 0x40 0xa > [drm:drm_mode_prune_invalid] Not using 640x480 mode: CLOCK_HIGH > [drm:drm_mode_debug_printmodeline] Modeline "800x600": 56 36000 800 > 824 896 1024 600 601 603 625 0x40 0x5 > [drm:drm_mode_prune_invalid] Not using 800x600 mode: CLOCK_HIGH > [drm:drm_mode_debug_printmodeline] Modeline "800x600": 60 40000 800 > 840 968 1056 600 601 605 628 0x40 0x5 > [drm:drm_mode_prune_invalid] Not using 800x600 mode: CLOCK_HIGH > [drm:drm_mode_debug_printmodeline] Modeline "848x480": 60 33750 848 > 864 976 1088 480 486 494 517 0x40 0x5 > [drm:drm_mode_prune_invalid] Not using 848x480 mode: CLOCK_HIGH > [drm:drm_mode_debug_printmodeline] Modeline "1024x768": 60 65000 1024 > 1048 1184 1344 768 771 777 806 0x40 0xa > [drm:drm_mode_prune_invalid] Not using 1024x768 mode: CLOCK_HIGH > [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:34:DP-1] > [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:34:DP-1] > status updated from unknown to disconnected > [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:34:DP-1] disconnected > [drm:drm_client_modeset_probe] No connectors reported connected with modes > [drm:drm_client_modeset_probe] connector 32 enabled? yes > [drm:drm_client_modeset_probe] connector 34 enabled? no > [drm:drm_client_firmware_config.constprop.0.isra.0] Not using firmware > configuration > [drm:drm_client_modeset_probe] looking for cmdline mode on connector 32 > [drm:drm_client_modeset_probe] looking for preferred mode on connector 32 0 > [drm:drm_client_modeset_probe] found mode none > [drm:drm_client_modeset_probe] picking CRTCs for 4096x4096 config > mediatek-drm mediatek-drm.12.auto: > [drm:__drm_fb_helper_initial_config_and_unlock] test CRTC 0 primary > plane > mediatek-drm mediatek-drm.12.auto: [drm] Cannot find any crtc or sizes > mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_dpcd_probe] aux_mtk_dp: > 0x00000 AUX -> (ret= 1) 14 > mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_dpcd_read] aux_mtk_dp: > 0x00000 AUX -> (ret= 15) 14 0a 84 41 00 00 01 80 02 00 00 00 0f 09 80 > mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_dpcd_probe] aux_mtk_dp: > 0x00000 AUX -> (ret= 1) 14 > mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_dpcd_read] aux_mtk_dp: > 0x02200 AUX -> (ret= 15) 14 0a 84 41 00 00 01 80 02 00 00 00 0f 01 80 > mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_read_dpcd_caps] > aux_mtk_dp: Base DPCD: 14 0a 84 41 00 00 01 80 02 00 00 00 0f 09 80 > mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_read_dpcd_caps] > aux_mtk_dp: DPCD: 14 0a 84 41 00 00 01 80 02 00 00 00 0f 01 80 > mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_dpcd_probe] aux_mtk_dp: > 0x00000 AUX -> (ret= 1) 14 > mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_dpcd_read] aux_mtk_dp: > 0x00021 AUX -> (ret= 1) 00 > panel-simple-dp-aux aux-1c500000.edp-tx: Detected BOE NE135FBM-N41 v8.1 (0x095f) > > If the panel is also built-in, then the eDP panel probe happens between > the drm driver adding components and binding to them, and everything seems > to work OK. > Argh. I actually forgot to test that case. Sorry about that. Anyway, you don't need regulator-always-on anymore, nor regulator-boot-on... ...I'll recheck with panel-edp as module and fix. Cheers, Angelo > > ChenYu > >> Changes in v4: >> - Set data lanes to idle to prevent stalls if bootloader didn't >> properly close the eDP port >> - Now using the .done_probing() callback for AUX bus to prevent >> probe deferral loops in case the panel-edp driver is a module >> as previously seen with another bridge driver (ANX7625) on >> some other SoCs (MT8192 and others) >> - Rebased over next-20230706 >> - Dropped Chen-Yu's T-b tag on last patch as some logic changed >> (before, I wasn't using the .done_probing() callback). >> >> Changes in v3: >> - Added DPTX AUX block initialization before trying to communicate >> to stop relying on the bootloader keeping it initialized before >> booting Linux. >> - Fixed commit description for patch [09/09] and removed commented >> out code (that slipped from dev phase.. sorry!). >> >> This series adds "real" support for eDP in the mtk-dp DisplayPort driver. >> >> Explaining the "real": >> Before this change, the DisplayPort driver did support eDP to some >> extent, but it was treating it entirely like a regular DP interface >> which is partially fine, after all, embedded DisplayPort *is* actually >> DisplayPort, but there might be some differences to account for... and >> this is for both small performance improvements and, more importantly, >> for correct functionality in some systems. >> >> Functionality first: >> >> One of the common differences found in various boards implementing eDP >> and machines using an eDP panel is that many times the HPD line is not >> connected. This *must* be accounted for: at startup, this specific IP >> will raise a HPD interrupt (which should maybe be ignored... as it does >> not appear to be a "real" event...) that will make the eDP panel to be >> detected and to actually work but, after a suspend-resume cycle, there >> will be no HPD interrupt (as there's no HPD line in my case!) producing >> a functionality issue - specifically, the DP Link Training fails because >> the panel doesn't get powered up, then it stays black and won't work >> until rebooting the machine (or removing and reinserting the module I >> think, but I haven't tried that). >> >> Now for.. both: >> eDP panels are *e*DP because they are *not* removable (in the sense that >> you can't unplug the cable without disassembling the machine, in which >> case, the machine shall be powered down..!): this (correct) assumption >> makes us able to solve some issues and to also gain a little performance >> during PM operations. >> >> What was done here is: >> - Caching the EDID if the panel is eDP: we're always going to read the >> same data everytime, so we can just cache that (as it's small enough) >> shortening PM resume times for the eDP driver instance; >> - Always return connector_status_connected if it's eDP: non-removable >> means connector_status_disconnected can't happen during runtime... >> this also saves us some time and even power, as we won't have to >> perform yet another power cycle of the HW; >> - Added aux-bus support! >> This makes us able to rely on panel autodetection from the EDID, >> avoiding to add more and more panel timings to panel-edp and, even >> better, allowing to use one panel node in devicetrees for multiple >> variants of the same machine since, at that point, it's not important >> to "preventively know" what panel we have (eh, it's autodetected...!). >> >> This was tested on a MT8195 Cherry Tomato Chromebook (panel-edp on aux-bus) >> >> >> P.S.: For your own testing commodity, here's a reference devicetree: >> >> pp3300_disp_x: regulator-pp3300-disp-x { >> compatible = "regulator-fixed"; >> regulator-name = "pp3300_disp_x"; >> regulator-min-microvolt = <3300000>; >> regulator-max-microvolt = <3300000>; >> enable-active-high; >> gpio = <&pio 55 GPIO_ACTIVE_HIGH>; >> pinctrl-names = "default"; >> pinctrl-0 = <&panel_fixed_pins>; >> }; >> >> &edp_tx { >> status = "okay"; >> >> pinctrl-names = "default"; >> pinctrl-0 = <&edptx_pins_default>; >> >> ports { >> #address-cells = <1>; >> #size-cells = <0>; >> >> port@0 { >> reg = <0>; >> edp_in: endpoint { >> remote-endpoint = <&dp_intf0_out>; >> }; >> }; >> >> port@1 { >> reg = <1>; >> edp_out: endpoint { >> data-lanes = <0 1 2 3>; >> remote-endpoint = <&panel_in>; >> }; >> }; >> }; >> >> aux-bus { >> panel: panel { >> compatible = "edp-panel"; >> power-supply = <&pp3300_disp_x>; >> backlight = <&backlight_lcd0>; >> port { >> panel_in: endpoint { >> remote-endpoint = <&edp_out>; >> }; >> }; >> }; >> }; >> }; >> >> AngeloGioacchino Del Regno (10): >> drm/mediatek: dp: Move AUX and panel poweron/off sequence to function >> drm/mediatek: dp: Change logging to dev for mtk_dp_aux_transfer() >> drm/mediatek: dp: Use devm variant of drm_bridge_add() >> drm/mediatek: dp: Move AUX_P0 setting to >> mtk_dp_initialize_aux_settings() >> drm/mediatek: dp: Enable event interrupt only when bridge attached >> drm/mediatek: dp: Avoid mutex locks if audio is not supported/enabled >> drm/mediatek: dp: Move PHY registration to new function >> drm/mediatek: dp: Add support for embedded DisplayPort aux-bus >> drm/mediatek: dp: Add .wait_hpd_asserted() for AUX bus >> drm/mediatek: dp: Don't register HPD interrupt handler for eDP case >> >> drivers/gpu/drm/mediatek/Kconfig | 1 + >> drivers/gpu/drm/mediatek/mtk_dp.c | 335 ++++++++++++++++++++---------- >> 2 files changed, 224 insertions(+), 112 deletions(-) >> >> -- >> 2.40.1 >> >
On Thu, Jul 13, 2023 at 5:57 PM AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> wrote: > > Il 13/07/23 11:54, Chen-Yu Tsai ha scritto: > > On Thu, Jul 13, 2023 at 5:01 PM AngeloGioacchino Del Regno > > <angelogioacchino.delregno@collabora.com> wrote: > >> > >> Changes in v5: > >> - Added .wait_hpd_asserted() callback for aux-bus > >> - Avoid enabling and registering HPD interrupt + handlers for > >> eDP case only (keeps HPD interrupts enabled for full DP case) > >> - Support not always-on eDP panels (boot with regulator off, > >> suspend with regulator off) for power saving in PM suspend. > > > > This still doesn't work when the DRM driver is builtin, and the panel > > driver is a module. This is still with regulator-always-on. > > > > From what I can tell from the kernel logs, the DRM driver is not waiting > > for eDP panel to probe (which sort of makes sense?), and simply uses > > the default EDID. When the panel does probe, nothing triggers the DRM > > driver to update its connector. > > > > [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:32:eDP-1] > > [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:32:eDP-1] > > status updated from unknown to connected > > [drm:drm_mode_debug_printmodeline] Modeline "640x480": 60 25175 640 > > 656 752 800 480 490 492 525 0x40 0xa > > [drm:drm_mode_prune_invalid] Not using 640x480 mode: CLOCK_HIGH > > [drm:drm_mode_debug_printmodeline] Modeline "800x600": 56 36000 800 > > 824 896 1024 600 601 603 625 0x40 0x5 > > [drm:drm_mode_prune_invalid] Not using 800x600 mode: CLOCK_HIGH > > [drm:drm_mode_debug_printmodeline] Modeline "800x600": 60 40000 800 > > 840 968 1056 600 601 605 628 0x40 0x5 > > [drm:drm_mode_prune_invalid] Not using 800x600 mode: CLOCK_HIGH > > [drm:drm_mode_debug_printmodeline] Modeline "848x480": 60 33750 848 > > 864 976 1088 480 486 494 517 0x40 0x5 > > [drm:drm_mode_prune_invalid] Not using 848x480 mode: CLOCK_HIGH > > [drm:drm_mode_debug_printmodeline] Modeline "1024x768": 60 65000 1024 > > 1048 1184 1344 768 771 777 806 0x40 0xa > > [drm:drm_mode_prune_invalid] Not using 1024x768 mode: CLOCK_HIGH > > [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:34:DP-1] > > [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:34:DP-1] > > status updated from unknown to disconnected > > [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:34:DP-1] disconnected > > [drm:drm_client_modeset_probe] No connectors reported connected with modes > > [drm:drm_client_modeset_probe] connector 32 enabled? yes > > [drm:drm_client_modeset_probe] connector 34 enabled? no > > [drm:drm_client_firmware_config.constprop.0.isra.0] Not using firmware > > configuration > > [drm:drm_client_modeset_probe] looking for cmdline mode on connector 32 > > [drm:drm_client_modeset_probe] looking for preferred mode on connector 32 0 > > [drm:drm_client_modeset_probe] found mode none > > [drm:drm_client_modeset_probe] picking CRTCs for 4096x4096 config > > mediatek-drm mediatek-drm.12.auto: > > [drm:__drm_fb_helper_initial_config_and_unlock] test CRTC 0 primary > > plane > > mediatek-drm mediatek-drm.12.auto: [drm] Cannot find any crtc or sizes > > mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_dpcd_probe] aux_mtk_dp: > > 0x00000 AUX -> (ret= 1) 14 > > mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_dpcd_read] aux_mtk_dp: > > 0x00000 AUX -> (ret= 15) 14 0a 84 41 00 00 01 80 02 00 00 00 0f 09 80 > > mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_dpcd_probe] aux_mtk_dp: > > 0x00000 AUX -> (ret= 1) 14 > > mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_dpcd_read] aux_mtk_dp: > > 0x02200 AUX -> (ret= 15) 14 0a 84 41 00 00 01 80 02 00 00 00 0f 01 80 > > mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_read_dpcd_caps] > > aux_mtk_dp: Base DPCD: 14 0a 84 41 00 00 01 80 02 00 00 00 0f 09 80 > > mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_read_dpcd_caps] > > aux_mtk_dp: DPCD: 14 0a 84 41 00 00 01 80 02 00 00 00 0f 01 80 > > mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_dpcd_probe] aux_mtk_dp: > > 0x00000 AUX -> (ret= 1) 14 > > mediatek-drm mediatek-drm.12.auto: [drm:drm_dp_dpcd_read] aux_mtk_dp: > > 0x00021 AUX -> (ret= 1) 00 > > panel-simple-dp-aux aux-1c500000.edp-tx: Detected BOE NE135FBM-N41 v8.1 (0x095f) > > > > If the panel is also built-in, then the eDP panel probe happens between > > the drm driver adding components and binding to them, and everything seems > > to work OK. > > > > Argh. I actually forgot to test that case. Sorry about that. > > Anyway, you don't need regulator-always-on anymore, nor regulator-boot-on... Confirmed this case works now. > ...I'll recheck with panel-edp as module and fix. With the module case, I also get an devlink error: mediatek-drm-dp 1c500000.edp-tx: Failed to create device link (0x180) with regulator-pp3300-disp-x which doesn't happen with the builtin case. Not sure if it gets a retry or anything later. ChenYu > Cheers, > Angelo > > > > > ChenYu > > > >> Changes in v4: > >> - Set data lanes to idle to prevent stalls if bootloader didn't > >> properly close the eDP port > >> - Now using the .done_probing() callback for AUX bus to prevent > >> probe deferral loops in case the panel-edp driver is a module > >> as previously seen with another bridge driver (ANX7625) on > >> some other SoCs (MT8192 and others) > >> - Rebased over next-20230706 > >> - Dropped Chen-Yu's T-b tag on last patch as some logic changed > >> (before, I wasn't using the .done_probing() callback). > >> > >> Changes in v3: > >> - Added DPTX AUX block initialization before trying to communicate > >> to stop relying on the bootloader keeping it initialized before > >> booting Linux. > >> - Fixed commit description for patch [09/09] and removed commented > >> out code (that slipped from dev phase.. sorry!). > >> > >> This series adds "real" support for eDP in the mtk-dp DisplayPort driver. > >> > >> Explaining the "real": > >> Before this change, the DisplayPort driver did support eDP to some > >> extent, but it was treating it entirely like a regular DP interface > >> which is partially fine, after all, embedded DisplayPort *is* actually > >> DisplayPort, but there might be some differences to account for... and > >> this is for both small performance improvements and, more importantly, > >> for correct functionality in some systems. > >> > >> Functionality first: > >> > >> One of the common differences found in various boards implementing eDP > >> and machines using an eDP panel is that many times the HPD line is not > >> connected. This *must* be accounted for: at startup, this specific IP > >> will raise a HPD interrupt (which should maybe be ignored... as it does > >> not appear to be a "real" event...) that will make the eDP panel to be > >> detected and to actually work but, after a suspend-resume cycle, there > >> will be no HPD interrupt (as there's no HPD line in my case!) producing > >> a functionality issue - specifically, the DP Link Training fails because > >> the panel doesn't get powered up, then it stays black and won't work > >> until rebooting the machine (or removing and reinserting the module I > >> think, but I haven't tried that). > >> > >> Now for.. both: > >> eDP panels are *e*DP because they are *not* removable (in the sense that > >> you can't unplug the cable without disassembling the machine, in which > >> case, the machine shall be powered down..!): this (correct) assumption > >> makes us able to solve some issues and to also gain a little performance > >> during PM operations. > >> > >> What was done here is: > >> - Caching the EDID if the panel is eDP: we're always going to read the > >> same data everytime, so we can just cache that (as it's small enough) > >> shortening PM resume times for the eDP driver instance; > >> - Always return connector_status_connected if it's eDP: non-removable > >> means connector_status_disconnected can't happen during runtime... > >> this also saves us some time and even power, as we won't have to > >> perform yet another power cycle of the HW; > >> - Added aux-bus support! > >> This makes us able to rely on panel autodetection from the EDID, > >> avoiding to add more and more panel timings to panel-edp and, even > >> better, allowing to use one panel node in devicetrees for multiple > >> variants of the same machine since, at that point, it's not important > >> to "preventively know" what panel we have (eh, it's autodetected...!). > >> > >> This was tested on a MT8195 Cherry Tomato Chromebook (panel-edp on aux-bus) > >> > >> > >> P.S.: For your own testing commodity, here's a reference devicetree: > >> > >> pp3300_disp_x: regulator-pp3300-disp-x { > >> compatible = "regulator-fixed"; > >> regulator-name = "pp3300_disp_x"; > >> regulator-min-microvolt = <3300000>; > >> regulator-max-microvolt = <3300000>; > >> enable-active-high; > >> gpio = <&pio 55 GPIO_ACTIVE_HIGH>; > >> pinctrl-names = "default"; > >> pinctrl-0 = <&panel_fixed_pins>; > >> }; > >> > >> &edp_tx { > >> status = "okay"; > >> > >> pinctrl-names = "default"; > >> pinctrl-0 = <&edptx_pins_default>; > >> > >> ports { > >> #address-cells = <1>; > >> #size-cells = <0>; > >> > >> port@0 { > >> reg = <0>; > >> edp_in: endpoint { > >> remote-endpoint = <&dp_intf0_out>; > >> }; > >> }; > >> > >> port@1 { > >> reg = <1>; > >> edp_out: endpoint { > >> data-lanes = <0 1 2 3>; > >> remote-endpoint = <&panel_in>; > >> }; > >> }; > >> }; > >> > >> aux-bus { > >> panel: panel { > >> compatible = "edp-panel"; > >> power-supply = <&pp3300_disp_x>; > >> backlight = <&backlight_lcd0>; > >> port { > >> panel_in: endpoint { > >> remote-endpoint = <&edp_out>; > >> }; > >> }; > >> }; > >> }; > >> }; > >> > >> AngeloGioacchino Del Regno (10): > >> drm/mediatek: dp: Move AUX and panel poweron/off sequence to function > >> drm/mediatek: dp: Change logging to dev for mtk_dp_aux_transfer() > >> drm/mediatek: dp: Use devm variant of drm_bridge_add() > >> drm/mediatek: dp: Move AUX_P0 setting to > >> mtk_dp_initialize_aux_settings() > >> drm/mediatek: dp: Enable event interrupt only when bridge attached > >> drm/mediatek: dp: Avoid mutex locks if audio is not supported/enabled > >> drm/mediatek: dp: Move PHY registration to new function > >> drm/mediatek: dp: Add support for embedded DisplayPort aux-bus > >> drm/mediatek: dp: Add .wait_hpd_asserted() for AUX bus > >> drm/mediatek: dp: Don't register HPD interrupt handler for eDP case > >> > >> drivers/gpu/drm/mediatek/Kconfig | 1 + > >> drivers/gpu/drm/mediatek/mtk_dp.c | 335 ++++++++++++++++++++---------- > >> 2 files changed, 224 insertions(+), 112 deletions(-) > >> > >> -- > >> 2.40.1 > >> > > >