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; > +} > + 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 193A9C43334 for ; Tue, 7 Jun 2022 06:21:36 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 25D3812AAD7; Tue, 7 Jun 2022 06:21:35 +0000 (UTC) Received: from mailgw02.mediatek.com (unknown [210.61.82.184]) by gabe.freedesktop.org (Postfix) with ESMTPS id 354DD12AAD4 for ; Tue, 7 Jun 2022 06:21:33 +0000 (UTC) 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 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 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Markus Schneider-Pargmann , linux-mediatek@lists.infradead.org, linux-phy@lists.infradead.org, linux-arm-kernel@lists.infradead.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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; > +} > + 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 82E14C43334 for ; Tue, 7 Jun 2022 06:22:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:CC:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=LUD2Sj5UUUvEEKDfDzOrtwAFm6F17T8k1ba4u0pxHuA=; b=iqqgZ1DAVCFmfk EOXtuNSHwF7yiJQFQC1NrkfmnJcVwknAOS0HnbGfkGOie4fA9EttIcY4/h7ICqt0PY2+9RFUC+Nz+ 2yWSi42zRonVaA+iOUqeVDAh9d6g4+lSzkENePmVU1hPa9Xhc3B0zaF9Ofa3MjFtE71JIcyKvUi88 0N3gi1pMUNzuzeVncnOrdxcPQi28AIhG7AqiqzUjgSX/dB/pDWV3GyaEoRdHmVeIS2z2GwYX/ukG/ AKliXm1cPDGx8wlDEW+hONBIEpzjHD9KIGJ0sLBFsmfYL7Q7SVrjdzQZs3wKtJ5Wz90S9ZQitstsb Rmk28ohgmZNAUmE4yCfQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nySb7-004zYk-1E; Tue, 07 Jun 2022 06:21:49 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nySaw-004zUo-4Q; Tue, 07 Jun 2022 06:21:39 +0000 X-UUID: e96d9b3026d74811b336021b3ec5d524-20220606 X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.5,REQID:b5e1c9c7-ceef-4abc-8c2b-5cf48d1b61c0,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:395f6f7e-c8dc-403a-96e8-6237210dceee,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: e96d9b3026d74811b336021b3ec5d524-20220606 Received: from mtkcas67.mediatek.inc [(172.29.193.45)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1846272803; Mon, 06 Jun 2022 23:21:28 -0700 Received: from mtkmbs11n1.mediatek.inc (172.21.101.185) by MTKMBS62N1.mediatek.inc (172.29.193.41) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 6 Jun 2022 23:21:27 -0700 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> X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220606_232138_205840_0D89847F X-CRM114-Status: GOOD ( 27.49 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.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; > +} > + _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EDF12C43334 for ; Tue, 7 Jun 2022 06:21:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:CC:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=iSuobUV6BLvZPOcZKRm+2HDV5ffyPgNHd0rYur7V6Zg=; b=uuK09tOMJ0MCw+ uIaSlVT87zdOoGRAjqnStpM3ItFSa7JdB8V+VtFuGk8DIfSK6fyeCCfGLfFguvYUwlz3gryp4CTYX n70KCmglxN4pcxZ21hy0ARiRCHW8uhHdaLGqgA+GKpgQTb2ZhCEayXYdgiuDl86/lu7XayRbGWEw6 lKR4yVd7e2U0vHmGHx/w8IATHvcpYffTe+Mq9QBnG7PEAPnkgYlkc/o5NaKGgs6S2oplcxHcAzl2r 3OKJl6gbKPjHLetMHNoLpzHYfCxxYZF8Vokkh3wQClDwtijwpWCHqkf+aY6ac7Rf/4jaTk+Qyi9h5 gnUJsHrk0mDR+hPM0eRg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nySb8-004zZP-8H; Tue, 07 Jun 2022 06:21:50 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nySaw-004zUo-4Q; Tue, 07 Jun 2022 06:21:39 +0000 X-UUID: e96d9b3026d74811b336021b3ec5d524-20220606 X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.5,REQID:b5e1c9c7-ceef-4abc-8c2b-5cf48d1b61c0,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:395f6f7e-c8dc-403a-96e8-6237210dceee,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: e96d9b3026d74811b336021b3ec5d524-20220606 Received: from mtkcas67.mediatek.inc [(172.29.193.45)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1846272803; Mon, 06 Jun 2022 23:21:28 -0700 Received: from mtkmbs11n1.mediatek.inc (172.21.101.185) by MTKMBS62N1.mediatek.inc (172.29.193.41) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 6 Jun 2022 23:21:27 -0700 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> X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220606_232138_205840_0D89847F X-CRM114-Status: GOOD ( 27.49 ) X-BeenThere: linux-phy@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux Phy Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-phy" Errors-To: linux-phy-bounces+linux-phy=archiver.kernel.org@lists.infradead.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; > +} > + -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E7D64C43334 for ; Tue, 7 Jun 2022 06:23:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:CC:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=lyj07z3U78gXBaCak5xUIVGg7f9TQBFuT+YB4oXgcpw=; b=ecbkfyNgXFwTEX vRkC4fuaMtPtyObkLQZeoRfegzFwxS59DEFAUN6+r1U1l6al5p22ImyUYZtg1rcXNF+BpNJGWhx6R LgzAHp/U9SsAIunxiKsHp+KB+w+Pdb/w0V0j50B6KVs/RABZKROQ7kAYZIOs4b7npM6sjC2+wVEjT U4JzAEj0S3s92Nq5JPaHBNBhisE12VUHa4OfGMRHDo6UpYoorZfCNk4KqVsI1m1LTIMKB6eJuCFD+ 07mCPPPKzY0cJS5/bpuDc//XBWiVlWf0XDdDShjJHymjwxhxGF/9FM5KeByfzAHjEWtaUOagiTX8v RZEh1FIegCyhXiNo9/yA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nySaz-004zWu-23; Tue, 07 Jun 2022 06:21:41 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nySaw-004zUo-4Q; Tue, 07 Jun 2022 06:21:39 +0000 X-UUID: e96d9b3026d74811b336021b3ec5d524-20220606 X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.5,REQID:b5e1c9c7-ceef-4abc-8c2b-5cf48d1b61c0,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:395f6f7e-c8dc-403a-96e8-6237210dceee,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: e96d9b3026d74811b336021b3ec5d524-20220606 Received: from mtkcas67.mediatek.inc [(172.29.193.45)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1846272803; Mon, 06 Jun 2022 23:21:28 -0700 Received: from mtkmbs11n1.mediatek.inc (172.21.101.185) by MTKMBS62N1.mediatek.inc (172.29.193.41) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 6 Jun 2022 23:21:27 -0700 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> X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220606_232138_205840_0D89847F X-CRM114-Status: GOOD ( 27.49 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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; > +} > + _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel