Linux-mediatek Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/6] phy: phy-mt65xx-usb3: add reference clock of usb3 analog phy
From: Chunfeng Yun @ 2017-01-18  5:51 UTC (permalink / raw)
  To: Kishon Vijay Abraham I
  Cc: Matthias Brugger, Felipe Balbi, Chunfeng Yun, linux-kernel,
	linux-arm-kernel, linux-usb, linux-mediatek

usually, the reference clock of usb3 analog phy comes from
26M oscillator directly, but some SoCs are not, add it for
compatibility.

Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
 drivers/phy/phy-mt65xx-usb3.c |   36 ++++++++++++++++++++++++++++--------
 1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index d972067..fc9a4f0 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -149,7 +149,8 @@ struct mt65xx_phy_instance {
 struct mt65xx_u3phy {
 	struct device *dev;
 	void __iomem *sif_base;	/* include sif2, but exclude port's */
-	struct clk *u3phya_ref;	/* reference clock of usb3 anolog phy */
+	struct clk *u2ref_clk;	/* reference clock of u2 analog phy */
+	struct clk *u3ref_clk;	/* reference clock of u3 analog phy */
 	const struct mt65xx_phy_pdata *pdata;
 	struct mt65xx_phy_instance **phys;
 	int nphys;
@@ -429,11 +430,17 @@ static int mt65xx_phy_init(struct phy *phy)
 {
 	struct mt65xx_phy_instance *instance = phy_get_drvdata(phy);
 	struct mt65xx_u3phy *u3phy = dev_get_drvdata(phy->dev.parent);
+	struct clk *ref_clk;
 	int ret;
 
-	ret = clk_prepare_enable(u3phy->u3phya_ref);
+	if (instance->type == PHY_TYPE_USB2)
+		ref_clk = u3phy->u2ref_clk;
+	else
+		ref_clk = u3phy->u3ref_clk;
+
+	ret = clk_prepare_enable(ref_clk);
 	if (ret) {
-		dev_err(u3phy->dev, "failed to enable u3phya_ref\n");
+		dev_err(u3phy->dev, "failed to enable ref clk\n");
 		return ret;
 	}
 
@@ -464,9 +471,16 @@ static int mt65xx_phy_exit(struct phy *phy)
 {
 	struct mt65xx_phy_instance *instance = phy_get_drvdata(phy);
 	struct mt65xx_u3phy *u3phy = dev_get_drvdata(phy->dev.parent);
+	struct clk *ref_clk;
 
 	phy_instance_exit(u3phy, instance);
-	clk_disable_unprepare(u3phy->u3phya_ref);
+
+	if (instance->type == PHY_TYPE_USB2)
+		ref_clk = u3phy->u2ref_clk;
+	else
+		ref_clk = u3phy->u3ref_clk;
+
+	clk_disable_unprepare(ref_clk);
 	return 0;
 }
 
@@ -566,10 +580,16 @@ static int mt65xx_u3phy_probe(struct platform_device *pdev)
 		return PTR_ERR(u3phy->sif_base);
 	}
 
-	u3phy->u3phya_ref = devm_clk_get(dev, "u3phya_ref");
-	if (IS_ERR(u3phy->u3phya_ref)) {
-		dev_err(dev, "error to get u3phya_ref\n");
-		return PTR_ERR(u3phy->u3phya_ref);
+	u3phy->u2ref_clk = devm_clk_get(dev, "u2ref_clk");
+	if (IS_ERR(u3phy->u2ref_clk)) {
+		dev_err(dev, "failed to get u2ref_clk\n");
+		return PTR_ERR(u3phy->u2ref_clk);
+	}
+
+	u3phy->u3ref_clk = devm_clk_get(dev, "u3ref_clk");
+	if (IS_ERR(u3phy->u3ref_clk)) {
+		dev_err(dev, "failed to get u3ref_clk\n");
+		return PTR_ERR(u3phy->u3ref_clk);
 	}
 
 	port = 0;
-- 
1.7.9.5

^ permalink raw reply related

* Re: [PATCH -next] mtd: nand: mediatek: remove redundant dev_err call in mtk_nfc_probe()
From: Marek Vasut @ 2017-01-17 15:20 UTC (permalink / raw)
  To: Wei Yongjun, Boris Brezillon, Richard Weinberger, David Woodhouse,
	Brian Norris, Cyrille Pitchen, Matthias Brugger
  Cc: Wei Yongjun, linux-mtd, linux-arm-kernel, linux-mediatek,
	linux-kernel
In-Reply-To: <20170117142246.9607-1-weiyj.lk@gmail.com>

On 01/17/2017 03:22 PM, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
> 
> There is a error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
> 
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>

Acked-by: Marek Vasut <marek.vasut@gmail.com>

> ---
>  drivers/mtd/nand/mtk_nand.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/mtk_nand.c b/drivers/mtd/nand/mtk_nand.c
> index 6c3eed3..6c517c6 100644
> --- a/drivers/mtd/nand/mtk_nand.c
> +++ b/drivers/mtd/nand/mtk_nand.c
> @@ -1383,7 +1383,6 @@ static int mtk_nfc_probe(struct platform_device *pdev)
>  	nfc->regs = devm_ioremap_resource(dev, res);
>  	if (IS_ERR(nfc->regs)) {
>  		ret = PTR_ERR(nfc->regs);
> -		dev_err(dev, "no nfi base\n");
>  		goto release_ecc;
>  	}
>  
> 
> 
> 


-- 
Best regards,
Marek Vasut

^ permalink raw reply

* [PATCH -next] mtd: nand: mediatek: remove redundant dev_err call in mtk_nfc_probe()
From: Wei Yongjun @ 2017-01-17 14:22 UTC (permalink / raw)
  To: Boris Brezillon, Richard Weinberger, David Woodhouse,
	Brian Norris, Marek Vasut, Cyrille Pitchen, Matthias Brugger
  Cc: Wei Yongjun, linux-mtd, linux-arm-kernel, linux-mediatek,
	linux-kernel

From: Wei Yongjun <weiyongjun1@huawei.com>

There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.

Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
 drivers/mtd/nand/mtk_nand.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/mtd/nand/mtk_nand.c b/drivers/mtd/nand/mtk_nand.c
index 6c3eed3..6c517c6 100644
--- a/drivers/mtd/nand/mtk_nand.c
+++ b/drivers/mtd/nand/mtk_nand.c
@@ -1383,7 +1383,6 @@ static int mtk_nfc_probe(struct platform_device *pdev)
 	nfc->regs = devm_ioremap_resource(dev, res);
 	if (IS_ERR(nfc->regs)) {
 		ret = PTR_ERR(nfc->regs);
-		dev_err(dev, "no nfi base\n");
 		goto release_ecc;
 	}
 

^ permalink raw reply related

* [PATCH v2 3/3] mmc: mediatek: Use data tune for CMD line tune
From: Yong Mao @ 2017-01-17 12:55 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Linus Walleij,
	linux-mmc-u79uwXL29TY76Z2rM5mHXA, yong mao,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Chunfeng Yun,
	Eddie Huang, Chaotian Jing
In-Reply-To: <1484657703-5861-1-git-send-email-yong.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>

From: yong mao <yong.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>

If we don't select a set of better parameters for our emmc host,
It may easily occur CMD response CRC error.
And also it may cause cannot boot up issue.

Fot getting a set of better parameters,
our emmc host supports data tune mechanism.
Therefore, our emmc driver also should change
to use data tune for CMD line

Because our emmc host use the different clock source
to sample the CMD signal between HS200 and HS400 mode,
the parameters are also different between these two modes.
Separate cmd internal delay for HS200/HS400 mode

This change can fix "System can not boot up" issue

Signed-off-by: Yong Mao <yong.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Signed-off-by: Chaotian Jing <chaotian.jing-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
 drivers/mmc/host/mtk-sd.c |  169 ++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 152 insertions(+), 17 deletions(-)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 80ba034..26f9d3b 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -75,6 +75,7 @@
 #define MSDC_PATCH_BIT1  0xb4
 #define MSDC_PAD_TUNE    0xec
 #define PAD_DS_TUNE      0x188
+#define PAD_CMD_TUNE     0x18c
 #define EMMC50_CFG0      0x208
 
 /*--------------------------------------------------------------------------*/
@@ -210,13 +211,18 @@
 #define MSDC_PATCH_BIT_SPCPUSH    (0x1 << 29)	/* RW */
 #define MSDC_PATCH_BIT_DECRCTMO   (0x1 << 30)	/* RW */
 
+#define MSDC_PAD_TUNE_DATWRDLY    (0x1f <<  0)  /* RW */
 #define MSDC_PAD_TUNE_DATRRDLY	  (0x1f <<  8)	/* RW */
 #define MSDC_PAD_TUNE_CMDRDLY	  (0x1f << 16)  /* RW */
+#define MSDC_PAD_TUNE_CMDRRDLY    (0x1f << 22)  /* RW */
+#define MSDC_PAD_TUNE_CLKTDLY     (0x1f << 27)  /* RW */
 
 #define PAD_DS_TUNE_DLY1	  (0x1f << 2)   /* RW */
 #define PAD_DS_TUNE_DLY2	  (0x1f << 7)   /* RW */
 #define PAD_DS_TUNE_DLY3	  (0x1f << 12)  /* RW */
 
+#define PAD_CMD_TUNE_RX_DLY3      (0x1f << 1)   /* RW */
+
 #define EMMC50_CFG_PADCMD_LATCHCK (0x1 << 0)   /* RW */
 #define EMMC50_CFG_CRCSTS_EDGE    (0x1 << 3)   /* RW */
 #define EMMC50_CFG_CFCSTS_SEL     (0x1 << 4)   /* RW */
@@ -284,12 +290,14 @@ struct msdc_save_para {
 	u32 patch_bit0;
 	u32 patch_bit1;
 	u32 pad_ds_tune;
+	u32 pad_cmd_tune;
 	u32 emmc50_cfg0;
 };
 
 struct msdc_tune_para {
 	u32 iocon;
 	u32 pad_tune;
+	u32 pad_cmd_tune;
 };
 
 struct msdc_delay_phase {
@@ -331,6 +339,9 @@ struct msdc_host {
 	unsigned char timing;
 	bool vqmmc_enabled;
 	u32 hs400_ds_delay;
+	u32 hs200_cmd_int_delay; /* cmd internal delay for HS200/SDR104 */
+	u32 hs400_cmd_int_delay; /* cmd internal delay for HS400 */
+	u32 hs200_cmd_resp_sel; /* cmd response sample selection */
 	bool hs400_mode;	/* current eMMC will run at hs400 mode */
 	struct msdc_save_para save_para; /* used when gate HCLK */
 	struct msdc_tune_para def_tune_para; /* default tune setting */
@@ -600,8 +611,14 @@ static void msdc_set_mclk(struct msdc_host *host, unsigned char timing, u32 hz)
 	} else {
 		writel(host->saved_tune_para.iocon, host->base + MSDC_IOCON);
 		writel(host->saved_tune_para.pad_tune, host->base + MSDC_PAD_TUNE);
+		writel(host->saved_tune_para.pad_cmd_tune,
+		       host->base + PAD_CMD_TUNE);
 	}
 
+	if (timing == MMC_TIMING_MMC_HS400)
+		sdr_set_field(host->base + PAD_CMD_TUNE,
+			      MSDC_PAD_TUNE_CMDRRDLY,
+			      host->hs400_cmd_int_delay);
 	dev_dbg(host->dev, "sclk: %d, timing: %d\n", host->sclk, timing);
 }
 
@@ -1302,7 +1319,7 @@ static struct msdc_delay_phase get_best_delay(struct msdc_host *host, u32 delay)
 			len_final = len;
 		}
 		start += len ? len : 1;
-		if (len >= 8 && start_final < 4)
+		if (len >= 12 && start_final < 4)
 			break;
 	}
 
@@ -1325,36 +1342,66 @@ static int msdc_tune_response(struct mmc_host *mmc, u32 opcode)
 	struct msdc_host *host = mmc_priv(mmc);
 	u32 rise_delay = 0, fall_delay = 0;
 	struct msdc_delay_phase final_rise_delay, final_fall_delay = { 0,};
+	struct msdc_delay_phase internal_delay_phase;
 	u8 final_delay, final_maxlen;
+	u32 internal_delay = 0;
 	int cmd_err;
-	int i;
+	int i, j;
 
+	if (mmc->ios.timing == MMC_TIMING_MMC_HS200 ||
+	    mmc->ios.timing == MMC_TIMING_UHS_SDR104)
+		sdr_set_field(host->base + MSDC_PAD_TUNE,
+			      MSDC_PAD_TUNE_CMDRRDLY,
+			      host->hs200_cmd_int_delay);
 	sdr_clr_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
 	for (i = 0 ; i < PAD_DELAY_MAX; i++) {
 		sdr_set_field(host->base + MSDC_PAD_TUNE,
 			      MSDC_PAD_TUNE_CMDRDLY, i);
-		mmc_send_tuning(mmc, opcode, &cmd_err);
-		if (!cmd_err)
-			rise_delay |= (1 << i);
+		/*
+		 * Using the same parameters, it may sometimes pass the test,
+		 * but sometimes it may fail. To make sure the parameters is
+		 * more stable, we test 3 times for one set of parameters.
+		 */
+		for (j = 0; j < 3; j++) {
+			mmc_send_tuning(mmc, opcode, &cmd_err);
+			if (!cmd_err) {
+				rise_delay |= (1 << i);
+			} else {
+				rise_delay &= ~(1 << i);
+				break;
+			}
+		}
 	}
 	final_rise_delay = get_best_delay(host, rise_delay);
 	/* if rising edge has enough margin, then do not scan falling edge */
-	if (final_rise_delay.maxlen >= 10 ||
-	    (final_rise_delay.start == 0 && final_rise_delay.maxlen >= 4))
+	if (final_rise_delay.maxlen >= 12 && final_rise_delay.start < 4)
 		goto skip_fall;
 
 	sdr_set_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
 	for (i = 0; i < PAD_DELAY_MAX; i++) {
 		sdr_set_field(host->base + MSDC_PAD_TUNE,
 			      MSDC_PAD_TUNE_CMDRDLY, i);
-		mmc_send_tuning(mmc, opcode, &cmd_err);
-		if (!cmd_err)
-			fall_delay |= (1 << i);
+		/*
+		 * Using the same parameters, it may sometimes pass the test,
+		 * but sometimes it may fail. To make sure the parameters is
+		 * more stable, we test 3 times for one set of parameters.
+		 */
+		for (j = 0; j < 3; j++) {
+			mmc_send_tuning(mmc, opcode, &cmd_err);
+			if (!cmd_err) {
+				fall_delay |= (1 << i);
+			} else {
+				fall_delay &= ~(1 << i);
+				break;
+			};
+		}
 	}
 	final_fall_delay = get_best_delay(host, fall_delay);
 
 skip_fall:
 	final_maxlen = max(final_rise_delay.maxlen, final_fall_delay.maxlen);
+	if (final_fall_delay.maxlen >= 12 && final_fall_delay.start < 4)
+		final_maxlen = final_fall_delay.maxlen;
 	if (final_maxlen == final_rise_delay.maxlen) {
 		sdr_clr_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
 		sdr_set_field(host->base + MSDC_PAD_TUNE, MSDC_PAD_TUNE_CMDRDLY,
@@ -1366,7 +1413,68 @@ static int msdc_tune_response(struct mmc_host *mmc, u32 opcode)
 			      final_fall_delay.final_phase);
 		final_delay = final_fall_delay.final_phase;
 	}
+	if (host->hs200_cmd_int_delay)
+		goto skip_internal;
+
+	for (i = 0; i < PAD_DELAY_MAX; i++) {
+		sdr_set_field(host->base + MSDC_PAD_TUNE,
+			      MSDC_PAD_TUNE_CMDRRDLY, i);
+		mmc_send_tuning(mmc, opcode, &cmd_err);
+		if (!cmd_err)
+			internal_delay |= (1 << i);
+	}
+	dev_dbg(host->dev, "Final internal delay: 0x%x\n", internal_delay);
+	internal_delay_phase = get_best_delay(host, internal_delay);
+	sdr_set_field(host->base + MSDC_PAD_TUNE, MSDC_PAD_TUNE_CMDRRDLY,
+		      internal_delay_phase.final_phase);
+skip_internal:
+	dev_dbg(host->dev, "Final cmd pad delay: %x\n", final_delay);
+	return final_delay == 0xff ? -EIO : 0;
+}
+
+static int hs400_tune_response(struct mmc_host *mmc, u32 opcode)
+{
+	struct msdc_host *host = mmc_priv(mmc);
+	u32 cmd_delay = 0;
+	struct msdc_delay_phase final_cmd_delay = { 0,};
+	u8 final_delay;
+	int cmd_err;
+	int i, j;
+
+	/* select EMMC50 PAD CMD tune */
+	sdr_set_bits(host->base + PAD_CMD_TUNE, BIT(0));
+
+	if (mmc->ios.timing == MMC_TIMING_MMC_HS200 ||
+	    mmc->ios.timing == MMC_TIMING_UHS_SDR104)
+		sdr_set_field(host->base + MSDC_PAD_TUNE,
+			      MSDC_PAD_TUNE_CMDRRDLY,
+			      host->hs200_cmd_int_delay);
+	sdr_set_field(host->base + MSDC_IOCON, MSDC_IOCON_RSPL,
+		      host->hs200_cmd_resp_sel);
+	for (i = 0 ; i < PAD_DELAY_MAX; i++) {
+		sdr_set_field(host->base + PAD_CMD_TUNE,
+			      PAD_CMD_TUNE_RX_DLY3, i);
+		/*
+		 * Using the same parameters, it may sometimes pass the test,
+		 * but sometimes it may fail. To make sure the parameters is
+		 * more stable, we test 3 times for one set of parameters.
+		 */
+		for (j = 0; j < 3; j++) {
+			mmc_send_tuning(mmc, opcode, &cmd_err);
+			if (!cmd_err) {
+				cmd_delay |= (1 << i);
+			} else {
+				cmd_delay &= ~(1 << i);
+				break;
+			}
+		}
+	}
+	final_cmd_delay = get_best_delay(host, cmd_delay);
+	sdr_set_field(host->base + PAD_CMD_TUNE, PAD_CMD_TUNE_RX_DLY3,
+		      final_cmd_delay.final_phase);
+	final_delay = final_cmd_delay.final_phase;
 
+	dev_dbg(host->dev, "Final cmd pad delay: %x\n", final_delay);
 	return final_delay == 0xff ? -EIO : 0;
 }
 
@@ -1389,7 +1497,7 @@ static int msdc_tune_data(struct mmc_host *mmc, u32 opcode)
 	}
 	final_rise_delay = get_best_delay(host, rise_delay);
 	/* if rising edge has enough margin, then do not scan falling edge */
-	if (final_rise_delay.maxlen >= 10 ||
+	if (final_rise_delay.maxlen >= 12 ||
 	    (final_rise_delay.start == 0 && final_rise_delay.maxlen >= 4))
 		goto skip_fall;
 
@@ -1422,6 +1530,7 @@ static int msdc_tune_data(struct mmc_host *mmc, u32 opcode)
 		final_delay = final_fall_delay.final_phase;
 	}
 
+	dev_dbg(host->dev, "Final data pad delay: %x\n", final_delay);
 	return final_delay == 0xff ? -EIO : 0;
 }
 
@@ -1430,7 +1539,10 @@ static int msdc_execute_tuning(struct mmc_host *mmc, u32 opcode)
 	struct msdc_host *host = mmc_priv(mmc);
 	int ret;
 
-	ret = msdc_tune_response(mmc, opcode);
+	if (host->hs400_mode)
+		ret = hs400_tune_response(mmc, opcode);
+	else
+		ret = msdc_tune_response(mmc, opcode);
 	if (ret == -EIO) {
 		dev_err(host->dev, "Tune response fail!\n");
 		return ret;
@@ -1443,6 +1555,7 @@ static int msdc_execute_tuning(struct mmc_host *mmc, u32 opcode)
 
 	host->saved_tune_para.iocon = readl(host->base + MSDC_IOCON);
 	host->saved_tune_para.pad_tune = readl(host->base + MSDC_PAD_TUNE);
+	host->saved_tune_para.pad_cmd_tune = readl(host->base + PAD_CMD_TUNE);
 	return ret;
 }
 
@@ -1477,6 +1590,30 @@ static void msdc_hw_reset(struct mmc_host *mmc)
 	.hw_reset = msdc_hw_reset,
 };
 
+static void msdc_of_property_parse(struct platform_device *pdev,
+				   struct msdc_host *host)
+{
+	if (!of_property_read_u32(pdev->dev.of_node, "hs400-ds-delay",
+				  &host->hs400_ds_delay))
+		dev_dbg(&pdev->dev, "hs400-ds-delay: %x\n",
+			host->hs400_ds_delay);
+
+	if (!of_property_read_u32(pdev->dev.of_node, "hs200-cmd-int-delay",
+				  &host->hs200_cmd_int_delay))
+		dev_dbg(&pdev->dev, "host->hs200-cmd-int-delay: %x\n",
+			host->hs200_cmd_int_delay);
+
+	if (!of_property_read_u32(pdev->dev.of_node, "hs400-cmd-int-delay",
+				  &host->hs400_cmd_int_delay))
+		dev_dbg(&pdev->dev, "host->hs400-cmd-int-delay: %x\n",
+			host->hs400_cmd_int_delay);
+
+	if (!of_property_read_u32(pdev->dev.of_node, "cmd-resp-sel",
+				  &host->hs200_cmd_resp_sel))
+		dev_dbg(&pdev->dev, "host->hs200_cmd-resp-sel: %x\n",
+			host->hs200_cmd_resp_sel);
+}
+
 static int msdc_drv_probe(struct platform_device *pdev)
 {
 	struct mmc_host *mmc;
@@ -1497,7 +1634,6 @@ static int msdc_drv_probe(struct platform_device *pdev)
 	ret = mmc_of_parse(mmc);
 	if (ret)
 		goto host_free;
-
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	host->base = devm_ioremap_resource(&pdev->dev, res);
 	if (IS_ERR(host->base)) {
@@ -1548,10 +1684,7 @@ static int msdc_drv_probe(struct platform_device *pdev)
 		goto host_free;
 	}
 
-	if (!of_property_read_u32(pdev->dev.of_node, "hs400-ds-delay",
-				  &host->hs400_ds_delay))
-		dev_dbg(&pdev->dev, "hs400-ds-delay: %x\n",
-			host->hs400_ds_delay);
+	msdc_of_property_parse(pdev, host);
 
 	host->dev = &pdev->dev;
 	host->mmc = mmc;
@@ -1663,6 +1796,7 @@ static void msdc_save_reg(struct msdc_host *host)
 	host->save_para.patch_bit0 = readl(host->base + MSDC_PATCH_BIT);
 	host->save_para.patch_bit1 = readl(host->base + MSDC_PATCH_BIT1);
 	host->save_para.pad_ds_tune = readl(host->base + PAD_DS_TUNE);
+	host->save_para.pad_cmd_tune = readl(host->base + PAD_CMD_TUNE);
 	host->save_para.emmc50_cfg0 = readl(host->base + EMMC50_CFG0);
 }
 
@@ -1675,6 +1809,7 @@ static void msdc_restore_reg(struct msdc_host *host)
 	writel(host->save_para.patch_bit0, host->base + MSDC_PATCH_BIT);
 	writel(host->save_para.patch_bit1, host->base + MSDC_PATCH_BIT1);
 	writel(host->save_para.pad_ds_tune, host->base + PAD_DS_TUNE);
+	writel(host->save_para.pad_cmd_tune, host->base + PAD_CMD_TUNE);
 	writel(host->save_para.emmc50_cfg0, host->base + EMMC50_CFG0);
 }
 
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH v2 2/3] dts: mediatek: configure some fixed mmc parameters
From: Yong Mao @ 2017-01-17 12:55 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Linus Walleij,
	linux-mmc-u79uwXL29TY76Z2rM5mHXA, yong mao,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Chunfeng Yun,
	Eddie Huang, Chaotian Jing
In-Reply-To: <1484657703-5861-1-git-send-email-yong.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>

From: yong mao <yong.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>

configure some fixed mmc parameters

Signed-off-by: Yong Mao <yong.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Signed-off-by: Chaotian Jing <chaotian.jing-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 0ecaad4..7356a32 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -134,6 +134,9 @@
 	bus-width = <8>;
 	max-frequency = <50000000>;
 	cap-mmc-highspeed;
+	hs200-cmd-int-delay=<26>;
+	hs400-cmd-int-delay=<14>;
+	cmd-resp-sel=<0>; /* 0:rising, 1:falling */
 	vmmc-supply = <&mt6397_vemc_3v3_reg>;
 	vqmmc-supply = <&mt6397_vio18_reg>;
 	non-removable;
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH v2 1/3] mmc: dt-bindings: update Mediatek MMC bindings
From: Yong Mao @ 2017-01-17 12:55 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Linus Walleij,
	linux-mmc-u79uwXL29TY76Z2rM5mHXA, yong mao,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Chunfeng Yun,
	Eddie Huang, Chaotian Jing
In-Reply-To: <1484657703-5861-1-git-send-email-yong.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>

From: yong mao <yong.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>

Add description for hs200-cmd-int-delay
Add description for hs400-cmd-int-delay
Add description for cmd-resp-sel

Signed-off-by: Yong Mao <yong.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
 Documentation/devicetree/bindings/mmc/mtk-sd.txt |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
index 0120c7f..2dbb3b0 100644
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
@@ -21,6 +21,9 @@ Optional properties:
 - assigned-clocks: PLL of the source clock
 - assigned-clock-parents: parent of source clock, used for HS400 mode to get 400Mhz source clock
 - hs400-ds-delay: HS400 DS delay setting
+- hs200-cmd-int-delay: HS200 command internal delay setting
+- hs400-cmd-int-delay: HS400 command internal delay setting
+- cmd-resp-sel: command response sample selection
 
 Examples:
 mmc0: mmc@11230000 {
@@ -38,4 +41,7 @@ mmc0: mmc@11230000 {
 	assigned-clocks = <&topckgen CLK_TOP_MSDC50_0_SEL>;
 	assigned-clock-parents = <&topckgen CLK_TOP_MSDCPLL_D2>;
 	hs400-ds-delay = <0x14015>;
+	hs200-cmd-int-delay = <26>;
+	hs400-cmd-int-delay = <14>;
+	cmd-resp-sel = <0>; /* 0: rising, 1: falling */
 };
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH v2 0/3] mmc: mediatek: Use data tune for CMD line tune
From: Yong Mao @ 2017-01-17 12:55 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Linus Walleij,
	linux-mmc-u79uwXL29TY76Z2rM5mHXA, yong mao,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Chunfeng Yun,
	Eddie Huang, Chaotian Jing

yong mao (3):
  mmc: dt-bindings: update Mediatek MMC bindings
  dts: mediatek: configure some fixed mmc parameters
  mmc: mediatek: Use data tune for CMD line tune

 Documentation/devicetree/bindings/mmc/mtk-sd.txt |   6 +
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts      |   3 +
 drivers/mmc/host/mtk-sd.c                        | 169 ++++++++++++++++++++---
 3 files changed, 161 insertions(+), 17 deletions(-)

-- 
1.8.1.1

^ permalink raw reply

* [PATCH v3] arm: dts: mt2701: Add thermal device node.
From: Erin Lo @ 2017-01-17  9:24 UTC (permalink / raw)
  To: Matthias Brugger
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Erin Lo, Dawei Chien,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1484645049-4477-1-git-send-email-erin.lo-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>

From: Dawei Chien <dawei.chien-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>

Add thermal controller device nodes for MT2701.

Signed-off-by: Dawei Chien <dawei.chien-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Signed-off-by: Erin Lo <erin.lo-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
 arch/arm/boot/dts/mt2701.dtsi | 43 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 4cfec57..26a88cb 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -89,6 +89,36 @@
 		clock-output-names = "rtc32k";
 	};
 
+	thermal-zones {
+		cpu_thermal: cpu_thermal {
+			polling-delay-passive = <1000>; /* milliseconds */
+			polling-delay = <1000>; /* milliseconds */
+
+			thermal-sensors = <&thermal 0>;
+			sustainable-power = <1000>;
+
+			trips {
+				threshold: trip-point@0 {
+					temperature = <68000>;
+					hysteresis = <2000>;
+					type = "passive";
+				};
+
+				target: trip-point@1 {
+					temperature = <85000>;
+					hysteresis = <2000>;
+					type = "passive";
+				};
+
+				cpu_crit: cpu_crit@0 {
+					temperature = <115000>;
+					hysteresis = <2000>;
+					type = "critical";
+				};
+			};
+		};
+	};
+
 	timer {
 		compatible = "arm,armv7-timer";
 		interrupt-parent = <&gic>;
@@ -270,6 +300,19 @@
 		status = "disabled";
 	};
 
+	thermal: thermal@1100b000 {
+		#thermal-sensor-cells = <0>;
+		compatible = "mediatek,mt2701-thermal";
+		reg = <0 0x1100b000 0 0x1000>;
+		interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_LOW>;
+		clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
+		clock-names = "therm", "auxadc";
+		resets = <&pericfg MT2701_PERI_THERM_SW_RST>;
+		reset-names = "therm";
+		mediatek,auxadc = <&auxadc>;
+		mediatek,apmixedsys = <&apmixedsys>;
+	};
+
 	nandc: nfi@1100d000 {
 		compatible = "mediatek,mt2701-nfc";
 		reg = <0 0x1100d000 0 0x1000>;
-- 
1.9.1

^ permalink raw reply related

* [PATCH v3] Add some DT nodes for Mediatek MT2701
From: Erin Lo @ 2017-01-17  9:24 UTC (permalink / raw)
  To: Matthias Brugger
  Cc: srv_heupstream, devicetree, linux-arm-kernel, linux-kernel,
	linux-mediatek

This patch series based on v4.10-rc2, include MT2701 spi/nand/auxadc/thermal controller DT nodes.

Dependent on "Add clock and power domain DT nodes for Mediatek MT2701"[1].

Change in v3:
1. Since some patches in v2 have been applied to v4.10-next/dts32, they were not included in v3 series.
2. Remove iommu DT nodes since it will be sent with its driver patch series later.
3. Remove ethernet DT nodes since it will be sent with its driver patch series later.
4. Modify thermal resets pin define from hard code to name.

Change in v2:
1. Add spi/auxadc pin setting
2. Add ethernet node and pin setting
3. Add thermal controller node

[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-December/007637.html

Dawei Chien (1):
  arm: dts: mt2701: Add thermal device node.

 arch/arm/boot/dts/mt2701.dtsi | 43 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

--
1.9.1

^ permalink raw reply

* Re: [PATCH v11 06/12] drm/mediatek: update display module connections
From: CK Hu @ 2017-01-17  5:19 UTC (permalink / raw)
  To: YT Shen
  Cc: Mark Rutland, devicetree, srv_heupstream, emil.l.velikov,
	linux-kernel, dri-devel, Rob Herring, linux-mediatek,
	Matthias Brugger, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1484117473-46644-7-git-send-email-yt.shen@mediatek.com>

Hi, YT:

On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> update connections for OVL, RDMA, BLS, DSI
> 
> Signed-off-by: YT Shen <yt.shen@mediatek.com>

Acked-by: CK Hu <ck.hu@mediatek.com>

> ---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 25 +++++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index b77d456..a9b209c 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -32,6 +32,10 @@
>  #define DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN	0x0c8
>  #define DISP_REG_CONFIG_MMSYS_CG_CON0		0x100
>  
> +#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN	0x030
> +#define DISP_REG_CONFIG_OUT_SEL			0x04c
> +#define DISP_REG_CONFIG_DSI_SEL			0x050
> +
>  #define DISP_REG_MUTEX_EN(n)	(0x20 + 0x20 * (n))
>  #define DISP_REG_MUTEX(n)	(0x24 + 0x20 * (n))
>  #define DISP_REG_MUTEX_RST(n)	(0x28 + 0x20 * (n))
> @@ -71,6 +75,10 @@
>  #define DPI0_SEL_IN_RDMA1		0x1
>  #define COLOR1_SEL_IN_OVL1		0x1
>  
> +#define OVL_MOUT_EN_RDMA		0x1
> +#define BLS_TO_DSI_RDMA1_TO_DPI1	0x8
> +#define DSI_SEL_IN_BLS			0x0
> +
>  struct mtk_disp_mutex {
>  	int id;
>  	bool claimed;
> @@ -111,6 +119,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
>  	if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_COLOR0) {
>  		*addr = DISP_REG_CONFIG_DISP_OVL0_MOUT_EN;
>  		value = OVL0_MOUT_EN_COLOR0;
> +	} else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
> +		*addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
> +		value = OVL_MOUT_EN_RDMA;
>  	} else if (cur == DDP_COMPONENT_OD && next == DDP_COMPONENT_RDMA0) {
>  		*addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
>  		value = OD_MOUT_EN_RDMA0;
> @@ -148,6 +159,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
>  	} else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
>  		*addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
>  		value = COLOR1_SEL_IN_OVL1;
> +	} else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
> +		*addr = DISP_REG_CONFIG_DSI_SEL;
> +		value = DSI_SEL_IN_BLS;
>  	} else {
>  		value = 0;
>  	}
> @@ -155,6 +169,15 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
>  	return value;
>  }
>  
> +static void mtk_ddp_sout_sel(void __iomem *config_regs,
> +			     enum mtk_ddp_comp_id cur,
> +			     enum mtk_ddp_comp_id next)
> +{
> +	if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0)
> +		writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1,
> +			       config_regs + DISP_REG_CONFIG_OUT_SEL);
> +}
> +
>  void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
>  			      enum mtk_ddp_comp_id cur,
>  			      enum mtk_ddp_comp_id next)
> @@ -167,6 +190,8 @@ void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
>  		writel_relaxed(reg, config_regs + addr);
>  	}
>  
> +	mtk_ddp_sout_sel(config_regs, cur, next);
> +
>  	value = mtk_ddp_sel_in(cur, next, &addr);
>  	if (value) {
>  		reg = readl_relaxed(config_regs + addr) | value;


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

^ permalink raw reply

* Re: [PATCH v11 05/12] drm/mediatek: add BLS component
From: CK Hu @ 2017-01-17  5:07 UTC (permalink / raw)
  To: YT Shen
  Cc: Mark Rutland, devicetree, srv_heupstream, emil.l.velikov,
	linux-kernel, dri-devel, Rob Herring, linux-mediatek,
	Matthias Brugger, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1484117473-46644-6-git-send-email-yt.shen@mediatek.com>

Hi, YT:

On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> Add BLS component for PWM + GAMMA function
> 
> Signed-off-by: YT Shen <yt.shen@mediatek.com>

Acked-by: CK Hu <ck.hu@mediatek.com>

> ---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 5 ++++-
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 ++
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 3ff788c..f6e853a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -255,6 +255,7 @@ static void mtk_gamma_set(struct mtk_ddp_comp *comp,
>  	[MTK_DISP_PWM] = "pwm",
>  	[MTK_DISP_MUTEX] = "mutex",
>  	[MTK_DISP_OD] = "od",
> +	[MTK_DISP_BLS] = "bls",
>  };
>  
>  struct mtk_ddp_comp_match {
> @@ -265,6 +266,7 @@ struct mtk_ddp_comp_match {
>  
>  static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
>  	[DDP_COMPONENT_AAL]	= { MTK_DISP_AAL,	0, &ddp_aal },
> +	[DDP_COMPONENT_BLS]	= { MTK_DISP_BLS,	0, NULL },
>  	[DDP_COMPONENT_COLOR0]	= { MTK_DISP_COLOR,	0, &ddp_color },
>  	[DDP_COMPONENT_COLOR1]	= { MTK_DISP_COLOR,	1, &ddp_color },
>  	[DDP_COMPONENT_DPI0]	= { MTK_DPI,		0, NULL },
> @@ -336,7 +338,8 @@ int mtk_ddp_comp_init(struct device *dev, struct device_node *node,
>  	comp->id = comp_id;
>  	comp->funcs = funcs ?: mtk_ddp_matches[comp_id].funcs;
>  
> -	if (comp_id == DDP_COMPONENT_DPI0 ||
> +	if (comp_id == DDP_COMPONENT_BLS ||
> +	    comp_id == DDP_COMPONENT_DPI0 ||
>  	    comp_id == DDP_COMPONENT_DSI0 ||
>  	    comp_id == DDP_COMPONENT_PWM0) {
>  		comp->regs = NULL;
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 22a33ee..0828cf8 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -36,11 +36,13 @@ enum mtk_ddp_comp_type {
>  	MTK_DISP_PWM,
>  	MTK_DISP_MUTEX,
>  	MTK_DISP_OD,
> +	MTK_DISP_BLS,
>  	MTK_DDP_COMP_TYPE_MAX,
>  };
>  
>  enum mtk_ddp_comp_id {
>  	DDP_COMPONENT_AAL,
> +	DDP_COMPONENT_BLS,
>  	DDP_COMPONENT_COLOR0,
>  	DDP_COMPONENT_COLOR1,
>  	DDP_COMPONENT_DPI0,


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

^ permalink raw reply

* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Thomas Petazzoni @ 2017-01-17  3:36 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Marek Vasut, Rob Herring, Mark Rutland, devicetree, Guochun Mao,
	Richard Weinberger, Russell King, linux-kernel, linux-mtd,
	Matthias Brugger, linux-mediatek, Cyrille Pitchen, Brian Norris,
	David Woodhouse, linux-arm-kernel
In-Reply-To: <20170116094032.6f471f11@bbrezillon>

Hello,

(Side note: you guys should learn about stripping irrelevant parts of
an e-mail when replying!)

On Mon, 16 Jan 2017 09:40:32 +0100, Boris Brezillon wrote:

> > Well this is OK I guess, but then you can also use "mediatek,mt8173-nor"
> > as the oldest supported compatible and be done with it, no ? It looks a
> > bit crappy though, I admit that ...
> 
> Let's stop bikeshedding and wait for DT maintainers feedback
> before taking a decision ;-).
> 
> Rob, Mark, any opinion?

I agree that a clarification would be good. There are really two
options:

 1. Have two compatible strings in the DT, the one that matches the
    exact SoC where the IP is found (first compatible string) and the
    one that matches some other SoC where the same IP is found (second
    compatible string). Originally, Linux only supports the second
    compatible string in its device driver, but if it happens that a
    difference is found between two IPs that we thought were the same,
    we can add support for the first compatible string in the driver,
    with a slightly different behavior.

 2. Have a single compatible string in the DT, matching the exact SoC
    where the IP is found. This involves adding immediately this
    compatible string in the corresponding driver.

I've not really been able to figure out which of the two options is the
most future-proof/appropriate.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Thomas Petazzoni @ 2017-01-17  3:32 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Mark Rutland, devicetree, Guochun Mao, Richard Weinberger,
	Russell King, linux-kernel, Marek Vasut, Rob Herring, linux-mtd,
	Matthias Brugger, linux-mediatek, Cyrille Pitchen, Brian Norris,
	David Woodhouse, linux-arm-kernel
In-Reply-To: <20170113175628.1793f433@bbrezillon>

Hello,

On Fri, 13 Jan 2017 17:56:28 +0100, Boris Brezillon wrote:

> because both compatible are referring to very specific IP version. It's
> not the same as
> 
> 	compatible = "mediatek,mt8173-nor", "mediatek,mt81xx-nor";

mt81xx-nor is a bogus compatible string, and DT binding maintainers
will not accept it. They don't want compatible strings with "wildcards".

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* Re: [PATCH v11 04/12] drm/mediatek: add shadow register support
From: CK Hu @ 2017-01-17  2:47 UTC (permalink / raw)
  To: YT Shen
  Cc: Mark Rutland, devicetree, srv_heupstream, emil.l.velikov,
	linux-kernel, dri-devel, Rob Herring, linux-mediatek,
	Matthias Brugger, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1484117473-46644-5-git-send-email-yt.shen@mediatek.com>

Hi, YT:

On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> We need to acquire mutex before using the resources,
> and need to release it after finished.
> So we don't need to write registers in the blanking period.
> 
> Signed-off-by: YT Shen <yt.shen@mediatek.com>

Acked-by: CK Hu <ck.hu@mediatek.com>

> ---
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 75 ++++++++++++++++++++-------------
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 25 +++++++++++
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |  2 +
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |  1 +
>  4 files changed, 74 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 01a21dd..b9b82e5 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -329,6 +329,42 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *mtk_crtc)
>  	pm_runtime_put(drm->dev);
>  }
>  
> +static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
> +{
> +	struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> +	struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
> +	struct mtk_ddp_comp *ovl = mtk_crtc->ddp_comp[0];
> +	unsigned int i;
> +
> +	/*
> +	 * TODO: instead of updating the registers here, we should prepare
> +	 * working registers in atomic_commit and let the hardware command
> +	 * queue update module registers on vblank.
> +	 */
> +	if (state->pending_config) {
> +		mtk_ddp_comp_config(ovl, state->pending_width,
> +				    state->pending_height,
> +				    state->pending_vrefresh, 0);
> +
> +		state->pending_config = false;
> +	}
> +
> +	if (mtk_crtc->pending_planes) {
> +		for (i = 0; i < OVL_LAYER_NR; i++) {
> +			struct drm_plane *plane = &mtk_crtc->planes[i];
> +			struct mtk_plane_state *plane_state;
> +
> +			plane_state = to_mtk_plane_state(plane->state);
> +
> +			if (plane_state->pending.config) {
> +				mtk_ddp_comp_layer_config(ovl, i, plane_state);
> +				plane_state->pending.config = false;
> +			}
> +		}
> +		mtk_crtc->pending_planes = false;
> +	}
> +}
> +
>  static void mtk_drm_crtc_enable(struct drm_crtc *crtc)
>  {
>  	struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> @@ -405,6 +441,7 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc,
>  				      struct drm_crtc_state *old_crtc_state)
>  {
>  	struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> +	struct mtk_drm_private *priv = crtc->dev->dev_private;
>  	unsigned int pending_planes = 0;
>  	int i;
>  
> @@ -426,6 +463,12 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc,
>  	if (crtc->state->color_mgmt_changed)
>  		for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
>  			mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state);
> +
> +	if (priv->data->shadow_register) {
> +		mtk_disp_mutex_acquire(mtk_crtc->mutex);
> +		mtk_crtc_ddp_config(crtc);
> +		mtk_disp_mutex_release(mtk_crtc->mutex);
> +	}
>  }
>  
>  static const struct drm_crtc_funcs mtk_crtc_funcs = {
> @@ -471,36 +514,10 @@ static int mtk_drm_crtc_init(struct drm_device *drm,
>  void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct mtk_ddp_comp *ovl)
>  {
>  	struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> -	struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
> -	unsigned int i;
> +	struct mtk_drm_private *priv = crtc->dev->dev_private;
>  
> -	/*
> -	 * TODO: instead of updating the registers here, we should prepare
> -	 * working registers in atomic_commit and let the hardware command
> -	 * queue update module registers on vblank.
> -	 */
> -	if (state->pending_config) {
> -		mtk_ddp_comp_config(ovl, state->pending_width,
> -				    state->pending_height,
> -				    state->pending_vrefresh, 0);
> -
> -		state->pending_config = false;
> -	}
> -
> -	if (mtk_crtc->pending_planes) {
> -		for (i = 0; i < OVL_LAYER_NR; i++) {
> -			struct drm_plane *plane = &mtk_crtc->planes[i];
> -			struct mtk_plane_state *plane_state;
> -
> -			plane_state = to_mtk_plane_state(plane->state);
> -
> -			if (plane_state->pending.config) {
> -				mtk_ddp_comp_layer_config(ovl, i, plane_state);
> -				plane_state->pending.config = false;
> -			}
> -		}
> -		mtk_crtc->pending_planes = false;
> -	}
> +	if (!priv->data->shadow_register)
> +		mtk_crtc_ddp_config(crtc);
>  
>  	mtk_drm_finish_page_flip(mtk_crtc);
>  }
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 8030769..b77d456 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -12,6 +12,7 @@
>   */
>  
>  #include <linux/clk.h>
> +#include <linux/iopoll.h>
>  #include <linux/module.h>
>  #include <linux/of_device.h>
>  #include <linux/platform_device.h>
> @@ -32,10 +33,13 @@
>  #define DISP_REG_CONFIG_MMSYS_CG_CON0		0x100
>  
>  #define DISP_REG_MUTEX_EN(n)	(0x20 + 0x20 * (n))
> +#define DISP_REG_MUTEX(n)	(0x24 + 0x20 * (n))
>  #define DISP_REG_MUTEX_RST(n)	(0x28 + 0x20 * (n))
>  #define DISP_REG_MUTEX_MOD(n)	(0x2c + 0x20 * (n))
>  #define DISP_REG_MUTEX_SOF(n)	(0x30 + 0x20 * (n))
>  
> +#define INT_MUTEX				BIT(1)
> +
>  #define MT8173_MUTEX_MOD_DISP_OVL0		BIT(11)
>  #define MT8173_MUTEX_MOD_DISP_OVL1		BIT(12)
>  #define MT8173_MUTEX_MOD_DISP_RDMA0		BIT(13)
> @@ -300,6 +304,27 @@ void mtk_disp_mutex_disable(struct mtk_disp_mutex *mutex)
>  	writel(0, ddp->regs + DISP_REG_MUTEX_EN(mutex->id));
>  }
>  
> +void mtk_disp_mutex_acquire(struct mtk_disp_mutex *mutex)
> +{
> +	struct mtk_ddp *ddp = container_of(mutex, struct mtk_ddp,
> +					   mutex[mutex->id]);
> +	u32 tmp;
> +
> +	writel(1, ddp->regs + DISP_REG_MUTEX_EN(mutex->id));
> +	writel(1, ddp->regs + DISP_REG_MUTEX(mutex->id));
> +	if (readl_poll_timeout_atomic(ddp->regs + DISP_REG_MUTEX(mutex->id),
> +				      tmp, tmp & INT_MUTEX, 1, 10000))
> +		pr_err("could not acquire mutex %d\n", mutex->id);
> +}
> +
> +void mtk_disp_mutex_release(struct mtk_disp_mutex *mutex)
> +{
> +	struct mtk_ddp *ddp = container_of(mutex, struct mtk_ddp,
> +					   mutex[mutex->id]);
> +
> +	writel(0, ddp->regs + DISP_REG_MUTEX(mutex->id));
> +}
> +
>  static int mtk_ddp_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
> index 92c1175..f9a7991 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
> @@ -37,5 +37,7 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex *mutex,
>  				enum mtk_ddp_comp_id id);
>  void mtk_disp_mutex_unprepare(struct mtk_disp_mutex *mutex);
>  void mtk_disp_mutex_put(struct mtk_disp_mutex *mutex);
> +void mtk_disp_mutex_acquire(struct mtk_disp_mutex *mutex);
> +void mtk_disp_mutex_release(struct mtk_disp_mutex *mutex);
>  
>  #endif /* MTK_DRM_DDP_H */
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> index fa0b106..94f8b66 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> @@ -33,6 +33,7 @@ struct mtk_mmsys_driver_data {
>  	unsigned int main_len;
>  	const enum mtk_ddp_comp_id *ext_path;
>  	unsigned int ext_len;
> +	bool shadow_register;
>  };
>  
>  struct mtk_drm_private {


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

^ permalink raw reply

* Re: [PATCH v11 03/12] drm/mediatek: add *driver_data for different hardware settings
From: CK Hu @ 2017-01-17  2:37 UTC (permalink / raw)
  To: YT Shen
  Cc: Mark Rutland, devicetree, srv_heupstream, emil.l.velikov,
	linux-kernel, dri-devel, Rob Herring, linux-mediatek,
	Matthias Brugger, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1484117473-46644-4-git-send-email-yt.shen@mediatek.com>

Hi, YT:

On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> There are some hardware settings changed, between MT8173 & MT2701:
> DISP_OVL address offset changed, color format definition changed.
> DISP_RDMA fifo size changed.
> DISP_COLOR offset changed.
> MIPI_TX pll setting changed.
> And add prefix for mtk_ddp_main & mtk_ddp_ext & mutex_mod.
> 
> Signed-off-by: YT Shen <yt.shen@mediatek.com>

Acked-by: CK Hu <ck.hu@mediatek.com>

> ---
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c     | 41 ++++++++++++-----
>  drivers/gpu/drm/mediatek/mtk_disp_rdma.c    | 18 +++++++-
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c      | 71 +++++++++++++++--------------
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 57 +++++++++++++++++++----
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c      | 25 +++++++---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h      |  8 ++++
>  drivers/gpu/drm/mediatek/mtk_mipi_tx.c      | 24 +++++++++-
>  7 files changed, 181 insertions(+), 63 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index ce2759f..4552178 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -35,18 +35,27 @@
>  #define DISP_REG_OVL_PITCH(n)			(0x0044 + 0x20 * (n))
>  #define DISP_REG_OVL_RDMA_CTRL(n)		(0x00c0 + 0x20 * (n))
>  #define DISP_REG_OVL_RDMA_GMC(n)		(0x00c8 + 0x20 * (n))
> -#define DISP_REG_OVL_ADDR(n)			(0x0f40 + 0x20 * (n))
> +#define DISP_REG_OVL_ADDR_MT8173		0x0f40
> +#define DISP_REG_OVL_ADDR(ovl, n)		((ovl)->data->addr + 0x20 * (n))
>  
>  #define	OVL_RDMA_MEM_GMC	0x40402020
>  
>  #define OVL_CON_BYTE_SWAP	BIT(24)
> -#define OVL_CON_CLRFMT_RGB565	(0 << 12)
> -#define OVL_CON_CLRFMT_RGB888	(1 << 12)
> +#define OVL_CON_CLRFMT_RGB	(1 << 12)
>  #define OVL_CON_CLRFMT_RGBA8888	(2 << 12)
>  #define OVL_CON_CLRFMT_ARGB8888	(3 << 12)
> +#define OVL_CON_CLRFMT_RGB565(ovl)	((ovl)->data->fmt_rgb565_is_0 ? \
> +					0 : OVL_CON_CLRFMT_RGB)
> +#define OVL_CON_CLRFMT_RGB888(ovl)	((ovl)->data->fmt_rgb565_is_0 ? \
> +					OVL_CON_CLRFMT_RGB : 0)
>  #define	OVL_CON_AEN		BIT(8)
>  #define	OVL_CON_ALPHA		0xff
>  
> +struct mtk_disp_ovl_data {
> +	unsigned int addr;
> +	bool fmt_rgb565_is_0;
> +};
> +
>  /**
>   * struct mtk_disp_ovl - DISP_OVL driver structure
>   * @ddp_comp - structure containing type enum and hardware resources
> @@ -55,6 +64,7 @@
>  struct mtk_disp_ovl {
>  	struct mtk_ddp_comp		ddp_comp;
>  	struct drm_crtc			*crtc;
> +	const struct mtk_disp_ovl_data	*data;
>  };
>  
>  static inline struct mtk_disp_ovl *comp_to_ovl(struct mtk_ddp_comp *comp)
> @@ -141,18 +151,18 @@ static void mtk_ovl_layer_off(struct mtk_ddp_comp *comp, unsigned int idx)
>  	writel(0x0, comp->regs + DISP_REG_OVL_RDMA_CTRL(idx));
>  }
>  
> -static unsigned int ovl_fmt_convert(unsigned int fmt)
> +static unsigned int ovl_fmt_convert(struct mtk_disp_ovl *ovl, unsigned int fmt)
>  {
>  	switch (fmt) {
>  	default:
>  	case DRM_FORMAT_RGB565:
> -		return OVL_CON_CLRFMT_RGB565;
> +		return OVL_CON_CLRFMT_RGB565(ovl);
>  	case DRM_FORMAT_BGR565:
> -		return OVL_CON_CLRFMT_RGB565 | OVL_CON_BYTE_SWAP;
> +		return OVL_CON_CLRFMT_RGB565(ovl) | OVL_CON_BYTE_SWAP;
>  	case DRM_FORMAT_RGB888:
> -		return OVL_CON_CLRFMT_RGB888;
> +		return OVL_CON_CLRFMT_RGB888(ovl);
>  	case DRM_FORMAT_BGR888:
> -		return OVL_CON_CLRFMT_RGB888 | OVL_CON_BYTE_SWAP;
> +		return OVL_CON_CLRFMT_RGB888(ovl) | OVL_CON_BYTE_SWAP;
>  	case DRM_FORMAT_RGBX8888:
>  	case DRM_FORMAT_RGBA8888:
>  		return OVL_CON_CLRFMT_ARGB8888;
> @@ -171,6 +181,7 @@ static unsigned int ovl_fmt_convert(unsigned int fmt)
>  static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp, unsigned int idx,
>  				 struct mtk_plane_state *state)
>  {
> +	struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
>  	struct mtk_plane_pending_state *pending = &state->pending;
>  	unsigned int addr = pending->addr;
>  	unsigned int pitch = pending->pitch & 0xffff;
> @@ -182,7 +193,7 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp, unsigned int idx,
>  	if (!pending->enable)
>  		mtk_ovl_layer_off(comp, idx);
>  
> -	con = ovl_fmt_convert(fmt);
> +	con = ovl_fmt_convert(ovl, fmt);
>  	if (idx != 0)
>  		con |= OVL_CON_AEN | OVL_CON_ALPHA;
>  
> @@ -190,7 +201,7 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp, unsigned int idx,
>  	writel_relaxed(pitch, comp->regs + DISP_REG_OVL_PITCH(idx));
>  	writel_relaxed(src_size, comp->regs + DISP_REG_OVL_SRC_SIZE(idx));
>  	writel_relaxed(offset, comp->regs + DISP_REG_OVL_OFFSET(idx));
> -	writel_relaxed(addr, comp->regs + DISP_REG_OVL_ADDR(idx));
> +	writel_relaxed(addr, comp->regs + DISP_REG_OVL_ADDR(ovl, idx));
>  
>  	if (pending->enable)
>  		mtk_ovl_layer_on(comp, idx);
> @@ -267,6 +278,8 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
>  		return ret;
>  	}
>  
> +	priv->data = of_device_get_match_data(dev);
> +
>  	platform_set_drvdata(pdev, priv);
>  
>  	ret = devm_request_irq(dev, irq, mtk_disp_ovl_irq_handler,
> @@ -290,8 +303,14 @@ static int mtk_disp_ovl_remove(struct platform_device *pdev)
>  	return 0;
>  }
>  
> +static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
> +	.addr = DISP_REG_OVL_ADDR_MT8173,
> +	.fmt_rgb565_is_0 = true,
> +};
> +
>  static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
> -	{ .compatible = "mediatek,mt8173-disp-ovl", },
> +	{ .compatible = "mediatek,mt8173-disp-ovl",
> +	  .data = &mt8173_ovl_driver_data},
>  	{},
>  };
>  MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index 21eff6f..e5e5318 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -38,6 +38,11 @@
>  #define RDMA_FIFO_UNDERFLOW_EN				BIT(31)
>  #define RDMA_FIFO_PSEUDO_SIZE(bytes)			(((bytes) / 16) << 16)
>  #define RDMA_OUTPUT_VALID_FIFO_THRESHOLD(bytes)		((bytes) / 16)
> +#define RDMA_FIFO_SIZE(rdma)			((rdma)->data->fifo_size)
> +
> +struct mtk_disp_rdma_data {
> +	unsigned int fifo_size;
> +};
>  
>  /**
>   * struct mtk_disp_rdma - DISP_RDMA driver structure
> @@ -47,6 +52,7 @@
>  struct mtk_disp_rdma {
>  	struct mtk_ddp_comp		ddp_comp;
>  	struct drm_crtc			*crtc;
> +	const struct mtk_disp_rdma_data	*data;
>  };
>  
>  static inline struct mtk_disp_rdma *comp_to_rdma(struct mtk_ddp_comp *comp)
> @@ -114,6 +120,7 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp, unsigned int width,
>  {
>  	unsigned int threshold;
>  	unsigned int reg;
> +	struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
>  
>  	rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_0, 0xfff, width);
>  	rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_1, 0xfffff, height);
> @@ -126,7 +133,7 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp, unsigned int width,
>  	 */
>  	threshold = width * height * vrefresh * 4 * 7 / 1000000;
>  	reg = RDMA_FIFO_UNDERFLOW_EN |
> -	      RDMA_FIFO_PSEUDO_SIZE(SZ_8K) |
> +	      RDMA_FIFO_PSEUDO_SIZE(RDMA_FIFO_SIZE(rdma)) |
>  	      RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold);
>  	writel(reg, comp->regs + DISP_REG_RDMA_FIFO_CON);
>  }
> @@ -211,6 +218,8 @@ static int mtk_disp_rdma_probe(struct platform_device *pdev)
>  		return ret;
>  	}
>  
> +	priv->data = of_device_get_match_data(dev);
> +
>  	platform_set_drvdata(pdev, priv);
>  
>  	ret = component_add(dev, &mtk_disp_rdma_component_ops);
> @@ -227,8 +236,13 @@ static int mtk_disp_rdma_remove(struct platform_device *pdev)
>  	return 0;
>  }
>  
> +static const struct mtk_disp_rdma_data mt8173_rdma_driver_data = {
> +	.fifo_size = SZ_8K,
> +};
> +
>  static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
> -	{ .compatible = "mediatek,mt8173-disp-rdma", },
> +	{ .compatible = "mediatek,mt8173-disp-rdma",
> +	  .data = &mt8173_rdma_driver_data},
>  	{},
>  };
>  MODULE_DEVICE_TABLE(of, mtk_disp_rdma_driver_dt_match);
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 17ba935..8030769 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -36,21 +36,21 @@
>  #define DISP_REG_MUTEX_MOD(n)	(0x2c + 0x20 * (n))
>  #define DISP_REG_MUTEX_SOF(n)	(0x30 + 0x20 * (n))
>  
> -#define MUTEX_MOD_DISP_OVL0		BIT(11)
> -#define MUTEX_MOD_DISP_OVL1		BIT(12)
> -#define MUTEX_MOD_DISP_RDMA0		BIT(13)
> -#define MUTEX_MOD_DISP_RDMA1		BIT(14)
> -#define MUTEX_MOD_DISP_RDMA2		BIT(15)
> -#define MUTEX_MOD_DISP_WDMA0		BIT(16)
> -#define MUTEX_MOD_DISP_WDMA1		BIT(17)
> -#define MUTEX_MOD_DISP_COLOR0		BIT(18)
> -#define MUTEX_MOD_DISP_COLOR1		BIT(19)
> -#define MUTEX_MOD_DISP_AAL		BIT(20)
> -#define MUTEX_MOD_DISP_GAMMA		BIT(21)
> -#define MUTEX_MOD_DISP_UFOE		BIT(22)
> -#define MUTEX_MOD_DISP_PWM0		BIT(23)
> -#define MUTEX_MOD_DISP_PWM1		BIT(24)
> -#define MUTEX_MOD_DISP_OD		BIT(25)
> +#define MT8173_MUTEX_MOD_DISP_OVL0		BIT(11)
> +#define MT8173_MUTEX_MOD_DISP_OVL1		BIT(12)
> +#define MT8173_MUTEX_MOD_DISP_RDMA0		BIT(13)
> +#define MT8173_MUTEX_MOD_DISP_RDMA1		BIT(14)
> +#define MT8173_MUTEX_MOD_DISP_RDMA2		BIT(15)
> +#define MT8173_MUTEX_MOD_DISP_WDMA0		BIT(16)
> +#define MT8173_MUTEX_MOD_DISP_WDMA1		BIT(17)
> +#define MT8173_MUTEX_MOD_DISP_COLOR0		BIT(18)
> +#define MT8173_MUTEX_MOD_DISP_COLOR1		BIT(19)
> +#define MT8173_MUTEX_MOD_DISP_AAL		BIT(20)
> +#define MT8173_MUTEX_MOD_DISP_GAMMA		BIT(21)
> +#define MT8173_MUTEX_MOD_DISP_UFOE		BIT(22)
> +#define MT8173_MUTEX_MOD_DISP_PWM0		BIT(23)
> +#define MT8173_MUTEX_MOD_DISP_PWM1		BIT(24)
> +#define MT8173_MUTEX_MOD_DISP_OD		BIT(25)
>  
>  #define MUTEX_SOF_SINGLE_MODE		0
>  #define MUTEX_SOF_DSI0			1
> @@ -77,24 +77,25 @@ struct mtk_ddp {
>  	struct clk			*clk;
>  	void __iomem			*regs;
>  	struct mtk_disp_mutex		mutex[10];
> +	const unsigned int		*mutex_mod;
>  };
>  
> -static const unsigned int mutex_mod[DDP_COMPONENT_ID_MAX] = {
> -	[DDP_COMPONENT_AAL] = MUTEX_MOD_DISP_AAL,
> -	[DDP_COMPONENT_COLOR0] = MUTEX_MOD_DISP_COLOR0,
> -	[DDP_COMPONENT_COLOR1] = MUTEX_MOD_DISP_COLOR1,
> -	[DDP_COMPONENT_GAMMA] = MUTEX_MOD_DISP_GAMMA,
> -	[DDP_COMPONENT_OD] = MUTEX_MOD_DISP_OD,
> -	[DDP_COMPONENT_OVL0] = MUTEX_MOD_DISP_OVL0,
> -	[DDP_COMPONENT_OVL1] = MUTEX_MOD_DISP_OVL1,
> -	[DDP_COMPONENT_PWM0] = MUTEX_MOD_DISP_PWM0,
> -	[DDP_COMPONENT_PWM1] = MUTEX_MOD_DISP_PWM1,
> -	[DDP_COMPONENT_RDMA0] = MUTEX_MOD_DISP_RDMA0,
> -	[DDP_COMPONENT_RDMA1] = MUTEX_MOD_DISP_RDMA1,
> -	[DDP_COMPONENT_RDMA2] = MUTEX_MOD_DISP_RDMA2,
> -	[DDP_COMPONENT_UFOE] = MUTEX_MOD_DISP_UFOE,
> -	[DDP_COMPONENT_WDMA0] = MUTEX_MOD_DISP_WDMA0,
> -	[DDP_COMPONENT_WDMA1] = MUTEX_MOD_DISP_WDMA1,
> +static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> +	[DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
> +	[DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
> +	[DDP_COMPONENT_COLOR1] = MT8173_MUTEX_MOD_DISP_COLOR1,
> +	[DDP_COMPONENT_GAMMA] = MT8173_MUTEX_MOD_DISP_GAMMA,
> +	[DDP_COMPONENT_OD] = MT8173_MUTEX_MOD_DISP_OD,
> +	[DDP_COMPONENT_OVL0] = MT8173_MUTEX_MOD_DISP_OVL0,
> +	[DDP_COMPONENT_OVL1] = MT8173_MUTEX_MOD_DISP_OVL1,
> +	[DDP_COMPONENT_PWM0] = MT8173_MUTEX_MOD_DISP_PWM0,
> +	[DDP_COMPONENT_PWM1] = MT8173_MUTEX_MOD_DISP_PWM1,
> +	[DDP_COMPONENT_RDMA0] = MT8173_MUTEX_MOD_DISP_RDMA0,
> +	[DDP_COMPONENT_RDMA1] = MT8173_MUTEX_MOD_DISP_RDMA1,
> +	[DDP_COMPONENT_RDMA2] = MT8173_MUTEX_MOD_DISP_RDMA2,
> +	[DDP_COMPONENT_UFOE] = MT8173_MUTEX_MOD_DISP_UFOE,
> +	[DDP_COMPONENT_WDMA0] = MT8173_MUTEX_MOD_DISP_WDMA0,
> +	[DDP_COMPONENT_WDMA1] = MT8173_MUTEX_MOD_DISP_WDMA1,
>  };
>  
>  static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> @@ -247,7 +248,7 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
>  		break;
>  	default:
>  		reg = readl_relaxed(ddp->regs + DISP_REG_MUTEX_MOD(mutex->id));
> -		reg |= mutex_mod[id];
> +		reg |= ddp->mutex_mod[id];
>  		writel_relaxed(reg, ddp->regs + DISP_REG_MUTEX_MOD(mutex->id));
>  		return;
>  	}
> @@ -273,7 +274,7 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex *mutex,
>  		break;
>  	default:
>  		reg = readl_relaxed(ddp->regs + DISP_REG_MUTEX_MOD(mutex->id));
> -		reg &= ~mutex_mod[id];
> +		reg &= ~(ddp->mutex_mod[id]);
>  		writel_relaxed(reg, ddp->regs + DISP_REG_MUTEX_MOD(mutex->id));
>  		break;
>  	}
> @@ -326,6 +327,8 @@ static int mtk_ddp_probe(struct platform_device *pdev)
>  		return PTR_ERR(ddp->regs);
>  	}
>  
> +	ddp->mutex_mod = of_device_get_match_data(dev);
> +
>  	platform_set_drvdata(pdev, ddp);
>  
>  	return 0;
> @@ -337,7 +340,7 @@ static int mtk_ddp_remove(struct platform_device *pdev)
>  }
>  
>  static const struct of_device_id ddp_driver_dt_match[] = {
> -	{ .compatible = "mediatek,mt8173-disp-mutex" },
> +	{ .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
>  	{},
>  };
>  MODULE_DEVICE_TABLE(of, ddp_driver_dt_match);
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 48cc01f..3ff788c 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -39,9 +39,10 @@
>  #define DISP_REG_UFO_START			0x0000
>  
>  #define DISP_COLOR_CFG_MAIN			0x0400
> -#define DISP_COLOR_START			0x0c00
> -#define DISP_COLOR_WIDTH			0x0c50
> -#define DISP_COLOR_HEIGHT			0x0c54
> +#define DISP_COLOR_START_MT8173			0x0c00
> +#define DISP_COLOR_START(comp)			((comp)->data->color_offset)
> +#define DISP_COLOR_WIDTH(comp)			(DISP_COLOR_START(comp) + 0x50)
> +#define DISP_COLOR_HEIGHT(comp)			(DISP_COLOR_START(comp) + 0x54)
>  
>  #define DISP_AAL_EN				0x0000
>  #define DISP_AAL_SIZE				0x0030
> @@ -80,6 +81,20 @@
>  #define DITHER_ADD_LSHIFT_G(x)			(((x) & 0x7) << 4)
>  #define DITHER_ADD_RSHIFT_G(x)			(((x) & 0x7) << 0)
>  
> +struct mtk_disp_color_data {
> +	unsigned int color_offset;
> +};
> +
> +struct mtk_disp_color {
> +	struct mtk_ddp_comp			ddp_comp;
> +	const struct mtk_disp_color_data	*data;
> +};
> +
> +static inline struct mtk_disp_color *comp_to_color(struct mtk_ddp_comp *comp)
> +{
> +	return container_of(comp, struct mtk_disp_color, ddp_comp);
> +}
> +
>  void mtk_dither_set(struct mtk_ddp_comp *comp, unsigned int bpc,
>  		    unsigned int CFG)
>  {
> @@ -107,15 +122,19 @@ static void mtk_color_config(struct mtk_ddp_comp *comp, unsigned int w,
>  			     unsigned int h, unsigned int vrefresh,
>  			     unsigned int bpc)
>  {
> -	writel(w, comp->regs + DISP_COLOR_WIDTH);
> -	writel(h, comp->regs + DISP_COLOR_HEIGHT);
> +	struct mtk_disp_color *color = comp_to_color(comp);
> +
> +	writel(w, comp->regs + DISP_COLOR_WIDTH(color));
> +	writel(h, comp->regs + DISP_COLOR_HEIGHT(color));
>  }
>  
>  static void mtk_color_start(struct mtk_ddp_comp *comp)
>  {
> +	struct mtk_disp_color *color = comp_to_color(comp);
> +
>  	writel(COLOR_BYPASS_ALL | COLOR_SEQ_SEL,
>  	       comp->regs + DISP_COLOR_CFG_MAIN);
> -	writel(0x1, comp->regs + DISP_COLOR_START);
> +	writel(0x1, comp->regs + DISP_COLOR_START(color));
>  }
>  
>  static void mtk_od_config(struct mtk_ddp_comp *comp, unsigned int w,
> @@ -264,6 +283,16 @@ struct mtk_ddp_comp_match {
>  	[DDP_COMPONENT_WDMA1]	= { MTK_DISP_WDMA,	1, NULL },
>  };
>  
> +static const struct mtk_disp_color_data mt8173_color_driver_data = {
> +	.color_offset = DISP_COLOR_START_MT8173,
> +};
> +
> +static const struct of_device_id mtk_disp_color_driver_dt_match[] = {
> +	{ .compatible = "mediatek,mt8173-disp-color",
> +	  .data = &mt8173_color_driver_data},
> +	{},
> +};
> +
>  int mtk_ddp_comp_get_id(struct device_node *node,
>  			enum mtk_ddp_comp_type comp_type)
>  {
> @@ -286,10 +315,24 @@ int mtk_ddp_comp_init(struct device *dev, struct device_node *node,
>  	enum mtk_ddp_comp_type type;
>  	struct device_node *larb_node;
>  	struct platform_device *larb_pdev;
> +	const struct of_device_id *match;
> +	struct mtk_disp_color *color;
>  
>  	if (comp_id < 0 || comp_id >= DDP_COMPONENT_ID_MAX)
>  		return -EINVAL;
>  
> +	type = mtk_ddp_matches[comp_id].type;
> +	if (type == MTK_DISP_COLOR) {
> +		devm_kfree(dev, comp);
> +		color = devm_kzalloc(dev, sizeof(*color), GFP_KERNEL);
> +		if (!color)
> +			return -ENOMEM;
> +
> +		match = of_match_node(mtk_disp_color_driver_dt_match, node);
> +		color->data = match->data;
> +		comp = &color->ddp_comp;
> +	}
> +
>  	comp->id = comp_id;
>  	comp->funcs = funcs ?: mtk_ddp_matches[comp_id].funcs;
>  
> @@ -308,8 +351,6 @@ int mtk_ddp_comp_init(struct device *dev, struct device_node *node,
>  	if (IS_ERR(comp->clk))
>  		comp->clk = NULL;
>  
> -	type = mtk_ddp_matches[comp_id].type;
> -
>  	/* Only DMA capable components need the LARB property */
>  	comp->larb_dev = NULL;
>  	if (type != MTK_DISP_OVL &&
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 4b7fe7e..074fe31 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -128,7 +128,7 @@ static int mtk_atomic_commit(struct drm_device *drm,
>  	.atomic_commit = mtk_atomic_commit,
>  };
>  
> -static const enum mtk_ddp_comp_id mtk_ddp_main[] = {
> +static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
>  	DDP_COMPONENT_OVL0,
>  	DDP_COMPONENT_COLOR0,
>  	DDP_COMPONENT_AAL,
> @@ -139,7 +139,7 @@ static int mtk_atomic_commit(struct drm_device *drm,
>  	DDP_COMPONENT_PWM0,
>  };
>  
> -static const enum mtk_ddp_comp_id mtk_ddp_ext[] = {
> +static const enum mtk_ddp_comp_id mt8173_mtk_ddp_ext[] = {
>  	DDP_COMPONENT_OVL1,
>  	DDP_COMPONENT_COLOR1,
>  	DDP_COMPONENT_GAMMA,
> @@ -147,6 +147,13 @@ static int mtk_atomic_commit(struct drm_device *drm,
>  	DDP_COMPONENT_DPI0,
>  };
>  
> +static const struct mtk_mmsys_driver_data mt8173_mmsys_driver_data = {
> +	.main_path = mt8173_mtk_ddp_main,
> +	.main_len = ARRAY_SIZE(mt8173_mtk_ddp_main),
> +	.ext_path = mt8173_mtk_ddp_ext,
> +	.ext_len = ARRAY_SIZE(mt8173_mtk_ddp_ext),
> +};
> +
>  static int mtk_drm_kms_init(struct drm_device *drm)
>  {
>  	struct mtk_drm_private *private = drm->dev_private;
> @@ -189,17 +196,19 @@ static int mtk_drm_kms_init(struct drm_device *drm)
>  	 * and each statically assigned to a crtc:
>  	 * OVL0 -> COLOR0 -> AAL -> OD -> RDMA0 -> UFOE -> DSI0 ...
>  	 */
> -	ret = mtk_drm_crtc_create(drm, mtk_ddp_main, ARRAY_SIZE(mtk_ddp_main));
> +	ret = mtk_drm_crtc_create(drm, private->data->main_path,
> +				  private->data->main_len);
>  	if (ret < 0)
>  		goto err_component_unbind;
>  	/* ... and OVL1 -> COLOR1 -> GAMMA -> RDMA1 -> DPI0. */
> -	ret = mtk_drm_crtc_create(drm, mtk_ddp_ext, ARRAY_SIZE(mtk_ddp_ext));
> +	ret = mtk_drm_crtc_create(drm, private->data->ext_path,
> +				  private->data->ext_len);
>  	if (ret < 0)
>  		goto err_component_unbind;
>  
>  	/* Use OVL device for all DMA memory allocations */
> -	np = private->comp_node[mtk_ddp_main[0]] ?:
> -	     private->comp_node[mtk_ddp_ext[0]];
> +	np = private->comp_node[private->data->main_path[0]] ?:
> +	     private->comp_node[private->data->ext_path[0]];
>  	pdev = of_find_device_by_node(np);
>  	if (!pdev) {
>  		ret = -ENODEV;
> @@ -362,6 +371,7 @@ static int mtk_drm_probe(struct platform_device *pdev)
>  
>  	mutex_init(&private->commit.lock);
>  	INIT_WORK(&private->commit.work, mtk_atomic_work);
> +	private->data = of_device_get_match_data(dev);
>  
>  	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	private->config_regs = devm_ioremap_resource(dev, mem);
> @@ -513,7 +523,8 @@ static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend,
>  			 mtk_drm_sys_resume);
>  
>  static const struct of_device_id mtk_drm_of_ids[] = {
> -	{ .compatible = "mediatek,mt8173-mmsys", },
> +	{ .compatible = "mediatek,mt8173-mmsys",
> +	  .data = &mt8173_mmsys_driver_data},
>  	{ }
>  };
>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> index aa93894..fa0b106 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> @@ -28,6 +28,13 @@
>  struct drm_property;
>  struct regmap;
>  
> +struct mtk_mmsys_driver_data {
> +	const enum mtk_ddp_comp_id *main_path;
> +	unsigned int main_len;
> +	const enum mtk_ddp_comp_id *ext_path;
> +	unsigned int ext_len;
> +};
> +
>  struct mtk_drm_private {
>  	struct drm_device *drm;
>  	struct device *dma_dev;
> @@ -40,6 +47,7 @@ struct mtk_drm_private {
>  	void __iomem *config_regs;
>  	struct device_node *comp_node[DDP_COMPONENT_ID_MAX];
>  	struct mtk_ddp_comp *ddp_comp[DDP_COMPONENT_ID_MAX];
> +	const struct mtk_mmsys_driver_data *data;
>  
>  	struct {
>  		struct drm_atomic_state *state;
> diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> index 1c366f8..c4a0165 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> @@ -16,6 +16,7 @@
>  #include <linux/delay.h>
>  #include <linux/io.h>
>  #include <linux/module.h>
> +#include <linux/of_device.h>
>  #include <linux/platform_device.h>
>  #include <linux/phy/phy.h>
>  
> @@ -87,6 +88,9 @@
>  
>  #define MIPITX_DSI_PLL_CON2	0x58
>  
> +#define MIPITX_DSI_PLL_TOP	0x64
> +#define RG_DSI_MPPLL_PRESERVE		(0xff << 8)
> +
>  #define MIPITX_DSI_PLL_PWR	0x68
>  #define RG_DSI_MPPLL_SDM_PWR_ON		BIT(0)
>  #define RG_DSI_MPPLL_SDM_ISO_EN		BIT(1)
> @@ -123,10 +127,15 @@
>  #define SW_LNT2_HSTX_PRE_OE		BIT(24)
>  #define SW_LNT2_HSTX_OE			BIT(25)
>  
> +struct mtk_mipitx_data {
> +	const u32 mppll_preserve;
> +};
> +
>  struct mtk_mipi_tx {
>  	struct device *dev;
>  	void __iomem *regs;
>  	unsigned int data_rate;
> +	const struct mtk_mipitx_data *driver_data;
>  	struct clk_hw pll_hw;
>  	struct clk *pll;
>  };
> @@ -243,6 +252,10 @@ static int mtk_mipi_tx_pll_prepare(struct clk_hw *hw)
>  	mtk_mipi_tx_clear_bits(mipi_tx, MIPITX_DSI_PLL_CON1,
>  			       RG_DSI_MPPLL_SDM_SSC_EN);
>  
> +	mtk_mipi_tx_update_bits(mipi_tx, MIPITX_DSI_PLL_TOP,
> +				RG_DSI_MPPLL_PRESERVE,
> +				mipi_tx->driver_data->mppll_preserve);
> +
>  	return 0;
>  }
>  
> @@ -255,6 +268,9 @@ static void mtk_mipi_tx_pll_unprepare(struct clk_hw *hw)
>  	mtk_mipi_tx_clear_bits(mipi_tx, MIPITX_DSI_PLL_CON0,
>  			       RG_DSI_MPPLL_PLL_EN);
>  
> +	mtk_mipi_tx_update_bits(mipi_tx, MIPITX_DSI_PLL_TOP,
> +				RG_DSI_MPPLL_PRESERVE, 0);
> +
>  	mtk_mipi_tx_update_bits(mipi_tx, MIPITX_DSI_PLL_PWR,
>  				RG_DSI_MPPLL_SDM_ISO_EN |
>  				RG_DSI_MPPLL_SDM_PWR_ON,
> @@ -391,6 +407,7 @@ static int mtk_mipi_tx_probe(struct platform_device *pdev)
>  	if (!mipi_tx)
>  		return -ENOMEM;
>  
> +	mipi_tx->driver_data = of_device_get_match_data(dev);
>  	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	mipi_tx->regs = devm_ioremap_resource(dev, mem);
>  	if (IS_ERR(mipi_tx->regs)) {
> @@ -448,8 +465,13 @@ static int mtk_mipi_tx_remove(struct platform_device *pdev)
>  	return 0;
>  }
>  
> +static const struct mtk_mipitx_data mt8173_mipitx_data = {
> +	.mppll_preserve = (0 << 8)
> +};
> +
>  static const struct of_device_id mtk_mipi_tx_match[] = {
> -	{ .compatible = "mediatek,mt8173-mipi-tx", },
> +	{ .compatible = "mediatek,mt8173-mipi-tx",
> +	  .data = &mt8173_mipitx_data },
>  	{},
>  };
>  


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

^ permalink raw reply

* Re: [PATCH 0/4] ARM: dts: mt7623: Add initial Geek Force support
From: Andreas Färber @ 2017-01-16 19:34 UTC (permalink / raw)
  To: John Crispin, linux-mediatek
  Cc: Matthias Brugger, devicetree, linux-kernel, Paul Lai,
	linux-arm-kernel
In-Reply-To: <0bd6567e-1c5b-0ff6-d044-57d25e1a40d2@phrozen.org>

Hi John,

Am 12.01.2017 um 09:23 schrieb John Crispin:
> had a look last night why the ethernet dtsi was not added and it
> obviously was not added as we were waiting for the clk-mt2701 to be
> merged. the ethernet dtsi will have phandles pointing at the clk nodes
> which did not exist at the time. same is true for the PWM code.
> 
> i sat down last night and worked out what pending patches i still have
> for mt7623 and out of the ~80 required to get v4.4 working i only need
> around 10 for v4.10-rc1.
> 
> i started to rebase these patches last night and will have time to test
> them tomorrow or early next week. as the pwrap node alone is around 200
> lines of devicetree we need to figure out a way to add this to the dts
> files without duplicating it. i'll try to post a series early next week
> that we can then discuss and rebase your geekboard patches on.

Sounds like a plan. Many thanks!

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

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

^ permalink raw reply

* Re: [PATCH 0/4] ARM: dts: mt7623: Add initial Geek Force support
From: Andreas Färber @ 2017-01-16 19:31 UTC (permalink / raw)
  To: John Crispin, linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
  Cc: Matthias Brugger, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Paul Lai,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <3fecb422-8185-7ee0-c203-2bfdc4fd1393-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>

Am 10.01.2017 um 11:18 schrieb John Crispin:
> On 10/01/2017 10:48, Andreas Färber wrote:
>> Am 10.01.2017 um 08:00 schrieb John Crispin:
>>> On 08/01/2017 14:30, Andreas Färber wrote:
>>>>
>>>> Andreas Färber (4):
>>>>   Documentation: devicetree: Add vendor prefix for AsiaRF
>>>>   Documentation: devicetree: arm: mediatek: Add Geek Force board
>>>>   ARM: dts: mt7623: Add Geek Force config
>>>>   MAINTAINERS: Extend ARM/Mediatek SoC support section
>>>>
>>>
>>> Hi,
>>>
>>> i need to NAK this series. the asiarf board is nothing more than the
>>> official MTK EVB with AsiaRF written on it. this board is already
>>> supported by linux (arch/arm/boot/dts/mt7623-evb.dts) please extend the
>>> EVB dts file nstead of adding a duplicate and letting the original
> bitrot.
>>
>> Well, I disagree.
> 
> reading the rest of the email you seem to be quite agro about this.

Please re-read your reply above and my comments and reconsider your
attitude when replying in the future. It's not about whether these
patches go in or not, it's about your wording. And that continues with
aggressively throwing around the term "agro" in two mails already. I
don't see anything aggressive or angry in my original cover letter that
would've prompted your reply and can only interpret that as your own
frustration with your mt7623 progress. Instead you should've taken the
time to explain a bit better what you really meant, then we could've
spared or shortened this lengthy discussion and have a v2 already.

>> First of all I'm not letting "the original" bitrot, because I have
>> nothing to do with that .dts! If anyone is to blame for letting it
>> bitrot since February 2016, pick your own nose:
>>
>>
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/arch/arm/boot/dts/mt7623-evb.dts
> 
> what should i pick my nose about ?

Don't blame _me_ for "bitrot" of a file _you_ added almost a year ago
that did not see any updates since.

Nothing wrong with you not working on something, just don't blame me for
it then, especially when I don't (knowingly) have that hardware and have
never come in touch with it before. I am new to linux-mediatek and had
checked LAKML in vein for any mt7623 patches before sending mine.

[snip]
>> Third, by your argumentation we shouldn't be adding, e.g., Odroid .dts
>> files either because they were based on a Samsung SMDK, or .dts files
>> for Amlogic TV boxes because they're almost identical to reference
>> designs, etc.
>> Users need to know which .dts file to choose, so having a sane .dts
>> filename is warranted. Depending on how similar they are, one could
>> either #include the -evb.dts or factor out a shared .dtsi, but that
>> takes us back to the previous point of hardly anyone having access to
>> EVB information to identify such a subset. Therefore duplicating trivial
>> nodes is the method of choice for all practical purposes - mt7623.dtsi
>> is getting reused just fine.
>>
> 
> in that case add a dtsi file for the EVB and include it in your geek
> board.dts and only update the compat string.

The question that I am not in a position to answer is: Are those two
boards identical or just very similar? Paul in CC can hopefully clarify
this when he is back. Matthias as maintainer has also remained silent.

>> Comparing our two .dts files, mine has two more UART nodes enabled, the
>> U-Boot bootloader's baudrate set to actually get serial output, a
>> different board compatible string for identification, and I chose the
>> new dual-licensing header that is being requested for new DT files.
> 
> 1) at the time we adde this the uart support was not ready

> 2) the bootloader i am using is a custom built one hence the random baudrate

Well, did the _original_ bootloader use 115200? In that case we could
update -evb.dts with it, and you could still override it via console=
for your custom build.

Or maybe having source access you could even contribute to mainline
U-Boot, so we can all work on the same codebase? I read a BPi-R2 is
coming up with mt7623, so booting without appended .dtb and uImage will
come in handy for more people than just EVB owners and Geek Force
backers. I'd happily contribute to making bootefi command work.

> 3) you can just updae the license if you want to, no problem

OK, will gladly look into the feasibility.

>> For lack of schematics I figured out UART1 by testing - continuity tests
>> for GND, console=ttySx,115200n8 and trial-and-error for RX/TX. Obviously
>> I can't do that for a board I don't have access to.
>> UART2 and UART0 pins were clear, but only UART2 was obvious from ttyMT2.
> 
> you do have the EVB directly in front of you
> 
>> Do you actually have access to a Geek Force board yourself, or what are
>> you basing your claims on? Mine looks different from the Indiegogo
>> picture and thus has different identification from that on
>> https://wikidevi.com/wiki/AsiaRF_WS2977 (WS3301, MT7623N RFB_V10).
> 
> i dont need the geek board as i have the EVB and they are identical
> according to MTK
> 
>> If you confirm the EVB's baudrate I can happily send that part your way.
>> I've seen 921600 on the Helio X20 96board for instance.
> 
> see above

So... 4) add my UART nodes to your -evb.dts? Any nitpicks on the actual
patch 3/4?

>> Also, none of what you've said justifies NAK'ing patch 4/4, which
>> applies to any mt7* and arm64 .dts, including yours.
> 
> agreed, i never even mentioned 4/4

You replied to the cover letter 0/4 "i need to NAK this series" - and
series includes all four patches. Therefore my frustration with your
hip-shot reply. If you haven't read the patch, don't NAK it!

In fact still no one replied to it at all, even now that you're aware of
its existence.

>> While we're at it, I noticed that mainline has a "mediatek,mt7623-eth"
>> network driver but no corresponding .dtsi node. Talk about bitrot...
> 
> the idea is that we work together to make thins optimal. this is not a
> you or is right. this is about the FOSS peer review process. please dont
> be so agro.

See above, please reconsider your tone. Peer review is no excuse for
rude and destructive behavior towards contributors you don't know.

Had you looked at the lists and codebase you would know that I am not
new to FOSS.

And please stop writing "agro", it sounds like some pothead making a
peace sign; not helpful among professional software developers.

Taking the time to start your sentences with a capital letter would also
be a respectful gesture.

> to me it seems suboptimal to support 2 dts files for the same board.

If it is the identical board, then we are in violent agreement. I just
find all your replies to me offensive so far, I don't know you and thus
have no reason to trust your unsubstantiated claims about my board.

Regards,

Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Marek Vasut @ 2017-01-16 16:09 UTC (permalink / raw)
  To: Boris Brezillon, Rob Herring, Mark Rutland
  Cc: Matthias Brugger, Guochun Mao, David Woodhouse, Brian Norris,
	Richard Weinberger, Cyrille Pitchen, Russell King,
	linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170116094032.6f471f11@bbrezillon>

On 01/16/2017 09:40 AM, Boris Brezillon wrote:
> On Sun, 15 Jan 2017 01:23:48 +0100
> Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
>> On 01/14/2017 09:29 AM, Boris Brezillon wrote:
>>> On Fri, 13 Jan 2017 18:33:40 +0100
>>> Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>   
>>>> On 01/13/2017 05:56 PM, Boris Brezillon wrote:  
>>>>> On Fri, 13 Jan 2017 17:44:12 +0100
>>>>> Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>     
>>>>>> On 01/13/2017 05:28 PM, Boris Brezillon wrote:    
>>>>>>> On Fri, 13 Jan 2017 17:13:55 +0100
>>>>>>> Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>>>       
>>>>>>>> On 01/13/2017 04:12 PM, Matthias Brugger wrote:      
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 13/01/17 15:17, Boris Brezillon wrote:        
>>>>>>>>>> On Fri, 13 Jan 2017 15:13:29 +0800
>>>>>>>>>> Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
>>>>>>>>>>        
>>>>>>>>>>> Add Mediatek nor flash node.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>>>>>>>>>> ---
>>>>>>>>>>>  arch/arm/boot/dts/mt2701-evb.dts |   25 +++++++++++++++++++++++++
>>>>>>>>>>>  arch/arm/boot/dts/mt2701.dtsi    |   12 ++++++++++++
>>>>>>>>>>>  2 files changed, 37 insertions(+)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>>>>>> b/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>>>>>> index 082ca88..85e5ae8 100644
>>>>>>>>>>> --- a/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>>>>>> +++ b/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>>>>>> @@ -24,6 +24,31 @@
>>>>>>>>>>>      };
>>>>>>>>>>>  };
>>>>>>>>>>>
>>>>>>>>>>> +&nor_flash {
>>>>>>>>>>> +    pinctrl-names = "default";
>>>>>>>>>>> +    pinctrl-0 = <&nor_pins_default>;
>>>>>>>>>>> +    status = "okay";
>>>>>>>>>>> +    flash@0 {
>>>>>>>>>>> +        compatible = "jedec,spi-nor";
>>>>>>>>>>> +        reg = <0>;
>>>>>>>>>>> +    };
>>>>>>>>>>> +};
>>>>>>>>>>> +
>>>>>>>>>>> +&pio {
>>>>>>>>>>> +    nor_pins_default: nor {
>>>>>>>>>>> +        pins1 {
>>>>>>>>>>> +            pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
>>>>>>>>>>> +                 <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
>>>>>>>>>>> +                 <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
>>>>>>>>>>> +                 <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
>>>>>>>>>>> +                 <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
>>>>>>>>>>> +                 <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
>>>>>>>>>>> +            drive-strength = <MTK_DRIVE_4mA>;
>>>>>>>>>>> +            bias-pull-up;
>>>>>>>>>>> +        };
>>>>>>>>>>> +    };
>>>>>>>>>>> +};
>>>>>>>>>>> +
>>>>>>>>>>>  &uart0 {
>>>>>>>>>>>      status = "okay";
>>>>>>>>>>>  };
>>>>>>>>>>> diff --git a/arch/arm/boot/dts/mt2701.dtsi
>>>>>>>>>>> b/arch/arm/boot/dts/mt2701.dtsi
>>>>>>>>>>> index bdf8954..1eefce4 100644
>>>>>>>>>>> --- a/arch/arm/boot/dts/mt2701.dtsi
>>>>>>>>>>> +++ b/arch/arm/boot/dts/mt2701.dtsi
>>>>>>>>>>> @@ -227,6 +227,18 @@
>>>>>>>>>>>          status = "disabled";
>>>>>>>>>>>      };
>>>>>>>>>>>
>>>>>>>>>>> +    nor_flash: spi@11014000 {
>>>>>>>>>>> +        compatible = "mediatek,mt2701-nor",
>>>>>>>>>>> +                 "mediatek,mt8173-nor";        
>>>>>>>>>>
>>>>>>>>>> Why define both here? Is "mediatek,mt8173-nor" really providing a
>>>>>>>>>> subset of the features supported by "mediatek,mt2701-nor"?
>>>>>>>>>>        
>>>>>>>>>
>>>>>>>>> I think even if the ip block is the same, we should provide both
>>>>>>>>> bindings, just in case in the future we find out that mt2701 has some
>>>>>>>>> hidden bug, feature or bug-feature. This way even if we update the
>>>>>>>>> driver, we stay compatible with older device tree blobs in the wild.
>>>>>>>>>
>>>>>>>>> We can drop the mt2701-nor in the bindings definition if you want.       
>>>>>>>
>>>>>>> Oh, sorry, I misunderstood. What I meant is that if you want to
>>>>>>> list/support all possible compatibles, maybe you should just put one
>>>>>>> compatible in your DT and patch your driver (+ binding doc) to define
>>>>>>> all of them.      
>>>>>>
>>>>>> Uh, what ? I lost you here :-)  
>>>
>>> I mean adding a new entry in the mtk_nor_of_ids table (in
>>> mtk-quadspi.c) so that the mediatek,mt2701-nor compatible string can be
>>> matched directly, and you won't need to define 2 compatible strings in
>>> your device tree.  
>>
>> But then you grow the table in the driver, is that what we want if we
>> can avoid that ?
> 
> The space you save by not growing the mtk_nor_of_ids table is lost in
> your dtbs, so I'm not sure the size argument is relevant here. Also,
> note that distros are shipping a lot of dtbs, and you're likely to have
> several boards based on the mt2701 SoC, so, for this specific use case,
> it's better to make the in-driver of-id table grow than specifying 2
> compatibles in the DT. But as I said, I'm not sure we should rely on
> this argument to decide which approach to choose (we're talking about a
> few bytes here).
> 
>>
>>>>>>    
>>>>>>>> This exactly. We should have a DT compat in the form:
>>>>>>>> compatible = "vendor,<soc>-block", "vendor,<oldest-compat-soc>-block";
>>>>>>>> Then if we find a problem in the future, we can match on the
>>>>>>>> "vendor,<soc>-block" and still support the old DTs.      
>>>>>>>
>>>>>>> Not sure it's only in term of whose IP appeared first. My understanding
>>>>>>> is that it's a way to provide inheritance. For example:
>>>>>>>
>>>>>>> 	"<soc-vendor>,<ip-version>", "<ip-vendor>,<ip-version>";
>>>>>>>
>>>>>>> or
>>>>>>>
>>>>>>> 	"<soc-vendor>,<full-featured-ip-version>","<soc-vendor>,<basic-feature-ip-version>";
>>>>>>>
>>>>>>> BTW, which one is the oldest between mt8173 and mt2701? :-)      
>>>>>>
>>>>>> And that's another thing and I agree with you, but I don't think that's
>>>>>> what we're discussing in this thread. But (!), OT, I think we should
>>>>>> codify the rules in Documentation/ . This discussion came up multiple
>>>>>> times recently.
>>>>>>
>>>>>> And my question still stands, what do we put into the DT here, IMO
>>>>>> compatible = "mediatek,mt2701-nor", "mediatek,mt8173-nor";    
>>>>>
>>>>> I'd say
>>>>>
>>>>> 	compatible = "mediatek,mt8173-nor";
>>>>>
>>>>> because both compatible are referring to very specific IP version. It's
>>>>> not the same as    
>>>>
>>>> But then you don't have the ability to handle a block in this particular
>>>> SoC in case there's a bug found in it in the future,
>>>> so IMO it should be:
>>>>
>>>> compatible = "mediatek,mt2701-nor", "mediatek,mt8173-nor";  
>>>
>>> Sorry again, I meant
>>>
>>> 	compatible = "mediatek,mt2701-nor";
>>>   
>>>>  
>>>>> 	compatible = "mediatek,mt8173-nor", "mediatek,mt81xx-nor";    
>>>>
>>>> This doesn't look right, since here we add two new compatibles ...  
>>>
>>> That was just an example to describe how compatible inheritance works
>>> (at least that's my understanding of it), it does not apply to this
>>> particular use case.  
>>
>> Well this is OK I guess, but then you can also use "mediatek,mt8173-nor"
>> as the oldest supported compatible and be done with it, no ? It looks a
>> bit crappy though, I admit that ...
>>
> 
> Let's stop bikeshedding and wait for DT maintainers feedback
> before taking a decision ;-).

+1 :)

> Rob, Mark, any opinion?
> 


-- 
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH] drivers: phy: constify phy_ops structures
From: Kishon Vijay Abraham I @ 2017-01-16  9:11 UTC (permalink / raw)
  To: Bhumika Goyal, julia.lawall, rjui, sbranden, jonmason,
	bcm-kernel-feedback-list, chunfeng.yun, yoshihiro.shimoda.uh,
	linux-kernel, linux-arm-kernel, linux-mediatek, linux-renesas-soc
In-Reply-To: <1483871756-19008-1-git-send-email-bhumirks@gmail.com>



On Sunday 08 January 2017 04:05 PM, Bhumika Goyal wrote:
> Declare phy_ops structures as const as they are only passed as an
> argument to the function devm_phy_create. This argument is of type const
> struct phy_ops *, so phy_ops structures having this property can be
> declared as const.
> Done using Coccinelle:

removed the rest of commit message and merged.

Thanks
Kishon

> 
> @r1 disable optional_qualifier @
> identifier i;
> position p;
> @@
> static struct phy_ops i@p = {...};
> 
> @ok1@
> identifier r1.i;
> position p;
> @@
> devm_phy_create(...,&i@p)
> 
> @bad@
> position p!={r1.p,ok1.p};
> identifier r1.i;
> @@
> i@p
> 
> @depends on !bad disable optional_qualifier@
> identifier r1.i;
> @@
> +const
> struct phy_ops i;
> 
> File size details:
> 
>    text	   data	    bss	    dec	    hex	filename
>    1504	    264	      0	   1768	    6e8	phy/phy-bcm-cygnus-pcie.o
>    1576	    192	      0	   1768	    6e8	phy/phy-bcm-cygnus-pcie.o
> 
>    1083	    264	      0	   1347	    543	phy/phy-hi6220-usb.o
>    1155	    192	      0	   1347	    543	phy/phy-hi6220-usb.o
> 
>    2767	    264	      0	   3031	    bd7	phy/phy-mt65xx-usb3.o
>    2829	    192	      0	   3021	    bcd	phy/phy-mt65xx-usb3.o
> 
>    2710	    304	      0	   3014	    bc6	phy/phy-rcar-gen3-usb2.o
>    2766	    240	      0	   3006	    bbe	phy/phy-rcar-gen3-usb2.o
> 
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
> ---
>  drivers/phy/phy-bcm-cygnus-pcie.c | 2 +-
>  drivers/phy/phy-hi6220-usb.c      | 2 +-
>  drivers/phy/phy-mt65xx-usb3.c     | 2 +-
>  drivers/phy/phy-rcar-gen3-usb2.c  | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/phy/phy-bcm-cygnus-pcie.c b/drivers/phy/phy-bcm-cygnus-pcie.c
> index 082c03f..0f4ac5d 100644
> --- a/drivers/phy/phy-bcm-cygnus-pcie.c
> +++ b/drivers/phy/phy-bcm-cygnus-pcie.c
> @@ -114,7 +114,7 @@ static int cygnus_pcie_phy_power_off(struct phy *p)
>  	return cygnus_pcie_power_config(phy, false);
>  }
>  
> -static struct phy_ops cygnus_pcie_phy_ops = {
> +static const struct phy_ops cygnus_pcie_phy_ops = {
>  	.power_on = cygnus_pcie_phy_power_on,
>  	.power_off = cygnus_pcie_phy_power_off,
>  	.owner = THIS_MODULE,
> diff --git a/drivers/phy/phy-hi6220-usb.c b/drivers/phy/phy-hi6220-usb.c
> index b2141cb..398c102 100644
> --- a/drivers/phy/phy-hi6220-usb.c
> +++ b/drivers/phy/phy-hi6220-usb.c
> @@ -112,7 +112,7 @@ static int hi6220_phy_exit(struct phy *phy)
>  	return hi6220_phy_setup(priv, false);
>  }
>  
> -static struct phy_ops hi6220_phy_ops = {
> +static const struct phy_ops hi6220_phy_ops = {
>  	.init		= hi6220_phy_start,
>  	.exit		= hi6220_phy_exit,
>  	.owner		= THIS_MODULE,
> diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
> index 4d85e73..d972067 100644
> --- a/drivers/phy/phy-mt65xx-usb3.c
> +++ b/drivers/phy/phy-mt65xx-usb3.c
> @@ -506,7 +506,7 @@ static struct phy *mt65xx_phy_xlate(struct device *dev,
>  	return instance->phy;
>  }
>  
> -static struct phy_ops mt65xx_u3phy_ops = {
> +static const struct phy_ops mt65xx_u3phy_ops = {
>  	.init		= mt65xx_phy_init,
>  	.exit		= mt65xx_phy_exit,
>  	.power_on	= mt65xx_phy_power_on,
> diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drivers/phy/phy-rcar-gen3-usb2.c
> index c63da1b..17be045 100644
> --- a/drivers/phy/phy-rcar-gen3-usb2.c
> +++ b/drivers/phy/phy-rcar-gen3-usb2.c
> @@ -350,7 +350,7 @@ static int rcar_gen3_phy_usb2_power_off(struct phy *p)
>  	return ret;
>  }
>  
> -static struct phy_ops rcar_gen3_phy_usb2_ops = {
> +static const struct phy_ops rcar_gen3_phy_usb2_ops = {
>  	.init		= rcar_gen3_phy_usb2_init,
>  	.exit		= rcar_gen3_phy_usb2_exit,
>  	.power_on	= rcar_gen3_phy_usb2_power_on,
> 

^ permalink raw reply

* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Boris Brezillon @ 2017-01-16  8:40 UTC (permalink / raw)
  To: Marek Vasut, Rob Herring, Mark Rutland
  Cc: Matthias Brugger, Guochun Mao, David Woodhouse, Brian Norris,
	Richard Weinberger, Cyrille Pitchen, Russell King,
	linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <e7fa1542-f0e2-0e45-23b3-25d6491ae40d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On Sun, 15 Jan 2017 01:23:48 +0100
Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On 01/14/2017 09:29 AM, Boris Brezillon wrote:
> > On Fri, 13 Jan 2017 18:33:40 +0100
> > Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >   
> >> On 01/13/2017 05:56 PM, Boris Brezillon wrote:  
> >>> On Fri, 13 Jan 2017 17:44:12 +0100
> >>> Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>>     
> >>>> On 01/13/2017 05:28 PM, Boris Brezillon wrote:    
> >>>>> On Fri, 13 Jan 2017 17:13:55 +0100
> >>>>> Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>>>>       
> >>>>>> On 01/13/2017 04:12 PM, Matthias Brugger wrote:      
> >>>>>>>
> >>>>>>>
> >>>>>>> On 13/01/17 15:17, Boris Brezillon wrote:        
> >>>>>>>> On Fri, 13 Jan 2017 15:13:29 +0800
> >>>>>>>> Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> >>>>>>>>        
> >>>>>>>>> Add Mediatek nor flash node.
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> >>>>>>>>> ---
> >>>>>>>>>  arch/arm/boot/dts/mt2701-evb.dts |   25 +++++++++++++++++++++++++
> >>>>>>>>>  arch/arm/boot/dts/mt2701.dtsi    |   12 ++++++++++++
> >>>>>>>>>  2 files changed, 37 insertions(+)
> >>>>>>>>>
> >>>>>>>>> diff --git a/arch/arm/boot/dts/mt2701-evb.dts
> >>>>>>>>> b/arch/arm/boot/dts/mt2701-evb.dts
> >>>>>>>>> index 082ca88..85e5ae8 100644
> >>>>>>>>> --- a/arch/arm/boot/dts/mt2701-evb.dts
> >>>>>>>>> +++ b/arch/arm/boot/dts/mt2701-evb.dts
> >>>>>>>>> @@ -24,6 +24,31 @@
> >>>>>>>>>      };
> >>>>>>>>>  };
> >>>>>>>>>
> >>>>>>>>> +&nor_flash {
> >>>>>>>>> +    pinctrl-names = "default";
> >>>>>>>>> +    pinctrl-0 = <&nor_pins_default>;
> >>>>>>>>> +    status = "okay";
> >>>>>>>>> +    flash@0 {
> >>>>>>>>> +        compatible = "jedec,spi-nor";
> >>>>>>>>> +        reg = <0>;
> >>>>>>>>> +    };
> >>>>>>>>> +};
> >>>>>>>>> +
> >>>>>>>>> +&pio {
> >>>>>>>>> +    nor_pins_default: nor {
> >>>>>>>>> +        pins1 {
> >>>>>>>>> +            pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
> >>>>>>>>> +                 <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
> >>>>>>>>> +                 <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
> >>>>>>>>> +                 <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
> >>>>>>>>> +                 <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
> >>>>>>>>> +                 <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
> >>>>>>>>> +            drive-strength = <MTK_DRIVE_4mA>;
> >>>>>>>>> +            bias-pull-up;
> >>>>>>>>> +        };
> >>>>>>>>> +    };
> >>>>>>>>> +};
> >>>>>>>>> +
> >>>>>>>>>  &uart0 {
> >>>>>>>>>      status = "okay";
> >>>>>>>>>  };
> >>>>>>>>> diff --git a/arch/arm/boot/dts/mt2701.dtsi
> >>>>>>>>> b/arch/arm/boot/dts/mt2701.dtsi
> >>>>>>>>> index bdf8954..1eefce4 100644
> >>>>>>>>> --- a/arch/arm/boot/dts/mt2701.dtsi
> >>>>>>>>> +++ b/arch/arm/boot/dts/mt2701.dtsi
> >>>>>>>>> @@ -227,6 +227,18 @@
> >>>>>>>>>          status = "disabled";
> >>>>>>>>>      };
> >>>>>>>>>
> >>>>>>>>> +    nor_flash: spi@11014000 {
> >>>>>>>>> +        compatible = "mediatek,mt2701-nor",
> >>>>>>>>> +                 "mediatek,mt8173-nor";        
> >>>>>>>>
> >>>>>>>> Why define both here? Is "mediatek,mt8173-nor" really providing a
> >>>>>>>> subset of the features supported by "mediatek,mt2701-nor"?
> >>>>>>>>        
> >>>>>>>
> >>>>>>> I think even if the ip block is the same, we should provide both
> >>>>>>> bindings, just in case in the future we find out that mt2701 has some
> >>>>>>> hidden bug, feature or bug-feature. This way even if we update the
> >>>>>>> driver, we stay compatible with older device tree blobs in the wild.
> >>>>>>>
> >>>>>>> We can drop the mt2701-nor in the bindings definition if you want.       
> >>>>>
> >>>>> Oh, sorry, I misunderstood. What I meant is that if you want to
> >>>>> list/support all possible compatibles, maybe you should just put one
> >>>>> compatible in your DT and patch your driver (+ binding doc) to define
> >>>>> all of them.      
> >>>>
> >>>> Uh, what ? I lost you here :-)  
> > 
> > I mean adding a new entry in the mtk_nor_of_ids table (in
> > mtk-quadspi.c) so that the mediatek,mt2701-nor compatible string can be
> > matched directly, and you won't need to define 2 compatible strings in
> > your device tree.  
> 
> But then you grow the table in the driver, is that what we want if we
> can avoid that ?

The space you save by not growing the mtk_nor_of_ids table is lost in
your dtbs, so I'm not sure the size argument is relevant here. Also,
note that distros are shipping a lot of dtbs, and you're likely to have
several boards based on the mt2701 SoC, so, for this specific use case,
it's better to make the in-driver of-id table grow than specifying 2
compatibles in the DT. But as I said, I'm not sure we should rely on
this argument to decide which approach to choose (we're talking about a
few bytes here).

> 
> >>>>    
> >>>>>> This exactly. We should have a DT compat in the form:
> >>>>>> compatible = "vendor,<soc>-block", "vendor,<oldest-compat-soc>-block";
> >>>>>> Then if we find a problem in the future, we can match on the
> >>>>>> "vendor,<soc>-block" and still support the old DTs.      
> >>>>>
> >>>>> Not sure it's only in term of whose IP appeared first. My understanding
> >>>>> is that it's a way to provide inheritance. For example:
> >>>>>
> >>>>> 	"<soc-vendor>,<ip-version>", "<ip-vendor>,<ip-version>";
> >>>>>
> >>>>> or
> >>>>>
> >>>>> 	"<soc-vendor>,<full-featured-ip-version>","<soc-vendor>,<basic-feature-ip-version>";
> >>>>>
> >>>>> BTW, which one is the oldest between mt8173 and mt2701? :-)      
> >>>>
> >>>> And that's another thing and I agree with you, but I don't think that's
> >>>> what we're discussing in this thread. But (!), OT, I think we should
> >>>> codify the rules in Documentation/ . This discussion came up multiple
> >>>> times recently.
> >>>>
> >>>> And my question still stands, what do we put into the DT here, IMO
> >>>> compatible = "mediatek,mt2701-nor", "mediatek,mt8173-nor";    
> >>>
> >>> I'd say
> >>>
> >>> 	compatible = "mediatek,mt8173-nor";
> >>>
> >>> because both compatible are referring to very specific IP version. It's
> >>> not the same as    
> >>
> >> But then you don't have the ability to handle a block in this particular
> >> SoC in case there's a bug found in it in the future,
> >> so IMO it should be:
> >>
> >> compatible = "mediatek,mt2701-nor", "mediatek,mt8173-nor";  
> > 
> > Sorry again, I meant
> > 
> > 	compatible = "mediatek,mt2701-nor";
> >   
> >>  
> >>> 	compatible = "mediatek,mt8173-nor", "mediatek,mt81xx-nor";    
> >>
> >> This doesn't look right, since here we add two new compatibles ...  
> > 
> > That was just an example to describe how compatible inheritance works
> > (at least that's my understanding of it), it does not apply to this
> > particular use case.  
> 
> Well this is OK I guess, but then you can also use "mediatek,mt8173-nor"
> as the oldest supported compatible and be done with it, no ? It looks a
> bit crappy though, I admit that ...
> 

Let's stop bikeshedding and wait for DT maintainers feedback
before taking a decision ;-).

Rob, Mark, any opinion?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v2 6/6] arm: dts: mt2701: Add thermal device node.
From: Dawei Chien @ 2017-01-16  3:46 UTC (permalink / raw)
  To: Matthias Brugger
  Cc: Erin Lo, srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1484538290.13258.3.camel@mtksdaap41>

On Mon, 2017-01-16 at 11:44 +0800, Dawei Chien wrote:
> On Fri, 2017-01-13 at 16:27 +0100, Matthias Brugger wrote:
> > 
> > On 13/01/17 09:42, Erin Lo wrote:
> > > From: Dawei Chien <dawei.chien-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > >
> > > Add thermal controller device nodes for MT2701.
> > >
> > > Signed-off-by: Dawei Chien <dawei.chien-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > > Signed-off-by: Erin Lo <erin.lo-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > > ---
> > >  arch/arm/boot/dts/mt2701.dtsi | 43 +++++++++++++++++++++++++++++++++++++++++++
> > >  1 file changed, 43 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> > > index 3847f70..c43d5f8 100644
> > > --- a/arch/arm/boot/dts/mt2701.dtsi
> > > +++ b/arch/arm/boot/dts/mt2701.dtsi
> > > @@ -89,6 +89,36 @@
> > >  		clock-output-names = "rtc32k";
> > >  	};
> > >
> > > +	thermal-zones {
> > > +		cpu_thermal: cpu_thermal {
> > > +			polling-delay-passive = <1000>; /* milliseconds */
> > > +			polling-delay = <1000>; /* milliseconds */
> > > +
> > > +			thermal-sensors = <&thermal 0>;
> > > +			sustainable-power = <1000>;
> > > +
> > > +			trips {
> > > +				threshold: trip-point@0 {
> > > +					temperature = <68000>;
> > > +					hysteresis = <2000>;
> > > +					type = "passive";
> > > +				};
> > > +
> > > +				target: trip-point@1 {
> > > +					temperature = <85000>;
> > > +					hysteresis = <2000>;
> > > +					type = "passive";
> > > +				};
> > > +
> > > +				cpu_crit: cpu_crit@0 {
> > > +					temperature = <115000>;
> > > +					hysteresis = <2000>;
> > > +					type = "critical";
> > > +				};
> > > +			};
> > > +		};
> > > +	};
> > > +
> > >  	timer {
> > >  		compatible = "arm,armv7-timer";
> > >  		interrupt-parent = <&gic>;
> > > @@ -270,6 +300,19 @@
> > >  		status = "disabled";
> > >  	};
> > >
> > > +	thermal: thermal@1100b000 {
> > > +		#thermal-sensor-cells = <0>;
> > > +		compatible = "mediatek,mt2701-thermal";
> > > +		reg = <0 0x1100b000 0 0x1000>;
> > > +		interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_LOW>;
> > > +		clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
> > > +		clock-names = "therm", "auxadc";
> > > +		resets = <&pericfg 0x10>;
> > 
> > should be MT2701_PERI_AUXADC_SW_RST, right?
> > 
> Thank you for your reminding, I didn't realize mt2701-resets.h upstream
> already, I would update on next version, thank you.
> 
> resets = <&pericfg MT2701_PERI_AUXADC_SW_RST>;

Actually, Should be MT2701_PERI_THERM_SW_RST.

resets = <&pericfg MT2701_PERI_THERM_SW_RST>;

> > > +		reset-names = "therm";
> > > +		mediatek,auxadc = <&auxadc>;
> > > +		mediatek,apmixedsys = <&apmixedsys>;
> > > +	};
> > > +
> > >  	nandc: nfi@1100d000 {
> > >  		compatible = "mediatek,mt2701-nfc";
> > >  		reg = <0 0x1100d000 0 0x1000>;
> > >
> 


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v2 6/6] arm: dts: mt2701: Add thermal device node.
From: Dawei Chien @ 2017-01-16  3:44 UTC (permalink / raw)
  To: Matthias Brugger
  Cc: Erin Lo, srv_heupstream, devicetree, linux-arm-kernel,
	linux-kernel, linux-mediatek
In-Reply-To: <c8bbd4a4-2207-44f0-4462-3761c1d6c8a9@gmail.com>

On Fri, 2017-01-13 at 16:27 +0100, Matthias Brugger wrote:
> 
> On 13/01/17 09:42, Erin Lo wrote:
> > From: Dawei Chien <dawei.chien@mediatek.com>
> >
> > Add thermal controller device nodes for MT2701.
> >
> > Signed-off-by: Dawei Chien <dawei.chien@mediatek.com>
> > Signed-off-by: Erin Lo <erin.lo@mediatek.com>
> > ---
> >  arch/arm/boot/dts/mt2701.dtsi | 43 +++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 43 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> > index 3847f70..c43d5f8 100644
> > --- a/arch/arm/boot/dts/mt2701.dtsi
> > +++ b/arch/arm/boot/dts/mt2701.dtsi
> > @@ -89,6 +89,36 @@
> >  		clock-output-names = "rtc32k";
> >  	};
> >
> > +	thermal-zones {
> > +		cpu_thermal: cpu_thermal {
> > +			polling-delay-passive = <1000>; /* milliseconds */
> > +			polling-delay = <1000>; /* milliseconds */
> > +
> > +			thermal-sensors = <&thermal 0>;
> > +			sustainable-power = <1000>;
> > +
> > +			trips {
> > +				threshold: trip-point@0 {
> > +					temperature = <68000>;
> > +					hysteresis = <2000>;
> > +					type = "passive";
> > +				};
> > +
> > +				target: trip-point@1 {
> > +					temperature = <85000>;
> > +					hysteresis = <2000>;
> > +					type = "passive";
> > +				};
> > +
> > +				cpu_crit: cpu_crit@0 {
> > +					temperature = <115000>;
> > +					hysteresis = <2000>;
> > +					type = "critical";
> > +				};
> > +			};
> > +		};
> > +	};
> > +
> >  	timer {
> >  		compatible = "arm,armv7-timer";
> >  		interrupt-parent = <&gic>;
> > @@ -270,6 +300,19 @@
> >  		status = "disabled";
> >  	};
> >
> > +	thermal: thermal@1100b000 {
> > +		#thermal-sensor-cells = <0>;
> > +		compatible = "mediatek,mt2701-thermal";
> > +		reg = <0 0x1100b000 0 0x1000>;
> > +		interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_LOW>;
> > +		clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
> > +		clock-names = "therm", "auxadc";
> > +		resets = <&pericfg 0x10>;
> 
> should be MT2701_PERI_AUXADC_SW_RST, right?
> 
Thank you for your reminding, I didn't realize mt2701-resets.h upstream
already, I would update on next version, thank you.

resets = <&pericfg MT2701_PERI_AUXADC_SW_RST>;

> > +		reset-names = "therm";
> > +		mediatek,auxadc = <&auxadc>;
> > +		mediatek,apmixedsys = <&apmixedsys>;
> > +	};
> > +
> >  	nandc: nfi@1100d000 {
> >  		compatible = "mediatek,mt2701-nfc";
> >  		reg = <0 0x1100d000 0 0x1000>;
> >

^ permalink raw reply

* Re: [PATCH v2 2/6] arm: dts: mt2701: Add iommu/smi device node
From: Honghui Zhang @ 2017-01-16  2:54 UTC (permalink / raw)
  To: Matthias Brugger
  Cc: Erin Lo, srv_heupstream, devicetree, linux-arm-kernel,
	linux-kernel, linux-mediatek
In-Reply-To: <02062506-f917-0140-4934-31d7d3317b80@gmail.com>

On Fri, 2017-01-13 at 16:05 +0100, Matthias Brugger wrote:
> Hi Erin,
> 
> I just took the patch from Honghui he send in june.
> Please see my comment inline.
> 
> On 13/01/17 09:42, Erin Lo wrote:
> > From: Honghui Zhang <honghui.zhang@mediatek.com>
> >
> > Add the device node of iommu and smi for MT2701.
> >
> > Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
> > Signed-off-by: Erin Lo <erin.lo@mediatek.com>
> > ---
> >  arch/arm/boot/dts/mt2701.dtsi | 54 +++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 54 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> > index eb4c6fd..87be52c 100644
> > --- a/arch/arm/boot/dts/mt2701.dtsi
> > +++ b/arch/arm/boot/dts/mt2701.dtsi
> > @@ -17,6 +17,7 @@
> >  #include <dt-bindings/interrupt-controller/irq.h>
> >  #include <dt-bindings/interrupt-controller/arm-gic.h>
> >  #include <dt-bindings/reset/mt2701-resets.h>
> > +#include <dt-bindings/memory/mt2701-larb-port.h>
> >  #include "skeleton64.dtsi"
> >  #include "mt2701-pinfunc.h"
> >
> > @@ -161,6 +162,16 @@
> >  		clock-names = "system-clk", "rtc-clk";
> >  	};
> >
> > +	smi_common: smi@1000c000 {
> > +		compatible = "mediatek,mt2701-smi-common";
> > +		reg = <0 0x1000c000 0 0x1000>;
> > +		clocks = <&infracfg CLK_INFRA_SMI>,
> > +			 <&mmsys CLK_MM_SMI_COMMON>,
> > +			 <&infracfg CLK_INFRA_SMI>;
> > +		clock-names = "apb", "smi", "async";
> > +		power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
> > +	};
> > +
> >  	sysirq: interrupt-controller@10200100 {
> >  		compatible = "mediatek,mt2701-sysirq",
> >  			     "mediatek,mt6577-sysirq";
> > @@ -170,6 +181,16 @@
> >  		reg = <0 0x10200100 0 0x1c>;
> >  	};
> >
> > +	iommu: mmsys_iommu@10205000 {
> > +		compatible = "mediatek,mt2701-m4u";
> > +		reg = <0 0x10205000 0 0x1000>;
> > +		interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_LOW>;
> > +		clocks = <&infracfg CLK_INFRA_M4U>;
> > +		clock-names = "bclk";
> > +		mediatek,larbs = <&larb0 &larb1 &larb2>;
> > +		#iommu-cells = <1>;
> > +	};
> > +
> >  	apmixedsys: syscon@10209000 {
> >  		compatible = "mediatek,mt2701-apmixedsys", "syscon";
> >  		reg = <0 0x10209000 0 0x1000>;
> > @@ -272,18 +293,51 @@
> >  		#clock-cells = <1>;
> >  	};
> >
> > +	larb0: larb@14010000 {
> > +		compatible = "mediatek,mt2701-smi-larb";
> > +		reg = <0 0x14010000 0 0x1000>;
> > +		mediatek,smi = <&smi_common>;
> > +		mediatek,larbidx = <0>;
> 
> Did I miss something? 'mediatek,larbidx' does not sound familiar to me.
> 

Hi, Mathias,
	It's my mistake, we found a bug need this to fix in smi driver,
but I mix those patches together and make it un-clear.

	I will send new patch serial to add the 'mediatek,larbidx' later since
you have applied the last one.

thanks very much.

> Regards,
> Matthias
> 
> > +		clocks = <&mmsys CLK_MM_SMI_LARB0>,
> > +			 <&mmsys CLK_MM_SMI_LARB0>;
> > +		clock-names = "apb", "smi";
> > +		power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
> > +	};
> > +
> >  	imgsys: syscon@15000000 {
> >  		compatible = "mediatek,mt2701-imgsys", "syscon";
> >  		reg = <0 0x15000000 0 0x1000>;
> >  		#clock-cells = <1>;
> >  	};
> >
> > +	larb2: larb@15001000 {
> > +		compatible = "mediatek,mt2701-smi-larb";
> > +		reg = <0 0x15001000 0 0x1000>;
> > +		mediatek,smi = <&smi_common>;
> > +		mediatek,larbidx = <2>;
> > +		clocks = <&imgsys CLK_IMG_SMI_COMM>,
> > +			 <&imgsys CLK_IMG_SMI_COMM>;
> > +		clock-names = "apb", "smi";
> > +		power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
> > +	};
> > +
> >  	vdecsys: syscon@16000000 {
> >  		compatible = "mediatek,mt2701-vdecsys", "syscon";
> >  		reg = <0 0x16000000 0 0x1000>;
> >  		#clock-cells = <1>;
> >  	};
> >
> > +	larb1: larb@16010000 {
> > +		compatible = "mediatek,mt2701-smi-larb";
> > +		reg = <0 0x16010000 0 0x1000>;
> > +		mediatek,smi = <&smi_common>;
> > +		mediatek,larbidx = <1>;
> > +		clocks = <&vdecsys CLK_VDEC_CKGEN>,
> > +			 <&vdecsys CLK_VDEC_LARB>;
> > +		clock-names = "apb", "smi";
> > +		power-domains = <&scpsys MT2701_POWER_DOMAIN_VDEC>;
> > +	};
> > +
> >  	hifsys: syscon@1a000000 {
> >  		compatible = "mediatek,mt2701-hifsys", "syscon";
> >  		reg = <0 0x1a000000 0 0x1000>;
> >

^ permalink raw reply

* Re: [PATCH v4 5/5] ARM: dts: mt2701: add iommu/smi dtsi node for mt2701
From: Honghui Zhang @ 2017-01-16  2:48 UTC (permalink / raw)
  To: Matthias Brugger
  Cc: joro-zLv9SwRftAIdnm+yROfE0A, treding-DDmLM1+adcrQT0dZR+AlfA,
	mark.rutland-5wv7dgnIgG8, robh-DgEjT+Ai2ygdnm+yROfE0A,
	robin.murphy-5wv7dgnIgG8, p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
	devicetree-u79uwXL29TY76Z2rM5mHXA, pebolle-IWqWACnzNjzz+pZb47iToQ,
	kendrick.hsu-NuS5LvNUpcJWk0Htik3J/w, arnd-r2nGTMty4D4,
	srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
	catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, tfiga-hpIqsD4AKlfQT0dZR+AlfA,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A, djkurtz-hpIqsD4AKlfQT0dZR+AlfA,
	kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	l.stach-bIcnvbaLZ9MEGnE8C9+IrQ,
	yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w,
	eddie.huang-NuS5LvNUpcJWk0Htik3J/w,
	youlin.pei-NuS5LvNUpcJWk0Htik3J/w, erin.lo-NuS5LvNUpcJWk0Htik3J/w
In-Reply-To: <5a45da57-9262-b1ff-1c6a-c5c211c1bfd4-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On Fri, 2017-01-13 at 15:54 +0100, Matthias Brugger wrote:
> 
> On 04/07/16 10:00, Matthias Brugger wrote:
> >
> >
> > On 04/07/16 03:32, Honghui Zhang wrote:
> >> On Sun, 2016-07-03 at 21:12 +0200, Matthias Brugger wrote:
> >>>
> >>> On 07/03/2016 08:24 AM, Matthias Brugger wrote:
> >>>>
> >>>>
> >>>> On 06/08/2016 11:51 AM, honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
> >>>>> From: Honghui Zhang <honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> >>>>>
> >>>>> Add the dtsi node of iommu and smi for mt2701.
> >>>>>
> >>>>> Signed-off-by: Honghui Zhang <honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> >>>>> ---
> >>>>>   arch/arm/boot/dts/mt2701.dtsi | 51
> >>>>> +++++++++++++++++++++++++++++++++++++++++++
> >>>>>   1 file changed, 51 insertions(+)
> >>>>>
> >>>>
> >>>> Applied,
> >>>
> >>> Please resend the patch including the infracfg and mmsys node.
> >>>
> >>
> >> Hi, Matthias,
> >>
> >> Please hold this one.
> >> This one is based on CCF "arm: dts: mt2701: Add clock controller device
> >> nodes"[1] and power domain patch "Mediatek MT2701 SCPSYS power domain
> >> support v7"[2],
> >> But these two patchset are still being reviewed now.
> >>
> >> Do you think it's better that I send this one later after ccf and power
> >> domain patch got merged? I will send this patch later if it's OK with
> >> you.
> >>
> >
> > Sounds good.
> 
> Applied now to v4.10-next/dts32
> 
> Thanks.
> 

Thanks.

> >
> > Thanks a lot,
> > Matthias
> >
> >> Thanks.
> >> [1] https://patchwork.kernel.org/patch/9109081
> >> [2]
> >> http://lists.infradead.org/pipermail/linux-mediatek/2016-May/005429.html
> >>


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v11 02/12] drm/mediatek: add helpers for coverting from the generic components
From: CK Hu @ 2017-01-16  1:09 UTC (permalink / raw)
  To: YT Shen
  Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Philipp Zabel,
	David Airlie, Rob Herring, Mark Rutland, Matthias Brugger,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
	yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w,
	emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w,
	thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, Daniel Kurtz
In-Reply-To: <1484117473-46644-3-git-send-email-yt.shen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>

On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> define helpers for converting from 'mtk_ddp_comp' to 'mtk_disp_ovl'
> define helpers for converting from 'mtk_ddp_comp' to 'mtk_disp_rdma'
> 
> Signed-off-by: YT Shen <yt.shen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>

Acked-by CK Hu <ck.hu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>

> ---
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c  | 15 +++++++++------
>  drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 15 +++++++++------
>  2 files changed, 18 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index c703102..ce2759f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -57,6 +57,11 @@ struct mtk_disp_ovl {
>  	struct drm_crtc			*crtc;
>  };
>  
> +static inline struct mtk_disp_ovl *comp_to_ovl(struct mtk_ddp_comp *comp)
> +{
> +	return container_of(comp, struct mtk_disp_ovl, ddp_comp);
> +}
> +
>  static irqreturn_t mtk_disp_ovl_irq_handler(int irq, void *dev_id)
>  {
>  	struct mtk_disp_ovl *priv = dev_id;
> @@ -76,20 +81,18 @@ static irqreturn_t mtk_disp_ovl_irq_handler(int irq, void *dev_id)
>  static void mtk_ovl_enable_vblank(struct mtk_ddp_comp *comp,
>  				  struct drm_crtc *crtc)
>  {
> -	struct mtk_disp_ovl *priv = container_of(comp, struct mtk_disp_ovl,
> -						 ddp_comp);
> +	struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
>  
> -	priv->crtc = crtc;
> +	ovl->crtc = crtc;
>  	writel(0x0, comp->regs + DISP_REG_OVL_INTSTA);
>  	writel_relaxed(OVL_FME_CPL_INT, comp->regs + DISP_REG_OVL_INTEN);
>  }
>  
>  static void mtk_ovl_disable_vblank(struct mtk_ddp_comp *comp)
>  {
> -	struct mtk_disp_ovl *priv = container_of(comp, struct mtk_disp_ovl,
> -						 ddp_comp);
> +	struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
>  
> -	priv->crtc = NULL;
> +	ovl->crtc = NULL;
>  	writel_relaxed(0x0, comp->regs + DISP_REG_OVL_INTEN);
>  }
>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index 0df05f9..21eff6f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -49,6 +49,11 @@ struct mtk_disp_rdma {
>  	struct drm_crtc			*crtc;
>  };
>  
> +static inline struct mtk_disp_rdma *comp_to_rdma(struct mtk_ddp_comp *comp)
> +{
> +	return container_of(comp, struct mtk_disp_rdma, ddp_comp);
> +}
> +
>  static irqreturn_t mtk_disp_rdma_irq_handler(int irq, void *dev_id)
>  {
>  	struct mtk_disp_rdma *priv = dev_id;
> @@ -77,20 +82,18 @@ static void rdma_update_bits(struct mtk_ddp_comp *comp, unsigned int reg,
>  static void mtk_rdma_enable_vblank(struct mtk_ddp_comp *comp,
>  				   struct drm_crtc *crtc)
>  {
> -	struct mtk_disp_rdma *priv = container_of(comp, struct mtk_disp_rdma,
> -						  ddp_comp);
> +	struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
>  
> -	priv->crtc = crtc;
> +	rdma->crtc = crtc;
>  	rdma_update_bits(comp, DISP_REG_RDMA_INT_ENABLE, RDMA_FRAME_END_INT,
>  			 RDMA_FRAME_END_INT);
>  }
>  
>  static void mtk_rdma_disable_vblank(struct mtk_ddp_comp *comp)
>  {
> -	struct mtk_disp_rdma *priv = container_of(comp, struct mtk_disp_rdma,
> -						  ddp_comp);
> +	struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
>  
> -	priv->crtc = NULL;
> +	rdma->crtc = NULL;
>  	rdma_update_bits(comp, DISP_REG_RDMA_INT_ENABLE, RDMA_FRAME_END_INT, 0);
>  }
>  


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox