[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 = &priv->phys[id];
port->portnum = id;
port->phy_priv = priv;
-   port->phy = devm_phy_create(dev, child, &phy_ops_28nm);
+   port->phy = devm_phy_create(dev, child, &phy_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 "unsubscribe d

[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 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 = <&periph_intc>;
+   interrupts = <86>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   brcm,broken-ncq;
+   brcm,broken-phy;
+   status = "disabled";
+
+   sata0: sata-port@0 {
+   reg = <0>;
+   phys = <&sata_phy0>;
+   };
+
+   sata1: sata-port@1 {
+   reg = <1>;
+   phys = <&sata_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 @@
 &ohci0 {
status = "okay";
 };
+
+&sata {
+   status = "okay";
+};
+
+&sata_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 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 = &pdev->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 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

[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 = <&periph_intc>;
+   interrupts = <40>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   brcm,broken-ncq;
+   brcm,broken-phy;
+   status = "disabled";
+
+   sata0: sata-port@0 {
+   reg = <0>;
+   phys = <&sata_phy0>;
+   };
+
+   sata1: sata-port@1 {
+   reg = <1>;
+   phys = <&sata_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 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 = <&periph_intc>;
+   interrupts = <40>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   brcm,broken-ncq;
+   brcm,broken-phy;
+   status = "disabled";
+
+   sata0: sata-port@0 {
+   reg = <0>;
+   phys = <&sata_phy0>;
+   };
+
+   sata1: sata-port@1 {
+   reg = <1>;
+   phys = <&sata_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 @@
 &ohci3 {
status = "okay";
 };
+
+&sata {
+   status = "okay";
+};
+
+&sata_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 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(&pdev->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(&pdev->dev, ahci);
+   devm_release_mem_region(&pdev->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

[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 = <&mt6397_vemc_3v3_reg>;
vqmmc-supply = <&mt6397_vio18_reg>;
-   clocks = <&pericfg CLK_PERI_MSDC30_0>, <&topckgen 
CLK_TOP_MSDC50_0_H_SEL>;
+   clocks = <&pericfg CLK_PERI_MSDC30_0>,
+<&topckgen CLK_TOP_MSDC50_0_H_SEL>;
clock-names = "source", "hclk";
pinctrl-names = "default", "state_uhs";
pinctrl-0 = <&mmc0_pins_default>;
pinctrl-1 = <&mmc0_pins_uhs>;
+   assigned-clocks = <&topckgen CLK_TOP_MSDC50_0_SEL>;
+   assigned-clock-parents = <&topckgen 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 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

[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, &host->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 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 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(&pdev->dev,
-   sizeof(struct mt_gpdma_desc),
+   2 * sizeof(struct mt_gpdma_desc),
&host->dma.gpd_addr, GFP_KERNEL);
host->dma.bd = dma_alloc_coherent(&pdev->dev,
MAX_BD_NUM * sizeof(struct mt_bdma_desc),
@@ -1347,7 +1350,7 @@ release:
 release_mem:
if (host->dma.gpd)
dma_free_coherent(&pdev->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(&pdev->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 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

[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, &mrq);
 
+   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;
min += ES

[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 = <&mt6397_vemc_3v3_reg>;
vqmmc-supply = <&mt6397_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 = <&mmc0_pins_default>;
pinctrl-1 = <&mmc0_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 = <&mt6397_vemc_3v3_reg>;
vqmmc-supply = <&mt6397_vio18_reg>;
+   assigned-clocks = <&topckgen CLK_TOP_MSDC50_0_SEL>;
+   assigned-clock-parents = <&topckgen CLK_TOP_MSDCPLL_D2>;
non-removable;
 };
 
@@ -84,9 +89,10 @@
pinctrl-0 = <&mmc1_pins_default>;
pinctrl-1 = <&mmc1_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 = <&pio 132 0>;
vmmc-supply = <&mt6397_vmch_reg>;
vqmmc-supply = <&mt6397_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 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

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

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"
-
  &tps {
+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_dp

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
+++ b/arch/arm/boot/dts/am335x-bone-comm

Re: [PATCH 1/3] dt-bindings: add document of mediatek efuse driver

[andrew-ct chen]

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.

> 
> --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 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.
> 
> >   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 = &pdev->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, &mtk_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 = "mediatek,mt8173-efuse",},
> > +   {/* sentinel */},
> > +};
> > +MODULE_DEVICE_TABLE(of, mtk_efuse_of_match);
> > +
> > +static struct platform_driver mtk_efuse_driver = {
> > +   .probe = mtk_efuse_probe,
> > +   .remove = mtk_efuse_remove,
> > +   .driver = {
> > +   .name = "mediatek,efuse",
> > +   .of_match_table = mtk_efuse_of_match,
> > +   },
> > +};
> > +module_platfo

Re: [PATCH v3 3/5] mtd: ofpart: update devicetree binding specification

[Rob Herring]

On Sun, Oct 11, 2015 at 3:04 PM, Brian Norris
 wrote:
> Hi DT maintainers,
>
> It's a bit hypocritical of me, since I've been a slow reviewer as well,
> but... can we get some review on this one? Usually, I'm comfortable
> taking driver DT bindings without your review, but this one is a bit
> more generic and is more far-reaching than the average driver.

Sorry, missed this one. This would be a good one to send to
devicetree-spec to BTW.

> I'm not a big fan of this change, and I don't quite understand why the
> bus driver (the SPI bus, which is a level up from the SPI device / MTD
> node) can specify its grandchildren (see spi-samsung.txt). But given the

That's just an example. I just would change it.

> constraints, I think Michal's solution is OK. And I do agree that MTD's
> ofpart should be bit more specific.
>
> Anyway, a quick look and an Ack/Nak would be appreciated.

Looks fine to me:

Acked-by: Rob Herring 

>
> Thanks,
> Brian
>
> On Tue, Aug 18, 2015 at 03:34:08PM -, Michal Suchanek wrote:
>> To avoid conflict with other drivers using subnodes of the mtd device
>> create only one ofpart-specific node rather than any number of
>> arbitrary partition subnodes.
>>
>> Signed-off-by: Michal Suchanek 
>> ---
>> v3:
>>
>>  - rename DT node ofpart -> partitions
>> ---
>>  .../devicetree/bindings/mtd/partition.txt  | 68 
>> +-
>>  1 file changed, 40 insertions(+), 28 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/partition.txt 
>> b/Documentation/devicetree/bindings/mtd/partition.txt
>> index 8e5557d..8c2aff7 100644
>> --- a/Documentation/devicetree/bindings/mtd/partition.txt
>> +++ b/Documentation/devicetree/bindings/mtd/partition.txt
>> @@ -4,10 +4,16 @@ Partitions can be represented by sub-nodes of an mtd 
>> device. This can be used
>>  on platforms which have strong conventions about which portions of a flash 
>> are
>>  used for what purposes, but which don't use an on-flash partition table such
>>  as RedBoot.
>> +
>> +The partition table should be partitions subnode of the mtd node. 
>> Partitions are
>> +defined in subnodes of the partitions node.
>> +
>> +For backwards compatibility partitions as direct subnodes of the mtd device 
>> are
>> +supported. This use is discouraged.
>>  NOTE: if the sub-node has a compatible string, then it is not a partition.
>>
>> -#address-cells & #size-cells must both be present in the mtd device. There 
>> are
>> -two valid values for both:
>> +#address-cells & #size-cells must both be present in the partitions subnode 
>> of the
>> +mtd device. There are two valid values for both:
>>  <1>: for partitions that require a single 32-bit cell to represent their
>>   size/address (aka the value is below 4 GiB)
>>  <2>: for partitions that require two 32-bit cells to represent their
>> @@ -28,44 +34,50 @@ Examples:
>>
>>
>>  flash@0 {
>> - #address-cells = <1>;
>> - #size-cells = <1>;
>> + partitions {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>>
>> - partition@0 {
>> - label = "u-boot";
>> - reg = <0x000 0x10>;
>> - read-only;
>> - };
>> + partition@0 {
>> + label = "u-boot";
>> + reg = <0x000 0x10>;
>> + read-only;
>> + };
>>
>> - uimage@10 {
>> - reg = <0x010 0x20>;
>> + uimage@10 {
>> + reg = <0x010 0x20>;
>> + };
>>   };
>>  };
>>
>>  flash@1 {
>> - #address-cells = <1>;
>> - #size-cells = <2>;
>> + partitions {
>> + #address-cells = <1>;
>> + #size-cells = <2>;
>>
>> - /* a 4 GiB partition */
>> - partition@0 {
>> - label = "filesystem";
>> - reg = <0x 0x1 0x>;
>> + /* a 4 GiB partition */
>> + partition@0 {
>> + label = "filesystem";
>> + reg = <0x 0x1 0x>;
>> + };
>>   };
>>  };
>>
>>  flash@2 {
>> - #address-cells = <2>;
>> - #size-cells = <2>;
>> + partitions {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>>
>> - /* an 8 GiB partition */
>> - partition@0 {
>> - label = "filesystem #1";
>> - reg = <0x0 0x 0x2 0x>;
>> - };
>> + /* an 8 GiB partition */
>> + partition@0 {
>> + label = "filesystem #1";
>> + reg = <0x0 0x 0x2 0x>;
>> + };
>>
>> - /* a 4 GiB partition */
>> - partition@2 {
>> - label = "filesystem #2";
>> - reg = <0x2 0x 0x1 0x>;
>> + /* a 4 GiB partition */
>> + partition@2 {
>> + label = "filesystem #2";
>> + reg = <0x2 0x

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Tuesday, October 20, 2015 12:04:05 PM Alan Stern wrote:
> On Tue, 20 Oct 2015, Mark Brown wrote:
> 
> > On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> > 
> > > Furthermore, that applies only to devices that use synchronous suspend.  
> > > Async suspend is becoming common, and there the only restrictions are 
> > > parent-child relations plus whatever explicit requirements that drivers 
> > > impose by calling device_pm_wait_for_dev().
> > 
> > Hrm, this is the first I'd noticed that feature though I see the initial
> > commit dates from January.
> 
> Async suspend and device_pm_wait_for_dev() were added in January 2010, 
> not 2015!
> 
> >  It looks like most of the users are PCs at
> > the minute but we should be using it more widely for embedded things,
> > there's definitely some cases I'm aware of where it will allow us to
> > remove some open coding.
> > 
> > It does seem like we want to be feeding dependency information we
> > discover for probing way into the suspend dependencies...
> 
> Rafael has been thinking about a way to do this systematically.  
> Nothing concrete has emerged yet.

Well, good point. :-)

I've been kind of struggling with finding time to work on the patches lately
and some aspects of the design are still not finalized.  It seems, though, that
it can be beneficial to discuss the approach in general, so let me start a new
thread for that.

Thanks,
Rafael

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

Re: [PATCH v2 1/3] clk: iproc: Extend binding to cover BCM63138

[Rob Herring]

On Mon, Oct 26, 2015 at 10:53 PM, Florian Fainelli  wrote:
> Broadcom BCM63138 DSL SoCs have the same ARMPLL clocking infrastructure
> as the Cygnus and iProc chips, add a dedicated compatible string and
> document that the ARMPLL node is a valid node for this chip.
>
> Signed-off-by: Florian Fainelli 

Acked-by: Rob Herring 

> ---
> No changes in v2
>
>  Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt 
> b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
> index ede65a55e21b..0b35e71b39e8 100644
> --- a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
> +++ b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
> @@ -208,3 +208,8 @@ These clock IDs are defined in:
>  ch3_unused lcpll_ports 4   BCM_NS2_LCPLL_PORTS_CH3_UNUSED
>  ch4_unused lcpll_ports 5   BCM_NS2_LCPLL_PORTS_CH4_UNUSED
>  ch5_unused lcpll_ports 6   BCM_NS2_LCPLL_PORTS_CH5_UNUSED
> +
> +BCM63138
> +
> +PLL and leaf clock compatible strings for BCM63138 are:
> +"brcm,bcm63138-armpll"
> --
> 2.1.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
--
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 0/3] clk: Broadcom BCM63138 support

[Ray Jui]

On 10/26/2015 8:53 PM, Florian Fainelli wrote:

Hi all,

This patch series adds support for the Broadcom BCM63138 DSL SoCs
clocking framework.

Since the HW is identical to the one found in Broadcom iProc SoCs, but the
integration is different (obviously), there is still a new compatible string
introduced just in case we happen to find issues in the future.

This applies on top of clk/next as of
679c51cffc3b316bd89ecc91ef92603dd6d4fc68 ("clk: Add stubs for of_clk_*() APIs when 
CONFIG_OF=n")

Since there is an obvious dependency between patch 2 and 3, we can either
merge this through the Clock tree or via a future arm-soc pull requests
for Broadcom SoCs.

Florian Fainelli (3):
   clk: iproc: Extend binding to cover BCM63138
   clk: bcm: Add BCM63138 clock support
   ARM: dts: BCM63xx: Add ARMPLL device tree nodes

  .../bindings/clock/brcm,iproc-clocks.txt   |  5 +++
  arch/arm/boot/dts/bcm63138.dtsi| 39 --
  drivers/clk/bcm/Kconfig| 10 ++
  drivers/clk/bcm/Makefile   |  1 +
  drivers/clk/bcm/clk-bcm63xx.c  | 22 
  5 files changed, 67 insertions(+), 10 deletions(-)
  create mode 100644 drivers/clk/bcm/clk-bcm63xx.c



The entire patch set looks good to me.

Reviewed-by: Ray Jui 

Thanks,

Ray


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

[PATCH v2 3/3] ARM: dts: BCM63xx: Add ARMPLL device tree nodes

[Florian Fainelli]

Add the ARM PLL controller which comes standard with the Cortex-A9 found
on the BCM63138 SoCs. This is the same controller as the one found in
the Broadcom iProc architecture, however, we have a separate compatible
string to indicate the integration difference.

While at it, properly rename references to the 50Mhz clock which is in
fact a crystal/oscillator and updates references to it.

Signed-off-by: Florian Fainelli 
---
No changes in v2

 arch/arm/boot/dts/bcm63138.dtsi | 39 +--
 1 file changed, 29 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/bcm63138.dtsi b/arch/arm/boot/dts/bcm63138.dtsi
index 34cd64051250..c146325eebdb 100644
--- a/arch/arm/boot/dts/bcm63138.dtsi
+++ b/arch/arm/boot/dts/bcm63138.dtsi
@@ -43,17 +43,29 @@
#address-cells = <1>;
#size-cells = <0>;
 
-   arm_timer_clk: arm_timer_clk {
+   osc: oscillator {
#clock-cells = <0>;
compatible = "fixed-clock";
-   clock-frequency = <5>;
+   clock-frequency = <5000>;
+   clock-output-names = "periph";
};
 
-   periph_clk: periph_clk {
+   /* peripheral clock for system timer */
+   axi_clk: axi_clk {
#clock-cells = <0>;
-   compatible = "fixed-clock";
-   clock-frequency = <5000>;
-   clock-output-names = "periph";
+   compatible = "fixed-factor-clock";
+   clocks = <&armpll>;
+   clock-div = <2>;
+   clock-mult = <1>;
+   };
+
+   /* APB bus clock */
+   apb_clk: apb_clk {
+   #clock-cells = <0>;
+   compatible = "fixed-factor-clock";
+   clocks = <&armpll>;
+   clock-div = <4>;
+   clock-mult = <1>;
};
};
 
@@ -93,14 +105,14 @@
compatible = "arm,cortex-a9-global-timer";
reg = <0x1e200 0x20>;
interrupts = ;
-   clocks = <&arm_timer_clk>;
+   clocks = <&axi_clk>;
};
 
local_timer: local-timer@1e600 {
compatible = "arm,cortex-a9-twd-timer";
reg = <0x1e600 0x20>;
interrupts = ;
-   clocks = <&arm_timer_clk>;
+   clocks = <&axi_clk>;
};
 
twd_watchdog: watchdog@1e620 {
@@ -109,6 +121,13 @@
interrupts = ;
};
 
+   armpll: armpll {
+   #clock-cells = <0>;
+   compatible = "brcm,bcm63138-armpll";
+   clocks = <&osc>;
+   reg = <0x2 0xf00>;
+   };
+
pmb0: reset-controller@4800c0 {
compatible = "brcm,bcm63138-pmb";
reg = <0x4800c0 0x10>;
@@ -138,7 +157,7 @@
compatible = "brcm,bcm6345-uart";
reg = <0x600 0x1b>;
interrupts = ;
-   clocks = <&periph_clk>;
+   clocks = <&osc>;
clock-names = "periph";
status = "disabled";
};
@@ -147,7 +166,7 @@
compatible = "brcm,bcm6345-uart";
reg = <0x620 0x1b>;
interrupts = ;
-   clocks = <&periph_clk>;
+   clocks = <&osc>;
clock-names = "periph";
status = "disabled";
};
-- 
2.1.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 v2 2/3] clk: bcm: Add BCM63138 clock support

[Florian Fainelli]

BCM63138 has a simple clocking domain which is primarily the ARMPLL
clocking complex, from which the ARM (CPU), APB and AXI clocks would be
derived from.

Since the ARMPLL controller is entirely compatible with the iProc ARM
PLL, we just initialize it without additional parameters.

Signed-off-by: Florian Fainelli 
---
Changes in v2:
- added COMPILE_TEST

 drivers/clk/bcm/Kconfig   | 10 ++
 drivers/clk/bcm/Makefile  |  1 +
 drivers/clk/bcm/clk-bcm63xx.c | 22 ++
 3 files changed, 33 insertions(+)
 create mode 100644 drivers/clk/bcm/clk-bcm63xx.c

diff --git a/drivers/clk/bcm/Kconfig b/drivers/clk/bcm/Kconfig
index 85260fb96b36..a0c18528b70d 100644
--- a/drivers/clk/bcm/Kconfig
+++ b/drivers/clk/bcm/Kconfig
@@ -1,3 +1,13 @@
+config CLK_BCM_63XX
+   bool "Broadcom BCM63xx clock support"
+   depends on ARCH_BCM_63XX || COMPILE_TEST
+   depends on COMMON_CLK
+   select COMMON_CLK_IPROC
+   default y
+   help
+ Enable common clock framework support for Broadcom BCM63xx DSL SoCs
+ based on the ARM architecture
+
 config CLK_BCM_KONA
bool "Broadcom Kona CCU clock support"
depends on ARCH_BCM_MOBILE || COMPILE_TEST
diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
index 3fc95060d875..247c26750d8b 100644
--- a/drivers/clk/bcm/Makefile
+++ b/drivers/clk/bcm/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_CLK_BCM_63XX) += clk-bcm63xx.o
 obj-$(CONFIG_CLK_BCM_KONA) += clk-kona.o
 obj-$(CONFIG_CLK_BCM_KONA) += clk-kona-setup.o
 obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm281xx.o
diff --git a/drivers/clk/bcm/clk-bcm63xx.c b/drivers/clk/bcm/clk-bcm63xx.c
new file mode 100644
index ..b7e0469d0522
--- /dev/null
+++ b/drivers/clk/bcm/clk-bcm63xx.c
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2015 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; 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 "clk-iproc.h"
+
+static void __init bcm63138_armpll_init(struct device_node *node)
+{
+   iproc_armpll_setup(node);
+}
+CLK_OF_DECLARE(bcm63138_armpll, "brcm,bcm63138-armpll", bcm63138_armpll_init);
-- 
2.1.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 v2 0/3] clk: Broadcom BCM63138 support

[Florian Fainelli]

Hi all,

This patch series adds support for the Broadcom BCM63138 DSL SoCs
clocking framework.

Since the HW is identical to the one found in Broadcom iProc SoCs, but the
integration is different (obviously), there is still a new compatible string
introduced just in case we happen to find issues in the future.

This applies on top of clk/next as of
679c51cffc3b316bd89ecc91ef92603dd6d4fc68 ("clk: Add stubs for of_clk_*() APIs 
when CONFIG_OF=n")

Since there is an obvious dependency between patch 2 and 3, we can either
merge this through the Clock tree or via a future arm-soc pull requests
for Broadcom SoCs.

Florian Fainelli (3):
  clk: iproc: Extend binding to cover BCM63138
  clk: bcm: Add BCM63138 clock support
  ARM: dts: BCM63xx: Add ARMPLL device tree nodes

 .../bindings/clock/brcm,iproc-clocks.txt   |  5 +++
 arch/arm/boot/dts/bcm63138.dtsi| 39 --
 drivers/clk/bcm/Kconfig| 10 ++
 drivers/clk/bcm/Makefile   |  1 +
 drivers/clk/bcm/clk-bcm63xx.c  | 22 
 5 files changed, 67 insertions(+), 10 deletions(-)
 create mode 100644 drivers/clk/bcm/clk-bcm63xx.c

-- 
2.1.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 v2 1/3] clk: iproc: Extend binding to cover BCM63138

[Florian Fainelli]

Broadcom BCM63138 DSL SoCs have the same ARMPLL clocking infrastructure
as the Cygnus and iProc chips, add a dedicated compatible string and
document that the ARMPLL node is a valid node for this chip.

Signed-off-by: Florian Fainelli 
---
No changes in v2

 Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt 
b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
index ede65a55e21b..0b35e71b39e8 100644
--- a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
+++ b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
@@ -208,3 +208,8 @@ These clock IDs are defined in:
 ch3_unused lcpll_ports 4   BCM_NS2_LCPLL_PORTS_CH3_UNUSED
 ch4_unused lcpll_ports 5   BCM_NS2_LCPLL_PORTS_CH4_UNUSED
 ch5_unused lcpll_ports 6   BCM_NS2_LCPLL_PORTS_CH5_UNUSED
+
+BCM63138
+
+PLL and leaf clock compatible strings for BCM63138 are:
+"brcm,bcm63138-armpll"
-- 
2.1.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: [linux-nfc] [PATCH v2 00/35] Few fixes and st21nfca/st-nci vendor_cmds support

[Samuel Ortiz]

On Tue, Oct 27, 2015 at 04:48:31AM +0100, Samuel Ortiz wrote:
> Hi Christophe,
> 
> On Mon, Oct 26, 2015 at 07:41:49AM +0100, Christophe Ricard wrote:
> > Hi Samuel,
> > 
> > I believe there was an issue when you applied my last series.
> > drivers/nfc/st-nci/vendor_cmds.c is not present and this introduce a
> > build fix already reported by kbuild robot.
> I add to manually install the st-nci vendor commands patch and forgot to
> git add vendor_cmds.c...
s/install/patch/

Cheers,
Samuel.
--
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 00/35] Few fixes and st21nfca/st-nci vendor_cmds support

[Samuel Ortiz]

Hi Christophe,

On Mon, Oct 26, 2015 at 07:41:49AM +0100, Christophe Ricard wrote:
> Hi Samuel,
> 
> I believe there was an issue when you applied my last series.
> drivers/nfc/st-nci/vendor_cmds.c is not present and this introduce a
> build fix already reported by kbuild robot.
I add to manually install the st-nci vendor commands patch and forgot to
git add vendor_cmds.c...

This should be all fixed now.

Cheers,
Samuel.
--
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] drivers: of: removing assignment of 0 to static variable

[Saurabh Sengar]

no need to initialise static variable with 0, hence correcting it.

Signed-off-by: Saurabh Sengar 
---
 drivers/of/fdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 6e82bc42..63699dd 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -184,7 +184,7 @@ static void * unflatten_dt_node(const void *blob,
struct property *pp, **prev_pp = NULL;
const char *pathp;
unsigned int l, allocl;
-   static int depth = 0;
+   static int depth;
int old_depth;
int offset;
int has_name = 0;
-- 
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] ARM: dts: uniphier: add system-bus-controller nodes

[Masahiro Yamada]

The System Bus Controller block has two register regions,
but having only the second one in a separate node was not nice.

Replace it with a new node with two register regions in it.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 7 +++
 arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 7 +++
 arch/arm/boot/dts/uniphier-ph1-pro5.dtsi| 7 +++
 arch/arm/boot/dts/uniphier-ph1-sld3.dtsi| 7 +++
 arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 7 +++
 arch/arm/boot/dts/uniphier-proxstream2.dtsi | 7 +++
 6 files changed, 18 insertions(+), 24 deletions(-)

diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi 
b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
index ae13469..af49381 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
@@ -200,10 +200,9 @@
clock-frequency = <10>;
};
 
-   system-bus-controller-misc@5980 {
-   compatible = 
"socionext,uniphier-system-bus-controller-misc",
-"syscon";
-   reg = <0x5980 0x2000>;
+   system-bus-controller@58c0 {
+   compatible = "socionext,uniphier-system-bus-controller";
+   reg = <0x58c0 0x400>, <0x5980 0x2000>;
};
 
usb0: usb@5a800100 {
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi 
b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
index 85377b2..254642f 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
@@ -232,10 +232,9 @@
clock-frequency = <40>;
};
 
-   system-bus-controller-misc@5980 {
-   compatible = 
"socionext,uniphier-system-bus-controller-misc",
-"syscon";
-   reg = <0x5980 0x2000>;
+   system-bus-controller@58c0 {
+   compatible = "socionext,uniphier-system-bus-controller";
+   reg = <0x58c0 0x400>, <0x5980 0x2000>;
};
 
usb2: usb@5a800100 {
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi 
b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
index 96da01e..11eb762 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
@@ -241,10 +241,9 @@
clock-frequency = <40>;
};
 
-   system-bus-controller-misc@5980 {
-   compatible = 
"socionext,uniphier-system-bus-controller-misc",
-"syscon";
-   reg = <0x5980 0x2000>;
+   system-bus-controller@58c0 {
+   compatible = "socionext,uniphier-system-bus-controller";
+   reg = <0x58c0 0x400>, <0x5980 0x2000>;
};
 
pinctrl: pinctrl@5f801000 {
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi 
b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
index 945b37f..691a17d 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
@@ -216,10 +216,9 @@
clock-frequency = <40>;
};
 
-   system-bus-controller-misc@5980 {
-   compatible = 
"socionext,uniphier-system-bus-controller-misc",
-"syscon";
-   reg = <0x5980 0x2000>;
+   system-bus-controller@58c0 {
+   compatible = "socionext,uniphier-system-bus-controller";
+   reg = <0x58c0 0x400>, <0x5980 0x2000>;
};
 
usb0: usb@5a800100 {
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi 
b/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
index c98428c..e88559b 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
@@ -200,10 +200,9 @@
clock-frequency = <10>;
};
 
-   system-bus-controller-misc@5980 {
-   compatible = 
"socionext,uniphier-system-bus-controller-misc",
-"syscon";
-   reg = <0x5980 0x2000>;
+   system-bus-controller@58c0 {
+   compatible = "socionext,uniphier-system-bus-controller";
+   reg = <0x58c0 0x400>, <0x5980 0x2000>;
};
 
usb0: usb@5a800100 {
diff --git a/arch/arm/boot/dts/uniphier-proxstream2.dtsi 
b/arch/arm/boot/dts/uniphier-proxstream2.dtsi
index ad5fb39..259f1a9 100644
--- a/arch/arm/boot/dts/uniphier-proxstream2.dtsi
+++ b/arch/arm/boot/dts/uniphier-proxstream2.dtsi
@@ -251,10 +251,9 @@
clock-frequency = <40>;
   

Re: [PATCH v4 0/2] powerpc/512x: add LocalPlus Bus FIFO device driver

[Vinod Koul]

On Thu, Oct 22, 2015 at 01:15:03AM +0300, Alexander Popov wrote:
> On 12.10.2015 00:08, Alexander Popov wrote:
> > This driver for Freescale MPC512x LocalPlus Bus FIFO (called SCLPC
> > in the Reference Manual) allows Direct Memory Access transfers
> > between RAM and peripheral devices on LocalPlus Bus.
> 
> > Changes in v4:
> >  - the race condition is fixed;
> >  - plenty of style fixes are made;
> >  - devm_* functions and EPROBE_DEFER are used in probe().
> 
> Hello,
> 
> I've done my best to fix the issues pointed by Timur Tabi and Vinod Koul.
> Could I have a feedback please?

I dont see to have v4 in my list :( Can you please repost

-- 
~Vinod
--
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 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.

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


signature.asc
Description: PGP signature

Re: [REPOST PATCH 0/3] dwc2 patches to allow wakeup on Rockchip rk3288

[John Youn]

On 10/21/2015 9:23 AM, Doug Anderson wrote:
> John,
> 
> On Mon, Jul 6, 2015 at 11:27 AM, Douglas Anderson  
> wrote:
>> This series of patches, together with
>>  from Chris Zhong and a
>> dts change allow us to wake up from a USB device on rk3288 boards.
>> The patches were tested on rk3288-jerry in the chromeos-3.14 kernel.
>> The chromeos-3.14 kernel tested included a full set of dwc2 backports
>> from upstream, so this is expected to function upstream once we get
>> everything setup there.
>>
>>
>> Douglas Anderson (3):
>>   USB: Export usb_wakeup_enabled_descendants()
>>   Documentation: dt-bindings: Add snps,need-phy-for-wake for dwc2 USB
>>   USB: dwc2: Don't turn off the usbphy in suspend if wakeup is enabled
>>
>>  Documentation/devicetree/bindings/usb/dwc2.txt |  4 +++
>>  drivers/usb/core/hub.c |  7 ++--
>>  drivers/usb/dwc2/core.h|  2 ++
>>  drivers/usb/dwc2/platform.c| 45 
>> --
>>  include/linux/usb/hcd.h|  5 +++
>>  5 files changed, 58 insertions(+), 5 deletions(-)
> 
> This series was posted a while ago.  Do you have any comments on it?
> Should I repost it?
> 
> Thanks!
> 
> -Doug
> 


Sorry, I must have missed it earlier.

Could you repost based on latest and I'll review.

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

Re: [PATCH v3 3/5] mtd: ofpart: update devicetree binding specification

[Brian Norris]

On Sun, Oct 11, 2015 at 01:04:02PM -0700, Brian Norris wrote:
> Hi DT maintainers,

Last call: I'd like a reviewer that
(1) does DT reviews somewhat regularly and
(2) is not me.

If I can't get one soon, I'll take this for 4.4.

Thanks,
Brian

> It's a bit hypocritical of me, since I've been a slow reviewer as well,
> but... can we get some review on this one? Usually, I'm comfortable
> taking driver DT bindings without your review, but this one is a bit
> more generic and is more far-reaching than the average driver.
> 
> I'm not a big fan of this change, and I don't quite understand why the
> bus driver (the SPI bus, which is a level up from the SPI device / MTD
> node) can specify its grandchildren (see spi-samsung.txt). But given the
> constraints, I think Michal's solution is OK. And I do agree that MTD's
> ofpart should be bit more specific.
> 
> Anyway, a quick look and an Ack/Nak would be appreciated.
> 
> Thanks,
> Brian
> 
> On Tue, Aug 18, 2015 at 03:34:08PM -, Michal Suchanek wrote:
> > To avoid conflict with other drivers using subnodes of the mtd device
> > create only one ofpart-specific node rather than any number of
> > arbitrary partition subnodes.
> > 
> > Signed-off-by: Michal Suchanek 
> > ---
> > v3:
> > 
> >  - rename DT node ofpart -> partitions
> > ---
> >  .../devicetree/bindings/mtd/partition.txt  | 68 
> > +-
> >  1 file changed, 40 insertions(+), 28 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/mtd/partition.txt 
> > b/Documentation/devicetree/bindings/mtd/partition.txt
> > index 8e5557d..8c2aff7 100644
> > --- a/Documentation/devicetree/bindings/mtd/partition.txt
> > +++ b/Documentation/devicetree/bindings/mtd/partition.txt
> > @@ -4,10 +4,16 @@ Partitions can be represented by sub-nodes of an mtd 
> > device. This can be used
> >  on platforms which have strong conventions about which portions of a flash 
> > are
> >  used for what purposes, but which don't use an on-flash partition table 
> > such
> >  as RedBoot.
> > +
> > +The partition table should be partitions subnode of the mtd node. 
> > Partitions are
> > +defined in subnodes of the partitions node.
> > +
> > +For backwards compatibility partitions as direct subnodes of the mtd 
> > device are
> > +supported. This use is discouraged.
> >  NOTE: if the sub-node has a compatible string, then it is not a partition.
> >  
> > -#address-cells & #size-cells must both be present in the mtd device. There 
> > are
> > -two valid values for both:
> > +#address-cells & #size-cells must both be present in the partitions 
> > subnode of the
> > +mtd device. There are two valid values for both:
> >  <1>: for partitions that require a single 32-bit cell to represent their
> >   size/address (aka the value is below 4 GiB)
> >  <2>: for partitions that require two 32-bit cells to represent their
> > @@ -28,44 +34,50 @@ Examples:
> >  
> >  
> >  flash@0 {
> > -   #address-cells = <1>;
> > -   #size-cells = <1>;
> > +   partitions {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> >  
> > -   partition@0 {
> > -   label = "u-boot";
> > -   reg = <0x000 0x10>;
> > -   read-only;
> > -   };
> > +   partition@0 {
> > +   label = "u-boot";
> > +   reg = <0x000 0x10>;
> > +   read-only;
> > +   };
> >  
> > -   uimage@10 {
> > -   reg = <0x010 0x20>;
> > +   uimage@10 {
> > +   reg = <0x010 0x20>;
> > +   };
> > };
> >  };
> >  
> >  flash@1 {
> > -   #address-cells = <1>;
> > -   #size-cells = <2>;
> > +   partitions {
> > +   #address-cells = <1>;
> > +   #size-cells = <2>;
> >  
> > -   /* a 4 GiB partition */
> > -   partition@0 {
> > -   label = "filesystem";
> > -   reg = <0x 0x1 0x>;
> > +   /* a 4 GiB partition */
> > +   partition@0 {
> > +   label = "filesystem";
> > +   reg = <0x 0x1 0x>;
> > +   };
> > };
> >  };
> >  
> >  flash@2 {
> > -   #address-cells = <2>;
> > -   #size-cells = <2>;
> > +   partitions {
> > +   #address-cells = <2>;
> > +   #size-cells = <2>;
> >  
> > -   /* an 8 GiB partition */
> > -   partition@0 {
> > -   label = "filesystem #1";
> > -   reg = <0x0 0x 0x2 0x>;
> > -   };
> > +   /* an 8 GiB partition */
> > +   partition@0 {
> > +   label = "filesystem #1";
> > +   reg = <0x0 0x 0x2 0x>;
> > +   };
> >  
> > -   /* a 4 GiB partition */
> > -   partition@2 {
> > -   label = "filesystem #2";
> > -   reg = <0x2 0x 0x1 0x>;
> > +   /* a 4 GiB partition */
> > +   partition@2 {
> > +   label = "filesystem #2";
> > +   

[PATCH] mtd: ofpart: drop undocumented, nonfunctional 'lock' property

[Brian Norris]

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.

Michal noticed that this flag was undocumented, but rather than document
a non-functioning DT property, let's just kill it, since obviously no
one cared about it.

Note that this logic does not apply to all MTD flags (e.g., the
"read-only" flags above the "lock" one), since certain flags *do* get
checked in the partition, at least in some cases (particularly, when
checking file permissions in mtdchar.c, but notably *not* in the core
APIs like mtd_write()).

Signed-off-by: Brian Norris 
Cc: Michal Suchanek 
---
 drivers/mtd/ofpart.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index aa26c32e1bc2..6bab6b5863e5 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -86,9 +86,6 @@ static int parse_ofpart_partitions(struct mtd_info *master,
if (of_get_property(pp, "read-only", &len))
(*pparts)[i].mask_flags |= MTD_WRITEABLE;
 
-   if (of_get_property(pp, "lock", &len))
-   (*pparts)[i].mask_flags |= MTD_POWERUP_LOCK;
-
i++;
}
 
-- 
2.6.0.rc2.230.g3dd15c0

--
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 4/5] mtd: ofpart: document the lock flag.

[Brian Norris]

On Sun, Oct 11, 2015 at 01:04:12PM -0700, Brian Norris wrote:
> On Tue, Aug 18, 2015 at 03:34:08PM -, Michal Suchanek wrote:
> > The lock flag of ofpart is undocumented. Add to binding doc.
> 
> Good catch. There are a lot of small corners of very old code that never
> really got reviewed properly, I expect...
> 
> (And the flag looks very odd. Why exactly is it in the partitions?)
> 
> And now that I'm looking further...does this flag even *do* anything?
> AFAICT, it doesn't set the master device flags -- only the partition
> flags. But MTD drivers currently never see the partition flags -- they
> only see the master struct mtd_info. I think the only way anyone could
> observe the effect of this flag is to read the MTD flags from sysfs. And
> that's pretty useless.
> 
> If my understanding is correct, then I'd rather completely remove the
> code that "handles" this flag, rather than codify it in the docs.

I've tested and confirmed: this only sets the flags for the partition
(*NOT* for the master device), so the only visible effect of this
property is to change sysfs flags. I'll send out a patch to kill this
property entirely.

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

Re: [PATCH v3 2/5] mtd: mtdpart: Do not fail mtd probe when parsing partitions fails.

[Brian Norris]

On Sun, Oct 11, 2015 at 01:03:47PM -0700, Brian Norris wrote:
> All in all, I think my suggestions would look something like the
> following alternative patch. I haven't tested it yet.
> 
> Brian
> 
> (git-format-patch pasted below)
> 
> From 53b60f31a2a0f2a7e8220a4aff47457248bccbcf Mon Sep 17 00:00:00 2001
> From: Brian Norris 
> Date: Sun, 11 Oct 2015 10:25:23 -0700
> Subject: [PATCH] mtd: mtdpart: Do not fail mtd probe when parsing partitions
>  fails.
> 
> Due to wrong assumption in ofpart ofpart fails on Exynos on SPI chips
> with no partitions because the subnode containing controller data
> confuses the ofpart parser.
> 
> Thus compiling in ofpart support automatically fails probing any SPI NOR
> flash without partitions on Exynos.
> 
> Compiling in a partitioning scheme should not cause probe of otherwise
> valid device to fail.
> 
> Instead, let's do the following:
>  * try parsers until one succeeds
>  * if no parser succeeds, report the first error we saw
>  * even in the failure case, allow MTD to probe, with fallback
>partitions or no partitions at all -- the master device will still be
>registered
> 
> Issue report and comments initially by Michal Suchanek.
> 
> Reported-by: Michal Suchanek 
> Signed-off-by: Brian Norris 
> ---
>  drivers/mtd/mtdcore.c |  6 --
>  drivers/mtd/mtdpart.c | 14 ++
>  2 files changed, 14 insertions(+), 6 deletions(-)

Tested, and applied this version to l2-mtd.git
--
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 0/4] Patches to fix remote wakeup on rk3288 dwc2 "host" port

[Doug Anderson]

Hi,

On Mon, Oct 26, 2015 at 4:49 PM, Doug Anderson  wrote:
> One note: the "full" PHY reset is actually not in the register map of
> the PHY.  It is amazingly enough in the CRU (clock reset unit).  So if
> we actually exposed the "full" reset through the PHY framework, the
> PHY would then turn around and pass it off to the reset framework,
> which is how the full PHY reset is exposed from the CRU.

Interestingly enough, it looks like there's a reasonable chance that
we won't be able to use the PHY port reset.  We might have to go back
to the full PHY reset (though it causes de-enumeration and
re-enumeration) for safety, since there might be some side effects of
the "phy port reset".

Probably shouldn't land this series until we can figure that out.
...but in that case we still have the question of how we should export
it.  It would certainly be easy to keep using the reset framework...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Laurent Pinchart]

Hi Geert,

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 = <&extal_clk>, <&extalr_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 
:-)

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.

> If a single device block (sharing the same register space), represented in
> DT as a single device node, actually represents multiple modules, there's no
> one-to-one mapping from SoC device to DT device node.
>
> Hence the device node will have multiple module clocks, and the driver will
> have to take care of managing them explicitly.

There can be other reasons why the clocks need to be controlled explicitly by 
the driver. At the end of the end it's a per-driver decision whether it wants 
to delegate clock management to 

Re: [PATCH v2 00/14] dmaenigne: edma/ti-crossbar: fixes, new bindings

[Vinod Koul]

On Fri, Oct 16, 2015 at 10:17:58AM +0300, Peter Ujfalusi wrote:
> Hi,
> 
> Changes since v1:
> - Comments in the memcpy optimization patch extended
> - The crossbar patch has been improved:
>  - debug prints changed
>  - fallback xbar parameters now type specific as the fallback values for DRA7
>are not valid for AM33xx crossbar.
> - New patch for Kconfig to select the crossbar in case the eDMA is used on 
> OMAP
>   platforms
> 
I am applying this series and Please note that this has ARM patches which i
have not heard any objections so applying :)

-- 
~Vinod
--
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 3/3] leds: rt5033: Add RT5033 Flash led device driver

[Ingi Kim]

Hi Jacek,

Thanks for the review
I can make this code better :)

On 2015년 10월 26일 19:10, Jacek Anaszewski wrote:
> Hi Ingi,
> 
> Thanks for the update. I've found a few minor issues, please
> refer to my comments below.
> 
> On 10/23/2015 07:48 AM, Ingi Kim wrote:
>> This patch adds device driver of Richtek RT5033 PMIC.
>> The driver supports a current regulated output to drive
>> white LEDs for camera flash.
>>
>> Signed-off-by: Ingi Kim 
>> ---
>>   drivers/leds/Kconfig   |   8 +
>>   drivers/leds/Makefile  |   1 +
>>   drivers/leds/leds-rt5033.c | 314 
>> +
>>   include/linux/mfd/rt5033-private.h |  49 ++
>>   include/linux/mfd/rt5033.h |  13 ++
>>   5 files changed, 385 insertions(+)
>>   create mode 100644 drivers/leds/leds-rt5033.c
>>
>> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
>> index 42990f2..29613e3 100644
>> --- a/drivers/leds/Kconfig
>> +++ b/drivers/leds/Kconfig
>> @@ -345,6 +345,14 @@ config LEDS_PCA963X
>> LED driver chip accessed via the I2C bus. Supported
>> devices include PCA9633 and PCA9634
>>
>> +config LEDS_RT5033
>> +tristate "LED support for RT5033 PMIC"
>> +depends on LEDS_CLASS_FLASH && OF
>> +depends on MFD_RT5033
>> +help
>> +  This option enables support for on-chip LED driver on
>> +  RT5033 PMIC.
>> +
>>   config LEDS_WM831X_STATUS
>>   tristate "LED support for status LEDs on WM831x PMICs"
>>   depends on LEDS_CLASS
>> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
>> index b503f92..bcc4d93 100644
>> --- a/drivers/leds/Makefile
>> +++ b/drivers/leds/Makefile
>> @@ -23,6 +23,7 @@ obj-$(CONFIG_LEDS_COBALT_QUBE)+= leds-cobalt-qube.o
>>   obj-$(CONFIG_LEDS_COBALT_RAQ)+= leds-cobalt-raq.o
>>   obj-$(CONFIG_LEDS_SUNFIRE)+= leds-sunfire.o
>>   obj-$(CONFIG_LEDS_PCA9532)+= leds-pca9532.o
>> +obj-$(CONFIG_LEDS_RT5033)+= leds-rt5033.o
>>   obj-$(CONFIG_LEDS_GPIO_REGISTER)+= leds-gpio-register.o
>>   obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
>>   obj-$(CONFIG_LEDS_LP3944)+= leds-lp3944.o
>> diff --git a/drivers/leds/leds-rt5033.c b/drivers/leds/leds-rt5033.c
>> new file mode 100644
>> index 000..4ba1ec6
>> --- /dev/null
>> +++ b/drivers/leds/leds-rt5033.c
>> @@ -0,0 +1,314 @@
>> +/*
>> + * led driver for RT5033
>> + *
>> + * Copyright (C) 2015 Samsung Electronics, Co., Ltd.
>> + * Ingi Kim 
>> + *
>> + * 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.
>> + *
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define RT5033_LED_FLASH_TIMEOUT_MIN64000
>> +#define RT5033_LED_FLASH_TIMEOUT_STEP32000
>> +#define RT5033_LED_FLASH_BRIGHTNESS_MIN5
>> +#define RT5033_LED_FLASH_BRIGHTNESS_STEP25000
>> +#define RT5033_LED_TORCH_BRIGHTNESS_MIN12500
>> +#define RT5033_LED_TORCH_BRIGHTNESS_STEP12500
>> +
>> +/* Macro to get offset of rt5033_led_config_data */
>> +#define RT5033_LED_CONFIG_DATA_OFFSET(val, step, min)(((val) - (min)) \
>> +/ (step))
>> +
>> +struct rt5033_led_config_data {
>> +u32 flash_max_microamp;
>> +u32 flash_max_timeout;
>> +u32 torch_max_microamp;
>> +};
>> +
>> +static struct rt5033_led *flcdev_to_led(
>> +struct led_classdev_flash *fled_cdev)
>> +{
>> +return container_of(fled_cdev, struct rt5033_led, fled_cdev);
>> +}
>> +
>> +static void rt5033_brightness_set(struct rt5033_led *led,
>> +  enum led_brightness brightness)
>> +{
>> +mutex_lock(&led->lock);
>> +
>> +if (!brightness) {
>> +regmap_update_bits(led->regmap, RT5033_REG_FLED_FUNCTION2,
>> +   RT5033_FLED_FUNC2_MASK, 0x0);
>> +} else {
>> +regmap_update_bits(led->regmap, RT5033_REG_FLED_FUNCTION1,
>> +   RT5033_FLED_FUNC1_MASK, RT5033_FLED_PINCTRL);
>> +regmap_update_bits(led->regmap,RT5033_REG_FLED_CTRL1,
>> +   RT5033_FLED_CTRL1_MASK,
>> +   (brightness - 1) << 4);
>> +regmap_update_bits(led->regmap, RT5033_REG_FLED_FUNCTION2,
>> +   RT5033_FLED_FUNC2_MASK, RT5033_FLED_ENFLED);
>> +}
>> +
>> +mutex_unlock(&led->lock);
>> +}
>> +
>> +static void rt5033_brightness_set_work(struct work_struct *work)
>> +{
>> +struct rt5033_led *led =
>> +container_of(work, struct rt5033_led, work_brightness_set);
>> +
>> +rt5033_brightness_set(led, led->torch_brightness);
>> +}
>> +
>> +static void rt5033_led_brightness_set(struct led_classdev *led_cdev,
>> +  enum led_brightness brightness)
>> +{
>> +struct led_classdev_flash *fled_cdev = lcdev_to_flcdev(led_cdev);
>> +struct rt5033_led *led = flcdev_to_led(fled_cdev);
>> +
>

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

[Mark Brown]

On Mon, Oct 26, 2015 at 10:13:55AM +0100, Heiko Schocher wrote:
> remove tps65217.dtsi and adapt all boards, which
> used it.

Acked-by: Mark Brown 

but really this is a DTS change so I'd expect it to go via arm-soc
rather than me.


signature.asc
Description: PGP signature

Re: [PATCH v2] ARM: dts: am335x-boneblack: Use pinctrl constants and AM33XX_IOPAD macro

[Javier Martinez Canillas]

Hello Andrew,

On Sun, Oct 25, 2015 at 2:05 AM, Andrew F. Davis  wrote:
> Using constants for pinctrl allows better readability and removes
> redundancy with comments. AM33XX_IOPAD allows us to use part of the
> pinctrl physical address as in the TRM instead of an offset.
>
> Signed-off-by: Andrew F. Davis 
> ---

I haven't verified the values against the TRM, but assuming there are correct:

Reviewed-by: Javier Martinez Canillas 

Best regards,
Javier
--
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/3] ARM: uniphier: add outer cache support and rework SMP operations

[Olof Johansson]

On Mon, Oct 26, 2015 at 01:16:50PM +0900, Masahiro Yamada wrote:
> Hi Arnd,
> 
> 
> 2015-10-10 15:59 GMT+09:00 Masahiro Yamada :
> > Hi Arnd,
> >
> >
> > 2015-10-06 15:22 GMT+01:00 Arnd Bergmann :
> >> On Tuesday 06 October 2015 16:20:23 Arnd Bergmann wrote:
> >>> On Friday 18 September 2015 13:37:31 Masahiro Yamada wrote:
> >>> > Hi Olof,
> >>> >
> >>> > Now Linux 4.3-rc1 is out, so I am back to this.
> >>> >
> >>> > 1/3: add outer cache support
> >>> > 2/3: rework SMP operations
> >>> > 3/3: add device tree nodes
> >>> >
> >>> > Because 2/3 highly depends on 1/3, I hope whole of this series
> >>> > is applied through ARM-SOC tree.
> >>>
> >>> Sorry for the long delay here. Is this the latest version of these
> >>> patches?
> >>>
> >>> Did Russell King review the first patch?
> >>> Is he ok with merging this through arm-soc?
> >>>
> >>
> >> I found an answer to the first question, as I see you posted
> >> v5 of the patchset in the meantime.
> >
> >
> > Yes, v5 is my latest version.
> >
> >
> > For the second question, Russell gave me some comments on the 1/3
> > and I answered.
> >
> > He mentioned nothing about merging the whole series thru arm-soc.
> > (At least, he was not opposed to it, I guess)
> >
> 
> Is it difficult to apply this series for the next merge window?
> V5 is the latest.
> No comment, but not applied.
> 
> Is there anything I can do but wait?

Looks like this one has fallen between the cracks, so sorry about that.

I checked in with Russell, and we'll pick this up for now even if it might
need some minor fixups down the road -- it seems good enough to go in.

Applied v5 of all 3 patches, first two to next/soc, last to next/dt.


Thanks, and apologies for the delay,

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

Re: [PATCH v4 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC

[Mark Brown]

On Mon, Oct 26, 2015 at 10:47:41AM -0500, Andrew F. Davis wrote:
> On 10/25/2015 07:43 PM, Mark Brown wrote:

> >>.of_compatible = "mediatek,mt6397-regulator",

> >This is in the MFD, this is not used in actual systems.

> Not sure what you mean by "actual systems", it looks like these
> use it?:

> arch/arm/boot/dts/mt8135-evbp1.dts
> arch/arm64/boot/dts/mediatek/mt8173-evb.dts

To repeat: the regulator driver does not register a compatible string
for the device for device model probing.

> I understand this, I thought we are talking about compatible strings in
> the regulator sub-node, not how the core instantiates the sub-driver.

No, this exactly about how the device model devices are instantiated.


signature.asc
Description: PGP signature

Re: [PATCH 0/4] Patches to fix remote wakeup on rk3288 dwc2 "host" port

[Doug Anderson]

Rob,

On Mon, Oct 26, 2015 at 4:05 PM, Rob Herring  wrote:
>>> A DT reset controller seems like a bit of an overkill here. I think this
>>> would be much more simple if we just add a phy reset hook to the phy
>>> subsystem.
>>
>> Adding a reset hook in the PHY subsystem does seem like a reasonable
>> idea to me.  I was considering it in an earlier version of this series
>> that actually used a reset of the PHY to the fix the stuck dwc2.
>>
>> ...but I think that even if the phy subsystem had a reset hook it
>> wouldn't be the ideal solution here.  When we assert the PHY "port
>> reset" we're not actually fully resetting the PHY.  We're instead
>> doing some sort of a more minor "state machine" reset in the PHY.
>> This appears better (in my case) than resetting the whole PHY because
>> it doesn't force a de-enumeration / re-enumeration.  Exposing this
>> more minor reset as a PHY reset seems wrong to me.  ...and it also
>> precludes us later also exposing the more full reset through the PHY
>> framework if that later becomes useful.
>
> Doesn't creating a binding also have similar possibility? Maybe an
> "attach host" or re-init hook would be more appropriate. I'm sure
> there are other such cases where the host and phy need more tight
> coupling. I recently had a similar case where there was an interleaved
> sequence of phy and host register writes. I managed rework things and
> avoid changing the phy interface, but there will certainly be cases
> where we can't.
>
> Changing function names in the kernel is easy. Changing the binding
> later not so much. Also as we're looking toward dependency handling,
> this creates a circular dependency. We'll probably have to deal with
> those anyway, but here it seems a bit pointless. We already have a
> connection between the host and phy defined. Let's use that and not
> define another.

I'm probably not understanding what you're proposing.  I was imagining
that you were proposing adding into "include/linux/phy/phy.h" a
definition like:

  int phy_reset(struct phy *phy);

If that existed in the PHY interface, it wouldn't be enough for me
since the "reset" that I'm doing isn't a full reset (and there does
exist another, fuller PHY reset on this SoC).  So if we wanted to use
the PHY interface, I'd need either:

  int phy_reset(struct phy *phy, int reset_id);
...or...
  int phy_reset(struct phy *phy, const char *reset_id);

I was expecting that to stay generic you'd somehow need to add a
mapping of these resets into the device tree because a given USB
controller may have different PHYs on different boards and the same
PHY might be used with more than one USB controller.  If you don't add
some type of mapping in the device tree then in _some_ type of include
file you'd need something like:

#define DWC2_RESET_ID_PHY_PORT_RESET  1
#define DWC2_RESET_ID_PHY_FULL_RESET  2
...or...
#define DWC2_RESET_ID_PHY_PORT_RESET  "phy_port_reset"
#define DWC2_RESET_ID_PHY_FULL_RESET  "phy_full_reset"

...presumably you'd expect that to be in a dwc2 header file, to be
included by the "rk3288 USB PHY"?  ...but, oddly enough, the "rk3288
USB PHY" is not specific to dwc2, so having it include a dwc2 header
file is pretty odd.  Specifically on rk3288 there are 3 instances of
the same PHY.  One is hooked up to the dwc2 "OTG" port.  One is hooked
up to the dwc2 "host" port (which doesn't have device functionality
and also has the need for this strange reset quirk).  One is hooked up
to an EHCI port (using the generic EHCI driver).

...so, while I could add a dwc2 specific include into the rk3288 PHY
driver, I'd need to somehow figure out which of the PHYs it applied
to.  For instance, maybe we later find that we need to activate this
reset for the EHCI port.  Now we'll need to include both headers.
...and hopefully there aren't name / number conflicts.

One note: the "full" PHY reset is actually not in the register map of
the PHY.  It is amazingly enough in the CRU (clock reset unit).  So if
we actually exposed the "full" reset through the PHY framework, the
PHY would then turn around and pass it off to the reset framework,
which is how the full PHY reset is exposed from the CRU.


>> ...we could, of course, re-invent the reset framework (with string or
>> integral IDs so we can assert different types of resets) within the
>> PHY framework.  That doesn't seem ideal to me, but if that's what
>> others want to do then I guess it would be OK...
>
> I think that should already be possible as you can have multiple
> cells. Of course, you have to plan for that with your cell values.

I didn't understand this comment.


Basically: to summarize, I think that we have a reset framework that
handles this beautifully and gets all the corner cases down.  Adding a
second link to the PHY seems totally reasonable to me because I could
totally imagine that this reset could be implemented in a totally
different place in some SoCs.  It happens to be in the PHY in my
particular case, but it need not be on all 

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Mon, Oct 26, 2015 at 11:51 AM, Michael Turquette
 wrote:
> Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
>> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown  wrote:
>> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
>> >
>> >> Well, I'm not quite sure why exactly everyone is so focused on probing 
>> >> here.
>> >
>> > Probe deferral is really noisy even if it's working fine on a given
>> > system so it's constantly being highlighted to people in a way that
>> > other issues aren't if you're not directly having problems.
>> >
>> > There's also the understanding people had that the order things get
>> > bound changes the ordering for some of the other cases (perhaps it's a
>> > good idea to do that, it seems likely to be sensible?).
>>
>> But it really doesn't do that.  Also making it do so doesn't help much
>> in the cases where things can happen asynchronously (system
>> suspend/resume, runtime PM).
>>
>> If, instead, there was a way to specify a functional dependency at the
>> device registration time, it might be used to change the order of
>> everything relevant, including probe.  That should help to reduce the
>> noise you're referring to.
>
> Taking it a step further, if functional dependencies were understood at
> link-time then we could optimize link order as well. There are probably
> lots of optimizations if we only made the effort to understand these
> dependencies earlier.

Do you mean the kernel link time or something else?

At least in some cases the dependency information won't be known at
that time, so we need a way to record a dependency at the time it
becomes visible to us anyway.

> Constructing the device/resource dependency graph before the device ever
> boots sounds interesting to me.

That's only practical if you build the kernel for a specific device.
If you want a generic binary that can work with multiple different
devices, that graph may very well be different for each of them.

Thanks,
Rafael
--
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

[Dmitry Torokhov]

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.

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 v4] Tegra: DT: add device tree binding doc for QSPI

[Rob Herring]

On Mon, Oct 26, 2015 at 5:22 PM, Tom Warren  wrote:
> This patch adds the device tree binding doc for the Tegra
> QSPI controller on Tegra210.
>
> Signed-off-by: Tom Warren 

Acked-by: Rob Herring 

> ---
> Changes in v2:
> - based it more on kernel's nvidia,tegra114-spi.txt binding
> - changes based on prelim review by swar...@nvidia.com
> Changes in v3:
> - renamed to 'nvidia,tegra210-qspi.txt' to match kernel bindings
> - more changes based on review from swar...@nvidia.com
> Changes in v4:
> - move 'clock' up under 'clock-names' entry
>
>  Documentation/devicetree/bindings/spi/nvidia,tegra210-qspi.txt | 42 
> ++
>  1 file changed, 42 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/spi/nvidia,tegra210-qspi.txt
>
> diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra210-qspi.txt 
> b/Documentation/devicetree/bindings/spi/nvidia,tegra210-qspi.txt
> new file mode 100644
> index 000..fe1558f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/nvidia,tegra210-qspi.txt
> @@ -0,0 +1,42 @@
> +NVIDIA Tegra QSPI controller.
> +
> +Required properties:
> +- compatible : for Tegra210, must contain "nvidia,tegra210-qspi".
> +- reg: Should contain QSPI registers location and length.
> +- interrupts: Should contain QSPI interrupt.
> +- clock-names : Must include the following entries:
> +  - qspi
> +- clocks : Must contain an entry for each entry in clock-names.
> +  See ../clocks/clock-bindings.txt for details.
> +- resets : Must contain an entry for each entry in reset-names.
> +  See ../reset/reset.txt for details.
> +- reset-names : Must include the following entries:
> +  - qspi
> +
> +Optional properties:
> +- dmas : Must contain an entry for each entry in clock-names.
> +  See ../dma/dma.txt for details.
> +- dma-names : Must include the following entries:
> +  - rx
> +  - tx
> +
> +Recommended properties:
> +- spi-max-frequency: Definition as per spi-bus.txt
> +
> +Example:
> +
> +spi@7041 {
> +   compatible = "nvidia,tegra210-qspi";
> +   reg = <0x0 0x7041 0x0 0x1000>;
> +   interrupts = <0 10 0x04>;
> +   spi-max-frequency = <2400>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   clocks = <&tegra_car 211>;
> +   clock-names = "qspi";
> +   resets = <&tegra_car 211>;
> +   reset-names = "qspi";
> +   dmas = <&apbdma 16>, <&apbdma 16>;
> +   dma-names = "rx", "tx";
> +   status = "disabled";
> +};
> --
> 1.8.2.1.610.g562af5b
>
--
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/10] pwm: core: add pulse feature to the PWM framework

[kbuild test robot]

Hi Olliver,

[auto build test WARNING on pwm/for-next -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Olliver-Schinagl/pwm-lpc18xx_pwm-use-pwm_set_chip_data/20151027-053853
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/clk/clk-pwm.c:89:25: sparse: not enough arguments for function 
>> pwm_config
   drivers/clk/clk-pwm.c: In function 'clk_pwm_probe':
   drivers/clk/clk-pwm.c:89:8: error: too few arguments to function 'pwm_config'
 ret = pwm_config(pwm, (pwm->period + 1) >> 1, pwm->period);
   ^
   In file included from drivers/clk/clk-pwm.c:15:0:
   include/linux/pwm.h:25:5: note: declared here
int pwm_config(struct pwm_device *pwm, int duty_ns,
^
--
>> drivers/gpu/drm/i915/intel_panel.c:652:19: sparse: not enough arguments for 
>> function pwm_config
   drivers/gpu/drm/i915/intel_panel.c:797:19: sparse: not enough arguments for 
function pwm_config
   drivers/gpu/drm/i915/intel_panel.c:1442:28: sparse: not enough arguments for 
function pwm_config
   drivers/gpu/drm/i915/intel_panel.c: In function 'pwm_set_backlight':
   drivers/gpu/drm/i915/intel_panel.c:652:2: error: too few arguments to 
function 'pwm_config'
 pwm_config(panel->backlight.pwm, duty_ns, CRC_PMIC_PWM_PERIOD_NS);
 ^
   In file included from drivers/gpu/drm/i915/intel_panel.c:35:0:
   include/linux/pwm.h:25:5: note: declared here
int pwm_config(struct pwm_device *pwm, int duty_ns,
^
   drivers/gpu/drm/i915/intel_panel.c: In function 'pwm_disable_backlight':
   drivers/gpu/drm/i915/intel_panel.c:797:2: error: too few arguments to 
function 'pwm_config'
 pwm_config(panel->backlight.pwm, 0, CRC_PMIC_PWM_PERIOD_NS);
 ^
   In file included from drivers/gpu/drm/i915/intel_panel.c:35:0:
   include/linux/pwm.h:25:5: note: declared here
int pwm_config(struct pwm_device *pwm, int duty_ns,
^
   drivers/gpu/drm/i915/intel_panel.c: In function 'pwm_setup_backlight':
   drivers/gpu/drm/i915/intel_panel.c:1442:11: error: too few arguments to 
function 'pwm_config'
 retval = pwm_config(panel->backlight.pwm, CRC_PMIC_PWM_PERIOD_NS,
  ^
   In file included from drivers/gpu/drm/i915/intel_panel.c:35:0:
   include/linux/pwm.h:25:5: note: declared here
int pwm_config(struct pwm_device *pwm, int duty_ns,
^
--
>> drivers/hwmon/pwm-fan.c:51:25: sparse: not enough arguments for function 
>> pwm_config
   drivers/hwmon/pwm-fan.c:240:25: sparse: not enough arguments for function 
pwm_config
   drivers/hwmon/pwm-fan.c:313:25: sparse: not enough arguments for function 
pwm_config
   drivers/hwmon/pwm-fan.c: In function '__set_pwm':
   drivers/hwmon/pwm-fan.c:51:8: error: too few arguments to function 
'pwm_config'
 ret = pwm_config(ctx->pwm, duty, ctx->pwm->period);
   ^
   In file included from drivers/hwmon/pwm-fan.c:25:0:
   include/linux/pwm.h:25:5: note: declared here
int pwm_config(struct pwm_device *pwm, int duty_ns,
^
   drivers/hwmon/pwm-fan.c: In function 'pwm_fan_probe':
   drivers/hwmon/pwm-fan.c:240:8: error: too few arguments to function 
'pwm_config'
 ret = pwm_config(ctx->pwm, duty_cycle, ctx->pwm->period);
   ^
   In file included from drivers/hwmon/pwm-fan.c:25:0:
   include/linux/pwm.h:25:5: note: declared here
int pwm_config(struct pwm_device *pwm, int duty_ns,
^
   drivers/hwmon/pwm-fan.c: In function 'pwm_fan_resume':
   drivers/hwmon/pwm-fan.c:313:8: error: too few arguments to function 
'pwm_config'
 ret = pwm_config(ctx->pwm, duty, ctx->pwm->period);
   ^
   In file included from drivers/hwmon/pwm-fan.c:25:0:
   include/linux/pwm.h:25:5: note: declared here
int pwm_config(struct pwm_device *pwm, int duty_ns,
^
--
>> drivers/input/misc/pwm-beeper.c:56:33: sparse: not enough arguments for 
>> function pwm_config
   drivers/input/misc/pwm-beeper.c:161:27: sparse: not enough arguments for 
function pwm_config
   drivers/input/misc/pwm-beeper.c: In function 'pwm_beeper_event':
   drivers/input/misc/pwm-beeper.c:56:9: error: too few arguments to function 
'pwm_config'
  ret = pwm_config(beeper->pwm, period / 2, period);
^
   In file included from drivers/input/misc/pwm-beeper.c:21:0:
   include/linux/pwm.h:25:5: note: declared here
int pwm_config(struct pwm_device *pwm, int duty_ns,
^
   drivers/input/misc/pwm-beeper.c: In function 'pwm_beeper_resume':
   drivers/input/misc/pwm-beeper.c:161:3: error: too few arguments to function 
'pwm_config'
  pwm_config(beeper->pwm, beeper->period / 2, beeper->period);
  ^
   In file included from drivers/input/misc/pwm-beeper.c:21:0:
   include/linux/pwm.h:25:5: note: declared here
int pwm_config(struct pwm_device *pwm, int duty_ns,
^
--
>> drivers/leds/leds-pwm.c:46:19: sparse: not e

Re: [PATCH 0/4] Patches to fix remote wakeup on rk3288 dwc2 "host" port

[Rob Herring]

On Sat, Oct 24, 2015 at 4:22 PM, Doug Anderson  wrote:
> Rob,
>
> On Sat, Oct 24, 2015 at 11:10 AM, Rob Herring  wrote:
>> On 10/23/2015 01:28 PM, Douglas Anderson wrote:
>>> The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
>>> has a hardware errata that causes everything to get confused when we get
>>> a remote wakeup.  It appears that the "port reset" bit that's in the USB
>>> phy (located in the rk3288 GRF) fixes things up and appears safe to do.
>>>
>>> This series of patches exports the "port reset" from the PHY and then
>>> hooks it up to dwc2 through a quirk.
>>>
>>> I've tested this series atop a bit of a conglomeration of Heiko's github
>>> "somewhat stable" branch (v4.3-rc3-876-g6509232) but with Greg KH's
>>> usb-next merged in.
>>>
>>> These patches currently conflict with patches that I posted previously
>>> to enable USB wakeup from S3, specifically:
>>> * https://patchwork.kernel.org/patch/6727081/
>>> * https://patchwork.kernel.org/patch/6727121/
>>> ...those patches no longer apply anyway, so presumably they need to be
>>> reposted and I can do so later atop these patches.
>>>
>>>
>>> Douglas Anderson (4):
>>>   phy: rockchip-usb: Support the PHY's "port reset"
>>>   usb: dwc2: optionally assert phy "port reset" when waking up
>>>   ARM: dts: rockchip: Enable the USB phys as reset providers on rk3288
>>>   ARM: dts: rockchip: Point rk3288 dwc2 usb at phy port reset
>>>
>>>  .../devicetree/bindings/phy/rockchip-usb-phy.txt   |  6 ++
>>>  Documentation/devicetree/bindings/usb/dwc2.txt |  7 ++
>>>  arch/arm/boot/dts/rk3288.dtsi  |  8 +++
>>>  drivers/phy/phy-rockchip-usb.c | 74 
>>> ++
>>>  drivers/usb/dwc2/core.h|  5 ++
>>>  drivers/usb/dwc2/core_intr.c   |  7 ++
>>>  drivers/usb/dwc2/platform.c| 13 
>>>  7 files changed, 120 insertions(+)
>>
>> A DT reset controller seems like a bit of an overkill here. I think this
>> would be much more simple if we just add a phy reset hook to the phy
>> subsystem.
>
> Adding a reset hook in the PHY subsystem does seem like a reasonable
> idea to me.  I was considering it in an earlier version of this series
> that actually used a reset of the PHY to the fix the stuck dwc2.
>
> ...but I think that even if the phy subsystem had a reset hook it
> wouldn't be the ideal solution here.  When we assert the PHY "port
> reset" we're not actually fully resetting the PHY.  We're instead
> doing some sort of a more minor "state machine" reset in the PHY.
> This appears better (in my case) than resetting the whole PHY because
> it doesn't force a de-enumeration / re-enumeration.  Exposing this
> more minor reset as a PHY reset seems wrong to me.  ...and it also
> precludes us later also exposing the more full reset through the PHY
> framework if that later becomes useful.

Doesn't creating a binding also have similar possibility? Maybe an
"attach host" or re-init hook would be more appropriate. I'm sure
there are other such cases where the host and phy need more tight
coupling. I recently had a similar case where there was an interleaved
sequence of phy and host register writes. I managed rework things and
avoid changing the phy interface, but there will certainly be cases
where we can't.

Changing function names in the kernel is easy. Changing the binding
later not so much. Also as we're looking toward dependency handling,
this creates a circular dependency. We'll probably have to deal with
those anyway, but here it seems a bit pointless. We already have a
connection between the host and phy defined. Let's use that and not
define another.

> ...we could, of course, re-invent the reset framework (with string or
> integral IDs so we can assert different types of resets) within the
> PHY framework.  That doesn't seem ideal to me, but if that's what
> others want to do then I guess it would be OK...

I think that should already be possible as you can have multiple
cells. Of course, you have to plan for that with your cell values.

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 v4] Tegra: DT: add device tree binding doc for QSPI

[Stephen Warren]

On 10/26/2015 04:22 PM, Tom Warren wrote:

This patch adds the device tree binding doc for the Tegra
QSPI controller on Tegra210.


Acked-by: Stephen Warren 

(I assume if others approve the binding, Thierry will take it through 
the Tegra tree)

--
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 net-next v2 2/2] Documentation: dts: xgene: Add TX/RX delay field

[Iyappan Subramanian]

Signed-off-by: Iyappan Subramanian 
---
 Documentation/devicetree/bindings/net/apm-xgene-enet.txt | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/apm-xgene-enet.txt 
b/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
index f55aa28..078060a 100644
--- a/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
+++ b/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
@@ -37,6 +37,14 @@ Required properties for ethernet interfaces that have 
external PHY:
 
 Optional properties:
 - status: Should be "ok" or "disabled" for enabled/disabled. Default is "ok".
+- tx-delay: Delay value for RGMII bridge TX clock.
+   Valid values are between 0 to 7, that maps to
+   417, 717, 1020, 1321, 1611, 1913, 2215, 2514 ps
+   Default value is 4, which corresponds to 1611 ps
+- rx-delay: Delay value for RGMII bridge RX clock.
+   Valid values are between 0 to 7, that maps to
+   273, 589, 899, 1222, 1480, 1806, 2147, 2464 ps
+   Default value is 2, which corresponds to 899 ps
 
 Example:
menetclk: menetclk {
@@ -72,5 +80,7 @@ Example:
 
 /* Board-specific peripheral configurations */
 &menet {
+   tx-delay = <4>;
+   rx-delay = <2>;
 status = "ok";
 };
-- 
1.9.1

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

[PATCH net-next v2 0/2] drivers: xgene: Add support RGMII TX/RX delay configuration

[Iyappan Subramanian]

X-Gene RGMII ethernet controller has a RGMII bridge that performs the
task of converting the RGMII signal {RX_CLK,RX_CTL, RX_DATA[3:0]} from
PHY to GMII signal {RX_DV,RX_ER,RX_DATA[7:0]} and vice versa.  This
RGMII bridge has a provision to internally delay the input RX_CLK and
the output TX_CLK using configuration registers. This will help in
maintain the CLK-CTL delay relationship in various operating
conditions.

This patch adds support RGMII TX/RX delay configuration.

Signed-off-by: Iyappan Subramanian 
---

Iyappan Subramanian (2):
  drivers: net: xgene: Add support RGMII TX/RX delay configuration
  Documentation: dts: xgene: Add TX/RX delay field

 .../devicetree/bindings/net/apm-xgene-enet.txt | 10 +
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c |  8 +++-
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.h |  1 +
 drivers/net/ethernet/apm/xgene/xgene_enet_main.c   | 49 ++
 drivers/net/ethernet/apm/xgene/xgene_enet_main.h   |  2 +
 5 files changed, 69 insertions(+), 1 deletion(-)

-- 
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 net-next v2 1/2] drivers: net: xgene: Add support RGMII TX/RX delay configuration

[Iyappan Subramanian]

Add RGMII TX/RX delay configuration support. RGMII standard requires 2ns
delay to help the RGMII bridge receiver to sample data correctly. If the
default value does not provide proper centering of the data sample, the
TX/RX delay parameters can be used to adjust accordingly.

Signed-off-by: Iyappan Subramanian 
---
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c   |  8 +++-
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.h   |  1 +
 drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 49 
 drivers/net/ethernet/apm/xgene/xgene_enet_main.h |  2 +
 4 files changed, 59 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c 
b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
index 652f218..33850a0 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -461,6 +461,7 @@ static void xgene_gmac_reset(struct xgene_enet_pdata *pdata)
 
 static void xgene_gmac_init(struct xgene_enet_pdata *pdata)
 {
+   struct device *dev = &pdata->pdev->dev;
u32 value, mc2;
u32 intf_ctl, rgmii;
u32 icm0, icm2;
@@ -490,7 +491,12 @@ static void xgene_gmac_init(struct xgene_enet_pdata *pdata)
default:
ENET_INTERFACE_MODE2_SET(&mc2, 2);
intf_ctl |= ENET_GHD_MODE;
-   CFG_TXCLK_MUXSEL0_SET(&rgmii, 4);
+
+   if (dev->of_node) {
+   CFG_TXCLK_MUXSEL0_SET(&rgmii, pdata->tx_delay);
+   CFG_RXCLK_MUXSEL0_SET(&rgmii, pdata->rx_delay);
+   }
+
xgene_enet_rd_csr(pdata, DEBUG_REG_ADDR, &value);
value |= CFG_BYPASS_UNISEC_TX | CFG_BYPASS_UNISEC_RX;
xgene_enet_wr_csr(pdata, DEBUG_REG_ADDR, value);
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h 
b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
index ff05bbc..6dee73c 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
@@ -144,6 +144,7 @@ enum xgene_enet_rm {
 #define CFG_BYPASS_UNISEC_RX   BIT(1)
 #define CFG_CLE_BYPASS_EN0 BIT(31)
 #define CFG_TXCLK_MUXSEL0_SET(dst, val)xgene_set_bits(dst, val, 29, 3)
+#define CFG_RXCLK_MUXSEL0_SET(dst, val)xgene_set_bits(dst, val, 26, 3)
 
 #define CFG_CLE_IP_PROTOCOL0_SET(dst, val) xgene_set_bits(dst, val, 16, 2)
 #define CFG_CLE_DSTQID0_SET(dst, val)  xgene_set_bits(dst, val, 0, 12)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c 
b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index 6b1846d..ce10687 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -1118,6 +1118,47 @@ static int xgene_get_port_id_dt(struct device *dev, 
struct xgene_enet_pdata *pda
return ret;
 }
 
+static int xgene_get_tx_delay(struct xgene_enet_pdata *pdata)
+{
+   struct device *dev = &pdata->pdev->dev;
+   int delay, ret;
+
+   ret = of_property_read_u32(dev->of_node, "tx-delay", &delay);
+   if (ret) {
+   pdata->tx_delay = 4;
+   return 0;
+   }
+
+   if (delay < 0 || delay > 7) {
+   dev_err(dev, "Invalid tx-delay specified\n");
+   return -EINVAL;
+   }
+
+   pdata->tx_delay = delay;
+
+   return 0;
+}
+
+static int xgene_get_rx_delay(struct xgene_enet_pdata *pdata)
+{
+   struct device *dev = &pdata->pdev->dev;
+   int delay, ret;
+
+   ret = of_property_read_u32(dev->of_node, "rx-delay", &delay);
+   if (ret) {
+   pdata->rx_delay = 2;
+   return 0;
+   }
+
+   if (delay < 0 || delay > 7) {
+   dev_err(dev, "Invalid rx-delay specified\n");
+   return -EINVAL;
+   }
+
+   pdata->rx_delay = delay;
+
+   return 0;
+}
 
 static int xgene_enet_get_resources(struct xgene_enet_pdata *pdata)
 {
@@ -1194,6 +1235,14 @@ static int xgene_enet_get_resources(struct 
xgene_enet_pdata *pdata)
return -ENODEV;
}
 
+   ret = xgene_get_tx_delay(pdata);
+   if (ret)
+   return ret;
+
+   ret = xgene_get_rx_delay(pdata);
+   if (ret)
+   return ret;
+
ret = platform_get_irq(pdev, 0);
if (ret <= 0) {
dev_err(dev, "Unable to get ENET Rx IRQ\n");
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h 
b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
index ff89a5d..a6e56b8 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
@@ -184,6 +184,8 @@ struct xgene_enet_pdata {
u8 bp_bufnum;
u16 ring_num;
u32 mss;
+   u8 tx_delay;
+   u8 rx_delay;
 };
 
 struct xgene_indirect_ctl {
-- 
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

[PATCH v4] Tegra: DT: add device tree binding doc for QSPI

[Tom Warren]

This patch adds the device tree binding doc for the Tegra
QSPI controller on Tegra210.

Signed-off-by: Tom Warren 
---
Changes in v2:
- based it more on kernel's nvidia,tegra114-spi.txt binding
- changes based on prelim review by swar...@nvidia.com
Changes in v3:
- renamed to 'nvidia,tegra210-qspi.txt' to match kernel bindings
- more changes based on review from swar...@nvidia.com
Changes in v4:
- move 'clock' up under 'clock-names' entry

 Documentation/devicetree/bindings/spi/nvidia,tegra210-qspi.txt | 42 
++
 1 file changed, 42 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/spi/nvidia,tegra210-qspi.txt

diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra210-qspi.txt 
b/Documentation/devicetree/bindings/spi/nvidia,tegra210-qspi.txt
new file mode 100644
index 000..fe1558f
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra210-qspi.txt
@@ -0,0 +1,42 @@
+NVIDIA Tegra QSPI controller.
+
+Required properties:
+- compatible : for Tegra210, must contain "nvidia,tegra210-qspi".
+- reg: Should contain QSPI registers location and length.
+- interrupts: Should contain QSPI interrupt.
+- clock-names : Must include the following entries:
+  - qspi
+- clocks : Must contain an entry for each entry in clock-names.
+  See ../clocks/clock-bindings.txt for details.
+- resets : Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+  - qspi
+
+Optional properties:
+- dmas : Must contain an entry for each entry in clock-names.
+  See ../dma/dma.txt for details.
+- dma-names : Must include the following entries:
+  - rx
+  - tx
+
+Recommended properties:
+- spi-max-frequency: Definition as per spi-bus.txt
+
+Example:
+
+spi@7041 {
+   compatible = "nvidia,tegra210-qspi";
+   reg = <0x0 0x7041 0x0 0x1000>;
+   interrupts = <0 10 0x04>;
+   spi-max-frequency = <2400>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = <&tegra_car 211>;
+   clock-names = "qspi";
+   resets = <&tegra_car 211>;
+   reset-names = "qspi";
+   dmas = <&apbdma 16>, <&apbdma 16>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+};
-- 
1.8.2.1.610.g562af5b

--
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/10] pwm: core: add pulse feature to the PWM framework

[kbuild test robot]

Hi Olliver,

[auto build test WARNING on pwm/for-next -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Olliver-Schinagl/pwm-lpc18xx_pwm-use-pwm_set_chip_data/20151027-053853
config: arm-at91_dt_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All warnings (new ones prefixed by >>):

>> drivers/pwm/pwm-atmel-tcb.c:359:2: warning: initialization from incompatible 
>> pointer type
 .config = atmel_tcb_pwm_config,
 ^
   drivers/pwm/pwm-atmel-tcb.c:359:2: warning: (near initialization for 
'atmel_tcb_pwm_ops.config')

vim +359 drivers/pwm/pwm-atmel-tcb.c

9421bade Boris BREZILLON 2013-01-08  343}
9421bade Boris BREZILLON 2013-01-08  344  
9421bade Boris BREZILLON 2013-01-08  345tcbpwm->period = period;
9421bade Boris BREZILLON 2013-01-08  346tcbpwm->div = i;
9421bade Boris BREZILLON 2013-01-08  347tcbpwm->duty = duty;
9421bade Boris BREZILLON 2013-01-08  348  
9421bade Boris BREZILLON 2013-01-08  349/* If the PWM is enabled, call 
enable to apply the new conf */
5c31252c Boris Brezillon 2015-07-01  350if (pwm_is_enabled(pwm))
9421bade Boris BREZILLON 2013-01-08  351
atmel_tcb_pwm_enable(chip, pwm);
9421bade Boris BREZILLON 2013-01-08  352  
9421bade Boris BREZILLON 2013-01-08  353return 0;
9421bade Boris BREZILLON 2013-01-08  354  }
9421bade Boris BREZILLON 2013-01-08  355  
9421bade Boris BREZILLON 2013-01-08  356  static const struct pwm_ops 
atmel_tcb_pwm_ops = {
9421bade Boris BREZILLON 2013-01-08  357.request = 
atmel_tcb_pwm_request,
9421bade Boris BREZILLON 2013-01-08  358.free = atmel_tcb_pwm_free,
9421bade Boris BREZILLON 2013-01-08 @359.config = atmel_tcb_pwm_config,
9421bade Boris BREZILLON 2013-01-08  360.set_polarity = 
atmel_tcb_pwm_set_polarity,
9421bade Boris BREZILLON 2013-01-08  361.enable = atmel_tcb_pwm_enable,
9421bade Boris BREZILLON 2013-01-08  362.disable = 
atmel_tcb_pwm_disable,
83c80dc5 Axel Lin2013-03-31  363.owner = THIS_MODULE,
9421bade Boris BREZILLON 2013-01-08  364  };
9421bade Boris BREZILLON 2013-01-08  365  
9421bade Boris BREZILLON 2013-01-08  366  static int atmel_tcb_pwm_probe(struct 
platform_device *pdev)
9421bade Boris BREZILLON 2013-01-08  367  {

:: The code at line 359 was first introduced by commit
:: 9421bade0765d8ffb86b8a99213b611278a3542a pwm: atmel: add Timer Counter 
Block PWM driver

:: TO: Boris BREZILLON 
:: CC: Thierry Reding 

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


.config.gz
Description: Binary data

Re: [PATCH 08/10] pwm: core: add pulse feature to the PWM framework

[kbuild test robot]

Hi Olliver,

[auto build test ERROR on pwm/for-next -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Olliver-Schinagl/pwm-lpc18xx_pwm-use-pwm_set_chip_data/20151027-053853
config: i386-randconfig-s1-201543 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/input/misc/max77693-haptic.c: In function 
'max77693_haptic_set_duty_cycle':
>> drivers/input/misc/max77693-haptic.c:76:10: error: too few arguments to 
>> function 'pwm_config'
 error = pwm_config(haptic->pwm_dev, delta, haptic->pwm_dev->period);
 ^
   In file included from drivers/input/misc/max77693-haptic.c:23:0:
   include/linux/pwm.h:25:5: note: declared here
int pwm_config(struct pwm_device *pwm, int duty_ns,
^
--
   drivers/input/misc/max8997_haptic.c: In function 
'max8997_haptic_set_duty_cycle':
>> drivers/input/misc/max8997_haptic.c:76:9: error: too few arguments to 
>> function 'pwm_config'
  ret = pwm_config(chip->pwm, duty, chip->pwm_period);
^
   In file included from drivers/input/misc/max8997_haptic.c:29:0:
   include/linux/pwm.h:25:5: note: declared here
int pwm_config(struct pwm_device *pwm, int duty_ns,
^

vim +/pwm_config +76 drivers/input/misc/max77693-haptic.c

a3b3ca75 Jaewon Kim 2014-09-11  70  
a3b3ca75 Jaewon Kim 2014-09-11  71  static int 
max77693_haptic_set_duty_cycle(struct max77693_haptic *haptic)
a3b3ca75 Jaewon Kim 2014-09-11  72  {
a3b3ca75 Jaewon Kim 2014-09-11  73  int delta = (haptic->pwm_dev->period + 
haptic->pwm_duty) / 2;
a3b3ca75 Jaewon Kim 2014-09-11  74  int error;
a3b3ca75 Jaewon Kim 2014-09-11  75  
a3b3ca75 Jaewon Kim 2014-09-11 @76  error = pwm_config(haptic->pwm_dev, 
delta, haptic->pwm_dev->period);
a3b3ca75 Jaewon Kim 2014-09-11  77  if (error) {
a3b3ca75 Jaewon Kim 2014-09-11  78  dev_err(haptic->dev, "failed to 
configure pwm: %d\n", error);
a3b3ca75 Jaewon Kim 2014-09-11  79  return error;

:: The code at line 76 was first introduced by commit
:: a3b3ca753cdc92c7d5f57404afed3115b3b79cc6 Input: add haptic driver on 
max77693

:: TO: Jaewon Kim 
:: CC: Dmitry Torokhov 

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


.config.gz
Description: Binary data

Re: [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms

[Murali Karicheri]

Russell,

On 10/23/2015 02:52 PM, Kishon Vijay Abraham I wrote:

Hi,

On Friday 23 October 2015 08:16 PM, Russell King - ARM Linux wrote:

On Fri, Oct 23, 2015 at 11:17:06AM +0200, Arnd Bergmann wrote:

On Thursday 22 October 2015 15:27:05 Loc Ho wrote:


phy-xgene.c
---


---CUT---


Let me comment on this APM X-Gene driver. This driver is dead and
won't be supported in near or foreseeable future. And someday, it will
be ripped out. Based on experience, this solution (having PHY driver
in Linux) can't be supported across boards and etc as it is just too
much maintenance. And therefore, we followed Arnd B guidance and move
all this into the boot loader. From Linux or OS perspective, it only
cares about the interface in which its interface with. This is just
your reference and may be this will help you as well.


This depends a lot on the use case. If the chip is only used on server
parts that have a real firmware and you can deliver bug fixes for the
firmware if necessary, it's always best to do as much of the setup as
possible there, and let Linux see a simplified view of the hardware.

However, for embedded systems that tend to ship with a minimal binary
bootloader and no way to update that as an end-user, we rely on Linux
to know about all the hardware that requires some form of setup, which
is why we have all sorts of drivers and frameworks in the kernel that
a server can easily ignore.

While keystone can show up in servers that won't use this driver, my
impression is that its main market is actually in embedded space.


That's an interesting point of view - especially as you can't make the
argument that Marvell Armada chips would ever be anything but the
embedded space, but we're so far getting away with having the serdes
setup in u-boot - and even Marvell's BSP doesn't have it in the kernel.

The real question here is:

   Why would we want to statically setup serdes links in the kernel
   according to the DTB, rather than having the boot loader set them up?


Lot of PHYs have HW configure the parameters with default values so the
driver really doesn't have to touch them (like programming the equalizer
and the various digital mode configuration and analog mode
configuration). Then the SW just has to take care of clock programming
and powering on/off the PHY.

Some platforms require the controller core be in reset before powering
on the PHY, so we can't have all the configurations done in bootloader
for all the platforms.

The problem w.r.t code size starts when the drivers starts to configure
the analog and digital components inside the PHY (like equalizer,
attenuation etc..).



Agree. There are also calibration required on the receive side for 10G 
and SRIO that adds to the code size. SRIO is currently not supported, 
but expected to be supported in the future. For 10G, and SRIO, it is 
expected that user may need to tune the coefficients on a per board 
basis and hence we can't afford to have the driver in the boot loader.



While performing all these configurations in bootloader will help reduce
the code size, as Arnd pointed out, it'll cause problems if the PHY
loses the contents after a suspend/resume cycle.




Agree.


For the most part, the choice between the serdes modes is fairly static,
depending on the board wiring.  You wouldn't ever want to configure a
mini-PCIe socket for gigabit ethernet.

This is true for most of the serdes except 10G. 10G would require 
reconfiguration of the SerDes if it has to work in 1G mode. You wouldn't 
want to power cycle the board in case user wants to plug in a 1G link. 
We plan to add 10G support based on this serdes patch and also need to 
handle 1G mode on 10G as well in the future.


10G also has another mode to use a firmware that handles auto 
negotiation. User may use different firmware as well and has to be taken 
care of in the driver. How do we support this if this has to be in boot 
loader?



However, there are cases when you would want to change it, and I'm
aware of these cases:

* Serdes routed to a mini-PCIe socket, which is compatible with mSATA.
   There's an argument here to allow the serdes link to be switched at
   runtime between PCIe and mSATA.  However, the card type can't be
   detected at run time, so this would have to be a manual configuration
   change by the user.

   Since mini-PCIe is not hot-pluggable, this configuration isn't
   something that could be changed without powering the system down.

* Serdes routed to a SFP cage, where the serdes link is configured
   for gigabit (or faster for SFP+) ethernet.  For gigabit only, serdes
   is configured in either 1000base-X or Cisco SGMII mode (SGMII is a
   non-802.3 modification to 1000base-X) depending on the type of
   transceiver plugged in.

   Arguably, there's a third option here, which is SATA as well -  I'm
   aware of one non-standard SFP module on the market which provides a
   SATA connector, 

Re: [PATCH 08/10] pwm: core: add pulse feature to the PWM framework

[kbuild test robot]

Hi Olliver,

[auto build test WARNING on pwm/for-next -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Olliver-Schinagl/pwm-lpc18xx_pwm-use-pwm_set_chip_data/20151027-053853
config: avr32-atstk1006_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=avr32 

All warnings (new ones prefixed by >>):

>> drivers/pwm/pwm-atmel.c:278: warning: initialization from incompatible 
>> pointer type

vim +278 drivers/pwm/pwm-atmel.c

472ac3dc Alexandre Belloni 2015-05-25  262  
mutex_lock(&atmel_pwm->isr_lock);
472ac3dc Alexandre Belloni 2015-05-25  263  atmel_pwm->updated_pwms |= 
atmel_pwm_readl(atmel_pwm, PWM_ISR);
472ac3dc Alexandre Belloni 2015-05-25  264  
472ac3dc Alexandre Belloni 2015-05-25  265  while 
(!(atmel_pwm->updated_pwms & (1 << pwm->hwpwm)) &&
472ac3dc Alexandre Belloni 2015-05-25  266 time_before(jiffies, 
timeout)) {
472ac3dc Alexandre Belloni 2015-05-25  267  usleep_range(10, 100);
472ac3dc Alexandre Belloni 2015-05-25  268  atmel_pwm->updated_pwms 
|= atmel_pwm_readl(atmel_pwm, PWM_ISR);
472ac3dc Alexandre Belloni 2015-05-25  269  }
32b16d46 Bo Shen   2013-12-13  270  
472ac3dc Alexandre Belloni 2015-05-25  271  
mutex_unlock(&atmel_pwm->isr_lock);
32b16d46 Bo Shen   2013-12-13  272  atmel_pwm_writel(atmel_pwm, 
PWM_DIS, 1 << pwm->hwpwm);
32b16d46 Bo Shen   2013-12-13  273  
32b16d46 Bo Shen   2013-12-13  274  clk_disable(atmel_pwm->clk);
32b16d46 Bo Shen   2013-12-13  275  }
32b16d46 Bo Shen   2013-12-13  276  
32b16d46 Bo Shen   2013-12-13  277  static const struct pwm_ops 
atmel_pwm_ops = {
32b16d46 Bo Shen   2013-12-13 @278  .config = atmel_pwm_config,
32b16d46 Bo Shen   2013-12-13  279  .set_polarity = 
atmel_pwm_set_polarity,
32b16d46 Bo Shen   2013-12-13  280  .enable = atmel_pwm_enable,
32b16d46 Bo Shen   2013-12-13  281  .disable = atmel_pwm_disable,
32b16d46 Bo Shen   2013-12-13  282  .owner = THIS_MODULE,
32b16d46 Bo Shen   2013-12-13  283  };
32b16d46 Bo Shen   2013-12-13  284  
32b16d46 Bo Shen   2013-12-13  285  struct atmel_pwm_data {
32b16d46 Bo Shen   2013-12-13  286  void (*config)(struct pwm_chip 
*chip, struct pwm_device *pwm,

:: The code at line 278 was first introduced by commit
:: 32b16d46e4154d6f9d9c1d5dd35f64cdf08b7aea pwm: atmel-pwm: Add Atmel PWM 
controller driver

:: TO: Bo Shen 
:: CC: Thierry Reding 

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


.config.gz
Description: Binary data

Re: [PATCH 08/10] pwm: core: add pulse feature to the PWM framework

[kbuild test robot]

Hi Olliver,

[auto build test ERROR on pwm/for-next -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Olliver-Schinagl/pwm-lpc18xx_pwm-use-pwm_set_chip_data/20151027-053853
config: x86_64-randconfig-n0-10270521 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_panel.c: In function 'pwm_set_backlight':
>> drivers/gpu/drm/i915/intel_panel.c:652:2: error: too few arguments to 
>> function 'pwm_config'
 pwm_config(panel->backlight.pwm, duty_ns, CRC_PMIC_PWM_PERIOD_NS);
 ^
   In file included from drivers/gpu/drm/i915/intel_panel.c:35:0:
   include/linux/pwm.h:52:19: note: declared here
static inline int pwm_config(struct pwm_device *pwm, int duty_ns,
  ^
   drivers/gpu/drm/i915/intel_panel.c: In function 'pwm_disable_backlight':
   drivers/gpu/drm/i915/intel_panel.c:797:2: error: too few arguments to 
function 'pwm_config'
 pwm_config(panel->backlight.pwm, 0, CRC_PMIC_PWM_PERIOD_NS);
 ^
   In file included from drivers/gpu/drm/i915/intel_panel.c:35:0:
   include/linux/pwm.h:52:19: note: declared here
static inline int pwm_config(struct pwm_device *pwm, int duty_ns,
  ^
   drivers/gpu/drm/i915/intel_panel.c: In function 'pwm_setup_backlight':
   drivers/gpu/drm/i915/intel_panel.c:1442:11: error: too few arguments to 
function 'pwm_config'
 retval = pwm_config(panel->backlight.pwm, CRC_PMIC_PWM_PERIOD_NS,
  ^
   In file included from drivers/gpu/drm/i915/intel_panel.c:35:0:
   include/linux/pwm.h:52:19: note: declared here
static inline int pwm_config(struct pwm_device *pwm, int duty_ns,
  ^

vim +/pwm_config +652 drivers/gpu/drm/i915/intel_panel.c

0fb890c0 Vandana Kannan 2015-05-05  646  
b029e66f Shobhit Kumar  2015-06-26  647  static void pwm_set_backlight(struct 
intel_connector *connector, u32 level)
b029e66f Shobhit Kumar  2015-06-26  648  {
b029e66f Shobhit Kumar  2015-06-26  649 struct intel_panel *panel = 
&connector->panel;
b029e66f Shobhit Kumar  2015-06-26  650 int duty_ns = 
DIV_ROUND_UP(level * CRC_PMIC_PWM_PERIOD_NS, 100);
b029e66f Shobhit Kumar  2015-06-26  651  
b029e66f Shobhit Kumar  2015-06-26 @652 
pwm_config(panel->backlight.pwm, duty_ns, CRC_PMIC_PWM_PERIOD_NS);
b029e66f Shobhit Kumar  2015-06-26  653  }
b029e66f Shobhit Kumar  2015-06-26  654  
7bd688cd Jani Nikula2013-11-08  655  static void

:: The code at line 652 was first introduced by commit
:: b029e66fa8e39ba10dcc47b114be8da8b082493b drm/i915: Backlight control 
using CRC PMIC based PWM driver

:: TO: Shobhit Kumar 
:: CC: Daniel Vetter 

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


.config.gz
Description: Binary data

Re: [PATCH 01/10] pwm: lpc18xx_pwm: use pwm_set_chip_data

[Ezequiel Garcia]

(+ 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.

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.
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
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/14] devicetree: Add hardware rng entry to qcom-apq8064.dtsi

[Bjorn Andersson]

On Fri 18 Sep 05:31 PDT 2015, Srinivas Kandagatla wrote:

> From: John Stultz 
> 
> Add devicetree data to add support for hw_rng support
> to the apq8064 dts.
> 
> Tested on the Nexus7 (2013).
> 
> Cc: Kumar Gala 
> Cc: Stephen Boyd 
> Cc: Srinivas Kandagatla 
> Cc: devicetree@vger.kernel.org

Reviewed-by: Bjorn Andersson 

> Reviewed-by: Stephen Boyd 
> Signed-off-by: John Stultz 

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

Re: [PATCH v3 1/2] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

[Måns Rullgård]

Forgot to CC netdev.

Mans Rullgard  writes:

> This adds a binding for the Aurora VLSI NB8800 Ethernet controller
> using the "aurora,nb8800" compatible string.  When used in Sigma
> Designs chips a few additional features are available.  These variants
> are indicated by a "sigma,-ethernet" compatible string.
>
> Signed-off-by: Mans Rullgard 
> ---
> Changes:
> - added phy child node
> ---
>  .../devicetree/bindings/net/aurora,nb8800.txt  | 37 
> ++
>  1 file changed, 37 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/aurora,nb8800.txt
>
> diff --git a/Documentation/devicetree/bindings/net/aurora,nb8800.txt 
> b/Documentation/devicetree/bindings/net/aurora,nb8800.txt
> new file mode 100644
> index 000..df12ff1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/aurora,nb8800.txt
> @@ -0,0 +1,37 @@
> +* Aurora VLSI AU-NB8800 Ethernet controller
> +
> +Required properties:
> +- compatible: Should be "sigma,-ethernet", "aurora,nb8800"
> +- reg: Should be MMIO address space of the device
> +- interrupts: Should contain the interrupt specifier for the device
> +- interrupt-parent: Should be a phandle for the interrupt controller
> +- clocks: Should be a phandle for the clock for the device
> +- #address-cells: Should be <1>
> +- #size-cells: Should be <0>
> +
> +Common properties described in ethernet.txt:
> +- local-mac-address
> +- mac-address
> +- phy-handle
> +- phy-mode
> +
> +The attached PHY should be specified in a child node as per phy.txt.
> +
> +Example:
> +
> +ethernet@26000 {
> + compatible = "sigma,smp8642-ethernet", "aurora,nb8800";
> + reg = <0x26000 0x800>;
> + interrupts = <38>;
> + clocks = <&sys_clk>;
> + max-speed = <1000>;
> + phy-connection-type = "rgmii";
> + phy-handle = <ð0_phy>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + eth0_phy: ethernet-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + };
> +};
> -- 
> 2.6.2
>

-- 
Måns Rullgård
m...@mansr.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 00/10]

[Olliver Schinagl]

Hey Thierry,

With this patch set I wanted to add some new features to the PWM framework,
while doing so, I ran into 2 minor things with the lpc18xx and sunxi driver.

The lpc18xx I bumped into because I was trying to learn from existing drivers.
Here I only added the setter to set the chip_data, since I think it is bad
practice to set data directly in the struct, I'll be happy to stand corrected
however and that patch not applied.

Since I use the sunxi platform a lot, I used this platform to test things with
and to also ran into some issues with the hardware PWM as can be seen in its
commit log.

The major feature of this patch-set however is the introduction of the Generic
GPIO based PWM driver based on the high-resolution timers. On an Olimex Lime2
featuring an Allwinner A20 SoC, I can toggle quite reliably at 100 kHz. At 150
kHz the SoC started to show signs of being to slow and the scope traces started
to become inconsistent.
Naturally of course, a GPIO based PWM is heavily dependent on system load and
on the SoC. For some use cases a bit-banged PWM might not be ideal, audio for
example does not sound 'pitch-perfect' but does work pretty alright. It really
is up to the users what one might one to use a bit-banged GPIO driver for.

Finally, I've started to add a 'pulse' option to the PWM framework and
added it to the sunxi and gpio variants. It currently does not work and I
did not wanted to submit it until Boris's PWM patches where in, but I also
felt an early review on the intention would be a good idea.
The idea is using this new feature, we can start emitting a fixed number of
pulses, using the PWM 'hardware' guaranteeing properly timed output.
Not all hardware may support this at all (might be emulated however) and the
sunxi hardware for example is limited to 1 pulse max (but may emulate more with
timers for example). The GPIO driver is able to produce a lot of timed pulses
however.

Thanks,

Olliver

Signed-off-by: Olliver Schinagl 

Olliver Schinagl (10):
  pwm: lpc18xx_pwm: use pwm_set_chip_data
  pwm: sunxi: fix whitespace issue
  pwm: sunxi: Yield some time to the pwm-block to become ready
  pwm: core: use bitops
  pwm: sysfs: do not unnecessarily store result in var
  pwm: sysfs: make use of the DEVICE_ATTR_[RW][WO] macro's
  pwm: gpio: Add a generic gpio based PWM driver
  pwm: core: add pulse feature to the PWM framework
  pwm: pwm_gpio: add pulse option
  pwm: sunxi: Add possibility to pulse the sunxi pwm output

 Documentation/devicetree/bindings/pwm/pwm-gpio.txt |  18 ++
 MAINTAINERS|   5 +
 drivers/pwm/Kconfig|  15 ++
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/core.c |  30 ++-
 drivers/pwm/pwm-gpio.c | 276 +
 drivers/pwm/pwm-lpc18xx-sct.c  |  11 +-
 drivers/pwm/pwm-sun4i.c|  73 --
 drivers/pwm/sysfs.c| 133 +++---
 include/linux/pwm.h|  71 +-
 10 files changed, 556 insertions(+), 77 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-gpio.txt
 create mode 100644 drivers/pwm/pwm-gpio.c

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

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

[Olliver Schinagl]

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.
+
+Example:
+#include 
+
+   pwm: pwm@0 {
+   compatible = "pwm-gpio";
+   #pwm-cells = 3;
+   pwm-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>;
+   pwm-gpios = <&pio 7 2 GPIO_ACTIVE_LOW>;
+   };
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
+
 GENERIC HDLC (WAN) DRIVERS
 M: Krzysztof Halasa 
 W: http://www.kernel.org/pub/linux/utils/net/hdlc/
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 0cfaf6b..c0bc296 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -170,6 +170,21 @@ config PWM_IMG
  To compile this driver as a module, choose M here: the module
  will be called pwm-img
 
+config PWM_GPIO
+   tristate "Generic GPIO bit-banged PWM driver"
+   depends on OF
+   depends on GPIOLIB
+   help
+ Some platforms do not offer any hardware PWM capabilities but do have
+ General Purpose Input Output (GPIO) pins available. Using the kernels
+ High-Resolution Timer API this driver tries to toggle GPIO using the
+ generic kernel PWM framework. The maximum frequency and/or accuracy
+ is dependent on several factors such as system load and the maximum
+ speed a pin can be toggled at the hardware.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-gpio.
+
 config PWM_IMX
tristate "i.MX PWM support"
depends on ARCH_MXC
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 69b8275..96aa9aa 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_PWM_CLPS711X)+= pwm-clps711x.o
 obj-$(CONFIG_PWM_CRC)  += pwm-crc.o
 obj-$(CONFIG_PWM_EP93XX)   += pwm-ep93xx.o
 obj-$(CONFIG_PWM_FSL_FTM)  += pwm-fsl-ftm.o
+obj-$(CONFIG_PWM_GPIO) += pwm-gpio.o
 obj-$(CONFIG_PWM_IMG)  += pwm-img.o
 obj-$(CONFIG_PWM_IMX)  += pwm-imx.o
 obj-$(CONFIG_PWM_JZ4740)   += pwm-jz4740.o
diff --git a/drivers/pwm/pwm-gpio.c b/drivers/pwm/pwm-gpio.c
new file mode 100644
index 000..8b588fb
--- /dev/null
+++ b/drivers/pwm/pwm-gpio.c
@@ -0,0 +1,253 @@
+/*
+ * Copyright (c) 2015 Olliver Schinagl 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * This driver adds a high-resolution timer based PWM driver. Since this is a
+ * bit-banged driver, accuracy will always depend on a lot of factors, such as
+ * GPIO toggle speed and system load.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME "pwm-gpio"
+
+struct gpio_pwm_data {
+   struct hrtimer timer;
+   struct gpio_desc *gpiod;
+   bool polarity;
+   bool pin_on;
+   int on_time;
+

[PATCH v3 1/2] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

[Mans Rullgard]

This adds a binding for the Aurora VLSI NB8800 Ethernet controller
using the "aurora,nb8800" compatible string.  When used in Sigma
Designs chips a few additional features are available.  These variants
are indicated by a "sigma,-ethernet" compatible string.

Signed-off-by: Mans Rullgard 
---
Changes:
- added phy child node
---
 .../devicetree/bindings/net/aurora,nb8800.txt  | 37 ++
 1 file changed, 37 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/aurora,nb8800.txt

diff --git a/Documentation/devicetree/bindings/net/aurora,nb8800.txt 
b/Documentation/devicetree/bindings/net/aurora,nb8800.txt
new file mode 100644
index 000..df12ff1
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/aurora,nb8800.txt
@@ -0,0 +1,37 @@
+* Aurora VLSI AU-NB8800 Ethernet controller
+
+Required properties:
+- compatible: Should be "sigma,-ethernet", "aurora,nb8800"
+- reg: Should be MMIO address space of the device
+- interrupts: Should contain the interrupt specifier for the device
+- interrupt-parent: Should be a phandle for the interrupt controller
+- clocks: Should be a phandle for the clock for the device
+- #address-cells: Should be <1>
+- #size-cells: Should be <0>
+
+Common properties described in ethernet.txt:
+- local-mac-address
+- mac-address
+- phy-handle
+- phy-mode
+
+The attached PHY should be specified in a child node as per phy.txt.
+
+Example:
+
+ethernet@26000 {
+   compatible = "sigma,smp8642-ethernet", "aurora,nb8800";
+   reg = <0x26000 0x800>;
+   interrupts = <38>;
+   clocks = <&sys_clk>;
+   max-speed = <1000>;
+   phy-connection-type = "rgmii";
+   phy-handle = <ð0_phy>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   eth0_phy: ethernet-phy@1 {
+   compatible = "ethernet-phy-ieee802.3-c22";
+   reg = <1>;
+   };
+};
-- 
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 05/10] pwm: sysfs: do not unnecessarily store result in var

[Olliver Schinagl]

From: Olliver Schinagl 

Use the result of pwm_is_enabled directly instead of storing it first.

Signed-off-by: Olliver Schinagl 
---
 drivers/pwm/sysfs.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
index c472772..ba67845 100644
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -97,9 +97,8 @@ static ssize_t pwm_enable_show(struct device *child,
   char *buf)
 {
const struct pwm_device *pwm = child_to_pwm_device(child);
-   int enabled = pwm_is_enabled(pwm);
 
-   return sprintf(buf, "%d\n", enabled);
+   return sprintf(buf, "%d\n", pwm_is_enabled(pwm));
 }
 
 static ssize_t pwm_enable_store(struct device *child,
-- 
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

[PATCH 08/10] pwm: core: add pulse feature to the PWM framework

[Olliver Schinagl]

From: Olliver Schinagl 

Some hardware PWM's have the possibility to only send out one (or more)
pulses. This can be quite a useful feature in case one wants or needs
only a single pulse, but at the exact width.

Additionally, if multiple pulses are possible, outputting a fixed amount
of pulses can be useful for various timing specific purposes.

A few new functions have been expanded or added for this new behavior.

* pwm_config()  now takes an additional parameter to setup the number of
pulses to output. The driver may force this to 0 or 1
for if example if this feature is not or only partially
supported
* pwm_[sg]et_pulse_count()  get or set the number of pulses the pwm
framework is configured for
* pwm_get_pulse_count_max() get the maximum number of pulses the pwm
driver supports
* pwm_pulse()   Tell the PWM to emit a pre-configured number of pulses
* pwm_pulse_done()  an internal function for drivers to call when
they have completed their pre-configured number
of pulses
* pwm_is_pulsing()  tells the callers if the pwm is busy pulsing,
yielding a little more information than just
pwm_is_enabled()

Signed-off-by: Olliver Schinagl 
---
 drivers/pwm/core.c  | 30 +++
 drivers/pwm/pwm-gpio.c  |  3 ++-
 drivers/pwm/pwm-sun4i.c |  3 ++-
 drivers/pwm/sysfs.c | 58 ++--
 include/linux/pwm.h | 64 ++---
 5 files changed, 147 insertions(+), 11 deletions(-)

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 3f9df3e..e2c1c0a 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -432,22 +432,29 @@ EXPORT_SYMBOL_GPL(pwm_free);
  * @pwm: PWM device
  * @duty_ns: "on" time (in nanoseconds)
  * @period_ns: duration (in nanoseconds) of one cycle
+ * @pulse_count: number of pulses (periods) to output on pwm_pulse
  *
  * Returns: 0 on success or a negative error code on failure.
  */
-int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
+int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns,
+  unsigned int pulse_count)
 {
int err;
 
if (!pwm || duty_ns < 0 || period_ns <= 0 || duty_ns > period_ns)
return -EINVAL;
 
-   err = pwm->chip->ops->config(pwm->chip, pwm, duty_ns, period_ns);
+   if (pulse_count > pwm->pulse_count_max)
+   return -EINVAL;
+
+   err = pwm->chip->ops->config(pwm->chip, pwm, duty_ns,
+period_ns, pulse_count);
if (err)
return err;
 
pwm->duty_cycle = duty_ns;
pwm->period = period_ns;
+   pwm->pulse_count = pulse_count;
 
return 0;
 }
@@ -487,6 +494,18 @@ int pwm_set_polarity(struct pwm_device *pwm, enum 
pwm_polarity polarity)
 EXPORT_SYMBOL_GPL(pwm_set_polarity);
 
 /**
+ * pwm_pulse_done() - notify the PWM framework that pulse_count pulses are done
+ * @pwm: PWM device
+ */
+void pwm_pulse_done(struct pwm_device *pwm)
+{
+   if (pwm && !test_and_clear_bit(PWMF_ENABLED | PWMF_PULSING,
+  &pwm->flags))
+   return pwm->chip->ops->disable(pwm->chip, pwm);
+}
+EXPORT_SYMBOL_GPL(pwm_pulse_done);
+
+/**
  * pwm_enable() - start a PWM output toggling
  * @pwm: PWM device
  *
@@ -494,7 +513,9 @@ EXPORT_SYMBOL_GPL(pwm_set_polarity);
  */
 int pwm_enable(struct pwm_device *pwm)
 {
-   if (pwm && !test_and_set_bit(PWMF_ENABLED, &pwm->flags))
+   if (pwm && !test_and_set_bit(
+   PWMF_ENABLED | !pwm->pulse_count ? : PWMF_PULSING,
+   &pwm->flags))
return pwm->chip->ops->enable(pwm->chip, pwm);
 
return pwm ? 0 : -EINVAL;
@@ -507,7 +528,8 @@ EXPORT_SYMBOL_GPL(pwm_enable);
  */
 void pwm_disable(struct pwm_device *pwm)
 {
-   if (pwm && test_and_clear_bit(PWMF_ENABLED, &pwm->flags))
+   if (pwm && test_and_clear_bit(PWMF_ENABLED | PWMF_PULSING,
+ &pwm->flags))
pwm->chip->ops->disable(pwm->chip, pwm);
 }
 EXPORT_SYMBOL_GPL(pwm_disable);
diff --git a/drivers/pwm/pwm-gpio.c b/drivers/pwm/pwm-gpio.c
index 8b588fb..cf4b170 100644
--- a/drivers/pwm/pwm-gpio.c
+++ b/drivers/pwm/pwm-gpio.c
@@ -84,7 +84,7 @@ enum hrtimer_restart gpio_pwm_timer(struct hrtimer *timer)
 }
 
 static int gpio_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
-   int duty_ns, int period_ns)
+   int duty_ns, int period_ns, unsigned int count)
 {
struct gpio_pwm_data *gpio_data = pwm_get_chip_data(pwm);
 
@@ -202,6 +202,7 @@ static int gpio_pwm_probe(struct platform_device *pdev)
hrtimer++;
 
pwm_set_chip_data(&gpio_chip->chip.pwms

[PATCH 03/10] pwm: sunxi: Yield some time to the pwm-block to become ready

[Olliver Schinagl]

The pwm-block of some of the sunxi chips feature a 'ready' flag to
indicate the software that it is ready for new commands.

Right now, when we call pwm_config and set the period, we write the
values to the registers, and turn off the clock to the IP. Because of
this, the hardware does not have time to configure the hardware and set
the 'ready' flag.

By running the clock just before making new changes and before checking
if the hardware is ready, the hardware has time to reconfigure itself
and set the clear the flag appropriately.

Signed-off-by: Olliver Schinagl 
---
 drivers/pwm/pwm-sun4i.c | 43 +--
 1 file changed, 25 insertions(+), 18 deletions(-)

diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
index 58ff424..4d84d9d 100644
--- a/drivers/pwm/pwm-sun4i.c
+++ b/drivers/pwm/pwm-sun4i.c
@@ -104,6 +104,22 @@ static int sun4i_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
u64 clk_rate, div = 0;
unsigned int prescaler = 0;
int err;
+   int ret = 0;
+
+   /* Let the PWM hardware run before making any changes. We do this to
+* allow the hardware to have some time to clear the 'ready' flag.
+*/
+   err = clk_prepare_enable(sun4i_pwm->clk);
+   if (err) {
+   dev_err(chip->dev, "failed to enable PWM clock\n");
+   return err;
+   }
+   spin_lock(&sun4i_pwm->ctrl_lock);
+   val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
+   clk_gate = val & BIT_CH(PWM_CLK_GATING, pwm->hwpwm);
+   val |= BIT_CH(PWM_CLK_GATING, pwm->hwpwm);
+   sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
+   spin_unlock(&sun4i_pwm->ctrl_lock);
 
clk_rate = clk_get_rate(sun4i_pwm->clk);
 
@@ -136,7 +152,9 @@ static int sun4i_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
 
if (div - 1 > PWM_PRD_MASK) {
dev_err(chip->dev, "period exceeds the maximum 
value\n");
-   return -EINVAL;
+   ret = -EINVAL;
+   spin_lock(&sun4i_pwm->ctrl_lock);
+   goto out;
}
}
 
@@ -145,26 +163,14 @@ static int sun4i_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
do_div(div, period_ns);
dty = div;
 
-   err = clk_prepare_enable(sun4i_pwm->clk);
-   if (err) {
-   dev_err(chip->dev, "failed to enable PWM clock\n");
-   return err;
-   }
-
spin_lock(&sun4i_pwm->ctrl_lock);
val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
-
if (sun4i_pwm->data->has_rdy && (val & PWM_RDY(pwm->hwpwm))) {
-   spin_unlock(&sun4i_pwm->ctrl_lock);
-   clk_disable_unprepare(sun4i_pwm->clk);
-   return -EBUSY;
-   }
-
-   clk_gate = val & BIT_CH(PWM_CLK_GATING, pwm->hwpwm);
-   if (clk_gate) {
-   val &= ~BIT_CH(PWM_CLK_GATING, pwm->hwpwm);
-   sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
+   ret = -EBUSY;
+   goto out;
}
+   val &= ~BIT_CH(PWM_CLK_GATING, pwm->hwpwm);
+   sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
 
val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
val &= ~BIT_CH(PWM_PRESCAL_MASK, pwm->hwpwm);
@@ -174,6 +180,7 @@ static int sun4i_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
val = (dty & PWM_DTY_MASK) | PWM_PRD(prd);
sun4i_pwm_writel(sun4i_pwm, val, PWM_CH_PRD(pwm->hwpwm));
 
+out:
if (clk_gate) {
val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
val |= clk_gate;
@@ -183,7 +190,7 @@ static int sun4i_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
spin_unlock(&sun4i_pwm->ctrl_lock);
clk_disable_unprepare(sun4i_pwm->clk);
 
-   return 0;
+   return ret;
 }
 
 static int sun4i_pwm_set_polarity(struct pwm_chip *chip, struct pwm_device 
*pwm,
-- 
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

[PATCH 10/10] pwm: sunxi: Add possibility to pulse the sunxi pwm output

[Olliver Schinagl]

From: Olliver Schinagl 

With the new pulse mode addition to the PWM framework, we can make use
of this for the sunxi PWM.

WARNING: Do not merge yet, currently, we can only pulse once and a
manual disable is required to 'reset' the PWM framework. I haven't
thought through how to automatically 'disable' the PWM after the pulse
is finished and need some guidance here.

Signed-off-by: Olliver Schinagl 
---
 drivers/pwm/pwm-sun4i.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
index 6347ca8..8370cca 100644
--- a/drivers/pwm/pwm-sun4i.c
+++ b/drivers/pwm/pwm-sun4i.c
@@ -32,7 +32,7 @@
 #define PWM_EN BIT(4)
 #define PWM_ACT_STATE  BIT(5)
 #define PWM_CLK_GATING BIT(6)
-#define PWM_MODE   BIT(7)
+#define PWM_MODE_PULSE BIT(7)
 #define PWM_PULSE  BIT(8)
 #define PWM_BYPASS BIT(9)
 
@@ -166,6 +166,8 @@ static int sun4i_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
 
spin_lock(&sun4i_pwm->ctrl_lock);
val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
+   if (pulse_count)
+   val |= BIT_CH(PWM_MODE_PULSE, pwm->hwpwm);
if (sun4i_pwm->data->has_rdy && (val & PWM_RDY(pwm->hwpwm))) {
ret = -EBUSY;
goto out;
@@ -237,7 +239,10 @@ static int sun4i_pwm_enable(struct pwm_chip *chip, struct 
pwm_device *pwm)
 
spin_lock(&sun4i_pwm->ctrl_lock);
val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
-   val |= BIT_CH(PWM_EN, pwm->hwpwm);
+   if (pwm->pulse_count)
+   val |= BIT_CH(PWM_PULSE, pwm->hwpwm);
+   else
+   val |= BIT_CH(PWM_EN, pwm->hwpwm);
val |= BIT_CH(PWM_CLK_GATING, pwm->hwpwm);
sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
spin_unlock(&sun4i_pwm->ctrl_lock);
@@ -350,9 +355,12 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
}
 
val = sun4i_pwm_readl(pwm, PWM_CTRL_REG);
-   for (i = 0; i < pwm->chip.npwm; i++)
+   for (i = 0; i < pwm->chip.npwm; i++) {
if (!(val & BIT_CH(PWM_ACT_STATE, i)))
pwm->chip.pwms[i].polarity = PWM_POLARITY_INVERSED;
+
+   pwm_set_pulse_count_max(&pwm->chip.pwms[i], 1);
+   }
clk_disable_unprepare(pwm->clk);
 
return 0;
-- 
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

[PATCH 09/10] pwm: pwm_gpio: add pulse option

[Olliver Schinagl]

From: Olliver Schinagl 

With the newly added pwm_pulse option added to the PWM framework, this
patch adds the pulse functionality to the gpio_pwm driver.

Signed-off-by: Olliver Schinagl 
---
 drivers/pwm/pwm-gpio.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/pwm/pwm-gpio.c b/drivers/pwm/pwm-gpio.c
index cf4b170..24c27b1 100644
--- a/drivers/pwm/pwm-gpio.c
+++ b/drivers/pwm/pwm-gpio.c
@@ -40,6 +40,8 @@ struct gpio_pwm_data {
bool pin_on;
int on_time;
int off_time;
+   unsigned int count;
+   bool pulse;
bool run;
 };
 
@@ -80,6 +82,16 @@ enum hrtimer_restart gpio_pwm_timer(struct hrtimer *timer)
gpio_data->pin_on = false;
}
 
+   if (gpio_data->count > 0)
+   gpio_data->count--;
+   if (!gpio_data->count && gpio_data->pulse) {
+   struct pwm_device *pwm = container_of((void *)gpio_data,
+ struct pwm_device,
+ chip_data);
+   pwm_pulse_done(pwm);
+   return HRTIMER_NORESTART;
+   }
+
return HRTIMER_RESTART;
 }
 
@@ -88,6 +100,10 @@ static int gpio_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
 {
struct gpio_pwm_data *gpio_data = pwm_get_chip_data(pwm);
 
+   /* A full pulse is both the on and off time, and since counting each
+* iteration of the timer is easy and clean, we need double the count.
+*/
+   gpio_data->count = count * 2;
gpio_data->on_time = duty_ns;
gpio_data->off_time = period_ns - duty_ns;
 
@@ -111,6 +127,9 @@ static int gpio_pwm_enable(struct pwm_chip *chip, struct 
pwm_device *pwm)
if (gpio_data->run)
return -EBUSY;
 
+   if (pwm->pulse_count)
+   gpio_data->pulse = true;
+   gpio_data->count = pwm->pulse_count;
gpio_data->run = true;
if (gpio_data->off_time) {
hrtimer_start(&gpio_data->timer, ktime_set(0, 0),
@@ -130,6 +149,7 @@ static void gpio_pwm_disable(struct pwm_chip *chip, struct 
pwm_device *pwm)
struct gpio_pwm_data *gpio_data = pwm_get_chip_data(pwm);
 
gpio_data->run = false;
+   gpio_data->pulse = false;
if (!gpio_data->off_time)
gpio_pwm_off(gpio_data);
 }
@@ -196,6 +216,8 @@ static int gpio_pwm_probe(struct platform_device *pdev)
gpio_data->timer.function = &gpio_pwm_timer;
gpio_data->gpiod = gpiod;
gpio_data->pin_on = false;
+   gpio_data->count = 0;
+   gpio_data->pulse = false;
gpio_data->run = false;
 
if (hrtimer_is_hres_active(&gpio_data->timer))
-- 
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

[PATCH 04/10] pwm: core: use bitops

[Olliver Schinagl]

From: Olliver Schinagl 

The pwm header defines bits manually while there is a nice bitops.h with
a BIT() macro. Use the BIT() macro to set bits in pwm.h

Signed-off-by: Olliver Schinagl 
---
 include/linux/pwm.h | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index d681f68..29315ad 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -1,6 +1,7 @@
 #ifndef __LINUX_PWM_H
 #define __LINUX_PWM_H
 
+#include 
 #include 
 #include 
 
@@ -74,9 +75,9 @@ enum pwm_polarity {
 };
 
 enum {
-   PWMF_REQUESTED = 1 << 0,
-   PWMF_ENABLED = 1 << 1,
-   PWMF_EXPORTED = 1 << 2,
+   PWMF_REQUESTED = BIT(0),
+   PWMF_ENABLED = BIT(1),
+   PWMF_EXPORTED = BIT(2),
 };
 
 /**
-- 
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

[PATCH 02/10] pwm: sunxi: fix whitespace issue

[Olliver Schinagl]

From: Olliver Schinagl 

This patch changes no code, it just fixes the whitespacing

Signed-off-by: Olliver Schinagl 
---
 drivers/pwm/pwm-sun4i.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
index 5ec4e8e..58ff424 100644
--- a/drivers/pwm/pwm-sun4i.c
+++ b/drivers/pwm/pwm-sun4i.c
@@ -115,7 +115,7 @@ static int sun4i_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
 * is not an integer so round it half up instead of
 * truncating to get less surprising values.
 */
-   div = clk_rate * period_ns + NSEC_PER_SEC/2;
+   div = clk_rate * period_ns + NSEC_PER_SEC / 2;
do_div(div, NSEC_PER_SEC);
if (div - 1 > PWM_PRD_MASK)
prescaler = 0;
-- 
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

[PATCH 06/10] pwm: sysfs: make use of the DEVICE_ATTR_[RW][WO] macro's

[Olliver Schinagl]

From: Olliver Schinagl 

For the npwm property the pwm sysfs interface already made use of the
DEVICE_ATTR_RO macro. This patch expands this to the other sysfs
properties so that the code base is concise and makes use of this
helpful macro.

This has the advantage of slightly reducing the code size, improving
readability and no longer using magic values for permissions.

Signed-off-by: Olliver Schinagl 
---
 drivers/pwm/sysfs.c | 72 ++---
 1 file changed, 36 insertions(+), 36 deletions(-)

diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
index ba67845..9c90886 100644
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -40,18 +40,18 @@ static struct pwm_device *child_to_pwm_device(struct device 
*child)
return export->pwm;
 }
 
-static ssize_t pwm_period_show(struct device *child,
-  struct device_attribute *attr,
-  char *buf)
+static ssize_t period_show(struct device *child,
+  struct device_attribute *attr,
+  char *buf)
 {
const struct pwm_device *pwm = child_to_pwm_device(child);
 
return sprintf(buf, "%u\n", pwm_get_period(pwm));
 }
 
-static ssize_t pwm_period_store(struct device *child,
-   struct device_attribute *attr,
-   const char *buf, size_t size)
+static ssize_t period_store(struct device *child,
+   struct device_attribute *attr,
+   const char *buf, size_t size)
 {
struct pwm_device *pwm = child_to_pwm_device(child);
unsigned int val;
@@ -66,18 +66,18 @@ static ssize_t pwm_period_store(struct device *child,
return ret ? : size;
 }
 
-static ssize_t pwm_duty_cycle_show(struct device *child,
-  struct device_attribute *attr,
-  char *buf)
+static ssize_t duty_cycle_show(struct device *child,
+  struct device_attribute *attr,
+  char *buf)
 {
const struct pwm_device *pwm = child_to_pwm_device(child);
 
return sprintf(buf, "%u\n", pwm_get_duty_cycle(pwm));
 }
 
-static ssize_t pwm_duty_cycle_store(struct device *child,
-   struct device_attribute *attr,
-   const char *buf, size_t size)
+static ssize_t duty_cycle_store(struct device *child,
+   struct device_attribute *attr,
+   const char *buf, size_t size)
 {
struct pwm_device *pwm = child_to_pwm_device(child);
unsigned int val;
@@ -92,18 +92,18 @@ static ssize_t pwm_duty_cycle_store(struct device *child,
return ret ? : size;
 }
 
-static ssize_t pwm_enable_show(struct device *child,
-  struct device_attribute *attr,
-  char *buf)
+static ssize_t enable_show(struct device *child,
+  struct device_attribute *attr,
+  char *buf)
 {
const struct pwm_device *pwm = child_to_pwm_device(child);
 
return sprintf(buf, "%d\n", pwm_is_enabled(pwm));
 }
 
-static ssize_t pwm_enable_store(struct device *child,
-   struct device_attribute *attr,
-   const char *buf, size_t size)
+static ssize_t enable_store(struct device *child,
+   struct device_attribute *attr,
+   const char *buf, size_t size)
 {
struct pwm_device *pwm = child_to_pwm_device(child);
int val, ret;
@@ -127,9 +127,9 @@ static ssize_t pwm_enable_store(struct device *child,
return ret ? : size;
 }
 
-static ssize_t pwm_polarity_show(struct device *child,
-struct device_attribute *attr,
-char *buf)
+static ssize_t polarity_show(struct device *child,
+struct device_attribute *attr,
+char *buf)
 {
const struct pwm_device *pwm = child_to_pwm_device(child);
const char *polarity = "unknown";
@@ -147,9 +147,9 @@ static ssize_t pwm_polarity_show(struct device *child,
return sprintf(buf, "%s\n", polarity);
 }
 
-static ssize_t pwm_polarity_store(struct device *child,
- struct device_attribute *attr,
- const char *buf, size_t size)
+static ssize_t polarity_store(struct device *child,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
 {
struct pwm_device *pwm = child_to_pwm_device(child);
enum pwm_polarity polarity;
@@ -167,10 +167,10 @@ static ssize_t pwm_polarity_store(struct device *child,
return ret ? : size;
 }
 
-static DEVICE_ATTR(period, 0644, pwm_period_show, pwm_period_s

[PATCH 01/10] pwm: lpc18xx_pwm: use pwm_set_chip_data

[Olliver Schinagl]

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

diff --git a/drivers/pwm/pwm-lpc18xx-sct.c b/drivers/pwm/pwm-lpc18xx-sct.c
index 9163085..0ab59f1 100644
--- a/drivers/pwm/pwm-lpc18xx-sct.c
+++ b/drivers/pwm/pwm-lpc18xx-sct.c
@@ -408,14 +408,17 @@ static int lpc18xx_pwm_probe(struct platform_device *pdev)
}
 
for (i = 0; i < lpc18xx_pwm->chip.npwm; i++) {
+   struct lpc18xx_pwm_data *lpc18xx_data;
+
pwm = &lpc18xx_pwm->chip.pwms[i];
-   pwm->chip_data = devm_kzalloc(lpc18xx_pwm->dev,
- sizeof(struct lpc18xx_pwm_data),
- GFP_KERNEL);
-   if (!pwm->chip_data) {
+   lpc18xx_data = devm_kzalloc(lpc18xx_pwm->dev,
+   sizeof(struct lpc18xx_pwm_data),
+   GFP_KERNEL);
+   if (!lpc18xx_data) {
ret = -ENOMEM;
goto remove_pwmchip;
}
+   pwm_set_chip_data(pwm, lpc18xx_data);
}
 
platform_set_drvdata(pdev, lpc18xx_pwm);
diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
index cd9dde5..5ec4e8e 100644
--- a/drivers/pwm/pwm-sun4i.c
+++ b/drivers/pwm/pwm-sun4i.c
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -244,6 +245,16 @@ static void sun4i_pwm_disable(struct pwm_chip *chip, 
struct pwm_device *pwm)
spin_lock(&sun4i_pwm->ctrl_lock);
val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
val &= ~BIT_CH(PWM_EN, pwm->hwpwm);
+   sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
+   spin_unlock(&sun4i_pwm->ctrl_lock);
+
+   /* Allow for the PWM hardware to finish its last toggle. The pulse
+* may have just started and thus we should wait a full period.
+*/
+   ndelay(pwm_get_period(pwm));
+
+   spin_lock(&sun4i_pwm->ctrl_lock);
+   val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
val &= ~BIT_CH(PWM_CLK_GATING, pwm->hwpwm);
sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
spin_unlock(&sun4i_pwm->ctrl_lock);
-- 
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

[PATCH 0/3] Remove the need for qcom,{msm-id,board-id,pmic-id}

[Stephen Boyd]

This patchset documents a compatible string format that encodes
all the information that was being encoded in qcom specific DT
properties in downstream msm kernels. The goal being to come
up with a format that will allow us to express the information
we want to express without requiring the use of vendor specific
properties. An updated dtbTool will be released after these new
bindings are accepted so that users can work with non-updateable
bootloaders.

This is an attempt to resolve a discussion around March of this year[1]
where the arm-soc maintainers suggested we express this information
through the board's compatible string.

[1] 
http://lkml.kernel.org/g/1425503602-24916-1-git-send-email-ga...@codeaurora.org

Stephen Boyd (3):
  devicetree: bindings: Document qcom board compatible format
  arm64: dts: qcom: Make msm8916-mtp compatible string compliant
  arm: dts: qcom: Update ifc6540 compat for qcom boot format

 Documentation/devicetree/bindings/arm/qcom.txt | 86 ++
 arch/arm/boot/dts/qcom-apq8084-ifc6540.dts |  2 +-
 arch/arm64/boot/dts/qcom/msm8916-mtp.dts   |  2 +-
 3 files changed, 88 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/qcom.txt

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[PATCH 2/3] arm64: dts: qcom: Make msm8916-mtp compatible string compliant

[Stephen Boyd]

This compatible string isn't compliant with the format for
subtypes. Replace it with a compliant compatible type.

Signed-off-by: Stephen Boyd 
---
 arch/arm64/boot/dts/qcom/msm8916-mtp.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8916-mtp.dts 
b/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
index fced77f0fd3a..b0a064d3806b 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
@@ -17,6 +17,6 @@
 
 / {
model = "Qualcomm Technologies, Inc. MSM 8916 MTP";
-   compatible = "qcom,msm8916-mtp", "qcom,msm8916-mtp-smb1360",
+   compatible = "qcom,msm8916-mtp", "qcom,msm8916-mtp/1",
"qcom,msm8916", "qcom,mtp";
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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/3] devicetree: bindings: Document qcom board compatible format

[Stephen Boyd]

Some qcom based bootloaders identify the dtb blob based on a set
of device properties like SoC, platform, PMIC, and revisions of
those components. In downstream kernels, these values are added
to the different component dtsi files (i.e. pmic dtsi file, SoC
dtsi file, board dtsi file, etc.) via qcom specific DT
properties. The dtb files are parsed by a program called dtbTool
that picks out these properties and creates a table of contents
binary blob with the property information and some offsets into
the concatenation of all the dtbs (termed a QCDT image).

The suggestion is to do this via the board compatible string
instead, because these qcom specific properties are never used by
the kernel. Add a document describing the format of the
compatible string that encodes all this information that's
currently encoded in the qcom,{msm-id,board-id,pmic-id}
properties in downstream devicetrees. Future bootloaders may be
updated to look at the compatible field instead of looking for
the table of contents image. For non-updateable bootloaders, a
new dtbTool program will parse the compatible string and generate
a QCDT image from it.

Signed-off-by: Stephen Boyd 
---
 Documentation/devicetree/bindings/arm/qcom.txt | 86 ++
 1 file changed, 86 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/qcom.txt

diff --git a/Documentation/devicetree/bindings/arm/qcom.txt 
b/Documentation/devicetree/bindings/arm/qcom.txt
new file mode 100644
index ..ed084367182d
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/qcom.txt
@@ -0,0 +1,86 @@
+QCOM device tree bindings
+-
+
+Some qcom based bootloaders identify the dtb blob based on a set of
+device properties like SoC, platform, PMIC, and revisions of those components.
+To support this scheme, we encode this information into the board compatible
+string.
+
+Each board must specify a top-level board compatible string with the following
+format:
+
+   compatible = 
"qcom,(-)(-)-(/)(-)(-MB)(--panel)(-boot-)(-(-v)){0-4}"
+
+where elements in parentheses "()" are optional and elements in brackets "<>"
+are names of elements. Meaning only the 'SoC' and 'plat_type' elements are
+required.
+
+The 'SoC' element must be one of the following strings:
+
+   apq8016
+   apq8074
+   apq8084
+   apq8096
+   msm8916
+   msm8974
+   msm8996
+
+The 'plat_type' element must be one of the following strings:
+
+   cdp
+   liquid
+   dragonboard
+   mtp sbc
+
+
+The 'soc_version', 'plat_version' and 'pmic_version' elements take the form of
+v. where the minor number may be omitted when it's zero, i.e.
+v1.0 is the same as v1. If all versions of the 'plat_version' element's match,
+then a wildcard '*' should be used, e.g. 'v*'.
+
+The 'foundry_id', 'subtype', and 'mb' elements are one or more digits from 0
+to 9.
+
+The 'panel' element must be one of the following strings:
+
+   720p
+   fWVGA
+   hd
+   qHD
+
+The 'boot' element must be one of the following strings:
+
+   emmc_sdc1
+   ufs
+
+The 'pmic' element must be one of the following strings:
+
+   pm8841
+   pm8019
+   pm8110
+   pma8084
+   pmi8962
+   pmd9635
+   pm8994
+   pmi8994
+   pm8916
+   pm8004
+   pm8909
+
+The 'pmic' element is specified in order of ascending USID. The PMIC in USID0
+goes first, and then USID2, USID4, and finally USID6. Up to four PMICs may be
+specified and no holes in the USID number space are allowed.
+
+Examples:
+
+   "qcom,msm8916-v1-cdp-pm8916-v2.1"
+
+A CDP board with an msm8916 SoC, version 1 paired with a pm8916 PMIC of version
+2.1.
+
+   
"qcom,apq8074-v2.0-2-dragonboard/1-v0.1-512MB-panel-qHD-boot-emmc_sdc1-pm8941-v0.2-pm8909-v2.2-pma8084-v3-pm8110-v1"
+
+A dragonboard board v0.1 of subtype 1 with an apq8074 SoC version 2, made in
+foundry 2 with 512MB of memory and a qHD panel booting from emmc_sdc1, paired
+with a pm8941 PMIC version 0.2 at USID0, pm8909 PMIC version 2.2 at USID2,
+pma8084 version 3 at USID4 and a pm8110 version 1 at USID6.
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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/3] arm: dts: qcom: Update ifc6540 compat for qcom boot format

[Stephen Boyd]

The ifc6540 is an sbc (single board computer) board, so update
the compatible field accordingly.

Signed-off-by: Stephen Boyd 
---
 arch/arm/boot/dts/qcom-apq8084-ifc6540.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts 
b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
index c9c2b769554f..32aaa9d45228 100644
--- a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
+++ b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
@@ -3,7 +3,7 @@
 
 / {
model = "Qualcomm APQ8084/IFC6540";
-   compatible = "qcom,apq8084-ifc6540", "qcom,apq8084";
+   compatible = "qcom,apq8084-sbc", "qcom,apq8084";
 
aliases {
serial0 = &blsp2_uart2;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Brian Norris]

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.

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.

Regards,
Brian
--
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: dts: sunxi: Add Allwinner H3 DTSI

[Maxime Ripard]

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 = <&ahb1>, <&ahb2>;
> > 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 = <&ahb1>, <&ahb2>, <&apb1>, <&apb2>;
>   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.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

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

[Maxime Ripard]

On Sat, Oct 24, 2015 at 10:39:49AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 10/23/2015 08:14 PM, Maxime Ripard wrote:
> >On Wed, Oct 21, 2015 at 06:20:27PM +0200, Jens Kuske wrote:
> >>+   bus_gates: clk@01c20060 {
> >>+   #clock-cells = <1>;
> >>+   compatible = "allwinner,sun8i-h3-bus-gates-clk";
> >>+   reg = <0x01c20060 0x14>;
> >>+   clock-indices = <5>, <6>, <8>,
> >>+   <9>, <10>, <13>,
> >>+   <14>, <17>, <18>,
> >>+   <19>, <20>,
> >>+   <21>, <23>,
> >>+   <24>, <25>,
> >>+   <26>, <27>,
> >>+   <28>, <29>,
> >>+   <30>, <31>, <32>,
> >>+   <35>, <36>, <37>,
> >>+   <40>, <41>, <43>,
> >>+   <44>, <52>, <53>,
> >>+   <54>, <64>,
> >>+   <65>, <69>, <72>,
> >>+   <76>, <77>, <78>,
> >>+   <96>, <97>, <98>,
> >>+   <112>, <113>,
> >>+   <114>, <115>, <116>,
> >>+   <128>, <135>;
> >>+   clocks = <&ahb1>, <&ahb1>, <&ahb1>,
> >>+<&ahb1>, <&ahb1>, <&ahb1>,
> >>+<&ahb1>, <&ahb2>, <&ahb1>,
> >>+<&ahb1>, <&ahb1>,
> >>+<&ahb1>, <&ahb1>,
> >>+<&ahb1>, <&ahb1>,
> >>+<&ahb1>, <&ahb1>,
> >>+<&ahb1>, <&ahb2>,
> >>+<&ahb2>, <&ahb2>, <&ahb1>,
> >>+<&ahb1>, <&ahb1>, <&ahb1>,
> >>+<&ahb1>, <&ahb1>, <&ahb1>,
> >>+<&ahb1>, <&ahb1>, <&ahb1>,
> >>+<&ahb1>, <&apb1>,
> >>+<&apb1>, <&apb1>, <&apb1>,
> >>+<&apb1>, <&apb1>, <&apb1>,
> >>+<&apb2>, <&apb2>, <&apb2>,
> >>+<&apb2>, <&apb2>,
> >>+<&apb2>, <&apb2>, <&apb2>,
> >>+<&ahb1>, <&ahb1>;
> >
> >This is not really what I had in mind...
> 
> I came to the same solution independently, I took my inspiration from
> the rockchip clocks driver which is dealing with this problem in the
> same way, so there is precedent for doing things this way, and this
> does give us lot of flexibility. Given that I expect other new allwinnner
> SoCs to have the same problem I believe it is good to have that
> flexibility.

The rockchip clocks driver are very different from our own regarding
the DT bindings. Being consistent within our own platform seems to
bring much more value than getting bits and pieces here and there when
it's convenient.

Plus, you actually forgot in your argument to mention that this
binding was documented as deprecated, and not used anywhere since
3.17... So apparently, someone tried that, and finally changed its
mind.

Again, this is clearly a workaround, with no way to easily identify if
a given clock has the right parent afterwards. We can't review it
properly, and it's going to be a pain to fix after the facts.

Having some association masks in the driver itself, using the BIT
macro, will be much easier to maintain in the long run.

> >This IP has 2 parents, and only two parents.
> 
> Nope it has 4: apb1, apb2, ahb1 and ahb2.

The point still remains though.

> >The mapping between the IPs should be done in the driver itself,
> >not in the DT where it is very error prone and barely readable.
> 
> It is just as error prone and barely readable in C-code, see Jens original
> patchset, he did an array of clock indices there (range 0-3 with an index
> into the parent clocks array), which is arguably even more unreadable since
> there is an extra level of indirection here.

I agree, and it's why I suggested another approach at the time.

> The problem with the unreadability simply comes from allwinner's decision
> to no longer have a gates register per bus but instead shove everything
> in a single bit-array in random order, there is nothing we can do to fix
> that.

Indeed. Except one solution is easier to maintain than the other.

> Also the argument "this belongs in the driver not in the DT" is a
> bit inconsistent with the moving of the mask of valid gates from the
> driver into the clock-indices in devicetree.

Except I never used that argument.

> The way things are done here actually are doing pretty much the same
> thing, putting info which could be derived from the compatible
> string into devicetree.
>
> Last as s

Re: [PATCH v3 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib

[Brian Norris]

+ 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(&pdev->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(&pdev->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?

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
> +++ b/include/linux/platform_data/mtd-nand-omap2.h
> @@ -70,7 +70,6 @@ struct omap_nand_platform_data {
>   int cs;
>   struct mtd_partition*parts;
>   int nr_parts;
> - booldev_ready;
>   boolflash_bbt;
>  

[PATCH v8] Documentation: add Device tree bindings for hwmon/nct7802

[Constantine Shulyupin]

From: Constantine Shulyupin 

Introduced subnodes sensor, fan and peci with properties.

Signed-off-by: Constantine Shulyupin 
---
Changed in v8:
- added senor type "local"
- Compatible nodes converted to senor types "vcore", "vcc"

Changed in v7:
- sensors type (thermistor, thermistor, voltage) and pwm type
selected with type property instead of compatible property.

Changed in v6:
- Removed previous definition.
- Introduced subnodes sensor, fan and peci with properties.

Changed in v5:
- Fixed typos

Changed in v4:
- Removed registers initialization by names
- Added properties nuvoton,sensor*-type

Changed in v3:
- Fixed vendor prefix
- Added short registers description,
  full registers description is available at
https://www.nuvoton.com/hq/products/cloud-computing/hardware-monitors/desktop-server-series/nct7802y/

Changed in v2:
- Removed nct7802,reg-init
- Added registers initialization by names

Introduced in v1:
 - nct7802,reg-init
---
 .../devicetree/bindings/hwmon/nct7802.txt  | 102 +
 1 file changed, 102 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/nct7802.txt

diff --git a/Documentation/devicetree/bindings/hwmon/nct7802.txt 
b/Documentation/devicetree/bindings/hwmon/nct7802.txt
new file mode 100644
index 000..8647783
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/nct7802.txt
@@ -0,0 +1,102 @@
+Nuvoton NCT7802Y Hardware Monitoring IC
+
+Required node properties:
+
+ - "compatible": must be "nuvoton,nct7802"
+ - "reg": I2C bus address of the device
+ - #address-cells=<1>;
+ - #size-cells=<0>;
+
+Optional subnodes:
+
+Sensor subnodes properties:
+ - "compatible", allowed values:
+- "nuvoton,nct7802"
+ - "sensor-type", allowed values:
+   "thermal-diode"
+   "thermistor"
+   "voltage"
+   "local"
+   "vcore"
+   "vcc"
+For sensors of types "thermal-diode", "thermistor" and "voltage" required
+ - "reg": index in range 0 .. 2
+
+Except sensor at address 2 can't be "thermal-diode".
+
+Fan subnode:
+
+Required properties:
+ - "reg" :index of in range 0 .. 2.
+ - "compatible", should be "nuvoton,nct7802-fan"
+Optional boolean properties:
+ - "direct-current" :direct current powered fan instead default PWM
+ - "invert" :inverted polarity
+ - "open-drain" :open-drain output instead push pull
+
+Subnode "peci" properties:
+ - "reg" :index in range 0 .. 1
+ - "compatible", should be "nuvoton,nct7802-peci"
+
+Not defined sensors, fans and PECI modules will be disabled.
+
+Example nct7802 node:
+
+nct7802-example@28 {
+   compatible = "nuvoton,nct7802";
+   reg = <0x28>;
+   #address-cells=<1>;
+   #size-cells=<0>;
+   local-sensor {
+   compatible = "nuvoton,nct7802-sensor";
+   sensor-type = "local";
+   };
+   sensor@0 {
+   compatible = "nuvoton,nct7802-sensor";
+   reg = <0>;
+   sensor-type = "thermal-diode";
+   };
+   sensor@1 {
+   compatible = "nuvoton,nct7802-sensor";
+   reg = <1>;
+   sensor-type = "thermistor";
+   };
+   sensor@2 {
+   compatible = "nuvoton,nct7802-sensor";
+   reg = <2>;
+   sensor-type = "voltage";
+   };
+   vcc {
+   compatible = "nuvoton,nct7802-sensor";
+   sensor-type = "vcc";
+   };
+   vcore {
+   compatible = "nuvoton,nct7802-sensor";
+   sensor-type = "vcore";
+   };
+   pwm-fan@0 {
+   compatible = "nuvoton,nct7802-fan";
+   reg = <0>;
+   };
+   dc-fan@1 {
+   compatible = "nuvoton,nct7802-fan";
+   reg = <1>;
+   direct-current;
+   open-drain;
+   invert;
+   };
+   fan@2 {
+   compatible = "nuvoton,nct7802-fan";
+   reg = <2>;
+   open-drain;
+   invert;
+   };
+   peci@0 {
+   compatible = "nuvoton,nct7802-peci";
+   reg = <0>;
+   };
+   peci@1 {
+   compatible = "nuvoton,nct7802-peci";
+   reg = <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 v2 05/32] scsi: hisi_sas: scan device tree

[kbuild test robot]

Hi John,

[auto build test ERROR on scsi/for-next -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/John-Garry/HiSilicon-SAS-driver/20151026-221717
config: x86_64-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "of_irq_count" [drivers/scsi/hisi_sas/hisi_sas_main.ko] undefined!

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


.config.gz
Description: Binary data

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

[Geert Uytterhoeven]

Hi Laurent,

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 = <&extal_clk>, <&extalr_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.

If a single device block (sharing the same register space), represented in
DT as a single device node, actually represents multiple modules, there's no
one-to-one mapping from SoC device to DT device node.
Hence the device node will have multiple module clocks, and the driver will
have to take care of managing them explicitly.

The register space sharing is an SoC-specific issue.
The single device node is a DT binding issue.

Perhaps such devices should use subnodes, so each of them can represent a
module, each with its own module clock.

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

[Bastien Nocera]

On Mon, 2015-10-26 at 19:21 +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).
> 
> 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.
> 
> 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.

I was waiting on at least Irina's patches being merged before testing
your patches again. I have limited time to do testing on this (I have
plenty more hardware that's sitting unloved here), and wanted to
minimise the amount of time I'd spend testing it.
--
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

[Ray Jui]

Hi Pramod,

On 10/26/2015 11:06 AM, Pramod Kumar wrote:

Hi Ray,


-Original Message-
From: Ray Jui [mailto:r...@broadcom.com]
Sent: 26 October 2015 22:43
To: Pramod Kumar; Laurent Pinchart; Rob Herring
Cc: Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala; Scott Branden; Russell
King; Linus Walleij; linux-g...@vger.kernel.org; bcm-kernel-feedback-list; Jason
Uy; Masahiro Yamada; Thomas Gleixner; devicetree@vger.kernel.org; linux-
arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org; Jonas Gorski
Subject: Re: [PATCH 05/11] dt-binding: Add ngpios property to GPIO controller
node

Hi Pramod,

On 10/26/2015 10:08 AM, Pramod Kumar wrote:




-Original Message-
From: Ray Jui [mailto:r...@broadcom.com]
Sent: 23 October 2015 21:38
To: Laurent Pinchart; Rob Herring
Cc: Pramod Kumar; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala;
Scott Branden; Russell King; Linus Walleij;
linux-g...@vger.kernel.org; bcm-kernel- feedback-list; Jason Uy;
Masahiro Yamada; Thomas Gleixner; devicetree@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; linux- ker...@vger.kernel.org;
Jonas Gorski
Subject: Re: [PATCH 05/11] dt-binding: Add ngpios property to GPIO
controller node



On 10/23/2015 6:02 AM, Laurent Pinchart wrote:

Hi Rob,

On Friday 23 October 2015 06:51:28 Rob Herring wrote:

On Fri, Oct 23, 2015 at 4:08 AM, Laurent Pinchart wrote:

On Thursday 22 October 2015 18:41:05 Rob Herring wrote:

On Thu, Oct 22, 2015 at 1:52 PM, Ray Jui wrote:

On 10/22/2015 11:43 AM, Rob Herring wrote:

On Mon, Oct 19, 2015 at 12: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 
---

Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt

| 5

+++
1 file changed, 5 insertions(+)

diff --git
a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.t
xt
b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.t
xt
index f92b833..655a8d7 100644
---
a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.t
xt
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gp
+++ io
+++ .txt

@@ -10,6 +10,9 @@ Required properties:
 Define the base and range of the I/O address space that
 contains

the Cygnus

 GPIO/PINCONF controller registers

+- ngpios:

+Total number of GPIOs the controller provides

This must be optional for compatibility and the driver needs to
handle it not present.


You meant to be compatible with existing Cygnus devices, correct?

Just to clarify, here you suggest we still leave the existing
hard coded ngpios in the driver, in order to be compatible with
all existing Cygnus devices (while the Cygnus device tree
changes to use ngpio is still being merged and through different
maintainer), and have all new iProc SoCs switch to use ngpios from

device tree, right?


Yes, an existing dtb should continue to work with a new kernel.
You can add the DT property to the older devices too and then
eventually remove the hard coded values some time in the future.
That could be immediately (don't care about compatibility at
all), a couple of kernel cycles, never... It all depends on users
of the impacted platforms.


But shouldn't the property still be documented as required to
ensure that new DTs always include it ?


Good point. If the intent is to eventually remove it from the
driver, then yes. We probably need "required for new designs" as a
category or maybe "recommended"? The wording is not so important
here, but I'm thinking about as we try to standardize the naming.


Required for new designs sounds better than recommended. Or maybe
something like "Required (optional for backward compatibility)".



Yes, it should be phrased as "required for new designs" because all
new iProc SoCs using this GPIO driver need to have this in DT.

Thanks,

Ray


Thanks for providing feedback. I'll make sure to use this property under phrase

" required for new designs " in next patch set.


Regards,
Pramod



To confirm, is your plan:

1) Continue to support hardcoded ngpios in the driver for the current SoC Cygnus
2) Proceed with Cygnus DTS changes to switch to DT based ngpios configuration
3) Modify the document to make DT ngpios a required property for all new SoCs
including NSP, NS2, and etc.

?

Thanks,

Ray


Ok. This patch-set is to make this driver more generic so that all future SoCs , as you 
mentioned like NS2, NSP, Stingray, could use it.  Since This Cygnus is in very very early 
stage and No customer is using it so we can afford it to address ngpio from DT and remove 
Cygnus hard coded values immediately from this patch. Otherwise we will see the same 
issue with "gpios-ranges" property and this will be highly inter-dependent as 
well.

Regards,
Pramod



That sounds fine to me. In this case, the patch set stays as it 

RE: [PATCH 05/11] dt-binding: Add ngpios property to GPIO controller node

[Pramod Kumar]

Hi Ray,

> -Original Message-
> From: Ray Jui [mailto:r...@broadcom.com]
> Sent: 26 October 2015 22:43
> To: Pramod Kumar; Laurent Pinchart; Rob Herring
> Cc: Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala; Scott Branden; Russell
> King; Linus Walleij; linux-g...@vger.kernel.org; bcm-kernel-feedback-list; 
> Jason
> Uy; Masahiro Yamada; Thomas Gleixner; devicetree@vger.kernel.org; linux-
> arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org; Jonas Gorski
> Subject: Re: [PATCH 05/11] dt-binding: Add ngpios property to GPIO controller
> node
> 
> Hi Pramod,
> 
> On 10/26/2015 10:08 AM, Pramod Kumar wrote:
> >
> >
> >> -Original Message-
> >> From: Ray Jui [mailto:r...@broadcom.com]
> >> Sent: 23 October 2015 21:38
> >> To: Laurent Pinchart; Rob Herring
> >> Cc: Pramod Kumar; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala;
> >> Scott Branden; Russell King; Linus Walleij;
> >> linux-g...@vger.kernel.org; bcm-kernel- feedback-list; Jason Uy;
> >> Masahiro Yamada; Thomas Gleixner; devicetree@vger.kernel.org;
> >> linux-arm-ker...@lists.infradead.org; linux- ker...@vger.kernel.org;
> >> Jonas Gorski
> >> Subject: Re: [PATCH 05/11] dt-binding: Add ngpios property to GPIO
> >> controller node
> >>
> >>
> >>
> >> On 10/23/2015 6:02 AM, Laurent Pinchart wrote:
> >>> Hi Rob,
> >>>
> >>> On Friday 23 October 2015 06:51:28 Rob Herring wrote:
>  On Fri, Oct 23, 2015 at 4:08 AM, Laurent Pinchart wrote:
> > On Thursday 22 October 2015 18:41:05 Rob Herring wrote:
> >> On Thu, Oct 22, 2015 at 1:52 PM, Ray Jui wrote:
> >>> On 10/22/2015 11:43 AM, Rob Herring wrote:
>  On Mon, Oct 19, 2015 at 12: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 
> > ---
> >
> >Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt
> | 5
> >+++
> >1 file changed, 5 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.t
> > xt
> > b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.t
> > xt
> > index f92b833..655a8d7 100644
> > ---
> > a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.t
> > xt
> > +++ b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gp
> > +++ io
> > +++ .txt
> >
> > @@ -10,6 +10,9 @@ Required properties:
> > Define the base and range of the I/O address space that
> > contains
> >
> > the Cygnus
> >
> > GPIO/PINCONF controller registers
> >
> > +- ngpios:
>  +Total number of GPIOs the controller provides
> 
>  This must be optional for compatibility and the driver needs to
>  handle it not present.
> >>>
> >>> You meant to be compatible with existing Cygnus devices, correct?
> >>>
> >>> Just to clarify, here you suggest we still leave the existing
> >>> hard coded ngpios in the driver, in order to be compatible with
> >>> all existing Cygnus devices (while the Cygnus device tree
> >>> changes to use ngpio is still being merged and through different
> >>> maintainer), and have all new iProc SoCs switch to use ngpios from
> device tree, right?
> >>
> >> Yes, an existing dtb should continue to work with a new kernel.
> >> You can add the DT property to the older devices too and then
> >> eventually remove the hard coded values some time in the future.
> >> That could be immediately (don't care about compatibility at
> >> all), a couple of kernel cycles, never... It all depends on users
> >> of the impacted platforms.
> >
> > But shouldn't the property still be documented as required to
> > ensure that new DTs always include it ?
> 
>  Good point. If the intent is to eventually remove it from the
>  driver, then yes. We probably need "required for new designs" as a
>  category or maybe "recommended"? The wording is not so important
>  here, but I'm thinking about as we try to standardize the naming.
> >>>
> >>> Required for new designs sounds better than recommended. Or maybe
> >>> something like "Required (optional for backward compatibility)".
> >>>
> >>
> >> Yes, it should be phrased as "required for new designs" because all
> >> new iProc SoCs using this GPIO driver need to have this in DT.
> >>
> >> Thanks,
> >>
> >> Ray
> >
> > Thanks for providing feedback. I'll make sure to use this property under 
> > phrase
> " required for new designs " in next patch set.
> >
> > Regards,
> > Pramod
> >
> 
> To conf

Re: [PATCH 03/10] ata: ahci_brcmstb: add support 40nm platforms

[Brian Norris]

Hi Jaedon,

On Sat, Oct 24, 2015 at 01:50:54PM +0900, Jaedon Shin wrote:
> On Oct 24, 2015, at 6:25 AM, Brian Norris  wrote:
> > On Fri, Oct 23, 2015 at 10:44:16AM +0900, Jaedon Shin wrote:
> > So, your patch gets phy control 1 correct for both ports, but it doesn't
> > get phy control 2 correct. (Or at least, even if my guess at the 40nm
> > layout is wrong, your patch makes "port 0, phy control 2" collide with
> > "port 1, phy control 1", which is most certainly a bug.)
> > 
> > Are you sure you're testing this properly? Did you try using both ports
> > at the same time? And please, apply the same scrutiny to the PHY driver.
> > (e.g., did you test SSC? did you test both ports?)
> > 
> > Brian
> > 
> 
> You are right. This must be changed. 
> 
> I found the 28nm chipsets have four phy interface control registers. But, 
> the the 40nm chipsets have only three registers. I did not testing with 
> two ports at the same time. It seems we should check more.

OK. So you don't just need more testing, you need to make sure the code
actually matches the documentation at all. If there are only 3 PHY
control registers for 40nm, then this driver (as patched by you) doesn't
make any sense. It will need a much different patch than what you gave.

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