Re: [PATCH] mtd: spi-nor: add hisilicon spi-nor flash controller driver

[kbuild test robot]

Hi Jiancheng,

[auto build test WARNING on v4.4-rc7]
[cannot apply to next-20151223]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Jiancheng-Xue/mtd-spi-nor-add-hisilicon-spi-nor-flash-controller-driver/20151230-104117
config: arm64-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All warnings (new ones prefixed by >>):

   drivers/mtd/spi-nor/hisi-sfc.c: In function 'hisi_spi_nor_send_cmd':
>> drivers/mtd/spi-nor/hisi-sfc.c:239:9: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
  reg = (u32)buf;
^
   drivers/mtd/spi-nor/hisi-sfc.c: In function 'hisi_spi_nor_erase':
>> drivers/mtd/spi-nor/hisi-sfc.c:376:6: warning: cast to pointer from integer 
>> of different size [-Wint-to-pointer-cast]
 (u8 *)(u32)offs, 0);
 ^

vim +239 drivers/mtd/spi-nor/hisi-sfc.c

   233  hisi_spi_nor_cmd_prepare(host, cmd, buf, &op_cfg);
   234  
   235  reg = FMC_CMD_CMD1(cmd);
   236  writel(reg, host->regbase + FMC_CMD);
   237  
   238  if (op_cfg & FMC_OP_ADDR_EN) {
 > 239  reg = (u32)buf;
   240  writel(reg, host->regbase + FMC_ADDRL);
   241  }
   242  
   243  reg = OP_CFG_FM_CS(priv->chipselect);
   244  if (op_cfg & FMC_OP_ADDR_EN)
   245  reg |= OP_CFG_ADDR_NUM(nor->addr_width);
   246  writel(reg, host->regbase + FMC_OP_CFG);
   247  
   248  reg = FMC_DATA_NUM_CNT(len);
   249  writel(reg, host->regbase + FMC_DATA_NUM);
   250  
   251  writel(0xff, host->regbase + FMC_INT_CLR);
   252  reg = op_cfg | FMC_OP_REG_OP_START;
   253  writel(reg, host->regbase + FMC_OP);
   254  wait_op_finish(host);
   255  
   256  return 0;
   257  }
   258  
   259  static int hisi_spi_nor_read_reg(struct spi_nor *nor, u8 opcode, u8 
*buf,
   260  int len)
   261  {
   262  struct hifmc_priv *priv = nor->priv;
   263  struct hifmc_host *host = priv->host;
   264  int ret;
   265  
   266  ret = hisi_spi_nor_send_cmd(nor, opcode, buf, len);
   267  if (ret)
   268  return ret;
   269  
   270  memcpy(buf, host->iobase, len);
   271  
   272  return ret;
   273  }
   274  
   275  static int hisi_spi_nor_write_reg(struct spi_nor *nor, u8 opcode,
   276  u8 *buf, int len)
   277  {
   278  struct hifmc_priv *priv = nor->priv;
   279  struct hifmc_host *host = priv->host;
   280  
   281  if (len)
   282  memcpy(host->iobase, buf, len);
   283  
   284  return hisi_spi_nor_send_cmd(nor, opcode, buf, len);
   285  }
   286  
   287  static void hisi_spi_nor_dma_transfer(struct spi_nor *nor, u32 
start_off,
   288  u32 dma_buf, u32 len, u8 op_type)
   289  {
   290  struct hifmc_priv *priv = nor->priv;
   291  struct hifmc_host *host = priv->host;
   292  u8 if_type = 0, dummy = 0;
   293  u8 w_cmd = 0, r_cmd = 0;
   294  u32 reg;
   295  
   296  writel(start_off, host->regbase + FMC_ADDRL);
   297  
   298  if (op_type == FMC_OP_READ) {
   299  if_type = get_if_type(nor->flash_read);
   300  dummy = nor->read_dummy >> 3;
   301  r_cmd = nor->read_opcode;
   302  } else
   303  w_cmd = nor->program_opcode;
   304  
   305  reg = OP_CFG_FM_CS(priv->chipselect)
   306  | OP_CFG_MEM_IF_TYPE(if_type)
   307  | OP_CFG_ADDR_NUM(nor->addr_width)
   308  | OP_CFG_DUMMY_NUM(dummy);
   309  writel(reg, host->regbase + FMC_OP_CFG);
   310  
   311  reg = FMC_DMA_LEN_SET(len);
   312  writel(reg, host->regbase + FMC_DMA_LEN);
   313  writel(dma_buf, host->regbase + FMC_DMA_SADDR_D0);
   314  
   315  reg = OP_CTRL_RD_OPCODE(r_cmd)
   316  | OP_CTRL_WR_OPCODE(w_cmd)
   317  | OP_CTRL_RW_OP(op_type)
   318  | OP_CTRL_DMA_OP_READY;
   319  writel(0xff, host->regbase + FMC_INT_CLR);
   320  writel(reg, host->regbase + FMC_OP_DMA);
   321  wait_op_finish(host);
   322  }
   323  
   324  static int hisi_spi_nor_read(struct spi_nor *nor, loff_t from, size_t 
len,
   325  size_t *retlen, u_char *read_buf)
   326  {
   327  struct hifmc_priv *priv = nor->priv;
   328  struct hifmc_host *host = priv->host;
   329  unsigned char *ptr = read_buf;
   330  int num;
   331  
   

[PATCH 3/4] soc: mediatek: Add MT2701 power dt-bindings

[James Liao]

From: Shunli Wang 

Add power dt-bindings for MT2701.

Signed-off-by: Shunli Wang 
Signed-off-by: James Liao 
---
 include/dt-bindings/power/mt2701-power.h | 27 +++
 1 file changed, 27 insertions(+)
 create mode 100644 include/dt-bindings/power/mt2701-power.h

diff --git a/include/dt-bindings/power/mt2701-power.h 
b/include/dt-bindings/power/mt2701-power.h
new file mode 100644
index 000..64cc826
--- /dev/null
+++ b/include/dt-bindings/power/mt2701-power.h
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2015 MediaTek Inc.
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _DT_BINDINGS_POWER_MT2701_POWER_H
+#define _DT_BINDINGS_POWER_MT2701_POWER_H
+
+#define MT2701_POWER_DOMAIN_CONN   0
+#define MT2701_POWER_DOMAIN_DISP   1
+#define MT2701_POWER_DOMAIN_MFG2
+#define MT2701_POWER_DOMAIN_VDEC   3
+#define MT2701_POWER_DOMAIN_ISP4
+#define MT2701_POWER_DOMAIN_BDP5
+#define MT2701_POWER_DOMAIN_ETH6
+#define MT2701_POWER_DOMAIN_HIF7
+#define MT2701_POWER_DOMAIN_IFR_MSC8
+
+#endif /* _DT_BINDINGS_POWER_MT2701_POWER_H */
-- 
1.9.1

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

[PATCH 0/4] Mediatek MT2701 SCPSYS power domain support

[James Liao]

This patchset is based on 4.4-rc7, add scpsys power domain support for
Mediatek MT2701/MT7623.

This patchset also separate MT8173 scpsys driver into common part
(mtk-scpsys.c) and platform part (mtk-scpsys-mt8173.c), so that MT2701
scpsys driver can share most implementation with MT8173.

James Liao (2):
  soc: mediatek: Separate scpsys driver common code
  soc: mediatek: Init MT8173 scpsys driver earlier

Shunli Wang (2):
  soc: mediatek: Add MT2701 power dt-bindings
  soc: mediatek: Add MT2701/MT7623 scpsys driver

 drivers/soc/mediatek/Kconfig |  24 ++-
 drivers/soc/mediatek/Makefile|   2 +
 drivers/soc/mediatek/mtk-scpsys-mt2701.c | 161 +
 drivers/soc/mediatek/mtk-scpsys-mt8173.c | 190 +++
 drivers/soc/mediatek/mtk-scpsys.c| 301 ---
 drivers/soc/mediatek/mtk-scpsys.h|  54 ++
 include/dt-bindings/power/mt2701-power.h |  27 +++
 7 files changed, 531 insertions(+), 228 deletions(-)
 create mode 100644 drivers/soc/mediatek/mtk-scpsys-mt2701.c
 create mode 100644 drivers/soc/mediatek/mtk-scpsys-mt8173.c
 create mode 100644 drivers/soc/mediatek/mtk-scpsys.h
 create mode 100644 include/dt-bindings/power/mt2701-power.h

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

[PATCH 1/4] soc: mediatek: Separate scpsys driver common code

[James Liao]

Separate scpsys driver common code to mtk-scpsys.c, and move MT8173
platform code to mtk-scpsys-mt8173.c.

Signed-off-by: James Liao 
---
 drivers/soc/mediatek/Kconfig |  13 +-
 drivers/soc/mediatek/Makefile|   1 +
 drivers/soc/mediatek/mtk-scpsys-mt8173.c | 179 ++
 drivers/soc/mediatek/mtk-scpsys.c| 301 ---
 drivers/soc/mediatek/mtk-scpsys.h|  54 ++
 5 files changed, 320 insertions(+), 228 deletions(-)
 create mode 100644 drivers/soc/mediatek/mtk-scpsys-mt8173.c
 create mode 100644 drivers/soc/mediatek/mtk-scpsys.h

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index 0a4ea80..eca6fb7 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -22,11 +22,20 @@ config MTK_PMIC_WRAP
 
 config MTK_SCPSYS
bool "MediaTek SCPSYS Support"
-   depends on ARCH_MEDIATEK || COMPILE_TEST
-   default ARM64 && ARCH_MEDIATEK
select REGMAP
select MTK_INFRACFG
select PM_GENERIC_DOMAINS if PM
help
  Say yes here to add support for the MediaTek SCPSYS power domain
  driver.
+
+config MTK_SCPSYS_MT8173
+   bool "MediaTek MT8173 SCPSYS Support"
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   select MTK_SCPSYS
+   default ARCH_MEDIATEK
+   help
+ Say yes here to add support for the MT8173 SCPSYS power domain
+ driver.
+ The System Control Processor System (SCPSYS) has several power
+ management related tasks in the system.
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 12998b0..3b22baa 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
 obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
 obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
+obj-$(CONFIG_MTK_SCPSYS_MT8173) += mtk-scpsys-mt8173.o
diff --git a/drivers/soc/mediatek/mtk-scpsys-mt8173.c 
b/drivers/soc/mediatek/mtk-scpsys-mt8173.c
new file mode 100644
index 000..3c7b569
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-scpsys-mt8173.c
@@ -0,0 +1,179 @@
+/*
+ * Copyright (c) 2015 Pengutronix, Sascha Hauer 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mtk-scpsys.h"
+
+#define SPM_VDE_PWR_CON0x0210
+#define SPM_MFG_PWR_CON0x0214
+#define SPM_VEN_PWR_CON0x0230
+#define SPM_ISP_PWR_CON0x0238
+#define SPM_DIS_PWR_CON0x023c
+#define SPM_VEN2_PWR_CON   0x0298
+#define SPM_AUDIO_PWR_CON  0x029c
+#define SPM_MFG_2D_PWR_CON 0x02c0
+#define SPM_MFG_ASYNC_PWR_CON  0x02c4
+#define SPM_USB_PWR_CON0x02cc
+
+#define PWR_STATUS_DISPBIT(3)
+#define PWR_STATUS_MFG BIT(4)
+#define PWR_STATUS_ISP BIT(5)
+#define PWR_STATUS_VDECBIT(7)
+#define PWR_STATUS_VENC_LT BIT(20)
+#define PWR_STATUS_VENCBIT(21)
+#define PWR_STATUS_MFG_2D  BIT(22)
+#define PWR_STATUS_MFG_ASYNC   BIT(23)
+#define PWR_STATUS_AUDIO   BIT(24)
+#define PWR_STATUS_USB BIT(25)
+
+static const struct scp_domain_data scp_domain_data[] __initconst = {
+   [MT8173_POWER_DOMAIN_VDEC] = {
+   .name = "vdec",
+   .sta_mask = PWR_STATUS_VDEC,
+   .ctl_offs = SPM_VDE_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .clk_id = {CLK_MM},
+   },
+   [MT8173_POWER_DOMAIN_VENC] = {
+   .name = "venc",
+   .sta_mask = PWR_STATUS_VENC,
+   .ctl_offs = SPM_VEN_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(15, 12),
+   .clk_id = {CLK_MM, CLK_VENC},
+   },
+   [MT8173_POWER_DOMAIN_ISP] = {
+   .name = "isp",
+   .sta_mask = PWR_STATUS_ISP,
+   .ctl_offs = SPM_ISP_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(13, 12),
+   .clk_id = {CLK_MM},
+   },
+   [MT8173_POWER_DOMAIN_MM] = {
+   .name = "mm",
+   .sta_mask = PWR_STATUS_DISP,
+   .ctl_offs = SPM_DIS_PWR_CON,
+   .sram_pdn_

[PATCH 4/4] soc: mediatek: Add MT2701/MT7623 scpsys driver

[James Liao]

From: Shunli Wang 

Add scpsys driver for MT2701 and MT7623.

Signed-off-by: Shunli Wang 
Signed-off-by: James Liao 
---
 drivers/soc/mediatek/Kconfig |  11 +++
 drivers/soc/mediatek/Makefile|   1 +
 drivers/soc/mediatek/mtk-scpsys-mt2701.c | 161 +++
 3 files changed, 173 insertions(+)
 create mode 100644 drivers/soc/mediatek/mtk-scpsys-mt2701.c

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index eca6fb7..92cf838 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -39,3 +39,14 @@ config MTK_SCPSYS_MT8173
  driver.
  The System Control Processor System (SCPSYS) has several power
  management related tasks in the system.
+
+config MTK_SCPSYS_MT2701
+   bool "SCPSYS Support MediaTek MT2701 and MT7623"
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   select MTK_SCPSYS
+   default ARCH_MEDIATEK
+   help
+ Say yes here to add support for the MT2701/MT7623 SCPSYS power
+ domain driver.
+ The System Control Processor System (SCPSYS) has several power
+ management related tasks in the system.
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 3b22baa..822986d 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
 obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
 obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
 obj-$(CONFIG_MTK_SCPSYS_MT8173) += mtk-scpsys-mt8173.o
+obj-$(CONFIG_MTK_SCPSYS_MT2701) += mtk-scpsys-mt2701.o
diff --git a/drivers/soc/mediatek/mtk-scpsys-mt2701.c 
b/drivers/soc/mediatek/mtk-scpsys-mt2701.c
new file mode 100644
index 000..339d5b8
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-scpsys-mt2701.c
@@ -0,0 +1,161 @@
+/*
+ * Copyright (c) 2015 Mediatek, Shunli Wang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mtk-scpsys.h"
+
+#define SPM_VDE_PWR_CON0x0210
+#define SPM_MFG_PWR_CON0x0214
+#define SPM_ISP_PWR_CON0x0238
+#define SPM_DIS_PWR_CON0x023C
+#define SPM_CONN_PWR_CON   0x0280
+#define SPM_BDP_PWR_CON0x029C
+#define SPM_ETH_PWR_CON0x02A0
+#define SPM_HIF_PWR_CON0x02A4
+#define SPM_IFR_MSC_PWR_CON0x02A8
+#define SPM_PWR_STATUS 0x060c
+#define SPM_PWR_STATUS_2ND 0x0610
+
+#define CONN_PWR_STA_MASK  BIT(1)
+#define DIS_PWR_STA_MASK   BIT(3)
+#define MFG_PWR_STA_MASK   BIT(4)
+#define ISP_PWR_STA_MASK   BIT(5)
+#define VDE_PWR_STA_MASK   BIT(7)
+#define BDP_PWR_STA_MASK   BIT(14)
+#define ETH_PWR_STA_MASK   BIT(15)
+#define HIF_PWR_STA_MASK   BIT(16)
+#define IFR_MSC_PWR_STA_MASK   BIT(17)
+
+#define MT2701_TOP_AXI_PROT_EN_CONN0x0104
+#define MT2701_TOP_AXI_PROT_EN_DISP0x0002
+
+static const struct scp_domain_data scp_domain_data[] = {
+   [MT2701_POWER_DOMAIN_CONN] = {
+   .name = "conn",
+   .sta_mask = CONN_PWR_STA_MASK,
+   .ctl_offs = SPM_CONN_PWR_CON,
+   .bus_prot_mask = MT2701_TOP_AXI_PROT_EN_CONN,
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_DISP] = {
+   .name = "disp",
+   .sta_mask = DIS_PWR_STA_MASK,
+   .ctl_offs = SPM_DIS_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .clk_id = {CLK_MM},
+   .bus_prot_mask = MT2701_TOP_AXI_PROT_EN_DISP,
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_MFG] = {
+   .name = "mfg",
+   .sta_mask = MFG_PWR_STA_MASK,
+   .ctl_offs = SPM_MFG_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_VDEC] = {
+   .name = "vdec",
+   .sta_mask = VDE_PWR_STA_MASK,
+   .ctl_offs = SPM_VDE_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .clk_id = {CLK_MM},
+   .active_wakeup = true,
+   },
+   [MT2701_POWER_DOMAIN_ISP] = {
+   .name = "isp",
+   .sta_mask = IS

[PATCH 2/4] soc: mediatek: Init MT8173 scpsys driver earlier

[James Liao]

Some power domain comsumers may init before module_init.
So the power domain provider (scpsys) need to be initialized
earlier too.

Signed-off-by: James Liao 
---
 drivers/soc/mediatek/mtk-scpsys-mt8173.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mtk-scpsys-mt8173.c 
b/drivers/soc/mediatek/mtk-scpsys-mt8173.c
index 3c7b569..827e696 100644
--- a/drivers/soc/mediatek/mtk-scpsys-mt8173.c
+++ b/drivers/soc/mediatek/mtk-scpsys-mt8173.c
@@ -176,4 +176,15 @@ static struct platform_driver scpsys_drv = {
},
 };
 
-module_platform_driver_probe(scpsys_drv, scpsys_probe);
+static int __init scpsys_drv_init(void)
+{
+   return platform_driver_probe(&scpsys_drv, scpsys_probe);
+}
+
+static void __exit scpsys_drv_exit(void)
+{
+   platform_driver_unregister(&scpsys_drv);
+}
+
+subsys_initcall(scpsys_drv_init);
+module_exit(scpsys_drv_exit);
-- 
1.9.1

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

[PATCH 4/5] reset: mediatek: mt2701 reset controller dt-binding file

[James Liao]

From: Shunli Wang 

Dt-binding file about reset controller is used to provide
kinds of definition, which is referenced by dts file and
IC-specified reset controller driver code.

Signed-off-by: Shunli Wang 
---
 .../dt-bindings/reset-controller/mt2701-resets.h   | 74 ++
 1 file changed, 74 insertions(+)
 create mode 100644 include/dt-bindings/reset-controller/mt2701-resets.h

diff --git a/include/dt-bindings/reset-controller/mt2701-resets.h 
b/include/dt-bindings/reset-controller/mt2701-resets.h
new file mode 100644
index 000..00efeb0
--- /dev/null
+++ b/include/dt-bindings/reset-controller/mt2701-resets.h
@@ -0,0 +1,74 @@
+/*
+ * Copyright (c) 2015 MediaTek, Shunli Wang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _DT_BINDINGS_RESET_CONTROLLER_MT2701
+#define _DT_BINDINGS_RESET_CONTROLLER_MT2701
+
+/* INFRACFG resets */
+#define MT2701_INFRA_EMI_REG_RST   0
+#define MT2701_INFRA_DRAMC0_A0_RST 1
+#define MT2701_INFRA_FHCTL_RST 2
+#define MT2701_INFRA_APCIRQ_EINT_RST   3
+#define MT2701_INFRA_APXGPT_RST4
+#define MT2701_INFRA_SCPSYS_RST5
+#define MT2701_INFRA_KP_RST6
+#define MT2701_INFRA_PMIC_WRAP_RST 7
+#define MT2701_INFRA_MIPI_RST  8
+#define MT2701_INFRA_IRRX_RST  9
+#define MT2701_INFRA_CEC_RST   10
+#define MT2701_INFRA_EMI_RST   32
+#define MT2701_INFRA_DRAMC0_RST34
+#define MT2701_INFRA_TRNG_RST  37
+#define MT2701_INFRA_SYSIRQ_RST38
+
+/*  PERICFG resets */
+#define MT2701_PERI_UART0_SW_RST   0
+#define MT2701_PERI_UART1_SW_RST   1
+#define MT2701_PERI_UART2_SW_RST   2
+#define MT2701_PERI_UART3_SW_RST   3
+#define MT2701_PERI_GCPU_SW_RST5
+#define MT2701_PERI_BTIF_SW_RST6
+#define MT2701_PERI_PWM_SW_RST 8
+#define MT2701_PERI_AUXADC_SW_RST  10
+#define MT2701_PERI_DMA_SW_RST 11
+#define MT2701_PERI_NFI_SW_RST 14
+#define MT2701_PERI_NLI_SW_RST 15
+#define MT2701_PERI_THERM_SW_RST   16
+#define MT2701_PERI_MSDC2_SW_RST   17
+#define MT2701_PERI_MSDC0_SW_RST   19
+#define MT2701_PERI_MSDC1_SW_RST   20
+#define MT2701_PERI_I2C0_SW_RST22
+#define MT2701_PERI_I2C1_SW_RST23
+#define MT2701_PERI_I2C2_SW_RST24
+#define MT2701_PERI_I2C3_SW_RST25
+#define MT2701_PERI_USB_SW_RST 28
+#define MT2701_PERI_ETH_SW_RST 29
+#define MT2701_PERI_SPI0_SW_RST33
+
+/* TOPRGU resets */
+#define MT2701_TOPRGU_INFRA_RST0
+#define MT2701_TOPRGU_MM_RST   1
+#define MT2701_TOPRGU_MFG_RST  2
+#define MT2701_TOPRGU_ETHDMA_RST   3
+#define MT2701_TOPRGU_VDEC_RST 4
+#define MT2701_TOPRGU_VENC_IMG_RST 5
+#define MT2701_TOPRGU_DDRPHY_RST   6
+#define MT2701_TOPRGU_MD_RST   7
+#define MT2701_TOPRGU_INFRA_AO_RST 8
+#define MT2701_TOPRGU_CONN_RST 9
+#define MT2701_TOPRGU_APMIXED_RST  10
+#define MT2701_TOPRGU_HIFSYS_RST   11
+#define MT2701_TOPRGU_CONN_MCU_RST 12
+#define MT2701_TOPRGU_BDP_DISP_RST 13
+
+#endif  /* _DT_BINDINGS_RESET_CONTROLLER_MT2701 */
-- 
1.9.1

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

[PATCH 3/5] clk: mediatek: Add MT2701 clock support

[James Liao]

From: Shunli Wang 

Add MT2701 clock support, include topckgen, apmixedsys,
infracfg, pericfg and subsystem clocks.

Signed-off-by: Shunli Wang 
Signed-off-by: James Liao 
---
 drivers/clk/mediatek/Kconfig  |8 +
 drivers/clk/mediatek/Makefile |1 +
 drivers/clk/mediatek/clk-gate.c   |   56 ++
 drivers/clk/mediatek/clk-gate.h   |2 +
 drivers/clk/mediatek/clk-mt2701.c | 1211 +
 drivers/clk/mediatek/clk-mtk.c|   25 +
 drivers/clk/mediatek/clk-mtk.h|   35 +-
 7 files changed, 1335 insertions(+), 3 deletions(-)
 create mode 100644 drivers/clk/mediatek/clk-mt2701.c

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index dc224e6..6c7cdc0 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -6,6 +6,14 @@ config COMMON_CLK_MEDIATEK
---help---
  Mediatek SoCs' clock support.
 
+config COMMON_CLK_MT2701
+   bool "Clock driver for Mediatek MT2701 and MT7623"
+   depends on COMMON_CLK
+   select COMMON_CLK_MEDIATEK
+   default ARCH_MEDIATEK
+   ---help---
+ This driver supports Mediatek MT2701 and MT7623 clocks.
+
 config COMMON_CLK_MT8135
bool "Clock driver for Mediatek MT8135"
depends on COMMON_CLK
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 32e7222..5b2b91b 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_COMMON_CLK_MEDIATEK) += clk-mtk.o clk-pll.o clk-gate.o 
clk-apmixed.o
 obj-$(CONFIG_RESET_CONTROLLER) += reset.o
+obj-$(CONFIG_COMMON_CLK_MT2701) += clk-mt2701.o
 obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135.o
 obj-$(CONFIG_COMMON_CLK_MT8173) += clk-mt8173.o
diff --git a/drivers/clk/mediatek/clk-gate.c b/drivers/clk/mediatek/clk-gate.c
index 576bdb7..38badb4 100644
--- a/drivers/clk/mediatek/clk-gate.c
+++ b/drivers/clk/mediatek/clk-gate.c
@@ -61,6 +61,26 @@ static void mtk_cg_clr_bit(struct clk_hw *hw)
regmap_write(cg->regmap, cg->clr_ofs, BIT(cg->bit));
 }
 
+static void mtk_cg_set_bit_no_setclr(struct clk_hw *hw)
+{
+   struct mtk_clk_gate *cg = to_clk_gate(hw);
+   u32 val;
+
+   regmap_read(cg->regmap, cg->sta_ofs, &val);
+   val |= BIT(cg->bit);
+   regmap_write(cg->regmap, cg->sta_ofs, val);
+}
+
+static void mtk_cg_clr_bit_no_setclr(struct clk_hw *hw)
+{
+   struct mtk_clk_gate *cg = to_clk_gate(hw);
+   u32 val;
+
+   regmap_read(cg->regmap, cg->sta_ofs, &val);
+   val &= ~(BIT(cg->bit));
+   regmap_write(cg->regmap, cg->sta_ofs, val);
+}
+
 static int mtk_cg_enable(struct clk_hw *hw)
 {
mtk_cg_clr_bit(hw);
@@ -85,6 +105,30 @@ static void mtk_cg_disable_inv(struct clk_hw *hw)
mtk_cg_clr_bit(hw);
 }
 
+static int mtk_cg_enable_no_setclr(struct clk_hw *hw)
+{
+   mtk_cg_clr_bit_no_setclr(hw);
+
+   return 0;
+}
+
+static void mtk_cg_disable_no_setclr(struct clk_hw *hw)
+{
+   mtk_cg_set_bit_no_setclr(hw);
+}
+
+static int mtk_cg_enable_inv_no_setclr(struct clk_hw *hw)
+{
+   mtk_cg_set_bit_no_setclr(hw);
+
+   return 0;
+}
+
+static void mtk_cg_disable_inv_no_setclr(struct clk_hw *hw)
+{
+   mtk_cg_clr_bit_no_setclr(hw);
+}
+
 const struct clk_ops mtk_clk_gate_ops_setclr = {
.is_enabled = mtk_cg_bit_is_cleared,
.enable = mtk_cg_enable,
@@ -97,6 +141,18 @@ const struct clk_ops mtk_clk_gate_ops_setclr_inv = {
.disable= mtk_cg_disable_inv,
 };
 
+const struct clk_ops mtk_clk_gate_ops_no_setclr = {
+   .is_enabled = mtk_cg_bit_is_cleared,
+   .enable = mtk_cg_enable_no_setclr,
+   .disable= mtk_cg_disable_no_setclr,
+};
+
+const struct clk_ops mtk_clk_gate_ops_no_setclr_inv = {
+   .is_enabled = mtk_cg_bit_is_set,
+   .enable = mtk_cg_enable_inv_no_setclr,
+   .disable= mtk_cg_disable_inv_no_setclr,
+};
+
 struct clk * __init mtk_clk_register_gate(
const char *name,
const char *parent_name,
diff --git a/drivers/clk/mediatek/clk-gate.h b/drivers/clk/mediatek/clk-gate.h
index 11e25c9..7f7ef34 100644
--- a/drivers/clk/mediatek/clk-gate.h
+++ b/drivers/clk/mediatek/clk-gate.h
@@ -36,6 +36,8 @@ static inline struct mtk_clk_gate *to_clk_gate(struct clk_hw 
*hw)
 
 extern const struct clk_ops mtk_clk_gate_ops_setclr;
 extern const struct clk_ops mtk_clk_gate_ops_setclr_inv;
+extern const struct clk_ops mtk_clk_gate_ops_no_setclr;
+extern const struct clk_ops mtk_clk_gate_ops_no_setclr_inv;
 
 struct clk *mtk_clk_register_gate(
const char *name,
diff --git a/drivers/clk/mediatek/clk-mt2701.c 
b/drivers/clk/mediatek/clk-mt2701.c
new file mode 100644
index 000..2acc8c3
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt2701.c
@@ -0,0 +1,1211 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: Shunli Wang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the G

[PATCH 5/5] reset: mediatek: mt2701 reset driver

[James Liao]

From: Shunli Wang 

In infrasys and perifsys, there are many reset
control bits for kinds of modules. These bits are
used as actual reset controllers to be registered
into kernel's generic reset controller framework.

Signed-off-by: Shunli Wang 
---
 drivers/clk/mediatek/clk-mt2701.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/clk/mediatek/clk-mt2701.c 
b/drivers/clk/mediatek/clk-mt2701.c
index 2acc8c3..802ab5c 100644
--- a/drivers/clk/mediatek/clk-mt2701.c
+++ b/drivers/clk/mediatek/clk-mt2701.c
@@ -666,6 +666,8 @@ static void __init mtk_infrasys_init(struct device_node 
*node)
if (r)
pr_err("%s(): could not register clock provider: %d\n",
__func__, r);
+
+   mtk_register_reset_controller(node, 2, 0x30);
 }
 CLK_OF_DECLARE(mtk_infrasys, "mediatek,mt2701-infracfg", mtk_infrasys_init);
 
@@ -783,6 +785,8 @@ static void __init mtk_pericfg_init(struct device_node 
*node)
if (r)
pr_err("%s(): could not register clock provider: %d\n",
__func__, r);
+
+   mtk_register_reset_controller(node, 2, 0x0);
 }
 CLK_OF_DECLARE(mtk_pericfg, "mediatek,mt2701-pericfg", mtk_pericfg_init);
 
-- 
1.9.1

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

Re: [PATCH] DT: i2c: Add Freescale MPL3115 to trivial devices list

[Wolfram Sang]

On Tue, Dec 29, 2015 at 12:35:16PM -0600, Rob Herring wrote:
> On Wed, Dec 23, 2015 at 01:59:07PM -0500, Akshay Bhat wrote:
> > This adds devicetree documentation for the bindings of mpl3115 driver.
> > 
> > Signed-off-by: Akshay Bhat 
> > ---
> >  Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 +
> >  1 file changed, 1 insertion(+)
> 
> Acked-by: Rob Herring 
> 
> Who did you want to apply this? Send patches TO that person which I 
> would expect to be Wolfram or me.

I usually take these. Will do again :)



signature.asc
Description: PGP signature

[PATCH 2/5] clk: mediatek: Add dt-bindings for MT2701 clocks

[James Liao]

From: Shunli Wang 

Add MT2701 clock dt-bindings, include topckgen, apmixedsys,
infracfg, pericfg and subsystem clocks.

Signed-off-by: Shunli Wang 
Signed-off-by: James Liao 
---
 include/dt-bindings/clock/mt2701-clk.h | 481 +
 1 file changed, 481 insertions(+)
 create mode 100644 include/dt-bindings/clock/mt2701-clk.h

diff --git a/include/dt-bindings/clock/mt2701-clk.h 
b/include/dt-bindings/clock/mt2701-clk.h
new file mode 100644
index 000..50972d1
--- /dev/null
+++ b/include/dt-bindings/clock/mt2701-clk.h
@@ -0,0 +1,481 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: Shunli Wang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _DT_BINDINGS_CLK_MT2701_H
+#define _DT_BINDINGS_CLK_MT2701_H
+
+/* TOPCKGEN */
+#define CLK_TOP_SYSPLL 1
+#define CLK_TOP_SYSPLL_D2  2
+#define CLK_TOP_SYSPLL_D3  3
+#define CLK_TOP_SYSPLL_D5  4
+#define CLK_TOP_SYSPLL_D7  5
+#define CLK_TOP_SYSPLL1_D2 6
+#define CLK_TOP_SYSPLL1_D4 7
+#define CLK_TOP_SYSPLL1_D8 8
+#define CLK_TOP_SYSPLL1_D169
+#define CLK_TOP_SYSPLL2_D2 10
+#define CLK_TOP_SYSPLL2_D4 11
+#define CLK_TOP_SYSPLL2_D8 12
+#define CLK_TOP_SYSPLL3_D2 13
+#define CLK_TOP_SYSPLL3_D4 14
+#define CLK_TOP_SYSPLL4_D2 15
+#define CLK_TOP_SYSPLL4_D4 16
+#define CLK_TOP_UNIVPLL17
+#define CLK_TOP_UNIVPLL_D2 18
+#define CLK_TOP_UNIVPLL_D3 19
+#define CLK_TOP_UNIVPLL_D5 20
+#define CLK_TOP_UNIVPLL_D7 21
+#define CLK_TOP_UNIVPLL_D2622
+#define CLK_TOP_UNIVPLL_D5223
+#define CLK_TOP_UNIVPLL_D108   24
+#define CLK_TOP_USB_PHY48M 25
+#define CLK_TOP_UNIVPLL1_D226
+#define CLK_TOP_UNIVPLL1_D427
+#define CLK_TOP_UNIVPLL1_D828
+#define CLK_TOP_UNIVPLL2_D229
+#define CLK_TOP_UNIVPLL2_D430
+#define CLK_TOP_UNIVPLL2_D831
+#define CLK_TOP_UNIVPLL2_D16   32
+#define CLK_TOP_UNIVPLL2_D32   33
+#define CLK_TOP_UNIVPLL3_D234
+#define CLK_TOP_UNIVPLL3_D435
+#define CLK_TOP_UNIVPLL3_D836
+#define CLK_TOP_MSDCPLL37
+#define CLK_TOP_MSDCPLL_D2 38
+#define CLK_TOP_MSDCPLL_D4 39
+#define CLK_TOP_MSDCPLL_D8 40
+#define CLK_TOP_MMPLL  41
+#define CLK_TOP_MMPLL_D2   42
+#define CLK_TOP_DMPLL  43
+#define CLK_TOP_DMPLL_D2   44
+#define CLK_TOP_DMPLL_D4   45
+#define CLK_TOP_DMPLL_X2   46
+#define CLK_TOP_TVDPLL 47
+#define CLK_TOP_TVDPLL_D2  48
+#define CLK_TOP_TVDPLL_D4  49
+#define CLK_TOP_TVD2PLL50
+#define CLK_TOP_TVD2PLL_D2 51
+#define CLK_TOP_HADDS2PLL_98M  52
+#define CLK_TOP_HADDS2PLL_294M 53
+#define CLK_TOP_HADDS2_FB  54
+#define CLK_TOP_MIPIPLL_D2 55
+#define CLK_TOP_MIPIPLL_D4 56
+#define CLK_TOP_HDMIPLL57
+#define CLK_TOP_HDMIPLL_D2 58
+#define CLK_TOP_HDMIPLL_D3 59
+#define CLK_TOP_HDMI_SCL_RX60
+#define CLK_TOP_HDMI_0_PIX340M 61
+#define CLK_TOP_HDMI_0_DEEP340M62
+#define CLK_TOP_HDMI_0_PLL340M 63
+#define CLK_TOP_AUD1PLL_98M64
+#define CLK_TOP_AUD2PLL_90M65
+#define CLK_TOP_AUDPLL 66
+#define CLK_TOP_AUDPLL_D4  67
+#define CLK_TOP_AUDPLL_D8  68
+#define CLK_TOP_AUDPLL_D16 69
+#define CLK_TOP_AUDPLL_D24 70
+#define CLK_TOP_ETHPLL_500M71
+#define CLK_TOP_VDECPLL72
+#define CLK_TOP_VENCPLL73
+#define CLK_TOP_MIPIPLL  

[PATCH 1/5] clk: mediatek: Refine the makefile to support multiple clock drivers

[James Liao]

Add a Kconfig to define clock configuration for each SoC, and
modify the Makefile to build drivers that only selected in config.

Signed-off-by: Shunli Wang 
Signed-off-by: James Liao 
---
 drivers/clk/Kconfig   |  1 +
 drivers/clk/mediatek/Kconfig  | 23 +++
 drivers/clk/mediatek/Makefile |  6 +++---
 3 files changed, 27 insertions(+), 3 deletions(-)
 create mode 100644 drivers/clk/mediatek/Kconfig

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index c3e3a02..b7a37dc 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -198,3 +198,4 @@ source "drivers/clk/mvebu/Kconfig"
 
 source "drivers/clk/samsung/Kconfig"
 source "drivers/clk/tegra/Kconfig"
+source "drivers/clk/mediatek/Kconfig"
diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
new file mode 100644
index 000..dc224e6
--- /dev/null
+++ b/drivers/clk/mediatek/Kconfig
@@ -0,0 +1,23 @@
+#
+# MediaTek SoC drivers
+#
+config COMMON_CLK_MEDIATEK
+   bool
+   ---help---
+ Mediatek SoCs' clock support.
+
+config COMMON_CLK_MT8135
+   bool "Clock driver for Mediatek MT8135"
+   depends on COMMON_CLK
+   select COMMON_CLK_MEDIATEK
+   default ARCH_MEDIATEK
+   ---help---
+ This driver supports Mediatek MT8135 clocks.
+
+config COMMON_CLK_MT8173
+   bool "Clock driver for Mediatek MT8173"
+   depends on COMMON_CLK
+   select COMMON_CLK_MEDIATEK
+   default ARCH_MEDIATEK
+   ---help---
+ This driver supports Mediatek MT8173 clocks.
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 95fdfac..32e7222 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -1,4 +1,4 @@
-obj-y += clk-mtk.o clk-pll.o clk-gate.o clk-apmixed.o
+obj-$(CONFIG_COMMON_CLK_MEDIATEK) += clk-mtk.o clk-pll.o clk-gate.o 
clk-apmixed.o
 obj-$(CONFIG_RESET_CONTROLLER) += reset.o
-obj-y += clk-mt8135.o
-obj-y += clk-mt8173.o
+obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135.o
+obj-$(CONFIG_COMMON_CLK_MT8173) += clk-mt8173.o
-- 
1.9.1

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

[PATCH 0/5] Add clock support for Mediatek MT2701

[James Liao]

This patchset is based on 4.4-rc7, add clock and reset controller support
for Mediatek MT2701.

This patchset also refined makefile and Kconfig to support configurable
multiple SoC clock support.

James Liao (1):
  clk: mediatek: Refine the makefile to support multiple clock drivers

Shunli Wang (4):
  clk: mediatek: Add dt-bindings for MT2701 clocks
  clk: mediatek: Add MT2701 clock support
  reset: mediatek: mt2701 reset controller dt-binding file
  reset: mediatek: mt2701 reset driver

 drivers/clk/Kconfig|1 +
 drivers/clk/mediatek/Kconfig   |   31 +
 drivers/clk/mediatek/Makefile  |7 +-
 drivers/clk/mediatek/clk-gate.c|   56 +
 drivers/clk/mediatek/clk-gate.h|2 +
 drivers/clk/mediatek/clk-mt2701.c  | 1215 
 drivers/clk/mediatek/clk-mtk.c |   25 +
 drivers/clk/mediatek/clk-mtk.h |   35 +-
 include/dt-bindings/clock/mt2701-clk.h |  481 
 .../dt-bindings/reset-controller/mt2701-resets.h   |   74 ++
 10 files changed, 1921 insertions(+), 6 deletions(-)
 create mode 100644 drivers/clk/mediatek/Kconfig
 create mode 100644 drivers/clk/mediatek/clk-mt2701.c
 create mode 100644 include/dt-bindings/clock/mt2701-clk.h
 create mode 100644 include/dt-bindings/reset-controller/mt2701-resets.h

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

[PATCH v2] iio: health: max30100: add config for LED current

[Matt Ranostay]

Allow the current for both RED and IR LEDs to be set via an device tree
property setting.

This is an optional setting that is useful for applications that have a
known glass attenuation factor.

Signed-off-by: Matt Ranostay 
---
Changes from v2:
* change to use microamp property name from LED class
* updated documentation for new format
* added allowed current index map

.../devicetree/bindings/iio/health/max30100.txt|  8 +++
 drivers/iio/health/max30100.c  | 81 --
 2 files changed, 83 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/iio/health/max30100.txt 
b/Documentation/devicetree/bindings/iio/health/max30100.txt
index f6fbac6..4eef96e 100644
--- a/Documentation/devicetree/bindings/iio/health/max30100.txt
+++ b/Documentation/devicetree/bindings/iio/health/max30100.txt
@@ -11,11 +11,19 @@ Required properties:
   Refer to interrupt-controller/interrupts.txt for generic
   interrupt client node bindings.
 
+Optional properties:
+  - maxim,led-current-microamp: configuration for LED current in microamperes
+while the engine is running. First indexed value is the configuration for
+the RED LED, and second value is for the IR LED.
+
+Refer to the datasheet for the allowed current values.
+
 Example:
 
 max30100@057 {
compatible = "maxim,max30100";
reg = <57>;
+   maxim,led-current-microamp = <24000 5>;
interrupt-parent = <&gpio1>;
interrupts = <16 2>;
 };
diff --git a/drivers/iio/health/max30100.c b/drivers/iio/health/max30100.c
index 9d1c81f..09db893 100644
--- a/drivers/iio/health/max30100.c
+++ b/drivers/iio/health/max30100.c
@@ -13,7 +13,7 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  * GNU General Public License for more details.
  *
- * TODO: allow LED current and pulse length controls via device tree properties
+ * TODO: enable pulse length controls via device tree properties
  */
 
 #include 
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -65,6 +66,7 @@
 #define MAX30100_REG_SPO2_CONFIG_1600US0x3
 
 #define MAX30100_REG_LED_CONFIG0x09
+#define MAX30100_REG_LED_CONFIG_LED_MASK   0x0f
 #define MAX30100_REG_LED_CONFIG_RED_LED_SHIFT  4
 
 #define MAX30100_REG_LED_CONFIG_24MA   0x07
@@ -111,6 +113,12 @@ static const struct regmap_config max30100_regmap_config = 
{
.volatile_reg = max30100_is_volatile_reg,
 };
 
+static const unsigned int max30100_led_current_mapping[] = {
+   4400, 7600, 11000, 14200, 17400,
+   20800, 24000, 27100, 30600, 33800,
+   37000, 40200, 43600, 46800, 5
+};
+
 static const unsigned long max30100_scan_masks[] = {0x3, 0};
 
 static const struct iio_chan_spec max30100_channels[] = {
@@ -243,15 +251,76 @@ static irqreturn_t max30100_interrupt_handler(int irq, 
void *private)
return IRQ_HANDLED;
 }
 
+static int max30100_get_current_idx(unsigned int val, int *reg)
+{
+   int idx;
+
+   /* LED turned off */
+   if (val == 0) {
+   *reg = 0;
+   return 0;
+   }
+
+   for (idx = 0; idx < ARRAY_SIZE(max30100_led_current_mapping); idx++) {
+   if (max30100_led_current_mapping[idx] == val) {
+   *reg = idx + 1;
+   return 0;
+   }
+   }
+
+   return -EINVAL;
+}
+
+static int max30100_led_init(struct max30100_data *data)
+{
+   struct device *dev = &data->client->dev;
+   struct device_node *np = dev->of_node;
+   unsigned int val[2];
+   int reg, ret;
+
+   ret = of_property_read_u32_array(np, "maxim,led-current-microamp",
+   (unsigned int *) &val, 2);
+   if (ret) {
+   /* Default to 24 mA RED LED, 50 mA IR LED */
+   reg = (MAX30100_REG_LED_CONFIG_24MA <<
+   MAX30100_REG_LED_CONFIG_RED_LED_SHIFT) |
+   MAX30100_REG_LED_CONFIG_50MA;
+   dev_warn(dev, "no led-current-microamp set");
+
+   return regmap_write(data->regmap, MAX30100_REG_LED_CONFIG, reg);
+   }
+
+   /* RED LED current */
+   ret = max30100_get_current_idx(val[0], ®);
+   if (ret) {
+   dev_err(dev, "invalid RED current setting %d", val[0]);
+   return ret;
+   }
+
+   ret = regmap_update_bits(data->regmap, MAX30100_REG_LED_CONFIG,
+   MAX30100_REG_LED_CONFIG_LED_MASK <<
+   MAX30100_REG_LED_CONFIG_RED_LED_SHIFT,
+   reg << MAX30100_REG_LED_CONFIG_RED_LED_SHIFT);
+   if (ret)
+   return ret;
+
+   /* IR LED current */
+   ret = max30100_get_current_idx(val[1], ®);
+   if (ret) {
+   dev_err(dev, "invalid IR current setting %d", val[1]);
+   return ret;
+   }
+
+   return regmap_update_bits(data->regmap, MAX30100_REG_LED_CONFIG,
+   

RE: [PATCH v2 1/4] Documentation: fsl-quadspi: Add fsl,ls2080a-dspi compatible string

[Yao Yuan]

Hi Rob,

Thanks for your review.
So you mean that I should add the commit message for why I add this new 
compatible?

Best Regards,
Yuan Yao

On Wed, Dec 30, 2015 at 02:35AM, Rob Herring wrote:
> On Thu, Dec 24, 2015 at 07:01:00PM +0800, Yuan Yao wrote:
> > new compatible string: "fsl,ls2080a-qspi".
> >
> > Signed-off-by: Yuan Yao 
> > ---
> > Changed in v2:
> > Update my email to 
> > ---
> >  Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > index fa77f87..2fe51d6 100644
> > --- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > +++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > @@ -1,7 +1,8 @@
> >  ARM Freescale DSPI controller
> >
> >  Required properties:
> > -- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi", 
> > "fsl,ls2085a-dspi"
> > +- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi",
> > +   "fsl,ls2085a-dspi", "fsl,ls2080a-dspi"
> 
> You should explain what combinations of compatible strings are valid.
> 
> Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3] net: emac: emac gigabit ethernet controller driver

[kbuild test robot]

Hi Gilad,

[auto build test WARNING on net/master]
[also build test WARNING on v4.4-rc7 next-20151223]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Gilad-Avidov/net-emac-emac-gigabit-ethernet-controller-driver/20151230-095104
config: ia64-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All warnings (new ones prefixed by >>):

   In file included from arch/ia64/include/asm/smp.h:20:0,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/slab.h:14,
from include/linux/textsearch.h:8,
from include/linux/skbuff.h:30,
from include/linux/tcp.h:21,
from drivers/net/ethernet/qualcomm/emac/emac-mac.c:16:
   drivers/net/ethernet/qualcomm/emac/emac-mac.c: In function 'emac_mac_up':
   arch/ia64/include/asm/io.h:394:30: warning: large integer implicitly 
truncated to unsigned type [-Woverflow]
#define writel(v,a) __writel((v), (a))
 ^
>> drivers/net/ethernet/qualcomm/emac/emac-mac.c:1090:2: note: in expansion of 
>> macro 'writel'
 writel(~DIS_INT, adpt->base + EMAC_INT_STATUS);
 ^

vim +/writel +1090 drivers/net/ethernet/qualcomm/emac/emac-mac.c

  1074  }
  1075  }
  1076  
  1077  ret = request_irq(irq->irq, emac_isr, 0, EMAC_MAC_IRQ_RES, irq);
  1078  if (ret) {
  1079  netdev_err(adpt->netdev,
  1080 "error:%d on request_irq(%d:%s flags:0)\n", 
ret,
  1081 irq->irq, EMAC_MAC_IRQ_RES);
  1082  goto err_request_irq;
  1083  }
  1084  
  1085  emac_mac_rx_descs_refill(adpt, &adpt->rx_q);
  1086  
  1087  napi_enable(&adpt->rx_q.napi);
  1088  
  1089  /* enable mac irq */
> 1090  writel(~DIS_INT, adpt->base + EMAC_INT_STATUS);
  1091  writel(adpt->irq.mask, adpt->base + EMAC_INT_MASK);
  1092  
  1093  netif_start_queue(netdev);
  1094  clear_bit(EMAC_STATUS_DOWN, &adpt->status);
  1095  
  1096  /* check link status */
  1097  set_bit(EMAC_STATUS_TASK_LSC_REQ, &adpt->status);
  1098  adpt->link_chk_timeout = jiffies + EMAC_TRY_LINK_TIMEOUT;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

RE: [PATCH] powerpc: fsl: update fman dt binding for PCS PHY

[Shaohui Xie]

> Subject: Re: [PATCH] powerpc: fsl: update fman dt binding for PCS PHY
> 
> On Mon, Dec 28, 2015 at 11:47:34AM +0800, shh@gmail.com wrote:
> > From: Shaohui Xie 
> >
> > PCS PHY can support backplane (1000BASE-KX and 10GBASE-KR), this needs
> > to change corresponding serdes lane settings, so a reference is needed
> > for serdes lane. This patch describes properties needed for PCS PHY to
> > support backplane.
> >
> > Signed-off-by: Shaohui Xie 
> > ---
> > based on: http://patchwork.ozlabs.org/patch/560936/
> >
> >  Documentation/devicetree/bindings/powerpc/fsl/fman.txt | 14
> > ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > index 55c2c03..b38e727 100644
> > --- a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > +++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > @@ -432,6 +432,16 @@ example of how to define a PHY (Internal PHY has no
> interrupt line).
> >  - For "fsl,fman-mdio" compatible internal mdio bus, the PHY is TBI PHY.
> >  - For "fsl,fman-memac-mdio" compatible internal mdio bus, the PHY is PCS 
> > PHY,
> >PCS PHY addr must be '0'.
> > +  PCS PHY can support backplane (1000BASE-KX and 10GBASE-KR), this
> > + needs to  change the corresponding serdes lane settings.
> > +
> > +  PCS PHY node properties required for backplane:
> > +
> > +  - compatible: must be "ethernet-phy-ieee802.3-c45".
> > +  - phy-mode: string, operation mode of the PHY interface; must be 
> > "1000base-
> kx"
> > +for 1000BASE-KX, or "10gbase-kr" for 10GBASE-KR.
> 
> Seems like these should be in common ethernet phy binding.
[S.H] 'compatible' and 'phy-mode' are standard properties already in common 
Ethernet
phy binding, I can update 'phy-mode' with "1000base-kx" and "10gbase-kr", how
about I still list the two properties here for the requirement of PCS PHY to 
support
backplane?

> 
> > +  - lane-handle: phandle, specifies a reference to a node representing a
> Serdes.
> > +  - lane-range: offset and length of the register set for the serdes lane.
> 
> These seem pretty FSL specific, so add vendor prefix.
[S.H] OK. will add fsl prefix.

Thank you for reviewing the patch!

Shaohui

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

[PATCH] mtd: spi-nor: add hisilicon spi-nor flash controller driver

[Jiancheng Xue]

add hisilicon spi-nor flash controller driver

Signed-off-by: Binquan Peng 
Signed-off-by: Jiancheng Xue 
---
 .../devicetree/bindings/spi/spi-hisi-sfc.txt   |  24 +
 drivers/mtd/spi-nor/Kconfig|   7 +
 drivers/mtd/spi-nor/Makefile   |   1 +
 drivers/mtd/spi-nor/hisi-sfc.c | 505 +
 4 files changed, 537 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/spi-hisi-sfc.txt
 create mode 100644 drivers/mtd/spi-nor/hisi-sfc.c

diff --git a/Documentation/devicetree/bindings/spi/spi-hisi-sfc.txt 
b/Documentation/devicetree/bindings/spi/spi-hisi-sfc.txt
new file mode 100644
index 000..170885a
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-hisi-sfc.txt
@@ -0,0 +1,24 @@
+HiSilicon SPI-NOR Flash Controller
+
+Required properties:
+- compatible : Should be "hisilicon,hisi-sfc".
+- address-cells: number of cells required to define a chip select
+address on the SPI bus. Should be set to 1. See spi-bus.txt.
+- size-cells:Should be 0.
+- reg : Offset and length of the register set for the controller device.
+- reg-names: Must include the following two entries:"control","memory".
+- clocks: handle to spi-nor flash controller clock.
+
+Example:
+spi-nor-controller@1400 {
+   compatible = "hisilicon,hisi-sfc";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x1000 0x1000>, <0x1400 0x100>;
+   reg-names = "control", "memory";
+   clocks = <&clock HI3519_FMC_CLK>;
+   spi-nor@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   };
+};
diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 2fe2a7e..7fe1564 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -30,6 +30,12 @@ config SPI_FSL_QUADSPI
  This controller does not support generic SPI. It only supports
  SPI NOR.
 
+config SPI_HISI_SFC
+   tristate "Hisilicon SPI-NOR Flash Controller(SFC)"
+   depends on ARCH_HISI
+   help
+ This enables support for hisilicon SPI-NOR flash controller.
+
 config SPI_NXP_SPIFI
tristate "NXP SPI Flash Interface (SPIFI)"
depends on OF && (ARCH_LPC18XX || COMPILE_TEST)
@@ -41,4 +47,5 @@ config SPI_NXP_SPIFI
  Flash. Enable this option if you have a device with a SPIFI
  controller and want to access the Flash as a mtd device.
 
+
 endif # MTD_SPI_NOR
diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
index e5e..8cea3c5 100644
--- a/drivers/mtd/spi-nor/Makefile
+++ b/drivers/mtd/spi-nor/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_MTD_SPI_NOR)  += spi-nor.o
 obj-$(CONFIG_SPI_FSL_QUADSPI)  += fsl-quadspi.o
+obj-$(CONFIG_SPI_HISI_SFC) += hisi-sfc.o
 obj-$(CONFIG_SPI_NXP_SPIFI)+= nxp-spifi.o
diff --git a/drivers/mtd/spi-nor/hisi-sfc.c b/drivers/mtd/spi-nor/hisi-sfc.c
new file mode 100644
index 000..fd9649a
--- /dev/null
+++ b/drivers/mtd/spi-nor/hisi-sfc.c
@@ -0,0 +1,505 @@
+/* HiSilicon SPI Nor Flash Controller Driver
+ *
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Hardware register offsets and field definitions */
+#define FMC_CFG0x00
+#define SPI_NOR_ADDR_MODE  BIT(10)
+#define FMC_GLOBAL_CFG 0x04
+#define FMC_GLOBAL_CFG_WP_ENABLE   BIT(6)
+#define FMC_SPI_TIMING_CFG 0x08
+#define TIMING_CFG_TCSH(nr)(((nr) & 0xf) << 8)
+#define TIMING_CFG_TCSS(nr)(((nr) & 0xf) << 4)
+#define TIMING_CFG_TSHSL(nr)   ((nr) & 0xf)
+#define CS_HOLD_TIME   0x6
+#define CS_SETUP_TIME  0x6
+#define CS_DESELECT_TIME   0xf
+#define FMC_INT0x18
+#define FMC_INT_OP_DONEBIT(0)
+#define FMC_INT_CLR0x20
+#define FMC_CMD0x24
+#define FMC_CMD_CMD1(_cmd) ((_cmd) & 0xff)
+#define FMC_ADDRL  0x2c
+#define FMC_OP_CFG 0x30
+#define OP_CFG_FM_CS(_cs)  ((_cs) << 11)
+#define OP_CFG_MEM_IF_TYPE(_type)  (((_type) & 0x7) << 7)
+#define OP_CFG_ADDR_NUM(

Re: [PATCH V3] net: emac: emac gigabit ethernet controller driver

[kbuild test robot]

Hi Gilad,

[auto build test WARNING on net/master]
[also build test WARNING on v4.4-rc7 next-20151223]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Gilad-Avidov/net-emac-emac-gigabit-ethernet-controller-driver/20151230-095104
config: x86_64-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/net/ethernet/qualcomm/emac/emac-mac.c: In function 'emac_mac_up':
>> drivers/net/ethernet/qualcomm/emac/emac-mac.c:1090:9: warning: large integer 
>> implicitly truncated to unsigned type [-Woverflow]
 writel(~DIS_INT, adpt->base + EMAC_INT_STATUS);
^

vim +1090 drivers/net/ethernet/qualcomm/emac/emac-mac.c

  1074  }
  1075  }
  1076  
  1077  ret = request_irq(irq->irq, emac_isr, 0, EMAC_MAC_IRQ_RES, irq);
  1078  if (ret) {
  1079  netdev_err(adpt->netdev,
  1080 "error:%d on request_irq(%d:%s flags:0)\n", 
ret,
  1081 irq->irq, EMAC_MAC_IRQ_RES);
  1082  goto err_request_irq;
  1083  }
  1084  
  1085  emac_mac_rx_descs_refill(adpt, &adpt->rx_q);
  1086  
  1087  napi_enable(&adpt->rx_q.napi);
  1088  
  1089  /* enable mac irq */
> 1090  writel(~DIS_INT, adpt->base + EMAC_INT_STATUS);
  1091  writel(adpt->irq.mask, adpt->base + EMAC_INT_MASK);
  1092  
  1093  netif_start_queue(netdev);
  1094  clear_bit(EMAC_STATUS_DOWN, &adpt->status);
  1095  
  1096  /* check link status */
  1097  set_bit(EMAC_STATUS_TASK_LSC_REQ, &adpt->status);
  1098  adpt->link_chk_timeout = jiffies + EMAC_TRY_LINK_TIMEOUT;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH] iio: health: max30100: add config for LED current

[Matt Ranostay]

On Tue, Dec 29, 2015 at 10:34 AM, Rob Herring  wrote:
> On Sat, Dec 26, 2015 at 08:38:24PM -0800, Matt Ranostay wrote:
>> Allow the current for both RED and IR LEDs to be set via an device tree
>> property setting.
>>
>> This is an optional setting that is useful for applications that have a
>> known glass attenuation factor.
>>
>> Signed-off-by: Matt Ranostay 
>> ---
>>  .../devicetree/bindings/iio/health/max30100.txt |  7 +++
>>  drivers/iio/health/max30100.c   | 21 
>> +++--
>>  2 files changed, 22 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/health/max30100.txt 
>> b/Documentation/devicetree/bindings/iio/health/max30100.txt
>> index f6fbac6..009314c 100644
>> --- a/Documentation/devicetree/bindings/iio/health/max30100.txt
>> +++ b/Documentation/devicetree/bindings/iio/health/max30100.txt
>> @@ -11,11 +11,18 @@ Required properties:
>>Refer to interrupt-controller/interrupts.txt for generic
>>interrupt client node bindings.
>>
>> +Optional properties:
>> +  - max30100,led-current: configuration for LED current (in mA) while the 
>> engine
>> +is running. Upper nibble is for the RED LED, and lower nibble the IR 
>> LED.
>
> Can you use the common LED binding and led-max-microamp instead?
>
> Otherwise, please add "-microamp" suffix and just split to 2 cells for
> RED and IR LEDs. Also, "max30100" is not a vendor prefix. Use maxim.

Ok.

>
>
>> + ret = of_property_read_u32(np, "max30100,led-current", &val);
>> + if (ret) {
>> + /* Default to 24 mA RED LED, 50 mA IR LED */
>> + val = (MAX30100_REG_LED_CONFIG_24MA <<
>> + MAX30100_REG_LED_CONFIG_RED_LED_SHIFT) |
>> + MAX30100_REG_LED_CONFIG_50MA;
>> + dev_warn(dev, "no led-current set, defaulting to %d", val);
>> + }
>> +
>> + ret = regmap_write(data->regmap, MAX30100_REG_LED_CONFIG, val & 0xFF);
>
> Huh? You say the units are milliamps, but then you use the DT value
> directly?

Yeah they are direct index values in the register. Probably should
make the documentation more clear.

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

[PATCH v4 4/6] ARM: debug: add hi3519 debug uart

[Jiancheng Xue]

add hi3519 debug uart.

Signed-off-by: Jiancheng Xue 
---
 arch/arm/Kconfig.debug | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 259c0ca..29af057 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -270,6 +270,14 @@ choice
  Say Y here if you want the debug print routines to direct
  their output to the 8250 at PCI COM1.
 
+   config DEBUG_HI3519_UART
+   bool "Hisilicon Hi3519 Debug UART"
+   depends on ARCH_HISI
+   select DEBUG_UART_PL01X
+   help
+ Say Y here if you want kernel low-level debugging support
+ on HI3519 UART.
+
config DEBUG_HI3620_UART
bool "Hisilicon HI3620 Debug UART"
depends on ARCH_HI3xxx
@@ -1449,6 +1457,7 @@ config DEBUG_UART_PHYS
default 0xf7fc9000 if DEBUG_BERLIN_UART
default 0xf8b0 if DEBUG_HIX5HD2_UART
default 0xf991e000 if DEBUG_QCOM_UARTDM
+   default 0x1210 if DEBUG_HI3519_UART
default 0xfcb0 if DEBUG_HI3620_UART
default 0xfd883000 if DEBUG_ALPINE_UART0
default 0xfe80 if ARCH_IOP32X
@@ -1529,6 +1538,7 @@ config DEBUG_UART_VIRT
default 0xfe23 if DEBUG_PICOXCELL_UART
default 0xfe30 if DEBUG_BCM_KONA_UART
default 0xfe80 if ARCH_IOP32X
+   default 0xfef0 if DEBUG_HI3519_UART
default 0xfeb0 if DEBUG_HI3620_UART || DEBUG_HIX5HD2_UART
default 0xfeb24000 if DEBUG_RK3X_UART0
default 0xfeb26000 if DEBUG_RK3X_UART1
-- 
1.9.1

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

[PATCH v4 3/6] ARM: config: hisi: enable CONFIG_RESET_CONTROLLER

[Jiancheng Xue]

enable CONFIG_RESET_CONTROLLER in hisi_defconfig

Signed-off-by: Jiancheng Xue 
---
 arch/arm/configs/hisi_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/hisi_defconfig b/arch/arm/configs/hisi_defconfig
index b2e340b..ba62c07 100644
--- a/arch/arm/configs/hisi_defconfig
+++ b/arch/arm/configs/hisi_defconfig
@@ -75,6 +75,7 @@ CONFIG_DMADEVICES=y
 CONFIG_DW_DMAC=y
 CONFIG_PL330_DMA=y
 CONFIG_PWM=y
+CONFIG_RESET_CONTROLLER=y
 CONFIG_PHY_HIX5HD2_SATA=y
 CONFIG_EXT4_FS=y
 CONFIG_TMPFS=y
-- 
1.9.1

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

[PATCH v4 2/6] ARM: hisi: add compatible string for Hi3519 soc

[Jiancheng Xue]

add compatible string for Hi3519 soc.

Signed-off-by: Jiancheng Xue 
---
 arch/arm/mach-hisi/hisilicon.c | 23 ---
 1 file changed, 4 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-hisi/hisilicon.c b/arch/arm/mach-hisi/hisilicon.c
index 8cc6215..00dae89 100644
--- a/arch/arm/mach-hisi/hisilicon.c
+++ b/arch/arm/mach-hisi/hisilicon.c
@@ -54,30 +54,15 @@ DT_MACHINE_START(HI3620, "Hisilicon Hi3620 (Flattened 
Device Tree)")
.dt_compat  = hi3xxx_compat,
 MACHINE_END
 
-static const char *const hix5hd2_compat[] __initconst = {
+static const char *const hisilicon_compat[] __initconst = {
"hisilicon,hix5hd2",
-   NULL,
-};
-
-DT_MACHINE_START(HIX5HD2_DT, "Hisilicon HIX5HD2 (Flattened Device Tree)")
-   .dt_compat  = hix5hd2_compat,
-MACHINE_END
-
-static const char *const hip04_compat[] __initconst = {
"hisilicon,hip04-d01",
-   NULL,
-};
-
-DT_MACHINE_START(HIP04, "Hisilicon HiP04 (Flattened Device Tree)")
-   .dt_compat  = hip04_compat,
-MACHINE_END
-
-static const char *const hip01_compat[] __initconst = {
"hisilicon,hip01",
"hisilicon,hip01-ca9x2",
+   "hisilicon,hi3519",
NULL,
 };
 
-DT_MACHINE_START(HIP01, "Hisilicon HIP01 (Flattened Device Tree)")
-   .dt_compat  = hip01_compat,
+DT_MACHINE_START(HISILICON_DT, "HiSilicon Soc")
+   .dt_compat  = hisilicon_compat,
 MACHINE_END
-- 
1.9.1

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

[PATCH v4 1/6] clk: hisilicon: add CRG driver for hi3519 soc

[Jiancheng Xue]

The CRG(Clock and Reset Generator) block provides clock
and reset signals for other modules in hi3519 soc.

Signed-off-by: Jiancheng Xue 
---
 .../devicetree/bindings/clock/hi3519-crg.txt   |  46 +++
 drivers/clk/hisilicon/Kconfig  |   7 +
 drivers/clk/hisilicon/Makefile |   2 +
 drivers/clk/hisilicon/clk-hi3519.c | 103 ++
 drivers/clk/hisilicon/reset.c  | 149 +
 drivers/clk/hisilicon/reset.h  |  32 +
 include/dt-bindings/clock/hi3519-clock.h   |  43 ++
 7 files changed, 382 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/hi3519-crg.txt
 create mode 100644 drivers/clk/hisilicon/clk-hi3519.c
 create mode 100644 drivers/clk/hisilicon/reset.c
 create mode 100644 drivers/clk/hisilicon/reset.h
 create mode 100644 include/dt-bindings/clock/hi3519-clock.h

diff --git a/Documentation/devicetree/bindings/clock/hi3519-crg.txt 
b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
new file mode 100644
index 000..2d23950
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
@@ -0,0 +1,46 @@
+* Hisilicon Hi3519 Clock and Reset Generator(CRG)
+
+The Hi3519 CRG module provides clock and reset signals to various
+controllers within the SoC.
+
+This binding uses the following bindings:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+Documentation/devicetree/bindings/reset/reset.txt
+
+Required Properties:
+
+- compatible: should be one of the following.
+  - "hisilicon,hi3519-crg" - controller compatible with Hi3519 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes use this identifier
+to specify the clock which they consume.
+
+All these identifier could be found in .
+
+- #reset-cells: should be 2.
+
+A reset signal can be controlled by writing a bit register in the CRG module.
+The reset specifier consists of two cells. The first cell represents the
+register offset relative to the base address. The second cell represents the
+bit index in the register.
+
+Example: CRG nodes
+CRG: clock-reset-controller@1201 {
+   compatible = "hisilicon,hi3519-crg";
+reg = <0x1201 0x1>;
+#clock-cells = <1>;
+#reset-cells = <2>;
+};
+
+Example: consumer nodes
+i2c0: i2c@1211 {
+   compatible = "hisilicon,hi3519-i2c";
+reg = <0x1211 0x1000>;
+clocks = <&CRG HI3519_I2C0_RST>;*/
+resets = <&CRG 0xe4 0>;
+};
diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
index e434854..b6baebf 100644
--- a/drivers/clk/hisilicon/Kconfig
+++ b/drivers/clk/hisilicon/Kconfig
@@ -1,3 +1,10 @@
+config COMMON_CLK_HI3519
+   tristate "Clock Driver for Hi3519"
+   depends on ARCH_HISI
+   default y
+   help
+ Build the clock driver for hi3519.
+
 config COMMON_CLK_HI6220
bool "Hi6220 Clock Driver"
depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
index 74dba31..3f57b09 100644
--- a/drivers/clk/hisilicon/Makefile
+++ b/drivers/clk/hisilicon/Makefile
@@ -4,8 +4,10 @@
 
 obj-y  += clk.o clkgate-separated.o clkdivider-hi6220.o
 
+obj-$(CONFIG_RESET_CONTROLLER) += reset.o
 obj-$(CONFIG_ARCH_HI3xxx)  += clk-hi3620.o
 obj-$(CONFIG_ARCH_HIP04)   += clk-hip04.o
 obj-$(CONFIG_ARCH_HIX5HD2) += clk-hix5hd2.o
 obj-$(CONFIG_COMMON_CLK_HI6220)+= clk-hi6220.o
 obj-$(CONFIG_STUB_CLK_HI6220)  += clk-hi6220-stub.o
+obj-$(CONFIG_COMMON_CLK_HI3519)+= clk-hi3519.o
diff --git a/drivers/clk/hisilicon/clk-hi3519.c 
b/drivers/clk/hisilicon/clk-hi3519.c
new file mode 100644
index 000..e220234
--- /dev/null
+++ b/drivers/clk/hisilicon/clk-hi3519.c
@@ -0,0 +1,103 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "clk.h"
+#include "reset.h"
+
+#define HI3519_FIXED_24M   (HI3519_EXT_CLKS + 1)
+#define HI3519_FIXED_50M   (HI3519_EXT_CLKS + 2)
+#define HI3519_FIXED_75M   (HI3519_EXT_CLKS + 3)
+#define HI3519_FIXED_125M  (HI3519_EXT_CLKS + 4)
+#define HI3519_FIXED_150M  

[PATCH v4 6/6] ARM: dts: add dts files for Hi3519

[Jiancheng Xue]

add dts files for Hi3519

Signed-off-by: Jiancheng Xue 
---
 arch/arm/boot/dts/Makefile|   2 +
 arch/arm/boot/dts/hi3519-demb.dts |  42 +
 arch/arm/boot/dts/hi3519.dtsi | 175 ++
 3 files changed, 219 insertions(+)
 create mode 100644 arch/arm/boot/dts/hi3519-demb.dts
 create mode 100644 arch/arm/boot/dts/hi3519.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..1ff3ed9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -135,6 +135,8 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
exynos5800-peach-pi.dtb
 dtb-$(CONFIG_ARCH_HI3xxx) += \
hi3620-hi4511.dtb
+dtb-$(CONFIG_ARCH_HISI) += \
+   hi3519-demb.dtb
 dtb-$(CONFIG_ARCH_HIX5HD2) += \
hisi-x5hd2-dkb.dtb
 dtb-$(CONFIG_ARCH_HIGHBANK) += \
diff --git a/arch/arm/boot/dts/hi3519-demb.dts 
b/arch/arm/boot/dts/hi3519-demb.dts
new file mode 100644
index 000..6991ab6
--- /dev/null
+++ b/arch/arm/boot/dts/hi3519-demb.dts
@@ -0,0 +1,42 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ *
+ */
+
+/dts-v1/;
+#include "hi3519.dtsi"
+
+/ {
+   model = "HiSilicon HI3519 DEMO Board";
+   compatible = "hisilicon,hi3519";
+
+   aliases {
+   serial0 = &uart0;
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x4000>;
+   };
+};
+
+&uart0 {
+   status = "okay";
+};
+
+&dual_timer0 {
+   status = "okay";
+};
diff --git a/arch/arm/boot/dts/hi3519.dtsi b/arch/arm/boot/dts/hi3519.dtsi
new file mode 100644
index 000..95137c7
--- /dev/null
+++ b/arch/arm/boot/dts/hi3519.dtsi
@@ -0,0 +1,175 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ *
+ */
+
+#include 
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   chosen { };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0>;
+   };
+   };
+
+   gic: interrupt-controller@1030 {
+   compatible = "arm,cortex-a7-gic";
+   #interrupt-cells = <3>;
+   interrupt-controller;
+   reg = <0x10301000 0x1000>, <0x10302000 0x1000>;
+   };
+
+   soc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "simple-bus";
+   interrupt-parent = <&gic>;
+   ranges;
+
+
+   uart0: serial@1210 {
+   compatible = "arm,pl011", "arm,primecell";
+   reg = <0x1210 0x1000>;
+   interrupts = <0 4 4>;
+   clocks = <&crg HI3519_UART0_CLK>;
+   clock-names = "apb_pclk";
+   status = "disable";
+   };
+
+   uart1: serial@12101000 {
+   compatible = "arm,pl011", "arm,primecell";
+   reg = <0x12101000 0x1000>;
+   interrupts = <0 5 4>;
+   clocks = <&crg HI3519_UART1_CLK>;
+   clock-names = "apb_pclk";
+   status = "disable";
+   };
+
+   uart2: serial@12102000 {
+   compatible = "arm,pl011", "arm,primecell";
+   reg = <0x12102000 0x1000>;
+   interrupts = <0 6 4>;
+   clocks = <&crg HI3519_UART2_CLK>;
+   clock-names = "apb_pclk";
+   

[PATCH v4 0/6] ARM: hisi: Add initial support including clock driver for Hi3519 soc.

[Jiancheng Xue]

Hello,

Hi3519 soc is mainly used for ip camera and sport DV solutions. This patchset 
adds initial support
for Hi3519 soc. It includes clock driver, arch configuration, debug uart 
configuration and device tree.
It has been tested on hi3519 reference board.

Spi-nor flash driver and other peripheral drivers will be submitted later.

Any comments will be appreciated!

Thanks!

Change Log
--
v4:
-Rebase to v4.4-rc7
-Divide patches according to Rob's comments
-Add spi nodes in hi3519-demb.dts

v3:
-Rebase to v4.4-rc4
-Adjust according to Arnd's comments
-Remove ARCH_HI3519, using ARCH_HISI directly

v2:
-Rebase to v4.4-rc3
-Put dt-binding doc and header file in a separate patch.
-Delete unused clocks definitions.
-Adjust the ARCH_xxx order in Kconfig file
-Rename ARCH_HI3xxx to ARCH_36xx

Jiancheng Xue (6):
  clk: hisilicon: add CRG driver for hi3519 soc
  ARM: hisi: add compatible string for Hi3519 soc
  ARM: config: hisi: enable CONFIG_RESET_CONTROLLER
  ARM: debug: add hi3519 debug uart
  mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
  ARM: dts: add dts files for Hi3519

 .../devicetree/bindings/clock/hi3519-crg.txt   |  46 ++
 Documentation/devicetree/bindings/mfd/hi3519.txt   |  14 ++
 arch/arm/Kconfig.debug |  10 ++
 arch/arm/boot/dts/Makefile |   2 +
 arch/arm/boot/dts/hi3519-demb.dts  |  42 +
 arch/arm/boot/dts/hi3519.dtsi  | 175 +
 arch/arm/configs/hisi_defconfig|   1 +
 arch/arm/mach-hisi/hisilicon.c |  23 +--
 drivers/clk/hisilicon/Kconfig  |   7 +
 drivers/clk/hisilicon/Makefile |   2 +
 drivers/clk/hisilicon/clk-hi3519.c | 103 
 drivers/clk/hisilicon/reset.c  | 149 ++
 drivers/clk/hisilicon/reset.h  |  32 
 include/dt-bindings/clock/hi3519-clock.h   |  43 +
 14 files changed, 630 insertions(+), 19 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/hi3519-crg.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
 create mode 100644 arch/arm/boot/dts/hi3519-demb.dts
 create mode 100644 arch/arm/boot/dts/hi3519.dtsi
 create mode 100644 drivers/clk/hisilicon/clk-hi3519.c
 create mode 100644 drivers/clk/hisilicon/reset.c
 create mode 100644 drivers/clk/hisilicon/reset.h
 create mode 100644 include/dt-bindings/clock/hi3519-clock.h

-- 
1.9.1

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

[PATCH v4 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl

[Jiancheng Xue]

Add device tree bindings for Hi3519 system controller.

Signed-off-by: Jiancheng Xue 
---
 Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt

diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt 
b/Documentation/devicetree/bindings/mfd/hi3519.txt
new file mode 100644
index 000..2536edc
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
@@ -0,0 +1,14 @@
+* Hisilicon Hi3519 System Controller Block
+
+This bindings use the following binding:
+Dcumentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible: "hisilicon,hi3519-sysctrl".
+- reg: the register region of this block
+
+Examples:
+sysctrl: system-controller@1201 {
+   compatible = "hisilicon,hi3519-sysctrl", "syscon";
+   reg = <0x1201 0x1000>;
+};
-- 
1.9.1

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

Re: [RESEND PATCH v1 0/4] Add support emac for the RK3036 SoC platform

[David Miller]

From: Heiko Stübner 
Date: Tue, 29 Dec 2015 23:27:55 +0100

> Hi Dave,
> 
> Am Dienstag, 29. Dezember 2015, 15:53:14 schrieb David Miller:
>> You have to submit this series properly, the same problem happend twice
>> now.
>> 
>> When you submit a series you should:
>> 
>> 1) Make it clear which tree you expect these changes to be applied
>>to.  Here it is completely ambiguous, do you want it to go into
>>my networking tree or some other subsystem tree?
>> 
>> 2) You MUST keep all parties informed about all patches for a series
>>like this.  That means you cannot drop netdev from patch #4 as
>>you did both times.  Doing this aggravates the situation for
>>#1 even more, because if a patch is not CC:'d to netdev it does
>>not enter patchwork.  And if it doesn't go into patchwork, I'm
>>not looking at it.
> 
> I guess that is some unfortunate result of git send-email combined with 
> get_maintainer.pl . In general I also prefer to see the whole series, but 
> have 
> gotten such partial series from other maintainers as well in the past, so it 
> seems to be depending on preferences somewhat.
> 
> For the series at hand, the 4th patch is the devicetree addition, which the 
> expected way is me picking it up, after you are comfortable with the code-
> related changes.

Why would it not be appropriate for a DT file change to go into my tree
if it corresponds to functionality created by the rest of the patches
in the series?

It looks better to put it all together as a unit, via one series, with
a merge commit containing your "[PATCH 0/N]" description in the commit
message.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/3] arm: boot: beaglex15: pass correct interrupt

[Chanwoo Choi]

From: Felipe Balbi 

According to latest schematics [1], GPIO_1/VBUSDET
on TPS659038 is tied to AM57x GPIO4_21. We can use
that as a VBUS interrupt, instead of relying on
PMIC's VBUS interrupts which don't seem to be firing
on x15 at all.

A follow up patch will add support for using this
GPIO-based interrupt mechanism for notifying about
VBUS.

[1] 
https://github.com/beagleboard/beagleboard-x15/blob/master/BeagleBoard-X15_RevA2.pdf

Signed-off-by: Felipe Balbi 
[cw00.choi: Use the 'vbus-gpio' property instead of 'interrupts-extended']
Signed-off-by: Chanwoo Choi 
---
 arch/arm/boot/dts/am57xx-beagle-x15.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index be4990608c77..3887ba89d2a5 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -560,6 +560,7 @@
extcon_usb2: tps659038_usb {
compatible = "ti,palmas-usb-vid";
ti,enable-vbus-detection;
+   vbus-gpio = <&gpio4 21 GPIO_ACTIVE_HIGH>;
};
 
};
-- 
1.9.1

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

[PATCH v2 2/3] arm: boot: dts: beaglex15: Remove ID GPIO

[Chanwoo Choi]

From: Felipe Balbi 

According to latest schematics [1], this board
leaves ID pin floating. It's not connected to
anything at all.

So let's remove it.

[1] 
https://github.com/beagleboard/beagleboard-x15/blob/master/BeagleBoard-X15_RevA2.pdf

Signed-off-by: Felipe Balbi 
Signed-off-by: Chanwoo Choi 
---
 arch/arm/boot/dts/am57xx-beagle-x15.dts | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index d9ba6b879fc1..be4990608c77 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -560,8 +560,6 @@
extcon_usb2: tps659038_usb {
compatible = "ti,palmas-usb-vid";
ti,enable-vbus-detection;
-   ti,enable-id-detection;
-   id-gpios = <&gpio7 24 GPIO_ACTIVE_HIGH>;
};
 
};
-- 
1.9.1

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

[PATCH v2 0/3] arm: beaglex15: fix USB Gadget

[Chanwoo Choi]

This patchset make the extcon-palmas.c more generic style and then send v2
patchset. I add the Felipe comment of v1 patchset as following:
But, I have not test on real board because I don't have it.
Just, I modify this patchset based on v1 patchset[1] from Felipe Balbi.

- Felipe comment of this patchset:
"Hi,

with the following patches I can get USB Gadget working
with my beagle x15 with today's Linus' tree.

regards".

[1] https://lkml.org/lkml/2015/11/12/508

Changes from v1:
(https://lkml.org/lkml/2015/11/12/508)
- Refactoring the extcon-palmas.c driver with more generic style to support
  the VBUS gpio pin.
- Use the 'vbus-gpio' property instead of 'interrupts-extended']

Felipe Balbi (3):
  extcon: palmas: Add the support for VBUS detection by using GPIO
  arm: boot: dts: beaglex15: Remove ID GPIO
  arm: boot: beaglex15: pass correct interrupt

 arch/arm/boot/dts/am57xx-beagle-x15.dts |  3 +-
 drivers/extcon/extcon-palmas.c  | 50 +
 include/linux/mfd/palmas.h  |  3 ++
 3 files changed, 54 insertions(+), 2 deletions(-)

-- 
1.9.1

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

[PATCH v2 1/3] extcon: palmas: Add the support for VBUS detection by using GPIO

[Chanwoo Choi]

From: Felipe Balbi 

This patch support for VBUS detection by using GPIO pin.

Signed-off-by: Felipe Balbi 
Signed-off-by: Chanwoo Choi 
---
 drivers/extcon/extcon-palmas.c | 50 ++
 include/linux/mfd/palmas.h |  3 +++
 2 files changed, 53 insertions(+)

diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
index 93c30a885740..885ee95a6a7b 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -216,11 +216,23 @@ static int palmas_usb_probe(struct platform_device *pdev)
return PTR_ERR(palmas_usb->id_gpiod);
}
 
+   palmas_usb->vbus_gpiod = devm_gpiod_get_optional(&pdev->dev, "vbus",
+   GPIOD_IN);
+   if (IS_ERR(palmas_usb->vbus_gpiod)) {
+   dev_err(&pdev->dev, "failed to get vbus gpio\n");
+   return PTR_ERR(palmas_usb->vbus_gpiod);
+   }
+
if (palmas_usb->enable_id_detection && palmas_usb->id_gpiod) {
palmas_usb->enable_id_detection = false;
palmas_usb->enable_gpio_id_detection = true;
}
 
+   if (palmas_usb->enable_vbus_detection && palmas_usb->vbus_gpiod) {
+   palmas_usb->enable_vbus_detection = false;
+   palmas_usb->enable_gpio_vbus_detection = true;
+   }
+
if (palmas_usb->enable_gpio_id_detection) {
u32 debounce;
 
@@ -311,6 +323,40 @@ static int palmas_usb_probe(struct platform_device *pdev)
palmas_usb->vbus_irq, status);
return status;
}
+   } else if (palmas_usb->enable_gpio_vbus_detection) {
+   /* remux GPIO_1 as VBUSDET */
+   status = palmas_update_bits(palmas,
+   PALMAS_PU_PD_OD_BASE,
+   PALMAS_PRIMARY_SECONDARY_PAD1,
+   PALMAS_PRIMARY_SECONDARY_PAD1_GPIO_1_MASK,
+   (1 << PALMAS_PRIMARY_SECONDARY_PAD1_GPIO_1_SHIFT));
+   if (status < 0) {
+   dev_err(&pdev->dev, "can't remux GPIO1\n");
+   return status;
+   }
+
+   palmas_usb->vbus_otg_irq = regmap_irq_get_virq(palmas->irq_data,
+  PALMAS_VBUS_OTG_IRQ);
+   palmas_usb->gpio_vbus_irq = 
gpiod_to_irq(palmas_usb->vbus_gpiod);
+   if (palmas_usb->gpio_vbus_irq < 0) {
+   dev_err(&pdev->dev, "failed to get vbus irq\n");
+   return palmas_usb->gpio_vbus_irq;
+   }
+   status = devm_request_threaded_irq(&pdev->dev,
+   palmas_usb->gpio_vbus_irq,
+   NULL,
+   palmas_vbus_irq_handler,
+   IRQF_TRIGGER_FALLING |
+   IRQF_TRIGGER_RISING |
+   IRQF_ONESHOT |
+   IRQF_EARLY_RESUME,
+   "palmas_usb_vbus",
+   palmas_usb);
+   if (status < 0) {
+   dev_err(&pdev->dev,
+   "failed to request handler for vbus irq\n");
+   return status;
+   }
}
 
palmas_enable_irq(palmas_usb);
@@ -337,6 +383,8 @@ static int palmas_usb_suspend(struct device *dev)
if (device_may_wakeup(dev)) {
if (palmas_usb->enable_vbus_detection)
enable_irq_wake(palmas_usb->vbus_irq);
+   if (palmas_usb->enable_gpio_vbus_detection)
+   enable_irq_wake(palmas_usb->gpio_vbus_irq);
if (palmas_usb->enable_id_detection)
enable_irq_wake(palmas_usb->id_irq);
if (palmas_usb->enable_gpio_id_detection)
@@ -352,6 +400,8 @@ static int palmas_usb_resume(struct device *dev)
if (device_may_wakeup(dev)) {
if (palmas_usb->enable_vbus_detection)
disable_irq_wake(palmas_usb->vbus_irq);
+   if (palmas_usb->enable_gpio_vbus_detection)
+   disable_irq_wake(palmas_usb->gpio_vbus_irq);
if (palmas_usb->enable_id_detection)
disable_irq_wake(palmas_usb->id_irq);
if (palmas_usb->enable_gpio_id_detection)
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index 13e1d96935ed..7b2526f7bc9b 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -553,7 +553,9 @@ struct palmas_usb {
int vbus_irq;
 
int gpio_id_irq;
+   int gpio_vbus_irq;
struct gpio_desc *id_gpiod;
+   struct gpio_desc

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

[Milo Kim]

Hi Paul,

On 29/12/15 20:13, Paul Kocialkowski wrote:

Hi Milo,

Le mardi 29 décembre 2015 à 09:45 +0900, Milo Kim a écrit :

Hi Paul,

On 29/12/15 07:49, Paul Kocialkowski wrote:

Hi Milo, thanks for the review,

Le lundi 28 décembre 2015 à 09:56 +0900, Milo Kim a écrit :

Hi Paul,

On 23/12/15 20:56, Mark Brown wrote:

On Wed, Dec 23, 2015 at 11:58:37AM +0100, Paul Kocialkowski wrote:


+   gpio = lp->pdata->enable_gpio;
+   if (!gpio_is_valid(gpio))
+   return 0;
+
+   /* Always set enable GPIO high. */
+   ret = devm_gpio_request_one(lp->dev, gpio, GPIOF_OUT_INIT_HIGH, "LP872X 
EN");
+   if (ret) {
+   dev_err(lp->dev, "gpio request err: %d\n", ret);
+   return ret;
+   }


This isn't really adding support for the enable GPIO as the changelog
suggests, it's requesting but not managing the GPIO.  Since there is
core support for manging enable GPIOs this seems especially silly,
please tell the core about the GPIO and then it will work at runtime
too.



With reference to my previous mail, external GPIOs for LDO3 and BUCK2 in
LP8725 can be specified through regulator_config.ena_gpio. BUCK2 only
can be controlled by external pin when CONFIG pin is grounded.

Please see the description at page 5 of the datasheet.

http://www.ti.com/lit/ds/symlink/lp8725.pdf


After reading the datasheets thoroughly, it seems to me that for the
lp8720, the EN pin is used to enable the regulators output, which is a
good fit for the core regulator GPIO framework, as there is no reason to
keep it on when no regulator is in use. The serial interface is already
available when EN=0 and regulators can be configured in that state. The
lp8725 seems seems to behave the same when CONFIG=0 (the datasheet
clearly states: "CONFIG=0: EN=1 turns on outputs or standby mode if
EN=0"). On the other hand, it is indeed used as a power-on pin when
CONFIG=1.


I think it's different use case. LP8720/5 are designed for system PMU,
so some regulators are enabled by default after the device is on. EN pin
is used for turning on/off the chip. This pin does not control regulator
outputs directly. It's separate functional block in the silicon.


Well, I really don't understand why the EN pin would turn on/off the
chip. All it does it enable the regulators outputs (by entering IDLE
mode), the serial block is already available in STANDBY state.

If we want some regulators enabled at boot, the best thing to do seems
to be to request the GPIO with the GPIOF_INIT_HIGH flag, as done in e.g.
the max8952 regulator driver:

if (pdata->reg_data->constraints.boot_on)
config.ena_gpio_flags |= GPIOF_OUT_INIT_HIGH;


According to MAX8952 datasheet, output regulator is enabled/disabled 
using EN pin, so ena_gpio is used correctly.
However, LP8720/5 regulators are enabled/disabled through I2C command. 
Only few regulators of LP8725 can be on/off by separate external pins. 
(B2_EN and LDO3_EN)
Please note that EN pin in LP8720/5 is not the control pin for 
enabling/disabling regulators.


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

Re: [PATCH 4/4] dt: binding: Add Qualcomm wcn36xx WiFi binding

[Rob Herring]

On Tue, Dec 29, 2015 at 11:03:57AM -0800, Bjorn Andersson wrote:
> On Tue 29 Dec 10:34 PST 2015, Rob Herring wrote:
> 
> > On Sun, Dec 27, 2015 at 05:34:27PM -0800, Bjorn Andersson wrote:
> > > Add binding representing the Qualcomm wcn3620/60/80 WiFi block.
> > > Signed-off-by: Bjorn Andersson 
> > > ---
> > >  .../bindings/net/wireless/qcom,wcn36xx-wifi.txt| 76 
> > > ++
> > >  1 file changed, 76 insertions(+)
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > > 
> > > diff --git 
> > > a/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt 
> > > b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > > new file mode 100644
> > > index ..7b314b9f30af
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > > @@ -0,0 +1,76 @@
> > > +Qualcomm WCN36xx WiFi Binding
> > > +
> > > +This binding describes the Qualcomm WCN36xx WiFi hardware. The hardware 
> > > block
> > > +is part of the Qualcomm WCNSS core, a WiFi/BT/FM combo chip, found in a 
> > > variety
> > > +of Qualcomm platforms.
> > 
> > Are BT/FM functions completely separate? If so, separate bindings are 
> > okay. If not, then we need to describe the full chip.
> > 
> 
> It's three different hardware blocks (WiFi, BT and FM-radio) with shared
> RF-hardware and an ARM core for control logic.
> 
> There seems to be some control commands going towards the BT part that
> controls coexistence properties of the RF-hardware, but other than that
> I see it as logically separate blocks.
> 
> 
> So I think it's fine to model this as separate pieces in DT.

Okay.

Acked-by: Rob Herring 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH v1 0/4] Add support emac for the RK3036 SoC platform

[Florian Fainelli]

On December 29, 2015 2:27:55 PM PST, "Heiko Stübner"  wrote:
>Hi Dave,
>
>Am Dienstag, 29. Dezember 2015, 15:53:14 schrieb David Miller:
>> You have to submit this series properly, the same problem happend
>twice
>> now.
>> 
>> When you submit a series you should:
>> 
>> 1) Make it clear which tree you expect these changes to be applied
>>to.  Here it is completely ambiguous, do you want it to go into
>>my networking tree or some other subsystem tree?
>> 
>> 2) You MUST keep all parties informed about all patches for a series
>>like this.  That means you cannot drop netdev from patch #4 as
>>you did both times.  Doing this aggravates the situation for
>>#1 even more, because if a patch is not CC:'d to netdev it does
>>not enter patchwork.  And if it doesn't go into patchwork, I'm
>>not looking at it.
>
>I guess that is some unfortunate result of git send-email combined with
>
>get_maintainer.pl . In general I also prefer to see the whole series,
>but have 
>gotten such partial series from other maintainers as well in the past,
>so it 
>seems to be depending on preferences somewhat.

You could run get_maintainer.pl against the individual patches in the series, 
merge the cc list somewhere in a file/variable and then do the actual mail 
submission with that full list for all patches. There could be a way to 
automate that with a bit of help from git send-email eventually.

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

Re: [RESEND PATCH v1 0/4] Add support emac for the RK3036 SoC platform

[Heiko Stübner]

Hi Dave,

Am Dienstag, 29. Dezember 2015, 15:53:14 schrieb David Miller:
> You have to submit this series properly, the same problem happend twice
> now.
> 
> When you submit a series you should:
> 
> 1) Make it clear which tree you expect these changes to be applied
>to.  Here it is completely ambiguous, do you want it to go into
>my networking tree or some other subsystem tree?
> 
> 2) You MUST keep all parties informed about all patches for a series
>like this.  That means you cannot drop netdev from patch #4 as
>you did both times.  Doing this aggravates the situation for
>#1 even more, because if a patch is not CC:'d to netdev it does
>not enter patchwork.  And if it doesn't go into patchwork, I'm
>not looking at it.

I guess that is some unfortunate result of git send-email combined with 
get_maintainer.pl . In general I also prefer to see the whole series, but have 
gotten such partial series from other maintainers as well in the past, so it 
seems to be depending on preferences somewhat.

For the series at hand, the 4th patch is the devicetree addition, which the 
expected way is me picking it up, after you are comfortable with the code-
related changes.


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

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Rob Herring]

+Arnd and Olof

On Mon, Dec 28, 2015 at 4:39 PM, Michael Turquette
 wrote:
> Quoting Eric Anholt (2015-12-24 15:45:15)
>> Michael Turquette  writes:
>>
>> > On Fri, Dec 18, 2015 at 8:19 PM, Rob Herring  wrote:
>> >> On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote:
>> >>> These will be used for enabling UART1, SPI1, and SPI2.
>> >>>
>> >>> Signed-off-by: Eric Anholt 
>> >>> ---
>> >>>
>> >>> v2: Make the binding cover both the IRQ and clock enable registers.
>> >>>
>> >>>  .../bindings/clock/brcm,bcm2835-aux-clock.txt  | 31 
>> >>> ++
>> >>>  include/dt-bindings/clock/bcm2835-aux.h| 17 
>> >>>  2 files changed, 48 insertions(+)
>> >>>  create mode 100644 
>> >>> Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
>> >>>  create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
>> >>
>> >> Acked-by: Rob Herring 
>> >
>> > Applied to clk-next.
>> >
>> > Next time if you put the header into the clk driver patch then we can
>> > send the binding description through the DT tree and take the header
>> > and C file through the clk tree in one patch.
>>
>> I would *love* to do that, but I've previously been told that having the
>> bindings patch reference a header file not present as of the bindings
>> patch is not acceptable and made to change it.
>
> Ugh, that is annoying. I would think that having code compile properly
> would trump the desire to have all of the documentation merged as one
> patch.

What about compiling the dts?

> On the other hand, I've been asked to not take binding descriptions
> through the clk tree. That is a policy that I'm happy to comply with,
> but it is at odds with the recommendation for the header and the binding
> description to be merged together.

By who? Any bindings in a series I always expect the subsystem
maintainers to take the whole series. That doesn't solve the problem
though as there is still a dependency between a subsystem tree and
arm-soc typically.

> DT folks, what is the right way to do this? An immutable, shared branch
> just for a single header file solves the problem, but also feels very
> cumbersome for such a trivial issue.

Arnd and Olof have been complaining about this problem which is worse
when it is a binding, driver and dts.

I'm open to maintaining a branch for this purpose if that helps. That
or staggering merging of bindings and drivers/dts are the only ideas
I've come up with.

> How about allowing binding descriptions to be merged without the header
> file, so long as it is merged through another tree?

I think that is wrong if we have the goal to separate bindings from
the kernel and the bindings should stand on their own. However, if it
greatly simplifies things, i'd be okay with that.

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

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

[Rob Herring]

On Tue, Dec 29, 2015 at 3:26 PM, Paul Kocialkowski  wrote:
> Le mardi 29 décembre 2015 à 14:02 -0600, Rob Herring a écrit :
>> On Wed, Dec 23, 2015 at 11:58:37AM +0100, Paul Kocialkowski wrote:
>> > LP872x regulators are made active via the EN pin, which might be hooked to 
>> > a
>> > GPIO. This adds support for driving the GPIO high when the driver is in 
>> > use.
>> >
>> > Signed-off-by: Paul Kocialkowski 
>> > ---
>> >  .../devicetree/bindings/regulator/lp872x.txt   |  1 +
>> >  drivers/regulator/lp872x.c | 33 
>> > --
>> >  include/linux/regulator/lp872x.h   |  2 ++
>> >  3 files changed, 33 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/regulator/lp872x.txt 
>> > b/Documentation/devicetree/bindings/regulator/lp872x.txt
>> > index 7818318..0559c25 100644
>> > --- a/Documentation/devicetree/bindings/regulator/lp872x.txt
>> > +++ b/Documentation/devicetree/bindings/regulator/lp872x.txt
>> > @@ -28,6 +28,7 @@ Optional properties:
>> >- ti,dvs-gpio: GPIO specifier for external DVS pin control of LP872x 
>> > devices.
>> >- ti,dvs-vsel: DVS selector. 0 = SEL_V1, 1 = SEL_V2.
>> >- ti,dvs-state: initial DVS pin state. 0 = DVS_LOW, 1 = DVS_HIGH.
>> > +  - ti,enable-gpio: GPIO specifier for EN pin control of LP872x devices.
>>
>> Should be "-gpios" instead of "-gpio".
>
> Care to comment why? There is only one GPIO that can be used here, since
> there is only one single EN pin. I thought this matched what is done
> already with "ti,dvs-gpio".

To be consistent. We use "clocks" and "interrupts" always whether one
or more for example.

-gpio is documented as deprecated now.

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

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

[Paul Kocialkowski]

Le mardi 29 décembre 2015 à 14:02 -0600, Rob Herring a écrit :
> On Wed, Dec 23, 2015 at 11:58:37AM +0100, Paul Kocialkowski wrote:
> > LP872x regulators are made active via the EN pin, which might be hooked to a
> > GPIO. This adds support for driving the GPIO high when the driver is in use.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  .../devicetree/bindings/regulator/lp872x.txt   |  1 +
> >  drivers/regulator/lp872x.c | 33 
> > --
> >  include/linux/regulator/lp872x.h   |  2 ++
> >  3 files changed, 33 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/regulator/lp872x.txt 
> > b/Documentation/devicetree/bindings/regulator/lp872x.txt
> > index 7818318..0559c25 100644
> > --- a/Documentation/devicetree/bindings/regulator/lp872x.txt
> > +++ b/Documentation/devicetree/bindings/regulator/lp872x.txt
> > @@ -28,6 +28,7 @@ Optional properties:
> >- ti,dvs-gpio: GPIO specifier for external DVS pin control of LP872x 
> > devices.
> >- ti,dvs-vsel: DVS selector. 0 = SEL_V1, 1 = SEL_V2.
> >- ti,dvs-state: initial DVS pin state. 0 = DVS_LOW, 1 = DVS_HIGH.
> > +  - ti,enable-gpio: GPIO specifier for EN pin control of LP872x devices.
> 
> Should be "-gpios" instead of "-gpio".

Care to comment why? There is only one GPIO that can be used here, since
there is only one single EN pin. I thought this matched what is done
already with "ti,dvs-gpio".

Thanks!


signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 1/3] devicetree/bindings: add reset-gpios and vcc-supply for panel-dpi

[Rob Herring]

On Sun, Dec 20, 2015 at 12:13:20PM +0100, Uwe Kleine-König wrote:
> Some displays have a reset input and/or need a regulator to function
> properly. Allow to specify them for panel-dpi devices.
> 
> Signed-off-by: Uwe Kleine-König 
> ---
>  Documentation/devicetree/bindings/display/panel/panel-dpi.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt 
> b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
> index 216c894d4f99..b52ac52757df 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
> +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
> @@ -7,6 +7,8 @@ Required properties:
>  Optional properties:
>  - label: a symbolic name for the panel
>  - enable-gpios: panel enable gpio
> +- reset-gpios: GPIO to control the RESET pin

The problem with this in a generic binding is what if the panel has 
ordering requirements like enable gpio has to be inactive when reset 
is deasserted?

> +- vcc-supply: phandle of regulator that will be used to enable power to the 
> display

What if there are 2 supplies?

While there are limits to what can be described here, I'm okay with 
allowing these, so:

Acked-by: Rob Herring 

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

Re: [RESEND PATCH v1 0/4] Add support emac for the RK3036 SoC platform

[David Miller]

You have to submit this series properly, the same problem happend twice
now.

When you submit a series you should:

1) Make it clear which tree you expect these changes to be applied
   to.  Here it is completely ambiguous, do you want it to go into
   my networking tree or some other subsystem tree?

2) You MUST keep all parties informed about all patches for a series
   like this.  That means you cannot drop netdev from patch #4 as
   you did both times.  Doing this aggravates the situation for
   #1 even more, because if a patch is not CC:'d to netdev it does
   not enter patchwork.  And if it doesn't go into patchwork, I'm
   not looking at it.

Thanks.

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

Re: [PATCH v4 9/9] phy: omap-usb2: use *syscon* framework API to power on/off the PHY

[Rob Herring]

On Mon, Dec 21, 2015 at 02:24:13PM +0530, Kishon Vijay Abraham I wrote:
> Deprecate using phy-omap-control driver to power on/off the PHY,
> and use *syscon* framework to do the same. This handles
> powering on/off the PHY for the USB2 PHYs used in various TI SoCs.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  Documentation/devicetree/bindings/phy/ti-phy.txt |8 +-
>  drivers/phy/phy-omap-usb2.c  |   92 
> ++
>  include/linux/phy/omap_usb.h |   23 ++
>  3 files changed, 105 insertions(+), 18 deletions(-)

Acked-by: Rob Herring 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] pci, pcie-thunder-pem: Add PCIe host driver for ThunderX processors.

[Rob Herring]

On Tue, Dec 22, 2015 at 03:43:52PM -0800, David Daney wrote:
> From: David Daney 
> 
> Some Cavium ThunderX processors require quirky access methods for the
> config space of the PCIe bridge.  Add a driver to provide these config
> space accessor functions.  The pci-host-common code is used to
> configure the PCI machinery.

Same comments again...

> Signed-off-by: David Daney 
> ---
>  .../devicetree/bindings/pci/pcie-thunder-pem.txt   |  43 
>  drivers/pci/host/Kconfig   |   7 +
>  drivers/pci/host/Makefile  |   1 +
>  drivers/pci/host/pcie-thunder-pem.c| 283 
> +
>  4 files changed, 334 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/pcie-thunder-pem.txt
>  create mode 100644 drivers/pci/host/pcie-thunder-pem.c
> 
> diff --git a/Documentation/devicetree/bindings/pci/pcie-thunder-pem.txt 
> b/Documentation/devicetree/bindings/pci/pcie-thunder-pem.txt
> new file mode 100644
> index 000..52f56b3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/pcie-thunder-pem.txt
> @@ -0,0 +1,43 @@
> +* ThunderX PEM PCIe host controller
> +
> +Firmware-initialized PCIe host controller found on some Cavium
> +ThunderX processors.
> +
> +The properties and their meanings are identical to those described in
> +host-generic-pci.txt except as listed below.
> +
> +Properties of the host controller node that differ from
> +host-generic-pci.txt:
> +
> +- compatible : Must be "cavium,pci-host-thunder-pem"

pcie rather than pci?

> +
> +- reg: Two entries: First the configuration space for down
> +   stream devices base address and size, as accessed
> +   from the parent bus. Second, the register bank of
> +   the PEM device PCIe bridge.
> +
> +Example:
> +
> +pem2 {

pcie-controller@... instead of pem2.

> + compatible = "cavium,pci-host-thunder-pem";
> + device_type = "pci";
> + msi-parent = <&its>;
> + msi-map = <0 &its 0x1 0x1>;
> + bus-range = <0x8f 0xc7>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> +
> + reg = <0x8880 0x8f00 0x0 0x3900>,  /* Configuration space */
> +   <0x87e0 0xc200 0x0 0x0001>; /* PEM space */
> + ranges = <0x0100 0x00 0x0002 0x88b0 0x0002 0x00 
> 0x0001>, /* I/O */
> +  <0x0300 0x00 0x1000 0x8890 0x1000 0x0f 
> 0xf000>, /* mem64 */
> +  <0x4300 0x10 0x 0x88a0 0x 0x10 
> 0x>, /* mem64-pref */
> +  <0x0300 0x87e0 0xc2f0 0x87e0 0xc200 0x00 
> 0x0010>; /* mem64 PEM BAR4 */
> +
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0 0 0 1 &gic0 0 0 0 24 4>, /* INTA */
> + <0 0 0 2 &gic0 0 0 0 25 4>, /* INTB */
> + <0 0 0 3 &gic0 0 0 0 26 4>, /* INTC */
> + <0 0 0 4 &gic0 0 0 0 27 4>; /* INTD */
> +};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] drivers: net: cpsw: fix error messages when using phy-handle DT property

[Rob Herring]

On Tue, Dec 22, 2015 at 07:36:33PM -0500, David Rivshin (Allworx) wrote:
> From: David Rivshin 
> 
> The phy-handle, phy_id, and fixed-link properties are mutually exclusive,
> and only one need be specified. However if phy-handle was specified, an
> error message would complain about the lack of phy_id or fixed-link.
> 
> Also, if phy-handle was specified and the subsequent of_phy_connect()
> failed, the error message still referenced slaved->data->phy_id, which
> would be empty. Instead, use the name of the device_node as a useful
> identifier.
> 
> Fixes: 9e42f715264f ("drivers: net: cpsw: add phy-handle parsing")
> Signed-off-by: David Rivshin 
> ---
> This would require some adjustments to backport to 4.3-stable due to
> other changes in this area. Let me know if you want a version of this
> against v4.3.3.
> 
>  Documentation/devicetree/bindings/net/cpsw.txt |  4 ++--

For the binding:

Acked-by: Rob Herring 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

[Rob Herring]

On Wed, Dec 23, 2015 at 11:58:37AM +0100, Paul Kocialkowski wrote:
> LP872x regulators are made active via the EN pin, which might be hooked to a
> GPIO. This adds support for driving the GPIO high when the driver is in use.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  .../devicetree/bindings/regulator/lp872x.txt   |  1 +
>  drivers/regulator/lp872x.c | 33 
> --
>  include/linux/regulator/lp872x.h   |  2 ++
>  3 files changed, 33 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/regulator/lp872x.txt 
> b/Documentation/devicetree/bindings/regulator/lp872x.txt
> index 7818318..0559c25 100644
> --- a/Documentation/devicetree/bindings/regulator/lp872x.txt
> +++ b/Documentation/devicetree/bindings/regulator/lp872x.txt
> @@ -28,6 +28,7 @@ Optional properties:
>- ti,dvs-gpio: GPIO specifier for external DVS pin control of LP872x 
> devices.
>- ti,dvs-vsel: DVS selector. 0 = SEL_V1, 1 = SEL_V2.
>- ti,dvs-state: initial DVS pin state. 0 = DVS_LOW, 1 = DVS_HIGH.
> +  - ti,enable-gpio: GPIO specifier for EN pin control of LP872x devices.

Should be "-gpios" instead of "-gpio".

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

Re: [PATCH 4/4] dt: binding: Add Qualcomm wcn36xx WiFi binding

[Andy Gross]

On Sun, Dec 27, 2015 at 05:34:27PM -0800, Bjorn Andersson wrote:
> Add binding representing the Qualcomm wcn3620/60/80 WiFi block.
> 
> Signed-off-by: Bjorn Andersson 
> ---



> +
> +- qcom,wcnss-mmio:
> + Usage: required
> + Value type: 

nit:  encoded

> + Definition: should specify base address and size of the WiFi related
> + registers of WCNSS
> +
> +- qcom,state:
> + Usage: required
> + Value type: 
> + Definition: should specify the tx-enable and tx-ring-empty state
> + references
> +



Otherwise looks good.

Reviewed-by: Andy Gross 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/4] dt-binding: remoteproc: Introduce Qualcomm WCNSS loader binding

[Andy Gross]

On Sun, Dec 27, 2015 at 05:15:45PM -0800, Bjorn Andersson wrote:
> The document defines the binding for a component that loads firmware for
> and boots the Qualcomm WCNSS core.
> 
> Signed-off-by: Bjorn Andersson 
> ---

Acked-by: Andy Gross 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] dt: binding: Add Qualcomm wcn36xx WiFi binding

[Bjorn Andersson]

On Tue 29 Dec 10:34 PST 2015, Rob Herring wrote:

> On Sun, Dec 27, 2015 at 05:34:27PM -0800, Bjorn Andersson wrote:
> > Add binding representing the Qualcomm wcn3620/60/80 WiFi block.
> > Signed-off-by: Bjorn Andersson 
> > ---
> >  .../bindings/net/wireless/qcom,wcn36xx-wifi.txt| 76 
> > ++
> >  1 file changed, 76 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt 
> > b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > new file mode 100644
> > index ..7b314b9f30af
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > @@ -0,0 +1,76 @@
> > +Qualcomm WCN36xx WiFi Binding
> > +
> > +This binding describes the Qualcomm WCN36xx WiFi hardware. The hardware 
> > block
> > +is part of the Qualcomm WCNSS core, a WiFi/BT/FM combo chip, found in a 
> > variety
> > +of Qualcomm platforms.
> 
> Are BT/FM functions completely separate? If so, separate bindings are 
> okay. If not, then we need to describe the full chip.
> 

It's three different hardware blocks (WiFi, BT and FM-radio) with shared
RF-hardware and an ARM core for control logic.

There seems to be some control commands going towards the BT part that
controls coexistence properties of the RF-hardware, but other than that
I see it as logically separate blocks.


So I think it's fine to model this as separate pieces in DT.

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

Re: [PATCH 2/2] dt-bindings: ci-hdrc-usb2: add missing compatibles

[Rob Herring]

On Tue, Dec 29, 2015 at 04:41:09PM +, Stefan Wahren wrote:
> This patch adds the missing compatible strings from ci_hdrc_imx.
> 
> Signed-off-by: Stefan Wahren 
> ---
>  .../devicetree/bindings/usb/ci-hdrc-usb2.txt   |7 +++
>  1 file changed, 7 insertions(+)

Acked-by: Rob Herring 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/4] dt-binding: remoteproc: Introduce Qualcomm WCNSS loader binding

[Rob Herring]

On Sun, Dec 27, 2015 at 05:15:45PM -0800, Bjorn Andersson wrote:
> The document defines the binding for a component that loads firmware for
> and boots the Qualcomm WCNSS core.
> 
> Signed-off-by: Bjorn Andersson 
> ---
> 
> Changes since v1:
> - Dropped custom properties for firmware-name and crash-reason
> 
>  .../bindings/remoteproc/qcom,wcnss-pil.txt | 92 
> ++
>  1 file changed, 92 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt

Seems reasonable to me. I'd like to see some acks from QC folks.

Acked-by: Rob Herring 


> +- clock-names:
> + Usage: requireduired

typo

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

Re: [PATCH 4/4] dt: binding: Add Qualcomm wcn36xx WiFi binding

[Rob Herring]

On Sun, Dec 27, 2015 at 05:34:27PM -0800, Bjorn Andersson wrote:
> Add binding representing the Qualcomm wcn3620/60/80 WiFi block.
> Signed-off-by: Bjorn Andersson 
> ---
>  .../bindings/net/wireless/qcom,wcn36xx-wifi.txt| 76 
> ++
>  1 file changed, 76 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt 
> b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> new file mode 100644
> index ..7b314b9f30af
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> @@ -0,0 +1,76 @@
> +Qualcomm WCN36xx WiFi Binding
> +
> +This binding describes the Qualcomm WCN36xx WiFi hardware. The hardware block
> +is part of the Qualcomm WCNSS core, a WiFi/BT/FM combo chip, found in a 
> variety
> +of Qualcomm platforms.

Are BT/FM functions completely separate? If so, separate bindings are 
okay. If not, then we need to describe the full chip.

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

Re: [PATCH v2 2/4] Documentation: fsl-quadspi: Add fsl, ls2080a-qspi compatible string

[Rob Herring]

On Thu, Dec 24, 2015 at 07:01:01PM +0800, Yuan Yao wrote:
> new compatible string: "fsl,ls2080a-qspi".
> 
> Signed-off-by: Yuan Yao 
> ---
> Changed in v2:
> Update my email to 
> ---
>  Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt 
> b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
> index 6585ac7..2bef0dc 100644
> --- a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
> +++ b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
> @@ -3,7 +3,7 @@
>  Required properties:
>- compatible : Should be "fsl,vf610-qspi", "fsl,imx6sx-qspi",
>"fsl,imx7d-qspi", "fsl,imx6ul-qspi",
> -  "fsl,ls1021-qspi"
> +  "fsl,ls1021a-qspi", "fsl,ls2080a-qspi"

You should explain what combinations of compatible strings are valid.

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

Re: [PATCH 2/2] dt-bindings: bus: ti-gpmc: Add AAD timings properties

[Rob Herring]

On Mon, Dec 28, 2015 at 02:39:21PM +0100, Neil Armstrong wrote:
> In order to support advanced AAD timings, add these properties to the DT
> GPMC bindings.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  Documentation/devicetree/bindings/bus/ti-gpmc.txt | 5 +
>  1 file changed, 5 insertions(+)

Acked-by: Rob Herring 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/4] Documentation: fsl-quadspi: Add fsl,ls2080a-dspi compatible string

[Rob Herring]

On Thu, Dec 24, 2015 at 07:01:00PM +0800, Yuan Yao wrote:
> new compatible string: "fsl,ls2080a-qspi".
> 
> Signed-off-by: Yuan Yao 
> ---
> Changed in v2:
> Update my email to 
> ---
>  Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt 
> b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> index fa77f87..2fe51d6 100644
> --- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> +++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> @@ -1,7 +1,8 @@
>  ARM Freescale DSPI controller
>  
>  Required properties:
> -- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi", "fsl,ls2085a-dspi"
> +- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi",
> + "fsl,ls2085a-dspi", "fsl,ls2080a-dspi"

You should explain what combinations of compatible strings are valid.

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

Re: [PATCH v9 1/3] Documentation: DT: Add entry for Freescale LS1043a-RDB board

[Rob Herring]

On Thu, Dec 24, 2015 at 05:37:51PM +0800, Zhiqiang Hou wrote:
> From: Mingkai Hu 
> 
> Signed-off-by: Mingkai Hu 
> Signed-off-by: Hou Zhiqiang 
> ---
> V9 - V2:
>  - No change.
>  Documentation/devicetree/bindings/arm/fsl.txt | 4 
>  1 file changed, 4 insertions(+)

Acked-by: Rob Herring 

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

Re: [PATCH v2 1/2] Documentation: DT: Add entry for Freescale LS1043a-QDS board

[Rob Herring]

On Thu, Dec 24, 2015 at 05:11:37PM +0800, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
> 
> Signed-off-by: Hou Zhiqiang 
> ---
> new patch
> 
>  Documentation/devicetree/bindings/arm/fsl.txt | 4 
>  1 file changed, 4 insertions(+)

Acked-by: Rob Herring 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm64: Add DT support for Juno r2 board

[Rob Herring]

On Wed, Dec 23, 2015 at 12:10:11PM +, Sudeep Holla wrote:
> Juno r2 is identical to Juno r1 with Cortex A57 cores replaced by
> Cortex A72 cores.

That's a bigger change than I'd expect...

> Acked-by: Liviu Dudau 
> Signed-off-by: Sudeep Holla 
> ---
>  Documentation/devicetree/bindings/arm/arm-boards |   1 +
>  Documentation/devicetree/bindings/arm/cpus.txt   |   1 +

This should probably be a separate patch, but I already have a patch in 
my tree for 4.5 adding arm,cortex-a72. So just drop this hunk.

>  arch/arm64/boot/dts/arm/Makefile |   2 +-
>  arch/arm64/boot/dts/arm/juno-r2.dts  | 200 
> +++
>  4 files changed, 203 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm64/boot/dts/arm/juno-r2.dts

[...]

> + pmu_a72 {
> + compatible = "arm,cortex-a72-pmu";

This needs to be documented.


> + pcie-controller@4000 {
> + compatible = "arm,juno-r1-pcie", "plda,xpressrich3-axi", 
> "pci-host-ecam-generic";

Is this common with r1?

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

Re: [PATCH 1/3] ti-st: use device handles and add device tree binding

[Rob Herring]

On Wed, Dec 23, 2015 at 11:38:29AM +, Reizer, Eyal wrote:
> - Add support for getting the platform data which includes the uart
>   used and gpio pin used for enable from device tree.
> 
> - Fix the implementation for using device handle for the uart and
>   gpiod for the enable pin, instead of device name (as string) used
>   for the uart and pio number which are both bad practice.
> 
> Signed-off-by: Eyal Reizer 
> ---
>  Documentation/devicetree/bindings/misc/ti-st.txt |   42 ++
>  arch/arm/mach-omap2/pdata-quirks.c   |   16 ++-
>  drivers/misc/ti-st/st_kim.c  |  159 
> --
>  drivers/misc/ti-st/st_ll.c   |   16 ++-
>  include/linux/ti_wilink_st.h |   13 +-

I'd suggest you look at commit c0bd1b9e58959c5 (Revert "ti-st: add 
device tree support") first.

>  5 files changed, 190 insertions(+), 56 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/misc/ti-st.txt
> 
> diff --git a/Documentation/devicetree/bindings/misc/ti-st.txt 
> b/Documentation/devicetree/bindings/misc/ti-st.txt
> new file mode 100644
> index 000..4490da6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/ti-st.txt
> @@ -0,0 +1,42 @@
> +TI Wilink 6/7/8 (wl12xx/wl18xx) Shared transport driver

Bindings shouldn't be describing drivers...

> +
> +TI’s Wireless Connectivity chips support Bluetooth (BT), WiFi, and GPS
> +technology cores in a single die.
> +
> +Such a multi-core combo chip will be interfaced to the application processor
> +using a single physical port (like UART).
> +
> +Shared Transport (ST) software enables BT and GPS protocols or software
> +components to interact with their respective cores over single physical port.
> +ST uses logical channels, over physical transport, to communicate with
> +individual cores.
> +
> +Logical channels 1, 2, 3, and 4 are used for BT packets, channel 8 for FM,
> +channel 9 for GPS and channels 30, 31, 32, and 33 are used for Chip Power
> +Management (PM).

All this is irrelevant for a binding. 

> +
> +This node provides properties for passing parameters to the ti shared
> +transport driver.
> +
> +Required properties:
> + - compatible: should be the following:
> +* "kim" - ti-st parameters

Who is kim? Certainly not a description of a h/w block.

> +
> +Optional properties:
> + - nshutdown-gpios : specifies attributes for gpio ping used for enabling
> + the bluetooth,gps and FM sub systems
> + - serial-device : the phandle for the phisical uart used for interacting
> + with the wilink device

There have been multiple discussions on serial slave devices recently. 
I'm not going to accept any device binding without a common uart slave 
device binding first.

> + - flow_cntrl : Indicates if uart flow control is used
> + - flow_cntrl : uart baud rate in BPS

Typo here, but these should be part of a common serial slave binding.

Don't use '_' in property names.

> +
> +Example:
> +
> +kim {
> + compatible = "kim";
> + nshutdown-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
> + serial-device = <&uart1>;
> + flow_cntrl = <1>;
> + flow_cntrl = <300>;
> +};
> +
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] DT: i2c: Add Freescale MPL3115 to trivial devices list

[Rob Herring]

On Wed, Dec 23, 2015 at 01:59:07PM -0500, Akshay Bhat wrote:
> This adds devicetree documentation for the bindings of mpl3115 driver.
> 
> Signed-off-by: Akshay Bhat 
> ---
>  Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Who did you want to apply this? Send patches TO that person which I 
would expect to be Wolfram or me.

Rob

> 
> diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt 
> b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> index c50cf13..f3f4bc2 100644
> --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> @@ -54,6 +54,7 @@ epson,rx8581I2C-BUS INTERFACE REAL TIME 
> CLOCK MODULE
>  fsl,mag3110  MAG3110: Xtrinsic High Accuracy, 3D Magnetometer
>  fsl,mc13892  MC13892: Power Management Integrated Circuit (PMIC) for 
> i.MX35/51
>  fsl,mma8450  MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic 
> Accelerometer
> +fsl,mpl3115  MPL3115: Absolute Digital Pressure Sensor
>  fsl,mpr121   MPR121: Proximity Capacitive Touch Sensor Controller
>  fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec
>  gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog 
> with Two-Wire Interface
> -- 
> 2.6.3
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] iio: health: max30100: add config for LED current

[Rob Herring]

On Sat, Dec 26, 2015 at 08:38:24PM -0800, Matt Ranostay wrote:
> Allow the current for both RED and IR LEDs to be set via an device tree
> property setting.
> 
> This is an optional setting that is useful for applications that have a
> known glass attenuation factor.
> 
> Signed-off-by: Matt Ranostay 
> ---
>  .../devicetree/bindings/iio/health/max30100.txt |  7 +++
>  drivers/iio/health/max30100.c   | 21 
> +++--
>  2 files changed, 22 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/iio/health/max30100.txt 
> b/Documentation/devicetree/bindings/iio/health/max30100.txt
> index f6fbac6..009314c 100644
> --- a/Documentation/devicetree/bindings/iio/health/max30100.txt
> +++ b/Documentation/devicetree/bindings/iio/health/max30100.txt
> @@ -11,11 +11,18 @@ Required properties:
>Refer to interrupt-controller/interrupts.txt for generic
>interrupt client node bindings.
>  
> +Optional properties:
> +  - max30100,led-current: configuration for LED current (in mA) while the 
> engine
> +is running. Upper nibble is for the RED LED, and lower nibble the IR LED.

Can you use the common LED binding and led-max-microamp instead?

Otherwise, please add "-microamp" suffix and just split to 2 cells for 
RED and IR LEDs. Also, "max30100" is not a vendor prefix. Use maxim.


> + ret = of_property_read_u32(np, "max30100,led-current", &val);
> + if (ret) {
> + /* Default to 24 mA RED LED, 50 mA IR LED */
> + val = (MAX30100_REG_LED_CONFIG_24MA <<
> + MAX30100_REG_LED_CONFIG_RED_LED_SHIFT) |
> + MAX30100_REG_LED_CONFIG_50MA;
> + dev_warn(dev, "no led-current set, defaulting to %d", val);
> + }
> +
> + ret = regmap_write(data->regmap, MAX30100_REG_LED_CONFIG, val & 0xFF);

Huh? You say the units are milliamps, but then you use the DT value 
directly?

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

Re: [PATCH 4/4] Documentation: fsl-quadspi: Add optional properties

[Rob Herring]

On Thu, Dec 24, 2015 at 07:01:03PM +0800, Yuan Yao wrote:
> Add optional properties for QSPI:
> big-endian
> if the register is big endian on this platform.
> 
> Signed-off-by: Yuan Yao 
> ---
>  Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] powerpc: fsl: update fman dt binding for PCS PHY

[Rob Herring]

On Mon, Dec 28, 2015 at 11:47:34AM +0800, shh@gmail.com wrote:
> From: Shaohui Xie 
> 
> PCS PHY can support backplane (1000BASE-KX and 10GBASE-KR), this needs
> to change corresponding serdes lane settings, so a reference is needed
> for serdes lane. This patch describes properties needed for PCS PHY to
> support backplane.
> 
> Signed-off-by: Shaohui Xie 
> ---
> based on: http://patchwork.ozlabs.org/patch/560936/
> 
>  Documentation/devicetree/bindings/powerpc/fsl/fman.txt | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt 
> b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> index 55c2c03..b38e727 100644
> --- a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> @@ -432,6 +432,16 @@ example of how to define a PHY (Internal PHY has no 
> interrupt line).
>  - For "fsl,fman-mdio" compatible internal mdio bus, the PHY is TBI PHY.
>  - For "fsl,fman-memac-mdio" compatible internal mdio bus, the PHY is PCS PHY,
>PCS PHY addr must be '0'.
> +  PCS PHY can support backplane (1000BASE-KX and 10GBASE-KR), this needs to
> +  change the corresponding serdes lane settings.
> +
> +  PCS PHY node properties required for backplane:
> +
> +  - compatible: must be "ethernet-phy-ieee802.3-c45".
> +  - phy-mode: string, operation mode of the PHY interface; must be 
> "1000base-kx"
> +for 1000BASE-KX, or "10gbase-kr" for 10GBASE-KR.

Seems like these should be in common ethernet phy binding.

> +  - lane-handle: phandle, specifies a reference to a node representing a 
> Serdes.
> +  - lane-range: offset and length of the register set for the serdes lane.

These seem pretty FSL specific, so add vendor prefix.

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

Re: [PATCH v3 2/5] dt-bindings: mediatek: Modify pinctrl bindings for mt2701

[Rob Herring]

On Mon, Dec 28, 2015 at 03:09:03PM +0800, Biao Huang wrote:
> Signed-off-by: Biao Huang 
> ---
>  .../devicetree/bindings/pinctrl/pinctrl-mt65xx.txt |9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)

I acked v2 already. Please add acks when posting new versions.

Acked-by: Rob Herring 

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

Re: [PATCH v3 2/3] wlcore/wl12xx: spi: add device tree support

[Rob Herring]

On Mon, Dec 28, 2015 at 02:02:18PM +0200, Uri Mashiach wrote:
> Add DT support for the wl1271 SPI WiFi.
> 
> Add documentation file for the wl1271 SPI WiFi.
> 
> Signed-off-by: Uri Mashiach 
> Acked-by: Igor Grinberg 
> ---
> v1 -> v2: update interrupt documentation.
>   replace interrupts and interrupt-parent with interrupts-extended.

Why? interrupts-extended is really just for cases with 2 interrupt 
parents.

> IRQ parameters retrieved from spi_device instead of DT.
> remove redundant #ifdef CONFIG_OF
> v2 -> v3: Add MODULE_DEVICE_TABLE.
>   Remove #ifdef CONFIG_OF.
> Make the Kconfig symbol to depend on OF.
> Replace irqd_get_trigger_type() with irq_get_trigger_type().
> 
>  .../bindings/net/wireless/ti,wlcore,spi.txt| 34 

In any case:

Acked-by: Rob Herring 

>  drivers/net/wireless/ti/wlcore/Kconfig |  2 +-
>  drivers/net/wireless/ti/wlcore/spi.c   | 47 
> --
>  3 files changed, 78 insertions(+), 5 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] usb: chipidea: add CI_HDRC_TURN_VBUS_EARLY_ON for imx23

[Stefan Wahren]

Until now the imx23 uses the imx27 platform flag. But the
imx23 needs the flag CI_HDRC_TURN_VBUS_EARLY_ON, too. So
fix this by adding a separate platform flag.

Suggested-by: Peter Chen 
Signed-off-by: Stefan Wahren 
---
 drivers/usb/chipidea/ci_hdrc_imx.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
b/drivers/usb/chipidea/ci_hdrc_imx.c
index f14f4ab..b4605dd 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -28,6 +28,11 @@ struct ci_hdrc_imx_platform_flag {
bool runtime_pm;
 };
 
+static const struct ci_hdrc_imx_platform_flag imx23_usb_data = {
+   .flags = CI_HDRC_TURN_VBUS_EARLY_ON |
+   CI_HDRC_DISABLE_STREAMING,
+};
+
 static const struct ci_hdrc_imx_platform_flag imx27_usb_data = {
CI_HDRC_DISABLE_STREAMING,
 };
@@ -66,6 +71,7 @@ static const struct ci_hdrc_imx_platform_flag imx7d_usb_data 
= {
 };
 
 static const struct of_device_id ci_hdrc_imx_dt_ids[] = {
+   { .compatible = "fsl,imx23-usb", .data = &imx23_usb_data},
{ .compatible = "fsl,imx28-usb", .data = &imx28_usb_data},
{ .compatible = "fsl,imx27-usb", .data = &imx27_usb_data},
{ .compatible = "fsl,imx6q-usb", .data = &imx6q_usb_data},
-- 
1.7.9.5

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

[PATCH 2/2] dt-bindings: ci-hdrc-usb2: add missing compatibles

[Stefan Wahren]

This patch adds the missing compatible strings from ci_hdrc_imx.

Signed-off-by: Stefan Wahren 
---
 .../devicetree/bindings/usb/ci-hdrc-usb2.txt   |7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt 
b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
index 781296b..1e83509 100644
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
@@ -2,7 +2,14 @@
 
 Required properties:
 - compatible: should be one of:
+   "fsl,imx23-usb"
"fsl,imx27-usb"
+   "fsl,imx28-usb"
+   "fsl,imx6q-usb"
+   "fsl,imx6sl-usb"
+   "fsl,imx6sx-usb"
+   "fsl,imx6ul-usb"
+   "fsl,imx7d-usb"
"lsi,zevio-usb"
"qcom,ci-hdrc"
"chipidea,usb2"
-- 
1.7.9.5

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

Re: [PATCH v4] arm64: dts: add all hi6220 i2c nodes

[Bintian]

On 2015/12/2 18:13, Xinwei Kong wrote:

This patch adds all I2C nodes for the Hi6220 SoC. This hi6220 Soc
use this I2C IP of Synopsys Designware for HiKey board.

Signed-off-by: Xinwei Kong 
Signed-off-by: Chen Feng 
---
  arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 34 +++
  1 file changed, 34 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 82d2488..8cec56a 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -208,5 +208,39 @@
clock-names = "uartclk", "apb_pclk";
status = "disabled";
};
+
+   i2c0: i2c@f710 {
+   compatible = "snps,designware-i2c";
+   reg = <0x0 0xf710 0x0 0x1000>;
+   interrupts = <0 44 4>;
+   clocks = <&sys_ctrl HI6220_I2C0_CLK>;
+   i2c-sda-hold-time-ns = <300>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c0_pmx_func &i2c0_cfg_func>;
+   status = "disabled";
+   };
+
+   i2c1: i2c@f7101000 {
+   compatible = "snps,designware-i2c";
+   reg = <0x0 0xf7101000 0x0 0x1000>;
+   clocks = <&sys_ctrl HI6220_I2C1_CLK>;
+   interrupts = <0 45 4>;
+   i2c-sda-hold-time-ns = <300>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c1_pmx_func &i2c1_cfg_func>;
+   status = "disabled";
+   };
+
+   i2c2: i2c@f7102000 {
+   compatible = "snps,designware-i2c";
+   reg = <0x0 0xf7102000 0x0 0x1000>;
+   clocks = <&sys_ctrl HI6220_I2C2_CLK>;
+   interrupts = <0 46 4>;
+   i2c-sda-hold-time-ns = <300>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c2_pmx_func &i2c2_cfg_func>;
+   status = "disabled";
+   };
+
};
  };


Looks good to me!

Reviewed-by: Bintian Wang


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

Re: [PATCH] ARM: dts: sun4i: Use red1 LED for heartbeat indication on Marsboard A10

[Aleksei Mamlin]

On Sun, 27 Dec 2015 21:51:51 +0100
Maxime Ripard  wrote:

> On Sat, Dec 26, 2015 at 12:57:59PM +0300, Aleksei Mamlin wrote:
> > Marsboard A10 have four red LEDs, the first one can be used for
> > heartbeat indication.
> > 
> > Signed-off-by: Aleksei Mamlin 
> 
> I'm really not sure about this one.
> 
> This is something that can easily be changed through sysfs, and it
> will likely end up being a "war" on what trigger people want to use.
> 

If so, then Ok, please ignore this patch.

Is there any way to set led triggers through cmdline instead of sysfs?

>
> Hans, Chen-Yu, What's your view on this?
> 
> Thanks,
> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com


-- 
Thanks and regards,
Aleksei Mamlin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] Re: [PATCH] ARM: dts: sun4i: Use red1 LED for heartbeat indication on Marsboard A10

[Chen-Yu Tsai]

On Tue, Dec 29, 2015 at 8:33 PM, Hans de Goede  wrote:
> Hi,
>
> On 27-12-15 21:51, Maxime Ripard wrote:
>>
>> On Sat, Dec 26, 2015 at 12:57:59PM +0300, Aleksei Mamlin wrote:
>>>
>>> Marsboard A10 have four red LEDs, the first one can be used for
>>> heartbeat indication.
>>>
>>> Signed-off-by: Aleksei Mamlin 
>>
>>
>> I'm really not sure about this one.
>>
>> This is something that can easily be changed through sysfs, and it
>> will likely end up being a "war" on what trigger people want to use.
>>
>> Hans, Chen-Yu, What's your view on this?
>
>
> I would prefer to not set any (default) led triggers in the dts
> files for sunxi boards.

+1

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

Re: [linux-sunxi] Re: [PATCH] ARM: dts: sun4i: Use red1 LED for heartbeat indication on Marsboard A10

[Hans de Goede]

Hi,

On 27-12-15 21:51, Maxime Ripard wrote:

On Sat, Dec 26, 2015 at 12:57:59PM +0300, Aleksei Mamlin wrote:

Marsboard A10 have four red LEDs, the first one can be used for
heartbeat indication.

Signed-off-by: Aleksei Mamlin 


I'm really not sure about this one.

This is something that can easily be changed through sysfs, and it
will likely end up being a "war" on what trigger people want to use.

Hans, Chen-Yu, What's your view on this?


I would prefer to not set any (default) led triggers in the dts
files for sunxi boards.

Regards,

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

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

[Paul Kocialkowski]

Hi Milo,

Le mardi 29 décembre 2015 à 09:45 +0900, Milo Kim a écrit :
> Hi Paul,
> 
> On 29/12/15 07:49, Paul Kocialkowski wrote:
> > Hi Milo, thanks for the review,
> >
> > Le lundi 28 décembre 2015 à 09:56 +0900, Milo Kim a écrit :
> >> Hi Paul,
> >>
> >> On 23/12/15 20:56, Mark Brown wrote:
> >>> On Wed, Dec 23, 2015 at 11:58:37AM +0100, Paul Kocialkowski wrote:
> >>>
>  +gpio = lp->pdata->enable_gpio;
>  +if (!gpio_is_valid(gpio))
>  +return 0;
>  +
>  +/* Always set enable GPIO high. */
>  +ret = devm_gpio_request_one(lp->dev, gpio, GPIOF_OUT_INIT_HIGH, 
>  "LP872X EN");
>  +if (ret) {
>  +dev_err(lp->dev, "gpio request err: %d\n", ret);
>  +return ret;
>  +}
> >>>
> >>> This isn't really adding support for the enable GPIO as the changelog
> >>> suggests, it's requesting but not managing the GPIO.  Since there is
> >>> core support for manging enable GPIOs this seems especially silly,
> >>> please tell the core about the GPIO and then it will work at runtime
> >>> too.
> >>>
> >>
> >> With reference to my previous mail, external GPIOs for LDO3 and BUCK2 in
> >> LP8725 can be specified through regulator_config.ena_gpio. BUCK2 only
> >> can be controlled by external pin when CONFIG pin is grounded.
> >>
> >> Please see the description at page 5 of the datasheet.
> >>
> >>http://www.ti.com/lit/ds/symlink/lp8725.pdf
> >
> > After reading the datasheets thoroughly, it seems to me that for the
> > lp8720, the EN pin is used to enable the regulators output, which is a
> > good fit for the core regulator GPIO framework, as there is no reason to
> > keep it on when no regulator is in use. The serial interface is already
> > available when EN=0 and regulators can be configured in that state. The
> > lp8725 seems seems to behave the same when CONFIG=0 (the datasheet
> > clearly states: "CONFIG=0: EN=1 turns on outputs or standby mode if
> > EN=0"). On the other hand, it is indeed used as a power-on pin when
> > CONFIG=1.
> 
> I think it's different use case. LP8720/5 are designed for system PMU, 
> so some regulators are enabled by default after the device is on. EN pin 
> is used for turning on/off the chip. This pin does not control regulator 
> outputs directly. It's separate functional block in the silicon.

Well, I really don't understand why the EN pin would turn on/off the
chip. All it does it enable the regulators outputs (by entering IDLE
mode), the serial block is already available in STANDBY state.

If we want some regulators enabled at boot, the best thing to do seems
to be to request the GPIO with the GPIOF_INIT_HIGH flag, as done in e.g.
the max8952 regulator driver:

if (pdata->reg_data->constraints.boot_on)
config.ena_gpio_flags |= GPIOF_OUT_INIT_HIGH;

> On the other hand, 'ena_gpio' is used for each regulator control itself.
> For example, WM8994 has two LDOs which are controlled by external pins. 
> LDOs are enabled/disabled through LDO1ENA and LDO2ENA pins. In this 
> case, 'ena_gpio' is used.

Of course, but the ena_gpio feature is also a good fit for a global
enable pin, as the GPIO can be shared by multiple regulators of the same
chip, which is what we have here.

In my opinion, using the ena_gpio feature is a good fit, as we don't
need to keep the EN pin high when no regulator is used.

>   http://www.cirrus.com/en/pubs/proDatasheet/WM8994_v4.4.pdf
>   (please refer to page 224 and 225)

Cheers,

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: https://www.replicant.us/
Blog: https://blog.replicant.us/
Wiki/tracker/forums: https://redmine.replicant.us/



signature.asc
Description: This is a digitally signed message part

[PATCH v8 4/4] arm64, dt, thunderx: Add initial dts for Cavium Thunderx in 2 node topology.

[Ganapatrao Kulkarni]

Adding dt file for Cavium's Thunderx dual socket platform.

Signed-off-by: Ganapatrao Kulkarni 
---
 arch/arm64/boot/dts/cavium/Makefile |   2 +-
 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts  |  83 +++
 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi | 806 
 3 files changed, 890 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts
 create mode 100644 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi

diff --git a/arch/arm64/boot/dts/cavium/Makefile 
b/arch/arm64/boot/dts/cavium/Makefile
index e34f89d..7fe7067 100644
--- a/arch/arm64/boot/dts/cavium/Makefile
+++ b/arch/arm64/boot/dts/cavium/Makefile
@@ -1,4 +1,4 @@
-dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb
+dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb thunder-88xx-2n.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts 
b/arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts
new file mode 100644
index 000..5601e87
--- /dev/null
+++ b/arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts
@@ -0,0 +1,83 @@
+/*
+ * Cavium Thunder DTS file - Thunder board description
+ *
+ * Copyright (C) 2014, Cavium Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this library; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+/include/ "thunder-88xx-2n.dtsi"
+
+/ {
+   model = "Cavium ThunderX CN88XX board";
+   compatible = "cavium,thunder-88xx";
+
+   aliases {
+   serial0 = &uaa0;
+   serial1 = &uaa1;
+   };
+
+   memory@ {
+   device_type = "memory";
+   reg = <0x0 0x0140 0x3 0xFEC0>;
+   /* socket 0 */
+   numa-node-id = <0>;
+   };
+
+   memory@100 {
+   device_type = "memory";
+   reg = <0x100 0x0040 0x3 0xFFC0>;
+/* socket 1 */
+   numa-node-id = <1>;
+   };
+
+   distance-map {
+   compatible = "numa-distance-map-v1";
+   distance-matrix = <0 0  10>,
+ <0 1  20>,
+ <1 1  10>;
+   };
+};
diff --git a/arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi 
b/arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi
new file mode 100644
index 000..b58e5c7
--- /dev/null
+++ b/arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi
@@ -0,0 +1,806 @@
+/*
+ * Cavium Thunder DTS file - Thunder SoC description
+ *
+ * Copyright (C) 2014, Cavium Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Genera

[PATCH v8 3/4] arm64/arm, numa, dt: adding numa dt binding implementation for arm64 platforms.

[Ganapatrao Kulkarni]

Adding numa dt binding support for arm64 based platforms.
dt node parsing for numa topology is done using device property
numa-node-id and device node distance-map.

Reviewed-by: Robert Richter 
Signed-off-by: Ganapatrao Kulkarni 
---
 arch/arm64/Kconfig|  10 ++
 arch/arm64/include/asm/numa.h |  10 ++
 arch/arm64/kernel/Makefile|   1 +
 arch/arm64/kernel/of_numa.c   | 265 ++
 arch/arm64/kernel/smp.c   |   2 +
 arch/arm64/mm/numa.c  |  10 +-
 6 files changed, 297 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/kernel/of_numa.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 74f5d73..775cf4a 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -515,6 +515,16 @@ config NUMA
  local memory of the CPU and add some more
  NUMA awareness to the kernel.
 
+config OF_NUMA
+   bool "Device Tree NUMA support"
+   depends on NUMA
+   depends on OF
+   default y
+   help
+ Enable Device Tree NUMA support.
+ This enables the numa mapping of cpu, memory, io and
+ inter node distances using dt bindings.
+
 config NODES_SHIFT
int "Maximum NUMA Nodes (as a power of 2)"
range 1 10
diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index 6efc85c..dd16639 100644
--- a/arch/arm64/include/asm/numa.h
+++ b/arch/arm64/include/asm/numa.h
@@ -43,4 +43,14 @@ void numa_store_cpu_info(unsigned int cpu);
 static inline void numa_store_cpu_info(unsigned int cpu)   { }
 static inline void arm64_numa_init(void)   { }
 #endif /* CONFIG_NUMA */
+
+struct device_node;
+#ifdef CONFIG_OF_NUMA
+int __init arm64_of_numa_init(void);
+void __init of_numa_set_node_info(unsigned int cpu, struct device_node *dn);
+#else
+static inline void of_numa_set_node_info(unsigned int cpu,
+   struct device_node *dn) { }
+#endif
+
 #endif /* __ASM_NUMA_H */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 474691f..7987763 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -41,6 +41,7 @@ arm64-obj-$(CONFIG_EFI)   += efi.o 
efi-entry.stub.o
 arm64-obj-$(CONFIG_PCI)+= pci.o
 arm64-obj-$(CONFIG_ARMV8_DEPRECATED)   += armv8_deprecated.o
 arm64-obj-$(CONFIG_ACPI)   += acpi.o
+arm64-obj-$(CONFIG_OF_NUMA)+= of_numa.o
 
 obj-y  += $(arm64-obj-y) vdso/
 obj-m  += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/of_numa.c b/arch/arm64/kernel/of_numa.c
new file mode 100644
index 000..40b1ce52
--- /dev/null
+++ b/arch/arm64/kernel/of_numa.c
@@ -0,0 +1,265 @@
+/*
+ * OF NUMA Parsing support.
+ *
+ * Copyright (C) 2015 Cavium Inc.
+ * Author: Ganapatrao Kulkarni 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* define default numa node to 0 */
+#define DEFAULT_NODE 0
+#define OF_NUMA_PROP "numa-node-id"
+
+/* Returns nid in the range [0..MAX_NUMNODES-1],
+ * or NUMA_NO_NODE if no valid numa-node-id entry found
+ * or DEFAULT_NODE if no numa-node-id entry exists
+ */
+static int of_numa_prop_to_nid(const __be32 *of_numa_prop, int length)
+{
+   int nid;
+
+   if (!of_numa_prop)
+   return DEFAULT_NODE;
+
+   if (length != sizeof(*of_numa_prop)) {
+   pr_warn("NUMA: Invalid of_numa_prop length %d found.\n",
+   length);
+   return NUMA_NO_NODE;
+   }
+
+   nid = of_read_number(of_numa_prop, 1);
+   if (nid >= MAX_NUMNODES) {
+   pr_warn("NUMA: Invalid numa node %d found.\n", nid);
+   return NUMA_NO_NODE;
+   }
+
+   return nid;
+}
+
+/* Must hold reference to node during call */
+static int of_get_numa_nid(struct device_node *device)
+{
+   int length;
+   const __be32 *of_numa_prop;
+
+   of_numa_prop = of_get_property(device, OF_NUMA_PROP, &length);
+
+   return of_numa_prop_to_nid(of_numa_prop, length);
+}
+
+static int __init early_init_of_get_numa_nid(unsigned long node)
+{
+   int length;
+   const __be32 *of_numa_prop;
+
+   of_numa_prop = of_get_flat_dt_prop(node, OF_NUMA_PROP, &length);
+
+   return of_numa_prop_to_nid(of_numa_prop, length);
+}
+
+/* Walk the device tree upwards, lo

[PATCH v8 1/4] arm64, numa: adding numa support for arm64 platforms.

[Ganapatrao Kulkarni]

Adding numa support for arm64 based platforms.
This patch adds by default the dummy numa node and
maps all memory and cpus to node 0.
using this patch, numa can be simulated on single node arm64 platforms.

Tested-by: Shannon Zhao 
Reviewed-by: Robert Richter 
Signed-off-by: Ganapatrao Kulkarni 
---
 arch/arm64/Kconfig  |  25 +++
 arch/arm64/include/asm/mmzone.h |  18 ++
 arch/arm64/include/asm/numa.h   |  46 +
 arch/arm64/kernel/pci.c |   9 +
 arch/arm64/kernel/setup.c   |   4 +
 arch/arm64/kernel/smp.c |   2 +
 arch/arm64/mm/Makefile  |   1 +
 arch/arm64/mm/init.c|  31 +++-
 arch/arm64/mm/mmu.c |   1 +
 arch/arm64/mm/numa.c| 387 
 10 files changed, 519 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm64/include/asm/mmzone.h
 create mode 100644 arch/arm64/include/asm/numa.h
 create mode 100644 arch/arm64/mm/numa.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 871f217..74f5d73 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -71,6 +71,7 @@ config ARM64
select HAVE_GENERIC_DMA_COHERENT
select HAVE_HW_BREAKPOINT if PERF_EVENTS
select HAVE_MEMBLOCK
+   select HAVE_MEMBLOCK_NODE_MAP if NUMA
select HAVE_PATA_PLATFORM
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
@@ -503,6 +504,30 @@ config HOTPLUG_CPU
  Say Y here to experiment with turning CPUs off and on.  CPUs
  can be controlled through /sys/devices/system/cpu.
 
+# Common NUMA Features
+config NUMA
+   bool "Numa Memory Allocation and Scheduler Support"
+   depends on SMP
+   help
+ Enable NUMA (Non Uniform Memory Access) support.
+
+ The kernel will try to allocate memory used by a CPU on the
+ local memory of the CPU and add some more
+ NUMA awareness to the kernel.
+
+config NODES_SHIFT
+   int "Maximum NUMA Nodes (as a power of 2)"
+   range 1 10
+   default "2"
+   depends on NEED_MULTIPLE_NODES
+   help
+ Specify the maximum number of NUMA Nodes available on the target
+ system.  Increases memory reserved to accommodate various tables.
+
+config USE_PERCPU_NUMA_NODE_ID
+   def_bool y
+   depends on NUMA
+
 source kernel/Kconfig.preempt
 source kernel/Kconfig.hz
 
diff --git a/arch/arm64/include/asm/mmzone.h b/arch/arm64/include/asm/mmzone.h
new file mode 100644
index 000..2cd804d
--- /dev/null
+++ b/arch/arm64/include/asm/mmzone.h
@@ -0,0 +1,18 @@
+#ifndef __ASM_MMZONE_H
+#define __ASM_MMZONE_H
+
+#ifdef CONFIG_NUMA
+
+#include 
+#include 
+
+#include 
+#include 
+
+extern struct pglist_data *node_data[];
+
+#define NODE_DATA(nid) (node_data[(nid)])
+
+#endif /* CONFIG_NUMA */
+
+#endif /* __ASM_MMZONE_H */
diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
new file mode 100644
index 000..6efc85c
--- /dev/null
+++ b/arch/arm64/include/asm/numa.h
@@ -0,0 +1,46 @@
+#ifndef __ASM_NUMA_H
+#define __ASM_NUMA_H
+
+#include 
+#include 
+
+#ifdef CONFIG_NUMA
+
+/* currently, arm64 implements flat NUMA topology */
+#define parent_node(node)  (node)
+
+extern int __node_distance(int from, int to);
+#define node_distance(a, b) __node_distance(a, b)
+
+struct pci_bus;
+int pcibus_to_node(struct pci_bus *bus);
+#define cpumask_of_pcibus(bus) (pcibus_to_node(bus) == -1 ?\
+cpu_all_mask : \
+cpumask_of_node(pcibus_to_node(bus)))
+
+extern int cpu_to_node_map[NR_CPUS];
+extern nodemask_t numa_nodes_parsed __initdata;
+
+/* Mappings between node number and cpus on that node. */
+extern cpumask_var_t node_to_cpumask_map[MAX_NUMNODES];
+extern void numa_clear_node(unsigned int cpu);
+#ifdef CONFIG_DEBUG_PER_CPU_MAPS
+extern const struct cpumask *cpumask_of_node(int node);
+#else
+/* Returns a pointer to the cpumask of CPUs on Node 'node'. */
+static inline const struct cpumask *cpumask_of_node(int node)
+{
+   return node_to_cpumask_map[node];
+}
+#endif
+
+void __init arm64_numa_init(void);
+int __init numa_add_memblk(int nodeid, u64 start, u64 end);
+void __init numa_set_distance(int from, int to, int distance);
+void __init numa_reset_distance(void);
+void numa_store_cpu_info(unsigned int cpu);
+#else  /* CONFIG_NUMA */
+static inline void numa_store_cpu_info(unsigned int cpu)   { }
+static inline void arm64_numa_init(void)   { }
+#endif /* CONFIG_NUMA */
+#endif /* __ASM_NUMA_H */
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index b3d098b..13a619e 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -84,3 +84,12 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root 
*root)
return NULL;
 }
 #endif
+
+#ifdef CONFIG_NUMA
+int pcibus_to_node(struct pci_bus *bus)
+{
+   return dev_to_node(&bus->dev);
+}
+EXPORT_SYMBOL(pcibus_to_node);
+#endif
+
d

[PATCH v8 0/4] arm64, numa: Add numa support for arm64 platforms

[Ganapatrao Kulkarni]

v8:
- Incorporated review comments of Mark Rutland and Will Deacon.
- Added pci helper function and macro for numa.

v7:
- managing numa memory mapping using memblock.
- Incorporated review comments of Mark Rutland.

v6:
- defined and implemented the numa dt binding using
node property proximity and device node distance-map.
- renamed dt_numa to of_numa

v5:
- created base verion of numa.c which creates dummy numa without using 
dt
  on single socket platforms. Then added patches for dt support.
- Incorporated review comments from Hanjun Guo.

v4:
done changes as per Arnd review comments.

v3:
Added changes to support numa on arm64 based platforms.
Tested these patches on cavium's multinode(2 node topology) platform.
In this patchset, defined and implemented dt bindings for numa mapping
for core and memory using device node property arm,associativity.

v2:
Defined and implemented numa map for memory, cores to node and
proximity distance matrix of nodes.

v1:
Initial patchset to support numa on arm64 platforms.

Note:
1. This patchset is tested for numa with dt on
   thunderx single socket and dual socket boards.
2. Numa DT booting needs the dt memory nodes, which are deleted in 
current efi-stub,
hence to try numa with dt, you need to rebase with ard's patchset.

http://git.linaro.org/people/ard.biesheuvel/linux-arm.git/shortlog/refs/heads/arm64-uefi-early-fdt-handling

Ganapatrao Kulkarni (4):
  arm64, numa: adding numa support for arm64 platforms.
  Documentation, dt, arm64/arm: dt bindings for numa.
  arm64/arm, numa, dt: adding numa dt binding implementation for arm64
platforms.
  arm64, dt, thunderx: Add initial dts for Cavium Thunderx in 2 node
topology.

 Documentation/devicetree/bindings/arm/numa.txt  | 272 
 arch/arm64/Kconfig  |  35 +
 arch/arm64/boot/dts/cavium/Makefile |   2 +-
 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts  |  83 +++
 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi | 806 
 arch/arm64/include/asm/mmzone.h |  18 +
 arch/arm64/include/asm/numa.h   |  56 ++
 arch/arm64/kernel/Makefile  |   1 +
 arch/arm64/kernel/of_numa.c | 265 
 arch/arm64/kernel/pci.c |   9 +
 arch/arm64/kernel/setup.c   |   4 +
 arch/arm64/kernel/smp.c |   4 +
 arch/arm64/mm/Makefile  |   1 +
 arch/arm64/mm/init.c|  31 +-
 arch/arm64/mm/mmu.c |   1 +
 arch/arm64/mm/numa.c| 395 
 16 files changed, 1977 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/numa.txt
 create mode 100644 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts
 create mode 100644 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi
 create mode 100644 arch/arm64/include/asm/mmzone.h
 create mode 100644 arch/arm64/include/asm/numa.h
 create mode 100644 arch/arm64/kernel/of_numa.c
 create mode 100644 arch/arm64/mm/numa.c

-- 
1.8.1.4

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

[PATCH v8 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

[Ganapatrao Kulkarni]

DT bindings for numa mapping of memory, cores and IOs.

Reviewed-by: Robert Richter 
Signed-off-by: Ganapatrao Kulkarni 
---
 Documentation/devicetree/bindings/arm/numa.txt | 272 +
 1 file changed, 272 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/numa.txt

diff --git a/Documentation/devicetree/bindings/arm/numa.txt 
b/Documentation/devicetree/bindings/arm/numa.txt
new file mode 100644
index 000..ee413150
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/numa.txt
@@ -0,0 +1,272 @@
+==
+NUMA binding description.
+==
+
+==
+1 - Introduction
+==
+
+Systems employing a Non Uniform Memory Access (NUMA) architecture contain
+collections of hardware resources including processors, memory, and I/O buses,
+that comprise what is commonly known as a NUMA node.
+Processor accesses to memory within the local NUMA node is generally faster
+than processor accesses to memory outside of the local NUMA node.
+DT defines interfaces that allow the platform to convey NUMA node
+topology information to OS.
+
+==
+2 - numa-node-id
+==
+
+For the purpose of identification, each NUMA node is associated with a unique
+token known as a node id. For the purpose of this binding
+a node id is a 32-bit integer.
+
+A device node is associated with a NUMA node by the presence of a
+numa-node-id property which contains the node id of the device.
+
+Example:
+   /* numa node 0 */
+   numa-node-id = <0>;
+
+   /* numa node 1 */
+   numa-node-id = <1>;
+
+==
+3 - distance-map
+==
+
+The device tree node distance-map describes the relative
+distance(memory latency) between all numa nodes.
+
+- compatible : Should at least contain "numa-distance-map-v1".
+
+- distance-matrix
+  This property defines a matrix to describe the relative distances
+  between all numa nodes.
+  It is represented as a list of node pairs and their relative distance.
+
+  Note:
+   1. Each entry represents distance from first node to second node.
+   The distance are equal in either direction.
+   2. The distance from a node to self(local distance) is represented
+   with value 10 and all inter node distance should be represented with
+   value greater than 10.
+   3. distance-matrix shold have entries in lexicographical ascending
+   order of nodes.
+   4. There must be only one Device node distance-map and must reside in 
the root node.
+
+Example:
+   4 nodes connected in mesh/ring topology as below,
+
+   0___20__1
+   |   |
+   |   |
+   20 20
+   |   |
+   |   |
+   |___|
+   3   20  2
+
+   if relative distance for each hop is 20,
+   then inter node distance would be,
+ 0 -> 1 = 20
+ 1 -> 2 = 20
+ 2 -> 3 = 20
+ 3 -> 0 = 20
+ 0 -> 2 = 40
+ 1 -> 3 = 40
+
+ and dt presentation for this distance matrix is,
+
+   distance-map {
+compatible = "numa-distance-map-v1";
+distance-matrix = <0 0  10>,
+  <0 1  20>,
+  <0 2  40>,
+  <0 3  20>,
+  <1 0  20>,
+  <1 1  10>,
+  <1 2  20>,
+  <1 3  40>,
+  <2 0  40>,
+  <2 1  20>,
+  <2 2  10>,
+  <2 3  20>,
+  <3 0  20>,
+  <3 1  40>,
+  <3 2  20>,
+  <3 3  10>;
+   };
+
+==
+4 - Example dts
+==
+
+2 sockets system consists of 2 boards connected through ccn bus and
+each board having one socket/soc of 8 cpus, memory and pci bus.
+
+   memory@00c0

Re: [PATCH v2 3/3] [media] mt9v032: Add V4L2 controls for AEC and AGC

[Laurent Pinchart]

Hi Markus,

On Wednesday 16 December 2015 11:14:28 Markus Pargmann wrote:
> On Wednesday 16 December 2015 09:47:58 Laurent Pinchart wrote:
> > On Monday 14 December 2015 15:41:53 Markus Pargmann wrote:
> >> This patch adds V4L2 controls for Auto Exposure Control and Auto Gain
> >> Control settings. These settings include low pass filter, update
> >> frequency of these settings and the update interval for those units.
> >> 
> >> Signed-off-by: Markus Pargmann 
> > 
> > Please see below for a few comments. If you agree about them there's no
> > need to resubmit, I'll fix the patch when applying.
> 
> Most of them are fine, I commented on the open ones.
> 
> >> ---
> >> 
> >>  drivers/media/i2c/mt9v032.c | 153 -
> >>  1 file changed, 152 insertions(+), 1 deletion(-)
> >> 
> >> diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c
> >> index cc16acf001de..6cbc3b87eda9 100644
> >> --- a/drivers/media/i2c/mt9v032.c
> >> +++ b/drivers/media/i2c/mt9v032.c

[snip]

> >> +static const struct v4l2_ctrl_config mt9v032_aec_max_shutter_width = {
> >> +  .ops= &mt9v032_ctrl_ops,
> >> +  .id = V4L2_CID_AEC_MAX_SHUTTER_WIDTH,
> >> +  .type   = V4L2_CTRL_TYPE_INTEGER,
> >> +  .name   = "aec_max_shutter_width",
> >> +  .min= 1,
> >> +  .max= MT9V032_TOTAL_SHUTTER_WIDTH_MAX,
> > 
> > According the the MT9V032 datasheet I have, the maximum value is 2047
> > while MT9V032_TOTAL_SHUTTER_WIDTH_MAX is defined as 32767. Do you have any
> > information that would hint for an error in the datasheet ?
> 
> The register is defined as having 15 bits. I simply assumed that the already
> defined TOTAL_SHUTTER_WIDTH_MAX would apply for this register as well. At
> least it should end up controlling the same property of the chip. I didn't
> test this on mt9v032 but on mt9v024.

According to the MT9V032 datasheet 
(http://www.onsemi.com/pub/Collateral/MT9V032-D.PDF) the maximum shutter width 
in AEC mode is limited to 2047. That is documented both in the Maximum Total 
Shutter Width register legal values and in the "Automatic Gain Control and 
Automatic Exposure Control" section:

"The exposure is measured in row-time by reading R0xBB. The exposure range is
1 to 2047."

I assume that the the AEC unit limits the shutter width to 2047 lines and that 
it's thus pointless to set the maximum total shutter width to a higher value. 
Whether doing so could have any adverse effect I don't know, but better be 
same than sorry. If you agree we should limit the value to 2047 I can fix 
this.

> >> +  .step   = 1,
> >> +  .def= MT9V032_TOTAL_SHUTTER_WIDTH_DEF,
> >> +  .flags  = 0,
> >> +};
> >> +
> >> +static const struct v4l2_ctrl_config mt9v034_aec_max_shutter_width = {
> >> +  .ops= &mt9v032_ctrl_ops,
> >> +  .id = V4L2_CID_AEC_MAX_SHUTTER_WIDTH,
> >> +  .type   = V4L2_CTRL_TYPE_INTEGER,
> >> +  .name   = "aec_max_shutter_width",
> >> +  .min= 1,
> >> +  .max= MT9V034_TOTAL_SHUTTER_WIDTH_MAX,
> >> +  .step   = 1,
> >> +  .def= MT9V032_TOTAL_SHUTTER_WIDTH_DEF,
> >> +  .flags  = 0,
> >> +};
> > 
> > [snip]

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v7 06/14] drm/mediatek: Add HDMI support

[Yingjoe Chen]

On Mon, 2015-11-30 at 22:07 +0100, Philipp Zabel wrote:
> From: Jie Qiu 
> 
> This patch adds drivers for the HDMI bridge connected to the DPI0
> display subsystem function block, for the HDMI DDC block, and for
> the HDMI PHY to support HDMI output.
> 
> Signed-off-by: Jie Qiu 
> Signed-off-by: Philipp Zabel 
> ---
<...>
> +static int mtk_hdmi_setup_avi_infoframe(struct mtk_hdmi *hdmi,
> + struct drm_display_mode *mode)
> +{
> + struct hdmi_avi_infoframe frame;
> + u8 buffer[17];
> + ssize_t err;
> +
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + if (err < 0) {
> + dev_err(hdmi->dev,
> + "Failed to get AVI infoframe from mode: %ld\n", err);

Please use %zd instead for ssize_t, otherwise you'll see warning message
when compile this on 32bits platform.

Joe.C


> + return err;
> + }
> +
> + err = hdmi_avi_infoframe_pack(&frame, buffer, sizeof(buffer));
> + if (err < 0) {
> + dev_err(hdmi->dev, "Failed to pack AVI infoframe: %ld\n", err);
> + return err;
> + }
> +
> + mtk_hdmi_hw_send_info_frame(hdmi, buffer, sizeof(buffer));
> + return 0;
> +}
> +

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

[PATCH V3 1/1] arm64: dts: add Hi6220 spi configuration nodes

[Zhong Kaihua]

arm64: dts: add Hi6220 spi configuration nodes

Signed-off-by: Zhong Kaihua 
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts |  1 +
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  | 20 
 2 files changed, 21 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts 
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index 4fb0bdc..2313ae0 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -23,6 +23,7 @@
serial1 = &uart1; /* BT UART */
serial2 = &uart2; /* LS Expansion UART0 */
serial3 = &uart3; /* LS Expansion UART1 */
+   spi0 = &spi_0;
};
 
chosen {
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 0f11e2a..da0fe37 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -489,5 +489,25 @@
clock-names = "apb_pclk";
status = "ok";
};
+
+   spi_0: spi@f7106000 {
+   compatible = "arm,pl022", "arm,primecell";
+   reg = <0x0 0xf7106000 0x0 0x1000>;
+   interrupts = <0 50 4>;
+   bus-id = <0>;
+   enable-dma = <0>;
+   /*dmas = <&dma0 12 &dma0 13>;*/
+   /*dma-names = "rx", "tx";*/
+
+   clocks = <&sys_ctrl HI6220_SPI_CLK>;
+   clock-names = "apb_pclk";
+   pinctrl-names = "default";
+   pinctrl-0 = <&spi0_pmx_func &spi0_cfg_func>;
+   num-cs = <1>;
+   cs-gpios = <&gpio6 2 0>;
+
+   status = "ok";
+   };
+
};
 };
-- 
1.9.1

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

Re: [RESEND v4 0/6] remoteproc: Add driver for STMicroelectronics platforms

[Ohad Ben-Cohen]

On Mon, Dec 28, 2015 at 8:41 PM, Bjorn Andersson  wrote:
> I interpreted this as you picked patch 1-4 and didn't pay more
> attention to them, but I can't find them in your kernel.org trees. So
> I've looked through them again.
>
> Please apply patch 1, 3 and 4 to your tree Ohad. I was unable to find
> a v5 of patch 2, but it's unrelated so no need to wait for a new
> version of that.

I was under the impression that Lee plans to resubmit once the
discussion around patch 2 settles, so I haven't picked the series yet.

Lee please let me know - I can take 1/3/4 and wait for the new 2 as well.

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