All of lore.kernel.org
 help / color / mirror / Atom feed
From: CK Hu <ck.hu@mediatek.com>
To: YT Shen <yt.shen@mediatek.com>
Cc: <dri-devel@lists.freedesktop.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	David Airlie <airlied@linux.ie>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Daniel Kurtz <djkurtz@chromium.org>,
	Mao Huang <littlecvr@chromium.org>,
	Bibby Hsieh <bibby.hsieh@mediatek.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	Thierry Reding <thierry.reding@gmail.com>,
	Jie Qiu <jie.qiu@mediatek.com>,
	Maxime Ripard <maxime.ripard@free-electrons.com>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	shaoming chen <shaoming.chen@mediatek.com>,
	Jitao Shi <jitao.shi@mediatek.com>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <srv_heupstream@mediatek.com>,
	Sascha Hauer <kernel@pengutronix.de>, <yingjoe.chen@mediatek.com>,
	<emil.l.velikov@gmail.com>
Subject: Re: [PATCH v8 8/9] drm/mediatek: update DSI sub driver flow
Date: Wed, 14 Sep 2016 13:42:21 +0800	[thread overview]
Message-ID: <1473831741.28437.78.camel@mtksdaap41> (raw)
In-Reply-To: <1473681672-47144-9-git-send-email-yt.shen@mediatek.com>

Hi, YT:

On Mon, 2016-09-12 at 20:01 +0800, YT Shen wrote:
> This patch update enable/disable flow of DSI module and MIPI TX module.
> Original flow works on there is a bridge chip: DSI -> bridge -> panel.
> In this case: DSI -> panel, the DSI sub driver flow should be updated.
> We need to initialize DSI first so that we can send commands to panel.
> 
> Signed-off-by: shaoming chen <shaoming.chen@mediatek.com>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
> ---
>  

[snip...]

>  
> +static void mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi)
> +{
> +	s32 ret = 0;
> +	unsigned long timeout = msecs_to_jiffies(500);
> +
> +	mtk_dsi_irq_data_clear(dsi, VM_DONE_INT_FLAG);
> +	mtk_dsi_set_cmd_mode(dsi);
> +
> +	ret = wait_event_interruptible_timeout(dsi->irq_wait_queue,
> +					       dsi->irq_data & VM_DONE_INT_FLAG,
> +					       timeout);
> +	if (ret == 0) {
> +		dev_info(dsi->dev, "dsi wait engine idle timeout\n");
> +
> +		mtk_dsi_enable(dsi);
> +		mtk_dsi_reset_engine(dsi);
> +	}

I think you should replace this event-waiting with
mtk_dsi_wait_for_irq_done(). And this is a reason for moving
mtk_dsi_wait_for_irq_done() to the patch of irq control.

> +}
> +
>  static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>  {
>  	if (WARN_ON(dsi->refcount == 0))
> @@ -528,6 +574,17 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>  	if (--dsi->refcount != 0)
>  		return;
>  
> +	mtk_dsi_switch_to_cmd_mode(dsi);
> +
> +	if (dsi->panel) {
> +		if (drm_panel_unprepare(dsi->panel)) {
> +			DRM_ERROR("failed to unprepare the panel\n");
> +			return;
> +		}
> +	}

I think drm_panel_unprepare should be placed after dsi is disabled. So
move this part after calling mtk_dsi_poweroff() in
mtk_output_dsi_disable().

> +
> +	mtk_dsi_reset_engine(dsi);
> +
>  	mtk_dsi_lane0_ulp_mode_enter(dsi);
>  	mtk_dsi_clk_ulp_mode_enter(dsi);
>  
> @@ -546,29 +603,37 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
>  	if (dsi->enabled)
>  		return;
>  
> -	if (dsi->panel) {
> -		if (drm_panel_prepare(dsi->panel)) {
> -			DRM_ERROR("failed to setup the panel\n");
> -			return;
> -		}
> -	}
> -
>  	ret = mtk_dsi_poweron(dsi);
>  	if (ret < 0) {
>  		DRM_ERROR("failed to power on dsi\n");
>  		return;
>  	}
>  
> +	usleep_range(20000, 21000);
> +
>  	mtk_dsi_rxtx_control(dsi);
> +	mtk_dsi_phy_timconfig(dsi);
> +	mtk_dsi_ps_control_vact(dsi);
> +	mtk_dsi_set_vm_cmd(dsi);
> +	mtk_dsi_config_vdo_timing(dsi);
> +	mtk_dsi_set_interrupt_enable(dsi);
>  
> +	mtk_dsi_enable(dsi);
>  	mtk_dsi_clk_ulp_mode_leave(dsi);
>  	mtk_dsi_lane0_ulp_mode_leave(dsi);
>  	mtk_dsi_clk_hs_mode(dsi, 0);
> -	mtk_dsi_set_mode(dsi);
>  
> -	mtk_dsi_ps_control_vact(dsi);
> -	mtk_dsi_config_vdo_timing(dsi);
> -	mtk_dsi_set_interrupt_enable(dsi);
> +	if (dsi->panel) {
> +		if (drm_panel_prepare(dsi->panel)) {
> +			DRM_ERROR("failed to prepare the panel\n");
> +			return;
> +		}
> +
> +		if (drm_panel_enable(dsi->panel)) {
> +			DRM_ERROR("failed to enable the panel\n");
> +			return;
> +		}
> +	}

I think drm_panel_prepare() should be called before DSI is enabled and
drm_panel_enable() should be called after DSI is enabled. But you may
encounter the problem that panel need transfer data when prepare and you
can refer to [1].

[1]
http://lxr.free-electrons.com/source/drivers/gpu/drm/exynos/exynos_drm_dsi.c#L1431

>  
>  	mtk_dsi_set_mode(dsi);
>  	mtk_dsi_clk_hs_mode(dsi, 1);
> @@ -590,6 +655,7 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
>  		}
>  	}
>  
> +	mtk_dsi_stop(dsi);
>  	mtk_dsi_poweroff(dsi);
>  
>  	dsi->enabled = false;
> diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> index 108d31a..34e95c6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> @@ -177,7 +177,9 @@ static int mtk_mipi_tx_pll_prepare(struct clk_hw *hw)
>  
>  	dev_dbg(mipi_tx->dev, "prepare: %u Hz\n", mipi_tx->data_rate);
>  
> -	if (mipi_tx->data_rate >= 500000000) {
> +	if (mipi_tx->data_rate > 1250000000) {
> +		return -EINVAL;
> +	} else if (mipi_tx->data_rate >= 500000000) {

What is the relationship of this part and "DSI driver flow"? Would this
be an independent patch?

>  		txdiv = 1;
>  		txdiv0 = 0;
>  		txdiv1 = 0;
> @@ -201,6 +203,10 @@ static int mtk_mipi_tx_pll_prepare(struct clk_hw *hw)
>  		return -EINVAL;
>  	}
>  
> +	mtk_mipi_tx_update_bits(mipi_tx, MIPITX_DSI_TOP_CON,
> +				RG_DSI_LNT_IMP_CAL_CODE | RG_DSI_LNT_HS_BIAS_EN,
> +				(8 << 4) | RG_DSI_LNT_HS_BIAS_EN);
> +
>  	mtk_mipi_tx_update_bits(mipi_tx, MIPITX_DSI_BG_CON,
>  				RG_DSI_VOUT_MSK |
>  				RG_DSI_BG_CKEN | RG_DSI_BG_CORE_EN,
>  

You modify many place without 'if (dsi->panel)'. Are all these
modifications compatible with bridge case?

Regards,
CK

WARNING: multiple messages have this Message-ID (diff)
From: CK Hu <ck.hu@mediatek.com>
To: YT Shen <yt.shen@mediatek.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Jie Qiu <jie.qiu@mediatek.com>,
	Mao Huang <littlecvr@chromium.org>,
	yingjoe.chen@mediatek.com,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Jitao Shi <jitao.shi@mediatek.com>,
	Sascha Hauer <kernel@pengutronix.de>,
	linux-mediatek@lists.infradead.org,
	dri-devel@lists.freedesktop.org,
	Matthias Brugger <matthias.bgg@gmail.com>,
	shaoming chen <shaoming.chen@mediatek.com>,
	linux-arm-kernel@lists.infradead.org,
	srv_heupstream@mediatek.com, emil.l.velikov@gmail.com,
	linux-kernel@vger.kernel.org,
	Maxime Ripard <maxime.ripard@free-electrons.com>
Subject: Re: [PATCH v8 8/9] drm/mediatek: update DSI sub driver flow
Date: Wed, 14 Sep 2016 13:42:21 +0800	[thread overview]
Message-ID: <1473831741.28437.78.camel@mtksdaap41> (raw)
In-Reply-To: <1473681672-47144-9-git-send-email-yt.shen@mediatek.com>

Hi, YT:

On Mon, 2016-09-12 at 20:01 +0800, YT Shen wrote:
> This patch update enable/disable flow of DSI module and MIPI TX module.
> Original flow works on there is a bridge chip: DSI -> bridge -> panel.
> In this case: DSI -> panel, the DSI sub driver flow should be updated.
> We need to initialize DSI first so that we can send commands to panel.
> 
> Signed-off-by: shaoming chen <shaoming.chen@mediatek.com>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
> ---
>  

[snip...]

>  
> +static void mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi)
> +{
> +	s32 ret = 0;
> +	unsigned long timeout = msecs_to_jiffies(500);
> +
> +	mtk_dsi_irq_data_clear(dsi, VM_DONE_INT_FLAG);
> +	mtk_dsi_set_cmd_mode(dsi);
> +
> +	ret = wait_event_interruptible_timeout(dsi->irq_wait_queue,
> +					       dsi->irq_data & VM_DONE_INT_FLAG,
> +					       timeout);
> +	if (ret == 0) {
> +		dev_info(dsi->dev, "dsi wait engine idle timeout\n");
> +
> +		mtk_dsi_enable(dsi);
> +		mtk_dsi_reset_engine(dsi);
> +	}

I think you should replace this event-waiting with
mtk_dsi_wait_for_irq_done(). And this is a reason for moving
mtk_dsi_wait_for_irq_done() to the patch of irq control.

> +}
> +
>  static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>  {
>  	if (WARN_ON(dsi->refcount == 0))
> @@ -528,6 +574,17 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>  	if (--dsi->refcount != 0)
>  		return;
>  
> +	mtk_dsi_switch_to_cmd_mode(dsi);
> +
> +	if (dsi->panel) {
> +		if (drm_panel_unprepare(dsi->panel)) {
> +			DRM_ERROR("failed to unprepare the panel\n");
> +			return;
> +		}
> +	}

I think drm_panel_unprepare should be placed after dsi is disabled. So
move this part after calling mtk_dsi_poweroff() in
mtk_output_dsi_disable().

> +
> +	mtk_dsi_reset_engine(dsi);
> +
>  	mtk_dsi_lane0_ulp_mode_enter(dsi);
>  	mtk_dsi_clk_ulp_mode_enter(dsi);
>  
> @@ -546,29 +603,37 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
>  	if (dsi->enabled)
>  		return;
>  
> -	if (dsi->panel) {
> -		if (drm_panel_prepare(dsi->panel)) {
> -			DRM_ERROR("failed to setup the panel\n");
> -			return;
> -		}
> -	}
> -
>  	ret = mtk_dsi_poweron(dsi);
>  	if (ret < 0) {
>  		DRM_ERROR("failed to power on dsi\n");
>  		return;
>  	}
>  
> +	usleep_range(20000, 21000);
> +
>  	mtk_dsi_rxtx_control(dsi);
> +	mtk_dsi_phy_timconfig(dsi);
> +	mtk_dsi_ps_control_vact(dsi);
> +	mtk_dsi_set_vm_cmd(dsi);
> +	mtk_dsi_config_vdo_timing(dsi);
> +	mtk_dsi_set_interrupt_enable(dsi);
>  
> +	mtk_dsi_enable(dsi);
>  	mtk_dsi_clk_ulp_mode_leave(dsi);
>  	mtk_dsi_lane0_ulp_mode_leave(dsi);
>  	mtk_dsi_clk_hs_mode(dsi, 0);
> -	mtk_dsi_set_mode(dsi);
>  
> -	mtk_dsi_ps_control_vact(dsi);
> -	mtk_dsi_config_vdo_timing(dsi);
> -	mtk_dsi_set_interrupt_enable(dsi);
> +	if (dsi->panel) {
> +		if (drm_panel_prepare(dsi->panel)) {
> +			DRM_ERROR("failed to prepare the panel\n");
> +			return;
> +		}
> +
> +		if (drm_panel_enable(dsi->panel)) {
> +			DRM_ERROR("failed to enable the panel\n");
> +			return;
> +		}
> +	}

I think drm_panel_prepare() should be called before DSI is enabled and
drm_panel_enable() should be called after DSI is enabled. But you may
encounter the problem that panel need transfer data when prepare and you
can refer to [1].

[1]
http://lxr.free-electrons.com/source/drivers/gpu/drm/exynos/exynos_drm_dsi.c#L1431

>  
>  	mtk_dsi_set_mode(dsi);
>  	mtk_dsi_clk_hs_mode(dsi, 1);
> @@ -590,6 +655,7 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
>  		}
>  	}
>  
> +	mtk_dsi_stop(dsi);
>  	mtk_dsi_poweroff(dsi);
>  
>  	dsi->enabled = false;
> diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> index 108d31a..34e95c6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> @@ -177,7 +177,9 @@ static int mtk_mipi_tx_pll_prepare(struct clk_hw *hw)
>  
>  	dev_dbg(mipi_tx->dev, "prepare: %u Hz\n", mipi_tx->data_rate);
>  
> -	if (mipi_tx->data_rate >= 500000000) {
> +	if (mipi_tx->data_rate > 1250000000) {
> +		return -EINVAL;
> +	} else if (mipi_tx->data_rate >= 500000000) {

What is the relationship of this part and "DSI driver flow"? Would this
be an independent patch?

>  		txdiv = 1;
>  		txdiv0 = 0;
>  		txdiv1 = 0;
> @@ -201,6 +203,10 @@ static int mtk_mipi_tx_pll_prepare(struct clk_hw *hw)
>  		return -EINVAL;
>  	}
>  
> +	mtk_mipi_tx_update_bits(mipi_tx, MIPITX_DSI_TOP_CON,
> +				RG_DSI_LNT_IMP_CAL_CODE | RG_DSI_LNT_HS_BIAS_EN,
> +				(8 << 4) | RG_DSI_LNT_HS_BIAS_EN);
> +
>  	mtk_mipi_tx_update_bits(mipi_tx, MIPITX_DSI_BG_CON,
>  				RG_DSI_VOUT_MSK |
>  				RG_DSI_BG_CKEN | RG_DSI_BG_CORE_EN,
>  

You modify many place without 'if (dsi->panel)'. Are all these
modifications compatible with bridge case?

Regards,
CK

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: ck.hu@mediatek.com (CK Hu)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v8 8/9] drm/mediatek: update DSI sub driver flow
Date: Wed, 14 Sep 2016 13:42:21 +0800	[thread overview]
Message-ID: <1473831741.28437.78.camel@mtksdaap41> (raw)
In-Reply-To: <1473681672-47144-9-git-send-email-yt.shen@mediatek.com>

Hi, YT:

On Mon, 2016-09-12 at 20:01 +0800, YT Shen wrote:
> This patch update enable/disable flow of DSI module and MIPI TX module.
> Original flow works on there is a bridge chip: DSI -> bridge -> panel.
> In this case: DSI -> panel, the DSI sub driver flow should be updated.
> We need to initialize DSI first so that we can send commands to panel.
> 
> Signed-off-by: shaoming chen <shaoming.chen@mediatek.com>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
> ---
>  

[snip...]

>  
> +static void mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi)
> +{
> +	s32 ret = 0;
> +	unsigned long timeout = msecs_to_jiffies(500);
> +
> +	mtk_dsi_irq_data_clear(dsi, VM_DONE_INT_FLAG);
> +	mtk_dsi_set_cmd_mode(dsi);
> +
> +	ret = wait_event_interruptible_timeout(dsi->irq_wait_queue,
> +					       dsi->irq_data & VM_DONE_INT_FLAG,
> +					       timeout);
> +	if (ret == 0) {
> +		dev_info(dsi->dev, "dsi wait engine idle timeout\n");
> +
> +		mtk_dsi_enable(dsi);
> +		mtk_dsi_reset_engine(dsi);
> +	}

I think you should replace this event-waiting with
mtk_dsi_wait_for_irq_done(). And this is a reason for moving
mtk_dsi_wait_for_irq_done() to the patch of irq control.

> +}
> +
>  static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>  {
>  	if (WARN_ON(dsi->refcount == 0))
> @@ -528,6 +574,17 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>  	if (--dsi->refcount != 0)
>  		return;
>  
> +	mtk_dsi_switch_to_cmd_mode(dsi);
> +
> +	if (dsi->panel) {
> +		if (drm_panel_unprepare(dsi->panel)) {
> +			DRM_ERROR("failed to unprepare the panel\n");
> +			return;
> +		}
> +	}

I think drm_panel_unprepare should be placed after dsi is disabled. So
move this part after calling mtk_dsi_poweroff() in
mtk_output_dsi_disable().

> +
> +	mtk_dsi_reset_engine(dsi);
> +
>  	mtk_dsi_lane0_ulp_mode_enter(dsi);
>  	mtk_dsi_clk_ulp_mode_enter(dsi);
>  
> @@ -546,29 +603,37 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
>  	if (dsi->enabled)
>  		return;
>  
> -	if (dsi->panel) {
> -		if (drm_panel_prepare(dsi->panel)) {
> -			DRM_ERROR("failed to setup the panel\n");
> -			return;
> -		}
> -	}
> -
>  	ret = mtk_dsi_poweron(dsi);
>  	if (ret < 0) {
>  		DRM_ERROR("failed to power on dsi\n");
>  		return;
>  	}
>  
> +	usleep_range(20000, 21000);
> +
>  	mtk_dsi_rxtx_control(dsi);
> +	mtk_dsi_phy_timconfig(dsi);
> +	mtk_dsi_ps_control_vact(dsi);
> +	mtk_dsi_set_vm_cmd(dsi);
> +	mtk_dsi_config_vdo_timing(dsi);
> +	mtk_dsi_set_interrupt_enable(dsi);
>  
> +	mtk_dsi_enable(dsi);
>  	mtk_dsi_clk_ulp_mode_leave(dsi);
>  	mtk_dsi_lane0_ulp_mode_leave(dsi);
>  	mtk_dsi_clk_hs_mode(dsi, 0);
> -	mtk_dsi_set_mode(dsi);
>  
> -	mtk_dsi_ps_control_vact(dsi);
> -	mtk_dsi_config_vdo_timing(dsi);
> -	mtk_dsi_set_interrupt_enable(dsi);
> +	if (dsi->panel) {
> +		if (drm_panel_prepare(dsi->panel)) {
> +			DRM_ERROR("failed to prepare the panel\n");
> +			return;
> +		}
> +
> +		if (drm_panel_enable(dsi->panel)) {
> +			DRM_ERROR("failed to enable the panel\n");
> +			return;
> +		}
> +	}

I think drm_panel_prepare() should be called before DSI is enabled and
drm_panel_enable() should be called after DSI is enabled. But you may
encounter the problem that panel need transfer data when prepare and you
can refer to [1].

[1]
http://lxr.free-electrons.com/source/drivers/gpu/drm/exynos/exynos_drm_dsi.c#L1431

>  
>  	mtk_dsi_set_mode(dsi);
>  	mtk_dsi_clk_hs_mode(dsi, 1);
> @@ -590,6 +655,7 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
>  		}
>  	}
>  
> +	mtk_dsi_stop(dsi);
>  	mtk_dsi_poweroff(dsi);
>  
>  	dsi->enabled = false;
> diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> index 108d31a..34e95c6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> @@ -177,7 +177,9 @@ static int mtk_mipi_tx_pll_prepare(struct clk_hw *hw)
>  
>  	dev_dbg(mipi_tx->dev, "prepare: %u Hz\n", mipi_tx->data_rate);
>  
> -	if (mipi_tx->data_rate >= 500000000) {
> +	if (mipi_tx->data_rate > 1250000000) {
> +		return -EINVAL;
> +	} else if (mipi_tx->data_rate >= 500000000) {

What is the relationship of this part and "DSI driver flow"? Would this
be an independent patch?

>  		txdiv = 1;
>  		txdiv0 = 0;
>  		txdiv1 = 0;
> @@ -201,6 +203,10 @@ static int mtk_mipi_tx_pll_prepare(struct clk_hw *hw)
>  		return -EINVAL;
>  	}
>  
> +	mtk_mipi_tx_update_bits(mipi_tx, MIPITX_DSI_TOP_CON,
> +				RG_DSI_LNT_IMP_CAL_CODE | RG_DSI_LNT_HS_BIAS_EN,
> +				(8 << 4) | RG_DSI_LNT_HS_BIAS_EN);
> +
>  	mtk_mipi_tx_update_bits(mipi_tx, MIPITX_DSI_BG_CON,
>  				RG_DSI_VOUT_MSK |
>  				RG_DSI_BG_CKEN | RG_DSI_BG_CORE_EN,
>  

You modify many place without 'if (dsi->panel)'. Are all these
modifications compatible with bridge case?

Regards,
CK

  reply	other threads:[~2016-09-14  5:42 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-12 12:01 [PATCH v8 0/9] MT2701 DRM support YT Shen
2016-09-12 12:01 ` YT Shen
2016-09-12 12:01 ` YT Shen
2016-09-12 12:01 ` [PATCH v8 1/9] drm/mediatek: rename macros, add chip prefix YT Shen
2016-09-12 12:01   ` YT Shen
2016-09-12 12:01   ` YT Shen
2016-09-12 12:01 ` [PATCH v8 2/9] drm/mediatek: add *driver_data for different hardware settings YT Shen
2016-09-12 12:01   ` YT Shen
2016-09-12 12:01   ` YT Shen
2016-09-12 12:01 ` [PATCH v8 3/9] drm/mediatek: add shadow register support YT Shen
2016-09-12 12:01   ` YT Shen
2016-09-12 12:01   ` YT Shen
2016-09-12 12:01 ` [PATCH v8 4/9] drm/mediatek: update display module connections YT Shen
2016-09-12 12:01   ` YT Shen
2016-09-12 12:01   ` YT Shen
2016-09-13  9:41   ` CK Hu
2016-09-13  9:41     ` CK Hu
2016-09-13  9:41     ` CK Hu
2016-09-12 12:01 ` [PATCH v8 5/9] drm/mediatek: cleaning up and refine YT Shen
2016-09-12 12:01   ` YT Shen
2016-09-12 12:01   ` YT Shen
2016-09-12 12:01 ` [PATCH v8 6/9] drm/mediatek: add dsi interrupt control YT Shen
2016-09-12 12:01   ` YT Shen
2016-09-12 12:01   ` YT Shen
2016-09-13  8:55   ` CK Hu
2016-09-13  8:55     ` CK Hu
2016-09-13  8:55     ` CK Hu
2016-09-12 12:01 ` [PATCH v8 7/9] drm/mediatek: add dsi transfer function YT Shen
2016-09-12 12:01   ` YT Shen
2016-09-12 12:01   ` YT Shen
2016-09-12 12:01 ` [PATCH v8 8/9] drm/mediatek: update DSI sub driver flow YT Shen
2016-09-12 12:01   ` YT Shen
2016-09-12 12:01   ` YT Shen
2016-09-14  5:42   ` CK Hu [this message]
2016-09-14  5:42     ` CK Hu
2016-09-14  5:42     ` CK Hu
2016-09-12 12:01 ` [PATCH v8 9/9] drm/mediatek: add support for Mediatek SoC MT2701 YT Shen
2016-09-12 12:01   ` YT Shen
2016-09-12 12:01   ` YT Shen
2016-09-19  1:08   ` CK Hu
2016-09-19  1:08     ` CK Hu
2016-09-19  1:08     ` CK Hu

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=1473831741.28437.78.camel@mtksdaap41 \
    --to=ck.hu@mediatek.com \
    --cc=airlied@linux.ie \
    --cc=bibby.hsieh@mediatek.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=dan.carpenter@oracle.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=djkurtz@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emil.l.velikov@gmail.com \
    --cc=jie.qiu@mediatek.com \
    --cc=jitao.shi@mediatek.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=littlecvr@chromium.org \
    --cc=matthias.bgg@gmail.com \
    --cc=maxime.ripard@free-electrons.com \
    --cc=p.zabel@pengutronix.de \
    --cc=shaoming.chen@mediatek.com \
    --cc=srv_heupstream@mediatek.com \
    --cc=thierry.reding@gmail.com \
    --cc=yingjoe.chen@mediatek.com \
    --cc=yt.shen@mediatek.com \
    /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.