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 60813C19F2D for ; Tue, 9 Aug 2022 08:06:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239255AbiHIIGg (ORCPT ); Tue, 9 Aug 2022 04:06:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50662 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229963AbiHIIGa (ORCPT ); Tue, 9 Aug 2022 04:06:30 -0400 Received: from mailgw01.mediatek.com (unknown [60.244.123.138]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4FA0EE00D; Tue, 9 Aug 2022 01:06:25 -0700 (PDT) X-UUID: 51b02bc78b574cc186146b642013d65d-20220809 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=3jeezdODHoDq/n+1k33XTZuIqbvhdPjitEJXsCEjp9I=; b=JhClGLG9oxQ/KDj9hbNHQpIlMQ8FJ/qZRdIhpznzlVCFSInvZSPStMRyYyzHuyOLRlEuQ9daQTeExBPnNE2dz6cZ2/3DWqQaYT0q2r1kM/jhgULcvFj3S054llJsjmuxdeW3pjHVctYafcwL3hdJta/h0UR65Z/ySQXGq+EGMyk=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.9,REQID:9ed45b08-8b63-46af-9824-7971ecc00656,OB:0,LO B:0,IP:0,URL:0,TC:0,Content:0,EDM:0,RT:0,SF:0,FILE:0,BULK:0,RULE:Release_H am,ACTION:release,TS:0 X-CID-META: VersionHash:3d8acc9,CLOUDID:5768289c-da39-4e3b-a854-56c7d2111b46,C OID:IGNORED,Recheck:0,SF:nil,TC:nil,Content:0,EDM:-3,IP:nil,URL:0,File:nil ,Bulk:nil,QS:nil,BEC:nil,COL:0 X-UUID: 51b02bc78b574cc186146b642013d65d-20220809 Received: from mtkexhb02.mediatek.inc [(172.21.101.103)] by mailgw01.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 598252204; Tue, 09 Aug 2022 16:06:19 +0800 Received: from mtkmbs11n2.mediatek.inc (172.21.101.187) by mtkmbs10n2.mediatek.inc (172.21.101.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Tue, 9 Aug 2022 16:06:17 +0800 Received: from mtksdccf07 (172.21.84.99) by mtkmbs11n2.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.792.15 via Frontend Transport; Tue, 9 Aug 2022 16:06:17 +0800 Message-ID: Subject: Re: [PATCH v16 3/8] drm/mediatek: Add MT8195 Embedded DisplayPort driver From: Bo-Chen Chen To: CK Hu , "chunkuang.hu@kernel.org" , "p.zabel@pengutronix.de" , "daniel@ffwll.ch" , "robh+dt@kernel.org" , "krzysztof.kozlowski+dt@linaro.org" , "mripard@kernel.org" , "tzimmermann@suse.de" , "matthias.bgg@gmail.com" , "deller@gmx.de" , "airlied@linux.ie" CC: "msp@baylibre.com" , "granquet@baylibre.com" , Jitao Shi =?UTF-8?Q?=28=E7=9F=B3=E8=AE=B0=E6=B6=9B=29?= , "wenst@chromium.org" , "angelogioacchino.delregno@collabora.com" , LiangXu Xu =?UTF-8?Q?=28=E5=BE=90=E4=BA=AE=29?= , "dri-devel@lists.freedesktop.org" , "linux-mediatek@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-fbdev@vger.kernel.org" , Project_Global_Chrome_Upstream_Group Date: Tue, 9 Aug 2022 16:06:12 +0800 In-Reply-To: <150988eef41cac1e1c4b422cf1ad65c10309f472.camel@mediatek.com> References: <20220805101459.3386-1-rex-bc.chen@mediatek.com> <20220805101459.3386-4-rex-bc.chen@mediatek.com> <150988eef41cac1e1c4b422cf1ad65c10309f472.camel@mediatek.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 On Mon, 2022-08-08 at 13:21 +0800, CK Hu wrote: > Hi, Bo-Chen: > > On Fri, 2022-08-05 at 18:14 +0800, Bo-Chen Chen wrote: > > From: Markus Schneider-Pargmann > > > > This patch adds a embedded 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 > > Jitao shi > > > > Signed-off-by: Markus Schneider-Pargmann > > Signed-off-by: Guillaume Ranquet > > Signed-off-by: Bo-Chen Chen > > Tested-by: AngeloGioacchino Del Regno < > > angelogioacchino.delregno@collabora.com> > > Reviewed-by: AngeloGioacchino Del Regno < > > angelogioacchino.delregno@collabora.com> > > --- > > [snip] > > > + > > +static void mtk_dp_hpd_sink_event(struct mtk_dp *mtk_dp) > > +{ > > + ssize_t ret; > > + u8 link_status[DP_LINK_STATUS_SIZE] = {}; > > + u32 link_status_reg = DP_LANE0_1_STATUS; > > + > > + ret = drm_dp_dpcd_read(&mtk_dp->aux, link_status_reg, > > link_status, > > + sizeof(link_status)); > > + if (!ret) { > > + drm_err(mtk_dp->drm_dev, "Read link status failed\n"); > > + return; > > + } > > + > > + if (!drm_dp_channel_eq_ok(link_status, mtk_dp- > > > train_info.lane_count)) { > > > > + drm_err(mtk_dp->drm_dev, "Channel EQ failed\n"); > > + return; > > + } > > + > > + if (link_status[1] & DP_REMOTE_CONTROL_COMMAND_PENDING) > > I does not see any other DP driver process > DP_REMOTE_CONTROL_COMMAND_PENDING, why mtk dp driver process it? If > this is an advanced function, separate this to an independent patch. > > Regards, > CK > Hello CK, We are not using this. The dpcd write is just for clearing the irq status of sink device, but we are not doing anything for this hpd event. So I will drop this. BRs, Bo-Chen > > + drm_dp_dpcd_writeb(&mtk_dp->aux, > > DP_DEVICE_SERVICE_IRQ_VECTOR, > > + DP_REMOTE_CONTROL_COMMAND_PENDING); > > +} > > + > > > >