From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F3F0CCCA47E for ; Tue, 7 Jun 2022 06:21:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230418AbiFGGVj (ORCPT ); Tue, 7 Jun 2022 02:21:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43494 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230086AbiFGGVh (ORCPT ); Tue, 7 Jun 2022 02:21:37 -0400 Received: from mailgw02.mediatek.com (unknown [210.61.82.184]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0C0366FD2F; Mon, 6 Jun 2022 23:21:30 -0700 (PDT) X-UUID: 65a4006f858644e5b49a6e18ee0f91e9-20220607 X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.5,REQID:2c3b1d89-4978-4ed5-8c92-0baceb47a6ee,OB:0,LO B:0,IP:0,URL:5,TC:0,Content:0,EDM:0,RT:0,SF:0,FILE:0,RULE:Release_Ham,ACTI ON:release,TS:5 X-CID-META: VersionHash:2a19b09,CLOUDID:47f0e4e4-2ba2-4dc1-b6c5-11feb6c769e0,C OID:IGNORED,Recheck:0,SF:nil,TC:nil,Content:0,EDM:-3,IP:nil,URL:1,File:nil ,QS:0,BEC:nil X-UUID: 65a4006f858644e5b49a6e18ee0f91e9-20220607 Received: from mtkexhb01.mediatek.inc [(172.21.101.102)] by mailgw02.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1400721123; Tue, 07 Jun 2022 14:21:27 +0800 Received: from mtkmbs11n1.mediatek.inc (172.21.101.185) by mtkmbs11n1.mediatek.inc (172.21.101.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Tue, 7 Jun 2022 14:21:25 +0800 Received: from mtksdccf07 (172.21.84.99) by mtkmbs11n1.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.792.3 via Frontend Transport; Tue, 7 Jun 2022 14:21:24 +0800 Message-ID: <0bd8b0c66b9e2a1b63280e7eab63048bee7fe786.camel@mediatek.com> Subject: Re: [PATCH v10 18/21] drm/mediatek: Add mt8195 Embedded DisplayPort driver From: CK Hu To: Rex-BC Chen , Guillaume Ranquet , Chun-Kuang Hu , "Philipp Zabel" , David Airlie , "Daniel Vetter" , Rob Herring , "Krzysztof Kozlowski" , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Matthias Brugger , Chunfeng Yun , "Kishon Vijay Abraham I" , Vinod Koul , "Helge Deller" , Jitao shi CC: Markus Schneider-Pargmann , , , , , , , Date: Tue, 7 Jun 2022 14:21:24 +0800 In-Reply-To: <20220523104758.29531-19-granquet@baylibre.com> References: <20220523104758.29531-1-granquet@baylibre.com> <20220523104758.29531-19-granquet@baylibre.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-MTK: N Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Rex: On Mon, 2022-05-23 at 12:47 +0200, Guillaume Ranquet wrote: > From: Markus Schneider-Pargmann > > This patch adds a DisplayPort driver for the Mediatek mt8195 SoC. > > It supports the mt8195, the embedded DisplayPort units. It offers > DisplayPort 1.4 with up to 4 lanes. > > The driver creates a child device for the phy. The child device will > never exist without the parent being active. As they are sharing a > register range, the parent passes a regmap pointer to the child so > that > both can work with the same register range. The phy driver sets > device > data that is read by the parent to get the phy device that can be > used > to control the phy properties. > > This driver is based on an initial version by > Jason-JH.Lin . > > Signed-off-by: Markus Schneider-Pargmann > Signed-off-by: Guillaume Ranquet > --- [snip] > + > +static irqreturn_t mtk_dp_hpd_event_thread(int hpd, void *dev) > +{ > + struct mtk_dp *mtk_dp = dev; > + int event; > + u8 buf[DP_RECEIVER_CAP_SIZE] = {}; > + > + event = mtk_dp_plug_state(mtk_dp) ? connector_status_connected > : > + connector_status_disc > onnected; > + > + if (event < 0) event is always > 0, isn't it? > + return IRQ_HANDLED; > + > + if (mtk_dp->drm_dev) { > + dev_info(mtk_dp->dev, "drm_helper_hpd_irq_event\n"); > + drm_helper_hpd_irq_event(mtk_dp->bridge.dev); I think this ISR would come once. If bridge has not attached, the drm core would lost this event. Maybe you should enable eDP hardware after bridge attached or send this event when attached. > + } > + > + if (mtk_dp->train_info.cable_state_change) { Executing this thread imply cable_state_change = true, so drop cable_state_change. > + mtk_dp->train_info.cable_state_change = false; > + > + mtk_dp->train_state = MTK_DP_TRAIN_STATE_STARTUP; > + > + if (!mtk_dp->train_info.cable_plugged_in || > + !mtk_dp_plug_state(mtk_dp)) { I do not like two variable to present one thing. If mtk_dp->train_info.cable_plugged_in = false and mtk_dp_plug_state(mtk_dp) = ture What does this mean? I think this mean 'now' is connected because cable_plugged_in is old information and mtk_dp_plug_state() is current information. But I would like to keep cable_plugged_in and drop mtk_dp_plug_state() because cable_plugged_in would be changed in isr and it would be the same as mtk_dp_plug_state(). Regards, CK > + mtk_dp_video_mute(mtk_dp, true); > + > + mtk_dp_initialize_priv_data(mtk_dp); > + mtk_dp_set_idle_pattern(mtk_dp, true); > + if (mtk_dp->has_fec) > + mtk_dp_fec_enable(mtk_dp, false); > + > + mtk_dp_update_bits(mtk_dp, > MTK_DP_TOP_PWR_STATE, > + DP_PWR_STATE_BANDGAP_TPLL, > + DP_PWR_STATE_MASK); > + } else { > + mtk_dp_update_bits(mtk_dp, > MTK_DP_TOP_PWR_STATE, > + DP_PWR_STATE_BANDGAP_TPLL_LA > NE, > + DP_PWR_STATE_MASK); > + drm_dp_read_dpcd_caps(&mtk_dp->aux, buf); > + mtk_dp->train_info.link_rate = > + min_t(int, mtk_dp->max_linkrate, > + buf[mtk_dp->max_linkrate]); > + mtk_dp->train_info.lane_count = > + min_t(int, mtk_dp->max_lanes, > + drm_dp_max_lane_count(buf)); > + } > + } > + > + if (mtk_dp->train_info.irq_status & MTK_DP_HPD_INTERRUPT) { > + dev_dbg(mtk_dp->dev, "MTK_DP_HPD_INTERRUPT\n"); > + mtk_dp->train_info.irq_status &= ~MTK_DP_HPD_INTERRUPT; > + mtk_dp_hpd_sink_event(mtk_dp); > + } > + > + return IRQ_HANDLED; > +} > +