All of lore.kernel.org
 help / color / mirror / Atom feed
From: AngeloGioacchino Del Regno  <angelogioacchino.delregno@collabora.com>
To: Guillaume Ranquet <granquet@baylibre.com>,
	airlied@linux.ie, chunfeng.yun@mediatek.com,
	chunkuang.hu@kernel.org, ck.hu@mediatek.com, daniel@ffwll.ch,
	deller@gmx.de, jitao.shi@mediatek.com, kishon@ti.com,
	krzk+dt@kernel.org, maarten.lankhorst@linux.intel.com,
	matthias.bgg@gmail.com, mripard@kernel.org,
	p.zabel@pengutronix.de, robh+dt@kernel.org, tzimmermann@suse.de,
	vkoul@kernel.org
Cc: devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mediatek@lists.infradead.org,
	linux-phy@lists.infradead.org, markyacoub@google.com,
	Markus Schneider-Pargmann <msp@baylibre.com>,
	kernel test robot <lkp@intel.com>
Subject: Re: [PATCH v9 18/22] drm/mediatek: Add mt8195 Embedded DisplayPort driver
Date: Mon, 28 Mar 2022 11:14:23 +0200	[thread overview]
Message-ID: <9a31c1ce-829b-acc7-6fc1-2a9df45e5c38@collabora.com> (raw)
In-Reply-To: <20220327223927.20848-19-granquet@baylibre.com>

Il 28/03/22 00:39, Guillaume Ranquet ha scritto:
> From: Markus Schneider-Pargmann <msp@baylibre.com>
> 
> 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 shares its iomap range with the mtk-dp-phy driver using
> the regmap/syscon facility.
> 
> This driver is based on an initial version by
> Jason-JH.Lin <jason-jh.lin@mediatek.com>.
> 
> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
> Signed-off-by: Guillaume Ranquet <granquet@baylibre.com>
> Reported-by: kernel test robot <lkp@intel.com>

Hello Guillaume,
as you know, there's some more work to do on this driver.

I will also mention here, not on the code, that at this point, your
mtk_dp_aux_transfer() function has something VERY similar to function
drm_dp_dpcd_access(), so I really believe that you can instead use
functions drm_dp_dpcd_read() and drm_dp_dpcd_write(), avoiding code
duplication around.

Please check drivers/gpu/drm/dp/drm_dp.c.

> ---
>   drivers/gpu/drm/mediatek/Kconfig       |    8 +
>   drivers/gpu/drm/mediatek/Makefile      |    2 +
>   drivers/gpu/drm/mediatek/mtk_dp.c      | 2221 ++++++++++++++++++++++++
>   drivers/gpu/drm/mediatek/mtk_dp_reg.h  |  568 ++++++
>   drivers/gpu/drm/mediatek/mtk_drm_drv.c |    1 +
>   drivers/gpu/drm/mediatek/mtk_drm_drv.h |    1 +
>   6 files changed, 2801 insertions(+)
>   create mode 100644 drivers/gpu/drm/mediatek/mtk_dp.c
>   create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_reg.h
> 
> diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
> index 2976d21e9a34..03ffa9b896c3 100644
> --- a/drivers/gpu/drm/mediatek/Kconfig
> +++ b/drivers/gpu/drm/mediatek/Kconfig
> @@ -28,3 +28,11 @@ config DRM_MEDIATEK_HDMI
>   	select PHY_MTK_HDMI
>   	help
>   	  DRM/KMS HDMI driver for Mediatek SoCs
> +
> +config MTK_DPTX_SUPPORT

Actually, I think that the best would be DRM_MEDIATEK_DP_TX or DRM_MEDIATEK_DP...
...also, ordering is important, please!

> +	tristate "DRM DPTX Support for Mediatek SoCs"
> +	depends on DRM_MEDIATEK
> +	select PHY_MTK_DP
> +	select DRM_DP_HELPER
> +	help
> +	  DRM/KMS Display Port driver for Mediatek SoCs.
> diff --git a/drivers/gpu/drm/mediatek/Makefile b/drivers/gpu/drm/mediatek/Makefile
> index 29098d7c8307..d86a6406055e 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -21,3 +21,5 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
>   			  mtk_hdmi_ddc.o
>   
>   obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
> +
> +obj-$(CONFIG_MTK_DPTX_SUPPORT) += mtk_dp.o
> diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
> new file mode 100644
> index 000000000000..7cd8459cf719
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
> @@ -0,0 +1,2221 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 MediaTek Inc.
> + * Copyright (c) 2021 BayLibre
> + */
> +
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_bridge.h>
> +#include <drm/drm_crtc.h>
> +#include <drm/dp/drm_dp_helper.h>
> +#include <drm/drm_edid.h>
> +#include <drm/drm_of.h>
> +#include <drm/drm_panel.h>
> +#include <drm/drm_print.h>
> +#include <drm/drm_probe_helper.h>
> +#include <linux/arm-smccc.h>
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/errno.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/nvmem-consumer.h>
> +#include <linux/of.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +#include <sound/hdmi-codec.h>
> +#include <video/videomode.h>
> +
> +#include "mtk_dp_reg.h"
> +
> +#define MTK_DP_AUX_WAIT_REPLY_COUNT 20
> +#define MTK_DP_CHECK_SINK_CAP_TIMEOUT_COUNT 3
> +
> +//TODO: platform/device data or dts?

Assuming that your TODO is about the maximum number of lanes,
{ .compatible = "mediatek,mt8195-edp-tx", .data = &some_const_structure },

> +#define MTK_DP_MAX_LANES 4
> +#define MTK_DP_MAX_LINK_RATE MTK_DP_LINKRATE_HBR3

..snip..

> +
> +static int mtk_dp_bulk_16bit_write(struct mtk_dp *mtk_dp, u32 offset, u8 *buf,
> +				   size_t length)
> +{
> +	int i;
> +	int ret = 0;
> +	int num_regs = (length + 1) / 2;
> +
> +	/* 2 bytes per register */
> +	for (i = 0; i < num_regs; i++) {
> +		u32 val = buf[i * 2] |
> +			  (i * 2 + 1 < length ? buf[i * 2 + 1] << 8 : 0);
> +
> +		ret = mtk_dp_write(mtk_dp, offset + i * 4, val);
> +		if (ret)
> +			goto out;

if (ret)
     return ret;

> +	}
> +
> +out:

Remove this label.

> +	return ret;
> +}
> +
> +static unsigned long mtk_dp_sip_atf_call(unsigned int cmd, unsigned int para)
> +{
> +	struct arm_smccc_res res;
> +
> +	arm_smccc_smc(MTK_DP_SIP_CONTROL_AARCH32, cmd, para, 0, 0, 0, 0, 0,
> +		      &res);
> +
> +	pr_debug("[DPTX]%s cmd 0x%x, p1 0x%x, ret 0x%lx-0x%lx", __func__, cmd,
> +		 para, res.a0, res.a1);
> +	return res.a1;
> +}
> +
> +static int mtk_dp_msa_bypass_disable(struct mtk_dp *mtk_dp)
> +{
> +	const u16 bits_to_set =
> +		BIT(HTOTAL_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(VTOTAL_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(HSTART_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(VSTART_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(HWIDTH_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(VHEIGHT_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(HSP_SEL_DP_ENC0_P0_SHIFT) | BIT(HSW_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(VSP_SEL_DP_ENC0_P0_SHIFT) | BIT(VSW_SEL_DP_ENC0_P0_SHIFT);
> +	return mtk_dp_update_bits(mtk_dp, MTK_DP_ENC0_P0_3030, bits_to_set,
> +			   bits_to_set);
> +}
> +
> +#define MTK_UPD_BITS_OR_OUT(mtk_dp, offset, val, mask, ret, label) \
> +	do {\
> +		ret = mtk_dp_update_bits(mtk_dp, offset, val, mask); \
> +		if (ret) \
> +			goto label; \
> +	} while (0)

I'm sorry, no offense - but this macro is a bit ugly...

I think I understand why you have introduced it, but in my opinion this decreases
human readability a lot, I was even about to point out multiple functions that
you had unused labels before checking this macro, as that was totally unexpected...

In my opinion, this should be open-coded everywhere... yes it makes the file a
bit fatter in terms of amount of text, but eh... it's life :)))


> +

....snip....

> +
> +static int mtk_dp_set_color_format(struct mtk_dp *mtk_dp,
> +				   enum mtk_dp_color_format color_format)
> +{
> +	u32 val;
> +	int ret;
> +
> +	mtk_dp->info.format = color_format;
> +
> +	/* Update MISC0 */
> +	ret = mtk_dp_update_bits(mtk_dp, MTK_DP_ENC0_P0_3034,
> +				 color_format << DP_TEST_COLOR_FORMAT_SHIFT,
> +			   DP_TEST_COLOR_FORMAT_MASK);
> +
> +	if (ret)
> +		return ret;
> +
> +	switch (color_format) {
> +	case MTK_DP_COLOR_FORMAT_YUV_422:
> +		val = PIXEL_ENCODE_FORMAT_DP_ENC0_P0_YCBCR422;
> +		break;
> +	case MTK_DP_COLOR_FORMAT_YUV_420:
> +		val = PIXEL_ENCODE_FORMAT_DP_ENC0_P0_YCBCR420;
> +		break;
> +	case MTK_DP_COLOR_FORMAT_YONLY:
> +	case MTK_DP_COLOR_FORMAT_RAW:
> +	case MTK_DP_COLOR_FORMAT_RESERVED:
> +	case MTK_DP_COLOR_FORMAT_UNKNOWN:
> +		drm_warn(mtk_dp->drm_dev, "Unsupported color format: %d\n",
> +			 color_format);
> +		fallthrough;

Uhm, are you sure that you should fallthrough?
If we get a color format that we don't understand, the best thing that would
happen is that we'd get scrambled colors... which is something unwanted.

The best idea is to return -EINVAL here, hence refuse to go on with an invalid
color format.

> +	case MTK_DP_COLOR_FORMAT_RGB_444:
> +	case MTK_DP_COLOR_FORMAT_YUV_444:
> +		val = PIXEL_ENCODE_FORMAT_DP_ENC0_P0_RGB;
> +		break;
> +	}
> +
> +	return mtk_dp_update_bits(mtk_dp, MTK_DP_ENC0_P0_303C, val,
> +			   PIXEL_ENCODE_FORMAT_DP_ENC0_P0_MASK);
> +}
> +

...snip...

> +
> +static void mtk_dp_initialize_hpd_detect_settings(struct mtk_dp *mtk_dp)
> +{
> +	// Debounce threshold

I think I already told you to fix comments style.

> +	mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3410,
> +			   8 << HPD_DEB_THD_DP_TRANS_P0_SHIFT,
> +			   HPD_DEB_THD_DP_TRANS_P0_MASK);
> +	mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3410,
> +			   (HPD_INT_THD_DP_TRANS_P0_LOWER_500US |
> +			    HPD_INT_THD_DP_TRANS_P0_UPPER_1100US)
> +				   << HPD_INT_THD_DP_TRANS_P0_SHIFT,
> +			   HPD_INT_THD_DP_TRANS_P0_MASK);
> +
> +	// Connect threshold 1.5ms + 5 x 0.1ms = 2ms
> +	// Disconnect threshold 1.5ms + 5 x 0.1ms = 2ms
> +	mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3410,
> +			   (5 << HPD_DISC_THD_DP_TRANS_P0_SHIFT) |
> +				   (5 << HPD_CONN_THD_DP_TRANS_P0_SHIFT),
> +			   HPD_DISC_THD_DP_TRANS_P0_MASK |
> +				   HPD_CONN_THD_DP_TRANS_P0_MASK);
> +	mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3430,
> +			   HPD_INT_THD_ECO_DP_TRANS_P0_HIGH_BOUND_EXT,
> +			   HPD_INT_THD_ECO_DP_TRANS_P0_MASK);
> +}
> +

..snip..

> +
> +static int mtk_dp_power_disable(struct mtk_dp *mtk_dp)
> +{
> +	int ret;
> +
> +	ret = mtk_dp_write(mtk_dp, MTK_DP_TOP_PWR_STATE, 0);
> +
> +	if (ret)
> +		goto out;
> +
> +	usleep_range(10, 200);
> +	ret = mtk_dp_write(mtk_dp, MTK_DP_0034,
> +			   DA_CKM_CKTX0_EN_FORCE_EN | DA_CKM_BIAS_LPF_EN_FORCE_VAL |
> +		     DA_CKM_BIAS_EN_FORCE_VAL |
> +		     DA_XTP_GLB_LDO_EN_FORCE_VAL |
> +		     DA_XTP_GLB_AVD10_ON_FORCE_VAL);
> +
> +	if (ret)
> +		goto out;
> +
> +	/* Disable RX */
> +	ret = mtk_dp_write(mtk_dp, MTK_DP_1040, 0);
> +
> +	if (ret)
> +		goto out;
> +
> +	ret = mtk_dp_write(mtk_dp, MTK_DP_TOP_MEM_PD,
> +			   0x550 | BIT(FUSE_SEL_SHIFT) | BIT(MEM_ISO_EN_SHIFT));
> +
> +out:

You are using a goto instead of a return, but you're not reverting any change,
so this goto usage is not justified - hence, wrong.

Please simply return ret when anything fails, and return 0 at the end of this
function.

	.......
	(blahblah function code)

	ret = something()
	if (ret)
		return ret;

	return 0;
}

> +	return ret;
> +}
> +

...snip...

> +
> +static int mtk_dp_dt_parse(struct mtk_dp *mtk_dp,
> +			   struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	int ret = 0;
> +	void __iomem *base;
> +
> +	base = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(base))
> +		return PTR_ERR(base);
> +
> +	mtk_dp->regs = syscon_node_to_regmap(dev->of_node);
> +	if (IS_ERR(mtk_dp->regs))
> +		return PTR_ERR(mtk_dp->regs);
> +
> +	//TODO: optional clock?

Well, if it's optional, you should use devm_clk_get_optional(), meaning
that......

> +	mtk_dp->dp_tx_clk = devm_clk_get(dev, "faxi");
> +	if (IS_ERR(mtk_dp->dp_tx_clk)) {
> +		ret = PTR_ERR(mtk_dp->dp_tx_clk);
> +		dev_info(dev, "Failed to get dptx clock: %d\n", ret);
> +		mtk_dp->dp_tx_clk = NULL;

...I shouldn't see this snippet of code, as it should be a bit different... :)

> +	}
> +
> +	return 0;
> +}
> +

..snip..

> +static void mtk_dp_bridge_atomic_disable(struct drm_bridge *bridge,
> +					 struct drm_bridge_state *old_state)
> +{
> +	struct mtk_dp *mtk_dp = mtk_dp_from_bridge(bridge);
> +
> +	mtk_dp_video_mute(mtk_dp, true);
> +	mtk_dp->state = MTK_DP_STATE_IDLE;
> +	mtk_dp->train_state = MTK_DP_TRAIN_STATE_STARTUP;
> +
> +	mtk_dp->enabled = false;

> +	msleep(100);

100 milliseconds is an eternity, why are we sleeping for *so long* here?

Please, either add a comment that fully explains the resons for that, or
remove the sleep entirely: to my eyes, it doesn't look like this sleep is
really needed for anything important because here you are disabling the
bridge and *powering off* the IP entirely.

> +	mtk_dp_poweroff(mtk_dp);
> +}
> +

..snip..

> +
> +static enum drm_mode_status
> +mtk_dp_bridge_mode_valid(struct drm_bridge *bridge,
> +			 const struct drm_display_info *info,
> +			 const struct drm_display_mode *mode)
> +{
> +	struct mtk_dp *mtk_dp = mtk_dp_from_bridge(bridge);
> +	u32 rx_linkrate = (u32)mtk_dp->train_info.link_rate * 27000;
> +	u32 bpp = info->color_formats & DRM_COLOR_FORMAT_YCBCR422 ? 16 : 24;
> +
> +	if (rx_linkrate * mtk_dp->train_info.lane_count < mode->clock * bpp / 8)
> +		return MODE_CLOCK_HIGH;
> +
> +	if (mode->clock > 600000)
> +		return MODE_CLOCK_HIGH;
> +
> +	//TODO: explain magic number: 62?

Please fix this TODO for v10.

> +	if ((mode->clock * 1000) / (mode->htotal * mode->vtotal) > 62)
> +		return MODE_CLOCK_HIGH;
> +
> +	return MODE_OK;
> +}
> +



WARNING: multiple messages have this Message-ID (diff)
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Guillaume Ranquet <granquet@baylibre.com>,
	airlied@linux.ie, chunfeng.yun@mediatek.com,
	chunkuang.hu@kernel.org, ck.hu@mediatek.com, daniel@ffwll.ch,
	deller@gmx.de, jitao.shi@mediatek.com, kishon@ti.com,
	krzk+dt@kernel.org, maarten.lankhorst@linux.intel.com,
	matthias.bgg@gmail.com, mripard@kernel.org,
	p.zabel@pengutronix.de, robh+dt@kernel.org, tzimmermann@suse.de,
	vkoul@kernel.org
Cc: devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mediatek@lists.infradead.org,
	linux-phy@lists.infradead.org, markyacoub@google.com,
	Markus Schneider-Pargmann <msp@baylibre.com>,
	kernel test robot <lkp@intel.com>
Subject: Re: [PATCH v9 18/22] drm/mediatek: Add mt8195 Embedded DisplayPort driver
Date: Mon, 28 Mar 2022 11:14:23 +0200	[thread overview]
Message-ID: <9a31c1ce-829b-acc7-6fc1-2a9df45e5c38@collabora.com> (raw)
In-Reply-To: <20220327223927.20848-19-granquet@baylibre.com>

Il 28/03/22 00:39, Guillaume Ranquet ha scritto:
> From: Markus Schneider-Pargmann <msp@baylibre.com>
> 
> 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 shares its iomap range with the mtk-dp-phy driver using
> the regmap/syscon facility.
> 
> This driver is based on an initial version by
> Jason-JH.Lin <jason-jh.lin@mediatek.com>.
> 
> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
> Signed-off-by: Guillaume Ranquet <granquet@baylibre.com>
> Reported-by: kernel test robot <lkp@intel.com>

Hello Guillaume,
as you know, there's some more work to do on this driver.

I will also mention here, not on the code, that at this point, your
mtk_dp_aux_transfer() function has something VERY similar to function
drm_dp_dpcd_access(), so I really believe that you can instead use
functions drm_dp_dpcd_read() and drm_dp_dpcd_write(), avoiding code
duplication around.

Please check drivers/gpu/drm/dp/drm_dp.c.

> ---
>   drivers/gpu/drm/mediatek/Kconfig       |    8 +
>   drivers/gpu/drm/mediatek/Makefile      |    2 +
>   drivers/gpu/drm/mediatek/mtk_dp.c      | 2221 ++++++++++++++++++++++++
>   drivers/gpu/drm/mediatek/mtk_dp_reg.h  |  568 ++++++
>   drivers/gpu/drm/mediatek/mtk_drm_drv.c |    1 +
>   drivers/gpu/drm/mediatek/mtk_drm_drv.h |    1 +
>   6 files changed, 2801 insertions(+)
>   create mode 100644 drivers/gpu/drm/mediatek/mtk_dp.c
>   create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_reg.h
> 
> diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
> index 2976d21e9a34..03ffa9b896c3 100644
> --- a/drivers/gpu/drm/mediatek/Kconfig
> +++ b/drivers/gpu/drm/mediatek/Kconfig
> @@ -28,3 +28,11 @@ config DRM_MEDIATEK_HDMI
>   	select PHY_MTK_HDMI
>   	help
>   	  DRM/KMS HDMI driver for Mediatek SoCs
> +
> +config MTK_DPTX_SUPPORT

Actually, I think that the best would be DRM_MEDIATEK_DP_TX or DRM_MEDIATEK_DP...
...also, ordering is important, please!

> +	tristate "DRM DPTX Support for Mediatek SoCs"
> +	depends on DRM_MEDIATEK
> +	select PHY_MTK_DP
> +	select DRM_DP_HELPER
> +	help
> +	  DRM/KMS Display Port driver for Mediatek SoCs.
> diff --git a/drivers/gpu/drm/mediatek/Makefile b/drivers/gpu/drm/mediatek/Makefile
> index 29098d7c8307..d86a6406055e 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -21,3 +21,5 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
>   			  mtk_hdmi_ddc.o
>   
>   obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
> +
> +obj-$(CONFIG_MTK_DPTX_SUPPORT) += mtk_dp.o
> diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
> new file mode 100644
> index 000000000000..7cd8459cf719
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
> @@ -0,0 +1,2221 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 MediaTek Inc.
> + * Copyright (c) 2021 BayLibre
> + */
> +
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_bridge.h>
> +#include <drm/drm_crtc.h>
> +#include <drm/dp/drm_dp_helper.h>
> +#include <drm/drm_edid.h>
> +#include <drm/drm_of.h>
> +#include <drm/drm_panel.h>
> +#include <drm/drm_print.h>
> +#include <drm/drm_probe_helper.h>
> +#include <linux/arm-smccc.h>
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/errno.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/nvmem-consumer.h>
> +#include <linux/of.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +#include <sound/hdmi-codec.h>
> +#include <video/videomode.h>
> +
> +#include "mtk_dp_reg.h"
> +
> +#define MTK_DP_AUX_WAIT_REPLY_COUNT 20
> +#define MTK_DP_CHECK_SINK_CAP_TIMEOUT_COUNT 3
> +
> +//TODO: platform/device data or dts?

Assuming that your TODO is about the maximum number of lanes,
{ .compatible = "mediatek,mt8195-edp-tx", .data = &some_const_structure },

> +#define MTK_DP_MAX_LANES 4
> +#define MTK_DP_MAX_LINK_RATE MTK_DP_LINKRATE_HBR3

..snip..

> +
> +static int mtk_dp_bulk_16bit_write(struct mtk_dp *mtk_dp, u32 offset, u8 *buf,
> +				   size_t length)
> +{
> +	int i;
> +	int ret = 0;
> +	int num_regs = (length + 1) / 2;
> +
> +	/* 2 bytes per register */
> +	for (i = 0; i < num_regs; i++) {
> +		u32 val = buf[i * 2] |
> +			  (i * 2 + 1 < length ? buf[i * 2 + 1] << 8 : 0);
> +
> +		ret = mtk_dp_write(mtk_dp, offset + i * 4, val);
> +		if (ret)
> +			goto out;

if (ret)
     return ret;

> +	}
> +
> +out:

Remove this label.

> +	return ret;
> +}
> +
> +static unsigned long mtk_dp_sip_atf_call(unsigned int cmd, unsigned int para)
> +{
> +	struct arm_smccc_res res;
> +
> +	arm_smccc_smc(MTK_DP_SIP_CONTROL_AARCH32, cmd, para, 0, 0, 0, 0, 0,
> +		      &res);
> +
> +	pr_debug("[DPTX]%s cmd 0x%x, p1 0x%x, ret 0x%lx-0x%lx", __func__, cmd,
> +		 para, res.a0, res.a1);
> +	return res.a1;
> +}
> +
> +static int mtk_dp_msa_bypass_disable(struct mtk_dp *mtk_dp)
> +{
> +	const u16 bits_to_set =
> +		BIT(HTOTAL_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(VTOTAL_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(HSTART_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(VSTART_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(HWIDTH_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(VHEIGHT_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(HSP_SEL_DP_ENC0_P0_SHIFT) | BIT(HSW_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(VSP_SEL_DP_ENC0_P0_SHIFT) | BIT(VSW_SEL_DP_ENC0_P0_SHIFT);
> +	return mtk_dp_update_bits(mtk_dp, MTK_DP_ENC0_P0_3030, bits_to_set,
> +			   bits_to_set);
> +}
> +
> +#define MTK_UPD_BITS_OR_OUT(mtk_dp, offset, val, mask, ret, label) \
> +	do {\
> +		ret = mtk_dp_update_bits(mtk_dp, offset, val, mask); \
> +		if (ret) \
> +			goto label; \
> +	} while (0)

I'm sorry, no offense - but this macro is a bit ugly...

I think I understand why you have introduced it, but in my opinion this decreases
human readability a lot, I was even about to point out multiple functions that
you had unused labels before checking this macro, as that was totally unexpected...

In my opinion, this should be open-coded everywhere... yes it makes the file a
bit fatter in terms of amount of text, but eh... it's life :)))


> +

....snip....

> +
> +static int mtk_dp_set_color_format(struct mtk_dp *mtk_dp,
> +				   enum mtk_dp_color_format color_format)
> +{
> +	u32 val;
> +	int ret;
> +
> +	mtk_dp->info.format = color_format;
> +
> +	/* Update MISC0 */
> +	ret = mtk_dp_update_bits(mtk_dp, MTK_DP_ENC0_P0_3034,
> +				 color_format << DP_TEST_COLOR_FORMAT_SHIFT,
> +			   DP_TEST_COLOR_FORMAT_MASK);
> +
> +	if (ret)
> +		return ret;
> +
> +	switch (color_format) {
> +	case MTK_DP_COLOR_FORMAT_YUV_422:
> +		val = PIXEL_ENCODE_FORMAT_DP_ENC0_P0_YCBCR422;
> +		break;
> +	case MTK_DP_COLOR_FORMAT_YUV_420:
> +		val = PIXEL_ENCODE_FORMAT_DP_ENC0_P0_YCBCR420;
> +		break;
> +	case MTK_DP_COLOR_FORMAT_YONLY:
> +	case MTK_DP_COLOR_FORMAT_RAW:
> +	case MTK_DP_COLOR_FORMAT_RESERVED:
> +	case MTK_DP_COLOR_FORMAT_UNKNOWN:
> +		drm_warn(mtk_dp->drm_dev, "Unsupported color format: %d\n",
> +			 color_format);
> +		fallthrough;

Uhm, are you sure that you should fallthrough?
If we get a color format that we don't understand, the best thing that would
happen is that we'd get scrambled colors... which is something unwanted.

The best idea is to return -EINVAL here, hence refuse to go on with an invalid
color format.

> +	case MTK_DP_COLOR_FORMAT_RGB_444:
> +	case MTK_DP_COLOR_FORMAT_YUV_444:
> +		val = PIXEL_ENCODE_FORMAT_DP_ENC0_P0_RGB;
> +		break;
> +	}
> +
> +	return mtk_dp_update_bits(mtk_dp, MTK_DP_ENC0_P0_303C, val,
> +			   PIXEL_ENCODE_FORMAT_DP_ENC0_P0_MASK);
> +}
> +

...snip...

> +
> +static void mtk_dp_initialize_hpd_detect_settings(struct mtk_dp *mtk_dp)
> +{
> +	// Debounce threshold

I think I already told you to fix comments style.

> +	mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3410,
> +			   8 << HPD_DEB_THD_DP_TRANS_P0_SHIFT,
> +			   HPD_DEB_THD_DP_TRANS_P0_MASK);
> +	mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3410,
> +			   (HPD_INT_THD_DP_TRANS_P0_LOWER_500US |
> +			    HPD_INT_THD_DP_TRANS_P0_UPPER_1100US)
> +				   << HPD_INT_THD_DP_TRANS_P0_SHIFT,
> +			   HPD_INT_THD_DP_TRANS_P0_MASK);
> +
> +	// Connect threshold 1.5ms + 5 x 0.1ms = 2ms
> +	// Disconnect threshold 1.5ms + 5 x 0.1ms = 2ms
> +	mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3410,
> +			   (5 << HPD_DISC_THD_DP_TRANS_P0_SHIFT) |
> +				   (5 << HPD_CONN_THD_DP_TRANS_P0_SHIFT),
> +			   HPD_DISC_THD_DP_TRANS_P0_MASK |
> +				   HPD_CONN_THD_DP_TRANS_P0_MASK);
> +	mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3430,
> +			   HPD_INT_THD_ECO_DP_TRANS_P0_HIGH_BOUND_EXT,
> +			   HPD_INT_THD_ECO_DP_TRANS_P0_MASK);
> +}
> +

..snip..

> +
> +static int mtk_dp_power_disable(struct mtk_dp *mtk_dp)
> +{
> +	int ret;
> +
> +	ret = mtk_dp_write(mtk_dp, MTK_DP_TOP_PWR_STATE, 0);
> +
> +	if (ret)
> +		goto out;
> +
> +	usleep_range(10, 200);
> +	ret = mtk_dp_write(mtk_dp, MTK_DP_0034,
> +			   DA_CKM_CKTX0_EN_FORCE_EN | DA_CKM_BIAS_LPF_EN_FORCE_VAL |
> +		     DA_CKM_BIAS_EN_FORCE_VAL |
> +		     DA_XTP_GLB_LDO_EN_FORCE_VAL |
> +		     DA_XTP_GLB_AVD10_ON_FORCE_VAL);
> +
> +	if (ret)
> +		goto out;
> +
> +	/* Disable RX */
> +	ret = mtk_dp_write(mtk_dp, MTK_DP_1040, 0);
> +
> +	if (ret)
> +		goto out;
> +
> +	ret = mtk_dp_write(mtk_dp, MTK_DP_TOP_MEM_PD,
> +			   0x550 | BIT(FUSE_SEL_SHIFT) | BIT(MEM_ISO_EN_SHIFT));
> +
> +out:

You are using a goto instead of a return, but you're not reverting any change,
so this goto usage is not justified - hence, wrong.

Please simply return ret when anything fails, and return 0 at the end of this
function.

	.......
	(blahblah function code)

	ret = something()
	if (ret)
		return ret;

	return 0;
}

> +	return ret;
> +}
> +

...snip...

> +
> +static int mtk_dp_dt_parse(struct mtk_dp *mtk_dp,
> +			   struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	int ret = 0;
> +	void __iomem *base;
> +
> +	base = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(base))
> +		return PTR_ERR(base);
> +
> +	mtk_dp->regs = syscon_node_to_regmap(dev->of_node);
> +	if (IS_ERR(mtk_dp->regs))
> +		return PTR_ERR(mtk_dp->regs);
> +
> +	//TODO: optional clock?

Well, if it's optional, you should use devm_clk_get_optional(), meaning
that......

> +	mtk_dp->dp_tx_clk = devm_clk_get(dev, "faxi");
> +	if (IS_ERR(mtk_dp->dp_tx_clk)) {
> +		ret = PTR_ERR(mtk_dp->dp_tx_clk);
> +		dev_info(dev, "Failed to get dptx clock: %d\n", ret);
> +		mtk_dp->dp_tx_clk = NULL;

...I shouldn't see this snippet of code, as it should be a bit different... :)

> +	}
> +
> +	return 0;
> +}
> +

..snip..

> +static void mtk_dp_bridge_atomic_disable(struct drm_bridge *bridge,
> +					 struct drm_bridge_state *old_state)
> +{
> +	struct mtk_dp *mtk_dp = mtk_dp_from_bridge(bridge);
> +
> +	mtk_dp_video_mute(mtk_dp, true);
> +	mtk_dp->state = MTK_DP_STATE_IDLE;
> +	mtk_dp->train_state = MTK_DP_TRAIN_STATE_STARTUP;
> +
> +	mtk_dp->enabled = false;

> +	msleep(100);

100 milliseconds is an eternity, why are we sleeping for *so long* here?

Please, either add a comment that fully explains the resons for that, or
remove the sleep entirely: to my eyes, it doesn't look like this sleep is
really needed for anything important because here you are disabling the
bridge and *powering off* the IP entirely.

> +	mtk_dp_poweroff(mtk_dp);
> +}
> +

..snip..

> +
> +static enum drm_mode_status
> +mtk_dp_bridge_mode_valid(struct drm_bridge *bridge,
> +			 const struct drm_display_info *info,
> +			 const struct drm_display_mode *mode)
> +{
> +	struct mtk_dp *mtk_dp = mtk_dp_from_bridge(bridge);
> +	u32 rx_linkrate = (u32)mtk_dp->train_info.link_rate * 27000;
> +	u32 bpp = info->color_formats & DRM_COLOR_FORMAT_YCBCR422 ? 16 : 24;
> +
> +	if (rx_linkrate * mtk_dp->train_info.lane_count < mode->clock * bpp / 8)
> +		return MODE_CLOCK_HIGH;
> +
> +	if (mode->clock > 600000)
> +		return MODE_CLOCK_HIGH;
> +
> +	//TODO: explain magic number: 62?

Please fix this TODO for v10.

> +	if ((mode->clock * 1000) / (mode->htotal * mode->vtotal) > 62)
> +		return MODE_CLOCK_HIGH;
> +
> +	return MODE_OK;
> +}
> +



_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Guillaume Ranquet <granquet@baylibre.com>,
	airlied@linux.ie, chunfeng.yun@mediatek.com,
	chunkuang.hu@kernel.org, ck.hu@mediatek.com, daniel@ffwll.ch,
	deller@gmx.de, jitao.shi@mediatek.com, kishon@ti.com,
	krzk+dt@kernel.org, maarten.lankhorst@linux.intel.com,
	matthias.bgg@gmail.com, mripard@kernel.org,
	p.zabel@pengutronix.de, robh+dt@kernel.org, tzimmermann@suse.de,
	vkoul@kernel.org
Cc: devicetree@vger.kernel.org, linux-fbdev@vger.kernel.org,
	kernel test robot <lkp@intel.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Markus Schneider-Pargmann <msp@baylibre.com>,
	linux-mediatek@lists.infradead.org,
	linux-phy@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org, markyacoub@google.com
Subject: Re: [PATCH v9 18/22] drm/mediatek: Add mt8195 Embedded DisplayPort driver
Date: Mon, 28 Mar 2022 11:14:23 +0200	[thread overview]
Message-ID: <9a31c1ce-829b-acc7-6fc1-2a9df45e5c38@collabora.com> (raw)
In-Reply-To: <20220327223927.20848-19-granquet@baylibre.com>

Il 28/03/22 00:39, Guillaume Ranquet ha scritto:
> From: Markus Schneider-Pargmann <msp@baylibre.com>
> 
> 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 shares its iomap range with the mtk-dp-phy driver using
> the regmap/syscon facility.
> 
> This driver is based on an initial version by
> Jason-JH.Lin <jason-jh.lin@mediatek.com>.
> 
> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
> Signed-off-by: Guillaume Ranquet <granquet@baylibre.com>
> Reported-by: kernel test robot <lkp@intel.com>

Hello Guillaume,
as you know, there's some more work to do on this driver.

I will also mention here, not on the code, that at this point, your
mtk_dp_aux_transfer() function has something VERY similar to function
drm_dp_dpcd_access(), so I really believe that you can instead use
functions drm_dp_dpcd_read() and drm_dp_dpcd_write(), avoiding code
duplication around.

Please check drivers/gpu/drm/dp/drm_dp.c.

> ---
>   drivers/gpu/drm/mediatek/Kconfig       |    8 +
>   drivers/gpu/drm/mediatek/Makefile      |    2 +
>   drivers/gpu/drm/mediatek/mtk_dp.c      | 2221 ++++++++++++++++++++++++
>   drivers/gpu/drm/mediatek/mtk_dp_reg.h  |  568 ++++++
>   drivers/gpu/drm/mediatek/mtk_drm_drv.c |    1 +
>   drivers/gpu/drm/mediatek/mtk_drm_drv.h |    1 +
>   6 files changed, 2801 insertions(+)
>   create mode 100644 drivers/gpu/drm/mediatek/mtk_dp.c
>   create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_reg.h
> 
> diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
> index 2976d21e9a34..03ffa9b896c3 100644
> --- a/drivers/gpu/drm/mediatek/Kconfig
> +++ b/drivers/gpu/drm/mediatek/Kconfig
> @@ -28,3 +28,11 @@ config DRM_MEDIATEK_HDMI
>   	select PHY_MTK_HDMI
>   	help
>   	  DRM/KMS HDMI driver for Mediatek SoCs
> +
> +config MTK_DPTX_SUPPORT

Actually, I think that the best would be DRM_MEDIATEK_DP_TX or DRM_MEDIATEK_DP...
...also, ordering is important, please!

> +	tristate "DRM DPTX Support for Mediatek SoCs"
> +	depends on DRM_MEDIATEK
> +	select PHY_MTK_DP
> +	select DRM_DP_HELPER
> +	help
> +	  DRM/KMS Display Port driver for Mediatek SoCs.
> diff --git a/drivers/gpu/drm/mediatek/Makefile b/drivers/gpu/drm/mediatek/Makefile
> index 29098d7c8307..d86a6406055e 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -21,3 +21,5 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
>   			  mtk_hdmi_ddc.o
>   
>   obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
> +
> +obj-$(CONFIG_MTK_DPTX_SUPPORT) += mtk_dp.o
> diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
> new file mode 100644
> index 000000000000..7cd8459cf719
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
> @@ -0,0 +1,2221 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 MediaTek Inc.
> + * Copyright (c) 2021 BayLibre
> + */
> +
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_bridge.h>
> +#include <drm/drm_crtc.h>
> +#include <drm/dp/drm_dp_helper.h>
> +#include <drm/drm_edid.h>
> +#include <drm/drm_of.h>
> +#include <drm/drm_panel.h>
> +#include <drm/drm_print.h>
> +#include <drm/drm_probe_helper.h>
> +#include <linux/arm-smccc.h>
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/errno.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/nvmem-consumer.h>
> +#include <linux/of.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +#include <sound/hdmi-codec.h>
> +#include <video/videomode.h>
> +
> +#include "mtk_dp_reg.h"
> +
> +#define MTK_DP_AUX_WAIT_REPLY_COUNT 20
> +#define MTK_DP_CHECK_SINK_CAP_TIMEOUT_COUNT 3
> +
> +//TODO: platform/device data or dts?

Assuming that your TODO is about the maximum number of lanes,
{ .compatible = "mediatek,mt8195-edp-tx", .data = &some_const_structure },

> +#define MTK_DP_MAX_LANES 4
> +#define MTK_DP_MAX_LINK_RATE MTK_DP_LINKRATE_HBR3

..snip..

> +
> +static int mtk_dp_bulk_16bit_write(struct mtk_dp *mtk_dp, u32 offset, u8 *buf,
> +				   size_t length)
> +{
> +	int i;
> +	int ret = 0;
> +	int num_regs = (length + 1) / 2;
> +
> +	/* 2 bytes per register */
> +	for (i = 0; i < num_regs; i++) {
> +		u32 val = buf[i * 2] |
> +			  (i * 2 + 1 < length ? buf[i * 2 + 1] << 8 : 0);
> +
> +		ret = mtk_dp_write(mtk_dp, offset + i * 4, val);
> +		if (ret)
> +			goto out;

if (ret)
     return ret;

> +	}
> +
> +out:

Remove this label.

> +	return ret;
> +}
> +
> +static unsigned long mtk_dp_sip_atf_call(unsigned int cmd, unsigned int para)
> +{
> +	struct arm_smccc_res res;
> +
> +	arm_smccc_smc(MTK_DP_SIP_CONTROL_AARCH32, cmd, para, 0, 0, 0, 0, 0,
> +		      &res);
> +
> +	pr_debug("[DPTX]%s cmd 0x%x, p1 0x%x, ret 0x%lx-0x%lx", __func__, cmd,
> +		 para, res.a0, res.a1);
> +	return res.a1;
> +}
> +
> +static int mtk_dp_msa_bypass_disable(struct mtk_dp *mtk_dp)
> +{
> +	const u16 bits_to_set =
> +		BIT(HTOTAL_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(VTOTAL_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(HSTART_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(VSTART_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(HWIDTH_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(VHEIGHT_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(HSP_SEL_DP_ENC0_P0_SHIFT) | BIT(HSW_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(VSP_SEL_DP_ENC0_P0_SHIFT) | BIT(VSW_SEL_DP_ENC0_P0_SHIFT);
> +	return mtk_dp_update_bits(mtk_dp, MTK_DP_ENC0_P0_3030, bits_to_set,
> +			   bits_to_set);
> +}
> +
> +#define MTK_UPD_BITS_OR_OUT(mtk_dp, offset, val, mask, ret, label) \
> +	do {\
> +		ret = mtk_dp_update_bits(mtk_dp, offset, val, mask); \
> +		if (ret) \
> +			goto label; \
> +	} while (0)

I'm sorry, no offense - but this macro is a bit ugly...

I think I understand why you have introduced it, but in my opinion this decreases
human readability a lot, I was even about to point out multiple functions that
you had unused labels before checking this macro, as that was totally unexpected...

In my opinion, this should be open-coded everywhere... yes it makes the file a
bit fatter in terms of amount of text, but eh... it's life :)))


> +

....snip....

> +
> +static int mtk_dp_set_color_format(struct mtk_dp *mtk_dp,
> +				   enum mtk_dp_color_format color_format)
> +{
> +	u32 val;
> +	int ret;
> +
> +	mtk_dp->info.format = color_format;
> +
> +	/* Update MISC0 */
> +	ret = mtk_dp_update_bits(mtk_dp, MTK_DP_ENC0_P0_3034,
> +				 color_format << DP_TEST_COLOR_FORMAT_SHIFT,
> +			   DP_TEST_COLOR_FORMAT_MASK);
> +
> +	if (ret)
> +		return ret;
> +
> +	switch (color_format) {
> +	case MTK_DP_COLOR_FORMAT_YUV_422:
> +		val = PIXEL_ENCODE_FORMAT_DP_ENC0_P0_YCBCR422;
> +		break;
> +	case MTK_DP_COLOR_FORMAT_YUV_420:
> +		val = PIXEL_ENCODE_FORMAT_DP_ENC0_P0_YCBCR420;
> +		break;
> +	case MTK_DP_COLOR_FORMAT_YONLY:
> +	case MTK_DP_COLOR_FORMAT_RAW:
> +	case MTK_DP_COLOR_FORMAT_RESERVED:
> +	case MTK_DP_COLOR_FORMAT_UNKNOWN:
> +		drm_warn(mtk_dp->drm_dev, "Unsupported color format: %d\n",
> +			 color_format);
> +		fallthrough;

Uhm, are you sure that you should fallthrough?
If we get a color format that we don't understand, the best thing that would
happen is that we'd get scrambled colors... which is something unwanted.

The best idea is to return -EINVAL here, hence refuse to go on with an invalid
color format.

> +	case MTK_DP_COLOR_FORMAT_RGB_444:
> +	case MTK_DP_COLOR_FORMAT_YUV_444:
> +		val = PIXEL_ENCODE_FORMAT_DP_ENC0_P0_RGB;
> +		break;
> +	}
> +
> +	return mtk_dp_update_bits(mtk_dp, MTK_DP_ENC0_P0_303C, val,
> +			   PIXEL_ENCODE_FORMAT_DP_ENC0_P0_MASK);
> +}
> +

...snip...

> +
> +static void mtk_dp_initialize_hpd_detect_settings(struct mtk_dp *mtk_dp)
> +{
> +	// Debounce threshold

I think I already told you to fix comments style.

> +	mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3410,
> +			   8 << HPD_DEB_THD_DP_TRANS_P0_SHIFT,
> +			   HPD_DEB_THD_DP_TRANS_P0_MASK);
> +	mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3410,
> +			   (HPD_INT_THD_DP_TRANS_P0_LOWER_500US |
> +			    HPD_INT_THD_DP_TRANS_P0_UPPER_1100US)
> +				   << HPD_INT_THD_DP_TRANS_P0_SHIFT,
> +			   HPD_INT_THD_DP_TRANS_P0_MASK);
> +
> +	// Connect threshold 1.5ms + 5 x 0.1ms = 2ms
> +	// Disconnect threshold 1.5ms + 5 x 0.1ms = 2ms
> +	mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3410,
> +			   (5 << HPD_DISC_THD_DP_TRANS_P0_SHIFT) |
> +				   (5 << HPD_CONN_THD_DP_TRANS_P0_SHIFT),
> +			   HPD_DISC_THD_DP_TRANS_P0_MASK |
> +				   HPD_CONN_THD_DP_TRANS_P0_MASK);
> +	mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3430,
> +			   HPD_INT_THD_ECO_DP_TRANS_P0_HIGH_BOUND_EXT,
> +			   HPD_INT_THD_ECO_DP_TRANS_P0_MASK);
> +}
> +

..snip..

> +
> +static int mtk_dp_power_disable(struct mtk_dp *mtk_dp)
> +{
> +	int ret;
> +
> +	ret = mtk_dp_write(mtk_dp, MTK_DP_TOP_PWR_STATE, 0);
> +
> +	if (ret)
> +		goto out;
> +
> +	usleep_range(10, 200);
> +	ret = mtk_dp_write(mtk_dp, MTK_DP_0034,
> +			   DA_CKM_CKTX0_EN_FORCE_EN | DA_CKM_BIAS_LPF_EN_FORCE_VAL |
> +		     DA_CKM_BIAS_EN_FORCE_VAL |
> +		     DA_XTP_GLB_LDO_EN_FORCE_VAL |
> +		     DA_XTP_GLB_AVD10_ON_FORCE_VAL);
> +
> +	if (ret)
> +		goto out;
> +
> +	/* Disable RX */
> +	ret = mtk_dp_write(mtk_dp, MTK_DP_1040, 0);
> +
> +	if (ret)
> +		goto out;
> +
> +	ret = mtk_dp_write(mtk_dp, MTK_DP_TOP_MEM_PD,
> +			   0x550 | BIT(FUSE_SEL_SHIFT) | BIT(MEM_ISO_EN_SHIFT));
> +
> +out:

You are using a goto instead of a return, but you're not reverting any change,
so this goto usage is not justified - hence, wrong.

Please simply return ret when anything fails, and return 0 at the end of this
function.

	.......
	(blahblah function code)

	ret = something()
	if (ret)
		return ret;

	return 0;
}

> +	return ret;
> +}
> +

...snip...

> +
> +static int mtk_dp_dt_parse(struct mtk_dp *mtk_dp,
> +			   struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	int ret = 0;
> +	void __iomem *base;
> +
> +	base = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(base))
> +		return PTR_ERR(base);
> +
> +	mtk_dp->regs = syscon_node_to_regmap(dev->of_node);
> +	if (IS_ERR(mtk_dp->regs))
> +		return PTR_ERR(mtk_dp->regs);
> +
> +	//TODO: optional clock?

Well, if it's optional, you should use devm_clk_get_optional(), meaning
that......

> +	mtk_dp->dp_tx_clk = devm_clk_get(dev, "faxi");
> +	if (IS_ERR(mtk_dp->dp_tx_clk)) {
> +		ret = PTR_ERR(mtk_dp->dp_tx_clk);
> +		dev_info(dev, "Failed to get dptx clock: %d\n", ret);
> +		mtk_dp->dp_tx_clk = NULL;

...I shouldn't see this snippet of code, as it should be a bit different... :)

> +	}
> +
> +	return 0;
> +}
> +

..snip..

> +static void mtk_dp_bridge_atomic_disable(struct drm_bridge *bridge,
> +					 struct drm_bridge_state *old_state)
> +{
> +	struct mtk_dp *mtk_dp = mtk_dp_from_bridge(bridge);
> +
> +	mtk_dp_video_mute(mtk_dp, true);
> +	mtk_dp->state = MTK_DP_STATE_IDLE;
> +	mtk_dp->train_state = MTK_DP_TRAIN_STATE_STARTUP;
> +
> +	mtk_dp->enabled = false;

> +	msleep(100);

100 milliseconds is an eternity, why are we sleeping for *so long* here?

Please, either add a comment that fully explains the resons for that, or
remove the sleep entirely: to my eyes, it doesn't look like this sleep is
really needed for anything important because here you are disabling the
bridge and *powering off* the IP entirely.

> +	mtk_dp_poweroff(mtk_dp);
> +}
> +

..snip..

> +
> +static enum drm_mode_status
> +mtk_dp_bridge_mode_valid(struct drm_bridge *bridge,
> +			 const struct drm_display_info *info,
> +			 const struct drm_display_mode *mode)
> +{
> +	struct mtk_dp *mtk_dp = mtk_dp_from_bridge(bridge);
> +	u32 rx_linkrate = (u32)mtk_dp->train_info.link_rate * 27000;
> +	u32 bpp = info->color_formats & DRM_COLOR_FORMAT_YCBCR422 ? 16 : 24;
> +
> +	if (rx_linkrate * mtk_dp->train_info.lane_count < mode->clock * bpp / 8)
> +		return MODE_CLOCK_HIGH;
> +
> +	if (mode->clock > 600000)
> +		return MODE_CLOCK_HIGH;
> +
> +	//TODO: explain magic number: 62?

Please fix this TODO for v10.

> +	if ((mode->clock * 1000) / (mode->htotal * mode->vtotal) > 62)
> +		return MODE_CLOCK_HIGH;
> +
> +	return MODE_OK;
> +}
> +



WARNING: multiple messages have this Message-ID (diff)
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Guillaume Ranquet <granquet@baylibre.com>,
	airlied@linux.ie, chunfeng.yun@mediatek.com,
	chunkuang.hu@kernel.org, ck.hu@mediatek.com, daniel@ffwll.ch,
	deller@gmx.de, jitao.shi@mediatek.com, kishon@ti.com,
	krzk+dt@kernel.org, maarten.lankhorst@linux.intel.com,
	matthias.bgg@gmail.com, mripard@kernel.org,
	p.zabel@pengutronix.de, robh+dt@kernel.org, tzimmermann@suse.de,
	vkoul@kernel.org
Cc: devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mediatek@lists.infradead.org,
	linux-phy@lists.infradead.org, markyacoub@google.com,
	Markus Schneider-Pargmann <msp@baylibre.com>,
	kernel test robot <lkp@intel.com>
Subject: Re: [PATCH v9 18/22] drm/mediatek: Add mt8195 Embedded DisplayPort driver
Date: Mon, 28 Mar 2022 11:14:23 +0200	[thread overview]
Message-ID: <9a31c1ce-829b-acc7-6fc1-2a9df45e5c38@collabora.com> (raw)
In-Reply-To: <20220327223927.20848-19-granquet@baylibre.com>

Il 28/03/22 00:39, Guillaume Ranquet ha scritto:
> From: Markus Schneider-Pargmann <msp@baylibre.com>
> 
> 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 shares its iomap range with the mtk-dp-phy driver using
> the regmap/syscon facility.
> 
> This driver is based on an initial version by
> Jason-JH.Lin <jason-jh.lin@mediatek.com>.
> 
> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
> Signed-off-by: Guillaume Ranquet <granquet@baylibre.com>
> Reported-by: kernel test robot <lkp@intel.com>

Hello Guillaume,
as you know, there's some more work to do on this driver.

I will also mention here, not on the code, that at this point, your
mtk_dp_aux_transfer() function has something VERY similar to function
drm_dp_dpcd_access(), so I really believe that you can instead use
functions drm_dp_dpcd_read() and drm_dp_dpcd_write(), avoiding code
duplication around.

Please check drivers/gpu/drm/dp/drm_dp.c.

> ---
>   drivers/gpu/drm/mediatek/Kconfig       |    8 +
>   drivers/gpu/drm/mediatek/Makefile      |    2 +
>   drivers/gpu/drm/mediatek/mtk_dp.c      | 2221 ++++++++++++++++++++++++
>   drivers/gpu/drm/mediatek/mtk_dp_reg.h  |  568 ++++++
>   drivers/gpu/drm/mediatek/mtk_drm_drv.c |    1 +
>   drivers/gpu/drm/mediatek/mtk_drm_drv.h |    1 +
>   6 files changed, 2801 insertions(+)
>   create mode 100644 drivers/gpu/drm/mediatek/mtk_dp.c
>   create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_reg.h
> 
> diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
> index 2976d21e9a34..03ffa9b896c3 100644
> --- a/drivers/gpu/drm/mediatek/Kconfig
> +++ b/drivers/gpu/drm/mediatek/Kconfig
> @@ -28,3 +28,11 @@ config DRM_MEDIATEK_HDMI
>   	select PHY_MTK_HDMI
>   	help
>   	  DRM/KMS HDMI driver for Mediatek SoCs
> +
> +config MTK_DPTX_SUPPORT

Actually, I think that the best would be DRM_MEDIATEK_DP_TX or DRM_MEDIATEK_DP...
...also, ordering is important, please!

> +	tristate "DRM DPTX Support for Mediatek SoCs"
> +	depends on DRM_MEDIATEK
> +	select PHY_MTK_DP
> +	select DRM_DP_HELPER
> +	help
> +	  DRM/KMS Display Port driver for Mediatek SoCs.
> diff --git a/drivers/gpu/drm/mediatek/Makefile b/drivers/gpu/drm/mediatek/Makefile
> index 29098d7c8307..d86a6406055e 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -21,3 +21,5 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
>   			  mtk_hdmi_ddc.o
>   
>   obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
> +
> +obj-$(CONFIG_MTK_DPTX_SUPPORT) += mtk_dp.o
> diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
> new file mode 100644
> index 000000000000..7cd8459cf719
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
> @@ -0,0 +1,2221 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 MediaTek Inc.
> + * Copyright (c) 2021 BayLibre
> + */
> +
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_bridge.h>
> +#include <drm/drm_crtc.h>
> +#include <drm/dp/drm_dp_helper.h>
> +#include <drm/drm_edid.h>
> +#include <drm/drm_of.h>
> +#include <drm/drm_panel.h>
> +#include <drm/drm_print.h>
> +#include <drm/drm_probe_helper.h>
> +#include <linux/arm-smccc.h>
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/errno.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/nvmem-consumer.h>
> +#include <linux/of.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +#include <sound/hdmi-codec.h>
> +#include <video/videomode.h>
> +
> +#include "mtk_dp_reg.h"
> +
> +#define MTK_DP_AUX_WAIT_REPLY_COUNT 20
> +#define MTK_DP_CHECK_SINK_CAP_TIMEOUT_COUNT 3
> +
> +//TODO: platform/device data or dts?

Assuming that your TODO is about the maximum number of lanes,
{ .compatible = "mediatek,mt8195-edp-tx", .data = &some_const_structure },

> +#define MTK_DP_MAX_LANES 4
> +#define MTK_DP_MAX_LINK_RATE MTK_DP_LINKRATE_HBR3

..snip..

> +
> +static int mtk_dp_bulk_16bit_write(struct mtk_dp *mtk_dp, u32 offset, u8 *buf,
> +				   size_t length)
> +{
> +	int i;
> +	int ret = 0;
> +	int num_regs = (length + 1) / 2;
> +
> +	/* 2 bytes per register */
> +	for (i = 0; i < num_regs; i++) {
> +		u32 val = buf[i * 2] |
> +			  (i * 2 + 1 < length ? buf[i * 2 + 1] << 8 : 0);
> +
> +		ret = mtk_dp_write(mtk_dp, offset + i * 4, val);
> +		if (ret)
> +			goto out;

if (ret)
     return ret;

> +	}
> +
> +out:

Remove this label.

> +	return ret;
> +}
> +
> +static unsigned long mtk_dp_sip_atf_call(unsigned int cmd, unsigned int para)
> +{
> +	struct arm_smccc_res res;
> +
> +	arm_smccc_smc(MTK_DP_SIP_CONTROL_AARCH32, cmd, para, 0, 0, 0, 0, 0,
> +		      &res);
> +
> +	pr_debug("[DPTX]%s cmd 0x%x, p1 0x%x, ret 0x%lx-0x%lx", __func__, cmd,
> +		 para, res.a0, res.a1);
> +	return res.a1;
> +}
> +
> +static int mtk_dp_msa_bypass_disable(struct mtk_dp *mtk_dp)
> +{
> +	const u16 bits_to_set =
> +		BIT(HTOTAL_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(VTOTAL_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(HSTART_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(VSTART_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(HWIDTH_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(VHEIGHT_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(HSP_SEL_DP_ENC0_P0_SHIFT) | BIT(HSW_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(VSP_SEL_DP_ENC0_P0_SHIFT) | BIT(VSW_SEL_DP_ENC0_P0_SHIFT);
> +	return mtk_dp_update_bits(mtk_dp, MTK_DP_ENC0_P0_3030, bits_to_set,
> +			   bits_to_set);
> +}
> +
> +#define MTK_UPD_BITS_OR_OUT(mtk_dp, offset, val, mask, ret, label) \
> +	do {\
> +		ret = mtk_dp_update_bits(mtk_dp, offset, val, mask); \
> +		if (ret) \
> +			goto label; \
> +	} while (0)

I'm sorry, no offense - but this macro is a bit ugly...

I think I understand why you have introduced it, but in my opinion this decreases
human readability a lot, I was even about to point out multiple functions that
you had unused labels before checking this macro, as that was totally unexpected...

In my opinion, this should be open-coded everywhere... yes it makes the file a
bit fatter in terms of amount of text, but eh... it's life :)))


> +

....snip....

> +
> +static int mtk_dp_set_color_format(struct mtk_dp *mtk_dp,
> +				   enum mtk_dp_color_format color_format)
> +{
> +	u32 val;
> +	int ret;
> +
> +	mtk_dp->info.format = color_format;
> +
> +	/* Update MISC0 */
> +	ret = mtk_dp_update_bits(mtk_dp, MTK_DP_ENC0_P0_3034,
> +				 color_format << DP_TEST_COLOR_FORMAT_SHIFT,
> +			   DP_TEST_COLOR_FORMAT_MASK);
> +
> +	if (ret)
> +		return ret;
> +
> +	switch (color_format) {
> +	case MTK_DP_COLOR_FORMAT_YUV_422:
> +		val = PIXEL_ENCODE_FORMAT_DP_ENC0_P0_YCBCR422;
> +		break;
> +	case MTK_DP_COLOR_FORMAT_YUV_420:
> +		val = PIXEL_ENCODE_FORMAT_DP_ENC0_P0_YCBCR420;
> +		break;
> +	case MTK_DP_COLOR_FORMAT_YONLY:
> +	case MTK_DP_COLOR_FORMAT_RAW:
> +	case MTK_DP_COLOR_FORMAT_RESERVED:
> +	case MTK_DP_COLOR_FORMAT_UNKNOWN:
> +		drm_warn(mtk_dp->drm_dev, "Unsupported color format: %d\n",
> +			 color_format);
> +		fallthrough;

Uhm, are you sure that you should fallthrough?
If we get a color format that we don't understand, the best thing that would
happen is that we'd get scrambled colors... which is something unwanted.

The best idea is to return -EINVAL here, hence refuse to go on with an invalid
color format.

> +	case MTK_DP_COLOR_FORMAT_RGB_444:
> +	case MTK_DP_COLOR_FORMAT_YUV_444:
> +		val = PIXEL_ENCODE_FORMAT_DP_ENC0_P0_RGB;
> +		break;
> +	}
> +
> +	return mtk_dp_update_bits(mtk_dp, MTK_DP_ENC0_P0_303C, val,
> +			   PIXEL_ENCODE_FORMAT_DP_ENC0_P0_MASK);
> +}
> +

...snip...

> +
> +static void mtk_dp_initialize_hpd_detect_settings(struct mtk_dp *mtk_dp)
> +{
> +	// Debounce threshold

I think I already told you to fix comments style.

> +	mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3410,
> +			   8 << HPD_DEB_THD_DP_TRANS_P0_SHIFT,
> +			   HPD_DEB_THD_DP_TRANS_P0_MASK);
> +	mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3410,
> +			   (HPD_INT_THD_DP_TRANS_P0_LOWER_500US |
> +			    HPD_INT_THD_DP_TRANS_P0_UPPER_1100US)
> +				   << HPD_INT_THD_DP_TRANS_P0_SHIFT,
> +			   HPD_INT_THD_DP_TRANS_P0_MASK);
> +
> +	// Connect threshold 1.5ms + 5 x 0.1ms = 2ms
> +	// Disconnect threshold 1.5ms + 5 x 0.1ms = 2ms
> +	mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3410,
> +			   (5 << HPD_DISC_THD_DP_TRANS_P0_SHIFT) |
> +				   (5 << HPD_CONN_THD_DP_TRANS_P0_SHIFT),
> +			   HPD_DISC_THD_DP_TRANS_P0_MASK |
> +				   HPD_CONN_THD_DP_TRANS_P0_MASK);
> +	mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3430,
> +			   HPD_INT_THD_ECO_DP_TRANS_P0_HIGH_BOUND_EXT,
> +			   HPD_INT_THD_ECO_DP_TRANS_P0_MASK);
> +}
> +

..snip..

> +
> +static int mtk_dp_power_disable(struct mtk_dp *mtk_dp)
> +{
> +	int ret;
> +
> +	ret = mtk_dp_write(mtk_dp, MTK_DP_TOP_PWR_STATE, 0);
> +
> +	if (ret)
> +		goto out;
> +
> +	usleep_range(10, 200);
> +	ret = mtk_dp_write(mtk_dp, MTK_DP_0034,
> +			   DA_CKM_CKTX0_EN_FORCE_EN | DA_CKM_BIAS_LPF_EN_FORCE_VAL |
> +		     DA_CKM_BIAS_EN_FORCE_VAL |
> +		     DA_XTP_GLB_LDO_EN_FORCE_VAL |
> +		     DA_XTP_GLB_AVD10_ON_FORCE_VAL);
> +
> +	if (ret)
> +		goto out;
> +
> +	/* Disable RX */
> +	ret = mtk_dp_write(mtk_dp, MTK_DP_1040, 0);
> +
> +	if (ret)
> +		goto out;
> +
> +	ret = mtk_dp_write(mtk_dp, MTK_DP_TOP_MEM_PD,
> +			   0x550 | BIT(FUSE_SEL_SHIFT) | BIT(MEM_ISO_EN_SHIFT));
> +
> +out:

You are using a goto instead of a return, but you're not reverting any change,
so this goto usage is not justified - hence, wrong.

Please simply return ret when anything fails, and return 0 at the end of this
function.

	.......
	(blahblah function code)

	ret = something()
	if (ret)
		return ret;

	return 0;
}

> +	return ret;
> +}
> +

...snip...

> +
> +static int mtk_dp_dt_parse(struct mtk_dp *mtk_dp,
> +			   struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	int ret = 0;
> +	void __iomem *base;
> +
> +	base = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(base))
> +		return PTR_ERR(base);
> +
> +	mtk_dp->regs = syscon_node_to_regmap(dev->of_node);
> +	if (IS_ERR(mtk_dp->regs))
> +		return PTR_ERR(mtk_dp->regs);
> +
> +	//TODO: optional clock?

Well, if it's optional, you should use devm_clk_get_optional(), meaning
that......

> +	mtk_dp->dp_tx_clk = devm_clk_get(dev, "faxi");
> +	if (IS_ERR(mtk_dp->dp_tx_clk)) {
> +		ret = PTR_ERR(mtk_dp->dp_tx_clk);
> +		dev_info(dev, "Failed to get dptx clock: %d\n", ret);
> +		mtk_dp->dp_tx_clk = NULL;

...I shouldn't see this snippet of code, as it should be a bit different... :)

> +	}
> +
> +	return 0;
> +}
> +

..snip..

> +static void mtk_dp_bridge_atomic_disable(struct drm_bridge *bridge,
> +					 struct drm_bridge_state *old_state)
> +{
> +	struct mtk_dp *mtk_dp = mtk_dp_from_bridge(bridge);
> +
> +	mtk_dp_video_mute(mtk_dp, true);
> +	mtk_dp->state = MTK_DP_STATE_IDLE;
> +	mtk_dp->train_state = MTK_DP_TRAIN_STATE_STARTUP;
> +
> +	mtk_dp->enabled = false;

> +	msleep(100);

100 milliseconds is an eternity, why are we sleeping for *so long* here?

Please, either add a comment that fully explains the resons for that, or
remove the sleep entirely: to my eyes, it doesn't look like this sleep is
really needed for anything important because here you are disabling the
bridge and *powering off* the IP entirely.

> +	mtk_dp_poweroff(mtk_dp);
> +}
> +

..snip..

> +
> +static enum drm_mode_status
> +mtk_dp_bridge_mode_valid(struct drm_bridge *bridge,
> +			 const struct drm_display_info *info,
> +			 const struct drm_display_mode *mode)
> +{
> +	struct mtk_dp *mtk_dp = mtk_dp_from_bridge(bridge);
> +	u32 rx_linkrate = (u32)mtk_dp->train_info.link_rate * 27000;
> +	u32 bpp = info->color_formats & DRM_COLOR_FORMAT_YCBCR422 ? 16 : 24;
> +
> +	if (rx_linkrate * mtk_dp->train_info.lane_count < mode->clock * bpp / 8)
> +		return MODE_CLOCK_HIGH;
> +
> +	if (mode->clock > 600000)
> +		return MODE_CLOCK_HIGH;
> +
> +	//TODO: explain magic number: 62?

Please fix this TODO for v10.

> +	if ((mode->clock * 1000) / (mode->htotal * mode->vtotal) > 62)
> +		return MODE_CLOCK_HIGH;
> +
> +	return MODE_OK;
> +}
> +



-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

WARNING: multiple messages have this Message-ID (diff)
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Guillaume Ranquet <granquet@baylibre.com>,
	airlied@linux.ie, chunfeng.yun@mediatek.com,
	chunkuang.hu@kernel.org, ck.hu@mediatek.com, daniel@ffwll.ch,
	deller@gmx.de, jitao.shi@mediatek.com, kishon@ti.com,
	krzk+dt@kernel.org, maarten.lankhorst@linux.intel.com,
	matthias.bgg@gmail.com, mripard@kernel.org,
	p.zabel@pengutronix.de, robh+dt@kernel.org, tzimmermann@suse.de,
	vkoul@kernel.org
Cc: devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mediatek@lists.infradead.org,
	linux-phy@lists.infradead.org, markyacoub@google.com,
	Markus Schneider-Pargmann <msp@baylibre.com>,
	kernel test robot <lkp@intel.com>
Subject: Re: [PATCH v9 18/22] drm/mediatek: Add mt8195 Embedded DisplayPort driver
Date: Mon, 28 Mar 2022 11:14:23 +0200	[thread overview]
Message-ID: <9a31c1ce-829b-acc7-6fc1-2a9df45e5c38@collabora.com> (raw)
In-Reply-To: <20220327223927.20848-19-granquet@baylibre.com>

Il 28/03/22 00:39, Guillaume Ranquet ha scritto:
> From: Markus Schneider-Pargmann <msp@baylibre.com>
> 
> 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 shares its iomap range with the mtk-dp-phy driver using
> the regmap/syscon facility.
> 
> This driver is based on an initial version by
> Jason-JH.Lin <jason-jh.lin@mediatek.com>.
> 
> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
> Signed-off-by: Guillaume Ranquet <granquet@baylibre.com>
> Reported-by: kernel test robot <lkp@intel.com>

Hello Guillaume,
as you know, there's some more work to do on this driver.

I will also mention here, not on the code, that at this point, your
mtk_dp_aux_transfer() function has something VERY similar to function
drm_dp_dpcd_access(), so I really believe that you can instead use
functions drm_dp_dpcd_read() and drm_dp_dpcd_write(), avoiding code
duplication around.

Please check drivers/gpu/drm/dp/drm_dp.c.

> ---
>   drivers/gpu/drm/mediatek/Kconfig       |    8 +
>   drivers/gpu/drm/mediatek/Makefile      |    2 +
>   drivers/gpu/drm/mediatek/mtk_dp.c      | 2221 ++++++++++++++++++++++++
>   drivers/gpu/drm/mediatek/mtk_dp_reg.h  |  568 ++++++
>   drivers/gpu/drm/mediatek/mtk_drm_drv.c |    1 +
>   drivers/gpu/drm/mediatek/mtk_drm_drv.h |    1 +
>   6 files changed, 2801 insertions(+)
>   create mode 100644 drivers/gpu/drm/mediatek/mtk_dp.c
>   create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_reg.h
> 
> diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
> index 2976d21e9a34..03ffa9b896c3 100644
> --- a/drivers/gpu/drm/mediatek/Kconfig
> +++ b/drivers/gpu/drm/mediatek/Kconfig
> @@ -28,3 +28,11 @@ config DRM_MEDIATEK_HDMI
>   	select PHY_MTK_HDMI
>   	help
>   	  DRM/KMS HDMI driver for Mediatek SoCs
> +
> +config MTK_DPTX_SUPPORT

Actually, I think that the best would be DRM_MEDIATEK_DP_TX or DRM_MEDIATEK_DP...
...also, ordering is important, please!

> +	tristate "DRM DPTX Support for Mediatek SoCs"
> +	depends on DRM_MEDIATEK
> +	select PHY_MTK_DP
> +	select DRM_DP_HELPER
> +	help
> +	  DRM/KMS Display Port driver for Mediatek SoCs.
> diff --git a/drivers/gpu/drm/mediatek/Makefile b/drivers/gpu/drm/mediatek/Makefile
> index 29098d7c8307..d86a6406055e 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -21,3 +21,5 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
>   			  mtk_hdmi_ddc.o
>   
>   obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
> +
> +obj-$(CONFIG_MTK_DPTX_SUPPORT) += mtk_dp.o
> diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
> new file mode 100644
> index 000000000000..7cd8459cf719
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
> @@ -0,0 +1,2221 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 MediaTek Inc.
> + * Copyright (c) 2021 BayLibre
> + */
> +
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_bridge.h>
> +#include <drm/drm_crtc.h>
> +#include <drm/dp/drm_dp_helper.h>
> +#include <drm/drm_edid.h>
> +#include <drm/drm_of.h>
> +#include <drm/drm_panel.h>
> +#include <drm/drm_print.h>
> +#include <drm/drm_probe_helper.h>
> +#include <linux/arm-smccc.h>
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/errno.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/nvmem-consumer.h>
> +#include <linux/of.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +#include <sound/hdmi-codec.h>
> +#include <video/videomode.h>
> +
> +#include "mtk_dp_reg.h"
> +
> +#define MTK_DP_AUX_WAIT_REPLY_COUNT 20
> +#define MTK_DP_CHECK_SINK_CAP_TIMEOUT_COUNT 3
> +
> +//TODO: platform/device data or dts?

Assuming that your TODO is about the maximum number of lanes,
{ .compatible = "mediatek,mt8195-edp-tx", .data = &some_const_structure },

> +#define MTK_DP_MAX_LANES 4
> +#define MTK_DP_MAX_LINK_RATE MTK_DP_LINKRATE_HBR3

..snip..

> +
> +static int mtk_dp_bulk_16bit_write(struct mtk_dp *mtk_dp, u32 offset, u8 *buf,
> +				   size_t length)
> +{
> +	int i;
> +	int ret = 0;
> +	int num_regs = (length + 1) / 2;
> +
> +	/* 2 bytes per register */
> +	for (i = 0; i < num_regs; i++) {
> +		u32 val = buf[i * 2] |
> +			  (i * 2 + 1 < length ? buf[i * 2 + 1] << 8 : 0);
> +
> +		ret = mtk_dp_write(mtk_dp, offset + i * 4, val);
> +		if (ret)
> +			goto out;

if (ret)
     return ret;

> +	}
> +
> +out:

Remove this label.

> +	return ret;
> +}
> +
> +static unsigned long mtk_dp_sip_atf_call(unsigned int cmd, unsigned int para)
> +{
> +	struct arm_smccc_res res;
> +
> +	arm_smccc_smc(MTK_DP_SIP_CONTROL_AARCH32, cmd, para, 0, 0, 0, 0, 0,
> +		      &res);
> +
> +	pr_debug("[DPTX]%s cmd 0x%x, p1 0x%x, ret 0x%lx-0x%lx", __func__, cmd,
> +		 para, res.a0, res.a1);
> +	return res.a1;
> +}
> +
> +static int mtk_dp_msa_bypass_disable(struct mtk_dp *mtk_dp)
> +{
> +	const u16 bits_to_set =
> +		BIT(HTOTAL_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(VTOTAL_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(HSTART_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(VSTART_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(HWIDTH_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(VHEIGHT_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(HSP_SEL_DP_ENC0_P0_SHIFT) | BIT(HSW_SEL_DP_ENC0_P0_SHIFT) |
> +		BIT(VSP_SEL_DP_ENC0_P0_SHIFT) | BIT(VSW_SEL_DP_ENC0_P0_SHIFT);
> +	return mtk_dp_update_bits(mtk_dp, MTK_DP_ENC0_P0_3030, bits_to_set,
> +			   bits_to_set);
> +}
> +
> +#define MTK_UPD_BITS_OR_OUT(mtk_dp, offset, val, mask, ret, label) \
> +	do {\
> +		ret = mtk_dp_update_bits(mtk_dp, offset, val, mask); \
> +		if (ret) \
> +			goto label; \
> +	} while (0)

I'm sorry, no offense - but this macro is a bit ugly...

I think I understand why you have introduced it, but in my opinion this decreases
human readability a lot, I was even about to point out multiple functions that
you had unused labels before checking this macro, as that was totally unexpected...

In my opinion, this should be open-coded everywhere... yes it makes the file a
bit fatter in terms of amount of text, but eh... it's life :)))


> +

....snip....

> +
> +static int mtk_dp_set_color_format(struct mtk_dp *mtk_dp,
> +				   enum mtk_dp_color_format color_format)
> +{
> +	u32 val;
> +	int ret;
> +
> +	mtk_dp->info.format = color_format;
> +
> +	/* Update MISC0 */
> +	ret = mtk_dp_update_bits(mtk_dp, MTK_DP_ENC0_P0_3034,
> +				 color_format << DP_TEST_COLOR_FORMAT_SHIFT,
> +			   DP_TEST_COLOR_FORMAT_MASK);
> +
> +	if (ret)
> +		return ret;
> +
> +	switch (color_format) {
> +	case MTK_DP_COLOR_FORMAT_YUV_422:
> +		val = PIXEL_ENCODE_FORMAT_DP_ENC0_P0_YCBCR422;
> +		break;
> +	case MTK_DP_COLOR_FORMAT_YUV_420:
> +		val = PIXEL_ENCODE_FORMAT_DP_ENC0_P0_YCBCR420;
> +		break;
> +	case MTK_DP_COLOR_FORMAT_YONLY:
> +	case MTK_DP_COLOR_FORMAT_RAW:
> +	case MTK_DP_COLOR_FORMAT_RESERVED:
> +	case MTK_DP_COLOR_FORMAT_UNKNOWN:
> +		drm_warn(mtk_dp->drm_dev, "Unsupported color format: %d\n",
> +			 color_format);
> +		fallthrough;

Uhm, are you sure that you should fallthrough?
If we get a color format that we don't understand, the best thing that would
happen is that we'd get scrambled colors... which is something unwanted.

The best idea is to return -EINVAL here, hence refuse to go on with an invalid
color format.

> +	case MTK_DP_COLOR_FORMAT_RGB_444:
> +	case MTK_DP_COLOR_FORMAT_YUV_444:
> +		val = PIXEL_ENCODE_FORMAT_DP_ENC0_P0_RGB;
> +		break;
> +	}
> +
> +	return mtk_dp_update_bits(mtk_dp, MTK_DP_ENC0_P0_303C, val,
> +			   PIXEL_ENCODE_FORMAT_DP_ENC0_P0_MASK);
> +}
> +

...snip...

> +
> +static void mtk_dp_initialize_hpd_detect_settings(struct mtk_dp *mtk_dp)
> +{
> +	// Debounce threshold

I think I already told you to fix comments style.

> +	mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3410,
> +			   8 << HPD_DEB_THD_DP_TRANS_P0_SHIFT,
> +			   HPD_DEB_THD_DP_TRANS_P0_MASK);
> +	mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3410,
> +			   (HPD_INT_THD_DP_TRANS_P0_LOWER_500US |
> +			    HPD_INT_THD_DP_TRANS_P0_UPPER_1100US)
> +				   << HPD_INT_THD_DP_TRANS_P0_SHIFT,
> +			   HPD_INT_THD_DP_TRANS_P0_MASK);
> +
> +	// Connect threshold 1.5ms + 5 x 0.1ms = 2ms
> +	// Disconnect threshold 1.5ms + 5 x 0.1ms = 2ms
> +	mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3410,
> +			   (5 << HPD_DISC_THD_DP_TRANS_P0_SHIFT) |
> +				   (5 << HPD_CONN_THD_DP_TRANS_P0_SHIFT),
> +			   HPD_DISC_THD_DP_TRANS_P0_MASK |
> +				   HPD_CONN_THD_DP_TRANS_P0_MASK);
> +	mtk_dp_update_bits(mtk_dp, MTK_DP_TRANS_P0_3430,
> +			   HPD_INT_THD_ECO_DP_TRANS_P0_HIGH_BOUND_EXT,
> +			   HPD_INT_THD_ECO_DP_TRANS_P0_MASK);
> +}
> +

..snip..

> +
> +static int mtk_dp_power_disable(struct mtk_dp *mtk_dp)
> +{
> +	int ret;
> +
> +	ret = mtk_dp_write(mtk_dp, MTK_DP_TOP_PWR_STATE, 0);
> +
> +	if (ret)
> +		goto out;
> +
> +	usleep_range(10, 200);
> +	ret = mtk_dp_write(mtk_dp, MTK_DP_0034,
> +			   DA_CKM_CKTX0_EN_FORCE_EN | DA_CKM_BIAS_LPF_EN_FORCE_VAL |
> +		     DA_CKM_BIAS_EN_FORCE_VAL |
> +		     DA_XTP_GLB_LDO_EN_FORCE_VAL |
> +		     DA_XTP_GLB_AVD10_ON_FORCE_VAL);
> +
> +	if (ret)
> +		goto out;
> +
> +	/* Disable RX */
> +	ret = mtk_dp_write(mtk_dp, MTK_DP_1040, 0);
> +
> +	if (ret)
> +		goto out;
> +
> +	ret = mtk_dp_write(mtk_dp, MTK_DP_TOP_MEM_PD,
> +			   0x550 | BIT(FUSE_SEL_SHIFT) | BIT(MEM_ISO_EN_SHIFT));
> +
> +out:

You are using a goto instead of a return, but you're not reverting any change,
so this goto usage is not justified - hence, wrong.

Please simply return ret when anything fails, and return 0 at the end of this
function.

	.......
	(blahblah function code)

	ret = something()
	if (ret)
		return ret;

	return 0;
}

> +	return ret;
> +}
> +

...snip...

> +
> +static int mtk_dp_dt_parse(struct mtk_dp *mtk_dp,
> +			   struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	int ret = 0;
> +	void __iomem *base;
> +
> +	base = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(base))
> +		return PTR_ERR(base);
> +
> +	mtk_dp->regs = syscon_node_to_regmap(dev->of_node);
> +	if (IS_ERR(mtk_dp->regs))
> +		return PTR_ERR(mtk_dp->regs);
> +
> +	//TODO: optional clock?

Well, if it's optional, you should use devm_clk_get_optional(), meaning
that......

> +	mtk_dp->dp_tx_clk = devm_clk_get(dev, "faxi");
> +	if (IS_ERR(mtk_dp->dp_tx_clk)) {
> +		ret = PTR_ERR(mtk_dp->dp_tx_clk);
> +		dev_info(dev, "Failed to get dptx clock: %d\n", ret);
> +		mtk_dp->dp_tx_clk = NULL;

...I shouldn't see this snippet of code, as it should be a bit different... :)

> +	}
> +
> +	return 0;
> +}
> +

..snip..

> +static void mtk_dp_bridge_atomic_disable(struct drm_bridge *bridge,
> +					 struct drm_bridge_state *old_state)
> +{
> +	struct mtk_dp *mtk_dp = mtk_dp_from_bridge(bridge);
> +
> +	mtk_dp_video_mute(mtk_dp, true);
> +	mtk_dp->state = MTK_DP_STATE_IDLE;
> +	mtk_dp->train_state = MTK_DP_TRAIN_STATE_STARTUP;
> +
> +	mtk_dp->enabled = false;

> +	msleep(100);

100 milliseconds is an eternity, why are we sleeping for *so long* here?

Please, either add a comment that fully explains the resons for that, or
remove the sleep entirely: to my eyes, it doesn't look like this sleep is
really needed for anything important because here you are disabling the
bridge and *powering off* the IP entirely.

> +	mtk_dp_poweroff(mtk_dp);
> +}
> +

..snip..

> +
> +static enum drm_mode_status
> +mtk_dp_bridge_mode_valid(struct drm_bridge *bridge,
> +			 const struct drm_display_info *info,
> +			 const struct drm_display_mode *mode)
> +{
> +	struct mtk_dp *mtk_dp = mtk_dp_from_bridge(bridge);
> +	u32 rx_linkrate = (u32)mtk_dp->train_info.link_rate * 27000;
> +	u32 bpp = info->color_formats & DRM_COLOR_FORMAT_YCBCR422 ? 16 : 24;
> +
> +	if (rx_linkrate * mtk_dp->train_info.lane_count < mode->clock * bpp / 8)
> +		return MODE_CLOCK_HIGH;
> +
> +	if (mode->clock > 600000)
> +		return MODE_CLOCK_HIGH;
> +
> +	//TODO: explain magic number: 62?

Please fix this TODO for v10.

> +	if ((mode->clock * 1000) / (mode->htotal * mode->vtotal) > 62)
> +		return MODE_CLOCK_HIGH;
> +
> +	return MODE_OK;
> +}
> +



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

  reply	other threads:[~2022-03-28  9:14 UTC|newest]

Thread overview: 335+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-27 22:39 [PATCH 00/22] drm/mediatek: Add mt8195 DisplayPort driver Guillaume Ranquet
2022-03-27 22:39 ` Guillaume Ranquet
2022-03-27 22:39 ` Guillaume Ranquet
2022-03-27 22:39 ` Guillaume Ranquet
2022-03-27 22:39 ` Guillaume Ranquet
2022-03-27 22:39 ` [PATCH v9 01/22] dt-bindings: mediatek,dpi: Add DP_INTF compatible Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-29 10:42   ` Matthias Brugger
2022-03-29 10:42     ` Matthias Brugger
2022-03-29 10:42     ` Matthias Brugger
2022-03-29 10:42     ` Matthias Brugger
2022-03-29 10:42     ` Matthias Brugger
2022-03-30  5:11   ` Miles Chen
2022-03-30  5:11     ` [PATCH v9 01/22] dt-bindings: mediatek, dpi: " Miles Chen
2022-03-30  5:11     ` Miles Chen
2022-03-30  5:11     ` Miles Chen
2022-03-30  5:11     ` Miles Chen
2022-04-22 10:57   ` [PATCH v9 01/22] dt-bindings: mediatek,dpi: " Maxime Ripard
2022-04-22 10:57     ` Maxime Ripard
2022-04-22 10:57     ` Maxime Ripard
2022-04-22 10:57     ` Maxime Ripard
2022-04-22 10:57     ` Maxime Ripard
2022-05-11 12:37     ` Guillaume Ranquet
2022-05-11 12:37       ` [PATCH v9 01/22] dt-bindings: mediatek, dpi: " Guillaume Ranquet
2022-05-11 12:37       ` Guillaume Ranquet
2022-05-11 12:37       ` Guillaume Ranquet
2022-05-11 12:37       ` Guillaume Ranquet
2022-03-27 22:39 ` [PATCH v9 02/22] dt-bindings: mediatek,dp: Add Display Port binding Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-28 12:51   ` Rob Herring
2022-03-28 12:51     ` [PATCH v9 02/22] dt-bindings: mediatek, dp: " Rob Herring
2022-03-28 12:51     ` Rob Herring
2022-03-28 12:51     ` Rob Herring
2022-03-28 12:51     ` Rob Herring
2022-03-28 16:33   ` [PATCH v9 02/22] dt-bindings: mediatek,dp: " Rob Herring
2022-03-28 16:33     ` Rob Herring
2022-03-28 16:33     ` Rob Herring
2022-03-28 16:33     ` Rob Herring
2022-03-28 16:33     ` Rob Herring
2022-03-30  5:12   ` Miles Chen
2022-03-30  5:12     ` [PATCH v9 02/22] dt-bindings: mediatek, dp: " Miles Chen
2022-03-30  5:12     ` Miles Chen
2022-03-30  5:12     ` Miles Chen
2022-03-30  5:12     ` Miles Chen
2022-03-27 22:39 ` [PATCH v9 03/22] dt-bindings: mediatek,dp_phy: Add Display Port PHY binding Guillaume Ranquet
2022-03-27 22:39   ` [PATCH v9 03/22] dt-bindings: mediatek, dp_phy: " Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-29 22:58   ` [PATCH v9 03/22] dt-bindings: mediatek,dp_phy: " Rob Herring
2022-03-29 22:58     ` Rob Herring
2022-03-29 22:58     ` Rob Herring
2022-03-29 22:58     ` Rob Herring
2022-03-29 22:58     ` Rob Herring
2022-04-12 10:06     ` Guillaume Ranquet
2022-04-12 10:06       ` Guillaume Ranquet
2022-04-12 10:06       ` Guillaume Ranquet
2022-04-12 10:06       ` Guillaume Ranquet
2022-04-12 10:06       ` Guillaume Ranquet
2022-03-30  5:12   ` Miles Chen
2022-03-30  5:12     ` [PATCH v9 03/22] dt-bindings: mediatek, dp_phy: " Miles Chen
2022-03-30  5:12     ` Miles Chen
2022-03-30  5:12     ` Miles Chen
2022-03-30  5:12     ` Miles Chen
2022-03-27 22:39 ` [PATCH v9 04/22] drm/edid: Convert cea_sad helper struct to kernelDoc Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-28  8:04   ` AngeloGioacchino Del Regno
2022-03-28  8:04     ` AngeloGioacchino Del Regno
2022-03-28  8:04     ` AngeloGioacchino Del Regno
2022-03-28  8:04     ` AngeloGioacchino Del Regno
2022-03-28  8:04     ` AngeloGioacchino Del Regno
2022-04-12  8:57     ` Guillaume Ranquet
2022-04-12  8:57       ` Guillaume Ranquet
2022-04-12  8:57       ` Guillaume Ranquet
2022-04-12  8:57       ` Guillaume Ranquet
2022-04-12  8:57       ` Guillaume Ranquet
2022-03-27 22:39 ` [PATCH v9 05/22] drm/edid: Add cea_sad helpers for freq/length Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39 ` [PATCH v9 06/22] video/hdmi: Add audio_infoframe packing for DP Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-28  8:09   ` AngeloGioacchino Del Regno
2022-03-28  8:09     ` AngeloGioacchino Del Regno
2022-03-28  8:09     ` AngeloGioacchino Del Regno
2022-03-28  8:09     ` AngeloGioacchino Del Regno
2022-03-28  8:09     ` AngeloGioacchino Del Regno
2022-04-12  8:59     ` Guillaume Ranquet
2022-04-12  8:59       ` Guillaume Ranquet
2022-04-12  8:59       ` Guillaume Ranquet
2022-04-12  8:59       ` Guillaume Ranquet
2022-04-12  8:59       ` Guillaume Ranquet
2022-03-27 22:39 ` [PATCH v9 07/22] drm/mediatek: dpi: move dpi limits to SoC config Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-28  7:18   ` Rex-BC Chen
2022-03-28  7:18     ` Rex-BC Chen
2022-03-28  7:18     ` Rex-BC Chen
2022-03-28  7:18     ` Rex-BC Chen
2022-03-28  7:18     ` Rex-BC Chen
2022-03-27 22:39 ` [PATCH v9 08/22] drm/mediatek: dpi: implement a CK/DE pol toggle in " Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-28  7:31   ` Rex-BC Chen
2022-03-28  7:31     ` Rex-BC Chen
2022-03-28  7:31     ` Rex-BC Chen
2022-03-28  7:31     ` Rex-BC Chen
2022-03-28  7:31     ` Rex-BC Chen
2022-03-27 22:39 ` [PATCH v9 09/22] drm/mediatek: dpi: implement a swap_input " Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-28  8:33   ` Rex-BC Chen
2022-03-28  8:33     ` Rex-BC Chen
2022-03-28  8:33     ` Rex-BC Chen
2022-03-28  8:33     ` Rex-BC Chen
2022-03-28  8:33     ` Rex-BC Chen
2022-03-27 22:39 ` [PATCH v9 10/22] drm/mediatek: dpi: move dimension mask to " Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-28  8:33   ` Rex-BC Chen
2022-03-28  8:33     ` Rex-BC Chen
2022-03-28  8:33     ` Rex-BC Chen
2022-03-28  8:33     ` Rex-BC Chen
2022-03-28  8:33     ` Rex-BC Chen
2022-03-27 22:39 ` [PATCH v9 11/22] drm/mediatek: dpi: move hvsize_mask " Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-28  8:34   ` Rex-BC Chen
2022-03-28  8:34     ` Rex-BC Chen
2022-03-28  8:34     ` Rex-BC Chen
2022-03-28  8:34     ` Rex-BC Chen
2022-03-28  8:34     ` Rex-BC Chen
2022-03-27 22:39 ` [PATCH v9 12/22] drm/mediatek: dpi: move swap_shift " Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-28  8:20   ` AngeloGioacchino Del Regno
2022-03-28  8:20     ` AngeloGioacchino Del Regno
2022-03-28  8:20     ` AngeloGioacchino Del Regno
2022-03-28  8:20     ` AngeloGioacchino Del Regno
2022-03-28  8:20     ` AngeloGioacchino Del Regno
2022-03-28  8:34   ` Rex-BC Chen
2022-03-28  8:34     ` Rex-BC Chen
2022-03-28  8:34     ` Rex-BC Chen
2022-03-28  8:34     ` Rex-BC Chen
2022-03-28  8:34     ` Rex-BC Chen
2022-03-27 22:39 ` [PATCH v9 13/22] drm/mediatek: dpi: move the yuv422_en_bit " Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-28  8:54   ` Rex-BC Chen
2022-03-28  8:54     ` Rex-BC Chen
2022-03-28  8:54     ` Rex-BC Chen
2022-03-28  8:54     ` Rex-BC Chen
2022-03-28  8:54     ` Rex-BC Chen
2022-03-27 22:39 ` [PATCH v9 14/22] drm/mediatek: dpi: move the csc_enable bit " Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-28  8:35   ` Rex-BC Chen
2022-03-28  8:35     ` Rex-BC Chen
2022-03-28  8:35     ` Rex-BC Chen
2022-03-28  8:35     ` Rex-BC Chen
2022-03-28  8:35     ` Rex-BC Chen
2022-03-27 22:39 ` [PATCH v9 15/22] drm/mediatek: dpi: Add dpintf support Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-28  8:38   ` Rex-BC Chen
2022-03-28  8:38     ` Rex-BC Chen
2022-03-28  8:38     ` Rex-BC Chen
2022-03-28  8:38     ` Rex-BC Chen
2022-03-28  8:38     ` Rex-BC Chen
2022-04-12  9:10     ` Guillaume Ranquet
2022-04-12  9:10       ` Guillaume Ranquet
2022-04-12  9:10       ` Guillaume Ranquet
2022-04-12  9:10       ` Guillaume Ranquet
2022-04-12  9:10       ` Guillaume Ranquet
2022-03-29  3:16   ` Rex-BC Chen
2022-03-29  3:16     ` Rex-BC Chen
2022-03-29  3:16     ` Rex-BC Chen
2022-03-29  3:16     ` Rex-BC Chen
2022-03-29  3:16     ` Rex-BC Chen
2022-04-12  9:12     ` Guillaume Ranquet
2022-04-12  9:12       ` Guillaume Ranquet
2022-04-12  9:12       ` Guillaume Ranquet
2022-04-12  9:12       ` Guillaume Ranquet
2022-04-12  9:12       ` Guillaume Ranquet
2022-03-27 22:39 ` [PATCH v9 16/22] drm/meditek: dpi: Add matrix_sel helper Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-28  8:49   ` Rex-BC Chen
2022-03-28  8:49     ` Rex-BC Chen
2022-03-28  8:49     ` Rex-BC Chen
2022-03-28  8:49     ` Rex-BC Chen
2022-03-28  8:49     ` Rex-BC Chen
2022-04-12  9:37     ` Guillaume Ranquet
2022-04-12  9:37       ` Guillaume Ranquet
2022-04-12  9:37       ` Guillaume Ranquet
2022-04-12  9:37       ` Guillaume Ranquet
2022-04-12  9:37       ` Guillaume Ranquet
2022-03-27 22:39 ` [PATCH v9 17/22] phy: phy-mtk-dp: Add driver for DP phy Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-28  8:20   ` AngeloGioacchino Del Regno
2022-03-28  8:20     ` AngeloGioacchino Del Regno
2022-03-28  8:20     ` AngeloGioacchino Del Regno
2022-03-28  8:20     ` AngeloGioacchino Del Regno
2022-03-28  8:20     ` AngeloGioacchino Del Regno
2022-04-12  9:04     ` Guillaume Ranquet
2022-04-12  9:04       ` Guillaume Ranquet
2022-04-12  9:04       ` Guillaume Ranquet
2022-04-12  9:04       ` Guillaume Ranquet
2022-04-12  9:04       ` Guillaume Ranquet
2022-03-27 22:39 ` [PATCH v9 18/22] drm/mediatek: Add mt8195 Embedded DisplayPort driver Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-28  9:14   ` AngeloGioacchino Del Regno [this message]
2022-03-28  9:14     ` AngeloGioacchino Del Regno
2022-03-28  9:14     ` AngeloGioacchino Del Regno
2022-03-28  9:14     ` AngeloGioacchino Del Regno
2022-03-28  9:14     ` AngeloGioacchino Del Regno
2022-04-12  9:46     ` Guillaume Ranquet
2022-04-12  9:46       ` Guillaume Ranquet
2022-04-12  9:46       ` Guillaume Ranquet
2022-04-12  9:46       ` Guillaume Ranquet
2022-04-12  9:46       ` Guillaume Ranquet
2022-04-13  7:50       ` AngeloGioacchino Del Regno
2022-04-13  7:50         ` AngeloGioacchino Del Regno
2022-04-13  7:50         ` AngeloGioacchino Del Regno
2022-04-13  7:50         ` AngeloGioacchino Del Regno
2022-04-13  7:50         ` AngeloGioacchino Del Regno
2022-03-29  3:34   ` Rex-BC Chen
2022-03-29  3:34     ` Rex-BC Chen
2022-03-29  3:34     ` Rex-BC Chen
2022-03-29  3:34     ` Rex-BC Chen
2022-03-29  3:34     ` Rex-BC Chen
2022-04-12  9:48     ` Guillaume Ranquet
2022-04-12  9:48       ` Guillaume Ranquet
2022-04-12  9:48       ` Guillaume Ranquet
2022-04-12  9:48       ` Guillaume Ranquet
2022-04-12  9:48       ` Guillaume Ranquet
2022-03-29  5:41   ` Rex-BC Chen
2022-03-29  5:41     ` Rex-BC Chen
2022-03-29  5:41     ` Rex-BC Chen
2022-03-29  5:41     ` Rex-BC Chen
2022-03-29  5:41     ` Rex-BC Chen
2022-04-12 10:03     ` Guillaume Ranquet
2022-04-12 10:03       ` Guillaume Ranquet
2022-04-12 10:03       ` Guillaume Ranquet
2022-04-12 10:03       ` Guillaume Ranquet
2022-04-12 10:03       ` Guillaume Ranquet
2022-04-29  8:39   ` Maxime Ripard
2022-04-29  8:39     ` Maxime Ripard
2022-04-29  8:39     ` Maxime Ripard
2022-04-29  8:39     ` Maxime Ripard
2022-04-29  8:39     ` Maxime Ripard
2022-05-11 12:59     ` Guillaume Ranquet
2022-05-11 12:59       ` Guillaume Ranquet
2022-05-11 12:59       ` Guillaume Ranquet
2022-05-11 12:59       ` Guillaume Ranquet
2022-05-11 12:59       ` Guillaume Ranquet
2022-05-12  7:44       ` Maxime Ripard
2022-05-12  7:44         ` Maxime Ripard
2022-05-12  7:44         ` Maxime Ripard
2022-05-12  7:44         ` Maxime Ripard
2022-05-12  7:44         ` Maxime Ripard
2022-05-19 16:26         ` Guillaume Ranquet
2022-05-19 16:26           ` Guillaume Ranquet
2022-05-19 16:26           ` Guillaume Ranquet
2022-05-19 16:26           ` Guillaume Ranquet
2022-05-19 16:26           ` Guillaume Ranquet
2022-05-25  9:44           ` Maxime Ripard
2022-05-25  9:44             ` Maxime Ripard
2022-05-25  9:44             ` Maxime Ripard
2022-05-25  9:44             ` Maxime Ripard
2022-05-25  9:44             ` Maxime Ripard
2022-03-27 22:39 ` [PATCH v9 19/22] drm/mediatek: Add mt8195 External DisplayPort support Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39 ` [PATCH v9 20/22] drm/mediatek: add hpd debounce Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39 ` [PATCH v9 21/22] drm/mediatek: change the aux retries times when receiving AUX_DEFER Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-28  1:46   ` Rex-BC Chen
2022-03-28  1:46     ` Rex-BC Chen
2022-03-28  1:46     ` Rex-BC Chen
2022-03-28  1:46     ` Rex-BC Chen
2022-03-28  1:46     ` Rex-BC Chen
2022-03-27 22:39 ` [PATCH v9 22/22] drm/mediatek: DP audio support for mt8195 Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet
2022-03-27 22:39   ` Guillaume Ranquet

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=9a31c1ce-829b-acc7-6fc1-2a9df45e5c38@collabora.com \
    --to=angelogioacchino.delregno@collabora.com \
    --cc=airlied@linux.ie \
    --cc=chunfeng.yun@mediatek.com \
    --cc=chunkuang.hu@kernel.org \
    --cc=ck.hu@mediatek.com \
    --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=kishon@ti.com \
    --cc=krzk+dt@kernel.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=linux-phy@lists.infradead.org \
    --cc=lkp@intel.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=markyacoub@google.com \
    --cc=matthias.bgg@gmail.com \
    --cc=mripard@kernel.org \
    --cc=msp@baylibre.com \
    --cc=p.zabel@pengutronix.de \
    --cc=robh+dt@kernel.org \
    --cc=tzimmermann@suse.de \
    --cc=vkoul@kernel.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.