Re: [PATCH v3] regulator, dt: add dt support for tps6502x regulator

[Heiko Schocher]

Hello Mark,

Am 27.10.2015 um 03:12 schrieb Mark Brown:

On Mon, Oct 26, 2015 at 12:25:17PM +0100, Heiko Schocher wrote:

add DT support for the tps6502x regulators.


Please use subject lines matching the style for the subsystem.


Would be "regulator: tps6520x:" correct?


+   regulators = of_get_child_by_name(np, "regulators");
+   if (!regulators) {
+   dev_err(dev, "regulator node not found\n");
+   return NULL;
+   }


Please use the generic support for locating the DT information for
regulators using regulators_node and of_match in the regulator_desc
rather than open coding this.


Hmm.. could you point me to a correct example? Seems I overlook sth.

drivers/regulator/tps65090-regulator.c
drivers/regulator/tps65910-regulator.c
drivers/regulator/tps6507x-regulator.c
drivers/regulator/tps6586x-regulator.c

are doing it all the same way ...

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
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 02/10] mmc: dt-bindings: update Mediatek MMC bindings

[Chaotian Jing]

Add 400Mhz clock source for HS400 mode

Signed-off-by: Chaotian Jing 
---
 Documentation/devicetree/bindings/mmc/mtk-sd.txt | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt 
b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
index a1adfa4..0120c7f 100644
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
@@ -17,6 +17,11 @@ Required properties:
 - vmmc-supply: power to the Core
 - vqmmc-supply: power to the IO
 
+Optional properties:
+- assigned-clocks: PLL of the source clock
+- assigned-clock-parents: parent of source clock, used for HS400 mode to get 
400Mhz source clock
+- hs400-ds-delay: HS400 DS delay setting
+
 Examples:
 mmc0: mmc@1123 {
compatible = "mediatek,mt8173-mmc", "mediatek,mt8135-mmc";
@@ -24,9 +29,13 @@ mmc0: mmc@1123 {
interrupts = ;
vmmc-supply = <_vemc_3v3_reg>;
vqmmc-supply = <_vio18_reg>;
-   clocks = < CLK_PERI_MSDC30_0>, < 
CLK_TOP_MSDC50_0_H_SEL>;
+   clocks = < CLK_PERI_MSDC30_0>,
+< CLK_TOP_MSDC50_0_H_SEL>;
clock-names = "source", "hclk";
pinctrl-names = "default", "state_uhs";
pinctrl-0 = <_pins_default>;
pinctrl-1 = <_pins_uhs>;
+   assigned-clocks = < CLK_TOP_MSDC50_0_SEL>;
+   assigned-clock-parents = < CLK_TOP_MSDCPLL_D2>;
+   hs400-ds-delay = <0x14015>;
 };
-- 
1.8.1.1.dirty

--
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 05/10] mmc: mediatek: fix got GPD checksum error interrupt when data transfer

[Chaotian Jing]

Even if we only use one gpd, we need alloc 2 gpd and make
the gpd->next pointer to the second gpd, or may get gpd checksum
error, this was checked by hardware

Signed-off-by: Chaotian Jing 
---
 drivers/mmc/host/mtk-sd.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index c877ded..3858163 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -1145,11 +1145,14 @@ static void msdc_init_gpd_bd(struct msdc_host *host, 
struct msdc_dma *dma)
struct mt_bdma_desc *bd = dma->bd;
int i;
 
-   memset(gpd, 0, sizeof(struct mt_gpdma_desc));
+   memset(gpd, 0, sizeof(struct mt_gpdma_desc) * 2);
 
gpd->gpd_info = GPDMA_DESC_BDP; /* hwo, cs, bd pointer */
gpd->ptr = (u32)dma->bd_addr; /* physical address */
-
+   /* gpd->next is must set for desc DMA
+* That's why must alloc 2 gpd structure.
+*/
+   gpd->next = (u32)dma->gpd_addr + sizeof(struct mt_gpdma_desc);
memset(bd, 0, sizeof(struct mt_bdma_desc) * MAX_BD_NUM);
for (i = 0; i < (MAX_BD_NUM - 1); i++)
bd[i].next = (u32)dma->bd_addr + sizeof(*bd) * (i + 1);
@@ -1306,7 +1309,7 @@ static int msdc_drv_probe(struct platform_device *pdev)
 
host->timeout_clks = 3 * 1048576;
host->dma.gpd = dma_alloc_coherent(>dev,
-   sizeof(struct mt_gpdma_desc),
+   2 * sizeof(struct mt_gpdma_desc),
>dma.gpd_addr, GFP_KERNEL);
host->dma.bd = dma_alloc_coherent(>dev,
MAX_BD_NUM * sizeof(struct mt_bdma_desc),
@@ -1347,7 +1350,7 @@ release:
 release_mem:
if (host->dma.gpd)
dma_free_coherent(>dev,
-   sizeof(struct mt_gpdma_desc),
+   2 * sizeof(struct mt_gpdma_desc),
host->dma.gpd, host->dma.gpd_addr);
if (host->dma.bd)
dma_free_coherent(>dev,
-- 
1.8.1.1.dirty

--
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 03/10] mmc: mediatek: make cmd_ints_mask to const

[Chaotian Jing]

cmd_ints_mask and data_ints_mask are constant value,
so make it to const

Signed-off-by: Chaotian Jing 
---
 drivers/mmc/host/mtk-sd.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index b2e89d3..8b3e15d 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -353,7 +353,10 @@ static void msdc_reset_hw(struct msdc_host *host)
 static void msdc_cmd_next(struct msdc_host *host,
struct mmc_request *mrq, struct mmc_command *cmd);
 
-static u32 data_ints_mask = MSDC_INTEN_XFER_COMPL | MSDC_INTEN_DATTMO |
+static const u32 cmd_ints_mask = MSDC_INTEN_CMDRDY | MSDC_INTEN_RSPCRCERR |
+   MSDC_INTEN_CMDTMO | MSDC_INTEN_ACMDRDY |
+   MSDC_INTEN_ACMDCRCERR | MSDC_INTEN_ACMDTMO;
+static const u32 data_ints_mask = MSDC_INTEN_XFER_COMPL | MSDC_INTEN_DATTMO |
MSDC_INTEN_DATCRCERR | MSDC_INTEN_DMA_BDCSERR |
MSDC_INTEN_DMA_GPDCSERR | MSDC_INTEN_DMA_PROTECT;
 
@@ -725,10 +728,7 @@ static bool msdc_cmd_done(struct msdc_host *host, int 
events,
if (done)
return true;
 
-   sdr_clr_bits(host->base + MSDC_INTEN, MSDC_INTEN_CMDRDY |
-   MSDC_INTEN_RSPCRCERR | MSDC_INTEN_CMDTMO |
-   MSDC_INTEN_ACMDRDY | MSDC_INTEN_ACMDCRCERR |
-   MSDC_INTEN_ACMDTMO);
+   sdr_clr_bits(host->base + MSDC_INTEN, cmd_ints_mask);
 
if (cmd->flags & MMC_RSP_PRESENT) {
if (cmd->flags & MMC_RSP_136) {
@@ -818,10 +818,7 @@ static void msdc_start_command(struct msdc_host *host,
rawcmd = msdc_cmd_prepare_raw_cmd(host, mrq, cmd);
mod_delayed_work(system_wq, >req_timeout, DAT_TIMEOUT);
 
-   sdr_set_bits(host->base + MSDC_INTEN, MSDC_INTEN_CMDRDY |
-   MSDC_INTEN_RSPCRCERR | MSDC_INTEN_CMDTMO |
-   MSDC_INTEN_ACMDRDY | MSDC_INTEN_ACMDCRCERR |
-   MSDC_INTEN_ACMDTMO);
+   sdr_set_bits(host->base + MSDC_INTEN, cmd_ints_mask);
writel(cmd->arg, host->base + SDC_ARG);
writel(rawcmd, host->base + SDC_CMD);
 }
-- 
1.8.1.1.dirty

--
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 04/10] mmc: mediatek: change the argument "ddr" to "timing"

[Chaotian Jing]

use the ios->timing directly is better
It can reflect current timing and do settings by timing

Signed-off-by: Chaotian Jing 
---
 drivers/mmc/host/mtk-sd.c | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 8b3e15d..c877ded 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -297,7 +297,7 @@ struct msdc_host {
u32 mclk;   /* mmc subsystem clock frequency */
u32 src_clk_freq;   /* source clock frequency */
u32 sclk;   /* SD/MS bus clock frequency */
-   bool ddr;
+   unsigned char timing;
bool vqmmc_enabled;
struct msdc_save_para save_para; /* used when gate HCLK */
 };
@@ -488,7 +488,7 @@ static void msdc_ungate_clock(struct msdc_host *host)
cpu_relax();
 }
 
-static void msdc_set_mclk(struct msdc_host *host, int ddr, u32 hz)
+static void msdc_set_mclk(struct msdc_host *host, unsigned char timing, u32 hz)
 {
u32 mode;
u32 flags;
@@ -504,7 +504,8 @@ static void msdc_set_mclk(struct msdc_host *host, int ddr, 
u32 hz)
 
flags = readl(host->base + MSDC_INTEN);
sdr_clr_bits(host->base + MSDC_INTEN, flags);
-   if (ddr) { /* may need to modify later */
+   if (timing == MMC_TIMING_UHS_DDR50 ||
+   timing == MMC_TIMING_MMC_DDR52) {
mode = 0x2; /* ddr mode and use divisor */
if (hz >= (host->src_clk_freq >> 2)) {
div = 0; /* mean div = 1/4 */
@@ -535,12 +536,12 @@ static void msdc_set_mclk(struct msdc_host *host, int 
ddr, u32 hz)
cpu_relax();
host->sclk = sclk;
host->mclk = hz;
-   host->ddr = ddr;
+   host->timing = timing;
/* need because clk changed. */
msdc_set_timeout(host, host->timeout_ns, host->timeout_clks);
sdr_set_bits(host->base + MSDC_INTEN, flags);
 
-   dev_dbg(host->dev, "sclk: %d, ddr: %d\n", host->sclk, ddr);
+   dev_dbg(host->dev, "sclk: %d, timing: %d\n", host->sclk, timing);
 }
 
 static inline u32 msdc_cmd_find_resp(struct msdc_host *host,
@@ -1158,14 +1159,9 @@ static void msdc_ops_set_ios(struct mmc_host *mmc, 
struct mmc_ios *ios)
 {
struct msdc_host *host = mmc_priv(mmc);
int ret;
-   u32 ddr = 0;
 
pm_runtime_get_sync(host->dev);
 
-   if (ios->timing == MMC_TIMING_UHS_DDR50 ||
-   ios->timing == MMC_TIMING_MMC_DDR52)
-   ddr = 1;
-
msdc_set_buswidth(host, ios->bus_width);
 
/* Suspend/Resume will do power off/on */
@@ -1202,8 +1198,8 @@ static void msdc_ops_set_ios(struct mmc_host *mmc, struct 
mmc_ios *ios)
break;
}
 
-   if (host->mclk != ios->clock || host->ddr != ddr)
-   msdc_set_mclk(host, ddr, ios->clock);
+   if (host->mclk != ios->clock || host->timing != ios->timing)
+   msdc_set_mclk(host, ios->timing, ios->clock);
 
 end:
pm_runtime_mark_last_busy(host->dev);
-- 
1.8.1.1.dirty

--
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

[v2 01/10] ata: ahci_brcmstb: add quick for broken ncq

[Jaedon Shin]

Add quick for bronken ncq. The chipsets (eg. BCM7439A0, BCM7445A0 and
BCM7445B0) need a workaround disabling NCQ. and it may need the
MIPS-based set-top box platforms.

Signed-off-by: Jaedon Shin 
---
 .../devicetree/bindings/ata/brcm,sata-brcmstb.txt  |  3 ++
 drivers/ata/ahci_brcmstb.c | 42 ++
 2 files changed, 45 insertions(+)

diff --git a/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt 
b/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt
index 20ac9bbfa1fd..4650c0aff6b3 100644
--- a/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt
+++ b/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt
@@ -10,6 +10,9 @@ Required properties:
 - reg-names  : "ahci" and "top-ctrl"
 - interrupts : interrupt mapping for SATA IRQ
 
+Optional properties:
+- brcm,broken-ncq: if present, NCQ is unusable
+
 Also see ahci-platform.txt.
 
 Example:
diff --git a/drivers/ata/ahci_brcmstb.c b/drivers/ata/ahci_brcmstb.c
index 14b7305d2ba0..a2df76698adb 100644
--- a/drivers/ata/ahci_brcmstb.c
+++ b/drivers/ata/ahci_brcmstb.c
@@ -69,10 +69,15 @@
(DATA_ENDIAN << DMADESC_ENDIAN_SHIFT) | \
(MMIO_ENDIAN << MMIO_ENDIAN_SHIFT))
 
+enum brcm_ahci_quicks {
+   BRCM_AHCI_QUICK_NONCQ   = BIT(0),
+};
+
 struct brcm_ahci_priv {
struct device *dev;
void __iomem *top_ctrl;
u32 port_mask;
+   u32 quicks;
 };
 
 static const struct ata_port_info ahci_brcm_port_info = {
@@ -209,6 +214,39 @@ static void brcm_sata_init(struct brcm_ahci_priv *priv)
   priv->top_ctrl + SATA_TOP_CTRL_BUS_CTRL);
 }
 
+static void brcm_sata_quick(struct platform_device *pdev,
+   struct brcm_ahci_priv *priv)
+{
+   void __iomem *ahci;
+   struct resource *res;
+   u32 reg;
+
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ahci");
+   ahci = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(ahci))
+   return;
+
+   if (priv->quicks & BRCM_AHCI_QUICK_NONCQ) {
+   reg  = readl(priv->top_ctrl + SATA_TOP_CTRL_BUS_CTRL);
+   reg |= OVERRIDE_HWINIT;
+   writel(reg, priv->top_ctrl + SATA_TOP_CTRL_BUS_CTRL);
+
+   /* Clear out the NCQ bit so the AHCI driver will not issue
+* FPDMA/NCQ commands.
+*/
+   reg = readl(ahci + HOST_CAP);
+   reg &= ~HOST_CAP_NCQ;
+   writel(reg, ahci + HOST_CAP);
+
+   reg = readl(priv->top_ctrl + SATA_TOP_CTRL_BUS_CTRL);
+   reg &= ~OVERRIDE_HWINIT;
+   writel(reg, priv->top_ctrl + SATA_TOP_CTRL_BUS_CTRL);
+   }
+
+   devm_iounmap(>dev, ahci);
+   devm_release_mem_region(>dev, res->start, resource_size(res));
+}
+
 #ifdef CONFIG_PM_SLEEP
 static int brcm_ahci_suspend(struct device *dev)
 {
@@ -256,7 +294,11 @@ static int brcm_ahci_probe(struct platform_device *pdev)
if (IS_ERR(priv->top_ctrl))
return PTR_ERR(priv->top_ctrl);
 
+   if (of_property_read_bool(dev->of_node, "brcm,broken-ncq"))
+   priv->quicks |= BRCM_AHCI_QUICK_NONCQ;
+
brcm_sata_init(priv);
+   brcm_sata_quick(pdev, priv);
 
priv->port_mask = brcm_ahci_get_portmask(pdev, priv);
if (!priv->port_mask)
-- 
2.6.2

--
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

[v2 08/10] MIPS: BMIPS: brcmstb: add SATA/PHY nodes for bcm7425

[Jaedon Shin]

Add AHCI and PHY device nodes to MIPS-based BCM7425 set-top box
platform.

Signed-off-by: Jaedon Shin 
---
 arch/mips/boot/dts/brcm/bcm7425.dtsi | 42 
 1 file changed, 42 insertions(+)

diff --git a/arch/mips/boot/dts/brcm/bcm7425.dtsi 
b/arch/mips/boot/dts/brcm/bcm7425.dtsi
index 5b660b617ead..e24d41ab4e30 100644
--- a/arch/mips/boot/dts/brcm/bcm7425.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7425.dtsi
@@ -221,5 +221,47 @@
interrupts = <73>;
status = "disabled";
};
+
+   sata: sata@181000 {
+   compatible = "brcm,bcm7425-ahci", "brcm,sata3-ahci";
+   reg-names = "ahci", "top-ctrl";
+   reg = <0x181000 0xa9c>, <0x180020 0x1c>;
+   interrupt-parent = <_intc>;
+   interrupts = <40>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   brcm,broken-ncq;
+   brcm,broken-phy;
+   status = "disabled";
+
+   sata0: sata-port@0 {
+   reg = <0>;
+   phys = <_phy0>;
+   };
+
+   sata1: sata-port@1 {
+   reg = <1>;
+   phys = <_phy1>;
+   };
+   };
+
+   sata_phy: sata-phy@180 {
+   compatible = "brcm,bcm7425-sata-phy", "brcm,phy-sata3";
+   reg = <0x180100 0x0eff>;
+   reg-names = "phy";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+
+   sata_phy0: sata-phy@0 {
+   reg = <0>;
+   #phy-cells = <0>;
+   };
+
+   sata_phy1: sata-phy@1 {
+   reg = <1>;
+   #phy-cells = <0>;
+   };
+   };
};
 };
-- 
2.6.2

--
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

[v2 04/10] ata: ahci_brcmstb: remove unused definitions

[Jaedon Shin]

Remove unused definitions.

The MIPS-based 40nm chipsets has different offset. The
SATA_TOP_CTRL_SATA_TP_OUT offset is 0x18 and the
SATA_TOP_CTRL_CLIENT_INIT_CTRL is not exist. So, To remove do to avoid
confusion.

Signed-off-by: Jaedon Shin 
---
 drivers/ata/ahci_brcmstb.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/ata/ahci_brcmstb.c b/drivers/ata/ahci_brcmstb.c
index c61303f7c7dc..2d25a28f4f64 100644
--- a/drivers/ata/ahci_brcmstb.c
+++ b/drivers/ata/ahci_brcmstb.c
@@ -52,8 +52,6 @@
   #define SATA_TOP_CTRL_2_PHY_GLOBAL_RESET BIT(14)
  #define SATA_TOP_CTRL_PHY_OFFS0x8
  #define SATA_TOP_MAX_PHYS 2
-#define SATA_TOP_CTRL_SATA_TP_OUT  0x1c
-#define SATA_TOP_CTRL_CLIENT_INIT_CTRL 0x20
 
 /* On big-endian MIPS, buses are reversed to big endian, so switch them back */
 #if defined(CONFIG_MIPS) && defined(__BIG_ENDIAN)
-- 
2.6.2

--
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

[v2 03/10] ata: ahci_brcmstb: add quick for broken phy

[Jaedon Shin]

Add quick for broken phy. The ARM-based 28nm chipsets have four phy
interface control registers and each port has two registers. But, The
MIPS-based 40nm chipsets have three. and there are no information and
documentation. The legacy version of broadcom's strict-ahci based
initial code did not control these registers.

Signed-off-by: Jaedon Shin 
---
 Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt |  1 +
 drivers/ata/ahci_brcmstb.c  | 10 ++
 2 files changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt 
b/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt
index 488a383ce202..0f0925d58188 100644
--- a/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt
+++ b/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt
@@ -12,6 +12,7 @@ Required properties:
 
 Optional properties:
 - brcm,broken-ncq: if present, NCQ is unusable
+- brcm,broken-phy: if present, to control phy interface is unusable
 
 Also see ahci-platform.txt.
 
diff --git a/drivers/ata/ahci_brcmstb.c b/drivers/ata/ahci_brcmstb.c
index e53962cb48ee..c61303f7c7dc 100644
--- a/drivers/ata/ahci_brcmstb.c
+++ b/drivers/ata/ahci_brcmstb.c
@@ -71,6 +71,7 @@
 
 enum brcm_ahci_quicks {
BRCM_AHCI_QUICK_NONCQ   = BIT(0),
+   BRCM_AHCI_QUICK_NOPHY   = BIT(1),
 };
 
 struct brcm_ahci_priv {
@@ -119,6 +120,9 @@ static void brcm_sata_phy_enable(struct brcm_ahci_priv 
*priv, int port)
void __iomem *p;
u32 reg;
 
+   if (priv->quicks & BRCM_AHCI_QUICK_NOPHY)
+   return;
+
/* clear PHY_DEFAULT_POWER_STATE */
p = phyctrl + SATA_TOP_CTRL_PHY_CTRL_1;
reg = brcm_sata_readreg(p);
@@ -148,6 +152,9 @@ static void brcm_sata_phy_disable(struct brcm_ahci_priv 
*priv, int port)
void __iomem *p;
u32 reg;
 
+   if (priv->quicks & BRCM_AHCI_QUICK_NOPHY)
+   return;
+
/* power-off the PHY digital logic */
p = phyctrl + SATA_TOP_CTRL_PHY_CTRL_2;
reg = brcm_sata_readreg(p);
@@ -297,6 +304,9 @@ static int brcm_ahci_probe(struct platform_device *pdev)
if (of_property_read_bool(dev->of_node, "brcm,broken-ncq"))
priv->quicks |= BRCM_AHCI_QUICK_NONCQ;
 
+   if (of_property_read_bool(dev->of_node, "brcm,broken-phy"))
+   priv->quicks |= BRCM_AHCI_QUICK_NOPHY;
+
brcm_sata_init(priv);
brcm_sata_quick(pdev, priv);
 
-- 
2.6.2

--
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

[v2 06/10] phy: phy_brcmstb_sata: add data for phy version

[Jaedon Shin]

Add data of device for phy version. and 28nm version is default.

Signed-off-by: Jaedon Shin 
---
 drivers/phy/phy-brcmstb-sata.c | 23 ---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/phy-brcmstb-sata.c b/drivers/phy/phy-brcmstb-sata.c
index 0be55dafe9ea..5de394f589c8 100644
--- a/drivers/phy/phy-brcmstb-sata.c
+++ b/drivers/phy/phy-brcmstb-sata.c
@@ -30,7 +30,11 @@
 #define MAX_PORTS  2
 
 /* Register offset between PHYs in PCB space */
-#define SATA_MDIO_REG_SPACE_SIZE   0x1000
+#define SATA_MDIO_REG_28NM_SPACE_SIZE  0x1000
+
+enum brcm_sata_phy_version {
+   BRCM_SATA_PHY_28NM,
+};
 
 struct brcm_sata_port {
int portnum;
@@ -42,6 +46,7 @@ struct brcm_sata_port {
 struct brcm_sata_phy {
struct device *dev;
void __iomem *phy_base;
+   enum brcm_sata_phy_version version;
 
struct brcm_sata_port phys[MAX_PORTS];
 };
@@ -64,8 +69,12 @@ enum sata_mdio_phy_regs_28nm {
 static inline void __iomem *brcm_sata_phy_base(struct brcm_sata_port *port)
 {
struct brcm_sata_phy *priv = port->phy_priv;
+   u32 offset;
 
-   return priv->phy_base + (port->portnum * SATA_MDIO_REG_SPACE_SIZE);
+   if (priv->version == BRCM_SATA_PHY_28NM)
+   offset = SATA_MDIO_REG_28NM_SPACE_SIZE;
+
+   return priv->phy_base + (port->portnum * offset);
 }
 
 static void brcm_sata_mdio_wr(void __iomem *addr, u32 bank, u32 ofs,
@@ -126,7 +135,8 @@ static const struct phy_ops phy_ops_28nm = {
 };
 
 static const struct of_device_id brcm_sata_phy_of_match[] = {
-   { .compatible   = "brcm,bcm7445-sata-phy" },
+   { .compatible   = "brcm,bcm7445-sata-phy",
+ .data = (void *)BRCM_SATA_PHY_28NM },
{},
 };
 MODULE_DEVICE_TABLE(of, brcm_sata_phy_of_match);
@@ -135,6 +145,7 @@ static int brcm_sata_phy_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
struct device_node *dn = dev->of_node, *child;
+   const struct of_device_id *of_id;
struct brcm_sata_phy *priv;
struct resource *res;
struct phy_provider *provider;
@@ -154,6 +165,12 @@ static int brcm_sata_phy_probe(struct platform_device 
*pdev)
if (IS_ERR(priv->phy_base))
return PTR_ERR(priv->phy_base);
 
+   of_id = of_match_node(brcm_sata_phy_of_match, dn);
+   if (of_id)
+   priv->version = (enum brcm_sata_phy_version)of_id->data;
+   else
+   priv->version = BRCM_SATA_PHY_28NM;
+
for_each_available_child_of_node(dn, child) {
unsigned int id;
struct brcm_sata_port *port;
-- 
2.6.2

--
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

[v2 05/10] phy: phy_brcmstb_sata: remove duplicate definitions

[Jaedon Shin]

Remove duplicate definitions.

Signed-off-by: Jaedon Shin 
---
 drivers/phy/phy-brcmstb-sata.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/phy/phy-brcmstb-sata.c b/drivers/phy/phy-brcmstb-sata.c
index 8a2cb16a1937..0be55dafe9ea 100644
--- a/drivers/phy/phy-brcmstb-sata.c
+++ b/drivers/phy/phy-brcmstb-sata.c
@@ -26,8 +26,6 @@
 
 #define SATA_MDIO_BANK_OFFSET  0x23c
 #define SATA_MDIO_REG_OFFSET(ofs)  ((ofs) * 4)
-#define SATA_MDIO_REG_SPACE_SIZE   0x1000
-#define SATA_MDIO_REG_LENGTH   0x1f00
 
 #define MAX_PORTS  2
 
-- 
2.6.2

--
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

[v2 07/10] phy: phy_brcmstb_sata: add support MIPS-based platforms

[Jaedon Shin]

The BCM7xxx ARM-based and MIPS-based platforms share a similar hardware
block for AHCI SATA3.

The BCM7425 is flagship chipset of 40nm class. Other MIPS-based 40nm
chipsets has same hardware block. so the compatible string may be use
brcm,bcm7425-sata-phy.

Signed-off-by: Jaedon Shin 
---
 .../bindings/phy/brcm,brcmstb-sata-phy.txt |  1 +
 drivers/phy/Kconfig|  4 ++--
 drivers/phy/phy-brcmstb-sata.c | 24 --
 3 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-sata-phy.txt 
b/Documentation/devicetree/bindings/phy/brcm,brcmstb-sata-phy.txt
index 7f81ef90146a..c4b31075ffef 100644
--- a/Documentation/devicetree/bindings/phy/brcm,brcmstb-sata-phy.txt
+++ b/Documentation/devicetree/bindings/phy/brcm,brcmstb-sata-phy.txt
@@ -3,6 +3,7 @@
 Required properties:
 - compatible: should be one or more of
  "brcm,bcm7445-sata-phy"
+ "brcm,bcm7425-sata-phy"
  "brcm,phy-sata3"
 - address-cells: should be 1
 - size-cells: should be 0
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 47da573d0bab..c83e48661fd7 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -364,11 +364,11 @@ config PHY_TUSB1210
 
 config PHY_BRCMSTB_SATA
tristate "Broadcom STB SATA PHY driver"
-   depends on ARCH_BRCMSTB
+   depends on ARCH_BRCMSTB || BMIPS_GENERIC
depends on OF
select GENERIC_PHY
help
- Enable this to support the SATA3 PHY on 28nm Broadcom STB SoCs.
+ Enable this to support the SATA3 PHY on 28nm or 40nm Broadcom STB 
SoCs.
  Likely useful only with CONFIG_SATA_BRCMSTB enabled.
 
 endmenu
diff --git a/drivers/phy/phy-brcmstb-sata.c b/drivers/phy/phy-brcmstb-sata.c
index 5de394f589c8..c8243581f196 100644
--- a/drivers/phy/phy-brcmstb-sata.c
+++ b/drivers/phy/phy-brcmstb-sata.c
@@ -32,8 +32,14 @@
 /* Register offset between PHYs in PCB space */
 #define SATA_MDIO_REG_28NM_SPACE_SIZE  0x1000
 
+/* The older SATA PHY registers duplicated per port registers within the map,
+ * rather than having a separate map per port.
+ */
+#define SATA_MDIO_REG_40NM_SPACE_SIZE  0x10
+
 enum brcm_sata_phy_version {
BRCM_SATA_PHY_28NM,
+   BRCM_SATA_PHY_40NM,
 };
 
 struct brcm_sata_port {
@@ -51,7 +57,7 @@ struct brcm_sata_phy {
struct brcm_sata_port phys[MAX_PORTS];
 };
 
-enum sata_mdio_phy_regs_28nm {
+enum sata_mdio_phy_regs {
PLL_REG_BANK_0  = 0x50,
PLL_REG_BANK_0_PLLCONTROL_0 = 0x81,
 
@@ -69,10 +75,14 @@ enum sata_mdio_phy_regs_28nm {
 static inline void __iomem *brcm_sata_phy_base(struct brcm_sata_port *port)
 {
struct brcm_sata_phy *priv = port->phy_priv;
-   u32 offset;
+   u32 offset = 0;
 
if (priv->version == BRCM_SATA_PHY_28NM)
offset = SATA_MDIO_REG_28NM_SPACE_SIZE;
+   else if (priv->version == BRCM_SATA_PHY_40NM)
+   offset = SATA_MDIO_REG_40NM_SPACE_SIZE;
+   else
+   dev_err(priv->dev, "should not happen\n");
 
return priv->phy_base + (port->portnum * offset);
 }
@@ -93,7 +103,7 @@ static void brcm_sata_mdio_wr(void __iomem *addr, u32 bank, 
u32 ofs,
 #define FMAX_VAL_DEFAULT   0x3df
 #define FMAX_VAL_SSC   0x83
 
-static void brcm_sata_cfg_ssc_28nm(struct brcm_sata_port *port)
+static void brcm_sata_cfg_ssc(struct brcm_sata_port *port)
 {
void __iomem *base = brcm_sata_phy_base(port);
struct brcm_sata_phy *priv = port->phy_priv;
@@ -124,12 +134,12 @@ static int brcm_sata_phy_init(struct phy *phy)
 {
struct brcm_sata_port *port = phy_get_drvdata(phy);
 
-   brcm_sata_cfg_ssc_28nm(port);
+   brcm_sata_cfg_ssc(port);
 
return 0;
 }
 
-static const struct phy_ops phy_ops_28nm = {
+static const struct phy_ops phy_ops = {
.init   = brcm_sata_phy_init,
.owner  = THIS_MODULE,
 };
@@ -137,6 +147,8 @@ static const struct phy_ops phy_ops_28nm = {
 static const struct of_device_id brcm_sata_phy_of_match[] = {
{ .compatible   = "brcm,bcm7445-sata-phy",
  .data = (void *)BRCM_SATA_PHY_28NM },
+   { .compatible   = "brcm,bcm7425-sata-phy",
+ .data = (void *)BRCM_SATA_PHY_40NM },
{},
 };
 MODULE_DEVICE_TABLE(of, brcm_sata_phy_of_match);
@@ -193,7 +205,7 @@ static int brcm_sata_phy_probe(struct platform_device *pdev)
port = >phys[id];
port->portnum = id;
port->phy_priv = priv;
-   port->phy = devm_phy_create(dev, child, _ops_28nm);
+   port->phy = devm_phy_create(dev, child, _ops);
port->ssc_en = of_property_read_bool(child, "brcm,enable-ssc");
if (IS_ERR(port->phy)) {
dev_err(dev, "failed to create PHY\n");
-- 
2.6.2

--
To unsubscribe from this list: send the line 

[v2 02/10] ata: ahci_brcmstb: add support MIPS-based platforms

[Jaedon Shin]

The BCM7xxx ARM-based and MIPS-based platforms share a similar hardware
block for AHCI SATA3.

The BCM7425 is flagship chipset of 40nm class. Other MIPS-based 40nm
chipsets has same hardware block. so the compatible string may be use
brcm,bcm7425-ahci.

Signed-off-by: Jaedon Shin 
---
 Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt | 4 ++--
 drivers/ata/Kconfig | 2 +-
 drivers/ata/ahci_brcmstb.c  | 1 +
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt 
b/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt
index 4650c0aff6b3..488a383ce202 100644
--- a/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt
+++ b/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt
@@ -4,8 +4,8 @@ SATA nodes are defined to describe on-chip Serial ATA 
controllers.
 Each SATA controller should have its own node.
 
 Required properties:
-- compatible : compatible list, may contain "brcm,bcm7445-ahci" and/or
-   "brcm,sata3-ahci"
+- compatible : compatible list, may contain "brcm,bcm7445-ahci" or
+   "brcm,bcm7425-ahci" or "brcm,sata3-ahci"
 - reg: register mappings for AHCI and SATA_TOP_CTRL
 - reg-names  : "ahci" and "top-ctrl"
 - interrupts : interrupt mapping for SATA IRQ
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 15e40ee62a94..8f535a88a0c7 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -100,7 +100,7 @@ config SATA_AHCI_PLATFORM
 
 config AHCI_BRCMSTB
tristate "Broadcom STB AHCI SATA support"
-   depends on ARCH_BRCMSTB
+   depends on ARCH_BRCMSTB || BMIPS_GENERIC
help
  This option enables support for the AHCI SATA3 controller found on
  STB SoC's.
diff --git a/drivers/ata/ahci_brcmstb.c b/drivers/ata/ahci_brcmstb.c
index a2df76698adb..e53962cb48ee 100644
--- a/drivers/ata/ahci_brcmstb.c
+++ b/drivers/ata/ahci_brcmstb.c
@@ -343,6 +343,7 @@ static int brcm_ahci_remove(struct platform_device *pdev)
 
 static const struct of_device_id ahci_of_match[] = {
{.compatible = "brcm,bcm7445-ahci"},
+   {.compatible = "brcm,bcm7425-ahci"},
{},
 };
 MODULE_DEVICE_TABLE(of, ahci_of_match);
-- 
2.6.2

--
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

[v2 09/10] MIPS: BMIPS: brcmstb: add SATA/PHY nodes for bcm7346

[Jaedon Shin]

Add AHCI and PHY device nodes to MIPS-based BCM7346 set-top box
platform.

Signed-off-by: Jaedon Shin 
---
 arch/mips/boot/dts/brcm/bcm7346.dtsi  | 42 +++
 arch/mips/boot/dts/brcm/bcm97346dbsmb.dts |  8 ++
 2 files changed, 50 insertions(+)

diff --git a/arch/mips/boot/dts/brcm/bcm7346.dtsi 
b/arch/mips/boot/dts/brcm/bcm7346.dtsi
index d817bb46b934..8535a5676d48 100644
--- a/arch/mips/boot/dts/brcm/bcm7346.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7346.dtsi
@@ -246,5 +246,47 @@
interrupts = <76>;
status = "disabled";
};
+
+   sata: sata@181000 {
+   compatible = "brcm,bcm7425-ahci", "brcm,sata3-ahci";
+   reg-names = "ahci", "top-ctrl";
+   reg = <0x181000 0xa9c>, <0x180020 0x1c>;
+   interrupt-parent = <_intc>;
+   interrupts = <40>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   brcm,broken-ncq;
+   brcm,broken-phy;
+   status = "disabled";
+
+   sata0: sata-port@0 {
+   reg = <0>;
+   phys = <_phy0>;
+   };
+
+   sata1: sata-port@1 {
+   reg = <1>;
+   phys = <_phy1>;
+   };
+   };
+
+   sata_phy: sata-phy@180 {
+   compatible = "brcm,bcm7425-sata-phy", "brcm,phy-sata3";
+   reg = <0x180100 0x0eff>;
+   reg-names = "phy";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+
+   sata_phy0: sata-phy@0 {
+   reg = <0>;
+   #phy-cells = <0>;
+   };
+
+   sata_phy1: sata-phy@1 {
+   reg = <1>;
+   #phy-cells = <0>;
+   };
+   };
};
 };
diff --git a/arch/mips/boot/dts/brcm/bcm97346dbsmb.dts 
b/arch/mips/boot/dts/brcm/bcm97346dbsmb.dts
index 3fe0445b9d37..e147c61178cc 100644
--- a/arch/mips/boot/dts/brcm/bcm97346dbsmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97346dbsmb.dts
@@ -64,3 +64,11 @@
  {
status = "okay";
 };
+
+ {
+   status = "okay";
+};
+
+_phy {
+   status = "okay";
+};
-- 
2.6.2

--
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

[v2 00/10] add support SATA for BMIPS_GENERIC

[Jaedon Shin]

Hi all,

This patch series add support SATA for BMIPS_GENERIC.

Ralf,
I request you to drop already submitted patches for NAND deivce nodes.
They are merge conflict with these.
http://patchwork.linux-mips.org/patch/10577/
http://patchwork.linux-mips.org/patch/10578/
http://patchwork.linux-mips.org/patch/10579/
http://patchwork.linux-mips.org/patch/10580/

Changes in v2:
- Adds quick for ncq
- Adds quick for phy interface control
- Remove unused definitions in ahci_brcmstb
- Combines compatible string

Jaedon Shin (10):
  ata: ahci_brcmstb: add quick for broken ncq
  ata: ahci_brcmstb: add support MIPS-based platforms
  ata: ahci_brcmstb: add quick for broken phy
  ata: ahci_brcmstb: remove unused definitions
  phy: phy_brcmstb_sata: remove duplicate definitions
  phy: phy_brcmstb_sata: add data for phy version
  phy: phy_brcmstb_sata: add support MIPS-based platforms
  MIPS: BMIPS: brcmstb: add SATA/PHY nodes for bcm7425
  MIPS: BMIPS: brcmstb: add SATA/PHY nodes for bcm7346
  MIPS: BMIPS: brcmstb: add SATA/PHY nodes for bcm7362

 .../devicetree/bindings/ata/brcm,sata-brcmstb.txt  |  8 +++-
 .../bindings/phy/brcm,brcmstb-sata-phy.txt |  1 +
 arch/mips/boot/dts/brcm/bcm7346.dtsi   | 42 +
 arch/mips/boot/dts/brcm/bcm7362.dtsi   | 42 +
 arch/mips/boot/dts/brcm/bcm7425.dtsi   | 42 +
 arch/mips/boot/dts/brcm/bcm97346dbsmb.dts  |  8 
 arch/mips/boot/dts/brcm/bcm97362svmb.dts   |  8 
 drivers/ata/Kconfig|  2 +-
 drivers/ata/ahci_brcmstb.c | 55 +-
 drivers/phy/Kconfig|  4 +-
 drivers/phy/phy-brcmstb-sata.c | 47 ++
 11 files changed, 242 insertions(+), 17 deletions(-)

-- 
2.6.2

--
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 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib

[Roger Quadros]

On 26/10/15 22:49, Brian Norris wrote:
> + others
> 
> A few comments below.
> 
> On Fri, Sep 18, 2015 at 05:53:40PM +0300, Roger Quadros wrote:
>> The GPMC WAIT pin status are now available over gpiolib.
>> Update the omap_dev_ready() function to use gpio instead of
>> directly accessing GPMC register space.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  drivers/mtd/nand/omap2.c | 29 
>> +---
>>  include/linux/platform_data/mtd-nand-omap2.h |  2 +-
>>  2 files changed, 19 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>> index 228f498..d0f2620 100644
>> --- a/drivers/mtd/nand/omap2.c
>> +++ b/drivers/mtd/nand/omap2.c
>> @@ -12,6 +12,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -184,6 +185,8 @@ struct omap_nand_info {
>>  /* fields specific for BCHx_HW ECC scheme */
>>  struct device   *elm_dev;
>>  struct device_node  *of_node;
>> +/* NAND ready gpio */
>> +struct gpio_desc*ready_gpiod;
>>  };
>>  
>>  /**
>> @@ -1047,22 +1050,17 @@ static int omap_wait(struct mtd_info *mtd, struct 
>> nand_chip *chip)
>>  }
>>  
>>  /**
>> - * omap_dev_ready - calls the platform specific dev_ready function
>> + * omap_dev_ready - checks the NAND Ready GPIO line
>>   * @mtd: MTD device structure
>> + *
>> + * Returns true if ready and false if busy.
>>   */
>>  static int omap_dev_ready(struct mtd_info *mtd)
>>  {
>> -unsigned int val = 0;
>>  struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
>>  mtd);
>>  
>> -val = readl(info->reg.gpmc_status);
>> -
>> -if ((val & 0x100) == 0x100) {
>> -return 1;
>> -} else {
>> -return 0;
>> -}
>> +return gpiod_get_value(info->ready_gpiod);
>>  }
>>  
>>  /**
>> @@ -1782,7 +1780,9 @@ static int omap_nand_probe(struct platform_device 
>> *pdev)
>>  info->reg = pdata->reg;
>>  info->of_node = pdata->of_node;
>>  info->ecc_opt = pdata->ecc_opt;
>> -info->dev_ready = pdata->dev_ready;
>> +if (pdata->dev_ready)
>> +dev_info(>dev, "pdata->dev_ready is 
>> deprecated\n");
>> +
>>  info->xfer_type = pdata->xfer_type;
>>  info->devsize = pdata->devsize;
>>  info->elm_of_node = pdata->elm_of_node;
>> @@ -1815,6 +1815,13 @@ static int omap_nand_probe(struct platform_device 
>> *pdev)
>>  nand_chip->IO_ADDR_W = nand_chip->IO_ADDR_R;
>>  nand_chip->cmd_ctrl  = omap_hwcontrol;
>>  
>> +info->ready_gpiod = devm_gpiod_get_optional(>dev, "ready",
>> +GPIOD_IN);
> 
> Others have been looking at using GPIOs for the ready/busy pin too. At a
> minimum, we need an updated DT binding doc for this, since I see you're
> adding this via device tree in a later patch (I don't see any DT binding
> patch for this; but I could just be overlooking it). It'd also be great
> if this support was moved to nand_dt_init() so other platforms can
> benefit, but I won't require that.
> 
> Also, previous [0] proposers had suggested 'rb-gpios', not 'ready-gpio'
> (the hardware docs typically call it 'rb' for ready/busy, FWIW). I don't
> really care, but the name should be going into a doc, so we can choose
> the same one everywhere.
> 
> EDIT: looks like the discussion was partly here [1] and it seems we're
> landing on "rb-gpios" in the latest version [2]. Can we stick with that?

Why should it be "rb-gpios" and not "rb-gpio"?
I don't think there are multiple gpios for r/b# function.

cheers,
-roger

> 
> Regards,
> Brian
> 
> [0] "Previous" may be subject to debate, as both series have been going
> for several revisions.
> [1] http://patchwork.ozlabs.org/patch/515327/
> [2] http://patchwork.ozlabs.org/patch/526819/
> 
>> +if (IS_ERR(info->ready_gpiod)) {
>> +dev_err(dev, "failed to get ready gpio\n");
>> +return PTR_ERR(info->ready_gpiod);
>> +}
>> +
>>  /*
>>   * If RDY/BSY line is connected to OMAP then use the omap ready
>>   * function and the generic nand_wait function which reads the status
>> @@ -1822,7 +1829,7 @@ static int omap_nand_probe(struct platform_device 
>> *pdev)
>>   * chip delay which is slightly more than tR (AC Timing) of the NAND
>>   * device and read status register until you get a failure or success
>>   */
>> -if (info->dev_ready) {
>> +if (info->ready_gpiod) {
>>  nand_chip->dev_ready = omap_dev_ready;
>>  nand_chip->chip_delay = 0;
>>  } else {
>> diff --git a/include/linux/platform_data/mtd-nand-omap2.h 
>> b/include/linux/platform_data/mtd-nand-omap2.h
>> index ff27e5a..19e509d 100644
>> --- a/include/linux/platform_data/mtd-nand-omap2.h
>> +++ 

Re: [linux-sunxi] Re: [PATCH 5/6] ARM: dts: sunxi: Add Allwinner H3 DTSI

[Hans de Goede]

Hi,

On 26-10-15 22:06, Maxime Ripard wrote:

On Sat, Oct 24, 2015 at 10:47:49AM +0200, Jean-Francois Moine wrote:

On Sat, 24 Oct 2015 09:13:28 +0200
Maxime Ripard  wrote:


Or simply

bus_gates {
clocks = <>, <>;
clock-indices = <5>, <6>, <8>, ...
clock-output-names = "bus_ce", "bus_dma", "bus_mmc0"
};


I don't understand: the apb1, apb2, ahb1 and ahb2 clocks may be
programmed independently to different frequencies


I don't understand why you're talking about frequencies here.


and you have to know which of them is the parent of each leaf clock.


Indeed, but that's also doable here. Just not in the DT.


So, either you hard-code the parents as Jens did in a first proposal,
or you define the full list of parents in the DT as in the last
proposal, or you use a container per parent in the DT as I proposed.

There could be an other solution using the output clock name to define
the parent clock:

bus_gates {
clocks = <>, <>, <>, <>;
clock-indices = <5>, <6>, <8>, ...
clock-output-names = "ahb1_ce", "ahb1_dma", "ahb1_mmc0"
};

with the documentation:

"the clocks MUST be defined in order: ahb1, ahb2, apb1, apb2."

and the code

if (strncmp(clock_name, "ahb1", 4) == 0)
clk_parent = of_clk_get_parent_name(node, 0);
else if (..)

but it seems a bit hacky.


It's exactly what I suggested, without the string comparison, but
relying on the ID instead.


I'm not following you here, what do you mean with "the ID" ?

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 v3 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib

[Boris Brezillon]

Hi Roger,

On Tue, 27 Oct 2015 10:03:02 +0200
Roger Quadros  wrote:

> On 26/10/15 22:49, Brian Norris wrote:
> > 
> > Others have been looking at using GPIOs for the ready/busy pin too. At a
> > minimum, we need an updated DT binding doc for this, since I see you're
> > adding this via device tree in a later patch (I don't see any DT binding
> > patch for this; but I could just be overlooking it). It'd also be great
> > if this support was moved to nand_dt_init() so other platforms can
> > benefit, but I won't require that.
> > 
> > Also, previous [0] proposers had suggested 'rb-gpios', not 'ready-gpio'
> > (the hardware docs typically call it 'rb' for ready/busy, FWIW). I don't
> > really care, but the name should be going into a doc, so we can choose
> > the same one everywhere.
> > 
> > EDIT: looks like the discussion was partly here [1] and it seems we're
> > landing on "rb-gpios" in the latest version [2]. Can we stick with that?
> 
> Why should it be "rb-gpios" and not "rb-gpio"?
> I don't think there are multiple gpios for r/b# function.

Because it's supposed to be a generic binding, and some NAND chips
embed several dies, thus exposing several CS and RB pins, hence the
rb-gpios name.
Also, as described here [1], the convention is to name your property
-gpios even if you only need one gpio.

Best Regards,

Boris

[1]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/gpio/gpio.txt#L16



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 08/10] mmc: mmc: extend the mmc_send_tuning()

[Chaotian Jing]

The mmc_execute_tuning() has already prepared the opcode,
there is no need to prepare it again at mmc_send_tuning(),
and, there is a BUG of mmc_send_tuning() to determine the opcode
by bus width, assume eMMC was running at HS200, 4bit mode,
then the mmc_send_tuning() will overwrite the opcode from CMD21
to CMD19, then got error.

in addition, extend an argument of "cmd_error" to allow getting
if there was cmd error when tune response.

Signed-off-by: Chaotian Jing 
---
 drivers/mmc/core/mmc_ops.c | 8 
 drivers/mmc/host/dw_mmc-exynos.c   | 4 ++--
 drivers/mmc/host/dw_mmc.c  | 2 +-
 drivers/mmc/host/dw_mmc.h  | 2 +-
 drivers/mmc/host/sdhci-esdhc-imx.c | 6 +++---
 drivers/mmc/host/sdhci-msm.c   | 2 +-
 drivers/mmc/host/sdhci-sirf.c  | 2 +-
 include/linux/mmc/core.h   | 2 +-
 8 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index 0e9ae1c..4305f75 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -589,7 +589,7 @@ int mmc_switch(struct mmc_card *card, u8 set, u8 index, u8 
value,
 }
 EXPORT_SYMBOL_GPL(mmc_switch);
 
-int mmc_send_tuning(struct mmc_host *host)
+int mmc_send_tuning(struct mmc_host *host, u32 opcode, int *cmd_error)
 {
struct mmc_request mrq = {NULL};
struct mmc_command cmd = {0};
@@ -599,16 +599,13 @@ int mmc_send_tuning(struct mmc_host *host)
const u8 *tuning_block_pattern;
int size, err = 0;
u8 *data_buf;
-   u32 opcode;
 
if (ios->bus_width == MMC_BUS_WIDTH_8) {
tuning_block_pattern = tuning_blk_pattern_8bit;
size = sizeof(tuning_blk_pattern_8bit);
-   opcode = MMC_SEND_TUNING_BLOCK_HS200;
} else if (ios->bus_width == MMC_BUS_WIDTH_4) {
tuning_block_pattern = tuning_blk_pattern_4bit;
size = sizeof(tuning_blk_pattern_4bit);
-   opcode = MMC_SEND_TUNING_BLOCK;
} else
return -EINVAL;
 
@@ -639,6 +636,9 @@ int mmc_send_tuning(struct mmc_host *host)
 
mmc_wait_for_req(host, );
 
+   if (cmd_error)
+   *cmd_error = cmd.error;
+
if (cmd.error) {
err = cmd.error;
goto out;
diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index 1e75309..3a7e835 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -446,7 +446,7 @@ out:
return loc;
 }
 
-static int dw_mci_exynos_execute_tuning(struct dw_mci_slot *slot)
+static int dw_mci_exynos_execute_tuning(struct dw_mci_slot *slot, u32 opcode)
 {
struct dw_mci *host = slot->host;
struct dw_mci_exynos_priv_data *priv = host->priv;
@@ -461,7 +461,7 @@ static int dw_mci_exynos_execute_tuning(struct dw_mci_slot 
*slot)
mci_writel(host, TMOUT, ~0);
smpl = dw_mci_exynos_move_next_clksmpl(host);
 
-   if (!mmc_send_tuning(mmc))
+   if (!mmc_send_tuning(mmc, opcode, NULL))
candiates |= (1 << smpl);
 
} while (start_smpl != smpl);
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index fcbf552..be8441d 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1427,7 +1427,7 @@ static int dw_mci_execute_tuning(struct mmc_host *mmc, 
u32 opcode)
int err = -EINVAL;
 
if (drv_data && drv_data->execute_tuning)
-   err = drv_data->execute_tuning(slot);
+   err = drv_data->execute_tuning(slot, opcode);
return err;
 }
 
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index 8ce4674..394340f 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -281,7 +281,7 @@ struct dw_mci_drv_data {
void(*prepare_command)(struct dw_mci *host, u32 *cmdr);
void(*set_ios)(struct dw_mci *host, struct mmc_ios *ios);
int (*parse_dt)(struct dw_mci *host);
-   int (*execute_tuning)(struct dw_mci_slot *slot);
+   int (*execute_tuning)(struct dw_mci_slot *slot, u32 opcode);
int (*prepare_hs400_tuning)(struct dw_mci *host,
struct mmc_ios *ios);
int (*switch_voltage)(struct mmc_host *mmc,
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
b/drivers/mmc/host/sdhci-esdhc-imx.c
index 886d230..1f1582f 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -759,7 +759,7 @@ static int esdhc_executing_tuning(struct sdhci_host *host, 
u32 opcode)
min = ESDHC_TUNE_CTRL_MIN;
while (min < ESDHC_TUNE_CTRL_MAX) {
esdhc_prepare_tuning(host, min);
-   if (!mmc_send_tuning(host->mmc))
+   if (!mmc_send_tuning(host->mmc, opcode, NULL))
break;
 

[PATCH v3 07/10] arm64: dts: mediatek: add eMMC hw reset support

[Chaotian Jing]

Add eMMC hardware reset support

Signed-off-by: Chaotian Jing 
---
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 4be66ca..6d79ffc 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -72,6 +72,7 @@
bus-width = <8>;
max-frequency = <5000>;
cap-mmc-highspeed;
+   cap-mmc-hw-reset;
vmmc-supply = <_vemc_3v3_reg>;
vqmmc-supply = <_vio18_reg>;
non-removable;
-- 
1.8.1.1.dirty

--
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 10/10] arm64: dts: mediatek: add HS200/HS400/SDR50/SDR104 support

[Chaotian Jing]

add HS200/HS400 support for eMMC
add SDR50/SDR104 support for SD

Signed-off-by: Chaotian Jing 
---
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 6d79ffc..a061221 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -70,11 +70,16 @@
pinctrl-0 = <_pins_default>;
pinctrl-1 = <_pins_uhs>;
bus-width = <8>;
-   max-frequency = <5000>;
+   max-frequency = <2>;
cap-mmc-highspeed;
+   mmc-hs200-1_8v;
+   mmc-hs400-1_8v;
cap-mmc-hw-reset;
+   hs400-ds-delay = <0x14015>;
vmmc-supply = <_vemc_3v3_reg>;
vqmmc-supply = <_vio18_reg>;
+   assigned-clocks = < CLK_TOP_MSDC50_0_SEL>;
+   assigned-clock-parents = < CLK_TOP_MSDCPLL_D2>;
non-removable;
 };
 
@@ -84,9 +89,10 @@
pinctrl-0 = <_pins_default>;
pinctrl-1 = <_pins_uhs>;
bus-width = <4>;
-   max-frequency = <5000>;
+   max-frequency = <2>;
cap-sd-highspeed;
-   sd-uhs-sdr25;
+   sd-uhs-sdr50;
+   sd-uhs-sdr104;
cd-gpios = < 132 0>;
vmmc-supply = <_vmch_reg>;
vqmmc-supply = <_vmc_reg>;
@@ -155,13 +161,19 @@
 ,
 ;
input-enable;
-   drive-strength = ;
+   drive-strength = ;
bias-pull-up = ;
};
 
pins_clk {
pinmux = ;
-   drive-strength = ;
+   drive-strength = ;
+   bias-pull-down = ;
+   };
+
+   pins_ds {
+   pinmux = ;
+   drive-strength = ;
bias-pull-down = ;
};
 
@@ -179,13 +191,13 @@
 ,
 ;
input-enable;
-   drive-strength = ;
+   drive-strength = ;
bias-pull-up = ;
};
 
pins_clk {
pinmux = ;
-   drive-strength = ;
+   drive-strength = ;
bias-pull-down = ;
};
};
-- 
1.8.1.1.dirty

--
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 09/10] mmc: mediatek: add HS400 support

[Chaotian Jing]

add HS400 mode and tune support

Signed-off-by: Chaotian Jing 
---
 drivers/mmc/host/mtk-sd.c | 249 +-
 1 file changed, 244 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 5627644..39568cc 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -72,6 +73,8 @@
 #define MSDC_PATCH_BIT   0xb0
 #define MSDC_PATCH_BIT1  0xb4
 #define MSDC_PAD_TUNE0xec
+#define PAD_DS_TUNE  0x188
+#define EMMC50_CFG0  0x208
 
 /*--*/
 /* Register Mask*/
@@ -88,6 +91,7 @@
 #define MSDC_CFG_CKSTB  (0x1 << 7) /* R  */
 #define MSDC_CFG_CKDIV  (0xff << 8)/* RW */
 #define MSDC_CFG_CKMOD  (0x3 << 16)/* RW */
+#define MSDC_CFG_HS400_CK_MODE  (0x1 << 18)/* RW */
 
 /* MSDC_IOCON mask */
 #define MSDC_IOCON_SDR104CKS(0x1 << 0) /* RW */
@@ -205,6 +209,17 @@
 #define MSDC_PATCH_BIT_SPCPUSH(0x1 << 29)  /* RW */
 #define MSDC_PATCH_BIT_DECRCTMO   (0x1 << 30)  /* RW */
 
+#define MSDC_PAD_TUNE_DATRRDLY   (0x1f <<  8)  /* RW */
+#define MSDC_PAD_TUNE_CMDRDLY(0x1f << 16)  /* RW */
+
+#define PAD_DS_TUNE_DLY1 (0x1f << 2)   /* RW */
+#define PAD_DS_TUNE_DLY2 (0x1f << 7)   /* RW */
+#define PAD_DS_TUNE_DLY3 (0x1f << 12)  /* RW */
+
+#define EMMC50_CFG_PADCMD_LATCHCK (0x1 << 0)   /* RW */
+#define EMMC50_CFG_CRCSTS_EDGE(0x1 << 3)   /* RW */
+#define EMMC50_CFG_CFCSTS_SEL (0x1 << 4)   /* RW */
+
 #define REQ_CMD_EIO  (0x1 << 0)
 #define REQ_CMD_TMO  (0x1 << 1)
 #define REQ_DAT_ERR  (0x1 << 2)
@@ -220,6 +235,7 @@
 #define CMD_TIMEOUT (HZ/10 * 5)/* 100ms x5 */
 #define DAT_TIMEOUT (HZ* 5)/* 1000ms x5 */
 
+#define PAD_DELAY_MAX  32 /* PAD delay cells */
 /*--*/
 /* Descriptor Structure */
 /*--*/
@@ -266,6 +282,14 @@ struct msdc_save_para {
u32 pad_tune;
u32 patch_bit0;
u32 patch_bit1;
+   u32 pad_ds_tune;
+   u32 emmc50_cfg0;
+};
+
+struct msdc_delay_phase {
+   u8 maxlen;
+   u8 start;
+   u8 final_phase;
 };
 
 struct msdc_host {
@@ -300,6 +324,7 @@ struct msdc_host {
u32 sclk;   /* SD/MS bus clock frequency */
unsigned char timing;
bool vqmmc_enabled;
+   u32 hs400_ds_delay;
struct msdc_save_para save_para; /* used when gate HCLK */
 };
 
@@ -505,9 +530,15 @@ static void msdc_set_mclk(struct msdc_host *host, unsigned 
char timing, u32 hz)
 
flags = readl(host->base + MSDC_INTEN);
sdr_clr_bits(host->base + MSDC_INTEN, flags);
+   sdr_clr_bits(host->base + MSDC_CFG, MSDC_CFG_HS400_CK_MODE);
if (timing == MMC_TIMING_UHS_DDR50 ||
-   timing == MMC_TIMING_MMC_DDR52) {
-   mode = 0x2; /* ddr mode and use divisor */
+   timing == MMC_TIMING_MMC_DDR52 ||
+   timing == MMC_TIMING_MMC_HS400) {
+   if (timing == MMC_TIMING_MMC_HS400)
+   mode = 0x3;
+   else
+   mode = 0x2; /* ddr mode and use divisor */
+
if (hz >= (host->src_clk_freq >> 2)) {
div = 0; /* mean div = 1/4 */
sclk = host->src_clk_freq >> 2; /* sclk = clk / 4 */
@@ -516,6 +547,14 @@ static void msdc_set_mclk(struct msdc_host *host, unsigned 
char timing, u32 hz)
sclk = (host->src_clk_freq >> 2) / div;
div = (div >> 1);
}
+
+   if (timing == MMC_TIMING_MMC_HS400 &&
+   hz >= (host->src_clk_freq >> 1)) {
+   sdr_set_bits(host->base + MSDC_CFG,
+MSDC_CFG_HS400_CK_MODE);
+   sclk = host->src_clk_freq >> 1;
+   div = 0; /* div is ignore when bit18 is set */
+   }
} else if (hz >= host->src_clk_freq) {
mode = 0x1; /* no divisor */
div = 0;
@@ -894,7 +933,7 @@ static void msdc_data_xfer_next(struct msdc_host *host,
struct mmc_request *mrq, struct mmc_data *data)
 {
if (mmc_op_multi(mrq->cmd->opcode) && mrq->stop && !mrq->stop->error &&
-   (!data->bytes_xfered || !mrq->sbc))
+   !mrq->sbc)
msdc_start_command(host, mrq, mrq->stop);
else
msdc_request_done(host, mrq);
@@ -940,6 +979,8 @@ static bool msdc_data_xfer_done(struct msdc_host *host, u32 
events,
 
if (events & MSDC_INT_DATTMO)
  

[PATCH v3 01/10] mmc: core: Add DT bindings for eMMC hardware reset support

[Chaotian Jing]

Sometime only need set MMC_CAP_HW_RESET for one of MMC hosts,
So set it in device tree is better.

Signed-off-by: Chaotian Jing 
---
 Documentation/devicetree/bindings/mmc/mmc.txt | 1 +
 drivers/mmc/core/host.c   | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
b/Documentation/devicetree/bindings/mmc/mmc.txt
index 0384fc3..f693baf 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -37,6 +37,7 @@ Optional properties:
 - sd-uhs-sdr104: SD UHS SDR104 speed is supported
 - sd-uhs-ddr50: SD UHS DDR50 speed is supported
 - cap-power-off-card: powering off the card is safe
+- cap-mmc-hw-reset: eMMC hardware reset is supported
 - cap-sdio-irq: enable SDIO IRQ signalling on this interface
 - full-pwr-cycle: full power cycle of the card is supported
 - mmc-ddr-1_8v: eMMC high-speed DDR mode(1.8V I/O) is supported
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index abd933b..04fdc2f 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -507,6 +507,8 @@ int mmc_of_parse(struct mmc_host *host)
host->caps |= MMC_CAP_UHS_DDR50;
if (of_property_read_bool(np, "cap-power-off-card"))
host->caps |= MMC_CAP_POWER_OFF_CARD;
+   if (of_property_read_bool(np, "cap-mmc-hw-reset"))
+   host->caps |= MMC_CAP_HW_RESET;
if (of_property_read_bool(np, "cap-sdio-irq"))
host->caps |= MMC_CAP_SDIO_IRQ;
if (of_property_read_bool(np, "full-pwr-cycle"))
-- 
1.8.1.1.dirty

--
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 06/10] mmc: mediatek: add implement of ops->hw_reset()

[Chaotian Jing]

add implement of ops->hw_reset() for eMMC

Signed-off-by: Chaotian Jing 

---
 drivers/mmc/host/mtk-sd.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 3858163..5627644 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -64,6 +64,7 @@
 #define SDC_RESP20x48
 #define SDC_RESP30x4c
 #define SDC_BLK_NUM  0x50
+#define EMMC_IOCON   0x7c
 #define SDC_ACMD_RESP0x80
 #define MSDC_DMA_SA  0x90
 #define MSDC_DMA_CTRL0x98
@@ -1209,6 +1210,15 @@ end:
pm_runtime_put_autosuspend(host->dev);
 }
 
+static void msdc_hw_reset(struct mmc_host *mmc)
+{
+   struct msdc_host *host = mmc_priv(mmc);
+
+   sdr_set_bits(host->base + EMMC_IOCON, 1);
+   udelay(10); /* 10us is enough */
+   sdr_clr_bits(host->base + EMMC_IOCON, 1);
+}
+
 static struct mmc_host_ops mt_msdc_ops = {
.post_req = msdc_post_req,
.pre_req = msdc_pre_req,
@@ -1216,6 +1226,7 @@ static struct mmc_host_ops mt_msdc_ops = {
.set_ios = msdc_ops_set_ios,
.start_signal_voltage_switch = msdc_ops_switch_volt,
.card_busy = msdc_card_busy,
+   .hw_reset = msdc_hw_reset,
 };
 
 static int msdc_drv_probe(struct platform_device *pdev)
-- 
1.8.1.1.dirty

--
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] regulator, dt: add dt support for tps6502x regulator

[Mark Brown]

On Tue, Oct 27, 2015 at 07:23:09AM +0100, Heiko Schocher wrote:
> Am 27.10.2015 um 03:12 schrieb Mark Brown:

> >Please use subject lines matching the style for the subsystem.

> Would be "regulator: tps6520x:" correct?

Yes.

> >>+   regulators = of_get_child_by_name(np, "regulators");
> >>+   if (!regulators) {
> >>+   dev_err(dev, "regulator node not found\n");
> >>+   return NULL;
> >>+   }

> >Please use the generic support for locating the DT information for
> >regulators using regulators_node and of_match in the regulator_desc
> >rather than open coding this.

> Hmm.. could you point me to a correct example? Seems I overlook sth.

$ grep -l regulators_node drivers/regulator/*.c
drivers/regulator/88pm800.c
drivers/regulator/axp20x-regulator.c
drivers/regulator/da9062-regulator.c
drivers/regulator/isl9305.c
drivers/regulator/max14577.c
drivers/regulator/max77686.c
drivers/regulator/max77693.c
drivers/regulator/max77802.c
drivers/regulator/mt6311-regulator.c
drivers/regulator/of_regulator.c
drivers/regulator/rn5t618-regulator.c
drivers/regulator/rt5033-regulator.c
drivers/regulator/sky81452-regulator.c
drivers/regulator/tps65217-regulator.c


signature.asc
Description: PGP signature

[PATCH v1 3/3] ARM64: dts: rk3368: Add mailbox device nodes

[Caesar Wang]

This adds mailbox device nodes in dts.

Mailbox is used by the Rockchip CPU cores to communicate
requests to MCU processor.

Signed-off-by: Caesar Wang 
---

Changes in v1:
- PATCH[3/3] dts:
- fix "processormZ"--> "processor",the miss-fingerboard.
- Remove the shared memory in mailbox controller dtsi.

 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index cc093a4..cefdad3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -484,6 +484,18 @@
status = "disabled";
};
 
+   mbox: mbox@ff6b {
+   compatible = "rockchip,rk3368-mailbox";
+   reg = <0x0 0xff6b 0x0 0x1000>,
+   interrupts = ,
+,
+,
+;
+   clocks = < PCLK_MAILBOX>;
+   clock-names = "pclk_mailbox";
+   #mbox-cells = <1>;
+   };
+
pmugrf: syscon@ff738000 {
compatible = "rockchip,rk3368-pmugrf", "syscon";
reg = <0x0 0xff738000 0x0 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: [PATCH v2 1/4] DT: nvmem: Add NXP LPC18xx EEPROM memory binding documentation

[Rob Herring]

On Mon, Oct 19, 2015 at 12:32 PM, Ariel D'Alessandro
 wrote:
> Add the devicetree binding document for NXP LPC18xx EEPROM memory.
>
> Signed-off-by: Ariel D'Alessandro 

Acked-by: Rob Herring 

> ---
>  .../devicetree/bindings/nvmem/lpc1857-eeprom.txt   | 26 
> ++
>  1 file changed, 26 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/lpc1857-eeprom.txt
>
> diff --git a/Documentation/devicetree/bindings/nvmem/lpc1857-eeprom.txt 
> b/Documentation/devicetree/bindings/nvmem/lpc1857-eeprom.txt
> new file mode 100644
> index 000..01cde0d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/lpc1857-eeprom.txt
> @@ -0,0 +1,26 @@
> +* NXP LPC18xx EEPROM memory NVMEM driver
> +
> +Required properties:
> +  - compatible: Should be "nxp,lpc1857-eeprom"
> +  - reg: Must contain an entry with the physical base address and length
> +for each entry in reg-names.
> +  - reg-names: Must include the following entries.
> +- reg: EEPROM registers.
> +- mem: EEPROM address space.
> +  - clocks: Must contain an entry for each entry in clock-names.
> +  - clock-names: Must include the following entries.
> +- eeprom: EEPROM operating clock.
> +  - interrupts: Should contain EEPROM interrupt.
> +
> +Example:
> +
> +  eeprom: eeprom@4000e000 {
> +compatible = "nxp,lpc1857-eeprom";
> +reg = <0x4000e000 0x1000>,
> +  <0x2004 0x4000>;
> +reg-names = "reg", "mem";
> +clocks = < CLK_CPU_EEPROM>;
> +clock-names = "eeprom";
> +resets = < 27>;
> +interrupts = <4>;
> +  };
> --
> 2.6.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 1/3] devicetree: mfd: Add binding for the TI LM3533

[Rob Herring]

On Sun, Oct 25, 2015 at 1:09 PM, Bjorn Andersson
 wrote:
> Add the binding for the Texas Instruments LM3533 lighting power
> solution.
>
> Signed-off-by: Bjorn Andersson 
> ---
>  Documentation/devicetree/bindings/mfd/lm3533.txt | 183 
> +++
>  1 file changed, 183 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/lm3533.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/lm3533.txt 
> b/Documentation/devicetree/bindings/mfd/lm3533.txt
> new file mode 100644
> index ..3cc41695a544
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/lm3533.txt
> @@ -0,0 +1,183 @@
> +Texas Instruments LM3533 binding
> +
> +This binding describes the Texas Instruments LM3533, a lighting power 
> solution
> +for smartphone handsets. The common properties are described directly in the
> +node, while each individual component are described in an optional subnode.
> +
> +- compatible:
> +   Usage: required
> +   Value type: 
> +   Definition: must be:
> +   "ti,lm3533"
> +
> +- reg:
> +   Usage: required
> +   Value type: 
> +   Definition: i2c address of the LM3533 chip
> +
> +- ti,hwen-gpios:
> +   Usage: required
> +   Value type: 
> +   Definition: reference to gpio pin connected to the HWEN input; as
> +   specified in "gpio/gpio.txt"
> +
> +- ti,als-supply:
> +   Usage: optional
> +   Value type: 
> +   Definition: reference to regulator powering the V_als input; as
> +   specified in "regulator/regulator.txt"
> +
> +- ti,boost-freq:

Append "-hz".

> +   Usage: required
> +   Value type: 
> +   Definition: switch-frequency of the boost converter, must be either:
> +   50 or 100
> +
> +- ti,boost-ovp:
> +   Usage: required
> +   Value type: 
> +   Definition: over voltage protection limit, must be one of: 16, 24, 32
> +   or 40
> +
> +- #address-cells:
> +   Usage: required
> +   Value type: 
> +   Definition: must be 1
> +
> +- #size-cells:
> +   Usage: required
> +   Value type: 
> +   Definition: must be 0
> +
> += ALS SUBNODE
> +The als subnode must be named "als", it carries the als related properties.
> +
> +- ti,als-resistance:
> +   Usage: required (unless ti,pwm-mode is specified)
> +   Value type: 
> +   Definition: specifies the resistor value (R_als), in Ohm. Valid values
> +   ranges from 200kOhm to 1574Ohm.

So append "-kohm"?

> +
> +- ti,pwm-mode:
> +   Usage: optional
> +   Value type: 
> +   Definition: specifies, if present, that the als should operate in pwm
> +   mode - rather than analog mode
> +
> += BACKLIGHT NODES
> +Backlight subnodes must be named "backlight", they carry the backlight 
> related
> +properties.
> +
> +- reg:
> +   Usage: required
> +   Value type: 
> +   Definition: specifies which of the two backlights this node 
> corresponds
> +   to
> +
> +- default-brightness:
> +   Usage: optional
> +   Value type: <32>
> +   Definition: specifies the default brightness for the backlight, in
> +   units of brightness [0-255]
> +
> +- label:
> +   Usage: required
> +   Value type: 
> +   Definition: specifies a name of this backlight
> +
> +- led-max-microamp:
> +   Usage: required
> +   Value type: 
> +   Definition: specifies the max current for this backlight, in uA, as
> +   described in "leds/common.txt"
> +
> +- ti,pwm-zones:
> +   Usage: optional
> +   Value type: 
> +   Definition: lists the ALS zones to be PWM controlled for this 
> backlight,
> +   the values in the list are in the range [0 - 4]
> +
> += LED NODES
> +LED subnodes must be named "led", they carry the LED related properties.
> +
> +- reg:
> +   Usage: required
> +   Value type: 
> +   Definition: specifies which of the four LEDs this node corresponds to
> +
> +- linux,default-trigger:
> +   Usage: optional
> +   Value type: 
> +   Definition: specifies the default trigger for the LED, as described in
> +   "leds/common.txt"
> +
> +- label:
> +   Usage: required
> +   Value type: 
> +   Definition: specifies a name of this LED, as described in
> +   "leds/common.txt"
> +
> +- led-max-microamp:
> +   Usage: required
> +   Value type: 
> +   Definition: specifies the max current for this LED, in uA, as 
> described
> +   in "leds/common.txt"
> +
> +- ti,pwm-zones:
> +   Usage: optional
> +   Value type: 
> +   Definition: lists the ALS zones to be PWM controlled for this LED, the
> +   values in the list are in the range [0 - 4]
> +
> += EXAMPLE
> +
> +i2c@1246 {
> +   compatible = 

Re: [PATCH v4 1/5] [RFC] clk: shmobile: Add new Renesas CPG/MSSR DT bindings

[Geert Uytterhoeven]

Hi Laurent,

CC linux-pm

On Tue, Oct 27, 2015 at 2:34 AM, Laurent Pinchart
 wrote:
> On Monday 26 October 2015 20:02:45 Geert Uytterhoeven wrote:
>> On Fri, Oct 23, 2015 at 1:10 PM, Laurent Pinchart wrote:
>> > On Friday 16 October 2015 14:49:16 Geert Uytterhoeven wrote:
>> >> On Renesas ARM SoCs (SH/R-Mobile, R-Car, RZ), the CPG (Clock Pulse
>> >> Generator) and MSSR (Module Standby and Software Reset) blocks are
>> >> intimately connected, and share the same register block.
>> >>
>> >> Hence it makes sense to describe these two blocks using a
>> >> single device node in DT, instead of using a hierarchical structure with
>> >> multiple nodes, using a mix of generic and SoC-specific bindings.
>> >>
>> >> These new DT bindings are intended to replace the existing DT bindings
>> >> for CPG core clocks ("renesas,*-cpg-clocks", "renesas,cpg-div6-clock")
>> >> and module clocks ("renesas,*-mstp-clocks"), at least for new SoCs.
>> >>
>> >> This will make it easier to add module reset support later, which is
>> >> currently not implemented, and difficult to achieve using the existing
>> >> bindings due to the intertwined register layout.
>> >>
>> >> Signed-off-by: Geert Uytterhoeven 
>> >>
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
>> >> @@ -0,0 +1,71 @@
>> >> +* Renesas Clock Pulse Generator / Module Standby and Software Reset
>> >> +
>> >> +On Renesas ARM SoCs (SH/R-Mobile, R-Car, RZ), the CPG (Clock Pulse
>> >> Generator)
>> >> +and MSSR (Module Standby and Software Reset) blocks are intimately
>> >> connected,
>> >> +and share the same register block.
>> >> +
>> >> +They provide the following functionalities:
>> >> +  - The CPG block generates various core clocks,
>> >> +  - The MSSR block provides two functions:
>> >> +  1. Module Standby, providing a Clock Domain to control the clock
>> >> supply
>> >> +  to individual SoC devices,
>> >> +  2. Reset Control, to perform a software reset of individual SoC
>> >> devices.
>>
>> [...]
>>
>> >> +  - #power-domain-cells: Must be 0
>> >> +  - SoC devices that are part of the CPG/MSSR Clock Domain and can
>> >> be
>> >> + power-managed through Module Standby should refer to the CPG device
>> >> + node in their "power-domains" property, as documented by the
>> >> generic PM + Domain bindings in
>> >> + Documentation/devicetree/bindings/power/power_domain.txt.
>> >> +
>> >> +
>> >> +Examples
>> >> +
>> >> +
>> >> +  - CPG device node:
>> >> +
>> >> + cpg: clock-controller@e615 {
>> >> + compatible = "renesas,r8a7795-cpg-mssr";
>> >> + reg = <0 0xe615 0 0x1000>;
>> >> + clocks = <_clk>, <_clk>;
>> >> + clock-names = "extal", "extalr";
>> >> + #clock-cells = <2>;
>> >> + #power-domain-cells = <0>;
>> >> + };
>> >> +
>> >> +
>> >
>> >> +  - CPG/MSSR Clock Domain member device node:
>> > Would it make sense to show two examples, one for a device whose driver
>> > manages the MSTP clock manually, and another one for a device whose driver
>> > delegates that to the power domain ?
>> >
>> > I hate using the word driver in DT bindings, but unfortunately that's
>> > essentially what it boils down to here as the decision to specify the
>> > power domain is really based on the driver, not on the hardware.
>>
>> IMHO it's not the driver, but the on-SoC module and its representation in
>> DT. Cfr. commit 797a0626e08ca4af ("ARM: shmobile: r8a7791 dtsi: Add
>> CPG/MSTP Clock Domain", which states:
>>
>> |   Add "power-domains" properties to all device nodes for devices that are
>> |   part of the CPG/MSTP Clock Domain and can be power-managed through an
>> |   MSTP clock.  This applies to most on-SoC devices, which have a
>> |   one-to-one mapping from SoC device to DT device node.  Notable
>> |   exceptions are the "display" and "sound" nodes, which represent multiple
>> |   SoC devices, each having their own MSTP clocks.
>
> You're quoting your own documentation to support your point, that's not fair
> :-)

I quoted it because it explains what was done.

> We're using power domains to gate clocks. The fact that it's not related to
> power supplies can already be borderline, but I can buy the argument that
> clocks relate to power consumption here. However, where the power domain
> abstraction is really abused is that we're adding all kind of devices to a
> single power domain while they're controlled by one clock gate each. That's a
> software hack, and we're using DT to tell whether our core code should control
> clock gating or not. That's not a hardware description, sorry.

IMHO the "power-domains" property naming is wrong: it should have been
"pm-domains", as it's following the spirit of the Linux PM Domain abstraction.

PM Domain = Collection of devices treated similarly w.r.t. power management

"similarly" here means "using module clocks". 

Re: [v2 03/10] ata: ahci_brcmstb: add quick for broken phy

[Rob Herring]

On Tue, Oct 27, 2015 at 1:48 AM, Jaedon Shin  wrote:
> Add quick for broken phy. The ARM-based 28nm chipsets have four phy

I believe you mean "quirk".

> interface control registers and each port has two registers. But, The

registers, but the...

> MIPS-based 40nm chipsets have three. and there are no information and

s/and there/There/

> documentation. The legacy version of broadcom's strict-ahci based
> initial code did not control these registers.
>
> Signed-off-by: Jaedon Shin 
> ---
>  Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt |  1 +

Other than the commit message:

Acked-by: Rob Herring 

>  drivers/ata/ahci_brcmstb.c  | 10 ++
>  2 files changed, 11 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt 
> b/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt
> index 488a383ce202..0f0925d58188 100644
> --- a/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt
> +++ b/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt
> @@ -12,6 +12,7 @@ Required properties:
>
>  Optional properties:
>  - brcm,broken-ncq: if present, NCQ is unusable
> +- brcm,broken-phy: if present, to control phy interface is unusable
>
>  Also see ahci-platform.txt.
>
> diff --git a/drivers/ata/ahci_brcmstb.c b/drivers/ata/ahci_brcmstb.c
> index e53962cb48ee..c61303f7c7dc 100644
> --- a/drivers/ata/ahci_brcmstb.c
> +++ b/drivers/ata/ahci_brcmstb.c
> @@ -71,6 +71,7 @@
>
>  enum brcm_ahci_quicks {
> BRCM_AHCI_QUICK_NONCQ   = BIT(0),
> +   BRCM_AHCI_QUICK_NOPHY   = BIT(1),
>  };
>
>  struct brcm_ahci_priv {
> @@ -119,6 +120,9 @@ static void brcm_sata_phy_enable(struct brcm_ahci_priv 
> *priv, int port)
> void __iomem *p;
> u32 reg;
>
> +   if (priv->quicks & BRCM_AHCI_QUICK_NOPHY)
> +   return;
> +
> /* clear PHY_DEFAULT_POWER_STATE */
> p = phyctrl + SATA_TOP_CTRL_PHY_CTRL_1;
> reg = brcm_sata_readreg(p);
> @@ -148,6 +152,9 @@ static void brcm_sata_phy_disable(struct brcm_ahci_priv 
> *priv, int port)
> void __iomem *p;
> u32 reg;
>
> +   if (priv->quicks & BRCM_AHCI_QUICK_NOPHY)
> +   return;
> +
> /* power-off the PHY digital logic */
> p = phyctrl + SATA_TOP_CTRL_PHY_CTRL_2;
> reg = brcm_sata_readreg(p);
> @@ -297,6 +304,9 @@ static int brcm_ahci_probe(struct platform_device *pdev)
> if (of_property_read_bool(dev->of_node, "brcm,broken-ncq"))
> priv->quicks |= BRCM_AHCI_QUICK_NONCQ;
>
> +   if (of_property_read_bool(dev->of_node, "brcm,broken-phy"))
> +   priv->quicks |= BRCM_AHCI_QUICK_NOPHY;
> +
> brcm_sata_init(priv);
> brcm_sata_quick(pdev, priv);
>
> --
> 2.6.2
>
--
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 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib

[Boris Brezillon]

Hi Brian,

On Mon, 26 Oct 2015 13:49:00 -0700
Brian Norris  wrote:

> + others
> 
> A few comments below.
> 
> On Fri, Sep 18, 2015 at 05:53:40PM +0300, Roger Quadros wrote:
> > The GPMC WAIT pin status are now available over gpiolib.
> > Update the omap_dev_ready() function to use gpio instead of
> > directly accessing GPMC register space.
> > 
> > Signed-off-by: Roger Quadros 
> > ---
> >  drivers/mtd/nand/omap2.c | 29 
> > +---
> >  include/linux/platform_data/mtd-nand-omap2.h |  2 +-
> >  2 files changed, 19 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> > index 228f498..d0f2620 100644
> > --- a/drivers/mtd/nand/omap2.c
> > +++ b/drivers/mtd/nand/omap2.c
> > @@ -12,6 +12,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -184,6 +185,8 @@ struct omap_nand_info {
> > /* fields specific for BCHx_HW ECC scheme */
> > struct device   *elm_dev;
> > struct device_node  *of_node;
> > +   /* NAND ready gpio */
> > +   struct gpio_desc*ready_gpiod;
> >  };
> >  
> >  /**
> > @@ -1047,22 +1050,17 @@ static int omap_wait(struct mtd_info *mtd, struct 
> > nand_chip *chip)
> >  }
> >  
> >  /**
> > - * omap_dev_ready - calls the platform specific dev_ready function
> > + * omap_dev_ready - checks the NAND Ready GPIO line
> >   * @mtd: MTD device structure
> > + *
> > + * Returns true if ready and false if busy.
> >   */
> >  static int omap_dev_ready(struct mtd_info *mtd)
> >  {
> > -   unsigned int val = 0;
> > struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
> > mtd);
> >  
> > -   val = readl(info->reg.gpmc_status);
> > -
> > -   if ((val & 0x100) == 0x100) {
> > -   return 1;
> > -   } else {
> > -   return 0;
> > -   }
> > +   return gpiod_get_value(info->ready_gpiod);
> >  }
> >  
> >  /**
> > @@ -1782,7 +1780,9 @@ static int omap_nand_probe(struct platform_device 
> > *pdev)
> > info->reg = pdata->reg;
> > info->of_node = pdata->of_node;
> > info->ecc_opt = pdata->ecc_opt;
> > -   info->dev_ready = pdata->dev_ready;
> > +   if (pdata->dev_ready)
> > +   dev_info(>dev, "pdata->dev_ready is 
> > deprecated\n");
> > +
> > info->xfer_type = pdata->xfer_type;
> > info->devsize = pdata->devsize;
> > info->elm_of_node = pdata->elm_of_node;
> > @@ -1815,6 +1815,13 @@ static int omap_nand_probe(struct platform_device 
> > *pdev)
> > nand_chip->IO_ADDR_W = nand_chip->IO_ADDR_R;
> > nand_chip->cmd_ctrl  = omap_hwcontrol;
> >  
> > +   info->ready_gpiod = devm_gpiod_get_optional(>dev, "ready",
> > +   GPIOD_IN);
> 
> Others have been looking at using GPIOs for the ready/busy pin too. At a
> minimum, we need an updated DT binding doc for this, since I see you're
> adding this via device tree in a later patch (I don't see any DT binding
> patch for this; but I could just be overlooking it). It'd also be great
> if this support was moved to nand_dt_init() so other platforms can
> benefit, but I won't require that.

Actually I started to work on a generic solution parsing the DT and
creating CS, WP and RB gpios when they are provided, but I think it's a
bit more complicated than just moving the rb-gpios parsing into
nand_dt_init().
First you'll need something to store your gpio_desc pointers, which
means you'll have to allocate a table of gpio_desc pointers (or a table
of struct embedding a gpio_desc pointer).
The other blocking point is that when nand_scan_ident() is called, the
caller is supposed to have filled the ->dev_ready() or ->waitfunc()
fields, and to choose how to implement it he may need to know
which kind of RB handler should be used (this is the case in the sunxi
driver, where the user can either use a GPIO or native R/B pin directly
connected to the controller).

All this makes me think that maybe nand_dt_init() should be called
separately or in a different helper (nand_init() ?) taking care of the
basic nand_chip initializations/allocations without interacting with
the NAND itself.

Another solution would be to add an ->init() function to nand_chip
and call it after the generic initialization has been done (but before
NAND chip detection). This way the NAND controller driver could adapt
some fields and parse controller specific properties.

What do you think?

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 v5 2/2] iio: ti-ads8688: Add DT binding documentation

[Sean Nyekjaer]

Adding binding documentation for Texas Instruments ADS8688 ADC.

Signed-off-by: Sean Nyekjaer 
Reviewed-by: Martin Hundebøll 
---
Changes since v2:
- Moved vref-supply to Optional properties

 .../devicetree/bindings/iio/adc/ti-ads8688.txt   | 20 
 1 file changed, 20 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/ti-ads8688.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/ti-ads8688.txt 
b/Documentation/devicetree/bindings/iio/adc/ti-ads8688.txt
new file mode 100644
index 000..a02337d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ti-ads8688.txt
@@ -0,0 +1,20 @@
+* Texas Instruments' ADS8684 and ADS8688 ADC chip
+
+Required properties:
+ - compatible: Should be "ti,ads8684" or "ti,ads8688"
+ - reg: spi chip select number for the device
+
+Recommended properties:
+ - spi-max-frequency: Definition as per
+   Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Optional properties:
+ - vref-supply: The regulator supply for ADC reference voltage
+
+Example:
+adc@0 {
+   compatible = "ti,ads8688";
+   reg = <0>;
+   vref-supply = <_supply>;
+   spi-max-frequency = <100>;
+};
-- 
2.6.2

--
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 00/10] Add tune support of Mediatek MMC driver

[Chaotian Jing]

Change in v3:
Fix checkpatch errors and warnings for patch 8
Split patch 9, make DT parts enabling hw reset separately

Change in v2:
Drop the 400mhz and use assigned-clock-parents to instead
Split the original tune patch to several independent patches
Re-write the mmc_send_tuning()
Fix GPD checksum error
Move the HS400 setting to ops->prepare_hs400_tuning()   
Modify SD driving settings

Change in v1:
Add DT bindings for eMMC hardware reset
Add pinctrl of data strobe pin for HS400 mode
Modify eMMC driving settings
Add 400mhz source clock for HS400 mode
Add eMMC HS200/HS400 mode support
Add SD SDR50/SDR104 mode support
Add implement of tune function with CMD19/CMD21

Chaotian Jing (10):
  mmc: core: Add DT bindings for eMMC hardware reset support
  mmc: dt-bindings: update Mediatek MMC bindings
  mmc: mediatek: make cmd_ints_mask to const
  mmc: mediatek: change the argument "ddr" to "timing"
  mmc: mediatek: fix got GPD checksum error interrupt when data transfer
  mmc: mediatek: add implement of ops->hw_reset()
  arm64: dts: mediatek: add eMMC hw reset support
  mmc: mmc: extend the mmc_send_tuning()
  mmc: mediatek: add HS400 support
  arm64: dts: mediatek: add HS200/HS400/SDR50/SDR104 support

 Documentation/devicetree/bindings/mmc/mmc.txt|   1 +
 Documentation/devicetree/bindings/mmc/mtk-sd.txt |  11 +-
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts  |  27 +-
 drivers/mmc/core/host.c  |   2 +
 drivers/mmc/core/mmc_ops.c   |   8 +-
 drivers/mmc/host/dw_mmc-exynos.c |   4 +-
 drivers/mmc/host/dw_mmc.c|   2 +-
 drivers/mmc/host/dw_mmc.h|   2 +-
 drivers/mmc/host/mtk-sd.c| 304 ---
 drivers/mmc/host/sdhci-esdhc-imx.c   |   6 +-
 drivers/mmc/host/sdhci-msm.c |   2 +-
 drivers/mmc/host/sdhci-sirf.c|   2 +-
 include/linux/mmc/core.h |   2 +-
 13 files changed, 322 insertions(+), 51 deletions(-)

-- 
1.8.1.1.dirty

--
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

[v2 10/10] MIPS: BMIPS: brcmstb: add SATA/PHY nodes for bcm7362

[Jaedon Shin]

Add AHCI and PHY device nodes to MIPS-based BCM7362 set-top box
platform.

Signed-off-by: Jaedon Shin 
---
 arch/mips/boot/dts/brcm/bcm7362.dtsi | 42 
 arch/mips/boot/dts/brcm/bcm97362svmb.dts |  8 ++
 2 files changed, 50 insertions(+)

diff --git a/arch/mips/boot/dts/brcm/bcm7362.dtsi 
b/arch/mips/boot/dts/brcm/bcm7362.dtsi
index 6e65db86fc61..53b73de9066c 100644
--- a/arch/mips/boot/dts/brcm/bcm7362.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7362.dtsi
@@ -189,5 +189,47 @@
interrupts = <66>;
status = "disabled";
};
+
+   sata: sata@181000 {
+   compatible = "brcm,bcm7425-ahci", "brcm,sata3-ahci";
+   reg-names = "ahci", "top-ctrl";
+   reg = <0x181000 0xa9c>, <0x180020 0x1c>;
+   interrupt-parent = <_intc>;
+   interrupts = <86>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   brcm,broken-ncq;
+   brcm,broken-phy;
+   status = "disabled";
+
+   sata0: sata-port@0 {
+   reg = <0>;
+   phys = <_phy0>;
+   };
+
+   sata1: sata-port@1 {
+   reg = <1>;
+   phys = <_phy1>;
+   };
+   };
+
+   sata_phy: sata-phy@180 {
+   compatible = "brcm,bcm7425-sata-phy", "brcm,phy-sata3";
+   reg = <0x180100 0x0eff>;
+   reg-names = "phy";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+
+   sata_phy0: sata-phy@0 {
+   reg = <0>;
+   #phy-cells = <0>;
+   };
+
+   sata_phy1: sata-phy@1 {
+   reg = <1>;
+   #phy-cells = <0>;
+   };
+   };
};
 };
diff --git a/arch/mips/boot/dts/brcm/bcm97362svmb.dts 
b/arch/mips/boot/dts/brcm/bcm97362svmb.dts
index 739c2ef5663b..ef9a69b79bc4 100644
--- a/arch/mips/boot/dts/brcm/bcm97362svmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97362svmb.dts
@@ -40,3 +40,11 @@
  {
status = "okay";
 };
+
+ {
+   status = "okay";
+};
+
+_phy {
+   status = "okay";
+};
-- 
2.6.2

--
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] mtd: ofpart: drop undocumented, nonfunctional 'lock' property

[Sascha Hauer]

Hi Brian,

On Mon, Oct 26, 2015 at 06:56:06PM -0700, Brian Norris wrote:
> The 'lock' property of a partition does nothing, because it effectively
> only sets the flags for the partition device, not the master device. And
> no MTD driver checks for MTD_POWERUP_LOCK in the partition device, only
> the master device.

This is not true. The flag gets checked in add_mtd_device:

/* Some chips always power up locked. Unlock them now */
if ((mtd->flags & MTD_WRITEABLE) && (mtd->flags & MTD_POWERUP_LOCK)) {
error = mtd_unlock(mtd, 0, mtd->size);
...
}

add_mtd_device() is called either for the master mtd device or for each
partition (if there are partitions). The flow is like that:

- Some flash devices come up locked from power on. Drivers for these
  devices set the MTD_POWERUP_LOCK flag (cfi_cmdset_0001.c,
  cfi_cmdset_0002.c)
- The partitions inherit the flags from the master device, but not the
  ones set in mask_flags:

ofpart.c:

if (of_get_property(pp, "lock", ))
(*pparts)[i].mask_flags |= MTD_POWERUP_LOCK;

mtdpart.c:

slave->mtd.flags = master->flags & ~part->mask_flags;

- So if the lock property is not set then the MTD_POWERUP_LOCK flag is
  still set in add_mtd_device() for the partition and the corresponding
  partition is not unlocked. Otherwise the partition is unlocked.

So how I see it the mechanism is still functional, except that it's
broken when the recently introduced option MTD_PARTITIONED_MASTER is
set. When it's set then add_mtd_device() is called for the master device
aswell and the whole device gets unlocked. When the partitions are
registered later then it makes no difference whether they are unlocked
or not, they are already unlocked anyway.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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 01/10] pwm: lpc18xx_pwm: use pwm_set_chip_data

[Olliver Schinagl]

Hey Ezequiel,

On October 26, 2015 10:58:18 PM CET, Ezequiel Garcia 
 wrote:
>(+ Ariel)
>
>Hi Oliver,
>
>Not sure why there's some many people in Cc for such a silly change.
>I guess you are using get_maintainers.pl on the entire patchset and get
>this rather long list.
>
I did indeed use the script and for v2 i'll split it up in several patches. The 
grouping that made sense to me was it was all pwm related. I'll do better next 
time. Sorry.

>IMO, the value of submitting patches as part of a larger series is to
>be able to
>push patches that need to be applied in some given order, or otherwise
>have some kind of logical relationship between them.
>
>However, this is not the case: it's just a very small change and has
>no relation to the rest of the patches in the series.
>I think a simple standalone patch would be better here.
>
>Also, get_maintainer.pl is just a hint, and not meant to be used as-is.
>In particular, you are missing the driver's author.
>
>On 26 October 2015 at 18:32, Olliver Schinagl
> wrote:
>> From: Olliver Schinagl 
>>
>> The lpc18xx driver currently manipulates the pwm_device struct
>directly
>> rather then using the pwm_set_chip_data. While the current method may
>> save a clock cycle or two, it is more obvious that data is set to the
>> chip pointer (especially since it is only a single int holding
>struct.
>>
>> Signed-off-by: Olliver Schinagl 
>> ---
>>  drivers/pwm/pwm-lpc18xx-sct.c | 11 +++
>>  drivers/pwm/pwm-sun4i.c   | 11 +++
>>  2 files changed, 18 insertions(+), 4 deletions(-)
>>
>
>...and this diffstat is obviously fishy.
It does.indeed, somehow i.must have accidentally merged two patches, stupid me. 
This.will also be addressed in the v2.

Olliver

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
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 v1 1/3] dt-bindings: rockchip-mailbox: Add mailbox controller document on Rockchip SoCs

[Caesar Wang]

This add the necessary binding documentation for mailbox
found on RK3368 SoC.

Signed-off-by: Caesar Wang 
---

Changes in v1:
- PATCH[1/3] doc:
- As the Rob Herring comments, s/share/shared/ and specify the value of 
#mbox-cells.
- Move the shared memory in mailbox, let's move the property the client
  driver in the future.

 .../bindings/mailbox/rockchip-mailbox.txt  | 32 ++
 1 file changed, 32 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt

diff --git a/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt 
b/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt
new file mode 100644
index 000..b6bb84a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt
@@ -0,0 +1,32 @@
+Rockchip mailbox
+
+The Rockchip mailbox is used by the Rockchip CPU cores to communicate
+requests to MCU processor.
+
+Refer to ./mailbox.txt for generic information about mailbox device-tree
+bindings.
+
+Required properties:
+
+ - compatible: should be one of the following.
+   - "rockchip,rk3368-mbox" for rk3368
+ - reg: physical base address of the controller and length of memory mapped
+   region.
+ - interrupts: The interrupt number to the cpu. The interrupt specifier format
+   depends on the interrupt controller.
+ - #mbox-cells: Common mailbox binding property to identify the number
+   of cells required for the mailbox specifier. Should be 1
+
+Example:
+
+
+/* RK3368 */
+mbox: mbox@ff6b {
+   compatible = "rockchip,rk3368-mailbox";
+   reg = <0x0 0xff6b 0x0 0x1000>,
+   interrupts = ,
+,
+,
+;
+   #mbox-cells = <1>;
+};
-- 
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 v1 0/3] mailbox: rockchip: Add mailbox driver for Rockchip platform

[Caesar Wang]

Mailbox is used by the Rockchip CPU cores to communicate
requests to MCU processor.

This driver is found on RK3368 SoCs.

The Mailbox module is a simple APB peripheral that allows both
the Cortex-A53 MCU system to communicate by writing operation to
generate interrupt.
The registers are accessible by both CPU via APB interface.

Tested on RK3368 SDK board.


Changes in v1:
- PATCH[1/3] doc:
- As the Rob Herring comments, s/share/shared/ and specify the value of 
#mbox-cells.
- Move the shared memory in mailbox, let's move the property the client
  driver in the future.
- PATCH[2/3] driver:
- The commit: %s/@/(num order).
- Add the module authors to instead of the notes.
- Add the COMPILE_TEST to auto compile test in Kconfig.
- Let the chan_to_idx() trys to instead of rockchip_mbox_chan.idx.
- Let's enable/disable the interrupt in startup/shutdown.
- Move the share memory and tx buf into the client drivers.
- PATCH[3/3] dts:
- fix "processormZ"--> "processor",the miss-fingerboard.
- Remove the shared memory in mailbox controller dtsi.

Caesar Wang (3):
  dt-bindings: rockchip-mailbox: Add mailbox controller document on
Rockchip SoCs
  mailbox: rockchip: Add Rockchip mailbox driver
  ARM64: dts: rk3368: Add mailbox device nodes

 .../bindings/mailbox/rockchip-mailbox.txt  |  32 +++
 arch/arm64/boot/dts/rockchip/rk3368.dtsi   |  12 +
 drivers/mailbox/Kconfig|   9 +
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/rockchip-mailbox.c | 286 +
 5 files changed, 341 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt
 create mode 100644 drivers/mailbox/rockchip-mailbox.c

-- 
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 v2] backlight: pm8941-wled: Add default-brightness property

[Rob Herring]

On Mon, Oct 26, 2015 at 12:45 PM, Bjorn Andersson
 wrote:
> Default the brightness to 2048 and add possibility to override this in
> device tree.
>
> Suggested-by: Rob Clark 
> Signed-off-by: Bjorn Andersson 
> ---
>
> Resend of v2, with updated backlight dt binding location.

Acked-by: Rob Herring 

>
>  Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt | 2 ++
>  drivers/video/backlight/pm8941-wled.c| 8 
>  2 files changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt 
> b/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
> index 424f8444a6cd..e5b294dafc58 100644
> --- a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
> +++ b/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
> @@ -5,6 +5,8 @@ Required properties:
>  - reg: slave address
>
>  Optional properties:
> +- default-brightness: brightness value on boot, value from: 0-4095
> +   default: 2048
>  - label: The name of the backlight device
>  - qcom,cs-out: bool; enable current sink output
>  - qcom,cabc: bool; enable content adaptive backlight control
> diff --git a/drivers/video/backlight/pm8941-wled.c 
> b/drivers/video/backlight/pm8941-wled.c
> index c704c3236034..e1298147bcbb 100644
> --- a/drivers/video/backlight/pm8941-wled.c
> +++ b/drivers/video/backlight/pm8941-wled.c
> @@ -17,6 +17,9 @@
>  #include 
>  #include 
>
> +/* From DT binding */
> +#define PM8941_WLED_DEFAULT_BRIGHTNESS 2048
> +
>  #define PM8941_WLED_REG_VAL_BASE   0x40
>  #define  PM8941_WLED_REG_VAL_MAX   0xFFF
>
> @@ -373,6 +376,7 @@ static int pm8941_wled_probe(struct platform_device *pdev)
> struct backlight_device *bl;
> struct pm8941_wled *wled;
> struct regmap *regmap;
> +   u32 val;
> int rc;
>
> regmap = dev_get_regmap(pdev->dev.parent, NULL);
> @@ -395,8 +399,12 @@ static int pm8941_wled_probe(struct platform_device 
> *pdev)
> if (rc)
> return rc;
>
> +   val = PM8941_WLED_DEFAULT_BRIGHTNESS;
> +   of_property_read_u32(pdev->dev.of_node, "default-brightness", );
> +
> memset(, 0, sizeof(struct backlight_properties));
> props.type = BACKLIGHT_RAW;
> +   props.brightness = val;
> props.max_brightness = PM8941_WLED_REG_VAL_MAX;
> bl = devm_backlight_device_register(>dev, wled->name,
> >dev, wled,
> --
> 2.4.2
>
--
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 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib

[Roger Quadros]

Boris,

On 27/10/15 10:12, Boris Brezillon wrote:
> Hi Roger,
> 
> On Tue, 27 Oct 2015 10:03:02 +0200
> Roger Quadros  wrote:
> 
>> On 26/10/15 22:49, Brian Norris wrote:
>>>
>>> Others have been looking at using GPIOs for the ready/busy pin too. At a
>>> minimum, we need an updated DT binding doc for this, since I see you're
>>> adding this via device tree in a later patch (I don't see any DT binding
>>> patch for this; but I could just be overlooking it). It'd also be great
>>> if this support was moved to nand_dt_init() so other platforms can
>>> benefit, but I won't require that.
>>>
>>> Also, previous [0] proposers had suggested 'rb-gpios', not 'ready-gpio'
>>> (the hardware docs typically call it 'rb' for ready/busy, FWIW). I don't
>>> really care, but the name should be going into a doc, so we can choose
>>> the same one everywhere.
>>>
>>> EDIT: looks like the discussion was partly here [1] and it seems we're
>>> landing on "rb-gpios" in the latest version [2]. Can we stick with that?
>>
>> Why should it be "rb-gpios" and not "rb-gpio"?
>> I don't think there are multiple gpios for r/b# function.
> 
> Because it's supposed to be a generic binding, and some NAND chips
> embed several dies, thus exposing several CS and RB pins, hence the
> rb-gpios name.
> Also, as described here [1], the convention is to name your property
> -gpios even if you only need one gpio.

Makes sense now. Thanks for the explanation.
I'll update this patch to use rb-gpios and update the binding doc as well.

--
cheers,
-roger
--
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 07/10] pwm: gpio: Add a generic gpio based PWM driver

[Olliver Schinagl]

Hey Rob,

On October 27, 2015 8:42:48 AM CET, Rob Herring  wrote:
>On Mon, Oct 26, 2015 at 4:32 PM, Olliver Schinagl
> wrote:
>> From: Olliver Schinagl 
>>
>> This patch adds a bit-banging gpio PWM driver. It makes use of
>hrtimers,
>> to allow nano-second resolution, though it obviously strongly depends
>on
>> the switching speed of the gpio pins, hrtimer and system load.
>>
>> Each pwm node can have 1 or more "pwm-gpio" entries, which will be
>> treated as pwm's as part of a pwm chip.
>>
>> Signed-off-by: Olliver Schinagl 
>> ---
>>  Documentation/devicetree/bindings/pwm/pwm-gpio.txt |  18 ++
>>  MAINTAINERS|   5 +
>>  drivers/pwm/Kconfig|  15 ++
>>  drivers/pwm/Makefile   |   1 +
>>  drivers/pwm/pwm-gpio.c | 253
>+
>>  5 files changed, 292 insertions(+)
>>  create mode 100644
>Documentation/devicetree/bindings/pwm/pwm-gpio.txt
>>  create mode 100644 drivers/pwm/pwm-gpio.c
>>
>> diff --git a/Documentation/devicetree/bindings/pwm/pwm-gpio.txt
>b/Documentation/devicetree/bindings/pwm/pwm-gpio.txt
>> new file mode 100644
>> index 000..336f61f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pwm/pwm-gpio.txt
>> @@ -0,0 +1,18 @@
>> +Generic GPIO bit-banged PWM driver
>> +
>> +Required properties:
>> +  - compatible: should be "pwm-gpio"
>> +  - #pwm-cells: should be 3, see pwm.txt in this directory for a
>general
>> +description of the cells format.
>> +  - pwm-gpios: one or more gpios describing the used gpio, see the
>gpio
>> +bindings for the used gpio driver.
>
>I'm not sure there is really much advantage to having multiple gpios
>per node. It would simplify the driver a bit not to, but I don't feel
>strongly either way.
I figured this way you have one (or more) gpio 'chips' and then per chip 1 or 
more outputs. I actually thing pne would use several gpios rather then several 
'chips'. Most hardware oprates the same way i thought.
>
>> +
>> +Example:
>> +#include 
>> +
>> +   pwm: pwm@0 {
>
>Unit address should be associated with a reg property, so drop it.
Done

>
>> +   compatible = "pwm-gpio";
>> +   #pwm-cells = 3;
>> +   pwm-gpios = < 7 1 GPIO_ACTIVE_LOW>;
>> +   pwm-gpios = < 7 2 GPIO_ACTIVE_LOW>;
>
>This would not actually compile. You can't have 2 properties of the
>same name.
A bad example is still a bug. Fixed.
>
>> +   };
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 7ba7ab7..0ae7fbf 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -4555,6 +4555,11 @@ F:   drivers/i2c/muxes/i2c-mux-gpio.c
>>  F: include/linux/i2c-mux-gpio.h
>>  F: Documentation/i2c/muxes/i2c-mux-gpio
>>
>> +GENERIC GPIO PWM DRIVER
>> +M: Olliver Schinagl 
>> +S: Maintained
>> +F: drivers/pwm/pwm-gpio.c
>
>Can you add the binding doc too.
Sure, done.

>
>Rob

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
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] regulator: tps65217: remove tps65217.dtsi file

[Heiko Schocher]

Hello Keerthy,

Am 27.10.2015 um 07:06 schrieb Keerthy:

Hi Heiko,

On Monday 26 October 2015 02:43 PM, Heiko Schocher wrote:

remove tps65217.dtsi and adapt all boards, which
used it.



I boot tested this on am335x-bone and am335x-boneblack boards and could 
successfully boot and i even
checked the regulators registered am335x-bone:

cat /sys/class/regulator/regulator.*/name
regulator-dummy
vmmcsd_fixed
DCDC1
DCDC2
DCDC3
LDO1
LDO2
LDO3
LDO4

Looks good to me. For am335x-bone and am335x-boneblack you can add

Tested-by: Keerthy 


Thanks for testing!

bye,
Heiko


Best Regards,
Keerthy


Signed-off-by: Heiko Schocher 
---
Suggested by Mark Brown, see:
https://lkml.org/lkml/2015/10/21/581

  .../devicetree/bindings/regulator/tps65217.txt | 78 --
  arch/arm/boot/dts/am335x-bone-common.dtsi  | 14 +++-
  arch/arm/boot/dts/am335x-chilisom.dtsi | 14 +++-
  arch/arm/boot/dts/am335x-nano.dts  | 14 +++-
  arch/arm/boot/dts/am335x-pepper.dts| 14 +++-
  arch/arm/boot/dts/am335x-sl50.dts  | 13 +++-
  arch/arm/boot/dts/tps65217.dtsi| 56 
  7 files changed, 58 insertions(+), 145 deletions(-)
  delete mode 100644 Documentation/devicetree/bindings/regulator/tps65217.txt
  delete mode 100644 arch/arm/boot/dts/tps65217.dtsi

diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt
b/Documentation/devicetree/bindings/regulator/tps65217.txt
deleted file mode 100644
index 4f05d20..000
--- a/Documentation/devicetree/bindings/regulator/tps65217.txt
+++ /dev/null
@@ -1,78 +0,0 @@
-TPS65217 family of regulators
-
-Required properties:
-- compatible: "ti,tps65217"
-- reg: I2C slave address
-- regulators: list of regulators provided by this controller, must be named
-  after their hardware counterparts: dcdc[1-3] and ldo[1-4]
-- regulators: This is the list of child nodes that specify the regulator
-  initialization data for defined regulators. Not all regulators for the given
-  device need to be present. The definition for each of these nodes is defined
-  using the standard binding for regulators found at
-  Documentation/devicetree/bindings/regulator/regulator.txt.
-
-Optional properties:
-- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle.
-
-  The valid names for regulators are:
-  tps65217: dcdc1, dcdc2, dcdc3, ldo1, ldo2, ldo3 and ldo4
-
-Each regulator is defined using the standard binding for regulators.
-
-Example:
-
-tps: tps@24 {
-compatible = "ti,tps65217";
-ti,pmic-shutdown-controller;
-
-regulators {
-dcdc1_reg: dcdc1 {
-regulator-min-microvolt = <90>;
-regulator-max-microvolt = <180>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-dcdc2_reg: dcdc2 {
-regulator-min-microvolt = <90>;
-regulator-max-microvolt = <330>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-dcdc3_reg: dcc3 {
-regulator-min-microvolt = <90>;
-regulator-max-microvolt = <150>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-ldo1_reg: ldo1 {
-regulator-min-microvolt = <100>;
-regulator-max-microvolt = <330>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-ldo2_reg: ldo2 {
-regulator-min-microvolt = <90>;
-regulator-max-microvolt = <330>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-ldo3_reg: ldo3 {
-regulator-min-microvolt = <180>;
-regulator-max-microvolt = <330>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-ldo4_reg: ldo4 {
-regulator-min-microvolt = <180>;
-regulator-max-microvolt = <330>;
-regulator-boot-on;
-regulator-always-on;
-};
-};
-};
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi 
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index fec7834..0c4bde0 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -285,10 +285,8 @@
  };
  };

-
-/include/ "tps65217.dtsi"
-
   {
+compatible = "ti,tps65217";
  /*
   * Configure pmic to enter OFF-state instead of SLEEP-state ("RTC-only
   * mode") at poweroff.  Most BeagleBone versions do not support RTC-only
@@ -309,12 +307,17 @@
  ti,pmic-shutdown-controller;

  regulators {
+#address-cells = <1>;
+#size-cells = <0>;
+
  dcdc1_reg: regulator@0 {
+reg = <0>;
   

Re: [PATCH 07/10] pwm: gpio: Add a generic gpio based PWM driver

[Rob Herring]

On Mon, Oct 26, 2015 at 4:32 PM, Olliver Schinagl
 wrote:
> From: Olliver Schinagl 
>
> This patch adds a bit-banging gpio PWM driver. It makes use of hrtimers,
> to allow nano-second resolution, though it obviously strongly depends on
> the switching speed of the gpio pins, hrtimer and system load.
>
> Each pwm node can have 1 or more "pwm-gpio" entries, which will be
> treated as pwm's as part of a pwm chip.
>
> Signed-off-by: Olliver Schinagl 
> ---
>  Documentation/devicetree/bindings/pwm/pwm-gpio.txt |  18 ++
>  MAINTAINERS|   5 +
>  drivers/pwm/Kconfig|  15 ++
>  drivers/pwm/Makefile   |   1 +
>  drivers/pwm/pwm-gpio.c | 253 
> +
>  5 files changed, 292 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-gpio.txt
>  create mode 100644 drivers/pwm/pwm-gpio.c
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-gpio.txt 
> b/Documentation/devicetree/bindings/pwm/pwm-gpio.txt
> new file mode 100644
> index 000..336f61f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-gpio.txt
> @@ -0,0 +1,18 @@
> +Generic GPIO bit-banged PWM driver
> +
> +Required properties:
> +  - compatible: should be "pwm-gpio"
> +  - #pwm-cells: should be 3, see pwm.txt in this directory for a general
> +description of the cells format.
> +  - pwm-gpios: one or more gpios describing the used gpio, see the gpio
> +bindings for the used gpio driver.

I'm not sure there is really much advantage to having multiple gpios
per node. It would simplify the driver a bit not to, but I don't feel
strongly either way.

> +
> +Example:
> +#include 
> +
> +   pwm: pwm@0 {

Unit address should be associated with a reg property, so drop it.

> +   compatible = "pwm-gpio";
> +   #pwm-cells = 3;
> +   pwm-gpios = < 7 1 GPIO_ACTIVE_LOW>;
> +   pwm-gpios = < 7 2 GPIO_ACTIVE_LOW>;

This would not actually compile. You can't have 2 properties of the same name.

> +   };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7ba7ab7..0ae7fbf 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4555,6 +4555,11 @@ F:   drivers/i2c/muxes/i2c-mux-gpio.c
>  F: include/linux/i2c-mux-gpio.h
>  F: Documentation/i2c/muxes/i2c-mux-gpio
>
> +GENERIC GPIO PWM DRIVER
> +M: Olliver Schinagl 
> +S: Maintained
> +F: drivers/pwm/pwm-gpio.c

Can you add the binding doc too.

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 08/13 v2] clk: add ARM syscon ICST device tree bindings

[Rob Herring]

On Mon, Oct 26, 2015 at 8:33 AM, Linus Walleij  wrote:
> This adds the device tree bindings for the ARM Syscon ICST
> oscillators, which is a register-level interface to the
> Integrated Device Technology (IDT) ICS525 and ICS307
> serially programmable oscillators.
>
> Cc: devicetree@vger.kernel.org
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Linus Walleij 

Acked-by: Rob Herring 

> ---
> ChangeLog v1->v2:
> - Spelling fixes.
>
> I'm looking for an ACK from the CLK maintainers to take this
> through the ARM SoC tree once the series stabilize.
> ---
>  .../devicetree/bindings/clock/arm-syscon-icst.txt  | 40 
> ++
>  1 file changed, 40 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/clock/arm-syscon-icst.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/arm-syscon-icst.txt 
> b/Documentation/devicetree/bindings/clock/arm-syscon-icst.txt
> new file mode 100644
> index ..8b7177cecb36
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/arm-syscon-icst.txt
> @@ -0,0 +1,40 @@
> +ARM System Controller ICST clocks
> +
> +The ICS525 and ICS307 oscillators are produced by Integrated Devices
> +Technology (IDT). ARM integrated these oscillators deeply into their
> +reference designs by adding special control registers that manage such
> +oscillators to their system controllers.
> +
> +The ARM system controller contains logic to serialize and initialize
> +an ICST clock request after a write to the 32 bit register at an offset
> +into the system controller. Furthermore, to even be able to alter one of
> +these frequencies, the system controller must first be unlocked by
> +writing a special token to another offset in the system controller.
> +
> +The ICST oscillator must be provided inside a system controller node.
> +
> +Required properties:
> +- lock-offset: the offset address into the system controller where the
> +  unlocking register is located
> +- vco-offset: the offset address into the system controller where the
> +  ICST control register is located (even 32 bit address)
> +- compatible: must be one of "arm,syscon-icst525" or "arm,syscon-icst307"
> +- #clock-cells: must be <0>
> +- clocks: parent clock, since the ICST needs a parent clock to derive its
> +  frequency from, this attribute is compulsory.
> +
> +Example:
> +
> +syscon: syscon@1000 {
> +   compatible = "syscon";
> +   reg = <0x1000 0x1000>;
> +
> +   oscclk0: osc0@0c {
> +   compatible = "arm,syscon-icst307";
> +   #clock-cells = <0>;
> +   lock-offset = <0x20>;
> +   vco-offset = <0x0c>;
> +   clocks = <>;
> +   };
> +   (...)
> +};
> --
> 2.4.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
--
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 v1 1/3] dt-bindings: rockchip-mailbox: Add mailbox controller document on Rockchip SoCs

[Rob Herring]

On Tue, Oct 27, 2015 at 2:31 AM, Caesar Wang  wrote:
> This add the necessary binding documentation for mailbox
> found on RK3368 SoC.
>
> Signed-off-by: Caesar Wang 
> ---
>
> Changes in v1:
> - PATCH[1/3] doc:
> - As the Rob Herring comments, s/share/shared/ and specify the value of 
> #mbox-cells.
> - Move the shared memory in mailbox, let's move the property the client
>   driver in the future.

Acked-by: Rob Herring 

>
>  .../bindings/mailbox/rockchip-mailbox.txt  | 32 
> ++
>  1 file changed, 32 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt
>
> diff --git a/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt 
> b/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt
> new file mode 100644
> index 000..b6bb84a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt
> @@ -0,0 +1,32 @@
> +Rockchip mailbox
> +
> +The Rockchip mailbox is used by the Rockchip CPU cores to communicate
> +requests to MCU processor.
> +
> +Refer to ./mailbox.txt for generic information about mailbox device-tree
> +bindings.
> +
> +Required properties:
> +
> + - compatible: should be one of the following.
> +   - "rockchip,rk3368-mbox" for rk3368
> + - reg: physical base address of the controller and length of memory mapped
> +   region.
> + - interrupts: The interrupt number to the cpu. The interrupt specifier 
> format
> +   depends on the interrupt controller.
> + - #mbox-cells: Common mailbox binding property to identify the number
> +   of cells required for the mailbox specifier. Should be 1
> +
> +Example:
> +
> +
> +/* RK3368 */
> +mbox: mbox@ff6b {
> +   compatible = "rockchip,rk3368-mailbox";
> +   reg = <0x0 0xff6b 0x0 0x1000>,
> +   interrupts = ,
> +,
> +,
> +;
> +   #mbox-cells = <1>;
> +};
> --
> 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 01/16] PM / OPP: Add 'supply-names' binding

[Viresh Kumar]

On 23-10-15, 01:39, Mark Brown wrote:
> When we start doing this we also start having to worry about things like
> the sequencing of the updates between the various supplies and end up in
> full on power sequencing (or at least baking some sequencing into the DT
> which will doubtless need extending at some point).

Absolutely.

> I'm not sure that's
> a place we want to end up just yet, I think it's safer to just have a
> little bit of code in the kernel that glues things together in the cases
> where this is needed.  

So you are effectively saying that we shouldn't go ahead with multi
regulator support in OPP library, right?

I went ahead with it as it came as a requirement (specially from
Qcom).

To the problem of sequencing, maybe we can just support that for the
simple case, where supplies will be programmed in the order in which
they are present in the property I added in this patch. And not try to
solve problem for the complex cases, if we feel it is getting ugly.

@Stephen ?

-- 
viresh
--
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 02/11] pinctrl: Remove GPIO to Pinctrl pin mapping from driver

[Linus Walleij]

On Mon, Oct 19, 2015 at 7:43 AM, Pramod Kumar  wrote:

> Remove gpio to pinctrl pin mapping code from driver and
> address this through standard property "gpio-ranges".
>
> Signed-off-by: Pramod Kumar 
> Reviewed-by: Ray Jui 
> Reviewed-by: Scott Branden 

Patch applied with a small subject tweak.

Yours,
Linus Walleij
--
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: [v2 03/10] ata: ahci_brcmstb: add quick for broken phy

[Jaedon Shin]

On Oct 27, 2015, at 5:17 PM, Rob Herring  wrote:
> 
> On Tue, Oct 27, 2015 at 1:48 AM, Jaedon Shin  wrote:
>> Add quick for broken phy. The ARM-based 28nm chipsets have four phy
> 
> I believe you mean "quirk".
> 

Oops! All the "quick" of patches should be changed to a "quirk".

Thanks.

>> interface control registers and each port has two registers. But, The
> 
> registers, but the...
> 
>> MIPS-based 40nm chipsets have three. and there are no information and
> 
> s/and there/There/
> 
>> documentation. The legacy version of broadcom's strict-ahci based
>> initial code did not control these registers.
>> 
>> Signed-off-by: Jaedon Shin 
>> ---
>> Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt |  1 +
> 
> Other than the commit message:
> 
> Acked-by: Rob Herring 
> 
>> drivers/ata/ahci_brcmstb.c  | 10 ++
>> 2 files changed, 11 insertions(+)
>> 
>> diff --git a/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt 
>> b/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt
>> index 488a383ce202..0f0925d58188 100644
>> --- a/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt
>> +++ b/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt
>> @@ -12,6 +12,7 @@ Required properties:
>> 
>> Optional properties:
>> - brcm,broken-ncq: if present, NCQ is unusable
>> +- brcm,broken-phy: if present, to control phy interface is unusable
>> 
>> Also see ahci-platform.txt.
>> 
>> diff --git a/drivers/ata/ahci_brcmstb.c b/drivers/ata/ahci_brcmstb.c
>> index e53962cb48ee..c61303f7c7dc 100644
>> --- a/drivers/ata/ahci_brcmstb.c
>> +++ b/drivers/ata/ahci_brcmstb.c
>> @@ -71,6 +71,7 @@
>> 
>> enum brcm_ahci_quicks {
>>BRCM_AHCI_QUICK_NONCQ   = BIT(0),
>> +   BRCM_AHCI_QUICK_NOPHY   = BIT(1),
>> };
>> 
>> struct brcm_ahci_priv {
>> @@ -119,6 +120,9 @@ static void brcm_sata_phy_enable(struct brcm_ahci_priv 
>> *priv, int port)
>>void __iomem *p;
>>u32 reg;
>> 
>> +   if (priv->quicks & BRCM_AHCI_QUICK_NOPHY)
>> +   return;
>> +
>>/* clear PHY_DEFAULT_POWER_STATE */
>>p = phyctrl + SATA_TOP_CTRL_PHY_CTRL_1;
>>reg = brcm_sata_readreg(p);
>> @@ -148,6 +152,9 @@ static void brcm_sata_phy_disable(struct brcm_ahci_priv 
>> *priv, int port)
>>void __iomem *p;
>>u32 reg;
>> 
>> +   if (priv->quicks & BRCM_AHCI_QUICK_NOPHY)
>> +   return;
>> +
>>/* power-off the PHY digital logic */
>>p = phyctrl + SATA_TOP_CTRL_PHY_CTRL_2;
>>reg = brcm_sata_readreg(p);
>> @@ -297,6 +304,9 @@ static int brcm_ahci_probe(struct platform_device *pdev)
>>if (of_property_read_bool(dev->of_node, "brcm,broken-ncq"))
>>priv->quicks |= BRCM_AHCI_QUICK_NONCQ;
>> 
>> +   if (of_property_read_bool(dev->of_node, "brcm,broken-phy"))
>> +   priv->quicks |= BRCM_AHCI_QUICK_NOPHY;
>> +
>>brcm_sata_init(priv);
>>brcm_sata_quick(pdev, priv);
>> 
>> --
>> 2.6.2
>> 

--
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 0/9] Goodix touchscreen enhancements

[Tirdea, Irina]

> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: 27 October, 2015 1:33
> To: Karsten Merker
> Cc: Bastien Nocera; Tirdea, Irina; Aleksei Mamlin; 
> linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux-
> ker...@vger.kernel.org; devicetree@vger.kernel.org
> Subject: Re: [PATCH v9 0/9] Goodix touchscreen enhancements
> 
> On Mon, Oct 26, 2015 at 07:21:12PM +0100, Karsten Merker wrote:
> > On Mon, Oct 26, 2015 at 04:06:29PM +0100, Bastien Nocera wrote:
> > > On Mon, 2015-10-12 at 18:24 +0300, Irina Tirdea wrote:
> >
> > > > v9 only adds GPIOLIB dependency in Kconfig for patch 2:
> > > > "Input: goodix - reset device at init". There are no other code
> > > > changes from v8.
> > > >
> > > > Thanks for testing these changes, Bastien and Aleksei!
> > > >
> > > > Karsten, there is no need to rebase your series on top of v9.
> > >
> > > Are we waiting on anything else before merging this? I'd like it to be
> > > scheduled to be merged so I can start focusing on the subsequent and
> > > dependent patches for that same driver.
> >
> > Hello,
> >
> > AFAICS there is one open point (cf.
> > http://www.spinics.net/lists/linux-input/msg41567.html) which
> > Irina wanted to address in a v10 of the patchset (cf.
> > http://www.spinics.net/lists/linux-input/msg41642.html).
> 
> There is also the whole thing about insane handling of named gpios in
> ACPI layer, which stops me from merging the reset code since these gpios
> should be marked as optional and we should stop ignoring errors coming
> from gpiolib.

The ACPI layer change is quite complex, since it includes changing the drivers
that use the gpio API before removing the fallback to indexed ACPI.
Not sure that will not also break current drivers that already count on this
fallback. Unfortunately, I do not have the time right now to get involved in
fixing the ACPI core myself.

Dmitry, is there anything I can do in the driver to get these patches merged?
I could go back to using indexed gpios and add an additional property
to specify if irq can be used as output or not (as suggested in one of the
previous reviews).

Thanks,
Irina

> 
> Thanks.
> 
> --
> Dmitry
--
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 04/11] dt-binding: Add new compatible string for gpio controller driver

[Linus Walleij]

On Mon, Oct 19, 2015 at 7:43 AM, Pramod Kumar  wrote:

> This new compatible string, "brcm,iproc-gpio", should be used for
> all new iproc-based future SoCs.
>
> Signed-off-by: Pramod Kumar 
> Reviewed-by: Ray Jui 
> Reviewed-by: Scott Branden 

Patch applied with subject tweak.

Think about Rob's comment to add an overarching SoC
compatible string, please.

Yours,
Linus Walleij
--
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 08/11] pinctrl: Add new compatible string to GPIO controller driver

[Linus Walleij]

On Mon, Oct 19, 2015 at 7:43 AM, Pramod Kumar  wrote:

> This compatible string should be used for all new iproc based future
> SoCs having the same GPIO controller hardware.
>
> Signed-off-by: Pramod Kumar 
> Reviewed-by: Ray Jui 
> Reviewed-by: Scott Branden 

Stopped applying patches, this looks OK but you will have
to rebase the series on my "devel" branch, addressing the
review comments.

Yours,
Linus Wallewij
--
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 00/10] Add tune support of Mediatek MMC driver

[Ulf Hansson]

On 27 October 2015 at 07:24, Chaotian Jing  wrote:
> Change in v3:
> Fix checkpatch errors and warnings for patch 8
> Split patch 9, make DT parts enabling hw reset separately
>
> Change in v2:
> Drop the 400mhz and use assigned-clock-parents to instead
> Split the original tune patch to several independent patches
> Re-write the mmc_send_tuning()
> Fix GPD checksum error
> Move the HS400 setting to ops->prepare_hs400_tuning()
> Modify SD driving settings
>
> Change in v1:
> Add DT bindings for eMMC hardware reset
> Add pinctrl of data strobe pin for HS400 mode
> Modify eMMC driving settings
> Add 400mhz source clock for HS400 mode
> Add eMMC HS200/HS400 mode support
> Add SD SDR50/SDR104 mode support
> Add implement of tune function with CMD19/CMD21
>
> Chaotian Jing (10):
>   mmc: core: Add DT bindings for eMMC hardware reset support
>   mmc: dt-bindings: update Mediatek MMC bindings
>   mmc: mediatek: make cmd_ints_mask to const
>   mmc: mediatek: change the argument "ddr" to "timing"
>   mmc: mediatek: fix got GPD checksum error interrupt when data transfer
>   mmc: mediatek: add implement of ops->hw_reset()
>   arm64: dts: mediatek: add eMMC hw reset support
>   mmc: mmc: extend the mmc_send_tuning()
>   mmc: mediatek: add HS400 support
>   arm64: dts: mediatek: add HS200/HS400/SDR50/SDR104 support
>
>  Documentation/devicetree/bindings/mmc/mmc.txt|   1 +
>  Documentation/devicetree/bindings/mmc/mtk-sd.txt |  11 +-
>  arch/arm64/boot/dts/mediatek/mt8173-evb.dts  |  27 +-
>  drivers/mmc/core/host.c  |   2 +
>  drivers/mmc/core/mmc_ops.c   |   8 +-
>  drivers/mmc/host/dw_mmc-exynos.c |   4 +-
>  drivers/mmc/host/dw_mmc.c|   2 +-
>  drivers/mmc/host/dw_mmc.h|   2 +-
>  drivers/mmc/host/mtk-sd.c| 304 
> ---
>  drivers/mmc/host/sdhci-esdhc-imx.c   |   6 +-
>  drivers/mmc/host/sdhci-msm.c |   2 +-
>  drivers/mmc/host/sdhci-sirf.c|   2 +-
>  include/linux/mmc/core.h |   2 +-
>  13 files changed, 322 insertions(+), 51 deletions(-)
>
> --
> 1.8.1.1.dirty
>

Chaotian,

I have applied this except the ARM patches (patch7 and patch10) as I
think those should go via ARM SoC (unless I get acks for them).

Regarding patch8, it didn't apply since it needed a re-base. This time
it was trivial to fix, so I decided to pick it up anyway.

Future wise I also advise you to significantly trim the cc/to list
when posting patches. Likely what happens when that many people are
requested for input, is that *none* cares. :-)

Thanks and kind regards!
Uffe
--
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/3] gpio: arizona: Support Cirrus Logic CS47L24 and WM1831

[Linus Walleij]

On Mon, Oct 19, 2015 at 4:13 PM, Richard Fitzgerald
 wrote:

> The CS47L24 and WM1831 codecs only have two GPIO lines, but are
> otherwise similar to the WM8280.
>
> Signed-off-by: Richard Fitzgerald 

Acked-by: Linus Walleij 

Lee can merge this into the MFD tree with patch 1/3 if he likes,
I guess that's simplest.

Yours,
Linus Walleij
--
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 00/10] add support SATA for BMIPS_GENERIC

[Ralf Baechle]

On Fri, Oct 23, 2015 at 10:44:13AM +0900, Jaedon Shin wrote:

> Ralf,
> I request you to drop already submitted patches for NAND device nodes.
> It is merge conflicts with this patches.
> http://patchwork.linux-mips.org/patch/10577/
> http://patchwork.linux-mips.org/patch/10578/
> http://patchwork.linux-mips.org/patch/10579/
> http://patchwork.linux-mips.org/patch/10580/

Done - but you can drop patches you have submitted from patchwork yourself.

  Ralf
--
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 0/9] Goodix touchscreen enhancements

[Tirdea, Irina]

> -Original Message-
> From: Karsten Merker [mailto:mer...@debian.org]
> Sent: 26 October, 2015 20:21
> To: Bastien Nocera; Tirdea, Irina
> Cc: Dmitry Torokhov; Aleksei Mamlin; Karsten Merker; 
> linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux-
> ker...@vger.kernel.org; devicetree@vger.kernel.org
> Subject: Re: [PATCH v9 0/9] Goodix touchscreen enhancements
> 
> On Mon, Oct 26, 2015 at 04:06:29PM +0100, Bastien Nocera wrote:
> > On Mon, 2015-10-12 at 18:24 +0300, Irina Tirdea wrote:
> 
> > > v9 only adds GPIOLIB dependency in Kconfig for patch 2:
> > > "Input: goodix - reset device at init". There are no other code
> > > changes from v8.
> > >
> > > Thanks for testing these changes, Bastien and Aleksei!
> > >
> > > Karsten, there is no need to rebase your series on top of v9.
> >
> > Are we waiting on anything else before merging this? I'd like it to be
> > scheduled to be merged so I can start focusing on the subsequent and
> > dependent patches for that same driver.
> 
> Hello,
> 
> AFAICS there is one open point (cf.
> http://www.spinics.net/lists/linux-input/msg41567.html) which
> Irina wanted to address in a v10 of the patchset (cf.
> http://www.spinics.net/lists/linux-input/msg41642.html).
> 
> Irina, how are your plans regarding the v10? It would be really
> nice if the patches could go into kernel 4.4, but the merge
> window opens on the coming weekend, so there is not much time
> left.

I can send v10 with the change mentioned above by the end of this week.

However, as Dmitry already mentioned, there is another issue with
the gpio ACPI layer that is blocking the entire patchset.

> 
> Bastien, did you have time to look at v3 of the axis
> swapping/inversion set?
> (http://www.spinics.net/lists/linux-input/msg41628.html)
> You had acked v2, but I had to do some small changes to address
> Irina's review comments after you had acked it, so I didn't want
> to carry your "acked-by" on to v3 without an ok from you.
> 
> Regards,
> Karsten
> --
> Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
> sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
> Werbung sowie der Markt- oder Meinungsforschung.

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

Hi Brian,

On 26/10/15 23:23, Brian Norris wrote:
> Hi Roger,
> 
> I'm not too familiar with OMAP platforms, and I might have missed out on
> prior discussions/context, so please forgive if I'm asking silly or old
> questions here.

No worries at all.

> 
> On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
>> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
>> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
>> This causes performance increase when using prefetch-irq mode.
>> 30% increase in read, 17% increase in write in prefetch-irq mode.
> 
> Have you pinpointed the exact causes for the performance increase, or
> can you give an educated guess? AIUI, you're reducing the number of
> interrupts needed for NAND prefetch mode, but you're also removing a bit
> of abstraction and implementing hooks that look awfully like the
> existing abstractions:
> 
> +   int (*nand_irq_enable)(enum gpmc_nand_irq irq);
> +   int (*nand_irq_disable)(enum gpmc_nand_irq irq);
> +   void (*nand_irq_clear)(enum gpmc_nand_irq irq);
> +   u32 (*nand_irq_status)(void);
> 
> That's not really a problem if there's a good reason for them (brcmnand
> implements similar hooks because of quirks in the implementation of
> interrupts across various BRCM SoCs, and it's not worth writing irqchip
> drivers for those cases). I'm mainly curious for an explanation.

I have both implementations with me. My guess is that the 20% performance
gain is due to absence of irqchip/irqdomain translation code.
I haven't investigated further though.

Another concern I have is that I'm not using any locking around
gpmc_nand_irq_enable/disable(). Could this pose problems in multiple NAND
use cases? My understanding is that it should not as the controller access
is serialized between multiple NAND chips.

However I do need to add some locking as the GPMC_IRQENABLE register is shared
between NAND and GPMC driver.

NOTE: We are not using prefetch-irq mode for any of the OMAP boards because
of lesser performance than prefetch-polled mode. So if the less performance
for an unused mode is a lesser concern compared to cleaner code then
I can resend this with the irqdomain implementation.

Below are performance logs of irqdomain vs hooks.

--
cheers,
-roger

test logs.

for-v4.4/gpmc-v2 - irqdomain with prefetch-irq. No ready pin.


[   67.696631] 
[   67.698201] =
[   67.704254] mtd_speedtest: MTD device: 8
[   67.708373] mtd_speedtest: MTD device size 8388608, eraseblock size 131072, 
page size 2048, count of eraseblocks 64, pages per eraseblock 64, OOB size 64
[   67.723701] mtd_test: scanning for bad eraseblocks
[   67.735468] mtd_test: scanned 64 eraseblocks, 0 are bad
[   67.772861] mtd_speedtest: testing eraseblock write speed
[   70.372903] mtd_speedtest: eraseblock write speed is 3156 KiB/s
[   70.379104] mtd_speedtest: testing eraseblock read speed
[   72.594169] mtd_speedtest: eraseblock read speed is 3708 KiB/s
[   72.656375] mtd_speedtest: testing page write speed
[   75.213646] mtd_speedtest: page write speed is 3208 KiB/s
[   75.219311] mtd_speedtest: testing page read speed
[   77.343639] mtd_speedtest: page read speed is 3865 KiB/s
[   77.405236] mtd_speedtest: testing 2 page write speed
[   80.039702] mtd_speedtest: 2 page write speed is 3114 KiB/s
[   80.045561] mtd_speedtest: testing 2 page read speed
[   82.175098] mtd_speedtest: 2 page read speed is 3856 KiB/s
[   82.180849] mtd_speedtest: Testing erase speed
[   82.241548] mtd_speedtest: erase speed is 146285 KiB/s
[   82.246920] mtd_speedtest: Testing 2x multi-block erase speed
[   82.284789] mtd_speedtest: 2x multi-block erase speed is 264258 KiB/s
[   82.291551] mtd_speedtest: Testing 4x multi-block erase speed
[   82.329358] mtd_speedtest: 4x multi-block erase speed is 264258 KiB/s
[   82.336116] mtd_speedtest: Testing 8x multi-block erase speed
[   82.373903] mtd_speedtest: 8x multi-block erase speed is 264258 KiB/s
[   82.380648] mtd_speedtest: Testing 16x multi-block erase speed
[   82.418503] mtd_speedtest: 16x multi-block erase speed is 264258 KiB/s
[   82.425356] mtd_speedtest: Testing 32x multi-block erase speed
[   82.463227] mtd_speedtest: 32x multi-block erase speed is 264258 KiB/s
[   82.470066] mtd_speedtest: Testing 64x multi-block erase speed
[   82.507908] mtd_speedtest: 64x multi-block erase speed is 264258 KiB/s
[   82.514758] mtd_speedtest: finished
[   82.518417] =

root@rockdesk:~# cat /proc/interrupts 
   CPU0   CPU1   
324: 798720  0  CBAR  15 Level gpmc
397: 798720  0  gpmc   0 Edge  gpmc-nand-fifo
398:  24576  0  gpmc   1 Edge  gpmc-nand-count


root@rockdesk:~# ./nandthroughput.sh 
Test file blobs/50M.bin found
mounting NAND partition 9
== attaching ubi to mtd9
[  133.102184] ubi0: attaching mtd9
[  

Re: [PATCH 01/11] dt-bindings: pinctrl: Optional DT property to support pin mappings

[Linus Walleij]

On Mon, Oct 19, 2015 at 7:43 AM, Pramod Kumar  wrote:

> If GPIO controller's pins are muxed, pin-controller subsystem
> need to be intimated by defining mapping between gpio and
> pinmux controller. This patch adds required properties to
> define this mapping via DT.
>
> Signed-off-by: Pramod Kumar 
> Reviewed-by: Ray Jui 
> Reviewed-by: Scott Branden 

Applied with Rob's ACK and a tweak to the subject line.

Yours,
Linus Walleij
--
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 05/11] dt-binding: Add ngpios property to GPIO controller node

[Linus Walleij]

On Mon, Oct 19, 2015 at 7:43 AM, Pramod Kumar  wrote:

> Add ngpios property to the gpio controller's DT node so that controller
> driver extracts total number of gpio lines present in controller
> from DT and removes dependency on driver.
>
> Signed-off-by: Pramod Kumar 
> Reviewed-by: Ray Jui 
> Reviewed-by: Scott Branden 
(...)
> +- ngpios:
> +Total number of GPIOs the controller provides

This description is wrong. The number of GPIOs the controller *provides*
is to be determined by the compatible-string.

ngpios is used to restrict the number of lines *used* or *routed* from
the number *available*. (I hope that is what the code does as well.)
Such as if 12 GPIOs are used of the 32 available on 32bits in a
register.

Update this description to say what it really means.

Yours,
Linus Walleij
--
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 03/11] dts: pinctrl: Add GPIO to Pinctrl pin mapping in DT

[Linus Walleij]

On Mon, Oct 19, 2015 at 7:43 AM, Pramod Kumar  wrote:

> ASIU gpio controller's pins are muxed with pin-cntroller.
> Add this mapping through property "gpio-ranges".
>
> Signed-off-by: Pramod Kumar 
> Reviewed-by: Ray Jui 
> Reviewed-by: Scott Branden 

Reviewed-by: Linus Walleij 

Please funnel this through the Broadcom Cygnus/ARM SoC tree.

Yours,
Linus Walleij
--
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 07/11] pinctrl: use ngpios propety from DT

[Linus Walleij]

On Mon, Oct 19, 2015 at 7:43 AM, Pramod Kumar  wrote:

> Since identical hardware is used in several instances and all pins
> are not routed to pinctrl hence getting total number of gpios from
> DT make more sense hence stop using total number of gpios pins from
> drivers and extract it from DT.
>
> Signed-off-by: Pramod Kumar 
> Reviewed-by: Ray Jui 
> Reviewed-by: Scott Branden 

This patch is wrong.

Keep this per-compatible code, and only overrid the ngpios
if and only if:

- The ngpios is set in the DT node
- The ngpios in the DT node is *smaller* than the hardware
  defined number of GPIOs.

ngpios is for restricting the number of available lines due to
routing etc, not to define what the hardware has, because the
hardware most certainly have all the lines, it's just that you're
not using all of them.

Yours,
Linus Walleij
--
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] dt-bindings: add document of mediatek efuse driver

[andrew-ct chen]

On Tue, 2015-10-27 at 13:32 +0800, andrew-ct chen wrote:
> On Mon, 2015-10-26 at 10:55 +, Srinivas Kandagatla wrote:
> > 
> > On 26/10/15 10:23, Sascha Hauer wrote:
> > > On Mon, Oct 26, 2015 at 09:56:14AM +, Srinivas Kandagatla wrote:
> > >>
> > >>
> > >> On 16/10/15 09:39, andrew-ct.c...@mediatek.com wrote:
> > >>> From: Andrew-CT Chen 
> > >>>
> > >>> Add Mediatek MT8173 EFUSE Devicetree binding file
> > >>>
> > >>> Signed-off-by: Andrew-CT Chen 
> > >>
> > >> Looks good to me, minor comment below.
> > >>
> > >> Will queue this for v4.5 once v4.4-rc1 is released.
> > >>
> > >>
> > >>> ---
> > >>>   .../devicetree/bindings/nvmem/mtk-efuse.txt| 36 
> > >>> ++
> > >>>   1 file changed, 36 insertions(+)
> > >>>   create mode 100644 
> > >>> Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
> > >>>
> > >>> diff --git a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt 
> > >>> b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
> > >>> new file mode 100644
> > >>> index 000..92edc3d
> > >>> --- /dev/null
> > >>> +++ b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
> > >>> @@ -0,0 +1,36 @@
> > >>> += Mediatek MTK-EFUSE device tree bindings =
> > >>> +
> > >>> +This binding is intended to represent MTK-EFUSE which is found in most 
> > >>> Mediatek SOCs.
> > >>> +
> > >>> +Required properties:
> > >>> +- compatible: should be "mediatek,mt8173-efuse" or 
> > >>> "mediatek,mt8135-efuse"
> > >>
> > >> Can we make the compatible more generic for mediatek socs? Like
> > >> "mediatek,efuse"  Or are they different in each SOC?
> > >
> > > While we can add an additional "mediatek,efuse" compatible we should
> > > always add the most specific compatible first. Otherwise we cannot
> > > differentiate between SoCs later without changing the device tree.
> > Yes, that’s correct.
> > 
> > AFAIK, Ideally the driver should have more generic compatible string 
> > unless there is any SOC specific thing, and DT can still use the order 
> > of specific, generic compatible strings. If not we would end up adding 
> > compatible strings into the driver for every new SOC.
> 
> We will modify for generic compatible string like "mediatek,efuse" and
> rebase it to v4.4-rc1.

For more clearly, we will modify the compatible string to
"mediatek,mt8173-efuse" and "mediatek,efuse".

> 
> > 
> > --srini
> > 
> > >
> > > Sascha
> > >
> 


--
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] nvmem: mediatek: Add Mediatek EFUSE driver

[andrew-ct chen]

On Tue, 2015-10-27 at 13:32 +0800, andrew-ct chen wrote:
> On Mon, 2015-10-26 at 09:56 +, Srinivas Kandagatla wrote:
> > On 16/10/15 09:39, andrew-ct.c...@mediatek.com wrote:
> > > From: Andrew-CT Chen 
> > >
> > > Add Mediatek EFUSE driver to access hardware data like
> > > thermal sensor calibration or HDMI impedance.
> > >
> > > Signed-off-by: Andrew-CT Chen 
> > 
> > Dirver looks pretty simple, below are few minor nits.
> > 
> > Please rebase this patch on top of v4.4-rc1 once its released in few 
> > weeks, so that I can queue this driver for v4.5.
> 
> We will rebase it.
> 
> > 
> > > ---
> > >   drivers/nvmem/Kconfig | 11 ++
> > >   drivers/nvmem/Makefile|  1 +
> > >   drivers/nvmem/mtk-efuse.c | 89 
> > > +++
> > >   3 files changed, 101 insertions(+)
> > >   create mode 100644 drivers/nvmem/mtk-efuse.c
> > >
> > > diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> > > index 8db2978..1bd5badc 100644
> > > --- a/drivers/nvmem/Kconfig
> > > +++ b/drivers/nvmem/Kconfig
> > > @@ -14,6 +14,17 @@ menuconfig NVMEM
> > >
> > >   if NVMEM
> > >
> > > +config MTK_EFUSE
> > > + tristate "Mediatek SoCs EFUSE support"
> > > + depends on ARCH_MEDIATEK || COMPILE_TEST
> > > + select REGMAP_MMIO
> > > + help
> > > +   This is a driver to access hardware related data like sensor
> > > +   calibration, HDMI impedance etc.
> > > +
> > > +   This driver can also be built as a module. If so, the module
> > > +   will be called efuse-mtk.
> > > +
> > >   config QCOM_QFPROM
> > >   tristate "QCOM QFPROM Support"
> > >   depends on ARCH_QCOM || COMPILE_TEST
> > > diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
> > > index 4328b93..916b727 100644
> > > --- a/drivers/nvmem/Makefile
> > > +++ b/drivers/nvmem/Makefile
> > > @@ -6,6 +6,7 @@ obj-$(CONFIG_NVMEM)   += nvmem_core.o
> > >   nvmem_core-y:= core.o
> > >
> > >   # Devices
> > > +obj-$(CONFIG_MTK_EFUSE)  += mtk-efuse.o
> > 
> > For consistency reasons, could you do this similar to other drivers.

We will do this for the consistency.

> > 
> > >   obj-$(CONFIG_QCOM_QFPROM)   += nvmem_qfprom.o
> > >   nvmem_qfprom-y  := qfprom.o
> > >   obj-$(CONFIG_NVMEM_SUNXI_SID)   += nvmem_sunxi_sid.o
> > > diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
> > > new file mode 100644
> > > index 000..9021c0b
> > > --- /dev/null
> > > +++ b/drivers/nvmem/mtk-efuse.c
> > > @@ -0,0 +1,89 @@
> > > +/*
> > > + * Copyright (c) 2015 MediaTek Inc.
> > > + * Author: Andrew-CT Chen 
> > > + *
> > > + * 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 
> > > +
> > > +static struct regmap_config mtk_regmap_config = {
> > > + .reg_bits = 32,
> > > + .val_bits = 32,
> > > + .reg_stride = 4,
> > > +};
> > > +
> > > +static int mtk_efuse_probe(struct platform_device *pdev)
> > > +{
> > > + struct device *dev = >dev;
> > > + struct resource *res;
> > > + struct nvmem_device *nvmem;
> > > + struct nvmem_config *econfig;
> > > + struct regmap *regmap;
> > > + void __iomem *base;
> > > +
> > > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > + base = devm_ioremap_resource(dev, res);
> > > + if (IS_ERR(base))
> > > + return PTR_ERR(base);
> > > +
> > > + econfig = devm_kzalloc(dev, sizeof(*econfig), GFP_KERNEL);
> > > + if (!econfig)
> > > + return -ENOMEM;
> > Why not use static econfig variable?
> > 
> > > +
> > > + mtk_regmap_config.max_register = resource_size(res) - 1;
> > > +
> > > + regmap = devm_regmap_init_mmio(dev, base, _regmap_config);
> > > + if (IS_ERR(regmap)) {
> > > + dev_err(dev, "regmap init failed\n");
> > > + return PTR_ERR(regmap);
> > > + }
> > > +
> > > + econfig->dev = dev;
> > > + econfig->owner = THIS_MODULE;
> > > + nvmem = nvmem_register(econfig);
> > > + if (IS_ERR(nvmem))
> > > + return PTR_ERR(nvmem);
> > > +
> > > + platform_set_drvdata(pdev, nvmem);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int mtk_efuse_remove(struct platform_device *pdev)
> > > +{
> > > + struct nvmem_device *nvmem = platform_get_drvdata(pdev);
> > > +
> > > + return nvmem_unregister(nvmem);
> > > +}
> > > +
> > > +static const struct of_device_id mtk_efuse_of_match[] = {
> > > + { .compatible = "mediatek,mt8135-efuse",},
> > > + { .compatible = 

Re: [PATCH] arm64: dts: mediatek: mt8173 PSCI-1.0 support

[Matthias Brugger]

On 28/08/15 04:11, fan.c...@mediatek.com wrote:

From: Fan Chen 

This patch adds psci comatible properties to support all mandatory
functions of PSCI-1.0, PSCI-0.2 and PSCI-0.1, and system suspend
can be supported in PSCI-1.0.

Signed-off-by: Fan Chen 
---


Applied to v4.4-next/arm64

Thanks,
Matthias


Because PSCI-1.0 patches hadn't landed on mainline, this patch is
based on three patch sets below:
[0] http://www.spinics.net/lists/arm-kernel/msg425793.html
 PSCI: system suspend support
[1] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git
 psci/unification
[2] http://www.spinics.net/lists/devicetree/msg82017.html
 [PATCH 0/6] drivers: firmware: psci: add basic v1.0 support

Before they are merged in, this patch still works fine with psci-0.2
support in current mainline.
---
  arch/arm64/boot/dts/mediatek/mt8173.dtsi |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index d18ee42..b9b4205 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -95,7 +95,7 @@
};

psci {
-   compatible = "arm,psci";
+   compatible = "arm,psci-1.0", "arm,psci-0.2", "arm,psci";
method = "smc";
cpu_suspend   = <0x8401>;
cpu_off   = <0x8402>;


--
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 RESEND v2 net-next] net: hisilicon: updates HNS config and documents

[huangdaode]

From: yankejian 

updates the bindings documents and dtsi file according to the review
comments[https://lkml.org/lkml/2015/9/21/670] from Rob Herring 

Acked-by: Rob Herring 
Signed-off-by: yankejian 
Signed-off-by: huangdaode 
---
 Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt | 2 +-
 arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi | 8 +++-
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt 
b/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt
index 9940aa0..9c23fdf 100644
--- a/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt
+++ b/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt
@@ -12,7 +12,7 @@ Example:
  mdio@803c {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "hisilicon,mdio","hisilicon,hns-mdio";
+   compatible = "hisilicon,hns-mdio","hisilicon,mdio";
reg = <0x0 0x803c 0x0 0x1>;
 
ethernet-phy@0 {
diff --git a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi 
b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
index 3500586..606dd5a 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
@@ -13,14 +13,12 @@ soc0: soc@0 {
reg = <0x0 0x803c 0x0 0x1
   0x0 0x8000 0x0 0x1>;
 
-   soc0_phy4: ethernet-phy@4 {
+   soc0_phy0: ethernet-phy@0 {
reg = <0x0>;
-   device_type = "ethernet-phy";
compatible = "ethernet-phy-ieee802.3-c22";
};
-   soc0_phy5: ethernet-phy@5 {
+   soc0_phy1: ethernet-phy@1 {
reg = <0x1>;
-   device_type = "ethernet-phy";
compatible = "ethernet-phy-ieee802.3-c22";
};
};
@@ -37,7 +35,7 @@ soc0: soc@0 {
   0x0 0xc700 0x0 0x6
   >;
 
-   phy-handle = <0 0 0 0 _phy4 _phy5 0 0>;
+   phy-handle = <0 0 0 0 _phy0 _phy1 0 0>;
interrupts = <
/* [14] ge fifo err 8 / xge 6**/
149 0x4 150 0x4 151 0x4 152 0x4
-- 
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] regulator: tps65217: remove tps65217.dtsi file

[Keerthy]

Hi Heiko,

On Monday 26 October 2015 02:43 PM, Heiko Schocher wrote:

remove tps65217.dtsi and adapt all boards, which
used it.



I boot tested this on am335x-bone and am335x-boneblack boards and could 
successfully boot and i even checked the regulators registered am335x-bone:


cat /sys/class/regulator/regulator.*/name
regulator-dummy
vmmcsd_fixed
DCDC1
DCDC2
DCDC3
LDO1
LDO2
LDO3
LDO4

Looks good to me. For am335x-bone and am335x-boneblack you can add

Tested-by: Keerthy 

Best Regards,
Keerthy


Signed-off-by: Heiko Schocher 
---
Suggested by Mark Brown, see:
https://lkml.org/lkml/2015/10/21/581

  .../devicetree/bindings/regulator/tps65217.txt | 78 --
  arch/arm/boot/dts/am335x-bone-common.dtsi  | 14 +++-
  arch/arm/boot/dts/am335x-chilisom.dtsi | 14 +++-
  arch/arm/boot/dts/am335x-nano.dts  | 14 +++-
  arch/arm/boot/dts/am335x-pepper.dts| 14 +++-
  arch/arm/boot/dts/am335x-sl50.dts  | 13 +++-
  arch/arm/boot/dts/tps65217.dtsi| 56 
  7 files changed, 58 insertions(+), 145 deletions(-)
  delete mode 100644 Documentation/devicetree/bindings/regulator/tps65217.txt
  delete mode 100644 arch/arm/boot/dts/tps65217.dtsi

diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt 
b/Documentation/devicetree/bindings/regulator/tps65217.txt
deleted file mode 100644
index 4f05d20..000
--- a/Documentation/devicetree/bindings/regulator/tps65217.txt
+++ /dev/null
@@ -1,78 +0,0 @@
-TPS65217 family of regulators
-
-Required properties:
-- compatible: "ti,tps65217"
-- reg: I2C slave address
-- regulators: list of regulators provided by this controller, must be named
-  after their hardware counterparts: dcdc[1-3] and ldo[1-4]
-- regulators: This is the list of child nodes that specify the regulator
-  initialization data for defined regulators. Not all regulators for the given
-  device need to be present. The definition for each of these nodes is defined
-  using the standard binding for regulators found at
-  Documentation/devicetree/bindings/regulator/regulator.txt.
-
-Optional properties:
-- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle.
-
-  The valid names for regulators are:
-  tps65217: dcdc1, dcdc2, dcdc3, ldo1, ldo2, ldo3 and ldo4
-
-Each regulator is defined using the standard binding for regulators.
-
-Example:
-
-   tps: tps@24 {
-   compatible = "ti,tps65217";
-   ti,pmic-shutdown-controller;
-
-   regulators {
-   dcdc1_reg: dcdc1 {
-   regulator-min-microvolt = <90>;
-   regulator-max-microvolt = <180>;
-   regulator-boot-on;
-   regulator-always-on;
-   };
-
-   dcdc2_reg: dcdc2 {
-   regulator-min-microvolt = <90>;
-   regulator-max-microvolt = <330>;
-   regulator-boot-on;
-   regulator-always-on;
-   };
-
-   dcdc3_reg: dcc3 {
-   regulator-min-microvolt = <90>;
-   regulator-max-microvolt = <150>;
-   regulator-boot-on;
-   regulator-always-on;
-   };
-
-   ldo1_reg: ldo1 {
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <330>;
-   regulator-boot-on;
-   regulator-always-on;
-   };
-
-   ldo2_reg: ldo2 {
-   regulator-min-microvolt = <90>;
-   regulator-max-microvolt = <330>;
-   regulator-boot-on;
-   regulator-always-on;
-   };
-
-   ldo3_reg: ldo3 {
-   regulator-min-microvolt = <180>;
-   regulator-max-microvolt = <330>;
-   regulator-boot-on;
-   regulator-always-on;
-   };
-
-   ldo4_reg: ldo4 {
-   regulator-min-microvolt = <180>;
-   regulator-max-microvolt = <330>;
-   regulator-boot-on;
-   regulator-always-on;
-   };
-   };
-   };
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi 
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index fec7834..0c4bde0 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ 

Re: [PATCH v2 03/13] arc: enable building of all dtbs

[Vineet Gupta]

On Thursday 08 October 2015 11:24 PM, Rob Herring wrote:

Enable building all dtb files when CONFIG_OF_ALL_DTBS is enabled. The dtbs
are not really dependent on a platform being enabled or any other kernel
config, so for testing coverage it is convenient to build all of the dtbs.
This builds all dts files in the tree, not just targets listed.

Signed-off-by: Rob Herring 
Cc: Vineet Gupta 

Sorry for the delay - slipped thru cracks.

Acked-by: Vineet Gupta 
--
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 5/6] ARM: OMAP2+: dts: cm-t335: add support for network device

[Mugunthan V N]

On Tuesday 27 October 2015 05:44 PM, Uri Mashiach wrote:
> From: Ilya Ledvich 
> 
> Add pinmux configurations for RGMII1 based CPSW Ethernet pins and
> MDIO pins:
>  - default configuration required for module in active state,
>  - sleep configuration required for module in inactive state.
> Add mac node with single slave device. Add nodes for davinci_mdio and
> cpsw_emac0.
> 
> Acked-by: Igor Grinberg 
> Signed-off-by: Ilya Ledvich 
> Signed-off-by: Uri Mashiach 

Acked-by: Mugunthan V N 

Regards
Mugunthan V N
--
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 v5 4/6] memory: mediatek: Add SMI driver

[Robin Murphy]

On 09/10/15 03:23, Yong Wu wrote:
[...]

+static int mtk_smi_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct mtk_smi_data *smidata;
+   int ret;
+
+   if (!dev->pm_domain)
+   return -EPROBE_DEFER;
+
+   smidata = devm_kzalloc(dev, sizeof(*smidata), GFP_KERNEL);
+   if (!smidata)
+   return -ENOMEM;
+
+   smidata->clk_apb = devm_clk_get(dev, "apb");
+   if (IS_ERR(smidata->clk_apb))
+   return PTR_ERR(smidata->clk_apb);
+
+   smidata->clk_smi = devm_clk_get(dev, "smi");
+   if (IS_ERR(smidata->clk_smi))
+   return PTR_ERR(smidata->clk_smi);
+
+   pm_runtime_enable(dev);
+   dev_set_drvdata(dev, smidata);
+   return ret;


ret is used uninitialised here, but you might as well just "return 0;" 
and get rid of the variable entirely.



+}


Robin.

--
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 v5 5/6] iommu/mediatek: Add mt8173 IOMMU driver

[Robin Murphy]

On 09/10/15 03:23, Yong Wu wrote:
[...]

+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 


Nit: ordering?


+#include 
+#include "io-pgtable.h"


[...]

+struct mtk_iommu_data {
+   void __iomem*base;
+   int irq;
+   struct device   *dev;
+   struct device   *larbdev[MTK_IOMMU_LARB_MAX_NR];
+   struct clk  *bclk;
+   phys_addr_t protect_base; /* protect memory base */
+   int larb_nr;/* local arbiter number */
+   struct mtk_iommu_suspend_regreg;
+};


I think I've finally got my head round the way this hardware works - 
each LARB can be configured to block or allow transactions from the 
client device behind each port, but they _don't_ otherwise pass any 
information downstream such that the M4U itself can identify individual 
transactions, right? If that is indeed the case, then Joerg is totally 
correct that all clients of one M4U should be in a single group, so you 
might as well keep a handy iommu_group pointer here. I'll refer back to 
that idea later...


[...]

+static void mtk_iommu_clear_intr(const struct mtk_iommu_data *data)
+{
+   u32 val;
+
+   val = readl_relaxed(data->base + REG_MMU_INT_CONTROL0);
+   val |= F_INT_L2_CLR_BIT;
+   writel_relaxed(val, data->base + REG_MMU_INT_CONTROL0);
+}


Do you anticipate any other callers of this? AFAICS these 3 lines could 
just be rolled into mtk_iommu_isr().



+static void mtk_iommu_tlb_flush_all(void *cookie)
+{
+   struct mtk_iommu_domain *domain = cookie;
+   void __iomem *base;
+
+   base = domain->data->base;
+   writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0, base + REG_MMU_INV_SEL);
+   writel_relaxed(F_ALL_INVLD, base + REG_MMU_INVALIDATE);
+   mb();/* Make sure flush all done */


If it's purely to make sure the write has completed, would wmb() be 
sufficient here?



+}
+
+static void mtk_iommu_tlb_add_flush(unsigned long iova, size_t size,
+   bool leaf, void *cookie)
+{
+   struct mtk_iommu_domain *domain = cookie;
+   void __iomem *base = domain->data->base;
+   unsigned int iova_start = iova, iova_end = iova + size - 1;


Nit: why not simply name the argument iova_start in the first place, or 
just use iova below?



+   writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0, base + REG_MMU_INV_SEL);
+
+   writel_relaxed(iova_start, base + REG_MMU_INVLD_START_A);
+   writel_relaxed(iova_end, base + REG_MMU_INVLD_END_A);
+   writel_relaxed(F_MMU_INV_RANGE, base + REG_MMU_INVALIDATE);
+}
+
+static void mtk_iommu_tlb_sync(void *cookie)
+{
+   struct mtk_iommu_domain *domain = cookie;
+   void __iomem *base = domain->data->base;
+   int ret;
+   u32 tmp;
+
+   ret = readl_poll_timeout_atomic(base + REG_MMU_CPE_DONE, tmp,
+   tmp != 0, 10, 100);
+   if (ret) {
+   dev_warn(domain->data->dev,
+"Partial TLB flush timed out, falling back to full 
flush\n");
+   mtk_iommu_tlb_flush_all(cookie);
+   }
+   writel_relaxed(0, base + REG_MMU_CPE_DONE);


Do you still need this writeback in the ret==0 case when you've already 
read CPE_DONE as 0, or should this be inside the condition? (in which 
case you could also use an early return to lose the indent)



+}

[...]

+static int mtk_iommu_hw_init(const struct mtk_iommu_domain *mtkdom)
+{
+   struct mtk_iommu_data *data = mtkdom->data;
+   void __iomem *base = data->base;
+   u32 regval;
+   int ret;
+
+   ret = clk_prepare_enable(data->bclk);
+   if (ret) {
+   dev_err(data->dev, "Failed to enable iommu clk(%d)\n", ret);
+   return ret;
+   }


I'm not sure about the asymmetry here; the clock gets enabled when 
attaching clients to a domain, but not disabled until the IOMMU itself 
is torn down in mtk_iommu_remove() (i.e. never). It seems like either 
the clock should be enabled in mtk_iommu_probe(), or disabled in domain 
detach.



+   writel_relaxed(mtkdom->cfg.arm_short_cfg.ttbr[0],
+  base + REG_MMU_PT_BASE_ADDR);
+
+   regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
+   F_MMU_TF_PROTECT_SEL(2) |
+   F_COHERENCE_EN;
+   writel_relaxed(regval, base + REG_MMU_CTRL_REG);
+
+   regval = F_L2_MULIT_HIT_EN |
+   F_TABLE_WALK_FAULT_INT_EN |
+   F_PREETCH_FIFO_OVERFLOW_INT_EN |
+   F_MISS_FIFO_OVERFLOW_INT_EN |
+   F_PREFETCH_FIFO_ERR_INT_EN |
+   F_MISS_FIFO_ERR_INT_EN;
+   writel_relaxed(regval, base + REG_MMU_INT_CONTROL0);
+
+   regval = F_INT_TRANSLATION_FAULT |
+   F_INT_MAIN_MULTI_HIT_FAULT |
+   F_INT_INVALID_PA_FAULT |
+

Re: [PATCH v2 02/13] arc: use common make variables for dtb builds

[Vineet Gupta]

On Thursday 08 October 2015 11:24 PM, Rob Herring wrote:

Use dtb-y and always make variables to build dtbs instead of explicit
dtbs rule. This is in preparation to support building all dtbs.

Signed-off-by: Rob Herring 
Cc: Vineet Gupta 

Acked-by: Vineet Gupta 


--
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 02/32] devicetree: bindings: scsi: HiSi SAS

[John Garry]

On 26/10/2015 14:45, Mark Rutland wrote:

On Mon, Oct 26, 2015 at 10:14:33PM +0800, John Garry wrote:

Add devicetree bindings for HiSilicon SAS driver.

Signed-off-by: John Garry 
---
  .../devicetree/bindings/scsi/hisilicon-sas.txt | 70 ++
  1 file changed, 70 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/scsi/hisilicon-sas.txt

diff --git a/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt 
b/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
new file mode 100644
index 000..d1e7b2a
--- /dev/null
+++ b/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
@@ -0,0 +1,70 @@
+* HiSilicon SAS controller
+
+The HiSilicon SAS controller supports SAS/SATA.
+
+Main node required properties:
+  - compatible : value should be as follows:
+   (a) "hisilicon,sas-controller-v1" for v1 of HiSilicon SAS controller IP
+  - reg : Address and length of the SAS register
+  - hisilicon,sas-syscon: phandle of syscon used for sas control
+  - ctrl-reg : offset to the following SAS control registers (in order):
+   - reset assert
+   - clock disable
+   - reset status
+   - reset de-assert
+   - clock enable


This needs a better name, and it should probably be split up into
several properties.

However, it sounds like the syscon is actually a clock+reset
controller, and should be modelled as such. It's not actually a part of
the SAS controller as such.


The syscon block is a general subsystem control block, and it is not 
specifically only for controlling reset and enabling clocks (other 
functions include serdes control, for example). It is also shared with 
other peripherals.


So we can remove the ctrl-reg property (since it is not part of the SAS 
controller), and add the relevant syscon register offsets to the 
"hisilicon,sas-syscon" property, like this:

hisilicon,sas-syscon = <_ctrl0 0xa60 0x33c 0x5a30 0xa64 0x338>;

Ok?




+  - queue-count : number of delivery and completion queues in the controller
+  - phy-count : number of phys accessible by the controller
+  - interrupts : Interrupts for phys, completion queues, and fatal
+interrupts:
+ - Each phy has 3 interrupt sources:
+   - broadcast
+   - phyup
+   - abnormal
+ - Each completion queue has 1 interrupt source
+ - Each controller has 2 fatal interrupt sources:
+   - ECC
+   - AXI bus


Please make the ordering explicit here (you might only need to add the
phrase "in order" in a few places).


Will do.



Thanks,
Mark.


Thanks,
John


--
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/6] ARM: OMAP2+: dts: cm-t335: add support for MMC

[Uri Mashiach]

From: Ilya Ledvich 

Add pinmux configuration for MMC0 pins.
Add fixed regulator 'vmmc_fixed'.
Enable MMC0 in 4-bit mode.

Acked-by: Igor Grinberg 
Signed-off-by: Ilya Ledvich 
Signed-off-by: Uri Mashiach 
---
 arch/arm/boot/dts/am335x-cm-t335.dts | 33 +
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-cm-t335.dts 
b/arch/arm/boot/dts/am335x-cm-t335.dts
index 9d6117a..976c330 100644
--- a/arch/arm/boot/dts/am335x-cm-t335.dts
+++ b/arch/arm/boot/dts/am335x-cm-t335.dts
@@ -31,6 +31,14 @@
linux,default-trigger = "heartbeat";
};
};
+
+   /* regulator for mmc */
+   vmmc_fixed: fixedregulator@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "vmmc_fixed";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
 };
 
 _pinmux {
@@ -104,6 +112,23 @@
0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)
>;
};
+
+   mmc1_pins: pinmux_mmc1_pins {
+   pinctrl-single,pins = <
+   /* mmc0_dat3.mmc0_dat3 */
+   0xf0 (PIN_INPUT_PULLUP | MUX_MODE0)
+   /* mmc0_dat2.mmc0_dat2 */
+   0xf4 (PIN_INPUT_PULLUP | MUX_MODE0)
+   /* mmc0_dat1.mmc0_dat1 */
+   0xf8 (PIN_INPUT_PULLUP | MUX_MODE0)
+   /* mmc0_dat0.mmc0_dat0 */
+   0xfc (PIN_INPUT_PULLUP | MUX_MODE0)
+   /* mmc0_clk.mmc0_clk */
+   0x100 (PIN_INPUT_PULLUP | MUX_MODE0)
+   /* mmc0_cmd.mmc0_cmd */
+   0x104 (PIN_INPUT_PULLUP | MUX_MODE0)
+   >;
+   };
 };
 
  {
@@ -203,3 +228,11 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+   vmmc-supply = <_fixed>;
+   bus-width = <4>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+};
+
-- 
2.6.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 6/6] ARM: OMAP2+: dts: cm-t335: add support for PWM backlight

[Uri Mashiach]

From: Ilya Ledvich 

Add pinmux configuration for ECAP0 pin.
Add node for PWM backlight device.
Use PWM output from ecap0 as backlight source.

Acked-by: Igor Grinberg 
Signed-off-by: Ilya Ledvich 
Signed-off-by: Uri Mashiach 
---
 arch/arm/boot/dts/am335x-cm-t335.dts | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-cm-t335.dts 
b/arch/arm/boot/dts/am335x-cm-t335.dts
index 0296d3f..571a453 100644
--- a/arch/arm/boot/dts/am335x-cm-t335.dts
+++ b/arch/arm/boot/dts/am335x-cm-t335.dts
@@ -39,6 +39,13 @@
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
};
+
+   backlight {
+   compatible = "pwm-backlight";
+   pwms = < 0 5 0>;
+   brightness-levels = <0 51 53 56 62 75 101 152 255>;
+   default-brightness-level = <8>;
+   };
 };
 
 _pinmux {
@@ -113,6 +120,13 @@
>;
};
 
+   ecap0_pins: pinmux_ecap0_pins {
+   pinctrl-single,pins = <
+   /* eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
+   0x164 0x0
+   >;
+   };
+
cpsw_default: cpsw_default {
pinctrl-single,pins = <
/* Slave 1 */
@@ -222,6 +236,16 @@
};
 };
 
+ {
+   status = "okay";
+
+   ecap0: ecap@48300100 {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   };
+};
+
  {
status = "okay";
pinctrl-names = "default";
-- 
2.6.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

Re: [PATCH] regulator: tps65217: remove tps65217.dtsi file

[Sebastian Reichel]

Hi,

On Mon, Oct 26, 2015 at 10:13:55AM +0100, Heiko Schocher wrote:
> remove tps65217.dtsi and adapt all boards, which
> used it.
> 
> Signed-off-by: Heiko Schocher 
> ---
> Suggested by Mark Brown, see:
> https://lkml.org/lkml/2015/10/21/581
> 
>  .../devicetree/bindings/regulator/tps65217.txt | 78 
> --

why did you delete the binding description?

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH] regulator: tps65217: remove tps65217.dtsi file

[Heiko Schocher]

Hello Sebastian,

Am 27.10.2015 um 13:21 schrieb Sebastian Reichel:

Hi,

On Mon, Oct 26, 2015 at 10:13:55AM +0100, Heiko Schocher wrote:

remove tps65217.dtsi and adapt all boards, which
used it.

Signed-off-by: Heiko Schocher 
---
Suggested by Mark Brown, see:
https://lkml.org/lkml/2015/10/21/581

  .../devicetree/bindings/regulator/tps65217.txt | 78 --


why did you delete the binding description?


Didn;t I sent a v2? I realized this after sending the v1 patch, and
prepared a v2, which does not remove this file ... Uh, yes, seems
I missed sending it ... Sorry. Send a v2 ASAP, thanks!

bye,
Heiko
--
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
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 18/19] ARM: dts: ste: replace legacy *,wakeup property with wakeup-source

[Linus Walleij]

On Wed, Oct 21, 2015 at 12:10 PM, Sudeep Holla  wrote:

> Though the keyboard and other driver will continue to support the legacy
> "gpio-key,wakeup", "linux,wakeup" boolean property to enable the wakeup
> source, "wakeup-source" is the new standard binding.
>
> This patch replaces all the legacy wakeup properties with the unified
> "wakeup-source" property in order to avoid any futher copy-paste
> duplication.
>
> Cc: Linus Walleij 
> Signed-off-by: Sudeep Holla 

Acked-by: Linus Walleij 

Are you sending this to ARM SoC or do I need to handle the
patch?

Yours,
Linus Walleij
--
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] regulator: tps65217: remove tps65217.dtsi file

[Heiko Schocher]

remove tps65217.dtsi and adapt all boards, which
used it.

Signed-off-by: Heiko Schocher 
Tested-by: Keerthy 
Acked-by: Mark Brown 
---
Suggested by Mark Brown, see:
https://lkml.org/lkml/2015/10/21/581

Changes in v2:
- accidentially removed tps65217.txt
  do not remove it, add Sebastian Reichel to
  cc, as he also deteted this.
- add Acked-by from Mark Brown
- add Tested-by from j-keerthy

 .../devicetree/bindings/regulator/tps65217.txt | 10 
 arch/arm/boot/dts/am335x-bone-common.dtsi  | 14 --
 arch/arm/boot/dts/am335x-chilisom.dtsi | 14 +-
 arch/arm/boot/dts/am335x-nano.dts  | 14 +-
 arch/arm/boot/dts/am335x-pepper.dts| 14 +-
 arch/arm/boot/dts/am335x-sl50.dts  | 13 -
 arch/arm/boot/dts/tps65217.dtsi| 56 --
 7 files changed, 68 insertions(+), 67 deletions(-)
 delete mode 100644 arch/arm/boot/dts/tps65217.dtsi

diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt 
b/Documentation/devicetree/bindings/regulator/tps65217.txt
index 4f05d20..d181096 100644
--- a/Documentation/devicetree/bindings/regulator/tps65217.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65217.txt
@@ -26,7 +26,11 @@ Example:
ti,pmic-shutdown-controller;
 
regulators {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
dcdc1_reg: dcdc1 {
+   reg = <0>;
regulator-min-microvolt = <90>;
regulator-max-microvolt = <180>;
regulator-boot-on;
@@ -34,6 +38,7 @@ Example:
};
 
dcdc2_reg: dcdc2 {
+   reg = <1>;
regulator-min-microvolt = <90>;
regulator-max-microvolt = <330>;
regulator-boot-on;
@@ -41,6 +46,7 @@ Example:
};
 
dcdc3_reg: dcc3 {
+   reg = <2>;
regulator-min-microvolt = <90>;
regulator-max-microvolt = <150>;
regulator-boot-on;
@@ -48,6 +54,7 @@ Example:
};
 
ldo1_reg: ldo1 {
+   reg = <3>;
regulator-min-microvolt = <100>;
regulator-max-microvolt = <330>;
regulator-boot-on;
@@ -55,6 +62,7 @@ Example:
};
 
ldo2_reg: ldo2 {
+   reg = <4>;
regulator-min-microvolt = <90>;
regulator-max-microvolt = <330>;
regulator-boot-on;
@@ -62,6 +70,7 @@ Example:
};
 
ldo3_reg: ldo3 {
+   reg = <5>;
regulator-min-microvolt = <180>;
regulator-max-microvolt = <330>;
regulator-boot-on;
@@ -69,6 +78,7 @@ Example:
};
 
ldo4_reg: ldo4 {
+   reg = <6>;
regulator-min-microvolt = <180>;
regulator-max-microvolt = <330>;
regulator-boot-on;
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi 
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index fec7834..0c4bde0 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -285,10 +285,8 @@
};
 };
 
-
-/include/ "tps65217.dtsi"
-
  {
+   compatible = "ti,tps65217";
/*
 * Configure pmic to enter OFF-state instead of SLEEP-state ("RTC-only
 * mode") at poweroff.  Most BeagleBone versions do not support RTC-only
@@ -309,12 +307,17 @@
ti,pmic-shutdown-controller;
 
regulators {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
dcdc1_reg: regulator@0 {
+   reg = <0>;
regulator-name = "vdds_dpr";
regulator-always-on;
};
 
dcdc2_reg: regulator@1 {
+   reg = <1>;
/* VDD_MPU voltage limits 0.95V - 1.26V with +/-4% 
tolerance */
regulator-name = "vdd_mpu";
regulator-min-microvolt = <925000>;
@@ -324,6 +327,7 @@
};
 
dcdc3_reg: regulator@2 {
+   reg = <2>;
 

[PATCH 0/6] ARM: OMAP2+: dts: cm-t335: initial support

[Uri Mashiach]

Add basic support for CompuLab cm-t335 module based on AM335X SoC.

CM-T335 is a tiny computer-on-module (CoM) / system-on-module (SoM)
The module is built around the Texas Instruments Sitara AM3352/4
system-on-chip.

The CPU is supplemented with up-to 512MB DDR3 and up-to 1GB of on-board
NAND storage, WiFi connected to SPI, Bluetooth, Analog audio, Gigabit
Ethernet, CAN bus.

Ilya Ledvich (6):
  ARM: OMAP2+: dts: cm-t335: add initial support
  ARM: OMAP2+: dts: cm-t335: add basic support for I2C
  ARM: OMAP2+: dts: cm-t335: add support for NAND flash
  ARM: OMAP2+: dts: cm-t335: add support for MMC
  ARM: OMAP2+: dts: cm-t335: add support for network device
  ARM: OMAP2+: dts: cm-t335: add support for PWM backlight

 .../devicetree/bindings/arm/omap/omap.txt  |   3 +
 arch/arm/boot/dts/Makefile |   7 +-
 arch/arm/boot/dts/am335x-cm-t335.dts   | 347 +
 3 files changed, 354 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/boot/dts/am335x-cm-t335.dts

-- 
2.6.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 1/6] ARM: OMAP2+: dts: cm-t335: add initial support

[Uri Mashiach]

From: Ilya Ledvich 

Add basic support for CompuLab cm-t335 module based on AM335X SoC.

CM-T335 is a tiny computer-on-module (CoM) / system-on-module (SoM)
The module is built around the Texas Instruments Sitara AM3352/4
system-on-chip.

The CPU is supplemented with up-to 512MB DDR3 and up-to 1GB of on-board
NAND storage, WiFi connected to SPI, Bluetooth, Analog audio, Gigabit
Ethernet, CAN bus.

Current patch adds support:
UART0 and GPIO LED

Detailed description can be found at the module site:
http://www.compulab.co.il/products/computer-on-modules/cm-t335/

Acked-by: Igor Grinberg 
Signed-off-by: Ilya Ledvich 
[uri.mashi...@compulab.co.il: the default RAM amount reduced to
128MB to support also the minimal module configuration]
Signed-off-by: Uri Mashiach 
---
 .../devicetree/bindings/arm/omap/omap.txt  |  3 ++
 arch/arm/boot/dts/Makefile |  7 +--
 arch/arm/boot/dts/am335x-cm-t335.dts   | 62 ++
 3 files changed, 69 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/boot/dts/am335x-cm-t335.dts

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 9f4e513..2154f97 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -138,6 +138,9 @@ Boards:
 - AM335X phyBOARD-WEGA: Single Board Computer dev kit
   compatible = "phytec,am335x-wega", "phytec,am335x-phycore-som", "ti,am33xx"
 
+- AM335X CM-T335 : System On Module, built around the Sitara AM3352/4
+  compatible = "compulab,cm-t335", "ti,am33xx"
+
 - OMAP5 EVM : Evaluation Module
   compatible = "ti,omap5-evm", "ti,omap5"
 
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bb8fa02..0e011dc 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -446,13 +446,14 @@ dtb-$(CONFIG_SOC_AM33XX) += \
am335x-base0033.dtb \
am335x-bone.dtb \
am335x-boneblack.dtb \
-   am335x-sl50.dtb \
+   am335x-chiliboard.dtb \
+   am335x-cm-t335.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
+   am335x-lxm.dtb \
am335x-nano.dtb \
am335x-pepper.dtb \
-   am335x-lxm.dtb \
-   am335x-chiliboard.dtb \
+   am335x-sl50.dtb \
am335x-wega-rdk.dtb
 dtb-$(CONFIG_ARCH_OMAP4) += \
omap4-duovero-parlor.dtb \
diff --git a/arch/arm/boot/dts/am335x-cm-t335.dts 
b/arch/arm/boot/dts/am335x-cm-t335.dts
new file mode 100644
index 000..197d5ce
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-cm-t335.dts
@@ -0,0 +1,62 @@
+/*
+ * am335x-cm-t335.dts - Device Tree file for Compulab CM-T335
+ *
+ * Copyright (C) 2014 - 2015 CompuLab Ltd. - http://www.compulab.co.il/
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+#include "am33xx.dtsi"
+
+/ {
+   model = "CompuLab CM-T335";
+   compatible = "compulab,cm-t335", "ti,am33xx";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x800>;   /* 128 MB */
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_led_pins>;
+   led@0 {
+   label = "cm_t335:green";
+   gpios = < 0 GPIO_ACTIVE_LOW>; /* gpio2_0 */
+   linux,default-trigger = "heartbeat";
+   };
+   };
+};
+
+_pinmux {
+   pinctrl-names = "default";
+   pinctrl-0 = <>;
+
+   gpio_led_pins: pinmux_gpio_led_pins {
+   pinctrl-single,pins = <
+   0x88 (PIN_OUTPUT | MUX_MODE7)   /* gpmc_csn3.gpio2_0 */
+   >;
+   };
+
+   uart0_pins: pinmux_uart0_pins {
+   pinctrl-single,pins = <
+   /* uart0_rxd.uart0_rxd */
+   0x170 (PIN_INPUT_PULLUP | MUX_MODE0)
+   /* uart0_txd.uart0_txd */
+   0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)
+   >;
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   status = "okay";
+};
+
-- 
2.6.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 3/6] ARM: OMAP2+: dts: cm-t335: add support for NAND flash

[Uri Mashiach]

From: Ilya Ledvich 

Add pinmux configuration for NAND specific GPMC pins.
Add description for GPMC controller. Add child node for NAND flash
including CM-T335 specific partition table to GPMC node.
Enable error-location module (ELM).

Acked-by: Igor Grinberg 
Signed-off-by: Ilya Ledvich 
Signed-off-by: Uri Mashiach 
---
 arch/arm/boot/dts/am335x-cm-t335.dts | 106 +++
 1 file changed, 106 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-cm-t335.dts 
b/arch/arm/boot/dts/am335x-cm-t335.dts
index 39df3d2..9d6117a 100644
--- a/arch/arm/boot/dts/am335x-cm-t335.dts
+++ b/arch/arm/boot/dts/am335x-cm-t335.dts
@@ -61,6 +61,41 @@
>;
};
 
+   nandflash_pins: pinmux_nandflash_pins {
+   pinctrl-single,pins = <
+   /* gpmc_ad0.gpmc_ad0 */
+   0x0 (PIN_INPUT_PULLUP | MUX_MODE0)
+   /* gpmc_ad1.gpmc_ad1 */
+   0x4 (PIN_INPUT_PULLUP | MUX_MODE0)
+   /* gpmc_ad2.gpmc_ad2 */
+   0x8 (PIN_INPUT_PULLUP | MUX_MODE0)
+   /* gpmc_ad3.gpmc_ad3 */
+   0xc (PIN_INPUT_PULLUP | MUX_MODE0)
+   /* gpmc_ad4.gpmc_ad4 */
+   0x10 (PIN_INPUT_PULLUP | MUX_MODE0)
+   /* gpmc_ad5.gpmc_ad5 */
+   0x14 (PIN_INPUT_PULLUP | MUX_MODE0)
+   /* gpmc_ad6.gpmc_ad6 */
+   0x18 (PIN_INPUT_PULLUP | MUX_MODE0)
+   /* gpmc_ad7.gpmc_ad7 */
+   0x1c (PIN_INPUT_PULLUP | MUX_MODE0)
+   /* gpmc_wait0.gpmc_wait0 */
+   0x70 (PIN_INPUT_PULLUP | MUX_MODE0)
+   /* gpmc_wpn.gpio0_30 */
+   0x74 (PIN_INPUT_PULLUP | MUX_MODE7)
+   /* gpmc_csn0.gpmc_csn0  */
+   0x7c (PIN_OUTPUT | MUX_MODE0)
+   /* gpmc_advn_ale.gpmc_advn_ale */
+   0x90 (PIN_OUTPUT | MUX_MODE0)
+   /* gpmc_oen_ren.gpmc_oen_ren */
+   0x94 (PIN_OUTPUT | MUX_MODE0)
+   /* gpmc_wen.gpmc_wen */
+   0x98 (PIN_OUTPUT | MUX_MODE0)
+   /* gpmc_be0n_cle.gpmc_be0n_cle */
+   0x9c (PIN_OUTPUT | MUX_MODE0)
+   >;
+   };
+
uart0_pins: pinmux_uart0_pins {
pinctrl-single,pins = <
/* uart0_rxd.uart0_rxd */
@@ -97,3 +132,74 @@
};
 };
 
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   ranges = <0 0 0x0800 0x1000>;   /* CS0: NAND */
+   nand@0,0 {
+   reg = <0 0 0>; /* CS0, offset 0 */
+   ti,nand-ecc-opt = "bch8";
+   ti,elm-id = <>;
+   nand-bus-width = <8>;
+   gpmc,device-width = <1>;
+   gpmc,sync-clk-ps = <0>;
+   gpmc,cs-on-ns = <0>;
+   gpmc,cs-rd-off-ns = <44>;
+   gpmc,cs-wr-off-ns = <44>;
+   gpmc,adv-on-ns = <6>;
+   gpmc,adv-rd-off-ns = <34>;
+   gpmc,adv-wr-off-ns = <44>;
+   gpmc,we-on-ns = <0>;
+   gpmc,we-off-ns = <40>;
+   gpmc,oe-on-ns = <0>;
+   gpmc,oe-off-ns = <54>;
+   gpmc,access-ns = <64>;
+   gpmc,rd-cycle-ns = <82>;
+   gpmc,wr-cycle-ns = <82>;
+   gpmc,wait-on-read = "true";
+   gpmc,wait-on-write = "true";
+   gpmc,bus-turnaround-ns = <0>;
+   gpmc,cycle2cycle-delay-ns = <0>;
+   gpmc,clk-activation-ns = <0>;
+   gpmc,wait-monitoring-ns = <0>;
+   gpmc,wr-access-ns = <40>;
+   gpmc,wr-data-mux-bus-ns = <0>;
+   /* MTD partition table */
+   #address-cells = <1>;
+   #size-cells = <1>;
+   partition@0 {
+   label = "spl";
+   reg = <0x 0x0020>;
+   };
+   partition@1 {
+   label = "uboot";
+   reg = <0x0020 0x0010>;
+   };
+   partition@2 {
+   label = "uboot environment";
+   reg = <0x0030 0x0010>;
+   };
+   partition@3 {
+   label = "dtb";
+   reg = <0x0040 0x0010>;
+   };
+   partition@4 {
+   label = "splash";
+   reg = <0x0050 0x0040>;
+   };
+   partition@5 {
+   label = "linux";
+   reg = <0x0090 0x0060>;
+   };

[PATCH 2/6] ARM: OMAP2+: dts: cm-t335: add basic support for I2C

[Uri Mashiach]

From: Ilya Ledvich 

Add pinmux configuration for I2C0 and I2C1 pins.
Add description for I2C0 bus, set clock frequency to 400kHz.
Add child nodes for 24c02 EEPROM and em3027 RTC on I2C0 bus.

Acked-by: Igor Grinberg 
Signed-off-by: Ilya Ledvich 
Signed-off-by: Uri Mashiach 
---
 arch/arm/boot/dts/am335x-cm-t335.dts | 37 
 1 file changed, 37 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-cm-t335.dts 
b/arch/arm/boot/dts/am335x-cm-t335.dts
index 197d5ce..39df3d2 100644
--- a/arch/arm/boot/dts/am335x-cm-t335.dts
+++ b/arch/arm/boot/dts/am335x-cm-t335.dts
@@ -37,6 +37,24 @@
pinctrl-names = "default";
pinctrl-0 = <>;
 
+   i2c0_pins: pinmux_i2c0_pins {
+   pinctrl-single,pins = <
+   /* i2c0_sda.i2c0_sda */
+   0x188 (PIN_INPUT_PULLUP | MUX_MODE0)
+   /* i2c0_scl.i2c0_scl */
+   0x18c (PIN_INPUT_PULLUP | MUX_MODE0)
+   >;
+   };
+
+   i2c1_pins: pinmux_i2c1_pins {
+   pinctrl-single,pins = <
+   /* uart0_ctsn.i2c1_sda */
+   0x168 (PIN_INPUT_PULLUP | MUX_MODE2)
+   /* uart0_rtsn.i2c1_scl */
+   0x16c (PIN_INPUT_PULLUP | MUX_MODE2)
+   >;
+   };
+
gpio_led_pins: pinmux_gpio_led_pins {
pinctrl-single,pins = <
0x88 (PIN_OUTPUT | MUX_MODE7)   /* gpmc_csn3.gpio2_0 */
@@ -60,3 +78,22 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   status = "okay";
+   clock-frequency = <40>;
+
+   eeprom: 24c02@50 {
+   compatible = "atmel,24c02";
+   reg = <0x50>;
+   pagesize = <16>;
+   };
+
+   ext_rtc: em3027@56 {
+   compatible = "emmicro,em3027";
+   reg = <0x56>;
+   };
+};
+
-- 
2.6.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 5/6] ARM: OMAP2+: dts: cm-t335: add support for network device

[Uri Mashiach]

From: Ilya Ledvich 

Add pinmux configurations for RGMII1 based CPSW Ethernet pins and
MDIO pins:
 - default configuration required for module in active state,
 - sleep configuration required for module in inactive state.
Add mac node with single slave device. Add nodes for davinci_mdio and
cpsw_emac0.

Acked-by: Igor Grinberg 
Signed-off-by: Ilya Ledvich 
Signed-off-by: Uri Mashiach 
---
 arch/arm/boot/dts/am335x-cm-t335.dts | 85 
 1 file changed, 85 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-cm-t335.dts 
b/arch/arm/boot/dts/am335x-cm-t335.dts
index 976c330..0296d3f 100644
--- a/arch/arm/boot/dts/am335x-cm-t335.dts
+++ b/arch/arm/boot/dts/am335x-cm-t335.dts
@@ -113,6 +113,71 @@
>;
};
 
+   cpsw_default: cpsw_default {
+   pinctrl-single,pins = <
+   /* Slave 1 */
+   /* mii1_txen.rgmii1_tctl */
+   0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)
+   /* mii1_rxdv.rgmii1_rctl */
+   0x118 (PIN_INPUT_PULLDOWN | MUX_MODE2)
+   /* mii1_txd3.rgmii1_td3 */
+   0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE2)
+   /* mii1_txd2.rgmii1_td2 */
+   0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)
+   /* mii1_txd1.rgmii1_td1 */
+   0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)
+   /* mii1_txd0.rgmii1_td0 */
+   0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)
+   /* mii1_txclk.rgmii1_tclk */
+   0x12c (PIN_OUTPUT_PULLDOWN | MUX_MODE2)
+   /* mii1_rxclk.rgmii1_rclk */
+   0x130 (PIN_INPUT_PULLDOWN | MUX_MODE2)
+   /* mii1_rxd3.rgmii1_rd3 */
+   0x134 (PIN_INPUT_PULLDOWN | MUX_MODE2)
+   /* mii1_rxd2.rgmii1_rd2 */
+   0x138 (PIN_INPUT_PULLDOWN | MUX_MODE2)
+   /* mii1_rxd1.rgmii1_rd1 */
+   0x13c (PIN_INPUT_PULLDOWN | MUX_MODE2)
+   /* mii1_rxd0.rgmii1_rd0 */
+   0x140 (PIN_INPUT_PULLDOWN | MUX_MODE2)
+   >;
+   };
+
+   cpsw_sleep: cpsw_sleep {
+   pinctrl-single,pins = <
+   /* Slave 1 reset value */
+   0x114 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+   0x118 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+   0x11c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+   0x120 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+   0x124 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+   0x128 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+   0x12c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+   0x130 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+   0x134 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+   0x138 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+   0x13c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+   0x140 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+   >;
+   };
+
+   davinci_mdio_default: davinci_mdio_default {
+   pinctrl-single,pins = <
+   /* mdio_data.mdio_data */
+   0x148 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)
+   /* mdio_clk.mdio_clk */
+   0x14c (PIN_OUTPUT_PULLUP | MUX_MODE0)
+   >;
+   };
+
+   davinci_mdio_sleep: davinci_mdio_sleep {
+   pinctrl-single,pins = <
+   /* MDIO reset value */
+   0x148 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+   0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+   >;
+   };
+
mmc1_pins: pinmux_mmc1_pins {
pinctrl-single,pins = <
/* mmc0_dat3.mmc0_dat3 */
@@ -228,6 +293,26 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_default>;
+   pinctrl-1 = <_sleep>;
+   slaves = <1>;
+   status = "okay";
+};
+
+_mdio {
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_mdio_default>;
+   pinctrl-1 = <_mdio_sleep>;
+   status = "okay";
+};
+
+_emac0 {
+   phy_id = <_mdio>, <0>;
+   phy-mode = "rgmii-txid";
+};
+
  {
status = "okay";
vmmc-supply = <_fixed>;
-- 
2.6.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

Re: [PATCH 18/19] ARM: dts: ste: replace legacy *,wakeup property with wakeup-source

[Sudeep Holla]

On 27/10/15 12:34, Linus Walleij wrote:

On Wed, Oct 21, 2015 at 12:10 PM, Sudeep Holla  wrote:


Though the keyboard and other driver will continue to support the legacy
"gpio-key,wakeup", "linux,wakeup" boolean property to enable the wakeup
source, "wakeup-source" is the new standard binding.

This patch replaces all the legacy wakeup properties with the unified
"wakeup-source" property in order to avoid any futher copy-paste
duplication.

Cc: Linus Walleij 
Signed-off-by: Sudeep Holla 


Acked-by: Linus Walleij 

Are you sending this to ARM SoC or do I need to handle the
patch?



Many platform maintainers preferred to pick up via their tree, so if you
want to pick up with other STE patches, I am fine as there's no
dependency on the driver changes.

--
Regards,
Sudeep
--
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] regulator: tps6520x: add dt support for tps6502x regulator

[Heiko Schocher]

add DT support for the tps6502x regulators.

Signed-off-by: Heiko Schocher 
---

Changes in v4:
- add comment from Mark Brown:
- adapt subject line to "regulator: tps6520x:"
- use the generic support for locating the DT information
  for regulators using regulators_node and of_match in the
  regulator_desc. Could only test DT support. As this
  touches also platform code handling, it would be good
  to have a "Tested-by" from someone who can test it on
  a platform based board ...

Changes in v3:
- fold kbuild patch:
  regulator, dt: fix platform_no_drv_owner.cocci warnings
  into this patch
  No need to set .owner here. The core will do it.

Changes in v2:
- add comment from kbuild test robot
  - tps6502x_parse_dt_data() can be static
- add comment from Mark Brown:
  - remove arch/arm/boot/dts/tps65023.dtsi
  - do not use "regulator-compatible"

 .../devicetree/bindings/regulator/tps6502x.txt |  61 
 drivers/regulator/tps65023-regulator.c | 324 -
 2 files changed, 246 insertions(+), 139 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/regulator/tps6502x.txt

diff --git a/Documentation/devicetree/bindings/regulator/tps6502x.txt 
b/Documentation/devicetree/bindings/regulator/tps6502x.txt
new file mode 100644
index 000..dfb23d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps6502x.txt
@@ -0,0 +1,61 @@
+TPS6502x family of regulators
+
+Required properties:
+- compatible: "ti,tps65020", "ti,tps65021" or "ti,tps65023"
+- reg: I2C slave address
+- regulators: list of regulators provided by this controller, must be named
+  after their hardware counterparts: dcdc[1-3] and ldo[1-2]
+- regulators: This is the list of child nodes that specify the regulator
+  initialization data for defined regulators. Not all regulators for the given
+  device need to be present. The definition for each of these nodes is defined
+  using the standard binding for regulators found at
+  Documentation/devicetree/bindings/regulator/regulator.txt.
+
+Each regulator is defined using the standard binding for regulators.
+
+Example:
+
+   tps: tps@48 {
+   compatible = "ti,tps65023";
+
+   regulators {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   vdcdc1_reg: vdcdc1 {
+   reg = <0>;
+   regulator-name = "vdd_core";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   regulator-always-on;
+   };
+   vdcdc2_reg: vdcdc2 {
+   reg = <1>;
+   regulator-name = "vddshv";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+   vdcdc3_reg: vdcdc3 {
+   reg = <2>;
+   regulator-name = "vdds";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
+   vldo1_reg: ldo1 {
+   reg = <3>;
+   regulator-name = "vdda1p8v_usbphy";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
+   vldo2_reg: ldo2 {
+   reg = <4>;
+   regulator-name = "vdda3p3v_usbphy";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+   };
+   };
diff --git a/drivers/regulator/tps65023-regulator.c 
b/drivers/regulator/tps65023-regulator.c
index 5cc19b4..ffeb3b5 100644
--- a/drivers/regulator/tps65023-regulator.c
+++ b/drivers/regulator/tps65023-regulator.c
@@ -25,6 +25,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 /* Register definitions */
 #defineTPS65023_REG_VERSION0
@@ -86,6 +90,44 @@
 
 #define TPS65023_MAX_REG_IDTPS65023_LDO_2
 
+#define TPS65023_REGULATOR(_name, _id, _of_match, _ops, _n, _vr, _vm, _em, \
+  _t) \
+   {   \
+   .name   = _name,\
+   .id = _id,  \
+   .of_match   = of_match_ptr(_of_match), 

[PATCH v8 1/5] Documentation: add sbsa-gwdt driver documentation

[fu . wei]

From: Fu Wei 

The sbsa-gwdt.txt documentation in devicetree/bindings/watchdog is for
introducing SBSA(Server Base System Architecture) Generic Watchdog
device node info into FDT.

Also add sbsa-gwdt introduction in watchdog-parameters.txt

Acked-by: Arnd Bergmann 
Signed-off-by: Fu Wei 
---
 .../devicetree/bindings/watchdog/sbsa-gwdt.txt | 46 ++
 Documentation/watchdog/watchdog-parameters.txt |  6 +++
 2 files changed, 52 insertions(+)

diff --git a/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt 
b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
new file mode 100644
index 000..ad8e99a
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
@@ -0,0 +1,46 @@
+* SBSA (Server Base System Architecture) Generic Watchdog
+
+The SBSA Generic Watchdog Timer is used to force a reset of the system
+after two stages of timeout have elapsed.  A detailed definition of the
+watchdog timer can be found in the ARM document: ARM-DEN-0029 - Server
+Base System Architecture (SBSA)
+
+Required properties:
+- compatible: Should at least contain "arm,sbsa-gwdt".
+
+- reg: Each entry specifies the base physical 64-bit address of a register
+  frame and the 64-bit length of that frame; currently, two frames must be
+  defined, in this order:
+  1: Watchdog control frame
+  2: Refresh frame.
+
+- interrupts: At least one interrupt must be defined that will be used as
+  the WS0 interrupt.  A WS1 interrupt definition can be provided, but is
+  optional.  The interrupts must be defined in this order:
+  1: WS0 interrupt
+  2: WS1 interrupt
+
+Optional properties
+- timeout-sec: To use a timeout value that is different from the driver
+  default values, use this property.  If used, at least one timeout value
+  (in seconds) must be provided.  A second optional timeout value (in
+  seconds) may also be provided and will be used as the pre-timeout value,
+  if it is given.
+
+  There are two possible sources for driver default timeout values:
+  (1) the driver contains hard-coded default values, or
+  (2) module parameters can be given when the module is loaded
+
+  If timeout/pretimeout values are provided when the module loads, they
+  will take priority.  Second priority will be the timeout-sec from DTB,
+  and third the hard-coded driver values.
+
+Example for FVP Foundation Model v8:
+
+watchdog@2a44 {
+   compatible = "arm,sbsa-gwdt";
+   reg = <0x0 0x2a44 0 0x1000>,
+ <0x0 0x2a45 0 0x1000>;
+   interrupts = <0 27 4>;
+   timeout-sec = <60 30>;
+};
diff --git a/Documentation/watchdog/watchdog-parameters.txt 
b/Documentation/watchdog/watchdog-parameters.txt
index 9f9ec9f..e62c8c4 100644
--- a/Documentation/watchdog/watchdog-parameters.txt
+++ b/Documentation/watchdog/watchdog-parameters.txt
@@ -284,6 +284,12 @@ sbc_fitpc2_wdt:
 margin: Watchdog margin in seconds (default 60s)
 nowayout: Watchdog cannot be stopped once started
 -
+sbsa_gwdt:
+timeout: Watchdog timeout in seconds. (default 60s)
+pretimeout: Watchdog pretimeout in seconds. (default 30s)
+nowayout: Watchdog cannot be stopped once started
+   (default=kernel config parameter)
+-
 sc1200wdt:
 isapnp: When set to 0 driver ISA PnP support will be disabled (default=1)
 io: io port
-- 
2.4.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

[PATCH v8 3/5] ARM64: add SBSA Generic Watchdog device node in amd-seattle-soc.dtsi

[fu . wei]

From: Fu Wei 

This can be a example of adding SBSA Generic Watchdog device node
into some dts files for the Soc which contains SBSA Generic Watchdog.

Acked-by: Arnd Bergmann 
Acked-by: Suravee Suthikulpanit 
Tested-by: Suravee Suthikulpanit 
Signed-off-by: Fu Wei 
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi 
b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index 2874d92..f62d60c1 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -84,6 +84,14 @@
clock-names = "uartclk", "apb_pclk";
};
 
+   watchdog0: watchdog@e0bb {
+   compatible = "arm,sbsa-gwdt";
+   reg = <0x0 0xe0bc 0 0x1000>,
+   <0x0 0xe0bb 0 0x1000>;
+   interrupts = <0 337 4>;
+   timeout-sec = <60 30>;
+   };
+
spi0: ssp@e102 {
status = "disabled";
compatible = "arm,pl022", "arm,primecell";
-- 
2.4.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

[PATCH v8 5/5] Watchdog: introduce ARM SBSA watchdog driver

[fu . wei]

From: Fu Wei 

This driver bases on linux kernel watchdog framework, and
use "pretimeout" in the framework. It supports getting timeout and
pretimeout from parameter and FDT at the driver init stage.
In first timeout, the interrupt routine run panic to save
system context.

Signed-off-by: Fu Wei 
Tested-by: Pratyush Anand 
---
 drivers/watchdog/Kconfig |  14 ++
 drivers/watchdog/Makefile|   1 +
 drivers/watchdog/sbsa_gwdt.c | 459 +++
 3 files changed, 474 insertions(+)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 79e1aa1..5cc8455 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -173,6 +173,20 @@ config ARM_SP805_WATCHDOG
  ARM Primecell SP805 Watchdog timer. This will reboot your system when
  the timeout is reached.
 
+config ARM_SBSA_WATCHDOG
+   tristate "ARM SBSA Generic Watchdog"
+   depends on ARM64
+   depends on ARM_ARCH_TIMER
+   select WATCHDOG_CORE
+   help
+ ARM SBSA Generic Watchdog. This watchdog has two Watchdog timeouts.
+ The first timeout will trigger a panic; the second timeout will
+ trigger a system reset.
+ More details: ARM DEN0029B - Server Base System Architecture (SBSA)
+
+ To compile this driver as module, choose M here: The module
+ will be called sbsa_gwdt.
+
 config AT91RM9200_WATCHDOG
tristate "AT91RM9200 watchdog"
depends on SOC_AT91RM9200 && MFD_SYSCON
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 0c616e3..b74a3ea 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
 
 # ARM Architecture
 obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
+obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o
 obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o
 obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
 obj-$(CONFIG_CADENCE_WATCHDOG) += cadence_wdt.o
diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
new file mode 100644
index 000..6fd1c63
--- /dev/null
+++ b/drivers/watchdog/sbsa_gwdt.c
@@ -0,0 +1,459 @@
+/*
+ * SBSA(Server Base System Architecture) Generic Watchdog driver
+ *
+ * Copyright (c) 2015, Linaro Ltd.
+ * Author: Fu Wei 
+ * Suravee Suthikulpanit 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License 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.
+ *
+ * The SBSA Generic watchdog driver is compatible with the pretimeout
+ * concept of Linux kernel.
+ * The timeout and pretimeout are determined by WCV or WOR.
+ * The first watch period is set by writing WCV directly, that can
+ * support more than 10s timeout at the maximum system counter
+ * frequency (400MHz).
+ * When WS0 is triggered, the second watch period (pretimeout) is
+ * determined by one of these registers:
+ * (1)WOR: 32bit register, this gives a maximum watch period of
+ * around 10s at the maximum system counter frequency. It's loaded
+ * automatically by hardware.
+ * (2)WCV: If the pretimeout value is greater then "max_wor_timeout",
+ * it will be loaded in WS0 interrupt routine. If system is in
+ * ws0_mode (reboot with watchdog enabled and WS0 == true), the ping
+ * operation will only reload WCV.
+ * More details about the hardware specification of this device:
+ * ARM DEN0029B - Server Base System Architecture (SBSA)
+ *
+ * Kernel/API: P--| pretimeout
+ *   |T timeout
+ * SBSA GWDT:  P---WOR (or WCV)---WS1 pretimeout
+ *   |---WCV--WS0~~~(ws0_mode)T timeout
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* SBSA Generic Watchdog register definitions */
+/* refresh frame */
+#define SBSA_GWDT_WRR  0x000
+
+/* control frame */
+#define SBSA_GWDT_WCS  0x000
+#define SBSA_GWDT_WOR  0x008
+#define SBSA_GWDT_WCV_LO   0x010
+#define SBSA_GWDT_WCV_HI   0x014
+
+/* refresh/control frame */
+#define SBSA_GWDT_W_IIDR   0xfcc
+#define SBSA_GWDT_IDR  0xfd0
+
+/* Watchdog Control and Status Register */
+#define SBSA_GWDT_WCS_EN   BIT(0)
+#define SBSA_GWDT_WCS_WS0  BIT(1)
+#define SBSA_GWDT_WCS_WS1  BIT(2)
+
+/**
+ * struct 

[PATCH v8 4/5] Watchdog: introdouce "pretimeout" into framework

[fu . wei]

From: Fu Wei 

Also update Documentation/watchdog/watchdog-kernel-api.txt to
introduce:
(1)the new elements in the watchdog_device and watchdog_ops struct;
(2)the new API "watchdog_init_timeouts"

Reasons:
(1)kernel already has two watchdog drivers are using "pretimeout":
drivers/char/ipmi/ipmi_watchdog.c
drivers/watchdog/kempld_wdt.c(but the definition is different)
(2)some other drivers are going to use this: ARM SBSA Generic Watchdog

Signed-off-by: Fu Wei 
Tested-by: Pratyush Anand 
---
 Documentation/watchdog/watchdog-kernel-api.txt |  55 +--
 drivers/watchdog/watchdog_core.c   | 127 +++--
 drivers/watchdog/watchdog_dev.c|  53 +++
 include/linux/watchdog.h   |  39 +++-
 4 files changed, 232 insertions(+), 42 deletions(-)

diff --git a/Documentation/watchdog/watchdog-kernel-api.txt 
b/Documentation/watchdog/watchdog-kernel-api.txt
index d8b0d33..9be942c 100644
--- a/Documentation/watchdog/watchdog-kernel-api.txt
+++ b/Documentation/watchdog/watchdog-kernel-api.txt
@@ -53,6 +53,9 @@ struct watchdog_device {
unsigned int timeout;
unsigned int min_timeout;
unsigned int max_timeout;
+   unsigned int pretimeout;
+   unsigned int min_pretimeout;
+   unsigned int max_pretimeout;
void *driver_data;
struct mutex lock;
unsigned long status;
@@ -75,6 +78,9 @@ It contains following fields:
 * timeout: the watchdog timer's timeout value (in seconds).
 * min_timeout: the watchdog timer's minimum timeout value (in seconds).
 * max_timeout: the watchdog timer's maximum timeout value (in seconds).
+* pretimeout: the watchdog timer's pretimeout value (in seconds).
+* min_pretimeout: the watchdog timer's minimum pretimeout value (in seconds).
+* max_pretimeout: the watchdog timer's maximum pretimeout value (in seconds).
 * bootstatus: status of the device after booting (reported with watchdog
   WDIOF_* status bits).
 * driver_data: a pointer to the drivers private data of a watchdog device.
@@ -99,6 +105,7 @@ struct watchdog_ops {
int (*ping)(struct watchdog_device *);
unsigned int (*status)(struct watchdog_device *);
int (*set_timeout)(struct watchdog_device *, unsigned int);
+   int (*set_pretimeout)(struct watchdog_device *, unsigned int);
unsigned int (*get_timeleft)(struct watchdog_device *);
void (*ref)(struct watchdog_device *);
void (*unref)(struct watchdog_device *);
@@ -156,13 +163,24 @@ they are supported. These optional routines/operations 
are:
 * status: this routine checks the status of the watchdog timer device. The
   status of the device is reported with watchdog WDIOF_* status flags/bits.
 * set_timeout: this routine checks and changes the timeout of the watchdog
-  timer device. It returns 0 on success, -EINVAL for "parameter out of range"
-  and -EIO for "could not write value to the watchdog". On success this
-  routine should set the timeout value of the watchdog_device to the
-  achieved timeout value (which may be different from the requested one
-  because the watchdog does not necessarily has a 1 second resolution).
+  timer device. It returns 0 on success, -EINVAL for "parameter out of
+  range" (e.g., if the driver supports pretimeout, then the requested
+  timeout value must be greater than the pretimeout value) and -EIO for
+  "could not write value to the watchdog". On success this routine will
+  set the timeout value of the watchdog_device to an actual timeout value
+  (which may be different from the requested one because the watchdog does
+  not necessarily have a 1 second resolution).
   (Note: the WDIOF_SETTIMEOUT needs to be set in the options field of the
   watchdog's info structure).
+* set_pretimeout: this routine checks and changes the pretimeout of the
+  watchdog timer device. It returns 0 on success, -EINVAL for "parameter
+  out of range" and -EIO for "could not write value to the watchdog". On
+  success this routine will set the pretimeout value of the
+  watchdog_device to an actual pretimeout value (which may be different
+  from the requested one because the watchdog does not necessarily have a
+  1 second resolution).
+  (Note: the WDIOF_PRETIMEOUT needs to be set in the options field of the
+  watchdog's info structure).
 * get_timeleft: this routines returns the time that's left before a reset.
 * ref: the operation that calls kref_get on the kref of a dynamically
   allocated watchdog_device struct.
@@ -226,8 +244,27 @@ extern int watchdog_init_timeout(struct watchdog_device 
*wdd,
   unsigned int timeout_parm, struct device 
*dev);
 
 The watchdog_init_timeout function allows you to initialize the timeout field
-using the module timeout parameter or by retrieving the timeout-sec property 
from
-the device tree (if the module timeout parameter is invalid). Best 

Re: [PATCH 2/3] ARM: zynq: DT: Add interrupt-controller property to GPIO

[Linus Walleij]

On Fri, Oct 23, 2015 at 6:25 PM, Soren Brinkmann
 wrote:

> GPIO can be used as interrupt-controller. Add the missing properties to
> the GPIO node.
>
> Signed-off-by: Soren Brinkmann 

Acked-by: Linus Walleij 

Yours,
Linus Walleij
--
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/5] ARM64: add SBSA Generic Watchdog device node in foundation-v8.dts

[fu . wei]

From: Fu Wei 

This can be a example of adding SBSA Generic Watchdog device node
into some dts files for the Soc which contains SBSA Generic Watchdog.

Acked-by: Arnd Bergmann 
Signed-off-by: Fu Wei 
---
 arch/arm64/boot/dts/arm/foundation-v8.dts | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/arm/foundation-v8.dts 
b/arch/arm64/boot/dts/arm/foundation-v8.dts
index 4eac8dc..1a4fc40 100644
--- a/arch/arm64/boot/dts/arm/foundation-v8.dts
+++ b/arch/arm64/boot/dts/arm/foundation-v8.dts
@@ -237,4 +237,11 @@
};
};
};
+   watchdog@2a44 {
+   compatible = "arm,sbsa-gwdt";
+   reg = <0x0 0x2a44 0 0x1000>,
+   <0x0 0x2a45 0 0x1000>;
+   interrupts = <0 27 4>;
+   timeout-sec = <60 30>;
+   };
 };
-- 
2.4.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 v8 1/5] Documentation: add sbsa-gwdt driver documentation

[Mark Rutland]

On Wed, Oct 28, 2015 at 12:06:35AM +0800, fu@linaro.org wrote:
> From: Fu Wei 
> 
> The sbsa-gwdt.txt documentation in devicetree/bindings/watchdog is for
> introducing SBSA(Server Base System Architecture) Generic Watchdog
> device node info into FDT.
> 
> Also add sbsa-gwdt introduction in watchdog-parameters.txt
> 
> Acked-by: Arnd Bergmann 
> Signed-off-by: Fu Wei 
> ---
>  .../devicetree/bindings/watchdog/sbsa-gwdt.txt | 46 
> ++
>  Documentation/watchdog/watchdog-parameters.txt |  6 +++
>  2 files changed, 52 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt 
> b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
> new file mode 100644
> index 000..ad8e99a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
> @@ -0,0 +1,46 @@
> +* SBSA (Server Base System Architecture) Generic Watchdog
> +
> +The SBSA Generic Watchdog Timer is used to force a reset of the system
> +after two stages of timeout have elapsed.  A detailed definition of the
> +watchdog timer can be found in the ARM document: ARM-DEN-0029 - Server
> +Base System Architecture (SBSA)
> +
> +Required properties:
> +- compatible: Should at least contain "arm,sbsa-gwdt".
> +
> +- reg: Each entry specifies the base physical 64-bit address of a register
> +  frame and the 64-bit length of that frame; currently, two frames must be

Remove "64-bit" here. This depends on #address-cells and #size-cells, as
usual.

> +  defined, in this order:
> +  1: Watchdog control frame
> +  2: Refresh frame.
> +
> +- interrupts: At least one interrupt must be defined that will be used as
> +  the WS0 interrupt.  A WS1 interrupt definition can be provided, but is
> +  optional.  The interrupts must be defined in this order:
> +  1: WS0 interrupt
> +  2: WS1 interrupt

Why is WS1 optional?

> +Optional properties
> +- timeout-sec: To use a timeout value that is different from the driver
> +  default values, use this property. 

Either define a default value, or don't state anything about the
behaviour when this is not present.

>If used, at least one timeout value
> +  (in seconds) must be provided.  A second optional timeout value (in
> +  seconds) may also be provided and will be used as the pre-timeout value,
> +  if it is given.
> +
> +  There are two possible sources for driver default timeout values:
> +  (1) the driver contains hard-coded default values, or
> +  (2) module parameters can be given when the module is loaded
> +
> +  If timeout/pretimeout values are provided when the module loads, they
> +  will take priority.  Second priority will be the timeout-sec from DTB,
> +  and third the hard-coded driver values.

The last two paragraphs should go. They describe Linux behaviour rather
than the binding.

Thanks,
Mark.
--
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 v8 6/8] scsi: ufs: make the UFS variant a platform device

[Gilad Broner]

Reviewed-by: Gilad Broner 

> This change turns the UFS variant (SCSI_UFS_QCOM) into a UFS
> a platform device.
> In order to do so a few additional changes are required:
> 1. The ufshcd-pltfrm is no longer serves as a platform device.
>Now it only serves as a group of platform APIs such as PM APIs
>(runtime suspend/resume, system suspend/resume etc), parsers of
>clocks, regulators and pm_levels from DT.
> 2. What used to be the old platform "probe" is now "only"
>a pltfrm_init() routine, that does exactly the same, but only
>being called by the new probe function of the UFS variant.
>
> Signed-off-by: Yaniv Gardi 
>
> ---
>  Documentation/devicetree/bindings/ufs/ufs-qcom.txt | 58 +
>  .../devicetree/bindings/ufs/ufshcd-pltfrm.txt  | 11 ++-
>  drivers/scsi/ufs/ufs-qcom.c| 62 +-
>  drivers/scsi/ufs/ufshcd-pltfrm.c   | 98
> ++
>  drivers/scsi/ufs/ufshcd-pltfrm.h   | 41 +
>  drivers/scsi/ufs/ufshcd.c  | 10 +++
>  drivers/scsi/ufs/ufshcd.h  |  1 +
>  7 files changed, 207 insertions(+), 74 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/ufs/ufs-qcom.txt
>  create mode 100644 drivers/scsi/ufs/ufshcd-pltfrm.h
>
> diff --git a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt
> b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt
> new file mode 100644
> index 000..070baf4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt
> @@ -0,0 +1,58 @@
> +* Qualcomm Technologies Inc Universal Flash Storage (UFS) PHY
> +
> +UFSPHY nodes are defined to describe on-chip UFS PHY hardware macro.
> +Each UFS PHY node should have its own node.
> +
> +To bind UFS PHY with UFS host controller, the controller node should
> +contain a phandle reference to UFS PHY node.
> +
> +Required properties:
> +- compatible: compatible list, contains "qcom,ufs-phy-qmp-20nm"
> +   or "qcom,ufs-phy-qmp-14nm" according to the relevant phy 
> in use.
> +- reg   : should contain PHY register address space
> (mandatory),
> +- reg-names : indicates various resources passed to driver (via
> reg proptery) by name.
> +  Required "reg-names" is "phy_mem".
> +- #phy-cells: This property shall be set to 0
> +- vdda-phy-supply   : phandle to main PHY supply for analog domain
> +- vdda-pll-supply   : phandle to PHY PLL and Power-Gen block power supply
> +- clocks : List of phandle and clock specifier pairs
> +- clock-names   : List of clock input name strings sorted in the same
> +   order as the clocks property. "ref_clk_src", "ref_clk",
> +   "tx_iface_clk" & "rx_iface_clk" are mandatory but
> +   "ref_clk_parent" is optional
> +
> +Optional properties:
> +- vdda-phy-max-microamp : specifies max. load that can be drawn from phy
> supply
> +- vdda-pll-max-microamp : specifies max. load that can be drawn from pll
> supply
> +- vddp-ref-clk-supply   : phandle to UFS device ref_clk pad power supply
> +- vddp-ref-clk-max-microamp : specifies max. load that can be drawn from
> this supply
> +- vddp-ref-clk-always-on : specifies if this supply needs to be kept
> always on
> +
> +Example:
> +
> + ufsphy1: ufsphy@0xfc597000 {
> + compatible = "qcom,ufs-phy-qmp-20nm";
> + reg = <0xfc597000 0x800>;
> + reg-names = "phy_mem";
> + #phy-cells = <0>;
> + vdda-phy-supply = <_l4>;
> + vdda-pll-supply = <_l12>;
> + vdda-phy-max-microamp = <5>;
> + vdda-pll-max-microamp = <1000>;
> + clock-names = "ref_clk_src",
> + "ref_clk_parent",
> + "ref_clk",
> + "tx_iface_clk",
> + "rx_iface_clk";
> + clocks = <_rpm clk_ln_bb_clk>,
> + <_gcc clk_pcie_1_phy_ldo >,
> + <_gcc clk_ufs_phy_ldo>,
> + <_gcc clk_gcc_ufs_tx_cfg_clk>,
> + <_gcc clk_gcc_ufs_rx_cfg_clk>;
> + };
> +
> + ufshc@0xfc598000 {
> + ...
> + phys = <>;
> + phy-names = "ufsphy";
> + };
> diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
> b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
> index 5357919..03c0e98 100644
> --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
> +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
> @@ -4,11 +4,18 @@ UFSHC nodes are defined to describe on-chip UFS host
> controllers.
>  Each UFS controller instance should have its own node.
>
>  Required properties:
> -- compatible: compatible list, contains "jedec,ufs-1.1"
> +- compatible : must contain "jedec,ufs-1.1", may also list one or 
> more
> +

Re: [PATCH v2 02/32] devicetree: bindings: scsi: HiSi SAS

[Mark Rutland]

> +  - ctrl-reg : offset to the following SAS control registers (in order):
> + - reset assert
> + - clock disable
> + - reset status
> + - reset de-assert
> + - clock enable

[...]

> >It would be better to have each offset in a separate property.
> >
> These register are not used for different purpose.
> Instead, they are all used for one purpose, reset the sas controller;
> Though a bit complicated, the silicon has special requirement here.

While they are indeed used together, they are separate registers, as
listed above. There may be other registers in future that turn out to
be useful for the SAS controller, or it might turn out a new system
doesn't have all of the existing registers.

> So still prefer using the original method,
> ctrl-reg = <0xa60 0x33c 0x5a30 0xa64 0x338>;
> Since we can simply use of_property_read_u32_array.

That may be simpler now, but makes future maintenance harder.

Use separate properties.

Mark.
--
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: dts: Added syscon-reboot node for FSL's LS2085A SoC

[Mark Rutland]

On Fri, Oct 23, 2015 at 08:31:20PM -0500, J. German Rivera wrote:
> Added sys-reboot node to the FSL's LS2085A SoC DT to leverage
> the ARM-generic reboot mechanism for this SoC. This mechanism
> is enabled through CONFIG_POWER_RESET_SYSCON.

Per the comments in arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi, the
platform has PSCI 0.2+, and therefore already has system reset
functionality.

Given that, why is this necessary?

Thanks,
Mark.

> Signed-off-by: J. German Rivera 
> ---
>  arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi 
> b/arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi
> index e281ceb..6f82163 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi
> @@ -131,6 +131,18 @@
>   interrupts = <1 9 0x4>;
>   };
>  
> + rst_ccsr: rstccsr@1E6 {
> + compatible = "syscon";
> + reg = <0x0 0x1E6 0x0 0x1>;
> + };
> +
> + reboot@65024000 {
> + compatible ="syscon-reboot";
> + regmap = <_ccsr>;
> + offset = <0x0>;
> + mask = <0x2>;
> + };
> +
>   timer {
>   compatible = "arm,armv8-timer";
>   interrupts = <1 13 0x8>, /* Physical Secure PPI, active-low */
> -- 
> 2.3.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 v3 0/2] watchdog: driver for BCM7038 and newer chips.

[Wim Van Sebroeck]

Hi Justin,

> This driver is for a watchdog block contained in all Broadcom Set-top
> Box chips since BCM7038. BCM7038 was made public during the 2004 CES,
> and since then, many chips use this watchdog block including some cable
> modem chips.
> 
> Changes since v2:
> Added clk_disable_unprepare if watchdog fails to register.
> 
> Changes since v1:
> Removed clock-frequency because it brought unnecessary complexity to the
> driver.
> Renamed a few variables.
> 
> Patch 1: watchdog device tree binding documentation
> 
> Patch 2: watchdog driver
> 
> Justin Chen (2):
>   watchdog: bcm7038: add device tree binding documentation
>   watchdog: Watchdog driver for Broadcom Set-Top Box
> 
>  .../bindings/watchdog/brcm,bcm7038-wdt.txt |  19 ++
>  drivers/watchdog/Kconfig   |   8 +
>  drivers/watchdog/Makefile  |   1 +
>  drivers/watchdog/bcm7038_wdt.c | 237 
> +
>  4 files changed, 265 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
>  create mode 100644 drivers/watchdog/bcm7038_wdt.c

Patches added to linux-watchdog-next.

Kind regards,
Wim.

--
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: [v2 01/10] ata: ahci_brcmstb: add quick for broken ncq

[Florian Fainelli]

On 26/10/15 23:48, Jaedon Shin wrote:
> Add quick for bronken ncq. The chipsets (eg. BCM7439A0, BCM7445A0 and
> BCM7445B0) need a workaround disabling NCQ. and it may need the
> MIPS-based set-top box platforms.

None of these chips are production chips, so at this point, disabling
NCQ should be done based on the compatible string we probed the driver
with, not using a specific property.

There are more comments below

> 
> Signed-off-by: Jaedon Shin 
> ---

[snip]

>  
> +static void brcm_sata_quick(struct platform_device *pdev,
> + struct brcm_ahci_priv *priv)
> +{
> + void __iomem *ahci;
> + struct resource *res;
> + u32 reg;
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ahci");
> + ahci = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(ahci))
> + return;
> +
> + if (priv->quicks & BRCM_AHCI_QUICK_NONCQ) {
> + reg  = readl(priv->top_ctrl + SATA_TOP_CTRL_BUS_CTRL);
> + reg |= OVERRIDE_HWINIT;
> + writel(reg, priv->top_ctrl + SATA_TOP_CTRL_BUS_CTRL);
> +
> + /* Clear out the NCQ bit so the AHCI driver will not issue
> +  * FPDMA/NCQ commands.
> +  */
> + reg = readl(ahci + HOST_CAP);
> + reg &= ~HOST_CAP_NCQ;
> + writel(reg, ahci + HOST_CAP);
> +
> + reg = readl(priv->top_ctrl + SATA_TOP_CTRL_BUS_CTRL);
> + reg &= ~OVERRIDE_HWINIT;
> + writel(reg, priv->top_ctrl + SATA_TOP_CTRL_BUS_CTRL);
> + }

In the original BSP, the NCQ disabling occurs prior to initializing the
SATA controller endianess. We would want to keep doing that in the same
order, and use brcm_sata_readreg() and brcm_sata_writereg() which take
care of doing these accesses in the native endianess of the system.

Reference is here:

https://github.com/Broadcom/stblinux-3.3/blob/master/linux/drivers/brcmstb/bchip.c#L254

> +
> + devm_iounmap(>dev, ahci);
> + devm_release_mem_region(>dev, res->start, resource_size(res));
> +}
> +
>  #ifdef CONFIG_PM_SLEEP
>  static int brcm_ahci_suspend(struct device *dev)
>  {
> @@ -256,7 +294,11 @@ static int brcm_ahci_probe(struct platform_device *pdev)
>   if (IS_ERR(priv->top_ctrl))
>   return PTR_ERR(priv->top_ctrl);
>  
> + if (of_property_read_bool(dev->of_node, "brcm,broken-ncq"))
> + priv->quicks |= BRCM_AHCI_QUICK_NONCQ;
> +
>   brcm_sata_init(priv);
> + brcm_sata_quick(pdev, priv);
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: [PATCH v2 02/32] devicetree: bindings: scsi: HiSi SAS

[Mark Rutland]

On Tue, Oct 27, 2015 at 01:09:15PM +, John Garry wrote:
> On 26/10/2015 14:45, Mark Rutland wrote:
> >On Mon, Oct 26, 2015 at 10:14:33PM +0800, John Garry wrote:
> >>Add devicetree bindings for HiSilicon SAS driver.
> >>
> >>Signed-off-by: John Garry 
> >>---
> >>  .../devicetree/bindings/scsi/hisilicon-sas.txt | 70 
> >> ++
> >>  1 file changed, 70 insertions(+)
> >>  create mode 100644 
> >> Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
> >>
> >>diff --git a/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt 
> >>b/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
> >>new file mode 100644
> >>index 000..d1e7b2a
> >>--- /dev/null
> >>+++ b/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
> >>@@ -0,0 +1,70 @@
> >>+* HiSilicon SAS controller
> >>+
> >>+The HiSilicon SAS controller supports SAS/SATA.
> >>+
> >>+Main node required properties:
> >>+  - compatible : value should be as follows:
> >>+   (a) "hisilicon,sas-controller-v1" for v1 of HiSilicon SAS controller IP
> >>+  - reg : Address and length of the SAS register
> >>+  - hisilicon,sas-syscon: phandle of syscon used for sas control
> >>+  - ctrl-reg : offset to the following SAS control registers (in order):
> >>+   - reset assert
> >>+   - clock disable
> >>+   - reset status
> >>+   - reset de-assert
> >>+   - clock enable
> >
> >This needs a better name, and it should probably be split up into
> >several properties.
> >
> >However, it sounds like the syscon is actually a clock+reset
> >controller, and should be modelled as such. It's not actually a part of
> >the SAS controller as such.
> 
> The syscon block is a general subsystem control block, and it is not
> specifically only for controlling reset and enabling clocks (other
> functions include serdes control, for example). It is also shared
> with other peripherals.
> 
> So we can remove the ctrl-reg property (since it is not part of the
> SAS controller), and add the relevant syscon register offsets to the
> "hisilicon,sas-syscon" property, like this:
> hisilicon,sas-syscon = <_ctrl0 0xa60 0x33c 0x5a30 0xa64 0x338>;
> 
> Ok?

It would be better to have each offset in a separate property.

Mark.
--
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 02/32] devicetree: bindings: scsi: HiSi SAS

[zhangfei]

On 10/27/2015 10:39 PM, Mark Rutland wrote:

On Tue, Oct 27, 2015 at 01:09:15PM +, John Garry wrote:

On 26/10/2015 14:45, Mark Rutland wrote:

On Mon, Oct 26, 2015 at 10:14:33PM +0800, John Garry wrote:

Add devicetree bindings for HiSilicon SAS driver.

Signed-off-by: John Garry 
---
  .../devicetree/bindings/scsi/hisilicon-sas.txt | 70 ++
  1 file changed, 70 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/scsi/hisilicon-sas.txt

diff --git a/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt 
b/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
new file mode 100644
index 000..d1e7b2a
--- /dev/null
+++ b/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
@@ -0,0 +1,70 @@
+* HiSilicon SAS controller
+
+The HiSilicon SAS controller supports SAS/SATA.
+
+Main node required properties:
+  - compatible : value should be as follows:
+   (a) "hisilicon,sas-controller-v1" for v1 of HiSilicon SAS controller IP
+  - reg : Address and length of the SAS register
+  - hisilicon,sas-syscon: phandle of syscon used for sas control
+  - ctrl-reg : offset to the following SAS control registers (in order):
+   - reset assert
+   - clock disable
+   - reset status
+   - reset de-assert
+   - clock enable


This needs a better name, and it should probably be split up into
several properties.

However, it sounds like the syscon is actually a clock+reset
controller, and should be modelled as such. It's not actually a part of
the SAS controller as such.


The syscon block is a general subsystem control block, and it is not
specifically only for controlling reset and enabling clocks (other
functions include serdes control, for example). It is also shared
with other peripherals.

So we can remove the ctrl-reg property (since it is not part of the
SAS controller), and add the relevant syscon register offsets to the
"hisilicon,sas-syscon" property, like this:
hisilicon,sas-syscon = <_ctrl0 0xa60 0x33c 0x5a30 0xa64 0x338>;

Ok?


It would be better to have each offset in a separate property.


These register are not used for different purpose.
Instead, they are all used for one purpose, reset the sas controller;
Though a bit complicated, the silicon has special requirement here.

So still prefer using the original method,
ctrl-reg = <0xa60 0x33c 0x5a30 0xa64 0x338>;
Since we can simply use of_property_read_u32_array.

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 v6 04/22] of: add function to allow probing a device from a OF node

[Tomeu Vizoso]

On 26 October 2015 at 09:16, Geert Uytterhoeven  wrote:
> On Mon, Sep 21, 2015 at 4:02 PM, Tomeu Vizoso
>  wrote:
>> Walks the OF tree up and finds the closest ancestor that has a struct
>> device associated with it, probing it if isn't bound to a driver yet.
>>
>> The above should ensure that the dependency represented by the passed OF
>> node is available, because probing a device should cause its descendants
>> to be probed as well (when they get registered).
>>
>> Subsystems can use this when looking up resources for drivers, to reduce
>> the chances of deferred probes because of the probing order of devices.
>>
>> Signed-off-by: Tomeu Vizoso 
>
> Don't know to which response I should post this comment, so I'm responding
> to the original email.
>
> Some subsystems already do this.
> If you call e.g. syscon_regmap_lookup_by_phandle(), it will call
> of_syscon_register() if the syscon device pointed to hasn't been registered 
> yet.

Hi Geert,

I think I prefer if devices are registered as early as possible and
then only probed on-demand, as registration is very much
device-specific but probing is the same for all devices.

But I think in general we should be doing more things on demand and
depending less on the order in which we mass initialize stuff
(devices, classes, drivers, etc).

Regards,

Tomeu

> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
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: [v2 03/10] ata: ahci_brcmstb: add quick for broken phy

[Florian Fainelli]

On 26/10/15 23:48, Jaedon Shin wrote:
> Add quick for broken phy. The ARM-based 28nm chipsets have four phy
> interface control registers and each port has two registers. But, The
> MIPS-based 40nm chipsets have three. and there are no information and
> documentation. The legacy version of broadcom's strict-ahci based
> initial code did not control these registers.

Qualifying this of a broken PHY is a misnomer, this is more about the
fact that the PHY control registers have a different layout and behavior
on 40nm vs 28nm chips, but more importantly, do not require any kind of
configuration.

> 
> Signed-off-by: Jaedon Shin 
> ---
>  Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt |  1 +
>  drivers/ata/ahci_brcmstb.c  | 10 ++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt 
> b/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt
> index 488a383ce202..0f0925d58188 100644
> --- a/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt
> +++ b/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt
> @@ -12,6 +12,7 @@ Required properties:
>  
>  Optional properties:
>  - brcm,broken-ncq: if present, NCQ is unusable
> +- brcm,broken-phy: if present, to control phy interface is unusable

Same comment as in patch 1, this is something that can be known based on
the compatible string, and the name of the property is misleading.

>  
>  Also see ahci-platform.txt.
>  
> diff --git a/drivers/ata/ahci_brcmstb.c b/drivers/ata/ahci_brcmstb.c
> index e53962cb48ee..c61303f7c7dc 100644
> --- a/drivers/ata/ahci_brcmstb.c
> +++ b/drivers/ata/ahci_brcmstb.c
> @@ -71,6 +71,7 @@
>  
>  enum brcm_ahci_quicks {
>   BRCM_AHCI_QUICK_NONCQ   = BIT(0),
> + BRCM_AHCI_QUICK_NOPHY   = BIT(1),

I would use something like BRCM_AHCI_SKIP_PHY_ENABLE or something like
that to illustrate what this really is about.

>  };
>  
>  struct brcm_ahci_priv {
> @@ -119,6 +120,9 @@ static void brcm_sata_phy_enable(struct brcm_ahci_priv 
> *priv, int port)
>   void __iomem *p;
>   u32 reg;
>  
> + if (priv->quicks & BRCM_AHCI_QUICK_NOPHY)
> + return;
> +
>   /* clear PHY_DEFAULT_POWER_STATE */
>   p = phyctrl + SATA_TOP_CTRL_PHY_CTRL_1;
>   reg = brcm_sata_readreg(p);
> @@ -148,6 +152,9 @@ static void brcm_sata_phy_disable(struct brcm_ahci_priv 
> *priv, int port)
>   void __iomem *p;
>   u32 reg;
>  
> + if (priv->quicks & BRCM_AHCI_QUICK_NOPHY)
> + return;
> +
>   /* power-off the PHY digital logic */
>   p = phyctrl + SATA_TOP_CTRL_PHY_CTRL_2;
>   reg = brcm_sata_readreg(p);
> @@ -297,6 +304,9 @@ static int brcm_ahci_probe(struct platform_device *pdev)
>   if (of_property_read_bool(dev->of_node, "brcm,broken-ncq"))
>   priv->quicks |= BRCM_AHCI_QUICK_NONCQ;
>  
> + if (of_property_read_bool(dev->of_node, "brcm,broken-phy"))
> + priv->quicks |= BRCM_AHCI_QUICK_NOPHY;
> +
>   brcm_sata_init(priv);
>   brcm_sata_quick(pdev, priv);
>  
> 


-- 
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