All of lore.kernel.org
 help / color / mirror / Atom feed
From: CK Hu <ck.hu@mediatek.com>
To: Rex-BC Chen <rex-bc.chen@mediatek.com>,
	"chunkuang.hu@kernel.org" <chunkuang.hu@kernel.org>,
	"p.zabel@pengutronix.de" <p.zabel@pengutronix.de>,
	"daniel@ffwll.ch" <daniel@ffwll.ch>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"krzysztof.kozlowski+dt@linaro.org" 
	<krzysztof.kozlowski+dt@linaro.org>,
	"mripard@kernel.org" <mripard@kernel.org>,
	"tzimmermann@suse.de" <tzimmermann@suse.de>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
	"deller@gmx.de" <deller@gmx.de>,
	"airlied@linux.ie" <airlied@linux.ie>
Cc: "msp@baylibre.com" <msp@baylibre.com>,
	"granquet@baylibre.com" <granquet@baylibre.com>,
	"Jitao Shi (石记涛)" <jitao.shi@mediatek.com>,
	"wenst@chromium.org" <wenst@chromium.org>,
	"angelogioacchino.delregno@collabora.com"
	<angelogioacchino.delregno@collabora.com>,
	"LiangXu Xu (徐亮)" <LiangXu.Xu@mediatek.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	Project_Global_Chrome_Upstream_Group
	<Project_Global_Chrome_Upstream_Group@mediatek.com>
Subject: Re: [PATCH v14 05/10] drm/mediatek: Add MT8195 Embedded DisplayPort driver
Date: Thu, 21 Jul 2022 14:24:58 +0800	[thread overview]
Message-ID: <4e543dc3a183af3966aa6f2f28b0afb9d95cbac2.camel@mediatek.com> (raw)
In-Reply-To: <7b1a555ab62aec8c3f5717b8827c81a2076bf569.camel@mediatek.com>

Hi, Rex:

On Thu, 2022-07-21 at 10:38 +0800, Rex-BC Chen wrote:
> On Fri, 2022-07-15 at 16:51 +0800, CK Hu wrote:
> > Hi, Bo-Chen:
> > 
> > On Tue, 2022-07-12 at 19:12 +0800, Bo-Chen Chen wrote:
> > > From: Markus Schneider-Pargmann <msp@baylibre.com>
> > > 
> > > 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 <jitao.shi@mediatek.com>
> > > 
> > > Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
> > > Signed-off-by: Guillaume Ranquet <granquet@baylibre.com>
> > > Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
> > > ---
> > 
> > [snip]
> > 
> > > +static void mtk_dp_hpd_sink_event(struct mtk_dp *mtk_dp)
> > > +{
> > > +	ssize_t ret;
> > > +	u8 sink_count;
> > > +	u8 link_status[DP_LINK_STATUS_SIZE] = {};
> > > +	u32 sink_count_reg = DP_SINK_COUNT_ESI;
> > > +	u32 link_status_reg = DP_LANE0_1_STATUS;
> > > +
> > > +	ret = drm_dp_dpcd_readb(&mtk_dp->aux, sink_count_reg,
> > > &sink_count);
> > 
> > According to your last reply, if drm_dp_dpcd_readb() fail, we could
> > skip below statement. So this just for error checking? If so, the
> > next
> > drm_dp_dpcd_read() would also do the error checking, so the
> > checking
> > here is redundant.
> > 
> > Regards,
> > CK
> > 
> 
> Hello CK,
> 
> sorry, I don't get your point.
> We use "drm_dp_dpcd_readb(&mtk_dp->aux, sink_count_reg, &sink_count)"
> to get sink count and use "drm_dp_dpcd_read(&mtk_dp->aux,
> link_status_reg, link_status, sizeof(link_status));" to get link
> status.
> 
> If we don't get any sink count, we don't need to check the link
> status.
> Therefore, we just return if we are failed to get sink count.

I assume that when error happen, both read sink_count and read
link_status would fail, so you could directly read link_status. Do you
think that when error happen, only read sink_count would fail and read
link_status would success? It it is the later case, we should keep the
checking of sink_count.

Regards,
CK

> 
> BRs,
> Bo-Chen
> 
> > > +	if (ret < 1) {
> > > +		drm_err(mtk_dp->drm_dev, "Read sink count failed\n");
> > > +		return;
> > > +	}
> > > +
> > > +	drm_dbg(mtk_dp->drm_dev,
> > > +		"read sink count from dpcd: %d\n", sink_count);
> > > +
> > > +	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)
> > > +		drm_dp_dpcd_writeb(&mtk_dp->aux,
> > > DP_DEVICE_SERVICE_IRQ_VECTOR,
> > > +				   DP_REMOTE_CONTROL_COMMAND_PENDING);
> > > +}
> > > +
> > 
> > 
> 
> 


WARNING: multiple messages have this Message-ID (diff)
From: CK Hu <ck.hu@mediatek.com>
To: Rex-BC Chen <rex-bc.chen@mediatek.com>,
	"chunkuang.hu@kernel.org" <chunkuang.hu@kernel.org>,
	"p.zabel@pengutronix.de" <p.zabel@pengutronix.de>,
	 "daniel@ffwll.ch" <daniel@ffwll.ch>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"krzysztof.kozlowski+dt@linaro.org"
	<krzysztof.kozlowski+dt@linaro.org>,
	"mripard@kernel.org" <mripard@kernel.org>,
	"tzimmermann@suse.de" <tzimmermann@suse.de>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
	"deller@gmx.de" <deller@gmx.de>,
	"airlied@linux.ie" <airlied@linux.ie>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	"granquet@baylibre.com" <granquet@baylibre.com>,
	"Jitao Shi (石记涛)" <jitao.shi@mediatek.com>,
	"LiangXu Xu (徐亮)" <LiangXu.Xu@mediatek.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"msp@baylibre.com" <msp@baylibre.com>,
	Project_Global_Chrome_Upstream_Group
	<Project_Global_Chrome_Upstream_Group@mediatek.com>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"wenst@chromium.org" <wenst@chromium.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"angelogioacchino.delregno@collabora.com"
	<angelogioacchino.delregno@collabora.com>
Subject: Re: [PATCH v14 05/10] drm/mediatek: Add MT8195 Embedded DisplayPort driver
Date: Thu, 21 Jul 2022 14:24:58 +0800	[thread overview]
Message-ID: <4e543dc3a183af3966aa6f2f28b0afb9d95cbac2.camel@mediatek.com> (raw)
In-Reply-To: <7b1a555ab62aec8c3f5717b8827c81a2076bf569.camel@mediatek.com>

Hi, Rex:

On Thu, 2022-07-21 at 10:38 +0800, Rex-BC Chen wrote:
> On Fri, 2022-07-15 at 16:51 +0800, CK Hu wrote:
> > Hi, Bo-Chen:
> > 
> > On Tue, 2022-07-12 at 19:12 +0800, Bo-Chen Chen wrote:
> > > From: Markus Schneider-Pargmann <msp@baylibre.com>
> > > 
> > > 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 <jitao.shi@mediatek.com>
> > > 
> > > Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
> > > Signed-off-by: Guillaume Ranquet <granquet@baylibre.com>
> > > Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
> > > ---
> > 
> > [snip]
> > 
> > > +static void mtk_dp_hpd_sink_event(struct mtk_dp *mtk_dp)
> > > +{
> > > +	ssize_t ret;
> > > +	u8 sink_count;
> > > +	u8 link_status[DP_LINK_STATUS_SIZE] = {};
> > > +	u32 sink_count_reg = DP_SINK_COUNT_ESI;
> > > +	u32 link_status_reg = DP_LANE0_1_STATUS;
> > > +
> > > +	ret = drm_dp_dpcd_readb(&mtk_dp->aux, sink_count_reg,
> > > &sink_count);
> > 
> > According to your last reply, if drm_dp_dpcd_readb() fail, we could
> > skip below statement. So this just for error checking? If so, the
> > next
> > drm_dp_dpcd_read() would also do the error checking, so the
> > checking
> > here is redundant.
> > 
> > Regards,
> > CK
> > 
> 
> Hello CK,
> 
> sorry, I don't get your point.
> We use "drm_dp_dpcd_readb(&mtk_dp->aux, sink_count_reg, &sink_count)"
> to get sink count and use "drm_dp_dpcd_read(&mtk_dp->aux,
> link_status_reg, link_status, sizeof(link_status));" to get link
> status.
> 
> If we don't get any sink count, we don't need to check the link
> status.
> Therefore, we just return if we are failed to get sink count.

I assume that when error happen, both read sink_count and read
link_status would fail, so you could directly read link_status. Do you
think that when error happen, only read sink_count would fail and read
link_status would success? It it is the later case, we should keep the
checking of sink_count.

Regards,
CK

> 
> BRs,
> Bo-Chen
> 
> > > +	if (ret < 1) {
> > > +		drm_err(mtk_dp->drm_dev, "Read sink count failed\n");
> > > +		return;
> > > +	}
> > > +
> > > +	drm_dbg(mtk_dp->drm_dev,
> > > +		"read sink count from dpcd: %d\n", sink_count);
> > > +
> > > +	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)
> > > +		drm_dp_dpcd_writeb(&mtk_dp->aux,
> > > DP_DEVICE_SERVICE_IRQ_VECTOR,
> > > +				   DP_REMOTE_CONTROL_COMMAND_PENDING);
> > > +}
> > > +
> > 
> > 
> 
> 


WARNING: multiple messages have this Message-ID (diff)
From: CK Hu <ck.hu@mediatek.com>
To: Rex-BC Chen <rex-bc.chen@mediatek.com>,
	"chunkuang.hu@kernel.org" <chunkuang.hu@kernel.org>,
	"p.zabel@pengutronix.de" <p.zabel@pengutronix.de>,
	"daniel@ffwll.ch" <daniel@ffwll.ch>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"krzysztof.kozlowski+dt@linaro.org"
	<krzysztof.kozlowski+dt@linaro.org>,
	"mripard@kernel.org" <mripard@kernel.org>,
	"tzimmermann@suse.de" <tzimmermann@suse.de>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
	"deller@gmx.de" <deller@gmx.de>,
	"airlied@linux.ie" <airlied@linux.ie>
Cc: "msp@baylibre.com" <msp@baylibre.com>,
	"granquet@baylibre.com" <granquet@baylibre.com>,
	"Jitao Shi (石记涛)" <jitao.shi@mediatek.com>,
	"wenst@chromium.org" <wenst@chromium.org>,
	"angelogioacchino.delregno@collabora.com"
	<angelogioacchino.delregno@collabora.com>,
	"LiangXu Xu (徐亮)" <LiangXu.Xu@mediatek.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	Project_Global_Chrome_Upstream_Group
	<Project_Global_Chrome_Upstream_Group@mediatek.com>
Subject: Re: [PATCH v14 05/10] drm/mediatek: Add MT8195 Embedded DisplayPort driver
Date: Thu, 21 Jul 2022 14:24:58 +0800	[thread overview]
Message-ID: <4e543dc3a183af3966aa6f2f28b0afb9d95cbac2.camel@mediatek.com> (raw)
In-Reply-To: <7b1a555ab62aec8c3f5717b8827c81a2076bf569.camel@mediatek.com>

Hi, Rex:

On Thu, 2022-07-21 at 10:38 +0800, Rex-BC Chen wrote:
> On Fri, 2022-07-15 at 16:51 +0800, CK Hu wrote:
> > Hi, Bo-Chen:
> > 
> > On Tue, 2022-07-12 at 19:12 +0800, Bo-Chen Chen wrote:
> > > From: Markus Schneider-Pargmann <msp@baylibre.com>
> > > 
> > > 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 <jitao.shi@mediatek.com>
> > > 
> > > Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
> > > Signed-off-by: Guillaume Ranquet <granquet@baylibre.com>
> > > Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
> > > ---
> > 
> > [snip]
> > 
> > > +static void mtk_dp_hpd_sink_event(struct mtk_dp *mtk_dp)
> > > +{
> > > +	ssize_t ret;
> > > +	u8 sink_count;
> > > +	u8 link_status[DP_LINK_STATUS_SIZE] = {};
> > > +	u32 sink_count_reg = DP_SINK_COUNT_ESI;
> > > +	u32 link_status_reg = DP_LANE0_1_STATUS;
> > > +
> > > +	ret = drm_dp_dpcd_readb(&mtk_dp->aux, sink_count_reg,
> > > &sink_count);
> > 
> > According to your last reply, if drm_dp_dpcd_readb() fail, we could
> > skip below statement. So this just for error checking? If so, the
> > next
> > drm_dp_dpcd_read() would also do the error checking, so the
> > checking
> > here is redundant.
> > 
> > Regards,
> > CK
> > 
> 
> Hello CK,
> 
> sorry, I don't get your point.
> We use "drm_dp_dpcd_readb(&mtk_dp->aux, sink_count_reg, &sink_count)"
> to get sink count and use "drm_dp_dpcd_read(&mtk_dp->aux,
> link_status_reg, link_status, sizeof(link_status));" to get link
> status.
> 
> If we don't get any sink count, we don't need to check the link
> status.
> Therefore, we just return if we are failed to get sink count.

I assume that when error happen, both read sink_count and read
link_status would fail, so you could directly read link_status. Do you
think that when error happen, only read sink_count would fail and read
link_status would success? It it is the later case, we should keep the
checking of sink_count.

Regards,
CK

> 
> BRs,
> Bo-Chen
> 
> > > +	if (ret < 1) {
> > > +		drm_err(mtk_dp->drm_dev, "Read sink count failed\n");
> > > +		return;
> > > +	}
> > > +
> > > +	drm_dbg(mtk_dp->drm_dev,
> > > +		"read sink count from dpcd: %d\n", sink_count);
> > > +
> > > +	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)
> > > +		drm_dp_dpcd_writeb(&mtk_dp->aux,
> > > DP_DEVICE_SERVICE_IRQ_VECTOR,
> > > +				   DP_REMOTE_CONTROL_COMMAND_PENDING);
> > > +}
> > > +
> > 
> > 
> 
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-07-21  6:25 UTC|newest]

Thread overview: 150+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-12 11:12 [PATCH v14 00/10] drm/mediatek: Add MT8195 DisplayPort driver Bo-Chen Chen
2022-07-12 11:12 ` Bo-Chen Chen
2022-07-12 11:12 ` Bo-Chen Chen
2022-07-12 11:12 ` [PATCH v14 01/10] dt-bindings: mediatek,dp: Add Display Port binding Bo-Chen Chen
2022-07-12 11:12   ` Bo-Chen Chen
2022-07-12 11:12   ` Bo-Chen Chen
2022-07-13  7:56   ` CK Hu
2022-07-13  7:56     ` CK Hu
2022-07-13  7:56     ` CK Hu
2022-07-26  6:18     ` Rex-BC Chen
2022-07-26  6:18       ` Rex-BC Chen
2022-07-26  6:18       ` Rex-BC Chen
2022-07-26  8:46       ` CK Hu
2022-07-26  8:46         ` CK Hu
2022-07-26  8:46         ` CK Hu
2022-07-18 20:21   ` Rob Herring
2022-07-18 20:21     ` Rob Herring
2022-07-18 20:21     ` Rob Herring
2022-07-12 11:12 ` [PATCH v14 02/10] drm/edid: Convert cea_sad helper struct to kernelDoc Bo-Chen Chen
2022-07-12 11:12   ` Bo-Chen Chen
2022-07-12 11:12   ` Bo-Chen Chen
2022-07-12 11:12 ` [PATCH v14 03/10] drm/edid: Add cea_sad helpers for freq/length Bo-Chen Chen
2022-07-12 11:12   ` Bo-Chen Chen
2022-07-12 11:12   ` Bo-Chen Chen
2022-07-14 11:12   ` AngeloGioacchino Del Regno
2022-07-14 11:12     ` AngeloGioacchino Del Regno
2022-07-14 11:12     ` AngeloGioacchino Del Regno
2022-07-14 11:19     ` Rex-BC Chen
2022-07-14 11:19       ` Rex-BC Chen
2022-07-14 11:19       ` Rex-BC Chen
2022-07-12 11:12 ` [PATCH v14 04/10] video/hdmi: Add audio_infoframe packing for DP Bo-Chen Chen
2022-07-12 11:12   ` Bo-Chen Chen
2022-07-12 11:12   ` Bo-Chen Chen
2022-07-14 11:26   ` AngeloGioacchino Del Regno
2022-07-14 11:26     ` AngeloGioacchino Del Regno
2022-07-14 11:26     ` AngeloGioacchino Del Regno
2022-07-12 11:12 ` [PATCH v14 05/10] drm/mediatek: Add MT8195 Embedded DisplayPort driver Bo-Chen Chen
2022-07-12 11:12   ` Bo-Chen Chen
2022-07-12 11:12   ` Bo-Chen Chen
2022-07-13  8:03   ` CK Hu
2022-07-13  8:03     ` CK Hu
2022-07-13  8:03     ` CK Hu
2022-07-13  8:10   ` CK Hu
2022-07-13  8:10     ` CK Hu
2022-07-13  8:10     ` CK Hu
2022-07-14  8:24     ` Rex-BC Chen
2022-07-14  8:24       ` Rex-BC Chen
2022-07-14  8:24       ` Rex-BC Chen
2022-07-14 10:21       ` CK Hu
2022-07-14 10:21         ` CK Hu
2022-07-14 10:21         ` CK Hu
2022-07-13  8:22   ` CK Hu
2022-07-13  8:22     ` CK Hu
2022-07-13  8:22     ` CK Hu
2022-07-13  8:30   ` CK Hu
2022-07-13  8:30     ` CK Hu
2022-07-13  8:30     ` CK Hu
2022-07-13  9:12   ` CK Hu
2022-07-13  9:12     ` CK Hu
2022-07-13  9:12     ` CK Hu
2022-07-13  9:31   ` CK Hu
2022-07-13  9:31     ` CK Hu
2022-07-13  9:31     ` CK Hu
2022-07-14  8:52     ` Rex-BC Chen
2022-07-14  8:52       ` Rex-BC Chen
2022-07-14  8:52       ` Rex-BC Chen
2022-07-13  9:33   ` CK Hu
2022-07-13  9:33     ` CK Hu
2022-07-13  9:33     ` CK Hu
2022-07-14  8:57     ` Rex-BC Chen
2022-07-14  8:57       ` Rex-BC Chen
2022-07-14  8:57       ` Rex-BC Chen
2022-07-13  9:45   ` CK Hu
2022-07-13  9:45     ` CK Hu
2022-07-13  9:45     ` CK Hu
2022-07-14  6:51   ` CK Hu
2022-07-14  6:51     ` CK Hu
2022-07-14  6:51     ` CK Hu
2022-07-14  9:09     ` Rex-BC Chen
2022-07-14  9:09       ` Rex-BC Chen
2022-07-14  9:09       ` Rex-BC Chen
2022-07-14 10:34       ` CK Hu
2022-07-14 10:34         ` CK Hu
2022-07-14 10:34         ` CK Hu
2022-07-14  7:06   ` CK Hu
2022-07-14  7:06     ` CK Hu
2022-07-14  7:06     ` CK Hu
2022-07-15  8:51   ` CK Hu
2022-07-15  8:51     ` CK Hu
2022-07-15  8:51     ` CK Hu
2022-07-21  2:38     ` Rex-BC Chen
2022-07-21  2:38       ` Rex-BC Chen
2022-07-21  2:38       ` Rex-BC Chen
2022-07-21  6:24       ` CK Hu [this message]
2022-07-21  6:24         ` CK Hu
2022-07-21  6:24         ` CK Hu
2022-07-15  9:13   ` CK Hu
2022-07-15  9:13     ` CK Hu
2022-07-15  9:13     ` CK Hu
2022-07-15  9:14   ` CK Hu
2022-07-15  9:14     ` CK Hu
2022-07-15  9:14     ` CK Hu
2022-07-15  9:37   ` CK Hu
2022-07-15  9:37     ` CK Hu
2022-07-15  9:37     ` CK Hu
2022-07-15 18:01   ` kernel test robot
2022-07-15 18:01     ` kernel test robot
2022-07-15 18:01     ` kernel test robot
2022-07-25  9:16   ` CK Hu
2022-07-25  9:16     ` CK Hu
2022-07-25  9:16     ` CK Hu
2022-07-26  6:42     ` Rex-BC Chen
2022-07-26  6:42       ` Rex-BC Chen
2022-07-26  6:42       ` Rex-BC Chen
2022-07-26  9:34       ` CK Hu
2022-07-26  9:34         ` CK Hu
2022-07-26  9:34         ` CK Hu
2022-07-26 10:06         ` Rex-BC Chen
2022-07-26 10:06           ` Rex-BC Chen
2022-07-26 10:06           ` Rex-BC Chen
2022-07-25  9:23   ` CK Hu
2022-07-25  9:23     ` CK Hu
2022-07-25  9:23     ` CK Hu
2022-07-26  3:30     ` Rex-BC Chen
2022-07-26  3:30       ` Rex-BC Chen
2022-07-26  3:30       ` Rex-BC Chen
2022-07-26  8:37       ` CK Hu
2022-07-26  8:37         ` CK Hu
2022-07-26  8:37         ` CK Hu
2022-07-12 11:12 ` [PATCH v14 06/10] drm/mediatek: Add MT8195 External DisplayPort support Bo-Chen Chen
2022-07-12 11:12   ` Bo-Chen Chen
2022-07-12 11:12   ` Bo-Chen Chen
2022-07-25  9:51   ` CK Hu
2022-07-25  9:51     ` CK Hu
2022-07-25  9:51     ` CK Hu
2022-07-12 11:12 ` [PATCH v14 07/10] drm/mediatek: add hpd debounce Bo-Chen Chen
2022-07-12 11:12   ` Bo-Chen Chen
2022-07-12 11:12   ` Bo-Chen Chen
2022-07-12 11:12 ` [PATCH v14 08/10] drm/mediatek: set monitor to DP_SET_POWER_D3 to avoid garbage Bo-Chen Chen
2022-07-12 11:12   ` Bo-Chen Chen
2022-07-12 11:12   ` Bo-Chen Chen
2022-07-12 11:12 ` [PATCH v14 09/10] drm/mediatek: DP audio support for MT8195 Bo-Chen Chen
2022-07-12 11:12   ` Bo-Chen Chen
2022-07-12 11:12   ` Bo-Chen Chen
2022-07-14 11:43   ` AngeloGioacchino Del Regno
2022-07-14 11:43     ` AngeloGioacchino Del Regno
2022-07-14 11:43     ` AngeloGioacchino Del Regno
2022-07-12 11:12 ` [PATCH v14 10/10] drm/mediatek: Use cached audio config when changing resolution Bo-Chen Chen
2022-07-12 11:12   ` Bo-Chen Chen
2022-07-12 11:12   ` Bo-Chen Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4e543dc3a183af3966aa6f2f28b0afb9d95cbac2.camel@mediatek.com \
    --to=ck.hu@mediatek.com \
    --cc=LiangXu.Xu@mediatek.com \
    --cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
    --cc=airlied@linux.ie \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=chunkuang.hu@kernel.org \
    --cc=daniel@ffwll.ch \
    --cc=deller@gmx.de \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=granquet@baylibre.com \
    --cc=jitao.shi@mediatek.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=mripard@kernel.org \
    --cc=msp@baylibre.com \
    --cc=p.zabel@pengutronix.de \
    --cc=rex-bc.chen@mediatek.com \
    --cc=robh+dt@kernel.org \
    --cc=tzimmermann@suse.de \
    --cc=wenst@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.