Message ID | 20230330142035.191399-1-angelogioacchino.delregno@collabora.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1178947vqo; Thu, 30 Mar 2023 07:44:03 -0700 (PDT) X-Google-Smtp-Source: AKy350aagPUSKxx8jXNorfrSwWs3qbV29QsKbhoe8RNd08orNzHZa2ovA4mGZEsoI2xmsjjDvOjM X-Received: by 2002:a17:90b:1647:b0:236:73d5:82cf with SMTP id il7-20020a17090b164700b0023673d582cfmr26790628pjb.9.1680187443193; Thu, 30 Mar 2023 07:44:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680187443; cv=none; d=google.com; s=arc-20160816; b=AdsLATLT8zuTSiFoe3uT58DE+iqOROqX83op4WbjwcynVEozjmvMy8BLN0EE0BpjiI cT2H5AOSlqozOWlkDzpZ/Momrqjv5HiNPW16k7HJ8Na2nmn31oo1X8AYOlkU0xqP+gRC myKyMZrOy3cllzjt9oN1Zk2NFdXlsmGpcnX6JrmMoGivAxN8CI10Ef0puixOuvBo8+rJ Pp60jblQ1pwa2D6maYRGJtPvaUorHm86qda5mAslw/pi4qc5z5jH04HbSUoeOOZfnpAh /5jhuExaj+1AmynzxVqeCgmQLGZ1359ItFbBtpyV1JT1TzETNhhCSx5NmyG5JzkGPsOD ZVsA== 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=0M4Ry3df6NVrXO0G3WC4aU/wNHteRp+/VH+Gpm1PEfQ=; b=TpVznR80dH7jRBu+Kr0bccK/7HoNADxCVp6BzZlrJwxzT38HNOnmCbfm0CGKlY9xAU OvZmUKg7gKYT/q2nKQcOv+IJx6MKJDk7Q3Inz3PlQWYJqjAgLCbUkjQlczND3t0MTmKL MY1grNBDNdV9vW/Ax209E0pLMVKd7BJ/sN3h1gF4N1Mtk922cpfweIsIQIJy5Pr4SIw3 Hrqcn/iu3U15LodJdO8ZFwJsfzWIDYkmElGlDRxCI1GlPQY5IoZLCyY0fzrxNfaGEUy6 AklAfC4DGq3cIU7HUqb2WwU0jI9n03vPCN3fTvALhEJpmRRhbCzkPTA/RHaWCZ9p7Tuo j3bg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b="SmUL/fcP"; 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 co19-20020a17090afe9300b0023750b695e1si4074592pjb.156.2023.03.30.07.43.49; Thu, 30 Mar 2023 07:44:03 -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="SmUL/fcP"; 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 S231688AbjC3OUp (ORCPT <rfc822;rua109.linux@gmail.com> + 99 others); Thu, 30 Mar 2023 10:20:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50294 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232081AbjC3OUn (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 30 Mar 2023 10:20:43 -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 8DB26AC for <linux-kernel@vger.kernel.org>; Thu, 30 Mar 2023 07:20:41 -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 A0F6B66030CD; Thu, 30 Mar 2023 15:20:39 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1680186040; bh=z67vNzKi9aaIqAtcwOlUEH/djDA/nzpldmj/FIyFeFE=; h=From:To:Cc:Subject:Date:From; b=SmUL/fcPVWMP9xKCbKnTdqhI6xu8GRuh0Zi1NBwpLtsx9mTCG8Ul+uSFZ5bAV6Okm V8FNs7jaUTWYRylJVu3sHHPC58NTPNmVPRhsFRq2UQHFq+1hIOrj/4SLTRkGwQejyF fHqB5FJy8V2zJNjxibyFvbI1I9SRkigAJzpaUMjyHIk/KajqkhkjLORwwOVQnxJKtY ivDZlTVRsAXuSGTI3F7Bokq4NxiGPX9PatVYPpYKxLY709DwmM3DfRikyIapP9HZTs eJ3Dg1Xs/wNoI8qarNNTy8TFePa8xIbdLbvjmASgRJBcx7jezG2FAH8bq5TCkKCND4 qXHkXzHzFGzAw== 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 Subject: [PATCH v2 0/8] MediaTek DisplayPort: support eDP and aux-bus Date: Thu, 30 Mar 2023 16:20:27 +0200 Message-Id: <20230330142035.191399-1-angelogioacchino.delregno@collabora.com> X-Mailer: git-send-email 2.40.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761803001671127944?= X-GMAIL-MSGID: =?utf-8?q?1761804228140425803?= |
Series |
MediaTek DisplayPort: support eDP and aux-bus
|
|
Message
AngeloGioacchino Del Regno
March 30, 2023, 2:20 p.m. UTC
Changes in v2: - Sorry, the v1 send got broken as I forgot to remove old patches in my send folder. 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: &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 (8): drm/mediatek: dp: Cache EDID for eDP panel drm/mediatek: dp: Move AUX and panel poweron/off sequence to function drm/mediatek: dp: Always return connected status for eDP in .detect() drm/mediatek: dp: Always set cable_plugged_in at resume for eDP panel drm/mediatek: dp: Change logging to dev for mtk_dp_aux_transfer() drm/mediatek: dp: Enable event interrupt only when bridge attached drm/mediatek: dp: Use devm variant of drm_bridge_add() drm/mediatek: dp: Add support for embedded DisplayPort aux-bus drivers/gpu/drm/mediatek/mtk_dp.c | 172 ++++++++++++++++++------------ 1 file changed, 106 insertions(+), 66 deletions(-)